* Re: 2.6.24-rc6-mm1
From: Torsten Kaiser @ 2008-01-06 3:16 UTC (permalink / raw)
To: Jarek Poplawski
Cc: Herbert Xu, Andrew Morton, linux-kernel, Neil Brown,
J. Bruce Fields, netdev, Tom Tucker
In-Reply-To: <64bb37e0801051410p39746295oab4dad438943372@mail.gmail.com>
On Jan 5, 2008 11:10 PM, Torsten Kaiser <just.for.lkml@googlemail.com> wrote:
> 2.6.24-rc6 + mm-patches up to git.battery (includes git-net and
> git-netdev-all) worked for 110 packages, then I proclaimed it good.
> 2.6.24-rc6 + mm-patches up to (including) git.nfsd is currently
> getting testet (9 packages done...)
That kernel did also work for all 110 packages.
2.6.24-rc6 + mm-patches up to (including) git.xfs -> crash
[ 576.899332] ------------[ cut here ]------------
[ 576.903661] kernel BUG at lib/list_debug.c:33!
[ 576.903661] invalid opcode: 0000 [1] SMP
[ 576.903661] last sysfs file:
/devices/system/cpu/cpu3/cache/index2/shared_cpu_map
[ 576.903661] CPU 3
[ 576.903661] Modules linked in: radeon drm w83792d ipv6 tuner
tea5767 tda8290 tuner_xc2028 tda9887 tuner_simple mt20xx tea5761
tvaudio msp3400 bttv ir_common compat_ioctl32 videobuf_dma_sg
videobuf_core btcx_risc tveeprom videodev v4l2_common usbhid
v4l1_compat sg hid i2c_nforce2 pata_amd
[ 576.903661] Pid: 5559, comm: nfsv4-svc Not tainted 2.6.24-rc6-mm-git.xfs #2
[ 576.903661] RIP: 0010:[<ffffffff803c16e4>] [<ffffffff803c16e4>]
__list_add+0x54/0x60
[ 576.903661] RSP: 0018:ffff81007d4e1dc0 EFLAGS: 00010282
[ 576.903661] RAX: 0000000000000088 RBX: ffff81007e955800 RCX: fffffffffc6c7900
[ 576.903661] RDX: ffff81007d53eef0 RSI: 0000000000000001 RDI: ffffffff80760140
[ 576.903661] RBP: ffff81007d4e1dc0 R08: 0000000000000001 R09: 0000000000000000
[ 576.903661] R10: ffff810080062008 R11: 0000000000000001 R12: ffff81007ed00900
[ 576.903661] R13: ffff81007ed00938 R14: ffff81007ed00938 R15: ffff81007dd6f100
[ 576.903661] FS: 00007f1b7e6a36f0(0000) GS:ffff81011ff1b780(0000)
knlGS:0000000000000000
[ 576.903661] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
[ 576.903661] CR2: 00007ffb28c2c000 CR3: 00000000741ab000 CR4: 00000000000006e0
[ 576.903661] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 576.903661] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[ 576.903661] Process nfsv4-svc (pid: 5559, threadinfo
ffff81007d4e0000, task ffff81007d53eef0)
[ 576.903661] Stack: ffff81007d4e1e00 ffffffff805c4dbb
ffff81007ed00908 ffff81007dd6f100
[ 576.903661] ffff81011ad7bc00 ffff81007d458000 ffff81007e955800
ffff81007dd6f110
[ 576.903661] ffff81007d4e1e10 ffffffff805c4ea7 ffff81007d4e1ee0
ffffffff805c5fd4
[ 576.903661] Call Trace:
[ 576.903661] [<ffffffff805c4dbb>] svc_xprt_enqueue+0x1ab/0x240
[ 576.903661] [<ffffffff805c4ea7>] svc_xprt_received+0x17/0x20
[ 576.903661] [<ffffffff805c5fd4>] svc_recv+0x394/0x7c0
[ 576.903661] [<ffffffff805c53de>] svc_send+0xae/0xd0
[ 576.903661] [<ffffffff80230ab0>] default_wake_function+0x0/0x10
[ 576.903661] [<ffffffff80316499>] nfs_callback_svc+0x79/0x130
[ 576.903662] [<ffffffff80232f8c>] finish_task_switch+0xcc/0xe0
[ 576.903662] [<ffffffff8020c818>] child_rip+0xa/0x12
[ 576.903662] [<ffffffff8020bf2f>] restore_args+0x0/0x30
[ 576.903662] [<ffffffff805b9ecd>] __svc_create_thread+0xdd/0x200
[ 576.903662] [<ffffffff80316420>] nfs_callback_svc+0x0/0x130
[ 576.903662] [<ffffffff8020c80e>] child_rip+0x0/0x12
[ 576.903662]
[ 576.903662]
[ 576.903662] Code: 0f 0b eb fe 0f 1f 84 00 00 00 00 00 55 48 8b 16
48 89 e5 e8
[ 576.903662] RIP [<ffffffff803c16e4>] __list_add+0x54/0x60
[ 576.903662] RSP <ffff81007d4e1dc0>
[ 576.903673] ---[ end trace d46de6b99ae8cd5a ]---
[ 576.913664] Kernel panic - not syncing: Aiee, killing interrupt handler!
Torsten
^ permalink raw reply
* Re: [PATCH 3/4] [XFRM]: Kill some bloat
From: Paul Moore @ 2008-01-06 3:25 UTC (permalink / raw)
To: Herbert Xu, Ilpo J??rvinen; +Cc: davem, netdev, acme, latten
In-Reply-To: <E1JBJOR-0000jO-00@gondolin.me.apana.org.au>
On Saturday 05 January 2008 7:29:35 pm Herbert Xu wrote:
> Ilpo J??rvinen <ilpo.jarvinen@helsinki.fi> wrote:
> > Signed-off-by: Ilpo J??rvinen <ilpo.jarvinen@helsinki.fi>
>
> Acked-by: Herbert Xu <herbert@gondor.apana.org.au>
>
> > #ifdef CONFIG_AUDITSYSCALL
> > -static inline void xfrm_audit_helper_sainfo(struct xfrm_state *x,
> > - struct audit_buffer
> > *audit_buf) +static void xfrm_audit_helper_sainfo(struct xfrm_state *x,
> > + struct audit_buffer *audit_buf)
>
> We should never use inline except when it's on the fast path and this
> is definitely not a fast path. If a function ends up being called
> just once the compiler will most likely inline it anyway, making the
> use of the keyword inline redundant.
For the record the inline was there before the audit patch I submitted ...
then again, I suppose I could have removed the inline while I was at it, I
just didn't notice it. Sorry about that.
Thanks for fixing this guys.
--
paul moore
linux security @ hp
^ permalink raw reply
* Re: 2.6.24-rc6-mm1
From: FUJITA Tomonori @ 2008-01-06 3:28 UTC (permalink / raw)
To: akpm
Cc: just.for.lkml, jarkao2, herbert, linux-kernel, neilb, bfields,
netdev, tom, tomof, fujita.tomonori
In-Reply-To: <20080105172524.fecb63bf.akpm@linux-foundation.org>
On Sat, 5 Jan 2008 17:25:24 -0800
Andrew Morton <akpm@linux-foundation.org> wrote:
> On Sat, 5 Jan 2008 23:10:17 +0100 "Torsten Kaiser" <just.for.lkml@googlemail.com> wrote:
>
> > On Jan 5, 2008 3:52 PM, Torsten Kaiser <just.for.lkml@googlemail.com> wrote:
> > > On Jan 5, 2008 11:13 AM, Jarek Poplawski <jarkao2@gmail.com> wrote:
> > > > On Sat, Jan 05, 2008 at 09:01:02AM +0100, Torsten Kaiser wrote:
> > > > > On Jan 5, 2008 1:07 AM, Jarek Poplawski <jarkao2@gmail.com> wrote:
> > > > > > I think it would be easier just to start with this working -rc6 and
> > > > > > simply check if we have 'right' suspects, so: git-net.patch and
> > > > > > git-nfsd.patch from -mm1-broken-out, as suggested by Herbert (I hope,
> > > > > > can compile - otherwise you could try the other way: add the whole -mm
> > > > > > and revert these two). Using current gits could complicate this
> > > > > > "investigation".
> > > > >
> > > > > OK, I will try this...
> > >
> > > still on the todo-list, I had no time to try this yet...
> >
> > working on it...
> > 2.6.24-rc6 + mm-patches up to git.battery (includes git-net and
> > git-netdev-all) worked for 110 packages, then I proclaimed it good.
> > 2.6.24-rc6 + mm-patches up to (including) git.nfsd is currently
> > getting testet (9 packages done...)
> >
> > But the cause of my mail is the following question:
> > Regarding my "iommu-sg-merging-patches are new in -rc3-mm and could be
> > the cause"-suspicion I looked at these patches and came across these
> > hunks:
> >
> > This is removed from arch/x86/lib/bitstr_64.c:
> > -/* Find string of zero bits in a bitmap */
> > -unsigned long
> > -find_next_zero_string(unsigned long *bitmap, long start, long nbits, int len)
> > -{
> > - unsigned long n, end, i;
> > -
> > - again:
> > - n = find_next_zero_bit(bitmap, nbits, start);
> > - if (n == -1)
> > - return -1;
> > -
> > - /* could test bitsliced, but it's hardly worth it */
> > - end = n+len;
> > - if (end > nbits)
> > - return -1;
> > - for (i = n+1; i < end; i++) {
> > - if (test_bit(i, bitmap)) {
> > - start = i+1;
> > - goto again;
> > - }
> > - }
> > - return n;
> > -}
> >
> > This is added to lib/iommu-helper.c:
> > +static unsigned long find_next_zero_area(unsigned long *map,
> > + unsigned long size,
> > + unsigned long start,
> > + unsigned int nr)
> > +{
> > + unsigned long index, end, i;
> > +again:
> > + index = find_next_zero_bit(map, size, start);
> > + end = index + nr;
> > + if (end > size)
> > + return -1;
> > + for (i = index + 1; i < end; i++) {
> > + if (test_bit(i, map)) {
> > + start = i+1;
> > + goto again;
> > + }
> > + }
> > + return index;
> > +}
> >
> > The old version checks, if find_next_zero_bit returns -1, the new
> > version doesn't do this.
> > Is this intended and can find_next_zero_bit never fail?
> > Hmm... but in the worst case it should only loop forever if I'm
> > reading this right (index = -1 => for-loop counts from 0 to nr, if any
> > bit is set it will jump to "again:" and if the next call to
> > find_next_zero_bit also fails, its an endless loop)
find_next_zero_bit returns -1?
It seems that x86_64 doesn't. POWER and SPARC64 IOMMUs use
find_next_zero_bit too but both doesn't check if find_next_zero_bit
returns -1. If find_next_zero_bit fails, it returns size. So it
doesn't leads to an endless loop.
But this patch has other bugs that break POWER IOMMUs.
If you use the IOMMUs on POWER, please try the following patch:
http://www.mail-archive.com/linux-scsi@vger.kernel.org/msg12702.html
>
> I susect these are doing different things.
> iommu-sg-kill-__clear_bit_string-and-find_next_zero_string.patch says:
>
> This kills unused __clear_bit_string and find_next_zero_string (they
> were used by only gart and calgary IOMMUs).
>
> iommu-sg-add-iommu-helper-functions-for-the-free-area-management.patch says:
>
> This adds IOMMU helper functions for the free area management. These
> functions take care of LLD's segment boundary limit for IOMMUs. They
> would be useful for IOMMUs that use bitmap for the free area management.
>
> > So even if this can not explain my bug, could somebody check if this
> > is a real bug or not?
>
> Let's cc the author of those changes.
>
> Thanks for persisting with this bug.
^ permalink raw reply
* Re: Top 10 kernel oopses for the week ending January 5th, 2008
From: Andi Kleen @ 2008-01-06 3:30 UTC (permalink / raw)
To: Arjan van de Ven
Cc: Linux Kernel Mailing List, Linus Torvalds, Andrew Morton, NetDev
In-Reply-To: <477FF149.4070609@linux.intel.com>
Arjan van de Ven <arjan@linux.intel.com> writes:
>
> Rank 4: remove_proc_entry
> Was also ranked 4th last week
> Only in tainted oopses
> Reported 3 times (12 total reports)
> More info: http://www.kerneloops.org/search.php?search=remove_proc_entry
Likely a broken module_exit() function that corrupts the list. To track
these down it might be useful to keep a list of recently unloaded modules
and dump these too in the oops module list with a special flag.
-Andi
^ permalink raw reply
* Re: Top 10 kernel oopses for the week ending January 5th, 2008
From: Arjan van de Ven @ 2008-01-06 3:31 UTC (permalink / raw)
To: Andi Kleen
Cc: Linux Kernel Mailing List, Linus Torvalds, Andrew Morton, NetDev
In-Reply-To: <p733atbr5q4.fsf@bingen.suse.de>
Andi Kleen wrote:
> Arjan van de Ven <arjan@linux.intel.com> writes:
>> Rank 4: remove_proc_entry
>> Was also ranked 4th last week
>> Only in tainted oopses
>> Reported 3 times (12 total reports)
>> More info: http://www.kerneloops.org/search.php?search=remove_proc_entry
>
> Likely a broken module_exit() function that corrupts the list. To track
> these down it might be useful to keep a list of recently unloaded modules
> and dump these too in the oops module list with a special flag.
>
I suspect that simply printing the currently unloading module will catch 90%+ already;
I'll look into adding this, it's a very good idea.
^ permalink raw reply
* Re: Top 10 kernel oopses for the week ending January 5th, 2008
From: Andi Kleen @ 2008-01-06 3:50 UTC (permalink / raw)
To: Arjan van de Ven
Cc: Andi Kleen, Linux Kernel Mailing List, Linus Torvalds,
Andrew Morton, NetDev
In-Reply-To: <47804B91.1050709@linux.intel.com>
On Sat, Jan 05, 2008 at 07:31:29PM -0800, Arjan van de Ven wrote:
> Andi Kleen wrote:
> >Arjan van de Ven <arjan@linux.intel.com> writes:
> >>Rank 4: remove_proc_entry
> >> Was also ranked 4th last week
> >> Only in tainted oopses
> >> Reported 3 times (12 total reports)
> >> More info:
> >> http://www.kerneloops.org/search.php?search=remove_proc_entry
> >
> >Likely a broken module_exit() function that corrupts the list. To track
> >these down it might be useful to keep a list of recently unloaded modules
> >and dump these too in the oops module list with a special flag.
> >
> I suspect that simply printing the currently unloading module will catch
> 90%+ already;
There are a few cases where the corruption is only visible next time
someone accesses the list. So a small ring buffer might make sense.
-Andi
^ permalink raw reply
* [PATCH] Fix regression in ip command line processing
From: Amos Waterland @ 2008-01-06 3:58 UTC (permalink / raw)
To: Simon Horman; +Cc: linux-kernel, netdev, David Miller, akpm
In-Reply-To: <20071226025903.GB14422@verge.net.au>
The recent changes for ip command line processing fixed some problems
but unfortunately broke some common usage scenarios. In current
2.6.24-rc6 the following command line results in no IP address
assignment, which is surely a regression:
ip=10.0.2.15::10.0.2.2:255.255.255.0::eth0:off
Please find below a patch that works for all cases I can find.
Signed-off-by: Amos Waterland <apw@us.ibm.com>
---
For convenience, here are the test cases phrased as qemu invocations:
ADDRESS ASSIGNED
qemu -kernel x86/arch/i386/boot/bzImage /dev/zero -append "ip=on"
qemu -kernel x86/arch/i386/boot/bzImage /dev/zero -append "ip=dhcp"
qemu -kernel x86/arch/i386/boot/bzImage /dev/zero -append "ip=both"
qemu -kernel x86/arch/i386/boot/bzImage /dev/zero -append "ip=any"
qemu -kernel x86/arch/i386/boot/bzImage /dev/zero -append "ip=::::::on"
qemu -kernel x86/arch/i386/boot/bzImage /dev/zero -append "ip=::::::dhcp"
qemu -kernel x86/arch/i386/boot/bzImage /dev/zero -append "ip=10.0.2.15::10.0.2.2:255.255.255.0::eth0:off"
qemu -kernel x86/arch/i386/boot/bzImage /dev/zero -append "ip=10.0.2.15::10.0.2.2:255.255.255.0::eth0:on"
ADDRESS NOT ASSIGNED
qemu -kernel x86/arch/i386/boot/bzImage /dev/zero -append "ip="
qemu -kernel x86/arch/i386/boot/bzImage /dev/zero -append "ip=off"
qemu -kernel x86/arch/i386/boot/bzImage /dev/zero -append "ip=::::::off"
---
Documentation/nfsroot.txt | 1 +
net/ipv4/ipconfig.c | 19 +++++++++++++++----
2 files changed, 16 insertions(+), 4 deletions(-)
diff --git a/Documentation/nfsroot.txt b/Documentation/nfsroot.txt
index c86dd38..1a4d199 100644
--- a/Documentation/nfsroot.txt
+++ b/Documentation/nfsroot.txt
@@ -145,6 +145,7 @@ ip=<client-ip>:<server-ip>:<gw-ip>:<netmask>:<hostname>:<device>:<autoconf>
this option.
off or none: don't use autoconfiguration
+ (do static IP assignment instead)
on or any: use any protocol available in the kernel
(default)
dhcp: use DHCP
diff --git a/net/ipv4/ipconfig.c b/net/ipv4/ipconfig.c
index 56a6757..8563b2e 100644
--- a/net/ipv4/ipconfig.c
+++ b/net/ipv4/ipconfig.c
@@ -1404,8 +1404,7 @@ static int __init ic_proto_name(char *name)
return 1;
}
if (!strcmp(name, "off") || !strcmp(name, "none")) {
- ic_enable = 0;
- return 1;
+ return 0;
}
#ifdef CONFIG_IP_PNP_DHCP
else if (!strcmp(name, "dhcp")) {
@@ -1442,10 +1441,20 @@ static int __init ip_auto_config_setup(char *addrs)
ic_set_manually = 1;
ic_enable = 1;
+ /*
+ * If any dhcp, bootp etc options are set, leave autoconfig on
+ * and skip the below static IP processing.
+ */
if (ic_proto_name(addrs))
return 1;
- /* Parse the whole string */
+ /* If no static IP is given, turn off autoconfig and bail. */
+ if (*addrs == 0 || strcmp(addrs, "off") == 0 || strcmp(addrs, "none") == 0) {
+ ic_enable = 0;
+ return 1;
+ }
+
+ /* Parse string for static IP assignment. */
ip = addrs;
while (ip && *ip) {
if ((cp = strchr(ip, ':')))
@@ -1483,7 +1492,9 @@ static int __init ip_auto_config_setup(char *addrs)
strlcpy(user_dev_name, ip, sizeof(user_dev_name));
break;
case 6:
- ic_proto_name(ip);
+ if (ic_proto_name(ip) == 0 && ic_myaddr == NONE) {
+ ic_enable = 0;
+ }
break;
}
}
^ permalink raw reply related
* Re: sparc oops in ip_fast_csum
From: Herbert Xu @ 2008-01-06 4:14 UTC (permalink / raw)
To: Al Viro
Cc: m.kozlowski, davem, sparclinux, netdev, linux-kernel,
Patrick McHardy
In-Reply-To: <20080106020214.GQ27894@ZenIV.linux.org.uk>
On Sun, Jan 06, 2008 at 02:02:14AM +0000, Al Viro wrote:
>
> E.g. what about ipt_REJECT.c::send_reset()? Or myri10ge_get_frag_header()?
Yes both look wrong.
Patrick, please have a look at the former. In fact it's not just
that ihl may be bogus (which might be harmless as long as the REJECT
hook only gets called from within the IP stack), I think REJECT would
also do the wrong thing if the packet had IP options. So perhaps we
should just make it create a packet from scratch rather than being
too clever in reusing the old one.
As to LRO, I must say it was a pretty shoddy job. Now I can't complain
too much because I wasn't able to spend any time in 2007 working on it.
But it's definitely high on my todo list for 2008.
Oh and Al, your effort in going through all the ip_fast_csum callers
is much appreciated!
Thanks,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: NAPI poll behavior in various Intel drivers
From: David Miller @ 2008-01-06 4:15 UTC (permalink / raw)
To: andi; +Cc: jchapman, netdev, auke-jan.h.kok
In-Reply-To: <p738x348kpq.fsf@bingen.suse.de>
From: Andi Kleen <andi@firstfloor.org>
Date: Sat, 05 Jan 2008 14:29:05 +0100
> In 2.4 we used to have (haven't checked recently) performance regressions
> with NAPI vs non NAPI (or versus the old BCM vendor driver) on tg3 for
> some workloads that didn't fully fill the link. The theory was always
> that the reason for that was something like the regular switching in
> and out. So I think we saw that problem on tg3 too.
It was because we originally didn't program the HW interrupt
mitigation settings at all when using NAPI, now we do and the problem
is long gone.
^ permalink raw reply
* Re: [NETNS]: Should build with CONFIG_SYSCTL=n
From: David Miller @ 2008-01-06 7:09 UTC (permalink / raw)
To: dada1; +Cc: netdev
In-Reply-To: <47800FB4.2040008@cosmosbay.com>
From: Eric Dumazet <dada1@cosmosbay.com>
Date: Sun, 06 Jan 2008 00:16:04 +0100
> [NETNS]: Should build with CONFIG_SYSCTL=n
>
> Previous NETNS patches broke CONFIG_SYSCTL=n case
>
> Signed-off-by: Eric Dumazet <dada1@cosmosbay.com>
Applied, thanks Eric.
^ permalink raw reply
* Re: [PATCH 1/4] [NETFILTER]: Kill some supper dupper bloatry
From: David Miller @ 2008-01-06 7:11 UTC (permalink / raw)
To: ilpo.jarvinen; +Cc: netdev, acme
In-Reply-To: <11995403481730-git-send-email-ilpo.jarvinen@helsinki.fi>
From: "Ilpo_Järvinen" <ilpo.jarvinen@helsinki.fi>
Date: Sat, 5 Jan 2008 15:39:05 +0200
> 10 functions changed, 11017 bytes removed, diff: -11017
...
> 6 functions changed, 2122 bytes added, diff: +2122
Yikes, applied :-)
Thanks Ilpo.
^ permalink raw reply
* Re: [PATCH 2/4] [IPVS]: Kill some bloat
From: David Miller @ 2008-01-06 7:12 UTC (permalink / raw)
To: ilpo.jarvinen; +Cc: netdev, acme
In-Reply-To: <11995403483512-git-send-email-ilpo.jarvinen@helsinki.fi>
From: "Ilpo_Järvinen" <ilpo.jarvinen@helsinki.fi>
Date: Sat, 5 Jan 2008 15:39:06 +0200
> net/ipv4/ipvs/ip_vs_xmit.c:
> ip_vs_icmp_xmit | -638
> ip_vs_tunnel_xmit | -674
> ip_vs_nat_xmit | -716
> ip_vs_dr_xmit | -682
> 4 functions changed, 2710 bytes removed, diff: -2710
>
> net/ipv4/ipvs/ip_vs_xmit.c:
> __ip_vs_get_out_rt | +595
> 1 function changed, 595 bytes added, diff: +595
>
> net/ipv4/ipvs/ip_vs_xmit.o:
> 5 functions changed, 595 bytes added, 2710 bytes removed, diff: -2115
>
> Without some CONFIG.*DEBUGs:
>
> net/ipv4/ipvs/ip_vs_xmit.o:
> 5 functions changed, 383 bytes added, 1513 bytes removed, diff: -1130
>
> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@helsinki.fi>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH 3/4] [XFRM]: Kill some bloat
From: David Miller @ 2008-01-06 7:13 UTC (permalink / raw)
To: ilpo.jarvinen; +Cc: netdev, acme
In-Reply-To: <1199540349385-git-send-email-ilpo.jarvinen@helsinki.fi>
From: "Ilpo_Järvinen" <ilpo.jarvinen@helsinki.fi>
Date: Sat, 5 Jan 2008 15:39:07 +0200
> From: =?ISO-8859-1?q?Ilpo_J=E4rvinen?= <ilpo.jarvinen@helsinki.fi>
>
> net/xfrm/xfrm_state.c:
> xfrm_audit_state_delete | -589
> xfrm_replay_check | -542
> xfrm_audit_state_icvfail | -520
> xfrm_audit_state_add | -589
> xfrm_audit_state_replay_overflow | -523
> xfrm_audit_state_notfound_simple | -509
> xfrm_audit_state_notfound | -521
> 7 functions changed, 3793 bytes removed, diff: -3793
>
> net/xfrm/xfrm_state.c:
> xfrm_audit_helper_pktinfo | +522
> xfrm_audit_helper_sainfo | +598
> 2 functions changed, 1120 bytes added, diff: +1120
>
> net/xfrm/xfrm_state.o:
> 9 functions changed, 1120 bytes added, 3793 bytes removed, diff: -2673
>
> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@helsinki.fi>
Applied.
^ permalink raw reply
* Re: [PATCH 4/4] [CCID3]: Kill some bloat
From: David Miller @ 2008-01-06 7:13 UTC (permalink / raw)
To: ilpo.jarvinen; +Cc: netdev, acme
In-Reply-To: <11995403493735-git-send-email-ilpo.jarvinen@helsinki.fi>
From: "Ilpo_Järvinen" <ilpo.jarvinen@helsinki.fi>
Date: Sat, 5 Jan 2008 15:39:08 +0200
> From: =?ISO-8859-1?q?Ilpo_J=E4rvinen?= <ilpo.jarvinen@helsinki.fi>
>
> Without a number of CONFIG.*DEBUG:
>
> net/dccp/ccids/ccid3.c:
> ccid3_hc_tx_update_x | -170
> ccid3_hc_tx_packet_sent | -175
> ccid3_hc_tx_packet_recv | -169
> ccid3_hc_tx_no_feedback_timer | -192
> ccid3_hc_tx_send_packet | -144
> 5 functions changed, 850 bytes removed, diff: -850
>
> net/dccp/ccids/ccid3.c:
> ccid3_update_send_interval | +191
> 1 function changed, 191 bytes added, diff: +191
>
> net/dccp/ccids/ccid3.o:
> 6 functions changed, 191 bytes added, 850 bytes removed, diff: -659
>
> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@helsinki.fi>
Also applied, thanks.
^ permalink raw reply
* Re: sparc oops in ip_fast_csum
From: David Miller @ 2008-01-06 7:15 UTC (permalink / raw)
To: herbert; +Cc: viro, m.kozlowski, sparclinux, netdev, linux-kernel
In-Reply-To: <E1JBJHA-0000hy-00@gondolin.me.apana.org.au>
From: Herbert Xu <herbert@gondor.apana.org.au>
Date: Sun, 06 Jan 2008 11:22:04 +1100
> [IPV4] raw: Strengthen check on validity of iph->ihl
>
> We currently check that iph->ihl is bounded by the real length and that
> the real length is greater than the minimum IP header length. However,
> we did not check the caes where iph->ihl is less than the minimum IP
> header length.
>
> This breaks because some ip_fast_csum implementations assume that which
> is quite reasonable.
>
> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Applied, I'll push this to -stable too, thanks Herbert.
^ permalink raw reply
* Re: [PATCH 3/4] [XFRM]: Kill some bloat
From: David Miller @ 2008-01-06 7:16 UTC (permalink / raw)
To: herbert; +Cc: ilpo.jarvinen, netdev, acme, paul.moore, latten
In-Reply-To: <E1JBJOR-0000jO-00@gondolin.me.apana.org.au>
From: Herbert Xu <herbert@gondor.apana.org.au>
Date: Sun, 06 Jan 2008 11:29:35 +1100
> We should never use inline except when it's on the fast path and this
> is definitely not a fast path. If a function ends up being called
> just once the compiler will most likely inline it anyway, making the
> use of the keyword inline redundant.
Similarly I question just about any inline usage at all in *.c files
these days.
I even would discourage it's use for fast-path cases as well.
^ permalink raw reply
* Re: [PATCH net-2.6.25] [NET]: Remove obsolete comment
From: David Miller @ 2008-01-06 7:18 UTC (permalink / raw)
To: ilpo.jarvinen; +Cc: netdev
In-Reply-To: <Pine.LNX.4.64.0801051418140.32403@kivilampi-30.cs.helsinki.fi>
From: "Ilpo_Järvinen" <ilpo.jarvinen@helsinki.fi>
Date: Sat, 5 Jan 2008 14:21:48 +0200 (EET)
> [PATCH] [NET]: Remove obsolete comment
>
> It seems that ip_build_xmit is no longer used in here and
> ip_append_data is used.
>
> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@helsinki.fi>
> ---
>
> Hi Dave,
>
> While reading some nearby code, I noticed this. I'm not 100%
> sure if the removal is valid or not nor have interest to dig
> it up from history but I suppose you know it better without
> having to look it up from history :-).
It's definitely obsolete cruft, good catch, applied :-)
^ permalink raw reply
* Re: [PATCH] Fix regression in ip command line processing
From: David Miller @ 2008-01-06 7:20 UTC (permalink / raw)
To: apw; +Cc: horms, linux-kernel, netdev, akpm
In-Reply-To: <20080106035816.GA16459@us.ibm.com>
From: Amos Waterland <apw@us.ibm.com>
Date: Sat, 5 Jan 2008 22:58:16 -0500
> ADDRESS ASSIGNED
>
> qemu -kernel x86/arch/i386/boot/bzImage /dev/zero -append "ip=on"
> qemu -kernel x86/arch/i386/boot/bzImage /dev/zero -append "ip=dhcp"
> qemu -kernel x86/arch/i386/boot/bzImage /dev/zero -append "ip=both"
> qemu -kernel x86/arch/i386/boot/bzImage /dev/zero -append "ip=any"
> qemu -kernel x86/arch/i386/boot/bzImage /dev/zero -append "ip=::::::on"
> qemu -kernel x86/arch/i386/boot/bzImage /dev/zero -append "ip=::::::dhcp"
> qemu -kernel x86/arch/i386/boot/bzImage /dev/zero -append "ip=10.0.2.15::10.0.2.2:255.255.255.0::eth0:off"
> qemu -kernel x86/arch/i386/boot/bzImage /dev/zero -append "ip=10.0.2.15::10.0.2.2:255.255.255.0::eth0:on"
>
> ADDRESS NOT ASSIGNED
>
> qemu -kernel x86/arch/i386/boot/bzImage /dev/zero -append "ip="
> qemu -kernel x86/arch/i386/boot/bzImage /dev/zero -append "ip=off"
> qemu -kernel x86/arch/i386/boot/bzImage /dev/zero -append "ip=::::::off"
I really wish Simon had tested his original patch as extensively
as you have, this is the second major regression it has caused.
:-/
I'll apply your fix, although I'll break up some super long lines
you've added, thanks a lot.
^ permalink raw reply
* Re: [2.6.24 patch] fix netx-eth.c compilation
From: David Miller @ 2008-01-06 7:55 UTC (permalink / raw)
To: adrian.bunk; +Cc: jeff, linux-kernel, netdev
In-Reply-To: <20080105214616.GE22232@does.not.exist>
From: Adrian Bunk <adrian.bunk@movial.fi>
Date: Sat, 5 Jan 2008 23:46:16 +0200
> This was missed when commit e2ac455a18806b31c2d0da0a51d8740af5010b7a
> fixed the compile errors in drivers/net/netx-eth.c caused by
> commit 09f75cd7bf13720738e6a196cc0107ce9a5bd5a0.
>
> Signed-off-by: Adrian Bunk <adrian.bunk@movial.fi>
Applied, thanks Adrian.
^ permalink raw reply
* Re: [PATCH] METH: fix MAC address handling
From: David Miller @ 2008-01-06 8:23 UTC (permalink / raw)
To: tsbogend; +Cc: netdev, linux-mips, ralf, jgarzik
In-Reply-To: <20080105224842.78EDCC2EFB@solo.franken.de>
From: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
Date: Sat, 5 Jan 2008 23:48:42 +0100 (CET)
> meth didn't set a valid mac address during probing, but later during
> open. Newer kernel refuse to open device with 00:00:00:00:00:00 as
> mac address -> dead ethernet. This patch sets the mac address in
> the probe function and uses only the mac address from the netdevice
> struct when setting up the hardware.
>
> Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
Applied, thanks.
> + u64 macaddr;
>
> - for (i = 0; i < 6; i++)
> - dev->dev_addr[i] = o2meth_eaddr[i];
> DPRINTK("Loading MAC Address: %s\n", print_mac(mac, dev->dev_addr));
> - mace->eth.mac_addr = (*(unsigned long*)o2meth_eaddr) >> 16;
> + macaddr = 0;
> + for (i = 0; i < 6; i++)
> + macaddr |= dev->dev_addr[i] << ((5 - i) * 8);
> +
> + mace->eth.mac_addr = macaddr;
> }
>
> /*
Can you double-check that this conversion is equivalent.
I know that this whole driver is full of assumptions about
the endianness of the system this chip is found on, so
I'm only interested in if the transformation is equivalent
and the driver will keep working properly.
Thanks.
^ permalink raw reply
* Re: 2.6.24-rc6-mm1
From: Jarek Poplawski @ 2008-01-06 8:27 UTC (permalink / raw)
To: Torsten Kaiser
Cc: Herbert Xu, Andrew Morton, linux-kernel, Neil Brown,
J. Bruce Fields, netdev, Tom Tucker
In-Reply-To: <64bb37e0801050652t7568e438uf93208601df84ef6@mail.gmail.com>
On Sat, Jan 05, 2008 at 03:52:32PM +0100, Torsten Kaiser wrote:
...
> So my personal conclusion would be, that someone is writing to memory
> that he no longer owns. Most probably 0-bytes. (the complete_routine
> got NULLed and the warning about dst->__refcnt being 0).
>
> Use-after-free or something else?
I agree: your conclusion seems to be the most probable explanation for
this. Then it could be really hard to solve this without bisection or
something similar. But there is some probabability this something could
try kfree later too, but simply this list debugging triggers earlier.
> > > If you think some other slub_debug might catch it, I would try this...
You can try to add "U" to these other slub_debug options. As a matter
of fact, if your above diagnose is right, it seems you risk to damage
your system or even the box with these tests, so if you want to
continue, you should probably turn any possible debugging on (not in
mm only).
BTW, you've written that some debugging options seem to delay the bug.
Since they often change sizes of some structures than such wrong
writes could have some 'safer' offsets. So, this could really delay
e.g. these list's bugs, but maybe this could also let to stay 'alive'
to such wrong kfree?
Cheers,
Jarek P.
^ permalink raw reply
* Re: [PATCH] Fix regression in ip command line processing
From: Simon Horman @ 2008-01-06 9:25 UTC (permalink / raw)
To: David Miller; +Cc: apw, linux-kernel, netdev, akpm
In-Reply-To: <20080105.232033.240181112.davem@davemloft.net>
On Sat, Jan 05, 2008 at 11:20:33PM -0800, David Miller wrote:
> From: Amos Waterland <apw@us.ibm.com>
> Date: Sat, 5 Jan 2008 22:58:16 -0500
>
> > ADDRESS ASSIGNED
> >
> > qemu -kernel x86/arch/i386/boot/bzImage /dev/zero -append "ip=on"
> > qemu -kernel x86/arch/i386/boot/bzImage /dev/zero -append "ip=dhcp"
> > qemu -kernel x86/arch/i386/boot/bzImage /dev/zero -append "ip=both"
> > qemu -kernel x86/arch/i386/boot/bzImage /dev/zero -append "ip=any"
> > qemu -kernel x86/arch/i386/boot/bzImage /dev/zero -append "ip=::::::on"
> > qemu -kernel x86/arch/i386/boot/bzImage /dev/zero -append "ip=::::::dhcp"
> > qemu -kernel x86/arch/i386/boot/bzImage /dev/zero -append "ip=10.0.2.15::10.0.2.2:255.255.255.0::eth0:off"
> > qemu -kernel x86/arch/i386/boot/bzImage /dev/zero -append "ip=10.0.2.15::10.0.2.2:255.255.255.0::eth0:on"
> >
> > ADDRESS NOT ASSIGNED
> >
> > qemu -kernel x86/arch/i386/boot/bzImage /dev/zero -append "ip="
> > qemu -kernel x86/arch/i386/boot/bzImage /dev/zero -append "ip=off"
> > qemu -kernel x86/arch/i386/boot/bzImage /dev/zero -append "ip=::::::off"
>
> I really wish Simon had tested his original patch as extensively
> as you have, this is the second major regression it has caused.
> :-/
Ok, this time around its an issue with my understainding of how things
are supposed to work. But sorry none the less.
--
Horms
^ permalink raw reply
* [PATCH net-2.6.25] [IPV4] Remove unused member of dst_entry
From: Rami Rosen @ 2008-01-06 10:15 UTC (permalink / raw)
To: David Miller; +Cc: netdev
[-- Attachment #1: Type: text/plain, Size: 161 bytes --]
Hi,
The info placeholder member of dst_entry seems to be unused in the
network stack.
Regards,
Rami Rosen
Signed-off-by: Rami Rosen <ramirose@gmail.com>
[-- Attachment #2: patch.txt --]
[-- Type: text/plain, Size: 257 bytes --]
diff --git a/include/net/dst.h b/include/net/dst.h
index 31468c9..e03ea0c 100644
--- a/include/net/dst.h
+++ b/include/net/dst.h
@@ -80,7 +80,6 @@ struct dst_entry
struct rt6_info *rt6_next;
struct dn_route *dn_next;
};
- char info[0];
};
^ permalink raw reply related
* Re: 2.6.24-rc6-mm1
From: Torsten Kaiser @ 2008-01-06 10:30 UTC (permalink / raw)
To: Jarek Poplawski
Cc: Herbert Xu, Andrew Morton, linux-kernel, Neil Brown,
J. Bruce Fields, netdev, Tom Tucker
In-Reply-To: <20080106082740.GA3117@ami.dom.local>
On Jan 6, 2008 9:27 AM, Jarek Poplawski <jarkao2@gmail.com> wrote:
> On Sat, Jan 05, 2008 at 03:52:32PM +0100, Torsten Kaiser wrote:
> ...
> > So my personal conclusion would be, that someone is writing to memory
> > that he no longer owns. Most probably 0-bytes. (the complete_routine
> > got NULLed and the warning about dst->__refcnt being 0).
> >
> > Use-after-free or something else?
>
> I agree: your conclusion seems to be the most probable explanation for
> this. Then it could be really hard to solve this without bisection or
> something similar. But there is some probabability this something could
> try kfree later too, but simply this list debugging triggers earlier.
As for example in the case when it dies in ieee1394-thread the list is
so corrupted that it will die anyway.
But I might try this anyway, as I don't really have a better idee.
> > > > If you think some other slub_debug might catch it, I would try this...
>
> You can try to add "U" to these other slub_debug options. As a matter
> of fact, if your above diagnose is right, it seems you risk to damage
> your system or even the box with these tests, so if you want to
> continue, you should probably turn any possible debugging on (not in
> mm only).
I did not add U, because I thought that would only needed to trace memory leaks.
And I hoped that using P (poison) would catch any later use (after free).
> BTW, you've written that some debugging options seem to delay the bug.
> Since they often change sizes of some structures than such wrong
> writes could have some 'safer' offsets. So, this could really delay
> e.g. these list's bugs, but maybe this could also let to stay 'alive'
> to such wrong kfree?
I think this bug is highly timing dependent. Its not always the same
package that dies and as this is a SMP system I would guess two CPUs
using the same data will trigger this.
And using the poison-option will definitily slow the system down and
mess up the timings.
What also speaks against the 'safer' offsets is, that after adding my
notfreed-byte to skbuff the bug still triggered in the same way.
I'm currently looking at
http://www.mail-archive.com/linux-scsi@vger.kernel.org/msg12702.html
,trying to understand if this is relevant for me on x86_64.
Torsten
^ permalink raw reply
* Re: 2.6.24-rc6-mm1
From: Torsten Kaiser @ 2008-01-06 10:41 UTC (permalink / raw)
To: FUJITA Tomonori
Cc: akpm, jarkao2, herbert, linux-kernel, neilb, bfields, netdev, tom,
fujita.tomonori
In-Reply-To: <20080106123103K.tomof@acm.org>
On Jan 6, 2008 4:28 AM, FUJITA Tomonori <tomof@acm.org> wrote:
> On Sat, 5 Jan 2008 17:25:24 -0800
> Andrew Morton <akpm@linux-foundation.org> wrote:
> > On Sat, 5 Jan 2008 23:10:17 +0100 "Torsten Kaiser" <just.for.lkml@googlemail.com> wrote:
> > > But the cause of my mail is the following question:
> > > Regarding my "iommu-sg-merging-patches are new in -rc3-mm and could be
> > > the cause"-suspicion I looked at these patches and came across these
> > > hunks:
> > >
> > > This is removed from arch/x86/lib/bitstr_64.c:
> > > -/* Find string of zero bits in a bitmap */
> > > -unsigned long
> > > -find_next_zero_string(unsigned long *bitmap, long start, long nbits, int len)
> > > -{
> > > - unsigned long n, end, i;
> > > -
> > > - again:
> > > - n = find_next_zero_bit(bitmap, nbits, start);
> > > - if (n == -1)
> > > - return -1;
> > > -
> > > - /* could test bitsliced, but it's hardly worth it */
> > > - end = n+len;
> > > - if (end > nbits)
> > > - return -1;
> > > - for (i = n+1; i < end; i++) {
> > > - if (test_bit(i, bitmap)) {
> > > - start = i+1;
> > > - goto again;
> > > - }
> > > - }
> > > - return n;
> > > -}
> > >
> > > This is added to lib/iommu-helper.c:
> > > +static unsigned long find_next_zero_area(unsigned long *map,
> > > + unsigned long size,
> > > + unsigned long start,
> > > + unsigned int nr)
> > > +{
> > > + unsigned long index, end, i;
> > > +again:
> > > + index = find_next_zero_bit(map, size, start);
> > > + end = index + nr;
> > > + if (end > size)
> > > + return -1;
> > > + for (i = index + 1; i < end; i++) {
> > > + if (test_bit(i, map)) {
> > > + start = i+1;
> > > + goto again;
> > > + }
> > > + }
> > > + return index;
> > > +}
> > >
> > > The old version checks, if find_next_zero_bit returns -1, the new
> > > version doesn't do this.
> > > Is this intended and can find_next_zero_bit never fail?
> > > Hmm... but in the worst case it should only loop forever if I'm
> > > reading this right (index = -1 => for-loop counts from 0 to nr, if any
> > > bit is set it will jump to "again:" and if the next call to
> > > find_next_zero_bit also fails, its an endless loop)
>
> find_next_zero_bit returns -1?
>
> It seems that x86_64 doesn't.
I'm sorry. I didn't look into find_next_zero_bit, I only noted that
the old version did check for -1 and the new one didn't.
Obviously the old check was superfluous.
> POWER and SPARC64 IOMMUs use
> find_next_zero_bit too but both doesn't check if find_next_zero_bit
> returns -1. If find_next_zero_bit fails, it returns size. So it
> doesn't leads to an endless loop.
Yes, this can't happen. It was a wrong assumption on my part.
> But this patch has other bugs that break POWER IOMMUs.
>
> If you use the IOMMUs on POWER, please try the following patch:
I'm using CONFIG_GART_IOMMU=y on x86_64.
> http://www.mail-archive.com/linux-scsi@vger.kernel.org/msg12702.html
I also noted the line "index = (index + align_mask) & ~align_mask;" in
iommu_area_alloc() and didn't understand what this was trying to do
and how this should work, but as arch/x86/kernel/pci-gart_64.c always
uses 0 as align_mask I just ignored it.
I will applie your patch and see if this hunk from
find_next_zero_area() makes a difference:
end = index + nr;
- if (end > size)
+ if (end >= size)
return -1;
- for (i = index + 1; i < end; i++) {
+ for (i = index; i < end; i++) {
if (test_bit(i, map)) {
Torsten
^ 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