From: Baoquan He
> Sent: 18 March 2022 09:37
>
> To replace open coded iter->count. This makes code cleaner.
...
> diff --git a/fs/proc/vmcore.c b/fs/proc/vmcore.c
> index 4cbb8db7c507..ed58a7edc821 100644
> --- a/fs/proc/vmcore.c
> +++ b/fs/proc/vmcore.c
> @@ -319,21 +319,21 @@ static ssize_t
From: Vlastimil Babka
> Sent: 15 December 2021 10:34
>
> On 12/15/21 08:27, Christoph Hellwig wrote:
> > On Wed, Dec 15, 2021 at 07:03:35AM +, Hyeonggon Yoo wrote:
> >> I'm not sure that allocating from ZONE_DMA32 instead of ZONE_DMA
> >> for kdump kernel is nice way to solve this problem.
>
From: Matthew Wilcox
> Sent: 12 December 2021 11:48
>
> On Sat, Dec 11, 2021 at 05:53:46PM +0000, David Laight wrote:
> > From: Tiezhu Yang
> > > Sent: 11 December 2021 03:33
> > >
> > > v2:
> > > -- add copy_to_user_or_kernel() in li
From: Tiezhu Yang
> Sent: 11 December 2021 03:33
>
> v2:
> -- add copy_to_user_or_kernel() in lib/usercopy.c
> -- define userbuf as bool type
Instead of having a flag to indicate whether the buffer is user or kernel,
would it be better to have two separate buffer pointers.
One for a user
From: Arnd Bergmann
> Sent: 17 May 2021 21:34
>
> The compat move_pages() implementation uses compat_alloc_user_space()
> for converting the pointer array. Moving the compat handling into
> the function itself is a bit simpler and lets us avoid the
> compat_alloc_user_space() call.
>
>
From: Arnd Bergmann
> Sent: 17 May 2021 21:34
>
> The compat version of sys_kexec_load() uses compat_alloc_user_space to
> convert the user-provided arguments into the native format.
>
> Move the conversion into the regular implementation with
> an in_compat_syscall() check to simplify it and
From: Petr Mladek
> Sent: 11 May 2021 15:22
>
> On Tue 2021-05-11 12:58:47, David Laight wrote:
> > From: Steven Rostedt
> > > Sent: 11 May 2021 13:53
> > >
> > > On Tue, 11 May 2021 12:36:06 +
> > > David Laight wrote:
> >
From: Steven Rostedt
> Sent: 11 May 2021 13:53
>
> On Tue, 11 May 2021 12:36:06 +0000
> David Laight wrote:
>
> > > x1 : ff93fef15788 x0 : ffe3622352e0
> > > Call trace:
> > > lkdtm_WARNING+0x28/0x30 [lkdtm ed5019fdf5e53be37cb1ba7899292d7e
From: Stephen Boyd
> Sent: 11 May 2021 01:39
>
> This series adds the kernel's build ID[1] to the stacktrace header
> printed in oops messages, warnings, etc. and the build ID for any module
> that appears in the stacktrace after the module name. The goal is to
> make the stacktrace more
From: Joe Perches
> Sent: 15 August 2020 00:52
...
> > This is why I think any discussion that says "people should buffer
> > their lines themselves and we should get rid if pr_cont()" is
> > fundamentally broken.
> >
> > Don't go down that hole. I won't take it. It's wrong.
>
> I don't think
From: Kees Cook
> Sent: 17 July 2020 18:43
> In preparation for further refactoring of kernel_read_file*(), rename
> the "max_size" argument to the more accurate "buf_size", and correct
> its type to size_t. Add kerndoc to explain the specifics of how the
> arguments will be used. Note that with
From: Dominik Brodowski
> Sent: 29 March 2018 15:42
> On Thu, Mar 29, 2018 at 07:20:27AM -0700, Matthew Wilcox wrote:
> > On Thu, Mar 29, 2018 at 01:22:37PM +0200, Dominik Brodowski wrote:
> > > At least on 64-bit x86, it will likely be a hard requirement from v4.17
> > > onwards to not call
From: Linuxppc-dev
[mailto:linuxppc-dev-bounces+david.laight=aculab@lists.ozlabs.org] On
Behalf Of
> > > So given what you have above, you'd use something like:
> > >
> > > struct ima_kexec_hdr {
> > > u16 version;
> > > u16 _reserved0;
> > > u32 _reserved1;
> > > u64 buffer_size;
>
From: Thiago Jung Bauermann
> Sent: 09 August 2016 14:19
...
> > > > +/* Some details preceding the binary serialized measurement list */
> > > > +struct ima_kexec_hdr {
> > > > + unsigned short version;
> > > > + unsigned long buffer_size;
> > > > + unsigned long count;
> > > >
Changed the add_usable_mem_property() to accept FILE* fp instead of
int fd,
as most of the other users of read_memory_region_limits() deals with
FILE*.
Signed-off-by: Suzuki K. Poulose suz...@in.ibm.com
Could you please let me know your thoughts/comments about this patch ?
Is the
15 matches
Mail list logo
