sta...@vger.kernel.org # v4.15+
Hmm, are you sure about 4.15? Doesn't this go all the way down to
deferred initialization? I do not see any recent changes on when
setup_per_cpu_pageset is called.
> Signed-off-by: Mel Gorman
Acked-by: Michal Hocko
> ---
> mm/page_allo
;
> Signed-off-by: Mel Gorman
Acked-by: Michal Hocko
> ---
> mm/page_alloc.c | 23 ---
> 1 file changed, 12 insertions(+), 11 deletions(-)
>
> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> index c0b2e0306720..cafe568d36f6 100644
> --- a/mm/page_al
> }
> -
> -/*
> - * Set PG_hwpoison flag if a given page is confirmed to be a free page. This
> - * test is performed under the zone lock to prevent a race against page
> - * allocation.
> - */
> -bool set_hwpoison_free_buddy_page(struct page *page)
> -{
> - struct zone *zone = page_zone(page);
> - unsigned long pfn = page_to_pfn(page);
> - unsigned long flags;
> - unsigned int order;
> - bool hwpoisoned = false;
> -
> - spin_lock_irqsave(&zone->lock, flags);
> - for (order = 0; order < MAX_ORDER; order++) {
> - struct page *page_head = page - (pfn & ((1 << order) - 1));
> -
> - if (PageBuddy(page_head) && page_order(page_head) >= order) {
> - if (!TestSetPageHWPoison(page))
> - hwpoisoned = true;
> - break;
> - }
> - }
> - spin_unlock_irqrestore(&zone->lock, flags);
> -
> - return hwpoisoned;
> -}
> #endif
> --
> 2.12.3
--
Michal Hocko
SUSE Labs
gt; + spin_unlock_irqrestore(&zone->lock, flags);
> + return ret;
> + }
> +
> +/*
> * Set PG_hwpoison flag if a given page is confirmed to be a free page. This
> * test is performed under the zone lock to prevent a race against page
> * allocation.
> --
> 2.12.3
--
Michal Hocko
SUSE Labs
he page reference taken by get_user_pages_fast(). In
> - * the absence of MF_COUNT_INCREASED the memory_failure()
> - * routine is responsible for pinning the page to prevent it
> - * from being released back to the page allocator.
> - */
> - put_page(page);
> ret = memory_failure(pfn, 0);
> if (ret)
> return ret;
> --
> 2.12.3
>
--
Michal Hocko
SUSE Labs
gt;flags;
> + page_flags = p->flags;
>
> /*
>* unpoison always clear PG_hwpoison inside page lock
> --
> 2.12.3
--
Michal Hocko
SUSE Labs
On Fri 18-10-19 13:00:45, David Hildenbrand wrote:
> On 18.10.19 10:55, Michal Hocko wrote:
> > On Fri 18-10-19 10:38:21, David Hildenbrand wrote:
> > > On 18.10.19 10:24, Michal Hocko wrote:
> > > > On Fri 18-10-19 10:13:36, David Hildenbrand wrote:
> >
On Fri 18-10-19 10:50:24, David Hildenbrand wrote:
> On 18.10.19 10:15, Michal Hocko wrote:
> > On Wed 16-10-19 16:14:52, David Hildenbrand wrote:
> > > On 16.10.19 16:03, Michal Hocko wrote:
> > [...]
> > > > But why cannot you keep the reference count at 1 (do
On Fri 18-10-19 10:38:21, David Hildenbrand wrote:
> On 18.10.19 10:24, Michal Hocko wrote:
> > On Fri 18-10-19 10:13:36, David Hildenbrand wrote:
> > [...]
> > > However, if the compound page spans multiple pageblocks
> >
> > Although hugetlb pages spanning pa
blocks as the name suggests. It is simply
traversing all valid RAM ranges (see walk_system_ram_range).
--
Michal Hocko
SUSE Labs
On Wed 16-10-19 16:14:52, David Hildenbrand wrote:
> On 16.10.19 16:03, Michal Hocko wrote:
[...]
> > But why cannot you keep the reference count at 1 (do get_page when
> > offlining the page)? In other words as long as the driver knows the page
> > has been returned to the
.org/r/20190124231441.37a4a...@viggo.jf.intel.com
How does this compare to
http://lkml.kernel.org/r/1560468577-101178-1-git-send-email-yang@linux.alibaba.com?
--
Michal Hocko
SUSE Labs
On Fri 18-10-19 06:32:22, Naoya Horiguchi wrote:
> On Fri, Oct 18, 2019 at 08:06:35AM +0200, Michal Hocko wrote:
> > On Fri 18-10-19 02:19:06, Naoya Horiguchi wrote:
> > > On Thu, Oct 17, 2019 at 08:27:59PM +0200, Michal Hocko wrote:
> > > > On Thu 17-10-19 14:07:13
On Fri 18-10-19 02:19:06, Naoya Horiguchi wrote:
> On Thu, Oct 17, 2019 at 08:27:59PM +0200, Michal Hocko wrote:
> > On Thu 17-10-19 14:07:13, Qian Cai wrote:
> > > On Thu, 2019-10-17 at 12:01 +0200, Michal Hocko wrote:
> > > > On Thu 17-10-19 09:34:10, Naoya Horiguch
On Thu 17-10-19 14:07:13, Qian Cai wrote:
> On Thu, 2019-10-17 at 12:01 +0200, Michal Hocko wrote:
> > On Thu 17-10-19 09:34:10, Naoya Horiguchi wrote:
> > > On Mon, Oct 14, 2019 at 10:39:14AM +0200, Michal Hocko wrote:
> >
> > [...]
> > > > diff --git a
fe and reasonable to perform GFP_KERNEL (aka sleepable)
allocations from this function?
> Cc: Andrew Morton
> Cc: Mike Rapoport
> Cc: Paul Burton
> Cc: Michal Hocko
> Cc: Michael Ellerman
> Cc: Anshuman Khandual
> Signed-off-by: yuqi jin
On Thu 17-10-19 11:25:47, David Laight wrote:
> From: Michal Hocko
> > Sent: 17 October 2019 12:05
> ...
> > > Plus, I don't see any locking here, should this be WRITE_ONCE() at
> > > minimum?
> >
> > Why would that matter? Do you expect several roo
On Thu 17-10-19 12:59:40, Pavel Machek wrote:
> Hi!
>
> > From: Michal Hocko
> >
> > commit b0f53dbc4bc4c371f38b14c391095a3bb8a0bb40 upstream.
> >
> > Partially revert 16db3d3f1170 ("kernel/sysctl.c: threads-max observe
> > limits") becau
On Thu 17-10-19 09:34:10, Naoya Horiguchi wrote:
> On Mon, Oct 14, 2019 at 10:39:14AM +0200, Michal Hocko wrote:
[...]
> > diff --git a/mm/page_isolation.c b/mm/page_isolation.c
> > index 89c19c0feadb..5fb3fee16fde 100644
> > --- a/mm/page_isolation.c
> > +++ b/mm/pag
On Thu 17-10-19 09:21:24, David Hildenbrand wrote:
> On 17.10.19 09:11, Michal Hocko wrote:
> > On Thu 17-10-19 10:44:41, Anshuman Khandual wrote:
> > [...]
> > > Does this add-on documentation look okay ? Should we also mention about
> > > the
> > >
aligned to a page boundary. If nr_pages
is a power of two then the alignement is guaranteed to be to the given
nr_pages (e.g. 1GB request would be aligned to 1GB).
--
Michal Hocko
SUSE Labs
On Wed 16-10-19 21:01:19, Anshuman Khandual wrote:
>
>
> On 10/16/2019 06:11 PM, Michal Hocko wrote:
> > On Wed 16-10-19 14:29:05, David Hildenbrand wrote:
> >> On 16.10.19 13:51, Michal Hocko wrote:
> >>> On Wed 16-10-19 16:43:57, Anshuman Khandual wrote:
&
On Wed 16-10-19 15:55:00, David Hildenbrand wrote:
> On 16.10.19 15:45, Michal Hocko wrote:
[...]
> > There is state stored in the struct page. In other words this shouldn't
> > be really different from HWPoison pages. I cannot find the code that is
> > doing that and
On Wed 16-10-19 15:45:06, David Hildenbrand wrote:
> On 16.10.19 13:43, Michal Hocko wrote:
> > On Thu 19-09-19 16:22:25, David Hildenbrand wrote:
> > > virtio-mem wants to allow to offline memory blocks of which some parts
> > > were unplugged, especially, to later of
On Wed 16-10-19 14:50:30, David Hildenbrand wrote:
> On 16.10.19 13:43, Michal Hocko wrote:
> > On Thu 19-09-19 16:22:25, David Hildenbrand wrote:
> > > virtio-mem wants to allow to offline memory blocks of which some parts
> > > were unplugged, especially, to later of
On Wed 16-10-19 14:29:05, David Hildenbrand wrote:
> On 16.10.19 13:51, Michal Hocko wrote:
> > On Wed 16-10-19 16:43:57, Anshuman Khandual wrote:
> > >
> > >
> > > On 10/16/2019 04:39 PM, David Hildenbrand wrote:
> > [...]
> > > > Just to
licitly what to be included for the respin. Anyways
> seems like the previous thread is active again. I am happy to incorporate
> anything new getting agreed on there.
Your patch is using the same alignment as the original code would do. If
an explicit alignement is needed then this can be adde
On Wed 16-10-19 13:10:41, David Hildenbrand wrote:
> On 16.10.19 13:08, Michal Hocko wrote:
> > On Wed 16-10-19 10:56:16, David Hildenbrand wrote:
[...]
> > > Gigantic pages have to be aligned AFAIK.
> >
> > Aligned to what? I do not see any guarantee like
ace.
I am also not really sure why do you want/need to control beyond the
offlining stage. Care to explain some more?
--
Michal Hocko
SUSE Labs
unt)
> + goto unmovable;
> continue;
> }
Do we really need to distinguish offline and hwpoison pages? They are
both unmovable for allocator purposes and offlineable for the hotplug,
right? Should we just hide them behind a helper and use it rather than
an explicit SKIP_$FOO?
--
Michal Hocko
SUSE Labs
APIs
are EXPORT_SYMBOL so there should better be a good reason for this one
to differ. I can understand that this one is slightly different by
requesting a specific range of the memory but it is still under a full
control of the core MM to say no.
> Cc: Andrew Morton
> Cc: Michal Hocko
>
On Wed 16-10-19 10:56:16, David Hildenbrand wrote:
> On 16.10.19 10:51, Michal Hocko wrote:
> > On Wed 16-10-19 10:08:21, David Hildenbrand wrote:
> > > On 16.10.19 09:34, Anshuman Khandual wrote:
> > [...]
> > > > +static bool pfn_range_valid_
his commit just adds more explanations, as a result giving
> answers on questions like when it can occur, how often, under
> which conditions and what happens if GFP_NOWAIT gets failed.
>
> Signed-off-by: Uladzislau Rezki (Sony)
Acked-by: Michal Hocko
> ---
> mm/vmalloc.c | 13 +++
because vmalloc is not GFP_NOWAIT compliant
in general (e.g. page table allocations are GFP_KERNEL) there is no
reason to spread that bad habit and it is good to fix the antipattern.
"
>
> Signed-off-by: Uladzislau Rezki (Sony)
Acked-by: Michal Hocko
> ---
> mm/vmalloc.c | 8 -
n regard of preloading
> - adjust and move some comments
>
> Fixes: 82dd23e84be3 ("mm/vmalloc.c: preload a CPU with one object for split
> purpose")
> Reviewed-by: Steven Rostedt (VMware)
> Acked-by: Sebastian Andrzej Siewior
>
On Wed 16-10-19 15:58:32, Anshuman Khandual wrote:
>
>
> On 10/16/2019 02:28 PM, Michal Hocko wrote:
[...]
> > After other issues mentioned by David get resolved you can add
>
> Just to confirm. Only the styling issues, right ? pfn_range_valid_contig(),
> pfn alignme
and broken instances.
> Cc: Mike Kravetz
> Cc: Andrew Morton
> Cc: Vlastimil Babka
> Cc: Michal Hocko
> Cc: David Rientjes
> Cc: Andrea Arcangeli
> Cc: Oscar Salvador
> Cc: Mel Gorman
> Cc: Mike Rapoport
> Cc: Dan Williams
> Cc: Pavel Tatashin
> Cc: Matth
lock, flags);
> > +
> > + pfn = ALIGN(zone->zone_start_pfn, nr_pages);
>
> This alignment does not make too much sense when allowing passing in !power
> of two orders. Maybe the caller should specify the requested alignment
> instead? Or should we enforce this to be aligned to make our life easier for
> now?
Are there any usecases that would require than the page alignment?
--
Michal Hocko
SUSE Labs
Poisoned(p))
> [ 13.898549][T1] [ cut here ]
> [ 13.898549][T1] kernel BUG at ./include/linux/mm.h:1107!
> [ 13.898549][ T1] invalid opcode: [#1] SMP DEBUG_PAGEALLOC KASAN PTI
> [ 13.898549][T1] CPU: 0 PID: 1 Comm: swapper/0 Not tainted
> 5.4.0-rc3-next-20191015+ #
--
Michal Hocko
SUSE Labs
il.com
> Signed-off-by: Gaowei Pu
> Reviewed-by: Andrew Morton
> Cc: Vlastimil Babka
> Cc: Michal Hocko
> Signed-off-by: Andrew Morton
Acked-by: Michal Hocko
There are few more to convert
diff --git a/kernel/events/uprobes.c b/kernel/events/uprobes.c
index 94d38a39d72e..9c197a2
On Tue 15-10-19 10:58:36, Guilherme G. Piccoli wrote:
> On 10/15/19 9:18 AM, Michal Hocko wrote:
> > I do agree with Qian Cai here. Kdump kernel requires a very tailored
> > environment considering it is running in a very restricted
> > configuration. The hugetlb pre-all
nly my opinion, let's see what people think about it!
I do agree with Qian Cai here. Kdump kernel requires a very tailored
environment considering it is running in a very restricted
configuration. The hugetlb pre-allocation sounds like a tooling problem
and should be fixed at that layer.
--
Michal Hocko
SUSE Labs
can be the case when an offline memory block (e.g., never onlined) is
> spanned by a zone.
>
> Note: As explained by Michal in [1], alloc_contig_range() will verify
> the range. So it boils down to the wrong access in this function.
>
> [1] http://lkml.kernel.org/r/201804230009
nd what they are testing for would be
really appreciated. Who wants to run these tests and why/when? What kind
of bugs would get detected? In short why do we really need/want this
code in the tree?
--
Michal Hocko
SUSE Labs
On Tue 15-10-19 13:49:14, Konstantin Khlebnikov wrote:
> On 15/10/2019 13.36, Michal Hocko wrote:
> > On Tue 15-10-19 11:44:22, Konstantin Khlebnikov wrote:
> > > On 15/10/2019 11.20, Michal Hocko wrote:
> > > > On Tue 15-10-19 11:09:59, Konstantin Khlebnikov wrot
> .mknod = hugetlbfs_mknod,
> .rename = simple_rename,
> .setattr= hugetlbfs_setattr,
> + .tmpfile= hugetlbfs_tmpfile,
> };
>
> static const struct inode_operations hugetlbfs_inode_operations = {
> --
> 2.21.0
>
--
Michal Hocko
SUSE Labs
On Tue 15-10-19 11:44:22, Konstantin Khlebnikov wrote:
> On 15/10/2019 11.20, Michal Hocko wrote:
> > On Tue 15-10-19 11:09:59, Konstantin Khlebnikov wrote:
> > > Mapped, dirty and writeback pages are also counted in per-lruvec stats.
> > > These counters needs update
r-lruvec stats infrastructure")
> Signed-off-by: Konstantin Khlebnikov
We want Cc: stable I suspect because broken stats might be really
misleading.
The patch looks ok to me otherwise
Acked-by: Michal Hocko
> ---
> mm/memcontrol.c | 18 --
> 1 file changed
> spin_lock_init(&memcg->deferred_split_queue.split_queue_lock);
> INIT_LIST_HEAD(&memcg->deferred_split_queue.split_queue);
> memcg->deferred_split_queue.split_queue_len = 0;
> + memcg->deferred_split_queue.deferred_split_calls = 0;
> + INIT_WORK(&memcg->deferred_split_queue.deferred_split_work,
> + flush_deferred_split_queue_memcg);
> #endif
> idr_replace(&mem_cgroup_idr, memcg, memcg->id.id);
> return memcg;
> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> index 15c2050c629b..2f52e538a26f 100644
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -6674,6 +6674,8 @@ static void pgdat_init_split_queue(struct pglist_data
> *pgdat)
> spin_lock_init(&ds_queue->split_queue_lock);
> INIT_LIST_HEAD(&ds_queue->split_queue);
> ds_queue->split_queue_len = 0;
> + ds_queue->deferred_split_calls = 0;
> + INIT_WORK(&ds_queue->deferred_split_work, flush_deferred_split_queue);
> }
> #else
> static void pgdat_init_split_queue(struct pglist_data *pgdat) {}
> --
> 2.21.0
--
Michal Hocko
SUSE Labs
ode(vmap_area_cachep, GFP_KERNEL,
> node);
> + pva = kmem_cache_alloc_node(vmap_area_cachep,
> + gfp_mask & GFP_RECLAIM_MASK, node);
>
> spin_lock(&vmap_area_lock);
>
> It should be sent as a separate patch, i think.
Yes. I do not think this would make any real difference because that
battle is lost long ago. vmalloc is simply not gfp mask friendly. There
are places like page table allocation which are hardcoded GFP_KERNEL so
GFP_NOWAIT semantic is not going to work, really. The above makes sense
from a pure aesthetic POV, though, I would say.
--
Michal Hocko
SUSE Labs
[Cc Oscar]
On Fri 11-10-19 12:13:17, David Hildenbrand wrote:
> On 11.10.19 08:02, Naoya Horiguchi wrote:
> > On Thu, Oct 10, 2019 at 09:58:40AM +0200, David Hildenbrand wrote:
> >> On 10.10.19 09:52, David Hildenbrand wrote:
> >>> On 10.10.19 09:35, Michal Hocko wr
d similarly return -EIO.
>
> Fixes: f1dd2cd13c4b ("mm, memory_hotplug: do not associate hotadded memory to
> zones until online") # visible after d0dc12e86b319
> Cc: Greg Kroah-Hartman
> Cc: "Rafael J. Wysocki"
> Cc: Michal Hocko
> Cc: Andrew Morton
&
will refill the cache we allocate from.
> + */
> + pva = kmem_cache_alloc_node(vmap_area_cachep, GFP_KERNEL, node);
>
> spin_lock(&vmap_area_lock);
> - preempt_enable();
> +
> + if (pva && __this_cpu_cmpxchg(ne_fit_preload_node, NULL, pva))
> + kmem_cache_free(vmap_area_cachep, pva);
>
> /*
>* If an allocation fails, the "vend" address is
> --
> 2.20.1
--
Michal Hocko
SUSE Labs
y(policy, bmp->maskp, bmp->size + 1) < 0)
numa_error("set_mempolicy");
}
The semantic is quite awkward but it is that way for years.
--
Michal Hocko
SUSE Labs
0).
>
> Fixes: f1dd2cd13c4b ("mm, memory_hotplug: do not associate hotadded memory to
> zones until online") # visible after d0dc12e86b319
> Signed-off-by: Qian Cai
> Cc: Andrew Morton
> Cc: Vlastimil Babka
> Cc: Michal Hocko
> Cc: Thomas Gleixner
> Cc: &q
- else if (skip_hwpoisoned_pages && PageHWPoison(page))
+ else if (skip_hwpoisoned_pages &&
PageHWPoison(compound_head(page)))
/* A HWPoisoned page cannot be also PageBuddy */
pfn++;
else
--
Michal Hocko
SUSE Labs
ND))
> return false;
>
> /*
> @@ -2577,6 +2582,10 @@ static bool clone3_args_valid(const struct
> kernel_clone_args *kargs)
> if (kargs->flags & (CLONE_DETACHED | CSIGNAL))
> return false;
>
> + if ((kargs->flags & (CLONE_SIGHAND | CLONE3_CLEAR_SIGHAND)) ==
> + (CLONE_SIGHAND | CLONE3_CLEAR_SIGHAND))
> + return false;
> +
> if ((kargs->flags & (CLONE_THREAD | CLONE_PARENT)) &&
> kargs->exit_signal)
> return false;
> --
> 2.23.0
--
Michal Hocko
SUSE Labs
On Thu 10-10-19 13:48:06, Qian Cai wrote:
> On Thu, 2019-10-10 at 19:30 +0200, Michal Hocko wrote:
> > On Thu 10-10-19 10:47:38, Qian Cai wrote:
> > > On Thu, 2019-10-10 at 16:18 +0200, Michal Hocko wrote:
> > > > On Thu 10-10-19 09:11:52, Qian Cai wrote:
> &g
On Thu 10-10-19 10:47:38, Qian Cai wrote:
> On Thu, 2019-10-10 at 16:18 +0200, Michal Hocko wrote:
> > On Thu 10-10-19 09:11:52, Qian Cai wrote:
> > > On Thu, 2019-10-10 at 12:59 +0200, Michal Hocko wrote:
> > > > On Thu 10-10-19 05:01:44, Qian Cai wrote:
> > &g
On Thu 10-10-19 09:11:52, Qian Cai wrote:
> On Thu, 2019-10-10 at 12:59 +0200, Michal Hocko wrote:
> > On Thu 10-10-19 05:01:44, Qian Cai wrote:
> > >
> > >
> > > > On Oct 9, 2019, at 12:23 PM, Michal Hocko wrote:
> > > >
> > > &
On Thu 10-10-19 05:01:44, Qian Cai wrote:
>
>
> > On Oct 9, 2019, at 12:23 PM, Michal Hocko wrote:
> >
> > If this was only about the memory offline code then I would agree. But
> > we are talking about any printk from the zone->lock context and that is
>
On Thu 10-10-19 17:16:29, Sergey Senozhatsky wrote:
> On (10/10/19 09:40), Michal Hocko wrote:
> [..]
> > > > Considering that console.write is called from essentially arbitrary code
> > > > path IIUC then all the locks used in this path should be pretty much
> >
On Thu 10-10-19 14:12:01, Sergey Senozhatsky wrote:
> On (10/09/19 16:26), Michal Hocko wrote:
> > On Wed 09-10-19 15:56:32, Peter Oberparleiter wrote:
> > [...]
> > > A generic solution would be preferable from my point of view though,
> > > because otherwise eac
On Thu 10-10-19 09:27:32, David Hildenbrand wrote:
> On 09.10.19 16:43, Michal Hocko wrote:
> > On Wed 09-10-19 16:24:35, David Hildenbrand wrote:
> >> We should check for pfn_to_online_page() to not access uninitialized
> >> memmaps. Reshuffle the code so we don&#x
eturn value but directly dereference it, which seems
> potentially unsafe.
> Such callers include mem_cgroup_hierarchy_read(),
> mem_cgroup_hierarchy_write(), mem_cgroup_read_u64(),
> mem_cgroup_reset(), etc.
And none of those should be ever called under that condition AFAICS.
Thanks!
--
Michal Hocko
SUSE Labs
On Wed 09-10-19 11:08:35, Qian Cai wrote:
> On Wed, 2019-10-09 at 16:34 +0200, Michal Hocko wrote:
> > On Wed 09-10-19 10:19:44, Qian Cai wrote:
> > > On Wed, 2019-10-09 at 15:51 +0200, Michal Hocko wrote:
> >
> > [...]
> > > > Can you paste the full lock
On Wed 09-10-19 16:24:35, David Hildenbrand wrote:
> We should check for pfn_to_online_page() to not access uninitialized
> memmaps. Reshuffle the code so we don't have to duplicate the error
> message.
>
> Cc: Naoya Horiguchi
> Cc: Andrew Morton
> Cc: Michal Hoc
ializing - garbage)
>*/
> }
>
> We'll leave the pfn_zone_device_reserved() check in stable_page_flags()
> in place as that function is also used from memory failure. We now
> no longer dump information about pages that are not in use anymore -
> offl
On Wed 09-10-19 10:19:44, Qian Cai wrote:
> On Wed, 2019-10-09 at 15:51 +0200, Michal Hocko wrote:
[...]
> > Can you paste the full lock chain graph to be sure we are on the same
> > page?
>
> WARNING: possible circular locking dependency detected
> 5.3.0-next
lock
chains.
--
Michal Hocko
SUSE Labs
On Wed 09-10-19 09:43:13, Qian Cai wrote:
> On Wed, 2019-10-09 at 15:27 +0200, Michal Hocko wrote:
> > On Wed 09-10-19 09:06:42, Qian Cai wrote:
> > [...]
> > > https://lore.kernel.org/linux-mm/1570460350.5576.290.ca...@lca.pw/
> > >
> >
On Wed 09-10-19 15:24:05, David Hildenbrand wrote:
> On 09.10.19 15:22, Michal Hocko wrote:
> > On Wed 09-10-19 14:58:24, David Hildenbrand wrote:
> > [...]
> >> I would be fine with this, but it means that - for now - the three
> >> /proc/ files won't b
clear example of a _real_ lockdep report that is not a false
possitive. All of them so far have been concluded to be false possitive
AFAIU.
--
Michal Hocko
SUSE Labs
nctionality?
--
Michal Hocko
SUSE Labs
really proposed a solution or followed up.
I will try to get back to that discussion but is there any technical
reason that prevents any conclusion or it is just stuck on a lack of
time of the participants?
--
Michal Hocko
SUSE Labs
o summarize this discussion in the changelog and
conclude why the explicit check is really good and what were other
alternatives considered.
Thanks!
> Reported-by: Qian Cai
> Cc: Alexey Dobriyan
> Cc: Naoya Horiguchi
> Cc: Andrew Morton
> Cc: Stephen Rothwell
> Cc: Michal Hoc
se a different data structure than drop the
static modifier which seems to be more of an misunderstanding than an
intention.
--
Michal Hocko
SUSE Labs
On Tue 08-10-19 15:06:13, Qian Cai wrote:
> On Tue, 2019-10-08 at 20:35 +0200, Michal Hocko wrote:
[...]
> > I fully agree that this class of lockdep splats are annoying especially
> > when they make the lockdep unusable but please discuss this with lockdep
> > maintainers
On Tue 08-10-19 12:08:37, Qian Cai wrote:
> On Tue, 2019-10-08 at 14:56 +0200, Christian Borntraeger wrote:
> > Adding Peter Oberparleiter.
> > Peter, can you have a look?
> >
> > On 08.10.19 10:27, Michal Hocko wrote:
> > > On Tue 08-10-19 09:43:57, Petr Mla
On Tue 08-10-19 17:44:37, Kirill A. Shutemov wrote:
> On Mon, Oct 07, 2019 at 04:30:30PM +0200, Michal Hocko wrote:
> > On Mon 07-10-19 16:19:59, Vlastimil Babka wrote:
> > > On 10/2/19 10:43 AM, Michal Hocko wrote:
> > > > On Wed 02-10-19 06:16:43, Yang
zero value
for end users. But it makes no sense to make to make it printk_deferred
on grounds mentioned so far.
--
Michal Hocko
SUSE Labs
ight? So the make sure
that linux-api is on the Cc list.
And one minore note. The ifdefery is just ugly, could you just make it a
separate function with ifdef hidden inside?
--
Michal Hocko
SUSE Labs
he
actual problem. The disucssion in this thread boils down to point to
lockdep splats which are most likely false possitives and there is no
clear evidence that the is any actual deadlock as those would be clearly
identifiable if the zone->lock or any other spinlock spinlock were
participating
On Tue 08-10-19 09:06:29, Qian Cai wrote:
> On Tue, 2019-10-08 at 14:39 +0200, Michal Hocko wrote:
> > On Tue 08-10-19 08:00:43, Qian Cai wrote:
> > >
> > >
> > > > On Oct 8, 2019, at 6:39 AM, Michal Hocko wrote:
> > > >
> > > > H
On Tue 08-10-19 08:00:43, Qian Cai wrote:
>
>
> > On Oct 8, 2019, at 6:39 AM, Michal Hocko wrote:
> >
> > Have you actually triggered any real deadlock? With a zone->lock in
> > place it would be pretty clear with hard lockups detected.
>
> Yes, I did tr
On Tue 08-10-19 06:04:32, Qian Cai wrote:
>
>
> > On Oct 8, 2019, at 4:40 AM, Michal Hocko wrote:
> >
> > Does this tip point to a real deadlock or merely a class of lockdep
> > false dependencies?
>
> I lean towards it is a real deadlock given how triv
On Mon 07-10-19 14:59:02, Andrew Morton wrote:
> On Mon, 7 Oct 2019 10:16:21 +0200 Michal Hocko wrote:
>
> > On Fri 04-10-19 14:57:01, Michal Hocko wrote:
> > > On Fri 04-10-19 08:31:49, Qian Cai wrote:
> > > > Long time ago, there fixed a similar deadlock
On Mon 07-10-19 11:33:27, Qian Cai wrote:
> On Mon, 2019-10-07 at 17:12 +0200, Michal Hocko wrote:
> > On Mon 07-10-19 10:59:10, Qian Cai wrote:
> > [...]
> > > It is almost impossible to eliminate all the indirect call chains from
> > > console_sem/console_owner
On Tue 08-10-19 09:43:57, Petr Mladek wrote:
> On Mon 2019-10-07 16:49:37, Michal Hocko wrote:
> > [Cc s390 maintainers - the lockdep is
> > http://lkml.kernel.org/r/1570228005-24979-1-git-send-email-...@lca.pw
> > Petr has explained it is a false positive
> >
On Mon 07-10-19 12:03:30, Mike Kravetz wrote:
> On 10/7/19 12:55 AM, Michal Hocko wrote:
> > From: David Rientjes
> >
> > b39d0ee2632d ("mm, page_alloc: avoid expensive reclaim when compaction
> > may not succeed") has chnaged the allocator to bail out fr
up_64+0xb6/0xc0
This is an early init code again so the lockdep sounds like a false
possitive to me.
--
Michal Hocko
SUSE Labs
te_initializing;
- sclp_read_sccb = (void *) __get_free_page(GFP_ATOMIC | GFP_DMA);
- sclp_init_sccb = (void *) __get_free_page(GFP_ATOMIC | GFP_DMA);
BUG_ON(!sclp_read_sccb || !sclp_init_sccb);
/* Set up variables */
INIT_LIST_HEAD(&sclp_req_queue);
--
Michal Hocko
SUSE Labs
On Mon 07-10-19 16:19:59, Vlastimil Babka wrote:
> On 10/2/19 10:43 AM, Michal Hocko wrote:
> > On Wed 02-10-19 06:16:43, Yang Shi wrote:
> >> The commit 87eaceb3faa59b9b4d940ec9554ce251325d83fe ("mm: thp: make
> >> deferred split shrinker memcg aware") makes d
On Fri 04-10-19 17:06:13, Konstantin Khlebnikov wrote:
> On 04/10/2019 16.39, Michal Hocko wrote:
> > On Fri 04-10-19 16:32:39, Konstantin Khlebnikov wrote:
> > > On 04/10/2019 16.12, Michal Hocko wrote:
> > > > On Fri 04-10-19 16:09:22, Konstantin Khlebnikov wrot
On Mon 07-10-19 08:11:44, Qian Cai wrote:
> On Mon, 2019-10-07 at 13:37 +0200, Michal Hocko wrote:
> > On Mon 07-10-19 07:04:00, Qian Cai wrote:
> > >
> > >
> > > > On Oct 7, 2019, at 4:07 AM, Michal Hocko wrote:
> > > >
> > > >
On Mon 07-10-19 07:04:00, Qian Cai wrote:
>
>
> > On Oct 7, 2019, at 4:07 AM, Michal Hocko wrote:
> >
> > I do not think that removing the printk is the right long term solution.
> > While I do agree that removing the debugging printk __offline_isolated_pages
>
On Mon 07-10-19 11:05:53, Petr Mladek wrote:
> On Mon 2019-10-07 10:07:42, Michal Hocko wrote:
> > On Fri 04-10-19 18:26:45, Qian Cai wrote:
> > > It is unsafe to call printk() while zone->lock was held, i.e.,
> > >
> > > zone->lock --> console_lock
On Fri 04-10-19 14:57:01, Michal Hocko wrote:
> On Fri 04-10-19 08:31:49, Qian Cai wrote:
> > Long time ago, there fixed a similar deadlock in show_slab_objects()
> > [1]. However, it is apparently due to the commits like 01fb58bcba63
> > ("slab: remove synchronous sync
000513bde2c>] vprintk_emit+0x184/0x3c8
> [<513be0b4>] vprintk_default+0x44/0x50
> [<513beb60>] printk+0xa8/0xc0
> [<5158c364>] __dump_page+0x1dc/0x710
> [<5158c8c6>] dump_page+0x2e/0x58
> [<515d87c8>] has_unmovable_pages+0x2e8/0x470
> [<5167072c>] start_isolate_page_range+0x404/0x538
> [<51b96de4>] __offline_pages+0x22c/0x1338
> [<51908586>] memory_subsys_offline+0xa6/0xe8
> [<518e561e>] device_offline+0xe6/0x118
> [<51908170>] state_store+0xf0/0x110
> [<51796384>] kernfs_fop_write+0x1bc/0x270
> [<5168972e>] vfs_write+0xce/0x220
> [<51689b9a>] ksys_write+0xea/0x190
> [<51ba9990>] system_call+0xd8/0x2b4
> INFO: lockdep is turned off.
--
Michal Hocko
SUSE Labs
requests.
[mho...@suse.com: reworded changelog]
Fixes: b39d0ee2632d ("mm, page_alloc: avoid expensive reclaim when compaction
may not succeed")
Cc: Mike Kravetz
Signed-off-by: David Rientjes
Signed-off-by: Michal Hocko
---
Hi,
this has been posted by David as an RFC [1]. David d
1401 - 1500 of 6330 matches
Mail list logo
