mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Karsten Keil <kkeil@suse.de>
To: linux-kernel@vger.kernel.org, isdn4linux@listserv.isdn4linux.de
Cc: Jesper Juhl <jesper.juhl@gmail.com>, David Miller <davem@davemloft.net>
Subject: Re: [PATCH] ISDN: fix double free bug in isdn_net
Date: Tue, 15 Aug 2006 18:06:57 +0200	[thread overview]
Message-ID: <20060815160657.GA14266@pingi.kke.suse.de> (raw)
In-Reply-To: <20060815.021503.71555009.davem@davemloft.net>

On Tue, Aug 15, 2006 at 02:15:03AM -0700, David Miller wrote:
> From: "Jesper Juhl" <jesper.juhl@gmail.com>
> Date: Tue, 15 Aug 2006 11:08:35 +0200
> 
> > Hmm, perhaps I made a mistake and missed a path. Maybe it would be
> > better to fix if by making isdn_writebuf_skb_stub() always set the skb
> > to NULL when it does free it. That would add a few more assignments
> > but should ensure the right result always.
> > What do you say?
> 
> Do we know if the ->writebuf_skb() method ever frees the skb?  If it
> never does, then yes your suggestion would be one way to handle this.


It does if it consumes the skb (then it returns skb->len).
But the skb have not to be freed imediately in this case, it maybe
queued or used until all bytes are written to the physical device.

If it returns any other value the skb is not freed.

This logic came from using skb for transparent data too.
Here it was possible, that the hw driver only take some bytes from the
skb (so it returns < skb->len), then the isdn layer should requeue
the skb so no transparent data get lost.

But this mechanism was never used in drivers, only 3 states:

The driver accept the packet then it is responsible for the skb
and return skb->len or the driver do not accept it (e.g. buffer full,
conntection is going down), then it return 0 and does not free the
skb.

If some internal error in the HW driver occur, it should return a
negative value and it also do not free the skb.
 
-- 
Karsten Keil
SuSE Labs
ISDN development

  parent reply	other threads:[~2006-08-15 16:07 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-08-12 20:48 Jesper Juhl
2006-08-15  9:00 ` David Miller
2006-08-15  9:08   ` Jesper Juhl
2006-08-15  9:15     ` David Miller
2006-08-15 10:42       ` Jesper Juhl
2006-08-15 16:06       ` Karsten Keil [this message]
2006-08-16 20:22         ` Jesper Juhl
2006-08-16 20:39           ` Karsten Keil
2006-08-16 20:44             ` David Miller
2006-08-16 20:48             ` Jesper Juhl

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=20060815160657.GA14266@pingi.kke.suse.de \
    --to=kkeil@suse.de \
    --cc=davem@davemloft.net \
    --cc=isdn4linux@listserv.isdn4linux.de \
    --cc=jesper.juhl@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®