On Mon, Nov 17, 2014 at 1:27 PM, Christian Riesch <christian.rie...@omicron.at> wrote: > Signed-off-by: Christian Riesch <christian.rie...@omicron.at> > Cc: Peter Hurley <pe...@hurleysoftware.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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
