similar to: [PATCH V2 0/2] mm/thp: Rename pmd_mknotpresent() as pmd_mkinvalid()

This series renames pmd_mknotpresent() as pmd_mknotvalid(). Before that it drops an existing pmd_mknotpresent() definition from powerpc platform which was never required as it defines it's pmdp_invalidate() through subscribing __HAVE_ARCH_PMDP_INVALIDATE. This does not create any functional change. This rename was suggested by Catalin during a previous discussion while we were trying to

pmd_present() is expected to test positive after pmdp_mknotpresent() as the PMD entry still points to a valid huge page in memory. pmdp_mknotpresent() implies that given PMD entry is just invalidated from MMU perspective while still holding on to pmd_page() referred valid huge page thus also clearing pmd_present() test. This creates the following situation which is counter intuitive.

On Tue, Apr 21, 2020 at 04:57:26AM +0530, Anshuman Khandual wrote: > > > On 04/21/2020 02:33 AM, Will Deacon wrote: > > On Fri, Mar 20, 2020 at 10:24:17AM +0530, Anshuman Khandual wrote: > >> pmd_present() is expected to test positive after pmdp_mknotpresent() as the > >> PMD entry still points to a valid huge page in memory. pmdp_mknotpresent() > >>

On Fri, Mar 20, 2020 at 10:24:17AM +0530, Anshuman Khandual wrote: > pmd_present() is expected to test positive after pmdp_mknotpresent() as the > PMD entry still points to a valid huge page in memory. pmdp_mknotpresent() > implies that given PMD entry is just invalidated from MMU perspective while > still holding on to pmd_page() referred valid huge page thus also clearing >

On 04/21/2020 02:33 AM, Will Deacon wrote: > On Fri, Mar 20, 2020 at 10:24:17AM +0530, Anshuman Khandual wrote: >> pmd_present() is expected to test positive after pmdp_mknotpresent() as the >> PMD entry still points to a valid huge page in memory. pmdp_mknotpresent() >> implies that given PMD entry is just invalidated from MMU perspective while >> still holding on to

On 03/20/2020 10:24 AM, Anshuman Khandual wrote: > This series renames pmd_mknotpresent() as pmd_mknotvalid(). Before that it > drops an existing pmd_mknotpresent() definition from powerpc platform which > was never required as it defines it's pmdp_invalidate() through subscribing > __HAVE_ARCH_PMDP_INVALIDATE. This does not create any functional change. > > This rename was

http://bugs.freedesktop.org/show_bug.cgi?id=14941 Summary: ioremap leak in DRM Product: xorg Version: unspecified Platform: x86-64 (AMD64) OS/Version: Linux (All) Status: NEW Severity: minor Priority: medium Component: Driver/nouveau AssignedTo: nouveau at lists.freedesktop.org ReportedBy:

Replacing return value -1 to error code Signed-off-by: Mugilraj Dhavachelvan <dmugil2000 at gmail.com> --- arch/x86/mm/kmmio.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/x86/mm/kmmio.c b/arch/x86/mm/kmmio.c index be020a7bc414..15430520c232 100644 --- a/arch/x86/mm/kmmio.c +++ b/arch/x86/mm/kmmio.c @@ -386,7 +386,7 @@ static int add_kmmio_fault_page(unsigned

Because Linux might use bigger pages than the 4K pages to handle those mmio ioremaps, the kmmio code shouldn't rely on the pade id as it currently does. Using the memory address instead of the page id let's us lookup how big the page is and what it's base address is, so that we won't get a page fault within the same page twice anymore. I don't know if I got this right though,

After every iounmap mmiotrace has to free kmmio_fault_pages, but it can't do it directly, so it defers freeing by RCU. It usually works, but when mmiotraced code calls ioremap-iounmap multiple times without sleeping between (so RCU won't kick in and start freeing) it can be given the same virtual address, so at every iounmap mmiotrace will schedule the same pages for release. Obviously it

There are ~4300 uses of pr_warn and ~250 uses of the older pr_warning in the kernel source tree. Make the use of pr_warn consistent across all kernel files. This excludes all files in tools/ as there is a separate define pr_warning for that directory tree and pr_warn is not used in tools/. Done with 'sed s/\bpr_warning\b/pr_warn/' and some emacsing. Miscellanea: o Coalesce formats and

There are ~4300 uses of pr_warn and ~250 uses of the older pr_warning in the kernel source tree. Make the use of pr_warn consistent across all kernel files. This excludes all files in tools/ as there is a separate define pr_warning for that directory tree and pr_warn is not used in tools/. Done with 'sed s/\bpr_warning\b/pr_warn/' and some emacsing. Miscellanea: o Coalesce formats and

There are ~4300 uses of pr_warn and ~250 uses of the older pr_warning in the kernel source tree. Make the use of pr_warn consistent across all kernel files. This excludes all files in tools/ as there is a separate define pr_warning for that directory tree and pr_warn is not used in tools/. Done with 'sed s/\bpr_warning\b/pr_warn/' and some emacsing. Miscellanea: o Coalesce formats and

Hi there, I'd like to help on finding out more details about the G8x hardware from NVidia, especially given these cards have more functionality than your average GPU: with CUDA ( http://developer.nvidia.com/object/cuda.html ) it is possible to use them as compute devices. This makes me very interested in their low level capabilities, like microcode/shader specifications, and maybe even how

On Mon, 13 Apr 2020, Geert Uytterhoeven wrote: > Below is the list of build error/warning regressions/improvements in > v5.7-rc1[1] compared to v5.6[2]. > > Summarized: > - build errors: +132/-3 > - build warnings: +257/-79 > > Happy fixing! ;-) > > Thanks to the linux-next team for providing the build service. > > [1]

On Mon, 13 Apr 2020, Geert Uytterhoeven wrote: > Below is the list of build error/warning regressions/improvements in > v5.7-rc1[1] compared to v5.6[2]. > > Summarized: > - build errors: +132/-3 > - build warnings: +257/-79 > > Happy fixing! ;-) > > Thanks to the linux-next team for providing the build service. > > [1]

http://bugs.freedesktop.org/show_bug.cgi?id=23672 Summary: Nouveau KMS fails with error: Failed to fence channel 0 Product: xorg Version: git Platform: Other OS/Version: All Status: NEW Severity: normal Priority: medium Component: Driver/nouveau AssignedTo: nouveau at lists.freedesktop.org

add_kmmio_fault_page using -1 instead of the -ENOMEM defined macro to specify kmmio_fault_page allocation failed. Smatch tool warning: arch/x86/mm/kmmio.c:389 add_kmmio_fault_page() warn: returning -1 instead of -ENOMEM is sloppy Signed-off-by: Vasyl Gomonovych <gomonovych at gmail.com> --- arch/x86/mm/kmmio.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

Both call sites, that access kmmio_ctx, access kmmio_ctx with interrupts disabled. There is no need to use get_cpu_var() which additionally disables preemption. Use this_cpu_ptr() to access the kmmio_ctx variable of the current CPU. Signed-off-by: Sebastian Andrzej Siewior <bigeasy at linutronix.de> --- arch/x86/mm/kmmio.c | 10 +++------- 1 file changed, 3 insertions(+), 7 deletions(-)

On Tue, 20 Oct 2020 14:13:44 +0530 Mugilraj Dhavachelvan <dmugil2000 at gmail.com> wrote: > Replacing return value -1 to error code > > Signed-off-by: Mugilraj Dhavachelvan <dmugil2000 at gmail.com> > --- > arch/x86/mm/kmmio.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/arch/x86/mm/kmmio.c b/arch/x86/mm/kmmio.c > index