Hi Robin,
I don't know the DMA mapping code well and haven't reviewed this
patch set in particular, but I wanted to comment on some of the things
you say here.
> Marek, I'm surprised that even you aren't seeing why that would at best be
> pointless churn. The fundamental design of dma_map_page()
On Wed, Jul 30, 2025 at 11:28:18AM -0300, Jason Gunthorpe wrote:
> On Wed, Jul 30, 2025 at 04:40:26PM +0300, Leon Romanovsky wrote:
<...>
> > The most reasonable way to prevent DMA_ATTR_SKIP_CPU_SYNC leakage is to
> > introduce new DMA attribute (let's call it DMA_ATTR_MMIO for now) and
> > pass
On 30.07.2025 13:11, Robin Murphy wrote:
> On 2025-07-08 11:27 am, Marek Szyprowski wrote:
>> On 30.06.2025 15:38, Christoph Hellwig wrote:
>>> On Fri, Jun 27, 2025 at 08:02:13PM +0300, Leon Romanovsky wrote:
> Thanks for this rework! I assume that the next step is to add
> map_phys
>
On Wed, Jul 30, 2025 at 04:40:26PM +0300, Leon Romanovsky wrote:
> > The natural working unit for whatever replaces dma_map_page() will be
> > whatever the replacement for alloc_pages() returns, and the replacement for
> > kmap_atomic() operates on. Until that exists (and I simply cannot believe i
On Wed, Jul 30, 2025 at 12:11:32PM +0100, Robin Murphy wrote:
> On 2025-07-08 11:27 am, Marek Szyprowski wrote:
> > On 30.06.2025 15:38, Christoph Hellwig wrote:
> > > On Fri, Jun 27, 2025 at 08:02:13PM +0300, Leon Romanovsky wrote:
> > > > > Thanks for this rework! I assume that the next step is t
On 2025-07-08 11:27 am, Marek Szyprowski wrote:
On 30.06.2025 15:38, Christoph Hellwig wrote:
On Fri, Jun 27, 2025 at 08:02:13PM +0300, Leon Romanovsky wrote:
Thanks for this rework! I assume that the next step is to add map_phys
callback also to the dma_map_ops and teach various dma-mapping pr
On Fri, Jul 25, 2025 at 09:05:46PM +0100, Robin Murphy wrote:
> But given what we do already know of from decades of experience, obvious
> question: For the tiny minority of users who know full well when they're
> dealing with a non-page-backed physical address, what's wrong with using
> dma_map_r
On 2025-06-25 2:18 pm, Leon Romanovsky wrote:
This series refactors the DMA mapping to use physical addresses
as the primary interface instead of page+offset parameters. This
change aligns the DMA API with the underlying hardware reality where
DMA operations work with physical addresses, not page
On 08.07.2025 14:56, Marek Szyprowski wrote:
> On 08.07.2025 14:06, Leon Romanovsky wrote:
>> On Tue, Jul 08, 2025 at 01:45:20PM +0200, Marek Szyprowski wrote:
>>> On 08.07.2025 13:00, Leon Romanovsky wrote:
On Tue, Jul 08, 2025 at 12:27:09PM +0200, Marek Szyprowski wrote:
> On 30.06.2025
On 08.07.2025 14:06, Leon Romanovsky wrote:
> On Tue, Jul 08, 2025 at 01:45:20PM +0200, Marek Szyprowski wrote:
>> On 08.07.2025 13:00, Leon Romanovsky wrote:
>>> On Tue, Jul 08, 2025 at 12:27:09PM +0200, Marek Szyprowski wrote:
On 30.06.2025 15:38, Christoph Hellwig wrote:
> On Fri, Jun 2
On Tue, Jul 08, 2025 at 01:45:20PM +0200, Marek Szyprowski wrote:
> On 08.07.2025 13:00, Leon Romanovsky wrote:
> > On Tue, Jul 08, 2025 at 12:27:09PM +0200, Marek Szyprowski wrote:
> >> On 30.06.2025 15:38, Christoph Hellwig wrote:
> >>> On Fri, Jun 27, 2025 at 08:02:13PM +0300, Leon Romanovsky wr
On 08.07.2025 13:00, Leon Romanovsky wrote:
> On Tue, Jul 08, 2025 at 12:27:09PM +0200, Marek Szyprowski wrote:
>> On 30.06.2025 15:38, Christoph Hellwig wrote:
>>> On Fri, Jun 27, 2025 at 08:02:13PM +0300, Leon Romanovsky wrote:
> Thanks for this rework! I assume that the next step is to add m
On Tue, Jul 08, 2025 at 12:27:09PM +0200, Marek Szyprowski wrote:
> On 30.06.2025 15:38, Christoph Hellwig wrote:
> > On Fri, Jun 27, 2025 at 08:02:13PM +0300, Leon Romanovsky wrote:
> >>> Thanks for this rework! I assume that the next step is to add map_phys
> >>> callback also to the dma_map_ops
On 30.06.2025 15:38, Christoph Hellwig wrote:
> On Fri, Jun 27, 2025 at 08:02:13PM +0300, Leon Romanovsky wrote:
>>> Thanks for this rework! I assume that the next step is to add map_phys
>>> callback also to the dma_map_ops and teach various dma-mapping providers
>>> to use it to avoid more phys-t
On Fri, Jun 27, 2025 at 08:02:13PM +0300, Leon Romanovsky wrote:
> On Fri, Jun 27, 2025 at 03:44:10PM +0200, Marek Szyprowski wrote:
> > On 25.06.2025 15:18, Leon Romanovsky wrote:
> > > This series refactors the DMA mapping to use physical addresses
> > > as the primary interface instead of page+o
On Fri, Jun 27, 2025 at 08:02:13PM +0300, Leon Romanovsky wrote:
> > Thanks for this rework! I assume that the next step is to add map_phys
> > callback also to the dma_map_ops and teach various dma-mapping providers
> > to use it to avoid more phys-to-page-to-phys conversions.
>
> Probably Chri
On Fri, Jun 27, 2025 at 03:44:10PM +0200, Marek Szyprowski wrote:
> On 25.06.2025 15:18, Leon Romanovsky wrote:
> > This series refactors the DMA mapping to use physical addresses
> > as the primary interface instead of page+offset parameters. This
> > change aligns the DMA API with the underlying
On 25.06.2025 15:18, Leon Romanovsky wrote:
> This series refactors the DMA mapping to use physical addresses
> as the primary interface instead of page+offset parameters. This
> change aligns the DMA API with the underlying hardware reality where
> DMA operations work with physical addresses, not
This series refactors the DMA mapping to use physical addresses
as the primary interface instead of page+offset parameters. This
change aligns the DMA API with the underlying hardware reality where
DMA operations work with physical addresses, not page structures.
The series consists of 8 patches t
On Thu, Jun 12, 2025 at 06:56:53AM +0200, Paolo Bonzini wrote:
> On 6/11/25 02:10, Sean Christopherson wrote:
> > Kill off include/kvm (through file moves/renames), and standardize the set
> > of
> > KVM includes across all architectures.
> >
> > This conflicts with Colton's partioned PMU series[
On 6/11/25 02:10, Sean Christopherson wrote:
Kill off include/kvm (through file moves/renames), and standardize the set of
KVM includes across all architectures.
This conflicts with Colton's partioned PMU series[1], but this should work as
a nice prepatory cleanup for the partitioned PMU work (a
Kill off include/kvm (through file moves/renames), and standardize the set of
KVM includes across all architectures.
This conflicts with Colton's partioned PMU series[1], but this should work as
a nice prepatory cleanup for the partitioned PMU work (and hopefully can land
sooner).
Note, these pat
On Wed, 28 May 2025 21:59:54 +0200, Krzysztof Kozlowski wrote:
> Make static data const for code safety and drop some unused fields in
> structs.
>
> This is based on for-v6.16 branch in ASoC tree for context in wcd938x
> driver.
>
> Best regards,
> Krzysztof
>
> [...]
Applied to
https://gi
On 5/28/25 8:59 PM, Krzysztof Kozlowski wrote:
> Make static data const for code safety and drop some unused fields in
> structs.
>
> This is based on for-v6.16 branch in ASoC tree for context in wcd938x
> driver.
>
> Best regards,
> Krzysztof
>
> ---
> Krzysztof Kozlowski (8):
> ASoC:
On 29/05/2025 11:33, Srinivas Kandagatla wrote:
>
>
> On 5/28/25 8:59 PM, Krzysztof Kozlowski wrote:
>> Make static data const for code safety and drop some unused fields in
>> structs.
>>
>> This is based on for-v6.16 branch in ASoC tree for context in wcd938x
>> driver.
>>
>> Best regards,
>> K
Make static data const for code safety and drop some unused fields in
structs.
This is based on for-v6.16 branch in ASoC tree for context in wcd938x
driver.
Best regards,
Krzysztof
---
Krzysztof Kozlowski (8):
ASoC: codecs: Constify regmap configuration static variables
ASoC: fsl: Co
Le 17/05/2024 à 16:27, Oscar Salvador a écrit :
> On Mon, Mar 25, 2024 at 03:55:53PM +0100, Christophe Leroy wrote:
>> This series reimplements hugepages with hugepd on powerpc 8xx.
>>
>> Unlike most architectures, powerpc 8xx HW requires a two-level
>> pagetable topology for all page sizes. So a
On Mon, Mar 25, 2024 at 03:55:53PM +0100, Christophe Leroy wrote:
> This series reimplements hugepages with hugepd on powerpc 8xx.
>
> Unlike most architectures, powerpc 8xx HW requires a two-level
> pagetable topology for all page sizes. So a leaf PMD-contig approach
> is not feasible as such.
>
On Tue, Apr 16, 2024 at 10:58:33AM +, Christophe Leroy wrote:
>
>
> Le 15/04/2024 à 21:12, Christophe Leroy a écrit :
> >
> >
> > Le 12/04/2024 à 16:30, Peter Xu a écrit :
> >> On Fri, Apr 12, 2024 at 02:08:03PM +, Christophe Leroy wrote:
> >>>
> >>>
> >>> Le 11/04/2024 à 18:15, Peter X
Le 15/04/2024 à 21:12, Christophe Leroy a écrit :
>
>
> Le 12/04/2024 à 16:30, Peter Xu a écrit :
>> On Fri, Apr 12, 2024 at 02:08:03PM +, Christophe Leroy wrote:
>>>
>>>
>>> Le 11/04/2024 à 18:15, Peter Xu a écrit :
On Mon, Mar 25, 2024 at 01:38:40PM -0300, Jason Gunthorpe wrote:
Le 12/04/2024 à 16:30, Peter Xu a écrit :
> On Fri, Apr 12, 2024 at 02:08:03PM +, Christophe Leroy wrote:
>>
>>
>> Le 11/04/2024 à 18:15, Peter Xu a écrit :
>>> On Mon, Mar 25, 2024 at 01:38:40PM -0300, Jason Gunthorpe wrote:
On Mon, Mar 25, 2024 at 03:55:53PM +0100, Christophe Leroy wro
On Fri, Apr 12, 2024 at 02:08:03PM +, Christophe Leroy wrote:
>
>
> Le 11/04/2024 à 18:15, Peter Xu a écrit :
> > On Mon, Mar 25, 2024 at 01:38:40PM -0300, Jason Gunthorpe wrote:
> >> On Mon, Mar 25, 2024 at 03:55:53PM +0100, Christophe Leroy wrote:
> >>> This series reimplements hugepages wi
Le 11/04/2024 à 18:15, Peter Xu a écrit :
> On Mon, Mar 25, 2024 at 01:38:40PM -0300, Jason Gunthorpe wrote:
>> On Mon, Mar 25, 2024 at 03:55:53PM +0100, Christophe Leroy wrote:
>>> This series reimplements hugepages with hugepd on powerpc 8xx.
>>>
>>> Unlike most architectures, powerpc 8xx HW re
On Mon, Mar 25, 2024 at 01:38:40PM -0300, Jason Gunthorpe wrote:
> On Mon, Mar 25, 2024 at 03:55:53PM +0100, Christophe Leroy wrote:
> > This series reimplements hugepages with hugepd on powerpc 8xx.
> >
> > Unlike most architectures, powerpc 8xx HW requires a two-level
> > pagetable topology for
On Mon, Mar 25, 2024 at 03:55:53PM +0100, Christophe Leroy wrote:
> This series reimplements hugepages with hugepd on powerpc 8xx.
>
> Unlike most architectures, powerpc 8xx HW requires a two-level
> pagetable topology for all page sizes. So a leaf PMD-contig approach
> is not feasible as such.
>
This series reimplements hugepages with hugepd on powerpc 8xx.
Unlike most architectures, powerpc 8xx HW requires a two-level
pagetable topology for all page sizes. So a leaf PMD-contig approach
is not feasible as such.
Possible sizes are 4k, 16k, 512k and 8M.
First level (PGD/PMD) covers 4M per
On Sat, Nov 25, 2023 at 03:47:41AM +0300, George Stark wrote:
> On 11/24/23 18:28, Andy Shevchenko wrote:
> > On Wed, Oct 25, 2023 at 04:07:29PM +0300, George Stark wrote:
> > > Lots of drivers use devm_led_classdev_register() to register their led
> > > objects
> > > and let the kernel free those
On Sat, 25 Nov 2023 03:47:41 +0300
George Stark wrote:
> Hello Andy
>
> Thanks for the review.
>
> On 11/24/23 18:28, Andy Shevchenko wrote:
> > On Wed, Oct 25, 2023 at 04:07:29PM +0300, George Stark wrote:
> >> Lots of drivers use devm_led_classdev_register() to register their led
> >> obje
Hello Andy
Thanks for the review.
On 11/24/23 18:28, Andy Shevchenko wrote:
On Wed, Oct 25, 2023 at 04:07:29PM +0300, George Stark wrote:
Lots of drivers use devm_led_classdev_register() to register their led objects
and let the kernel free those leds at the driver's remove stage.
It can lead
On Wed, Oct 25, 2023 at 04:07:29PM +0300, George Stark wrote:
> Lots of drivers use devm_led_classdev_register() to register their led objects
> and let the kernel free those leds at the driver's remove stage.
> It can lead to a problem due to led_classdev_unregister()
> implementation calls led_se
On Sat, Nov 4, 2023 at 9:17 AM George Stark wrote:
>
> Hello Andy
>
> Could you please take a look at this patch series?
>
> I've just found your post on habr about devres API misusing and I think
> this is just another case.
Just had a look, sorry for the delay.
By quickly reading it seems to be
Le 10/11/2023 à 02:38, Daniel Walker a écrit :
> This release is an up-rev of the v5 patches. No additional features have
> been added. Some changes were mode to function names and some changes to
> Kconfig dependencies. Also updated the config conversion for mips.
>
> There are a number of peop
On Fri, 10 Nov 2023 02:22:27 + "Daniel Walker (danielwa)"
wrote:
> On Thu, Nov 09, 2023 at 05:51:42PM -0800, Andrew Morton wrote:
> > On Thu, 9 Nov 2023 17:38:04 -0800 Daniel Walker wrote:
> >
> > > This release is an up-rev of the v5 patches. No additional features have
> > > been added.
On Thu, Nov 09, 2023 at 05:51:42PM -0800, Andrew Morton wrote:
> On Thu, 9 Nov 2023 17:38:04 -0800 Daniel Walker wrote:
>
> > This release is an up-rev of the v5 patches. No additional features have
> > been added. Some changes were mode to function names and some changes to
> > Kconfig dependen
On Thu, 9 Nov 2023 17:38:04 -0800 Daniel Walker wrote:
> This release is an up-rev of the v5 patches. No additional features have
> been added. Some changes were mode to function names and some changes to
> Kconfig dependencies. Also updated the config conversion for mips.
>
> There are a numbe
This release is an up-rev of the v5 patches. No additional features have
been added. Some changes were mode to function names and some changes to
Kconfig dependencies. Also updated the config conversion for mips.
There are a number of people who have expressed interest in these
patches either by a
Le 25/10/2023 à 15:07, George Stark a écrit :
> Lots of drivers use devm_led_classdev_register() to register their led objects
> and let the kernel free those leds at the driver's remove stage.
> It can lead to a problem due to led_classdev_unregister()
> implementation calls led_set_brightness()
Hello Andy
Could you please take a look at this patch series?
I've just found your post on habr about devres API misusing and I think
this is just another case.
On 10/25/23 16:07, George Stark wrote:
Lots of drivers use devm_led_classdev_register() to register their led objects
and let the k
Lots of drivers use devm_led_classdev_register() to register their led objects
and let the kernel free those leds at the driver's remove stage.
It can lead to a problem due to led_classdev_unregister()
implementation calls led_set_brightness() to turn off the led.
led_set_brightness() may call one
Continue converting drivers to the new interface. Introduce
ops->blocked_domain to hold the global static BLOCKED domain and convert
all drivers supporting BLOCKED to use it.
This makes it trivial for dart and iommufd to convert over to
domain_alloc_paging().
There are six drivers remaining:
dri
From: Joel Granados
What?
These commits remove the sentinel element (last empty element) from the
sysctl arrays of all the files under the "arch/" directory that use a
sysctl array for registration. The merging of the preparation patches
(in https://lore.kernel.org/all/zo5yx5jfoggi%2f...@bombadil
On Mon, 06 Mar 2023 15:33:39 -0600, Nathan Lynch wrote:
> Proposed changes for the RTAS subsystem and client code.
>
> Fixes that are subject to backporting are at the front of the queue,
> followed by documentation and cleanups, with enhancements at the end.
>
> Noteworthy changes:
> * Change sy
This patch series contains cleanups for fsl_uli1575 driver.
This patch series is prerequisity for another patch series:
"powerpc/85xx: p2020: Create one unified machine description"
Christophe Leroy (1):
powerpc/fsl_uli1575: Misc cleanup
Pali Rohár (7):
powerpc/85xx: mpc85xx_ds: Simplify mpc
On Mon, 06 Mar 2023 15:33:39 -0600, Nathan Lynch wrote:
> Proposed changes for the RTAS subsystem and client code.
>
> Fixes that are subject to backporting are at the front of the queue,
> followed by documentation and cleanups, with enhancements at the end.
>
> Noteworthy changes:
> * Change sy
Proposed changes for the RTAS subsystem and client code.
Fixes that are subject to backporting are at the front of the queue,
followed by documentation and cleanups, with enhancements at the end.
Noteworthy changes:
* Change sys_rtas() to consume -2/990x statuses instead of returning
them to us
The way copy_thread works, particularly with kernel threads and kernel
created user threads is a bit muddled and confusing. This series tries
to straighten things out a bit.
Thanks,
Nick
Nicholas Piggin (8):
powerpc: copy_thread remove unused pkey code
powerpc: copy_thread make ret_from_fork
On Mon, Sep 26, 2022 at 05:52:18PM -0500, Rob Herring wrote:
> On Thu, Sep 22, 2022 at 4:15 PM Daniel Gimpelevich
> wrote:
> >
> > On Thu, 2022-09-22 at 14:10 -0700, Daniel Walker wrote:
> > > On Thu, Sep 22, 2022 at 05:03:46PM -0400, Sean Anderson wrote:
> > [snip]
> > > > As recently as last mon
On Thu, Sep 22, 2022 at 02:15:44PM -0700, Daniel Gimpelevich wrote:
> On Thu, 2022-09-22 at 14:10 -0700, Daniel Walker wrote:
> > On Thu, Sep 22, 2022 at 05:03:46PM -0400, Sean Anderson wrote:
> [snip]
> > > As recently as last month, someone's patch to add such support was
> > > rejected for this
On Thu, Sep 22, 2022 at 4:15 PM Daniel Gimpelevich
wrote:
>
> On Thu, 2022-09-22 at 14:10 -0700, Daniel Walker wrote:
> > On Thu, Sep 22, 2022 at 05:03:46PM -0400, Sean Anderson wrote:
> [snip]
> > > As recently as last month, someone's patch to add such support was
> > > rejected for this reason
On Thu, 2022-09-22 at 14:10 -0700, Daniel Walker wrote:
> On Thu, Sep 22, 2022 at 05:03:46PM -0400, Sean Anderson wrote:
[snip]
> > As recently as last month, someone's patch to add such support was
> > rejected for this reason [1].
> >
> > --Sean
> >
> > [1]
> > https://lore.kernel.org/linux-ar
On Thu, Sep 22, 2022 at 05:03:46PM -0400, Sean Anderson wrote:
>
>
>
> On 9/22/22 4:53 PM, Daniel Walker wrote:
> > On Thu, Sep 22, 2022 at 04:45:01PM -0400, Sean Anderson wrote:
> >>
> >>
> >>
> >> For an arm64 platform (after rebasing):
> >>
> >> Tested-by: Sean Anderson
> >
> > Maybe I'
On 9/22/22 4:53 PM, Daniel Walker wrote:
> On Thu, Sep 22, 2022 at 04:45:01PM -0400, Sean Anderson wrote:
>>
>>
>>
>> For an arm64 platform (after rebasing):
>>
>> Tested-by: Sean Anderson
>
> Maybe I'll re-submit it.
>
> Daniel
>
There's still no way to extend the command line on ARM6
On Thu, Sep 22, 2022 at 04:45:01PM -0400, Sean Anderson wrote:
>
>
>
> For an arm64 platform (after rebasing):
>
> Tested-by: Sean Anderson
Maybe I'll re-submit it.
Daniel
On 4/16/21 12:09 AM, Daniel Walker wrote:
>
> v4 release changes
>
> * Updated insert-sys-cert tool to change command line symbols after
> compilation.
>
> This tool is used to release binary kernels internally to companies
> and then later insert certificates for each product b
From: Guo Ren
This macro isn't used in Linux, now. Delete in include/linux/sched.h
and arch's include/asm. This would confuse people who are
implementing the COMPAT feature for architecture.
Guo Ren (8):
sched: Remove unused TASK_SIZE_OF
sched: x86: Remove unused TASK_SIZE_OF
sched: sparc:
Le 24/11/2021 à 14:40, Christophe Leroy a écrit :
Le 24/11/2021 à 14:21, Nicholas Piggin a écrit :
Excerpts from Christophe Leroy's message of November 22, 2021 6:48 pm:
This series converts powerpc to default topdown mmap layout.
powerpc provides its own arch_get_unmapped_area() only whe
Le 24/11/2021 à 14:21, Nicholas Piggin a écrit :
Excerpts from Christophe Leroy's message of November 22, 2021 6:48 pm:
This series converts powerpc to default topdown mmap layout.
powerpc provides its own arch_get_unmapped_area() only when
slices are needed, which is only for book3s/64. Fir
Excerpts from Christophe Leroy's message of November 22, 2021 6:48 pm:
> This series converts powerpc to default topdown mmap layout.
>
> powerpc provides its own arch_get_unmapped_area() only when
> slices are needed, which is only for book3s/64. First part of
> the series moves slices into book3
This series converts powerpc to default topdown mmap layout.
powerpc provides its own arch_get_unmapped_area() only when
slices are needed, which is only for book3s/64. First part of
the series moves slices into book3s/64 specific directories
and cleans up other subarchitectures.
Then a small mod
This patch series aims at fixing some of the AER error handling issues
we have.
Currently we have the following issues:
- Confusing message in aer_print_error()
- aer_err_info not being initialized completely in DPC path before
we print the AER logs
- A bug [1] in clearing of AER registers
On Tue, 14 Sept 2021 at 15:55, Mark Rutland wrote:
>
> On Tue, Sep 14, 2021 at 02:10:28PM +0200, Ard Biesheuvel wrote:
> > Commit c65eacbe290b ("sched/core: Allow putting thread_info into
> > task_struct") mentions that, along with moving thread_info into
> > task_struct, the cpu field is moved ou
On Tue, Sep 14, 2021 at 02:10:28PM +0200, Ard Biesheuvel wrote:
> Commit c65eacbe290b ("sched/core: Allow putting thread_info into
> task_struct") mentions that, along with moving thread_info into
> task_struct, the cpu field is moved out of the former into the latter,
> but does not explain why.
Le 14/09/2021 à 14:10, Ard Biesheuvel a écrit :
Commit c65eacbe290b ("sched/core: Allow putting thread_info into
task_struct") mentions that, along with moving thread_info into
task_struct, the cpu field is moved out of the former into the latter,
but does not explain why.
I think it does ex
Commit c65eacbe290b ("sched/core: Allow putting thread_info into
task_struct") mentions that, along with moving thread_info into
task_struct, the cpu field is moved out of the former into the latter,
but does not explain why.
While collaborating with Keith on adding THREAD_INFO_IN_TASK support to
This is a bunch of fixes for powerpc next, mostly a nasty hole in fast
interrupt exit code found by Sachin and some other bits along the way
while looking at it.
So far this survives about 5 hours of stress testing with a workload
that would trigger it in a few seconds (guest 128 vcpus running ker
On 6/14/21 1:39 PM, Aneesh Kumar K.V wrote:
Form2 associativity adds a much more flexible NUMA topology layout
than what is provided by Form1. This also allows PAPR SCM device
to use better associativity when using the device as DAX KMEM
device. More details can be found in patch x
$ ndctl li
Form2 associativity adds a much more flexible NUMA topology layout
than what is provided by Form1. This also allows PAPR SCM device
to use better associativity when using the device as DAX KMEM
device. More details can be found in patch x
$ ndctl list -N -v
[
{
"dev":"namespace0.0",
"mod
On Thu, May 13, 2021 at 12:02:54PM +0200, Juergen Gross wrote:
> Xen backends of para-virtualized devices can live in dom0 kernel, dom0
> user land, or in a driver domain. This means that a backend might
> reside in a less trusted environment than the Xen core components, so
> a backend should not
Xen backends of para-virtualized devices can live in dom0 kernel, dom0
user land, or in a driver domain. This means that a backend might
reside in a less trusted environment than the Xen core components, so
a backend should not be able to do harm to a Xen guest (it can still
mess up I/O data, but i
v4 release changes
* Updated insert-sys-cert tool to change command line symbols after
compilation.
This tool is used to release binary kernels internally to companies
and then later insert certificates for each product by consumers of
the binary kernel. Cisco uses thi
On Thu, 25 Feb 2021 14:09:58 +1100, Daniel Axtens wrote:
> To support Clang's CFI we need LTO. For LTO, we need to be able to compile
> with the LLVM integrated assembler.
>
> Currently, we can't.
>
> This series gets us a bit closer, but I'm still stuck and I'm hoping
> someone can point me in t
To support Clang's CFI we need LTO. For LTO, we need to be able to compile
with the LLVM integrated assembler.
Currently, we can't.
This series gets us a bit closer, but I'm still stuck and I'm hoping
someone can point me in the right direction.
Patch 1 is a fix that can be merged at any time.
On Sat, 28 Nov 2020 17:07:20 +1000, Nicholas Piggin wrote:
> First patch is a nasty memory scribble introduced by me :( That
> should go into fixes.
>
> The next ones could wait for next merge window. They get things to the
> point where misbehaving or buggy guest isn't so painful for the host,
>
On Sat, 28 Nov 2020 17:07:20 +1000, Nicholas Piggin wrote:
> First patch is a nasty memory scribble introduced by me :( That
> should go into fixes.
>
> The next ones could wait for next merge window. They get things to the
> point where misbehaving or buggy guest isn't so painful for the host,
>
This is a rebase now on top of Arnd's asm-generic tree, which has
reduced most of the fluff from this patch series.
The x86 refactoring is still in the way a bit, I hope to get some
movement on that rather than rebase the main patches off it, because
I think it's a good cleanup. I think it could g
First patch is a nasty memory scribble introduced by me :( That
should go into fixes.
The next ones could wait for next merge window. They get things to the
point where misbehaving or buggy guest isn't so painful for the host,
and also get the guest SLB dumping code working (because the host no
lo
On Thu, 26 Nov 2020 13:38:45 + Lee Jones wrote:
> Resending the stragglers.
>
> This set is part of a larger effort attempting to clean-up W=1
> kernel builds, which are currently overwhelmingly riddled with
> niggly little warnings.
This set doesn't apply to net-next, please rebase.
Resending the stragglers.
This set is part of a larger effort attempting to clean-up W=1
kernel builds, which are currently overwhelmingly riddled with
niggly little warnings.
Lee Jones (8):
net: ethernet: smsc: smc91x: Demote non-conformant kernel function
header
net: xen-netback: xenbus
As reported by Anton, there is a large penalty to signal handling
performance on radix systems using KUAP. The signal handling code
performs many user access operations, each of which needs to switch the
KUAP permissions bit to open and then close user access. This involves a
costly 'mtspr' operati
> > > >
> > > > Commit 12cc923f1ccc ("tasklet: Introduce new initialization
> > > > API")' introduced a new tasklet initialization API. This series
> > > > converts all the scsi drivers to use the new tasklet_setup() API
> > >
> > > I've got to say I agree with Jens, this was a silly obfuscation:
>
On Mon, 2020-08-17 at 12:28 -0700, Kees Cook wrote:
> On Mon, Aug 17, 2020 at 07:41:58AM -0700, James Bottomley wrote:
> > On Mon, 2020-08-17 at 14:24 +0530, Allen Pais wrote:
> > > From: Allen Pais
> > >
> > > Commit 12cc923f1ccc ("tasklet: Introduce new initialization
> > > API")' introduced a
On Mon, 2020-08-17 at 14:24 +0530, Allen Pais wrote:
> From: Allen Pais
>
> Commit 12cc923f1ccc ("tasklet: Introduce new initialization API")'
> introduced a new tasklet initialization API. This series converts
> all the scsi drivers to use the new tasklet_setup() API
I've got to say I agree wi
On Mon, Aug 17, 2020 at 07:41:58AM -0700, James Bottomley wrote:
> On Mon, 2020-08-17 at 14:24 +0530, Allen Pais wrote:
> > From: Allen Pais
> >
> > Commit 12cc923f1ccc ("tasklet: Introduce new initialization API")'
> > introduced a new tasklet initialization API. This series converts
> > all th
From: Allen Pais
Commit 12cc923f1ccc ("tasklet: Introduce new initialization API")'
introduced a new tasklet initialization API. This series converts
all the scsi drivers to use the new tasklet_setup() API
Allen Pais (8):
scsi: aic94xx: convert tasklets to use new tasklet_setup() API
scsi:
On Sun, 31 May 2020 09:17:03 +1000, Finn Thain wrote:
> The adb-iop driver was never finished. Some deficiencies have become
> apparent over the years. For example,
>
> - Mouse and/or keyboard may stop working if used together
>
> - SRQ autopoll list cannot be changed
>
> [...]
Applied to pow
Gentle ping.
On Sat, Jun 27, 2020 at 05:34:45PM +0300, Mike Rapoport wrote:
> From: Mike Rapoport
>
> Hi,
>
> Most architectures have very similar versions of pXd_alloc_one() and
> pXd_free_one() for intermediate levels of page table.
> These patches add generic versions of these functions in
This series adds an option to use queued spinlocks for powerpc, and
makes it the default for the Book3S-64 subarch.
This effort starts with the generic code so it's very simple but
still very performant. There are optimisations that can be made to
slowpaths, but I think it's better to attack those
On Mon, Jun 15, 2020 at 09:32:17AM +0200, refactormys...@gmail.com wrote:
> Bolarinwa Olayemi Saheed (8):
> IB/hfi1: Convert PCIBIOS_* errors to generic -E* errors
> IB/hfi1: Convert PCIBIOS_* errors to generic -E* errors
Applied to rdma for-next thanks
Jason
On Sat, Jun 27, 2020 at 5:35 PM Mike Rapoport wrote:
> Most architectures have very similar versions of pXd_alloc_one() and
> pXd_free_one() for intermediate levels of page table.
> These patches add generic versions of these functions in
> and enable use of the generic functions where
> appropri
On Sat, Jun 27, 2020 at 05:34:45PM +0300, Mike Rapoport wrote:
> Most architectures have very similar versions of pXd_alloc_one() and
> pXd_free_one() for intermediate levels of page table.
> These patches add generic versions of these functions in
> and enable use of the generic functions where
1 - 100 of 412 matches
Mail list logo
