Re: [PATCH 1/2] kdump: Allow shrinking of kdump region to be overridden
On Tue, Mar 15, 2011 at 2:13 AM, Mahesh J Salgaonkar wrote: > > During free we do free all of them including RMO region. But since the rtas > region is always on top of RMO, crashkernel memory overlaps rtas region and > we endup freeing that even, which is causing the crash. > Okay, but with this patch applied, we will just ignore rtas region, right? Thus, when I echo 0 to free all the 128M crashkernel memory, the final result will be 32M left, which means crash_size will still show 32M. This looks odd. How about skipping the 32M as a whole? I mean once the region being freed has overlap with this rtas region, skip the whole rtas region, and let crash_size show 0? Thanks. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/2] kdump: Allow shrinking of kdump region to be overridden
On Wed, Mar 09, 2011 at 11:46:57PM +1100, Anton Blanchard wrote: > >Hi, > >> The crashkernel region is specified via kernel cmdline, so why >> not just drop a failure when it overlaps with RMO region? >> Am I missing something? > >Unfortunately a ppc64 kernel requires a chunk of RMO memory. We would >need the ability to specify multiple crashkernel regions - about 32MB >in the RMO and the rest can be anywhere. That sounds pretty fragile for >a user to configure successfully on the cmdline. > >Thats why the ppc64 crashkernel region begins mid way through the RMO >region. It means both kernels get a chunk of RMO and we only have to >deal with one crashkernel reservation in all the tools and >documentation. > So, when I specify 128M in cmdline, 32M of them are RMO, and the rest 96M are normal memory? And when I want to free all of them, actually the 32M RMO will never be freed? ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/2] kdump: Allow shrinking of kdump region to be overridden
On Wed, Mar 09, 2011 at 12:02:06PM +0530, Mahesh Jagannath Salgaonkar wrote: >On 08/25/2010 06:07 AM, Eric W. Biederman wrote: >> Anton Blanchard writes: >> >>> On ppc64 the crashkernel region almost always overlaps an area of firmware. >>> This works fine except when using the sysfs interface to reduce the kdump >>> region. If we free the firmware area we are guaranteed to crash. >> >> That is ppc64 bug. firmware should not be in the reserved region. Any >> random kernel like thing can be put in to that region at any valid >> address and the fact that shrinking the region frees your firmware means >> that using that region could also stomp your firmware (which I assume >> would be a bad thing). >The issue only happens while shrinking the region using sysfs interface. >We already have checks in kexec for not to stomp over on the firmware >overlap area while loading capture kernel. Currently we do a top-down >allocation for the firmware region which means it sits at the top of the >RMO, right in the middle of the crashdump region. We can not move the >crashkernel region beyond firmware region because kernel needs its some >of memory in RMO region. The crashkernel region is specified via kernel cmdline, so why not just drop a failure when it overlaps with RMO region? Am I missing something? Thanks. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc: Add vmcoreinfo symbols to allow makdumpfile to filter core files properly
On Mon, Jul 26, 2010 at 11:23 PM, Neil Horman wrote: > On Tue, Jul 13, 2010 at 09:46:09AM -0400, Neil Horman wrote: >> Hey all- >> About 2 years ago now, I sent this patch upstream to allow makedumpfile >> to properly filter cores on ppc64: >> http://www.mail-archive.com/ke...@lists.infradead.org/msg02426.html >> It got acks from the kexec folks so I pulled it into RHEL, but I never >> checked >> back here to make sure it ever made it in, which apparently it didn't. It >> still >> needs to be included, so I'm reposting it here, making sure to copy all the >> ppc >> folks this time. I've retested it on the latest linus kernel and it works >> fine, >> allowing makedumpfile to find all the symbols it needs to properly strip a >> vmcore on ppc64. >> >> Neil >> >> Signed-off-by: Neil Horman >> > Ping, anyone want to chime in on this, its needed for dump filtering to work > properly on ppc64 This patch looks good for me. Reviewed-by: WANG Cong Thanks! ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] Restrict stack space reservation to rlimit
On Mon, Feb 8, 2010 at 2:05 PM, KOSAKI Motohiro wrote: >> --- linux-2.6-ozlabs.orig/fs/exec.c >> +++ linux-2.6-ozlabs/fs/exec.c >> @@ -627,10 +627,13 @@ int setup_arg_pages(struct linux_binprm >> goto out_unlock; >> } >> >> + stack_base = min(EXTRA_STACK_VM_PAGES * PAGE_SIZE, >> + current->signal->rlim[RLIMIT_STACK].rlim_cur - >> + PAGE_SIZE); > > This line is a bit unclear why "- PAGE_SIZE" is necessary. > personally, I like following likes explicit comments. > > stack_expand = EXTRA_STACK_VM_PAGES * PAGE_SIZE; > stack_lim = ACCESS_ONCE(rlim[RLIMIT_STACK].rlim_cur); > > /* Initial stack must not cause stack overflow. */ > if (stack_expand + PAGE_SIZE > stack_lim) > stack_expand = stack_lim - PAGE_SIZE; > > note: accessing rlim_cur require ACCESS_ONCE. > > > Thought? It's better to use the helper function: rlimit(). ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: 2.6.32 Kernel panic - not syncing: Attempted to kill init! Rebooting in 180 seconds..
On Fri, Dec 18, 2009 at 3:38 PM, Zhiyong Wu wrote > On Fri, Dec 18, 2009 at 3:12 PM, Américo Wang > wrote: >> On Fri, Dec 18, 2009 at 12:08 PM, Zhiyong Wu wrote: >>> HI, >>> >>> linux-2.6.32 is compiled on a p6 machine with RH5.4 OS and KVM option is >>> enable. >>> >>> When rebooting this machine, a crash takes place such as: >>> >>> command line: ro console=hvc0 rhgb quiet root=LABEL=/ >>> memory layout at init: >>> memory_limit : (16 MB aligned) >>> alloc_bottom : 019b >>> alloc_top : 0800 >>> alloc_top_hi : 0800 >>> rmo_top : 0800 >>> ram_top : 0800 >>> instantiating rtas at 0x06e1... done >>> boot cpu hw idx >>> copying OF device tree... >>> Building dt strings... >>> Building dt structure... >>> Device tree strings 0x01bc -> 0x01bc15bb >>> Device tree struct 0x01bd -> 0x01bf >>> Calling quiesce... >>> returning from prom_init >>> Red Hat nash version 5.1.19.6 starting >>> ibmvscsi 3002: fast_fail not supported in server >>> sd 0:0:1:0: [sda] Assuming drive cache: write through >>> sd 0:0:1:0: [sda] Assuming drive cache: write through >>> sd 0:0:1:0: [sda] Assuming drive cache: write through >>> insmod: error inserting '/lib/dm-region-hash.ko': -1 File exists >>> mount: could not find filesystem '/dev/root' >>> setuproot: moving /dev failed: No such file or directory >>> setuproot: error mounting /proc: No such file or directory >>> setuproot: error mounting /sys: No such file or directory >>> switchroot: mount failed: No such file or directory >>> Kernel panic - not syncing: Attempted to kill init! >>> Rebooting in 180 seconds..[disconnect] >>> >>> Can anyone give me a warm hand? >> >> Probably this is not a problem of kernel, maybe it's >> a problem of your initial ramdisk, or something wrong with >> your root filesystem. >> >> Does changing "root=LABEL=/" to "root=/dev/XXX" help? >> Where "/dev/XXX" is your root filesystem. >> > > It does'nt still work based on your method. Hmm, so I would guess it's a problem in your initial ramdisk. So you can boot RH5 native kernel with the same boot options but only this one not?? Or maybe the udev your are using doesn't work with 2.6.32? Only another guess... But anyway, checking your 'mkinitrd' would help. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: 2.6.32 Kernel panic - not syncing: Attempted to kill init! Rebooting in 180 seconds..
On Fri, Dec 18, 2009 at 12:08 PM, Zhiyong Wu wrote: > HI, > > linux-2.6.32 is compiled on a p6 machine with RH5.4 OS and KVM option is > enable. > > When rebooting this machine, a crash takes place such as: > > Loading ramdisk... > ramdisk loaded at 0170, size: 2700 Kbytes > OF stdout device is: /vdevice/v...@3000 > Preparing to boot Linux version 2.6.32 (r...@p6ml4n07.clusters.com) > (gcc version 4.1.2 20080704 (Red Hat 4.1.2-46)) #1 SMP Fri Dec 18 > 06:53:27 EST 2009 > Calling ibm,client-architecture-support.../ > Elapsed time since release of system processors: 1212 mins 30 secs > > Config file read, 1024 bytes > > Welcome > Welcome to yaboot version 1.3.13 (Red Hat 1.3.13-8.el5) > Enter "help" to get some basic usage information > boot: linux-32 > Please wait, loading kernel... > Elf64 kernel loaded... > Loading ramdisk... > ramdisk loaded at 0170, size: 2700 Kbytes > OF stdout device is: /vdevice/v...@3000 > Preparing to boot Linux version 2.6.32 (r...@p6ml4n07.clusters.com) > (gcc version 4.1.2 20080704 (Red Hat 4.1.2-46)) #1 SMP Fri Dec 18 > 06:53:27 EST 2009 > Calling ibm,client-architecture-support... done > command line: ro console=hvc0 rhgb quiet root=LABEL=/ > memory layout at init: > memory_limit : (16 MB aligned) > alloc_bottom : 019b > alloc_top : 0800 > alloc_top_hi : 0800 > rmo_top : 0800 > ram_top : 0800 > instantiating rtas at 0x06e1... done > boot cpu hw idx > copying OF device tree... > Building dt strings... > Building dt structure... > Device tree strings 0x01bc -> 0x01bc15bb > Device tree struct 0x01bd -> 0x01bf > Calling quiesce... > returning from prom_init > Red Hat nash version 5.1.19.6 starting > ibmvscsi 3002: fast_fail not supported in server > sd 0:0:1:0: [sda] Assuming drive cache: write through > sd 0:0:1:0: [sda] Assuming drive cache: write through > sd 0:0:1:0: [sda] Assuming drive cache: write through > insmod: error inserting '/lib/dm-region-hash.ko': -1 File exists > mount: could not find filesystem '/dev/root' > setuproot: moving /dev failed: No such file or directory > setuproot: error mounting /proc: No such file or directory > setuproot: error mounting /sys: No such file or directory > switchroot: mount failed: No such file or directory > Kernel panic - not syncing: Attempted to kill init! > Rebooting in 180 seconds..[disconnect] > > Can anyone give me a warm hand? Probably this is not a problem of kernel, maybe it's a problem of your initial ramdisk, or something wrong with your root filesystem. Does changing "root=LABEL=/" to "root=/dev/XXX" help? Where "/dev/XXX" is your root filesystem. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] BUILD_BUG_ON: make it handle more cases
On Tue, Oct 20, 2009 at 10:43 PM, Alan Jenkins
wrote:
> On 10/20/09, Américo Wang wrote:
>> On Tue, Oct 20, 2009 at 02:15:33PM +1030, Rusty Russell wrote:
>>>BUILD_BUG_ON used to use the optimizer to do code elimination or fail
>>>at link time; it was changed to first the size of a negative array (a
>>>nicer compile time error), then (in
>>>8c87df457cb58fe75b9b893007917cf8095660a0) to a bitfield.
>>>
>>>bitfields: needs a literal constant at parse time, and can't be put under
>>> "if (__builtin_constant_p(x))" for example.
>>>negative array: can handle anything, but if the compiler can't tell it's
>>> a constant, silently has no effect.
>>>link time: breaks link if the compiler can't determine the value, but the
>>> linker output is not usually as informative as a compiler error.
>>>
>>>If we use the negative-array-size method *and* the link time trick,
>>>we get the ability to use BUILD_BUG_ON() under __builtin_constant_p()
>>>branches, and maximal ability for the compiler to detect errors at
>>>build time.
>>>
>>>Signed-off-by: Rusty Russell
>>>
>>>diff --git a/include/linux/kernel.h b/include/linux/kernel.h
>>>--- a/include/linux/kernel.h
>>>+++ b/include/linux/kernel.h
>>>@@ -683,12 +683,6 @@ struct sysinfo {
>>> char _f[20-2*sizeof(long)-sizeof(int)]; /* Padding: libc5 uses this..
>>> */
>>> };
>>>
>>>-/* Force a compilation error if condition is true */
>>>-#define BUILD_BUG_ON(condition) ((void)BUILD_BUG_ON_ZERO(condition))
>>>-
>>>-/* Force a compilation error if condition is constant and true */
>>>-#define MAYBE_BUILD_BUG_ON(cond) ((void)sizeof(char[1 - 2 * !!(cond)]))
>>>-
>>> /* Force a compilation error if condition is true, but also produce a
>>> result (of value 0 and type size_t), so the expression can be used
>>> e.g. in a structure initializer (or where-ever else comma expressions
>>>@@ -696,6 +690,33 @@ struct sysinfo {
>>> #define BUILD_BUG_ON_ZERO(e) (sizeof(struct { int:-!!(e); }))
>>> #define BUILD_BUG_ON_NULL(e) ((void *)sizeof(struct { int:-!!(e); }))
>>>
>>>+/**
>>>+ * BUILD_BUG_ON - break compile if a condition is true.
>>>+ * @cond: the condition which the compiler should know is false.
>>>+ *
>>>+ * If you have some code which relies on certain constants being equal, or
>>>+ * other compile-time-evaluated condition, you should use BUILD_BUG_ON to
>>>+ * detect if someone changes it.
>>>+ *
>>>+ * The implementation uses gcc's reluctance to create a negative array,
>>> but
>>>+ * gcc (as of 4.4) only emits that error for obvious cases (eg. not
>>> arguments
>>>+ * to inline functions). So as a fallback we use the optimizer; if it
>>> can't
>>>+ * prove the condition is false, it will cause a link error on the
>>> undefined
>>>+ * "__build_bug_on_failed". This error message can be harder to track
>>> down
>>>+ * though, hence the two different methods.
>>>+ */
>>>+#ifndef __OPTIMIZE__
>>>+#define BUILD_BUG_ON(condition) ((void)sizeof(char[1 - 2*!!(condition)]))
>>>+#else
>>>+extern int __build_bug_on_failed;
>>
>> Hmm, what exactly is __build_bug_on_failed?
>
> Well, we haven't added a definition for it in this patch. I'm sure
> grep will tell you it wasn't defined before hand either. So any
> reference to it is an error - which will be reported at link time.
>
>>>+#define BUILD_BUG_ON(condition) \
>>>+ do { \
>>>+ ((void)sizeof(char[1 - 2*!!(condition)])); \
>>>+ if (condition) __build_bug_on_failed = 1; \
>
> If "condition" is known false at compile time, gcc -O will eliminate
> the code which refers to __build_bug_on_failed. If it's not proved to
> be false - it will break the build, which is exactly what we want
> BUILD_BUG_ON to do.
Ah, clever trick! Got it.
Thanks!
Reviewed-by: WANG Cong
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] BUILD_BUG_ON: make it handle more cases
On Tue, Oct 20, 2009 at 02:15:33PM +1030, Rusty Russell wrote:
>BUILD_BUG_ON used to use the optimizer to do code elimination or fail
>at link time; it was changed to first the size of a negative array (a
>nicer compile time error), then (in
>8c87df457cb58fe75b9b893007917cf8095660a0) to a bitfield.
>
>bitfields: needs a literal constant at parse time, and can't be put under
> "if (__builtin_constant_p(x))" for example.
>negative array: can handle anything, but if the compiler can't tell it's
> a constant, silently has no effect.
>link time: breaks link if the compiler can't determine the value, but the
> linker output is not usually as informative as a compiler error.
>
>If we use the negative-array-size method *and* the link time trick,
>we get the ability to use BUILD_BUG_ON() under __builtin_constant_p()
>branches, and maximal ability for the compiler to detect errors at
>build time.
>
>Signed-off-by: Rusty Russell
>
>diff --git a/include/linux/kernel.h b/include/linux/kernel.h
>--- a/include/linux/kernel.h
>+++ b/include/linux/kernel.h
>@@ -683,12 +683,6 @@ struct sysinfo {
> char _f[20-2*sizeof(long)-sizeof(int)]; /* Padding: libc5 uses this.. */
> };
>
>-/* Force a compilation error if condition is true */
>-#define BUILD_BUG_ON(condition) ((void)BUILD_BUG_ON_ZERO(condition))
>-
>-/* Force a compilation error if condition is constant and true */
>-#define MAYBE_BUILD_BUG_ON(cond) ((void)sizeof(char[1 - 2 * !!(cond)]))
>-
> /* Force a compilation error if condition is true, but also produce a
>result (of value 0 and type size_t), so the expression can be used
>e.g. in a structure initializer (or where-ever else comma expressions
>@@ -696,6 +690,33 @@ struct sysinfo {
> #define BUILD_BUG_ON_ZERO(e) (sizeof(struct { int:-!!(e); }))
> #define BUILD_BUG_ON_NULL(e) ((void *)sizeof(struct { int:-!!(e); }))
>
>+/**
>+ * BUILD_BUG_ON - break compile if a condition is true.
>+ * @cond: the condition which the compiler should know is false.
>+ *
>+ * If you have some code which relies on certain constants being equal, or
>+ * other compile-time-evaluated condition, you should use BUILD_BUG_ON to
>+ * detect if someone changes it.
>+ *
>+ * The implementation uses gcc's reluctance to create a negative array, but
>+ * gcc (as of 4.4) only emits that error for obvious cases (eg. not arguments
>+ * to inline functions). So as a fallback we use the optimizer; if it can't
>+ * prove the condition is false, it will cause a link error on the undefined
>+ * "__build_bug_on_failed". This error message can be harder to track down
>+ * though, hence the two different methods.
>+ */
>+#ifndef __OPTIMIZE__
>+#define BUILD_BUG_ON(condition) ((void)sizeof(char[1 - 2*!!(condition)]))
>+#else
>+extern int __build_bug_on_failed;
Hmm, what exactly is __build_bug_on_failed?
>+#define BUILD_BUG_ON(condition) \
>+ do {\
>+ ((void)sizeof(char[1 - 2*!!(condition)])); \
>+ if (condition) __build_bug_on_failed = 1; \
>+ } while(0)
>+#endif
>+#define MAYBE_BUILD_BUG_ON(condition) BUILD_BUG_ON(condition)
>+
> /* Trap pasters of __FUNCTION__ at compile-time */
> #define __FUNCTION__ (__func__)
>
>--
>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/
--
Live like a child, think like the god.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
