Re: linux-next: build failure after merge of the net-next tree

On Wed, 5 Aug 2020 22:31:21 +1000 Stephen Rothwell wrote: > Hi all, > > After merging the net-next tree, today's linux-next build (s390 defconfig) > failed like this: > > net/ipv4/ip_tunnel_core.c:335:2: error: implicit declaration of function > 'csum_ipv6_magic'

Re: linux-next: build failure after merge of the net-next tree

On Wed, 5 Aug 2020 15:21:44 +0200 Heiko Carstens wrote: > On Wed, Aug 05, 2020 at 03:06:27PM +0200, Stefano Brivio wrote: > > On Wed, 5 Aug 2020 22:31:21 +1000 > > Stephen Rothwell wrote: > > > > > Hi all, > > > > > > After merging the net-nex

Re: [PATCH net-next v2 2/6] tunnels: PMTU discovery support for directly bridged IP packets

Hi Naresh, On Wed, 5 Aug 2020 22:24:03 +0530 Naresh Kamboju wrote: > On Tue, 4 Aug 2020 at 11:24, Stefano Brivio wrote: > > > > + icmp6h->icmp6_cksum = csum_ipv6_magic(>saddr, >daddr, > > len, > > + IPPROTO_

[PATCH RESEND net-next] ip_tunnel_core: Fix build for archs without _HAVE_ARCH_IPV6_CSUM

-by: Stephen Rothwell Fixes: 4cb47a8644cc ("tunnels: PMTU discovery support for directly bridged IP packets") Signed-off-by: Stefano Brivio --- I'm submitting this for net-next despite the fact it's closed, as the offending code isn't merged to net.git yet. Should I rather submit this to...

[PATCH net-next] ip_tunnel_core: Fix build for archs without _HAVE_ARCH_IPV6_CSUM

-by: Stephen Rothwell Fixes: 4cb47a8644cc ("tunnels: PMTU discovery support for directly bridged IP packets") Signed-off-by: Stefano Brivio --- I'm submitting this for net-next despite the fact it's closed, as the offending code isn't merged to net.git yet. Should I rather submit this to...

Re: [PATCH 2/2] bitmap: Add test for bitmap_cut()

On Mon, 15 Jun 2020 14:43:53 +0300 Andy Shevchenko wrote: > On Mon, Jun 15, 2020 at 01:08:25PM +0200, Stefano Brivio wrote: > > > > [...] > > > > By the way, tests for 'parse', 'parse_user' and 'parselist' report > > issues: > > I believe this

Re: [PATCH 2/2] bitmap: Add test for bitmap_cut()

On Mon, 15 Jun 2020 12:46:16 +0300 Andy Shevchenko wrote: > On Mon, Jun 15, 2020 at 12:41:55PM +0300, Andy Shevchenko wrote: > > On Sun, Jun 14, 2020 at 07:40:54PM +0200, Stefano Brivio wrote: > > > Inspired by an original patch from Yury Norov: introduce a test fo

Re: Good idea to rename files in include/uapi/ ?

On Sun, 14 Jun 2020 21:41:17 +0200 "Alexander A. Klimov" wrote: > Hello there! > > At the moment one can't checkout a clean working directory w/o any > changed files on a case-insensitive FS as the following file names have > lower-case duplicates: They are not duplicates: matching

[PATCH 1/2] bitmap: Fix bitmap_cut() for partial overlapping case

overlapping src and dst. Reported-by: Yury Norov Fixes: 2092767168f0 ("bitmap: Introduce bitmap_cut(): cut bits and shift remaining") Signed-off-by: Stefano Brivio --- v2: No changes lib/bitmap.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/lib/bitmap.c b/li

[PATCH 2/2] bitmap: Add test for bitmap_cut()

Inspired by an original patch from Yury Norov: introduce a test for bitmap_cut() that also makes sure functionality is as described for partially overlapping src and dst. Signed-off-by: Stefano Brivio --- v2: - use expect_eq_bitmap() instead of open coding result check (Andy Shevchenko

[PATCH 0/2] lib: Fix bitmap_cut() for overlaps, add test

stack overflow Stefano Brivio (2): bitmap: Fix bitmap_cut() for partial overlapping case bitmap: Add test for bitmap_cut() lib/bitmap.c | 4 ++-- lib/test_bitmap.c | 58 +++ 2 files changed, 60 insertions(+), 2 deletions(-) -- 2.27.0

Re: [PATCH 2/2] lib: Add test for bitmap_cut()

On Mon, 8 Jun 2020 14:31:02 +0300 Andy Shevchenko wrote: > On Mon, Jun 8, 2020 at 1:29 PM Stefano Brivio wrote: > > On Mon, 8 Jun 2020 13:12:14 +0300 > > Andy Shevchenko wrote: > > > On Mon, Jun 08, 2020 at 11:13:29AM +0200, Stefano Brivio wrote: > > > >

Re: [PATCH 2/2] lib: Add test for bitmap_cut()

On Mon, 8 Jun 2020 13:12:14 +0300 Andy Shevchenko wrote: > On Mon, Jun 08, 2020 at 11:13:29AM +0200, Stefano Brivio wrote: > > Based on an original patch by Yury Norov: introduce a test for > > bitmap_cut() that also makes sure functionality is as described for > > part

[PATCH 1/2] lib: Fix bitmap_cut() for partial overlapping case

overlapping src and dst. Reported-by: Yury Norov Fixes: 2092767168f0 ("bitmap: Introduce bitmap_cut(): cut bits and shift remaining") Signed-off-by: Stefano Brivio --- lib/bitmap.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/lib/bitmap.c b/lib/bitmap.c index 89

[PATCH 2/2] lib: Add test for bitmap_cut()

Based on an original patch by Yury Norov: introduce a test for bitmap_cut() that also makes sure functionality is as described for partially overlapping src and dst. Co-authored-by: Yury Norov Signed-off-by: Stefano Brivio --- lib/test_bitmap.c | 60

[PATCH 0/2] lib: Fix bitmap_cut() for overlaps, add test

Patch 1/2 addresses the issue Yury reported with partially overlapping src and dst in bitmap_cut(), and 2/2 adds a test that covers basic functionality as well as this case. Stefano Brivio (2): lib: Fix bitmap_cut() for partial overlapping case lib: Add test for bitmap_cut() lib/bitmap.c

Re: [LKP] Re: [netfilter] e32a4dc651: BUG:using_smp_processor_id()in_preemptible

On Fri, 5 Jun 2020 08:15:07 +0800 Liu Yiding wrote: > Hi, > > On 6/5/20 6:23 AM, Stefano Brivio wrote: > > Hi, > > > > On Wed, 3 Jun 2020 16:49:34 +0800 > > kernel test robot wrote: > > > >> Greeting, > >> > >> FYI, we

Re: [netfilter] e32a4dc651: BUG:using_smp_processor_id()in_preemptible

Hi, On Wed, 3 Jun 2020 16:49:34 +0800 kernel test robot wrote: > Greeting, > > FYI, we noticed the following commit (built with gcc-7): > > commit: e32a4dc6512ce3c1a1920531246e7037896e510a ("netfilter: nf_tables: make > sets built-in") >

Re: [PATCH] lib/bitmap: rework bitmap_cut()

Hi Yury, On Sat, 7 Mar 2020 06:07:39 -0800 Yury Norov wrote: > On Sat, Mar 07, 2020 at 02:33:41PM +0100, Stefano Brivio wrote: > > > > [...] > > > > ...which means it would be a good idea to also add tests for numbers of > > bits that are not multiple of eight,

Re: [PATCH 4.19 41/80] netfilter: nft_set_rbtree: Introduce and use nft_rbtree_interval_start()

On Tue, 19 May 2020 14:51:13 +0200 Greg Kroah-Hartman wrote: > On Tue, May 19, 2020 at 02:19:07PM +0200, Pavel Machek wrote: > > On Tue 2020-05-19 14:13:56, Greg Kroah-Hartman wrote: > > > On Tue, May 19, 2020 at 02:06:25PM +0200, Pavel Machek wrote: > > > > Hi! > > > > > > > > > [

Re: [PATCH] net: openvswitch: free vport unless register_netdevice() succeeds

On Sat, 10 Aug 2019 00:34:55 -0700 Pravin Shelar wrote: > On Thu, Aug 8, 2019 at 8:55 PM Hillf Danton wrote: > > > > > > syzbot found the following crash on: > > > > HEAD commit:1e78030e Merge tag 'mmc-v5.3-rc1' of git://git.kernel.org/.. > > git tree: upstream > > console output:

Re: [PATCH] rat_cs: Remove duplicate code

On Sat, 20 Jul 2019 23:16:47 +0530 Hariprasad Kelam wrote: > Code is same if translate is true/false in case invalid packet is > received.So remove else part. > > Issue identified with coccicheck > > Signed-off-by: Hariprasad Kelam > --- > drivers/net/wireless/ray_cs.c | 29

Re: linux-next: Fixes tag needs some work in the net-next tree

On Wed, 20 Feb 2019 12:25:48 -0800 (PST) David Miller wrote: > From: Stefano Brivio > Date: Wed, 20 Feb 2019 20:59:10 +0100 > > > On Wed, 20 Feb 2019 11:02:01 -0800 (PST) > > David Miller wrote: > > > >> From: Jiri Pirko > >> Date: Wed, 20

Re: linux-next: Fixes tag needs some work in the net-next tree

On Wed, 20 Feb 2019 11:02:01 -0800 (PST) David Miller wrote: > From: Jiri Pirko > Date: Wed, 20 Feb 2019 09:36:11 +0100 > > > Would be good to have some robot checking "Fixes" sanity... > > I want to add a script to my trees that locally do it for me but the > backlog for patch review for

Re: kernel panic: stack is corrupted in udp4_lib_lookup2

On Fri, 4 Jan 2019 18:26:16 +0100 Dmitry Vyukov wrote: > On Fri, Jan 4, 2019 at 6:14 PM Stefano Brivio wrote: > > > > On Fri, 4 Jan 2019 12:05:04 +0100 > > Dmitry Vyukov wrote: > > > > > I've added these as tests: > > > > > > https://githu

Re: kernel panic: stack is corrupted in udp4_lib_lookup2

On Fri, 4 Jan 2019 12:24:18 -0500 Willem de Bruijn wrote: > On Fri, Jan 4, 2019 at 12:14 PM Stefano Brivio wrote: > > > > On Fri, 4 Jan 2019 12:05:04 +0100 > > Dmitry Vyukov wrote: > > > > > On Fri, Jan 4, 2019 at 11:54 AM Stefano Brivio > > > w

Re: kernel panic: stack is corrupted in udp4_lib_lookup2

On Fri, 4 Jan 2019 12:05:04 +0100 Dmitry Vyukov wrote: > On Fri, Jan 4, 2019 at 11:54 AM Stefano Brivio wrote: > > > > On Fri, 4 Jan 2019 11:32:12 +0100 > > Dmitry Vyukov wrote: > > > > > On Thu, Jan 3, 2019 at 10:54 PM Stefano Brivio > > > wrot

Re: kernel panic: stack is corrupted in udp4_lib_lookup2

On Fri, 4 Jan 2019 11:32:12 +0100 Dmitry Vyukov wrote: > On Thu, Jan 3, 2019 at 10:54 PM Stefano Brivio wrote: > > > > On Thu, 3 Jan 2019 15:15:06 -0600 > > Willem de Bruijn wrote: > > > > > syzbot generated stack traces with > > &

Re: kernel panic: stack is corrupted in udp4_lib_lookup2

On Thu, 3 Jan 2019 15:15:06 -0600 Willem de Bruijn wrote: > syzbot generated stack traces with > > [ 183.517380] udpv6_err+0x46/0x60 > [ 183.520739] ? __udp6_lib_err+0x1890/0x1890 > [ 183.525054] gue6_err_proto_handler+0x199/0x280 Where? I can't find that in any logs linked from the

[PATCH net 1/2] fou: Prevent unbounded recursion in GUE error handler also with UDP-Lite

ght happen with a UDP-Lite inner payload. Also skip exception handling for inner UDP-Lite protocol. Fixes: 11789039da53 ("fou: Prevent unbounded recursion in GUE error handler") Signed-off-by: Stefano Brivio --- net/ipv4/fou.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --gi

[PATCH net 2/2] fou6: Prevent unbounded recursion in GUE error handler

c7a33e4ab9...@syzkaller.appspotmail.com Reported-by: Willem de Bruijn Reported-by: Eric Dumazet Fixes: b8a51b38e4d4 ("fou, fou6: ICMP error handlers for FoU and GUE") Signed-off-by: Stefano Brivio --- net/ipv6/fou6.c | 8 1 file changed, 8 insertions(+) diff --git a/net/ipv6/fou6

[PATCH net 0/2] Fix two further potential unbounded recursions in GUE error handlers

ich I also forgot to deal with in that same commit. Stefano Brivio (2): fou: Prevent unbounded recursion in GUE error handler also with UDP-Lite fou6: Prevent unbounded recursion in GUE error handler net/ipv4/fou.c | 3 ++- net/ipv6/fou6.c | 8 2 files changed, 10 insertions(+),

Re: kernel panic: stack is corrupted in udp4_lib_lookup2

ers can be reached at syzkal...@googlegroups.com. > > > > syzbot will keep track of this bug report. See: > > https://goo.gl/tpsmEJ#bug-status-tracking for how to communicate with > > syzbot. > > Maybe commit 11789039da536fea96c98a40c2b441decf2e7323 > Author: Stefano Brivio

Re: kernel panic: stack is corrupted in udp4_lib_lookup2

Hi Willem, On Thu, 3 Jan 2019 13:41:43 -0600 Willem de Bruijn wrote: > On Thu, Jan 3, 2019 at 1:39 PM Willem de Bruijn > wrote: > > > > On Thu, Jan 3, 2019 at 7:07 AM syzbot > > wrote: > > > > > > Hello, > > > > > > syzbot found the following crash on: > > > > > > HEAD commit:

Re: WARNING in __rcu_read_unlock

[Dropping syzbot from Cc:] On Tue, 18 Dec 2018 14:26:00 +0100 Dmitry Vyukov wrote: > On Tue, Dec 18, 2018 at 1:40 PM Stefano Brivio > wrote: > > > Maybe it would be nice to have a semi-automated way to isolate and > > describe/name specific conditions found by syzbot via

Re: WARNING in __rcu_read_unlock

On Tue, 18 Dec 2018 09:49:17 +0100 Dmitry Vyukov wrote: > On Tue, Dec 18, 2018 at 12:18 AM Stefano Brivio wrote: > > > > On Mon, 17 Dec 2018 16:53:36 +0100 > > Dmitry Vyukov wrote: > > > > > On Mon, Dec 17, 2018 at 4:24 PM Stefano Brivio > > >

Re: WARNING in __rcu_read_unlock

On Mon, 17 Dec 2018 16:53:36 +0100 Dmitry Vyukov wrote: > On Mon, Dec 17, 2018 at 4:24 PM Stefano Brivio wrote: > > > > On Mon, 17 Dec 2018 06:57:35 -0800 > > Eric Dumazet wrote: > > > > > Might be cause by commit b8a51b38e4d4dec3e379d52c0fe1a66827f7cf1e

[PATCH net-next] fou: Prevent unbounded recursion in GUE error handler

iterative handling for these cases. Reported-and-tested-by: syzbot+43f6755d1c2e62743...@syzkaller.appspotmail.com Fixes: b8a51b38e4d4 ("fou, fou6: ICMP error handlers for FoU and GUE") Signed-off-by: Stefano Brivio --- net/ipv4/fou.c | 7 +++ 1 file changed, 7 insertions(+) diff --git

Re: WARNING in __rcu_read_unlock

On Mon, 17 Dec 2018 16:24:21 +0100 Stefano Brivio wrote: > On Mon, 17 Dec 2018 06:57:35 -0800 > Eric Dumazet wrote: > > > Might be cause by commit b8a51b38e4d4dec3e379d52c0fe1a66827f7cf1e > > fou, fou6: ICMP error handlers for FoU and GUE > > This: > >

Re: WARNING in __rcu_read_unlock

On Mon, 17 Dec 2018 06:57:35 -0800 Eric Dumazet wrote: > Might be cause by commit b8a51b38e4d4dec3e379d52c0fe1a66827f7cf1e > fou, fou6: ICMP error handlers for FoU and GUE This: diff --git a/net/ipv4/fou.c b/net/ipv4/fou.c index 0d0ad19ecb87..20a6de26d146 100644 --- a/net/ipv4/fou.c +++

Re: WARNING in __rcu_read_unlock

On Mon, 17 Dec 2018 06:57:35 -0800 Eric Dumazet wrote: > Might be cause by commit b8a51b38e4d4dec3e379d52c0fe1a66827f7cf1e > fou, fou6: ICMP error handlers for FoU and GUE Most likely, yes. > Please Stefano take a look, thanks ! Started one minute before your email, thanks for Cc'ing me

Re: [lkp-robot] [vti6] b4331a6818: kernel_selftests.net.pmtu.sh.fail

On Tue, 5 Jun 2018 15:09:27 +0800 kernel test robot wrote: > FYI, we noticed the following commit (built with gcc-7): > > commit: b4331a681822b420511b3258f1c3db35001fde48 ("vti6: Change minimum MTU > to IPV4_MIN_MTU, vti6 can carry IPv4 too") >

Re: [lkp-robot] [vti6] b4331a6818: kernel_selftests.net.pmtu.sh.fail

On Tue, 5 Jun 2018 15:09:27 +0800 kernel test robot wrote: > FYI, we noticed the following commit (built with gcc-7): > > commit: b4331a681822b420511b3258f1c3db35001fde48 ("vti6: Change minimum MTU > to IPV4_MIN_MTU, vti6 can carry IPv4 too") >

Re: [PATCH v4 ipsec-next] xfrm: remove VLA usage in __xfrm6_sort()

it log (Steffen) > - use "= { }" instead of memset() (Stefano) > v2: > - use XFRM_MAX_DEPTH for "count" array (Steffen and Mathias). > --- Acked-by: Stefano Brivio <sbri...@redhat.com>

Re: [PATCH v4 ipsec-next] xfrm: remove VLA usage in __xfrm6_sort()

v2: > - use XFRM_MAX_DEPTH for "count" array (Steffen and Mathias). > --- Acked-by: Stefano Brivio

Re: [PATCH v3 ipsec-next] xfrm: remove VLA usage in __xfrm6_sort()

Hi Kees, On Tue, 24 Apr 2018 16:46:51 -0700 Kees Cook wrote: > In the quest to remove all stack VLA usage removed from the kernel[1], > just use XFRM_MAX_DEPTH as already done for the "class" array. In one > case, it'll do this loop up to 5, the other caller up to 6. > >

Re: [PATCH v3 ipsec-next] xfrm: remove VLA usage in __xfrm6_sort()

Hi Kees, On Tue, 24 Apr 2018 16:46:51 -0700 Kees Cook wrote: > In the quest to remove all stack VLA usage removed from the kernel[1], > just use XFRM_MAX_DEPTH as already done for the "class" array. In one > case, it'll do this loop up to 5, the other caller up to 6. > > [1]

Re: [PATCH v2] net: ipv6: xfrm6_state: remove VLA usage

Andreas, On Sat, 10 Mar 2018 09:40:44 +0200 Andreas Christoforou wrote: > The kernel would like to have all stack VLA usage removed[1]. > Instead of dynamic allocation, just use XFRM_MAX_DEPTH > as already done for the "class" array, but as per feedback, > I will not

Re: [PATCH v2] net: ipv6: xfrm6_state: remove VLA usage

Andreas, On Sat, 10 Mar 2018 09:40:44 +0200 Andreas Christoforou wrote: > The kernel would like to have all stack VLA usage removed[1]. > Instead of dynamic allocation, just use XFRM_MAX_DEPTH > as already done for the "class" array, but as per feedback, > I will not drop maxclass because that

Re: [PATCH 4.4 92/97] ip6_vti: adjust vti mtu according to mtu of lower device

On Wed, 04 Apr 2018 01:09:16 +0100 Ben Hutchings wrote: > On Fri, 2018-03-23 at 10:55 +0100, Greg Kroah-Hartman wrote: > > 4.4-stable review patch.  If anyone has any objections, please let me know. > > > > -- > > > > From: Alexey Kodanev

Re: [PATCH 4.4 92/97] ip6_vti: adjust vti mtu according to mtu of lower device

On Wed, 04 Apr 2018 01:09:16 +0100 Ben Hutchings wrote: > On Fri, 2018-03-23 at 10:55 +0100, Greg Kroah-Hartman wrote: > > 4.4-stable review patch.  If anyone has any objections, please let me know. > > > > -- > > > > From: Alexey Kodanev > > > > > > [ Upstream commit

Re: linux-next: manual merge of the ipsec tree with the net tree

Petr's patch: Fixes: adab890d00dc ("Merge remote-tracking branch 'ipsec/master'") Reviewed-by: Stefano Brivio <sbri...@redhat.com> Tested-by: Stefano Brivio <sbri...@redhat.com> > What's the right way to proceed from here? It looks to me like Stefano > or Steffen should

Re: linux-next: manual merge of the ipsec tree with the net tree

0d00dc ("Merge remote-tracking branch 'ipsec/master'") Reviewed-by: Stefano Brivio Tested-by: Stefano Brivio > What's the right way to proceed from here? It looks to me like Stefano > or Steffen should take this into the ipsec tree (possibly just squash to > the clam

Re: [PATCH v2] net: ipv6: xfrm6_state: remove VLA usage

On Sat, 10 Mar 2018 09:18:46 -0800 Kees Cook <keesc...@chromium.org> wrote: > On Sat, Mar 10, 2018 at 12:43 AM, Stefano Brivio <sbri...@redhat.com> wrote: > > On Sat, 10 Mar 2018 09:40:44 +0200 > > Andreas Christoforou <andreaschrist...@gmail.com> wrote:

Re: [PATCH v2] net: ipv6: xfrm6_state: remove VLA usage

On Sat, 10 Mar 2018 09:18:46 -0800 Kees Cook wrote: > On Sat, Mar 10, 2018 at 12:43 AM, Stefano Brivio wrote: > > On Sat, 10 Mar 2018 09:40:44 +0200 > > Andreas Christoforou wrote: > > > >> diff --git a/net/ipv6/xfrm6_state.c b/net/ipv6/xfrm6_state.c >

Re: [PATCH v2] net: ipv6: xfrm6_state: remove VLA usage

On Sat, 10 Mar 2018 09:40:44 +0200 Andreas Christoforou wrote: > diff --git a/net/ipv6/xfrm6_state.c b/net/ipv6/xfrm6_state.c > index b15075a..270a53a 100644 > --- a/net/ipv6/xfrm6_state.c > +++ b/net/ipv6/xfrm6_state.c > @@ -62,7 +62,7 @@ __xfrm6_sort(void **dst,

Re: [PATCH v2] net: ipv6: xfrm6_state: remove VLA usage

On Sat, 10 Mar 2018 09:40:44 +0200 Andreas Christoforou wrote: > diff --git a/net/ipv6/xfrm6_state.c b/net/ipv6/xfrm6_state.c > index b15075a..270a53a 100644 > --- a/net/ipv6/xfrm6_state.c > +++ b/net/ipv6/xfrm6_state.c > @@ -62,7 +62,7 @@ __xfrm6_sort(void **dst, void **src, int n, int

Re: [PATCH v2] net: ipv4: emulate READ_ONCE() on ->hdrincl bit-field in raw_sendmsg()

s from hdrincl with reloads from inet->hdrincl. > > Fixes: 8f659a03a0ba ("net: ipv4: fix for a race condition in raw_sendmsg") > Signed-off-by: Nicolai Stange <nsta...@suse.de> Reviewed-by: Stefano Brivio <sbri...@redhat.com> -- Stefano

Re: [PATCH v2] net: ipv4: emulate READ_ONCE() on ->hdrincl bit-field in raw_sendmsg()

ith reloads from inet->hdrincl. > > Fixes: 8f659a03a0ba ("net: ipv4: fix for a race condition in raw_sendmsg") > Signed-off-by: Nicolai Stange Reviewed-by: Stefano Brivio -- Stefano

Re: atm/clip: Use seq_puts() in svc_addr()

On Sun, 7 Jan 2018 09:19:17 +0100 SF Markus Elfring wrote: > >> Two strings should be quickly put into a sequence by two function calls. > >> Thus use the function "seq_puts" instead of "seq_printf". > >> > >> This issue was detected by using the Coccinelle

Re: atm/clip: Use seq_puts() in svc_addr()

On Sun, 7 Jan 2018 09:19:17 +0100 SF Markus Elfring wrote: > >> Two strings should be quickly put into a sequence by two function calls. > >> Thus use the function "seq_puts" instead of "seq_printf". > >> > >> This issue was detected by using the Coccinelle software. > > > > Can you please

Re: [PATCH] atm/clip: Use seq_puts() in svc_addr()

On Sat, 6 Jan 2018 22:44:08 +0100 SF Markus Elfring wrote: > From: Markus Elfring > Date: Sat, 6 Jan 2018 22:34:12 +0100 > > Two strings should be quickly put into a sequence by two function calls. > Thus use the function "seq_puts"

Re: [PATCH] atm/clip: Use seq_puts() in svc_addr()

On Sat, 6 Jan 2018 22:44:08 +0100 SF Markus Elfring wrote: > From: Markus Elfring > Date: Sat, 6 Jan 2018 22:34:12 +0100 > > Two strings should be quickly put into a sequence by two function calls. > Thus use the function "seq_puts" instead of "seq_printf". > > This issue was detected by using

Re: [PATCH] net: ipv4: emulate READ_ONCE() on ->hdrincl bit-field in raw_sendmsg()

Hi Nicolai, On Wed, 03 Jan 2018 10:28:20 +0100 Nicolai Stange <nsta...@suse.de> wrote: > Hi Stefano, > > Stefano Brivio <sbri...@redhat.com> writes: > > > On Tue, 2 Jan 2018 17:30:20 +0100 > > Nicolai Stange <nsta...@suse.de> wrote: > > > &

Re: [PATCH] net: ipv4: emulate READ_ONCE() on ->hdrincl bit-field in raw_sendmsg()

Hi Nicolai, On Wed, 03 Jan 2018 10:28:20 +0100 Nicolai Stange wrote: > Hi Stefano, > > Stefano Brivio writes: > > > On Tue, 2 Jan 2018 17:30:20 +0100 > > Nicolai Stange wrote: > > > >> [...] > >> > >> diff --git a/net/ipv4/raw

Re: [PATCH] net: ipv4: emulate READ_ONCE() on ->hdrincl bit-field in raw_sendmsg()

Hi, On Tue, 2 Jan 2018 17:30:20 +0100 Nicolai Stange wrote: > [...] > > diff --git a/net/ipv4/raw.c b/net/ipv4/raw.c > index 5b9bd5c33d9d..e84290c28c0c 100644 > --- a/net/ipv4/raw.c > +++ b/net/ipv4/raw.c > @@ -513,16 +513,18 @@ static int raw_sendmsg(struct sock *sk, struct

Re: [PATCH] net: ipv4: emulate READ_ONCE() on ->hdrincl bit-field in raw_sendmsg()

Hi, On Tue, 2 Jan 2018 17:30:20 +0100 Nicolai Stange wrote: > [...] > > diff --git a/net/ipv4/raw.c b/net/ipv4/raw.c > index 5b9bd5c33d9d..e84290c28c0c 100644 > --- a/net/ipv4/raw.c > +++ b/net/ipv4/raw.c > @@ -513,16 +513,18 @@ static int raw_sendmsg(struct sock *sk, struct msghdr > *msg,

Re: hung task in mac80211

On Wed, 06 Sep 2017 14:58:48 +0200 Johannes Berg wrote: > +void __ieee80211_start_rx_ba_session(struct sta_info *sta, > + u8 dialog_token, u16 timeout, > + u16 start_seq_num, u16 ba_policy, u16 tid, > +

Re: hung task in mac80211

On Wed, 06 Sep 2017 14:58:48 +0200 Johannes Berg wrote: > +void __ieee80211_start_rx_ba_session(struct sta_info *sta, > + u8 dialog_token, u16 timeout, > + u16 start_seq_num, u16 ba_policy, u16 tid, > +

Re: hung task in mac80211

On Wed, 06 Sep 2017 15:30:10 +0200 Johannes Berg wrote: > So for example replacing the loop of tid = 0..NUM_TIDS-1 with a > list_for_each_entry() would already be unsafe with the dropping if the > list were to require the mutex for locking. Sure. Still, it would need

Re: hung task in mac80211

On Wed, 06 Sep 2017 15:30:10 +0200 Johannes Berg wrote: > So for example replacing the loop of tid = 0..NUM_TIDS-1 with a > list_for_each_entry() would already be unsafe with the dropping if the > list were to require the mutex for locking. Sure. Still, it would need another code change to

Re: hung task in mac80211

On Wed, 06 Sep 2017 15:21:00 +0200 Johannes Berg <johan...@sipsolutions.net> wrote: > On Wed, 2017-09-06 at 15:19 +0200, Stefano Brivio wrote: > > On Wed, 06 Sep 2017 14:48:35 +0200 > > Johannes Berg <johan...@sipsolutions.net> wrote: >

Re: hung task in mac80211

On Wed, 06 Sep 2017 15:21:00 +0200 Johannes Berg wrote: > On Wed, 2017-09-06 at 15:19 +0200, Stefano Brivio wrote: > > On Wed, 06 Sep 2017 14:48:35 +0200 > > Johannes Berg wrote: > > > > > I'll look in a bit - but > > > > > > > +

Re: hung task in mac80211

On Wed, 06 Sep 2017 14:48:35 +0200 Johannes Berg wrote: > I'll look in a bit - but > > > + mutex_unlock(>ampdu_mlme.mtx); > >   ___ieee80211_stop_rx_ba_session( > >   sta, tid, WLAN_BACK_RECIPIENT, > >  

Re: hung task in mac80211

On Wed, 06 Sep 2017 14:48:35 +0200 Johannes Berg wrote: > I'll look in a bit - but > > > + mutex_unlock(>ampdu_mlme.mtx); > >   ___ieee80211_stop_rx_ba_session( > >   sta, tid, WLAN_BACK_RECIPIENT, > >  

Re: hung task in mac80211

On Wed, 6 Sep 2017 13:57:47 +0200 Matteo Croce wrote: > Hi, > > I have an hung task on vanilla 4.13 kernel which I haven't on 4.12. > The problem is present both on my AP and on my notebook, > so it seems it affects AP and STA mode as well. > The generated messages are: > >

Re: hung task in mac80211

On Wed, 6 Sep 2017 13:57:47 +0200 Matteo Croce wrote: > Hi, > > I have an hung task on vanilla 4.13 kernel which I haven't on 4.12. > The problem is present both on my AP and on my notebook, > so it seems it affects AP and STA mode as well. > The generated messages are: > > INFO: task

Re: [PATCH 0/4] irda: move it to drivers/staging so we can delete it

On Tue, 29 Aug 2017 12:59:00 +0200 Geert Uytterhoeven wrote: > Hi Greg, > > On Sun, Aug 27, 2017 at 5:03 PM, Greg Kroah-Hartman > wrote: > > The IRDA code has long been obsolete and broken. So, to keep people > > from trying to use it, and to

Re: [PATCH 0/4] irda: move it to drivers/staging so we can delete it

On Tue, 29 Aug 2017 12:59:00 +0200 Geert Uytterhoeven wrote: > Hi Greg, > > On Sun, Aug 27, 2017 at 5:03 PM, Greg Kroah-Hartman > wrote: > > The IRDA code has long been obsolete and broken. So, to keep people > > from trying to use it, and to prevent people from having to maintain it, > >

[PATCH net] sctp: Avoid out-of-bounds reads from address storage

xes: 8f840e47f190 ("sctp: add the sctp_diag.c file") Cc: <sta...@vger.kernel.org> # 4.7+ Cc: Xin Long <lucien@gmail.com> Cc: Vlad Yasevich <vyasev...@gmail.com> Cc: Neil Horman <nhor...@tuxdriver.com> Signed-off-by: Stefano Brivio <sbri...@redhat.com> --- net/sctp

[PATCH net] sctp: Avoid out-of-bounds reads from address storage

xes: 8f840e47f190 ("sctp: add the sctp_diag.c file") Cc: # 4.7+ Cc: Xin Long Cc: Vlad Yasevich Cc: Neil Horman Signed-off-by: Stefano Brivio --- net/sctp/sctp_diag.c | 7 +-- net/sctp/socket.c| 3 +-- 2 files changed, 6 insertions(+), 4 deletions(-) diff --git a/net/sctp/sctp_diag

Re: [PATCH] net/i40e: use cpumask_copy() for assigning cpumask

Hi Juergen, On Sat, 12 Aug 2017 18:09:46 +0200 Juergen Gross wrote: > Using direct assignment for a cpumask is wrong, cpumask_copy() should > be used instead. Perhaps a Fixes: tag might be helpful here, such as: Fixes: 96db776a3682 ("i40e/i40evf: fix interrupt

Re: [PATCH] net/i40e: use cpumask_copy() for assigning cpumask

Hi Juergen, On Sat, 12 Aug 2017 18:09:46 +0200 Juergen Gross wrote: > Using direct assignment for a cpumask is wrong, cpumask_copy() should > be used instead. Perhaps a Fixes: tag might be helpful here, such as: Fixes: 96db776a3682 ("i40e/i40evf: fix interrupt affinity bug") as I

Re: rtl8187 rate control doesn't work

On Sat, 12 Jan 2008 19:23:53 +0100 Hauke Mehrtens <[EMAIL PROTECTED]> wrote: > I have tried wireless-2.6 and I have the same problem. If the rate goes > over 11M no TCP/IP traffic goes through the wireless connecting. If rate > is set to auto and the rate control algorithm changes it to something

Re: rtl8187 rate control doesn't work

On Sat, 12 Jan 2008 15:44:30 +0100 Hauke Mehrtens <[EMAIL PROTECTED]> wrote: > I have tested kernel 2.6.24-rc7-git4 with the build in rtl8187 module > and I have the same problem. Could you please try the wireless-2.6 kernel tree? I think it's fixed there. Details on how to download that can be

Re: rtl8187 rate control doesn't work

On Sat, 12 Jan 2008 15:44:30 +0100 Hauke Mehrtens [EMAIL PROTECTED] wrote: I have tested kernel 2.6.24-rc7-git4 with the build in rtl8187 module and I have the same problem. Could you please try the wireless-2.6 kernel tree? I think it's fixed there. Details on how to download that can be

Re: rtl8187 rate control doesn't work

On Sat, 12 Jan 2008 19:23:53 +0100 Hauke Mehrtens [EMAIL PROTECTED] wrote: I have tried wireless-2.6 and I have the same problem. If the rate goes over 11M no TCP/IP traffic goes through the wireless connecting. If rate is set to auto and the rate control algorithm changes it to something

Re: 2.6.24-rc6-git12: Reported regressions from 2.6.23

On Sun, 6 Jan 2008 10:38:53 +0100 Ingo Molnar <[EMAIL PROTECTED]> wrote: > * Rafael J. Wysocki <[EMAIL PROTECTED]> wrote: > > > Subject : jiffies counter leaps in 2.6.24-rc3 > > Submitter : Stefano Brivio <[EMAIL PROTECTED]> > > Date

Re: 2.6.24-rc6-git12: Reported regressions from 2.6.23

On Sun, 6 Jan 2008 10:38:53 +0100 Ingo Molnar [EMAIL PROTECTED] wrote: * Rafael J. Wysocki [EMAIL PROTECTED] wrote: Subject : jiffies counter leaps in 2.6.24-rc3 Submitter : Stefano Brivio [EMAIL PROTECTED] Date: 2007-11-29 08:36 References : http

Re: [PATCH v4 7/8] debugfs: allow access to signed values

On Fri, 28 Dec 2007 19:58:32 +0100 Christoph Hellwig <[EMAIL PROTECTED]> wrote: > On Thu, Dec 20, 2007 at 01:47:13PM +0100, Arnd Bergmann wrote: > > Also, Christoph has recently posted a suggestion for how to improve > > the interface to allow the 'get' operation to return an error: > >

Re: [PATCH v4 7/8] debugfs: allow access to signed values

On Fri, 28 Dec 2007 19:58:32 +0100 Christoph Hellwig [EMAIL PROTECTED] wrote: On Thu, Dec 20, 2007 at 01:47:13PM +0100, Arnd Bergmann wrote: Also, Christoph has recently posted a suggestion for how to improve the interface to allow the 'get' operation to return an error:

[PATCH v5 7/8] debugfs: allow access to signed values

gt; To: Greg Kroah-Hartman <[EMAIL PROTECTED]> To: Arnd Bergmann <[EMAIL PROTECTED]> To: Akinobu Mita <[EMAIL PROTECTED]> Signed-off-by: Stefano Brivio <[EMAIL PROTECTED]> --- This version addresses last Johannes' concerns. Please just discard v4. --- arch/powerpc/platforms/c

[PATCH v4 7/8] debugfs: allow access to signed values

gt; To: Greg Kroah-Hartman <[EMAIL PROTECTED]> To: Arnd Bergmann <[EMAIL PROTECTED]> To: Akinobu Mita <[EMAIL PROTECTED]> Signed-off-by: Stefano Brivio <[EMAIL PROTECTED]> --- This version addresses last Johannes' concerns. --- arch/powerpc/platforms/cell/spufs/file.

[PATCH v4 7/8] debugfs: allow access to signed values

-Hartman [EMAIL PROTECTED] To: Arnd Bergmann [EMAIL PROTECTED] To: Akinobu Mita [EMAIL PROTECTED] Signed-off-by: Stefano Brivio [EMAIL PROTECTED] --- This version addresses last Johannes' concerns. --- arch/powerpc/platforms/cell/spufs/file.c | 48 fs/debugfs/file.c

[PATCH v5 7/8] debugfs: allow access to signed values

-Hartman [EMAIL PROTECTED] To: Arnd Bergmann [EMAIL PROTECTED] To: Akinobu Mita [EMAIL PROTECTED] Signed-off-by: Stefano Brivio [EMAIL PROTECTED] --- This version addresses last Johannes' concerns. Please just discard v4. --- arch/powerpc/platforms/cell/spufs/file.c | 48 fs/debugfs

[PATCH v4 7/8] debugfs: allow access to signed values

Add debugfs_create_s{8,16,32,64}. For these to work properly, we need to remove a cast in libfs. Cc: Johannes Berg <[EMAIL PROTECTED]> Signed-off-by: Stefano Brivio <[EMAIL PROTECTED]> Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]> --- fs/debugfs/f

Re: [PATCH v3 7/8] debugfs: allow access to signed values

On Tue, 18 Dec 2007 22:45:10 -0800 Greg KH <[EMAIL PROTECTED]> wrote: > On Wed, Dec 19, 2007 at 01:27:39AM +0100, Stefano Brivio wrote: > > Add debugfs_create_s{8,16,32,64}. For these to work properly, we need to > > remove > > a cast in libfs. > > > &

Re: [PATCH v3 7/8] debugfs: allow access to signed values

On Tue, 18 Dec 2007 22:45:10 -0800 Greg KH [EMAIL PROTECTED] wrote: On Wed, Dec 19, 2007 at 01:27:39AM +0100, Stefano Brivio wrote: Add debugfs_create_s{8,16,32,64}. For these to work properly, we need to remove a cast in libfs. Cc: Johannes Berg [EMAIL PROTECTED] To: Greg Kroah

[PATCH v4 7/8] debugfs: allow access to signed values

Add debugfs_create_s{8,16,32,64}. For these to work properly, we need to remove a cast in libfs. Cc: Johannes Berg [EMAIL PROTECTED] Signed-off-by: Stefano Brivio [EMAIL PROTECTED] Signed-off-by: Greg Kroah-Hartman [EMAIL PROTECTED] --- fs/debugfs/file.c | 166

Re: 2.6.24-rc4-git5: Reported regressions from 2.6.23

On Tue, 11 Dec 2007 10:01:20 +0100 Ingo Molnar <[EMAIL PROTECTED]> wrote: > ok, just to make sure we are all synced up. I made 8 patches related to > this problem category (and all the trickle effects). 3 are upstream > already, 5 are pending for v2.6.25. One out of those 5 is an immaterial >

  1   2   >