gt;
> Signed-off-by: Suren Baghdasaryan
Acked-by: Michal Hocko
> ---
> mm/debug.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/mm/debug.c b/mm/debug.c
> index 9d3d893dc7f4..96d594e16292 100644
> --- a/mm/debug.c
> +++ b/mm/debug.c
> @@ -215,6
On Wed 25-01-23 08:57:48, Suren Baghdasaryan wrote:
> On Wed, Jan 25, 2023 at 1:38 AM 'Michal Hocko' via kernel-team
> wrote:
> >
> > On Wed 25-01-23 00:38:49, Suren Baghdasaryan wrote:
> > > Replace indirect modifications to vma->vm_flags with calls t
ut it would introduce a huge additional
> churn (800+ hits) with no obvious benefits, I think. Does that clarify
> the intent of this trick?
I think that makes sense at this stage. The conversion patch is quite
large already. Maybe the final renaming could be done on top of
everything and patch generated by coccinele. The const union is a neat
trick but a potential lockdep assert is a nice plus as well. I wouldn't
see it as a top priority though.
--
Michal Hocko
SUSE Labs
on that much even in the core kernel - e.g. init_rwsem vs. mutex_init)
Acked-by: Michal Hocko
> ---
> include/linux/mm.h | 37 +
> include/linux/mm_types.h | 10 +-
> 2 files changed, 46 insertions(+), 1 deletion(-)
>
> diff
ch situation, when VMA is
> not part of VMA tree and locking it is not required.
> Pass a hint to untrack_pfn to conditionally use mod_vm_flags_nolock for
> flags modification and to avoid assertion.
>
> Signed-off-by: Suren Baghdasaryan
Acked-by: Michal Hocko
Thanks!
> ---
>
git blame would be more visible
when the conversion is from WRITE_ONCE.
One way or the other
Acked-by: Michal Hocko
> ---
> Notes:
> - The patch applies cleanly over mm-unstable
> - The SHA in Fixes: line is from mm-unstable, so is... unstable
>
> include/linux/mm.h | 7 +++
>
, kernel_page_present() used
> along PG_reserved in hibernation code will always return "true"
> on powerpc, resulting in the pages getting touched. It's too
> generic - e.g., indicates boot allocations.
>
> Note 3: For now, we keep using memory_block
e_single rather than adding a new
wrapper but nothing really critical.
> Also, change madvise_dontneed_single_vma to use this new routine.
>
> [1]
> https://lore.kernel.org/linux-mm/20221114235507.294320-2-mike.krav...@oracle.com/
> Suggested-by: Peter Xu
> Signed-off-by: Mike Kr
ngle().
> - Remove zap_page_range.
>
> [1]
> https://lore.kernel.org/linux-mm/20221114235507.294320-2-mike.krav...@oracle.com/
> Suggested-by: Peter Xu
> Signed-off-by: Mike Kravetz
This looks even better than the previous version.
Acked-by: Michal Hocko
minor nit
[...]
>
a real problem? Sure there might be a lot of
those but your patch increases it by rwsem (without the last patch)
which is something like 40B on top of 136B vma so we are talking about
400B in total which even with wild mapcount limits shouldn't really be
prohibitive. With a default map count
at this stage.
--
Michal Hocko
SUSE Labs
On Wed 11-01-23 09:04:41, Suren Baghdasaryan wrote:
> On Wed, Jan 11, 2023 at 8:44 AM Michal Hocko wrote:
> >
> > On Wed 11-01-23 08:28:49, Suren Baghdasaryan wrote:
> > [...]
> > > Anyhow. Sounds like the overhead of the current design is small enough
> > >
On Wed 11-01-23 09:49:08, Suren Baghdasaryan wrote:
> On Wed, Jan 11, 2023 at 9:37 AM Michal Hocko wrote:
> >
> > On Wed 11-01-23 09:04:41, Suren Baghdasaryan wrote:
> > > On Wed, Jan 11, 2023 at 8:44 AM Michal Hocko wrote:
> > > >
> > > > On
chep, vma);
> +#endif
Is it safe to have vma with already freed vma_name? I suspect this is
safe because of mmap_lock but is there any reason to split the freeing
process and have this potential UAF lurking?
> }
>
> static void account_kernel_stack(struct task_struct *tsk, int accoun
t; struct task_struct *p,
> seqcount_init(&mm->write_protect_seq);
> mmap_init_lock(mm);
> INIT_LIST_HEAD(&mm->mmlist);
> +#ifdef CONFIG_PER_VMA_LOCK
> + WRITE_ONCE(mm->mm_lock_seq, 0);
> +#endif
> mm_pgtables_bytes_init(mm);
> mm->map_count = 0;
> mm->locked_vm = 0;
> diff --git a/mm/init-mm.c b/mm/init-mm.c
> index c9327abb771c..33269314e060 100644
> --- a/mm/init-mm.c
> +++ b/mm/init-mm.c
> @@ -37,6 +37,9 @@ struct mm_struct init_mm = {
> .page_table_lock = __SPIN_LOCK_UNLOCKED(init_mm.page_table_lock),
> .arg_lock = __SPIN_LOCK_UNLOCKED(init_mm.arg_lock),
> .mmlist = LIST_HEAD_INIT(init_mm.mmlist),
> +#ifdef CONFIG_PER_VMA_LOCK
> + .mm_lock_seq= 0,
> +#endif
> .user_ns= &init_user_ns,
> .cpu_bitmap = CPU_BITS_NONE,
> #ifdef CONFIG_IOMMU_SVA
> --
> 2.39.0
--
Michal Hocko
SUSE Labs
m_struct *mm_init(struct mm_struct *mm,
> struct task_struct *p,
> seqcount_init(&mm->write_protect_seq);
> mmap_init_lock(mm);
> INIT_LIST_HEAD(&mm->mmlist);
> +#ifdef CONFIG_PER_VMA_LOCK
> + WRITE_ONCE(mm->mm_lock_seq, 0);
> +#endif
The mm shouldn't be visible so why WRITE_ONCE?
--
Michal Hocko
SUSE Labs
unsigned long set, unsigned long clear)
> +{
> + vma_write_lock(vma);
> + vma->vm_flags |= set;
> + vma->vm_flags &= ~clear;
> +}
> +
This is rather unusual pattern. There is no note about locking involved
in the naming and also why is the locking part of this interface in the
first place? I can see reason for access functions to actually check for
lock asserts.
--
Michal Hocko
SUSE Labs
On Tue 17-01-23 16:04:26, Michal Hocko wrote:
> On Mon 09-01-23 12:53:07, Suren Baghdasaryan wrote:
> > Introduce a per-VMA rw_semaphore to be used during page fault handling
> > instead of mmap_lock. Because there are cases when multiple VMAs need
> > to be exclusively l
On Tue 17-01-23 16:09:03, Michal Hocko wrote:
> On Mon 09-01-23 12:53:08, Suren Baghdasaryan wrote:
> > To keep vma locking correctness when vm_flags are modified, add modifier
> > functions to be used whenever flags are updated.
> >
> > Signed-off-by: Suren Baghdas
On Mon 09-01-23 12:53:12, Suren Baghdasaryan wrote:
> Move VMA flag modification (which now implies VMA locking) before
> anon_vma_lock_write to match the locking order of page fault handler.
Does this changelog assumes per vma locking in the #PF?
--
Michal Hocko
SUSE Labs
#PF handling and THP collapsing need to be mutually
exclusive currently so in order to keep that assumption you have mark
the vma write locked?
Also it is not really clear to me how that handles other vmas which can
share the same thp?
--
Michal Hocko
SUSE Labs
q != READ_ONCE(vma->vm_mm->mm_lock_seq),
> + vma);
Do we really need to check for vm_lock_seq? rwsem_is_locked should tell
us something is wrong on its own, no? This could be somebody racing with
the vma destruction and using the write lock. Unlikely but I do not see
why to narrow debugging scope.
--
Michal Hocko
SUSE Labs
vma = validate;
> + goto retry;
> + }
> +
> + rcu_read_unlock();
> + return vma;
> +inval:
> + rcu_read_unlock();
> + count_vm_vma_lock_event(VMA_LOCK_ABORT);
> + return NULL;
> +}
> +#endif /* CONFIG_PER_VMA_LOCK */
> +
> #ifndef __PAGETABLE_P4D_FOLDED
> /*
> * Allocate p4d page table.
> --
> 2.39.0
--
Michal Hocko
SUSE Labs
, place VMAs into
> a list and free them in groups using one call_rcu() call per group.
Please add some data to justify this additional complexity.
--
Michal Hocko
SUSE Labs
ble and based on actual real life
numbers. This whole thing is quite big enough that we do not have to go
through "is this new synchronization primitive correct and behaving
reasonably" exercise.
--
Michal Hocko
SUSE Labs
On Tue 17-01-23 21:54:58, Matthew Wilcox wrote:
> On Tue, Jan 17, 2023 at 01:21:47PM -0800, Suren Baghdasaryan wrote:
> > On Tue, Jan 17, 2023 at 7:12 AM Michal Hocko wrote:
> > >
> > > On Tue 17-01-23 16:04:26, Michal Hocko wrote:
> > > > On Mon 09-0
On Tue 17-01-23 18:01:01, Suren Baghdasaryan wrote:
> On Tue, Jan 17, 2023 at 7:16 AM Michal Hocko wrote:
> >
> > On Mon 09-01-23 12:53:12, Suren Baghdasaryan wrote:
> > > Move VMA flag modification (which now implies VMA locking) before
> > > anon_vma_lock_wr
On Tue 17-01-23 21:28:06, Jann Horn wrote:
> On Tue, Jan 17, 2023 at 4:25 PM Michal Hocko wrote:
> > On Mon 09-01-23 12:53:13, Suren Baghdasaryan wrote:
> > > Protect VMA from concurrent page fault handler while collapsing a huge
> > > page. Page fault handler needs
On Tue 17-01-23 17:53:00, Suren Baghdasaryan wrote:
> On Tue, Jan 17, 2023 at 7:42 AM 'Michal Hocko' via kernel-team
> wrote:
> >
> > On Mon 09-01-23 12:53:21, Suren Baghdasaryan wrote:
> > > Assert there are no holders of VMA lock for reading w
On Tue 17-01-23 17:19:46, Suren Baghdasaryan wrote:
> On Tue, Jan 17, 2023 at 7:57 AM Michal Hocko wrote:
> >
> > On Mon 09-01-23 12:53:34, Suren Baghdasaryan wrote:
> > > call_rcu() can take a long time when callback offloading is enabled.
> > > Its use in the v
t vm_area_free is guaranteed to sync up with ongoing readers.
vma manipulation functions like __adjust_vma make my head spin. Would it
make more sense to have a rcu style synchronization point in
vm_area_free directly before call_rcu? This would add an overhead of
uncontended down_write of course.
--
Michal Hocko
SUSE Labs
On Wed 18-01-23 14:23:32, Jann Horn wrote:
> On Wed, Jan 18, 2023 at 1:28 PM Michal Hocko wrote:
> > On Tue 17-01-23 19:02:55, Jann Horn wrote:
> > > +locking maintainers
> > >
> > > On Mon, Jan 9, 2023 at 9:54 PM Suren Baghdasaryan
> > > wrote:
&
On Wed 18-01-23 09:36:44, Suren Baghdasaryan wrote:
> On Wed, Jan 18, 2023 at 7:11 AM 'Michal Hocko' via kernel-team
> wrote:
> >
> > On Wed 18-01-23 14:23:32, Jann Horn wrote:
> > > On Wed, Jan 18, 2023 at 1:28 PM Michal Hocko wrote:
> > &g
On Wed 18-01-23 10:09:29, Suren Baghdasaryan wrote:
> On Wed, Jan 18, 2023 at 1:23 AM Michal Hocko wrote:
> >
> > On Tue 17-01-23 18:01:01, Suren Baghdasaryan wrote:
> > > On Tue, Jan 17, 2023 at 7:16 AM Michal Hocko wrote:
> > > >
> > > > On
On Wed 18-01-23 13:48:13, Suren Baghdasaryan wrote:
> On Wed, Jan 18, 2023 at 1:33 PM Michal Hocko wrote:
[...]
> > So it will become:
> > Move VMA flag modification (which now implies VMA locking) before
> > vma_adjust_trans_huge() to ensure the modifications are done a
tions. Is there any
reason to stick with that memory model for an advance feature you are
working on?
--
Michal Hocko
SUSE Labs
gzilla.kernel.org/show_bug.cgi?id=202187
> >>
> >> So... do we merge this patch or not? Seems that the overall view is
> >> "risky but nobody is likely to do anything better any time soon"?
> >
> > Can we decide on this one way or the other?
>
> Hmm, not sure who's the person to decide. I tend to prefer doing the
> node renaming, handling this in ppc code;
Agreed. That would be a safer option.
--
Michal Hocko
SUSE Labs
;slab: introduce kzfree()")
> Cc: sta...@vger.kernel.org
> Signed-off-by: Waiman Long
Acked-by: Michal Hocko
Although I am not really sure this is a stable material. Is there any
known instance where the memset was optimized out from kzfree?
> ---
> mm/slab_common.c | 2
locate from the vmalloc allocator, I really think that kvfree()
> should assert that it's !in_atomic(). Otherwise we can get into trouble
> if we end up calling vfree() and have to take the mutex.
FWIW __vfree already checks for atomic context and put the work into a
deferred context. So this should be safe. It should be used as a last
resort, though.
--
Michal Hocko
SUSE Labs
On Wed 17-06-20 04:08:20, Matthew Wilcox wrote:
> On Wed, Jun 17, 2020 at 09:12:12AM +0200, Michal Hocko wrote:
> > On Tue 16-06-20 17:37:11, Matthew Wilcox wrote:
> > > Not just performance critical, but correctness critical. Since kvfree()
> > > may allocate from the
On Wed 17-06-20 05:23:21, Matthew Wilcox wrote:
> On Wed, Jun 17, 2020 at 01:31:57PM +0200, Michal Hocko wrote:
> > On Wed 17-06-20 04:08:20, Matthew Wilcox wrote:
> > > If you call vfree() under
> > > a spinlock, you're in trouble. in_atomic() only knows
expected places. IIRC we have discussed testing in the previous
version and David has provided a way to emulate these configurations
on x86. Did you manage to use those instruction for additional testing
on other than ppc architectures?
> Cc: linuxppc-dev@lists.ozlabs.org
> Cc: linux...@kvack.or
On Wed 01-07-20 13:30:57, David Hildenbrand wrote:
> On 01.07.20 13:06, David Hildenbrand wrote:
> > On 01.07.20 13:01, Srikar Dronamraju wrote:
> >> * David Hildenbrand [2020-07-01 12:15:54]:
> >>
> >>> On 01.07.20 12:04, Srikar Dronamraju wrote:
>
; used by the kernel and can be used arbitrarily?
> >
>
> I thought Michal Hocko already gave a clear picture on why mapping is a bad
> idea. https://lore.kernel.org/lkml/20200316085425.gb11...@dhcp22.suse.cz/t/#u
> Are you suggesting that we add that as part of the changelog?
On Thu 02-07-20 12:14:08, Srikar Dronamraju wrote:
> * Michal Hocko [2020-07-01 14:21:10]:
>
> > > >>>>>>
> > > >>>>>> 2. Also existence of dummy node also leads to inconsistent
> > > >>>>>> informati
[Cc Andi]
On Fri 03-07-20 11:10:01, Michal Suchanek wrote:
> On Wed, Jul 01, 2020 at 02:21:10PM +0200, Michal Hocko wrote:
> > On Wed 01-07-20 13:30:57, David Hildenbrand wrote:
[...]
> > > Yep, looks like it.
> > >
> > > [0.009726] SRAT: PXM 1 ->
On Fri 03-07-20 11:24:17, Michal Hocko wrote:
> [Cc Andi]
>
> On Fri 03-07-20 11:10:01, Michal Suchanek wrote:
> > On Wed, Jul 01, 2020 at 02:21:10PM +0200, Michal Hocko wrote:
> > > On Wed 01-07-20 13:30:57, David Hildenbrand wrote:
> [...]
On Fri 03-07-20 13:32:21, David Hildenbrand wrote:
> On 03.07.20 12:59, Michal Hocko wrote:
> > On Fri 03-07-20 11:24:17, Michal Hocko wrote:
> >> [Cc Andi]
> >>
> >> On Fri 03-07-20 11:10:01, Michal Suchanek wrote:
> >>> On Wed, Jul 01, 2020 at 02:
lly helpful.
I will think about this some more but I am traveling this week. It seems
really awkward to register a sysfs file for an empty range. That looks
like a bug to me.
--
Michal Hocko
SUSE Labs
unsigned long align,
unsigned long goal)
{
- return memblock_virt_alloc_try_nid(size, align, goal,
+ return memblock_virt_alloc_core(size, align, goal,
BOOTMEM_ALLOC_ACCESSIBLE, node);
}
--
Michal Hocko
SUSE Labs
Correct, when memory it hotplugged, to gain the benefit of this fix, and
> also not to regress by actually double zeroing "struct pages" we should not
> zero it out. However, I do not really have means to test it.
It should be pretty easy to test with kvm, but I can help with testing
on the real HW as well.
Thanks!
--
Michal Hocko
SUSE Labs
nce count and other struct members. Almost nobody should be
looking at our page at this time and stealing the cache line. On the
other hand a large memcpy will basically wipe everything away from the
cpu cache. Or am I missing something?
--
Michal Hocko
SUSE Labs
On Wed 10-05-17 11:19:43, David S. Miller wrote:
> From: Michal Hocko
> Date: Wed, 10 May 2017 16:57:26 +0200
>
> > Have you measured that? I do not think it would be super hard to
> > measure. I would be quite surprised if this added much if anything at
> > all as t
re too worried then make it opt-in and make
it depend on ARCH_WANT_PER_PAGE_INIT and make it enabled for x86 and
sparc after memset optimization.
--
Michal Hocko
SUSE Labs
On Mon 15-05-17 16:44:26, Pasha Tatashin wrote:
> On 05/15/2017 03:38 PM, Michal Hocko wrote:
> >I do not think this is the right approach. Your measurements just show
> >that sparc could have a more optimized memset for small sizes. If you
> >keep the same memset
memory traffic for exclusive cache line and
struct pages are very likely to exclusive at that stage.
If that doesn't fly then be it but I have to confess I still do not
understand why that is not the case.
--
Michal Hocko
SUSE Labs
it would be slower but would that be
measurable? I am sorry to be so persistent here but I would be really
happier if this didn't depend on the deferred initialization. If this is
absolutely a no-go then I can live with that of course.
--
Michal Hocko
SUSE Labs
PARC by removing memset() from memblock, and
> using 8 stx in __init_single_page(). It appears we never miss L1 in
> __init_single_page() after the initial 8 stx.
OK, that is good to hear and it actually matches my understanding that
writes to a single cacheline should add an overhead.
Thanks!
--
Michal Hocko
SUSE Labs
do
you need to store anything in the pte? My understanding of PKEYs is that
the setup and teardown should be very cheap and so no page tables have
to updated. Or do I just misunderstand what you wrote here?
--
Michal Hocko
SUSE Labs
On Tue 11-07-17 12:32:57, Ram Pai wrote:
> On Tue, Jul 11, 2017 at 04:52:46PM +0200, Michal Hocko wrote:
> > On Wed 05-07-17 14:21:37, Ram Pai wrote:
> > > Memory protection keys enable applications to protect its
> > > address space from inadvertent access or c
On Wed 12-07-17 09:23:37, Michal Hocko wrote:
> On Tue 11-07-17 12:32:57, Ram Pai wrote:
[...]
> > Ideally the MMU looks at the PTE for keys, in order to enforce
> > protection. This is the case with x86 and is the case with power9 Radix
> > page table. Hence the keys have
On Thu 13-07-17 08:53:52, Benjamin Herrenschmidt wrote:
> On Wed, 2017-07-12 at 09:23 +0200, Michal Hocko wrote:
> >
> > >
> > > Ideally the MMU looks at the PTE for keys, in order to enforce
> > > protection. This is the case with x86 and is the case with
using them.
>
> The deferred-reserved pages are initialized in free_all_bootmem().
> Therefore, the fix is to switch the above calls.
Thanks for extending the changelog. This is more informative now.
> Signed-off-by: Pavel Tatashin
> Reviewed-by: Steven Sistare
> Reviewed-by:
calls.
>
> Signed-off-by: Pavel Tatashin
> Reviewed-by: Steven Sistare
> Reviewed-by: Daniel Jordan
> Reviewed-by: Bob Picco
> Acked-by: David S. Miller
As you separated x86 and sparc patches doing essentially the same I
assume David is going to take this patch?
Acked-by:
> -free_range:
> - /* Free the current block of pages to allocator */
> - nr_pages += nr_to_free;
> - deferred_free_range(free_base_page, free_base_pfn,
> - nr_to_free);
> - free_base_page = NULL;
> - free_base_pfn = nr_to_free = 0;
> - }
> - /* Free the last block of pages to allocator */
> - nr_pages += nr_to_free;
> - deferred_free_range(free_base_page, free_base_pfn, nr_to_free);
> -
> - first_init_pfn = max(end_pfn, first_init_pfn);
> + for_each_free_mem_range(i, nid, MEMBLOCK_NONE, &spa, &epa, NULL) {
> + spfn = max_t(unsigned long, first_init_pfn, PFN_UP(spa));
> + epfn = min_t(unsigned long, zone_end_pfn(zone), PFN_DOWN(epa));
> + nr_pages += deferred_init_range(nid, zid, spfn, epfn);
> }
>
> /* Sanity check that the next zone really is unpopulated */
> --
> 2.14.1
--
Michal Hocko
SUSE Labs
> Acked-by: David S. Miller
Acked-by: Michal Hocko
> ---
> arch/sparc/mm/init_64.c | 23 ++-
> 1 file changed, 6 insertions(+), 17 deletions(-)
>
> diff --git a/arch/sparc/mm/init_64.c b/arch/sparc/mm/init_64.c
> index 310c6754bcaa..99aea4d15a5f 100644
&g
>
> Signed-off-by: Pavel Tatashin
> Reviewed-by: Steven Sistare
> Reviewed-by: Daniel Jordan
> Reviewed-by: Bob Picco
> Acked-by: Michal Hocko
> ---
> include/linux/mm.h | 9 +
> mm/page_alloc.c| 1 +
> 2 files changed, 10 insertions(+)
>
> diff
> through __init_single_page().
Could you be more specific where is such a memory reserved?
--
Michal Hocko
SUSE Labs
LIGN(size);
> - map = memblock_virt_alloc_try_nid(size * map_count,
> - PAGE_SIZE, __pa(MAX_DMA_ADDRESS),
> - BOOTMEM_ALLOC_ACCESSIBLE, nodeid);
> + map = memblock_virt_alloc_try_nid_raw(size * map_count,
> + PAGE_SIZE, __pa(MAX_DMA_ADDRESS),
> + BOOTMEM_ALLOC_ACCESSIBLE, nodeid);
> if (map) {
> for (pnum = pnum_begin; pnum < pnum_end; pnum++) {
> if (!present_section_nr(pnum))
> --
> 2.14.1
--
Michal Hocko
SUSE Labs
"stop zeroing ..."
I think that moving the zeroying in one go is more reasonable than
adding it to __init_single_page with misleading numbers and later
dropping the zeroying from the memmap path.
--
Michal Hocko
SUSE Labs
On Tue 03-10-17 11:22:35, Pasha Tatashin wrote:
>
>
> On 10/03/2017 09:08 AM, Michal Hocko wrote:
> > On Wed 20-09-17 16:17:08, Pavel Tatashin wrote:
> > > Add struct page zeroing as a part of initialization of other fields in
> > > __init_single_page()
ng any new branches, and the code is still going to stay
> compact.
OK. It is a bit clunky but we are holding too much state there. I
haven't checked whether that can be simplified but this can be always
done later.
--
Michal Hocko
SUSE Labs
On Tue 03-10-17 11:29:16, Pasha Tatashin wrote:
> On 10/03/2017 09:18 AM, Michal Hocko wrote:
> > On Wed 20-09-17 16:17:10, Pavel Tatashin wrote:
> > > Some memory is reserved but unavailable: not present in memblock.memory
> > > (because not backed by phys
m_low_memory_range code path. I am
not even sure we have to care about it because nobody should be walking
pfns outside of any zone. I am worried that this patch adds a code which
is not really used and it will just stay that way for ever because
nobody will dare to change it as it is too obscure an
ctually sure that trim_low_memory_range is doing a sane and
really needed thing? In other words do we have a zone which contains
this no-memory backed pfns?
--
Michal Hocko
SUSE Labs
ck_virt_alloc_try_nid_raw is a new
function which doesn't zero out...
--
Michal Hocko
SUSE Labs
On Fri 06-10-17 12:11:42, David Laight wrote:
> From: Michal Hocko
> > Sent: 06 October 2017 12:47
> > On Fri 06-10-17 11:10:14, David Laight wrote:
> > > From: Pavel Tatashin
> > > > Sent: 05 October 2017 22:11
> > > > vmemmap_alloc_block() will no
ot;, pgcnt);
> +}
> +#endif /* CONFIG_HAVE_MEMBLOCK */
> +
> #ifdef CONFIG_HAVE_MEMBLOCK_NODE_MAP
>
> #if MAX_NUMNODES > 1
> @@ -6632,6 +6668,7 @@ void __init free_area_init_nodes(unsigned long
> *max_zone_pfn)
> node_set_state(nid, N_MEMORY);
> check_for_memory(pgdat, nid);
> }
> + zero_resv_unavail();
> }
>
> static int __init cmdline_parse_core(char *p, unsigned long *core)
> @@ -6795,6 +6832,7 @@ void __init free_area_init(unsigned long *zones_size)
> {
> free_area_init_node(0, zones_size,
> __pa(PAGE_OFFSET) >> PAGE_SHIFT, NULL);
> + zero_resv_unavail();
> }
>
> static int page_alloc_cpu_dead(unsigned int cpu)
> --
> 2.14.2
--
Michal Hocko
SUSE Labs
x27;s fix it up but right now I would rather
go a simpler path.
--
Michal Hocko
SUSE Labs
to pfn 0.
Hmm, this is really interesting! I thought each memblock is guaranteed
to be section size aligned. But I suspect this is more of a wishful
thinking. But now I see what is the problem.
--
Michal Hocko
SUSE Labs
Signed-off-by: Pavel Tatashin
> Reviewed-by: Steven Sistare
> Reviewed-by: Daniel Jordan
> Reviewed-by: Bob Picco
Acked-by: Michal Hocko
> ---
> include/linux/memblock.h | 16
> include/linux/mm.h | 15 +++
> mm/page_alloc.c | 38 +++
On Tue 10-10-17 15:44:41, Michal Hocko wrote:
> On Mon 09-10-17 18:19:27, Pavel Tatashin wrote:
> > Some memory is reserved but unavailable: not present in memblock.memory
> > (because not backed by physical pages), but present in memblock.reserved.
> > Such memory has back
. The perfomance improvements are a bonus on
top.
Thanks, good work!
--
Michal Hocko
SUSE Labs
though. I also
suspect the code can be further simplified but again this is nothing to
block this to go.
> Signed-off-by: Pavel Tatashin
> Reviewed-by: Steven Sistare
> Reviewed-by: Daniel Jordan
> Reviewed-by: Bob Picco
I do not see any obvious issues in the patch
Acked-b
vma->vm_end >=
vma->vm_mm->start_stack)
+ name = "[stack]";
+ }
+ pr_cont(" name:%s\n", name);
+ } else
+ pr_info("Uhm, no clashing VMA\n");
+ up_read(&mm->mmap_sem);
return -EAGAIN;
}
--
Michal Hocko
SUSE Labs
On Tue 07-11-17 11:28:54, Michal Hocko wrote:
> On Tue 07-11-17 15:20:29, Abdul Haleem wrote:
> > Hi,
> >
> > Today's next kernel fails to boot on Power 7 Machine with below errors
> > in boot log messages.
> >
> > 'Uhuuh, elf segement at 00
Hi Abdul,
On Tue 07-11-17 11:28:54, Michal Hocko wrote:
> On Tue 07-11-17 15:20:29, Abdul Haleem wrote:
> > Hi,
> >
> > Today's next kernel fails to boot on Power 7 Machine with below errors
> > in boot log messages.
> >
> > 'Uhuuh, elf segemen
[Cc arm and ppc maintainers]
Thanks a lot for testing!
On Sun 12-11-17 11:38:02, Joel Stanley wrote:
> On Fri, Nov 10, 2017 at 11:00 PM, Michal Hocko wrote:
> > Hi Joel,
> >
> > On Wed 08-11-17 15:20:50, Michal Hocko wrote:
> > [...]
> >> > There are a
On Mon 13-11-17 10:20:06, Michal Hocko wrote:
> [Cc arm and ppc maintainers]
Hmm, it turned out to be a problem on other architectures as well.
CCing more maintainers. For your reference, we are talking about
http://lkml.kernel.org/r/20171023082608.6167-1-mho...@kernel.org
which has bro
On Mon 13-11-17 22:34:50, Michael Ellerman wrote:
> Hi Michal,
>
> Michal Hocko writes:
> > On Mon 13-11-17 10:20:06, Michal Hocko wrote:
> >> [Cc arm and ppc maintainers]
> >
> > Hmm, it turned out to be a problem on other architectures as well.
> >
On Mon 13-11-17 10:20:06, Michal Hocko wrote:
> [Cc arm and ppc maintainers]
>
> Thanks a lot for testing!
>
> On Sun 12-11-17 11:38:02, Joel Stanley wrote:
> > On Fri, Nov 10, 2017 at 11:00 PM, Michal Hocko wrote:
> > > Hi Joel,
> > >
> > &
On Mon 13-11-17 13:00:57, Michal Hocko wrote:
[...]
> Yes, I have mentioned that in the previous email but the amount of code
> would be even larger. Basically every arch which reimplements
> arch_get_unmapped_area would have to special case new MAP_FIXED flag to
> do vma lookup.
I
On Mon 13-11-17 15:09:09, Russell King - ARM Linux wrote:
> On Mon, Nov 13, 2017 at 03:11:40PM +0100, Michal Hocko wrote:
> > On Mon 13-11-17 10:20:06, Michal Hocko wrote:
> > > [Cc arm and ppc maintainers]
> > >
> > > Thanks a lot for testing!
> > >
On Mon 13-11-17 16:16:41, Michal Hocko wrote:
> On Mon 13-11-17 13:00:57, Michal Hocko wrote:
> [...]
> > Yes, I have mentioned that in the previous email but the amount of code
> > would be even larger. Basically every arch which reimplements
> > arch_get_unmapped_area wo
On Mon 13-11-17 15:48:13, Russell King - ARM Linux wrote:
> On Mon, Nov 13, 2017 at 04:16:41PM +0100, Michal Hocko wrote:
> > On Mon 13-11-17 13:00:57, Michal Hocko wrote:
> > [...]
> > > Yes, I have mentioned that in the previous email but the amount of code
> > >
[Sorry for spamming, this one is the last attempt hopefully]
On Mon 13-11-17 16:49:39, Michal Hocko wrote:
> On Mon 13-11-17 16:16:41, Michal Hocko wrote:
> > On Mon 13-11-17 13:00:57, Michal Hocko wrote:
> > [...]
> > > Yes, I have mentioned that in the previous emai
On Mon 13-11-17 09:35:22, Khalid Aziz wrote:
> On 11/13/2017 09:06 AM, Michal Hocko wrote:
> > OK, so this one should take care of the backward compatibility while
> > still not touching the arch code
> > ---
> > commit 39ff9bf8597e79a032da0954aea1f0d77d137765
> &g
On Tue 14-11-17 19:54:59, Michael Ellerman wrote:
> Michal Hocko writes:
[...]
> > So this was the most simple solution I could come up
> > with. If there was a general interest for MAP_FIXED_SAFE then we can
> > introduce it later of course. I would just like the harden
On Tue 14-11-17 20:18:04, Michael Ellerman wrote:
> Michal Hocko writes:
>
> > [Sorry for spamming, this one is the last attempt hopefully]
> >
> > On Mon 13-11-17 16:49:39, Michal Hocko wrote:
> >> On Mon 13-11-17 16:16:41, Michal Hocko wrote:
> >> >
Y_HOTPLUG disabled.
There is slight risk that we will encounter corner cases on some
architectures with weird memory layout/topology but we should better
explicitly disable this code rather than make it opt-in so this looks
like an improvement to me.
> Signed-off-by: Pavel Tatashin
Acked-b
301 - 400 of 484 matches
Mail list logo
