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 <jlayton@xxxxxxxxxx> 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: stable@xxxxxxxxxx
> Cc: Al Viro <viro@xxxxxxxxxxxxxxxxxx>
> Signed-off-by: Jeff Layton <jlayton@xxxxxxxxxx>
> ---
> 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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
