linux-kernel - Re: [PATCH v5 14/14] locks: add new fcntl cmd values for handling file private locks

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]

Message-ID: <CALCETrWjYoHLvuocWy9SRR=Kowu9YJjf4_dk4xzagZEYFhfXzA@mail.gmail.com>
Date:	Thu, 9 Jan 2014 17:01:38 -0800
From:	Andy Lutomirski <luto@...capital.net>
To:	Jeff Layton <jlayton@...hat.com>
Cc:	Linux FS Devel <linux-fsdevel@...r.kernel.org>,
	nfs-ganesha-devel@...ts.sourceforge.net,
	samba-technical@...ts.samba.org,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v5 14/14] locks: add new fcntl cmd values for handling
 file private locks

On Thu, Jan 9, 2014 at 4:55 PM, Jeff Layton <jlayton@...hat.com> wrote:
> On Thu, 09 Jan 2014 12:29:04 -0800
> Andy Lutomirski <luto@...capital.net> wrote:
>
>> On 01/09/2014 06:19 AM, Jeff Layton wrote:
>> > Due to some unfortunate history, POSIX locks have very strange and
>> > unhelpful semantics. The thing that usually catches people by surprise
>> > is that they are dropped whenever the process closes any file descriptor
>> > associated with the inode.
>> >
>>
>> [...]
>>
>> > +#define F_GETLKP   36
>> > +#define F_SETLKP   37
>> > +#define F_SETLKPW  38
>> > +
>> > +#ifndef CONFIG_64BIT
>> > +#ifndef F_GETLK64
>> > +#define F_GETLKP64 39
>> > +#define F_SETLKP64 40
>> > +#define F_SETLKPW64        41
>> > +#endif
>> > +#endif
>> > +
>>
>> Since there are no existing callers of these fcntls, can you get rid of
>> the non-64-bit variants?  The implementation might be a bit more of
>> departure from current code, but it should make everything a lot cleaner
>> and make it easier (aka automatic) for new architectures to support this
>> feature.
>>
>
> That sounds reasonable, but I'll admit I had some trouble slogging
> through the morass of fcntl/fcntl64 syscall handling code. I mostly did
> the cargo-cult thing on this patch to get something that worked.
>
> So, to make sure I understand...
>
> You're basically suggesting that we just require that 32-bit userland
> always use fcntl64() to access these new cmd values?

Exactly.

It's general Linux policy these days to avoid introducing new
interfaces that need compat support.  (The OABI thing is probably
unavoidable here, but at least the compat mess could be restricted to
ARM.)

You may be able to do pretty well by undoing the compat changes and
leaving everything else alone.  I suspect that everything will just
work.

>
> I'll try to do that, but I'll probably need someone to carefully review
> what I come up with (hint, hint).

I'll try.  I'm not an expert on this particular morass :)

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