On Thu, 15 May 2014, Madhavan Srinivasan wrote:
>
> Hi Ingo,
>
> Do you have any comments for the latest version of the patchset. If
> not, kindly can you pick it up as is.
>
>
> With regards
> Maddy
>
> > Kirill A. Shutemov with 8c6e50b029 commit introduced
> > vm_ops->map_pages() for m
On Mon, 19 May 2014, Madhavan Srinivasan wrote:
> On Monday 19 May 2014 05:42 AM, Rusty Russell wrote:
> > Hugh Dickins writes:
> >> On Thu, 15 May 2014, Madhavan Srinivasan wrote:
> >>>
> >>> Hi Ingo,
> >>>
> >>> Do you have
On Tue, 20 May 2014, Rusty Russell wrote:
> Hugh Dickins writes:
> >> On Monday 19 May 2014 05:42 AM, Rusty Russell wrote:
> >> >
> >> > Perhaps we try to generalize from two data points (a slight improvement
> >> > over doing it from 1!), eg:
&
_PAGE_PTE only on
present entries.
But if that's wrong, a reasonable alternative would be to
#define __pte_to_swp_entry(pte) ((swp_entry_t) { pte_val(pte) & ~_PAGE_PTE })
#define __swp_entry_to_pte(x) __pte((x).val | _PAGE_PTE)
Signed-off-by: Hugh Dickins
---
arch/powerpc/mm/pgtabl
it's true that swapoff
should be made more robust; but nevertheless, fix up the powerpc ifdefs
as x86_64 and s390 (which met the same problem) have them, defining the
bits as 0 if CONFIG_MEM_SOFT_DIRTY is not set.
Signed-off-by: Hugh Dickins
---
arch/powerpc/include/asm/book3s/64/h
a no-op,
whether the bit in question is defined as 0 or the asm-generic fallback
is used, unless soft dirty is fully turned on.
Why "maybe" in maybe_same_pte()? Rename it pte_same_as_swp().
Signed-off-by: Hugh Dickins
---
mm/swapfile.c | 18 --
1 file changed, 4 in
On Mon, 11 Jan 2016, Aneesh Kumar K.V wrote:
> Hugh Dickins writes:
>
> > Swapoff after swapping hangs on the G5. That's because the _PAGE_PTE
> > bit, added by set_pte_at(), is not expected by swapoff: so swap ptes
> > cannot be recognized.
> >
> >
On Mon, 11 Jan 2016, Aneesh Kumar K.V wrote:
> Hugh Dickins writes:
>
> > Swapoff after swapping hangs on the G5, when CONFIG_CHECKPOINT_RESTORE=y
> > but CONFIG_MEM_SOFT_DIRTY is not set. That's because the non-zero
> > _PAGE_SWP_SOFT_DIRTY bit, added by CONFIG_H
On Mon, 11 Jan 2016, Aneesh Kumar K.V wrote:
> "Aneesh Kumar K.V" writes:
> > Hugh Dickins writes:
> >
> >> Swapoff after swapping hangs on the G5. That's because the _PAGE_PTE
> >> bit, added by set_pte_at(), is not expected by swapoff: so swap p
On Mon, 11 Jan 2016, Aneesh Kumar K.V wrote:
> Hugh Dickins writes:
> > On Mon, 11 Jan 2016, Aneesh Kumar K.V wrote:
> >> Hugh Dickins writes:
> >>
> >> > Swapoff after swapping hangs on the G5, when CONFIG_CHECKPOINT_RESTORE=y
> >> > but CO
nction, reading from
> each used swap block into a page, then trying to find where that page
> belongs, looking at every non-file pte of every mm that ever swapped.
>
> Reported-by: Hugh Dickins
> Suggested-by: Hugh Dickins
> Signed-off-by: Aneesh Kumar K.V
I think we've see
vise() call which need to be exported
> since KVM PPC can be a kernel module.
>
> Signed-off-by: Bharata B Rao
> Acked-by: Paul Mackerras
> Cc: Andrea Arcangeli
> Cc: Hugh Dickins
I can say
Acked-by: Hugh Dickins
to this one.
But not to your 2/7 which actually make
3.2.0-rc3-next-20111202 with CONFIG_DEBUG_PREEMPT=y gives me lots of
Dec 4 20:03:19 thorn kernel: BUG: using smp_processor_id() in preemptible
[] code: startpar/1365
Dec 4 20:03:19 thorn kernel: caller is .arch_local_irq_restore+0x44/0x90
Dec 4 20:03:19 thorn kernel: Call Trace:
Dec 4
On Mon, 5 Dec 2011, Hugh Dickins wrote:
> 3.2.0-rc3-next-20111202 with CONFIG_DEBUG_PREEMPT=y gives me lots of
>
> Dec 4 20:03:19 thorn kernel: BUG: using smp_processor_id() in preemptible
> [] code: startpar/1365
> Dec 4 20:03:19 thorn kernel: caller is .arch_local_i
On Fri, 23 Dec 2011, Benjamin Herrenschmidt wrote:
> On Thu, 2011-12-22 at 04:07 -0800, Hugh Dickins wrote:
> > On Mon, 5 Dec 2011, Hugh Dickins wrote:
> >
> > > 3.2.0-rc3-next-20111202 with CONFIG_DEBUG_PREEMPT=y gives me lots of
> > >
> > >
On Sun, 15 Jan 2012, Benjamin Herrenschmidt wrote:
> On Sat, 2012-01-14 at 14:21 -0800, Hugh Dickins wrote:
> > On Fri, 23 Dec 2011, Benjamin Herrenschmidt wrote:
> > > On Thu, 2011-12-22 at 04:07 -0800, Hugh Dickins wrote:
> > > > On Mon, 5 Dec 2011, Hugh Dickins w
I have to revert the patch below from mmotm 2012-07-20-16-30 or
next-20120720 in order to boot on the PowerPC G5: otherwise it
freezes before switching to the framebuffer console - but I'm
not certain where because that initial console doesn't scroll
(there are mpic messages at bottom and at top of
On Sun, 22 Jul 2012, Benjamin Herrenschmidt wrote:
> On Sat, 2012-07-21 at 19:47 -0700, Hugh Dickins wrote:
> > I have to revert the patch below from mmotm 2012-07-20-16-30 or
> > next-20120720 in order to boot on the PowerPC G5: otherwise it
> > freezes before switching to th
On Mon, 23 Jul 2012, Benjamin Herrenschmidt wrote:
> On Sat, 2012-07-21 at 19:47 -0700, Hugh Dickins wrote:
> > I have to revert the patch below from mmotm 2012-07-20-16-30 or
> > next-20120720 in order to boot on the PowerPC G5: otherwise it
> > freezes before switching to th
On Thu, 9 Feb 2012, Benjamin Herrenschmidt wrote:
> We use __get_cpu_var() which triggers a false positive warning
> in smp_processor_id() thinking interrupts are enabled (at this
> point, they are soft-enabled but hard-disabled).
>
> Signed-off-by: Benjamin Herrenschmidt
> ---
>
> I was initial
Hi Paul,
On 3.4.0-rc4-next-20120427 and preceding linux-nexts (I've not tried
rc5-next-20120430 but expect it's the same), on PowerPC G5 quad with
CONFIG_PREEMPT=y and CONFIG_DEBUG_ATOMIC_SLEEP=y, I'm getting spurious
"BUG: sleeping function called from invalid context" messages from
__might_sleep
On Tue, 1 May 2012, Benjamin Herrenschmidt wrote:
> On Mon, 2012-04-30 at 15:37 -0700, Hugh Dickins wrote:
> >
> > BUG: sleeping function called from invalid context at
> > include/linux/pagemap.h:354
> > in_atomic(): 0, irqs_disabled(): 0, pid: 6886, name: cc1
On Tue, 1 May 2012, Paul E. McKenney wrote:
> On Mon, Apr 30, 2012 at 10:10:06PM -0700, Hugh Dickins wrote:
> > On Tue, 1 May 2012, Benjamin Herrenschmidt wrote:
> > > On Mon, 2012-04-30 at 15:37 -0700, Hugh Dickins wrote:
> > > >
> > > > BUG: sleepi
On Tue, 1 May 2012, Paul E. McKenney wrote:
> > > > > On Mon, 2012-04-30 at 15:37 -0700, Hugh Dickins wrote:
> > > > > >
> > > > > > BUG: sleeping function called from invalid context at
> > > > > > include/linux/pagemap.h:354
On Wed, May 2, 2012 at 2:54 PM, Paul E. McKenney
wrote:
> On Thu, May 03, 2012 at 07:20:15AM +1000, Benjamin Herrenschmidt wrote:
>> On Wed, 2012-05-02 at 13:25 -0700, Hugh Dickins wrote:
>> > Got it at last. Embarrassingly obvious. __rcu_read_lock() and
>> > __rcu_re
On Wed, 2 May 2012, Paul E. McKenney wrote:
> On Wed, May 02, 2012 at 03:54:24PM -0700, Hugh Dickins wrote:
> > On Wed, May 2, 2012 at 2:54 PM, Paul E. McKenney
> > wrote:
> > > On Thu, May 03, 2012 at 07:20:15AM +1000, Benjamin Herrenschmidt wrote:
> > >> On
Hi Ben,
3.4.0-rc5-next-20120504 and 3.4.0-rc6-next-20120507
crash while booting the PowerMac G5: I have to revert
your commit e326b30fda9985a2e7fda6fb9212b86bf025c39
powerpc/pmac: Convert windfarm_smu_sat to new i2c probing
to get a working system.
Actual oops message scrolled off screen, and I d
On Wed, 2 May 2012, Hugh Dickins wrote:
> On Wed, 2 May 2012, Paul E. McKenney wrote:
> >
> > In any case, I must confess that I feel quite silly about my series
> > of patches. I have reverted them aside from a couple that did useful
> > optimizations, and they shou
On Mon, 7 May 2012, Paul E. McKenney wrote:
> On Mon, May 07, 2012 at 09:21:54AM -0700, Hugh Dickins wrote:
> >
> > In 70 hours I got six isolated messages like the below (but from
> > different __might_sleep callsites) - where before I'd have flurries
> > of h
On Tue, 8 May 2012, Benjamin Herrenschmidt wrote:
> On Mon, 2012-05-07 at 08:57 -0700, Hugh Dickins wrote:
> > Hi Ben,
> >
> > 3.4.0-rc5-next-20120504 and 3.4.0-rc6-next-20120507
> > crash while booting the PowerMac G5: I have to revert
> > your commit e326b3
With recent 2.6.37-rc, with CONFIG_PREEMPT=y CONFIG_DEBUG_PREEMPT=y
on the PowerPC G5, I get spammed by BUG warnings each time I swapoff:
BUG: using smp_processor_id() in preemptible [] code: swapoff/3974
caller is .hpte_need_flush+0x4c/0x2e8
Call Trace:
[c001b4a3f830] [c000f3c
On Thu, 30 Dec 2010, Benjamin Herrenschmidt wrote:
> On Wed, 2010-12-29 at 14:54 -0800, Hugh Dickins wrote:
> > With recent 2.6.37-rc, with CONFIG_PREEMPT=y CONFIG_DEBUG_PREEMPT=y
> > on the PowerPC G5, I get spammed by BUG warnings each time I swapoff:
> >
> > BUG:
Hi Grant,
I've been unable to boot mmotm on the G5 for a few weeks; and now that
the problem has reached Linus, I've bisected and it converges on your:
commit b5d937de0367d26f65b9af1aef5f2c34c1939be0
powerpc/pci: Make both ppc32 and ppc64 use sysdata for pci_controller
Currently, ppc3
Hi Ben,
As I warned a few weeks ago, Jeremy has vmalloc apply_to_pte_range
patches in mmotm, which again assault PowerPC's expectations, and
cause lots of noise with CONFIG_PREEMPT=y CONFIG_PREEMPT_DEBUG=y.
This time in vmalloc as well as vfree; and Peter's fix to the last
lot, which went into 2.
On Mon, 21 Mar 2011, Benjamin Herrenschmidt wrote:
> On Sat, 2011-03-19 at 21:11 -0700, Hugh Dickins wrote:
> >
> > As I warned a few weeks ago, Jeremy has vmalloc apply_to_pte_range
> > patches in mmotm, which again assault PowerPC's expectations, and
> > cause l
On Mon, 21 Mar 2011, Benjamin Herrenschmidt wrote:
>
> As long as the races to avoid are between map/unmap vs. access, yes, it
> -should- be fine, and we used to not do demand faulting on kernel space
> (but for how long ?). I'm wondering why we don't just stick a ptl in
> there or is there a good
On Sat, 31 Oct 2009, Benjamin Herrenschmidt wrote:
> Hi folks !
>
> So I have a little problem on powerpc ... :-)
Thanks a lot for running this by us.
>
> Due to the way I'm attempting to do my I$/D$ coherency on embedded
> processors, I basically need to "filter out" _PAGE_EXEC in set_pte_at(
On Tue, 3 Nov 2009, Benjamin Herrenschmidt wrote:
> On Mon, 2009-11-02 at 13:27 +0000, Hugh Dickins wrote:
>
> > You're being a very good citizen to want to bring this so forcefully
> > to the attention of any user of set_pte_at(); but given how few care,
> > and t
On Thu, 2 Apr 2009, Michael Ellerman wrote:
> On Wed, 2009-04-01 at 17:18 -0600, Chris Friesen wrote:
> > Resending due to lack of response to original post.
>
> Hi Chris,
>
> You'll probably get a more useful response on lkml. You CC'ed
> linux-kernel-owner originally :)
Thanks.
>
> > I was v
On Thu, 2 Apr 2009, Chris Friesen wrote:
> Hugh Dickins wrote:
> > > > f7feb000-f7fec000 rw-p f7feb000 00:00 0
> > > > ffe6d000-ffe82000 rw-p ffeb000 00:00 0 [stack]
>
> > Chris isn't the first to be concerned by that: there's a patch
On Thu, 2 Apr 2009, Chris Friesen wrote:
> Hugh Dickins wrote:
>
> > This is a cosmetic matter, not worth more than a couple of lines of
> > code: I suggested masking off the high bits in the display, but when
> > KAMEZAWA-san suggested just showing 0, it was hard to argu
Now that shmem's divisions by zero and SHMEM_MAX_BYTES are fixed,
let powerpc 256kB pages coexist with CONFIG_SHMEM again.
Signed-off-by: Hugh Dickins
---
Added linuxppc-dev and some other Cc's for this 3/3: sorry
if you didn't see 1/3 and 2/3, they were just in mm/shmem.c.
On Tue, 7 Apr 2009, Paul Mackerras wrote:
> Hugh Dickins writes:
>
> > Now that shmem's divisions by zero and SHMEM_MAX_BYTES are fixed,
> > let powerpc 256kB pages coexist with CONFIG_SHMEM again.
> >
> > Signed-off-by: Hugh Dickins
> > ---
> > Ad
On Thu, 9 Apr 2009, Andrew Morton wrote:
> On Mon, 6 Apr 2009 22:01:15 +0100 (BST)
> Hugh Dickins wrote:
>
> > Now that shmem's divisions by zero and SHMEM_MAX_BYTES are fixed,
> > let powerpc 256kB pages coexist with CONFIG_SHMEM again.
> >
> > Signed-o
et_namespace: 2000 bytes
> >
> > Complete dmesg attached. Let me know if you need any other info. I will
> > try yesterday's next
> > tree to check if this problem can be recreated.
>
> Almost certainly commit 874a9e18f25c86dbc199ad32ddd9ca44d25290e8
> ("
On Thu, Apr 14, 2011 at 2:02 AM, Michel Dänzer wrote:
> On Mit, 2011-04-13 at 18:43 -0500, kevin diggs wrote:
>>
>> On Wed, Apr 13, 2011 at 6:21 PM, Benjamin Herrenschmidt
>> wrote:
>> > On Wed, 2011-04-13 at 12:52 -0500, kevin diggs wrote:
>> >> > Actually I do get a crash in X later on... somet
On Thu, Apr 14, 2011 at 2:54 PM, Benjamin Herrenschmidt
wrote:
> On Thu, 2011-04-14 at 14:25 -0700, Hugh Dickins wrote:
>>
>> Something worth trying: turn off CONFIG_IDE. That's what I need to
>> boot 2.6.39-rc[1-3] on PowerPC G5.
>>
>> I know Jens has be
On Sun, Apr 17, 2011 at 12:00 AM, Jens Axboe wrote:
> On 2011-04-17 05:16, Hugh Dickins wrote:
>> On Thu, Apr 14, 2011 at 2:54 PM, Benjamin Herrenschmidt
>> wrote:
>>> On Thu, 2011-04-14 at 14:25 -0700, Hugh Dickins wrote:
>>>>
>>>> Something w
&pcp1) % (2 * sizeof(pcp1)));
on line 268 of the morass that is include/linux/percpu.h)
I tried the following alignment patch and found it to work.
Signed-off-by: Hugh Dickins
---
include/linux/slub_def.h |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- 3.0-rc2/include/linux/slub_d
On Mon, Jun 13, 2011 at 1:34 PM, Pekka Enberg wrote:
> On Mon, Jun 13, 2011 at 10:29 PM, Christoph Lameter wrote:
>> On Mon, 13 Jun 2011, Pekka Enberg wrote:
>>
>>> > Hmmm.. The allocpercpu in alloc_kmem_cache_cpus should take care of the
>>> > alignment. Uhh.. I see that a patch that removes the
On Tue, 14 Jun 2011, Benjamin Herrenschmidt wrote:
> On Mon, 2011-06-13 at 14:00 -0700, Hugh Dickins wrote:
> > On Mon, Jun 13, 2011 at 1:34 PM, Pekka Enberg wrote:
> > > On Mon, Jun 13, 2011 at 10:29 PM, Christoph Lameter
> > > wrote:
> > >>
On Wed, 28 Jun 2023, Gerald Schaefer wrote:
>
> As discussed in the other thread, we would rather go with less complexity,
> possibly switching to an approach w/o the list and fragment re-use in the
> future. For now, as a first step in that direction, we can try with not
> adding fragments back o
On Thu, 29 Jun 2023, Gerald Schaefer wrote:
> On Thu, 29 Jun 2023 12:22:24 -0300
> Jason Gunthorpe wrote:
> > On Wed, Jun 28, 2023 at 10:08:08PM -0700, Hugh Dickins wrote:
> > > On Wed, 28 Jun 2023, Gerald Schaefer wrote:
> > > >
> > > > As disc
On Fri, 30 Jun 2023, Claudio Imbrenda wrote:
> On Tue, 20 Jun 2023 00:51:19 -0700 (PDT)
> Hugh Dickins wrote:
>
> [...]
>
> > +void pte_free_defer(struct mm_struct *mm, pgtable_t pgtable)
> > +{
> > + unsigned int bit, mask;
> > + struct page *page;
&g
On Fri, 30 Jun 2023, Claudio Imbrenda wrote:
> On Fri, 30 Jun 2023 08:28:54 -0700 (PDT)
> Hugh Dickins wrote:
> > On Fri, 30 Jun 2023, Claudio Imbrenda wrote:
> > > On Tue, 20 Jun 2023 00:51:19 -0700 (PDT)
> > > Hugh Dickins wrote:
> > >
> > > [.
On Thu, 29 Jun 2023, Hugh Dickins wrote:
>
> I've grown to dislike the (ab)use of pt_frag_refcount even more, to the
> extent that I've not even tried to verify it; but I think I do get the
> point now, that we need further info than just PPHHAA to know whether
> the p
On Tue, 4 Jul 2023, Alexander Gordeev wrote:
> On Sat, Jul 01, 2023 at 09:32:38PM -0700, Hugh Dickins wrote:
> > On Thu, 29 Jun 2023, Hugh Dickins wrote:
>
> Hi Hugh,
>
> ...
> > No, not quite the same rules as before: I came to realize that using
> > list_add
On Tue, 4 Jul 2023, Gerald Schaefer wrote:
> On Sat, 1 Jul 2023 21:32:38 -0700 (PDT)
> Hugh Dickins wrote:
> > On Thu, 29 Jun 2023, Hugh Dickins wrote:
> > >
> > > I've grown to dislike the (ab)use of pt_frag_refcount even more, to the
> > > extent
On Wed, 5 Jul 2023, Alexander Gordeev wrote:
> On Sat, Jul 01, 2023 at 09:32:38PM -0700, Hugh Dickins wrote:
> > On Thu, 29 Jun 2023, Hugh Dickins wrote:
>
> Hi Hugh,
>
> ...
>
> > +#ifdef CONFIG_TRANSPARENT_HUGEPAGE
> > +void pte_free_defer(str
On Wed, 5 Jul 2023, Gerald Schaefer wrote:
> On Tue, 4 Jul 2023 10:03:57 -0700 (PDT)
> Hugh Dickins wrote:
> > On Tue, 4 Jul 2023, Gerald Schaefer wrote:
> > > On Sat, 1 Jul 2023 21:32:38 -0700 (PDT)
> > > Hugh Dickins wrote:
> > > &g
x13c/0x520
> get_arg_page+0x80/0x1d0
> copy_string_kernel+0xc8/0x250
> kernel_execve+0x11c/0x270
> run_init_process+0xe4/0x10c
> kernel_init+0xbc/0x1a0
> ret_from_kernel_user_thread+0x14/0x1c
>
> Cc: Hugh Dickins
> Reported-by: Michael Ellerman
> Signed-off-by:
On Thu, 6 Jul 2023, Gerald Schaefer wrote:
>
> Since none of my remarks on the comments seem valid or strictly necessary
> any more, and I also could not find functional issues, I think you can add
> this patch as new version for 07/12. And I can now give you this:
>
> Reviewed-by: Gerald Schaefe
("mm: lock newly mapped VMA which can be modified after it
becomes visible")
Cc: sta...@vger.kernel.org
Signed-off-by: Hugh Dickins
---
mm/mmap.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/mm/mmap.c b/mm/mmap.c
index 84c71431a527..3eda23c9ebe7 100644
---
Here is v3 of the series of patches to mm (and a few architectures), based
on v6.5-rc1 which includes the preceding two series (thank you!): in which
khugepaged takes advantage of pte_offset_map[_lock]() allowing for pmd
transitions. Differences from v1 and v2 are noted patch by patch below.
This
-by: Hugh Dickins
---
include/linux/pgtable.h | 4 ++--
mm/pgtable-generic.c| 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/include/linux/pgtable.h b/include/linux/pgtable.h
index 5063b482e34f..5134edcec668 100644
--- a/include/linux/pgtable.h
+++ b/include/linux
ssumptions).
Signed-off-by: Hugh Dickins
---
include/linux/pgtable.h | 4
mm/pgtable-generic.c| 29 +
2 files changed, 33 insertions(+)
diff --git a/include/linux/pgtable.h b/include/linux/pgtable.h
index 5134edcec668..7f2db400f653 100644
--- a/include/linux
-by: Hugh Dickins
---
arch/arm/mm/fault-armv.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/arch/arm/mm/fault-armv.c b/arch/arm/mm/fault-armv.c
index ca5302b0b7ee..7cb125497976 100644
--- a/arch/arm/mm/fault-armv.c
+++ b/arch/arm/mm/fault-armv.c
@@ -117,11 +117,10 @@ static
know, if an assert_pte_locked() caller can be racing such transitions?
This mod might cause new crashes: which either expose my ignorance, or
indicate issues to be fixed, or limit the usage of assert_pte_locked().
Signed-off-by: Hugh Dickins
---
arch/powerpc/mm/pgtable.c | 16 ++
lling pte_fragment_free() directly; and there call_rcu() to
pte_free_now() when last fragment is freed and the page is PageActive.
Suggested-by: Jason Gunthorpe
Signed-off-by: Hugh Dickins
---
arch/powerpc/include/asm/pgalloc.h | 4
arch/powerpc/mm/pgtable-frag.c
ble_t.
sparc32 supports pagetables sharing a page, but does not support THP;
sparc64 supports THP, but does not support pagetables sharing a page.
So the sparc-specific pte_free_defer() is as simple as the generic one,
except for converting between pte_t *pgtable_t and struct page *.
Signed-off-by:
_tlb_remove_table(), where we might not have a stable mm any more.
Signed-off-by: Hugh Dickins
Reviewed-by: Gerald Schaefer
---
arch/s390/include/asm/pgalloc.h | 4 ++
arch/s390/mm/pgalloc.c | 80 +--
2 files changed, 72 insertions(+), 12 deletions(-)
diff
table (none of whose pte_free()s use the mm arg which was passed to it).
Signed-off-by: Hugh Dickins
---
include/linux/mm_types.h | 4
include/linux/pgtable.h | 2 ++
mm/pgtable-generic.c | 20
3 files changed, 26 insertions(+)
diff --git a/include/linux/mm_type
nhanced to replace_page_tables(), which
inserts the final huge pmd without mmap lock: going through an invalid
state instead of pmd_none() followed by fault. But that enhancement
does raise some more questions: leave it until a later release.
Signed-off-by: Hugh Dickins
---
mm/khugepag
". But with those
entries now cleared, "step 4" (after dropping ptl to do pmd_lock) is kept
safe by the huge page lock, which stops new PTEs from being faulted in.
Signed-off-by: Hugh Dickins
---
mm/khugepaged.c | 172 ++
1 file
recollapsed. Call collapse_pte_mapped_thp()
directly in this case (why was it deferred before? I assume an issue
with needing mmap_lock for write, but now it's only needed for read).
Signed-off-by: Hugh Dickins
---
mm/khugepaged.c | 125 +++---
1 file ch
mmap_write_trylock() and vma_try_start_write() were added just for
khugepaged, but now it has no use for them: delete.
Signed-off-by: Hugh Dickins
---
include/linux/mm.h| 17 -
include/linux/mmap_lock.h | 10 --
2 files changed, 27 deletions(-)
diff --git a
Add a block of comments on pte_offset_map_lock(), pte_offset_map() and
pte_offset_map_nolock() to mm/pgtable-generic.c, to help explain them.
Signed-off-by: Hugh Dickins
---
mm/pgtable-generic.c | 44
1 file changed, 44 insertions(+)
diff --git a/mm
mmap_write_trylock() and vma_try_start_write() were added just for
khugepaged, but now it has no use for them: delete.
Signed-off-by: Hugh Dickins
---
This is the version which applies to mm-unstable or linux-next.
include/linux/mm.h| 17 -
include/linux/mmap_lock.h
On Tue, 18 Jul 2023, Aneesh Kumar K.V wrote:
> Hugh Dickins writes:
>
> > Instead of pte_lockptr(), use the recently added pte_offset_map_nolock()
> > in assert_pte_locked(). BUG if pte_offset_map_nolock() fails: this is
> > stricter than the previous implementation, whi
assert_pte_locked(). BUG if pte_offset_map_nolock() fails.
Signed-off-by: Hugh Dickins
---
arch/powerpc/mm/pgtable.c | 8
1 file changed, 8 insertions(+)
diff --git a/arch/powerpc/mm/pgtable.c b/arch/powerpc/mm/pgtable.c
index 16b061af86d7..a3dcdb2d5b4b 100644
--- a/arch/powerpc/mm/pgtable.c
Claudio finds warning on mm_has_pgste() more useful than on mm_alloc_pgste().
Signed-off-by: Hugh Dickins
---
arch/s390/mm/pgalloc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/s390/mm/pgalloc.c b/arch/s390/mm/pgalloc.c
index 760b4ace475e..d7374add7820 100644
--- a
ler.appspotmail.com
Closes:
https://lore.kernel.org/linux-mm/e4b0f0060123c...@google.com/
Signed-off-by: Hugh Dickins
---
mm/khugepaged.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/mm/khugepaged.c b/mm/khugepaged.c
index 6bad69c0e4bd..1c773db26e88 100644
--- a/mm/khugepaged.
Though not yet detected by syzbot, this commit was making the same
mistake with mmap_locked as the previous commit: fix that.
Signed-off-by: Hugh Dickins
---
mm/khugepaged.c | 8 +++-
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/mm/khugepaged.c b/mm/khugepaged.c
index
On Mon, 24 Jul 2023, Vishal Moola (Oracle) wrote:
> The MM subsystem is trying to shrink struct page. This patchset
> introduces a memory descriptor for page table tracking - struct ptdesc.
>
> This patchset introduces ptdesc, splits ptdesc from struct page, and
> converts many callers of page ta
On Thu, 3 Aug 2023, Qi Zheng wrote:
> On 2023/7/12 12:42, Hugh Dickins wrote:
> > Bring collapse_and_free_pmd() back into collapse_pte_mapped_thp().
> > It does need mmap_read_lock(), but it does not need mmap_write_lock(),
> > nor vma_start_write() nor i_mmap lock nor anon_
Use ptep_clear() instead of pte_clear(): when CONFIG_PAGE_TABLE_CHECK=y,
ptep_clear() adds some accounting, missing which would cause a BUG later.
Signed-off-by: Hugh Dickins
Reported-by: Qi Zheng
Closes:
https://lore.kernel.org/linux-mm/0df84f9f-e9b0-80b1-4c9e-95abc1a73...@bytedance.com
On Mon, 14 Aug 2023, Jann Horn wrote:
> On Wed, Jul 12, 2023 at 6:42 AM Hugh Dickins wrote:
> > Bring collapse_and_free_pmd() back into collapse_pte_mapped_thp().
> > It does need mmap_read_lock(), but it does not need mmap_write_lock(),
> > nor vma_start_write() nor i_mmap l
On Tue, 15 Aug 2023, David Hildenbrand wrote:
> On 15.08.23 08:34, Hugh Dickins wrote:
> > On Mon, 14 Aug 2023, Jann Horn wrote:
> >>
> >> /* step 4: remove page table */
> >> + if (strcmp(current->comm, "DELAYME") == 0) {
> >
On Mon, 14 Aug 2023, Jann Horn wrote:
> On Wed, Jul 12, 2023 at 6:42 AM Hugh Dickins wrote:
> > Bring collapse_and_free_pmd() back into collapse_pte_mapped_thp().
> > It does need mmap_read_lock(), but it does not need mmap_write_lock(),
> > nor vma_start_write() nor i_mmap l
z0FxiRC4d3VTu_a9h=rg5fw-kyd5rg5xo_rdbm0ltt...@mail.gmail.com/
Fixes: 1043173eb5eb ("mm/khugepaged: collapse_pte_mapped_thp() with
mmap_read_lock()")
Signed-off-by: Hugh Dickins
---
mm/khugepaged.c | 38 +-
1 file changed, 29 insertions(+), 9 deletions(-)
On Mon, 21 Aug 2023, Jann Horn wrote:
> On Mon, Aug 21, 2023 at 9:51 PM Hugh Dickins wrote:
> > Jann Horn demonstrated how userfaultfd ioctl UFFDIO_COPY into a private
> > shmem mapping can add valid PTEs to page table collapse_pte_mapped_thp()
> > thought it had emptied:
On Tue, 22 Aug 2023, Jann Horn wrote:
> On Tue, Aug 22, 2023 at 4:51 AM Hugh Dickins wrote:
> > On Mon, 21 Aug 2023, Jann Horn wrote:
> > > On Mon, Aug 21, 2023 at 9:51 PM Hugh Dickins wrote:
> > > > Just for this case, take the pmd_lock() two steps earlier: no
On Tue, 22 Aug 2023, Matthew Wilcox wrote:
> On Tue, Aug 22, 2023 at 11:34:19AM -0700, Hugh Dickins wrote:
> > (Yes, the locking is a bit confusing: but mainly for the unrelated reason,
> > that with the split locking configs, we never quite know whether this lock
> > is the
Here is a series of patches to various architectures, based on v6.4-rc1:
preparing for changes expected to follow in mm, affecting pte_offset_map()
and pte_offset_map_lock().
In a week or two, I intend to post a separate series, of equivalent
preparations in mm. These two series are "independent"
In rare transient cases, not yet made possible, pte_offset_map() and
pte_offset_map_lock() may not find a page table: handle appropriately.
Signed-off-by: Hugh Dickins
---
arch/arm/lib/uaccess_with_memcpy.c | 3 +++
arch/arm/mm/fault-armv.c | 5 -
arch/arm/mm/fault.c
In rare transient cases, not yet made possible, pte_offset_map() and
pte_offset_map_lock() may not find a page table: handle appropriately.
Signed-off-by: Hugh Dickins
---
arch/arm64/mm/fault.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/arm64/mm/fault.c b/arch/arm64/mm/fault.c
pte_alloc_map() expects to be followed by pte_unmap(), but hugetlb omits
that: to keep balance in future, use the recently added pte_alloc_huge()
instead; with pte_offset_huge() a better name for pte_offset_kernel().
Signed-off-by: Hugh Dickins
---
arch/arm64/mm/hugetlbpage.c | 11
pte_alloc_map() expects to be followed by pte_unmap(), but hugetlb omits
that: to keep balance in future, use the recently added pte_alloc_huge()
instead; with pte_offset_huge() a better name for pte_offset_kernel().
Signed-off-by: Hugh Dickins
---
arch/ia64/mm/hugetlbpage.c | 4 ++--
1 file
In rare transient cases, not yet made possible, pte_offset_map() and
pte_offset_map_lock() may not find a page table: handle appropriately.
Restructure cf_tlb_miss() with a pte_unmap() (previously omitted)
at label out, followed by one local_irq_restore() for all.
Signed-off-by: Hugh Dickins
In rare transient cases, not yet made possible, pte_offset_map() and
pte_offset_map_lock() may not find a page table: handle appropriately.
Signed-off-by: Hugh Dickins
---
arch/microblaze/kernel/signal.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/arch/microblaze
1 - 100 of 235 matches
Mail list logo
