linux-kernel - Re: [PATCH] mos7840: fix chars_in

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: <20160929100929.GF5650@localhost>
Date:   Thu, 29 Sep 2016 12:09:29 +0200
From:   Johan Hovold <johan@...nel.org>
To:     Stas Sergeev <stsp@...t.ru>
Cc:     Caylan Van Larson <i@...lan.net>,
        Alan Cox <alan@...rguk.ukuu.org.uk>,
        Johan Hovold <johan@...nel.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        linux-usb@...r.kernel.org, linux-kernel@...r.kernel.org,
        sergei.shtylyov@...entembedded.com
Subject: Re: [PATCH] mos7840: fix chars_in_buffer() return value

On Sat, Sep 24, 2016 at 06:00:57PM +0300, Stas Sergeev wrote:
> The TIOCOUTQ ioctl calls chars_in_buffer(), and some apps depend on
> a correct behaviour of that.
> mos7840 implements it wrongly: if you write just one char, TIOCOUTQ
> will return 32.
> This patch should fix it by accounting the number of chars actually
> written.
> This patch, unfortunately, misses the Tested-by tag.
> The reporter didn't test it, and I don't have the hardware in question.

Why do you think the driver returns 32b in chars_in_buffer after writing
a single character?

As far as I can see, the driver correctly sums up the outstanding bytes
in its queue (represented by the submitted URBs). There is a tiny window
where the count may be a little off due to the write() implementation
claiming the URB before initialising it, but I'm not sure anyone cares.

But specifically, if you write just one character, TIOCOUTQ does indeed
return a correct count.

Also note that your patch would break the driver in case a line
discipline forwards an empty write request.

Thanks,
Johan