On Tue, Sep 10, 2024 at 02:14:29PM +1000, Alistair Popple wrote:
> @@ -337,6 +341,7 @@ struct folio {
> /* private: */
> };
> /* public: */
> + struct dev_pagemap *pgmap;
Shouldn't that be indented by one more tab stop?
And for ease of
Currently if a PTE points to a FS DAX page vm_normal_page() will
return NULL as these have their own special refcounting scheme. A
future change will allow FS DAX pages to be refcounted the same as any
other normal page.
Therefore vm_normal_page() will start returning FS DAX pages. To avoid
any ch
Now that DAX and all other reference counts to ZONE_DEVICE pages are
managed normally there is no need for the special devmap PTE/PMD/PUD
page table bits. So drop all references to these, freeing up a
software defined page table bit on architectures supporting it.
Signed-off-by: Alistair Popple
A
The devmap PTE special bit was used to detect mappings of FS DAX
pages. This tracking was required to ensure the generic mm did not
manipulate the page reference counts as FS DAX implemented it's own
reference counting scheme.
Now that FS DAX pages have their references counted the same way as
nor
Currently fs dax pages are considered free when the refcount drops to
one and their refcounts are not increased when mapped via PTEs or
decreased when unmapped. This requires special logic in mm paths to
detect that these pages should not be properly refcounted, and to
detect when the refcount drop
Longterm pinning of FS DAX pages should already be disallowed by
various pXX_devmap checks. However a future change will cause these
checks to be invalid for FS DAX pages so make
folio_is_longterm_pinnable() return false for FS DAX pages.
Signed-off-by: Alistair Popple
---
include/linux/memremap
Currently DAX folio/page reference counts are managed differently to
normal pages. To allow these to be managed the same as normal pages
introduce dax_insert_pfn_pmd. This will map the entire PMD-sized folio
and take references as it would for a normally mapped page.
This is distinct from the curr
Currently DAX folio/page reference counts are managed differently to
normal pages. To allow these to be managed the same as normal pages
introduce dax_insert_pfn_pud. This will map the entire PUD-sized folio
and take references as it would for a normally mapped page.
This is distinct from the curr
Currently to map a DAX page the DAX driver calls vmf_insert_pfn. This
creates a special devmap PTE entry for the pfn but does not take a
reference on the underlying struct page for the mapping. This is
because DAX page refcounts are treated specially, as indicated by the
presence of a devmap entry.
Zone device pages are used to represent various type of device memory
managed by device drivers. Currently compound zone device pages are
not supported. This is because MEMORY_DEVICE_FS_DAX pages are the only
user of higher order zone device pages and have their own page
reference counting.
A futu
A FS DAX page is considered idle when its refcount drops to one. This
is currently open-coded in all file systems supporting FS DAX. Move
the idle detection to a common function to make future changes easier.
Signed-off-by: Alistair Popple
Reviewed-by: Jan Kara
Reviewed-by: Christoph Hellwig
--
The reference counts for ZONE_DEVICE private pages should be
initialised by the driver when the page is actually allocated by the
driver allocator, not when they are first created. This is currently
the case for MEMORY_DEVICE_PRIVATE and MEMORY_DEVICE_COHERENT pages
but not MEMORY_DEVICE_PCI_P2PDMA
PCI P2PDMA pages are not mapped with pXX_devmap PTEs therefore the
check in __gup_device_huge() is redundant. Remove it
Signed-off-by: Alistair Popple
Reviewed-by: Jason Gunthorpe
Acked-by: David Hildenbrand
---
mm/gup.c | 5 -
1 file changed, 5 deletions(-)
diff --git a/mm/gup.c b/mm/gup
Main updates since v1:
- Now passes the same number of xfs_test with dax=always as without
this series (some seem to fail on my setup normally). Thanks Dave
for the suggestion as there were some deadlocks/crashes in v1 due
to misshandling of write-protect faults and truncation which shou
Gaosheng Cui writes:
> Most of the drivers which used this header have been deleted, most
> of these code is obsoleted, move the only defines that are actually
> used into arch/powerpc/platforms/chrp/pegasos_eth.c and delete the
> file completely.
>
> Signed-off-by: Gaosheng Cui
> ---
> v2: Delet
On Fri, Sep 06, 2024 at 10:52:34AM +0100, Lorenzo Stoakes wrote:
> (Sorry having issues with my IPv6 setup that duplicated the original email...
>
> On Fri, Sep 06, 2024 at 09:14:08AM GMT, Arnd Bergmann wrote:
> > On Fri, Sep 6, 2024, at 08:14, Lorenzo Stoakes wrote:
> > > On Fri, Sep 06, 2024 at
The Powerpc cell_defconfig and mpc83xx_defconfig builds failed on the
Linux next-20240909 due to following build warnings / errors with gcc-13 and
clang-19.
First seen on next-20240909
Good: next-20240906
BAD: next-20240909
Reported-by: Linux Kernel Functional Testing
build log
On Mon, 09 Sep 2024 17:12:30 +0200, Uwe Kleine-König wrote:
> After commit 0edb555a65d1 ("platform: Make platform_driver::remove()
> return void") .remove() is (again) the right callback to implement for
> platform drivers.
>
> Convert all drivers below sound/soc to use .remove(), with the eventua
On Fri, Sep 06, 2024 at 04:59:40PM +1000, Michael Ellerman wrote:
> Charlie Jenkins writes:
> > Create a personality flag ADDR_LIMIT_47BIT to support applications
> > that wish to transition from running in environments that support at
> > most 47-bit VAs to environments that support larger VAs. T
The build of ppc44x_defconfig is ok with this change
on top of next-20240909
Hello all,
Just wanted to ping and see if there was any further feedback or
questions regarding the patch?
--
Ryan
On Mon, Sep 9, 2024 at 11:58 PM Stephen Rothwell wrote:
>
> Hi Christophe,
>
> On Mon, 9 Sep 2024 16:22:26 +0200 Christophe Leroy
> wrote:
> >
> > Le 09/09/2024 à 12:09, Stephen Rothwell a écrit :
> > > Hi all,
> > >
> > > After merging the powerpc tree, today's linux-next build (powerpc
> > > p
After commit 0edb555a65d1 ("platform: Make platform_driver::remove()
return void") .remove() is (again) the right callback to implement for
platform drivers.
Convert all drivers below sound/soc to use .remove(), with the eventual
goal to drop struct platform_driver::remove_new(). As .remove() and
Hi Christophe,
On Mon, 9 Sep 2024 16:22:26 +0200 Christophe Leroy
wrote:
>
> Le 09/09/2024 à 12:09, Stephen Rothwell a écrit :
> > Hi all,
> >
> > After merging the powerpc tree, today's linux-next build (powerpc
> > ppc44x_defconfig) failed like this:
> >
> > make[3]: *** No rule to make targ
On Mon, 9 Sep 2024 17:34:48 +0300
Mike Rapoport wrote:
> > This is insane, just force BUILDTIME_MCOUNT_SORT
>
> The comment in ftrace.c says "... while mcount loc in modules can not be
> sorted at build time"
>
> I don't know enough about objtool, but I'd presume it's because the sorting
> s
On Mon, Sep 09, 2024 at 11:29:23AM +0200, Peter Zijlstra wrote:
> On Mon, Sep 09, 2024 at 09:47:28AM +0300, Mike Rapoport wrote:
> > diff --git a/arch/x86/kernel/ftrace.c b/arch/x86/kernel/ftrace.c
> > index 8da0e66ca22d..563d9a890ce2 100644
> > --- a/arch/x86/kernel/ftrace.c
> > +++ b/arch/x86/ker
Le 09/09/2024 à 12:09, Stephen Rothwell a écrit :
Hi all,
After merging the powerpc tree, today's linux-next build (powerpc
ppc44x_defconfig) failed like this:
make[3]: *** No rule to make target 'arch/powerpc/boot/treeImage.ebony', needed
by 'arch/powerpc/boot/zImage'. Stop.
make[2]: ***
On 05/09/24 6:33 PM, Michael Ellerman wrote:
Narayana Murty N writes:
VFIO_EEH_PE_INJECT_ERR ioctl is currently failing on pseries
due to missing implementation of err_inject eeh_ops for pseries.
This patch implements pseries_eeh_err_inject in eeh_ops/pseries
eeh_ops. Implements support for i
VFIO_EEH_PE_INJECT_ERR ioctl is currently failing on pseries
due to missing implementation of err_inject eeh_ops for pseries.
This patch implements pseries_eeh_err_inject in eeh_ops/pseries
eeh_ops. Implements support for injecting MMIO load/store error
for testing from user space.
The check on PC
After commit 0edb555a65d1 ("platform: Make platform_driver::remove()
return void") .remove() is (again) the right callback to implement for
platform drivers.
Convert all pwm drivers to use .remove(), with the eventual goal to drop
struct platform_driver::remove_new(). As .remove() and .remove_new(
Most of the drivers which used this header have been deleted, most
of these code is obsoleted, move the only defines that are actually
used into arch/powerpc/platforms/chrp/pegasos_eth.c and delete the
file completely.
Signed-off-by: Gaosheng Cui
---
v2: Delete the header file include/linux/mv643
In some configuration, compilation raises warnings related to unused
data. Indeed, depending on configuration, those data can be unused.
mark those data as __maybe_unused to avoid compilation warnings.
Reported-by: kernel test robot
Closes:
https://lore.kernel.org/oe-kbuild-all/202409071707.ou2
On Mon, Sep 09, 2024 at 09:47:28AM +0300, Mike Rapoport wrote:
> diff --git a/arch/x86/kernel/ftrace.c b/arch/x86/kernel/ftrace.c
> index 8da0e66ca22d..563d9a890ce2 100644
> --- a/arch/x86/kernel/ftrace.c
> +++ b/arch/x86/kernel/ftrace.c
> @@ -654,4 +656,15 @@ void ftrace_graph_func(unsigned long
Hi all,
After merging the powerpc tree, today's linux-next build (powerpc
ppc44x_defconfig) failed like this:
make[3]: *** No rule to make target 'arch/powerpc/boot/treeImage.ebony', needed
by 'arch/powerpc/boot/zImage'. Stop.
make[2]: *** [/home/sfr/next/next/arch/powerpc/Makefile:236: zImage]
On Thu, Sep 05, 2024 at 10:26:52AM -0700, Charlie Jenkins wrote:
> On Thu, Sep 05, 2024 at 09:47:47AM +0300, Kirill A. Shutemov wrote:
> > On Thu, Aug 29, 2024 at 12:15:57AM -0700, Charlie Jenkins wrote:
> > > Some applications rely on placing data in free bits addresses allocated
> > > by mmap. Va
Hello:
This series was applied to netdev/net-next.git (main)
by David S. Miller :
On Wed, 4 Sep 2024 19:18:13 +0200 you wrote:
> Hi everyone,
>
> This is V3 of a series that cleans-up fs_enet, with the ultimate goal of
> converting it to phylink (patch 8).
>
> The main changes compared to V2 a
36 matches
Mail list logo
