On Thu, 13 Jun 2024 16:06:47 +0200
Ard Biesheuvel wrote:
> Fair enough. As long as it is documented that there is no guarantee
> that this will keep working over a kernel upgrade, then I have no
> objections.
Thanks,
I'll send out v6 and even stress that this may not work for all kernel
On Thu, 13 Jun 2024 09:00:31 +0300
Mike Rapoport wrote:
> > + /* Make sure the name is not already used (size is only updated if
> > found) */
> > + if (reserve_mem_find_by_name(name, , ))
> > + return -EBUSY;
>
> I'd prefer another variable here rather than size. Will be more
On Thu, 13 Jun 2024 08:11:48 +0200
Ard Biesheuvel wrote:
> >
> > I've added one more comment to v5, with that fixed I can take this.
> >
>
> So how is this supposed to work wrt to the rigid 'no user visible
> regressions' rule, given that this whole thing is a best effort thing
This has
emoved "built-in" from module description that was changed from v1.
Changes since v1:
https://lore.kernel.org/all/2024060320.801075...@goodmis.org/
- Updated the change log of the first patch as well as added an entry
into kernel-parameters.txt about how reserve_mem is fo
From: "Steven Rostedt (Google)"
In order to allow for requesting a memory region that can be used for
things like pstore on multiple machines where the memory layout is not the
same, add a new option to the kernel command line called "reserve_mem".
The format is: reser
From: "Steven Rostedt (Google)"
Add a method to find a region specified by reserve_mem=nn:align:name for
ramoops. Adding a kernel command line parameter:
reserve_mem=12M:4096:oops ramoops.mem_name=oops
Will use the size and location defined by the memmap parameter where it
finds
On Wed, 12 Jun 2024 11:45:57 -0700
Kees Cook wrote:
> On Tue, Jun 11, 2024 at 10:49:13AM -0400, Steven Rostedt wrote:
> > From: "Steven Rostedt (Google)"
> >
> > Add a method to find a region specified by reserve_mem=nn:align:name for
> > ramoops. A
On Wed, 12 Jun 2024 07:23:40 +
Wei Yang wrote:
> >> >+struct reserve_mem_table {
> >> >+ charname[RESERVE_MEM_NAME_SIZE];
> >> >+ unsigned long start;
> >> >+ unsigned long size;
> >>
> >> phys_addr_t looks more precise?
> >
> >For just the start
On Wed, 12 Jun 2024 07:30:49 +
Wei Yang wrote:
> >+/* Add wildcard region with a lookup name */
> >+static int __init reserved_mem_add(unsigned long start, unsigned long size,
> >+ const char *name)
> >+{
> >+struct reserve_mem_table *map;
> >+
> >+if
On Tue, 11 Jun 2024 15:26:05 -0700
Guenter Roeck wrote:
> > diff --git a/mm/memblock.c b/mm/memblock.c
> > index d09136e040d3..044ddce8f085 100644
> > --- a/mm/memblock.c
> > +++ b/mm/memblock.c
> > @@ -2244,6 +2244,121 @@ void __init memblock_free_all(void)
> > totalram_pages_add(pages);
>
t-in" from module description that was changed from v1.
Changes since v1:
https://lore.kernel.org/all/2024060320.801075...@goodmis.org/
- Updated the change log of the first patch as well as added an entry
into kernel-parameters.txt about how reserve_mem is for soft reboots
and may n
From: "Steven Rostedt (Google)"
In order to allow for requesting a memory region that can be used for
things like pstore on multiple machines where the memory layout is not the
same, add a new option to the kernel command line called "reserve_mem".
The format is: reser
From: "Steven Rostedt (Google)"
Add a method to find a region specified by reserve_mem=nn:align:name for
ramoops. Adding a kernel command line parameter:
reserve_mem=12M:4096:oops ramoops.mem_name=oops
Will use the size and location defined by the memmap parameter where it
finds
On Tue, 11 Jun 2024 11:12:18 -0400
Steven Rostedt wrote:
> > >+ p++;
> > >+ err = reserved_mem_add(start, size, p);
> > >+ if (err) {
> > >+ memblock_phys_free(start, size);
> > >+ return err;
> > >+ }
> > >
On Tue, 11 Jun 2024 19:30:47 +0300
Mike Rapoport wrote:
> > I don't know if we care what the align is. Zero is valid.
>
> memblock won't like zero align, it should be SMP_CACHE_BYTES at least.
> No point requiring it from user, just update the alignment if the user passed
> zero.
Thanks,
On Tue, 11 Jun 2024 14:40:29 +
Wei Yang wrote:
Missed this just before sending out v3 :-p
> >diff --git a/mm/memblock.c b/mm/memblock.c
> >index d09136e040d3..a8bf0ee9e2b4 100644
> >--- a/mm/memblock.c
> >+++ b/mm/memblock.c
> >@@ -2244,6 +2244,103 @@ void __init memblock_free_all(void)
> >
From: "Steven Rostedt (Google)"
Add a method to find a region specified by reserve_mem=nn:align:name for
ramoops. Adding a kernel command line parameter:
reserve_mem=12M:4096:oops ramoops.mem_name=oops
Will use the size and location defined by the memmap parameter where it
finds
From: "Steven Rostedt (Google)"
In order to allow for requesting a memory region that can be used for
things like pstore on multiple machines where the memory layout is not the
same, add a new option to the kernel command line called "reserve_mem".
The format is: reser
_mem is for soft reboots
and may not be reliable.
Steven Rostedt (Google) (2):
mm/memblock: Add "reserve_mem" to reserved named memory at boot up
pstore/ramoops: Add ramoops.mem_name= command line option
Documentation/admin-guide/kernel-parameters.txt | 20
On Fri, 7 Jun 2024 16:54:41 -0300
"Guilherme G. Piccoli" wrote:
> Some code review in the patches themselves (like a missing
> EXPORT_SYMBOL_GPL), but all in all, that's a great addition! Feel free
> to add my:
>
> Tested-by: Guilherme G. Piccoli
Thanks a lot Guilherme! Much appreciated.
From: "Steven Rostedt (Google)"
Add a method to find a region specified by reserve_mem=nn:align:name for
ramoops. Adding a kernel command line parameter:
reserve_mem=12M:4096:oops ramoops.mem_name=oops
Will use the size and location defined by the memmap parameter where it
finds
From: "Steven Rostedt (Google)"
In order to allow for requesting a memory region that can be used for
things like pstore on multiple machines where the memory layout is not the
same, add a new option to the kernel command line called "reserve_mem".
The format is: reser
ernel-parameters.txt about how reserve_mem is for soft reboots
and may not be reliable.
git://git.kernel.org/pub/scm/linux/kernel/git/trace/linux-trace.git
reserve-mem
Head SHA1: 94c7d2d9093e9a7a899215c65adf28180d44a247
Steven Rostedt (Google) (2):
mm/memblock: Add "reserve_mem&q
On Tue, 4 Jun 2024 16:05:04 +
"Luck, Tony" wrote:
> > I have been using this on two different test machines, as well as a
> > chromebook, and it appears to work on all ofthem. As well as for VMs. I
> > plan on adding this to my workstation and server too (they use EFI).
>
> I think that
On Tue, 4 Jun 2024 08:03:54 +0200
Ard Biesheuvel wrote:
> On Tue, 4 Jun 2024 at 01:35, Steven Rostedt wrote:
> >
> > From: "Steven Rostedt (Google)"
> >
> > In order to allow for requesting a memory region that can be used for
> > things like pstore o
On Mon, 03 Jun 2024 22:52:37 -0700
Kees Cook wrote:
> On June 3, 2024 4:33:31 PM PDT, Steven Rostedt wrote:
> >From: "Steven Rostedt (Google)"
> >
> >In order to allow for requesting a memory region that can be used for
> >things like pstore on mult
From: "Steven Rostedt (Google)"
Add a method to find a region specified by reserve_mem=nn:align:name for
ramoops. Adding a kernel command line parameter:
reserve_mem=12M:4096:oops ramoops.mem_name=oops
Will use the size and location defined by the memmap parameter where it
finds
From: "Steven Rostedt (Google)"
In order to allow for requesting a memory region that can be used for
things like pstore on multiple machines where the memory layout is not the
same, add a new option to the kernel command line called "reserve_mem".
The format is: reser
doesn't know what the extra option is.
- No longer keeping the table as __initdata so that pstore can use it via
a module.
- This is no longer a proof of concept patch series.
Steven Rostedt (Google) (2):
mm/memblock: Add "reserve_mem" to reserved named memory at boot up
On Thu, 9 May 2024 23:24:20 +0300
Mike Rapoport wrote:
> On Thu, May 09, 2024 at 01:31:22PM -0400, Steven Rostedt wrote:
> > On Thu, 9 May 2024 00:00:23 -0400
> > Steven Rostedt wrote:
> >
> > > I tried this approach and it unfortunately picks a different phys
On Thu, 9 May 2024 00:00:23 -0400
Steven Rostedt wrote:
> I tried this approach and it unfortunately picks a different physical
> location every time :-(
>
> So it is either adding to e820 tables or we create a new way to
> allocate memory at early boot up.
>
Hmm, now I
On Wed, 1 May 2024 18:30:40 +0300
Mike Rapoport wrote:
> > So this will allocate the same physical location for every boot, if booting
> > the same kernel and having the same physical memory layout?
>
> Up to kaslr that might use that location for the kernel image.
> But it's the same as
On Mon, 6 May 2024 12:38:32 +0200
Ard Biesheuvel wrote:
> The logic in arch/x86/boot/compressed/kaslr.c is now only used by non-EFI
> boot.
>
> In general, I am highly skeptical that hopes and prayers are enough to
> prevent the firmware from stepping on such a region, unless this is
> only a
On Wed, 1 May 2024 18:30:40 +0300
Mike Rapoport wrote:
> > > /*
> > > * Parse early_reserve_mem=nn:align:name
> > > */
> > > static int __init early_reserve_mem(char *p)
> > > {
> > > phys_addr_t start, size, align;
> > > char *oldp;
> > > int err;
> > >
> > > if (!p)
> > >
On Wed, 1 May 2024 17:45:49 +0300
Mike Rapoport wrote:
> > +static void __init memmap_copy(void)
> > +{
> > + if (!early_mmap_size)
> > + return;
> > +
> > + mmap_list = kcalloc(early_mmap_size + 1, sizeof(mmap_list),
> > GFP_KERNEL);
>
> We can keep early_mmap_size after boot
On Fri, 12 Apr 2024 23:59:07 +0300
Mike Rapoport wrote:
> On Tue, Apr 09, 2024 at 04:41:24PM -0700, Kees Cook wrote:
> > On Tue, Apr 09, 2024 at 07:11:56PM -0400, Steven Rostedt wrote:
> > > On Tue, 9 Apr 2024 15:23:07 -0700
> > > Kees Cook wrote:
> > >
On Fri, 12 Apr 2024 09:17:18 -0300
"Guilherme G. Piccoli" wrote:
> Thanks Steve, seems a good idea. With that, I could test on kdumpst (the
> tool used on Steam Deck), since it relies on modular pstore/ram.
Something like this could work.
-- Steve
diff --git a/arch/x86/kernel/e820.c
On Thu, 11 Apr 2024 16:11:55 -0300
"Guilherme G. Piccoli" wrote:
> Thanks Steve! Like Kees, I've been wanting a consistent way of mapping
> some RAM for pstore for a while, without resorting to platform drivers
> like Chromebooks do...
Great!
>
> The idea seems very interesting and helpful,
On Wed, 10 Apr 2024 11:41:18 -0400
Chuck Lever wrote:
> > If anything, it needs to be:
> >
> > __string_len(acceptor, data, len)
> >
> > as the macro code has changed recently, and the current code will crash!
>
> A general question:
>
> Is there a test suite we should run
On Mon, 01 Apr 2024 23:48:52 +
Justin Stitt wrote:
> diff --git a/include/trace/events/rpcgss.h b/include/trace/events/rpcgss.h
> index ba2d96a1bc2f..274c297f1b15 100644
> --- a/include/trace/events/rpcgss.h
> +++ b/include/trace/events/rpcgss.h
> @@ -618,7 +618,7 @@
On Tue, 9 Apr 2024 22:25:33 +
"Luck, Tony" wrote:
> >> I forgot to mention that this makes it trivial for any machine that doesn't
> >> clear memory on soft-reboot, to enable console ramoops (to have access to
> >> the last boot dmesg without needing serial).
> >>
> >> I tested this on a
On Tue, 9 Apr 2024 15:18:45 -0700
Kees Cook wrote:
> > @@ -914,6 +919,19 @@ static void __init ramoops_register_dummy(void)
> > {
> > struct ramoops_platform_data pdata;
> >
> > +#ifndef MODULE
> > + /* Only allowed when builtin */
>
> Why only when builtin?
Well, because the memory
On Tue, 9 Apr 2024 15:23:07 -0700
Kees Cook wrote:
> Do we need to involve e820 at all? I think it might be possible to just
> have pstore call request_mem_region() very early? Or does KASLR make
> that unstable?
Yeah, would that give the same physical memory each boot, and can we
guarantee
On Tue, 09 Apr 2024 17:02:54 -0400
Steven Rostedt wrote:
> memmap=12M*4096:oops ramoops.mem_name=oops
I forgot to mention that this makes it trivial for any machine that doesn't
clear memory on soft-reboot, to enable console ramoops (to have access to
the last boot dmesg without need
From: "Steven Rostedt (Google)"
In order to allow for requesting a memory region that can be used for
things like pstore on multiple machines where the memory is not the same,
add a new option to the memmap=nn$ kernel command line.
The memmap=nn$addr will reserve nn amount
ch
board. I only tested this locally, it has not been tested in the field. Before
doing anything, I am looking for feedback. Maybe I missed something. Perhaps
there's a better way. Anyway, this is both a Proof of Concept as well as a
Request for Comments.
Thanks!
Steven Rostedt (Google) (2):
From: "Steven Rostedt (Google)"
Add a method to find a region specified by memmap=nn*align:name for
ramoops. Adding a kernel command line parameter:
memmap=12M*4096:oops ramoops.mem_name=oops
Will use the size and location defined by the memmap parameter where it
finds the memory
On Thu, 4 Jan 2024 10:43:53 +0100
Petr Mladek wrote:
> And CAP_SYS_ADMIN has really been deprecated last 13 years, see the
> commit ee24aebffb75a7f940cf ("cap_syslog: accept CAP_SYS_ADMIN for now").
>
> Maybe, it is really time to remove it.
Perhaps what we should do is to remove it in a
return value ignored
> cgroup1_release_agent()
> wasn't checking "too large" error
> proc_cgroup_show()
> already converted "too large" to negative
> v
memcpy(__get_dynamic_array(list), lst,
> __length_of(lst) * sizeof(int));
Acked-by: Steven Rostedt (Google)
-- Steve
On Thu, 26 Oct 2023 23:20:15 +0300
Andy Shevchenko wrote:
> > +#define DECLARE_SEQ_BUF(NAME, SIZE)
> > \
> > + char __ ## NAME ## _buffer[SIZE] = ""; \
> > + struct seq_buf NAME = { .buffer = &__ ## NAME ## _buffer, \
> >
On Thu, 26 Oct 2023 12:40:37 -0700
Kees Cook wrote:
> @@ -81,16 +88,20 @@ static inline unsigned int seq_buf_used(struct seq_buf *s)
> *
> * After this function is called, s->buffer is safe to use
> * in string operations.
> + *
> + * Returns @s->buf after making sure it is terminated.
>
On Thu, 26 Oct 2023 12:35:43 -0700
Kees Cook wrote:
> I'll send a v2 as seq_buf_str()...
Thanks.
-- Steve
On Thu, 26 Oct 2023 10:54:26 -0700
Kees Cook wrote:
> > Do we really need to call it _cstr? Why not just have seq_buf_str() ?
> >
> > I mean, this is C, do we need to state that in the name too?
>
> I'm fine either way. I did that just to make the distinction between our
> length-managed
On Thu, 26 Oct 2023 10:07:28 -0700
Kees Cook wrote:
> Solve two ergonomic issues with struct seq_buf:
"ergonomic"? Does it cause carpal tunnel? ;-)
>
> 1) Too much boilerplate is required to initialize:
>
> struct seq_buf s;
> char buf[32];
>
> seq_buf_init(s, buf,
On Thu, 26 Oct 2023 07:39:44 -0400
James Bottomley wrote:
> While it's nice in theory to have everything documented, it's not much
> use if no one can actually find the information ...
Does kerneldoc provide an automated index? That is, if we had a single file
that had every function in the
On Fri, 20 Oct 2023 05:59:36 +0800
kernel test robot wrote:
> 3a161d99c43ce7 kernel/trace/seq_buf.c Steven Rostedt (Red Hat 2014-06-25
> 323) /**
> 9dbbc3b9d09d6d lib/seq_buf.c Zhen Lei 2021-07-07
> 324 * seq_buf_to_user - copy the sequence buffer t
On Thu, 19 Oct 2023 17:14:39 -0400
Steven Rostedt wrote:
> On Thu, 19 Oct 2023 20:45:13 +0100
> "Matthew Wilcox (Oracle)" wrote:
>
> > Prompted by the recent mails on ksummit, let's actually try to make this
> > work this time. We need a container
On Thu, 19 Oct 2023 20:45:13 +0100
"Matthew Wilcox (Oracle)" wrote:
> Prompted by the recent mails on ksummit, let's actually try to make this
> work this time. We need a container for manipulating strings easily,
> and seq_buf is the closest thing we have to it. The only problem I have
> with
59 matches
Mail list logo
