[lkml]   [2018]   [Oct]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH 3/3] kernel/workqueue: Suppress a false positive lockdep complaint
On Thu, Oct 25, 2018 at 09:59:38PM +0200, Johannes Berg wrote:
> > So, thinking about this more, can you guarantee (somehow) that the
> > workqueue is empty at this point?
> (I hadn't looked at the code then - obviously that's guaranteed)

We can guarantee it from someone who is looking at the code path. In

if (!sb->s_dio_done_wq)
return sb_init_dio_done_wq(sb);

And then sb_init_dio_done_wq:

int sb_init_dio_done_wq(struct super_block *sb)
struct workqueue_struct *old;
struct workqueue_struct *wq = alloc_workqueue("dio/%s",
if (!wq)
return -ENOMEM;
* This has to be atomic as more DIOs can race to create the workqueue
old = cmpxchg(&sb->s_dio_done_wq, NULL, wq);
/* Someone created workqueue before us? Free ours... */
if (old)
return 0;

The race found in the syzbot reproducer has multiple threads all
running DIO writes at the same time. So we have multiple threads
calling sb_init_dio_done_wq, but all but one will lose the race, and
then call destry_workqueue on the freshly created (but never used)

We could replace the destroy_workqueue(wq) with a

Or, as Tejun suggested, "destroy_workqueue_skip_drain(wq)", but there is
no way for the workqueue code to know whether the caller was using the
interface correctly. So this basically becomes a philosophical
question about whether or not we trust the caller to be correct or

I don't see an obvious way that we can test to make sure the workqueue
is never used without actually taking a performance. Am I correct
that we would need to take the wq->mutex before we can mess with the
wq->flags field?

- Ted

 \ /
  Last update: 2018-10-25 22:21    [W:0.094 / U:6.328 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site