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: <CAFd_ZdCmqfj_Y80ZJih5G5Zn1nW0pE-R+gRFBMWRULjN7SNCkA@mail.gmail.com>
Date: Fri, 9 May 2025 12:40:13 -0400
From: Jake Rice <jake@...erice.dev>
To: Greg KH <gregkh@...uxfoundation.org>
Cc: linux-usb@...r.kernel.org, stern@...land.harvard.edu, 
	usb-storage@...ts.one-eyed-alien.net, linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH] usb: storage: Add blockbuffer ptr to info struct of
 sddr09 driver

On Fri, May 9, 2025 at 10:45 AM Greg KH <gregkh@...uxfoundation.org> wrote:
>
> On Tue, May 06, 2025 at 03:15:31PM -0400, Jake Rice wrote:
> > Hi all,
> >
> > This patch updates the sddr09 driver to allocate a reusable block
> > buffer. Unfortunately, I don't have access to the SDDR-00 hardware
> > (which I know is pretty ancient), so I'm requesting testing from anyone who does.
> > Please let me now if the patch causes any issues or improves performance.
> >
> > Best,
> > Jake
> >
> > ---
> > Currently, upon every write the block buffer is allocated and freed which is
> > computationally expensive. With this implementation, a buffer pointer
> > is added as a member to the info struct and allocated when the card
> > information is read. The buffer is freed during desconstruction if
> > necessary.
>
> As Alan said, this is really slow hardware so I doubt allocating/free
> the buffer will even be noticeable.  Why make this change at all if you
> don't have access to the hardware to test it?
>
> thanks,
>
> greg k-h
Alan and Greg,

I apologize, I was learning about the usb subsystem/usb drivers and
saw the TODO for this and figured it was a quick implementation. I
should have waited until I got the hardware before submitting the
change. It won't happen again.

In any case, thank you, I appreciate the feedback. I ordered the
device to test this. If I find a significant performance improvement,
I will re-submit.

Best,
Jake

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ