linux-kernel - Re: [xfs-masters] linux-next: manual merge of the xfs tree with Linus' tree

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: <1301367438.2005.1.camel@doink>
Date:	Mon, 28 Mar 2011 21:57:18 -0500
From:	Alex Elder <aelder@....com>
To:	Jens Axboe <jaxboe@...ionio.com>
Cc:	Christoph Hellwig <hch@....de>,
	Stephen Rothwell <sfr@...b.auug.org.au>,
	David Chinner <david@...morbit.com>,
	"xfs-masters@....sgi.com" <xfs-masters@....sgi.com>,
	"linux-next@...r.kernel.org" <linux-next@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [xfs-masters] linux-next: manual merge of the xfs tree with 
 Linus' tree

On Mon, 2011-03-28 at 12:58 +0200, Jens Axboe wrote:
> On 2011-03-28 12:53, Christoph Hellwig wrote:
> > On Mon, Mar 28, 2011 at 12:47:53PM +0200, Christoph Hellwig wrote:
> >> What XFS does is to replace blk_run_address_space, which was a wrapper
> >> around blk_run_backing_dev with a direct call to blk_run_backing_dev,
> >> as there change means we don't have the address_space around anymore.
> >>
> >> Jens' tree removes both these functions, and introduces blk_flush_plug
> >> as a sort-of replacement.  Sticking to the variant from Jens' tree / mainline
> >> with blk_flush_plug is the correct thing here for this case.
> >>
> >> Where there more conflicts than just this?
> > 
> > Actually I think we can remove some calls alltogether:  the on-stack
> > plugging already flushes the plug queue when context switching,
> > which we'll always do in xfs_buf_wait_unpin, and if we get the lock
> > without blocking in xfs_buf_lock we don't need to unplug either.
> 
> Yes, in fact all of the blk_flush_plug() calls in XFS can just go away
> now. I tried to keep them for clarity, but they are primarily there
> since XFS was the first conversion/testing I did back when it was hacked
> up.
> 

I sent a fix to Linus but he must not have pulled it in
time for the March 29 build.  He has pulled it now though.
Ought to be fixed tomorrow.

(To be clear, I just did the simple conflict resolution,
I didn't remove the calls--that'll wait.)

					-Alex

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