linux-kernel - Re: [PATCH] backing_dev: Fix hung task on sync

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAGAzgsqD0aRnDMMyDCUVii6Rv22f97G0irpzFBz4c_ukKsn2hg@mail.gmail.com>
Date:	Sun, 16 Mar 2014 12:13:55 -0700
From:	"dbasehore ." <dbasehore@...omium.org>
To:	Tejun Heo <tj@...nel.org>
Cc:	Jan Kara <jack@...e.cz>, Alexander Viro <viro@...to.linux.org.uk>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	"Darrick J. Wong" <darrick.wong@...cle.com>,
	Kees Cook <keescook@...omium.org>,
	linux-fsdevel@...r.kernel.org,
	linux-kernel <linux-kernel@...r.kernel.org>, linux-mm@...ck.org,
	bleung@...omium.org, sonnyrao@...omium.org,
	Luigi Semenzato <semenzato@...omium.org>
Subject: Re: [PATCH] backing_dev: Fix hung task on sync

There's already behavior that is somewhat like that with the current
implementation. If there's an item on a workqueue, it could run at any
time. From the perspective of the driver/etc. that is using the
workqueue, there should be no difference between work being on the
workqueue and the kernel triggering a schedule right after the work is
removed from the workqueue, but before the work function has done
anything.

So to reiterate, calling mod_delayed_work on something that is already
in the workqueue has two behaviors. One, the work is dispatched before
mod_delayed_work can remove it from the workqueue. Two,
mod_delayed_work removes it from the workqueue and sets the timer (or
not in the case of 0). The behavior of the proposed change should be
no different than the first behavior.

This should not introduce new behavior from the perspective of the
code using delayed_work. It is true that there is a larger window of
time between when you call mod_delayed_work and when an already queued
work item will run, but I don't believe that matters.

The API will still make sense since we will only ever mod delayed work
but not work that is no longer delayed (on the workqueue).

On Sun, Mar 16, 2014 at 7:59 AM, Tejun Heo <tj@...nel.org> wrote:
> On Sat, Mar 15, 2014 at 01:22:53PM -0700, dbasehore . wrote:
>> mod_delayed_work currently removes a work item from a workqueue if it
>> is on it. Correct me if I'm wrong, but I don't think that this is
>> necessarily required for mod_delayed_work to have the current
>> behavior. We should be able to set the timer while a delayed_work is
>> currently on a workqueue. If the delayed_work is still on the
>> workqueue when the timer goes off, everything is fine. If it has left
>> the workqueue, we can queue it again.
>
> What different would that make w.r.t. this issue?  Plus, please note
> that a work item may wait non-insignificant amount of time pending if
> the workqueue is saturated to max_active.  Doing the above would make
> mod_delayed_work()'s behavior quite fuzzy - the work item is modified
> or queued to the specified time but if the timer has already expired,
> the work item may execute after unspecified amount of time which may
> be shorter than the new timeout.  What kind of interface would that
> be?
>
> Thanks.
>
> --
> tejun
--
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/