linux-kernel - Re: [PATCH v2 3/6] USB: serial: f81232: use usb_control_msg_recv() and usb_control_msg

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: <YUnKzz1Cwsc9hT++@hovoldconsulting.com>
Date:   Tue, 21 Sep 2021 14:06:39 +0200
From:   Johan Hovold <johan@...nel.org>
To:     Himadri Pandya <himadrispandya@...il.com>
Cc:     gregkh@...uxfoundation.org, linux-usb@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 3/6] USB: serial: f81232: use usb_control_msg_recv()
 and usb_control_msg_send()

On Mon, Aug 02, 2021 at 02:01:19AM +0530, Himadri Pandya wrote:
> New wrapper functions usb_control_msg_send/recv accept stack variables
> for usb message buffer and eliminate the need of creating temporary dma
> buffers. The wrappers also have proper error checks for short
> read/writes. Hence use the wrappers instead of using usb_control_msg()
> directly.
> 
> Signed-off-by: Himadri Pandya <himadrispandya@...il.com>

I amended the commit message as follows when applying this one:

 USB: serial: f81232: use usb_control_msg_recv() and usb_control_msg_send()
    
    The new wrapper functions usb_control_msg_send/recv accept stack
    variables for USB message buffers and eliminate the need of manually
    allocating temporary DMA buffers. The read wrapper also treats short
    reads as errors. Hence use the wrappers instead of using
    usb_control_msg() directly.
    
    Note that the conversion of f81534a_ctrl_set_register() adds an extra an
    extra allocation and memcpy for every retry. Since this function is
    called rarely and retries are hopefully rare, the overhead should be
    acceptable.
    
    Also note that short reads are now logged as -EREMOTEIO instead of
    indicating the amount of data read.

Johan