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]

Date:	Sat, 15 Mar 2014 13:22:53 -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

Resurrecting this for further discussion about the root of the problem.

mod_delayed_work_if_later addresses the problem one way, but the
problem is still there for mod_delayed_work. I think we could take
another approach that doesn't modify the API, but still addresses
(most of) the problem.

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.

On Wed, Feb 19, 2014 at 11:01 AM, Tejun Heo <tj@...nel.org> wrote:
> Hello, Jan.
>
> On Wed, Feb 19, 2014 at 10:27:31AM +0100, Jan Kara wrote:
>>   You are the workqueue expert so you may know better ;) But the way I
>> understand it is that queue_delayed_work() does nothing if the timer is
>> already running. Since we queue flusher work to run either immediately or
>> after dirty_writeback_interval we are safe to run queue_delayed_work()
>> whenever we want it to run after dirty_writeback_interval and
>> mod_delayed_work() whenever we want to run it immediately.
>
> Ah, okay, so it's always mod on immediate and queue on delayed.  Yeah,
> that should work.
>
>> But it's subtle and some interface where we could say queue delayed work
>> after no later than X would be easier to grasp.
>
> Yeah, I think it'd be better if we had something like
> mod_delayed_work_if_later().  Hmm...
>
> 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/