Re: getting allwinner SoC support upstream (was Re: Uploading linux (3.9.4-1))
On Wed, Jun 05, 2013 at 08:46:30PM +0100, Luke Kenneth Casson Leighton wrote: > to begin to describe the problem in getting allwinner soc source code > upstream is this: not only do we have the usual "let's get it out the > door as fast as possible" learning curve of a very young, very new and > bewilderingly-successful fabless SoC company, but we also have a > completely new type of very successful and comprehensive > device-tree-like dynamic configuration system to deal with, which > allwinner have called "fex" [*1]. IBM for example pushs the code into the kernel before the silicon is even finished. Once a driver was removed because the project was scrapped before it reached the customers. Arm did the same for the 64bit variant of the architecture. Are the turn around times for the allwinner SoC stuff really shorter then two kernel releases? > basically at the time when device-tree was being thought of, > allwinner needed something that they could *right then* - not waiting > for developers to finish device-tree - they needed to be able to > reconfigure their customer's kernels *without* needing a recompile. > so they invented the script.fex system, which is a simple config.ini > file-format, compile it to binary, and get the bootloader to upload it > to memory and read it. So it was invented over five years ago? What did you do in the last two years since it was finished in all its glory? > what's the point of mentioning this? Obviously nothing, as the decision stands. > well, the point is: the expectation of the linux kernel developers is > that Everyone Must Convert To DeviceTree. implicitly behind that is, > i believe, an expectation that if you *don't* convert to Device Tree, > you can kiss upstream submission goodbye. and, in allwinner's case, > that's simply not going to happen. Yes. Our project, our rules. If you don't like them, go away. > add to this the fact that they've already taken *five* near-identical > copies of each version of their drivers (for sun3i up to sun7i) - if > you do a recursive diff in the drivers/usb/sun7i_usb and > drivers/usb/sun4i_usb directories, the discrepancies are negligeable > (and are in many cases a regression, reintroducing known or new > bugs!), you can start to see that they simply have no idea how to work > with the free software community (they're too busy) and that they're > not really about to start, either. Send patches as everyone else. Bastian -- I've already got a female to worry about. Her name is the Enterprise. -- Kirk, "The Corbomite Maneuver", stardate 1514.0 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: getting allwinner SoC support upstream (was Re: Uploading linux (3.9.4-1))
On Wed, Jun 05, 2013 at 08:46:30PM +0100, Luke Kenneth Casson Leighton wrote: to begin to describe the problem in getting allwinner soc source code upstream is this: not only do we have the usual let's get it out the door as fast as possible learning curve of a very young, very new and bewilderingly-successful fabless SoC company, but we also have a completely new type of very successful and comprehensive device-tree-like dynamic configuration system to deal with, which allwinner have called fex [*1]. IBM for example pushs the code into the kernel before the silicon is even finished. Once a driver was removed because the project was scrapped before it reached the customers. Arm did the same for the 64bit variant of the architecture. Are the turn around times for the allwinner SoC stuff really shorter then two kernel releases? basically at the time when device-tree was being thought of, allwinner needed something that they could *right then* - not waiting for developers to finish device-tree - they needed to be able to reconfigure their customer's kernels *without* needing a recompile. so they invented the script.fex system, which is a simple config.ini file-format, compile it to binary, and get the bootloader to upload it to memory and read it. So it was invented over five years ago? What did you do in the last two years since it was finished in all its glory? what's the point of mentioning this? Obviously nothing, as the decision stands. well, the point is: the expectation of the linux kernel developers is that Everyone Must Convert To DeviceTree. implicitly behind that is, i believe, an expectation that if you *don't* convert to Device Tree, you can kiss upstream submission goodbye. and, in allwinner's case, that's simply not going to happen. Yes. Our project, our rules. If you don't like them, go away. add to this the fact that they've already taken *five* near-identical copies of each version of their drivers (for sun3i up to sun7i) - if you do a recursive diff in the drivers/usb/sun7i_usb and drivers/usb/sun4i_usb directories, the discrepancies are negligeable (and are in many cases a regression, reintroducing known or new bugs!), you can start to see that they simply have no idea how to work with the free software community (they're too busy) and that they're not really about to start, either. Send patches as everyone else. Bastian -- I've already got a female to worry about. Her name is the Enterprise. -- Kirk, The Corbomite Maneuver, stardate 1514.0 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 07/13] Initialize per cpu lowcores on cpu hotplug.
On Wed, Feb 20, 2008 at 10:45:52AM +0100, Heiko Carstens wrote: > - copy_page(lowcore, _lowcore); > + memcpy(lowcore, _lowcore, 512); Okay > memset((void *)lowcore + 512, 0, sizeof(*lowcore) - 512); Not completely okay. void pointer are not allowed in arithmetic. gcc handles void * as char * in this case, but I think it should usualy be avoided. Bastian -- Peace was the way. -- Kirk, "The City on the Edge of Forever", stardate unknown -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 07/13] Initialize per cpu lowcores on cpu hotplug.
On Wed, Feb 20, 2008 at 10:45:52AM +0100, Heiko Carstens wrote: - copy_page(lowcore, S390_lowcore); + memcpy(lowcore, S390_lowcore, 512); Okay memset((void *)lowcore + 512, 0, sizeof(*lowcore) - 512); Not completely okay. void pointer are not allowed in arithmetic. gcc handles void * as char * in this case, but I think it should usualy be avoided. Bastian -- Peace was the way. -- Kirk, The City on the Edge of Forever, stardate unknown -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 07/13] Initialize per cpu lowcores on cpu hotplug.
On Tue, Feb 19, 2008 at 03:40:54PM +0100, Martin Schwidefsky wrote: > + /* > + * Only need to copy the first 512 bytes from address 0. But since > + * the compiler emits a warning if src == NULL for memcpy use copy_page > + * instead. Copies more than needed but this code is not performance > + * critical. > + */ > + copy_page(lowcore, _lowcore); Boah, workaround alert. Why do you not fix the compiler? Bastian -- We fight only when there is no other choice. We prefer the ways of peaceful contact. -- Kirk, "Spectre of the Gun", stardate 4385.3 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 07/13] Initialize per cpu lowcores on cpu hotplug.
On Tue, Feb 19, 2008 at 03:40:54PM +0100, Martin Schwidefsky wrote: + /* + * Only need to copy the first 512 bytes from address 0. But since + * the compiler emits a warning if src == NULL for memcpy use copy_page + * instead. Copies more than needed but this code is not performance + * critical. + */ + copy_page(lowcore, S390_lowcore); Boah, workaround alert. Why do you not fix the compiler? Bastian -- We fight only when there is no other choice. We prefer the ways of peaceful contact. -- Kirk, Spectre of the Gun, stardate 4385.3 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] splice: fix user pointer access in get_iovec_page_array()
On Sun, Feb 10, 2008 at 04:47:57PM +0200, Pekka J Enberg wrote:
> From: Bastian Blank <[EMAIL PROTECTED]>
>
> The commit 8811930dc74a503415b35c4a79d14fb0b408a361 ("splice: missing user
> pointer access verification") added access_ok() to copy_from_user_mmap_sem()
> which only ensures we can copy the struct iovecs from userspace to the kernel
> but we also must check whether we can access the actual memory region pointed
> to by the struct iovec to close the local root exploit.
>
> Cc: <[EMAIL PROTECTED]>
> Cc: Jens Axboe <[EMAIL PROTECTED]>
> Cc: Andrew Morton <[EMAIL PROTECTED]>
> Signed-off-by: Pekka Enberg <[EMAIL PROTECTED]>
Signed-off-by: Bastian Blank <[EMAIL PROTECTED]>
> Index: linux-2.6/fs/splice.c
> ===
> --- linux-2.6.orig/fs/splice.c
> +++ linux-2.6/fs/splice.c
> @@ -1237,6 +1237,9 @@ static int get_iovec_page_array(const st
> if (unlikely(!base))
> break;
>
> + if (unlikely(!access_ok(VERIFY_READ, base, len)))
> + break;
> +
> /*
>* Get this base offset and number of pages, then map
>* in the user pages.
--
Those who hate and fight must stop themselves -- otherwise it is not stopped.
-- Spock, "Day of the Dove", stardate unknown
signature.asc
Description: Digital signature
Re: [PATCH] kernel 2.6.24.1 still vulnerable to the vmsplice local root exploit
On Sun, Feb 10, 2008 at 12:39:05PM +, Niki Denev wrote: > This patch is against 2.6.24.1 which has already the fix to vmsplice_to_user > With it i can't exploit the hole, and it is returns "invalid address" This is the vmsplice_to_pipe path and I have many reports that it is not fixed. Bastian -- If there are self-made purgatories, then we all have to live in them. -- Spock, "This Side of Paradise", stardate 3417.7 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] kernel 2.6.24.1 still vulnerable to the vmsplice local root exploit
On Sun, Feb 10, 2008 at 04:40:53AM -0500, Niki Denev wrote:
> this fixed the problem for me (kernel 2.6.24.1) :
> It appears that the initial patch checked the input to vmsplice_to_user,
> but the exploit used vmsplice_to_pipe which remained open to the attack.
This patch is broken. It opens the old hole again.
> @@ -1450,6 +1454,31 @@
> .ops = _page_pipe_buf_ops,
> };
>
> + error = ret = 0;
> +
> + /*
> + * Get user address base and length for this iovec.
> + */
> + error = get_user(base, >iov_base);
> + if (unlikely(error))
> + return error;
> + error = get_user(len, >iov_len);
> + if (unlikely(error))
> + return error;
iov is unchecked.
> + if (unlikely(!access_ok(VERIFY_WRITE, base, len))) {
> + return -EFAULT;
> + }
Use VERIFY_READ and this only checks the first entry.
I checked the following patch and it at least fixes the known exploit.
diff --git a/fs/splice.c b/fs/splice.c
index 14e2262..80beb2b 100644
--- a/fs/splice.c
+++ b/fs/splice.c
@@ -1237,6 +1237,11 @@ static int get_iovec_page_array(const struct iovec
__user *iov,
if (unlikely(!base))
break;
+ if (!access_ok(VERIFY_READ, base, len)) {
+ error = -EFAULT;
+ break;
+ }
+
/*
* Get this base offset and number of pages, then map
* in the user pages.
--
Even historians fail to learn from history -- they repeat the same mistakes.
-- John Gill, "Patterns of Force", stardate 2534.7
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] kernel 2.6.24.1 still vulnerable to the vmsplice local root exploit
On Sun, Feb 10, 2008 at 04:40:53AM -0500, Niki Denev wrote:
this fixed the problem for me (kernel 2.6.24.1) :
It appears that the initial patch checked the input to vmsplice_to_user,
but the exploit used vmsplice_to_pipe which remained open to the attack.
This patch is broken. It opens the old hole again.
@@ -1450,6 +1454,31 @@
.ops = user_page_pipe_buf_ops,
};
+ error = ret = 0;
+
+ /*
+ * Get user address base and length for this iovec.
+ */
+ error = get_user(base, iov-iov_base);
+ if (unlikely(error))
+ return error;
+ error = get_user(len, iov-iov_len);
+ if (unlikely(error))
+ return error;
iov is unchecked.
+ if (unlikely(!access_ok(VERIFY_WRITE, base, len))) {
+ return -EFAULT;
+ }
Use VERIFY_READ and this only checks the first entry.
I checked the following patch and it at least fixes the known exploit.
diff --git a/fs/splice.c b/fs/splice.c
index 14e2262..80beb2b 100644
--- a/fs/splice.c
+++ b/fs/splice.c
@@ -1237,6 +1237,11 @@ static int get_iovec_page_array(const struct iovec
__user *iov,
if (unlikely(!base))
break;
+ if (!access_ok(VERIFY_READ, base, len)) {
+ error = -EFAULT;
+ break;
+ }
+
/*
* Get this base offset and number of pages, then map
* in the user pages.
--
Even historians fail to learn from history -- they repeat the same mistakes.
-- John Gill, Patterns of Force, stardate 2534.7
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] kernel 2.6.24.1 still vulnerable to the vmsplice local root exploit
On Sun, Feb 10, 2008 at 12:39:05PM +, Niki Denev wrote: This patch is against 2.6.24.1 which has already the fix to vmsplice_to_user With it i can't exploit the hole, and it is returns invalid address This is the vmsplice_to_pipe path and I have many reports that it is not fixed. Bastian -- If there are self-made purgatories, then we all have to live in them. -- Spock, This Side of Paradise, stardate 3417.7 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] splice: fix user pointer access in get_iovec_page_array()
On Sun, Feb 10, 2008 at 04:47:57PM +0200, Pekka J Enberg wrote: From: Bastian Blank [EMAIL PROTECTED] The commit 8811930dc74a503415b35c4a79d14fb0b408a361 (splice: missing user pointer access verification) added access_ok() to copy_from_user_mmap_sem() which only ensures we can copy the struct iovecs from userspace to the kernel but we also must check whether we can access the actual memory region pointed to by the struct iovec to close the local root exploit. Cc: [EMAIL PROTECTED] Cc: Jens Axboe [EMAIL PROTECTED] Cc: Andrew Morton [EMAIL PROTECTED] Signed-off-by: Pekka Enberg [EMAIL PROTECTED] Signed-off-by: Bastian Blank [EMAIL PROTECTED] Index: linux-2.6/fs/splice.c === --- linux-2.6.orig/fs/splice.c +++ linux-2.6/fs/splice.c @@ -1237,6 +1237,9 @@ static int get_iovec_page_array(const st if (unlikely(!base)) break; + if (unlikely(!access_ok(VERIFY_READ, base, len))) + break; + /* * Get this base offset and number of pages, then map * in the user pages. -- Those who hate and fight must stop themselves -- otherwise it is not stopped. -- Spock, Day of the Dove, stardate unknown signature.asc Description: Digital signature
Re: [PATCH] Remove old definition of setup_per_cpu_areas
On Fri, Feb 01, 2008 at 09:16:15PM +0100, Bastian Blank wrote:
> Remove old definition of setup_per_cpu_areas.
This was completely wrong. Lets try it again.
Adopt x86 percpu changes for powerpc and ia64.
dd5af90a7f3d79e04b7eace9a98644dbf2038f4d replaced the config variable
ARCH_SETS_UP_PER_CPU_AREA with HAVE_SETUP_PER_CPU_AREA and moved
percpu_modcopy into kernel/module.c.
Do the same for ia64 and powerpc.
| init/main.c:376: error: static declaration of ‘setup_per_cpu_areas’ follows
non-static declaration
| include/asm/percpu.h:33: error: previous declaration of ‘setup_per_cpu_areas’
was here
Signed-off-by: Bastian Blank <[EMAIL PROTECTED]>
diff --git a/arch/ia64/Kconfig b/arch/ia64/Kconfig
index 5a41e75..c9307c9 100644
--- a/arch/ia64/Kconfig
+++ b/arch/ia64/Kconfig
@@ -80,7 +80,7 @@ config GENERIC_TIME_VSYSCALL
bool
default y
-config ARCH_SETS_UP_PER_CPU_AREA
+config HAVE_SETUP_PER_CPU_AREA
def_bool y
config DMI
diff --git a/arch/ia64/kernel/module.c b/arch/ia64/kernel/module.c
index e699eb6..bbcdcfd 100644
--- a/arch/ia64/kernel/module.c
+++ b/arch/ia64/kernel/module.c
@@ -941,13 +941,3 @@ module_arch_cleanup (struct module *mod)
unw_remove_unwind_table(mod->arch.core_unw_table);
}
-#ifdef CONFIG_SMP
-void
-percpu_modcopy (void *pcpudst, const void *src, unsigned long size)
-{
- unsigned int i;
- for_each_possible_cpu(i) {
- memcpy(pcpudst + per_cpu_offset(i), src, size);
- }
-}
-#endif /* CONFIG_SMP */
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index fb85f6b..bb16443 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -42,7 +42,7 @@ config GENERIC_HARDIRQS
bool
default y
-config ARCH_SETS_UP_PER_CPU_AREA
+config HAVE_SETUP_PER_CPU_AREA
def_bool PPC64
config IRQ_PER_CPU
diff --git a/arch/sparc64/Kconfig b/arch/sparc64/Kconfig
index 26f5791..73fc05d 100644
--- a/arch/sparc64/Kconfig
+++ b/arch/sparc64/Kconfig
@@ -66,7 +66,7 @@ config AUDIT_ARCH
bool
default y
-config ARCH_SETS_UP_PER_CPU_AREA
+config HAVE_SETUP_PER_CPU_AREA
def_bool y
config ARCH_NO_VIRT_TO_BUS
diff --git a/include/asm-ia64/percpu.h b/include/asm-ia64/percpu.h
index 0095bcf..a4af49f 100644
--- a/include/asm-ia64/percpu.h
+++ b/include/asm-ia64/percpu.h
@@ -38,8 +38,9 @@ DECLARE_PER_CPU(unsigned long, local_per_cpu_offset);
#define __get_cpu_var(var) (*RELOC_HIDE(_cpu__##var,
__ia64_per_cpu_var(local_per_cpu_offset)))
#define __raw_get_cpu_var(var) (*RELOC_HIDE(_cpu__##var,
__ia64_per_cpu_var(local_per_cpu_offset)))
-extern void percpu_modcopy(void *pcpudst, const void *src, unsigned long size);
+#ifdef CONFIG_HAVE_SETUP_PER_CPU_AREA
extern void setup_per_cpu_areas (void);
+#endif
extern void *per_cpu_init(void);
#else /* ! SMP */
diff --git a/include/asm-powerpc/percpu.h b/include/asm-powerpc/percpu.h
index cc1cbf6..ea8cbb7 100644
--- a/include/asm-powerpc/percpu.h
+++ b/include/asm-powerpc/percpu.h
@@ -21,16 +21,9 @@
#define __get_cpu_var(var) (*RELOC_HIDE(_cpu__##var, __my_cpu_offset()))
#define __raw_get_cpu_var(var) (*RELOC_HIDE(_cpu__##var,
local_paca->data_offset))
-/* A macro to avoid #include hell... */
-#define percpu_modcopy(pcpudst, src, size) \
-do { \
- unsigned int __i; \
- for_each_possible_cpu(__i) \
- memcpy((pcpudst)+__per_cpu_offset(__i), \
- (src), (size)); \
-} while (0)
-
+#ifdef CONFIG_HAVE_SETUP_PER_CPU_AREA
extern void setup_per_cpu_areas(void);
+#endif
#else /* ! SMP */
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Fix ext4 bitops
On Fri, Feb 01, 2008 at 12:22:57PM -0800, Andrew Morton wrote: > On Fri, 1 Feb 2008 21:02:08 +0100 > Bastian Blank <[EMAIL PROTECTED]> 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 > > + > > #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 [EMAIL PROTECTED] > 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 -- 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/
[PATCH] Fix ext4 bitops
Fix ext4 bitops. Signed-off-by: Bastian Blank <[EMAIL PROTECTED]> 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 + #define ext2_set_bit(nr,addr) \ __test_and_set_le_bit((nr), (unsigned long*)addr) #define ext2_clear_bit(nr, addr) \ -- 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/
[PATCH] Fix ext4 bitops
Fix ext4 bitops. Signed-off-by: Bastian Blank <[EMAIL PROTECTED]> 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 + #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-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/
[PATCH] Remove old definition of setup_per_cpu_areas
Remove old definition of setup_per_cpu_areas.
The definition is done depending on the new config variable
HAVE_SETUP_PER_CPU_AREA.
Signed-off-by: Bastian Blank <[EMAIL PROTECTED]>
diff --git a/include/asm-powerpc/percpu.h b/include/asm-powerpc/percpu.h
index cc1cbf6..f309d34 100644
--- a/include/asm-powerpc/percpu.h
+++ b/include/asm-powerpc/percpu.h
@@ -30,8 +30,6 @@ do {
\
(src), (size)); \
} while (0)
-extern void setup_per_cpu_areas(void);
-
#else /* ! SMP */
#define per_cpu(var, cpu) (*((void)(cpu),
_cpu__##var))
--
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/
[PATCH] Remove old definition of setup_per_cpu_areas
Remove old definition of setup_per_cpu_areas.
The definition is done depending on the new config variable
HAVE_SETUP_PER_CPU_AREA.
Signed-off-by: Bastian Blank [EMAIL PROTECTED]
diff --git a/include/asm-powerpc/percpu.h b/include/asm-powerpc/percpu.h
index cc1cbf6..f309d34 100644
--- a/include/asm-powerpc/percpu.h
+++ b/include/asm-powerpc/percpu.h
@@ -30,8 +30,6 @@ do {
\
(src), (size)); \
} while (0)
-extern void setup_per_cpu_areas(void);
-
#else /* ! SMP */
#define per_cpu(var, cpu) (*((void)(cpu),
per_cpu__##var))
--
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/
[PATCH] Fix ext4 bitops
Fix ext4 bitops. Signed-off-by: Bastian Blank [EMAIL PROTECTED] 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) \ -- 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/
[PATCH] Fix ext4 bitops
Fix ext4 bitops. Signed-off-by: Bastian Blank [EMAIL PROTECTED] 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-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Fix ext4 bitops
On Fri, Feb 01, 2008 at 12:22:57PM -0800, Andrew Morton wrote: On Fri, 1 Feb 2008 21:02:08 +0100 Bastian Blank [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 7/24] consolidate msr.h
On Fri, Nov 09, 2007 at 04:42:48PM -0200, Glauber de Oliveira Costa wrote: > - wrmsrl(MSR_CSTAR, ia32_cstar_target); > + wrmsrl(MSR_CSTAR, (u64)ia32_cstar_target); Hmm, why do you add explicit casts? The compiler should convert that correctly on its own. > +static inline void wrmsrl(unsigned int msr, unsigned long long val) Hmm, long long is 64 bit on all x86, but why not use explicit u64 to show that? Bastian -- Captain's Log, star date 21:34.5... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 7/24] consolidate msr.h
On Fri, Nov 09, 2007 at 04:42:48PM -0200, Glauber de Oliveira Costa wrote: - wrmsrl(MSR_CSTAR, ia32_cstar_target); + wrmsrl(MSR_CSTAR, (u64)ia32_cstar_target); Hmm, why do you add explicit casts? The compiler should convert that correctly on its own. +static inline void wrmsrl(unsigned int msr, unsigned long long val) Hmm, long long is 64 bit on all x86, but why not use explicit u64 to show that? Bastian -- Captain's Log, star date 21:34.5... - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 3/6] sclp: call sclp_init() from start_kernel().
On Fri, Nov 16, 2007 at 03:29:45PM +0100, Martin Schwidefsky wrote:
> #else
> static inline void acpi_early_init(void) { }
> #endif
> +#ifdef CONFIG_S390
> +extern int sclp_init(void);
> +#else
> +static inline int sclp_init(void) {return 0;}
> +#endif
> #ifndef CONFIG_DEBUG_RODATA
> static inline void mark_rodata_ro(void) { }
> #endif
> @@ -643,6 +648,7 @@ asmlinkage void __init start_kernel(void
> check_bugs();
>
> acpi_early_init(); /* before LAPIC and SMP init */
> + sclp_init();
What happens if sclp_init fails? The other early init calls explicitely
returns void and handels the error internal.
Bastian
--
Time is fluid ... like a river with currents, eddies, backwash.
-- Spock, "The City on the Edge of Forever", stardate 3134.0
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 3/6] sclp: call sclp_init() from start_kernel().
On Fri, Nov 16, 2007 at 03:29:45PM +0100, Martin Schwidefsky wrote:
#else
static inline void acpi_early_init(void) { }
#endif
+#ifdef CONFIG_S390
+extern int sclp_init(void);
+#else
+static inline int sclp_init(void) {return 0;}
+#endif
#ifndef CONFIG_DEBUG_RODATA
static inline void mark_rodata_ro(void) { }
#endif
@@ -643,6 +648,7 @@ asmlinkage void __init start_kernel(void
check_bugs();
acpi_early_init(); /* before LAPIC and SMP init */
+ sclp_init();
What happens if sclp_init fails? The other early init calls explicitely
returns void and handels the error internal.
Bastian
--
Time is fluid ... like a river with currents, eddies, backwash.
-- Spock, The City on the Edge of Forever, stardate 3134.0
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 5/6] Move psw_set_key.
On Tue, Jun 19, 2007 at 10:45:21AM +0200, Martin Schwidefsky wrote: > Move psw_set_key() from ptrace.h to processor.h which is a more > suitable place for it. In addition the moves makes the function > invisible to user space. Hmm, this does not really describe the changes. Bastian -- Violence in reality is quite different from theory. -- Spock, "The Cloud Minders", stardate 5818.4 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 5/6] Move psw_set_key.
On Tue, Jun 19, 2007 at 10:45:21AM +0200, Martin Schwidefsky wrote: Move psw_set_key() from ptrace.h to processor.h which is a more suitable place for it. In addition the moves makes the function invisible to user space. Hmm, this does not really describe the changes. Bastian -- Violence in reality is quite different from theory. -- Spock, The Cloud Minders, stardate 5818.4 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Xen-devel] [patch 19/28]xen: Add early printk support via hvc console
On Thu, May 10, 2007 at 05:07:02PM -0700, Jeremy Fitzhardinge wrote:
> +#ifdef CONFIG_XEN
xenboot_console is only available with CONFIG_HVC_XEN.
> + } else if (!strncmp(buf, "xen", 3)) {
> + early_console = _console;
> +#endif
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [Xen-devel] [patch 19/28]xen: Add early printk support via hvc console
On Thu, May 10, 2007 at 05:07:02PM -0700, Jeremy Fitzhardinge wrote:
+#ifdef CONFIG_XEN
xenboot_console is only available with CONFIG_HVC_XEN.
+ } else if (!strncmp(buf, xen, 3)) {
+ early_console = xenboot_console;
+#endif
-
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/
[PATCH] Allow reading tainted flag as user
The commit 34f5a39899f3f3e815da64f48ddb72942d86c366 restricted reading of the tainted value. The attached patch changes this back to a write-only check and restores the read behaviour of older versions. Signed-off-by: Bastian Blank <[EMAIL PROTECTED]> -- The joys of love made her human and the agonies of love destroyed her. -- Spock, "Requiem for Methuselah", stardate 5842.8 signature.asc Description: Digital signature
Re: [PATCH] Allow reading tainted flag as user
On Sun, Apr 22, 2007 at 01:50:45AM -0700, Andrew Morton wrote:
> On Sun, 22 Apr 2007 10:39:41 +0200 Bastian Blank <[EMAIL PROTECTED]> wrote:
>
> > The commit 34f5a39899f3f3e815da64f48ddb72942d86c366 restricted reading
> > of the tainted value. The attached patch changes this back to a
> > write-only check and restores the read behaviour of older versions.
> >
> > Signed-off-by: Bastian Blank <[EMAIL PROTECTED]>
>
> there's no patch here.
Ups.
diff --git a/kernel/sysctl.c b/kernel/sysctl.c
index 1b255df..c904748 100644
--- a/kernel/sysctl.c
+++ b/kernel/sysctl.c
@@ -1676,7 +1676,7 @@ static int proc_dointvec_taint(ctl_table *table, int
write, struct file *filp,
{
int op;
- if (!capable(CAP_SYS_ADMIN))
+ if (write && !capable(CAP_SYS_ADMIN))
return -EPERM;
op = OP_OR;
--
Captain's Log, star date 21:34.5...
signature.asc
Description: Digital signature
Re: [PATCH] Allow reading tainted flag as user
On Sun, Apr 22, 2007 at 01:50:45AM -0700, Andrew Morton wrote:
On Sun, 22 Apr 2007 10:39:41 +0200 Bastian Blank [EMAIL PROTECTED] wrote:
The commit 34f5a39899f3f3e815da64f48ddb72942d86c366 restricted reading
of the tainted value. The attached patch changes this back to a
write-only check and restores the read behaviour of older versions.
Signed-off-by: Bastian Blank [EMAIL PROTECTED]
there's no patch here.
Ups.
diff --git a/kernel/sysctl.c b/kernel/sysctl.c
index 1b255df..c904748 100644
--- a/kernel/sysctl.c
+++ b/kernel/sysctl.c
@@ -1676,7 +1676,7 @@ static int proc_dointvec_taint(ctl_table *table, int
write, struct file *filp,
{
int op;
- if (!capable(CAP_SYS_ADMIN))
+ if (write !capable(CAP_SYS_ADMIN))
return -EPERM;
op = OP_OR;
--
Captain's Log, star date 21:34.5...
signature.asc
Description: Digital signature
[PATCH] Allow reading tainted flag as user
The commit 34f5a39899f3f3e815da64f48ddb72942d86c366 restricted reading of the tainted value. The attached patch changes this back to a write-only check and restores the read behaviour of older versions. Signed-off-by: Bastian Blank [EMAIL PROTECTED] -- The joys of love made her human and the agonies of love destroyed her. -- Spock, Requiem for Methuselah, stardate 5842.8 signature.asc Description: Digital signature
Re: [Patch 1/2] add for_each_substring() and match_substring()
On Tue, Mar 06, 2007 at 08:19:23PM +0100, Martin Peschke wrote:
> +char *match_to(const char *cs, const char *ct)
> +{
> + char *delim = strpbrk(cs, ct);
> + if (delim)
> + return delim;
> + else if (*cs != '\0')
> + return (char *)(cs + strlen(cs));
This disallows the use of match_to with a real constant char array,
please remove the const from the prototyp.
Bastian
--
"Get back to your stations!"
"We're beaming down to the planet, sir."
-- Kirk and Mr. Leslie, "This Side of Paradise",
stardate 3417.3
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [Patch 1/2] add for_each_substring() and match_substring()
On Tue, Mar 06, 2007 at 08:19:23PM +0100, Martin Peschke wrote:
+char *match_to(const char *cs, const char *ct)
+{
+ char *delim = strpbrk(cs, ct);
+ if (delim)
+ return delim;
+ else if (*cs != '\0')
+ return (char *)(cs + strlen(cs));
This disallows the use of match_to with a real constant char array,
please remove the const from the prototyp.
Bastian
--
Get back to your stations!
We're beaming down to the planet, sir.
-- Kirk and Mr. Leslie, This Side of Paradise,
stardate 3417.3
-
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/
ibmvstgt/aio broken with 2.6.20-rc6 powerpc
Hi folks I'm not really sure if this is a ibmvstgt or a generic aio problem. I tried ibmvstgt on my openpower and the kernel shows the following warning several times: | Jan 28 15:11:15 waldi kernel: Badness at arch/powerpc/mm/slb.c:95 | Jan 28 15:11:15 waldi kernel: Call Trace: | Jan 28 15:11:15 waldi kernel: [C282B750] [C000EC94] .show_stack+0x68/0x1b0 (unreliable) | Jan 28 15:11:15 waldi kernel: [C282B7F0] [C015ED64] .report_bug+0x94/0xe8 | Jan 28 15:11:15 waldi kernel: [C282B880] [C00228DC] .program_check_exception+0x140/0x54c | Jan 28 15:11:15 waldi kernel: [C282B920] [C0004774] program_check_common+0xf4/0x100 | Jan 28 15:11:15 waldi kernel: --- Exception: 700 at .slb_flush_and_rebolt+0xc/0xe0 | Jan 28 15:11:15 waldi kernel: LR = .switch_slb+0xac/0x1a0 | Jan 28 15:11:15 waldi kernel: [C282BC10] [] 0x (unreliable) | Jan 28 15:11:15 waldi kernel: [C282BCB0] [C00E1750] .aio_kick_handler+0x128/0x278 | Jan 28 15:11:15 waldi kernel: [C282BD60] [C0066380] .run_workqueue+0xec/0x1d4 | Jan 28 15:11:15 waldi kernel: [C282BE00] [C0066F2C] .worker_thread+0x164/0x1bc | Jan 28 15:11:15 waldi kernel: [C282BEE0] [C006B6E8] .kthread+0x120/0x170 | Jan 28 15:11:15 waldi kernel: [C282BF90] [C0024204] .kernel_thread+0x4c/0x68 One possibility: aio_kick_handler calls use_mm. use_mm calls switch_mm. It seems that 90aef12e6dd609e1ad7fb70044eedc78ca55ee5e changed that from activate_mm. activate_mm on powerpc disables interupts and calls swtich_mm. So switch_mm is now called with interrupts enabled and runs into the WARN_ON. Bastian -- She won' go Warp 7, Cap'n! The batteries are dead! - 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/
ibmvstgt/aio broken with 2.6.20-rc6 powerpc
Hi folks I'm not really sure if this is a ibmvstgt or a generic aio problem. I tried ibmvstgt on my openpower and the kernel shows the following warning several times: | Jan 28 15:11:15 waldi kernel: Badness at arch/powerpc/mm/slb.c:95 | Jan 28 15:11:15 waldi kernel: Call Trace: | Jan 28 15:11:15 waldi kernel: [C282B750] [C000EC94] .show_stack+0x68/0x1b0 (unreliable) | Jan 28 15:11:15 waldi kernel: [C282B7F0] [C015ED64] .report_bug+0x94/0xe8 | Jan 28 15:11:15 waldi kernel: [C282B880] [C00228DC] .program_check_exception+0x140/0x54c | Jan 28 15:11:15 waldi kernel: [C282B920] [C0004774] program_check_common+0xf4/0x100 | Jan 28 15:11:15 waldi kernel: --- Exception: 700 at .slb_flush_and_rebolt+0xc/0xe0 | Jan 28 15:11:15 waldi kernel: LR = .switch_slb+0xac/0x1a0 | Jan 28 15:11:15 waldi kernel: [C282BC10] [] 0x (unreliable) | Jan 28 15:11:15 waldi kernel: [C282BCB0] [C00E1750] .aio_kick_handler+0x128/0x278 | Jan 28 15:11:15 waldi kernel: [C282BD60] [C0066380] .run_workqueue+0xec/0x1d4 | Jan 28 15:11:15 waldi kernel: [C282BE00] [C0066F2C] .worker_thread+0x164/0x1bc | Jan 28 15:11:15 waldi kernel: [C282BEE0] [C006B6E8] .kthread+0x120/0x170 | Jan 28 15:11:15 waldi kernel: [C282BF90] [C0024204] .kernel_thread+0x4c/0x68 One possibility: aio_kick_handler calls use_mm. use_mm calls switch_mm. It seems that 90aef12e6dd609e1ad7fb70044eedc78ca55ee5e changed that from activate_mm. activate_mm on powerpc disables interupts and calls swtich_mm. So switch_mm is now called with interrupts enabled and runs into the WARN_ON. Bastian -- She won' go Warp 7, Cap'n! The batteries are dead! - 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/
[PATCH] kbuild: Don't ignore localversion files if the path includes a ~
Hi Kai, Sam The following patch fixes the problem that localversion files where ignored if the tree lives in a path which contains a ~. It changes the test to apply to the filename only. Debian allows versions which contains ~ in it. The upstream part of the version is in the directory name of the build tree and we got weird results because the localversion files was just got ignored in this case. --- a/Makefile +++ b/Makefile @@ -807,7 +807,7 @@ space := $(nullstring) # end of line ___localver = $(objtree)/localversion* $(srctree)/localversion* __localver = $(sort $(wildcard $(___localver))) # skip backup files (containing '~') -_localver = $(foreach f, $(__localver), $(if $(findstring ~, $(f)),,$(f))) +_localver = $(foreach f, $(__localver), $(if $(findstring ~, $(notdir $(f))),,$(f))) localver = $(subst $(space),, \ $(shell cat /dev/null $(_localver)) \ -- Totally illogical, there was no chance. -- Spock, "The Galileo Seven", stardate 2822.3 signature.asc Description: Digital signature
[PATCH] kbuild: Don't ignore localversion files if the path includes a ~
Hi Kai, Sam The following patch fixes the problem that localversion files where ignored if the tree lives in a path which contains a ~. It changes the test to apply to the filename only. Debian allows versions which contains ~ in it. The upstream part of the version is in the directory name of the build tree and we got weird results because the localversion files was just got ignored in this case. --- a/Makefile +++ b/Makefile @@ -807,7 +807,7 @@ space := $(nullstring) # end of line ___localver = $(objtree)/localversion* $(srctree)/localversion* __localver = $(sort $(wildcard $(___localver))) # skip backup files (containing '~') -_localver = $(foreach f, $(__localver), $(if $(findstring ~, $(f)),,$(f))) +_localver = $(foreach f, $(__localver), $(if $(findstring ~, $(notdir $(f))),,$(f))) localver = $(subst $(space),, \ $(shell cat /dev/null $(_localver)) \ -- Totally illogical, there was no chance. -- Spock, The Galileo Seven, stardate 2822.3 signature.asc Description: Digital signature
[PATCH] s390 - fix posix types
Hi folks The attached patch remove the usage of __ptr_t from include/asm-s390/posix_types.h. Bastian -- Landru! Guide us! -- A Beta 3-oid, "The Return of the Archons", stardate 3157.4 diff --git a/include/asm-s390/posix_types.h b/include/asm-s390/posix_types.h index b94c988..878057b 100644 --- a/include/asm-s390/posix_types.h +++ b/include/asm-s390/posix_types.h @@ -104,7 +104,7 @@ static inline int __FD_ISSET(unsigned long fd, const __kernel_fd_set *fdsetp) #undef __FD_ZERO #define __FD_ZERO(fdsetp) \ - ((void) memset ((__ptr_t) (fdsetp), 0, sizeof (__kernel_fd_set))) + ((void) memset ((fdsetp), 0, sizeof (__kernel_fd_set))) #endif /* __KERNEL__ */
[PATCH] s390 - fix posix types
Hi folks The attached patch remove the usage of __ptr_t from include/asm-s390/posix_types.h. Bastian -- Landru! Guide us! -- A Beta 3-oid, The Return of the Archons, stardate 3157.4 diff --git a/include/asm-s390/posix_types.h b/include/asm-s390/posix_types.h index b94c988..878057b 100644 --- a/include/asm-s390/posix_types.h +++ b/include/asm-s390/posix_types.h @@ -104,7 +104,7 @@ static inline int __FD_ISSET(unsigned long fd, const __kernel_fd_set *fdsetp) #undef __FD_ZERO #define __FD_ZERO(fdsetp) \ - ((void) memset ((__ptr_t) (fdsetp), 0, sizeof (__kernel_fd_set))) + ((void) memset ((fdsetp), 0, sizeof (__kernel_fd_set))) #endif /* __KERNEL__ */
[RFC] device types for s390 network devices
The s390 network devices specifies device types which does not match the reality. ctc === This device is currently specified as ARPHRD_SLIP. If I see it correctly, SLIP is an IP-only transport. ctc is more, the link level header contains the ethernet protocoll type, so it is some sort of pointopoint ethernet (which is sometimes crippled to IPv4-only for compatiblity reasons). qeth This device is currently specified as the corresponding real device type if it is a real adapter, or ARPHRD_ETHER if it is a virtual one. The virtual device behaves different in different modi: - "layer2": In this mode, the device behaves like a real layer 2 device. - "fake_ll": The kernel prepends a faked link level header. - default: The kernel processes the IP-packages. This is the most used mode, in whom it is impossible to use a standard libpcap as it parses the IP-headers as Ethernet. (IBM suggests to patch libpcap, but I think that changing the device type to something more matching is the correct solution.) At least the last part needs some fix, but I don't know how to fix if properly. Bastian -- The more complex the mind, the greater the need for the simplicity of play. -- Kirk, "Shore Leave", stardate 3025.8 signature.asc Description: Digital signature
[RFC] device types for s390 network devices
The s390 network devices specifies device types which does not match the reality. ctc === This device is currently specified as ARPHRD_SLIP. If I see it correctly, SLIP is an IP-only transport. ctc is more, the link level header contains the ethernet protocoll type, so it is some sort of pointopoint ethernet (which is sometimes crippled to IPv4-only for compatiblity reasons). qeth This device is currently specified as the corresponding real device type if it is a real adapter, or ARPHRD_ETHER if it is a virtual one. The virtual device behaves different in different modi: - layer2: In this mode, the device behaves like a real layer 2 device. - fake_ll: The kernel prepends a faked link level header. - default: The kernel processes the IP-packages. This is the most used mode, in whom it is impossible to use a standard libpcap as it parses the IP-headers as Ethernet. (IBM suggests to patch libpcap, but I think that changing the device type to something more matching is the correct solution.) At least the last part needs some fix, but I don't know how to fix if properly. Bastian -- The more complex the mind, the greater the need for the simplicity of play. -- Kirk, Shore Leave, stardate 3025.8 signature.asc Description: Digital signature
