With CONFIG_SPARSEMEM disabled the below kernel build error is observed.
arch/powerpc/mm/init_64.c:477:38: error: use of undeclared identifier
'SECTION_SIZE_BITS'
CONFIG_MEMORY_HOTPLUG depends on CONFIG_SPARSEMEM and it is more clear
to describe the code dependency in terms of MEMORY_HOTPLUG. O
commit 4d15721177d5 ("powerpc/mm: Cleanup memory block size probing")
used 256MB as the memory block size when we have
ibm,coherent-device-memory device tree node present. Instead of
returning with 256MB memory block size, continue to check the rest of the memory
regions and make sure we can still
On 8/28/23 1:16 PM, Aneesh Kumar K.V wrote:
> With CONFIG_SPARSEMEM disabled the below kernel build error is observed.
>
> arch/powerpc/mm/init_64.c:477:38: error: use of undeclared identifier
> 'SECTION_SIZE_BITS'
>
> CONFIG_MEMORY_HOTPLUG depends on CONFIG_SPARSEMEM and it is more clear
> to
Process the result of hold_open() and return it from
uhdlc_open() in case of an error
It is necessary to pass the error code up the control flow,
similar to a possible error in request_irq()
Found by Linux Verification Center (linuxtesting.org) with SVACE.
Fixes: c19b6d246a35 ("drivers/net: suppo
Le 28/08/2023 à 10:27, Alexandra Diupina a écrit :
> [Vous ne recevez pas souvent de courriers de adiup...@astralinux.ru.
> Découvrez pourquoi ceci est important à
> https://aka.ms/LearnAboutSenderIdentification ]
>
> Process the result of hold_open() and return it from
> uhdlc_open() in case
On Fri, Aug 25, 2023 at 07:44:32PM +0800, kernel test robot wrote:
>
> All errors (new ones prefixed by >>):
>
>In file included from arch/powerpc/crypto/poly1305-p10-glue.c:19:
...
> ae3a197e3d0bfe3 David Howells2012-03-28 75
> ae3a197e3d0bfe3 David Howells2012-03-28 76 #ifdef
On Sat, Aug 26, 2023 at 12:44 AM Michael Schmitz wrote:
> (Incidentally - did you ever publish the m68k full history tree anywhere
> in git?)
You mean the gitified version of the Linux/m68k CVS tree Ralf created
for me because my machine wasn't powerful enough?
No, and I should look into doing th
Hi Geert,
Am 28.08.2023 um 18:42 schrieb Geert Uytterhoeven:
On Sat, Aug 26, 2023 at 12:44 AM Michael Schmitz wrote:
(Incidentally - did you ever publish the m68k full history tree anywhere
in git?)
You mean the gitified version of the Linux/m68k CVS tree Ralf created
for me because my machi
Process the result of hold_open() and return it from
uhdlc_open() in case of an error
It is necessary to pass the error code up the control flow,
similar to a possible error in request_irq()
Found by Linux Verification Center (linuxtesting.org) with SVACE.
Fixes: c19b6d246a35 ("drivers/net: suppo
Le 28/08/2023 à 14:12, Alexandra Diupina a écrit :
> [Vous ne recevez pas souvent de courriers de adiup...@astralinux.ru.
> Découvrez pourquoi ceci est important à
> https://aka.ms/LearnAboutSenderIdentification ]
>
> Process the result of hold_open() and return it from
> uhdlc_open() in case
flags-$(CONFIG_PPC64) := $(NO_MINIMAL_TOC)
obj-y += xmon.o nonstdio.o spr_access.o xmon_bpts.o
---
base-commit: 2ee82481c392eec06a7ef28df61b7f0d8e45be2e
change-id: 20230828-ppc_rerevert-647427f04ce1
Best regards,
--
Nick Desaulniers
IMAL_TOC)
>
> obj-y+= xmon.o nonstdio.o spr_access.o xmon_bpts.o
>
> ---
> base-commit: 2ee82481c392eec06a7ef28df61b7f0d8e45be2e
> change-id: 20230828-ppc_rerevert-647427f04ce1
>
> Best regards,
> --
> Nick Desaulniers
>
On Mon, 28 Aug 2023 15:12:35 +0300 Alexandra Diupina wrote:
> Process the result of hold_open() and return it from
> uhdlc_open() in case of an error
> It is necessary to pass the error code up the control flow,
> similar to a possible error in request_irq()
>
> Found by Linux Verification Center
On Wed, Aug 23, 2023 at 01:47:22PM -0300, Jason Gunthorpe wrote:
> Except for dart (which forces IOMMU_DOMAIN_DMA) every driver returns 0 or
> IDENTITY from ops->def_domain_type().
>
> The drivers that return IDENTITY have some kind of good reason, typically
> that quirky hardware really can't sup
On Wed, Aug 23, 2023 at 01:47:23PM -0300, Jason Gunthorpe wrote:
> Even though dma-iommu.c and CONFIG_ARM_DMA_USE_IOMMU do approximately the
> same stuff, the way they relate to the IOMMU core is quiet different.
>
> dma-iommu.c expects the core code to setup an UNMANAGED domain (of type
> IOMMU_D
On Wed, Aug 23, 2023 at 01:47:24PM -0300, Jason Gunthorpe wrote:
> What exynos calls exynos_iommu_detach_device is actually putting the iommu
> into identity mode.
>
> Move to the new core support for ARM_DMA_USE_IOMMU by defining
> ops->identity_domain.
>
> Tested-by: Marek Szyprowski
> Acked-b
On Wed, Aug 23, 2023 at 01:47:25PM -0300, Jason Gunthorpe wrote:
> What tegra-smmu does during tegra_smmu_set_platform_dma() is actually
> putting the iommu into identity mode.
>
> Move to the new core support for ARM_DMA_USE_IOMMU by defining
> ops->identity_domain.
>
> Reviewed-by: Lu Baolu
>
On Wed, Aug 23, 2023 at 01:47:26PM -0300, Jason Gunthorpe wrote:
> All ARM64 iommu drivers should support IOMMU_DOMAIN_DMA to enable
> dma-iommu.c.
>
> tegra is blocking dma-iommu usage, and also default_domain's, because it
> wants an identity translation. This is needed for some device quirk. Th
ed-by tags.
- Update commit message slightly, including oneline.
- Link to v1:
https://lore.kernel.org/r/20230828-ppc_rerevert-v1-1-74f55b818...@google.com
---
arch/powerpc/xmon/Makefile | 4
1 file changed, 4 insertions(+)
diff --git a/arch/powerpc/xmon/Makefile b/arch/powerpc/xmon/Make
On Wed, Aug 23, 2023 at 01:47:27PM -0300, Jason Gunthorpe wrote:
> What omap does during omap_iommu_set_platform_dma() is actually putting
> the iommu into identity mode.
>
> Move to the new core support for ARM_DMA_USE_IOMMU by defining
> ops->identity_domain.
>
> This driver does not support IO
On Wed, Aug 23, 2023 at 01:47:28PM -0300, Jason Gunthorpe wrote:
> What msm does during msm_iommu_set_platform_dma() is actually putting the
> iommu into identity mode.
>
> Move to the new core support for ARM_DMA_USE_IOMMU by defining
> ops->identity_domain.
>
> This driver does not support IOMM
On Wed, Aug 23, 2023 at 01:47:29PM -0300, Jason Gunthorpe wrote:
> All drivers are now using IDENTITY or PLATFORM domains for what this did,
> we can remove it now. It is no longer possible to attach to a NULL domain.
>
> Tested-by: Heiko Stuebner
> Tested-by: Niklas Schnelle
> Tested-by: Steven
On Wed, Aug 23, 2023 at 01:47:30PM -0300, Jason Gunthorpe wrote:
> This brings back the ops->detach_dev() code that commit
> 1b932ceddd19 ("iommu: Remove detach_dev callbacks") deleted and turns it
> into an IDENTITY domain.
>
> Reviewed-by: Lu Baolu
> Signed-off-by: Jason Gunthorpe
> ---
> dri
On Wed, Aug 23, 2023 at 01:47:31PM -0300, Jason Gunthorpe wrote:
> This brings back the ops->detach_dev() code that commit
> 1b932ceddd19 ("iommu: Remove detach_dev callbacks") deleted and turns it
> into an IDENTITY domain.
>
> Also reverts commit 584d334b1393 ("iommu/ipmmu-vmsa: Remove
> ipmmu_u
On Wed, Aug 23, 2023 at 01:47:32PM -0300, Jason Gunthorpe wrote:
> This brings back the ops->detach_dev() code that commit
> 1b932ceddd19 ("iommu: Remove detach_dev callbacks") deleted and turns it
> into an IDENTITY domain.
>
> Reviewed-by: Lu Baolu
> Signed-off-by: Jason Gunthorpe
> ---
> dri
On Wed, Aug 23, 2023 at 01:47:33PM -0300, Jason Gunthorpe wrote:
> Prior to commit 1b932ceddd19 ("iommu: Remove detach_dev callbacks") the
> sun50i_iommu_detach_device() function was being called by
> ops->detach_dev().
>
> This is an IDENTITY domain so convert sun50i_iommu_detach_device() into
>
On Wed, Aug 23, 2023 at 01:47:34PM -0300, Jason Gunthorpe wrote:
> At this point every iommu driver will cause a default_domain to be
> selected, so we can finally remove this gap from the core code.
>
> The following table explains what each driver supports and what the
> resulting default_domain
Audra Mitchell writes:
> With PPC builds enabling CONFIG_HARDENED_USERCOPY, interacting with the
> RunTime
> Abstraction Services (RTAS) firmware by writing to
> /proc/powerpc/rtas/firmware_flash will end up triggering the mm/usercopy.c:101
> assertion:
Thanks, this was fixed already:
4f3175979
On Wed, Aug 23, 2023 at 01:47:35PM -0300, Jason Gunthorpe wrote:
> Allocate a domain from a group. Automatically obtains the iommu_ops to use
> from the device list of the group. Convert the internal callers to use it.
>
> Tested-by: Steven Price
> Tested-by: Marek Szyprowski
> Tested-by: Nicoli
Sean Christopherson writes:
> On Mon, Aug 21, 2023, Ackerley Tng wrote:
>> Sean Christopherson writes:
>>
>> > On Tue, Aug 15, 2023, Ackerley Tng wrote:
>> >> Sean Christopherson writes:
>> >> > Nullifying the KVM pointer isn't sufficient, because without additional
>> >> > actions
>> >> > use
With PPC builds enabling CONFIG_HARDENED_USERCOPY, interacting with the RunTime
Abstraction Services (RTAS) firmware by writing to
/proc/powerpc/rtas/firmware_flash will end up triggering the mm/usercopy.c:101
assertion:
[ 38.647148] rw /proc/powerpc/rtas/firmware_flash
[ 38.650254] usercopy:
On Wed, Aug 23, 2023 at 01:47:36PM -0300, Jason Gunthorpe wrote:
> This callback requests the driver to create only a __IOMMU_DOMAIN_PAGING
> domain, so it saves a few lines in a lot of drivers needlessly checking
> the type.
>
> More critically, this allows us to sweep out all the
> IOMMU_DOMAIN_
On Wed, Aug 23, 2023 at 01:47:37PM -0300, Jason Gunthorpe wrote:
> These drivers are all trivially converted since the function is only
> called if the domain type is going to be
> IOMMU_DOMAIN_UNMANAGED/DMA.
>
> Tested-by: Heiko Stuebner
> Tested-by: Steven Price
> Tested-by: Marek Szyprowski
On Wed, Aug 23, 2023 at 01:47:38PM -0300, Jason Gunthorpe wrote:
> These drivers don't support IOMMU_DOMAIN_DMA, so this commit effectively
> allows them to support that mode.
>
> The prior work to require default_domains makes this safe because every
> one of these drivers is either compilation i
On 8/28/2023 3:56 PM, Ackerley Tng wrote:
> 1. Since the physical memory's representation is the inode and should be
> coupled to the virtual machine (as a concept, not struct kvm), should
> the binding/coupling be with the file, or the inode?
>
I've been working on Gunyah's implementa
On Mon 28 Aug 2023 16:17:07 GMT, Michael Ellerman wrote:
> Masahiro Yamada writes:
> > On Sat, Aug 26, 2023 at 4:55 AM Kees Cook wrote:
> >>
> >> Hi,
> >>
> >> This is my series to show *.config targets in the "help" target so these
> >> various topics can be more easily discoverd.
> >>
> >> v2:
thread_change_pc() uses CPU local data, so must be protected from
swapping CPUs while it is reading the breakpoint struct.
The error is more noticeable after 1e60f3564bad ("powerpc/watchpoints:
Track perf single step directly on the breakpoint"), which added an
unconditional __this_cpu_read() call
This is called in an atomic context, so is not allowed to sleep if a
user page needs to be faulted in and has nowhere it can be deferred to.
The pagefault_disabled() function is documented as preventing user
access methods from sleeping.
In practice the page will be mapped in nearly always because
When enabling debug config options relating to preemption, several bugs
appear in the kernel log. With this series applied, the breakpoint code
no longer prints bugs when running the powerpc/ptrace selftests.
Benjamin Gray (3):
powerpc/watchpoints: Disable preemption in thread_change_pc()
powe
It can be easy to miss that the notifier mechanism invokes the callbacks
in an atomic context, so add some comments to that effect on the two
handlers we register here.
Signed-off-by: Benjamin Gray
---
arch/powerpc/kernel/hw_breakpoint.c | 9 +
1 file changed, 9 insertions(+)
diff --git
On 29/8/23 4:34 pm, Benjamin Gray wrote:
When enabling debug config options relating to preemption, several bugs
appear in the kernel log. With this series applied, the breakpoint code
no longer prints bugs when running the powerpc/ptrace selftests.
Benjamin Gray (3):
powerpc/watchpoints: Dis
41 matches
Mail list logo
