* Re: [patch] ipv4: initialize arp_tbl rw lock
From: Heiko Carstens @ 2006-04-15 23:00 UTC (permalink / raw)
To: David S. Miller
Cc: shemminger, jgarzik, akpm, netdev, linux-kernel, fpavlic, davem
In-Reply-To: <20060415.003457.103031290.davem@davemloft.net>
> > callchain: inet_init() -> inet_register_protosw() -> synchronize_net()
>
> The problem can't be rcu_init(), that gets done very early
> in init/main.c
>
> Maybe it's some timer or something else specific to s390?
>
> It could also be that there's perhaps nothing to context
> switch to, thus the RCU takes forever to "happen".
Changing inet_init to fs_initcall() moves it way up the chain...
There are quite a few __initcall()s (way is this mapped to
device_initcall()?) and module_init()s in places where I would
never have expected them (e.g. kernel/).
After all the dependencies are anything but obvious to me. The
only obvious solution which fixes my problem would be to convert
qeth's module_init() to late_initcall().
^ permalink raw reply
* Re: [NFS] [RFC: 2.6 patch] net/sunrpc/: possible cleanups
From: Lever, Charles @ 2006-04-15 23:01 UTC (permalink / raw)
To: Adrian Bunk
Cc: David Miller, neilb, Trond Myklebust, Linux Kernel, nfs, netdev
In-Reply-To: <20060415213215.GN15022@stusta.de>
On 4/15/06 5:32 PM, "Adrian Bunk" <bunk@stusta.de> wrote:
> On Thu, Oct 06, 2005 at 07:13:14AM -0700, Lever, Charles wrote:
>
>> actually, can we hold off on this change? the RPC transport switch will
>> eventually need most of those EXPORT_SYMBOLs.
>> ...
>>> This patch was already sent on:
>>> - 30 May 2005
>>> - 7 May 2005
>> ...
>
> One year has passed since I sent this patch the first time, and with the
> exception that it needs re-diff'ing it still applies.
>
> Charles, are the changes you are talking about that might need them
> available in the very near future?
Yes, they are coming soon.
^ permalink raw reply
* [PATCH] sungem: Marvell PHY suspend
From: Johannes Berg @ 2006-04-16 0:52 UTC (permalink / raw)
To: netdev; +Cc: Benjamin Herrenschmidt
In a short discussion with Benjamin Herrenschmidt he mentioned
that Marvell PHYs are powered down the same way as the other
ones we currently handle. Thus actually do that, hopefully
saving some power during suspend.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
CC: Benjamin Herrenschmidt <benh@kernel.crashing.org>
--- a/drivers/net/sungem_phy.c
+++ b/drivers/net/sungem_phy.c
@@ -275,7 +275,7 @@ static int bcm5411_init(struct mii_phy*
return 0;
}
-static int bcm5411_suspend(struct mii_phy* phy)
+static int generic_suspend(struct mii_phy* phy)
{
phy_write(phy, MII_BMCR, BMCR_PDOWN);
@@ -738,7 +738,7 @@ static struct mii_phy_def bcm5401_phy_de
/* Broadcom BCM 5411 */
static struct mii_phy_ops bcm5411_phy_ops = {
.init = bcm5411_init,
- .suspend = bcm5411_suspend,
+ .suspend = generic_suspend,
.setup_aneg = bcm54xx_setup_aneg,
.setup_forced = bcm54xx_setup_forced,
.poll_link = genmii_poll_link,
@@ -757,7 +757,7 @@ static struct mii_phy_def bcm5411_phy_de
/* Broadcom BCM 5421 */
static struct mii_phy_ops bcm5421_phy_ops = {
.init = bcm5421_init,
- .suspend = bcm5411_suspend,
+ .suspend = generic_suspend,
.setup_aneg = bcm54xx_setup_aneg,
.setup_forced = bcm54xx_setup_forced,
.poll_link = genmii_poll_link,
@@ -776,7 +776,7 @@ static struct mii_phy_def bcm5421_phy_de
/* Broadcom BCM 5421 built-in K2 */
static struct mii_phy_ops bcm5421k2_phy_ops = {
.init = bcm5421_init,
- .suspend = bcm5411_suspend,
+ .suspend = generic_suspend,
.setup_aneg = bcm54xx_setup_aneg,
.setup_forced = bcm54xx_setup_forced,
.poll_link = genmii_poll_link,
@@ -795,7 +795,7 @@ static struct mii_phy_def bcm5421k2_phy_
/* Broadcom BCM 5462 built-in Vesta */
static struct mii_phy_ops bcm5462V_phy_ops = {
.init = bcm5421_init,
- .suspend = bcm5411_suspend,
+ .suspend = generic_suspend,
.setup_aneg = bcm54xx_setup_aneg,
.setup_forced = bcm54xx_setup_forced,
.poll_link = genmii_poll_link,
@@ -816,6 +816,7 @@ static struct mii_phy_def bcm5462V_phy_d
* would be useful here) --BenH.
*/
static struct mii_phy_ops marvell_phy_ops = {
+ .suspend = generic_suspend,
.setup_aneg = marvell_setup_aneg,
.setup_forced = marvell_setup_forced,
.poll_link = genmii_poll_link,
^ permalink raw reply
* Re: r8169 locks up in 2.6.16.5
From: Francois Romieu @ 2006-04-16 0:58 UTC (permalink / raw)
To: Thomas A. Oehser; +Cc: netdev
In-Reply-To: <20060415204716.GA1755@jupiter.toms.net>
Thomas A. Oehser <tom@toms.net> :
[...]
> On a dual Athlon 2600+ MP with 2GB RAM, and nothing else running.
^^^^^^^^^^^^ ^^
Which motherboard and filesystem do you use ?
[...]
> Should I just give these cards away and forget I ever heard of RealTeK?
I don't think so.
> Is it known that this driver, or this card, or the combination, is unstable?
Some r8169 PR are still open (mac address change, acpi suspend/resume
and "special" motherboard) but there is no clear pattern related to
stability under load.
Can you send before and after the ping takes 9000 ms:
- ifconfig output
- registers dump via ethtool
9000ms seems quite close to the watchdog timeout (6 s) + ping
interval. Complete dmesg and .config will be welcome.
--
Ueimor
^ permalink raw reply
* Obtaining a DIPLOMA has never been so easy!
From: Zachary Roberts @ 2006-04-16 4:37 UTC (permalink / raw)
To: netdev
NO ONE is turned down.
According to the U.S. Census Bureau, with the following degrees,
here's how much you can expect to make in your lifetime:
High School Diploma: $1,100,000
Bachelor's Degree: $2,100,000
Master's Degree: $2,500,000
Doctorate: $4,400,000
You Need a Better Degree, and we can Help!
Obtain degrees from Prestigious non-accredited
Universities based on you life experience.
NO ONE is turned down.
Call Now 7 days a week.
"1-718-504-5376"
^ permalink raw reply
* Re: [PATCH] sungem: Marvell PHY suspend
From: Benjamin Herrenschmidt @ 2006-04-16 4:35 UTC (permalink / raw)
To: Johannes Berg; +Cc: netdev
In-Reply-To: <1145148738.6560.12.camel@localhost>
On Sun, 2006-04-16 at 02:52 +0200, Johannes Berg wrote:
> In a short discussion with Benjamin Herrenschmidt he mentioned
> that Marvell PHYs are powered down the same way as the other
> ones we currently handle. Thus actually do that, hopefully
> saving some power during suspend.
>
> Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
^ permalink raw reply
* [PATCH][RFC] Security marking
From: James Morris @ 2006-04-16 5:10 UTC (permalink / raw)
To: netdev, David S. Miller; +Cc: Patrick McHardy, Stephen Smalley, Chris Wright
Last year, I posted a set of patches to allow iptables matching against
associated processes for incoming packets. With this patch, I'm proposing
a much simpler alternative and solictiting feedback on the idea from other
networking developers.
For the original patches and discussion, see:
http://marc.theaimsgroup.com/?l=linux-netdev&m=113027175208707&w=2
and
http://people.redhat.com/jmorris/selinux/skfilter/
The purpose of the patches was to allow incoming owner matching to work
cleanly, as well as allow integration of SELinux and Netfilter apps
(iptables, conntrack etc). This would also allow the existing SELinux
networking hooks to be replaced in a more powerful and expressive way.
The skfilter patches posted are quite invasive, and probably require
moving all Netfilter 'input' processing to the socket layer, with several
unresolved issues.
Also, from an SELinux point of view, the skfilter patches mean handing all
of the packet-based network policy to iptables, distinct from the existing
SELinux policy language constructs and enforcement mechanisms.
At the SELinux developer summit, there was discussion of a different
approach (sorry, not sure exactly who came up with it initially), where we
instead use iptables to mark packets with security contexts, then allow
the core SELinux code to act on those markings.
A nice side-effect of this approach is that it does not require any
significant changes to the Netfilter code, as the markings are made at the
network layer via Netfilter and then interpreted at the socket layer via
the security module.
An initial idea was to make use of nfmark for this, however, it appears to
be the wrong approach. nfmark is used for and by the networking code,
configured by the admin for e.g. routing, packet classification etc. If
we also use nfmark for SELinux, then once SELinux is enabled (the default
case for two distributions), the admin will not be able to reliably use
nfmark; and nfmark manipulations will also screw up SELinux MAC. From a
design point of view, security markings should be distinct from network
markings: the former are used to implement security policy, the latter to
implement networking policy (e.g. routing).
So, I propose to introduce a secmark field (per the patch below), which is
only present when enabled as a sub-feature of LSM. That is, it does not
have any effect at all for the default kernel. As an integer field, it
also does not require the kind of lifecycle management assoicated with
security blobs, which becomes invasive for skbs.
Example usage scenario for SELinux:
1) Mark all incoming packets to port 80 with a security context of
"system_u:system_r:http_packet_t"
This would require implementing an iptables target, say SEL, which
validates the security context, obtains an integer representation
(Security ID or SID), then marks the packet with it.
# iptables -A INPUT -p tcp -m tcp --dport 80 -j SEL --ctx \
system_u:system_r:http_packet_t
2) During delivery of the packet to the receiving process, verify that the
security context of the associated socket is allowed to receive packets
with that security context.
The SELinux core code would enforce this policy via
selinux_socket_sock_rcv_skb(), using a new object class ('packet') and
associated permissions ('recv', 'send').
# allow httpd_t http_packet_t:packet { recv }
>From an SELinux point of view, this critically allows security policy to
be enforced within the AVC using a verifiable policy. It also separates
marking (labeling) from enforcement in a flexible way, allowing the
expressiveness of Netfilter apps to be used during marking, as well as
allowing the enforcement code to be greatly simplified.
This scheme does not prevent a fully iptables-based approach (e.g. add a
SELinux match and you can mark and control entirely via iptables), and
still allows useful stuff like adding security context support to the LOG
target.
Before moving ahead with any further of the above development, I'd
appreciate feedback on whether the patch below looks acceptable from a
networking point of view. This is the entirety of the changes required in
the core networking (not counting the SEL target).
Thanks,
---
include/linux/skbuff.h | 22 ++++++++++++++++++++++
net/core/skbuff.c | 3 ++-
net/ipv4/ip_output.c | 1 +
net/ipv4/netfilter/ipt_REJECT.c | 1 +
net/ipv6/ip6_output.c | 1 +
security/Kconfig | 8 ++++++++
security/selinux/Kconfig | 2 +-
7 files changed, 36 insertions(+), 2 deletions(-)
diff -purN -X dontdiff linux-2.6.17-rc1.o/include/linux/skbuff.h linux-2.6.17-rc1.w/include/linux/skbuff.h
--- linux-2.6.17-rc1.o/include/linux/skbuff.h 2006-04-15 19:57:58.000000000 -0400
+++ linux-2.6.17-rc1.w/include/linux/skbuff.h 2006-04-15 23:36:07.000000000 -0400
@@ -209,6 +209,7 @@ enum {
* @nf_bridge: Saved data about a bridged frame - see br_netfilter.c
* @tc_index: Traffic control index
* @tc_verd: traffic control verdict
+ * @secmark: security marking
*/
struct sk_buff {
@@ -285,6 +286,9 @@ struct sk_buff {
__u16 tc_verd; /* traffic control verdict */
#endif
#endif
+#ifdef CONFIG_SECURITY_NETWORK_MARK
+ __u32 secmark;
+#endif
/* These elements must be at the end, see alloc_skb() for details. */
@@ -1389,5 +1393,23 @@ static inline void nf_reset(struct sk_bu
static inline void nf_reset(struct sk_buff *skb) {}
#endif /* CONFIG_NETFILTER */
+#ifdef CONFIG_SECURITY_NETWORK_MARK
+static inline void skb_copy_secmark(struct sk_buff *to, struct sk_buff *from)
+{
+ to->secmark = from->secmark;
+}
+
+static inline void skb_init_secmark(struct sk_buff *skb)
+{
+ skb->secmark = 0;
+}
+#else
+static inline void skb_copy_secmark(struct sk_buff *to, struct sk_buff *from)
+{ }
+
+static inline void skb_init_secmark(struct sk_buff *skb)
+{ }
+#endif
+
#endif /* __KERNEL__ */
#endif /* _LINUX_SKBUFF_H */
diff -purN -X dontdiff linux-2.6.17-rc1.o/net/core/skbuff.c linux-2.6.17-rc1.w/net/core/skbuff.c
--- linux-2.6.17-rc1.o/net/core/skbuff.c 2006-04-15 19:57:58.000000000 -0400
+++ linux-2.6.17-rc1.w/net/core/skbuff.c 2006-04-15 23:40:32.000000000 -0400
@@ -456,7 +456,7 @@ struct sk_buff *skb_clone(struct sk_buff
n->tc_verd = CLR_TC_MUNGED(n->tc_verd);
C(input_dev);
#endif
-
+ skb_copy_secmark(n, skb);
#endif
C(truesize);
atomic_set(&n->users, 1);
@@ -518,6 +518,7 @@ static void copy_skb_header(struct sk_bu
#endif
new->tc_index = old->tc_index;
#endif
+ skb_copy_secmark(new, old);
atomic_set(&new->users, 1);
skb_shinfo(new)->tso_size = skb_shinfo(old)->tso_size;
skb_shinfo(new)->tso_segs = skb_shinfo(old)->tso_segs;
diff -purN -X dontdiff linux-2.6.17-rc1.o/net/ipv4/ip_output.c linux-2.6.17-rc1.w/net/ipv4/ip_output.c
--- linux-2.6.17-rc1.o/net/ipv4/ip_output.c 2006-04-15 19:57:58.000000000 -0400
+++ linux-2.6.17-rc1.w/net/ipv4/ip_output.c 2006-04-15 23:34:14.000000000 -0400
@@ -412,6 +412,7 @@ static void ip_copy_metadata(struct sk_b
nf_bridge_get(to->nf_bridge);
#endif
#endif
+ skb_copy_secmark(to, from);
}
/*
diff -purN -X dontdiff linux-2.6.17-rc1.o/net/ipv4/netfilter/ipt_REJECT.c linux-2.6.17-rc1.w/net/ipv4/netfilter/ipt_REJECT.c
--- linux-2.6.17-rc1.o/net/ipv4/netfilter/ipt_REJECT.c 2006-04-15 19:57:58.000000000 -0400
+++ linux-2.6.17-rc1.w/net/ipv4/netfilter/ipt_REJECT.c 2006-04-15 23:35:20.000000000 -0400
@@ -154,6 +154,7 @@ static void send_reset(struct sk_buff *o
/* This packet will not be the same as the other: clear nf fields */
nf_reset(nskb);
nskb->nfmark = 0;
+ skb_init_secmark(nskb);
tcph = (struct tcphdr *)((u_int32_t*)nskb->nh.iph + nskb->nh.iph->ihl);
diff -purN -X dontdiff linux-2.6.17-rc1.o/net/ipv6/ip6_output.c linux-2.6.17-rc1.w/net/ipv6/ip6_output.c
--- linux-2.6.17-rc1.o/net/ipv6/ip6_output.c 2006-04-15 19:57:58.000000000 -0400
+++ linux-2.6.17-rc1.w/net/ipv6/ip6_output.c 2006-04-15 23:33:49.000000000 -0400
@@ -458,6 +458,7 @@ static void ip6_copy_metadata(struct sk_
nf_bridge_get(to->nf_bridge);
#endif
#endif
+ skb_copy_secmark(to, from);
}
int ip6_find_1stfragopt(struct sk_buff *skb, u8 **nexthdr)
diff -purN -X dontdiff linux-2.6.17-rc1.o/security/Kconfig linux-2.6.17-rc1.w/security/Kconfig
--- linux-2.6.17-rc1.o/security/Kconfig 2006-03-20 00:53:29.000000000 -0500
+++ linux-2.6.17-rc1.w/security/Kconfig 2006-04-15 23:11:56.000000000 -0400
@@ -67,6 +67,14 @@ config SECURITY_NETWORK_XFRM
IPSec.
If you are unsure how to answer this question, answer N.
+config SECURITY_NETWORK_MARK
+ bool "Security Marking"
+ depends on SECURITY_NETWORK
+ help
+ This enables security marking of network packets, similar
+ to nfmark, but designated for security purposes.
+ If you are unsure how to answer this question, answer N.
+
config SECURITY_CAPABILITIES
tristate "Default Linux Capabilities"
depends on SECURITY
diff -purN -X dontdiff linux-2.6.17-rc1.o/security/selinux/Kconfig linux-2.6.17-rc1.w/security/selinux/Kconfig
--- linux-2.6.17-rc1.o/security/selinux/Kconfig 2006-03-20 00:53:29.000000000 -0500
+++ linux-2.6.17-rc1.w/security/selinux/Kconfig 2006-04-15 23:19:11.000000000 -0400
@@ -1,6 +1,6 @@
config SECURITY_SELINUX
bool "NSA SELinux Support"
- depends on SECURITY_NETWORK && AUDIT && NET && INET
+ depends on AUDIT && NET && INET && SECURITY_NETWORK_MARK
default n
help
This selects NSA Security-Enhanced Linux (SELinux).
^ permalink raw reply
* Re: [PATCH][RFC] Security marking
From: James Morris @ 2006-04-16 5:28 UTC (permalink / raw)
To: netdev, David S. Miller; +Cc: Patrick McHardy, Stephen Smalley, Chris Wright
In-Reply-To: <Pine.LNX.4.64.0604160012500.16600@d.namei>
On Sun, 16 Apr 2006, James Morris wrote:
> +static inline void skb_copy_secmark(struct sk_buff *to, struct sk_buff *from)
(Btw, I know the last param here needs to be const, fixed locally).
--
James Morris
<jmorris@namei.org>
^ permalink raw reply
* Kernel error
From: Saurabh Jain @ 2006-04-16 6:43 UTC (permalink / raw)
To: netdev
Hi Guys,
I am getting the following kernel error while doing some experiments.
Any idea where things are going wrong. To me it looks like there is an
error while copying data from user space to kernel space. The
application which i am running is iperf. However i also have netem
module for emulating some wide area network characteristics like
delay. I am using delay of 100ms.
##################Error Message#############################
Unable to handle kernel NULL pointer dereference at virtual address 00000004
printing eip:
c02fee3c
*pde = 7ded4067
Oops: 0002 [#5]
Modules linked in: setparam(U) sch_netem(U) nfs(U) lockd(U) autofs4(U)
sunrpc(U)CPU: 0
EIP: 0060:[<c02fee3c>] Not tainted VLI
EFLAGS: 00010286 (2.6.12-1.1390_FC4-emulab-1)
EIP is at tcp_transmit_skb+0x3ef/0x8de
eax: 00000000 ebx: f71a1a40 ecx: ed64f960 edx: ed64ff60
esi: 00000000 edi: f2f98500 ebp: ed71b780 esp: f47bddd4
ds: 007b es: 007b ss: 0068
Process iperf (pid: 2443, threadinfo=f47bc000 task=f71a1a40)
Stack: f2f9854c c02d1019 ed71b7b8 f2f98500 ed15cc80 00000282 ed71b780 00000100
c02ce99f f71a1a40 f2f98500 f71a1a40 00000000 f2f98500 f2f9854c c02f53ad
00000000 ed335db8 f2f98500 f2f98500 f47bdeb8 00000000 00000000 002ce99f
Call Trace:
[<c02d1019>] skb_copy_datagram_iovec+0x180/0x1f8
[<c02ce99f>] alloc_skb+0x31/0xc1
[<c02f53ad>] tcp_recvmsg+0x2b1/0x74e
[<c02fd83f>] tcp_rcv_established+0x5d2/0x77a
[<c02ce2e0>] sock_common_recvmsg+0x41/0x57
[<c02cb052>] sock_aio_read+0xf9/0x12b
[<c014fccb>] do_sync_read+0x9e/0xec
[<c01291ae>] autoremove_wake_function+0x0/0x37
[<c014fe23>] vfs_read+0x10a/0x10e
[<c0150064>] sys_read+0x41/0x6a
[<c0102d29>] syscall_call+0x7/0xb
Code: a1 04 07 39 c0 e8 c0 e5 e3 ff 89 c2 85 c0 74 2d 83 87 08 04 00 00 01 8b 8
#############################################################
Thanks in advance
^ permalink raw reply
* Re: fixing sk_stream_rfree()
From: Herbert Xu @ 2006-04-16 11:18 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev
In-Reply-To: <20060414.205927.13626300.davem@davemloft.net>
Hi David:
I've been flying on and off for the last two days so I only saw this now.
On Fri, Apr 14, 2006 at 08:59:27PM -0700, David S. Miller wrote:
>
> Herbert, as you may have noticed we found some missing
> locking in sk_stream_rfree(). It could explain the
> "!sk_forward_alloc" BUG() we thought was caused by e1000's
> TSO implementation and the Intel folks have provided enough
> datapoints to prove that it is indeed not an e1000 specific
> problem.
Great eyes! Yes that bug seems to have been around forever. I'll
look over the patch tomorrow as right now I'm still on west-coast
time :)
I have one niggling doubt though as to why turning off TSO seems
to cure the problem for people. Perhaps it'll become clearer
tomorrow morning when I look at it again :)
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* softmac: semantics of SIOCSIWFREQ
From: Ulrich Kunitz @ 2006-04-16 11:24 UTC (permalink / raw)
To: Johannes Berg; +Cc: netdev, softmac-dev
In-Reply-To: <1145129105.6560.2.camel@localhost>
Hi,
I'm just reviewing the zd1211 code and I'm wondering about the
semantics of SIOCSIWFREQ and actually, what is good for. It looks
like that softmac's set_channel can be called at any time and will
ignore any settings of SIOCSIWFREQ even it is has been given the
flag IW_FREQ_FIXED.
Following questions come to mind:
- Is SIOCSIWFREQ allowed while associated?
- If the flag IW_FREQ_FIXED is set, should all activitity
including scanning only be allowed on this frequency? (Actually
a better would even be to work with channel/frequency sets.
These sets would make a lot of sense for parallel scanning
whith more than one device.)
- Is there any use of the control, if the frequency is not fixed?
SIOCSIWFREQ and SIOCGIWFREQ appear to be good candidates to be
included in the softmac. If I would have a rough idea, what the
semantics should be, I would even volunteer to implement it.
Uli
--
Ulrich Kunitz - kune@deine-taler.de
^ permalink raw reply
* Re: skb diet
From: bert hubert @ 2006-04-16 11:43 UTC (permalink / raw)
To: Andi Kleen; +Cc: Hisham Kotry, netdev
In-Reply-To: <200604152122.01914.ak@suse.de>
On Sat, Apr 15, 2006 at 09:22:01PM +0200, Andi Kleen wrote:
> And optimizing for uncommon cases (not TCP) doesn't seem too useful.
There are servers that do tens of megabits of UDP these days (think VoIP, or
in my case, DNS), so it not that uncommon.
Bert
--
http://www.PowerDNS.com Open source, database driven DNS Software
http://netherlabs.nl Open and Closed source services
^ permalink raw reply
* softmac: semantics of SIOCSIWFREQ
From: Johannes Berg @ 2006-04-16 12:34 UTC (permalink / raw)
To: netdev; +Cc: softmac-dev, Jean Tourrilhes
[-- Attachment #1: Type: text/plain, Size: 1255 bytes --]
[breaking out to a new thread so discussion on this doesn't get too
hidden, CC Jean since he designed this]
> - Is SIOCSIWFREQ allowed while associated?
No idea.
> - If the flag IW_FREQ_FIXED is set, should all activitity
> including scanning only be allowed on this frequency? (Actually
> a better would even be to work with channel/frequency sets.
> These sets would make a lot of sense for parallel scanning
> whith more than one device.)
Yeah, but that's impossible to code on top of the current wext
structures I'd say.
> - Is there any use of the control, if the frequency is not fixed?
Good question :)
> SIOCSIWFREQ and SIOCGIWFREQ appear to be good candidates to be
> included in the softmac. If I would have a rough idea, what the
> semantics should be, I would even volunteer to implement it.
Yes, they definitely could/should be moved into softmac, but when
writing softmac I had no real incentive to do it because I didn't want
to dig up the info for all the above points :)
I was thinking of adding all the 'what is this ioctl supposed to do'
things we came up with to the softmac or netdev wiki. Would that be
good/useful, or should we just put it into that driver writers guide?
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 793 bytes --]
^ permalink raw reply
* Re: skb diet
From: Hisham Kotry @ 2006-04-16 12:56 UTC (permalink / raw)
To: Andi Kleen; +Cc: netdev
In-Reply-To: <200604152122.01914.ak@suse.de>
> Where would that tag list be stored if you want to remove the
> 40 bytes of ->cb?
I apologize if I wasn't clear, the tag list would go in a new
skb->tags field replacing the existsing skb->cb array, so the skb
would lose 40-sizeof(void*) bytes wich seems reasonable to me.
> Linux 2.0 did something like this, but that was removed for good
> reasons. Now TCP always clones skbs before sending it out.
Do you remember what those reasons were? I couldn't find a related
discussion in the archives. I think the BSD mbuf tags approach is
sound enough to justify the move.
> And optimizing for uncommon cases (not TCP) doesn't seem too useful.
As pointed out by Bert Hubert, there are people who have heavy traffic
on non-tcp connections.
Thanks,
Hisham
^ permalink raw reply
* Re: r8169 locks up in 2.6.16.5
From: Thomas A. Oehser @ 2006-04-16 13:42 UTC (permalink / raw)
To: Francois Romieu, netdev
In-Reply-To: <20060416005821.GA9821@electric-eye.fr.zoreil.com>
> Which motherboard and filesystem do you use ?
It's an MSI using EXT3.
> Can you send before and after the ping takes 9000 ms:
> - ifconfig output
> - registers dump via ethtool
>
> 9000ms seems quite close to the watchdog timeout (6 s) + ping
> interval. Complete dmesg and .config will be welcome.
I tested with everything turned off (no SMP, no swap, no
USB, no firewire, no iptables, no lmsensors, flat 1G memory,
etc. etc. etc.) except the bare minimum (LSI new Megaraid for the
SCSI and SATA raid arrays, both of which use the same driver, EXT3,
VGA console, keyboard, mouse). Also, with everything static and
no modules.
Changing _nothing_ other than replacing EEPRO100 with R8169 and
vice versa causes it to work perfectly or fail abominably... the
machine always had both nics physically connected, so it was just
the software change of one driver or the other as eth0.
There was no dmesg output.
Note, one thing I have noticed- it always failed when the load was
coming from the same machine. Perhaps the packets from that machine
have something about them that particularly spasms the driver?
I'll look at what nic and driver that machine is using.
Note, it will be a day or few before I can retest with ethtool etc.,
I have to do my taxes today.
-Thanks, -Tom
^ permalink raw reply
* Re: r8169 locks up in 2.6.16.5
From: Francois Romieu @ 2006-04-16 14:43 UTC (permalink / raw)
To: Thomas A. Oehser; +Cc: netdev
In-Reply-To: <20060416134201.GA2681@jupiter.toms.net>
Thomas A. Oehser <tom@toms.net> :
[...]
> I tested with everything turned off (no SMP, no swap, no
> USB, no firewire, no iptables, no lmsensors, flat 1G memory,
> etc. etc. etc.) except the bare minimum (LSI new Megaraid for the
> SCSI and SATA raid arrays, both of which use the same driver, EXT3,
> VGA console, keyboard, mouse). Also, with everything static and
> no modules.
Ok, it really looks like a genuine bug.
[...]
> Changing _nothing_ other than replacing EEPRO100 with R8169 and
> vice versa causes it to work perfectly or fail abominably... the
> machine always had both nics physically connected, so it was just
> the software change of one driver or the other as eth0.
>
> There was no dmesg output.
Then the Rx part of the driver is more screwed than the Tx one.
I'll welcome a complete dmesg after you have recovered through
ifconfig down/up though.
[...]
> Note, it will be a day or few before I can retest with ethtool etc.,
> I have to do my taxes today.
No problem. One more question: have you enabled NAPI ? If not, you
should.
--
Ueimor
^ permalink raw reply
* Re: skb diet
From: Andi Kleen @ 2006-04-16 15:16 UTC (permalink / raw)
To: Hisham Kotry; +Cc: netdev
In-Reply-To: <baebb9a00604160556o2abe6df1y4a185a0fd8f45e7b@mail.gmail.com>
On Sunday 16 April 2006 14:56, Hisham Kotry wrote:
> > Where would that tag list be stored if you want to remove the
> > 40 bytes of ->cb?
>
> I apologize if I wasn't clear, the tag list would go in a new
> skb->tags field replacing the existsing skb->cb array, so the skb
> would lose 40-sizeof(void*) bytes wich seems reasonable to me.
This means for the common TCP case you would actually
need more memory than before - a new pointer and overhead
from the tags. Currently we neither need pointer nor tags
for anything.
Also you would need to complicate alloc_skb to preallocate
this memory and complicate the freeing by checking for it
and freeing it if it was allocated dynamically
(e.g. if a later layer needed it, not the layer that first allocates
it you would need to allocate a new buffer later which would then
need to be freed)
>
> > Linux 2.0 did something like this, but that was removed for good
> > reasons. Now TCP always clones skbs before sending it out.
>
> Do you remember what those reasons were? I couldn't find a related
> discussion in the archives. I think the BSD mbuf tags approach is
> sound enough to justify the move.
>From your description so far it seems to only have disadvantages.
> > And optimizing for uncommon cases (not TCP) doesn't seem too useful.
>
> As pointed out by Bert Hubert, there are people who have heavy traffic
> on non-tcp connections.
It's a small minority compared to TCP users.
-Andi
^ permalink raw reply
* Re: softmac: semantics of SIOCSIWFREQ
From: Ulrich Kunitz @ 2006-04-16 17:17 UTC (permalink / raw)
To: Johannes Berg; +Cc: netdev, softmac-dev, Jean Tourrilhes
In-Reply-To: <1145190888.6560.22.camel@localhost>
On Sun, 16 Apr 2006, Johannes Berg wrote:
> > - If the flag IW_FREQ_FIXED is set, should all activitity
> > including scanning only be allowed on this frequency? (Actually
> > a better would even be to work with channel/frequency sets.
> > These sets would make a lot of sense for parallel scanning
> > whith more than one device.)
>
> Yeah, but that's impossible to code on top of the current wext
> structures I'd say.
I could be done via an iwpriv. Actually the Personal Telco people,
would like to use WLAN devices in parallel to do WAR driving. At
least I would like to support the fixed channel semantics.
> > SIOCSIWFREQ and SIOCGIWFREQ appear to be good candidates to be
> > included in the softmac. If I would have a rough idea, what the
> > semantics should be, I would even volunteer to implement it.
>
> I was thinking of adding all the 'what is this ioctl supposed to do'
> things we came up with to the softmac or netdev wiki. Would that be
> good/useful, or should we just put it into that driver writers guide?
Regarding the wireless extension ioctls, I think the best would be
to add kerneldoc comments.
Uli
--
Ulrich Kunitz - kune@deine-taler.de
^ permalink raw reply
* Re: r8169 locks up in 2.6.16.5
From: Thomas A. Oehser @ 2006-04-16 17:26 UTC (permalink / raw)
To: Francois Romieu; +Cc: Thomas A. Oehser, netdev
In-Reply-To: <20060416144354.GA11433@electric-eye.fr.zoreil.com>
> I'll welcome a complete dmesg after you have recovered through
> ifconfig down/up though.
_Nothing_ on dmesg.
> No problem. One more question: have you enabled NAPI ? If not, you
> should.
Doesn't seem to make a difference. Here, with it on, after failing it:
--- 192.168.99.100 ping statistics ---
1362 packets transmitted, 903 packets received, 33% packet loss
round-trip min/avg/max = 0.1/35803.4/65264.8 ms
Worse than I thought, to a machine on the same gigabit copper switch...
ifconfig eth1:
eth1 Link encap:Ethernet HWaddr 00:E0:4C:13:A9:56
inet addr:192.168.99.99 Bcast:192.168.99.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:528416 errors:252 dropped:620 overruns:0 frame:966
TX packets:243040 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
Interrupt:161 Base address:0xe000
ethtool eth1:
Settings for eth1:
Supported ports: [ TP ]
Supported link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
Supports auto-negotiation: Yes
Advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
Advertised auto-negotiation: Yes
Speed: 1000Mb/s
Duplex: Full
Port: Twisted Pair
PHYAD: 0
Transceiver: internal
Auto-negotiation: on
Supports Wake-on: pumbg
Wake-on: g
Current message level: 0x00000033 (51)
Link detected: yes
Note, without having thrown traffic through it, I have:
PING 192.168.99.100 (192.168.99.100): 56 data bytes
64 bytes from 192.168.99.100: icmp_seq=0 ttl=128 time=0.1 ms
64 bytes from 192.168.99.100: icmp_seq=1 ttl=128 time=0.1 ms
64 bytes from 192.168.99.100: icmp_seq=2 ttl=128 time=0.1 ms
64 bytes from 192.168.99.100: icmp_seq=3 ttl=128 time=0.1 ms
--- 192.168.99.100 ping statistics ---
4 packets transmitted, 4 packets received, 0% packet loss
round-trip min/avg/max = 0.1/0.1/0.1 ms
What next?
-Tom
^ permalink raw reply
* Re: [PATCH-2.6] e1000: fix media_type <-> phy_type thinko
From: Auke Kok @ 2006-04-16 17:48 UTC (permalink / raw)
To: Willy TARREAU; +Cc: jesse.brandeburg, netdev, linux-kernel, rol
In-Reply-To: <20060415110025.GA6266@w.ods.org>
Willy TARREAU wrote:
> Recent patch cb764326dff0ee51aca0d450e1a292de65661055 introduced
> a thinko in e1000_main.c : e1000_media_type_copper is compared
> to hw.phy_type instead of hw.media_type. Original patch proposed
> by Jesse Brandeburg was correct, but what has been merged is not.
Indeed this seems like a mistake to me. I'll make sure this is checked
tomorrow with Jeff Kirsher who submitted the original patch.
Auke Kok
> ---
>
> drivers/net/e1000/e1000_main.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> 3df8a180d50c89a72c28abf37151e38ffda75f39
> diff --git a/drivers/net/e1000/e1000_main.c b/drivers/net/e1000/e1000_main.c
> index add8dc4..590a456 100644
> --- a/drivers/net/e1000/e1000_main.c
> +++ b/drivers/net/e1000/e1000_main.c
> @@ -4156,7 +4156,7 @@ e1000_mii_ioctl(struct net_device *netde
> spin_unlock_irqrestore(&adapter->stats_lock, flags);
> return -EIO;
> }
> - if (adapter->hw.phy_type == e1000_media_type_copper) {
> + if (adapter->hw.media_type == e1000_media_type_copper) {
> switch (data->reg_num) {
> case PHY_CTRL:
> if (mii_reg & MII_CR_POWER_DOWN)
^ permalink raw reply
* Re: [RFC: 2.6 patch] net/irda/irias_object.c: remove unused exports
From: Arjan van de Ven @ 2006-04-16 17:46 UTC (permalink / raw)
To: jt; +Cc: Adrian Bunk, Samuel.Ortiz, netdev, linux-kernel
In-Reply-To: <20060414164203.GA24146@bougret.hpl.hp.com>
> Personally, I don't see what this patch buy us...
all the unused exports in the kernel together make a binary kernel 100Kb
bigger. It's a case of a lot of little steps I suppose (each export
taking like 100 to 150 bytes depending on the size of the function name)
^ permalink raw reply
* Re: [RFC: 2.6 patch] net/irda/irias_object.c: remove unused exports
From: Alan Cox @ 2006-04-16 18:37 UTC (permalink / raw)
To: Arjan van de Ven; +Cc: jt, Adrian Bunk, Samuel.Ortiz, netdev, linux-kernel
In-Reply-To: <1145209616.3809.14.camel@laptopd505.fenrus.org>
On Sul, 2006-04-16 at 19:46 +0200, Arjan van de Ven wrote:
> > Personally, I don't see what this patch buy us...
>
> all the unused exports in the kernel together make a binary kernel 100Kb
> bigger. It's a case of a lot of little steps I suppose (each export
> taking like 100 to 150 bytes depending on the size of the function name)
So why are exports taking us 100-150 bytes, not say 20 which is what I'd
expect ?
^ permalink raw reply
* Re: [RFC: 2.6 patch] net/irda/irias_object.c: remove unused exports
From: Arjan van de Ven @ 2006-04-16 19:07 UTC (permalink / raw)
To: Alan Cox; +Cc: jt, Adrian Bunk, Samuel.Ortiz, netdev, linux-kernel
In-Reply-To: <1145212639.5656.3.camel@localhost.localdomain>
On Sun, 2006-04-16 at 19:37 +0100, Alan Cox wrote:
> On Sul, 2006-04-16 at 19:46 +0200, Arjan van de Ven wrote:
> > > Personally, I don't see what this patch buy us...
> >
> > all the unused exports in the kernel together make a binary kernel 100Kb
> > bigger. It's a case of a lot of little steps I suppose (each export
> > taking like 100 to 150 bytes depending on the size of the function name)
>
>
> So why are exports taking us 100-150 bytes, not say 20 which is what I'd
> expect ?
there is the name, the crc, the address, a module name thingy (which I
think is only filled for non-built-in symbols) and I'm sure there's some
padding here and there...
About 1/3rd of all exports is unused, so killing those is an easy way to
gain back the space...
^ permalink raw reply
* Re: r8169 locks up in 2.6.16.5
From: Francois Romieu @ 2006-04-16 19:53 UTC (permalink / raw)
To: Thomas A. Oehser; +Cc: netdev
In-Reply-To: <20060416172639.GA12243@jupiter.toms.net>
Thomas A. Oehser <tom@toms.net> :
[...]
> > I'll welcome a complete dmesg after you have recovered through
> > ifconfig down/up though.
>
> _Nothing_ on dmesg.
Huh... Nothing appears when you issue 'dmesg' ?
[...]
> eth1 Link encap:Ethernet HWaddr 00:E0:4C:13:A9:56
> inet addr:192.168.99.99 Bcast:192.168.99.255 Mask:255.255.255.0
> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
> RX packets:528416 errors:252 dropped:620 overruns:0 frame:966
> TX packets:243040 errors:0 dropped:0 overruns:0 carrier:0
> collisions:0 txqueuelen:1000
> Interrupt:161 Base address:0xe000
How much long was the card under load ? A few seconds ?
The same 1500 bytes mtu is used everywhere and the issue can not be
reproduced with a simple ping -f -q -l 64 -s what_you_want aimed at
the 8169, right ?
[...]
> What next?
ethtool -d/-S before and after failure, .config and /proc/interrupts.
--
Ueimor
^ permalink raw reply
* how to do probabilistic packet loss in kernel?
From: George P Nychis @ 2006-04-16 22:44 UTC (permalink / raw)
To: lartc, netdev
Hi,
I am using iproute2 to setup fowarding, adding routes like "ip route add 192.168.1.3 via 192.168.1.2"
I was wondering where in the kernel I can insert probabilistic packet loss only for forwarded packets? So that for instance I can drop 5% of all forwarded packets?
I don't need help with the actual code, just need help finding where to insert this code :)
Thanks!
George
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox