* memory corruption after "Fix race when checking i_size on direct i/o read" @ 2014-02-08 20:45 ` J. Bruce Fields 0 siblings, 0 replies; 8+ messages in thread From: J. Bruce Fields @ 2014-02-08 20:45 UTC (permalink / raw) To: Steven Whitehouse; +Cc: linux-kernel, linux-fsdevel, linux-nfs I'm getting warnings about corruption of the kmalloc-32 slab on an nfs server while running some regression tests. A bisect lands on 9fe55eea7e4b444bafc42fa0000cc2d1d2847275 "Fix race when checking i_size on direct i/o read". Is there any known problem here? It doesn't reproduce immediately and it's possible I could have made a mistake on the bisect. I'll verify and try to narrow down the reproducer. --b. ^ permalink raw reply [flat|nested] 8+ messages in thread
* memory corruption after "Fix race when checking i_size on direct i/o read" @ 2014-02-08 20:45 ` J. Bruce Fields 0 siblings, 0 replies; 8+ messages in thread From: J. Bruce Fields @ 2014-02-08 20:45 UTC (permalink / raw) To: Steven Whitehouse Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA, linux-fsdevel-u79uwXL29TY76Z2rM5mHXA, linux-nfs-u79uwXL29TY76Z2rM5mHXA I'm getting warnings about corruption of the kmalloc-32 slab on an nfs server while running some regression tests. A bisect lands on 9fe55eea7e4b444bafc42fa0000cc2d1d2847275 "Fix race when checking i_size on direct i/o read". Is there any known problem here? It doesn't reproduce immediately and it's possible I could have made a mistake on the bisect. I'll verify and try to narrow down the reproducer. --b. -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: memory corruption after "Fix race when checking i_size on direct i/o read" @ 2014-02-09 2:09 ` J. Bruce Fields 0 siblings, 0 replies; 8+ messages in thread From: J. Bruce Fields @ 2014-02-09 2:09 UTC (permalink / raw) To: Steven Whitehouse; +Cc: linux-kernel, linux-fsdevel, linux-nfs On Sat, Feb 08, 2014 at 03:45:22PM -0500, bfields wrote: > I'm getting warnings about corruption of the kmalloc-32 slab on an nfs > server while running some regression tests. > > A bisect lands on 9fe55eea7e4b444bafc42fa0000cc2d1d2847275 "Fix race > when checking i_size on direct i/o read". Is there any known problem > here? > > It doesn't reproduce immediately and it's possible I could have made a > mistake on the bisect. Argh, apologies, yes--I'm able to reproduce the corruption before that commit. I'll keep looking.... --b. ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: memory corruption after "Fix race when checking i_size on direct i/o read" @ 2014-02-09 2:09 ` J. Bruce Fields 0 siblings, 0 replies; 8+ messages in thread From: J. Bruce Fields @ 2014-02-09 2:09 UTC (permalink / raw) To: Steven Whitehouse Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA, linux-fsdevel-u79uwXL29TY76Z2rM5mHXA, linux-nfs-u79uwXL29TY76Z2rM5mHXA On Sat, Feb 08, 2014 at 03:45:22PM -0500, bfields wrote: > I'm getting warnings about corruption of the kmalloc-32 slab on an nfs > server while running some regression tests. > > A bisect lands on 9fe55eea7e4b444bafc42fa0000cc2d1d2847275 "Fix race > when checking i_size on direct i/o read". Is there any known problem > here? > > It doesn't reproduce immediately and it's possible I could have made a > mistake on the bisect. Argh, apologies, yes--I'm able to reproduce the corruption before that commit. I'll keep looking.... --b. -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 8+ messages in thread
* [PATCH] nfsd4: fix acl buffer overrun 2014-02-09 2:09 ` J. Bruce Fields (?) @ 2014-02-11 19:38 ` J. Bruce Fields 2014-02-11 20:25 ` Christoph Hellwig -1 siblings, 1 reply; 8+ messages in thread From: J. Bruce Fields @ 2014-02-11 19:38 UTC (permalink / raw) To: Steven Whitehouse Cc: linux-kernel, linux-fsdevel, linux-nfs, Christoph Hellwig From: "J. Bruce Fields" <bfields@redhat.com> 4ac7249ea5a0ceef9f8269f63f33cc873c3fac61 "nfsd: use get_acl and ->set_acl" forgets to set the size in the case get_acl() succeeds, so _posix_to_nfsv4_one() can then write past the end of its allocation. Symptoms were slab corruption warnings. Also, some minor cleanup while we're here. (Among other things, note that the first few lines guarantee that pacl is non-NULL.) Signed-off-by: J. Bruce Fields <bfields@redhat.com> --- fs/nfsd/nfs4acl.c | 9 +++------ 1 file changed, 3 insertions(+), 6 deletions(-) On Sat, Feb 08, 2014 at 09:09:33PM -0500, J. Bruce Fields wrote: > On Sat, Feb 08, 2014 at 03:45:22PM -0500, bfields wrote: > > I'm getting warnings about corruption of the kmalloc-32 slab on an nfs > > server while running some regression tests. > > > > A bisect lands on 9fe55eea7e4b444bafc42fa0000cc2d1d2847275 "Fix race > > when checking i_size on direct i/o read". Is there any known problem > > here? > > > > It doesn't reproduce immediately and it's possible I could have made a > > mistake on the bisect. > > Argh, apologies, yes--I'm able to reproduce the corruption before that > commit. I'll keep looking.... Fortunately my mistake was at the end of the bisect so the offending commit was nearby (and clearly labeled "nfsd:..."). This fixes the regression I was seeing. I intend to include it in a pull request for 3.14 soon. diff --git a/fs/nfsd/nfs4acl.c b/fs/nfsd/nfs4acl.c index d3a5871..d190e33 100644 --- a/fs/nfsd/nfs4acl.c +++ b/fs/nfsd/nfs4acl.c @@ -151,17 +151,15 @@ nfsd4_get_nfs4_acl(struct svc_rqst *rqstp, struct dentry *dentry, pacl = posix_acl_from_mode(inode->i_mode, GFP_KERNEL); if (IS_ERR(pacl)) return PTR_ERR(pacl); - /* allocate for worst case: one (deny, allow) pair each: */ - size += 2 * pacl->a_count; } + /* allocate for worst case: one (deny, allow) pair each: */ + size += 2 * pacl->a_count; if (S_ISDIR(inode->i_mode)) { flags = NFS4_ACL_DIR; dpacl = get_acl(inode, ACL_TYPE_DEFAULT); if (dpacl) size += 2 * dpacl->a_count; - } else { - dpacl = NULL; } *acl = nfs4_acl_new(size); @@ -170,8 +168,7 @@ nfsd4_get_nfs4_acl(struct svc_rqst *rqstp, struct dentry *dentry, goto out; } - if (pacl) - _posix_to_nfsv4_one(pacl, *acl, flags & ~NFS4_ACL_TYPE_DEFAULT); + _posix_to_nfsv4_one(pacl, *acl, flags & ~NFS4_ACL_TYPE_DEFAULT); if (dpacl) _posix_to_nfsv4_one(dpacl, *acl, flags | NFS4_ACL_TYPE_DEFAULT); -- 1.7.9.5 ^ permalink raw reply related [flat|nested] 8+ messages in thread
* Re: [PATCH] nfsd4: fix acl buffer overrun 2014-02-11 19:38 ` [PATCH] nfsd4: fix acl buffer overrun J. Bruce Fields @ 2014-02-11 20:25 ` Christoph Hellwig 2014-02-11 22:33 ` J. Bruce Fields 0 siblings, 1 reply; 8+ messages in thread From: Christoph Hellwig @ 2014-02-11 20:25 UTC (permalink / raw) To: J. Bruce Fields Cc: Steven Whitehouse, linux-kernel, linux-fsdevel, linux-nfs, Christoph Hellwig Looks good and sorry for the regression. ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH] nfsd4: fix acl buffer overrun @ 2014-02-11 22:33 ` J. Bruce Fields 0 siblings, 0 replies; 8+ messages in thread From: J. Bruce Fields @ 2014-02-11 22:33 UTC (permalink / raw) To: Christoph Hellwig Cc: Steven Whitehouse, linux-kernel, linux-fsdevel, linux-nfs On Tue, Feb 11, 2014 at 12:25:48PM -0800, Christoph Hellwig wrote: > Looks good and sorry for the regression. Well, my fault for not reviewing the patch, I saw it and didn't give it more than a skim. Not sure I would have caught that, though. The only thing I can think of that might have made it easier to catch was breaking up the patch (v4 could probably have been done separately from v2/v3?). But I still probably would've overlooked it.... --b. ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH] nfsd4: fix acl buffer overrun @ 2014-02-11 22:33 ` J. Bruce Fields 0 siblings, 0 replies; 8+ messages in thread From: J. Bruce Fields @ 2014-02-11 22:33 UTC (permalink / raw) To: Christoph Hellwig Cc: Steven Whitehouse, linux-kernel-u79uwXL29TY76Z2rM5mHXA, linux-fsdevel-u79uwXL29TY76Z2rM5mHXA, linux-nfs-u79uwXL29TY76Z2rM5mHXA On Tue, Feb 11, 2014 at 12:25:48PM -0800, Christoph Hellwig wrote: > Looks good and sorry for the regression. Well, my fault for not reviewing the patch, I saw it and didn't give it more than a skim. Not sure I would have caught that, though. The only thing I can think of that might have made it easier to catch was breaking up the patch (v4 could probably have been done separately from v2/v3?). But I still probably would've overlooked it.... --b. -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2014-02-11 22:34 UTC | newest] Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2014-02-08 20:45 memory corruption after "Fix race when checking i_size on direct i/o read" J. Bruce Fields 2014-02-08 20:45 ` J. Bruce Fields 2014-02-09 2:09 ` J. Bruce Fields 2014-02-09 2:09 ` J. Bruce Fields 2014-02-11 19:38 ` [PATCH] nfsd4: fix acl buffer overrun J. Bruce Fields 2014-02-11 20:25 ` Christoph Hellwig 2014-02-11 22:33 ` J. Bruce Fields 2014-02-11 22:33 ` J. Bruce Fields
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.