All of lore.kernel.org
 help / color / mirror / Atom feed
From: Michal Hocko <mhocko@kernel.org>
To: "Kirill A. Shutemov" <kirill@shutemov.name>
Cc: linux-mm@kvack.org
Subject: Re: VM_BUG_ON_PGFLAGS with CONFIG_DEBUG_VM_PGFLAGS=n
Date: Wed, 5 Sep 2018 15:46:07 +0200	[thread overview]
Message-ID: <20180905134607.GF14951@dhcp22.suse.cz> (raw)
In-Reply-To: <20180905132613.gqc3ifkgiybnhc3m@kshutemo-mobl1>

On Wed 05-09-18 16:26:13, Kirill A. Shutemov wrote:
> On Wed, Sep 05, 2018 at 08:48:00AM +0200, Michal Hocko wrote:
> > Hi Kirill,
> > while looking at something unrelated I have stumbled over %subj and I
> > simply do not understand how BUILD_BUG_ON_INVALID is supposed to work
> > for page flags checks which are dynamic by definition.
> > BUILD_BUG_ON_INVALID is noop without any side effects unless __CHECKER__
> > is enabled when it evaluates to ((void )(sizeof((__force long )(e)))).
> 
> You've read it backwards. BUILD_BUG_ON_INVALID() is not if __CHECKER__ is
> enabled.

Well, that is what I meant I just reworded the text and kept the
negation...

> > How is this supposed to work? Am I just confused or BUILD_BUG_ON_INVALID
> > is simply not a good fit here and all you wanted is the no side-effect
> > nature of it?
> 
> Without CONFIG_DEBUG_VM_PGFLAGS() is basically nop. BUILD_BUG_ON_INVALID()
> here is fance version of nop that check that what you've wrote inside
> parses fine. That's it.

OK, I see it. I somehow implied that this is similar to BUILD_BUG_ON. If
this is about pure expression correctness then it finally makes some
sense to me.

Thanks!
-- 
Michal Hocko
SUSE Labs

      reply	other threads:[~2018-09-05 13:46 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-09-05  6:48 VM_BUG_ON_PGFLAGS with CONFIG_DEBUG_VM_PGFLAGS=n Michal Hocko
2018-09-05 13:26 ` Kirill A. Shutemov
2018-09-05 13:46   ` Michal Hocko [this message]

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=20180905134607.GF14951@dhcp22.suse.cz \
    --to=mhocko@kernel.org \
    --cc=kirill@shutemov.name \
    --cc=linux-mm@kvack.org \
    /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.