[no subject]

2018-11-26 Thread Offer
-- 
-- 
Guten Tag, Wir sind eine registrierte private Geldverleiher. Wir geben
Kredite an Firmen, Einzelpersonen, die ihre finanzielle Status auf der
ganzen Welt aktualisieren müssen, mit minimalen jährlichen Zinsen von
2% .reply, wenn nötig.

Good Day, We are a registered private money lender. We give out loans
to firms, Individual who need to update their financial status all
over the world, with Minimal annual Interest Rates of 2%reply if
needed.


[no subject]

2018-11-18 Thread Major Dennis Hornbeck



I am in the military unit here in Afghanistan, we have some amount of funds 
that we want to move out of the country. My partners and I need a good partner 
someone we can trust. It is risk free and legal. Reply to this email: 
hornbeckmajordennis...@gmail.com
Regards,Major Dennis Hornbeck.


[no subject]

2018-11-18 Thread Mrs. Maureen Hinckley



I am Maureen Hinckley and my foundation is donating (Five hundred and fifty 
thousand USD) to you. Contact us via my email at (maurhin...@gmail.com) for 
further details.


 Best Regards, Mrs. Maureen Hinckley,  Copyright 2018 The Maureen 
Hinckley Foundation All Rights Reserved.


[no subject]

2018-11-11 Thread Oliver Carter
Netdev https://goo.gl/pW8d8y Oliver Carter

[no subject]

2018-10-30 Thread Ubaithullah Masood
This is Mr Ubaithullah Masood from Banco Santander Bank S A Hong Kong.
I got your contact during my private search on net..Would you be
interested in a business transaction to act as the beneficiary to
claim 9.8M USD funds of my deceased client who died intestate (
Without a Will)and my bank wants to confiscate the funds if the funds
are not claimed soon. Do get back for more details as this deal is
safe and all documentation will be done legally and we will share 50%
each.
Thanks.


[no subject]

2018-10-19 Thread David Miller
From: David Howells 
Date: Fri, 19 Oct 2018 21:51:35 +0100

> David Miller  wrote:
> 
>> > Is there going to be a merge of net into net-next before the merge
>> > window opens?  Or do you have a sample merge that I can rebase my
>> > afs-next branch on?
>> 
>> I'll be doing a net to net-next merge some time today.
> 
> Excellent, thanks!

And this is now complete.


[no subject]

2018-10-19 Thread David Howells
David Miller  wrote:

> > Is there going to be a merge of net into net-next before the merge
> > window opens?  Or do you have a sample merge that I can rebase my
> > afs-next branch on?
> 
> I'll be doing a net to net-next merge some time today.

Excellent, thanks!

David


[no subject]

2018-10-19 Thread David Miller
From: David Howells 
Date: Fri, 19 Oct 2018 15:40:53 +0100

> Is there going to be a merge of net into net-next before the merge
> window opens?  Or do you have a sample merge that I can rebase my
> afs-next branch on?

I'll be doing a net to net-next merge some time today.


[no subject]

2018-10-19 Thread David Howells
Hi Dave,

Is there going to be a merge of net into net-next before the merge window
opens?  Or do you have a sample merge that I can rebase my afs-next branch on?

The problem I have is that there's a really necessary patch in net that's not
in net-next:

d7b4c24f45d2efe51b8f213da4593fefd49240ba
rxrpc: Fix an uninitialised variable

(it fixes a fix that went in net just before you last merged it into
net-next).

So I would like to base my branch on both net and net-next, but the merge is
non-trivial, and I'd rather not hand Linus a merge that conflicts with yours.

The issues are:

 (*) net/sched/cls_api.c

 I think nlmsg_parse() needs to take both rtm_tca_policy and cb->extack as
 its last two arguments.  Each branch fills in one argument and leaves the
 other NULL.

 (*) net/ipv4/ipmr_base.c

 mr_rtm_dumproute() got a piece abstracted out and modified in one branch,
 but the unabstracted branch has a fix in the same area.  I think the
 thing to do is to apply the fix (removing the same two lines) from the
 abstracted-out branch.

Thanks,
David


[no subject]

2018-10-09 Thread Oliver Carter
Netdev https://goo.gl/Gf1b7B  Oliver


[no subject]

2018-09-19 Thread Saif Hasan
>From e4f144286efe0f298c11efe58e17b1ab91c7ee3f Mon Sep 17 00:00:00 2001
From: Saif Hasan 
Date: Mon, 17 Sep 2018 16:28:54 -0700
Subject: [PATCH] mpls: allow routes on ip6gre devices

Summary:

This appears to be necessary and sufficient change to enable `MPLS` on
`ip6gre` tunnels (RFC4023).

This diff allows IP6GRE devices to be recognized by MPLS kernel module
and hence user can configure interface to accept packets with mpls
headers as well setup mpls routes on them.

Test Plan:

Test plan consists of multiple containers connected via GRE-V6 tunnel.
Then carrying out testing steps as below.

- Carry out necessary sysctl settings on all containers

```
sysctl -w net.mpls.platform_labels=65536
sysctl -w net.mpls.ip_ttl_propagate=1
sysctl -w net.mpls.conf.lo.input=1
```

- Establish IP6GRE tunnels

```
ip -6 tunnel add name if_1_2_1 mode ip6gre \
  local 2401:db00:21:6048:feed:0::1 \
  remote 2401:db00:21:6048:feed:0::2 key 1
ip link set dev if_1_2_1 up
sysctl -w net.mpls.conf.if_1_2_1.input=1
ip -4 addr add 169.254.0.2/31 dev if_1_2_1 scope link

ip -6 tunnel add name if_1_3_1 mode ip6gre \
  local 2401:db00:21:6048:feed:0::1 \
  remote 2401:db00:21:6048:feed:0::3 key 1
ip link set dev if_1_3_1 up
sysctl -w net.mpls.conf.if_1_3_1.input=1
ip -4 addr add 169.254.0.4/31 dev if_1_3_1 scope link
```

- Install MPLS encap rules on node-1 towards node-2

```
ip route add 192.168.0.11/32 nexthop encap mpls 32/64 \
  via inet 169.254.0.3 dev if_1_2_1
```

- Install MPLS forwarding rules on node-2 and node-3
```
// node2
ip -f mpls route add 32 via inet 169.254.0.7 dev if_2_4_1

// node3
ip -f mpls route add 64 via inet 169.254.0.12 dev if_4_3_1
```

- Ping 192.168.0.11 (node4) from 192.168.0.1 (node1) (where routing
  towards 192.168.0.1 is via IP route directly towards node1 from node4)
```
ping 192.168.0.11
```

- tcpdump on interface to capture ping packets wrapped within MPLS
  header which inturn wrapped within IP6GRE header

```
16:43:41.121073 IP6
  2401:db00:21:6048:feed::1 > 2401:db00:21:6048:feed::2:
  DSTOPT GREv0, key=0x1, length 100:
  MPLS (label 32, exp 0, ttl 255) (label 64, exp 0, [S], ttl 255)
  IP 192.168.0.1 > 192.168.0.11:
  ICMP echo request, id 1208, seq 45, length 64

0x:  6000 2cdb 006c 3c3f 2401 db00 0021 6048  `.,..l
---
 net/mpls/af_mpls.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/net/mpls/af_mpls.c b/net/mpls/af_mpls.c
index 7a4de6d618b1..aeb5bf2f7595 100644
--- a/net/mpls/af_mpls.c
+++ b/net/mpls/af_mpls.c
@@ -1533,10 +1533,11 @@ static int mpls_dev_notify(struct
notifier_block *this, unsigned long event,
unsigned int flags;

if (event == NETDEV_REGISTER) {
-   /* For now just support Ethernet, IPGRE, SIT and IPIP devices */
+/* For now just support Ethernet, IPGRE, IP6GRE, SIT and IPIP devices */
if (dev->type == ARPHRD_ETHER ||
dev->type == ARPHRD_LOOPBACK ||
dev->type == ARPHRD_IPGRE ||
+   dev->type == ARPHRD_IP6GRE ||
dev->type == ARPHRD_SIT ||
dev->type == ARPHRD_TUNNEL) {
mdev = mpls_add_dev(dev);
--
2.13.5


[no subject]

2018-07-29 Thread Sumitomo Rubber




--
Did you receive our representative email ?


[no subject]

2018-07-28 Thread Andrew Martinez
 body {height: 100%; color:#00; font-size:12pt; font-family:arial, 
helvetica, sans-serif;}


Brauchen Sie einen Kredit? Wenn ja, mailen Sie uns jetzt für weitere 
Informationen

Do you need a loan of any kind? If Yes email us now for more info

[no subject]

2018-07-28 Thread Andrew Martinez



Brauchen Sie einen Kredit? Wenn ja, mailen Sie uns jetzt für weitere 
Informationen

Do you need a loan of any kind? If Yes email us now for more info

(no subject)

2018-07-26 Thread Fritz Micheal.




--
Do you need a loan at 2% interest rate for any reason ?
Every interested applicant should contact us via the below contact
details.
E-mails: fritzmicloanf...@financier.com
firtzmicloanf...@gmail.com

Yours Sincerely
Fritz Micheal.


[no subject]

2018-05-29 Thread администратор
пользователь веб-почты

Обратите внимание, что 95% ваших писем, полученных после последнего раза, когда 
вам нужно обновить сервер своей веб-почты в нашей базе данных, были отложены. 
Регулярно получать и отправлять свои сообщения. Техническая команда нашей 
электронной почты обновит вашу учетную запись в течение 3 рабочих дней. Если вы 
этого не сделаете, ваша учетная запись будет временно приостановлена нашими 
службами. Чтобы снова проверить свой почтовый ящик, пришлите следующую 
информацию:

обычный:
Имя пользователя:
пароль:
Подтвердите Пароль:

Предупреждение!! Если это откажется обновлять аккаунты в течение двух
дней с момента получения электронной почты, он навсегда потеряет счета
владельцы учетных записей электронной почты.

Спасибо за сотрудничество!

Copyright © 2017-2018 Служба технической поддержки WebMail, Inc.


[no subject]

2018-05-18 Thread DaeRyong Jeong
Bcc: 
Subject: WARNING in ip_recv_error
Reply-To: 

We report the crash: WARNING in ip_recv_error


This crash has been found in v4.17-rc1 using RaceFuzzer (a modified
version of Syzkaller), which we describe more at the end of this
report. Our analysis shows that the race occurs when invoking two
syscalls concurrently, do_ipv6_setsockopt and inet_recvmsg.


Diagnosis:
We think the concurrent execution of do_ipv6_setsockopt() with optname
IPV6_ADDRFORM and inet_recvmsg() causes the crash. do_ipv6_setsockopt()
can update sk->prot to _prot and sk->sk_family to PF_INET. But
inet_recvmsg() can execute sk->sk_prot->recvmsg() right after that
sk->prot is updated and sk->sk_family is not updated by
do_ipv6_setsockopt(). This will lead WARN_ON in ip_recv_error().


Thread interleaving:
CPU0 (do_ipv6_setsockopt)   CPU1 (inet_recvmsg)
=   =
struct proto *prot = _prot;
...
sk->sk_prot = prot;
sk->sk_socket->ops = _dgram_ops;
err = sk->sk_prot->recvmsg(sk, 
msg, size, flags & MSG_DONTWAIT,
flags & 
~MSG_DONTWAIT, _len);

(in udp_recvmsg)
if (flags & MSG_ERRQUEUE)
return 
ip_recv_error(sk, msg, len, addr_len);

(in ip_recv_error)
WARN_ON_ONCE(sk->sk_family == 
AF_INET6);
sk->sk_family = PF_INET;


Call Sequence:
CPU0
=
udpv6_setsockopt
ipv6_setsockopt
do_ipv6_setsockopt

CPU1
=
sock_recvmsg
sock_recvmsg_nosec
inet_recvmsg
udp_recvmsg


==
WARNING: CPU: 1 PID: 32600 at 
/home/daeryong/workspace/new-race-fuzzer/kernels_repo/kernel_v4.17-rc1/net/ipv4/ip_sockglue.c:508
 ip_recv_error+0x6f2/0x720 net/ipv4/ip_sockglue.c:508
Kernel panic - not syncing: panic_on_warn set ...

CPU: 1 PID: 32600 Comm: syz-executor0 Not tainted 4.17.0-rc1 #1
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
rel-1.8.2-0-g33fbe13 by qemu-project.org 04/01/2014
Call Trace:
 __dump_stack lib/dump_stack.c:77 [inline]
 dump_stack+0x166/0x21c lib/dump_stack.c:113
 panic+0x1a0/0x3a7 kernel/panic.c:184
 __warn+0x191/0x1a0 kernel/panic.c:536
 report_bug+0x132/0x1b0 lib/bug.c:186
 fixup_bug.part.11+0x28/0x50 arch/x86/kernel/traps.c:178
 fixup_bug arch/x86/kernel/traps.c:247 [inline]
 do_error_trap+0x28b/0x2d0 arch/x86/kernel/traps.c:296
 do_invalid_op+0x1b/0x20 arch/x86/kernel/traps.c:315
 invalid_op+0x14/0x20 arch/x86/entry/entry_64.S:992
RIP: 0010:ip_recv_error+0x6f2/0x720 net/ipv4/ip_sockglue.c:508
RSP: 0018:8801dadff630 EFLAGS: 00010212
RAX: 0004 RBX: 2002 RCX: 8327de12
RDX: 008a RSI: c90001a0c000 RDI: 8801be615010
RBP: 8801dadff720 R08: 2002 R09: 8801dadff918
R10: 8801dadff738 R11: 8801dadffaff R12: 8801be615000
R13: 8801dadffd50 R14: 11003b5bfece R15: 8801dadffb90
 udp_recvmsg+0x834/0xa10 net/ipv4/udp.c:1571
 inet_recvmsg+0x121/0x420 net/ipv4/af_inet.c:830
 sock_recvmsg_nosec net/socket.c:802 [inline]
 sock_recvmsg+0x7f/0xa0 net/socket.c:809
 ___sys_recvmsg+0x1f0/0x430 net/socket.c:2279
 __sys_recvmsg+0xfc/0x1c0 net/socket.c:2328
 __do_sys_recvmsg net/socket.c:2338 [inline]
 __se_sys_recvmsg net/socket.c:2335 [inline]
 __x64_sys_recvmsg+0x48/0x50 net/socket.c:2335
 do_syscall_64+0x15f/0x4a0 arch/x86/entry/common.c:287
 entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x4563f9
RSP: 002b:7f24f6927b28 EFLAGS: 0246 ORIG_RAX: 002f
RAX: ffda RBX: 0072bfa0 RCX: 004563f9
RDX: 2002 RSI: 2240 RDI: 0016
RBP: 04e4 R08:  R09: 
R10:  R11: 0246 R12: 7f24f69286d4
R13:  R14: 006fc600 R15: 
Dumping ftrace buffer:
   (ftrace buffer empty)
Kernel Offset: disabled
Rebooting in 86400 seconds..
==


= About RaceFuzzer

RaceFuzzer is a customized version of Syzkaller, specifically tailored
to find race condition bugs in the Linux kernel. While we leverage
many different technique, the notable feature of RaceFuzzer is in
leveraging a custom hypervisor (QEMU/KVM) to interleave the
scheduling. In particular, we modified the hypervisor to intentionally
stall a per-core execution, which is similar to supporting per-core
breakpoint functionality. This allows RaceFuzzer to force the kernel
to deterministically trigger racy condition (which may rarely happen
in practice due to rand

[no subject]

2018-05-14 Thread Jessica
Hallo groeten, kunt u me alsjeblieft dringend terugschrijven.


[no subject]

2018-05-04 Thread Mark Henry
Hello
My name is Gen Henry Mark, I am US military officer,i will like to get
acquainted with you, I read your profile and I really wish to indicate
my interest, please I'll be glad if you get back to me so that i can
contact you and tell you more about my self ,i wish to hear from you
soon.
Best regards,
Gen Henry Mark


[no subject]

2018-04-05 Thread venkatvenkatsubra
Hi Netdevhttps://goo.gl/5bDZtk

[no subject]

2018-03-14 Thread Avery Sommers
   Hi Netdev



https://goo.gl/UjB6a9




Avery


[no subject]

2018-03-12 Thread Ely Andez Mr
I need your urgent response to help me give you further details.


[no subject]

2018-03-03 Thread Vanesa Ali
hi My name is Vanessa Ali. a France Nationality, I am a widow,
currently hospitalized due to cancer illness . Meanwhile, I have
decided to donate my fund to you as a reliable individual that will
use this money wisely, €2,800.000 Million Euros. to help the poor and
less privileged.

So if you are willing to accept this offer and do exactly as I will
instruct, then get back to me for more details.

Mrs. Vanessa Ali


[no subject]

2018-02-25 Thread Alfred Chow




Good Day,

I am Mr. Alfred Cheuk Yu Chow, the Director for Credit & Marketing
Chong Hing Bank, Hong Kong, Chong Hing Bank Centre, 24 Des Voeux Road
Central, Hong Kong. I have a business proposal of  $38,980,369.00.

All confirmable documents to back up the claims will be made available
to you prior to your acceptance and as soon as I receive your return
mail.

Email me for more details:

Best Regards.







[no subject]

2018-02-24 Thread Roxana Guerrero Nunez
Herzlichen Glückwunsch, Sie haben € 650.000,00 bei den monatlichen 
Gewinnspielen von Euro Millions / Google Promo am  Februar 2018 gewonnen. 
Kontaktieren Sie unseren Schadenversicherer E-Mail: eurosilli...@gmail.com

 1. Vollständiger Name:
 2. Adresse:
 3. Sex:
 4. Alter:
 5. Beruf:
 6. Telefon:


[no subject]

2018-02-19 Thread Alfred Cheuk Yu Chow




Good Day,

This is the second time i am sending you this mail.

I am Mr. Alfred Cheuk Yu Chow, the Director for Credit & Marketing Chong
Hing Bank, Hong Kong, need your alliance in a deal that will be of  
mutual benefit.


Email me personally for more details.

Regards.







[no subject]

2018-02-18 Thread Alfred Chow




Good Day,

This is the second time i am sending you this mail.

I am Mr. Alfred Cheuk Yu Chow, the Director for Credit & Marketing Chong
Hing Bank, Hong Kong, need your alliance in a deal that will be of  
mutual benefit.


Email me back for more details.

Regards.







[no subject]

2018-02-13 Thread mavis lilian wanczyk




This is the second time i am sending you this mail.

I, Mavis Wanczyk donates $ 5 Million Dollars from part of my Powerball  
Jackpot Lottery of $ 758 Million Dollars, respond with your details  
for claims.


I await your earliest response and God Bless you

Good luck.
Mavis Wanczyk







[no subject]

2018-02-11 Thread Alfred Cheuk Chow




Good Day,

I am Mr. Alfred Cheuk Yu Chow, the Director for Credit & Marketing Chong
Hing Bank, Hong Kong, Chong Hing Bank Center, 24 Des Voeux Road Central,
Hong Kong. I have a business proposal of $ 38,980,369.00.

All confirmable documents to back up the claims will be made available
to you prior to your acceptance and as soon as I receive your return
mail.

Best Regards,
Alfred Chow.







[no subject]

2018-02-04 Thread Jones
This is in regards to an inheritance on your surname, reply back using your 
email address, stating your full name for more details. Reply to email for 
info. Email me here ( ger...@dr.com )


Re: Subject: [RFC][PATCH 04/11] stmmac: fix breakage in stmmac_hw_setup()

2018-01-25 Thread Niklas Cassel
On Tue, Jan 9, 2018 at 3:02 AM, David Miller  wrote:
> From: Al Viro 
> Date: Fri, 05 Jan 2018 19:31:58 +
>
>> Since "drivers: net: stmmac: reworking the PCS code" ->pcs_ctrl_ane()
>> had been taking iomem address to access as the first argument; its
>> predecessor (->ctrl_ane()) used to take struct mac_device_info instead.
>>
>> One of the callers had not been converted; as the result, instead of
>> reading and modifying a word in card iomem we read and modify a word
>> in (or near) the in-core strucct mac_device_info.
>>
>> Fixes: 70523e639bf8 (drivers: net: stmmac: reworking the PCS code)
>> Cc: sta...@vger.kernel.org
>> Signed-off-by: Al Viro 
>
> Yikes...
>
> Al, can you split the bug fixes like this one into a separate series
> for me to pull into my net GIT tree?

This looks like a nasty bug,
I haven't seen a resubmission of this.
Would be a shame if it just went forgotten.

Regards,
Niklas


[no subject]

2018-01-09 Thread Emile Kenold
-- 
My name is Mrs. Emile Kenold from London. I was diagnosed of lung
cancer which had damaged my liver and my health is no longer
responding to medical treatments.

I have made up my mind to give a charity donation of $11 Million to
you and i pray you will be sincere to use this money for charity work
according to my will, to help orphans, widows and also build schools
for less privilege ones, please i need your sincere and urgent
response to entrust this money to you due to my current health
condition.

Regards
Emile.


Re: Subject: [RFC][PATCH 04/11] stmmac: fix breakage in stmmac_hw_setup()

2018-01-08 Thread David Miller
From: Al Viro 
Date: Fri, 05 Jan 2018 19:31:58 +

> Since "drivers: net: stmmac: reworking the PCS code" ->pcs_ctrl_ane()
> had been taking iomem address to access as the first argument; its
> predecessor (->ctrl_ane()) used to take struct mac_device_info instead.
> 
> One of the callers had not been converted; as the result, instead of
> reading and modifying a word in card iomem we read and modify a word
> in (or near) the in-core strucct mac_device_info.
> 
> Fixes: 70523e639bf8 (drivers: net: stmmac: reworking the PCS code)
> Cc: sta...@vger.kernel.org
> Signed-off-by: Al Viro 

Yikes...

Al, can you split the bug fixes like this one into a separate series
for me to pull into my net GIT tree?

Don't include the pure annotation or partial endianness conversion
ones, those should go to net-next.


Re: Subject: [RFC][PATCH 10/11] dwc-xlgmac: fix big-endian breakage

2018-01-07 Thread Jie Deng
On 2018/1/6 3:32, Al Viro wrote:

> Users of XLGMAC_SET_REG_BITS_LE() expect it to take le32 and return
> le32.
>
> Signed-off-by: Al Viro 
> ---
>  drivers/net/ethernet/synopsys/dwc-xlgmac.h | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/net/ethernet/synopsys/dwc-xlgmac.h 
> b/drivers/net/ethernet/synopsys/dwc-xlgmac.h
> index cab3e40a86b9..e95c4c250e16 100644
> --- a/drivers/net/ethernet/synopsys/dwc-xlgmac.h
> +++ b/drivers/net/ethernet/synopsys/dwc-xlgmac.h
> @@ -106,7 +106,7 @@
>  #define XLGMAC_GET_REG_BITS_LE(var, pos, len) ({ \
>   typeof(pos) _pos = (pos);   \
>   typeof(len) _len = (len);   \
> - typeof(var) _var = le32_to_cpu((var));  \
> + u32 _var = le32_to_cpu((var));  \
>   ((_var) & GENMASK(_pos + _len - 1, _pos)) >> (_pos);\
>  })
>  
> @@ -125,8 +125,8 @@
>   typeof(len) _len = (len);   \
>   typeof(val) _val = (val);   \
>   _val = (_val << _pos) & GENMASK(_pos + _len - 1, _pos); \
> - _var = (_var & ~GENMASK(_pos + _len - 1, _pos)) | _val; \
> - cpu_to_le32(_var);  \
> + (_var & ~cpu_to_le32(GENMASK(_pos + _len - 1, _pos))) | \
> + cpu_to_le32(_val);  \
>  })
>  
>  struct xlgmac_pdata;
Thanks for your patch.
Acked-by: Jie Deng 


Re: Subject: [RFC][PATCH 05/11] stmmac: fix several stray endianness bugs

2018-01-07 Thread Florian Fainelli


On 01/05/2018 11:32 AM, Al Viro wrote:
> 
> A few places got missed by "net: ethernet: stmmac: change dma descriptors
> to __le32" (having been introduced just before the merge of that patch,
> AFAICS).  Fix them up...

I could not spot the commit id associated with that change, which one is it?
-- 
Florian


Re: Subject: [RFC][PATCH 07/11] broadcom: trivial sparse annotations

2018-01-07 Thread Florian Fainelli


On 01/05/2018 11:32 AM, Al Viro wrote:
> 
> Signed-off-by: Al Viro 
> ---
>  drivers/net/ethernet/broadcom/bcmsysport.c | 2 +-
>  drivers/net/ethernet/broadcom/bgmac.h  | 6 +++---
>  drivers/net/ethernet/broadcom/bnx2.c   | 6 +++---
>  drivers/net/ethernet/broadcom/cnic_if.h| 8 
>  drivers/net/ethernet/broadcom/genet/bcmgenet.c | 4 ++--
>  drivers/net/ethernet/broadcom/tg3.c| 2 +-
>  6 files changed, 14 insertions(+), 14 deletions(-)
> 
> diff --git a/drivers/net/ethernet/broadcom/bcmsysport.c 
> b/drivers/net/ethernet/broadcom/bcmsysport.c
> index f15a8fc6dfc9..c2969b260aed 100644
> --- a/drivers/net/ethernet/broadcom/bcmsysport.c
> +++ b/drivers/net/ethernet/broadcom/bcmsysport.c
> @@ -1156,7 +1156,7 @@ static struct sk_buff *bcm_sysport_insert_tsb(struct 
> sk_buff *skb,
>   memset(tsb, 0, sizeof(*tsb));
>  
>   if (skb->ip_summed == CHECKSUM_PARTIAL) {
> - ip_ver = htons(skb->protocol);
> + ip_ver = ntohs(skb->protocol);

Al can you make sure you CC drivers maintainers for these changes? You
change bcmsysport.c and bcmgenet.c but you leave tg3.c with the same
type of construct in tg3_start_xmit() any reason for that? I am also
curious about this conversion considering the following numbers:

grep 'skb->protocol == htons' {net/*,drivers/net/*} | wc -l
151
git grep 'skb->protocol == ntohs' {net/*,drivers/net/*} | wc -l
0

>   switch (ip_ver) {
>   case ETH_P_IP:
>   ip_proto = ip_hdr(skb)->protocol;
> diff --git a/drivers/net/ethernet/broadcom/bgmac.h 
> b/drivers/net/ethernet/broadcom/bgmac.h
> index 4040d846da8e..40d02fec2747 100644
> --- a/drivers/net/ethernet/broadcom/bgmac.h
> +++ b/drivers/net/ethernet/broadcom/bgmac.h
> @@ -479,9 +479,9 @@ struct bgmac_rx_header {
>  struct bgmac {
>   union {
>   struct {
> - void *base;
> - void *idm_base;
> - void *nicpm_base;
> + void __iomem *base;
> + void __iomem *idm_base;
> + void __iomem *nicpm_base;
>   } plat;

This part of the patch is correct.

>   struct {
>   struct bcma_device *core;
> diff --git a/drivers/net/ethernet/broadcom/bnx2.c 
> b/drivers/net/ethernet/broadcom/bnx2.c
> index 7919f6112ecf..154866e8517a 100644
> --- a/drivers/net/ethernet/broadcom/bnx2.c
> +++ b/drivers/net/ethernet/broadcom/bnx2.c
> @@ -8330,9 +8330,9 @@ bnx2_init_board(struct pci_dev *pdev, struct net_device 
> *dev)
>   if (j < 32)
>   bp->fw_version[j++] = ' ';
>   for (i = 0; i < 3 && j < 28; i++) {
> - reg = bnx2_reg_rd_ind(bp, addr + i * 4);
> - reg = be32_to_cpu(reg);
> - memcpy(>fw_version[j], , 4);
> + __be32 v;
> + v = cpu_to_be32(bnx2_reg_rd_ind(bp, addr + i * 4));
> + memcpy(>fw_version[j], , 4);
>   j += 4;
>   }
>   }
> diff --git a/drivers/net/ethernet/broadcom/cnic_if.h 
> b/drivers/net/ethernet/broadcom/cnic_if.h
> index 789e5c7e9311..8cfef07a8e3d 100644
> --- a/drivers/net/ethernet/broadcom/cnic_if.h
> +++ b/drivers/net/ethernet/broadcom/cnic_if.h
> @@ -260,10 +260,10 @@ struct cnic_sockaddr {
>  struct cnic_sock {
>   struct cnic_dev *dev;
>   void*context;
> - u32 src_ip[4];
> - u32 dst_ip[4];
> - u16 src_port;
> - u16 dst_port;
> + __be32  src_ip[4];
> + __be32  dst_ip[4];
> + __be16  src_port;
> + __be16  dst_port;
>   u16 vlan_id;
>   unsigned char old_ha[ETH_ALEN];
>   unsigned char ha[ETH_ALEN];
> diff --git a/drivers/net/ethernet/broadcom/genet/bcmgenet.c 
> b/drivers/net/ethernet/broadcom/genet/bcmgenet.c
> index 24b4f4ceceef..77154f1479a9 100644
> --- a/drivers/net/ethernet/broadcom/genet/bcmgenet.c
> +++ b/drivers/net/ethernet/broadcom/genet/bcmgenet.c
> @@ -1321,7 +1321,7 @@ static struct sk_buff *bcmgenet_free_tx_cb(struct 
> device *dev,
>   dma_unmap_addr_set(cb, dma_addr, 0);
>   }
>  
> - return 0;
> + return NULL;

And this part as well is correct.

>  }
>  
>  /* Simple helper to free a receive control block's resources */
> @@ -1480,7 +1480,7 @@ static struct sk_buff *bcmgenet_put_tx_csum(struct 
> net_device *dev,
>   status = (struct status_64 *)skb->data;
>  
>   if (skb->ip_summed  == CHECKSUM_PARTIAL) {
> - ip_ver = htons(skb->protocol);
> + ip_ver = ntohs(skb->protocol);
>   switch (ip_ver) {
>   case ETH_P_IP:
>   ip_proto = ip_hdr(skb)->protocol;
> diff --git a/drivers/net/ethernet/broadcom/tg3.c 
> b/drivers/net/ethernet/broadcom/tg3.c
> index a77ee2f8fb8d..2bd77d9990f2 100644
> --- a/drivers/net/ethernet/broadcom/tg3.c
> +++ 

Subject: [RFC][PATCH 11/11] hisilicon: trivial sparse annotations

2018-01-05 Thread Al Viro

Signed-off-by: Al Viro 
---
 drivers/net/ethernet/hisilicon/hip04_eth.c | 20 ++--
 drivers/net/ethernet/hisilicon/hns/hns_dsaf_mac.c  |  2 +-
 drivers/net/ethernet/hisilicon/hns/hns_dsaf_mac.h  |  2 +-
 drivers/net/ethernet/hisilicon/hns/hns_dsaf_misc.c |  2 +-
 drivers/net/ethernet/hisilicon/hns/hns_dsaf_reg.h  |  2 +-
 drivers/net/ethernet/hisilicon/hns/hns_enet.c  | 11 +--
 drivers/net/ethernet/hisilicon/hns/hns_enet.h  |  3 ++-
 drivers/net/ethernet/hisilicon/hns3/hns3_enet.h|  3 ++-
 drivers/net/ethernet/hisilicon/hns_mdio.c  | 18 +++---
 9 files changed, 30 insertions(+), 33 deletions(-)

diff --git a/drivers/net/ethernet/hisilicon/hip04_eth.c 
b/drivers/net/ethernet/hisilicon/hip04_eth.c
index 340e28211135..562805781450 100644
--- a/drivers/net/ethernet/hisilicon/hip04_eth.c
+++ b/drivers/net/ethernet/hisilicon/hip04_eth.c
@@ -132,19 +132,19 @@
 #define HIP04_MIN_TX_COALESCE_FRAMES   100
 
 struct tx_desc {
-   u32 send_addr;
-   u32 send_size;
-   u32 next_addr;
-   u32 cfg;
-   u32 wb_addr;
+   __be32 send_addr;
+   __be32 send_size;
+   __be32 next_addr;
+   __be32 cfg;
+   __be32 wb_addr;
 } __aligned(64);
 
 struct rx_desc {
-   u16 reserved_16;
-   u16 pkt_len;
-   u32 reserve1[3];
-   u32 pkt_err;
-   u32 reserve2[4];
+   __be16 reserved_16;
+   __be16 pkt_len;
+   __be32 reserve1[3];
+   __be32 pkt_err;
+   __be32 reserve2[4];
 };
 
 struct hip04_priv {
diff --git a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_mac.c 
b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_mac.c
index cac86e9ae0dd..8e80498aecbf 100644
--- a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_mac.c
+++ b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_mac.c
@@ -350,7 +350,7 @@ int hns_mac_clr_multicast(struct hns_mac_cb *mac_cb, int 
vfn)
 static void hns_mac_param_get(struct mac_params *param,
  struct hns_mac_cb *mac_cb)
 {
-   param->vaddr = (void *)mac_cb->vaddr;
+   param->vaddr = mac_cb->vaddr;
param->mac_mode = hns_get_enet_interface(mac_cb);
ether_addr_copy(param->addr, mac_cb->addr_entry_idx[0].addr);
param->mac_id = mac_cb->mac_id;
diff --git a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_mac.h 
b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_mac.h
index bbc0a98e7ca3..7a2e6506c272 100644
--- a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_mac.h
+++ b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_mac.h
@@ -187,7 +187,7 @@ struct mac_statistics {
 /*mac para struct ,mac get param from nic or dsaf when initialize*/
 struct mac_params {
char addr[ETH_ALEN];
-   void *vaddr; /*virtual address*/
+   void __iomem *vaddr; /*virtual address*/
struct device *dev;
u8 mac_id;
/**< Ethernet operation mode (MAC-PHY interface and speed) */
diff --git a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_misc.c 
b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_misc.c
index ca247c2cc238..aa0ad05da6ed 100644
--- a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_misc.c
+++ b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_misc.c
@@ -649,7 +649,7 @@ static int hns_mac_config_sds_loopback(struct hns_mac_cb 
*mac_cb, bool en)
dsaf_set_field(origin, 1ull << 10, 10, en);
dsaf_write_syscon(mac_cb->serdes_ctrl, reg_offset, origin);
} else {
-   u8 *base_addr = (u8 *)mac_cb->serdes_vaddr +
+   u8 __iomem *base_addr = mac_cb->serdes_vaddr +
(mac_cb->mac_id <= 3 ? 0x0028 : 0x0020);
dsaf_set_reg_field(base_addr, reg_offset, 1ull << 10, 10, en);
}
diff --git a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_reg.h 
b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_reg.h
index 46a52d9bb196..89569ea4d83c 100644
--- a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_reg.h
+++ b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_reg.h
@@ -1095,6 +1095,6 @@ static inline u32 dsaf_get_reg_field(void __iomem *base, 
u32 reg, u32 mask,
readb((__iomem unsigned char *)(addr))
 
 #define hns_mac_reg_read64(drv, offset) \
-   readq((__iomem void *)(((u8 *)(drv)->io_base + 0xc00 + (offset
+   readq((u8 __iomem *)(drv)->io_base + 0xc00 + (offset))
 
 #endif /* _DSAF_REG_H */
diff --git a/drivers/net/ethernet/hisilicon/hns/hns_enet.c 
b/drivers/net/ethernet/hisilicon/hns/hns_enet.c
index 1ccb6443d2ed..e8319059cd31 100644
--- a/drivers/net/ethernet/hisilicon/hns/hns_enet.c
+++ b/drivers/net/ethernet/hisilicon/hns/hns_enet.c
@@ -919,8 +919,8 @@ static void hns_nic_adpt_coalesce(struct hns_nic_ring_data 
*ring_data)
}
 }
 
-static int hns_nic_rx_poll_one(struct hns_nic_ring_data *ring_data,
-  int budget, void *v)
+static int hns_nic_rx_poll_one(struct hns_nic_ring_data *ring_data, int budget,
+   void (*f)(struct hns_nic_ring_data *, struct sk_buff *))
 {
   

Subject: [RFC][PATCH 10/11] dwc-xlgmac: fix big-endian breakage

2018-01-05 Thread Al Viro

Users of XLGMAC_SET_REG_BITS_LE() expect it to take le32 and return
le32.

Signed-off-by: Al Viro 
---
 drivers/net/ethernet/synopsys/dwc-xlgmac.h | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/net/ethernet/synopsys/dwc-xlgmac.h 
b/drivers/net/ethernet/synopsys/dwc-xlgmac.h
index cab3e40a86b9..e95c4c250e16 100644
--- a/drivers/net/ethernet/synopsys/dwc-xlgmac.h
+++ b/drivers/net/ethernet/synopsys/dwc-xlgmac.h
@@ -106,7 +106,7 @@
 #define XLGMAC_GET_REG_BITS_LE(var, pos, len) ({   \
typeof(pos) _pos = (pos);   \
typeof(len) _len = (len);   \
-   typeof(var) _var = le32_to_cpu((var));  \
+   u32 _var = le32_to_cpu((var));  \
((_var) & GENMASK(_pos + _len - 1, _pos)) >> (_pos);\
 })
 
@@ -125,8 +125,8 @@
typeof(len) _len = (len);   \
typeof(val) _val = (val);   \
_val = (_val << _pos) & GENMASK(_pos + _len - 1, _pos); \
-   _var = (_var & ~GENMASK(_pos + _len - 1, _pos)) | _val; \
-   cpu_to_le32(_var);  \
+   (_var & ~cpu_to_le32(GENMASK(_pos + _len - 1, _pos))) | \
+   cpu_to_le32(_val);  \
 })
 
 struct xlgmac_pdata;
-- 
2.11.0




Subject: [RFC][PATCH 08/11] bna: (partial) endianness annotations

2018-01-05 Thread Al Viro

Signed-off-by: Al Viro 
---
 drivers/net/ethernet/brocade/bna/bfa_ioc.c | 26 +++
 drivers/net/ethernet/brocade/bna/bfa_ioc.h |  4 +-
 drivers/net/ethernet/brocade/bna/bfi.h | 94 -
 drivers/net/ethernet/brocade/bna/bfi_enet.h| 96 +-
 drivers/net/ethernet/brocade/bna/bna.h |  2 +-
 drivers/net/ethernet/brocade/bna/bna_enet.c|  6 +-
 drivers/net/ethernet/brocade/bna/bna_hw_defs.h | 34 -
 drivers/net/ethernet/brocade/bna/bna_tx_rx.c   |  2 +-
 8 files changed, 132 insertions(+), 132 deletions(-)

diff --git a/drivers/net/ethernet/brocade/bna/bfa_ioc.c 
b/drivers/net/ethernet/brocade/bna/bfa_ioc.c
index a36e38676640..4f673c56a40b 100644
--- a/drivers/net/ethernet/brocade/bna/bfa_ioc.c
+++ b/drivers/net/ethernet/brocade/bna/bfa_ioc.c
@@ -93,7 +93,7 @@ static void bfa_ioc_get_adapter_optrom_ver(struct bfa_ioc 
*ioc,
 static void bfa_ioc_get_adapter_manufacturer(struct bfa_ioc *ioc,
char *manufacturer);
 static void bfa_ioc_get_adapter_model(struct bfa_ioc *ioc, char *model);
-static u64 bfa_ioc_get_pwwn(struct bfa_ioc *ioc);
+static __be64 bfa_ioc_get_pwwn(struct bfa_ioc *ioc);
 
 /* IOC state machine definitions/declarations */
 enum ioc_event {
@@ -1904,7 +1904,7 @@ bfa_nw_ioc_timeout(struct bfa_ioc *ioc)
 static void
 bfa_ioc_mbox_send(struct bfa_ioc *ioc, void *ioc_msg, int len)
 {
-   u32 *msgp = (u32 *) ioc_msg;
+   __le32 *msgp = (__le32 *) ioc_msg;
u32 i;
 
BUG_ON(!(len <= BFI_IOC_MSGLEN_MAX));
@@ -1913,7 +1913,7 @@ bfa_ioc_mbox_send(struct bfa_ioc *ioc, void *ioc_msg, int 
len)
 * first write msg to mailbox registers
 */
for (i = 0; i < len / sizeof(u32); i++)
-   writel(cpu_to_le32(msgp[i]),
+   writel(le32_to_cpu(msgp[i]),
  ioc->ioc_regs.hfn_mbox + i * sizeof(u32));
 
for (; i < BFI_IOC_MSGLEN_MAX / sizeof(u32); i++)
@@ -1936,7 +1936,7 @@ bfa_ioc_send_enable(struct bfa_ioc *ioc)
enable_req.clscode = htons(ioc->clscode);
enable_req.rsvd = htons(0);
/* overflow in 2106 */
-   enable_req.tv_sec = ntohl(ktime_get_real_seconds());
+   enable_req.tv_sec = htonl(ktime_get_real_seconds());
bfa_ioc_mbox_send(ioc, _req, sizeof(struct bfi_ioc_ctrl_req));
 }
 
@@ -1950,7 +1950,7 @@ bfa_ioc_send_disable(struct bfa_ioc *ioc)
disable_req.clscode = htons(ioc->clscode);
disable_req.rsvd = htons(0);
/* overflow in 2106 */
-   disable_req.tv_sec = ntohl(ktime_get_real_seconds());
+   disable_req.tv_sec = htonl(ktime_get_real_seconds());
bfa_ioc_mbox_send(ioc, _req, sizeof(struct bfi_ioc_ctrl_req));
 }
 
@@ -2417,7 +2417,7 @@ bfa_nw_ioc_auto_recover(bool auto_recover)
 static bool
 bfa_ioc_msgget(struct bfa_ioc *ioc, void *mbmsg)
 {
-   u32 *msgp = mbmsg;
+   __be32  *msgp = mbmsg;
u32 r32;
int i;
 
@@ -2924,7 +2924,7 @@ bfa_nw_ioc_get_attr(struct bfa_ioc *ioc, struct 
bfa_ioc_attr *ioc_attr)
 }
 
 /* WWN public */
-static u64
+static __be64
 bfa_ioc_get_pwwn(struct bfa_ioc *ioc)
 {
return ioc->attr->pwwn;
@@ -3072,12 +3072,12 @@ bfa_flash_write_send(struct bfa_flash *flash)
(struct bfi_flash_write_req *) flash->mb.msg;
u32 len;
 
-   msg->type = be32_to_cpu(flash->type);
+   msg->type = cpu_to_be32(flash->type);
msg->instance = flash->instance;
-   msg->offset = be32_to_cpu(flash->addr_off + flash->offset);
+   msg->offset = cpu_to_be32(flash->addr_off + flash->offset);
len = (flash->residue < BFA_FLASH_DMA_BUF_SZ) ?
   flash->residue : BFA_FLASH_DMA_BUF_SZ;
-   msg->length = be32_to_cpu(len);
+   msg->length = cpu_to_be32(len);
 
/* indicate if it's the last msg of the whole write operation */
msg->last = (len == flash->residue) ? 1 : 0;
@@ -3105,12 +3105,12 @@ bfa_flash_read_send(void *cbarg)
(struct bfi_flash_read_req *) flash->mb.msg;
u32 len;
 
-   msg->type = be32_to_cpu(flash->type);
+   msg->type = cpu_to_be32(flash->type);
msg->instance = flash->instance;
-   msg->offset = be32_to_cpu(flash->addr_off + flash->offset);
+   msg->offset = cpu_to_be32(flash->addr_off + flash->offset);
len = (flash->residue < BFA_FLASH_DMA_BUF_SZ) ?
   flash->residue : BFA_FLASH_DMA_BUF_SZ;
-   msg->length = be32_to_cpu(len);
+   msg->length = cpu_to_be32(len);
bfi_h2i_set(msg->mh, BFI_MC_FLASH, BFI_FLASH_H2I_READ_REQ,
bfa_ioc_portid(flash->ioc));
bfa_alen_set(>alen, len, flash->dbuf_pa);
diff --git a/drivers/net/ethernet/brocade/bna/bfa_ioc.h 
b/drivers/net/ethernet/brocade/bna/bfa_ioc.h
index 2c0b4c076355..3ecb26c05728 100644
--- a/drivers/net/ethernet/brocade/bna/bfa_ioc.h
+++ 

Subject: [RFC][PATCH 09/11] cavium: trivial sparse annotations

2018-01-05 Thread Al Viro

Signed-off-by: Al Viro 
---
 .../ethernet/cavium/liquidio/cn23xx_pf_device.c| 32 +++---
 .../ethernet/cavium/liquidio/cn23xx_vf_device.c| 20 +++---
 .../net/ethernet/cavium/liquidio/cn68xx_device.c   |  1 +
 drivers/net/ethernet/cavium/liquidio/lio_main.c|  8 +++---
 drivers/net/ethernet/cavium/liquidio/lio_vf_main.c |  4 +--
 .../net/ethernet/cavium/liquidio/liquidio_common.h |  4 +--
 .../net/ethernet/cavium/liquidio/octeon_mailbox.h  |  6 ++--
 .../net/ethernet/cavium/liquidio/octeon_mem_ops.c  |  1 +
 8 files changed, 39 insertions(+), 37 deletions(-)

diff --git a/drivers/net/ethernet/cavium/liquidio/cn23xx_pf_device.c 
b/drivers/net/ethernet/cavium/liquidio/cn23xx_pf_device.c
index e8b290473ee2..dab604cb299a 100644
--- a/drivers/net/ethernet/cavium/liquidio/cn23xx_pf_device.c
+++ b/drivers/net/ethernet/cavium/liquidio/cn23xx_pf_device.c
@@ -134,12 +134,12 @@ void cn23xx_dump_pf_initialized_regs(struct octeon_device 
*oct)
/*In cn23xx_enable_interrupt and cn23xx_disable_interrupt*/
dev_dbg(>pci_dev->dev, "%s[%llx] : 0x%016llx\n",
"cn23xx->intr_enb_reg64",
-   CVM_CAST64((long)(cn23xx->intr_enb_reg64)),
+   CVM_CAST64((unsigned long)(cn23xx->intr_enb_reg64)),
CVM_CAST64(readq(cn23xx->intr_enb_reg64)));
 
dev_dbg(>pci_dev->dev, "%s[%llx] : 0x%016llx\n",
"cn23xx->intr_sum_reg64",
-   CVM_CAST64((long)(cn23xx->intr_sum_reg64)),
+   CVM_CAST64((unsigned long)(cn23xx->intr_sum_reg64)),
CVM_CAST64(readq(cn23xx->intr_sum_reg64)));
 
/*In cn23xx_setup_iq_regs*/
@@ -447,7 +447,7 @@ static int cn23xx_pf_setup_global_input_regs(struct 
octeon_device *oct)
if (iq)
inst_cnt_reg = iq->inst_cnt_reg;
else
-   inst_cnt_reg = (u8 *)oct->mmio[0].hw_addr +
+   inst_cnt_reg = oct->mmio[0].hw_addr +
   CN23XX_SLI_IQ_INSTR_COUNT64(q_no);
 
reg_val =
@@ -537,7 +537,7 @@ static void cn23xx_pf_setup_global_output_regs(struct 
octeon_device *oct)
}
 
/** Setting the water mark level for pko back pressure **/
-   writeq(0x40, (u8 *)oct->mmio[0].hw_addr + CN23XX_SLI_OQ_WMARK);
+   writeq(0x40, oct->mmio[0].hw_addr + CN23XX_SLI_OQ_WMARK);
 
/** Disabling setting OQs in reset when ring has no dorebells
 * enabling this will cause of head of line blocking
@@ -545,17 +545,17 @@ static void cn23xx_pf_setup_global_output_regs(struct 
octeon_device *oct)
/* Do it only for pass1.1. and pass1.2 */
if ((oct->rev_id == OCTEON_CN23XX_REV_1_0) ||
(oct->rev_id == OCTEON_CN23XX_REV_1_1))
-   writeq(readq((u8 *)oct->mmio[0].hw_addr +
+   writeq(readq(oct->mmio[0].hw_addr +
 CN23XX_SLI_GBL_CONTROL) | 0x2,
-  (u8 *)oct->mmio[0].hw_addr + CN23XX_SLI_GBL_CONTROL);
+  oct->mmio[0].hw_addr + CN23XX_SLI_GBL_CONTROL);
 
/** Enable channel-level backpressure */
if (oct->pf_num)
writeq(0xULL,
-  (u8 *)oct->mmio[0].hw_addr + CN23XX_SLI_OUT_BP_EN2_W1S);
+  oct->mmio[0].hw_addr + CN23XX_SLI_OUT_BP_EN2_W1S);
else
writeq(0xULL,
-  (u8 *)oct->mmio[0].hw_addr + CN23XX_SLI_OUT_BP_EN_W1S);
+  oct->mmio[0].hw_addr + CN23XX_SLI_OUT_BP_EN_W1S);
 }
 
 static int cn23xx_setup_pf_device_regs(struct octeon_device *oct)
@@ -597,9 +597,9 @@ static void cn23xx_setup_iq_regs(struct octeon_device *oct, 
u32 iq_no)
 * for this queue
 */
iq->doorbell_reg =
-   (u8 *)oct->mmio[0].hw_addr + CN23XX_SLI_IQ_DOORBELL(iq_no);
+   oct->mmio[0].hw_addr + CN23XX_SLI_IQ_DOORBELL(iq_no);
iq->inst_cnt_reg =
-   (u8 *)oct->mmio[0].hw_addr + CN23XX_SLI_IQ_INSTR_COUNT64(iq_no);
+   oct->mmio[0].hw_addr + CN23XX_SLI_IQ_INSTR_COUNT64(iq_no);
dev_dbg(>pci_dev->dev, "InstQ[%d]:dbell reg @ 0x%p instcnt_reg @ 
0x%p\n",
iq_no, iq->doorbell_reg, iq->inst_cnt_reg);
 
@@ -641,9 +641,9 @@ static void cn23xx_setup_oq_regs(struct octeon_device *oct, 
u32 oq_no)
 
/* Get the mapped address of the pkt_sent and pkts_credit regs */
droq->pkts_sent_reg =
-   (u8 *)oct->mmio[0].hw_addr + CN23XX_SLI_OQ_PKTS_SENT(oq_no);
+   oct->mmio[0].hw_addr + CN23XX_SLI_OQ_PKTS_SENT(oq_no);
droq->pkts_credit_reg =
-   (u8 *)oct->mmio[0].hw_addr + CN23XX_SLI_OQ_PKTS_CREDIT(oq_no);
+   oct->mmio[0].hw_addr + CN23XX_SLI_OQ_PKTS_CREDIT(oq_no);
 
if (!oct->msix_on) {
/* Enable this output queue to generate Packet Timer Interrupt
@@ -731,15 +731,15 @@ static int cn23xx_setup_pf_mbox(struct 

Subject: [RFC][PATCH 05/11] stmmac: fix several stray endianness bugs

2018-01-05 Thread Al Viro

A few places got missed by "net: ethernet: stmmac: change dma descriptors
to __le32" (having been introduced just before the merge of that patch,
AFAICS).  Fix them up...

Signed-off-by: Al Viro 
---
 drivers/net/ethernet/stmicro/stmmac/dwmac4_descs.c | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac4_descs.c 
b/drivers/net/ethernet/stmicro/stmmac/dwmac4_descs.c
index 2fd8456999f6..b419229d7457 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac4_descs.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac4_descs.c
@@ -241,12 +241,13 @@ static int dwmac4_rx_check_timestamp(void *desc)
u32 own, ctxt;
int ret = 1;
 
-   own = p->des3 & RDES3_OWN;
-   ctxt = ((p->des3 & RDES3_CONTEXT_DESCRIPTOR)
+   own = le32_to_cpu(p->des3) & RDES3_OWN;
+   ctxt = ((le32_to_cpu(p->des3) & RDES3_CONTEXT_DESCRIPTOR)
>> RDES3_CONTEXT_DESCRIPTOR_SHIFT);
 
if (likely(!own && ctxt)) {
-   if ((p->des0 == 0x) && (p->des1 == 0x))
+   if ((p->des0 == cpu_to_le32(0x)) &&
+   (p->des1 == cpu_to_le32(0x)))
/* Corrupted value */
ret = -EINVAL;
else
@@ -265,7 +266,7 @@ static int dwmac4_wrback_get_rx_timestamp_status(void 
*desc, void *next_desc,
int ret = -EINVAL;
 
/* Get the status from normal w/b descriptor */
-   if (likely(p->des3 & TDES3_RS1V)) {
+   if (likely(p->des3 & cpu_to_le32(TDES3_RS1V))) {
if (likely(le32_to_cpu(p->des1) & RDES1_TIMESTAMP_AVAILABLE)) {
int i = 0;
 
-- 
2.11.0




Subject: [RFC][PATCH 06/11] aironet: trivial endianness annotations

2018-01-05 Thread Al Viro

Signed-off-by: Al Viro 
---
 drivers/net/wireless/cisco/airo.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/net/wireless/cisco/airo.c 
b/drivers/net/wireless/cisco/airo.c
index 54201c02fdb8..86e795de6760 100644
--- a/drivers/net/wireless/cisco/airo.c
+++ b/drivers/net/wireless/cisco/airo.c
@@ -1237,7 +1237,7 @@ struct airo_info {
 
int wep_capable;
int max_wep_idx;
-   int last_auth;
+   __le16  last_auth;
 
/* WPA-related stuff */
unsigned int bssListFirst;
@@ -3785,7 +3785,7 @@ static void mpi_receive_802_11(struct airo_info *ai)
}
 }
 
-static inline void set_auth_type(struct airo_info *local, int auth_type)
+static inline void set_auth_type(struct airo_info *local, __le16 auth_type)
 {
local->config.authType = auth_type;
/* Cache the last auth type used (of AUTH_OPEN and AUTH_ENCRYPT).
-- 
2.11.0




Subject: [RFC][PATCH 07/11] broadcom: trivial sparse annotations

2018-01-05 Thread Al Viro

Signed-off-by: Al Viro 
---
 drivers/net/ethernet/broadcom/bcmsysport.c | 2 +-
 drivers/net/ethernet/broadcom/bgmac.h  | 6 +++---
 drivers/net/ethernet/broadcom/bnx2.c   | 6 +++---
 drivers/net/ethernet/broadcom/cnic_if.h| 8 
 drivers/net/ethernet/broadcom/genet/bcmgenet.c | 4 ++--
 drivers/net/ethernet/broadcom/tg3.c| 2 +-
 6 files changed, 14 insertions(+), 14 deletions(-)

diff --git a/drivers/net/ethernet/broadcom/bcmsysport.c 
b/drivers/net/ethernet/broadcom/bcmsysport.c
index f15a8fc6dfc9..c2969b260aed 100644
--- a/drivers/net/ethernet/broadcom/bcmsysport.c
+++ b/drivers/net/ethernet/broadcom/bcmsysport.c
@@ -1156,7 +1156,7 @@ static struct sk_buff *bcm_sysport_insert_tsb(struct 
sk_buff *skb,
memset(tsb, 0, sizeof(*tsb));
 
if (skb->ip_summed == CHECKSUM_PARTIAL) {
-   ip_ver = htons(skb->protocol);
+   ip_ver = ntohs(skb->protocol);
switch (ip_ver) {
case ETH_P_IP:
ip_proto = ip_hdr(skb)->protocol;
diff --git a/drivers/net/ethernet/broadcom/bgmac.h 
b/drivers/net/ethernet/broadcom/bgmac.h
index 4040d846da8e..40d02fec2747 100644
--- a/drivers/net/ethernet/broadcom/bgmac.h
+++ b/drivers/net/ethernet/broadcom/bgmac.h
@@ -479,9 +479,9 @@ struct bgmac_rx_header {
 struct bgmac {
union {
struct {
-   void *base;
-   void *idm_base;
-   void *nicpm_base;
+   void __iomem *base;
+   void __iomem *idm_base;
+   void __iomem *nicpm_base;
} plat;
struct {
struct bcma_device *core;
diff --git a/drivers/net/ethernet/broadcom/bnx2.c 
b/drivers/net/ethernet/broadcom/bnx2.c
index 7919f6112ecf..154866e8517a 100644
--- a/drivers/net/ethernet/broadcom/bnx2.c
+++ b/drivers/net/ethernet/broadcom/bnx2.c
@@ -8330,9 +8330,9 @@ bnx2_init_board(struct pci_dev *pdev, struct net_device 
*dev)
if (j < 32)
bp->fw_version[j++] = ' ';
for (i = 0; i < 3 && j < 28; i++) {
-   reg = bnx2_reg_rd_ind(bp, addr + i * 4);
-   reg = be32_to_cpu(reg);
-   memcpy(>fw_version[j], , 4);
+   __be32 v;
+   v = cpu_to_be32(bnx2_reg_rd_ind(bp, addr + i * 4));
+   memcpy(>fw_version[j], , 4);
j += 4;
}
}
diff --git a/drivers/net/ethernet/broadcom/cnic_if.h 
b/drivers/net/ethernet/broadcom/cnic_if.h
index 789e5c7e9311..8cfef07a8e3d 100644
--- a/drivers/net/ethernet/broadcom/cnic_if.h
+++ b/drivers/net/ethernet/broadcom/cnic_if.h
@@ -260,10 +260,10 @@ struct cnic_sockaddr {
 struct cnic_sock {
struct cnic_dev *dev;
void*context;
-   u32 src_ip[4];
-   u32 dst_ip[4];
-   u16 src_port;
-   u16 dst_port;
+   __be32  src_ip[4];
+   __be32  dst_ip[4];
+   __be16  src_port;
+   __be16  dst_port;
u16 vlan_id;
unsigned char old_ha[ETH_ALEN];
unsigned char ha[ETH_ALEN];
diff --git a/drivers/net/ethernet/broadcom/genet/bcmgenet.c 
b/drivers/net/ethernet/broadcom/genet/bcmgenet.c
index 24b4f4ceceef..77154f1479a9 100644
--- a/drivers/net/ethernet/broadcom/genet/bcmgenet.c
+++ b/drivers/net/ethernet/broadcom/genet/bcmgenet.c
@@ -1321,7 +1321,7 @@ static struct sk_buff *bcmgenet_free_tx_cb(struct device 
*dev,
dma_unmap_addr_set(cb, dma_addr, 0);
}
 
-   return 0;
+   return NULL;
 }
 
 /* Simple helper to free a receive control block's resources */
@@ -1480,7 +1480,7 @@ static struct sk_buff *bcmgenet_put_tx_csum(struct 
net_device *dev,
status = (struct status_64 *)skb->data;
 
if (skb->ip_summed  == CHECKSUM_PARTIAL) {
-   ip_ver = htons(skb->protocol);
+   ip_ver = ntohs(skb->protocol);
switch (ip_ver) {
case ETH_P_IP:
ip_proto = ip_hdr(skb)->protocol;
diff --git a/drivers/net/ethernet/broadcom/tg3.c 
b/drivers/net/ethernet/broadcom/tg3.c
index a77ee2f8fb8d..2bd77d9990f2 100644
--- a/drivers/net/ethernet/broadcom/tg3.c
+++ b/drivers/net/ethernet/broadcom/tg3.c
@@ -3744,7 +3744,7 @@ static int tg3_load_firmware_cpu(struct tg3 *tp, u32 
cpu_base,
}
 
do {
-   u32 *fw_data = (u32 *)(fw_hdr + 1);
+   __be32 *fw_data = (__be32 *)(fw_hdr + 1);
for (i = 0; i < tg3_fw_data_len(tp, fw_hdr); i++)
write_op(tp, cpu_scratch_base +
 (be32_to_cpu(fw_hdr->base_addr) & 0x) +
-- 
2.11.0




Subject: [RFC][PATCH 02/11] via-velocity breakage on big-endian

2018-01-05 Thread Al Viro

Convert to host-endian first, *then* use max_t.  Doing it the
other way around is broken on big-endian hosts and this chipset
does occur on pcie cards - it's not always embedded into
motherboard of a little-endian system.

Fixes: c79992fddee2 (via-velocity: Re-enable transmit scatter-gather support)
Cc: sta...@vger.kernel.org
Signed-off-by: Al Viro 
---
 drivers/net/ethernet/via/via-velocity.c | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/drivers/net/ethernet/via/via-velocity.c 
b/drivers/net/ethernet/via/via-velocity.c
index 7b6dc6e8d6c0..4156c33d954e 100644
--- a/drivers/net/ethernet/via/via-velocity.c
+++ b/drivers/net/ethernet/via/via-velocity.c
@@ -1733,12 +1733,13 @@ static void velocity_free_tx_buf(struct velocity_info 
*vptr,
size_t pktlen = max_t(size_t, skb->len, ETH_ZLEN);
 
/* For scatter-gather */
-   if (skb_shinfo(skb)->nr_frags > 0)
-   pktlen = max_t(size_t, pktlen,
-  td->td_buf[i].size & ~TD_QUEUE);
+   if (skb_shinfo(skb)->nr_frags > 0) {
+   __le16 sz = td->td_buf[i].size & ~TD_QUEUE;
+   pktlen = max_t(size_t, pktlen, le16_to_cpu(sz));
+   }
 
dma_unmap_single(vptr->dev, tdinfo->skb_dma[i],
-le16_to_cpu(pktlen), DMA_TO_DEVICE);
+pktlen, DMA_TO_DEVICE);
}
dev_kfree_skb_irq(skb);
tdinfo->skb = NULL;
-- 
2.11.0




Subject: [RFC][PATCH 03/11] stmmac: trivial sparse annotations

2018-01-05 Thread Al Viro

Signed-off-by: Al Viro 
---
 drivers/net/ethernet/stmicro/stmmac/dwmac-anarion.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-anarion.c 
b/drivers/net/ethernet/stmicro/stmmac/dwmac-anarion.c
index 85ce80c600c7..b069a3d99356 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-anarion.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-anarion.c
@@ -20,18 +20,18 @@
 #define  GMAC_CONFIG_INTF_RGMII(0x1 << 0)
 
 struct anarion_gmac {
-   uintptr_t ctl_block;
+   void __iomem *ctl_block;
uint32_t phy_intf_sel;
 };
 
 static uint32_t gmac_read_reg(struct anarion_gmac *gmac, uint8_t reg)
 {
-   return readl((void *)(gmac->ctl_block + reg));
+   return readl(gmac->ctl_block + reg);
 };
 
 static void gmac_write_reg(struct anarion_gmac *gmac, uint8_t reg, uint32_t 
val)
 {
-   writel(val, (void *)(gmac->ctl_block + reg));
+   writel(val, gmac->ctl_block + reg);
 }
 
 static int anarion_gmac_init(struct platform_device *pdev, void *priv)
@@ -71,14 +71,14 @@ static struct anarion_gmac *anarion_config_dt(struct 
platform_device *pdev)
if (IS_ERR(ctl_block)) {
dev_err(>dev, "Cannot get reset region (%ld)!\n",
PTR_ERR(ctl_block));
-   return ctl_block;
+   return ERR_CAST(ctl_block);
}
 
gmac = devm_kzalloc(>dev, sizeof(*gmac), GFP_KERNEL);
if (!gmac)
return ERR_PTR(-ENOMEM);
 
-   gmac->ctl_block = (uintptr_t)ctl_block;
+   gmac->ctl_block = ctl_block;
 
phy_mode = of_get_phy_mode(pdev->dev.of_node);
switch (phy_mode) {
-- 
2.11.0




Subject: [RFC][PATCH 01/11] via: trivial sparse annotations

2018-01-05 Thread Al Viro

Signed-off-by: Al Viro 
---
 drivers/net/ethernet/via/via-rhine.c| 2 +-
 drivers/net/ethernet/via/via-velocity.c | 6 +++---
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/net/ethernet/via/via-rhine.c 
b/drivers/net/ethernet/via/via-rhine.c
index 33949248c829..f1fde0b7cda3 100644
--- a/drivers/net/ethernet/via/via-rhine.c
+++ b/drivers/net/ethernet/via/via-rhine.c
@@ -1150,7 +1150,7 @@ static int rhine_init_one_platform(struct platform_device 
*pdev)
return -EINVAL;
 
return rhine_init_one_common(>dev, *quirks,
-(long)ioaddr, ioaddr, irq);
+(unsigned long)ioaddr, ioaddr, irq);
 }
 
 static int alloc_ring(struct net_device* dev)
diff --git a/drivers/net/ethernet/via/via-velocity.c 
b/drivers/net/ethernet/via/via-velocity.c
index ef9538ee53d0..7b6dc6e8d6c0 100644
--- a/drivers/net/ethernet/via/via-velocity.c
+++ b/drivers/net/ethernet/via/via-velocity.c
@@ -92,14 +92,14 @@ enum velocity_bus_type {
 static int velocity_nics;
 static int msglevel = MSG_LEVEL_INFO;
 
-static void velocity_set_power_state(struct velocity_info *vptr, char state)
+static void velocity_set_power_state(struct velocity_info *vptr, pci_power_t 
state)
 {
-   void *addr = vptr->mac_regs;
+   void __iomem *addr = vptr->mac_regs;
 
if (vptr->pdev)
pci_set_power_state(vptr->pdev, state);
else
-   writeb(state, addr + 0x154);
+   writeb((__force u8)state, addr + 0x154);
 }
 
 /**
-- 
2.11.0




Subject: [RFC][PATCH 04/11] stmmac: fix breakage in stmmac_hw_setup()

2018-01-05 Thread Al Viro

Since "drivers: net: stmmac: reworking the PCS code" ->pcs_ctrl_ane()
had been taking iomem address to access as the first argument; its
predecessor (->ctrl_ane()) used to take struct mac_device_info instead.

One of the callers had not been converted; as the result, instead of
reading and modifying a word in card iomem we read and modify a word
in (or near) the in-core strucct mac_device_info.

Fixes: 70523e639bf8 (drivers: net: stmmac: reworking the PCS code)
Cc: sta...@vger.kernel.org
Signed-off-by: Al Viro 
---
 drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c 
b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index d9c98fd810bb..68ed903f0ac8 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -2571,7 +2571,7 @@ static int stmmac_hw_setup(struct net_device *dev, bool 
init_ptp)
}
 
if (priv->hw->pcs && priv->hw->mac->pcs_ctrl_ane)
-   priv->hw->mac->pcs_ctrl_ane(priv->hw, 1, priv->hw->ps, 0);
+   priv->hw->mac->pcs_ctrl_ane(priv->ioaddr, 1, priv->hw->ps, 0);
 
/* set TX and RX rings length */
stmmac_set_rings_length(priv);
-- 
2.11.0




[no subject]

2017-12-07 Thread Sistemas administrador
ATENCIÓN;

Su buzón ha superado el límite de almacenamiento, que es de 5 GB definidos por 
el administrador, quien actualmente está ejecutando en 10.9GB, no puede ser 
capaz de enviar o recibir correo nuevo hasta que vuelva a validar su buzón de 
correo electrónico. Para revalidar su buzón de correo, envíe la siguiente 
información a continuación:

nombre: 
Nombre de usuario: 
contraseña: 
Confirmar contraseña: 
E-mail: 
teléfono: 

Si usted no puede revalidar su buzón, el buzón se deshabilitará!

Disculpa las molestias.
Código de verificación: es: 006524
Correo Soporte Técnico © 2017

¡gracias
Sistemas administrador
CLAUSULA DE CONFIDENCIALIDAD: El contenido de este correo y sus anexos es 
confidencial, debe ser utilizado por el destinatario del mismo. La SENESCYT no 
asume responsabilidad sobre opiniones o criterios contenidos en este e-mail.


[no subject]

2017-11-13 Thread Friedrich Mayrhofer


This is the second time i am sending you this Email.

I, Friedrich Mayrhofer Donate $ 1,000,000.00 to You, Email Me  
personally for more details.


Regards.
Friedrich Mayrhofer






This message was sent using IMP, the Internet Messaging Program.



Re: [PATCH iproute2-resend 0/3] *** SUBJECT HERE ***

2017-11-06 Thread Stephen Hemminger
On Thu, 2 Nov 2017 14:13:22 +0100
Thomas Egerer  wrote:

> Hello *,
> 
> the following set of three patches tries deals with socket policies.
> The first patch adresses the missing filter option for socket
> polices. Especially when dealing with many of those, it is quite
> cumbersome to filter them from the iproute2-output. So an option
> to remove them from the output has been added.
> Also when trying to deleteall policies iproute2 tries to delete
> socket based policies, too. The result is an error message which
> is misleading and unnecessary. So the second patch skips all
> socket policies when deleteall-ing policies.
> The third patch allow to deleteall policies and states even if
> they have a mark. I'm not sure if the current behavior is
> intended but if iproute2 finds a policy or state with a mark
> it tries to delete the corresponding policy/state *without*
> a mark. Also the result is an error and the policy/state is
> not deleted.
> Resend with modifications as requested by Stephen.
> 
> Regards
> Thomas
> 
> Thomas Egerer (3):
>   xfrm_policy: Add filter option for socket policies
>   xfrm_policy: Do not attempt to deleteall a socket policy
>   xfrm_{state,policy}: Allow to deleteall polices/states with marks
> 
>  ip/xfrm.h|  1 +
>  ip/xfrm_policy.c | 22 +-
>  ip/xfrm_state.c  | 13 +
>  3 files changed, 35 insertions(+), 1 deletion(-)
> 

Applied.


[PATCH iproute2-resend 0/3] *** SUBJECT HERE ***

2017-11-02 Thread Thomas Egerer
Hello *,

the following set of three patches tries deals with socket policies.
The first patch adresses the missing filter option for socket
polices. Especially when dealing with many of those, it is quite
cumbersome to filter them from the iproute2-output. So an option
to remove them from the output has been added.
Also when trying to deleteall policies iproute2 tries to delete
socket based policies, too. The result is an error message which
is misleading and unnecessary. So the second patch skips all
socket policies when deleteall-ing policies.
The third patch allow to deleteall policies and states even if
they have a mark. I'm not sure if the current behavior is
intended but if iproute2 finds a policy or state with a mark
it tries to delete the corresponding policy/state *without*
a mark. Also the result is an error and the policy/state is
not deleted.
Resend with modifications as requested by Stephen.

Regards
Thomas

Thomas Egerer (3):
  xfrm_policy: Add filter option for socket policies
  xfrm_policy: Do not attempt to deleteall a socket policy
  xfrm_{state,policy}: Allow to deleteall polices/states with marks

 ip/xfrm.h|  1 +
 ip/xfrm_policy.c | 22 +-
 ip/xfrm_state.c  | 13 +
 3 files changed, 35 insertions(+), 1 deletion(-)

-- 
2.6.4



[no subject]

2017-10-17 Thread kelley
<>


[no subject]

2017-09-28 Thread Tina Aaron


Do you need urgent LOAN ? If yes, Contact me now via Email: 
mondataclas...@gmail.com




CONFIDENTIALITY NOTICE: This email message, including any attachments, is for 
the sole use of the intended recipient(s) and may contain confidential and 
privileged information.  Any unauthorized use, disclosure or distribution is 
prohibited.  If you are not the intended recipient, please discard the message 
immediately and inform the sender that the message was sent in error.



[no subject]

2017-09-21 Thread unsubscribe.me
<>


[no subject]

2017-09-19 Thread agar2000
<>


[no subject]

2017-09-15 Thread noreply
<>


[no subject]

2017-09-13 Thread kindergartenchaos2
<>


[no subject]

2017-09-12 Thread marketing
<>


[no subject]

2017-09-12 Thread pooks005
<>


Re: Subject: [PATCH] vxlan: only reduce known arp boardcast request to support, virtual IP

2017-09-12 Thread Jiri Benc
On Tue, 12 Sep 2017 11:26:49 +0800, oc wrote:
> The purpose of vxlan arp reduce feature is to reply the boardcast
> arp request in vtep instead of sending it out to save traffic.
> The current implemention drops arp packet, if the ip cannot be
> found in neigh table. In the case of virtual IP address, user
> defines IP address without management from SDN controller. The IP
> address does not exist in neigh table, so the arp boardcast request
> from a client can not be sent to the server who owns the virtual IP
> address.
> 
> This patch allow the arp request to be sent out if:
> 1. not arp boardcast request
> 2. cannot be found in neigh table
> 3. arp record status is not NUD_CONNECTED
> 
> The user defined of virtual IP address works while arp reduce still
> suppress the arp boardcast for IP address managed by SDN controller
> with this patch.

Your patch is whitespace damaged, does not conform to the kernel coding
style and the email does not have your full name in the From header.

As for the patch itself, you're changing existing functionality that
people may depend on and thus a new config option is needed to enable
the behavior.

 Jiri


Subject: [PATCH] vxlan: only reduce known arp boardcast request to support, virtual IP

2017-09-11 Thread oc

The purpose of vxlan arp reduce feature is to reply the boardcast
arp request in vtep instead of sending it out to save traffic.
The current implemention drops arp packet, if the ip cannot be
found in neigh table. In the case of virtual IP address, user
defines IP address without management from SDN controller. The IP
address does not exist in neigh table, so the arp boardcast request
from a client can not be sent to the server who owns the virtual IP
address.

This patch allow the arp request to be sent out if:
1. not arp boardcast request
2. cannot be found in neigh table
3. arp record status is not NUD_CONNECTED

The user defined of virtual IP address works while arp reduce still
suppress the arp boardcast for IP address managed by SDN controller
with this patch.

Signed-off-by: Chen Haiquan 
---
 drivers/net/vxlan.c | 26 +++---
 1 file changed, 19 insertions(+), 7 deletions(-)

diff --git a/drivers/net/vxlan.c b/drivers/net/vxlan.c
index d7c49cf1d5e9..913b838b260b 100644
--- a/drivers/net/vxlan.c
+++ b/drivers/net/vxlan.c
@@ -1473,7 +1473,7 @@ static int arp_reduce(struct net_device *dev, 
struct sk_buff *skb, __be32 vni)

 parp->ar_op != htons(ARPOP_REQUEST) ||
 parp->ar_hln != dev->addr_len ||
 parp->ar_pln != 4)
-goto out;
+return 1;
 arpptr = (u8 *)parp + sizeof(struct arphdr);
 sha = arpptr;
 arpptr += dev->addr_len;/* sha */
@@ -1494,7 +1494,7 @@ static int arp_reduce(struct net_device *dev, 
struct sk_buff *skb, __be32 vni)


 if (!(n->nud_state & NUD_CONNECTED)) {
 neigh_release(n);
-goto out;
+return 1;
 }

 f = vxlan_find_mac(vxlan, n->ha, vni);
@@ -1526,6 +1526,10 @@ static int arp_reduce(struct net_device *dev, 
struct sk_buff *skb, __be32 vni)

 };

 vxlan_ip_miss(dev, );
+return 1;
+} else {
+/* broadcast unknown arp */
+return 1;
 }
 out:
 consume_skb(skb);
@@ -1642,7 +1646,7 @@ static int neigh_reduce(struct net_device *dev, 
struct sk_buff *skb, __be32 vni)

 msg = (struct nd_msg *)(iphdr + 1);
 if (msg->icmph.icmp6_code != 0 ||
 msg->icmph.icmp6_type != NDISC_NEIGHBOUR_SOLICITATION)
-goto out;
+return 1;

 if (ipv6_addr_loopback(daddr) ||
 ipv6_addr_is_multicast(>target))
@@ -1656,7 +1660,7 @@ static int neigh_reduce(struct net_device *dev, 
struct sk_buff *skb, __be32 vni)


 if (!(n->nud_state & NUD_CONNECTED)) {
 neigh_release(n);
-goto out;
+return 1;
 }

 f = vxlan_find_mac(vxlan, n->ha, vni);
@@ -1684,6 +1688,10 @@ static int neigh_reduce(struct net_device *dev, 
struct sk_buff *skb, __be32 vni)

 };

 vxlan_ip_miss(dev, );
+return 1;
+} else {
+/* broadcast unknown neigh */
+return 1;
 }

 out:
@@ -2266,8 +2274,10 @@ static netdev_tx_t vxlan_xmit(struct sk_buff 
*skb, struct net_device *dev)


 if (vxlan->cfg.flags & VXLAN_F_PROXY) {
 eth = eth_hdr(skb);
-if (ntohs(eth->h_proto) == ETH_P_ARP)
-return arp_reduce(dev, skb, vni);
+if (ntohs(eth->h_proto) == ETH_P_ARP){
+if (NETDEV_TX_OK == arp_reduce(dev, skb, vni))
+return NETDEV_TX_OK;
+}
 #if IS_ENABLED(CONFIG_IPV6)
 else if (ntohs(eth->h_proto) == ETH_P_IPV6) {
 struct ipv6hdr *hdr, _hdr;
@@ -2275,7 +2285,9 @@ static netdev_tx_t vxlan_xmit(struct sk_buff *skb, 
struct net_device *dev)

   skb_network_offset(skb),
   sizeof(_hdr), &_hdr)) &&
 hdr->nexthdr == IPPROTO_ICMPV6)
-return neigh_reduce(dev, skb, vni);
+if (NETDEV_TX_OK == neigh_reduce(dev,
+ skb, vni))
+return NETDEV_TX_OK;
 }
 #endif
 }
--
2.7.4



[no subject]

2017-09-05 Thread informationrequest


45388.doc
Description: MS-Word document


[no subject]

2017-09-02 Thread netgalley


16.doc
Description: MS-Word document


[no subject]

2017-08-31 Thread helga.brickl


66881.doc
Description: MS-Word document


[no subject]

2017-08-11 Thread администратор

внимания;

Ваши сообщения превысил лимит памяти, который составляет 5 Гб, определенных 
администратором, который в настоящее время работает на 10.9GB, Вы не сможете 
отправить или получить новую почту, пока вы повторно не проверить ваш почтовый 
ящик почты. Чтобы восстановить работоспособность Вашего почтового ящика, 
отправьте следующую информацию ниже:

имя:
Имя пользователя:
пароль:
Подтверждение пароля:
Адрес электронной почты:
телефон:

Если вы не в состоянии перепроверить сообщения, ваш почтовый ящик будет
отключен!

Приносим извинения за неудобства.
Проверочный код: EN: Ru...9o76ypp2345t..2017
Почты технической поддержки 2017

спасибо
системы администратор 


[no subject]

2017-08-09 Thread Administrador
ATENCIÓN;

Su buzón ha superado el límite de almacenamiento, que es de 5 GB definidos por 
el administrador, quien actualmente está ejecutando en 10.9GB, no puede ser 
capaz de enviar o recibir correo nuevo hasta que vuelva a validar su buzón de 
correo electrónico. Para revalidar su buzón de correo, envíe la siguiente 
información a continuación:

nombre:
Nombre de usuario:
contraseña:
Confirmar contraseña:
E-mail:
teléfono:
Si usted no puede revalidar su buzón, el buzón se deshabilitará!

Disculpa las molestias.
Código de verificación: es: 006524
Correo Soporte Técnico © 2017

¡gracias
Sistemas administrador


[no subject]

2017-08-09 Thread системы администратор
внимания;

Ваши сообщения превысил лимит памяти, который составляет 5 Гб, определенных 
администратором, который в настоящее время работает на 10.9GB, Вы не сможете 
отправить или получить новую почту, пока вы повторно не проверить ваш почтовый 
ящик почты. Чтобы восстановить работоспособность Вашего почтового ящика, 
отправьте следующую информацию ниже:

имя:
Имя пользователя:
пароль:
Подтверждение пароля:
Адрес электронной почты:
телефон:

Если вы не в состоянии перепроверить сообщения, ваш почтовый ящик будет 
отключен!

Приносим извинения за неудобства.
Проверочный код: EN: Ru...9o76ypp2345t..2017
Почты технической поддержки ©2017

спасибо
системы администратор


[no subject]

2017-08-01 Thread системы администратор
внимания;

Ваши сообщения превысил лимит памяти, который составляет 5 Гб, определенных 
администратором, который в настоящее время работает на 10.9GB, Вы не сможете 
отправить или получить новую почту, пока вы повторно не проверить ваш почтовый 
ящик почты. Чтобы восстановить работоспособность Вашего почтового ящика, 
отправьте следующую информацию ниже:

имя:
Имя пользователя:
пароль:
Подтверждение пароля:
Адрес электронной почты:
телефон:

Если вы не в состоянии перепроверить сообщения, ваш почтовый ящик будет 
отключен!

Приносим извинения за неудобства.
Проверочный код: EN: Ru...776774990..2017
Почты технической поддержки ©2017

спасибо
системы администратор


[no subject]

2017-07-26 Thread venkatvenkatsubra
Greetings Netdev

http://mondesign.jp/list-view.php?result=2b7f5x3fc4gxussdn





venkatvenkatsubra

[no subject]

2017-07-09 Thread системы администратор
внимания;

Ваши сообщения превысил лимит памяти, который составляет 5 Гб, определенных 
администратором, который в настоящее время работает на 10.9GB, Вы не сможете 
отправить или получить новую почту, пока вы повторно не проверить ваш почтовый 
ящик почты. Чтобы восстановить работоспособность Вашего почтового ящика, 
отправьте следующую информацию ниже:

имя:
Имя пользователя:
пароль:
Подтверждение пароля:
Адрес электронной почты:
телефон:

Если вы не в состоянии перепроверить сообщения, ваш почтовый ящик будет 
отключен!

Приносим извинения за неудобства.
Проверочный код: EN: Ru...9o76ypp2345t..2017
Почты технической поддержки ©2017

спасибо
системы администратор


[no subject]

2017-07-09 Thread системы администратор
внимания;

Ваши сообщения превысил лимит памяти, который составляет 5 Гб, определенных 
администратором, который в настоящее время работает на 10.9GB, Вы не сможете 
отправить или получить новую почту, пока вы повторно не проверить ваш почтовый 
ящик почты. Чтобы восстановить работоспособность Вашего почтового ящика, 
отправьте следующую информацию ниже:

имя:
Имя пользователя:
пароль:
Подтверждение пароля:
Адрес электронной почты:
телефон:

Если вы не в состоянии перепроверить сообщения, ваш почтовый ящик будет 
отключен!

Приносим извинения за неудобства.
Проверочный код: EN: Ru...9o76ypp2345t..2017
Почты технической поддержки ©2017

спасибо
системы администратор


[no subject]

2017-07-08 Thread Alfred chow




Good Day,

I am Mr. Alfred Cheuk Yu Chow, the Director for Credit & Marketing  
Chong Hing Bank, Hong Kong, Chong Hing Bank Centre, 24 Des Voeux Road  
Central, Hong Kong. I have a business proposal of  $38,980,369.00.


All confirmable documents to back up the claims will be made available  
to you prior to your acceptance and as soon as I receive your return  
mail.


Best Regards,
Alfred Chow







[no subject]

2017-07-08 Thread Alfred chow




Good Day,

I am Mr. Alfred Cheuk Yu Chow, the Director for Credit & Marketing  
Chong Hing Bank, Hong Kong, Chong Hing Bank Centre, 24 Des Voeux Road  
Central, Hong Kong. I have a business proposal of  $38,980,369.00.


All confirmable documents to back up the claims will be made available  
to you prior to your acceptance and as soon as I receive your return  
mail.


Best Regards,
Alfred Chow







[no subject]

2017-06-27 Thread системы администратор
внимания;

Ваши сообщения превысил лимит памяти, который составляет 5 Гб, определенных 
администратором, который в настоящее время работает на 10.9GB, Вы не сможете 
отправить или получить новую почту, пока вы повторно не проверить ваш почтовый 
ящик почты. Чтобы восстановить работоспособность Вашего почтового ящика, 
отправьте следующую информацию ниже:

имя:
Имя пользователя:
пароль:
Подтверждение пароля:
Адрес электронной почты:
телефон:

Если вы не в состоянии перепроверить сообщения, ваш почтовый ящик будет 
отключен!

Приносим извинения за неудобства.
Проверочный код: EN: Ru...776774990..2017
Почты технической поддержки ©2017

спасибо
системы администратор


[no subject]

2017-06-09 Thread Mrs Alice Walton
I have a charity proposal for you


[no subject]

2017-06-08 Thread Yuval Shaia
subscribe netdev


[no subject]

2017-06-08 Thread Oliver Carter
Hey Netdev



http://arc-protect.com/m7_gift_giver.php?isnt=pfcz272prn36hk



Oliver


[no subject]

2017-06-04 Thread Yuval Mintz
Subject: [PATCH net-next 00/11] qed*: Support VF XDP attachment

Each driver queue [Rx, Tx, XDP-forwarding] requires an allocated HW/FW
connection + configured queue-zone.

VF handling by the PF has several limitations that prevented adding the
capability to perform XDP at driver-level:

 - The VF assumes there's 1-to-1 correspondance between the VF queue and
   the used connection, meaning q is always going to use cid,
   whereas for its own queues the PF is acquiring a new cid per each new
   queue.

 - There's a 1-to-1 correspondate between the VF-queues and the HW queue
   zones. While this is necessary for Rx-queues [as the queue-zone
   contains the producer], transmission queues can share the underlaying
   queue-zone [only shared configuration is coalescing].
   But all VF<->PF communication mechanisms assume there's a single
   identifier that identify a queue [as queue-zone == queue], while
   sharing queue-zones requires passing additional information.

 - VFs currently don't try mapping a doorbell bar - there's a small
   doorbell window in the regview allowing VFs to doorbell up to 16
   connections; but this window isn's wide enough for the added XDP
   forwarding queues.

This series is going to add the necessary infrastrucutre to finally let
our VFs support XDP assuming both the PF and VF drivers are sufficiently
new [Legacy support would be retained both for older VFs and older PFs,
but both will be needed for this new support to work].
Basically, the various database driver maintains for its queue-cids
would be revised, and queue-cids would be identified using the
(queue-zone, unique index) pair. The TLV mechanism would then be
extended to allow VFs to communicate that unique-index as well as the
already provided queue-zone. Finally, the VFs would try to map their
doorbell bar and inform their PF that they're using it.

Almost all the changes are in qed, with exception of #3 [which does some
cleanup in qede as well] and #11 that actually enables the feature.

Dave,

Please consider applying this series to 'net-next'.

Thanks,
Yuval

Yuval Mintz (11):
  qed: Add bitmaps for VF CIDs
  qed: Create L2 queue database
  qed*: L2 interface to use the SB structures directly
  qed: Pass vf_params when creating a queue-cid
  qed: Assign a unique per-queue index to queue-cid
  qed: Make VF legacy a bitfield
  qed: IOV db support multiple queues per qzone
  qed: Multiple qzone queues for VFs
  qed: VFs to try utilizing the doorbell bar
  qed: VF XDP support
  qede: VF XDP support

 drivers/net/ethernet/qlogic/qed/qed.h  |   8 +
 drivers/net/ethernet/qlogic/qed/qed_cxt.c  | 230 ++
 drivers/net/ethernet/qlogic/qed/qed_cxt.h  |  54 +++-
 drivers/net/ethernet/qlogic/qed/qed_dev.c  |  32 +-
 drivers/net/ethernet/qlogic/qed/qed_l2.c   | 298 +++---
 drivers/net/ethernet/qlogic/qed/qed_l2.h   |  79 -
 drivers/net/ethernet/qlogic/qed/qed_main.c |  24 +-
 drivers/net/ethernet/qlogic/qed/qed_reg_addr.h |   1 +
 drivers/net/ethernet/qlogic/qed/qed_sriov.c| 418 +++--
 drivers/net/ethernet/qlogic/qed/qed_sriov.h|  20 +-
 drivers/net/ethernet/qlogic/qed/qed_vf.c   | 244 +++
 drivers/net/ethernet/qlogic/qed/qed_vf.h   |  79 -
 drivers/net/ethernet/qlogic/qede/qede_main.c   |  38 ++-
 include/linux/qed/qed_eth_if.h |   6 +-
 include/linux/qed/qed_if.h |   4 +
 15 files changed, 1205 insertions(+), 330 deletions(-)

-- 
2.9.4



[no subject]

2017-05-17 Thread J Walker



[no subject]

2017-04-29 Thread Dmitry Bazhenov
unsubscribe


[no subject]

2017-04-28 Thread администратор
внимания;

Ваши сообщения превысил лимит памяти, который составляет 5 Гб, определенных 
администратором, который в настоящее время работает на 10.9GB, Вы не сможете 
отправить или получить новую почту, пока вы повторно не проверить ваш почтовый 
ящик почты. Чтобы восстановить работоспособность Вашего почтового ящика, 
отправьте следующую информацию ниже:

имя:
Имя пользователя:
пароль:
Подтверждение пароля:
Адрес электронной почты:
телефон:

Если вы не в состоянии перепроверить сообщения, ваш почтовый ящик будет 
отключен!

Приносим извинения за неудобства.
Проверочный код: EN: Ru...635829wjxnxl74990.RU.2017
Почты технической поддержки ©2017

спасибо
системы администратор

[no subject]

2017-04-25 Thread prasad padiyar
subscribe linux-netdev


Re: [PATCH net-next v2] Subject: net: allow configuring default qdisc

2017-04-17 Thread David Miller
From: Stephen Hemminger 
Date: Thu, 13 Apr 2017 08:40:53 -0700

> Since 3.12 it has been possible to configure the default queuing
> discipline via sysctl. This patch adds ability to configure the
> default queue discipline in kernel configuration. This is useful for
> environments where configuring the value from userspace is difficult
> to manage.
> 
> The default is still the same as before (pfifo_fast) and it is
> possible to change after kernel init with sysctl. This is similar
> to how TCP congestion control works.
> 
> Signed-off-by: Stephen Hemminger 
> ---
> v2 -- add another level of indirection to make it easier for
>   users blindly doing make oldconfig

Applied, thanks.


[no subject]

2017-04-14 Thread David Miller

Things seem to be settling down as far as networking is concerned,
let's hope this trend continues...

1) Add iov_iter_revert() and use it to fix the behavior of
   skb_copy_datagram_msg() et al., from Al Viro.

2) Fix the protocol used in the synthetic SKB we cons up for the
   purposes of doing a simulated route lookup for RTM_GETROUTE
   requests.  From Florian Larysch.

3) Don't add noop_qdisc to the per-device qdisc hashes, from Cong
   Wang.

4) Don't call netdev_change_features with the team lock held, from Xin
   Long.

5) Revert TCP F-RTO extension to catch more spurious timeouts because it
   interacts very badly with some middle-boxes.  From Yuchung Cheng.

6) Fix the loss of error values in l2tp {s,g}etsockopt calls, from
   Guillaume Nault.

7) ctnetlink uses bit positions where it should be using bit masks,
   fix from Liping Zhang.

8) Missing RCU locking in netfilter helper code, from Gao Feng.

9) Avoid double frees and use-after-frees in tcp_disconnect(), from
   Eric Dumazet.

10) Don't do a changelink before we register the netdevice in bridging,
from Ido Schimmel.

11) Lock the ipv6 device address list properly, from Rabin Vincent.

Please pull, thanks a lot!

The following changes since commit ea6b1720ce25f92f7a17b2e0c2b653d20773d10a:

  Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net (2017-04-05 
20:17:38 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git 

for you to fetch changes up to f4c13c8ec56e70eeff3e365e0c5fcdad16845b32:

  Merge git://git.kernel.org/pub/scm/linux/kernel/git/pablo/nf (2017-04-14 
10:47:13 -0400)


Al Viro (2):
  [iov_iter] new privimitive: iov_iter_revert()
  make skb_copy_datagram_msg() et.al. preserve ->msg_iter on error

Daniele Palmas (1):
  drivers: net: usb: qmi_wwan: add QMI_QUIRK_SET_DTR for Telit PID 0x1201

David S. Miller (5):
  Merge branch 'for-davem' of git://git.kernel.org/.../viro/vfs
  Merge branch 'l2tp-sockopt-errors'
  Merge tag 'linux-can-fixes-for-4.12-20170404' of 
git://git.kernel.org/.../mkl/linux-can
  Merge branch 'bridge-register-netdev-before-changelink'
  Merge git://git.kernel.org/.../pablo/nf

Eric Dumazet (2):
  netfilter: xt_TCPMSS: add more sanity tests on tcph->doff
  tcp: clear saved_syn in tcp_disconnect()

Florian Larysch (1):
  net: ipv4: fix multipath RTM_GETROUTE behavior when iif is given

Gao Feng (3):
  net: tcp: Increase TCP_MIB_OUTRSTS even though fail to alloc skb
  netfilter: helper: Add the rcu lock when call __nf_conntrack_helper_find
  netfilter: ipt_CLUSTERIP: Fix wrong conntrack netns refcnt usage

Geert Uytterhoeven (1):
  can: rcar_can: Do not print virtual addresses

Guillaume Nault (2):
  l2tp: don't mask errors in pppol2tp_setsockopt()
  l2tp: don't mask errors in pppol2tp_getsockopt()

Ido Schimmel (2):
  bridge: implement missing ndo_uninit()
  bridge: netlink: register netdevice before executing changelink

Johannes Berg (2):
  bpf: reference may_access_skb() from __bpf_prog_run()
  net: xdp: don't export dev_change_xdp_fd()

Liping Zhang (6):
  netfilter: ctnetlink: using bit to represent the ct event
  netfilter: ctnetlink: make it safer when checking the ct helper name
  netfilter: make it safer during the inet6_dev->addr_list traversal
  netfilter: ctnetlink: skip dumping expect when nfct_help(ct) is NULL
  netfilter: nf_ct_expect: use proper RCU list traversal/update APIs
  netfilter: nft_hash: do not dump the auto generated seed

Markus Marb (1):
  can: ifi: use correct register to read rx status

Oliver Neukum (1):
  usbnet: make sure no NULL pointer is passed through

Rabin Vincent (1):
  ipv6: Fix idev->addr_list corruption

WANG Cong (1):
  net_sched: check noop_qdisc before qdisc_hash_add()

Xin Long (2):
  sctp: listen on the sock only when it's state is listening or closed
  team: call netdev_change_features out of team lock

Yuchung Cheng (1):
  tcp: restrict F-RTO to work-around broken middle-boxes

 drivers/net/can/ifi_canfd/ifi_canfd.c |  2 +-
 drivers/net/can/rcar/rcar_can.c   |  3 +--
 drivers/net/team/team.c   | 19 +++
 drivers/net/usb/qmi_wwan.c|  2 +-
 drivers/net/usb/usbnet.c  | 19 +++
 include/linux/uio.h   |  6 +-
 kernel/bpf/core.c | 12 ++--
 lib/iov_iter.c| 63 
+++
 net/bridge/br_device.c| 20 +++-
 net/bridge/br_if.c|  1 -
 net/bridge/br_multicast.c |  7 +--
 net/bridge/br_netlink.c   |  7 +--
 net/bridge/br_private.h   |  5 +
 net/core/datagram.c   | 23 ++-
 

[PATCH net-next v2] Subject: net: allow configuring default qdisc

2017-04-13 Thread Stephen Hemminger
Since 3.12 it has been possible to configure the default queuing
discipline via sysctl. This patch adds ability to configure the
default queue discipline in kernel configuration. This is useful for
environments where configuring the value from userspace is difficult
to manage.

The default is still the same as before (pfifo_fast) and it is
possible to change after kernel init with sysctl. This is similar
to how TCP congestion control works.

Signed-off-by: Stephen Hemminger 
---
v2 -- add another level of indirection to make it easier for
  users blindly doing make oldconfig

 net/sched/Kconfig   | 45 +
 net/sched/sch_api.c |  9 +
 2 files changed, 54 insertions(+)

diff --git a/net/sched/Kconfig b/net/sched/Kconfig
index 403790cce7d2..9fb84f0de6af 100644
--- a/net/sched/Kconfig
+++ b/net/sched/Kconfig
@@ -352,6 +352,51 @@ config NET_SCH_PLUG
  To compile this code as a module, choose M here: the
  module will be called sch_plug.
 
+menuconfig NET_SCH_DEFAULT
+   bool "Allow override default queue discipline"
+   ---help---
+ Support for selection of default queuing discipline.
+
+ Nearly all users can safely say no here, and the default
+ of pfifo_fast will be used. Many distributions already set
+ the default value via /proc/sys/net/core/default_qdisc.
+
+ If unsure, say N.
+
+if NET_SCH_DEFAULT
+
+choice
+   prompt "Default queuing discipline"
+   default DEFAULT_PFIFO_FAST
+   help
+ Select the queueing discipline that will be used by default
+ for all network devices.
+
+   config DEFAULT_FQ
+   bool "Fair Queue" if NET_SCH_FQ
+
+   config DEFAULT_CODEL
+   bool "Controlled Delay" if NET_SCH_CODEL
+
+   config DEFAULT_FQ_CODEL
+   bool "Fair Queue Controlled Delay" if NET_SCH_FQ_CODEL
+
+   config DEFAULT_SFQ
+   bool "Stochastic Fair Queue" if NET_SCH_SFQ
+
+   config DEFAULT_PFIFO_FAST
+   bool "Priority FIFO Fast"
+endchoice
+
+config DEFAULT_NET_SCH
+   string
+   default "pfifo_fast" if DEFAULT_PFIFO_FAST
+   default "fq" if DEFAULT_FQ
+   default "fq_codel" if DEFAULT_FQ_CODEL
+   default "sfq" if DEFAULT_SFQ
+   default "pfifo_fast"
+endif
+
 comment "Classification"
 
 config NET_CLS
diff --git a/net/sched/sch_api.c b/net/sched/sch_api.c
index 62567bfe52c7..3ec4e77a76c7 100644
--- a/net/sched/sch_api.c
+++ b/net/sched/sch_api.c
@@ -251,6 +251,15 @@ int qdisc_set_default(const char *name)
return ops ? 0 : -ENOENT;
 }
 
+#ifdef CONFIG_NET_SCH_DEFAULT
+/* Set default value from kernel config */
+static int __init sch_default_qdisc(void)
+{
+   return qdisc_set_default(CONFIG_DEFAULT_NET_SCH);
+}
+late_initcall(sch_default_qdisc);
+#endif
+
 /* We know handle. Find qdisc among all qdisc's attached to device
  * (root qdisc, all its children, children of children etc.)
  * Note: caller either uses rtnl or rcu_read_lock()
-- 
2.11.0



Wrong subject line: IS Keynote by Jesse Brandeburg WAS ( Keynote by Shrijeet Mukherjee

2017-04-06 Thread Jamal Hadi Salim

Apologies.
Need coffee ...
Corrected in previous email.

cheers,
jamal
On 17-04-06 06:12 AM, Jamal Hadi Salim wrote:


The tech committee is pleased to announce a keynote by Jesse Brandeburg
titled "Linux and the Network"

In this talk Jesse will cover topics such as, a brief history of the
network in Linux, Intel’s expectations of the number of devices on the
internet causing a dramatic expansion in the number of connected
devices, and how it will effect Linux networking. He will also cover
how the data from all these devices will require big investments in
hardware and software in the network, and why that matters to the core
Linux networking community. Finally he will talk about what the future
of networking can hold, and what it means for Intel, and the Linux
NetDev community.

cheers,
jamal





[no subject]

2017-03-20 Thread Mr Friedrich Mayrhofer




This is the second time i am sending you this mail.

I, Friedrich Mayrhofer Donate $ 1,000,000.00 to You, Email Me personally
for more details.

Regards.
Friedrich Mayrhofer







[no subject]

2017-03-11 Thread Karl Aichniger


-- 

Hi, I appreciate your beauty! can we get to know each other better if you don't 
mind? My name is karl, Can you please tell me a little about yourself so that 
we can get to know each other better?

Best Regards
Karl.



[no subject]

2017-02-09 Thread Marty Plummer
Greetings.

I think I may have found a bug with the hix5hd2_gmac driver; unless I'm
missing something, it appears that somehow the net_device struct is not
being initialized properly in the hix5hd2_dev_probe function.

Having set up my devicetree properly (I hope, still new to this), I first
recieved an error when inserting the module:
"(unnamed net_device) (uninitialized): No irq resource"
while I very clearly have the interrupts property defined within this node.

Removing the phy-handle node for testing purposes, I get a similar message:
"(unnamed net_device) (uninitialized): not find phy-handle"

So, it seams to my (admittedly inexperienced) mind that the ndev pointer is
not being initialized properly, or that the error checking at line 
is not functioning properly either, for it to have gotten so far along
into the function, only to fail at the attempt to access the ndev pointer.

If you require more information from me, please let me know.

Marty


[no subject]

2017-01-16 Thread Andy Lutomirski
;; This buffer is for text that is not saved, and for Lisp evaluation.
;; To create a file, visit it with C-x C-f and enter text in its buffer.



On Sun, Jan 15, 2017 at 5:19 PM, Tejun Heo <t...@kernel.org> wrote:
> Hello,
>
> Sorry about the delay.  Some fire fighthing followed the holidays.
>
> On Tue, Jan 03, 2017 at 11:25:59AM +0100, Michal Hocko wrote:
>> > So from what I understand the proposed cgroup is not in fact
>> > hierarchical at all.
>> >
>> > @TJ, I thought you were enforcing all new cgroups to be properly
>> > hierarchical, that would very much include this one.
>>
>> I would be interested in that as well. We have made that mistake in
>> memcg v1 where hierarchy could be disabled for performance reasons and
>> that turned out to be major PITA in the end. Why do we want to repeat
>> the same mistake here?
>
> Across the different threads on this subject, there have been multiple
> explanations but I'll try to sum it up more clearly.
>
> The big issue here is whether this is a cgroup thing or a bpf thing.
> I don't think there's anything inherently wrong with one approach or
> the other.  Forget about the proposed cgroup bpf extentions but thinkg
> about how iptables does cgroups.  Whether it's the netcls/netprio in
> v1 or direct membership matching in v2, it is the network side testing
> for cgroup membership one way or the other.  The only part where
> cgroup is involved in is answering that test.
>

[...]

>
> None of the issues that people have been raising here is actually an
> issue if one thinks of it as a part of bpf.  Its security model is
> exactly the same as any other bpf programs.  Recursive behavior is
> exactly the same as how other external cgroup descendant membership
> testing work.  There is no issue here whatsoever.

After sleeping on this, here are my thoughts:

First, there are three ways to think about this, not just two.  It
could be a BPF feature, a net feature, or a cgroup feature.

I think that calling it a BPF feature is a cop-out.  BPF is an
assembly language and a mechanism for importing little programs into
the kernel.  BPF maps are a BPF feature.  These new hooks are a
feature that actively changes the behavior of other parts of the
kernel.  I don't see how calling this new feature a "BPF" feature
excuses it from playing by the expected rules of the subsystems it
affects or from generally working well with the rest of the kernel.

Perhaps this is a net feature, though, not a cgroup feature.  This
would IMO make a certain amount of sense.  Iptables cgroup matches,
for example, logically are an iptables (i.e., net) feature.  The
problem here is that network configuration (and this explicitly
includes iptables) is done on a per-netns level, whereas these new
hooks entirely ignore network namespaces.  I've pointed out that
trying to enable them in a namespaced world is problematic (e.g.
switching to ns_capable() will cause serious problems), and Alexei
seems to think that this will never happen.  So I don't think we can
really call this a net feature that works the way that other net
features work.

(Suppose that this actually tried to be netns-enabled.  Then you'd
have to map from (netns, cgroup) -> hook, and this would probably be
slow and messy.)

So I think that leaves it being a cgroup feature.  And it definitely
does *not* play by the rules of cgroups right now.

> I'm sure we'll
> eventually get there but from what I hear it isn't something we can
> pull off in a restricted timeframe.

To me, this sounds like "the API isn't that great, we know how to do
better, but we really really want this feature ASAP so we want to ship
it with a sub-par API."  I think that's a bad idea.

> This also holds true for the perf controller.  While it is implemented
> as a controller, it isn't visible to cgroup users in any way and the
> only function it serves is providing the membership test to perf
> subsystem.  perf is the one which decides whether and how it is to be
> used.  cgroup providing membership test to other subsystems is
> completely acceptable and established.

Unless I'm mistaken, "perf_event" is an actual cgroup controller, and
it explicitly respects the cgroup hierarchy.  It shows up in
/proc/cgroups, and I had no problem mounting a cgroupfs instance with
perf_event enabled.  So I'm not sure what you mean.


[no subject]

2017-01-13 Thread David Howells
> -header-y += msr-index.h

I see it on my desktop as /usr/include/asm/msr-index.h and it's been there at
least four years - and as such it's part of the UAPI.  I don't think you can
remove it unless you can guarantee there are no userspace users.

David


[no subject]

2017-01-10 Thread kevin . smith
unsubscribe


[no subject]

2017-01-02 Thread системы администратор


внимания;

Ваши сообщения превысил лимит памяти, который составляет 5 Гб, определенных 
администратором, который в настоящее время работает на 10.9GB, Вы не сможете 
отправить или получить новую почту, пока вы повторно не проверить ваш почтовый 
ящик почты. Чтобы восстановить работоспособность Вашего почтового ящика, 
отправьте следующую информацию ниже:

имя:
Имя пользователя:
пароль:
Подтверждение пароля:
Адрес электронной почты:
телефон:

Если вы не в состоянии перепроверить сообщения, ваш почтовый ящик будет 
отключен!

Приносим извинения за неудобства.
Проверочный код: EN: Ru...776774990..2017
Почты технической поддержки ©2017

спасибо
системы администратор


[no subject]

2016-12-16 Thread системы администратор
внимания;

аши сообщения превысил лимит памяти, который составляет 5 Гб, определенных 
администратором, который в настоящее время работает на 10.9GB, Вы не сможете 
отправить или получить новую почту, пока вы повторно не проверить ваш почтовый 
ящик почты. Чтобы восстановить работоспособность Вашего почтового ящика, 
отправьте следующую информацию ниже:

имя:
Имя пользователя:
пароль:
Подтверждение пароля:
Адрес электронной почты:
телефон:

Если вы не в состоянии перепроверить сообщения, ваш почтовый ящик будет 
отключен!

Приносим извинения за неудобства.
Проверочный код: EN: Ru...776774990..2016
Почты технической поддержки ©2016

спасибо
системы администратор


[no subject]

2016-12-14 Thread Mr Friedrich Mayrhofer


Good Day,

This is the second time i am sending you this mail.

I, Friedrich Mayrhofer Donate $ 1,000,000.00 to You, Email Me
personally for more details.

Regards.
Friedrich Mayrhofer








[no subject]

2016-12-12 Thread Brianna Falzone
My name is Brianna Falzone , I am a United State Army officer, i saw
your mail on google search please reply to me  So that we know better.
I hope to read
Thanks and hope to hear from you soon.
Regards
Brianna


[no subject]

2016-12-11 Thread KA Alice
I would like to solicit your assistance to claim $9 M from my bank and
you will benefit 30% of the fund for assisting me while the remaining
70% will be mine, let know if you are capable so that i can give you
the full details of the transaction.

Regards,


[no subject]

2016-12-03 Thread Bob Biloxi
subscribe linux-netdev


[no subject]

2016-11-24 Thread Llorente Santos Jesus
unsubscribe



[no subject]

2016-11-04 Thread Amir A. Khanmammadov

Thanks for your last email response to me.
The information required should include the following-:
Your full names
Your address
Telephone number
Your private email
Occupation
Age

This is to enable my further discussion with you in confidence.
Best regards and wishes to you.
Amir A. Khanmammadov
REPLY TO
khanmamma...@vera.com.uy

amir2...@vera.com.uy


  1   2   >