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

[Christian Riesch]

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

> [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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/