linux-kernel - Re: [git pull] vfs part 3 (write

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <4B955C8D.6030907@RedHat.com>
Date:	Mon, 08 Mar 2010 15:22:37 -0500
From:	Steve Dickson <SteveD@...hat.com>
To:	Al Viro <viro@...IV.linux.org.uk>
CC:	Linus Torvalds <torvalds@...ux-foundation.org>,
	linux-nfs@...r.kernel.org, linux-kernel@...r.kernel.org,
	Trond Myklebust <Trond.Myklebust@...app.com>
Subject: Re: [git pull] vfs part 3 (write_inode mess)

On 03/05/2010 12:40 PM, Al Viro wrote:
> On Fri, Mar 05, 2010 at 03:48:23PM +0000, Al Viro wrote:
>> I'm going to push the next VFS pile in about half an hour and get to the
>> write_inode situation.  I'm not sure what's the best course here.  Note
>> that since you've pulled it, you also have conflicts with what's in the
>> mainline.  I can do *another* backmerge (already had one due to gfs2 trivial
>> conflicts) and push the result.  Which will suck, since XFS conflicts
>> are not entirely trivial and we'll get a really ugly merge node, with
>> conflict resolution both hidden and not quite obvious.
> 
> OK, a backmerge it is.  Linus, could you please pull
> git.kernel.org/pub/scm/linux/kernel/git/viro/vfs-2.6.git/ write_inode
> or suggest a saner way to do that?
> 
> I've done backmerges of two points in mainline (trees that got merged
> into mainline, actually) that created conflicts.  So at that point it's
> (a) descendent of what's been pulled into NFS tree and (b) merges clean
> with mainline.  All for two patches (at commit 716c28c..) ;-/
> 
> It's independent from the previous VFS pull; there's more stuff, hopefully
> for later today, but the worst of the mess should be gone with that one.
Has there been any kind of testing that show this approach does indeed
improve performance? Any hardcore number? 

Just curious....

steved.

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