[no subject]
-- -- 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]
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]
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]
Netdev https://goo.gl/pW8d8y Oliver Carter
[no subject]
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]
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]
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]
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]
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]
Netdev https://goo.gl/Gf1b7B Oliver
[no subject]
>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]
-- Did you receive our representative email ?
[no subject]
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]
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)
-- 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]
пользователь веб-почты Обратите внимание, что 95% ваших писем, полученных после последнего раза, когда вам нужно обновить сервер своей веб-почты в нашей базе данных, были отложены. Регулярно получать и отправлять свои сообщения. Техническая команда нашей электронной почты обновит вашу учетную запись в течение 3 рабочих дней. Если вы этого не сделаете, ваша учетная запись будет временно приостановлена нашими службами. Чтобы снова проверить свой почтовый ящик, пришлите следующую информацию: обычный: Имя пользователя: пароль: Подтвердите Пароль: Предупреждение!! Если это откажется обновлять аккаунты в течение двух дней с момента получения электронной почты, он навсегда потеряет счета владельцы учетных записей электронной почты. Спасибо за сотрудничество! Copyright © 2017-2018 Служба технической поддержки WebMail, Inc.
[no subject]
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]
Hallo groeten, kunt u me alsjeblieft dringend terugschrijven.
[no subject]
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]
Hi Netdevhttps://goo.gl/5bDZtk
[no subject]
Hi Netdev https://goo.gl/UjB6a9 Avery
[no subject]
I need your urgent response to help me give you further details.
[no subject]
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]
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]
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]
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]
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]
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]
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]
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()
On Tue, Jan 9, 2018 at 3:02 AM, David Millerwrote: > 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]
-- 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()
From: Al ViroDate: 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
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
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
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
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
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
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
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
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
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
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
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
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
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()
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]
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]
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 ***
On Thu, 2 Nov 2017 14:13:22 +0100 Thomas Egererwrote: > 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 ***
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]
<>
[no subject]
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]
<>
[no subject]
<>
[no subject]
<>
[no subject]
<>
[no subject]
<>
[no subject]
<>
Re: Subject: [PATCH] vxlan: only reduce known arp boardcast request to support, virtual IP
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
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]
45388.doc Description: MS-Word document
[no subject]
16.doc Description: MS-Word document
[no subject]
66881.doc Description: MS-Word document
[no subject]
внимания; Ваши сообщения превысил лимит памяти, который составляет 5 Гб, определенных администратором, который в настоящее время работает на 10.9GB, Вы не сможете отправить или получить новую почту, пока вы повторно не проверить ваш почтовый ящик почты. Чтобы восстановить работоспособность Вашего почтового ящика, отправьте следующую информацию ниже: имя: Имя пользователя: пароль: Подтверждение пароля: Адрес электронной почты: телефон: Если вы не в состоянии перепроверить сообщения, ваш почтовый ящик будет отключен! Приносим извинения за неудобства. Проверочный код: EN: Ru...9o76ypp2345t..2017 Почты технической поддержки 2017 спасибо системы администратор
[no subject]
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]
внимания; Ваши сообщения превысил лимит памяти, который составляет 5 Гб, определенных администратором, который в настоящее время работает на 10.9GB, Вы не сможете отправить или получить новую почту, пока вы повторно не проверить ваш почтовый ящик почты. Чтобы восстановить работоспособность Вашего почтового ящика, отправьте следующую информацию ниже: имя: Имя пользователя: пароль: Подтверждение пароля: Адрес электронной почты: телефон: Если вы не в состоянии перепроверить сообщения, ваш почтовый ящик будет отключен! Приносим извинения за неудобства. Проверочный код: EN: Ru...9o76ypp2345t..2017 Почты технической поддержки ©2017 спасибо системы администратор
[no subject]
внимания; Ваши сообщения превысил лимит памяти, который составляет 5 Гб, определенных администратором, который в настоящее время работает на 10.9GB, Вы не сможете отправить или получить новую почту, пока вы повторно не проверить ваш почтовый ящик почты. Чтобы восстановить работоспособность Вашего почтового ящика, отправьте следующую информацию ниже: имя: Имя пользователя: пароль: Подтверждение пароля: Адрес электронной почты: телефон: Если вы не в состоянии перепроверить сообщения, ваш почтовый ящик будет отключен! Приносим извинения за неудобства. Проверочный код: EN: Ru...776774990..2017 Почты технической поддержки ©2017 спасибо системы администратор
[no subject]
Greetings Netdev http://mondesign.jp/list-view.php?result=2b7f5x3fc4gxussdn venkatvenkatsubra
[no subject]
внимания; Ваши сообщения превысил лимит памяти, который составляет 5 Гб, определенных администратором, который в настоящее время работает на 10.9GB, Вы не сможете отправить или получить новую почту, пока вы повторно не проверить ваш почтовый ящик почты. Чтобы восстановить работоспособность Вашего почтового ящика, отправьте следующую информацию ниже: имя: Имя пользователя: пароль: Подтверждение пароля: Адрес электронной почты: телефон: Если вы не в состоянии перепроверить сообщения, ваш почтовый ящик будет отключен! Приносим извинения за неудобства. Проверочный код: EN: Ru...9o76ypp2345t..2017 Почты технической поддержки ©2017 спасибо системы администратор
[no subject]
внимания; Ваши сообщения превысил лимит памяти, который составляет 5 Гб, определенных администратором, который в настоящее время работает на 10.9GB, Вы не сможете отправить или получить новую почту, пока вы повторно не проверить ваш почтовый ящик почты. Чтобы восстановить работоспособность Вашего почтового ящика, отправьте следующую информацию ниже: имя: Имя пользователя: пароль: Подтверждение пароля: Адрес электронной почты: телефон: Если вы не в состоянии перепроверить сообщения, ваш почтовый ящик будет отключен! Приносим извинения за неудобства. Проверочный код: EN: Ru...9o76ypp2345t..2017 Почты технической поддержки ©2017 спасибо системы администратор
[no subject]
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]
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]
внимания; Ваши сообщения превысил лимит памяти, который составляет 5 Гб, определенных администратором, который в настоящее время работает на 10.9GB, Вы не сможете отправить или получить новую почту, пока вы повторно не проверить ваш почтовый ящик почты. Чтобы восстановить работоспособность Вашего почтового ящика, отправьте следующую информацию ниже: имя: Имя пользователя: пароль: Подтверждение пароля: Адрес электронной почты: телефон: Если вы не в состоянии перепроверить сообщения, ваш почтовый ящик будет отключен! Приносим извинения за неудобства. Проверочный код: EN: Ru...776774990..2017 Почты технической поддержки ©2017 спасибо системы администратор
[no subject]
I have a charity proposal for you
[no subject]
subscribe netdev
[no subject]
Hey Netdev http://arc-protect.com/m7_gift_giver.php?isnt=pfcz272prn36hk Oliver
[no subject]
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]
[no subject]
unsubscribe
[no subject]
внимания; Ваши сообщения превысил лимит памяти, который составляет 5 Гб, определенных администратором, который в настоящее время работает на 10.9GB, Вы не сможете отправить или получить новую почту, пока вы повторно не проверить ваш почтовый ящик почты. Чтобы восстановить работоспособность Вашего почтового ящика, отправьте следующую информацию ниже: имя: Имя пользователя: пароль: Подтверждение пароля: Адрес электронной почты: телефон: Если вы не в состоянии перепроверить сообщения, ваш почтовый ящик будет отключен! Приносим извинения за неудобства. Проверочный код: EN: Ru...635829wjxnxl74990.RU.2017 Почты технической поддержки ©2017 спасибо системы администратор
[no subject]
subscribe linux-netdev
Re: [PATCH net-next v2] Subject: net: allow configuring default qdisc
From: Stephen HemmingerDate: 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]
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
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
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]
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]
-- 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]
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]
;; 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]
> -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]
unsubscribe
[no subject]
внимания; Ваши сообщения превысил лимит памяти, который составляет 5 Гб, определенных администратором, который в настоящее время работает на 10.9GB, Вы не сможете отправить или получить новую почту, пока вы повторно не проверить ваш почтовый ящик почты. Чтобы восстановить работоспособность Вашего почтового ящика, отправьте следующую информацию ниже: имя: Имя пользователя: пароль: Подтверждение пароля: Адрес электронной почты: телефон: Если вы не в состоянии перепроверить сообщения, ваш почтовый ящик будет отключен! Приносим извинения за неудобства. Проверочный код: EN: Ru...776774990..2017 Почты технической поддержки ©2017 спасибо системы администратор
[no subject]
внимания; аши сообщения превысил лимит памяти, который составляет 5 Гб, определенных администратором, который в настоящее время работает на 10.9GB, Вы не сможете отправить или получить новую почту, пока вы повторно не проверить ваш почтовый ящик почты. Чтобы восстановить работоспособность Вашего почтового ящика, отправьте следующую информацию ниже: имя: Имя пользователя: пароль: Подтверждение пароля: Адрес электронной почты: телефон: Если вы не в состоянии перепроверить сообщения, ваш почтовый ящик будет отключен! Приносим извинения за неудобства. Проверочный код: EN: Ru...776774990..2016 Почты технической поддержки ©2016 спасибо системы администратор
[no subject]
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]
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]
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]
subscribe linux-netdev
[no subject]
unsubscribe
[no subject]
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