On Sat, Apr 17, 2021 at 9:41 PM Cong Wang wrote:
>
> From: Cong Wang
>
> We hit a divide error in rwb_arm_timer() and crash dump shows
> rqd->scale_step is 16777215 (0xff in hex), so the expression
> "(rqd->scale_step + 1) << 8)" is 0x1, whi
From: Cong Wang
We hit a divide error in rwb_arm_timer() and crash dump shows
rqd->scale_step is 16777215 (0xff in hex), so the expression
"(rqd->scale_step + 1) << 8)" is 0x1, which is just beyond
32-bit integer range, hence it is truncated to 0 and int_sqrt(0
On Fri, Apr 9, 2021 at 12:45 PM John Fastabend wrote:
>
> syzbot wrote:
> > Hello,
> >
> > syzbot found the following issue on:
> >
> > HEAD commit:9c54130c Add linux-next specific files for 20210406
> > git tree: linux-next
> > console output:
On Wed, Apr 7, 2021 at 8:11 PM Stephen Rothwell wrote:
>
> Hi all,
>
> Today's linux-next merge of the net-next tree got a conflict in:
>
> net/core/skmsg.c
>
> between commit:
>
> 144748eb0c44 ("bpf, sockmap: Fix incorrect fwd_alloc accounting")
>
> from the bpf tree and commit:
>
>
On Wed, Apr 7, 2021 at 8:02 PM Stephen Rothwell wrote:
>
> Hi all,
>
> Today's linux-next merge of the net-next tree got a conflict in:
>
> include/linux/skmsg.h
>
> between commit:
>
> 1c84b33101c8 ("bpf, sockmap: Fix sk->prot unhash op reset")
>
> from the bpf tree and commit:
>
>
On Tue, Apr 6, 2021 at 6:01 AM syzbot
wrote:
> ==
> BUG: KASAN: use-after-free in __lock_acquire+0x3e6f/0x54c0
> kernel/locking/lockdep.c:4770
> Read of size 8 at addr 888024f66238 by task syz-executor.1/14202
>
> CPU: 0 PID:
On Tue, Apr 6, 2021 at 2:44 AM syzbot
wrote:
>
> Hello,
>
> syzbot found the following issue on:
>
> HEAD commit:514e1150 net: x25: Queue received packets in the drivers i..
> git tree: net-next
> console output: https://syzkaller.appspot.com/x/log.txt?x=112a8831d0
> kernel config:
On Sat, Apr 3, 2021 at 5:23 AM Jiri Kosina wrote:
>
> I am still planning to have Yunsheng Lin's (CCing) fix [1] tested in the
> coming days. If it works, then we can consider proceeding with it,
> otherwise I am all for reverting the whole NOLOCK stuff.
>
> [1]
>
On Mon, Mar 29, 2021 at 3:55 PM Kumar Kartikeya Dwivedi
wrote:
> diff --git a/net/sched/act_api.c b/net/sched/act_api.c
> index b919826939e0..43cceb924976 100644
> --- a/net/sched/act_api.c
> +++ b/net/sched/act_api.c
> @@ -1042,6 +1042,9 @@ struct tc_action *tcf_action_init_1(struct net *net,
>
On Tue, Mar 23, 2021 at 7:24 PM Yunsheng Lin wrote:
> @@ -176,8 +207,23 @@ static inline bool qdisc_run_begin(struct Qdisc *qdisc)
> static inline void qdisc_run_end(struct Qdisc *qdisc)
> {
> write_seqcount_end(>running);
> - if (qdisc->flags & TCQ_F_NOLOCK)
> + if
On Sun, Mar 21, 2021 at 5:55 PM Yunsheng Lin wrote:
>
> On 2021/3/20 2:15, Cong Wang wrote:
> > On Thu, Mar 18, 2021 at 12:33 AM Yunsheng Lin
> > wrote:
> >>
> >> On 2021/3/17 21:45, Jason A. Donenfeld wrote:
> >>> On 3/17/21, Toke Hø
On Sun, Mar 21, 2021 at 9:34 AM Pavel Machek wrote:
>
> dev_get_mac_address() does not always initialize whole
> structure. Unfortunately, other code copies such structure to
> userspace, leaking information. Fix it.
Well, most callers already initialize it with a memset() or copy_from_user(),
On Fri, Mar 19, 2021 at 2:25 AM Yunsheng Lin wrote:
> I had done some performance test to see if there is value to
> fix the packet stuck problem and support lockless qdisc bypass,
> here is some result using pktgen in 'queue_xmit' mode on a dummy
> device as Paolo Abeni had done in [1], and
On Wed, Mar 17, 2021 at 11:52 PM Yunsheng Lin wrote:
>
> Lockless qdisc has below concurrent problem:
> cpu0 cpu1
> . .
> q->enqueue .
> . .
>qdisc_run_begin().
> .
On Thu, Mar 18, 2021 at 12:33 AM Yunsheng Lin wrote:
>
> On 2021/3/17 21:45, Jason A. Donenfeld wrote:
> > On 3/17/21, Toke Høiland-Jørgensen wrote:
> >> Cong Wang writes:
> >>
> >>> On Mon, Mar 15, 2021 at 2:07 PM Jakub Kicinski wrote:
On Mon, Mar 15, 2021 at 2:07 PM Jakub Kicinski wrote:
>
> I thought pfifo was supposed to be "lockless" and this change
> re-introduces a lock between producer and consumer, no?
It has never been truly lockless, it uses two spinlocks in the ring buffer
implementation, and it introduced a
On Mon, Mar 15, 2021 at 4:42 PM David Miller wrote:
>
> From: Yunsheng Lin
> Date: Mon, 15 Mar 2021 17:30:10 +0800
>
> > Currently qdisc_lock(q) is taken before enqueuing and dequeuing
> > for lockless qdisc's skb_bad_txq/gso_skb queue, qdisc->seqlock is
> > also taken, which can provide the
On Mon, Mar 15, 2021 at 2:29 AM Yunsheng Lin wrote:
>
> Currently qdisc_lock(q) is taken before enqueuing and dequeuing
> for lockless qdisc's skb_bad_txq/gso_skb queue, qdisc->seqlock is
> also taken, which can provide the same protection as qdisc_lock(q).
>
> This patch removes the unnecessay
On Thu, Mar 4, 2021 at 6:44 AM Maximilian Heyne wrote:
>
> This is a follow up of commit ea3274695353 ("net: sched: avoid
> duplicates in qdisc dump") which has fixed the issue only for the qdisc
> dump.
>
> The duplicate printing also occurs when dumping the classes via
> tc class show dev
On Thu, Feb 25, 2021 at 5:39 PM Kefeng Wang wrote:
>
>
> On 2021/2/26 5:22, Cong Wang wrote:
> > On Wed, Feb 24, 2021 at 8:03 AM Kefeng Wang
> > wrote:
> >> HAVE_JUMP_LABLE is removed by commit e9666d10a567 ("jump_label: move
> >> 'asm goto' supp
On Thu, Feb 25, 2021 at 7:59 PM Xuesen Huang wrote:
> v3:
> - Fix the code format.
>
> v2:
> Suggested-by: Willem de Bruijn
> - Add a new flag to specify the type of the inner packet.
These need to be moved after '---', otherwise it would be merged
into the final git log.
>
> Suggested-by:
On Wed, Feb 24, 2021 at 8:03 AM Kefeng Wang wrote:
>
> HAVE_JUMP_LABLE is removed by commit e9666d10a567 ("jump_label: move
> 'asm goto' support test to Kconfig"), use CONFIG_JUMP_LABLE instead
> of HAVE_JUMP_LABLE.
>
> Fixes: 971502d77faa ("bridge: netfilter: unroll NF_HOOK helper in bridge
>
On Tue, Feb 23, 2021 at 6:55 AM syzbot
wrote:
>
> syzbot has found a reproducer for the following issue on:
>
> HEAD commit:a99163e9 Merge tag 'devicetree-for-5.12' of git://git.kern..
> git tree: upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=11a6fccad0
>
On Sat, Feb 20, 2021 at 11:32 AM Al Viro wrote:
>
> On Sat, Feb 20, 2021 at 11:12:33AM -0800, Cong Wang wrote:
> > On Thu, Feb 18, 2021 at 8:22 PM Al Viro wrote:
> > >
> > > Duplicated logics in all bind variants (autobind, bind-to-path,
> > > bind-to-ab
On Thu, Feb 18, 2021 at 8:22 PM Al Viro wrote:
>
> Duplicated logics in all bind variants (autobind, bind-to-path,
> bind-to-abstract) gets taken into a common helper.
>
> Signed-off-by: Al Viro
> ---
> net/unix/af_unix.c | 30 +++---
> 1 file changed, 15 insertions(+),
and-tested-by: syzbot+151e3e714d34ae4ce...@syzkaller.appspotmail.com
Reviewed-by: Cong Wang
Thanks.
On Wed, Feb 10, 2021 at 9:53 PM syzbot
wrote:
>
> syzbot has found a reproducer for the following issue on:
>
> HEAD commit:291009f6 Merge tag 'pm-5.11-rc8' of git://git.kernel.org/p..
> git tree: upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=14470d18d0
>
On Wed, Jan 27, 2021 at 4:56 PM Jakub Kicinski wrote:
>
> On Mon, 25 Jan 2021 22:10:10 +0200 Slava Bacherikov wrote:
> > Hi, I'd like to report a regression. Currently, if you create GRE
> > interface on the latest stable or LTS kernel (5.4 branch) with
> > unspecified remote destination it's MTU
On Fri, Jan 22, 2021 at 4:42 PM Tetsuo Handa
wrote:
>
> Hello, BPF developers.
>
> Alexey Kardashevskiy is reporting that system_wq gets stuck due to flooding of
> unbounded bpf_map_free_deferred work. Use of WQ_MEM_RECLAIM | WQ_HIGHPRI |
> WQ_UNBOUND
> workqueue did not solve this problem. Is
On Mon, Jan 11, 2021 at 11:33 AM Jakub Kicinski wrote:
>
> Looks like a AF_CAN socket:
>
> r0 = socket(0x1d, 0x2, 0x6)
> getsockname$packet(r0, &(0x7f000100)={0x11, 0x0, 0x0, 0x1, 0x0, 0x6,
> @broadcast}, &(0x7f00)=0x14)
>
Right, it seems we need a memset(0) in isotp_getname().
On Mon, Jan 4, 2021 at 7:29 AM Alan Maguire wrote:
>
> BPF Type Format (BTF) provides a description of kernel data structures
> and of the types kernel functions utilize as arguments and return values.
>
> A helper was recently added - bpf_snprintf_btf() - that uses that
> description to create a
gt;
> #syz invalid
>
> Hard to track down what fixed this, but the lockdep splat is mixing up
> locks from two different hashtables, so there was never a real issue
> here.
This one is probably fixed by:
commit ff93bca769925a2d8fd7f910cdf543d992e17f07
Author: Cong Wang
Date: Tue Aug 14 15:21:31 2018 -0700
ila: make lockdep happy again
given the time of last reproducing...
Thanks.
On Wed, Nov 4, 2020 at 10:04 PM Cong Wang wrote:
>
> On Mon, Nov 2, 2020 at 11:24 PM Yunsheng Lin wrote:
> > >> From my understanding, we can do anything about the old qdisc (including
> > >> destorying the old qdisc) after some_qdisc_is_busy() return false.
> &g
On Mon, Nov 2, 2020 at 11:24 PM Yunsheng Lin wrote:
> >> From my understanding, we can do anything about the old qdisc (including
> >> destorying the old qdisc) after some_qdisc_is_busy() return false.
> >
> > But the current code does the reset _before_ some_qdisc_is_busy(). ;)
>
> If lock is
On Fri, Oct 30, 2020 at 12:38 AM Yunsheng Lin wrote:
>
> On 2020/10/30 3:05, Cong Wang wrote:
> >
> > I do not see how and why it should. synchronize_net() is merely an optimized
> > version of synchronize_rcu(), it should wait for RCU readers, softirqs are
> > n
On Wed, Oct 28, 2020 at 7:54 PM Yunsheng Lin wrote:
>
> On 2020/9/18 3:26, Cong Wang wrote:
> > On Fri, Sep 11, 2020 at 1:13 AM Yunsheng Lin wrote:
> >>
> >> On 2020/9/11 4:07, Cong Wang wrote:
> >>> On Tue, Sep 8, 2020 at 4:06 AM Yunsheng
On Wed, Oct 28, 2020 at 8:37 AM Pai, Vishwanath wrote:
> Hi,
>
> We noticed some problems when testing the latest 5.4 LTS kernel and traced it
> back to this commit using git bisect. When running our tests the machine stops
> responding to all traffic and the only way to recover is a reboot. I do
On Wed, Oct 28, 2020 at 6:59 AM Tom Rix wrote:
>
>
> On 10/28/20 4:35 AM, Lukas Bulwahn wrote:
> > @@ -2971,13 +2963,11 @@ static int tc_dump_chain(struct sk_buff *skb,
> > struct netlink_callback *cb)
> > if (!dev)
> > return skb->len;
> >
> > -
On Mon, Oct 12, 2020 at 2:53 AM Muchun Song wrote:
> We are not complaining about TCP using too much memory, but how do
> we know that TCP uses a lot of memory. When I firstly face this problem,
> I do not know who uses the 25GB memory and it is not shown in the
> /proc/meminfo.
> If we can know
On Sun, Oct 11, 2020 at 9:22 PM Muchun Song wrote:
>
> On Mon, Oct 12, 2020 at 2:39 AM Cong Wang wrote:
> >
> > On Sat, Oct 10, 2020 at 3:39 AM Muchun Song
> > wrote:
> > >
> > > The amount of memory allocated to sockets buffer can become sig
#syz fix: net_sched: check error pointer in tcf_dump_walker()
On Sat, Oct 10, 2020 at 3:39 AM Muchun Song wrote:
>
> The amount of memory allocated to sockets buffer can become significant.
> However, we do not display the amount of memory consumed by sockets
> buffer. In this case, knowing where the memory is consumed by the kernel
We do it via `ss -m`.
#syz test: https://github.com/congwang/linux.git net
On Wed, Sep 30, 2020 at 10:42 AM syzbot
wrote:
>
> syzbot has found a reproducer for the following issue on:
>
> HEAD commit:2b3e981a Merge branch 'mptcp-Fix-for-32-bit-DATA_FIN'
> git tree: net
> console output: https://syzkaller.appspot.com/x/log.txt?x=1653724790
> kernel config:
#syz fix: net_sched: commit action insertions together
On Fri, Sep 25, 2020 at 2:56 AM John Garry wrote:
>
> This series contains a patch to solve the longterm IOVA issue which
> leizhen originally tried to address at [0].
>
> I also included the small optimisation from Cong Wang, which never seems
> to be have been accepted [
On Fri, Sep 11, 2020 at 1:13 AM Yunsheng Lin wrote:
>
> On 2020/9/11 4:07, Cong Wang wrote:
> > On Tue, Sep 8, 2020 at 4:06 AM Yunsheng Lin wrote:
> >>
> >> Currently there is concurrent reset and enqueue operation for the
> >> same lockless qdisc when the
On Sun, Sep 13, 2020 at 7:10 PM Yunsheng Lin wrote:
>
> On 2020/9/11 4:19, Cong Wang wrote:
> > On Thu, Sep 3, 2020 at 8:21 PM Kehuan Feng wrote:
> >> I also tried Cong's patch (shown below on my tree) and it could avoid
> >> the issue (stressing for 30 minutus
On Wed, Sep 16, 2020 at 11:05 PM Xiaoyong Yan wrote:
>
> in the function cbs_dequeue_soft, when q->credits <0, [now - q->last]
> should be accounted for sendslope,not idleslope.
>
> so the solution as follows: when q->credits is less than 0, directly
> calculate delay time, activate hrtimer and
On Wed, Sep 16, 2020 at 9:33 AM YueHaibing wrote:
>
> It is never used, so can remove it.
This is a bit confusing, it was actually used before, see commit
ab0d76f6823cc3a4e2.
On Thu, Sep 3, 2020 at 8:21 PM Kehuan Feng wrote:
> I also tried Cong's patch (shown below on my tree) and it could avoid
> the issue (stressing for 30 minutus for three times and not jitter
> observed).
Thanks for verifying it!
>
> --- ./include/net/sch_generic.h.orig 2020-08-21
On Thu, Sep 3, 2020 at 10:08 PM John Fastabend wrote:
> Maybe this would unlock us,
>
> diff --git a/net/core/dev.c b/net/core/dev.c
> index 7df6c9617321..9b09429103f1 100644
> --- a/net/core/dev.c
> +++ b/net/core/dev.c
> @@ -3749,7 +3749,7 @@ static inline int __dev_xmit_skb(struct sk_buff
On Tue, Sep 8, 2020 at 4:06 AM Yunsheng Lin wrote:
>
> Currently there is concurrent reset and enqueue operation for the
> same lockless qdisc when there is no lock to synchronize the
> q->enqueue() in __dev_xmit_skb() with the qdisc reset operation in
> qdisc_deactivate() called by
On Thu, Sep 3, 2020 at 2:47 AM Eric Dumazet wrote:
> This commit might be related :
>
> commit 4e407ff5cd67ec76a1deec227b7982dc7f66
> Author: Cong Wang
> Date: Sun Aug 19 12:22:12 2018 -0700
>
> act_ife: move tcfa_lock down to where necessary
It does not look l
On Thu, Sep 3, 2020 at 1:40 AM Paolo Abeni wrote:
>
> On Wed, 2020-09-02 at 22:01 -0700, Cong Wang wrote:
> > Can you test the attached one-line fix? I think we are overthinking,
> > probably all
> > we need here is a busy wait.
>
> I think that will solve, but I al
Hello, Kehuan
Can you test the attached one-line fix? I think we are overthinking,
probably all
we need here is a busy wait.
Thanks.
diff --git a/include/net/sch_generic.h b/include/net/sch_generic.h
index d60e7c39d60c..fc1bacdb102b 100644
--- a/include/net/sch_generic.h
+++
On Wed, Sep 2, 2020 at 7:22 PM Yunsheng Lin wrote:
>
> On 2020/9/3 9:48, Cong Wang wrote:
> > On Wed, Sep 2, 2020 at 6:22 PM Yunsheng Lin wrote:
> >>
> >> On 2020/9/3 8:35, Cong Wang wrote:
> >>> On Tue, Sep 1, 2020 at 11:35 PM Yunsheng Lin
> >
On Wed, Sep 2, 2020 at 6:22 PM Yunsheng Lin wrote:
>
> On 2020/9/3 8:35, Cong Wang wrote:
> > On Tue, Sep 1, 2020 at 11:35 PM Yunsheng Lin wrote:
> >>
> >> On 2020/9/2 12:41, Cong Wang wrote:
> >>> On Tue, Sep 1, 2020 at 6:42 PM Yunsheng Lin
> &g
On Tue, Sep 1, 2020 at 11:35 PM Yunsheng Lin wrote:
>
> On 2020/9/2 12:41, Cong Wang wrote:
> > On Tue, Sep 1, 2020 at 6:42 PM Yunsheng Lin wrote:
> >>
> >> On 2020/9/2 2:24, Cong Wang wrote:
> >>> On Mon, Aug 31, 2020 at 5:59 PM Yunsheng
On Tue, Sep 1, 2020 at 6:42 PM Yunsheng Lin wrote:
>
> On 2020/9/2 2:24, Cong Wang wrote:
> > On Mon, Aug 31, 2020 at 5:59 PM Yunsheng Lin wrote:
> >>
> >> Currently there is concurrent reset and enqueue operation for the
> >> same lockless qdisc when the
On Mon, Aug 31, 2020 at 5:59 PM Yunsheng Lin wrote:
>
> Currently there is concurrent reset and enqueue operation for the
> same lockless qdisc when there is no lock to synchronize the
> q->enqueue() in __dev_xmit_skb() with the qdisc reset operation in
> qdisc_deactivate() called by
On Sun, Aug 16, 2020 at 10:45 PM Christoph Hellwig wrote:
>
> On Sun, Aug 16, 2020 at 10:55:09AM -0700, Cong Wang wrote:
> > On Sun, Aug 16, 2020 at 1:36 AM Coly Li wrote:
> > >
> > > The original problem was from nvme-over-tcp code, who mistakenly uses
> &g
On Sun, Aug 16, 2020 at 1:36 AM Coly Li wrote:
>
> The original problem was from nvme-over-tcp code, who mistakenly uses
> kernel_sendpage() to send pages allocated by __get_free_pages() without
> __GFP_COMP flag. Such pages don't have refcount (page_count is 0) on
> tail pages, sending them by
On Wed, Aug 12, 2020 at 2:21 AM linmiaohe wrote:
>
> Hi all:
> David Miller wrote:
> >From: Cong Wang
> >Date: Tue, 11 Aug 2020 16:02:51 -0700
> >
> >>> @@ -3406,6 +3406,16 @@ static void sock_inuse_add(struct net *net,
> >>> int val) } #en
On Mon, Aug 10, 2020 at 5:19 AM Miaohe Lin wrote:
>
> If we failed to assign proto idx, we free the twsk_slab_name but forget to
> free the twsk_slab. Add a helper function tw_prot_cleanup() to free these
> together and also use this helper function in proto_unregister().
>
> Fixes: b45ce32135d1
On Mon, Aug 10, 2020 at 3:10 PM Peilin Ye wrote:
>
> do_ip_vs_set_ctl() is referencing uninitialized stack value when `len` is
> zero. Fix it.
Which exact 'cmd' is it here?
I _guess_ it is one of those uninitialized in set_arglen[], which is 0.
But if that is the case, should it be initialized
On Sat, Aug 8, 2020 at 10:07 AM Gaurav Singh wrote:
>
> This PR fixes a possible segmentation violation.
>
> In function: ip6_xmit(), we have
> const struct ipv6_pinfo *np = inet6_sk(sk); which returns NULL
> unconditionally (regardless sk being NULL or not).
>
> In include/linux/ipv6.h:
>
>
On Tue, Aug 4, 2020 at 9:14 AM wrote:
>
> From: Izabela Bakollari
>
> Dropwatch is a utility that monitors dropped frames by having userspace
> record them over the dropwatch protocol over a file. This augument
> allows live monitoring of dropped frames using tools like tcpdump.
>
> With this
Hello,
On Mon, Jul 27, 2020 at 12:41 PM Xie He wrote:
>
> Hi Cong Wang,
>
> I'm wishing to change a driver from using "hard_header_len" to using
> "needed_headroom" to declare its needed headroom. I submitted a patch
> and it is decided it needs
On Mon, Jul 27, 2020 at 7:14 PM Gaurav Singh wrote:
>
> Add return to fix build issue. Haven't reproduced this issue at
> my end.
>
> My hypothesis is this: In function: ip6_xmit(), we have
> const struct ipv6_pinfo *np = inet6_sk(sk); which returns NULL.
>
> Further down the function, there's a
On Sun, Jul 26, 2020 at 8:39 PM Gaurav Singh wrote:
>
> ipv6_pinfo is initlialized by inet6_sk() which returns NULL.
Why? It only returns NULL for timewait or request sock, but
I don't see how ip6_autoflowlabel() could be called on these
sockets. So please explain.
> Hence it can cause
On Sat, Jul 25, 2020 at 11:12 PM B K Karthik wrote:
>
> On Sun, Jul 26, 2020 at 11:05 AM Cong Wang wrote:
> >
> > On Sat, Jul 25, 2020 at 8:09 PM B K Karthik wrote:
> > > @@ -103,10 +103,10 @@ static int __xfrm6_tunnel_spi_check(struct net
> > > *net, u3
On Sat, Jul 25, 2020 at 8:09 PM B K Karthik wrote:
> @@ -103,10 +103,10 @@ static int __xfrm6_tunnel_spi_check(struct net *net,
> u32 spi)
> {
> struct xfrm6_tunnel_net *xfrm6_tn = xfrm6_tunnel_pernet(net);
> struct xfrm6_tunnel_spi *x6spi;
> - int index =
#syz test: https://github.com/congwang/linux.git net
#syz test: https://github.com/congwang/linux.git net
#syz test: https://github.com/congwang/linux.git net
On Tue, Jul 14, 2020 at 6:27 PM Weilong Chen wrote:
>
> When vlan_newlink call register_vlan_dev fails, it might return error
> with dev->reg_state = NETREG_UNREGISTERED. The rtnl_newlink should
> free the memory. But currently rtnl_newlink only free the memory which
> state is
On Tue, Jul 7, 2020 at 7:18 AM Paolo Abeni wrote:
> So the regression with 2 pktgen threads is still relevant. 'perf' shows
> relevant time spent into net_tx_action() and __netif_schedule().
So, touching the __QDISC_STATE_SCHED bit in __dev_xmit_skb() is
not a good idea.
Let me see if there is
On Wed, Jul 1, 2020 at 9:05 AM Cong Wang wrote:
>
> On Tue, Jun 30, 2020 at 2:08 PM Josh Hunt wrote:
> > Do either of you know if there's been any development on a fix for this
> > issue? If not we can propose something.
>
> If you have a reproducer, I can look into
On Tue, Jun 30, 2020 at 2:08 PM Josh Hunt wrote:
> Do either of you know if there's been any development on a fix for this
> issue? If not we can propose something.
If you have a reproducer, I can look into this.
Thanks.
On Tue, Jun 30, 2020 at 7:49 PM 孙世龙 sunshilong wrote:
>
> Hi, list
>
> My x86 machine(linux4.19) sometimes hangs, suddenly not responding in
> any way to the mouse or the keyboard.
>
> How can I investigate why it hung up? Is there extra information I can
> find for a clue? Is there anything less
#syz fix: genetlink: get rid of family->attrbuf
#syz fix: genetlink: get rid of family->attrbuf
#syz fix: genetlink: get rid of family->attrbuf
#syz fix: genetlink: get rid of family->attrbuf
#syz fix: genetlink: get rid of family->attrbuf
#syz fix: genetlink: get rid of family->attrbuf
#syz fix: genetlink: get rid of family->attrbuf
#syz fix: genetlink: get rid of family->attrbuf
#syz fix: genetlink: get rid of family->attrbuf
#syz fix: genetlink: get rid of family->attrbuf
On Mon, Jun 29, 2020 at 6:17 PM Jason A. Donenfeld wrote:
>
> Hey Cong,
Hi, Jason
>
> I'm wondering if the below error is related to what you've been
> looking at yesterday. AFAICT, there's a simple UaF on the attrbuf
> passed to the start method. I recall recently you were working on the
>
#syz test: https://github.com/congwang/linux.git net
#syz test: https://github.com/congwang/linux.git net
On Mon, Jun 1, 2020 at 11:47 PM YueHaibing wrote:
> @@ -630,6 +625,9 @@ static int genl_family_rcv_msg_dumpit(const struct
> genl_family *family,
> err = __netlink_dump_start(net->genl_sock, skb, nlh, );
> }
>
> + genl_family_rcv_msg_attrs_free(info->family,
see 552 bytes of stack usage for fl_classify(), plus 528 bytes
> for fl_mask_lookup().
>
> Fixes: 58cff782cc55 ("flow_dissector: Parse multiple MPLS Label Stack
> Entries")
> Signed-off-by: Arnd Bergmann
I think this is probably the quickest way to amend this warning,
so:
Acked-by: Cong Wang
Thanks.
On Fri, May 22, 2020 at 12:48 PM Randy Dunlap wrote:
>
> On 5/22/20 12:17 PM, Cong Wang wrote:
> > On Fri, May 22, 2020 at 12:03 PM Randy Dunlap wrote:
> >>
> >> From: Randy Dunlap
> >>
> >> Fix psample build error when CONFIG_INET is not set/ena
On Fri, May 22, 2020 at 12:03 PM Randy Dunlap wrote:
>
> From: Randy Dunlap
>
> Fix psample build error when CONFIG_INET is not set/enabled.
> PSAMPLE should depend on INET instead of NET since
> ip_tunnel_info_opts() is only present for CONFIG_INET.
>
> ../net/psample/psample.c: In function
On Fri, May 15, 2020 at 6:53 AM syzbot
wrote:
>
> Hello,
>
> syzbot found the following crash on:
>
> HEAD commit:99addbe3 net: broadcom: Select BROADCOM_PHY for BCMGENET
> git tree: net
> console output: https://syzkaller.appspot.com/x/log.txt?x=173e568c10
> kernel config:
On Sat, May 16, 2020 at 9:16 AM Subhashini Rao Beerisetty
wrote:
> Yes, those are out-of-tree modules. Basically, my question is, in
> general what is the difference between 'general protection fault' and
> 'Oops' failure in kernel mode.
For your case, they are likely just different consequences
1 - 100 of 1561 matches
Mail list logo
