public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Bob Dunlop <Bob.Dunlop@farsite.co.uk>
To: Paul Fulghum <paulkf@microgate.com>
Cc: Matt Schulkind <mschulkind@sbs.com>,
	linux-ppp@vger.kernel.org, paulus@samba.org,
	linux-kernel@vger.kernel.org
Subject: Re: Syncppp
Date: Tue, 7 Aug 2001 10:26:13 +0100	[thread overview]
Message-ID: <20010807102613.A18724@farsite.co.uk> (raw)
In-Reply-To: <3810755D5165D2118F4400104B36917AC4FD34@normandy> <002f01c11eca$1db590f0$8119fea9@diemos>
In-Reply-To: <002f01c11eca$1db590f0$8119fea9@diemos>; from paulkf@microgate.com on Mon, Aug 06, 2001 at 11:41:56PM +0100

Hi,

On Mon, Aug  6,  Paul Fulghum wrote:
> > In the 2.2.16 kernel, it seems that the ppp_device structure was changed to
> > use a pointer to the net device instead of haveing the structure contained
> > within, and the if_down procedure was changed accordingly to use the sppp_of
> > macro. But, if I take a look at the 2.4.x kernel sources, it seems only the
> > first change, the pointer vs. struct change was made, but the if_down
> > procedure was not changed. I believe this is a bug and the if_down procedure
> > in the 2.4.x kernel must be changed to match 2.2.16+. Could anyone confirm
> > this?
> > -Matt Schulkind
> 
> It looks like you are right. The current 2.4 code
> appears to scribble into the net_device structure
> someplace (yuck) when if_down() is called.

I agree it's a bug.
Well spotted!  How many times have I scrolled past that line?

On Intel (i386) it looks like it clobbers last_rx which is probably harmless,
but it's close to some hairy pointers so who knows on other architectures.
The fact that pp_link_state is not being reset could well explain how I was
getting into that negotiation loop problem earlier in the year.  The loop
fix is still a valid safety however.

> I'm going to change this and test it tomorrow to be
> for sure.

Well I've applied the obvious fix (below) and tested it on Intel with the
Farsync driver and all looks good.  Don't have access to other architectures
for any other testing.


--- linux/drivers/net/wan/syncppp.c.orig	Thu Jun 28 01:10:55 2001
+++ linux/drivers/net/wan/syncppp.c	Tue Aug  7 08:14:43 2001
@@ -156,7 +156,7 @@
 
 static void if_down(struct net_device *dev)
 {
-	struct sppp *sp = &((struct ppp_device *)dev)->sppp;
+	struct sppp *sp = (struct sppp *)sppp_of(dev);
 
 	sp->pp_link_state=SPPP_LINK_DOWN;
 }



-- 
        Bob Dunlop
        FarSite Communications Ltd.
        http://www.farsite.co.uk/

  reply	other threads:[~2001-08-07  9:26 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-08-06 19:15 Syncppp Matt Schulkind
2001-08-06 22:49 ` Syncppp Paul Fulghum
2001-08-07  9:26   ` Bob Dunlop [this message]
2001-08-07 14:32     ` Syncppp 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=20010807102613.A18724@farsite.co.uk \
    --to=bob.dunlop@farsite.co.uk \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-ppp@vger.kernel.org \
    --cc=mschulkind@sbs.com \
    --cc=paulkf@microgate.com \
    --cc=paulus@samba.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox