From: Paul Fulghum <paulkf@microgate.com>
To: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: Diego Calleja <diegocg@gmail.com>, linux-kernel@vger.kernel.org
Subject: Re: pppd oopses current linu's git tree on disconnect
Date: Tue, 24 Jan 2006 17:44:15 -0600 [thread overview]
Message-ID: <43D6BBCF.7090403@microgate.com> (raw)
In-Reply-To: <1138145129.21284.12.camel@localhost.localdomain>
Alan Cox wrote:
> Yeah the new tty code assumed the same locking rules as the old tty code
> and nobody on the planet followed them since 2.2.
I could not find any code that used the tty read_lock
when pushing data. So at least its a clean start.
> I think you've been reading my mind, only you've actually come up with a
> slightly neater variant than I have half coded here.
OK, good.
>> int tty_prepare_flip_string(struct tty_struct *tty, unsigned char **chars, size_t size)
>> {
>> int space = tty_buffer_request_room(tty, size);
>>- struct tty_buffer *tb = tty->buf.tail;
>>- *chars = tb->char_buf_ptr + tb->used;
>>- memset(tb->flag_buf_ptr + tb->used, TTY_NORMAL, space);
>>- tb->used += space;
>>+ if (space) {
>>+ struct tty_buffer *tb = tty->buf.tail;
>>+ *chars = tb->char_buf_ptr + tb->used;
>>+ memset(tb->flag_buf_ptr + tb->used, TTY_NORMAL, space);
>>+ tb->used += space;
>>+ }
Unrelated, yes.
But if space == 0 then tty->buf.tail could be NULL
Touching tb could oops. I think you already do a similar
check in tty_insert_flip_string() etc.
>> static inline void con_schedule_flip(struct tty_struct *t)
>
> Should die as a duplicate by the look of it, and the tty one probably
> should cease to be inline.
The only difference seems to be schedule_delayed_work()
in tty_schedule_flip() vs schedule_work() in con_schedule_flip().
All three:
tty_schedule_flip()
con_schedule_flip()
tty_flip_buffer_push()
seem to be duplicates other than that.
> Looks good to me.
There is still the esp and cyclades driver which
schedule the buf.work directly which need to be
switched to one of the above 3 functions.
I also found a case where the active flag
is not cleared correctly. (when a partial buffer is
filled and a new tail buffer is allocated before
calling one of the schedule functions.
I'll fix both of these up tomorrow, post a new
patch and continue testing.
Thanks,
Paul
--
Paul Fulghum
Microgate Systems, Ltd
next prev parent reply other threads:[~2006-01-24 23:44 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-01-19 0:06 pppd oopses current linu's git tree on disconnect Diego Calleja
2006-01-19 17:33 ` Paul Fulghum
2006-01-19 22:07 ` Diego Calleja
2006-01-19 22:39 ` Paul Fulghum
2006-01-23 2:42 ` Diego Calleja
2006-01-24 3:48 ` Diego Calleja
2006-01-24 22:06 ` Paul Fulghum
2006-01-24 23:25 ` Alan Cox
2006-01-24 23:44 ` Paul Fulghum [this message]
2006-01-25 0:22 ` Alan Cox
2006-01-25 21:00 ` Paul Fulghum
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=43D6BBCF.7090403@microgate.com \
--to=paulkf@microgate.com \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=diegocg@gmail.com \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.