Re: Oops with touch and unknown uid [was Re: 2.6.22-rc6-mm1]
On Sun, 22 Jul 2007 23:48:14 +0200 "J.A. Magallón" <[EMAIL PROTECTED]> wrote:
> On Thu, 28 Jun 2007 03:43:21 -0700, Andrew Morton <[EMAIL PROTECTED]> wrote:
>
> >
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.22-rc6/2.6.22-rc6-mm1/
> >
>
> I have noticed a funny problem.
> Lets say 666 is not an uid used on you system. This oopses:
>
> rm -f dummy
> touch dummy
> chown 666 dummy
> touch dummy
Does Linus's fix fix it?
commit 1e5de2837c166535f9bb4232bfe97ea1f9fc7a1c
Author: Linus Torvalds <[EMAIL PROTECTED]>
Date: Sun Jul 8 12:02:55 2007 -0700
Fix permission checking for the new utimensat() system call
Commit 1c710c896eb461895d3c399e15bb5f20b39c9073 added the utimensat()
system call, but didn't handle the case of checking for the writability
of the target right, when the target was a file descriptor, not a
filename.
We cannot use vfs_permission(MAY_WRITE) for that case, and need to
simply check whether the file descriptor is writable. The oops from
using the wrong function was noticed and narrowed down by Markus
Trippelsdorf.
Cc: Ulrich Drepper <[EMAIL PROTECTED]>
Cc: Markus Trippelsdorf <[EMAIL PROTECTED]>
Cc: Andrew Morton <[EMAIL PROTECTED]>
Acked-by: Al Viro <[EMAIL PROTECTED]>
Signed-off-by: Linus Torvalds <[EMAIL PROTECTED]>
diff --git a/fs/utimes.c b/fs/utimes.c
index 480f7c8..b3c8895 100644
--- a/fs/utimes.c
+++ b/fs/utimes.c
@@ -106,9 +106,16 @@ long do_utimes(int dfd, char __user *fil
if (IS_IMMUTABLE(inode))
goto dput_and_out;
- if (current->fsuid != inode->i_uid &&
- (error = vfs_permission(&nd, MAY_WRITE)) != 0)
- goto dput_and_out;
+ if (current->fsuid != inode->i_uid) {
+ if (f) {
+ if (!(f->f_mode & FMODE_WRITE))
+ goto dput_and_out;
+ } else {
+ error = vfs_permission(&nd, MAY_WRITE);
+ if (error)
+ goto dput_and_out;
+ }
+ }
}
mutex_lock(&inode->i_mutex);
error = notify_change(dentry, &newattrs);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Oops with touch and unknown uid [was Re: 2.6.22-rc6-mm1]
On Sun, 22 Jul 2007 23:48:14 +0200 J.A. Magallón wrote: > On Thu, 28 Jun 2007 03:43:21 -0700, Andrew Morton <[EMAIL PROTECTED]> wrote: > > > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.22-rc6/2.6.22-rc6-mm1/ > > so is this 2.6.22-rc6-mm1 or is it as Oops says: 2.6.21-jam12 ? I tested 2.6.22-rc6-mm1 and couldn't reproduce this. Maybe your .config file would help. > I have noticed a funny problem. > Lets say 666 is not an uid used on you system. This oopses: > > rm -f dummy > touch dummy > chown 666 dummy > touch dummy > > Oops: > > BUG: unable to handle kernel NULL pointer dereference at virtual address > 006a > printing eip: > c0165281 > *pde = > Oops: [#2] > PREEMPT SMP > Modules linked in: w83627hf hwmon_vid hwmon i2c_dev loop floppy udf microcode > snd_emu10k1 snd_rawmidi snd_ac97_codec ac97_bus snd_pcm nvidia(P) snd_timer > 3c59x snd_page_alloc snd_util_mem snd_hwdep snd usblp ohci1394 e1000 ieee1394 > sata_promise emu10k1_gp gameport intel_agp i2c_i801 agpgart evdev sg > CPU:3 > EIP:0060:[]Tainted: P D VLI > EFLAGS: 00210297 (2.6.21-jam12 #1) > EIP is at permission+0x4/0xa1 > eax: ebx: c5785aa0 ecx: c43a1f04 edx: 0002 > esi: edi: ebp: c3442c00 esp: c43a1ef0 > ds: 007b es: 007b fs: 00d8 gs: 0033 ss: 0068 > Process touch (pid: 8401, ti=c43a1000 task=c25d69b0 task.ti=c43a1000) > Stack: c5785aa0 fff3 c017ba84 c43e9c50 c55c52a8 c43e9c50 c344ab7c > 00c9 > c3442c00 b7f14f70 c4f574d0 c2ea5400 > c03ef580 > 0004 b7f14f70 c0125cac > c4f574d0 > Call Trace: > [] do_utimes+0x174/0x1b9 > [] __atomic_notifier_call_chain+0x27/0x4d > [] do_page_fault+0x523/0x68d > [] sys_utimensat+0x22/0x92 > [] do_page_fault+0x0/0x68d > [] sysenter_past_esp+0x5f/0x85 > [] packet_setsockopt+0x279/0x325 > === > Code: eb b1 66 c1 ee 06 8d 74 26 00 eb 8c 83 e7 02 75 c5 b8 02 00 00 00 8d 74 > 26 00 e8 16 bf fb ff 85 c0 74 b3 31 c0 eb c9 56 53 89 c6 <0f> b7 58 6a f6 c2 > 02 74 31 8b 80 a4 00 00 00 f6 40 30 01 74 1c > EIP: [] permission+0x4/0xa1 SS:ESP 0068:c43a1ef0 > > Any ideas ? --- ~Randy *** Remember to use Documentation/SubmitChecklist when testing your code *** - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Oops with touch and unknown uid [was Re: 2.6.22-rc6-mm1]
On Thu, 28 Jun 2007 03:43:21 -0700, Andrew Morton <[EMAIL PROTECTED]> wrote:
>
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.22-rc6/2.6.22-rc6-mm1/
>
I have noticed a funny problem.
Lets say 666 is not an uid used on you system. This oopses:
rm -f dummy
touch dummy
chown 666 dummy
touch dummy
Oops:
BUG: unable to handle kernel NULL pointer dereference at virtual address
006a
printing eip:
c0165281
*pde =
Oops: [#2]
PREEMPT SMP
Modules linked in: w83627hf hwmon_vid hwmon i2c_dev loop floppy udf microcode
snd_emu10k1 snd_rawmidi snd_ac97_codec ac97_bus snd_pcm nvidia(P) snd_timer
3c59x snd_page_alloc snd_util_mem snd_hwdep snd usblp ohci1394 e1000 ieee1394
sata_promise emu10k1_gp gameport intel_agp i2c_i801 agpgart evdev sg
CPU:3
EIP:0060:[]Tainted: P D VLI
EFLAGS: 00210297 (2.6.21-jam12 #1)
EIP is at permission+0x4/0xa1
eax: ebx: c5785aa0 ecx: c43a1f04 edx: 0002
esi: edi: ebp: c3442c00 esp: c43a1ef0
ds: 007b es: 007b fs: 00d8 gs: 0033 ss: 0068
Process touch (pid: 8401, ti=c43a1000 task=c25d69b0 task.ti=c43a1000)
Stack: c5785aa0 fff3 c017ba84 c43e9c50 c55c52a8 c43e9c50 c344ab7c 00c9
c3442c00 b7f14f70 c4f574d0 c2ea5400 c03ef580
0004 b7f14f70 c0125cac c4f574d0
Call Trace:
[] do_utimes+0x174/0x1b9
[] __atomic_notifier_call_chain+0x27/0x4d
[] do_page_fault+0x523/0x68d
[] sys_utimensat+0x22/0x92
[] do_page_fault+0x0/0x68d
[] sysenter_past_esp+0x5f/0x85
[] packet_setsockopt+0x279/0x325
===
Code: eb b1 66 c1 ee 06 8d 74 26 00 eb 8c 83 e7 02 75 c5 b8 02 00 00 00 8d 74
26 00 e8 16 bf fb ff 85 c0 74 b3 31 c0 eb c9 56 53 89 c6 <0f> b7 58 6a f6 c2 02
74 31 8b 80 a4 00 00 00 f6 40 30 01 74 1c
EIP: [] permission+0x4/0xa1 SS:ESP 0068:c43a1ef0
Any ideas ?
--
J.A. Magallon \ Software is like sex:
\ It's better when it's free
Mandriva Linux release 2008.0 (Cooker) for i586
Linux 2.6.21-jam12 (gcc 4.2.1 20070704 (4.2.1-3mdv2008.0)) SMP PREEMPT
09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.22-rc6-mm1
On Sat, 2007-07-14 at 02:07 -0700, Andrew Morton wrote:
> + if (0 && (id & HPET_ID_LEGSUP)) {
> hpet_enable_int();
> hpet_reserve_platform_timers(id);
> /*
> _
>
> will, if executed (on x86_64, at least), instaoops the machine. It might
> take down i386 as well, dunno.
>
> I'd forgotten about this problem, and it seems that Thomas & John have too.
> It's a showstopper.
No, I have not. I found and solved the problem. Updates to the x8664
hrtimer queue are going out tomorrow.
tglx
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.22-rc6-mm1
On Sat, 14 Jul 2007 01:22:10 -0600 Robert Hancock <[EMAIL PROTECTED]> wrote:
> Andrew Morton wrote:
> > +x86_64-dynticks-disable-hpet_id_legsup-hpets.patch
> >
> > pretend to fix it
>
> I'm not sure what this patch does on x86_64, but it seems like it
> trashes all HPET support on i386?
>
It might do, if your i386 is old and has the HPET_ID_LEGSUP bit set.
The code path which that patch disables:
--- a/arch/i386/kernel/hpet.c~x86_64-dynticks-disable-hpet_id_legsup-hpets
+++ a/arch/i386/kernel/hpet.c
@@ -376,7 +376,7 @@ int __init hpet_enable(void)
clocksource_register(&clocksource_hpet);
- if (id & HPET_ID_LEGSUP) {
+ if (0 && (id & HPET_ID_LEGSUP)) {
hpet_enable_int();
hpet_reserve_platform_timers(id);
/*
_
will, if executed (on x86_64, at least), instaoops the machine. It might
take down i386 as well, dunno.
I'd forgotten about this problem, and it seems that Thomas & John have too.
It's a showstopper.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.22-rc6-mm1
Andrew Morton wrote: +x86_64-dynticks-disable-hpet_id_legsup-hpets.patch pretend to fix it I'm not sure what this patch does on x86_64, but it seems like it trashes all HPET support on i386? -- Robert Hancock Saskatoon, SK, Canada To email, remove "nospam" from [EMAIL PROTECTED] Home Page: http://www.roberthancock.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.22-rc6-mm1
On 6/28/07, Andrew Morton <[EMAIL PROTECTED]> wrote: ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.22-rc6/2.6.22-rc6-mm1/ - NOTE (an uppercase one, indeed): there are a lot of menuconfig changes in here which break `make oldconfig' badly. If you grab an old .config and run `make oldconfig', your kernel probably won't work. I lost useful things like CONFIG_BLK_DEV and the whole SCSI system, because they were added after I generated my .config. So save yourself some hassle and check your .config carefully before building this kernel. Make sure that everything you need is still enabled. I found that manually adding "CONFIG_BLK_DEV=y" to the .config before running oldconfig saved a large number of config items from getting lost. On the one ppc64 machine I have to test on for memoryless nodes, I found I had to add back in CONFIG_BLK_DEV=y and CONFIG_SCSI_LOWLEVEL=y. Just for reference as other folks pull out their hair. Those menuconfig changes have been a huge pain. Yes. Thanks, Nish - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.22-rc6-mm1 reiser4_tree_by_page NULL pointer
On Thu, 2007-07-12 at 14:31 -0600, Zan Lynx wrote: > Edward Shishkin wrote: > > > > I have found the bug, which kills data > > when booting after crash, power loss, etc. > > The patch is attached. > > Please, ping me, if it doesn't help.. > > It appears to be holding up well so far. About 5 hours of Gentoo > updating and compiling. Maybe it isn't fixed so well at that. I got one of these today, here is the dmesg (at the bottom): Linux version 2.6.22-rc6-mm1 ([EMAIL PROTECTED]) (gcc version 4.2.0 (Gentoo 4.2.0)) #4 SMP PREEMPT Wed Jul 11 23:22:08 MDT 2007 Command line: root=/dev/sda2 rootfstype=reiser4 ro i8042.nomux elevator=anticipatory resume=/dev/sda3 panic=5 nmi_watchdog=2,panic debug kernelcore=384M BIOS-provided physical RAM map: BIOS-e820: - 0009f800 (usable) BIOS-e820: 0009f800 - 000a (reserved) BIOS-e820: 000d - 0010 (reserved) BIOS-e820: 0010 - 3ff7 (usable) BIOS-e820: 3ff7 - 3ff7f000 (ACPI data) BIOS-e820: 3ff7f000 - 3ff8 (ACPI NVS) BIOS-e820: 3ff8 - 4000 (reserved) BIOS-e820: fff8 - 0001 (reserved) Entering add_active_range(0, 0, 159) 0 entries of 256 used Entering add_active_range(0, 256, 262000) 1 entries of 256 used end_pfn_map = 1048576 DMI present. ACPI: RSDP 000F7240, 0014 (r0 PTLTD ) ACPI: RSDT 3FF7A87E, 0034 (r1 PTLTDRSDT604 LTP0) ACPI: FACP 3FF7EE13, 0074 (r1 NVIDIA CK8 604 PTL_F4240) ACPI: DSDT 3FF7A8B2, 4561 (r1 NVIDIA CK8 604 MSFT 10E) ACPI: FACS 3FF7FFC0, 0040 ACPI: APIC 3FF7EE87, 005A (r1 NVIDIA NV_APIC_ 604 LTP0) ACPI: BOOT 3FF7EEE1, 0028 (r1 PTLTD $SBFTBL$ 604 LTP1) ACPI: SSDT 3FF7EF09, 00F7 (r1 PTLTD POWERNOW 604 LTP1) Entering add_active_range(0, 0, 159) 0 entries of 256 used Entering add_active_range(0, 256, 262000) 1 entries of 256 used No mptable found. sizeof(struct page) = 88 Zone PFN ranges: DMA 0 -> 4096 DMA324096 -> 1048576 Normal1048576 -> 1048576 Movable zone start PFN for each node Node 0: 99328 early_node_map[2] active PFN ranges 0:0 -> 159 0: 256 -> 262000 On node 0 totalpages: 261903 Node 0 memmap at 0x81000100 size 23068672 first pfn 0x81000100 DMA zone: 88 pages used for memmap DMA zone: 2784 pages reserved DMA zone: 1127 pages, LIFO batch:0 DMA32 zone: 2046 pages used for memmap DMA32 zone: 93186 pages, LIFO batch:31 Normal zone: 0 pages used for memmap Movable zone: 3494 pages used for memmap Movable zone: 159178 pages, LIFO batch:31 Nvidia board detected. Ignoring ACPI timer override. If you got timer trouble try acpi_use_timer_override ACPI: PM-Timer IO Port: 0x8008 ACPI: Local APIC address 0xfee0 ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled) Processor #0 (Bootup-CPU) ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1]) ACPI: IOAPIC (id[0x02] address[0xfec0] gsi_base[0]) IOAPIC[0]: apic_id 2, address 0xfec0, GSI 0-23 ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 low level) ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) ACPI: BIOS IRQ0 pin2 override ignored. ACPI: IRQ9 used by override. Setting APIC routing to flat Using ACPI (MADT) for SMP configuration information swsusp: Registered nosave memory region: 0009f000 - 000a swsusp: Registered nosave memory region: 000a - 000d swsusp: Registered nosave memory region: 000d - 0010 Allocating PCI resources starting at 5000 (gap: 4000:bff8) SMP: Allowing 1 CPUs, 0 hotplug CPUs PERCPU: Allocating 33144 bytes of per cpu data Built 1 zonelists in Zone order, mobility grouping on. Total pages: 253491 Kernel command line: root=/dev/sda2 rootfstype=reiser4 ro i8042.nomux elevator=anticipatory resume=/dev/sda3 panic=5 nmi_watchdog=2,panic debug kernelcore=384M Initializing CPU#0 PID hash table entries: 4096 (order: 12, 32768 bytes) TSC calibrated against PM_TIMER time.c: Detected 797.942 MHz processor. Console: colour VGA+ 80x25 console [tty0] enabled Lock dependency validator: Copyright (c) 2006 Red Hat, Inc., Ingo Molnar ... MAX_LOCKDEP_SUBCLASSES:8 ... MAX_LOCK_DEPTH: 30 ... MAX_LOCKDEP_KEYS:2048 ... CLASSHASH_SIZE: 1024 ... MAX_LOCKDEP_ENTRIES: 8192 ... MAX_LOCKDEP_CHAINS: 16384 ... CHAINHASH_SIZE: 8192 memory used by lock dependency info: 1648 kB per task-struct memory footprint: 1680 bytes | Locking API testsuite: | spin |wlock |rlock |mutex | wsem | rsem | -- A-A deadlock: ok | ok | ok | ok | ok | ok | A-B-B-A deadlock:
Re: 2.6.22-rc6-mm1 -- BUG - EIP: [] sysfs_addrm_finish+0x1c2/0x226 SS:ESP 0068:c5ff9db8
Miles Lane wrote: > Tejun, > > I tried 2.6.22-rc6-mm1 + your latest patch, and it failed to boot. > Unfortunately, the machine limped along and am unable to capture > the initial BUG or OOPS. I'll try to get a serial connection set up for > debugging tomorrow, but I am very busy with other stuff. It would be > great if you could test your own build with the .config file I initially > sent > to you for the original BUG: issue. If you would like me to resend the > .config, just let me know. Hmmm... I did test with your .config before posting the updated patch and I just tested again. It runs well on my ICH9 box. I'm sorry but I'll need to see the oops. Thanks a lot. -- tejun - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.22-rc6-mm1 reiser4_tree_by_page NULL pointer
Edward Shishkin wrote: I have found the bug, which kills data when booting after crash, power loss, etc. The patch is attached. Please, ping me, if it doesn't help.. It appears to be holding up well so far. About 5 hours of Gentoo updating and compiling. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.22-rc6-mm1 -- BUG - EIP: [] sysfs_addrm_finish+0x1c2/0x226 SS:ESP 0068:c5ff9db8
Tejun, I tried 2.6.22-rc6-mm1 + your latest patch, and it failed to boot. Unfortunately, the machine limped along and am unable to capture the initial BUG or OOPS. I'll try to get a serial connection set up for debugging tomorrow, but I am very busy with other stuff. It would be great if you could test your own build with the .config file I initially sent to you for the original BUG: issue. If you would like me to resend the .config, just let me know. Miles On 7/11/07, Tejun Heo <[EMAIL PROTECTED]> wrote: Miles Lane wrote: > Does this patch replace or add to the last patch you sent me? > I'll try applying them with --dry-run and assume that if #1 + #2 > doesn't apply cleanly, then you only want me to test with this > latest patch. This replaces the old one. Just revert the old one and apply this one. > I'll be able to test this later this evening. I've had house guests and > so haven't been available the last few days. Yeap, I'll wait for the result. Thanks a lot. -- tejun - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.22-rc6-mm1 -- BUG - EIP: [] sysfs_addrm_finish+0x1c2/0x226 SS:ESP 0068:c5ff9db8
Miles Lane wrote: > Does this patch replace or add to the last patch you sent me? > I'll try applying them with --dry-run and assume that if #1 + #2 > doesn't apply cleanly, then you only want me to test with this > latest patch. This replaces the old one. Just revert the old one and apply this one. > I'll be able to test this later this evening. I've had house guests and > so haven't been available the last few days. Yeap, I'll wait for the result. Thanks a lot. -- tejun - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.22-rc6-mm1 -- BUG - EIP: [] sysfs_addrm_finish+0x1c2/0x226 SS:ESP 0068:c5ff9db8
On 7/11/07, Tejun Heo <[EMAIL PROTECTED]> wrote:
Tejun Heo wrote:
> Miles Lane wrote:
>>> Thanks a lot. Just in case, if you remove the patch (patch -R -p1), the
>>> oops goes away, right?
>> I double-checked. I can boot fine after building without your patch.
>> Also, I reproduced the initial BUG I reported (triggered by
>> "modprobe -r ipw2200").
>
> This is creepy. I was able to reproduce the oops here with your
> configuration file and making buffers for kallsyms static solved the
> problem. It isn't stack overflow. At maximum those arrays added 254
> bytes to the stack and when the oops occurs stack area was left more
> than enough. I'll keep looking into why that happened but the attached
> patch should get us going on the original subject.
Alright, found out what was going on. KSYM_NAME_LEN doesn't include
space for the trailing '\0'. Gees, I've read enough assembly for the
month to find that out. Anyways, here's proper debug patch.
Thanks.
--
tejun
---
fs/sysfs/dir.c| 43 +++
fs/sysfs/sysfs.h | 16 ++--
include/linux/sysfs.h |3 +++
net/core/net-sysfs.c |6 +-
4 files changed, 53 insertions(+), 15 deletions(-)
Index: tree0/fs/sysfs/dir.c
===
--- tree0.orig/fs/sysfs/dir.c
+++ tree0/fs/sysfs/dir.c
@@ -11,15 +11,52 @@
#include
#include
#include
+#include
#include
#include "sysfs.h"
+struct kobject *sysfs_debug_me;
+
DEFINE_MUTEX(sysfs_mutex);
spinlock_t sysfs_assoc_lock = SPIN_LOCK_UNLOCKED;
static spinlock_t sysfs_ino_lock = SPIN_LOCK_UNLOCKED;
static DEFINE_IDA(sysfs_ino_ida);
+struct sysfs_dirent * sysfs_get(struct sysfs_dirent * sd)
+{
+ if (sd) {
+ if (sd->s_flags & SYSFS_FLAG_XXX) {
+ char c0[KSYM_NAME_LEN + 1], c1[KSYM_NAME_LEN + 1];
+
+ lookup_symbol_name((unsigned
long)__builtin_return_address(0), c0);
+ lookup_symbol_name((unsigned
long)__builtin_return_address(1), c1);
+
+ printk("sysfs_get(%s): cnt=%d++ called from %s:%s\n",
+ sd->s_name, atomic_read(&sd->s_count), c0, c1);
+ }
+ WARN_ON(!atomic_read(&sd->s_count));
+ atomic_inc(&sd->s_count);
+ }
+ return sd;
+}
+
+void sysfs_put(struct sysfs_dirent * sd)
+{
+ if (sd && sd->s_flags & SYSFS_FLAG_XXX) {
+ char c0[KSYM_NAME_LEN + 1], c1[KSYM_NAME_LEN + 1];
+
+ lookup_symbol_name((unsigned long)__builtin_return_address(0),
c0);
+ lookup_symbol_name((unsigned long)__builtin_return_address(1),
c1);
+
+ printk("sysfs_put(%s): cnt=%d-- called from %s:%s\n",
+ sd->s_name, atomic_read(&sd->s_count), c0, c1);
+ }
+
+ if (sd && atomic_dec_and_test(&sd->s_count))
+ release_sysfs_dirent(sd);
+}
+
/**
* sysfs_link_sibling - link sysfs_dirent into sibling list
* @sd: sysfs_dirent of interest
@@ -317,6 +354,10 @@ void release_sysfs_dirent(struct sysfs_d
* sd->s_parent won't change beneath us.
*/
parent_sd = sd->s_parent;
+ if (parent_sd->s_flags & SYSFS_FLAG_XXX)
+ printk("put from release(%s): cnt=%d-- (rel=%s)\n",
+ parent_sd->s_name, atomic_read(&parent_sd->s_count),
+ sd->s_name);
if (sysfs_type(sd) == SYSFS_KOBJ_LINK)
sysfs_put(sd->s_elem.symlink.target_sd);
@@ -695,6 +736,8 @@ static int create_dir(struct kobject *ko
if (!sd)
return -ENOMEM;
sd->s_elem.dir.kobj = kobj;
+ if (sysfs_debug_me && sysfs_debug_me == kobj)
+ sd->s_flags |= SYSFS_FLAG_XXX;
/* link in */
sysfs_addrm_start(&acxt, parent_sd);
Index: tree0/fs/sysfs/sysfs.h
===
--- tree0.orig/fs/sysfs/sysfs.h
+++ tree0/fs/sysfs/sysfs.h
@@ -108,20 +108,8 @@ static inline unsigned int sysfs_type(st
return sd->s_flags & SYSFS_TYPE_MASK;
}
-static inline struct sysfs_dirent * sysfs_get(struct sysfs_dirent * sd)
-{
- if (sd) {
- WARN_ON(!atomic_read(&sd->s_count));
- atomic_inc(&sd->s_count);
- }
- return sd;
-}
-
-static inline void sysfs_put(struct sysfs_dirent * sd)
-{
- if (sd && atomic_dec_and_test(&sd->s_count))
- release_sysfs_dirent(sd);
-}
+struct sysfs_dirent * sysfs_get(struct sysfs_dirent * sd);
+void sysfs_put(struct sysfs_dirent * sd);
static inline int sysfs_is_shadowed_inode(struct inode *inode)
{
Index: tree0/include/linux/sysfs.h
===
--- tree0.orig/include/linux/sysfs.h
+++ tree0/include/linux/sysfs.h
@@ -87,9 +87,12 @@ struct sysfs_ops {
#define SYSFS_FLAG_MASK~SYSFS_TYPE_MASK
#define SYSFS_FLA
Re: 2.6.22-rc6-mm1 reiser4_tree_by_page NULL pointer
I have found the bug, which kills data
when booting after crash, power loss, etc.
The patch is attached.
Please, ping me, if it doesn't help..
Thanks,
Edward.
Zan Lynx wrote:
This bug is annoying enough that I mostly stopped using rc6-mm1, which
is why it took this long to make a report. Previous crashes were
tainted.
I recall seeing something about page table problems with this rc6-mm1
but I don't know if that's what happened to me.
System highlights are: x86_64, SLUB, Reiser4, ZONE_MOVABLE
(kernelcore=384M), PATA with libata.
So here it is:
netconsole: network logging started
eth0: no IPv6 routers present
Hangcheck: hangcheck value past margin!
ISO 9660 Extensions: Microsoft Joliet Level 3
ISO 9660 Extensions: RRIP_1991A
Hangcheck: hangcheck value past margin!
Hangcheck: hangcheck value past margin!
Hangcheck: hangcheck value past margin!
Hangcheck: hangcheck value past margin!
Hangcheck: hangcheck value past margin!
Unable to handle kernel NULL pointer dereference at RIP:
[] reiser4_tree_by_page+0x4/0x20
PGD 9a69067 PUD 9a57067 PMD 0
Oops: [1] PREEMPT SMP
CPU 0
Modules linked in: nls_iso8859_1 isofs nls_base netconsole usbhid hid snd_pcm_oss snd_mixer_oss ipv6 snd_intel8x0 snd_ac97_codec ac97_bus snd_pcm snd_timer snd snd_page_alloc ehci_hcd ohci_hcd usbcore evdev psmouse serio_raw sg
Pid: 10479, comm: rhythmbox Not tainted 2.6.22-rc6-mm1 #3
RIP: 0010:[] []
reiser4_tree_by_page+0x4/0x20
RSP: 0018:810011c21940 EFLAGS: 00010296
RAX: RBX: RCX: 000c
RDX: 00f0 RSI: RDI: 810002135d80
RBP: 810002135d80 R08: R09: 0001
R10: 02b2 R11: 8035a350 R12: 810002135d80
R13: 810011c21a90 R14: 81000e5fcdbc R15: 81000e5fcdbc
FS: 42003940(0063) GS:8075b000() knlGS:f7ddf6b0
CS: 0010 DS: ES: CR0: 8005003b
CR2: CR3: 04368000 CR4: 06e0
DR0: DR1: DR2:
DR3: DR6: 0ff0 DR7: 0400
Process rhythmbox (pid: 10479, threadinfo 810011c2, task
817b2f10)
Stack: 8032649a 810011c21a90 810002135d80
810011c21a58 810011c21a90 81000e5fcdbc 81000e5fcdbc
8102 [] readpages_unix_file+0x56/0xc0
[] do_generic_mapping_read+0x2f5/0x4b0
[] autoremove_wake_function+0x0/0x30
[] read_unix_file+0x49f/0x4c0
[] vfs_read+0xc5/0x180
Code: 80 00 04
RSP
Bad page state in process 'gdb'
page:810002135d80 flags:0xc001 mapping:
mapcount:0 count:0
Trying to fix it up, but a reboot is needed
Backtrace:
Call Trace:
[] bad_page+0x6b/0x120
[] get_page_from_freelist+0x435/0x520
[] __alloc_pages+0x9e/0x3c0
[] __handle_mm_fault+0x4eb/0x930
[] do_page_fault+0x14e/0x8c0
[] do_page_fault+0x1cb/0x8c0
[] dequeue_entity+0xaf/0xf0
[] _spin_unlock_irq+0x2f/0x50
[] error_exit+0x0/0x96
[] file_read_actor+0x10d/0x1b0
[] do_generic_mapping_read+0x231/0x4b0
[] file_read_actor+0x0/0x1b0
[] generic_file_aio_read+0x106/0x1c0
[] do_sync_read+0xd9/0x120
[] check_bytes_and_report+0x4b/0x100
[] check_object+0x224/0x260
[] autoremove_wake_function+0x0/0x30
[] _spin_unlock+0x29/0x50
[] reiser4_grab+0x8c/0xd0
[] read_unix_file+0x49f/0x4c0
[] cp_new_stat+0xe5/0x100
[] vfs_read+0xc5/0x180
[] sys_read+0x53/0x90
[] system_call+0x7e/0x83
INFO: lockdep is turned off.
Hexdump:
000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
010: 00 00 00 00 00 00 00 00SysRq : Emergency Sync
Emergency Sync complete
SysRq : Emergency Sync
Emergency Sync complete
Hangcheck: hangcheck value past margin!
SysRq : Emergency Sync
Emergency Sync complete
SysRq : Resetting
Fixed bug in extent2tail conversion.
Bug description:
when converting partially converted file
(with flag REISER4_PART_MIXED installed)
reiser4_cut_tree() starts to cut old metatada
from wrong offset. Result is data corruption.
Signed-off-by: Edward Shishkin <[EMAIL PROTECTED]>
---
linux-2.6.22-rc6-mm1/fs/reiser4/plugin/file/file.c|7 ---
linux-2.6.22-rc6-mm1/fs/reiser4/plugin/file/tail_conversion.c |2 +-
2 files changed, 1 insertion(+), 8 deletions(-)
--- linux-2.6.22-rc6-mm1/fs/reiser4/plugin/file/tail_conversion.c.orig
+++ linux-2.6.22-rc6-mm1/fs/reiser4/plugin/file/tail_conversion.c
@@ -620,7 +620,7 @@
}
/* cut part of file we have read */
- start_byte = (__u64) (i << PAGE_CACHE_SHIFT);
+ start_byte = (__u64) ((i + start_page) << PAGE_CACHE_SHIFT);
set_key_offset(&from, start_byte);
set_key_offset(&to, start_byte + PAGE_CACHE_SIZE - 1);
/*
--- linux-2.6.22-rc6-mm1/fs/reiser4/plugin/file/file.c.orig
+++ linux-2.6.22-rc6-mm1/fs/reiser4/plugin/file/file.c
@@ -195,13 +195,6 @@
assert("vs-1164", level == LEAF_LEVEL || level == TWIG_LEVEL);
if (uf_info->container == UF_CONTAINER_UNKNOWN) {
- /*
- * container is unknown, therefo
Re: 2.6.22-rc6-mm1 -- BUG - EIP: [] sysfs_addrm_finish+0x1c2/0x226 SS:ESP 0068:c5ff9db8
Tejun Heo wrote:
> Miles Lane wrote:
>>> Thanks a lot. Just in case, if you remove the patch (patch -R -p1), the
>>> oops goes away, right?
>> I double-checked. I can boot fine after building without your patch.
>> Also, I reproduced the initial BUG I reported (triggered by
>> "modprobe -r ipw2200").
>
> This is creepy. I was able to reproduce the oops here with your
> configuration file and making buffers for kallsyms static solved the
> problem. It isn't stack overflow. At maximum those arrays added 254
> bytes to the stack and when the oops occurs stack area was left more
> than enough. I'll keep looking into why that happened but the attached
> patch should get us going on the original subject.
Alright, found out what was going on. KSYM_NAME_LEN doesn't include
space for the trailing '\0'. Gees, I've read enough assembly for the
month to find that out. Anyways, here's proper debug patch.
Thanks.
--
tejun
---
fs/sysfs/dir.c| 43 +++
fs/sysfs/sysfs.h | 16 ++--
include/linux/sysfs.h |3 +++
net/core/net-sysfs.c |6 +-
4 files changed, 53 insertions(+), 15 deletions(-)
Index: tree0/fs/sysfs/dir.c
===
--- tree0.orig/fs/sysfs/dir.c
+++ tree0/fs/sysfs/dir.c
@@ -11,15 +11,52 @@
#include
#include
#include
+#include
#include
#include "sysfs.h"
+struct kobject *sysfs_debug_me;
+
DEFINE_MUTEX(sysfs_mutex);
spinlock_t sysfs_assoc_lock = SPIN_LOCK_UNLOCKED;
static spinlock_t sysfs_ino_lock = SPIN_LOCK_UNLOCKED;
static DEFINE_IDA(sysfs_ino_ida);
+struct sysfs_dirent * sysfs_get(struct sysfs_dirent * sd)
+{
+ if (sd) {
+ if (sd->s_flags & SYSFS_FLAG_XXX) {
+ char c0[KSYM_NAME_LEN + 1], c1[KSYM_NAME_LEN + 1];
+
+ lookup_symbol_name((unsigned
long)__builtin_return_address(0), c0);
+ lookup_symbol_name((unsigned
long)__builtin_return_address(1), c1);
+
+ printk("sysfs_get(%s): cnt=%d++ called from %s:%s\n",
+ sd->s_name, atomic_read(&sd->s_count), c0, c1);
+ }
+ WARN_ON(!atomic_read(&sd->s_count));
+ atomic_inc(&sd->s_count);
+ }
+ return sd;
+}
+
+void sysfs_put(struct sysfs_dirent * sd)
+{
+ if (sd && sd->s_flags & SYSFS_FLAG_XXX) {
+ char c0[KSYM_NAME_LEN + 1], c1[KSYM_NAME_LEN + 1];
+
+ lookup_symbol_name((unsigned long)__builtin_return_address(0),
c0);
+ lookup_symbol_name((unsigned long)__builtin_return_address(1),
c1);
+
+ printk("sysfs_put(%s): cnt=%d-- called from %s:%s\n",
+ sd->s_name, atomic_read(&sd->s_count), c0, c1);
+ }
+
+ if (sd && atomic_dec_and_test(&sd->s_count))
+ release_sysfs_dirent(sd);
+}
+
/**
* sysfs_link_sibling - link sysfs_dirent into sibling list
* @sd: sysfs_dirent of interest
@@ -317,6 +354,10 @@ void release_sysfs_dirent(struct sysfs_d
* sd->s_parent won't change beneath us.
*/
parent_sd = sd->s_parent;
+ if (parent_sd->s_flags & SYSFS_FLAG_XXX)
+ printk("put from release(%s): cnt=%d-- (rel=%s)\n",
+ parent_sd->s_name, atomic_read(&parent_sd->s_count),
+ sd->s_name);
if (sysfs_type(sd) == SYSFS_KOBJ_LINK)
sysfs_put(sd->s_elem.symlink.target_sd);
@@ -695,6 +736,8 @@ static int create_dir(struct kobject *ko
if (!sd)
return -ENOMEM;
sd->s_elem.dir.kobj = kobj;
+ if (sysfs_debug_me && sysfs_debug_me == kobj)
+ sd->s_flags |= SYSFS_FLAG_XXX;
/* link in */
sysfs_addrm_start(&acxt, parent_sd);
Index: tree0/fs/sysfs/sysfs.h
===
--- tree0.orig/fs/sysfs/sysfs.h
+++ tree0/fs/sysfs/sysfs.h
@@ -108,20 +108,8 @@ static inline unsigned int sysfs_type(st
return sd->s_flags & SYSFS_TYPE_MASK;
}
-static inline struct sysfs_dirent * sysfs_get(struct sysfs_dirent * sd)
-{
- if (sd) {
- WARN_ON(!atomic_read(&sd->s_count));
- atomic_inc(&sd->s_count);
- }
- return sd;
-}
-
-static inline void sysfs_put(struct sysfs_dirent * sd)
-{
- if (sd && atomic_dec_and_test(&sd->s_count))
- release_sysfs_dirent(sd);
-}
+struct sysfs_dirent * sysfs_get(struct sysfs_dirent * sd);
+void sysfs_put(struct sysfs_dirent * sd);
static inline int sysfs_is_shadowed_inode(struct inode *inode)
{
Index: tree0/include/linux/sysfs.h
===
--- tree0.orig/include/linux/sysfs.h
+++ tree0/include/linux/sysfs.h
@@ -87,9 +87,12 @@ struct sysfs_ops {
#define SYSFS_FLAG_MASK~SYSFS_TYPE_MASK
#define SYSFS_FLAG_REMOVED 0x0100
+#define SYSFS_FLAG_X
Re: 2.6.22-rc6-mm1 -- BUG - EIP: [] sysfs_addrm_finish+0x1c2/0x226 SS:ESP 0068:c5ff9db8
Miles Lane wrote:
>> Thanks a lot. Just in case, if you remove the patch (patch -R -p1), the
>> oops goes away, right?
>
> I double-checked. I can boot fine after building without your patch.
> Also, I reproduced the initial BUG I reported (triggered by
> "modprobe -r ipw2200").
This is creepy. I was able to reproduce the oops here with your
configuration file and making buffers for kallsyms static solved the
problem. It isn't stack overflow. At maximum those arrays added 254
bytes to the stack and when the oops occurs stack area was left more
than enough. I'll keep looking into why that happened but the attached
patch should get us going on the original subject.
Thanks.
--
tejun
---
fs/sysfs/dir.c| 43 +++
fs/sysfs/sysfs.h | 16 ++--
include/linux/sysfs.h |3 +++
net/core/net-sysfs.c |6 +-
4 files changed, 53 insertions(+), 15 deletions(-)
Index: tree0/fs/sysfs/dir.c
===
--- tree0.orig/fs/sysfs/dir.c
+++ tree0/fs/sysfs/dir.c
@@ -11,15 +11,52 @@
#include
#include
#include
+#include
#include
#include "sysfs.h"
+struct kobject *sysfs_debug_me;
+
DEFINE_MUTEX(sysfs_mutex);
spinlock_t sysfs_assoc_lock = SPIN_LOCK_UNLOCKED;
static spinlock_t sysfs_ino_lock = SPIN_LOCK_UNLOCKED;
static DEFINE_IDA(sysfs_ino_ida);
+struct sysfs_dirent * sysfs_get(struct sysfs_dirent * sd)
+{
+ if (sd) {
+ if (sd->s_flags & SYSFS_FLAG_XXX) {
+ static char c0[KSYM_NAME_LEN], c1[KSYM_NAME_LEN];
+
+ lookup_symbol_name((unsigned
long)__builtin_return_address(0), c0);
+ lookup_symbol_name((unsigned
long)__builtin_return_address(1), c1);
+
+ printk("sysfs_get(%s): cnt=%d++ called from %s:%s\n",
+ sd->s_name, atomic_read(&sd->s_count), c0, c1);
+ }
+ WARN_ON(!atomic_read(&sd->s_count));
+ atomic_inc(&sd->s_count);
+ }
+ return sd;
+}
+
+void sysfs_put(struct sysfs_dirent * sd)
+{
+ if (sd && sd->s_flags & SYSFS_FLAG_XXX) {
+ static char c0[KSYM_NAME_LEN], c1[KSYM_NAME_LEN];
+
+ lookup_symbol_name((unsigned long)__builtin_return_address(0),
c0);
+ lookup_symbol_name((unsigned long)__builtin_return_address(1),
c1);
+
+ printk("sysfs_put(%s): cnt=%d-- called from %s:%s\n",
+ sd->s_name, atomic_read(&sd->s_count), c0, c1);
+ }
+
+ if (sd && atomic_dec_and_test(&sd->s_count))
+ release_sysfs_dirent(sd);
+}
+
/**
* sysfs_link_sibling - link sysfs_dirent into sibling list
* @sd: sysfs_dirent of interest
@@ -317,6 +354,10 @@ void release_sysfs_dirent(struct sysfs_d
* sd->s_parent won't change beneath us.
*/
parent_sd = sd->s_parent;
+ if (parent_sd->s_flags & SYSFS_FLAG_XXX)
+ printk("put from release(%s): cnt=%d-- (rel=%s)\n",
+ parent_sd->s_name, atomic_read(&parent_sd->s_count),
+ sd->s_name);
if (sysfs_type(sd) == SYSFS_KOBJ_LINK)
sysfs_put(sd->s_elem.symlink.target_sd);
@@ -695,6 +736,8 @@ static int create_dir(struct kobject *ko
if (!sd)
return -ENOMEM;
sd->s_elem.dir.kobj = kobj;
+ if (sysfs_debug_me && sysfs_debug_me == kobj)
+ sd->s_flags |= SYSFS_FLAG_XXX;
/* link in */
sysfs_addrm_start(&acxt, parent_sd);
Index: tree0/fs/sysfs/sysfs.h
===
--- tree0.orig/fs/sysfs/sysfs.h
+++ tree0/fs/sysfs/sysfs.h
@@ -108,20 +108,8 @@ static inline unsigned int sysfs_type(st
return sd->s_flags & SYSFS_TYPE_MASK;
}
-static inline struct sysfs_dirent * sysfs_get(struct sysfs_dirent * sd)
-{
- if (sd) {
- WARN_ON(!atomic_read(&sd->s_count));
- atomic_inc(&sd->s_count);
- }
- return sd;
-}
-
-static inline void sysfs_put(struct sysfs_dirent * sd)
-{
- if (sd && atomic_dec_and_test(&sd->s_count))
- release_sysfs_dirent(sd);
-}
+struct sysfs_dirent * sysfs_get(struct sysfs_dirent * sd);
+void sysfs_put(struct sysfs_dirent * sd);
static inline int sysfs_is_shadowed_inode(struct inode *inode)
{
Index: tree0/include/linux/sysfs.h
===
--- tree0.orig/include/linux/sysfs.h
+++ tree0/include/linux/sysfs.h
@@ -87,9 +87,12 @@ struct sysfs_ops {
#define SYSFS_FLAG_MASK~SYSFS_TYPE_MASK
#define SYSFS_FLAG_REMOVED 0x0100
+#define SYSFS_FLAG_XXX 0x0200
#ifdef CONFIG_SYSFS
+extern struct kobject *sysfs_debug_me;
+
extern int sysfs_schedule_callback(struct kobject *kobj,
void (*func)(void *), void *data, struct module *owner);
Index: tree0/net/cor
Re: 2.6.22-rc6-mm1-cfs-v19 Unable to handle kernel NULL pointer dereference (reproducable)
Markus Trippelsdorf wrote: Just got this oops while I was updating my system: Unable to handle kernel NULL pointer dereference at 02a6 RIP: [] vfs_permission+0x6/0x10 The same thing just happened here during dist-upgrade with stock ubuntu 2.6.22-7-generic x86_64 kernel (based on -rc4 I think): [ 6361.299928] Unable to handle kernel NULL pointer dereference at 02a2 RIP: [ 6361.299933] [] vfs_permission+0x6/0x10 ext3 in use. L. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.22-rc6(mm1) Unable to handle kernel NULL pointer dereference - git-bisect result
On Sun, Jul 08, 2007 at 12:00:55PM -0700, Linus Torvalds wrote: > > > On Sun, 8 Jul 2007, Al Viro wrote: > > > > I think that we need to go the other way round - gather nameidata > > ->nd and ->dentry into struct path and pass pointer to that instead... > > Yeah, that sounds fine too. > > > But that's .23-rc1 fodder, if not .23-rc2 one (we might want to > > do -rc2 with just that, to avoid conflicts with pending patches). > > Definitely not for .22-final. > > Oh, absolutely. I wasn't implying that we would want to do it today, but > as it is now, just looking at that code makes my eyes water.. So it would > be nice to fix that up. > > One reason I would almost prefer an "nd", though, is that it would allow > us to in general always just convert anythign that now looks up a path to > look up "a path or file descriptor" instead. Those things need "nd" right > now, and if it's a "struct path", then you'll always have the two > different cases, rather than just the common "release_nd()" at the end. Umm... Perhaps, but I'm not sure if we want to play with refcounts for mnt/dentry in file case. If we do, we can always do your helper, but have it fill supplied struct file - either from fd or from nameidata. And release_nd() before returning from helper. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.22-rc6(mm1) Unable to handle kernel NULL pointer dereference - git-bisect result
On Sun, 8 Jul 2007, Al Viro wrote: > > I think that we need to go the other way round - gather nameidata > ->nd and ->dentry into struct path and pass pointer to that instead... Yeah, that sounds fine too. > But that's .23-rc1 fodder, if not .23-rc2 one (we might want to > do -rc2 with just that, to avoid conflicts with pending patches). > Definitely not for .22-final. Oh, absolutely. I wasn't implying that we would want to do it today, but as it is now, just looking at that code makes my eyes water.. So it would be nice to fix that up. One reason I would almost prefer an "nd", though, is that it would allow us to in general always just convert anythign that now looks up a path to look up "a path or file descriptor" instead. Those things need "nd" right now, and if it's a "struct path", then you'll always have the two different cases, rather than just the common "release_nd()" at the end. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.22-rc6(mm1) Unable to handle kernel NULL pointer dereference - git-bisect result
On Sun, Jul 08, 2007 at 11:38:20AM -0700, Linus Torvalds wrote: > I do think that it would be even nicer to just have a function that fills > in the "struct nameidata" from the dfd. I think we should be able to: the > "struct file" really does have the "f_path" thing with both dentry and mnt > information, and that would clean up that whole ugly "filepointer-vs-nd" > thing a lot. > > That would be an "Al cleanup", though. What do you think, Al? I think that we need to go the other way round - gather nameidata ->nd and ->dentry into struct path and pass pointer to that instead... But that's .23-rc1 fodder, if not .23-rc2 one (we might want to do -rc2 with just that, to avoid conflicts with pending patches). Definitely not for .22-final. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.22-rc6(mm1) Unable to handle kernel NULL pointer dereference - git-bisect result
On Sun, 8 Jul 2007, Ulrich Drepper wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Linus Torvalds wrote:
> > notify_change() does *not* do permission checks for
> > ATTR_CTIME/MTIME/ATIME.
>
> Then I don't understand
>
> /* Check for setting the inode time. */
> if (ia_valid & (ATTR_MTIME_SET | ATTR_ATIME_SET)) {
> if (current->fsuid != inode->i_uid && !capable(CAP_FOWNER))
> goto error;
> }
>
> in inode_change_ok. This seems to me exactly like the check needed.
No it's not. It really allows only the _owner_ to change MTIME/ATIME.
And the thing is, other people _can_ change MTIME/ATIME, but only to the
current time!
This is why ATTR_MTIME_SET ("set it to a _specific_ time") is so different
from ATTR_MTIME ("set it to the _current_ time").
The former is for times() with times != NULL, and is strictly limited to
only the owner (or root).
The latter is a "anybody who can change the inode can implicitly also
change the inode timestamps, but only to the _current_ time".
In other words, the ATTR_A/MTIME_SET thing allows people to _lie_ about
the time, and only the owner is allowed to do that. Which is why they are
very different.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.22-rc6(mm1) Unable to handle kernel NULL pointer dereference - git-bisect result
On Sun, 8 Jul 2007, Linus Torvalds wrote: > > This would seem to be the minimal change, and I think it's right. Side note: I considered just changing do_utimes() to use ATIME_SET/MTIME_SET instead, which would simplify the logic a lot.. But it turns out that the semantics for A/MTIME_SET is that only the owner of the file can do that. So the "!times" case is simply _fundamentally_ different from a permissions check standpoint, and there we have to check for "writable" rather than anything else (although ownership will override it). So rather than simplify the thing, I had to add code. Oh, well. I do think that it would be even nicer to just have a function that fills in the "struct nameidata" from the dfd. I think we should be able to: the "struct file" really does have the "f_path" thing with both dentry and mnt information, and that would clean up that whole ugly "filepointer-vs-nd" thing a lot. That would be an "Al cleanup", though. What do you think, Al? Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.22-rc6(mm1) Unable to handle kernel NULL pointer dereference - git-bisect result
On Sun, Jul 08, 2007 at 11:30:15AM -0700, Linus Torvalds wrote: > - non-owners can set it only when they have write permissions, and if it >was a file descriptor, the only way for us to know that they have write >permissions is if it's opened writably, which is hopefully equivalent >to that MAY_WRITE test (except the MAY_WRITE test was done at _open_ >time). > > This would seem to be the minimal change, and I think it's right. Yeah, FMODE_WRITE is probably right. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.22-rc6(mm1) Unable to handle kernel NULL pointer dereference - git-bisect result
On Sun, Jul 08, 2007 at 11:24:53AM -0700, Ulrich Drepper wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Linus Torvalds wrote:
> > notify_change() does *not* do permission checks for
> > ATTR_CTIME/MTIME/ATIME.
>
> Then I don't understand
>
> /* Check for setting the inode time. */
> if (ia_valid & (ATTR_MTIME_SET | ATTR_ATIME_SET)) {
> if (current->fsuid != inode->i_uid && !capable(CAP_FOWNER))
> goto error;
> }
>
> in inode_change_ok. This seems to me exactly like the check needed.
Sigh... There are two operations.
1) set the timestamp to user-supplied value. Owner-only.
2) have the timestamp set to _now_. Obviously can be done not
only by the owner (think of e.g. write(2)); having write access is
sufficient.
ATTR_MTIME_SET is the former. ATTR_MTIME without ATTR_MTIME_SET is the
latter and that's what utimes(foo, NULL) ends up doing.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.22-rc6(mm1) Unable to handle kernel NULL pointer dereference - git-bisect result
On Sun, 8 Jul 2007, Linus Torvalds wrote:
>
> No.
>
> notify_change() does *not* do permission checks for
> ATTR_CTIME/MTIME/ATIME.
>
> It does them for the "xxx_SET" attributes, but MTIME/ATIME is expected to
> change when other things change, so notify_change() expects that those
> _other_ changes have been validated from a security standpoint!
>
> utimes() is special.
This might be an acceptable patch.
Al? What do you think? Basically, it says that
- the file owner can always set MTIME/ATIME, of course
- non-owners can set it only when they have write permissions, and if it
was a file descriptor, the only way for us to know that they have write
permissions is if it's opened writably, which is hopefully equivalent
to that MAY_WRITE test (except the MAY_WRITE test was done at _open_
time).
This would seem to be the minimal change, and I think it's right.
Linus
---
fs/utimes.c | 13 ++---
1 files changed, 10 insertions(+), 3 deletions(-)
diff --git a/fs/utimes.c b/fs/utimes.c
index 480f7c8..b3c8895 100644
--- a/fs/utimes.c
+++ b/fs/utimes.c
@@ -106,9 +106,16 @@ long do_utimes(int dfd, char __user *filename, struct
timespec *times, int flags
if (IS_IMMUTABLE(inode))
goto dput_and_out;
- if (current->fsuid != inode->i_uid &&
- (error = vfs_permission(&nd, MAY_WRITE)) != 0)
- goto dput_and_out;
+ if (current->fsuid != inode->i_uid) {
+ if (f) {
+ if (!(f->f_mode & FMODE_WRITE))
+ goto dput_and_out;
+ } else {
+ error = vfs_permission(&nd, MAY_WRITE);
+ if (error)
+ goto dput_and_out;
+ }
+ }
}
mutex_lock(&inode->i_mutex);
error = notify_change(dentry, &newattrs);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.22-rc6(mm1) Unable to handle kernel NULL pointer dereference - git-bisect result
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Linus Torvalds wrote:
> notify_change() does *not* do permission checks for
> ATTR_CTIME/MTIME/ATIME.
Then I don't understand
/* Check for setting the inode time. */
if (ia_valid & (ATTR_MTIME_SET | ATTR_ATIME_SET)) {
if (current->fsuid != inode->i_uid && !capable(CAP_FOWNER))
goto error;
}
in inode_change_ok. This seems to me exactly like the check needed.
- --
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (GNU/Linux)
iD8DBQFGkSv12ijCOnn/RHQRAkp8AJ9q9vuy1ACjiYHteRac4Q86WO5wlgCfbr11
I0d6V5VGJGmpkuc9NsO6lkE=
=imhB
-END PGP SIGNATURE-
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.22-rc6(mm1) Unable to handle kernel NULL pointer dereference - git-bisect result
On Sun, Jul 08, 2007 at 10:41:46AM -0700, Ulrich Drepper wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Al Viro wrote: > > Like hell. At the very least you want it to be opened for write. > > And even that is dubious, since "process has write access to file" > > is not quite the same thing as "somebody had given the process a > > descriptor opened for write". > > But the real permissions tests are performed in notify_change. I think > all this is consistent with how, for instance, fchmod works. The > additional tests in fchmod which aren't here (IS_RDONLY and IS_APPEND) > would also apply to the case where a file name is given. So, either the > code was inconsistent already are these tests are really not needed. Yes, it's either that, or you haven't bothered to read what it really does. ATTR_UID et.al. are checked in inode_change_ok(). So is ATTR_MTIME_SET (only owner can explicitly set timestamps). ATTR_MTIME is not and *should* *not* be checked there. Exactly because it's done as a side effect of many operations with access control of their own and nothing that could be pushed down into notify_change() path. Think of e.g. write(2) - by the time you get to notify_change(), you don't even have a file descriptor. Just the dentry and process writing to file doesn't have to have *any* permissions on it. Hell, _try_ it. Build the kernel with your patch and without it. Call utimes() with NULL second argument on a file you have no write access to. See if the timestamps change. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.22-rc6(mm1) Unable to handle kernel NULL pointer dereference - git-bisect result
On Sun, 8 Jul 2007, Ulrich Drepper wrote: > > But the real permissions tests are performed in notify_change. I think > all this is consistent with how, for instance, fchmod works. The > additional tests in fchmod which aren't here (IS_RDONLY and IS_APPEND) > would also apply to the case where a file name is given. So, either the > code was inconsistent already are these tests are really not needed. No. notify_change() does *not* do permission checks for ATTR_CTIME/MTIME/ATIME. It does them for the "xxx_SET" attributes, but MTIME/ATIME is expected to change when other things change, so notify_change() expects that those _other_ changes have been validated from a security standpoint! utimes() is special. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.22-rc6(mm1) Unable to handle kernel NULL pointer dereference - git-bisect result
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Al Viro wrote: > Like hell. At the very least you want it to be opened for write. > And even that is dubious, since "process has write access to file" > is not quite the same thing as "somebody had given the process a > descriptor opened for write". But the real permissions tests are performed in notify_change. I think all this is consistent with how, for instance, fchmod works. The additional tests in fchmod which aren't here (IS_RDONLY and IS_APPEND) would also apply to the case where a file name is given. So, either the code was inconsistent already are these tests are really not needed. - -- ➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) iD8DBQFGkSHa2ijCOnn/RHQRAp0RAJ9ouvOd52feTPuFurxj8LzHZuGZsACgwxA8 ybEo1xmvakkKVenWc07PYhs= =5DBy -END PGP SIGNATURE- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.22-rc6(mm1) Unable to handle kernel NULL pointer dereference - git-bisect result
On Sun, Jul 08, 2007 at 10:06:43AM -0700, Ulrich Drepper wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Markus Trippelsdorf wrote: > > I tested this further and it turned out that the Linus tree is also > > affected. So I ran git-bisect, after I found out that version > > 2.6.21.6 was not affected by this bug. > > Try this patch. The vfs_permission test can be skipped since the VFS > isn't involved. We got the inode etc from a file descriptor. > > > Signed-Off-By: Ulrich Drepper <[EMAIL PROTECTED]> > > diff --git a/fs/utimes.c b/fs/utimes.c > index 480f7c8..873edcb 100644 > - --- a/fs/utimes.c > +++ b/fs/utimes.c > @@ -106,7 +106,8 @@ long do_utimes(int dfd, char __user *filename, struct > timespec *times, int flags > if (IS_IMMUTABLE(inode)) > goto dput_and_out; > > - - if (current->fsuid != inode->i_uid && > + if (f == NULL && > + current->fsuid != inode->i_uid && > (error = vfs_permission(&nd, MAY_WRITE)) != 0) > goto dput_and_out; > } > > I had to hand apply the patch, but it solved the problem. Thanks. -- Markus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.22-rc6(mm1) Unable to handle kernel NULL pointer dereference - git-bisect result
On Sun, Jul 08, 2007 at 10:06:43AM -0700, Ulrich Drepper wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Markus Trippelsdorf wrote: > > I tested this further and it turned out that the Linus tree is also > > affected. So I ran git-bisect, after I found out that version > > 2.6.21.6 was not affected by this bug. > > Try this patch. The vfs_permission test can be skipped since the VFS > isn't involved. We got the inode etc from a file descriptor. Like hell. At the very least you want it to be opened for write. And even that is dubious, since "process has write access to file" is not quite the same thing as "somebody had given the process a descriptor opened for write". - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.22-rc6(mm1) Unable to handle kernel NULL pointer dereference - git-bisect result
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Markus Trippelsdorf wrote: > I tested this further and it turned out that the Linus tree is also > affected. So I ran git-bisect, after I found out that version > 2.6.21.6 was not affected by this bug. Try this patch. The vfs_permission test can be skipped since the VFS isn't involved. We got the inode etc from a file descriptor. Signed-Off-By: Ulrich Drepper <[EMAIL PROTECTED]> diff --git a/fs/utimes.c b/fs/utimes.c index 480f7c8..873edcb 100644 - --- a/fs/utimes.c +++ b/fs/utimes.c @@ -106,7 +106,8 @@ long do_utimes(int dfd, char __user *filename, struct timespec *times, int flags if (IS_IMMUTABLE(inode)) goto dput_and_out; - - if (current->fsuid != inode->i_uid && + if (f == NULL && + current->fsuid != inode->i_uid && (error = vfs_permission(&nd, MAY_WRITE)) != 0) goto dput_and_out; } - -- ➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) iD8DBQFGkRmj2ijCOnn/RHQRAkuyAJ41CIDhT8yKb6SKX14ylFXznO6gfwCfdtEo 4Gt9hPsotmKddwE2xdYkJmQ= =JyVn -END PGP SIGNATURE- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.22-rc6(mm1) Unable to handle kernel NULL pointer dereference - git-bisect result
On Sun, 8 Jul 2007, Markus Trippelsdorf wrote: > > I tested this further and it turned out that the Linus tree is also > affected. So I ran git-bisect, after I found out that version > 2.6.21.6 was not affected by this bug. git-bisect is wonderful. > gentoox2 linux # git bisect bad > 1c710c896eb461895d3c399e15bb5f20b39c9073 is first bad commit > commit 1c710c896eb461895d3c399e15bb5f20b39c9073 > Author: Ulrich Drepper <[EMAIL PROTECTED]> Ok, I see what's wrong. We're doing "vfs_permission()" and passing in "nd" to it when "times" is NULL, but Uli didn't even *initialize* it for the case of filename == NULL && dfd != AT_FDCWD so yeah, it's broken. I was planning on doing 2.6.22 today, so I'm actually inclined to revert the commit entirely, even though it looks like it's probably fairly trivial to fix. But if we get a really quick and obvious fix, I guess I'll apply it. I have to say, the new do_utimes() code is pretty ugly compared to the old one exactly in the added special cases (the ones that caused this bug..) Uli? Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.22-rc6(mm1) Unable to handle kernel NULL pointer dereference - git-bisect result
On Sun, Jul 08, 2007 at 12:09:11PM +0200, Markus Trippelsdorf wrote: > On Sun, Jul 08, 2007 at 01:20:16AM -0700, Andrew Morton wrote: > > On Sun, 8 Jul 2007 07:14:52 +0200 Markus Trippelsdorf <[EMAIL PROTECTED]> > > wrote: > > > > ... > > > touch src/.depend # to prevent unecessary warnings > > > make: *** [dep] Killed > > > > ug. nd.dentry.d_inode (as set up by do_utimes()) is garbage. I don't know > > what could have caused that. > > > > > > > Running "touch > > > /var/tmp/paludis/sys-libs/gpm-1.20.1-r6/work/gpm-1.20.1/src/.depend" > > > triggers this oops. > > > > What type of filesystem is at /var/tmp? > > > > Is it repeatable after a reboot? > > > > The filesystem at /var/tmp was xfs. And yes it was repeatable after a > reboot... > > So I ran xfs_check on that partition and it reported errors. Then I ran > xfs_repair and after that rebooted, but the problem was still there. > Finally I switched the partition back to ext3, because it got too scary. > But the oops is now repeatable even on this new ext3 partition. I tested this further and it turned out that the Linus tree is also affected. So I ran git-bisect, after I found out that version 2.6.21.6 was not affected by this bug. This is the result: gentoox2 linux # git bisect bad 1c710c896eb461895d3c399e15bb5f20b39c9073 is first bad commit commit 1c710c896eb461895d3c399e15bb5f20b39c9073 Author: Ulrich Drepper <[EMAIL PROTECTED]> Date: Tue May 8 00:33:25 2007 -0700 utimensat implementation Implement utimensat(2) which is an extension to futimesat(2) in that it a) supports nano-second resolution for the timestamps b) allows to selectively ignore the atime/mtime value c) allows to selectively use the current time for either atime or mtime d) supports changing the atime/mtime of a symlink itself along the lines of the BSD lutimes(3) functions For this change the internally used do_utimes() functions was changed to accept a timespec time value and an additional flags parameter. Additionally the sys_utime function was changed to match compat_sys_utime which already use do_utimes instead of duplicating the work. Also, the completely missing futimensat() functionality is added. We have such a function in glibc but we have to resort to using /proc/self/fd/* which not everybody likes (chroot etc). Test application (the syscall number will need per-arch editing): ... [EMAIL PROTECTED]: add missing i386 syscall table entry] Signed-off-by: Ulrich Drepper <[EMAIL PROTECTED]> Cc: Alexey Dobriyan <[EMAIL PROTECTED]> Cc: Michael Kerrisk <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Signed-off-by: Andrew Morton <[EMAIL PROTECTED]> Signed-off-by: Linus Torvalds <[EMAIL PROTECTED]> HTH, -- Markus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.22-rc6-mm1: UNION_FS=y + BLOCK=n = compile error
I'm adding Jens Axboe to the CC list (BLOCK layer maintainer).
In message <[EMAIL PROTECTED]>, Adrian Bunk writes:
> On Thu, Jun 28, 2007 at 03:43:21AM -0700, Andrew Morton wrote:
> >...
> > Changes since 2.6.22-rc4-mm2:
> >...
> > git-unionfs.patch
> >...
> > git trees
> >...
>
> CONFIG_UNION_FS=y, CONFIG_BLOCK=n results in the following compile error:
>
> <-- snip -->
>
> ...
> CC fs/unionfs/file.o
> /home/bunk/linux/kernel-2.6/linux-2.6.22-rc6-mm1/fs/unionfs/file.c:147:
> error: âfile_fsyncâ undeclared here (not in a function)
> make[3]: *** [fs/unionfs/file.o] Error 1
> ...
>
> <-- snip -->
>
> cu
> Adrian
Adrian, thanks. I was able to reproduce this compiler error. But I think
there may be a problem with the mainline kernel itself.
Unionfs defines its fsync file op to file_fsync. file_fsync, defined in
fs/sync.c, appears to be a generic syncing function that can be used by
other file systems. In fact, the comment above it says "Generic function to
fsync a file." From fs/Makefile, it looks like sync.c gets compiled
regardless whether CONFIG_BLOCK is defined or not.
Moreover, file_fsync() makes a call to sync_blockdev(), clearly a function
which depends on CONFIG_BLOCK=y. However, include/linux/buffer_head.h
defines sync_blockdev() to a noop if CONFIG_BLOCK=n:
static inline int sync_blockdev(struct block_device *bdev) { return 0; }
This further indicates to me that someone went through the effort of making
file_fsync available and operational *even* if CONFIG_BLOCK=n.
But here's the problem: if CONFIG_BLOCK=n, the function file_fsync exists
and gets compiled into the kernel, but the extern definition for it is not
compiled in (it's wrapped in an #ifdef CONFIG_BLOCK in buffer_head.h). This
looks to me like a discrepancy: why compile the file_fsync function, and
even ensure that it will find a dummy sync_blockdev() symbol, if one doesn't
provide an extern for it?
One more oddity: the EXPORT_SYMBOL for fs/sync.c:file_fsync() is in
fs/buffer.c, and buffer.c does not get compiled if CONFIG_BLOCK=n. I
thought all EXPORT_SYMBOL calls are supposed to be near their respective
functions, no?
I suggest one of two things:
1. If you agree with me as to this discrepancy, then we can move the extern
for file_fsync() outside the #ifdef CONFIG_BLOCK in buffer_head.h -- it
should be defined regardless. Then move the EXPORT_SYMBOL(file_fsync)
from buffer.c to sync. I can provide a small patch right away.
2. If you disagree, then I can change Unionfs to avoid calling file_fsync
directly. I can define a unionfs_fsync file method which does the usual
stuff (pass the op to the layer below).
My preference is option #1; I'd like to avoid defining any more stackable
wrappers than I have to.
Thanks,
Erez.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.22-rc6-mm1-cfs-v19 Unable to handle kernel NULL pointer dereference (reproducable)
On Sun, Jul 08, 2007 at 01:20:16AM -0700, Andrew Morton wrote: > On Sun, 8 Jul 2007 07:14:52 +0200 Markus Trippelsdorf <[EMAIL PROTECTED]> > wrote: > > ... > > touch src/.depend # to prevent unecessary warnings > > make: *** [dep] Killed > > ug. nd.dentry.d_inode (as set up by do_utimes()) is garbage. I don't know > what could have caused that. > > > > Running "touch > > /var/tmp/paludis/sys-libs/gpm-1.20.1-r6/work/gpm-1.20.1/src/.depend" > > triggers this oops. > > What type of filesystem is at /var/tmp? > > Is it repeatable after a reboot? > The filesystem at /var/tmp was xfs. And yes it was repeatable after a reboot... So I ran xfs_check on that partition and it reported errors. Then I ran xfs_repair and after that rebooted, but the problem was still there. Finally I switched the partition back to ext3, because it got too scary. But the oops is now repeatable even on this new ext3 partition. There are no errors in the smartd log. I will run "smartctl -t long" now and will report back if it finds any errors. -- Markus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.22-rc6-mm1-cfs-v19 Unable to handle kernel NULL pointer dereference (reproducable)
On Sun, 8 Jul 2007 07:14:52 +0200 Markus Trippelsdorf <[EMAIL PROTECTED]> wrote: > Just got this oops while I was updating my system: > > Unable to handle kernel NULL pointer dereference at 02a6 RIP: > [] vfs_permission+0x6/0x10 > PGD 120f9067 PUD 4f5ec067 PMD 0 > Oops: [1] SMP > CPU 0 > Pid: 14067, comm: touch Not tainted 2.6.22-rc6-mm1-cfs-v19 #7 > RIP: 0010:[] [] vfs_permission+0x6/0x10 > RSP: 0018:8100083a7e20 EFLAGS: 00010293 > RAX: 0296 RBX: RCX: 81001cb6ee00 > RDX: 8100083a7e28 RSI: 0002 RDI: 8100083a7e28 > RBP: fff3 R08: 0002 R09: 2b70e16872b8 > R10: R11: 0246 R12: 81001cb6ee00 > R13: 81006396e828 R14: 81000c35da28 R15: 0002 > FS: 2b70e23fbd10() GS:8061b000() knlGS:f6ca96c0 > CS: 0010 DS: ES: CR0: 8005003b > CR2: 02a6 CR3: 1ca29000 CR4: 06e0 > DR0: DR1: DR2: > DR3: DR6: 0ff0 DR7: 0400 > Process touch (pid: 14067, threadinfo 8100083a6000, task 81001c589620) > Stack: 802a15e0 0296 8021d9c0 01b6 > 81001cb6ee00 81006396e828 2b70e1d66850 > 0004 8100083a7f58 81001c589620 > Call Trace: > [] do_utimes+0x230/0x250 > [] do_page_fault+0x420/0x8a0 > [] do_filp_open+0x3a/0x50 > [] sys_utimensat+0x37/0xe0 > [] error_exit+0x0/0x84 > [] system_call+0x7e/0x83 > > > Code: 48 8b 78 10 e9 d1 fd ff ff 90 53 48 89 fb 48 8d bf b4 00 00 > RIP [] vfs_permission+0x6/0x10 > RSP > CR2: 02a6 > > I was running the »paludis« package manager: > > make[1]: Leaving directory > `/var/tmp/paludis/sys-libs/gpm-1.20.1-r6/work/gpm-1.20.1/contrib' > >>> Done src_compile > >>> Skipping src_test (SKIP_FUNCTIONS) > >>> Starting builtin_saveenv > >>> Done builtin_saveenv > >>> Completed ebuild phases loadenv unpack compile test saveenv > >>> Running ebuild phases loadenv install saveenv as root:root... > >>> Starting builtin_loadenv > >>> Done builtin_loadenv > >>> Starting src_install > touch src/.depend # to prevent unecessary warnings > make: *** [dep] Killed ug. nd.dentry.d_inode (as set up by do_utimes()) is garbage. I don't know what could have caused that. > Running "touch > /var/tmp/paludis/sys-libs/gpm-1.20.1-r6/work/gpm-1.20.1/src/.depend" > triggers this oops. What type of filesystem is at /var/tmp? Is it repeatable after a reboot? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.22-rc6-mm1: git-kgdb breaks sh compilation
Adrian Bunk wrote: On Thu, Jun 28, 2007 at 03:43:21AM -0700, Andrew Morton wrote: ... Changes since 2.6.22-rc4-mm2: ... git-kgdb.patch ... git trees ... This tree adds to include/asm-sh/system.h code that already exists in the same file a few lines above resulting in compile errors. Please remove the include/asm-sh/system.h part from the git tree. cu Adrian Adrian, This is fixed in the for_mm branch of the kgdb git repository so it will be fixed on next pull into the -mm tree. I also cleaned up the sh-lite.patch to comply with checkpatch.pl Thanks, Jason. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.22-rc6-mm1 -- BUG - EIP: [] sysfs_addrm_finish+0x1c2/0x226 SS:ESP 0068:c5ff9db8
On 7/7/07, Tejun Heo <[EMAIL PROTECTED]> wrote: Miles Lane wrote: >> Weird, that's unrelated path. It seems sd->s_parent is NULL in >> sysfs_link_sibling(), which doesn't make sense because it's being called >> from sysfs_create_link() which makes sure parent_sd isn't NULL && >> sysfs_addrm_start() should have caused oops earlier as it deferences >> parent_sd. >> >> Can you please retry the test (test clean 2.6.22-rc6-mm1, apply patch, >> rebuild and test)? > > I downloaded linux-2.6.22-rc6.tar.bz2, applied 2.6.22-rc6-mm1 and then > applied your second patch. I still get the same OOPS I reported to you > and Andrew in the image I attached to my previous message. Thanks a lot. Just in case, if you remove the patch (patch -R -p1), the oops goes away, right? I double-checked. I can boot fine after building without your patch. Also, I reproduced the initial BUG I reported (triggered by "modprobe -r ipw2200"). Miles - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.22-rc6-mm1 -- BUG - EIP: [] sysfs_addrm_finish+0x1c2/0x226 SS:ESP 0068:c5ff9db8
Miles Lane wrote: >> Weird, that's unrelated path. It seems sd->s_parent is NULL in >> sysfs_link_sibling(), which doesn't make sense because it's being called >> from sysfs_create_link() which makes sure parent_sd isn't NULL && >> sysfs_addrm_start() should have caused oops earlier as it deferences >> parent_sd. >> >> Can you please retry the test (test clean 2.6.22-rc6-mm1, apply patch, >> rebuild and test)? > > I downloaded linux-2.6.22-rc6.tar.bz2, applied 2.6.22-rc6-mm1 and then > applied your second patch. I still get the same OOPS I reported to you > and Andrew in the image I attached to my previous message. Thanks a lot. Just in case, if you remove the patch (patch -R -p1), the oops goes away, right? -- tejun - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.22-rc6-mm1 -- BUG - EIP: [] sysfs_addrm_finish+0x1c2/0x226 SS:ESP 0068:c5ff9db8
On 7/6/07, Tejun Heo <[EMAIL PROTECTED]> wrote: (restoring cc to lkml) Hello, Miles. Miles Lane wrote: > With this patch applied, I can't boot at all. I have attached an OOPS > screenshot, since I don't have a serial debugging station set up. I > am leaving LKML out of the loop, because of the attachment. Weird, that's unrelated path. It seems sd->s_parent is NULL in sysfs_link_sibling(), which doesn't make sense because it's being called from sysfs_create_link() which makes sure parent_sd isn't NULL && sysfs_addrm_start() should have caused oops earlier as it deferences parent_sd. Can you please retry the test (test clean 2.6.22-rc6-mm1, apply patch, rebuild and test)? I downloaded linux-2.6.22-rc6.tar.bz2, applied 2.6.22-rc6-mm1 and then applied your second patch. I still get the same OOPS I reported to you and Andrew in the image I attached to my previous message. I must have a problematic .config file? # # Automatically generated make config: don't edit # Linux kernel version: 2.6.22-rc6-mm1 # Sat Jul 7 16:58:14 2007 # CONFIG_X86_32=y CONFIG_GENERIC_TIME=y CONFIG_GENERIC_CMOS_UPDATE=y CONFIG_CLOCKSOURCE_WATCHDOG=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y CONFIG_NONIRQ_WAKEUP=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_SEMAPHORE_SLEEPERS=y CONFIG_X86=y CONFIG_MMU=y CONFIG_ZONE_DMA=y CONFIG_QUICKLIST=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_IOMAP=y CONFIG_GENERIC_BUG=y CONFIG_GENERIC_HWEIGHT=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_DMI=y CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" # # Code maturity level options # CONFIG_EXPERIMENTAL=y CONFIG_BROKEN_ON_SMP=y CONFIG_LOCK_KERNEL=y CONFIG_INIT_ENV_ARG_LIMIT=32 # # General setup # CONFIG_LOCALVERSION="" CONFIG_LOCALVERSION_AUTO=y CONFIG_SWAP=y CONFIG_SWAP_PREFETCH=y CONFIG_SYSVIPC=y CONFIG_SYSVIPC_SYSCTL=y CONFIG_POSIX_MQUEUE=y # CONFIG_BSD_PROCESS_ACCT is not set # CONFIG_TASKSTATS is not set # CONFIG_USER_NS is not set # CONFIG_AUDIT is not set CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y CONFIG_LOG_BUF_SHIFT=18 # CONFIG_CONTAINER_DEBUG is not set CONFIG_SYSFS_DEPRECATED=y # CONFIG_CONTAINER_CPUACCT is not set # CONFIG_CONTAINER_NS is not set # CONFIG_RELAY is not set CONFIG_BLK_DEV_INITRD=y CONFIG_INITRAMFS_SOURCE="" CONFIG_CC_OPTIMIZE_FOR_SIZE=y CONFIG_SYSCTL=y # CONFIG_EMBEDDED is not set CONFIG_UID16=y CONFIG_SYSCTL_SYSCALL=y CONFIG_KALLSYMS=y CONFIG_KALLSYMS_ALL=y # CONFIG_KALLSYMS_EXTRA_PASS is not set CONFIG_HOTPLUG=y CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_ELF_CORE=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_ANON_INODES=y CONFIG_EPOLL=y CONFIG_SIGNALFD=y CONFIG_TIMERFD=y CONFIG_EVENTFD=y CONFIG_SHMEM=y CONFIG_VM_EVENT_COUNTERS=y CONFIG_SLUB_DEBUG=y # CONFIG_SLAB is not set CONFIG_SLUB=y # CONFIG_SLOB is not set CONFIG_PROC_SMAPS=y CONFIG_PROC_CLEAR_REFS=y CONFIG_PROC_PAGEMAP=y CONFIG_PROC_KPAGEMAP=y CONFIG_RT_MUTEXES=y # CONFIG_TINY_SHMEM is not set CONFIG_BASE_SMALL=0 CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y CONFIG_MODULE_FORCE_UNLOAD=y # CONFIG_MODVERSIONS is not set # CONFIG_MODULE_SRCVERSION_ALL is not set CONFIG_KMOD=y CONFIG_BLOCK=y CONFIG_LBD=y # CONFIG_BLK_DEV_IO_TRACE is not set # CONFIG_LSF is not set # # IO Schedulers # CONFIG_IOSCHED_NOOP=y CONFIG_IOSCHED_AS=y CONFIG_IOSCHED_DEADLINE=m CONFIG_IOSCHED_CFQ=m CONFIG_DEFAULT_AS=y # CONFIG_DEFAULT_DEADLINE is not set # CONFIG_DEFAULT_CFQ is not set # CONFIG_DEFAULT_NOOP is not set CONFIG_DEFAULT_IOSCHED="anticipatory" # # Processor type and features # CONFIG_TICK_ONESHOT=y CONFIG_NO_HZ=y CONFIG_HIGH_RES_TIMERS=y # CONFIG_SMP is not set CONFIG_X86_PC=y # CONFIG_X86_ELAN is not set # CONFIG_X86_VOYAGER is not set # CONFIG_X86_NUMAQ is not set # CONFIG_X86_SUMMIT is not set # CONFIG_X86_BIGSMP is not set # CONFIG_X86_VISWS is not set # CONFIG_X86_GENERICARCH is not set # CONFIG_X86_ES7000 is not set # CONFIG_PARAVIRT is not set # CONFIG_M386 is not set # CONFIG_M486 is not set # CONFIG_M586 is not set # CONFIG_M586TSC is not set # CONFIG_M586MMX is not set # CONFIG_M686 is not set # CONFIG_MPENTIUMII is not set # CONFIG_MPENTIUMIII is not set # CONFIG_MPENTIUMM is not set # CONFIG_MCORE2 is not set CONFIG_MPENTIUM4=y # CONFIG_MK6 is not set # CONFIG_MK7 is not set # CONFIG_MK8 is not set # CONFIG_MCRUSOE is not set # CONFIG_MEFFICEON is not set # CONFIG_MWINCHIPC6 is not set # CONFIG_MWINCHIP2 is not set # CONFIG_MWINCHIP3D is not set # CONFIG_MGEODEGX1 is not set # CONFIG_MGEODE_LX is not set # CONFIG_MCYRIXIII is not set # CONFIG_MVIAC3_2 is not set # CONFIG_MVIAC7 is not set # CONFIG_X86_GENERIC is not set CONFIG_X86_CMPXCHG=y CONFIG_X86_L1_CACHE_SHIFT=7 CONFIG_X86_XADD=y CONFIG_RWSEM_XCHGADD_ALGORITHM=y # CONFIG_ARCH_HAS_ILOG2_U32 is not set # CONFIG_ARCH_HAS_ILOG2_U64 is not set CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_X86_WP_WORKS_OK=y CONFIG_X86_INVLPG=y CONFIG_X86_BSWAP=y CONFIG_X86_POPAD_OK=y CONFIG_X86_GOOD_APIC=y CONFIG_X86_INTEL_USERCOPY=y CONFIG_X86_USE_PPRO_CHECKSUM=y CONFIG_X86_TSC=y CONFIG_X86_CMOV=y CONFIG_X86_
Re: 2.6.22-rc6-mm1 -- BUG - EIP: [] sysfs_addrm_finish+0x1c2/0x226 SS:ESP 0068:c5ff9db8
(restoring cc to lkml) Hello, Miles. Miles Lane wrote: > With this patch applied, I can't boot at all. I have attached an OOPS > screenshot, since I don't have a serial debugging station set up. I > am leaving LKML out of the loop, because of the attachment. Weird, that's unrelated path. It seems sd->s_parent is NULL in sysfs_link_sibling(), which doesn't make sense because it's being called from sysfs_create_link() which makes sure parent_sd isn't NULL && sysfs_addrm_start() should have caused oops earlier as it deferences parent_sd. Can you please retry the test (test clean 2.6.22-rc6-mm1, apply patch, rebuild and test)? Thanks. -- tejun - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.22-rc6-mm1: SLUB_DEBUG=n compile error
On Sat, 7 Jul 2007, Adrian Bunk wrote: > > Why switch CONFIG_SLUB_DEBUG off? This is an option for embedded systems. > > Unlikely to occur on NUMA. > > ??? > This compile error is not related to NUMA. Ah. the init_kmem_cache_node() code was moved outside of CONFIG_NUMA. Sigh. Only the other issue in early_kmem_cache_node is NUMA related but you did not encounter this since CONFIG_NUMA was not set. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.22-rc6-mm1: SLUB_DEBUG=n compile error
On Fri, Jul 06, 2007 at 07:03:34PM -0700, Christoph Lameter wrote: > On Sat, 7 Jul 2007, Adrian Bunk wrote: > > > With CONFIG_SLUB_DEBUG=n: > > Why switch CONFIG_SLUB_DEBUG off? This is an option for embedded systems. > Unlikely to occur on NUMA. ??? This compile error is not related to NUMA. > > /home/bunk/linux/kernel-2.6/linux-2.6.22-rc6-mm1/mm/slub.c: In function > > ÿÿinit_kmem_cache_nodeÿÿ: > > /home/bunk/linux/kernel-2.6/linux-2.6.22-rc6-mm1/mm/slub.c:1873: error: > > ÿÿstruct kmem_cache_nodeÿÿ has no member named ÿÿfullÿÿ > > ... > > make[2]: *** [mm/slub.o] Error 1 > > A fix for this is already in Andrew's tree. Thanks. cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.22-rc6-mm1: SLUB_DEBUG=n compile error
On Sat, 7 Jul 2007, Adrian Bunk wrote: > With CONFIG_SLUB_DEBUG=n: Why switch CONFIG_SLUB_DEBUG off? This is an option for embedded systems. Unlikely to occur on NUMA. > /home/bunk/linux/kernel-2.6/linux-2.6.22-rc6-mm1/mm/slub.c: In function > ÿÿinit_kmem_cache_nodeÿÿ: > /home/bunk/linux/kernel-2.6/linux-2.6.22-rc6-mm1/mm/slub.c:1873: error: > ÿÿstruct kmem_cache_nodeÿÿ has no member named ÿÿfullÿÿ > ... > make[2]: *** [mm/slub.o] Error 1 A fix for this is already in Andrew's tree.
Re: 2.6.22-rc6-mm1
On Thu, 2007-06-28 at 03:43 -0700, Andrew Morton wrote: > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.22-rc6/2.6.22-rc6-mm1/ > fs/xfs/linux-2.6/xfs_ioctl32.c: In function ‘xfs_ioc_bulkstat_compat’: fs/xfs/linux-2.6/xfs_ioctl32.c:334: error: ‘xfs_inumbers_fmt_compat’ undeclared (first use in this function)fs/xfs/linux-2.6/xfs_ioctl32.c:334: error: (Each undeclared identifier is reported only once fs/xfs/linux-2.6/xfs_ioctl32.c:334: error: for each function it appears in.) make[2]: *** [fs/xfs/linux-2.6/xfs_ioctl32.o] Error 1 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.22-rc6-mm1 -- BUG - EIP: [] sysfs_addrm_finish+0x1c2/0x226 SS:ESP 0068:c5ff9db8
Hello,
Miles Lane wrote:
> XXX sysfs_deactivate: sd=c36ba6c0 s_sibling=6b6b6b6b s_flags=0x6b6b6b6b
> [ cut here ]
> kernel BUG at fs/sysfs/dir.c:274!
OIC, ref counter is too low by one. The sysfs_dirent is probably
getting freed on sysfs_drop_dentry(). Hmmm... Where did I screw up?
Can you apply the attached patch and report the log after oops? It
shouldn't generate too much output.
Thanks.
--
tejun
---
fs/sysfs/dir.c| 43 +++
fs/sysfs/sysfs.h | 16 ++--
include/linux/sysfs.h |3 +++
net/core/net-sysfs.c |6 +-
4 files changed, 53 insertions(+), 15 deletions(-)
Index: tree0/fs/sysfs/dir.c
===
--- tree0.orig/fs/sysfs/dir.c
+++ tree0/fs/sysfs/dir.c
@@ -11,15 +11,52 @@
#include
#include
#include
+#include
#include
#include "sysfs.h"
+struct kobject *sysfs_debug_me;
+
DEFINE_MUTEX(sysfs_mutex);
spinlock_t sysfs_assoc_lock = SPIN_LOCK_UNLOCKED;
static spinlock_t sysfs_ino_lock = SPIN_LOCK_UNLOCKED;
static DEFINE_IDA(sysfs_ino_ida);
+struct sysfs_dirent * sysfs_get(struct sysfs_dirent * sd)
+{
+ if (sd) {
+ if (sd->s_flags & SYSFS_FLAG_XXX) {
+ char c0[KSYM_NAME_LEN], c1[KSYM_NAME_LEN];
+
+ lookup_symbol_name((unsigned
long)__builtin_return_address(0), c0);
+ lookup_symbol_name((unsigned
long)__builtin_return_address(1), c1);
+
+ printk("sysfs_get(%s): cnt=%d++ called from %s:%s\n",
+ sd->s_name, atomic_read(&sd->s_count), c0, c1);
+ }
+ WARN_ON(!atomic_read(&sd->s_count));
+ atomic_inc(&sd->s_count);
+ }
+ return sd;
+}
+
+void sysfs_put(struct sysfs_dirent * sd)
+{
+ if (sd && sd->s_flags & SYSFS_FLAG_XXX) {
+ char c0[KSYM_NAME_LEN], c1[KSYM_NAME_LEN];
+
+ lookup_symbol_name((unsigned long)__builtin_return_address(0),
c0);
+ lookup_symbol_name((unsigned long)__builtin_return_address(1),
c1);
+
+ printk("sysfs_put(%s): cnt=%d-- called from %s:%s\n",
+ sd->s_name, atomic_read(&sd->s_count), c0, c1);
+ }
+
+ if (sd && atomic_dec_and_test(&sd->s_count))
+ release_sysfs_dirent(sd);
+}
+
/**
* sysfs_link_sibling - link sysfs_dirent into sibling list
* @sd: sysfs_dirent of interest
@@ -317,6 +354,10 @@ void release_sysfs_dirent(struct sysfs_d
* sd->s_parent won't change beneath us.
*/
parent_sd = sd->s_parent;
+ if (parent_sd->s_flags & SYSFS_FLAG_XXX)
+ printk("put from release(%s): cnt=%d-- (rel=%s)\n",
+ parent_sd->s_name, atomic_read(&parent_sd->s_count),
+ sd->s_name);
if (sysfs_type(sd) == SYSFS_KOBJ_LINK)
sysfs_put(sd->s_elem.symlink.target_sd);
@@ -695,6 +736,8 @@ static int create_dir(struct kobject *ko
if (!sd)
return -ENOMEM;
sd->s_elem.dir.kobj = kobj;
+ if (sysfs_debug_me && sysfs_debug_me == kobj)
+ sd->s_flags |= SYSFS_FLAG_XXX;
/* link in */
sysfs_addrm_start(&acxt, parent_sd);
Index: tree0/fs/sysfs/sysfs.h
===
--- tree0.orig/fs/sysfs/sysfs.h
+++ tree0/fs/sysfs/sysfs.h
@@ -108,20 +108,8 @@ static inline unsigned int sysfs_type(st
return sd->s_flags & SYSFS_TYPE_MASK;
}
-static inline struct sysfs_dirent * sysfs_get(struct sysfs_dirent * sd)
-{
- if (sd) {
- WARN_ON(!atomic_read(&sd->s_count));
- atomic_inc(&sd->s_count);
- }
- return sd;
-}
-
-static inline void sysfs_put(struct sysfs_dirent * sd)
-{
- if (sd && atomic_dec_and_test(&sd->s_count))
- release_sysfs_dirent(sd);
-}
+struct sysfs_dirent * sysfs_get(struct sysfs_dirent * sd);
+void sysfs_put(struct sysfs_dirent * sd);
static inline int sysfs_is_shadowed_inode(struct inode *inode)
{
Index: tree0/include/linux/sysfs.h
===
--- tree0.orig/include/linux/sysfs.h
+++ tree0/include/linux/sysfs.h
@@ -87,9 +87,12 @@ struct sysfs_ops {
#define SYSFS_FLAG_MASK~SYSFS_TYPE_MASK
#define SYSFS_FLAG_REMOVED 0x0100
+#define SYSFS_FLAG_XXX 0x0200
#ifdef CONFIG_SYSFS
+extern struct kobject *sysfs_debug_me;
+
extern int sysfs_schedule_callback(struct kobject *kobj,
void (*func)(void *), void *data, struct module *owner);
Index: tree0/net/core/net-sysfs.c
===
--- tree0.orig/net/core/net-sysfs.c
+++ tree0/net/core/net-sysfs.c
@@ -472,6 +472,7 @@ int netdev_register_sysfs(struct net_dev
{
struct device *dev = &(net->dev);
struct attribute
Re: 2.6.22-rc6-mm1 -- BUG - EIP: [] sysfs_addrm_finish+0x1c2/0x226 SS:ESP 0068:c5ff9db8
Hello,
Andrew Morton wrote:
>> EIP is at sysfs_addrm_finish+0x1c2/0x226
>> eax: 0001 ebx: c5ff9dc0 ecx: c058aa40 edx: 0001
>> esi: c5ff9de8 edi: c37c3240 ebp: c5ff9e1c esp: c5ff9db8
>> ds: 007b es: 007b fs: gs: 0033 ss: 0068
>> Process modprobe (pid: 3519, ti=c5ff9000 task=c5ef15e0 task.ti=c5ff9000)
>> Stack: c03a3eda c5ff9e24 0001 dead4ead
>> c0657cf0
>> c046359d c5ff9de0 c5ff9de0 0001 dead4ead
>>
>> c0657cf0 c046359d c5ff9de0 c5ff9de0 c37c3240
>> c5ff9e24
>> Call Trace:
>> [] remove_dir+0x2e/0x35
>> [] __sysfs_remove_dir+0x5a/0x61
>> [] sysfs_remove_dir+0x2c/0x30
Hmm... That's weird. I tried to regenerate it here but mine unloads
happily. Can you apply the attached patch and report the resulting
messages when oops happens?
Thanks.
--
tejun
---
fs/sysfs/dir.c |8
1 file changed, 8 insertions(+)
Index: tree0/fs/sysfs/dir.c
===
--- tree0.orig/fs/sysfs/dir.c
+++ tree0/fs/sysfs/dir.c
@@ -268,6 +268,9 @@ static void sysfs_deactivate(struct sysf
DECLARE_COMPLETION_ONSTACK(wait);
int v;
+ if (sd->s_sibling || !(sd->s_flags & SYSFS_FLAG_REMOVED))
+ printk("XXX sysfs_deactivate: sd=%p s_sibling=%p
s_flags=0x%x\n",
+ sd, sd->s_sibling, sd->s_flags);
BUG_ON(sd->s_sibling || !(sd->s_flags & SYSFS_FLAG_REMOVED));
sd->s_sibling = (void *)&wait;
@@ -530,6 +533,9 @@ void sysfs_remove_one(struct sysfs_addrm
drop_nlink(acxt->parent_inode);
acxt->cnt++;
+
+ printk("XXX sysfs_remove_one: acxt=%p sd=%p s_flags=0x%x cnt=%d\n",
+ acxt, sd, sd->s_flags, acxt->cnt);
}
/**
@@ -624,6 +630,8 @@ int sysfs_addrm_finish(struct sysfs_addr
acxt->removed = sd->s_sibling;
sd->s_sibling = NULL;
+ printk("XXX sysfs_addrm_finish: acxt=%p sd=%p s_sibling=%p
s_flags=0x%x\n",
+ acxt, sd, sd->s_sibling, sd->s_flags);
sysfs_drop_dentry(sd);
sysfs_deactivate(sd);
sysfs_put(sd);
Re: 2.6.22-rc6-mm1 -- Problems with suspend/resume.
On Tue, 3 Jul 2007 20:45:41 -0700 "Miles Lane" <[EMAIL PROTECTED]> wrote: > Should I not report stuff like this when it is > generated after an OOPS? All bets are off if the kernel has oopsed. Reboot, see if the bug still happens without the earlier oops, perhaps. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.22-rc6-mm1 -- Problems with suspend/resume.
On 7/3/07, Andrew Morton <[EMAIL PROTECTED]> wrote: On Tue, 3 Jul 2007 18:09:29 -0700 "Miles Lane" <[EMAIL PROTECTED]> wrote: > Sorry. I don't know who else to include in the To: list. Should I > send this again with .config information? Would ps -Af help? Gosh, what a lot of output we generated. It's pretty digestible though. It looks like these are the problem: cat D 002B 0 5603 1 (NOTLB) c8102e4c 0096 80cc15ad 002b c1176c2c c8102e38 0046 c7fb2bc0 c7fb2d50 c265c100 80cc15ad 002b c8102e4c c7f12d00 c014b438 0001 c036759c c63b6914 c8102e68 c63b68e0 0246 c8102e88 c0367416 Call Trace: [] __mutex_lock_slowpath+0x1c7/0x32c [] mutex_lock+0x21/0x24 [] drm_vma_info+0x1f/0x310 [drm] [] proc_file_read+0x108/0x222 [] proc_reg_read+0x63/0x76 [] vfs_read+0xb0/0x139 [] sys_read+0x3d/0x72 [] sysenter_past_esp+0x6b/0xb5 [] 0xe410 === INFO: lockdep is turned off. tail D 002C 0 5646 1 (NOTLB) c811ce4c 0096 7137dc36 002c c1175f98 c811ce38 0046 c80e15e0 c80e1770 c265c100 7137dc36 002c c811ce4c c7f11e00 c014b438 0001 c036759c c63b6914 c811ce68 c63b68e0 0246 c811ce88 c0367416 Call Trace: [] __mutex_lock_slowpath+0x1c7/0x32c [] mutex_lock+0x21/0x24 [] drm_vma_info+0x1f/0x310 [drm] [] proc_file_read+0x108/0x222 [] proc_reg_read+0x63/0x76 [] vfs_read+0xb0/0x139 [] sys_read+0x3d/0x72 [] sysenter_past_esp+0x6b/0xb5 [] 0xe410 === INFO: lockdep is turned off. cat D 0033 0 5910 1 (NOTLB) c8107e4c 0096 24ccdd52 0033 c014b438 0001 c8107e14 c7e9ed60 c7e9eef0 c265c100 24ccdd52 0033 c8107e4c c7f11b80 c014b438 0001 c036759c c63b6914 c8107e68 c63b68e0 0246 c8107e88 c0367416 Call Trace: [] __mutex_lock_slowpath+0x1c7/0x32c [] mutex_lock+0x21/0x24 [] drm_vma_info+0x1f/0x310 [drm] [] proc_file_read+0x108/0x222 [] proc_reg_read+0x63/0x76 [] vfs_read+0xb0/0x139 [] sys_read+0x3d/0x72 [] sysenter_past_esp+0x6b/0xb5 [] 0xe410 === INFO: lockdep is turned off. cat D 0033 0 5926 1 (NOTLB) c8160e4c 0096 8cc85f27 0033 c117483c c8160e38 0046 c80e0af0 c80e0c80 c265c100 8cc85f27 0033 c8160e4c c7f13480 c014b438 0001 c036759c c63b6914 c8160e68 c63b68e0 0246 c8160e88 c0367416 Call Trace: [] __mutex_lock_slowpath+0x1c7/0x32c [] mutex_lock+0x21/0x24 [] drm_vma_info+0x1f/0x310 [drm] [] proc_file_read+0x108/0x222 [] proc_reg_read+0x63/0x76 [] vfs_read+0xb0/0x139 [] sys_read+0x3d/0x72 [] sysenter_past_esp+0x6b/0xb5 [] 0xe410 === INFO: lockdep is turned off. cat D 0034 0 5950 1 (NOTLB) c8084e4c 0096 39b9c536 0034 c117afbc c8084e38 0046 c6ce15e0 c6ce1770 c265c100 39b9c536 0034 c8084e4c c7f13200 c014b438 0001 c036759c c63b6914 c8084e68 c63b68e0 0246 c8084e88 c0367416 Call Trace: [] __mutex_lock_slowpath+0x1c7/0x32c [] mutex_lock+0x21/0x24 [] drm_vma_info+0x1f/0x310 [drm] [] proc_file_read+0x108/0x222 [] proc_reg_read+0x63/0x76 [] vfs_read+0xb0/0x139 [] sys_read+0x3d/0x72 [] sysenter_past_esp+0x6b/0xb5 [] 0xe410 === and I'm guessing that this kernel is one which has already oopsed in drm_vma_info()? If so, then problem solved: it oopsed with the lock held. If not, then perhaps we have another problem in DRM. Or the same one remanifesting. Yes, it is. Thanks. Should I not report stuff like this when it is generated after an OOPS? Sorry to trouble you. Miles - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.22-rc6-mm1 -- Problems with suspend/resume.
On Tue, 3 Jul 2007 18:09:29 -0700 "Miles Lane" <[EMAIL PROTECTED]> wrote: > Sorry. I don't know who else to include in the To: list. Should I > send this again with .config information? Would ps -Af help? Gosh, what a lot of output we generated. It's pretty digestible though. It looks like these are the problem: cat D 002B 0 5603 1 (NOTLB) c8102e4c 0096 80cc15ad 002b c1176c2c c8102e38 0046 c7fb2bc0 c7fb2d50 c265c100 80cc15ad 002b c8102e4c c7f12d00 c014b438 0001 c036759c c63b6914 c8102e68 c63b68e0 0246 c8102e88 c0367416 Call Trace: [] __mutex_lock_slowpath+0x1c7/0x32c [] mutex_lock+0x21/0x24 [] drm_vma_info+0x1f/0x310 [drm] [] proc_file_read+0x108/0x222 [] proc_reg_read+0x63/0x76 [] vfs_read+0xb0/0x139 [] sys_read+0x3d/0x72 [] sysenter_past_esp+0x6b/0xb5 [] 0xe410 === INFO: lockdep is turned off. tail D 002C 0 5646 1 (NOTLB) c811ce4c 0096 7137dc36 002c c1175f98 c811ce38 0046 c80e15e0 c80e1770 c265c100 7137dc36 002c c811ce4c c7f11e00 c014b438 0001 c036759c c63b6914 c811ce68 c63b68e0 0246 c811ce88 c0367416 Call Trace: [] __mutex_lock_slowpath+0x1c7/0x32c [] mutex_lock+0x21/0x24 [] drm_vma_info+0x1f/0x310 [drm] [] proc_file_read+0x108/0x222 [] proc_reg_read+0x63/0x76 [] vfs_read+0xb0/0x139 [] sys_read+0x3d/0x72 [] sysenter_past_esp+0x6b/0xb5 [] 0xe410 === INFO: lockdep is turned off. cat D 0033 0 5910 1 (NOTLB) c8107e4c 0096 24ccdd52 0033 c014b438 0001 c8107e14 c7e9ed60 c7e9eef0 c265c100 24ccdd52 0033 c8107e4c c7f11b80 c014b438 0001 c036759c c63b6914 c8107e68 c63b68e0 0246 c8107e88 c0367416 Call Trace: [] __mutex_lock_slowpath+0x1c7/0x32c [] mutex_lock+0x21/0x24 [] drm_vma_info+0x1f/0x310 [drm] [] proc_file_read+0x108/0x222 [] proc_reg_read+0x63/0x76 [] vfs_read+0xb0/0x139 [] sys_read+0x3d/0x72 [] sysenter_past_esp+0x6b/0xb5 [] 0xe410 === INFO: lockdep is turned off. cat D 0033 0 5926 1 (NOTLB) c8160e4c 0096 8cc85f27 0033 c117483c c8160e38 0046 c80e0af0 c80e0c80 c265c100 8cc85f27 0033 c8160e4c c7f13480 c014b438 0001 c036759c c63b6914 c8160e68 c63b68e0 0246 c8160e88 c0367416 Call Trace: [] __mutex_lock_slowpath+0x1c7/0x32c [] mutex_lock+0x21/0x24 [] drm_vma_info+0x1f/0x310 [drm] [] proc_file_read+0x108/0x222 [] proc_reg_read+0x63/0x76 [] vfs_read+0xb0/0x139 [] sys_read+0x3d/0x72 [] sysenter_past_esp+0x6b/0xb5 [] 0xe410 === INFO: lockdep is turned off. cat D 0034 0 5950 1 (NOTLB) c8084e4c 0096 39b9c536 0034 c117afbc c8084e38 0046 c6ce15e0 c6ce1770 c265c100 39b9c536 0034 c8084e4c c7f13200 c014b438 0001 c036759c c63b6914 c8084e68 c63b68e0 0246 c8084e88 c0367416 Call Trace: [] __mutex_lock_slowpath+0x1c7/0x32c [] mutex_lock+0x21/0x24 [] drm_vma_info+0x1f/0x310 [drm] [] proc_file_read+0x108/0x222 [] proc_reg_read+0x63/0x76 [] vfs_read+0xb0/0x139 [] sys_read+0x3d/0x72 [] sysenter_past_esp+0x6b/0xb5 [] 0xe410 === and I'm guessing that this kernel is one which has already oopsed in drm_vma_info()? If so, then problem solved: it oopsed with the lock held. If not, then perhaps we have another problem in DRM. Or the same one remanifesting. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.22-rc6-mm1 -- BUG - EIP: [] drm_vma_info+0x2a5/0x310 [drm] SS:ESP 0068:c80cde9c
On Tue, 3 Jul 2007 15:59:08 -0700 "Miles Lane" <[EMAIL PROTECTED]> wrote: > I ran the command: > find /proc | xargs grep a > > BUG: unable to handle kernel NULL pointer dereference at virtual > address > printing eip: > f8ac1350 > *pde = > Oops: [#1] > SMP > Modules linked in: arc4 ecb blkcipher cryptomgr crypto_algapi > ieee80211_crypt_wep bluetooth i915 drm acpi_cpufreq > cpufreq_conservative cpufreq_powersave cpufreq_performance ac battery > video output button processor container firewire_sbp2 parport_pc lp > parport pcmcia snd_intel8x0 snd_ac97_codec ac97_bus snd_pcm_oss > snd_mixer_oss snd_pcm snd_seq_dummy snd_seq_oss yenta_socket > rsrc_nonstatic sdhci snd_seq_midi_event ipw2200 tifm_7xx1 mmc_core > pcmcia_core ieee80211 ieee80211_crypt tifm_core snd_seq snd_timer > snd_seq_device evdev shpchp snd iTCO_wdt iTCO_vendor_support > pci_hotplug soundcore snd_page_alloc firewire_ohci firewire_core > crc_itu_t 8139too ehci_hcd uhci_hcd usbcore fan > CPU:0 > EIP:0060:[]Not tainted VLI > EFLAGS: 00010283 (2.6.22-rc6-mm1 #5) > EIP is at drm_vma_info+0x2a5/0x310 [drm] > eax: ebx: c80cdf38 ecx: edx: > esi: 8000 edi: c467e000 ebp: c80cdf0c esp: c80cde9c > ds: 007b es: 007b fs: 00d8 gs: 0033 ss: 0068 > Process grep (pid: 5172, ti=c80cd000 task=c7e9ed60 task.ti=c80cd000) > Stack: c467e000 f8ac595a f800 3800 c0526e9c c80cdefc >c0165700 0044 0001 c7e9ed60 c467e000 c63b68e0 >c1195548 0035 c7e9f328 0001 000800d0 > Call Trace: > [] proc_file_read+0x108/0x222 > [] proc_reg_read+0x63/0x76 > [] vfs_read+0xb0/0x139 > [] sys_read+0x3d/0x72 > [] sysenter_past_esp+0x6b/0xb5 > [] 0xe410 > === > INFO: lockdep is turned off. > Code: 24 04 c9 59 ac f8 8b 45 c8 01 d8 89 04 24 e8 3c 66 74 c7 01 c3 > 89 5d d8 81 fb b0 0f 00 00 77 4a 8b 45 d4 8b 00 89 45 d4 8b 55 d4 <8b> > 02 0f 18 00 90 8b 45 10 05 98 01 00 00 39 c2 0f 85 e7 fd ff > EIP: [] drm_vma_info+0x2a5/0x310 [drm] SS:ESP 0068:c80cde9c Dave, your code is being bad. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.22-rc6-mm1
On Sun, 1 Jul 2007 03:53:08 +0200 (CEST) Roman Zippel <[EMAIL PROTECTED]> wrote: > Hi, > > On Sat, 30 Jun 2007, Andrew Morton wrote: > > > > > I continue to believe that kbuild's lets-trash-your-symlink behaviour is > > > > obnoxious, but I was unable to persuade anyone else of this. > > > > > > I thought we fixed that long time ago?!?! > > > > Nope, a simple `make oldconfig' breaks the symlink. > > KCONFIG_OVERWRITECONFIG was added especially for you. :-) > But nobody told me! It works, thanks ;) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.22-rc6-mm1 -- BUG - EIP: [] sysfs_addrm_finish+0x1c2/0x226 SS:ESP 0068:c5ff9db8
On Tue, 3 Jul 2007 09:32:32 -0700 "Miles Lane" <[EMAIL PROTECTED]> wrote: > I tried to remove the ipw2200 module and hit this BUG. > > kernel BUG at fs/sysfs/dir.c:271! > invalid opcode: [#1] > PREEMPT > Modules linked in: i915 drm cpufreq_conservative cpufreq_powersave > cpufreq_performance firewire_sbp2 parport_pc lp parport snd_intel8x0 > snd_ac97_codec ac97_bus pcmcia snd_pcm_oss snd_mixer_oss snd_pcm > snd_seq_dummy sdhci ipw2200 mmc_core yenta_socket rsrc_nonstatic > pcmcia_core ieee80211 ieee80211_crypt snd_seq_oss snd_seq_midi_event > snd_seq snd_timer snd_seq_device snd iTCO_wdt iTCO_vendor_support > soundcore snd_page_alloc firewire_ohci firewire_core crc_itu_t > ehci_hcd uhci_hcd usbcore > CPU:0 > EIP:0060:[]Not tainted VLI > EFLAGS: 00010202 (2.6.22-rc6-mm1 #2) > EIP is at sysfs_addrm_finish+0x1c2/0x226 > eax: 0001 ebx: c5ff9dc0 ecx: c058aa40 edx: 0001 > esi: c5ff9de8 edi: c37c3240 ebp: c5ff9e1c esp: c5ff9db8 > ds: 007b es: 007b fs: gs: 0033 ss: 0068 > Process modprobe (pid: 3519, ti=c5ff9000 task=c5ef15e0 task.ti=c5ff9000) > Stack: c03a3eda c5ff9e24 0001 dead4ead c0657cf0 > c046359d c5ff9de0 c5ff9de0 0001 dead4ead > c0657cf0 c046359d c5ff9de0 c5ff9de0 c37c3240 c5ff9e24 > Call Trace: > [] remove_dir+0x2e/0x35 > [] __sysfs_remove_dir+0x5a/0x61 > [] sysfs_remove_dir+0x2c/0x30 > [] kobject_del+0xf/0x19 > [] device_del+0x254/0x27a > [] netdev_unregister_sysfs+0x1b/0x1e > [] unregister_netdevice+0x1c3/0x1fe > [] unregister_netdev+0x12/0x1a > [] ipw_pci_remove+0x59/0x1c4 [ipw2200] > [] pci_device_remove+0x19/0x39 > [] __device_release_driver+0x74/0x90 > [] driver_detach+0x9a/0xd7 > [] bus_remove_driver+0x5d/0x79 > [] driver_unregister+0x8/0xa > [] pci_unregister_driver+0x13/0x55 > [] ipw_exit+0x1c/0x1e [ipw2200] > [] sys_delete_module+0x1bd/0x22a > [] sysenter_past_esp+0x5f/0x99 > [] 0xe410 > === > INFO: lockdep is turned off. > Code: d8 e8 30 58 09 00 ba 01 00 00 00 83 7f 0c 00 75 0c 8b 57 1c 80 > f6 01 c1 ea 08 83 e2 01 b8 40 aa 58 c0 e8 8f 5e 0a 00 85 c0 74 04 <0f> > 0b eb fe 8d 55 a4 89 57 0c b8 00 00 00 80 0f c1 47 04 85 c0 > EIP: [] sysfs_addrm_finish+0x1c2/0x226 SS:ESP 0068:c5ff9db8 OK, thanks. That's --- a/fs/sysfs/dir.c +++ b/fs/sysfs/dir.c @@ -171,7 +171,7 @@ void sysfs_deactivate(struct sysfs_diren DECLARE_COMPLETION_ONSTACK(wait); int v; - BUG_ON(sd->s_sibling); + BUG_ON(sd->s_sibling || !(sd->s_flags & SYSFS_FLAG_REMOVED)); sd->s_sibling = (void *)&wait; /* atomic_add_return() is a mb(), put_active() will always see added by Tejun's gregkh-driver-sysfs-implement-sysfs_flag_removed-flag.patch. Probably it has tripped up some problem in the ipw2200 driver? btw, we see here why BUG_ON(foo || bar); is inferior to BUG_ON(foo); BUG_ON(bar); - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.22-rc6-mm1 bad_page events.
On Tue, Jul 03, 2007 at 11:37:47AM -0400, Mathieu Desnoyers wrote:
> Hi Alan,
>
> I already sent a fix to Andrew and Andi for this (hrm, forget to CC
> lkml on the original message):
>
>
> x86_64 mm cpa cache flush fix
>
> X86_64 and i386 cpa cache flush fix:
>
> list_del the deferred list entries to poison their pointers.
> clear the flag for every page put in the list.
>
Hi Mathieu,
I've tried the patch on rc6-mm1, but it doesn't seem to fix the
problem. From what I understood, the bad_page() is called on PG_reserved
being set (flags:0x0400), not the lru pointer being not NULL or
PG_arch_1 being set.
Regards,
Frederik
> Signed-off-by: Mathieu Desnoyers <[EMAIL PROTECTED]>
> CC: Andi Kleen <[EMAIL PROTECTED]>
[...]
> flush_map(&l);
> list_for_each_entry_safe(pg, next, &l, lru) {
> + clear_bit(PG_arch_1, &pg->flags);
> + list_del(&pg->lru);
> if (page_private(pg) != 0)
> continue;
> ClearPagePrivate(pg);
> - clear_bit(PG_arch_1, &pg->flags);
> __free_page(pg);
> }
> }
[...]
> * Alan Cox ([EMAIL PROTECTED]) wrote:
> > X86 32bit with lots of debug turned on I get this:
[...]
> > Bad page state in process 'swapper'
> > page:c1c0 flags:0x0400 mapping: mapcount:0 count:0
> > Trying to fix it up, but a reboot is needed
> > Backtrace:
> > [] bad_page+0x6c/0x100
> > [] free_hot_cold_page+0x5d/0x140
> > [] global_flush_tlb+0x112/0x130
> > [] init_post+0xd/0xe0
> > [] kernel_init+0x216/0x220
> > [] schedule_tail+0x0/0xe0
> > [] kernel_init+0x0/0x220
> > [] kernel_init+0x0/0x220
> > [] kernel_thread_helper+0x7/0x10
> > ===
> > Hexdump:
> > 000: 00 06 00 00 01 00 00 00 ff ff ff ff 0f 00 00 00
> > 010: 00 00 00 00 00 00 00 00 78 00 00 c1 b8 00 00 c1
> > 020: 00 06 00 00 01 00 00 00 ff ff ff ff a7 03 00 00
> > 030: 00 00 00 00 00 00 00 00 98 00 00 c1 d8 00 00 c1
> > 040: 00 04 00 00 00 00 00 00 ff ff ff ff 00 00 00 00
> > 050: 00 00 00 00 00 00 00 00 b8 00 00 c1 f8 00 00 c1
> > 060: 00 06 00 00 01 00 00 00 ff ff ff ff 00 04 00 00
> > 070: 00 00 00 00 00 00 00 00 d8 00 00 c1 18 01 00 c1
> > 080: 00 06 00 00 01 00 00 00 ff ff ff ff 9c 03 00 00
> > 090: 00 00 00 00 00 00 00 00 f8 00 00 c1 38 01 00 c1
> > 0a0: 00 06 00 00 01 00 00 00 ff ff ff ff 00 04 00 00
> > 0b0: 00 00 00 00 00 00 00 00 18 01 00 c1 58 01 00 c1
> > -
> > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> > the body of a message to [EMAIL PROTECTED]
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
> > Please read the FAQ at http://www.tux.org/lkml/
> >
>
> --
> Mathieu Desnoyers
> Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal
> OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.22-rc6-mm1 bad_page events.
On Tue, 3 Jul 2007 15:06:56 +0100 Alan Cox <[EMAIL PROTECTED]> wrote: > X86 32bit with lots of debug turned on I get this: > > > > Freeing unused kernel memory: 156k freed > Write protecting the kernel text: 1668k > Write protecting the kernel read-only data: 719k > Bad page state in process 'swapper' > page:c1c0 flags:0x0400 mapping: mapcount:0 count:0 > Trying to fix it up, but a reboot is needed > Backtrace: > [] bad_page+0x6c/0x100 > [] free_hot_cold_page+0x5d/0x140 > [] global_flush_tlb+0x112/0x130 > [] init_post+0xd/0xe0 > [] kernel_init+0x216/0x220 > [] schedule_tail+0x0/0xe0 > [] kernel_init+0x0/0x220 > [] kernel_init+0x0/0x220 > [] kernel_thread_helper+0x7/0x10 > === > Hexdump: > 000: 00 06 00 00 01 00 00 00 ff ff ff ff 0f 00 00 00 > 010: 00 00 00 00 00 00 00 00 78 00 00 c1 b8 00 00 c1 > 020: 00 06 00 00 01 00 00 00 ff ff ff ff a7 03 00 00 > 030: 00 00 00 00 00 00 00 00 98 00 00 c1 d8 00 00 c1 > 040: 00 04 00 00 00 00 00 00 ff ff ff ff 00 00 00 00 > 050: 00 00 00 00 00 00 00 00 b8 00 00 c1 f8 00 00 c1 > 060: 00 06 00 00 01 00 00 00 ff ff ff ff 00 04 00 00 > 070: 00 00 00 00 00 00 00 00 d8 00 00 c1 18 01 00 c1 > 080: 00 06 00 00 01 00 00 00 ff ff ff ff 9c 03 00 00 > 090: 00 00 00 00 00 00 00 00 f8 00 00 c1 38 01 00 c1 > 0a0: 00 06 00 00 01 00 00 00 ff ff ff ff 00 04 00 00 > 0b0: 00 00 00 00 00 00 00 00 18 01 00 c1 58 01 00 c1 Wow, freeing lots of PageReserved() pages. I assume via free_initmem(), but it's strange that free_initmem() makes no appearance in the backtrace. I don't know which change could have caused this. Nobody else has reported this, but 32-on-64 might be pretty rare. If you can send the config I'll see if it happens here? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.22-rc6-mm1 bad_page events.
Hi Alan,
I already sent a fix to Andrew and Andi for this (hrm, forget to CC
lkml on the original message):
x86_64 mm cpa cache flush fix
X86_64 and i386 cpa cache flush fix:
list_del the deferred list entries to poison their pointers.
clear the flag for every page put in the list.
Signed-off-by: Mathieu Desnoyers <[EMAIL PROTECTED]>
CC: Andi Kleen <[EMAIL PROTECTED]>
---
arch/i386/mm/pageattr.c |3 ++-
arch/x86_64/mm/pageattr.c |3 ++-
2 files changed, 4 insertions(+), 2 deletions(-)
Index: linux-2.6-lttng/arch/i386/mm/pageattr.c
===
--- linux-2.6-lttng.orig/arch/i386/mm/pageattr.c2007-06-29
12:33:47.0 -0400
+++ linux-2.6-lttng/arch/i386/mm/pageattr.c 2007-06-29 12:35:45.0
-0400
@@ -245,10 +245,11 @@
spin_unlock_irq(&cpa_lock);
flush_map(&l);
list_for_each_entry_safe(pg, next, &l, lru) {
+ clear_bit(PG_arch_1, &pg->flags);
+ list_del(&pg->lru);
if (page_private(pg) != 0)
continue;
ClearPagePrivate(pg);
- clear_bit(PG_arch_1, &pg->flags);
__free_page(pg);
}
}
Index: linux-2.6-lttng/arch/x86_64/mm/pageattr.c
===
--- linux-2.6-lttng.orig/arch/x86_64/mm/pageattr.c 2007-06-29
12:33:51.0 -0400
+++ linux-2.6-lttng/arch/x86_64/mm/pageattr.c 2007-06-29 12:34:57.0
-0400
@@ -235,10 +235,11 @@
flush_map(&l);
list_for_each_entry_safe(pg, next, &l, lru) {
+ clear_bit(PG_arch_1, &pg->flags);
+ list_del(&pg->lru);
if (page_private(pg) != 0)
continue;
ClearPagePrivate(pg);
- clear_bit(PG_arch_1, &pg->flags);
__free_page(pg);
}
}
* Alan Cox ([EMAIL PROTECTED]) wrote:
> X86 32bit with lots of debug turned on I get this:
>
>
>
> Freeing unused kernel memory: 156k freed
> Write protecting the kernel text: 1668k
> Write protecting the kernel read-only data: 719k
> Bad page state in process 'swapper'
> page:c1c0 flags:0x0400 mapping: mapcount:0 count:0
> Trying to fix it up, but a reboot is needed
> Backtrace:
> [] bad_page+0x6c/0x100
> [] free_hot_cold_page+0x5d/0x140
> [] global_flush_tlb+0x112/0x130
> [] init_post+0xd/0xe0
> [] kernel_init+0x216/0x220
> [] schedule_tail+0x0/0xe0
> [] kernel_init+0x0/0x220
> [] kernel_init+0x0/0x220
> [] kernel_thread_helper+0x7/0x10
> ===
> Hexdump:
> 000: 00 06 00 00 01 00 00 00 ff ff ff ff 0f 00 00 00
> 010: 00 00 00 00 00 00 00 00 78 00 00 c1 b8 00 00 c1
> 020: 00 06 00 00 01 00 00 00 ff ff ff ff a7 03 00 00
> 030: 00 00 00 00 00 00 00 00 98 00 00 c1 d8 00 00 c1
> 040: 00 04 00 00 00 00 00 00 ff ff ff ff 00 00 00 00
> 050: 00 00 00 00 00 00 00 00 b8 00 00 c1 f8 00 00 c1
> 060: 00 06 00 00 01 00 00 00 ff ff ff ff 00 04 00 00
> 070: 00 00 00 00 00 00 00 00 d8 00 00 c1 18 01 00 c1
> 080: 00 06 00 00 01 00 00 00 ff ff ff ff 9c 03 00 00
> 090: 00 00 00 00 00 00 00 00 f8 00 00 c1 38 01 00 c1
> 0a0: 00 06 00 00 01 00 00 00 ff ff ff ff 00 04 00 00
> 0b0: 00 00 00 00 00 00 00 00 18 01 00 c1 58 01 00 c1
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
--
Mathieu Desnoyers
Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.22-rc6-mm1
Jason Wessel writes: > I suppose the argument could be made to remove the check in the compiled > file, but it does serve as a way to protect kgdb for now if someone > tries to hard compile in xmon and kgdb. Completely unpredictable > results will occur with the debugger unless some pieces are fixed. I > would rather make sure until that happens there is no way head down the > rat hole. It should all work provided kgdb plays nicely. We used to be able to compile in both xmon and kdb and select at runtime which one gets used. > That issue aside would it be useful to have xmon+kgdb? After having > looked at the hook points for xmon, if a command was added to xmon to > provide an "detach" it would be easy enough to have kgdb and xmon in the > same kernel. Obviously only one or the other can be used at any given time. Well, xmon_init(0) will do a detach. However, I don't see that it is needed; there is plenty of flexibility to choose to have xmon or not using the CONFIG_XMON_DEFAULT config option and the xmon= boot command line option. Paul. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.22-rc6-mm1
Sergei Shtylyov wrote: Hello. Jason Wessel wrote: allmodconfig on powerpc (iMac g3) fails due to git-kgdb.patch. allmodconfig defaults should be changed? CC arch/powerpc/kernel/kgdb.o arch/powerpc/kernel/kgdb.c:485:2: error: #error Both XMON and KGDB selected in .config. Unselect one of them. make[1]: *** [arch/powerpc/kernel/kgdb.o] Blad 1 make: *** [arch/powerpc/kernel] Blad 2 This patch does not seem complete as the #error that was tiggering has not been deleleted from arch/powerpc/kernel/kgdb.c (and not it's useless) I suppose the argument could be made to remove the check in the compiled file, but it does serve as a way to protect kgdb for now if someone tries to hard compile in xmon and kgdb. Completely unpredictable results will occur with the debugger unless some pieces are fixed. I would rather make sure until that happens there is no way head down the rat hole. That issue aside would it be useful to have xmon+kgdb? After having looked at the hook points for xmon, if a command was added to xmon to provide an "detach" it would be easy enough to have kgdb and xmon in the same kernel. Obviously only one or the other can be used at any given time. Jason. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.22-rc6-mm1
Hello. Jason Wessel wrote: allmodconfig on powerpc (iMac g3) fails due to git-kgdb.patch. allmodconfig defaults should be changed? CC arch/powerpc/kernel/kgdb.o arch/powerpc/kernel/kgdb.c:485:2: error: #error Both XMON and KGDB selected in .config. Unselect one of them. make[1]: *** [arch/powerpc/kernel/kgdb.o] Blad 1 make: *** [arch/powerpc/kernel] Blad 2 I'm not sure if this will work out but maybe it's worth to disable XMON if KGDB is selected, like this? config XMON bool "Include xmon kernel debugger" depends on DEBUGGER && !KGDB It did not seem that you can make a radio button / multi-select kernel config option unless the options are in the same Kconfig file. Given that xmon and kgdb are mutually exclusive at the moment. What Sergei mentioned is the fix that needs to be used for the time being. Attached is the patch I put in the for_mm branch in the linux-2.6-kgdb git tree. Jason. xmon_or_kgdb.patch From: Jason Wessel <[EMAIL PROTECTED]> Subject: [PATCH] Turn off xmon if kgdb is active on ppc and powerpc Xmon and kgdb are mutuall exclusive at the moment so xmon should be turned off in the kernel config options if kgdb selected. The case with "make allmodconfig" was failing and this patch addresses the problem. Signed-off-by: Jason Wessel <[EMAIL PROTECTED]> --- arch/powerpc/Kconfig.debug |2 +- arch/ppc/Kconfig.debug |2 +- 2 files changed, 2 insertions(+), 2 deletions(-) This patch does not seem complete as the #error that was tiggering has not been deleleted from arch/powerpc/kernel/kgdb.c (and not it's useless) WBR, Sergei - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.22-rc6-mm1
Sergei Shtylyov wrote: Hello. Mariusz Kozlowski wrote: allmodconfig on powerpc (iMac g3) fails due to git-kgdb.patch. allmodconfig defaults should be changed? CC arch/powerpc/kernel/kgdb.o arch/powerpc/kernel/kgdb.c:485:2: error: #error Both XMON and KGDB selected in .config. Unselect one of them. make[1]: *** [arch/powerpc/kernel/kgdb.o] Blad 1 make: *** [arch/powerpc/kernel] Blad 2 I'm not sure if this will work out but maybe it's worth to disable XMON if KGDB is selected, like this? config XMON bool "Include xmon kernel debugger" depends on DEBUGGER && !KGDB It did not seem that you can make a radio button / multi-select kernel config option unless the options are in the same Kconfig file. Given that xmon and kgdb are mutually exclusive at the moment. What Sergei mentioned is the fix that needs to be used for the time being. Attached is the patch I put in the for_mm branch in the linux-2.6-kgdb git tree. Jason. xmon_or_kgdb.patch From: Jason Wessel <[EMAIL PROTECTED]> Subject: [PATCH] Turn off xmon if kgdb is active on ppc and powerpc Xmon and kgdb are mutuall exclusive at the moment so xmon should be turned off in the kernel config options if kgdb selected. The case with "make allmodconfig" was failing and this patch addresses the problem. Signed-off-by: Jason Wessel <[EMAIL PROTECTED]> --- arch/powerpc/Kconfig.debug |2 +- arch/ppc/Kconfig.debug |2 +- 2 files changed, 2 insertions(+), 2 deletions(-) Index: linux-2.6-kgdb/arch/powerpc/Kconfig.debug === --- linux-2.6-kgdb.orig/arch/powerpc/Kconfig.debug +++ linux-2.6-kgdb/arch/powerpc/Kconfig.debug @@ -43,7 +43,7 @@ config HCALL_STATS config XMON bool "Include xmon kernel debugger" - depends on DEBUG_KERNEL + depends on DEBUG_KERNEL && !KGDB help Include in-kernel hooks for the xmon kernel monitor/debugger. Unless you are intending to debug the kernel, say N here. Index: linux-2.6-kgdb/arch/ppc/Kconfig.debug === --- linux-2.6-kgdb.orig/arch/ppc/Kconfig.debug +++ linux-2.6-kgdb/arch/ppc/Kconfig.debug @@ -4,7 +4,7 @@ source "lib/Kconfig.debug" config XMON bool "Include xmon kernel debugger" - depends on DEBUG_KERNEL + depends on DEBUG_KERNEL && !KGDB help Include in-kernel hooks for the xmon kernel monitor/debugger. Unless you are intending to debug the kernel, say N here.
Re: 2.6.22-rc6-mm1: TUNER_TEA5761 kconfig fixes
Adrian Bunk wrote: > On Thu, Jun 28, 2007 at 03:43:21AM -0700, Andrew Morton wrote: > >> ... >> Changes since 2.6.22-rc4-mm2: >> ... >> git-dvb.patch >> ... >> git trees >> ... >> > > > The following doesn't make much sense: > > drivers/media/video/Kconfig: > ... > config TUNER_TEA5761 > tristate "TEA 5761 radio tuner (EXPERIMENTAL)" > ... > > drivers/media/video/Makefile: > ... > ifneq ($(CONFIG_TUNER_TEA5761),) > tuner-objs += tea5761.o > endif > ... > > With this setup, TUNER_TEA5761=m is equivalent to TUNER_TEA5761=y. > > This patch therefore changes TUNER_TEA5761 to a bool. > > The missing dependency on EXPERIMENTAL the prompt text indicates also > gets added by this patch. > > Additionally, the Makefile entry can now be written in a more compact way. > > Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]> > Acked-by: Michael Krufky <[EMAIL PROTECTED]> Thanks, Adrian Mauro, I'll push this into hg and send you a pull request. > --- > > BTW: tea5761.c is currently completely unused. > > drivers/media/video/Kconfig |3 ++- > drivers/media/video/Makefile |4 +--- > 2 files changed, 3 insertions(+), 4 deletions(-) > > --- linux-2.6.22-rc6-mm1/drivers/media/video/Kconfig.old 2007-06-30 > 03:51:13.0 +0200 > +++ linux-2.6.22-rc6-mm1/drivers/media/video/Kconfig 2007-06-30 > 03:51:40.0 +0200 > @@ -490,7 +490,8 @@ > If in doubt, say N. > > config TUNER_TEA5761 > - tristate "TEA 5761 radio tuner (EXPERIMENTAL)" > + bool "TEA 5761 radio tuner (EXPERIMENTAL)" > + depends on EXPERIMENTAL > depends on I2C > select VIDEO_TUNER > help > --- linux-2.6.22-rc6-mm1/drivers/media/video/Makefile.old 2007-06-30 > 03:52:00.0 +0200 > +++ linux-2.6.22-rc6-mm1/drivers/media/video/Makefile 2007-06-30 > 03:53:25.0 +0200 > @@ -7,9 +7,7 @@ > tuner-objs := tuner-core.o tuner-types.o tuner-simple.o \ > mt20xx.o tda8290.o tea5767.o tda9887.o > > -ifneq ($(CONFIG_TUNER_TEA5761),) > - tuner-objs += tea5761.o > -endif > +tuner-$(CONFIG_TUNER_TEA5761)+= tea5761.o > > msp3400-objs := msp3400-driver.o msp3400-kthreads.o > > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.22-rc6-mm1: Xen: WARNING: Absolute relocations present
Eric W. Biederman wrote:
Jeremy Fitzhardinge <[EMAIL PROTECTED]> writes:
Adrian Bunk wrote:
<-- snip -->
...
RELOCS arch/i386/boot/compressed/vmlinux.relocs
WARNING: Absolute relocations present
Offset Info Type Sym.Value Sym.Name
c0101f80 020c6501 R_386_32 xen_irq_disable_direct_reloc
c0101f9a 0221ea01 R_386_32 xen_save_fl_direct_reloc
Actually I have to ask. How in the world are these absolute symbols
ok from a relocation perspective.
If the kernel is not running at 0xc010 the offset value looks like
it will be completely bogus.
Notice they're absolute 0.
Maybe those are ok, but if you could please explain why those are
false positives I would appreciate it. (Especially in your patch
description).
If these are indeed false positives the patch looks ok.
Subject: xen: suppress abs symbol warnings for unused reloc pointers
arch/i386/xen/xen-asm.S defines some small pieces of code which are
used to implement a few paravirt_ops. They're designed so they can be
used either in-place, or be inline patched into their callsites if
there's enough space.
Some of those operations need to make calls out (specifically, if you
re-enable events [interrupts], and there's a pending event at that
time). These calls need the call instruction to be relocated if the
code is patched inline. In this case xen_foo_reloc is a section-relative
symbol which points to xen_foo's required relocation.
Other operations have no need of a relocation, and so their
corresponding xen_bar_reloc is absolute 0. These are the cases which
are triggering the warning.
This patch adds those symbols to the list of safe abs symbols.
Signed-off-by: Jeremy Fitzhardinge <[EMAIL PROTECTED]>
Cc: Adrian Bunk <[EMAIL PROTECTED]>
---
arch/i386/boot/compressed/relocs.c |2 ++
1 file changed, 2 insertions(+)
===
--- a/arch/i386/boot/compressed/relocs.c
+++ b/arch/i386/boot/compressed/relocs.c
@@ -31,6 +31,8 @@ static const char* safe_abs_relocs[] = {
"__kernel_rt_sigreturn",
"__kernel_sigreturn",
"SYSENTER_RETURN",
+ "xen_irq_disable_direct_reloc",
+ "xen_save_fl_direct_reloc",
};
static int is_safe_abs_reloc(const char* sym_name)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.22-rc6-mm1: Xen: WARNING: Absolute relocations present
Jeremy Fitzhardinge <[EMAIL PROTECTED]> writes: > Eric W. Biederman wrote: >> Jeremy Fitzhardinge <[EMAIL PROTECTED]> writes: >> >> >>> Adrian Bunk wrote: >>> <-- snip --> ... RELOCS arch/i386/boot/compressed/vmlinux.relocs WARNING: Absolute relocations present Offset Info Type Sym.Value Sym.Name c0101f80 020c6501 R_386_32 xen_irq_disable_direct_reloc c0101f9a 0221ea01 R_386_32 xen_save_fl_direct_reloc ... <-- snip --> >>> Hm. Those are false alarms. I guess I could do something to hide them, but >>> there's nothing inherently wrong with correctly used abs symbols. Is there >>> someway to whitelist them? >>> >> >> Yes. Just add them to arch/i386/boot/compressed/relocs.c safe_abs_syms. >> > > OK, how's this? > > Subject: xen: suppress abs symbol warnings for unused reloc pointers > > The Xen code generates some abs symbols which are OK from a relocation > perspective. Actually I have to ask. How in the world are these absolute symbols ok from a relocation perspective. If the kernel is not running at 0xc010 the offset value looks like it will be completely bogus. Maybe those are ok, but if you could please explain why those are false positives I would appreciate it. (Especially in your patch description). If these are indeed false positives the patch looks ok. Eric - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.22-rc6-mm1: Xen: WARNING: Absolute relocations present
On Sun, Jul 01, 2007 at 09:33:08AM -0700, Jeremy Fitzhardinge wrote: > Eric W. Biederman wrote: >> Jeremy Fitzhardinge <[EMAIL PROTECTED]> writes: >> >> >>> Adrian Bunk wrote: >>> <-- snip --> ... RELOCS arch/i386/boot/compressed/vmlinux.relocs WARNING: Absolute relocations present Offset Info Type Sym.Value Sym.Name c0101f80 020c6501 R_386_32 xen_irq_disable_direct_reloc c0101f9a 0221ea01 R_386_32 xen_save_fl_direct_reloc ... <-- snip --> >>> Hm. Those are false alarms. I guess I could do something to hide them, >>> but >>> there's nothing inherently wrong with correctly used abs symbols. Is >>> there >>> someway to whitelist them? >>> >> >> Yes. Just add them to arch/i386/boot/compressed/relocs.c safe_abs_syms. >> > > OK, how's this? > > Subject: xen: suppress abs symbol warnings for unused reloc pointers >... Thanks, works for me. cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.22-rc6-mm1: Xen: WARNING: Absolute relocations present
Eric W. Biederman wrote:
Jeremy Fitzhardinge <[EMAIL PROTECTED]> writes:
Adrian Bunk wrote:
<-- snip -->
...
RELOCS arch/i386/boot/compressed/vmlinux.relocs
WARNING: Absolute relocations present
Offset Info Type Sym.Value Sym.Name
c0101f80 020c6501 R_386_32 xen_irq_disable_direct_reloc
c0101f9a 0221ea01 R_386_32 xen_save_fl_direct_reloc
...
<-- snip -->
Hm. Those are false alarms. I guess I could do something to hide them, but
there's nothing inherently wrong with correctly used abs symbols. Is there
someway to whitelist them?
Yes. Just add them to arch/i386/boot/compressed/relocs.c safe_abs_syms.
OK, how's this?
Subject: xen: suppress abs symbol warnings for unused reloc pointers
The Xen code generates some abs symbols which are OK from a relocation
perspective.
Signed-off-by: Jeremy Fitzhardinge <[EMAIL PROTECTED]>
Cc: Adrian Bunk <[EMAIL PROTECTED]>
---
arch/i386/boot/compressed/relocs.c |2 ++
1 file changed, 2 insertions(+)
===
--- a/arch/i386/boot/compressed/relocs.c
+++ b/arch/i386/boot/compressed/relocs.c
@@ -31,6 +31,8 @@ static const char* safe_abs_relocs[] = {
"__kernel_rt_sigreturn",
"__kernel_sigreturn",
"SYSENTER_RETURN",
+ "xen_irq_disable_direct_reloc",
+ "xen_save_fl_direct_reloc",
};
static int is_safe_abs_reloc(const char* sym_name)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.22-rc6-mm1: Xen: WARNING: Absolute relocations present
Jeremy Fitzhardinge <[EMAIL PROTECTED]> writes: > Adrian Bunk wrote: >> <-- snip --> >> >> ... >> RELOCS arch/i386/boot/compressed/vmlinux.relocs >> WARNING: Absolute relocations present >> Offset Info Type Sym.Value Sym.Name >> c0101f80 020c6501 R_386_32 xen_irq_disable_direct_reloc >> c0101f9a 0221ea01 R_386_32 xen_save_fl_direct_reloc >> ... >> >> <-- snip --> >> > > Hm. Those are false alarms. I guess I could do something to hide them, but > there's nothing inherently wrong with correctly used abs symbols. Is there > someway to whitelist them? Yes. Just add them to arch/i386/boot/compressed/relocs.c safe_abs_syms. Eric - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.22-rc6-mm1
On Sun, Jul 01, 2007 at 11:01:45AM +0530, Satyam Sharma wrote: > On 7/1/07, Sam Ravnborg <[EMAIL PROTECTED]> wrote: > >[...] > >I am heading for vacation for 20 days without Internet (real vacation :-)) > > I hope I'm not late in catching you here ... > > >By the way - kbuild.git is lacking behind on patches. > >I have several queded from other peopel and have more in the works myself. > > ... is http://lkml.org/lkml/2007/6/23/116/ one of those queued up too? Nope. I usually does not include section mismatch fixes in the kbuild.git tree but leave that to the maintainers in the particular areas. This patch should go in via SH maintainer since this is sh specific driver(s). Sam - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.22-rc6-mm1
On 7/1/07, Sam Ravnborg <[EMAIL PROTECTED]> wrote: [...] I am heading for vacation for 20 days without Internet (real vacation :-)) I hope I'm not late in catching you here ... By the way - kbuild.git is lacking behind on patches. I have several queded from other peopel and have more in the works myself. ... is http://lkml.org/lkml/2007/6/23/116/ one of those queued up too? Note that that patch is also: Tested-by: Adrian McMenamin <[EMAIL PROTECTED]> As you can see from: http://readlist.com/lists/vger.kernel.org/linux-kernel/72/361641.html [ I think I'll utilize the next few days going through my patches-to-do list and resurrecting old patches-that-fell-into-lkml-blackhole ... ] Satyam - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.22-rc6-mm1
Hi, On Sat, 30 Jun 2007, Andrew Morton wrote: > > > I continue to believe that kbuild's lets-trash-your-symlink behaviour is > > > obnoxious, but I was unable to persuade anyone else of this. > > > > I thought we fixed that long time ago?!?! > > Nope, a simple `make oldconfig' breaks the symlink. KCONFIG_OVERWRITECONFIG was added especially for you. :-) bye, Roman - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.22-rc6-mm1
Hi, On Fri, 29 Jun 2007, Andrew Morton wrote: > > Reset generates values only if Kconfig and .config agree. > > unclear. Could you please explain further what this change does? Normally generated values (Kconfig entries without a prompt) are cleared as they are regenerated anyway and so they appear as new should they become visible and defaults work as expected (once a value is set defaults aren't used anymore). The detection whether a value is generated or not is only based on its visibility status, which can quickly change for a lot of symbols by just removing a single line from .config or adding a dependency to Kconfig as you noticed. The patch now suppresses this logic when .config and Kconfig aren't in sync and .config needs to be updated, so that you can remove now a random value from .config and oldconfig won't reask for many other values. bye, Roman - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.22-rc6-mm1
On Sat, 30 Jun 2007 23:10:17 +0200 Sam Ravnborg <[EMAIL PROTECTED]> wrote: > > I continue to believe that kbuild's lets-trash-your-symlink behaviour is > > obnoxious, but I was unable to persuade anyone else of this. > > I thought we fixed that long time ago?!?! Nope, a simple `make oldconfig' breaks the symlink. > I am heading for vacation for 20 days without Internet (real vacation :-)) Can I come? > and have properly forget most about Linux and everything about this > issue when I return. > In the unlikely event that I recall it I will take a look when I'm back. > > By the way - kbuild.git is lacking behind on patches. > I have several queded from other peopel and have more in the works myself. > This will not be looked into until I'm back. No probs - it's been like that for all time. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.22-rc6-mm1
On Fri, Jun 29, 2007 at 10:15:10PM -0700, Andrew Morton wrote: > On Sat, 30 Jun 2007 00:17:46 -0400 [EMAIL PROTECTED] wrote: > > > On Fri, 29 Jun 2007 14:01:30 PDT, Andrew Morton said: > > > On Fri, 29 Jun 2007 10:50:30 -0400 > > > [EMAIL PROTECTED] wrote: > > > > > > Odd - just for grins, I checked what 'make oldconfig' did when handed a > > > > .config > > > > from 22-rc4-mm2, and it behaved just fine, much to my surprise. > > > > > > That's probably because your old config file was relatively recent, and > > > had things like CONFIG_BLK_DEV=y in it. > > > > Ahh... Yeah, it gets a 'make oldconfig' for pretty > > much every single -mm, I suck at any regression testing other than "since > > the last -mm". > > > > All my .configs have mouldered since I lost the ability to have .config be > a symlink to a revision-controlled file (used to carry a custom patch for > this, but it died). > > I continue to believe that kbuild's lets-trash-your-symlink behaviour is > obnoxious, but I was unable to persuade anyone else of this. I thought we fixed that long time ago?!?! I am heading for vacation for 20 days without Internet (real vacation :-)) and have properly forget most about Linux and everything about this issue when I return. In the unlikely event that I recall it I will take a look when I'm back. By the way - kbuild.git is lacking behind on patches. I have several queded from other peopel and have more in the works myself. This will not be looked into until I'm back. Sam - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.22-rc6-mm1
Andrew Morton wrote: > On Fri, 29 Jun 2007 14:32:09 +0200 > Mariusz Kozlowski <[EMAIL PROTECTED]> wrote: >> anyway after unselecting XMON we can see: >> >> CC [M] fs/xfs/linux-2.6/xfs_ioctl32.o >> fs/xfs/linux-2.6/xfs_ioctl32.c: In function 'xfs_ioc_bulkstat_compat': >> fs/xfs/linux-2.6/xfs_ioctl32.c:334: error: 'xfs_inumbers_fmt_compat' >> undeclared (first use in this function) >> fs/xfs/linux-2.6/xfs_ioctl32.c:334: error: (Each undeclared identifier is >> reported only once >> fs/xfs/linux-2.6/xfs_ioctl32.c:334: error: for each function it appears in.) >> make[2]: *** [fs/xfs/linux-2.6/xfs_ioctl32.o] Blad 1 >> make[1]: *** [fs/xfs] Blad 2 > > Michal cc'ed. I think this is the one which was already reported but > I haven't seen a fix yet? Hi, I sent you an updated patch yesterday (should I've changed the subject / started a new thread? This was my first patch so bear with me... :)). Anyway, the mail with the fix is here: http://lkml.org/lkml/2007/6/29/87 Michal - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.22-rc6-mm1 Intel DMAR crash on AMD x86_64
Muli Ben-Yehuda <[EMAIL PROTECTED]> writes: > > The convention is to print a KERN_DEBUG message if hardware is not > found when probing it, otherwise the boot messages become cluttered > with lots of "$FOO not found". No the convention is to print no message at all when nothing is found Some drivers fail this, but they're bad examples. -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.22-rc6-mm1
Andrew Morton wrote: All my .configs have mouldered since I lost the ability to have .config be a symlink to a revision-controlled file (used to carry a custom patch for this, but it died). I continue to believe that kbuild's lets-trash-your-symlink behaviour is obnoxious, but I was unable to persuade anyone else of this. That's pretty awful, but it hasn't really affected me much since I started using separate object directories for pretty much everything. J - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.22-rc6-mm1
On Sat, 30 Jun 2007 00:17:46 -0400 [EMAIL PROTECTED] wrote: > On Fri, 29 Jun 2007 14:01:30 PDT, Andrew Morton said: > > On Fri, 29 Jun 2007 10:50:30 -0400 > > [EMAIL PROTECTED] wrote: > > > > Odd - just for grins, I checked what 'make oldconfig' did when handed a > > > .config > > > from 22-rc4-mm2, and it behaved just fine, much to my surprise. > > > > That's probably because your old config file was relatively recent, and > > had things like CONFIG_BLK_DEV=y in it. > > Ahh... Yeah, it gets a 'make oldconfig' for pretty > much every single -mm, I suck at any regression testing other than "since > the last -mm". > All my .configs have mouldered since I lost the ability to have .config be a symlink to a revision-controlled file (used to carry a custom patch for this, but it died). I continue to believe that kbuild's lets-trash-your-symlink behaviour is obnoxious, but I was unable to persuade anyone else of this. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.22-rc6-mm1
On Fri, 29 Jun 2007 14:01:30 PDT, Andrew Morton said: > On Fri, 29 Jun 2007 10:50:30 -0400 > [EMAIL PROTECTED] wrote: > > Odd - just for grins, I checked what 'make oldconfig' did when handed a > > .config > > from 22-rc4-mm2, and it behaved just fine, much to my surprise. > > That's probably because your old config file was relatively recent, and > had things like CONFIG_BLK_DEV=y in it. Ahh... Yeah, it gets a 'make oldconfig' for pretty much every single -mm, I suck at any regression testing other than "since the last -mm". pgpwUuUiftAZq.pgp Description: PGP signature
Re: 2.6.22-rc6-mm1 Intel DMAR crash on AMD x86_64
On Friday, 29 June 2007 17:28, Keshavamurthy, Anil S wrote:
> On Thu, Jun 28, 2007 at 06:14:27PM -0700, Li, Shaohua wrote:
> >
> >
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.22-
> > >rc6/2.6.22-rc6-mm1/
> > >>
> > >>> +intel-iommu-dmar-detection-and-parsing-logic.patch
> [..]
> > >
> > >I took a picture of it, looks like the backtrace is:
> > >
> > >NULL pointer dereference at 024
> > >EIP:dmar_table_init+0x11
> > >intel_iommu_init+0x30
> > >pci_iommu_init+0xe
> > >kernel_init+0x16e
> > >
> > >Presumably something is NULL in dmar_table_init that wasn't expected to
> > >be.. I would guess it likely crashes on any system without an Intel
> > >IOMMU in it.
> Yup, that is correct.
>
> > How about something like below?
> >
> >
> > int __init dmar_table_init(void)
> > {
> > + if (!dmar_tbl)
> > + return -ENODEV;
> > parse_dmar_table();
> why not check for NULL in the function where it touched?
> Also when there are no DMAR devices we need the below
> printk on the console.
>
> > if (list_empty(&dmar_drhd_units)) {
> > printk(KERN_ERR PREFIX "No DMAR devices found\n");
> > return -ENODEV;
> > }
> > return 0;
> > }
>
> Here is the revised patch of the above.
> Andrew, please add this fix to
> +intel-iommu-dmar-detection-and-parsing-logic.patch
>
>
> Check for dmar_tbl pointer as this can be NULL on
> systems with no Intel VT-d support.
>
> Signed-off-by: Anil S Keshavamurthy <[EMAIL PROTECTED]>
For the record, this patch fixes the boot crash on my AMD64-based test box.
Thanks,
Rafael
--
"Premature optimization is the root of all evil." - Donald Knuth
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.22-rc6-mm1 Intel DMAR crash on AMD x86_64
On Fri, Jun 29, 2007 at 12:23:53PM -0700, Keshavamurthy, Anil S wrote: > Since this is IOMMU is built into the kernel and it is good idea to > report that the device is not present. Yes - as a debug message. > The above is printed only once and is consistent with other IOMMU > implementation. Atleast it is useful when people report bugs we can > makeout whether IOMMU is being detected or not. If it was printed that it was detected it was - otherwise, it wasn't. > Here is what I see on my box. > [..] > "PCI-GART: No AMD northbridge found." You're right, that should be a debug message as well. > [..] > Calgary: detecting Calgary via BIOS EBDA area > Calgary: Unable to locate Rio Grande table in EBDA - bailing! These are KERN_DEBUG messages. Cheers, Muli - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.22-rc6-mm1
On Fri, 29 Jun 2007 10:50:30 -0400 [EMAIL PROTECTED] wrote: > On Thu, 28 Jun 2007 03:43:21 PDT, Andrew Morton said: > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.22-rc6/2.6.22-rc6-mm1/ > > Configures, builds, boots on first try. Dell Latitude D820 laptop, T7200 CPU, > x86_64 kernel. Doesn't break any of the out-of-tree stuff I use. > > > `make oldconfig', your kernel probably won't work. I lost useful things > > like CONFIG_BLK_DEV and the whole SCSI system, because they were added > > after > > I generated my .config. > > Odd - just for grins, I checked what 'make oldconfig' did when handed a > .config > from 22-rc4-mm2, and it behaved just fine, much to my surprise. That's probably because your old config file was relatively recent, and had things like CONFIG_BLK_DEV=y in it. But those people who are still dragging around old config files which predate the introduction of CONFIG_BLK_DEV will find that 2.6.22-rc6-mm1 oldconfig will give them CONFIG_BLK_DEV=n instead of current mainline's deafult of CONFIG_BLK_DEV=y. I think making BLK_DEV deafult to n was a bit dumb, so I dropped the offending patches. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.22-rc6-mm1
On Fri, 29 Jun 2007 16:17:38 +0200 (CEST) Roman Zippel <[EMAIL PROTECTED]> wrote: > On Thu, 28 Jun 2007, Andrew Morton wrote: > > > So save yourself some hassle and check your .config carefully before > > building this kernel. Make sure that everything you need is still > > enabled. > > > > I found that manually adding "CONFIG_BLK_DEV=y" to the .config before > > running oldconfig saved a large number of config items from getting lost. > > This patch should help for this, so that this isn't done when Kconfig or > .config has been changed and they are not in sync. > > bye, Roman > > > Reset generates values only if Kconfig and .config agree. unclear. Could you please explain further what this change does? Thanks. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.22-rc6-mm1
On Fri, 29 Jun 2007 14:32:09 +0200 Mariusz Kozlowski <[EMAIL PROTECTED]> wrote: > Hello, > > allmodconfig on powerpc (iMac g3) fails due to > git-kgdb.patch. allmodconfig defaults should be changed? > > CC arch/powerpc/kernel/kgdb.o > arch/powerpc/kernel/kgdb.c:485:2: error: #error Both XMON and KGDB selected > in .config. Unselect one of them. > make[1]: *** [arch/powerpc/kernel/kgdb.o] Blad 1 > make: *** [arch/powerpc/kernel] Blad 2 Jason cc'ed > anyway after unselecting XMON we can see: > > CC [M] fs/xfs/linux-2.6/xfs_ioctl32.o > fs/xfs/linux-2.6/xfs_ioctl32.c: In function 'xfs_ioc_bulkstat_compat': > fs/xfs/linux-2.6/xfs_ioctl32.c:334: error: 'xfs_inumbers_fmt_compat' > undeclared (first use in this function) > fs/xfs/linux-2.6/xfs_ioctl32.c:334: error: (Each undeclared identifier is > reported only once > fs/xfs/linux-2.6/xfs_ioctl32.c:334: error: for each function it appears in.) > make[2]: *** [fs/xfs/linux-2.6/xfs_ioctl32.o] Blad 1 > make[1]: *** [fs/xfs] Blad 2 > > This is just allmodconfig - not a .config that's used daily by users but I'm > used to compiling the kernel using it anyway 8) > Michal cc'ed. I think this is the one which was already reported but I haven't seen a fix yet? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.22-rc6-mm1 Intel DMAR crash on AMD x86_64
On Fri, Jun 29, 2007 at 12:23:43PM -0400, Muli Ben-Yehuda wrote:
> On Fri, Jun 29, 2007 at 08:28:58AM -0700, Keshavamurthy, Anil S wrote:
>
> > +++ linux-2.6.22-rc4-mm2/drivers/pci/dmar.c 2007-06-29 07:46:25.0
> > -0700
> > @@ -260,6 +260,8 @@
> > int ret = 0;
> >
> > dmar = (struct acpi_table_dmar *)dmar_tbl;
> > + if (!dmar)
> > + return -ENODEV;
> >
> > if (!dmar->width) {
> > printk (KERN_WARNING PREFIX "Zero: Invalid DMAR haw\n");
> > @@ -301,7 +303,7 @@
> >
> > parse_dmar_table();
> > if (list_empty(&dmar_drhd_units)) {
> > - printk(KERN_ERR PREFIX "No DMAR devices found\n");
> > + printk(KERN_INFO PREFIX "No DMAR devices found\n");
> > return -ENODEV;
> > }
> > return 0;
>
> The convention is to print a KERN_DEBUG message if hardware is not
> found when probing it, otherwise the boot messages become cluttered
> with lots of "$FOO not found".
Since this is IOMMU is built into the kernel and it is
good idea to report that the device is not present. The
above is printed only once and is consistent with other
IOMMU implementation. Atleast it is useful when people
report bugs we can makeout whether IOMMU is being detected
or not.
Here is what I see on my box.
[..]
"PCI-GART: No AMD northbridge found."
[..]
Calgary: detecting Calgary via BIOS EBDA area
Calgary: Unable to locate Rio Grande table in EBDA - bailing!
[..]
As you can see I don;t have either GART or Calgary on my box.
-Thanks,
Anil
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.22-rc6-mm1 Intel DMAR crash on AMD x86_64
On Fri, Jun 29, 2007 at 08:28:58AM -0700, Keshavamurthy, Anil S wrote:
> Here is the revised patch of the above.
> Andrew, please add this fix to
> +intel-iommu-dmar-detection-and-parsing-logic.patch
>
>
> Check for dmar_tbl pointer as this can be NULL on
> systems with no Intel VT-d support.
>
> Signed-off-by: Anil S Keshavamurthy <[EMAIL PROTECTED]>
>
> ---
> drivers/pci/dmar.c |4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> Index: linux-2.6.22-rc4-mm2/drivers/pci/dmar.c
> ===
> --- linux-2.6.22-rc4-mm2.orig/drivers/pci/dmar.c 2007-06-29
> 07:43:43.0 -0700
> +++ linux-2.6.22-rc4-mm2/drivers/pci/dmar.c 2007-06-29 07:46:25.0
> -0700
> @@ -260,6 +260,8 @@
> int ret = 0;
>
> dmar = (struct acpi_table_dmar *)dmar_tbl;
> + if (!dmar)
> + return -ENODEV;
>
> if (!dmar->width) {
> printk (KERN_WARNING PREFIX "Zero: Invalid DMAR haw\n");
> @@ -301,7 +303,7 @@
>
> parse_dmar_table();
> if (list_empty(&dmar_drhd_units)) {
> - printk(KERN_ERR PREFIX "No DMAR devices found\n");
> + printk(KERN_INFO PREFIX "No DMAR devices found\n");
> return -ENODEV;
> }
> return 0;
The convention is to print a KERN_DEBUG message if hardware is not
found when probing it, otherwise the boot messages become cluttered
with lots of "$FOO not found".
Cheers,
Muli
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.22-rc6-mm1 Intel DMAR crash on AMD x86_64
On Thu, Jun 28, 2007 at 06:14:27PM -0700, Li, Shaohua wrote:
>
>
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.22-
> >rc6/2.6.22-rc6-mm1/
> >>
> >>> +intel-iommu-dmar-detection-and-parsing-logic.patch
[..]
> >
> >I took a picture of it, looks like the backtrace is:
> >
> >NULL pointer dereference at 024
> >EIP:dmar_table_init+0x11
> >intel_iommu_init+0x30
> >pci_iommu_init+0xe
> >kernel_init+0x16e
> >
> >Presumably something is NULL in dmar_table_init that wasn't expected to
> >be.. I would guess it likely crashes on any system without an Intel
> >IOMMU in it.
Yup, that is correct.
> How about something like below?
>
>
> int __init dmar_table_init(void)
> {
> + if (!dmar_tbl)
> + return -ENODEV;
> parse_dmar_table();
why not check for NULL in the function where it touched?
Also when there are no DMAR devices we need the below
printk on the console.
> if (list_empty(&dmar_drhd_units)) {
> printk(KERN_ERR PREFIX "No DMAR devices found\n");
> return -ENODEV;
> }
> return 0;
> }
Here is the revised patch of the above.
Andrew, please add this fix to
+intel-iommu-dmar-detection-and-parsing-logic.patch
Check for dmar_tbl pointer as this can be NULL on
systems with no Intel VT-d support.
Signed-off-by: Anil S Keshavamurthy <[EMAIL PROTECTED]>
---
drivers/pci/dmar.c |4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
Index: linux-2.6.22-rc4-mm2/drivers/pci/dmar.c
===
--- linux-2.6.22-rc4-mm2.orig/drivers/pci/dmar.c2007-06-29
07:43:43.0 -0700
+++ linux-2.6.22-rc4-mm2/drivers/pci/dmar.c 2007-06-29 07:46:25.0
-0700
@@ -260,6 +260,8 @@
int ret = 0;
dmar = (struct acpi_table_dmar *)dmar_tbl;
+ if (!dmar)
+ return -ENODEV;
if (!dmar->width) {
printk (KERN_WARNING PREFIX "Zero: Invalid DMAR haw\n");
@@ -301,7 +303,7 @@
parse_dmar_table();
if (list_empty(&dmar_drhd_units)) {
- printk(KERN_ERR PREFIX "No DMAR devices found\n");
+ printk(KERN_INFO PREFIX "No DMAR devices found\n");
return -ENODEV;
}
return 0;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.22-rc6-mm1
On Thu, 28 Jun 2007 03:43:21 PDT, Andrew Morton said: > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.22-rc6/2.6.22-rc6-mm1/ Configures, builds, boots on first try. Dell Latitude D820 laptop, T7200 CPU, x86_64 kernel. Doesn't break any of the out-of-tree stuff I use. > `make oldconfig', your kernel probably won't work. I lost useful things > like CONFIG_BLK_DEV and the whole SCSI system, because they were added after > I generated my .config. Odd - just for grins, I checked what 'make oldconfig' did when handed a .config from 22-rc4-mm2, and it behaved just fine, much to my surprise. I can't comment on the DMAR issues, my .config didn't include PCI_MSI so I never got asked about that one by oldconfig. Maybe if I get brave this afternoon. :) pgpxXsQfEBhWH.pgp Description: PGP signature
Re: 2.6.22-rc6-mm1
Hi,
On Thu, 28 Jun 2007, Andrew Morton wrote:
> So save yourself some hassle and check your .config carefully before
> building this kernel. Make sure that everything you need is still enabled.
>
> I found that manually adding "CONFIG_BLK_DEV=y" to the .config before
> running oldconfig saved a large number of config items from getting lost.
This patch should help for this, so that this isn't done when Kconfig or
.config has been changed and they are not in sync.
bye, Roman
Reset generates values only if Kconfig and .config agree.
Signed-off-by: Roman Zippel <[EMAIL PROTECTED]>
---
scripts/kconfig/confdata.c | 37 ++---
1 file changed, 26 insertions(+), 11 deletions(-)
Index: linux-2.6/scripts/kconfig/confdata.c
===
--- linux-2.6.orig/scripts/kconfig/confdata.c
+++ linux-2.6/scripts/kconfig/confdata.c
@@ -341,27 +341,42 @@ int conf_read(const char *name)
conf_unsaved++;
/* maybe print value in verbose mode... */
sym_ok:
+ if (!sym_is_choice(sym))
+ continue;
+ /* The choice symbol only has a set value (and thus is not new)
+* if all its visible childs have values.
+*/
+ prop = sym_get_choice_prop(sym);
+ flags = sym->flags;
+ for (e = prop->expr; e; e = e->left.expr)
+ if (e->right.sym->visible != no)
+ flags &= e->right.sym->flags;
+ sym->flags &= flags | ~SYMBOL_DEF_USER;
+ }
+
+ for_all_symbols(i, sym) {
if (sym_has_value(sym) && !sym_is_choice_value(sym)) {
- if (sym->visible == no)
+ /* Reset values of generates values, so they'll appear
+* as new, if they should become visible, but that
+* doesn't quite work if the Kconfig and the saved
+* configuration disagree.
+*/
+ if (sym->visible == no && !conf_unsaved)
sym->flags &= ~SYMBOL_DEF_USER;
switch (sym->type) {
case S_STRING:
case S_INT:
case S_HEX:
- if (!sym_string_within_range(sym,
sym->def[S_DEF_USER].val))
- sym->flags &=
~(SYMBOL_VALID|SYMBOL_DEF_USER);
+ /* Reset a string value if it's out of range */
+ if (sym_string_within_range(sym,
sym->def[S_DEF_USER].val))
+ break;
+ sym->flags &= ~(SYMBOL_VALID|SYMBOL_DEF_USER);
+ conf_unsaved++;
+ break;
default:
break;
}
}
- if (!sym_is_choice(sym))
- continue;
- prop = sym_get_choice_prop(sym);
- flags = sym->flags;
- for (e = prop->expr; e; e = e->left.expr)
- if (e->right.sym->visible != no)
- flags &= e->right.sym->flags;
- sym->flags &= flags | ~SYMBOL_DEF_USER;
}
sym_add_change_count(conf_warnings || conf_unsaved);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.22-rc6-mm1
Hello. Mariusz Kozlowski wrote: allmodconfig on powerpc (iMac g3) fails due to git-kgdb.patch. allmodconfig defaults should be changed? CC arch/powerpc/kernel/kgdb.o arch/powerpc/kernel/kgdb.c:485:2: error: #error Both XMON and KGDB selected in .config. Unselect one of them. make[1]: *** [arch/powerpc/kernel/kgdb.o] Blad 1 make: *** [arch/powerpc/kernel] Blad 2 I'm not sure if this will work out but maybe it's worth to disable XMON if KGDB is selected, like this? config XMON bool "Include xmon kernel debugger" depends on DEBUGGER && !KGDB Regards, Mariusz WBR, Sergei - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.22-rc6-mm1
Hello, allmodconfig on powerpc (iMac g3) fails due to git-kgdb.patch. allmodconfig defaults should be changed? CC arch/powerpc/kernel/kgdb.o arch/powerpc/kernel/kgdb.c:485:2: error: #error Both XMON and KGDB selected in .config. Unselect one of them. make[1]: *** [arch/powerpc/kernel/kgdb.o] Blad 1 make: *** [arch/powerpc/kernel] Blad 2 anyway after unselecting XMON we can see: CC [M] fs/xfs/linux-2.6/xfs_ioctl32.o fs/xfs/linux-2.6/xfs_ioctl32.c: In function 'xfs_ioc_bulkstat_compat': fs/xfs/linux-2.6/xfs_ioctl32.c:334: error: 'xfs_inumbers_fmt_compat' undeclared (first use in this function) fs/xfs/linux-2.6/xfs_ioctl32.c:334: error: (Each undeclared identifier is reported only once fs/xfs/linux-2.6/xfs_ioctl32.c:334: error: for each function it appears in.) make[2]: *** [fs/xfs/linux-2.6/xfs_ioctl32.o] Blad 1 make[1]: *** [fs/xfs] Blad 2 This is just allmodconfig - not a .config that's used daily by users but I'm used to compiling the kernel using it anyway 8) Regards, Mariusz - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: 2.6.22-rc6-mm1 Intel DMAR crash on AMD x86_64
>-Original Message-
>From: Robert Hancock [mailto:[EMAIL PROTECTED]
>Sent: Friday, June 29, 2007 8:59 AM
>To: Zan Lynx
>Cc: Andrew Morton; linux-kernel@vger.kernel.org; Raj, Ashok; Li,
Shaohua;
>Keshavamurthy, Anil S
>Subject: Re: 2.6.22-rc6-mm1 Intel DMAR crash on AMD x86_64
>
>Zan Lynx wrote:
>> On Thu, 2007-06-28 at 03:43 -0700, Andrew Morton wrote:
>>>
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.22-
>rc6/2.6.22-rc6-mm1/
>>
>>> +intel-iommu-dmar-detection-and-parsing-logic.patch
>>> +intel-iommu-pci-generic-helper-function.patch
>>> +intel-iommu-pci-generic-helper-function-fix.patch
>>> +intel-iommu-clflush_cache_range-now-takes-size-param.patch
>>> +intel-iommu-iova-allocation-and-management-routines.patch
>>> +intel-iommu-iova-allocation-and-management-routines-fix.patch
>>> +intel-iommu-iova-allocation-and-management-routines-fix-2.patch
>>> +intel-iommu-intel-iommu-driver.patch
>>> +intel-iommu-intel-iommu-driver-fix.patch
>>> +intel-iommu-intel-iommu-driver-fix-2.patch
>>>
+intel-iommu-avoid-memory-allocation-failures-in-dma-map-api-calls.patch
>>> +intel-iommu-intel-iommu-cmdline-option-forcedac.patch
>>> +intel-iommu-dmar-fault-handling-support.patch
>>> +intel-iommu-iommu-gfx-workaround.patch
>>> +intel-iommu-iommu-floppy-workaround.patch
>>> +intel-iommu-iommu-floppy-workaround-fix.patch
>>> +intel-iommu-iommu-floppy-workaround-fix-fix.patch
>>>
>>> Intel IOMMU support
>>
>> I believe the above patch set is causing the problem. On my first
try
>> with rc6-mm1 I said Yes to the CONFIG_DMAR options. (I'm nearly as
good
>> as random option selection :-)
>>
>> The system panicked during boot, I believe it was trying to detect an
>> Intel IOMMU. Later when I have a camera, I will try to post a
>> screenshot of the backtrace. (I can't seem to get netconsole to work
on
>> boot, only in a module).
>>
>> When I recompiled without DMAR set, things seem to be working great.
I
>> seem to be getting better disk read throughput than rc3-mm1, by the
way.
>>
>> This laptop is an AMD Athlon64 on a NForce3 running a 64-bit Gentoo
>> build.
>>
>> I'll provide more details on request, and when I get the chance.
This
>> is a heads-up on the BUG in case someone has an "ah ha!" moment.
>
>I took a picture of it, looks like the backtrace is:
>
>NULL pointer dereference at 024
>EIP:dmar_table_init+0x11
>intel_iommu_init+0x30
>pci_iommu_init+0xe
>kernel_init+0x16e
>
>Presumably something is NULL in dmar_table_init that wasn't expected to
>be.. I would guess it likely crashes on any system without an Intel
>IOMMU in it.
How about something like below?
int __init dmar_table_init(void)
{
+ if (!dmar_tbl)
+ return -ENODEV;
parse_dmar_table();
if (list_empty(&dmar_drhd_units)) {
printk(KERN_ERR PREFIX "No DMAR devices found\n");
return -ENODEV;
}
return 0;
}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.22-rc6-mm1 Intel DMAR crash on AMD x86_64
Zan Lynx wrote: On Thu, 2007-06-28 at 03:43 -0700, Andrew Morton wrote: ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.22-rc6/2.6.22-rc6-mm1/ +intel-iommu-dmar-detection-and-parsing-logic.patch +intel-iommu-pci-generic-helper-function.patch +intel-iommu-pci-generic-helper-function-fix.patch +intel-iommu-clflush_cache_range-now-takes-size-param.patch +intel-iommu-iova-allocation-and-management-routines.patch +intel-iommu-iova-allocation-and-management-routines-fix.patch +intel-iommu-iova-allocation-and-management-routines-fix-2.patch +intel-iommu-intel-iommu-driver.patch +intel-iommu-intel-iommu-driver-fix.patch +intel-iommu-intel-iommu-driver-fix-2.patch +intel-iommu-avoid-memory-allocation-failures-in-dma-map-api-calls.patch +intel-iommu-intel-iommu-cmdline-option-forcedac.patch +intel-iommu-dmar-fault-handling-support.patch +intel-iommu-iommu-gfx-workaround.patch +intel-iommu-iommu-floppy-workaround.patch +intel-iommu-iommu-floppy-workaround-fix.patch +intel-iommu-iommu-floppy-workaround-fix-fix.patch Intel IOMMU support I believe the above patch set is causing the problem. On my first try with rc6-mm1 I said Yes to the CONFIG_DMAR options. (I'm nearly as good as random option selection :-) The system panicked during boot, I believe it was trying to detect an Intel IOMMU. Later when I have a camera, I will try to post a screenshot of the backtrace. (I can't seem to get netconsole to work on boot, only in a module). When I recompiled without DMAR set, things seem to be working great. I seem to be getting better disk read throughput than rc3-mm1, by the way. This laptop is an AMD Athlon64 on a NForce3 running a 64-bit Gentoo build. I'll provide more details on request, and when I get the chance. This is a heads-up on the BUG in case someone has an "ah ha!" moment. I took a picture of it, looks like the backtrace is: NULL pointer dereference at 024 EIP:dmar_table_init+0x11 intel_iommu_init+0x30 pci_iommu_init+0xe kernel_init+0x16e Presumably something is NULL in dmar_table_init that wasn't expected to be.. I would guess it likely crashes on any system without an Intel IOMMU in it. -- Robert Hancock Saskatoon, SK, Canada To email, remove "nospam" from [EMAIL PROTECTED] Home Page: http://www.roberthancock.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.22-rc6-mm1 Intel DMAR crash on AMD x86_64
On Thursday 28 June 2007 01:40:32 pm you wrote: > I'll provide more details on request, and when I get the chance. This > is a heads-up on the BUG in case someone has an "ah ha!" moment. I believe I have also reproduced this bug. I have an ABIT K9 Ultra motherboard with NFORCE hardware. My serial console cannot seem to capture it, but removing the DMAR options definately takes away the problem and allows me to boot. If anyone would like me to gather other info or test out patches, please let me know. Linux hoth 2.6.22-rc6-mm1 #8 SMP Thu Jun 28 16:18:17 PDT 2007 x86_64 x86_64 x86_64 GNU/Linux Gnu C 4.1.2 Gnu make 3.81 binutils 2.17.50.0.12-4 util-linux 2.13-pre7 mount 2.13-pre7 module-init-tools 3.3-pre11 e2fsprogs 1.39 pcmciautils014 quota-tools3.14. PPP2.4.4 isdn4k-utils 3.9 Linux C Library> libc.2.6 Dynamic linker (ldd) 2.6 Procps 3.2.7 Net-tools 1.60 Kbd1.12 oprofile 0.9.2 Sh-utils 6.9 udev 106 wireless-tools 28 Modules Loaded tun ppdev ipt_MASQUERADE iptable_nat nf_nat nf_conntrack_ipv4 xt_state nf_conntrack nfnetlink ipt_REJECT xt_tcpudp iptable_filter ip_tables x_tables bridge llc hidp l2cap bluetooth ipv6 dm_mirror dm_multipath dm_mod raid10 raid0 video output sbs button dock battery ac lp loop kvm_amd kvm parport_serial snd_hda_intel snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss snd_mixer_oss snd_pcm snd_timer snd parport_pc parport soundcore snd_page_alloc usblp k8temp serio_raw hwmon forcedeth shpchp i2c_nforce2 i2c_core sr_mod cdrom floppy sg pata_amd sata_nv libata sd_mod scsi_mod raid456 async_xor async_memcpy async_tx xor raid1 ext3 jbd mbcache ehci_hcd ohci_hcd uhci_hcd [EMAIL PROTECTED] ~]# cat /proc/cpuinfo processor : 0 vendor_id : AuthenticAMD cpu family : 15 model : 75 model name : AMD Athlon(tm) 64 X2 Dual Core Processor 3800+ stepping: 2 cpu MHz : 1000.000 cache size : 512 KB physical id : 0 siblings: 2 core id : 0 cpu cores : 2 fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt rdtscp lm 3dnowext 3dnow rep_good pni cx16 lahf_lm cmp_legacy svm extapic cr8_legacy bogomips: 2000.92 TLB size: 1024 4K pages clflush size: 64 cache_alignment : 64 address sizes : 40 bits physical, 48 bits virtual power management: ts fid vid ttp tm stc processor : 1 vendor_id : AuthenticAMD cpu family : 15 model : 75 model name : AMD Athlon(tm) 64 X2 Dual Core Processor 3800+ stepping: 2 cpu MHz : 1000.000 cache size : 512 KB physical id : 0 siblings: 2 core id : 1 cpu cores : 2 fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt rdtscp lm 3dnowext 3dnow rep_good pni cx16 lahf_lm cmp_legacy svm extapic cr8_legacy bogomips: 2000.92 TLB size: 1024 4K pages clflush size: 64 cache_alignment : 64 address sizes : 40 bits physical, 48 bits virtual power management: ts fid vid ttp tm stc 00:00.0 RAM memory: nVidia Corporation MCP55 Memory Controller (rev a1) Subsystem: ABIT Computer Corp. Unknown device 1c24 Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- Reset- FastB2B- Capabilities: [b8] Subsystem: nVidia Corporation Unknown device cb84 Capabilities: [8c] HyperTransport: MSI Mapping 00:06.1 Audio device: nVidia Corporation MCP55 High Definition Audio (rev a2) Subsystem: ABIT Computer Corp. Unknown device 1c20 Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- Reset- FastB2B- Capabilities: [40] Subsystem: nVidia Corporation Unknown device Capabilities: [48] Power Management version 2 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold+) Status: D0 PME-Enable- DSel=0 DScale=0 PME- Capabilities: [50] Message Signalled Interrupts: Mask- 64bit+ Queue=0/1 Enable+
Re: 2.6.22-rc6-mm1: io_apic build error
> > On Thu, 28 Jun 2007 13:09:21 -0700 > Randy Dunlap <[EMAIL PROTECTED]> wrote: > > > On Thu, 28 Jun 2007 03:43:21 -0700 Andrew Morton wrote: > > > > > > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.22-rc6/2.6.22-rc6-mm1/ > > > > > > on x86_64, with CONFIG_PCI disabled, CONFIG_PM disabled, > > hence CONFIG_ACPI disabled: > > > > > > arch/x86_64/kernel/built-in.o: In function `setup_IO_APIC': > > (.init.text+0x4ef7): undefined reference to `mp_apic_pin_to_gsi' > > make: *** [.tmp_vmlinux1] Error 1 > > > > hm, it's not immediately obvious how to fix that so I'll ask John to do > repairs, please. > OK, I'll take a look. John - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.22-rc6-mm1: Xen: WARNING: Absolute relocations present
Adrian Bunk wrote: <-- snip --> ... RELOCS arch/i386/boot/compressed/vmlinux.relocs WARNING: Absolute relocations present Offset Info Type Sym.Value Sym.Name c0101f80 020c6501 R_386_32 xen_irq_disable_direct_reloc c0101f9a 0221ea01 R_386_32 xen_save_fl_direct_reloc ... <-- snip --> Hm. Those are false alarms. I guess I could do something to hide them, but there's nothing inherently wrong with correctly used abs symbols. Is there someway to whitelist them? J - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.22-rc6-mm1 Intel DMAR crash on AMD x86_64
On Thu, 2007-06-28 at 03:43 -0700, Andrew Morton wrote: > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.22-rc6/2.6.22-rc6-mm1/ > +intel-iommu-dmar-detection-and-parsing-logic.patch > +intel-iommu-pci-generic-helper-function.patch > +intel-iommu-pci-generic-helper-function-fix.patch > +intel-iommu-clflush_cache_range-now-takes-size-param.patch > +intel-iommu-iova-allocation-and-management-routines.patch > +intel-iommu-iova-allocation-and-management-routines-fix.patch > +intel-iommu-iova-allocation-and-management-routines-fix-2.patch > +intel-iommu-intel-iommu-driver.patch > +intel-iommu-intel-iommu-driver-fix.patch > +intel-iommu-intel-iommu-driver-fix-2.patch > +intel-iommu-avoid-memory-allocation-failures-in-dma-map-api-calls.patch > +intel-iommu-intel-iommu-cmdline-option-forcedac.patch > +intel-iommu-dmar-fault-handling-support.patch > +intel-iommu-iommu-gfx-workaround.patch > +intel-iommu-iommu-floppy-workaround.patch > +intel-iommu-iommu-floppy-workaround-fix.patch > +intel-iommu-iommu-floppy-workaround-fix-fix.patch > > Intel IOMMU support I believe the above patch set is causing the problem. On my first try with rc6-mm1 I said Yes to the CONFIG_DMAR options. (I'm nearly as good as random option selection :-) The system panicked during boot, I believe it was trying to detect an Intel IOMMU. Later when I have a camera, I will try to post a screenshot of the backtrace. (I can't seem to get netconsole to work on boot, only in a module). When I recompiled without DMAR set, things seem to be working great. I seem to be getting better disk read throughput than rc3-mm1, by the way. This laptop is an AMD Athlon64 on a NForce3 running a 64-bit Gentoo build. I'll provide more details on request, and when I get the chance. This is a heads-up on the BUG in case someone has an "ah ha!" moment. -- Zan Lynx <[EMAIL PROTECTED]> signature.asc Description: This is a digitally signed message part
Re: 2.6.22-rc6-mm1: io_apic build error
On Thu, 28 Jun 2007 13:09:21 -0700 Randy Dunlap <[EMAIL PROTECTED]> wrote: > On Thu, 28 Jun 2007 03:43:21 -0700 Andrew Morton wrote: > > > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.22-rc6/2.6.22-rc6-mm1/ > > > on x86_64, with CONFIG_PCI disabled, CONFIG_PM disabled, > hence CONFIG_ACPI disabled: > > > arch/x86_64/kernel/built-in.o: In function `setup_IO_APIC': > (.init.text+0x4ef7): undefined reference to `mp_apic_pin_to_gsi' > make: *** [.tmp_vmlinux1] Error 1 > hm, it's not immediately obvious how to fix that so I'll ask John to do repairs, please. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.22-rc6-mm1: io_apic build error
On Thu, 28 Jun 2007 03:43:21 -0700 Andrew Morton wrote: > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.22-rc6/2.6.22-rc6-mm1/ on x86_64, with CONFIG_PCI disabled, CONFIG_PM disabled, hence CONFIG_ACPI disabled: arch/x86_64/kernel/built-in.o: In function `setup_IO_APIC': (.init.text+0x4ef7): undefined reference to `mp_apic_pin_to_gsi' make: *** [.tmp_vmlinux1] Error 1 --- ~Randy *** Remember to use Documentation/SubmitChecklist when testing your code *** config-apic-gsi-err Description: Binary data
Re: 2.6.22-rc6-mm1: multiple definition of `check_reset'
On Thu, 28 Jun 2007 21:29:50 +0200
Adrian Bunk <[EMAIL PROTECTED]> wrote:
> LD drivers/built-in.o
> drivers/isdn/built-in.o: In function `check_reset': (.text+0xab974):
> multiple definition of `check_reset'
> drivers/scsi/built-in.o:(.data+0xdba8): first defined here
> ld: Warning: size of symbol `check_reset' changed from 4 in
> drivers/scsi/built-in.o to 214 in drivers/isdn/built-in.o
> ld: Warning: type of symbol `check_reset' changed from 1 to 2 in
> drivers/isdn/built-in.o
check_reset wasn't a great choice of identifier...
diff -puN drivers/scsi/aacraid/aachba.c~aacraid-rename-check_reset
drivers/scsi/aacraid/aachba.c
--- a/drivers/scsi/aacraid/aachba.c~aacraid-rename-check_reset
+++ a/drivers/scsi/aacraid/aachba.c
@@ -177,9 +177,9 @@ int check_interval = 24 * 60 * 60;
module_param(check_interval, int, S_IRUGO|S_IWUSR);
MODULE_PARM_DESC(check_interval, "Interval in seconds between adapter health
checks.");
-int check_reset = 1;
-module_param(check_reset, int, S_IRUGO|S_IWUSR);
-MODULE_PARM_DESC(check_reset, "If adapter fails health check, reset the
adapter.");
+int aacraid_check_reset = 1;
+module_param_named(check_reset, aacraid_check_reset, int, S_IRUGO|S_IWUSR);
+MODULE_PARM_DESC(aacraid_check_reset, "If adapter fails health check, reset
the adapter.");
int expose_physicals = -1;
module_param(expose_physicals, int, S_IRUGO|S_IWUSR);
@@ -1211,7 +1211,7 @@ int aac_get_adapter_info(struct aac_dev*
(int)sizeof(dev->supplement_adapter_info.VpdInfo.Tsid),
dev->supplement_adapter_info.VpdInfo.Tsid);
}
- if (!check_reset ||
+ if (!aacraid_check_reset ||
(dev->supplement_adapter_info.SupportedOptions2 &
le32_to_cpu(AAC_OPTION_IGNORE_RESET))) {
printk(KERN_INFO "%s%d: Reset Adapter Ignored\n",
diff -puN drivers/scsi/aacraid/aacraid.h~aacraid-rename-check_reset
drivers/scsi/aacraid/aacraid.h
--- a/drivers/scsi/aacraid/aacraid.h~aacraid-rename-check_reset
+++ a/drivers/scsi/aacraid/aacraid.h
@@ -1857,4 +1857,4 @@ extern int aac_reset_devices;
extern int aac_commit;
extern int update_interval;
extern int check_interval;
-extern int check_reset;
+extern int aacraid_check_reset;
diff -puN drivers/scsi/aacraid/commsup.c~aacraid-rename-check_reset
drivers/scsi/aacraid/commsup.c
--- a/drivers/scsi/aacraid/commsup.c~aacraid-rename-check_reset
+++ a/drivers/scsi/aacraid/commsup.c
@@ -1370,8 +1370,9 @@ int aac_check_health(struct aac_dev * aa
printk(KERN_ERR "%s: Host adapter BLINK LED 0x%x\n", aac->name,
BlinkLED);
- if (!check_reset || (aac->supplement_adapter_info.SupportedOptions2 &
- le32_to_cpu(AAC_OPTION_IGNORE_RESET)))
+ if (!aacraid_check_reset ||
+ (aac->supplement_adapter_info.SupportedOptions2 &
+ le32_to_cpu(AAC_OPTION_IGNORE_RESET)))
goto out;
host = aac->scsi_host_ptr;
if (aac->thread->pid != current->pid)
_
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.22-rc6-mm1
On Thu, 28 Jun 2007 14:08:49 +0200 Gabriel C <[EMAIL PROTECTED]> wrote: > Andrew Morton wrote: > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.22-rc6/2.6.22-rc6-mm1/ > > > > > > Compile error here. > > ... > > Kernel: arch/i386/boot/bzImage is ready (#1) > ERROR: "check_signature" [drivers/input/misc/wistron_btns.ko] undefined! > ERROR: "check_signature" [drivers/block/xd.ko] undefined! > make[1]: *** [__modpost] Error 1 > make: *** [modules] Error 2 > grrr. --- a/lib/Makefile~uninline-check_signature-fix +++ a/lib/Makefile @@ -5,8 +5,7 @@ lib-y := ctype.o string.o vsprintf.o cmdline.o \ rbtree.o radix-tree.o dump_stack.o \ idr.o int_sqrt.o bitmap.o extable.o prio_tree.o \ -sha1.o irq_regs.o reciprocal_div.o argv_split.o \ -check_signature.o +sha1.o irq_regs.o reciprocal_div.o argv_split.o lib-$(CONFIG_MMU) += ioremap.o pagewalk.o lib-$(CONFIG_SMP) += cpumask.o @@ -14,7 +13,7 @@ lib-$(CONFIG_SMP) += cpumask.o lib-y += kobject.o kref.o kobject_uevent.o klist.o obj-y += div64.o sort.o parser.o halfmd4.o debug_locks.o random32.o \ -bust_spinlocks.o hexdump.o +bust_spinlocks.o hexdump.o check_signature.o ifeq ($(CONFIG_DEBUG_KOBJECT),y) CFLAGS_kobject.o += -DDEBUG _ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
