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

This series renames pmd_mknotpresent() as pmd_mkinvalid(). 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 change

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 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() > >>

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 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

These patches apply to linux-5.8.0-rc1. Patches 1-3 should probably go into 5.8, the others can be queued for 5.9. Patches 4-6 improve the HMM self tests. Patch 7-8 prepare nouveau for the meat of this series which adds support and testing for compound page mapping of system memory (patches 9-11) and compound page migration to device private memory (patches 12-16). Since these changes are split

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]

On 19 Jun 2020, at 17:56, Ralph Campbell wrote: > Support transparent huge page migration to ZONE_DEVICE private memory. > A new flag (MIGRATE_PFN_COMPOUND) is added to the input PFN array to > indicate the huge page was fully mapped by the CPU. > Export prep_compound_page() so that device drivers can create huge > device private pages after calling memremap_pages(). > >

I''m sure everyone has seen the drop of VMI patches for Linux at this point, but just in case, the link is included below. I''ve read this version of the VMI spec and have made my way through most of the patches. While I wasn''t really that impressed with the first spec wrt Xen, the second version seems to be much more palatable. Specifically, the code inlining and

This series adds support for transparent huge page migration to migrate_vma_*() and adds nouveau SVM and HMM selftests as consumers. Earlier versions were posted previously [1] and [2]. The patches apply cleanly to the linux-mm 5.10.0-rc2 tree. There are a lot of other THP patches being posted. I don't think there are any semantic conflicts but there may be some merge conflicts depending on

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