On Mon, Dec 6, 2010 at 11:48 AM, Jeff Layton <jlayton@xxxxxxxxx> wrote:
> On Mon, 6 Dec 2010 10:26:08 -0600
> Steve French <smfrench@xxxxxxxxx> wrote:
>
>> 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.
>>
>
> No objection, but if you're going to take this, then please also take
> the three patches I sent on 11/22.
(and perhaps the fourth one, the RFC1001 name clean-up patch also?)
>
> --
> Jeff Layton <jlayton@xxxxxxxxx>
> --
> 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
>
--
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
