Probably reasonable. How often are you hitting this (roughly) in cthon test run now? I don't remember seeing it much before - do you remember seeing it before?
On Mon, Aug 8, 2011 at 10:50 AM, Jeff Layton <[email protected]> wrote: > Running the cthon tests on a recent kernel caused this message to pop > occasionally: > > CIFS VFS: did not end path lookup where expected namelen is 0 > > Some added debugging showed that namelen and dfsplen were both 0 when > this occurred. That means that the read_seqretry returned true. > > Assuming that the comment inside the if statement is true, this should > be harmless and just means that we raced with a rename. If that is the > case, then there's no need for alarm and we can demote this to cFYI. > > While we're at it, print the dfsplen too so that we can see what > happened here if the message pops during debugging. > > Cc: [email protected] > Cc: Al Viro <[email protected]> > Signed-off-by: Jeff Layton <[email protected]> > --- > fs/cifs/dir.c | 4 ++-- > 1 files changed, 2 insertions(+), 2 deletions(-) > > diff --git a/fs/cifs/dir.c b/fs/cifs/dir.c > index ae576fb..72d448b 100644 > --- a/fs/cifs/dir.c > +++ b/fs/cifs/dir.c > @@ -105,8 +105,8 @@ cifs_bp_rename_retry: > } > rcu_read_unlock(); > if (namelen != dfsplen || read_seqretry(&rename_lock, seq)) { > - cERROR(1, "did not end path lookup where expected namelen is > %d", > - namelen); > + cFYI(1, "did not end path lookup where expected. namelen=%d " > + "dfsplen=%d", namelen, dfsplen); > /* presumably this is only possible if racing with a rename > of one of the parent directories (we can not lock the dentries > above us to prevent this, but retrying should be harmless) */ > -- > 1.7.6 > > -- Thanks, Steve -- To unsubscribe from this list: send the line "unsubscribe linux-cifs" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
