Re: [PATCH][CIFS] Workaround MacOS server problem with SMB2.1 write response

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, Aug 14, 2014 at 3:44 PM, Jeremy Allison <jra@xxxxxxxxx> wrote:
> On Thu, Aug 14, 2014 at 04:40:14PM -0400, Jeff Layton wrote:
>>
>> Failing here won't change the buffer allocation. That buffer has
>> already been allocated, and the receive is complete at this point. So
>> any "damage" has already been done.
>
> Yep. You've got to have read the data to know it's too much !
>
>> So, I just don't get why you'd bother with an arbitrary limit at all.
>> The error checking is _simpler_ if you don't bother with this limit. Or
>> am I missing something here?
>
> Nope. The server has to deal with the same problem
> as well. We just accept what the client sends inside
> the NetBIOS length limit, and ignore anything after
> the "useful" data within the packet.
>
> Doesn't matter *what* is in the extra bits, code
> data, whatever. We don't look at it.
>
> Steve, what is the problem with just ignoring the
> extra data ? If it offends you - log a warning
> message is the rfc1001 length is too long and
> ignore it.

It does bug me that the server would send
arbitrary amount of junk since it can slow
down the client.

I looked at the printk ratelimit stuff but
it looked like it was not worth the trouble
to avoid the log floods.

Perhaps just log if the length is off by
more than 3? So if some server is
off by more than the Mac write response
we can tell them.  Is it even worth the
trouble to ratelimit the log message if
we don't know of any server's that are off
by that much.


-- 
Thanks,

Steve
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [Samba]     [Device Mapper]     [CEPH Development]
  Powered by Linux