linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Hans de Goede <hdegoede@redhat.com>
To: Borislav Petkov <bp@alien8.de>
Cc: Arvind Sankar <nivedita@alum.mit.edu>,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>, "H . Peter Anvin" <hpa@zytor.com>,
	x86@kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v4 2/2] x86/purgatory: Make sure we fail the build if purgatory.ro has missing symbols
Date: Thu, 12 Mar 2020 14:34:30 +0100	[thread overview]
Message-ID: <8af51d90-27fa-6d2a-2159-ef0a9089453a@redhat.com> (raw)
In-Reply-To: <20200312125032.GC15619@zn.tnic>

Hi,

On 3/12/20 1:50 PM, Borislav Petkov wrote:
> On Thu, Mar 12, 2020 at 12:58:24PM +0100, Hans de Goede wrote:
>> My version of this patch has already been tested this way. It is
> 
> Tested with kexec maybe but if the 0day bot keeps finding breakage, that
> ain't good enough.

Which is why I have been fixing the issues which the 0day bot finds,
but then I get complaints about reving the patch set to quickly...

>> 1. Things are already broken, my patch just exposes the brokenness
>> of some configs, it is not actually breaking things (well it breaks
>> the build, changing a silent brokenness into an obvious one).
> 
> As I already explained, that is not good enough.

Right, which as I already said is why I'm fixing those issues.

>> 2. I send out the first version of this patch on 7 October 2019, it
>> has not seen any reaction until now. So I'm sending out new versions
>> quickly now that this issue is finally getting some attention...
> 
> And that is never the right approach.

In my experience once a patch-set has a maintainers attention,
quickly fixing any issues found usually is the right approach.
Because then usually it can get merged quickly and both the maintainer
and I can move on to other stuff. I'm sorry if you are finding this
annoying.

> Maintainers are busy as hell so !urgent stuff gets to wait. Spamming
> them with more patchsets does not help - fixing stuff properly does.

I am trying to fix this properly, the reason the 0daybot is
complaining is because of pre-existing bugs, not because of issues
with my original patch.

If I was not trying to fix this properly I would have long dropped
this patch to the floor and moved on.

TBH I'm quite unhappy that I'm being "yelled" at now (or so it
feels) while all I'm doing is trying to fix a long standing issue :(

> So, to sum up: if Arvind's approach is the better one, then we should do
> that and s390 should be fixed this way too. And all tested. And we will
> remove the hurry element from it all since it has not been noticed so
> far so it is not urgent and we can take our time and fix it properly.
> 
> Ok?

No not ok, I'm doing my best to help make things better here and
in return I'm getting what feels as a bunch of negativity and that
is NOT ok!

Now as how to move forward with this, I suggest that:

1) We wait a bit to see if the 0daybot finds any more existing issues
which are exposed by my patch

2) Change my patch to check for missing symbols to use the approach
which Arvind has suggested

3) Check that "kexec -l <kernel>" + "kexec -e" still work

4) Post v6.

Does that work for you ?

Regards,

Hans


  reply	other threads:[~2020-03-12 13:34 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-11 21:45 [PATCH v4 0/2] x86/purgatory: Make sure we fail the build if purgatory.ro has missing symbols Hans de Goede
2020-03-11 21:46 ` [PATCH v4 1/2] x86/purgatory: Fix missing ftrace_likely_update symbol Hans de Goede
2020-03-11 21:46 ` [PATCH v4 2/2] x86/purgatory: Make sure we fail the build if purgatory.ro has missing symbols Hans de Goede
2020-03-12  0:10   ` Arvind Sankar
2020-03-12 11:31     ` Hans de Goede
2020-03-12 11:42       ` Borislav Petkov
2020-03-12 11:58         ` Hans de Goede
2020-03-12 12:50           ` Borislav Petkov
2020-03-12 13:34             ` Hans de Goede [this message]
2020-03-12 14:25               ` Borislav Petkov
2020-03-12 14:38                 ` Hans de Goede
2020-03-12 14:49                   ` Borislav Petkov
2020-03-12 14:57                     ` Hans de Goede
2020-03-12 15:12                       ` Borislav Petkov
2020-03-13  4:42             ` Arvind Sankar
2020-03-13  4:58               ` Arvind Sankar
2020-03-13  5:15                 ` Arvind Sankar
2020-03-16 18:52                 ` Nick Desaulniers
2020-03-13 10:47               ` Hans de Goede
2020-03-13 18:06               ` Borislav Petkov
2020-03-12 17:46     ` Hans de Goede
2020-03-12 18:23       ` Arvind Sankar

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=8af51d90-27fa-6d2a-2159-ef0a9089453a@redhat.com \
    --to=hdegoede@redhat.com \
    --cc=bp@alien8.de \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=nivedita@alum.mit.edu \
    --cc=tglx@linutronix.de \
    --cc=x86@kernel.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;
as well as URLs for NNTP newsgroup(s).