Since dumps carry struct genl_info now, use the attrs pointer
from genl_info and remove the one in struct genl_dumpit_info.
Reviewed-by: Johannes Berg
Reviewed-by: Miquel Raynal
Reviewed-by: Jiri Pirko
Signed-off-by: Jakub Kicinski
---
CC: ja...@zx2c4.com
CC: j...@resnulli.us
CC: alex.ar
Since dumps carry struct genl_info now, use the attrs pointer
from genl_info and remove the one in struct genl_dumpit_info.
Reviewed-by: Johannes Berg
Reviewed-by: Miquel Raynal
Reviewed-by: Jiri Pirko
Signed-off-by: Jakub Kicinski
---
CC: ja...@zx2c4.com
CC: j...@resnulli.us
CC: alex.ar
Since dumps carry struct genl_info now, use the attrs pointer
use the attr pointer from genl_info and remove the one in
struct genl_dumpit_info.
Signed-off-by: Jakub Kicinski
---
CC: ja...@zx2c4.com
CC: j...@resnulli.us
CC: alex.ar...@gmail.com
CC: ste...@datenfreihafen.org
CC: miquel.ray
On Wed, 24 May 2023 08:33:41 -0700 Jakub Kicinski wrote:
> On Wed, 24 May 2023 10:24:31 +0200 Dmitry Vyukov wrote:
> > FWIW There are more report examples on the dashboard.
> > There are some that don't mention wireguard nor usbnet, e.g.:
> > https://syzkaller.appspot.
On Wed, 24 May 2023 10:24:31 +0200 Dmitry Vyukov wrote:
> FWIW There are more report examples on the dashboard.
> There are some that don't mention wireguard nor usbnet, e.g.:
> https://syzkaller.appspot.com/text?tag=CrashReport&x=17dd244628
> So that's probably red herring. But they all seem t
On Tue, 23 May 2023 18:42:53 +0200 Jason A. Donenfeld wrote:
> > It should, no idea why it isn't. Looking thru the code now I don't see
> > any obvious gaps where timer object is on a list but not active :S
> > There's no way to get a vmcore from syzbot, right? :)
> >
> > Also I thought the shutdow
On Tue, 23 May 2023 18:14:18 +0200 Jason A. Donenfeld wrote:
> So, IOW, not a wireguard bug, right?
What's slightly concerning is that there aren't any other timers
leading to
KASAN: slab-use-after-free Write in enqueue_timer
:( If WG was just an innocent bystander there should be, right?
On Tue, 23 May 2023 18:12:32 +0200 Eric Dumazet wrote:
> > Your timer had the pleasure of getting queued _after_ a dead watchdog
> > timer, no? IOW it tries to update the ->next pointer of a queued
> > watchdog timer. We should probably do:
> >
> > diff --git a/net/core/dev.c b/net/core/dev.c
> > i
On Tue, 23 May 2023 17:46:20 +0200 Jason A. Donenfeld wrote:
> > Freed by task 41:
> > __kmem_cache_free+0x264/0x3c0 mm/slub.c:3799
> > device_release+0x95/0x1c0
> > kobject_cleanup lib/kobject.c:683 [inline]
> > kobject_release lib/kobject.c:714 [inline]
> > kref_put include/linux/kref.h:65 [
new families do the right thing by default
put the onus of opting out of validation on existing families.
Signed-off-by: Jakub Kicinski
---
CC: j...@resnulli.us
CC: johan...@sipsolutions.net
CC: linux-bl...@vger.kernel.org
CC: osmocom-net-g...@lists.osmocom.org
CC: linux-w...@vger.kernel.org
CC
On Sat, 19 Mar 2022 01:16:24 -0700 syzbot wrote:
> Hello,
>
> syzbot found the following issue on:
>
> HEAD commit:6d72dda014a4 Add linux-next specific files for 20220318
> git tree: linux-next
> console output: https://syzkaller.appspot.com/x/log.txt?x=124f558970
> kernel config:
On Fri, 18 Mar 2022 16:36:19 -0700 syzbot wrote:
> Hello,
>
> syzbot found the following issue on:
>
> HEAD commit:e89600ebeeb1 af_vsock: SOCK_SEQPACKET broken buffer test
> git tree: net-next
> console output: https://syzkaller.appspot.com/x/log.txt?x=134d43d570
> kernel config: h
On Fri, 18 Mar 2022 18:50:08 -0600 Jason A. Donenfeld wrote:
> Hi Jakub,
>
> Er, I forgot to mark this as net-next, but as it's connected to the
> discussion we were just having, I think you get the idea. :)
Yup, patchwork bot figured it out, too. All good :)
On Fri, 19 Nov 2021 10:41:44 -0800 Jakub Kicinski wrote:
> On Fri, 19 Nov 2021 10:26:19 -0800 Kees Cook wrote:
> > On Thu, Nov 18, 2021 at 11:13:55PM -0800, Jakub Kicinski wrote:
> > > This adds ~27k of these warnings to W=1 gcc builds:
> > >
> > > i
On Fri, 19 Nov 2021 10:26:19 -0800 Kees Cook wrote:
> On Thu, Nov 18, 2021 at 11:13:55PM -0800, Jakub Kicinski wrote:
> > On Thu, 18 Nov 2021 10:36:15 -0800 Kees Cook wrote:
> > > In preparation for FORTIFY_SOURCE performing compile-time and run-time
> > > field
On Thu, 18 Nov 2021 10:36:15 -0800 Kees Cook wrote:
> In preparation for FORTIFY_SOURCE performing compile-time and run-time
> field bounds checking for memcpy(), memmove(), and memset(), avoid
> intentionally writing across neighboring fields.
>
> Replace the existing empty member position marker
On Sat, 7 Nov 2020 21:48:13 +0100 Heiner Kallweit wrote:
> It's a frequent pattern to use netdev->stats for the less frequently
> accessed counters and per-cpu counters for the frequently accessed
> counters (rx/tx bytes/packets). Add a default ndo_get_stats64()
> implementation for this use case.
On Fri, 6 Nov 2020 09:27:45 +0100 Heiner Kallweit wrote:
> On 06.11.2020 08:48, Heiner Kallweit wrote:
> > On 06.11.2020 02:14, Jakub Kicinski wrote:
> >> On Wed, 4 Nov 2020 15:25:24 +0100 Heiner Kallweit wrote:
> >>> @@ -1066,7 +1054,7 @@ static netdev_tx
On Wed, 4 Nov 2020 15:25:24 +0100 Heiner Kallweit wrote:
> @@ -1066,7 +1054,7 @@ static netdev_tx_t tun_net_xmit(struct sk_buff *skb,
> struct net_device *dev)
> return NETDEV_TX_OK;
>
> drop:
> - this_cpu_inc(tun->pcpu_stats->tx_dropped);
> + dev->stats.tx_dropped++;
> skb_
19 matches
Mail list logo
