Hi Pavel,
After going through this series, I think if this can be done by using
identity map through ttbr0.
Then the processes may be neat (I hope so):
-1. set up identity map in machine_kexec_post_load(), instead of
copying linear map.
-2. Also past this temporary identity map to
On Tue, Mar 9, 2021 at 10:02 PM Will Deacon wrote:
>
> [typo in subject "rebudant"]
>
> On Tue, Mar 09, 2021 at 06:21:38PM +0800, Pingfan Liu wrote:
> > There are two identical implementations of setup_per_cpu_areas() in
> > mm/percpu.c and drivers/base/arch_numa
There are two identical implementations of setup_per_cpu_areas() in
mm/percpu.c and drivers/base/arch_numa.c.
Hence removing the one in arch_numa.c. And let arm64 drop
HAVE_SETUP_PER_CPU_AREA.
Signed-off-by: Pingfan Liu
Cc: Catalin Marinas
Cc: Will Deacon
Cc: Greg Kroah-Hartman
Cc: "Raf
On Tue, Dec 8, 2020 at 5:51 PM Marc Zyngier wrote:
>
> On 2020-12-08 09:43, Pingfan Liu wrote:
> > On Tue, Dec 8, 2020 at 5:31 PM Marc Zyngier wrote:
> >>
> >> On 2020-12-08 09:21, Pingfan Liu wrote:
> >> > Although there is a runtime WARN_ON() w
On Tue, Dec 8, 2020 at 5:31 PM Marc Zyngier wrote:
>
> On 2020-12-08 09:21, Pingfan Liu wrote:
> > Although there is a runtime WARN_ON() when NR_IPR > max SGI, it had
> > better
> > do the check during built time, and associate these related code
> > together.
&
Although there is a runtime WARN_ON() when NR_IPR > max SGI, it had better
do the check during built time, and associate these related code together.
Signed-off-by: Pingfan Liu
Cc: Catalin Marinas
Cc: Will Deacon
Cc: Thomas Gleixner
Cc: Jason Cooper
Cc: Marc Zyngier
Cc: Mark Rutl
Sorry that I had made a misunderstanding of the code.
Nacked it
On Mon, Nov 23, 2020 at 1:37 PM Pingfan Liu wrote:
>
> During jumping to the new kernel, on the crashed cpu, the memory mapping
> switches from an old one to an identity one. It had better disable PMU to
> suppress NM
On Mon, Nov 23, 2020 at 10:05 PM Peter Zijlstra wrote:
>
> On Mon, Nov 23, 2020 at 01:37:25PM +0800, Pingfan Liu wrote:
>
> > +/* When crashed, other cpus hang in idle loop, so here do an emergency job
> > under no lock */
>
> -ENOPARSE, -ETOOLONG
>
>
In crash context, NMI should be suppressed before jump to a new kernel.
Naturally as the source of NMI on some arches, PMU should be turned off at
that time.
Introduce perf_pmu_disable_all() to achieve the goal.
Signed-off-by: Pingfan Liu
Cc: Peter Zijlstra
Cc: Ingo Molnar
Cc: Arnaldo
During jumping to the new kernel, on the crashed cpu, the memory mapping
switches from an old one to an identity one. It had better disable PMU to
suppress NMI, which can be delivered using the old mapping.
Also on x86_64, idt_invalidate() to clear idt as on 32 bits.
Signed-off-by: Pingfan Liu
://lore.kernel.org/lkml/87tuueftou@nanos.tec.linutronix.de/
[2]:
https://lore.kernel.org/linux-pci/20181018183721.27467-1-gpicc...@canonical.com/
Signed-off-by: Pingfan Liu
Cc: Thomas Gleixner
Cc: Jisheng Zhang
Cc: "Peter Zijlstra (Intel)"
Cc: Vlastimil Babka
Cc: Andrew Morton
Cc: &q
The incoming statistics of irq average number will base on the delta of
watchdog_touch_ts. Improving the accuracy of watchdog_touch_ts from second
to nanosecond can help improve the accuracy of the statistics.
Signed-off-by: Pingfan Liu
Cc: Thomas Gleixner
Cc: Jisheng Zhang
Cc: "Peter Zij
quot;
Cc: Petr Mladek
Cc: ke...@lists.infradead.org
To: linux-kernel@vger.kernel.org
Pingfan Liu (3):
x86/irq: account the unused irq
kernel/watchdog: make watchdog_touch_ts more accurate by using
nanosecond
kernel/watchdog: use soft lockup to detect irq flood
arch/x86/kernel/irq.c | 1 +
in
Accounting the unused irq in order to count it if irq flood.
Signed-off-by: Pingfan Liu
Cc: Thomas Gleixner
Cc: Jisheng Zhang
Cc: "Peter Zijlstra (Intel)"
Cc: Vlastimil Babka
Cc: Andrew Morton
Cc: "Guilherme G. Piccoli"
Cc: Petr Mladek
Cc: ke...@lists.infradead.
On Wed, Oct 28, 2020 at 7:58 PM Thomas Gleixner wrote:
>
[...]
> ---
> include/linux/irqdesc.h |4 ++
> kernel/irq/manage.c |3 +
> kernel/irq/spurious.c | 74
> +++-
> 3 files changed, 61 insertions(+), 20 deletions(-)
>
> ---
On Wed, Oct 28, 2020 at 12:58:41PM +0100, Thomas Gleixner wrote:
> On Wed, Oct 28 2020 at 14:02, Pingfan Liu wrote:
> > On Tue, Oct 27, 2020 at 3:59 AM Thomas Gleixner wrote:
> >> Also Liu's patch only works if:
> >>
> >> 1) CONFIG_IRQ_TIME_ACCOUNTING is ena
On Tue, Oct 27, 2020 at 3:59 AM Thomas Gleixner wrote:
>
[...]
>
> And contrary to Liu's patches which try to disable a requested interrupt
> if too many of them arrive, the kernel cannot do anything because there
> is nothing to disable in your case. That's why you needed to do the MSI
> disable
On Sun, Oct 25, 2020 at 8:21 PM Oliver O'Halloran wrote:
>
> On Sun, Oct 25, 2020 at 10:22 PM Pingfan Liu wrote:
> >
> > On Thu, Oct 22, 2020 at 4:37 PM Thomas Gleixner wrote:
> > >
> > > On Thu, Oct 22 2020 at 13:56, Pingfan Liu wrote:
> > > > I
On Thu, Oct 22, 2020 at 4:37 PM Thomas Gleixner wrote:
>
> On Thu, Oct 22 2020 at 13:56, Pingfan Liu wrote:
> > I hit a irqflood bug on powerpc platform, and two years ago, on a x86
> > platform.
> > When the bug happens, the kernel is totally occupies by irq. Curre
The param "irqflood_suppress" is helpful for capture kernel to survive irq
flood.
Signed-off-by: Pingfan Liu
Cc: Thomas Gleixner
Cc: Peter Zijlstra
Cc: Jisheng Zhang
Cc: Andrew Morton
Cc: "Guilherme G. Piccoli"
Cc: Petr Mladek
Cc: Marc Zyngier
Cc: Linus Walleij
Cc
off-by: Pingfan Liu
Cc: Thomas Gleixner
Cc: Peter Zijlstra
Cc: Jisheng Zhang
Cc: Andrew Morton
Cc: "Guilherme G. Piccoli"
Cc: Petr Mladek
Cc: Marc Zyngier
Cc: Linus Walleij
Cc: afzal mohammed
Cc: Lina Iyer
Cc: "Gustavo A. R. Silva"
Cc: Maulik Shah
Cc: Al Viro
Cc: Jon
The capture kernel should try its best to save the crash info. Normally,
irq flood is caused by some trivial devices, which has no impact on saving
vmcore.
Introducing a parameter "irqflood_suppress" to enable suppress irq flood.
Signed-off-by: Pingfan Liu
Cc: Thomas Gleixner
hah
Cc: Al Viro
Cc: Jonathan Corbet
Cc: Pawan Gupta
Cc: Mike Kravetz
Cc: Oliver Neukum
To: linux-kernel@vger.kernel.org
Cc: linux-...@vger.kernel.org
Cc: ke...@lists.infradead.org
Pingfan Liu (3):
kernel/watchdog: show irq percentage if irq floods
kernel/watchdog: suppress max
On Wed, Oct 14, 2020 at 9:02 PM Peter Zijlstra wrote:
>
> On Mon, Oct 12, 2020 at 09:50:44PM +0800, Pingfan Liu wrote:
> > __do_softirq() may be interrupted by hardware interrupts. In this case,
> > irqtime_account_irq() will account the time slice as CPUTIME_SOFT
On Tue, Oct 13, 2020 at 11:10 AM jun qian wrote:
>
> Pingfan Liu 于2020年10月12日周一 下午9:54写道：
> >
> > __do_softirq() may be interrupted by hardware interrupts. In this case,
> > irqtime_account_irq() will account the time slice as CPUTIME_SOFTIRQ by
> &g
-by: Pingfan Liu
Cc: Ingo Molnar
Cc: Peter Zijlstra
Cc: Juri Lelli
Cc: Vincent Guittot
Cc: Dietmar Eggemann
Cc: Steven Rostedt
Cc: Ben Segall
Cc: Mel Gorman
Cc: Thomas Gleixner
Cc: Andy Lutomirski
Cc: Will Deacon
Cc: "Paul E. McKenney"
Cc: Frederic Weisbecker
Cc: Allen Pais
The following commit has been merged into the x86/urgent branch of tip:
Commit-ID: 52416ffcf823ee11aa19792715664ab94757f111
Gitweb:
https://git.kernel.org/tip/52416ffcf823ee11aa19792715664ab94757f111
Author:Pingfan Liu
AuthorDate:Mon, 03 Aug 2020 13:49:48 +08:00
Committer
The following commit has been merged into the x86/urgent branch of tip:
Commit-ID: b031cf7752a82fefa6818a788d906d14f533afa9
Gitweb:
https://git.kernel.org/tip/b031cf7752a82fefa6818a788d906d14f533afa9
Author:Pingfan Liu
AuthorDate:Mon, 03 Aug 2020 13:49:48 +08:00
Committer
is useless in purgatory.ro. And discarding them can save about
200K space.
Original:
259080 kexec-purgatory.o
Stripped debug info:
29152 kexec-purgatory.o
Signed-off-by: Pingfan Liu
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: Borislav Petkov
Cc: "H. Peter Anvin"
Cc: Hans de Goede
On Sat, Aug 1, 2020 at 2:18 AM Nick Desaulniers wrote:
>
> On Fri, Jul 31, 2020 at 2:36 AM Pingfan Liu wrote:
> >
> > On Fri, Jul 31, 2020 at 7:11 AM Nick Desaulniers
> > wrote:
> > >
> > > On Thu, Jul 30, 2020 at 1:27 AM Pingfan Liu wrote:
> &
On Fri, Jul 31, 2020 at 7:11 AM Nick Desaulniers
wrote:
>
> On Thu, Jul 30, 2020 at 1:27 AM Pingfan Liu wrote:
> >
> > It is useless to keep debug info in purgatory. And discarding them saves
> > about 200K space.
> >
> > Original:
> > 259080 ke
It is useless to keep debug info in purgatory. And discarding them saves
about 200K space.
Original:
259080 kexec-purgatory.o
Stripped:
29152 kexec-purgatory.o
Signed-off-by: Pingfan Liu
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: Borislav Petkov
Cc: "H. Peter Anvin"
Cc: Han
On Fri, Aug 16, 2019 at 11:02:22PM +0800, Pingfan Liu wrote:
> On Thu, Aug 15, 2019 at 01:22:22PM -0400, Jerome Glisse wrote:
> > On Tue, Aug 06, 2019 at 04:00:10PM +0800, Pingfan Liu wrote:
> > > MIGRATE_PFN_MIGRATE marks a valid pfn, further more, suitable to migrate.
On Thu, Aug 15, 2019 at 01:22:22PM -0400, Jerome Glisse wrote:
> On Tue, Aug 06, 2019 at 04:00:10PM +0800, Pingfan Liu wrote:
> > MIGRATE_PFN_MIGRATE marks a valid pfn, further more, suitable to migrate.
> > As for hole, there is no valid pfn, not to mention migration.
> >
On Thu, Aug 15, 2019 at 03:40:21PM -0400, Jerome Glisse wrote:
> On Thu, Aug 15, 2019 at 12:23:44PM -0700, Ralph Campbell wrote:
> [...]
> >
> > I don't understand. The only use of "pfn" I see is in the "else"
> > clause above where it is set just before using it.
>
> Ok i managed to confuse
Clean up useless 'pfn' variable.
Signed-off-by: Pingfan Liu
Cc: "Jérôme Glisse"
Cc: Andrew Morton
Cc: Mel Gorman
Cc: Jan Kara
Cc: "Kirill A. Shutemov"
Cc: Michal Hocko
Cc: Mike Kravetz
Cc: Andrea Arcangeli
Cc: Matthew Wilcox
To: linux...@kvack.org
Cc: linux-ke
On Wed, Aug 07, 2019 at 11:00:41AM +0800, Dave Young wrote:
> Add Tony and Xunlei in cc.
> On 08/05/19 at 04:58pm, Pingfan Liu wrote:
> > This series include two related groups:
> > [1-3/4]: protect nr_cpus from rebooting by broadcast mce
> > [4/4]: improve "kexec -l&
On Tue, Aug 06, 2019 at 06:35:03AM -0700, Matthew Wilcox wrote:
>
> This needs something beyond the subject line. Maybe ...
>
> After these assignments, we either restart the loop with a fresh variable,
> or we assign to the variable again without using the value we've assigned.
>
>
.
migrate_vma_prepare()
{
struct page *page = migrate_pfn_to_page(migrate->src[i]);
if (!page || (migrate->src[i] & MIGRATE_PFN_MIGRATE))
\_ this condition
}
Signed-off-by: Pingfan Liu
Cc: "Jérôme Glisse"
Cc: Andrew Morton
Cc: Mel Gorm
Signed-off-by: Pingfan Liu
Cc: "Jérôme Glisse"
Cc: Andrew Morton
Cc: Mel Gorman
Cc: Jan Kara
Cc: "Kirill A. Shutemov"
Cc: Michal Hocko
Cc: Mike Kravetz
Cc: Andrea Arcangeli
Cc: Matthew Wilcox
To: linux...@kvack.org
Cc: linux-kernel@vger.kernel.org
---
mm/migrate
After the previous patch which sees hole as invalid source,
migrate_vma_collect_hole() has the same code as migrate_vma_collect_skip().
Removing the duplicated code.
Signed-off-by: Pingfan Liu
Cc: "Jérôme Glisse"
Cc: Andrew Morton
Cc: Mel Gorman
Cc: Jan Kara
Cc: "Kirill A
On Mon, Jul 22, 2019 at 11:41:29AM +0200, Thomas Gleixner wrote:
> On Wed, 10 Jul 2019, Pingfan Liu wrote:
> >
> > +static inline bool maxcpus_allowed(unsigned int cpu)
> > +{
> > + /* maxcpus only takes effect during system bootup */
> > + if (smp_boot_
Commit-ID: 69732102426b1c55a257386841fb80ec1f425d32
Gitweb: https://git.kernel.org/tip/69732102426b1c55a257386841fb80ec1f425d32
Author: Pingfan Liu
AuthorDate: Tue, 16 Jul 2019 16:40:24 +0800
Committer: Thomas Gleixner
CommitDate: Mon, 22 Jul 2019 11:30:18 +0200
x86/realmode: Remove
In current code, there is no reader of trampoline_status. It turns out that
after commit ce4b1b16502b ("x86/smpboot: Initialize secondary CPU only if
master CPU will wait for it"), trampoline_status is not needed any more.
Signed-off-by: Pingfan Liu
Cc: Thomas Gleixner
Cc: Ingo
On Tue, Jul 9, 2019 at 9:34 PM Andy Lutomirski wrote:
>
>
>
> > On Jul 9, 2019, at 1:24 AM, Pingfan Liu wrote:
> >
> >> On Tue, Jul 9, 2019 at 2:12 PM Thomas Gleixner wrote:
> >>
> >>> On Tue, 9 Jul 2019, Pingfan Liu wrote:
> >>>
of
maxcpus, the initialization of capped out cpus may be deferred indefinitely
until a user brings them up. This exposes the machine under the risk of
sudden shutdown indefinitely.
Minimize the risk window by initializing all cpus at boot time.
Signed-off-by: Pingfan Liu
Cc: Thomas Gleixner
Cc: "
On Tue, Jul 9, 2019 at 2:12 PM Thomas Gleixner wrote:
>
> On Tue, 9 Jul 2019, Pingfan Liu wrote:
> > On Mon, Jul 8, 2019 at 5:35 PM Thomas Gleixner wrote:
> > > It can and it does.
> > >
> > > That's the whole point why we bring up all CPUs in the 'nosmt
On Tue, Jul 9, 2019 at 1:53 AM Andy Lutomirski wrote:
>
>
>
> > On Jul 8, 2019, at 3:35 AM, Thomas Gleixner wrote:
> >
> >> On Mon, 8 Jul 2019, Pingfan Liu wrote:
> >>> On Mon, Jul 8, 2019 at 3:44 AM Thomas Gleixner wrote:
> >>>
> >&g
On Mon, Jul 8, 2019 at 5:35 PM Thomas Gleixner wrote:
>
> On Mon, 8 Jul 2019, Pingfan Liu wrote:
> > On Mon, Jul 8, 2019 at 3:44 AM Thomas Gleixner wrote:
> > >
> > > On Fri, 5 Jul 2019, Pingfan Liu wrote:
> > >
> > > > I hit a bug on an A
On Mon, Jul 8, 2019 at 3:44 AM Thomas Gleixner wrote:
>
> On Fri, 5 Jul 2019, Pingfan Liu wrote:
>
> > I hit a bug on an AMD machine, with kexec -l nr_cpus=4 option. nr_cpus
> > option
> > is used to speed up kdump process, so it is not a rare case.
>
>
or other archs, they need extra
dedicated effort.
[1]: https://patchwork.kernel.org/patch/10738733/
[2]: https://lkml.org/lkml/2019/2/13/253
[3]: https://lore.kernel.org/lkml/20190528182011.gg1...@dhcp22.suse.cz/T/
Signed-off-by: Pingfan Liu
Cc: Michal Hocko
Cc: Dave Hansen
Cc: Mike Rapoport
Cc: Tony Luck
Cc:
Node online means either memory online or cpu online. But there is
requirement to instance a pglist_data, which has neither cpu nor memory
online (refer to [2/2]).
So carve out the online semantics, and call node_set_online() where either
memory or cpu is online.
Signed-off-by: Pingfan Liu
Cc
undo_isolate_page_range() never fails, so no need to return value.
Signed-off-by: Pingfan Liu
Cc: Andrew Morton
Cc: Michal Hocko
Cc: Oscar Salvador
Cc: Qian Cai
Cc: Anshuman Khandual
Cc: linux-kernel@vger.kernel.org
---
include/linux/page-isolation.h | 2 +-
mm/page_isolation.c
On Fri, Jun 28, 2019 at 7:25 AM Andrew Morton wrote:
>
> On Thu, 27 Jun 2019 13:15:45 +0800 Pingfan Liu wrote:
>
> > Both hugetlb and thp locate on the same migration type of pageblock, since
> > they are allocated from a free_list[]. Based on this fact, it is enough to
,
similar on other archs.
Furthermore, when executing isolate_huge_page(), it avoid taking global
hugetlb_lock many times, and meanless remove/add to the local link list
cma_page_list.
Signed-off-by: Pingfan Liu
Cc: Andrew Morton
Cc: Ira Weiny
Cc: Mike Rapoport
Cc: "Kirill A. Shutemov"
On Wed, Jun 26, 2019 at 9:57 PM Michal Hocko wrote:
>
> On Mon 24-06-19 16:42:20, Pingfan Liu wrote:
> > Hi Michal,
> >
> > What about dropping the change of the online definition of your patch,
> > just do the following?
>
> I am sorry but I am unl
On Thu, Jun 27, 2019 at 7:15 AM Andrew Morton wrote:
>
> On Wed, 26 Jun 2019 21:10:00 +0800 Pingfan Liu wrote:
>
> > Both hugetlb and thp locate on the same migration type of pageblock, since
> > they are allocated from a free_list[]. Based on this fact, it is enough to
,
similar on other archs.
Furthermore, when executing isolate_huge_page(), it avoid taking global
hugetlb_lock many times, and meanless remove/add to the local link list
cma_page_list.
Signed-off-by: Pingfan Liu
Cc: Andrew Morton
Cc: Ira Weiny
Cc: Mike Rapoport
Cc: "Kirill A. Shutemov"
On Wed, Jun 26, 2019 at 1:51 AM Ira Weiny wrote:
>
> On Tue, Jun 25, 2019 at 10:13:19PM +0800, Pingfan Liu wrote:
> > Both hugetlb and thp locate on the same migration type of pageblock, since
> > they are allocated from a free_list[]. Based on this fact, it is enough to
>
,
similar on other archs.
Furthermore, when executing isolate_huge_page(), it avoid taking global
hugetlb_lock many times, and meanless remove/add to the local link list
cma_page_list.
Signed-off-by: Pingfan Liu
Cc: Andrew Morton
Cc: Ira Weiny
Cc: Mike Rapoport
Cc: "Kirill A. Shutemov"
Hi Michal,
What about dropping the change of the online definition of your patch,
just do the following?
diff --git a/arch/x86/mm/numa.c b/arch/x86/mm/numa.c
index e6dad60..9c087c3 100644
--- a/arch/x86/mm/numa.c
+++ b/arch/x86/mm/numa.c
@@ -749,13 +749,12 @@ static void __init
On Mon, Jun 24, 2019 at 1:16 PM Anshuman Khandual
wrote:
>
>
>
> On 06/24/2019 09:51 AM, Pingfan Liu wrote:
> > The current pfn_range_valid_gigantic() rejects the pud huge page allocation
> > if there is a pmd huge page inside the candidate range.
> >
> > But p
On Mon, Jun 24, 2019 at 1:03 PM Ira Weiny wrote:
>
> On Mon, Jun 24, 2019 at 12:21:08PM +0800, Pingfan Liu wrote:
> > The current pfn_range_valid_gigantic() rejects the pud huge page allocation
> > if there is a pmd huge page inside the candidate range.
> >
> > But
On Mon, Jun 24, 2019 at 1:32 PM Pingfan Liu wrote:
>
> On Mon, Jun 24, 2019 at 12:43 PM Ira Weiny wrote:
> >
> > On Mon, Jun 24, 2019 at 12:12:41PM +0800, Pingfan Liu wrote:
> > > Both hugetlb and thp locate on the same migration type of pageblock, since
> > >
On Mon, Jun 24, 2019 at 12:43 PM Ira Weiny wrote:
>
> On Mon, Jun 24, 2019 at 12:12:41PM +0800, Pingfan Liu wrote:
> > Both hugetlb and thp locate on the same migration type of pageblock, since
> > they are allocated from a free_list[]. Based on this fact, it is enough to
>
logic is applied to pgd and pud huge pages.
Signed-off-by: Pingfan Liu
Cc: Mike Kravetz
Cc: Oscar Salvador
Cc: David Hildenbrand
Cc: Andrew Morton
Cc: linux-kernel@vger.kernel.org
---
mm/hugetlb.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/mm/hugetlb.c b/mm
,
similar on other archs.
Furthermore, when executing isolate_huge_page(), it avoid taking global
hugetlb_lock many times, and meanless remove/add to the local link list
cma_page_list.
Signed-off-by: Pingfan Liu
Cc: Andrew Morton
Cc: Ira Weiny
Cc: Mike Rapoport
Cc: "Kirill A. Shutemov"
On Sat, Jun 22, 2019 at 2:13 AM Ira Weiny wrote:
>
> On Fri, Jun 21, 2019 at 06:15:16PM +0800, Pingfan Liu wrote:
> > Both hugetlb and thp locate on the same migration type of pageblock, since
> > they are allocated from a free_list[]. Based on this fact, it is enough to
>
,
similar on other archs.
Furthermore, when executing isolate_huge_page(), it avoid taking global
hugetlb_lock many times, and meanless remove/add to the local link list
cma_page_list.
Signed-off-by: Pingfan Liu
Cc: Andrew Morton
Cc: Ira Weiny
Cc: Mike Rapoport
Cc: "Kirill A. Shutemov"
Cc Mike, David, who is an expert of hugetlb and thp
On Fri, Jun 14, 2019 at 5:37 AM Ira Weiny wrote:
>
> On Thu, Jun 13, 2019 at 06:45:01PM +0800, Pingfan Liu wrote:
> > FOLL_LONGTERM suggests a pin which is going to be given to hardware and
> > can't move. It would trunca
Introduce a GUP_LONGTERM_BENCHMARK ioctl to test longterm pin in gup fast
path.
Signed-off-by: Pingfan Liu
Cc: Ira Weiny
Cc: Andrew Morton
Cc: Mike Rapoport
Cc: Dan Williams
Cc: Matthew Wilcox
Cc: John Hubbard
Cc: "Aneesh Kumar K.V"
Cc: Keith Busch
Cc: Christoph Hellwig
Cc:
To better reflect the held state of pages and make code self-explaining,
rename nr as nr_pinned.
Signed-off-by: Pingfan Liu
Cc: Ira Weiny
Cc: Andrew Morton
Cc: Mike Rapoport
Cc: Dan Williams
Cc: Matthew Wilcox
Cc: John Hubbard
Cc: "Aneesh Kumar K.V"
Cc: Keith Busch
Cc: Christo
requirement through this crack.
Place a check in gup_pte_range() in the fast path.
Signed-off-by: Pingfan Liu
Cc: Ira Weiny
Cc: Andrew Morton
Cc: Mike Rapoport
Cc: Dan Williams
Cc: Matthew Wilcox
Cc: John Hubbard
Cc: "Aneesh Kumar K.V"
Cc: Keith Busch
Cc: Christoph Hellwig
Cc: Shua
ike Rapoport
Cc: Dan Williams
Cc: Matthew Wilcox
Cc: John Hubbard
Cc: "Aneesh Kumar K.V"
Cc: Keith Busch
Cc: Christoph Hellwig
Cc: Shuah Khan
Cc: linux-kernel@vger.kernel.org
Pingfan Liu (3):
mm/gup: rename nr as nr_pinned in get_user_pages_fast()
mm/gup: fix omission of check on
On Thu, Jun 13, 2019 at 7:49 AM Ira Weiny wrote:
>
> On Wed, Jun 12, 2019 at 09:54:58PM +0800, Pingfan Liu wrote:
> > On Tue, Jun 11, 2019 at 04:29:11PM +, Weiny, Ira wrote:
> > > > Pingfan Liu writes:
> > > >
> > > > > A
On Wed, Jun 12, 2019 at 12:46 AM Ira Weiny wrote:
>
> On Tue, Jun 11, 2019 at 08:29:35PM +0800, Pingfan Liu wrote:
> > On Fri, Jun 07, 2019 at 02:10:15PM +0800, Pingfan Liu wrote:
> > > On Fri, Jun 7, 2019 at 5:17 AM John Hubbard wrote:
> > > >
> > &
On Tue, Jun 11, 2019 at 04:29:11PM +, Weiny, Ira wrote:
> > Pingfan Liu writes:
> >
> > > As for FOLL_LONGTERM, it is checked in the slow path
> > > __gup_longterm_unlocked(). But it is not checked in the fast path,
> > > which means a possible leak of
On Fri, Jun 07, 2019 at 02:10:15PM +0800, Pingfan Liu wrote:
> On Fri, Jun 7, 2019 at 5:17 AM John Hubbard wrote:
> >
> > On 6/5/19 7:19 PM, Pingfan Liu wrote:
> > > On Thu, Jun 6, 2019 at 5:49 AM Andrew Morton
> > > wrote:
> > ...
> &
On Fri, Jun 7, 2019 at 5:17 AM John Hubbard wrote:
>
> On 6/5/19 7:19 PM, Pingfan Liu wrote:
> > On Thu, Jun 6, 2019 at 5:49 AM Andrew Morton
> > wrote:
> ...
> >>> --- a/mm/gup.c
> >>> +++ b/mm/gup.c
> >>> @@ -2196,6 +2196,26 @@ stat
On Thu, Jun 6, 2019 at 5:49 AM Andrew Morton wrote:
>
> On Wed, 5 Jun 2019 17:10:19 +0800 Pingfan Liu wrote:
>
> > As for FOLL_LONGTERM, it is checked in the slow path
> > __gup_longterm_unlocked(). But it is not checked in the fast path, which
> > means a possible l
To better reflect the held state of pages and make code self-explaining,
rename nr as nr_pinned.
Signed-off-by: Pingfan Liu
Cc: Ira Weiny
Cc: Andrew Morton
Cc: Mike Rapoport
Cc: Dan Williams
Cc: Matthew Wilcox
Cc: John Hubbard
Cc: "Aneesh Kumar K.V"
Cc: Keith Busch
Cc: Christo
As for FOLL_LONGTERM, it is checked in the slow path
__gup_longterm_unlocked(). But it is not checked in the fast path, which
means a possible leak of CMA page to longterm pinned requirement through
this crack.
Place a check in the fast path.
Signed-off-by: Pingfan Liu
Cc: Ira Weiny
Cc: Andrew
On Tue, Jun 4, 2019 at 4:30 PM Aneesh Kumar K.V
wrote:
>
> On 6/4/19 12:56 PM, Pingfan Liu wrote:
> > The PF_MEMALLOC_NOCMA is set by memalloc_nocma_save(), which is finally
> > cast to ~_GFP_MOVABLE. So __get_user_pages_locked() will get pages from
> > n
The PF_MEMALLOC_NOCMA is set by memalloc_nocma_save(), which is finally
cast to ~_GFP_MOVABLE. So __get_user_pages_locked() will get pages from
non CMA area and pin them. There is no need to
check_and_migrate_cma_pages().
Signed-off-by: Pingfan Liu
Cc: Andrew Morton
Cc: Ira Weiny
Cc: Dan
On Tue, Jun 4, 2019 at 3:08 PM Christoph Hellwig wrote:
>
> On Mon, Jun 03, 2019 at 04:56:10PM -0700, Ira Weiny wrote:
> > On Mon, Jun 03, 2019 at 09:42:06AM -0700, Christoph Hellwig wrote:
> > > > +#if defined(CONFIG_CMA)
> > >
> > > You can just use #ifdef here.
> > >
> > > > +static inline int
On Tue, Jun 4, 2019 at 3:17 PM Christoph Hellwig wrote:
>
> On Tue, Jun 04, 2019 at 03:13:21PM +0800, Pingfan Liu wrote:
> > Is it a convention? scripts/checkpatch.pl can not detect it. Could you
> > show me some light so later I can avoid it?
>
> If you look at most ker
On Tue, Jun 4, 2019 at 12:42 AM Christoph Hellwig wrote:
>
> > +#if defined(CONFIG_CMA)
>
> You can just use #ifdef here.
>
OK.
> > +static inline int reject_cma_pages(int nr_pinned, unsigned int gup_flags,
> > + struct page **pages)
>
> Please use two instead of one tab to indent the
As for FOLL_LONGTERM, it is checked in the slow path
__gup_longterm_unlocked(). But it is not checked in the fast path, which
means a possible leak of CMA page to longterm pinned requirement through
this crack.
Place a check in the fast path.
Signed-off-by: Pingfan Liu
Cc: Ira Weiny
Cc: Andrew
To better reflect the held state of pages and make code self-explaining,
rename nr as nr_pinned.
Signed-off-by: Pingfan Liu
Cc: Ira Weiny
Cc: Andrew Morton
Cc: Mike Rapoport
Cc: Dan Williams
Cc: Matthew Wilcox
Cc: John Hubbard
Cc: "Aneesh Kumar K.V"
Cc: Keith Busch
Cc: li
On Fri, May 31, 2019 at 5:03 PM Michal Hocko wrote:
>
> On Thu 30-05-19 20:55:32, Pingfan Liu wrote:
> > On Wed, May 29, 2019 at 2:20 AM Michal Hocko wrote:
> > >
> > > [Sorry for a late reply]
> > >
> > > On Thu 23-05-19 11:58:45, Pingfan Li
On Sat, Jun 1, 2019 at 1:06 AM John Hubbard wrote:
>
> On 5/31/19 4:05 AM, Pingfan Liu wrote:
> > On Fri, May 31, 2019 at 7:21 AM John Hubbard wrote:
> >> On 5/30/19 2:47 PM, Ira Weiny wrote:
> >>> On Thu, May 30, 2019 at 06:54:04AM +0800, Pingfan Liu wrote:
>
On Sat, Jun 1, 2019 at 1:12 AM Ira Weiny wrote:
>
> On Fri, May 31, 2019 at 07:05:27PM +0800, Pingfan Liu wrote:
> > On Fri, May 31, 2019 at 7:21 AM John Hubbard wrote:
> > >
> > >
> > > Rather lightly tested...I've compile-tested with CONFIG_CMA and
&
On Fri, May 31, 2019 at 7:21 AM John Hubbard wrote:
>
> On 5/30/19 2:47 PM, Ira Weiny wrote:
> > On Thu, May 30, 2019 at 06:54:04AM +0800, Pingfan Liu wrote:
> [...]
> >> +for (j = i; j < nr; j++)
> >> +
On Fri, May 31, 2019 at 7:52 AM Ira Weiny wrote:
>
> On Thu, May 30, 2019 at 04:21:19PM -0700, John Hubbard wrote:
> > On 5/30/19 2:47 PM, Ira Weiny wrote:
> > > On Thu, May 30, 2019 at 06:54:04AM +0800, Pingfan Liu wrote:
> > [...]
> > >> +
On Fri, May 31, 2019 at 5:46 AM Ira Weiny wrote:
>
> On Thu, May 30, 2019 at 06:54:04AM +0800, Pingfan Liu wrote:
> > As for FOLL_LONGTERM, it is checked in the slow path
> > __gup_longterm_unlocked(). But it is not checked in the fast path, which
> > means a possible leak
KASLR: skip the specified crashkernel region" has no depend
on the "re-design the return value of parse_crashkernel()".
Thanks,
Pingfan
On Tue, May 7, 2019 at 12:32 PM Pingfan Liu wrote:
>
> crashkernel=x@y or or =range1:size1[,range2:size2,...]@offset option may
> fail t
On Wed, May 29, 2019 at 2:21 AM Michal Hocko wrote:
>
> On Thu 23-05-19 12:00:46, Pingfan Liu wrote:
> [...]
> > > Yes, but maybe it will pay great effort on it.
> > >
> > And as a first step, we can find a way to fix the bug reported by me
> > and the one
On Wed, May 29, 2019 at 2:20 AM Michal Hocko wrote:
>
> [Sorry for a late reply]
>
> On Thu 23-05-19 11:58:45, Pingfan Liu wrote:
> > On Wed, May 22, 2019 at 7:16 PM Michal Hocko wrote:
> > >
> > > On Wed 22-05-19 15:12:16, Pingfan Liu wrote:
> [..
As for FOLL_LONGTERM, it is checked in the slow path
__gup_longterm_unlocked(). But it is not checked in the fast path, which
means a possible leak of CMA page to longterm pinned requirement through
this crack.
Place a check in the fast path.
Signed-off-by: Pingfan Liu
Cc: Ira Weiny
Cc: Andrew
Matthias, ping? Any suggestions?
Thanks,
Pingfan
On Thu, May 2, 2019 at 2:22 PM Pingfan Liu wrote:
>
> On Thu, Apr 25, 2019 at 4:20 PM Pingfan Liu wrote:
> >
> > On Wed, Apr 24, 2019 at 4:31 PM Matthias Brugger wrote:
> > >
> > >
> > [...]
>
1 - 100 of 304 matches
Mail list logo
