linux-kernel - Re: [PATCH] Increase usbfs bulk buffer 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 for Android: free password hash cracker in your pocket

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

Message-ID: <20110819052629.GA32682@suse.de>
Date:	Thu, 18 Aug 2011 22:26:29 -0700
From:	Greg KH <gregkh@...e.de>
To:	Markus Rechberger <mrechberger@...il.com>
Cc:	linux-usb@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] Increase usbfs bulk buffer size

On Thu, Aug 18, 2011 at 09:13:04PM +0200, Markus Rechberger wrote:
> On Thu, Aug 18, 2011 at 8:37 PM, Greg KH <gregkh@...e.de> wrote:
> > On Wed, Aug 17, 2011 at 07:07:01PM +0200, Markus Rechberger wrote:
> >> Hi,
> >>
> >> this patch increases the maximum buffersize for bulk transfers, our
> >> devices support at least up to 46k bytes for bulk transfers.
> >> This patch allows us to lower the iterations between kernel and
> >> userspace and lower the system pressure.
> >
> > But as Oliver pointed out, this increases the memory pressure.  I'm
> > curious why you say there is "system pressure" with the current buffer
> > size.  What is the problems here, you are just passing the same logic
> > issues down to the kernel, that you should be handling in userspace if
> > you want to use usbfs.
> >
> 
> userspace applications are not realtime applications, the bigger the buffer
> the less buffers will be required.

In userspace, yes, but it's not "free", you still end up allocating the
same amount of memory in the kernel instead.  And larger memory
allocations like this, provide more memory pressure on the system
overall, which can cause problems.

> As noted this is just 1/4th the buffersize we are already using with
> Isochronous.  Back then with small isochronous buffers even moving the
> mozilla GUI window could cause incomplete data (and I'm talking about
> 170mbit per second transfers here), with increased buffers this issue
> is gone (and it's gone since I submitted a similar patch for
> isochronous ~1-2 years ago).  In case of bulk allocations can go down
> for 2/3 of the current pressure, of course it goes up on another side
> but that side has a better performance.

Do you have real numbers and example programs that show the difference
of this kernel change making a real difference?

> >> Signed-off-by: Markus Rechberger <mrechberger@...il.com>
> >
> > Also note that this is a user/kernel API that you are changing, are you
> > _sure_ you didn't just break some user code with this change that was
> > assuming that the buffer size was 16Kb, as it's been that way for the
> > past 10 years?
> >
> 
> just the check about the maximum allowed buffer size will be
> increased, nothing else.
> Existing applications will still go for 16k.

Yes, but you just changed the value the kernel can accept, which could
cause problems.

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/