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:	Fri, 8 Jan 2010 17:17:14 -0800 (PST)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Trond Myklebust <Trond.Myklebust@...app.com>
cc:	Andi Kleen <andi@...stfloor.org>, linux-kernel@...r.kernel.org,
	linux-nfs@...r.kernel.org
Subject: Re: [RFC PATCH 0/2] Fix up the NFS mmap code



On Fri, 8 Jan 2010, Trond Myklebust wrote:
>
> How about something like the following. I chose to wrap the call to
> do_mmap_pgoff() instead of making a special ->pre_mmap(), since that
> seems more consistent with the way we handle ->read() and ->write().

I still don't think that you can ever do mmap _and_ readdir on the same 
inode, so there's something wrong with the lockdep annotations.

See my earlier mail about putting directory inodes in a different class 
from non-directory inodes, and the email after that that points out that 
we already do:

 - inode_init_always():
	lockdep_set_class(&inode->i_mutex, &sb->s_type->i_mutex_key);

 - unlock_new_inode() (for directories):
	lockdep_set_class(&inode->i_mutex, &type->i_mutex_dir_key);

and I suspect that the reason why NFS triggers lockdep problems is that 
NFS probably plays some game with inodes (presumably the root inode) that 
ends up bypassing the normal new-inode handling.

In short - I really don't think this issue merits VFS-level (or VM, 
whatever you want to call it) hooks. There's a bug there, but I don't 
think you're actually fixing the right thing.

And _especially_ not the way you did it, where the filesystem can wrap the 
whole complex do_mmap_pgoff. The NFS use you have doesn't seem too bad, 
but anybody who tries to be clever and avoid "generic_mmap_do_pgoff()" 
would immediately be a major disaster.

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

Powered by blists - more mailing lists