On Thu, 2018-10-25 at 13:39 -0700, Bart Van Assche wrote:
>
> > +void flush_workqueue_nested(struct workqueue_struct *wq, int subclass)
> > {
> > struct wq_flusher this_flusher = {
> > .list = LIST_HEAD_INIT(this_flusher.list),
> > @@ -2652,7 +2653,7 @@ void
On Thu, 2018-10-25 at 13:39 -0700, Bart Van Assche wrote:
>
> > +void flush_workqueue_nested(struct workqueue_struct *wq, int subclass)
> > {
> > struct wq_flusher this_flusher = {
> > .list = LIST_HEAD_INIT(this_flusher.list),
> > @@ -2652,7 +2653,7 @@ void
On Thu, 2018-10-25 at 21:51 +0200, Johannes Berg wrote:
> [ ... ]
> diff --git a/fs/direct-io.c b/fs/direct-io.c
> index 093fb54cd316..9ef33d6cba56 100644
> --- a/fs/direct-io.c
> +++ b/fs/direct-io.c
> @@ -629,9 +629,16 @@ int sb_init_dio_done_wq(struct super_block *sb)
>* This has to be
On Thu, 2018-10-25 at 21:51 +0200, Johannes Berg wrote:
> [ ... ]
> diff --git a/fs/direct-io.c b/fs/direct-io.c
> index 093fb54cd316..9ef33d6cba56 100644
> --- a/fs/direct-io.c
> +++ b/fs/direct-io.c
> @@ -629,9 +629,16 @@ int sb_init_dio_done_wq(struct super_block *sb)
>* This has to be
On Thu, 2018-10-25 at 16:21 -0400, Theodore Y. Ts'o wrote:
> We can guarantee it from someone who is looking at the code path. In
> dio_set_defer_completion:
[snip]
Right, it's indeed pretty obvious. I shouldn't have tried to reply
before the kids went to bed, that made me cut some corners ;-)
On Thu, 2018-10-25 at 16:21 -0400, Theodore Y. Ts'o wrote:
> We can guarantee it from someone who is looking at the code path. In
> dio_set_defer_completion:
[snip]
Right, it's indeed pretty obvious. I shouldn't have tried to reply
before the kids went to bed, that made me cut some corners ;-)
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
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
On Thu, 2018-10-25 at 15:36 +, Tejun Heo wrote:
> We
> wanna annotate the users for the exceptions rather than weakening the
> workqueue lockdep checks, especially because workqueue related
> deadlocks can be pretty difficult to trigger and root cause
> afterwards.
I think you just said more
On Thu, 2018-10-25 at 15:36 +, Tejun Heo wrote:
> We
> wanna annotate the users for the exceptions rather than weakening the
> workqueue lockdep checks, especially because workqueue related
> deadlocks can be pretty difficult to trigger and root cause
> afterwards.
I think you just said more
On Thu, 2018-10-25 at 08:55 -0700, Bart Van Assche wrote:
> Please have a look at the call trace in the description of this patch and also
> at the direct I/O code. The lockdep complaint in the description of this patch
> really is a false positive.
I agree. I just don't agree that it's a false
On Thu, 2018-10-25 at 08:55 -0700, Bart Van Assche wrote:
> Please have a look at the call trace in the description of this patch and also
> at the direct I/O code. The lockdep complaint in the description of this patch
> really is a false positive.
I agree. I just don't agree that it's a false
On Thu, 2018-10-25 at 10:11 -0700, Bart Van Assche wrote:
> On Thu, 2018-10-25 at 19:02 +0200, Johannes Berg wrote:
> > On Thu, 2018-10-25 at 15:05 +, Bart Van Assche wrote:
> > > It can happen that the direct I/O queue creates and destroys an empty
> > > workqueue from inside a work function.
On Thu, 2018-10-25 at 10:11 -0700, Bart Van Assche wrote:
> On Thu, 2018-10-25 at 19:02 +0200, Johannes Berg wrote:
> > On Thu, 2018-10-25 at 15:05 +, Bart Van Assche wrote:
> > > It can happen that the direct I/O queue creates and destroys an empty
> > > workqueue from inside a work function.
On Thu, 2018-10-25 at 19:02 +0200, Johannes Berg wrote:
> On Thu, 2018-10-25 at 15:05 +, Bart Van Assche wrote:
> > It can happen that the direct I/O queue creates and destroys an empty
> > workqueue from inside a work function.
>
> So, thinking about this more, can you guarantee (somehow)
On Thu, 2018-10-25 at 19:02 +0200, Johannes Berg wrote:
> On Thu, 2018-10-25 at 15:05 +, Bart Van Assche wrote:
> > It can happen that the direct I/O queue creates and destroys an empty
> > workqueue from inside a work function.
>
> So, thinking about this more, can you guarantee (somehow)
On Thu, 2018-10-25 at 15:05 +, Bart Van Assche wrote:
> It can happen that the direct I/O queue creates and destroys an empty
> workqueue from inside a work function.
So, thinking about this more, can you guarantee (somehow) that the
workqueue is empty at this point? Perhaps then we should
On Thu, 2018-10-25 at 15:05 +, Bart Van Assche wrote:
> It can happen that the direct I/O queue creates and destroys an empty
> workqueue from inside a work function.
So, thinking about this more, can you guarantee (somehow) that the
workqueue is empty at this point? Perhaps then we should
On Thu, 2018-10-25 at 17:34 +0200, Johannes Berg wrote:
> On Thu, 2018-10-25 at 15:05 +, Bart Van Assche wrote:
>
> > @@ -2889,7 +2893,7 @@ static bool start_flush_work(struct work_struct
> > *work, struct wq_barrier *barr,
> > * workqueues the deadlock happens when the rescuer stalls,
On Thu, 2018-10-25 at 17:34 +0200, Johannes Berg wrote:
> On Thu, 2018-10-25 at 15:05 +, Bart Van Assche wrote:
>
> > @@ -2889,7 +2893,7 @@ static bool start_flush_work(struct work_struct
> > *work, struct wq_barrier *barr,
> > * workqueues the deadlock happens when the rescuer stalls,
On Thu, Oct 25, 2018 at 08:05:40AM -0700, Bart Van Assche wrote:
> diff --git a/kernel/workqueue.c b/kernel/workqueue.c
> index fc9129d5909e..0ef275fe526c 100644
> --- a/kernel/workqueue.c
> +++ b/kernel/workqueue.c
> @@ -1383,6 +1383,10 @@ static void __queue_work(int cpu, struct
>
On Thu, Oct 25, 2018 at 08:05:40AM -0700, Bart Van Assche wrote:
> diff --git a/kernel/workqueue.c b/kernel/workqueue.c
> index fc9129d5909e..0ef275fe526c 100644
> --- a/kernel/workqueue.c
> +++ b/kernel/workqueue.c
> @@ -1383,6 +1383,10 @@ static void __queue_work(int cpu, struct
>
On Thu, Oct 25, 2018 at 08:36:57AM -0700, Tejun Heo wrote:
> Hello, Bart.
>
> On Thu, Oct 25, 2018 at 08:05:40AM -0700, Bart Van Assche wrote:
> > diff --git a/include/linux/workqueue.h b/include/linux/workqueue.h
> > index 60d673e15632..375ec764f148 100644
> > --- a/include/linux/workqueue.h
> >
On Thu, Oct 25, 2018 at 08:36:57AM -0700, Tejun Heo wrote:
> Hello, Bart.
>
> On Thu, Oct 25, 2018 at 08:05:40AM -0700, Bart Van Assche wrote:
> > diff --git a/include/linux/workqueue.h b/include/linux/workqueue.h
> > index 60d673e15632..375ec764f148 100644
> > --- a/include/linux/workqueue.h
> >
Hello, Bart.
On Thu, Oct 25, 2018 at 08:05:40AM -0700, Bart Van Assche wrote:
> diff --git a/include/linux/workqueue.h b/include/linux/workqueue.h
> index 60d673e15632..375ec764f148 100644
> --- a/include/linux/workqueue.h
> +++ b/include/linux/workqueue.h
> @@ -344,6 +344,7 @@ enum {
>
Hello, Bart.
On Thu, Oct 25, 2018 at 08:05:40AM -0700, Bart Van Assche wrote:
> diff --git a/include/linux/workqueue.h b/include/linux/workqueue.h
> index 60d673e15632..375ec764f148 100644
> --- a/include/linux/workqueue.h
> +++ b/include/linux/workqueue.h
> @@ -344,6 +344,7 @@ enum {
>
On Thu, 2018-10-25 at 15:05 +, Bart Van Assche wrote:
> @@ -2889,7 +2893,7 @@ static bool start_flush_work(struct work_struct *work,
> struct wq_barrier *barr,
>* workqueues the deadlock happens when the rescuer stalls, blocking
>* forward progress.
>*/
> - if
On Thu, 2018-10-25 at 15:05 +, Bart Van Assche wrote:
> @@ -2889,7 +2893,7 @@ static bool start_flush_work(struct work_struct *work,
> struct wq_barrier *barr,
>* workqueues the deadlock happens when the rescuer stalls, blocking
>* forward progress.
>*/
> - if
It can happen that the direct I/O queue creates and destroys an empty
workqueue from inside a work function. Avoid that this triggers the
false positive lockdep complaint shown below.
==
WARNING: possible circular locking dependency detected
It can happen that the direct I/O queue creates and destroys an empty
workqueue from inside a work function. Avoid that this triggers the
false positive lockdep complaint shown below.
==
WARNING: possible circular locking dependency detected
30 matches
Mail list logo
