From: Thomas Gleixner <tglx@linutronix.de>
To: Alex Belits <abelits@marvell.com>,
"frederic\@kernel.org" <frederic@kernel.org>,
"rostedt\@goodmis.org" <rostedt@goodmis.org>
Cc: Prasun Kapoor <pkapoor@marvell.com>,
"mingo\@kernel.org" <mingo@kernel.org>,
"davem\@davemloft.net" <davem@davemloft.net>,
"linux-api\@vger.kernel.org" <linux-api@vger.kernel.org>,
"peterz\@infradead.org" <peterz@infradead.org>,
"linux-arch\@vger.kernel.org" <linux-arch@vger.kernel.org>,
"catalin.marinas\@arm.com" <catalin.marinas@arm.com>,
"will\@kernel.org" <will@kernel.org>,
"linux-arm-kernel\@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
"linux-kernel\@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"netdev\@vger.kernel.org" <netdev@vger.kernel.org>
Subject: Re: [PATCH v4 00/13] "Task_isolation" mode
Date: Thu, 23 Jul 2020 15:17:04 +0200 [thread overview]
Message-ID: <87imeextf3.fsf@nanos.tec.linutronix.de> (raw)
In-Reply-To: <04be044c1bcd76b7438b7563edc35383417f12c8.camel@marvell.com>
Alex,
Alex Belits <abelits@marvell.com> writes:
> This is a new version of task isolation implementation. Previous version is at
> https://lore.kernel.org/lkml/07c25c246c55012981ec0296eee23e68c719333a.camel@marvell.com/
>
> Mostly this covers race conditions prevention on breaking isolation. Early after kernel entry,
> task_isolation_enter() is called to update flags visible to other CPU cores and to perform
> synchronization if necessary. Before this call only "safe" operations happen, as long as
> CONFIG_TRACE_IRQFLAGS is not enabled.
Without going into details of the individual patches, let me give you a
high level view of this series:
1) Entry code handling:
That's completely broken vs. the careful ordering and instrumentation
protection of the entry code. You can't just slap stuff randomly
into places which you think are safe w/o actually trying to understand
why this code is ordered in the way it is.
This clearly was never built and tested with any of the relevant
debug options enabled. Both build and boot would have told you.
2) Instruction synchronization
Trying to do instruction synchronization delayed is a clear recipe
for hard to diagnose failures. Just because it blew not up in your
face does not make it correct in any way. It's broken by design and
violates _all_ rules of safe instruction patching and introduces a
complete trainwreck in x86 NMI processing.
If you really think that this is correct, then please have at least
the courtesy to come up with a detailed and precise argumentation
why this is a valid approach.
While writing that up you surely will find out why it is not.
3) Debug calls
Sprinkling debug calls around the codebase randomly is not going to
happen. That's an unmaintainable mess.
Aside of that none of these dmesg based debug things is necessary.
This can simply be monitored with tracing.
4) Tons of undocumented smp barriers
See Documentation/process/submit-checklist.rst #25
5) Signal on page fault
Why is this a magic task isolation feature instead of making it
something which can be used in general? There are other legit
reasons why a task might want a notification about an unexpected
(resolved) page fault.
6) Coding style violations all over the place
Using checkpatch.pl is mandatory
7) Not Cc'ed maintainers
While your Cc list is huge, you completely fail to Cc the relevant
maintainers of various files and subsystems as requested in
Documentation/process/*
8) Changelogs
Most of the changelogs have something along the lines:
'task isolation does not want X, so do Y to make it not do X'
without any single line of explanation why this approach was chosen
and why it is correct under all circumstances and cannot have nasty
side effects.
It's not the job of the reviewers/maintainers to figure this out.
Please come up with a coherent design first and then address the
identified issues one by one in a way which is palatable and reviewable.
Throwing a big pile of completely undocumented 'works for me' mess over
the fence does not get you anywhere, not even to the point that people
are willing to review it in detail.
Thanks,
tglx
next prev parent reply other threads:[~2020-07-23 13:17 UTC|newest]
Thread overview: 49+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-07-22 14:44 [PATCH v4 00/13] "Task_isolation" mode Alex Belits
2020-07-22 14:47 ` [PATCH v4 01/13] task_isolation: vmstat: add quiet_vmstat_sync function Alex Belits
2020-07-22 14:48 ` [PATCH v4 02/13] task_isolation: vmstat: add vmstat_idle function Alex Belits
2020-07-22 14:49 ` [PATCH v4 03/13] task_isolation: userspace hard isolation from kernel Alex Belits
2020-10-01 13:56 ` Frederic Weisbecker
2020-10-04 14:44 ` [EXT] " Alex Belits
2020-10-04 23:14 ` Frederic Weisbecker
2020-10-05 18:52 ` Nitesh Narayan Lal
2020-10-06 10:35 ` Frederic Weisbecker
2020-10-17 1:13 ` Alex Belits
2020-10-17 1:08 ` Alex Belits
2020-10-17 16:08 ` Thomas Gleixner
2020-10-17 16:15 ` Alex Belits
2020-10-17 20:03 ` Thomas Gleixner
2020-10-06 11:01 ` Alex Belits
2020-10-01 14:40 ` Frederic Weisbecker
2020-10-04 15:01 ` [EXT] " Alex Belits
2020-07-22 14:51 ` [PATCH v4 04/13] task_isolation: Add task isolation hooks to arch-independent code Alex Belits
2020-07-22 14:51 ` [PATCH v4 05/13] task_isolation: Add xen-specific hook Alex Belits
2020-07-22 14:53 ` [PATCH 06/13] task_isolation: Add driver-specific hooks Alex Belits
2020-07-22 14:54 ` [PATCH v4 07/13] task_isolation: arch/x86: enable task isolation functionality Alex Belits
2020-07-22 14:55 ` [PATCH 08/13] task_isolation: arch/arm64: " Alex Belits
2020-07-22 14:56 ` [PATCH v4 09/13] task_isolation: arch/arm: " Alex Belits
2020-07-22 14:57 ` [PATCH v4 10/13] task_isolation: don't interrupt CPUs with tick_nohz_full_kick_cpu() Alex Belits
2020-10-01 14:44 ` Frederic Weisbecker
2020-10-04 15:22 ` [EXT] " Alex Belits
2020-10-06 21:41 ` Frederic Weisbecker
2020-10-17 0:17 ` Alex Belits
2020-07-22 14:58 ` [PATCH v4 11/13] task_isolation: net: don't flush backlog on CPUs running isolated tasks Alex Belits
2020-10-01 14:47 ` Frederic Weisbecker
2020-10-04 17:12 ` [EXT] " Alex Belits
2021-01-22 14:13 ` Marcelo Tosatti
2021-01-22 16:13 ` Paolo Abeni
2020-07-22 14:59 ` [PATCH v4 12/13] task_isolation: ringbuffer: don't interrupt CPUs running isolated tasks on buffer resize Alex Belits
2020-07-22 14:59 ` [PATCH 13/13] task_isolation: kick_all_cpus_sync: don't kick isolated cpus Alex Belits
2020-07-23 13:17 ` Thomas Gleixner [this message]
2020-07-23 14:26 ` [PATCH v4 00/13] "Task_isolation" mode Peter Zijlstra
2020-07-23 14:53 ` Thomas Gleixner
2020-07-23 14:29 ` Peter Zijlstra
2020-07-23 15:41 ` [EXT] " Alex Belits
2020-07-23 15:48 ` Peter Zijlstra
2020-07-23 16:19 ` Alex Belits
2020-07-23 15:18 ` Alex Belits
2020-07-23 15:49 ` Peter Zijlstra
2020-07-23 16:50 ` Alex Belits
2020-07-23 21:44 ` Thomas Gleixner
2020-07-24 3:00 ` [EXT] " Alex Belits
2020-07-24 16:08 ` Thomas Gleixner
2020-07-23 21:31 ` Thomas Gleixner
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=87imeextf3.fsf@nanos.tec.linutronix.de \
--to=tglx@linutronix.de \
--cc=abelits@marvell.com \
--cc=catalin.marinas@arm.com \
--cc=davem@davemloft.net \
--cc=frederic@kernel.org \
--cc=linux-api@vger.kernel.org \
--cc=linux-arch@vger.kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=netdev@vger.kernel.org \
--cc=peterz@infradead.org \
--cc=pkapoor@marvell.com \
--cc=rostedt@goodmis.org \
--cc=will@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).