Stephen Hemminger wrote:
The skb is always consumed so the the return value is informational only.
Yes, this is true. Handing off an skb to netif_rx() relieves the driver
of further responsibility for it.
Jeff
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
Patrick McHardy <[EMAIL PROTECTED]> wrote:
>
> This leaves the question what to do in the path after ip_output,
> when skb->dev points to the output device. We don't know the
> input device anymore, so there doesn't seem to be a way to make
> it do what the sysctl promises.
Perhaps we could chang
On Sat, 19 May 2007 21:47:00 -0400
Jeff Garzik <[EMAIL PROTECTED]> wrote:
> Dan Williams wrote:
> > On Fri, 2007-05-18 at 14:09 -0400, John W. Linville wrote:
> >> On Wed, May 16, 2007 at 05:01:27PM -0400, Florin Malita wrote:
> >>> In libertas_process_rxed_packet() and process_rxed_802_11_packet(
David Miller <[EMAIL PROTECTED]> wrote:
> From: Dave Johnson <[EMAIL PROTECTED]>
>>
>> The below patch changes rt_run_flush() to only take each spinlock
>> protecting the rt_hash_table once instead of taking a spinlock for
>> every hash table bucket (and ending up taking the same small set
>> of
On Sat, 19 May 2007 15:38:29 -0700 (PDT)
David Miller <[EMAIL PROTECTED]> wrote:
> From: Michal Piotrowski <[EMAIL PROTECTED]>
> Date: Sun, 20 May 2007 00:06:33 +0200
>
> > Subject: OOPS triggered by ip(8) deconfiguring a network interface
> > References : http://bugzilla.kernel.org/show_bug.
Dan Williams wrote:
On Fri, 2007-05-18 at 14:09 -0400, John W. Linville wrote:
On Wed, May 16, 2007 at 05:01:27PM -0400, Florin Malita wrote:
In libertas_process_rxed_packet() and process_rxed_802_11_packet() the
skb is dereferenced after being passed to netif_rx (called from
libertas_upload_r
On Fri, 2007-05-18 at 14:09 -0400, John W. Linville wrote:
> On Wed, May 16, 2007 at 05:01:27PM -0400, Florin Malita wrote:
> > In libertas_process_rxed_packet() and process_rxed_802_11_packet() the
> > skb is dereferenced after being passed to netif_rx (called from
> > libertas_upload_rx_packet)
On Sun, 20 May 2007 00:30:55 +0200 "Sasa Ostrouska" <[EMAIL PROTECTED]> wrote:
> Hi everybody,
>
> I tried today to upgrade the kernel to 2.6.21.1 and i got the same
> error during the boot time.
> Here is the dmesg of the 2.6.20.2, can somebody tell me what this is ?
>
> ...
>
> Marvell 88E1101
The bridge cleanup timer is fired 10 times a second for timers that are
at least 15 seconds ahead in time and that are not critical to be
cleaned asap.
This patch calculates the next time to run the timer as the minimum of
all timers or a minimum based on the current state.
Signed-Off-By: Baruch
From: Michal Piotrowski <[EMAIL PROTECTED]>
Date: Sun, 20 May 2007 00:06:33 +0200
> Subject: OOPS triggered by ip(8) deconfiguring a network interface
> References : http://bugzilla.kernel.org/show_bug.cgi?id=8491
> Submitter : Ben Collins <[EMAIL PROTECTED]>
> Status : Unknown
Might be
Hi all,
Here is a list of some known regressions in 2.6.22-rc2.
Feel free to add new regressions/remove fixed etc.
http://kernelnewbies.org/known_regressions
Networking
Subject: OOPS triggered by ip(8) deconfiguring a network interface
References : http://bugzilla.kernel.org/show_bug.cgi?
From: Patrick McHardy <[EMAIL PROTECTED]>
Date: Thu, 17 May 2007 18:52:29 +0200
> [IPV4]: icmp: fix crash with sysctl_icmp_errors_use_inbound_ifaddr
>
> When icmp_send is called on the local output path before the
> packet hits ip_output, skb->dev is not set, causing a crash
> when sysctl_icmp_er
From: Herbert Xu <[EMAIL PROTECTED]>
Date: Sat, 19 May 2007 07:21:48 +1000
> On Fri, May 18, 2007 at 02:34:12PM +1000, Herbert Xu wrote:
> >
> > Actually, I think we should just probe for the specific algorithm
> > requested rather than everything. See patch below.
>
> Doh, forgot to actually r
From: "Ilpo_Järvinen" <[EMAIL PROTECTED]>
Date: Fri, 18 May 2007 12:17:44 +0300 (EEST)
> State could become inconsistent in two cases:
>
> 1) Userspace disabled FRTO by tuning sysctl when one of the TCP
>flows was in the middle of FRTO algorithm (and then RTO is
>again triggered)
>
> 2)
From: "Ilpo_Järvinen" <[EMAIL PROTECTED]>
Date: Fri, 18 May 2007 12:15:21 +0300 (EEST)
> The conservative spurious RTO response did not queue CWR even
> though the sending rate was lowered. Whenever reduction happens
> regardless of reason, CWR should be sent (forgetting to send it
> is not very f
Signed-off-by: Richard Knutsson <[EMAIL PROTECTED]>
---
Compile-tested with all(yes|mod|no)config on x86(|_64) & sparc(|64)
Diffed against Linus' git-tree.
diff --git a/drivers/net/8139cp.c b/drivers/net/8139cp.c
index e8c9f27..635d0ab 100644
--- a/drivers/net/8139cp.c
+++ b/drivers/net/8139cp.c
Signed-off-by: Richard Knutsson <[EMAIL PROTECTED]>
---
Compile-tested with all(yes|mod|no)config on x86(|_64) & sparc(|64)
Diffed against Linus' git-tree.
de4x5.c | 98
de4x5.h |9 -
2 files changed, 49 insertions(+), 58
Vasantha Kumar Puttappa a écrit :
Hi All,
Please somebody guide me here. I desparatley need help regarding this
issue. ( plz do "reply to all")
I am tracking all udp packets (in particular, SIP based UDP packets)that
goes through the iptables using LOG mechanism.
I use the following command,
From: Ivo van Doorn <[EMAIL PROTECTED]>
Date: Sat, 19 May 2007 14:08:43 +0200
> coverity has spotted a bug in rfkill.c (bug id #1627),
> in rfkill_allocate() NULL was returns if the kzalloc() works,
> and deref the NULL pointer if it fails,
>
> Signed-off-by: Ivo van Doorn <[EMAIL PROTECTED]>
I
Stephen Hemminger <[EMAIL PROTECTED]> writes:
>
> I would think a non-conditional deref would be easily pipelined.
> If the net_device struct was more cache dense, it probably would
> even out.
It might be a good idea to consider strategic prefetch points for it.
e.g. TCP executes quite a lot of
coverity has spotted a bug in rfkill.c (bug id #1627),
in rfkill_allocate() NULL was returns if the kzalloc() works,
and deref the NULL pointer if it fails,
Signed-off-by: Ivo van Doorn <[EMAIL PROTECTED]>
---
diff --git a/net/rfkill/rfkill.c b/net/rfkill/rfkill.c
index a973603..f3986d4 100644
-
Some weeks ago, I posted [0] asking for help about current handling of
promisc mode. I didn't have any answer but I kept researching on this.
I found that the new mechanism for using promisc mode (PACKET_{ADD|
REMOVE}_MEMBERSHIP) modify the dev->promiscuity counter and set the
IFF_PROMISC bit in d
On Fri, 18 May 2007, Rick Jones wrote:
> or is this more of a "once ssthresh is above this, behave in this new
> way?"
Not even that is very exact, since both ssthresh and cwnd have to be above
max_ssthresh to get any new behavior...
--
i.
-
To unsubscribe from this list: send the line "u
On Sat, 19 May 2007, Ilpo Järvinen wrote:
> but since nothing else seems to have came up
...Doh, I must have been gazing somewhere else while scanning the list
mails, please ignore this, I apologize for the noise...
--
i.
On Fri, 18 May 2007, John Heffner wrote:
> Rick Jones wrote:
> > as an asside, "tcp_max_ssthresh" sounds like the maximum value ssthresh can
> > take-on. is that correct, or is this more of a "once ssthresh is above
> > this, behave in this new way?" If that is the case, while the
>
> I don't
On Fri, 18 May 2007, Baruch Even wrote:
> I'm not a native English speaker but "at most" sounds a bit awkward to
> me, maybe change it to "by no more than". But I'm sure someone can find
> a better phrasing.
Neither am I, but since nothing else seems to have came up, here is one
with your propos
26 matches
Mail list logo
