Re: [patch] ipv4: initialize arp_tbl rw lock
Ok, so the problem seems to be that inet_init gets called after qeth_init. Looking at the top level Makefile this seems to be true for all network drivers in drivers/net/ and drivers/s390/net/ since we have vmlinux-main := $(core-y) $(libs-y) $(drivers-y) $(net-y) The patch below works for me... I guess there must be a better way to make sure that any networking driver's initcall is made before inet_init? Signed-off-by: Heiko Carstens [EMAIL PROTECTED] We could make inet_init() a subsystem init but I vaguely recall that we were doing that at one point and it broke things for some reason. Perhaps fs_initcall() would work better. Or if that causes problems we could create a net_initcall() that sits between fs_initcall() and device_initcall(). Or any other ideas? Tried to figure out what is causing the delays I experienced when I replaced module_init() in af_inet.c with fs_initcall(). After all it turned out that synchronize_net() which is basicically nothing else than synchronize_rcu() sometimes takes several seconds to complete?! No idea why that is... callchain: inet_init() - inet_register_protosw() - synchronize_net() - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch] ipv4: initialize arp_tbl rw lock
From: Heiko Carstens [EMAIL PROTECTED] Date: Sat, 15 Apr 2006 09:27:45 +0200 Tried to figure out what is causing the delays I experienced when I replaced module_init() in af_inet.c with fs_initcall(). After all it turned out that synchronize_net() which is basicically nothing else than synchronize_rcu() sometimes takes several seconds to complete?! No idea why that is... 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. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: fixing sk_stream_rfree()
From: David S. Miller [EMAIL PROTECTED] Date: Fri, 14 Apr 2006 20:59:27 -0700 (PDT) Any ideas? Come to think of it, __sk_stream_mem_reclaim() looks really racey even as-is. I came up with one more possible approach, it goes something like this: 1) Get rid of the skb-destructor callback for TCP receive data. 2) Adjust sk_rmem_alloc and sk_forward_alloc explicitly when we add packets to sk_receive_queue/out_of_order_queue, and when we unlink them from sk_receive_queue and __kfree_skb() them up. I think this would work and get rid of the unlocked accesses to sk_forward_alloc. And it would do so without adding new overheads (the other two ideas did, by adding locks or turning sk_forward_alloc into an atomic_t). The implementation needs a bit of thinking in order to not mess up all the nice abstractions Arnaldo has created for stream sockets and the interfaces we share between TCP and DCCP. But actually DCCP needs this fix too, since it also uses sk_forward_alloc, so building the solution into the shared interfaces is desirable. Too bad this will take a little bit of time to implement, I really want to be able to cook up a much simpler test patch that the people who can reproduce the BUG() can try out. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: fixing sk_stream_rfree()
From: David S. Miller [EMAIL PROTECTED]
Date: Sat, 15 Apr 2006 01:23:27 -0700 (PDT)
I came up with one more possible approach, it goes something like
this:
1) Get rid of the skb-destructor callback for TCP receive
data.
2) Adjust sk_rmem_alloc and sk_forward_alloc explicitly when we add
packets to sk_receive_queue/out_of_order_queue, and when we unlink
them from sk_receive_queue and __kfree_skb() them up.
It turns out DCCP doesn't use the sk_forward_alloc memory
scheduling at least not for receive.
So, as food for thought, below is a comile-tested-only
implementation of the above idea. The basic transformations
are:
1) sk_eat_skb -- sk_stream_eat_skb which does the sk_forward_alloc
et al. accounting by hand which would have been done by the
skb-destructor sk_stream_rfree()
2) __skb_queue_purge -- sk_stream_eat_queue
3) sk_stream_set_owner_r -- sk_stream_charge_r which does
the accounting for a new receive skb but does not hook up
the destructor
4) unlink and free SKB not received to userspace yet --
sk_stream_eat_skb()
... and then I noticed that ip_rcv() unshares the SKB, so
skb-users should always be 1 and therefore it is impossible
for sk_stream_rfree() to be called from a non socket locked
context.
And all of this was a wild goose chase, oh well :-)
So the BUG_ON(!sk_forward_alloc) problem is elsewhere. :-/
diff --git a/arch/x86_64/kernel/functionlist b/arch/x86_64/kernel/functionlist
index 2bcebdc..da3379a 100644
--- a/arch/x86_64/kernel/functionlist
+++ b/arch/x86_64/kernel/functionlist
@@ -751,7 +751,6 @@
*(.text.strcmp)
*(.text.steal_locks)
*(.text.sock_create)
-*(.text.sk_stream_rfree)
*(.text.sk_stream_mem_schedule)
*(.text.skip_atoi)
*(.text.sk_alloc)
diff --git a/include/net/sock.h b/include/net/sock.h
index af2b054..54d5a2f 100644
--- a/include/net/sock.h
+++ b/include/net/sock.h
@@ -442,14 +442,56 @@ static inline int sk_stream_memory_free(
return sk-sk_wmem_queued sk-sk_sndbuf;
}
-extern void sk_stream_rfree(struct sk_buff *skb);
-
-static inline void sk_stream_set_owner_r(struct sk_buff *skb, struct sock *sk)
+/* Charge SKB as receive queue memory to SK. The socket must be locked
+ * when we get here.
+ */
+static inline void sk_stream_charge_r(struct sk_buff *skb, struct sock *sk)
{
- skb-sk = sk;
- skb-destructor = sk_stream_rfree;
atomic_add(skb-truesize, sk-sk_rmem_alloc);
sk-sk_forward_alloc -= skb-truesize;
+}
+
+/* Release SKB as receive queue memory from SK. The socket must be
+ * locked when we get here.
+ */
+static inline void sk_stream_release_r(struct sk_buff *skb, struct sock *sk)
+{
+ atomic_sub(skb-truesize, sk-sk_rmem_alloc);
+ sk-sk_forward_alloc += skb-truesize;
+}
+
+/**
+ * sk_stream_eat_skb - Release a skb if it is no longer needed
+ * @sk: socket to eat this skb from
+ * @skb: socket buffer to eat
+ * @queue: skb queue to unlink from
+ *
+ * This routine must be called with interrupts disabled or with the socket
+ * locked so that the sk_buff queue operation is ok.
+ */
+static inline void sk_stream_eat_skb(struct sk_buff *skb, struct sock *sk,
struct sk_buff_head *queue)
+{
+ __skb_unlink(skb, queue);
+ sk_stream_release_r(skb, sk);
+ __kfree_skb(skb);
+}
+
+/*
+ * sk_stream_eat_queue - Release an entire queue of skbs, when no longer needed
+ * @sk: socket to eat these skbs from
+ * @queue: queue of skbs to eat
+ *
+ * This routine must be called with interrupts disabled or with the socket
+ * locked so that the sk_buff queue operation is ok.
+ */
+static inline void sk_stream_eat_queue(struct sock *sk, struct sk_buff_head
*queue)
+{
+ struct sk_buff *skb;
+
+ while ((skb = __skb_dequeue(queue)) != NULL) {
+ sk_stream_release_r(skb, sk);
+ __kfree_skb(skb);
+ }
}
static inline void sk_stream_free_skb(struct sock *sk, struct sk_buff *skb)
diff --git a/net/core/stream.c b/net/core/stream.c
index 35e2525..a034f2d 100644
--- a/net/core/stream.c
+++ b/net/core/stream.c
@@ -172,16 +172,6 @@ do_interrupted:
EXPORT_SYMBOL(sk_stream_wait_memory);
-void sk_stream_rfree(struct sk_buff *skb)
-{
- struct sock *sk = skb-sk;
-
- atomic_sub(skb-truesize, sk-sk_rmem_alloc);
- sk-sk_forward_alloc += skb-truesize;
-}
-
-EXPORT_SYMBOL(sk_stream_rfree);
-
int sk_stream_error(struct sock *sk, int flags, int err)
{
if (err == -EPIPE)
diff --git a/net/ipv4/tcp.c b/net/ipv4/tcp.c
index 87f68e7..c45a9c2 100644
--- a/net/ipv4/tcp.c
+++ b/net/ipv4/tcp.c
@@ -1072,11 +1072,11 @@ int tcp_read_sock(struct sock *sk, read_
break;
}
if (skb-h.th-fin) {
- sk_eat_skb(sk, skb);
+ sk_stream_eat_skb(skb, sk, sk-sk_receive_queue);
++seq;
break;
}
- sk_eat_skb(sk, skb);
+ sk_stream_eat_skb(skb, sk,
Re: [RFC: 2.6 patch] net/irda/irias_object.c: remove unused exports
On Fri, 14 Apr 2006, ext Adrian Bunk wrote:
This patch removes the following unused EXPORT_SYMBOL's:
- irias_find_attrib
- irias_new_string_value
- irias_new_octseq_value
Signed-off-by: Adrian Bunk [EMAIL PROTECTED]
Looks good to me.
Signed-off-by: Samuel Ortiz [EMAIL PROTECTED]
---
net/irda/irias_object.c |3 ---
1 file changed, 3 deletions(-)
--- linux-2.6.17-rc1-mm2-full/net/irda/irias_object.c.old 2006-04-14
12:37:49.0 +0200
+++ linux-2.6.17-rc1-mm2-full/net/irda/irias_object.c 2006-04-14
12:39:26.0 +0200
@@ -257,7 +257,6 @@
/* Unsafe (locking), attrib might change */
return attrib;
}
-EXPORT_SYMBOL(irias_find_attrib);
/*
* Function irias_add_attribute (obj, attrib)
@@ -484,7 +483,6 @@
return value;
}
-EXPORT_SYMBOL(irias_new_string_value);
/*
* Function irias_new_octseq_value (octets, len)
@@ -519,7 +517,6 @@
memcpy(value-t.oct_seq, octseq , len);
return value;
}
-EXPORT_SYMBOL(irias_new_octseq_value);
struct ias_value *irias_new_missing_value(void)
{
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC: 2.6 patch] net/irda/irias_object.c: remove unused exports
From: Samuel Ortiz [EMAIL PROTECTED] Date: Sat, 15 Apr 2006 11:58:21 +0300 (EEST) On Fri, 14 Apr 2006, ext Adrian Bunk wrote: This patch removes the following unused EXPORT_SYMBOL's: - irias_find_attrib - irias_new_string_value - irias_new_octseq_value Signed-off-by: Adrian Bunk [EMAIL PROTECTED] Looks good to me. Signed-off-by: Samuel Ortiz [EMAIL PROTECTED] Sam, just add this to your IRDA queue. Ok? - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH-2.6] e1000: fix media_type - phy_type thinko
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.
---
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)
--
1.2.4
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
skb diet
Hi, I just read David S. Miller's skb redundancy page and in it he seems to suggest taking an approach similar to that of BSD's mbufs to reduce the skb's size. I was going to do some janitor work on the network stack and I thought that maybe I could start by adding a tag list to the skb similar to BSD's mbuf tags and change the code to store its private variables in tags rather than in skb-cb. That should save 40 bytes per skb and maybe later the tc and nf related variables could go in tags too. The transition shouldn't be hard for the most part, many users of skb-cb use macros like FRAG_CB(skb) so I could redefine those macros to search the tag-list for the appropriate tag and return its contents. Is this approach acceptable or is there a consensus on another approach? - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Fw: Openswan, iptables (fiaif) and 2.6.16 kernel
Andrew Morton wrote: Begin forwarded message: Date: Fri, 14 Apr 2006 14:32:39 +0200 From: Laurent CARON [EMAIL PROTECTED] To: linux-kernel@vger.kernel.org Subject: Openswan, iptables (fiaif) and 2.6.16 kernel Hi, I'm running an openswan gateway for quite a long time now. I have used 2.4.X and 2.6.X kernels without any problem until i decided to upgrade to 2.6.16 kernel. Summary of problem: Under 2.6.15 everything is fine Under 2.6.16 my tunnels establish well, but i can't even ping a single computer located on the other end of the tunnel when the firewall is up. Disabling the firewall solves the problem (but is not an option for me). $ cat ip_conntrack | grep 192.168.10 icmp 1 8 src=192.168.0.192 dst=192.168.10.1 type=8 code=0 id=793 packets=4 bytes=116 [UNREPLIED] src=192.168.10.1 dst=XXX.XXX.XXX.XXX type=0 code=0 id=793 packets=0 bytes=0 mark=0 use=1 192.168.0.0/24 is my lan subnet (natted so that lan computers can access the internet through the public ip address) 192.168.0.192 is a workstation on my lan 192.168.10.0/24 is the other subnet XXX.XXX.XXX.XXX is my public ip address If i disable the nat of 192.168.0.0/24, i can ping the other end. Re-enabling the nat however disables the ability to ping the other end. Seems iptables is trying to nat packets the wrong way :$, or that I missed a major change in 2.6.16. Do anyone have any clue about this weiredness? Thanks Laurent I have replied to Laurent and to openswan list: http://lists.openswan.org/pipermail/users/2006-April/009070.html - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] sir: switch to a workqueue
On Sat, Apr 15, 2006 at 04:24:15PM +0200, Martin Diehl wrote: My only concern with this patch is this: .. Hm, queue_work might fail (like it was possible with irda_queue_request), if work-pending is set. In that case, chances are we have a partially configured irda device dangling around. The idea was to (re-)enable rx and restore the xmit queue state on netdev so we can rely on the upper layers to recover. I think without the fallback the netdev might become unuseable until ifdown/ifup-cycle, if queue_work would ever fail. queue_work doesn't fail if work-pending, it just noticed this particular work_Struct is already beeing serviced and tells you that. In the sir code that can't happen because the work_struct has ben allocated and initialized a few lines above, so there's zero chance for someone else to call queue_work on it concurrently. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Geographical/regulatory information for ieee80211
On Thu, Apr 13, 2006 at 07:59:21PM -0500, Larry Finger wrote: I am planning on writing a new routine to be added to net/ieee80211/ieee80211_geo.c that will populate an ieee80211_geo object given a country code. The new routine will eliminate the need for each driver to do their own. This sounds like a generally good idea, but the question is: do we want this inside a kernel module or in userspace, either like the regulartory daemon intel has (unfortunately in binary only form) or as a simple init script. I really don't want to recompile my kernel just because regulations changed, and they seems to do that quite often. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH] softmac: (v2) send WEXT assoc/disassoc events to userspace
On Thu, 2006-04-13 at 19:05 -0600, Hans Fugal wrote: With the patch, wpa_supplicant is able to work properly for WEP and plaintext as tested with my bcm4306 (iBook), and the latest git. Thanks, great. I have network-manager up and running too now (finally!) However, and this may not be related, I still must issue an ip link set up eth1 after loading the bcm43xx module but before starting wpa_supplicant or it will not work. Right, that is expected behaviour right now until we come up with how to handle this properly. johannes signature.asc Description: This is a digitally signed message part
Re: [RFC: 2.6 patch] net/irda/irias_object.c: remove unused exports
On Sat, 15 Apr 2006, ext David S. Miller wrote: From: Samuel Ortiz [EMAIL PROTECTED] Date: Sat, 15 Apr 2006 11:58:21 +0300 (EEST) On Fri, 14 Apr 2006, ext Adrian Bunk wrote: This patch removes the following unused EXPORT_SYMBOL's: - irias_find_attrib - irias_new_string_value - irias_new_octseq_value Signed-off-by: Adrian Bunk [EMAIL PROTECTED] Looks good to me. Signed-off-by: Samuel Ortiz [EMAIL PROTECTED] Sam, just add this to your IRDA queue. Ok? Sure, I will. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [NFS] [RFC: 2.6 patch] net/sunrpc/: possible cleanups
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? If not, I'd suggest to remove them and re-add them when code using them will be included in the kernel (reverting parts or all of my patch should be trivial). This way, they'll not continue to uselessly making the kernel image larger. cu Adrian -- Is there not promise of rain? Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. Only a promise, Lao Er said. Pearl S. Buck - Dragon Seed - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch] ipv4: initialize arp_tbl rw lock
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(). - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [NFS] [RFC: 2.6 patch] net/sunrpc/: possible cleanups
On 4/15/06 5:32 PM, Adrian Bunk [EMAIL PROTECTED] 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. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] sungem: Marvell PHY suspend
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 [EMAIL PROTECTED]
CC: Benjamin Herrenschmidt [EMAIL PROTECTED]
--- 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,
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: r8169 locks up in 2.6.16.5
Thomas A. Oehser [EMAIL PROTECTED] :
[...]
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
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] sungem: Marvell PHY suspend
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 [EMAIL PROTECTED] Acked-by: Benjamin Herrenschmidt [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 http://vger.kernel.org/majordomo-info.html
[PATCH][RFC] Security marking
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-netdevm=113027175208707w=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.0
-0400
+++ linux-2.6.17-rc1.w/include/linux/skbuff.h 2006-04-15 23:36:07.0
-0400
@@ -209,6 +209,7 @@ enum {
* @nf_bridge: Saved data about a bridged frame -
Re: [PATCH][RFC] Security marking
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 [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 http://vger.kernel.org/majordomo-info.html
