Re: [PATCH 0/8] add generic builtin command line
On Thu, Sep 27, 2018 at 07:55:08PM +0300, Maksym Kokhan wrote: > Daniel Walker (7): > add generic builtin command line > drivers: of: ifdef out cmdline section > x86: convert to generic builtin command line > arm: convert to generic builtin command line > arm64: convert to generic builtin command line > mips: convert to generic builtin command line > powerpc: convert to generic builtin command line > When I originally submitted these I had a very good conversion with Rob Herring on the device tree changes. It seemed fairly clear that my approach in these changes could be done better. It effected specifically arm64, but a lot of other platforms use the device tree integrally. With arm64 you can reduce the changes down to only Kconfig changes, and that would likely be the case for many of the other architecture. I made patches to do this a while back, but have not had time to test them and push them out. In terms of mips I think there's a fair amount of work needed to pull out their architecture specific mangling into something generic. Part of my motivation for these was to take the architecture specific feature and open that up for all the architecture. So it makes sense that the mips changes should become part of that. The only changes which have no comments are the generic changes, x86, and powerpc. Those patches have been used at Cisco for years with no issues. I added those changes into my -next tree for a round of testing. Assuming there are no issues I can work out the merging with the architecture maintainers. As for the other changes I think they can be done in time, as long as the generic parts of upstream the rest can be worked on by any of the architecture developers. Daniel
Re: simple_alloc space tramples initrd
On Tue, Jan 12, 2016 at 09:17:53AM +1100, Michael Ellerman wrote: > On Mon, 2016-01-11 at 08:49 -0800, dwal...@fifo99.com wrote: > > On Mon, Jan 11, 2016 at 02:09:34PM +1100, Michael Ellerman wrote: > > > On Fri, 2016-01-08 at 09:45 -0800, dwal...@fifo99.com wrote: > > > > Hi, > > > > > > > > A powerpc machine I'm working on has this problem where the > > > > simple_alloc_init() area is trampling the initrd. The two are placed > > > > fairly > > > > close together. > > > > > > Which machine / platform? > > > > It's not upstream yet. I'm still putting the patches together, that's when > > this > > issue came up. I can send an RFC if you want to look at the patches. > > OK. Thanks but I don't need more patches to look at :) > > I was just trying to narrow down which code you were talking about. It's coming eventually anyways ;) .. > > > I don't really know that code very well. But ideally either the boot > > > loader > > > gives you space, or the platform boot code is smart enough to detect that > > > there > > > is insufficient room and puts the heap somewhere else. > > > > It seems like the kernel should be able to handle it. I believe the > > bootloader passes > > the initrd location , but I don't think it's evaluated till later in the > > boot up. For > > simple_alloc_init() it seems all platforms just assume the space is empty > > without checking. > > Yeah that's what I see too, which seems like it's liable to break, but > obviously hasn't for anyone else yet. > > The bootloader must pass the initrd location, otherwise the kernel can't use > it, so it seems like the kernel should be able to notice when they are too > close. But it may be complicated by the sequencing of the code. I found a similar one, arch/powerpc/boot/ps3.c:platform_init() I realized that in platform_init() your discovering the initrd location, so you do have access to the values. In ps3 you can see how if the initrd is placed in the 16megs after the kernel image then the simple_alloc code could corrupt it. I think it would be appropriate to check the initrd location in that function (since it's available) and make a choice to put the simple_alloc area after the initrd if the areas overlap. Does that make sense ? Daniel ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: simple_alloc space tramples initrd
On Mon, Jan 11, 2016 at 02:09:34PM +1100, Michael Ellerman wrote: > On Fri, 2016-01-08 at 09:45 -0800, dwal...@fifo99.com wrote: > > Hi, > > > > A powerpc machine I'm working on has this problem where the > > simple_alloc_init() area is trampling the initrd. The two are placed fairly > > close together. > > Which machine / platform? It's not upstream yet. I'm still putting the patches together, that's when this issue came up. I can send an RFC if you want to look at the patches. > > I have a fix for this proposed to add a section into > > arch/powerpc/boot/zImage.lds.S called "mallocarea" to account for this > > space, > > but not all powerpc platforms use simple_alloc_init(). So for those > > platforms > > it's a waste. > > Yeah I don't really like the sound of that. We could do it if it was behind a > CONFIG option, but hopefully there is a better solution. > > > Another alternative is to alter the bootloader to place more space between > > the kernel image and initrd image. > > > > I wanted to get some feedback on the right way to fix this. It seems like it > > could be a generic issue on powerpc, or it's possibly already fixed > > someplace > > and I just haven't noticed. > > I don't really know that code very well. But ideally either the boot loader > gives you space, or the platform boot code is smart enough to detect that > there > is insufficient room and puts the heap somewhere else. It seems like the kernel should be able to handle it. I believe the bootloader passes the initrd location , but I don't think it's evaluated till later in the boot up. For simple_alloc_init() it seems all platforms just assume the space is empty without checking. Daniel ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
simple_alloc space tramples initrd
Hi, A powerpc machine I'm working on has this problem where the simple_alloc_init() area is trampling the initrd. The two are placed fairly close together. I have a fix for this proposed to add a section into arch/powerpc/boot/zImage.lds.S called "mallocarea" to account for this space, but not all powerpc platforms use simple_alloc_init(). So for those platforms it's a waste. Another alternative is to alter the bootloader to place more space between the kernel image and initrd image. I wanted to get some feedback on the right way to fix this. It seems like it could be a generic issue on powerpc, or it's possibly already fixed someplace and I just haven't noticed. Any feedback appreciated. Daniel ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/3] panic: Disable crash_kexec_post_notifiers if kdump is not available
On Mon, Jul 13, 2015 at 08:19:45PM -0500, Eric W. Biederman wrote: dwal...@fifo99.com writes: On Fri, Jul 10, 2015 at 08:41:28AM -0500, Eric W. Biederman wrote: Hidehiro Kawai hidehiro.kawai...@hitachi.com writes: You can call panic notifiers and kmsg dumpers before kdump by specifying crash_kexec_post_notifiers as a boot parameter. However, it doesn't make sense if kdump is not available. In that case, disable crash_kexec_post_notifiers boot parameter so that you can't change the value of the parameter. Nacked-by: Eric W. Biederman ebied...@xmission.com I think it would make sense if he just replaced kdump with kexec. It would be less insane, however it still makes no sense as without kexec on panic support crash_kexec is a noop. So the value of the seeting makes no difference. Can you explain more, I don't really understand what you mean. Are you suggesting the whole crash_kexec_post_notifiers feature has no value ? Daniel ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/3] panic: Disable crash_kexec_post_notifiers if kdump is not available
On Tue, Jul 14, 2015 at 11:02:08AM -0400, Vivek Goyal wrote: On Tue, Jul 14, 2015 at 01:59:19PM +, dwal...@fifo99.com wrote: On Mon, Jul 13, 2015 at 08:19:45PM -0500, Eric W. Biederman wrote: dwal...@fifo99.com writes: On Fri, Jul 10, 2015 at 08:41:28AM -0500, Eric W. Biederman wrote: Hidehiro Kawai hidehiro.kawai...@hitachi.com writes: You can call panic notifiers and kmsg dumpers before kdump by specifying crash_kexec_post_notifiers as a boot parameter. However, it doesn't make sense if kdump is not available. In that case, disable crash_kexec_post_notifiers boot parameter so that you can't change the value of the parameter. Nacked-by: Eric W. Biederman ebied...@xmission.com I think it would make sense if he just replaced kdump with kexec. It would be less insane, however it still makes no sense as without kexec on panic support crash_kexec is a noop. So the value of the seeting makes no difference. Can you explain more, I don't really understand what you mean. Are you suggesting the whole crash_kexec_post_notifiers feature has no value ? Daniel, BTW, why are you using crash_kexec_post_notifiers commandline? Why not without it? It was explained in the prior thread but to rehash, the notifiers are used to do a switch over from the crashed machine to another redundant machine. Daniel ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/3] panic: Disable crash_kexec_post_notifiers if kdump is not available
On Tue, Jul 14, 2015 at 11:40:40AM -0400, Vivek Goyal wrote: On Tue, Jul 14, 2015 at 03:34:30PM +, dwal...@fifo99.com wrote: On Tue, Jul 14, 2015 at 11:02:08AM -0400, Vivek Goyal wrote: On Tue, Jul 14, 2015 at 01:59:19PM +, dwal...@fifo99.com wrote: On Mon, Jul 13, 2015 at 08:19:45PM -0500, Eric W. Biederman wrote: dwal...@fifo99.com writes: On Fri, Jul 10, 2015 at 08:41:28AM -0500, Eric W. Biederman wrote: Hidehiro Kawai hidehiro.kawai...@hitachi.com writes: You can call panic notifiers and kmsg dumpers before kdump by specifying crash_kexec_post_notifiers as a boot parameter. However, it doesn't make sense if kdump is not available. In that case, disable crash_kexec_post_notifiers boot parameter so that you can't change the value of the parameter. Nacked-by: Eric W. Biederman ebied...@xmission.com I think it would make sense if he just replaced kdump with kexec. It would be less insane, however it still makes no sense as without kexec on panic support crash_kexec is a noop. So the value of the seeting makes no difference. Can you explain more, I don't really understand what you mean. Are you suggesting the whole crash_kexec_post_notifiers feature has no value ? Daniel, BTW, why are you using crash_kexec_post_notifiers commandline? Why not without it? It was explained in the prior thread but to rehash, the notifiers are used to do a switch over from the crashed machine to another redundant machine. So why not detect failure using polling or issue notifications from second kernel. IOW, expecting that a crashed machine will be able to deliver notification reliably is falwed to begin with, IMHO. It's flawed to think you can kexec, but you still do it right ? I've not gotten into the deep details of this switching process, but that's how this interface is used. If a machine is failing, there are high chance it can't deliver you the notification. Detecting that failure suing some kind of polling mechanism might be more reliable. And it will make even kdump mechanism more reliable so that it does not have to run panic notifiers after the crash. I think what your suggesting is that my company should change how it's hardware works and that's not really an option for me. This isn't a simple thing like checking over the network if the machine is down or not, this is way more complex hardware design. Daniel ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/3] panic: Disable crash_kexec_post_notifiers if kdump is not available
On Tue, Jul 14, 2015 at 12:06:15PM -0500, Eric W. Biederman wrote: Vivek Goyal vgo...@redhat.com writes: On Tue, Jul 14, 2015 at 03:48:33PM +, dwal...@fifo99.com wrote: On Tue, Jul 14, 2015 at 11:40:40AM -0400, Vivek Goyal wrote: On Tue, Jul 14, 2015 at 03:34:30PM +, dwal...@fifo99.com wrote: On Tue, Jul 14, 2015 at 11:02:08AM -0400, Vivek Goyal wrote: On Tue, Jul 14, 2015 at 01:59:19PM +, dwal...@fifo99.com wrote: On Mon, Jul 13, 2015 at 08:19:45PM -0500, Eric W. Biederman wrote: dwal...@fifo99.com writes: On Fri, Jul 10, 2015 at 08:41:28AM -0500, Eric W. Biederman wrote: Hidehiro Kawai hidehiro.kawai...@hitachi.com writes: You can call panic notifiers and kmsg dumpers before kdump by specifying crash_kexec_post_notifiers as a boot parameter. However, it doesn't make sense if kdump is not available. In that case, disable crash_kexec_post_notifiers boot parameter so that you can't change the value of the parameter. Nacked-by: Eric W. Biederman ebied...@xmission.com I think it would make sense if he just replaced kdump with kexec. It would be less insane, however it still makes no sense as without kexec on panic support crash_kexec is a noop. So the value of the seeting makes no difference. Can you explain more, I don't really understand what you mean. Are you suggesting the whole crash_kexec_post_notifiers feature has no value ? Daniel, BTW, why are you using crash_kexec_post_notifiers commandline? Why not without it? It was explained in the prior thread but to rehash, the notifiers are used to do a switch over from the crashed machine to another redundant machine. So why not detect failure using polling or issue notifications from second kernel. IOW, expecting that a crashed machine will be able to deliver notification reliably is falwed to begin with, IMHO. It's flawed to think you can kexec, but you still do it right ? I've not gotten into the deep details of this switching process, but that's how this interface is used. Sure. But the deal here is that users of interface know that sometimes it can be unreliable. And in the absence of more reliable mechanism, somewhat less reliable mechanism is fine. If a machine is failing, there are high chance it can't deliver you the notification. Detecting that failure suing some kind of polling mechanism might be more reliable. And it will make even kdump mechanism more reliable so that it does not have to run panic notifiers after the crash. I think what your suggesting is that my company should change how it's hardware works and that's not really an option for me. This isn't a simple thing like checking over the network if the machine is down or not, this is way more complex hardware design. That means you are ready to live with an unreliable design. There might be cases where notifier does not get run properly and you will not do switch despite the fact that OS has failed. I was just trying to nudge you in a direction which could be more reliable mechanism. Sigh I see some deep confusion going on here. The panic notifiers are just that panic notifiers. They have not been nor should they be tied to kexec. If those notifiers force a switch over of between machines I fail to see why you would care if it was kexec or another panic situation that is forcing that switchover. Hidehiro isn't fixing the failover situation on my side, he's fixing register information collection when crash_kexec_post_notifiers is used. Daniel ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/3] panic: Disable crash_kexec_post_notifiers if kdump is not available
On Fri, Jul 10, 2015 at 08:41:28AM -0500, Eric W. Biederman wrote: Hidehiro Kawai hidehiro.kawai...@hitachi.com writes: You can call panic notifiers and kmsg dumpers before kdump by specifying crash_kexec_post_notifiers as a boot parameter. However, it doesn't make sense if kdump is not available. In that case, disable crash_kexec_post_notifiers boot parameter so that you can't change the value of the parameter. Nacked-by: Eric W. Biederman ebied...@xmission.com I think it would make sense if he just replaced kdump with kexec. Daniel ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
