On 5 Jan 2024, at 5:53, Hou Tao wrote:
> From: Hou Tao
>
> When invoking virtio_fs_enqueue_req() through kworker, both the
> allocation of the sg array and the bounce buffer still use GFP_ATOMIC.
> Considering the size of both the sg array and the bounce buffer may be
> greater than PAGE_SIZE, us
On 12 Sep 2019, at 9:25, Trond Myklebust wrote:
> On Thu, 2019-09-12 at 09:13 -0400, J. Bruce Fields wrote:
>> (Unless I'm missing something. I haven't looked at this code in a
>> while. Though it was problem me that wrote it originally--apologies
>> for
>> that)
>>
>
> The function itself i
On 12 Sep 2019, at 8:53, Trond Myklebust wrote:
> Let's please just scrap this function and rewrite it as a generic
> function for reading the MIC. It clearly is not a generic function for
> reading arbitrary netobjs, and modifications like the above just make
> the misnomer painfully obvious.
>
On 11 Sep 2019, at 13:54, Chuck Lever wrote:
On Sep 11, 2019, at 1:50 PM, Benjamin Coddington
wrote:
On 11 Sep 2019, at 13:40, Benjamin Coddington wrote:
On 11 Sep 2019, at 13:29, Chuck Lever wrote:
On Sep 11, 2019, at 1:26 PM, Benjamin Coddington
wrote:
On 11 Sep 2019, at 12:39
On 11 Sep 2019, at 13:43, Chuck Lever wrote:
On Sep 11, 2019, at 1:40 PM, Benjamin Coddington
wrote:
On 11 Sep 2019, at 13:29, Chuck Lever wrote:
On Sep 11, 2019, at 1:26 PM, Benjamin Coddington
wrote:
On 11 Sep 2019, at 12:39, Chuck Lever wrote:
On Sep 11, 2019, at 12:25 PM, Benjamin
On 11 Sep 2019, at 13:40, Benjamin Coddington wrote:
On 11 Sep 2019, at 13:29, Chuck Lever wrote:
On Sep 11, 2019, at 1:26 PM, Benjamin Coddington
wrote:
On 11 Sep 2019, at 12:39, Chuck Lever wrote:
On Sep 11, 2019, at 12:25 PM, Benjamin Coddington
wrote:
Instead, I think we want
On 11 Sep 2019, at 13:29, Chuck Lever wrote:
On Sep 11, 2019, at 1:26 PM, Benjamin Coddington
wrote:
On 11 Sep 2019, at 12:39, Chuck Lever wrote:
On Sep 11, 2019, at 12:25 PM, Benjamin Coddington
wrote:
Instead, I think we want to make sure the mic falls squarely into
the tail
On 11 Sep 2019, at 13:26, Benjamin Coddington wrote:
On 11 Sep 2019, at 12:39, Chuck Lever wrote:
On Sep 11, 2019, at 12:25 PM, Benjamin Coddington
wrote:
Instead, I think we want to make sure the mic falls squarely into
the tail
every time.
I'm not clear how you could do
On 11 Sep 2019, at 12:39, Chuck Lever wrote:
On Sep 11, 2019, at 12:25 PM, Benjamin Coddington
wrote:
Instead, I think we want to make sure the mic falls squarely into the
tail
every time.
I'm not clear how you could do that. The length of the page data is
not
known to the c
On 6 Sep 2019, at 16:50, Chuck Lever wrote:
On Sep 6, 2019, at 4:47 PM, Jason L Tibbitts III
wrote:
"JBF" == J Bruce Fields writes:
JBF> Those readdir changes were client-side, right? Based on that
I'd
JBF> been assuming a client bug, but maybe it'd be worth getting a
full
JBF> packet
On 6 Sep 2019, at 16:50, Chuck Lever wrote:
On Sep 6, 2019, at 4:47 PM, Jason L Tibbitts III
wrote:
"JBF" == J Bruce Fields writes:
JBF> Those readdir changes were client-side, right? Based on that
I'd
JBF> been assuming a client bug, but maybe it'd be worth getting a
full
JBF> packet
ior art in commit 416ad3c9c006 ("freezer: add unsafe
versions of freezable helpers for NFS") to skip lock dependency checks for
NFS.
Signed-off-by: Benjamin Coddington
---
fs/nfs/nfs4proc.c | 2 +-
include/linux/freezer.h | 13 +
2 files changed, 14 insertions(+),
ed to the wrong git tree, please drop us a note
to help improve the system]
url:
https://github.com/0day-ci/linux/commits/Benjamin-Coddington/freezer-NFS-add-an-unsafe-schedule_timeout_interruptable-freezable-helper-for-NFS/20190829-161623
config: x86_64-randconfig-f004-201934 (attached as .c
ior art in commit 416ad3c9c006 ("freezer: add unsafe
versions of freezable helpers for NFS") to skip lock dependency checks for
NFS.
Signed-off-by: Benjamin Coddington
---
fs/nfs/nfs4proc.c | 2 +-
include/linux/freezer.h | 10 ++
2 files changed, 11 insertions(+), 1 delet
On 2 Jul 2019, at 12:11, Eric Biggers wrote:
On Tue, Jul 02, 2019 at 07:23:32AM -0400, Benjamin Coddington wrote:
On 2 Jul 2019, at 2:31, Eric Biggers wrote:
On Tue, Jun 11, 2019 at 12:23:12PM -0400, Benjamin Coddington wrote:
Ugh.. Now that you can cancel the wait, you have to also handle
On 2 Jul 2019, at 2:31, Eric Biggers wrote:
On Tue, Jun 11, 2019 at 12:23:12PM -0400, Benjamin Coddington wrote:
Ugh.. Now that you can cancel the wait, you have to also handle if
"new" was
allocated. I think this needs:
diff --git a/fs/nfs/client.c b/fs/nfs/client.c
index d7
Ugh.. Now that you can cancel the wait, you have to also handle if "new"
was allocated. I think this needs:
diff --git a/fs/nfs/client.c b/fs/nfs/client.c
index d7e4f0848e28..4d90f5bf0b0a 100644
--- a/fs/nfs/client.c
+++ b/fs/nfs/client.c
@@ -406,10 +406,10 @@ struct nfs_client *nfs_get_client(
Maintainers, what's the best thing to do here: fold these into another
patch version and post it (add attribution)? Add it as another patch at
the end of the series?
I have learned my lesson: add sparse to my workflow.
Ben
On 28 May 2019, at 5:06, YueHaibing wrote:
Fix sparse warnings:
fs
lete in nfs_match_client, as a
consequence if we get a fatal signal and client is not
fully initialised, we'll loop to "again" label
This has been proven to cause soft lockups on some scenarios
(no-carrier but configured network interfaces)
Signed-off-by: Roberto Bergant
gt;
From: Benjamin Coddington
Date: Thu, 9 May 2019 07:25:21 -0400
Subject: [PATCH] NFS: Fix a double unlock from nfs_match,get_client
Now that nfs_match_client drops the nfs_client_lock, we should be
careful
to always return it in the same condition: locked.
Fixes: 950a578c6128 (&
We need to return from nfs_match_client() while still holding the
nfs_client_lock, or maybe fixed with ISERR_OR_NULL in nfs_match
client().
Anna, would you like a patch to fix it, or can that commit be pulled out
and fixed up at this point?
Ben
On 8 May 2019, at 20:17, syzbot wrote:
Hell
nslation in case we are in
init_pid_ns
fs/lock: show locks taken by processes from another pidns
These look good to me too. It makes sense that we treat pid numbers out
of
our namespace in the same way we'd treat remote pids, by returning 0
instead
of skipping their display altogether. You can add my
Reviewed-by: Benjamin Coddington
to these two.
Ben
files: that
fl_pid ought to be returned from the filesystem as <= 0 to indicate that
it makes no sense to translate this l_pid.
- Follow up with a patch to have filesystems negate fl_pid for remote
locks on remote files.
Benjamin Coddington (3):
fs/locks:
pdates lustre, 9p, ceph, cifs, and dlm to negate the remote pid
returned for F_GETLK lock requests.
Signed-off-by: Benjamin Coddington
---
drivers/staging/lustre/lustre/ldlm/ldlm_flock.c | 2 +-
fs/9p/vfs_file.c| 2 +-
fs/ceph/locks.c
Struct file_lock is fairly large, so let's save some space on the stack by
using an allocation for struct file_lock in fcntl_getlk(), just as we do
for fcntl_setlk().
Signed-off-by: Benjamin Coddington
---
fs/locks.c | 46 ++
1 file change
translate to
init's pid namespace, so that the locks API can then translate from init's
pid namespace into the pid namespace of the caller.
Signed-off-by: Benjamin Coddington
---
fs/fuse/file.c | 6 +++---
fs/locks.c | 62 ---
On 20 Jun 2017, at 15:32, Jeff Layton wrote:
On Tue, 2017-06-20 at 15:17 -0400, Benjamin Coddington wrote:
On 20 Jun 2017, at 13:06, Jeff Layton wrote:
Now that I think about it a bit more, I don't think we really need a
flag here.
Just have the ->lock operation set the fl_pid to a
On 20 Jun 2017, at 13:06, Jeff Layton wrote:
>
> Now that I think about it a bit more, I don't think we really need a
> flag here.
>
> Just have the ->lock operation set the fl_pid to a negative value. That
> will never be a valid pid anyway. Then flock_translate_pid could just
> return any negativ
On 20 Jun 2017, at 10:03, Benjamin Coddington wrote:
On 19 Jun 2017, at 13:32, Jeff Layton wrote:
On Mon, 2017-06-19 at 09:24 -0400, Benjamin Coddington wrote:
@@ -2041,16 +2034,46 @@ SYSCALL_DEFINE2(flock, unsigned int, fd,
unsigned int, cmd)
*/
int vfs_test_lock(struct file *filp
On 19 Jun 2017, at 13:32, Jeff Layton wrote:
On Mon, 2017-06-19 at 09:24 -0400, Benjamin Coddington wrote:
@@ -2041,16 +2034,46 @@ SYSCALL_DEFINE2(flock, unsigned int, fd,
unsigned int, cmd)
*/
int vfs_test_lock(struct file *filp, struct file_lock *fl)
{
- if (filp->f_op-&g
Struct file_lock is fairly large, so let's save some space on the stack by
using an allocation for struct file_lock in fcntl_getlk(), just as we do
for fcntl_setlk().
Signed-off-by: Benjamin Coddington
---
fs/locks.c | 46 ++
1 file change
anslated into a local pid namespace. If
the filesystem implements the lock operation, set a flag to return the
lock's fl_pid value directly, rather translate it.
Signed-off-by: Benjamin Coddington
---
fs/locks.c | 70 +++---
include
while it may be freed.
v5: - Squash previous 2/3 and 3/3 to avoid regression where F_GETLK would
return the init_ns pid instead of a translated pid.
Benjamin Coddington (2):
fs/locks: Use allocation rather than the stack in fcntl_getlk()
fs/locks: Remove fl_nspid and use fs-specific
On 19 Jun 2017, at 8:37, Benjamin Coddington wrote:
> Apologies for the delayed response..
>
> On 7 Jun 2017, at 7:40, Jeff Layton wrote:
>
>> On Tue, 2017-06-06 at 16:45 -0400, Benjamin Coddington wrote:
>>> Now that we're translating fl_pid for F_GETLK and /proc/
Apologies for the delayed response..
On 7 Jun 2017, at 7:40, Jeff Layton wrote:
> On Tue, 2017-06-06 at 16:45 -0400, Benjamin Coddington wrote:
>> Now that we're translating fl_pid for F_GETLK and /proc/locks, we need to
>> handle the case where a remote filesystem directly s
Struct file_lock is fairly large, so let's save some space on the stack by
using an allocation for struct file_lock in fcntl_getlk(), just as we do
for fcntl_setlk().
Signed-off-by: Benjamin Coddington
---
fs/locks.c | 46 ++
1 file change
while it may be freed.
Benjamin Coddington (3):
fs/locks: Use allocation rather than the stack in fcntl_getlk()
fs/locks: Remove fl_nspid
fs/locks: Use fs-specific l_pid for remote locks
fs/locks.c | 116 -
include/linux/fs.h | 2
ock's fl_pid value directly, rather translate it.
Signed-off-by: Benjamin Coddington
---
fs/locks.c | 22 ++
include/linux/fs.h | 1 +
2 files changed, 19 insertions(+), 4 deletions(-)
diff --git a/fs/locks.c b/fs/locks.c
index 8d48e4c42ed3..206a46d28bbd 10064
s just look up the virtual pid number from fl_pid when it is needed.
That means we can remove fl_nspid entirely.
Signed-off-by: Benjamin Coddington
---
fs/locks.c | 52 +---
include/linux/fs.h | 1 -
2 files changed, 29 insertions(+), 24
On 6 Jun 2017, at 14:57, Benjamin Coddington wrote:
On 6 Jun 2017, at 14:25, Jeff Layton wrote:
On Tue, 2017-06-06 at 14:00 -0400, Jeff Layton wrote:
On Tue, 2017-06-06 at 13:19 -0400, Benjamin Coddington wrote:
Since commit c69899a17ca4 "NFSv4: Update of VFS byte range lock
must be
a
On 6 Jun 2017, at 14:25, Jeff Layton wrote:
On Tue, 2017-06-06 at 14:00 -0400, Jeff Layton wrote:
On Tue, 2017-06-06 at 13:19 -0400, Benjamin Coddington wrote:
Since commit c69899a17ca4 "NFSv4: Update of VFS byte range lock must
be
atomic with the stateid update", NFSv4 has been
namespace-translated pid until it actually needed.
Benjamin Coddington (3):
fs/locks: Use allocation rather than the stack in fcntl_getlk()
fs/locks: Remove fl_nspid
fs/locks: Use fs-specific l_pid for remote locks
fs/locks.c | 122
ock's fl_pid value directly, rather translate it.
Signed-off-by: Benjamin Coddington
---
fs/locks.c | 22 ++
include/linux/fs.h | 1 +
2 files changed, 19 insertions(+), 4 deletions(-)
diff --git a/fs/locks.c b/fs/locks.c
index 104398ccc9b9..6858ec9802d2 10064
s just look up the virtual pid number from fl_pid when it is needed.
That means we can remove fl_nspid entirely.
Signed-off-by: Benjamin Coddington
---
fs/locks.c | 58 --
include/linux/fs.h | 1 -
2 files changed, 35 insertions(+), 24
Struct file_lock is fairly large, so let's save some space on the stack by
using an allocation for struct file_lock in fcntl_getlk(), just as we do
for fcntl_setlk().
Signed-off-by: Benjamin Coddington
---
fs/locks.c | 46 ++
1 file change
allel lookup
Signed-off-by: Benjamin Coddington
---
fs/nfs/dir.c | 37 -
1 file changed, 12 insertions(+), 25 deletions(-)
diff --git a/fs/nfs/dir.c b/fs/nfs/dir.c
index fad81041f5ab..18cdf11a1720 100644
--- a/fs/nfs/dir.c
+++ b/fs/nfs/dir.c
@@
On 15 Dec 2016, at 17:40, Trond Myklebust wrote:
On Dec 9, 2016, at 08:41, Benjamin Coddington
wrote:
@@ -519,13 +508,7 @@ void nfs_prime_dcache(struct dentry *parent,
struct nfs_entry *entry)
filename.hash = full_name_hash(parent, filename.name, filename.len);
dentry
c3d3e8460e ("nfs: switch to ->iterate_shared()")
Signed-off-by: Benjamin Coddington
---
fs/nfs/dir.c | 71
1 file changed, 28 insertions(+), 43 deletions(-)
diff --git a/fs/nfs/dir.c b/fs/nfs/dir.c
index 7483722162fa..1905f3af544
call
blkdev_put() if bdev is not 0 resulting in a wrong pointer
dereference.
Fixing this by setting bdev in struct pnfs_block_dev only if we didn't
get an error from blkdev_get_by_*().
Signed-off-by: Artem Savkov
Looks good to me.
Reviewed-by: Benjamin Coddington
---
fs/nfs/blockl
On 16 Jun 2016, at 13:52, Calvin Owens wrote:
On Tuesday 03/08 at 11:37 +0100, Dmitry Vyukov wrote:
On Tue, Mar 8, 2016 at 11:27 AM, Benjamin Coddington
wrote:
Adding linux-...@vger.kernel.org ..
On Mon, 7 Mar 2016, Alexei Starovoitov wrote:
seeing on ton of these errors on net-next with
On Wed, 13 Apr 2016, Ding Tianhong wrote:
> Hi everyone:
>
> I have met this problem when I try to test udp6 for nfs connection, my
> environment is:
>
> Server:
> kernel: 4.1.15
> IP:::36/64
> MTU:1500
> Setting: /etc/exports:/home/nfs *(rw,sync,no_subtree_check,no_root_squash)
>
> Client:
>
Adding linux-...@vger.kernel.org ..
On Mon, 7 Mar 2016, Alexei Starovoitov wrote:
> seeing on ton of these errors on net-next with kasan on.
> Likely old bug though.
>
> [ 373.705691] BUG: KASAN: slab-out-of-bounds in memcpy+0x28/0x40 at
> addr 8811ada62cb0
> [ 373.707137] Write of size 28
Instead of having users check for FL_POSIX or FL_FLOCK to call the correct
locks API function, use the check within locks_lock_inode_wait(). This
allows for some later cleanup.
Signed-off-by: Benjamin Coddington
---
drivers/staging/lustre/lustre/llite/file.c |8 ++--
fs/9p/vfs_file.c
Users of the locks API commonly call either posix_lock_file_wait() or
flock_lock_file_wait() depending upon the lock type. Add a new function
locks_lock_inode_wait() which will check and call the correct function for
the type of lock passed in.
Signed-off-by: Benjamin Coddington
---
fs/locks.c
.
Changes in v2:
- fix typo that caused build failure for CONFIG_FILE_LOCKS=n
- make posix_lock_inode_wait and flock_lock_inode_wait static
- trimmed away a number of distro-lists to minimize cross-posting
Benjamin Coddington (3):
locks: introduce locks_lock_inode_wait()
Move
All callers use locks_lock_inode_wait() instead.
Signed-off-by: Benjamin Coddington
---
fs/locks.c |9 +++--
include/linux/fs.h | 24
2 files changed, 3 insertions(+), 30 deletions(-)
diff --git a/fs/locks.c b/fs/locks.c
index 94d50d3..4181f83 100644
On Thu, 22 Oct 2015, Benjamin Coddington wrote:
> Users of the locks API commonly call either posix_lock_file_wait() or
> flock_lock_file_wait() depending upon the lock type. Add a new function
> locks_lock_inode_wait() which will check and call the correct function for
> the type of
.
Benjamin Coddington (3):
locks: introduce locks_lock_inode_wait()
Move locks API users to locks_lock_inode_wait()
locks: cleanup posix_lock_inode_wait and flock_lock_inode_wait
drivers/staging/lustre/lustre/llite/file.c |8 +-
fs/9p/vfs_file.c |4 +-
fs/ceph
Users of the locks API commonly call either posix_lock_file_wait() or
flock_lock_file_wait() depending upon the lock type. Add a new function
locks_lock_inode_wait() which will check and call the correct function for
the type of lock passed in.
Signed-off-by: Benjamin Coddington
---
fs/locks.c
All callers use locks_lock_inode_wait() instead.
Signed-off-by: Benjamin Coddington
---
fs/locks.c |5 +
include/linux/fs.h | 24
2 files changed, 1 insertions(+), 28 deletions(-)
diff --git a/fs/locks.c b/fs/locks.c
index 94d50d3..b6f3c92 100644
Instead of having users check for FL_POSIX or FL_FLOCK to call the correct
locks API function, use the check within locks_lock_inode_wait(). This
allows for some later cleanup.
Signed-off-by: Benjamin Coddington
---
drivers/staging/lustre/lustre/llite/file.c |8 ++--
fs/9p/vfs_file.c
On Fri, 1 May 2015, Benjamin Coddington wrote:
> On Wed, 4 Mar 2015, Shawn Bohrer wrote:
>
> > Hello,
> >
> > We're using the Linux cgroup Freezer on some machines that use NFS and
> > have run into what appears to be a bug where frozen tasks are blocking
&g
On Wed, 4 Mar 2015, Shawn Bohrer wrote:
> Hello,
>
> We're using the Linux cgroup Freezer on some machines that use NFS and
> have run into what appears to be a bug where frozen tasks are blocking
> running tasks and preventing them from completing. On one of our
> machines which happens to be ru
On Tue, 24 Feb 2015, J. Bruce Fields wrote:
> On Mon, Feb 23, 2015 at 05:22:12PM -0800, Benjamin Coddington wrote:
> > That sounds a lot closer to some of the work I've been doing to see if I can
> > come up with a way to solve the "where's the namespace I need?&
On Tue, 24 Feb 2015, Ian Kent wrote:
> On Mon, 2015-02-23 at 09:52 -0500, J. Bruce Fields wrote:
> > On Sat, Feb 21, 2015 at 11:58:58AM +0800, Ian Kent wrote:
> > > On Fri, 2015-02-20 at 14:05 -0500, J. Bruce Fields wrote:
> > > > On Fri, Feb 20, 2015 at 12:07:15PM -0600, Eric W. Biederman wrote:
Frame 36 of nfs-client.pcap has this interesting string:
0ff0 00 01 3b f6 fb b6 26 16 8f 7c 00 00 00 41 62 74 ..;...&..|...Abt
1000 72 66 73 2d 32 30 00 00 00 00 00 00 00 00 30 36 rfs-2006
1010 2d 66 69 78 2d 64 65 61 64 6c 6f 63 6b 2d 77 68 -fix-deadlock-wh
1020 65 6e 2d 6d 6f 7
On Wed, 3 Dec 2014, Eric W. Biederman wrote:
> Ian Kent writes:
>
> > On Mon, 2014-12-01 at 16:56 -0500, Benjamin Coddington wrote:
> >> n Tue, 25 Nov 2014, Eric W. Biederman wrote:
> >> Hi,
> >>
> >> > Ian Kent writes:
> >> >
n Tue, 25 Nov 2014, Eric W. Biederman wrote:
Hi,
> Ian Kent writes:
>
> > On Tue, 2014-11-25 at 17:19 -0600, Eric W. Biederman wrote:
> >> Ian Kent writes:
> >>
> >> > On Tue, 2014-11-25 at 16:23 -0600, Eric W. Biederman wrote:
> >> >> Oleg Nesterov writes:
> >> >>
> >> >> > On 11/25, Oleg Nest
68 matches
Mail list logo
