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] [day] [month] [year] [list]
Message-ID: <20140317205943.GF17373@mtj.dyndns.org>
Date:	Mon, 17 Mar 2014 16:59:43 -0400
From:	Tejun Heo <tj@...nel.org>
To:	"dbasehore ." <dbasehore@...omium.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 01:53:57PM -0700, dbasehore . wrote:
> 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.

I really don't see what you're suggesting happening.  Managing work
item pending status is already extremely delicate and I'd like to keep
all the paths which can share pending state management to do so.
You're suggesting introducing a new pending state where a work item
may be pending in two different places which will also affect cancel
and flushing for rather dubious benefit.  If you can write up a patch
which isn't too complicated, let's talk about it, but I'm likely to
resist any significant amount of extra complexity coming from it.

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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ