On Thu, Aug 22, 2019 at 5:05 AM Eric Biggers wrote:
>
> On Mon, Aug 19, 2019 at 05:22:07AM -0700, syzbot wrote:
> > Hello,
> >
> > syzbot found the following crash on:
> >
> > HEAD commit:5181b473 net: phy: realtek: add NBase-T PHY auto-detection
> > git tree: net-next
> > console output
On Mon, Aug 19, 2019 at 05:22:07AM -0700, syzbot wrote:
> Hello,
>
> syzbot found the following crash on:
>
> HEAD commit:5181b473 net: phy: realtek: add NBase-T PHY auto-detection
> git tree: net-next
> console output: https://syzkaller.appspot.com/x/log.txt?x=156b731c60
> kernel c
On 7/12/19 1:55 AM, Peter Zijlstra wrote:
On Thu, Jul 11, 2019 at 11:53:12AM -0700, Bart Van Assche wrote:
On 7/10/19 3:09 PM, Peter Zijlstra wrote:
One thing I mentioned when Thomas did the unwinder API changes was
trying to move lockdep over to something like stackdepot.
We can't directly us
On Thu, Jul 11, 2019 at 11:53:12AM -0700, Bart Van Assche wrote:
> On 7/10/19 3:09 PM, Peter Zijlstra wrote:
> > One thing I mentioned when Thomas did the unwinder API changes was
> > trying to move lockdep over to something like stackdepot.
> >
> > We can't directly use stackdepot as is, because
On 7/10/19 3:09 PM, Peter Zijlstra wrote:
One thing I mentioned when Thomas did the unwinder API changes was
trying to move lockdep over to something like stackdepot.
We can't directly use stackdepot as is, because it uses locks and memory
allocation, but we could maybe add a lower level API to
On Wed, Jul 10, 2019 at 02:23:39PM -0700, Bart Van Assche wrote:
> As one can see in remove_class_from_lock_chain() there is already code
> present in lockdep for compacting the chain_hlocks[] array. Similar code
> is not yet available for the stack_trace[] array because I had not
> encountered any
On 7/10/19 1:47 PM, Eric Dumazet wrote:
>
>
> On 7/10/19 9:09 PM, Bart Van Assche wrote:
>> On 7/10/19 11:44 AM, Eric Dumazet wrote:
>>> If anything using workqueues in dynamically allocated objects can turn off
>>> lockdep,
>>> we have a serious issue.
>>
>> As far as I know that issue is only
On 7/10/19 9:09 PM, Bart Van Assche wrote:
> On 7/10/19 11:44 AM, Eric Dumazet wrote:
>> If anything using workqueues in dynamically allocated objects can turn off
>> lockdep,
>> we have a serious issue.
>
> As far as I know that issue is only hit by syzbot tests.
> Anyway, I see
> two poss
On 7/10/19 11:44 AM, Eric Dumazet wrote:
> If anything using workqueues in dynamically allocated objects can turn off
> lockdep,
> we have a serious issue.
As far as I know that issue is only hit by syzbot tests. Anyway, I see
two possible paths forward:
* Revert the patch that makes workqueues u
On 7/10/19 8:36 PM, Bart Van Assche wrote:
> On 7/10/19 11:02 AM, Eric Biggers wrote:
>> I already mentioned that io_uring triggers it too.
>>
>> Those are just 2 cases that syzbot happened to generate reproducers for. I
>> expect there are many others too, since many places in the kernel alloc
On 7/10/19 11:02 AM, Eric Biggers wrote:
> I already mentioned that io_uring triggers it too.
>
> Those are just 2 cases that syzbot happened to generate reproducers for. I
> expect there are many others too, since many places in the kernel allocate
> workqueues. AFAICS most are placed in static
On Wed, Jul 10, 2019 at 10:46:00AM -0700, Bart Van Assche wrote:
> On 7/10/19 10:21 AM, Eric Biggers wrote:
> > With my simplified reproducer, on commit 669de8bda87b ("kernel/workqueue:
> > Use
> > dynamic lockdep keys for workqueues") I see:
> >
> > WARNING: CPU: 3 PID: 189 at kernel/locking
On 7/10/19 10:21 AM, Eric Biggers wrote:
> With my simplified reproducer, on commit 669de8bda87b ("kernel/workqueue: Use
> dynamic lockdep keys for workqueues") I see:
>
> WARNING: CPU: 3 PID: 189 at kernel/locking/lockdep.c:747
> register_lock_class+0x4f6/0x580
>
> and then somewhat later
On Wed, Jul 10, 2019 at 10:00:59AM -0700, Eric Biggers wrote:
> On Wed, Jul 10, 2019 at 07:19:55AM -0700, Bart Van Assche wrote:
> > On 7/9/19 10:30 PM, Eric Biggers wrote:
> > > [Moved most people to Bcc; syzbot added way too many random people to
> > > this.]
> > >
> > > Hi Bart,
> > >
> > > O
On Wed, Jul 10, 2019 at 07:19:55AM -0700, Bart Van Assche wrote:
> On 7/9/19 10:30 PM, Eric Biggers wrote:
> > [Moved most people to Bcc; syzbot added way too many random people to this.]
> >
> > Hi Bart,
> >
> > On Sat, Mar 30, 2019 at 07:17:09PM -0700, Bart Van Assche wrote:
> > > On 3/30/19 2:
On 7/9/19 10:30 PM, Eric Biggers wrote:
[Moved most people to Bcc; syzbot added way too many random people to this.]
Hi Bart,
On Sat, Mar 30, 2019 at 07:17:09PM -0700, Bart Van Assche wrote:
On 3/30/19 2:58 PM, syzbot wrote:
syzbot has bisected this bug to:
commit 669de8bda87b92ab9a2fc663b3f
[Moved most people to Bcc; syzbot added way too many random people to this.]
Hi Bart,
On Sat, Mar 30, 2019 at 07:17:09PM -0700, Bart Van Assche wrote:
> On 3/30/19 2:58 PM, syzbot wrote:
> > syzbot has bisected this bug to:
> >
> > commit 669de8bda87b92ab9a2fc663b3f5743c2ad1ae9f
> > Author: Bart
On 3/30/19 2:58 PM, syzbot wrote:
syzbot has bisected this bug to:
commit 669de8bda87b92ab9a2fc663b3f5743c2ad1ae9f
Author: Bart Van Assche
Date: Thu Feb 14 23:00:54 2019 +
kernel/workqueue: Use dynamic lockdep keys for workqueues
bisection log: https://syzkaller.appspot.com/x/bise
syzbot has bisected this bug to:
commit 669de8bda87b92ab9a2fc663b3f5743c2ad1ae9f
Author: Bart Van Assche
Date: Thu Feb 14 23:00:54 2019 +
kernel/workqueue: Use dynamic lockdep keys for workqueues
bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=17f1bacd20
start commit
syzbot has found a reproducer for the following crash on:
HEAD commit:0e40da3e Merge tag 'kbuild-fixes-v5.1' of git://git.kernel..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=14d9123f20
kernel config: https://syzkaller.appspot.com/x/.config?x=8dcdce
On Mon, 2019-03-11 at 10:48 -0700, Linus Torvalds wrote:
> On Mon, Mar 11, 2019 at 8:19 AM Bart Van Assche wrote:
> >
> > I think this issue has been fixed by a commit that went upstream yesterday.
> > Hence:
> >
> > #syz fix: workqueue, lockdep: Fix an alloc_workqueue() error path
>
> Well, s
On Mon, Mar 11, 2019 at 8:19 AM Bart Van Assche wrote:
>
> I think this issue has been fixed by a commit that went upstream yesterday.
> Hence:
>
> #syz fix: workqueue, lockdep: Fix an alloc_workqueue() error path
Well, syzbot just reported a problem with that fix itself ("WARNING in
lockdep_unr
On Mon, 2019-03-11 at 06:26 -0700, syzbot wrote:
> syzbot has bisected this bug to:
>
> commit 669de8bda87b92ab9a2fc663b3f5743c2ad1ae9f
> Author: Bart Van Assche
> Date: Thu Feb 14 23:00:54 2019 +
>
> kernel/workqueue: Use dynamic lockdep keys for workqueues
>
> bisection log: https
syzbot has bisected this bug to:
commit 669de8bda87b92ab9a2fc663b3f5743c2ad1ae9f
Author: Bart Van Assche
Date: Thu Feb 14 23:00:54 2019 +
kernel/workqueue: Use dynamic lockdep keys for workqueues
bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=17dec75720
start commit
Probably more a lockdep than XFS thing..
On Fri, Mar 01, 2019 at 11:06:04PM -0800, syzbot wrote:
> Hello,
>
> syzbot found the following crash on:
>
> HEAD commit:c63e9e91a254 Add linux-next specific files for 20190301
> git tree: linux-next
> console output: https://syzkaller.appspot.
syzbot has found a reproducer for the following crash on:
HEAD commit:c63e9e91a254 Add linux-next specific files for 20190301
git tree: linux-next
console output: https://syzkaller.appspot.com/x/log.txt?x=1085615720
kernel config: https://syzkaller.appspot.com/x/.config?x=f5875f9dc
26 matches
Mail list logo
