Do NOT upgrade to palo v2.10

Do NOT upgrade to palo v2.10

[Helge Deller]

PALO version 2.10 was released last week, but it has a bug
which may prevent that you are able to boot your kernels:

Entry 000e0000 first 000e0000 n 2
Segment 0 load 000e0000 size 8249207 mediaptr 0x1000
Abort: Would overwrite palo 00060000-000f8e30 or data 3faef580 areas.
ERROR: failed to load kernel

I'm working on this issue, but until a new version
has been released, please don't update palo.

Helge

Re: Do NOT upgrade to palo v2.10

[James Bottomley]

On Tue, 2019-07-30 at 22:58 +0200, Helge Deller wrote:
> PALO version 2.10 was released last week, but it has a bug
> which may prevent that you are able to boot your kernels:
> 
> Entry 000e0000 first 000e0000 n 2
> Segment 0 load 000e0000 size 8249207 mediaptr 0x1000
> Abort: Would overwrite palo 00060000-000f8e30 or data 3faef580 areas.
> ERROR: failed to load kernel

Ah, that's unfortunate.  It must be an artifact of compressed kernels
because my uncompressed one boots here:

Entry 00100000 first 00100000 n 5
Segment 0 load 00100000 size 508616 mediaptr 0x1000
Segment 1 load 0017d000 size 370864 mediaptr 0x7e000
Segment 2 load 00200000 size 12026224 mediaptr 0xd9000
Segment 3 load 00d79000 size 3850884 mediaptr 0xc52000
Segment 4 load 01200000 size 2690120 mediaptr 0xfff000
Loading ramdisk 24263780 bytes @ 3e8ca000...

which would be why I never saw this.

James

Re: Do NOT upgrade to palo v2.10

[James Bottomley]

On Tue, 2019-07-30 at 14:30 -0700, James Bottomley wrote:
> On Tue, 2019-07-30 at 22:58 +0200, Helge Deller wrote:
> > PALO version 2.10 was released last week, but it has a bug
> > which may prevent that you are able to boot your kernels:
> > 
> > Entry 000e0000 first 000e0000 n 2
> > Segment 0 load 000e0000 size 8249207 mediaptr 0x1000
> > Abort: Would overwrite palo 00060000-000f8e30 or data 3faef580
> > areas.
> > ERROR: failed to load kernel
> 
> Ah, that's unfortunate.  It must be an artifact of compressed kernels
> because my uncompressed one boots here:
> 
> Entry 00100000 first 00100000 n 5
> Segment 0 load 00100000 size 508616 mediaptr 0x1000
> Segment 1 load 0017d000 size 370864 mediaptr 0x7e000
> Segment 2 load 00200000 size 12026224 mediaptr 0xd9000
> Segment 3 load 00d79000 size 3850884 mediaptr 0xc52000
> Segment 4 load 01200000 size 2690120 mediaptr 0xfff000
> Loading ramdisk 24263780 bytes @ 3e8ca000...
> 
> which would be why I never saw this.

This is what I'm currently testing as the fix; it reduces the bss from

  6 .bss          0008d8b0  0006b580  0006b580  0000b5f8  2**6
                  ALLOC

To

  6 .bss          0003d8b0  0006b600  0006b600  0000b654  2**6
                  ALLOC

Which will get us under 0x000e0000 assuming that's the lowest address a
kernel can be loaded at ...

James

---
diff --git a/ipl/ext2.c b/ipl/ext2.c
index 31b8469..d8b0c2f 100644
--- a/ipl/ext2.c
+++ b/ipl/ext2.c
@@ -475,17 +475,25 @@ static int ext3_extent_node_find(struct ext2_inode *ip,
 static int ext3_extent_load_find(struct ext2_inode *ip, int leaf, int d,
 				 int blkoff)
 {
-	static char blockbuf[EXTENT_MAX_DEPTH][EXT2_MAX_BLOCK_SIZE];
+	static char *blockbuf;
 	static int cached_blockno[EXTENT_MAX_DEPTH];
 	struct ext3_extent_header *hdr;
 
-	hdr = (struct ext3_extent_header *)blockbuf[d];
+	if (!blockbuf) {
+		blockbuf = malloc(EXTENT_MAX_DEPTH*EXT2_MAX_BLOCK_SIZE);
+		if (!blockbuf) {
+			printf("Failed to allocate memory for block buffer\n");
+			return -1;
+		}
+	}
+
+	hdr = (struct ext3_extent_header *)&blockbuf[d * EXT2_MAX_BLOCK_SIZE];
 	if (cached_blockno[d] != leaf) {
 		printf("load extent tree[%d] block at %d\n", d, leaf);
 
-		if (cons_read(dev, blockbuf[d], sizeof(blockbuf[d]),
+		if (cons_read(dev, hdr, EXT2_MAX_BLOCK_SIZE,
 			      leaf * ext2_blocksize) !=
-		    sizeof(blockbuf[d])) {
+		    EXT2_MAX_BLOCK_SIZE) {
 			printf("ext3_extent_load_find: read error\n");
 			return -1;
 		}
@@ -504,7 +512,7 @@ static int ext3_extent_load_find(struct ext2_inode *ip, int leaf, int d,
 		return -1;
 	}
 	if (sizeof(hdr) + sizeof(struct ext3_extent)*hdr->eh_entries >
-	    sizeof(blockbuf[d])) {
+	    EXT2_MAX_BLOCK_SIZE) {
 		printf("ext3_extent_load_find: extent is larger than buffer\n");
 		return -1;
 	}

Re: Do NOT upgrade to palo v2.10

[Helge Deller]

On 30.07.19 23:47, James Bottomley wrote:
> On Tue, 2019-07-30 at 14:30 -0700, James Bottomley wrote:
>> On Tue, 2019-07-30 at 22:58 +0200, Helge Deller wrote:
>>> PALO version 2.10 was released last week, but it has a bug
>>> which may prevent that you are able to boot your kernels:
>>>
>>> Entry 000e0000 first 000e0000 n 2
>>> Segment 0 load 000e0000 size 8249207 mediaptr 0x1000
>>> Abort: Would overwrite palo 00060000-000f8e30 or data 3faef580
>>> areas.
>>> ERROR: failed to load kernel
>>
>> Ah, that's unfortunate.  It must be an artifact of compressed kernels
>> because my uncompressed one boots here:
>>
>> Entry 00100000 first 00100000 n 5
>> Segment 0 load 00100000 size 508616 mediaptr 0x1000
>> Segment 1 load 0017d000 size 370864 mediaptr 0x7e000
>> Segment 2 load 00200000 size 12026224 mediaptr 0xd9000
>> Segment 3 load 00d79000 size 3850884 mediaptr 0xc52000
>> Segment 4 load 01200000 size 2690120 mediaptr 0xfff000
>> Loading ramdisk 24263780 bytes @ 3e8ca000...
>>
>> which would be why I never saw this.
>
> This is what I'm currently testing as the fix; it reduces the bss from
>
>    6 .bss          0008d8b0  0006b580  0006b580  0000b5f8  2**6
>                    ALLOC
>
> To
>
>    6 .bss          0003d8b0  0006b600  0006b600  0000b654  2**6
>                    ALLOC
>
> Which will get us under 0x000e0000 assuming that's the lowest address a
> kernel can be loaded at ...

It can be loaded everywhere as long it's not conflicting with palo.
The problem is that the released kernels all have 0x000e0000 as
starting point, so if palo is blocking this area we are stuck and
can't load existing kernels any longer.

For the future I think adding this patch to the kernel would make sense (copy&pasted):

diff --git a/arch/parisc/boot/compressed/vmlinux.lds.S b/arch/parisc/boot/compressed/vmlinux.lds.S
index bfd7872739a3..71ccc6796c06 100644
--- a/arch/parisc/boot/compressed/vmlinux.lds.S
+++ b/arch/parisc/boot/compressed/vmlinux.lds.S
@@ -16,7 +16,7 @@ SECTIONS
  {
         /* palo loads at 0x60000 */
         /* loaded kernel will move to 0x10000 */
-       . = 0xe0000;    /* should not overwrite palo code */
+       . = 0xfa000;    /* should not overwrite palo code */


Thanks for the patch below, I'll test tomorrow...

Helge

>
> James
>
> ---
> diff --git a/ipl/ext2.c b/ipl/ext2.c
> index 31b8469..d8b0c2f 100644
> --- a/ipl/ext2.c
> +++ b/ipl/ext2.c
> @@ -475,17 +475,25 @@ static int ext3_extent_node_find(struct ext2_inode *ip,
>   static int ext3_extent_load_find(struct ext2_inode *ip, int leaf, int d,
>   				 int blkoff)
>   {
> -	static char blockbuf[EXTENT_MAX_DEPTH][EXT2_MAX_BLOCK_SIZE];
> +	static char *blockbuf;
>   	static int cached_blockno[EXTENT_MAX_DEPTH];
>   	struct ext3_extent_header *hdr;
>
> -	hdr = (struct ext3_extent_header *)blockbuf[d];
> +	if (!blockbuf) {
> +		blockbuf = malloc(EXTENT_MAX_DEPTH*EXT2_MAX_BLOCK_SIZE);
> +		if (!blockbuf) {
> +			printf("Failed to allocate memory for block buffer\n");
> +			return -1;
> +		}
> +	}
> +
> +	hdr = (struct ext3_extent_header *)&blockbuf[d * EXT2_MAX_BLOCK_SIZE];
>   	if (cached_blockno[d] != leaf) {
>   		printf("load extent tree[%d] block at %d\n", d, leaf);
>
> -		if (cons_read(dev, blockbuf[d], sizeof(blockbuf[d]),
> +		if (cons_read(dev, hdr, EXT2_MAX_BLOCK_SIZE,
>   			      leaf * ext2_blocksize) !=
> -		    sizeof(blockbuf[d])) {
> +		    EXT2_MAX_BLOCK_SIZE) {
>   			printf("ext3_extent_load_find: read error\n");
>   			return -1;
>   		}
> @@ -504,7 +512,7 @@ static int ext3_extent_load_find(struct ext2_inode *ip, int leaf, int d,
>   		return -1;
>   	}
>   	if (sizeof(hdr) + sizeof(struct ext3_extent)*hdr->eh_entries >
> -	    sizeof(blockbuf[d])) {
> +	    EXT2_MAX_BLOCK_SIZE) {
>   		printf("ext3_extent_load_find: extent is larger than buffer\n");
>   		return -1;
>   	}
>

Re: Do NOT upgrade to palo v2.10

[Helge Deller]

On 30.07.19 22:58, Helge Deller wrote:
> PALO version 2.10 was released last week, but it has a bug
> which may prevent that you are able to boot your kernels:
>
> Entry 000e0000 first 000e0000 n 2
> Segment 0 load 000e0000 size 8249207 mediaptr 0x1000
> Abort: Would overwrite palo 00060000-000f8e30 or data 3faef580 areas.
> ERROR: failed to load kernel

I've released a new palo version v2.11 at the official website:
https://git.kernel.org/pub/scm/linux/kernel/git/deller/palo.git/

Until the new debian package reaches the repo, you may use
this prebuilt debian package in the meantime:
http://backup.parisc-linux.org/kernel/palo_2.11_hppa.deb

Helge

Re: Do NOT upgrade to palo v2.10

[James Bottomley]

On Tue, 2019-07-30 at 23:54 +0200, Helge Deller wrote:
[...]
> Thanks for the patch below, I'll test tomorrow...

It passed my test bed.  Just FYI, the code in question is never
exercised unless you see the message:

load extent tree[%d] block at %d

Somewhere in the boot.  The reason is that if you keep a separate /boot
partition, the chances are it has very few files, so those files it has
are very contiguous and ext4 doesn't need to build an extent tree so
our IPL code handles everything in ext3_extent_leaf_find().  The way to
build a fragmented /boot is (starting with an empty /boot):

mkdir /boot/tmp
a=0; while dd if=/dev/zero of=/boot/tmp/block.${a} bs=16k count=1; do a=$[$a+1]; done
a=0 while rm /boot/tmp/block.${a}; do a=$[$a+2]; done

And then copy the kernels in.

James

Re: Do NOT upgrade to palo v2.10

[Helge Deller]

On 31.07.19 16:45, James Bottomley wrote:
> On Tue, 2019-07-30 at 23:54 +0200, Helge Deller wrote:
> [...]
>> Thanks for the patch below, I'll test tomorrow...
>
> It passed my test bed.

Very good.

> Just FYI, the code in question is never
> exercised unless you see the message:
>
> load extent tree[%d] block at %d

Actually, fyi, in the patch I committed I hided that message behind a
Debug flag, so normal users would never see that message.

> Somewhere in the boot.  The reason is that if you keep a separate /boot
> partition, the chances are it has very few files, so those files it has
> are very contiguous and ext4 doesn't need to build an extent tree so
> our IPL code handles everything in ext3_extent_leaf_find().  The way to
> build a fragmented /boot is (starting with an empty /boot):
>
> mkdir /boot/tmp
> a=0; while dd if=/dev/zero of=/boot/tmp/block.${a} bs=16k count=1; do a=$[$a+1]; done
> a=0 while rm /boot/tmp/block.${a}; do a=$[$a+2]; done
>
> And then copy the kernels in.

The fixed PALO version 2.11 is now available in the debian repositories.

Helge