[PATCH 4/6] ARM: dts: bcm2711: Expose boot-loader configuration
RPi4's co-processor will copy the board's bootloader configuration in
memory. Expose it to user-space by using 'nvmem-rmem'.
Signed-off-by: Nicolas Saenz Julienne
---
arch/arm/boot/dts/bcm2711-rpi-4-b.dts | 11 +++
1 file changed, 11 insertions(+)
diff --git a/arch/arm/boot/dts/bcm2711-rpi-4-b.dts
b/arch/arm/boot/dts/bcm2711-rpi-4-b.dts
index c58e58e8ce39..261169eb5e3b 100644
--- a/arch/arm/boot/dts/bcm2711-rpi-4-b.dts
+++ b/arch/arm/boot/dts/bcm2711-rpi-4-b.dts
@@ -26,6 +26,17 @@ aliases {
ethernet0 =
pcie0 =
eeprom =
+ fw_config = _config;
+ };
+
+ fw_config: fw-config {
+ compatible = "nvmem-rmem";
+ memory-region = <>;
+ /*
+* Will be enabled by the bootloader if the reserved memory
+* region is valid.
+*/
+ status = "disabled";
};
leds {
--
2.29.2
[PATCH 3.16 058/129] ext4: update quota information while swapping boot loader inode
3.16.70-rc1 review patch. If anyone has any objections, please let me know.
--
From: yangerkun
commit aa507b5faf38784defe49f5e64605ac3c4425e26 upstream.
While do swap between two inode, they swap i_data without update
quota information. Also, swap_inode_boot_loader can do "revert"
somtimes, so update the quota while all operations has been finished.
Signed-off-by: yangerkun
Signed-off-by: Theodore Ts'o
[bwh: Backported to 3.16:
- Include
- dquot_initialize() does not return an erro
- Adjust context]
Signed-off-by: Ben Hutchings
---
--- a/fs/ext4/ioctl.c
+++ b/fs/ext4/ioctl.c
@@ -14,6 +14,7 @@
#include
#include
#include
+#include
#include
#include "ext4_jbd2.h"
#include "ext4.h"
@@ -66,9 +67,6 @@ static void swap_inode_data(struct inode
memswap(>i_version, >i_version,
sizeof(inode1->i_version));
- memswap(>i_blocks, >i_blocks,
- sizeof(inode1->i_blocks));
- memswap(>i_bytes, >i_bytes, sizeof(inode1->i_bytes));
memswap(>i_atime, >i_atime, sizeof(inode1->i_atime));
memswap(>i_mtime, >i_mtime, sizeof(inode1->i_mtime));
@@ -117,6 +115,9 @@ static long swap_inode_boot_loader(struc
struct inode *inode_bl;
struct ext4_inode_info *ei_bl;
struct ext4_sb_info *sbi = EXT4_SB(sb);
+ qsize_t size, size_bl, diff;
+ blkcnt_t blocks;
+ unsigned short bytes;
inode_bl = ext4_iget(sb, EXT4_BOOT_LOADER_INO, EXT4_IGET_SPECIAL);
if (IS_ERR(inode_bl))
@@ -179,6 +180,11 @@ static long swap_inode_boot_loader(struc
memset(ei_bl->i_data, 0, sizeof(ei_bl->i_data));
}
+ dquot_initialize(inode);
+
+ size = (qsize_t)(inode->i_blocks) * (1 << 9) + inode->i_bytes;
+ size_bl = (qsize_t)(inode_bl->i_blocks) * (1 << 9) + inode_bl->i_bytes;
+ diff = size - size_bl;
swap_inode_data(inode, inode_bl);
inode->i_ctime = inode_bl->i_ctime = ext4_current_time(inode);
@@ -194,24 +200,46 @@ static long swap_inode_boot_loader(struc
err = ext4_mark_inode_dirty(handle, inode);
if (err < 0) {
+ /* No need to update quota information. */
ext4_warning(inode->i_sb,
"couldn't mark inode #%lu dirty (err %d)",
inode->i_ino, err);
/* Revert all changes: */
swap_inode_data(inode, inode_bl);
ext4_mark_inode_dirty(handle, inode);
- } else {
- err = ext4_mark_inode_dirty(handle, inode_bl);
- if (err < 0) {
- ext4_warning(inode_bl->i_sb,
- "couldn't mark inode #%lu dirty (err %d)",
- inode_bl->i_ino, err);
- /* Revert all changes: */
- swap_inode_data(inode, inode_bl);
- ext4_mark_inode_dirty(handle, inode);
- ext4_mark_inode_dirty(handle, inode_bl);
- }
+ goto err_out1;
}
+
+ blocks = inode_bl->i_blocks;
+ bytes = inode_bl->i_bytes;
+ inode_bl->i_blocks = inode->i_blocks;
+ inode_bl->i_bytes = inode->i_bytes;
+ err = ext4_mark_inode_dirty(handle, inode_bl);
+ if (err < 0) {
+ /* No need to update quota information. */
+ ext4_warning(inode_bl->i_sb,
+ "couldn't mark inode #%lu dirty (err %d)",
+ inode_bl->i_ino, err);
+ goto revert;
+ }
+
+ /* Bootloader inode should not be counted into quota information. */
+ if (diff > 0)
+ dquot_free_space(inode, diff);
+ else
+ err = dquot_alloc_space(inode, -1 * diff);
+
+ if (err < 0) {
+revert:
+ /* Revert all changes: */
+ inode_bl->i_blocks = blocks;
+ inode_bl->i_bytes = bytes;
+ swap_inode_data(inode, inode_bl);
+ ext4_mark_inode_dirty(handle, inode);
+ ext4_mark_inode_dirty(handle, inode_bl);
+ }
+
+err_out1:
ext4_journal_stop(handle);
ext4_double_up_write_data_sem(inode, inode_bl);
Re: [v4 PATCH] RISC-V: Add an Image header that boot loader can parse.
> On 5/28/19 3:47 AM, Ard Biesheuvel wrote: >> On Tue, 28 May 2019 at 12:34, Anup Patel wrote: >> >> >> >>> -Original Message- >>> From: Karsten Merker >>> Sent: Tuesday, May 28, 2019 1:53 PM >>> To: Anup Patel >>> Cc: Troy Benjegerdes ; Karsten Merker >>> ; Albert Ou ; Jonathan >>> Corbet ; Ard Biesheuvel ; >>> linux-kernel@vger.kernel.org List ; Zong Li >>> ; Atish Patra ; Palmer >>> Dabbelt ; paul.walms...@sifive.com; Nick Kossifidis >>> ; linux-ri...@lists.infradead.org; >>> marek.va...@gmail.com >>> Subject: Re: [v4 PATCH] RISC-V: Add an Image header that boot loader can >>> parse. >>> >>>> On Tue, May 28, 2019 at 03:54:02AM +, Anup Patel wrote: >>>>>> From: Troy Benjegerdes >>>>>>> On May 27, 2019, at 5:16 PM, Karsten Merker >>>>>> wrote: >>>>>> >>>>>>> On Mon, May 27, 2019 at 04:34:57PM +0200, Ard Biesheuvel wrote: >>>>>>> On Fri, 24 May 2019 at 06:18, Atish Patra >>> wrote: >>>>>>>> Currently, the last stage boot loaders such as U-Boot can accept >>>>>>>> only uImage which is an unnecessary additional step in >>>>>>>> automating boot process. >>>>>>>> >>>>>>>> Add an image header that boot loader understands and boot Linux >>>>>>>> from flat Image directly. >>>>>>>> >>>>>>>> This header is based on ARM64 boot image header and provides an >>>>>>>> opportunity to combine both ARM64 & RISC-V image headers in >>> future. >>>>>>>> >>>>>>>> Also make sure that PE/COFF header can co-exist in the same >>>>>>>> image so that EFI stub can be supported for RISC-V in future. >>>>>>>> EFI specification needs PE/COFF image header in the beginning of >>>>>>>> the kernel image in order to load it as an EFI application. In >>>>>>>> order to support EFI stub, code0 should be replaced with "MZ" >>>>>>>> magic string and res4(at offset 0x3c) should point to the rest >>>>>>>> of the PE/COFF header (which will be added during EFI support). >>>>>> [...] >>>>>>>> Documentation/riscv/boot-image-header.txt | 50 >>>>> ++ >>>>>>>> arch/riscv/include/asm/image.h| 64 >>> +++ >>>>>>>> arch/riscv/kernel/head.S | 32 >>>>>>>> 3 files changed, 146 insertions(+) create mode 100644 >>>>>>>> Documentation/riscv/boot-image-header.txt >>>>>>>> create mode 100644 arch/riscv/include/asm/image.h >>>>>>>> >>>>>>>> diff --git a/Documentation/riscv/boot-image-header.txt >>>>>>>> b/Documentation/riscv/boot-image-header.txt >>>>>>>> new file mode 100644 >>>>>>>> index ..68abc2353cec >>>>>>>> --- /dev/null >>>>>>>> +++ b/Documentation/riscv/boot-image-header.txt >>>>>>>> @@ -0,0 +1,50 @@ >>>>>>>> + Boot image header in RISC-V >>>>>>>> + Linux >>>>>>>> + >>>>>>>> + = >>>>>>>> + >>>>>>>> +Author: Atish Patra Date : 20 May 2019 >>>>>>>> + >>>>>>>> +This document only describes the boot image header details for >>>>>>>> +RISC-V >>>>> Linux. >>>>>>>> +The complete booting guide will be available at >>>>> Documentation/riscv/booting.txt. >>>>>>>> + >>>>>>>> +The following 64-byte header is present in decompressed Linux >>>>>>>> +kernel >>>>> image. >>>>>>>> + >>>>>>>> + u32 code0;/* Executable code */ >>>>>>>> + u32 code1;/* Executable code */ >>>>>>> >>>>>>> Apologies for not mentioning this in my previous reply, but given >>>>>>> that you alrea
Re: [v4 PATCH] RISC-V: Add an Image header that boot loader can parse.
On Tue, 28 May 2019 at 12:34, Anup Patel wrote: > > > > > -Original Message- > > From: Karsten Merker > > Sent: Tuesday, May 28, 2019 1:53 PM > > To: Anup Patel > > Cc: Troy Benjegerdes ; Karsten Merker > > ; Albert Ou ; Jonathan > > Corbet ; Ard Biesheuvel ; > > linux-kernel@vger.kernel.org List ; Zong Li > > ; Atish Patra ; Palmer > > Dabbelt ; paul.walms...@sifive.com; Nick Kossifidis > > ; linux-ri...@lists.infradead.org; > > marek.va...@gmail.com > > Subject: Re: [v4 PATCH] RISC-V: Add an Image header that boot loader can > > parse. > > > > On Tue, May 28, 2019 at 03:54:02AM +, Anup Patel wrote: > > > > From: Troy Benjegerdes > > > > > On May 27, 2019, at 5:16 PM, Karsten Merker > > > > wrote: > > > > > > > > > > On Mon, May 27, 2019 at 04:34:57PM +0200, Ard Biesheuvel wrote: > > > > >> On Fri, 24 May 2019 at 06:18, Atish Patra > > wrote: > > > > >>> Currently, the last stage boot loaders such as U-Boot can accept > > > > >>> only uImage which is an unnecessary additional step in > > > > >>> automating boot process. > > > > >>> > > > > >>> Add an image header that boot loader understands and boot Linux > > > > >>> from flat Image directly. > > > > >>> > > > > >>> This header is based on ARM64 boot image header and provides an > > > > >>> opportunity to combine both ARM64 & RISC-V image headers in > > future. > > > > >>> > > > > >>> Also make sure that PE/COFF header can co-exist in the same > > > > >>> image so that EFI stub can be supported for RISC-V in future. > > > > >>> EFI specification needs PE/COFF image header in the beginning of > > > > >>> the kernel image in order to load it as an EFI application. In > > > > >>> order to support EFI stub, code0 should be replaced with "MZ" > > > > >>> magic string and res4(at offset 0x3c) should point to the rest > > > > >>> of the PE/COFF header (which will be added during EFI support). > > > > > [...] > > > > >>> Documentation/riscv/boot-image-header.txt | 50 > > > > ++ > > > > >>> arch/riscv/include/asm/image.h| 64 > > +++ > > > > >>> arch/riscv/kernel/head.S | 32 > > > > >>> 3 files changed, 146 insertions(+) create mode 100644 > > > > >>> Documentation/riscv/boot-image-header.txt > > > > >>> create mode 100644 arch/riscv/include/asm/image.h > > > > >>> > > > > >>> diff --git a/Documentation/riscv/boot-image-header.txt > > > > >>> b/Documentation/riscv/boot-image-header.txt > > > > >>> new file mode 100644 > > > > >>> index ..68abc2353cec > > > > >>> --- /dev/null > > > > >>> +++ b/Documentation/riscv/boot-image-header.txt > > > > >>> @@ -0,0 +1,50 @@ > > > > >>> + Boot image header in RISC-V > > > > >>> + Linux > > > > >>> + > > > > >>> + = > > > > >>> + > > > > >>> +Author: Atish Patra Date : 20 May 2019 > > > > >>> + > > > > >>> +This document only describes the boot image header details for > > > > >>> +RISC-V > > > > Linux. > > > > >>> +The complete booting guide will be available at > > > > Documentation/riscv/booting.txt. > > > > >>> + > > > > >>> +The following 64-byte header is present in decompressed Linux > > > > >>> +kernel > > > > image. > > > > >>> + > > > > >>> + u32 code0;/* Executable code */ > > > > >>> + u32 code1;/* Executable code */ > > > > >> > > > > >> Apologies for not mentioning this in my previous reply, but given > > > > >> that you already know that you will need to put the magic string > > > > >> MZ at offset 0x0, it makes more sense to not put any code there > > >
RE: [v4 PATCH] RISC-V: Add an Image header that boot loader can parse.
> -Original Message- > From: Karsten Merker > Sent: Tuesday, May 28, 2019 1:53 PM > To: Anup Patel > Cc: Troy Benjegerdes ; Karsten Merker > ; Albert Ou ; Jonathan > Corbet ; Ard Biesheuvel ; > linux-kernel@vger.kernel.org List ; Zong Li > ; Atish Patra ; Palmer > Dabbelt ; paul.walms...@sifive.com; Nick Kossifidis > ; linux-ri...@lists.infradead.org; > marek.va...@gmail.com > Subject: Re: [v4 PATCH] RISC-V: Add an Image header that boot loader can > parse. > > On Tue, May 28, 2019 at 03:54:02AM +, Anup Patel wrote: > > > From: Troy Benjegerdes > > > > On May 27, 2019, at 5:16 PM, Karsten Merker > > > wrote: > > > > > > > > On Mon, May 27, 2019 at 04:34:57PM +0200, Ard Biesheuvel wrote: > > > >> On Fri, 24 May 2019 at 06:18, Atish Patra > wrote: > > > >>> Currently, the last stage boot loaders such as U-Boot can accept > > > >>> only uImage which is an unnecessary additional step in > > > >>> automating boot process. > > > >>> > > > >>> Add an image header that boot loader understands and boot Linux > > > >>> from flat Image directly. > > > >>> > > > >>> This header is based on ARM64 boot image header and provides an > > > >>> opportunity to combine both ARM64 & RISC-V image headers in > future. > > > >>> > > > >>> Also make sure that PE/COFF header can co-exist in the same > > > >>> image so that EFI stub can be supported for RISC-V in future. > > > >>> EFI specification needs PE/COFF image header in the beginning of > > > >>> the kernel image in order to load it as an EFI application. In > > > >>> order to support EFI stub, code0 should be replaced with "MZ" > > > >>> magic string and res4(at offset 0x3c) should point to the rest > > > >>> of the PE/COFF header (which will be added during EFI support). > > > > [...] > > > >>> Documentation/riscv/boot-image-header.txt | 50 > > > ++ > > > >>> arch/riscv/include/asm/image.h| 64 > +++ > > > >>> arch/riscv/kernel/head.S | 32 > > > >>> 3 files changed, 146 insertions(+) create mode 100644 > > > >>> Documentation/riscv/boot-image-header.txt > > > >>> create mode 100644 arch/riscv/include/asm/image.h > > > >>> > > > >>> diff --git a/Documentation/riscv/boot-image-header.txt > > > >>> b/Documentation/riscv/boot-image-header.txt > > > >>> new file mode 100644 > > > >>> index ..68abc2353cec > > > >>> --- /dev/null > > > >>> +++ b/Documentation/riscv/boot-image-header.txt > > > >>> @@ -0,0 +1,50 @@ > > > >>> + Boot image header in RISC-V > > > >>> + Linux > > > >>> + > > > >>> + = > > > >>> + > > > >>> +Author: Atish Patra Date : 20 May 2019 > > > >>> + > > > >>> +This document only describes the boot image header details for > > > >>> +RISC-V > > > Linux. > > > >>> +The complete booting guide will be available at > > > Documentation/riscv/booting.txt. > > > >>> + > > > >>> +The following 64-byte header is present in decompressed Linux > > > >>> +kernel > > > image. > > > >>> + > > > >>> + u32 code0;/* Executable code */ > > > >>> + u32 code1;/* Executable code */ > > > >> > > > >> Apologies for not mentioning this in my previous reply, but given > > > >> that you already know that you will need to put the magic string > > > >> MZ at offset 0x0, it makes more sense to not put any code there > > > >> at all, but educate the bootloader that the first executable > > > >> instruction is at offset 0x20, and put the spare fields right > > > >> after it in case you ever need more than 2 slots. (On arm64, we > > > >> were lucky to be able to find an opcode that happened to contain > > > >> the MZ bit pattern and act almost like a NOP, but it seems silly > > > >> to rely on that for R
RE: [v4 PATCH] RISC-V: Add an Image header that boot loader can parse.
> -Original Message- > From: Troy Benjegerdes > Sent: Tuesday, May 28, 2019 5:11 AM > To: Karsten Merker > Cc: Ard Biesheuvel ; Albert Ou > ; Jonathan Corbet ; Anup Patel > ; Zong Li ; Atish Patra > ; Nick Kossifidis ; Palmer Dabbelt > ; paul.walms...@sifive.com; linux- > ri...@lists.infradead.org; marek.va...@gmail.com > Subject: Re: [v4 PATCH] RISC-V: Add an Image header that boot loader can > parse. > > > > > On May 27, 2019, at 5:16 PM, Karsten Merker > wrote: > > > > On Mon, May 27, 2019 at 04:34:57PM +0200, Ard Biesheuvel wrote: > >> On Fri, 24 May 2019 at 06:18, Atish Patra wrote: > >>> Currently, the last stage boot loaders such as U-Boot can accept > >>> only uImage which is an unnecessary additional step in automating > >>> boot process. > >>> > >>> Add an image header that boot loader understands and boot Linux from > >>> flat Image directly. > >>> > >>> This header is based on ARM64 boot image header and provides an > >>> opportunity to combine both ARM64 & RISC-V image headers in future. > >>> > >>> Also make sure that PE/COFF header can co-exist in the same image so > >>> that EFI stub can be supported for RISC-V in future. EFI > >>> specification needs PE/COFF image header in the beginning of the > >>> kernel image in order to load it as an EFI application. In order to > >>> support EFI stub, code0 should be replaced with "MZ" magic string > >>> and res4(at offset 0x3c) should point to the rest of the PE/COFF > >>> header (which will be added during EFI support). > > [...] > >>> Documentation/riscv/boot-image-header.txt | 50 > ++ > >>> arch/riscv/include/asm/image.h| 64 +++ > >>> arch/riscv/kernel/head.S | 32 > >>> 3 files changed, 146 insertions(+) > >>> create mode 100644 Documentation/riscv/boot-image-header.txt > >>> create mode 100644 arch/riscv/include/asm/image.h > >>> > >>> diff --git a/Documentation/riscv/boot-image-header.txt > >>> b/Documentation/riscv/boot-image-header.txt > >>> new file mode 100644 > >>> index ..68abc2353cec > >>> --- /dev/null > >>> +++ b/Documentation/riscv/boot-image-header.txt > >>> @@ -0,0 +1,50 @@ > >>> + Boot image header in RISC-V Linux > >>> + > >>> + = > >>> + > >>> +Author: Atish Patra Date : 20 May 2019 > >>> + > >>> +This document only describes the boot image header details for RISC-V > Linux. > >>> +The complete booting guide will be available at > Documentation/riscv/booting.txt. > >>> + > >>> +The following 64-byte header is present in decompressed Linux kernel > image. > >>> + > >>> + u32 code0;/* Executable code */ > >>> + u32 code1;/* Executable code */ > >> > >> Apologies for not mentioning this in my previous reply, but given > >> that you already know that you will need to put the magic string MZ > >> at offset 0x0, it makes more sense to not put any code there at all, > >> but educate the bootloader that the first executable instruction is > >> at offset 0x20, and put the spare fields right after it in case you > >> ever need more than 2 slots. (On arm64, we were lucky to be able to > >> find an opcode that happened to contain the MZ bit pattern and act > >> almost like a NOP, but it seems silly to rely on that for RISC-V as > >> well) > >> > >> So something like > >> > >> u16 pe_res1; /* MZ for EFI bootable images, don't care otherwise */ > >> u8 magic[6];/* "RISCV\0" > >> > >> u64 text_offset; /* Image load offset, little endian */ > >> u64 image_size; /* Effective Image size, little endian */ > >> u64 flags;/* kernel flags, little endian */ > >> > >> u32 code0;/* Executable code */ > >> u32 code1;/* Executable code */ > >> > >> u64 reserved[2]; /* reserved for future use */ > >> > >> u32 version; /* Version of this header */ > >> u32 pe_res2; /* Reserved for PE COFF offset */ > > > > Hello, > > > > wouldn't th
Re: [v4 PATCH] RISC-V: Add an Image header that boot loader can parse.
On Thu 23 May 2019 at 21:18, Atish Patra wrote: > Currently, the last stage boot loaders such as U-Boot can accept only > uImage which is an unnecessary additional step in automating boot > process. > > Add an image header that boot loader understands and boot Linux from > flat Image directly. > > This header is based on ARM64 boot image header and provides an > opportunity to combine both ARM64 & RISC-V image headers in future. > > Also make sure that PE/COFF header can co-exist in the same image so > that EFI stub can be supported for RISC-V in future. EFI specification > needs PE/COFF image header in the beginning of the kernel image in order > to load it as an EFI application. In order to support EFI stub, code0 > should be replaced with "MZ" magic string and res4(at offset 0x3c) > should point to the rest of the PE/COFF header (which will be added > during EFI support). > > Tested on both QEMU and HiFive Unleashed using OpenSBI + U-Boot + Linux. Thanks Atish, happy to have this support that makes the boot process more straightforward. Tested on HiFive Unleashed using OpenSBI + U-Boot v2019.07-rc2 + Linux. > > Signed-off-by: Atish Patra > Reviewed-by: Karsten Merker > Tested-by: Karsten Merker (QEMU+OpenSBI+U-Boot) Tested-by: Loys Ollivier
Re: [PATCH v2] pstore: Add boot loader log messages support
On Wed, 15 May 2019 15:04:09 -0700
Kees Cook wrote:
> Hi!
>
> Thanks for the reminder to review this code. :) Sorry for the delay!
>
> On Thu, Feb 14, 2019 at 11:49 PM Yue Hu wrote:
> >
> > From: Yue Hu
> >
> > Sometimes we hope to check boot loader log messages (e.g. Android
> > Verified Boot status) when kernel is coming up. Generally it does
> > depend on serial device, but it will be removed for the hardware
> > shipping to market by most of manufacturers. In that case better
> > solder and proper serial cable for different interface (e.g. Type-C
> > or microUSB) are needed. That is inconvenient and even wasting much
> > time on it.
>
> Can you give some examples of how this would be used on a real device?
> More notes below...
>
> >
> > Therefore, let's add a logging support: PSTORE_TYPE_XBL.
> >
> > Signed-off-by: Yue Hu
> > ---
> > v2: mention info of interacting with boot loader
> >
> > fs/pstore/Kconfig | 10 +++
> > fs/pstore/platform.c | 16 ++
> > fs/pstore/ram.c| 81
> > --
> > include/linux/pstore.h | 21 +
> > 4 files changed, 121 insertions(+), 7 deletions(-)
> >
> > diff --git a/fs/pstore/Kconfig b/fs/pstore/Kconfig
> > index 0d19d19..ef4a2dc 100644
> > --- a/fs/pstore/Kconfig
> > +++ b/fs/pstore/Kconfig
> > @@ -137,6 +137,16 @@ config PSTORE_FTRACE
> >
> > If unsure, say N.
> >
> > +config PSTORE_XBL
> > + bool "Log bootloader messages"
> > + depends on PSTORE
> > + help
> > + When the option is enabled, pstore will log boot loader
> > + messages to /sys/fs/pstore/xbl-ramoops-[ID] after reboot.
> > + Boot loader needs to support log buffer reserved.
> > +
> > + If unsure, say N.
> > +
> > config PSTORE_RAM
> > tristate "Log panic/oops to a RAM buffer"
> > depends on PSTORE
> > diff --git a/fs/pstore/platform.c b/fs/pstore/platform.c
> > index 2d1066e..2e6c3f8f 100644
> > --- a/fs/pstore/platform.c
> > +++ b/fs/pstore/platform.c
> > @@ -65,6 +65,7 @@
> > "mce",
> > "console",
> > "ftrace",
> > + "xbl",
> > "rtas",
> > "powerpc-ofw",
> > "powerpc-common",
> > @@ -530,6 +531,19 @@ static void pstore_register_console(void) {}
> > static void pstore_unregister_console(void) {}
> > #endif
> >
> > +#ifdef CONFIG_PSTORE_XBL
> > +static void pstore_register_xbl(void)
> > +{
> > + struct pstore_record record;
> > +
> > + pstore_record_init(, psinfo);
> > + record.type = PSTORE_TYPE_XBL;
> > + psinfo->write();
> > +}
>
> This seems like a very strange way to get the record: this is an
> "empty" write that has a side-effect of reading the XBL region and
> copying it into the prz area. I would expect this to all happen in
> ramoops_pstore_read() instead.
>
> > +#else
> > +static void pstore_register_xbl(void) {}
> > +#endif
> > +
> > static int pstore_write_user_compat(struct pstore_record *record,
> > const char __user *buf)
> > {
> > @@ -616,6 +630,8 @@ int pstore_register(struct pstore_info *psi)
> > pstore_register_ftrace();
> > if (psi->flags & PSTORE_FLAGS_PMSG)
> > pstore_register_pmsg();
> > + if (psi->flags & PSTORE_FLAGS_XBL)
> > + pstore_register_xbl();
> >
> > /* Start watching for new records, if desired. */
> > if (pstore_update_ms >= 0) {
> > diff --git a/fs/pstore/ram.c b/fs/pstore/ram.c
> > index 1adb5e3..b114b1d 100644
> > --- a/fs/pstore/ram.c
> > +++ b/fs/pstore/ram.c
> > @@ -56,6 +56,27 @@
> > module_param_named(pmsg_size, ramoops_pmsg_size, ulong, 0400);
> > MODULE_PARM_DESC(pmsg_size, "size of user space message log");
>
> How is the base address of the XBL area specified? It looks currently
> like it's up to the end user to do all the math correctly to line it
> up with where it's expected?
>
> >
> > +/*
> > + * interact with boot loader
> > + * =
> > + *
> > + * xbl memory layout:
> > + * ++
> > + * |dst |
> > + * || ++
> > + * |src > | header |
>
Re: [PATCH v2] pstore: Add boot loader log messages support
Hi!
Thanks for the reminder to review this code. :) Sorry for the delay!
On Thu, Feb 14, 2019 at 11:49 PM Yue Hu wrote:
>
> From: Yue Hu
>
> Sometimes we hope to check boot loader log messages (e.g. Android
> Verified Boot status) when kernel is coming up. Generally it does
> depend on serial device, but it will be removed for the hardware
> shipping to market by most of manufacturers. In that case better
> solder and proper serial cable for different interface (e.g. Type-C
> or microUSB) are needed. That is inconvenient and even wasting much
> time on it.
Can you give some examples of how this would be used on a real device?
More notes below...
>
> Therefore, let's add a logging support: PSTORE_TYPE_XBL.
>
> Signed-off-by: Yue Hu
> ---
> v2: mention info of interacting with boot loader
>
> fs/pstore/Kconfig | 10 +++
> fs/pstore/platform.c | 16 ++
> fs/pstore/ram.c| 81
> --
> include/linux/pstore.h | 21 +
> 4 files changed, 121 insertions(+), 7 deletions(-)
>
> diff --git a/fs/pstore/Kconfig b/fs/pstore/Kconfig
> index 0d19d19..ef4a2dc 100644
> --- a/fs/pstore/Kconfig
> +++ b/fs/pstore/Kconfig
> @@ -137,6 +137,16 @@ config PSTORE_FTRACE
>
> If unsure, say N.
>
> +config PSTORE_XBL
> + bool "Log bootloader messages"
> + depends on PSTORE
> + help
> + When the option is enabled, pstore will log boot loader
> + messages to /sys/fs/pstore/xbl-ramoops-[ID] after reboot.
> + Boot loader needs to support log buffer reserved.
> +
> + If unsure, say N.
> +
> config PSTORE_RAM
> tristate "Log panic/oops to a RAM buffer"
> depends on PSTORE
> diff --git a/fs/pstore/platform.c b/fs/pstore/platform.c
> index 2d1066e..2e6c3f8f 100644
> --- a/fs/pstore/platform.c
> +++ b/fs/pstore/platform.c
> @@ -65,6 +65,7 @@
> "mce",
> "console",
> "ftrace",
> + "xbl",
> "rtas",
> "powerpc-ofw",
> "powerpc-common",
> @@ -530,6 +531,19 @@ static void pstore_register_console(void) {}
> static void pstore_unregister_console(void) {}
> #endif
>
> +#ifdef CONFIG_PSTORE_XBL
> +static void pstore_register_xbl(void)
> +{
> + struct pstore_record record;
> +
> + pstore_record_init(, psinfo);
> + record.type = PSTORE_TYPE_XBL;
> + psinfo->write();
> +}
This seems like a very strange way to get the record: this is an
"empty" write that has a side-effect of reading the XBL region and
copying it into the prz area. I would expect this to all happen in
ramoops_pstore_read() instead.
> +#else
> +static void pstore_register_xbl(void) {}
> +#endif
> +
> static int pstore_write_user_compat(struct pstore_record *record,
> const char __user *buf)
> {
> @@ -616,6 +630,8 @@ int pstore_register(struct pstore_info *psi)
> pstore_register_ftrace();
> if (psi->flags & PSTORE_FLAGS_PMSG)
> pstore_register_pmsg();
> + if (psi->flags & PSTORE_FLAGS_XBL)
> + pstore_register_xbl();
>
> /* Start watching for new records, if desired. */
> if (pstore_update_ms >= 0) {
> diff --git a/fs/pstore/ram.c b/fs/pstore/ram.c
> index 1adb5e3..b114b1d 100644
> --- a/fs/pstore/ram.c
> +++ b/fs/pstore/ram.c
> @@ -56,6 +56,27 @@
> module_param_named(pmsg_size, ramoops_pmsg_size, ulong, 0400);
> MODULE_PARM_DESC(pmsg_size, "size of user space message log");
How is the base address of the XBL area specified? It looks currently
like it's up to the end user to do all the math correctly to line it
up with where it's expected?
>
> +/*
> + * interact with boot loader
> + * =
> + *
> + * xbl memory layout:
> + * ++
> + * |dst |
> + * || ++
> + * |src > | header |
> + * ++ |log messages|
> + *++
> + *
> + * As above, src memory is used to store header and log messages generated
> + * by boot loader, pstore will copy the log messages to dst memory which
> + * has same size as src. The header in src is to record log messages size
> + * written and make xbl cookie.
Why is such a copy needed? The log is already present in memory; why
can't pstore just use what's already there?
> + */
> +static ulong ramoops_xbl_size = MIN_MEM_SIZE;
> +module_param_named(xbl_size, ramoops_xbl_size, ulong, 0400);
> +MODULE_PARM_DESC(xbl_size, "size of boot loader log&qu
[PATCH v2 0/6] ktest: support for Boot Loader Specification
From: Masayoshi Mizuma Fedora 30 introduces Boot Loader Specification (BLS) [1], it changes around grub entry configuration. This patch series deals with the new configuration. - Add grub2bls option as REBOOT_TYPE to deal with BLS. - Some cleanup around getting kernel entries. To use ktest.pl to BLS environment, - Set REBOOT_TYPE = grub2bls. - Set POST_INSTALL to add the kernel entry like as follows. POST_INSTALL = ssh root@Test "/usr/bin/kernel-install add \ $KERNEL_VERSION /boot/vmlinuz-$KERNEL_VERSION" - Set POST_KTEST to remove the kernel entry (optional). POST_KTEST = ssh root@Test "/usr/bin/kernel-install remove $KERNEL_VERSION" [1] https://fedoraproject.org/wiki/Changes/BootLoaderSpecByDefault Masayoshi Mizuma (6): ktest: introduce _get_grub_index ktest: cleanup get_grub_index ktest: introduce grub2bls REBOOT_TYPE option ktest: pass KERNEL_VERSION to POST_KTEST ktest: remove get_grub2_index ktest: update sample.conf for grub2bls tools/testing/ktest/ktest.pl| 89 - tools/testing/ktest/sample.conf | 20 +++- 2 files changed, 62 insertions(+), 47 deletions(-) -- 2.20.1
[PATCH 0/5] ktest: support for Boot Loader Specification
From: Masayoshi Mizuma Fedora 30 introduces Boot Loader Specification (BLS) [1], it changes around grub entry configuration. This patchset deals with the new configuration. - Add grub2bls option as REBOOT_TYPE to deal with BLS. - Some cleanup around getting kernel entries. [1] https://fedoraproject.org/wiki/Changes/BootLoaderSpecByDefault Masayoshi Mizuma (5): ktest: introduce _get_grub_index ktest: cleanup get_grub_index ktest: introduce grub2bls REBOOT_TYPE option ktest: remove get_grub2_index ktest: update sample.conf for grub2bls tools/testing/ktest/ktest.pl| 86 +++-- tools/testing/ktest/sample.conf | 10 +++- 2 files changed, 48 insertions(+), 48 deletions(-) -- 2.20.1
Re: [PATCH] RISC-V: Add an Image header that boot loader can parse.
On Wed, May 01, 2019 at 10:41:52PM +0530, Anup Patel wrote:
> On Wed, May 1, 2019 at 10:30 PM Mark Rutland wrote:
> >
> > On Mon, Apr 29, 2019 at 10:42:40PM -0700, Atish Patra wrote:
> > > On 4/29/19 4:40 PM, Palmer Dabbelt wrote:
> > > > On Tue, 23 Apr 2019 16:25:06 PDT (-0700), atish.pa...@wdc.com wrote:
> > > > > Currently, last stage boot loaders such as U-Boot can accept only
> > > > > uImage which is an unnecessary additional step in automating boot
> > > > > flows.
> > > > >
> > > > > Add a simple image header that boot loaders can parse and directly
> > > > > load kernel flat Image. The existing booting methods will continue to
> > > > > work as it is.
> > > > >
> > > > > Tested on both QEMU and HiFive Unleashed using OpenSBI + U-Boot +
> > > > > Linux.
> > > > >
> > > > > Signed-off-by: Atish Patra
> > > > > ---
> > > > > arch/riscv/include/asm/image.h | 32
> > > > > arch/riscv/kernel/head.S | 28
> > > > > 2 files changed, 60 insertions(+)
> > > > > create mode 100644 arch/riscv/include/asm/image.h
> > > > >
> > > > > diff --git a/arch/riscv/include/asm/image.h
> > > > > b/arch/riscv/include/asm/image.h
> > > > > new file mode 100644
> > > > > index ..76a7e0d4068a
> > > > > --- /dev/null
> > > > > +++ b/arch/riscv/include/asm/image.h
> > > > > @@ -0,0 +1,32 @@
> > > > > +/* SPDX-License-Identifier: GPL-2.0 */
> > > > > +
> > > > > +#ifndef __ASM_IMAGE_H
> > > > > +#define __ASM_IMAGE_H
> > > > > +
> > > > > +#define RISCV_IMAGE_MAGIC"RISCV"
> > > > > +
> > > > > +#ifndef __ASSEMBLY__
> > > > > +/*
> > > > > + * struct riscv_image_header - riscv kernel image header
> > > > > + *
> > > > > + * @code0: Executable code
> > > > > + * @code1: Executable code
> > > > > + * @text_offset: Image load offset
> > > > > + * @image_size: Effective Image size
> > > > > + * @reserved:reserved
> > > > > + * @magic: Magic number
> > > > > + * @reserved:reserved
> > > > > + */
> > > > > +
> > > > > +struct riscv_image_header {
> > > > > + u32 code0;
> > > > > + u32 code1;
> > > > > + u64 text_offset;
> > > > > + u64 image_size;
> > > > > + u64 res1;
> > > > > + u64 magic;
> > > > > + u32 res2;
> > > > > + u32 res3;
> > > > > +};
> > > >
> > > > I don't want to invent our own file format. Is there a reason we can't
> > > > just
> > > > use something standard? Off the top of my head I can think of ELF
> > > > files and
> > > > multiboot.
> > >
> > > Additional header is required to accommodate PE header format. Currently,
> > > this is only used for booti command but it will be reused for EFI headers
> > > as
> > > well. Linux kernel Image can pretend as an EFI application if PE/COFF
> > > header
> > > is present. This removes the need of an explicit EFI boot loader and EFI
> > > firmware can directly load Linux (obviously after EFI stub implementation
> > > for RISC-V).
> >
> > Adding the EFI stub on arm64 required very careful consideration of our
> > Image header and the EFI spec, along with the PE/COFF spec.
> >
> > For example, to be a compliant PE/COFF header, the first two bytes of
> > your kernel image need to be "MZ" in ASCII. On arm64 we happened to find
> > a valid instruction that we could rely upon that met this requirement...
>
> The "MZ" ASCII (i.e. 0x5a4d) is "li s4,-13" instruction in RISC-V so this
> modifies "s4" register which is pretty harmless from Linux RISC-V booting
> perspective.
>
> Of course, we should only add "MZ" ASCII in Linux RISC-V image header
> when CONFIG_EFI is enabled (just like Linux ARM64).
Great. It would probably be worth just mentioning that in the commit
message, so that it's clear that has been considered.
Thanks,
Mark.
Re: [PATCH] RISC-V: Add an Image header that boot loader can parse.
On 5/1/19 10:02 AM, Anup Patel wrote:
On Wed, May 1, 2019 at 10:14 PM Karsten Merker wrote:
On Mon, Apr 29, 2019 at 10:42:40PM -0700, Atish Patra wrote:
On 4/29/19 4:40 PM, Palmer Dabbelt wrote:
On Tue, 23 Apr 2019 16:25:06 PDT (-0700), atish.pa...@wdc.com wrote:
Currently, last stage boot loaders such as U-Boot can accept only
uImage which is an unnecessary additional step in automating boot flows.
Add a simple image header that boot loaders can parse and directly
load kernel flat Image. The existing booting methods will continue to
work as it is.
Tested on both QEMU and HiFive Unleashed using OpenSBI + U-Boot + Linux.
Signed-off-by: Atish Patra
---
arch/riscv/include/asm/image.h | 32
arch/riscv/kernel/head.S | 28
2 files changed, 60 insertions(+)
create mode 100644 arch/riscv/include/asm/image.h
diff --git a/arch/riscv/include/asm/image.h b/arch/riscv/include/asm/image.h
new file mode 100644
index ..76a7e0d4068a
--- /dev/null
+++ b/arch/riscv/include/asm/image.h
@@ -0,0 +1,32 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+
+#ifndef __ASM_IMAGE_H
+#define __ASM_IMAGE_H
+
+#define RISCV_IMAGE_MAGIC"RISCV"
+
+#ifndef __ASSEMBLY__
+/*
+ * struct riscv_image_header - riscv kernel image header
+ *
+ * @code0: Executable code
+ * @code1: Executable code
+ * @text_offset: Image load offset
+ * @image_size: Effective Image size
+ * @reserved:reserved
+ * @magic: Magic number
+ * @reserved:reserved
+ */
+
+struct riscv_image_header {
+ u32 code0;
+ u32 code1;
+ u64 text_offset;
+ u64 image_size;
+ u64 res1;
+ u64 magic;
+ u32 res2;
+ u32 res3;
+};
I don't want to invent our own file format. Is there a reason we can't just
use something standard? Off the top of my head I can think of ELF files and
multiboot.
Additional header is required to accommodate PE header format. Currently,
this is only used for booti command but it will be reused for EFI headers as
well. Linux kernel Image can pretend as an EFI application if PE/COFF header
is present. This removes the need of an explicit EFI boot loader and EFI
firmware can directly load Linux (obviously after EFI stub implementation
for RISC-V).
ARM64 follows the similar header format as well.
https://www.kernel.org/doc/Documentation/arm64/booting.txt
Hello Atish,
the arm64 header looks a bit different (quoted from the
aforementioned URL):
u32 code0;/* Executable code */
u32 code1;/* Executable code */
u64 text_offset; /* Image load offset, little endian */
u64 image_size; /* Effective Image size, little endian */
u64 flags;/* kernel flags, little endian */
u64 res2 = 0;/* reserved */
u64 res3 = 0;/* reserved */
u64 res4 = 0;/* reserved */
u32 magic = 0x644d5241; /* Magic number, little endian, "ARM\x64" */
u32 res5; /* reserved (used for PE COFF offset) */
What I am unclear about is in which ways a RISC-V PE/COFF header
differs from an arm64 one as the arm64 struct is longer than your
RISC-V header and for arm64 the PE offset field is in the last
field, i.e. outside of the area covered by your RISC-V structure
definition. Can you perhaps explain this part in a bit more
detail or does anybody else have a pointer to a specification of
the RISC-V PE/COFF header format (I have found a lot of documents
about COFF in general, but nothing specific to RISC-V).
Karsten,
The only difference compared to ARM64 is the values of code0, code1
and res5 fields.
As-per PE/COFF, the 32bit value at offset 0x3c tells us offset of PE/COFF
header in image.
For more details refer,
https://en.wikipedia.org/wiki/Portable_Executable
https://en.wikipedia.org/wiki/Portable_Executable#/media/File:Portable_Executable_32_bit_Structure_in_SVG_fixed.svg
For both ARM64 header and RISC-V image header, is actually the
"DOS header" part of PE/COFF format.
This patch only adds "DOS header" part of PE/COFF format. Rest of
the PE/COFF header will be added when add EFI support to Linux
RISC-V kernel.
I think Anup answered your question. The original plan was to add EFI
specific stuff in EFI support patch. That includes adjusting the PE/COFF
offset at 0x3c and adding the "MZ" value for code0 if EFI is enabled.
In hindsight, I think it created more confusion. I will update the
"riscv_image_header" structure to put PE/COFF offset(0x3c) at right
place in v2 patch to avoid further confusion.
"MZ" value part should be added once EFI is enabled.
I will update the comments on riscv/include/asm/image.h as well to
clarify more.
Regards,
Atish
Regards,
Anup
Re: [PATCH] RISC-V: Add an Image header that boot loader can parse.
On Wed, May 1, 2019 at 10:30 PM Mark Rutland wrote:
>
> On Mon, Apr 29, 2019 at 10:42:40PM -0700, Atish Patra wrote:
> > On 4/29/19 4:40 PM, Palmer Dabbelt wrote:
> > > On Tue, 23 Apr 2019 16:25:06 PDT (-0700), atish.pa...@wdc.com wrote:
> > > > Currently, last stage boot loaders such as U-Boot can accept only
> > > > uImage which is an unnecessary additional step in automating boot flows.
> > > >
> > > > Add a simple image header that boot loaders can parse and directly
> > > > load kernel flat Image. The existing booting methods will continue to
> > > > work as it is.
> > > >
> > > > Tested on both QEMU and HiFive Unleashed using OpenSBI + U-Boot + Linux.
> > > >
> > > > Signed-off-by: Atish Patra
> > > > ---
> > > > arch/riscv/include/asm/image.h | 32
> > > > arch/riscv/kernel/head.S | 28
> > > > 2 files changed, 60 insertions(+)
> > > > create mode 100644 arch/riscv/include/asm/image.h
> > > >
> > > > diff --git a/arch/riscv/include/asm/image.h
> > > > b/arch/riscv/include/asm/image.h
> > > > new file mode 100644
> > > > index ..76a7e0d4068a
> > > > --- /dev/null
> > > > +++ b/arch/riscv/include/asm/image.h
> > > > @@ -0,0 +1,32 @@
> > > > +/* SPDX-License-Identifier: GPL-2.0 */
> > > > +
> > > > +#ifndef __ASM_IMAGE_H
> > > > +#define __ASM_IMAGE_H
> > > > +
> > > > +#define RISCV_IMAGE_MAGIC"RISCV"
> > > > +
> > > > +#ifndef __ASSEMBLY__
> > > > +/*
> > > > + * struct riscv_image_header - riscv kernel image header
> > > > + *
> > > > + * @code0: Executable code
> > > > + * @code1: Executable code
> > > > + * @text_offset: Image load offset
> > > > + * @image_size: Effective Image size
> > > > + * @reserved:reserved
> > > > + * @magic: Magic number
> > > > + * @reserved:reserved
> > > > + */
> > > > +
> > > > +struct riscv_image_header {
> > > > + u32 code0;
> > > > + u32 code1;
> > > > + u64 text_offset;
> > > > + u64 image_size;
> > > > + u64 res1;
> > > > + u64 magic;
> > > > + u32 res2;
> > > > + u32 res3;
> > > > +};
> > >
> > > I don't want to invent our own file format. Is there a reason we can't
> > > just
> > > use something standard? Off the top of my head I can think of ELF files
> > > and
> > > multiboot.
> >
> > Additional header is required to accommodate PE header format. Currently,
> > this is only used for booti command but it will be reused for EFI headers as
> > well. Linux kernel Image can pretend as an EFI application if PE/COFF header
> > is present. This removes the need of an explicit EFI boot loader and EFI
> > firmware can directly load Linux (obviously after EFI stub implementation
> > for RISC-V).
>
> Adding the EFI stub on arm64 required very careful consideration of our
> Image header and the EFI spec, along with the PE/COFF spec.
>
> For example, to be a compliant PE/COFF header, the first two bytes of
> your kernel image need to be "MZ" in ASCII. On arm64 we happened to find
> a valid instruction that we could rely upon that met this requirement...
The "MZ" ASCII (i.e. 0x5a4d) is "li s4,-13" instruction in RISC-V so this
modifies "s4" register which is pretty harmless from Linux RISC-V booting
perspective.
Of course, we should only add "MZ" ASCII in Linux RISC-V image header
when CONFIG_EFI is enabled (just like Linux ARM64).
>
> > > > __INIT
> > > > ENTRY(_start)
> > > > + /*
> > > > + * Image header expected by Linux boot-loaders. The image header data
> > > > + * structure is described in asm/image.h.
> > > > + * Do not modify it without modifying the structure and all
> > > > bootloaders
> > > > + * that expects this header format!!
> > > > + */
> > > > + /* jump to start kernel */
> > > > + j _start_kernel
>
> ... but it's not clear to me if this instruction meets that requriement.
>
> I would strongly encourage you to consider what you actually need for a
> compliant EFI header before you set the rest of this ABI in stone.
>
> On arm64 we also had issues with endianness, and I would strongly
> recommend that you define how big/little endian will work ahead of time.
> e.g. whether fields are always in a fixed endianness.
As of now RISC-V is little-endian but if big-endian show-up in-future
then we should consider endianness issue.
Regards,
Anup
Re: [PATCH] RISC-V: Add an Image header that boot loader can parse.
On Wed, May 1, 2019 at 10:14 PM Karsten Merker wrote:
>
> On Mon, Apr 29, 2019 at 10:42:40PM -0700, Atish Patra wrote:
> > On 4/29/19 4:40 PM, Palmer Dabbelt wrote:
> > > On Tue, 23 Apr 2019 16:25:06 PDT (-0700), atish.pa...@wdc.com wrote:
> > > > Currently, last stage boot loaders such as U-Boot can accept only
> > > > uImage which is an unnecessary additional step in automating boot flows.
> > > >
> > > > Add a simple image header that boot loaders can parse and directly
> > > > load kernel flat Image. The existing booting methods will continue to
> > > > work as it is.
> > > >
> > > > Tested on both QEMU and HiFive Unleashed using OpenSBI + U-Boot + Linux.
> > > >
> > > > Signed-off-by: Atish Patra
> > > > ---
> > > > arch/riscv/include/asm/image.h | 32
> > > > arch/riscv/kernel/head.S | 28
> > > > 2 files changed, 60 insertions(+)
> > > > create mode 100644 arch/riscv/include/asm/image.h
> > > >
> > > > diff --git a/arch/riscv/include/asm/image.h
> > > > b/arch/riscv/include/asm/image.h
> > > > new file mode 100644
> > > > index ..76a7e0d4068a
> > > > --- /dev/null
> > > > +++ b/arch/riscv/include/asm/image.h
> > > > @@ -0,0 +1,32 @@
> > > > +/* SPDX-License-Identifier: GPL-2.0 */
> > > > +
> > > > +#ifndef __ASM_IMAGE_H
> > > > +#define __ASM_IMAGE_H
> > > > +
> > > > +#define RISCV_IMAGE_MAGIC"RISCV"
> > > > +
> > > > +#ifndef __ASSEMBLY__
> > > > +/*
> > > > + * struct riscv_image_header - riscv kernel image header
> > > > + *
> > > > + * @code0: Executable code
> > > > + * @code1: Executable code
> > > > + * @text_offset: Image load offset
> > > > + * @image_size: Effective Image size
> > > > + * @reserved:reserved
> > > > + * @magic: Magic number
> > > > + * @reserved:reserved
> > > > + */
> > > > +
> > > > +struct riscv_image_header {
> > > > + u32 code0;
> > > > + u32 code1;
> > > > + u64 text_offset;
> > > > + u64 image_size;
> > > > + u64 res1;
> > > > + u64 magic;
> > > > + u32 res2;
> > > > + u32 res3;
> > > > +};
> > >
> > > I don't want to invent our own file format. Is there a reason we can't
> > > just
> > > use something standard? Off the top of my head I can think of ELF files
> > > and
> > > multiboot.
> >
> > Additional header is required to accommodate PE header format. Currently,
> > this is only used for booti command but it will be reused for EFI headers as
> > well. Linux kernel Image can pretend as an EFI application if PE/COFF header
> > is present. This removes the need of an explicit EFI boot loader and EFI
> > firmware can directly load Linux (obviously after EFI stub implementation
> > for RISC-V).
> >
> > ARM64 follows the similar header format as well.
> > https://www.kernel.org/doc/Documentation/arm64/booting.txt
>
> Hello Atish,
>
> the arm64 header looks a bit different (quoted from the
> aforementioned URL):
>
> u32 code0;/* Executable code */
> u32 code1;/* Executable code */
> u64 text_offset; /* Image load offset, little endian */
> u64 image_size; /* Effective Image size, little endian */
> u64 flags;/* kernel flags, little endian */
> u64 res2 = 0;/* reserved */
> u64 res3 = 0;/* reserved */
> u64 res4 = 0;/* reserved */
> u32 magic = 0x644d5241; /* Magic number, little endian, "ARM\x64" */
> u32 res5; /* reserved (used for PE COFF offset) */
>
> What I am unclear about is in which ways a RISC-V PE/COFF header
> differs from an arm64 one as the arm64 struct is longer than your
> RISC-V header and for arm64 the PE offset field is in the last
> field, i.e. outside of the area covered by your RISC-V structure
> definition. Can you perhaps explain this part in a bit more
> detail or does anybody else have a pointer to a specification of
> the RISC-V PE/COFF header format (I have found a lot of documents
> about COFF in general, but nothing specific to RISC-V).
The only difference compared to ARM64 is the values of code0, code1
and res5 fields.
As-per PE/COFF, the 32bit value at offset 0x3c tells us offset of PE/COFF
header in image.
For more details refer,
https://en.wikipedia.org/wiki/Portable_Executable
https://en.wikipedia.org/wiki/Portable_Executable#/media/File:Portable_Executable_32_bit_Structure_in_SVG_fixed.svg
For both ARM64 header and RISC-V image header, is actually the
"DOS header" part of PE/COFF format.
This patch only adds "DOS header" part of PE/COFF format. Rest of
the PE/COFF header will be added when add EFI support to Linux
RISC-V kernel.
Regards,
Anup
Re: [PATCH] RISC-V: Add an Image header that boot loader can parse.
On Mon, Apr 29, 2019 at 10:42:40PM -0700, Atish Patra wrote:
> On 4/29/19 4:40 PM, Palmer Dabbelt wrote:
> > On Tue, 23 Apr 2019 16:25:06 PDT (-0700), atish.pa...@wdc.com wrote:
> > > Currently, last stage boot loaders such as U-Boot can accept only
> > > uImage which is an unnecessary additional step in automating boot flows.
> > >
> > > Add a simple image header that boot loaders can parse and directly
> > > load kernel flat Image. The existing booting methods will continue to
> > > work as it is.
> > >
> > > Tested on both QEMU and HiFive Unleashed using OpenSBI + U-Boot + Linux.
> > >
> > > Signed-off-by: Atish Patra
> > > ---
> > > arch/riscv/include/asm/image.h | 32
> > > arch/riscv/kernel/head.S | 28
> > > 2 files changed, 60 insertions(+)
> > > create mode 100644 arch/riscv/include/asm/image.h
> > >
> > > diff --git a/arch/riscv/include/asm/image.h
> > > b/arch/riscv/include/asm/image.h
> > > new file mode 100644
> > > index ..76a7e0d4068a
> > > --- /dev/null
> > > +++ b/arch/riscv/include/asm/image.h
> > > @@ -0,0 +1,32 @@
> > > +/* SPDX-License-Identifier: GPL-2.0 */
> > > +
> > > +#ifndef __ASM_IMAGE_H
> > > +#define __ASM_IMAGE_H
> > > +
> > > +#define RISCV_IMAGE_MAGIC"RISCV"
> > > +
> > > +#ifndef __ASSEMBLY__
> > > +/*
> > > + * struct riscv_image_header - riscv kernel image header
> > > + *
> > > + * @code0: Executable code
> > > + * @code1: Executable code
> > > + * @text_offset: Image load offset
> > > + * @image_size: Effective Image size
> > > + * @reserved:reserved
> > > + * @magic: Magic number
> > > + * @reserved:reserved
> > > + */
> > > +
> > > +struct riscv_image_header {
> > > + u32 code0;
> > > + u32 code1;
> > > + u64 text_offset;
> > > + u64 image_size;
> > > + u64 res1;
> > > + u64 magic;
> > > + u32 res2;
> > > + u32 res3;
> > > +};
> >
> > I don't want to invent our own file format. Is there a reason we can't just
> > use something standard? Off the top of my head I can think of ELF files and
> > multiboot.
>
> Additional header is required to accommodate PE header format. Currently,
> this is only used for booti command but it will be reused for EFI headers as
> well. Linux kernel Image can pretend as an EFI application if PE/COFF header
> is present. This removes the need of an explicit EFI boot loader and EFI
> firmware can directly load Linux (obviously after EFI stub implementation
> for RISC-V).
Adding the EFI stub on arm64 required very careful consideration of our
Image header and the EFI spec, along with the PE/COFF spec.
For example, to be a compliant PE/COFF header, the first two bytes of
your kernel image need to be "MZ" in ASCII. On arm64 we happened to find
a valid instruction that we could rely upon that met this requirement...
> > > __INIT
> > > ENTRY(_start)
> > > + /*
> > > + * Image header expected by Linux boot-loaders. The image header data
> > > + * structure is described in asm/image.h.
> > > + * Do not modify it without modifying the structure and all bootloaders
> > > + * that expects this header format!!
> > > + */
> > > + /* jump to start kernel */
> > > + j _start_kernel
... but it's not clear to me if this instruction meets that requriement.
I would strongly encourage you to consider what you actually need for a
compliant EFI header before you set the rest of this ABI in stone.
On arm64 we also had issues with endianness, and I would strongly
recommend that you define how big/little endian will work ahead of time.
e.g. whether fields are always in a fixed endianness.
Thanks,
Mark.
Re: [PATCH] RISC-V: Add an Image header that boot loader can parse.
On Mon, Apr 29, 2019 at 10:42:40PM -0700, Atish Patra wrote:
> On 4/29/19 4:40 PM, Palmer Dabbelt wrote:
> > On Tue, 23 Apr 2019 16:25:06 PDT (-0700), atish.pa...@wdc.com wrote:
> > > Currently, last stage boot loaders such as U-Boot can accept only
> > > uImage which is an unnecessary additional step in automating boot flows.
> > >
> > > Add a simple image header that boot loaders can parse and directly
> > > load kernel flat Image. The existing booting methods will continue to
> > > work as it is.
> > >
> > > Tested on both QEMU and HiFive Unleashed using OpenSBI + U-Boot + Linux.
> > >
> > > Signed-off-by: Atish Patra
> > > ---
> > > arch/riscv/include/asm/image.h | 32
> > > arch/riscv/kernel/head.S | 28
> > > 2 files changed, 60 insertions(+)
> > > create mode 100644 arch/riscv/include/asm/image.h
> > >
> > > diff --git a/arch/riscv/include/asm/image.h
> > > b/arch/riscv/include/asm/image.h
> > > new file mode 100644
> > > index ..76a7e0d4068a
> > > --- /dev/null
> > > +++ b/arch/riscv/include/asm/image.h
> > > @@ -0,0 +1,32 @@
> > > +/* SPDX-License-Identifier: GPL-2.0 */
> > > +
> > > +#ifndef __ASM_IMAGE_H
> > > +#define __ASM_IMAGE_H
> > > +
> > > +#define RISCV_IMAGE_MAGIC"RISCV"
> > > +
> > > +#ifndef __ASSEMBLY__
> > > +/*
> > > + * struct riscv_image_header - riscv kernel image header
> > > + *
> > > + * @code0: Executable code
> > > + * @code1: Executable code
> > > + * @text_offset: Image load offset
> > > + * @image_size: Effective Image size
> > > + * @reserved:reserved
> > > + * @magic: Magic number
> > > + * @reserved:reserved
> > > + */
> > > +
> > > +struct riscv_image_header {
> > > + u32 code0;
> > > + u32 code1;
> > > + u64 text_offset;
> > > + u64 image_size;
> > > + u64 res1;
> > > + u64 magic;
> > > + u32 res2;
> > > + u32 res3;
> > > +};
> >
> > I don't want to invent our own file format. Is there a reason we can't just
> > use something standard? Off the top of my head I can think of ELF files and
> > multiboot.
>
> Additional header is required to accommodate PE header format. Currently,
> this is only used for booti command but it will be reused for EFI headers as
> well. Linux kernel Image can pretend as an EFI application if PE/COFF header
> is present. This removes the need of an explicit EFI boot loader and EFI
> firmware can directly load Linux (obviously after EFI stub implementation
> for RISC-V).
>
> ARM64 follows the similar header format as well.
> https://www.kernel.org/doc/Documentation/arm64/booting.txt
Hello Atish,
the arm64 header looks a bit different (quoted from the
aforementioned URL):
u32 code0;/* Executable code */
u32 code1;/* Executable code */
u64 text_offset; /* Image load offset, little endian */
u64 image_size; /* Effective Image size, little endian */
u64 flags;/* kernel flags, little endian */
u64 res2 = 0;/* reserved */
u64 res3 = 0;/* reserved */
u64 res4 = 0;/* reserved */
u32 magic = 0x644d5241; /* Magic number, little endian, "ARM\x64" */
u32 res5; /* reserved (used for PE COFF offset) */
What I am unclear about is in which ways a RISC-V PE/COFF header
differs from an arm64 one as the arm64 struct is longer than your
RISC-V header and for arm64 the PE offset field is in the last
field, i.e. outside of the area covered by your RISC-V structure
definition. Can you perhaps explain this part in a bit more
detail or does anybody else have a pointer to a specification of
the RISC-V PE/COFF header format (I have found a lot of documents
about COFF in general, but nothing specific to RISC-V).
Regards,
Karsten
--
Ich widerspreche hiermit ausdrücklich der Nutzung sowie der
Weitergabe meiner personenbezogenen Daten für Zwecke der Werbung
sowie der Markt- oder Meinungsforschung.
Re: [PATCH] RISC-V: Add an Image header that boot loader can parse.
On 4/29/19 4:40 PM, Palmer Dabbelt wrote:
On Tue, 23 Apr 2019 16:25:06 PDT (-0700), atish.pa...@wdc.com wrote:
Currently, last stage boot loaders such as U-Boot can accept only
uImage which is an unnecessary additional step in automating boot flows.
Add a simple image header that boot loaders can parse and directly
load kernel flat Image. The existing booting methods will continue to
work as it is.
Tested on both QEMU and HiFive Unleashed using OpenSBI + U-Boot + Linux.
Signed-off-by: Atish Patra
---
arch/riscv/include/asm/image.h | 32
arch/riscv/kernel/head.S | 28
2 files changed, 60 insertions(+)
create mode 100644 arch/riscv/include/asm/image.h
diff --git a/arch/riscv/include/asm/image.h b/arch/riscv/include/asm/image.h
new file mode 100644
index ..76a7e0d4068a
--- /dev/null
+++ b/arch/riscv/include/asm/image.h
@@ -0,0 +1,32 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+
+#ifndef __ASM_IMAGE_H
+#define __ASM_IMAGE_H
+
+#define RISCV_IMAGE_MAGIC "RISCV"
+
+#ifndef __ASSEMBLY__
+/*
+ * struct riscv_image_header - riscv kernel image header
+ *
+ * @code0: Executable code
+ * @code1: Executable code
+ * @text_offset: Image load offset
+ * @image_size:Effective Image size
+ * @reserved: reserved
+ * @magic: Magic number
+ * @reserved: reserved
+ */
+
+struct riscv_image_header {
+ u32 code0;
+ u32 code1;
+ u64 text_offset;
+ u64 image_size;
+ u64 res1;
+ u64 magic;
+ u32 res2;
+ u32 res3;
+};
I don't want to invent our own file format. Is there a reason we can't just
use something standard? Off the top of my head I can think of ELF files and
multiboot.
Additional header is required to accommodate PE header format.
Currently, this is only used for booti command but it will be reused for
EFI headers as well. Linux kernel Image can pretend as an EFI
application if PE/COFF header is present. This removes the need of an
explicit EFI boot loader and EFI firmware can directly load Linux
(obviously after EFI stub implementation for RISC-V).
ARM64 follows the similar header format as well.
https://www.kernel.org/doc/Documentation/arm64/booting.txt
Regards,
Atish
+#endif /* __ASSEMBLY__ */
+#endif /* __ASM_IMAGE_H */
diff --git a/arch/riscv/kernel/head.S b/arch/riscv/kernel/head.S
index fe884cd69abd..154647395601 100644
--- a/arch/riscv/kernel/head.S
+++ b/arch/riscv/kernel/head.S
@@ -19,9 +19,37 @@
#include
#include
#include
+#include
__INIT
ENTRY(_start)
+ /*
+* Image header expected by Linux boot-loaders. The image header data
+* structure is described in asm/image.h.
+* Do not modify it without modifying the structure and all bootloaders
+* that expects this header format!!
+*/
+ /* jump to start kernel */
+ j _start_kernel
+ /* reserved */
+ .word 0
+ .balign 8
+#if __riscv_xlen == 64
+ /* Image load offset(2MB) from start of RAM */
+ .dword 0x20
+#else
+ /* Image load offset(4MB) from start of RAM */
+ .dword 0x40
+#endif
+ /* Effective size of kernel image */
+ .dword _end - _start
+ .dword 0
+ .asciz RISCV_IMAGE_MAGIC
+ .word 0
+ .word 0
+
+.global _start_kernel
+_start_kernel:
/* Mask all interrupts */
csrw sie, zero
___
linux-riscv mailing list
linux-ri...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
Re: [PATCH] RISC-V: Add an Image header that boot loader can parse.
On Tue, 23 Apr 2019 16:25:06 PDT (-0700), atish.pa...@wdc.com wrote:
Currently, last stage boot loaders such as U-Boot can accept only
uImage which is an unnecessary additional step in automating boot flows.
Add a simple image header that boot loaders can parse and directly
load kernel flat Image. The existing booting methods will continue to
work as it is.
Tested on both QEMU and HiFive Unleashed using OpenSBI + U-Boot + Linux.
Signed-off-by: Atish Patra
---
arch/riscv/include/asm/image.h | 32
arch/riscv/kernel/head.S | 28
2 files changed, 60 insertions(+)
create mode 100644 arch/riscv/include/asm/image.h
diff --git a/arch/riscv/include/asm/image.h b/arch/riscv/include/asm/image.h
new file mode 100644
index ..76a7e0d4068a
--- /dev/null
+++ b/arch/riscv/include/asm/image.h
@@ -0,0 +1,32 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+
+#ifndef __ASM_IMAGE_H
+#define __ASM_IMAGE_H
+
+#define RISCV_IMAGE_MAGIC "RISCV"
+
+#ifndef __ASSEMBLY__
+/*
+ * struct riscv_image_header - riscv kernel image header
+ *
+ * @code0: Executable code
+ * @code1: Executable code
+ * @text_offset: Image load offset
+ * @image_size:Effective Image size
+ * @reserved: reserved
+ * @magic: Magic number
+ * @reserved: reserved
+ */
+
+struct riscv_image_header {
+ u32 code0;
+ u32 code1;
+ u64 text_offset;
+ u64 image_size;
+ u64 res1;
+ u64 magic;
+ u32 res2;
+ u32 res3;
+};
I don't want to invent our own file format. Is there a reason we can't just
use something standard? Off the top of my head I can think of ELF files and
multiboot.
+#endif /* __ASSEMBLY__ */
+#endif /* __ASM_IMAGE_H */
diff --git a/arch/riscv/kernel/head.S b/arch/riscv/kernel/head.S
index fe884cd69abd..154647395601 100644
--- a/arch/riscv/kernel/head.S
+++ b/arch/riscv/kernel/head.S
@@ -19,9 +19,37 @@
#include
#include
#include
+#include
__INIT
ENTRY(_start)
+ /*
+* Image header expected by Linux boot-loaders. The image header data
+* structure is described in asm/image.h.
+* Do not modify it without modifying the structure and all bootloaders
+* that expects this header format!!
+*/
+ /* jump to start kernel */
+ j _start_kernel
+ /* reserved */
+ .word 0
+ .balign 8
+#if __riscv_xlen == 64
+ /* Image load offset(2MB) from start of RAM */
+ .dword 0x20
+#else
+ /* Image load offset(4MB) from start of RAM */
+ .dword 0x40
+#endif
+ /* Effective size of kernel image */
+ .dword _end - _start
+ .dword 0
+ .asciz RISCV_IMAGE_MAGIC
+ .word 0
+ .word 0
+
+.global _start_kernel
+_start_kernel:
/* Mask all interrupts */
csrw sie, zero
[PATCH] RISC-V: Add an Image header that boot loader can parse.
Currently, last stage boot loaders such as U-Boot can accept only
uImage which is an unnecessary additional step in automating boot flows.
Add a simple image header that boot loaders can parse and directly
load kernel flat Image. The existing booting methods will continue to
work as it is.
Tested on both QEMU and HiFive Unleashed using OpenSBI + U-Boot + Linux.
Signed-off-by: Atish Patra
---
arch/riscv/include/asm/image.h | 32
arch/riscv/kernel/head.S | 28
2 files changed, 60 insertions(+)
create mode 100644 arch/riscv/include/asm/image.h
diff --git a/arch/riscv/include/asm/image.h b/arch/riscv/include/asm/image.h
new file mode 100644
index ..76a7e0d4068a
--- /dev/null
+++ b/arch/riscv/include/asm/image.h
@@ -0,0 +1,32 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+
+#ifndef __ASM_IMAGE_H
+#define __ASM_IMAGE_H
+
+#define RISCV_IMAGE_MAGIC "RISCV"
+
+#ifndef __ASSEMBLY__
+/*
+ * struct riscv_image_header - riscv kernel image header
+ *
+ * @code0: Executable code
+ * @code1: Executable code
+ * @text_offset: Image load offset
+ * @image_size:Effective Image size
+ * @reserved: reserved
+ * @magic: Magic number
+ * @reserved: reserved
+ */
+
+struct riscv_image_header {
+ u32 code0;
+ u32 code1;
+ u64 text_offset;
+ u64 image_size;
+ u64 res1;
+ u64 magic;
+ u32 res2;
+ u32 res3;
+};
+#endif /* __ASSEMBLY__ */
+#endif /* __ASM_IMAGE_H */
diff --git a/arch/riscv/kernel/head.S b/arch/riscv/kernel/head.S
index fe884cd69abd..154647395601 100644
--- a/arch/riscv/kernel/head.S
+++ b/arch/riscv/kernel/head.S
@@ -19,9 +19,37 @@
#include
#include
#include
+#include
__INIT
ENTRY(_start)
+ /*
+* Image header expected by Linux boot-loaders. The image header data
+* structure is described in asm/image.h.
+* Do not modify it without modifying the structure and all bootloaders
+* that expects this header format!!
+*/
+ /* jump to start kernel */
+ j _start_kernel
+ /* reserved */
+ .word 0
+ .balign 8
+#if __riscv_xlen == 64
+ /* Image load offset(2MB) from start of RAM */
+ .dword 0x20
+#else
+ /* Image load offset(4MB) from start of RAM */
+ .dword 0x40
+#endif
+ /* Effective size of kernel image */
+ .dword _end - _start
+ .dword 0
+ .asciz RISCV_IMAGE_MAGIC
+ .word 0
+ .word 0
+
+.global _start_kernel
+_start_kernel:
/* Mask all interrupts */
csrw sie, zero
--
2.21.0
[PATCH 5.0 121/238] ext4: update quota information while swapping boot loader inode
5.0-stable review patch. If anyone has any objections, please let me know.
--
From: yangerkun
commit aa507b5faf38784defe49f5e64605ac3c4425e26 upstream.
While do swap between two inode, they swap i_data without update
quota information. Also, swap_inode_boot_loader can do "revert"
somtimes, so update the quota while all operations has been finished.
Signed-off-by: yangerkun
Signed-off-by: Theodore Ts'o
Cc: sta...@kernel.org
Signed-off-by: Greg Kroah-Hartman
---
fs/ext4/ioctl.c | 56 +++-
1 file changed, 43 insertions(+), 13 deletions(-)
--- a/fs/ext4/ioctl.c
+++ b/fs/ext4/ioctl.c
@@ -68,8 +68,6 @@ static void swap_inode_data(struct inode
ei2 = EXT4_I(inode2);
swap(inode1->i_version, inode2->i_version);
- swap(inode1->i_blocks, inode2->i_blocks);
- swap(inode1->i_bytes, inode2->i_bytes);
swap(inode1->i_atime, inode2->i_atime);
swap(inode1->i_mtime, inode2->i_mtime);
@@ -115,6 +113,9 @@ static long swap_inode_boot_loader(struc
int err;
struct inode *inode_bl;
struct ext4_inode_info *ei_bl;
+ qsize_t size, size_bl, diff;
+ blkcnt_t blocks;
+ unsigned short bytes;
inode_bl = ext4_iget(sb, EXT4_BOOT_LOADER_INO, EXT4_IGET_SPECIAL);
if (IS_ERR(inode_bl))
@@ -180,6 +181,13 @@ static long swap_inode_boot_loader(struc
memset(ei_bl->i_data, 0, sizeof(ei_bl->i_data));
}
+ err = dquot_initialize(inode);
+ if (err)
+ goto err_out1;
+
+ size = (qsize_t)(inode->i_blocks) * (1 << 9) + inode->i_bytes;
+ size_bl = (qsize_t)(inode_bl->i_blocks) * (1 << 9) + inode_bl->i_bytes;
+ diff = size - size_bl;
swap_inode_data(inode, inode_bl);
inode->i_ctime = inode_bl->i_ctime = current_time(inode);
@@ -193,24 +201,46 @@ static long swap_inode_boot_loader(struc
err = ext4_mark_inode_dirty(handle, inode);
if (err < 0) {
+ /* No need to update quota information. */
ext4_warning(inode->i_sb,
"couldn't mark inode #%lu dirty (err %d)",
inode->i_ino, err);
/* Revert all changes: */
swap_inode_data(inode, inode_bl);
ext4_mark_inode_dirty(handle, inode);
- } else {
- err = ext4_mark_inode_dirty(handle, inode_bl);
- if (err < 0) {
- ext4_warning(inode_bl->i_sb,
- "couldn't mark inode #%lu dirty (err %d)",
- inode_bl->i_ino, err);
- /* Revert all changes: */
- swap_inode_data(inode, inode_bl);
- ext4_mark_inode_dirty(handle, inode);
- ext4_mark_inode_dirty(handle, inode_bl);
- }
+ goto err_out1;
+ }
+
+ blocks = inode_bl->i_blocks;
+ bytes = inode_bl->i_bytes;
+ inode_bl->i_blocks = inode->i_blocks;
+ inode_bl->i_bytes = inode->i_bytes;
+ err = ext4_mark_inode_dirty(handle, inode_bl);
+ if (err < 0) {
+ /* No need to update quota information. */
+ ext4_warning(inode_bl->i_sb,
+ "couldn't mark inode #%lu dirty (err %d)",
+ inode_bl->i_ino, err);
+ goto revert;
+ }
+
+ /* Bootloader inode should not be counted into quota information. */
+ if (diff > 0)
+ dquot_free_space(inode, diff);
+ else
+ err = dquot_alloc_space(inode, -1 * diff);
+
+ if (err < 0) {
+revert:
+ /* Revert all changes: */
+ inode_bl->i_blocks = blocks;
+ inode_bl->i_bytes = bytes;
+ swap_inode_data(inode, inode_bl);
+ ext4_mark_inode_dirty(handle, inode);
+ ext4_mark_inode_dirty(handle, inode_bl);
}
+
+err_out1:
ext4_journal_stop(handle);
ext4_double_up_write_data_sem(inode, inode_bl);
[PATCH 4.19 182/280] ext4: update quota information while swapping boot loader inode
4.19-stable review patch. If anyone has any objections, please let me know.
--
From: yangerkun
commit aa507b5faf38784defe49f5e64605ac3c4425e26 upstream.
While do swap between two inode, they swap i_data without update
quota information. Also, swap_inode_boot_loader can do "revert"
somtimes, so update the quota while all operations has been finished.
Signed-off-by: yangerkun
Signed-off-by: Theodore Ts'o
Cc: sta...@kernel.org
Signed-off-by: Greg Kroah-Hartman
---
fs/ext4/ioctl.c | 56 +++-
1 file changed, 43 insertions(+), 13 deletions(-)
--- a/fs/ext4/ioctl.c
+++ b/fs/ext4/ioctl.c
@@ -68,8 +68,6 @@ static void swap_inode_data(struct inode
ei2 = EXT4_I(inode2);
swap(inode1->i_version, inode2->i_version);
- swap(inode1->i_blocks, inode2->i_blocks);
- swap(inode1->i_bytes, inode2->i_bytes);
swap(inode1->i_atime, inode2->i_atime);
swap(inode1->i_mtime, inode2->i_mtime);
@@ -115,6 +113,9 @@ static long swap_inode_boot_loader(struc
int err;
struct inode *inode_bl;
struct ext4_inode_info *ei_bl;
+ qsize_t size, size_bl, diff;
+ blkcnt_t blocks;
+ unsigned short bytes;
inode_bl = ext4_iget(sb, EXT4_BOOT_LOADER_INO, EXT4_IGET_SPECIAL);
if (IS_ERR(inode_bl))
@@ -180,6 +181,13 @@ static long swap_inode_boot_loader(struc
memset(ei_bl->i_data, 0, sizeof(ei_bl->i_data));
}
+ err = dquot_initialize(inode);
+ if (err)
+ goto err_out1;
+
+ size = (qsize_t)(inode->i_blocks) * (1 << 9) + inode->i_bytes;
+ size_bl = (qsize_t)(inode_bl->i_blocks) * (1 << 9) + inode_bl->i_bytes;
+ diff = size - size_bl;
swap_inode_data(inode, inode_bl);
inode->i_ctime = inode_bl->i_ctime = current_time(inode);
@@ -193,24 +201,46 @@ static long swap_inode_boot_loader(struc
err = ext4_mark_inode_dirty(handle, inode);
if (err < 0) {
+ /* No need to update quota information. */
ext4_warning(inode->i_sb,
"couldn't mark inode #%lu dirty (err %d)",
inode->i_ino, err);
/* Revert all changes: */
swap_inode_data(inode, inode_bl);
ext4_mark_inode_dirty(handle, inode);
- } else {
- err = ext4_mark_inode_dirty(handle, inode_bl);
- if (err < 0) {
- ext4_warning(inode_bl->i_sb,
- "couldn't mark inode #%lu dirty (err %d)",
- inode_bl->i_ino, err);
- /* Revert all changes: */
- swap_inode_data(inode, inode_bl);
- ext4_mark_inode_dirty(handle, inode);
- ext4_mark_inode_dirty(handle, inode_bl);
- }
+ goto err_out1;
+ }
+
+ blocks = inode_bl->i_blocks;
+ bytes = inode_bl->i_bytes;
+ inode_bl->i_blocks = inode->i_blocks;
+ inode_bl->i_bytes = inode->i_bytes;
+ err = ext4_mark_inode_dirty(handle, inode_bl);
+ if (err < 0) {
+ /* No need to update quota information. */
+ ext4_warning(inode_bl->i_sb,
+ "couldn't mark inode #%lu dirty (err %d)",
+ inode_bl->i_ino, err);
+ goto revert;
+ }
+
+ /* Bootloader inode should not be counted into quota information. */
+ if (diff > 0)
+ dquot_free_space(inode, diff);
+ else
+ err = dquot_alloc_space(inode, -1 * diff);
+
+ if (err < 0) {
+revert:
+ /* Revert all changes: */
+ inode_bl->i_blocks = blocks;
+ inode_bl->i_bytes = bytes;
+ swap_inode_data(inode, inode_bl);
+ ext4_mark_inode_dirty(handle, inode);
+ ext4_mark_inode_dirty(handle, inode_bl);
}
+
+err_out1:
ext4_journal_stop(handle);
ext4_double_up_write_data_sem(inode, inode_bl);
Re: [PATCH] pstore: Add boot loader log messages support
On Fri, 15 Feb 2019 12:01:30 +0800
Yue Hu wrote:
> On Tue, 12 Feb 2019 12:43:36 -0800
> Kees Cook wrote:
>
> > On Fri, Feb 1, 2019 at 12:30 AM Yue Hu wrote:
> > >
> > > From bac8bbcd6081b967422dc82074a41098a0cf5180 Mon Sep 17 00:00:00 2001
> > > From: Yue Hu
> > > Date: Tue, 29 Jan 2019 11:42:27 +0800
> > > Subject: [PATCH] pstore: Add boot loader log messages support
> > >
> > > Sometimes we hope to check boot loader log messages (e.g. Android
> > > Verified Boot status) when kernel is coming up. Generally it does
> > > depend on serial device, but it will be removed for the hardware
> > > shipping to market by most of manufacturers. In that case better
> > > solder and proper serial cable for different interface (e.g. Type-C
> > > or microUSB) are needed. That is inconvenient and even wasting much
> > > time on it.
> > >
> > > Therefore, let's add a logging support: PSTORE_TYPE_XBL.
> > >
> > > Signed-off-by: Yue Hu
> > > ---
> > > fs/pstore/Kconfig | 10
> > > fs/pstore/platform.c | 16 +
> > > fs/pstore/ram.c| 64
> > > --
> > > include/linux/pstore.h | 21 +
> > > 4 files changed, 104 insertions(+), 7 deletions(-)
> > >
> > > diff --git a/fs/pstore/Kconfig b/fs/pstore/Kconfig
> > > index 0d19d19..ef4a2dc 100644
> > > --- a/fs/pstore/Kconfig
> > > +++ b/fs/pstore/Kconfig
> > > @@ -137,6 +137,16 @@ config PSTORE_FTRACE
> > >
> > > If unsure, say N.
> > >
> > > +config PSTORE_XBL
> > > + bool "Log bootloader messages"
> > > + depends on PSTORE
> > > + help
> > > + When the option is enabled, pstore will log boot loader
> > > + messages to /sys/fs/pstore/xbl-ramoops-[ID] after reboot.
> > > + Boot loader needs to support log buffer reserved.
> > > +
> > > + If unsure, say N.
> > > +
> > > config PSTORE_RAM
> > > tristate "Log panic/oops to a RAM buffer"
> > > depends on PSTORE
> > > diff --git a/fs/pstore/platform.c b/fs/pstore/platform.c
> > > index 0ca7657..7486e48 100644
> > > --- a/fs/pstore/platform.c
> > > +++ b/fs/pstore/platform.c
> > > @@ -66,6 +66,7 @@
> > > "mce",
> > > "console",
> > > "ftrace",
> > > + "xbl",
> > > "rtas",
> > > "powerpc-ofw",
> > > "powerpc-common",
> > > @@ -532,6 +533,19 @@ static void pstore_register_console(void) {}
> > > static void pstore_unregister_console(void) {}
> > > #endif
> > >
> > > +#ifdef CONFIG_PSTORE_XBL
> > > +static void pstore_register_xbl(void)
> > > +{
> > > + struct pstore_record record;
> > > +
> > > + pstore_record_init(, psinfo);
> > > + record.type = PSTORE_TYPE_XBL;
> > > + psinfo->write();
> > > +}
> >
> > This writes a zero-length record at registration time. Why?
>
> It's related to interact with boot loader. Write callback will get the
> real record size which is set by boot loader.
>
> >
> > > +#else
> > > +static void pstore_register_xbl(void) {}
> > > +#endif
> > > +
> > > static int pstore_write_user_compat(struct pstore_record *record,
> > > const char __user *buf)
> > > {
> > > @@ -618,6 +632,8 @@ int pstore_register(struct pstore_info *psi)
> > > pstore_register_ftrace();
> > > if (psi->flags & PSTORE_FLAGS_PMSG)
> > > pstore_register_pmsg();
> > > + if (psi->flags & PSTORE_FLAGS_XBL)
> > > + pstore_register_xbl();
> > >
> > > /* Start watching for new records, if desired. */
> > > if (pstore_update_ms >= 0) {
> > > diff --git a/fs/pstore/ram.c b/fs/pstore/ram.c
> > > index ca01778..0bb086b 100644
> > > --- a/fs/pstore/ram.c
> > > +++ b/fs/pstore/ram.c
> > > @@ -56,6 +56,10 @@
> > > module_param_named(pmsg_size, ramoops_pmsg_size, ulong, 0400);
> > > MODULE_PARM_DESC(pmsg_size, "size of user space message log");
> > >
> >
[PATCH v2] pstore: Add boot loader log messages support
From: Yue Hu
Sometimes we hope to check boot loader log messages (e.g. Android
Verified Boot status) when kernel is coming up. Generally it does
depend on serial device, but it will be removed for the hardware
shipping to market by most of manufacturers. In that case better
solder and proper serial cable for different interface (e.g. Type-C
or microUSB) are needed. That is inconvenient and even wasting much
time on it.
Therefore, let's add a logging support: PSTORE_TYPE_XBL.
Signed-off-by: Yue Hu
---
v2: mention info of interacting with boot loader
fs/pstore/Kconfig | 10 +++
fs/pstore/platform.c | 16 ++
fs/pstore/ram.c| 81 --
include/linux/pstore.h | 21 +
4 files changed, 121 insertions(+), 7 deletions(-)
diff --git a/fs/pstore/Kconfig b/fs/pstore/Kconfig
index 0d19d19..ef4a2dc 100644
--- a/fs/pstore/Kconfig
+++ b/fs/pstore/Kconfig
@@ -137,6 +137,16 @@ config PSTORE_FTRACE
If unsure, say N.
+config PSTORE_XBL
+ bool "Log bootloader messages"
+ depends on PSTORE
+ help
+ When the option is enabled, pstore will log boot loader
+ messages to /sys/fs/pstore/xbl-ramoops-[ID] after reboot.
+ Boot loader needs to support log buffer reserved.
+
+ If unsure, say N.
+
config PSTORE_RAM
tristate "Log panic/oops to a RAM buffer"
depends on PSTORE
diff --git a/fs/pstore/platform.c b/fs/pstore/platform.c
index 2d1066e..2e6c3f8f 100644
--- a/fs/pstore/platform.c
+++ b/fs/pstore/platform.c
@@ -65,6 +65,7 @@
"mce",
"console",
"ftrace",
+ "xbl",
"rtas",
"powerpc-ofw",
"powerpc-common",
@@ -530,6 +531,19 @@ static void pstore_register_console(void) {}
static void pstore_unregister_console(void) {}
#endif
+#ifdef CONFIG_PSTORE_XBL
+static void pstore_register_xbl(void)
+{
+ struct pstore_record record;
+
+ pstore_record_init(, psinfo);
+ record.type = PSTORE_TYPE_XBL;
+ psinfo->write();
+}
+#else
+static void pstore_register_xbl(void) {}
+#endif
+
static int pstore_write_user_compat(struct pstore_record *record,
const char __user *buf)
{
@@ -616,6 +630,8 @@ int pstore_register(struct pstore_info *psi)
pstore_register_ftrace();
if (psi->flags & PSTORE_FLAGS_PMSG)
pstore_register_pmsg();
+ if (psi->flags & PSTORE_FLAGS_XBL)
+ pstore_register_xbl();
/* Start watching for new records, if desired. */
if (pstore_update_ms >= 0) {
diff --git a/fs/pstore/ram.c b/fs/pstore/ram.c
index 1adb5e3..b114b1d 100644
--- a/fs/pstore/ram.c
+++ b/fs/pstore/ram.c
@@ -56,6 +56,27 @@
module_param_named(pmsg_size, ramoops_pmsg_size, ulong, 0400);
MODULE_PARM_DESC(pmsg_size, "size of user space message log");
+/*
+ * interact with boot loader
+ * =
+ *
+ * xbl memory layout:
+ * ++
+ * |dst |
+ * || ++
+ * |src > | header |
+ * ++ |log messages|
+ * ++
+ *
+ * As above, src memory is used to store header and log messages generated
+ * by boot loader, pstore will copy the log messages to dst memory which
+ * has same size as src. The header in src is to record log messages size
+ * written and make xbl cookie.
+ */
+static ulong ramoops_xbl_size = MIN_MEM_SIZE;
+module_param_named(xbl_size, ramoops_xbl_size, ulong, 0400);
+MODULE_PARM_DESC(xbl_size, "size of boot loader log");
+
static unsigned long long mem_address;
module_param_hw(mem_address, ullong, other, 0400);
MODULE_PARM_DESC(mem_address,
@@ -88,6 +109,7 @@ struct ramoops_context {
struct persistent_ram_zone *cprz; /* Console zone */
struct persistent_ram_zone **fprzs; /* Ftrace zones */
struct persistent_ram_zone *mprz; /* PMSG zone */
+ struct persistent_ram_zone *bprz; /* XBL zone */
phys_addr_t phys_addr;
unsigned long size;
unsigned int memtype;
@@ -95,6 +117,7 @@ struct ramoops_context {
size_t console_size;
size_t ftrace_size;
size_t pmsg_size;
+ size_t xbl_size;
int dump_oops;
u32 flags;
struct persistent_ram_ecc_info ecc_info;
@@ -106,6 +129,7 @@ struct ramoops_context {
unsigned int max_ftrace_cnt;
unsigned int ftrace_read_cnt;
unsigned int pmsg_read_cnt;
+ unsigned int xbl_read_cnt;
struct pstore_info pstore;
};
@@ -119,6 +143,7 @@ static int ramoops_pstore_open(struct pstore_info *psi)
cxt->console_read_cnt = 0;
cxt->ftrace_read_cnt = 0;
cxt->pmsg_read_cnt = 0;
+ cxt->xbl_read_cnt = 0;
return 0;
}
@@ -272,6 +297,10 @@ static ssize_t ramoops_pstore_read(struct ps
Re: [PATCH] pstore: Add boot loader log messages support
On Thu, Feb 14, 2019 at 8:01 PM Yue Hu wrote: > Yes, boot loader will did the _write_. When booting from power on, the first > phase > is boot loader, it will log to specific reserver memory. Then kernel/pstore is > coming up, pstore will copy the log generated by boot loader to xbl zone. The > xbl > memory zone layout like below: > > +-+- > |dest | > |-| xbl zone > |src | > +-+- > > Anyway, i think it is a useful debug feature. Ah-ha, interesting. Okay, please mention this (and how the boot loader knows to write in the area) in v2. Thanks! -- Kees Cook
Re: [PATCH] pstore: Add boot loader log messages support
On Fri, Feb 1, 2019 at 12:30 AM Yue Hu wrote:
>
> From bac8bbcd6081b967422dc82074a41098a0cf5180 Mon Sep 17 00:00:00 2001
> From: Yue Hu
> Date: Tue, 29 Jan 2019 11:42:27 +0800
> Subject: [PATCH] pstore: Add boot loader log messages support
>
> Sometimes we hope to check boot loader log messages (e.g. Android
> Verified Boot status) when kernel is coming up. Generally it does
> depend on serial device, but it will be removed for the hardware
> shipping to market by most of manufacturers. In that case better
> solder and proper serial cable for different interface (e.g. Type-C
> or microUSB) are needed. That is inconvenient and even wasting much
> time on it.
>
> Therefore, let's add a logging support: PSTORE_TYPE_XBL.
>
> Signed-off-by: Yue Hu
> ---
> fs/pstore/Kconfig | 10
> fs/pstore/platform.c | 16 +
> fs/pstore/ram.c| 64
> --
> include/linux/pstore.h | 21 +
> 4 files changed, 104 insertions(+), 7 deletions(-)
>
> diff --git a/fs/pstore/Kconfig b/fs/pstore/Kconfig
> index 0d19d19..ef4a2dc 100644
> --- a/fs/pstore/Kconfig
> +++ b/fs/pstore/Kconfig
> @@ -137,6 +137,16 @@ config PSTORE_FTRACE
>
> If unsure, say N.
>
> +config PSTORE_XBL
> + bool "Log bootloader messages"
> + depends on PSTORE
> + help
> + When the option is enabled, pstore will log boot loader
> + messages to /sys/fs/pstore/xbl-ramoops-[ID] after reboot.
> + Boot loader needs to support log buffer reserved.
> +
> + If unsure, say N.
> +
> config PSTORE_RAM
> tristate "Log panic/oops to a RAM buffer"
> depends on PSTORE
> diff --git a/fs/pstore/platform.c b/fs/pstore/platform.c
> index 0ca7657..7486e48 100644
> --- a/fs/pstore/platform.c
> +++ b/fs/pstore/platform.c
> @@ -66,6 +66,7 @@
> "mce",
> "console",
> "ftrace",
> + "xbl",
> "rtas",
> "powerpc-ofw",
> "powerpc-common",
> @@ -532,6 +533,19 @@ static void pstore_register_console(void) {}
> static void pstore_unregister_console(void) {}
> #endif
>
> +#ifdef CONFIG_PSTORE_XBL
> +static void pstore_register_xbl(void)
> +{
> + struct pstore_record record;
> +
> + pstore_record_init(, psinfo);
> + record.type = PSTORE_TYPE_XBL;
> + psinfo->write();
> +}
This writes a zero-length record at registration time. Why?
> +#else
> +static void pstore_register_xbl(void) {}
> +#endif
> +
> static int pstore_write_user_compat(struct pstore_record *record,
> const char __user *buf)
> {
> @@ -618,6 +632,8 @@ int pstore_register(struct pstore_info *psi)
> pstore_register_ftrace();
> if (psi->flags & PSTORE_FLAGS_PMSG)
> pstore_register_pmsg();
> + if (psi->flags & PSTORE_FLAGS_XBL)
> + pstore_register_xbl();
>
> /* Start watching for new records, if desired. */
> if (pstore_update_ms >= 0) {
> diff --git a/fs/pstore/ram.c b/fs/pstore/ram.c
> index ca01778..0bb086b 100644
> --- a/fs/pstore/ram.c
> +++ b/fs/pstore/ram.c
> @@ -56,6 +56,10 @@
> module_param_named(pmsg_size, ramoops_pmsg_size, ulong, 0400);
> MODULE_PARM_DESC(pmsg_size, "size of user space message log");
>
> +static ulong ramoops_xbl_size = MIN_MEM_SIZE;
> +module_param_named(xbl_size, ramoops_xbl_size, ulong, 0400);
> +MODULE_PARM_DESC(xbl_size, "size of boot loader log");
> +
> static unsigned long long mem_address;
> module_param_hw(mem_address, ullong, other, 0400);
> MODULE_PARM_DESC(mem_address,
> @@ -88,6 +92,7 @@ struct ramoops_context {
> struct persistent_ram_zone *cprz; /* Console zone */
> struct persistent_ram_zone **fprzs; /* Ftrace zones */
> struct persistent_ram_zone *mprz; /* PMSG zone */
> + struct persistent_ram_zone *bprz; /* XBL zone */
> phys_addr_t phys_addr;
> unsigned long size;
> unsigned int memtype;
> @@ -95,6 +100,7 @@ struct ramoops_context {
> size_t console_size;
> size_t ftrace_size;
> size_t pmsg_size;
> + size_t xbl_size;
> int dump_oops;
> u32 flags;
> struct persistent_ram_ecc_info ecc_info;
> @@ -106,6 +112,7 @@ struct ramoops_context {
> unsigned int max_ftrace_cnt;
> unsigned int ftrace_read_cnt;
> unsigned int pmsg_read_cnt;
> + unsigned int xbl_read_cnt;
>
[PATCH 4.19 042/361] x86/xen: Fix boot loader version reported for PVH guests
4.19-stable review patch. If anyone has any objections, please let me know. -- From: Juergen Gross commit 357d291ce035d1b757568058f3c9898c60d125b1 upstream. The boot loader version reported via sysfs is wrong in case of the kernel being booted via the Xen PVH boot entry. it should be 2.12 (0x020c), but it is reported to be 2.18 (0x0212). As the current way to set the version is error prone use the more readable variant (2 << 8) | 12. Signed-off-by: Juergen Gross Cc: # 4.12 Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: boris.ostrov...@oracle.com Cc: b...@alien8.de Cc: cor...@lwn.net Cc: linux-...@vger.kernel.org Cc: xen-de...@lists.xenproject.org Link: http://lkml.kernel.org/r/20181010061456.22238-2-jgr...@suse.com Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman --- arch/x86/xen/enlighten_pvh.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/arch/x86/xen/enlighten_pvh.c +++ b/arch/x86/xen/enlighten_pvh.c @@ -75,7 +75,7 @@ static void __init init_pvh_bootparams(v * Version 2.12 supports Xen entry point but we will use default x86/PC * environment (i.e. hardware_subarch 0). */ - pvh_bootparams.hdr.version = 0x212; + pvh_bootparams.hdr.version = (2 << 8) | 12; pvh_bootparams.hdr.type_of_loader = (9 << 4) | 0; /* Xen loader */ x86_init.acpi.get_root_pointer = pvh_get_root_pointer;
[PATCH 4.19 042/361] x86/xen: Fix boot loader version reported for PVH guests
4.19-stable review patch. If anyone has any objections, please let me know. -- From: Juergen Gross commit 357d291ce035d1b757568058f3c9898c60d125b1 upstream. The boot loader version reported via sysfs is wrong in case of the kernel being booted via the Xen PVH boot entry. it should be 2.12 (0x020c), but it is reported to be 2.18 (0x0212). As the current way to set the version is error prone use the more readable variant (2 << 8) | 12. Signed-off-by: Juergen Gross Cc: # 4.12 Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: boris.ostrov...@oracle.com Cc: b...@alien8.de Cc: cor...@lwn.net Cc: linux-...@vger.kernel.org Cc: xen-de...@lists.xenproject.org Link: http://lkml.kernel.org/r/20181010061456.22238-2-jgr...@suse.com Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman --- arch/x86/xen/enlighten_pvh.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/arch/x86/xen/enlighten_pvh.c +++ b/arch/x86/xen/enlighten_pvh.c @@ -75,7 +75,7 @@ static void __init init_pvh_bootparams(v * Version 2.12 supports Xen entry point but we will use default x86/PC * environment (i.e. hardware_subarch 0). */ - pvh_bootparams.hdr.version = 0x212; + pvh_bootparams.hdr.version = (2 << 8) | 12; pvh_bootparams.hdr.type_of_loader = (9 << 4) | 0; /* Xen loader */ x86_init.acpi.get_root_pointer = pvh_get_root_pointer;
[PATCH 4.14 020/222] x86/xen: Fix boot loader version reported for PVH guests
4.14-stable review patch. If anyone has any objections, please let me know. -- From: Juergen Gross commit 357d291ce035d1b757568058f3c9898c60d125b1 upstream. The boot loader version reported via sysfs is wrong in case of the kernel being booted via the Xen PVH boot entry. it should be 2.12 (0x020c), but it is reported to be 2.18 (0x0212). As the current way to set the version is error prone use the more readable variant (2 << 8) | 12. Signed-off-by: Juergen Gross Cc: # 4.12 Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: boris.ostrov...@oracle.com Cc: b...@alien8.de Cc: cor...@lwn.net Cc: linux-...@vger.kernel.org Cc: xen-de...@lists.xenproject.org Link: http://lkml.kernel.org/r/20181010061456.22238-2-jgr...@suse.com Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman --- arch/x86/xen/enlighten_pvh.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/arch/x86/xen/enlighten_pvh.c +++ b/arch/x86/xen/enlighten_pvh.c @@ -76,7 +76,7 @@ static void __init init_pvh_bootparams(v * Version 2.12 supports Xen entry point but we will use default x86/PC * environment (i.e. hardware_subarch 0). */ - pvh_bootparams.hdr.version = 0x212; + pvh_bootparams.hdr.version = (2 << 8) | 12; pvh_bootparams.hdr.type_of_loader = (9 << 4) | 0; /* Xen loader */ }
[PATCH 4.14 020/222] x86/xen: Fix boot loader version reported for PVH guests
4.14-stable review patch. If anyone has any objections, please let me know. -- From: Juergen Gross commit 357d291ce035d1b757568058f3c9898c60d125b1 upstream. The boot loader version reported via sysfs is wrong in case of the kernel being booted via the Xen PVH boot entry. it should be 2.12 (0x020c), but it is reported to be 2.18 (0x0212). As the current way to set the version is error prone use the more readable variant (2 << 8) | 12. Signed-off-by: Juergen Gross Cc: # 4.12 Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: boris.ostrov...@oracle.com Cc: b...@alien8.de Cc: cor...@lwn.net Cc: linux-...@vger.kernel.org Cc: xen-de...@lists.xenproject.org Link: http://lkml.kernel.org/r/20181010061456.22238-2-jgr...@suse.com Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman --- arch/x86/xen/enlighten_pvh.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/arch/x86/xen/enlighten_pvh.c +++ b/arch/x86/xen/enlighten_pvh.c @@ -76,7 +76,7 @@ static void __init init_pvh_bootparams(v * Version 2.12 supports Xen entry point but we will use default x86/PC * environment (i.e. hardware_subarch 0). */ - pvh_bootparams.hdr.version = 0x212; + pvh_bootparams.hdr.version = (2 << 8) | 12; pvh_bootparams.hdr.type_of_loader = (9 << 4) | 0; /* Xen loader */ }
[PATCH 4.18 037/350] x86/xen: Fix boot loader version reported for PVH guests
4.18-stable review patch. If anyone has any objections, please let me know. -- From: Juergen Gross commit 357d291ce035d1b757568058f3c9898c60d125b1 upstream. The boot loader version reported via sysfs is wrong in case of the kernel being booted via the Xen PVH boot entry. it should be 2.12 (0x020c), but it is reported to be 2.18 (0x0212). As the current way to set the version is error prone use the more readable variant (2 << 8) | 12. Signed-off-by: Juergen Gross Cc: # 4.12 Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: boris.ostrov...@oracle.com Cc: b...@alien8.de Cc: cor...@lwn.net Cc: linux-...@vger.kernel.org Cc: xen-de...@lists.xenproject.org Link: http://lkml.kernel.org/r/20181010061456.22238-2-jgr...@suse.com Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman --- arch/x86/xen/enlighten_pvh.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/arch/x86/xen/enlighten_pvh.c +++ b/arch/x86/xen/enlighten_pvh.c @@ -75,7 +75,7 @@ static void __init init_pvh_bootparams(v * Version 2.12 supports Xen entry point but we will use default x86/PC * environment (i.e. hardware_subarch 0). */ - pvh_bootparams.hdr.version = 0x212; + pvh_bootparams.hdr.version = (2 << 8) | 12; pvh_bootparams.hdr.type_of_loader = (9 << 4) | 0; /* Xen loader */ x86_init.acpi.get_root_pointer = pvh_get_root_pointer;
[PATCH 4.18 037/350] x86/xen: Fix boot loader version reported for PVH guests
4.18-stable review patch. If anyone has any objections, please let me know. -- From: Juergen Gross commit 357d291ce035d1b757568058f3c9898c60d125b1 upstream. The boot loader version reported via sysfs is wrong in case of the kernel being booted via the Xen PVH boot entry. it should be 2.12 (0x020c), but it is reported to be 2.18 (0x0212). As the current way to set the version is error prone use the more readable variant (2 << 8) | 12. Signed-off-by: Juergen Gross Cc: # 4.12 Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: boris.ostrov...@oracle.com Cc: b...@alien8.de Cc: cor...@lwn.net Cc: linux-...@vger.kernel.org Cc: xen-de...@lists.xenproject.org Link: http://lkml.kernel.org/r/20181010061456.22238-2-jgr...@suse.com Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman --- arch/x86/xen/enlighten_pvh.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/arch/x86/xen/enlighten_pvh.c +++ b/arch/x86/xen/enlighten_pvh.c @@ -75,7 +75,7 @@ static void __init init_pvh_bootparams(v * Version 2.12 supports Xen entry point but we will use default x86/PC * environment (i.e. hardware_subarch 0). */ - pvh_bootparams.hdr.version = 0x212; + pvh_bootparams.hdr.version = (2 << 8) | 12; pvh_bootparams.hdr.type_of_loader = (9 << 4) | 0; /* Xen loader */ x86_init.acpi.get_root_pointer = pvh_get_root_pointer;
[tip:x86/boot] x86/xen: Fix the boot loader version reported for PVH guests
Commit-ID: 88750a6c33f813b815516990f01fb5ee488c477e Gitweb: https://git.kernel.org/tip/88750a6c33f813b815516990f01fb5ee488c477e Author: Juergen Gross <jgr...@suse.com> AuthorDate: Fri, 8 Dec 2017 16:11:38 +0100 Committer: Ingo Molnar <mi...@kernel.org> CommitDate: Mon, 11 Dec 2017 15:14:20 +0100 x86/xen: Fix the boot loader version reported for PVH guests The boot loader version reported via sysfs is wrong in case of the kernel being booted via the Xen PVH boot entry. it should be 2.12 (0x020c), but it is reported to be 2.18 (0x0212). As the current way to set the version is error prone use the more readable variant (2 << 8) | 12. Signed-off-by: Juergen Gross <jgr...@suse.com> Cc: <sta...@vger.kernel.org> # 4.12 Cc: Linus Torvalds <torva...@linux-foundation.org> Cc: Peter Zijlstra <pet...@infradead.org> Cc: Thomas Gleixner <t...@linutronix.de> Cc: boris.ostrov...@oracle.com Cc: cor...@lwn.net Cc: l...@kernel.org Cc: linux-a...@vger.kernel.org Cc: r...@rjwysocki.net Cc: xen-de...@lists.xenproject.org Link: http://lkml.kernel.org/r/20171208151139.30213-4-jgr...@suse.com Signed-off-by: Ingo Molnar <mi...@kernel.org> --- arch/x86/xen/enlighten_pvh.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/x86/xen/enlighten_pvh.c b/arch/x86/xen/enlighten_pvh.c index 436c4f0..6e6430c 100644 --- a/arch/x86/xen/enlighten_pvh.c +++ b/arch/x86/xen/enlighten_pvh.c @@ -69,7 +69,7 @@ static void __init init_pvh_bootparams(void) * Version 2.12 supports Xen entry point but we will use default x86/PC * environment (i.e. hardware_subarch 0). */ - pvh_bootparams.hdr.version = 0x212; + pvh_bootparams.hdr.version = (2 << 8) | 12; pvh_bootparams.hdr.type_of_loader = (9 << 4) | 0; /* Xen loader */ }
[tip:x86/boot] x86/xen: Fix the boot loader version reported for PVH guests
Commit-ID: 88750a6c33f813b815516990f01fb5ee488c477e Gitweb: https://git.kernel.org/tip/88750a6c33f813b815516990f01fb5ee488c477e Author: Juergen Gross AuthorDate: Fri, 8 Dec 2017 16:11:38 +0100 Committer: Ingo Molnar CommitDate: Mon, 11 Dec 2017 15:14:20 +0100 x86/xen: Fix the boot loader version reported for PVH guests The boot loader version reported via sysfs is wrong in case of the kernel being booted via the Xen PVH boot entry. it should be 2.12 (0x020c), but it is reported to be 2.18 (0x0212). As the current way to set the version is error prone use the more readable variant (2 << 8) | 12. Signed-off-by: Juergen Gross Cc: # 4.12 Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: boris.ostrov...@oracle.com Cc: cor...@lwn.net Cc: l...@kernel.org Cc: linux-a...@vger.kernel.org Cc: r...@rjwysocki.net Cc: xen-de...@lists.xenproject.org Link: http://lkml.kernel.org/r/20171208151139.30213-4-jgr...@suse.com Signed-off-by: Ingo Molnar --- arch/x86/xen/enlighten_pvh.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/x86/xen/enlighten_pvh.c b/arch/x86/xen/enlighten_pvh.c index 436c4f0..6e6430c 100644 --- a/arch/x86/xen/enlighten_pvh.c +++ b/arch/x86/xen/enlighten_pvh.c @@ -69,7 +69,7 @@ static void __init init_pvh_bootparams(void) * Version 2.12 supports Xen entry point but we will use default x86/PC * environment (i.e. hardware_subarch 0). */ - pvh_bootparams.hdr.version = 0x212; + pvh_bootparams.hdr.version = (2 << 8) | 12; pvh_bootparams.hdr.type_of_loader = (9 << 4) | 0; /* Xen loader */ }
[PATCH v3 3/4] x86/xen: fix boot loader version reported for pvh guests
The boot loader version reported via sysfs is wrong in case of the kernel being booted via the Xen PVH boot entry. it should be 2.12 (0x020c), but it is reported to be 2.18 (0x0212). As the current way to set the version is error prone use the more readable variant (2 << 8) | 12. Cc: <sta...@vger.kernel.org> # 4.12 Signed-off-by: Juergen Gross <jgr...@suse.com> --- arch/x86/xen/enlighten_pvh.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/x86/xen/enlighten_pvh.c b/arch/x86/xen/enlighten_pvh.c index 436c4f003e17..6e6430cb5e3f 100644 --- a/arch/x86/xen/enlighten_pvh.c +++ b/arch/x86/xen/enlighten_pvh.c @@ -69,7 +69,7 @@ static void __init init_pvh_bootparams(void) * Version 2.12 supports Xen entry point but we will use default x86/PC * environment (i.e. hardware_subarch 0). */ - pvh_bootparams.hdr.version = 0x212; + pvh_bootparams.hdr.version = (2 << 8) | 12; pvh_bootparams.hdr.type_of_loader = (9 << 4) | 0; /* Xen loader */ } -- 2.12.3
[PATCH v3 3/4] x86/xen: fix boot loader version reported for pvh guests
The boot loader version reported via sysfs is wrong in case of the kernel being booted via the Xen PVH boot entry. it should be 2.12 (0x020c), but it is reported to be 2.18 (0x0212). As the current way to set the version is error prone use the more readable variant (2 << 8) | 12. Cc: # 4.12 Signed-off-by: Juergen Gross --- arch/x86/xen/enlighten_pvh.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/x86/xen/enlighten_pvh.c b/arch/x86/xen/enlighten_pvh.c index 436c4f003e17..6e6430cb5e3f 100644 --- a/arch/x86/xen/enlighten_pvh.c +++ b/arch/x86/xen/enlighten_pvh.c @@ -69,7 +69,7 @@ static void __init init_pvh_bootparams(void) * Version 2.12 supports Xen entry point but we will use default x86/PC * environment (i.e. hardware_subarch 0). */ - pvh_bootparams.hdr.version = 0x212; + pvh_bootparams.hdr.version = (2 << 8) | 12; pvh_bootparams.hdr.type_of_loader = (9 << 4) | 0; /* Xen loader */ } -- 2.12.3
Re: [PATCH] Staging: setup.c : boot loader kernel arguments are secured over cmdline.txt arguments for some systems
Hi Kishore, [auto build test ERROR on tip/x86/core] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Kishore-Karanala/Staging-setup-c-boot-loader-kernel-arguments-are-secured-over-cmdline-txt-arguments-for-some-systems/20170212-033448 config: x86_64-randconfig-x008-201707 compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901 reproduce: make ARCH=x86_64 randconfig make ARCH=x86_64 All errors (new ones prefixed by >>): >> arch/x86/Kconfig:2199: syntax error >> arch/x86/Kconfig:2198: unknown option "In" arch/x86/Kconfig:2199:warning: ignoring unsupported character ',' >> arch/x86/Kconfig:2199: unknown option "cmdline" >> arch/x86/Kconfig:2200: unknown option "CMDLINE" make[2]: *** [oldconfig] Error 1 make[1]: *** [oldconfig] Error 2 make: *** [sub-make] Error 2 -- >> arch/x86/Kconfig:2199: syntax error >> arch/x86/Kconfig:2198: unknown option "In" arch/x86/Kconfig:2199:warning: ignoring unsupported character ',' >> arch/x86/Kconfig:2199: unknown option "cmdline" >> arch/x86/Kconfig:2200: unknown option "CMDLINE" make[2]: *** [olddefconfig] Error 1 make[2]: Target 'oldnoconfig' not remade because of errors. make[1]: *** [oldnoconfig] Error 2 make: *** [sub-make] Error 2 vim +2199 arch/x86/Kconfig 2192However, you can use the CONFIG_CMDLINE_OVERRIDE option to 2193change this behavior. 2194 2195In most cases, the command line (whether built-in or provided 2196by the boot loader) should specify the device for the root 2197file system. > 2198 In some of the systems boot loader arguments needs dominated > over > 2199 cmdline arguments in systems like automotive , this can be > done using > 2200 CMDLINE="!root=/dev/mmcblk0p1 ro" 2201 2202 config CMDLINE_OVERRIDE 2203 bool "Built-in command line overrides boot loader arguments" --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation
Re: [PATCH] Staging: setup.c : boot loader kernel arguments are secured over cmdline.txt arguments for some systems
Hi Kishore, [auto build test ERROR on tip/x86/core] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Kishore-Karanala/Staging-setup-c-boot-loader-kernel-arguments-are-secured-over-cmdline-txt-arguments-for-some-systems/20170212-033448 config: x86_64-randconfig-x008-201707 compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901 reproduce: make ARCH=x86_64 randconfig make ARCH=x86_64 All errors (new ones prefixed by >>): >> arch/x86/Kconfig:2199: syntax error >> arch/x86/Kconfig:2198: unknown option "In" arch/x86/Kconfig:2199:warning: ignoring unsupported character ',' >> arch/x86/Kconfig:2199: unknown option "cmdline" >> arch/x86/Kconfig:2200: unknown option "CMDLINE" make[2]: *** [oldconfig] Error 1 make[1]: *** [oldconfig] Error 2 make: *** [sub-make] Error 2 -- >> arch/x86/Kconfig:2199: syntax error >> arch/x86/Kconfig:2198: unknown option "In" arch/x86/Kconfig:2199:warning: ignoring unsupported character ',' >> arch/x86/Kconfig:2199: unknown option "cmdline" >> arch/x86/Kconfig:2200: unknown option "CMDLINE" make[2]: *** [olddefconfig] Error 1 make[2]: Target 'oldnoconfig' not remade because of errors. make[1]: *** [oldnoconfig] Error 2 make: *** [sub-make] Error 2 vim +2199 arch/x86/Kconfig 2192However, you can use the CONFIG_CMDLINE_OVERRIDE option to 2193change this behavior. 2194 2195In most cases, the command line (whether built-in or provided 2196by the boot loader) should specify the device for the root 2197file system. > 2198 In some of the systems boot loader arguments needs dominated > over > 2199 cmdline arguments in systems like automotive , this can be > done using > 2200 CMDLINE="!root=/dev/mmcblk0p1 ro" 2201 2202 config CMDLINE_OVERRIDE 2203 bool "Built-in command line overrides boot loader arguments" --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation
Re: [PATCH] Staging: setup.c : boot loader kernel arguments are secured over cmdline.txt arguments for some systems
On Sun, 12 Feb 2017, Kishore Karanala wrote:
1;2802;0c
The proper subsystem for x86 is x86 and not staging.
Also your subject line is a way too long sentence instead of a short and
precise summary of the change.
> boot loader kernel arguments are secured over cmdline.txt
> arguments for some systems
Repeating it does not make it any better.
What's missing here is an explanation WHY this changes is needed and which
problem it solves.
> Signed-off-by: Kishore Karanala <kishore.karan...@gmail.com>
> ---
> arch/x86/Kconfig| 3 +++
> arch/x86/kernel/setup.c | 7 ++-
> 2 files changed, 9 insertions(+), 1 deletion(-)
>
> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
> index e487493..3077fb0 100644
> --- a/arch/x86/Kconfig
> +++ b/arch/x86/Kconfig
> @@ -2224,6 +2224,9 @@ config CMDLINE
> In most cases, the command line (whether built-in or provided
> by the boot loader) should specify the device for the root
> file system.
> + In some of the systems boot loader arguments needs dominated over
> + cmdline arguments in systems like automotive , this can be done using
> + CMDLINE="!root=/dev/mmcblk0p1 ro"
I really have no idea what that sentence means. Also it does not explain
what the exclamation mark stands for.
Aside of that the indentation of that paragraph is wrong.
> config CMDLINE_OVERRIDE
> bool "Built-in command line overrides boot loader arguments"
> diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
> index 4cfba94..5fa3194 100644
> --- a/arch/x86/kernel/setup.c
> +++ b/arch/x86/kernel/setup.c
> @@ -962,11 +962,16 @@ void __init setup_arch(char **cmdline_p)
> #ifdef CONFIG_CMDLINE_OVERRIDE
> strlcpy(boot_command_line, builtin_cmdline, COMMAND_LINE_SIZE);
> #else
> - if (builtin_cmdline[0]) {
> + if (builtin_cmdline[0] != '!') {
> /* append boot loader cmdline to builtin */
> strlcat(builtin_cmdline, " ", COMMAND_LINE_SIZE);
> strlcat(builtin_cmdline, boot_command_line, COMMAND_LINE_SIZE);
> strlcpy(boot_command_line, builtin_cmdline, COMMAND_LINE_SIZE);
> + } else {
> + /* This will provide additional secuirty to cmdline */
I assume you mean security. What has this to do with security? The empty
changelog does not explain it neither does this comment.
> + /* arguments not overriding bootloader arguments */
Multiline comments are formatted like this
/*
* This is the first line of a multiline comment which
* continues on the second line.
*/
> + strlcat(boot_command_line, " ", COMMAND_LINE_SIZE);
> + strlcat(boot_command_line, _cmdline[1],
> COMMAND_LINE_SIZE);
So this is just the reverse order of the exsiting mechanism. What's the
point of this exercise?
Thanks,
tglx
Re: [PATCH] Staging: setup.c : boot loader kernel arguments are secured over cmdline.txt arguments for some systems
On Sun, 12 Feb 2017, Kishore Karanala wrote:
1;2802;0c
The proper subsystem for x86 is x86 and not staging.
Also your subject line is a way too long sentence instead of a short and
precise summary of the change.
> boot loader kernel arguments are secured over cmdline.txt
> arguments for some systems
Repeating it does not make it any better.
What's missing here is an explanation WHY this changes is needed and which
problem it solves.
> Signed-off-by: Kishore Karanala
> ---
> arch/x86/Kconfig| 3 +++
> arch/x86/kernel/setup.c | 7 ++-
> 2 files changed, 9 insertions(+), 1 deletion(-)
>
> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
> index e487493..3077fb0 100644
> --- a/arch/x86/Kconfig
> +++ b/arch/x86/Kconfig
> @@ -2224,6 +2224,9 @@ config CMDLINE
> In most cases, the command line (whether built-in or provided
> by the boot loader) should specify the device for the root
> file system.
> + In some of the systems boot loader arguments needs dominated over
> + cmdline arguments in systems like automotive , this can be done using
> + CMDLINE="!root=/dev/mmcblk0p1 ro"
I really have no idea what that sentence means. Also it does not explain
what the exclamation mark stands for.
Aside of that the indentation of that paragraph is wrong.
> config CMDLINE_OVERRIDE
> bool "Built-in command line overrides boot loader arguments"
> diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
> index 4cfba94..5fa3194 100644
> --- a/arch/x86/kernel/setup.c
> +++ b/arch/x86/kernel/setup.c
> @@ -962,11 +962,16 @@ void __init setup_arch(char **cmdline_p)
> #ifdef CONFIG_CMDLINE_OVERRIDE
> strlcpy(boot_command_line, builtin_cmdline, COMMAND_LINE_SIZE);
> #else
> - if (builtin_cmdline[0]) {
> + if (builtin_cmdline[0] != '!') {
> /* append boot loader cmdline to builtin */
> strlcat(builtin_cmdline, " ", COMMAND_LINE_SIZE);
> strlcat(builtin_cmdline, boot_command_line, COMMAND_LINE_SIZE);
> strlcpy(boot_command_line, builtin_cmdline, COMMAND_LINE_SIZE);
> + } else {
> + /* This will provide additional secuirty to cmdline */
I assume you mean security. What has this to do with security? The empty
changelog does not explain it neither does this comment.
> + /* arguments not overriding bootloader arguments */
Multiline comments are formatted like this
/*
* This is the first line of a multiline comment which
* continues on the second line.
*/
> + strlcat(boot_command_line, " ", COMMAND_LINE_SIZE);
> + strlcat(boot_command_line, _cmdline[1],
> COMMAND_LINE_SIZE);
So this is just the reverse order of the exsiting mechanism. What's the
point of this exercise?
Thanks,
tglx
[PATCH] Staging: setup.c : boot loader kernel arguments are secured over cmdline.txt arguments for some systems
boot loader kernel arguments are secured over cmdline.txt
arguments for some systems
Signed-off-by: Kishore Karanala <kishore.karan...@gmail.com>
---
arch/x86/Kconfig| 3 +++
arch/x86/kernel/setup.c | 7 ++-
2 files changed, 9 insertions(+), 1 deletion(-)
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index e487493..3077fb0 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -2224,6 +2224,9 @@ config CMDLINE
In most cases, the command line (whether built-in or provided
by the boot loader) should specify the device for the root
file system.
+In some of the systems boot loader arguments needs dominated over
+cmdline arguments in systems like automotive , this can be done using
+CMDLINE="!root=/dev/mmcblk0p1 ro"
config CMDLINE_OVERRIDE
bool "Built-in command line overrides boot loader arguments"
diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
index 4cfba94..5fa3194 100644
--- a/arch/x86/kernel/setup.c
+++ b/arch/x86/kernel/setup.c
@@ -962,11 +962,16 @@ void __init setup_arch(char **cmdline_p)
#ifdef CONFIG_CMDLINE_OVERRIDE
strlcpy(boot_command_line, builtin_cmdline, COMMAND_LINE_SIZE);
#else
- if (builtin_cmdline[0]) {
+ if (builtin_cmdline[0] != '!') {
/* append boot loader cmdline to builtin */
strlcat(builtin_cmdline, " ", COMMAND_LINE_SIZE);
strlcat(builtin_cmdline, boot_command_line, COMMAND_LINE_SIZE);
strlcpy(boot_command_line, builtin_cmdline, COMMAND_LINE_SIZE);
+ } else {
+ /* This will provide additional secuirty to cmdline */
+ /* arguments not overriding bootloader arguments */
+ strlcat(boot_command_line, " ", COMMAND_LINE_SIZE);
+ strlcat(boot_command_line, _cmdline[1],
COMMAND_LINE_SIZE);
}
#endif
#endif
--
2.7.4
[PATCH] Staging: setup.c : boot loader kernel arguments are secured over cmdline.txt arguments for some systems
boot loader kernel arguments are secured over cmdline.txt
arguments for some systems
Signed-off-by: Kishore Karanala
---
arch/x86/Kconfig| 3 +++
arch/x86/kernel/setup.c | 7 ++-
2 files changed, 9 insertions(+), 1 deletion(-)
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index e487493..3077fb0 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -2224,6 +2224,9 @@ config CMDLINE
In most cases, the command line (whether built-in or provided
by the boot loader) should specify the device for the root
file system.
+In some of the systems boot loader arguments needs dominated over
+cmdline arguments in systems like automotive , this can be done using
+CMDLINE="!root=/dev/mmcblk0p1 ro"
config CMDLINE_OVERRIDE
bool "Built-in command line overrides boot loader arguments"
diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
index 4cfba94..5fa3194 100644
--- a/arch/x86/kernel/setup.c
+++ b/arch/x86/kernel/setup.c
@@ -962,11 +962,16 @@ void __init setup_arch(char **cmdline_p)
#ifdef CONFIG_CMDLINE_OVERRIDE
strlcpy(boot_command_line, builtin_cmdline, COMMAND_LINE_SIZE);
#else
- if (builtin_cmdline[0]) {
+ if (builtin_cmdline[0] != '!') {
/* append boot loader cmdline to builtin */
strlcat(builtin_cmdline, " ", COMMAND_LINE_SIZE);
strlcat(builtin_cmdline, boot_command_line, COMMAND_LINE_SIZE);
strlcpy(boot_command_line, builtin_cmdline, COMMAND_LINE_SIZE);
+ } else {
+ /* This will provide additional secuirty to cmdline */
+ /* arguments not overriding bootloader arguments */
+ strlcat(boot_command_line, " ", COMMAND_LINE_SIZE);
+ strlcat(boot_command_line, _cmdline[1],
COMMAND_LINE_SIZE);
}
#endif
#endif
--
2.7.4
Re: [PATCH] kbuild/mkspec: clean boot loader configuration on rpm removal
Dne 2.3.2016 v 15:28 Paolo Abeni napsal(a): > This patch add a rpm preuninstall scriptlet to cleanup the > boot loader configuration on kernel package uninstall. > The initrd for the to-be-removed kernel is deleted, too. > > Signed-off-by: Paolo Abeni <pab...@redhat.com> Applied to kbuild.git#misc. Michal
Re: [PATCH] kbuild/mkspec: clean boot loader configuration on rpm removal
Dne 2.3.2016 v 15:28 Paolo Abeni napsal(a): > This patch add a rpm preuninstall scriptlet to cleanup the > boot loader configuration on kernel package uninstall. > The initrd for the to-be-removed kernel is deleted, too. > > Signed-off-by: Paolo Abeni Applied to kbuild.git#misc. Michal
Re: [PATCH] kbuild/mkspec: clean boot loader configuration on rpm removal
Dne 3.3.2016 v 10:09 Paolo Abeni napsal(a): > I'm sorry, I try to dig a bit, but I did not find any distro agnostic > kernel removal tools. Can you please point out some ? There isn't any, so unfortunately we need a list of various distro-specific methods, starting with ew-kernel-pkg. The %post script should stay as is, though. Michal
Re: [PATCH] kbuild/mkspec: clean boot loader configuration on rpm removal
Dne 3.3.2016 v 10:09 Paolo Abeni napsal(a): > I'm sorry, I try to dig a bit, but I did not find any distro agnostic > kernel removal tools. Can you please point out some ? There isn't any, so unfortunately we need a list of various distro-specific methods, starting with ew-kernel-pkg. The %post script should stay as is, though. Michal
Re: [PATCH] kbuild/mkspec: clean boot loader configuration on rpm removal
On Wed, 2016-03-02 at 10:09 -0500, Josh Boyer wrote: > On Wed, Mar 2, 2016 at 9:38 AM, Hannes Frederic Sowa > <han...@stressinduktion.org> wrote: > > On 02.03.2016 15:28, Paolo Abeni wrote: > >> > >> This patch add a rpm preuninstall scriptlet to cleanup the > >> boot loader configuration on kernel package uninstall. > >> The initrd for the to-be-removed kernel is deleted, too. > >> > >> Signed-off-by: Paolo Abeni <pab...@redhat.com> > >> --- > >> scripts/package/mkspec | 5 + > >> 1 file changed, 5 insertions(+) > >> > >> diff --git a/scripts/package/mkspec b/scripts/package/mkspec > >> index fe44d68..b6de63c 100755 > >> --- a/scripts/package/mkspec > >> +++ b/scripts/package/mkspec > >> @@ -138,6 +138,11 @@ echo "/sbin/installkernel $KERNELRELEASE > >> /boot/.vmlinuz-$KERNELRELEASE-rpm /boot > >> echo "rm -f /boot/.vmlinuz-$KERNELRELEASE-rpm > >> /boot/.System.map-$KERNELRELEASE-rpm" > >> echo "fi" > >> echo "" > >> +echo "%preun" > >> +echo "if [ -x /sbin/new-kernel-pkg ]; then" > >> +echo "new-kernel-pkg --remove $KERNELRELEASE --rminitrd > >> --initrdfile=/boot/initramfs-$KERNELRELEASE.img" > >> +echo "fi" > >> +echo "" > >> echo "%files" > >> echo '%defattr (-, root, root)' > >> echo "/lib/modules/$KERNELRELEASE" > >> > > > > Maybe we should also switch to new-kernel-pkg for the postinstall call? How > > about switching to kernel-install? > > new-kernel-pkg probably shouldn't be used here either. The > installkernel binary is the distro agnostic kernel installation tool > and the various distros provide that as either the tool they use or as > a wrapper. Switching to new-kernel-pkg implies this would only be > viable on grubby based distros, and using kernel-install would require > systemd. I'm sorry, I try to dig a bit, but I did not find any distro agnostic kernel removal tools. Can you please point out some ? Elsewhere can we stuck with new-kernel-pkg, plus eventual fall-back to other options, i.e. kernel-install? Thank you, Paolo
Re: [PATCH] kbuild/mkspec: clean boot loader configuration on rpm removal
On Wed, 2016-03-02 at 10:09 -0500, Josh Boyer wrote: > On Wed, Mar 2, 2016 at 9:38 AM, Hannes Frederic Sowa > wrote: > > On 02.03.2016 15:28, Paolo Abeni wrote: > >> > >> This patch add a rpm preuninstall scriptlet to cleanup the > >> boot loader configuration on kernel package uninstall. > >> The initrd for the to-be-removed kernel is deleted, too. > >> > >> Signed-off-by: Paolo Abeni > >> --- > >> scripts/package/mkspec | 5 + > >> 1 file changed, 5 insertions(+) > >> > >> diff --git a/scripts/package/mkspec b/scripts/package/mkspec > >> index fe44d68..b6de63c 100755 > >> --- a/scripts/package/mkspec > >> +++ b/scripts/package/mkspec > >> @@ -138,6 +138,11 @@ echo "/sbin/installkernel $KERNELRELEASE > >> /boot/.vmlinuz-$KERNELRELEASE-rpm /boot > >> echo "rm -f /boot/.vmlinuz-$KERNELRELEASE-rpm > >> /boot/.System.map-$KERNELRELEASE-rpm" > >> echo "fi" > >> echo "" > >> +echo "%preun" > >> +echo "if [ -x /sbin/new-kernel-pkg ]; then" > >> +echo "new-kernel-pkg --remove $KERNELRELEASE --rminitrd > >> --initrdfile=/boot/initramfs-$KERNELRELEASE.img" > >> +echo "fi" > >> +echo "" > >> echo "%files" > >> echo '%defattr (-, root, root)' > >> echo "/lib/modules/$KERNELRELEASE" > >> > > > > Maybe we should also switch to new-kernel-pkg for the postinstall call? How > > about switching to kernel-install? > > new-kernel-pkg probably shouldn't be used here either. The > installkernel binary is the distro agnostic kernel installation tool > and the various distros provide that as either the tool they use or as > a wrapper. Switching to new-kernel-pkg implies this would only be > viable on grubby based distros, and using kernel-install would require > systemd. I'm sorry, I try to dig a bit, but I did not find any distro agnostic kernel removal tools. Can you please point out some ? Elsewhere can we stuck with new-kernel-pkg, plus eventual fall-back to other options, i.e. kernel-install? Thank you, Paolo
Re: [PATCH] kbuild/mkspec: clean boot loader configuration on rpm removal
On Wed, Mar 2, 2016 at 9:38 AM, Hannes Frederic Sowa <han...@stressinduktion.org> wrote: > On 02.03.2016 15:28, Paolo Abeni wrote: >> >> This patch add a rpm preuninstall scriptlet to cleanup the >> boot loader configuration on kernel package uninstall. >> The initrd for the to-be-removed kernel is deleted, too. >> >> Signed-off-by: Paolo Abeni <pab...@redhat.com> >> --- >> scripts/package/mkspec | 5 + >> 1 file changed, 5 insertions(+) >> >> diff --git a/scripts/package/mkspec b/scripts/package/mkspec >> index fe44d68..b6de63c 100755 >> --- a/scripts/package/mkspec >> +++ b/scripts/package/mkspec >> @@ -138,6 +138,11 @@ echo "/sbin/installkernel $KERNELRELEASE >> /boot/.vmlinuz-$KERNELRELEASE-rpm /boot >> echo "rm -f /boot/.vmlinuz-$KERNELRELEASE-rpm >> /boot/.System.map-$KERNELRELEASE-rpm" >> echo "fi" >> echo "" >> +echo "%preun" >> +echo "if [ -x /sbin/new-kernel-pkg ]; then" >> +echo "new-kernel-pkg --remove $KERNELRELEASE --rminitrd >> --initrdfile=/boot/initramfs-$KERNELRELEASE.img" >> +echo "fi" >> +echo "" >> echo "%files" >> echo '%defattr (-, root, root)' >> echo "/lib/modules/$KERNELRELEASE" >> > > Maybe we should also switch to new-kernel-pkg for the postinstall call? How > about switching to kernel-install? new-kernel-pkg probably shouldn't be used here either. The installkernel binary is the distro agnostic kernel installation tool and the various distros provide that as either the tool they use or as a wrapper. Switching to new-kernel-pkg implies this would only be viable on grubby based distros, and using kernel-install would require systemd. josh
Re: [PATCH] kbuild/mkspec: clean boot loader configuration on rpm removal
On Wed, Mar 2, 2016 at 9:38 AM, Hannes Frederic Sowa wrote: > On 02.03.2016 15:28, Paolo Abeni wrote: >> >> This patch add a rpm preuninstall scriptlet to cleanup the >> boot loader configuration on kernel package uninstall. >> The initrd for the to-be-removed kernel is deleted, too. >> >> Signed-off-by: Paolo Abeni >> --- >> scripts/package/mkspec | 5 + >> 1 file changed, 5 insertions(+) >> >> diff --git a/scripts/package/mkspec b/scripts/package/mkspec >> index fe44d68..b6de63c 100755 >> --- a/scripts/package/mkspec >> +++ b/scripts/package/mkspec >> @@ -138,6 +138,11 @@ echo "/sbin/installkernel $KERNELRELEASE >> /boot/.vmlinuz-$KERNELRELEASE-rpm /boot >> echo "rm -f /boot/.vmlinuz-$KERNELRELEASE-rpm >> /boot/.System.map-$KERNELRELEASE-rpm" >> echo "fi" >> echo "" >> +echo "%preun" >> +echo "if [ -x /sbin/new-kernel-pkg ]; then" >> +echo "new-kernel-pkg --remove $KERNELRELEASE --rminitrd >> --initrdfile=/boot/initramfs-$KERNELRELEASE.img" >> +echo "fi" >> +echo "" >> echo "%files" >> echo '%defattr (-, root, root)' >> echo "/lib/modules/$KERNELRELEASE" >> > > Maybe we should also switch to new-kernel-pkg for the postinstall call? How > about switching to kernel-install? new-kernel-pkg probably shouldn't be used here either. The installkernel binary is the distro agnostic kernel installation tool and the various distros provide that as either the tool they use or as a wrapper. Switching to new-kernel-pkg implies this would only be viable on grubby based distros, and using kernel-install would require systemd. josh
Re: [PATCH] kbuild/mkspec: clean boot loader configuration on rpm removal
On 02.03.2016 15:28, Paolo Abeni wrote: This patch add a rpm preuninstall scriptlet to cleanup the boot loader configuration on kernel package uninstall. The initrd for the to-be-removed kernel is deleted, too. Signed-off-by: Paolo Abeni <pab...@redhat.com> --- scripts/package/mkspec | 5 + 1 file changed, 5 insertions(+) diff --git a/scripts/package/mkspec b/scripts/package/mkspec index fe44d68..b6de63c 100755 --- a/scripts/package/mkspec +++ b/scripts/package/mkspec @@ -138,6 +138,11 @@ echo "/sbin/installkernel $KERNELRELEASE /boot/.vmlinuz-$KERNELRELEASE-rpm /boot echo "rm -f /boot/.vmlinuz-$KERNELRELEASE-rpm /boot/.System.map-$KERNELRELEASE-rpm" echo "fi" echo "" +echo "%preun" +echo "if [ -x /sbin/new-kernel-pkg ]; then" +echo "new-kernel-pkg --remove $KERNELRELEASE --rminitrd --initrdfile=/boot/initramfs-$KERNELRELEASE.img" +echo "fi" +echo "" echo "%files" echo '%defattr (-, root, root)' echo "/lib/modules/$KERNELRELEASE" Maybe we should also switch to new-kernel-pkg for the postinstall call? How about switching to kernel-install? Thanks, Hannes
Re: [PATCH] kbuild/mkspec: clean boot loader configuration on rpm removal
On 02.03.2016 15:28, Paolo Abeni wrote: This patch add a rpm preuninstall scriptlet to cleanup the boot loader configuration on kernel package uninstall. The initrd for the to-be-removed kernel is deleted, too. Signed-off-by: Paolo Abeni --- scripts/package/mkspec | 5 + 1 file changed, 5 insertions(+) diff --git a/scripts/package/mkspec b/scripts/package/mkspec index fe44d68..b6de63c 100755 --- a/scripts/package/mkspec +++ b/scripts/package/mkspec @@ -138,6 +138,11 @@ echo "/sbin/installkernel $KERNELRELEASE /boot/.vmlinuz-$KERNELRELEASE-rpm /boot echo "rm -f /boot/.vmlinuz-$KERNELRELEASE-rpm /boot/.System.map-$KERNELRELEASE-rpm" echo "fi" echo "" +echo "%preun" +echo "if [ -x /sbin/new-kernel-pkg ]; then" +echo "new-kernel-pkg --remove $KERNELRELEASE --rminitrd --initrdfile=/boot/initramfs-$KERNELRELEASE.img" +echo "fi" +echo "" echo "%files" echo '%defattr (-, root, root)' echo "/lib/modules/$KERNELRELEASE" Maybe we should also switch to new-kernel-pkg for the postinstall call? How about switching to kernel-install? Thanks, Hannes
[PATCH] kbuild/mkspec: clean boot loader configuration on rpm removal
This patch add a rpm preuninstall scriptlet to cleanup the boot loader configuration on kernel package uninstall. The initrd for the to-be-removed kernel is deleted, too. Signed-off-by: Paolo Abeni <pab...@redhat.com> --- scripts/package/mkspec | 5 + 1 file changed, 5 insertions(+) diff --git a/scripts/package/mkspec b/scripts/package/mkspec index fe44d68..b6de63c 100755 --- a/scripts/package/mkspec +++ b/scripts/package/mkspec @@ -138,6 +138,11 @@ echo "/sbin/installkernel $KERNELRELEASE /boot/.vmlinuz-$KERNELRELEASE-rpm /boot echo "rm -f /boot/.vmlinuz-$KERNELRELEASE-rpm /boot/.System.map-$KERNELRELEASE-rpm" echo "fi" echo "" +echo "%preun" +echo "if [ -x /sbin/new-kernel-pkg ]; then" +echo "new-kernel-pkg --remove $KERNELRELEASE --rminitrd --initrdfile=/boot/initramfs-$KERNELRELEASE.img" +echo "fi" +echo "" echo "%files" echo '%defattr (-, root, root)' echo "/lib/modules/$KERNELRELEASE" -- 1.8.3.1
[PATCH] kbuild/mkspec: clean boot loader configuration on rpm removal
This patch add a rpm preuninstall scriptlet to cleanup the boot loader configuration on kernel package uninstall. The initrd for the to-be-removed kernel is deleted, too. Signed-off-by: Paolo Abeni --- scripts/package/mkspec | 5 + 1 file changed, 5 insertions(+) diff --git a/scripts/package/mkspec b/scripts/package/mkspec index fe44d68..b6de63c 100755 --- a/scripts/package/mkspec +++ b/scripts/package/mkspec @@ -138,6 +138,11 @@ echo "/sbin/installkernel $KERNELRELEASE /boot/.vmlinuz-$KERNELRELEASE-rpm /boot echo "rm -f /boot/.vmlinuz-$KERNELRELEASE-rpm /boot/.System.map-$KERNELRELEASE-rpm" echo "fi" echo "" +echo "%preun" +echo "if [ -x /sbin/new-kernel-pkg ]; then" +echo "new-kernel-pkg --remove $KERNELRELEASE --rminitrd --initrdfile=/boot/initramfs-$KERNELRELEASE.img" +echo "fi" +echo "" echo "%files" echo '%defattr (-, root, root)' echo "/lib/modules/$KERNELRELEASE" -- 1.8.3.1
[PATCH 4.2 038/120] clk: pistachio: Fix override of clk-pll settings from boot loader
4.2-stable review patch. If anyone has any objections, please let me know.
--
From: Zdenko Pulitika
commit e53f21c761d141bbcbce06e9ddab3b4e0a828f2c upstream.
PLL enable callbacks are overriding PLL mode (int/frac) and
Noise reduction (on/off) settings set by the boot loader which
results in the incorrect clock rate.
PLL mode and noise reduction are defined by the DSMPD and DACPD bits
of the PLL control register. PLL .enable() callbacks enable PLL
by deasserting all power-down bits of the PLL control register,
including DSMPD and DACPD bits, which is not necessary since
these bits don't actually enable/disable PLL.
This commit fixes the problem by removing DSMPD and DACPD bits
from the "PLL enable" mask.
Fixes: 43049b0c83f17("CLK: Pistachio: Add PLL driver")
Reviewed-by: Andrew Bresitcker
Signed-off-by: Zdenko Pulitika
Signed-off-by: Govindraj Raja
Signed-off-by: Stephen Boyd
Signed-off-by: Greg Kroah-Hartman
---
drivers/clk/pistachio/clk-pll.c |5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
--- a/drivers/clk/pistachio/clk-pll.c
+++ b/drivers/clk/pistachio/clk-pll.c
@@ -134,8 +134,7 @@ static int pll_gf40lp_frac_enable(struct
u32 val;
val = pll_readl(pll, PLL_CTRL3);
- val &= ~(PLL_FRAC_CTRL3_PD | PLL_FRAC_CTRL3_DACPD |
-PLL_FRAC_CTRL3_DSMPD | PLL_FRAC_CTRL3_FOUTPOSTDIVPD |
+ val &= ~(PLL_FRAC_CTRL3_PD | PLL_FRAC_CTRL3_FOUTPOSTDIVPD |
PLL_FRAC_CTRL3_FOUT4PHASEPD | PLL_FRAC_CTRL3_FOUTVCOPD);
pll_writel(pll, val, PLL_CTRL3);
@@ -277,7 +276,7 @@ static int pll_gf40lp_laint_enable(struc
u32 val;
val = pll_readl(pll, PLL_CTRL1);
- val &= ~(PLL_INT_CTRL1_PD | PLL_INT_CTRL1_DSMPD |
+ val &= ~(PLL_INT_CTRL1_PD |
PLL_INT_CTRL1_FOUTPOSTDIVPD | PLL_INT_CTRL1_FOUTVCOPD);
pll_writel(pll, val, PLL_CTRL1);
--
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/
[PATCH 4.1 032/102] clk: pistachio: Fix override of clk-pll settings from boot loader
4.1-stable review patch. If anyone has any objections, please let me know.
--
From: Zdenko Pulitika
commit e53f21c761d141bbcbce06e9ddab3b4e0a828f2c upstream.
PLL enable callbacks are overriding PLL mode (int/frac) and
Noise reduction (on/off) settings set by the boot loader which
results in the incorrect clock rate.
PLL mode and noise reduction are defined by the DSMPD and DACPD bits
of the PLL control register. PLL .enable() callbacks enable PLL
by deasserting all power-down bits of the PLL control register,
including DSMPD and DACPD bits, which is not necessary since
these bits don't actually enable/disable PLL.
This commit fixes the problem by removing DSMPD and DACPD bits
from the "PLL enable" mask.
Fixes: 43049b0c83f17("CLK: Pistachio: Add PLL driver")
Reviewed-by: Andrew Bresitcker
Signed-off-by: Zdenko Pulitika
Signed-off-by: Govindraj Raja
Signed-off-by: Stephen Boyd
Signed-off-by: Greg Kroah-Hartman
---
drivers/clk/pistachio/clk-pll.c |5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
--- a/drivers/clk/pistachio/clk-pll.c
+++ b/drivers/clk/pistachio/clk-pll.c
@@ -115,8 +115,7 @@ static int pll_gf40lp_frac_enable(struct
u32 val;
val = pll_readl(pll, PLL_CTRL3);
- val &= ~(PLL_FRAC_CTRL3_PD | PLL_FRAC_CTRL3_DACPD |
-PLL_FRAC_CTRL3_DSMPD | PLL_FRAC_CTRL3_FOUTPOSTDIVPD |
+ val &= ~(PLL_FRAC_CTRL3_PD | PLL_FRAC_CTRL3_FOUTPOSTDIVPD |
PLL_FRAC_CTRL3_FOUT4PHASEPD | PLL_FRAC_CTRL3_FOUTVCOPD);
pll_writel(pll, val, PLL_CTRL3);
@@ -233,7 +232,7 @@ static int pll_gf40lp_laint_enable(struc
u32 val;
val = pll_readl(pll, PLL_CTRL1);
- val &= ~(PLL_INT_CTRL1_PD | PLL_INT_CTRL1_DSMPD |
+ val &= ~(PLL_INT_CTRL1_PD |
PLL_INT_CTRL1_FOUTPOSTDIVPD | PLL_INT_CTRL1_FOUTVCOPD);
pll_writel(pll, val, PLL_CTRL1);
--
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/
[PATCH 4.1 032/102] clk: pistachio: Fix override of clk-pll settings from boot loader
4.1-stable review patch. If anyone has any objections, please let me know.
--
From: Zdenko Pulitika <zdenko.pulit...@imgtec.com>
commit e53f21c761d141bbcbce06e9ddab3b4e0a828f2c upstream.
PLL enable callbacks are overriding PLL mode (int/frac) and
Noise reduction (on/off) settings set by the boot loader which
results in the incorrect clock rate.
PLL mode and noise reduction are defined by the DSMPD and DACPD bits
of the PLL control register. PLL .enable() callbacks enable PLL
by deasserting all power-down bits of the PLL control register,
including DSMPD and DACPD bits, which is not necessary since
these bits don't actually enable/disable PLL.
This commit fixes the problem by removing DSMPD and DACPD bits
from the "PLL enable" mask.
Fixes: 43049b0c83f17("CLK: Pistachio: Add PLL driver")
Reviewed-by: Andrew Bresitcker <abres...@chromium.org>
Signed-off-by: Zdenko Pulitika <zdenko.pulit...@imgtec.com>
Signed-off-by: Govindraj Raja <govindraj.r...@imgtec.com>
Signed-off-by: Stephen Boyd <sb...@codeaurora.org>
Signed-off-by: Greg Kroah-Hartman <gre...@linuxfoundation.org>
---
drivers/clk/pistachio/clk-pll.c |5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
--- a/drivers/clk/pistachio/clk-pll.c
+++ b/drivers/clk/pistachio/clk-pll.c
@@ -115,8 +115,7 @@ static int pll_gf40lp_frac_enable(struct
u32 val;
val = pll_readl(pll, PLL_CTRL3);
- val &= ~(PLL_FRAC_CTRL3_PD | PLL_FRAC_CTRL3_DACPD |
-PLL_FRAC_CTRL3_DSMPD | PLL_FRAC_CTRL3_FOUTPOSTDIVPD |
+ val &= ~(PLL_FRAC_CTRL3_PD | PLL_FRAC_CTRL3_FOUTPOSTDIVPD |
PLL_FRAC_CTRL3_FOUT4PHASEPD | PLL_FRAC_CTRL3_FOUTVCOPD);
pll_writel(pll, val, PLL_CTRL3);
@@ -233,7 +232,7 @@ static int pll_gf40lp_laint_enable(struc
u32 val;
val = pll_readl(pll, PLL_CTRL1);
- val &= ~(PLL_INT_CTRL1_PD | PLL_INT_CTRL1_DSMPD |
+ val &= ~(PLL_INT_CTRL1_PD |
PLL_INT_CTRL1_FOUTPOSTDIVPD | PLL_INT_CTRL1_FOUTVCOPD);
pll_writel(pll, val, PLL_CTRL1);
--
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/
[PATCH 4.2 038/120] clk: pistachio: Fix override of clk-pll settings from boot loader
4.2-stable review patch. If anyone has any objections, please let me know.
--
From: Zdenko Pulitika <zdenko.pulit...@imgtec.com>
commit e53f21c761d141bbcbce06e9ddab3b4e0a828f2c upstream.
PLL enable callbacks are overriding PLL mode (int/frac) and
Noise reduction (on/off) settings set by the boot loader which
results in the incorrect clock rate.
PLL mode and noise reduction are defined by the DSMPD and DACPD bits
of the PLL control register. PLL .enable() callbacks enable PLL
by deasserting all power-down bits of the PLL control register,
including DSMPD and DACPD bits, which is not necessary since
these bits don't actually enable/disable PLL.
This commit fixes the problem by removing DSMPD and DACPD bits
from the "PLL enable" mask.
Fixes: 43049b0c83f17("CLK: Pistachio: Add PLL driver")
Reviewed-by: Andrew Bresitcker <abres...@chromium.org>
Signed-off-by: Zdenko Pulitika <zdenko.pulit...@imgtec.com>
Signed-off-by: Govindraj Raja <govindraj.r...@imgtec.com>
Signed-off-by: Stephen Boyd <sb...@codeaurora.org>
Signed-off-by: Greg Kroah-Hartman <gre...@linuxfoundation.org>
---
drivers/clk/pistachio/clk-pll.c |5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
--- a/drivers/clk/pistachio/clk-pll.c
+++ b/drivers/clk/pistachio/clk-pll.c
@@ -134,8 +134,7 @@ static int pll_gf40lp_frac_enable(struct
u32 val;
val = pll_readl(pll, PLL_CTRL3);
- val &= ~(PLL_FRAC_CTRL3_PD | PLL_FRAC_CTRL3_DACPD |
-PLL_FRAC_CTRL3_DSMPD | PLL_FRAC_CTRL3_FOUTPOSTDIVPD |
+ val &= ~(PLL_FRAC_CTRL3_PD | PLL_FRAC_CTRL3_FOUTPOSTDIVPD |
PLL_FRAC_CTRL3_FOUT4PHASEPD | PLL_FRAC_CTRL3_FOUTVCOPD);
pll_writel(pll, val, PLL_CTRL3);
@@ -277,7 +276,7 @@ static int pll_gf40lp_laint_enable(struc
u32 val;
val = pll_readl(pll, PLL_CTRL1);
- val &= ~(PLL_INT_CTRL1_PD | PLL_INT_CTRL1_DSMPD |
+ val &= ~(PLL_INT_CTRL1_PD |
PLL_INT_CTRL1_FOUTPOSTDIVPD | PLL_INT_CTRL1_FOUTVCOPD);
pll_writel(pll, val, PLL_CTRL1);
--
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] Documentation: ARM: EXYNOS: Extend boot loader interface documentation
On Sun, 5 Jul 2015 11:56:51 +0900 Krzysztof Kozlowski wrote: > Extend the kernel-bootloader interface documentation with usage of > register INFORM1 (0x0804) and different CPU resume address on Exynos542x > family (with Multi-Cluster Power Management enabled). I have to assume that the new info here is correct...hopefully somebody will scream if that's not true. Applied to the docs tree, thanks. jon -- 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] Documentation: ARM: EXYNOS: Extend boot loader interface documentation
On Sun, 5 Jul 2015 11:56:51 +0900 Krzysztof Kozlowski k.kozlowsk...@gmail.com wrote: Extend the kernel-bootloader interface documentation with usage of register INFORM1 (0x0804) and different CPU resume address on Exynos542x family (with Multi-Cluster Power Management enabled). I have to assume that the new info here is correct...hopefully somebody will scream if that's not true. Applied to the docs tree, thanks. jon -- 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/
[PATCH] Documentation: ARM: EXYNOS: Extend boot loader interface documentation
Extend the kernel-bootloader interface documentation with usage of register INFORM1 (0x0804) and different CPU resume address on Exynos542x family (with Multi-Cluster Power Management enabled). Additionally add glossary and reformat section titles. Signed-off-by: Krzysztof Kozlowski --- Documentation/arm/Samsung/Bootloader-interface.txt | 15 ++- 1 file changed, 14 insertions(+), 1 deletion(-) diff --git a/Documentation/arm/Samsung/Bootloader-interface.txt b/Documentation/arm/Samsung/Bootloader-interface.txt index b96ead9a6919..df8d4fb85939 100644 --- a/Documentation/arm/Samsung/Bootloader-interface.txt +++ b/Documentation/arm/Samsung/Bootloader-interface.txt @@ -15,6 +15,7 @@ executing kernel. 1. Non-Secure mode + Address: sysram_ns_base_addr OffsetValuePurpose = @@ -28,6 +29,7 @@ OffsetValue Purpose 2. Secure mode + Address: sysram_base_addr OffsetValuePurpose = @@ -40,14 +42,25 @@ OffsetValue Purpose Address: pmu_base_addr OffsetValuePurpose = -0x0800exynos_cpu_resumeAFTR +0x0800exynos_cpu_resumeAFTR, suspend +0x0800mcpm_entry_point (Exynos542x with MCPM) AFTR, suspend +0x08040xfcba0d10 (Magic cookie)AFTR +0x08040x0bad (Magic cookie)System suspend 0x0814exynos4_secondary_startup (Exynos4210 r1.1) Secondary CPU boot 0x08180xfcba0d10 (Magic cookie, Exynos4210 r1.1) AFTR 0x081Cexynos_cpu_resume (Exynos4210 r1.1) AFTR 3. Other (regardless of secure/non-secure mode) + Address: pmu_base_addr OffsetValue Purpose = 0x0908Non-zero (only Exynos3250) Secondary CPU boot up indicator + + +4. Glossary + +AFTR - ARM Off Top Running, a low power mode, Cortex cores and many other +modules are power gated, except the TOP modules +MCPM - Multi-Cluster Power Management -- 2.1.4 -- 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/
[PATCH] Documentation: ARM: EXYNOS: Extend boot loader interface documentation
Extend the kernel-bootloader interface documentation with usage of register INFORM1 (0x0804) and different CPU resume address on Exynos542x family (with Multi-Cluster Power Management enabled). Additionally add glossary and reformat section titles. Signed-off-by: Krzysztof Kozlowski k.kozlowsk...@gmail.com --- Documentation/arm/Samsung/Bootloader-interface.txt | 15 ++- 1 file changed, 14 insertions(+), 1 deletion(-) diff --git a/Documentation/arm/Samsung/Bootloader-interface.txt b/Documentation/arm/Samsung/Bootloader-interface.txt index b96ead9a6919..df8d4fb85939 100644 --- a/Documentation/arm/Samsung/Bootloader-interface.txt +++ b/Documentation/arm/Samsung/Bootloader-interface.txt @@ -15,6 +15,7 @@ executing kernel. 1. Non-Secure mode + Address: sysram_ns_base_addr OffsetValuePurpose = @@ -28,6 +29,7 @@ OffsetValue Purpose 2. Secure mode + Address: sysram_base_addr OffsetValuePurpose = @@ -40,14 +42,25 @@ OffsetValue Purpose Address: pmu_base_addr OffsetValuePurpose = -0x0800exynos_cpu_resumeAFTR +0x0800exynos_cpu_resumeAFTR, suspend +0x0800mcpm_entry_point (Exynos542x with MCPM) AFTR, suspend +0x08040xfcba0d10 (Magic cookie)AFTR +0x08040x0bad (Magic cookie)System suspend 0x0814exynos4_secondary_startup (Exynos4210 r1.1) Secondary CPU boot 0x08180xfcba0d10 (Magic cookie, Exynos4210 r1.1) AFTR 0x081Cexynos_cpu_resume (Exynos4210 r1.1) AFTR 3. Other (regardless of secure/non-secure mode) + Address: pmu_base_addr OffsetValue Purpose = 0x0908Non-zero (only Exynos3250) Secondary CPU boot up indicator + + +4. Glossary + +AFTR - ARM Off Top Running, a low power mode, Cortex cores and many other +modules are power gated, except the TOP modules +MCPM - Multi-Cluster Power Management -- 2.1.4 -- 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: boot loader
Am 13.05.2015 um 09:02 schrieb Pavel Machek: Anyone here, who uses a Linux kernel as bootloader / preboot environment ? Yes. See kexec. Can you tell us a bit more about your setup ? Which platforms/archs are you on ? cu -- Enrico Weigelt, metux IT consult +49-151-27565287 MELAG Medizintechnik oHG Sitz Berlin Registergericht AG Charlottenburg HRA 21333 B Wichtiger Hinweis: Diese Nachricht kann vertrauliche oder nur für einen begrenzten Personenkreis bestimmte Informationen enthalten. Sie ist ausschließlich für denjenigen bestimmt, an den sie gerichtet worden ist. Wenn Sie nicht der Adressat dieser E-Mail sind, dürfen Sie diese nicht kopieren, weiterleiten, weitergeben oder sie ganz oder teilweise in irgendeiner Weise nutzen. Sollten Sie diese E-Mail irrtümlich erhalten haben, so benachrichtigen Sie bitte den Absender, indem Sie auf diese Nachricht antworten. Bitte löschen Sie in diesem Fall diese Nachricht und alle Anhänge, ohne eine Kopie zu behalten. Important Notice: This message may contain confidential or privileged information. It is intended only for the person it was addressed to. If you are not the intended recipient of this email you may not copy, forward, disclose or otherwise use it or any part of it in any form whatsoever. If you received this email in error please notify the sender by replying and delete this message and any attachments without retaining a copy. -- 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: boot loader
On Wed 2015-05-13 09:53:09, Enrico Weigelt, metux IT consult wrote: > Am 13.05.2015 um 09:02 schrieb Pavel Machek: > > >>Anyone here, who uses a Linux kernel as bootloader / preboot > >>environment ? > > > >Yes. See kexec. > > Can you tell us a bit more about your setup ? > Which platforms/archs are you on ? It was very useful on sharp zaurus. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- 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: boot loader
On Tue 2015-05-12 13:11:26, Enrico Weigelt, metux IT consult wrote: > Am 12.05.2015 um 02:17 schrieb Thiago Farina: > > >Yeah. Maybe it was a right decision from Linus to isolate, focus and work > >solely on kernel and not including everything else (like FreeBSD does) > >that makes a usable system. > > Just a little sidenote: > > Plan9 uses a trimmed-down Kernel as bootloader, which gives interesting > opportunities (eg. using various services like filesystems, shells, etc > in the bootloader). > > With modern bootloaders like Barebox, the need for that IMHO isn't > that huge anymore. OTOH, there're still several things, I'd wish to > have available in the bootloader (eg. iscsi- or bnlkdev support). > > Anyone here, who uses a Linux kernel as bootloader / preboot > environment ? Yes. See kexec. -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- 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: boot loader
On Tue 2015-05-12 13:11:26, Enrico Weigelt, metux IT consult wrote: Am 12.05.2015 um 02:17 schrieb Thiago Farina: Yeah. Maybe it was a right decision from Linus to isolate, focus and work solely on kernel and not including everything else (like FreeBSD does) that makes a usable system. Just a little sidenote: Plan9 uses a trimmed-down Kernel as bootloader, which gives interesting opportunities (eg. using various services like filesystems, shells, etc in the bootloader). With modern bootloaders like Barebox, the need for that IMHO isn't that huge anymore. OTOH, there're still several things, I'd wish to have available in the bootloader (eg. iscsi- or bnlkdev support). Anyone here, who uses a Linux kernel as bootloader / preboot environment ? Yes. See kexec. -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- 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: boot loader
On Wed 2015-05-13 09:53:09, Enrico Weigelt, metux IT consult wrote: Am 13.05.2015 um 09:02 schrieb Pavel Machek: Anyone here, who uses a Linux kernel as bootloader / preboot environment ? Yes. See kexec. Can you tell us a bit more about your setup ? Which platforms/archs are you on ? It was very useful on sharp zaurus. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- 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: boot loader
Am 13.05.2015 um 09:02 schrieb Pavel Machek: Anyone here, who uses a Linux kernel as bootloader / preboot environment ? Yes. See kexec. Can you tell us a bit more about your setup ? Which platforms/archs are you on ? cu -- Enrico Weigelt, metux IT consult +49-151-27565287 MELAG Medizintechnik oHG Sitz Berlin Registergericht AG Charlottenburg HRA 21333 B Wichtiger Hinweis: Diese Nachricht kann vertrauliche oder nur für einen begrenzten Personenkreis bestimmte Informationen enthalten. Sie ist ausschließlich für denjenigen bestimmt, an den sie gerichtet worden ist. Wenn Sie nicht der Adressat dieser E-Mail sind, dürfen Sie diese nicht kopieren, weiterleiten, weitergeben oder sie ganz oder teilweise in irgendeiner Weise nutzen. Sollten Sie diese E-Mail irrtümlich erhalten haben, so benachrichtigen Sie bitte den Absender, indem Sie auf diese Nachricht antworten. Bitte löschen Sie in diesem Fall diese Nachricht und alle Anhänge, ohne eine Kopie zu behalten. Important Notice: This message may contain confidential or privileged information. It is intended only for the person it was addressed to. If you are not the intended recipient of this email you may not copy, forward, disclose or otherwise use it or any part of it in any form whatsoever. If you received this email in error please notify the sender by replying and delete this message and any attachments without retaining a copy. -- 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: boot loader
Am 12.05.2015 um 02:17 schrieb Thiago Farina: Yeah. Maybe it was a right decision from Linus to isolate, focus and work solely on kernel and not including everything else (like FreeBSD does) that makes a usable system. Just a little sidenote: Plan9 uses a trimmed-down Kernel as bootloader, which gives interesting opportunities (eg. using various services like filesystems, shells, etc in the bootloader). With modern bootloaders like Barebox, the need for that IMHO isn't that huge anymore. OTOH, there're still several things, I'd wish to have available in the bootloader (eg. iscsi- or bnlkdev support). Anyone here, who uses a Linux kernel as bootloader / preboot environment ? cu -- Enrico Weigelt, metux IT consult +49-151-27565287 MELAG Medizintechnik oHG Sitz Berlin Registergericht AG Charlottenburg HRA 21333 B Wichtiger Hinweis: Diese Nachricht kann vertrauliche oder nur für einen begrenzten Personenkreis bestimmte Informationen enthalten. Sie ist ausschließlich für denjenigen bestimmt, an den sie gerichtet worden ist. Wenn Sie nicht der Adressat dieser E-Mail sind, dürfen Sie diese nicht kopieren, weiterleiten, weitergeben oder sie ganz oder teilweise in irgendeiner Weise nutzen. Sollten Sie diese E-Mail irrtümlich erhalten haben, so benachrichtigen Sie bitte den Absender, indem Sie auf diese Nachricht antworten. Bitte löschen Sie in diesem Fall diese Nachricht und alle Anhänge, ohne eine Kopie zu behalten. Important Notice: This message may contain confidential or privileged information. It is intended only for the person it was addressed to. If you are not the intended recipient of this email you may not copy, forward, disclose or otherwise use it or any part of it in any form whatsoever. If you received this email in error please notify the sender by replying and delete this message and any attachments without retaining a copy. -- 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: boot loader
Am 12.05.2015 um 02:17 schrieb Thiago Farina: Yeah. Maybe it was a right decision from Linus to isolate, focus and work solely on kernel and not including everything else (like FreeBSD does) that makes a usable system. Just a little sidenote: Plan9 uses a trimmed-down Kernel as bootloader, which gives interesting opportunities (eg. using various services like filesystems, shells, etc in the bootloader). With modern bootloaders like Barebox, the need for that IMHO isn't that huge anymore. OTOH, there're still several things, I'd wish to have available in the bootloader (eg. iscsi- or bnlkdev support). Anyone here, who uses a Linux kernel as bootloader / preboot environment ? cu -- Enrico Weigelt, metux IT consult +49-151-27565287 MELAG Medizintechnik oHG Sitz Berlin Registergericht AG Charlottenburg HRA 21333 B Wichtiger Hinweis: Diese Nachricht kann vertrauliche oder nur für einen begrenzten Personenkreis bestimmte Informationen enthalten. Sie ist ausschließlich für denjenigen bestimmt, an den sie gerichtet worden ist. Wenn Sie nicht der Adressat dieser E-Mail sind, dürfen Sie diese nicht kopieren, weiterleiten, weitergeben oder sie ganz oder teilweise in irgendeiner Weise nutzen. Sollten Sie diese E-Mail irrtümlich erhalten haben, so benachrichtigen Sie bitte den Absender, indem Sie auf diese Nachricht antworten. Bitte löschen Sie in diesem Fall diese Nachricht und alle Anhänge, ohne eine Kopie zu behalten. Important Notice: This message may contain confidential or privileged information. It is intended only for the person it was addressed to. If you are not the intended recipient of this email you may not copy, forward, disclose or otherwise use it or any part of it in any form whatsoever. If you received this email in error please notify the sender by replying and delete this message and any attachments without retaining a copy. -- 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: boot loader
Hi Pavel, On Mon, May 11, 2015 at 7:11 PM, Pavel Machek wrote: > On Tue 2015-04-28 12:12:26, Thiago Farina wrote: >> Hi, >> >> Does the kernel include a simple boot loader like FreeBSD does? > > Long time ago, Linux included ability to boot from floppy on PC. Not > any more, IIRC. Yeah. Maybe it was a right decision from Linus to isolate, focus and work solely on kernel and not including everything else (like FreeBSD does) that makes a usable system. Regards, -- Thiago Farina -- 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: boot loader
On Tue 2015-04-28 12:12:26, Thiago Farina wrote: > Hi, > > Does the kernel include a simple boot loader like FreeBSD does? Long time ago, Linux included ability to boot from floppy on PC. Not any more, IIRC. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- 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: boot loader
On Tue 2015-04-28 12:12:26, Thiago Farina wrote: Hi, Does the kernel include a simple boot loader like FreeBSD does? Long time ago, Linux included ability to boot from floppy on PC. Not any more, IIRC. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- 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: boot loader
Hi Pavel, On Mon, May 11, 2015 at 7:11 PM, Pavel Machek pa...@ucw.cz wrote: On Tue 2015-04-28 12:12:26, Thiago Farina wrote: Hi, Does the kernel include a simple boot loader like FreeBSD does? Long time ago, Linux included ability to boot from floppy on PC. Not any more, IIRC. Yeah. Maybe it was a right decision from Linus to isolate, focus and work solely on kernel and not including everything else (like FreeBSD does) that makes a usable system. Regards, -- Thiago Farina -- 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: boot loader
On Tue, Apr 28, 2015 at 5:12 PM, Thiago Farina wrote:
> Does the kernel include a simple boot loader like FreeBSD does?
No idea what FreeBSD does, but you can use the kernel as a boot loader
for something else with kexec.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
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: boot loader
On Tue, Apr 28, 2015 at 5:12 PM, Thiago Farina tfrans...@gmail.com wrote:
Does the kernel include a simple boot loader like FreeBSD does?
No idea what FreeBSD does, but you can use the kernel as a boot loader
for something else with kexec.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
--
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: boot loader
On Tue, Apr 28, 2015 at 08:44:34PM -0300, Thiago Farina wrote: > On Tue, Apr 28, 2015 at 6:49 PM, Richard Weinberger > wrote: > > On Tue, Apr 28, 2015 at 5:12 PM, Thiago Farina wrote: > >> Hi, > >> > >> Does the kernel include a simple boot loader like FreeBSD does? > > > > Why don't you figure yourself? > > > I think it doesn't. I just wanted someone to confirm my thought. > Does the FreeBSD kernel really include a boot loader ? Surely the loader is what reads the kernel into memory and then hands control to it. If you look at FreeBSD as a whole, it has a boot loader for whichever architecture it was built for. But linux is only the kernel - different distros (in this context, android could be regarded as a distro) and most importantly different architectures or platforms all do different things - in my fairly-limited experience I've used grub, lilo, uboot, yaboot - there are many others. But please remember that asking general questions not related to kernel development on this list is generally regarded as off-topic. ĸen -- Nanny Ogg usually went to bed early. After all, she was an old lady. Sometimes she went to bed as early as 6 a.m. -- 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: boot loader
On Tue, Apr 28, 2015 at 6:49 PM, Richard Weinberger wrote: > On Tue, Apr 28, 2015 at 5:12 PM, Thiago Farina wrote: >> Hi, >> >> Does the kernel include a simple boot loader like FreeBSD does? > > Why don't you figure yourself? > I think it doesn't. I just wanted someone to confirm my thought. -- Thiago Farina -- 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: boot loader
On Tue, Apr 28, 2015 at 5:12 PM, Thiago Farina wrote: > Hi, > > Does the kernel include a simple boot loader like FreeBSD does? Why don't you figure yourself? -- Thanks, //richard -- 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/
boot loader
Hi, Does the kernel include a simple boot loader like FreeBSD does? -- Thiago Farina -- 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: boot loader
On Tue, Apr 28, 2015 at 6:49 PM, Richard Weinberger richard.weinber...@gmail.com wrote: On Tue, Apr 28, 2015 at 5:12 PM, Thiago Farina tfrans...@gmail.com wrote: Hi, Does the kernel include a simple boot loader like FreeBSD does? Why don't you figure yourself? I think it doesn't. I just wanted someone to confirm my thought. -- Thiago Farina -- 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: boot loader
On Tue, Apr 28, 2015 at 08:44:34PM -0300, Thiago Farina wrote: On Tue, Apr 28, 2015 at 6:49 PM, Richard Weinberger richard.weinber...@gmail.com wrote: On Tue, Apr 28, 2015 at 5:12 PM, Thiago Farina tfrans...@gmail.com wrote: Hi, Does the kernel include a simple boot loader like FreeBSD does? Why don't you figure yourself? I think it doesn't. I just wanted someone to confirm my thought. Does the FreeBSD kernel really include a boot loader ? Surely the loader is what reads the kernel into memory and then hands control to it. If you look at FreeBSD as a whole, it has a boot loader for whichever architecture it was built for. But linux is only the kernel - different distros (in this context, android could be regarded as a distro) and most importantly different architectures or platforms all do different things - in my fairly-limited experience I've used grub, lilo, uboot, yaboot - there are many others. But please remember that asking general questions not related to kernel development on this list is generally regarded as off-topic. ĸen -- Nanny Ogg usually went to bed early. After all, she was an old lady. Sometimes she went to bed as early as 6 a.m. -- 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/
boot loader
Hi, Does the kernel include a simple boot loader like FreeBSD does? -- Thiago Farina -- 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: boot loader
On Tue, Apr 28, 2015 at 5:12 PM, Thiago Farina tfrans...@gmail.com wrote: Hi, Does the kernel include a simple boot loader like FreeBSD does? Why don't you figure yourself? -- Thanks, //richard -- 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/
[PATCH 3.4 063/177] ext4: don't orphan or truncate the boot loader inode
From: Theodore Ts'o
3.4.106-rc1 review patch. If anyone has any objections, please let me know.
--
commit e2bfb088fac03c0f621886a04cffc7faa2b49b1d upstream.
The boot loader inode (inode #5) should never be visible in the
directory hierarchy, but it's possible if the file system is corrupted
that there will be a directory entry that points at inode #5. In
order to avoid accidentally trashing it, when such a directory inode
is opened, the inode will be marked as a bad inode, so that it's not
possible to modify (or read) the inode from userspace.
Unfortunately, when we unlink this (invalid/illegal) directory entry,
we will put the bad inode on the ophan list, and then when try to
unlink the directory, we don't actually remove the bad inode from the
orphan list before freeing in-memory inode structure. This means the
in-memory orphan list is corrupted, leading to a kernel oops.
In addition, avoid truncating a bad inode in ext4_destroy_inode(),
since truncating the boot loader inode is not a smart thing to do.
Reported-by: Sami Liedes
Reviewed-by: Jan Kara
Signed-off-by: Theodore Ts'o
[lizf: Backported to 3.4: adjust context]
Signed-off-by: Zefan Li
---
fs/ext4/inode.c | 8 +++-
fs/ext4/namei.c | 2 +-
2 files changed, 4 insertions(+), 6 deletions(-)
diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c
index 5b6dcba..b9c3995 100644
--- a/fs/ext4/inode.c
+++ b/fs/ext4/inode.c
@@ -157,16 +157,14 @@ void ext4_evict_inode(struct inode *inode)
goto no_delete;
}
- if (!is_bad_inode(inode))
- dquot_initialize(inode);
+ if (is_bad_inode(inode))
+ goto no_delete;
+ dquot_initialize(inode);
if (ext4_should_order_data(inode))
ext4_begin_ordered_truncate(inode, 0);
truncate_inode_pages(>i_data, 0);
- if (is_bad_inode(inode))
- goto no_delete;
-
handle = ext4_journal_start(inode, ext4_blocks_for_truncate(inode)+3);
if (IS_ERR(handle)) {
ext4_std_error(inode->i_sb, PTR_ERR(handle));
diff --git a/fs/ext4/namei.c b/fs/ext4/namei.c
index 665e55c..11566d7 100644
--- a/fs/ext4/namei.c
+++ b/fs/ext4/namei.c
@@ -1992,7 +1992,7 @@ int ext4_orphan_add(handle_t *handle, struct inode *inode)
struct ext4_iloc iloc;
int err = 0, rc;
- if (!ext4_handle_valid(handle))
+ if (!ext4_handle_valid(handle) || is_bad_inode(inode))
return 0;
mutex_lock(_SB(sb)->s_orphan_lock);
--
1.9.1
--
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/
[PATCH 3.4 063/177] ext4: don't orphan or truncate the boot loader inode
From: Theodore Ts'o ty...@mit.edu
3.4.106-rc1 review patch. If anyone has any objections, please let me know.
--
commit e2bfb088fac03c0f621886a04cffc7faa2b49b1d upstream.
The boot loader inode (inode #5) should never be visible in the
directory hierarchy, but it's possible if the file system is corrupted
that there will be a directory entry that points at inode #5. In
order to avoid accidentally trashing it, when such a directory inode
is opened, the inode will be marked as a bad inode, so that it's not
possible to modify (or read) the inode from userspace.
Unfortunately, when we unlink this (invalid/illegal) directory entry,
we will put the bad inode on the ophan list, and then when try to
unlink the directory, we don't actually remove the bad inode from the
orphan list before freeing in-memory inode structure. This means the
in-memory orphan list is corrupted, leading to a kernel oops.
In addition, avoid truncating a bad inode in ext4_destroy_inode(),
since truncating the boot loader inode is not a smart thing to do.
Reported-by: Sami Liedes sami.lie...@iki.fi
Reviewed-by: Jan Kara j...@suse.cz
Signed-off-by: Theodore Ts'o ty...@mit.edu
[lizf: Backported to 3.4: adjust context]
Signed-off-by: Zefan Li lize...@huawei.com
---
fs/ext4/inode.c | 8 +++-
fs/ext4/namei.c | 2 +-
2 files changed, 4 insertions(+), 6 deletions(-)
diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c
index 5b6dcba..b9c3995 100644
--- a/fs/ext4/inode.c
+++ b/fs/ext4/inode.c
@@ -157,16 +157,14 @@ void ext4_evict_inode(struct inode *inode)
goto no_delete;
}
- if (!is_bad_inode(inode))
- dquot_initialize(inode);
+ if (is_bad_inode(inode))
+ goto no_delete;
+ dquot_initialize(inode);
if (ext4_should_order_data(inode))
ext4_begin_ordered_truncate(inode, 0);
truncate_inode_pages(inode-i_data, 0);
- if (is_bad_inode(inode))
- goto no_delete;
-
handle = ext4_journal_start(inode, ext4_blocks_for_truncate(inode)+3);
if (IS_ERR(handle)) {
ext4_std_error(inode-i_sb, PTR_ERR(handle));
diff --git a/fs/ext4/namei.c b/fs/ext4/namei.c
index 665e55c..11566d7 100644
--- a/fs/ext4/namei.c
+++ b/fs/ext4/namei.c
@@ -1992,7 +1992,7 @@ int ext4_orphan_add(handle_t *handle, struct inode *inode)
struct ext4_iloc iloc;
int err = 0, rc;
- if (!ext4_handle_valid(handle))
+ if (!ext4_handle_valid(handle) || is_bad_inode(inode))
return 0;
mutex_lock(EXT4_SB(sb)-s_orphan_lock);
--
1.9.1
--
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/
[PATCH 3.2 046/164] ext4: don't orphan or truncate the boot loader inode
3.2.65-rc1 review patch. If anyone has any objections, please let me know.
--
From: Theodore Ts'o
commit e2bfb088fac03c0f621886a04cffc7faa2b49b1d upstream.
The boot loader inode (inode #5) should never be visible in the
directory hierarchy, but it's possible if the file system is corrupted
that there will be a directory entry that points at inode #5. In
order to avoid accidentally trashing it, when such a directory inode
is opened, the inode will be marked as a bad inode, so that it's not
possible to modify (or read) the inode from userspace.
Unfortunately, when we unlink this (invalid/illegal) directory entry,
we will put the bad inode on the ophan list, and then when try to
unlink the directory, we don't actually remove the bad inode from the
orphan list before freeing in-memory inode structure. This means the
in-memory orphan list is corrupted, leading to a kernel oops.
In addition, avoid truncating a bad inode in ext4_destroy_inode(),
since truncating the boot loader inode is not a smart thing to do.
Reported-by: Sami Liedes
Reviewed-by: Jan Kara
Signed-off-by: Theodore Ts'o
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings
---
fs/ext4/inode.c | 7 +++
fs/ext4/namei.c | 2 +-
2 files changed, 4 insertions(+), 5 deletions(-)
--- a/fs/ext4/inode.c
+++ b/fs/ext4/inode.c
@@ -155,15 +155,14 @@ void ext4_evict_inode(struct inode *inod
goto no_delete;
}
- if (!is_bad_inode(inode))
- dquot_initialize(inode);
+ if (is_bad_inode(inode))
+ goto no_delete;
+ dquot_initialize(inode);
if (ext4_should_order_data(inode))
ext4_begin_ordered_truncate(inode, 0);
truncate_inode_pages(>i_data, 0);
- if (is_bad_inode(inode))
- goto no_delete;
handle = ext4_journal_start(inode, ext4_blocks_for_truncate(inode)+3);
if (IS_ERR(handle)) {
--- a/fs/ext4/namei.c
+++ b/fs/ext4/namei.c
@@ -1979,7 +1979,7 @@ int ext4_orphan_add(handle_t *handle, st
struct ext4_iloc iloc;
int err = 0, rc;
- if (!ext4_handle_valid(handle))
+ if (!ext4_handle_valid(handle) || is_bad_inode(inode))
return 0;
mutex_lock(_SB(sb)->s_orphan_lock);
--
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/
[PATCH 3.2 046/164] ext4: don't orphan or truncate the boot loader inode
3.2.65-rc1 review patch. If anyone has any objections, please let me know.
--
From: Theodore Ts'o ty...@mit.edu
commit e2bfb088fac03c0f621886a04cffc7faa2b49b1d upstream.
The boot loader inode (inode #5) should never be visible in the
directory hierarchy, but it's possible if the file system is corrupted
that there will be a directory entry that points at inode #5. In
order to avoid accidentally trashing it, when such a directory inode
is opened, the inode will be marked as a bad inode, so that it's not
possible to modify (or read) the inode from userspace.
Unfortunately, when we unlink this (invalid/illegal) directory entry,
we will put the bad inode on the ophan list, and then when try to
unlink the directory, we don't actually remove the bad inode from the
orphan list before freeing in-memory inode structure. This means the
in-memory orphan list is corrupted, leading to a kernel oops.
In addition, avoid truncating a bad inode in ext4_destroy_inode(),
since truncating the boot loader inode is not a smart thing to do.
Reported-by: Sami Liedes sami.lie...@iki.fi
Reviewed-by: Jan Kara j...@suse.cz
Signed-off-by: Theodore Ts'o ty...@mit.edu
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings b...@decadent.org.uk
---
fs/ext4/inode.c | 7 +++
fs/ext4/namei.c | 2 +-
2 files changed, 4 insertions(+), 5 deletions(-)
--- a/fs/ext4/inode.c
+++ b/fs/ext4/inode.c
@@ -155,15 +155,14 @@ void ext4_evict_inode(struct inode *inod
goto no_delete;
}
- if (!is_bad_inode(inode))
- dquot_initialize(inode);
+ if (is_bad_inode(inode))
+ goto no_delete;
+ dquot_initialize(inode);
if (ext4_should_order_data(inode))
ext4_begin_ordered_truncate(inode, 0);
truncate_inode_pages(inode-i_data, 0);
- if (is_bad_inode(inode))
- goto no_delete;
handle = ext4_journal_start(inode, ext4_blocks_for_truncate(inode)+3);
if (IS_ERR(handle)) {
--- a/fs/ext4/namei.c
+++ b/fs/ext4/namei.c
@@ -1979,7 +1979,7 @@ int ext4_orphan_add(handle_t *handle, st
struct ext4_iloc iloc;
int err = 0, rc;
- if (!ext4_handle_valid(handle))
+ if (!ext4_handle_valid(handle) || is_bad_inode(inode))
return 0;
mutex_lock(EXT4_SB(sb)-s_orphan_lock);
--
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/
[PATCH 3.17 156/319] ext4: dont orphan or truncate the boot loader inode
3.17-stable review patch. If anyone has any objections, please let me know. -- From: Theodore Ts'o commit e2bfb088fac03c0f621886a04cffc7faa2b49b1d upstream. The boot loader inode (inode #5) should never be visible in the directory hierarchy, but it's possible if the file system is corrupted that there will be a directory entry that points at inode #5. In order to avoid accidentally trashing it, when such a directory inode is opened, the inode will be marked as a bad inode, so that it's not possible to modify (or read) the inode from userspace. Unfortunately, when we unlink this (invalid/illegal) directory entry, we will put the bad inode on the ophan list, and then when try to unlink the directory, we don't actually remove the bad inode from the orphan list before freeing in-memory inode structure. This means the in-memory orphan list is corrupted, leading to a kernel oops. In addition, avoid truncating a bad inode in ext4_destroy_inode(), since truncating the boot loader inode is not a smart thing to do. Reported-by: Sami Liedes Reviewed-by: Jan Kara Signed-off-by: Theodore Ts'o Signed-off-by: Greg Kroah-Hartman --- fs/ext4/inode.c |7 +++ fs/ext4/namei.c |2 +- 2 files changed, 4 insertions(+), 5 deletions(-) --- a/fs/ext4/inode.c +++ b/fs/ext4/inode.c @@ -224,16 +224,15 @@ void ext4_evict_inode(struct inode *inod goto no_delete; } - if (!is_bad_inode(inode)) - dquot_initialize(inode); + if (is_bad_inode(inode)) + goto no_delete; + dquot_initialize(inode); if (ext4_should_order_data(inode)) ext4_begin_ordered_truncate(inode, 0); truncate_inode_pages_final(>i_data); WARN_ON(atomic_read(_I(inode)->i_ioend_count)); - if (is_bad_inode(inode)) - goto no_delete; /* * Protect us against freezing - iput() caller didn't have to have any --- a/fs/ext4/namei.c +++ b/fs/ext4/namei.c @@ -2573,7 +2573,7 @@ int ext4_orphan_add(handle_t *handle, st int err = 0, rc; bool dirty = false; - if (!sbi->s_journal) + if (!sbi->s_journal || is_bad_inode(inode)) return 0; WARN_ON_ONCE(!(inode->i_state & (I_NEW | I_FREEING)) && -- 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/
[PATCH 3.16.y-ckt 022/170] ext4: don't orphan or truncate the boot loader inode
3.16.7-ckt1 -stable review patch. If anyone has any objections, please let me know. -- From: Theodore Ts'o commit e2bfb088fac03c0f621886a04cffc7faa2b49b1d upstream. The boot loader inode (inode #5) should never be visible in the directory hierarchy, but it's possible if the file system is corrupted that there will be a directory entry that points at inode #5. In order to avoid accidentally trashing it, when such a directory inode is opened, the inode will be marked as a bad inode, so that it's not possible to modify (or read) the inode from userspace. Unfortunately, when we unlink this (invalid/illegal) directory entry, we will put the bad inode on the ophan list, and then when try to unlink the directory, we don't actually remove the bad inode from the orphan list before freeing in-memory inode structure. This means the in-memory orphan list is corrupted, leading to a kernel oops. In addition, avoid truncating a bad inode in ext4_destroy_inode(), since truncating the boot loader inode is not a smart thing to do. Reported-by: Sami Liedes Reviewed-by: Jan Kara Signed-off-by: Theodore Ts'o Signed-off-by: Luis Henriques --- fs/ext4/inode.c | 7 +++ fs/ext4/namei.c | 2 +- 2 files changed, 4 insertions(+), 5 deletions(-) diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c index 14f34b02dde5..eee357d03a87 100644 --- a/fs/ext4/inode.c +++ b/fs/ext4/inode.c @@ -224,16 +224,15 @@ void ext4_evict_inode(struct inode *inode) goto no_delete; } - if (!is_bad_inode(inode)) - dquot_initialize(inode); + if (is_bad_inode(inode)) + goto no_delete; + dquot_initialize(inode); if (ext4_should_order_data(inode)) ext4_begin_ordered_truncate(inode, 0); truncate_inode_pages_final(>i_data); WARN_ON(atomic_read(_I(inode)->i_ioend_count)); - if (is_bad_inode(inode)) - goto no_delete; /* * Protect us against freezing - iput() caller didn't have to have any diff --git a/fs/ext4/namei.c b/fs/ext4/namei.c index 5e127be91bb6..1cafd5d98a9b 100644 --- a/fs/ext4/namei.c +++ b/fs/ext4/namei.c @@ -2573,7 +2573,7 @@ int ext4_orphan_add(handle_t *handle, struct inode *inode) int err = 0, rc; bool dirty = false; - if (!sbi->s_journal) + if (!sbi->s_journal || is_bad_inode(inode)) return 0; WARN_ON_ONCE(!(inode->i_state & (I_NEW | I_FREEING)) && -- 2.1.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/
[PATCH 3.16.y-ckt 022/170] ext4: don't orphan or truncate the boot loader inode
3.16.7-ckt1 -stable review patch. If anyone has any objections, please let me know. -- From: Theodore Ts'o ty...@mit.edu commit e2bfb088fac03c0f621886a04cffc7faa2b49b1d upstream. The boot loader inode (inode #5) should never be visible in the directory hierarchy, but it's possible if the file system is corrupted that there will be a directory entry that points at inode #5. In order to avoid accidentally trashing it, when such a directory inode is opened, the inode will be marked as a bad inode, so that it's not possible to modify (or read) the inode from userspace. Unfortunately, when we unlink this (invalid/illegal) directory entry, we will put the bad inode on the ophan list, and then when try to unlink the directory, we don't actually remove the bad inode from the orphan list before freeing in-memory inode structure. This means the in-memory orphan list is corrupted, leading to a kernel oops. In addition, avoid truncating a bad inode in ext4_destroy_inode(), since truncating the boot loader inode is not a smart thing to do. Reported-by: Sami Liedes sami.lie...@iki.fi Reviewed-by: Jan Kara j...@suse.cz Signed-off-by: Theodore Ts'o ty...@mit.edu Signed-off-by: Luis Henriques luis.henriq...@canonical.com --- fs/ext4/inode.c | 7 +++ fs/ext4/namei.c | 2 +- 2 files changed, 4 insertions(+), 5 deletions(-) diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c index 14f34b02dde5..eee357d03a87 100644 --- a/fs/ext4/inode.c +++ b/fs/ext4/inode.c @@ -224,16 +224,15 @@ void ext4_evict_inode(struct inode *inode) goto no_delete; } - if (!is_bad_inode(inode)) - dquot_initialize(inode); + if (is_bad_inode(inode)) + goto no_delete; + dquot_initialize(inode); if (ext4_should_order_data(inode)) ext4_begin_ordered_truncate(inode, 0); truncate_inode_pages_final(inode-i_data); WARN_ON(atomic_read(EXT4_I(inode)-i_ioend_count)); - if (is_bad_inode(inode)) - goto no_delete; /* * Protect us against freezing - iput() caller didn't have to have any diff --git a/fs/ext4/namei.c b/fs/ext4/namei.c index 5e127be91bb6..1cafd5d98a9b 100644 --- a/fs/ext4/namei.c +++ b/fs/ext4/namei.c @@ -2573,7 +2573,7 @@ int ext4_orphan_add(handle_t *handle, struct inode *inode) int err = 0, rc; bool dirty = false; - if (!sbi-s_journal) + if (!sbi-s_journal || is_bad_inode(inode)) return 0; WARN_ON_ONCE(!(inode-i_state (I_NEW | I_FREEING)) -- 2.1.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/
[PATCH 3.17 156/319] ext4: dont orphan or truncate the boot loader inode
3.17-stable review patch. If anyone has any objections, please let me know. -- From: Theodore Ts'o ty...@mit.edu commit e2bfb088fac03c0f621886a04cffc7faa2b49b1d upstream. The boot loader inode (inode #5) should never be visible in the directory hierarchy, but it's possible if the file system is corrupted that there will be a directory entry that points at inode #5. In order to avoid accidentally trashing it, when such a directory inode is opened, the inode will be marked as a bad inode, so that it's not possible to modify (or read) the inode from userspace. Unfortunately, when we unlink this (invalid/illegal) directory entry, we will put the bad inode on the ophan list, and then when try to unlink the directory, we don't actually remove the bad inode from the orphan list before freeing in-memory inode structure. This means the in-memory orphan list is corrupted, leading to a kernel oops. In addition, avoid truncating a bad inode in ext4_destroy_inode(), since truncating the boot loader inode is not a smart thing to do. Reported-by: Sami Liedes sami.lie...@iki.fi Reviewed-by: Jan Kara j...@suse.cz Signed-off-by: Theodore Ts'o ty...@mit.edu Signed-off-by: Greg Kroah-Hartman gre...@linuxfoundation.org --- fs/ext4/inode.c |7 +++ fs/ext4/namei.c |2 +- 2 files changed, 4 insertions(+), 5 deletions(-) --- a/fs/ext4/inode.c +++ b/fs/ext4/inode.c @@ -224,16 +224,15 @@ void ext4_evict_inode(struct inode *inod goto no_delete; } - if (!is_bad_inode(inode)) - dquot_initialize(inode); + if (is_bad_inode(inode)) + goto no_delete; + dquot_initialize(inode); if (ext4_should_order_data(inode)) ext4_begin_ordered_truncate(inode, 0); truncate_inode_pages_final(inode-i_data); WARN_ON(atomic_read(EXT4_I(inode)-i_ioend_count)); - if (is_bad_inode(inode)) - goto no_delete; /* * Protect us against freezing - iput() caller didn't have to have any --- a/fs/ext4/namei.c +++ b/fs/ext4/namei.c @@ -2573,7 +2573,7 @@ int ext4_orphan_add(handle_t *handle, st int err = 0, rc; bool dirty = false; - if (!sbi-s_journal) + if (!sbi-s_journal || is_bad_inode(inode)) return 0; WARN_ON_ONCE(!(inode-i_state (I_NEW | I_FREEING)) -- 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/
[PATCH 3.13 067/162] ext4: don't orphan or truncate the boot loader inode
3.13.11.11 -stable review patch. If anyone has any objections, please let me know. -- From: Theodore Ts'o commit e2bfb088fac03c0f621886a04cffc7faa2b49b1d upstream. The boot loader inode (inode #5) should never be visible in the directory hierarchy, but it's possible if the file system is corrupted that there will be a directory entry that points at inode #5. In order to avoid accidentally trashing it, when such a directory inode is opened, the inode will be marked as a bad inode, so that it's not possible to modify (or read) the inode from userspace. Unfortunately, when we unlink this (invalid/illegal) directory entry, we will put the bad inode on the ophan list, and then when try to unlink the directory, we don't actually remove the bad inode from the orphan list before freeing in-memory inode structure. This means the in-memory orphan list is corrupted, leading to a kernel oops. In addition, avoid truncating a bad inode in ext4_destroy_inode(), since truncating the boot loader inode is not a smart thing to do. Reported-by: Sami Liedes Reviewed-by: Jan Kara Signed-off-by: Theodore Ts'o [ kamal: backport to 3.13-stable (context) ] Signed-off-by: Kamal Mostafa --- fs/ext4/inode.c | 7 +++ fs/ext4/namei.c | 2 +- 2 files changed, 4 insertions(+), 5 deletions(-) diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c index fd6501e3..37d3b1a 100644 --- a/fs/ext4/inode.c +++ b/fs/ext4/inode.c @@ -221,16 +221,15 @@ void ext4_evict_inode(struct inode *inode) goto no_delete; } - if (!is_bad_inode(inode)) - dquot_initialize(inode); + if (is_bad_inode(inode)) + goto no_delete; + dquot_initialize(inode); if (ext4_should_order_data(inode)) ext4_begin_ordered_truncate(inode, 0); truncate_inode_pages(>i_data, 0); WARN_ON(atomic_read(_I(inode)->i_ioend_count)); - if (is_bad_inode(inode)) - goto no_delete; /* * Protect us against freezing - iput() caller didn't have to have any diff --git a/fs/ext4/namei.c b/fs/ext4/namei.c index 5a0408d..d4fa3ed 100644 --- a/fs/ext4/namei.c +++ b/fs/ext4/namei.c @@ -2554,7 +2554,7 @@ int ext4_orphan_add(handle_t *handle, struct inode *inode) struct ext4_iloc iloc; int err = 0, rc; - if (!EXT4_SB(sb)->s_journal) + if (!EXT4_SB(sb)->s_journal || is_bad_inode(inode)) return 0; mutex_lock(_SB(sb)->s_orphan_lock); -- 1.9.1 -- 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/
[PATCH 3.13 067/162] ext4: don't orphan or truncate the boot loader inode
3.13.11.11 -stable review patch. If anyone has any objections, please let me know. -- From: Theodore Ts'o ty...@mit.edu commit e2bfb088fac03c0f621886a04cffc7faa2b49b1d upstream. The boot loader inode (inode #5) should never be visible in the directory hierarchy, but it's possible if the file system is corrupted that there will be a directory entry that points at inode #5. In order to avoid accidentally trashing it, when such a directory inode is opened, the inode will be marked as a bad inode, so that it's not possible to modify (or read) the inode from userspace. Unfortunately, when we unlink this (invalid/illegal) directory entry, we will put the bad inode on the ophan list, and then when try to unlink the directory, we don't actually remove the bad inode from the orphan list before freeing in-memory inode structure. This means the in-memory orphan list is corrupted, leading to a kernel oops. In addition, avoid truncating a bad inode in ext4_destroy_inode(), since truncating the boot loader inode is not a smart thing to do. Reported-by: Sami Liedes sami.lie...@iki.fi Reviewed-by: Jan Kara j...@suse.cz Signed-off-by: Theodore Ts'o ty...@mit.edu [ kamal: backport to 3.13-stable (context) ] Signed-off-by: Kamal Mostafa ka...@canonical.com --- fs/ext4/inode.c | 7 +++ fs/ext4/namei.c | 2 +- 2 files changed, 4 insertions(+), 5 deletions(-) diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c index fd6501e3..37d3b1a 100644 --- a/fs/ext4/inode.c +++ b/fs/ext4/inode.c @@ -221,16 +221,15 @@ void ext4_evict_inode(struct inode *inode) goto no_delete; } - if (!is_bad_inode(inode)) - dquot_initialize(inode); + if (is_bad_inode(inode)) + goto no_delete; + dquot_initialize(inode); if (ext4_should_order_data(inode)) ext4_begin_ordered_truncate(inode, 0); truncate_inode_pages(inode-i_data, 0); WARN_ON(atomic_read(EXT4_I(inode)-i_ioend_count)); - if (is_bad_inode(inode)) - goto no_delete; /* * Protect us against freezing - iput() caller didn't have to have any diff --git a/fs/ext4/namei.c b/fs/ext4/namei.c index 5a0408d..d4fa3ed 100644 --- a/fs/ext4/namei.c +++ b/fs/ext4/namei.c @@ -2554,7 +2554,7 @@ int ext4_orphan_add(handle_t *handle, struct inode *inode) struct ext4_iloc iloc; int err = 0, rc; - if (!EXT4_SB(sb)-s_journal) + if (!EXT4_SB(sb)-s_journal || is_bad_inode(inode)) return 0; mutex_lock(EXT4_SB(sb)-s_orphan_lock); -- 1.9.1 -- 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/
[PATCH 3/5] ktest: Add native support for syslinux boot loader
From: Steven Rostedt
I installed Fedora 17 which no longer supports grub v1. I worked
with grub2 for a while, but there's so many issues with it and automated
rebooting, that I decided to switch to syslinux. Instead of using
the REBOOT_SCRIPT and add customized changes to get syslinux booted,
I thought it better to make ktest aware of syslinux and add options
to simplify the use of syslinux on a target test box.
Acked-by: H. Peter Anvin
Cc: John 'Warthog9' Hawley
Signed-off-by: Steven Rostedt
---
tools/testing/ktest/ktest.pl| 28 +++-
tools/testing/ktest/sample.conf | 22 +-
2 files changed, 48 insertions(+), 2 deletions(-)
diff --git a/tools/testing/ktest/ktest.pl b/tools/testing/ktest/ktest.pl
index f4b8f96..067337b 100755
--- a/tools/testing/ktest/ktest.pl
+++ b/tools/testing/ktest/ktest.pl
@@ -54,6 +54,8 @@ my %default = (
"STOP_TEST_AFTER" => 600,
"MAX_MONITOR_WAIT" => 1800,
"GRUB_REBOOT" => "grub2-reboot",
+"SYSLINUX" => "extlinux",
+"SYSLINUX_PATH"=> "/boot/extlinux",
# required, and we will ask users if they don't have them but we keep the
default
# value something that is common.
@@ -109,6 +111,9 @@ my $grub_menu;
my $grub_file;
my $grub_number;
my $grub_reboot;
+my $syslinux;
+my $syslinux_path;
+my $syslinux_label;
my $target;
my $make;
my $pre_install;
@@ -237,6 +242,9 @@ my %option_map = (
"GRUB_MENU"=> \$grub_menu,
"GRUB_FILE"=> \$grub_file,
"GRUB_REBOOT" => \$grub_reboot,
+"SYSLINUX" => \$syslinux,
+"SYSLINUX_PATH"=> \$syslinux_path,
+"SYSLINUX_LABEL" => \$syslinux_label,
"PRE_INSTALL" => \$pre_install,
"POST_INSTALL" => \$post_install,
"NO_INSTALL" => \$no_install,
@@ -373,7 +381,7 @@ EOF
;
$config_help{"REBOOT_TYPE"} = << "EOF"
Way to reboot the box to the test kernel.
- Only valid options so far are "grub", "grub2", and "script".
+ Only valid options so far are "grub", "grub2", "syslinux", and "script".
If you specify grub, it will assume grub version 1
and will search in /boot/grub/menu.lst for the title \$GRUB_MENU
@@ -386,6 +394,11 @@ $config_help{"REBOOT_TYPE"} = << "EOF"
If you specify grub2, then you also need to specify both \$GRUB_MENU
and \$GRUB_FILE.
+
+ If you specify syslinux, then you may use SYSLINUX to define the syslinux
+ command (defaults to extlinux), and SYSLINUX_PATH to specify the path to
+ the syslinux install (defaults to /boot/extlinux). But you have to specify
+ SYSLINUX_LABEL to define the label to boot to for the test kernel.
EOF
;
$config_help{"GRUB_MENU"} = << "EOF"
@@ -414,6 +427,11 @@ $config_help{"GRUB_FILE"} = << "EOF"
here. Use something like /boot/grub2/grub.cfg to search.
EOF
;
+$config_help{"SYSLINUX_LABEL"} = << "EOF"
+ If syslinux is used, the label that boots the target kernel must
+ be specified with SYSLINUX_LABEL.
+EOF
+;
$config_help{"REBOOT_SCRIPT"} = << "EOF"
A script to reboot the target into the test kernel
(Only mandatory if REBOOT_TYPE = script)
@@ -545,6 +563,10 @@ sub get_ktest_configs {
get_ktest_config("GRUB_MENU");
get_ktest_config("GRUB_FILE");
}
+
+if ($rtype eq "syslinux") {
+ get_ktest_config("SYSLINUX_LABEL");
+}
}
sub process_variables {
@@ -1589,6 +1611,8 @@ sub reboot_to {
run_ssh "'(echo \"savedefault --default=$grub_number --once\" | grub
--batch)'";
} elsif ($reboot_type eq "grub2") {
run_ssh "$grub_reboot $grub_number";
+} elsif ($reboot_type eq "syslinux") {
+ run_ssh "$syslinux --once \\\"$syslinux_label\\\" $syslinux_path";
} elsif (defined $reboot_script) {
run_command "$reboot_script";
}
@@ -3768,6 +3792,8 @@ for (my $i = 1; $i <= $opt{"NUM_TESTS"}; $i++) {
} elsif ($reboot_type eq "grub2") {
dodie "GRUB_MENU not defined" if (!defined($grub_menu));
dodie "GRUB_FILE not defined" if (!defined($grub_file));
+ } elsif ($reboot_type eq "syslinux") {
+ dodie "SYSLINUX_LABEL not defined" if (!defined($syslinux_label));
}
}
diff --git a/tools/testing/ktest/sample.conf b/tools/testing/ktest/sample.conf
index 57617ec..4012e93 100644
--- a/tools/testing/ktest/sample.conf
+++ b/tools/testing/ktest/sample.conf
@@ -364,6 +364,22 @@
#
#GRUB_MENU = Test Kernel
+# For REBOOT_TYPE = syslinux, the name of the syslinux executable
+# (on the target) to use to set up the next reboot to boot the
+# test kernel.
+# (default extlinux)
+#SYSLINUX = syslinux
+
+# For REBOOT_TYPE = syslinux, the path that is passed to to the
+# syslinux command where syslinux is installed.
+# (default /boot/extlinux)
+#SYSLINUX_PATH = /boot/syslinux
+
+# For REBOOT_TYPE = syslinux, the syslinux label that references the
+# test kernel in
[PATCH 3/5] ktest: Add native support for syslinux boot loader
From: Steven Rostedt srost...@redhat.com
I installed Fedora 17 which no longer supports grub v1. I worked
with grub2 for a while, but there's so many issues with it and automated
rebooting, that I decided to switch to syslinux. Instead of using
the REBOOT_SCRIPT and add customized changes to get syslinux booted,
I thought it better to make ktest aware of syslinux and add options
to simplify the use of syslinux on a target test box.
Acked-by: H. Peter Anvin h...@zytor.com
Cc: John 'Warthog9' Hawley warth...@kernel.org
Signed-off-by: Steven Rostedt rost...@goodmis.org
---
tools/testing/ktest/ktest.pl| 28 +++-
tools/testing/ktest/sample.conf | 22 +-
2 files changed, 48 insertions(+), 2 deletions(-)
diff --git a/tools/testing/ktest/ktest.pl b/tools/testing/ktest/ktest.pl
index f4b8f96..067337b 100755
--- a/tools/testing/ktest/ktest.pl
+++ b/tools/testing/ktest/ktest.pl
@@ -54,6 +54,8 @@ my %default = (
STOP_TEST_AFTER = 600,
MAX_MONITOR_WAIT = 1800,
GRUB_REBOOT = grub2-reboot,
+SYSLINUX = extlinux,
+SYSLINUX_PATH= /boot/extlinux,
# required, and we will ask users if they don't have them but we keep the
default
# value something that is common.
@@ -109,6 +111,9 @@ my $grub_menu;
my $grub_file;
my $grub_number;
my $grub_reboot;
+my $syslinux;
+my $syslinux_path;
+my $syslinux_label;
my $target;
my $make;
my $pre_install;
@@ -237,6 +242,9 @@ my %option_map = (
GRUB_MENU= \$grub_menu,
GRUB_FILE= \$grub_file,
GRUB_REBOOT = \$grub_reboot,
+SYSLINUX = \$syslinux,
+SYSLINUX_PATH= \$syslinux_path,
+SYSLINUX_LABEL = \$syslinux_label,
PRE_INSTALL = \$pre_install,
POST_INSTALL = \$post_install,
NO_INSTALL = \$no_install,
@@ -373,7 +381,7 @@ EOF
;
$config_help{REBOOT_TYPE} = EOF
Way to reboot the box to the test kernel.
- Only valid options so far are grub, grub2, and script.
+ Only valid options so far are grub, grub2, syslinux, and script.
If you specify grub, it will assume grub version 1
and will search in /boot/grub/menu.lst for the title \$GRUB_MENU
@@ -386,6 +394,11 @@ $config_help{REBOOT_TYPE} = EOF
If you specify grub2, then you also need to specify both \$GRUB_MENU
and \$GRUB_FILE.
+
+ If you specify syslinux, then you may use SYSLINUX to define the syslinux
+ command (defaults to extlinux), and SYSLINUX_PATH to specify the path to
+ the syslinux install (defaults to /boot/extlinux). But you have to specify
+ SYSLINUX_LABEL to define the label to boot to for the test kernel.
EOF
;
$config_help{GRUB_MENU} = EOF
@@ -414,6 +427,11 @@ $config_help{GRUB_FILE} = EOF
here. Use something like /boot/grub2/grub.cfg to search.
EOF
;
+$config_help{SYSLINUX_LABEL} = EOF
+ If syslinux is used, the label that boots the target kernel must
+ be specified with SYSLINUX_LABEL.
+EOF
+;
$config_help{REBOOT_SCRIPT} = EOF
A script to reboot the target into the test kernel
(Only mandatory if REBOOT_TYPE = script)
@@ -545,6 +563,10 @@ sub get_ktest_configs {
get_ktest_config(GRUB_MENU);
get_ktest_config(GRUB_FILE);
}
+
+if ($rtype eq syslinux) {
+ get_ktest_config(SYSLINUX_LABEL);
+}
}
sub process_variables {
@@ -1589,6 +1611,8 @@ sub reboot_to {
run_ssh '(echo \savedefault --default=$grub_number --once\ | grub
--batch)';
} elsif ($reboot_type eq grub2) {
run_ssh $grub_reboot $grub_number;
+} elsif ($reboot_type eq syslinux) {
+ run_ssh $syslinux --once \\\$syslinux_label\\\ $syslinux_path;
} elsif (defined $reboot_script) {
run_command $reboot_script;
}
@@ -3768,6 +3792,8 @@ for (my $i = 1; $i = $opt{NUM_TESTS}; $i++) {
} elsif ($reboot_type eq grub2) {
dodie GRUB_MENU not defined if (!defined($grub_menu));
dodie GRUB_FILE not defined if (!defined($grub_file));
+ } elsif ($reboot_type eq syslinux) {
+ dodie SYSLINUX_LABEL not defined if (!defined($syslinux_label));
}
}
diff --git a/tools/testing/ktest/sample.conf b/tools/testing/ktest/sample.conf
index 57617ec..4012e93 100644
--- a/tools/testing/ktest/sample.conf
+++ b/tools/testing/ktest/sample.conf
@@ -364,6 +364,22 @@
#
#GRUB_MENU = Test Kernel
+# For REBOOT_TYPE = syslinux, the name of the syslinux executable
+# (on the target) to use to set up the next reboot to boot the
+# test kernel.
+# (default extlinux)
+#SYSLINUX = syslinux
+
+# For REBOOT_TYPE = syslinux, the path that is passed to to the
+# syslinux command where syslinux is installed.
+# (default /boot/extlinux)
+#SYSLINUX_PATH = /boot/syslinux
+
+# For REBOOT_TYPE = syslinux, the syslinux label that references the
+# test kernel in the syslinux config file.
+# (default undefined)
Re: [RFC] libusb / in-kernel usb driver criteria (was: USB driver for talking to the Microchip PIC18 boot loader)
On Wed, Jan 02, 2008 at 07:59:15PM +, Paulo Marques wrote: > Xiaofan Chen wrote: >> On Dec 30, 2007 11:53 AM, mgross <[EMAIL PROTECTED]> wrote: >>> [...] >>> What is the linux-usb policies on new drivers that could be >>> implemented in user space? When does a kernel driver make sense over >>> a libusb one? >> That would be interesting to know. > > I myself have been faced with this question before, and I think we should > try to clarify this by adding a document with some guidelines to > Documentation/usb. > > So, to get the ball rolling, here are some factors that IMHO help decide in > which side to implement a driver: > > - if the driver ties a hardware device to an existing in-kernel interface > (network, block, serial, bluetooth, video4linux, etc.), it should probably > be implemented in-kernel. Agreed, I think this is clear. > > - on the other hand, if the driver doesn't use an existing kernel > interface and creates a new user-visible interface that is going to be used > by a single userspace application, it should probably be done in userspace. > To me this is still grey, and comes down to opinions of style. I happen to like the way code looks when things are split up into drivers (that know a lot about the hardware and protects it from data that will turn it into a brick) and application code that talks to the interface defined by the driver. The libusb based applications I've seen tend to be quite convoluted and do a poor job of separating the USB protocol from the application protocol for talking to the device. I don't think there is a clear way to define when to do a kernel driver vrs just use a libusb thing, other than if no one does a kernel driver for a device then users are stuck with the libusb applications. If someone steps up and does one and is willing to support it, then to me its like, "whatever" add the driver. BTW I don't know if its worth to code bloat for my driver as I ponder this issue now. I like the way non-libusb applications look more but I guess I could create a lib of api-wrappers to the libusb interface and use that, but I really think its less code to create a simple kernel driver. If it where up to me, I would say if the LOC is smaller to have a kernel driver and application then a kernel driver is justified otherwise its not. --mgross > - if it is going to be used by several applications it could still be > implemented as a library, but it starts moving into the gray area. > > - performance might be a reason to move to kernel space, but I don't think > it matters for transfer rates below 10Mbytes/sec or so. > > Anyway, this is just MHO, so feel free to discuss this further. I'm simply > volunteering to sum up this thread into a patch to add a > Documentation/usb/userspace_drivers.txt (or something like that), so that > we can help future developers decide where to write their drivers. > > -- > Paulo Marques - www.grupopie.com > > "Very funny Scotty. Now beam up my clothes." -- 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: [RFC] libusb / in-kernel usb driver criteria (was: USB driver for talking to the Microchip PIC18 boot loader)
On Wed, Jan 02, 2008 at 07:59:15PM +, Paulo Marques wrote: Xiaofan Chen wrote: On Dec 30, 2007 11:53 AM, mgross [EMAIL PROTECTED] wrote: [...] What is the linux-usb policies on new drivers that could be implemented in user space? When does a kernel driver make sense over a libusb one? That would be interesting to know. I myself have been faced with this question before, and I think we should try to clarify this by adding a document with some guidelines to Documentation/usb. So, to get the ball rolling, here are some factors that IMHO help decide in which side to implement a driver: - if the driver ties a hardware device to an existing in-kernel interface (network, block, serial, bluetooth, video4linux, etc.), it should probably be implemented in-kernel. Agreed, I think this is clear. - on the other hand, if the driver doesn't use an existing kernel interface and creates a new user-visible interface that is going to be used by a single userspace application, it should probably be done in userspace. To me this is still grey, and comes down to opinions of style. I happen to like the way code looks when things are split up into drivers (that know a lot about the hardware and protects it from data that will turn it into a brick) and application code that talks to the interface defined by the driver. The libusb based applications I've seen tend to be quite convoluted and do a poor job of separating the USB protocol from the application protocol for talking to the device. I don't think there is a clear way to define when to do a kernel driver vrs just use a libusb thing, other than if no one does a kernel driver for a device then users are stuck with the libusb applications. If someone steps up and does one and is willing to support it, then to me its like, whatever add the driver. BTW I don't know if its worth to code bloat for my driver as I ponder this issue now. I like the way non-libusb applications look more but I guess I could create a lib of api-wrappers to the libusb interface and use that, but I really think its less code to create a simple kernel driver. If it where up to me, I would say if the LOC is smaller to have a kernel driver and application then a kernel driver is justified otherwise its not. --mgross - if it is going to be used by several applications it could still be implemented as a library, but it starts moving into the gray area. - performance might be a reason to move to kernel space, but I don't think it matters for transfer rates below 10Mbytes/sec or so. Anyway, this is just MHO, so feel free to discuss this further. I'm simply volunteering to sum up this thread into a patch to add a Documentation/usb/userspace_drivers.txt (or something like that), so that we can help future developers decide where to write their drivers. -- Paulo Marques - www.grupopie.com Very funny Scotty. Now beam up my clothes. -- 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: [RFC] libusb / in-kernel usb driver criteria (was: USB driver for talking to the Microchip PIC18 boot loader)
Xiaofan Chen wrote: On Dec 30, 2007 11:53 AM, mgross <[EMAIL PROTECTED]> wrote: [...] What is the linux-usb policies on new drivers that could be implemented in user space? When does a kernel driver make sense over a libusb one? That would be interesting to know. I myself have been faced with this question before, and I think we should try to clarify this by adding a document with some guidelines to Documentation/usb. So, to get the ball rolling, here are some factors that IMHO help decide in which side to implement a driver: - if the driver ties a hardware device to an existing in-kernel interface (network, block, serial, bluetooth, video4linux, etc.), it should probably be implemented in-kernel. - on the other hand, if the driver doesn't use an existing kernel interface and creates a new user-visible interface that is going to be used by a single userspace application, it should probably be done in userspace. - if it is going to be used by several applications it could still be implemented as a library, but it starts moving into the gray area. - performance might be a reason to move to kernel space, but I don't think it matters for transfer rates below 10Mbytes/sec or so. Anyway, this is just MHO, so feel free to discuss this further. I'm simply volunteering to sum up this thread into a patch to add a Documentation/usb/userspace_drivers.txt (or something like that), so that we can help future developers decide where to write their drivers. -- Paulo Marques - www.grupopie.com "Very funny Scotty. Now beam up my clothes." -- 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: [RFC] libusb / in-kernel usb driver criteria (was: USB driver for talking to the Microchip PIC18 boot loader)
Xiaofan Chen wrote: On Dec 30, 2007 11:53 AM, mgross [EMAIL PROTECTED] wrote: [...] What is the linux-usb policies on new drivers that could be implemented in user space? When does a kernel driver make sense over a libusb one? That would be interesting to know. I myself have been faced with this question before, and I think we should try to clarify this by adding a document with some guidelines to Documentation/usb. So, to get the ball rolling, here are some factors that IMHO help decide in which side to implement a driver: - if the driver ties a hardware device to an existing in-kernel interface (network, block, serial, bluetooth, video4linux, etc.), it should probably be implemented in-kernel. - on the other hand, if the driver doesn't use an existing kernel interface and creates a new user-visible interface that is going to be used by a single userspace application, it should probably be done in userspace. - if it is going to be used by several applications it could still be implemented as a library, but it starts moving into the gray area. - performance might be a reason to move to kernel space, but I don't think it matters for transfer rates below 10Mbytes/sec or so. Anyway, this is just MHO, so feel free to discuss this further. I'm simply volunteering to sum up this thread into a patch to add a Documentation/usb/userspace_drivers.txt (or something like that), so that we can help future developers decide where to write their drivers. -- Paulo Marques - www.grupopie.com Very funny Scotty. Now beam up my clothes. -- 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/
