On Wed, 2012-09-19 at 15:53 +0000, Myklebust, Trond wrote: > On Wed, 2012-09-19 at 04:39 +0100, Ben Hutchings wrote: > > On Tue, 2012-09-18 at 22:26 -0300, Herton Ronaldo Krzesinski wrote: > > > On Mon, Sep 17, 2012 at 01:38:22AM +0100, Ben Hutchings wrote: > > > > 3.2-stable review patch. If anyone has any objections, please let me > > > > know. > > > > > > > > I'm not sure whether my expansion of the fix is correct here. [...] > > > I'm also not sure about the expansion of the fix here, not knowing very > > > much about nfs. It seems that the code in some cases want to discard the > > > status from decode_getfattr, for example nfs4_xdr_dec_rename is one case > > > which does the same. Is it ok to return the status of decode_getfattr on > > > nfs4_xdr_dec_open here? Or should it remain like it was before? > > > > It looks like we try to get the file and directory attributes, and those > > are nice to have but the open operation is still successful even if we > > can't get them. So my extra 'fixes' here are wrong. Trond, is this > > right? > > Hi Ben, > > We do not want to fail the RPC call in the case where the attribute > decode failed; we already have ways to recover from that situation in > the higher layers of the open code (we send a separate getattr RPC > call). If, on the other hand, the filehandle decode fails, then we are > screwed since we can't know exactly which file was just opened and this > would be the reason for Dros's patch. > > So please do leave the decode_getfattr() line as it was, and apply the > change to the decode_getfh() line only.
Thanks for the confirmation; this is what I've done. Ben. -- Ben Hutchings The world is coming to an end. Please log off.
signature.asc
Description: This is a digitally signed message part
