* [PATCH] net: scm: Fix a possible sleep-in-atomic-context bug in scm_fp_copy()
From: Jia-Ju Bai @ 2018-09-01 10:00 UTC (permalink / raw)
To: davem, ktkhai, viro, adobriyan, dvlasenk, xiyou.wangcong
Cc: netdev, linux-kernel, Jia-Ju Bai
The kernel module may sleep with holding a spinlock.
The function call paths (from bottom to top) in Linux-4.16 are:
[FUNC] kmalloc(GFP_KERNEL)
net/core/scm.c, 85: kmalloc in scm_fp_copy
net/core/scm.c, 161: scm_fp_copy in __scm_send
./include/net/scm.h, 88: __scm_send in scm_send
net/unix/af_unix.c, 1600: scm_send in maybe_init_creds
net/unix/af_unix.c, 1983: maybe_init_creds in unix_stream_sendpage
net/unix/af_unix.c, 1973: spin_lock in unix_stream_sendpage
To fix this bug, GFP_KERNEL is replaced with GFP_ATOMIC.
This bug is found by my static analysis tool DSAC.
Signed-off-by: Jia-Ju Bai <baijiaju1990@gmail.com>
---
net/core/scm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/core/scm.c b/net/core/scm.c
index b1ff8a441748..49548f81c45b 100644
--- a/net/core/scm.c
+++ b/net/core/scm.c
@@ -82,7 +82,7 @@ static int scm_fp_copy(struct cmsghdr *cmsg, struct scm_fp_list **fplp)
if (!fpl)
{
- fpl = kmalloc(sizeof(struct scm_fp_list), GFP_KERNEL);
+ fpl = kmalloc(sizeof(struct scm_fp_list), GFP_ATOMIC);
if (!fpl)
return -ENOMEM;
*fplp = fpl;
--
2.17.0
^ permalink raw reply related
* Re: [Patch net-nnext] Revert "net: sched: act: add extack for lookup callback"
From: David Miller @ 2018-09-01 5:50 UTC (permalink / raw)
To: xiyou.wangcong; +Cc: netdev, aring
In-Reply-To: <20180829171536.23162-1-xiyou.wangcong@gmail.com>
From: Cong Wang <xiyou.wangcong@gmail.com>
Date: Wed, 29 Aug 2018 10:15:35 -0700
> This reverts commit 331a9295de23 ("net: sched: act: add extack for lookup callback").
>
> This extack is never used after 6 months... In fact, it can be just
> set in the caller, right after ->lookup().
>
> Cc: Alexander Aring <aring@mojatatu.com>
> Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH v2 3/6] net/wan/fsl_ucc_hdlc: Adding ARPHRD_ETHER
From: David Miller @ 2018-09-01 5:55 UTC (permalink / raw)
To: david.gounaris; +Cc: qiang.zhao, netdev, linuxppc-dev, robh+dt
In-Reply-To: <20180829131328.27901-4-david.gounaris@infinera.com>
From: David Gounaris <david.gounaris@infinera.com>
Date: Wed, 29 Aug 2018 15:13:25 +0200
> @@ -513,6 +517,8 @@ static int hdlc_rx_done(struct ucc_hdlc_private *priv, int rx_work_limit)
> break;
>
> case ARPHRD_PPP:
> + case ARPHRD_ETHER:
> +
Please don't add such an extraneous empty line.
Thanks.
^ permalink raw reply
* Re: [Patch net-nnext] net_sched: add missing tcf_lock for act_connmark
From: David Miller @ 2018-09-01 5:59 UTC (permalink / raw)
To: xiyou.wangcong; +Cc: netdev, vladbu
In-Reply-To: <20180829171536.23162-2-xiyou.wangcong@gmail.com>
From: Cong Wang <xiyou.wangcong@gmail.com>
Date: Wed, 29 Aug 2018 10:15:36 -0700
> According to the new locking rule, we have to take tcf_lock
> for both ->init() and ->dump(), as RTNL will be removed.
> However, it is missing for act_connmark.
>
> Cc: Vlad Buslov <vladbu@mellanox.com>
> Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH net] Revert "packet: switch kvzalloc to allocate memory"
From: David Miller @ 2018-09-01 6:01 UTC (permalink / raw)
To: edumazet; +Cc: netdev, eric.dumazet, zhangyu31, lirongqing
In-Reply-To: <20180829185012.143366-1-edumazet@google.com>
From: Eric Dumazet <edumazet@google.com>
Date: Wed, 29 Aug 2018 11:50:12 -0700
> This reverts commit 71e41286203c017d24f041a7cd71abea7ca7b1e0.
>
> mmap()/munmap() can not be backed by kmalloced pages :
>
> We fault in :
>
> VM_BUG_ON_PAGE(PageSlab(page), page);
>
> unmap_single_vma+0x8a/0x110
> unmap_vmas+0x4b/0x90
> unmap_region+0xc9/0x140
> do_munmap+0x274/0x360
> vm_munmap+0x81/0xc0
> SyS_munmap+0x2b/0x40
> do_syscall_64+0x13e/0x1c0
> entry_SYSCALL_64_after_hwframe+0x42/0xb7
>
> Fixes: 71e41286203c ("packet: switch kvzalloc to allocate memory")
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> Reported-by: John Sperbeck <jsperbeck@google.com>
> Bisected-by: John Sperbeck <jsperbeck@google.com>
Oops, applied, thanks Eric.
^ permalink raw reply
* Re: [PATCH net] nfp: wait for posted reconfigs when disabling the device
From: David Miller @ 2018-09-01 6:03 UTC (permalink / raw)
To: jakub.kicinski; +Cc: netdev, oss-drivers
In-Reply-To: <20180829194608.25454-1-jakub.kicinski@netronome.com>
From: Jakub Kicinski <jakub.kicinski@netronome.com>
Date: Wed, 29 Aug 2018 12:46:08 -0700
> To avoid leaking a running timer we need to wait for the
> posted reconfigs after netdev is unregistered. In common
> case the process of deinitializing the device will perform
> synchronous reconfigs which wait for posted requests, but
> especially with VXLAN ports being actively added and removed
> there can be a race condition leaving a timer running after
> adapter structure is freed leading to a crash.
>
> Add an explicit flush after deregistering and for a good
> measure a warning to check if timer is running just before
> structures are freed.
>
> Fixes: 3d780b926a12 ("nfp: add async reconfiguration mechanism")
> Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com>
> Reviewed-by: Dirk van der Merwe <dirk.vandermerwe@netronome.com>
Applied and queued up for -stable.
^ permalink raw reply
* Re: [PATCH net-next] tcp: change IPv6 flow-label upon receiving spurious retransmission
From: David Miller @ 2018-09-01 6:03 UTC (permalink / raw)
To: ycheng; +Cc: edumazet, netdev, ncardwell
In-Reply-To: <20180829215356.235336-1-ycheng@google.com>
From: Yuchung Cheng <ycheng@google.com>
Date: Wed, 29 Aug 2018 14:53:56 -0700
> Currently a Linux IPv6 TCP sender will change the flow label upon
> timeouts to potentially steer away from a data path that has gone
> bad. However this does not help if the problem is on the ACK path
> and the data path is healthy. In this case the receiver is likely
> to receive repeated spurious retransmission because the sender
> couldn't get the ACKs in time and has recurring timeouts.
>
> This patch adds another feature to mitigate this problem. It
> leverages the DSACK states in the receiver to change the flow
> label of the ACKs to speculatively re-route the ACK packets.
> In order to allow triggering on the second consecutive spurious
> RTO, the receiver changes the flow label upon sending a second
> consecutive DSACK for a sequence number below RCV.NXT.
>
> Signed-off-by: Yuchung Cheng <ycheng@google.com>
> Signed-off-by: Neal Cardwell <ncardwell@google.com>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next] net/ipv4: Add extack message that dev is required for ONLINK
From: David Miller @ 2018-09-01 6:04 UTC (permalink / raw)
To: dsahern; +Cc: netdev, dsahern
In-Reply-To: <20180829235327.18307-1-dsahern@kernel.org>
From: dsahern@kernel.org
Date: Wed, 29 Aug 2018 16:53:27 -0700
> From: David Ahern <dsahern@gmail.com>
>
> Make IPv4 consistent with IPv6 and return an extack message that the
> ONLINK flag requires a nexthop device.
>
> Signed-off-by: David Ahern <dsahern@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next] net/ipv6: Do not reset nl_net in ip6_route_info_create
From: David Miller @ 2018-09-01 6:05 UTC (permalink / raw)
To: dsahern; +Cc: netdev, dsahern
In-Reply-To: <20180829235401.18367-1-dsahern@kernel.org>
From: dsahern@kernel.org
Date: Wed, 29 Aug 2018 16:54:01 -0700
> From: David Ahern <dsahern@gmail.com>
>
> nl_net is set on entry to ip6_route_info_create. Only devices
> within that namespace are considered so no need to reset it
> before returning.
>
> Signed-off-by: David Ahern <dsahern@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next] net: dsa: mv88e6xxx: Share main switch IRQ
From: David Miller @ 2018-09-01 6:05 UTC (permalink / raw)
To: marek.behun; +Cc: netdev
In-Reply-To: <20180830001350.10062-1-marek.behun@nic.cz>
From: Marek Behún <marek.behun@nic.cz>
Date: Thu, 30 Aug 2018 02:13:50 +0200
> On some boards the interrupt can be shared between multiple devices.
> For example on Turris Mox the interrupt is shared between all switches.
>
> Signed-off-by: Marek Behun <marek.behun@nic.cz>
Applied.
^ permalink raw reply
* Re: [PATCH net] tcp: do not restart timewait timer on rst reception
From: David Miller @ 2018-09-01 6:11 UTC (permalink / raw)
To: fw; +Cc: netdev, edumazet
In-Reply-To: <20180830122429.3546-1-fw@strlen.de>
From: Florian Westphal <fw@strlen.de>
Date: Thu, 30 Aug 2018 14:24:29 +0200
> RFC 1337 says:
> ''Ignore RST segments in TIME-WAIT state.
> If the 2 minute MSL is enforced, this fix avoids all three hazards.''
>
> So with net.ipv4.tcp_rfc1337=1, expected behaviour is to have TIME-WAIT sk
> expire rather than removing it instantly when a reset is received.
>
> However, Linux will also re-start the TIME-WAIT timer.
>
> This causes connect to fail when tying to re-use ports or very long
> delays (until syn retry interval exceeds MSL).
...
> Without this patch, 'ss' shows restarts of tw timer and last packet is
> thus just another pure ack, more than one minute later.
>
> This restores the original code from commit 283fd6cf0be690a83
> ("Merge in ANK networking jumbo patch") in netdev-vger-cvs.git .
>
> For some reason the else branch was removed/lost in 1f28b683339f7
> ("Merge in TCP/UDP optimizations and [..]") and timer restart became
> unconditional.
>
> Reported-by: Michal Tesar <mtesar@redhat.com>
> Signed-off-by: Florian Westphal <fw@strlen.de>
Applied and thanks for the packet drill test case :-)
^ permalink raw reply
* Re: [PATCH v1] bridge: Switch to bitmap_zalloc()
From: David Miller @ 2018-09-01 6:13 UTC (permalink / raw)
To: andriy.shevchenko; +Cc: stephen, bridge, netdev
In-Reply-To: <20180830103318.60804-1-andriy.shevchenko@linux.intel.com>
From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Date: Thu, 30 Aug 2018 13:33:18 +0300
> Switch to bitmap_zalloc() to show clearly what we are allocating.
> Besides that it returns pointer of bitmap type instead of opaque void *.
>
> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Applied to net-next, thanks.
^ permalink raw reply
* Re: [PATCH net 1/2] selftests: pmtu: maximum MTU for vti4 is 2^16-1-20
From: David Miller @ 2018-09-01 6:14 UTC (permalink / raw)
To: sd; +Cc: netdev, sbrivio, nicolas.dichtel
In-Reply-To: <1e62875c4c72b38b17f6c73f9654696b14fb3166.1535636302.git.sd@queasysnail.net>
From: Sabrina Dubroca <sd@queasysnail.net>
Date: Thu, 30 Aug 2018 16:01:17 +0200
> Since commit 82612de1c98e ("ip_tunnel: restore binding to ifaces with a
> large mtu"), the maximum MTU for vti4 is based on IP_MAX_MTU instead of
> the mysterious constant 0xFFF8. This makes this selftest fail.
>
> Fixes: 82612de1c98e ("ip_tunnel: restore binding to ifaces with a large mtu")
> Signed-off-by: Sabrina Dubroca <sd@queasysnail.net>
> Acked-by: Stefano Brivio <sbrivio@redhat.com>
Applied.
^ permalink raw reply
* Re: [PATCH net 2/2] selftests: pmtu: detect correct binary to ping ipv6 addresses
From: David Miller @ 2018-09-01 6:14 UTC (permalink / raw)
To: sd; +Cc: netdev, sbrivio
In-Reply-To: <1dde5f922552343009b6c29f637f6155cea08520.1535636302.git.sd@queasysnail.net>
From: Sabrina Dubroca <sd@queasysnail.net>
Date: Thu, 30 Aug 2018 16:01:18 +0200
> Some systems don't have the ping6 binary anymore, and use ping for
> everything. Detect the absence of ping6 and try to use ping instead.
>
> Fixes: d1f1b9cbf34c ("selftests: net: Introduce first PMTU test")
> Signed-off-by: Sabrina Dubroca <sd@queasysnail.net>
> Acked-by: Stefano Brivio <sbrivio@redhat.com>
Applied.
^ permalink raw reply
* Re: [PATCH net] ibmvnic: Include missing return code checks in reset function
From: David Miller @ 2018-09-01 6:16 UTC (permalink / raw)
To: tlfalcon; +Cc: netdev
In-Reply-To: <1535653193-15778-1-git-send-email-tlfalcon@linux.vnet.ibm.com>
From: Thomas Falcon <tlfalcon@linux.vnet.ibm.com>
Date: Thu, 30 Aug 2018 13:19:53 -0500
> Check the return codes of these functions and halt reset
> in case of failure. The driver will remain in a dormant state
> until the next reset event, when device initialization will be
> re-attempted.
>
> Signed-off-by: Thomas Falcon <tlfalcon@linux.vnet.ibm.com>
Applied.
^ permalink raw reply
* [PATCH] net: ipv6: route: Fix a sleep-in-atomic-context bug in ip6_convert_metrics()
From: Jia-Ju Bai @ 2018-09-01 11:19 UTC (permalink / raw)
To: davem, kuznet, yoshfuji; +Cc: netdev, linux-kernel, Jia-Ju Bai
The kernel module may sleep with holding a spinlock.
The function call paths (from bottom to top) in Linux-4.16 are:
[FUNC] kzalloc(GFP_KERNEL)
net/ipv6/route.c, 2430:
kzalloc in ip6_convert_metrics
net/ipv6/route.c, 2890:
ip6_convert_metrics in ip6_route_add
net/ipv6/addrconf.c, 2322:
ip6_route_add in addrconf_prefix_route
net/ipv6/addrconf.c, 3331:
addrconf_prefix_route in fixup_permanent_addr
net/ipv6/addrconf.c, 3354:
fixup_permanent_addr in addrconf_permanent_addr
net/ipv6/addrconf.c, 3358:
_raw_write_lock_bh in addrconf_permanent_addr
To fix this bug, GFP_KERNEL is replaced with GFP_ATOMIC.
This bug is found by my static analysis tool DSAC.
Signed-off-by: Jia-Ju Bai <baijiaju1990@gmail.com>
---
net/ipv6/route.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/ipv6/route.c b/net/ipv6/route.c
index ec18b3ce8b6d..d15e72def7c1 100644
--- a/net/ipv6/route.c
+++ b/net/ipv6/route.c
@@ -2742,7 +2742,7 @@ static int ip6_convert_metrics(struct net *net, struct fib6_info *rt,
if (!cfg->fc_mx)
return 0;
- p = kzalloc(sizeof(*rt->fib6_metrics), GFP_KERNEL);
+ p = kzalloc(sizeof(*rt->fib6_metrics), GFP_ATOMIC);
if (unlikely(!p))
return -ENOMEM;
--
2.17.0
^ permalink raw reply related
* [PATCH] isdn: mISDN: layer2: Fix a sleep-in-atomic-context bug in create_l2()
From: Jia-Ju Bai @ 2018-09-01 11:57 UTC (permalink / raw)
To: isdn; +Cc: netdev, linux-kernel, Jia-Ju Bai
The kernel module may sleep with holding a spinlock.
The function call paths (from bottom to top) in Linux-4.16 are:
[FUNC] kzalloc(GFP_KERNEL)
drivers/isdn/mISDN/layer2.c, 2126: kzalloc in create_l2
drivers/isdn/mISDN/tei.c, 1054: create_l2 in create_teimgr
drivers/isdn/mISDN/tei.c, 1278: create_teimgr in mgr_ctrl
drivers/isdn/mISDN/tei.c, 1048: [FUNC_PTR]mgr_ctrl in create_teimgr
drivers/isdn/mISDN/tei.c, 1045: _raw_read_lock_irqsave in create_teimgr
Note that [FUNC_PTR] means a function pointer call is used.
To fix this bug, GFP_KERNEL is replaced with GFP_ATOMIC.
This bug is found by my static analysis tool DSAC
Signed-off-by: Jia-Ju Bai <baijiaju1990@gmail.com>
---
drivers/isdn/mISDN/layer2.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/isdn/mISDN/layer2.c b/drivers/isdn/mISDN/layer2.c
index 9ff0903a0e89..383f31ae4b92 100644
--- a/drivers/isdn/mISDN/layer2.c
+++ b/drivers/isdn/mISDN/layer2.c
@@ -2123,7 +2123,7 @@ create_l2(struct mISDNchannel *ch, u_int protocol, u_long options, int tei,
struct layer2 *l2;
struct channel_req rq;
- l2 = kzalloc(sizeof(struct layer2), GFP_KERNEL);
+ l2 = kzalloc(sizeof(struct layer2), GFP_ATOMIC);
if (!l2) {
printk(KERN_ERR "kzalloc layer2 failed\n");
return NULL;
--
2.17.0
^ permalink raw reply related
* [PATCH] isdn: mISDN: tei: Fix a sleep-in-atomic-context bug in create_teimgr()
From: Jia-Ju Bai @ 2018-09-01 12:00 UTC (permalink / raw)
To: isdn; +Cc: netdev, linux-kernel, Jia-Ju Bai
The kernel module may sleep with holding a spinlock.
The function call paths (from bottom to top) in Linux-4.16 are:
[FUNC] kzalloc(GFP_KERNEL)
drivers/isdn/mISDN/tei.c, 1058: kzalloc in create_teimgr
drivers/isdn/mISDN/tei.c, 1278: create_teimgr in mgr_ctrl
drivers/isdn/mISDN/tei.c, 1048: [FUNC_PTR]mgr_ctrl in create_teimgr
drivers/isdn/mISDN/tei.c, 1045: _raw_read_lock_irqsave in create_teimgr
Note that [FUNC_PTR] means a function pointer call is used.
To fix this bug, GFP_KERNEL is replaced with GFP_ATOMIC.
This bug is found by my static analysis tool DSAC.
Signed-off-by: Jia-Ju Bai <baijiaju1990@gmail.com>
---
drivers/isdn/mISDN/tei.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/isdn/mISDN/tei.c b/drivers/isdn/mISDN/tei.c
index 12d9e5f4beb1..6d95ee639fdb 100644
--- a/drivers/isdn/mISDN/tei.c
+++ b/drivers/isdn/mISDN/tei.c
@@ -1055,7 +1055,7 @@ create_teimgr(struct manager *mgr, struct channel_req *crq)
crq->adr.tei, crq->adr.sapi);
if (!l2)
return -ENOMEM;
- l2->tm = kzalloc(sizeof(struct teimgr), GFP_KERNEL);
+ l2->tm = kzalloc(sizeof(struct teimgr), GFP_ATOMIC);
if (!l2->tm) {
kfree(l2);
printk(KERN_ERR "kmalloc teimgr failed\n");
--
2.17.0
^ permalink raw reply related
* [PATCH] net: cadence: Fix a sleep-in-atomic-context bug in macb_halt_tx()
From: Jia-Ju Bai @ 2018-09-01 12:11 UTC (permalink / raw)
To: nicolas.ferre, davem; +Cc: netdev, linux-kernel, Jia-Ju Bai
The kernel module may sleep with holding a spinlock.
The function call paths (from bottom to top) in Linux-4.16 are:
[FUNC] usleep_range
drivers/net/ethernet/cadence/macb_main.c, 648:
usleep_range in macb_halt_tx
drivers/net/ethernet/cadence/macb_main.c, 730:
macb_halt_tx in macb_tx_error_task
drivers/net/ethernet/cadence/macb_main.c, 721:
_raw_spin_lock_irqsave in macb_tx_error_task
To fix this bug, usleep_range() is replaced with udelay().
This bug is found by my static analysis tool DSAC.
Signed-off-by: Jia-Ju Bai <baijiaju1990@gmail.com>
---
drivers/net/ethernet/cadence/macb_main.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/cadence/macb_main.c b/drivers/net/ethernet/cadence/macb_main.c
index a6c911bb5ce2..3dcc31cd4261 100644
--- a/drivers/net/ethernet/cadence/macb_main.c
+++ b/drivers/net/ethernet/cadence/macb_main.c
@@ -641,7 +641,7 @@ static int macb_halt_tx(struct macb *bp)
if (!(status & MACB_BIT(TGO)))
return 0;
- usleep_range(10, 250);
+ udelay(250);
} while (time_before(halt_time, timeout));
return -ETIMEDOUT;
--
2.17.0
^ permalink raw reply related
* [PATCH net-next v3] tcp: propagate gso_segs to the new skb built in tcp collapse
From: Yafang Shao @ 2018-09-01 12:21 UTC (permalink / raw)
To: edumazet, davem; +Cc: netdev, linux-kernel, Yafang Shao
The gso_segs of the new built SKB in tcp collapse is inited to 0,
that makes us hard to know the accurate segments number of this new SKB.
We'd better propagate the gso_segs of the collapsed SKB to the new built
one, so when this SKB is dropped (for example when doing tcp prune) the
sk_drops will be added to the correct value.
If the collapsed SKB is fully copied to the new built one, we just add its
gso_segs to the new SKB.
While if the collapsed SKB is partially copied to the new built SKB,
we have to calculate how many segments are copied.
And when do the calculation we must make sure one SKB holds the same
gso_segs.
Furthemore, we have to reset the gso_segs of this SKB if is is partially
copied, so in the next round when the left segments are copied it could
propagate the correct value.
The gso_size will never exceed 65536 as the max size of the new built SKB
is 4K.
Signed-off-by: Yafang Shao <laoar.shao@gmail.com>
---
net/ipv4/tcp_input.c | 17 +++++++++++++++--
1 file changed, 15 insertions(+), 2 deletions(-)
diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
index 62508a2..6dc8e2f 100644
--- a/net/ipv4/tcp_input.c
+++ b/net/ipv4/tcp_input.c
@@ -4910,6 +4910,7 @@ void tcp_rbtree_insert(struct rb_root *root, struct sk_buff *skb)
while (before(start, end)) {
int copy = min_t(int, SKB_MAX_ORDER(0, 0), end - start);
struct sk_buff *nskb;
+ int len = copy;
nskb = alloc_skb(copy, GFP_ATOMIC);
if (!nskb)
@@ -4928,12 +4929,24 @@ void tcp_rbtree_insert(struct rb_root *root, struct sk_buff *skb)
/* Copy data, releasing collapsed skbs. */
while (copy > 0) {
- int offset = start - TCP_SKB_CB(skb)->seq;
int size = TCP_SKB_CB(skb)->end_seq - start;
+ int offset = start - TCP_SKB_CB(skb)->seq;
BUG_ON(offset < 0);
if (size > 0) {
- size = min(copy, size);
+ if (copy >= size) {
+ skb_shinfo(nskb)->gso_segs +=
+ max_t(u16, 1, skb_shinfo(skb)->gso_segs);
+ } else {
+ skb_shinfo(nskb)->gso_size =
+ skb_shinfo(skb)->gso_size;
+ skb_shinfo(nskb)->gso_segs =
+ DIV_ROUND_UP(len, skb_shinfo(nskb)->gso_size);
+ skb_shinfo(skb)->gso_segs =
+ DIV_ROUND_UP(size - copy, skb_shinfo(skb)->gso_size);
+ size = copy;
+ }
+
if (skb_copy_bits(skb, offset, skb_put(nskb, size), size))
BUG();
TCP_SKB_CB(nskb)->end_seq += size;
--
1.8.3.1
^ permalink raw reply related
* [PATCH net-next] tcp: remove useless add operation when init sysctl_max_tw_buckets
From: Yafang Shao @ 2018-09-01 12:21 UTC (permalink / raw)
To: edumazet, davem; +Cc: netdev, linux-kernel, Yafang Shao
In-Reply-To: <1535804465-11795-1-git-send-email-laoar.shao@gmail.com>
cp_hashinfo.ehash_mask is always an odd number, which is set in function
alloc_large_system_hash(). See bellow,
if (_hash_mask)
*_hash_mask = (1 << log2qty) - 1; <<< always odd number
Hence the local variable 'cnt' is a even number, as a result of that it is
no difference to do the incrementation here.
Signed-off-by: Yafang Shao <laoar.shao@gmail.com>
---
net/ipv4/tcp_ipv4.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/ipv4/tcp_ipv4.c b/net/ipv4/tcp_ipv4.c
index 44c09ed..09547ef 100644
--- a/net/ipv4/tcp_ipv4.c
+++ b/net/ipv4/tcp_ipv4.c
@@ -2549,7 +2549,7 @@ static int __net_init tcp_sk_init(struct net *net)
net->ipv4.sysctl_tcp_tw_reuse = 2;
cnt = tcp_hashinfo.ehash_mask + 1;
- net->ipv4.tcp_death_row.sysctl_max_tw_buckets = (cnt + 1) / 2;
+ net->ipv4.tcp_death_row.sysctl_max_tw_buckets = cnt / 2;
net->ipv4.tcp_death_row.hashinfo = &tcp_hashinfo;
net->ipv4.sysctl_max_syn_backlog = max(128, cnt / 256);
--
1.8.3.1
^ permalink raw reply related
* Re: [PATCH v2 1/6] net/wan/fsl_ucc_hdlc: allow ucc index up to 7
From: christophe leroy @ 2018-09-01 7:58 UTC (permalink / raw)
To: David Gounaris, qiang.zhao, netdev, linuxppc-dev, robh+dt
In-Reply-To: <20180829131328.27901-2-david.gounaris@infinera.com>
Le 29/08/2018 à 15:13, David Gounaris a écrit :
> There is a need to allow higher indexes to be
> able to support MPC83xx platforms. (UCC1-UCC8)
>
> Signed-off-by: David Gounaris <david.gounaris@infinera.com>
> ---
> drivers/net/wan/fsl_ucc_hdlc.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/wan/fsl_ucc_hdlc.c b/drivers/net/wan/fsl_ucc_hdlc.c
> index 33df76405b86..5cf6dcba039c 100644
> --- a/drivers/net/wan/fsl_ucc_hdlc.c
> +++ b/drivers/net/wan/fsl_ucc_hdlc.c
> @@ -1016,7 +1016,7 @@ static int ucc_hdlc_probe(struct platform_device *pdev)
> }
>
> ucc_num = val - 1;
> - if ((ucc_num > 3) || (ucc_num < 0)) {
> + if ((ucc_num > UCC_MAX_NUM - 1) || (ucc_num < 0)) {
CHECK:UNNECESSARY_PARENTHESES: Unnecessary parentheses around 'ucc_num < 0'
#23: FILE: drivers/net/wan/fsl_ucc_hdlc.c:1018:
+ if ((ucc_num > UCC_MAX_NUM - 1) || (ucc_num < 0)) {
> dev_err(&pdev->dev, ": Invalid UCC num\n");
> return -EINVAL;
> }
>
---
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel antivirus Avast.
https://www.avast.com/antivirus
^ permalink raw reply
* Re: [PATCH v2 3/6] net/wan/fsl_ucc_hdlc: Adding ARPHRD_ETHER
From: christophe leroy @ 2018-09-01 8:05 UTC (permalink / raw)
To: David Gounaris, qiang.zhao, netdev, linuxppc-dev, robh+dt
In-Reply-To: <20180829131328.27901-4-david.gounaris@infinera.com>
Le 29/08/2018 à 15:13, David Gounaris a écrit :
> This patch is to avoid discarding ethernet
> packets when using HDLC_ETH protocol.
>
> Signed-off-by: David Gounaris <david.gounaris@infinera.com>
> ---
> drivers/net/wan/fsl_ucc_hdlc.c | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/drivers/net/wan/fsl_ucc_hdlc.c b/drivers/net/wan/fsl_ucc_hdlc.c
> index c8e526bf1130..0f703d7be5e0 100644
> --- a/drivers/net/wan/fsl_ucc_hdlc.c
> +++ b/drivers/net/wan/fsl_ucc_hdlc.c
> @@ -376,6 +376,10 @@ static netdev_tx_t ucc_hdlc_tx(struct sk_buff *skb, struct net_device *dev)
> dev->stats.tx_bytes += skb->len;
> break;
>
> + case ARPHRD_ETHER:
> + dev->stats.tx_bytes += skb->len;
> + break;
> +
> default:
> dev->stats.tx_dropped++;
> dev_kfree_skb(skb);
> @@ -513,6 +517,8 @@ static int hdlc_rx_done(struct ucc_hdlc_private *priv, int rx_work_limit)
> break;
>
> case ARPHRD_PPP:
> + case ARPHRD_ETHER:
> +
ERROR:TRAILING_WHITESPACE: trailing whitespace
#34: FILE: drivers/net/wan/fsl_ucc_hdlc.c:520:
+^I^I^I$
Note that 'git show' would show it to you in red background so you
shouldn't miss it.
And this additional blank line is unnecessary.
> length -= HDLC_CRC_SIZE;
>
> skb = dev_alloc_skb(length);
>
---
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel antivirus Avast.
https://www.avast.com/antivirus
^ permalink raw reply
* Re: [PATCH v2 4/6] net/wan/fsl_ucc_hdlc: hmask
From: christophe leroy @ 2018-09-01 8:06 UTC (permalink / raw)
To: David Gounaris, qiang.zhao, netdev, linuxppc-dev, robh+dt
In-Reply-To: <20180829131328.27901-5-david.gounaris@infinera.com>
Le 29/08/2018 à 15:13, David Gounaris a écrit :
> Ability to set hmask in the device-tree,
> which can be used to change address
> filtering of packets.
>
> Signed-off-by: David Gounaris <david.gounaris@infinera.com>
> ---
> Documentation/devicetree/bindings/soc/fsl/cpm_qe/network.txt | 6 ++++++
> drivers/net/wan/fsl_ucc_hdlc.c | 5 ++++-
> drivers/net/wan/fsl_ucc_hdlc.h | 1 +
> 3 files changed, 11 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/soc/fsl/cpm_qe/network.txt b/Documentation/devicetree/bindings/soc/fsl/cpm_qe/network.txt
> index 03c741602c6d..6d2dd8a31482 100644
> --- a/Documentation/devicetree/bindings/soc/fsl/cpm_qe/network.txt
> +++ b/Documentation/devicetree/bindings/soc/fsl/cpm_qe/network.txt
> @@ -98,6 +98,12 @@ The property below is dependent on fsl,tdm-interface:
> usage: optional for tdm interface
> value type: <empty>
> Definition : Internal loopback connecting on TDM layer.
> +- fsl,hmask
> + usage: optional
> + Value type: <u16>
> + Definition: HDLC address recognition. Set to zero to disable
> + address filtering of packets:
> + fsl,hmask = /bits/ 16 <0x0000>;
>
> Example for tdm interface:
>
> diff --git a/drivers/net/wan/fsl_ucc_hdlc.c b/drivers/net/wan/fsl_ucc_hdlc.c
> index 0f703d7be5e0..be5b0096af3b 100644
> --- a/drivers/net/wan/fsl_ucc_hdlc.c
> +++ b/drivers/net/wan/fsl_ucc_hdlc.c
> @@ -263,7 +263,7 @@ static int uhdlc_init(struct ucc_hdlc_private *priv)
> iowrite16be(MAX_FRAME_LENGTH, &priv->ucc_pram->mflr);
> iowrite16be(DEFAULT_RFTHR, &priv->ucc_pram->rfthr);
> iowrite16be(DEFAULT_RFTHR, &priv->ucc_pram->rfcnt);
> - iowrite16be(DEFAULT_ADDR_MASK, &priv->ucc_pram->hmask);
> + iowrite16be(priv->hmask, &priv->ucc_pram->hmask);
> iowrite16be(DEFAULT_HDLC_ADDR, &priv->ucc_pram->haddr1);
> iowrite16be(DEFAULT_HDLC_ADDR, &priv->ucc_pram->haddr2);
> iowrite16be(DEFAULT_HDLC_ADDR, &priv->ucc_pram->haddr3);
> @@ -1097,6 +1097,9 @@ static int ucc_hdlc_probe(struct platform_device *pdev)
> if (ret)
> goto free_utdm;
> }
> +
ERROR:TRAILING_WHITESPACE: trailing whitespace
#51: FILE: drivers/net/wan/fsl_ucc_hdlc.c:1099:
+^I$
'git show' (or git log -p) would show it to you in red background.
> + if (of_property_read_u16(np, "fsl,hmask", &uhdlc_priv->hmask))
> + uhdlc_priv->hmask = DEFAULT_ADDR_MASK;
>
> ret = uhdlc_init(uhdlc_priv);
> if (ret) {
> diff --git a/drivers/net/wan/fsl_ucc_hdlc.h b/drivers/net/wan/fsl_ucc_hdlc.h
> index c21134c1f180..b99fa2f1cd99 100644
> --- a/drivers/net/wan/fsl_ucc_hdlc.h
> +++ b/drivers/net/wan/fsl_ucc_hdlc.h
> @@ -106,6 +106,7 @@ struct ucc_hdlc_private {
>
> unsigned short encoding;
> unsigned short parity;
> + unsigned short hmask;
> u32 clocking;
> spinlock_t lock; /* lock for Tx BD and Tx buffer */
> #ifdef CONFIG_PM
>
---
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel antivirus Avast.
https://www.avast.com/antivirus
^ permalink raw reply
* Re: [PATCH v2 2/6] net/wan/fsl_ucc_hdlc: allow PARITY_CRC16_PR0_CCITT parity
From: christophe leroy @ 2018-09-01 8:03 UTC (permalink / raw)
To: David Gounaris, qiang.zhao, netdev, linuxppc-dev, robh+dt
In-Reply-To: <20180829131328.27901-3-david.gounaris@infinera.com>
Le 29/08/2018 à 15:13, David Gounaris a écrit :
> Signed-off-by: David Gounaris <david.gounaris@infinera.com>
> ---
> drivers/net/wan/fsl_ucc_hdlc.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/wan/fsl_ucc_hdlc.c b/drivers/net/wan/fsl_ucc_hdlc.c
> index 5cf6dcba039c..c8e526bf1130 100644
> --- a/drivers/net/wan/fsl_ucc_hdlc.c
> +++ b/drivers/net/wan/fsl_ucc_hdlc.c
> @@ -781,7 +781,8 @@ static int ucc_hdlc_attach(struct net_device *dev, unsigned short encoding,
>
> if (parity != PARITY_NONE &&
> parity != PARITY_CRC32_PR1_CCITT &&
> - parity != PARITY_CRC16_PR1_CCITT)
> + parity != PARITY_CRC16_PR1_CCITT &&
> + parity != PARITY_CRC16_PR0_CCITT)
ERROR:TRAILING_WHITESPACE: trailing whitespace
#20: FILE: drivers/net/wan/fsl_ucc_hdlc.c:783:
+^I parity != PARITY_CRC16_PR1_CCITT && $
Also, you could have left the line 'parity != PARITY_CRC16_PR1_CCITT)'
as is and just have added 'parity != PARITY_CRC16_PR0_CCITT &&' on the
previous line, would make more sense to have PR0 before PR1, and instead
of having 2+1- you would only have 1+
> return -EINVAL;
>
> priv->encoding = encoding;
>
---
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel antivirus Avast.
https://www.avast.com/antivirus
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox