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] [day] [month] [year] [list]
Date:	Wed, 14 Nov 2007 17:50:50 -0500
From:	"J. Bruce Fields" <bfields@...ldses.org>
To:	Kumar Gala <galak@...nel.crashing.org>
Cc:	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	richterd@...i.umich.edu
Subject: Re: generic_setlease and tmpfs -- LTP fcntl failure

On Wed, Nov 14, 2007 at 03:19:31PM -0600, Kumar Gala wrote:
> In debugging a LTP failure related to fcntl on tmpfs it appears that we 
> aren't able to use fcntl(fd, F_SETLEASE, F_WRLCK).  In the debugging it 
> looks like we artificial increase the dentry->d_count and so 
> generic_setlease() always fails with -EAGAIN since it appears 
> dentry->d_count will be 2.
>
> This is my first time delving into fs code so I'm not that familiar with 
> why tmpfs is artificially increasing the d_count.  I was wondering what a 
> possible solution would be.
>
> Maybe something like:
>
> shmem_setlease(...) {
> 	if (arg == F_WRLCK) {
> 		dput(dentry)
> 		generic_setlease(...)
> 		dget(dentry)
> 	} else {
> 		generic_setlease(...)
> 	}
> }
>
> Not sure what harm doing the dput() / dget() will have.

I guess if you *know* for whatever reason that you hold two references
on the dentry, then that might be safe.

I'd be happier if we could come up with some better way for the setlease
code to determine whether someone has the file open for writing.  The
current tests seem incredibly fragile.

Would it be at all reasonable, for example, to keep a count of the
number of readers stored in the inode?

--b.
-
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ