All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@linux-foundation.org>
To: Michal Hocko <mhocko@suse.com>
Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>,
	kirill@shutemov.name, linux-mm@kvack.org,
	kirill.shutemov@linux.intel.com
Subject: Re: [PATCH v2] mm: Warn on lock_page() from reclaim context.
Date: Tue, 20 Mar 2018 10:50:09 -0700	[thread overview]
Message-ID: <20180320105009.2a7055bd3dfefe750d01cd38@linux-foundation.org> (raw)
In-Reply-To: <20180320084445.GE23100@dhcp22.suse.cz>

On Tue, 20 Mar 2018 09:44:45 +0100 Michal Hocko <mhocko@suse.com> wrote:

> > And I wonder if overloading CONFIG_PROVE_LOCKING is appropriate here. 
> > CONFIG_PROVE_LOCKING is a high-level thing under which a whole bunch of
> > different debugging options may exist.
> 
> Yes but it is meant to catch locking issues in general so I think doing
> this check under the same config makes sense.
> 
> > I guess we should add a new config item under PROVE_LOCKING,
> 
> I am not convinced a new config is really worth it. We have way too many
> already and PROVE_LOCKING sounds like a good fit to me.

I few scruffy misc sites have used PROVE_LOCKING in this fashion, but
they really shouldn't have.  It means that if anyone wants to enable,
say, "Locking API boot-time self-tests" then they must enable
PROVE_LOCKING, so they accidentally get this feature as well.

  reply	other threads:[~2018-03-20 17:50 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-03-17 14:11 [PATCH] mm: Warn on lock_page() from reclaim context Tetsuo Handa
2018-03-17 15:54 ` Kirill A. Shutemov
2018-03-18  1:22   ` [PATCH v2] " Tetsuo Handa
2018-03-18  8:55     ` Kirill A. Shutemov
2018-03-19  9:04     ` Michal Hocko
2018-03-19 10:14       ` Kirill A. Shutemov
2018-03-19 10:33         ` Michal Hocko
2018-03-19 10:45           ` Kirill A. Shutemov
2018-03-19 10:55             ` Michal Hocko
2018-03-19 12:04               ` Tetsuo Handa
2018-03-19 22:08     ` Andrew Morton
2018-03-20  8:44       ` Michal Hocko
2018-03-20 17:50         ` Andrew Morton [this message]
2018-03-29  7:04     ` [lkp-robot] [mm] 67ffc906f8: WARNING:at_mm/filemap.c:#__warn_lock_page_from_reclaim_context kernel test robot
2018-03-29  7:04       ` kernel test robot
2018-03-29 10:32       ` [lkp-robot] [mm] 67ffc906f8:WARNING:at_mm/filemap.c:#__warn_lock_page_from_reclaim_context Tetsuo Handa
2018-03-29 10:32         ` Tetsuo Handa

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20180320105009.2a7055bd3dfefe750d01cd38@linux-foundation.org \
    --to=akpm@linux-foundation.org \
    --cc=kirill.shutemov@linux.intel.com \
    --cc=kirill@shutemov.name \
    --cc=linux-mm@kvack.org \
    --cc=mhocko@suse.com \
    --cc=penguin-kernel@I-love.SAKURA.ne.jp \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.