--- /dev/null
+From e1c71f8f918047ce822dc19b42ab1261ed259fd1 Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Ville=20Syrj=C3=A4l=C3=A4?= <ville.syrjala@linux.intel.com>
+Date: Wed, 29 Mar 2023 20:24:33 +0300
+Subject: drm/i915: Fix fast wake AUX sync len
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Ville Syrjälä <ville.syrjala@linux.intel.com>
+
+commit e1c71f8f918047ce822dc19b42ab1261ed259fd1 upstream.
+
+Fast wake should use 8 SYNC pulses for the preamble
+and 10-16 SYNC pulses for the precharge. Reduce our
+fast wake SYNC count to match the maximum value.
+We also use the maximum precharge length for normal
+AUX transactions.
+
+Cc: stable@vger.kernel.org
+Cc: Jouni Högander <jouni.hogander@intel.com>
+Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
+Link: https://patchwork.freedesktop.org/patch/msgid/20230329172434.18744-1-ville.syrjala@linux.intel.com
+Reviewed-by: Jouni Högander <jouni.hogander@intel.com>
+(cherry picked from commit 605f7c73133341d4b762cbd9a22174cc22d4c38b)
+Signed-off-by: Jani Nikula <jani.nikula@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/gpu/drm/i915/display/intel_dp_aux.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/gpu/drm/i915/display/intel_dp_aux.c
++++ b/drivers/gpu/drm/i915/display/intel_dp_aux.c
+@@ -167,7 +167,7 @@ static u32 skl_get_aux_send_ctl(struct i
+ DP_AUX_CH_CTL_TIME_OUT_MAX |
+ DP_AUX_CH_CTL_RECEIVE_ERROR |
+ (send_bytes << DP_AUX_CH_CTL_MESSAGE_SIZE_SHIFT) |
+- DP_AUX_CH_CTL_FW_SYNC_PULSE_SKL(32) |
++ DP_AUX_CH_CTL_FW_SYNC_PULSE_SKL(24) |
+ DP_AUX_CH_CTL_SYNC_PULSE_SKL(32);
+
+ if (intel_phy_is_tc(i915, phy) &&
--- /dev/null
+From dd47ac428c3f5f3bcabe845f36be870fe6c20784 Mon Sep 17 00:00:00 2001
+From: Peter Xu <peterx@redhat.com>
+Date: Wed, 5 Apr 2023 11:51:20 -0400
+Subject: mm/khugepaged: check again on anon uffd-wp during isolation
+
+From: Peter Xu <peterx@redhat.com>
+
+commit dd47ac428c3f5f3bcabe845f36be870fe6c20784 upstream.
+
+Khugepaged collapse an anonymous thp in two rounds of scans. The 2nd
+round done in __collapse_huge_page_isolate() after
+hpage_collapse_scan_pmd(), during which all the locks will be released
+temporarily. It means the pgtable can change during this phase before 2nd
+round starts.
+
+It's logically possible some ptes got wr-protected during this phase, and
+we can errornously collapse a thp without noticing some ptes are
+wr-protected by userfault. e1e267c7928f wanted to avoid it but it only
+did that for the 1st phase, not the 2nd phase.
+
+Since __collapse_huge_page_isolate() happens after a round of small page
+swapins, we don't need to worry on any !present ptes - if it existed
+khugepaged will already bail out. So we only need to check present ptes
+with uffd-wp bit set there.
+
+This is something I found only but never had a reproducer, I thought it
+was one caused a bug in Muhammad's recent pagemap new ioctl work, but it
+turns out it's not the cause of that but an userspace bug. However this
+seems to still be a real bug even with a very small race window, still
+worth to have it fixed and copy stable.
+
+Link: https://lkml.kernel.org/r/20230405155120.3608140-1-peterx@redhat.com
+Fixes: e1e267c7928f ("khugepaged: skip collapse if uffd-wp detected")
+Signed-off-by: Peter Xu <peterx@redhat.com>
+Reviewed-by: David Hildenbrand <david@redhat.com>
+Reviewed-by: Yang Shi <shy828301@gmail.com>
+Cc: Andrea Arcangeli <aarcange@redhat.com>
+Cc: Axel Rasmussen <axelrasmussen@google.com>
+Cc: Mike Rapoport <rppt@linux.vnet.ibm.com>
+Cc: Nadav Amit <nadav.amit@gmail.com>
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ mm/khugepaged.c | 4 ++++
+ 1 file changed, 4 insertions(+)
+
+--- a/mm/khugepaged.c
++++ b/mm/khugepaged.c
+@@ -625,6 +625,10 @@ static int __collapse_huge_page_isolate(
+ result = SCAN_PTE_NON_PRESENT;
+ goto out;
+ }
++ if (pte_uffd_wp(pteval)) {
++ result = SCAN_PTE_UFFD_WP;
++ goto out;
++ }
+ page = vm_normal_page(vma, address, pteval);
+ if (unlikely(!page)) {
+ result = SCAN_PAGE_NULL;
--- /dev/null
+From 4d73ba5fa710fe7d432e0b271e6fecd252aef66e Mon Sep 17 00:00:00 2001
+From: Mel Gorman <mgorman@techsingularity.net>
+Date: Fri, 14 Apr 2023 15:14:29 +0100
+Subject: mm: page_alloc: skip regions with hugetlbfs pages when allocating 1G pages
+
+From: Mel Gorman <mgorman@techsingularity.net>
+
+commit 4d73ba5fa710fe7d432e0b271e6fecd252aef66e upstream.
+
+A bug was reported by Yuanxi Liu where allocating 1G pages at runtime is
+taking an excessive amount of time for large amounts of memory. Further
+testing allocating huge pages that the cost is linear i.e. if allocating
+1G pages in batches of 10 then the time to allocate nr_hugepages from
+10->20->30->etc increases linearly even though 10 pages are allocated at
+each step. Profiles indicated that much of the time is spent checking the
+validity within already existing huge pages and then attempting a
+migration that fails after isolating the range, draining pages and a whole
+lot of other useless work.
+
+Commit eb14d4eefdc4 ("mm,page_alloc: drop unnecessary checks from
+pfn_range_valid_contig") removed two checks, one which ignored huge pages
+for contiguous allocations as huge pages can sometimes migrate. While
+there may be value on migrating a 2M page to satisfy a 1G allocation, it's
+potentially expensive if the 1G allocation fails and it's pointless to try
+moving a 1G page for a new 1G allocation or scan the tail pages for valid
+PFNs.
+
+Reintroduce the PageHuge check and assume any contiguous region with
+hugetlbfs pages is unsuitable for a new 1G allocation.
+
+The hpagealloc test allocates huge pages in batches and reports the
+average latency per page over time. This test happens just after boot
+when fragmentation is not an issue. Units are in milliseconds.
+
+hpagealloc
+ 6.3.0-rc6 6.3.0-rc6 6.3.0-rc6
+ vanilla hugeallocrevert-v1r1 hugeallocsimple-v1r2
+Min Latency 26.42 ( 0.00%) 5.07 ( 80.82%) 18.94 ( 28.30%)
+1st-qrtle Latency 356.61 ( 0.00%) 5.34 ( 98.50%) 19.85 ( 94.43%)
+2nd-qrtle Latency 697.26 ( 0.00%) 5.47 ( 99.22%) 20.44 ( 97.07%)
+3rd-qrtle Latency 972.94 ( 0.00%) 5.50 ( 99.43%) 20.81 ( 97.86%)
+Max-1 Latency 26.42 ( 0.00%) 5.07 ( 80.82%) 18.94 ( 28.30%)
+Max-5 Latency 82.14 ( 0.00%) 5.11 ( 93.78%) 19.31 ( 76.49%)
+Max-10 Latency 150.54 ( 0.00%) 5.20 ( 96.55%) 19.43 ( 87.09%)
+Max-90 Latency 1164.45 ( 0.00%) 5.53 ( 99.52%) 20.97 ( 98.20%)
+Max-95 Latency 1223.06 ( 0.00%) 5.55 ( 99.55%) 21.06 ( 98.28%)
+Max-99 Latency 1278.67 ( 0.00%) 5.57 ( 99.56%) 22.56 ( 98.24%)
+Max Latency 1310.90 ( 0.00%) 8.06 ( 99.39%) 26.62 ( 97.97%)
+Amean Latency 678.36 ( 0.00%) 5.44 * 99.20%* 20.44 * 96.99%*
+
+ 6.3.0-rc6 6.3.0-rc6 6.3.0-rc6
+ vanilla revert-v1 hugeallocfix-v2
+Duration User 0.28 0.27 0.30
+Duration System 808.66 17.77 35.99
+Duration Elapsed 830.87 18.08 36.33
+
+The vanilla kernel is poor, taking up to 1.3 second to allocate a huge
+page and almost 10 minutes in total to run the test. Reverting the
+problematic commit reduces it to 8ms at worst and the patch takes 26ms.
+This patch fixes the main issue with skipping huge pages but leaves the
+page_count() out because a page with an elevated count potentially can
+migrate.
+
+BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=217022
+Link: https://lkml.kernel.org/r/20230414141429.pwgieuwluxwez3rj@techsingularity.net
+Fixes: eb14d4eefdc4 ("mm,page_alloc: drop unnecessary checks from pfn_range_valid_contig")
+Signed-off-by: Mel Gorman <mgorman@techsingularity.net>
+Reported-by: Yuanxi Liu <y.liu@naruida.com>
+Acked-by: Vlastimil Babka <vbabka@suse.cz>
+Reviewed-by: David Hildenbrand <david@redhat.com>
+Acked-by: Michal Hocko <mhocko@suse.com>
+Reviewed-by: Oscar Salvador <osalvador@suse.de>
+Cc: Matthew Wilcox <willy@infradead.org>
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ mm/page_alloc.c | 3 +++
+ 1 file changed, 3 insertions(+)
+
+--- a/mm/page_alloc.c
++++ b/mm/page_alloc.c
+@@ -9239,6 +9239,9 @@ static bool pfn_range_valid_contig(struc
+
+ if (PageReserved(page))
+ return false;
++
++ if (PageHuge(page))
++ return false;
+ }
+ return true;
+ }
--- /dev/null
+From 2265098fd6a6272fde3fd1be5761f2f5895bd99a Mon Sep 17 00:00:00 2001
+From: Bhavya Kapoor <b-kapoor@ti.com>
+Date: Fri, 17 Mar 2023 14:57:11 +0530
+Subject: mmc: sdhci_am654: Set HIGH_SPEED_ENA for SDR12 and SDR25
+
+From: Bhavya Kapoor <b-kapoor@ti.com>
+
+commit 2265098fd6a6272fde3fd1be5761f2f5895bd99a upstream.
+
+Timing Information in Datasheet assumes that HIGH_SPEED_ENA=1 should be
+set for SDR12 and SDR25 modes. But sdhci_am654 driver clears
+HIGH_SPEED_ENA register. Thus, Modify sdhci_am654 to not clear
+HIGH_SPEED_ENA (HOST_CONTROL[2]) bit for SDR12 and SDR25 speed modes.
+
+Fixes: e374e87538f4 ("mmc: sdhci_am654: Clear HISPD_ENA in some lower speed modes")
+Signed-off-by: Bhavya Kapoor <b-kapoor@ti.com>
+Cc: stable@vger.kernel.org
+Link: https://lore.kernel.org/r/20230317092711.660897-1-b-kapoor@ti.com
+Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/mmc/host/sdhci_am654.c | 2 --
+ 1 file changed, 2 deletions(-)
+
+--- a/drivers/mmc/host/sdhci_am654.c
++++ b/drivers/mmc/host/sdhci_am654.c
+@@ -351,8 +351,6 @@ static void sdhci_am654_write_b(struct s
+ */
+ case MMC_TIMING_SD_HS:
+ case MMC_TIMING_MMC_HS:
+- case MMC_TIMING_UHS_SDR12:
+- case MMC_TIMING_UHS_SDR25:
+ val &= ~SDHCI_CTRL_HISPD;
+ }
+ }
nilfs2-initialize-unused-bytes-in-segment-summary-blocks.patch
memstick-fix-memory-leak-if-card-device-is-never-registered.patch
kernel-sys.c-fix-and-improve-control-flow-in-__sys_setresid.patch
+mmc-sdhci_am654-set-high_speed_ena-for-sdr12-and-sdr25.patch
+drm-i915-fix-fast-wake-aux-sync-len.patch
+mm-khugepaged-check-again-on-anon-uffd-wp-during-isolation.patch
+mm-page_alloc-skip-regions-with-hugetlbfs-pages-when-allocating-1g-pages.patch
projects / thirdparty / kernel / stable-queue.git / commitdiff
