linux-kernel - Re: [PATCH 1/8] writeback: get rid of generic_sync_sb

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:	Tue, 8 Sep 2009 12:57:28 +0200
From:	Jens Axboe <jens.axboe@...cle.com>
To:	Artem Bityutskiy <dedekind1@...il.com>
Cc:	linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org,
	chris.mason@...cle.com, david@...morbit.com, hch@...radead.org,
	akpm@...ux-foundation.org, jack@...e.cz
Subject: Re: [PATCH 1/8] writeback: get rid of generic_sync_sb_inodes()
	export

On Tue, Sep 08 2009, Artem Bityutskiy wrote:
> On Tue, 2009-09-08 at 12:41 +0200, Jens Axboe wrote:
> > On Tue, Sep 08 2009, Artem Bityutskiy wrote:
> > > Hi Jens,
> > >
> > > On 09/08/2009 12:23 PM, Jens Axboe wrote:
> > >>   	int i, err;
> > >>   	struct ubifs_info *c = sb->s_fs_info;
> > >> -	struct writeback_control wbc = {
> > >> -		.sync_mode   = WB_SYNC_ALL,
> > >> -		.range_start = 0,
> > >> -		.range_end   = LLONG_MAX,
> > >> -		.nr_to_write = LONG_MAX,
> > >> -	};
> > >>
> > >>   	/*
> > >>   	 * Zero @wait is just an advisory thing to help the file system shove
> > >> @@ -462,7 +456,7 @@ static int ubifs_sync_fs(struct super_block *sb, int wait)
> > >>   	 * the user be able to get more accurate results of 'statfs()' after
> > >>   	 * they synchronize the file system.
> > >>   	 */
> > >> -	generic_sync_sb_inodes(sb,&wbc);
> > >> +	sync_inodes_sb(sb);
> > >
> > > This call is unnecessary and I've removed it and the patch is sitting in
> > > linux-next for long time:
> > > http://git.infradead.org/ubifs-2.6.git/commit/887ee17117fd23e962332b353d250ac9e090b20f
> > >
> > > Stephen e-mailed about the conflict recently. Could we please resolve the
> > > conflict? I guess if you pick up my patch then git will be able to resolve
> > > stuff automatically.
> > 
> > Would seem weird for me to carry your patch. As the issue is resolved in
> > -next, I'd say we just let whomever gets to merge last resolve it at
> > their end.
> 
> That's Linus. Do you think it is nice to send him a pull request which
> for sure requires requires manual work?

No, that's not what I wrote, you should never send Linus a pull request
that requires manual merging. One of us gets to resolve it, depending on
who gets to send the latter pull request.

> But well, if you do not want to carry my patch, then I'll have to
> re-base my tree later, fix stuff, and send a pull request. I mean,
> your stuff will for sure be merged first, because I send pull requests
> late, just because UBIFS is a minor thing in the kernel.

You don't have to rebase, if my work is merged first then you just merge
Linus' tree into yours and fixup the conflict before asking Linus to
pull.

It's a trivial conflict, I don't understand what the fuzz is about.

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