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 for Android: free password hash cracker in your pocket

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

Date:	Mon, 17 Mar 2014 13:53:57 -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

On Mon, Mar 17, 2014 at 7:40 AM, Tejun Heo <tj@...nel.org> wrote:
> Hello,
>
> On Sun, Mar 16, 2014 at 12:13:55PM -0700, dbasehore . wrote:
>> 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.
>
> It is different.  mod_delayed_work() *guarantees* that the target work
> item will become pending for execution at least after the specified
> time has passed.  What you're suggesting removes any semantically
> consistent meaning of the API.
>

It will still be at least be pending after the specified time has
passed. I'm proposing that we still set the timer. The difference is
that there is a possibility the work will already be pending when the
timer goes off. There will still at least be an execution after the
given time has past. We could still remove the work in the workqueue
from the timer function, but this would make the mod_delayed_work not
race with any work that was scheduled for immediate execution
previously.

If you make the timer function remove any pending work from the
workqueue when the timer goes off, this is still following the API.
The work will still become pending at least after the specified time
has passed.

>> 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.
>
> No, mod_delayed_work() does *one* thing - the work item is queued for
> the specified delay no matter the current state of the work item.  It
> is *guaranteed* that the work item will go pending after the specified
> time.  That is the sole meaning of the API.
>
>> 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.
>
> You're completely misunderstanding the API.  Plesae re-read it and
> understand what it does first.
>
> 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/