All of lore.kernel.org
 help / color / mirror / Atom feed
From: Thomas Gleixner <tglx@linutronix.de>
To: Jan Beulich <JBeulich@suse.com>
Cc: mingo@elte.hu, linux-kernel@vger.kernel.org, hpa@zytor.com
Subject: Re: [PATCH] x86/mm: avoid premature success when changing page attributes
Date: Wed, 27 Jan 2016 11:53:50 +0100 (CET)	[thread overview]
Message-ID: <alpine.DEB.2.11.1601271147320.3886@nanos> (raw)
In-Reply-To: <56A8AD9E02000078000CB7CA@prv-mh.provo.novell.com>

On Wed, 27 Jan 2016, Jan Beulich wrote:
> >>> On 27.01.16 at 11:05, <tglx@linutronix.de> wrote:
> > On Mon, 25 Jan 2016, Jan Beulich wrote:
> > 
> > Sorry, that changelog does not make any sense.
> > 
> >> Since successful return from __cpa_process_fault() makes
> >> __change_page_attr() exit early (and successfully), its caller needs to
> > 
> > That has nothing to do with a successful return from __cpa_process_fault().
> 
> How does it not? When __change_page_attr() calls
> __cpa_process_fault() it doesn't even loot at its return value, but
> directly returns __cpa_process_fault()'s return value to its own
> caller. I.e. success of __cpa_process_fault() means success of
> __change_page_attr().

You wrote:

> >> Since successful return from __cpa_process_fault() makes
> >> __change_page_attr() exit early

This is wrong. Because it implies that a non successful return from
__cpa_process_fault() is not resulting in an early exit of
__change_page_attr().

> > __change_page_attr() always returns immediately after calling
> > __cpa_process_fault() no matter what the return code is.
> > 
> >> be instructed to continue its iteration by adjusting ->numpages.
> > 
> > And how is that instruction working?
> 
> I think some understanding of the internal working of cpa can
> be expected.

I very much know how it works as I wrote large parts of it. Still your
changelog makes no sense to me.

> The only adjustment I can see as being doable for me would be to
> invert the ordering of the description, starting with describing the
> failure scenario. That would nevertheless be with more or less the
> same wording, so I'm quite uncertain it would help (and hence be
> worth my time).

Documentation/SubmittingPatches:: 2) Describe your changes.

does apply to everyone including you. It's well worth the time because badly
written changelogs waste the time of reviewers, maintainers and people who
need to consult changelogs later on.

Thanks,

	tglx

  reply	other threads:[~2016-01-27 10:55 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-01-25 16:54 [PATCH] x86/mm: avoid premature success when changing page attributes Jan Beulich
2016-01-27 10:05 ` Thomas Gleixner
2016-01-27 10:44   ` Jan Beulich
2016-01-27 10:53     ` Thomas Gleixner [this message]
2016-01-27 11:10       ` Jan Beulich
2016-01-27 11:21       ` [PATCH v2] " Jan Beulich
2016-01-28  8:42         ` Ingo Molnar
2016-02-02  8:46           ` Jan Beulich
2016-02-09 14:30             ` Ingo Molnar
2016-02-10  9:03               ` [PATCH v3] " Jan Beulich
2016-02-25  9:45                 ` [tip:x86/mm] x86/mm: Avoid " tip-bot for Jan Beulich

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=alpine.DEB.2.11.1601271147320.3886@nanos \
    --to=tglx@linutronix.de \
    --cc=JBeulich@suse.com \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    /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.