* 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 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: [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
* 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: 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
* [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
* [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
* 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
* 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] 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] 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 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] 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: David Miller @ 2010-10-04 4:01 UTC (permalink / raw)
To: ben; +Cc: netdev
In-Reply-To: <1286164495.3916.316.camel@localhost>
From: Ben Hutchings <ben@decadent.org.uk>
Date: Mon, 04 Oct 2010 04:54:55 +0100
> 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.
Oh, I see, ok I'll apply your patches thanks for explaining Ben.
^ permalink raw reply
* Re: [PATCH net-next] gre: protocol table can be static
From: David Miller @ 2010-10-04 4:51 UTC (permalink / raw)
To: shemminger; +Cc: netdev, herbert
In-Reply-To: <20101002085800.4cd06561@s6510>
From: Stephen Hemminger <shemminger@vyatta.com>
Date: Sat, 2 Oct 2010 08:58:00 +0900
> This table is only used in gre.c
>
> Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next 1/4] ipmr: __pim_rcv() is called under rcu_read_lock
From: David Miller @ 2010-10-04 4:51 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <1285985695.2582.521.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Sat, 02 Oct 2010 04:14:55 +0200
> No need to get a reference on reg_dev and release it, we are in a
> rcu_read_lock() protected section.
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next 2/4] ipmr: RCU conversion of mroute_sk
From: David Miller @ 2010-10-04 4:51 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <1285985701.2582.522.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Sat, 02 Oct 2010 04:15:01 +0200
> Use RCU and RTNL to protect (struct mr_table)->mroute_sk
>
> Readers use RCU, writers use RTNL.
>
> ip_ra_control() already use an RCU grace period before
> ip_ra_destroy_rcu(), so we dont need synchronize_rcu() in
> mrtsock_destruct()
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next 3/4] ipmr: RCU protection for mfc_cache_array
From: David Miller @ 2010-10-04 4:51 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <1285985708.2582.523.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Sat, 02 Oct 2010 04:15:08 +0200
> Use RCU & RTNL protection for mfc_cache_array[]
>
> ipmr_cache_find() is called under rcu_read_lock();
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next 4/4] ipmr: cleanups
From: David Miller @ 2010-10-04 4:51 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <1285985729.2582.525.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Sat, 02 Oct 2010 04:15:29 +0200
> Various code style cleanups
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Applied.
^ permalink raw reply
* Re: [patch 1/1] sctp: prevent reading out-of-bounds memory
From: David Miller @ 2010-10-04 4:59 UTC (permalink / raw)
To: akpm; +Cc: netdev, dan.j.rosenberg, vladislav.yasevich
In-Reply-To: <201010012116.o91LGwS5021150@imap1.linux-foundation.org>
From: akpm@linux-foundation.org
Date: Fri, 01 Oct 2010 14:16:58 -0700
> From: Dan Rosenberg <dan.j.rosenberg@gmail.com>
>
> Two user-controlled allocations in SCTP are subsequently dereferenced as
> sockaddr structs, without checking if the dereferenced struct members fall
> beyond the end of the allocated chunk. There doesn't appear to be any
> information leakage here based on how these members are used and
> additional checking, but it's still worth fixing.
>
> [akpm@linux-foundation.org: remove unfashionable newlines, fix gmail tab->space conversion]
> Signed-off-by: Dan Rosenberg <dan.j.rosenberg@gmail.com>
> Acked-by: Vlad Yasevich <vladislav.yasevich@hp.com>
> Cc: David Miller <davem@davemloft.net>
> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Applied.
^ permalink raw reply
* Re: [patch 2/2] drivers/net/stmmac/: add HAS_IOMEM dependency
From: David Miller @ 2010-10-04 5:00 UTC (permalink / raw)
To: akpm; +Cc: netdev, schwidefsky, heiko.carstens, peppe.cavallaro
In-Reply-To: <201010012117.o91LHDCF021161@imap1.linux-foundation.org>
From: akpm@linux-foundation.org
Date: Fri, 01 Oct 2010 14:17:13 -0700
> From: Martin Schwidefsky <schwidefsky@de.ibm.com>
>
> The stmmac driver does not compile on s390:
>
> drivers/net/stmmac/stmmac_main.c: In function 'stmmac_adjust_link':
> drivers/net/stmmac/stmmac_main.c:210: error: implicit declaration of function 'readl'
> drivers/net/stmmac/stmmac_main.c:263: error: implicit declaration of function 'writel'
> drivers/net/stmmac/stmmac_main.c: In function 'stmmac_dvr_probe':
> drivers/net/stmmac/stmmac_main.c:1674: error: implicit declaration of function 'ioremap'
> drivers/net/stmmac/stmmac_main.c:1674: warning: assignment makes pointer from integer without a cast
> drivers/net/stmmac/stmmac_main.c:1761: error: implicit declaration of function 'iounmap'
> make[3]: *** [drivers/net/stmmac/stmmac_main.o] Error 1
>
> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
> Cc: Giuseppe CAVALLARO <peppe.cavallaro@st.com>
> Cc: David S. Miller <davem@davemloft.net>
> Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
This got fixed by adding a dependency on CPU_SUBTYPE_ST40.
^ permalink raw reply
* Re: [patch 1/2] drivers-net-tulip-de4x5c-fix-copy-length-in-de4x5_ioctl-checkpatch-fixes
From: David Miller @ 2010-10-04 5:00 UTC (permalink / raw)
To: akpm; +Cc: netdev, dan.j.rosenberg, grundler, jeffm
In-Reply-To: <201010012117.o91LHCJt021158@imap1.linux-foundation.org>
From: akpm@linux-foundation.org
Date: Fri, 01 Oct 2010 14:17:12 -0700
> From: Andrew Morton <akpm@linux-foundation.org>
>
> ERROR: trailing statements should be on next line
> #23: FILE: drivers/net/tulip/de4x5.c:5477:
> + if (copy_to_user(ioc->data, tmp.lval, ioc->len)) return -EFAULT;
>
> total: 1 errors, 0 warnings, 8 lines checked
>
> ./patches/drivers-net-tulip-de4x5c-fix-copy-length-in-de4x5_ioctl.patch has style problems, please review. If any of these errors
> are false positives report them to the maintainer, see
> CHECKPATCH in MAINTAINERS.
>
> Please run checkpatch prior to sending patches
>
> Cc: Dan Rosenberg <dan.j.rosenberg@gmail.com>
> Cc: Grant Grundler <grundler@parisc-linux.org>
> Cc: Jeff Mahoney <jeffm@suse.com>
> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Applied to net-next-2.6
^ permalink raw reply
* Re: [PATCH] correct IGMP behavior on v3 query during v2-compatibility mode
From: David Miller @ 2010-10-04 5:01 UTC (permalink / raw)
To: dlstevens; +Cc: netdev
In-Reply-To: <1285892980.21804.7.camel@w-dls.beaverton.ibm.com>
From: David L Stevens <dlstevens@us.ibm.com>
Date: Thu, 30 Sep 2010 17:29:40 -0700
> A recent patch to allow IGMPv2 responses to IGMPv3 queries
> bypasses length checks for valid query lengths, incorrectly
> resets the v2_seen timer, and does not support IGMPv1.
>
> The following patch responds with a v2 report as required
> by IGMPv2 while correcting the other problems introduced
> by the patch.
>
> Signed-Off-By: David L Stevens <dlstevens@us.ibm.com>
Applied, thanks David.
^ permalink raw reply
* Re: [PATCH] Fix out-of-bounds reading in sctp_asoc_get_hmac()
From: David Miller @ 2010-10-04 5:00 UTC (permalink / raw)
To: vladislav.yasevich
Cc: drosenberg, sri, linux-sctp, linux-kernel, security, stable,
netdev
In-Reply-To: <4CA65D0E.6080604@hp.com>
From: Vlad Yasevich <vladislav.yasevich@hp.com>
Date: Fri, 01 Oct 2010 18:13:34 -0400
> On 10/01/2010 05:51 PM, Dan Rosenberg wrote:
>> The sctp_asoc_get_hmac() function iterates through a peer's hmac_ids
>> array and attempts to ensure that only a supported hmac entry is
>> returned. The current code fails to do this properly - if the last id
>> in the array is out of range (greater than SCTP_AUTH_HMAC_ID_MAX), the
>> id integer remains set after exiting the loop, and the address of an
>> out-of-bounds entry will be returned and subsequently used in the
>> parent
>> function, causing potentially ugly memory corruption. This patch
>> resets
>> the id integer to 0 on encountering an invalid id so that NULL will be
>> returned after finishing the loop if no valid ids are found.
>>
>> Signed-off-by: Dan Rosenberg<drosenberg@vsecurity.com>
>
> Good catch.
>
> Acked-by: Vlad Yasevich <vladislav.yasevich@hp.com>
Applied.
^ permalink raw reply
* Re: [PATCH 4/4] drivers/atm/idt77252.c: Remove unnecessary error check
From: David Miller @ 2010-10-04 5:06 UTC (permalink / raw)
To: julia
Cc: wharms, chas, kernel-janitors, linux-atm-general, netdev,
linux-kernel
In-Reply-To: <Pine.LNX.4.64.1010021636330.21879@ask.diku.dk>
From: Julia Lawall <julia@diku.dk>
Date: Sat, 2 Oct 2010 16:37:07 +0200 (CEST)
> This code does not call deinit_card(card); in an error case, as done in
> other error-handling code in the same function. But actually, the called
> function init_sram can only return 0, so there is no need for the error
> check at all.
>
> init_sram is also given a void return type, and its single return statement
> at the end of the function is dropped.
>
> A simplified version of the sematic match that finds this problem is as
> follows: (http://coccinelle.lip6.fr/)
...
> Signed-off-by: Julia Lawall <julia@diku.dk>
Applied, thank you.
^ 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