Hello,
From: Herbert Xu <[EMAIL PROTECTED]>
Date: Sun, 14 Oct 2007 12:27:40 +0800
> [SKBUFF]: Add skb_morph
>
> This patch creates a new function skb_morph that's just like skb_clone
> except that it lets user provide the spare skb that will be overwritten
> by the one that's to be cloned.
>
>
> Except C doesn't have namespaces and this mechanism doesn't create them. So
> this is just complete and utter makework; as I said before, noone's going to
> confuse all those udp_* functions if they're not in the udp namespace.
I don't understand why you're so opposed to organizing the ker
> > I agree that we shouldn't make things too hard for out-of-tree
> > modules, but I disagree with your first statement: there clearly is a
> > large class of symbols that are used by multiple modules but which are
> > not generically useful -- they are only useful by a certain small class
>
On Sun, 25 Nov 2007 16:12:57 +0100 Wagner Ferenc <[EMAIL PROTECTED]> wrote:
> Hi,
>
> Am I totally of the limit with the attached patch against
> drivers/net/bonding/bond_sysfs.c? I'd like to receive some comments,
> as I'm not a kernel developer.
Plese alwayts cc netdev@vger.kernel.org on netw
On Mon, Nov 26, 2007 at 12:03:46PM +0900, Masahide NAKAMURA wrote:
>
> With SMP enabled kernel, I found a lock problem at xfrm_state_walk()
> path with the patch on current net-2.6.25. Its log is "circular locking
> dependency detected".
Thanks. Ingo Molnar reported that too.
I'm just going to r
Hello Herbert,
Wednesday 10 October 2007 09:48, Herbert Xu wrote:
> On Tue, Oct 09, 2007 at 01:33:07PM -0700, David Miller wrote:
> >
> > I would be more careful with the changelog description for
> > something like this in the future. It sounds like this
> > patch will cause us to touch userspac
Ian Brown <[EMAIL PROTECTED]> wrote:
>
> 3) in net/core/dst.c:
> struct dst_entry *dst_destroy(struct dst_entry * dst)
>{
>...
>...
> int nohash = dst->flags & DST_NOHASH;
>...
>...
> }
You were so close :)
This is where it's used. Look harder.
David Schwartz <[EMAIL PROTECTED]> wrote:
>
> Exactly. But *he* doesn't need to check that checksum, given that he already
> got the packet, since he has an upper-level checksum. He is not saying that
> his reasoning applies to everyone, just that it applies to him. He is not
> talking about disabl
On Sun, Nov 25, 2007 at 01:21:44PM -0800, Stephen Hemminger wrote:
>
> No too wasteful. I'm working a patch to eth_type_trans to realign if
> needed for any device.
If you're going to do that you can probably compute the checksum
at the same time.
Cheers,
--
Visit Openswan at http://www.openswa
On Sun, Nov 25, 2007 at 06:04:17PM +0100, Johannes Berg wrote:
>
> I'd think that totally depends on the traffic. If you have a non-QoS AP
> with WPS upstream connection, then the traffic to stations will be
> four-byte aligned while the WPS upstream will be at a 2-byte-mod-4
> boundary. And you'll
On Monday 26 November 2007 07:27:03 Roland Dreier wrote:
> > This patch allows to export symbols only for specific modules by
> > introducing symbol name spaces. A module name space has a white
> > list of modules that are allowed to import symbols for it; all others
> > can't use the symbols.
On Monday 26 November 2007 07:29:39 Roland Dreier wrote:
> > Yes, and if a symbol is already used by multiple modules, it's
> > generically useful. And if so, why restrict it to in-tree modules?
>
> I agree that we shouldn't make things too hard for out-of-tree
> modules, but I disagree with you
On Saturday 24 November 2007 23:39:43 Andi Kleen wrote:
> On Sat, Nov 24, 2007 at 03:53:34PM +1100, Rusty Russell wrote:
> > So, you're saying that there's a problem with in-tree modules using
> > symbols they shouldn't? Can you give an example?
[ Note: no response to this ]
> > If people aren't
Martin Michlmayr <[EMAIL PROTECTED]> :
[...]
> I'd like to backport the fix to the 2.6.18 kernel that is in our
> stable release and have a couple of questions:
> - Does your later patch "align the IP header when there is no DMA
>constraint" fix any bugs or is it merely an improvement?
It fix
On Sunday November 25 2007 04:25:06 pm Stephen Hemminger wrote:
>
> Two important bits of data:
>
> 1) What is hardware (output of lspci and dmesg) would be useful to know
> which type
> of board is involved.
uname -srvm:
Linux 2.6.24-rc3 #1 SMP PREEMPT Sat Nov 17 00:26:41 EST 2007 x86_64
CONFIG
Elvis Pranskevichus wrote:
Paul Collins wrote:
Hi Stephen,
Running amd64 kernel built from 2ffbb8377c7a0713baf6644e285adc27a5654582
after about three days of uptime, this morning I found the network dead
and the following in dmesg:
sky2 eth0: hung mac 7:69 fifo 0 (165:176)
sky2 eth0: r
Herbert Xu wrote:
On Sat, Nov 24, 2007 at 12:11:08PM -0800, Stephen Hemminger wrote:
Then what about hardware that can't dma ethernet to non-aligned address.
Sky2 hardware breaks if DMA is not 8 byte aligned. IMHO the IP stack should
handle any alignment, and do the appropriate memove if the
> Yes, and if a symbol is already used by multiple modules, it's generically
> useful. And if so, why restrict it to in-tree modules?
I agree that we shouldn't make things too hard for out-of-tree
modules, but I disagree with your first statement: there clearly is a
large class of symbols that
> This patch allows to export symbols only for specific modules by
> introducing symbol name spaces. A module name space has a white
> list of modules that are allowed to import symbols for it; all others
> can't use the symbols.
>
> It adds two new macros:
>
> MODULE_NAMESPACE_ALLOW(na
> > Hmm. I don't think so. Take an AP for example. It gets a lot of packets
> > from stations. Now, if you're not QoS capable then all is well. But i
> > you are and some stations are as well then all those stations send QoS
> > packets (+2 bytes). Or take an AP connected via wireless (WPS), WPS h
On Mon, Nov 19, 2007 at 09:26:39PM -0800, David Miller wrote:
> From: Adrian Bunk <[EMAIL PROTECTED]>
> Date: Thu, 8 Nov 2007 04:30:10 +0100
>
> > @davem:
> >
> > Please look at net/ipv4/arp.c:arp_process()
> >
> > Am I right that CONFIG_NET_ETHERNET=n and CONFIG_NETDEV_1000=y or
> > CONFIG_NET
> David Schwartz <[EMAIL PROTECTED]> wrote:
> >> Regardless of whatever verifications your application is doing
> >> on the data, it is not checksumming the ports and that's what
> >> the pseudo-header is helping with.
> > So what? We are in the case where the data has already gotten
> > to him.
Hello, netdev,
I try, in vain, to understand what is DST_NOHASH for.
I looked for DST_NOHASH under the linux source tree (http://lxr.linux.no/source)
and found that it appears in 4 files:
1) in include/net/dst.h (just defined there, #define DST_NOHASH 8)
2)
in xfrm4_policy.c:
static int
__xfrm4
On Sun, Nov 25, 2007 at 02:54:24PM +0100, Johannes Berg wrote:
>
> But I do have a choice where to fix it up and I'd prefer the drivers to
> do it where necessary. For that, the warning would work because it'd
> show driver authors that they need to fix something.
Fair enough.
> Hmm. I don't thin
> > Not sure. On the one hand, yeah, that's something we should probably do,
> > on the other hand this will suck because for most drivers either nothing
> > needs to be done or the fixup is trivial. I suppose we should do this
> > but stick in a WARN_ON_ONCE() or something, at least with mac80211
On Sun, Nov 25, 2007 at 12:00:28PM +0100, Johannes Berg wrote:
>
> Not sure. On the one hand, yeah, that's something we should probably do,
> on the other hand this will suck because for most drivers either nothing
> needs to be done or the fixup is trivial. I suppose we should do this
> but stick
> Sorry I was wrong about the 8 bytes requirement. Although the
> IPv6 protocol does try to maintain an 8-byte alignment the Linux
> stack never does anything that requires that.
>
> So 4 bytes is enough.
Whew. Good to hear.
> However, the wireless core is definitely not out of the woods.
> It
27 matches
Mail list logo
