linux-kernel - Re: [3.0.0+][Regression][Bisected] CIFS: getdents() broken for large dirs

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CAH2r5mu9POJmnXPQSq9cnXJU05oW0bn71+Y3Oo0YPB_uhz1cKQ@mail.gmail.com>
Date:	Tue, 2 Aug 2011 16:49:49 -0500
From:	Steve French <smfrench@...il.com>
To:	Jeff Layton <jlayton@...hat.com>
Cc:	Jan Seiffert <kaffeemonster@...glemail.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	sfrench@...ibm.com, linux-cifs@...r.kernel.org
Subject: Re: [3.0.0+][Regression][Bisected] CIFS: getdents() broken for large dirs

your explanation makes sense.  will revert the commit unless anyone objects.

On Tue, Aug 2, 2011 at 4:43 PM, Jeff Layton <jlayton@...hat.com> wrote:
> On Tue, 2 Aug 2011 11:03:28 -0500
> Steve French <smfrench@...il.com> wrote:
>
>> your patch does look right.
>>
>
> Sigh...as is often the case, things are not quite so simple...
>
> I did some auditing of how server->maxBuf is used in the cifs code and
> found it to be very confused. The reason it basically works, I think is
> because on NEGOTIATE, the client does this:
>
>       server->maxBuf = min(le32_to_cpu(pSMBr->MaxBufferSize),
>                       (__u32) CIFSMaxBufSize + MAX_CIFS_HDR_SIZE);
>
> So using maxBuf and CIFSMaxBufSize interchangeably like the code does
> is basically OK, even if it is confusing to limit how much the client
> can receive based on how much the server can.
>
> I think that we really need to approach this more comprehensively and
> have a clear delineation between server->maxBuf and CIFSMaxBufSize. I
> don't think it would be wise though to put that into 3.1 at this point.
>
> I think it would probably be best to just back out commit c4d3396b2 for
> now, and I'll plan to do this as a larger (and hopefully better-tested)
> patchset for 6.2.
>
> Sound ok? Do you need me to send a revert patch?
>
> --
> Jeff Layton <jlayton@...hat.com>
>



-- 
Thanks,

Steve
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/