[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20151124100650.GF10750@pathway.suse.cz>
Date: Tue, 24 Nov 2015 11:06:50 +0100
From: Petr Mladek <pmladek@...e.com>
To: Tejun Heo <tj@...nel.org>
Cc: Andrew Morton <akpm@...ux-foundation.org>,
Oleg Nesterov <oleg@...hat.com>,
Ingo Molnar <mingo@...hat.com>,
Peter Zijlstra <peterz@...radead.org>,
Steven Rostedt <rostedt@...dmis.org>,
"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
Josh Triplett <josh@...htriplett.org>,
Thomas Gleixner <tglx@...utronix.de>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Jiri Kosina <jkosina@...e.cz>, Borislav Petkov <bp@...e.de>,
Michal Hocko <mhocko@...e.cz>, linux-mm@...ck.org,
Vlastimil Babka <vbabka@...e.cz>, linux-api@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3 07/22] kthread: Detect when a kthread work is used by
more workers
On Mon 2015-11-23 17:27:03, Tejun Heo wrote:
> Hello,
>
> On Wed, Nov 18, 2015 at 02:25:12PM +0100, Petr Mladek wrote:
> > @@ -610,6 +625,12 @@ repeat:
> > if (work) {
> > __set_current_state(TASK_RUNNING);
> > work->func(work);
> > +
> > + spin_lock_irq(&worker->lock);
> > + /* Allow to queue the work into another worker */
> > + if (!kthread_work_pending(work))
> > + work->worker = NULL;
> > + spin_unlock_irq(&worker->lock);
>
> Doesn't this mean that the work item can't be freed from its callback?
> That pattern tends to happen regularly.
I am not sure if I understand your question. Do you mean switching
work->func during the life time of the struct kthread_work? This
should not be affected by the above code.
The above code allows to queue an _unused_ kthread_work into any
kthread_worker. For example, it is needed for khugepaged,
see http://marc.info/?l=linux-kernel&m=144785344924871&w=2
The work is static but the worker can be started/stopped
(allocated/freed) repeatedly. It means that the work need
to be usable with many workers. But it is associated only
with one worker when being used.
If the work is in use (pending or being proceed), we must not
touch work->worker. Otherwise there might be a race. Because
all the operations with the work are synchronized using
work->worker->lock.
I hope that it makes sense.
Thanks a lot for feedback,
Petr
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists