* Re: [PATCH] drm/amdkfd: make SPDX License expression more sound
From: Felix Kuehling @ 2022-01-05 19:27 UTC (permalink / raw)
To: Lukas Bulwahn, Jonathan Kim, Alex Deucher, amd-gfx
Cc: Greg Kroah-Hartman, Thomas Gleixner, linux-kernel, linux-spdx
In-Reply-To: <20211216094503.10597-1-lukas.bulwahn@gmail.com>
Am 2021-12-16 um 4:45 a.m. schrieb Lukas Bulwahn:
> Commit b5f57384805a ("drm/amdkfd: Add sysfs bitfields and enums to uAPI")
> adds include/uapi/linux/kfd_sysfs.h with the "GPL-2.0 OR MIT WITH
> Linux-syscall-note" SPDX-License expression.
>
> The command ./scripts/spdxcheck.py warns:
>
> include/uapi/linux/kfd_sysfs.h: 1:48 Exception not valid for license MIT: Linux-syscall-note
>
> For a uapi header, the file under GPLv2 License must be combined with the
> Linux-syscall-note, but combining the MIT License with the
> Linux-syscall-note makes no sense, as the note provides an exception for
> GPL-licensed code, not for permissively licensed code.
>
> So, reorganize the SPDX expression to only combine the note with the GPL
> License condition. This makes spdxcheck happy again.
>
> Signed-off-by: Lukas Bulwahn <lukas.bulwahn@gmail.com>
Reviewed-by: Felix Kuehling <Felix.Kuehling@amd.com>
> ---
> I am not a lawyer and I do not intend to modify the actual licensing of
> this header file. So, I really would like to have an Ack from some AMD
> developer here.
>
> Maybe also a lawyer on the linux-spdx list can check my reasoning on the
> licensing with the exception note?
>
> include/uapi/linux/kfd_sysfs.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/include/uapi/linux/kfd_sysfs.h b/include/uapi/linux/kfd_sysfs.h
> index e1fb78b4bf09..3e330f368917 100644
> --- a/include/uapi/linux/kfd_sysfs.h
> +++ b/include/uapi/linux/kfd_sysfs.h
> @@ -1,4 +1,4 @@
> -/* SPDX-License-Identifier: GPL-2.0 OR MIT WITH Linux-syscall-note */
> +/* SPDX-License-Identifier: (GPL-2.0 WITH Linux-syscall-note) OR MIT */
> /*
> * Copyright 2021 Advanced Micro Devices, Inc.
> *
^ permalink raw reply
* Re: [PATCH] pci: Skip power-off reset when pending unplug
From: Alex Williamson @ 2022-01-05 19:17 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: qemu-devel, kraxel
In-Reply-To: <20211223060931-mutt-send-email-mst@kernel.org>
On Thu, 23 Dec 2021 08:33:09 -0500
"Michael S. Tsirkin" <mst@redhat.com> wrote:
> On Wed, Dec 22, 2021 at 04:10:07PM -0700, Alex Williamson wrote:
> > On Wed, 22 Dec 2021 15:48:24 -0500
> > "Michael S. Tsirkin" <mst@redhat.com> wrote:
> >
> > > On Wed, Dec 22, 2021 at 12:08:09PM -0700, Alex Williamson wrote:
> > > > On Tue, 21 Dec 2021 18:40:09 -0500
> > > > "Michael S. Tsirkin" <mst@redhat.com> wrote:
> > > The reset is actually just an attempt to approximate power off.
> > > So I'm not sure that is right powering device off and then on
> > > is just a slow but reasonable way for guests to reset a device.
> >
> > Agree, I don't have a problem with resetting devices in response to the
> > slot being powered off, just that it's pointless, and in some scenarios
> > causes us additional grief when it occurs when the device is being
> > removed anyway.
> >
> > > > In that case we could reorganize things to let the unplug occur
> > > > before the power transition.
> > >
> > > Hmm you mean unplug on host immediately when it starts blinking?
> > > But drivers are not notified at this point, are they?
> >
> > I think this is confusing Attention Indicator and Power Indicator
> > again.
>
> Let's try to clear it up.
>
> Here's text from the SHPC spec, pcie spec is less clear imho but
> same idea IIUC.
>
> The Power Indicator provides visual feedback to the human operator (if the system
> software accepts the request initiated by the Attention Button) by blinking. Once the
> Power Indicator begins blinking, a 5-second abort interval exists during which a second
> depression of the Attention Button cancels the operation.
>
> Attention Indicator is confusingly unrelated to the Attention Button.
> Right?
Yeah, I think that's where I was getting confused. So a qdev_unplug()
results in "pushing" the attention button, the power indicator starts
flashing for 5s, during which an additional attention button press
could cancel the event. After that 5s period and with the power
indicator still flashing, the power controller is set to off, followed
by the power indicator turning off.
> > The write sequence I noted for the slot control register was as
> > follows:
> >
> > 01f1 - > 02f1 -> 06f1 -> 07f1
> >
> > 01f1:
> > Attention Indicator: OFF
> > Power Indicator: ON
> > Power Controller: ON
> >
> > 02f1:
> > Power Indicator: ON -> BLINK
> >
> > 06f1:
> > Power Controller: ON -> OFF
> >
> > 07f1:
> > Power Indicator: BLINK -> OFF
> >
> > The device reset currently occurs at 06f1, when the Power Controller
> > removes power to the slot. The unplug doesn't occur until 07f1 when
> > the Power Indicator turns off. On bare metal, the device power would
> > be in some indeterminate state between those two writes as the power
> > drains. We've chosen to reset the device at the beginning of this
> > phase, where power is first removed (ie. instantaneous power drain),
> > but on a physical device it happens somewhere in between.
>
> Yes, this is true I think. But I think on bare metal it's guaranteed to
> happen within 1 second after power is removed, whatever the state of the
> power indicator.
> Also, Gerd attempted to add PV code that special cases KVM and
> removes all the multi-second waiting from unplug path.
> So I am not sure we should rely on the 1 second wait, either.
Right, if we don't reset when power is removed we're in a guessing game
of whether the guest is following our assumed transitions.
> > It therefore
> > seems valid that it could happen at the moment the Power Indicator
> > turns off such that we could precede the device reset with any
> > necessary unplug operations.
>
> However the power indicator is merely an indicator for the
> human operator. My understanding is that driver that does not want to permit
> removing the device can turn off power without turning off
> the power indicator.
Yes, on bare metal there's likely some small window where the device
power state is indeterminate, but to take advantage of that we'd need
to do something like setup a 2s timer to reset the device, where that
timer gets canceled if the power indicator turns off in the meantime.
It's a lot of heuristics.
> > > > Of course the original proposal also
> > > > essentially supports this interpretation, the slot power off reset does
> > > > not occur for devices with a pending unplug and those devices are
> > > > removed after the slot transition grace period.
> > >
> > > Meaning the patch you posted? It relies on guest doing a specific
> > > thing though, and guest and host states are not synchronized.
> >
> > The proposed patch just means we won't reset the device in response to
> > slot power if an unplug is pending. So sure, if it's true that a guest
> > playing with the Power Controller without using the Power Indicator to
> > reflect the slot state could skip a device reset, but is that valid
> > guest behavior?
>
> I'm not 100% sure:
> The Power Indicator in the Off state indicates that insertion or removal of an the adapter is
> permitted.
>
> but also
>
> System software must cause a slot’s Power Indicator to be turned off when the slot
> is not powered and/or it is permissible to insert or remove an adapter.
>
> this and/or confuses me, but I think the "or" here is simply misguided.
> The SHPC spec from which the interface in pcie was inherited just says:
>
> When the Power Indicator is off, it means that main power to the slot is off and that
> insertion or removal of an add-in card is permitted.
I think the power indicator is clearly our guideline for when we're
allowed to insert or remove a device from the slot. Other than
resetting when slot power is removed as we do now, the above timer hack
is the only solution I can think of that guarantees we eventually reset
the device after power is removed without relying on the power
indicator transition. But I'm not sure it's worthwhile.
> > > I think it might work to defer reset if it's blinking until it actually
> > > stops blinking. To me it seems a bit less risky but but again, in theory
> > > some guest driver could use the power cycle reset while hotplug plays
> > > with PIC waiting for the cancel button press.
> >
> > That's essentially my previous suggestion above. The Power Indicator
> > blinking tells us the slot power is in transition, the option to press
> > the attention button to abort has passed. I understand the abort
> > window to be governed by the Attention Indicator blinking.
>
> what text in the spec gives you that impression?
My misunderstanding of the attention vs power indicators.
> > > E.g. I suspect your patch can be broken just by guest loading/unloading
> > > driver in a loop while host also triggers plug/unplug.
> >
> > It's not clear to me why that might fail. Can you elaborate? All it
> > does is skip the reset when an unplug is pending, but the actual unplug
> > finalizes the device and any subsequent plug necessarily uses a new
> > device, so I don't see what goes wrong.
>
> host wants to start unplug
> meanwhile guest wants to attempt a reset (for its own reasons)
> we skip the reset to device retains a bunch of state in
> its registers, the guest attempts to drive it assuming
> a reset device.
Under the condition of the kernel device lock being held, we can't
reset the device anyway. But yes, we don't need to extend that
vfio-pci limitation to other devices. Unless you're interested in
pursuing a timer based solution, which I guess would model a physical
system with super capacitors on the power rail that will drain
eventually, or instantly with the power indicator turning off, I think
the best we can do at the moment is to clean up the error reporting in
vfio-pci, report that the reset failed, but not some obscure error
about un-owned groups because we've fallen through to unexpected reset
methods. A reasonable error message for this condition can be
considered a feature rather than a regression. It's arguably correct
to try to reset the device here. I'll post a different patch where we
clean up the vfio-pci error reporting for this case. Thanks,
Alex
^ permalink raw reply
* stable/linux-5.10.y baseline: 164 runs, 1 regressions (v5.10.90)
From: kernelci.org bot @ 2022-01-05 19:26 UTC (permalink / raw)
To: stable, kernel-build-reports, kernelci-results
stable/linux-5.10.y baseline: 164 runs, 1 regressions (v5.10.90)
Regressions Summary
-------------------
platform | arch | lab | compiler | defconfig | regressions
--------------------+-------+--------------+----------+-----------+------------
r8a77950-salvator-x | arm64 | lab-baylibre | gcc-10 | defconfig | 1
Details: https://kernelci.org/test/job/stable/branch/linux-5.10.y/kernel/v5.10.90/plan/baseline/
Test: baseline
Tree: stable
Branch: linux-5.10.y
Describe: v5.10.90
URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
SHA: d3e491a20d152e5fba6c02a38916d63f982d98a5
Test Regressions
----------------
platform | arch | lab | compiler | defconfig | regressions
--------------------+-------+--------------+----------+-----------+------------
r8a77950-salvator-x | arm64 | lab-baylibre | gcc-10 | defconfig | 1
Details: https://kernelci.org/test/plan/id/61d5bc26468872f07aef6742
Results: 0 PASS, 1 FAIL, 0 SKIP
Full config: defconfig
Compiler: gcc-10 (aarch64-linux-gnu-gcc (Debian 10.2.1-6) 10.2.1 20210110)
Plain log: https://storage.kernelci.org//stable/linux-5.10.y/v5.10.90/arm64/defconfig/gcc-10/lab-baylibre/baseline-r8a77950-salvator-x.txt
HTML log: https://storage.kernelci.org//stable/linux-5.10.y/v5.10.90/arm64/defconfig/gcc-10/lab-baylibre/baseline-r8a77950-salvator-x.html
Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/buildroot-baseline/20211210.0/arm64/rootfs.cpio.gz
* baseline.login: https://kernelci.org/test/case/id/61d5bc26468872f07aef6743
new failure (last pass: v5.10.89)
^ permalink raw reply
* [PATCH] submodule.h: use a named enum for RECURSE_SUBMODULES_*
From: Philippe Blain via GitGitGadget @ 2022-01-05 19:26 UTC (permalink / raw)
To: git; +Cc: Emily Shaffer, Glen Choo, Philippe Blain, Philippe Blain
From: Philippe Blain <levraiphilippeblain@gmail.com>
Using a named enum allows casting an integer to the enum type in both
GDB and LLDB:
(gdb) p (enum diff_submodule_format) options->submodule_format
$1 = DIFF_SUBMODULE_LOG
(lldb) p (diff_submodule_format) options->submodule_format
(diff_submodule_format) $1 = DIFF_SUBMODULE_LOG
In LLDB, it's also required to cast in the reversed direction, i.e.
cast an enum constant into its corresponding integer:
(lldb) p (int) diff_submodule_format::DIFF_SUBMODULE_SHORT
(int) $0 = 0
Name the enum listing the different RECURSE_SUBMODULES_* modes, to make
debugging easier.
Signed-off-by: Philippe Blain <levraiphilippeblain@gmail.com>
---
submodule.h: use a named enum for RECURSE_SUBMODULES_*
Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-1111%2Fphil-blain%2Fsubmodule-recurse-enum-v1
Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-1111/phil-blain/submodule-recurse-enum-v1
Pull-Request: https://github.com/gitgitgadget/git/pull/1111
submodule.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/submodule.h b/submodule.h
index 6bd2c99fd99..55cf6f01d0c 100644
--- a/submodule.h
+++ b/submodule.h
@@ -13,7 +13,7 @@ struct repository;
struct string_list;
struct strbuf;
-enum {
+enum submodule_recurse_mode {
RECURSE_SUBMODULES_ONLY = -5,
RECURSE_SUBMODULES_CHECK = -4,
RECURSE_SUBMODULES_ERROR = -3,
base-commit: 2ae0a9cb8298185a94e5998086f380a355dd8907
--
gitgitgadget
^ permalink raw reply related
* Re: [PATCHv3 0/4] queue_rqs error handling
From: Jens Axboe @ 2022-01-05 19:25 UTC (permalink / raw)
To: linux-nvme, Keith Busch, linux-block; +Cc: sagi, hch, mgurtovoy
In-Reply-To: <20220105170518.3181469-1-kbusch@kernel.org>
On Wed, 5 Jan 2022 09:05:14 -0800, Keith Busch wrote:
> The only real change since v2 is a prep patch that relocates the rq list
> macros to blk-mq.h since that's where 'struct request' is defined.
>
> Patch 3 removes the 'next' parameter since it is trivially obtainable
> via 'rq->rq_next' anyway.
>
> Otherwise, the series is the same as v2 and tested with lots of random
> error injection in the prep path. The same errors would have lost
> requests in the current driver, but is successful with this series.
>
> [...]
Applied, thanks!
[1/4] block: move rq_list macros to blk-mq.h
commit: edce22e19bfa86efa2522d041d6367f2f099e8ed
[2/4] block: introduce rq_list_for_each_safe macro
commit: 3764fd05e1f89530e2ee5cbff0b638f2b1141b90
[3/4] block: introduce rq_list_move
commit: d2528be7a8b09af9796a270debd14101a72bb552
[4/4] nvme-pci: fix queue_rqs list splitting
commit: 6bfec7992ec79b63fb07330ae97f3fb43120aa37
Best regards,
--
Jens Axboe
^ permalink raw reply
* Re: [PATCH v3] thermal: rcar_thermal: Use platform_get_irq_optional() to get the interrupt
From: Lad, Prabhakar @ 2022-01-05 19:25 UTC (permalink / raw)
To: Niklas Söderlund
Cc: Lad Prabhakar, Geert Uytterhoeven, Rafael J. Wysocki,
Daniel Lezcano, Amit Kucheria, Zhang Rui, Rob Herring,
Andy Shevchenko, Linux-Renesas, Linux PM list, LKML
In-Reply-To: <YdXt2mDjZ0zikbt6@oden.dyn.berto.se>
Hi Niklas,
Thank you for the review.
On Wed, Jan 5, 2022 at 7:13 PM Niklas Söderlund
<niklas.soderlund@ragnatech.se> wrote:
>
> Hi Lad,
>
> Thanks for your work.
>
> On 2022-01-04 14:52:11 +0000, Lad Prabhakar wrote:
> > platform_get_resource(pdev, IORESOURCE_IRQ, ..) relies on static
> > allocation of IRQ resources in DT core code, this causes an issue
> > when using hierarchical interrupt domains using "interrupts" property
> > in the node as this bypasses the hierarchical setup and messes up the
> > irq chaining.
> >
> > In preparation for removal of static setup of IRQ resource from DT core
> > code use platform_get_irq_optional().
> >
> > Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
> > ---
> > v2-v3:
> > * Fixed review comment pointed by Andy
> >
> > v1->v2
> > * Simplified checking error code
> > * Break loop earlier if no interrupts are seen
> >
> > v1: https://lkml.org/lkml/2021/12/18/163
> > ---
> > drivers/thermal/rcar_thermal.c | 17 ++++++++++++-----
> > 1 file changed, 12 insertions(+), 5 deletions(-)
> >
> > diff --git a/drivers/thermal/rcar_thermal.c b/drivers/thermal/rcar_thermal.c
> > index b49f04daaf47..e480f7290ccf 100644
> > --- a/drivers/thermal/rcar_thermal.c
> > +++ b/drivers/thermal/rcar_thermal.c
> > @@ -445,7 +445,7 @@ static int rcar_thermal_probe(struct platform_device *pdev)
> > struct rcar_thermal_common *common;
> > struct rcar_thermal_priv *priv;
> > struct device *dev = &pdev->dev;
> > - struct resource *res, *irq;
> > + struct resource *res;
> > const struct rcar_thermal_chip *chip = of_device_get_match_data(dev);
> > int mres = 0;
> > int i;
> > @@ -467,9 +467,16 @@ static int rcar_thermal_probe(struct platform_device *pdev)
> > pm_runtime_get_sync(dev);
> >
> > for (i = 0; i < chip->nirqs; i++) {
> > - irq = platform_get_resource(pdev, IORESOURCE_IRQ, i);
> > - if (!irq)
> > - continue;
> > + int irq;
> > +
> > + irq = platform_get_irq_optional(pdev, i);
> > + if (irq < 0 && irq != -ENXIO) {
> > + ret = irq;
> > + goto error_unregister;
> > + }
> > + if (!irq || irq == -ENXIO)
> > + break;
>
> This do not look correct and differs form v1.
>
> In the old code if we can't get an IRQ the loop is continued. This is
> used to detect if interrupts are supported or not on the platform. This
> change will fail on all systems that don't describes interrupts in DT
> while the driver can function without interrupts.
>
There are no non-DT users for this driver. Do you see this driver
being used in a non-DT environment in near future?
> Is there a reason you wish to do this change in addition to the switch
> to platform_get_irq_optional()? If so I think that should be done in a
> separate patch.
>
No other reason, It was suggested by Gerrt too to use a break instead
of continue in v1.
Cheers,
Prabhakar
^ permalink raw reply
* Re: [PATCH] ethernet: ibmveth: use default_groups in kobj_type
From: Tyrel Datwyler @ 2022-01-05 19:23 UTC (permalink / raw)
To: Greg Kroah-Hartman, linux-kernel
Cc: Cristobal Forno, netdev, Paul Mackerras, Jakub Kicinski,
linuxppc-dev, David S. Miller
In-Reply-To: <20220105184101.2859410-1-gregkh@linuxfoundation.org>
On 1/5/22 10:41 AM, Greg Kroah-Hartman wrote:
> There are currently 2 ways to create a set of sysfs files for a
> kobj_type, through the default_attrs field, and the default_groups
> field. Move the ibmveth sysfs code to use default_groups
> field which has been the preferred way since aa30f47cf666 ("kobject: Add
> support for default attribute groups to kobj_type") so that we can soon
> get rid of the obsolete default_attrs field.
>
> Cc: Michael Ellerman <mpe@ellerman.id.au>
> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> Cc: Paul Mackerras <paulus@samba.org>
> Cc: Cristobal Forno <cforno12@linux.ibm.com>
> Cc: "David S. Miller" <davem@davemloft.net>
> Cc: Jakub Kicinski <kuba@kernel.org>
> Cc: linuxppc-dev@lists.ozlabs.org
> Cc: netdev@vger.kernel.org
> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> ---
Reviewed-by: Tyrel Datwyler <tyreld@linux.ibm.com>
^ permalink raw reply
* Re: [PATCH 09/17] pnv_phb4_pec.c: move pnv_pec_phb_offset() to pnv_phb4.c
From: Daniel Henrique Barboza @ 2022-01-05 19:14 UTC (permalink / raw)
To: Cédric Le Goater, qemu-devel; +Cc: qemu-ppc, david
In-Reply-To: <dc489ab6-3d0c-f6ab-4fe4-bf179081ecf4@kaod.org>
On 1/3/22 06:00, Cédric Le Goater wrote:
> On 12/28/21 20:37, Daniel Henrique Barboza wrote:
>> The logic inside pnv_pec_phb_offset() wiil be useful in the next patch
>
> will
>
>> to determine the stack that should contain a PHB4 device.
>>
>> Move the function to pnv_phb4.c and make it public since there's no
>> pnv_phb4_pec.h header. While we're at it, add 'stack_index' as a
>> parameter and make the function return 'phb-id' directly. And rename it
>> to pnv_pec_get_phb_id() to be even clearer about the function intent.
>>
>> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
>
> Looks good,
>
>> ---
>> hw/pci-host/pnv_phb4.c | 17 +++++++++++++++++
>> hw/pci-host/pnv_phb4_pec.c | 15 +--------------
>> include/hw/pci-host/pnv_phb4.h | 2 ++
>> 3 files changed, 20 insertions(+), 14 deletions(-)
>>
>> diff --git a/hw/pci-host/pnv_phb4.c b/hw/pci-host/pnv_phb4.c
>> index 0ea505cc94..36c56007ba 100644
>> --- a/hw/pci-host/pnv_phb4.c
>> +++ b/hw/pci-host/pnv_phb4.c
>> @@ -1164,6 +1164,23 @@ static AddressSpace *pnv_phb4_dma_iommu(PCIBus *bus, void *opaque, int devfn)
>> return &ds->dma_as;
>> }
>> +/*
>> + * Return the index/phb-id of a PHB4 that belongs to a
>> + * pec->stacks[stack_index] stack.
>> + */
>> +int pnv_pec_get_phb_id(PnvPhb4PecState *pec, int stack_index)
>
> pnv_phb4_pec_get_phb_id() would be cleaner.
Changed in the upcoming v2.
Daniel
>
> Thanks,
>
> C.
>
>
>
>> +{
>> + PnvPhb4PecClass *pecc = PNV_PHB4_PEC_GET_CLASS(pec);
>> + int index = pec->index;
>> + int offset = 0;
>> +
>> + while (index--) {
>> + offset += pecc->num_stacks[index];
>> + }
>> +
>> + return offset + stack_index;
>> +}
>> +
>> /*
>> * Set the object properties of a phb in relation with its stack.
>> *
>> diff --git a/hw/pci-host/pnv_phb4_pec.c b/hw/pci-host/pnv_phb4_pec.c
>> index 700ee4b185..bc2f8bb8b1 100644
>> --- a/hw/pci-host/pnv_phb4_pec.c
>> +++ b/hw/pci-host/pnv_phb4_pec.c
>> @@ -374,19 +374,6 @@ static void pnv_pec_instance_init(Object *obj)
>> }
>> }
>> -static int pnv_pec_phb_offset(PnvPhb4PecState *pec)
>> -{
>> - PnvPhb4PecClass *pecc = PNV_PHB4_PEC_GET_CLASS(pec);
>> - int index = pec->index;
>> - int offset = 0;
>> -
>> - while (index--) {
>> - offset += pecc->num_stacks[index];
>> - }
>> -
>> - return offset;
>> -}
>> -
>> static void pnv_pec_realize(DeviceState *dev, Error **errp)
>> {
>> PnvPhb4PecState *pec = PNV_PHB4_PEC(dev);
>> @@ -422,7 +409,7 @@ static void pnv_pec_realize(DeviceState *dev, Error **errp)
>> for (i = 0; i < pec->num_stacks; i++) {
>> PnvPhb4PecStack *stack = &pec->stacks[i];
>> Object *stk_obj = OBJECT(stack);
>> - int phb_id = pnv_pec_phb_offset(pec) + i;
>> + int phb_id = pnv_pec_get_phb_id(pec, i);
>> object_property_set_int(stk_obj, "stack-no", i, &error_abort);
>> object_property_set_int(stk_obj, "phb-id", phb_id, &error_abort);
>> diff --git a/include/hw/pci-host/pnv_phb4.h b/include/hw/pci-host/pnv_phb4.h
>> index d7838513f1..0fa88ca3fa 100644
>> --- a/include/hw/pci-host/pnv_phb4.h
>> +++ b/include/hw/pci-host/pnv_phb4.h
>> @@ -15,6 +15,7 @@
>> #include "hw/ppc/xive.h"
>> #include "qom/object.h"
>> +typedef struct PnvPhb4PecState PnvPhb4PecState;
>> typedef struct PnvPhb4PecStack PnvPhb4PecStack;
>> typedef struct PnvPHB4 PnvPHB4;
>> typedef struct PnvChip PnvChip;
>> @@ -134,6 +135,7 @@ struct PnvPHB4 {
>> void pnv_phb4_pic_print_info(PnvPHB4 *phb, Monitor *mon);
>> void pnv_phb4_update_regions(PnvPhb4PecStack *stack);
>> void pnv_phb4_set_stack_phb_props(PnvPhb4PecStack *stack, PnvPHB4 *phb);
>> +int pnv_pec_get_phb_id(PnvPhb4PecState *pec, int stack_index);
>> extern const MemoryRegionOps pnv_phb4_xscom_ops;
>> /*
>>
>
^ permalink raw reply
* Re: Please pull u-boot-marvell/master
From: Tom Rini @ 2022-01-05 19:24 UTC (permalink / raw)
To: Stefan Roese; +Cc: U-Boot Mailing List
In-Reply-To: <9bbce462-306a-b568-521b-18bf00c84e1e@denx.de>
[-- Attachment #1: Type: text/plain, Size: 187 bytes --]
On Wed, Jan 05, 2022 at 06:27:38PM +0100, Stefan Roese wrote:
> Hi Tom,
>
> please pull this last minute kwbimage related fix:
>
Applied to u-boot/master, thanks!
--
Tom
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]
^ permalink raw reply
* Re: [PATCH v2 net-next 0/7] Cleanup to main DSA structures
From: Vladimir Oltean @ 2022-01-05 19:22 UTC (permalink / raw)
To: Florian Fainelli
Cc: netdev@vger.kernel.org, David S. Miller, Jakub Kicinski,
Andrew Lunn, Vivien Didelot
In-Reply-To: <cadbfac7-0f20-baaf-d559-d9fe62f08856@gmail.com>
On Wed, Jan 05, 2022 at 11:04:24AM -0800, Florian Fainelli wrote:
> On 1/5/22 10:59 AM, Vladimir Oltean wrote:
> > On Wed, Jan 05, 2022 at 10:39:04AM -0800, Florian Fainelli wrote:
> >> On 1/5/22 5:21 AM, Vladimir Oltean wrote:
> >>> This series contains changes that do the following:
> >>>
> >>> - struct dsa_port reduced from 576 to 544 bytes, and first cache line a
> >>> bit better organized
> >>> - struct dsa_switch from 160 to 136 bytes, and first cache line a bit
> >>> better organized
> >>> - struct dsa_switch_tree from 112 to 104 bytes, and first cache line a
> >>> bit better organized
> >>>
> >>> No changes compared to v1, just split into a separate patch set.
> >>
> >> This is all looking good to me. I suppose we could possibly swap the
> >> 'nh' and 'tag_ops' member since dst->tag_ops is used in
> >> dsa_tag_generic_flow_dissect() which is a fast path, what do you think?
> >
> > pahole is telling me that dst->tag_ops is in the first cache line on
> > both arm64 and arm32. Are you saying that it's better for it to take
> > dst->nh's place?
>
> Sorry it stuck in my head somehow based upon patch 7's pahole output
> that tag_ops was still in the second cache line when the after clearly
> shows that it moved to the first cache line. No need to add additional
> changes then, thanks!
Yes, that output is a bit verbose and small details are easy to miss
(adding --expand_types makes it even worse). Happened to me quite a few
times during the session...
I'll prepare a v3 once we figure out what would suffice in terms of
warning other developers about the lack of bit field atomicity.
^ permalink raw reply
* Re: [PATCH] tracing/kprobes: 'nmissed' not showed correctly for kretprobe
From: Steven Rostedt @ 2022-01-05 19:22 UTC (permalink / raw)
To: Xiangyang Zhang; +Cc: mingo, Masami Hiramatsu, oleg, namhyung.kim, linux-kernel
In-Reply-To: <20220105141556.12fb2ceb@gandalf.local.home>
Resending again, this time with Masami's working email address.
On Wed, 5 Jan 2022 14:15:56 -0500
Steven Rostedt <rostedt@goodmis.org> wrote:
> On Sat, 11 Dec 2021 23:00:32 +0800
> Xiangyang Zhang <xyz.sun.ok@gmail.com> wrote:
>
> > The 'nmissed' column of the 'kprobe_profile' file for kretprobe is
> > always zero, because 'nmissed' for kretprobe is maintained in
> > 'tk->rp.nmissed' but not in 'tk->rp.kp.nmissed'
> >
> > Fixes: c31ffb3ff633 ("tracing/kprobes: Factor out struct trace_probe")
> > Signed-off-by: Xiangyang Zhang <xyz.sun.ok@gmail.com>
> > ---
> > kernel/trace/trace_kprobe.c | 4 +++-
> > 1 file changed, 3 insertions(+), 1 deletion(-)
> >
> > diff --git a/kernel/trace/trace_kprobe.c b/kernel/trace/trace_kprobe.c
> > index d10c01948e68..2b9de6826e94 100644
> > --- a/kernel/trace/trace_kprobe.c
> > +++ b/kernel/trace/trace_kprobe.c
> > @@ -1175,15 +1175,17 @@ static int probes_profile_seq_show(struct seq_file *m, void *v)
> > {
> > struct dyn_event *ev = v;
> > struct trace_kprobe *tk;
> > + unsigned long nmissed = 0;
>
> No need to initialize this to zero, the first use is an assignment.
>
> >
> > if (!is_trace_kprobe(ev))
> > return 0;
> >
> > tk = to_trace_kprobe(ev);
> > + nmissed = tk->rp.handler ? tk->rp.nmissed : tk->rp.kp.nmissed;
> > seq_printf(m, " %-44s %15lu %15lu\n",
> > trace_probe_name(&tk->tp),
> > trace_kprobe_nhit(tk),
> > - tk->rp.kp.nmissed);
> > + nmissed);
>
> Masami, what's your thoughts on this patch?
>
> -- Steve
>
> >
> > return 0;
> > }
>
^ permalink raw reply
* Re: [PATCH v5 4/4] KVM: mmu: remove over-aggressive warnings
From: Sean Christopherson @ 2022-01-05 19:19 UTC (permalink / raw)
To: David Stevens
Cc: Marc Zyngier, Paolo Bonzini, James Morse, Alexandru Elisei,
Suzuki K Poulose, Will Deacon, Wanpeng Li, Jim Mattson,
Joerg Roedel, linux-arm-kernel, kvmarm, linux-kernel, kvm
In-Reply-To: <YdXrURHO/R82puD4@google.com>
On Wed, Jan 05, 2022, Sean Christopherson wrote:
> Ah, I got royally confused by ensure_pfn_ref()'s comment
>
> * Certain IO or PFNMAP mappings can be backed with valid
> * struct pages, but be allocated without refcounting e.g.,
> * tail pages of non-compound higher order allocations, which
> * would then underflow the refcount when the caller does the
> * required put_page. Don't allow those pages here.
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> that doesn't apply here because kvm_faultin_pfn() uses the low level
> __gfn_to_pfn_page_memslot().
On fifth thought, I think this is wrong and doomed to fail. By mapping these pages
into the guest, KVM is effectively saying it supports these pages. But if the guest
uses the corresponding gfns for an action that requires KVM to access the page,
e.g. via kvm_vcpu_map(), ensure_pfn_ref() will reject the access and all sorts of
bad things will happen to the guest.
So, why not fully reject these types of pages? If someone is relying on KVM to
support these types of pages, then we'll fail fast and get a bug report letting us
know we need to properly support these types of pages. And if not, then we reduce
KVM's complexity and I get to keep my precious WARN :-)
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* stable-rc/queue/4.19 build: 160 builds: 5 failed, 155 passed, 26 warnings (v4.19.223-27-g13efc105b0f8)
From: kernelci.org bot @ 2022-01-05 19:20 UTC (permalink / raw)
To: stable, kernel-build-reports, kernelci-results
stable-rc/queue/4.19 build: 160 builds: 5 failed, 155 passed, 26 warnings (v4.19.223-27-g13efc105b0f8)
Full Build Summary: https://kernelci.org/build/stable-rc/branch/queue%2F4.19/kernel/v4.19.223-27-g13efc105b0f8/
Tree: stable-rc
Branch: queue/4.19
Git Describe: v4.19.223-27-g13efc105b0f8
Git Commit: 13efc105b0f8cd7796860cb2a28a3f9873d424af
Git URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
Built: 7 unique architectures
Build Failures Detected:
mips:
ip27_defconfig: (gcc-10) FAIL
ip28_defconfig: (gcc-10) FAIL
riscv:
allnoconfig: (gcc-10) FAIL
defconfig: (gcc-10) FAIL
tinyconfig: (gcc-10) FAIL
Warnings Detected:
arc:
arm64:
defconfig (gcc-10): 3 warnings
defconfig+arm64-chromebook (gcc-10): 3 warnings
arm:
i386:
allnoconfig (gcc-10): 2 warnings
i386_defconfig (gcc-10): 2 warnings
tinyconfig (gcc-10): 2 warnings
mips:
malta_qemu_32r6_defconfig (gcc-10): 1 warning
mtx1_defconfig (gcc-10): 3 warnings
nlm_xlp_defconfig (gcc-10): 1 warning
riscv:
x86_64:
allnoconfig (gcc-10): 3 warnings
tinyconfig (gcc-10): 3 warnings
x86_64_defconfig (gcc-10): 3 warnings
Warnings summary:
6 ld: warning: creating DT_TEXTREL in a PIE
6 aarch64-linux-gnu-ld: warning: -z norelro ignored
3 ld: arch/x86/boot/compressed/head_64.o: warning: relocation in read-only section `.head.text'
3 ld: arch/x86/boot/compressed/head_32.o: warning: relocation in read-only section `.head.text'
3 arch/x86/entry/entry_64.S:1738: Warning: no instruction mnemonic suffix given and no register operands; using default for `sysret'
2 sound/pci/echoaudio/echoaudio_dsp.c:647:9: warning: iteration 1073741824 invokes undefined behavior [-Waggressive-loop-optimizations]
1 {standard input}:132: Warning: macro instruction expanded into multiple instructions
1 sound/pci/echoaudio/echoaudio_dsp.c:658:9: warning: iteration 1073741824 invokes undefined behavior [-Waggressive-loop-optimizations]
1 net/core/rtnetlink.c:3197:1: warning: the frame size of 1344 bytes is larger than 1024 bytes [-Wframe-larger-than=]
================================================================================
Detailed per-defconfig build reports:
--------------------------------------------------------------------------------
acs5k_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
acs5k_tiny_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
allnoconfig (i386, gcc-10) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
ld: arch/x86/boot/compressed/head_32.o: warning: relocation in read-only section `.head.text'
ld: warning: creating DT_TEXTREL in a PIE
--------------------------------------------------------------------------------
allnoconfig (riscv, gcc-10) — FAIL, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
allnoconfig (x86_64, gcc-10) — PASS, 0 errors, 3 warnings, 0 section mismatches
Warnings:
arch/x86/entry/entry_64.S:1738: Warning: no instruction mnemonic suffix given and no register operands; using default for `sysret'
ld: arch/x86/boot/compressed/head_64.o: warning: relocation in read-only section `.head.text'
ld: warning: creating DT_TEXTREL in a PIE
--------------------------------------------------------------------------------
am200epdkit_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
ar7_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
aspeed_g4_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
aspeed_g5_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
assabet_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
ath25_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
axs103_defconfig (arc, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
axs103_smp_defconfig (arc, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
bcm2835_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
bcm47xx_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
bigsur_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
bmips_be_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
capcella_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
cerfcube_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
ci20_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
cm_x2xx_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
cm_x300_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
cobalt_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
colibri_pxa300_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
collie_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
corgi_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
davinci_all_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
decstation_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
defconfig (arm64, gcc-10) — PASS, 0 errors, 3 warnings, 0 section mismatches
Warnings:
aarch64-linux-gnu-ld: warning: -z norelro ignored
aarch64-linux-gnu-ld: warning: -z norelro ignored
aarch64-linux-gnu-ld: warning: -z norelro ignored
--------------------------------------------------------------------------------
defconfig (riscv, gcc-10) — FAIL, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
defconfig+arm64-chromebook (arm64, gcc-10) — PASS, 0 errors, 3 warnings, 0 section mismatches
Warnings:
aarch64-linux-gnu-ld: warning: -z norelro ignored
aarch64-linux-gnu-ld: warning: -z norelro ignored
aarch64-linux-gnu-ld: warning: -z norelro ignored
--------------------------------------------------------------------------------
dove_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
e55_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
ebsa110_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
efm32_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
em_x270_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
eseries_pxa_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
exynos_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
footbridge_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
gcw0_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
gpr_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
h3600_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
h5000_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
hackkit_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
haps_hs_defconfig (arc, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
haps_hs_smp_defconfig (arc, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
hisi_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
hsdk_defconfig (arc, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
i386_defconfig (i386, gcc-10) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
ld: arch/x86/boot/compressed/head_32.o: warning: relocation in read-only section `.head.text'
ld: warning: creating DT_TEXTREL in a PIE
--------------------------------------------------------------------------------
imote2_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
imx_v4_v5_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
imx_v6_v7_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
integrator_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
iop13xx_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
iop32x_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
iop33x_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
ip27_defconfig (mips, gcc-10) — FAIL, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
ip28_defconfig (mips, gcc-10) — FAIL, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
ip32_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
ixp4xx_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
jazz_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
jmr3927_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
jornada720_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
keystone_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
ks8695_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
loongson1b_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
loongson1c_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
lpc18xx_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
lpc32xx_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
lpd270_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
lubbock_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
mainstone_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
malta_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
malta_kvm_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
malta_qemu_32r6_defconfig (mips, gcc-10) — PASS, 0 errors, 1 warning, 0 section mismatches
Warnings:
{standard input}:132: Warning: macro instruction expanded into multiple instructions
--------------------------------------------------------------------------------
maltaaprp_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
maltasmvp_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
maltasmvp_eva_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
markeins_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
mini2440_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
mmp2_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
moxart_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
mpc30x_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
mps2_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
msp71xx_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
mtx1_defconfig (mips, gcc-10) — PASS, 0 errors, 3 warnings, 0 section mismatches
Warnings:
sound/pci/echoaudio/echoaudio_dsp.c:647:9: warning: iteration 1073741824 invokes undefined behavior [-Waggressive-loop-optimizations]
sound/pci/echoaudio/echoaudio_dsp.c:658:9: warning: iteration 1073741824 invokes undefined behavior [-Waggressive-loop-optimizations]
sound/pci/echoaudio/echoaudio_dsp.c:647:9: warning: iteration 1073741824 invokes undefined behavior [-Waggressive-loop-optimizations]
--------------------------------------------------------------------------------
multi_v4t_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
multi_v5_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
mvebu_v5_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
mvebu_v7_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
neponset_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
netx_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
nhk8815_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
nlm_xlp_defconfig (mips, gcc-10) — PASS, 0 errors, 1 warning, 0 section mismatches
Warnings:
net/core/rtnetlink.c:3197:1: warning: the frame size of 1344 bytes is larger than 1024 bytes [-Wframe-larger-than=]
--------------------------------------------------------------------------------
nlm_xlr_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
nsim_hs_defconfig (arc, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
nsim_hs_smp_defconfig (arc, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
nsimosci_hs_defconfig (arc, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
nsimosci_hs_smp_defconfig (arc, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
nuc910_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
nuc950_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
nuc960_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
orion5x_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
oxnas_v6_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
palmz72_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
pcm027_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
pic32mzda_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
pistachio_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
pleb_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
pnx8335_stb225_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
prima2_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
pxa255-idp_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
pxa3xx_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
pxa910_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
pxa_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
qcom_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
qi_lb60_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
raumfeld_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
rb532_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
rbtx49xx_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
realview_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
rm200_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
rt305x_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
s3c2410_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
s3c6400_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
s5pv210_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
sb1250_swarm_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
shannon_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
shmobile_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
simpad_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
spear13xx_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
spear3xx_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
spear6xx_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
spitz_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
stm32_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
sunxi_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
tango4_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
tb0226_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
tb0287_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
tct_hammer_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
tegra_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
tinyconfig (i386, gcc-10) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
ld: arch/x86/boot/compressed/head_32.o: warning: relocation in read-only section `.head.text'
ld: warning: creating DT_TEXTREL in a PIE
--------------------------------------------------------------------------------
tinyconfig (arc, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
tinyconfig (riscv, gcc-10) — FAIL, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
tinyconfig (x86_64, gcc-10) — PASS, 0 errors, 3 warnings, 0 section mismatches
Warnings:
arch/x86/entry/entry_64.S:1738: Warning: no instruction mnemonic suffix given and no register operands; using default for `sysret'
ld: arch/x86/boot/compressed/head_64.o: warning: relocation in read-only section `.head.text'
ld: warning: creating DT_TEXTREL in a PIE
--------------------------------------------------------------------------------
trizeps4_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
u300_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
vexpress_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
vf610m4_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
viper_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
vocore2_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
vt8500_v6_v7_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
workpad_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
x86_64_defconfig (x86_64, gcc-10) — PASS, 0 errors, 3 warnings, 0 section mismatches
Warnings:
arch/x86/entry/entry_64.S:1738: Warning: no instruction mnemonic suffix given and no register operands; using default for `sysret'
ld: arch/x86/boot/compressed/head_64.o: warning: relocation in read-only section `.head.text'
ld: warning: creating DT_TEXTREL in a PIE
--------------------------------------------------------------------------------
xcep_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
zeus_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
zx_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
---
For more info write to <info@kernelci.org>
^ permalink raw reply
* Re: [PATCH v9 02/10] dax: Introduce holder for dax_device
From: Dan Williams @ 2022-01-05 19:20 UTC (permalink / raw)
To: Darrick J. Wong
Cc: Shiyang Ruan, Linux Kernel Mailing List, linux-xfs, Linux NVDIMM,
Linux MM, linux-fsdevel, david, Christoph Hellwig, Jane Chu
In-Reply-To: <20220105185626.GE398655@magnolia>
On Wed, Jan 5, 2022 at 10:56 AM Darrick J. Wong <djwong@kernel.org> wrote:
>
> On Wed, Jan 05, 2022 at 10:23:08AM -0800, Dan Williams wrote:
> > On Wed, Jan 5, 2022 at 10:12 AM Darrick J. Wong <djwong@kernel.org> wrote:
> > >
> > > On Sun, Dec 26, 2021 at 10:34:31PM +0800, Shiyang Ruan wrote:
> > > > To easily track filesystem from a pmem device, we introduce a holder for
> > > > dax_device structure, and also its operation. This holder is used to
> > > > remember who is using this dax_device:
> > > > - When it is the backend of a filesystem, the holder will be the
> > > > instance of this filesystem.
> > > > - When this pmem device is one of the targets in a mapped device, the
> > > > holder will be this mapped device. In this case, the mapped device
> > > > has its own dax_device and it will follow the first rule. So that we
> > > > can finally track to the filesystem we needed.
> > > >
> > > > The holder and holder_ops will be set when filesystem is being mounted,
> > > > or an target device is being activated.
> > > >
> > > > Signed-off-by: Shiyang Ruan <ruansy.fnst@fujitsu.com>
> > > > ---
> > > > drivers/dax/super.c | 62 +++++++++++++++++++++++++++++++++++++++++++++
> > > > include/linux/dax.h | 29 +++++++++++++++++++++
> > > > 2 files changed, 91 insertions(+)
> > > >
> > > > diff --git a/drivers/dax/super.c b/drivers/dax/super.c
> > > > index c46f56e33d40..94c51f2ee133 100644
> > > > --- a/drivers/dax/super.c
> > > > +++ b/drivers/dax/super.c
> > > > @@ -20,15 +20,20 @@
> > > > * @inode: core vfs
> > > > * @cdev: optional character interface for "device dax"
> > > > * @private: dax driver private data
> > > > + * @holder_data: holder of a dax_device: could be filesystem or mapped device
> > > > * @flags: state and boolean properties
> > > > + * @ops: operations for dax_device
> > > > + * @holder_ops: operations for the inner holder
> > > > */
> > > > struct dax_device {
> > > > struct inode inode;
> > > > struct cdev cdev;
> > > > void *private;
> > > > struct percpu_rw_semaphore rwsem;
> > > > + void *holder_data;
> > > > unsigned long flags;
> > > > const struct dax_operations *ops;
> > > > + const struct dax_holder_operations *holder_ops;
> > > > };
> > > >
> > > > static dev_t dax_devt;
> > > > @@ -192,6 +197,29 @@ int dax_zero_page_range(struct dax_device *dax_dev, pgoff_t pgoff,
> > > > }
> > > > EXPORT_SYMBOL_GPL(dax_zero_page_range);
> > > >
> > > > +int dax_holder_notify_failure(struct dax_device *dax_dev, u64 off,
> > > > + u64 len, int mf_flags)
> > > > +{
> > > > + int rc;
> > > > +
> > > > + dax_read_lock(dax_dev);
> > > > + if (!dax_alive(dax_dev)) {
> > > > + rc = -ENXIO;
> > > > + goto out;
> > > > + }
> > > > +
> > > > + if (!dax_dev->holder_ops) {
> > > > + rc = -EOPNOTSUPP;
> > > > + goto out;
> > > > + }
> > > > +
> > > > + rc = dax_dev->holder_ops->notify_failure(dax_dev, off, len, mf_flags);
> > > > +out:
> > > > + dax_read_unlock(dax_dev);
> > > > + return rc;
> > > > +}
> > > > +EXPORT_SYMBOL_GPL(dax_holder_notify_failure);
> > > > +
> > > > #ifdef CONFIG_ARCH_HAS_PMEM_API
> > > > void arch_wb_cache_pmem(void *addr, size_t size);
> > > > void dax_flush(struct dax_device *dax_dev, void *addr, size_t size)
> > > > @@ -254,6 +282,10 @@ void kill_dax(struct dax_device *dax_dev)
> > > > return;
> > > > dax_write_lock(dax_dev);
> > > > clear_bit(DAXDEV_ALIVE, &dax_dev->flags);
> > > > +
> > > > + /* clear holder data */
> > > > + dax_dev->holder_ops = NULL;
> > > > + dax_dev->holder_data = NULL;
> > > > dax_write_unlock(dax_dev);
> > > > }
> > > > EXPORT_SYMBOL_GPL(kill_dax);
> > > > @@ -401,6 +433,36 @@ void put_dax(struct dax_device *dax_dev)
> > > > }
> > > > EXPORT_SYMBOL_GPL(put_dax);
> > > >
> > > > +void dax_register_holder(struct dax_device *dax_dev, void *holder,
> > > > + const struct dax_holder_operations *ops)
> > > > +{
> > > > + if (!dax_alive(dax_dev))
> > > > + return;
> > > > +
> > > > + dax_dev->holder_data = holder;
> > > > + dax_dev->holder_ops = ops;
> > >
> > > Shouldn't this return an error code if the dax device is dead or if
> > > someone already registered a holder? I'm pretty sure XFS should not
> > > bind to a dax device if someone else already registered for it...
> >
> > Agree, yes.
> >
> > >
> > > ...unless you want to use a notifier chain for failure events so that
> > > there can be multiple consumers of dax failure events?
> >
> > No, I would hope not. It should be 1:1 holders to dax-devices. Similar
> > ownership semantics like bd_prepare_to_claim().
>
> Does each partition on a pmem device still have its own dax_device?
No, it never did...
Just as before, each dax-device is still associated with a gendisk /
whole-block_device. The recent change is that instead of needing that
partition-block_device plumbed to convert a relative block number to
its absolute whole-block_device offset the filesystem now handles that
at iomap_begin() time. See:
if (mapping_flags & IOMAP_DAX)
iomap->addr += target->bt_dax_part_off;
...in xfs_bmbt_to_iomap() (in -next). I.e. bdev_dax_pgoff() is gone
with the lead-in reworks.
^ permalink raw reply
* Re: [PATCH v5 4/4] KVM: mmu: remove over-aggressive warnings
From: Sean Christopherson @ 2022-01-05 19:19 UTC (permalink / raw)
To: David Stevens
Cc: Marc Zyngier, Paolo Bonzini, James Morse, Alexandru Elisei,
Suzuki K Poulose, Will Deacon, Wanpeng Li, Jim Mattson,
Joerg Roedel, linux-arm-kernel, kvmarm, linux-kernel, kvm
In-Reply-To: <YdXrURHO/R82puD4@google.com>
On Wed, Jan 05, 2022, Sean Christopherson wrote:
> Ah, I got royally confused by ensure_pfn_ref()'s comment
>
> * Certain IO or PFNMAP mappings can be backed with valid
> * struct pages, but be allocated without refcounting e.g.,
> * tail pages of non-compound higher order allocations, which
> * would then underflow the refcount when the caller does the
> * required put_page. Don't allow those pages here.
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> that doesn't apply here because kvm_faultin_pfn() uses the low level
> __gfn_to_pfn_page_memslot().
On fifth thought, I think this is wrong and doomed to fail. By mapping these pages
into the guest, KVM is effectively saying it supports these pages. But if the guest
uses the corresponding gfns for an action that requires KVM to access the page,
e.g. via kvm_vcpu_map(), ensure_pfn_ref() will reject the access and all sorts of
bad things will happen to the guest.
So, why not fully reject these types of pages? If someone is relying on KVM to
support these types of pages, then we'll fail fast and get a bug report letting us
know we need to properly support these types of pages. And if not, then we reduce
KVM's complexity and I get to keep my precious WARN :-)
^ permalink raw reply
* Re: [PATCH v5 4/4] KVM: mmu: remove over-aggressive warnings
From: Sean Christopherson @ 2022-01-05 19:19 UTC (permalink / raw)
To: David Stevens
Cc: Wanpeng Li, kvm, Marc Zyngier, Joerg Roedel, linux-kernel,
Paolo Bonzini, Will Deacon, kvmarm, linux-arm-kernel, Jim Mattson
In-Reply-To: <YdXrURHO/R82puD4@google.com>
On Wed, Jan 05, 2022, Sean Christopherson wrote:
> Ah, I got royally confused by ensure_pfn_ref()'s comment
>
> * Certain IO or PFNMAP mappings can be backed with valid
> * struct pages, but be allocated without refcounting e.g.,
> * tail pages of non-compound higher order allocations, which
> * would then underflow the refcount when the caller does the
> * required put_page. Don't allow those pages here.
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> that doesn't apply here because kvm_faultin_pfn() uses the low level
> __gfn_to_pfn_page_memslot().
On fifth thought, I think this is wrong and doomed to fail. By mapping these pages
into the guest, KVM is effectively saying it supports these pages. But if the guest
uses the corresponding gfns for an action that requires KVM to access the page,
e.g. via kvm_vcpu_map(), ensure_pfn_ref() will reject the access and all sorts of
bad things will happen to the guest.
So, why not fully reject these types of pages? If someone is relying on KVM to
support these types of pages, then we'll fail fast and get a bug report letting us
know we need to properly support these types of pages. And if not, then we reduce
KVM's complexity and I get to keep my precious WARN :-)
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
^ permalink raw reply
* Re: [PATCH RESEND 1/1] x86/smpboot: check cpu_initialized_mask first after returning from schedule()
From: Tim Chen @ 2022-01-05 19:19 UTC (permalink / raw)
To: Dongli Zhang, x86
Cc: tglx, mingo, bp, dave.hansen, hpa, peterz, rafael.j.wysocki,
vkuznets, alison.schofield, boris.ostrovsky, joe.jin, longpeng2,
bigeasy, linux-kernel
In-Reply-To: <20211223210343.1116-1-dongli.zhang@oracle.com>
On Thu, 2021-12-23 at 13:03 -0800, Dongli Zhang wrote:
> To online a new CPU, the master CPU signals the secondary and waits
> for at
> most 10 seconds until cpu_initialized_mask is set by the secondary
> CPU.
> There is a case that the master CPU fails the online when it takes
> 10+
> seconds for schedule() to return (although the cpu_initialized_mask
> is
> already set by the secondary CPU).
>
> 1. The master CPU signals the secondary CPU in do_boot_cpu().
>
> 2. As the cpu_initialized_mask is still not set, the master CPU
> reschedules
> via schedule().
>
> 3. Suppose it takes 10+ seconds until schedule() returns due to
> performance
> issue. The secondary CPU sets the cpu_initialized_mask during those
> 10+
> seconds.
The patch seems reasonable. But do you know what other task got run
and caused such long delay (>10 sec), preventing switch
back to in the master CPU? It seems like there could be some problem
causing the long delay. It is better if we understand the root cause
of that.
Tim
>
> 4. Once the schedule() at the master CPU returns, although the
> cpu_initialized_mask is set, the time_before(jiffies, timeout) fails.
> As a
> result, the master CPU regards this as failure.
>
> [ 51.983296] smpboot: do_boot_cpu failed(-1) to wakeup CPU#4
>
> 5. Since the secondary CPU is stuck at state CPU_UP_PREPARE, any
> further
> online operation will fail by cpu_check_up_prepare(), unless the
> below
> patch set is applied.
>
> https://lore.kernel.org/all/20211206152034.2150770-1-bigeasy@linutronix.de/
>
> This issue is resolved by always first checking whether the secondary
> CPU
> has set cpu_initialized_mask.
>
> Cc: Longpeng(Mike) <longpeng2@huawei.com>
> Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
> Cc: Joe Jin <joe.jin@oracle.com>
> Signed-off-by: Dongli Zhang <dongli.zhang@oracle.com>
> ---
> To resend by Cc linux-kernel@vger.kernel.org as well.
>
> arch/x86/kernel/smpboot.c | 6 +++++-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/arch/x86/kernel/smpboot.c b/arch/x86/kernel/smpboot.c
> index 617012f4619f..faad4fcf67eb 100644
> --- a/arch/x86/kernel/smpboot.c
> +++ b/arch/x86/kernel/smpboot.c
> @@ -1145,7 +1145,7 @@ static int do_boot_cpu(int apicid, int cpu,
> struct task_struct *idle,
> */
> boot_error = -1;
> timeout = jiffies + 10*HZ;
> - while (time_before(jiffies, timeout)) {
> + while (true) {
> if (cpumask_test_cpu(cpu,
> cpu_initialized_mask)) {
> /*
> * Tell AP to proceed with
> initialization
> @@ -1154,6 +1154,10 @@ static int do_boot_cpu(int apicid, int cpu,
> struct task_struct *idle,
> boot_error = 0;
> break;
> }
> +
> + if (time_after_eq(jiffies, timeout))
> + break;
> +
> schedule();
> }
> }
^ permalink raw reply
* Re: [Patch v2 1/3] thermal: qcom: lmh: Add support for sm8150
From: Thara Gopinath @ 2022-01-05 19:18 UTC (permalink / raw)
To: Daniel Lezcano, agross, bjorn.andersson, rafael, rui.zhang,
robh+dt
Cc: linux-arm-msm, linux-pm, devicetree, linux-kernel
In-Reply-To: <62f98846-0126-86ee-9bbd-f7abd03a4791@linaro.org>
On 12/20/21 7:04 AM, Daniel Lezcano wrote:
> On 15/12/2021 17:33, Thara Gopinath wrote:
>> Add compatible to support LMh for sm8150 SoC.
>> sm8150 does not require explicit enabling for various LMh subsystems.
>> Add a variable indicating the same as match data which is set for sdm845.
>> Execute the piece of code enabling various LMh subsystems only if
>> enable algorithm match data is present.
>>
>> Signed-off-by: Thara Gopinath <thara.gopinath@linaro.org>
>> ---
>>
>> v1->v2:
>> - Added LMH_ENABLE_ALGOS of_device_id match data to indicate
>> whether LMh subsytems need explicit enabling or not.
>>
>> drivers/thermal/qcom/lmh.c | 62 +++++++++++++++++++++-----------------
>> 1 file changed, 35 insertions(+), 27 deletions(-)
>>
>> diff --git a/drivers/thermal/qcom/lmh.c b/drivers/thermal/qcom/lmh.c
>> index eafa7526eb8b..80d26d043498 100644
>> --- a/drivers/thermal/qcom/lmh.c
>> +++ b/drivers/thermal/qcom/lmh.c
>> @@ -28,6 +28,8 @@
>>
>> #define LMH_REG_DCVS_INTR_CLR 0x8
>>
>> +#define LMH_ENABLE_ALGOS ((void *)1)
>
> It will be nicer a probe function here
Hello Daniel,
As we discussed, there are SoCs for which all the algorithms need not be
enabled. So introducing a separate probe function for each will be
clumsy. The idea here is to use flags (currently just one to specify
whether the algorithms need to be enabled or not) to specify which
algorithms to be enabled.
--
Warm Regards
Thara (She/Her/Hers)
>
>> +
>> struct lmh_hw_data {
>> void __iomem *base;
>> struct irq_domain *domain;
>> @@ -87,6 +89,7 @@ static int lmh_probe(struct platform_device *pdev)
>> {
>> struct device *dev = &pdev->dev;
>> struct device_node *np = dev->of_node;
>> + const struct of_device_id *of_id;
>> struct device_node *cpu_node;
>> struct lmh_hw_data *lmh_data;
>> int temp_low, temp_high, temp_arm, cpu_id, ret;
>> @@ -141,32 +144,36 @@ static int lmh_probe(struct platform_device *pdev)
>> if (!qcom_scm_lmh_dcvsh_available())
>> return -EINVAL;
>>
>> - ret = qcom_scm_lmh_dcvsh(LMH_SUB_FN_CRNT, LMH_ALGO_MODE_ENABLE, 1,
>> - LMH_NODE_DCVS, node_id, 0);
>> - if (ret)
>> - dev_err(dev, "Error %d enabling current subfunction\n", ret);
>> -
>> - ret = qcom_scm_lmh_dcvsh(LMH_SUB_FN_REL, LMH_ALGO_MODE_ENABLE, 1,
>> - LMH_NODE_DCVS, node_id, 0);
>> - if (ret)
>> - dev_err(dev, "Error %d enabling reliability subfunction\n", ret);
>> -
>> - ret = qcom_scm_lmh_dcvsh(LMH_SUB_FN_BCL, LMH_ALGO_MODE_ENABLE, 1,
>> - LMH_NODE_DCVS, node_id, 0);
>> - if (ret)
>> - dev_err(dev, "Error %d enabling BCL subfunction\n", ret);
>> -
>> - ret = qcom_scm_lmh_dcvsh(LMH_SUB_FN_THERMAL, LMH_ALGO_MODE_ENABLE, 1,
>> - LMH_NODE_DCVS, node_id, 0);
>> - if (ret) {
>> - dev_err(dev, "Error %d enabling thermal subfunction\n", ret);
>> - return ret;
>> - }
>> -
>> - ret = qcom_scm_lmh_profile_change(0x1);
>> - if (ret) {
>> - dev_err(dev, "Error %d changing profile\n", ret);
>> - return ret;
>> + of_id = of_match_device(dev->driver->of_match_table, dev);
>> +
>> + if (of_id && of_id->data == LMH_ENABLE_ALGOS) {
>> + ret = qcom_scm_lmh_dcvsh(LMH_SUB_FN_CRNT, LMH_ALGO_MODE_ENABLE, 1,
>> + LMH_NODE_DCVS, node_id, 0);
>> + if (ret)
>> + dev_err(dev, "Error %d enabling current subfunction\n", ret);
>> +
>> + ret = qcom_scm_lmh_dcvsh(LMH_SUB_FN_REL, LMH_ALGO_MODE_ENABLE, 1,
>> + LMH_NODE_DCVS, node_id, 0);
>> + if (ret)
>> + dev_err(dev, "Error %d enabling reliability subfunction\n", ret);
>> +
>> + ret = qcom_scm_lmh_dcvsh(LMH_SUB_FN_BCL, LMH_ALGO_MODE_ENABLE, 1,
>> + LMH_NODE_DCVS, node_id, 0);
>> + if (ret)
>> + dev_err(dev, "Error %d enabling BCL subfunction\n", ret);
>> +
>> + ret = qcom_scm_lmh_dcvsh(LMH_SUB_FN_THERMAL, LMH_ALGO_MODE_ENABLE, 1,
>> + LMH_NODE_DCVS, node_id, 0);
>> + if (ret) {
>> + dev_err(dev, "Error %d enabling thermal subfunction\n", ret);
>> + return ret;
>> + }
>> +
>> + ret = qcom_scm_lmh_profile_change(0x1);
>> + if (ret) {
>> + dev_err(dev, "Error %d changing profile\n", ret);
>> + return ret;
>> + }
>> }
>>
>> /* Set default thermal trips */
>> @@ -213,7 +220,8 @@ static int lmh_probe(struct platform_device *pdev)
>> }
>>
>> static const struct of_device_id lmh_table[] = {
>> - { .compatible = "qcom,sdm845-lmh", },
>> + { .compatible = "qcom,sdm845-lmh", .data = LMH_ENABLE_ALGOS},
>> + { .compatible = "qcom,sm8150-lmh", },
>> {}
>> };
>> MODULE_DEVICE_TABLE(of, lmh_table);
>>
>
>
^ permalink raw reply
* Re: [PATCH v2 8/8] merge-tree: provide an easy way to access which files have conflicts
From: Elijah Newren @ 2022-01-05 19:17 UTC (permalink / raw)
To: Ramsay Jones
Cc: Elijah Newren via GitGitGadget, Git Mailing List,
Christian Couder, Taylor Blau, Johannes Altmanninger
In-Reply-To: <ed528125-a2bb-9445-80c5-8c2994ef0d56@ramsayjones.plus.com>
On Wed, Jan 5, 2022 at 11:09 AM Ramsay Jones
<ramsay@ramsayjones.plus.com> wrote:
>
> On 05/01/2022 17:27, Elijah Newren via GitGitGadget wrote:
> > From: Elijah Newren <newren@gmail.com>
> >
> > Callers of `git merge-tree --real` might want an easy way to determine
> > which files conflicted. While they could potentially use the --messages
> > option and parse the resulting messages written to that file, those
> > messages are not meant to be machine readable. Provide a simpler
> > mechanism of having the user specify --unmerged-list=$FILENAME, and then
>
> s/unmerged-list/conflicted-list/
Indeed. I had noticed after v1 that I had a mixture of using both
"unmerged" and "conflicted" to refer to the same thing, and tried to
fix it by always using the latter term. Unfortunately, I missed
updating this commit message. Thanks for pointing it out; will fix.
^ permalink raw reply
* Re: [PATCH] tracing/kprobes: 'nmissed' not showed correctly for kretprobe
From: Steven Rostedt @ 2022-01-05 19:15 UTC (permalink / raw)
To: Xiangyang Zhang
Cc: mingo, masami.hiramatsu.pt, oleg, namhyung.kim, linux-kernel
In-Reply-To: <20211211150032.7568-1-xyz.sun.ok@gmail.com>
On Sat, 11 Dec 2021 23:00:32 +0800
Xiangyang Zhang <xyz.sun.ok@gmail.com> wrote:
> The 'nmissed' column of the 'kprobe_profile' file for kretprobe is
> always zero, because 'nmissed' for kretprobe is maintained in
> 'tk->rp.nmissed' but not in 'tk->rp.kp.nmissed'
>
> Fixes: c31ffb3ff633 ("tracing/kprobes: Factor out struct trace_probe")
> Signed-off-by: Xiangyang Zhang <xyz.sun.ok@gmail.com>
> ---
> kernel/trace/trace_kprobe.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/kernel/trace/trace_kprobe.c b/kernel/trace/trace_kprobe.c
> index d10c01948e68..2b9de6826e94 100644
> --- a/kernel/trace/trace_kprobe.c
> +++ b/kernel/trace/trace_kprobe.c
> @@ -1175,15 +1175,17 @@ static int probes_profile_seq_show(struct seq_file *m, void *v)
> {
> struct dyn_event *ev = v;
> struct trace_kprobe *tk;
> + unsigned long nmissed = 0;
No need to initialize this to zero, the first use is an assignment.
>
> if (!is_trace_kprobe(ev))
> return 0;
>
> tk = to_trace_kprobe(ev);
> + nmissed = tk->rp.handler ? tk->rp.nmissed : tk->rp.kp.nmissed;
> seq_printf(m, " %-44s %15lu %15lu\n",
> trace_probe_name(&tk->tp),
> trace_kprobe_nhit(tk),
> - tk->rp.kp.nmissed);
> + nmissed);
Masami, what's your thoughts on this patch?
-- Steve
>
> return 0;
> }
^ permalink raw reply
* [Intel-wired-lan] [next-queue, v2] i40e: Remove unused RX realloc stat
From: Jesse Brandeburg @ 2022-01-05 19:15 UTC (permalink / raw)
To: intel-wired-lan
In-Reply-To: <1641397753-121138-1-git-send-email-jdamato@fastly.com>
On 1/5/2022 7:49 AM, Joe Damato wrote:
> After commit 1a557afc4dd5 ("i40e: Refactor receive routine"),
> rx_stats.realloc_count is no longer being incremented, so remove it.
>
> The debugfs string was left, but hardcoded to 0. This is intended to
> prevent breaking any existing code / scripts that are parsing debugfs
> for i40e.
>
> Fixes: 1a557afc4dd5 ("i40e: Refactor receive routine")
> Signed-off-by: Joe Damato <jdamato@fastly.com>
>
> ---
> v1 -> v2: Fix commit message to include one-line SHA summary. Patch is now
> based on next-queue.
Reviewed-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
^ permalink raw reply
* Re: [PATCH][TRIVIAL] btrfs-progs: Allow autodetect_object_types() to handle the link.
From: Goffredo Baroncelli @ 2022-01-05 19:14 UTC (permalink / raw)
To: Boris Burkov; +Cc: linux-btrfs
In-Reply-To: <YdXsD+oQ8Z3DNYtG@zen>
On 05/01/2022 20.05, Boris Burkov wrote:
> On Wed, Jan 05, 2022 at 07:23:33PM +0100, Goffredo Baroncelli wrote:
>> On 05/01/2022 18.50, Boris Burkov wrote:
>>> On Wed, Jan 05, 2022 at 02:32:58PM +0100, Goffredo Baroncelli wrote:
>>>> From: Goffredo Baroncelli <kreijack@inwind.it>
>> [...]
>>>
>>> I took a look at the original lstat and it doesn't seem super strongly
>>> motivated. It is used to detect a subvolume object (ino==256) so I don't
>>> see why we would hate to have property get/set work on a symlink to a
>>> subvol.
>>
>> It is not so simple: think about a case where the symlink points to a
>> subvolume of *another* filesystem.
>>
>> Now, "btrfs prop get" returns the property (e.g. the label) of the *underlining*
>> filesystem. If we change statl to stat, it still return the property of the
>> underlining filesystem, thinking that it is a subvolume (of a foreign filesystem).
>>
>> If fact I added an exception of that rule, because if we pass a block device, we
>> don't consider the underling filesystem, but the filesystem contained in the block
>> device. But there is a precedence in get/set label.
>>
>> Anyway, symlink created some confusion, and I bet that in btrfs there are areas
>> with incoherence around symlink between the pointed object and the underling
>> filesystem.
>
> Good point. I agree that btrfs (the tool) is not the most rigorous with
> symlinks. In this very function, we check if it is a btrfs object by
> opening the file without O_NOFOLLOW, but then we do this lstat.
>
> I'm not exactly sure what you are alluding to regarding the precedent set
> by label, but I tested links and labels and it seems to exhibit the link
> following behavior.
>
> mkfs.btrfs -f /dev/loop0
> mkfs.btrfs -f -L LOOP /dev/loop1
> mount /dev/loop0 /mnt/0
> mount /dev/loop1 /mnt/1
> ln -s /mnt/1 /mnt/0/lnk
> btrfs property get /mnt/0 label
> label=
> btrfs property get /mnt/1 label
> label=LOOP
> btrfs property get /mnt/0/lnk label
> label=LOOP
> btrfs property get /mnt/0/lnk ro
> ERROR: object is not compatible with property: ro
>
> So it looks like root detection follows links but subvol detection does
> not. Without testing, but judging by the code, I think inode follows
> symlinks too. So with all that said, I think the most consistent is to
> make subvol follow the symlink, unless you have a really confusing
> unexpected behavior in mind with links out to another btrfs that I am
> failing to see.
Hi Boris,
you are right. I didn't consider that open(path) follows the symlink too.
So I will update the patch changing statl() to stat() and removing the
2nd stat invocation.
BR
G.Baroncelli
> Thanks,
> Boris
>
>>
>> BR
>> G.Baroncelli
>>
>> --
>> gpg @keyserver.linux.it: Goffredo Baroncelli <kreijackATinwind.it>
>> Key fingerprint BBF5 1610 0B64 DAC6 5F7D 17B2 0EDA 9B37 8B82 E0B5
--
gpg @keyserver.linux.it: Goffredo Baroncelli <kreijackATinwind.it>
Key fingerprint BBF5 1610 0B64 DAC6 5F7D 17B2 0EDA 9B37 8B82 E0B5
^ permalink raw reply
* Re: [PATCH v5 7/8] KVM: VMX: Update PID-pointer table entry when APIC ID is changed
From: Tom Lendacky @ 2022-01-05 19:13 UTC (permalink / raw)
To: Zeng Guang, Paolo Bonzini, Sean Christopherson, Vitaly Kuznetsov,
Wanpeng Li, Jim Mattson, Joerg Roedel, kvm, Dave Hansen,
Tony Luck, Kan Liang, Thomas Gleixner, Ingo Molnar,
Borislav Petkov, H. Peter Anvin, Kim Phillips, Jarkko Sakkinen,
Jethro Beekman, Kai Huang
Cc: x86, linux-kernel, Robert Hu, Gao Chao
In-Reply-To: <20211231142849.611-8-guang.zeng@intel.com>
On 12/31/21 8:28 AM, Zeng Guang wrote:
> In xAPIC mode, guest is allowed to modify APIC ID at runtime.
> If IPI virtualization is enabled, corresponding entry in
> PID-pointer table need change accordingly.
>
> Signed-off-by: Zeng Guang <guang.zeng@intel.com>
> ---
> arch/x86/include/asm/kvm_host.h | 1 +
> arch/x86/kvm/lapic.c | 7 +++++--
> arch/x86/kvm/vmx/vmx.c | 12 ++++++++++++
> 3 files changed, 18 insertions(+), 2 deletions(-)
>
> diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
> index 2164b9f4c7b0..753bf2a7cebc 100644
> --- a/arch/x86/include/asm/kvm_host.h
> +++ b/arch/x86/include/asm/kvm_host.h
> @@ -1493,6 +1493,7 @@ struct kvm_x86_ops {
> int (*complete_emulated_msr)(struct kvm_vcpu *vcpu, int err);
>
> void (*vcpu_deliver_sipi_vector)(struct kvm_vcpu *vcpu, u8 vector);
> + void (*update_ipiv_pid_entry)(struct kvm_vcpu *vcpu, u8 old_id, u8 new_id);
> };
>
> struct kvm_x86_nested_ops {
> diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c
> index 3ce7142ba00e..83c2c7594bcd 100644
> --- a/arch/x86/kvm/lapic.c
> +++ b/arch/x86/kvm/lapic.c
> @@ -2007,9 +2007,12 @@ int kvm_lapic_reg_write(struct kvm_lapic *apic, u32 reg, u32 val)
>
> switch (reg) {
> case APIC_ID: /* Local APIC ID */
> - if (!apic_x2apic_mode(apic))
> + if (!apic_x2apic_mode(apic)) {
> + u8 old_id = kvm_lapic_get_reg(apic, APIC_ID) >> 24;
> +
> kvm_apic_set_xapic_id(apic, val >> 24);
> - else
> + kvm_x86_ops.update_ipiv_pid_entry(apic->vcpu, old_id, val >> 24);
Won't this blow up on AMD since there is no corresponding SVM op?
Thanks,
Tom
> + } else
> ret = 1;
> break;
>
> diff --git a/arch/x86/kvm/vmx/vmx.c b/arch/x86/kvm/vmx/vmx.c
> index 2e65464d6dee..f21ce15c5eb8 100644
> --- a/arch/x86/kvm/vmx/vmx.c
> +++ b/arch/x86/kvm/vmx/vmx.c
> @@ -7633,6 +7633,17 @@ static void vmx_vm_destroy(struct kvm *kvm)
> free_pages((unsigned long)kvm_vmx->pid_table, MAX_PID_TABLE_ORDER);
> }
>
> +static void vmx_update_ipiv_pid_entry(struct kvm_vcpu *vcpu, u8 old_id, u8 new_id)
> +{
> + if (enable_ipiv && kvm_vcpu_apicv_active(vcpu)) {
> + u64 *pid_table = to_kvm_vmx(vcpu->kvm)->pid_table;
> +
> + WRITE_ONCE(pid_table[old_id], 0);
> + WRITE_ONCE(pid_table[new_id], __pa(&to_vmx(vcpu)->pi_desc) |
> + PID_TABLE_ENTRY_VALID);
> + }
> +}
> +
> static struct kvm_x86_ops vmx_x86_ops __initdata = {
> .name = "kvm_intel",
>
> @@ -7770,6 +7781,7 @@ static struct kvm_x86_ops vmx_x86_ops __initdata = {
> .complete_emulated_msr = kvm_complete_insn_gp,
>
> .vcpu_deliver_sipi_vector = kvm_vcpu_deliver_sipi_vector,
> + .update_ipiv_pid_entry = vmx_update_ipiv_pid_entry,
> };
>
> static __init void vmx_setup_user_return_msrs(void)
>
^ permalink raw reply
* Re: psi_trigger_poll() is completely broken
From: Linus Torvalds @ 2022-01-05 19:13 UTC (permalink / raw)
To: Eric Biggers, Tejun Heo, Zefan Li
Cc: Johannes Weiner, Peter Zijlstra, Juri Lelli, Vincent Guittot,
Ingo Molnar, Hillf Danton, syzbot, linux-fsdevel,
Linux Kernel Mailing List, syzkaller-bugs, Linux-MM
In-Reply-To: <CAHk-=wjddvNbZBuvh9m_2VYFC1W7HvbP33mAzkPGOCHuVi5fJg@mail.gmail.com>
On Wed, Jan 5, 2022 at 11:07 AM Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
> Whoever came up with that stupid "replace existing trigger with a
> write()" model should feel bad. It's garbage, and it's actively buggy
> in multiple ways.
What are the users? Can we make the rule for -EBUSY simply be that you
can _install_ a trigger, but you can't replace an existing one (except
with NULL, when you close it).
That would fix the poll() lifetime issue, and would make the
psi_trigger_replace() races fairly easy to fix - just use
if (cmpxchg(trigger_ptr, NULL, new) != NULL) {
... free 'new', return -EBUSY ..
to install the new one, instead of
rcu_assign_pointer(*trigger_ptr, new);
or something like that. No locking necessary.
But I assume people actually end up re-writing triggers, because
people are perverse and have taken advantage of this completely broken
API.
Linus
^ permalink raw reply
* Re: [PATCH net-next v2] net/smc: Reduce overflow of smc clcsock listen queue
From: Karsten Graul @ 2022-01-05 19:13 UTC (permalink / raw)
To: D. Wythe; +Cc: dust.li, kuba, davem, netdev, linux-s390, linux-rdma
In-Reply-To: <20220105150612.GA75522@e02h04389.eu6sqa>
On 05/01/2022 16:06, D. Wythe wrote:
> LGTM. Fallback makes the restrictions on SMC dangling
> connections more meaningful to me, compared to dropping them.
>
> Overall, i see there are two scenario.
>
> 1. Drop the overflow connections limited by userspace application
> accept.
>
> 2. Fallback the overflow connections limited by the heavy process of
> current SMC handshake. ( We can also control its behavior through
> sysctl.)
>
I vote for (2) which makes the behavior from user space applications point of view more like TCP.
One comment to sysctl: our current approach is to add new switches to the existing
netlink interface which can be used with the smc-tools package (or own implementations of course).
Is this prereq problematic in your environment?
We tried to avoid more sysctls and the netlink interface keeps use more flexible.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.