* Re: possible deadlock in blk_trace_remove [not found] <001a1141f8dc4440a9055e53896e@google.com> @ 2017-11-19 18:50 ` Jens Axboe 2017-12-03 20:24 ` Eric Biggers 1 sibling, 0 replies; 6+ messages in thread From: Jens Axboe @ 2017-11-19 18:50 UTC (permalink / raw) To: syzbot, linux-block, linux-kernel, mingo, rostedt, syzkaller-bugs On 11/19/2017 03:36 AM, syzbot wrote: > Hello, > > syzkaller hit the following crash on > d9e0e63d9a6f88440eb201e1491fcf730272c706 > git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/master > compiler: gcc (GCC) 7.1.1 20170620 > .config is attached > Raw console output is attached. > > Unfortunately, I don't have any reproducer for this bug yet.> > > Use struct sctp_sack_info instead > > ============================================ > WARNING: possible recursive locking detected > 4.14.0-rc8-next-20171110+ #40 Not tainted > -------------------------------------------- > syz-executor6/21462 is trying to acquire lock: > (&q->blk_trace_mutex){+.+.}, at: [<ffffffff81760261>] > blk_trace_remove+0x21/0x40 kernel/trace/blktrace.c:373 > > but task is already holding lock: > (&q->blk_trace_mutex){+.+.}, at: [<ffffffff81763b38>] > blk_trace_setup+0x38/0x70 kernel/trace/blktrace.c:606 > > other info that might help us debug this: > Possible unsafe locking scenario: > > CPU0 > ---- > lock(&q->blk_trace_mutex); > lock(&q->blk_trace_mutex); The below should fix it. diff --git a/kernel/trace/blktrace.c b/kernel/trace/blktrace.c index 206e0e2ace53..f224985de5fa 100644 --- a/kernel/trace/blktrace.c +++ b/kernel/trace/blktrace.c @@ -591,7 +591,7 @@ static int __blk_trace_setup(struct request_queue *q, char *name, dev_t dev, return ret; if (copy_to_user(arg, &buts, sizeof(buts))) { - blk_trace_remove(q); + __blk_trace_remove(q); return -EFAULT; } return 0; @@ -637,7 +637,7 @@ static int compat_blk_trace_setup(struct request_queue *q, char *name, return ret; if (copy_to_user(arg, &buts.name, ARRAY_SIZE(buts.name))) { - blk_trace_remove(q); + __blk_trace_remove(q); return -EFAULT; } -- Jens Axboe ^ permalink raw reply related [flat|nested] 6+ messages in thread
* Re: possible deadlock in blk_trace_remove [not found] <001a1141f8dc4440a9055e53896e@google.com> 2017-11-19 18:50 ` possible deadlock in blk_trace_remove Jens Axboe @ 2017-12-03 20:24 ` Eric Biggers 2017-12-04 0:24 ` Jens Axboe 1 sibling, 1 reply; 6+ messages in thread From: Eric Biggers @ 2017-12-03 20:24 UTC (permalink / raw) To: syzbot; +Cc: axboe, linux-block, linux-kernel, mingo, rostedt, syzkaller-bugs On Sun, Nov 19, 2017 at 02:36:01AM -0800, syzbot wrote: > Hello, > > syzkaller hit the following crash on > d9e0e63d9a6f88440eb201e1491fcf730272c706 > git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/master > compiler: gcc (GCC) 7.1.1 20170620 > .config is attached > Raw console output is attached. > > Unfortunately, I don't have any reproducer for this bug yet. > > > Use struct sctp_sack_info instead > > ============================================ > WARNING: possible recursive locking detected > 4.14.0-rc8-next-20171110+ #40 Not tainted > -------------------------------------------- > syz-executor6/21462 is trying to acquire lock: > (&q->blk_trace_mutex){+.+.}, at: [<ffffffff81760261>] > blk_trace_remove+0x21/0x40 kernel/trace/blktrace.c:373 > > but task is already holding lock: > (&q->blk_trace_mutex){+.+.}, at: [<ffffffff81763b38>] > blk_trace_setup+0x38/0x70 kernel/trace/blktrace.c:606 > > other info that might help us debug this: > Possible unsafe locking scenario: #syz fix: blktrace: fix trace mutex deadlock ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: possible deadlock in blk_trace_remove 2017-12-03 20:24 ` Eric Biggers @ 2017-12-04 0:24 ` Jens Axboe 2017-12-04 0:44 ` Eric Biggers 0 siblings, 1 reply; 6+ messages in thread From: Jens Axboe @ 2017-12-04 0:24 UTC (permalink / raw) To: Eric Biggers, syzbot Cc: linux-block, linux-kernel, mingo, rostedt, syzkaller-bugs On 12/03/2017 01:24 PM, Eric Biggers wrote: > On Sun, Nov 19, 2017 at 02:36:01AM -0800, syzbot wrote: >> Hello, >> >> syzkaller hit the following crash on >> d9e0e63d9a6f88440eb201e1491fcf730272c706 >> git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/master >> compiler: gcc (GCC) 7.1.1 20170620 >> .config is attached >> Raw console output is attached. >> >> Unfortunately, I don't have any reproducer for this bug yet. >> >> >> Use struct sctp_sack_info instead >> >> ============================================ >> WARNING: possible recursive locking detected >> 4.14.0-rc8-next-20171110+ #40 Not tainted >> -------------------------------------------- >> syz-executor6/21462 is trying to acquire lock: >> (&q->blk_trace_mutex){+.+.}, at: [<ffffffff81760261>] >> blk_trace_remove+0x21/0x40 kernel/trace/blktrace.c:373 >> >> but task is already holding lock: >> (&q->blk_trace_mutex){+.+.}, at: [<ffffffff81763b38>] >> blk_trace_setup+0x38/0x70 kernel/trace/blktrace.c:606 >> >> other info that might help us debug this: >> Possible unsafe locking scenario: > > #syz fix: blktrace: fix trace mutex deadlock This is fixed in current -git. -- Jens Axboe ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: possible deadlock in blk_trace_remove 2017-12-04 0:24 ` Jens Axboe @ 2017-12-04 0:44 ` Eric Biggers 2017-12-04 0:47 ` Jens Axboe 0 siblings, 1 reply; 6+ messages in thread From: Eric Biggers @ 2017-12-04 0:44 UTC (permalink / raw) To: Jens Axboe Cc: syzbot, linux-block, linux-kernel, mingo, rostedt, syzkaller-bugs On Sun, Dec 03, 2017 at 05:24:32PM -0700, Jens Axboe wrote: > On 12/03/2017 01:24 PM, Eric Biggers wrote: > > On Sun, Nov 19, 2017 at 02:36:01AM -0800, syzbot wrote: > >> Hello, > >> > >> syzkaller hit the following crash on > >> d9e0e63d9a6f88440eb201e1491fcf730272c706 > >> git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/master > >> compiler: gcc (GCC) 7.1.1 20170620 > >> .config is attached > >> Raw console output is attached. > >> > >> Unfortunately, I don't have any reproducer for this bug yet. > >> > >> > >> Use struct sctp_sack_info instead > >> > >> ============================================ > >> WARNING: possible recursive locking detected > >> 4.14.0-rc8-next-20171110+ #40 Not tainted > >> -------------------------------------------- > >> syz-executor6/21462 is trying to acquire lock: > >> (&q->blk_trace_mutex){+.+.}, at: [<ffffffff81760261>] > >> blk_trace_remove+0x21/0x40 kernel/trace/blktrace.c:373 > >> > >> but task is already holding lock: > >> (&q->blk_trace_mutex){+.+.}, at: [<ffffffff81763b38>] > >> blk_trace_setup+0x38/0x70 kernel/trace/blktrace.c:606 > >> > >> other info that might help us debug this: > >> Possible unsafe locking scenario: > > > > #syz fix: blktrace: fix trace mutex deadlock > > This is fixed in current -git. > I know, but syzbot needed to be told what commit fixes the bug. See https://github.com/google/syzkaller/blob/master/docs/syzbot.md ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: possible deadlock in blk_trace_remove 2017-12-04 0:44 ` Eric Biggers @ 2017-12-04 0:47 ` Jens Axboe 2017-12-04 3:47 ` Mike Galbraith 0 siblings, 1 reply; 6+ messages in thread From: Jens Axboe @ 2017-12-04 0:47 UTC (permalink / raw) To: Eric Biggers Cc: syzbot, linux-block, linux-kernel, mingo, rostedt, syzkaller-bugs On 12/03/2017 05:44 PM, Eric Biggers wrote: > On Sun, Dec 03, 2017 at 05:24:32PM -0700, Jens Axboe wrote: >> On 12/03/2017 01:24 PM, Eric Biggers wrote: >>> On Sun, Nov 19, 2017 at 02:36:01AM -0800, syzbot wrote: >>>> Hello, >>>> >>>> syzkaller hit the following crash on >>>> d9e0e63d9a6f88440eb201e1491fcf730272c706 >>>> git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/master >>>> compiler: gcc (GCC) 7.1.1 20170620 >>>> .config is attached >>>> Raw console output is attached. >>>> >>>> Unfortunately, I don't have any reproducer for this bug yet. >>>> >>>> >>>> Use struct sctp_sack_info instead >>>> >>>> ============================================ >>>> WARNING: possible recursive locking detected >>>> 4.14.0-rc8-next-20171110+ #40 Not tainted >>>> -------------------------------------------- >>>> syz-executor6/21462 is trying to acquire lock: >>>> (&q->blk_trace_mutex){+.+.}, at: [<ffffffff81760261>] >>>> blk_trace_remove+0x21/0x40 kernel/trace/blktrace.c:373 >>>> >>>> but task is already holding lock: >>>> (&q->blk_trace_mutex){+.+.}, at: [<ffffffff81763b38>] >>>> blk_trace_setup+0x38/0x70 kernel/trace/blktrace.c:606 >>>> >>>> other info that might help us debug this: >>>> Possible unsafe locking scenario: >>> >>> #syz fix: blktrace: fix trace mutex deadlock >> >> This is fixed in current -git. >> > > I know, but syzbot needed to be told what commit fixes the bug. > See https://github.com/google/syzkaller/blob/master/docs/syzbot.md Ah gotcha. -- Jens Axboe ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: possible deadlock in blk_trace_remove 2017-12-04 0:47 ` Jens Axboe @ 2017-12-04 3:47 ` Mike Galbraith 0 siblings, 0 replies; 6+ messages in thread From: Mike Galbraith @ 2017-12-04 3:47 UTC (permalink / raw) To: Jens Axboe, Eric Biggers Cc: syzbot, linux-block, linux-kernel, mingo, rostedt, syzkaller-bugs On Sun, 2017-12-03 at 17:47 -0700, Jens Axboe wrote: > On 12/03/2017 05:44 PM, Eric Biggers wrote: > > > >>> #syz fix: blktrace: fix trace mutex deadlock > >> > >> This is fixed in current -git. > >> > > > > I know, but syzbot needed to be told what commit fixes the bug. > > See https://github.com/google/syzkaller/blob/master/docs/syzbot.md > > Ah gotcha. "@syzbot fix: bla" syntax would have been intuitive. -Mike ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2017-12-04 3:48 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <001a1141f8dc4440a9055e53896e@google.com>
2017-11-19 18:50 ` possible deadlock in blk_trace_remove Jens Axboe
2017-12-03 20:24 ` Eric Biggers
2017-12-04 0:24 ` Jens Axboe
2017-12-04 0:44 ` Eric Biggers
2017-12-04 0:47 ` Jens Axboe
2017-12-04 3:47 ` Mike Galbraith
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).