Re: [PATCH 1/3] fs/locks: Alloc file_lock where practical

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

To: Benjamin Coddington <bcodding@xxxxxxxxxx>
Subject: Re: [PATCH 1/3] fs/locks: Alloc file_lock where practical
From: Christoph Hellwig <hch@xxxxxxxxxxxxx>
Date: Sat, 27 May 2017 23:35:20 -0700
Cc: Alexander Viro <viro@xxxxxxxxxxxxxxxxxx>, Jeff Layton <jlayton@xxxxxxxxxxxxxxx>, bfields@xxxxxxxxxxxx, linux-fsdevel@xxxxxxxxxxxxxxx, linux-nfs@xxxxxxxxxxxxxxx
In-reply-to: <1588d987ebffd963a71b0ac23d73d11b34142d15.1495829587.git.bcodding@redhat.com>
User-agent: Mutt/1.8.0 (2017-02-23)

On Fri, May 26, 2017 at 04:14:49PM -0400, Benjamin Coddington wrote:
> Use an allocation it where makes sense to do so.

Care to expain why it makes sense?

References:
- [PATCH 0/3] Fixups for l_pid
  - From: Benjamin Coddington
- [PATCH 1/3] fs/locks: Alloc file_lock where practical
  - From: Benjamin Coddington

Prev by Date: Re: [PATCH] fs: warn in case userspace lied about modprobe return
Next by Date: Re: [PATCH 0/10 v9] No wait AIO
Previous by thread: Re: [PATCH 1/3] fs/locks: Alloc file_lock where practical
Next by thread: [PATCH 2/3] fs/locks: Set fl_nspid at file_lock allocation
Index(es):
- Date
- Thread

[Index of Archives] [Linux Ext4 Filesystem] [Union Filesystem] [Filesystem Testing] [Ceph Users] [Ecryptfs] [AutoFS] [Kernel Newbies] [Share Photos] [Security] [Netfilter] [Bugtraq] [Yosemite News] [MIPS Linux] [ARM Linux] [Linux Security] [Linux Cachefs] [Reiser Filesystem] [Linux RAID] [Samba] [Device Mapper] [CEPH Development]

Powered by Linux