Re: svn commit: r296428 - head/sys/boot/common
Are the CFI directives so that DTRACE works, or is there some other reason? It allows gdb to backtrace across exception frames. later, Peter. ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r296428 - head/sys/boot/common
On 07 Mar 2016, at 19:50, Warner Losh wrote: > >> On Mar 7, 2016, at 10:41 AM, Dimitry Andric wrote: >> >> On 07 Mar 2016, at 17:28, Warner Losh wrote: >> ... >>> Alternatively, is there a switch to clang 3.8 that says 'Don't generate the >>> new >>> relocation, use the old one instead" which would also be safe and allow a >>> less-bumpy transition? >> >> On amd64, we actually compile source files for the kernel with >> -fno-asynchronous-unwind-tables, which is the flag that ensures object >> files do not end up with a .eh_frame section, because the compiler will >> refrain from inserting CFI directives into the assembler. > > Excellent. > >> However, this only affects C source files, and we have a number of >> hand-written assembler sources in the tree, with CFI directives in them. >> These will always result in .eh_frame sections, unless there is another >> assembler-specific flag of suppressing that. > > what are the odds of fixing this? Since the vast majority of assembler code > is going to be in the base kernel. The AESNI stuff is the only exception > that I can think of… > > Are the CFI directives so that DTRACE works, or is there some other reason? You could comment out the directives, but these are really the standard way to do unwinding on amd64, without having to follow stack frames 'manually'. It would even be better to drop the -fno-asynchronous-unwind-tables option, and actually start making use of the unwind information in e.g. the kernel debugger, or even for producing crash backtraces. -Dimitry signature.asc Description: Message signed with OpenPGP using GPGMail
Re: svn commit: r296428 - head/sys/boot/common
> On Mar 7, 2016, at 10:41 AM, Dimitry Andric wrote: > > On 07 Mar 2016, at 17:28, Warner Losh wrote: > ... >> Alternatively, is there a switch to clang 3.8 that says 'Don't generate the >> new >> relocation, use the old one instead" which would also be safe and allow a >> less-bumpy transition? > > On amd64, we actually compile source files for the kernel with > -fno-asynchronous-unwind-tables, which is the flag that ensures object > files do not end up with a .eh_frame section, because the compiler will > refrain from inserting CFI directives into the assembler. Excellent. > However, this only affects C source files, and we have a number of > hand-written assembler sources in the tree, with CFI directives in them. > These will always result in .eh_frame sections, unless there is another > assembler-specific flag of suppressing that. what are the odds of fixing this? Since the vast majority of assembler code is going to be in the base kernel. The AESNI stuff is the only exception that I can think of… Are the CFI directives so that DTRACE works, or is there some other reason? Warner signature.asc Description: Message signed with OpenPGP using GPGMail
Re: svn commit: r296428 - head/sys/boot/common
On 07 Mar 2016, at 17:28, Warner Losh wrote: ... > Alternatively, is there a switch to clang 3.8 that says 'Don't generate the > new > relocation, use the old one instead" which would also be safe and allow a > less-bumpy transition? On amd64, we actually compile source files for the kernel with -fno-asynchronous-unwind-tables, which is the flag that ensures object files do not end up with a .eh_frame section, because the compiler will refrain from inserting CFI directives into the assembler. However, this only affects C source files, and we have a number of hand-written assembler sources in the tree, with CFI directives in them. These will always result in .eh_frame sections, unless there is another assembler-specific flag of suppressing that. -Dimitry signature.asc Description: Message signed with OpenPGP using GPGMail
Re: svn commit: r296428 - head/sys/boot/common
On Mon, Mar 07, 2016 at 10:04:59AM -0700, Warner Losh wrote: > On Mon, Mar 7, 2016 at 9:51 AM, Konstantin Belousov > wrote: > > > On Mon, Mar 07, 2016 at 09:28:13AM -0700, Warner Losh wrote: > > > On Mon, Mar 7, 2016 at 8:52 AM, Konstantin Belousov > > > > > wrote: > > > > > > > On Mon, Mar 07, 2016 at 08:39:47AM -0700, Ian Lepore wrote: > > > > > Is there no way to prevent the panic other than making the unwind > > data > > > > > be present? Why can't the kernel be fixed to cope with the missing > > > > > data in some gentler way during a transition period? Perhaps > > valid-but > > > > > -fake data could be generated if necessary? Being unable to get a > > > > > stack traceback through a loaded module would be a small price to pay > > > > > for trouble-free updgrades. > > > > > > > > It is practically impossible to recover from partially-loaded object > > file' > > > > module. The loader workaround currently only affects HEAD and since > > the > > > > MFC was done, 10.3 should be safe. We always required lastest stable > > > > for the jump to next major branch. > > > > > > > > What could be done is demoting the panics (there are several, besides > > > > the one which was triggered) to a message and refusing to load the > > > > affected module. OTOH, if the reaction would be a message and not > > panic, > > > > it definitely go ignored for quite some time. > > > > > > > > > > The new loader could also pass in some version or cookie in the metadata > > > that says it is the new one. The kernel could examine this and issue a > > > warning, > > > on amd64 / i386, that module linking may be incomplete and you'll need to > > > upgrade your /boot/loader if you encounter a crash. > > This is absolute useless kernel bloat. Kernel should provide an execution > > environment for user programs, and not lecture users about proper system > > configuration. > > > On the other hand, the kernel and the boot loader have a protocol they > both implement. When one side implements it wrong, the other side should > detect it if it is easy to do so. > > > > > Could the kernel detect that a .eh_frame module was loaded and ignore it > > > in "safe mode"? Perhaps combined with the new boot-loader cookie, this > > > would be an automatic way to not mysteriously crash. > > Why should kernel ignore loaded .eh_frame ? I do not see any use for > > other part of the suggestion at all. To clarify, kernel paniced because > > some (required but currently not utilized) part of the binary module was > > not loaded. > > > Not ignore eh_frame, just modules that have eh_frame and potentially bad > relocations. Or, you could pre-scan the relocations and only fail when the > module actually has them. But if you make the linker pancis into warnings > instead, then that would likely also be OK. > > > Alternatively, is there a switch to clang 3.8 that says 'Don't generate > > the > > > new > > > relocation, use the old one instead" which would also be safe and allow a > > > less-bumpy transition? > > > > > > Finally, would the partially loaded module stop at the first bad > > relocation, > > > or would it do them all and just skip the bad ones? Is the data from this > > > relocation > > > used all the time, or just when we're doing a stack unwind for an > > exception > > > or a backtrace? > > Practically, we could ignore that relocations and still load the module, > > but this is only because we know what the scope of the relocations is. > > For some arbitrary situation with the same detected missed place for > > relocations, loader cannot know is it safe or not. > > > > True. However, this is a well-known case. There is no way to distinguish well-known case against some other case. > > > > The problem is fixed and does not deserve nuking of all computers in > > the world, which was an equivalent of some other suggestions how to > > handle that. Most of the suggestions come to extreme which is not > > deserved. > > > > What could be useful, as I noted already, is to demote the panics from > > kernel linker to warnings. I intended to work on this. > > > That would fit the bill for what I'm interested in this stuff for. Normally, > we load the new kernel with new boot loader in my company's > upgrade process. There are times, however, when we'll wind up > loading the new kernel with the old boot loader (but more commonly > vice-versa). Having some indication of the error would be quite useful > in this scenario so we know we need to do something else. With the patch attached, and old pxeloader, I get Preloaded elf obj module "/boot/kernel/aesni.ko" at 0x80e20478. kldload: aesni.ko: lost base for reltab during boot, and then the only consequence is aesni.ko not loaded. The system booted multiuser. The error handling is not ideal, some stuff could leak with the patch. But the same is true for existing error return pathes as well, so I do not consider this a stopper. diff --git a/sys/kern/link_elf_obj.c b/sys/kern/lin
Re: svn commit: r296428 - head/sys/boot/common
On Mon, Mar 7, 2016 at 9:51 AM, Konstantin Belousov wrote: > On Mon, Mar 07, 2016 at 09:28:13AM -0700, Warner Losh wrote: > > On Mon, Mar 7, 2016 at 8:52 AM, Konstantin Belousov > > > wrote: > > > > > On Mon, Mar 07, 2016 at 08:39:47AM -0700, Ian Lepore wrote: > > > > Is there no way to prevent the panic other than making the unwind > data > > > > be present? Why can't the kernel be fixed to cope with the missing > > > > data in some gentler way during a transition period? Perhaps > valid-but > > > > -fake data could be generated if necessary? Being unable to get a > > > > stack traceback through a loaded module would be a small price to pay > > > > for trouble-free updgrades. > > > > > > It is practically impossible to recover from partially-loaded object > file' > > > module. The loader workaround currently only affects HEAD and since > the > > > MFC was done, 10.3 should be safe. We always required lastest stable > > > for the jump to next major branch. > > > > > > What could be done is demoting the panics (there are several, besides > > > the one which was triggered) to a message and refusing to load the > > > affected module. OTOH, if the reaction would be a message and not > panic, > > > it definitely go ignored for quite some time. > > > > > > > The new loader could also pass in some version or cookie in the metadata > > that says it is the new one. The kernel could examine this and issue a > > warning, > > on amd64 / i386, that module linking may be incomplete and you'll need to > > upgrade your /boot/loader if you encounter a crash. > This is absolute useless kernel bloat. Kernel should provide an execution > environment for user programs, and not lecture users about proper system > configuration. On the other hand, the kernel and the boot loader have a protocol they both implement. When one side implements it wrong, the other side should detect it if it is easy to do so. > > Could the kernel detect that a .eh_frame module was loaded and ignore it > > in "safe mode"? Perhaps combined with the new boot-loader cookie, this > > would be an automatic way to not mysteriously crash. > Why should kernel ignore loaded .eh_frame ? I do not see any use for > other part of the suggestion at all. To clarify, kernel paniced because > some (required but currently not utilized) part of the binary module was > not loaded. Not ignore eh_frame, just modules that have eh_frame and potentially bad relocations. Or, you could pre-scan the relocations and only fail when the module actually has them. But if you make the linker pancis into warnings instead, then that would likely also be OK. > Alternatively, is there a switch to clang 3.8 that says 'Don't generate > the > > new > > relocation, use the old one instead" which would also be safe and allow a > > less-bumpy transition? > > > > Finally, would the partially loaded module stop at the first bad > relocation, > > or would it do them all and just skip the bad ones? Is the data from this > > relocation > > used all the time, or just when we're doing a stack unwind for an > exception > > or a backtrace? > Practically, we could ignore that relocations and still load the module, > but this is only because we know what the scope of the relocations is. > For some arbitrary situation with the same detected missed place for > relocations, loader cannot know is it safe or not. > True. However, this is a well-known case. > The problem is fixed and does not deserve nuking of all computers in > the world, which was an equivalent of some other suggestions how to > handle that. Most of the suggestions come to extreme which is not > deserved. > > What could be useful, as I noted already, is to demote the panics from > kernel linker to warnings. I intended to work on this. That would fit the bill for what I'm interested in this stuff for. Normally, we load the new kernel with new boot loader in my company's upgrade process. There are times, however, when we'll wind up loading the new kernel with the old boot loader (but more commonly vice-versa). Having some indication of the error would be quite useful in this scenario so we know we need to do something else. Warner ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r296428 - head/sys/boot/common
On Mon, Mar 07, 2016 at 09:28:13AM -0700, Warner Losh wrote: > On Mon, Mar 7, 2016 at 8:52 AM, Konstantin Belousov > wrote: > > > On Mon, Mar 07, 2016 at 08:39:47AM -0700, Ian Lepore wrote: > > > Is there no way to prevent the panic other than making the unwind data > > > be present? Why can't the kernel be fixed to cope with the missing > > > data in some gentler way during a transition period? Perhaps valid-but > > > -fake data could be generated if necessary? Being unable to get a > > > stack traceback through a loaded module would be a small price to pay > > > for trouble-free updgrades. > > > > It is practically impossible to recover from partially-loaded object file' > > module. The loader workaround currently only affects HEAD and since the > > MFC was done, 10.3 should be safe. We always required lastest stable > > for the jump to next major branch. > > > > What could be done is demoting the panics (there are several, besides > > the one which was triggered) to a message and refusing to load the > > affected module. OTOH, if the reaction would be a message and not panic, > > it definitely go ignored for quite some time. > > > > The new loader could also pass in some version or cookie in the metadata > that says it is the new one. The kernel could examine this and issue a > warning, > on amd64 / i386, that module linking may be incomplete and you'll need to > upgrade your /boot/loader if you encounter a crash. This is absolute useless kernel bloat. Kernel should provide an execution environment for user programs, and not lecture users about proper system configuration. > > Could the kernel detect that a .eh_frame module was loaded and ignore it > in "safe mode"? Perhaps combined with the new boot-loader cookie, this > would be an automatic way to not mysteriously crash. Why should kernel ignore loaded .eh_frame ? I do not see any use for other part of the suggestion at all. To clarify, kernel paniced because some (required but currently not utilized) part of the binary module was not loaded. > > Alternatively, is there a switch to clang 3.8 that says 'Don't generate the > new > relocation, use the old one instead" which would also be safe and allow a > less-bumpy transition? > > Finally, would the partially loaded module stop at the first bad relocation, > or would it do them all and just skip the bad ones? Is the data from this > relocation > used all the time, or just when we're doing a stack unwind for an exception > or a backtrace? Practically, we could ignore that relocations and still load the module, but this is only because we know what the scope of the relocations is. For some arbitrary situation with the same detected missed place for relocations, loader cannot know is it safe or not. The problem is fixed and does not deserve nuking of all computers in the world, which was an equivalent of some other suggestions how to handle that. Most of the suggestions come to extreme which is not deserved. What could be useful, as I noted already, is to demote the panics from kernel linker to warnings. I intended to work on this. ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r296428 - head/sys/boot/common
On Mon, Mar 7, 2016 at 8:52 AM, Konstantin Belousov wrote: > On Mon, Mar 07, 2016 at 08:39:47AM -0700, Ian Lepore wrote: > > Is there no way to prevent the panic other than making the unwind data > > be present? Why can't the kernel be fixed to cope with the missing > > data in some gentler way during a transition period? Perhaps valid-but > > -fake data could be generated if necessary? Being unable to get a > > stack traceback through a loaded module would be a small price to pay > > for trouble-free updgrades. > > It is practically impossible to recover from partially-loaded object file' > module. The loader workaround currently only affects HEAD and since the > MFC was done, 10.3 should be safe. We always required lastest stable > for the jump to next major branch. > Require is a strong word here. That's the only guarantee the project makes. However, our boot loader has been stable enough that even very old /boot/loaders can load -current until this change. It goes a bit against POLA given what has traditionally worked. If the effort isn't large, we should do something and only fall back to being this strict if there's really no other way possible forward. > What could be done is demoting the panics (there are several, besides > the one which was triggered) to a message and refusing to load the > affected module. OTOH, if the reaction would be a message and not panic, > it definitely go ignored for quite some time. > But a message would tell the user what's up and give them a working kernel with which to fix the problem. It would also allow the traditional upgrade path, burned into many people's fingers, to just work unless they needed one of the rare .eh_frame modules to affect that upgrade. Warner ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r296428 - head/sys/boot/common
On Mon, Mar 7, 2016 at 8:52 AM, Konstantin Belousov wrote: > On Mon, Mar 07, 2016 at 08:39:47AM -0700, Ian Lepore wrote: > > Is there no way to prevent the panic other than making the unwind data > > be present? Why can't the kernel be fixed to cope with the missing > > data in some gentler way during a transition period? Perhaps valid-but > > -fake data could be generated if necessary? Being unable to get a > > stack traceback through a loaded module would be a small price to pay > > for trouble-free updgrades. > > It is practically impossible to recover from partially-loaded object file' > module. The loader workaround currently only affects HEAD and since the > MFC was done, 10.3 should be safe. We always required lastest stable > for the jump to next major branch. > > What could be done is demoting the panics (there are several, besides > the one which was triggered) to a message and refusing to load the > affected module. OTOH, if the reaction would be a message and not panic, > it definitely go ignored for quite some time. > The new loader could also pass in some version or cookie in the metadata that says it is the new one. The kernel could examine this and issue a warning, on amd64 / i386, that module linking may be incomplete and you'll need to upgrade your /boot/loader if you encounter a crash. Could the kernel detect that a .eh_frame module was loaded and ignore it in "safe mode"? Perhaps combined with the new boot-loader cookie, this would be an automatic way to not mysteriously crash. Alternatively, is there a switch to clang 3.8 that says 'Don't generate the new relocation, use the old one instead" which would also be safe and allow a less-bumpy transition? Finally, would the partially loaded module stop at the first bad relocation, or would it do them all and just skip the bad ones? Is the data from this relocation used all the time, or just when we're doing a stack unwind for an exception or a backtrace? Warner ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r296428 - head/sys/boot/common
On Mon, Mar 07, 2016 at 08:39:47AM -0700, Ian Lepore wrote: > Is there no way to prevent the panic other than making the unwind data > be present? Why can't the kernel be fixed to cope with the missing > data in some gentler way during a transition period? Perhaps valid-but > -fake data could be generated if necessary? Being unable to get a > stack traceback through a loaded module would be a small price to pay > for trouble-free updgrades. It is practically impossible to recover from partially-loaded object file' module. The loader workaround currently only affects HEAD and since the MFC was done, 10.3 should be safe. We always required lastest stable for the jump to next major branch. What could be done is demoting the panics (there are several, besides the one which was triggered) to a message and refusing to load the affected module. OTOH, if the reaction would be a message and not panic, it definitely go ignored for quite some time. ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r296428 - head/sys/boot/common
On Mon, 2016-03-07 at 08:41 +0100, Dimitry Andric wrote: > On 07 Mar 2016, at 02:11, Julian Elischer wrote: > > > > On 6/03/2016 7:57 AM, Dimitry Andric wrote: > > > Author: dim > > > Date: Sun Mar 6 15:57:43 2016 > > > New Revision: 296428 > > > URL: https://svnweb.freebsd.org/changeset/base/296428 > > > > > > Log: > > > Since kernel modules can now contain sections of type > > > SHT_AMD64_UNWIND, > > > the boot loader should not skip over these anymore while > > > loading images. > > > Otherwise the kernel can still panic when it doesn't find the > > > .eh_frame > > > section belonging to the .rela.eh_frame section. > > > Unfortunately this will require installing boot loaders from > > > sys/boot > > > before attempting to boot with a new kernel. > > > > what happens to someone who doesn't replace their bootblocks? > > Or is this just the loader? > > This just about the loaders, e.g. loader, loader.efi and zfsloader. > > > > The general way we have handled this sort of thing in the past is > > that we do something > > that produces a nagging message for a decent time before it becomes > > mandatory. > > > > I don't like the idea of people being caught unaware by this.. > > > > Can you please give a more detailed description of what happens? > > If you preload modules with .eh_frame sections in them (such as > aesni.ko) from your loader.conf, your kernel will panic very early in > the boot. > > If you don't preload any modules, or load only modules without > .eh_frame > sections (most of of them), there is no issue at all. > > -Dimitry > Is there no way to prevent the panic other than making the unwind data be present? Why can't the kernel be fixed to cope with the missing data in some gentler way during a transition period? Perhaps valid-but -fake data could be generated if necessary? Being unable to get a stack traceback through a loaded module would be a small price to pay for trouble-free updgrades. -- Ian ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r296428 - head/sys/boot/common
On 07 Mar 2016, at 02:11, Julian Elischer wrote: > > On 6/03/2016 7:57 AM, Dimitry Andric wrote: >> Author: dim >> Date: Sun Mar 6 15:57:43 2016 >> New Revision: 296428 >> URL: https://svnweb.freebsd.org/changeset/base/296428 >> >> Log: >> Since kernel modules can now contain sections of type SHT_AMD64_UNWIND, >> the boot loader should not skip over these anymore while loading images. >> Otherwise the kernel can still panic when it doesn't find the .eh_frame >> section belonging to the .rela.eh_frame section. >> Unfortunately this will require installing boot loaders from sys/boot >> before attempting to boot with a new kernel. > > what happens to someone who doesn't replace their bootblocks? > Or is this just the loader? This just about the loaders, e.g. loader, loader.efi and zfsloader. > The general way we have handled this sort of thing in the past is that we do > something > that produces a nagging message for a decent time before it becomes mandatory. > > I don't like the idea of people being caught unaware by this.. > > Can you please give a more detailed description of what happens? If you preload modules with .eh_frame sections in them (such as aesni.ko) from your loader.conf, your kernel will panic very early in the boot. If you don't preload any modules, or load only modules without .eh_frame sections (most of of them), there is no issue at all. -Dimitry signature.asc Description: Message signed with OpenPGP using GPGMail
Re: svn commit: r296428 - head/sys/boot/common
On Sun, Mar 06, 2016 at 05:11:11PM -0800, Julian Elischer wrote:
> On 6/03/2016 7:57 AM, Dimitry Andric wrote:
> > Author: dim
> > Date: Sun Mar 6 15:57:43 2016
> > New Revision: 296428
> > URL: https://svnweb.freebsd.org/changeset/base/296428
> >
> > Log:
> >Since kernel modules can now contain sections of type SHT_AMD64_UNWIND,
> >the boot loader should not skip over these anymore while loading images.
> >Otherwise the kernel can still panic when it doesn't find the .eh_frame
> >section belonging to the .rela.eh_frame section.
> >
> >Unfortunately this will require installing boot loaders from sys/boot
> >before attempting to boot with a new kernel.
>
> what happens to someone who doesn't replace their bootblocks?
> Or is this just the loader?
>
> The general way we have handled this sort of thing in the past is that
> we do something
> that produces a nagging message for a decent time before it becomes
> mandatory.
>
> I don't like the idea of people being caught unaware by this..
>
> Can you please give a more detailed description of what happens?
In this case it's the loader. I just upgraded a second laptop and did NOT
replace
the boot block (boot1.efi), but DID populate /boot (and actually a full world),
and
it booted fine,
>
> >
> >Reviewed by: kib
> >MFC after: 2 weeks
> >X-MFC-With: r296419
> >
> > Modified:
> >head/sys/boot/common/load_elf_obj.c
> >
> > Modified: head/sys/boot/common/load_elf_obj.c
> > ==
> > --- head/sys/boot/common/load_elf_obj.c Sun Mar 6 14:37:49 2016
> > (r296427)
> > +++ head/sys/boot/common/load_elf_obj.c Sun Mar 6 15:57:43 2016
> > (r296428)
> > @@ -221,6 +221,9 @@ __elfN(obj_loadimage)(struct preloaded_f
> > switch (shdr[i].sh_type) {
> > case SHT_PROGBITS:
> > case SHT_NOBITS:
> > +#if defined(__i386__) || defined(__amd64__)
> > + case SHT_AMD64_UNWIND:
> > +#endif
> > lastaddr = roundup(lastaddr, shdr[i].sh_addralign);
> > shdr[i].sh_addr = (Elf_Addr)lastaddr;
> > lastaddr += shdr[i].sh_size;
> >
> >
>
> ___
> svn-src-all@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/svn-src-all
> To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 214-642-9640 E-Mail: l...@lerctr.org
US Mail: 7011 W Parmer Ln, Apt 1115, Austin, TX 78729-6961
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r296428 - head/sys/boot/common
On 6/03/2016 7:57 AM, Dimitry Andric wrote:
Author: dim
Date: Sun Mar 6 15:57:43 2016
New Revision: 296428
URL: https://svnweb.freebsd.org/changeset/base/296428
Log:
Since kernel modules can now contain sections of type SHT_AMD64_UNWIND,
the boot loader should not skip over these anymore while loading images.
Otherwise the kernel can still panic when it doesn't find the .eh_frame
section belonging to the .rela.eh_frame section.
Unfortunately this will require installing boot loaders from sys/boot
before attempting to boot with a new kernel.
what happens to someone who doesn't replace their bootblocks?
Or is this just the loader?
The general way we have handled this sort of thing in the past is that
we do something
that produces a nagging message for a decent time before it becomes
mandatory.
I don't like the idea of people being caught unaware by this..
Can you please give a more detailed description of what happens?
Reviewed by: kib
MFC after: 2 weeks
X-MFC-With: r296419
Modified:
head/sys/boot/common/load_elf_obj.c
Modified: head/sys/boot/common/load_elf_obj.c
==
--- head/sys/boot/common/load_elf_obj.c Sun Mar 6 14:37:49 2016
(r296427)
+++ head/sys/boot/common/load_elf_obj.c Sun Mar 6 15:57:43 2016
(r296428)
@@ -221,6 +221,9 @@ __elfN(obj_loadimage)(struct preloaded_f
switch (shdr[i].sh_type) {
case SHT_PROGBITS:
case SHT_NOBITS:
+#if defined(__i386__) || defined(__amd64__)
+ case SHT_AMD64_UNWIND:
+#endif
lastaddr = roundup(lastaddr, shdr[i].sh_addralign);
shdr[i].sh_addr = (Elf_Addr)lastaddr;
lastaddr += shdr[i].sh_size;
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r296428 - head/sys/boot/common
Oh wow, i didn't know at all that limits broke booting in this way. Sorry :( This is the first time I've heard about it. -a On 6 March 2016 at 16:38, Warner Losh wrote: > > > On Sun, Mar 6, 2016 at 4:44 PM, Nikolai Lifanov > wrote: >> >> On March 6, 2016 4:13:34 PM EST, Dimitry Andric wrote: >> >On 06 Mar 2016, at 20:57, Nikolai Lifanov >> >wrote: >> >> >> >> On 2016-03-06 11:17, Dimitry Andric wrote: >> >>> On 06 Mar 2016, at 17:00, Oliver Pinter >> > wrote: >> On 3/6/16, Dimitry Andric wrote: >> > Author: dim >> > Date: Sun Mar 6 15:57:43 2016 >> > New Revision: 296428 >> > URL: https://svnweb.freebsd.org/changeset/base/296428 >> > Log: >> > Since kernel modules can now contain sections of type >> >SHT_AMD64_UNWIND, >> > the boot loader should not skip over these anymore while loading >> >images. >> > Otherwise the kernel can still panic when it doesn't find the >> >.eh_frame >> > section belonging to the .rela.eh_frame section. >> > Unfortunately this will require installing boot loaders from >> >sys/boot >> > before attempting to boot with a new kernel. >> Could you please add a note about this to UPDATING file? >> >>> I am a bit torn on this, because normally we always tell people to >> >>> install the kernel first, reboot, then run make installworld (which >> >also >> >>> installs the boot loaders). >> >>> However, in this case, people might depend on their boot loader >> >loading >> >>> modules which are required to make the system boot at all. So if >> >they >> >>> happened to forget updating their boot loader first, a panic might >> >be >> >>> the result. >> >>> I wonder what a failsafe and acceptable upgrade scenario is, in this >> >>> case. Normally the procedure is something like: >> >>> make buildworld >> >>> make buildkernel (with KERNCONF=whatever, if needed) >> >>> make installkernel (again with KERNCONF, if needed) >> >>> reboot (to single user, but cheating is possible usually) >> >>> mergemaster -p >> >>> make installworld >> >>> This could maybe be modified to: >> >>> make buildworld >> >>> make buildkernel (with KERNCONF=whatever, if needed) >> >>> make installkernel (again with KERNCONF, if needed) >> >>> make -C sys/boot install >> >>> reboot (to single user, but cheating is possible usually) >> >>> mergemaster -p >> >>> make installworld >> >>> E.g. insert the step which installs the boot loaders just after (or >> >>> before) the step which installs the kernel. >> >>> Is something like this acceptable as a one-time workaround, or maybe >> >it >> >>> is better in general, in case we ever add other new features to the >> >boot >> >>> loaders? >> >>> -Dimitry >> >> >> >> In my opinion, boot *blocks* (boot1) should be updated seldomly and >> >not on every install. >> >> All (?) instances of not updating these resulting in a failed boot >> >have an UPDATING >> >> entry or a similar warning (like the one during "zpool upgrade"). >> > >> >Well, each time you run make installworld, almost all the files in >> >/boot >> >(except for configuration) get reinstalled. For e.g. mbr, boot1 and >> >such, this has no consequences at all, until you install them into some >> >partition using gpart, but changes to loader, loader.efi or zfsloader >> >*will* affect the next startup. >> > >> >Per a suggestion from Kostik, maybe it would be nice to have a separate >> >"make installboot" target, which installs just the components in /boot. >> >This could then be used before or after "make installkernel". >> > >> >-Dimitry >> >> The bootcode gets installed to boot, but deployed with gpart, cp, sliced >> in half and dd, etc. And that's to one or more partitions. >> I don't think that a separate install target that just stages boot1 to >> /boot is valuable. > > > I think it is. First, the boot code you talk about doesn't matter *AT*ALL* > for this > change. It needn't be deployed to be safe. We've had a few rare cases where > you > do need new boot code as well, but they seem to happen about once a decade > or so. > > Personally, I always install both a kernel and userspace at the same time > when > upgrading, though sometimes just the kernel. Usually it just doesn't matter. > In > this case, I'll know I need new boot blocks. I'm kinda of the opinion that > the boot > loader should be part of installkernel, but I can see how others may > disagree and > that's likely too much POLA to do now (it should have been done in the 4.0 > time > frame when we went to a tertiary boot loader). > > With the recent expansion of limits, however, it's become critical that you > have > a new kernel on boot so that limits used by the rc system are set correctly > (the > new code has no fallback, but fails for limits it doesn't know about, which > is > super lame, and should be fixed, but until it is we're stuck with needing a > new kernel. This also means, btw, that a 10.x kernel has no chance of > booting > an 11.x userland, which is somewhat contra
Re: svn commit: r296428 - head/sys/boot/common
On Sun, Mar 6, 2016 at 4:44 PM, Nikolai Lifanov wrote: > On March 6, 2016 4:13:34 PM EST, Dimitry Andric wrote: > >On 06 Mar 2016, at 20:57, Nikolai Lifanov > >wrote: > >> > >> On 2016-03-06 11:17, Dimitry Andric wrote: > >>> On 06 Mar 2016, at 17:00, Oliver Pinter > > wrote: > On 3/6/16, Dimitry Andric wrote: > > Author: dim > > Date: Sun Mar 6 15:57:43 2016 > > New Revision: 296428 > > URL: https://svnweb.freebsd.org/changeset/base/296428 > > Log: > > Since kernel modules can now contain sections of type > >SHT_AMD64_UNWIND, > > the boot loader should not skip over these anymore while loading > >images. > > Otherwise the kernel can still panic when it doesn't find the > >.eh_frame > > section belonging to the .rela.eh_frame section. > > Unfortunately this will require installing boot loaders from > >sys/boot > > before attempting to boot with a new kernel. > Could you please add a note about this to UPDATING file? > >>> I am a bit torn on this, because normally we always tell people to > >>> install the kernel first, reboot, then run make installworld (which > >also > >>> installs the boot loaders). > >>> However, in this case, people might depend on their boot loader > >loading > >>> modules which are required to make the system boot at all. So if > >they > >>> happened to forget updating their boot loader first, a panic might > >be > >>> the result. > >>> I wonder what a failsafe and acceptable upgrade scenario is, in this > >>> case. Normally the procedure is something like: > >>> make buildworld > >>> make buildkernel (with KERNCONF=whatever, if needed) > >>> make installkernel (again with KERNCONF, if needed) > >>> reboot (to single user, but cheating is possible usually) > >>> mergemaster -p > >>> make installworld > >>> This could maybe be modified to: > >>> make buildworld > >>> make buildkernel (with KERNCONF=whatever, if needed) > >>> make installkernel (again with KERNCONF, if needed) > >>> make -C sys/boot install > >>> reboot (to single user, but cheating is possible usually) > >>> mergemaster -p > >>> make installworld > >>> E.g. insert the step which installs the boot loaders just after (or > >>> before) the step which installs the kernel. > >>> Is something like this acceptable as a one-time workaround, or maybe > >it > >>> is better in general, in case we ever add other new features to the > >boot > >>> loaders? > >>> -Dimitry > >> > >> In my opinion, boot *blocks* (boot1) should be updated seldomly and > >not on every install. > >> All (?) instances of not updating these resulting in a failed boot > >have an UPDATING > >> entry or a similar warning (like the one during "zpool upgrade"). > > > >Well, each time you run make installworld, almost all the files in > >/boot > >(except for configuration) get reinstalled. For e.g. mbr, boot1 and > >such, this has no consequences at all, until you install them into some > >partition using gpart, but changes to loader, loader.efi or zfsloader > >*will* affect the next startup. > > > >Per a suggestion from Kostik, maybe it would be nice to have a separate > >"make installboot" target, which installs just the components in /boot. > >This could then be used before or after "make installkernel". > > > >-Dimitry > > The bootcode gets installed to boot, but deployed with gpart, cp, sliced > in half and dd, etc. And that's to one or more partitions. > I don't think that a separate install target that just stages boot1 to > /boot is valuable. > I think it is. First, the boot code you talk about doesn't matter *AT*ALL* for this change. It needn't be deployed to be safe. We've had a few rare cases where you do need new boot code as well, but they seem to happen about once a decade or so. Personally, I always install both a kernel and userspace at the same time when upgrading, though sometimes just the kernel. Usually it just doesn't matter. In this case, I'll know I need new boot blocks. I'm kinda of the opinion that the boot loader should be part of installkernel, but I can see how others may disagree and that's likely too much POLA to do now (it should have been done in the 4.0 time frame when we went to a tertiary boot loader). With the recent expansion of limits, however, it's become critical that you have a new kernel on boot so that limits used by the rc system are set correctly (the new code has no fallback, but fails for limits it doesn't know about, which is super lame, and should be fixed, but until it is we're stuck with needing a new kernel. This also means, btw, that a 10.x kernel has no chance of booting an 11.x userland, which is somewhat contrary to traditional practice in the project). Warner ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r296428 - head/sys/boot/common
On March 6, 2016 4:13:34 PM EST, Dimitry Andric wrote: >On 06 Mar 2016, at 20:57, Nikolai Lifanov >wrote: >> >> On 2016-03-06 11:17, Dimitry Andric wrote: >>> On 06 Mar 2016, at 17:00, Oliver Pinter > wrote: On 3/6/16, Dimitry Andric wrote: > Author: dim > Date: Sun Mar 6 15:57:43 2016 > New Revision: 296428 > URL: https://svnweb.freebsd.org/changeset/base/296428 > Log: > Since kernel modules can now contain sections of type >SHT_AMD64_UNWIND, > the boot loader should not skip over these anymore while loading >images. > Otherwise the kernel can still panic when it doesn't find the >.eh_frame > section belonging to the .rela.eh_frame section. > Unfortunately this will require installing boot loaders from >sys/boot > before attempting to boot with a new kernel. Could you please add a note about this to UPDATING file? >>> I am a bit torn on this, because normally we always tell people to >>> install the kernel first, reboot, then run make installworld (which >also >>> installs the boot loaders). >>> However, in this case, people might depend on their boot loader >loading >>> modules which are required to make the system boot at all. So if >they >>> happened to forget updating their boot loader first, a panic might >be >>> the result. >>> I wonder what a failsafe and acceptable upgrade scenario is, in this >>> case. Normally the procedure is something like: >>> make buildworld >>> make buildkernel (with KERNCONF=whatever, if needed) >>> make installkernel (again with KERNCONF, if needed) >>> reboot (to single user, but cheating is possible usually) >>> mergemaster -p >>> make installworld >>> This could maybe be modified to: >>> make buildworld >>> make buildkernel (with KERNCONF=whatever, if needed) >>> make installkernel (again with KERNCONF, if needed) >>> make -C sys/boot install >>> reboot (to single user, but cheating is possible usually) >>> mergemaster -p >>> make installworld >>> E.g. insert the step which installs the boot loaders just after (or >>> before) the step which installs the kernel. >>> Is something like this acceptable as a one-time workaround, or maybe >it >>> is better in general, in case we ever add other new features to the >boot >>> loaders? >>> -Dimitry >> >> In my opinion, boot *blocks* (boot1) should be updated seldomly and >not on every install. >> All (?) instances of not updating these resulting in a failed boot >have an UPDATING >> entry or a similar warning (like the one during "zpool upgrade"). > >Well, each time you run make installworld, almost all the files in >/boot >(except for configuration) get reinstalled. For e.g. mbr, boot1 and >such, this has no consequences at all, until you install them into some >partition using gpart, but changes to loader, loader.efi or zfsloader >*will* affect the next startup. > >Per a suggestion from Kostik, maybe it would be nice to have a separate >"make installboot" target, which installs just the components in /boot. >This could then be used before or after "make installkernel". > >-Dimitry The bootcode gets installed to boot, but deployed with gpart, cp, sliced in half and dd, etc. And that's to one or more partitions. I don't think that a separate install target that just stages boot1 to /boot is valuable. - Nikolai Lifanov ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r296428 - head/sys/boot/common
On 06 Mar 2016, at 20:57, Nikolai Lifanov wrote: > > On 2016-03-06 11:17, Dimitry Andric wrote: >> On 06 Mar 2016, at 17:00, Oliver Pinter >> wrote: >>> On 3/6/16, Dimitry Andric wrote: Author: dim Date: Sun Mar 6 15:57:43 2016 New Revision: 296428 URL: https://svnweb.freebsd.org/changeset/base/296428 Log: Since kernel modules can now contain sections of type SHT_AMD64_UNWIND, the boot loader should not skip over these anymore while loading images. Otherwise the kernel can still panic when it doesn't find the .eh_frame section belonging to the .rela.eh_frame section. Unfortunately this will require installing boot loaders from sys/boot before attempting to boot with a new kernel. >>> Could you please add a note about this to UPDATING file? >> I am a bit torn on this, because normally we always tell people to >> install the kernel first, reboot, then run make installworld (which also >> installs the boot loaders). >> However, in this case, people might depend on their boot loader loading >> modules which are required to make the system boot at all. So if they >> happened to forget updating their boot loader first, a panic might be >> the result. >> I wonder what a failsafe and acceptable upgrade scenario is, in this >> case. Normally the procedure is something like: >> make buildworld >> make buildkernel (with KERNCONF=whatever, if needed) >> make installkernel (again with KERNCONF, if needed) >> reboot (to single user, but cheating is possible usually) >> mergemaster -p >> make installworld >> This could maybe be modified to: >> make buildworld >> make buildkernel (with KERNCONF=whatever, if needed) >> make installkernel (again with KERNCONF, if needed) >> make -C sys/boot install >> reboot (to single user, but cheating is possible usually) >> mergemaster -p >> make installworld >> E.g. insert the step which installs the boot loaders just after (or >> before) the step which installs the kernel. >> Is something like this acceptable as a one-time workaround, or maybe it >> is better in general, in case we ever add other new features to the boot >> loaders? >> -Dimitry > > In my opinion, boot *blocks* (boot1) should be updated seldomly and not on > every install. > All (?) instances of not updating these resulting in a failed boot have an > UPDATING > entry or a similar warning (like the one during "zpool upgrade"). Well, each time you run make installworld, almost all the files in /boot (except for configuration) get reinstalled. For e.g. mbr, boot1 and such, this has no consequences at all, until you install them into some partition using gpart, but changes to loader, loader.efi or zfsloader *will* affect the next startup. Per a suggestion from Kostik, maybe it would be nice to have a separate "make installboot" target, which installs just the components in /boot. This could then be used before or after "make installkernel". -Dimitry signature.asc Description: Message signed with OpenPGP using GPGMail
Re: svn commit: r296428 - head/sys/boot/common
On 2016-03-06 11:17, Dimitry Andric wrote: On 06 Mar 2016, at 17:00, Oliver Pinter wrote: On 3/6/16, Dimitry Andric wrote: Author: dim Date: Sun Mar 6 15:57:43 2016 New Revision: 296428 URL: https://svnweb.freebsd.org/changeset/base/296428 Log: Since kernel modules can now contain sections of type SHT_AMD64_UNWIND, the boot loader should not skip over these anymore while loading images. Otherwise the kernel can still panic when it doesn't find the .eh_frame section belonging to the .rela.eh_frame section. Unfortunately this will require installing boot loaders from sys/boot before attempting to boot with a new kernel. Could you please add a note about this to UPDATING file? I am a bit torn on this, because normally we always tell people to install the kernel first, reboot, then run make installworld (which also installs the boot loaders). However, in this case, people might depend on their boot loader loading modules which are required to make the system boot at all. So if they happened to forget updating their boot loader first, a panic might be the result. I wonder what a failsafe and acceptable upgrade scenario is, in this case. Normally the procedure is something like: make buildworld make buildkernel (with KERNCONF=whatever, if needed) make installkernel (again with KERNCONF, if needed) reboot (to single user, but cheating is possible usually) mergemaster -p make installworld This could maybe be modified to: make buildworld make buildkernel (with KERNCONF=whatever, if needed) make installkernel (again with KERNCONF, if needed) make -C sys/boot install reboot (to single user, but cheating is possible usually) mergemaster -p make installworld E.g. insert the step which installs the boot loaders just after (or before) the step which installs the kernel. Is something like this acceptable as a one-time workaround, or maybe it is better in general, in case we ever add other new features to the boot loaders? -Dimitry In my opinion, boot *blocks* (boot1) should be updated seldomly and not on every install. All (?) instances of not updating these resulting in a failed boot have an UPDATING entry or a similar warning (like the one during "zpool upgrade"). - Nikolai Lifanov ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r296428 - head/sys/boot/common
On 3/6/16, Dimitry Andric wrote:
> On 06 Mar 2016, at 17:00, Oliver Pinter
> wrote:
>>
>> On 3/6/16, Dimitry Andric wrote:
>>> Author: dim
>>> Date: Sun Mar 6 15:57:43 2016
>>> New Revision: 296428
>>> URL: https://svnweb.freebsd.org/changeset/base/296428
>>>
>>> Log:
>>> Since kernel modules can now contain sections of type SHT_AMD64_UNWIND,
>>> the boot loader should not skip over these anymore while loading
>>> images.
>>> Otherwise the kernel can still panic when it doesn't find the .eh_frame
>>> section belonging to the .rela.eh_frame section.
>>>
>>> Unfortunately this will require installing boot loaders from sys/boot
>>> before attempting to boot with a new kernel.
>>
>> Could you please add a note about this to UPDATING file?
>
> I am a bit torn on this, because normally we always tell people to
> install the kernel first, reboot, then run make installworld (which also
> installs the boot loaders).
>
> However, in this case, people might depend on their boot loader loading
> modules which are required to make the system boot at all. So if they
> happened to forget updating their boot loader first, a panic might be
> the result.
>
> I wonder what a failsafe and acceptable upgrade scenario is, in this
> case. Normally the procedure is something like:
>
> make buildworld
> make buildkernel (with KERNCONF=whatever, if needed)
> make installkernel (again with KERNCONF, if needed)
> reboot (to single user, but cheating is possible usually)
> mergemaster -p
> make installworld
>
> This could maybe be modified to:
>
> make buildworld
> make buildkernel (with KERNCONF=whatever, if needed)
> make installkernel (again with KERNCONF, if needed)
> make -C sys/boot install
> reboot (to single user, but cheating is possible usually)
> mergemaster -p
> make installworld
>
> E.g. insert the step which installs the boot loaders just after (or
> before) the step which installs the kernel.
>
> Is something like this acceptable as a one-time workaround, or maybe it
> is better in general, in case we ever add other new features to the boot
> loaders?
If I'm not wrong, the bootloaders are self-contained (using libstand,
and statically linked) same as the kernel, so they are not depend from
the other parts of the system, and they already lives under the
${SRCTOP}/sys with the kernel, so logically bootloader belong to the
kernel and it's acceptable from me to update them under the
installkernel phase. The question is with this method everything
working fine or this would break something?
>
> -Dimitry
>
>
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r296428 - head/sys/boot/common
On 06 Mar 2016, at 17:00, Oliver Pinter wrote: > > On 3/6/16, Dimitry Andric wrote: >> Author: dim >> Date: Sun Mar 6 15:57:43 2016 >> New Revision: 296428 >> URL: https://svnweb.freebsd.org/changeset/base/296428 >> >> Log: >> Since kernel modules can now contain sections of type SHT_AMD64_UNWIND, >> the boot loader should not skip over these anymore while loading images. >> Otherwise the kernel can still panic when it doesn't find the .eh_frame >> section belonging to the .rela.eh_frame section. >> >> Unfortunately this will require installing boot loaders from sys/boot >> before attempting to boot with a new kernel. > > Could you please add a note about this to UPDATING file? I am a bit torn on this, because normally we always tell people to install the kernel first, reboot, then run make installworld (which also installs the boot loaders). However, in this case, people might depend on their boot loader loading modules which are required to make the system boot at all. So if they happened to forget updating their boot loader first, a panic might be the result. I wonder what a failsafe and acceptable upgrade scenario is, in this case. Normally the procedure is something like: make buildworld make buildkernel (with KERNCONF=whatever, if needed) make installkernel (again with KERNCONF, if needed) reboot (to single user, but cheating is possible usually) mergemaster -p make installworld This could maybe be modified to: make buildworld make buildkernel (with KERNCONF=whatever, if needed) make installkernel (again with KERNCONF, if needed) make -C sys/boot install reboot (to single user, but cheating is possible usually) mergemaster -p make installworld E.g. insert the step which installs the boot loaders just after (or before) the step which installs the kernel. Is something like this acceptable as a one-time workaround, or maybe it is better in general, in case we ever add other new features to the boot loaders? -Dimitry signature.asc Description: Message signed with OpenPGP using GPGMail
Re: svn commit: r296428 - head/sys/boot/common
On 3/6/16, Dimitry Andric wrote:
> Author: dim
> Date: Sun Mar 6 15:57:43 2016
> New Revision: 296428
> URL: https://svnweb.freebsd.org/changeset/base/296428
>
> Log:
> Since kernel modules can now contain sections of type SHT_AMD64_UNWIND,
> the boot loader should not skip over these anymore while loading images.
> Otherwise the kernel can still panic when it doesn't find the .eh_frame
> section belonging to the .rela.eh_frame section.
>
> Unfortunately this will require installing boot loaders from sys/boot
> before attempting to boot with a new kernel.
Could you please add a note about this to UPDATING file?
>
> Reviewed by:kib
> MFC after: 2 weeks
> X-MFC-With: r296419
>
> Modified:
> head/sys/boot/common/load_elf_obj.c
>
> Modified: head/sys/boot/common/load_elf_obj.c
> ==
> --- head/sys/boot/common/load_elf_obj.c Sun Mar 6 14:37:49 2016
> (r296427)
> +++ head/sys/boot/common/load_elf_obj.c Sun Mar 6 15:57:43 2016
> (r296428)
> @@ -221,6 +221,9 @@ __elfN(obj_loadimage)(struct preloaded_f
> switch (shdr[i].sh_type) {
> case SHT_PROGBITS:
> case SHT_NOBITS:
> +#if defined(__i386__) || defined(__amd64__)
> + case SHT_AMD64_UNWIND:
> +#endif
> lastaddr = roundup(lastaddr, shdr[i].sh_addralign);
> shdr[i].sh_addr = (Elf_Addr)lastaddr;
> lastaddr += shdr[i].sh_size;
> ___
> svn-src-h...@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/svn-src-head
> To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
>
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
svn commit: r296428 - head/sys/boot/common
Author: dim
Date: Sun Mar 6 15:57:43 2016
New Revision: 296428
URL: https://svnweb.freebsd.org/changeset/base/296428
Log:
Since kernel modules can now contain sections of type SHT_AMD64_UNWIND,
the boot loader should not skip over these anymore while loading images.
Otherwise the kernel can still panic when it doesn't find the .eh_frame
section belonging to the .rela.eh_frame section.
Unfortunately this will require installing boot loaders from sys/boot
before attempting to boot with a new kernel.
Reviewed by: kib
MFC after:2 weeks
X-MFC-With: r296419
Modified:
head/sys/boot/common/load_elf_obj.c
Modified: head/sys/boot/common/load_elf_obj.c
==
--- head/sys/boot/common/load_elf_obj.c Sun Mar 6 14:37:49 2016
(r296427)
+++ head/sys/boot/common/load_elf_obj.c Sun Mar 6 15:57:43 2016
(r296428)
@@ -221,6 +221,9 @@ __elfN(obj_loadimage)(struct preloaded_f
switch (shdr[i].sh_type) {
case SHT_PROGBITS:
case SHT_NOBITS:
+#if defined(__i386__) || defined(__amd64__)
+ case SHT_AMD64_UNWIND:
+#endif
lastaddr = roundup(lastaddr, shdr[i].sh_addralign);
shdr[i].sh_addr = (Elf_Addr)lastaddr;
lastaddr += shdr[i].sh_size;
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
