linux-kernel - Re: nfs: infinite loop in fcntl(F

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:	Sun, 13 Apr 2008 10:28:08 +0200
From:	Miklos Szeredi <miklos@...redi.hu>
To:	bfields@...ldses.org
CC:	trond.myklebust@....uio.no, miklos@...redi.hu,
	eshel@...aden.ibm.com, neilb@...e.de, akpm@...ux-foundation.org,
	linux-nfs@...r.kernel.org, linux-kernel@...r.kernel.org,
	linux-fsdevel@...r.kernel.org
Subject: Re: nfs: infinite loop in fcntl(F_SETLKW)

> Apologies, that was indeed a behavioral change introduced in a commit
> that claimed just to be shuffling code around.

Another complaint about this series: using EINPROGRESS to signal
asynchronous locking looks really fishy.  How does the filesystem
know, that the caller wants to do async locking?  How do we make sure,
that the filesystem (like fuse or 9p, which "blindly" return the error
from the server) doesn't return EINPROGRESS even when it's _not_ doing
an asynchronous lock?

I think it would have been much cleaner to have a completely separate
interface for async locking, instead of trying to cram that into
f_op->lock().

Would that be possible to fix now?  Or at least make EINPROGRESS a
kernel-internal error value (>512), to make it that it has a special
meaning for the _kernel only_?

Thanks,
Miklos
--
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/