linux-kernel - Re: Lease semantic proposal

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:   Mon, 20 Jan 2020 18:56:24 -0600
From:   Steve French <smfrench@...il.com>
To:     "J. Bruce Fields" <bfields@...ldses.org>
Cc:     Jeff Layton <jlayton@...nel.org>, Ira Weiny <ira.weiny@...el.com>,
        linux-fsdevel <linux-fsdevel@...r.kernel.org>,
        linux-xfs <linux-xfs@...r.kernel.org>,
        linux-ext4@...r.kernel.org, linux-rdma@...r.kernel.org,
        LKML <linux-kernel@...r.kernel.org>, linux-nvdimm@...ts.01.org,
        linux-mm <linux-mm@...ck.org>,
        Dave Chinner <david@...morbit.com>, Jan Kara <jack@...e.cz>,
        "Theodore Ts'o" <tytso@....edu>,
        John Hubbard <jhubbard@...dia.com>,
        Dan Williams <dan.j.williams@...el.com>,
        Jason Gunthorpe <jgg@...pe.ca>
Subject: Re: Lease semantic proposal

Two common complaints about the current lease API is that for some of the
common protocols like SMB3 there is the need to be able to pass in
the lease request on open itself, and also to
upgrade and downgrade leases (in SMB3 lease keys can be
passed over the wire) and of course it would be helpful if
information about whether a lease was aquired were returned on open
(and create) to minimize syscalls.

On Thu, Oct 3, 2019 at 11:00 AM J. Bruce Fields <bfields@...ldses.org> wrote:
>
> On Wed, Oct 02, 2019 at 04:35:55PM -0400, Jeff Layton wrote:
> > On Wed, 2019-10-02 at 15:27 -0400, J. Bruce Fields wrote:
> > > On Wed, Oct 02, 2019 at 08:28:40AM -0400, Jeff Layton wrote:
> > > > For the byte ranges, the catch there is that extending the userland
> > > > interface for that later will be difficult.
> > >
> > > Why would it be difficult?
> >
> > Legacy userland code that wanted to use byte range enabled layouts would
> > have to be rebuilt to take advantage of them. If we require a range from
> > the get-go, then they will get the benefit of them once they're
> > available.
>
> I can't see writing byte-range code for a kernel that doesn't support
> that yet.  How would I test it?
>
> > > > What I'd probably suggest
> > > > (and what would jive with the way pNFS works) would be to go ahead and
> > > > add an offset and length to the arguments and result (maybe also
> > > > whence?).
> > >
> > > Why not add new commands with range arguments later if it turns out to
> > > be necessary?
> >
> > We could do that. It'd be a little ugly, IMO, simply because then we'd
> > end up with two interfaces that do almost the exact same thing.
> >
> > Should byte-range layouts at that point conflict with non-byte range
> > layouts, or should they be in different "spaces" (a'la POSIX and flock
> > locks)? When it's all one interface, those sorts of questions sort of
> > answer themselves. When they aren't we'll have to document them clearly
> > and I think the result will be more confusing for userland programmers.
> I was hoping they'd be in the same space, with the old interface just
> defined to deal in locks with range [0,∞).
>
> I'm just worried about getting the interface wrong if it's specified
> without being implemented.  Maybe this is straightforward enough that
> there's not a risk, I don't know.

Yes


-- 
Thanks,

Steve