On Mon, Dec 6, 2010 at 2:15 AM, Suresh Jayaraman <sjayaraman@xxxxxxx> wrote:
>
> As the FIXME points out correctly, now filldir() itself returns -EOVERFLOW if
> it not possible to represent the inode number supplied by the filesystem in
> the field provided by userspace.
>
> Signed-off-by: Suresh Jayaraman <sjayaraman@xxxxxxx>
> ---
> fs/cifs/readdir.c | 12 ------------
> 1 files changed, 0 insertions(+), 12 deletions(-)
>
> diff --git a/fs/cifs/readdir.c b/fs/cifs/readdir.c
> index 32d300e..a73eb9f 100644
> --- a/fs/cifs/readdir.c
> +++ b/fs/cifs/readdir.c
> @@ -759,18 +759,6 @@ static int cifs_filldir(char *pfindEntry, struct file *file, filldir_t filldir,
> rc = filldir(direntry, qstring.name, qstring.len, file->f_pos,
> ino, fattr.cf_dtype);
>
> - /*
> - * we can not return filldir errors to the caller since they are
> - * "normal" when the stat blocksize is too small - we return remapped
> - * error instead
> - *
> - * FIXME: This looks bogus. filldir returns -EOVERFLOW in the above
> - * case already. Why should we be clobbering other errors from it?
> - */
> - if (rc) {
> - cFYI(1, "filldir rc = %d", rc);
> - rc = -EOVERFLOW;
> - }
> dput(tmp_dentry);
> return rc;
> }
Makes sense - Any objections to pushing this upstream now.
--
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
