On Wed, Aug 28, 2024 at 07:19:36PM +0100, Lorenzo Stoakes wrote:
> On Tue, Aug 27, 2024 at 10:49:06PM GMT, Charlie Jenkins wrote:
> > Some applications rely on placing data in free bits addresses allocated
> > by mmap. Various architectures (eg. x86, arm64, powerpc) restrict the
> > address returne
Some applications rely on placing data in free bits addresses allocated
by mmap. Various architectures (eg. x86, arm64, powerpc) restrict the
address returned by mmap to be less than the 48-bit address space,
unless the hint address uses more than 47 bits (the 48th bit is reserved
for the kernel ad
Some applications rely on placing data in free bits addresses allocated
by mmap. Various architectures (eg. x86, arm64, powerpc) restrict the
address returned by mmap to be less than the 48-bit address space,
unless the hint address uses more than 47 bits (the 48th bit is reserved
for the kernel ad
The hint address and mmap_flags are necessary to determine if
MAP_BELOW_HINT requirements are satisfied.
Signed-off-by: Charlie Jenkins
---
arch/alpha/kernel/osf_sys.c | 2 ++
arch/arc/mm/mmap.c | 3 +++
arch/arm/mm/mmap.c | 7 +++
arch/csky/abiv1/mmap.c
To ensure that all memory allocations comply with the new MAP_BELOW_HINT
flag, set the high_limit in vm_unmapped_area() to the hint address +
length at most. All callers to this function set the high_limit to
something reasonable, usually with space for a random offset and a gap
for the stack. To r
Add a selftest for MAP_BELOW_HINT that maps until it runs out of space
below the hint address.
Signed-off-by: Charlie Jenkins
---
tools/testing/selftests/mm/Makefile | 1 +
tools/testing/selftests/mm/map_below_hint.c | 32 +
2 files changed, 33 insertions(+)
On 2024/8/22 15:13, Qi Zheng wrote:
In assert_pte_locked(), we just get the ptl and assert if it was already
held, so convert it to using pte_offset_map_ro_nolock().
Signed-off-by: Qi Zheng
Reviewed-by: Muchun Song
> On Aug 22, 2024, at 15:13, Qi Zheng wrote:
>
> In filemap_fault_recheck_pte_none(), we just do pte_none() check, so
> convert it to using pte_offset_map_ro_nolock().
>
> Signed-off-by: Qi Zheng
Reviewed-by: Muchun Song
> On Aug 22, 2024, at 15:13, Qi Zheng wrote:
>
> In __collapse_huge_page_swapin(), we just use the ptl for pte_same() check
> in do_swap_page(). In other places, we directly use pte_offset_map_lock(),
> so convert it to using pte_offset_map_ro_nolock().
>
> Signed-off-by: Qi Zheng
Reviewed-
> On Aug 22, 2024, at 15:13, Qi Zheng wrote:
>
> In handle_pte_fault(), we may modify the vmf->pte after acquiring the
> vmf->ptl, so convert it to using pte_offset_map_rw_nolock(). But since we
> will do the pte_same() check, so there is no need to get pmdval to do
> pmd_same() check, just pa
Hi Pierre,
On 2024/8/27 23:40, Pierre Gondois wrote:
> Hello Yicong,
> IIUC we are looking for the maximum number of threads a CPU can have
> in the platform. But is is actually possible to have a platform with
> CPUs not having the same number of threads ?
>
I was thinking of the heterogenous p
On 2024/8/22 15:13, Qi Zheng wrote:
In collapse_pte_mapped_thp(), we may modify the pte and pmd entry after
acquring the ptl, so convert it to using pte_offset_map_rw_nolock(). At
this time, the write lock of mmap_lock is not held, and the pte_same()
check is not performed after the PTL held.
> On Aug 22, 2024, at 15:13, Qi Zheng wrote:
>
> In copy_pte_range(), we may modify the src_pte entry after holding the
> src_ptl, so convert it to using pte_offset_map_rw_nolock(). But since we
> already hold the write lock of mmap_lock, there is no need to get pmdval
> to do pmd_same() check
Charlie Jenkins writes:
> Some applications rely on placing data in free bits addresses allocated
> by mmap. Various architectures (eg. x86, arm64, powerpc) restrict the
> address returned by mmap to be less than the 48-bit address space,
> unless the hint address uses more than 47 bits (the 48th
Hello Simon,
On Wed, 28 Aug 2024 17:32:24 +0100
Simon Horman wrote:
> On Wed, Aug 28, 2024 at 11:51:02AM +0200, Maxime Chevallier wrote:
> > fs_enet is a quite old but still used Ethernet driver found on some NXP
> > devices. It has support for 10/100 Mbps ethernet, with half and full
> > duplex
On Thu, Aug 29, 2024 at 12:15:59AM GMT, Charlie Jenkins wrote:
[snip]
> diff --git a/mm/mmap.c b/mm/mmap.c
> index d0dfc85b209b..34ba0db23678 100644
> --- a/mm/mmap.c
> +++ b/mm/mmap.c
> @@ -1796,6 +1796,9 @@ generic_get_unmapped_area(struct file *filp, unsigned
> long addr,
> struct vm_un
Helper function for_each_child_of_node() can iterate
through the DT node, so we don't need to use while loop.
Signed-off-by: Lin Ruifeng
---
sound/aoa/core/gpio-feature.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/sound/aoa/core/gpio-feature.c b/sound/aoa/core/gpio-featu
On Thu, Aug 29, 2024 at 12:15:57AM GMT, Charlie Jenkins wrote:
> Some applications rely on placing data in free bits addresses allocated
> by mmap. Various architectures (eg. x86, arm64, powerpc) restrict the
> address returned by mmap to be less than the 48-bit address space,
> unless the hint add
On Thu 29-08-24 00:15:57, Charlie Jenkins wrote:
> Some applications rely on placing data in free bits addresses allocated
> by mmap. Various architectures (eg. x86, arm64, powerpc) restrict the
> address returned by mmap to be less than the 48-bit address space,
> unless the hint address uses more
On Wed, 2024-08-28 at 18:38 +0800, Jinjie Ruan wrote:
> cxl_pci_to_cfg_record() is not used anywhere, and its function can be
> replacd with PCI_DEVID(), so remove it.
>
> Signed-off-by: Jinjie Ruan
This description is inaccurate - this removes both
cxl_pci_to_cfg_record() (which is unused), and
Such a large recipient list and no linux-api. CC'd, please include it on
future postings.
On 8/29/24 09:15, Charlie Jenkins wrote:
> Some applications rely on placing data in free bits addresses allocated
> by mmap. Various architectures (eg. x86, arm64, powerpc) restrict the
> address returned by
On Thu, Aug 29, 2024 at 09:42:22AM GMT, Lorenzo Stoakes wrote:
> On Thu, Aug 29, 2024 at 12:15:57AM GMT, Charlie Jenkins wrote:
> > Some applications rely on placing data in free bits addresses allocated
> > by mmap. Various architectures (eg. x86, arm64, powerpc) restrict the
> > address returned
On Wed, Aug 28, 2024 at 09:27:23AM +0200, Christophe Leroy wrote:
>
>
> Le 28/08/2024 à 08:50, Luming Yu a écrit :
> > On Wed, Aug 28, 2024 at 07:46:52AM +0200, Christophe Leroy wrote:
> > > Hi,
> > >
> > > Le 28/08/2024 à 05:17, 虞陆铭 a écrit :
> > > > Hi,
> > > >
> > > > it appears the little f
On 2024/8/28 18:48, David Hildenbrand wrote:
On 27.08.24 06:33, Qi Zheng wrote:
[...]
sufficient AFAIUK.
Drop the "AFAIUK" :)
"For R/O access this is sufficient."
pte_offset_map_rw_nolock(mm, pmd, addr, pmdvalp, ptlp), above, is like
pte_offset_map_ro_nolock(); but when successful, i
Hi Christophe,
On 27/08/2024 18:14, Christophe Leroy wrote:
>
>
> Le 27/08/2024 à 18:05, Vincenzo Frascino a écrit :
>> Hi Christophe,
>>
>> On 27/08/2024 11:49, Christophe Leroy wrote:
>>
>> ...
...
>>
>> Could you please clarify where minmax is needed? I tried to build Jason's
>> master
>>
Hello Yicong,
On 8/29/24 09:40, Yicong Yang wrote:
Hi Pierre,
On 2024/8/27 23:40, Pierre Gondois wrote:
Hello Yicong,
IIUC we are looking for the maximum number of threads a CPU can have
in the platform. But is is actually possible to have a platform with
CPUs not having the same number of thr
On 8/27/24 22:27, Oleksandr Ocheretnyi wrote:
Commit 450be4960a0f ("powerpc/pci: Remove LSI mappings on device
teardown") frees irq descriptors on PCIe hotplug link change event
(Link Down), but the disposed mappings are not restored back on PCIe
hotplug link change event (Card present).
This
Hi Christophe,
On 27/08/2024 18:38, LEROY Christophe wrote:
> Hi Vicenzo,
>
> Le 27/08/2024 à 18:05, Vincenzo Frascino a écrit :
>> Hi Christophe,
>>
>> On 27/08/2024 11:49, Christophe Leroy wrote:
>>
>> ...
>>
>>
>>
>> I agree with Arnd here. uapi/linux/mman.h can cause us problems in the long
https://git.codelinaro.org/linaro/qcomlt/ci/staging/cdba-tester/-/jobs/165617
bisect log:
# bad: [b18bbfc14a38b5234e09c2adcf713e38063a7e6e] Add linux-next specific files
for 20240829
# good: [5be63fc19fcaa4c236b307420483578a56986a37] Linux 6.11-rc5
git bisect start 'FETCH_HEAD' &#
On 2024-08-29 2:42 pm, Neil Armstrong wrote:
Hi,
On 11/08/2024 09:09, Baruch Siach wrote:
From: Catalin Marinas
Hardware DMA limit might not be power of 2. When RAM range starts above
0, say 4GB, DMA limit of 30 bits should end at 5GB. A single high bit
can not encode this limit.
Use plain a
Hi Robin,
On 29/08/2024 16:38, Robin Murphy wrote:
On 2024-08-29 2:42 pm, Neil Armstrong wrote:
Hi,
On 11/08/2024 09:09, Baruch Siach wrote:
From: Catalin Marinas
Hardware DMA limit might not be power of 2. When RAM range starts above
0, say 4GB, DMA limit of 30 bits should end at 5GB. A si
Hi Vincenzo,
Le 29/08/2024 à 14:01, Vincenzo Frascino a écrit :
Hi Christophe,
On 27/08/2024 18:14, Christophe Leroy wrote:
Le 27/08/2024 à 18:05, Vincenzo Frascino a écrit :
Hi Christophe,
On 27/08/2024 11:49, Christophe Leroy wrote:
...
...
Could you please clarify where minmax is
On 29.08.24 12:59, Qi Zheng wrote:
On 2024/8/28 18:48, David Hildenbrand wrote:
On 27.08.24 06:33, Qi Zheng wrote:
[...]
sufficient AFAIUK.
Drop the "AFAIUK" :)
"For R/O access this is sufficient."
pte_offset_map_rw_nolock(mm, pmd, addr, pmdvalp, ptlp), above, is like
pte_offset_map_
...
>>> Without linux/array_size.h:
>>>
>>> VDSO32C arch/powerpc/kernel/vdso/vgetrandom-32.o
>>> In file included from :
>>> /home/chleroy/linux-powerpc/lib/vdso/getrandom.c: In function
>>> '__cvdso_getrandom_data':
>>> /home/chleroy/linux-powerpc/lib/vdso/getrandom.c:89:40: error: implicit
On 22.08.24 09:13, Qi Zheng wrote:
In copy_pte_range(), we may modify the src_pte entry after holding the
src_ptl, so convert it to using pte_offset_map_rw_nolock(). But since we
already hold the write lock of mmap_lock, there is no need to get pmdval
to do pmd_same() check, just pass a dummy var
There's no in-tree user for the fs_ops .adjust_link() function, so we
can always use the generic one in fe_enet-main.
Acked-by: Christophe Leroy
Reviewed-by: Christophe Leroy
Signed-off-by: Maxime Chevallier
---
drivers/net/ethernet/freescale/fs_enet/fs_enet-main.c | 7 +--
drivers/net/eth
Hi everyone,
This is V2 of the fs_enet cleanup and phylink conversion series. The
main difference from V1 is the introduction of patch 6, that uses
devm_get_clk_enabled to manage the register clock, a cleanup of the
probe error sequence, and the removal of the netif_running checks.
I also gathere
The ENET driver has SPDX tags in the header files, but they were missing
in the C files. Change the licence information to SPDX format.
Acked-by: Christophe Leroy
Reviewed-by: Christophe Leroy
Signed-off-by: Maxime Chevallier
---
drivers/net/ethernet/freescale/fs_enet/fs_enet-main.c | 5 +
The PHY speed and duplex should be manipulated using the SPEED_XXX and
DUPLEX_XXX macros available. Use it in the fcc, fec and scc MAC for fs_enet.
Acked-by: Christophe Leroy
Reviewed-by: Christophe Leroy
Signed-off-by: Maxime Chevallier
---
drivers/net/ethernet/freescale/fs_enet/mac-fcc.c | 4
devm_clock_get_enabled() can be used to simplify clock handling for the
PER register clock.
Signed-off-by: Maxime Chevallier
---
- v2: new patch
.../ethernet/freescale/fs_enet/fs_enet-main.c| 16
drivers/net/ethernet/freescale/fs_enet/fs_enet.h | 2 --
2 files changed, 4 i
fs_enet is a quite old but still used Ethernet driver found on some NXP
devices. It has support for 10/100 Mbps ethernet, with half and full
duplex. Some variants of it can use RMII, while other integrations are
MII-only.
Add phylink support, thus removing custom fixed-link hanldling.
This also a
There's no user of the struct phy_info, the 'phy' field and the
mii_if_info in the fs_enet driver, probably dating back when phylib
wasn't as widely used. Drop these from the driver code.
Acked-by: Christophe Leroy
Reviewed-by: Christophe Leroy
Signed-off-by: Maxime Chevallier
---
drivers/net
Due to the age of the driver and the slow recent activity on it, the code
has taken some layers of dust. Clean the main driver file up so that it
passes checkpatch and also conforms with the net coding style.
Changes include :
- Re-ordering of the variable declarations for RCT
- Fixing the comme
On 8/28/24 13:15, Charlie Jenkins wrote:
> A way to restrict mmap() to return LAM compliant addresses in an entire
> address space also doesn't have to be mutually exclusive with this flag.
> This flag allows for the greatest degree of control from applications.
> I don't believe there is additiona
On Thu, Aug 29, 2024 at 10:30:56AM +0200, Michal Hocko wrote:
> On Thu 29-08-24 00:15:57, Charlie Jenkins wrote:
> > Some applications rely on placing data in free bits addresses allocated
> > by mmap. Various architectures (eg. x86, arm64, powerpc) restrict the
> > address returned by mmap to be l
Le 28/08/2024 à 19:25, Segher Boessenkool a écrit :
Not sure about static binaries, though: do those even use the VDSO?
With "static binary" people usually mean "a binary not using any DSOs",
I think the VDSO is a DSO, also in this respect? As always, -static
builds are *way* less problem
On Thu, Aug 22, 2024 at 04:10:59PM +0100, Joey Gouly wrote:
> +static bool fault_from_pkey(unsigned long esr, struct vm_area_struct *vma,
> + unsigned int mm_flags)
> +{
> + unsigned long iss2 = ESR_ELx_ISS2(esr);
> +
> + if (!system_supports_poe())
> + retu
On Thu, Aug 29, 2024 at 07:36:38PM +0200, Christophe Leroy wrote:
>
>
> Le 28/08/2024 à 19:25, Segher Boessenkool a écrit :
> >
> >>Not sure about static binaries, though: do those even use the VDSO?
> >
> >With "static binary" people usually mean "a binary not using any DSOs",
> >I think the VDS
Le 29/08/2024 à 20:02, Segher Boessenkool a écrit :
On Thu, Aug 29, 2024 at 07:36:38PM +0200, Christophe Leroy wrote:
Le 28/08/2024 à 19:25, Segher Boessenkool a écrit :
Not sure about static binaries, though: do those even use the VDSO?
With "static binary" people usually mean "a bina
* Dave Hansen [240829 12:54]:
> On 8/28/24 13:15, Charlie Jenkins wrote:
> > A way to restrict mmap() to return LAM compliant addresses in an entire
> > address space also doesn't have to be mutually exclusive with this flag.
> > This flag allows for the greatest degree of control from application
On Thu, Aug 29, 2024 at 10:54:25AM +0100, Lorenzo Stoakes wrote:
> On Thu, Aug 29, 2024 at 09:42:22AM GMT, Lorenzo Stoakes wrote:
> > On Thu, Aug 29, 2024 at 12:15:57AM GMT, Charlie Jenkins wrote:
> > > Some applications rely on placing data in free bits addresses allocated
> > > by mmap. Various a
From: Thierry Reding
On Tue, 27 Aug 2024 19:45:59 +0800, Jinjie Ruan wrote:
> Use for_each_child_of_node_scoped() to simplify code.
>
> Jinjie Ruan (8):
> soc: fsl: cpm1: Simplify with scoped for each OF child loop
> soc: fsl: cpm1: Simplify with dev_err_probe()
> soc: fsl: cpm1: qmc: Sim
Jinjie Ruan writes:
> @@ -1080,17 +1080,13 @@ static int knav_queue_setup_regions(struct
> knav_device *kdev,
> {
> struct device *dev = kdev->dev;
> struct knav_region *region;
> - struct device_node *child;
> u32 temp[2];
> int ret;
>
> - for_each_child_of_nod
On Thu, 29 Aug 2024 02:02:34 PDT (-0700), vba...@suse.cz wrote:
> Such a large recipient list and no linux-api. CC'd, please include it on
> future postings.
>
> On 8/29/24 09:15, Charlie Jenkins wrote:
>> Some applications rely on placing data in free bits addresses allocated
>> by mmap. Various a
On 21:28-20240829, Kousik Sanagavarapu wrote:
> Jinjie Ruan writes:
> > @@ -1080,17 +1080,13 @@ static int knav_queue_setup_regions(struct
> > knav_device *kdev,
> > {
> > struct device *dev = kdev->dev;
> > struct knav_region *region;
> > - s
On Thu, Aug 29, 2024 at 09:54:08AM -0700, Dave Hansen wrote:
> On 8/28/24 13:15, Charlie Jenkins wrote:
> > A way to restrict mmap() to return LAM compliant addresses in an entire
> > address space also doesn't have to be mutually exclusive with this flag.
> > This flag allows for the greatest degr
On Thu, Aug 29, 2024 at 03:36:43PM -0400, Liam R. Howlett wrote:
> * Dave Hansen [240829 12:54]:
> > On 8/28/24 13:15, Charlie Jenkins wrote:
> > > A way to restrict mmap() to return LAM compliant addresses in an entire
> > > address space also doesn't have to be mutually exclusive with this flag.
On Thu, Aug 29, 2024 at 09:48:44AM +0100, Lorenzo Stoakes wrote:
> On Thu, Aug 29, 2024 at 12:15:59AM GMT, Charlie Jenkins wrote:
>
> [snip]
>
> > diff --git a/mm/mmap.c b/mm/mmap.c
> > index d0dfc85b209b..34ba0db23678 100644
> > --- a/mm/mmap.c
> > +++ b/mm/mmap.c
> > @@ -1796,6 +1796,9 @@ gener
On Thu, Aug 29, 2024 at 06:26:41PM +1000, Michael Ellerman wrote:
> Charlie Jenkins writes:
> > Some applications rely on placing data in free bits addresses allocated
> > by mmap. Various architectures (eg. x86, arm64, powerpc) restrict the
> > address returned by mmap to be less than the 48-bit
Hi Dave,
On 08/23/24 at 08:51am, Dave Vasilevsky wrote:
..snip..
> diff --git a/arch/sh/Kconfig b/arch/sh/Kconfig
> index 1aa3c4a0c5b2..b04cfa23378c 100644
> --- a/arch/sh/Kconfig
> +++ b/arch/sh/Kconfig
> @@ -549,6 +549,9 @@ config ARCH_SUPPORTS_KEXEC
> config ARCH_SUPPORTS_CRASH_DUMP
>
On 2024/8/29 23:58, Kousik Sanagavarapu wrote:
> Jinjie Ruan writes:
>> @@ -1080,17 +1080,13 @@ static int knav_queue_setup_regions(struct
>> knav_device *kdev,
>> {
>> struct device *dev = kdev->dev;
>> struct knav_region *region;
>> -struct device_node *child;
>> u32 temp
On 2024-08-29 23:15, Baoquan He wrote:
>> +config ARCH_DEFAULT_CRASH_DUMP
>> +def_bool n
>
> If we don't add ARCH_DEFAULT_CRASH_DUMP at all in sh arch, the
> CRASH_DUMP will be off by default according to the below new definition
> of CRASH_DUMP?
Yes, that's true. But if we don't add it at al
Use the dev_err_probe() helper to simplify error handling during probe.
Signed-off-by: Jinjie Ruan
---
v2:
- Update the commit message.
---
drivers/soc/fsl/qe/qmc.c | 53
1 file changed, 21 insertions(+), 32 deletions(-)
diff --git a/drivers/soc/fsl/qe/q
Use for_each_child_of_node_scoped() and dev_err_probe() to simplify code.
Changes in v2:
- Split from the whole soc patch set.
- Update the commit message.
Jinjie Ruan (4):
soc: fsl: cpm1: Simplify with scoped for each OF child loop
soc: fsl: cpm1: Simplify with dev_err_probe()
soc: fsl: cp
Use the dev_err_probe() helper to simplify error handling during probe.
Signed-off-by: Jinjie Ruan
---
v2:
- Update the commit message.
---
drivers/soc/fsl/qe/tsa.c | 62 +++-
1 file changed, 23 insertions(+), 39 deletions(-)
diff --git a/drivers/soc/fsl/qe/t
Use scoped for_each_available_child_of_node_scoped() when iterating
over device nodes to make code a bit simpler.
Signed-off-by: Jinjie Ruan
---
drivers/soc/fsl/qe/qmc.c | 13 ++---
1 file changed, 2 insertions(+), 11 deletions(-)
diff --git a/drivers/soc/fsl/qe/qmc.c b/drivers/soc/fsl/
Use scoped for_each_available_child_of_node_scoped when iterating
over device nodes to make code a bit simpler.
Signed-off-by: Jinjie Ruan
---
drivers/soc/fsl/qe/tsa.c | 28
1 file changed, 4 insertions(+), 24 deletions(-)
diff --git a/drivers/soc/fsl/qe/tsa.c b/dri
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git
fixes-test
branch HEAD: f8c29fc27feb230a3383204f22aa5474042f6ed8 powerpc/pseries: Fix
dtl_access_lock to be a rw_semaphore
elapsed time: 909m
configs tested: 167
configs skipped: 6
The following configs have been b
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git
fixes
branch HEAD: 734ad0af3609464f8f93e00b6c0de1e112f44559 powerpc/qspinlock: Fix
deadlock in MCS queue
elapsed time: 913m
configs tested: 167
configs skipped: 6
The following configs have been built successfully.
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git
next-test
branch HEAD: 8ae4f16f7d7b59cca55aeca6db7c9636ffe7fbaa powerpc/64s/mm: Move
__real_pte stubs into hash-4k.h
elapsed time: 926m
configs tested: 167
configs skipped: 6
The following configs have been built s
On 08/29/24 at 11:37pm, Dave Vasilevsky wrote:
> On 2024-08-29 23:15, Baoquan He wrote:
> >> +config ARCH_DEFAULT_CRASH_DUMP
> >> + def_bool n
> >
> > If we don't add ARCH_DEFAULT_CRASH_DUMP at all in sh arch, the
> > CRASH_DUMP will be off by default according to the below new definition
> > of
On 08/23/24 at 08:51am, Dave Vasilevsky wrote:
> Fixes boot failures on 6.9 on PPC_BOOK3S_32 machines using
> Open Firmware. On these machines, the kernel refuses to boot
> from non-zero PHYSICAL_START, which occurs when CRASH_DUMP is on.
>
> Since most PPC_BOOK3S_32 machines boot via Open Firmwar
On 2024/8/29 23:31, David Hildenbrand wrote:
On 29.08.24 12:59, Qi Zheng wrote:
On 2024/8/28 18:48, David Hildenbrand wrote:
On 27.08.24 06:33, Qi Zheng wrote:
[...]
sufficient AFAIUK.
Drop the "AFAIUK" :)
"For R/O access this is sufficient."
pte_offset_map_rw_nolock(mm, pmd, add
On 2024/8/29 23:36, David Hildenbrand wrote:
On 22.08.24 09:13, Qi Zheng wrote:
In copy_pte_range(), we may modify the src_pte entry after holding the
src_ptl, so convert it to using pte_offset_map_rw_nolock(). But since we
already hold the write lock of mmap_lock, there is no need to get pmd
On 2024/8/29 16:10, Muchun Song wrote:
On 2024/8/22 15:13, Qi Zheng wrote:
In collapse_pte_mapped_thp(), we may modify the pte and pmd entry after
acquring the ptl, so convert it to using pte_offset_map_rw_nolock(). At
this time, the write lock of mmap_lock is not held, and the pte_same()
c
75 matches
Mail list logo
