linux-kernel - Re: [RFC PATCH] n_tty: Add memory barriers where required for lock-less circular buffer

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]

Date:	Mon, 17 Nov 2014 14:48:48 +0100
From:	Christian Riesch <christian.riesch@...cron.at>
To:	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Cc:	Christian Riesch <christian.riesch@...cron.at>,
	Peter Hurley <peter@...leysoftware.com>
Subject: Re: [RFC PATCH] n_tty: Add memory barriers where required for
 lock-less circular buffer

On Mon, Nov 17, 2014 at 1:27 PM, Christian Riesch
<christian.riesch@...cron.at> wrote:
> Signed-off-by: Christian Riesch <christian.riesch@...cron.at>
> Cc: Peter Hurley <peter@...leysoftware.com>
[...]

> [2] https://lkml.org/lkml/2014/11/11/77

Uupps, [2] should point to https://lkml.org/lkml/2014/11/13/1 instead.
v3 instead of v2. Sorry.

>
>  drivers/tty/n_tty.c |   93 +++++++++++++++++++++++++++++++++++----------------
>  1 file changed, 64 insertions(+), 29 deletions(-)
>
> diff --git a/drivers/tty/n_tty.c b/drivers/tty/n_tty.c
> index 47ca0f3..656d868 100644
> --- a/drivers/tty/n_tty.c
> +++ b/drivers/tty/n_tty.c

[...]

> @@ -165,14 +180,18 @@ static int receive_room(struct tty_struct *tty)
>  {
>         struct n_tty_data *ldata = tty->disc_data;
>         int left;
> +       size_t head, tail;
> +
> +       head = ldata->read_head;
> +       tail = ACCESS_ONCE(ldata->read_tail);

I just noticed that this is probably wrong, since receive_room is
called from both the consumer and producer paths.

>
>         if (I_PARMRK(tty)) {
> -               /* Multiply read_cnt by 3, since each byte might take up to
> -                * three times as many spaces when PARMRK is set (depending on
> -                * its flags, e.g. parity error). */
> -               left = N_TTY_BUF_SIZE - read_cnt(ldata) * 3 - 1;

BTW does this make sense? When the data is in the buffer, it is
already expanded by the PARMRK feature. Only new data could be
expanded by a factor of 3 when PARMRK is set.
Shouldn't that be (N_TTY_BUF_SIZE - read_cnt(ldata) - 1)/3 ?

Regards, Christian
--
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/