On Thu, Aug 10, 2023 at 08:09:27AM +0800, Ming Lei wrote:
> 1) some archs support 'nr_cpus=1' for kdump kernel, which is fine, since
> num_possible_cpus becomes 1.
>
> 2) some archs do not support 'nr_cpus=1', and have to rely on
> 'max_cpus=1', so num_possible_cpus isn't changed, and kernel just
On Thu, May 25, 2023 at 04:14:30PM +0200, Jan Kara wrote:
> Yes, this is exactly how I'd imagine it. Thanks for writing the patch!
>
> I'd just note that this would need rebasing on top of Luis' patches 1 and
> 2. Also:
I'd not do that for now. 1 needs a lot more work, and 2 seems rather
On Mon, May 22, 2023 at 04:42:00PM -0700, Darrick J. Wong wrote:
> How about this as an alternative patch? Kernel and userspace freeze
> state are stored in s_writers; each type cannot block the other (though
> you still can't have nested kernel or userspace freezes); and the freeze
> is
On Sun, May 07, 2023 at 06:17:13PM -0700, Luis Chamberlain wrote:
> Provide helpers so that we can check a superblock frozen state.
> This will make subsequent changes easier to read. This makes
> no functional changes.
I'll look at the further changes, but having frozen/unfrozen helpers
that
block locked.
>
> Suggested-by: Christoph Hellwig
> Signed-off-by: Luis Chamberlain
Maybe I'm just getting old, but where did I suggest this?
That being said, holding an active reference over any operation is a
good thing. As Jan said it can be done way simpler than this, though.
Also plea
gned-off-by: Baoquan He
Looks good:
Reviewed-by: Christoph Hellwig
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
On Fri, Apr 08, 2022 at 05:06:35PM +0800, Baoquan He wrote:
> From: "Matthew Wilcox (Oracle)"
>
> This gets rid of copy_to() and let us use proc_read_iter() instead
> of proc_read().
>
> Signed-off-by: Matthew Wilcox (Oracle)
> Signed-off-by: Baoquan He
Look
Looks good:
Reviewed-by: Christoph Hellwig
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
Looks good:
Reviewed-by: Christoph Hellwig
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
On Tue, Apr 05, 2022 at 12:40:31PM -0700, Omar Sandoval wrote:
> A simple way to "fix" this would be to make set_iounmap_nonlazy() set
> vmap_lazy_nr to lazy_max_pages() instead of lazy_max_pages() + 1. But, I
> think it'd be better to get rid of this hack of clobbering vmap_lazy_nr.
> Instead,
Looks good,
Reviewed-by: Christoph Hellwig
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
On Wed, Dec 22, 2021 at 12:37:03PM +, Hyeonggon Yoo wrote:
> Oh I misunderstood this. Underlying physical address of vmalloc()-allocated
> memory
> can be mapped using DMA API, and it needs to be setup as scatterlist because
> the allocated memory is not physically continuous. Right?
Yes.
>
On Fri, Dec 17, 2021 at 11:38:27AM +, Hyeonggon Yoo wrote:
> My understanding is any buffer requested from kmalloc (without
> GFP_DMA/DMA32) can be used by device driver because it allocates
> continuous physical memory. It doesn't mean that buffer allocated
> with kmalloc is free of
Looks good,
Reviewed-by: Christoph Hellwig
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
On Mon, Dec 13, 2021 at 02:39:27PM +, Matthew Wilcox (Oracle) wrote:
> Remove the read_from_oldmem() wrapper introduced earlier and convert
> all the remaining callers to pass an iov_iter.
Looks good,
Reviewed-by: Christoph Hellwig
___
Looks good,
Reviewed-by: Christoph Hellwig
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
On Tue, Dec 14, 2021 at 11:07:34AM -0600, john.p.donne...@oracle.com wrote:
> Is CONFIG_ZONE_DMA even needed anymore in x86_64 ?
Yes. There are still plenty of addressing challenged devices, mostly
ISA-like but also a few PCI/PCIe ones.
___
kexec
ose by DMA API or
> > just remove GFP_DMA from kmalloc()
> >
> > 3) Drop support for allocating DMA memory from slab allocator
> > (as Christoph Hellwig said) and convert them to use DMA32
>
> (as Christoph Hellwig said) and convert them to u
On Mon, Dec 13, 2021 at 08:27:12PM +0800, Baoquan He wrote:
> Dma-kmalloc will be created as long as CONFIG_ZONE_DMA is enabled.
> However, it will fail if DMA zone has no managed pages. The failure
> can be seen in kdump kernel of x86_64 as below:
Please just switch the sr allocation to use
>
> 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;
> +
> + iov_iter_kvec(, READ, , 1, count);
> +
> + return
On Mon, Dec 13, 2021 at 12:06:35AM +, Matthew Wilcox (Oracle) wrote:
> + /* trim iter to not go beyond EOF */
> + if (iter->count > vmcore_size - *fpos)
> + iter->count = vmcore_size - *fpos;
Nit: iov_iter_truncate()
Otherwise this looks good from a cursory view.
On Mon, Dec 13, 2021 at 12:06:34AM +, Matthew Wilcox (Oracle) wrote:
> Instead of passing in a 'buf' and 'userbuf' argument, pass in an iov_iter.
> s390 needs more work to pass the iov_iter down further, or refactor,
> but I'd be more comfortable if someone who can test on s390 did that work.
On Mon, Dec 13, 2021 at 03:39:25PM +0800, Baoquan He wrote:
> > > As said at above, ia64 and riscv don't have ZONE_DMA at all, they just
> > > cover low 4G with ZONE_DMA32 alone.
> >
> > If you do not have devices that are crap and cannot address the full
> > memory then you dont need these
On Tue, Dec 07, 2021 at 09:05:26AM +0100, Christoph Lameter wrote:
> On Tue, 7 Dec 2021, Baoquan He wrote:
>
> > into ZONE_DMA32 by default. The zone DMA covering low 16M is used to
> > take care of antique ISA devices. In fact, on 64bit system, it rarely
> > need ZONE_DMA (which is low 16M) to
On Tue, Dec 07, 2021 at 11:07:47AM +0800, Baoquan He wrote:
> In the current code, three atomic memory pools are always created,
> atomic_pool_kernel|dma|dma32, even though 'coherent_pool=0' is
> specified in kernel command line. In fact, atomic pool is only
> necessary when
On Mon, Dec 06, 2021 at 03:07:15PM +, Matthew Wilcox wrote:
> > > What do you think to adding a generic copy_pfn_to_iter()? Not sure
> > > which APIs to use to implement it ... some architectures have weird
> > > requirements about which APIs can be used for what kinds of PFNs.
> >
> > Hmm.
On Mon, Dec 06, 2021 at 02:17:24PM +, 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 iov_iter
> > here?
>
> I coincidentally made a start on this last night. Happy
On Fri, Dec 03, 2021 at 04:12:18PM +0530, Amit Daniel Kachhap wrote:
> + return read_from_oldmem_to_kernel(buf, count, ppos,
> +
> cc_platform_has(CC_ATTR_GUEST_MEM_ENCRYPT));
Overly long line.
> +ssize_t read_from_oldmem(char __user *ubuf, char *kbuf,
On Wed, Sep 15, 2021 at 07:18:34PM +0200, Christophe Leroy wrote:
> Could you please provide more explicit explanation why inlining such an
> helper is considered as bad practice and messy ?
Because now we get architectures to all subly differ. Look at the mess
for ioremap and the ioremap*
On Thu, Aug 19, 2021 at 01:33:09PM -0500, Tom Lendacky wrote:
> I did it as inline originally because the presence of the function will be
> decided based on the ARCH_HAS_PROTECTED_GUEST config. For now, that is
> only selected by the AMD memory encryption support, so if I went out of
> line I
On Fri, Aug 13, 2021 at 11:59:23AM -0500, Tom Lendacky wrote:
> +static inline bool prot_guest_has(unsigned int attr)
No reall need to have this inline. In fact I'd suggest we havea the
prototype in a common header so that everyone must implement it out
of line.
On Fri, Aug 13, 2021 at 11:59:22AM -0500, Tom Lendacky wrote:
> While the name suggests this is intended mainly for guests, it will
> also be used for host memory encryption checks in place of sme_active().
Which suggest that the name is not good to start with. Maybe protected
hardware, system
On Fri, Aug 13, 2021 at 11:59:21AM -0500, Tom Lendacky wrote:
> +#define PATTR_MEM_ENCRYPT0 /* Encrypted memory */
> +#define PATTR_HOST_MEM_ENCRYPT 1 /* Host encrypted
> memory */
> +#define PATTR_GUEST_MEM_ENCRYPT 2 /* Guest encrypted
>
On Tue, Aug 10, 2021 at 03:52:25PM -0500, Tom Lendacky via iommu wrote:
> I think the atomic pool is used by the NVMe driver. My understanding is
> that driver will do a dma_alloc_coherent() from interrupt context, so it
> needs to use GFP_ATOMIC. The pool was created because dma_alloc_coherent()
On Tue, Jul 27, 2021 at 05:26:05PM -0500, Tom Lendacky via iommu wrote:
> Introduce an x86 version of the prot_guest_has() function. This will be
> used in the more generic x86 code to replace vendor specific calls like
> sev_active(), etc.
>
> While the name suggests this is intended mainly for
On Tue, Jul 27, 2021 at 05:26:04PM -0500, Tom Lendacky via iommu wrote:
> In prep for other protected virtualization technologies, introduce a
> generic helper function, prot_guest_has(), that can be used to check
> for specific protection attributes, like memory encryption. This is
> intended to
This can be simplified a little more by killing off
copy_user_segment_list entirely, using memdup_user and dropping the
not really required _locked wrapper. The locking move might make
most sense as a separate prep patch.
diff --git a/kernel/kexec.c b/kernel/kexec.c
index
On Thu, Jun 24, 2021 at 11:47:31AM +0100, Robin Murphy wrote:
> Hmm, I think the Kconfig reshuffle has actually left a slight wrinkle here.
> For DMA_DIRECT_REMAP=y we can assume an atomic pool is always needed, since
> that was the original behaviour anyway. However the implications of
>
So reduce the amount allocated. But the pool is needed for proper
operation on systems with memory encryption. And please add the right
maintainer or at least mailing list for the code you're touching next
time.
___
kexec mailing list
Looks good,
Reviewed-by: Christoph Hellwig
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
Except for the various annoying overly long lines this looks fine to me:
Reviewed-by: Christoph Hellwig
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
Looks good,
Reviewed-by: Christoph Hellwig
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
On Mon, May 17, 2021 at 10:57:24PM -0500, Eric W. Biederman wrote:
> We open ourselves up to bugs whenever we lie to the type system.
>
> Skimming through the code it looks like it should be possible
> to not need the in_compat_syscall and the casts to the wrong
> type by changing the order of
> + if (in_compat_syscall())
> + return copy_user_compat_segment_list(image, nr_segments,
> segments);
Annoying overly lone line here.
Otherwise:
Reviewed-by: Christoph Hellwig
___
kexec mailing list
kexec@lists.infradead
> This also removes all the superflous freezer calls on all filesystems
> as they are no longer needed as the VFS now performs filesystem
> freezing/thaw if the filesystem has support for it. The filesystem
> therefore is in charge of properly dealing with quiescing of the
> filesystem through its
Wouldn't it be simpler to just add a new flag to signal a kernel
initiated freeze, or even better the exact reason (suspend) instead of
overloading the state machine?
___
kexec mailing list
kexec@lists.infradead.org
On Sat, Apr 17, 2021 at 12:10:21AM +, Luis Chamberlain wrote:
> freeze_super() holds a write lock, however we wish to also enable
> callers which already hold the write lock. To do this provide a helper
> and make freeze_super() use it. This way, all that freeze_super() does
> now is lock
On Tue, Mar 23, 2021 at 07:04:31PM -0700, Stephen Boyd wrote:
> x5 : x4 : 0001
> x3 : 0008 x2 : ff93fef25a70
> x1 : ff93fef15788 x0 : ffe3622352e0
> Call trace:
> lkdtm_WARNING+0x28/0x30 [lkdtm ed5019fdf5e53be37cb1ba7899292d7e143b259e]
>
On Tue, Nov 03, 2020 at 10:45:54AM +0100, Arnd Bergmann wrote:
> I had it there originally, I guess I should have left it there ;-)
>
> When I changed it, I was considering to do the same for additional
> syscalls that have very small differences now (timer_create,
> rt_sigqueueinfo,
> #ifdef CONFIG_COMPAT
> COMPAT_SYSCALL_DEFINE6(move_pages, pid_t, pid, compat_ulong_t, nr_pages,
> +compat_uptr_t __user *, pages,
> const int __user *, nodes,
> int __user *, status,
> int, flags)
> {
> +
On Mon, Nov 02, 2020 at 01:31:51PM +0100, Arnd Bergmann wrote:
> From: Arnd Bergmann
>
> These are all handled correctly when calling the native
> system call entry point, so remove the special cases.
Ok, this is where you do it. I think this belongs into the main
patches.
> + for (i=0; i < nr_segments; i++) {
Missing spaces around the "=".
> +SYSCALL_DEFINE4(kexec_load, unsigned long, entry, unsigned long, nr_segments,
> + struct kexec_segment __user *, segments, unsigned long, flags)
> +{
> + return kernel_kexec_load(entry, nr_segments,
> - kaddr = kmap(pp);
> + kaddr = kmap_thread(pp);
> memcpy(kaddr, vip->vii_immed.vi_immed + offset, PAGE_SIZE);
> - kunmap(pp);
> + kunmap_thread(pp);
You only Cced me on this particular patch, which means I have absolutely
no idea what kmap_thread and kunmap_thread
On Fri, Sep 18, 2020 at 03:24:39PM +0200, Arnd Bergmann wrote:
> The compat implementations for mbind, get_mempolicy, set_mempolicy
> and migrate_pages are just there to handle the subtly different
> layout of bitmaps on 32-bit hosts.
>
> The compat implementation however lacks some of the checks
On Fri, Sep 18, 2020 at 03:24:38PM +0200, Arnd Bergmann wrote:
> 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.
On Fri, Sep 18, 2020 at 03:24:37PM +0200, Arnd Bergmann wrote:
> 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
On Fri, Sep 18, 2020 at 03:24:36PM +0200, Arnd Bergmann wrote:
> sys_move_pages() is an optional syscall, and once we remove
> the compat version of it in favor of the native one with an
> in_compat_syscall() check, the x32 syscall table refers to
> a __x32_sys_move_pages symbol that may not exist
Looks good,
Reviewed-by: Christoph Hellwig
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
On Fri, May 15, 2020 at 09:29:33PM +, Luis Chamberlain wrote:
> On Wed, May 13, 2020 at 11:17:36AM -0700, Christoph Hellwig wrote:
> > Can you also move kernel_read_* out of fs.h? That header gets pulled
> > in just about everywhere and doesn't really need funct
Can you also move kernel_read_* out of fs.h? That header gets pulled
in just about everywhere and doesn't really need function not related
to the general fs interface.
___
kexec mailing list
kexec@lists.infradead.org
On Wed, Jun 07, 2017 at 02:17:32PM -0500, Tom Lendacky wrote:
> Add warnings to let the user know when bounce buffers are being used for
> DMA when SME is active. Since the bounce buffers are not in encrypted
> memory, these notifications are to allow the user to determine some
> appropriate
On Thu, Jun 16, 2016 at 11:22:46AM +0200, Vitaly Kuznetsov wrote:
> _count -> _refcount rename in commit 0139aa7b7fa12 ("mm: rename _count,
> field of the struct page, to _refcount") broke kdump. makedumpfile(8) does
> stuff like READ_MEMBER_OFFSET("page._count", page._count) and fails. While
> it
On Wed, Jun 23, 2010 at 02:35:38PM +0200, Andi Kleen wrote:
I haven't heard any complains about existing syscalls wrappers.
At least for me they always interrupt my grepping.
What kind of annotations could solve that?
If you put the annotation in a separate macro and leave the original
63 matches
Mail list logo
