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

[Alex Elder]

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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/