* [PATCH] Fix ext4 bitops @ 2008-02-01 20:02 Bastian Blank 2008-02-01 20:22 ` Andrew Morton 0 siblings, 1 reply; 17+ messages in thread From: Bastian Blank @ 2008-02-01 20:02 UTC (permalink / raw) To: linux-s390, akpm; +Cc: linux-kernel Fix ext4 bitops. Signed-off-by: Bastian Blank <waldi@debian.org> diff --git a/include/asm-s390/bitops.h b/include/asm-s390/bitops.h index dba6fec..47844fc 100644 --- a/include/asm-s390/bitops.h +++ b/include/asm-s390/bitops.h @@ -762,6 +762,8 @@ static inline int sched_find_first_bit(unsigned long *b) * 23 22 21 20 19 18 17 16 31 30 29 28 27 26 25 24 */ +#include <asm-generic/bitops/le.h> + #define ext2_set_bit(nr, addr) \ __test_and_set_bit((nr)^(__BITOPS_WORDSIZE - 8), (unsigned long *)addr) #define ext2_set_bit_atomic(lock, nr, addr) \ ^ permalink raw reply related [flat|nested] 17+ messages in thread
* Re: [PATCH] Fix ext4 bitops 2008-02-01 20:02 [PATCH] Fix ext4 bitops Bastian Blank @ 2008-02-01 20:22 ` Andrew Morton 2008-02-01 21:04 ` Bastian Blank 0 siblings, 1 reply; 17+ messages in thread From: Andrew Morton @ 2008-02-01 20:22 UTC (permalink / raw) To: Bastian Blank; +Cc: linux-s390, linux-kernel On Fri, 1 Feb 2008 21:02:08 +0100 Bastian Blank <bastian@waldi.eu.org> wrote: > Fix ext4 bitops. > This is incomplete. Please tell us what was "fixed". If it was a build error then please quote the compile error output in the changelog, as well as the usual description of what the problem is, and how it was fixed. > > diff --git a/include/asm-s390/bitops.h b/include/asm-s390/bitops.h > index dba6fec..47844fc 100644 > --- a/include/asm-s390/bitops.h > +++ b/include/asm-s390/bitops.h > @@ -762,6 +762,8 @@ static inline int sched_find_first_bit(unsigned long *b) > * 23 22 21 20 19 18 17 16 31 30 29 28 27 26 25 24 > */ > > +#include <asm-generic/bitops/le.h> > + > #define ext2_set_bit(nr, addr) \ > __test_and_set_bit((nr)^(__BITOPS_WORDSIZE - 8), (unsigned long *)addr) > #define ext2_set_bit_atomic(lock, nr, addr) \ ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH] Fix ext4 bitops 2008-02-01 20:22 ` Andrew Morton @ 2008-02-01 21:04 ` Bastian Blank 2008-02-03 12:12 ` Heiko Carstens 0 siblings, 1 reply; 17+ messages in thread From: Bastian Blank @ 2008-02-01 21:04 UTC (permalink / raw) To: Andrew Morton; +Cc: linux-s390, linux-kernel On Fri, Feb 01, 2008 at 12:22:57PM -0800, Andrew Morton wrote: > On Fri, 1 Feb 2008 21:02:08 +0100 > Bastian Blank <bastian@waldi.eu.org> wrote: > > > Fix ext4 bitops. > > This is incomplete. Please tell us what was "fixed". > > If it was a build error then please quote the compile error output in the > changelog, as well as the usual description of what the problem is, and how > it was fixed. | fs/ext4/mballoc.c: In function 'ext4_mb_generate_buddy': | fs/ext4/mballoc.c:954: error: implicit declaration of function 'generic_find_next_le_bit' The s390 specific bitops uses parts of the generic implementation. Include the correct header. > > diff --git a/include/asm-s390/bitops.h b/include/asm-s390/bitops.h > > index dba6fec..47844fc 100644 > > --- a/include/asm-s390/bitops.h > > +++ b/include/asm-s390/bitops.h > > @@ -762,6 +762,8 @@ static inline int sched_find_first_bit(unsigned long *b) > > * 23 22 21 20 19 18 17 16 31 30 29 28 27 26 25 24 > > */ > > > > +#include <asm-generic/bitops/le.h> > > + > > #define ext2_set_bit(nr, addr) \ > > __test_and_set_bit((nr)^(__BITOPS_WORDSIZE - 8), (unsigned long *)addr) > > #define ext2_set_bit_atomic(lock, nr, addr) \ > > > - > To unsubscribe from this list: send the line "unsubscribe linux-s390" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- The idea of male and female are universal constants. -- Kirk, "Metamorphosis", stardate 3219.8 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH] Fix ext4 bitops 2008-02-01 21:04 ` Bastian Blank @ 2008-02-03 12:12 ` Heiko Carstens 2008-02-03 12:39 ` Geert Uytterhoeven 0 siblings, 1 reply; 17+ messages in thread From: Heiko Carstens @ 2008-02-03 12:12 UTC (permalink / raw) To: Bastian Blank, Andrew Morton, linux-s390, linux-kernel On Fri, Feb 01, 2008 at 10:04:04PM +0100, Bastian Blank wrote: > On Fri, Feb 01, 2008 at 12:22:57PM -0800, Andrew Morton wrote: > > On Fri, 1 Feb 2008 21:02:08 +0100 > > Bastian Blank <bastian@waldi.eu.org> wrote: > > > > > Fix ext4 bitops. > > > > This is incomplete. Please tell us what was "fixed". > > > > If it was a build error then please quote the compile error output in the > > changelog, as well as the usual description of what the problem is, and how > > it was fixed. > > | fs/ext4/mballoc.c: In function 'ext4_mb_generate_buddy': > | fs/ext4/mballoc.c:954: error: implicit declaration of function 'generic_find_next_le_bit' > > The s390 specific bitops uses parts of the generic implementation. > Include the correct header. That doesn't work: fs/built-in.o: In function `ext4_mb_release_inode_pa': mballoc.c:(.text+0x95a8a): undefined reference to `generic_find_next_le_bit' fs/built-in.o: In function `ext4_mb_init_cache': mballoc.c:(.text+0x967ea): undefined reference to `generic_find_next_le_bit' This still needs generic_find_next_le_bit which comes from lib/find_next_bit.c. That one doesn't get built on s390 since we don't set GENERIC_FIND_NEXT_BIT. Currently we have the lengthly patch below queued. Subject: [PATCH] Implement ext2_find_next_bit. From: Heiko Carstens <heiko.carstens@de.ibm.com> Fixes this compile error: fs/ext4/mballoc.c: In function 'ext4_mb_generate_buddy': fs/ext4/mballoc.c:954: error: implicit declaration of function 'generic_find_next_le_bit' Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com> --- include/asm-s390/bitops.h | 130 +++++++++++++++++++++++++++++++++++++++++++++- 1 file changed, 128 insertions(+), 2 deletions(-) diff -urpN linux-2.6/include/asm-s390/bitops.h linux-2.6-patched/include/asm-s390/bitops.h --- linux-2.6/include/asm-s390/bitops.h 2008-02-01 12:29:03.000000000 +0100 +++ linux-2.6-patched/include/asm-s390/bitops.h 2008-02-01 12:31:39.000000000 +0100 @@ -772,8 +772,6 @@ static inline int sched_find_first_bit(u test_and_clear_bit((nr)^(__BITOPS_WORDSIZE - 8), (unsigned long *)addr) #define ext2_test_bit(nr, addr) \ test_bit((nr)^(__BITOPS_WORDSIZE - 8), (unsigned long *)addr) -#define ext2_find_next_bit(addr, size, off) \ - generic_find_next_le_bit((unsigned long *)(addr), (size), (off)) #ifndef __s390x__ @@ -820,6 +818,48 @@ ext2_find_first_zero_bit(void *vaddr, un return (res < size) ? res : size; } +static inline int __ext2_find_first_bit(void *vaddr, unsigned int size) +{ + typedef struct { long _[__BITOPS_WORDS(size)]; } addrtype; + unsigned long cmp, count; + unsigned int res; + + if (!size) + return 0; + asm volatile( + " lhi %1,0\n" + " lr %2,%3\n" + " lhi %0,0\n" + " ahi %2,31\n" + " srl %2,5\n" + "0: cl %1,0(%0,%4)\n" + " jne 1f\n" + " ahi %0,4\n" + " brct %2,0b\n" + " lr %0,%3\n" + " j 4f\n" + "1: l %2,0(%0,%4)\n" + " sll %0,3\n" + " ahi %0,24\n" + " lhi %1,0xff\n" + " tmh %2,0xffff\n" + " jnz 2f\n" + " ahi %0,-16\n" + " srl %2,16\n" + "2: tml %2,0xff00\n" + " jnz 3f\n" + " ahi %0,-8\n" + " srl %2,8\n" + "3: nr %2,%1\n" + " ic %2,0(%2,%5)\n" + " alr %0,%2\n" + "4:" + : "=&a" (res), "=&d" (cmp), "=&a" (count) + : "a" (size), "a" (vaddr), "a" (&_sb_findmap), + "m" (*(addrtype *) vaddr) : "cc"); + return (res < size) ? res : size; +} + #else /* __s390x__ */ static inline unsigned long @@ -867,6 +907,51 @@ ext2_find_first_zero_bit(void *vaddr, un return (res < size) ? res : size; } +static inline unsigned long __ext2_find_first_bit(void *vaddr, + unsigned long size) +{ + typedef struct { long _[__BITOPS_WORDS(size)]; } addrtype; + unsigned long res, cmp, count; + + if (!size) + return 0; + asm volatile( + " lghi %1,0\n" + " lgr %2,%3\n" + " lghi %0,0\n" + " aghi %2,63\n" + " srlg %2,%2,6\n" + "0: clg %1,0(%0,%4)\n" + " jne 1f\n" + " aghi %0,8\n" + " brct %2,0b\n" + " lgr %0,%3\n" + " j 5f\n" + "1: cl %1,0(%0,%4)\n" + " jne 2f\n" + " aghi %0,4\n" + "2: l %2,0(%0,%4)\n" + " sllg %0,%0,3\n" + " aghi %0,24\n" + " lghi %1,0xff\n" + " tmlh %2,0xffff\n" + " jnz 3f\n" + " aghi %0,-16\n" + " srl %2,16\n" + "3: tmll %2,0xff00\n" + " jnz 4f\n" + " aghi %0,-8\n" + " srl %2,8\n" + "4: ngr %2,%1\n" + " ic %2,0(%2,%5)\n" + " algr %0,%2\n" + "5:" + : "=&a" (res), "=&d" (cmp), "=&a" (count) + : "a" (size), "a" (vaddr), "a" (&_sb_findmap), + "m" (*(addrtype *) vaddr) : "cc"); + return (res < size) ? res : size; +} + #endif /* __s390x__ */ static inline int @@ -910,6 +995,47 @@ ext2_find_next_zero_bit(void *vaddr, uns return offset + ext2_find_first_zero_bit(p, size); } +static inline unsigned long ext2_find_next_bit(void *vaddr, unsigned long size, + unsigned long offset) +{ + unsigned long *addr = vaddr, *p; + unsigned long word, bit, set; + + if (offset >= size) + return size; + bit = offset & (__BITOPS_WORDSIZE - 1); + offset -= bit; + size -= offset; + p = addr + offset / __BITOPS_WORDSIZE; + if (bit) { +#ifndef __s390x__ + asm volatile( + " ic %0,0(%1)\n" + " icm %0,2,1(%1)\n" + " icm %0,4,2(%1)\n" + " icm %0,8,3(%1)" + : "=&a" (word) : "a" (p), "m" (*p) : "cc"); +#else + asm volatile( + " lrvg %0,%1" + : "=a" (word) : "m" (*p) ); +#endif + /* + * s390 version of __ffs returns __BITOPS_WORDSIZE + * if no one bit is present in the word. + */ + set = __ffs(word >> bit) + bit; + if (set >= size) + return size + offset; + if (set < __BITOPS_WORDSIZE) + return set + offset; + offset += __BITOPS_WORDSIZE; + size -= __BITOPS_WORDSIZE; + p++; + } + return offset + __ext2_find_first_bit(p, size); +} + #include <asm-generic/bitops/minix.h> #endif /* __KERNEL__ */ ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH] Fix ext4 bitops 2008-02-03 12:12 ` Heiko Carstens @ 2008-02-03 12:39 ` Geert Uytterhoeven 0 siblings, 0 replies; 17+ messages in thread From: Geert Uytterhoeven @ 2008-02-03 12:39 UTC (permalink / raw) To: Heiko Carstens, aneesh.kumar Cc: Bastian Blank, Andrew Morton, linux-s390, Linux Kernel Development, Linux/PPC Development, linux-ext4 On Sun, 3 Feb 2008, Heiko Carstens wrote: > On Fri, Feb 01, 2008 at 10:04:04PM +0100, Bastian Blank wrote: > > On Fri, Feb 01, 2008 at 12:22:57PM -0800, Andrew Morton wrote: > > > On Fri, 1 Feb 2008 21:02:08 +0100 > > > Bastian Blank <bastian@waldi.eu.org> wrote: > > > > > > > Fix ext4 bitops. > > > > > > This is incomplete. Please tell us what was "fixed". > > > > > > If it was a build error then please quote the compile error output in the > > > changelog, as well as the usual description of what the problem is, and how > > > it was fixed. > > > > | fs/ext4/mballoc.c: In function 'ext4_mb_generate_buddy': > > | fs/ext4/mballoc.c:954: error: implicit declaration of function 'generic_find_next_le_bit' > > > > The s390 specific bitops uses parts of the generic implementation. > > Include the correct header. > > That doesn't work: > > fs/built-in.o: In function `ext4_mb_release_inode_pa': > mballoc.c:(.text+0x95a8a): undefined reference to `generic_find_next_le_bit' > fs/built-in.o: In function `ext4_mb_init_cache': > mballoc.c:(.text+0x967ea): undefined reference to `generic_find_next_le_bit' > > This still needs generic_find_next_le_bit which comes > from lib/find_next_bit.c. That one doesn't get built on s390 since we > don't set GENERIC_FIND_NEXT_BIT. > Currently we have the lengthly patch below queued. Similar issue on m68k. As Bastian also saw it on powerpc, I'm getting the impression the ext4 people don't (compile) test on big endian machines? Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH] Fix ext4 bitops @ 2008-02-03 12:39 ` Geert Uytterhoeven 0 siblings, 0 replies; 17+ messages in thread From: Geert Uytterhoeven @ 2008-02-03 12:39 UTC (permalink / raw) To: Heiko Carstens, aneesh.kumar Cc: linux-s390, Bastian Blank, Linux Kernel Development, Linux/PPC Development, Andrew Morton, linux-ext4 On Sun, 3 Feb 2008, Heiko Carstens wrote: > On Fri, Feb 01, 2008 at 10:04:04PM +0100, Bastian Blank wrote: > > On Fri, Feb 01, 2008 at 12:22:57PM -0800, Andrew Morton wrote: > > > On Fri, 1 Feb 2008 21:02:08 +0100 > > > Bastian Blank <bastian@waldi.eu.org> wrote: > > > > > > > Fix ext4 bitops. > > > > > > This is incomplete. Please tell us what was "fixed". > > > > > > If it was a build error then please quote the compile error output in the > > > changelog, as well as the usual description of what the problem is, and how > > > it was fixed. > > > > | fs/ext4/mballoc.c: In function 'ext4_mb_generate_buddy': > > | fs/ext4/mballoc.c:954: error: implicit declaration of function 'generic_find_next_le_bit' > > > > The s390 specific bitops uses parts of the generic implementation. > > Include the correct header. > > That doesn't work: > > fs/built-in.o: In function `ext4_mb_release_inode_pa': > mballoc.c:(.text+0x95a8a): undefined reference to `generic_find_next_le_bit' > fs/built-in.o: In function `ext4_mb_init_cache': > mballoc.c:(.text+0x967ea): undefined reference to `generic_find_next_le_bit' > > This still needs generic_find_next_le_bit which comes > from lib/find_next_bit.c. That one doesn't get built on s390 since we > don't set GENERIC_FIND_NEXT_BIT. > Currently we have the lengthly patch below queued. Similar issue on m68k. As Bastian also saw it on powerpc, I'm getting the impression the ext4 people don't (compile) test on big endian machines? Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH] Fix ext4 bitops 2008-02-03 12:39 ` Geert Uytterhoeven @ 2008-02-04 4:50 ` Aneesh Kumar K.V -1 siblings, 0 replies; 17+ messages in thread From: Aneesh Kumar K.V @ 2008-02-04 4:50 UTC (permalink / raw) To: Geert Uytterhoeven Cc: Heiko Carstens, Bastian Blank, Andrew Morton, linux-s390, Linux Kernel Development, Linux/PPC Development, linux-ext4 On Sun, Feb 03, 2008 at 01:39:02PM +0100, Geert Uytterhoeven wrote: > On Sun, 3 Feb 2008, Heiko Carstens wrote: > > On Fri, Feb 01, 2008 at 10:04:04PM +0100, Bastian Blank wrote: > > > On Fri, Feb 01, 2008 at 12:22:57PM -0800, Andrew Morton wrote: > > > > On Fri, 1 Feb 2008 21:02:08 +0100 > > > > Bastian Blank <bastian@waldi.eu.org> wrote: > > > > > > > > > Fix ext4 bitops. > > > > > > > > This is incomplete. Please tell us what was "fixed". > > > > > > > > If it was a build error then please quote the compile error output in the > > > > changelog, as well as the usual description of what the problem is, and how > > > > it was fixed. > > > > > > | fs/ext4/mballoc.c: In function 'ext4_mb_generate_buddy': > > > | fs/ext4/mballoc.c:954: error: implicit declaration of function 'generic_find_next_le_bit' > > > > > > The s390 specific bitops uses parts of the generic implementation. > > > Include the correct header. > > > > That doesn't work: > > > > fs/built-in.o: In function `ext4_mb_release_inode_pa': > > mballoc.c:(.text+0x95a8a): undefined reference to `generic_find_next_le_bit' > > fs/built-in.o: In function `ext4_mb_init_cache': > > mballoc.c:(.text+0x967ea): undefined reference to `generic_find_next_le_bit' > > > > This still needs generic_find_next_le_bit which comes > > from lib/find_next_bit.c. That one doesn't get built on s390 since we > > don't set GENERIC_FIND_NEXT_BIT. > > Currently we have the lengthly patch below queued. > > Similar issue on m68k. As Bastian also saw it on powerpc, I'm getting the > impression the ext4 people don't (compile) test on big endian machines? > > Gr{oetje,eeting}s, > I have sent this patches to linux-arch expecting a review from different arch people. It is true that the patches are tested only on powerpc, x86-64, x86. That's the primary reason of me sending the patches to linux-arch. http://marc.info/?l=linux-arch&m=119503501127737&w=2 -aneesh ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH] Fix ext4 bitops @ 2008-02-04 4:50 ` Aneesh Kumar K.V 0 siblings, 0 replies; 17+ messages in thread From: Aneesh Kumar K.V @ 2008-02-04 4:50 UTC (permalink / raw) To: Geert Uytterhoeven Cc: linux-s390, Heiko Carstens, Bastian Blank, Linux Kernel Development, Linux/PPC Development, Andrew Morton, linux-ext4 On Sun, Feb 03, 2008 at 01:39:02PM +0100, Geert Uytterhoeven wrote: > On Sun, 3 Feb 2008, Heiko Carstens wrote: > > On Fri, Feb 01, 2008 at 10:04:04PM +0100, Bastian Blank wrote: > > > On Fri, Feb 01, 2008 at 12:22:57PM -0800, Andrew Morton wrote: > > > > On Fri, 1 Feb 2008 21:02:08 +0100 > > > > Bastian Blank <bastian@waldi.eu.org> wrote: > > > > > > > > > Fix ext4 bitops. > > > > > > > > This is incomplete. Please tell us what was "fixed". > > > > > > > > If it was a build error then please quote the compile error output in the > > > > changelog, as well as the usual description of what the problem is, and how > > > > it was fixed. > > > > > > | fs/ext4/mballoc.c: In function 'ext4_mb_generate_buddy': > > > | fs/ext4/mballoc.c:954: error: implicit declaration of function 'generic_find_next_le_bit' > > > > > > The s390 specific bitops uses parts of the generic implementation. > > > Include the correct header. > > > > That doesn't work: > > > > fs/built-in.o: In function `ext4_mb_release_inode_pa': > > mballoc.c:(.text+0x95a8a): undefined reference to `generic_find_next_le_bit' > > fs/built-in.o: In function `ext4_mb_init_cache': > > mballoc.c:(.text+0x967ea): undefined reference to `generic_find_next_le_bit' > > > > This still needs generic_find_next_le_bit which comes > > from lib/find_next_bit.c. That one doesn't get built on s390 since we > > don't set GENERIC_FIND_NEXT_BIT. > > Currently we have the lengthly patch below queued. > > Similar issue on m68k. As Bastian also saw it on powerpc, I'm getting the > impression the ext4 people don't (compile) test on big endian machines? > > Gr{oetje,eeting}s, > I have sent this patches to linux-arch expecting a review from different arch people. It is true that the patches are tested only on powerpc, x86-64, x86. That's the primary reason of me sending the patches to linux-arch. http://marc.info/?l=linux-arch&m=119503501127737&w=2 -aneesh ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH] Fix ext4 bitops 2008-02-04 4:50 ` Aneesh Kumar K.V @ 2008-02-04 9:24 ` Heiko Carstens -1 siblings, 0 replies; 17+ messages in thread From: Heiko Carstens @ 2008-02-04 9:24 UTC (permalink / raw) To: Aneesh Kumar K.V Cc: Geert Uytterhoeven, Bastian Blank, Andrew Morton, linux-s390, Linux Kernel Development, Linux/PPC Development, linux-ext4 > > > > | fs/ext4/mballoc.c: In function 'ext4_mb_generate_buddy': > > > > | fs/ext4/mballoc.c:954: error: implicit declaration of function 'generic_find_next_le_bit' > > > > > > > > The s390 specific bitops uses parts of the generic implementation. > > > > Include the correct header. > > > > > > That doesn't work: > > > > > > fs/built-in.o: In function `ext4_mb_release_inode_pa': > > > mballoc.c:(.text+0x95a8a): undefined reference to `generic_find_next_le_bit' > > > fs/built-in.o: In function `ext4_mb_init_cache': > > > mballoc.c:(.text+0x967ea): undefined reference to `generic_find_next_le_bit' > > > > > > This still needs generic_find_next_le_bit which comes > > > from lib/find_next_bit.c. That one doesn't get built on s390 since we > > > don't set GENERIC_FIND_NEXT_BIT. > > > Currently we have the lengthly patch below queued. > > > > Similar issue on m68k. As Bastian also saw it on powerpc, I'm getting the > > impression the ext4 people don't (compile) test on big endian machines? > > > > Gr{oetje,eeting}s, > > > > I have sent this patches to linux-arch expecting a review from > different arch people. It is true that the patches are tested only on > powerpc, x86-64, x86. That's the primary reason of me sending the > patches to linux-arch. Is there anything special I need to do so the ext4 code actually uses ext2_find_next_bit() ? Haven't looked at the ext4 code, but I'd like to test if the s390 implementation is ok. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH] Fix ext4 bitops @ 2008-02-04 9:24 ` Heiko Carstens 0 siblings, 0 replies; 17+ messages in thread From: Heiko Carstens @ 2008-02-04 9:24 UTC (permalink / raw) To: Aneesh Kumar K.V Cc: linux-s390, Bastian Blank, Linux Kernel Development, Linux/PPC Development, Geert Uytterhoeven, Andrew Morton, linux-ext4 > > > > | fs/ext4/mballoc.c: In function 'ext4_mb_generate_buddy': > > > > | fs/ext4/mballoc.c:954: error: implicit declaration of function 'generic_find_next_le_bit' > > > > > > > > The s390 specific bitops uses parts of the generic implementation. > > > > Include the correct header. > > > > > > That doesn't work: > > > > > > fs/built-in.o: In function `ext4_mb_release_inode_pa': > > > mballoc.c:(.text+0x95a8a): undefined reference to `generic_find_next_le_bit' > > > fs/built-in.o: In function `ext4_mb_init_cache': > > > mballoc.c:(.text+0x967ea): undefined reference to `generic_find_next_le_bit' > > > > > > This still needs generic_find_next_le_bit which comes > > > from lib/find_next_bit.c. That one doesn't get built on s390 since we > > > don't set GENERIC_FIND_NEXT_BIT. > > > Currently we have the lengthly patch below queued. > > > > Similar issue on m68k. As Bastian also saw it on powerpc, I'm getting the > > impression the ext4 people don't (compile) test on big endian machines? > > > > Gr{oetje,eeting}s, > > > > I have sent this patches to linux-arch expecting a review from > different arch people. It is true that the patches are tested only on > powerpc, x86-64, x86. That's the primary reason of me sending the > patches to linux-arch. Is there anything special I need to do so the ext4 code actually uses ext2_find_next_bit() ? Haven't looked at the ext4 code, but I'd like to test if the s390 implementation is ok. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH] Fix ext4 bitops 2008-02-04 9:24 ` Heiko Carstens @ 2008-02-04 9:29 ` Aneesh Kumar K.V -1 siblings, 0 replies; 17+ messages in thread From: Aneesh Kumar K.V @ 2008-02-04 9:29 UTC (permalink / raw) To: Heiko Carstens Cc: Geert Uytterhoeven, Bastian Blank, Andrew Morton, linux-s390, Linux Kernel Development, Linux/PPC Development, linux-ext4 On Mon, Feb 04, 2008 at 10:24:36AM +0100, Heiko Carstens wrote: > > > > > | fs/ext4/mballoc.c: In function 'ext4_mb_generate_buddy': > > > > > | fs/ext4/mballoc.c:954: error: implicit declaration of function 'generic_find_next_le_bit' > > > > > > > > > > The s390 specific bitops uses parts of the generic implementation. > > > > > Include the correct header. > > > > > > > > That doesn't work: > > > > > > > > fs/built-in.o: In function `ext4_mb_release_inode_pa': > > > > mballoc.c:(.text+0x95a8a): undefined reference to `generic_find_next_le_bit' > > > > fs/built-in.o: In function `ext4_mb_init_cache': > > > > mballoc.c:(.text+0x967ea): undefined reference to `generic_find_next_le_bit' > > > > > > > > This still needs generic_find_next_le_bit which comes > > > > from lib/find_next_bit.c. That one doesn't get built on s390 since we > > > > don't set GENERIC_FIND_NEXT_BIT. > > > > Currently we have the lengthly patch below queued. > > > > > > Similar issue on m68k. As Bastian also saw it on powerpc, I'm getting the > > > impression the ext4 people don't (compile) test on big endian machines? > > > > > > Gr{oetje,eeting}s, > > > > > > > I have sent this patches to linux-arch expecting a review from > > different arch people. It is true that the patches are tested only on > > powerpc, x86-64, x86. That's the primary reason of me sending the > > patches to linux-arch. > > Is there anything special I need to do so the ext4 code actually uses > ext2_find_next_bit() ? Haven't looked at the ext4 code, but I'd like to > test if the s390 implementation is ok. With the latest linus kernel in git you can test it by mounting ext4 mount -t ext4dev <device> <mntpoint> -aneesh ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH] Fix ext4 bitops @ 2008-02-04 9:29 ` Aneesh Kumar K.V 0 siblings, 0 replies; 17+ messages in thread From: Aneesh Kumar K.V @ 2008-02-04 9:29 UTC (permalink / raw) To: Heiko Carstens Cc: linux-s390, Bastian Blank, Linux Kernel Development, Linux/PPC Development, Geert Uytterhoeven, Andrew Morton, linux-ext4 On Mon, Feb 04, 2008 at 10:24:36AM +0100, Heiko Carstens wrote: > > > > > | fs/ext4/mballoc.c: In function 'ext4_mb_generate_buddy': > > > > > | fs/ext4/mballoc.c:954: error: implicit declaration of function 'generic_find_next_le_bit' > > > > > > > > > > The s390 specific bitops uses parts of the generic implementation. > > > > > Include the correct header. > > > > > > > > That doesn't work: > > > > > > > > fs/built-in.o: In function `ext4_mb_release_inode_pa': > > > > mballoc.c:(.text+0x95a8a): undefined reference to `generic_find_next_le_bit' > > > > fs/built-in.o: In function `ext4_mb_init_cache': > > > > mballoc.c:(.text+0x967ea): undefined reference to `generic_find_next_le_bit' > > > > > > > > This still needs generic_find_next_le_bit which comes > > > > from lib/find_next_bit.c. That one doesn't get built on s390 since we > > > > don't set GENERIC_FIND_NEXT_BIT. > > > > Currently we have the lengthly patch below queued. > > > > > > Similar issue on m68k. As Bastian also saw it on powerpc, I'm getting the > > > impression the ext4 people don't (compile) test on big endian machines? > > > > > > Gr{oetje,eeting}s, > > > > > > > I have sent this patches to linux-arch expecting a review from > > different arch people. It is true that the patches are tested only on > > powerpc, x86-64, x86. That's the primary reason of me sending the > > patches to linux-arch. > > Is there anything special I need to do so the ext4 code actually uses > ext2_find_next_bit() ? Haven't looked at the ext4 code, but I'd like to > test if the s390 implementation is ok. With the latest linus kernel in git you can test it by mounting ext4 mount -t ext4dev <device> <mntpoint> -aneesh ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH] Fix ext4 bitops 2008-02-04 4:50 ` Aneesh Kumar K.V @ 2008-02-04 20:11 ` Geert Uytterhoeven -1 siblings, 0 replies; 17+ messages in thread From: Geert Uytterhoeven @ 2008-02-04 20:11 UTC (permalink / raw) To: Aneesh Kumar K.V Cc: Heiko Carstens, Bastian Blank, Andrew Morton, linux-s390, Linux Kernel Development, Linux/PPC Development, linux-ext4 On Mon, 4 Feb 2008, Aneesh Kumar K.V wrote: > On Sun, Feb 03, 2008 at 01:39:02PM +0100, Geert Uytterhoeven wrote: > > On Sun, 3 Feb 2008, Heiko Carstens wrote: > > > On Fri, Feb 01, 2008 at 10:04:04PM +0100, Bastian Blank wrote: > > > > On Fri, Feb 01, 2008 at 12:22:57PM -0800, Andrew Morton wrote: > > > > > On Fri, 1 Feb 2008 21:02:08 +0100 > > > > > Bastian Blank <bastian@waldi.eu.org> wrote: > > > > > > Fix ext4 bitops. > > > > > > > > > > This is incomplete. Please tell us what was "fixed". > > > > > > > > > > If it was a build error then please quote the compile error output in the > > > > > changelog, as well as the usual description of what the problem is, and how > > > > > it was fixed. > > > > > > > > | fs/ext4/mballoc.c: In function 'ext4_mb_generate_buddy': > > > > | fs/ext4/mballoc.c:954: error: implicit declaration of function 'generic_find_next_le_bit' > > > > > > > > The s390 specific bitops uses parts of the generic implementation. > > > > Include the correct header. > > > > > > That doesn't work: > > > > > > fs/built-in.o: In function `ext4_mb_release_inode_pa': > > > mballoc.c:(.text+0x95a8a): undefined reference to `generic_find_next_le_bit' > > > fs/built-in.o: In function `ext4_mb_init_cache': > > > mballoc.c:(.text+0x967ea): undefined reference to `generic_find_next_le_bit' > > > > > > This still needs generic_find_next_le_bit which comes > > > from lib/find_next_bit.c. That one doesn't get built on s390 since we > > > don't set GENERIC_FIND_NEXT_BIT. > > > Currently we have the lengthly patch below queued. > > > > Similar issue on m68k. As Bastian also saw it on powerpc, I'm getting the > > impression the ext4 people don't (compile) test on big endian machines? > > I have sent this patches to linux-arch expecting a review from > different arch people. It is true that the patches are tested only on > powerpc, x86-64, x86. That's the primary reason of me sending the > patches to linux-arch. > > http://marc.info/?l=linux-arch&m=119503501127737&w=2 Sometimes it's difficult to see what can go wrong due to a single patch that just adds a #define. Sorry, I missed the lack of prototype for generic_find_next_le_bit() and that we don't set GENERIC_FIND_NEXT_BIT, just like s390. And yes, usually I rely on the -mm autocompiler to catch things like this, but this time it didn't work out... Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH] Fix ext4 bitops @ 2008-02-04 20:11 ` Geert Uytterhoeven 0 siblings, 0 replies; 17+ messages in thread From: Geert Uytterhoeven @ 2008-02-04 20:11 UTC (permalink / raw) To: Aneesh Kumar K.V Cc: linux-s390, Heiko Carstens, Bastian Blank, Linux Kernel Development, Linux/PPC Development, Andrew Morton, linux-ext4 On Mon, 4 Feb 2008, Aneesh Kumar K.V wrote: > On Sun, Feb 03, 2008 at 01:39:02PM +0100, Geert Uytterhoeven wrote: > > On Sun, 3 Feb 2008, Heiko Carstens wrote: > > > On Fri, Feb 01, 2008 at 10:04:04PM +0100, Bastian Blank wrote: > > > > On Fri, Feb 01, 2008 at 12:22:57PM -0800, Andrew Morton wrote: > > > > > On Fri, 1 Feb 2008 21:02:08 +0100 > > > > > Bastian Blank <bastian@waldi.eu.org> wrote: > > > > > > Fix ext4 bitops. > > > > > > > > > > This is incomplete. Please tell us what was "fixed". > > > > > > > > > > If it was a build error then please quote the compile error output in the > > > > > changelog, as well as the usual description of what the problem is, and how > > > > > it was fixed. > > > > > > > > | fs/ext4/mballoc.c: In function 'ext4_mb_generate_buddy': > > > > | fs/ext4/mballoc.c:954: error: implicit declaration of function 'generic_find_next_le_bit' > > > > > > > > The s390 specific bitops uses parts of the generic implementation. > > > > Include the correct header. > > > > > > That doesn't work: > > > > > > fs/built-in.o: In function `ext4_mb_release_inode_pa': > > > mballoc.c:(.text+0x95a8a): undefined reference to `generic_find_next_le_bit' > > > fs/built-in.o: In function `ext4_mb_init_cache': > > > mballoc.c:(.text+0x967ea): undefined reference to `generic_find_next_le_bit' > > > > > > This still needs generic_find_next_le_bit which comes > > > from lib/find_next_bit.c. That one doesn't get built on s390 since we > > > don't set GENERIC_FIND_NEXT_BIT. > > > Currently we have the lengthly patch below queued. > > > > Similar issue on m68k. As Bastian also saw it on powerpc, I'm getting the > > impression the ext4 people don't (compile) test on big endian machines? > > I have sent this patches to linux-arch expecting a review from > different arch people. It is true that the patches are tested only on > powerpc, x86-64, x86. That's the primary reason of me sending the > patches to linux-arch. > > http://marc.info/?l=linux-arch&m=119503501127737&w=2 Sometimes it's difficult to see what can go wrong due to a single patch that just adds a #define. Sorry, I missed the lack of prototype for generic_find_next_le_bit() and that we don't set GENERIC_FIND_NEXT_BIT, just like s390. And yes, usually I rely on the -mm autocompiler to catch things like this, but this time it didn't work out... Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds ^ permalink raw reply [flat|nested] 17+ messages in thread
* [PATCH] Fix ext4 bitops @ 2008-02-01 20:02 Bastian Blank 2008-02-03 7:36 ` Benjamin Herrenschmidt 2008-02-04 5:22 ` Aneesh Kumar K.V 0 siblings, 2 replies; 17+ messages in thread From: Bastian Blank @ 2008-02-01 20:02 UTC (permalink / raw) To: linuxppc-dev, akpm; +Cc: linux-kernel Fix ext4 bitops. Signed-off-by: Bastian Blank <waldi@debian.org> diff --git a/include/asm-powerpc/bitops.h b/include/asm-powerpc/bitops.h index 220d9a7..d0980df 100644 --- a/include/asm-powerpc/bitops.h +++ b/include/asm-powerpc/bitops.h @@ -363,6 +363,8 @@ unsigned long generic_find_next_le_bit(const unsigned long *addr, unsigned long size, unsigned long offset); /* Bitmap functions for the ext2 filesystem */ +#include <asm-generic/bitops/le.h> + #define ext2_set_bit(nr,addr) \ __test_and_set_le_bit((nr), (unsigned long*)addr) #define ext2_clear_bit(nr, addr) \ ^ permalink raw reply related [flat|nested] 17+ messages in thread
* Re: [PATCH] Fix ext4 bitops 2008-02-01 20:02 Bastian Blank @ 2008-02-03 7:36 ` Benjamin Herrenschmidt 2008-02-04 5:22 ` Aneesh Kumar K.V 1 sibling, 0 replies; 17+ messages in thread From: Benjamin Herrenschmidt @ 2008-02-03 7:36 UTC (permalink / raw) To: Bastian Blank; +Cc: linuxppc-dev, akpm, linux-kernel On Fri, 2008-02-01 at 21:02 +0100, Bastian Blank wrote: > Fix ext4 bitops. Please provide a better description, as it's not obvious at first sight. > Signed-off-by: Bastian Blank <waldi@debian.org> > > diff --git a/include/asm-powerpc/bitops.h b/include/asm-powerpc/bitops.h > index 220d9a7..d0980df 100644 > --- a/include/asm-powerpc/bitops.h > +++ b/include/asm-powerpc/bitops.h > @@ -363,6 +363,8 @@ unsigned long generic_find_next_le_bit(const unsigned long *addr, > unsigned long size, unsigned long offset); > /* Bitmap functions for the ext2 filesystem */ > > +#include <asm-generic/bitops/le.h> A comment would be useful to indicate that this defines the _le versions of the bitops as it would be easy to mistake that for something else. > #define ext2_set_bit(nr,addr) \ > __test_and_set_le_bit((nr), (unsigned long*)addr) > #define ext2_clear_bit(nr, addr) \ > _______________________________________________ > Linuxppc-dev mailing list > Linuxppc-dev@ozlabs.org > https://ozlabs.org/mailman/listinfo/linuxppc-dev ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH] Fix ext4 bitops 2008-02-01 20:02 Bastian Blank 2008-02-03 7:36 ` Benjamin Herrenschmidt @ 2008-02-04 5:22 ` Aneesh Kumar K.V 1 sibling, 0 replies; 17+ messages in thread From: Aneesh Kumar K.V @ 2008-02-04 5:22 UTC (permalink / raw) To: Bastian Blank, linuxppc-dev, akpm, linux-kernel On Fri, Feb 01, 2008 at 09:02:40PM +0100, Bastian Blank wrote: > Fix ext4 bitops. > > Signed-off-by: Bastian Blank <waldi@debian.org> > > diff --git a/include/asm-powerpc/bitops.h b/include/asm-powerpc/bitops.h > index 220d9a7..d0980df 100644 > --- a/include/asm-powerpc/bitops.h > +++ b/include/asm-powerpc/bitops.h > @@ -363,6 +363,8 @@ unsigned long generic_find_next_le_bit(const unsigned long *addr, > unsigned long size, unsigned long offset); > /* Bitmap functions for the ext2 filesystem */ > > +#include <asm-generic/bitops/le.h> > + > #define ext2_set_bit(nr,addr) \ > __test_and_set_le_bit((nr), (unsigned long*)addr) > #define ext2_clear_bit(nr, addr) \ I am not sure what the changes are for. Can you send me the build logs with the compile error. I always test Ext4 on powerpc so not sure what went wrong. -aneesh ^ permalink raw reply [flat|nested] 17+ messages in thread
end of thread, other threads:[~2008-02-04 20:11 UTC | newest] Thread overview: 17+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2008-02-01 20:02 [PATCH] Fix ext4 bitops Bastian Blank 2008-02-01 20:22 ` Andrew Morton 2008-02-01 21:04 ` Bastian Blank 2008-02-03 12:12 ` Heiko Carstens 2008-02-03 12:39 ` Geert Uytterhoeven 2008-02-03 12:39 ` Geert Uytterhoeven 2008-02-04 4:50 ` Aneesh Kumar K.V 2008-02-04 4:50 ` Aneesh Kumar K.V 2008-02-04 9:24 ` Heiko Carstens 2008-02-04 9:24 ` Heiko Carstens 2008-02-04 9:29 ` Aneesh Kumar K.V 2008-02-04 9:29 ` Aneesh Kumar K.V 2008-02-04 20:11 ` Geert Uytterhoeven 2008-02-04 20:11 ` Geert Uytterhoeven -- strict thread matches above, loose matches on Subject: below -- 2008-02-01 20:02 Bastian Blank 2008-02-03 7:36 ` Benjamin Herrenschmidt 2008-02-04 5:22 ` Aneesh Kumar K.V
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.