LinuxLists.cc - 2.6.19-rc5-mm2

by tip-bot for Gautham R Shenoy

[permalink] [raw]

Subject: Re: 2.6.19-rc5-mm2

On Tue, 14 Nov 2006 13:46:51 +0100
Mariusz Kozlowski <[email protected]> wrote:

> Hello,
>
> On every box I tried I got this warning:
>
> $ make
> scripts/kconfig/conf -s arch/i386/Kconfig
> Warning! Found recursive dependency: INET IPV6 DLM (null) DLM_TCP INET

yup. The GFS guys have since fixed that.

> Second thing: the same thing as with 2.6.19-rc5-mm1 happens:
>
> > > > > LD .tmp_vmlinux1
> > > > > arch/x86_64/kernel/built-in.o(.init.text+0x31b7): In function
> > > > > `alternative_instructions': arch/i386/kernel/alternative.c:437:
> undefined
> > > > > reference to `__stop_parainstructions'
> > > > >
> arch/x86_64/kernel/built-in.o(.init.text+0x31be):arch/i386/kernel/alterna
> > > > >tive.c:437: undefined reference to `__start_parainstructions' make: ***
> > > > > [.tmp_vmlinux1] Error 1
> > > >
> > > > Thanks. Please send me the .config and I'll see if it's still
> happening.
> > >
> > > Please find .config attached.
> >
> > Thanks. The paravirt patches have churned a bit recently and we appear to
> > have fixed this one.
>
> Here it goes:
>
> LD .tmp_vmlinux1
> arch/x86_64/kernel/built-in.o(.init.text+0x328f): In function
> `alternative_instructions':
> arch/i386/kernel/alternative.c:437: undefined reference to
> `__stop_parainstructions'
> arch/x86_64/kernel/built-in.o(.init.text+0x3296):arch/i386/kernel/alternative.c:437:
> undefined reference to `__start_parainstructions'
> make: *** [.tmp_vmlinux1] Error 1

Strange, I don't get that with your .config. I guess it's a binutils
difference.

This should fix it:

diff -puN arch/i386/kernel/alternative.c~fix-x86_64-mm-patch-inline-replacements-for arch/i386/kernel/alternative.c
--- a/arch/i386/kernel/alternative.c~fix-x86_64-mm-patch-inline-replacements-for
+++ a/arch/i386/kernel/alternative.c
@@ -381,10 +381,7 @@ void apply_paravirt(struct paravirt_patc
extern struct paravirt_patch __start_parainstructions[],
__stop_parainstructions[];
#else
-void apply_paravirt(struct paravirt_patch *start, struct paravirt_patch *end)
-{
-}
-extern struct paravirt_patch *__start_parainstructions, *__stop_parainstructions;
+#define apply_paravirt(start, end) do { } while (0)
#endif /* CONFIG_PARAVIRT */

void __init alternative_instructions(void)
_

2006-11-14 17:00:51

[permalink] [raw]

Subject: Re: 2.6.19-rc5-mm2

On Tue, Nov 14, 2006 at 10:31:40PM +1100, Reuben Farrelly wrote:

Hi Reuben,

> Oops:
>
> (davej cc'd - I think it's his specialty)
>

[snip]

> ------------[ cut here ]------------
> kernel BUG at drivers/cpufreq/cpufreq_userspace.c:138!
> invalid opcode: 0000 [1] SMP
> last sysfs file:
> CPU 0
> Modules linked in:
> Pid: 1, comm: swapper Not tainted 2.6.19-rc5-mm2 #1
> RIP: 0010:[<ffffffff80435299>] [<ffffffff80435299>]
> cpufreq_governor_userspace+0x4e/0x1aa
> RSP: 0000:ffff81003f61fb40 EFLAGS: 00010246
> RAX: 0000000000000000 RBX: ffff81003ef4a0d8 RCX: 0000000000000003
> RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff81003ef4a0d8
> RBP: ffff81003f61fb60 R08: 0000000000000002 R09: 0000000000000001
> R10: 0000000000000002 R11: 0000000000000001 R12: 0000000000000000
> R13: 00000000ffffffea R14: 0000000000000000 R15: 0000000000000000
> FS: 0000000000000000(0000) GS:ffffffff80652000(0000) knlGS:0000000000000000
> CS: 0010 DS: 0018 ES: 0018 CR0: 000000008005003b
> CR2: 0000000000000000 CR3: 0000000000201000 CR4: 00000000000006e0
> Process swapper (pid: 1, threadinfo ffff81003f61e000, task ffff810037ff0040)
> Stack: ffff81003f61fb60 ffff81003ef4a0d8 0000000000000001 ffff81003ef4a0d8
> ffff81003f61fb90 ffffffff80433b11 ffffffff805d0e80 ffff81003f61fc20
> 0000000000000000 ffff81003ef4a0d8 ffff81003f61fbc0 ffffffff80434278
> Call Trace:
> [<ffffffff80433b11>] __cpufreq_governor+0x51/0x9b
> [<ffffffff80434278>] __cpufreq_set_policy+0xf8/0x13b
> [<ffffffff804343e9>] cpufreq_set_policy+0x3c/0x93
> [<ffffffff80435125>] cpufreq_add_dev+0x315/0x427
> [<ffffffff803b6f87>] sysdev_driver_register+0x87/0xdb
> [<ffffffff80434a8e>] cpufreq_register_driver+0x9e/0x120
> [<ffffffff806837b2>] acpi_cpufreq_init+0xbe/0xc9
> [<ffffffff802666c0>] init+0x160/0x31c
> [<ffffffff8025deb8>] child_rip+0xa/0x12
>
>

Hmmm.. The BUG indicates policy->cur i.e current frequency is 0.

In this scenario, policy->cur variable was last set inside
acpi_cpufreq_cpu_init when cpufreq_add_dev made a call to
cpufreq_driver->init(policy).

Are you able to reproduce this with 2.6.19-rc5-mm1?

Because AFAICS, there ain't many changes w.r.t x86_64 acpi-cpufreq
from 2.6.19-rc5-mm1 to 2.6.19-rc5-mm2.

>
> I've put the full config up at
> http://www.reub.net/files/kernel/configs/2.6.19-rc5-mm1-brokencpufreq

I hope the name 2.6.19-rc5-'mm1'-brokencpufreq is by mistake :-)

> Disable cpufreq in the config and the kernel otherwise boots and works fine.
>
> Reuben

regards,
gautham.
--
Gautham R Shenoy
Linux Technology Center
IBM India.
"Freedom comes with a price tag of responsibility, which is still a bargain,
because Freedom is priceless!"

2006-11-14 17:09:56

[permalink] [raw]

Subject: Re: 2.6.19-rc5-mm2

On Tue, 14 Nov 2006 08:41:30 -0800
Andrew Morton <[email protected]> wrote:

> This should fix it:
>
>
> diff -puN arch/i386/kernel/alternative.c~fix-x86_64-mm-patch-inline-replacements-for arch/i386/kernel/alternative.c
> --- a/arch/i386/kernel/alternative.c~fix-x86_64-mm-patch-inline-replacements-for
> +++ a/arch/i386/kernel/alternative.c
> @@ -381,10 +381,7 @@ void apply_paravirt(struct paravirt_patc
> extern struct paravirt_patch __start_parainstructions[],
> __stop_parainstructions[];
> #else
> -void apply_paravirt(struct paravirt_patch *start, struct paravirt_patch *end)
> -{
> -}
> -extern struct paravirt_patch *__start_parainstructions, *__stop_parainstructions;
> +#define apply_paravirt(start, end) do { } while (0)
> #endif /* CONFIG_PARAVIRT */
>
> void __init alternative_instructions(void)

hm, but that breaks x86. Maybe this..

arch/i386/kernel/alternative.c | 5 -----
include/asm-i386/alternative.h | 4 ++++
include/asm-x86_64/alternative.h | 4 ++++
3 files changed, 8 insertions(+), 5 deletions(-)

diff -puN arch/i386/kernel/alternative.c~fix-x86_64-mm-patch-inline-replacements-for arch/i386/kernel/alternative.c
--- a/arch/i386/kernel/alternative.c~fix-x86_64-mm-patch-inline-replacements-for
+++ a/arch/i386/kernel/alternative.c
@@ -380,11 +380,6 @@ void apply_paravirt(struct paravirt_patc
}
extern struct paravirt_patch __start_parainstructions[],
__stop_parainstructions[];
-#else
-void apply_paravirt(struct paravirt_patch *start, struct paravirt_patch *end)
-{
-}
-extern struct paravirt_patch *__start_parainstructions, *__stop_parainstructions;
#endif /* CONFIG_PARAVIRT */

void __init alternative_instructions(void)
diff -puN include/asm-i386/alternative.h~fix-x86_64-mm-patch-inline-replacements-for include/asm-i386/alternative.h
--- a/include/asm-i386/alternative.h~fix-x86_64-mm-patch-inline-replacements-for
+++ a/include/asm-i386/alternative.h
@@ -119,6 +119,10 @@ static inline void alternatives_smp_swit
#endif

struct paravirt_patch;
+#ifdef CONFIG_PARAVIRT
void apply_paravirt(struct paravirt_patch *start, struct paravirt_patch *end);
+#else
+#define apply_paravirt(start, end) do { } while (0)
+#endif

#endif /* _I386_ALTERNATIVE_H */
diff -puN include/asm-x86_64/alternative.h~fix-x86_64-mm-patch-inline-replacements-for include/asm-x86_64/alternative.h
--- a/include/asm-x86_64/alternative.h~fix-x86_64-mm-patch-inline-replacements-for
+++ a/include/asm-x86_64/alternative.h
@@ -134,6 +134,10 @@ static inline void alternatives_smp_swit
#endif

struct paravirt_patch;
+#ifdef CONFIG_PARAVIRT
void apply_paravirt(struct paravirt_patch *start, struct paravirt_patch *end);
+#else
+#define apply_paravirt(start, end) do { } while (0)
+#endif

#endif /* _X86_64_ALTERNATIVE_H */
_

Unpleasant duplication there. Perhaps we should have linux/alternative.h

2006-11-14 18:33:20

[permalink] [raw]

Subject: [-mm patch] fix the DLM dependencies.

On Tue, Nov 14, 2006 at 01:41:25AM -0800, Andrew Morton wrote:
>...
> - A nasty Kconfig warning comes out during the build. It's due to
> git-gfs2-nmw.patch.
>...

So let's fix it. ;-)

cu
Adrian

<-- snip -->

Kconfig said:
Warning! Found recursive dependency: INET IPV6 DLM (null) DLM_TCP INET

Due to the "depends on IPV6 || IPV6=n" it's not really a circular
dependency, but there's another bug that anyway should be fixed:
The "select IP_SCTP" ignored the dependency of IP_SCTP on INET.

Considering that:
- there's no way to use DLM with INET=n and
- INET=n being a mostly pathological case
this patch fixes both this bug and the "recursive dependency" warning by
letting DLM depend on INET again.

Signed-off-by: Adrian Bunk <[email protected]>

--- linux-2.6.19-rc5-mm2/fs/dlm/Kconfig.old 2006-11-14 18:41:35.000000000 +0100
+++ linux-2.6.19-rc5-mm2/fs/dlm/Kconfig 2006-11-14 18:44:12.000000000 +0100
@@ -1,5 +1,5 @@
menu "Distributed Lock Manager"
- depends on EXPERIMENTAL
+ depends on EXPERIMENTAL && INET

config DLM
tristate "Distributed Lock Manager (DLM)"
@@ -20,7 +20,6 @@ choice

config DLM_TCP
bool "TCP/IP"
- select INET

config DLM_SCTP
bool "SCTP"

2006-11-14 18:49:24

by mel

[permalink] [raw]

Subject: Boot failure with ext2 and initrds

On (14/11/06 01:41), Andrew Morton didst pronounce:
>
> Presently at
>
> http://userweb.kernel.org/~akpm/2.6.19-rc5-mm2/
>
> and will appear later at
>
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.19-rc5/2.6.19-rc5-mm2/
>

Am seeing errors with systems using ext2. First machine is a plan old x86
using initramfs. Console output looks like;

RAMDISK: Compressed image found at block 0
VFS: Mounted root (ext2 filesystem).
Starting udev
Creating devices
EXT2-fs error (device ram0): ext2_new_blocks: Allocating block in system zone - blocks from 0, length 0
EXT2-fs error (device ram0): ext2_new_blocks: block(0) >= blocks count(5164) - block_group = 0, es == dff00400
EXT2-fs error (device ram0): ext2_new_blocks: Allocating block in system zone - blocks from 0, length 0
EXT2-fs error (device ram0): ext2_new_blocks: block(0) >= blocks count(5164) - block_group = 0, es == dff00400
EXT2-fs error (device ram0): ext2_new_blocks: Allocating block in system zone - blocks from 0, length 0
EXT2-fs error (device ram0): ext2_new_blocks: block(0) >= blocks count(5164) - block_group = 0, es == dff00400
EXT2-fs error (device ram0): ext2_new_blocks: Allocating block in system zone - blocks from 0, length 0
EXT2-fs error (device ram0): ext2_new_blocks: block(0) >= blocks count(5164) - block_group = 0, es == dff00400
EXT2-fs error (device ram0): ext2_new_blocks: Allocating block in system zone - blocks from 0, length 0
EXT2-fs error (device ram0): ext2_new_blocks: block(0) >= blocks count(5164) - block_group = 0, es == dff00400

Second machine is a numaq with an ext2 root filesystem

hecking root file system...
fsck 1.37 (21-Mar-2005)
e2fsck 1.37 (21-Mar-2005)
/dev/sda1: clean, 310908/2240224 files, 2189096/4480119 blocks (check in
3 mounts)
System time was Tue Nov 14 17:06:21 UTC 2006.
Setting the System Clock using the Hardware Clock as reference...
System Clock set. System local time is now Tue Nov 14 17:06:23 UTC 2006.
Cleaning up ifupdown...done.
Calculating module dependencies... done.
Loading modules...
All modules loaded.
Creating device-mapper devices...done.
Checking all file systems...
fsck 1.37 (21-Mar-2005)
Setting kernel variables ...
... done.
Mounting local filesystems...
Unable to find swap-space signature
Cleaning /tmp /var/run /var/lock.
Running 0dns-down to make sure resolv.conf is ok...done.
Setting up networking...done.
Setting up IP spoofing protection: rp_filter.
Configuring network interfaces...BUG: soft lockup detected on CPU#3!
[<c0139233>] softlockup_tick+0x9e/0xac
[<c0124a16>] update_process_times+0x4b/0x77
[<c0132438>] handle_update_profile+0x1c/0x2a
[<c010d45a>] local_apic_timer_interrupt+0x43/0x48
[<c010d486>] smp_apic_timer_interrupt+0x27/0x36
[<c0103598>] apic_timer_interrupt+0x28/0x30
[<c01b3b80>] ext2_try_to_allocate+0xdb/0x152
[<c01b3e72>] ext2_try_to_allocate_with_rsv+0x4b/0x1b2
[<c01b42c6>] ext2_new_blocks+0x28d/0x4b3
[<c01b667a>] ext2_alloc_blocks+0x4b/0xcd
[<c01b674a>] ext2_alloc_branch+0x4e/0x1ae
[<c01b36a8>] ext2_init_block_alloc_info+0x26/0x6d
[<c01b6b9b>] ext2_get_blocks+0x23c/0x31d
[<c0181c89>] alloc_buffer_head+0x38/0x3e
[<c017f2ef>] alloc_page_buffers+0x6f/0xb2
[<c01b6cb9>] ext2_get_block+0x3d/0x51
[<c0180162>] __block_prepare_write+0x186/0x41b
[<c0180c3c>] block_prepare_write+0x31/0x3f
[<c01b6c7c>] ext2_get_block+0x0/0x51
[<c013d470>] generic_file_buffered_write+0x227/0x62a
[<c01b6c7c>] ext2_get_block+0x0/0x51
[<c0173936>] file_update_time+0x3e/0xbc
[<c013e08e>] __generic_file_aio_write_nolock+0x538/0x563
[<c013b957>] find_get_page+0x22/0x43
[<c013e1d2>] generic_file_aio_write+0x69/0xd1
[<c01616a9>] do_sync_write+0xda/0x117
[<c012e45d>] autoremove_wake_function+0x0/0x4b
[<c011201c>] do_page_fault+0x394/0x6c8
[<c0161787>] vfs_write+0xa1/0x167
[<c0161909>] sys_write+0x4b/0x71
[<c0102b40>] syscall_call+0x7/0xb
[<c0330033>] __mutex_lock_interruptible_slowpath+0x7f/0x94
=======================
BUG: soft lockup detected on CPU#3!
[<c0139233>] softlockup_tick+0x9e/0xac
[<c0124a16>] update_process_times+0x4b/0x77
[<c0132438>] handle_update_profile+0x1c/0x2a
[<c010d45a>] local_apic_timer_interrupt+0x43/0x48
[<c010d486>] smp_apic_timer_interrupt+0x27/0x36
[<c0103598>] apic_timer_interrupt+0x28/0x30
[<c01b3b79>] ext2_try_to_allocate+0xd4/0x152
[<c01b3e72>] ext2_try_to_allocate_with_rsv+0x4b/0x1b2
[<c01b42c6>] ext2_new_blocks+0x28d/0x4b3
[<c01b667a>] ext2_alloc_blocks+0x4b/0xcd
[<c01b674a>] ext2_alloc_branch+0x4e/0x1ae
[<c01b36a8>] ext2_init_block_alloc_info+0x26/0x6d
[<c01b6b9b>] ext2_get_blocks+0x23c/0x31d
[<c0181c89>] alloc_buffer_head+0x38/0x3e
[<c017f2ef>] alloc_page_buffers+0x6f/0xb2
[<c01b6cb9>] ext2_get_block+0x3d/0x51
[<c0180162>] __block_prepare_write+0x186/0x41b
[<c0180c3c>] block_prepare_write+0x31/0x3f
[<c01b6c7c>] ext2_get_block+0x0/0x51
[<c013d470>] generic_file_buffered_write+0x227/0x62a
[<c01b6c7c>] ext2_get_block+0x0/0x51
[<c0173936>] file_update_time+0x3e/0xbc
[<c013e08e>] __generic_file_aio_write_nolock+0x538/0x563
[<c013b957>] find_get_page+0x22/0x43
[<c013e1d2>] generic_file_aio_write+0x69/0xd1
[<c01616a9>] do_sync_write+0xda/0x117
[<c012e45d>] autoremove_wake_function+0x0/0x4b
[<c011201c>] do_page_fault+0x394/0x6c8
[<c0161787>] vfs_write+0xa1/0x167
[<c0161909>] sys_write+0x4b/0x71
[<c0102b40>] syscall_call+0x7/0xb
[<c0330033>] __mutex_lock_interruptible_slowpath+0x7f/0x94
(message repeats a lot)

I've not investigated yet what patches might be at fault.

2006-11-14 19:08:44

[permalink] [raw]

Subject: Re: Boot failure with ext2 and initrds

Mel Gorman wrote:
> On (14/11/06 01:41), Andrew Morton didst pronounce:
>> Presently at
>>
>> http://userweb.kernel.org/~akpm/2.6.19-rc5-mm2/
>>
>> and will appear later at
>>
>> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.19-rc5/2.6.19-rc5-mm2/
>>
>
> Am seeing errors with systems using ext2. First machine is a plan old x86
> using initramfs. Console output looks like;

Probably from the ext2 reservations stuff. Any chance you could back out:

ext2-reservations.patch
ext2-reservations-fix.patch
ext2-reservations-sequential-read-regression-fix.patch
ext2-reservations-filesystem-bogus-ENOSPC-with-reservation-fix.patch
ext2-reservations-ext3_clear_inode-avoid-kfree-null.patch
ext2-reservations-multile-block-allocate-little-endian-fixes.patch
ext2-reservations-mark-group-descriptors-dirty-during-allocation.patch
ext2-reservations-nuke-noisy-printk.patch
ext2-reservations-bring-ext2-reservations-code-in-line-with-latest-ext3.patch

and see if it goes away?

Else I shall pray that Val or Mingming is smarter than I am and can
see what went wrong ;-)

Thanks,

M.

> RAMDISK: Compressed image found at block 0
> VFS: Mounted root (ext2 filesystem).
> Starting udev
> Creating devices
> EXT2-fs error (device ram0): ext2_new_blocks: Allocating block in system zone - blocks from 0, length 0
> EXT2-fs error (device ram0): ext2_new_blocks: block(0) >= blocks count(5164) - block_group = 0, es == dff00400
> EXT2-fs error (device ram0): ext2_new_blocks: Allocating block in system zone - blocks from 0, length 0
> EXT2-fs error (device ram0): ext2_new_blocks: block(0) >= blocks count(5164) - block_group = 0, es == dff00400
> EXT2-fs error (device ram0): ext2_new_blocks: Allocating block in system zone - blocks from 0, length 0
> EXT2-fs error (device ram0): ext2_new_blocks: block(0) >= blocks count(5164) - block_group = 0, es == dff00400
> EXT2-fs error (device ram0): ext2_new_blocks: Allocating block in system zone - blocks from 0, length 0
> EXT2-fs error (device ram0): ext2_new_blocks: block(0) >= blocks count(5164) - block_group = 0, es == dff00400
> EXT2-fs error (device ram0): ext2_new_blocks: Allocating block in system zone - blocks from 0, length 0
> EXT2-fs error (device ram0): ext2_new_blocks: block(0) >= blocks count(5164) - block_group = 0, es == dff00400
>
> Second machine is a numaq with an ext2 root filesystem
>
> hecking root file system...
> fsck 1.37 (21-Mar-2005)
> e2fsck 1.37 (21-Mar-2005)
> /dev/sda1: clean, 310908/2240224 files, 2189096/4480119 blocks (check in
> 3 mounts)
> System time was Tue Nov 14 17:06:21 UTC 2006.
> Setting the System Clock using the Hardware Clock as reference...
> System Clock set. System local time is now Tue Nov 14 17:06:23 UTC 2006.
> Cleaning up ifupdown...done.
> Calculating module dependencies... done.
> Loading modules...
> All modules loaded.
> Creating device-mapper devices...done.
> Checking all file systems...
> fsck 1.37 (21-Mar-2005)
> Setting kernel variables ...
> ... done.
> Mounting local filesystems...
> Unable to find swap-space signature
> Cleaning /tmp /var/run /var/lock.
> Running 0dns-down to make sure resolv.conf is ok...done.
> Setting up networking...done.
> Setting up IP spoofing protection: rp_filter.
> Configuring network interfaces...BUG: soft lockup detected on CPU#3!
> [<c0139233>] softlockup_tick+0x9e/0xac
> [<c0124a16>] update_process_times+0x4b/0x77
> [<c0132438>] handle_update_profile+0x1c/0x2a
> [<c010d45a>] local_apic_timer_interrupt+0x43/0x48
> [<c010d486>] smp_apic_timer_interrupt+0x27/0x36
> [<c0103598>] apic_timer_interrupt+0x28/0x30
> [<c01b3b80>] ext2_try_to_allocate+0xdb/0x152
> [<c01b3e72>] ext2_try_to_allocate_with_rsv+0x4b/0x1b2
> [<c01b42c6>] ext2_new_blocks+0x28d/0x4b3
> [<c01b667a>] ext2_alloc_blocks+0x4b/0xcd
> [<c01b674a>] ext2_alloc_branch+0x4e/0x1ae
> [<c01b36a8>] ext2_init_block_alloc_info+0x26/0x6d
> [<c01b6b9b>] ext2_get_blocks+0x23c/0x31d
> [<c0181c89>] alloc_buffer_head+0x38/0x3e
> [<c017f2ef>] alloc_page_buffers+0x6f/0xb2
> [<c01b6cb9>] ext2_get_block+0x3d/0x51
> [<c0180162>] __block_prepare_write+0x186/0x41b
> [<c0180c3c>] block_prepare_write+0x31/0x3f
> [<c01b6c7c>] ext2_get_block+0x0/0x51
> [<c013d470>] generic_file_buffered_write+0x227/0x62a
> [<c01b6c7c>] ext2_get_block+0x0/0x51
> [<c0173936>] file_update_time+0x3e/0xbc
> [<c013e08e>] __generic_file_aio_write_nolock+0x538/0x563
> [<c013b957>] find_get_page+0x22/0x43
> [<c013e1d2>] generic_file_aio_write+0x69/0xd1
> [<c01616a9>] do_sync_write+0xda/0x117
> [<c012e45d>] autoremove_wake_function+0x0/0x4b
> [<c011201c>] do_page_fault+0x394/0x6c8
> [<c0161787>] vfs_write+0xa1/0x167
> [<c0161909>] sys_write+0x4b/0x71
> [<c0102b40>] syscall_call+0x7/0xb
> [<c0330033>] __mutex_lock_interruptible_slowpath+0x7f/0x94
> =======================
> BUG: soft lockup detected on CPU#3!
> [<c0139233>] softlockup_tick+0x9e/0xac
> [<c0124a16>] update_process_times+0x4b/0x77
> [<c0132438>] handle_update_profile+0x1c/0x2a
> [<c010d45a>] local_apic_timer_interrupt+0x43/0x48
> [<c010d486>] smp_apic_timer_interrupt+0x27/0x36
> [<c0103598>] apic_timer_interrupt+0x28/0x30
> [<c01b3b79>] ext2_try_to_allocate+0xd4/0x152
> [<c01b3e72>] ext2_try_to_allocate_with_rsv+0x4b/0x1b2
> [<c01b42c6>] ext2_new_blocks+0x28d/0x4b3
> [<c01b667a>] ext2_alloc_blocks+0x4b/0xcd
> [<c01b674a>] ext2_alloc_branch+0x4e/0x1ae
> [<c01b36a8>] ext2_init_block_alloc_info+0x26/0x6d
> [<c01b6b9b>] ext2_get_blocks+0x23c/0x31d
> [<c0181c89>] alloc_buffer_head+0x38/0x3e
> [<c017f2ef>] alloc_page_buffers+0x6f/0xb2
> [<c01b6cb9>] ext2_get_block+0x3d/0x51
> [<c0180162>] __block_prepare_write+0x186/0x41b
> [<c0180c3c>] block_prepare_write+0x31/0x3f
> [<c01b6c7c>] ext2_get_block+0x0/0x51
> [<c013d470>] generic_file_buffered_write+0x227/0x62a
> [<c01b6c7c>] ext2_get_block+0x0/0x51
> [<c0173936>] file_update_time+0x3e/0xbc
> [<c013e08e>] __generic_file_aio_write_nolock+0x538/0x563
> [<c013b957>] find_get_page+0x22/0x43
> [<c013e1d2>] generic_file_aio_write+0x69/0xd1
> [<c01616a9>] do_sync_write+0xda/0x117
> [<c012e45d>] autoremove_wake_function+0x0/0x4b
> [<c011201c>] do_page_fault+0x394/0x6c8
> [<c0161787>] vfs_write+0xa1/0x167
> [<c0161909>] sys_write+0x4b/0x71
> [<c0102b40>] syscall_call+0x7/0xb
> [<c0330033>] __mutex_lock_interruptible_slowpath+0x7f/0x94
> (message repeats a lot)
>
> I've not investigated yet what patches might be at fault.
> -
> 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/
>
>

2006-11-14 19:11:07

[permalink] [raw]

Subject: Re: Boot failure with ext2 and initrds

On Tue, 14 Nov 2006, Mel Gorman wrote:
> 2.6.19-rc5-mm2
>
> Am seeing errors with systems using ext2. First machine is a plan old x86
> using initramfs. Console output looks like;
> ...
> Configuring network interfaces...BUG: soft lockup detected on CPU#3!
> ...
> [<c01b3b80>] ext2_try_to_allocate+0xdb/0x152
> [<c01b3e72>] ext2_try_to_allocate_with_rsv+0x4b/0x1b2
>
> I've not investigated yet what patches might be at fault.

I expect you'll find it's
ext2-reservations-bring-ext2-reservations-code-in-line-with-latest-ext3.patch
which gets stuck in a loop there for me too: back it out and all seems fine.

It's not obvious which part of the patch is to blame: mostly it's
cleanup, but a few variables do change size: I'm currently narrowing
down to where a fix is needed.

Hugh

2006-11-14 19:21:52

[permalink] [raw]

Subject: Re: Boot failure with ext2 and initrds

Hugh Dickins wrote:
> On Tue, 14 Nov 2006, Mel Gorman wrote:
>> 2.6.19-rc5-mm2
>>
>> Am seeing errors with systems using ext2. First machine is a plan old x86
>> using initramfs. Console output looks like;
>> ...
>> Configuring network interfaces...BUG: soft lockup detected on CPU#3!
>> ...
>> [<c01b3b80>] ext2_try_to_allocate+0xdb/0x152
>> [<c01b3e72>] ext2_try_to_allocate_with_rsv+0x4b/0x1b2
>>
>> I've not investigated yet what patches might be at fault.
>
> I expect you'll find it's
> ext2-reservations-bring-ext2-reservations-code-in-line-with-latest-ext3.patch
> which gets stuck in a loop there for me too: back it out and all seems fine.
>
> It's not obvious which part of the patch is to blame: mostly it's
> cleanup, but a few variables do change size: I'm currently narrowing
> down to where a fix is needed.

Humpf. that was meant to be one of those "so obvious I can't screw it
up" patches.

typedef unsigned long ext2_fsblk_t;
typedef int ext2_grpblk_t;

in ext2_alloc_blocks we do change from "unsigned long long" to
"unsigned long" for new_blocks[], but akpm thinks that was garbage
before (same for ext2_alloc_branch's current_block)

The ext2_grpblk_t ones all look innocuous.

2006-11-14 19:24:22

by Mariusz Kozlowski

[permalink] [raw]

Subject: Re: 2.6.19-rc5-mm2

> hm, but that breaks x86. Maybe this..
>
>
> arch/i386/kernel/alternative.c | 5 -----
> include/asm-i386/alternative.h | 4 ++++
> include/asm-x86_64/alternative.h | 4 ++++
> 3 files changed, 8 insertions(+), 5 deletions(-)
>
> diff -puN
> arch/i386/kernel/alternative.c~fix-x86_64-mm-patch-inline-replacements-for
> arch/i386/kernel/alternative.c ---
> a/arch/i386/kernel/alternative.c~fix-x86_64-mm-patch-inline-replacements-fo
>r +++ a/arch/i386/kernel/alternative.c
> @@ -380,11 +380,6 @@ void apply_paravirt(struct paravirt_patc
> }
> extern struct paravirt_patch __start_parainstructions[],
> __stop_parainstructions[];
> -#else
> -void apply_paravirt(struct paravirt_patch *start, struct paravirt_patch
> *end) -{
> -}
> -extern struct paravirt_patch *__start_parainstructions,
> *__stop_parainstructions; #endif /* CONFIG_PARAVIRT */
>
> void __init alternative_instructions(void)
> diff -puN
> include/asm-i386/alternative.h~fix-x86_64-mm-patch-inline-replacements-for
> include/asm-i386/alternative.h ---
> a/include/asm-i386/alternative.h~fix-x86_64-mm-patch-inline-replacements-fo
>r +++ a/include/asm-i386/alternative.h
> @@ -119,6 +119,10 @@ static inline void alternatives_smp_swit
> #endif
>
> struct paravirt_patch;
> +#ifdef CONFIG_PARAVIRT
> void apply_paravirt(struct paravirt_patch *start, struct paravirt_patch
> *end); +#else
> +#define apply_paravirt(start, end) do { } while (0)
> +#endif
>
> #endif /* _I386_ALTERNATIVE_H */
> diff -puN
> include/asm-x86_64/alternative.h~fix-x86_64-mm-patch-inline-replacements-fo
>r include/asm-x86_64/alternative.h ---
> a/include/asm-x86_64/alternative.h~fix-x86_64-mm-patch-inline-replacements-
>for +++ a/include/asm-x86_64/alternative.h
> @@ -134,6 +134,10 @@ static inline void alternatives_smp_swit
> #endif
>
> struct paravirt_patch;
> +#ifdef CONFIG_PARAVIRT
> void apply_paravirt(struct paravirt_patch *start, struct paravirt_patch
> *end); +#else
> +#define apply_paravirt(start, end) do { } while (0)
> +#endif
>
> #endif /* _X86_64_ALTERNATIVE_H */
> _
>
>
> Unpleasant duplication there. Perhaps we should have linux/alternative.h

Thanks. It compiled fine with this patch.

--
Regards,

Mariusz Kozlowski

2006-11-14 19:31:36

[permalink] [raw]

Subject: Re: Boot failure with ext2 and initrds

On Tue, 14 Nov 2006 19:11:22 +0000 (GMT)
Hugh Dickins <[email protected]> wrote:

> On Tue, 14 Nov 2006, Mel Gorman wrote:
> > 2.6.19-rc5-mm2
> >
> > Am seeing errors with systems using ext2. First machine is a plan old x86
> > using initramfs. Console output looks like;
> > ...
> > Configuring network interfaces...BUG: soft lockup detected on CPU#3!
> > ...
> > [<c01b3b80>] ext2_try_to_allocate+0xdb/0x152
> > [<c01b3e72>] ext2_try_to_allocate_with_rsv+0x4b/0x1b2
> >
> > I've not investigated yet what patches might be at fault.
>
> I expect you'll find it's
> ext2-reservations-bring-ext2-reservations-code-in-line-with-latest-ext3.patch
> which gets stuck in a loop there for me too: back it out and all seems fine.
>
> It's not obvious which part of the patch is to blame: mostly it's
> cleanup, but a few variables do change size: I'm currently narrowing
> down to where a fix is needed.
>

Doing s/-Wall/-W/ tends to shake out bugs in this stuff.

The below might help.

Sorry, I tested this well, then the cleanup patch was merged and I didn't
get onto retesting :(

From: Andrew Morton <[email protected]>

Signed-off-by: Andrew Morton <[email protected]>
---

fs/ext2/balloc.c | 33 +++++++++++++++------------------
1 files changed, 15 insertions(+), 18 deletions(-)

diff -puN fs/ext2/balloc.c~ext2-reservations-bring-ext2-reservations-code-in-line-with-latest-ext3-fix fs/ext2/balloc.c
--- a/fs/ext2/balloc.c~ext2-reservations-bring-ext2-reservations-code-in-line-with-latest-ext3-fix
+++ a/fs/ext2/balloc.c
@@ -1155,9 +1155,10 @@ int ext2_new_blocks(struct inode *inode,
struct buffer_head *gdp_bh;
int group_no;
int goal_group;
+ ext2_grpblk_t grp_target_blk; /* blockgroup relative goal block */
+ ext2_grpblk_t grp_alloc_blk; /* blockgroup-relative allocated block*/
ext2_fsblk_t ret_block; /* filesyetem-wide allocated block */
int bgi; /* blockgroup iteration index */
- int target_block;
int performed_allocation = 0;
ext2_grpblk_t free_blocks; /* number of free blocks in a group */
struct super_block *sb;
@@ -1230,14 +1231,15 @@ retry_alloc:
my_rsv = NULL;

if (free_blocks > 0) {
- ret_block = ((goal - le32_to_cpu(es->s_first_data_block)) %
+ grp_target_blk = ((goal - le32_to_cpu(es->s_first_data_block)) %
EXT2_BLOCKS_PER_GROUP(sb));
bitmap_bh = read_block_bitmap(sb, group_no);
if (!bitmap_bh)
goto io_error;
- ret_block = ext2_try_to_allocate_with_rsv(sb, group_no,
- bitmap_bh, ret_block, my_rsv, &num);
- if (ret_block >= 0)
+ grp_alloc_blk = ext2_try_to_allocate_with_rsv(sb, group_no,
+ bitmap_bh, grp_target_blk,
+ my_rsv, &num);
+ if (grp_alloc_blk >= 0)
goto allocated;
}

@@ -1273,9 +1275,9 @@ retry_alloc:
/*
* try to allocate block(s) from this group, without a goal(-1).
*/
- ret_block = ext2_try_to_allocate_with_rsv(sb, group_no,
+ grp_alloc_blk = ext2_try_to_allocate_with_rsv(sb, group_no,
bitmap_bh, -1, my_rsv, &num);
- if (ret_block >= 0)
+ if (grp_alloc_blk >= 0)
goto allocated;
}
/*
@@ -1299,25 +1301,20 @@ allocated:
ext2_debug("using block group %d(%d)\n",
group_no, gdp->bg_free_blocks_count);

- target_block = ret_block + group_no * EXT2_BLOCKS_PER_GROUP(sb)
- + le32_to_cpu(es->s_first_data_block);
+ ret_block = grp_alloc_blk + ext2_group_first_block_no(sb, group_no);

- if (in_range(le32_to_cpu(gdp->bg_block_bitmap), target_block, num) ||
- in_range(le32_to_cpu(gdp->bg_inode_bitmap), target_block, num) ||
- in_range(target_block, le32_to_cpu(gdp->bg_inode_table),
+ if (in_range(le32_to_cpu(gdp->bg_block_bitmap), ret_block, num) ||
+ in_range(le32_to_cpu(gdp->bg_inode_bitmap), ret_block, num) ||
+ in_range(ret_block, le32_to_cpu(gdp->bg_inode_table),
EXT2_SB(sb)->s_itb_per_group) ||
- in_range(target_block + num - 1, le32_to_cpu(gdp->bg_inode_table),
+ in_range(ret_block + num - 1, le32_to_cpu(gdp->bg_inode_table),
EXT2_SB(sb)->s_itb_per_group))
ext2_error(sb, "ext2_new_blocks",
"Allocating block in system zone - "
- "blocks from %u, length %lu", target_block, num);
+ "blocks from %u, length %lu", ret_block, num);

performed_allocation = 1;

-
- /* ret_block was blockgroup-relative. Now it becomes fs-relative */
- ret_block = target_block;
-
if (ret_block + num - 1 >= le32_to_cpu(es->s_blocks_count)) {
ext2_error(sb, "ext2_new_blocks",
"block("E2FSBLK") >= blocks count(%d) - "
_

2006-11-14 20:02:45

[permalink] [raw]

Subject: 2.6.19-rc5-mm2: no help text for FAULT_INJECTION

On Tue, Nov 14, 2006 at 01:41:25AM -0800, Andrew Morton wrote:
>...
> Changes since 2.6.19-rc5-mm2:
>...
> +fault-injection-Kconfig-cleanup.patch
>...
> Fault-injection framework and applications thereof.
>...

The FAULT_INJECTION option lacks a help text.

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

2006-11-14 20:20:31

[permalink] [raw]

Subject: Re: Boot failure with ext2 and initrds

On Tue, 14 Nov 2006, Martin Bligh wrote:
> Hugh Dickins wrote:
> > I expect you'll find it's
> > ext2-reservations-bring-ext2-reservations-code-in-line-with-latest-ext3.patch
> > which gets stuck in a loop there for me too: back it out and all seems fine.
> >
> > It's not obvious which part of the patch is to blame: mostly it's
> > cleanup, but a few variables do change size: I'm currently narrowing
> > down to where a fix is needed.
>
> Humpf. that was meant to be one of those "so obvious I can't screw it
> up" patches.

Never underestimate yourself, Martin ;)

>
> typedef unsigned long ext2_fsblk_t;
> typedef int ext2_grpblk_t;
>
> in ext2_alloc_blocks we do change from "unsigned long long" to
> "unsigned long" for new_blocks[], but akpm thinks that was garbage
> before (same for ext2_alloc_branch's current_block)

Yes, I agree, those particular changes looked just fine,
and indeed they're not to blame.

>
> The ext2_grpblk_t ones all look innocuous.

Yes, those all looked like no-ops. The guilty party is ext2_new_blocks:
i386, x86_64 and ppc64 are now happily building on ext2s with this patch
below (I've been lazy, could have deleted your "E2FSBLK" addition too).

But I haven't attempted to correlate it with the loops seen (with OOMs
too on the x86_64, no idea why, but they've likewise melted away with
this patch). And I'm dubious whether it's the _right_ fix: the whole
mess of ints, unsigned longs and __u32s looks tricky to me, not some-
thing to sort out in a hurry - I'm only working with small filesystems
here (looped on a tmpfs file). (And if ret_block really should be an
ext2_fsblk_t there, shouldn't ext2_new_blocks return an ext2_fsblk_t
rather than an int?)

I see Andrew's sent me an alternative patch to try, I'll give that
a whirl now; and see if just making ext2_new_blocks return an
ext2_fsblk_t would do it too.

Hugh

--- 2.6.19-rc5-mm2/fs/ext2/balloc.c 2006-11-14 12:10:07.000000000 +0000
+++ linux/fs/ext2/balloc.c 2006-11-14 19:34:06.000000000 +0000
@@ -1155,7 +1155,7 @@ int ext2_new_blocks(struct inode *inode,
struct buffer_head *gdp_bh;
int group_no;
int goal_group;
- ext2_fsblk_t ret_block; /* filesyetem-wide allocated block */
+ int ret_block; /* filesystem-wide allocated block */
int bgi; /* blockgroup iteration index */
int target_block;
int performed_allocation = 0;
@@ -1320,7 +1320,7 @@ allocated:

if (ret_block + num - 1 >= le32_to_cpu(es->s_blocks_count)) {
ext2_error(sb, "ext2_new_blocks",
- "block("E2FSBLK") >= blocks count(%d) - "
+ "block(%d) >= blocks count(%d) - "
"block_group = %d, es == %p ", ret_block,
le32_to_cpu(es->s_blocks_count), group_no, es);
goto out;

2006-11-14 20:30:13

[permalink] [raw]

Subject: Re: Boot failure with ext2 and initrds

> Never underestimate yourself, Martin ;)

Thanks ;-)

> Yes, those all looked like no-ops. The guilty party is ext2_new_blocks:
> i386, x86_64 and ppc64 are now happily building on ext2s with this patch
> below (I've been lazy, could have deleted your "E2FSBLK" addition too).

Yup, we started throwing away the error return code ;-(

> But I haven't attempted to correlate it with the loops seen (with OOMs
> too on the x86_64, no idea why, but they've likewise melted away with
> this patch). And I'm dubious whether it's the _right_ fix: the whole
> mess of ints, unsigned longs and __u32s looks tricky to me, not some-
> thing to sort out in a hurry - I'm only working with small filesystems
> here (looped on a tmpfs file). (And if ret_block really should be an
> ext2_fsblk_t there, shouldn't ext2_new_blocks return an ext2_fsblk_t
> rather than an int?)

I was trying to harmonize it with what ext3 code does, but as Andrew
understands this code a thousand times better than I, hopefully it's
all fixed properly ;-)

> I see Andrew's sent me an alternative patch to try, I'll give that
> a whirl now; and see if just making ext2_new_blocks return an
> ext2_fsblk_t would do it too.

M.

2006-11-14 20:59:11

[permalink] [raw]

Subject: Re: 2.6.19-rc5-mm2

On Tue, Nov 14, 2006 at 10:30:53PM +0530, Gautham R Shenoy wrote:
> On Tue, Nov 14, 2006 at 10:31:40PM +1100, Reuben Farrelly wrote:
>
> Hi Reuben,
>
> > Oops:
> >
> > (davej cc'd - I think it's his specialty)
> >
>
> [snip]
>
> > ------------[ cut here ]------------
> > kernel BUG at drivers/cpufreq/cpufreq_userspace.c:138!
> > invalid opcode: 0000 [1] SMP
> > last sysfs file:
> > CPU 0
> > Modules linked in:
> > Pid: 1, comm: swapper Not tainted 2.6.19-rc5-mm2 #1
> > RIP: 0010:[<ffffffff80435299>] [<ffffffff80435299>]
> > cpufreq_governor_userspace+0x4e/0x1aa
> > RSP: 0000:ffff81003f61fb40 EFLAGS: 00010246
> > RAX: 0000000000000000 RBX: ffff81003ef4a0d8 RCX: 0000000000000003
> > RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff81003ef4a0d8
> > RBP: ffff81003f61fb60 R08: 0000000000000002 R09: 0000000000000001
> > R10: 0000000000000002 R11: 0000000000000001 R12: 0000000000000000
> > R13: 00000000ffffffea R14: 0000000000000000 R15: 0000000000000000
> > FS: 0000000000000000(0000) GS:ffffffff80652000(0000) knlGS:0000000000000000
> > CS: 0010 DS: 0018 ES: 0018 CR0: 000000008005003b
> > CR2: 0000000000000000 CR3: 0000000000201000 CR4: 00000000000006e0
> > Process swapper (pid: 1, threadinfo ffff81003f61e000, task ffff810037ff0040)
> > Stack: ffff81003f61fb60 ffff81003ef4a0d8 0000000000000001 ffff81003ef4a0d8
> > ffff81003f61fb90 ffffffff80433b11 ffffffff805d0e80 ffff81003f61fc20
> > 0000000000000000 ffff81003ef4a0d8 ffff81003f61fbc0 ffffffff80434278
> > Call Trace:
> > [<ffffffff80433b11>] __cpufreq_governor+0x51/0x9b
> > [<ffffffff80434278>] __cpufreq_set_policy+0xf8/0x13b
> > [<ffffffff804343e9>] cpufreq_set_policy+0x3c/0x93
> > [<ffffffff80435125>] cpufreq_add_dev+0x315/0x427
> > [<ffffffff803b6f87>] sysdev_driver_register+0x87/0xdb
> > [<ffffffff80434a8e>] cpufreq_register_driver+0x9e/0x120
> > [<ffffffff806837b2>] acpi_cpufreq_init+0xbe/0xc9
> > [<ffffffff802666c0>] init+0x160/0x31c
> > [<ffffffff8025deb8>] child_rip+0xa/0x12
> >
> >
>
> Hmmm.. The BUG indicates policy->cur i.e current frequency is 0.
>
> In this scenario, policy->cur variable was last set inside
> acpi_cpufreq_cpu_init when cpufreq_add_dev made a call to
> cpufreq_driver->init(policy).
>
> Are you able to reproduce this with 2.6.19-rc5-mm1?
>
> Because AFAICS, there ain't many changes w.r.t x86_64 acpi-cpufreq
> from 2.6.19-rc5-mm1 to 2.6.19-rc5-mm2.

maybe this helps? mostly guessing here, but when cpufreq_userspace is
the default governor we may hit this path and leave policy->cur
unset.

diff --git a/arch/i386/kernel/cpu/cpufreq/acpi-cpufreq.c b/arch/i386/kernel/cpu/cpufreq/acpi-cpufreq.c
index 18f4715..94e6e86 100644
--- a/arch/i386/kernel/cpu/cpufreq/acpi-cpufreq.c
+++ b/arch/i386/kernel/cpu/cpufreq/acpi-cpufreq.c
@@ -706,7 +706,7 @@ static int acpi_cpufreq_cpu_init(struct
break;
case ACPI_ADR_SPACE_FIXED_HARDWARE:
acpi_cpufreq_driver.get = get_cur_freq_on_cpu;
- get_cur_freq_on_cpu(cpu);
+ policy->cur = get_cur_freq_on_cpu(cpu);
break;
default:
break;

--
mattia
:wq!

2006-11-14 21:12:57

by Akinobu Mita

[permalink] [raw]

Subject: [PATCH -mm] CONFIG_FAULT_INJECTION help text

On Tue, Nov 14, 2006 at 09:02:49PM +0100, Adrian Bunk wrote:
> The FAULT_INJECTION option lacks a help text.

Thank you for pointing that out.

Subject: [PATCH -mm] CONFIG_FAULT_INJECTION help text

This patch add a help text for CONFIG_FAULT_INJECTION

Signed-off-by: Akinobu Mita <[email protected]>

lib/Kconfig.debug | 3 +++
1 file changed, 3 insertions(+)

Index: work-fault-inject/lib/Kconfig.debug
===================================================================
--- work-fault-inject.orig/lib/Kconfig.debug
+++ work-fault-inject/lib/Kconfig.debug
@@ -477,6 +477,9 @@ config FAULT_INJECTION
depends on DEBUG_KERNEL
depends on STACKTRACE
select FRAME_POINTER
+ help
+ Provide fault-injection framework.
+ For more details, see Documentation/fault-injection/.

config FAILSLAB
bool "Fault-injection capability for kmalloc"

2006-11-14 21:15:13

by Akinobu Mita

[permalink] [raw]

Subject: [PATCH -mm] failslab: remove __GFP_HIGHMEM filtering

Filtering __GFP_HIGHMEM flag for slab allocations is useless.
Because no one sets __GFP_HIGHMEM for slab allocator, unlike
for page allocator.

Signed-off-by: Akinobu Mita <[email protected]>

Documentation/fault-injection/fault-injection.txt | 2 --
mm/slab.c | 17 ++---------------
2 files changed, 2 insertions(+), 17 deletions(-)

Index: work-fault-inject/mm/slab.c
===================================================================
--- work-fault-inject.orig/mm/slab.c
+++ work-fault-inject/mm/slab.c
@@ -3105,15 +3105,10 @@ static struct failslab_attr {

struct fault_attr attr;

- u32 ignore_gfp_highmem;
u32 ignore_gfp_wait;
-
#ifdef CONFIG_FAULT_INJECTION_DEBUG_FS
-
- struct dentry *ignore_gfp_highmem_file;
struct dentry *ignore_gfp_wait_file;
-
-#endif /* CONFIG_FAULT_INJECTION_DEBUG_FS */
+#endif

} failslab = {
.attr = FAULT_ATTR_INITIALIZER,
@@ -3131,8 +3126,6 @@ static int should_failslab(struct kmem_c
return 0;
if (flags & __GFP_NOFAIL)
return 0;
- if (failslab.ignore_gfp_highmem && (flags & __GFP_HIGHMEM))
- return 0;
if (failslab.ignore_gfp_wait && (flags & __GFP_WAIT))
return 0;

@@ -3156,15 +3149,9 @@ static int __init failslab_debugfs(void)
debugfs_create_bool("ignore-gfp-wait", mode, dir,
&failslab.ignore_gfp_wait);

- failslab.ignore_gfp_highmem_file =
- debugfs_create_bool("ignore-gfp-highmem", mode, dir,
- &failslab.ignore_gfp_highmem);
-
- if (!failslab.ignore_gfp_wait_file ||
- !failslab.ignore_gfp_highmem_file) {
+ if (!failslab.ignore_gfp_wait_file) {
err = -ENOMEM;
debugfs_remove(failslab.ignore_gfp_wait_file);
- debugfs_remove(failslab.ignore_gfp_highmem_file);
cleanup_fault_attr_dentries(&failslab.attr);
}

Index: work-fault-inject/Documentation/fault-injection/fault-injection.txt
===================================================================
--- work-fault-inject.orig/Documentation/fault-injection/fault-injection.txt
+++ work-fault-inject/Documentation/fault-injection/fault-injection.txt
@@ -86,7 +86,6 @@ configuration of fault-injection capabil
specifies the maximum stacktrace depth walked during search
for a caller within [address-start,address-end).

-- /debug/failslab/ignore-gfp-highmem:
- /debug/fail_page_alloc/ignore-gfp-highmem:

Format: { 0 | 1 }
@@ -167,7 +166,6 @@ echo 10 > /debug/$FAILNAME/probability
echo 100 > /debug/$FAILNAME/interval
echo -1 > /debug/$FAILNAME/times
echo 2 > /debug/$FAILNAME/verbose
-echo 1 > /debug/$FAILNAME/ignore-gfp-highmem
echo 1 > /debug/$FAILNAME/ignore-gfp-wait

blacklist()

2006-11-14 21:17:48

[permalink] [raw]

Subject: Re: Boot failure with ext2 and initrds

On Tue, 14 Nov 2006, Andrew Morton wrote:
>
> The below might help.

Indeed it does (with Martin's E2FSBLK warning fix),
seems to be running well on all machines now.

(Of course, my ext2_fsblk_t ext2_new_blocks() notion did not pan out,
for same reason as the original: that ret_block was expected signed.)

Thanks,
Hugh

2006-11-14 21:20:24

by Mel Gorman

[permalink] [raw]

Subject: Re: Boot failure with ext2 and initrds

On Tue, 14 Nov 2006, Andrew Morton wrote:

> On Tue, 14 Nov 2006 19:11:22 +0000 (GMT)
> Hugh Dickins <[email protected]> wrote:
>
>> On Tue, 14 Nov 2006, Mel Gorman wrote:
>>> 2.6.19-rc5-mm2
>>>
>>> Am seeing errors with systems using ext2. First machine is a plan old x86
>>> using initramfs. Console output looks like;
>>> ...
>>> Configuring network interfaces...BUG: soft lockup detected on CPU#3!
>>> ...
>>> [<c01b3b80>] ext2_try_to_allocate+0xdb/0x152
>>> [<c01b3e72>] ext2_try_to_allocate_with_rsv+0x4b/0x1b2
>>>
>>> I've not investigated yet what patches might be at fault.
>>
>> I expect you'll find it's
>> ext2-reservations-bring-ext2-reservations-code-in-line-with-latest-ext3.patch
>> which gets stuck in a loop there for me too: back it out and all seems fine.
>>
>> It's not obvious which part of the patch is to blame: mostly it's
>> cleanup, but a few variables do change size: I'm currently narrowing
>> down to where a fix is needed.
>>
>
> Doing s/-Wall/-W/ tends to shake out bugs in this stuff.
>
> The below might help.
>

It worked for me on the two problem machines. Thanks

2006-11-14 21:19:58

[permalink] [raw]

Subject: Re: Boot failure with ext2 and initrds

Hugh Dickins wrote:
> On Tue, 14 Nov 2006, Andrew Morton wrote:
>> The below might help.
>
> Indeed it does (with Martin's E2FSBLK warning fix),
> seems to be running well on all machines now.
>
> (Of course, my ext2_fsblk_t ext2_new_blocks() notion did not pan out,
> for same reason as the original: that ret_block was expected signed.)

Whilst I've got all the smart people looking at this ...

/*max window size: 1024(direct blocks) + 3([t,d]indirect blocks) */
#define EXT2_MAX_RESERVE_BLOCKS 1027

Is that wrong? If it's meaning one triple, one double, and one single
indirect block, surely it can span a boundary, so we need (potentially)
two of each?

M.

2006-11-14 22:56:20

[permalink] [raw]

Subject: 2.6.19-rc5-mm2: warnings in MODPOST and later

Since people were recently complaining about too many warnings:
Here is a list of the warnings I'm getting in MODPOST and later.

Since the warnings by far exceed the 100kB limit of linux-kernel (sic),
I had to attach them compressed.

With the exception of the "drivers/ide/pci/atiixp:FFFF05", none of these
warnings is present in Linus' tree.

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

Attachments:

(No filename) (605.00 B)
warnings-mm.bz2 (45.12 kB)
Download all attachments

2006-11-14 22:56:44

[permalink] [raw]

Subject: [-mm patch] fix the DLM dependencies, part 2

On Tue, Nov 14, 2006 at 07:33:24PM +0100, Adrian Bunk wrote:
> On Tue, Nov 14, 2006 at 01:41:25AM -0800, Andrew Morton wrote:
> >...
> > - A nasty Kconfig warning comes out during the build. It's due to
> > git-gfs2-nmw.patch.
> >...
>
> So let's fix it. ;-)
>...

And let's also fix another bug...

<-- snip -->

IPV6=m, DLM=m, DLM_SCTP=y mustn't result in IP_SCTP=y.

Signed-off-by: Adrian Bunk <[email protected]>

--- linux-2.6.19-rc5-mm2/fs/dlm/Kconfig.old 2006-11-14 22:25:01.000000000 +0100
+++ linux-2.6.19-rc5-mm2/fs/dlm/Kconfig 2006-11-14 22:25:19.000000000 +0100
@@ -5,6 +5,7 @@ config DLM
tristate "Distributed Lock Manager (DLM)"
depends on IPV6 || IPV6=n
select CONFIGFS_FS
+ select IP_SCTP if DLM_SCTP
help
A general purpose distributed lock manager for kernel or userspace
applications.
@@ -23,7 +24,6 @@ config DLM_TCP

config DLM_SCTP
bool "SCTP"
- select IP_SCTP

endchoice

2006-11-14 23:12:28

[permalink] [raw]

Subject: Re: 2.6.19-rc5-mm2: warnings in MODPOST and later

On Tue, 14 Nov 2006 23:56:22 +0100
Adrian Bunk <[email protected]> wrote:

> Since people were recently complaining about too many warnings:
> Here is a list of the warnings I'm getting in MODPOST and later.
>
> Since the warnings by far exceed the 100kB limit of linux-kernel (sic),
> I had to attach them compressed.
>
> With the exception of the "drivers/ide/pci/atiixp:FFFF05", none of these
> warnings is present in Linus' tree.

yes, lots of new section mismatch warnings.

A large number of them are due to the paravirt patches:

WARNING: vmlinux - Section mismatch: reference to .init.text: from .parainstructions between '__start_parainstructions' (at offset 0xc0458470) and '__stop_parainstructions'
WARNING: vmlinux - Section mismatch: reference to .init.text: from .parainstructions between '__start_parainstructions' (at offset 0xc0458478) and '__stop_parainstructions'
WARNING: vmlinux - Section mismatch: reference to .init.text: from .parainstructions between '__start_parainstructions' (at offset 0xc0458480) and '__stop_parainstructions'
WARNING: vmlinux - Section mismatch: reference to .init.text: from .parainstructions between '__start_parainstructions' (at offset 0xc0458488) and '__stop_parainstructions'
WARNING: vmlinux - Section mismatch: reference to .init.text: from .parainstructions between '__start_parainstructions' (at offset 0xc0458490) and '__stop_parainstructions'
WARNING: vmlinux - Section mismatch: reference to .init.text: from .parainstructions between '__start_parainstructions' (at offset 0xc0458498) and '__stop_parainstructions'
WARNING: vmlinux - Section mismatch: reference to .init.text: from .parainstructions between '__start_parainstructions' (at offset 0xc04584a0) and '__stop_parainstructions'
WARNING: Can't handle masks in drivers/ata/ahci:FFFF05
WARNING: drivers/ata/pata_legacy.o - Section mismatch: reference to .init.text: from .parainstructions after '' (at offset 0x18)
WARNING: drivers/ata/pata_legacy.o - Section mismatch: reference to .init.text: from .parainstructions after '' (at offset 0x20)
WARNING: drivers/ata/pata_legacy.o - Section mismatch: reference to .init.text: from .parainstructions after '' (at offset 0x28)
WARNING: drivers/ata/pata_qdi.o - Section mismatch: reference to .init.text: from .parainstructions after '' (at offset 0x0)
WARNING: drivers/ata/pata_qdi.o - Section mismatch: reference to .init.text: from .parainstructions after '' (at offset 0x8)

but there are others too.

2006-11-14 23:14:05

by Sergio Monteiro Basto

[permalink] [raw]

Subject: and in www.kernel.org page? Re: 2.6.19-rc5-mm2

Hi,
What happens with http://www.kernel.org don't get update ?

I don't see 2.6.19-rc5-mm2 neither patch-2.6.19-rc5-git4.gz on
http://www.kernel.org

On Tue, 2006-11-14 at 01:41 -0800, Andrew Morton wrote:
> and will appear later at
>
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.19-rc5/2.6.19-rc5-mm2/
>
>
--
S?rgio M.B.

Attachments:

smime.p7s (2.12 kB)

2006-11-15 00:26:17

by Andy Whitcroft

[permalink] [raw]

Subject: Re: Boot failure with ext2 and initrds

Seeing this too. Will try this patch out on the affected machines.

If there are any others you recommend with it. Yell.

-apw

2006-11-15 00:58:17

[permalink] [raw]

Subject: Re: Boot failure with ext2 and initrds

On Wed, 15 Nov 2006 00:25:55 +0000
Andy Whitcroft <[email protected]> wrote:

> Seeing this too. Will try this patch out on the affected machines.
>
> If there are any others you recommend with it. Yell.
>

There are three, but kernel.org mirroring is taking *hours*, so I stuck
them in http://userweb.kernel.org/~akpm/hot-fixes/

2006-11-15 07:42:14

[permalink] [raw]

Subject: Re: 2.6.19-rc5-mm2: warnings in MODPOST and later

On Tue, 2006-11-14 at 15:09 -0800, Andrew Morton wrote:
> On Tue, 14 Nov 2006 23:56:22 +0100
> Adrian Bunk <[email protected]> wrote:
>
> > Since people were recently complaining about too many warnings:
> > Here is a list of the warnings I'm getting in MODPOST and later.
> >
> > Since the warnings by far exceed the 100kB limit of linux-kernel (sic),
> > I had to attach them compressed.
> >
> > With the exception of the "drivers/ide/pci/atiixp:FFFF05", none of these
> > warnings is present in Linus' tree.
>
> yes, lots of new section mismatch warnings.
>
> A large number of them are due to the paravirt patches:
>
> WARNING: vmlinux - Section mismatch: reference to .init.text: from .parainstructions between '__start_parainstructions' (at offset 0xc0458470) and '__stop_parainstructions'
> WARNING: vmlinux - Section mismatch: reference to .init.text: from .parainstructions between '__start_parainstructions' (at offset 0xc0458478) and '__stop_parainstructions'

ok this means that you shouldn't probably switch paravirtualizations
after boot, but that's ok ;) it's not like hypervisor support should be
a module anyway

2006-11-15 10:12:57

by Patrick Caulfield

[permalink] [raw]

Subject: Re: [-mm patch] fix the DLM dependencies, part 2

Adrian Bunk wrote:
> On Tue, Nov 14, 2006 at 07:33:24PM +0100, Adrian Bunk wrote:
>> On Tue, Nov 14, 2006 at 01:41:25AM -0800, Andrew Morton wrote:
>>> ...
>>> - A nasty Kconfig warning comes out during the build. It's due to
>>> git-gfs2-nmw.patch.
>>> ...
>> So let's fix it. ;-)
>> ...
>
> And let's also fix another bug...
>
>
> <-- snip -->
>
>
> IPV6=m, DLM=m, DLM_SCTP=y mustn't result in IP_SCTP=y.
>
> Signed-off-by: Adrian Bunk <[email protected]>
>
> --- linux-2.6.19-rc5-mm2/fs/dlm/Kconfig.old 2006-11-14 22:25:01.000000000 +0100
> +++ linux-2.6.19-rc5-mm2/fs/dlm/Kconfig 2006-11-14 22:25:19.000000000 +0100
> @@ -5,6 +5,7 @@ config DLM
> tristate "Distributed Lock Manager (DLM)"
> depends on IPV6 || IPV6=n
> select CONFIGFS_FS
> + select IP_SCTP if DLM_SCTP
> help
> A general purpose distributed lock manager for kernel or userspace
> applications.
> @@ -23,7 +24,6 @@ config DLM_TCP
>
> config DLM_SCTP
> bool "SCTP"
> - select IP_SCTP
>
> endchoice

Thanks Adrian. I need to read the kconfig docs a little more closely :)

Incidentally, I think the 'depends on IPV6 || IPV6=n' can go too; it's in a patch I sent to Steve and it's basically just a line
copied from SCTP which is obsoleted by these other changes and the addition of the TCP transport.

--

patrick

2006-11-15 10:23:46

by tip-bot for Gautham R Shenoy

[permalink] [raw]

Subject: Re: [-mm patch] fix the DLM dependencies, part 2

On Wed, Nov 15, 2006 at 10:11:35AM +0000, Patrick Caulfield wrote:
> Adrian Bunk wrote:
> > On Tue, Nov 14, 2006 at 07:33:24PM +0100, Adrian Bunk wrote:
> >> On Tue, Nov 14, 2006 at 01:41:25AM -0800, Andrew Morton wrote:
> >>> ...
> >>> - A nasty Kconfig warning comes out during the build. It's due to
> >>> git-gfs2-nmw.patch.
> >>> ...
> >> So let's fix it. ;-)
> >> ...
> >
> > And let's also fix another bug...
> >
> >
> > <-- snip -->
> >
> >
> > IPV6=m, DLM=m, DLM_SCTP=y mustn't result in IP_SCTP=y.
> >
> > Signed-off-by: Adrian Bunk <[email protected]>
> >
> > --- linux-2.6.19-rc5-mm2/fs/dlm/Kconfig.old 2006-11-14 22:25:01.000000000 +0100
> > +++ linux-2.6.19-rc5-mm2/fs/dlm/Kconfig 2006-11-14 22:25:19.000000000 +0100
> > @@ -5,6 +5,7 @@ config DLM
> > tristate "Distributed Lock Manager (DLM)"
> > depends on IPV6 || IPV6=n
> > select CONFIGFS_FS
> > + select IP_SCTP if DLM_SCTP
> > help
> > A general purpose distributed lock manager for kernel or userspace
> > applications.
> > @@ -23,7 +24,6 @@ config DLM_TCP
> >
> > config DLM_SCTP
> > bool "SCTP"
> > - select IP_SCTP
> >
> > endchoice
>
> Thanks Adrian. I need to read the kconfig docs a little more closely :)
>
> Incidentally, I think the 'depends on IPV6 || IPV6=n' can go too; it's in a patch I sent to Steve and it's basically just a line
> copied from SCTP which is obsoleted by these other changes and the addition of the TCP transport.

As long as you select IP_SCTP, the "depends on IPV6 || IPV6=n" can't go:
Otherwise, the illegal configuration DLM=y, IP_SCTP=y, IPV6=m would
become possible.

> patrick

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

2006-11-15 10:35:49

[permalink] [raw]

Subject: Re: 2.6.19-rc5-mm2

Hi,

On Tue, Nov 14, 2006 at 09:58:29PM +0100, Mattia Dongili wrote:
>
> maybe this helps? mostly guessing here, but when cpufreq_userspace is
> the default governor we may hit this path and leave policy->cur
> unset.

I doubt if that's causing the problem. My reasons are:

- Reuben's config shows his system to be a x64_64. So if I am not
mistaken, the correct file look for would be
arch/ia64/kernel/cpufreq/acpi-cpufreq.c.

- The fix provided by you deals with the state of a
driver(hardware) specific variable data->cpu_feature while the
governors like userspace/performance/powersave/ondemand are
driver(hardware) independent.

Nevertheless, it could be a valid fix for i386 acpi_cpufreq considering
that policy->cur is not being initialized if
data->cpu_feature == ACPI_ADR_SPACE_FIXED_HARDWARE.

Please check with Dave Jones or Venkatesh Pallipadi.

Thanks
gautham.

>
> diff --git a/arch/i386/kernel/cpu/cpufreq/acpi-cpufreq.c b/arch/i386/kernel/cpu/cpufreq/acpi-cpufreq.c
> index 18f4715..94e6e86 100644
> --- a/arch/i386/kernel/cpu/cpufreq/acpi-cpufreq.c
> +++ b/arch/i386/kernel/cpu/cpufreq/acpi-cpufreq.c
> @@ -706,7 +706,7 @@ static int acpi_cpufreq_cpu_init(struct
> break;
> case ACPI_ADR_SPACE_FIXED_HARDWARE:
> acpi_cpufreq_driver.get = get_cur_freq_on_cpu;
> - get_cur_freq_on_cpu(cpu);
> + policy->cur = get_cur_freq_on_cpu(cpu);
> break;
> default:
> break;
>
> --
> mattia
> :wq!
> -
> 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/
>

--
Gautham R Shenoy
Linux Technology Center
IBM India.
"Freedom comes with a price tag of responsibility, which is still a bargain,
because Freedom is priceless!"

2006-11-15 10:42:19

by Reuben Farrelly

[permalink] [raw]

Subject: Re: 2.6.19-rc5-mm2

Hi,

On 15/11/2006 9:34 PM, Gautham R Shenoy wrote:
> Hi,
>
> On Tue, Nov 14, 2006 at 09:58:29PM +0100, Mattia Dongili wrote:
>> maybe this helps? mostly guessing here, but when cpufreq_userspace is
>> the default governor we may hit this path and leave policy->cur
>> unset.
>
> I doubt if that's causing the problem. My reasons are:

Yes. I just tried with the one-liner from Mattia as below, and unfortunately it
made no difference. The crash was the same..

Unfortunately I didn't get to test out 2.6.19-rc5-mm1 as there was some issue
with it unable to mount my ext3/raid-1 root (fixed in -rc5-mm2), that I didn't
have time to get to the bottom of.

So there is a chance that this cpufreq problem is not new to -rc5-mm2.

Reuben

> - Reuben's config shows his system to be a x64_64. So if I am not
> mistaken, the correct file look for would be
> arch/ia64/kernel/cpufreq/acpi-cpufreq.c.
>
> - The fix provided by you deals with the state of a
> driver(hardware) specific variable data->cpu_feature while the
> governors like userspace/performance/powersave/ondemand are
> driver(hardware) independent.
>
> Nevertheless, it could be a valid fix for i386 acpi_cpufreq considering
> that policy->cur is not being initialized if
> data->cpu_feature == ACPI_ADR_SPACE_FIXED_HARDWARE.
>
> Please check with Dave Jones or Venkatesh Pallipadi.
>
> Thanks
> gautham.
>
>> diff --git a/arch/i386/kernel/cpu/cpufreq/acpi-cpufreq.c b/arch/i386/kernel/cpu/cpufreq/acpi-cpufreq.c
>> index 18f4715..94e6e86 100644
>> --- a/arch/i386/kernel/cpu/cpufreq/acpi-cpufreq.c
>> +++ b/arch/i386/kernel/cpu/cpufreq/acpi-cpufreq.c
>> @@ -706,7 +706,7 @@ static int acpi_cpufreq_cpu_init(struct
>> break;
>> case ACPI_ADR_SPACE_FIXED_HARDWARE:
>> acpi_cpufreq_driver.get = get_cur_freq_on_cpu;
>> - get_cur_freq_on_cpu(cpu);
>> + policy->cur = get_cur_freq_on_cpu(cpu);
>> break;
>> default:
>> break;
>>
>> --
>> mattia

2006-11-15 14:09:52

by Pallipadi, Venkatesh

[permalink] [raw]

Subject: RE: 2.6.19-rc5-mm2

>-----Original Message-----
>From: Gautham R Shenoy [mailto:[email protected]]
>Sent: Wednesday, November 15, 2006 2:34 AM
>To: Gautham R Shenoy; Reuben Farrelly; Andrew Morton;
>[email protected]; [email protected]; Pallipadi,
>Venkatesh; CPUFreq Mailing List
>Subject: Re: 2.6.19-rc5-mm2
>
>Hi,
>
>On Tue, Nov 14, 2006 at 09:58:29PM +0100, Mattia Dongili wrote:
>>
>> maybe this helps? mostly guessing here, but when cpufreq_userspace is
>> the default governor we may hit this path and leave policy->cur
>> unset.
>
>I doubt if that's causing the problem. My reasons are:
>
>- Reuben's config shows his system to be a x64_64. So if I am not
> mistaken, the correct file look for would be
> arch/ia64/kernel/cpufreq/acpi-cpufreq.c.

ia64 and x86_64 are different!
X86_64 shares acpi-cpufreq.c in arch/i386/kernel/cpu/cpufreq. So, that
is the file that can be causing problems here.

>- The fix provided by you deals with the state of a
> driver(hardware) specific variable data->cpu_feature while the
> governors like userspace/performance/powersave/ondemand are
> driver(hardware) independent.
>
>Nevertheless, it could be a valid fix for i386 acpi_cpufreq considering
>that policy->cur is not being initialized if
>data->cpu_feature == ACPI_ADR_SPACE_FIXED_HARDWARE.

Yes. Patch from Mattia is indeed required for acpi-cpufreq.
Mattia: Can you please send the patch towards Andrew (With signed off
etc) for inclusion.

Reuben: Can you please enable CPU_FREQ_DEBUG in your config and boot
with "cpufreq.debug=7" boot parameter and send me the log. That will
give some more debug information that should help to root cause this
faster.

Thanks,
Venki

2006-11-15 14:16:44

[permalink] [raw]

Subject: Re: Boot failure with ext2 and initrds

On Tue, 14 Nov 2006, Hugh Dickins wrote:
> On Tue, 14 Nov 2006, Andrew Morton wrote:
> >
> > The below might help.
>
> Indeed it does (with Martin's E2FSBLK warning fix),
> seems to be running well on all machines now.

i386 and ppc64 still doing builds, but after an hour on x86_64,
an ld got stuck in a loop under ext2_try_to_allocate_with_rsv,
alternating between ext2_rsv_window_add and rsv_window_remove.
Send me a patch and I'll try it...

ext2_try_to_allocate_with_rsv+0x288
ext2_new_blocks+0x21e
ext2_get_blocks+0x398
ext2_get_block+0x46
__block_prepare_write+0x171
block_prepare_write+0x39
ext2_prepare_write+0x2c
generic_file_buffered_write+0x2b0
__generic_file_aio_write_nolock+0x4bc
generic_file_aio_write+0x6d
do_sync_write+0xf9
vfs_write+0xc8
sys_write+0x51

2006-11-15 15:34:32

[permalink] [raw]

Subject: Re: Boot failure with ext2 and initrds

Hugh Dickins wrote:
> On Tue, 14 Nov 2006, Hugh Dickins wrote:
>> On Tue, 14 Nov 2006, Andrew Morton wrote:
>>> The below might help.
>> Indeed it does (with Martin's E2FSBLK warning fix),
>> seems to be running well on all machines now.
>
> i386 and ppc64 still doing builds, but after an hour on x86_64,
> an ld got stuck in a loop under ext2_try_to_allocate_with_rsv,
> alternating between ext2_rsv_window_add and rsv_window_remove.

Ugh. What test are you doing? kernel compile in a tight loop forever?

Andrew, do you want to drop the set for now, and we can try and
debug it outside of -mm? No reason to break your tree if we don't
have to ...

> Send me a patch and I'll try it...
>
> ext2_try_to_allocate_with_rsv+0x288
> ext2_new_blocks+0x21e
> ext2_get_blocks+0x398
> ext2_get_block+0x46
> __block_prepare_write+0x171
> block_prepare_write+0x39
> ext2_prepare_write+0x2c
> generic_file_buffered_write+0x2b0
> __generic_file_aio_write_nolock+0x4bc
> generic_file_aio_write+0x6d
> do_sync_write+0xf9
> vfs_write+0xc8
> sys_write+0x51

2006-11-15 15:56:41

[permalink] [raw]

Subject: Re: Boot failure with ext2 and initrds

On Wed, 15 Nov 2006, Martin J. Bligh wrote:
> Hugh Dickins wrote:
> >
> > i386 and ppc64 still doing builds, but after an hour on x86_64,
> > an ld got stuck in a loop under ext2_try_to_allocate_with_rsv,
> > alternating between ext2_rsv_window_add and rsv_window_remove.
>
> Ugh. What test are you doing? kernel compile in a tight loop forever?

That kind of thing, yes: my usual test, two repeated make -j20s of
a smallish kernel in 512MB RAM + 1or2GB swap, one in a tmpfs and
one in an ext2 backed by a looped tmpfs file. (When things go
badly wrong, little harm befalls the hard disk.)

Hugh

2006-11-15 17:47:39

[permalink] [raw]

Subject: Re: 2.6.19-rc5-mm2

On Wed, Nov 15, 2006 at 06:09:47AM -0800, Pallipadi, Venkatesh wrote:
[...]
> >data->cpu_feature == ACPI_ADR_SPACE_FIXED_HARDWARE.
>
> Yes. Patch from Mattia is indeed required for acpi-cpufreq.
> Mattia: Can you please send the patch towards Andrew (With signed off
> etc) for inclusion.

Venki, I'm a little worried about the switch/case in question (line
702): the data->cpu_feature is set either to SYSTEM_IO_CAPABLE or
SYSTEM_INTEL_MSR_CAPABLE just a few lines above so it seems the switch
variable is wrong and none of the 2 cases will ever get a chance to
execute.

Unfortunately I don't have enough knowledge to tell if it's simply
necessary to fix the switch variable as

- switch (data->cpu_feature) {
+ switch (perf->control_register.space_id) {
case ACPI_ADR_SPACE_SYSTEM_IO:

or if change it more dramatically like:

diff --git a/arch/i386/kernel/cpu/cpufreq/acpi-cpufreq.c b/arch/i386/kernel/cpu/cpufreq/acpi-cpufreq.c
index 18f4715..428ac5b 100644
--- a/arch/i386/kernel/cpu/cpufreq/acpi-cpufreq.c
+++ b/arch/i386/kernel/cpu/cpufreq/acpi-cpufreq.c
@@ -699,18 +699,8 @@ static int acpi_cpufreq_cpu_init(struct
if (result)
goto err_freqfree;

- switch (data->cpu_feature) {
- case ACPI_ADR_SPACE_SYSTEM_IO:
- /* Current speed is unknown and not detectable by IO port */
- policy->cur = acpi_cpufreq_guess_freq(data, policy->cpu);
- break;
- case ACPI_ADR_SPACE_FIXED_HARDWARE:
- acpi_cpufreq_driver.get = get_cur_freq_on_cpu;
- get_cur_freq_on_cpu(cpu);
- break;
- default:
- break;
- }
+ acpi_cpufreq_driver.get = get_cur_freq_on_cpu;
+ policy->cur = get_cur_freq_on_cpu(cpu);

/* notify BIOS that we exist */
acpi_processor_notify_smm(THIS_MODULE);

Thoughts?
--
mattia
:wq!

2006-11-15 18:06:33

by Pallipadi, Venkatesh

[permalink] [raw]

Subject: RE: 2.6.19-rc5-mm2

>-----Original Message-----
>From: Mattia Dongili [mailto:[email protected]]
>Sent: Wednesday, November 15, 2006 9:47 AM
>To: Pallipadi, Venkatesh
>Cc: [email protected]; Reuben Farrelly; Andrew Morton;
>[email protected]; [email protected]; CPUFreq
>Mailing List; Sadykov, Denis M
>Subject: Re: 2.6.19-rc5-mm2
>
>On Wed, Nov 15, 2006 at 06:09:47AM -0800, Pallipadi, Venkatesh wrote:
>[...]
>> >data->cpu_feature == ACPI_ADR_SPACE_FIXED_HARDWARE.
>>
>> Yes. Patch from Mattia is indeed required for acpi-cpufreq.
>> Mattia: Can you please send the patch towards Andrew (With signed off
>> etc) for inclusion.
>
>Venki, I'm a little worried about the switch/case in question (line
>702): the data->cpu_feature is set either to SYSTEM_IO_CAPABLE or
>SYSTEM_INTEL_MSR_CAPABLE just a few lines above so it seems the switch
>variable is wrong and none of the 2 cases will ever get a chance to
>execute.
>

The variable is set few lines before. So, it should be OK to switch on
that
variable set and one of the two cases will execute. isn't it? Or am
I missing something?

>Unfortunately I don't have enough knowledge to tell if it's simply
>necessary to fix the switch variable as

Get_cur_freq_on_cpu will not work on SYSTEM_IO space as ACPI does not
have an interface to get the current frequency. It only has a interface
to say whether the last transitions tried was successful or not.
So, if indeed a change in switch is required, first option should be
good...

Thanks,
Venki

2006-11-15 18:36:39

[permalink] [raw]

Subject: Re: 2.6.19-rc5-mm2

On Wed, Nov 15, 2006 at 10:06:23AM -0800, Pallipadi, Venkatesh wrote:
[...]
> >Venki, I'm a little worried about the switch/case in question (line
> >702): the data->cpu_feature is set either to SYSTEM_IO_CAPABLE or
> >SYSTEM_INTEL_MSR_CAPABLE just a few lines above so it seems the switch
> >variable is wrong and none of the 2 cases will ever get a chance to
> >execute.
> >
>
> The variable is set few lines before. So, it should be OK to switch on
> that
> variable set and one of the two cases will execute. isn't it? Or am
> I missing something?

Yes, patch is coming.

> >Unfortunately I don't have enough knowledge to tell if it's simply
> >necessary to fix the switch variable as
>
> Get_cur_freq_on_cpu will not work on SYSTEM_IO space as ACPI does not
> have an interface to get the current frequency. It only has a interface
> to say whether the last transitions tried was successful or not.
> So, if indeed a change in switch is required, first option should be
> good...

Hmmmm... I see, the following path fooled me, but re-reading it seems
more obvious what it is doing :)

get_cur_freq_on_cpu
extract_freq
switch (data->cpu_feature) {
case SYSTEM_INTEL_MSR_CAPABLE:
return extract_msr(val, data);
case SYSTEM_IO_CAPABLE:
return extract_io(val, data);
...

--
mattia
:wq!

2006-11-15 19:09:00

[permalink] [raw]

Subject: [PATCH 2.6.19-rc5-mm2] cpufreq: set policy->curfreq on initialization

Check the correct variable and set policy->cur upon acpi-cpufreq
initialization to allow the userspace governor to be used as default.

Signed-off-by: Mattia Dongili <[email protected]>

---

Reuben, could you also try if this patch fixes the BUG()?
Thanks

diff --git a/arch/i386/kernel/cpu/cpufreq/acpi-cpufreq.c b/arch/i386/kernel/cpu/cpufreq/acpi-cpufreq.c
index 18f4715..a630f94 100644
--- a/arch/i386/kernel/cpu/cpufreq/acpi-cpufreq.c
+++ b/arch/i386/kernel/cpu/cpufreq/acpi-cpufreq.c
@@ -699,14 +699,14 @@ static int acpi_cpufreq_cpu_init(struct
if (result)
goto err_freqfree;

- switch (data->cpu_feature) {
+ switch (perf->control_register.space_id) {
case ACPI_ADR_SPACE_SYSTEM_IO:
/* Current speed is unknown and not detectable by IO port */
policy->cur = acpi_cpufreq_guess_freq(data, policy->cpu);
break;
case ACPI_ADR_SPACE_FIXED_HARDWARE:
acpi_cpufreq_driver.get = get_cur_freq_on_cpu;
- get_cur_freq_on_cpu(cpu);
+ policy->cur = get_cur_freq_on_cpu(cpu);
break;
default:
break;

2006-11-15 23:16:29

[permalink] [raw]

Subject: 2.6.19-rc5-mm2: paravirt X86_PAE=y compile error

Paravirt breaks CONFIG_X86_PAE=y compilation:

<-- snip -->

...
CC init/main.o
In file included from include2/asm/pgtable.h:245,
from
/home/bunk/linux/kernel-2.6/linux-2.6.19-rc5-mm2/include/linux/mm.h:40,
from
/home/bunk/linux/kernel-2.6/linux-2.6.19-rc5-mm2/include/linux/poll.h:11,
from
/home/bunk/linux/kernel-2.6/linux-2.6.19-rc5-mm2/include/linux/rtc.h:113,
from
/home/bunk/linux/kernel-2.6/linux-2.6.19-rc5-mm2/include/linux/efi.h:19,
from
/home/bunk/linux/kernel-2.6/linux-2.6.19-rc5-mm2/init/main.c:43:
include2/asm/pgtable-3level.h:108: error: redefinition of 'pte_clear'
include2/asm/paravirt.h:365: error: previous definition of 'pte_clear' was here
include2/asm/pgtable-3level.h:115: error: redefinition of 'pmd_clear'
include2/asm/paravirt.h:370: error: previous definition of 'pmd_clear' was here
make[2]: *** [init/main.o] Error 1

<-- snip -->

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

2006-11-15 23:39:40

[permalink] [raw]

Subject: Re: 2.6.19-rc5-mm2: paravirt X86_PAE=y compile error

On Thu, 16 Nov 2006 00:16:26 +0100
Adrian Bunk <[email protected]> wrote:

> Paravirt breaks CONFIG_X86_PAE=y compilation:
>
> <-- snip -->
>
> ...
> CC init/main.o
> In file included from include2/asm/pgtable.h:245,
> from
> /home/bunk/linux/kernel-2.6/linux-2.6.19-rc5-mm2/include/linux/mm.h:40,
> from
> /home/bunk/linux/kernel-2.6/linux-2.6.19-rc5-mm2/include/linux/poll.h:11,
> from
> /home/bunk/linux/kernel-2.6/linux-2.6.19-rc5-mm2/include/linux/rtc.h:113,
> from
> /home/bunk/linux/kernel-2.6/linux-2.6.19-rc5-mm2/include/linux/efi.h:19,
> from
> /home/bunk/linux/kernel-2.6/linux-2.6.19-rc5-mm2/init/main.c:43:
> include2/asm/pgtable-3level.h:108: error: redefinition of 'pte_clear'
> include2/asm/paravirt.h:365: error: previous definition of 'pte_clear' was here
> include2/asm/pgtable-3level.h:115: error: redefinition of 'pmd_clear'
> include2/asm/paravirt.h:370: error: previous definition of 'pmd_clear' was here
> make[2]: *** [init/main.o] Error 1
>

So it does. Zach will save us.

How come allmodconfig doesn't select highmem?

2006-11-15 23:55:04

by Andy Whitcroft

[permalink] [raw]

Subject: Re: Boot failure with ext2 and initrds

Andrew Morton wrote:
> On Wed, 15 Nov 2006 00:25:55 +0000
> Andy Whitcroft <[email protected]> wrote:
>
>> Seeing this too. Will try this patch out on the affected machines.
>>
>> If there are any others you recommend with it. Yell.
>>
>
> There are three, but kernel.org mirroring is taking *hours*, so I stuck
> them in http://userweb.kernel.org/~akpm/hot-fixes/

Yeah, what is it with mirroring over there. Seems to have gone to hell
in a hand basket.

The automatic hotfix pickup seems to have done its thing and the results
should be out on TKO. Generally looking _much_ better.

-apw

2006-11-16 01:30:36

by Zachary Amsden

[permalink] [raw]

Subject: Re: 2.6.19-rc5-mm2: paravirt X86_PAE=y compile error

Save big on PAE patches, now cheaper by the dozen!
I hope this doesn't trip someone's ham filter.

Signed-off-by: Zachary Amsden <[email protected]>

Index: linux-2.6.18/include/asm-i386/pgtable-3level.h
===================================================================
--- linux-2.6.18.orig/include/asm-i386/pgtable-3level.h 2006-11-10 14:49:51.000000000 -0800
+++ linux-2.6.18/include/asm-i386/pgtable-3level.h 2006-11-15 17:26:54.000000000 -0800
@@ -78,26 +78,6 @@ static inline void set_pte_present(struc
set_64bit((unsigned long long *)(pmdptr),pmd_val(pmdval))
#define set_pud(pudptr,pudval) \
(*(pudptr) = (pudval))
-#endif
-
-/*
- * Pentium-II erratum A13: in PAE mode we explicitly have to flush
- * the TLB via cr3 if the top-level pgd is changed...
- * We do not let the generic code free and clear pgd entries due to
- * this erratum.
- */
-static inline void pud_clear (pud_t * pud) { }
-
-#define pud_page(pud) \
-((struct page *) __va(pud_val(pud) & PAGE_MASK))
-
-#define pud_page_vaddr(pud) \
-((unsigned long) __va(pud_val(pud) & PAGE_MASK))
-
-
-/* Find an entry in the second-level page table.. */
-#define pmd_offset(pud, address) ((pmd_t *) pud_page(*(pud)) + \
- pmd_index(address))

/*
* For PTEs and PDEs, we must clear the P-bit first when clearing a page table
@@ -118,6 +98,26 @@ static inline void pmd_clear(pmd_t *pmd)
smp_wmb();
*(tmp + 1) = 0;
}
+#endif
+
+/*
+ * Pentium-II erratum A13: in PAE mode we explicitly have to flush
+ * the TLB via cr3 if the top-level pgd is changed...
+ * We do not let the generic code free and clear pgd entries due to
+ * this erratum.
+ */
+static inline void pud_clear (pud_t * pud) { }
+
+#define pud_page(pud) \
+((struct page *) __va(pud_val(pud) & PAGE_MASK))
+
+#define pud_page_vaddr(pud) \
+((unsigned long) __va(pud_val(pud) & PAGE_MASK))
+
+
+/* Find an entry in the second-level page table.. */
+#define pmd_offset(pud, address) ((pmd_t *) pud_page(*(pud)) + \
+ pmd_index(address))

#define __HAVE_ARCH_PTEP_GET_AND_CLEAR
static inline pte_t ptep_get_and_clear(struct mm_struct *mm, unsigned long addr, pte_t *ptep)

Attachments:

pae-fix.patch (2.07 kB)

2006-11-16 02:27:14

by Chris Wright

[permalink] [raw]

Subject: Re: 2.6.19-rc5-mm2: paravirt X86_PAE=y compile error

* Zachary Amsden ([email protected]) wrote:
> Well that shouldn't have happened. Must have been some reject that went
> unnoticed? Try this.

Thanks Zach, added to the pv patchqueue as well.
-chris

2006-11-16 05:49:01

[permalink] [raw]

Subject: Re: Boot failure with ext2 and initrds

On Wed, 15 Nov 2006 14:17:01 +0000 (GMT)
Hugh Dickins <[email protected]> wrote:

> On Tue, 14 Nov 2006, Hugh Dickins wrote:
> > On Tue, 14 Nov 2006, Andrew Morton wrote:
> > >
> > > The below might help.
> >
> > Indeed it does (with Martin's E2FSBLK warning fix),
> > seems to be running well on all machines now.
>
> i386 and ppc64 still doing builds, but after an hour on x86_64,
> an ld got stuck in a loop under ext2_try_to_allocate_with_rsv,
> alternating between ext2_rsv_window_add and rsv_window_remove.
> Send me a patch and I'll try it...
>
> ext2_try_to_allocate_with_rsv+0x288
> ext2_new_blocks+0x21e
> ext2_get_blocks+0x398
> ext2_get_block+0x46
> __block_prepare_write+0x171
> block_prepare_write+0x39
> ext2_prepare_write+0x2c
> generic_file_buffered_write+0x2b0
> __generic_file_aio_write_nolock+0x4bc
> generic_file_aio_write+0x6d
> do_sync_write+0xf9
> vfs_write+0xc8
> sys_write+0x51

OK, I have a theory.

This must have been the seventeenth damn time I've stared at
find_next_zero_bit() wondering what the damn return value is and wondering
how any even slightly non-sadistic person could write a damn function like
that and not damn well document it.

int find_next_zero_bit(const unsigned long *addr, int size, int offset)

It returns the offset of the first zero bit relative to addr.

ext3's bitmap_search_next_usable_block() assumed that find_next_zero_bit()
returns the offset of the first zero bit relative to (addr+offset).

The while loop in ext3's bitmap_search_next_usable_block() serendipitously
covered that bug up.

ext2's bitmap_search_next_usable_block() doesn't need that while loop, so
ext3's benign bug became ext2's fatal bug.

So...

--- a/fs/ext2/balloc.c~a
+++ a/fs/ext2/balloc.c
@@ -524,7 +524,7 @@ bitmap_search_next_usable_block(ext2_grp
ext2_grpblk_t next;

next = ext2_find_next_zero_bit(bh->b_data, maxblocks, start);
- if (next >= maxblocks)
+ if (next >= start + maxblocks)
return -1;
return next;
}
_

Anyway, I think that's the bug. Or a bug, at least. If so, the cause of
this bug is inadequate code commenting, pure and simple. And ext3 and ext4
need fixing.

2006-11-16 06:39:48

[permalink] [raw]

Subject: Re: Boot failure with ext2 and initrds

On Wed, 15 Nov 2006 21:45:34 -0800
Andrew Morton <[email protected]> wrote:

> --- a/fs/ext2/balloc.c~a
> +++ a/fs/ext2/balloc.c
> @@ -524,7 +524,7 @@ bitmap_search_next_usable_block(ext2_grp
> ext2_grpblk_t next;
>
> next = ext2_find_next_zero_bit(bh->b_data, maxblocks, start);
> - if (next >= maxblocks)
> + if (next >= start + maxblocks)
> return -1;
> return next;
> }
> _
>
> Anyway, I think that's the bug.

Changed my mind. Drat.

2006-11-16 06:56:06

[permalink] [raw]

Subject: Re: Boot failure with ext2 and initrds

Andrew Morton wrote:
> On Wed, 15 Nov 2006 14:17:01 +0000 (GMT)
> Hugh Dickins <[email protected]> wrote:
>
>
>>On Tue, 14 Nov 2006, Hugh Dickins wrote:
>>
>>>On Tue, 14 Nov 2006, Andrew Morton wrote:
>>>
>>>>The below might help.
>>>
>>>Indeed it does (with Martin's E2FSBLK warning fix),
>>>seems to be running well on all machines now.
>>
>>i386 and ppc64 still doing builds, but after an hour on x86_64,
>>an ld got stuck in a loop under ext2_try_to_allocate_with_rsv,
>>alternating between ext2_rsv_window_add and rsv_window_remove.
>>Send me a patch and I'll try it...
>>
>>ext2_try_to_allocate_with_rsv+0x288
>>ext2_new_blocks+0x21e
>>ext2_get_blocks+0x398
>>ext2_get_block+0x46
>>__block_prepare_write+0x171
>>block_prepare_write+0x39
>>ext2_prepare_write+0x2c
>>generic_file_buffered_write+0x2b0
>>__generic_file_aio_write_nolock+0x4bc
>>generic_file_aio_write+0x6d
>>do_sync_write+0xf9
>>vfs_write+0xc8
>>sys_write+0x51
>
>
> OK, I have a theory.
>
> This must have been the seventeenth damn time I've stared at
> find_next_zero_bit() wondering what the damn return value is and wondering
> how any even slightly non-sadistic person could write a damn function like
> that and not damn well document it.
>
> int find_next_zero_bit(const unsigned long *addr, int size, int offset)
>
> It returns the offset of the first zero bit relative to addr.
>
> ext3's bitmap_search_next_usable_block() assumed that find_next_zero_bit()
> returns the offset of the first zero bit relative to (addr+offset).
>
> The while loop in ext3's bitmap_search_next_usable_block() serendipitously
> covered that bug up.
>
> ext2's bitmap_search_next_usable_block() doesn't need that while loop, so
> ext3's benign bug became ext2's fatal bug.
>
> So...
>
> --- a/fs/ext2/balloc.c~a
> +++ a/fs/ext2/balloc.c
> @@ -524,7 +524,7 @@ bitmap_search_next_usable_block(ext2_grp
> ext2_grpblk_t next;
>
> next = ext2_find_next_zero_bit(bh->b_data, maxblocks, start);
> - if (next >= maxblocks)
> + if (next >= start + maxblocks)
> return -1;
> return next;
> }
> _
>
> Anyway, I think that's the bug. Or a bug, at least. If so, the cause of
> this bug is inadequate code commenting, pure and simple. And ext3 and ext4
> need fixing.
>
Hmm, maxblocks, in bitmap_search_next_usable_block(), is the end block
number of the range to search, not the lengh of the range. maxblocks
get passed to ext2_find_next_zero_bit(), where it expecting to take the
_size_ of the range to search instead...

Something like this: (this is not a patch)
@@ -524,7 +524,7 @@ bitmap_search_next_usable_block(ext2_grp
ext2_grpblk_t next;

- next = ext2_find_next_zero_bit(bh->b_data, maxblocks, start);
+ next = ext2_find_next_zero_bit(bh->b_data, maxblocks-start + 1,
start);
if (next >= maxblocks)
return -1;
return next;
}

Mingming

Yes, it's quite confusing and probably we should replace it a better
name......

Mingming

2006-11-16 07:05:37

by Andi Kleen

[permalink] [raw]

Subject: Re: 2.6.19-rc5-mm2: paravirt X86_PAE=y compile error

On Thursday 16 November 2006 03:27, Chris Wright wrote:
> * Zachary Amsden ([email protected]) wrote:
> > Well that shouldn't have happened. Must have been some reject that went
> > unnoticed? Try this.
>
> Thanks Zach, added to the pv patchqueue as well.

That was one of the things that got fixed in paravirt-compile too iirc

-Andi

2006-11-16 07:22:49

[permalink] [raw]

Subject: Re: Boot failure with ext2 and initrds

On Wed, 15 Nov 2006 22:55:43 -0800
Mingming Cao <[email protected]> wrote:

> Hmm, maxblocks, in bitmap_search_next_usable_block(), is the end block
> number of the range to search, not the lengh of the range. maxblocks
> get passed to ext2_find_next_zero_bit(), where it expecting to take the
> _size_ of the range to search instead...
>
> Something like this: (this is not a patch)
> @@ -524,7 +524,7 @@ bitmap_search_next_usable_block(ext2_grp
> ext2_grpblk_t next;
>
> - next = ext2_find_next_zero_bit(bh->b_data, maxblocks, start);
> + next = ext2_find_next_zero_bit(bh->b_data, maxblocks-start + 1, start);
> if (next >= maxblocks)
> return -1;
> return next;
> }

yes, the `size' arg to find_next_zero_bit() represents the number of bits
to scan at `offset'.

So I think your change is correctish. But we don't want the "+ 1", do we?

If we're right then this bug could cause the code to scan off the end of the
bitmap. But it won't explain Hugh's bug, because of the if (next >= maxblocks).

btw, how come try_to_extend_reservation() uses spin_trylock?

2006-11-16 08:49:28

[permalink] [raw]

Subject: Re: Boot failure with ext2 and initrds

On Wed, 2006-11-15 at 23:22 -0800, Andrew Morton wrote:
> On Wed, 15 Nov 2006 22:55:43 -0800
> Mingming Cao <[email protected]> wrote:
>
> > Hmm, maxblocks, in bitmap_search_next_usable_block(), is the end block
> > number of the range to search, not the lengh of the range. maxblocks
> > get passed to ext2_find_next_zero_bit(), where it expecting to take the
> > _size_ of the range to search instead...
> >
> > Something like this: (this is not a patch)
> > @@ -524,7 +524,7 @@ bitmap_search_next_usable_block(ext2_grp
> > ext2_grpblk_t next;
> >
> > - next = ext2_find_next_zero_bit(bh->b_data, maxblocks, start);
> > + next = ext2_find_next_zero_bit(bh->b_data, maxblocks-start + 1, start);
> > if (next >= maxblocks)
> > return -1;
> > return next;
> > }
>
> yes, the `size' arg to find_next_zero_bit() represents the number of bits
> to scan at `offset'.
>
> So I think your change is correctish. But we don't want the "+ 1", do we?
>
I think we still need the "+1", maxblocks here is the ending block of
the reservation window, so the number of bits to scan =end-start+1.

> If we're right then this bug could cause the code to scan off the end of the
> bitmap. But it won't explain Hugh's bug, because of the if (next >= maxblocks).
>

Yeah.. at first I thought it might be related, then, thinked it over,
the bug only makes the bits to scan larger, so if find_next_zero_bit()
returns something off the end of bitmap, that is fine, it just
indicating that there is no free bit left in the rest of bitmap, which
is expected behavior. So bitmap_search_next_usable_block() fail is the
expected. It will move on to next block group and try to create a new
reservation window there.

That does not explain the repeated reservation window add and remove
behavior Huge has reported.

> btw, how come try_to_extend_reservation() uses spin_trylock?

Since locks are all allocated from reservation window, when ext3
multiple blocks allocation was added, we added try_to_extend_reservation
() to ext3, which trying to extend the reservation window size to at
least match the number of blocks to allocate. So we have better chance
to allocating multiple blocks from the window at a time.

Since all the multiple block allocation is based on best effort basis,
the same applied to try_to_extend_reservation(). It seems no need to
wait for the reservation tree lock if it's not avaible at that moment.

Mingming

2006-11-16 09:05:23

[permalink] [raw]

Subject: Re: Boot failure with ext2 and initrds

On Tue, 2006-11-14 at 11:31 -0800, Andrew Morton wrote:
> On Tue, 14 Nov 2006 19:11:22 +0000 (GMT)
> Hugh Dickins <[email protected]> wrote:
>
> > On Tue, 14 Nov 2006, Mel Gorman wrote:
> > > 2.6.19-rc5-mm2
> > >
> > > Am seeing errors with systems using ext2. First machine is a plan old x86
> > > using initramfs. Console output looks like;
> > > ...
> > > Configuring network interfaces...BUG: soft lockup detected on CPU#3!
> > > ...
> > > [<c01b3b80>] ext2_try_to_allocate+0xdb/0x152
> > > [<c01b3e72>] ext2_try_to_allocate_with_rsv+0x4b/0x1b2
> > >
> > > I've not investigated yet what patches might be at fault.
> >
> > I expect you'll find it's
> > ext2-reservations-bring-ext2-reservations-code-in-line-with-latest-ext3.patch
> > which gets stuck in a loop there for me too: back it out and all seems fine.
> >
> > It's not obvious which part of the patch is to blame: mostly it's
> > cleanup, but a few variables do change size: I'm currently narrowing
> > down to where a fix is needed.
> >
>
> Doing s/-Wall/-W/ tends to shake out bugs in this stuff.
>
> The below might help.
>
> Sorry, I tested this well, then the cleanup patch was merged and I didn't
> get onto retesting :(
>
>
>
> From: Andrew Morton <[email protected]>
>
> Signed-off-by: Andrew Morton <[email protected]>
> ---
>
> fs/ext2/balloc.c | 33 +++++++++++++++------------------
> 1 files changed, 15 insertions(+), 18 deletions(-)
>
> diff -puN fs/ext2/balloc.c~ext2-reservations-bring-ext2-reservations-code-in-line-with-latest-ext3-fix fs/ext2/balloc.c
> --- a/fs/ext2/balloc.c~ext2-reservations-bring-ext2-reservations-code-in-line-with-latest-ext3-fix
> +++ a/fs/ext2/balloc.c
> @@ -1155,9 +1155,10 @@ int ext2_new_blocks(struct inode *inode,

This is different from ext3. Shouldn't the return value from
ext2_new_blocks() a ext2_fsblk_t type?

ext2_alloc_blocks() already thinks that ext2_new_blocks return unsigned
block number.

> struct buffer_head *gdp_bh;
> int group_no;
> int goal_group;
> + ext2_grpblk_t grp_target_blk; /* blockgroup relative goal block */
> + ext2_grpblk_t grp_alloc_blk; /* blockgroup-relative allocated block*/
> ext2_fsblk_t ret_block; /* filesyetem-wide allocated block */
> int bgi; /* blockgroup iteration index */
> - int target_block;
> int performed_allocation = 0;
> ext2_grpblk_t free_blocks; /* number of free blocks in a group */
> struct super_block *sb;
> @@ -1230,14 +1231,15 @@ retry_alloc:
> my_rsv = NULL;
>
> if (free_blocks > 0) {
> - ret_block = ((goal - le32_to_cpu(es->s_first_data_block)) %
> + grp_target_blk = ((goal - le32_to_cpu(es->s_first_data_block)) %
> EXT2_BLOCKS_PER_GROUP(sb));
> bitmap_bh = read_block_bitmap(sb, group_no);
> if (!bitmap_bh)
> goto io_error;
> - ret_block = ext2_try_to_allocate_with_rsv(sb, group_no,
> - bitmap_bh, ret_block, my_rsv, &num);
> - if (ret_block >= 0)
> + grp_alloc_blk = ext2_try_to_allocate_with_rsv(sb, group_no,
> + bitmap_bh, grp_target_blk,
> + my_rsv, &num);
> + if (grp_alloc_blk >= 0)
> goto allocated;
> }
>
> @@ -1273,9 +1275,9 @@ retry_alloc:
> /*
> * try to allocate block(s) from this group, without a goal(-1).
> */
> - ret_block = ext2_try_to_allocate_with_rsv(sb, group_no,
> + grp_alloc_blk = ext2_try_to_allocate_with_rsv(sb, group_no,
> bitmap_bh, -1, my_rsv, &num);
> - if (ret_block >= 0)
> + if (grp_alloc_blk >= 0)
> goto allocated;
> }
> /*
> @@ -1299,25 +1301,20 @@ allocated:
> ext2_debug("using block group %d(%d)\n",
> group_no, gdp->bg_free_blocks_count);
>
> - target_block = ret_block + group_no * EXT2_BLOCKS_PER_GROUP(sb)
> - + le32_to_cpu(es->s_first_data_block);
> + ret_block = grp_alloc_blk + ext2_group_first_block_no(sb, group_no);
>
> - if (in_range(le32_to_cpu(gdp->bg_block_bitmap), target_block, num) ||
> - in_range(le32_to_cpu(gdp->bg_inode_bitmap), target_block, num) ||
> - in_range(target_block, le32_to_cpu(gdp->bg_inode_table),
> + if (in_range(le32_to_cpu(gdp->bg_block_bitmap), ret_block, num) ||
> + in_range(le32_to_cpu(gdp->bg_inode_bitmap), ret_block, num) ||
> + in_range(ret_block, le32_to_cpu(gdp->bg_inode_table),
> EXT2_SB(sb)->s_itb_per_group) ||
> - in_range(target_block + num - 1, le32_to_cpu(gdp->bg_inode_table),
> + in_range(ret_block + num - 1, le32_to_cpu(gdp->bg_inode_table),
> EXT2_SB(sb)->s_itb_per_group))
> ext2_error(sb, "ext2_new_blocks",
> "Allocating block in system zone - "
> - "blocks from %u, length %lu", target_block, num);
> + "blocks from %u, length %lu", ret_block, num);
>
> performed_allocation = 1;
>
> -
> - /* ret_block was blockgroup-relative. Now it becomes fs-relative */
> - ret_block = target_block;
> -
> if (ret_block + num - 1 >= le32_to_cpu(es->s_blocks_count)) {
> ext2_error(sb, "ext2_new_blocks",
> "block("E2FSBLK") >= blocks count(%d) - "
> _
>
> -
> 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/
>

2006-11-16 09:21:20

[permalink] [raw]

Subject: Re: Boot failure with ext2 and initrds

On Thu, 16 Nov 2006 00:49:20 -0800
Mingming Cao <[email protected]> wrote:

> On Wed, 2006-11-15 at 23:22 -0800, Andrew Morton wrote:
> > On Wed, 15 Nov 2006 22:55:43 -0800
> > Mingming Cao <[email protected]> wrote:
> >
> > > Hmm, maxblocks, in bitmap_search_next_usable_block(), is the end block
> > > number of the range to search, not the lengh of the range. maxblocks
> > > get passed to ext2_find_next_zero_bit(), where it expecting to take the
> > > _size_ of the range to search instead...
> > >
> > > Something like this: (this is not a patch)
> > > @@ -524,7 +524,7 @@ bitmap_search_next_usable_block(ext2_grp
> > > ext2_grpblk_t next;
> > >
> > > - next = ext2_find_next_zero_bit(bh->b_data, maxblocks, start);
> > > + next = ext2_find_next_zero_bit(bh->b_data, maxblocks-start + 1, start);
> > > if (next >= maxblocks)
> > > return -1;
> > > return next;
> > > }
> >
> > yes, the `size' arg to find_next_zero_bit() represents the number of bits
> > to scan at `offset'.
> >
> > So I think your change is correctish. But we don't want the "+ 1", do we?
> >
> I think we still need the "+1", maxblocks here is the ending block of
> the reservation window, so the number of bits to scan =end-start+1.
>
> > If we're right then this bug could cause the code to scan off the end of the
> > bitmap. But it won't explain Hugh's bug, because of the if (next >= maxblocks).
> >
>
> Yeah.. at first I thought it might be related, then, thinked it over,
> the bug only makes the bits to scan larger, so if find_next_zero_bit()
> returns something off the end of bitmap, that is fine, it just
> indicating that there is no free bit left in the rest of bitmap, which
> is expected behavior. So bitmap_search_next_usable_block() fail is the
> expected. It will move on to next block group and try to create a new
> reservation window there.

I wonder why it's never oopsed. Perhaps there's always a zero in there for
some reason.

> That does not explain the repeated reservation window add and remove
> behavior Huge has reported.

I spent quite some time comparing with ext3. I'm a bit stumped and I'm
suspecting that the simplistic porting the code is now OK, but something's
just wrong.

I assume that the while (1) loop in ext3_try_to_allocate_with_rsv() has
gone infinite. I don't see why, but more staring is needed.

What lock protects the fields in struct ext[234]_reserve_window from being
concurrently modified by two CPUs? None, it seems. Ditto
ext[234]_reserve_window_node. i_mutex will cover it for write(), but not
for pageout over a file hole. If we end up with a zero- or negative-sized
window then odd things might happen.

> > btw, how come try_to_extend_reservation() uses spin_trylock?
>
> Since locks are all allocated from reservation window, when ext3
> multiple blocks allocation was added, we added try_to_extend_reservation
> () to ext3, which trying to extend the reservation window size to at
> least match the number of blocks to allocate. So we have better chance
> to allocating multiple blocks from the window at a time.
>
> Since all the multiple block allocation is based on best effort basis,
> the same applied to try_to_extend_reservation(). It seems no need to
> wait for the reservation tree lock if it's not avaible at that moment.
>

I suspect that was not a good idea - it has added rather different
behaviour in the once-in-a-million case.

2006-11-16 09:39:56

by Alex Tomas

[permalink] [raw]

Subject: Re: Boot failure with ext2 and initrds

>>>>> Andrew Morton (AM) writes:

AM> What lock protects the fields in struct ext[234]_reserve_window from being
AM> concurrently modified by two CPUs? None, it seems. Ditto
AM> ext[234]_reserve_window_node. i_mutex will cover it for write(), but not
AM> for pageout over a file hole. If we end up with a zero- or negative-sized
AM> window then odd things might happen.

truncate_mutex?

thanks, Alex

2006-11-16 09:50:49

[permalink] [raw]

Subject: Re: Boot failure with ext2 and initrds

On Thu, 16 Nov 2006 01:48:09 -0800
Andrew Morton <[email protected]> wrote:

> On Thu, 16 Nov 2006 12:37:17 +0300
> Alex Tomas <[email protected]> wrote:
>
> > >>>>> Andrew Morton (AM) writes:
> >
> > AM> What lock protects the fields in struct ext[234]_reserve_window from being
> > AM> concurrently modified by two CPUs? None, it seems. Ditto
> > AM> ext[234]_reserve_window_node. i_mutex will cover it for write(), but not
> > AM> for pageout over a file hole. If we end up with a zero- or negative-sized
> > AM> window then odd things might happen.
> >
> > truncate_mutex?
> >
>
> yes. hmm.

by which I mean "ext2 doesn't have a truncate_mutex".

2006-11-16 09:51:34

[permalink] [raw]

Subject: Re: Boot failure with ext2 and initrds

On Thu, 16 Nov 2006 12:37:17 +0300
Alex Tomas <[email protected]> wrote:

> >>>>> Andrew Morton (AM) writes:
>
> AM> What lock protects the fields in struct ext[234]_reserve_window from being
> AM> concurrently modified by two CPUs? None, it seems. Ditto
> AM> ext[234]_reserve_window_node. i_mutex will cover it for write(), but not
> AM> for pageout over a file hole. If we end up with a zero- or negative-sized
> AM> window then odd things might happen.
>
> truncate_mutex?
>

yes. hmm.

2006-11-16 12:16:20

[permalink] [raw]

Subject: [-mm patch] remove arch/i386/kernel/time_hpet.c:hpet_reenable()

On Tue, Nov 14, 2006 at 01:41:25AM -0800, Andrew Morton wrote:
>...
> Changes since 2.6.19-rc5-mm2:
>...
> +updated-i386-convert-to-clock-event-devices.patch
>...
> Updated/fixed/reworked/redone hrtimer and dynticks patches.
>...

This patch removes the no longer used hpet_reenable()

Signed-off-by: Adrian Bunk <[email protected]>

---

arch/i386/kernel/time_hpet.c | 5 -----
include/asm-i386/hpet.h | 1 -
2 files changed, 6 deletions(-)

--- linux-2.6.19-rc5-mm2/include/asm-i386/hpet.h.old 2006-11-15 18:49:35.000000000 +0100
+++ linux-2.6.19-rc5-mm2/include/asm-i386/hpet.h 2006-11-15 18:49:44.000000000 +0100
@@ -96,7 +96,6 @@

extern int hpet_rtc_timer_init(void);
extern int hpet_enable(void);
-extern int hpet_reenable(void);
extern int is_hpet_enabled(void);
extern int is_hpet_capable(void);
extern int hpet_readl(unsigned long a);
--- linux-2.6.19-rc5-mm2/arch/i386/kernel/time_hpet.c.old 2006-11-15 18:49:53.000000000 +0100
+++ linux-2.6.19-rc5-mm2/arch/i386/kernel/time_hpet.c 2006-11-15 18:50:02.000000000 +0100
@@ -199,11 +199,6 @@
return 0;
}

-int hpet_reenable(void)
-{
- return hpet_timer_stop_set_go(hpet_tick);
-}
-
int is_hpet_enabled(void)
{
return use_hpet;

2006-11-16 12:35:11

[permalink] [raw]

Subject: Re: Boot failure with ext2 and initrds

On Wed, Nov 15, 2006 at 11:22:28PM -0800, Andrew Morton wrote:
> On Wed, 15 Nov 2006 22:55:43 -0800
> Mingming Cao <[email protected]> wrote:
>
> > Hmm, maxblocks, in bitmap_search_next_usable_block(), is the end block
> > number of the range to search, not the lengh of the range. maxblocks
> > get passed to ext2_find_next_zero_bit(), where it expecting to take the
> > _size_ of the range to search instead...
> >
> > Something like this: (this is not a patch)
> > @@ -524,7 +524,7 @@ bitmap_search_next_usable_block(ext2_grp
> > ext2_grpblk_t next;
> >
> > - next = ext2_find_next_zero_bit(bh->b_data, maxblocks, start);
> > + next = ext2_find_next_zero_bit(bh->b_data, maxblocks-start + 1, start);
> > if (next >= maxblocks)
> > return -1;
> > return next;
> > }
>
> yes, the `size' arg to find_next_zero_bit() represents the number of bits
> to scan at `offset'.

Are you sure? That's not the way it's implemented in many architectures.
find_next_*_bit() has always taken "address, maximum offset, starting offset"
and always has returned "next offset".

Just look at arch/i386/lib/bitops.c:

int find_next_zero_bit(const unsigned long *addr, int size, int offset)
{
unsigned long * p = ((unsigned long *) addr) + (offset >> 5);
int set = 0, bit = offset & 31, res;
...
/*
* No zero yet, search remaining full bytes for a zero
*/
res = find_first_zero_bit (p, size - 32 * (p - (unsigned long *) addr));
return (offset + set + res);
}

So for the case that "offset" is aligned to a "long" boundary, that gives us:

res = find_first_zero_bit(addr + (offset>>5),
size - 32 * (addr + (offset>>5) - addr));

or:

res = find_first_zero_bit(addr + (offset>>5), size - (offset & ~31));

So, size _excludes_ offset.

Now, considering the return value, "res" above will be relative to
"addr + (offset>>5)". However, we add "offset" on to that, so it's
relative to addr + (offset bits).

--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 Serial core

2006-11-16 16:25:49

[permalink] [raw]

Subject: Re: Boot failure with ext2 and initrds

On Thu, 16 Nov 2006, Andrew Morton wrote:
> On Thu, 16 Nov 2006 00:49:20 -0800
> Mingming Cao <[email protected]> wrote:
>
> > That does not explain the repeated reservation window add and remove
> > behavior Huge has reported.
>
> I spent quite some time comparing with ext3. I'm a bit stumped and I'm
> suspecting that the simplistic porting the code is now OK, but something's
> just wrong.
>
> I assume that the while (1) loop in ext3_try_to_allocate_with_rsv() has
> gone infinite. I don't see why, but more staring is needed.

Just to report that similar tests on three machines have each run
for 20 hours so far without any such infinite loop reoccurring.

Well, I broke off the x86_64 for a couple of hours: wondered if I'd got
confused, forgotten to "rmmod ext2" at one stage, and saw that behaviour
with my simple "ext2fs_blk_t ret_block" patch, rather than your more
extensive patch to ext2_new_blocks() that I'd believed I was testing.
I didn't give it long enough to be conclusive, but the problem didn't
show up with that either, so I've gone back to testing with yours.

I'd have kept the hang around for longer if I'd guessed it would be
hard to reproduce, and that it would be puzzling even to you: sorry.
kdb is in, if it comes again I can peer at it more closely.

Hugh

2006-11-16 17:17:31

[permalink] [raw]

Subject: Re: 2.6.19-rc5-mm2

Hello,

got the following when removing ohci1394 (also happens in -mm1), config
and full dmesg are here:
http://oioio.altervista.org/linux/config-2.6.19-rc5-mm2-1
http://oioio.altervista.org/linux/config-2.6.19-rc5-mm1-4
http://oioio.altervista.org/linux/oops_rmmod_ohci-2.6.19-rc5-mm2
http://oioio.altervista.org/linux/oops_rmmod_ohci-2.6.19-rc5-mm1

ieee1394: Node removed: ID:BUS[0-00:1023] GUID[080046030227e7bb]
ieee1394: Node removed: ID:BUS[20754571-38:0391] GUID[00000000f8eb5067]
BUG: unable to handle kernel NULL pointer dereference at virtual address 000000a4
printing eip:
c0238c60
*pde = 00000000
Oops: 0000 [#1]
SMP
last sysfs file: /devices/pci0000:00/0000:00:1c.1/0000:06:00.0/cmd
Modules linked in: ipv6 cpufreq_ondemand acpi_cpufreq freq_table thermal fan button processor ac battery ipt_MASQUERADE iptable_nat ip_nat xt_tcpudp xt_state ip_conntrack nfnetlink iptable_filter ip_tables x_tables dm_snapshot dm_mirror dm_mod sonypi sony_acpi backlight loop hci_usb bluetooth eth1394 usb_storage pcmcia snd_hda_intel snd_hda_codec snd_pcm_oss snd_mixer_oss ipw3945 snd_pcm ieee80211 ieee80211_crypt i2c_i801 intel_agp ohci1394 ide_cd firmware_class yenta_socket rsrc_nonstatic pcmcia_core sky2 tifm_7xx1 tifm_core agpgart rtc uhci_hcd psmouse tpm_infineon tpm tpm_bios ieee1394 snd_timer evdev usbcore pcspkr cdrom snd soundcore snd_page_alloc
CPU: 0
EIP: 0060:[<c0238c60>] Not tainted VLI
EFLAGS: 00010246 (2.6.19-rc5-mm2-1 #9)
EIP is at class_device_remove_attrs+0xd/0x34
eax: f7f7938c ebx: 00000000 ecx: c012013a edx: 00000000
esi: 00000000 edi: f7f7938c ebp: f71a7df4 esp: f71a7de8
ds: 007b es: 007b ss: 0068
Process rmmod (pid: 2398, ti=f71a6000 task=c1974030 task.ti=f71a6000)
Stack: f7f7938c f7f79394 00000000 f71a7e10 c0238d47 00000000 f7f791f4 f7f7938c
f7f79230 00000000 f71a7e1c c0238d82 f7f791f4 f71a7e44 f8d49ea9 f8d4f495
013cb08b 00000026 00000187 f8eb5067 00000000 00000000 f8d49ebe f71a7e4c
Call Trace:
[<c0238d47>] class_device_del+0xc0/0xf0
[<c0238d82>] class_device_unregister+0xb/0x15
[<f8d49ea9>] nodemgr_remove_ne+0x64/0x79 [ieee1394]
[<f8d49ec9>] __nodemgr_remove_host_dev+0xb/0xf [ieee1394]
[<c02366dc>] device_for_each_child+0x1d/0x46
[<f8d49f9a>] nodemgr_remove_host+0x33/0x90 [ieee1394]
[<f8d47500>] __unregister_host+0x1b/0x9b [ieee1394]
[<f8d47716>] highlevel_remove_host+0x24/0x47 [ieee1394]
[<f8d4715e>] hpsb_remove_host+0x3b/0x5d [ieee1394]
[<f8dca212>] ohci1394_pci_remove+0x47/0x1c7 [ohci1394]
[<c01dd619>] pci_device_remove+0x19/0x39
[<c02383f7>] __device_release_driver+0x71/0x86
[<c023885f>] driver_detach+0x83/0xc4
[<c023802b>] bus_remove_driver+0x5a/0x76
[<c02388c7>] driver_unregister+0xb/0x18
[<c01dd787>] pci_unregister_driver+0xf/0x5b
[<f8dcd2de>] ohci1394_cleanup+0xd/0xf [ohci1394]
[<c013b193>] sys_delete_module+0x18c/0x1b5
[<c0102d66>] sysenter_past_esp+0x5f/0x85
DWARF2 unwinder stuck at sysenter_past_esp+0x5f/0x85
Leftover inexact backtrace:
=======================
Code: c0 08 e8 fb f2 f5 ff 89 c1 5d 89 c8 c3 55 85 c0 89 e5 74 08 83 c0 08 e8 6b d9 f5 ff 5d c3 55 89 e5 57 89 c7 56 53 31 db 8b 70 48 <83> be a4 00 00 00 00 75 09 eb 17 89 f8 e8 d0 ff ff ff 89 da 83
EIP: [<c0238c60>] class_device_remove_attrs+0xd/0x34 SS:ESP 0068:f71a7de8

--
mattia
:wq!

2006-11-16 18:30:01

[permalink] [raw]

Subject: Re: 2.6.19-rc5-mm2

Mattia Dongili wrote:
> got the following when removing ohci1394 (also happens in -mm1),
...
> ieee1394: Node removed: ID:BUS[0-00:1023] GUID[080046030227e7bb]
> ieee1394: Node removed: ID:BUS[20754571-38:0391] GUID[00000000f8eb5067]

Hm, there is garbage in this node data. Moreover, your full logs show
that there was never another node added besides the host node. IOW the
second "Node removed" line shouldn't be there. Very strange.

> BUG: unable to handle kernel NULL pointer dereference at virtual address 000000a4
...
> EIP is at class_device_remove_attrs+0xd/0x34
...

Could you also test one or even better both of:
- 2.6.19-rc5 plus
http://me.in-berlin.de/~s5r6/linux1394/updates/2.6.19-rc5/2.6.19-rc5_ieee1394_v204_experimental.patch.bz2
(these are the same FireWire drivers as in -rc5-mm2)
and/ or
- 2.6.19-rc5-mm2 minus
http://www.it.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.19-rc5/2.6.19-rc5-mm2/broken-out/git-ieee1394.patch

Thanks so far,
--
Stefan Richter
-=====-=-==- =-== =----
http://arcgraph.de/sr/

2006-11-16 20:15:22

[permalink] [raw]

Subject: Re: Boot failure with ext2 and initrds

On Thu, 2006-11-16 at 01:13 -0800, Andrew Morton wrote:
> On Thu, 16 Nov 2006 00:49:20 -0800
> Mingming Cao <[email protected]> wrote:
>
> > On Wed, 2006-11-15 at 23:22 -0800, Andrew Morton wrote:
> > > On Wed, 15 Nov 2006 22:55:43 -0800
> > > Mingming Cao <[email protected]> wrote:
> > >
> > > > Hmm, maxblocks, in bitmap_search_next_usable_block(), is the end block
> > > > number of the range to search, not the lengh of the range. maxblocks
> > > > get passed to ext2_find_next_zero_bit(), where it expecting to take the
> > > > _size_ of the range to search instead...
> > > >
> > > > Something like this: (this is not a patch)
> > > > @@ -524,7 +524,7 @@ bitmap_search_next_usable_block(ext2_grp
> > > > ext2_grpblk_t next;
> > > >
> > > > - next = ext2_find_next_zero_bit(bh->b_data, maxblocks, start);
> > > > + next = ext2_find_next_zero_bit(bh->b_data, maxblocks-start + 1, start);
> > > > if (next >= maxblocks)
> > > > return -1;
> > > > return next;
> > > > }
> > >
> > > yes, the `size' arg to find_next_zero_bit() represents the number of bits
> > > to scan at `offset'.
> > >
> > > So I think your change is correctish. But we don't want the "+ 1", do we?
> > >
> > I think we still need the "+1", maxblocks here is the ending block of
> > the reservation window, so the number of bits to scan =end-start+1.
> >
> > > If we're right then this bug could cause the code to scan off the end of the
> > > bitmap. But it won't explain Hugh's bug, because of the if (next >= maxblocks).
> > >
> >
> > Yeah.. at first I thought it might be related, then, thinked it over,
> > the bug only makes the bits to scan larger, so if find_next_zero_bit()
> > returns something off the end of bitmap, that is fine, it just
> > indicating that there is no free bit left in the rest of bitmap, which
> > is expected behavior. So bitmap_search_next_usable_block() fail is the
> > expected. It will move on to next block group and try to create a new
> > reservation window there.
>
> I wonder why it's never oopsed. Perhaps there's always a zero in there for
> some reason.
>

Why you think it should oopsed? Even if find_next_zero_bit() finds a
zero bit beyond of the end of bitmap, the check next > maxblocks will
catch this and make sure we are not taking a zero bit out of the bitmap
range, so it fails as expected.

> > That does not explain the repeated reservation window add and remove
> > behavior Huge has reported.
>
> I spent quite some time comparing with ext3. I'm a bit stumped and I'm
> suspecting that the simplistic porting the code is now OK, but something's
> just wrong.
>
> I assume that the while (1) loop in ext3_try_to_allocate_with_rsv() has
> gone infinite. I don't see why, but more staring is needed.
>

The loop should not go forever, it will stops when there is no window
with free bit to reserve in the given block group.

> What lock protects the fields in struct ext[234]_reserve_window from being
> concurrently modified by two CPUs? None, it seems. Ditto
> ext[234]_reserve_window_node. i_mutex will cover it for write(), but not
> for pageout over a file hole. If we end up with a zero- or negative-sized
> window then odd things might happen.
>

Yes, trucate_mutex protect both struct ext[234]_reserve_window and ext
[234]_reserve_window_node, and struct ext[234]_block_alloc_info.
Actually I think truncate_mutex protects all data structures related to
block allocation/mapping structures.

Mingming

2006-11-16 20:39:46

[permalink] [raw]

Subject: Re: 2.6.19-rc5-mm2

On Thu, Nov 16, 2006 at 07:29:35PM +0100, Stefan Richter wrote:
> Mattia Dongili wrote:
> > got the following when removing ohci1394 (also happens in -mm1),
> ...
> > ieee1394: Node removed: ID:BUS[0-00:1023] GUID[080046030227e7bb]
> > ieee1394: Node removed: ID:BUS[20754571-38:0391] GUID[00000000f8eb5067]
>
> Hm, there is garbage in this node data. Moreover, your full logs show
> that there was never another node added besides the host node. IOW the
> second "Node removed" line shouldn't be there. Very strange.
>
> > BUG: unable to handle kernel NULL pointer dereference at virtual address 000000a4
> ...
> > EIP is at class_device_remove_attrs+0xd/0x34
> ...
>
> Could you also test one or even better both of:
> - 2.6.19-rc5 plus
> http://me.in-berlin.de/~s5r6/linux1394/updates/2.6.19-rc5/2.6.19-rc5_ieee1394_v204_experimental.patch.bz2
> (these are the same FireWire drivers as in -rc5-mm2)

the oops disappear

> and/ or
> - 2.6.19-rc5-mm2 minus
> http://www.it.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.19-rc5/2.6.19-rc5-mm2/broken-out/git-ieee1394.patch

the oops is there again.
I suppose git-ieee1394 is the one then...

dmesg:
http://oioio.altervista.org/linux/2.6.19-rc5-test1-ok
http://oioio.altervista.org/linux/2.6.19-rc5-mm2-1-ko

next step (smells like bisection) if for tomorrow :)
--
mattia
:wq!

2006-11-16 21:27:42

[permalink] [raw]

Subject: Re: Boot failure with ext2 and initrds

On Thu, 16 Nov 2006 12:15:16 -0800
Mingming Cao <[email protected]> wrote:

> On Thu, 2006-11-16 at 01:13 -0800, Andrew Morton wrote:
> > On Thu, 16 Nov 2006 00:49:20 -0800
> > Mingming Cao <[email protected]> wrote:
> >
> > > On Wed, 2006-11-15 at 23:22 -0800, Andrew Morton wrote:
> > > > On Wed, 15 Nov 2006 22:55:43 -0800
> > > > Mingming Cao <[email protected]> wrote:
> > > >
> > > > > Hmm, maxblocks, in bitmap_search_next_usable_block(), is the end block
> > > > > number of the range to search, not the lengh of the range. maxblocks
> > > > > get passed to ext2_find_next_zero_bit(), where it expecting to take the
> > > > > _size_ of the range to search instead...
> > > > >
> > > > > Something like this: (this is not a patch)
> > > > > @@ -524,7 +524,7 @@ bitmap_search_next_usable_block(ext2_grp
> > > > > ext2_grpblk_t next;
> > > > >
> > > > > - next = ext2_find_next_zero_bit(bh->b_data, maxblocks, start);
> > > > > + next = ext2_find_next_zero_bit(bh->b_data, maxblocks-start + 1, start);
> > > > > if (next >= maxblocks)
> > > > > return -1;
> > > > > return next;
> > > > > }
> > > >
> > > > yes, the `size' arg to find_next_zero_bit() represents the number of bits
> > > > to scan at `offset'.
> > > >
> > > > So I think your change is correctish. But we don't want the "+ 1", do we?
> > > >
> > > I think we still need the "+1", maxblocks here is the ending block of
> > > the reservation window, so the number of bits to scan =end-start+1.
> > >
> > > > If we're right then this bug could cause the code to scan off the end of the
> > > > bitmap. But it won't explain Hugh's bug, because of the if (next >= maxblocks).
> > > >
> > >
> > > Yeah.. at first I thought it might be related, then, thinked it over,
> > > the bug only makes the bits to scan larger, so if find_next_zero_bit()
> > > returns something off the end of bitmap, that is fine, it just
> > > indicating that there is no free bit left in the rest of bitmap, which
> > > is expected behavior. So bitmap_search_next_usable_block() fail is the
> > > expected. It will move on to next block group and try to create a new
> > > reservation window there.
> >
> > I wonder why it's never oopsed. Perhaps there's always a zero in there for
> > some reason.
> >
>
> Why you think it should oopsed? Even if find_next_zero_bit() finds a
> zero bit beyond of the end of bitmap, the check next > maxblocks will
> catch this and make sure we are not taking a zero bit out of the bitmap
> range, so it fails as expected.

If it can read off the end of the buffer, it can oops. With
CONFIG_DEBUG_PAGEALLOC, especially.

> > > That does not explain the repeated reservation window add and remove
> > > behavior Huge has reported.
> >
> > I spent quite some time comparing with ext3. I'm a bit stumped and I'm
> > suspecting that the simplistic porting the code is now OK, but something's
> > just wrong.
> >
> > I assume that the while (1) loop in ext3_try_to_allocate_with_rsv() has
> > gone infinite. I don't see why, but more staring is needed.
> >
>
> The loop should not go forever, it will stops when there is no window
> with free bit to reserve in the given block group.

It seems to have done so in Hugh's testing, but there's some question there
now. Although I didn't check to see if there's a significant difference
between Hugh's patch and mine.

> > What lock protects the fields in struct ext[234]_reserve_window from being
> > concurrently modified by two CPUs? None, it seems. Ditto
> > ext[234]_reserve_window_node. i_mutex will cover it for write(), but not
> > for pageout over a file hole. If we end up with a zero- or negative-sized
> > window then odd things might happen.
> >
>
> Yes, trucate_mutex protect both struct ext[234]_reserve_window and ext
> [234]_reserve_window_node, and struct ext[234]_block_alloc_info.
> Actually I think truncate_mutex protects all data structures related to
> block allocation/mapping structures.

Yes. I guess ext2 needs a new mutex for this. Sad.

2006-11-16 22:51:19

[permalink] [raw]

Subject: Re: 2.6.19-rc5-mm2

Mattia Dongili wrote:
> On Thu, Nov 16, 2006 at 07:29:35PM +0100, Stefan Richter wrote:
>> Could you also test one or even better both of:
>> - 2.6.19-rc5 plus
>> http://me.in-berlin.de/~s5r6/linux1394/updates/2.6.19-rc5/2.6.19-rc5_ieee1394_v204_experimental.patch.bz2
>> (these are the same FireWire drivers as in -rc5-mm2)
>
> the oops disappear
>
>> and/ or
>> - 2.6.19-rc5-mm2 minus
>> http://www.it.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.19-rc5/2.6.19-rc5-mm2/broken-out/git-ieee1394.patch
>
> the oops is there again.
> I suppose git-ieee1394 is the one then...

On the contrary, it's very likely _not_ git-ieee1394.

> dmesg:
> http://oioio.altervista.org/linux/2.6.19-rc5-test1-ok
> http://oioio.altervista.org/linux/2.6.19-rc5-mm2-1-ko

I will look at it tomorrow.

> next step (smells like bisection) if for tomorrow :)

Unless you are eager to get results faster, let me think about where
this superfluous node_entry could come from. Perhaps a run-time test of
-mm by myself is in order; I am currently on 2.6.19-rc4 plus that patch
at me.in-berlin.de. Could spare you a lot of time if I find out more. :-)

Thanks for the help,
--
Stefan Richter
-=====-=-==- =-== =----
http://arcgraph.de/sr/

2006-11-17 01:19:50

[permalink] [raw]

Subject: [-mm patch] make drivers/base/core.c:setup_parent() static

This patch makes the needlessly global setup_parent() static.

Signed-off-by: Adrian Bunk <[email protected]>

--- linux-2.6.19-rc5-mm2/drivers/base/core.c.old 2006-11-16 23:14:44.000000000 +0100
+++ linux-2.6.19-rc5-mm2/drivers/base/core.c 2006-11-16 23:14:56.000000000 +0100
@@ -389,7 +389,7 @@
}

#ifdef CONFIG_SYSFS_DEPRECATED
-int setup_parent(struct device *dev, struct device *parent)
+static int setup_parent(struct device *dev, struct device *parent)
{
/* Set the parent to the class, not the parent device */
/* this keeps sysfs from having a symlink to make old udevs happy */
@@ -418,7 +418,7 @@
return 0;
}

-int setup_parent(struct device *dev, struct device *parent)
+static int setup_parent(struct device *dev, struct device *parent)
{
int error;

2006-11-17 01:20:03

[permalink] [raw]

Subject: [-mm patch] make drivers/acpi/bay.c:drive_bays static

On Tue, Nov 14, 2006 at 01:41:25AM -0800, Andrew Morton wrote:
>...
> Changes since 2.6.19-rc5-mm2:
>...
> git-acpi.patch
>...
> git trees
>...

This patch makes the needlessly global "drive_bays" static.

Signed-off-by: Adrian Bunk <[email protected]>

--- linux-2.6.19-rc5-mm2/drivers/acpi/bay.c.old 2006-11-16 23:03:28.000000000 +0100
+++ linux-2.6.19-rc5-mm2/drivers/acpi/bay.c 2006-11-16 23:03:38.000000000 +0100
@@ -70,7 +70,7 @@
struct proc_dir_entry *proc;
};

-LIST_HEAD(drive_bays);
+static LIST_HEAD(drive_bays);

static struct proc_dir_entry *acpi_bay_dir;

2006-11-17 01:19:31

[permalink] [raw]

Subject: [-mm patch] crypto/xcbc.c: make some code static

On Tue, Nov 14, 2006 at 01:41:25AM -0800, Andrew Morton wrote:
>...
> Changes since 2.6.19-rc5-mm2:
>...
> git-cryptodev.patch
>...
> git trees
>...

This patch makes some needlessly global code static.

Signed-off-by: Adrian Bunk <[email protected]>

---

crypto/xcbc.c | 14 ++++++++------
1 file changed, 8 insertions(+), 6 deletions(-)

--- linux-2.6.19-rc5-mm2/crypto/xcbc.c.old 2006-11-16 22:56:01.000000000 +0100
+++ linux-2.6.19-rc5-mm2/crypto/xcbc.c 2006-11-16 22:57:12.000000000 +0100
@@ -28,9 +28,9 @@
#include <linux/scatterlist.h>
#include "internal.h"

-u_int32_t ks[12] = {0x01010101, 0x01010101, 0x01010101, 0x01010101,
- 0x02020202, 0x02020202, 0x02020202, 0x02020202,
- 0x03030303, 0x03030303, 0x03030303, 0x03030303};
+static u_int32_t ks[12] = {0x01010101, 0x01010101, 0x01010101, 0x01010101,
+ 0x02020202, 0x02020202, 0x02020202, 0x02020202,
+ 0x03030303, 0x03030303, 0x03030303, 0x03030303};
/*
* +------------------------
* | <parent tfm>
@@ -96,7 +96,7 @@
return _crypto_xcbc_digest_setkey(parent, ctx);
}

-int crypto_xcbc_digest_init(struct hash_desc *pdesc)
+static int crypto_xcbc_digest_init(struct hash_desc *pdesc)
{
struct crypto_xcbc_ctx *ctx = crypto_hash_ctx_aligned(pdesc->tfm);
int bs = crypto_hash_blocksize(pdesc->tfm);
@@ -108,7 +108,9 @@
return 0;
}

-int crypto_xcbc_digest_update(struct hash_desc *pdesc, struct scatterlist *sg, unsigned int nbytes)
+static int crypto_xcbc_digest_update(struct hash_desc *pdesc,
+ struct scatterlist *sg,
+ unsigned int nbytes)
{
struct crypto_hash *parent = pdesc->tfm;
struct crypto_xcbc_ctx *ctx = crypto_hash_ctx_aligned(parent);
@@ -181,7 +183,7 @@
return 0;
}

-int crypto_xcbc_digest_final(struct hash_desc *pdesc, u8 *out)
+static int crypto_xcbc_digest_final(struct hash_desc *pdesc, u8 *out)
{
struct crypto_hash *parent = pdesc->tfm;
struct crypto_xcbc_ctx *ctx = crypto_hash_ctx_aligned(parent);

2006-11-17 01:20:54

[permalink] [raw]

Subject: [-mm patch] make geode_aes_crypt() static

On Tue, Nov 14, 2006 at 01:41:25AM -0800, Andrew Morton wrote:
>...
> Changes since 2.6.19-rc5-mm2:
>...
> git-cryptodev.patch
>...
> git trees
>...

This patch makes the needlessly global geode_aes_crypt() static.

Signed-off-by: Adrian Bunk <[email protected]>

---

drivers/crypto/geode-aes.c | 2 +-
drivers/crypto/geode-aes.h | 2 --
2 files changed, 1 insertion(+), 3 deletions(-)

--- linux-2.6.19-rc5-mm2/drivers/crypto/geode-aes.h.old 2006-11-16 23:17:43.000000000 +0100
+++ linux-2.6.19-rc5-mm2/drivers/crypto/geode-aes.h 2006-11-16 23:17:57.000000000 +0100
@@ -37,6 +37,4 @@
u8 iv[AES_IV_LENGTH];
};

-unsigned int geode_aes_crypt(struct geode_aes_op *);
-
#endif
--- linux-2.6.19-rc5-mm2/drivers/crypto/geode-aes.c.old 2006-11-16 23:17:12.000000000 +0100
+++ linux-2.6.19-rc5-mm2/drivers/crypto/geode-aes.c 2006-11-16 23:17:38.000000000 +0100
@@ -97,7 +97,7 @@
return counter ? 0 : 1;
}

-unsigned int
+static unsigned int
geode_aes_crypt(struct geode_aes_op *op)
{

2006-11-17 02:44:26

by Herbert Xu

[permalink] [raw]

Subject: Re: [-mm patch] crypto/xcbc.c: make some code static

On Fri, Nov 17, 2006 at 02:19:29AM +0100, Adrian Bunk wrote:
> On Tue, Nov 14, 2006 at 01:41:25AM -0800, Andrew Morton wrote:
> >...
> > Changes since 2.6.19-rc5-mm2:
> >...
> > git-cryptodev.patch
> >...
> > git trees
> >...
>
> This patch makes some needlessly global code static.
>
> Signed-off-by: Adrian Bunk <[email protected]>

Both patches applied. Thanks Adrian.
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

2006-11-17 07:16:52

[permalink] [raw]

Subject: Re: 2.6.19-rc5-mm2

On Thu, Nov 16, 2006 at 11:50:48PM +0100, Stefan Richter wrote:
> Mattia Dongili wrote:
> > On Thu, Nov 16, 2006 at 07:29:35PM +0100, Stefan Richter wrote:
> >> Could you also test one or even better both of:
> >> - 2.6.19-rc5 plus
> >> http://me.in-berlin.de/~s5r6/linux1394/updates/2.6.19-rc5/2.6.19-rc5_ieee1394_v204_experimental.patch.bz2
> >> (these are the same FireWire drivers as in -rc5-mm2)
> >
> > the oops disappear
> >
> >> and/ or
> >> - 2.6.19-rc5-mm2 minus
> >> http://www.it.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.19-rc5/2.6.19-rc5-mm2/broken-out/git-ieee1394.patch
> >
> > the oops is there again.
> > I suppose git-ieee1394 is the one then...
>
> On the contrary, it's very likely _not_ git-ieee1394.

yup, sorry. That's exactly what I ordered my fingers to type... (damn
fingers).

> > dmesg:
> > http://oioio.altervista.org/linux/2.6.19-rc5-test1-ok
> > http://oioio.altervista.org/linux/2.6.19-rc5-mm2-1-ko
>
> I will look at it tomorrow.
>
> > next step (smells like bisection) if for tomorrow :)
>
> Unless you are eager to get results faster, let me think about where
> this superfluous node_entry could come from. Perhaps a run-time test of
> -mm by myself is in order; I am currently on 2.6.19-rc4 plus that patch
> at me.in-berlin.de. Could spare you a lot of time if I find out more. :-)

No problems, I can wait :) After all I don't have any ieee1394 device
(that's why I was rmmod-ing modules :))
If needed feel free to ask me for a bisection.

--
mattia
:wq!

2006-11-17 12:42:40

[permalink] [raw]

Subject: -mm: cx88-blackbird.c: unused code re-added

On Tue, Nov 14, 2006 at 01:41:25AM -0800, Andrew Morton wrote:
>...
> Changes since 2.6.19-rc5-mm2:
>...
> git-dvb.patch
>...
> git trees
>...

Why does this patch re-add the still unused cx88_ioctl_hook and
cx88_ioctl_translator in drivers/media/video/cx88/cx88-blackbird.c
I removed a few months ago?

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

2006-11-17 13:53:57

by Michael Ira Krufky

[permalink] [raw]

Subject: Re: [v4l-dvb-maintainer] -mm: cx88-blackbird.c: unused code re-added

Adrian Bunk wrote:

>On Tue, Nov 14, 2006 at 01:41:25AM -0800, Andrew Morton wrote:
>
>
>>...
>>Changes since 2.6.19-rc5-mm2:
>>...
>> git-dvb.patch
>>...
>> git trees
>>...
>>
>>
>
>Why does this patch re-add the still unused cx88_ioctl_hook and
>cx88_ioctl_translator in drivers/media/video/cx88/cx88-blackbird.c
>I removed a few months ago?
>

Adrian,

I have added those hooks back into the driver, because they are needed
for the cx88-ivtv ioctl emulation layer. However, I have instructed
Mauro not to merge that patch upstream -- it is meant to stay at our
mercurial repository only, since the vanilla kernel does not need to use
the cx88-ivtv ioctl emulation layer.

It looks like somehow these got into -mm ... I think that is because
Andrew's scripts pull from Mauro's devel branch in his git tree.

The problem commit is: de513acdbafc48c52017255fee02af727dcfcc32

It appears that Mauro has folded my patch into Steve's patch, which he
should not have done. :-( What a mess!

I will send a new patch to Mauro later on today to be applied to his git
devel branch, which will remove those hooks again.

As soon as ivtv gets merged into our tree, that's when we will be able
to remove cx88-ivtv alltogether, as there will no longer be any need to
support the ivtv API.

regards,

Mike Krufky

2006-11-17 13:56:17

by Reuben Farrelly

[permalink] [raw]

Subject: Re: [PATCH 2.6.19-rc5-mm2] cpufreq: set policy->curfreq on initialization

On 16/11/2006 6:05 AM, Mattia Dongili wrote:
> Check the correct variable and set policy->cur upon acpi-cpufreq
> initialization to allow the userspace governor to be used as default.
>
> Signed-off-by: Mattia Dongili <[email protected]>
>
> ---
>
> Reuben, could you also try if this patch fixes the BUG()?
> Thanks

It does, and all looks fine now, thanks. Sorry for not getting back about it a
little earlier.

Reuben

> diff --git a/arch/i386/kernel/cpu/cpufreq/acpi-cpufreq.c b/arch/i386/kernel/cpu/cpufreq/acpi-cpufreq.c
> index 18f4715..a630f94 100644
> --- a/arch/i386/kernel/cpu/cpufreq/acpi-cpufreq.c
> +++ b/arch/i386/kernel/cpu/cpufreq/acpi-cpufreq.c
> @@ -699,14 +699,14 @@ static int acpi_cpufreq_cpu_init(struct
> if (result)
> goto err_freqfree;
>
> - switch (data->cpu_feature) {
> + switch (perf->control_register.space_id) {
> case ACPI_ADR_SPACE_SYSTEM_IO:
> /* Current speed is unknown and not detectable by IO port */
> policy->cur = acpi_cpufreq_guess_freq(data, policy->cpu);
> break;
> case ACPI_ADR_SPACE_FIXED_HARDWARE:
> acpi_cpufreq_driver.get = get_cur_freq_on_cpu;
> - get_cur_freq_on_cpu(cpu);
> + policy->cur = get_cur_freq_on_cpu(cpu);
> break;
> default:
> break;

2006-11-17 14:01:48

by Pallipadi, Venkatesh

[permalink] [raw]

Subject: RE: [PATCH 2.6.19-rc5-mm2] cpufreq: set policy->curfreq on initialization

Acked.
Andrew: Please include this patch in mm.

Thanks,
Venki

>-----Original Message-----
>From: Mattia Dongili [mailto:[email protected]]
>Sent: Wednesday, November 15, 2006 11:05 AM
>To: Pallipadi, Venkatesh; [email protected]; Reuben Farrelly;
>Andrew Morton; [email protected]; [email protected];
>CPUFreq Mailing List; Sadykov, Denis M
>Subject: [PATCH 2.6.19-rc5-mm2] cpufreq: set policy->curfreq
>on initialization
>
>
>Check the correct variable and set policy->cur upon acpi-cpufreq
>initialization to allow the userspace governor to be used as default.
>
>Signed-off-by: Mattia Dongili <[email protected]>
>
>---
>
>Reuben, could you also try if this patch fixes the BUG()?
>Thanks
>
>diff --git a/arch/i386/kernel/cpu/cpufreq/acpi-cpufreq.c
>b/arch/i386/kernel/cpu/cpufreq/acpi-cpufreq.c
>index 18f4715..a630f94 100644
>--- a/arch/i386/kernel/cpu/cpufreq/acpi-cpufreq.c
>+++ b/arch/i386/kernel/cpu/cpufreq/acpi-cpufreq.c
>@@ -699,14 +699,14 @@ static int acpi_cpufreq_cpu_init(struct
> if (result)
> goto err_freqfree;
>
>- switch (data->cpu_feature) {
>+ switch (perf->control_register.space_id) {
> case ACPI_ADR_SPACE_SYSTEM_IO:
> /* Current speed is unknown and not detectable
>by IO port */
> policy->cur = acpi_cpufreq_guess_freq(data,
>policy->cpu);
> break;
> case ACPI_ADR_SPACE_FIXED_HARDWARE:
> acpi_cpufreq_driver.get = get_cur_freq_on_cpu;
>- get_cur_freq_on_cpu(cpu);
>+ policy->cur = get_cur_freq_on_cpu(cpu);
> break;
> default:
> break;
>

2006-11-17 14:14:36

by Mauro Carvalho Chehab

[permalink] [raw]

Subject: Re: [v4l-dvb-maintainer] -mm: cx88-blackbird.c: unused code re-added

Hi Adrian,

Em Sex, 2006-11-17 ?s 13:42 +0100, Adrian Bunk escreveu:
> On Tue, Nov 14, 2006 at 01:41:25AM -0800, Andrew Morton wrote:
> >...
> > Changes since 2.6.19-rc5-mm2:
> >...
> > git-dvb.patch
> >...
> > git trees
> >...
>
> Why does this patch re-add the still unused cx88_ioctl_hook and
> cx88_ioctl_translator in drivers/media/video/cx88/cx88-blackbird.c
> I removed a few months ago?
Hmm... I think I sent to my -git the patch that reenables it.

Let me explain a little bit about those hooks.

As you know, ivtv is being re-worked to be inserted at kernel. This
includes a complete API review of several ivtv calls. Some of they were
providing stuff already at V4L2 API, but implemented on a different way.
This turned into a huge project, being delayed with the first scheduling
time. First, we've migrated all i2c drivers. Then mpeg decoding. Now, we
are working at mpeg encoding part.

cx88-blackbird provides mpeg outputs for analog tv, in a similar way as
ivtv devices. However, some userspace apps were not implementing the
experimental mpeg support added at V4L2 api for mpeg streams, but
instead, were using an API developed for ivtv.

We received a patch for a cx88-ivtv module that allows using
ivtv-enabled programs to work with cx88-blackbird.

To avoid causing later regressions of removing IVTV API calls from
kernel, we decided to create the hooks at kernel, and having cx88-ivtv
only at v4l-dvb tree. The proper API calls will be added as soon as ivtv
driver will be finished and the proper api is available to be
incorporated at cx88-blackbird.

Anyway, I've redesigned cx88 to use video_ioctl2 interface, who is
incompatible with the hooks. The newer approach is at:
http://www.linuxtv.org/hg/~mchehab/cx88_ioctls

After merging this branch into the v4l-dvb tree, the patches will be
removed. I intend to apply those changes to 2.6.20, so, there's no need
to worry about this stuff.

>
> cu
> Adrian
>
Cheers,
Mauro.

2006-11-17 14:21:17

[permalink] [raw]

Subject: [-mm patch] drivers/media/video/cafe_ccic.c: make a function static

On Tue, Nov 14, 2006 at 01:41:25AM -0800, Andrew Morton wrote:
>...
> Changes since 2.6.19-rc5-mm2:
>...
> git-dvb.patch
>...
> git trees
>...

This patch makes the needlessly global cafe_v4l_dev_release() static.

Signed-off-by: Adrian Bunk <[email protected]>

--- linux-2.6.19-rc5-mm2/drivers/media/video/cafe_ccic.c.old 2006-11-17 13:13:44.000000000 +0100
+++ linux-2.6.19-rc5-mm2/drivers/media/video/cafe_ccic.c 2006-11-17 13:13:57.000000000 +0100
@@ -1688,7 +1688,7 @@
};

-void cafe_v4l_dev_release(struct video_device *vd)
+static void cafe_v4l_dev_release(struct video_device *vd)
{
struct cafe_camera *cam = container_of(vd, struct cafe_camera, v4ldev);

2006-11-17 14:21:48

[permalink] [raw]

Subject: [-mm patch] remove drivers/pci/search.c:pci_find_device_reverse()

This patch removes the no longer used pci_find_device_reverse().

Signed-off-by: Adrian Bunk <[email protected]>

---

drivers/pci/search.c | 38 --------------------------------------
include/linux/pci.h | 1 -
2 files changed, 39 deletions(-)

--- linux-2.6.19-rc5-mm2/include/linux/pci.h.old 2006-11-17 13:52:21.000000000 +0100
+++ linux-2.6.19-rc5-mm2/include/linux/pci.h 2006-11-17 13:52:30.000000000 +0100
@@ -442,7 +442,6 @@
/* Generic PCI functions exported to card drivers */

struct pci_dev *pci_find_device (unsigned int vendor, unsigned int device, const struct pci_dev *from);
-struct pci_dev *pci_find_device_reverse (unsigned int vendor, unsigned int device, const struct pci_dev *from);
struct pci_dev *pci_find_slot (unsigned int bus, unsigned int devfn);
int pci_find_capability (struct pci_dev *dev, int cap);
int pci_find_next_capability (struct pci_dev *dev, u8 pos, int cap);
--- linux-2.6.19-rc5-mm2/drivers/pci/search.c.old 2006-11-17 13:52:38.000000000 +0100
+++ linux-2.6.19-rc5-mm2/drivers/pci/search.c 2006-11-17 13:52:52.000000000 +0100
@@ -340,43 +340,6 @@
}

/**
- * pci_find_device_reverse - begin or continue searching for a PCI device by vendor/device id
- * @vendor: PCI vendor id to match, or %PCI_ANY_ID to match all vendor ids
- * @device: PCI device id to match, or %PCI_ANY_ID to match all device ids
- * @from: Previous PCI device found in search, or %NULL for new search.
- *
- * Iterates through the list of known PCI devices in the reverse order of
- * pci_find_device().
- * If a PCI device is found with a matching @vendor and @device, a pointer to
- * its device structure is returned. Otherwise, %NULL is returned.
- * A new search is initiated by passing %NULL as the @from argument.
- * Otherwise if @from is not %NULL, searches continue from previous device
- * on the global list.
- */
-struct pci_dev *
-pci_find_device_reverse(unsigned int vendor, unsigned int device, const struct pci_dev *from)
-{
- struct list_head *n;
- struct pci_dev *dev;
-
- WARN_ON(in_interrupt());
- down_read(&pci_bus_sem);
- n = from ? from->global_list.prev : pci_devices.prev;
-
- while (n && (n != &pci_devices)) {
- dev = pci_dev_g(n);
- if ((vendor == PCI_ANY_ID || dev->vendor == vendor) &&
- (device == PCI_ANY_ID || dev->device == device))
- goto exit;
- n = n->prev;
- }
- dev = NULL;
-exit:
- up_read(&pci_bus_sem);
- return dev;
-}
-
-/**
* pci_get_class - begin or continue searching for a PCI device by class
* @class: search for a PCI device with this class designation
* @from: Previous PCI device found in search, or %NULL for new search.
@@ -447,7 +410,6 @@
EXPORT_SYMBOL(pci_dev_present);

EXPORT_SYMBOL(pci_find_device);
-EXPORT_SYMBOL(pci_find_device_reverse);
EXPORT_SYMBOL(pci_find_slot);
/* For boot time work */
EXPORT_SYMBOL(pci_find_bus);

2006-11-17 14:33:57

by Alan Cox

[permalink] [raw]

Subject: Re: [-mm patch] remove drivers/pci/search.c:pci_find_device_reverse()

On Fri, Nov 17, 2006 at 03:21:45PM +0100, Adrian Bunk wrote:
> This patch removes the no longer used pci_find_device_reverse().
>
> Signed-off-by: Adrian Bunk <[email protected]>

Acked-by: Alan Cox <[email protected]>

Soon we should deprecate pci_find_device as well

2006-11-17 15:02:17

[permalink] [raw]

Subject: Re: 2.6.19-rc5-mm2

Mattia Dongili wrote:
>>> http://oioio.altervista.org/linux/2.6.19-rc5-mm2-1-ko
and
http://oioio.altervista.org/linux/config-2.6.19-rc5-mm2-1
| # CONFIG_SYSFS_DEPRECATED is not set

| ieee1394: Node removed: ID:BUS[0-00:1023] GUID[080046030227e7bb]
| ieee1394: Node removed: ID:BUS[20754571-38:0455] GUID[00000000f8ee6067]
| BUG: unable to handle kernel NULL pointer dereference at virtual
address 000000a4
| printing eip:
| c0238c60
| *pde = 00000000
| Oops: 0000 [#1]
| SMP
| last sysfs file: /devices/pci0000:00/0000:00:00.0/class
[...]
| EIP is at class_device_remove_attrs+0xd/0x34
| eax: f7e02b8c ebx: 00000000 ecx: ffffffff edx: 00000000
| esi: 00000000 edi: f7e02b8c ebp: f7629e04 esp: f7629df8
| ds: 007b es: 007b ss: 0068
| Process rmmod (pid: 2419, ti=f7628000 task=f702a550 task.ti=f7628000)
| Stack: f7e02b8c f7e02b94 00000000 f7629e20 c0238d47 00000000 f7e02a30
f7e02b8c
| f7e02a30 00000000 f7629e2c c0238d82 f7e029f4 f7629e54 f8d5da3d
f8d63087
| 013cb08b 00000026 000001c7 f8ee6067 00000000 00000000 f8d5da52
f7629e5c
| Call Trace:
| [<c0238d47>] class_device_del+0xc0/0xf0
| [<c0238d82>] class_device_unregister+0xb/0x15
| [<f8d5da3d>] nodemgr_remove_ne+0x64/0x79 [ieee1394]
| [<f8d5da5d>] __nodemgr_remove_host_dev+0xb/0xf [ieee1394]
| [<c02366dc>] device_for_each_child+0x1d/0x46
| [<f8d5dd82>] nodemgr_remove_host+0x36/0x5d [ieee1394]
| [<f8d5b4f3>] __unregister_host+0x1b/0x9c [ieee1394]
| [<f8d5b70b>] highlevel_remove_host+0x24/0x47 [ieee1394]
| [<f8d5b14f>] hpsb_remove_host+0x3b/0x5c [ieee1394]
| [<f8dcbf9d>] ohci1394_pci_remove+0x47/0x1c7 [ohci1394]
| [<c01dd619>] pci_device_remove+0x19/0x39

Either the FireWire host's device->klist_children was overwritten before
the call to device_for_each_child (perhaps nodemgr didn't hold a
reference which it should have), or/and all of this is an issue with the
ongoing migration away from class_device.
--
Stefan Richter
-=====-=-==- =-== =---=
http://arcgraph.de/sr/

2006-11-17 15:24:30

[permalink] [raw]

Subject: Re: 2.6.19-rc5-mm2 (Oops in class_device_remove_attrs during nodemgr_remove_host)

I wrote:
> Mattia Dongili wrote:
>>>> http://oioio.altervista.org/linux/2.6.19-rc5-mm2-1-ko
> and
> http://oioio.altervista.org/linux/config-2.6.19-rc5-mm2-1
> | # CONFIG_SYSFS_DEPRECATED is not set
>
> | ieee1394: Node removed: ID:BUS[0-00:1023] GUID[080046030227e7bb]
> | ieee1394: Node removed: ID:BUS[20754571-38:0455] GUID[00000000f8ee6067]
> | BUG: unable to handle kernel NULL pointer dereference at virtual
> address 000000a4
> | printing eip:
> | c0238c60
> | *pde = 00000000
> | Oops: 0000 [#1]
> | SMP
> | last sysfs file: /devices/pci0000:00/0000:00:00.0/class
> [...]
> | EIP is at class_device_remove_attrs+0xd/0x34
> | eax: f7e02b8c ebx: 00000000 ecx: ffffffff edx: 00000000
> | esi: 00000000 edi: f7e02b8c ebp: f7629e04 esp: f7629df8
> | ds: 007b es: 007b ss: 0068
> | Process rmmod (pid: 2419, ti=f7628000 task=f702a550 task.ti=f7628000)
> | Stack: f7e02b8c f7e02b94 00000000 f7629e20 c0238d47 00000000 f7e02a30
> f7e02b8c
> | f7e02a30 00000000 f7629e2c c0238d82 f7e029f4 f7629e54 f8d5da3d
> f8d63087
> | 013cb08b 00000026 000001c7 f8ee6067 00000000 00000000 f8d5da52
> f7629e5c
> | Call Trace:
> | [<c0238d47>] class_device_del+0xc0/0xf0
> | [<c0238d82>] class_device_unregister+0xb/0x15
> | [<f8d5da3d>] nodemgr_remove_ne+0x64/0x79 [ieee1394]
> | [<f8d5da5d>] __nodemgr_remove_host_dev+0xb/0xf [ieee1394]
> | [<c02366dc>] device_for_each_child+0x1d/0x46
> | [<f8d5dd82>] nodemgr_remove_host+0x36/0x5d [ieee1394]
> | [<f8d5b4f3>] __unregister_host+0x1b/0x9c [ieee1394]
> | [<f8d5b70b>] highlevel_remove_host+0x24/0x47 [ieee1394]
> | [<f8d5b14f>] hpsb_remove_host+0x3b/0x5c [ieee1394]
> | [<f8dcbf9d>] ohci1394_pci_remove+0x47/0x1c7 [ohci1394]
> | [<c01dd619>] pci_device_remove+0x19/0x39
>
> Either the FireWire host's device->klist_children was overwritten before
> the call to device_for_each_child

or *during* the run of device_for_each_child, which first successfully
called nodemgr_remove_ne for node [0-00:1023] but then stumbled over the
false node [20754571-38:0455].

> (perhaps nodemgr didn't hold a reference which it should have), or/and
> all of this is an issue with the ongoing migration away from class_device.

--
Stefan Richter
-=====-=-==- =-== =---=
http://arcgraph.de/sr/

2006-11-17 17:02:10

[permalink] [raw]

Subject: [-mm patch] make net/core/skbuff.c:skb_over_panic() static

skb_over_panic() can now become static.

Signed-off-by: Adrian Bunk <[email protected]>

---

Note:
This patch depends on net-uninline-skb_put.patch.

include/linux/skbuff.h | 2 --
net/core/skbuff.c | 3 +--
2 files changed, 1 insertion(+), 4 deletions(-)

--- linux-2.6.19-rc5-mm2/include/linux/skbuff.h.old 2006-11-17 15:24:22.000000000 +0100
+++ linux-2.6.19-rc5-mm2/include/linux/skbuff.h 2006-11-17 15:24:31.000000000 +0100
@@ -364,8 +364,6 @@ extern struct sk_buff *skb_copy_expand(c
gfp_t priority);
extern int skb_pad(struct sk_buff *skb, int pad);
#define dev_kfree_skb(a) kfree_skb(a)
-extern void skb_over_panic(struct sk_buff *skb, int len,
- void *here);
extern void skb_under_panic(struct sk_buff *skb, int len,
void *here);
extern void skb_truesize_bug(struct sk_buff *skb);
--- linux-2.6.19-rc5-mm2/net/core/skbuff.c.old 2006-11-17 15:24:38.000000000 +0100
+++ linux-2.6.19-rc5-mm2/net/core/skbuff.c 2006-11-17 15:25:09.000000000 +0100
@@ -84,7 +84,7 @@ static kmem_cache_t *skbuff_fclone_cache
*
* Out of line support code for skb_put(). Not user callable.
*/
-void skb_over_panic(struct sk_buff *skb, int sz, void *here)
+static void skb_over_panic(struct sk_buff *skb, int sz, void *here)
{
printk(KERN_EMERG "skb_over_panic: text:%p len:%d put:%d head:%p "
"data:%p tail:%p end:%p dev:%s\n",
@@ -2094,7 +2094,6 @@ EXPORT_SYMBOL(skb_copy_and_csum_bits);
EXPORT_SYMBOL(skb_copy_and_csum_dev);
EXPORT_SYMBOL(skb_copy_bits);
EXPORT_SYMBOL(skb_copy_expand);
-EXPORT_SYMBOL(skb_over_panic);
EXPORT_SYMBOL(skb_pad);
EXPORT_SYMBOL(skb_realloc_headroom);
EXPORT_SYMBOL(skb_under_panic);

2006-11-17 17:02:15

[permalink] [raw]

Subject: [-mm patch] security/slim/slm_main.c: make 2 functions static

This patch makes two needlessly global functions static.

Signed-off-by: Adrian Bunk <[email protected]>

---

security/slim/slm_main.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)

--- linux-2.6.19-rc5-mm2/security/slim/slm_main.c.old 2006-11-17 16:42:58.000000000 +0100
+++ linux-2.6.19-rc5-mm2/security/slim/slm_main.c 2006-11-17 16:43:22.000000000 +0100
@@ -967,8 +967,8 @@
* of the current process. This is especially important for objects
* being promoted.
*/
-int slm_inode_setxattr(struct dentry *dentry, char *name, void *value,
- size_t size, int flags)
+static int slm_inode_setxattr(struct dentry *dentry, char *name, void *value,
+ size_t size, int flags)
{
struct slm_tsec_data *cur_tsec = current->security;
char *data = value;
@@ -1075,7 +1075,7 @@
/*
* Opening a socket demotes the integrity of a process to untrusted.
*/
-int slm_socket_create(int family, int type, int protocol, int kern)
+static int slm_socket_create(int family, int type, int protocol, int kern)
{
struct task_struct *parent_tsk;
struct slm_tsec_data *cur_tsec = current->security, *parent_tsec;

2006-11-17 19:57:53

[permalink] [raw]

Subject: Re: [-mm patch] remove drivers/pci/search.c:pci_find_device_reverse()

On Fri, 17 Nov 2006 15:21:45 +0100
Adrian Bunk <[email protected]> wrote:

> This patch removes the no longer used pci_find_device_reverse().

But it is exported to modules.

This is what we created EXPORT_UNUSED_SYMBOL() for.

2006-11-17 20:34:00

[permalink] [raw]

Subject: Re: [-mm patch] remove drivers/pci/search.c:pci_find_device_reverse()

On Fri, Nov 17, 2006 at 11:54:04AM -0800, Andrew Morton wrote:
> On Fri, 17 Nov 2006 15:21:45 +0100
> Adrian Bunk <[email protected]> wrote:
>
> > This patch removes the no longer used pci_find_device_reverse().
>
> But it is exported to modules.
>
> This is what we created EXPORT_UNUSED_SYMBOL() for.

The fact that noone uses it (except for the 8 symbols I marked in June)
might be a good indication that it doesn't fit into the current kernel
development model:
- there is no stable kernel API and
- we lack a strict process for reviewing _every single_ newly added
export - especially the many that get added without any in-kernel user

And if you'd take your EXPORT_UNUSED_SYMBOL() serious, any changes to
the signatures of exported functions had to be strictly forbidden.

Please do either make strong promises about the API for external modules
with all consequences or allow all API changes immediately.

But you currently allowing API changes at any time while putting high
obstacles for my cleanup patches to remove code with zero in-kernel
users is very close to a personal offense.

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

2006-11-17 22:17:29

by Alan Cox

[permalink] [raw]

Subject: Re: [-mm patch] remove drivers/pci/search.c:pci_find_device_reverse()

2006-11-17 23:58:22

[permalink] [raw]

Subject: [-mm patch] make sound/pci/hda/patch_sigmatel.c:stac92xx_dmic_labels[] static

On Tue, Nov 14, 2006 at 01:41:25AM -0800, Andrew Morton wrote:
>...
> Changes since 2.6.19-rc5-mm2:
>...
> git-alsa.patch
>...
> git trees
>...

This patch makes the needlessly global stac92xx_dmic_labels[] static.

Signed-off-by: Adrian Bunk <[email protected]>

--- linux-2.6.19-rc5-mm2/sound/pci/hda/patch_sigmatel.c.old 2006-11-17 18:36:16.000000000 +0100
+++ linux-2.6.19-rc5-mm2/sound/pci/hda/patch_sigmatel.c 2006-11-17 18:36:26.000000000 +0100
@@ -1201,7 +1201,7 @@
}

/* labels for dmic mux inputs */
-const char *stac92xx_dmic_labels[5] = {
+static const char *stac92xx_dmic_labels[5] = {
"Analog Inputs", "Digital Mic 1", "Digital Mic 2",
"Digital Mic 3", "Digital Mic 4"
};

2006-11-17 23:58:27

[permalink] [raw]

Subject: [-mm patch] make mm/thrash.c:global_faults static

This patch makes the needlessly global "global_faults" static.

Signed-off-by: Adrian Bunk <[email protected]>

--- linux-2.6.19-rc5-mm2/mm/thrash.c.old 2006-11-17 18:47:46.000000000 +0100
+++ linux-2.6.19-rc5-mm2/mm/thrash.c 2006-11-17 18:48:06.000000000 +0100
@@ -24,7 +24,7 @@

static DEFINE_SPINLOCK(swap_token_lock);
struct mm_struct *swap_token_mm;
-unsigned int global_faults;
+static unsigned int global_faults;

void grab_swap_token(void)
{

2006-11-18 00:00:29

[permalink] [raw]

Subject: [RFC: -mm patch] make kernel/timer.c:__next_timer_interrupt() static

This patch makes the needlessly global __next_timer_interrupt() static.

Signed-off-by: Adrian Bunk <[email protected]>

--- linux-2.6.19-rc5-mm2/kernel/timer.c.old 2006-11-17 19:11:49.000000000 +0100
+++ linux-2.6.19-rc5-mm2/kernel/timer.c 2006-11-17 19:12:02.000000000 +0100
@@ -621,7 +621,8 @@
* is used on S/390 to stop all activity when a cpus is idle.
* This functions needs to be called disabled.
*/
-unsigned long __next_timer_interrupt(tvec_base_t *base, unsigned long now)
+static unsigned long __next_timer_interrupt(tvec_base_t *base,
+ unsigned long now)
{
struct list_head *list;
struct timer_list *nte, *found = NULL;

2006-11-17 23:59:48

[permalink] [raw]

Subject: [RFC: -mm patch] remove kernel/timer.c:wall_jiffies

"wall_jiffies" was added, but it's completely unused...

Signed-off-by: Adrian Bunk <[email protected]>

--- linux-2.6.19-rc5-mm2/kernel/timer.c.old 2006-11-17 19:09:54.000000000 +0100
+++ linux-2.6.19-rc5-mm2/kernel/timer.c 2006-11-17 19:10:01.000000000 +0100
@@ -42,9 +42,6 @@
#include <asm/timex.h>
#include <asm/io.h>

-/* jiffies at the most recent update of wall time */
-unsigned long wall_jiffies = INITIAL_JIFFIES;
-
u64 jiffies_64 __cacheline_aligned_in_smp = INITIAL_JIFFIES;

EXPORT_SYMBOL(jiffies_64);

2006-11-18 00:12:00

[permalink] [raw]

Subject: [2.6 patch] mark pci_find_device() as __deprecated

On Fri, Nov 17, 2006 at 09:32:36AM -0500, Alan Cox wrote:
> On Fri, Nov 17, 2006 at 03:21:45PM +0100, Adrian Bunk wrote:
> > This patch removes the no longer used pci_find_device_reverse().
> >
> > Signed-off-by: Adrian Bunk <[email protected]>
>
> Acked-by: Alan Cox <[email protected]>
>
> Soon we should deprecate pci_find_device as well

So let's mark it as __deprecated now, which also has the side effect
that noone can later whine that removing it might break some shiny
external modules.

Oh, and if anything starts complaining "But this adds some warnings to
my kernel build!", he should either first fix the 200 kB (sic) of
warnings I'm getting in 2.6.19-rc5-mm2 starting at MODPOST or go to hell.

Signed-off-by: Adrian Bunk <[email protected]>

--- linux-2.6.19-rc5-mm2/include/linux/pci.h.old 2006-11-18 01:03:27.000000000 +0100
+++ linux-2.6.19-rc5-mm2/include/linux/pci.h 2006-11-18 01:05:46.000000000 +0100
@@ -441,7 +441,7 @@

/* Generic PCI functions exported to card drivers */

-struct pci_dev *pci_find_device (unsigned int vendor, unsigned int device, const struct pci_dev *from);
+struct pci_dev __deprecated *pci_find_device (unsigned int vendor, unsigned int device, const struct pci_dev *from);
struct pci_dev *pci_find_slot (unsigned int bus, unsigned int devfn);
int pci_find_capability (struct pci_dev *dev, int cap);
int pci_find_next_capability (struct pci_dev *dev, u8 pos, int cap);

2006-11-18 01:39:22

by Alan

[permalink] [raw]

Subject: Re: [2.6 patch] mark pci_find_device() as __deprecated

On Sat, 18 Nov 2006 01:06:29 +0100
> Oh, and if anything starts complaining "But this adds some warnings to
> my kernel build!", he should either first fix the 200 kB (sic) of
> warnings I'm getting in 2.6.19-rc5-mm2 starting at MODPOST or go to hell.
>
> Signed-off-by: Adrian Bunk <[email protected]>

The only significant user remaining is the old ISDN code so it doesn't
create too many of them.

Acked-by: Alan Cox <[email protected]>

2006-11-18 06:59:39

by Ingo Molnar

[permalink] [raw]

Subject: Re: [RFC: -mm patch] make kernel/timer.c:__next_timer_interrupt() static

* Adrian Bunk <[email protected]> wrote:

> This patch makes the needlessly global __next_timer_interrupt() static.
>
> Signed-off-by: Adrian Bunk <[email protected]>

ok.

Acked-by: Ingo Molnar <[email protected]>

Ingo

2006-11-18 07:01:14

by Ingo Molnar

[permalink] [raw]

Subject: Re: [RFC: -mm patch] remove kernel/timer.c:wall_jiffies

* Adrian Bunk <[email protected]> wrote:

> "wall_jiffies" was added, but it's completely unused...
>
> Signed-off-by: Adrian Bunk <[email protected]>

yeah, that's a merge leftover in:

gtod-persistent-clock-support-core.patch

Acked-by: Ingo Molnar <[email protected]>

Ingo

2006-11-18 10:46:30

by Greg KH

[permalink] [raw]

Subject: Re: 2.6.19-rc5-mm2 (Oops in class_device_remove_attrs during nodemgr_remove_host)

On Fri, Nov 17, 2006 at 04:24:27PM +0100, Stefan Richter wrote:
> I wrote:
> > Mattia Dongili wrote:
> >>>> http://oioio.altervista.org/linux/2.6.19-rc5-mm2-1-ko
> > and
> > http://oioio.altervista.org/linux/config-2.6.19-rc5-mm2-1
> > | # CONFIG_SYSFS_DEPRECATED is not set
> >
> > | ieee1394: Node removed: ID:BUS[0-00:1023] GUID[080046030227e7bb]
> > | ieee1394: Node removed: ID:BUS[20754571-38:0455] GUID[00000000f8ee6067]
> > | BUG: unable to handle kernel NULL pointer dereference at virtual
> > address 000000a4
> > | printing eip:
> > | c0238c60
> > | *pde = 00000000
> > | Oops: 0000 [#1]
> > | SMP
> > | last sysfs file: /devices/pci0000:00/0000:00:00.0/class
> > [...]
> > | EIP is at class_device_remove_attrs+0xd/0x34
> > | eax: f7e02b8c ebx: 00000000 ecx: ffffffff edx: 00000000
> > | esi: 00000000 edi: f7e02b8c ebp: f7629e04 esp: f7629df8
> > | ds: 007b es: 007b ss: 0068
> > | Process rmmod (pid: 2419, ti=f7628000 task=f702a550 task.ti=f7628000)
> > | Stack: f7e02b8c f7e02b94 00000000 f7629e20 c0238d47 00000000 f7e02a30
> > f7e02b8c
> > | f7e02a30 00000000 f7629e2c c0238d82 f7e029f4 f7629e54 f8d5da3d
> > f8d63087
> > | 013cb08b 00000026 000001c7 f8ee6067 00000000 00000000 f8d5da52
> > f7629e5c
> > | Call Trace:
> > | [<c0238d47>] class_device_del+0xc0/0xf0
> > | [<c0238d82>] class_device_unregister+0xb/0x15
> > | [<f8d5da3d>] nodemgr_remove_ne+0x64/0x79 [ieee1394]
> > | [<f8d5da5d>] __nodemgr_remove_host_dev+0xb/0xf [ieee1394]
> > | [<c02366dc>] device_for_each_child+0x1d/0x46
> > | [<f8d5dd82>] nodemgr_remove_host+0x36/0x5d [ieee1394]
> > | [<f8d5b4f3>] __unregister_host+0x1b/0x9c [ieee1394]
> > | [<f8d5b70b>] highlevel_remove_host+0x24/0x47 [ieee1394]
> > | [<f8d5b14f>] hpsb_remove_host+0x3b/0x5c [ieee1394]
> > | [<f8dcbf9d>] ohci1394_pci_remove+0x47/0x1c7 [ohci1394]
> > | [<c01dd619>] pci_device_remove+0x19/0x39
> >
> > Either the FireWire host's device->klist_children was overwritten before
> > the call to device_for_each_child
>
> or *during* the run of device_for_each_child, which first successfully
> called nodemgr_remove_ne for node [0-00:1023] but then stumbled over the
> false node [20754571-38:0455].
>
> > (perhaps nodemgr didn't hold a reference which it should have), or/and
> > all of this is an issue with the ongoing migration away from class_device.

I don't have any firewire class_device migration patches in -mm right
now.

I do have one sitting here if you wish to play around with it, but it
needs some more infrastructure patches that I have not really tested all
that well yet.

Either way, I don't think this is caused by any new class_device
patches, but I'm very willing to be proven wrong :)

thanks,

greg k-h

2006-11-18 11:29:08

[permalink] [raw]

Subject: Re: 2.6.19-rc5-mm2 (Oops in class_device_remove_attrs during nodemgr_remove_host)

Greg KH wrote:
> On Fri, Nov 17, 2006 at 04:24:27PM +0100, Stefan Richter wrote:
>> I wrote:
>>> Either the FireWire host's device->klist_children was overwritten before
>>> the call to device_for_each_child
>> or *during* the run of device_for_each_child, which first successfully
>> called nodemgr_remove_ne for node [0-00:1023] but then stumbled over the
>> false node [20754571-38:0455].
>>
>>> (perhaps nodemgr didn't hold a reference which it should have), or/and
>>> all of this is an issue with the ongoing migration away from class_device.
>
> I don't have any firewire class_device migration patches in -mm right
> now.

Yes, I looked through the driver core related patches in -mm but wasn't
sure if there was a change to generic code which could affect
ieee1394/nodemgr.

> I do have one sitting here if you wish to play around with it, but it
> needs some more infrastructure patches that I have not really tested all
> that well yet.

(Is this infrastructure something which other subsystems will require
anyway? If not, maybe the ieee1394 subsystem's sysfs interface could be
cut to size instead.)

> Either way, I don't think this is caused by any new class_device
> patches, but I'm very willing to be proven wrong :)

Good, I just wanted to hear your opinion before drilling further down.
Seems there is an older bug in nodemgr. But whatever it is, the reporter
reproduced it _only_ in -mm, with either of 2.6.19-rc-mm's and
2.6.19-rc's ieee1394 code. Time for me to let -mm loose on my PC.

Thanks,
--
Stefan Richter
-=====-=-==- =-== =--=-
http://arcgraph.de/sr/

2006-11-18 17:08:24

[permalink] [raw]

Subject: Re: 2.6.19-rc5-mm2 (Oops in class_device_remove_attrs during nodemgr_remove_host)

> Time for me to let -mm loose on my PC.

Small progress:

- I get the oops already in nodemgr_remove_ne, unlike the original
report where it happened a little later in driver core functions
called by nodemgr_remove_ne.

- I get it only if eth1394 is loaded when I unload ohci1394.

- Like Mattia already found, this only happens on -mm, not on
2.6.19-rc plus patched ieee1394 code which is 100% the same as
in -mm except for Nigel Cunningham's
add-include-linux-freezerh-and-move-definitions-from.patch
which is of course not involved.

EIP is at nodemgr_remove_ne+0x40/0x90 [ieee1394]
eax: 00000000 ebx: f6af0c68 ecx: c02fcc20 edx: 0000003a
esi: f6af0c2c edi: f8c14b60 ebp: f7395dd8 esp: f7395db8
ds: 007b es: 007b ss: 0068
Process modprobe (pid: 4568, ti=f7394000 task=f69c3530 task.ti=f7394000)
Stack: f6af0c68 00000000 00000020 0000003a f8de0e00 00000000 00000000
f7395dfc
f7395dec f8c14b8e f6af0c2c f73c20c4 f6af0c9c f7395e18 c02228e2
f6af0c68
f73c20c4 f73c20c4 f73c20e4 f6af0c98 c02b4698 f73c20c4 f73c2000
f73c2000
Call Trace:
[<c010400f>] show_trace_log_lvl+0x2f/0x50
[<c01040f7>] show_stack_log_lvl+0x97/0xc0
[<c0104355>] show_registers+0x1c5/0x340
[<c010469a>] die+0x12a/0x220
[<c0114649>] do_page_fault+0x369/0x660
[<c02b697c>] error_code+0x7c/0x84
[<f8c14b8e>] __nodemgr_remove_host_dev+0x2e/0x40 [ieee1394]
[<c02228e2>] device_for_each_child+0x32/0x60
[<f8c14bbe>] nodemgr_remove_host_dev+0x1e/0x90 [ieee1394]
[<f8c169f7>] nodemgr_remove_host+0x37/0x40 [ieee1394]
[<f8c111bc>] __unregister_host+0x8c/0xd0 [ieee1394]
[<f8c11b16>] highlevel_remove_host+0x36/0x60 [ieee1394]
[<f8c10c23>] hpsb_remove_host+0x43/0x70 [ieee1394]
[<f8c07e08>] ohci1394_pci_remove+0x68/0x240 [ohci1394]
[<c01f7f86>] pci_device_remove+0x46/0x50
[<c0224cae>] __device_release_driver+0xae/0xc0
[<c0224e38>] driver_detach+0x118/0x120
[<c0224174>] bus_remove_driver+0x44/0x70
[<c0225102>] driver_unregister+0x12/0x20
[<c01f8305>] pci_unregister_driver+0x15/0x30
[<f8c084d2>] ohci1394_cleanup+0x12/0x14 [ohci1394]
[<c0142aa6>] sys_delete_module+0x156/0x180
[<c01031f6>] sysenter_past_esp+0x5f/0x85
=======================
Code: c7 85 c0 89 c3 74 60 8b 06 8b 56 04 89 44 24 10 89 54 24 14 0f b7
46 14 89 c2 83 e0 3f c1 ea 06 89 44 24 08 89 54 24 0c 8b 46 10 <8b> 80
b8 00 00 00 c7 04 24 84 bc c1 f8 89 44 24 04 e8 7a 9c 50
EIP: [<f8c14b10>] nodemgr_remove_ne+0x40/0x90 [ieee1394] SS:ESP
0068:f7395db8

In that way it is 100% reproducible here. I continue to debug this.
--
Stefan Richter
-=====-=-==- =-== =--=-
http://arcgraph.de/sr/

2006-11-18 21:45:30

[permalink] [raw]

Subject: Re: 2.6.19-rc5-mm2 (Oops in class_device_remove_attrs during nodemgr_remove_host)

I added the following patch:

--- linux-2.6.19-rc5-mm2.orig/drivers/ieee1394/nodemgr.c 2006-11-18 21:18:05.000000000 +0100
+++ linux-2.6.19-rc5-mm2/drivers/ieee1394/nodemgr.c 2006-11-18 21:33:44.000000000 +0100
@@ -798,8 +798,9 @@ static void nodemgr_remove_uds(struct no

static void nodemgr_remove_ne(struct node_entry *ne)
{
- struct device *dev = &ne->device;
+ struct device *dev;

+ HPSB_DEBUG("****** nodemgr_remove_ne");
dev = get_device(&ne->device);
if (!dev)
return;
@@ -817,7 +818,10 @@ static void nodemgr_remove_ne(struct nod

static int __nodemgr_remove_host_dev(struct device *dev, void *data)
{
- nodemgr_remove_ne(container_of(dev, struct node_entry, device));
+ struct node_entry *ne = container_of(dev, struct node_entry, device);
+
+ HPSB_DEBUG("****** ne = %p", ne);
+ nodemgr_remove_ne(ne);
return 0;
}

@@ -906,6 +910,7 @@ static struct node_entry *nodemgr_create
HPSB_DEBUG("%s added: ID:BUS[" NODE_BUS_FMT "] GUID[%016Lx]",
(host->node_id == nodeid) ? "Host" : "Node",
NODE_BUS_ARGS(host, nodeid), (unsigned long long)guid);
+ HPSB_DEBUG("****** ne = %p", ne);

return ne;

With this I get the following kernel log on a PC with two FireWire cards:

# modprobe ohci1394

Nov 18 21:38:05 shuttle kernel: ieee1394: Initialized config rom entry `ip1394'
Nov 18 21:38:05 shuttle kernel: ohci1394: fw-host0: OHCI-1394 1.1 (PCI): IRQ=[17] MMIO=[e7004000-e70047ff] Max Packet=[4096] IR/IT contexts=[4/8]
Nov 18 21:38:05 shuttle kernel: ohci1394: fw-host1: OHCI-1394 1.0 (PCI): IRQ=[19] MMIO=[e7006000-e70067ff] Max Packet=[2048] IR/IT contexts=[8/8]
Nov 18 21:38:07 shuttle kernel: ieee1394: Error parsing configrom for node 0-01:1023
Nov 18 21:38:07 shuttle kernel: ieee1394: Host added: ID:BUS[0-02:1023] GUID[0001080000002d02]
Nov 18 21:38:07 shuttle kernel: ieee1394: ****** ne = f61f609c
Nov 18 21:38:07 shuttle kernel: eth1394: eth1: IEEE-1394 IPv4 over 1394 Ethernet (fw-host0)
Nov 18 21:38:07 shuttle kernel: eth1394: eth2: IEEE-1394 IPv4 over 1394 Ethernet (fw-host1)
Nov 18 21:38:07 shuttle kernel: ieee1394: Host added: ID:BUS[1-00:1023] GUID[00301bac00002ba4]
Nov 18 21:38:07 shuttle kernel: ieee1394: ****** ne = f50db964

# modprobe -r ohci1394

Nov 18 21:38:18 shuttle kernel: ieee1394: ****** ne = f627952c
Nov 18 21:38:18 shuttle kernel: ieee1394: ****** nodemgr_remove_ne
Nov 18 21:38:18 shuttle kernel: BUG: unable to handle kernel NULL pointer dereference at virtual address 000000b8

We never created a "ne" at f627952c. This address is obtained by the
container_of() in __nodemgr_remove_host_dev(). Ergo the list of device
pointers which device_for_each_child() in nodemgr_remove_host_dev() is
iterating over, i.e. the host->device.klist_children, was corrupted
somewhere.

Nov 18 21:38:18 shuttle kernel: printing eip:
Nov 18 21:38:18 shuttle kernel: f9057b4c
Nov 18 21:38:18 shuttle kernel: *pde = 00000000
Nov 18 21:38:18 shuttle kernel: Oops: 0000 [#1]
Nov 18 21:38:18 shuttle kernel: PREEMPT SMP
Nov 18 21:38:18 shuttle kernel: last sysfs file: /class/printer/lp0/dev
Nov 18 21:38:18 shuttle kernel: Modules linked in: eth1394 ohci1394 ieee1394 nvidia(P) nfsd exportfs lockd sunrpc snd_via82xx snd_ac97_codec snd_ac97_bus snd_pcm snd_timer snd_page_alloc snd_mpu401_uart snd_rawmidi snd lp af_packet 8139too mii loop via_agp agpgart uhci_hcd
Nov 18 21:38:18 shuttle kernel: CPU: 0
Nov 18 21:38:18 shuttle kernel: EIP: 0060:[pg0+950528844/1067602944] Tainted: P VLI
Nov 18 21:38:18 shuttle kernel: EIP: 0060:[<f9057b4c>] Tainted: P VLI
Nov 18 21:38:18 shuttle kernel: EFLAGS: 00210213 (2.6.19-rc5-mm2 #15)
Nov 18 21:38:18 shuttle kernel: EIP is at nodemgr_remove_ne+0x4c/0x90 [ieee1394]
Nov 18 21:38:18 shuttle kernel: eax: 00000000 ebx: f6279568 ecx: 00003a2d edx: 0000037a
Nov 18 21:38:18 shuttle kernel: esi: f627952c edi: f9057b90 ebp: f57a3dd8 esp: f57a3db8
Nov 18 21:38:18 shuttle kernel: ds: 007b es: 007b ss: 0068
Nov 18 21:38:18 shuttle kernel: Process modprobe (pid: 5967, ti=f57a2000 task=f576e0f0 task.ti=f57a2000)
Nov 18 21:38:18 shuttle kernel: Stack: f6279568 f627952c 00000020 0000037a f8c7de00 00000000 f627952c f57a3dfc
Nov 18 21:38:18 shuttle kernel: f57a3dec f9057bb5 f627952c f627952c 00000000 f57a3e18 c02313b2 f6279568
Nov 18 21:38:18 shuttle kernel: 00000000 f73ea0c4 f73ea0e4 f6279598 c02d8b18 f73ea0c4 f73ea000 f73ea000
Nov 18 21:38:18 shuttle kernel: Call Trace:
Nov 18 21:38:19 shuttle kernel: [show_trace_log_lvl+47/80] show_trace_log_lvl+0x2f/0x50
Nov 18 21:38:19 shuttle kernel: [<c010400f>] show_trace_log_lvl+0x2f/0x50
Nov 18 21:38:19 shuttle kernel: [show_stack_log_lvl+151/192] show_stack_log_lvl+0x97/0xc0
Nov 18 21:38:19 shuttle kernel: [<c01040f7>] show_stack_log_lvl+0x97/0xc0
Nov 18 21:38:19 shuttle kernel: [show_registers+453/832] show_registers+0x1c5/0x340
Nov 18 21:38:19 shuttle kernel: [<c0104355>] show_registers+0x1c5/0x340
Nov 18 21:38:19 shuttle kernel: [die+298/544] die+0x12a/0x220
Nov 18 21:38:19 shuttle kernel: [<c010469a>] die+0x12a/0x220
Nov 18 21:38:19 shuttle kernel: [do_page_fault+873/1632] do_page_fault+0x369/0x660
Nov 18 21:38:19 shuttle kernel: [<c0114649>] do_page_fault+0x369/0x660
Nov 18 21:38:19 shuttle kernel: [error_code+124/132] error_code+0x7c/0x84
Nov 18 21:38:19 shuttle kernel: [<c02dadfc>] error_code+0x7c/0x84
Nov 18 21:38:19 shuttle kernel: [pg0+950528949/1067602944] __nodemgr_remove_host_dev+0x25/0x30 [ieee1394]
Nov 18 21:38:19 shuttle kernel: [<f9057bb5>] __nodemgr_remove_host_dev+0x25/0x30 [ieee1394]
Nov 18 21:38:19 shuttle kernel: [device_for_each_child+50/96] device_for_each_child+0x32/0x60
Nov 18 21:38:19 shuttle kernel: [<c02313b2>] device_for_each_child+0x32/0x60
Nov 18 21:38:19 shuttle kernel: [pg0+950528994/1067602944] nodemgr_remove_host_dev+0x22/0x90 [ieee1394]
Nov 18 21:38:19 shuttle kernel: [<f9057be2>] nodemgr_remove_host_dev+0x22/0x90 [ieee1394]
Nov 18 21:38:19 shuttle kernel: [pg0+950536711/1067602944] nodemgr_remove_host+0x37/0x40 [ieee1394]
Nov 18 21:38:19 shuttle kernel: [<f9059a07>] nodemgr_remove_host+0x37/0x40 [ieee1394]
Nov 18 21:38:19 shuttle kernel: [pg0+950514108/1067602944] __unregister_host+0x8c/0xd0 [ieee1394]
Nov 18 21:38:19 shuttle kernel: [<f90541bc>] __unregister_host+0x8c/0xd0 [ieee1394]
Nov 18 21:38:19 shuttle kernel: [pg0+950516502/1067602944] highlevel_remove_host+0x36/0x60 [ieee1394]
Nov 18 21:38:19 shuttle kernel: [<f9054b16>] highlevel_remove_host+0x36/0x60 [ieee1394]
Nov 18 21:38:19 shuttle kernel: [pg0+950512675/1067602944] hpsb_remove_host+0x43/0x70 [ieee1394]
Nov 18 21:38:19 shuttle kernel: [<f9053c23>] hpsb_remove_host+0x43/0x70 [ieee1394]
Nov 18 21:38:19 shuttle kernel: [pg0+946040328/1067602944] ohci1394_pci_remove+0x68/0x240 [ohci1394]
Nov 18 21:38:19 shuttle kernel: [<f8c0fe08>] ohci1394_pci_remove+0x68/0x240 [ohci1394]
Nov 18 21:38:19 shuttle kernel: [pci_device_remove+70/80] pci_device_remove+0x46/0x50
Nov 18 21:38:19 shuttle kernel: [<c01fe976>] pci_device_remove+0x46/0x50
Nov 18 21:38:19 shuttle kernel: [__device_release_driver+174/192] __device_release_driver+0xae/0xc0
Nov 18 21:38:19 shuttle kernel: [<c023377e>] __device_release_driver+0xae/0xc0
Nov 18 21:38:19 shuttle kernel: [driver_detach+280/288] driver_detach+0x118/0x120
Nov 18 21:38:19 shuttle kernel: [<c0233908>] driver_detach+0x118/0x120
Nov 18 21:38:19 shuttle kernel: [bus_remove_driver+68/112] bus_remove_driver+0x44/0x70
Nov 18 21:38:19 shuttle kernel: [<c0232c44>] bus_remove_driver+0x44/0x70
Nov 18 21:38:19 shuttle kernel: [driver_unregister+18/32] driver_unregister+0x12/0x20
Nov 18 21:38:19 shuttle kernel: [<c0233bd2>] driver_unregister+0x12/0x20
Nov 18 21:38:19 shuttle kernel: [pci_unregister_driver+21/48] pci_unregister_driver+0x15/0x30
Nov 18 21:38:19 shuttle kernel: [<c01fecf5>] pci_unregister_driver+0x15/0x30
Nov 18 21:38:19 shuttle kernel: [pg0+946042066/1067602944] ohci1394_cleanup+0x12/0x14 [ohci1394]
Nov 18 21:38:19 shuttle kernel: [<f8c104d2>] ohci1394_cleanup+0x12/0x14 [ohci1394]
Nov 18 21:38:19 shuttle kernel: [sys_delete_module+342/384] sys_delete_module+0x156/0x180
Nov 18 21:38:19 shuttle kernel: [<c0142aa6>] sys_delete_module+0x156/0x180
Nov 18 21:38:19 shuttle kernel: [sysenter_past_esp+95/133] sysenter_past_esp+0x5f/0x85
Nov 18 21:38:19 shuttle kernel: [<c01031f6>] sysenter_past_esp+0x5f/0x85
Nov 18 21:38:19 shuttle kernel: =======================
Nov 18 21:38:19 shuttle kernel: Code: c7 85 c0 89 c3 74 60 8b 06 8b 56 04 89 44 24 10 89 54 24 14 0f b7 46 14 89 c2 83 e0 3f c1 ea 06 89 44 24 08 89 54 24 0c 8b 46 10 <8b> 80 b8 00 00 00 c7 04 24 2c b5 07 f9 89 44 24 04 e8 3e 6c 0c
Nov 18 21:38:19 shuttle kernel: EIP: [pg0+950528844/1067602944] nodemgr_remove_ne+0x4c/0x90 [ieee1394] SS:ESP 0068:f57a3db8
Nov 18 21:38:19 shuttle kernel: EIP: [<f9057b4c>] nodemgr_remove_ne+0x4c/0x90 [ieee1394] SS:ESP 0068:f57a3db8

The same on Linux 2.6.19-rc4 plus what constitutes git-ieee1394.patch
plus the diagnostics patch:

# modprobe ohci1394

Nov 18 22:09:25 shuttle kernel: ieee1394: Initialized config rom entry `ip1394'
Nov 18 22:09:25 shuttle kernel: ohci1394: fw-host0: OHCI-1394 1.1 (PCI): IRQ=[17] MMIO=[e7004000-e70047ff] Max Packet=[4096] IR/IT contexts=[4/8]
Nov 18 22:09:25 shuttle kernel: ohci1394: fw-host1: OHCI-1394 1.0 (PCI): IRQ=[19] MMIO=[e7006000-e70067ff] Max Packet=[2048] IR/IT contexts=[8/8]
Nov 18 22:09:27 shuttle kernel: ieee1394: Error parsing configrom for node 0-01:1023
Nov 18 22:09:27 shuttle kernel: ieee1394: Host added: ID:BUS[0-02:1023] GUID[0001080000002d02]
Nov 18 22:09:27 shuttle kernel: ieee1394: ****** ne = f505512c
Nov 18 22:09:27 shuttle kernel: eth1394: eth1: IEEE-1394 IPv4 over 1394 Ethernet (fw-host0)
Nov 18 22:09:27 shuttle kernel: eth1394: eth2: IEEE-1394 IPv4 over 1394 Ethernet (fw-host1)
Nov 18 22:09:27 shuttle kernel: ieee1394: Host added: ID:BUS[1-00:1023] GUID[00301bac00002ba4]
Nov 18 22:09:27 shuttle kernel: ieee1394: ****** ne = f5140d80

# modprobe -r ohci1394

Nov 18 22:09:31 shuttle kernel: ieee1394: ****** ne = f5140d80
Nov 18 22:09:31 shuttle kernel: ieee1394: ****** nodemgr_remove_ne
Nov 18 22:09:31 shuttle kernel: ieee1394: Node removed: ID:BUS[1-00:1023] GUID[00301bac00002ba4]
Nov 18 22:09:32 shuttle kernel: ieee1394: ****** ne = f505512c
Nov 18 22:09:32 shuttle kernel: ieee1394: ****** nodemgr_remove_ne
Nov 18 22:09:32 shuttle kernel: ieee1394: Node removed: ID:BUS[0-02:1023] GUID[0001080000002d02]

It seems like one of the patches in -mm overwrites a device's list of
children with junk.

Mattia, *if* your machine is able to compile and reboot into new
kernels really quickly, it would be nice if you could biject between
the -mm patches. I suppose the following ones are those to concentrate
on first:

broken-out/gregkh-driver-config_sysfs_deprecated-bus.patch
broken-out/gregkh-driver-config_sysfs_deprecated-class.patch
broken-out/gregkh-driver-config_sysfs_deprecated-device.patch
broken-out/gregkh-driver-config_sysfs_deprecated-PHYSDEV.patch
broken-out/gregkh-driver-driver-link-sysfs-timing.patch
broken-out/gregkh-driver-sysfs-crash-debugging.patch
broken-out/gregkh-driver-udev-compatible-hack.patch

But hold on, I will do one other thing after I sent this message; I'll
test -mm with CONFIG_SYSFS_DEPRECATED=y.
--
Stefan Richter
-=====-=-==- =-== =--=-
http://arcgraph.de/sr/

2006-11-18 22:09:13

[permalink] [raw]

Subject: Re: 2.6.19-rc5-mm2 (Oops in class_device_remove_attrs during nodemgr_remove_host)

I wrote:
> It seems like one of the patches in -mm overwrites a device's list of
> children with junk.

And this happens only if eth1394 wasn't unloaded (therefore unbound
from FireWire "ud" devices beneath FireWire "ne" devices beneath the
FireWire host devices) before the host devices's children are to be
removed.

> Mattia, *if* your machine is able to compile and reboot into new
> kernels really quickly, it would be nice if you could biject between
> the -mm patches.
...
> But hold on, I will do one other thing after I sent this message; I'll
> test -mm with CONFIG_SYSFS_DEPRECATED=y.

CONFIG_SYSFS_DEPRECATED=y does not change anything.
--
Stefan Richter
-=====-=-==- =-== =--=-
http://arcgraph.de/sr/

2006-11-19 08:56:46

[permalink] [raw]

Subject: Re: 2.6.19-rc5-mm2 (Oops in class_device_remove_attrs during nodemgr_remove_host)

On Sat, Nov 18, 2006 at 10:45:01PM +0100, Stefan Richter wrote:
[...]
> It seems like one of the patches in -mm overwrites a device's list of
> children with junk.
>
> Mattia, *if* your machine is able to compile and reboot into new
> kernels really quickly, it would be nice if you could biject between
> the -mm patches. I suppose the following ones are those to concentrate
> on first:
>
> broken-out/gregkh-driver-config_sysfs_deprecated-bus.patch
> broken-out/gregkh-driver-config_sysfs_deprecated-class.patch
> broken-out/gregkh-driver-config_sysfs_deprecated-device.patch
> broken-out/gregkh-driver-config_sysfs_deprecated-PHYSDEV.patch
> broken-out/gregkh-driver-driver-link-sysfs-timing.patch
> broken-out/gregkh-driver-sysfs-crash-debugging.patch
> broken-out/gregkh-driver-udev-compatible-hack.patch
>
> But hold on, I will do one other thing after I sent this message; I'll
> test -mm with CONFIG_SYSFS_DEPRECATED=y.

Ok, will go through these patches first and let you know

--
mattia
:wq!

2006-11-19 09:47:25

[permalink] [raw]

Subject: Re: [2.6 patch] mark pci_find_device() as __deprecated

>
> Oh, and if anything starts complaining "But this adds some warnings to
> my kernel build!", he should either first fix the 200 kB (sic) of
> warnings I'm getting in 2.6.19-rc5-mm2 starting at MODPOST or go to hell.

we can solve this btw; we could have a

#define THIS_MODULE_IS_LEGACY_CRAP_AND_WONT_GET_FIXED

that would turn __deprecated into a nop for those few legacy modules
inside the kernel that nobody really is looking after.

(and yes the define should be really offensive so that nobody will put
it in a maintained module, and maybe it should even cause the kernel to
printk something when such a module gets loaded into the kernel)

If this sounds like a good idea I'll code it up...

2006-11-19 09:44:34

[permalink] [raw]

Subject: Re: [-mm patch] remove drivers/pci/search.c:pci_find_device_reverse()

On Fri, 2006-11-17 at 11:54 -0800, Andrew Morton wrote:
> On Fri, 17 Nov 2006 15:21:45 +0100
> Adrian Bunk <[email protected]> wrote:
>
> > This patch removes the no longer used pci_find_device_reverse().
>
> But it is exported to modules.

and no module uses it ;)

--
if you want to mail me at work (you don't), use arjan (at) linux.intel.com
Test the interaction between Linux and your BIOS via http://www.linuxfirmwarekit.org

2006-11-19 09:53:06

by Muli Ben-Yehuda

[permalink] [raw]

Subject: Re: [2.6 patch] mark pci_find_device() as __deprecated

On Sun, Nov 19, 2006 at 10:47:12AM +0100, Arjan van de Ven wrote:
>
> >
> > Oh, and if anything starts complaining "But this adds some warnings to
> > my kernel build!", he should either first fix the 200 kB (sic) of
> > warnings I'm getting in 2.6.19-rc5-mm2 starting at MODPOST or go to hell.
>
> we can solve this btw; we could have a
>
> #define THIS_MODULE_IS_LEGACY_CRAP_AND_WONT_GET_FIXED
>
> that would turn __deprecated into a nop for those few legacy modules
> inside the kernel that nobody really is looking after.

If no one is looking after them, shouldn't they just be removed?

Cheers,
Muli

2006-11-19 10:01:26

[permalink] [raw]

Subject: Re: [2.6 patch] mark pci_find_device() as __deprecated

On Sun, 2006-11-19 at 11:52 +0200, Muli Ben-Yehuda wrote:
> On Sun, Nov 19, 2006 at 10:47:12AM +0100, Arjan van de Ven wrote:
> >
> > >
> > > Oh, and if anything starts complaining "But this adds some warnings to
> > > my kernel build!", he should either first fix the 200 kB (sic) of
> > > warnings I'm getting in 2.6.19-rc5-mm2 starting at MODPOST or go to hell.
> >
> > we can solve this btw; we could have a
> >
> > #define THIS_MODULE_IS_LEGACY_CRAP_AND_WONT_GET_FIXED
> >
> > that would turn __deprecated into a nop for those few legacy modules
> > inside the kernel that nobody really is looking after.
>
> If no one is looking after them, shouldn't they just be removed?

that's a whole different flamewar, esp if they sort of kinda mostly work
if the moon is aligned properly with Mars.

--
if you want to mail me at work (you don't), use arjan (at) linux.intel.com
Test the interaction between Linux and your BIOS via http://www.linuxfirmwarekit.org

2006-11-19 14:04:23

[permalink] [raw]

Subject: Re: [2.6 patch] mark pci_find_device() as __deprecated

On Sun, Nov 19, 2006 at 10:47:12AM +0100, Arjan van de Ven wrote:
>
> >
> > Oh, and if anything starts complaining "But this adds some warnings to
> > my kernel build!", he should either first fix the 200 kB (sic) of
> > warnings I'm getting in 2.6.19-rc5-mm2 starting at MODPOST or go to hell.
>
> we can solve this btw; we could have a
>
> #define THIS_MODULE_IS_LEGACY_CRAP_AND_WONT_GET_FIXED
>...

The few warnings by __deprecated are not that much of a problem.

But the > 200 kB starting at MODPOST in -mm are really annoying.
And it seems noone cares about them.

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

2006-11-19 14:06:05

[permalink] [raw]

Subject: Re: [2.6 patch] mark pci_find_device() as __deprecated

On Sun, Nov 19, 2006 at 11:52:58AM +0200, Muli Ben-Yehuda wrote:
> On Sun, Nov 19, 2006 at 10:47:12AM +0100, Arjan van de Ven wrote:
> >
> > >
> > > Oh, and if anything starts complaining "But this adds some warnings to
> > > my kernel build!", he should either first fix the 200 kB (sic) of
> > > warnings I'm getting in 2.6.19-rc5-mm2 starting at MODPOST or go to hell.
> >
> > we can solve this btw; we could have a
> >
> > #define THIS_MODULE_IS_LEGACY_CRAP_AND_WONT_GET_FIXED
> >
> > that would turn __deprecated into a nop for those few legacy modules
> > inside the kernel that nobody really is looking after.
>
> If no one is looking after them, shouldn't they just be removed?

unmaintained != not used

As an example, some people might be unhappy if the floppy driver that is
unmaintained for ages and not in a good state was removed.

> Cheers,
> Muli

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

2006-11-19 14:13:12

[permalink] [raw]

Subject: Re: [2.6 patch] mark pci_find_device() as __deprecated

On Sun, 2006-11-19 at 15:04 +0100, Adrian Bunk wrote:
> On Sun, Nov 19, 2006 at 10:47:12AM +0100, Arjan van de Ven wrote:
> >
> > >
> > > Oh, and if anything starts complaining "But this adds some warnings to
> > > my kernel build!", he should either first fix the 200 kB (sic) of
> > > warnings I'm getting in 2.6.19-rc5-mm2 starting at MODPOST or go to hell.
> >
> > we can solve this btw; we could have a
> >
> > #define THIS_MODULE_IS_LEGACY_CRAP_AND_WONT_GET_FIXED
> >...
>
> The few warnings by __deprecated are not that much of a problem.

yes they are; the current situation prevents things that are used in
only a set of old unmaintained legacy drivers (read: ISDN) as being
marked __deprecated because they add too many warnings, while the API
really should be marked deprecated..

think for example the entire sleep_on() family of API's (which basically
are impossible to use race-free in 2.6)

--
if you want to mail me at work (you don't), use arjan (at) linux.intel.com
Test the interaction between Linux and your BIOS via http://www.linuxfirmwarekit.org

2006-11-19 14:27:37

[permalink] [raw]

Subject: Re: [2.6 patch] mark pci_find_device() as __deprecated

On Sun, Nov 19, 2006 at 03:13:04PM +0100, Arjan van de Ven wrote:
> On Sun, 2006-11-19 at 15:04 +0100, Adrian Bunk wrote:
> > On Sun, Nov 19, 2006 at 10:47:12AM +0100, Arjan van de Ven wrote:
> > >
> > > >
> > > > Oh, and if anything starts complaining "But this adds some warnings to
> > > > my kernel build!", he should either first fix the 200 kB (sic) of
> > > > warnings I'm getting in 2.6.19-rc5-mm2 starting at MODPOST or go to hell.
> > >
> > > we can solve this btw; we could have a
> > >
> > > #define THIS_MODULE_IS_LEGACY_CRAP_AND_WONT_GET_FIXED
> > >...
> >
> > The few warnings by __deprecated are not that much of a problem.
>
> yes they are; the current situation prevents things that are used in
> only a set of old unmaintained legacy drivers (read: ISDN) as being

ISDN at least has reachable maintainers.

There are much worse drivers in the kernel.

> marked __deprecated because they add too many warnings, while the API
> really should be marked deprecated..
>
> think for example the entire sleep_on() family of API's (which basically
> are impossible to use race-free in 2.6)

At about 100 warnings with an allyesconfig kernel build and less than a
handful of warnings with a normal .config .

That's not that bad, and it might result in even these legacy drivers
getting fixed so that the API can be completely removed.

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

2006-11-19 15:24:33

by Muli Ben-Yehuda

[permalink] [raw]

Subject: Re: [2.6 patch] mark pci_find_device() as __deprecated

On Sun, Nov 19, 2006 at 03:06:00PM +0100, Adrian Bunk wrote:

> unmaintained != not used
>
> As an example, some people might be unhappy if the floppy driver that is
> unmaintained for ages and not in a good state was removed.

I understand. However, if it was slated to be removed, said people
might be inclined to start maintaining it. We have a bar for inclusion
of new code into the tree - why shouldn't a quality bar also be
applied to old code in the tree?

Cheers,
Muli

2006-11-19 15:49:12

[permalink] [raw]

Subject: Re: [2.6 patch] mark pci_find_device() as __deprecated

On Sun, Nov 19, 2006 at 05:24:21PM +0200, Muli Ben-Yehuda wrote:
> On Sun, Nov 19, 2006 at 03:06:00PM +0100, Adrian Bunk wrote:
>
> > unmaintained != not used
> >
> > As an example, some people might be unhappy if the floppy driver that is
> > unmaintained for ages and not in a good state was removed.
>
> I understand. However, if it was slated to be removed, said people
> might be inclined to start maintaining it.

Most Linux users weren't able to maintain any peace of kernel code even
if they wanted to.

> We have a bar for inclusion
> of new code into the tree - why shouldn't a quality bar also be
> applied to old code in the tree?

Removing an older unmaintained but working driver is from a user's point
of view a regression that locks this user into using an older kernel.

> Cheers,
> Muli

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

2006-11-19 16:22:48

[permalink] [raw]

Subject: ohci1394 oops bisected [was Re: 2.6.19-rc5-mm2 (Oops in class_device_remove_attrs during nodemgr_remove_host)]

On Sat, Nov 18, 2006 at 10:45:01PM +0100, Stefan Richter wrote:
[...]
> broken-out/gregkh-driver-config_sysfs_deprecated-bus.patch
> broken-out/gregkh-driver-config_sysfs_deprecated-class.patch
> broken-out/gregkh-driver-config_sysfs_deprecated-device.patch
> broken-out/gregkh-driver-config_sysfs_deprecated-PHYSDEV.patch
> broken-out/gregkh-driver-driver-link-sysfs-timing.patch
> broken-out/gregkh-driver-sysfs-crash-debugging.patch
> broken-out/gregkh-driver-udev-compatible-hack.patch

Very close :) But no, the winner is...
gregkh-driver-network-device.patch

--
mattia
:wq!

2006-11-19 16:50:20

[permalink] [raw]

Subject: Re: [2.6 patch] mark pci_find_device() as __deprecated

On Sun, 2006-11-19 at 17:24 +0200, Muli Ben-Yehuda wrote:
> On Sun, Nov 19, 2006 at 03:06:00PM +0100, Adrian Bunk wrote:
>
> > unmaintained != not used
> >
> > As an example, some people might be unhappy if the floppy driver that is
> > unmaintained for ages and not in a good state was removed.
>
> I understand. However, if it was slated to be removed, said people
> might be inclined to start maintaining it. We have a bar for inclusion
> of new code into the tree - why shouldn't a quality bar also be
> applied to old code in the tree?

this bypasses the convenient fact that there are 2 types of
unmaintained:

1) Drivers that barely, if at all, limp along and nobody has hw for
2) Drivers that no one person is the declared maintainer, but which do
get fixed when they break by "someone"

floppy.c is of the later kind; the hardware is widespread enough to make
that feasible I suppose; while the former kind are mostly ISA slot cards
that virtually nobody has (or only people who can't or don't want to
care about the linux kernel driver; a bunch of serial expander drivers
and a whole lot of the ISDN drivers falls in this category)

marking the category 1) drivers that limp along as "don't warn on
deprecated" is sort of fair; they're not far enough down deathrow yet
that they can be removed entirely, yet they also shouldn't clutter up
the build logs and they shouldn't prevent us from deprecating APIs that
are truely broken (*_sleep_on(), cli() etc) in 2.6 kernels...

--
if you want to mail me at work (you don't), use arjan (at) linux.intel.com
Test the interaction between Linux and your BIOS via http://www.linuxfirmwarekit.org

2006-11-19 17:14:25

[permalink] [raw]

Subject: Re: ohci1394 oops bisected [was Re: 2.6.19-rc5-mm2 (Oops in class_device_remove_attrs during nodemgr_remove_host)]

Mattia Dongili wrote:
> the winner is... gregkh-driver-network-device.patch

Interesting. Looks very much like eth1394's sysfs interface is getting
in the way. And since it is entirely handled by the ieee1394 core, it
means ieee1394 needs the class_dev to dev treatment. I think it's OK if
we just wait for Greg to finish his preliminary patch. Until then,
CONFIG_IEEE1394_ETH1394=n should avoid the oops. (Or Andrew marks
eth1394 broken or removes gregkh-driver-network-device.patch...)

Mattia, thanks for the many tests.
--
Stefan Richter
-=====-=-==- =-== =--==
http://arcgraph.de/sr/

2006-11-19 17:14:40

by Gene Heskett

[permalink] [raw]

Subject: Re: ohci1394 oops bisected [was Re: 2.6.19-rc5-mm2 (Oops in class_device_remove_attrs during nodemgr_remove_host)]

On Sunday 19 November 2006 11:22, Mattia Dongili wrote:
>On Sat, Nov 18, 2006 at 10:45:01PM +0100, Stefan Richter wrote:
>[...]
>
>> broken-out/gregkh-driver-config_sysfs_deprecated-bus.patch
>> broken-out/gregkh-driver-config_sysfs_deprecated-class.patch
>> broken-out/gregkh-driver-config_sysfs_deprecated-device.patch
>> broken-out/gregkh-driver-config_sysfs_deprecated-PHYSDEV.patch
>> broken-out/gregkh-driver-driver-link-sysfs-timing.patch
>> broken-out/gregkh-driver-sysfs-crash-debugging.patch
>> broken-out/gregkh-driver-udev-compatible-hack.patch
>
>Very close :) But no, the winner is...
>gregkh-driver-network-device.patch

If this has anything to do with kino segfaulting and going away when
trying to make use of the on-screen camera motion controls, please see to
it that it gets incorporated into the next FC6 kernel release, its badly
needed for us ieee1394 users.

--
Cheers, Gene
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Yahoo.com and AOL/TW attorneys please note, additions to the above
message by Gene Heskett are:
Copyright 2006 by Maurice Eugene Heskett, all rights reserved.

2006-11-19 18:08:35

[permalink] [raw]

Subject: Kino segfault (was Re: ohci1394 oops bisected)

Gene Heskett wrote:
> If this has anything to do with kino segfaulting and going away when
> trying to make use of the on-screen camera motion controls, please see to
> it that it gets incorporated into the next FC6 kernel release, its badly
> needed for us ieee1394 users.

No, it's very probably unrelated. You could report Kino related bugs via
http://www.kinodv.org --- or on bugzilla.redhat.com if it's merely an issue
with the distributed versions of Kino/ libraries/ kernel.
--
Stefan Richter
-=====-=-==- =-== =--==
http://arcgraph.de/sr/

2006-11-19 20:11:43

by Gene Heskett

[permalink] [raw]

Subject: Re: Kino segfault (was Re: ohci1394 oops bisected)

On Sunday 19 November 2006 13:07, Stefan Richter wrote:
>Gene Heskett wrote:
>> If this has anything to do with kino segfaulting and going away when
>> trying to make use of the on-screen camera motion controls, please see
>> to it that it gets incorporated into the next FC6 kernel release, its
>> badly needed for us ieee1394 users.
>
>No, it's very probably unrelated. You could report Kino related bugs via
>http://www.kinodv.org --- or on bugzilla.redhat.com if it's merely an issue
>with the distributed versions of Kino/ libraries/ kernel.

Dan is aware of my problem(s) but cannot duplicate them on his system.
That is the first place I took my problem to.

--
Cheers, Gene
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Yahoo.com and AOL/TW attorneys please note, additions to the above
message by Gene Heskett are:
Copyright 2006 by Maurice Eugene Heskett, all rights reserved.

2006-11-19 20:34:45

[permalink] [raw]

Subject: Re: ohci1394 oops bisected [was Re: 2.6.19-rc5-mm2 (Oops in class_device_remove_attrs during nodemgr_remove_host)]

On Sun, 19 Nov 2006 18:13:45 +0100
Stefan Richter <[email protected]> wrote:

> Mattia Dongili wrote:
> > the winner is... gregkh-driver-network-device.patch

That was a fair bet - that patch has caused a mountain of grief.

> Interesting. Looks very much like eth1394's sysfs interface is getting
> in the way. And since it is entirely handled by the ieee1394 core, it
> means ieee1394 needs the class_dev to dev treatment. I think it's OK if
> we just wait for Greg to finish his preliminary patch. Until then,
> CONFIG_IEEE1394_ETH1394=n should avoid the oops. (Or Andrew marks
> eth1394 broken or removes gregkh-driver-network-device.patch...)

Do we know what's actually wrong, and what needs to be done about it?

2006-11-19 21:01:50

[permalink] [raw]

Subject: Re: ohci1394 oops bisected [was Re: 2.6.19-rc5-mm2 (Oops in class_device_remove_attrs during nodemgr_remove_host)]

Andrew Morton wrote:
> On Sun, 19 Nov 2006 18:13:45 +0100
> Stefan Richter <[email protected]> wrote:
>> Looks very much like eth1394's sysfs interface is getting
>> in the way. And since it is entirely handled by the ieee1394 core, it
>> means ieee1394 needs the class_dev to dev treatment. I think it's OK if
>> we just wait for Greg to finish his preliminary patch. Until then,
>> CONFIG_IEEE1394_ETH1394=n should avoid the oops. (Or Andrew marks
>> eth1394 broken or removes gregkh-driver-network-device.patch...)
>
> Do we know what's actually wrong, and what needs to be done about it?

I for one don't know what's needed precisely. But at the moment I
actually don't want to spend any more time on this because:
- It happens only if ohci1394 is unloaded while eth1394 is loaded.
(That's not an unusual condition though.)
- It happens only in -mm, and only because -mm contains the work-in-
progress patches for class_device -> device transition.
I expect it to go away automatically once Greg is done with the
transition. It seems Greg is the one to do it :-), at least I'm not
available right now to lend a hand. There are older ieee1394 bugs in
mainline with bigger practical impact for me to work on. If there are
still issues once ieee1394 was converted away from class_device, I'm OK
with revisiting it.

(Besides, if anybody wants to become eth1394 maintainer, please step up.
MAINTAINERS currently lists eth1394 as in "Odd fixes" mode.)
--
Stefan Richter
-=====-=-==- =-== =--==
http://arcgraph.de/sr/

2006-11-20 02:26:23

[permalink] [raw]

Subject: [-mm patch] fs/reiser4/: possible cleanups

This patch contains the following possible cleanups:
- make the following needlessly global functions statis:
- plugin/file/file_conversion.c: prepped_dclust_ok()
- plugin/file/file_conversion.c: cryptcompress2unixfile()
- #if 0 the following unused global functions:
- plugin/file/cryptcompress.c: prepare_write_cryptcompress()
- plugin/file/file_conversion.c: prot_delete_object_cryptcompress()

Signed-off-by: Adrian Bunk <[email protected]>

---

fs/reiser4/plugin/file/cryptcompress.c | 2 ++
fs/reiser4/plugin/file/file.h | 3 ---
fs/reiser4/plugin/file/file_conversion.c | 8 +++++---
3 files changed, 7 insertions(+), 6 deletions(-)

--- linux-2.6.19-rc5-mm2/fs/reiser4/plugin/file/file.h.old 2006-11-20 02:12:25.000000000 +0100
+++ linux-2.6.19-rc5-mm2/fs/reiser4/plugin/file/file.h 2006-11-20 02:14:54.000000000 +0100
@@ -203,8 +203,6 @@
ssize_t prot_read_cryptcompress(struct file *, char __user *buf,
size_t read_amount, loff_t * off);

-int prepare_write_cryptcompress(struct file *file, struct page *page,
- unsigned from, unsigned to);
ssize_t write_cryptcompress(struct file *, const char __user *buf, size_t write_amount,
loff_t * off, int * conv);
ssize_t prot_write_cryptcompress(struct file *, const char __user *buf, size_t write_amount,
@@ -230,7 +228,6 @@
int create_cryptcompress(struct inode *, struct inode *,
reiser4_object_create_data *);
int delete_object_cryptcompress(struct inode *);
-int prot_delete_object_cryptcompress(struct inode *);
void init_inode_data_cryptcompress(struct inode *, reiser4_object_create_data *,
int create);
int cut_tree_worker_cryptcompress(tap_t *, const reiser4_key * from_key,
--- linux-2.6.19-rc5-mm2/fs/reiser4/plugin/file/cryptcompress.c.old 2006-11-20 02:12:37.000000000 +0100
+++ linux-2.6.19-rc5-mm2/fs/reiser4/plugin/file/cryptcompress.c 2006-11-20 02:12:56.000000000 +0100
@@ -3768,11 +3768,13 @@
return 0;
}

+#if 0
int prepare_write_cryptcompress(struct file *file, struct page *page,
unsigned from, unsigned to)
{
return prepare_write_common(file, page, from, to);
}
+#endif /* 0 */

/*
--- linux-2.6.19-rc5-mm2/fs/reiser4/plugin/file/file_conversion.c.old 2006-11-20 02:13:24.000000000 +0100
+++ linux-2.6.19-rc5-mm2/fs/reiser4/plugin/file/file_conversion.c 2006-11-20 02:15:07.000000000 +0100
@@ -239,7 +239,7 @@
}

#if REISER4_DEBUG
-int prepped_dclust_ok(hint_t * hint)
+static int prepped_dclust_ok(hint_t * hint)
{
reiser4_key key;
coord_t * coord = &hint->ext_coord.coord;
@@ -410,8 +410,8 @@

/* do conversion */
-int cryptcompress2unixfile(struct file *file, struct inode * inode,
- reiser4_cluster_t * clust)
+static int cryptcompress2unixfile(struct file *file, struct inode * inode,
+ reiser4_cluster_t * clust)
{
int i;
int result = 0;
@@ -577,10 +577,12 @@
(file, ppos, count, actor, target));
}

+#if 0
int prot_delete_object_cryptcompress(struct inode *inode)
{
return PROT_PASSIVE(int, delete_object, (inode));
}
+#endif /* 0 */

/*
Local variables:

2006-11-20 02:27:39

[permalink] [raw]

Subject: [-mm patch] fs/dlm/lowcomms-tcp.c: remove 2 functions

On Tue, Nov 14, 2006 at 01:41:25AM -0800, Andrew Morton wrote:
>...
> Changes since 2.6.19-rc5-mm2:
>...
> git-gfs2-nmw.patch
>...
> git trees
>...

This patch removes the following unused functions:
- lowcomms_send_message()
- lowcomms_max_buffer_size()

Signed-off-by: Adrian Bunk <[email protected]>

---

fs/dlm/lowcomms-tcp.c | 24 ------------------------
1 file changed, 24 deletions(-)

--- linux-2.6.19-rc5-mm2/fs/dlm/lowcomms-tcp.c.old 2006-11-20 01:16:31.000000000 +0100
+++ linux-2.6.19-rc5-mm2/fs/dlm/lowcomms-tcp.c 2006-11-20 01:17:22.000000000 +0100
@@ -913,22 +913,6 @@
return -1;
}

-/* API send message call, may queue the request */
-/* N.B. This is the old interface - use the new one for new calls */
-int lowcomms_send_message(int nodeid, char *buf, int len, gfp_t allocation)
-{
- struct writequeue_entry *e;
- char *b;
-
- e = dlm_lowcomms_get_buffer(nodeid, len, allocation, &b);
- if (e) {
- memcpy(b, buf, len);
- dlm_lowcomms_commit_buffer(e);
- return 0;
- }
- return -ENOBUFS;
-}
-
/* Look for activity on active sockets */
static void process_sockets(void)
{
@@ -1129,14 +1113,6 @@
return 0;
}

-/*
- * Return the largest buffer size we can cope with.
- */
-int lowcomms_max_buffer_size(void)
-{
- return PAGE_CACHE_SIZE;
-}
-
void dlm_lowcomms_stop(void)
{
int i;

2006-11-20 02:27:52

[permalink] [raw]

Subject: [-mm patch] make ext2_get_blocks() static

On Tue, Nov 14, 2006 at 01:41:25AM -0800, Andrew Morton wrote:
>...
> Changes since 2.6.19-rc5-mm2:
>...
> +ext2-reservations.patch
>...
> Port the ext3 reservations code into ext2.
>...

This patch makes the needlessly global ext2_get_blocks() static.

Signed-off-by: Adrian Bunk <[email protected]>

--- linux-2.6.19-rc5-mm2/fs/ext2/inode.c.old 2006-11-20 01:35:58.000000000 +0100
+++ linux-2.6.19-rc5-mm2/fs/ext2/inode.c 2006-11-20 01:36:08.000000000 +0100
@@ -574,10 +574,10 @@
* return = 0, if plain lookup failed.
* return < 0, error case.
*/
-int ext2_get_blocks(struct inode *inode,
- sector_t iblock, unsigned long maxblocks,
- struct buffer_head *bh_result,
- int create)
+static int ext2_get_blocks(struct inode *inode,
+ sector_t iblock, unsigned long maxblocks,
+ struct buffer_head *bh_result,
+ int create)
{
int err = -EIO;
int offsets[4];

2006-11-20 02:28:13

[permalink] [raw]

Subject: [-mm patch] drivers/scsi/scsi_scan.c: make 2 functions static

On Tue, Nov 14, 2006 at 01:41:25AM -0800, Andrew Morton wrote:
>...
> Changes since 2.6.19-rc5-mm2:
>...
> git-scsi-misc.patch
>...
> git trees
>...

This patch makes two needlessly global functions static.

Signed-off-by: Adrian Bunk <[email protected]>

---

drivers/scsi/scsi_scan.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)

--- linux-2.6.19-rc5-mm2/drivers/scsi/scsi_scan.c.old 2006-11-20 00:57:44.000000000 +0100
+++ linux-2.6.19-rc5-mm2/drivers/scsi/scsi_scan.c 2006-11-20 00:58:05.000000000 +0100
@@ -1633,7 +1633,7 @@
* that other asynchronous scans started after this one won't affect the
* ordering of the discovered devices.
*/
-struct async_scan_data *scsi_prep_async_scan(struct Scsi_Host *shost)
+static struct async_scan_data *scsi_prep_async_scan(struct Scsi_Host *shost)
{
struct async_scan_data *data;

@@ -1677,7 +1677,7 @@
* This function announces all the devices it has found to the rest
* of the system.
*/
-void scsi_finish_async_scan(struct async_scan_data *data)
+static void scsi_finish_async_scan(struct async_scan_data *data)
{
struct Scsi_Host *shost;

2006-11-20 02:34:29

by Matthew Wilcox

[permalink] [raw]

Subject: Re: [-mm patch] drivers/scsi/scsi_scan.c: make 2 functions static

On Mon, Nov 20, 2006 at 03:23:52AM +0100, Adrian Bunk wrote:
> This patch makes two needlessly global functions static.

NAK, it's already in my scsi-async-scan tree which should be included
before the 2.6.20 merge.

2006-11-20 16:19:25

[permalink] [raw]

Subject: Re: Boot failure with ext2 and initrds

On Thu, 16 Nov 2006, Andrew Morton wrote:
> On Thu, 16 Nov 2006 12:15:16 -0800
> Mingming Cao <[email protected]> wrote:
> > On Thu, 2006-11-16 at 01:13 -0800, Andrew Morton wrote:
> > >
> > > I assume that the while (1) loop in ext3_try_to_allocate_with_rsv() has
> > > gone infinite. I don't see why, but more staring is needed.
> >
> > The loop should not go forever, it will stops when there is no window
> > with free bit to reserve in the given block group.
>
> It seems to have done so in Hugh's testing, but there's some question there
> now. Although I didn't check to see if there's a significant difference
> between Hugh's patch and mine.

After four days of running, the EM64T has at last reproduced the same
hang as it did in an hour before: stuck in ext2_try_to_allocate_with_rsv,
repeatedly ext2_rsv_window_add, ext2_try_to_allocate, rsv_window_remove
(perhaps not in that order).

But somehow I've screwed up, and before I'd extracted any new info,
kdb was spinning on its own kdb_printf_lock, and then the box completely
frozen: nothing for it but to reboot.

Grrrr.

Well: at least this resolves the doubt I raised earlier, whether
I'd been testing with the right ext2 patch. This time was definitely
with your patch not my two-liner: your original patch from Tuesday 14 Nov,
ext2-reservations-bring-ext2-reservations-code-in-line-with-latest-ext3-fix

Various other patches have come into -mm (one gone) since then, but I've
been running just with that: so far as I can see, none of the later ones
should be important in my case - the filesystem is too small for the
difference between int and ext2_fsblk_t to become important, and
neither "ld" nor "as" (the writer this time) does MAP_SHARED pageout.

I'll do a little staring at the code myself: I'm unlikely to notice
anything you've missed, but there's just a chance staring at it will
direct me to some detail I've jotted down from before.

Hugh

2006-11-20 16:44:48

by Takashi Iwai

[permalink] [raw]

Subject: Re: [Alsa-devel] [-mm patch] make sound/pci/hda/patch_sigmatel.c:stac92xx_dmic_labels[] static

At Sat, 18 Nov 2006 00:58:20 +0100,
Adrian Bunk wrote:
>
> On Tue, Nov 14, 2006 at 01:41:25AM -0800, Andrew Morton wrote:
> >...
> > Changes since 2.6.19-rc5-mm2:
> >...
> > git-alsa.patch
> >...
> > git trees
> >...
>
> This patch makes the needlessly global stac92xx_dmic_labels[] static.
>
> Signed-off-by: Adrian Bunk <[email protected]>

Thanks, fixed on ALSA tree now.

Takashi

>
> --- linux-2.6.19-rc5-mm2/sound/pci/hda/patch_sigmatel.c.old 2006-11-17 18:36:16.000000000 +0100
> +++ linux-2.6.19-rc5-mm2/sound/pci/hda/patch_sigmatel.c 2006-11-17 18:36:26.000000000 +0100
> @@ -1201,7 +1201,7 @@
> }
>
> /* labels for dmic mux inputs */
> -const char *stac92xx_dmic_labels[5] = {
> +static const char *stac92xx_dmic_labels[5] = {
> "Analog Inputs", "Digital Mic 1", "Digital Mic 2",
> "Digital Mic 3", "Digital Mic 4"
> };
>
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Alsa-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/alsa-devel
>

2006-11-20 20:54:07

[permalink] [raw]

Subject: Re: Boot failure with ext2 and initrds

On Mon, 20 Nov 2006, Hugh Dickins wrote:
>
> I'll do a little staring at the code myself: I'm unlikely to notice
> anything you've missed, but there's just a chance staring at it will
> direct me to some detail I've jotted down from before.

Not found anything relevant, but I keep noticing these lines
in ext2_try_to_allocate_with_rsv(), ext3 and ext4 similar:

} else if (grp_goal > 0 &&
(my_rsv->rsv_end - grp_goal + 1) < *count)
try_to_extend_reservation(my_rsv, sb,
*count-my_rsv->rsv_end + grp_goal - 1);

They're wrong, a no-op in most groups, aren't they? rsv_end is an
absolute block number, whereas grp_goal is group-relative, so the
calculation ought to bring in group_first_block? Or I'm confused.

(Whereas in my hang the grp_goal to ext2_try_to_allocate was -1
when I looked, with group 0 and num 1.)

Hugh

2006-11-21 00:55:57

by David Miller

[permalink] [raw]

Subject: Re: [-mm patch] make net/core/skbuff.c:skb_over_panic() static

From: Adrian Bunk <[email protected]>
Date: Fri, 17 Nov 2006 18:02:05 +0100

> skb_over_panic() can now become static.
>
> Signed-off-by: Adrian Bunk <[email protected]>

Applied to net-2.6.20, thanks Adrian.

2006-11-21 01:36:11

[permalink] [raw]

Subject: Re: Boot failure with ext2 and initrds

On Mon, 2006-11-20 at 20:54 +0000, Hugh Dickins wrote:
> Not found anything relevant, but I keep noticing these lines
> in ext2_try_to_allocate_with_rsv(), ext3 and ext4 similar:
>
> } else if (grp_goal > 0 &&
> (my_rsv->rsv_end - grp_goal + 1) < *count)
> try_to_extend_reservation(my_rsv, sb,
> *count-my_rsv->rsv_end + grp_goal - 1);
>
> They're wrong, a no-op in most groups, aren't they? rsv_end is an
> absolute block number, whereas grp_goal is group-relative, so the
> calculation ought to bring in group_first_block? Or I'm confused.
>

You are right, thanks. Here are two patches, to fix this bug in ext3/4
and ext2 correspondingly.

Signed-Off-By: Mingming Cao <[email protected]>

---

linux-2.6.19-rc5-cmm/fs/ext3/balloc.c | 12 ++++++++----
linux-2.6.19-rc5-cmm/fs/ext4/balloc.c | 12 ++++++++----
2 files changed, 16 insertions(+), 8 deletions(-)

diff -puN fs/ext3/balloc.c~ext34_extend_reservation_window_fix fs/ext3/balloc.c
--- linux-2.6.19-rc5/fs/ext3/balloc.c~ext34_extend_reservation_window_fix 2006-11-20 15:58:11.000000000 -0800
+++ linux-2.6.19-rc5-cmm/fs/ext3/balloc.c 2006-11-20 15:58:11.000000000 -0800
@@ -1307,10 +1307,14 @@ ext3_try_to_allocate_with_rsv(struct sup
if (!goal_in_my_reservation(&my_rsv->rsv_window,
grp_goal, group, sb))
grp_goal = -1;
- } else if (grp_goal > 0 &&
- (my_rsv->rsv_end-grp_goal+1) < *count)
- try_to_extend_reservation(my_rsv, sb,
- *count-my_rsv->rsv_end + grp_goal - 1);
+ } else if (grp_goal > 0) {
+ int curr = my_rsv->rsv_end -
+ (grp_goal + group_first_block) + 1;
+
+ if (curr < *count)
+ try_to_extend_reservation(my_rsv, sb,
+ *count - curr);
+ }

if ((my_rsv->rsv_start > group_last_block) ||
(my_rsv->rsv_end < group_first_block)) {
diff -puN fs/ext4/balloc.c~ext34_extend_reservation_window_fix fs/ext4/balloc.c
--- linux-2.6.19-rc5/fs/ext4/balloc.c~ext34_extend_reservation_window_fix 2006-11-20 15:58:11.000000000 -0800
+++ linux-2.6.19-rc5-cmm/fs/ext4/balloc.c 2006-11-20 15:58:11.000000000 -0800
@@ -1324,10 +1324,14 @@ ext4_try_to_allocate_with_rsv(struct sup
if (!goal_in_my_reservation(&my_rsv->rsv_window,
grp_goal, group, sb))
grp_goal = -1;
- } else if (grp_goal > 0 &&
- (my_rsv->rsv_end-grp_goal+1) < *count)
- try_to_extend_reservation(my_rsv, sb,
- *count-my_rsv->rsv_end + grp_goal - 1);
+ } else if (grp_goal > 0) {
+ int curr = my_rsv->rsv_end -
+ (grp_goal + group_first_block) + 1;
+
+ if (curr < *count)
+ try_to_extend_reservation(my_rsv, sb,
+ *count - curr);
+ }

if ((my_rsv->rsv_start > group_last_block) ||
(my_rsv->rsv_end < group_first_block)) {

Sync up ext2 with ext3/4 for the extend reservation window bug.

Signed-Off-By: Mingming Cao <[email protected]>

---

linux-2.6.19-rc5-cmm/fs/ext2/balloc.c | 12 ++++++++----
1 file changed, 8 insertions(+), 4 deletions(-)

diff -puN fs/ext2/balloc.c~ext2_reservation_extend_window_fix fs/ext2/balloc.c
--- linux-2.6.19-rc5/fs/ext2/balloc.c~ext2_reservation_extend_window_fix 2006-11-20 16:05:36.000000000 -0800
+++ linux-2.6.19-rc5-cmm/fs/ext2/balloc.c 2006-11-20 16:05:36.000000000 -0800
@@ -1091,10 +1091,14 @@ ext2_try_to_allocate_with_rsv(struct sup
if (!goal_in_my_reservation(&my_rsv->rsv_window,
grp_goal, group, sb))
grp_goal = -1;
- } else if (grp_goal > 0 &&
- (my_rsv->rsv_end - grp_goal + 1) < *count)
- try_to_extend_reservation(my_rsv, sb,
- *count-my_rsv->rsv_end + grp_goal - 1);
+ } else if (grp_goal > 0) {
+ int curr = my_rsv->rsv_end -
+ (grp_goal + group_first_block) + 1;
+
+ if (curr < *count)
+ try_to_extend_reservation(my_rsv, sb,
+ *count - curr);
+ }

if ((my_rsv->rsv_start >=
group_first_block + EXT2_BLOCKS_PER_GROUP(sb))

_

2006-11-21 01:39:13

by David Miller

[permalink] [raw]

Subject: Re: [-mm patch] make net/core/skbuff.c:skb_over_panic() static

From: David Miller <[email protected]>
Date: Mon, 20 Nov 2006 19:55:56 -0500 (EST)

> From: Adrian Bunk <[email protected]>
> Date: Fri, 17 Nov 2006 18:02:05 +0100
>
> > skb_over_panic() can now become static.
> >
> > Signed-off-by: Adrian Bunk <[email protected]>
>
> Applied to net-2.6.20, thanks Adrian.

I just realized this requires a patch already in -mm which
isn't in my tree.

Sorry about that.

I really doubt I'll put that skb_put() patch into my tree,
ever, we can just remove the debugging checks or make them
conditional to keep the inline.

2006-11-21 01:40:33

[permalink] [raw]

Subject: Re: [-mm patch] make net/core/skbuff.c:skb_over_panic() static

On Mon, 20 Nov 2006 19:55:56 -0500 (EST)
David Miller <[email protected]> wrote:

> From: Adrian Bunk <[email protected]>
> Date: Fri, 17 Nov 2006 18:02:05 +0100
>
> > skb_over_panic() can now become static.
> >
> > Signed-off-by: Adrian Bunk <[email protected]>
>
> Applied to net-2.6.20, thanks Adrian.

Adrian's patch is only applicable if my net-uninline-skb_put.patch is also
applied.

I'm not sure what to do with net-uninline-skb_put.patch. It's a good patch
if all that deudgging stuff is present in skb_put(), but it's a bad patch
if it isn't present. But it _is_ present.

2006-11-21 01:40:47

by David Miller

[permalink] [raw]

Subject: Re: [-mm patch] make net/core/skbuff.c:skb_over_panic() static

From: Andrew Morton <[email protected]>
Date: Mon, 20 Nov 2006 17:37:16 -0800

> Adrian's patch is only applicable if my net-uninline-skb_put.patch is also
> applied.

I just realized that, see the email I just sent out.

> I'm not sure what to do with net-uninline-skb_put.patch. It's a
> good patch if all that deudgging stuff is present in skb_put(), but
> it's a bad patch if it isn't present. But it _is_ present.

Keep it in your tree if you want, it's never going into mine :)

2006-11-21 01:47:40

[permalink] [raw]

Subject: Re: Boot failure with ext2 and initrds

On Mon, 2006-11-20 at 16:19 +0000, Hugh Dickins wrote:
> On Thu, 16 Nov 2006, Andrew Morton wrote:
> > On Thu, 16 Nov 2006 12:15:16 -0800
> > Mingming Cao <[email protected]> wrote:
> > > On Thu, 2006-11-16 at 01:13 -0800, Andrew Morton wrote:
> > > >
> > > > I assume that the while (1) loop in ext3_try_to_allocate_with_rsv() has
> > > > gone infinite. I don't see why, but more staring is needed.
> > >
> > > The loop should not go forever, it will stops when there is no window
> > > with free bit to reserve in the given block group.
> >
> > It seems to have done so in Hugh's testing, but there's some question there
> > now. Although I didn't check to see if there's a significant difference
> > between Hugh's patch and mine.
>
> After four days of running, the EM64T has at last reproduced the same
> hang as it did in an hour before: stuck in ext2_try_to_allocate_with_rsv,
> repeatedly ext2_rsv_window_add, ext2_try_to_allocate, rsv_window_remove
> (perhaps not in that order).
>
> But somehow I've screwed up, and before I'd extracted any new info,
> kdb was spinning on its own kdb_printf_lock, and then the box completely
> frozen: nothing for it but to reboot.
>
> Grrrr.
>
> Well: at least this resolves the doubt I raised earlier, whether
> I'd been testing with the right ext2 patch. This time was definitely
> with your patch not my two-liner: your original patch from Tuesday 14 Nov,
> ext2-reservations-bring-ext2-reservations-code-in-line-with-latest-ext3-fix
>
> Various other patches have come into -mm (one gone) since then, but I've
> been running just with that: so far as I can see, none of the later ones
> should be important in my case - the filesystem is too small for the
> difference between int and ext2_fsblk_t to become important, and
> neither "ld" nor "as" (the writer this time) does MAP_SHARED pageout.
>

So there is only one writer at the moment the hang was happening?

hmm, is the filesystem relatively all being used or reserved, i.e, the
free bits are all being reserved? There is one extreme case that may
cause starvation. If filesystem free blocks are all being reserved, when
a new writer need a free block, it has to go through the entire
filesystems, try to reserve a space, which will repeatly calling
rsv_window_add and rsv_window_remove, since. Finally give up and fall
back to allocation without reservation. But this is all theory, not sure
fits your case here.

2006-11-21 05:38:55

[permalink] [raw]

Subject: Re: Boot failure with ext2 and initrds

On Mon, 20 Nov 2006, Mingming Cao wrote:
>
> So there is only one writer at the moment the hang was happening?

I expect there were multiple writers when the task which hangs
first entered its ext2_prepare_write (it's a make -j20 build on
that ext2 filesystem); but by the time I come to look at the hang,
there's only that one writer active - everything else would be waiting
on that part of the build to complete (well, your question makes me
realize that I didn't look down the whole "ps" listing to see what
was waiting; but the hanging task is the only one I see running on
on any cpu, each time I break in).

>
> hmm, is the filesystem relatively all being used or reserved, i.e, the
> free bits are all being reserved? There is one extreme case that may
> cause starvation. If filesystem free blocks are all being reserved, when
> a new writer need a free block, it has to go through the entire
> filesystems, try to reserve a space, which will repeatly calling
> rsv_window_add and rsv_window_remove, since. Finally give up and fall
> back to allocation without reservation. But this is all theory, not sure
> fits your case here.

I can understand that there may be a worst case like that: but I hope
it wouldn't take 20 hours to find a free block on a default 340MB ext2
filesystem! And unless something else has gone wrong, this build would
not be filling the filesystem to that extent: it's probably around 80%
full at this stage, and shouldn't get fuller than 98% in the end.

Any suggestions for what I might check, next time it happens?

Hugh

2006-11-21 18:37:07

[permalink] [raw]

Subject: -mm: please drop reiser4-export-handle_ra_miss.patch

Andrew,

please drop reiser4-export-handle_ra_miss.patch, this patch was
obsoleted by reiser4-simplify-reading-of-partially-converted-files.patch.

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

2006-11-21 19:42:19

[permalink] [raw]

Subject: [-mm patch] unexport {,__}remove_from_page_cache

This patch removes the no longer required export of
{,__}remove_from_page_cache introduced by
reiser4-export-remove_from_page_cache.patch.

Signed-off-by: Adrian Bunk <[email protected]>

--- linux-2.6.19-rc5-mm2/mm/filemap.c.old 2006-11-21 19:48:44.000000000 +0100
+++ linux-2.6.19-rc5-mm2/mm/filemap.c 2006-11-21 19:48:51.000000000 +0100
@@ -127,7 +127,6 @@
mapping->nrpages--;
__dec_zone_page_state(page, NR_FILE_PAGES);
}
-EXPORT_SYMBOL(__remove_from_page_cache);

void remove_from_page_cache(struct page *page)
{
@@ -139,7 +138,6 @@
__remove_from_page_cache(page);
write_unlock_irq(&mapping->tree_lock);
}
-EXPORT_SYMBOL(remove_from_page_cache);

static int sync_page(void *word)
{

2006-11-22 00:43:17

[permalink] [raw]

Subject: Re: Boot failure with ext2 and initrds

On Mon, 2006-11-20 at 16:19 +0000, Hugh Dickins wrote:
> After four days of running, the EM64T has at last reproduced the same
> hang as it did in an hour before: stuck in
> ext2_try_to_allocate_with_rsv,
> repeatedly ext2_rsv_window_add, ext2_try_to_allocate,
> rsv_window_remove
> (perhaps not in that order).
>

Don't have much clue, still...:(

The logic of the while loop in ext2_try_to_allocate_with_rsv() looks
like:

while (1) {
/*make a new reservation window*/
ret = allocate_new_reservation();
if (ret < 0)
break /*fail*/
/*allocate a block from the reservation window */
ret = ext2_try_to_allocate_with_rsv()
if (ret > 0) {
...
break; /*success*/
}
}
If it stucks in the loop, that means next two things have to be true:

1) ext2_try_to_allocate() keeps failing to allocate a bit from the
window just reserved, every time.

2) we could endlessly create a new reservation window in this block
group.

For (1), when create a new reservation window, we do make sure there are
at least one free bit in the window, so that
ext2_try_to_allocate_with_rsv() could claim that bit. I haven't found
any thing wrong in that part yet;

For (2)the search for the next reservation window should start from the
end block of the old window, and should stop and fail if it reachs the
last block of the block group.

Will continue looking at the code, but so far everything looks just fine
to me.:(

On Tue, 2006-11-21 at 05:39 +0000, Hugh Dickins wrote:
> On Mon, 20 Nov 2006, Mingming Cao wrote:
> >
> > So there is only one writer at the moment the hang was happening?
>
> I expect there were multiple writers when the task which hangs
> first entered its ext2_prepare_write (it's a make -j20 build on
> that ext2 filesystem); but by the time I come to look at the hang,
> there's only that one writer active - everything else would be waiting
> on that part of the build to complete
> (well, your question makes me
> realize that I didn't look down the whole "ps" listing to see what
> was waiting; but the hanging task is the only one I see running on
> on any cpu, each time I break in).
>
A bit confused, did the whole system hang or just the "ld" writer hang
in ext2 block allocation? And what other writers were waiting for? Were
they trying to write to the same file?

> >
> > hmm, is the filesystem relatively all being used or reserved, i.e, the
> > free bits are all being reserved? There is one extreme case that may
> > cause starvation. If filesystem free blocks are all being reserved, when
> > a new writer need a free block, it has to go through the entire
> > filesystems, try to reserve a space, which will repeatly calling
> > rsv_window_add and rsv_window_remove, since. Finally give up and fall
> > back to allocation without reservation. But this is all theory, not sure
> > fits your case here.
>
> I can understand that there may be a worst case like that: but I hope
> it wouldn't take 20 hours to find a free block on a default 340MB ext2
> filesystem! And unless something else has gone wrong, this build would
> not be filling the filesystem to that extent: it's probably around 80%
> full at this stage, and shouldn't get fuller than 98% in the end.
>
> Any suggestions for what I might check, next time it happens?
>

It might be helpful to check the return value of ext2_try_to_allocate(),
to see if it fails. It would be nice if you could check if there any
free bit inside the reservation window.

And could you check the start and end block for every rsv_window_add and
rsv_window_remove, to see if it was keep creating and removing the same
window in the same block group?

And it might be useful to dump the whole filesystem block reservation
tree as well.

Not sure if it worth the effort to test it on ext3. The ext2 block
reservation code in 2.6.19-rc5-mm2 looks pretty much the same as ext3/4,
except the missing truncate_mutex. I understand this might take a few
days to reproduce, so this might not needed now.

Mingming
> Hugh
> -
> To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html

2006-11-22 03:23:43

[permalink] [raw]

Subject: 2.6.19-rc5-mm2: suspend related BLOCK=n compile error

swsusp-freeze-filesystems-during-suspend-rev-2.patch causes the
following compile error with CONFIG_BLOCK=n:

<-- snip -->

...
CC kernel/power/process.o
/home/bunk/linux/kernel-2.6/linux-2.6.19-rc5-mm2/kernel/power/process.c: In function 'freeze_processes':
/home/bunk/linux/kernel-2.6/linux-2.6.19-rc5-mm2/kernel/power/process.c:124: error: implicit declaration of function 'freeze_filesystems'
/home/bunk/linux/kernel-2.6/linux-2.6.19-rc5-mm2/kernel/power/process.c: In function 'thaw_processes':
/home/bunk/linux/kernel-2.6/linux-2.6.19-rc5-mm2/kernel/power/process.c:189: error: implicit declaration of function 'thaw_filesystems'
make[3]: *** [kernel/power/process.o] Error 1

<-- snip -->

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

2006-11-22 03:36:27

by Randy Dunlap

[permalink] [raw]

Subject: Re: 2.6.19-rc5-mm2: suspend related BLOCK=n compile error

On Wed, 22 Nov 2006 04:23:41 +0100 Adrian Bunk wrote:

> swsusp-freeze-filesystems-during-suspend-rev-2.patch causes the
> following compile error with CONFIG_BLOCK=n:
>
> <-- snip -->
>
> ...
> CC kernel/power/process.o
> /home/bunk/linux/kernel-2.6/linux-2.6.19-rc5-mm2/kernel/power/process.c: In function 'freeze_processes':
> /home/bunk/linux/kernel-2.6/linux-2.6.19-rc5-mm2/kernel/power/process.c:124: error: implicit declaration of function 'freeze_filesystems'
> /home/bunk/linux/kernel-2.6/linux-2.6.19-rc5-mm2/kernel/power/process.c: In function 'thaw_processes':
> /home/bunk/linux/kernel-2.6/linux-2.6.19-rc5-mm2/kernel/power/process.c:189: error: implicit declaration of function 'thaw_filesystems'
> make[3]: *** [kernel/power/process.o] Error 1

Yes, I sent a patch for that, but Pavel said that they will be
removing/dropping that code anyway.

---
~Randy

2006-11-22 04:18:18

[permalink] [raw]

Subject: [-mm patch] fs/fscache/main.c: cleanups

This patch contains the following cleanups:
- remove the unused global variable fscache_debug
- make the needlessly global struct fscache_kset static

Signed-off-by: Adrian Bunk <[email protected]>

---

fs/fscache/main.c | 6 +-----
1 file changed, 1 insertion(+), 5 deletions(-)

--- linux-2.6.19-rc5-mm2/fs/fscache/main.c.old 2006-11-22 03:08:53.000000000 +0100
+++ linux-2.6.19-rc5-mm2/fs/fscache/main.c 2006-11-22 03:09:23.000000000 +0100
@@ -16,8 +16,6 @@
#include <linux/slab.h>
#include "fscache-int.h"

-int fscache_debug;
-
static int fscache_init(void);
static void fscache_exit(void);

@@ -41,14 +39,12 @@ static struct kobj_type fscache_ktype =
.default_attrs = NULL,
};

-struct kset fscache_kset = {
+static struct kset fscache_kset = {
.kobj.name = "fscache",
.kobj.kset = &fs_subsys.kset,
.ktype = &fscache_ktype,
};

-EXPORT_SYMBOL(fscache_kset);
-
/*****************************************************************************/
/*
* initialise the fs caching module

2006-11-22 04:18:05

[permalink] [raw]

Subject: [-mm patch] CACHEFILES must depend on PROC_FS

I got the following compile error with CONFIG_PROC_FS=n:

<-- snip -->

...
CC fs/cachefiles/cf-main.o
/home/bunk/linux/kernel-2.6/linux-2.6.19-rc5-mm2/fs/cachefiles/cf-main.c: In function 'cachefiles_init':
/home/bunk/linux/kernel-2.6/linux-2.6.19-rc5-mm2/fs/cachefiles/cf-main.c:77: error: 'proc_root_fs' undeclared (first use in this function)
/home/bunk/linux/kernel-2.6/linux-2.6.19-rc5-mm2/fs/cachefiles/cf-main.c:77: error: (Each undeclared identifier is reported only once
/home/bunk/linux/kernel-2.6/linux-2.6.19-rc5-mm2/fs/cachefiles/cf-main.c:77: error: for each function it appears in.)
make[3]: *** [fs/cachefiles/cf-main.o] Error 1

<-- snip -->

This patch adds the missing dependency of CACHEFILES on PROC_FS.

Signed-off-by: Adrian Bunk <[email protected]>

--- linux-2.6.19-rc5-mm2/fs/Kconfig.old 2006-11-22 02:48:36.000000000 +0100
+++ linux-2.6.19-rc5-mm2/fs/Kconfig 2006-11-22 02:49:01.000000000 +0100
@@ -654,6 +654,7 @@ config FSCACHE

config CACHEFILES
tristate "Filesystem caching on files"
+ depends on PROC_FS
select FSCACHE
help
This permits use of a mounted filesystem as a cache for other

2006-11-22 04:38:13

[permalink] [raw]

Subject: [-mm patch] drivers/mtd/nand/rtc_from4.c: use lib/bitrev.c

This patch converts drivers/mtd/nand/rtc_from4.c to use the new
lib/bitrev.c

Signed-off-by: Adrian Bunk <[email protected]>

---

drivers/mtd/nand/Kconfig | 1
drivers/mtd/nand/rtc_from4.c | 44 +----------------------------------
2 files changed, 3 insertions(+), 42 deletions(-)

--- linux-2.6.19-rc5-mm2/drivers/mtd/nand/Kconfig.old 2006-11-22 05:23:38.000000000 +0100
+++ linux-2.6.19-rc5-mm2/drivers/mtd/nand/Kconfig 2006-11-22 05:23:52.000000000 +0100
@@ -90,6 +90,7 @@
depends on MTD_NAND && SH_SOLUTION_ENGINE
select REED_SOLOMON
select REED_SOLOMON_DEC8
+ select BITREVERSE
help
This enables the driver for the Renesas Technology AG-AND
flash interface board (FROM_BOARD4)
--- linux-2.6.19-rc5-mm2/drivers/mtd/nand/rtc_from4.c.old 2006-11-22 05:22:37.000000000 +0100
+++ linux-2.6.19-rc5-mm2/drivers/mtd/nand/rtc_from4.c 2006-11-22 05:24:31.000000000 +0100
@@ -24,6 +24,7 @@
#include <linux/init.h>
#include <linux/slab.h>
#include <linux/rslib.h>
+#include <linux/bitrev.h>
#include <linux/module.h>
#include <linux/mtd/compatmac.h>
#include <linux/mtd/mtd.h>
@@ -152,47 +153,6 @@
.oobfree = {{32, 32}}
};

-/* Aargh. I missed the reversed bit order, when I
- * was talking to Renesas about the FPGA.
- *
- * The table is used for bit reordering and inversion
- * of the ecc byte which we get from the FPGA
- */
-static uint8_t revbits[256] = {
- 0x00, 0x80, 0x40, 0xc0, 0x20, 0xa0, 0x60, 0xe0,
- 0x10, 0x90, 0x50, 0xd0, 0x30, 0xb0, 0x70, 0xf0,
- 0x08, 0x88, 0x48, 0xc8, 0x28, 0xa8, 0x68, 0xe8,
- 0x18, 0x98, 0x58, 0xd8, 0x38, 0xb8, 0x78, 0xf8,
- 0x04, 0x84, 0x44, 0xc4, 0x24, 0xa4, 0x64, 0xe4,
- 0x14, 0x94, 0x54, 0xd4, 0x34, 0xb4, 0x74, 0xf4,
- 0x0c, 0x8c, 0x4c, 0xcc, 0x2c, 0xac, 0x6c, 0xec,
- 0x1c, 0x9c, 0x5c, 0xdc, 0x3c, 0xbc, 0x7c, 0xfc,
- 0x02, 0x82, 0x42, 0xc2, 0x22, 0xa2, 0x62, 0xe2,
- 0x12, 0x92, 0x52, 0xd2, 0x32, 0xb2, 0x72, 0xf2,
- 0x0a, 0x8a, 0x4a, 0xca, 0x2a, 0xaa, 0x6a, 0xea,
- 0x1a, 0x9a, 0x5a, 0xda, 0x3a, 0xba, 0x7a, 0xfa,
- 0x06, 0x86, 0x46, 0xc6, 0x26, 0xa6, 0x66, 0xe6,
- 0x16, 0x96, 0x56, 0xd6, 0x36, 0xb6, 0x76, 0xf6,
- 0x0e, 0x8e, 0x4e, 0xce, 0x2e, 0xae, 0x6e, 0xee,
- 0x1e, 0x9e, 0x5e, 0xde, 0x3e, 0xbe, 0x7e, 0xfe,
- 0x01, 0x81, 0x41, 0xc1, 0x21, 0xa1, 0x61, 0xe1,
- 0x11, 0x91, 0x51, 0xd1, 0x31, 0xb1, 0x71, 0xf1,
- 0x09, 0x89, 0x49, 0xc9, 0x29, 0xa9, 0x69, 0xe9,
- 0x19, 0x99, 0x59, 0xd9, 0x39, 0xb9, 0x79, 0xf9,
- 0x05, 0x85, 0x45, 0xc5, 0x25, 0xa5, 0x65, 0xe5,
- 0x15, 0x95, 0x55, 0xd5, 0x35, 0xb5, 0x75, 0xf5,
- 0x0d, 0x8d, 0x4d, 0xcd, 0x2d, 0xad, 0x6d, 0xed,
- 0x1d, 0x9d, 0x5d, 0xdd, 0x3d, 0xbd, 0x7d, 0xfd,
- 0x03, 0x83, 0x43, 0xc3, 0x23, 0xa3, 0x63, 0xe3,
- 0x13, 0x93, 0x53, 0xd3, 0x33, 0xb3, 0x73, 0xf3,
- 0x0b, 0x8b, 0x4b, 0xcb, 0x2b, 0xab, 0x6b, 0xeb,
- 0x1b, 0x9b, 0x5b, 0xdb, 0x3b, 0xbb, 0x7b, 0xfb,
- 0x07, 0x87, 0x47, 0xc7, 0x27, 0xa7, 0x67, 0xe7,
- 0x17, 0x97, 0x57, 0xd7, 0x37, 0xb7, 0x77, 0xf7,
- 0x0f, 0x8f, 0x4f, 0xcf, 0x2f, 0xaf, 0x6f, 0xef,
- 0x1f, 0x9f, 0x5f, 0xdf, 0x3f, 0xbf, 0x7f, 0xff,
-};
-
#endif

/*
@@ -397,7 +357,7 @@
/* Read the syndrom pattern from the FPGA and correct the bitorder */
rs_ecc = (volatile unsigned short *)(rtc_from4_fio_base + RTC_FROM4_RS_ECC);
for (i = 0; i < 8; i++) {
- ecc[i] = revbits[(*rs_ecc) & 0xFF];
+ ecc[i] = byte_rev_table[(*rs_ecc) & 0xFF];
rs_ecc++;
}

2006-11-22 04:39:00

by Randy Dunlap

[permalink] [raw]

Subject: Re: [-mm patch] CACHEFILES must depend on PROC_FS

On Wed, 22 Nov 2006 05:17:36 +0100 Adrian Bunk wrote:

> I got the following compile error with CONFIG_PROC_FS=n:
>
> <-- snip -->
>
> ...
> CC fs/cachefiles/cf-main.o
> /home/bunk/linux/kernel-2.6/linux-2.6.19-rc5-mm2/fs/cachefiles/cf-main.c: In function 'cachefiles_init':
> /home/bunk/linux/kernel-2.6/linux-2.6.19-rc5-mm2/fs/cachefiles/cf-main.c:77: error: 'proc_root_fs' undeclared (first use in this function)
> /home/bunk/linux/kernel-2.6/linux-2.6.19-rc5-mm2/fs/cachefiles/cf-main.c:77: error: (Each undeclared identifier is reported only once
> /home/bunk/linux/kernel-2.6/linux-2.6.19-rc5-mm2/fs/cachefiles/cf-main.c:77: error: for each function it appears in.)
> make[3]: *** [fs/cachefiles/cf-main.o] Error 1
>
> <-- snip -->
>
> This patch adds the missing dependency of CACHEFILES on PROC_FS.
>
> Signed-off-by: Adrian Bunk <[email protected]>
>
> --- linux-2.6.19-rc5-mm2/fs/Kconfig.old 2006-11-22 02:48:36.000000000 +0100
> +++ linux-2.6.19-rc5-mm2/fs/Kconfig 2006-11-22 02:49:01.000000000 +0100
> @@ -654,6 +654,7 @@ config FSCACHE
>
> config CACHEFILES
> tristate "Filesystem caching on files"
> + depends on PROC_FS
> select FSCACHE
> help
> This permits use of a mounted filesystem as a cache for other

I made that same patch (on linux-fsdevel). David Howells replied:

Randy Dunlap <[email protected]> wrote:

> CACHEFILES uses PROC_FS, so make it a Kconfig depends.

Thanks, but the new and improved CacheFiles doesn't use procfs as Christoph
Hellwig objects to such a practice. In any case, Andrew Morton has dropped it
from -mm as it's now obsolete.

---
~Randy

2006-11-22 11:24:43

by Rafael J. Wysocki

[permalink] [raw]

Subject: Re: 2.6.19-rc5-mm2: suspend related BLOCK=n compile error

On Wednesday, 22 November 2006 04:34, Randy Dunlap wrote:
> On Wed, 22 Nov 2006 04:23:41 +0100 Adrian Bunk wrote:
>
> > swsusp-freeze-filesystems-during-suspend-rev-2.patch causes the
> > following compile error with CONFIG_BLOCK=n:
> >
> > <-- snip -->
> >
> > ...
> > CC kernel/power/process.o
> > /home/bunk/linux/kernel-2.6/linux-2.6.19-rc5-mm2/kernel/power/process.c: In function 'freeze_processes':
> > /home/bunk/linux/kernel-2.6/linux-2.6.19-rc5-mm2/kernel/power/process.c:124: error: implicit declaration of function 'freeze_filesystems'
> > /home/bunk/linux/kernel-2.6/linux-2.6.19-rc5-mm2/kernel/power/process.c: In function 'thaw_processes':
> > /home/bunk/linux/kernel-2.6/linux-2.6.19-rc5-mm2/kernel/power/process.c:189: error: implicit declaration of function 'thaw_filesystems'
> > make[3]: *** [kernel/power/process.o] Error 1
>
> Yes, I sent a patch for that, but Pavel said that they will be
> removing/dropping that code anyway.

AFAICT, the swsusp-freeze-filesystems-during-suspend-rev-2.patch has been
dropped from -mm already.

Greetings,
Rafael

--
You never change things by fighting the existing reality.
R. Buckminster Fuller

2006-11-24 08:43:26

by Greg KH

[permalink] [raw]

Subject: Re: ohci1394 oops bisected [was Re: 2.6.19-rc5-mm2 (Oops in class_device_remove_attrs during nodemgr_remove_host)]

On Sun, Nov 19, 2006 at 10:01:06PM +0100, Stefan Richter wrote:
> Andrew Morton wrote:
> > On Sun, 19 Nov 2006 18:13:45 +0100
> > Stefan Richter <[email protected]> wrote:
> >> Looks very much like eth1394's sysfs interface is getting
> >> in the way. And since it is entirely handled by the ieee1394 core, it
> >> means ieee1394 needs the class_dev to dev treatment. I think it's OK if
> >> we just wait for Greg to finish his preliminary patch. Until then,
> >> CONFIG_IEEE1394_ETH1394=n should avoid the oops. (Or Andrew marks
> >> eth1394 broken or removes gregkh-driver-network-device.patch...)
> >
> > Do we know what's actually wrong, and what needs to be done about it?
>
> I for one don't know what's needed precisely. But at the moment I
> actually don't want to spend any more time on this because:
> - It happens only if ohci1394 is unloaded while eth1394 is loaded.
> (That's not an unusual condition though.)

Yes, I can trigger this quite easily here now.

> - It happens only in -mm, and only because -mm contains the work-in-
> progress patches for class_device -> device transition.
> I expect it to go away automatically once Greg is done with the
> transition. It seems Greg is the one to do it :-), at least I'm not
> available right now to lend a hand. There are older ieee1394 bugs in
> mainline with bigger practical impact for me to work on. If there are
> still issues once ieee1394 was converted away from class_device, I'm OK
> with revisiting it.

I'll hold off on submitting the network change to mainline until I fix
this problem, so it might be a while...

thanks for narrowing it down for me.

greg k-h

2006-11-24 17:13:17

[permalink] [raw]

Subject: Re: ohci1394 oops bisected [was Re: 2.6.19-rc5-mm2 (Oops in class_device_remove_attrs during nodemgr_remove_host)]

Greg KH wrote:
> On Sun, Nov 19, 2006 at 10:01:06PM +0100, Stefan Richter wrote:
...
>> at the moment I actually don't want to spend any more time on this
...
>> There are older ieee1394 bugs in
>> mainline with bigger practical impact for me to work on. If there are
>> still issues once ieee1394 was converted away from class_device, I'm OK
>> with revisiting it.
>
> I'll hold off on submitting the network change to mainline until I fix
> this problem, so it might be a while...

In case you find the ieee1394 stack doing weird things to the driver
core, point it out. I'm not good at analyzing and (re)designing such
things but I might be able to contribute once I'm given clear
directions. ;-)
--
Stefan Richter
-=====-=-==- =-== ==---
http://arcgraph.de/sr/

2006-11-25 14:59:39

[permalink] [raw]

Subject: Re: Boot failure with ext2 and initrds

On Thu, Nov 16, 2006 at 12:34:48PM +0000, Russell King wrote:
> On Wed, Nov 15, 2006 at 11:22:28PM -0800, Andrew Morton wrote:
> > On Wed, 15 Nov 2006 22:55:43 -0800
> > Mingming Cao <[email protected]> wrote:
> >
> > > Hmm, maxblocks, in bitmap_search_next_usable_block(), is the end block
> > > number of the range to search, not the lengh of the range. maxblocks
> > > get passed to ext2_find_next_zero_bit(), where it expecting to take the
> > > _size_ of the range to search instead...
> > >
> > > Something like this: (this is not a patch)
> > > @@ -524,7 +524,7 @@ bitmap_search_next_usable_block(ext2_grp
> > > ext2_grpblk_t next;
> > >
> > > - next = ext2_find_next_zero_bit(bh->b_data, maxblocks, start);
> > > + next = ext2_find_next_zero_bit(bh->b_data, maxblocks-start + 1, start);
> > > if (next >= maxblocks)
> > > return -1;
> > > return next;
> > > }
> >
> > yes, the `size' arg to find_next_zero_bit() represents the number of bits
> > to scan at `offset'.
>
> Are you sure? That's not the way it's implemented in many architectures.
> find_next_*_bit() has always taken "address, maximum offset, starting offset"
> and always has returned "next offset".
>
> Just look at arch/i386/lib/bitops.c:
>
> int find_next_zero_bit(const unsigned long *addr, int size, int offset)
> {
> unsigned long * p = ((unsigned long *) addr) + (offset >> 5);
> int set = 0, bit = offset & 31, res;
> ...
> /*
> * No zero yet, search remaining full bytes for a zero
> */
> res = find_first_zero_bit (p, size - 32 * (p - (unsigned long *) addr));
> return (offset + set + res);
> }
>
> So for the case that "offset" is aligned to a "long" boundary, that gives us:
>
> res = find_first_zero_bit(addr + (offset>>5),
> size - 32 * (addr + (offset>>5) - addr));
>
> or:
>
> res = find_first_zero_bit(addr + (offset>>5), size - (offset & ~31));
>
> So, size _excludes_ offset.
>
> Now, considering the return value, "res" above will be relative to
> "addr + (offset>>5)". However, we add "offset" on to that, so it's
> relative to addr + (offset bits).

Andrew,

Please respond to the above. If what you say is correct then all
architectures need their bitops fixing to fit ext2's requirements.

--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of:

2006-11-28 17:39:47

[permalink] [raw]

Subject: [PATCH 1/6] ext2 balloc: fix _with_rsv freeze

After several days of testing ext2 with reservations, it got caught inside
ext2_try_to_allocate_with_rsv: alloc_new_reservation repeatedly succeeding
on the window [12cff,12d0e], ext2_try_to_allocate repeatedly failing to
find the free block guaranteed to be included (unless there's contention).

Fix the range to find_next_usable_block's memscan: the scan from "here"
(0xcfe) up to (but excluding) "maxblocks" (0xd0e) needs to scan 3 bytes
not 2 (the relevant bytes of bitmap in this case being f7 df ff - none
00, but the premature cutoff implying that the last was found 00).

Is this a problem for mainline ext2? No, because the "size" in its memscan
is always EXT2_BLOCKS_PER_GROUP(sb), which mkfs.ext2 requires to be a
multiple of 8. Is this a problem for ext3 or ext4? No, because they have
an additional extN_test_allocatable test which rescues them from the error.

Signed-off-by: Hugh Dickins <[email protected]>
---
But the bigger question is, why does the my_rsv case come here to
find_next_usable_block at all? Doesn't its 64-bit boundary limit, and its
memscan, blithely ignore what the reservation prepared? It's messy too,
the complement of the memscan being that "i < 7" loop over in
ext2_try_to_allocate. I think this ought to be cleaned up,
in ext2+reservations and ext3 and ext4.

fs/ext2/balloc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- 2.6.19-rc6-mm2/fs/ext2/balloc.c 2006-11-24 08:18:02.000000000 +0000
+++ linux/fs/ext2/balloc.c 2006-11-27 19:28:41.000000000 +0000
@@ -570,7 +570,7 @@ find_next_usable_block(int start, struct
here = 0;

p = ((char *)bh->b_data) + (here >> 3);
- r = memscan(p, 0, (maxblocks - here + 7) >> 3);
+ r = memscan(p, 0, ((maxblocks + 7) >> 3) - (here >> 3));
next = (r - ((char *)bh->b_data)) << 3;

if (next < maxblocks && next >= here)

2006-11-28 17:40:33

[permalink] [raw]

Subject: [PATCH 2/6] ext2 balloc: reset windowsz when full

ext2_new_blocks should reset the reservation window size to 0 when squeezing
the last blocks out of an almost full filesystem, so the retry doesn't skip
any groups with less than half that free, reporting ENOSPC too soon.

Signed-off-by: Hugh Dickins <[email protected]>
---

fs/ext2/balloc.c | 1 +
1 file changed, 1 insertion(+)

--- 2.6.19-rc6-mm2/fs/ext2/balloc.c 2006-11-24 08:18:02.000000000 +0000
+++ linux/fs/ext2/balloc.c 2006-11-27 19:28:41.000000000 +0000
@@ -1292,6 +1292,7 @@ retry_alloc:
*/
if (my_rsv) {
my_rsv = NULL;
+ windowsz = 0;
group_no = goal_group;
goto retry_alloc;
}

2006-11-28 17:41:21

[permalink] [raw]

Subject: [PATCH 3/6] ext2 balloc: fix off-by-one against rsv_end

rsv_end is the last block within the reservation,
so alloc_new_reservation should accept start_block == rsv_end as success.

Signed-off-by: Hugh Dickins <[email protected]>
---

fs/ext2/balloc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- 2.6.19-rc6-mm2/fs/ext2/balloc.c 2006-11-24 08:18:02.000000000 +0000
+++ linux/fs/ext2/balloc.c 2006-11-27 19:28:41.000000000 +0000
@@ -950,7 +950,7 @@ retry:
* check if the first free block is within the
* free space we just reserved
*/
- if (start_block >= my_rsv->rsv_start && start_block < my_rsv->rsv_end)
+ if (start_block >= my_rsv->rsv_start && start_block <= my_rsv->rsv_end)
return 0; /* success */
/*
* if the first free bit we found is out of the reservable space

2006-11-28 17:42:24

[permalink] [raw]

Subject: [PATCH 4/6] ext2 balloc: fix off-by-one against grp_goal

grp_goal 0 is a genuine goal (unlike -1),
so ext2_try_to_allocate_with_rsv should treat it as such.

Signed-off-by: Hugh Dickins <[email protected]>
---

fs/ext2/balloc.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)

--- 2.6.19-rc6-mm2/fs/ext2/balloc.c 2006-11-24 08:18:02.000000000 +0000
+++ linux/fs/ext2/balloc.c 2006-11-27 19:28:41.000000000 +0000
@@ -1053,7 +1053,7 @@ ext2_try_to_allocate_with_rsv(struct sup
}
/*
* grp_goal is a group relative block number (if there is a goal)
- * 0 < grp_goal < EXT2_BLOCKS_PER_GROUP(sb)
+ * 0 <= grp_goal < EXT2_BLOCKS_PER_GROUP(sb)
* first block is a filesystem wide block number
* first block is the block number of the first block in this group
*/
@@ -1089,7 +1089,7 @@ ext2_try_to_allocate_with_rsv(struct sup
if (!goal_in_my_reservation(&my_rsv->rsv_window,
grp_goal, group, sb))
grp_goal = -1;
- } else if (grp_goal > 0) {
+ } else if (grp_goal >= 0) {
int curr = my_rsv->rsv_end -
(grp_goal + group_first_block) + 1;

2006-11-28 17:43:20

[permalink] [raw]

Subject: [PATCH 5/6] ext2 balloc: say rb_entry not list_entry

The reservations tree is an rb_tree not a list, so it's less confusing to
use rb_entry() than list_entry() - though they're both just container_of().

Signed-off-by: Hugh Dickins <[email protected]>
---

fs/ext2/balloc.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)

--- 2.6.19-rc6-mm2/fs/ext2/balloc.c 2006-11-24 08:18:02.000000000 +0000
+++ linux/fs/ext2/balloc.c 2006-11-27 19:28:41.000000000 +0000
@@ -156,7 +156,7 @@ restart:

printk("Block Allocation Reservation Windows Map (%s):\n", fn);
while (n) {
- rsv = list_entry(n, struct ext2_reserve_window_node, rsv_node);
+ rsv = rb_entry(n, struct ext2_reserve_window_node, rsv_node);
if (verbose)
printk("reservation window 0x%p "
"start: %lu, end: %lu\n",
@@ -753,7 +753,7 @@ static int find_next_reservable_window(

prev = rsv;
next = rb_next(&rsv->rsv_node);
- rsv = list_entry(next,struct ext2_reserve_window_node,rsv_node);
+ rsv = rb_entry(next,struct ext2_reserve_window_node,rsv_node);

/*
* Reached the last reservation, we can just append to the
@@ -995,7 +995,7 @@ static void try_to_extend_reservation(st
if (!next)
my_rsv->rsv_end += size;
else {
- next_rsv = list_entry(next, struct ext2_reserve_window_node, rsv_node);
+ next_rsv = rb_entry(next, struct ext2_reserve_window_node, rsv_node);

if ((next_rsv->rsv_start - my_rsv->rsv_end - 1) >= size)
my_rsv->rsv_end += size;

2006-11-28 17:43:57

[permalink] [raw]

Subject: [PATCH 6/6] ext2 balloc: use io_error label

ext2_new_blocks has a nice io_error label for setting -EIO,
so goto that in the one place that doesn't already use it.

Signed-off-by: Hugh Dickins <[email protected]>
---

fs/ext2/balloc.c | 7 +++----
1 file changed, 3 insertions(+), 4 deletions(-)

--- 2.6.19-rc6-mm2/fs/ext2/balloc.c 2006-11-24 08:18:02.000000000 +0000
+++ linux/fs/ext2/balloc.c 2006-11-27 19:28:41.000000000 +0000
@@ -1258,10 +1258,9 @@ retry_alloc:
if (group_no >= ngroups)
group_no = 0;
gdp = ext2_get_group_desc(sb, group_no, &gdp_bh);
- if (!gdp) {
- *errp = -EIO;
- goto out;
- }
+ if (!gdp)
+ goto io_error;
+
free_blocks = le16_to_cpu(gdp->bg_free_blocks_count);
/*
* skip this group if the number of

2006-11-28 19:26:18

[permalink] [raw]

Subject: Re: [PATCH 1/6] ext2 balloc: fix _with_rsv freeze

On Tue, 2006-11-28 at 17:40 +0000, Hugh Dickins wrote:
> After several days of testing ext2 with reservations, it got caught inside
> ext2_try_to_allocate_with_rsv: alloc_new_reservation repeatedly succeeding
> on the window [12cff,12d0e], ext2_try_to_allocate repeatedly failing to
> find the free block guaranteed to be included (unless there's contention).
>

Hmm, I suspect there is other issue: alloc_new_reservation should not
repeatedly allocating the same window, if ext2_try_to_allocate
repeatedly fails to find a free block in that window.
find_next_reservable_window() takes my_rsv (the old window that he
thinks there is no free block) as a guide to find a window "after" the
end block of my_rsv, so how could this happen?

> Fix the range to find_next_usable_block's memscan: the scan from "here"
> (0xcfe) up to (but excluding) "maxblocks" (0xd0e) needs to scan 3 bytes
> not 2 (the relevant bytes of bitmap in this case being f7 df ff - none
> 00, but the premature cutoff implying that the last was found 00).
>

alloc_new_reservation() reserved a window with free block, when come to
the time to claim it, it scans the window again. So it seems that the
range of the the scan is too small:

p = ((char *)bh->b_data) + (here >> 3);
r = memscan(p, 0, (maxblocks - here + 7) >> 3);
next = (r - ((char *)bh->b_data)) << 3;

---------------------> next is -1
if (next < maxblocks && next >= here)
return next;

----------------------> falls to false branch

here = bitmap_search_next_usable_block(here, bh, maxblocks);
return here;

So we failed to find a free byte in the range. That's seems fine to me.
It's only a nice thing to have -- try to allocate a block in a place
where it's neighbors are all free also. If it fails, it will search the
window bit by bit. So I don't understand why it is not being recovered
by bitmap_search_next_usable_block(), which test the bitmap bit by bit?

> Is this a problem for mainline ext2? No, because the "size" in its memscan
> is always EXT2_BLOCKS_PER_GROUP(sb), which mkfs.ext2 requires to be a
> multiple of 8. Is this a problem for ext3 or ext4? No, because they have
> an additional extN_test_allocatable test which rescues them from the error.
>
Hmm, if the error is it prematurely think there is no free block in the
range (bitmap on disk), then even in ext3/4, it will not bother checking
the jbd copy of the bitmap. I am not sure this is the cause that ext3/4
may not has the problem.

> But the bigger question is, why does the my_rsv case come here to
> find_next_usable_block at all?

Because grp_goal is -1?

> Doesn't its 64-bit boundary limit, and its
> memscan, blithely ignore what the reservation prepared?

I agree with you that the double check is urgly. But it's necessary:( If
there to prevent contention: other file make steal that free block we
reserved for this file, in the case filesystem is full of reservation...

> It's messy too,
> the complement of the memscan being that "i < 7" loop over in
> ext2_try_to_allocate. I think this ought to be cleaned up,
> in ext2+reservations and ext3 and ext4.
>
The "i<7" loop there is for non reservation case. Since
find_next_usable_block() could find a free byte, it's trying to avoid
filesystem holes by shifting the start of the free block for at most 7
times.

Thanks!

Mingming
> fs/ext2/balloc.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> --- 2.6.19-rc6-mm2/fs/ext2/balloc.c 2006-11-24 08:18:02.000000000 +0000
> +++ linux/fs/ext2/balloc.c 2006-11-27 19:28:41.000000000 +0000
> @@ -570,7 +570,7 @@ find_next_usable_block(int start, struct
> here = 0;
>
> p = ((char *)bh->b_data) + (here >> 3);
> - r = memscan(p, 0, (maxblocks - here + 7) >> 3);
> + r = memscan(p, 0, ((maxblocks + 7) >> 3) - (here >> 3));
> next = (r - ((char *)bh->b_data)) << 3;
>
> if (next < maxblocks && next >= here)
> -
> To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html

2006-11-28 19:36:20

[permalink] [raw]

Subject: Re: [PATCH 2/6] ext2 balloc: reset windowsz when full

On Tue, 2006-11-28 at 17:40 +0000, Hugh Dickins wrote:
> ext2_new_blocks should reset the reservation window size to 0 when squeezing
> the last blocks out of an almost full filesystem, so the retry doesn't skip
> any groups with less than half that free, reporting ENOSPC too soon.
>

I realize this is a bug when I was looking at the code as well. I was
thinking we should not check for whether the window size is less than
the free blocks counter at all, when the allocation is fall back to non
reservation allocation. But your fix works as well.

Mingming

2006-11-28 19:42:21

[permalink] [raw]

Subject: Re: [PATCH 3/6] ext2 balloc: fix off-by-one against rsv_end

On Tue, 2006-11-28 at 17:41 +0000, Hugh Dickins wrote:
> rsv_end is the last block within the reservation,
> so alloc_new_reservation should accept start_block == rsv_end as success.
>
> Signed-off-by: Hugh Dickins <[email protected]>
> ---
>

Thanks, Acked.

This is not a problem for now, as the default window size is 8 blocks,
and we never shrink the window size. But it could be a issue in the
future, if the reservation window could be dynamically shrink, when it
keep failing to create a new(large) reservation window, or we keep throw
away a just-allocated-window as the application is doing very seeky
random write.

> fs/ext2/balloc.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> --- 2.6.19-rc6-mm2/fs/ext2/balloc.c 2006-11-24 08:18:02.000000000 +0000
> +++ linux/fs/ext2/balloc.c 2006-11-27 19:28:41.000000000 +0000
> @@ -950,7 +950,7 @@ retry:
> * check if the first free block is within the
> * free space we just reserved
> */
> - if (start_block >= my_rsv->rsv_start && start_block < my_rsv->rsv_end)
> + if (start_block >= my_rsv->rsv_start && start_block <= my_rsv->rsv_end)
> return 0; /* success */
> /*
> * if the first free bit we found is out of the reservable space

2006-11-28 20:08:46

[permalink] [raw]

Subject: Re: [PATCH 1/6] ext2 balloc: fix _with_rsv freeze

On Tue, 28 Nov 2006, Mingming Cao wrote:
> On Tue, 2006-11-28 at 17:40 +0000, Hugh Dickins wrote:
> > After several days of testing ext2 with reservations, it got caught inside
> > ext2_try_to_allocate_with_rsv: alloc_new_reservation repeatedly succeeding
> > on the window [12cff,12d0e], ext2_try_to_allocate repeatedly failing to
> > find the free block guaranteed to be included (unless there's contention).
> >
>
> Hmm, I suspect there is other issue: alloc_new_reservation should not
> repeatedly allocating the same window, if ext2_try_to_allocate
> repeatedly fails to find a free block in that window.
> find_next_reservable_window() takes my_rsv (the old window that he
> thinks there is no free block) as a guide to find a window "after" the
> end block of my_rsv, so how could this happen?

Hmmm. I haven't studied that part of the code, but what you say sounds
sensible: that would leave more to be explained, yes. I guess it would
happen if all the rest of the bitmap were either allocated or reserved,
but I don't believe that was the case here: I have noted that the map
was all 00s from offset 0x1ae onwards, plenty unallocated; I've not
recorded the following reservations, but it seems unlikely they covered
the remaining free area (and still covered it even when the remaining
tasks got to the point of just waiting for this one).

>
> > Fix the range to find_next_usable_block's memscan: the scan from "here"
> > (0xcfe) up to (but excluding) "maxblocks" (0xd0e) needs to scan 3 bytes
> > not 2 (the relevant bytes of bitmap in this case being f7 df ff - none
> > 00, but the premature cutoff implying that the last was found 00).
> >
>
> alloc_new_reservation() reserved a window with free block, when come to
> the time to claim it, it scans the window again. So it seems that the
> range of the the scan is too small:

The range of the scan is 1 byte too small in this case, yes.

>
> p = ((char *)bh->b_data) + (here >> 3);
> r = memscan(p, 0, (maxblocks - here + 7) >> 3);
> next = (r - ((char *)bh->b_data)) << 3;
>
> ---------------------> next is -1

I don't understand you: next was not -1, it was 0xd08.

> if (next < maxblocks && next >= here)
> return next;
>
> ----------------------> falls to false branch

No, it passed the "next < maxblocks && next >= here" test
(maxblocks being 0xd0e and here being 0xcfe), so returned
pointing to an allocated block - then the caller finds it
cannot set the bit.

>
> here = bitmap_search_next_usable_block(here, bh, maxblocks);
> return here;
>
> So we failed to find a free byte in the range. That's seems fine to me.
> It's only a nice thing to have -- try to allocate a block in a place
> where it's neighbors are all free also. If it fails, it will search the
> window bit by bit. So I don't understand why it is not being recovered
> by bitmap_search_next_usable_block(), which test the bitmap bit by bit?

It already returned, it doesn't reach that line.

>
> > Is this a problem for mainline ext2? No, because the "size" in its memscan
> > is always EXT2_BLOCKS_PER_GROUP(sb), which mkfs.ext2 requires to be a
> > multiple of 8. Is this a problem for ext3 or ext4? No, because they have
> > an additional extN_test_allocatable test which rescues them from the error.
> >
> Hmm, if the error is it prematurely think there is no free block in the
> range (bitmap on disk), then even in ext3/4, it will not bother checking
> the jbd copy of the bitmap. I am not sure this is the cause that ext3/4
> may not has the problem.

In the ext3/4 case, it indeed won't bother to check the jbd copy
(having found this bitmap bit set), it'll fall through to the
bitmap_search_next_usable_block you indicated above,
and that should do the right thing, finding the first
free bit in the area originally reserved.

>
> > But the bigger question is, why does the my_rsv case come here to
> > find_next_usable_block at all?
>
> Because grp_goal is -1?

Well, yes, but my point is that we've got a reservation, and we're
hoping to allocate from it (even though we've given up on the "goal"),
but find_next_usable_block is not respecting it at all - liable to be
allocating out of others' reservations instead.

>
> > Doesn't its 64-bit boundary limit, and its
> > memscan, blithely ignore what the reservation prepared?
>
> I agree with you that the double check is urgly. But it's necessary:( If
> there to prevent contention: other file make steal that free block we
> reserved for this file, in the case filesystem is full of reservation...

I agree it's necessary to recheck the allocation; I disagree that the
64-bit boundary limit and memscan are appropriate when my_rsv is set.

>
> > It's messy too,
> > the complement of the memscan being that "i < 7" loop over in
> > ext2_try_to_allocate. I think this ought to be cleaned up,
> > in ext2+reservations and ext3 and ext4.
> >
> The "i<7" loop there is for non reservation case. Since
> find_next_usable_block() could find a free byte, it's trying to avoid
> filesystem holes by shifting the start of the free block for at most 7
> times.

Yes, the "i<7" loop rightly has a !my_rsv check; my point it that it's
the "other end" of the memscan, which was operating 8-bits at a time,
which lacks any my_rsv check (doesn't even know my_rsv at that level).

Hugh

2006-11-28 20:27:59

[permalink] [raw]

Subject: Re: Boot failure with ext2 and initrds

On Tue, 21 Nov 2006, Mingming Cao wrote:
> On Mon, 2006-11-20 at 16:19 +0000, Hugh Dickins wrote:
> > After four days of running, the EM64T has at last reproduced the same
> > hang as it did in an hour before: stuck in
> > ext2_try_to_allocate_with_rsv,
> > repeatedly ext2_rsv_window_add, ext2_try_to_allocate,
> > rsv_window_remove
> > (perhaps not in that order).
> >

At last it did happen again, on both x86_64 and ppc64.

>
> Don't have much clue, still...:(

Don't worry, KDB helped me work it out, patch follows in a moment.

>
> The logic of the while loop in ext2_try_to_allocate_with_rsv() looks
> like:

Thanks for your clarifications and tips.

> >
> A bit confused, did the whole system hang or just the "ld" writer hang
> in ext2 block allocation? And what other writers were waiting for? Were
> they trying to write to the same file?

The system was pingable, but couldn't do much else. Only the one
"ld" was active on the ext2 filesystem by this time, other tasks of
the make just waiting on it, nothing else was trying to write there.

4 cpus, well, 2*HT: why couldn't I ssh or login? I don't know,
something else to investigate, but that can be quite separate: very
unlikely to be related to the particular ext2 bug which showed it
(that filesystem was just for the test, it's not my root).
Probably stupidly obvious once I've worked it out.

>
> It might be helpful to check the return value of ext2_try_to_allocate(),
> to see if it fails. It would be nice if you could check if there any
> free bit inside the reservation window.

After screwing up last time, I was ultra-paranoid this time, and did
not dare to set any breakpoints: proceeded by repeatedly breaking in
from the keyboard, and the time I happened to catch it on return from
memscan() was revealing.

>
> And could you check the start and end block for every rsv_window_add and
> rsv_window_remove, to see if it was keep creating and removing the same
> window in the same block group?

The same every time it settled on a usable reservation, but a lot of
wasted adds and removes as it works across a fully allocated area of
the bitmap. Not very efficient, all those rb_tree insertions and
removals until it gets to a free area; but I can't judge from this
example how common that would be, may not be worth bothering about.

>
> And it might be useful to dump the whole filesystem block reservation
> tree as well.

Not necessary, I've put just the relevant numbers in the patch comment,
it helped me a lot to see the actual numbers and work it out from there.

>
> Not sure if it worth the effort to test it on ext3. The ext2 block
> reservation code in 2.6.19-rc5-mm2 looks pretty much the same as ext3/4,
> except the missing truncate_mutex. I understand this might take a few
> days to reproduce, so this might not needed now.

Turns out vanilla-ext2 and ext3 and ext4 are safe:
ext3 and ext4 slightly wrong in the same way, but safe.

I'll continue this thread with the bugfix patch 1/6; and five more
(roughly descending order of importance, the latter just cosmetic)
little fs/ext2/balloc.c patches to things I noticed on the way.
Nothing very worrying. Easier to send patches than ask questions:
please check, perhaps my "off-by-one" accusations are wrong, for
example. If you're satisfied they're right, please apply the
same to ext3 and ext4.

Although 1/6 does (I believe: too early for my tests to tell)
fix the bug in a minimal way, I rather think that area needs
cleanup - further comments below my Signed-off-by in 1/6.

Hugh

2006-11-28 21:05:01

[permalink] [raw]

Subject: Re: Boot failure with ext2 and initrds

On Tue, 2006-11-28 at 17:38 +0000, Hugh Dickins wrote:

> >
> > And could you check the start and end block for every rsv_window_add and
> > rsv_window_remove, to see if it was keep creating and removing the same
> > window in the same block group?
>
> The same every time it settled on a usable reservation, but a lot of
> wasted adds and removes as it works across a fully allocated area of
> the bitmap. Not very efficient, all those rb_tree insertions and
> removals until it gets to a free area; but I can't judge from this
> example how common that would be, may not be worth bothering about.
>

Yeah, it's not so efficient to add a window before knowing it has a free
block, as rb tree insertion is quit expensive. Actually it used to be
this way: only insert a window to the rb tree when there is a free bit
inside of it. However we need to hold the per-fs reservation lock while
scanning the bitmap:( This badly hurt the performance in some case and
the real time folks complained about it.

So we changed the code to the current way. I think it was not that
inefficient in the case it works across a fully allocated/reserved area,
since bitmap_search_next_usable_block() will skip the fully allocated
area fairly quickly, as it searchs from the beginning of the window till
the last block of the block group (not just the end of the window)

> >
> > And it might be useful to dump the whole filesystem block reservation
> > tree as well.
>
> Not necessary, I've put just the relevant numbers in the patch comment,
> it helped me a lot to see the actual numbers and work it out from there.
>
> >
> > Not sure if it worth the effort to test it on ext3. The ext2 block
> > reservation code in 2.6.19-rc5-mm2 looks pretty much the same as ext3/4,
> > except the missing truncate_mutex. I understand this might take a few
> > days to reproduce, so this might not needed now.
>
> Turns out vanilla-ext2 and ext3 and ext4 are safe:
> ext3 and ext4 slightly wrong in the same way, but safe.
>

Good to know.

> I'll continue this thread with the bugfix patch 1/6; and five more
> (roughly descending order of importance, the latter just cosmetic)
> little fs/ext2/balloc.c patches to things I noticed on the way.
> Nothing very worrying. Easier to send patches than ask questions:
> please check, perhaps my "off-by-one" accusations are wrong, for
> example. If you're satisfied they're right, please apply the
> same to ext3 and ext4.
>

Thanks, I have acked most of them, and will port them to ext3/4 soon.

2006-11-28 22:19:41

by David Woodhouse

[permalink] [raw]

Subject: Re: [-mm patch] drivers/mtd/nand/rtc_from4.c: use lib/bitrev.c

On Wed, 2006-11-22 at 05:38 +0100, Adrian Bunk wrote:
> This patch converts drivers/mtd/nand/rtc_from4.c to use the new
> lib/bitrev.c
>
> Signed-off-by: Adrian Bunk <[email protected]>

Applied; thanks.

--
dwmw2

2006-11-28 22:34:15

[permalink] [raw]

Subject: Re: Boot failure with ext2 and initrds

On Tue, 28 Nov 2006 13:04:53 -0800
Mingming Cao <[email protected]> wrote:

> Thanks, I have acked most of them, and will port them to ext3/4 soon.

You've acked #2 and #3. #4, #5 and #6 remain un-commented-upon and #1 is
unclear?

2006-11-28 22:52:23

by David Woodhouse

[permalink] [raw]

Subject: Re: [-mm patch] drivers/mtd/nand/rtc_from4.c: use lib/bitrev.c

On Tue, 2006-11-28 at 14:49 -0800, Andrew Morton wrote:
> Won't compile - you don't have the bitrev library patches.

Hm, yeah -- I'd just come to that conclusion :)

> I'll take that as an ack and shall merge this once
> crc32-replace-bitreverse-by-bitrev32.patch is merged ;)

I assume the bitrev thing will be going in as soon as 2.6.19 is actually
released, so there's no point in me reverting it from the mtd tree?

--
dwmw2

2006-11-28 22:52:53

[permalink] [raw]

Subject: Re: [-mm patch] drivers/mtd/nand/rtc_from4.c: use lib/bitrev.c

On Tue, 28 Nov 2006 22:19:36 +0000
David Woodhouse <[email protected]> wrote:

> On Wed, 2006-11-22 at 05:38 +0100, Adrian Bunk wrote:
> > This patch converts drivers/mtd/nand/rtc_from4.c to use the new
> > lib/bitrev.c
> >
> > Signed-off-by: Adrian Bunk <[email protected]>
>
> Applied; thanks.
>

Won't compile - you don't have the bitrev library patches.

I'll take that as an ack and shall merge this once
crc32-replace-bitreverse-by-bitrev32.patch is merged ;)

2006-11-28 23:30:38

[permalink] [raw]

Subject: Re: [PATCH 4/6] ext2 balloc: fix off-by-one against grp_goal

On Tue, 2006-11-28 at 17:42 +0000, Hugh Dickins wrote:
> grp_goal 0 is a genuine goal (unlike -1),
> so ext2_try_to_allocate_with_rsv should treat it as such.
>
> Signed-off-by: Hugh Dickins <[email protected]>

Acked.

Thanks,

Mingming
> ---
>
> fs/ext2/balloc.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> --- 2.6.19-rc6-mm2/fs/ext2/balloc.c 2006-11-24 08:18:02.000000000 +0000
> +++ linux/fs/ext2/balloc.c 2006-11-27 19:28:41.000000000 +0000
> @@ -1053,7 +1053,7 @@ ext2_try_to_allocate_with_rsv(struct sup
> }
> /*
> * grp_goal is a group relative block number (if there is a goal)
> - * 0 < grp_goal < EXT2_BLOCKS_PER_GROUP(sb)
> + * 0 <= grp_goal < EXT2_BLOCKS_PER_GROUP(sb)
> * first block is a filesystem wide block number
> * first block is the block number of the first block in this group
> */
> @@ -1089,7 +1089,7 @@ ext2_try_to_allocate_with_rsv(struct sup
> if (!goal_in_my_reservation(&my_rsv->rsv_window,
> grp_goal, group, sb))
> grp_goal = -1;
> - } else if (grp_goal > 0) {
> + } else if (grp_goal >= 0) {
> int curr = my_rsv->rsv_end -
> (grp_goal + group_first_block) + 1;
>

2006-11-28 23:31:18

[permalink] [raw]

Subject: Re: [PATCH 6/6] ext2 balloc: use io_error label

On Tue, 2006-11-28 at 17:44 +0000, Hugh Dickins wrote:
> ext2_new_blocks has a nice io_error label for setting -EIO,
> so goto that in the one place that doesn't already use it.
>
> Signed-off-by: Hugh Dickins <[email protected]>
> ---
>

Acked,

Mingming
> fs/ext2/balloc.c | 7 +++----
> 1 file changed, 3 insertions(+), 4 deletions(-)
>
> --- 2.6.19-rc6-mm2/fs/ext2/balloc.c 2006-11-24 08:18:02.000000000 +0000
> +++ linux/fs/ext2/balloc.c 2006-11-27 19:28:41.000000000 +0000
> @@ -1258,10 +1258,9 @@ retry_alloc:
> if (group_no >= ngroups)
> group_no = 0;
> gdp = ext2_get_group_desc(sb, group_no, &gdp_bh);
> - if (!gdp) {
> - *errp = -EIO;
> - goto out;
> - }
> + if (!gdp)
> + goto io_error;
> +
> free_blocks = le16_to_cpu(gdp->bg_free_blocks_count);
> /*
> * skip this group if the number of
> -
> To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html

2006-11-28 23:31:04

[permalink] [raw]

Subject: Re: [PATCH 5/6] ext2 balloc: say rb_entry not list_entry

On Tue, 2006-11-28 at 17:43 +0000, Hugh Dickins wrote:
> The reservations tree is an rb_tree not a list, so it's less confusing to
> use rb_entry() than list_entry() - though they're both just container_of().
>
> Signed-off-by: Hugh Dickins <[email protected]>
> ---
>

Acked.

Thanks,
Mingming
> fs/ext2/balloc.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> --- 2.6.19-rc6-mm2/fs/ext2/balloc.c 2006-11-24 08:18:02.000000000 +0000
> +++ linux/fs/ext2/balloc.c 2006-11-27 19:28:41.000000000 +0000
> @@ -156,7 +156,7 @@ restart:
>
> printk("Block Allocation Reservation Windows Map (%s):\n", fn);
> while (n) {
> - rsv = list_entry(n, struct ext2_reserve_window_node, rsv_node);
> + rsv = rb_entry(n, struct ext2_reserve_window_node, rsv_node);
> if (verbose)
> printk("reservation window 0x%p "
> "start: %lu, end: %lu\n",
> @@ -753,7 +753,7 @@ static int find_next_reservable_window(
>
> prev = rsv;
> next = rb_next(&rsv->rsv_node);
> - rsv = list_entry(next,struct ext2_reserve_window_node,rsv_node);
> + rsv = rb_entry(next,struct ext2_reserve_window_node,rsv_node);
>
> /*
> * Reached the last reservation, we can just append to the
> @@ -995,7 +995,7 @@ static void try_to_extend_reservation(st
> if (!next)
> my_rsv->rsv_end += size;
> else {
> - next_rsv = list_entry(next, struct ext2_reserve_window_node, rsv_node);
> + next_rsv = rb_entry(next, struct ext2_reserve_window_node, rsv_node);
>
> if ((next_rsv->rsv_start - my_rsv->rsv_end - 1) >= size)
> my_rsv->rsv_end += size;

2006-11-28 23:38:32

[permalink] [raw]

Subject: Re: Boot failure with ext2 and initrds

On Tue, 2006-11-28 at 14:33 -0800, Andrew Morton wrote:
> On Tue, 28 Nov 2006 13:04:53 -0800
> Mingming Cao <[email protected]> wrote:
>
> > Thanks, I have acked most of them, and will port them to ext3/4 soon.
>
> You've acked #2 and #3. #4, #5 and #6 remain un-commented-upon and #1 is
> unclear?

sorry, just acked #4, #5 and #6. I mean to do that before I said so but
they did not go out of my outbox till now ( I was out for a few hours).

#1 looks correct to me now, just thought there are other issues. I will
comment on that one in that thread.

Mingming

2006-11-28 23:39:39

by Randy Dunlap

[permalink] [raw]

Subject: Re: 2.6.19-rc5-mm2: paravirt X86_PAE=y compile error

On Wed, 15 Nov 2006 15:36:14 -0800 Andrew Morton wrote:

> On Thu, 16 Nov 2006 00:16:26 +0100
> Adrian Bunk <[email protected]> wrote:
>
> > Paravirt breaks CONFIG_X86_PAE=y compilation:
> >
> > <-- snip -->
> >
> > ...
> > CC init/main.o
> > In file included from include2/asm/pgtable.h:245,
> > from
> > /home/bunk/linux/kernel-2.6/linux-2.6.19-rc5-mm2/include/linux/mm.h:40,
> > from
> > /home/bunk/linux/kernel-2.6/linux-2.6.19-rc5-mm2/include/linux/poll.h:11,
> > from
> > /home/bunk/linux/kernel-2.6/linux-2.6.19-rc5-mm2/include/linux/rtc.h:113,
> > from
> > /home/bunk/linux/kernel-2.6/linux-2.6.19-rc5-mm2/include/linux/efi.h:19,
> > from
> > /home/bunk/linux/kernel-2.6/linux-2.6.19-rc5-mm2/init/main.c:43:
> > include2/asm/pgtable-3level.h:108: error: redefinition of 'pte_clear'
> > include2/asm/paravirt.h:365: error: previous definition of 'pte_clear' was here
> > include2/asm/pgtable-3level.h:115: error: redefinition of 'pmd_clear'
> > include2/asm/paravirt.h:370: error: previous definition of 'pmd_clear' was here
> > make[2]: *** [init/main.o] Error 1
> >
>
> So it does. Zach will save us.
>
> How come allmodconfig doesn't select highmem?

Must be because of "choice" and its default:

choice
prompt "High Memory Support"
default NOHIGHMEM

Changing the default fixes it. I suppose conf.c could be
hacked to do something different on choices, but it's not
clear how/what to do there as a general rule.

---
From: Randy Dunlap <[email protected]>

Make ix86 default to HIGHMEM4G instead of NOHIGHMEM.

Signed-off-by: Randy Dunlap <[email protected]>
---
arch/i386/Kconfig | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)

--- linux-2.6.19-rc6-git10.orig/arch/i386/Kconfig
+++ linux-2.6.19-rc6-git10/arch/i386/Kconfig
@@ -443,7 +443,8 @@ source "drivers/firmware/Kconfig"

choice
prompt "High Memory Support"
- default NOHIGHMEM
+ default HIGHMEM4G if !X86_NUMAQ
+ default HIGHMEM64G if X86_NUMAQ

config NOHIGHMEM
bool "off"

2006-11-29 00:12:46

[permalink] [raw]

Subject: Re: [-mm patch] drivers/mtd/nand/rtc_from4.c: use lib/bitrev.c

On Tue, 28 Nov 2006 22:52:16 +0000
David Woodhouse <[email protected]> wrote:

> > I'll take that as an ack and shall merge this once
> > crc32-replace-bitreverse-by-bitrev32.patch is merged ;)
>
> I assume the bitrev thing will be going in as soon as 2.6.19 is actually
> released,

It will take over a week after 2.6.19 - I prefer to wait until the git tree
laggards^Wowners have merged before merging -mm stuff, so things land in
appropriate order.

> so there's no point in me reverting it from the mtd tree?

Your call.

I do have a fixlet against this patch:

--- a/drivers/mtd/nand/rtc_from4.c~drivers-mtd-nand-rtc_from4c-use-lib-bitrevc-tidy
+++ a/drivers/mtd/nand/rtc_from4.c
@@ -357,7 +357,7 @@ static int rtc_from4_correct_data(struct
/* Read the syndrom pattern from the FPGA and correct the bitorder */
rs_ecc = (volatile unsigned short *)(rtc_from4_fio_base + RTC_FROM4_RS_ECC);
for (i = 0; i < 8; i++) {
- ecc[i] = byte_rev_table[(*rs_ecc) & 0xFF];
+ ecc[i] = bitrev8(*rs_ecc);
rs_ecc++;
}

_

2006-11-29 00:42:11

[permalink] [raw]

Subject: Re: [PATCH 1/6] ext2 balloc: fix _with_rsv freeze

On Tue, 2006-11-28 at 20:07 +0000, Hugh Dickins wrote:
> On Tue, 28 Nov 2006, Mingming Cao wrote:
> > On Tue, 2006-11-28 at 17:40 +0000, Hugh Dickins wrote:
> > > After several days of testing ext2 with reservations, it got caught inside
> > > ext2_try_to_allocate_with_rsv: alloc_new_reservation repeatedly succeeding
> > > on the window [12cff,12d0e], ext2_try_to_allocate repeatedly failing to
> > > find the free block guaranteed to be included (unless there's contention).
> > >
> >
> > Hmm, I suspect there is other issue: alloc_new_reservation should not
> > repeatedly allocating the same window, if ext2_try_to_allocate
> > repeatedly fails to find a free block in that window.
> > find_next_reservable_window() takes my_rsv (the old window that he
> > thinks there is no free block) as a guide to find a window "after" the
> > end block of my_rsv, so how could this happen?
>
> Hmmm. I haven't studied that part of the code, but what you say sounds
> sensible: that would leave more to be explained, yes. I guess it would
> happen if all the rest of the bitmap were either allocated or reserved,

But bitmap_search_next_usable_block() will fail in the case the rest of
bitmap were allocated, and find_next_reservable_space() will fail in the
case the rest of group were all reserved. alloc_new_reservation() should
not create a new window in this case.

> but I don't believe that was the case here: I have noted that the map
> was all 00s from offset 0x1ae onwards, plenty unallocated; I've not
> recorded the following reservations, but it seems unlikely they covered
> the remaining free area (and still covered it even when the remaining
> tasks got to the point of just waiting for this one).
>
> >
> > > Fix the range to find_next_usable_block's memscan: the scan from "here"
> > > (0xcfe) up to (but excluding) "maxblocks" (0xd0e) needs to scan 3 bytes
> > > not 2 (the relevant bytes of bitmap in this case being f7 df ff - none
> > > 00, but the premature cutoff implying that the last was found 00).
> > >
> >
> > alloc_new_reservation() reserved a window with free block, when come to
> > the time to claim it, it scans the window again. So it seems that the
> > range of the the scan is too small:
>
> The range of the scan is 1 byte too small in this case, yes.
>
> >
> > p = ((char *)bh->b_data) + (here >> 3);
> > r = memscan(p, 0, (maxblocks - here + 7) >> 3);
> > next = (r - ((char *)bh->b_data)) << 3;
> >
> > ---------------------> next is -1
>
> I don't understand you: next was not -1, it was 0xd08.
>
> > if (next < maxblocks && next >= here)
> > return next;
> >
> > ----------------------> falls to false branch
>
> No, it passed the "next < maxblocks && next >= here" test
> (maxblocks being 0xd0e and here being 0xcfe), so returned
> pointing to an allocated block - then the caller finds it
> cannot set the bit.
>

Apologies for the confusion. I thought ext2_try_to_allocate() failed
because we could not find a free block in the reserved window (i.e.,
find_next_usable_block() failed)

It seems in this case, find_next_usable_block() incorrectly returns a
bit it *thinks* free, but ext2_try_to_allocate() fails to claim it as
it's being marked as used.

So yes, Acked this fix. Thanks.

> >
> > here = bitmap_search_next_usable_block(here, bh, maxblocks);
> > return here;
> >
> > So we failed to find a free byte in the range. That's seems fine to me.
> > It's only a nice thing to have -- try to allocate a block in a place
> > where it's neighbors are all free also. If it fails, it will search the
> > window bit by bit. So I don't understand why it is not being recovered
> > by bitmap_search_next_usable_block(), which test the bitmap bit by bit?
>
> It already returned, it doesn't reach that line.
>
Yep.

> >
> > > Is this a problem for mainline ext2? No, because the "size" in its memscan
> > > is always EXT2_BLOCKS_PER_GROUP(sb), which mkfs.ext2 requires to be a
> > > multiple of 8. Is this a problem for ext3 or ext4? No, because they have
> > > an additional extN_test_allocatable test which rescues them from the error.
> > >
> > Hmm, if the error is it prematurely think there is no free block in the
> > range (bitmap on disk), then even in ext3/4, it will not bother checking
> > the jbd copy of the bitmap. I am not sure this is the cause that ext3/4
> > may not has the problem.
>
> In the ext3/4 case, it indeed won't bother to check the jbd copy
> (having found this bitmap bit set), it'll fall through to the
> bitmap_search_next_usable_block you indicated above,
> and that should do the right thing, finding the first
> free bit in the area originally reserved.
>
Make sense.
> >
> > > But the bigger question is, why does the my_rsv case come here to
> > > find_next_usable_block at all?
> >
> > Because grp_goal is -1?
>
> Well, yes, but my point is that we've got a reservation, and we're
> hoping to allocate from it (even though we've given up on the "goal"),
> but find_next_usable_block is not respecting it at all - liable to be
> allocating out of others' reservations instead.
>
Okay got your points. I think you are right.:) Well, right now the
window is just a (start,end) pair which pointing to a range that nobody
has reserved, that doesn't include the information about which block is
free even though we did scan the bitmap making sure there is a free
block. So when alloc_new_reservation() successfully create a new
window, so we still relies on find_next_usable() to check for which free
block to use.

It does seem redundant in the reservation case. We could adjust the new
created window start block to the first free block returned from
bitmap_search_next_usable_block(), so that the information of first free
block in the window got passed to ext2_try_to_allocate().

> >
> > > Doesn't its 64-bit boundary limit, and its
> > > memscan, blithely ignore what the reservation prepared?
> >
> > I agree with you that the double check is urgly. But it's necessary:( If
> > there to prevent contention: other file make steal that free block we
> > reserved for this file, in the case filesystem is full of reservation...
>
> I agree it's necessary to recheck the allocation; I disagree that the
> 64-bit boundary limit and memscan are appropriate when my_rsv is set.
>

Okay, I understand your points now:) Quite reasonable. I have the
similar doubts when I first touch this code when implement reservation
code. it's all about allocation policy. Looking at the
ext2_try_to_allocate(), it's the core of ext2/3 block allocation
strategy:

1) if there are some free block near by the goal block(64 bit boundary
limit), then take that block (locality)

2) otherwise, try to place a new block in a contiguous chunk of free
block(memscan for a free byte), so file could be less fragmented

3) otherwise, any free block in the given range of bitmap will work.

The same policy applies to both reservation and non reservation: goal
guided first, then searching for free chunk. the In the following
example, reservation window is (16,39), goal is block 32, blocks 17,
24-31, and 33 are free. Which block should it allocate?

|------------------------------------------------|
|1 0 1 1 1 1 1 1 0 0 0 0 0 0 0 0 1 0 1 1 1 1 1 1 |
|------------------------------------------------|
16 24 32 40

In the current code with 64bit boundary limit, it will try to satisfy
locality so block #33 will be allocated. If we skip the 64bit boundary
limit and and memscan, it will go directly pick up block #17, seems less
optimized.

> >
> > > It's messy too,
> > > the complement of the memscan being that "i < 7" loop over in
> > > ext2_try_to_allocate. I think this ought to be cleaned up,
> > > in ext2+reservations and ext3 and ext4.
> > >
> > The "i<7" loop there is for non reservation case. Since
> > find_next_usable_block() could find a free byte, it's trying to avoid
> > filesystem holes by shifting the start of the free block for at most 7
> > times.
>
> Yes, the "i<7" loop rightly has a !my_rsv check; my point it that it's
> the "other end" of the memscan, which was operating 8-bits at a time,
> which lacks any my_rsv check (doesn't even know my_rsv at that level).
>

To me memscan still make sense for reservation case. In above example,
if block #33 is also allocated, since there is no free block nearby
(right side) the goal block, it probably better to allocate block #24,
so that the next allocation will be contiguous if application is doing
sequential allocation.

Mingming

2006-11-29 04:14:01

[permalink] [raw]

Subject: [PATCH 1/12] ext3 balloc: reset windowsz when full

Port a series ext2 balloc patches from Hugh to ext3/4. The first 6
patches are against ext3, and the rest are aginst ext4.

------------------------------------------------------
Subject: ext2 balloc: reset windowsz when full
From: Hugh Dickins <[email protected]>

ext2_new_blocks should reset the reservation window size to 0 when squeezing
the last blocks out of an almost full filesystem, so the retry doesn't skip
any groups with less than half that free, reporting ENOSPC too soon.

------------------------------------------------------
Sync up reservation fix from ext2

Signed-off-by: Mingming Cao <[email protected]>
---

---

linux-2.6.19-rc5-cmm/fs/ext3/balloc.c | 1 +
1 file changed, 1 insertion(+)

diff -puN fs/ext3/balloc.c~ext3_reset_windowsz_in_full_fs fs/ext3/balloc.c
--- linux-2.6.19-rc5/fs/ext3/balloc.c~ext3_reset_windowsz_in_full_fs 2006-11-28 19:36:41.000000000 -0800
+++ linux-2.6.19-rc5-cmm/fs/ext3/balloc.c 2006-11-28 19:36:41.000000000 -0800
@@ -1552,6 +1552,7 @@ retry_alloc:
*/
if (my_rsv) {
my_rsv = NULL;
+ windowsz = 0;
group_no = goal_group;
goto retry_alloc;
}

_

2006-11-29 04:14:27

[permalink] [raw]

Subject: [PATCH 3/12] ext3 balloc: fix off-by-one against rsv_end

------------------------------------------------------
Subject: ext2 balloc: fix off-by-one against rsv_end
From: Hugh Dickins <[email protected]>

rsv_end is the last block within the reservation, so alloc_new_reservation
should accept start_block == rsv_end as success.
------------------------------------------------------
Sync up a ext2 reservation fix in ext3

Signed-Off-By: Mingming Cao <[email protected]>

---

linux-2.6.19-rc5-cmm/fs/ext3/balloc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff -puN fs/ext3/balloc.c~ext3-balloc-fix-off-by-one-against-rsv_end fs/ext3/balloc.c
--- linux-2.6.19-rc5/fs/ext3/balloc.c~ext3-balloc-fix-off-by-one-against-rsv_end 2006-11-28 19:36:58.000000000 -0800
+++ linux-2.6.19-rc5-cmm/fs/ext3/balloc.c 2006-11-28 19:36:58.000000000 -0800
@@ -1148,7 +1148,7 @@ retry:
* check if the first free block is within the
* free space we just reserved
*/
- if (start_block >= my_rsv->rsv_start && start_block < my_rsv->rsv_end)
+ if (start_block >= my_rsv->rsv_start && start_block <= my_rsv->rsv_end)
return 0; /* success */
/*
* if the first free bit we found is out of the reservable space

_

2006-11-29 04:14:34

[permalink] [raw]

Subject: [PATCH 4/12] ext3 balloc: say rb_entry not list_entry

------------------------------------------------------
Subject: ext2 balloc: say rb_entry not list_entry
From: Hugh Dickins <[email protected]>

The reservations tree is an rb_tree not a list, so it's less confusing to use
rb_entry() than list_entry() - though they're both just container_of().

----------------------------------------------------------

Sync up this fix in ext3

Signed-off-by: Mingming Cao <[email protected]>
---

---

linux-2.6.19-rc5-cmm/fs/ext3/balloc.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)

diff -puN fs/ext3/balloc.c~ext3-balloc-say-rb_entry-not-list_entry fs/ext3/balloc.c
--- linux-2.6.19-rc5/fs/ext3/balloc.c~ext3-balloc-say-rb_entry-not-list_entry 2006-11-28 19:36:52.000000000 -0800
+++ linux-2.6.19-rc5-cmm/fs/ext3/balloc.c 2006-11-28 19:36:52.000000000 -0800
@@ -144,7 +144,7 @@ restart:

printk("Block Allocation Reservation Windows Map (%s):\n", fn);
while (n) {
- rsv = list_entry(n, struct ext3_reserve_window_node, rsv_node);
+ rsv = rb_entry(n, struct ext3_reserve_window_node, rsv_node);
if (verbose)
printk("reservation window 0x%p "
"start: %lu, end: %lu\n",
@@ -949,7 +949,7 @@ static int find_next_reservable_window(

prev = rsv;
next = rb_next(&rsv->rsv_node);
- rsv = list_entry(next,struct ext3_reserve_window_node,rsv_node);
+ rsv = rb_entry(next,struct ext3_reserve_window_node,rsv_node);

/*
* Reached the last reservation, we can just append to the
@@ -1193,7 +1193,7 @@ static void try_to_extend_reservation(st
if (!next)
my_rsv->rsv_end += size;
else {
- next_rsv = list_entry(next, struct ext3_reserve_window_node, rsv_node);
+ next_rsv = rb_entry(next, struct ext3_reserve_window_node, rsv_node);

if ((next_rsv->rsv_start - my_rsv->rsv_end - 1) >= size)
my_rsv->rsv_end += size;

_

2006-11-29 04:14:58

[permalink] [raw]

Subject: [PATCH 5/12] ext3 balloc: use io_error label

------------------------------------------------------
Subject: ext2 balloc: use io_error label
From: Hugh Dickins <[email protected]>

ext2_new_blocks has a nice io_error label for setting -EIO, so goto that in
the one place that doesn't already use it.

------------------------------------------------------
Fix it in ext3_new_blocks.

Signed-off-by: Mingming Cao <[email protected]>

---

linux-2.6.19-rc5-cmm/fs/ext3/balloc.c | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)

diff -puN fs/ext3/balloc.c~ext3-balloc-use-io_error-label fs/ext3/balloc.c
--- linux-2.6.19-rc5/fs/ext3/balloc.c~ext3-balloc-use-io_error-label 2006-11-28 19:45:51.000000000 -0800
+++ linux-2.6.19-rc5-cmm/fs/ext3/balloc.c 2006-11-28 19:45:51.000000000 -0800
@@ -1515,10 +1515,8 @@ retry_alloc:
if (group_no >= ngroups)
group_no = 0;
gdp = ext3_get_group_desc(sb, group_no, &gdp_bh);
- if (!gdp) {
- *errp = -EIO;
- goto out;
- }
+ if (!gdp)
+ goto io_error;
free_blocks = le16_to_cpu(gdp->bg_free_blocks_count);
/*
* skip this group if the number of

_

2006-11-29 04:15:05

[permalink] [raw]

Subject: [PATCH 2/12] ext3 balloc: fix off-by-one against grp_goal

------------------------------------------------------
Subject: ext2 balloc: fix off-by-one against grp_goal
From: Hugh Dickins <[email protected]>

grp_goal 0 is a genuine goal (unlike -1), so ext2_try_to_allocate_with_rsv
should treat it as such.
------------------------------------------------------

Sync up with ext2 reservation fix in ext3

Signed-off-by: Mingming Cao <[email protected]>
---

---

linux-2.6.19-rc5-cmm/fs/ext3/balloc.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)

diff -puN fs/ext3/balloc.c~ext3-balloc-fix-off-by-one-against-grp_goal fs/ext3/balloc.c
--- linux-2.6.19-rc5/fs/ext3/balloc.c~ext3-balloc-fix-off-by-one-against-grp_goal 2006-11-28 19:36:48.000000000 -0800
+++ linux-2.6.19-rc5-cmm/fs/ext3/balloc.c 2006-11-28 19:36:48.000000000 -0800
@@ -1271,7 +1271,7 @@ ext3_try_to_allocate_with_rsv(struct sup
}
/*
* grp_goal is a group relative block number (if there is a goal)
- * 0 < grp_goal < EXT3_BLOCKS_PER_GROUP(sb)
+ * 0 <= grp_goal < EXT3_BLOCKS_PER_GROUP(sb)
* first block is a filesystem wide block number
* first block is the block number of the first block in this group
*/
@@ -1307,7 +1307,7 @@ ext3_try_to_allocate_with_rsv(struct sup
if (!goal_in_my_reservation(&my_rsv->rsv_window,
grp_goal, group, sb))
grp_goal = -1;
- } else if (grp_goal > 0) {
+ } else if (grp_goal >= 0) {
int curr = my_rsv->rsv_end -
(grp_goal + group_first_block) + 1;

_

2006-11-29 04:16:33

[permalink] [raw]

Subject: [PATCH 7/12] ext4 balloc: reset windowsz when full

------------------------------------------------------
Subject: ext2 balloc: reset windowsz when full
From: Hugh Dickins <[email protected]>

ext2_new_blocks should reset the reservation window size to 0 when squeezing
the last blocks out of an almost full filesystem, so the retry doesn't skip
any groups with less than half that free, reporting ENOSPC too soon.

------------------------------------------------------
Sync up reservation fix from ext2 in ext4

Signed-off-by: Mingming Cao <[email protected]>
---

---

linux-2.6.19-rc5-cmm/fs/ext4/balloc.c | 1 +
1 file changed, 1 insertion(+)

diff -puN fs/ext4/balloc.c~ext4_reset_windowsz_in_full_fs fs/ext4/balloc.c
--- linux-2.6.19-rc5/fs/ext4/balloc.c~ext4_reset_windowsz_in_full_fs 2006-11-28 19:37:01.000000000 -0800
+++ linux-2.6.19-rc5-cmm/fs/ext4/balloc.c 2006-11-28 19:37:01.000000000 -0800
@@ -1566,6 +1566,7 @@ retry_alloc:
*/
if (my_rsv) {
my_rsv = NULL;
+ windowsz = 0;
group_no = goal_group;
goto retry_alloc;
}

_

2006-11-29 04:15:52

[permalink] [raw]

Subject: [PATCH 12/12] ext3 balloc: fix _with_rsv freeze

------------------------------------------------------
Subject: ext2 balloc: fix _with_rsv freeze
From: Hugh Dickins <[email protected]>

After several days of testing ext2 with reservations, it got caught inside
ext2_try_to_allocate_with_rsv: alloc_new_reservation repeatedly succeeding on
the window [12cff,12d0e], ext2_try_to_allocate repeatedly failing to find the
free block guaranteed to be included (unless there's contention).

Fix the range to find_next_usable_block's memscan: the scan from "here"
(0xcfe) up to (but excluding) "maxblocks" (0xd0e) needs to scan 3 bytes not 2
(the relevant bytes of bitmap in this case being f7 df ff - none 00, but the
premature cutoff implying that the last was found 00).

Is this a problem for mainline ext2? No, because the "size" in its memscan is
always EXT2_BLOCKS_PER_GROUP(sb), which mkfs.ext2 requires to be a multiple of
8. Is this a problem for ext3 or ext4? No, because they have an additional
extN_test_allocatable test which rescues them from the error.

--------------------------------------------------

Sync up a reservation fix from ext2 in ext4
Signed-off-by: Mingming Cao <[email protected]>

---

linux-2.6.19-rc5-cmm/fs/ext4/balloc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff -puN fs/ext4/balloc.c~ext4-balloc-fix-_with_rsv-freeze fs/ext4/balloc.c
--- linux-2.6.19-rc5/fs/ext4/balloc.c~ext4-balloc-fix-_with_rsv-freeze 2006-11-28 19:37:12.000000000 -0800
+++ linux-2.6.19-rc5-cmm/fs/ext4/balloc.c 2006-11-28 19:37:12.000000000 -0800
@@ -747,7 +747,7 @@ find_next_usable_block(ext4_grpblk_t sta
here = 0;

p = ((char *)bh->b_data) + (here >> 3);
- r = memscan(p, 0, (maxblocks - here + 7) >> 3);
+ r = memscan(p, 0, ((maxblocks + 7) >> 3 - (here >> 3));
next = (r - ((char *)bh->b_data)) << 3;

if (next < maxblocks && next >= start && ext4_test_allocatable(next, bh))

_

2006-11-29 04:15:54

[permalink] [raw]

Subject: [PATCH 11/12] ext4 balloc: use io_error label

------------------------------------------------------
Subject: ext2 balloc: use io_error label
From: Hugh Dickins <[email protected]>

ext2_new_blocks has a nice io_error label for setting -EIO, so goto that in
the one place that doesn't already use it.

------------------------------------------------------
Fix it in ext4_new_blocks.

Signed-off-by: Mingming Cao <[email protected]>

---

linux-2.6.19-rc5-cmm/fs/ext4/balloc.c | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)

diff -puN fs/ext4/balloc.c~ext4-balloc-use-io_error-label fs/ext4/balloc.c
--- linux-2.6.19-rc5/fs/ext4/balloc.c~ext4-balloc-use-io_error-label 2006-11-28 19:42:45.000000000 -0800
+++ linux-2.6.19-rc5-cmm/fs/ext4/balloc.c 2006-11-28 19:43:21.000000000 -0800
@@ -1529,10 +1529,8 @@ retry_alloc:
if (group_no >= ngroups)
group_no = 0;
gdp = ext4_get_group_desc(sb, group_no, &gdp_bh);
- if (!gdp) {
- *errp = -EIO;
- goto out;
- }
+ if (!gdp)
+ goto io_error;
free_blocks = le16_to_cpu(gdp->bg_free_blocks_count);
/*
* skip this group if the number of

_

2006-11-29 04:16:45

[permalink] [raw]

Subject: [PATCH 8/12] ext4 balloc: fix off-by-one against grp_goal

Subject: ext2 balloc: fix off-by-one against grp_goal
From: Hugh Dickins <[email protected]>

grp_goal 0 is a genuine goal (unlike -1), so ext2_try_to_allocate_with_rsv
should treat it as such.
------------------------------------------------------
Sync up with ext2 reservation fix in ext4
Signed-off-by: Mingming Cao <[email protected]>
---

---

linux-2.6.19-rc5-cmm/fs/ext4/balloc.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)

diff -puN fs/ext4/balloc.c~ext4-balloc-fix-off-by-one-against-grp_goal fs/ext4/balloc.c
--- linux-2.6.19-rc5/fs/ext4/balloc.c~ext4-balloc-fix-off-by-one-against-grp_goal 2006-11-28 19:37:05.000000000 -0800
+++ linux-2.6.19-rc5-cmm/fs/ext4/balloc.c 2006-11-28 19:37:05.000000000 -0800
@@ -1288,7 +1288,7 @@ ext4_try_to_allocate_with_rsv(struct sup
}
/*
* grp_goal is a group relative block number (if there is a goal)
- * 0 < grp_goal < EXT4_BLOCKS_PER_GROUP(sb)
+ * 0 <= grp_goal < EXT4_BLOCKS_PER_GROUP(sb)
* first block is a filesystem wide block number
* first block is the block number of the first block in this group
*/
@@ -1324,7 +1324,7 @@ ext4_try_to_allocate_with_rsv(struct sup
if (!goal_in_my_reservation(&my_rsv->rsv_window,
grp_goal, group, sb))
grp_goal = -1;
- } else if (grp_goal > 0) {
+ } else if (grp_goal >= 0) {
int curr = my_rsv->rsv_end -
(grp_goal + group_first_block) + 1;

_

2006-11-29 04:17:11

[permalink] [raw]

Subject: [PATCH 9/12] ext4 balloc: fix off-by-one against rsv_end

------------------------------------------------------
Subject: ext2 balloc: fix off-by-one against rsv_end
From: Hugh Dickins <[email protected]>

rsv_end is the last block within the reservation, so alloc_new_reservation
should accept start_block == rsv_end as success.
------------------------------------------------------
Sync up a ext2 reservation fix in ext4
Signed-Off-By: Mingming Cao <[email protected]>

---

linux-2.6.19-rc5-cmm/fs/ext4/balloc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff -puN fs/ext4/balloc.c~ext4-balloc-fix-off-by-one-against-rsv_end fs/ext4/balloc.c
--- linux-2.6.19-rc5/fs/ext4/balloc.c~ext4-balloc-fix-off-by-one-against-rsv_end 2006-11-28 19:37:15.000000000 -0800
+++ linux-2.6.19-rc5-cmm/fs/ext4/balloc.c 2006-11-28 19:37:15.000000000 -0800
@@ -1165,7 +1165,7 @@ retry:
* check if the first free block is within the
* free space we just reserved
*/
- if (start_block >= my_rsv->rsv_start && start_block < my_rsv->rsv_end)
+ if (start_block >= my_rsv->rsv_start && start_block <= my_rsv->rsv_end)
return 0; /* success */
/*
* if the first free bit we found is out of the reservable space

_

2006-11-29 04:17:11

[permalink] [raw]

Subject: [PATCH 10/12] ext4 balloc: say rb_entry not list_entry

------------------------------------------------------
Subject: ext2 balloc: say rb_entry not list_entry
From: Hugh Dickins <[email protected]>

The reservations tree is an rb_tree not a list, so it's less confusing to use
rb_entry() than list_entry() - though they're both just container_of().

----------------------------------------------------------

Sync up this fix in ext4

Signed-off-by: Mingming Cao <[email protected]>
---

---

linux-2.6.19-rc5-cmm/fs/ext4/balloc.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)

diff -puN fs/ext4/balloc.c~ext4-balloc-say-rb_entry-not-list_entry fs/ext4/balloc.c
--- linux-2.6.19-rc5/fs/ext4/balloc.c~ext4-balloc-say-rb_entry-not-list_entry 2006-11-28 19:37:08.000000000 -0800
+++ linux-2.6.19-rc5-cmm/fs/ext4/balloc.c 2006-11-28 19:37:08.000000000 -0800
@@ -165,7 +165,7 @@ restart:

printk("Block Allocation Reservation Windows Map (%s):\n", fn);
while (n) {
- rsv = list_entry(n, struct ext4_reserve_window_node, rsv_node);
+ rsv = rb_entry(n, struct ext4_reserve_window_node, rsv_node);
if (verbose)
printk("reservation window 0x%p "
"start: %llu, end: %llu\n",
@@ -966,7 +966,7 @@ static int find_next_reservable_window(

prev = rsv;
next = rb_next(&rsv->rsv_node);
- rsv = list_entry(next,struct ext4_reserve_window_node,rsv_node);
+ rsv = rb_entry(next,struct ext4_reserve_window_node,rsv_node);

/*
* Reached the last reservation, we can just append to the
@@ -1210,7 +1210,7 @@ static void try_to_extend_reservation(st
if (!next)
my_rsv->rsv_end += size;
else {
- next_rsv = list_entry(next, struct ext4_reserve_window_node, rsv_node);
+ next_rsv = rb_entry(next, struct ext4_reserve_window_node, rsv_node);

if ((next_rsv->rsv_start - my_rsv->rsv_end - 1) >= size)
my_rsv->rsv_end += size;

_

2006-11-29 04:17:54

[permalink] [raw]

Subject: [PATCH 6/12] ext2 balloc: fix _with_rsv freeze

Sync up a reservation fix from ext2 in ext3
------------------------------------------------------
Subject: ext2 balloc: fix _with_rsv freeze
From: Hugh Dickins <[email protected]>

After several days of testing ext2 with reservations, it got caught inside
ext2_try_to_allocate_with_rsv: alloc_new_reservation repeatedly succeeding on
the window [12cff,12d0e], ext2_try_to_allocate repeatedly failing to find the
free block guaranteed to be included (unless there's contention).

Fix the range to find_next_usable_block's memscan: the scan from "here"
(0xcfe) up to (but excluding) "maxblocks" (0xd0e) needs to scan 3 bytes not 2
(the relevant bytes of bitmap in this case being f7 df ff - none 00, but the
premature cutoff implying that the last was found 00).

Is this a problem for mainline ext2? No, because the "size" in its memscan is
always EXT2_BLOCKS_PER_GROUP(sb), which mkfs.ext2 requires to be a multiple of
8. Is this a problem for ext3 or ext4? No, because they have an additional
extN_test_allocatable test which rescues them from the error.

--------------------------------------------------

Signed-off-by: Mingming Cao <[email protected]>

---

linux-2.6.19-rc5-cmm/fs/ext3/balloc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff -puN fs/ext3/balloc.c~ext3-balloc-fix-_with_rsv-freeze fs/ext3/balloc.c
--- linux-2.6.19-rc5/fs/ext3/balloc.c~ext3-balloc-fix-_with_rsv-freeze 2006-11-28 19:36:55.000000000 -0800
+++ linux-2.6.19-rc5-cmm/fs/ext3/balloc.c 2006-11-28 19:36:55.000000000 -0800
@@ -730,7 +730,7 @@ find_next_usable_block(ext3_grpblk_t sta
here = 0;

p = ((char *)bh->b_data) + (here >> 3);
- r = memscan(p, 0, (maxblocks - here + 7) >> 3);
+ r = memscan(p, 0, ((maxblocks + 7) >> 3) - (here >> 3));
next = (r - ((char *)bh->b_data)) << 3;

if (next < maxblocks && next >= start && ext3_test_allocatable(next, bh))

_

2006-11-29 05:51:43

[permalink] [raw]

Subject: Re: [PATCH 1/12] ext3 balloc: reset windowsz when full

On Tue, 28 Nov 2006, Mingming Cao wrote:

> Port a series ext2 balloc patches from Hugh to ext3/4. The first 6
> patches are against ext3, and the rest are aginst ext4.

Thanks for all that, Mingming:
whichever is appropriate, all twelve
Acked-by: Hugh Dickins <[email protected]>
or
Signed-off-by: Hugh Dickins <[email protected]>

I'll think about your other mails, those that need further thought,
later on: I need to pin down more accurately the repetitious sequence of
reservations in the mistaken case - maybe it indicated further issues,
maybe not; and I need to consider our different views of the my_rsv
find_next_usable_block.

Hugh

2006-11-29 08:24:34

[permalink] [raw]

Subject: Re: Boot failure with ext2 and initrds

Yet another attempt to get a response from Andrew. It is rather
important that you DO respond to this.

On Sat, Nov 25, 2006 at 02:59:16PM +0000, Russell King wrote:
> On Thu, Nov 16, 2006 at 12:34:48PM +0000, Russell King wrote:
> > On Wed, Nov 15, 2006 at 11:22:28PM -0800, Andrew Morton wrote:
> > > On Wed, 15 Nov 2006 22:55:43 -0800
> > > Mingming Cao <[email protected]> wrote:
> > >
> > > > Hmm, maxblocks, in bitmap_search_next_usable_block(), is the end block
> > > > number of the range to search, not the lengh of the range. maxblocks
> > > > get passed to ext2_find_next_zero_bit(), where it expecting to take the
> > > > _size_ of the range to search instead...
> > > >
> > > > Something like this: (this is not a patch)
> > > > @@ -524,7 +524,7 @@ bitmap_search_next_usable_block(ext2_grp
> > > > ext2_grpblk_t next;
> > > >
> > > > - next = ext2_find_next_zero_bit(bh->b_data, maxblocks, start);
> > > > + next = ext2_find_next_zero_bit(bh->b_data, maxblocks-start + 1, start);
> > > > if (next >= maxblocks)
> > > > return -1;
> > > > return next;
> > > > }
> > >
> > > yes, the `size' arg to find_next_zero_bit() represents the number of bits
> > > to scan at `offset'.
> >
> > Are you sure? That's not the way it's implemented in many architectures.
> > find_next_*_bit() has always taken "address, maximum offset, starting offset"
> > and always has returned "next offset".
> >
> > Just look at arch/i386/lib/bitops.c:
> >
> > int find_next_zero_bit(const unsigned long *addr, int size, int offset)
> > {
> > unsigned long * p = ((unsigned long *) addr) + (offset >> 5);
> > int set = 0, bit = offset & 31, res;
> > ...
> > /*
> > * No zero yet, search remaining full bytes for a zero
> > */
> > res = find_first_zero_bit (p, size - 32 * (p - (unsigned long *) addr));
> > return (offset + set + res);
> > }
> >
> > So for the case that "offset" is aligned to a "long" boundary, that gives us:
> >
> > res = find_first_zero_bit(addr + (offset>>5),
> > size - 32 * (addr + (offset>>5) - addr));
> >
> > or:
> >
> > res = find_first_zero_bit(addr + (offset>>5), size - (offset & ~31));
> >
> > So, size _excludes_ offset.
> >
> > Now, considering the return value, "res" above will be relative to
> > "addr + (offset>>5)". However, we add "offset" on to that, so it's
> > relative to addr + (offset bits).
>
> Andrew,
>
> Please respond to the above. If what you say is correct then all
> architectures need their bitops fixing to fit ext2's requirements.
>
> --
> Russell King
> Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
> maintainer of:
> -
> 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/

--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of:

2006-11-29 08:31:10

[permalink] [raw]

Subject: Re: Boot failure with ext2 and initrds

On Wed, 29 Nov 2006 07:40:00 +0000
Russell King <[email protected]> wrote:

> Yet another attempt to get a response from Andrew. It is rather
> important that you DO respond to this.

You can read the code as easily as I can? I'm not really sure what
you're asking - I thought Mingming cleared things up.

2006-11-29 09:20:43

[permalink] [raw]

Subject: Re: Boot failure with ext2 and initrds

On Wed, Nov 29, 2006 at 12:30:36AM -0800, Andrew Morton wrote:
> On Wed, 29 Nov 2006 07:40:00 +0000
> Russell King <[email protected]> wrote:
>
> > Yet another attempt to get a response from Andrew. It is rather
> > important that you DO respond to this.
>
> You can read the code as easily as I can?

Sigh. Please don't cut the relevant part of my _first_ email message
where it can be clearly seen that I _have_ read the code and interpreted
it _differently_ from you.

> I'm not really sure what you're asking - I thought Mingming cleared
> things up.

Which message did this happen?

What I'm looking for is confirmation of the semantics of
find_next_zero_bit(), which is a fairly simple question to ask, and
certainly does not justify this rather obtuse and difficult thread.

<extremely frustrated>

--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of:

2006-11-29 09:40:16

[permalink] [raw]

Subject: Re: Boot failure with ext2 and initrds

On Wed, 29 Nov 2006 09:20:24 +0000
Russell King <[email protected]> wrote:

> What I'm looking for is confirmation of the semantics of
> find_next_zero_bit()

What are the existing semantics? I see no documentation in any of the
architectures I've looked at. That's my point.

>From a quick read of fs/ext2/balloc.c

ext2_find_next_zero_bit(base, size, offset)

appears to expect that base is the start of the memory buffer, size is the
number of bits at *base and offset is the bit at which to start the search,
relative to base. If a zero bit is found it will return the offset of that
bit relative to base. It will return some number greater than `size' if no
zero-bit was found.

Whether that's how all the implementors interpreted it is anyone's guess.
Presumably the architectures all do roughly the same thing.

> <extremely frustrated>

Well likewise. It appears that nobody (and about 20 people have
implemented these things) could be bothered getting off ass and documenting
the pathetic thing.

2006-11-29 18:16:24