linux-kernel - Re: [PATCH v2 14/17] locks: __break_lease cleanup in preparation of allowing direct removal of leases

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: <20140904180725.GA11232@infradead.org>
Date:	Thu, 4 Sep 2014 11:07:25 -0700
From:	Christoph Hellwig <hch@...radead.org>
To:	Jeff Layton <jlayton@...marydata.com>
Cc:	linux-fsdevel@...r.kernel.org, linux-nfs@...r.kernel.org,
	Christoph Hellwig <hch@...radead.org>,
	"J. Bruce Fields" <bfields@...ldses.org>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 14/17] locks: __break_lease cleanup in preparation of
 allowing direct removal of leases

On Thu, Sep 04, 2014 at 08:38:40AM -0400, Jeff Layton wrote:
> Eliminate an unneeded "flock" variable. We can use "fl" as a loop cursor
> everywhere. Add a any_leases_conflict helper function as well to
> consolidate a bit of code.

Looks good,

Reviewed-by: Christoph Hellwig <hch@....de>

One thing that came to mind after starring at this code for a while and
then seeing your cleanup:

the sleep/wake patterns in __break_lease seem highly suboptimal, as
we always wait for the break time on the first least found, why
don't we simply take the max of the lease break times, and wait for
that?

I guess the case of lots of read leases just isn't common enough to
bother..
--
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/