ossible deadlock in
> > > console_lock_spinning_enable”[1] and "possible deadlock in
> > > console_unlock"[2] should share the same root cause.
> > >
> > > The reasons for the above statement:
> > > 1) the stack trace is the same, and this title
On Thu, Jan 21, 2021 at 8:49 PM Lukas Bulwahn wrote:
>
> On Thu, Jan 21, 2021 at 6:37 AM 慕冬亮 wrote:
> >
> > Dear kernel developers,
> >
> > I found that on the syzbot dashboard, “possible deadlock in
> > console_lock_spinning_enable”[1] and "possible
On Thu, Jan 21, 2021 at 6:37 AM 慕冬亮 wrote:
>
> Dear kernel developers,
>
> I found that on the syzbot dashboard, “possible deadlock in
> console_lock_spinning_enable”[1] and "possible deadlock in
> console_unlock"[2] should share the same root cause.
>
> The re
On Thu, Jan 21, 2021 at 01:37:05PM +0800, 慕冬亮 wrote:
> Dear kernel developers,
>
> I found that on the syzbot dashboard, “possible deadlock in
> console_lock_spinning_enable”[1] and "possible deadlock in
> console_unlock"[2] should share the same root cause.
>
Dear kernel developers,
I found that on the syzbot dashboard, “possible deadlock in
console_lock_spinning_enable”[1] and "possible deadlock in
console_unlock"[2] should share the same root cause.
The reasons for the above statement:
1) the stack trace is the same, and this title dif
FTR, this topic seems to be moved to
https://lkml.kernel.org/r/ebc01f4f-5b1d-4f8a-1d0d-463d5218e...@huawei.com .
On 2/19/2019 9:32 AM, Sergey Senozhatsky wrote:
> On (02/18/19 22:07), Yao HongBo wrote:
I have tried GFP_NOWARN, but the problem still exists.
Only print_safe contexts for tty locks can solve the problem.
My test scenario is falt-injection.
>>>
>>> Oh, I see. Yes, fault-injection
On (02/18/19 22:07), Yao HongBo wrote:
> >> I have tried GFP_NOWARN, but the problem still exists.
> >> Only print_safe contexts for tty locks can solve the problem.
> >> My test scenario is falt-injection.
> >
> > Oh, I see. Yes, fault-injection is special.
> >
> > I suspect that this patch seri
On 2/18/2019 1:46 PM, Sergey Senozhatsky wrote:
> Hi,
>
> On (02/16/19 15:59), Yao HongBo wrote:
>>> GFP_NOWARN is probably the best option for now. Yes, it, maybe,
>>> will not work for fault-injection cases; but printk_safe approach
>>> is harder to push for, especially given that printk_safe
On 2/18/2019 1:46 PM, Sergey Senozhatsky wrote:
> Hi,
>
> On (02/16/19 15:59), Yao HongBo wrote:
>>> GFP_NOWARN is probably the best option for now. Yes, it, maybe,
>>> will not work for fault-injection cases; but printk_safe approach
>>> is harder to push for, especially given that printk_safe
Hi,
On (02/16/19 15:59), Yao HongBo wrote:
> > GFP_NOWARN is probably the best option for now. Yes, it, maybe,
> > will not work for fault-injection cases; but printk_safe approach
> > is harder to push for, especially given that printk_safe maybe will
> > not even exist in the future.
>
> I have
On 2/16/2019 3:46 PM, Sergey Senozhatsky wrote:
> On (02/16/19 16:21), Sergey Senozhatsky wrote:
>> On (02/16/19 14:36), Yao HongBo wrote:
>>> hi, sergey:
>>>
>>> As shown in that link, https://lkml.org/lkml/2018/6/6/397
>>>
>>> On the linux
On (02/16/19 16:21), Sergey Senozhatsky wrote:
> On (02/16/19 14:36), Yao HongBo wrote:
> > hi, sergey:
> >
> > As shown in that link, https://lkml.org/lkml/2018/6/6/397
> >
> > On the linux kernel 5.0-rc6, Syzkaller also hit 'possible deadlock in
> &g
On (02/16/19 14:36), Yao HongBo wrote:
> hi, sergey:
>
> As shown in that link, https://lkml.org/lkml/2018/6/6/397
>
> On the linux kernel 5.0-rc6, Syzkaller also hit 'possible deadlock in
> console_unlock'
> bug for several times in my environment.
>
>
hi, sergey:
As shown in that link, https://lkml.org/lkml/2018/6/6/397
On the linux kernel 5.0-rc6, Syzkaller also hit 'possible deadlock in
console_unlock'
bug for several times in my environment.
This solution fixes things for me. Do you have a plan to submit patches to
solve th
On (06/19/18 10:04), Petr Mladek wrote:
> > >
> > > We could allow nesting. It is just a matter of how many bits we
> > > reserve for it in printk_context variable.
> > [..]
> > > In each case, I would like to keep the printk_safe context usage
> > > at minimum. It has its own problems caused by l
On Fri 2018-06-15 17:38:04, Sergey Senozhatsky wrote:
> On (06/08/18 10:18), Petr Mladek wrote:
> [..]
> > > Could be.
> > > The good thing about printk_safe is that printk_safe sections can nest.
> > > I suspect there might be locks/printk_safe sections nesting at some
> > > point. In any case, sw
On (06/08/18 10:18), Petr Mladek wrote:
[..]
> > Could be.
> > The good thing about printk_safe is that printk_safe sections can nest.
> > I suspect there might be locks/printk_safe sections nesting at some
> > point. In any case, switching to a new flavor of printk_safe will be
> > pretty easy - j
On Thu 2018-06-07 23:01:00, Sergey Senozhatsky wrote:
> On (06/07/18 13:00), Petr Mladek wrote:
> > > Another way could be - switch to printk_safe mode around that
> > > kmalloc():
> > >
> > > __printk_safe_enter();
> > > kmalloc(sizeof(struct tty_buffer) + 2 * size, GFP_ATOMIC);
> > > __pri
On (06/07/18 20:40), Tetsuo Handa wrote:
> >> diff --git a/drivers/tty/tty_buffer.c b/drivers/tty/tty_buffer.c
> >> index c996b6859c5e..71958ef6a831 100644
> >> --- a/drivers/tty/tty_buffer.c
> >> +++ b/drivers/tty/tty_buffer.c
> >> @@ -167,7 +167,8 @@ static struct tty_buffer *tty_buffer_alloc(str
On (06/07/18 13:00), Petr Mladek wrote:
> > IOW
> >
> > tty ioctl
> > tty_port->lock IRQ
> > printk uart_port->lock
> > console_owner
> > uart_port->lock tty_port->rlock
>
> Great analyze!
Thanks!
> I am just afraid that there are many other
On 2018/06/07 20:00, Petr Mladek wrote:
>> ---
>>
>> drivers/tty/tty_buffer.c | 3 ++-
>> 1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/tty/tty_buffer.c b/drivers/tty/tty_buffer.c
>> index c996b6859c5e..71958ef6a831 100644
>> --- a/drivers/tty/tty_buffer.c
>> +++ b/driv
On Thu 2018-06-07 14:10:19, Sergey Senozhatsky wrote:
> Cc-ing more people
> Link: lkml.kernel.org/r/87008b056df8f...@google.com
>
> On (06/06/18 06:17), syzbot wrote:
> > Hello,
> >
> > syzbot found the following crash on:
> >
> > HEAD commit:af6c5d5e01ad Merge branch 'for-4.18'
Cc-ing more people
Link: lkml.kernel.org/r/87008b056df8f...@google.com
On (06/06/18 06:17), syzbot wrote:
> Hello,
>
> syzbot found the following crash on:
>
> HEAD commit:af6c5d5e01ad Merge branch 'for-4.18' of git://git.kernel.o..
> git tree: upstream
> console output: ht
syzbot has found a reproducer for the following crash on:
HEAD commit:0ad39cb3d70f Merge tag 'kconfig-v4.18' of git://git.kernel..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=1158868f80
kernel config: https://syzkaller.appspot.com/x/.config?x=b9a1f3
Hello,
syzbot found the following crash on:
HEAD commit:af6c5d5e01ad Merge branch 'for-4.18' of git://git.kernel.o..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=173d93ef80
kernel config: https://syzkaller.appspot.com/x/.config?x=12ff770540994680
da
26 matches
Mail list logo
