* Re: [PATCH] ppc64/fadump: fix inaccurate CPU state info in vmcore generated with panic
From: Hari Bathini @ 2021-11-17 6:09 UTC (permalink / raw)
To: Nicholas Piggin, linuxppc-dev, Michael Ellerman; +Cc: mahesh, sourabhjain
In-Reply-To: <1636636120.84ownze0a9.astroid@bobo.none>
On 11/11/21 6:50 pm, Nicholas Piggin wrote:
> Excerpts from Hari Bathini's message of November 11, 2021 10:06 pm:
>>
>>
>> On 11/11/21 11:44 am, Michael Ellerman wrote:
>>> Hari Bathini <hbathini@linux.ibm.com> writes:
>>>> In panic path, fadump is triggered via a panic notifier function.
>>>> Before calling panic notifier functions, smp_send_stop() gets called,
>>>> which stops all CPUs except the panic'ing CPU. Commit 8389b37dffdc
>>>> ("powerpc: stop_this_cpu: remove the cpu from the online map.") and
>>>> again commit bab26238bbd4 ("powerpc: Offline CPU in stop_this_cpu()")
>>>> started marking CPUs as offline while stopping them. So, if a kernel
>>>> has either of the above commits, vmcore captured with fadump via panic
>>>> path would show only the panic'ing CPU as online. Sample output of
>>>> crash-utility with such vmcore:
>>>>
>>>> # crash vmlinux vmcore
>>>> ...
>>>> KERNEL: vmlinux
>>>> DUMPFILE: vmcore [PARTIAL DUMP]
>>>> CPUS: 1
>>>> DATE: Wed Nov 10 09:56:34 EST 2021
>>>> UPTIME: 00:00:42
>>>> LOAD AVERAGE: 2.27, 0.69, 0.24
>>>> TASKS: 183
>>>> NODENAME: XXXXXXXXX
>>>> RELEASE: 5.15.0+
>>>> VERSION: #974 SMP Wed Nov 10 04:18:19 CST 2021
>>>> MACHINE: ppc64le (2500 Mhz)
>>>> MEMORY: 8 GB
>>>> PANIC: "Kernel panic - not syncing: sysrq triggered crash"
>>>> PID: 3394
>>>> COMMAND: "bash"
>>>> TASK: c0000000150a5f80 [THREAD_INFO: c0000000150a5f80]
>>>> CPU: 1
>>>> STATE: TASK_RUNNING (PANIC)
>>>>
>>>> crash> p -x __cpu_online_mask
>>>> __cpu_online_mask = $1 = {
>>>> bits = {0x2, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}
>>>> }
>>>> crash>
>>>> crash>
>>>> crash> p -x __cpu_active_mask
>>>> __cpu_active_mask = $2 = {
>>>> bits = {0xff, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}
>>>> }
>>>> crash>
>>>>
>>>> While this has been the case since fadump was introduced, the issue
>>>> was not identified for two probable reasons:
>>>>
>>>> - In general, the bulk of the vmcores analyzed were from crash
>>>> due to exception.
>>>>
>>>> - The above did change since commit 8341f2f222d7 ("sysrq: Use
>>>> panic() to force a crash") started using panic() instead of
>>>> deferencing NULL pointer to force a kernel crash. But then
>>>> commit de6e5d38417e ("powerpc: smp_send_stop do not offline
>>>> stopped CPUs") stopped marking CPUs as offline till kernel
>>>> commit bab26238bbd4 ("powerpc: Offline CPU in stop_this_cpu()")
>>>> reverted that change.
>>>>
>>>> To avoid vmcore from showing only one CPU as online in panic path,
>>>> skip marking non panic'ing CPUs as offline while stopping them
>>>> during fadump crash.
>>>
>>> Is this really worth the added complexity/bug surface?
>>>
>>> Why does it matter if the vmcore shows only one CPU online?
>>
>> We lose out on backtrace/register data of non-crashing CPUs as they
>> are explicitly marked offline.
>>
>> Actually, the state of CPU resources is explicitly changed after the
>> panic though the aim of vmcore is to capture the system state at the
>> time of panic...
>>
>> Alternatively, how about moving crash_fadump() call from panic notifier
>> into panic() function explicitly, just like __crash_kexec() - before the
>> smp_send_stop() call, so as to remove dependency with smp_send_stop()
>> implementation altogether...
>
> Does the crash dump code snapshot the CPUs with send_debuggr_break? I
> can't remember the exact flow. But if it sends NMI IPIs to all other
> CPUs then maybe it could be moved before smp_send_stop, good idea.
Except for crashing CPU, snapshot of register data for all other CPUs is
collected by f/w on ibm,os-term rtas call.
>>> The comment talks about printk_safe_flush_on_panic(), and this change
>>> would presumably break that. Except that printk_safe_flush_on_panic() no
>>> longer exists.
>>>
>>> So do we need to set the CPU online here at all?
>>>
>>> ie. could we revert bab26238bbd4 ("powerpc: Offline CPU in stop_this_cpu()")
>>> now that printk_safe_flush_on_panic() no longer exists?
>>
>> Yeah, sounds like the logical thing to do but I guess, Nick would be in
>> a better position to answer this..
>
> Maybe we could look at reverting it, it would be nice. But I think it
> would be good to consider moving crash_fadump as well. There is at
OK, I will try moving crash_fadump() instead and post the patch..
Thanks
Hari
^ permalink raw reply
* [PATCH v2 2/2] powerpc/rtas: rtas_busy_delay_time() kernel-doc
From: Nathan Lynch @ 2021-11-17 6:02 UTC (permalink / raw)
To: linuxppc-dev; +Cc: tyreld, ajd, aik, cheloha, ldufour
In-Reply-To: <20211117060259.957178-1-nathanl@linux.ibm.com>
Provide API documentation for rtas_busy_delay_time(), explaining why we
return the same value for 9900 and -2.
Signed-off-by: Nathan Lynch <nathanl@linux.ibm.com>
---
arch/powerpc/kernel/rtas.c | 21 +++++++++++++++++++--
1 file changed, 19 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/kernel/rtas.c b/arch/powerpc/kernel/rtas.c
index d686834fe7f5..4cfe9f93a9cd 100644
--- a/arch/powerpc/kernel/rtas.c
+++ b/arch/powerpc/kernel/rtas.c
@@ -492,8 +492,25 @@ int rtas_call(int token, int nargs, int nret, int *outputs, ...)
}
EXPORT_SYMBOL(rtas_call);
-/* For RTAS_BUSY (-2), delay for 1 millisecond. For an extended busy status
- * code of 990n, perform the hinted delay of 10^n (last digit) milliseconds.
+/**
+ * rtas_busy_delay_time() - From an RTAS status value, calculate the
+ * suggested delay time in milliseconds.
+ *
+ * @status: a value returned from rtas_call() or similar APIs which return
+ * the status of a RTAS function call.
+ *
+ * Context: Any context.
+ *
+ * Return:
+ * * 100000 - If @status is 9905.
+ * * 10000 - If @status is 9904.
+ * * 1000 - If @status is 9903.
+ * * 100 - If @status is 9902.
+ * * 10 - If @status is 9901.
+ * * 1 - If @status is either 9900 or -2. This is "wrong" for -2, but
+ * some callers depend on this behavior, and the worst outcome
+ * is that they will delay for longer than necessary.
+ * * 0 - If @status is not a busy or extended delay value.
*/
unsigned int rtas_busy_delay_time(int status)
{
--
2.31.1
^ permalink raw reply related
* [PATCH v2 0/2] powerpc/rtas: improved busy and extended delay status handling
From: Nathan Lynch @ 2021-11-17 6:02 UTC (permalink / raw)
To: linuxppc-dev; +Cc: tyreld, ajd, aik, cheloha, ldufour
This can be considered a successor to:
https://lore.kernel.org/linuxppc-dev/20210504030358.1715034-1-nathanl@linux.ibm.com/
which tried to address both the suboptimal delay behavior as well as API
issues. This version achieves the performance improvements and leaves major
API changes for another time.
Changes since v1:
* Drop major API changes.
* Avoid division when calculating the arguments to usleep_range() (Alexey).
* Improve kernel-doc for rtas_busy_delay(), rtas_busy_delay_time().
Nathan Lynch (2):
powerpc/rtas: rtas_busy_delay() improvements
powerpc/rtas: rtas_busy_delay_time() kernel-doc
arch/powerpc/include/asm/rtas.h | 2 +-
arch/powerpc/kernel/rtas.c | 95 +++++++++++++++++++++++++++++----
2 files changed, 87 insertions(+), 10 deletions(-)
--
2.31.1
^ permalink raw reply
* [PATCH v2 1/2] powerpc/rtas: rtas_busy_delay() improvements
From: Nathan Lynch @ 2021-11-17 6:02 UTC (permalink / raw)
To: linuxppc-dev; +Cc: tyreld, ajd, aik, cheloha, ldufour
In-Reply-To: <20211117060259.957178-1-nathanl@linux.ibm.com>
Generally RTAS cannot block, and in PAPR it is required to return control
to the OS within a few tens of microseconds. In order to support operations
which may take longer to complete, many RTAS primitives can return
intermediate -2 ("busy") or 990x ("extended delay") values, which indicate
that the OS should reattempt the same call with the same arguments at some
point in the future.
Current versions of PAPR are less than clear about this, but the intended
meanings of these values in more detail are:
RTAS_BUSY (-2): RTAS has suspended a potentially long-running operation in
order to meet its latency obligation and give the OS the opportunity to
perform other work. RTAS can resume making progress as soon as the OS
reattempts the call.
RTAS_EXTENDED_DELAY_{MIN...MAX} (9900-9905): RTAS must wait for an external
event to occur or for internal contention to resolve before it can complete
the requested operation. The value encodes a non-binding hint as to roughly
how long the OS should wait before calling again, but the OS is allowed to
reattempt the call sooner or even immediately.
Linux of course must take its own CPU scheduling obligations into account
when handling these statuses; e.g. a task which receives an RTAS_BUSY
status should check whether to reschedule before it attempts the RTAS call
again to avoid starving other tasks.
rtas_busy_delay() is a helper function that "consumes" a busy or extended
delay status. Common usage:
int rc;
do {
rc = rtas_call(rtas_token("some-function"), ...);
} while (rtas_busy_delay(rc));
/* convert rc to Linux error value, etc */
If rc is a busy or extended delay status, the caller can rely on
rtas_busy_delay() to perform an appropriate sleep or reschedule and return
nonzero. Other statuses are handled normally by the caller.
The current implementation of rtas_busy_delay() both oversleeps and
overuses the CPU:
* It performs msleep() for all 990x and even when no delay is
suggested (-2), but this is understood to actually sleep for two jiffies
minimum in practice (20ms with HZ=100). 9900 (1ms) and 9901 (10ms)
appear to be the most common extended delay statuses, and the
oversleeping measurably lengthens DLPAR operations, which perform
many RTAS calls.
* It does not sleep on 990x unless need_resched() is true, causing code
like the loop above to needlessly retry, wasting CPU time.
Alter the logic to align better with the intended meanings:
* When passed RTAS_BUSY, perform cond_resched() and return without
sleeping. The caller should reattempt immediately
* Always sleep when passed an extended delay status, using usleep_range()
for precise shorter sleeps. Limit the sleep time to one second even
though there are higher architected values.
Change rtas_busy_delay()'s return type to bool to better reflect its usage,
and add kernel-doc.
rtas_busy_delay_time() is unchanged, even though it "incorrectly" returns 1
for RTAS_BUSY. There are users of that API with open-coded delay loops in
sensitive contexts that will have to be taken on an individual basis.
Brief results for addition and removal of 5GB memory on a small P9 PowerVM
partition follow. Load was generated with stress-ng --cpu N. For add,
elapsed time is greatly reduced without significant change in the number of
RTAS calls or time spent on CPU. For remove, elapsed time is modestly
reduced, with significant reductions in RTAS calls and time spent on CPU.
With no competing workload (- before, + after):
Performance counter stats for 'bash -c echo "memory add count 20" > /sys/kernel/dlpar' (10 runs):
- 1,935 probe:rtas_call # 0.003 M/sec ( +- 0.22% )
- 609.99 msec task-clock # 0.183 CPUs utilized ( +- 0.19% )
+ 1,956 probe:rtas_call # 0.003 M/sec ( +- 0.17% )
+ 618.56 msec task-clock # 0.278 CPUs utilized ( +- 0.11% )
- 3.3322 +- 0.0670 seconds time elapsed ( +- 2.01% )
+ 2.2222 +- 0.0416 seconds time elapsed ( +- 1.87% )
Performance counter stats for 'bash -c echo "memory remove count 20" > /sys/kernel/dlpar' (10 runs):
- 6,224 probe:rtas_call # 0.008 M/sec ( +- 2.57% )
- 750.36 msec task-clock # 0.190 CPUs utilized ( +- 2.01% )
+ 843 probe:rtas_call # 0.003 M/sec ( +- 0.12% )
+ 250.66 msec task-clock # 0.068 CPUs utilized ( +- 0.17% )
- 3.9394 +- 0.0890 seconds time elapsed ( +- 2.26% )
+ 3.678 +- 0.113 seconds time elapsed ( +- 3.07% )
With all CPUs 100% busy (- before, + after):
Performance counter stats for 'bash -c echo "memory add count 20" > /sys/kernel/dlpar' (10 runs):
- 2,979 probe:rtas_call # 0.003 M/sec ( +- 0.12% )
- 1,096.62 msec task-clock # 0.105 CPUs utilized ( +- 0.10% )
+ 2,981 probe:rtas_call # 0.003 M/sec ( +- 0.22% )
+ 1,095.26 msec task-clock # 0.154 CPUs utilized ( +- 0.21% )
- 10.476 +- 0.104 seconds time elapsed ( +- 1.00% )
+ 7.1124 +- 0.0865 seconds time elapsed ( +- 1.22% )
Performance counter stats for 'bash -c echo "memory remove count 20" > /sys/kernel/dlpar' (10 runs):
- 2,702 probe:rtas_call # 0.004 M/sec ( +- 4.00% )
- 722.71 msec task-clock # 0.067 CPUs utilized ( +- 2.41% )
+ 1,246 probe:rtas_call # 0.003 M/sec ( +- 0.25% )
+ 487.73 msec task-clock # 0.049 CPUs utilized ( +- 0.20% )
- 10.829 +- 0.163 seconds time elapsed ( +- 1.51% )
+ 9.9887 +- 0.0866 seconds time elapsed ( +- 0.87% )
Signed-off-by: Nathan Lynch <nathanl@linux.ibm.com>
---
Notes:
This could be considered a sequel to:
https://lore.kernel.org/linuxppc-dev/20210504030358.1715034-1-nathanl@linux.ibm.com/
which tried to address both the suboptimal delay behavior as well as naming
issues. The present change achieves the performance improvement and leaves
the matter of naming for another time.
I've incorporated Alexey's feedback from that series to avoid division when
calculating the arguments to usleep_range().
arch/powerpc/include/asm/rtas.h | 2 +-
arch/powerpc/kernel/rtas.c | 74 +++++++++++++++++++++++++++++----
2 files changed, 68 insertions(+), 8 deletions(-)
diff --git a/arch/powerpc/include/asm/rtas.h b/arch/powerpc/include/asm/rtas.h
index 9dc97d2f9d27..82e5b055fa2a 100644
--- a/arch/powerpc/include/asm/rtas.h
+++ b/arch/powerpc/include/asm/rtas.h
@@ -264,7 +264,7 @@ extern void rtas_get_rtc_time(struct rtc_time *rtc_time);
extern int rtas_set_rtc_time(struct rtc_time *rtc_time);
extern unsigned int rtas_busy_delay_time(int status);
-extern unsigned int rtas_busy_delay(int status);
+bool rtas_busy_delay(int status);
extern int early_init_dt_scan_rtas(unsigned long node,
const char *uname, int depth, void *data);
diff --git a/arch/powerpc/kernel/rtas.c b/arch/powerpc/kernel/rtas.c
index ff80bbad22a5..d686834fe7f5 100644
--- a/arch/powerpc/kernel/rtas.c
+++ b/arch/powerpc/kernel/rtas.c
@@ -513,17 +513,77 @@ unsigned int rtas_busy_delay_time(int status)
}
EXPORT_SYMBOL(rtas_busy_delay_time);
-/* For an RTAS busy status code, perform the hinted delay. */
-unsigned int rtas_busy_delay(int status)
+/**
+ * rtas_busy_delay() - helper for RTAS busy and extended delay statuses
+ *
+ * @status: a value returned from rtas_call() or similar APIs which return
+ * the status of a RTAS function call.
+ *
+ * Context: Process context. May sleep or schedule.
+ *
+ * Return:
+ * * true - @status is RTAS_BUSY or an extended delay hint. The
+ * caller may assume that the CPU has been yielded if necessary,
+ * and that an appropriate delay for @status has elapsed.
+ * Generally the caller should reattempt the RTAS call which
+ * yielded @status.
+ *
+ * * false - @status is not @RTAS_BUSY nor an extended delay hint. The
+ * caller is responsible for handling @status.
+ */
+bool rtas_busy_delay(int status)
{
unsigned int ms;
+ bool ret;
- might_sleep();
- ms = rtas_busy_delay_time(status);
- if (ms && need_resched())
- msleep(ms);
+ switch (status) {
+ case RTAS_EXTENDED_DELAY_MIN...RTAS_EXTENDED_DELAY_MAX:
+ ret = true;
+ ms = rtas_busy_delay_time(status);
+ /*
+ * The extended delay hint can be as high as 100 seconds.
+ * Surely any function returning such a status is either
+ * buggy or isn't going to be significantly slowed by us
+ * polling at 1HZ. Clamp the sleep time to one second.
+ */
+ ms = clamp(ms, 1U, 1000U);
+ /*
+ * The delay hint is an order-of-magnitude suggestion, not
+ * a minimum. It is fine, possibly even advantageous, for
+ * us to pause for less time than hinted. For small values,
+ * use usleep_range() to ensure we don't sleep much longer
+ * than actually needed.
+ *
+ * See Documentation/timers/timers-howto.rst for
+ * explanation of the threshold used here. In effect we use
+ * usleep_range() for 9900 and 9901, msleep() for
+ * 9902-9905.
+ */
+ if (ms <= 20)
+ usleep_range(ms * 100, ms * 1000);
+ else
+ msleep(ms);
+ break;
+ case RTAS_BUSY:
+ ret = true;
+ /*
+ * We should call again immediately if there's no other
+ * work to do.
+ */
+ cond_resched();
+ break;
+ default:
+ ret = false;
+ /*
+ * Not a busy or extended delay status; the caller should
+ * handle @status itself. Ensure we warn on misuses in
+ * atomic context regardless.
+ */
+ might_sleep();
+ break;
+ }
- return ms;
+ return ret;
}
EXPORT_SYMBOL(rtas_busy_delay);
--
2.31.1
^ permalink raw reply related
* Re: [PATCH 12/13] sysctl: add helper to register empty subdir
From: Luis Chamberlain @ 2021-11-17 3:30 UTC (permalink / raw)
To: Eric W. Biederman, Andrew Morton
Cc: jack, rafael, airlied, amir73il, clemens, dri-devel, joseph.qi,
sfr, mark, rdna, yzaikin, joonas.lahtinen, keescook, arnd,
intel-gfx, jani.nikula, julia.lawall, viro, rodrigo.vivi,
nixiaoming, vbabka, axboe, tytso, gregkh, linux-kernel, daniel,
akpm, linuxppc-dev, ocfs2-devel, jlbec
In-Reply-To: <878shasxkp.fsf@x220.int.ebiederm.org>
On Fri, May 29, 2020 at 08:03:02AM -0500, Eric W. Biederman wrote:
> Luis Chamberlain <mcgrof@kernel.org> writes:
>
> > The way to create a subdirectory from the base set of directories
> > is a bit obscure, so provide a helper which makes this clear, and
> > also helps remove boiler plate code required to do this work.
>
> I agreee calling:
> register_sysctl("fs/binfmt_misc", sysctl_mount_point)
> is a bit obscure but if you are going to make a wrapper
> please make it the trivial one liner above.
>
> Say something that looks like:
> struct sysctl_header *register_sysctl_mount_point(const char *path)
> {
> return register_sysctl(path, sysctl_mount_point);
> }
>
> And yes please talk about a mount point and not an empty dir, as these
> are permanently empty directories to serve as mount points. There are
> some subtle but important permission checks this allows in the case of
> unprivileged mounts.
>
> Further code like this belong in proc_sysctl.c next to all of the code
> it is related to so that it is easier to see how to refactor the code if
> necessary.
Alrighty, it's been a while since this kernel/sysctl.c kitchen sink
cleanup... so it's time to respin this now that the merge window is
open. I already rebased patches, addressed all input and now just
waiting to fix any compilation errors. I'm going to split the patches
up into real small sets so to ensure we just get this through becauase
getting this in otherwise is going to be hard.
I'd appreciate folk's review once the patches start going out. I think
a hard part will be deciding what tree this should got through.
Luis
^ permalink raw reply
* Re: [RFC PATCH 0/3] Use pageblock_order for cma and alloc_contig_range alignment.
From: Zi Yan @ 2021-11-17 3:04 UTC (permalink / raw)
To: David Hildenbrand
Cc: linuxppc-dev, linux-kernel, virtualization, linux-mm, iommu,
Robin Murphy, Christoph Hellwig, Marek Szyprowski
In-Reply-To: <d19fb078-cb9b-f60f-e310-fdeea1b947d2@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 10499 bytes --]
On 16 Nov 2021, at 3:58, David Hildenbrand wrote:
> On 15.11.21 20:37, Zi Yan wrote:
>> From: Zi Yan <ziy@nvidia.com>
>>
>> Hi David,
>
> Hi,
>
> thanks for looking into this.
>
>>
>> You suggested to make alloc_contig_range() deal with pageblock_order instead of
>> MAX_ORDER - 1 and get rid of MAX_ORDER - 1 dependency in virtio_mem[1]. This
>> patchset is my attempt to achieve that. Please take a look and let me know if
>> I am doing it correctly or not.
>>
>> From what my understanding, cma required alignment of
>> max(MAX_ORDER - 1, pageblock_order), because when MIGRATE_CMA was introduced,
>> __free_one_page() does not prevent merging two different pageblocks, when
>> MAX_ORDER - 1 > pageblock_order. But current __free_one_page() implementation
>> does prevent that. It should be OK to just align cma to pageblock_order.
>> alloc_contig_range() relies on MIGRATE_CMA to get free pages, so it can use
>> pageblock_order as alignment too.
>
> I wonder if that's sufficient. Especially the outer_start logic in
> alloc_contig_range() might be problematic. There are some ugly corner
> cases with free pages/allocations spanning multiple pageblocks and we
> only isolated a single pageblock.
Thank you a lot for writing the list of these corner cases. They are
very helpful!
>
>
> Regarding CMA, we have to keep the following cases working:
>
> a) Different pageblock types (MIGRATE_CMA and !MIGRATE_CMA) in MAX_ORDER
> - 1 page:
> [ MAX_ ORDER - 1 ]
> [ pageblock 0 | pageblock 1]
>
> Assume either pageblock 0 is MIGRATE_CMA or pageblock 1 is MIGRATE_CMA,
> but not both. We have to make sure alloc_contig_range() keeps working
> correctly. This should be the case even with your change, as we won't
> merging pages accross differing migratetypes.
Yes.
>
> b) Migrating/freeing a MAX_ ORDER - 1 page while partially isolated:
> [ MAX_ ORDER - 1 ]
> [ pageblock 0 | pageblock 1]
>
> Assume both are MIGRATE_CMA. Assume we want to either allocate from
> pageblock 0 or pageblock 1. Especially, assume we want to allocate from
> pageblock 1. While we would isolate pageblock 1, we wouldn't isolate
> pageblock 0.
>
> What happens if we either have a free page spanning the MAX_ORDER - 1
> range already OR if we have to migrate a MAX_ORDER - 1 page, resulting
> in a free MAX_ORDER - 1 page of which only the second pageblock is
> isolated? We would end up essentially freeing a page that has mixed
> pageblocks, essentially placing it in !MIGRATE_ISOLATE free lists ... I
> might be wrong but I have the feeling that this would be problematic.
>
This could happen when start_isolate_page_range() stumbles upon a compound
page with order >= pageblock_order or a free page with order >=
pageblock_order, but should not. start_isolate_page_range() should check
the actual page size, either compound page size or free page size, and set
the migratetype across pageblocks if the page is bigger than pageblock size.
More precisely set_migratetype_isolate() should do that.
> c) Concurrent allocations:
> [ MAX_ ORDER - 1 ]
> [ pageblock 0 | pageblock 1]
>
> Assume b) but we have two concurrent CMA allocations to pageblock 0 and
> pageblock 1, which would now be possible as start_isolate_page_range()
> isolate would succeed on both.
Two isolations will be serialized by the zone lock taken by
set_migratetype_isolate(), so the concurrent allocation would not be a problem.
If it is a MAX_ORDER-1 free page, the first comer should split it and only
isolate one of the pageblock then second one can isolate the other pageblock.
If it is a MAX_ORDER-1 compound page, the first comer should isolate both
pageblocks, then the second one would fail. WDYT?
In sum, it seems to me that the issue is page isolation code only sees
pageblock without check the actual page. When there are multiple pageblocks
belonging to one page, the problem appears. This should be fixed.
>
>
> Regarding virtio-mem, we care about the following cases:
>
> a) Allocating parts from completely movable MAX_ ORDER - 1 page:
> [ MAX_ ORDER - 1 ]
> [ pageblock 0 | pageblock 1]
>
> Assume pageblock 0 and pageblock 1 are either free or contain only
> movable pages. Assume we allocated pageblock 0. We have to make sure we
> can allocate pageblock 1. The other way around, assume we allocated
> pageblock 1, we have to make sure we can allocate pageblock 0.
>
> Free pages spanning both pageblocks might be problematic.
Can you elaborate a bit? If either of pageblock 0 and 1 is used by
virtio-mem, why do we care the other? If pageblock 0 and 1 belong to
the same page (either free or compound), they should have the same
migratetype. If we want to just allocate one of them, we can split
the free page or migrate the compound page then split the remaining
free page.
>
> b) Allocate parts of partially movable MAX_ ORDER - 1 page:
> [ MAX_ ORDER - 1 ]
> [ pageblock 0 | pageblock 1]
>
> Assume pageblock 0 contains unmovable data but pageblock 1 not: we have
> to make sure we can allocate pageblock 1. Similarly, assume pageblock 1
> contains unmovable data but pageblock 0 no: we have to make sure we can
> allocate pageblock 1. has_unmovable_pages() might allow for that.
>
> But, we want to fail early in case we want to allocate a single
> pageblock but it contains unmovable data. This could be either directly
> or indirectly.
>
> If we have an unmovable (compound) MAX_ ORDER - 1 and we'd try isolating
> pageblock 1, has_unmovable_pages() would always return "false" because
> we'd simply be skiping over any tail pages, and not detect the
> un-movability.
OK. It seems to me that has_unmovable_pages() needs to be fixed to handle
such a situation.
>
> c) Migrating/freeing a MAX_ ORDER - 1 page while partially isolated:
>
> Same concern as for CMA b)
>
>
> So the biggest concern I have is dealing with migrating/freeing >
> pageblock_order pages while only having isolated a single pageblock.
I agree. I think isolation code needs to be aware of >pageblock_order
pages and act accordingly. If it is a free page, split the page to
avoid isolating a subset of the page. If it is a compound page, either
fail the isolation or isolate the entire compound page instead.
>
>>
>> In terms of virtio_mem, if I understand correctly, it relies on
>> alloc_contig_range() to obtain contiguous free pages and offlines them to reduce
>> guest memory size. As the result of alloc_contig_range() alignment change,
>> virtio_mem should be able to just align PFNs to pageblock_order.
>
> For virtio-mem it will most probably be desirable to first try
> allocating the MAX_ORDER -1 range if possible and then fallback to
> pageblock_order. But that's an additional change on top in virtio-mem code.
>
Just to understand the motivation, is this because MAX_ORDER-1 range
would be faster than pageblock_order? What if MAX_ORDER-1 goes beyond
a memory section size (like my WIP patchset to increase MAX_ORDER
beyond the memory section size)? virtio-mem could first try PAGES_PER_SECTION,
then fall back to pageblock_order, right?
>
>
> My take to teach alloc_contig_range() to properly handle would be the
> following:
>
> a) Convert MIGRATE_ISOLATE into a separate pageblock flag
>
> We would want to convert MIGRATE_ISOLATE into a separate pageblock
> flags, such that when we isolate a page block we preserve the original
> migratetype. While start_isolate_page_range() would set that bit,
> undo_isolate_page_range() would simply clear that bit. The buddy would
> use a single MIGRATE_ISOLATE queue as is: the original migratetype is
> only used for restoring the correct migratetype. This would allow for
> restoring e.g., MIGRATE_UNMOVABLE after isolating an unmovable pageblock
> (below) and not simply setting all such pageblocks to MIGRATE_MOVABLE
> when un-isolating.
>
> Ideally, we'd get rid of the "migratetype" parameter for
> alloc_contig_range(). However, even with the above change we have to
> make sure that memory offlining and ordinary alloc_contig_range() users
> will fail on MIGRATE_CMA pageblocks (has_unmovable_page() checks that as
> of today). We could achieve that differently, though (e.g., bool
> cma_alloc parameter instead).
This might need to be done in a separate patch, since pageblock bits require
to be word aligned and it is 4 now. To convert MIGRATE_ISOLATE to a separate
bit, either NR_PAGEBLOCK_BITS needs to be increased to 8 or a separate
isolation bitmap array needs to be allocated. Or the migratetype information
can be stored temporarily during isolation process. I can look into it later.
>
>
> b) Allow isolating pageblocks with unmovable pages
>
> We'd pass the actual range of interest to start_isolate_page_range() and
> rework the code to check has_unmovable_pages() only on the range of
> interest, but considering overlapping larger allocations. E.g., if we
> stumble over a compound page, lookup the head an test if that page is
> movable/unmovable.
This is an optimization to reduce isolation failure rate, right? This only
applies to the pageblocks at the beginning and the end of a range of interest.
>
> c) Change alloc_contig_range() to not "extend" the range of interest to
> include pageblock of different type. Assume we're isolating a
> MIGRATE_CMA pageblock, only isolate a neighboring MIGRATE_CMA pageblock,
> not other pageblocks.
But alloc_contig_range() would return these extended pageblocks at the end.
And if pageblock migratetype can be preserved during isolation (item (a) above),
this would not be a problem, right?
>
>
> So we'd keep isolating complete MAX_ORDER - 1 pages unless c) prevents
> it. We'd allow isolating even pageblocks that contain unmovable pages on
> ZONE_NORMAL, and check via has_unmovable_pages() only if the range of
> interest contains unmovable pages, not the whole MAX_ORDER -1 range or
> even the whole pageblock. We'd not silently overwrite the pageblock type
> when restoring but instead restore the old migratetype.
>
I assume MAX_ORDER - 1 is an optimization for faster isolation speed.
If MAX_ORDER goes beyond a memory section size, I guess PAGES_PER_SECTION
is what you want, right? FYI, I am preparing a follow-up patch to replace
any MAX_ORDER use that is intended to indicate maximum physically contiguous
size with a new variable, MAX_PHYS_CONTIG_ORDER, which is PFN_SECTION_SHIFT
when SPARSEMEM and MAX_ORDER when FLATMEM. I would replace MAX_ORDER here
with the new variable.
--
Best Regards,
Yan, Zi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 854 bytes --]
^ permalink raw reply
* Re: [PATCH] powerpc/pseries: delete scanlog
From: Nathan Lynch @ 2021-11-17 2:48 UTC (permalink / raw)
To: linuxppc-dev; +Cc: tyreld
In-Reply-To: <20210920173203.1800475-1-nathanl@linux.ibm.com>
Nathan Lynch <nathanl@linux.ibm.com> writes:
> Remove the pseries scanlog driver.
>
> This code supports functions from Power4-era servers that are not present
> on targets currently supported by arch/powerpc. System manuals from this
> time have this description:
>
> Scan Dump data is a set of chip data that the service processor gathers
> after a system malfunction. It consists of chip scan rings, chip trace
> arrays, and Scan COM (SCOM) registers. This data is stored in the
> scan-log partition of the system’s Nonvolatile Random Access
> Memory (NVRAM).
>
> PowerVM partition firmware development doesn't recognize the associated
> function call or property, and they don't see any references to them in
> their codebase. It seems to have been specific to non-virtualized
> pseries.
Just bumping this to see if there are any objections.
^ permalink raw reply
* Re: Build regressions/improvements in v5.16-rc1
From: Nick Terrell @ 2021-11-17 2:19 UTC (permalink / raw)
To: Randy Dunlap
Cc: Peter Zijlstra, linux-pci, DRI Development,
open list:BROADCOM NVRAM DRIVER, James E.J. Bottomley,
Andrey Ryabinin, Stan Skowronek, Herbert Xu, Helge Deller,
kasan-dev, Sergio Paracuellos, Geert Uytterhoeven,
Anton Altaparmakov, linux-arm-msm, open list:GPIO SUBSYSTEM,
Joey Gouly, André Almeida, Linux ARM, Thomas Bogendoerfer,
Parisc List, linux-ntfs-dev@lists.sourceforge.net, Hector Martin,
Linux Kernel Mailing List, Rob Clark, Linux Crypto Mailing List,
linuxppc-dev
In-Reply-To: <78b2d093-e06c-ba04-9890-69f948bfb937@infradead.org>
> On Nov 16, 2021, at 6:05 PM, Randy Dunlap <rdunlap@infradead.org> wrote:
>
> On 11/16/21 5:59 PM, Nick Terrell wrote:
>>> On Nov 15, 2021, at 8:44 AM, Helge Deller <deller@gmx.de> wrote:
>>>
>>> On 11/15/21 17:12, Geert Uytterhoeven wrote:
>>>> On Mon, Nov 15, 2021 at 4:54 PM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
>>>>> Below is the list of build error/warning regressions/improvements in
>>>>> v5.16-rc1[1] compared to v5.15[2].
>>>>>
>>>>> Summarized:
>>>>> - build errors: +20/-13
>>>>> - build warnings: +3/-28
>>>>>
>>>>> Happy fixing! ;-)
>>>>>
>>>>> Thanks to the linux-next team for providing the build service.
>>>>>
>>>>> [1] http://kisskb.ellerman.id.au/kisskb/branch/linus/head/fa55b7dcdc43c1aa1ba12bca9d2dd4318c2a0dbf/ (all 90 configs)
>>>>> [2] http://kisskb.ellerman.id.au/kisskb/branch/linus/head/8bb7eca972ad531c9b149c0a51ab43a417385813/ (all 90 configs)
>>>>>
>>>>>
>>>>> *** ERRORS ***
>>>>>
>>>>> 20 error regressions:
>>>>> + /kisskb/src/arch/parisc/include/asm/jump_label.h: error: expected ':' before '__stringify': => 33:4, 18:4
>>>>> + /kisskb/src/arch/parisc/include/asm/jump_label.h: error: label 'l_yes' defined but not used [-Werror=unused-label]: => 38:1, 23:1
>>>>
>>>> due to static_branch_likely() in crypto/api.c
>>>>
>>>> parisc-allmodconfig
>>>
>>> fixed now in the parisc for-next git tree.
>>>
>>>
>>>>> + /kisskb/src/drivers/gpu/drm/msm/msm_drv.h: error: "COND" redefined [-Werror]: => 531
>>>>> + /kisskb/src/lib/zstd/compress/zstd_double_fast.c: error: the frame size of 3252 bytes is larger than 1536 bytes [-Werror=frame-larger-than=]: => 47:1
>>>>> + /kisskb/src/lib/zstd/compress/zstd_double_fast.c: error: the frame size of 3360 bytes is larger than 1536 bytes [-Werror=frame-larger-than=]: => 499:1
>>>>> + /kisskb/src/lib/zstd/compress/zstd_double_fast.c: error: the frame size of 5344 bytes is larger than 1536 bytes [-Werror=frame-larger-than=]: => 334:1
>>>>> + /kisskb/src/lib/zstd/compress/zstd_double_fast.c: error: the frame size of 5380 bytes is larger than 1536 bytes [-Werror=frame-larger-than=]: => 354:1
>>>>> + /kisskb/src/lib/zstd/compress/zstd_fast.c: error: the frame size of 1824 bytes is larger than 1536 bytes [-Werror=frame-larger-than=]: => 372:1
>>>>> + /kisskb/src/lib/zstd/compress/zstd_fast.c: error: the frame size of 2224 bytes is larger than 1536 bytes [-Werror=frame-larger-than=]: => 204:1
>>>>> + /kisskb/src/lib/zstd/compress/zstd_fast.c: error: the frame size of 3800 bytes is larger than 1536 bytes [-Werror=frame-larger-than=]: => 476:1
>>>>
>>>> parisc-allmodconfig
>>>
>>> parisc needs much bigger frame sizes, so I'm not astonished here.
>>> During the v5.15 cycl I increased it to 1536 (from 1280), so I'm simply tempted to
>>> increase it this time to 4096, unless someone has a better idea....
>> This patch set should fix the zstd stack size warnings [0]. I’ve
>> verified the fix using the same tooling: gcc-8-hppa-linux-gnu.
>> I’ll send the PR to Linus tomorrow. I’ve been informed that it
>> isn't strictly necessary to send the patches to the mailing list
>> for bug fixes, but its already done, so I’ll wait and see if there
>> is any feedback.
>
> IMO several (or many more) people would disagree with that.
>
> "strictly?" OK, it's probably possible that almost any patch
> could be merged without being on a mailing list, but it's not
> desirable (except in the case of "security" patches).
Good to know! Thanks for the advice, I wasn’t really sure what
the best practice is for sending patches to your own tree, as I
didn't see anything about it in the maintainer guide.
Thanks,
Nick Terrell
> --
> ~Randy
^ permalink raw reply
* Re: Build regressions/improvements in v5.16-rc1
From: Randy Dunlap @ 2021-11-17 2:05 UTC (permalink / raw)
To: Nick Terrell, Helge Deller
Cc: Peter Zijlstra, linux-pci, DRI Development,
open list:BROADCOM NVRAM DRIVER, James E.J. Bottomley,
Andrey Ryabinin, Stan Skowronek, Herbert Xu, kasan-dev,
Sergio Paracuellos, Geert Uytterhoeven, Anton Altaparmakov,
linux-arm-msm, open list:GPIO SUBSYSTEM, Joey Gouly,
André Almeida, Linux ARM, Thomas Bogendoerfer, Parisc List,
linux-ntfs-dev@lists.sourceforge.net, Hector Martin,
Linux Kernel Mailing List, Rob Clark, Linux Crypto Mailing List,
linuxppc-dev
In-Reply-To: <480CE37B-FE60-44EE-B9D2-59A88FDFE809@fb.com>
On 11/16/21 5:59 PM, Nick Terrell wrote:
>
>
>> On Nov 15, 2021, at 8:44 AM, Helge Deller <deller@gmx.de> wrote:
>>
>> On 11/15/21 17:12, Geert Uytterhoeven wrote:
>>> On Mon, Nov 15, 2021 at 4:54 PM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
>>>> Below is the list of build error/warning regressions/improvements in
>>>> v5.16-rc1[1] compared to v5.15[2].
>>>>
>>>> Summarized:
>>>> - build errors: +20/-13
>>>> - build warnings: +3/-28
>>>>
>>>> Happy fixing! ;-)
>>>>
>>>> Thanks to the linux-next team for providing the build service.
>>>>
>>>> [1] http://kisskb.ellerman.id.au/kisskb/branch/linus/head/fa55b7dcdc43c1aa1ba12bca9d2dd4318c2a0dbf/ (all 90 configs)
>>>> [2] http://kisskb.ellerman.id.au/kisskb/branch/linus/head/8bb7eca972ad531c9b149c0a51ab43a417385813/ (all 90 configs)
>>>>
>>>>
>>>> *** ERRORS ***
>>>>
>>>> 20 error regressions:
>>>> + /kisskb/src/arch/parisc/include/asm/jump_label.h: error: expected ':' before '__stringify': => 33:4, 18:4
>>>> + /kisskb/src/arch/parisc/include/asm/jump_label.h: error: label 'l_yes' defined but not used [-Werror=unused-label]: => 38:1, 23:1
>>>
>>> due to static_branch_likely() in crypto/api.c
>>>
>>> parisc-allmodconfig
>>
>> fixed now in the parisc for-next git tree.
>>
>>
>>>> + /kisskb/src/drivers/gpu/drm/msm/msm_drv.h: error: "COND" redefined [-Werror]: => 531
>>>> + /kisskb/src/lib/zstd/compress/zstd_double_fast.c: error: the frame size of 3252 bytes is larger than 1536 bytes [-Werror=frame-larger-than=]: => 47:1
>>>> + /kisskb/src/lib/zstd/compress/zstd_double_fast.c: error: the frame size of 3360 bytes is larger than 1536 bytes [-Werror=frame-larger-than=]: => 499:1
>>>> + /kisskb/src/lib/zstd/compress/zstd_double_fast.c: error: the frame size of 5344 bytes is larger than 1536 bytes [-Werror=frame-larger-than=]: => 334:1
>>>> + /kisskb/src/lib/zstd/compress/zstd_double_fast.c: error: the frame size of 5380 bytes is larger than 1536 bytes [-Werror=frame-larger-than=]: => 354:1
>>>> + /kisskb/src/lib/zstd/compress/zstd_fast.c: error: the frame size of 1824 bytes is larger than 1536 bytes [-Werror=frame-larger-than=]: => 372:1
>>>> + /kisskb/src/lib/zstd/compress/zstd_fast.c: error: the frame size of 2224 bytes is larger than 1536 bytes [-Werror=frame-larger-than=]: => 204:1
>>>> + /kisskb/src/lib/zstd/compress/zstd_fast.c: error: the frame size of 3800 bytes is larger than 1536 bytes [-Werror=frame-larger-than=]: => 476:1
>>>
>>> parisc-allmodconfig
>>
>> parisc needs much bigger frame sizes, so I'm not astonished here.
>> During the v5.15 cycl I increased it to 1536 (from 1280), so I'm simply tempted to
>> increase it this time to 4096, unless someone has a better idea....
>
> This patch set should fix the zstd stack size warnings [0]. I’ve
> verified the fix using the same tooling: gcc-8-hppa-linux-gnu.
>
> I’ll send the PR to Linus tomorrow. I’ve been informed that it
> isn't strictly necessary to send the patches to the mailing list
> for bug fixes, but its already done, so I’ll wait and see if there
> is any feedback.
IMO several (or many more) people would disagree with that.
"strictly?" OK, it's probably possible that almost any patch
could be merged without being on a mailing list, but it's not
desirable (except in the case of "security" patches).
--
~Randy
^ permalink raw reply
* Re: Build regressions/improvements in v5.16-rc1
From: Nick Terrell @ 2021-11-17 1:59 UTC (permalink / raw)
To: Helge Deller
Cc: Peter Zijlstra, linux-pci, DRI Development,
open list:BROADCOM NVRAM DRIVER, James E.J. Bottomley,
Andrey Ryabinin, Stan Skowronek, Herbert Xu, kasan-dev,
Sergio Paracuellos, Geert Uytterhoeven, Anton Altaparmakov,
linux-arm-msm, open list:GPIO SUBSYSTEM, Joey Gouly,
André Almeida, Linux ARM, Thomas Bogendoerfer, Parisc List,
linux-ntfs-dev@lists.sourceforge.net, Hector Martin,
Linux Kernel Mailing List, Rob Clark, Linux Crypto Mailing List,
linuxppc-dev
In-Reply-To: <fcdead1c-2e26-b8ca-9914-4b3718d8f6d4@gmx.de>
> On Nov 15, 2021, at 8:44 AM, Helge Deller <deller@gmx.de> wrote:
>
> On 11/15/21 17:12, Geert Uytterhoeven wrote:
>> On Mon, Nov 15, 2021 at 4:54 PM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
>>> Below is the list of build error/warning regressions/improvements in
>>> v5.16-rc1[1] compared to v5.15[2].
>>>
>>> Summarized:
>>> - build errors: +20/-13
>>> - build warnings: +3/-28
>>>
>>> Happy fixing! ;-)
>>>
>>> Thanks to the linux-next team for providing the build service.
>>>
>>> [1] http://kisskb.ellerman.id.au/kisskb/branch/linus/head/fa55b7dcdc43c1aa1ba12bca9d2dd4318c2a0dbf/ (all 90 configs)
>>> [2] http://kisskb.ellerman.id.au/kisskb/branch/linus/head/8bb7eca972ad531c9b149c0a51ab43a417385813/ (all 90 configs)
>>>
>>>
>>> *** ERRORS ***
>>>
>>> 20 error regressions:
>>> + /kisskb/src/arch/parisc/include/asm/jump_label.h: error: expected ':' before '__stringify': => 33:4, 18:4
>>> + /kisskb/src/arch/parisc/include/asm/jump_label.h: error: label 'l_yes' defined but not used [-Werror=unused-label]: => 38:1, 23:1
>>
>> due to static_branch_likely() in crypto/api.c
>>
>> parisc-allmodconfig
>
> fixed now in the parisc for-next git tree.
>
>
>>> + /kisskb/src/drivers/gpu/drm/msm/msm_drv.h: error: "COND" redefined [-Werror]: => 531
>>> + /kisskb/src/lib/zstd/compress/zstd_double_fast.c: error: the frame size of 3252 bytes is larger than 1536 bytes [-Werror=frame-larger-than=]: => 47:1
>>> + /kisskb/src/lib/zstd/compress/zstd_double_fast.c: error: the frame size of 3360 bytes is larger than 1536 bytes [-Werror=frame-larger-than=]: => 499:1
>>> + /kisskb/src/lib/zstd/compress/zstd_double_fast.c: error: the frame size of 5344 bytes is larger than 1536 bytes [-Werror=frame-larger-than=]: => 334:1
>>> + /kisskb/src/lib/zstd/compress/zstd_double_fast.c: error: the frame size of 5380 bytes is larger than 1536 bytes [-Werror=frame-larger-than=]: => 354:1
>>> + /kisskb/src/lib/zstd/compress/zstd_fast.c: error: the frame size of 1824 bytes is larger than 1536 bytes [-Werror=frame-larger-than=]: => 372:1
>>> + /kisskb/src/lib/zstd/compress/zstd_fast.c: error: the frame size of 2224 bytes is larger than 1536 bytes [-Werror=frame-larger-than=]: => 204:1
>>> + /kisskb/src/lib/zstd/compress/zstd_fast.c: error: the frame size of 3800 bytes is larger than 1536 bytes [-Werror=frame-larger-than=]: => 476:1
>>
>> parisc-allmodconfig
>
> parisc needs much bigger frame sizes, so I'm not astonished here.
> During the v5.15 cycl I increased it to 1536 (from 1280), so I'm simply tempted to
> increase it this time to 4096, unless someone has a better idea....
This patch set should fix the zstd stack size warnings [0]. I’ve
verified the fix using the same tooling: gcc-8-hppa-linux-gnu.
I’ll send the PR to Linus tomorrow. I’ve been informed that it
isn't strictly necessary to send the patches to the mailing list
for bug fixes, but its already done, so I’ll wait and see if there
is any feedback.
Best,
Nick Terrell
[0] https://lkml.org/lkml/2021/11/16/1217
>>> + /kisskb/src/fs/ntfs/aops.c: error: the frame size of 2240 bytes is larger than 2048 bytes [-Werror=frame-larger-than=]: => 1311:1
>>> + /kisskb/src/fs/ntfs/aops.c: error: the frame size of 2304 bytes is larger than 2048 bytes [-Werror=frame-larger-than=]: => 1311:1
>>> + /kisskb/src/fs/ntfs/aops.c: error: the frame size of 2320 bytes is larger than 2048 bytes [-Werror=frame-larger-than=]: => 1311:1
>>
>> powerpc-allmodconfig
>>
>>> + /kisskb/src/include/linux/compiler_types.h: error: call to '__compiletime_assert_366' declared with attribute error: FIELD_PREP: value too large for the field: => 335:38
>>
>> in drivers/pinctrl/pinctrl-apple-gpio.c
>>
>> arm64-allmodconfig (gcc8)
>>
>>> + /kisskb/src/include/linux/fortify-string.h: error: call to '__read_overflow' declared with attribute error: detected read beyond size of object (1st parameter): => 263:25, 277:17
>>
>> in lib/test_kasan.c
>>
>> s390-all{mod,yes}config
>> arm64-allmodconfig (gcc11)
>>
>>> + error: modpost: "mips_cm_is64" [drivers/pci/controller/pcie-mt7621.ko] undefined!: => N/A
>>> + error: modpost: "mips_cm_lock_other" [drivers/pci/controller/pcie-mt7621.ko] undefined!: => N/A
>>> + error: modpost: "mips_cm_unlock_other" [drivers/pci/controller/pcie-mt7621.ko] undefined!: => N/A
>>> + error: modpost: "mips_cpc_base" [drivers/pci/controller/pcie-mt7621.ko] undefined!: => N/A
>>> + error: modpost: "mips_gcr_base" [drivers/pci/controller/pcie-mt7621.ko] undefined!: => N/A
>>
>> mips-allmodconfig
>>
>>> 3 warning regressions:
>>> + <stdin>: warning: #warning syscall futex_waitv not implemented [-Wcpp]: => 1559:2
>>
>> powerpc, m68k, mips, s390, parisc (and probably more)
>
> Will someone update all of them at once?
>
>
>
>
> Helge
>
>
>>> + arch/m68k/configs/multi_defconfig: warning: symbol value 'm' invalid for MCTP: => 322
>>> + arch/m68k/configs/sun3_defconfig: warning: symbol value 'm' invalid for MCTP: => 295
>>
>> Yeah, that happens when symbols are changed from tristate to bool...
>> Will be fixed in 5.17-rc1, with the next defconfig refresh.
>>
>> Gr{oetje,eeting}s,
>>
>> Geert
>>
>> --
>> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
>>
>> In personal conversations with technical people, I call myself a hacker. But
>> when I'm talking to journalists I just say "programmer" or something like that.
>> -- Linus Torvalds
>>
>
^ permalink raw reply
* [powerpc:fixes-test] BUILD SUCCESS 1e35eba4055149c578baf0318d2f2f89ea3c44a0
From: kernel test robot @ 2021-11-17 0:41 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git fixes-test
branch HEAD: 1e35eba4055149c578baf0318d2f2f89ea3c44a0 powerpc/8xx: Fix pinned TLBs with CONFIG_STRICT_KERNEL_RWX
elapsed time: 724m
configs tested: 190
configs skipped: 104
The following configs have been built successfully.
More configs may be tested in the coming days.
gcc tested configs:
arm defconfig
arm64 allyesconfig
arm64 defconfig
arm allyesconfig
arm allmodconfig
i386 randconfig-c001-20211116
mips randconfig-c004-20211116
powerpc mpc836x_rdk_defconfig
arm pxa_defconfig
powerpc mpc8313_rdb_defconfig
sh r7785rp_defconfig
s390 allmodconfig
microblaze mmu_defconfig
mips tb0287_defconfig
sh sh7724_generic_defconfig
m68k m5249evb_defconfig
x86_64 defconfig
arm cerfcube_defconfig
powerpc eiger_defconfig
mips loongson2k_defconfig
powerpc socrates_defconfig
xtensa common_defconfig
mips decstation_64_defconfig
m68k q40_defconfig
arc hsdk_defconfig
arm s5pv210_defconfig
xtensa iss_defconfig
powerpc mpc837x_rdb_defconfig
powerpc ps3_defconfig
sh rts7751r2d1_defconfig
sh titan_defconfig
um i386_defconfig
ia64 allyesconfig
sh hp6xx_defconfig
powerpc ppc44x_defconfig
powerpc mpc85xx_cds_defconfig
s390 zfcpdump_defconfig
arm mini2440_defconfig
microblaze defconfig
sh landisk_defconfig
arm at91_dt_defconfig
m68k m5407c3_defconfig
openrisc defconfig
mips decstation_r4k_defconfig
powerpc pq2fads_defconfig
powerpc walnut_defconfig
arm mxs_defconfig
mips ath79_defconfig
powerpc makalu_defconfig
mips sb1250_swarm_defconfig
arm clps711x_defconfig
arm socfpga_defconfig
powerpc mpc834x_itxgp_defconfig
mips rs90_defconfig
arm exynos_defconfig
powerpc cell_defconfig
arm axm55xx_defconfig
arm sama5_defconfig
mips rm200_defconfig
arm stm32_defconfig
arm spear13xx_defconfig
ia64 alldefconfig
mips malta_defconfig
arm versatile_defconfig
arm gemini_defconfig
arm eseries_pxa_defconfig
arm u8500_defconfig
mips cobalt_defconfig
sh secureedge5410_defconfig
powerpc bamboo_defconfig
h8300 defconfig
arm aspeed_g4_defconfig
arm imx_v6_v7_defconfig
powerpc mpc832x_mds_defconfig
s390 alldefconfig
arm imx_v4_v5_defconfig
sh apsh4a3a_defconfig
arm hisi_defconfig
mips rb532_defconfig
ia64 defconfig
arm magician_defconfig
powerpc mpc7448_hpc2_defconfig
arm collie_defconfig
powerpc ep88xc_defconfig
arc tb10x_defconfig
arm dove_defconfig
nios2 3c120_defconfig
arm mainstone_defconfig
powerpc wii_defconfig
powerpc mpc512x_defconfig
sh kfr2r09-romimage_defconfig
sh rsk7264_defconfig
m68k apollo_defconfig
sh shmin_defconfig
h8300 alldefconfig
mips rt305x_defconfig
arm mps2_defconfig
xtensa cadence_csp_defconfig
sh ap325rxa_defconfig
m68k amcore_defconfig
arm mvebu_v7_defconfig
sh dreamcast_defconfig
arm vexpress_defconfig
sh urquell_defconfig
sh se7751_defconfig
arm cns3420vb_defconfig
arm vt8500_v6_v7_defconfig
arc nsim_700_defconfig
arm milbeaut_m10v_defconfig
sh sh7770_generic_defconfig
h8300 h8s-sim_defconfig
powerpc mvme5100_defconfig
arm lpc32xx_defconfig
sh se7780_defconfig
xtensa virt_defconfig
ia64 tiger_defconfig
arm randconfig-c002-20211116
ia64 allmodconfig
m68k allmodconfig
m68k defconfig
m68k allyesconfig
nios2 defconfig
arc allyesconfig
nds32 allnoconfig
nds32 defconfig
nios2 allyesconfig
csky defconfig
alpha defconfig
alpha allyesconfig
xtensa allyesconfig
h8300 allyesconfig
arc defconfig
sh allmodconfig
parisc defconfig
s390 allyesconfig
parisc allyesconfig
s390 defconfig
i386 allyesconfig
sparc allyesconfig
sparc defconfig
i386 defconfig
i386 debian-10.3
mips allyesconfig
mips allmodconfig
powerpc allyesconfig
powerpc allmodconfig
powerpc allnoconfig
x86_64 randconfig-a015-20211116
x86_64 randconfig-a013-20211116
x86_64 randconfig-a012-20211116
x86_64 randconfig-a011-20211116
x86_64 randconfig-a016-20211116
x86_64 randconfig-a014-20211116
i386 randconfig-a014-20211116
i386 randconfig-a016-20211116
i386 randconfig-a012-20211116
i386 randconfig-a013-20211116
i386 randconfig-a011-20211116
i386 randconfig-a015-20211116
riscv nommu_k210_defconfig
riscv allyesconfig
riscv nommu_virt_defconfig
riscv allnoconfig
riscv defconfig
riscv rv32_defconfig
riscv allmodconfig
x86_64 rhel-8.3-kselftests
um x86_64_defconfig
x86_64 allyesconfig
x86_64 rhel-8.3
x86_64 rhel-8.3-func
x86_64 kexec
clang tested configs:
x86_64 randconfig-c007-20211116
i386 randconfig-c001-20211116
arm randconfig-c002-20211116
riscv randconfig-c006-20211116
powerpc randconfig-c003-20211116
s390 randconfig-c005-20211116
mips randconfig-c004-20211116
x86_64 randconfig-a005-20211116
x86_64 randconfig-a003-20211116
x86_64 randconfig-a001-20211116
x86_64 randconfig-a002-20211116
x86_64 randconfig-a006-20211116
x86_64 randconfig-a004-20211116
i386 randconfig-a006-20211116
i386 randconfig-a003-20211116
i386 randconfig-a005-20211116
i386 randconfig-a001-20211116
i386 randconfig-a004-20211116
i386 randconfig-a002-20211116
hexagon randconfig-r045-20211116
hexagon randconfig-r041-20211116
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
^ permalink raw reply
* [powerpc:fixes] BUILD SUCCESS 302039466f6a3b9421ecb9a6a2c528801dc24a86
From: kernel test robot @ 2021-11-17 0:41 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git fixes
branch HEAD: 302039466f6a3b9421ecb9a6a2c528801dc24a86 powerpc/pseries: Fix numa FORM2 parsing fallback code
elapsed time: 725m
configs tested: 153
configs skipped: 108
The following configs have been built successfully.
More configs may be tested in the coming days.
gcc tested configs:
arm defconfig
arm64 allyesconfig
arm64 defconfig
arm allyesconfig
arm allmodconfig
i386 randconfig-c001-20211116
mips randconfig-c004-20211116
powerpc mpc836x_rdk_defconfig
arm pxa_defconfig
powerpc mpc8313_rdb_defconfig
sh r7785rp_defconfig
s390 allmodconfig
microblaze mmu_defconfig
mips tb0287_defconfig
sh sh7724_generic_defconfig
m68k m5249evb_defconfig
arm cerfcube_defconfig
powerpc eiger_defconfig
m68k q40_defconfig
arc hsdk_defconfig
arm s5pv210_defconfig
xtensa iss_defconfig
powerpc mpc837x_rdb_defconfig
powerpc ps3_defconfig
sh rts7751r2d1_defconfig
sh titan_defconfig
um i386_defconfig
ia64 allyesconfig
s390 zfcpdump_defconfig
arm mini2440_defconfig
microblaze defconfig
sh landisk_defconfig
arm at91_dt_defconfig
m68k m5407c3_defconfig
openrisc defconfig
mips decstation_r4k_defconfig
arm axm55xx_defconfig
arm sama5_defconfig
mips rm200_defconfig
arm stm32_defconfig
arm spear13xx_defconfig
ia64 alldefconfig
powerpc mpc834x_itxgp_defconfig
mips malta_defconfig
arm versatile_defconfig
arm imx_v4_v5_defconfig
sh apsh4a3a_defconfig
arm hisi_defconfig
mips rb532_defconfig
ia64 defconfig
arm magician_defconfig
powerpc mpc7448_hpc2_defconfig
mips ath79_defconfig
arm collie_defconfig
nios2 3c120_defconfig
arm mainstone_defconfig
powerpc wii_defconfig
powerpc mpc512x_defconfig
powerpc mpc85xx_cds_defconfig
sh kfr2r09-romimage_defconfig
sh rsk7264_defconfig
m68k apollo_defconfig
sh shmin_defconfig
h8300 alldefconfig
mips rt305x_defconfig
powerpc mpc832x_mds_defconfig
arm mps2_defconfig
xtensa cadence_csp_defconfig
sh ap325rxa_defconfig
m68k amcore_defconfig
arm mvebu_v7_defconfig
sh dreamcast_defconfig
arm vt8500_v6_v7_defconfig
arc nsim_700_defconfig
arm milbeaut_m10v_defconfig
sh sh7770_generic_defconfig
xtensa virt_defconfig
ia64 tiger_defconfig
arm randconfig-c002-20211116
ia64 allmodconfig
m68k allmodconfig
m68k defconfig
m68k allyesconfig
nios2 defconfig
arc allyesconfig
nds32 allnoconfig
nds32 defconfig
nios2 allyesconfig
csky defconfig
alpha defconfig
alpha allyesconfig
xtensa allyesconfig
h8300 allyesconfig
arc defconfig
sh allmodconfig
parisc defconfig
s390 allyesconfig
parisc allyesconfig
s390 defconfig
i386 allyesconfig
sparc allyesconfig
sparc defconfig
i386 defconfig
i386 debian-10.3
mips allyesconfig
mips allmodconfig
powerpc allyesconfig
powerpc allmodconfig
powerpc allnoconfig
x86_64 randconfig-a015-20211116
x86_64 randconfig-a013-20211116
x86_64 randconfig-a012-20211116
x86_64 randconfig-a011-20211116
x86_64 randconfig-a016-20211116
x86_64 randconfig-a014-20211116
i386 randconfig-a014-20211116
i386 randconfig-a016-20211116
i386 randconfig-a012-20211116
i386 randconfig-a013-20211116
i386 randconfig-a011-20211116
i386 randconfig-a015-20211116
riscv nommu_k210_defconfig
riscv allyesconfig
riscv nommu_virt_defconfig
riscv allnoconfig
riscv defconfig
riscv rv32_defconfig
riscv allmodconfig
x86_64 rhel-8.3-kselftests
um x86_64_defconfig
x86_64 allyesconfig
x86_64 defconfig
x86_64 rhel-8.3
x86_64 rhel-8.3-func
x86_64 kexec
clang tested configs:
x86_64 randconfig-c007-20211116
i386 randconfig-c001-20211116
arm randconfig-c002-20211116
riscv randconfig-c006-20211116
powerpc randconfig-c003-20211116
s390 randconfig-c005-20211116
mips randconfig-c004-20211116
x86_64 randconfig-a005-20211116
x86_64 randconfig-a003-20211116
x86_64 randconfig-a001-20211116
x86_64 randconfig-a002-20211116
x86_64 randconfig-a006-20211116
x86_64 randconfig-a004-20211116
i386 randconfig-a006-20211116
i386 randconfig-a003-20211116
i386 randconfig-a005-20211116
i386 randconfig-a001-20211116
i386 randconfig-a004-20211116
i386 randconfig-a002-20211116
hexagon randconfig-r045-20211116
hexagon randconfig-r041-20211116
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
^ permalink raw reply
* [powerpc:next-test] BUILD SUCCESS 098a78a0f7f776200f1c5694983a37b77c522dbb
From: kernel test robot @ 2021-11-17 0:41 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git next-test
branch HEAD: 098a78a0f7f776200f1c5694983a37b77c522dbb powerpc/code-patching: Improve verification of patchability
elapsed time: 721m
configs tested: 195
configs skipped: 4
The following configs have been built successfully.
More configs may be tested in the coming days.
gcc tested configs:
arm defconfig
arm64 allyesconfig
arm64 defconfig
arm allyesconfig
arm allmodconfig
i386 randconfig-c001-20211116
mips randconfig-c004-20211116
powerpc mpc836x_rdk_defconfig
arm pxa_defconfig
powerpc mpc8313_rdb_defconfig
sh r7785rp_defconfig
s390 allmodconfig
microblaze mmu_defconfig
mips tb0287_defconfig
sh sh7724_generic_defconfig
m68k m5249evb_defconfig
x86_64 defconfig
arm cerfcube_defconfig
powerpc eiger_defconfig
mips loongson2k_defconfig
powerpc socrates_defconfig
xtensa common_defconfig
mips decstation_64_defconfig
m68k q40_defconfig
arc hsdk_defconfig
arm s5pv210_defconfig
xtensa iss_defconfig
powerpc mpc837x_rdb_defconfig
powerpc ps3_defconfig
sh rts7751r2d1_defconfig
sh titan_defconfig
um i386_defconfig
ia64 allyesconfig
sh hp6xx_defconfig
powerpc ppc44x_defconfig
powerpc mpc85xx_cds_defconfig
s390 zfcpdump_defconfig
arm mini2440_defconfig
microblaze defconfig
mips malta_kvm_defconfig
sparc64 alldefconfig
mips ath25_defconfig
arm simpad_defconfig
sh landisk_defconfig
arm at91_dt_defconfig
m68k m5407c3_defconfig
openrisc defconfig
mips decstation_r4k_defconfig
powerpc pq2fads_defconfig
powerpc walnut_defconfig
arm mxs_defconfig
mips ath79_defconfig
powerpc makalu_defconfig
mips sb1250_swarm_defconfig
arm clps711x_defconfig
arm socfpga_defconfig
powerpc mpc834x_itxgp_defconfig
mips rs90_defconfig
arm exynos_defconfig
powerpc cell_defconfig
arm axm55xx_defconfig
arm sama5_defconfig
mips rm200_defconfig
arm stm32_defconfig
arm spear13xx_defconfig
ia64 alldefconfig
mips malta_defconfig
arm versatile_defconfig
sh secureedge5410_defconfig
powerpc bamboo_defconfig
h8300 defconfig
arm aspeed_g4_defconfig
arm imx_v6_v7_defconfig
powerpc mpc832x_mds_defconfig
s390 alldefconfig
arm imx_v4_v5_defconfig
sh apsh4a3a_defconfig
arm hisi_defconfig
mips rb532_defconfig
arm hackkit_defconfig
arm qcom_defconfig
sh r7780mp_defconfig
sh migor_defconfig
arm orion5x_defconfig
ia64 defconfig
arm magician_defconfig
powerpc mpc7448_hpc2_defconfig
arm collie_defconfig
powerpc ep88xc_defconfig
arc tb10x_defconfig
arm dove_defconfig
nios2 3c120_defconfig
arm mainstone_defconfig
powerpc wii_defconfig
powerpc mpc512x_defconfig
sh kfr2r09-romimage_defconfig
sh rsk7264_defconfig
m68k apollo_defconfig
sh shmin_defconfig
h8300 alldefconfig
mips rt305x_defconfig
arm mps2_defconfig
xtensa cadence_csp_defconfig
sh ap325rxa_defconfig
m68k amcore_defconfig
arm mvebu_v7_defconfig
sh dreamcast_defconfig
arm vexpress_defconfig
sh urquell_defconfig
sh se7751_defconfig
arm cns3420vb_defconfig
arm vt8500_v6_v7_defconfig
arc nsim_700_defconfig
arm milbeaut_m10v_defconfig
sh sh7770_generic_defconfig
h8300 h8s-sim_defconfig
powerpc mvme5100_defconfig
arm lpc32xx_defconfig
sh se7780_defconfig
xtensa virt_defconfig
ia64 tiger_defconfig
arm randconfig-c002-20211116
ia64 allmodconfig
m68k allmodconfig
m68k defconfig
m68k allyesconfig
nios2 defconfig
arc allyesconfig
nds32 allnoconfig
nds32 defconfig
nios2 allyesconfig
csky defconfig
alpha defconfig
alpha allyesconfig
xtensa allyesconfig
h8300 allyesconfig
arc defconfig
sh allmodconfig
parisc defconfig
s390 allyesconfig
parisc allyesconfig
s390 defconfig
i386 allyesconfig
sparc allyesconfig
sparc defconfig
i386 defconfig
i386 debian-10.3
mips allyesconfig
mips allmodconfig
powerpc allyesconfig
powerpc allmodconfig
powerpc allnoconfig
x86_64 randconfig-a015-20211116
x86_64 randconfig-a013-20211116
x86_64 randconfig-a012-20211116
x86_64 randconfig-a011-20211116
x86_64 randconfig-a016-20211116
x86_64 randconfig-a014-20211116
i386 randconfig-a014-20211116
i386 randconfig-a016-20211116
i386 randconfig-a012-20211116
i386 randconfig-a013-20211116
i386 randconfig-a011-20211116
i386 randconfig-a015-20211116
riscv nommu_k210_defconfig
riscv allyesconfig
riscv nommu_virt_defconfig
riscv allnoconfig
riscv defconfig
riscv rv32_defconfig
riscv allmodconfig
x86_64 rhel-8.3-kselftests
um x86_64_defconfig
x86_64 allyesconfig
x86_64 rhel-8.3
x86_64 rhel-8.3-func
x86_64 kexec
clang tested configs:
x86_64 randconfig-c007-20211116
i386 randconfig-c001-20211116
arm randconfig-c002-20211116
riscv randconfig-c006-20211116
powerpc randconfig-c003-20211116
s390 randconfig-c005-20211116
mips randconfig-c004-20211116
x86_64 randconfig-a005-20211116
x86_64 randconfig-a003-20211116
x86_64 randconfig-a001-20211116
x86_64 randconfig-a002-20211116
x86_64 randconfig-a006-20211116
x86_64 randconfig-a004-20211116
i386 randconfig-a006-20211116
i386 randconfig-a003-20211116
i386 randconfig-a005-20211116
i386 randconfig-a001-20211116
i386 randconfig-a004-20211116
i386 randconfig-a002-20211116
hexagon randconfig-r045-20211116
hexagon randconfig-r041-20211116
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
^ permalink raw reply
* [powerpc:merge] BUILD SUCCESS 64044d20a2d777d2346cde7eb41d17497c4f4449
From: kernel test robot @ 2021-11-17 0:41 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git merge
branch HEAD: 64044d20a2d777d2346cde7eb41d17497c4f4449 Automatic merge of 'fixes' into merge (2021-11-16 22:46)
elapsed time: 721m
configs tested: 140
configs skipped: 3
The following configs have been built successfully.
More configs may be tested in the coming days.
gcc tested configs:
arm defconfig
arm64 allyesconfig
arm64 defconfig
arm allyesconfig
arm allmodconfig
i386 randconfig-c001-20211116
mips tb0287_defconfig
sh sh7724_generic_defconfig
m68k m5249evb_defconfig
x86_64 defconfig
arm cerfcube_defconfig
powerpc eiger_defconfig
mips cu1830-neo_defconfig
powerpc pcm030_defconfig
arm sama5_defconfig
sparc64 alldefconfig
s390 zfcpdump_defconfig
arm mini2440_defconfig
microblaze defconfig
mips cavium_octeon_defconfig
powerpc adder875_defconfig
m68k amcore_defconfig
powerpc ppc40x_defconfig
arc vdk_hs38_defconfig
arm mvebu_v5_defconfig
arm mv78xx0_defconfig
sh se7619_defconfig
xtensa generic_kc705_defconfig
powerpc64 defconfig
arm axm55xx_defconfig
mips rm200_defconfig
arm stm32_defconfig
arm spear13xx_defconfig
ia64 alldefconfig
powerpc ps3_defconfig
powerpc mpc836x_rdk_defconfig
arm gemini_defconfig
arm eseries_pxa_defconfig
arm u8500_defconfig
mips cobalt_defconfig
arm lart_defconfig
powerpc pseries_defconfig
sh hp6xx_defconfig
mips maltaaprp_defconfig
powerpc xes_mpc85xx_defconfig
arc vdk_hs38_smp_defconfig
sh apsh4ad0a_defconfig
s390 alldefconfig
s390 debug_defconfig
sh kfr2r09-romimage_defconfig
sh rsk7264_defconfig
m68k apollo_defconfig
sh shmin_defconfig
h8300 alldefconfig
mips rt305x_defconfig
powerpc mpc832x_mds_defconfig
arm mps2_defconfig
xtensa cadence_csp_defconfig
riscv allnoconfig
arm vt8500_v6_v7_defconfig
arc nsim_700_defconfig
arm milbeaut_m10v_defconfig
sh sh7770_generic_defconfig
powerpc mpc85xx_cds_defconfig
arm randconfig-c002-20211116
ia64 allmodconfig
ia64 defconfig
ia64 allyesconfig
m68k allmodconfig
m68k defconfig
m68k allyesconfig
nios2 defconfig
arc allyesconfig
nds32 allnoconfig
nds32 defconfig
nios2 allyesconfig
csky defconfig
alpha defconfig
alpha allyesconfig
xtensa allyesconfig
h8300 allyesconfig
arc defconfig
sh allmodconfig
parisc defconfig
s390 allyesconfig
s390 allmodconfig
parisc allyesconfig
s390 defconfig
i386 allyesconfig
sparc allyesconfig
sparc defconfig
i386 defconfig
i386 debian-10.3
mips allyesconfig
mips allmodconfig
powerpc allyesconfig
powerpc allmodconfig
powerpc allnoconfig
x86_64 randconfig-a015-20211116
x86_64 randconfig-a013-20211116
x86_64 randconfig-a012-20211116
x86_64 randconfig-a011-20211116
x86_64 randconfig-a016-20211116
x86_64 randconfig-a014-20211116
i386 randconfig-a014-20211116
i386 randconfig-a016-20211116
i386 randconfig-a012-20211116
i386 randconfig-a013-20211116
i386 randconfig-a011-20211116
i386 randconfig-a015-20211116
arc randconfig-r043-20211116
riscv randconfig-r042-20211116
s390 randconfig-r044-20211116
riscv nommu_k210_defconfig
riscv nommu_virt_defconfig
riscv rv32_defconfig
riscv allyesconfig
riscv defconfig
riscv allmodconfig
um x86_64_defconfig
um i386_defconfig
x86_64 rhel-8.3
x86_64 kexec
x86_64 rhel-8.3-kselftests
x86_64 rhel-8.3-func
x86_64 allyesconfig
clang tested configs:
x86_64 randconfig-a005-20211116
x86_64 randconfig-a003-20211116
x86_64 randconfig-a001-20211116
x86_64 randconfig-a002-20211116
x86_64 randconfig-a006-20211116
x86_64 randconfig-a004-20211116
i386 randconfig-a006-20211116
i386 randconfig-a003-20211116
i386 randconfig-a005-20211116
i386 randconfig-a001-20211116
i386 randconfig-a004-20211116
i386 randconfig-a002-20211116
hexagon randconfig-r045-20211116
hexagon randconfig-r041-20211116
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
^ permalink raw reply
* [PATCH] powerpc/rtas: kernel-doc fixes
From: Nathan Lynch @ 2021-11-16 21:58 UTC (permalink / raw)
To: linuxppc-dev
Fix the following issues reported by kernel-doc:
$ scripts/kernel-doc -v -none arch/powerpc/kernel/rtas.c
arch/powerpc/kernel/rtas.c:810: info: Scanning doc for function rtas_activate_firmware
arch/powerpc/kernel/rtas.c:818: warning: contents before sections
arch/powerpc/kernel/rtas.c:841: info: Scanning doc for function rtas_call_reentrant
arch/powerpc/kernel/rtas.c:893: warning: This comment starts with '/**', but isn't a kernel-doc comment. Refer Documentation/doc-guide/kernel-doc.rst
* Find a specific pseries error log in an RTAS extended event log.
Signed-off-by: Nathan Lynch <nathanl@linux.ibm.com>
---
arch/powerpc/kernel/rtas.c | 9 +++++----
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/kernel/rtas.c b/arch/powerpc/kernel/rtas.c
index ff80bbad22a5..ca27421f471a 100644
--- a/arch/powerpc/kernel/rtas.c
+++ b/arch/powerpc/kernel/rtas.c
@@ -809,13 +809,13 @@ void rtas_os_term(char *str)
/**
* rtas_activate_firmware() - Activate a new version of firmware.
*
+ * Context: This function may sleep.
+ *
* Activate a new version of partition firmware. The OS must call this
* after resuming from a partition hibernation or migration in order
* to maintain the ability to perform live firmware updates. It's not
* catastrophic for this method to be absent or to fail; just log the
* condition in that case.
- *
- * Context: This function may sleep.
*/
void rtas_activate_firmware(void)
{
@@ -890,11 +890,12 @@ int rtas_call_reentrant(int token, int nargs, int nret, int *outputs, ...)
#endif /* CONFIG_PPC_PSERIES */
/**
- * Find a specific pseries error log in an RTAS extended event log.
+ * get_pseries_errorlog() - Find a specific pseries error log in an RTAS
+ * extended event log.
* @log: RTAS error/event log
* @section_id: two character section identifier
*
- * Returns a pointer to the specified errorlog or NULL if not found.
+ * Return: A pointer to the specified errorlog or NULL if not found.
*/
struct pseries_errorlog *get_pseries_errorlog(struct rtas_error_log *log,
uint16_t section_id)
--
2.31.1
^ permalink raw reply related
* Re: Build regressions/improvements in v5.16-rc1
From: Nick Terrell @ 2021-11-16 21:08 UTC (permalink / raw)
To: Helge Deller
Cc: Peter Zijlstra, linux-pci, DRI Development,
open list:BROADCOM NVRAM DRIVER, James E.J. Bottomley,
Andrey Ryabinin, Stan Skowronek, Herbert Xu, kasan-dev,
Sergio Paracuellos, Geert Uytterhoeven, Anton Altaparmakov,
linux-arm-msm, open list:GPIO SUBSYSTEM, Joey Gouly,
André Almeida, Linux ARM, Thomas Bogendoerfer, Parisc List,
linux-ntfs-dev@lists.sourceforge.net, Hector Martin,
Linux Kernel Mailing List, Rob Clark, Linux Crypto Mailing List,
linuxppc-dev
In-Reply-To: <fcdead1c-2e26-b8ca-9914-4b3718d8f6d4@gmx.de>
> On Nov 15, 2021, at 8:44 AM, Helge Deller <deller@gmx.de> wrote:
>
> On 11/15/21 17:12, Geert Uytterhoeven wrote:
>> On Mon, Nov 15, 2021 at 4:54 PM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
>>> Below is the list of build error/warning regressions/improvements in
>>> v5.16-rc1[1] compared to v5.15[2].
>>>
>>> Summarized:
>>> - build errors: +20/-13
>>> - build warnings: +3/-28
>>>
>>> Happy fixing! ;-)
>>>
>>> Thanks to the linux-next team for providing the build service.
>>>
>>> [1] http://kisskb.ellerman.id.au/kisskb/branch/linus/head/fa55b7dcdc43c1aa1ba12bca9d2dd4318c2a0dbf/ (all 90 configs)
>>> [2] http://kisskb.ellerman.id.au/kisskb/branch/linus/head/8bb7eca972ad531c9b149c0a51ab43a417385813/ (all 90 configs)
>>>
>>>
>>> *** ERRORS ***
>>>
>>> 20 error regressions:
>>> + /kisskb/src/arch/parisc/include/asm/jump_label.h: error: expected ':' before '__stringify': => 33:4, 18:4
>>> + /kisskb/src/arch/parisc/include/asm/jump_label.h: error: label 'l_yes' defined but not used [-Werror=unused-label]: => 38:1, 23:1
>>
>> due to static_branch_likely() in crypto/api.c
>>
>> parisc-allmodconfig
>
> fixed now in the parisc for-next git tree.
>
>
>>> + /kisskb/src/drivers/gpu/drm/msm/msm_drv.h: error: "COND" redefined [-Werror]: => 531
>>> + /kisskb/src/lib/zstd/compress/zstd_double_fast.c: error: the frame size of 3252 bytes is larger than 1536 bytes [-Werror=frame-larger-than=]: => 47:1
>>> + /kisskb/src/lib/zstd/compress/zstd_double_fast.c: error: the frame size of 3360 bytes is larger than 1536 bytes [-Werror=frame-larger-than=]: => 499:1
>>> + /kisskb/src/lib/zstd/compress/zstd_double_fast.c: error: the frame size of 5344 bytes is larger than 1536 bytes [-Werror=frame-larger-than=]: => 334:1
>>> + /kisskb/src/lib/zstd/compress/zstd_double_fast.c: error: the frame size of 5380 bytes is larger than 1536 bytes [-Werror=frame-larger-than=]: => 354:1
>>> + /kisskb/src/lib/zstd/compress/zstd_fast.c: error: the frame size of 1824 bytes is larger than 1536 bytes [-Werror=frame-larger-than=]: => 372:1
>>> + /kisskb/src/lib/zstd/compress/zstd_fast.c: error: the frame size of 2224 bytes is larger than 1536 bytes [-Werror=frame-larger-than=]: => 204:1
>>> + /kisskb/src/lib/zstd/compress/zstd_fast.c: error: the frame size of 3800 bytes is larger than 1536 bytes [-Werror=frame-larger-than=]: => 476:1
>>
>> parisc-allmodconfig
>
> parisc needs much bigger frame sizes, so I'm not astonished here.
> During the v5.15 cycl I increased it to 1536 (from 1280), so I'm simply tempted to
> increase it this time to 4096, unless someone has a better idea....
I am working on a patch set to reduce the frame allocations some, but it doesn’t
get every function below 1536 on parisc with UBSAN. But, in addition to parisc
needing bigger frame sizes, it seems the gcc-8-hppa-linux-gnu compiler is doing a
horrendously bad job, especially with -fsanitize=shift enabled.
As an example, one of the functions warned ZSTD_fillDoubleHashTable() [0] takes
3252 bytes of stack with -fsanitize=shift enabled (as shown in the first warning on line
47 above). It is a trivial function, and there is no reason it should take any more than
a few bytes of stack allocation. On x86-64 it takes 48 bytes with -fsanitize=shift. On
gcc-10-hppa-linux-gnu this function only takes 380 bytes of stack space with
-fsanitize=shift. So it seems like whatever issue is present in gcc-8 they fixed in gcc-10.
On gcc-10-hppa-linux-gnu, after my patch set, I don’t see any -Wframe-larger-than=1536
errors. So, you could either increase it to 4096 bytes, or switch to gcc-10 for the parisc
test.
I’ll reply in more detail later today when I put up my patch set to reduce the stack usage.
Best,
Nick Terrell
[0] https://github.com/torvalds/linux/blob/8ab774587903771821b59471cc723bba6d893942/lib/zstd/compress/zstd_double_fast.c#L15-L47
>>> + /kisskb/src/fs/ntfs/aops.c: error: the frame size of 2240 bytes is larger than 2048 bytes [-Werror=frame-larger-than=]: => 1311:1
>>> + /kisskb/src/fs/ntfs/aops.c: error: the frame size of 2304 bytes is larger than 2048 bytes [-Werror=frame-larger-than=]: => 1311:1
>>> + /kisskb/src/fs/ntfs/aops.c: error: the frame size of 2320 bytes is larger than 2048 bytes [-Werror=frame-larger-than=]: => 1311:1
>>
>> powerpc-allmodconfig
>>
>>> + /kisskb/src/include/linux/compiler_types.h: error: call to '__compiletime_assert_366' declared with attribute error: FIELD_PREP: value too large for the field: => 335:38
>>
>> in drivers/pinctrl/pinctrl-apple-gpio.c
>>
>> arm64-allmodconfig (gcc8)
>>
>>> + /kisskb/src/include/linux/fortify-string.h: error: call to '__read_overflow' declared with attribute error: detected read beyond size of object (1st parameter): => 263:25, 277:17
>>
>> in lib/test_kasan.c
>>
>> s390-all{mod,yes}config
>> arm64-allmodconfig (gcc11)
>>
>>> + error: modpost: "mips_cm_is64" [drivers/pci/controller/pcie-mt7621.ko] undefined!: => N/A
>>> + error: modpost: "mips_cm_lock_other" [drivers/pci/controller/pcie-mt7621.ko] undefined!: => N/A
>>> + error: modpost: "mips_cm_unlock_other" [drivers/pci/controller/pcie-mt7621.ko] undefined!: => N/A
>>> + error: modpost: "mips_cpc_base" [drivers/pci/controller/pcie-mt7621.ko] undefined!: => N/A
>>> + error: modpost: "mips_gcr_base" [drivers/pci/controller/pcie-mt7621.ko] undefined!: => N/A
>>
>> mips-allmodconfig
>>
>>> 3 warning regressions:
>>> + <stdin>: warning: #warning syscall futex_waitv not implemented [-Wcpp]: => 1559:2
>>
>> powerpc, m68k, mips, s390, parisc (and probably more)
>
> Will someone update all of them at once?
>
>
>
>
> Helge
>
>
>>> + arch/m68k/configs/multi_defconfig: warning: symbol value 'm' invalid for MCTP: => 322
>>> + arch/m68k/configs/sun3_defconfig: warning: symbol value 'm' invalid for MCTP: => 295
>>
>> Yeah, that happens when symbols are changed from tristate to bool...
>> Will be fixed in 5.17-rc1, with the next defconfig refresh.
>>
>> Gr{oetje,eeting}s,
>>
>> Geert
>>
>> --
>> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
>>
>> In personal conversations with technical people, I call myself a hacker. But
>> when I'm talking to journalists I just say "programmer" or something like that.
>> -- Linus Torvalds
>>
>
^ permalink raw reply
* Re: Build regressions/improvements in v5.16-rc1
From: Nick Terrell @ 2021-11-16 21:27 UTC (permalink / raw)
To: Helge Deller
Cc: Peter Zijlstra, linux-pci, DRI Development,
open list:BROADCOM NVRAM DRIVER, James E.J. Bottomley,
Andrey Ryabinin, Stan Skowronek, Herbert Xu, kasan-dev,
Sergio Paracuellos, Geert Uytterhoeven, Anton Altaparmakov,
linux-arm-msm, open list:GPIO SUBSYSTEM, Joey Gouly,
André Almeida, Linux ARM, Thomas Bogendoerfer, Parisc List,
linux-ntfs-dev@lists.sourceforge.net, Hector Martin,
Linux Kernel Mailing List, Rob Clark, Linux Crypto Mailing List,
linuxppc-dev
In-Reply-To: <587BB1D2-A46B-4E93-A3EA-91325288CD6A@fb.com>
> On Nov 16, 2021, at 1:08 PM, Nick Terrell <terrelln@fb.com> wrote:
>
>
>
>> On Nov 15, 2021, at 8:44 AM, Helge Deller <deller@gmx.de> wrote:
>>
>> On 11/15/21 17:12, Geert Uytterhoeven wrote:
>>> On Mon, Nov 15, 2021 at 4:54 PM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
>>>> Below is the list of build error/warning regressions/improvements in
>>>> v5.16-rc1[1] compared to v5.15[2].
>>>>
>>>> Summarized:
>>>> - build errors: +20/-13
>>>> - build warnings: +3/-28
>>>>
>>>> Happy fixing! ;-)
>>>>
>>>> Thanks to the linux-next team for providing the build service.
>>>>
>>>> [1] http://kisskb.ellerman.id.au/kisskb/branch/linus/head/fa55b7dcdc43c1aa1ba12bca9d2dd4318c2a0dbf/ (all 90 configs)
>>>> [2] http://kisskb.ellerman.id.au/kisskb/branch/linus/head/8bb7eca972ad531c9b149c0a51ab43a417385813/ (all 90 configs)
>>>>
>>>>
>>>> *** ERRORS ***
>>>>
>>>> 20 error regressions:
>>>> + /kisskb/src/arch/parisc/include/asm/jump_label.h: error: expected ':' before '__stringify': => 33:4, 18:4
>>>> + /kisskb/src/arch/parisc/include/asm/jump_label.h: error: label 'l_yes' defined but not used [-Werror=unused-label]: => 38:1, 23:1
>>>
>>> due to static_branch_likely() in crypto/api.c
>>>
>>> parisc-allmodconfig
>>
>> fixed now in the parisc for-next git tree.
>>
>>
>>>> + /kisskb/src/drivers/gpu/drm/msm/msm_drv.h: error: "COND" redefined [-Werror]: => 531
>>>> + /kisskb/src/lib/zstd/compress/zstd_double_fast.c: error: the frame size of 3252 bytes is larger than 1536 bytes [-Werror=frame-larger-than=]: => 47:1
>>>> + /kisskb/src/lib/zstd/compress/zstd_double_fast.c: error: the frame size of 3360 bytes is larger than 1536 bytes [-Werror=frame-larger-than=]: => 499:1
>>>> + /kisskb/src/lib/zstd/compress/zstd_double_fast.c: error: the frame size of 5344 bytes is larger than 1536 bytes [-Werror=frame-larger-than=]: => 334:1
>>>> + /kisskb/src/lib/zstd/compress/zstd_double_fast.c: error: the frame size of 5380 bytes is larger than 1536 bytes [-Werror=frame-larger-than=]: => 354:1
>>>> + /kisskb/src/lib/zstd/compress/zstd_fast.c: error: the frame size of 1824 bytes is larger than 1536 bytes [-Werror=frame-larger-than=]: => 372:1
>>>> + /kisskb/src/lib/zstd/compress/zstd_fast.c: error: the frame size of 2224 bytes is larger than 1536 bytes [-Werror=frame-larger-than=]: => 204:1
>>>> + /kisskb/src/lib/zstd/compress/zstd_fast.c: error: the frame size of 3800 bytes is larger than 1536 bytes [-Werror=frame-larger-than=]: => 476:1
>>>
>>> parisc-allmodconfig
>>
>> parisc needs much bigger frame sizes, so I'm not astonished here.
>> During the v5.15 cycl I increased it to 1536 (from 1280), so I'm simply tempted to
>> increase it this time to 4096, unless someone has a better idea....
>
> I am working on a patch set to reduce the frame allocations some, but it doesn’t
> get every function below 1536 on parisc with UBSAN. But, in addition to parisc
> needing bigger frame sizes, it seems the gcc-8-hppa-linux-gnu compiler is doing a
> horrendously bad job, especially with -fsanitize=shift enabled.
>
> As an example, one of the functions warned ZSTD_fillDoubleHashTable() [0] takes
> 3252 bytes of stack with -fsanitize=shift enabled (as shown in the first warning on line
> 47 above). It is a trivial function, and there is no reason it should take any more than
> a few bytes of stack allocation. On x86-64 it takes 48 bytes with -fsanitize=shift. On
> gcc-10-hppa-linux-gnu this function only takes 380 bytes of stack space with
> -fsanitize=shift. So it seems like whatever issue is present in gcc-8 they fixed in gcc-10.
>
> On gcc-10-hppa-linux-gnu, after my patch set, I don’t see any -Wframe-larger-than=1536
> errors. So, you could either increase it to 4096 bytes, or switch to gcc-10 for the parisc
> test.
>
> I’ll reply in more detail later today when I put up my patch set to reduce the stack usage.
Zstd has been compiled with -O3 since before this update, and I’ve left it in. However, if
I remove -O3 (which reverts to the default of -O2), the stack space reductions disappear
on parisc. So it seems like gcc-hppa-linux-gnu doesn’t handle -O3 well.
I’ve done some preliminary performance measurements, and -O3 doesn’t seem to be
necessary good performance anymore. So I should be able to remove it. I’ll measure a
bit more carefully, then put a patch up.
> Best,
> Nick Terrell
>
> [0] https://github.com/torvalds/linux/blob/8ab774587903771821b59471cc723bba6d893942/lib/zstd/compress/zstd_double_fast.c#L15-L47
>
>>>> + /kisskb/src/fs/ntfs/aops.c: error: the frame size of 2240 bytes is larger than 2048 bytes [-Werror=frame-larger-than=]: => 1311:1
>>>> + /kisskb/src/fs/ntfs/aops.c: error: the frame size of 2304 bytes is larger than 2048 bytes [-Werror=frame-larger-than=]: => 1311:1
>>>> + /kisskb/src/fs/ntfs/aops.c: error: the frame size of 2320 bytes is larger than 2048 bytes [-Werror=frame-larger-than=]: => 1311:1
>>>
>>> powerpc-allmodconfig
>>>
>>>> + /kisskb/src/include/linux/compiler_types.h: error: call to '__compiletime_assert_366' declared with attribute error: FIELD_PREP: value too large for the field: => 335:38
>>>
>>> in drivers/pinctrl/pinctrl-apple-gpio.c
>>>
>>> arm64-allmodconfig (gcc8)
>>>
>>>> + /kisskb/src/include/linux/fortify-string.h: error: call to '__read_overflow' declared with attribute error: detected read beyond size of object (1st parameter): => 263:25, 277:17
>>>
>>> in lib/test_kasan.c
>>>
>>> s390-all{mod,yes}config
>>> arm64-allmodconfig (gcc11)
>>>
>>>> + error: modpost: "mips_cm_is64" [drivers/pci/controller/pcie-mt7621.ko] undefined!: => N/A
>>>> + error: modpost: "mips_cm_lock_other" [drivers/pci/controller/pcie-mt7621.ko] undefined!: => N/A
>>>> + error: modpost: "mips_cm_unlock_other" [drivers/pci/controller/pcie-mt7621.ko] undefined!: => N/A
>>>> + error: modpost: "mips_cpc_base" [drivers/pci/controller/pcie-mt7621.ko] undefined!: => N/A
>>>> + error: modpost: "mips_gcr_base" [drivers/pci/controller/pcie-mt7621.ko] undefined!: => N/A
>>>
>>> mips-allmodconfig
>>>
>>>> 3 warning regressions:
>>>> + <stdin>: warning: #warning syscall futex_waitv not implemented [-Wcpp]: => 1559:2
>>>
>>> powerpc, m68k, mips, s390, parisc (and probably more)
>>
>> Will someone update all of them at once?
>>
>>
>>
>>
>> Helge
>>
>>
>>>> + arch/m68k/configs/multi_defconfig: warning: symbol value 'm' invalid for MCTP: => 322
>>>> + arch/m68k/configs/sun3_defconfig: warning: symbol value 'm' invalid for MCTP: => 295
>>>
>>> Yeah, that happens when symbols are changed from tristate to bool...
>>> Will be fixed in 5.17-rc1, with the next defconfig refresh.
>>>
>>> Gr{oetje,eeting}s,
>>>
>>> Geert
>>>
>>> --
>>> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
>>>
>>> In personal conversations with technical people, I call myself a hacker. But
>>> when I'm talking to journalists I just say "programmer" or something like that.
>>> -- Linus Torvalds
^ permalink raw reply
* RE: bug: usb: gadget: FSL_UDC_CORE Corrupted request list leads to unrecoverable loop.
From: Eugene Bordenkircher @ 2021-11-16 19:11 UTC (permalink / raw)
To: Thorsten Leemhuis, Joakim Tjernlund,
linuxppc-dev@lists.ozlabs.org, linux-usb@vger.kernel.org
Cc: gregkh@linuxfoundation.org, balbi@kernel.org, leoyang.li@nxp.com
In-Reply-To: <bb5c5d0f-2ae7-8426-0021-baeca8f7dd11@leemhuis.info>
On 02.11.21 22:15, Joakim Tjernlund wrote:
> On Sat, 2021-10-30 at 14:20 +0000, Joakim Tjernlund wrote:
>> On Fri, 2021-10-29 at 17:14 +0000, Eugene Bordenkircher wrote:
>
>>> We've discovered a situation where the FSL udc driver (drivers/usb/gadget/udc/fsl_udc_core.c) will enter a loop iterating over the request queue, but the queue has been corrupted at some point so it loops infinitely. I believe we have narrowed into the offending code, but we are in need of assistance trying to find an appropriate fix for the problem. The identified code appears to be in all versions of the Linux kernel the driver exists in.
>>>
>>> The problem appears to be when handling a USB_REQ_GET_STATUS request. The driver gets this request and then calls the ch9getstatus() function. In this function, it starts a request by "borrowing" the per device status_req, filling it in, and then queuing it with a call to list_add_tail() to add the request to the endpoint queue. Right before it exits the function however, it's calling ep0_prime_status(), which is filling out that same status_req structure and then queuing it with another call to list_add_tail() to add the request to the endpoint queue. This adds two instances of the exact same LIST_HEAD to the endpoint queue, which breaks the list since the prev and next pointers end up pointing to the wrong things. This ends up causing a hard loop the next time nuke() gets called, which happens on the next setup IRQ.
>>>
>>> I'm not sure what the appropriate fix to this problem is, mostly due to my lack of expertise in USB and this driver stack. The code has been this way in the kernel for a very long time, which suggests that it has been working, unless USB_REQ_GET_STATUS requests are never made. This further suggests that there is something else going on that I don't understand. Deleting the call to ep0_prime_status() and the following ep0stall() call appears, on the surface, to get the device working again, but may have side effects that I'm not seeing.
>>>
>>> I'm hopeful someone in the community can help provide some information on what I may be missing or help come up with a solution to the problem. A big thank you to anyone who would like to help out.
>>>
>>> Eugene
>>
>> Run into this to a while ago. Found the bug and a few more fixes.
>> This is against 4.19 so you may have to tweak them a bit.
>> Feel free to upstream them.
>>
>> Jocke
>
> Curious, did my patches help? Good to known once we upgrade as well.
>
> Jocke
There's good news and bad news.
The good news is that this appears to stop the driver from entering an infinite loop, which prevents the Linux system from locking up and never recovering. So I'm willing to say we've made the behavior better.
The bad news is that once we get past this point, there is new bad behavior. What is on top of this driver in our system is the RNDIS gadget driver communicating to a Laptop running Win10 -1809. Everything appears to work fine with the Linux system until there is a USB disconnect. After the disconnect, the Linux side appears to continue on just fine, but the Windows side doesn't seem to recognize the disconnect, which causes the USB driver on that side to hang forever and eventually blue screen the box. This doesn't happen on all machines, just a select few. I think we can isolate the behavior to a specific antivirus/security software driver that is inserting itself into the USB stack and filtering the disconnect message, but we're still proving that.
I'm about 90% certain this is a different problem and we can call this patchset good, at least for our test setup. My only hesitation is if the Linux side is sending a set of responses that are confusing the Windows side (specifically this antivirus) or not. I'd be content calling that a separate defect though and letting this one close up with that patchset.
Eugene
^ permalink raw reply
* Re: [PATCH 6/7] KVM: powerpc: Use Makefile.kvm for common files
From: David Woodhouse @ 2021-11-16 19:13 UTC (permalink / raw)
To: Sean Christopherson
Cc: Anup Patel, wanpengli @ tencent . com, kvm, Joao Martins,
Will Deacon, kvmarm, linux-s390, joro @ 8bytes . org, Huacai Chen,
Christian Borntraeger, Aleksandar Markovic, karahmed,
Catalin Marinas, Suzuki K Poulose, Boris Ostrovsky,
Alexandru Elisei, linux-arm-kernel, jmattson @ google . com,
mtosatti @ redhat . com, linux-mips, James Morse, kvm-riscv,
Marc Zyngier, Paolo Bonzini, vkuznets @ redhat . com,
linuxppc-dev
In-Reply-To: <YZP76Un0mip17E1K@google.com>
[-- Attachment #1: Type: text/plain, Size: 2476 bytes --]
On Tue, 2021-11-16 at 18:43 +0000, Sean Christopherson wrote:
> On Tue, Nov 16, 2021, David Woodhouse wrote:
> > From: David Woodhouse <dwmw@amazon.co.uk>
> >
> > It's all fairly baroque but in the end, I don't think there's any reason
> > for $(KVM)/irqchip.o to have been handled differently, as they all end
> > up in $(kvm-y) in the end anyway, regardless of whether they get there
> > via $(common-objs-y) and the CPU-specific object lists.
> >
> > The generic Makefile.kvm uses HAVE_KVM_IRQCHIP for irqchip.o instead of
> > HAVE_KVM_IRQ_ROUTING. That change is fine (and arguably correct) because
> > they are both set together for KVM_MPIC, or neither is set.
>
> Nope.
>
> Symbol: HAVE_KVM_IRQCHIP [=y]
> Type : bool
> Defined at virt/kvm/Kconfig:7
> Selected by [m]:
> - KVM_XICS [=y] && VIRTUALIZATION [=y] && KVM_BOOK3S_64 [=m] && !KVM_MPIC [=n]
> Selected by [n]:
> - KVM_MPIC [=n] && VIRTUALIZATION [=y] && KVM [=y] && E500 [=n]
>
> leads to this and a whole pile of other errors
>
> arch/powerpc/kvm/../../../virt/kvm/irqchip.c: In function ‘kvm_irq_map_gsi’:
> arch/powerpc/kvm/../../../virt/kvm/irqchip.c:31:35: error: invalid use of undefined type ‘struct kvm_irq_routing_table’
> 31 | if (irq_rt && gsi < irq_rt->nr_rt_entries) {
> | ^~
>
Hm, perhaps it should have been like this then (incremental):
+++ b/virt/kvm/Makefile.kvm
@@ -9,6 +9,6 @@ kvm-y := $(KVM)/kvm_main.o $(KVM)/eventfd.o $(KVM)/binary_stats.o
kvm-$(CONFIG_KVM_VFIO) += $(KVM)/vfio.o
kvm-$(CONFIG_KVM_MMIO) += $(KVM)/coalesced_mmio.o
kvm-$(CONFIG_KVM_ASYNC_PF) += $(KVM)/async_pf.o
-kvm-$(CONFIG_HAVE_KVM_IRQCHIP) += $(KVM)/irqchip.o
+kvm-$(CONFIG_HAVE_KVM_IRQ_ROUTING) += $(KVM)/irqchip.o
kvm-$(CONFIG_HAVE_KVM_DIRTY_RING) += $(KVM)/dirty_ring.o
kvm-$(CONFIG_HAVE_KVM_PFNCACHE) += $(KVM)/pfncache.o
> Side topic, please don't post a new version/series in-reply-to a different series.
> b4 also gets confused in this case, e.g. it tried to grab the original patch. b4
> has also made me really lazy, heaven forbid I actually had to manually grab these
> from mutt :-)
Sorry ;)
I think that one might even be a new series in reply to what was
already a second series on top of what I was *actually* trying to do
when I first started shaving this yak. Or maybe what I was originally
trying to implement has already been lost in the noise :)
[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5174 bytes --]
^ permalink raw reply
* Re: [PATCH 6/7] KVM: powerpc: Use Makefile.kvm for common files
From: Sean Christopherson @ 2021-11-16 18:43 UTC (permalink / raw)
To: David Woodhouse
Cc: Anup Patel, wanpengli @ tencent . com, kvm, Joao Martins,
Will Deacon, kvmarm, linux-s390, joro @ 8bytes . org, Huacai Chen,
Christian Borntraeger, Aleksandar Markovic, karahmed,
Catalin Marinas, Suzuki K Poulose, Boris Ostrovsky,
Alexandru Elisei, linux-arm-kernel, jmattson @ google . com,
mtosatti @ redhat . com, linux-mips, James Morse, kvm-riscv,
Marc Zyngier, Paolo Bonzini, vkuznets @ redhat . com,
linuxppc-dev
In-Reply-To: <20211116115051.119956-6-dwmw2@infradead.org>
On Tue, Nov 16, 2021, David Woodhouse wrote:
> From: David Woodhouse <dwmw@amazon.co.uk>
>
> It's all fairly baroque but in the end, I don't think there's any reason
> for $(KVM)/irqchip.o to have been handled differently, as they all end
> up in $(kvm-y) in the end anyway, regardless of whether they get there
> via $(common-objs-y) and the CPU-specific object lists.
>
> The generic Makefile.kvm uses HAVE_KVM_IRQCHIP for irqchip.o instead of
> HAVE_KVM_IRQ_ROUTING. That change is fine (and arguably correct) because
> they are both set together for KVM_MPIC, or neither is set.
Nope.
Symbol: HAVE_KVM_IRQCHIP [=y]
Type : bool
Defined at virt/kvm/Kconfig:7
Selected by [m]:
- KVM_XICS [=y] && VIRTUALIZATION [=y] && KVM_BOOK3S_64 [=m] && !KVM_MPIC [=n]
Selected by [n]:
- KVM_MPIC [=n] && VIRTUALIZATION [=y] && KVM [=y] && E500 [=n]
leads to this and a whole pile of other errors
arch/powerpc/kvm/../../../virt/kvm/irqchip.c: In function ‘kvm_irq_map_gsi’:
arch/powerpc/kvm/../../../virt/kvm/irqchip.c:31:35: error: invalid use of undefined type ‘struct kvm_irq_routing_table’
31 | if (irq_rt && gsi < irq_rt->nr_rt_entries) {
| ^~
Side topic, please don't post a new version/series in-reply-to a different series.
b4 also gets confused in this case, e.g. it tried to grab the original patch. b4
has also made me really lazy, heaven forbid I actually had to manually grab these
from mutt :-)
^ permalink raw reply
* Re: [PATCH] powerpc/xive: Change IRQ domain to a tree domain
From: Cédric Le Goater @ 2021-11-16 17:56 UTC (permalink / raw)
To: Marc Zyngier; +Cc: linuxppc-dev, Greg Kurz, stable
In-Reply-To: <874k8c82cn.wl-maz@kernel.org>
On 11/16/21 17:58, Marc Zyngier wrote:
> On Tue, 16 Nov 2021 13:40:22 +0000,
> Cédric Le Goater <clg@kaod.org> wrote:
>>
>> Commit 4f86a06e2d6e ("irqdomain: Make normal and nomap irqdomains
>> exclusive") introduced an IRQ_DOMAIN_FLAG_NO_MAP flag to isolate the
>> 'nomap' domains still in use under the powerpc arch. With this new
>> flag, the revmap_tree of the IRQ domain is not used anymore. This
>> change broke the support of shared LSIs [1] in the XIVE driver because
>> it was relying on a lookup in the revmap_tree to query previously
>> mapped interrupts.
>
> Just a lookup? Surely there is more to it, no?
nope. The HW IRQ for the INTx is defined in the DT. It is caught by
of_irq_parse_and_map_pci() which simply adds an extra mapping on the
same INTx since the previous one is not found.
Using an INTx is quite rare now days and a shared one is even more
uncommon I guess, I could only reproduced on the baremetal platform
with the QEMU PowerNV machine using the same virtio devices.
Thanks,
C.
>
>> Linux now creates two distinct IRQ mappings on the
>> same HW IRQ which can lead to unexpected behavior in the drivers.
>>
>> The XIVE IRQ domain is not a direct mapping domain and its HW IRQ
>> interrupt number space is rather large : 1M/socket on POWER9 and
>> POWER10, change the XIVE driver to use a 'tree' domain type instead.
>>
>> [1] For instance, a linux KVM guest with virtio-rng and virtio-balloon
>> devices.
>>
>> Cc: Marc Zyngier <maz@kernel.org>
>> Cc: stable@vger.kernel.org # v5.14+
>> Fixes: 4f86a06e2d6e ("irqdomain: Make normal and nomap irqdomains exclusive")
>> Signed-off-by: Cédric Le Goater <clg@kaod.org>
>> ---
>>
>> Marc,
>>
>> The Fixes tag is there because the patch in question revealed that
>> something was broken in XIVE. genirq is not in cause. However, I
>> don't know for PS3 and Cell. May be less critical for now.
>
> Depends if they expect something that a no-map domain cannot provide.>
>>
>> arch/powerpc/sysdev/xive/common.c | 3 +--
>> arch/powerpc/sysdev/xive/Kconfig | 1 -
>> 2 files changed, 1 insertion(+), 3 deletions(-)
>>
>> diff --git a/arch/powerpc/sysdev/xive/common.c b/arch/powerpc/sysdev/xive/common.c
>> index fed6fd16c8f4..9d0f0fe25598 100644
>> --- a/arch/powerpc/sysdev/xive/common.c
>> +++ b/arch/powerpc/sysdev/xive/common.c
>> @@ -1536,8 +1536,7 @@ static const struct irq_domain_ops xive_irq_domain_ops = {
>>
>> static void __init xive_init_host(struct device_node *np)
>> {
>> - xive_irq_domain = irq_domain_add_nomap(np, XIVE_MAX_IRQ,
>> - &xive_irq_domain_ops, NULL);
>> + xive_irq_domain = irq_domain_add_tree(np, &xive_irq_domain_ops, NULL);
>> if (WARN_ON(xive_irq_domain == NULL))
>> return;
>> irq_set_default_host(xive_irq_domain);
>> diff --git a/arch/powerpc/sysdev/xive/Kconfig b/arch/powerpc/sysdev/xive/Kconfig
>> index 97796c6b63f0..785c292d104b 100644
>> --- a/arch/powerpc/sysdev/xive/Kconfig
>> +++ b/arch/powerpc/sysdev/xive/Kconfig
>> @@ -3,7 +3,6 @@ config PPC_XIVE
>> bool
>> select PPC_SMP_MUXED_IPI
>> select HARDIRQS_SW_RESEND
>> - select IRQ_DOMAIN_NOMAP
>>
>> config PPC_XIVE_NATIVE
>> bool
>
> As long as this works, I'm happy with one less no-map user.
>
> Acked-by: Marc Zyngier <maz@kernel.org>
>
> M.
>
^ permalink raw reply
* Re: [PATCH] powerpc/xive: Change IRQ domain to a tree domain
From: Marc Zyngier @ 2021-11-16 16:58 UTC (permalink / raw)
To: Cédric Le Goater; +Cc: linuxppc-dev, Greg Kurz, stable
In-Reply-To: <20211116134022.420412-1-clg@kaod.org>
On Tue, 16 Nov 2021 13:40:22 +0000,
Cédric Le Goater <clg@kaod.org> wrote:
>
> Commit 4f86a06e2d6e ("irqdomain: Make normal and nomap irqdomains
> exclusive") introduced an IRQ_DOMAIN_FLAG_NO_MAP flag to isolate the
> 'nomap' domains still in use under the powerpc arch. With this new
> flag, the revmap_tree of the IRQ domain is not used anymore. This
> change broke the support of shared LSIs [1] in the XIVE driver because
> it was relying on a lookup in the revmap_tree to query previously
> mapped interrupts.
Just a lookup? Surely there is more to it, no?
> Linux now creates two distinct IRQ mappings on the
> same HW IRQ which can lead to unexpected behavior in the drivers.
>
> The XIVE IRQ domain is not a direct mapping domain and its HW IRQ
> interrupt number space is rather large : 1M/socket on POWER9 and
> POWER10, change the XIVE driver to use a 'tree' domain type instead.
>
> [1] For instance, a linux KVM guest with virtio-rng and virtio-balloon
> devices.
>
> Cc: Marc Zyngier <maz@kernel.org>
> Cc: stable@vger.kernel.org # v5.14+
> Fixes: 4f86a06e2d6e ("irqdomain: Make normal and nomap irqdomains exclusive")
> Signed-off-by: Cédric Le Goater <clg@kaod.org>
> ---
>
> Marc,
>
> The Fixes tag is there because the patch in question revealed that
> something was broken in XIVE. genirq is not in cause. However, I
> don't know for PS3 and Cell. May be less critical for now.
Depends if they expect something that a no-map domain cannot provide.
>
> arch/powerpc/sysdev/xive/common.c | 3 +--
> arch/powerpc/sysdev/xive/Kconfig | 1 -
> 2 files changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/arch/powerpc/sysdev/xive/common.c b/arch/powerpc/sysdev/xive/common.c
> index fed6fd16c8f4..9d0f0fe25598 100644
> --- a/arch/powerpc/sysdev/xive/common.c
> +++ b/arch/powerpc/sysdev/xive/common.c
> @@ -1536,8 +1536,7 @@ static const struct irq_domain_ops xive_irq_domain_ops = {
>
> static void __init xive_init_host(struct device_node *np)
> {
> - xive_irq_domain = irq_domain_add_nomap(np, XIVE_MAX_IRQ,
> - &xive_irq_domain_ops, NULL);
> + xive_irq_domain = irq_domain_add_tree(np, &xive_irq_domain_ops, NULL);
> if (WARN_ON(xive_irq_domain == NULL))
> return;
> irq_set_default_host(xive_irq_domain);
> diff --git a/arch/powerpc/sysdev/xive/Kconfig b/arch/powerpc/sysdev/xive/Kconfig
> index 97796c6b63f0..785c292d104b 100644
> --- a/arch/powerpc/sysdev/xive/Kconfig
> +++ b/arch/powerpc/sysdev/xive/Kconfig
> @@ -3,7 +3,6 @@ config PPC_XIVE
> bool
> select PPC_SMP_MUXED_IPI
> select HARDIRQS_SW_RESEND
> - select IRQ_DOMAIN_NOMAP
>
> config PPC_XIVE_NATIVE
> bool
As long as this works, I'm happy with one less no-map user.
Acked-by: Marc Zyngier <maz@kernel.org>
M.
--
Without deviation from the norm, progress is not possible.
^ permalink raw reply
* Re: [PATCH 4/5] KVM: x86: Use kvm_get_vcpu() instead of open-coded access
From: Paolo Bonzini @ 2021-11-16 16:48 UTC (permalink / raw)
To: Sean Christopherson
Cc: Juergen Gross, Alexandru Elisei, Anup Patel, Janosch Frank, kvm,
Christian Borntraeger, Marc Zyngier, Huacai Chen,
David Hildenbrand, linux-mips, Nicholas Piggin, Atish Patra,
Aleksandar Markovic, Paul Mackerras, James Morse, kernel-team,
Claudio Imbrenda, linuxppc-dev, kvmarm, Suzuki K Poulose
In-Reply-To: <YZPXU3eBT8j0fUPs@google.com>
On 11/16/21 17:07, Sean Christopherson wrote:
>>> if (!kvm_arch_has_assigned_device(kvm) ||
>>> !irq_remapping_cap(IRQ_POSTING_CAP) ||
>>> - !kvm_vcpu_apicv_active(kvm->vcpus[0]))
>>> + !irqchip_in_kernel(kvm) || !enable_apicv)
>>> return 0;
>>>
>>> idx = srcu_read_lock(&kvm->irq_srcu);
>> What happens then if pi_pre_block is called and the IRTE denotes a posted
>> interrupt?
>>
>> I might be wrong, but it seems to me that you have to change all of the
>> occurrences this way. As soon as enable_apicv is set, you need to go
>> through the POSTED_INTR_WAKEUP_VECTOR just in case.
> Sorry, I didn't grok that at all. All occurences of what?
Of the !assigned-device || !VTd-PI || !kvm_vcpu_apicv_active(vcpu)
checks. This way, CPUs are woken up correctly even if you have
!kvm_vcpu_apicv_active(vcpu) but the IRTE is a posted-interrupt one.
Paolo
^ permalink raw reply
* Re: [PATCH 4/5] KVM: x86: Use kvm_get_vcpu() instead of open-coded access
From: Sean Christopherson @ 2021-11-16 16:07 UTC (permalink / raw)
To: Paolo Bonzini
Cc: Juergen Gross, Alexandru Elisei, Anup Patel, Janosch Frank, kvm,
Christian Borntraeger, Marc Zyngier, Huacai Chen,
David Hildenbrand, linux-mips, Nicholas Piggin, Atish Patra,
Aleksandar Markovic, Paul Mackerras, James Morse, kernel-team,
Claudio Imbrenda, linuxppc-dev, kvmarm, Suzuki K Poulose
In-Reply-To: <330eb780-1963-ac1f-aaad-908346112f28@redhat.com>
On Tue, Nov 16, 2021, Paolo Bonzini wrote:
> On 11/5/21 21:03, Sean Christopherson wrote:
> > But I think even that is flawed, as APICv can be dynamically deactivated and
> > re-activated while the VM is running, and I don't see a path that re-updates
> > the IRTE when APICv is re-activated. So I think a more conservative check is
> > needed, e.g.
> >
> > diff --git a/arch/x86/kvm/vmx/posted_intr.c b/arch/x86/kvm/vmx/posted_intr.c
> > index 5f81ef092bd4..6cf5b2e86118 100644
> > --- a/arch/x86/kvm/vmx/posted_intr.c
> > +++ b/arch/x86/kvm/vmx/posted_intr.c
> > @@ -272,7 +272,7 @@ int pi_update_irte(struct kvm *kvm, unsigned int host_irq, uint32_t guest_irq,
> >
> > if (!kvm_arch_has_assigned_device(kvm) ||
> > !irq_remapping_cap(IRQ_POSTING_CAP) ||
> > - !kvm_vcpu_apicv_active(kvm->vcpus[0]))
> > + !irqchip_in_kernel(kvm) || !enable_apicv)
> > return 0;
> >
> > idx = srcu_read_lock(&kvm->irq_srcu);
>
> What happens then if pi_pre_block is called and the IRTE denotes a posted
> interrupt?
>
> I might be wrong, but it seems to me that you have to change all of the
> occurrences this way. As soon as enable_apicv is set, you need to go
> through the POSTED_INTR_WAKEUP_VECTOR just in case.
Sorry, I didn't grok that at all. All occurences of what?
^ permalink raw reply
* [PATCH v2 7/7] KVM: Convert kvm_for_each_vcpu() to using xa_for_each_range()
From: Marc Zyngier @ 2021-11-16 16:04 UTC (permalink / raw)
To: kvm, linux-mips, kvmarm, linuxppc-dev, Paolo Bonzini
Cc: Juergen Gross, Huacai Chen, Janosch Frank, David Hildenbrand,
Sean Christopherson, Anup Patel, Philippe Mathieu-Daudé,
Nicholas Piggin, Christian Borntraeger, Aleksandar Markovic,
Paul Mackerras, James Morse, kernel-team, Claudio Imbrenda,
Alexandru Elisei, Suzuki K Poulose
In-Reply-To: <20211116160403.4074052-1-maz@kernel.org>
Now that the vcpu array is backed by an xarray, use the optimised
iterator that matches the underlying data structure.
Suggested-by: Sean Christopherson <seanjc@google.com>
Signed-off-by: Marc Zyngier <maz@kernel.org>
---
include/linux/kvm_host.h | 8 +++-----
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
index dc635fbfd901..d20e33378c63 100644
--- a/include/linux/kvm_host.h
+++ b/include/linux/kvm_host.h
@@ -705,11 +705,9 @@ static inline struct kvm_vcpu *kvm_get_vcpu(struct kvm *kvm, int i)
return xa_load(&kvm->vcpu_array, i);
}
-#define kvm_for_each_vcpu(idx, vcpup, kvm) \
- for (idx = 0; \
- idx < atomic_read(&kvm->online_vcpus) && \
- (vcpup = kvm_get_vcpu(kvm, idx)) != NULL; \
- idx++)
+#define kvm_for_each_vcpu(idx, vcpup, kvm) \
+ xa_for_each_range(&kvm->vcpu_array, idx, vcpup, 0, \
+ (atomic_read(&kvm->online_vcpus) - 1))
static inline struct kvm_vcpu *kvm_get_vcpu_by_id(struct kvm *kvm, int id)
{
--
2.30.2
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox