* Empty core dumps on NFSv4 mounts
@ 2010-07-02 8:01 Arnaud Giersch
2010-07-02 13:03 ` Trond Myklebust
0 siblings, 1 reply; 6+ messages in thread
From: Arnaud Giersch @ 2010-07-02 8:01 UTC (permalink / raw)
To: linux-nfs
Hi,
On NFSv4 mounts, many core dumps are empty, although ulimit -c is
unlimited. An ls command shortly after the core dump often shows
4294967294 (2^32-2) as UID and GID for the "core" file.
This only happens when there was no "core" file before the dump. If a
"core" file owned by the current user is already present, it is
correctly filled.
After having done a git bisect, it seems that the problem was
introduced by commit 80e52aced138bb41b045a8595a87510f27d8d8c5
(NFSv4: Don't do idmapper upcalls for asynchronous RPC calls).
If I understand correctly what happens, do_coredump() [fs/exec.c] fails
because (inode->i_uid != current_fsuid()). In fact inode->i_uid equals
-2, because decode_attr_owner() [fs/nfs/nfs4xdr.c], which is called from
nfs4_xdr_dec_open() via decode_getfattr(), returns without calling
nfs_map_to_uid(), since its may_sleep parameter is false.
I however do not clearly understand what the aforementioned commit is
supposed to fix. I read the linux-nfs mailing list archive, and tried
some google search, but I didn't find anything.
Regards,
Arnaud Giersch
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Empty core dumps on NFSv4 mounts
2010-07-02 8:01 Arnaud Giersch
@ 2010-07-02 13:03 ` Trond Myklebust
0 siblings, 0 replies; 6+ messages in thread
From: Trond Myklebust @ 2010-07-02 13:03 UTC (permalink / raw)
To: Arnaud Giersch; +Cc: linux-nfs
On Fri, 2010-07-02 at 10:01 +0200, Arnaud Giersch wrote:
> Hi,
>
> On NFSv4 mounts, many core dumps are empty, although ulimit -c is
> unlimited. An ls command shortly after the core dump often shows
> 4294967294 (2^32-2) as UID and GID for the "core" file.
>
> This only happens when there was no "core" file before the dump. If a
> "core" file owned by the current user is already present, it is
> correctly filled.
>
> After having done a git bisect, it seems that the problem was
> introduced by commit 80e52aced138bb41b045a8595a87510f27d8d8c5
> (NFSv4: Don't do idmapper upcalls for asynchronous RPC calls).
>
> If I understand correctly what happens, do_coredump() [fs/exec.c] fails
> because (inode->i_uid != current_fsuid()). In fact inode->i_uid equals
> -2, because decode_attr_owner() [fs/nfs/nfs4xdr.c], which is called from
> nfs4_xdr_dec_open() via decode_getfattr(), returns without calling
> nfs_map_to_uid(), since its may_sleep parameter is false.
>
> I however do not clearly understand what the aforementioned commit is
> supposed to fix. I read the linux-nfs mailing list archive, and tried
> some google search, but I didn't find anything.
rpciod threads should never do anything that can cause them to sleep.
Doing an upcall as part of an XDR decode is therefore verboten.
We should ideally rather be saving the owner/group strings and doing the
upcall after the XDR is done. While that wasn't feasible when 'fattr'
structs were being allocated on the stack, now that they are dynamically
allocated, maybe we can rethink that...
Cheers
Trond
^ permalink raw reply [flat|nested] 6+ messages in thread
* Empty core dumps on NFSv4 mounts
@ 2011-12-05 20:09 Chuck Lever
2011-12-05 20:14 ` Myklebust, Trond
0 siblings, 1 reply; 6+ messages in thread
From: Chuck Lever @ 2011-12-05 20:09 UTC (permalink / raw)
To: Trond Myklebust; +Cc: Linux NFS Mailing List
Bump.
http://comments.gmane.org/gmane.linux.nfs/33390
We have evidence that this is still occurring as late as 3.0. Have recent idmapper changes addressed this issue?
--
Chuck Lever
chuck[dot]lever[at]oracle[dot]com
^ permalink raw reply [flat|nested] 6+ messages in thread
* RE: Empty core dumps on NFSv4 mounts
2011-12-05 20:09 Empty core dumps on NFSv4 mounts Chuck Lever
@ 2011-12-05 20:14 ` Myklebust, Trond
2011-12-05 20:19 ` Chuck Lever
0 siblings, 1 reply; 6+ messages in thread
From: Myklebust, Trond @ 2011-12-05 20:14 UTC (permalink / raw)
To: Chuck Lever; +Cc: Linux NFS Mailing List
No. There have been no kernel idmapper changes since then.
The correct thing to do here is to cache the string name in struct
nfs_fattr, and then do the upcall from the caller of OPEN. I believe
that Arnaud wrote a patch to do this, however the whole pNFS merge got
in my way of reviewing this. Feel free to take a look at what he did,
and post comments...
Cheers
Trond
> -----Original Message-----
> From: Chuck Lever [mailto:chuck.lever@oracle.com]
> Sent: Monday, December 05, 2011 3:10 PM
> To: Myklebust, Trond
> Cc: Linux NFS Mailing List
> Subject: Empty core dumps on NFSv4 mounts
>
> Bump.
>
> http://comments.gmane.org/gmane.linux.nfs/33390
>
> We have evidence that this is still occurring as late as 3.0. Have
recent
> idmapper changes addressed this issue?
>
> --
> Chuck Lever
> chuck[dot]lever[at]oracle[dot]com
>
>
>
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Empty core dumps on NFSv4 mounts
2011-12-05 20:14 ` Myklebust, Trond
@ 2011-12-05 20:19 ` Chuck Lever
2011-12-05 20:21 ` Myklebust, Trond
0 siblings, 1 reply; 6+ messages in thread
From: Chuck Lever @ 2011-12-05 20:19 UTC (permalink / raw)
To: Myklebust, Trond; +Cc: Linux NFS Mailing List
On Dec 5, 2011, at 3:14 PM, Myklebust, Trond wrote:
> No. There have been no kernel idmapper changes since then.
>
> The correct thing to do here is to cache the string name in struct
> nfs_fattr, and then do the upcall from the caller of OPEN. I believe
> that Arnaud wrote a patch to do this, however the whole pNFS merge got
> in my way of reviewing this. Feel free to take a look at what he did,
> and post comments...
We're looking at his patch, from July 2010, now. It calls kmalloc() in the XDR decoder. Is there a newer version?
> Cheers
> Trond
>
>> -----Original Message-----
>> From: Chuck Lever [mailto:chuck.lever@oracle.com]
>> Sent: Monday, December 05, 2011 3:10 PM
>> To: Myklebust, Trond
>> Cc: Linux NFS Mailing List
>> Subject: Empty core dumps on NFSv4 mounts
>>
>> Bump.
>>
>> http://comments.gmane.org/gmane.linux.nfs/33390
>>
>> We have evidence that this is still occurring as late as 3.0. Have
> recent
>> idmapper changes addressed this issue?
>>
>> --
>> Chuck Lever
>> chuck[dot]lever[at]oracle[dot]com
>>
>>
>>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Chuck Lever
chuck[dot]lever[at]oracle[dot]com
^ permalink raw reply [flat|nested] 6+ messages in thread
* RE: Empty core dumps on NFSv4 mounts
2011-12-05 20:19 ` Chuck Lever
@ 2011-12-05 20:21 ` Myklebust, Trond
0 siblings, 0 replies; 6+ messages in thread
From: Myklebust, Trond @ 2011-12-05 20:21 UTC (permalink / raw)
To: Chuck Lever; +Cc: Linux NFS Mailing List
> -----Original Message-----
> From: Chuck Lever [mailto:chuck.lever@oracle.com]
> Sent: Monday, December 05, 2011 3:19 PM
> To: Myklebust, Trond
> Cc: Linux NFS Mailing List
> Subject: Re: Empty core dumps on NFSv4 mounts
>
>
> On Dec 5, 2011, at 3:14 PM, Myklebust, Trond wrote:
>
> > No. There have been no kernel idmapper changes since then.
> >
> > The correct thing to do here is to cache the string name in struct
> > nfs_fattr, and then do the upcall from the caller of OPEN. I believe
> > that Arnaud wrote a patch to do this, however the whole pNFS merge
got
> > in my way of reviewing this. Feel free to take a look at what he
did,
> > and post comments...
>
> We're looking at his patch, from July 2010, now. It calls kmalloc()
in the XDR
> decoder. Is there a newer version?
Not as far as I know, and I agree that calling kmalloc in the XDR is a
problem... If, however, we can accept that it will occasionally fail,
then perhaps kmalloc(GFP_NOWAIT) might be acceptable?
Cheers
Trond
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2011-12-05 20:21 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2011-12-05 20:09 Empty core dumps on NFSv4 mounts Chuck Lever
2011-12-05 20:14 ` Myklebust, Trond
2011-12-05 20:19 ` Chuck Lever
2011-12-05 20:21 ` Myklebust, Trond
-- strict thread matches above, loose matches on Subject: below --
2010-07-02 8:01 Arnaud Giersch
2010-07-02 13:03 ` Trond Myklebust
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).