MIME-Version: 1.0
In-Reply-To: <1390956313.25542.64.camel@kjgkr>
References: <20140128224336.GF25989@kernel.dk>
	<20140128225229.GH25989@kernel.dk>
	<20140129110536.00ce3c9e580f747fd0f1d0e6@canb.auug.org.au>
	<1390956313.25542.64.camel@kjgkr>
Date: Thu, 30 Jan 2014 11:26:04 -0800
Message-ID: <CA+55aFwYxdqf3EZNr_Z1EUADi4ExL8aZc_HCR-X6XRv1r223yQ@mail.gmail.com>
Subject: Re: [GIT PULL] Core block IO changes for 3.14
From: Linus Torvalds <torvalds@linux-foundation.org>
To: jaegeuk.kim@samsung.com
Cc: Stephen Rothwell <sfr@canb.auug.org.au>, Jens Axboe <axboe@kernel.dk>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Content-Type: text/plain; charset=UTF-8
Sender: linux-kernel-owner@vger.kernel.org

On Tue, Jan 28, 2014 at 4:45 PM, Jaegeuk Kim <jaegeuk.kim@samsung.com> wrote:
>
> In the case of f2fs, could you please check the following code changes?

So I ended up doing the merge differently wrt the f2fs_write_end_io() function.

As far as I can tell, we can just initialize the f2fs_sb_info directly
and unconditionally using the first bio_vec entry, giving us the
simpler

    struct f2fs_sb_info *sbi =
F2FS_SB(bio->bi_io_vec->bv_page->mapping->host->i_sb);

which is still ugly, but whatever. I'm not quite seeing why f2fs
doesn't just set bio->private to the superblock pointer and avoid this
whole complex and long pointer chasing, but there's probably some
reason.

Anyway, it compiles for me, and looks simpler than the alternate
resolutions, but maybe there is some reason I miss why you guys did it
the way you did. And while I could test that it compiles and looks
sane, I don't have a f2fs to actually *test* it on, and maybe I
screwed up royally.

I'll push it out once I've done the rest of the allmodconfig build-test.

                 Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/