The previous implementation wrote only the status of each request.
This patch implements a more accurate block device simulator,
providing a ramdisk-like behavior and adding input validation.
Acked-by: Jason Wang
Reviewed-by: Stefan Hajnoczi
Signed-off-by: Stefano Garzarella
---
v2:
- used %zd
The previous implementation wrote only the status of each request.
This patch implements a more accurate block device simulator,
providing a ramdisk-like behavior and adding input validation.
Acked-by: Jason Wang
Reviewed-by: Stefan Hajnoczi
Signed-off-by: Stefano Garzarella
---
v2:
- used %zd
On Thu, Jan 28, 2021 at 03:41:26PM +0100, Stefano Garzarella wrote:
> The previous implementation wrote only the status of each request.
> This patch implements a more accurate block device simulator,
> providing a ramdisk-like behavior.
>
> Signed-off-by: Stefano Garzarella
>
On 2021/1/28 下午10:41, Stefano Garzarella wrote:
The previous implementation wrote only the status of each request.
This patch implements a more accurate block device simulator,
providing a ramdisk-like behavior.
Signed-off-by: Stefano Garzarella
---
v2:
- used %zd %zx to print size_t and
The previous implementation wrote only the status of each request.
This patch implements a more accurate block device simulator,
providing a ramdisk-like behavior.
Signed-off-by: Stefano Garzarella
---
v2:
- used %zd %zx to print size_t and ssize_t variables in dev_err()
- removed unnecessary
On Tue, Nov 17, 2020 at 11:36:36AM +, Stefan Hajnoczi wrote:
On Fri, Nov 13, 2020 at 02:47:12PM +0100, Stefano Garzarella wrote:
diff --git a/drivers/vdpa/vdpa_sim/vdpa_sim_blk.c
b/drivers/vdpa/vdpa_sim/vdpa_sim_blk.c
index 8e41b3ab98d5..68e74383322f 100644
--- a/drivers/vdpa/vdpa_sim/vdpa_
On Fri, Nov 13, 2020 at 02:47:12PM +0100, Stefano Garzarella wrote:
> diff --git a/drivers/vdpa/vdpa_sim/vdpa_sim_blk.c
> b/drivers/vdpa/vdpa_sim/vdpa_sim_blk.c
> index 8e41b3ab98d5..68e74383322f 100644
> --- a/drivers/vdpa/vdpa_sim/vdpa_sim_blk.c
> +++ b/drivers/vdpa/vdpa_sim/vdpa_sim_blk.c
> @@
On Mon, Nov 16, 2020 at 04:50:43AM -0500, Michael S. Tsirkin wrote:
On Fri, Nov 13, 2020 at 02:47:12PM +0100, Stefano Garzarella wrote:
The previous implementation wrote only the status of each request.
This patch implements a more accurate block device simulator,
providing a ramdisk-like
On Mon, Nov 16, 2020 at 01:25:31PM +0800, Jason Wang wrote:
On 2020/11/13 下午9:47, Stefano Garzarella wrote:
The previous implementation wrote only the status of each request.
This patch implements a more accurate block device simulator,
providing a ramdisk-like behavior.
Also handle
On Fri, Nov 13, 2020 at 02:47:12PM +0100, Stefano Garzarella wrote:
> The previous implementation wrote only the status of each request.
> This patch implements a more accurate block device simulator,
> providing a ramdisk-like behavior.
>
> Also handle VIRTIO_BLK_T_GET_ID
On 2020/11/13 下午9:47, Stefano Garzarella wrote:
The previous implementation wrote only the status of each request.
This patch implements a more accurate block device simulator,
providing a ramdisk-like behavior.
Also handle VIRTIO_BLK_T_GET_ID request, always answering the
"vdpa_bl
The previous implementation wrote only the status of each request.
This patch implements a more accurate block device simulator,
providing a ramdisk-like behavior.
Also handle VIRTIO_BLK_T_GET_ID request, always answering the
"vdpa_blk_sim" string.
Signed-off-by: Stefano Garzarella
--
Remove use of "rdev" from blockdev/ramdisk.rst and update
admin-guide/kernel-parameters.txt.
"rdev" is considered antiquated, ancient, archaic, obsolete, deprecated
{choose any or all}.
"rdev" was removed from util-linux in 2010:
https://git.kernel.org/pub/scm/utils/util-linux/util-linux.git/c
Remove use of "rdev" from blockdev/ramdisk.rst and update
admin-guide/kernel-parameters.txt.
"rdev" is considered antiquated, ancient, archaic, obsolete, deprecated
{choose any or all}.
"rdev" was removed from util-linux in 2010:
https://git.kernel.org/pub/scm/utils/util-linux/util-linux.git/c
On Mon, Aug 06, 2018 at 01:52:35PM +0300, Mike Rapoport wrote:
> The detection and reservation of ramdisk memory were separated to allow
> bootmem bitmap initialization after the ramdisk boundaries are detected.
> Since the bootmem initialization is removed, the reservation of ramdisk
&g
The detection and reservation of ramdisk memory were separated to allow
bootmem bitmap initialization after the ramdisk boundaries are detected.
Since the bootmem initialization is removed, the reservation of ramdisk
memory is done immediately after its boundaries are found.
Split the entire
Hi Mike.
On Thu, Aug 02, 2018 at 02:53:53PM +0300, Mike Rapoport wrote:
> The detection and reservation of ramdisk memory were separated to allow
> bootmem bitmap initialization after the ramdisk boundaries are detected.
> Since the bootmem initialization is removed, the reservation o
The detection and reservation of ramdisk memory were separated to allow
bootmem bitmap initialization after the ramdisk boundaries are detected.
Since the bootmem initialization is removed, the reservation of ramdisk
memory can be done immediately after its boundaries are found.
Signed-off-by
Hi,
On Sat, Mar 03, 2018 at 06:14:33PM +0200, Andy Shevchenko wrote:
> On Fri, Mar 2, 2018 at 10:55 PM, Aaro Koskinen wrote:
> > Use pr_cont() at the end of ramdisk loading. This will avoid the rotator
> > and an extra newline appearing in the dmesg.
>
> >
On Fri, Mar 2, 2018 at 10:55 PM, Aaro Koskinen wrote:
> Use pr_cont() at the end of ramdisk loading. This will avoid the rotator
> and an extra newline appearing in the dmesg.
> printk("Error closing the disk.\n");
What about this one?
--
Use pr_cont() at the end of ramdisk loading. This will avoid the rotator
and an extra newline appearing in the dmesg.
Before:
[0.868650] RAMDISK: Loading 2436KiB [1 disk] into ram disk... |
[1.490464] done.
After:
[0.868587] RAMDISK: Loading 2436KiB [1 disk] into ram disk... done
From: Rob Landley
Clarify help text that compression applies to ramfs as well as legacy ramdisk.
Signed-off-by: Rob Landley
---
usr/Kconfig | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/usr/Kconfig b/usr/Kconfig
index 572dcf7..d6f4633 100644
--- a/usr
On Tue, Dec 20, 2016 at 05:48:21PM -0500, Boris Ostrovsky wrote:
> Both AMD and Intel tests passed. Bare-metal and various guests.
Very cool, thanks a lot for testing!
--
Regards/Gruss,
Boris.
Good mailing practices for 400: avoid top-posting and trim the reply.
On 12/20/2016 02:31 PM, Borislav Petkov wrote:
> On Tue, Dec 20, 2016 at 02:26:40PM -0500, Boris Ostrovsky wrote:
>> Without your Sunday's patches but with my AMD-related fixes (cpuid and
>> eq_id=0)
> Can you test tip/x86/urgent with my patch ontop please?
>
> This:
> http://git.kernel.org/cgit/l
On Tue, Dec 20, 2016 at 02:26:40PM -0500, Boris Ostrovsky wrote:
> Without your Sunday's patches but with my AMD-related fixes (cpuid and
> eq_id=0)
Can you test tip/x86/urgent with my patch ontop please?
This: http://git.kernel.org/cgit/linux/kernel/git/tip/tip.git/log/?h=x86/urgent
Thanks.
--
On 12/20/2016 09:40 AM, Borislav Petkov wrote:
>
> Yes please. Here's a minimal patch for 4.10. Please run it on your setup
> to verify it fixes your issue. It boots fine on my boxes here, FWIW.
>
Without your Sunday's patches but with my AMD-related fixes (cpuid and
eq_id=0)
Tested-by: Boris Ost
l 32-bit .config
always relocates the ramdisk. And that was taken care of. But not the
case where it didn't relocate it. I.e., your case.
The fix below should generalize the situation to *always*
read initrd_start when we're running late, with VAs and after
reserve_initrd() has run and pot
Intel
(which is where I observed it).
Ah, that was an important fact. Yes, I can repro it now.
Ok, questions:
* does your guest relocate the ramdisk?
This is not a guest. I crashed with baremetal kernel.
I.e., do you see something like this in dmesg before the splat:
[0.00
was an important fact. Yes, I can repro it now.
Ok, questions:
* does your guest relocate the ramdisk?
This is not a guest. I crashed with baremetal kernel.
I.e., do you see something like this in dmesg before the splat:
[0.00] RAMDISK: [mem 0x7f84c000-0x7ffc]
[0.00
act. Yes, I can repro it now.
Ok, questions:
* does your guest relocate the ramdisk?
I.e., do you see something like this in dmesg before the splat:
[0.00] RAMDISK: [mem 0x7f84c000-0x7ffc]
[0.00] Allocated new RAMDISK: [mem 0x3647a000-0x36bfd9e6]
[0.00] Move RAMDISK
On Mon, Dec 19, 2016 at 01:12:25PM -0500, Boris Ostrovsky wrote:
> IIUIC find_microcode_in_initrd() is called with paging on only on Intel
> (which is where I observed it).
Ah, that was an important fact. Yes, I can repro it now.
Thanks.
--
Regards/Gruss,
Boris.
Good mailing practices for
[0.00] x86/fpu: Legacy x87 FPU detected.
> [0.00] e820: BIOS-provided physical RAM map:
> ...
> [0.00] RAMDISK: [mem 0x37845000-0x37c19fff]
> [0.00] Allocated new RAMDISK: [mem 0x3647-0x36844f5e]
> [0.00] Move RAMDISK from [mem 0x37845000-0x37c
ded physical RAM map:
...
[ 0.00] RAMDISK: [mem 0x37845000-0x37c19fff]
[0.00] Allocated new RAMDISK: [mem 0x3647-0x36844f5e]
[0.00] Move RAMDISK from [mem 0x37845000-0x37c19f5e] to [mem
0x3647-0x36844f5e]
...
[0.243326] smpboot: CPU0: AMD E-350 Processor (family: 0x14, model:
On Mon, Dec 19, 2016 at 11:10:29AM -0500, Boris Ostrovsky wrote:
> config attached. I'll see how I can get you the initrd.
Wait a bit, lemme see if I can repro with my initrd here.
Thanks.
--
Regards/Gruss,
Boris.
Good mailing practices for 400: avoid top-posting and trim the reply.
On 12/19/2016 10:37 AM, Borislav Petkov wrote:
> On Mon, Dec 19, 2016 at 10:32:13AM -0500, Boris Ostrovsky wrote:
>> When searching for microcode in the ramdisk image we need to adjust the
>> start address after paging has been turned on (in 32-bit mode).
> I need more info:
>
On Mon, Dec 19, 2016 at 10:32:13AM -0500, Boris Ostrovsky wrote:
> When searching for microcode in the ramdisk image we need to adjust the
> start address after paging has been turned on (in 32-bit mode).
I need more info:
* Is this fixing a real issue?
* how do you reproduce this?
*
When searching for microcode in the ramdisk image we need to adjust the
start address after paging has been turned on (in 32-bit mode).
Signed-off-by: Boris Ostrovsky
---
arch/x86/kernel/cpu/microcode/core.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/arch/x86/kernel
Otherwise each individual rotator char would be printed in a new line:
(...)
[0.642350] -
[0.644374] |
[0.646367] -
(...)
Signed-off-by: Nicolas Schichan
---
init/do_mounts_rd.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/init/do_mounts_rd.c b/init/do_mounts_
On Thu, Jul 14, 2016 at 9:05 PM, Lee, Chun-Yi wrote:
> This patch adds logic to treat virtual ramdisk SPA as pmem region, then
> ramdisk's /dev/pmem* device can be mounted with iso9660.
>
> It's useful to work with the httpboot in EFI firmware to pull a remote
> ISO
This patch adds logic to treat virtual ramdisk SPA as pmem region, then
ramdisk's /dev/pmem* device can be mounted with iso9660.
It's useful to work with the httpboot in EFI firmware to pull a remote
ISO file to the local memory region for booting and installation.
Wiki page of UEF
This patch adds logic to treat virtual ramdisk SPA as pmem region, then
ramdisk's /dev/pmem* device can be mounted with iso9660.
It's useful to work with the httpboot in EFI firmware to pull a remote
ISO file to the local memory region for booting and installation.
Wiki page of UEF
This patch adds logic to treat virtual ramdisk SPA as pmem region, then
ramdisk's /dev/pmem* device can be mounted with iso9660.
It's useful to work with the httpboot in EFI firmware to pull a remote
ISO file to the local memory region for booting and installation.
Wiki page of UEF
ramdisk parameters only once
The check and definitions related to ramdisk are similar in the
early_reserve_initrd() and reserve_initrd() functions.
This patch introduces 'struct ramdisk' which contains information
about initrd. This structure will be filled in the setup_arch()
and pas
On Sat, Feb 27, 2016 at 12:55:46PM +0100, Ingo Molnar wrote:
> So I find it highly annoying that this review feedback was done by Boris, but
> not
> implemented in v8 :-(
And I missed it when going over v8. :-(
FWIW, since recently I get the impression that people don't take review
feedback ser
* Borislav Petkov wrote:
> > void __init setup_arch(char **cmdline_p)
> > {
> > + struct ramdisk ramdisk = {
> > + .start_addr = get_ramdisk_image(),
> > + .size = PAGE_ALIGN(get_ramdisk_size()),
> > + .reserve_ramdisk
On Fri, Feb 26, 2016 at 03:04:36PM +0600, Alexander Kuleshov wrote:
> The check and definitions related to ramdisk are similar in the
> early_reserve_initrd() and reserve_initrd() functions.
>
> This patch introduces struct ramdisk which contains information
> about initrd. This st
The check and definitions related to ramdisk are similar in the
early_reserve_initrd() and reserve_initrd() functions.
This patch introduces struct ramdisk which contains information
about initrd. This structure will be filled in the setup_arch()
and passed to the reserve_initrd() and
x d3d80e6..449b4da 100644
> --- a/arch/x86/kernel/setup.c
> +++ b/arch/x86/kernel/setup.c
> @@ -169,6 +169,15 @@ static struct resource bss_resource = {
> .flags = IORESOURCE_BUSY | IORESOURCE_MEM
> };
>
> +/*
> + * ramdisk setup
> + */
No need for that comm
The check and definitions related to ramdisk are similar in the
early_reserve_initrd() and reserve_initrd() functions.
This patch introduces struct ramdisk which contains information
about initrd. This structure will be filled in the setup_arch()
and passed to the reserve_initrd() and
The check and definitions related to ramdisk are similar in the
early_reserve_initrd() and reserve_initrd() functions.
This patch introduces struct ramdisk which contains information
about initrd. This structure will be filled in the setup_arch()
and passed to the reserve_initrd() and
*/
> + else
> + memblock_reserve(ramdisk_image.start_addr, ramdisk_image.size);
... and _now_ it's clear that it makes sense to keep early_reserve_initrd(),
move
that new chunk of code to it and pass in the ramdisk structure.
Also, please rename the too long 'ramdisk_image' local var
The check and definitions related to ramdisk are similar in the
early_reserve_initrd() and reserve_initrd() functions.
This patch introduces struct ramdisk which contains information
about initrd. This structure will be filled in the setup_arch()
and passed to the reserve_initrd() and
* Alexander Kuleshov wrote:
> void __init setup_arch(char **cmdline_p)
> {
> + struct ramdisk ramdisk_image = {
> + .start_addr = get_ramdisk_image(),
> + .size = get_ramdisk_size(),
> + .reserve_ramdisk = true
> + };
> +
&g
The check and definitions related to ramdisk are similar in the
early_reserve_initrd() and reserve_initrd() functions.
This patch introduces struct ramdisk which contains information
about initrd. This structure will be filled in the setup_arch()
and passed to the reserve_initrd() and
/Alexander-Kuleshov/x86-setup-get-ramdisk-parameters-only-once/20160209-210207
config: i386-alldefconfig (attached as .config)
reproduce:
# save the attached .config to linux build tree
make ARCH=i386
All errors (new ones prefixed by >>):
arch/x86/kernel/setup.c: In fu
* Alexander Kuleshov wrote:
> +/*
> + * ramdisk setup
> + */
> +struct ramdisk {
> + u64 image;
> + u64 size;
> + u64 end;
> +};
So what exactly are 'image' and 'end'? The names are not self-descriptory.
Please
add comments that describ
The check and definitions related to ramdisk are similar in the
early_reserve_initrd() and reserve_initrd() functions. We can
get size and address of ramdisk in the setup_arch() and than
pass ramdisk structure with filled ramdisk related parameters
to early_reserve_initrd(), reserve_initrd() and
On Thu, Nov 12, 2015 at 11:18:30AM +0100, Andreas Ziegler wrote:
> Hi Florian,
>
> your patch "MIPS: BMIPS: Enable GZIP ramdisk and timed printks"
> showed up as commit fb9e5642aa9e in linux-next today (that is,
> next-20151112). I noticed it because we (a research grou
Hi Florian,
your patch "MIPS: BMIPS: Enable GZIP ramdisk and timed printks"
showed up as commit fb9e5642aa9e in linux-next today (that is,
next-20151112). I noticed it because we (a research group from
Erlangen[0]) are running daily checks on linux-next.
Your commit adds two entries to
On 10/07/2015 03:31 PM, santosh shilimkar wrote:
> Nishant,
>
> On 10/7/2015 12:56 PM, Nishanth Menon wrote:
>> On 10/07/2015 02:37 PM, Arnd Bergmann wrote:
>>> On Wednesday 07 October 2015 14:28:09 Nishanth Menon wrote:
>>>> Add ramdisk support to allo
Nishant,
On 10/7/2015 12:56 PM, Nishanth Menon wrote:
On 10/07/2015 02:37 PM, Arnd Bergmann wrote:
On Wednesday 07 October 2015 14:28:09 Nishanth Menon wrote:
Add ramdisk support to allow for minimal kernel to be supported.
Signed-off-by: Nishanth Menon
I have not seen that in a while
On 10/7/2015 12:37 PM, Arnd Bergmann wrote:
On Wednesday 07 October 2015 14:28:09 Nishanth Menon wrote:
Add ramdisk support to allow for minimal kernel to be supported.
Signed-off-by: Nishanth Menon
I have not seen that in a while. Can you explain why the normal
initramfs method doesn&#
On 10/07/2015 02:37 PM, Arnd Bergmann wrote:
> On Wednesday 07 October 2015 14:28:09 Nishanth Menon wrote:
>> Add ramdisk support to allow for minimal kernel to be supported.
>>
>> Signed-off-by: Nishanth Menon
>>
>
> I have not seen that in a while. Can you e
On Wednesday 07 October 2015 14:28:09 Nishanth Menon wrote:
> Add ramdisk support to allow for minimal kernel to be supported.
>
> Signed-off-by: Nishanth Menon
>
I have not seen that in a while. Can you explain why the normal
initramfs method doesn't work on keystone?
Add ramdisk support to allow for minimal kernel to be supported.
Signed-off-by: Nishanth Menon
---
Based on next-20151007 (with SPI disabled)
test: http://pastebin.ubuntu.com/12707715/
arch/arm/configs/keystone_defconfig | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/configs
On Tue, Jul 7, 2015 at 1:20 PM, Yinghai Lu wrote:
> When using kexec with 64bit kernel, bzImage and ramdisk could be
> loaded above 4G. We need this to get correct ramdisk adress.
>
> Make get_ramdisk_image() global and use it for early microcode updating.
This looks correct, thank
When using kexec with 64bit kernel, bzImage and ramdisk could be
loaded above 4G. We need this to get correct ramdisk adress.
Make get_ramdisk_image() global and use it for early microcode updating.
-v2: update changelog.
Signed-off-by: Yinghai Lu
---
arch/x86/include/asm/setup.h
Hi,
I am running into failures when run filebench on ramdisk(/dev/ram0)
with Ext4-DAX.
The kernel version is 4.0, and I also verified it occurs on 4.2-rc1.
The issue reproduction steps:
// Set ramdisk size to 2GB
# mkfs.ext4 /dev/ram0
# mount -o dax /dev/ram0 /mnt/ramdisk
# filebench
filebench
Hi,
I'm testing mmap() performance on a ramdisk. The kernel is 3.19-rc3.
The device driver is brd, and the file system is ext2. Normal mmap()
does not make sense on a ramdisk because it adds additional memory
copy, so XIP is enabled to map the pages directly into application's
add
On Fri, Aug 22, 2014 at 6:59 AM, wrote:
> From: Harald Hoyer
>
> commit 4bf7111f50167133a71c23530ca852a41355e739 enabled loading of the
> initramfs above 4G addresses. So I was wondering, if the early microcode
> code might want to honor the upper 32bit of the 64bit address.
>
https://lkml.org/
From: Harald Hoyer
commit 4bf7111f50167133a71c23530ca852a41355e739 enabled loading of the
initramfs above 4G addresses. So I was wondering, if the early microcode
code might want to honor the upper 32bit of the 64bit address.
Signed-off-by: Harald Hoyer
---
arch/x86/kernel/cpu/microcode/amd_ea
When using kexec with 64bit kernel, bzImage and ramdisk could be
loaded above 4G. We need this to get correct ramdisk adress.
Make get_ramdisk_image() global and use it for early microcode updating.
-v2: update changelog.
Signed-off-by: Yinghai Lu
---
arch/x86/include/asm/setup.h
On Fri, Jun 27, 2014 at 4:58 PM, H. Peter Anvin wrote:
> On 06/10/2014 10:04 PM, Yinghai Lu wrote:
>> When using kexec with 64bit kernel, bzImage and ramdisk could be
>> loaded above 4G. We need this to get correct ramdisk adress.
>>
>> Make get_ramdisk_image()
On 06/10/2014 10:04 PM, Yinghai Lu wrote:
> When using kexec with 64bit kernel, bzImage and ramdisk could be
> loaded above 4G. We need this to get correct ramdisk adress.
>
> Make get_ramdisk_image() global and use it for early microcode updating.
> Also make it to take boot_par
On Wed, Jun 11, 2014 at 10:34 AM, Yinghai Lu wrote:
> On Wed, Jun 11, 2014 at 10:32 AM, H. Peter Anvin wrote:
>>
>> It is not about loading over 4G, it is that some kinds of code (in
>> particular accessing global variables) from the early microcode loading
>> code doesn't work on 32 bits, so it
On Wed, Jun 11, 2014 at 10:32 AM, H. Peter Anvin wrote:
>
> It is not about loading over 4G, it is that some kinds of code (in
> particular accessing global variables) from the early microcode loading
> code doesn't work on 32 bits, so it needs to be tested.
Ok, will test 32bit path.
Thanks
Yin
On 06/11/2014 10:30 AM, Yinghai Lu wrote:
> On Tue, Jun 10, 2014 at 11:08 PM, H. Peter Anvin wrote:
>> On 06/10/2014 10:04 PM, Yinghai Lu wrote:
>>> When using kexec with 64bit kernel, bzImage and ramdisk could be
>>> loaded above 4G. We need this to get correct r
On Tue, Jun 10, 2014 at 11:08 PM, H. Peter Anvin wrote:
> On 06/10/2014 10:04 PM, Yinghai Lu wrote:
>> When using kexec with 64bit kernel, bzImage and ramdisk could be
>> loaded above 4G. We need this to get correct ramdisk adress.
>>
>> Make get_ramdisk_image()
On 06/10/2014 10:04 PM, Yinghai Lu wrote:
> When using kexec with 64bit kernel, bzImage and ramdisk could be
> loaded above 4G. We need this to get correct ramdisk adress.
>
> Make get_ramdisk_image() global and use it for early microcode
> updating. Also make it to take boot_par
When using kexec with 64bit kernel, bzImage and ramdisk could be
loaded above 4G. We need this to get correct ramdisk adress.
Make get_ramdisk_image() global and use it for early microcode updating.
Also make it to take boot_params pointer for different usage.
Signed-off-by: Yinghai Lu
max ramdisk size name
The name in struct bootparam is ->initrd_addr_max and not ramdisk_max.
Fix that.
Signed-off-by: Borislav Petkov
Link: http://lkml.kernel.org/r/1394633584-5509-2-git-send-email...@alien8.de
Signed-off-by: H. Peter Anvin
---
Documentation/x86/boot.txt | 4 ++--
arch/x86/b
From: Borislav Petkov
The name in struct bootparam is ->initrd_addr_max and not ramdisk_max.
Fix that.
Signed-off-by: Borislav Petkov
---
Documentation/x86/boot.txt | 4 ++--
arch/x86/boot/header.S | 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/Documentation/x86/boo
From: Borislav Petkov
The name in struct bootparam is ->initrd_addr_max and not ramdisk_max.
Fix that.
Signed-off-by: Borislav Petkov
---
Documentation/x86/boot.txt | 4 ++--
arch/x86/boot/header.S | 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/Documentation/x86/boo
On Wed, Jan 08, 2014 at 04:56:45PM +0800, fal...@meizu.com wrote:
> From: Wu Zhangjin
>
> During embedded linux system booting, before decompressing the kernel image,
> the bootloader(E.g. Uboot) loads the compressed kernel image and ramdisk into
> two contiguous memory space, t
From: Wu Zhangjin
During embedded linux system booting, before decompressing the kernel image,
the bootloader(E.g. Uboot) loads the compressed kernel image and ramdisk into
two contiguous memory space, these two memory space are fixed after the Uboot
is released, as a result, the maximum size of
On 12/08/13 03:28, Fabian Frederick wrote:
> -ramdisk_blocksize doesn't exist anymore
> -Module parameters added to documentation
>
> Signed-off-by: Fabian Frederick
Acked-by: Randy Dunlap
Thanks.
> ---
> Documentation/blockdev/ramdisk.txt | 21 +++--
> 1 file changed, 15 in
-ramdisk_blocksize doesn't exist anymore
-Module parameters added to documentation
Signed-off-by: Fabian Frederick
---
Documentation/blockdev/ramdisk.txt | 21 +++--
1 file changed, 15 insertions(+), 6 deletions(-)
diff --git a/Documentation/blockdev/ramdisk.txt
b/Documentation
On 12/08/13 00:35, Fabian Frederick wrote:
>
> I had no reaction to this patch (also about ramdisk)
> https://lkml.org/lkml/2013/12/6/748
> Should I merge it to this one ?
Your choice. You could merge them and then add
Jens Axboe and Andrew Morton as recipients on the new pa
>
> See ramdisk_size.
> or
> Same as ramdisk_size.
ok.
>
> >
> > 3) Using "rdev -r"
> > --
>
>
> As for the Changelog, it would be better just to delete all of it.
> That's what git is for (and good at).
On 12/06/13 15:52, Fabian Frederick wrote:
> -ramdisk_blocksize doesn't exist anymore.
> -Module parameters added to documentation.
>
> Signed-off-by: Fabian Frederick
> ---
> Documentation/blockdev/ramdisk.txt | 23 ++-
> 1 file changed, 18 insertions(+), 5 deletions(-)
>
>
-ramdisk_blocksize doesn't exist anymore.
-Module parameters added to documentation.
Signed-off-by: Fabian Frederick
---
Documentation/blockdev/ramdisk.txt | 23 ++-
1 file changed, 18 insertions(+), 5 deletions(-)
diff --git a/Documentation/blockdev/ramdisk.txt
b/Documenta
From: Borislav Petkov
The ramdisk can possibly get relocated if the whole image is not mapped.
And since we're going over it in the microcode loader and fishing
out the relevant microcode patches, we want to access it at its new
location. Thus, export it.
Signed-off-by: Borislav P
From: Wu Zhangjin
During the booting of an embedded Linux system, before decompressing the kernel
image, the bootloader(E.g. Uboot) loads the compressed kernel image and ramdisk
image into two contiguous memory spaces, these two memory spaces are fixed
after the Uboot is released, as a result
version, I missed to include init/do_mounts_rd.c
changes in the previous one.
Thank you.
--
Prasad J Pandit / Red Hat Security Response TeamFrom 14dccee98f12f2dbca224510bcfedd1a397ed177 Mon Sep 17 00:00:00 2001
From: P J P
Date: Thu, 10 Oct 2013 20:37:48 +0530
Subject: Export initial ramdisk
:53:24 +0530
Subject: Export initial ramdisk compression config option
Make menuconfig allows one to choose compression format of an
initial ramdisk image. But this choice does not result in duly
compressed ramdisk image. Because - $ make install - does not
pass on the selected compression choice to
Hello Andrew,
+-- On Wed, 9 Oct 2013, Andrew Morton wrote --+
| It would be better to make the change in one place, rather than for each
| architecture. That would appear to involve moving a hunk from
| arch/x86/Makefile into init/Makefile, or perhaps ./Makefile.
Right, I was trying to fi
On Wed, 25 Sep 2013 01:11:54 +0530 (IST) P J P wrote:
> | A few things...
> | - Why is it specific to x86? Other architcetures use initramfs?
>
> No, it is not specific to x86, most likely all architecturess' Makefile
> would need similar patch. But I haven't looked into those yet.
It would
Hello Andrew,
Just to check, did you have a chance to review it further? Are you waiting on
me for something?
--
Prasad J Pandit / Red Hat Security Response Team
DB7A 84C5 D3F9 7CD1 B5EB C939 D048 7860 3655 602B
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the
Hello Andrew,
I was wondering if you had a chance to review this patch further? Should I
send similar patches for other architectures too? As in you aren't waiting on
me for that, are you?
Thank you.
--
Prasad J Pandit / Red Hat Security Response Team
DB7A 84C5 D3F9 7CD1 B5EB C939 D048 7860
+-- On Wed, 25 Sep 2013, Rob Landley wrote --+
| Ah, so it's an out of tree bespoke Red Hat tool. No wonder I couldn't find it.
It is not Red Hat tool.
| You're reimplemented the posix "pax" command?
Ummn, not sure. Didn't see anything about 'pax'.
| Is this what you're currently doing, or
1 - 100 of 456 matches
Mail list logo
