On Tue, 13 Mar 2007, Roland McGrath wrote:
>
> Ok, fine. But PATH_MAX is a real constant that has some meaning in the
> kernel. It's perfectly correct to use PATH_MAX as a constant on a system
> like Linux that defines it and means what it says. Conversely, OPEN_MAX
> has no useful relationsh
On Tue, 13 Mar 2007 12:04:18 -0700, Stephen Hemminger <[EMAIL PROTECTED]> wrote:
> > + * 1.35Fix an usage of streaming DMA API.
> > */
>
> Please don't use comments as changelog anymore. It gets out of date.
> The use of change control systems has made this practice obsolete.
OK, Jeff, shou
> I'd actually prefer this as part of the "remove OPEN_MAX" patch.
Ok. (But now you're going to argue with me about "remove OPEN_MAX",
and you haven't said you have any problem with changing SCM_MAX_FD,
so why make it wait?)
> That said, it actually worries me that you should call "_SC_OPEN_MAX"
On 3/13/07, Jesse Brandeburg <[EMAIL PROTECTED]> wrote:
acme, good stuff, but does the " * 4" generate equivalent assembly
with gcc 3/4 as " << 2" ?
I could assume that the compiler would be smart enough, but every time
I assume I know what the compiler is doing I get myself in trouble.
neverm
On 3/13/07, Arnaldo Carvalho de Melo <[EMAIL PROTECTED]> wrote:
Introduce tcp_hdrlen() and tcp_optlen():
The ip_hdrlen() buddy, created to reduce the number of skb->h.th-> uses and to
avoid the longer, open coded equivalent.
+static inline unsigned int tcp_hdrlen(const struct sk_buff *skb)
+{
+
This is an experimental to the iproute2 command set.
The version number includes the kernel version to denote what features are
supported. The same source should build on older systems, but obviously the
newer kernel features won't be available. As much as possible, this package
tries to be source
These are a bit more subtle, they are of this type:
- skb->h.raw = payload;
__skb_pull(skb, payload - skb->data);
+ skb_reset_transport_header(skb);
__skb_pull results in:
skb->data = skb->data + payload - skb->data;
skb->data = payload;
So after __skb_pull we have skb->data
Signed-off-by: Arnaldo Carvalho de Melo <[EMAIL PROTECTED]>
---
net/sctp/input.c |8
net/sctp/ipv6.c |5 ++---
2 files changed, 6 insertions(+), 7 deletions(-)
From b9c0a34313240c6f74bcc5587a496493480daf7d Mon Sep 17 00:00:00 2001
From: Arnaldo Carvalho de Melo <[EMAIL PROTECTED]>
For the places where we need a pointer to the transport header, it is
still legal
to touch skb->h.raw directly if just adding to, subtracting from or setting it
to another layer header.
Signed-off-by: Arnaldo Carvalho de Melo <[EMAIL PROTECTED]>
---
drivers/net/appletalk/ltpc.c|7 +--
Signed-off-by: Arnaldo Carvalho de Melo <[EMAIL PROTECTED]>
---
drivers/net/gianfar.c |4 ++--
drivers/net/ioc3-eth.c|2 +-
drivers/net/mv643xx_eth.c |2 +-
include/linux/skbuff.h|1 -
include/linux/udp.h |9 +
include/net/udplite.h |2 +-
net/core/n
Signed-off-by: Arnaldo Carvalho de Melo <[EMAIL PROTECTED]>
---
include/linux/icmp.h |9 +
include/linux/skbuff.h |1 -
net/dccp/ipv4.c|4 ++--
net/ipv4/ah4.c |4 ++--
net/ipv4/esp4.c|4 ++--
net/ipv4/icmp.c| 14 +++---
net/ipv4/ip_
Signed-off-by: Arnaldo Carvalho de Melo <[EMAIL PROTECTED]>
---
drivers/net/atl1/atl1_main.c |7 ---
drivers/net/bnx2.c |8
drivers/net/chelsio/sge.c |2 +-
drivers/net/cxgb3/sge.c|2 +-
drivers/net/e1000/e1000_main.c | 11 ++-
drivers/n
Signed-off-by: Arnaldo Carvalho de Melo <[EMAIL PROTECTED]>
---
include/linux/ipv6.h |5 +
include/linux/skbuff.h |1 -
net/ipv6/xfrm6_mode_beet.c |4 ++--
net/ipv6/xfrm6_mode_tunnel.c |8
4 files changed, 11 insertions(+), 7 deletions(-)
From bb1c2a7d91b74
Signed-off-by: Arnaldo Carvalho de Melo <[EMAIL PROTECTED]>
---
drivers/net/sk98lin/skge.c |4 ++--
drivers/net/skge.c |2 +-
include/linux/ip.h |5 +
include/linux/skbuff.h |1 -
net/ipv4/xfrm4_mode_tunnel.c |6 +++---
net/ipv6/xfrm6_mode_tunnel.c |
Signed-off-by: Arnaldo Carvalho de Melo <[EMAIL PROTECTED]>
---
include/linux/igmp.h | 21 +
include/linux/skbuff.h |1 -
net/ipv4/igmp.c| 22 +++---
net/ipv4/ipmr.c|2 +-
4 files changed, 33 insertions(+), 13 deletions(-)
From 515b800d
For the cases where the transport header is being set to a offset from
skb->data.
Signed-off-by: Arnaldo Carvalho de Melo <[EMAIL PROTECTED]>
---
include/linux/skbuff.h |6 ++
net/ax25/af_ax25.c | 20
net/ax25/ax25_in.c
For consistency with all the other skb->h.raw accessors.
Signed-off-by: Arnaldo Carvalho de Melo <[EMAIL PROTECTED]>
---
include/linux/sctp.h |9 +
net/sctp/input.c | 14 +-
net/sctp/ipv6.c |4 ++--
net/sctp/protocol.c | 10 --
4 files changed, 20 ins
For consistency with all the other skb->h.raw accessors.
Signed-off-by: Arnaldo Carvalho de Melo <[EMAIL PROTECTED]>
---
include/linux/icmpv6.h |9 +
net/ipv6/datagram.c|2 +-
net/ipv6/icmp.c|8
net/ipv6/mcast.c |6 +++---
net/ipv6/ndisc.c |
The ip_hdrlen() buddy, created to reduce the number of skb->h.th-> uses and to
avoid the longer, open coded equivalent.
Ditched a no-op in bnx2 in the process.
I wonder if we should have a BUG_ON(skb->h.th->doff < 5) in tcp_optlen()...
Signed-off-by: Arnaldo Carvalho de Melo <[EMAIL PROTECTED]>
Hi David,
Please consider pulling from:
master.kernel.org:/pub/scm/linux/kernel/git/acme/net-2.6.22
We're getting close...
Thanks a lot!
- Arnaldo
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo i
For the common, open coded 'skb->h.raw = skb->data' operation, so that we can
later turn skb->h.raw into a offset, reducing the size of struct sk_buff in
64bit land while possibly keeping it as a pointer on 32bit.
This one touches just the most simple cases:
skb->h.raw = skb->data;
skb->h.raw =
For the quite common 'skb->h.raw - skb->data' sequence.
Signed-off-by: Arnaldo Carvalho de Melo <[EMAIL PROTECTED]>
---
drivers/net/atl1/atl1_main.c | 10 +-
drivers/net/cassini.c |6 ++
drivers/net/cxgb3/sge.c|7 ---
drivers/net/e1000/e1000_m
On Sun, 25 Feb 2007 12:02:23 -0500
jamal <[EMAIL PROTECTED]> wrote:
>
> cheers,
> jamal
>
applied both patches
--
Stephen Hemminger <[EMAIL PROTECTED]>
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at htt
On Sun, 4 Mar 2007 20:14:53 +0100 (MET)
Patrick McHardy <[EMAIL PROTECTED]> wrote:
> This patchset consists of four parts:
>
> - minor TBF time conversion fix
>
> - consolidation of time calculations: consolidate commonly used expressions
> with the goal of making it easier to audit for integ
On Tue, Mar 13, 2007 at 08:42:05PM +0100, Johannes Berg wrote:
> On Mon, 2007-03-12 at 10:56 -0700, Jean Tourrilhes wrote:
>
> > I did that in the e-mail to Jouni. The problem is that most
> > people are unfamiliar with decoding iwevents, so can't grasp the
> > explanation.
> > Basically,
On Tue, 13 Mar 2007, Roland McGrath wrote:
>
> The OPEN_MAX constant is an arbitrary number with no useful relation to
> anything. Nothing should be using it. SCM_MAX_FD is just an arbitrary
> constant and it should be clear that its value is chosen in net/scm.h
> and not actually derived from
It isn't any faster to test a boolean global variable than do a
simple check for empty list.
Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]>
---
net/core/dev.c | 18 +-
1 files changed, 5 insertions(+), 13 deletions(-)
diff --git a/net/core/dev.c b/net/core/dev.c
index 3a
Hi Stephen,
On Mon, Mar 12, 2007 at 02:11:56PM -0700, Stephen Hemminger wrote:
> > Oh BTW, I have a newer version with a first approximation of the
> > cbrt() before the div64_64, which allows us to reduce from 3 div64
> > to only 2 div64. This results in a version which is twice as fast
> > as th
On Tue, 13 Mar 2007 12:39:54 -0700 (PDT)
David Miller <[EMAIL PROTECTED]> wrote:
> From: Eric Dumazet <[EMAIL PROTECTED]>
> Date: Tue, 13 Mar 2007 14:38:32 +0100
>
> > But memcmp() has a strong semantic (in libc). memcmp(a, b, 6) should
> > do 6 byte compares and conditional branches, regardless
> > -#define SCM_MAX_FD (OPEN_MAX-1)
> > +#define SCM_MAX_FD (NR_OPEN-1)
>
> This is a bad idea. [...]
Ok. My only agenda is to get rid of OPEN_MAX.
I then propose the following instead.
Thanks,
Roland
---
[PATCH] avoid OPEN_MAX in SCM_MAX_FD
The OPEN_MAX constant is an arbitrary number wit
On Mon, 2007-03-12 at 10:56 -0700, Jean Tourrilhes wrote:
> I did that in the e-mail to Jouni. The problem is that most
> people are unfamiliar with decoding iwevents, so can't grasp the
> explanation.
> Basically, for iwpoint, we have an outer lenght and an inner
> length. If they don
From: Eric Dumazet <[EMAIL PROTECTED]>
Date: Tue, 13 Mar 2007 14:38:32 +0100
> But memcmp() has a strong semantic (in libc). memcmp(a, b, 6) should
> do 6 byte compares and conditional branches, regardless of a/b
> alignment. Or use the x86 "rep cmpsb" instruction that basically
> has the same co
On Tue, Mar 13, 2007 at 04:53:54PM +0300, Sergei Shtylyov wrote:
> Mark Brown wrote:
> >confused and eventually locks up. Before locking up it will usually
> >report one or more oversided packets so this is a useful hint that we
> >should reset the recieve state machine in order to recover from t
Stephen Hemminger <[EMAIL PROTECTED]> writes:
>
> /*
> * FIXME: On x86 and some other CPUs the split into user and softirq parts
> * is not needed because addl $1,memory is atomic against interrupts (but
> * atomic_inc would be overkill because of the lock cycles). Wants new
> * nonlocked_a
On Wed, 14 Mar 2007 01:02:20 +0900 (JST)
Atsushi Nemoto <[EMAIL PROTECTED]> wrote:
> The tc35815 driver lacks a call to pci_dma_sync_single_for_device() on
> receiving. Recent fix of MIPS dma_sync_single_for_cpu() reveal this
> bug.
>
> Signed-off-by: Atsushi Nemoto <[EMAIL PROTECTED]>
> ---
> T
Alex Sidorenko wrote:
Here are the values from live kernel (obtained with 'crash') when the host was
in SWS state:
full_space=708 full_space/2=354
free_space=393
window=76
In this case the test from my original fix, (window < full_space/2),
succeeds. But John's test
free_space > w
On 12/03/07, Tejun Heo <[EMAIL PROTECTED]> wrote:
Stephen Hemminger wrote:
> On Tue, 13 Mar 2007 04:03:00 +0900
> Tejun Heo <[EMAIL PROTECTED]> wrote:
>
>> Stephen Hemminger wrote:
1. the controller has IRQ stuck high (infrequent but possible)
2. the IRQ is already requested by another
On Mon, Mar 12, 2007 at 10:07:33AM -0400, Jeff Garzik wrote:
> Pekka Enberg wrote:
> >Hi,
> >
> >On 3/12/07, Valerie Henson <[EMAIL PROTECTED]> wrote:
> >>--- tulip-2.6-mm-linux.orig/drivers/net/tulip/tulip_core.c
> >>+++ tulip-2.6-mm-linux/drivers/net/tulip/tulip_core.c
> >>@@ -17,11 +17,11 @@
> >
The tc35815 driver lacks a call to pci_dma_sync_single_for_device() on
receiving. Recent fix of MIPS dma_sync_single_for_cpu() reveal this
bug.
Signed-off-by: Atsushi Nemoto <[EMAIL PROTECTED]>
---
This patch can be applied to netdev-2.6 tree or 2.6.21-rc3-mm2.
diff --git a/drivers/net/tc35815.c
Hi,
and the last one for now: Acquire the sock lock in pppoe_sendmsg()
before accessing the sock - and in particular avoid releasing the lock
even though it hasn't been acquired.
Florian
---
Signed-off-by: Florian Zumbiehl <
Hi,
I'm not sure whether this is really worth it, but it looked so
extremely inefficient that I couldn't resist - so let's hope providers
will keep PPPoE around for a while, at least until terabit dsl ;-)
The new code produces the same results as the old version and is
~ 3 to 6 times faster for 4
Hi,
here another patch for the PPPoX/E code that makes sure that ENOTTY is
returned for unknown ioctl requests rather than 0 (and removes another
unneeded initializer which I didn't bother creating a separate patch for).
Florian
---
On Tuesday 13 March 2007 15:44, Eric Dumazet wrote:
> Also, 'lastuse' could use a u32 too, I even had a patch for this one...
Here is the patch I have here for lastuse u32 conversion, not for inclusion
yet because not yet tested (only compiled)
[PATCH] NET : abstract lastuse (from struct dst_en
On Tuesday 13 March 2007 15:31, Andi Kleen wrote:
> Ok. When you do such changes you should always add a comment, otherwise
> it will be always destroyed with the next change.
>
> But it seems highly fragile to me anyways because it depends on the exact
> value of RTAX_MAX which tends to change r
On Tuesday 13 March 2007 15:10, Eric Dumazet wrote:
> On Tuesday 13 March 2007 14:48, Andi Kleen wrote:
> > The ICMP rate limiting state can be shorts, we don't send that many ICMPs.
> > Changing flags to short and reorder fields to be sorted by size to avoid
> > holes. Move cold fields towards the
On Tue, Mar 13, 2007 at 01:39:12AM -0700, Roland McGrath wrote:
> The OPEN_MAX constant is an arbitrary number with no useful relation to
> anything. Nothing should be using it. This patch changes SCM_MAX_FD to
> use NR_OPEN instead of OPEN_MAX. This increases the size of the struct
> scm_fp_lis
On Tuesday 13 March 2007 14:48, Andi Kleen wrote:
> The ICMP rate limiting state can be shorts, we don't send that many ICMPs.
> Changing flags to short and reorder fields to be sorted by size to avoid
> holes. Move cold fields towards the end.
>
Nope, you cannot break the reordering I've done one
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/pppoe.c | 21
below you find a patch that fixes a memory leak when a PPPoE socket is
release()d after it has been connect()ed, but before the PPPIOCGCHAN ioctl
ever has been called on it.
This is somewhat of a security problem, too, since PPPoE sockets can be
created by any user, so any user can easily allocate
below you find a patch that (hopefully) fixes a race between an interface
going down and a connect() to a peer on that interface. Before,
connect() would determine that an interface is up, then the interface
could go down and all entries referring to that interface in the
item_hash_table would be m
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 consistently (sock lock,
followed by the pppoe_hash_lock). However, the scan process is based on
us holding the sock lock. So, when something is found in the scan we must
Hello.
Mark Brown wrote:
Moving netdev_rx() would fix that one but there's some others too -
there's one in the timer routine if the chip crashes. In the case you
Erm, sorry, I'm not seeing it -- could you "point with finger" please?
:-)
In netdev_timer() when the device is using POR
The ICMP rate limiting state can be shorts, we don't send that many ICMPs.
Changing flags to short and reorder fields to be sorted by size to avoid holes.
Move cold fields towards the end.
Signed-off-by: Andi Kleen <[EMAIL PROTECTED]>
Index: linux-2.6.21-rc3-net/include/net/dst.h
===
Hello.
Mark Brown wrote:
Subject: natsemi: Fix NAPI for interrupt sharing
The interrupt status register for the natsemi chips is clear on read and
was read unconditionally from both the interrupt and from the NAPI poll
routine, meaning that if the interrupt service routine was called (for
e
On Tuesday 13 March 2007 15:01, Andi Kleen wrote:
> David Miller <[EMAIL PROTECTED]> writes:
> > From: Rick Jones <[EMAIL PROTECTED]>
> > Date: Mon, 12 Mar 2007 17:05:39 -0700
> >
> > > Being paranoid - are there no worries about the alignment of dest?
> >
> > If it's an issue, it's an issue elsewh
David Miller <[EMAIL PROTECTED]> writes:
> From: Rick Jones <[EMAIL PROTECTED]>
> Date: Mon, 12 Mar 2007 17:05:39 -0700
>
> > Being paranoid - are there no worries about the alignment of dest?
>
> If it's an issue, it's an issue elsewhere too, as the places
> where Stephen took this idiomatic co
This email lists some known regressions in Linus' tree compared to 2.6.20.
If you find your name in the Cc header, you are either submitter of one
of the bugs, maintainer of an affectected subsystem or driver, a patch
of you caused a breakage or I'm considering you in any other way
possibly involv
NetXen: This will fix a softlock seen on some machines.
The reason was too much time was spent waiting for hardware access
to go through.
Signed-off by: Mithlesh Thukral <[EMAIL PROTECTED]>
---
drivers/net/netxen/netxen_nic.h |1 +
drivers/net/netxen/netxen_nic_ethtool.c |1 +
dr
NetXen: Set the MTU for the right port depending upon the port number
for XG cards.
Signed-off by: Mithlesh Thukral <[EMAIL PROTECTED]>
---
drivers/net/netxen/netxen_nic_hw.c |5 -
1 files changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/net/netxen/netxen_nic_hw.c
b/drivers
Hi All,
I will be sending bug fixes to NetXen: 1G/10G Ethernet driver in subsequent
mails.
The patches are with respect to netdev#upstream-fixes.
Regards,
Mithlesh Thukral
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More major
On Friday 09 March 2007 21:56, Stephen Hemminger wrote:
> Linsys Contractor Mithlesh Thukral wrote:
> > NetXen: This will fix a softlock seen on some machines.
> > The reason was too much time was spent waiting for writes to go through.
> >
> > Signed-off by: Mithlesh Thukral <[EMAIL PROTECTED]>
>
o The AX.25 Howto is unmaintained since several years. I've replaced it
with a wiki at http://www.linux-ax25.org which provides more uptodate
information.
o Change default for AX25_DAMA_SLAVE to Y. AX25_DAMA_SLAVE only compiles
in support for DAMA but doesn't activate it. I hope this
On Tue, Mar 13, 2007 at 11:08:27AM +0100, Eric Dumazet ([EMAIL PROTECTED])
wrote:
> On Tuesday 13 March 2007 10:32, Evgeniy Polyakov wrote:
> > On Fri, Mar 02, 2007 at 11:52:47AM +0300, Evgeniy Polyakov
> ([EMAIL PROTECTED]) wrote:
> > So, I ask network developers about testing environment for so
On Tuesday 13 March 2007 10:32, Evgeniy Polyakov wrote:
> On Fri, Mar 02, 2007 at 11:52:47AM +0300, Evgeniy Polyakov
([EMAIL PROTECTED]) wrote:
> So, I ask network developers about testing environment for socket lookup
> benchmarking. What would be the best test case to determine performance
> of
On Fri, Mar 02, 2007 at 11:52:47AM +0300, Evgeniy Polyakov ([EMAIL PROTECTED])
wrote:
> So I get my words about tree/trie implementation instead of hash table
> for socket lookup back.
Hmm, I was a bit fast to draw a line, there are some possibilities to
have faster than hash table lookup using
On Thu, 08 Mar 2007 10:35:13 +0900 (JST), Atsushi Nemoto <[EMAIL PROTECTED]>
wrote:
> > netpoll_rx() should be invokable from hardware interrupt context.
> > What is the crash you are seeing?
>
> The problem is not netpoll_rx(). It should be called from irq context.
> The problem is, netif_recei
66 matches
Mail list logo
