linux-mm.kvack.org archive mirror
 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 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox