ll is made
synchronously and not in a tasklet.
Looking at the stack traces earlier in this thread, it seems to me that
even if the PPPoE call was made in a tasklet, this same warning could be
generated.
--
Michal Ostrowski
[EMAIL PROTECTED]
Jarek Poplawski wrote:
On Wed, Apr 11, 2007 at 12:52:
below is a patch that just removes dead code/initializers without any
effect (first access is an assignment) that I stumbled accross while
reading the source.
Signed-off-by: Florian Zumbiehl <[EMAIL PROTECTED]>
Acked-by: Michal Ostrowski <[EMAIL PROTECTED]>
---
drivers/net/pp
ocess
will ever need to create a PPPoE socket, no? Allocating all session IDs
for a known AC is a kind of DoS, too, after all - with Juniper ERXes,
this is really easy, actually, since they don't ever assign session ids
above 8000 ...
Signed-off-by: Florian Zumbiehl <[EMAIL PROTECTED]
ers at the
"NETDEV_GOING_DOWN" phase (just to pretend to be nice). However, it is the
NETDEV_DOWN scan that takes all the responsibility for ensuring nobody is
hanging around at that time.
Signed-off-by: Florian Zumbiehl <[EMAIL PROTECTED]>
Acked-by: Michal Ostrowski <[EMAIL PROTECT
stent manner.
pppoe_hash_lock protects the contents of the "pppox_sock" objects that reside
inside the hash. Thus, NULL'ing out the pppoe_dev field should be done
under the protection of this lock.
Signed-off-by: Michal Ostrowski <[EMAIL PROTECTED]>
---
rying to do that now would just cause patch conflicts).
--
Michal Ostrowski <[EMAIL PROTECTED]>
[PATCH] PPPOE Fix device tear-down notification.
pppoe_flush_dev() kicks all sockets bound to a device that is going down.
In doing so, locks must be taken in the right order consisten
I'd like to ask you to please use a "Signed-off-by" statement.
That why I can ack it and push it upstream without hesitation.
--
Michal Ostrowski <[EMAIL PROTECTED]>
On Sun, 2007-03-11 at 05:41 +0100, Florian Zumbiehl wrote:
> Hi,
>
> below you find the la
; is this related to some
other work you are doing or is it correctness as a virtue?
--
Michal Ostrowski <[EMAIL PROTECTED]>
On Wed, 2007-03-07 at 15:32 +0100, Florian Zumbiehl wrote:
> Hi,
>
> > In the current code SID 0 indicates that the socket is to be un-bound.
>
&g
ack
patches in this regard. However, I don't see what there is to be
actually gained by pursuing this. I'm open to being convinced; what is
the motivation behind this? If there is a real problem here I'll be
glad to get involved in fixing it myself.
--
Michal Ostrowski <[EMAI
his code would require that the user-space component be
synchronized with this change; as the socket interface implies that 0 is
an invalid/unbound session id.
Lots of badness will occur if 0 is allowed as a session id, and nothing
will be gained because it can't possibly be a valid session id
Sorry for the late reply I've been on the road the past few days.
I ACK the patch.
I'll need to think about it some more, but we could probably go a step
further and eliminate the MAC address from the hash as well.
--
Michal Ostrowski <[EMAIL PROTECTED]>
On Sat, 2007-03-0
hardcoded MTU.
--
Michal Ostrowski <[EMAIL PROTECTED]>
On Tue, 2006-09-26 at 09:32 +0300, Pekka Savola wrote:
> Speaking of PPPoE and MTU, does Linux support recently-published RFC
> 4638:
>
>Accommodating a Maximum Transit Unit/Maximum Receive Unit (MTU/MRU)
>
On Sun, 2006-09-24 at 18:41 -0700, David Miller wrote:
> From: Michal Ostrowski <[EMAIL PROTECTED]>
> Date: Sun, 24 Sep 2006 07:29:25 -0500
>
> > I think the call path via dev->hard_start_xmit, if it fails, may result
> > in an skb not being freed. This appears
uch a case.
>
I think the call path via dev->hard_start_xmit, if it fails, may result
in an skb not being freed. This appears to be the case with the e100.c
driver. The qdisc_restart path to dev->hard_start_xmit also appears
susceptible to this. It appears that not all devices agree a
The connection between these two hosts is via your ISP right?
I'd like to see a third trace, synchronized to the other two, performed
on 213.139.163.144: tcpdump -n -i eth0
This will show me what PPPoE packets are being sent (on the other side
of the ppp0 device).
--
Michal Ostrowski
O
15 matches
Mail list logo
