From: "Andrew Morton" <[EMAIL PROTECTED]>
> Your analysis is correct. It's a bug.
>
> Furthermore, n_hdlc_tty_open() (for example) can sleep prior to
> incrementing the module refcount, which means the module can be
> unloaded while it's running. I cut a patch ages ago which fixes
> this one f
Kevin Buhr wrote:
>
> ...
> When changing line disciplines, "sys_ioctl" gets the big kernel lock
> for us, and the "tty_set_ldisc" function doesn't get any additional
> locks. It just calls the line discipline "open" function.
>
> Suppose, at this point, the modem hangs up. From a hardware
> i
Paul Mackerras <[EMAIL PROTECTED]> writes:
>
> I didn't realize you were talking about linux 2.4.0 and pppd 2.3.11.
That was my stupid oversight. I carefully tested and retested the
patch under 2.4.0-test5, then ported it to 2.4.2 and sent it off with
only a cursory check using the new pppd [sm
Kevin Buhr writes:
> I didn't realize my specific hang was a peculiarity of the older
> attachment style. The channel created by pushing the PPP line
I didn't realize you were talking about linux 2.4.0 and pppd 2.3.11.
> discipline onto a TTY was connected to a unit with a PPPIOCATTACH
> ioctl
Paul Mackerras <[EMAIL PROTECTED]> writes:
>
> But the waiting process must have had an instance of /dev/ppp open and
> attached to the channel in order to be doing anything with rwait,
> within either ppp_file_read or ppp_poll. The process of attaching to
> the channel increases its refcnt, mea
Kevin Buhr writes:
> If there's a hangup in the TTY layer on an async PPP channel,
> do_tty_hangup shuts down the PPP line discipline, and, in ppp_async.c,
> the function ppp_asynctty_close unregisteres the channel. In
> ppp_generic.c, ppp_unregister_channel merrily wakes up the rwait
> queue, t
6 matches
Mail list logo
