* Re: [PATCH] ibmtr: fix tr%d in dmesg
From: David Miller @ 2010-10-04 3:56 UTC (permalink / raw)
To: mroos; +Cc: netdev
In-Reply-To: <alpine.SOC.1.00.1010022056000.27121@math.ut.ee>
From: Meelis Roos <mroos@linux.ee>
Date: Sat, 2 Oct 2010 21:35:15 +0300 (EEST)
> ibmtr and ibmtr_cs show tr%d in dmesg after alloc_netdev() but before
> register_netdev(). Fix it like e100 does - put a different name into
> dev->name until the device gets registered. I/O port seems to be unique
> enough and is available for the time of printk messages. With the fix,
> dmesg shows
>
> ibmtr@0a20: ISA P&P 16/4 Adapter/A (short) | 16/4 ISA-16 Adapter found
> ibmtr@0a20: using irq 3, PIOaddr a20, 64K shared RAM.
> ibmtr@0a20: Hardware address : 00:40:aa:a9:03:98
> ibmtr@0a20: Shared RAM paging disabled. ti->page_mask 0
> ibmtr@0a20: Maximum Receive Internet Protocol MTU 16Mbps: 16344, 4Mbps: 6104
> tr0: port 0xa20, irq 3, mmio 0xd4850000, sram 0xd0000, hwaddr=00:40:aa:a9:03:98
>
> Signed-off-by: Meelis Roos <mroos@linux.ee>
That may be how e100 does it, but this is a very ugly hack and
an abuse of netdev->name
Instead, the more correct way to fit this is to use dev_info(),
dev_err(), and friends. It will both print the correct stuff,
and also document the probing path messages that occur before
the net device is registered.
So please correct the prolem that way, thank you.
^ permalink raw reply
* Re: [PATCH 1/2] Revert "ipv4: Make INET_LRO a bool instead of tristate."
From: Ben Hutchings @ 2010-10-04 3:54 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20101003.195618.193723845.davem@davemloft.net>
[-- Attachment #1: Type: text/plain, Size: 942 bytes --]
On Sun, 2010-10-03 at 19:56 -0700, David Miller wrote:
> From: Ben Hutchings <ben@decadent.org.uk>
> Date: Mon, 04 Oct 2010 02:37:42 +0100
>
> > You made the change I want to revert in response to
> > <http://article.gmane.org/gmane.linux.kernel/825646>. The real problem
> > with its configuration is actually that CONFIG_INET is not set but
> > CONFIG_INET_LRO=m, and the fix is to make CONFIG_PASEMI_MAC depend on
> > CONFIG_INET.
>
> Ben, you can't just revert this by itself.
>
> That knowingly breaks the build.
>
> If you want the tristate back, you must do it after or at the
> same time as fixing the driver deps.
The fact that the driver dependencies are broken has nothing to do with
whether CONFIG_INET_LRO is boolean or tristate. You fixed a problem
that didn't exist rather than the problem that did.
Ben.
--
Ben Hutchings
Once a job is fouled up, anything done to improve it makes it worse.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
^ permalink raw reply
* Re: [PATCH] net: Fix the condition passed to sk_wait_event()
From: David Miller @ 2010-10-04 3:42 UTC (permalink / raw)
To: tomer_iisc; +Cc: netdev, linux-kernel
In-Reply-To: <316201.7438.qm@web53706.mail.re2.yahoo.com>
From: Nagendra Tomar <tomer_iisc@yahoo.com>
Date: Sun, 3 Oct 2010 02:45:06 -0700 (PDT)
> This patch fixes the condition (3rd arg) passed to sk_wait_event() in
> sk_stream_wait_memory(). The incorrect check in sk_stream_wait_memory()
> causes the following soft lockup in tcp_sendmsg() when the global tcp
> memory pool has exhausted.
...
> What is happening is, that the sk_wait_event() condition passed from
> sk_stream_wait_memory() evaluates to true for the case of tcp global memory
> exhaustion. This is because both sk_stream_memory_free() and vm_wait are true
> which causes sk_wait_event() to *not* call schedule_timeout().
> Hence sk_stream_wait_memory() returns immediately to the caller w/o sleeping.
> This causes the caller to again try allocation, which again fails and again
> calls sk_stream_wait_memory(), and so on.
>
>
> Signed-off-by: Nagendra Singh Tomar <tomer_iisc@yahoo.com>
Applied, thanks.
This bug was introduced by the following commit, which I made
a note of in the commit message for the fix:
--------------------
commit c1cbe4b7ad0bc4b1d98ea708a3fecb7362aa4088
Author: Benjamin LaHaise <benjamin.c.lahaise@intel.com>
Date: Tue Dec 13 23:22:19 2005 -0800
[NET]: Avoid atomic xchg() for non-error case
It also looks like there were 2 places where the test on sk_err was
missing from the event wait logic (in sk_stream_wait_connect and
sk_stream_wait_memory), while the rest of the sock_error() users look
to be doing the right thing. This version of the patch fixes those,
and cleans up a few places that were testing ->sk_err directly.
Signed-off-by: Benjamin LaHaise <benjamin.c.lahaise@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
diff --git a/include/net/sock.h b/include/net/sock.h
index 982b4ec..0fbae85 100644
--- a/include/net/sock.h
+++ b/include/net/sock.h
@@ -1166,7 +1166,10 @@ static inline int sock_queue_err_skb(struct sock *sk, struct sk_buff *skb)
static inline int sock_error(struct sock *sk)
{
- int err = xchg(&sk->sk_err, 0);
+ int err;
+ if (likely(!sk->sk_err))
+ return 0;
+ err = xchg(&sk->sk_err, 0);
return -err;
}
diff --git a/net/bluetooth/af_bluetooth.c b/net/bluetooth/af_bluetooth.c
index ea616e3..fb031fe 100644
--- a/net/bluetooth/af_bluetooth.c
+++ b/net/bluetooth/af_bluetooth.c
@@ -287,10 +287,9 @@ int bt_sock_wait_state(struct sock *sk, int state, unsigned long timeo)
timeo = schedule_timeout(timeo);
lock_sock(sk);
- if (sk->sk_err) {
- err = sock_error(sk);
+ err = sock_error(sk);
+ if (err)
break;
- }
}
set_current_state(TASK_RUNNING);
remove_wait_queue(sk->sk_sleep, &wait);
diff --git a/net/bluetooth/l2cap.c b/net/bluetooth/l2cap.c
index e3bb11c..95f33cc 100644
--- a/net/bluetooth/l2cap.c
+++ b/net/bluetooth/l2cap.c
@@ -767,8 +767,9 @@ static int l2cap_sock_sendmsg(struct kiocb *iocb, struct socket *sock, struct ms
BT_DBG("sock %p, sk %p", sock, sk);
- if (sk->sk_err)
- return sock_error(sk);
+ err = sock_error(sk);
+ if (err)
+ return err;
if (msg->msg_flags & MSG_OOB)
return -EOPNOTSUPP;
diff --git a/net/bluetooth/sco.c b/net/bluetooth/sco.c
index 9cb00dc..6481814 100644
--- a/net/bluetooth/sco.c
+++ b/net/bluetooth/sco.c
@@ -637,8 +637,9 @@ static int sco_sock_sendmsg(struct kiocb *iocb, struct socket *sock,
BT_DBG("sock %p, sk %p", sock, sk);
- if (sk->sk_err)
- return sock_error(sk);
+ err = sock_error(sk);
+ if (err)
+ return err;
if (msg->msg_flags & MSG_OOB)
return -EOPNOTSUPP;
diff --git a/net/core/stream.c b/net/core/stream.c
index 15bfd03..35e2525 100644
--- a/net/core/stream.c
+++ b/net/core/stream.c
@@ -55,8 +55,9 @@ int sk_stream_wait_connect(struct sock *sk, long *timeo_p)
int done;
do {
- if (sk->sk_err)
- return sock_error(sk);
+ int err = sock_error(sk);
+ if (err)
+ return err;
if ((1 << sk->sk_state) & ~(TCPF_SYN_SENT | TCPF_SYN_RECV))
return -EPIPE;
if (!*timeo_p)
@@ -67,6 +68,7 @@ int sk_stream_wait_connect(struct sock *sk, long *timeo_p)
prepare_to_wait(sk->sk_sleep, &wait, TASK_INTERRUPTIBLE);
sk->sk_write_pending++;
done = sk_wait_event(sk, timeo_p,
+ !sk->sk_err &&
!((1 << sk->sk_state) &
~(TCPF_ESTABLISHED | TCPF_CLOSE_WAIT)));
finish_wait(sk->sk_sleep, &wait);
@@ -137,7 +139,9 @@ int sk_stream_wait_memory(struct sock *sk, long *timeo_p)
set_bit(SOCK_NOSPACE, &sk->sk_socket->flags);
sk->sk_write_pending++;
- sk_wait_event(sk, ¤t_timeo, sk_stream_memory_free(sk) &&
+ sk_wait_event(sk, ¤t_timeo, !sk->sk_err &&
+ !(sk->sk_shutdown & SEND_SHUTDOWN) &&
+ sk_stream_memory_free(sk) &&
vm_wait);
sk->sk_write_pending--;
diff --git a/net/irda/af_irda.c b/net/irda/af_irda.c
index 6f92f9c..f121f7d 100644
--- a/net/irda/af_irda.c
+++ b/net/irda/af_irda.c
@@ -1438,8 +1438,9 @@ static int irda_recvmsg_stream(struct kiocb *iocb, struct socket *sock,
/*
* POSIX 1003.1g mandates this order.
*/
- if (sk->sk_err)
- ret = sock_error(sk);
+ ret = sock_error(sk);
+ if (ret)
+ break;
else if (sk->sk_shutdown & RCV_SHUTDOWN)
;
else if (noblock)
diff --git a/net/llc/af_llc.c b/net/llc/af_llc.c
index c3f0b07..b6d3df5 100644
--- a/net/llc/af_llc.c
+++ b/net/llc/af_llc.c
@@ -566,10 +566,9 @@ static int llc_wait_data(struct sock *sk, long timeo)
/*
* POSIX 1003.1g mandates this order.
*/
- if (sk->sk_err) {
- rc = sock_error(sk);
+ rc = sock_error(sk);
+ if (rc)
break;
- }
rc = 0;
if (sk->sk_shutdown & RCV_SHUTDOWN)
break;
^ permalink raw reply related
* Re: [PATCH] sysctl: fix min/max handling in __do_proc_doulongvec_minmax()
From: Américo Wang @ 2010-10-04 3:09 UTC (permalink / raw)
To: Eric Dumazet
Cc: Andrew Morton, linux-kernel, Robin Holt, Willy Tarreau,
David S. Miller, netdev, James Morris, Hideaki YOSHIFUJI,
Pekka Savola (ipv6), Patrick McHardy, Alexey Kuznetsov
In-Reply-To: <1286025469.2582.1806.camel@edumazet-laptop>
On Sat, Oct 02, 2010 at 03:17:49PM +0200, Eric Dumazet wrote:
>When proc_doulongvec_minmax() is used with an array of longs,
>and no min/max check requested (.extra1 or .extra2 being NULL), we
>dereference a NULL pointer for the second element of the array.
>
>Noticed while doing some changes in network stack for the "16TB problem"
>
>Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
>---
> kernel/sysctl.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
>diff --git a/kernel/sysctl.c b/kernel/sysctl.c
>index f88552c..4fba86d 100644
>--- a/kernel/sysctl.c
>+++ b/kernel/sysctl.c
>@@ -2500,7 +2500,8 @@ static int __do_proc_doulongvec_minmax(void *data, struct ctl_table *table, int
> break;
> if (neg)
> continue;
>- if ((min && val < *min) || (max && val > *max))
>+ if ((table->extra1 && val < *min) ||
>+ (table->extra2 && val > *max))
> continue;
Yes? This is wrong for me, min and max are pointers to ->extra{1,2},
they are increased within the for loop, you are only checking the
the pointer to the first element of ->extra{1,2}.
^ permalink raw reply
* Re: [PATCH] tms380tr: fix long delays in initialization
From: David Miller @ 2010-10-04 3:01 UTC (permalink / raw)
To: mroos; +Cc: netdev
In-Reply-To: <alpine.SOC.1.00.1010032228450.28867@math.ut.ee>
From: Meelis Roos <mroos@linux.ee>
Date: Sun, 3 Oct 2010 22:34:30 +0300 (EEST)
> tms380tr driver tries to use udelay (meaning busy loop) for several half
> second delays during hardware initialization. Crazy overly long busy
> wait delays mean no delay at all so driver initialization fails without
> waiting. Fix it by using msleep() for long delays and leave it to
> udelay() for short delays.
>
> Signed-off-by: Meelis Roos <mroos@linux.ee>
You can't use msleep() here because this code can be invoked
from interrupts and thus cannot sleep.
^ permalink raw reply
* Re: [PATCH 1/2] Revert "ipv4: Make INET_LRO a bool instead of tristate."
From: David Miller @ 2010-10-04 2:56 UTC (permalink / raw)
To: ben; +Cc: netdev
In-Reply-To: <1286156262.3916.213.camel@localhost>
From: Ben Hutchings <ben@decadent.org.uk>
Date: Mon, 04 Oct 2010 02:37:42 +0100
> You made the change I want to revert in response to
> <http://article.gmane.org/gmane.linux.kernel/825646>. The real problem
> with its configuration is actually that CONFIG_INET is not set but
> CONFIG_INET_LRO=m, and the fix is to make CONFIG_PASEMI_MAC depend on
> CONFIG_INET.
Ben, you can't just revert this by itself.
That knowingly breaks the build.
If you want the tristate back, you must do it after or at the
same time as fixing the driver deps.
Thanks.
^ permalink raw reply
* [PATCH 2/2] netdev: Depend on INET before selecting INET_LRO
From: Ben Hutchings @ 2010-10-04 1:42 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Subrata Modak, Lennert Buytenhek, Olof Johansson
In-Reply-To: <1286156262.3916.213.camel@localhost>
Since 'select' ignores dependencies, drivers that select INET_LRO must
depend on INET. This fixes the broken configuration reported in
<http://article.gmane.org/gmane.linux.kernel/825646>.
Reported-by: Subrata Modak <subrata@linux.vnet.ibm.com>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
---
drivers/net/Kconfig | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index ef683a9..13d01f3 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -2428,7 +2428,7 @@ config UGETH_TX_ON_DEMAND
config MV643XX_ETH
tristate "Marvell Discovery (643XX) and Orion ethernet support"
- depends on MV64X60 || PPC32 || PLAT_ORION
+ depends on (MV64X60 || PPC32 || PLAT_ORION) && INET
select INET_LRO
select PHYLIB
help
@@ -2815,7 +2815,7 @@ config NIU
config PASEMI_MAC
tristate "PA Semi 1/10Gbit MAC"
- depends on PPC_PASEMI && PCI
+ depends on PPC_PASEMI && PCI && INET
select PHYLIB
select INET_LRO
help
--
1.7.1
^ permalink raw reply related
* [PATCH 1/2] Revert "ipv4: Make INET_LRO a bool instead of tristate."
From: Ben Hutchings @ 2010-10-04 1:37 UTC (permalink / raw)
To: David Miller; +Cc: netdev
This reverts commit e81963b180ac502fda0326edf059b1e29cdef1a2.
LRO is now deprecated in favour of GRO, and only a few drivers use it,
so it is desirable to build it as a module in distribution kernels.
The original change to prevent building it as a module was made in an
attempt to avoid the case where some dependents are set to y and some
to m, and INET_LRO can be set to m rather than y. However, the
Kconfig system will reliably set INET_LRO=y in this case.
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
---
Dave,
You made the change I want to revert in response to
<http://article.gmane.org/gmane.linux.kernel/825646>. The real problem
with its configuration is actually that CONFIG_INET is not set but
CONFIG_INET_LRO=m, and the fix is to make CONFIG_PASEMI_MAC depend on
CONFIG_INET.
Ben.
net/ipv4/Kconfig | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/net/ipv4/Kconfig b/net/ipv4/Kconfig
index 94e0b51..704a0cf 100644
--- a/net/ipv4/Kconfig
+++ b/net/ipv4/Kconfig
@@ -420,7 +420,7 @@ config INET_XFRM_MODE_BEET
If unsure, say Y.
config INET_LRO
- bool "Large Receive Offload (ipv4/tcp)"
+ tristate "Large Receive Offload (ipv4/tcp)"
default y
---help---
Support for Large Receive Offload (ipv4/tcp).
--
1.7.1
^ permalink raw reply related
* Re: [PATCH] net: Fix IPv6 PMTU disc. w/ asymmetric routes
From: Maciej Żenczykowski @ 2010-10-04 0:21 UTC (permalink / raw)
To: David Miller; +Cc: netdev, yoshfuji
In-Reply-To: <20101003.144931.71122620.davem@davemloft.net>
> Ok, meanwhile I did the research.
>
> What ipv6 does is that when you lookup a route, it clones or copies
> the prefixes route into one that is fully specified for a specific
> SADDR/DADDR pair, and then inserts that specific route into the FIB6
> tree.
>
> Therefore the only cases we should lookup for PMTU discovery for ipv6
> are:
>
> { daddr, saddr, ifindex == 0 }
> { daddr, saddr, ifindex == dev->ifindex }
>
> This achieves the same effect as what ipv4 is doing.
>
> So Maciej your original attempt was correct all along, and as a result
> I'll commit the following.
>
> Thanks!
Awesome. I've been trying to convince myself of this and come up with
a concise explanation - but it sounds like you got there first.
[I ran into SUBTREES and got stuck in trying to understand exactly how
they work and whether they affect this at all.]
^ permalink raw reply
* Hello
From: Mrs. Zeng Q. Zhen @ 2010-10-03 20:56 UTC (permalink / raw)
Compliment of the day,
I am Mrs. Zeng Q. Zhen, a staff of lloyds Group Plc. here in Hong Kong
attached with Private Banking Services; I have a secured business proposal
for you. Should you be interested please reach me on my private email address
(mrszengqzhene53@gmail.com) And after that I shall provide you with more
details of my proposal. Your earliest response to this letter will be
appreciated.
Yours Sincerely,
Zeng Q.Zhen
^ permalink raw reply
* Re: [PATCH] net: Fix IPv6 PMTU disc. w/ asymmetric routes
From: David Miller @ 2010-10-03 21:49 UTC (permalink / raw)
To: zenczykowski; +Cc: netdev, yoshfuji
In-Reply-To: <20100930.004136.91329579.davem@davemloft.net>
From: David Miller <davem@davemloft.net>
Date: Thu, 30 Sep 2010 00:41:36 -0700 (PDT)
> Maybe the problem is that the ipv6 side uses the same saddr for both
> the lookup and the entry comparison in these PMTU code paths? Does it
> not allow specifying them seperately as the ipv4 PMTU (and incidently
> the RT redirect) code paths do?
>
> Or is this not an issue on the ipv6 side for some reason?
Ok, meanwhile I did the research.
What ipv6 does is that when you lookup a route, it clones or copies
the prefixes route into one that is fully specified for a specific
SADDR/DADDR pair, and then inserts that specific route into the FIB6
tree.
Therefore the only cases we should lookup for PMTU discovery for ipv6
are:
{ daddr, saddr, ifindex == 0 }
{ daddr, saddr, ifindex == dev->ifindex }
This achieves the same effect as what ipv4 is doing.
So Maciej your original attempt was correct all along, and as a result
I'll commit the following.
Thanks!
--------------------
net: Fix IPv6 PMTU disc. w/ asymmetric routes
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
---
net/ipv6/route.c | 28 ++++++++++++++++++++++++----
1 files changed, 24 insertions(+), 4 deletions(-)
diff --git a/net/ipv6/route.c b/net/ipv6/route.c
index 8323136..a275c6e 100644
--- a/net/ipv6/route.c
+++ b/net/ipv6/route.c
@@ -1556,14 +1556,13 @@ out:
* i.e. Path MTU discovery
*/
-void rt6_pmtu_discovery(struct in6_addr *daddr, struct in6_addr *saddr,
- struct net_device *dev, u32 pmtu)
+static void rt6_do_pmtu_disc(struct in6_addr *daddr, struct in6_addr *saddr,
+ struct net *net, u32 pmtu, int ifindex)
{
struct rt6_info *rt, *nrt;
- struct net *net = dev_net(dev);
int allfrag = 0;
- rt = rt6_lookup(net, daddr, saddr, dev->ifindex, 0);
+ rt = rt6_lookup(net, daddr, saddr, ifindex, 0);
if (rt == NULL)
return;
@@ -1631,6 +1630,27 @@ out:
dst_release(&rt->dst);
}
+void rt6_pmtu_discovery(struct in6_addr *daddr, struct in6_addr *saddr,
+ struct net_device *dev, u32 pmtu)
+{
+ struct net *net = dev_net(dev);
+
+ /*
+ * RFC 1981 states that a node "MUST reduce the size of the packets it
+ * is sending along the path" that caused the Packet Too Big message.
+ * Since it's not possible in the general case to determine which
+ * interface was used to send the original packet, we update the MTU
+ * on the interface that will be used to send future packets. We also
+ * update the MTU on the interface that received the Packet Too Big in
+ * case the original packet was forced out that interface with
+ * SO_BINDTODEVICE or similar. This is the next best thing to the
+ * correct behaviour, which would be to update the MTU on all
+ * interfaces.
+ */
+ rt6_do_pmtu_disc(daddr, saddr, net, pmtu, 0);
+ rt6_do_pmtu_disc(daddr, saddr, net, pmtu, dev->ifindex);
+}
+
/*
* Misc support functions
*/
--
1.7.3.1
^ permalink raw reply related
* 2.6.36-rc6-git2: Reported regressions 2.6.34 -> 2.6.35
From: Rafael J. Wysocki @ 2010-10-03 21:36 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Maciej Rutecki, Florian Mickler, Andrew Morton, Linus Torvalds,
Kernel Testers List, Network Development, Linux ACPI,
Linux PM List, Linux SCSI List, Linux Wireless List, DRI
This message contains a list of some post-2.6.34 regressions introduced before
2.6.35, for which there are no fixes in the mainline known to the tracking team.
If any of them have been fixed already, please let us know.
If you know of any other unresolved post-2.6.34 regressions, please let us know
either and we'll add them to the list. Also, please let us know if any
of the entries below are invalid.
Each entry from the list will be sent additionally in an automatic reply to
this message with CCs to the people involved in reporting and handling the
issue.
Listed regressions statistics:
Date Total Pending Unresolved
----------------------------------------
2010-10-03 141 21 17
2010-09-26 139 24 21
2010-09-20 137 27 25
2010-09-12 135 26 25
2010-08-30 124 38 34
2010-08-01 100 27 23
2010-07-23 94 33 25
2010-07-09 79 45 37
2010-06-21 46 37 26
2010-06-09 15 13 10
Unresolved regressions
----------------------
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=19612
Subject : Computer fails to hibernate - problem idling SMP CPU's
Submitter : <tempo444z-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date : 2010-10-02 22:26 (2 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=19302
Subject : PROBLEM: kernel crash on USB-modem (Huawei E1750) hangup.
Submitter : O01eg <O01eg-o+MxOtu4lMCHXe+LvDLADg@public.gmane.org>
Date : 2010-09-26 19:50 (8 days old)
Message-ID : <op.vjnn1up1yohvy1@localhost>
References : http://marc.info/?l=linux-kernel&m=128553111709569&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=18522
Subject : cdrom drive doesn't detect removal
Submitter : Maxim Levitsky <maximlevitsky-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date : 2010-09-12 9:49 (22 days old)
First-Bad-Commit: http://git.kernel.org/linus/6b4517a7913a09d3259bb1d21c9cb300f12294bd
Message-ID : <1284284969.2928.18.camel@maxim-laptop>
References : http://marc.info/?l=linux-kernel&m=128428499013930&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=17812
Subject : Kernel completely frozen when memory is full
Submitter : Mickey86 <mikael.cordon-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date : 2010-09-05 13:09 (29 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=17261
Subject : Freezes on bootup
Submitter : Dan Dart <dandart-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org>
Date : 2010-08-29 09:00 (36 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16891
Subject : Kernel panic while loading intel module during boot
Submitter : Anisse Astier <anisse-fwwRqrJYcP2HXe+LvDLADg@public.gmane.org>
Date : 2010-08-24 13:19 (41 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16691
Subject : IPW5100: iwlagn broken with 2.6.34.x to 2.6.35.2 update
Submitter : Can Celasun <dcelasun-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date : 2010-08-21 08:28 (44 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16614
Subject : [2.6.35] usb 2.0 em28xx kernel panic general protection fault: 0000 [#1] SMP RIP: 0010:[<ffffffffa004fbc5>] [<ffffffffa004fbc5>] em28xx_isoc_copy_vbi+0x62e/0x812 [em28xx]
Submitter : Sander Eikelenboom <linux-6SM94LqRVpn6gRhOQ7JHfg@public.gmane.org>
Date : 2010-08-10 22:12 (55 days old)
Message-ID : <61936849.20100811001257-6SM94LqRVpn6gRhOQ7JHfg@public.gmane.org>
References : http://marc.info/?l=linux-kernel&m=128152075830927&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16562
Subject : 2.6.35: cpu_idle bug report / on i7 870 cpu (x86_64)
Submitter : Justin Piszcz <jpiszcz-BP4nVm5VUdNhbmWW9KSYcQ@public.gmane.org>
Date : 2010-08-06 22:09 (59 days old)
Message-ID : <alpine.DEB.2.00.1008061800530.5241-0qmrozcXWo8bm2hyYBkBBg@public.gmane.org>
References : http://marc.info/?l=linux-kernel&m=128113260904048&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16549
Subject : 2.6.35: suspicious rcu_dereference_check() usage
Submitter : Vladislav Bolkhovitin <vst-d+Crzxg7Rs0@public.gmane.org>
Date : 2010-08-04 10:56 (61 days old)
Message-ID : <4C594740.1090608-d+Crzxg7Rs0@public.gmane.org>
References : http://marc.info/?l=linux-kernel&m=128091938215177&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16525
Subject : unexpected high load since 2.6.35
Submitter : MadLoisae-hi6Y0CQ0nG0@public.gmane.org <MadLoisae-hi6Y0CQ0nG0@public.gmane.org>
Date : 2010-08-02 20:53 (63 days old)
Message-ID : <4C573041.1070103-hi6Y0CQ0nG0@public.gmane.org>
References : http://marc.info/?l=linux-kernel&m=128078243726655&w=2
http://lkml.org/lkml/2010/9/14/105
http://lkml.org/lkml/2010/9/27/328
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16515
Subject : [bisected] Radeon rv280 can't boot on kernel 2.6.35.
Submitter : Albert Gall <ss3vdr-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date : 2010-08-04 16:10 (61 days old)
First-Bad-Commit: http://git.kernel.org/linus/https://bugzilla.kernel.org/attachment.cgi?id=27350
Handled-By : Alex Deucher <alexdeucher-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16488
Subject : [i915] Framebuffer ID error after suspend/hibernate leading to X crash
Submitter : Milan Bouchet-Valat <nalimilan-pqIVbhRXszc@public.gmane.org>
Date : 2010-08-01 08:55 (64 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16458
Subject : Bluetooth disabled after resume
Submitter : AttilaN <attila123456-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date : 2010-07-25 09:33 (71 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16380
Subject : Loop devices act strangely in 2.6.35
Submitter : Artem S. Tashkinov <t.artem-VInPYn6yXxRWk0Htik3J/w@public.gmane.org>
Date : 2010-07-13 23:21 (83 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16265
Subject : Why is kslowd accumulating so much CPU time?
Submitter : Theodore Ts'o <tytso-3s7WtUTddSA@public.gmane.org>
Date : 2010-06-09 18:36 (117 days old)
First-Bad-Commit: http://git.kernel.org/linus/fbf81762e385d3d45acad057b654d56972acf58c
Message-ID : <E1OMQ88-0002a1-Gb-UK71uKi2zisAobODsErMgNi2O/JbrIOy@public.gmane.org>
References : http://marc.info/?l=linux-kernel&m=127610857819033&w=4
http://bugs.freedesktop.org/show_bug.cgi?id=29536
Handled-By : Chris Wilson <chris-Y6uKTt2uX1cEflXRtASbqLVCufUGDwFn@public.gmane.org>
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16221
Subject : 2.6.35-rc2-git5 -- [drm:drm_mode_getfb] *ERROR* invalid framebuffer id
Submitter : Miles Lane <miles.lane-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date : 2010-06-11 20:31 (115 days old)
Message-ID : <AANLkTim0jVRyqkwlGOcrg_XTvUQwcBYfWJX-aRzkkrLG-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
References : http://marc.info/?l=linux-kernel&m=127628828119623&w=2
Regressions with patches
------------------------
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=17772
Subject : Unable to locate IOAPIC for GSI *
Submitter : zersaa <zersaa-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date : 2010-09-04 21:28 (30 days old)
Handled-By : Eric W. Biederman <ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
Patch : https://patchwork.kernel.org/patch/104501/
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16462
Subject : unable to connect to hidden SSID AP on legal channel 13
Submitter : Daniel J Blueman <daniel.blueman-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date : 2010-07-25 17:06 (71 days old)
Handled-By : Johannes Berg <johannes.berg-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
Patch : https://bugzilla.kernel.org/attachment.cgi?id=31862
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16312
Subject : WARNING: at fs/fs-writeback.c:1127 __mark_inode_dirty
Submitter : Zdenek Kabelac <zdenek.kabelac-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date : 2010-06-28 9:40 (98 days old)
Message-ID : <AANLkTin24fr5O4_q5Xbo9Y_NKkEmtcp6Hgmr9_4qXaFz-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
References : http://marc.info/?l=linux-kernel&m=127771804806465&w=2
http://lkml.indiana.edu/hypermail/linux/kernel/1007.3/00884.html
Handled-By : Jan Kara <jack-AlSwsSmVLrQ@public.gmane.org>
Jan Kara <jack-AlSwsSmVLrQ@public.gmane.org>
Patch : https://bugzilla.kernel.org/attachment.cgi?id=30282
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16228
Subject : BUG/boot failure on Dell Precision T3500 (pci/ahci_stop_engine)
Submitter : Brian Bloniarz <brian.bloniarz-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date : 2010-06-16 17:57 (110 days old)
Handled-By : Bjorn Helgaas <bjorn.helgaas-VXdhtT5mjnY@public.gmane.org>
Patch : https://patchwork.kernel.org/patch/189182/
https://patchwork.kernel.org/patch/189232/
https://patchwork.kernel.org/patch/189242/
https://patchwork.kernel.org/patch/189252/
For details, please visit the bug entries and follow the links given in
references.
As you can see, there is a Bugzilla entry for each of the listed regressions.
There also is a Bugzilla entry used for tracking the regressions introduced
between 2.6.34 and 2.6.35, unresolved as well as resolved, at:
http://bugzilla.kernel.org/show_bug.cgi?id=16055
Please let the tracking team know if there are any Bugzilla entries that
should be added to the list in there.
Thanks!
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCHv3 net-next-2.6 3/5] XFRM,IPv6: Add IRO src/dst address remapping XFRM types and i/o handlers
From: Arnaud Ebalard @ 2010-10-03 21:25 UTC (permalink / raw)
To: Herbert Xu; +Cc: David Miller, eric.dumazet, yoshfuji, netdev
In-Reply-To: <20101003151202.GA11963@gondor.apana.org.au>
Hello,
Herbert Xu <herbert@gondor.apana.org.au> writes:
> On Sun, Oct 03, 2010 at 03:41:04PM +0200, Arnaud Ebalard wrote:
>>
>> After your reply, I took a (too long) look at the history of
>> xfrm6_input_addr() to understand why it is as it is. If it can spare you
>> some time, here is what I think happened:
>
> ...
>
>> - Then, as you wrote, the state lock was moved in all input handlers
>> (commit 0ebea8ef, Nov 13 2007), including RH2/HAO ones:
>
> ...
>
>> With that commit, I think a deadlock was introduced in MIPv6 code
>> because xfm6_input_addr() was left unchanged, i.e. x->type->input()
>> was called with the lock held. Am I correct?
>>
>> - The code of xfrm6_input_addr() was then optimized by commit a002c6fd
>> in such a way that x->type->input() was then put outside the
>> protection of the lock, which (if I am not mistaken) removed the
>> deadlock:
>
> ...
>
>> I don't know if this is was intentional.
>
> Indeed MIPv6 was completely out of action for three months and
> nobody noticed :)
hehe ;-) Just to correct a missing waypoint in my history, which is in
fact the real fix for the deadlock:
commit 9473e1f631de339c50bde1e3bd09e1045fe90fd5
Author: Masahide NAKAMURA <nakam@linux-ipv6.org>
Date: Thu Dec 20 20:41:57 2007 -0800
[XFRM] MIPv6: Fix to input RO state correctly.
Disable spin_lock during xfrm_type.input() function.
Follow design as IPsec inbound does.
Signed-off-by: Masahide NAKAMURA <nakam@linux-ipv6.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
>> But the main question remains on the position of the lock. Here,
>> checks are done on the status of the state, lock is released,
>> reacquired in the input handler to do additional check and then
>> released again, to be reacquired later in the function to act on
>> statistics. Is my reading of the code correct?
>
> When I moved the lock down I chose the safest option and added
> it to every single input function. So it may well be the case
> that the lock isn't needed at all on the MIPv6 path.
I don't have any technical argument to support the removal of the locks,
i.e. don't see what would prevent changes during the check. I will try
and spend more time on it, but meanwhile I think it's safe to keep
things the way they are.
Thanks for your time, Herbert.
Cheers,
a+
^ permalink raw reply
* 2.6.36-rc6-git2: Reported regressions from 2.6.35
From: Rafael J. Wysocki @ 2010-10-03 21:15 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Linux SCSI List, Linux ACPI, Network Development,
Linux Wireless List, DRI, Florian Mickler, Andrew Morton,
Kernel Testers List, Linus Torvalds, Linux PM List,
Maciej Rutecki
This message contains a list of some regressions from 2.6.35,
for which there are no fixes in the mainline known to the tracking team.
If any of them have been fixed already, please let us know.
If you know of any other unresolved regressions from 2.6.35, please let us
know either and we'll add them to the list. Also, please let us know
if any of the entries below are invalid.
Each entry from the list will be sent additionally in an automatic reply
to this message with CCs to the people involved in reporting and handling
the issue.
Listed regressions statistics:
Date Total Pending Unresolved
----------------------------------------
2010-10-03 52 16 14
2010-09-26 46 15 13
2010-09-20 38 15 15
2010-09-12 28 14 13
2010-08-30 21 16 15
Unresolved regressions
----------------------
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=19642
Subject : 2.6.36-rc6 BUG at drivers/scsi/scsi_lib.c:1113
Submitter : George Spelvin <linux@horizon.com>
Date : 2010-09-30 21:10 (4 days old)
Message-ID : <20100930211006.27449.qmail@science.horizon.com>
References : http://marc.info/?l=linux-kernel&m=128588102620299&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=19632
Subject : 2.6.36-rc6: modprobe Not tainted warning
Submitter : Heinz Diehl <htd@fritha.org>
Date : 2010-09-30 18:25 (4 days old)
Message-ID : <20100930182516.GA15089@fritha.org>
References : http://marc.info/?l=linux-kernel&m=128587114004680&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=19392
Subject : WARNING: at drivers/net/wireless/ath/ath5k/base.c:3475 ath5k_bss_info_changed+0x44/0x168 [ath5k]()
Submitter : Justin Mattock <justinmattock@gmail.com>
Date : 2010-09-28 22:30 (6 days old)
Message-ID : <AANLkTim5WCGKPvEkOkO_YnMF9pg8mvLfQoFBNUFpfa_k@mail.gmail.com>
References : http://marc.info/?l=linux-kernel&m=128571307018635&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=19372
Subject : 2.6.36-rc6: WARNING: at drivers/gpu/drm/radeon/radeon_fence.c:235 radeon_fence_wait+0x35a/0x3c0
Submitter : Alexey Dobriyan <adobriyan@gmail.com>
Date : 2010-09-29 21:29 (5 days old)
Message-ID : <20100929212923.GA5578@core2.telecom.by>
References : http://marc.info/?l=linux-kernel&m=128579579400315&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=19142
Subject : Screen flickers when switching from the console to X
Submitter : Andrey Rahmatullin <wrar@altlinux.org>
Date : 2010-09-27 12:05 (7 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=19072
Subject : [2.6.36-rc regression] occasional complete system hangs on sparc64 SMP
Submitter : Mikael Pettersson <mikpe@it.uu.se>
Date : 2010-09-23 17:02 (11 days old)
Message-ID : <19611.34846.813757.309183@pilspetsen.it.uu.se>
References : http://marc.info/?l=linux-kernel&m=128526136531048&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=19062
Subject : Dirtiable inode bdi default != sb bdi btrfs
Submitter : Cesar Eduardo Barros <cesarb@cesarb.net>
Date : 2010-09-23 0:54 (11 days old)
Message-ID : <<4C9AA546.6050201@cesarb.net>>
References : http://marc.info/?l=linux-kernel&m=128520328929595&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=19052
Subject : 2.6.36-rc5-git1 -- [drm:i915_report_and_clear_eir] *ERROR* EIR stuck: 0x00000010, masking
Submitter : Miles Lane <miles.lane@gmail.com>
Date : 2010-09-22 23:47 (12 days old)
Message-ID : <AANLkTikWQjUQjFJU9MO1+XbSLAEE-GARz+S+Dz2Fgu4h@mail.gmail.com>
References : http://marc.info/?l=linux-kernel&m=128519926626322&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=19002
Subject : Radeon rv730 AGP/KMS/DRM kernel lockup
Submitter : Duncan <1i5t5.duncan@cox.net>
Date : 2010-09-23 16:48 (11 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=17361
Subject : Watchdog detected hard LOCKUP in jbd2_journal_get_write_access
Submitter : Christian Casteyde <casteyde.christian@free.fr>
Date : 2010-08-29 19:59 (36 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=17121
Subject : Two blank rectangles more than 10 cm long when booting
Submitter : Eric Valette <eric.valette@free.fr>
Date : 2010-08-26 17:24 (39 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=17061
Subject : 2.6.36-rc1 on zaurus: bluetooth regression
Submitter : Pavel Machek <pavel@ucw.cz>
Date : 2010-08-21 15:24 (44 days old)
Message-ID : <20100821152445.GA1536@ucw.cz>
References : http://marc.info/?l=linux-kernel&m=128240433828087&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16971
Subject : qla4xxx compile failure on 32-bit PowerPC: missing readq and writeq
Submitter : Meelis Roos <mroos@linux.ee>
Date : 2010-08-19 21:03 (46 days old)
Message-ID : <alpine.SOC.1.00.1008192359310.19654@math.ut.ee>
References : http://marc.info/?l=linux-kernel&m=128225184900892&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16951
Subject : hackbench regression with 2.6.36-rc1
Submitter : Zhang, Yanmin <yanmin_zhang@linux.intel.com>
Date : 2010-08-18 6:18 (47 days old)
Message-ID : <1282112318.21202.8.camel@ymzhang.sh.intel.com>
References : http://marc.info/?l=linux-kernel&m=128211235904910&w=2
Regressions with patches
------------------------
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=18742
Subject : PROBLEM: Kernel panic on 2.6.36-rc4 when loading intel_ips on Core i3 laptop
Submitter : infernix <infernix@infernix.net>
Date : 2010-09-15 14:35 (19 days old)
Message-ID : <4C90D998.6050103@infernix.net>
References : http://marc.info/?l=linux-kernel&m=128456187928496&w=2
Handled-By : Jesse Barnes <jbarnes@virtuousgeek.org>
Patch : https://bugzilla.kernel.org/attachment.cgi?id=31112
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=17722
Subject : 2.6.36-rc3: WARNING: at net/mac80211/scan.c:269 ieee80211_scan_completed
Submitter : Thomas Meyer <thomas@m3y3r.de>
Date : 2010-08-31 20:14 (34 days old)
Message-ID : <201008312214.52473.thomas@m3y3r.de>
References : http://marc.info/?l=linux-kernel&m=128328580504227&w=2
http://www.spinics.net/lists/netdev/msg140769.html
Handled-By : Florian Mickler <florian@mickler.org>
Patch : https://bugzilla.kernel.org/attachment.cgi?id=31671
For details, please visit the bug entries and follow the links given in
references.
As you can see, there is a Bugzilla entry for each of the listed regressions.
There also is a Bugzilla entry used for tracking the regressions from 2.6.35,
unresolved as well as resolved, at:
http://bugzilla.kernel.org/show_bug.cgi?id=16444
Please let the tracking team know if there are any Bugzilla entries that
should be added to the list in there.
Thanks!
^ permalink raw reply
* Re: [PATCH] atmtcp: add sysfs attr for changing atm carrier signal state.
From: David Miller @ 2010-10-03 20:00 UTC (permalink / raw)
To: karl; +Cc: netdev, linux-atm-general, chas
In-Reply-To: <1286135485-27355-1-git-send-email-karl@hiramoto.org>
From: Karl Hiramoto <karl@hiramoto.org>
Date: Sun, 3 Oct 2010 21:51:25 +0200
> This will be used for device testing carrier signal changes in other parts of
> the atm stack.
>
> Carrier lost set by:
> echo -n 0 > /sys/class/atm/atmtcp0/carrier
>
> Carrier detected:
> echo -n 1 > /sys/class/atm/atmtcp0/carrier
>
> Signed-off-by: Karl Hiramoto <karl@hiramoto.org>
We already have enough sysfs hacky knobs.
And for something as fundamental as setting the carrier status, it's
not acceptable to add a device-type specific control.
Use something we have already, either via core device state management
(via netlink or ifconfig's ioctls) or ethtool.
Thanks.
^ permalink raw reply
* [PATCH] atmtcp: add sysfs attr for changing atm carrier signal state.
From: Karl Hiramoto @ 2010-10-03 19:51 UTC (permalink / raw)
To: netdev, linux-atm-general; +Cc: chas, davem, Karl Hiramoto
This will be used for device testing carrier signal changes in other parts of
the atm stack.
Carrier lost set by:
echo -n 0 > /sys/class/atm/atmtcp0/carrier
Carrier detected:
echo -n 1 > /sys/class/atm/atmtcp0/carrier
Signed-off-by: Karl Hiramoto <karl@hiramoto.org>
---
drivers/atm/atmtcp.c | 59 ++++++++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 59 insertions(+), 0 deletions(-)
diff --git a/drivers/atm/atmtcp.c b/drivers/atm/atmtcp.c
index b910181..7540e33 100644
--- a/drivers/atm/atmtcp.c
+++ b/drivers/atm/atmtcp.c
@@ -210,6 +210,18 @@ static int atmtcp_v_send(struct atm_vcc *vcc,struct sk_buff *skb)
atomic_inc(&vcc->stats->tx_err);
return -ENOLINK;
}
+
+ if (vcc->dev->signal == ATM_PHY_SIG_LOST) {
+ pr_warning(DEV_LABEL ": Dropping TX pkt, upper layer not handling carrier signal lost\n");
+ if (vcc->pop)
+ vcc->pop(vcc, skb);
+ else
+ dev_kfree_skb(skb);
+
+ atomic_inc(&vcc->stats->tx_err);
+ return -ENOLINK;
+ }
+
size = skb->len+sizeof(struct atmtcp_hdr);
new_skb = atm_alloc_charge(out_vcc,size,GFP_ATOMIC);
if (!new_skb) {
@@ -304,6 +316,12 @@ static int atmtcp_c_send(struct atm_vcc *vcc,struct sk_buff *skb)
atomic_inc(&vcc->stats->tx_err);
goto done;
}
+
+ if (out_vcc->dev->signal == ATM_PHY_SIG_LOST) {
+ pr_debug(DEV_LABEL ": Dropping RX pkt while no carrier signal\n");
+ result = -ENOLINK;
+ goto done;
+ }
skb_pull(skb,sizeof(struct atmtcp_hdr));
new_skb = atm_alloc_charge(out_vcc,skb->len,GFP_KERNEL);
if (!new_skb) {
@@ -356,6 +374,43 @@ static struct atm_dev atmtcp_control_dev = {
.lock = __SPIN_LOCK_UNLOCKED(atmtcp_control_dev.lock)
};
+static ssize_t __set_signal(struct device *dev,
+ struct device_attribute *attr,
+ const char *buf, size_t len)
+{
+ struct atm_dev *atm_dev = container_of(dev, struct atm_dev, class_dev);
+ int signal;
+
+ if (sscanf(buf, "%d", &signal) == 1) {
+
+ if (signal < ATM_PHY_SIG_LOST || signal > ATM_PHY_SIG_FOUND)
+ signal = ATM_PHY_SIG_UNKNOWN;
+
+ atm_dev_signal_change(atm_dev, signal);
+ return 1;
+ }
+ return -EINVAL;
+}
+
+static ssize_t __show_signal(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ struct atm_dev *atm_dev = container_of(dev, struct atm_dev, class_dev);
+ return sprintf(buf, "%d\n", atm_dev->signal);
+}
+
+static DEVICE_ATTR(signal, 0644, __show_signal, __set_signal);
+
+static struct attribute *atmtcp_attrs[] = {
+ &dev_attr_signal.attr,
+ NULL
+};
+
+static struct attribute_group atmtcp_group_attrs = {
+ .name = NULL, /* We want them in dev's root folder */
+ .attrs = atmtcp_attrs
+};
+
static int atmtcp_create(int itf,int persist,struct atm_dev **result)
{
@@ -376,6 +431,10 @@ static int atmtcp_create(int itf,int persist,struct atm_dev **result)
dev->dev_data = dev_data;
PRIV(dev)->vcc = NULL;
PRIV(dev)->persist = persist;
+
+ if (sysfs_create_group(&dev->class_dev.kobj, &atmtcp_group_attrs))
+ dev_err(&dev->class_dev, "Could not register sysfs attrs for atmtcp\n");
+
if (result) *result = dev;
return 0;
}
--
1.7.2.2
^ permalink raw reply related
* Reply Urgent Message
From: Huss Ejvet @ 2010-10-03 19:41 UTC (permalink / raw)
--
I am Ejvet a Manager in AKBank NV,I have a confidential proposal for you which I need you to execute with me.The sum of GBP£25,000,000.00(Twenty Five Million Pounds Sterling's)please provide me details if you are interested :
1.Full Name
2.Telephone Number
3.Contact Address
Thank
Huss Ejvet
^ permalink raw reply
* [PATCH] tms380tr: fix long delays in initialization
From: Meelis Roos @ 2010-10-03 19:34 UTC (permalink / raw)
To: netdev
tms380tr driver tries to use udelay (meaning busy loop) for several half
second delays during hardware initialization. Crazy overly long busy
wait delays mean no delay at all so driver initialization fails without
waiting. Fix it by using msleep() for long delays and leave it to
udelay() for short delays.
Signed-off-by: Meelis Roos <mroos@linux.ee>
---
drivers/net/tokenring/tms380tr.c | 32 ++++++++++++++++----------------
1 files changed, 16 insertions(+), 16 deletions(-)
diff --git a/drivers/net/tokenring/tms380tr.c b/drivers/net/tokenring/tms380tr.c
index aaec637..e6dc2df 100644
--- a/drivers/net/tokenring/tms380tr.c
+++ b/drivers/net/tokenring/tms380tr.c
@@ -177,6 +177,7 @@ static void tms380tr_update_rcv_stats(struct net_local *tp,
unsigned char DataPtr[], unsigned int Length);
/* "W" */
void tms380tr_wait(unsigned long time);
+static void tms380tr_wait_long(unsigned long time);
static void tms380tr_write_rpl_status(RPL *rpl, unsigned int Status);
static void tms380tr_write_tpl_status(TPL *tpl, unsigned int Status);
@@ -1216,20 +1217,19 @@ static void tms380tr_set_multicast_list(struct net_device *dev)
}
/*
- * Wait for some time (microseconds)
+ * Wait for some time (microseconds) - busy wait
*/
void tms380tr_wait(unsigned long time)
{
-#if 0
- long tmp;
-
- tmp = jiffies + time/(1000000/HZ);
- do {
- tmp = schedule_timeout_interruptible(tmp);
- } while(time_after(tmp, jiffies));
-#else
udelay(time);
-#endif
+}
+
+/*
+ * Wait for long time (microseconds) - schedule
+ */
+static void tms380tr_wait_long(unsigned long time)
+{
+ msleep(time / 1000);
}
/*
@@ -1352,9 +1352,9 @@ static int tms380tr_bringup_diags(struct net_device *dev)
int loop_cnt, retry_cnt;
unsigned short Status;
- tms380tr_wait(HALF_SECOND);
+ tms380tr_wait_long(HALF_SECOND);
tms380tr_exec_sifcmd(dev, EXEC_SOFT_RESET);
- tms380tr_wait(HALF_SECOND);
+ tms380tr_wait_long(HALF_SECOND);
retry_cnt = BUD_MAX_RETRIES; /* maximal number of retrys */
@@ -1365,7 +1365,7 @@ static int tms380tr_bringup_diags(struct net_device *dev)
loop_cnt = BUD_MAX_LOOPCNT; /* maximum: three seconds*/
do { /* Inspect BUD results */
loop_cnt--;
- tms380tr_wait(HALF_SECOND);
+ tms380tr_wait_long(HALF_SECOND);
Status = SIFREADW(SIFSTS);
Status &= STS_MASK;
@@ -1384,7 +1384,7 @@ static int tms380tr_bringup_diags(struct net_device *dev)
printk(KERN_INFO "%s: Adapter Software Reset.\n",
dev->name);
tms380tr_exec_sifcmd(dev, EXEC_SOFT_RESET);
- tms380tr_wait(HALF_SECOND);
+ tms380tr_wait_long(HALF_SECOND);
}
} while(retry_cnt > 0);
@@ -1457,7 +1457,7 @@ static int tms380tr_init_adapter(struct net_device *dev)
do {
Status = 0;
loop_cnt--;
- tms380tr_wait(HALF_SECOND);
+ tms380tr_wait_long(HALF_SECOND);
/* Mask interesting status bits */
Status = SIFREADW(SIFSTS);
@@ -1506,7 +1506,7 @@ static int tms380tr_init_adapter(struct net_device *dev)
{
/* Reset adapter and try init again */
tms380tr_exec_sifcmd(dev, EXEC_SOFT_RESET);
- tms380tr_wait(HALF_SECOND);
+ tms380tr_wait_long(HALF_SECOND);
}
}
}
--
1.7.1
--
Meelis Roos (mroos@linux.ee)
^ permalink raw reply related
* Reply Urgent Message
From: Huss Ejvet @ 2010-10-03 18:58 UTC (permalink / raw)
I am Ejvet a Manager in AKBank NV,I have a confidential proposal for you which I need you to execute with me.The sum of GBP£25,000,000.00(Twenty Five Million Pounds Sterling's)please provide me details if you are interested :
1.Full Name
2.Telephone Number
3.Contact Address
Thank
Huss Ejvet
^ permalink raw reply
* [GIT] Networking
From: David Miller @ 2010-10-03 18:41 UTC (permalink / raw)
To: torvalds; +Cc: akpm, netdev, linux-kernel
1) The UM duplicate field regression fix, from Boaz Harrosh.
2) Max SYN retry sysctl doesn't end up generating the right number of
SYN retransmits due to bad calculations in retransmits_timed_out().
Fix from Damian Lukowski.
3) We erroneously drop VLAN packets when device is in promiscuous mode,
fix from Eric Dumazet.
4) Fix ip_gre Kconfig dependenices wrt. ipv6.
5) Phone uses stale protocol header pointer after pskb_may_pull() call,
fix from Kumar Sanghvi.
6) Use after free fix in mac80211 from Johannes Berg.
7) Fix work queueing in Intel wireless, from Florian Mickler.
Please pull, thanks a lot!
The following changes since commit c6ea21e35bf3691cad59647c771e6606067f627d:
Merge git://git.kernel.org/pub/scm/linux/kernel/git/sfrench/cifs-2.6 (2010-10-01 15:03:37 -0700)
are available in the git repository at:
master.kernel.org:/pub/scm/linux/kernel/git/davem/net-2.6.git master
Boaz Harrosh (1):
um: Proper Fix for f25c80a4: remove duplicate structure field initialization
Damian Lukowski (1):
net-2.6: SYN retransmits: Add new parameter to retransmits_timed_out()
David S. Miller (2):
ip_gre: Fix dependencies wrt. ipv6.
Merge branch 'master' of git://git.kernel.org/.../linville/wireless-2.6
Eric Dumazet (1):
vlan: dont drop packets from unknown vlans in promiscuous mode
Florian Mickler (1):
iwl3945: queue the right work if the scan needs to be aborted
Johannes Berg (1):
mac80211: fix use-after-free
Kumar Sanghvi (1):
Phonet: Correct header retrieval after pskb_may_pull
arch/um/drivers/net_kern.c | 17 +++--------------
drivers/net/wireless/iwlwifi/iwl-agn-lib.c | 2 +-
drivers/net/wireless/iwlwifi/iwl3945-base.c | 2 +-
net/8021q/vlan_core.c | 14 ++++++++++----
net/ipv4/Kconfig | 1 +
net/ipv4/tcp_timer.c | 24 ++++++++++++++----------
net/mac80211/rx.c | 4 ----
net/phonet/pep.c | 3 ++-
8 files changed, 32 insertions(+), 35 deletions(-)
^ permalink raw reply
* Re: sysctl_{tcp,udp,sctp}_mem overflow on 16TB system.
From: Willy Tarreau @ 2010-10-03 16:43 UTC (permalink / raw)
To: Maciej ??enczykowski
Cc: Robin Holt, David S. Miller, Alexey Kuznetsov,
Pekka Savola (ipv6), James Morris, Hideaki YOSHIFUJI,
Patrick McHardy, Vlad Yasevich, Sridhar Samudrala, linux-kernel,
netdev, linux-decnet-user, linux-sctp
In-Reply-To: <AANLkTin5wPvFQDFrupqGs_Jbh1rgrTjMupbPUFnvrBrv@mail.gmail.com>
On Sun, Oct 03, 2010 at 01:20:32AM -0700, Maciej ??enczykowski wrote:
> Isn't INT_MAX/2 just 1GB, which is only ~0.9 seconds at 10 Gbps?
no, the size is in pages (and is often wrong when people change it
from the default value).
Regards,
Willy
^ permalink raw reply
* Re: [PATCHv3 net-next-2.6 3/5] XFRM,IPv6: Add IRO src/dst address remapping XFRM types and i/o handlers
From: Herbert Xu @ 2010-10-03 15:12 UTC (permalink / raw)
To: Arnaud Ebalard; +Cc: David Miller, eric.dumazet, yoshfuji, netdev
In-Reply-To: <87iq1j5r7z.fsf@small.ssi.corp>
On Sun, Oct 03, 2010 at 03:41:04PM +0200, Arnaud Ebalard wrote:
>
> After your reply, I took a (too long) look at the history of
> xfrm6_input_addr() to understand why it is as it is. If it can spare you
> some time, here is what I think happened:
...
> - Then, as you wrote, the state lock was moved in all input handlers
> (commit 0ebea8ef, Nov 13 2007), including RH2/HAO ones:
...
> With that commit, I think a deadlock was introduced in MIPv6 code
> because xfm6_input_addr() was left unchanged, i.e. x->type->input()
> was called with the lock held. Am I correct?
>
> - The code of xfrm6_input_addr() was then optimized by commit a002c6fd
> in such a way that x->type->input() was then put outside the
> protection of the lock, which (if I am not mistaken) removed the
> deadlock:
...
> I don't know if this is was intentional.
Indeed MIPv6 was completely out of action for three months and
nobody noticed :)
> But the main question remains on the position of the lock. Here,
> checks are done on the status of the state, lock is released,
> reacquired in the input handler to do additional check and then
> released again, to be reacquired later in the function to act on
> statistics. Is my reading of the code correct?
When I moved the lock down I chose the safest option and added
it to every single input function. So it may well be the case
that the lock isn't needed at all on the MIPv6 path.
Cheers,
--
Email: Herbert Xu <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
* URGENT REPLY
From: CEO Walter Partnership @ 2010-10-03 13:38 UTC (permalink / raw)
Dear Beneficiary,
INVESTIGATION ON YOUR PAYMENT FILE
Today investigation on your payment file and reason for delaying your
own payment approved since.
Please are you still alive/dead? Did you sign any dead assignment in
favor of this (John Smith) to receive your funds today?
This investigation bureau office has endorsed the actual time for the
final accomplishment of your payment.
Re-confirm to us immediately and receive your overdue approved
payment/fund as you fill this form below:
Name......................
Address...................
Nationality................
Age, Sex..................
Occupation.................
Company Name..............
Telephone Number..........
Drivers license/Int? Passport
Do reply immediately for confirmation and receive your final approved
funds of $2 million united state dollars.
Best regards,
Mr Christus Benard,
(Chief Investigation Officer).
^ permalink raw reply
* Re: [PATCH 8/8] net: Implement socketat.
From: jamal @ 2010-10-03 13:44 UTC (permalink / raw)
To: Daniel Lezcano
Cc: Pavel Emelyanov, Eric W. Biederman, linux-kernel,
Linux Containers, netdev, netfilter-devel, linux-fsdevel,
Linus Torvalds, Michael Kerrisk, Ulrich Drepper, Al Viro,
David Miller, Serge E. Hallyn, Pavel Emelyanov, Ben Greear,
Matt Helsley, Jonathan Corbet, Sukadev Bhattiprolu,
Jan Engelhardt, Patrick McHardy
In-Reply-To: <4CA7A07C.5030504@free.fr>
Hi Daniel,
Thanks for clarifying this ..
On Sat, 2010-10-02 at 23:13 +0200, Daniel Lezcano wrote:
> Just to clarify this point. You enter the namespace, create the socket
> and go back to the initial namespace (or create a new one). Further
> operations can be made against this fd because it is the network
> namespace stored in the sock struct which is used, not the current
> process network namespace which is used at the socket creation only.
>
> We can actually already do that by unsharing and then create a
> socket.
> This socket will pin the namespace and can be used as a control socket
> for the namespace (assuming the socket domain will be ok for all the
> operations).
>
> Jamal, I don't know what kind of application you want to use but if I
> assume you want to create a process controlling 1024 netns,
At the moment i am looking at 8K on a Nehalem with lots of RAM. They
will mostly be created at startup but some could be created afterwards.
Each will have its own netdevs etc. also created at startup (and some
other config that may happen later).
Because startup time may accumulate, it is clearly important to me
to pick whatever scheme that reduces the number of calls...
> let's try to identificate what happen with setns and with socketat :
>
> With setns:
>
> * open /proc/self/ns/net (1)
> * unshare the netns
> * open /proc/self/ns/net (2)
> * setns (1)
> * create a virtual network device
> * move the virtual device to (2) (using the set netns by fd)
> * unshare the netns
> ...
>
> With socketat:
>
> * open a socket (1)
> * unshare the netns
> * open a netlink with socketat(1) => (2)
> * create a virtual device using (2) (at this point it is
> init_net_ns)
> * move the virtual device to the current netns (using the set
> netns
> by pid)
> * open a socket (3)
> * unshare the netns
> ...
>
> We have the same number of file descriptors kept opened. Except, with
> setns we can bind mount the directory somewhere, that will pin the
> namespace and then we can close the /proc/self/ns/net file descriptors
> and reopen them later.
>
Ok, so a wrapper such as: create_socket_on(namespaceid)
will have generally less system calls with socketat()
> If your application has to do a lot of specific network processing,
> during its life cycle, in different namespaces, the socketat syscall
> will be better because it will reduce the number of syscalls but at
> the cost of keeping the file descriptors opened (potentially a big
> number). Otherwise, setns should fit your needs.
Makes sense.
One thing still confuses me...
The app control point is in namespace0. I still want to be able to
"boot" namespaces first and maybe a few seconds later do a socketat()...
and create devices, tcp sockets etc. I suspect create_ns(namespace-name)
would involve:
* open /proc/self/ns/net (namespace-name)
* unshare the netns
Is this correct?
cheers,
jamal
^ permalink raw reply
* Re: [PATCHv3 net-next-2.6 3/5] XFRM,IPv6: Add IRO src/dst address remapping XFRM types and i/o handlers
From: Arnaud Ebalard @ 2010-10-03 13:41 UTC (permalink / raw)
To: Herbert Xu; +Cc: David Miller, eric.dumazet, yoshfuji, netdev
In-Reply-To: <20101002103205.GA3879@gondor.apana.org.au>
Hi Herbert,
Herbert Xu <herbert@gondor.apana.org.au> writes:
> On Sat, Oct 02, 2010 at 12:17:35PM +0200, Arnaud Ebalard wrote:
>>
>> and I see no reason not to keep the lock we have on the state until the
>> end of the function when the state is valid (when we break), instead of
>> releasing it to get it again later. Something like the following would
>> allow removing the spin_lock()/spin_unlock() calls from all mip6 input
>> handlers (mip6_{destopt,rthdr,iro_src,iro_dst}_input()):
>
> No I moved the state lock down precisely because it should not
> be taken at a higher level as that breaks asynchronous IPsec
> processing and the fact that it isn't needed in most places.
>
> If your code needs it then you should take it rather than impose
> it on real IPsec users.
Understood. Note that I am on your side with this: my primary concern
while pushing the feature is *to not break or slow down standard IPsec*.
I do not expect my code to be accepted or even read otherwise.
As for the current point raised by David on the position of the locks in
my input handlers, they are based on the position of the locks in the
*existing* RH2 (mip6_rthdr_input()) and HAO (mip6_destopt_input())
handlers. As they serve the same purpose (src/dst address check against
state's address) and the code is basically the same, I have no reason to
do things differently as what is currently upstream.
After your reply, I took a (too long) look at the history of
xfrm6_input_addr() to understand why it is as it is. If it can spare you
some time, here is what I think happened:
- Initially (commit fbd9a5b4, Aug 23 2006), the checks on the status of
state, the call to x->type->input() and the changes on state's
processing stats (x->curlft changes) were *globally* protected by a
call to spin_lock(). The same day, a related commit (3d126890) added
support for RH2/HAO input handler. No lock inside the handler. The
content of xfrm6_input_addr() was:
spin_lock(&x->lock);
<...snip...>
nh = x->type->input(x, skb);
if (nh <= 0) {
spin_unlock(&x->lock);
xfrm_state_put(x);
x = NULL;
continue;
}
x->curlft.bytes += skb->len;
x->curlft.packets++;
spin_unlock(&x->lock);
- Then, as you wrote, the state lock was moved in all input handlers
(commit 0ebea8ef, Nov 13 2007), including RH2/HAO ones:
@@ -128,12 +128,15 @@ static int mip6_destopt_input(struct xfrm_state *x, struct sk_buff *skb)
{
struct ipv6hdr *iph = ipv6_hdr(skb);
struct ipv6_destopt_hdr *destopt = (struct ipv6_destopt_hdr *)skb->data;
+ int err = destopt->nexthdr;
+ spin_lock(&x->lock);
if (!ipv6_addr_equal(&iph->saddr, (struct in6_addr *)x->coaddr) &&
!ipv6_addr_any((struct in6_addr *)x->coaddr))
- return -ENOENT;
+ err = -ENOENT;
+ spin_unlock(&x->lock);
- return destopt->nexthdr;
+ return err;
}
With that commit, I think a deadlock was introduced in MIPv6 code
because xfm6_input_addr() was left unchanged, i.e. x->type->input()
was called with the lock held. Am I correct?
- The code of xfrm6_input_addr() was then optimized by commit a002c6fd
in such a way that x->type->input() was then put outside the
protection of the lock, which (if I am not mistaken) removed the
deadlock:
spin_lock(&x->lock);
if ((!i || (x->props.flags & XFRM_STATE_WILDRECV)) &&
likely(x->km.state == XFRM_STATE_VALID) &&
!xfrm_state_check_expire(x)) {
spin_unlock(&x->lock);
if (x->type->input(x, skb) > 0) {
/* found a valid state */
break;
}
} else
spin_unlock(&x->lock);
I don't know if this is was intentional.
But the main question remains on the position of the lock. Here,
checks are done on the status of the state, lock is released,
reacquired in the input handler to do additional check and then
released again, to be reacquired later in the function to act on
statistics. Is my reading of the code correct?
Herbert, you certainly have a better understanding of XFRM code than I
have and can probably tell if the locking behavior above is valid or
buggy. Yoshifuji-san, David or Eric may also have good ideas on that.
As a side note (I think I was not explicit enough in my previous email),
I think the possible changes to xfrm_input_addr() and MIPv6 handlers we
are discussing are not expected to impact standard IPsec code because
there are 2 different cases in which states input handlers are called
(i.e. x->type->input()):
- xfrm_input(): for standard IPsec case (incl. async resumption). This
is only for esp, ah, ipcomp and tunneling.
- xfrm6_input_addr(): for MIPv6 extension header, i.e. RH2 and HAO in
destopt.
and we are discussing the second.
David, as for my patches, if this is ok for you, I will keep the code of
my input handlers aligned on the code of RH2/HAO handlers and will modify
it later based on the possible corrections made on those upstream.
Don't hesitate to slap me if I made some mistakes in my analysis ;-)
Cheers,
a+
^ 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