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+O4pCKfem5nAQvpRWBZp21XsE6Z3Nn1iDW9yosuQ3fLqhtZ1A@mail.gmail.com>
Date:	Wed, 12 Oct 2011 23:48:45 +0200
From:	Markus Rechberger <mrechberger@...il.com>
To:	Greg KH <gregkh@...e.de>
Cc:	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 Wed, Oct 12, 2011 at 10:33 PM, Greg KH <gregkh@...e.de> wrote:
> On Wed, Oct 12, 2011 at 06:59:01PM +0200, Markus Rechberger wrote:
>> On Wed, Oct 12, 2011 at 4:17 PM, Greg KH <gregkh@...e.de> wrote:
>> > On Wed, Oct 12, 2011 at 02:36:59PM +0200, Markus Rechberger wrote:
>> >> We have 2 products which can perform better with increased Bulk transfers
>> >
>> > I don't believe you :)
>> >
>> > As stated before, this patch is not acceptable.  Please work to figure
>> > out the real reason for your device problems here, this is not the
>> > correct solution at all.
>> >
>>
>> OK no device support for linux then. Windows and MacOSX are fine.
>
> That is your choice, not ours, as you are the one writing the closed
> source code.  Without usbmon dumps, showing that the problem really is
> in the kernel code, we can't do anything for you here.
>

here take your usbmon logs:
http://sundtek.de/support/working.log
http://sundtek.de/support/notworking.log (this is with your proposed
split up of 22k).

Isochronous already supports up to 190kb buffers which cause no
trouble anywhere.
Bulk is castrated to 15kb buffers and 50kb should be such a big issue
while applications
which do not request it are not affected at all.

I'm very angry that you do not really focus on what I write and just
try to write stories about
bogus things like my patch might break other applications while I
pointed out that this is not
possible with legacy applications which use this interface. It is not
even possible to read the
maximum buffer value from the kernelspace.

Your bogus message about 1Gig ram you can put it elsewhere, I checked
multiple windows drivers
in the past the buffer size varies between small and something around
50k usually.
I would fully like to avoid to patch this kernel to get those things
work because I don't want to
deal with people who just write around the actual issues.

Alsi the fact that bigger buffers are already being used plus the HW
specifications of our main device also points out to a certain
buffersize near 50k. But of course you are the smart knowitall without
the need of explanation why
those things can be affected by HW and some HW chips have options to
influence that buffer size.

I'm certainly angry,
Markus

> Best of luck,
>
> greg k-h
>
--
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/