Bug 68444

Summary: pppd dies in persist mode with redhats version of kernel 2.4.18
Product: [Retired] Red Hat Linux Reporter: Leo Bergolth <leo>
Component: pppAssignee: Thomas Woerner <twoerner>
Status: CLOSED NOTABUG QA Contact: Aaron Brown <abrown>
Severity: medium Docs Contact:
Priority: medium    
Version: 7.3CC: leo
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2004-08-16 16:08:05 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
syslog entries to illustrate the pppd problem
none
dirty patch that restarts pppd after it died from this error none

Description Leo Bergolth 2002-07-10 09:38:41 UTC
Description of Problem:
I'm experiencing problems after upgrading from Redhat 7.2 (kernel 2.4.9) to 7.3
(Kernel 2.4.18).

I've been using pppd (ppp-2.4.1-3 rpm) (in an ISDN-setup together with
capiplugin) for several month in persist-mode without problems with RH 7.2 and
kernel 2.4.9.
However, after the kernel upgrade, pppd dies when trying to reconnect after the
line was hung up. The problem seems to be some new kernel-code that causes the
PPPIOCDETACH ioctl to fail:

Jul  7 10:44:29 homer kernel: PPPIOCDETACH file->f_count=3

This corresponds to the following code in ppp_generic.c, which is patched in
Redhat's version of the kernel (patch: linux-2.4.17-selected-ac-bits.patch):

---------- snipp! ----------
        if (cmd == PPPIOCDETACH) {
                /*
                 * We have to be careful here... if the file descriptor
                 * has been dup'd, we could have another process in the
                 * middle of a poll using the same file *, so we had
                 * better not free the interface data structures -
                 * instead we fail the ioctl.  Even in this case, we
                 * shut down the interface if we are the owner of it.
                 * Actually, we should get rid of PPPIOCDETACH, userland
                 * (i.e. pppd) could achieve the same effect by closing
                 * this fd and reopening /dev/ppp.
                 */
                err = -EINVAL;
                if (pf->kind == INTERFACE) {
                        ppp = PF_TO_PPP(pf);
                        if (file == ppp->owner)
                                ppp_shutdown_interface(ppp);
                }
                if (atomic_read(&file->f_count) <= 2) {
                        ppp_release(inode, file);
                        err = 0;
                } else
                        printk(KERN_DEBUG "PPPIOCDETACH file->f_count=%d\n",
                               atomic_read(&file->f_count));
                return err;
        }
---------- snipp! ----------

The documentation tells:
* PPPIOCDETACH detaches the instance from the channel.  This ioctl is
  deprecated since the same effect can be achieved by closing the
  instance.  In order to prevent possible races this ioctl will fail
  with an EINVAL error if more than one file descriptor refers to this
  instance (i.e. as a result of dup(), dup2() or fork()). 

# /usr/sbin/lsof /dev/ppp
COMMAND   PID USER   FD   TYPE DEVICE SIZE    NODE NAME
pppd    24396 root    4u   CHR  108,0      1311344 /dev/ppp
pppd    24396 root   10u   CHR  108,0      1311344 /dev/ppp



Version-Release number of selected component (if applicable):
kernel-2.4.18

How Reproducible:


Steps to Reproduce:
1. Run pppd in persist mode.
2. Unplug the telephone line

Actual Results:
pppd fails with "Couldn't release PPP unit: Invalid argument"

Expected Results:


Additional Information:
corresponding syslog entries are attached

Comment 1 Leo Bergolth 2002-07-10 09:41:13 UTC
Created attachment 64567 [details]
syslog entries to illustrate the pppd problem

Comment 2 Leo Bergolth 2002-07-19 09:26:19 UTC
I've applied a dirty patch to ppp-watch which restarts pppd after it died from
the above error. This temporarily fixes my problem but it is not a clean
solution since pppd signals a fatal error which shouldn't be treated like that.


Comment 3 Leo Bergolth 2002-07-19 09:28:51 UTC
Created attachment 65905 [details]
dirty patch that restarts pppd after it died from this error

Comment 4 Thomas Woerner 2004-08-16 16:08:05 UTC
Please verify this with a newer version of Red Hat Enterprise Linux or
Fedora Core and reopen it against the new version if it still occurs.

Closing as "not a bug" for now.