On Thu, Jan 04, 2024 at 04:02:21PM +0100, Joel Granados via B4 Relay wrote:
> From: Joel Granados
>
> What?
The reason I wanted you to do the sentinel removal before the split was
so that there weren't two rounds of patches. Ironically, because you
refused to do it that way, not only are there
opy_oldmem_page() to take an iov_iter")
> Signed-off-by: Dan Carpenter
Reviewed-by: Matthew Wilcox (Oracle)
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
On Thu, Jan 26, 2023 at 04:50:59PM +0200, Mike Rapoport wrote:
> On Thu, Jan 26, 2023 at 11:17:09AM +0200, Mike Rapoport wrote:
> > On Wed, Jan 25, 2023 at 12:38:46AM -0800, Suren Baghdasaryan wrote:
> > > +/* Use when VMA is not part of the VMA tree and needs no locking */
> > > +static inline
On Wed, Jan 25, 2023 at 08:49:50AM -0800, Suren Baghdasaryan wrote:
> On Wed, Jan 25, 2023 at 1:10 AM Peter Zijlstra wrote:
> > > + /*
> > > + * Flags, see mm.h.
> > > + * WARNING! Do not modify directly.
> > > + * Use {init|reset|set|clear|mod}_vm_flags() functions instead.
>
On Wed, Jan 25, 2023 at 12:38:46AM -0800, Suren Baghdasaryan wrote:
> +/* Use when VMA is not part of the VMA tree and needs no locking */
> +static inline void init_vm_flags(struct vm_area_struct *vma,
> + unsigned long flags)
> +{
> + vma->vm_flags = flags;
On Tue, Sep 13, 2022 at 02:25:01PM +0800, Jianglei Nie wrote:
> }
> - elfcorehdr_free(elfcorehdr_addr);
> elfcorehdr_addr = ELFCORE_ADDR_ERR;
>
> proc_vmcore = proc_create("vmcore", S_IRUSR, NULL, _proc_ops);
> if (proc_vmcore)
> proc_vmcore->size =
On Mon, Jul 11, 2022 at 03:49:51PM +0800, Baoquan He wrote:
> On 07/11/22 at 03:34pm, Jianglei Nie wrote:
> > elfcorehdr_alloc() allocates a memory chunk for elfcorehdr_addr with
> > kzalloc(). If is_vmcore_usable() returns false, elfcorehdr_addr is a
> > predefined value. If
On Mon, Apr 11, 2022 at 08:32:26AM +0800, Baoquan He wrote:
> On 04/09/22 at 02:44am, Matthew Wilcox wrote:
> > On Sat, Apr 09, 2022 at 09:02:29AM +0800, Baoquan He wrote:
> > > I tried on x86_64 system, for the 1st step, I got this:
> > >
> > > [ ~]# wget
>
On Sat, Apr 09, 2022 at 09:02:29AM +0800, Baoquan He wrote:
> I tried on x86_64 system, for the 1st step, I got this:
>
> [ ~]# wget
> https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
> ~/bin/make.cross
> /root/bin/make.cross: No such file or directory
... I don't
On Sat, Apr 02, 2022 at 01:29:31PM +0800, Baoquan He wrote:
> On 04/02/22 at 12:30pm, Baoquan He wrote:
>
> It's odd. I cann't see the content of patches in this series from my
> mailbox and mail client, but I can see them in lore.kernel.org.
Yes, Red Hat have screwed up their email server
On Thu, Mar 31, 2022 at 07:25:33PM +0800, Baoquan He wrote:
> Hi Andrew,
>
> On 03/18/22 at 05:37pm, Baoquan He wrote:
> > Copy the description of v3 cover letter from Willy:
>
> Could you pick this series into your tree? I reviewed the patches 1~3
> and tested the whole patchset, no issue
On Fri, Mar 18, 2022 at 01:48:07PM +, David Laight wrote:
> For some definition of 'cleaner' :-)
>
> iter->count is clearly a simple, cheap structure member lookup.
> OTOH iov_iter_count(iter) might be an expensive traversal of
> the vector (or worse).
>
> So a quick read of the code by
On Tue, Dec 14, 2021 at 06:03:11PM +0800, Tiezhu Yang wrote:
> On 12/13/2021 10:43 PM, Matthew Wilcox wrote:
> > On Mon, Dec 13, 2021 at 08:30:33AM +, David Laight wrote:
> > > From: Matthew Wilcox
> > > > Sent: 12 December 2021 11:48
> > > >
> &
On Mon, Dec 13, 2021 at 08:30:33AM +, David Laight wrote:
> From: Matthew Wilcox
> > Sent: 12 December 2021 11:48
> >
> > On Sat, Dec 11, 2021 at 05:53:46PM +, David Laight wrote:
> > > From: Tiezhu Yang
> > > > Sent: 11 December 2021
Remove the read_from_oldmem() wrapper introduced earlier and convert
all the remaining callers to pass an iov_iter.
Signed-off-by: Matthew Wilcox (Oracle)
---
arch/x86/kernel/crash_dump_64.c | 7 +-
fs/proc/vmcore.c| 40 +
include/linux
:
- Send the correct patches this time
v2:
- Removed unnecessary kernel-doc
- Included uio.h to fix compilation problems
- Made read_from_oldmem_iter static to avoid compile warnings during the
conversion
- Use iov_iter_truncate() (Christoph)
Matthew Wilcox (Oracle) (3):
vmcore: Convert
an iov_iter at the same time, so rename it to read_from_oldmem_iter()
and add a temporary read_from_oldmem() wrapper that creates an iov_iter.
Signed-off-by: Matthew Wilcox (Oracle)
---
arch/arm/kernel/crash_dump.c | 27 +++-
arch/arm64/kernel/crash_dump.c | 29 +++--
arch
This gets rid of copy_to() and let us use proc_read_iter() instead
of proc_read().
Signed-off-by: Matthew Wilcox (Oracle)
---
fs/proc/vmcore.c | 81 +---
1 file changed, 29 insertions(+), 52 deletions(-)
diff --git a/fs/proc/vmcore.c b/fs/proc
On Mon, Dec 13, 2021 at 02:19:07PM +, Matthew Wilcox (Oracle) wrote:
> ---
> fs/9p/vfs_dir.c | 5 +
> fs/9p/xattr.c | 6 ++
> include/linux/uio.h | 9 +
> lib/iov_iter.c | 32
> 4 files changed, 44 insertio
This gets rid of copy_to() and let us use proc_read_iter() instead
of proc_read().
Signed-off-by: Matthew Wilcox (Oracle)
---
fs/proc/vmcore.c | 81 +---
1 file changed, 29 insertions(+), 52 deletions(-)
diff --git a/fs/proc/vmcore.c b/fs/proc
:
- Removed unnecessary kernel-doc
- Included uio.h to fix compilation problems
- Made read_from_oldmem_iter static to avoid compile warnings during the
conversion
- Use iov_iter_truncate() (Christoph)
Matthew Wilcox (Oracle) (3):
vmcore: Convert __read_vmcore to use an iov_iter
vmcore: Convert
Remove the read_from_oldmem() wrapper introduced earlier and convert
all the remaining callers to pass an iov_iter.
Signed-off-by: Matthew Wilcox (Oracle)
---
arch/x86/kernel/crash_dump_64.c | 7 +-
fs/proc/vmcore.c| 40 +
include/linux
---
fs/9p/vfs_dir.c | 5 +
fs/9p/xattr.c | 6 ++
include/linux/uio.h | 9 +
lib/iov_iter.c | 32
4 files changed, 44 insertions(+), 8 deletions(-)
diff --git a/fs/9p/vfs_dir.c b/fs/9p/vfs_dir.c
index 8c854d8cb0cd..cad6c24f9f0d
On Mon, Dec 13, 2021 at 09:02:57AM +0100, Christoph Hellwig wrote:
> >
> > ssize_t elfcorehdr_read(char *buf, size_t count, u64 *ppos)
> > {
> > - return read_from_oldmem(buf, count, ppos, 0,
> > + struct kvec kvec = { .iov_base = buf, .iov_len = count };
> > + struct iov_iter iter;
> >
On Mon, Dec 13, 2021 at 12:06:34AM +, Matthew Wilcox (Oracle) wrote:
> +++ b/arch/arm/kernel/crash_dump.c
> @@ -27,9 +27,8 @@
> * @buf. If @buf is in userspace, set @userbuf to %1. Returns number of bytes
> * copied or negative error in case of failure.
> */
> -ssize_
This gets rid of copy_to() and let us use proc_read_iter() instead
of proc_read().
Signed-off-by: Matthew Wilcox (Oracle)
---
fs/proc/vmcore.c | 83 ++--
1 file changed, 31 insertions(+), 52 deletions(-)
diff --git a/fs/proc/vmcore.c b/fs/proc
For some reason several people have been sending bad patches to fix
compiler warnings in vmcore recently. Here's how it should be done.
Compile-tested only on x86. As noted in the first patch, s390 should
take this conversion a bit further, but I'm not inclined to do that
work myself.
Matthew
an iov_iter at the same time, so rename it to read_from_oldmem_iter()
and add a temporary read_from_oldmem() wrapper that creates an iov_iter.
Signed-off-by: Matthew Wilcox (Oracle)
---
arch/arm/kernel/crash_dump.c | 14 ++---
arch/arm64/kernel/crash_dump.c | 14 ++---
arch/ia64/kernel
Remove the read_from_oldmem() wrapper introduced earlier and convert
all the remaining callers to pass an iov_iter.
Signed-off-by: Matthew Wilcox (Oracle)
---
arch/x86/kernel/crash_dump_64.c | 7 +-
fs/proc/vmcore.c| 40 +
include/linux
On Sat, Dec 11, 2021 at 05:53:46PM +, David Laight wrote:
> 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
On Mon, Dec 06, 2021 at 03:54:22PM +0100, Christoph Hellwig wrote:
> On Mon, Dec 06, 2021 at 02:17:24PM +0000, Matthew Wilcox wrote:
> > On Mon, Dec 06, 2021 at 03:04:51PM +0100, Christoph Hellwig wrote:
> > > This looks like a huge mess. What speak against using an i
On Mon, Dec 06, 2021 at 03:04:51PM +0100, Christoph Hellwig wrote:
> This looks like a huge mess. What speak against using an iov_iter
> here?
I coincidentally made a start on this last night. Happy to stop.
What do you think to adding a generic copy_pfn_to_iter()? Not sure
which APIs to use
On Tue, May 11, 2021 at 02:31:38PM +, David Laight wrote:
> Actually, for the use case, the id could be trimmed significantly.
> It is only trying to differentiate between builds of a specific module.
> So even 8 digits would be plenty.
asked and answered. please review the bidding.
On Tue, Oct 13, 2020 at 11:44:29AM -0700, Dan Williams wrote:
> On Fri, Oct 9, 2020 at 12:52 PM wrote:
> >
> > From: Ira Weiny
> >
> > The kmap() calls in this FS are localized to a single thread. To avoid
> > the over head of global PKRS updates use the new kmap_thread() call.
> >
> > Cc:
On Mon, Oct 12, 2020 at 09:28:29AM -0700, Dave Hansen wrote:
> kmap_atomic() is always preferred over kmap()/kmap_thread().
> kmap_atomic() is _much_ more lightweight since its TLB invalidation is
> always CPU-local and never broadcast.
>
> So, basically, unless you *must* sleep while the mapping
On Mon, Oct 12, 2020 at 12:53:54PM -0700, Ira Weiny wrote:
> On Mon, Oct 12, 2020 at 05:44:38PM +0100, Matthew Wilcox wrote:
> > On Mon, Oct 12, 2020 at 09:28:29AM -0700, Dave Hansen wrote:
> > > kmap_atomic() is always preferred over kmap()/kmap_thread().
> > > k
On Fri, Oct 09, 2020 at 02:34:34PM -0700, Eric Biggers wrote:
> On Fri, Oct 09, 2020 at 12:49:57PM -0700, ira.we...@intel.com wrote:
> > The kmap() calls in this FS are localized to a single thread. To avoid
> > the over head of global PKRS updates use the new kmap_thread() call.
> >
> > @@
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 system call functions in the kernel: It is better to
> use use a different calling convention for system calls there, where
> struct
On Sun, Sep 09, 2007 at 10:39:18AM +0200, Bernhard Walle wrote:
Because the total amount of System RAM must be known when calling this
function, efi_memmap_init() is modified to return its comulated
accumulated?
total_memory variable in a pointer value. IMO that's better than making the
39 matches
Mail list logo
