linux-kernel - Re: [Patch] Increase USBFS Bulk Transfer size

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <CA+O4pC+mBw9wQp6kAiVVTc8FABGf2bCtmWLYVuJxmELdH+PGPg@mail.gmail.com>
Date:	Thu, 13 Oct 2011 11:39:57 +0200
From:	Markus Rechberger <mrechberger@...il.com>
To:	Manu Abraham <abraham.manu@...il.com>
Cc:	Greg KH <gregkh@...e.de>, Alan Stern <stern@...land.harvard.edu>,
	USB list <linux-usb@...r.kernel.org>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: [Patch] Increase USBFS Bulk Transfer size

On Thu, Oct 13, 2011 at 11:34 AM, Manu Abraham <abraham.manu@...il.com> wrote:
>> yes the PID is 0x1fff which are null packets over there, so those ones are okay.
>> Main point is it works and it would even comply with certain HW specs (the other
>> device points out about 256*188 bulk transfer buffer sizes.
>>
>> Now it would be the time for some people to open their eyes and get
>> that patch in.
>
>
> Call me dumb, but it still defies my logic why there would be stream
> corruption with a smaller buffer size, if the driver is handling the
> stream correctly.
>

you can see it in the logfile that the TS packets don't start as they should
0x47 is not the first value which is wrong and so on. And this is a
fact which everyone
can see by looking at the logfile.
At least every second transfer would have to start with 0x47, at the
point of logging the userspace
application does not have access to the USB buffer.

> I can probably imagine that there could be a likely chance, user space
> would have to poll more often in case with smaller buffers, while
> making it larger you increase the latency of the stream; that being a
> double edged blade.
>
>
>> The maximum transfer buffer size was derived from our other device which can
>> do the flexible setting. According to the specification it is no magic value.
>
>
> So, with your single device, if you were to make changes to some
> "magical constants"; and tomorrow if someone wants to have
> modifications again, what would you do ?

please do some investigation about the patch, if the value is
increased it does not
affect any previous application. That constant is not readable from
the kernel so applications
need to hardcode it. Small buffers are totally unrelated to that.

That is what I don't like here that some people are talking without
doing their homework and reviewing
what it is about.

> If that change is a must,
> maybe it should be configurable in some way, rather than having
> another fixed magical number.
>

Although I agree with that one.

BR,
Markus
--
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/