linux-kernel - Re: 2.6.20-rc6-mm3

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:	Fri, 2 Feb 2007 08:31:18 +0100
From:	Jens Axboe <jens.axboe@...cle.com>
To:	David Chinner <dgc@....com>
Cc:	Christoph Lameter <clameter@....com>,
	Andrew Morton <akpm@...l.org>, linux-kernel@...r.kernel.org
Subject: Re: 2.6.20-rc6-mm3

On Fri, Feb 02 2007, David Chinner wrote:
> On Thu, Feb 01, 2007 at 08:18:57PM +0100, Jens Axboe wrote:
> > That down() probably wants a replug to precede it. Probably something
> > like:
> > 
> >         if (atomic_read(&bp->b_io_remaining))
> >                 blk_replug_current_nested();
> > 
> > for xfs_buf_wait_unpin() and xfs_buf_lock(). Does this fix it?
> 
> Jens, this patch looks like you originally removed the explicit
> unplug calls that XFS used to prevent metadata I/O hangs and now you
> are putting them back.  Correct?
> 
> Reading on from Andrew's earlier comments, shouldn't XFS have
> worked unchanged? I'm just trying to understand why you removed
> the explicit unplugs in the first place.....

It should, the problem is if someone has plugged higher up in the
hierarchy, then you do need the explicit replug to drain that before
going to sleep and waiting for IO to complete. Not very happy about that
situation, I'd prefer if that happened automagically. I'll likely change
the code to fix that, so we don't have to sprinkle
blk_replug_current_nested() and always call io_schedule() instead of
schedule(). It's just going to cause too many problems.

-- 
Jens Axboe

-
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/