* [PATCH v2] pwm: stm32-lp: add check in case requested period cannot be achieved
From: Fabrice Gasnier @ 2019-09-18 14:54 UTC (permalink / raw)
To: thierry.reding
Cc: linux-pwm, alexandre.torgue, linux-kernel, u.kleine-koenig,
fabrice.gasnier, linux-stm32, linux-arm-kernel
LPTimer can use a 32KHz clock for counting. It depends on clock tree
configuration. In such a case, PWM output frequency range is limited.
Although unlikely, nothing prevents user from requesting a PWM frequency
above counting clock (32KHz for instance):
- This causes (prd - 1) = 0xffff to be written in ARR register later in
the apply() routine.
This results in badly configured PWM period (and also duty_cycle).
Add a check to report an error is such a case.
Signed-off-by: Fabrice Gasnier <fabrice.gasnier@st.com>
---
Changes in v2:
- remarks from Uwe: update the comment, use dev_dbg() and print period that
cannot be reached
---
drivers/pwm/pwm-stm32-lp.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/drivers/pwm/pwm-stm32-lp.c b/drivers/pwm/pwm-stm32-lp.c
index 2211a64..97a9afa 100644
--- a/drivers/pwm/pwm-stm32-lp.c
+++ b/drivers/pwm/pwm-stm32-lp.c
@@ -59,6 +59,12 @@ static int stm32_pwm_lp_apply(struct pwm_chip *chip, struct pwm_device *pwm,
/* Calculate the period and prescaler value */
div = (unsigned long long)clk_get_rate(priv->clk) * state->period;
do_div(div, NSEC_PER_SEC);
+ if (!div) {
+ /* Clock is too slow to achieve requested period. */
+ dev_dbg(priv->chip.dev, "Can't reach %u ns\n", state->period);
+ return -EINVAL;
+ }
+
prd = div;
while (div > STM32_LPTIM_MAX_ARR) {
presc++;
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v2] pwm: atmel: Remove platform_device_id and use only dt bindings
From: Kamel Bouhara @ 2019-09-18 14:57 UTC (permalink / raw)
To: Claudiu Beznea, Thierry Reding, linux-pwm, linux-kernel
Cc: Kamel Bouhara, Alexandre Belloni, Gregory Clement,
Ludovic Desroches, Thomas Petazzoni, linux-arm-kernel
Since commit 26202873bb51 ("avr32: remove support for AVR32
architecture") there is no more user of platform_device_id and we
should only use dt bindings
Signed-off-by: Kamel Bouhara <kamel.bouhara@bootlin.com>
---
Changelog:
v1->v2
- Remove whole function atmel_pwm_get_driver_data and call
of_device_get_match_data from atmel_pwm_probe
drivers/pwm/Kconfig | 2 +-
drivers/pwm/pwm-atmel.c | 35 +++--------------------------------
2 files changed, 4 insertions(+), 33 deletions(-)
diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig
index a7e57516959e..b51fb1a33aa2 100644
--- a/drivers/pwm/Kconfig
+++ b/drivers/pwm/Kconfig
@@ -44,7 +44,7 @@ config PWM_AB8500
config PWM_ATMEL
tristate "Atmel PWM support"
- depends on ARCH_AT91
+ depends on ARCH_AT91 && OF
help
Generic PWM framework driver for Atmel SoC.
diff --git a/drivers/pwm/pwm-atmel.c b/drivers/pwm/pwm-atmel.c
index e5e1eaf372fa..f7cf0a86a37c 100644
--- a/drivers/pwm/pwm-atmel.c
+++ b/drivers/pwm/pwm-atmel.c
@@ -318,19 +318,6 @@ static const struct atmel_pwm_data mchp_sam9x60_pwm_data = {
},
};
-static const struct platform_device_id atmel_pwm_devtypes[] = {
- {
- .name = "at91sam9rl-pwm",
- .driver_data = (kernel_ulong_t)&atmel_sam9rl_pwm_data,
- }, {
- .name = "sama5d3-pwm",
- .driver_data = (kernel_ulong_t)&atmel_sama5_pwm_data,
- }, {
- /* sentinel */
- },
-};
-MODULE_DEVICE_TABLE(platform, atmel_pwm_devtypes);
-
static const struct of_device_id atmel_pwm_dt_ids[] = {
{
.compatible = "atmel,at91sam9rl-pwm",
@@ -350,19 +337,6 @@ static const struct of_device_id atmel_pwm_dt_ids[] = {
};
MODULE_DEVICE_TABLE(of, atmel_pwm_dt_ids);
-static inline const struct atmel_pwm_data *
-atmel_pwm_get_driver_data(struct platform_device *pdev)
-{
- const struct platform_device_id *id;
-
- if (pdev->dev.of_node)
- return of_device_get_match_data(&pdev->dev);
-
- id = platform_get_device_id(pdev);
-
- return (struct atmel_pwm_data *)id->driver_data;
-}
-
static int atmel_pwm_probe(struct platform_device *pdev)
{
const struct atmel_pwm_data *data;
@@ -370,7 +344,7 @@ static int atmel_pwm_probe(struct platform_device *pdev)
struct resource *res;
int ret;
- data = atmel_pwm_get_driver_data(pdev);
+ data = of_device_get_match_data(&pdev->dev);
if (!data)
return -ENODEV;
@@ -396,10 +370,8 @@ static int atmel_pwm_probe(struct platform_device *pdev)
atmel_pwm->chip.dev = &pdev->dev;
atmel_pwm->chip.ops = &atmel_pwm_ops;
- if (pdev->dev.of_node) {
- atmel_pwm->chip.of_xlate = of_pwm_xlate_with_flags;
- atmel_pwm->chip.of_pwm_n_cells = 3;
- }
+ atmel_pwm->chip.of_xlate = of_pwm_xlate_with_flags;
+ atmel_pwm->chip.of_pwm_n_cells = 3;
atmel_pwm->chip.base = -1;
atmel_pwm->chip.npwm = 4;
@@ -437,7 +409,6 @@ static struct platform_driver atmel_pwm_driver = {
.name = "atmel-pwm",
.of_match_table = of_match_ptr(atmel_pwm_dt_ids),
},
- .id_table = atmel_pwm_devtypes,
.probe = atmel_pwm_probe,
.remove = atmel_pwm_remove,
};
--
2.23.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [GIT PULL] fixes for omaps for v5.4 merge window
From: Tony Lindgren @ 2019-09-18 15:10 UTC (permalink / raw)
To: soc; +Cc: Tony Lindgren, linux-omap, arm, linux-arm-kernel
From: "Tony Lindgren" <tony@atomide.com>
The following changes since commit 4a65bbb9109ed7edd4b6ed7168ced48abb8561a2:
soc: ti: pm33xx: Make two symbols static (2019-08-13 05:05:38 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap tags/fixes-5.4-merge-window
for you to fetch changes up to a4c8723a162e6244fb01944fbf446750575dba59:
bus: ti-sysc: Remove unpaired sysc_clkdm_deny_idle() (2019-09-06 12:57:46 -0700)
----------------------------------------------------------------
Fixes for omap variants
Few fixes for ti-sysc interconnect target module driver for no-idle
quirks that caused nfsroot to fail on some dra7 boards.
And let's fixes to get LCD working again for logicpd board that got
broken a while back with removal of panel-dpi driver. We need to now
use generic CONFIG_DRM_PANEL_SIMPLE instead.
----------------------------------------------------------------
Adam Ford (4):
ARM: omap2plus_defconfig: Fix missing video
ARM: dts: logicpd-torpedo-baseboard: Fix missing video
ARM: dts: am3517-evm: Fix missing video
ARM: dts: logicpd-som-lv: Fix i2c2 and i2c3 Pin mux
Tony Lindgren (3):
bus: ti-sysc: Fix clock handling for no-idle quirks
bus: ti-sysc: Fix handling of invalid clocks
bus: ti-sysc: Remove unpaired sysc_clkdm_deny_idle()
arch/arm/boot/dts/am3517-evm.dts | 23 ++---------
arch/arm/boot/dts/logicpd-som-lv.dtsi | 26 ++++++------
arch/arm/boot/dts/logicpd-torpedo-baseboard.dtsi | 37 +++--------------
arch/arm/configs/omap2plus_defconfig | 1 +
arch/arm/mach-omap2/pdata-quirks.c | 4 +-
drivers/bus/ti-sysc.c | 52 +++++++++++++++++-------
6 files changed, 64 insertions(+), 79 deletions(-)
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2] pwm: atmel: Remove platform_device_id and use only dt bindings
From: Alexandre Belloni @ 2019-09-18 15:11 UTC (permalink / raw)
To: Kamel Bouhara
Cc: linux-pwm, Gregory Clement, linux-kernel, Ludovic Desroches,
Thierry Reding, Thomas Petazzoni, Claudiu Beznea,
linux-arm-kernel
In-Reply-To: <20190918145716.32022-1-kamel.bouhara@bootlin.com>
On 18/09/2019 16:57:16+0200, Kamel Bouhara wrote:
> Since commit 26202873bb51 ("avr32: remove support for AVR32
> architecture") there is no more user of platform_device_id and we
> should only use dt bindings
>
> Signed-off-by: Kamel Bouhara <kamel.bouhara@bootlin.com>
Acked-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
>cj ---
> Changelog:
> v1->v2
>
> - Remove whole function atmel_pwm_get_driver_data and call
> of_device_get_match_data from atmel_pwm_probe
>
> drivers/pwm/Kconfig | 2 +-
> drivers/pwm/pwm-atmel.c | 35 +++--------------------------------
> 2 files changed, 4 insertions(+), 33 deletions(-)
>
> diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig
> index a7e57516959e..b51fb1a33aa2 100644
> --- a/drivers/pwm/Kconfig
> +++ b/drivers/pwm/Kconfig
> @@ -44,7 +44,7 @@ config PWM_AB8500
>
> config PWM_ATMEL
> tristate "Atmel PWM support"
> - depends on ARCH_AT91
> + depends on ARCH_AT91 && OF
> help
> Generic PWM framework driver for Atmel SoC.
>
> diff --git a/drivers/pwm/pwm-atmel.c b/drivers/pwm/pwm-atmel.c
> index e5e1eaf372fa..f7cf0a86a37c 100644
> --- a/drivers/pwm/pwm-atmel.c
> +++ b/drivers/pwm/pwm-atmel.c
> @@ -318,19 +318,6 @@ static const struct atmel_pwm_data mchp_sam9x60_pwm_data = {
> },
> };
>
> -static const struct platform_device_id atmel_pwm_devtypes[] = {
> - {
> - .name = "at91sam9rl-pwm",
> - .driver_data = (kernel_ulong_t)&atmel_sam9rl_pwm_data,
> - }, {
> - .name = "sama5d3-pwm",
> - .driver_data = (kernel_ulong_t)&atmel_sama5_pwm_data,
> - }, {
> - /* sentinel */
> - },
> -};
> -MODULE_DEVICE_TABLE(platform, atmel_pwm_devtypes);
> -
> static const struct of_device_id atmel_pwm_dt_ids[] = {
> {
> .compatible = "atmel,at91sam9rl-pwm",
> @@ -350,19 +337,6 @@ static const struct of_device_id atmel_pwm_dt_ids[] = {
> };
> MODULE_DEVICE_TABLE(of, atmel_pwm_dt_ids);
>
> -static inline const struct atmel_pwm_data *
> -atmel_pwm_get_driver_data(struct platform_device *pdev)
> -{
> - const struct platform_device_id *id;
> -
> - if (pdev->dev.of_node)
> - return of_device_get_match_data(&pdev->dev);
> -
> - id = platform_get_device_id(pdev);
> -
> - return (struct atmel_pwm_data *)id->driver_data;
> -}
> -
> static int atmel_pwm_probe(struct platform_device *pdev)
> {
> const struct atmel_pwm_data *data;
> @@ -370,7 +344,7 @@ static int atmel_pwm_probe(struct platform_device *pdev)
> struct resource *res;
> int ret;
>
> - data = atmel_pwm_get_driver_data(pdev);
> + data = of_device_get_match_data(&pdev->dev);
> if (!data)
> return -ENODEV;
>
> @@ -396,10 +370,8 @@ static int atmel_pwm_probe(struct platform_device *pdev)
> atmel_pwm->chip.dev = &pdev->dev;
> atmel_pwm->chip.ops = &atmel_pwm_ops;
>
> - if (pdev->dev.of_node) {
> - atmel_pwm->chip.of_xlate = of_pwm_xlate_with_flags;
> - atmel_pwm->chip.of_pwm_n_cells = 3;
> - }
> + atmel_pwm->chip.of_xlate = of_pwm_xlate_with_flags;
> + atmel_pwm->chip.of_pwm_n_cells = 3;
>
> atmel_pwm->chip.base = -1;
> atmel_pwm->chip.npwm = 4;
> @@ -437,7 +409,6 @@ static struct platform_driver atmel_pwm_driver = {
> .name = "atmel-pwm",
> .of_match_table = of_match_ptr(atmel_pwm_dt_ids),
> },
> - .id_table = atmel_pwm_devtypes,
> .probe = atmel_pwm_probe,
> .remove = atmel_pwm_remove,
> };
> --
> 2.23.0
>
--
Alexandre Belloni, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] drm: sun8i-ui/vi: Fix layer zpos change/atomic modesetting
From: Ondřej Jirman @ 2019-09-18 15:23 UTC (permalink / raw)
To: Maxime Ripard
Cc: David Airlie, linux-kernel, dri-devel, Chen-Yu Tsai,
Daniel Vetter, linux-arm-kernel
In-Reply-To: <20190918141734.kerdbbaynwutrxf6@gilmour>
Hi,
On Wed, Sep 18, 2019 at 04:17:34PM +0200, Maxime Ripard wrote:
> Hi,
>
> On Sun, Sep 15, 2019 at 12:03:37AM +0200, megous@megous.com wrote:
> > From: Ondrej Jirman <megous@megous.com>
> >
> > There are various issues that this re-work of sun8i_[uv]i_layer_enable
> > function fixes:
> >
> > - Make sure that we re-initialize zpos on reset
> > - Minimize register updates by doing them only when state changes
> > - Fix issue where DE pipe might get disabled even if it is no longer
> > used by the layer that's currently calling sun8i_ui_layer_enable
> > - .atomic_disable callback is not really needed because .atomic_update
> > can do the disable too, so drop the duplicate code
> >
> > Signed-off-by: Ondrej Jirman <megous@megous.com>
>
> It looks like these fixes should be in separate patches. Is there any
> reason it's not the case?
Bullet points just describe the resulting effect/benefits of the change to fix
the pipe control register update issue (see the referenced e-mail).
I can maybe split off the first bullet point into a separate patch. But
I can't guarantee it will not make the original issue worse, because it might
have been hiding the other issue with register updates.
The rest is just a result of the single logical change. It doesn't work
individually, it all has the goal of fixing the issue as a whole.
If I were to split it I would have to actually re-implement .atomic_disable
callback only to remove it in the next patch. I don't see the benefit.
regards,
o.
> Maxime
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH V6 1/2] dt-bindings: mailbox: add binding doc for the ARM SMC/HVC mailbox
From: Jassi Brar @ 2019-09-18 15:31 UTC (permalink / raw)
To: Andre Przywara
Cc: mark.rutland@arm.com, devicetree@vger.kernel.org, Peng Fan,
f.fainelli@gmail.com, linux-kernel@vger.kernel.org,
robh+dt@kernel.org, dl-linux-imx, sudeep.holla@arm.com,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <20190918154654.6fb7e7f5@donnerap.cambridge.arm.com>
On Wed, Sep 18, 2019 at 9:46 AM Andre Przywara <andre.przywara@arm.com> wrote:
>
> On Wed, 18 Sep 2019 09:19:46 -0500
> Jassi Brar <jassisinghbrar@gmail.com> wrote:
>
> Hi,
>
> > On Wed, Sep 18, 2019 at 4:44 AM Andre Przywara <andre.przywara@arm.com> wrote:
> >
> > >
> > > > which needs 9 arguments to work. The fact that the fist argument is
> > > > always going to be same on a platform is just the way we use this
> > > > instruction.
> > > >
> > > > > We should be as strict as possible to avoid any security issues.
> > > > >
> > > > Any example of such a security issue?
> > >
> > > Someone finds a way to trick some mailbox client to send a crafted message to the mailbox.
> > >
> > What if someone finds a way to trick the block layer to erase 'sda' ?
>
> Yes, the Linux block driver control the whole block device, it can do whatever it wants.
>
Sorry, it doesn't make any sense.
> > That is called "bug in the code".
> > It does happen in every subsystem but we don't stop implementing new
> > features .... we write flexible code and then fix any bug.
> >
> >
> > > Do you have any example of a use case where the mailbox client needs to provide the function ID?
> > >
> > FSL_SIP_SCMI_1/2 ?
>
> Huh? Where does the SCPI or SCMI driver provide this? Those clients don't even provide any arguments. Adding some would defeat the whole point of having this mailbox in the first place, which was to provide a drop-in replacement for a hardware mailbox device used on other platforms.
>
SCPI/SCMI implementation is broken. I did NAK it.
With the 'smc' mailbox you may get away without have to program the
channel before transmit, but not every controller is natively so.
> > But that is not the main point, which is to be consistent (not
> > ignoring first argument because someone may find a bug to exploit) and
> > flexible.
>
> Please read the SMCCC[1]: The first argument is in r1/w1/x1. r0/w0 is the function ID, and this is a specific value (fixed by the firmware implementation, see Peng's ATF patch) and not up to be guessed by a client.
>
The first argument of smc call is the function-id
arm_smccc_hvc(function_id, arg0, arg1, arg2, arg3, arg4, arg5, 0, &res);
>
> That's why I think the function ID (which is part of the SMCCC protocol, not of the mailbox service!) should just be set in the controller DT node and nowhere else.
>
Actually that is the very reason func-id should be a client thing and
passed via client's DT node :)
It is general understanding that protocol specific bits should not be
a part of controller driver, but the client(protocol) driver.
Page-7 Function-ID specifies :-
1) The service to be invoked.
2) The function to be invoked.
3) The calling convention (32-bit or 64-bit) that is in use.
4) The call type (fast or yielding) that is in use.
Even if we turn blind to 2,3 & 4, but (1) shouts like a runtime property.
Thanks.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2] iommu/arm-smmu: Report USF more clearly
From: Doug Anderson @ 2019-09-18 15:32 UTC (permalink / raw)
To: Robin Murphy
Cc: list@263.net:IOMMU DRIVERS <iommu@lists.linux-foundation.org>, Joerg Roedel <joro@8bytes.org>, ,
Will Deacon,
list@263.net:IOMMU DRIVERS <iommu@lists.linux-foundation.org>, Joerg Roedel <joro@8bytes.org>, ,
Linux ARM
In-Reply-To: <4febe7a87a95ed607b4dc68ba96b15210df84e9e.1568731534.git.robin.murphy@arm.com>
Hi,
On Tue, Sep 17, 2019 at 7:45 AM Robin Murphy <robin.murphy@arm.com> wrote:
>
> Although CONFIG_ARM_SMMU_DISABLE_BYPASS_BY_DEFAULT is a welcome tool
> for smoking out inadequate firmware, the failure mode is non-obvious
> and can be confusing for end users. Add some special-case reporting of
> Unidentified Stream Faults to help clarify this particular symptom.
> Since we're adding yet another print to the mix, also break out an
> explicit ratelimit state to make sure everything stays together (and
> reduce the static storage footprint a little).
>
> CC: Douglas Anderson <dianders@chromium.org>
nit: Cc, not CC.
> Signed-off-by: Robin Murphy <robin.murphy@arm.com>
> ---
> drivers/iommu/arm-smmu.c | 21 ++++++++++++++++-----
> drivers/iommu/arm-smmu.h | 2 ++
> 2 files changed, 18 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
> index b7cf24402a94..b27020fd6c90 100644
> --- a/drivers/iommu/arm-smmu.c
> +++ b/drivers/iommu/arm-smmu.c
> @@ -36,6 +36,7 @@
> #include <linux/pci.h>
> #include <linux/platform_device.h>
> #include <linux/pm_runtime.h>
> +#include <linux/ratelimit.h>
> #include <linux/slab.h>
>
> #include <linux/amba/bus.h>
> @@ -485,6 +486,8 @@ static irqreturn_t arm_smmu_global_fault(int irq, void *dev)
> {
> u32 gfsr, gfsynr0, gfsynr1, gfsynr2;
> struct arm_smmu_device *smmu = dev;
> + static DEFINE_RATELIMIT_STATE(rs, DEFAULT_RATELIMIT_INTERVAL,
> + DEFAULT_RATELIMIT_BURST);
>
> gfsr = arm_smmu_gr0_read(smmu, ARM_SMMU_GR0_sGFSR);
> gfsynr0 = arm_smmu_gr0_read(smmu, ARM_SMMU_GR0_sGFSYNR0);
> @@ -494,11 +497,19 @@ static irqreturn_t arm_smmu_global_fault(int irq, void *dev)
> if (!gfsr)
> return IRQ_NONE;
>
> - dev_err_ratelimited(smmu->dev,
> - "Unexpected global fault, this could be serious\n");
> - dev_err_ratelimited(smmu->dev,
> - "\tGFSR 0x%08x, GFSYNR0 0x%08x, GFSYNR1 0x%08x, GFSYNR2 0x%08x\n",
> - gfsr, gfsynr0, gfsynr1, gfsynr2);
> + if (__ratelimit(&rs)) {
> + if (IS_ENABLED(CONFIG_ARM_SMMU_DISABLE_BYPASS_BY_DEFAULT) &&
> + (gfsr & sGFSR_USF))
> + dev_err(smmu->dev,
> + "Blocked unknown Stream ID 0x%hx; boot with \"arm-smmu.disable_bypass=0\" to allow, but this may have security implications\n",
optional nit: "%#hx" instead of "0x%hx"
Reviewed-by: Douglas Anderson <dianders@chromium.org>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 1/5] iommu: Implement iommu_put_resv_regions_simple()
From: Will Deacon @ 2019-09-18 15:37 UTC (permalink / raw)
To: Thierry Reding
Cc: Jean-Philippe Brucker, Robin Murphy, Joerg Roedel, linux-kernel,
virtualization, iommu, David Woodhouse, linux-arm-kernel
In-Reply-To: <20190829111752.17513-2-thierry.reding@gmail.com>
On Thu, Aug 29, 2019 at 01:17:48PM +0200, Thierry Reding wrote:
> From: Thierry Reding <treding@nvidia.com>
>
> Implement a generic function for removing reserved regions. This can be
> used by drivers that don't do anything fancy with these regions other
> than allocating memory for them.
>
> Signed-off-by: Thierry Reding <treding@nvidia.com>
> ---
> drivers/iommu/iommu.c | 19 +++++++++++++++++++
> include/linux/iommu.h | 2 ++
> 2 files changed, 21 insertions(+)
>
> diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
> index 0f585b614657..73a2a6b13507 100644
> --- a/drivers/iommu/iommu.c
> +++ b/drivers/iommu/iommu.c
> @@ -2170,6 +2170,25 @@ void iommu_put_resv_regions(struct device *dev, struct list_head *list)
> ops->put_resv_regions(dev, list);
> }
>
> +/**
> + * iommu_put_resv_regions_simple - Reserved region driver helper
> + * @dev: device for which to free reserved regions
> + * @list: reserved region list for device
> + *
> + * IOMMU drivers can use this to implement their .put_resv_regions() callback
> + * for simple reservations. Memory allocated for each reserved region will be
> + * freed. If an IOMMU driver allocates additional resources per region, it is
> + * going to have to implement a custom callback.
> + */
> +void iommu_put_resv_regions_simple(struct device *dev, struct list_head *list)
> +{
> + struct iommu_resv_region *entry, *next;
> +
> + list_for_each_entry_safe(entry, next, list, list)
> + kfree(entry);
> +}
> +EXPORT_SYMBOL(iommu_put_resv_regions_simple);
Can you call this directly from iommu_put_resv_regions() if the function
pointer in ops is NULL? That would save having to plumb the default callback
into a bunch of drivers.
Will
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Applied "ASoC: atmel_ssc_dai: Remove wrong spinlock usage" to the asoc tree
From: Mark Brown @ 2019-09-18 10:14 UTC (permalink / raw)
To: Gregory CLEMENT
Cc: Alexandre Belloni, alsa-devel, linux-kernel, Liam Girdwood,
Ludovic Desroches, Mark Brown, Codrin Ciubotariu,
linux-arm-kernel
In-Reply-To: <20190918100344.23629-1-gregory.clement@bootlin.com>
The patch
ASoC: atmel_ssc_dai: Remove wrong spinlock usage
has been applied to the asoc tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-5.4
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
From 0dce49efc70536a8c3b4bb5354a71b727ba31b80 Mon Sep 17 00:00:00 2001
From: Gregory CLEMENT <gregory.clement@bootlin.com>
Date: Wed, 18 Sep 2019 12:03:44 +0200
Subject: [PATCH] ASoC: atmel_ssc_dai: Remove wrong spinlock usage
A potential bug was reported in the email "[BUG] atmel_ssc_dai: a
possible sleep-in-atomic bug in atmel_ssc_shutdown"[1]
Indeed in the function atmel_ssc_shutdown() free_irq() was called in a
critical section protected by spinlock.
However this spinlock is only used in atmel_ssc_shutdown() and
atmel_ssc_startup() functions. After further analysis, it occurred that
the call to these function are already protected by mutex used on the
calling functions.
Then we can remove the spinlock which will fix this bug as a side
effect. Thanks to this patch the following message disappears:
"BUG: sleeping function called from invalid context at
kernel/locking/mutex.c:909"
[1]: https://www.spinics.net/lists/alsa-devel/msg71286.html
Reviewed-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com>
Link: https://lore.kernel.org/r/20190918100344.23629-1-gregory.clement@bootlin.com
Signed-off-by: Mark Brown <broonie@kernel.org>
---
sound/soc/atmel/atmel_ssc_dai.c | 12 ++----------
sound/soc/atmel/atmel_ssc_dai.h | 1 -
2 files changed, 2 insertions(+), 11 deletions(-)
diff --git a/sound/soc/atmel/atmel_ssc_dai.c b/sound/soc/atmel/atmel_ssc_dai.c
index 48e9eef34c0f..ca603397651c 100644
--- a/sound/soc/atmel/atmel_ssc_dai.c
+++ b/sound/soc/atmel/atmel_ssc_dai.c
@@ -116,19 +116,16 @@ static struct atmel_pcm_dma_params ssc_dma_params[NUM_SSC_DEVICES][2] = {
static struct atmel_ssc_info ssc_info[NUM_SSC_DEVICES] = {
{
.name = "ssc0",
- .lock = __SPIN_LOCK_UNLOCKED(ssc_info[0].lock),
.dir_mask = SSC_DIR_MASK_UNUSED,
.initialized = 0,
},
{
.name = "ssc1",
- .lock = __SPIN_LOCK_UNLOCKED(ssc_info[1].lock),
.dir_mask = SSC_DIR_MASK_UNUSED,
.initialized = 0,
},
{
.name = "ssc2",
- .lock = __SPIN_LOCK_UNLOCKED(ssc_info[2].lock),
.dir_mask = SSC_DIR_MASK_UNUSED,
.initialized = 0,
},
@@ -317,13 +314,10 @@ static int atmel_ssc_startup(struct snd_pcm_substream *substream,
snd_soc_dai_set_dma_data(dai, substream, dma_params);
- spin_lock_irq(&ssc_p->lock);
- if (ssc_p->dir_mask & dir_mask) {
- spin_unlock_irq(&ssc_p->lock);
+ if (ssc_p->dir_mask & dir_mask)
return -EBUSY;
- }
+
ssc_p->dir_mask |= dir_mask;
- spin_unlock_irq(&ssc_p->lock);
return 0;
}
@@ -355,7 +349,6 @@ static void atmel_ssc_shutdown(struct snd_pcm_substream *substream,
dir_mask = 1 << dir;
- spin_lock_irq(&ssc_p->lock);
ssc_p->dir_mask &= ~dir_mask;
if (!ssc_p->dir_mask) {
if (ssc_p->initialized) {
@@ -369,7 +362,6 @@ static void atmel_ssc_shutdown(struct snd_pcm_substream *substream,
ssc_p->cmr_div = ssc_p->tcmr_period = ssc_p->rcmr_period = 0;
ssc_p->forced_divider = 0;
}
- spin_unlock_irq(&ssc_p->lock);
/* Shutdown the SSC clock. */
pr_debug("atmel_ssc_dai: Stopping clock\n");
diff --git a/sound/soc/atmel/atmel_ssc_dai.h b/sound/soc/atmel/atmel_ssc_dai.h
index ae764cb541c7..3470b966e449 100644
--- a/sound/soc/atmel/atmel_ssc_dai.h
+++ b/sound/soc/atmel/atmel_ssc_dai.h
@@ -93,7 +93,6 @@ struct atmel_ssc_state {
struct atmel_ssc_info {
char *name;
struct ssc_device *ssc;
- spinlock_t lock; /* lock for dir_mask */
unsigned short dir_mask; /* 0=unused, 1=playback, 2=capture */
unsigned short initialized; /* true if SSC has been initialized */
unsigned short daifmt;
--
2.20.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH v12 05/12] namei: obey trailing magic-link DAC permissions
From: Aleksa Sarai @ 2019-09-18 15:46 UTC (permalink / raw)
To: Jann Horn
Cc: linux-ia64, linux-sh, Peter Zijlstra, Rasmus Villemoes,
Alexei Starovoitov, kernel list, David Howells,
open list:KERNEL SELFTEST FRAMEWORK, sparclinux, Jiri Olsa,
linux-arch, linux-s390, Tycho Andersen, Aleksa Sarai, Shuah Khan,
Alexander Shishkin, Ingo Molnar, linux-arm-kernel, linux-mips,
linux-xtensa, Kees Cook, Arnd Bergmann, linuxppc-dev, linux-m68k,
Al Viro, Andy Lutomirski, Shuah Khan, Namhyung Kim,
David Drysdale, Christian Brauner, J. Bruce Fields, linux-parisc,
Linux API, Chanho Min, Jeff Layton, Oleg Nesterov, Eric Biederman,
linux-alpha, linux-fsdevel, Andrew Morton, Linus Torvalds,
Linux Containers
In-Reply-To: <20190918135100.sdxdmdluq6wlwryv@yavin.microfocus.com>
[-- Attachment #1.1: Type: text/plain, Size: 4577 bytes --]
On 2019-09-18, Aleksa Sarai <cyphar@cyphar.com> wrote:
> On 2019-09-17, Jann Horn <jannh@google.com> wrote:
> > On Wed, Sep 4, 2019 at 10:21 PM Aleksa Sarai <cyphar@cyphar.com> wrote:
> > > The ability for userspace to "re-open" file descriptors through
> > > /proc/self/fd has been a very useful tool for all sorts of usecases
> > > (container runtimes are one common example). However, the current
> > > interface for doing this has resulted in some pretty subtle security
> > > holes. Userspace can re-open a file descriptor with more permissions
> > > than the original, which can result in cases such as /proc/$pid/exe
> > > being re-opened O_RDWR at a later date even though (by definition)
> > > /proc/$pid/exe cannot be opened for writing. When combined with O_PATH
> > > the results can get even more confusing.
> > [...]
> > > Instead we have to restrict it in such a way that it doesn't break
> > > (good) users but does block potential attackers. The solution applied in
> > > this patch is to restrict *re-opening* (not resolution through)
> > > magic-links by requiring that mode of the link be obeyed. Normal
> > > symlinks have modes of a+rwx but magic-links have other modes. These
> > > magic-link modes were historically ignored during path resolution, but
> > > they've now been re-purposed for more useful ends.
> >
> > Thanks for dealing with this issue!
> >
> > [...]
> > > diff --git a/fs/namei.c b/fs/namei.c
> > > index 209c51a5226c..54d57dad0f91 100644
> > > --- a/fs/namei.c
> > > +++ b/fs/namei.c
> > > @@ -872,7 +872,7 @@ void nd_jump_link(struct path *path)
> > >
> > > nd->path = *path;
> > > nd->inode = nd->path.dentry->d_inode;
> > > - nd->flags |= LOOKUP_JUMPED;
> > > + nd->flags |= LOOKUP_JUMPED | LOOKUP_MAGICLINK_JUMPED;
> > > }
> > [...]
> > > +static int trailing_magiclink(struct nameidata *nd, int acc_mode,
> > > + fmode_t *opath_mask)
> > > +{
> > > + struct inode *inode = nd->link_inode;
> > > + fmode_t upgrade_mask = 0;
> > > +
> > > + /* Was the trailing_symlink() a magic-link? */
> > > + if (!(nd->flags & LOOKUP_MAGICLINK_JUMPED))
> > > + return 0;
> > > +
> > > + /*
> > > + * Figure out the upgrade-mask of the link_inode. Since these aren't
> > > + * strictly POSIX semantics we don't do an acl_permission_check() here,
> > > + * so we only care that at least one bit is set for each upgrade-mode.
> > > + */
> > > + if (inode->i_mode & S_IRUGO)
> > > + upgrade_mask |= FMODE_PATH_READ;
> > > + if (inode->i_mode & S_IWUGO)
> > > + upgrade_mask |= FMODE_PATH_WRITE;
> > > + /* Restrict the O_PATH upgrade-mask of the caller. */
> > > + if (opath_mask)
> > > + *opath_mask &= upgrade_mask;
> > > + return may_open_magiclink(upgrade_mask, acc_mode);
> > > }
> >
> > This looks racy because entries in the file descriptor table can be
> > switched out as long as task->files->file_lock isn't held. Unless I'm
> > missing something, something like the following (untested) would
> > bypass this restriction:
>
> You're absolutely right -- good catch!
>
> > Perhaps you could change nd_jump_link() to "void nd_jump_link(struct
> > path *path, umode_t link_mode)", and let proc_pid_get_link() pass the
> > link_mode through from an out-argument of .proc_get_link()? Then
> > proc_fd_link() could grab the proper mode in a race-free manner. And
> > nd_jump_link() could stash the mode in the nameidata.
>
> This indeed does appear to be the simplest solution -- I'm currently
> testing a variation of the patch you proposed (with a few extra bits to
> deal with nd_jump_link and proc_get_link being used elsewhere).
>
> I'll include this change (assuming it fixes the flaw you found) in the
> v13 series I'll send around next week. Thanks, Jann!
In case you're interested -- I've also included a selftest based on this
attack in my series (though it uses CLONE_FILES so that we could also
test O_EMPTYPATH, which wasn't affected because it didn't go through
procfs and thus couldn't hit the "outdated inode->i_mode" problem).
The attack script succeeds around 20% of the time on the original
patchset, and with the updated patchset it doesn't succeed in several
hundred thousand attempts (which I've repeated a few times).
--
Aleksa Sarai
Senior Software Engineer (Containers)
SUSE Linux GmbH
<https://www.cyphar.com/>
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: printk() + memory offline deadlock (WAS Re: page_alloc.shuffle=1 + CONFIG_PROVE_LOCKING=y = arm64 hang)
From: Sergey Senozhatsky @ 2019-09-18 15:50 UTC (permalink / raw)
To: Qian Cai
Cc: Petr Mladek, Theodore Ts'o, Sergey Senozhatsky, Arnd Bergmann,
Peter Zijlstra, Catalin Marinas, linux-kernel, Steven Rostedt,
linux-mm, Greg Kroah-Hartman, Waiman Long, Dan Williams,
Will Deacon, Thomas Gleixner, linux-arm-kernel
In-Reply-To: <1568817579.5576.172.camel@lca.pw>
On (09/18/19 10:39), Qian Cai wrote:
> > Perhaps for a quick fix (and a comment that says this needs to be fixed
> > properly). I think the changes to printk() that was discussed at
> > Plumbers may also solve this properly.
>
> I assume that the new printk() stuff will also fix this deadlock between
> printk() and memory offline.
Mother chicken...
Do you actually see a deadlock? I'd rather expect a lockdep splat, but
anyway...
> [ 317.337595] WARNING: possible circular locking dependency detected
> [ 317.337596] 5.3.0-next-20190917+ #9 Not tainted
> [ 317.337597] ------------------------------------------------------
> [ 317.337597] test.sh/8738 is trying to acquire lock:
> [ 317.337598] ffffffffb33a4978 ((console_sem).lock){-.-.}, at:> down_trylock+0x16/0x50
>
> [ 317.337602] but task is already holding lock:
> [ 317.337602] ffff88883fff4318 (&(&zone->lock)->rlock){-.-.}, at:> start_isolate_page_range+0x1f7/0x570
>
> [ 317.337606] which lock already depends on the new lock.
>
> [ 317.337608] the existing dependency chain (in reverse order) is:
>
> [ 317.337609] -> #3 (&(&zone->lock)->rlock){-.-.}:
> [ 317.337612] __lock_acquire+0x5b3/0xb40
> [ 317.337613] lock_acquire+0x126/0x280
> [ 317.337613] _raw_spin_lock+0x2f/0x40
> [ 317.337614] rmqueue_bulk.constprop.21+0xb6/0x1160
> [ 317.337615] get_page_from_freelist+0x898/0x22c0
> [ 317.337616] __alloc_pages_nodemask+0x2f3/0x1cd0
> [ 317.337617] alloc_page_interleave+0x18/0x130
> [ 317.337618] alloc_pages_current+0xf6/0x110
> [ 317.337619] allocate_slab+0x4c6/0x19c0
> [ 317.337620] new_slab+0x46/0x70
> [ 317.337621] ___slab_alloc+0x58b/0x960
> [ 317.337621] __slab_alloc+0x43/0x70
> [ 317.337622] kmem_cache_alloc+0x354/0x460
> [ 317.337623] fill_pool+0x272/0x4b0
> [ 317.337624] __debug_object_init+0x86/0x790
> [ 317.337624] debug_object_init+0x16/0x20
> [ 317.337625] hrtimer_init+0x27/0x1e0
> [ 317.337626] init_dl_task_timer+0x20/0x40
> [ 317.337627] __sched_fork+0x10b/0x1f0
> [ 317.337627] init_idle+0xac/0x520
> [ 317.337628] idle_thread_get+0x7c/0xc0
> [ 317.337629] bringup_cpu+0x1a/0x1e0
> [ 317.337630] cpuhp_invoke_callback+0x197/0x1120
> [ 317.337630] _cpu_up+0x171/0x280
> [ 317.337631] do_cpu_up+0xb1/0x120
> [ 317.337632] cpu_up+0x13/0x20
> [ 317.337632] smp_init+0xa4/0x12d
> [ 317.337633] kernel_init_freeable+0x37e/0x76e
> [ 317.337634] kernel_init+0x11/0x12f
> [ 317.337635] ret_from_fork+0x3a/0x50
So you have debug objects enabled. Right? This thing does not behave
when it comes to printing. debug_objects are slightly problematic.
This thing does
rq->lock --> zone->lock
It takes rq->lock and then calls into __sched_fork()->hrtimer_init()->debug_objects()->MM
This doesn't look very right - a dive into MM under rq->lock.
Peter, Thomas am I wrong?
> [ 317.337635] -> #2 (&rq->lock){-.-.}:
> [ 317.337638] __lock_acquire+0x5b3/0xb40
> [ 317.337639] lock_acquire+0x126/0x280
> [ 317.337639] _raw_spin_lock+0x2f/0x40
> [ 317.337640] task_fork_fair+0x43/0x200
> [ 317.337641] sched_fork+0x29b/0x420
> [ 317.337642] copy_process+0xf3c/0x2fd0
> [ 317.337642] _do_fork+0xef/0x950
> [ 317.337643] kernel_thread+0xa8/0xe0
> [ 317.337644] rest_init+0x28/0x311
> [ 317.337645] arch_call_rest_init+0xe/0x1b
> [ 317.337645] start_kernel+0x6eb/0x724
> [ 317.337646] x86_64_start_reservations+0x24/0x26
> [ 317.337647] x86_64_start_kernel+0xf4/0xfb
> [ 317.337648] secondary_startup_64+0xb6/0xc0
pi_lock --> rq->lock
> [ 317.337649] -> #1 (&p->pi_lock){-.-.}:
> [ 317.337651] __lock_acquire+0x5b3/0xb40
> [ 317.337652] lock_acquire+0x126/0x280
> [ 317.337653] _raw_spin_lock_irqsave+0x3a/0x50
> [ 317.337653] try_to_wake_up+0xb4/0x1030
> [ 317.337654] wake_up_process+0x15/0x20
> [ 317.337655] __up+0xaa/0xc0
> [ 317.337655] up+0x55/0x60
> [ 317.337656] __up_console_sem+0x37/0x60
> [ 317.337657] console_unlock+0x3a0/0x750
> [ 317.337658] vprintk_emit+0x10d/0x340
> [ 317.337658] vprintk_default+0x1f/0x30
> [ 317.337659] vprintk_func+0x44/0xd4
> [ 317.337660] printk+0x9f/0xc5
> [ 317.337660] crng_reseed+0x3cc/0x440
> [ 317.337661] credit_entropy_bits+0x3e8/0x4f0
> [ 317.337662] random_ioctl+0x1eb/0x250
> [ 317.337663] do_vfs_ioctl+0x13e/0xa70
> [ 317.337663] ksys_ioctl+0x41/0x80
> [ 317.337664] __x64_sys_ioctl+0x43/0x4c
> [ 317.337665] do_syscall_64+0xcc/0x76c
> [ 317.337666] entry_SYSCALL_64_after_hwframe+0x49/0xbe
console_sem->lock --> pi_lock
This also covers console_sem->lock --> rq->lock, and maintains
pi_lock --> rq->lock
So we have
console_sem->lock --> pi_lock --> rq->lock
> [ 317.337667] -> #0 ((console_sem).lock){-.-.}:
> [ 317.337669] check_prev_add+0x107/0xea0
> [ 317.337670] validate_chain+0x8fc/0x1200
> [ 317.337671] __lock_acquire+0x5b3/0xb40
> [ 317.337671] lock_acquire+0x126/0x280
> [ 317.337672] _raw_spin_lock_irqsave+0x3a/0x50
> [ 317.337673] down_trylock+0x16/0x50
> [ 317.337674] __down_trylock_console_sem+0x2b/0xa0
> [ 317.337675] console_trylock+0x16/0x60
> [ 317.337676] vprintk_emit+0x100/0x340
> [ 317.337677] vprintk_default+0x1f/0x30
> [ 317.337678] vprintk_func+0x44/0xd4
> [ 317.337678] printk+0x9f/0xc5
> [ 317.337679] __dump_page.cold.2+0x73/0x210
> [ 317.337680] dump_page+0x12/0x50
> [ 317.337680] has_unmovable_pages+0x3e9/0x4b0
> [ 317.337681] start_isolate_page_range+0x3b4/0x570
> [ 317.337682] __offline_pages+0x1ad/0xa10
> [ 317.337683] offline_pages+0x11/0x20
> [ 317.337683] memory_subsys_offline+0x7e/0xc0
> [ 317.337684] device_offline+0xd5/0x110
> [ 317.337685] state_store+0xc6/0xe0
> [ 317.337686] dev_attr_store+0x3f/0x60
> [ 317.337686] sysfs_kf_write+0x89/0xb0
> [ 317.337687] kernfs_fop_write+0x188/0x240
> [ 317.337688] __vfs_write+0x50/0xa0
> [ 317.337688] vfs_write+0x105/0x290
> [ 317.337689] ksys_write+0xc6/0x160
> [ 317.337690] __x64_sys_write+0x43/0x50
> [ 317.337691] do_syscall_64+0xcc/0x76c
> [ 317.337691] entry_SYSCALL_64_after_hwframe+0x49/0xbe
zone->lock --> console_sem->lock
So then we have
zone->lock --> console_sem->lock --> pi_lock --> rq->lock
vs. the reverse chain
rq->lock --> console_sem->lock
If I get this right.
> [ 317.337693] other info that might help us debug this:
>
> [ 317.337694] Chain exists of:
> [ 317.337694] (console_sem).lock --> &rq->lock --> &(&zone->lock)->rlock
>
> [ 317.337699] Possible unsafe locking scenario:
>
> [ 317.337700] CPU0 CPU1
> [ 317.337701] ---- ----
> [ 317.337701] lock(&(&zone->lock)->rlock);
> [ 317.337703] lock(&rq->lock);
> [ 317.337705] lock(&(&zone->lock)->rlock);
> [ 317.337706] lock((console_sem).lock);
>
> [ 317.337708] *** DEADLOCK ***
>
> [ 317.337710] 8 locks held by test.sh/8738:
> [ 317.337710] #0: ffff8883940b5408 (sb_writers#4){.+.+}, at: vfs_write+0x25f/0x290
> [ 317.337713] #1: ffff889fce310280 (&of->mutex){+.+.}, at: kernfs_fop_write+0x128/0x240
> [ 317.337716] #2: ffff889feb6d4830 (kn->count#115){.+.+}, at: kernfs_fop_write+0x138/0x240
> [ 317.337720] #3: ffffffffb3762d40 (device_hotplug_lock){+.+.}, at: lock_device_hotplug_sysfs+0x16/0x50
> [ 317.337723] #4: ffff88981f0dc990 (&dev->mutex){....}, at: device_offline+0x70/0x110
> [ 317.337726] #5: ffffffffb3315250 (cpu_hotplug_lock.rw_sem){++++}, at: __offline_pages+0xbf/0xa10
> [ 317.337729] #6: ffffffffb35408b0 (mem_hotplug_lock.rw_sem){++++}, at: percpu_down_write+0x87/0x2f0
> [ 317.337732] #7: ffff88883fff4318 (&(&zone->lock)->rlock){-.-.}, at: start_isolate_page_range+0x1f7/0x570
> [ 317.337736] stack backtrace:
> [ 317.337737] CPU: 58 PID: 8738 Comm: test.sh Not tainted 5.3.0-next-20190917+ #9
> [ 317.337738] Hardware name: HPE ProLiant DL560 Gen10/ProLiant DL560 Gen10, BIOS U34 05/21/2019
> [ 317.337739] Call Trace:
> [ 317.337739] dump_stack+0x86/0xca
> [ 317.337740] print_circular_bug.cold.31+0x243/0x26e
> [ 317.337741] check_noncircular+0x29e/0x2e0
> [ 317.337742] ? debug_lockdep_rcu_enabled+0x4b/0x60
> [ 317.337742] ? print_circular_bug+0x120/0x120
> [ 317.337743] ? is_ftrace_trampoline+0x9/0x20
> [ 317.337744] ? kernel_text_address+0x59/0xc0
> [ 317.337744] ? __kernel_text_address+0x12/0x40
> [ 317.337745] check_prev_add+0x107/0xea0
> [ 317.337746] validate_chain+0x8fc/0x1200
> [ 317.337746] ? check_prev_add+0xea0/0xea0
> [ 317.337747] ? format_decode+0xd6/0x600
> [ 317.337748] ? file_dentry_name+0xe0/0xe0
> [ 317.337749] __lock_acquire+0x5b3/0xb40
> [ 317.337749] lock_acquire+0x126/0x280
> [ 317.337750] ? down_trylock+0x16/0x50
> [ 317.337751] ? vprintk_emit+0x100/0x340
> [ 317.337752] _raw_spin_lock_irqsave+0x3a/0x50
> [ 317.337753] ? down_trylock+0x16/0x50
> [ 317.337753] down_trylock+0x16/0x50
> [ 317.337754] ? vprintk_emit+0x100/0x340
> [ 317.337755] __down_trylock_console_sem+0x2b/0xa0
> [ 317.337756] console_trylock+0x16/0x60
> [ 317.337756] vprintk_emit+0x100/0x340
> [ 317.337757] vprintk_default+0x1f/0x30
> [ 317.337758] vprintk_func+0x44/0xd4
> [ 317.337758] printk+0x9f/0xc5
> [ 317.337759] ? kmsg_dump_rewind_nolock+0x64/0x64
> [ 317.337760] ? __dump_page+0x1d7/0x430
> [ 317.337760] __dump_page.cold.2+0x73/0x210
> [ 317.337761] dump_page+0x12/0x50
> [ 317.337762] has_unmovable_pages+0x3e9/0x4b0
> [ 317.337763] start_isolate_page_range+0x3b4/0x570
> [ 317.337763] ? unset_migratetype_isolate+0x280/0x280
> [ 317.337764] ? rcu_read_lock_bh_held+0xc0/0xc0
> [ 317.337765] __offline_pages+0x1ad/0xa10
> [ 317.337765] ? lock_acquire+0x126/0x280
> [ 317.337766] ? __add_memory+0xc0/0xc0
> [ 317.337767] ? __kasan_check_write+0x14/0x20
> [ 317.337767] ? __mutex_lock+0x344/0xcd0
> [ 317.337768] ? _raw_spin_unlock_irqrestore+0x49/0x50
> [ 317.337769] ? device_offline+0x70/0x110
> [ 317.337770] ? klist_next+0x1c1/0x1e0
> [ 317.337770] ? __mutex_add_waiter+0xc0/0xc0
> [ 317.337771] ? klist_next+0x10b/0x1e0
> [ 317.337772] ? klist_iter_exit+0x16/0x40
> [ 317.337772] ? device_for_each_child+0xd0/0x110
> [ 317.337773] offline_pages+0x11/0x20
> [ 317.337774] memory_subsys_offline+0x7e/0xc0
> [ 317.337774] device_offline+0xd5/0x110
> [ 317.337775] ? auto_online_blocks_show+0x70/0x70
> [ 317.337776] state_store+0xc6/0xe0
> [ 317.337776] dev_attr_store+0x3f/0x60
> [ 317.337777] ? device_match_name+0x40/0x40
> [ 317.337778] sysfs_kf_write+0x89/0xb0
> [ 317.337778] ? sysfs_file_ops+0xa0/0xa0
> [ 317.337779] kernfs_fop_write+0x188/0x240
> [ 317.337780] __vfs_write+0x50/0xa0
> [ 317.337780] vfs_write+0x105/0x290
> [ 317.337781] ksys_write+0xc6/0x160
> [ 317.337782] ? __x64_sys_read+0x50/0x50
> [ 317.337782] ? do_syscall_64+0x79/0x76c
> [ 317.337783] ? do_syscall_64+0x79/0x76c
> [ 317.337784] __x64_sys_write+0x43/0x50
> [ 317.337784] do_syscall_64+0xcc/0x76c
> [ 317.337785] ? trace_hardirqs_on_thunk+0x1a/0x20
> [ 317.337786] ? syscall_return_slowpath+0x210/0x210
> [ 317.337787] ? entry_SYSCALL_64_after_hwframe+0x3e/0xbe
> [ 317.337787] ? trace_hardirqs_off_caller+0x3a/0x150
> [ 317.337788] ? trace_hardirqs_off_thunk+0x1a/0x20
> [ 317.337789] entry_SYSCALL_64_after_hwframe+0x49/0xbe
Lovely.
-ss
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 5/8] ARM: dts: Drop bogus ahclkr clocks for dra7 mcasp 3 to 8
From: Tony Lindgren @ 2019-09-18 15:51 UTC (permalink / raw)
To: Tero Kristo
Cc: Nishanth Menon, Dave Gerlach, Keerthy, linux-kernel,
Peter Ujfalusi, Faiz Abbas, Greg Kroah-Hartman, linux-omap,
linux-arm-kernel, Roger Quadros
In-Reply-To: <931eb0e1-8024-3003-1fb3-6f6ad8b74bf9@ti.com>
* Tero Kristo <t-kristo@ti.com> [190917 07:22]:
> On 24/07/2019 09:47, Tony Lindgren wrote:
> > * Suman Anna <s-anna@ti.com> [190723 21:02]:
> > > Hi Tony,
> > >
> > > On 7/23/19 6:28 AM, Tony Lindgren wrote:
> > > > The ahclkr clkctrl clock bit 28 only exists for mcasp 1 and 2 on dra7.
> > > > Otherwise we get the following warning on beagle-x15:
> > ...
> > > > @@ -2962,9 +2958,8 @@
> > > > <SYSC_IDLE_SMART>;
> > > > /* Domains (P, C): l4per_pwrdm, l4per2_clkdm */
> > > > clocks = <&l4per2_clkctrl DRA7_L4PER2_MCASP7_CLKCTRL 0>,
> > > > - <&l4per2_clkctrl DRA7_L4PER2_MCASP7_CLKCTRL 24>,
> > > > - <&l4per2_clkctrl DRA7_L4PER2_MCASP7_CLKCTRL 28>;
> > > > - clock-names = "fck", "ahclkx", "ahclkr";
> > > > + <&l4per2_clkctrl DRA7_L4PER2_MCASP7_CLKCTRL 24>;
> > > > + clock-names = "fck", "ahclkx";
> > >
> > > The equivalent change to MCASP8 is missing.
> >
> > Thanks for spotting it, probably should be set up the same way as
> > MCASP4 too looking at the TRM.
> >
> > Tero, care to check the dra7 mcasp clocks we have defined?
>
> Sorry, missed this earlier.
>
> >
> > $ grep MCASP drivers/clk/ti/clk-7xx.c
> > { DRA7_IPU_MCASP1_CLKCTRL, dra7_mcasp1_bit_data, CLKF_SW_SUP, "ipu-clkctrl:0000:22" },
> > { DRA7_L4PER2_MCASP2_CLKCTRL, dra7_mcasp2_bit_data, CLKF_SW_SUP, "l4per2-clkctrl:0154:22" },
> > { DRA7_L4PER2_MCASP3_CLKCTRL, dra7_mcasp3_bit_data, CLKF_SW_SUP, "l4per2-clkctrl:015c:22" },
> > { DRA7_L4PER2_MCASP5_CLKCTRL, dra7_mcasp5_bit_data, CLKF_SW_SUP, "l4per2-clkctrl:016c:22" },
> > { DRA7_L4PER2_MCASP8_CLKCTRL, dra7_mcasp8_bit_data, CLKF_SW_SUP, "l4per2-clkctrl:0184:24" },
> > { DRA7_L4PER2_MCASP4_CLKCTRL, dra7_mcasp4_bit_data, CLKF_SW_SUP, "l4per2-clkctrl:018c:22" },
> > { DRA7_L4PER2_MCASP6_CLKCTRL, dra7_mcasp6_bit_data, CLKF_SW_SUP, "l4per2-clkctrl:01f8:22" },
> > { DRA7_L4PER2_MCASP7_CLKCTRL, dra7_mcasp7_bit_data, CLKF_SW_SUP, "l4per2-clkctrl:01fc:22" },
> >
> > Is bit 24 above correct for MCASP8 or should it too be 22 like
> > adjacent MCASP4 in the TRM?
>
> So yeah, mcasp8 is wrong here, should be 22 as rest of them. I did fix
> mcasp8 clocks partially when doing the conversion but missed the parenting
> here; it was completely broken before.
OK thanks, I'll post a patch to fix that and an updated mcasp dts fix.
Regards,
Tony
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: printk() + memory offline deadlock (WAS Re: page_alloc.shuffle=1 + CONFIG_PROVE_LOCKING=y = arm64 hang)
From: Sergey Senozhatsky @ 2019-09-18 15:58 UTC (permalink / raw)
To: Sergey Senozhatsky
Cc: Petr Mladek, Theodore Ts'o, Arnd Bergmann, Peter Zijlstra,
Catalin Marinas, linux-kernel, Steven Rostedt, linux-mm, Qian Cai,
Greg Kroah-Hartman, Waiman Long, Dan Williams, Will Deacon,
Thomas Gleixner, linux-arm-kernel
In-Reply-To: <20190918155059.GA158834@tigerII.localdomain>
A correction:
On (09/19/19 00:51), Sergey Senozhatsky wrote:
[..]
>
> zone->lock --> console_sem->lock
>
> So then we have
>
> zone->lock --> console_sem->lock --> pi_lock --> rq->lock
>
> vs. the reverse chain
>
> rq->lock --> console_sem->lock
^^^ zone->lock
-ss
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [GIT PULL] Mailbox changes for v5.4
From: Jassi Brar @ 2019-09-18 16:00 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Linux Kernel Mailing List, linux-arm-kernel
Hi Linus,
The following changes since commit f74c2bb98776e2de508f4d607cd519873065118e:
Linux 5.3-rc8 (2019-09-08 13:33:15 -0700)
are available in the Git repository at:
git://git.linaro.org/landing-teams/working/fujitsu/integration.git
tags/mailbox-v5.4
for you to fetch changes up to 556a0964e28c4441dcdd50fb07596fd042246bd5:
mailbox: qcom-apcs: fix max_register value (2019-09-17 00:54:29 -0500)
----------------------------------------------------------------
- qcom : enable support for ipq8074, sm1850 and sm7180.
add child device node for qcs404.
misc fixes.
- mediatek : enable support for mt8183.
misc rejig of cmdq driver.
new client-reg dt property.
- armada: use device-managed registration api
----------------------------------------------------------------
Bibby Hsieh (6):
dt-binding: gce: remove thread-num property
dt-binding: gce: add gce header file for mt8183
dt-binding: gce: add binding for gce client reg property
mailbox: mediatek: cmdq: move the CMDQ_IRQ_MASK into cmdq driver data
mailbox: mediatek: cmdq: support mt8183 gce function
mailbox: mediatek: cmdq: clear the event in cmdq initial flow
Chuhong Yuan (1):
mailbox: armada-37xx-rwtm: Use device-managed registration API
Gokul Sriram Palanisamy (2):
dt-bindings: mailbox: qom: Add ipq8074 APPS compatible
mailbox: qcom: Add support for IPQ8074 APCS
Jorge Ramirez-Ortiz (3):
mbox: qcom: add APCS child device for QCS404
mbox: qcom: replace integer with valid macro
mailbox: qcom-apcs: fix max_register value
Sibi Sankar (2):
dt-bindings: mailbox: Add APSS shared for SM8150 and SC7180 SoCs
mailbox: qcom: Add support for Qualcomm SM8150 and SC7180 SoCs
.../devicetree/bindings/mailbox/mtk-gce.txt | 23 ++-
.../bindings/mailbox/qcom,apcs-kpss-global.txt | 3 +
drivers/mailbox/armada-37xx-rwtm-mailbox.c | 14 +-
drivers/mailbox/mtk-cmdq-mailbox.c | 18 ++-
drivers/mailbox/qcom-apcs-ipc-mailbox.c | 16 +-
include/dt-bindings/gce/mt8183-gce.h | 175 +++++++++++++++++++++
include/linux/mailbox/mtk-cmdq-mailbox.h | 3 +
include/linux/soc/mediatek/mtk-cmdq.h | 3 -
8 files changed, 222 insertions(+), 33 deletions(-)
create mode 100644 include/dt-bindings/gce/mt8183-gce.h
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] [v2] arm64: fix unreachable code issue with cmpxchg
From: Nathan Chancellor @ 2019-09-18 16:02 UTC (permalink / raw)
To: Will Deacon
Cc: Mark Rutland, Arnd Bergmann, Peter Zijlstra (Intel),
Catalin Marinas, Nick Desaulniers, linux-kernel,
clang-built-linux, Andrew Murray, Thomas Gleixner,
linux-arm-kernel
In-Reply-To: <20190918090240.5cc3rfcuenefisgr@willie-the-truck>
On Wed, Sep 18, 2019 at 10:02:41AM +0100, Will Deacon wrote:
> On Tue, Sep 17, 2019 at 01:34:25PM -0700, Nathan Chancellor wrote:
> > On Tue, Sep 10, 2019 at 01:56:22PM +0200, Arnd Bergmann wrote:
> > > On arm64 build with clang, sometimes the __cmpxchg_mb is not inlined
> > > when CONFIG_OPTIMIZE_INLINING is set.
> > > Clang then fails a compile-time assertion, because it cannot tell at
> > > compile time what the size of the argument is:
> > >
> > > mm/memcontrol.o: In function `__cmpxchg_mb':
> > > memcontrol.c:(.text+0x1a4c): undefined reference to `__compiletime_assert_175'
> > > memcontrol.c:(.text+0x1a4c): relocation truncated to fit: R_AARCH64_CALL26 against undefined symbol `__compiletime_assert_175'
> > >
> > > Mark all of the cmpxchg() style functions as __always_inline to
> > > ensure that the compiler can see the result.
> > >
> > > Acked-by: Nick Desaulniers <ndesaulniers@google.com>
> > > Reported-by: Nathan Chancellor <natechancellor@gmail.com>
> > > Link: https://github.com/ClangBuiltLinux/linux/issues/648
> > > Reviewed-by: Nathan Chancellor <natechancellor@gmail.com>
> > > Tested-by: Nathan Chancellor <natechancellor@gmail.com>
> > > Reviewed-by: Andrew Murray <andrew.murray@arm.com>
> > > Tested-by: Andrew Murray <andrew.murray@arm.com>
> > > Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> > > ---
> > > v2: skip unneeded changes, as suggested by Andrew Murray
> > > ---
> > > arch/arm64/include/asm/cmpxchg.h | 6 +++---
> > > 1 file changed, 3 insertions(+), 3 deletions(-)
> > >
> > > diff --git a/arch/arm64/include/asm/cmpxchg.h b/arch/arm64/include/asm/cmpxchg.h
> > > index a1398f2f9994..f9bef42c1411 100644
> > > --- a/arch/arm64/include/asm/cmpxchg.h
> > > +++ b/arch/arm64/include/asm/cmpxchg.h
> > > @@ -62,7 +62,7 @@ __XCHG_CASE( , , mb_, 64, dmb ish, nop, , a, l, "memory")
> > > #undef __XCHG_CASE
> > >
> > > #define __XCHG_GEN(sfx) \
> > > -static inline unsigned long __xchg##sfx(unsigned long x, \
> > > +static __always_inline unsigned long __xchg##sfx(unsigned long x, \
> > > volatile void *ptr, \
> > > int size) \
> > > { \
> > > @@ -148,7 +148,7 @@ __CMPXCHG_DBL(_mb)
> > > #undef __CMPXCHG_DBL
> > >
> > > #define __CMPXCHG_GEN(sfx) \
> > > -static inline unsigned long __cmpxchg##sfx(volatile void *ptr, \
> > > +static __always_inline unsigned long __cmpxchg##sfx(volatile void *ptr, \
> > > unsigned long old, \
> > > unsigned long new, \
> > > int size) \
> > > @@ -255,7 +255,7 @@ __CMPWAIT_CASE( , , 64);
> > > #undef __CMPWAIT_CASE
> > >
> > > #define __CMPWAIT_GEN(sfx) \
> > > -static inline void __cmpwait##sfx(volatile void *ptr, \
> > > +static __always_inline void __cmpwait##sfx(volatile void *ptr, \
> > > unsigned long val, \
> > > int size) \
> > > { \
> > > --
> > > 2.20.0
> > >
> >
> > Looks like the arm64 pull request happened without this patch so clang
> > all{mod,yes}config builds are broken. Did the maintainers have any
> > further comments on it or could this make it in with the next one?
>
> Fear not! I plan to send this with some other fixes we've got for -rc1.
> I just to get my CI scripts going again (new machine), but that shouldn't
> take long.
>
> Will
Great, thank you!
Cheers,
Nathan
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: printk() + memory offline deadlock (WAS Re: page_alloc.shuffle=1 + CONFIG_PROVE_LOCKING=y = arm64 hang)
From: Qian Cai @ 2019-09-18 16:10 UTC (permalink / raw)
To: Sergey Senozhatsky
Cc: Petr Mladek, Theodore Ts'o, Sergey Senozhatsky, Arnd Bergmann,
Peter Zijlstra, Catalin Marinas, linux-kernel, Steven Rostedt,
linux-mm, Greg Kroah-Hartman, Waiman Long, Dan Williams,
Will Deacon, Thomas Gleixner, linux-arm-kernel
In-Reply-To: <20190918155059.GA158834@tigerII.localdomain>
On Thu, 2019-09-19 at 00:50 +0900, Sergey Senozhatsky wrote:
> On (09/18/19 10:39), Qian Cai wrote:
> > > Perhaps for a quick fix (and a comment that says this needs to be fixed
> > > properly). I think the changes to printk() that was discussed at
> > > Plumbers may also solve this properly.
> >
> > I assume that the new printk() stuff will also fix this deadlock between
> > printk() and memory offline.
>
> Mother chicken...
>
> Do you actually see a deadlock? I'd rather expect a lockdep splat, but
> anyway...
Not yet, just a lockdep splat so far.
>
> > [ 317.337595] WARNING: possible circular locking dependency detected
> > [ 317.337596] 5.3.0-next-20190917+ #9 Not tainted
> > [ 317.337597] ------------------------------------------------------
> > [ 317.337597] test.sh/8738 is trying to acquire lock:
> > [ 317.337598] ffffffffb33a4978 ((console_sem).lock){-.-.}, at:> down_trylock+0x16/0x50
> >
> > [ 317.337602] but task is already holding lock:
> > [ 317.337602] ffff88883fff4318 (&(&zone->lock)->rlock){-.-.}, at:> start_isolate_page_range+0x1f7/0x570
> >
> > [ 317.337606] which lock already depends on the new lock.
> >
> > [ 317.337608] the existing dependency chain (in reverse order) is:
> >
> > [ 317.337609] -> #3 (&(&zone->lock)->rlock){-.-.}:
> > [ 317.337612] __lock_acquire+0x5b3/0xb40
> > [ 317.337613] lock_acquire+0x126/0x280
> > [ 317.337613] _raw_spin_lock+0x2f/0x40
> > [ 317.337614] rmqueue_bulk.constprop.21+0xb6/0x1160
> > [ 317.337615] get_page_from_freelist+0x898/0x22c0
> > [ 317.337616] __alloc_pages_nodemask+0x2f3/0x1cd0
> > [ 317.337617] alloc_page_interleave+0x18/0x130
> > [ 317.337618] alloc_pages_current+0xf6/0x110
> > [ 317.337619] allocate_slab+0x4c6/0x19c0
> > [ 317.337620] new_slab+0x46/0x70
> > [ 317.337621] ___slab_alloc+0x58b/0x960
> > [ 317.337621] __slab_alloc+0x43/0x70
> > [ 317.337622] kmem_cache_alloc+0x354/0x460
> > [ 317.337623] fill_pool+0x272/0x4b0
> > [ 317.337624] __debug_object_init+0x86/0x790
> > [ 317.337624] debug_object_init+0x16/0x20
> > [ 317.337625] hrtimer_init+0x27/0x1e0
> > [ 317.337626] init_dl_task_timer+0x20/0x40
> > [ 317.337627] __sched_fork+0x10b/0x1f0
> > [ 317.337627] init_idle+0xac/0x520
> > [ 317.337628] idle_thread_get+0x7c/0xc0
> > [ 317.337629] bringup_cpu+0x1a/0x1e0
> > [ 317.337630] cpuhp_invoke_callback+0x197/0x1120
> > [ 317.337630] _cpu_up+0x171/0x280
> > [ 317.337631] do_cpu_up+0xb1/0x120
> > [ 317.337632] cpu_up+0x13/0x20
> > [ 317.337632] smp_init+0xa4/0x12d
> > [ 317.337633] kernel_init_freeable+0x37e/0x76e
> > [ 317.337634] kernel_init+0x11/0x12f
> > [ 317.337635] ret_from_fork+0x3a/0x50
>
> So you have debug objects enabled. Right? This thing does not behave
> when it comes to printing. debug_objects are slightly problematic.
Yes, but there is an also a similar splat without the debug_objects. It looks
like anything try to allocate memory in that path will trigger it anyway.
[ 297.425908] WARNING: possible circular locking dependency detected
[ 297.425908] 5.3.0-next-20190917 #8 Not tainted
[ 297.425909] ------------------------------------------------------
[ 297.425910] test.sh/8653 is trying to acquire lock:
[ 297.425911] ffffffff865a4460 (console_owner){-.-.}, at:
console_unlock+0x207/0x750
[ 297.425914] but task is already holding lock:
[ 297.425915] ffff88883fff3c58 (&(&zone->lock)->rlock){-.-.}, at:
__offline_isolated_pages+0x179/0x3e0
[ 297.425919] which lock already depends on the new lock.
[ 297.425920] the existing dependency chain (in reverse order) is:
[ 297.425922] -> #3 (&(&zone->lock)->rlock){-.-.}:
[ 297.425925] __lock_acquire+0x5b3/0xb40
[ 297.425925] lock_acquire+0x126/0x280
[ 297.425926] _raw_spin_lock+0x2f/0x40
[ 297.425927] rmqueue_bulk.constprop.21+0xb6/0x1160
[ 297.425928] get_page_from_freelist+0x898/0x22c0
[ 297.425928] __alloc_pages_nodemask+0x2f3/0x1cd0
[ 297.425929] alloc_pages_current+0x9c/0x110
[ 297.425930] allocate_slab+0x4c6/0x19c0
[ 297.425931] new_slab+0x46/0x70
[ 297.425931] ___slab_alloc+0x58b/0x960
[ 297.425932] __slab_alloc+0x43/0x70
[ 297.425933] __kmalloc+0x3ad/0x4b0
[ 297.425933] __tty_buffer_request_room+0x100/0x250
[ 297.425934] tty_insert_flip_string_fixed_flag+0x67/0x110
[ 297.425935] pty_write+0xa2/0xf0
[ 297.425936] n_tty_write+0x36b/0x7b0
[ 297.425936] tty_write+0x284/0x4c0
[ 297.425937] __vfs_write+0x50/0xa0
[ 297.425938] vfs_write+0x105/0x290
[ 297.425939] redirected_tty_write+0x6a/0xc0
[ 297.425939] do_iter_write+0x248/0x2a0
[ 297.425940] vfs_writev+0x106/0x1e0
[ 297.425941] do_writev+0xd4/0x180
[ 297.425941] __x64_sys_writev+0x45/0x50
[ 297.425942] do_syscall_64+0xcc/0x76c
[ 297.425943] entry_SYSCALL_64_after_hwframe+0x49/0xbe
[ 297.425944] -> #2 (&(&port->lock)->rlock){-.-.}:
[ 297.425946] __lock_acquire+0x5b3/0xb40
[ 297.425947] lock_acquire+0x126/0x280
[ 297.425948] _raw_spin_lock_irqsave+0x3a/0x50
[ 297.425949] tty_port_tty_get+0x20/0x60
[ 297.425949] tty_port_default_wakeup+0xf/0x30
[ 297.425950] tty_port_tty_wakeup+0x39/0x40
[ 297.425951] uart_write_wakeup+0x2a/0x40
[ 297.425952] serial8250_tx_chars+0x22e/0x440
[ 297.425952] serial8250_handle_irq.part.8+0x14a/0x170
[ 297.425953] serial8250_default_handle_irq+0x5c/0x90
[ 297.425954] serial8250_interrupt+0xa6/0x130
[ 297.425955] __handle_irq_event_percpu+0x78/0x4f0
[ 297.425955] handle_irq_event_percpu+0x70/0x100
[ 297.425956] handle_irq_event+0x5a/0x8b
[ 297.425957] handle_edge_irq+0x117/0x370
[ 297.425958] do_IRQ+0x9e/0x1e0
[ 297.425958] ret_from_intr+0x0/0x2a
[ 297.425959] cpuidle_enter_state+0x156/0x8e0
[ 297.425960] cpuidle_enter+0x41/0x70
[ 297.425960] call_cpuidle+0x5e/0x90
[ 297.425961] do_idle+0x333/0x370
[ 297.425962] cpu_startup_entry+0x1d/0x1f
[ 297.425962] start_secondary+0x290/0x330
[ 297.425963] secondary_startup_64+0xb6/0xc0
[ 297.425964] -> #1 (&port_lock_key){-.-.}:
[ 297.425967] __lock_acquire+0x5b3/0xb40
[ 297.425967] lock_acquire+0x126/0x280
[ 297.425968] _raw_spin_lock_irqsave+0x3a/0x50
[ 297.425969] serial8250_console_write+0x3e4/0x450
[ 297.425970] univ8250_console_write+0x4b/0x60
[ 297.425970] console_unlock+0x501/0x750
[ 297.425971] vprintk_emit+0x10d/0x340
[ 297.425972] vprintk_default+0x1f/0x30
[ 297.425972] vprintk_func+0x44/0xd4
[ 297.425973] printk+0x9f/0xc5
[ 297.425974] register_console+0x39c/0x520
[ 297.425975] univ8250_console_init+0x23/0x2d
[ 297.425975] console_init+0x338/0x4cd
[ 297.425976] start_kernel+0x534/0x724
[ 297.425977] x86_64_start_reservations+0x24/0x26
[ 297.425977] x86_64_start_kernel+0xf4/0xfb
[ 297.425978] secondary_startup_64+0xb6/0xc0
[ 297.425979] -> #0 (console_owner){-.-.}:
[ 297.425982] check_prev_add+0x107/0xea0
[ 297.425982] validate_chain+0x8fc/0x1200
[ 297.425983] __lock_acquire+0x5b3/0xb40
[ 297.425984] lock_acquire+0x126/0x280
[ 297.425984] console_unlock+0x269/0x750
[ 297.425985] vprintk_emit+0x10d/0x340
[ 297.425986] vprintk_default+0x1f/0x30
[ 297.425987] vprintk_func+0x44/0xd4
[ 297.425987] printk+0x9f/0xc5
[ 297.425988] __offline_isolated_pages.cold.52+0x2f/0x30a
[ 297.425989] offline_isolated_pages_cb+0x17/0x30
[ 297.425990] walk_system_ram_range+0xda/0x160
[ 297.425990] __offline_pages+0x79c/0xa10
[ 297.425991] offline_pages+0x11/0x20
[ 297.425992] memory_subsys_offline+0x7e/0xc0
[ 297.425992] device_offline+0xd5/0x110
[ 297.425993] state_store+0xc6/0xe0
[ 297.425994] dev_attr_store+0x3f/0x60
[ 297.425995] sysfs_kf_write+0x89/0xb0
[ 297.425995] kernfs_fop_write+0x188/0x240
[ 297.425996] __vfs_write+0x50/0xa0
[ 297.425997] vfs_write+0x105/0x290
[ 297.425997] ksys_write+0xc6/0x160
[ 297.425998] __x64_sys_write+0x43/0x50
[ 297.425999] do_syscall_64+0xcc/0x76c
[ 297.426000] entry_SYSCALL_64_after_hwframe+0x49/0xbe
[ 297.426001] other info that might help us debug this:
[ 297.426002] Chain exists of:
[ 297.426002] console_owner --> &(&port->lock)->rlock --> &(&zone->lock)-
>rlock
[ 297.426007] Possible unsafe locking scenario:
[ 297.426008] CPU0 CPU1
[ 297.426009] ---- ----
[ 297.426009] lock(&(&zone->lock)->rlock);
[ 297.426011] lock(&(&port->lock)->rlock);
[ 297.426013] lock(&(&zone->lock)->rlock);
[ 297.426014] lock(console_owner);
[ 297.426016] *** DEADLOCK ***
[ 297.426017] 9 locks held by test.sh/8653:
[ 297.426018] #0: ffff88839ba7d408 (sb_writers#4){.+.+}, at:
vfs_write+0x25f/0x290
[ 297.426021] #1: ffff888277618880 (&of->mutex){+.+.}, at:
kernfs_fop_write+0x128/0x240
[ 297.426024] #2: ffff8898131fc218 (kn->count#115){.+.+}, at:
kernfs_fop_write+0x138/0x240
[ 297.426028] #3: ffffffff86962a80 (device_hotplug_lock){+.+.}, at:
lock_device_hotplug_sysfs+0x16/0x50
[ 297.426031] #4: ffff8884374f4990 (&dev->mutex){....}, at:
device_offline+0x70/0x110
[ 297.426034] #5: ffffffff86515250 (cpu_hotplug_lock.rw_sem){++++}, at:
__offline_pages+0xbf/0xa10
[ 297.426037] #6: ffffffff867405f0 (mem_hotplug_lock.rw_sem){++++}, at:
percpu_down_write+0x87/0x2f0
[ 297.426040] #7: ffff88883fff3c58 (&(&zone->lock)->rlock){-.-.}, at:
__offline_isolated_pages+0x179/0x3e0
[ 297.426043] #8: ffffffff865a4920 (console_lock){+.+.}, at:
vprintk_emit+0x100/0x340
[ 297.426047] stack backtrace:
[ 297.426048] CPU: 1 PID: 8653 Comm: test.sh Not tainted 5.3.0-next-20190917 #8
[ 297.426049] Hardware name: HPE ProLiant DL560 Gen10/ProLiant DL560 Gen10,
BIOS U34 05/21/2019
[ 297.426049] Call Trace:
[ 297.426050] dump_stack+0x86/0xca
[ 297.426051] print_circular_bug.cold.31+0x243/0x26e
[ 297.426051] check_noncircular+0x29e/0x2e0
[ 297.426052] ? stack_trace_save+0x87/0xb0
[ 297.426053] ? print_circular_bug+0x120/0x120
[ 297.426053] check_prev_add+0x107/0xea0
[ 297.426054] validate_chain+0x8fc/0x1200
[ 297.426055] ? check_prev_add+0xea0/0xea0
[ 297.426055] __lock_acquire+0x5b3/0xb40
[ 297.426056] lock_acquire+0x126/0x280
[ 297.426057] ? console_unlock+0x207/0x750
[ 297.426057] ? __kasan_check_read+0x11/0x20
[ 297.426058] console_unlock+0x269/0x750
[ 297.426059] ? console_unlock+0x207/0x750
[ 297.426059] vprintk_emit+0x10d/0x340
[ 297.426060] vprintk_default+0x1f/0x30
[ 297.426061] vprintk_func+0x44/0xd4
[ 297.426061] ? do_raw_spin_lock+0x118/0x1d0
[ 297.426062] printk+0x9f/0xc5
[ 297.426063] ? kmsg_dump_rewind_nolock+0x64/0x64
[ 297.426064] ? __offline_isolated_pages+0x179/0x3e0
[ 297.426064] __offline_isolated_pages.cold.52+0x2f/0x30a
[ 297.426065] ? online_memory_block+0x20/0x20
[ 297.426066] offline_isolated_pages_cb+0x17/0x30
[ 297.426067] walk_system_ram_range+0xda/0x160
[ 297.426067] ? walk_mem_res+0x30/0x30
[ 297.426068] ? dissolve_free_huge_page+0x1e/0x2b0
[ 297.426069] __offline_pages+0x79c/0xa10
[ 297.426069] ? __add_memory+0xc0/0xc0
[ 297.426070] ? __kasan_check_write+0x14/0x20
[ 297.426071] ? __mutex_lock+0x344/0xcd0
[ 297.426071] ? _raw_spin_unlock_irqrestore+0x49/0x50
[ 297.426072] ? device_offline+0x70/0x110
[ 297.426073] ? klist_next+0x1c1/0x1e0
[ 297.426073] ? __mutex_add_waiter+0xc0/0xc0
[ 297.426074] ? klist_next+0x10b/0x1e0
[ 297.426075] ? klist_iter_exit+0x16/0x40
[ 297.426076] ? device_for_each_child+0xd0/0x110
[ 297.426076] offline_pages+0x11/0x20
[ 297.426077] memory_subsys_offline+0x7e/0xc0
[ 297.426078] device_offline+0xd5/0x110
[ 297.426078] ? auto_online_blocks_show+0x70/0x70
[ 297.426079] state_store+0xc6/0xe0
[ 297.426080] dev_attr_store+0x3f/0x60
[ 297.426080] ? device_match_name+0x40/0x40
[ 297.426081] sysfs_kf_write+0x89/0xb0
[ 297.426082] ? sysfs_file_ops+0xa0/0xa0
[ 297.426082] kernfs_fop_write+0x188/0x240
[ 297.426083] __vfs_write+0x50/0xa0
[ 297.426084] vfs_write+0x105/0x290
[ 297.426084] ksys_write+0xc6/0x160
[ 297.426085] ? __x64_sys_read+0x50/0x50
[ 297.426086] ? do_syscall_64+0x79/0x76c
[ 297.426086] ? do_syscall_64+0x79/0x76c
[ 297.426087] __x64_sys_write+0x43/0x50
[ 297.426088] do_syscall_64+0xcc/0x76c
[ 297.426088] ? trace_hardirqs_on_thunk+0x1a/0x20
[ 297.426089] ? syscall_return_slowpath+0x210/0x210
[ 297.426090] ? entry_SYSCALL_64_after_hwframe+0x3e/0xbe
[ 297.426091] ? trace_hardirqs_off_caller+0x3a/0x150
[ 297.426092] ? trace_hardirqs_off_thunk+0x1a/0x20
[ 297.426092] entry_SYSCALL_64_after_hwframe+0x49/0xbe
[ 297.426093] RIP: 0033:0x7fd7336b4e18
[ 297.426095] Code: 89 02 48 c7 c0 ff ff ff ff eb b3 0f 1f 80 00 00 00 00 f3 0f
1e fa 48 8d 05 05 59 2d 00 8b 00 85 c0 75 17 b8 01 00 00 00 0f 05 <48> 3d 00 f0
ff ff 77 58 c3 0f 1f 80 00 00 00 00 41 54 49 89 d4 55
[ 297.426096] RSP: 002b:00007ffc58c7b258 EFLAGS: 00000246 ORIG_RAX:
0000000000000001
[ 297.426098] RAX: ffffffffffffffda RBX: 0000000000000008 RCX: 00007fd7336b4e18
[ 297.426098] RDX: 0000000000000008 RSI: 000055ad6d519c70 RDI: 0000000000000001
[ 297.426099] RBP: 000055ad6d519c70 R08: 000000000000000a R09: 00007fd733746300
[ 297.426100] R10: 000000000000000a R11: 0000000000000246 R12: 00007fd733986780
[ 297.426101] R13: 0000000000000008 R14: 00007fd733981740 R15: 0000000000000008
[ 763.659202][ C6] WARNING: possible circular locking dependency detected
[ 763.659202][ C6] 5.3.0-next-20190917 #3 Not tainted
[ 763.659203][ C6] ------------------------------------------------------
[ 763.659203][ C6] test.sh/8352 is trying to acquire lock:
[ 763.659203][ C6] ffffffffa187e5f8 ((console_sem).lock){..-.}, at:
down_trylock+0x14/0x40
[ 763.659206][ C6]
[ 763.659206][ C6] but task is already holding lock:
[ 763.659206][ C6] ffff9bcf7f373c58 (&(&zone->lock)->rlock){-.-.}, at:
__offline_isolated_pages+0x11e/0x2d0
[ 763.659208][ C6]
[ 763.659208][ C6] which lock already depends on the new lock.
[ 763.659209][ C6]
[ 763.659209][ C6]
[ 763.659209][ C6] the existing dependency chain (in reverse order) is:
[ 763.659210][ C6]
[ 763.659210][ C6] -> #3 (&(&zone->lock)->rlock){-.-.}:
[ 763.659211][ C6] __lock_acquire+0x44e/0x8c0
[ 763.659212][ C6] lock_acquire+0xc0/0x1c0
[ 763.659212][ C6] _raw_spin_lock+0x2f/0x40
[ 763.659212][ C6] rmqueue_bulk.constprop.24+0x62/0xba0
[ 763.659213][ C6] get_page_from_freelist+0x581/0x1810
[ 763.659213][ C6] __alloc_pages_nodemask+0x20d/0x1750
[ 763.659214][ C6] alloc_page_interleave+0x17/0x100
[ 763.659214][ C6] alloc_pages_current+0xc0/0xe0
[ 763.659214][ C6] allocate_slab+0x4b2/0x1a20
[ 763.659215][ C6] new_slab+0x46/0x70
[ 763.659215][ C6] ___slab_alloc+0x58a/0x960
[ 763.659215][ C6] __slab_alloc+0x43/0x70
[ 763.659216][ C6] kmem_cache_alloc+0x33e/0x440
[ 763.659216][ C6] fill_pool+0x1ae/0x460
[ 763.659216][ C6] __debug_object_init+0x35/0x4a0
[ 763.659217][ C6] debug_object_init+0x16/0x20
[ 763.659217][ C6] hrtimer_init+0x25/0x130
[ 763.659218][ C6] init_dl_task_timer+0x20/0x30
[ 763.659218][ C6] __sched_fork+0x92/0x100
[ 763.659218][ C6] init_idle+0x8d/0x380
[ 763.659219][ C6] fork_idle+0xd9/0x140
[ 763.659219][ C6] idle_threads_init+0xd3/0x15e
[ 763.659219][ C6] smp_init+0x1b/0xbb
[ 763.659220][ C6] kernel_init_freeable+0x248/0x557
[ 763.659220][ C6] kernel_init+0xf/0x11e
[ 763.659220][ C6] ret_from_fork+0x27/0x50
[ 763.659221][ C6]
[ 763.659221][ C6] -> #2 (&rq->lock){-.-.}:
[ 763.659222][ C6] __lock_acquire+0x44e/0x8c0
[ 763.659223][ C6] lock_acquire+0xc0/0x1c0
[ 763.659223][ C6] _raw_spin_lock+0x2f/0x40
[ 763.659223][ C6] task_fork_fair+0x37/0x150
[ 763.659224][ C6] sched_fork+0x126/0x230
[ 763.659224][ C6] copy_process+0xafc/0x1e90
[ 763.659224][ C6] _do_fork+0x89/0x720
[ 763.659225][ C6] kernel_thread+0x58/0x70
[ 763.659225][ C6] rest_init+0x28/0x302
[ 763.659225][ C6] arch_call_rest_init+0xe/0x1b
[ 763.659226][ C6] start_kernel+0x581/0x5a0
[ 763.659226][ C6] x86_64_start_reservations+0x24/0x26
[ 763.659227][ C6] x86_64_start_kernel+0xef/0xf6
[ 763.659227][ C6] secondary_startup_64+0xb6/0xc0
[ 763.659227][ C6]
[ 763.659227][ C6] -> #1 (&p->pi_lock){-.-.}:
[ 763.659229][ C6] __lock_acquire+0x44e/0x8c0
[ 763.659229][ C6] lock_acquire+0xc0/0x1c0
[ 763.659230][ C6] _raw_spin_lock_irqsave+0x3a/0x50
[ 763.659230][ C6] try_to_wake_up+0x5c/0xbc0
[ 763.659230][ C6] wake_up_process+0x15/0x20
[ 763.659231][ C6] __up+0x4a/0x50
[ 763.659231][ C6] up+0x45/0x50
[ 763.659231][ C6] __up_console_sem+0x37/0x60
[ 763.659232][ C6] console_unlock+0x357/0x600
[ 763.659232][ C6] vprintk_emit+0x101/0x320
[ 763.659232][ C6] vprintk_default+0x1f/0x30
[ 763.659233][ C6] vprintk_func+0x44/0xd4
[ 763.659233][ C6] printk+0x58/0x6f
[ 763.659234][ C6] do_exit+0xd73/0xd80
[ 763.659234][ C6] do_group_exit+0x41/0xd0
[ 763.659234][ C6] __x64_sys_exit_group+0x18/0x20
[ 763.659235][ C6] do_syscall_64+0x6d/0x488
[ 763.659235][ C6] entry_SYSCALL_64_after_hwframe+0x49/0xbe
[ 763.659235][ C6]
[ 763.659236][ C6] -> #0 ((console_sem).lock){..-.}:
[ 763.659237][ C6] check_prev_add+0x9b/0xa10
[ 763.659237][ C6] validate_chain+0x759/0xdc0
[ 763.659238][ C6] __lock_acquire+0x44e/0x8c0
[ 763.659238][ C6] lock_acquire+0xc0/0x1c0
[ 763.659239][ C6] _raw_spin_lock_irqsave+0x3a/0x50
[ 763.659239][ C6] down_trylock+0x14/0x40
[ 763.659239][ C6] __down_trylock_console_sem+0x2b/0xa0
[ 763.659240][ C6] console_trylock+0x16/0x60
[ 763.659240][ C6] vprintk_emit+0xf4/0x320
[ 763.659240][ C6] vprintk_default+0x1f/0x30
[ 763.659241][ C6] vprintk_func+0x44/0xd4
[ 763.659241][ C6] printk+0x58/0x6f
[ 763.659242][ C6] __offline_isolated_pages.cold.55+0x38/0x28e
[ 763.659242][ C6] offline_isolated_pages_cb+0x15/0x20
[ 763.659242][ C6] walk_system_ram_range+0x7b/0xd0
[ 763.659243][ C6] __offline_pages+0x456/0xc10
[ 763.659243][ C6] offline_pages+0x11/0x20
[ 763.659243][ C6] memory_subsys_offline+0x44/0x60
[ 763.659244][ C6] device_offline+0x90/0xc0
[ 763.659244][ C6] state_store+0xbc/0xe0
[ 763.659244][ C6] dev_attr_store+0x17/0x30
[ 763.659245][ C6] sysfs_kf_write+0x4b/0x60
[ 763.659245][ C6] kernfs_fop_write+0x119/0x1c0
[ 763.659245][ C6] __vfs_write+0x1b/0x40
[ 763.659246][ C6] vfs_write+0xbd/0x1c0
[ 763.659246][ C6] ksys_write+0x64/0xe0
[ 763.659247][ C6] __x64_sys_write+0x1a/0x20
[ 763.659247][ C6] do_syscall_64+0x6d/0x488
[ 763.659247][ C6] entry_SYSCALL_64_after_hwframe+0x49/0xbe
[ 763.659248][ C6]
[ 763.659248][ C6] other info that might help us debug this:
[ 763.659248][ C6]
[ 763.659248][ C6] Chain exists of:
[ 763.659249][ C6] (console_sem).lock --> &rq->lock --> &(&zone->lock)-
>rlock
[ 763.659251][ C6]
[ 763.659251][ C6] Possible unsafe locking scenario:
[ 763.659251][ C6]
[ 763.659252][ C6] CPU0 CPU1
[ 763.659252][ C6] ---- ----
[ 763.659252][ C6] lock(&(&zone->lock)->rlock);
[ 763.659253][ C6] lock(&rq->lock);
[ 763.659254][ C6] lock(&(&zone->lock)-
>rlock);
[ 763.659255][ C6] lock((console_sem).lock);
[ 763.659256][ C6]
[ 763.659256][ C6] *** DEADLOCK ***
[ 763.659256][ C6]
[ 763.659257][ C6] 8 locks held by test.sh/8352:
[ 763.659257][ C6] #0: ffff9bdf4da39408 (sb_writers#4){.+.+}, at:
vfs_write+0x174/0x1c0
[ 763.659259][ C6] #1: ffff9be348280880 (&of->mutex){+.+.}, at:
kernfs_fop_write+0xe4/0x1c0
[ 763.659260][ C6] #2: ffff9bdb873757d0 (kn->count#125){.+.+}, at:
kernfs_fop_write+0xed/0x1c0
[ 763.659262][ C6] #3: ffffffffa194dec0 (device_hotplug_lock){+.+.}, at:
lock_device_hotplug_sysfs+0x15/0x40
[ 763.659264][ C6] #4: ffff9bcf7314c990 (&dev->mutex){....}, at:
device_offline+0x4e/0xc0
[ 763.659265][ C6] #5: ffffffffa185b9f0 (cpu_hotplug_lock.rw_sem){++++},
at: __offline_pages+0x3b/0xc10
[ 763.659267][ C6] #6: ffffffffa18e0b90 (mem_hotplug_lock.rw_sem){++++},
at: percpu_down_write+0x36/0x1c0
[ 763.659268][ C6] #7: ffff9bcf7f373c58 (&(&zone->lock)->rlock){-.-.}, at:
__offline_isolated_pages+0x11e/0x2d0
[ 763.659270][ C6]
[ 763.659270][ C6] stack backtrace:
[ 763.659271][ C6] CPU: 6 PID: 8352 Comm: test.sh Not tainted 5.3.0-next-
20190917 #3
[ 763.659271][ C6] Hardware name: HPE ProLiant DL385 Gen10/ProLiant DL385
Gen10, BIOS A40 07/10/2019
[ 763.659272][ C6] Call Trace:
[ 763.659272][ C6] dump_stack+0x70/0x9a
[ 763.659272][ C6] print_circular_bug.cold.31+0x1c0/0x1eb
[ 763.659273][ C6] check_noncircular+0x18c/0x1a0
[ 763.659273][ C6] check_prev_add+0x9b/0xa10
[ 763.659273][ C6] validate_chain+0x759/0xdc0
[ 763.659274][ C6] __lock_acquire+0x44e/0x8c0
[ 763.659274][ C6] lock_acquire+0xc0/0x1c0
[ 763.659274][ C6] ? down_trylock+0x14/0x40
[ 763.659275][ C6] ? vprintk_emit+0xf4/0x320
[ 763.659275][ C6] _raw_spin_lock_irqsave+0x3a/0x50
[ 763.659275][ C6] ? down_trylock+0x14/0x40
[ 763.659276][ C6] down_trylock+0x14/0x40
[ 763.659276][ C6] __down_trylock_console_sem+0x2b/0xa0
[ 763.659276][ C6] console_trylock+0x16/0x60
[ 763.659277][ C6] vprintk_emit+0xf4/0x320
[ 763.659277][ C6] vprintk_default+0x1f/0x30
[ 763.659277][ C6] vprintk_func+0x44/0xd4
[ 763.659278][ C6] printk+0x58/0x6f
[ 763.659278][ C6] __offline_isolated_pages.cold.55+0x38/0x28e
[ 763.659278][ C6] ? online_memory_block+0x20/0x20
[ 763.659279][ C6] offline_isolated_pages_cb+0x15/0x20
[ 763.659279][ C6] walk_system_ram_range+0x7b/0xd0
[ 763.659279][ C6] __offline_pages+0x456/0xc10
[ 763.659280][ C6] offline_pages+0x11/0x20
[ 763.659280][ C6] memory_subsys_offline+0x44/0x60
[ 763.659280][ C6] device_offline+0x90/0xc0
[ 763.659281][ C6] state_store+0xbc/0xe0
[ 763.659281][ C6] dev_attr_store+0x17/0x30
[ 763.659281][ C6] sysfs_kf_write+0x4b/0x60
[ 763.659282][ C6] kernfs_fop_write+0x119/0x1c0
[ 763.659282][ C6] __vfs_write+0x1b/0x40
[ 763.659282][ C6] vfs_write+0xbd/0x1c0
[ 763.659283][ C6] ksys_write+0x64/0xe0
[ 763.659283][ C6] __x64_sys_write+0x1a/0x20
[ 763.659283][ C6] do_syscall_64+0x6d/0x488
[ 763.659284][ C6] ? trace_hardirqs_off_thunk+0x1a/0x20
[ 763.659284][ C6] entry_SYSCALL_64_after_hwframe+0x49/0xbe
>
> This thing does
>
> rq->lock --> zone->lock
>
> It takes rq->lock and then calls into __sched_fork()->hrtimer_init()->debug_objects()->MM
>
> This doesn't look very right - a dive into MM under rq->lock.
>
> Peter, Thomas am I wrong?
>
> > [ 317.337635] -> #2 (&rq->lock){-.-.}:
> > [ 317.337638] __lock_acquire+0x5b3/0xb40
> > [ 317.337639] lock_acquire+0x126/0x280
> > [ 317.337639] _raw_spin_lock+0x2f/0x40
> > [ 317.337640] task_fork_fair+0x43/0x200
> > [ 317.337641] sched_fork+0x29b/0x420
> > [ 317.337642] copy_process+0xf3c/0x2fd0
> > [ 317.337642] _do_fork+0xef/0x950
> > [ 317.337643] kernel_thread+0xa8/0xe0
> > [ 317.337644] rest_init+0x28/0x311
> > [ 317.337645] arch_call_rest_init+0xe/0x1b
> > [ 317.337645] start_kernel+0x6eb/0x724
> > [ 317.337646] x86_64_start_reservations+0x24/0x26
> > [ 317.337647] x86_64_start_kernel+0xf4/0xfb
> > [ 317.337648] secondary_startup_64+0xb6/0xc0
>
> pi_lock --> rq->lock
>
> > [ 317.337649] -> #1 (&p->pi_lock){-.-.}:
> > [ 317.337651] __lock_acquire+0x5b3/0xb40
> > [ 317.337652] lock_acquire+0x126/0x280
> > [ 317.337653] _raw_spin_lock_irqsave+0x3a/0x50
> > [ 317.337653] try_to_wake_up+0xb4/0x1030
> > [ 317.337654] wake_up_process+0x15/0x20
> > [ 317.337655] __up+0xaa/0xc0
> > [ 317.337655] up+0x55/0x60
> > [ 317.337656] __up_console_sem+0x37/0x60
> > [ 317.337657] console_unlock+0x3a0/0x750
> > [ 317.337658] vprintk_emit+0x10d/0x340
> > [ 317.337658] vprintk_default+0x1f/0x30
> > [ 317.337659] vprintk_func+0x44/0xd4
> > [ 317.337660] printk+0x9f/0xc5
> > [ 317.337660] crng_reseed+0x3cc/0x440
> > [ 317.337661] credit_entropy_bits+0x3e8/0x4f0
> > [ 317.337662] random_ioctl+0x1eb/0x250
> > [ 317.337663] do_vfs_ioctl+0x13e/0xa70
> > [ 317.337663] ksys_ioctl+0x41/0x80
> > [ 317.337664] __x64_sys_ioctl+0x43/0x4c
> > [ 317.337665] do_syscall_64+0xcc/0x76c
> > [ 317.337666] entry_SYSCALL_64_after_hwframe+0x49/0xbe
>
> console_sem->lock --> pi_lock
>
> This also covers console_sem->lock --> rq->lock, and maintains
> pi_lock --> rq->lock
>
> So we have
>
> console_sem->lock --> pi_lock --> rq->lock
>
> > [ 317.337667] -> #0 ((console_sem).lock){-.-.}:
> > [ 317.337669] check_prev_add+0x107/0xea0
> > [ 317.337670] validate_chain+0x8fc/0x1200
> > [ 317.337671] __lock_acquire+0x5b3/0xb40
> > [ 317.337671] lock_acquire+0x126/0x280
> > [ 317.337672] _raw_spin_lock_irqsave+0x3a/0x50
> > [ 317.337673] down_trylock+0x16/0x50
> > [ 317.337674] __down_trylock_console_sem+0x2b/0xa0
> > [ 317.337675] console_trylock+0x16/0x60
> > [ 317.337676] vprintk_emit+0x100/0x340
> > [ 317.337677] vprintk_default+0x1f/0x30
> > [ 317.337678] vprintk_func+0x44/0xd4
> > [ 317.337678] printk+0x9f/0xc5
> > [ 317.337679] __dump_page.cold.2+0x73/0x210
> > [ 317.337680] dump_page+0x12/0x50
> > [ 317.337680] has_unmovable_pages+0x3e9/0x4b0
> > [ 317.337681] start_isolate_page_range+0x3b4/0x570
> > [ 317.337682] __offline_pages+0x1ad/0xa10
> > [ 317.337683] offline_pages+0x11/0x20
> > [ 317.337683] memory_subsys_offline+0x7e/0xc0
> > [ 317.337684] device_offline+0xd5/0x110
> > [ 317.337685] state_store+0xc6/0xe0
> > [ 317.337686] dev_attr_store+0x3f/0x60
> > [ 317.337686] sysfs_kf_write+0x89/0xb0
> > [ 317.337687] kernfs_fop_write+0x188/0x240
> > [ 317.337688] __vfs_write+0x50/0xa0
> > [ 317.337688] vfs_write+0x105/0x290
> > [ 317.337689] ksys_write+0xc6/0x160
> > [ 317.337690] __x64_sys_write+0x43/0x50
> > [ 317.337691] do_syscall_64+0xcc/0x76c
> > [ 317.337691] entry_SYSCALL_64_after_hwframe+0x49/0xbe
>
> zone->lock --> console_sem->lock
>
> So then we have
>
> zone->lock --> console_sem->lock --> pi_lock --> rq->lock
>
> vs. the reverse chain
>
> rq->lock --> console_sem->lock
>
> If I get this right.
>
> > [ 317.337693] other info that might help us debug this:
> >
> > [ 317.337694] Chain exists of:
> > [ 317.337694] (console_sem).lock --> &rq->lock --> &(&zone->lock)->rlock
> >
> > [ 317.337699] Possible unsafe locking scenario:
> >
> > [ 317.337700] CPU0 CPU1
> > [ 317.337701] ---- ----
> > [ 317.337701] lock(&(&zone->lock)->rlock);
> > [ 317.337703] lock(&rq->lock);
> > [ 317.337705] lock(&(&zone->lock)->rlock);
> > [ 317.337706] lock((console_sem).lock);
> >
> > [ 317.337708] *** DEADLOCK ***
> >
> > [ 317.337710] 8 locks held by test.sh/8738:
> > [ 317.337710] #0: ffff8883940b5408 (sb_writers#4){.+.+}, at: vfs_write+0x25f/0x290
> > [ 317.337713] #1: ffff889fce310280 (&of->mutex){+.+.}, at: kernfs_fop_write+0x128/0x240
> > [ 317.337716] #2: ffff889feb6d4830 (kn->count#115){.+.+}, at: kernfs_fop_write+0x138/0x240
> > [ 317.337720] #3: ffffffffb3762d40 (device_hotplug_lock){+.+.}, at: lock_device_hotplug_sysfs+0x16/0x50
> > [ 317.337723] #4: ffff88981f0dc990 (&dev->mutex){....}, at: device_offline+0x70/0x110
> > [ 317.337726] #5: ffffffffb3315250 (cpu_hotplug_lock.rw_sem){++++}, at: __offline_pages+0xbf/0xa10
> > [ 317.337729] #6: ffffffffb35408b0 (mem_hotplug_lock.rw_sem){++++}, at: percpu_down_write+0x87/0x2f0
> > [ 317.337732] #7: ffff88883fff4318 (&(&zone->lock)->rlock){-.-.}, at: start_isolate_page_range+0x1f7/0x570
> > [ 317.337736] stack backtrace:
> > [ 317.337737] CPU: 58 PID: 8738 Comm: test.sh Not tainted 5.3.0-next-20190917+ #9
> > [ 317.337738] Hardware name: HPE ProLiant DL560 Gen10/ProLiant DL560 Gen10, BIOS U34 05/21/2019
> > [ 317.337739] Call Trace:
> > [ 317.337739] dump_stack+0x86/0xca
> > [ 317.337740] print_circular_bug.cold.31+0x243/0x26e
> > [ 317.337741] check_noncircular+0x29e/0x2e0
> > [ 317.337742] ? debug_lockdep_rcu_enabled+0x4b/0x60
> > [ 317.337742] ? print_circular_bug+0x120/0x120
> > [ 317.337743] ? is_ftrace_trampoline+0x9/0x20
> > [ 317.337744] ? kernel_text_address+0x59/0xc0
> > [ 317.337744] ? __kernel_text_address+0x12/0x40
> > [ 317.337745] check_prev_add+0x107/0xea0
> > [ 317.337746] validate_chain+0x8fc/0x1200
> > [ 317.337746] ? check_prev_add+0xea0/0xea0
> > [ 317.337747] ? format_decode+0xd6/0x600
> > [ 317.337748] ? file_dentry_name+0xe0/0xe0
> > [ 317.337749] __lock_acquire+0x5b3/0xb40
> > [ 317.337749] lock_acquire+0x126/0x280
> > [ 317.337750] ? down_trylock+0x16/0x50
> > [ 317.337751] ? vprintk_emit+0x100/0x340
> > [ 317.337752] _raw_spin_lock_irqsave+0x3a/0x50
> > [ 317.337753] ? down_trylock+0x16/0x50
> > [ 317.337753] down_trylock+0x16/0x50
> > [ 317.337754] ? vprintk_emit+0x100/0x340
> > [ 317.337755] __down_trylock_console_sem+0x2b/0xa0
> > [ 317.337756] console_trylock+0x16/0x60
> > [ 317.337756] vprintk_emit+0x100/0x340
> > [ 317.337757] vprintk_default+0x1f/0x30
> > [ 317.337758] vprintk_func+0x44/0xd4
> > [ 317.337758] printk+0x9f/0xc5
> > [ 317.337759] ? kmsg_dump_rewind_nolock+0x64/0x64
> > [ 317.337760] ? __dump_page+0x1d7/0x430
> > [ 317.337760] __dump_page.cold.2+0x73/0x210
> > [ 317.337761] dump_page+0x12/0x50
> > [ 317.337762] has_unmovable_pages+0x3e9/0x4b0
> > [ 317.337763] start_isolate_page_range+0x3b4/0x570
> > [ 317.337763] ? unset_migratetype_isolate+0x280/0x280
> > [ 317.337764] ? rcu_read_lock_bh_held+0xc0/0xc0
> > [ 317.337765] __offline_pages+0x1ad/0xa10
> > [ 317.337765] ? lock_acquire+0x126/0x280
> > [ 317.337766] ? __add_memory+0xc0/0xc0
> > [ 317.337767] ? __kasan_check_write+0x14/0x20
> > [ 317.337767] ? __mutex_lock+0x344/0xcd0
> > [ 317.337768] ? _raw_spin_unlock_irqrestore+0x49/0x50
> > [ 317.337769] ? device_offline+0x70/0x110
> > [ 317.337770] ? klist_next+0x1c1/0x1e0
> > [ 317.337770] ? __mutex_add_waiter+0xc0/0xc0
> > [ 317.337771] ? klist_next+0x10b/0x1e0
> > [ 317.337772] ? klist_iter_exit+0x16/0x40
> > [ 317.337772] ? device_for_each_child+0xd0/0x110
> > [ 317.337773] offline_pages+0x11/0x20
> > [ 317.337774] memory_subsys_offline+0x7e/0xc0
> > [ 317.337774] device_offline+0xd5/0x110
> > [ 317.337775] ? auto_online_blocks_show+0x70/0x70
> > [ 317.337776] state_store+0xc6/0xe0
> > [ 317.337776] dev_attr_store+0x3f/0x60
> > [ 317.337777] ? device_match_name+0x40/0x40
> > [ 317.337778] sysfs_kf_write+0x89/0xb0
> > [ 317.337778] ? sysfs_file_ops+0xa0/0xa0
> > [ 317.337779] kernfs_fop_write+0x188/0x240
> > [ 317.337780] __vfs_write+0x50/0xa0
> > [ 317.337780] vfs_write+0x105/0x290
> > [ 317.337781] ksys_write+0xc6/0x160
> > [ 317.337782] ? __x64_sys_read+0x50/0x50
> > [ 317.337782] ? do_syscall_64+0x79/0x76c
> > [ 317.337783] ? do_syscall_64+0x79/0x76c
> > [ 317.337784] __x64_sys_write+0x43/0x50
> > [ 317.337784] do_syscall_64+0xcc/0x76c
> > [ 317.337785] ? trace_hardirqs_on_thunk+0x1a/0x20
> > [ 317.337786] ? syscall_return_slowpath+0x210/0x210
> > [ 317.337787] ? entry_SYSCALL_64_after_hwframe+0x3e/0xbe
> > [ 317.337787] ? trace_hardirqs_off_caller+0x3a/0x150
> > [ 317.337788] ? trace_hardirqs_off_thunk+0x1a/0x20
> > [ 317.337789] entry_SYSCALL_64_after_hwframe+0x49/0xbe
>
> Lovely.
>
> -ss
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 0/4] iommu/arm-smmu: Remove arm_smmu_flush_ops
From: Robin Murphy @ 2019-09-18 16:17 UTC (permalink / raw)
To: will; +Cc: iommu, joro, linux-arm-kernel
Hi all,
Off the back of Will's iommu_flush_ops work, here's an initial followup
to replace the temporary solution in arm-smmu with a full conversion.
Removing teh extra layer of indirection should generally make things a
good bit more efficient, and rather more readable to boot.
Robin.
Robin Murphy (4):
iommu/arm-smmu: Remove .tlb_inv_range indirection
iommu/arm-smmu: Remove "leaf" indirection
iommu/arm-smmu: Move .tlb_sync method to implementation
iommu/arm-smmu: Remove arm_smmu_flush_ops
drivers/iommu/arm-smmu.c | 178 +++++++++++++++++++++------------------
drivers/iommu/arm-smmu.h | 11 +--
2 files changed, 97 insertions(+), 92 deletions(-)
--
2.21.0.dirty
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 1/4] iommu/arm-smmu: Remove .tlb_inv_range indirection
From: Robin Murphy @ 2019-09-18 16:17 UTC (permalink / raw)
To: will; +Cc: iommu, joro, linux-arm-kernel
In-Reply-To: <cover.1568820087.git.robin.murphy@arm.com>
Fill in 'native' iommu_flush_ops callbacks for all the
arm_smmu_flush_ops variants, and clear up the remains of the previous
.tlb_inv_range abstraction.
Signed-off-by: Robin Murphy <robin.murphy@arm.com>
---
drivers/iommu/arm-smmu.c | 110 ++++++++++++++++++++++-----------------
drivers/iommu/arm-smmu.h | 2 -
2 files changed, 63 insertions(+), 49 deletions(-)
diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
index c3ef0cc8f764..f2b81b1ce224 100644
--- a/drivers/iommu/arm-smmu.c
+++ b/drivers/iommu/arm-smmu.c
@@ -312,7 +312,7 @@ static void arm_smmu_tlb_inv_context_s2(void *cookie)
}
static void arm_smmu_tlb_inv_range_s1(unsigned long iova, size_t size,
- size_t granule, bool leaf, void *cookie)
+ size_t granule, void *cookie, bool leaf)
{
struct arm_smmu_domain *smmu_domain = cookie;
struct arm_smmu_device *smmu = smmu_domain->smmu;
@@ -342,7 +342,7 @@ static void arm_smmu_tlb_inv_range_s1(unsigned long iova, size_t size,
}
static void arm_smmu_tlb_inv_range_s2(unsigned long iova, size_t size,
- size_t granule, bool leaf, void *cookie)
+ size_t granule, void *cookie, bool leaf)
{
struct arm_smmu_domain *smmu_domain = cookie;
struct arm_smmu_device *smmu = smmu_domain->smmu;
@@ -362,14 +362,63 @@ static void arm_smmu_tlb_inv_range_s2(unsigned long iova, size_t size,
} while (size -= granule);
}
+static void arm_smmu_tlb_inv_walk_s1(unsigned long iova, size_t size,
+ size_t granule, void *cookie)
+{
+ arm_smmu_tlb_inv_range_s1(iova, size, granule, cookie, false);
+ arm_smmu_tlb_sync_context(cookie);
+}
+
+static void arm_smmu_tlb_inv_leaf_s1(unsigned long iova, size_t size,
+ size_t granule, void *cookie)
+{
+ arm_smmu_tlb_inv_range_s1(iova, size, granule, cookie, true);
+ arm_smmu_tlb_sync_context(cookie);
+}
+
+static void arm_smmu_tlb_add_page_s1(struct iommu_iotlb_gather *gather,
+ unsigned long iova, size_t granule,
+ void *cookie)
+{
+ arm_smmu_tlb_inv_range_s1(iova, granule, granule, cookie, true);
+}
+
+static void arm_smmu_tlb_inv_walk_s2(unsigned long iova, size_t size,
+ size_t granule, void *cookie)
+{
+ arm_smmu_tlb_inv_range_s2(iova, size, granule, cookie, false);
+ arm_smmu_tlb_sync_context(cookie);
+}
+
+static void arm_smmu_tlb_inv_leaf_s2(unsigned long iova, size_t size,
+ size_t granule, void *cookie)
+{
+ arm_smmu_tlb_inv_range_s2(iova, size, granule, cookie, true);
+ arm_smmu_tlb_sync_context(cookie);
+}
+
+static void arm_smmu_tlb_add_page_s2(struct iommu_iotlb_gather *gather,
+ unsigned long iova, size_t granule,
+ void *cookie)
+{
+ arm_smmu_tlb_inv_range_s2(iova, granule, granule, cookie, true);
+}
+
+static void arm_smmu_tlb_inv_any_s2_v1(unsigned long iova, size_t size,
+ size_t granule, void *cookie)
+{
+ arm_smmu_tlb_inv_context_s2(cookie);
+}
/*
* On MMU-401 at least, the cost of firing off multiple TLBIVMIDs appears
* almost negligible, but the benefit of getting the first one in as far ahead
* of the sync as possible is significant, hence we don't just make this a
- * no-op and set .tlb_sync to arm_smmu_tlb_inv_context_s2() as you might think.
+ * no-op and call arm_smmu_tlb_inv_context_s2() from .iotlb_sync as you might
+ * think.
*/
-static void arm_smmu_tlb_inv_vmid_nosync(unsigned long iova, size_t size,
- size_t granule, bool leaf, void *cookie)
+static void arm_smmu_tlb_add_page_s2_v1(struct iommu_iotlb_gather *gather,
+ unsigned long iova, size_t granule,
+ void *cookie)
{
struct arm_smmu_domain *smmu_domain = cookie;
struct arm_smmu_device *smmu = smmu_domain->smmu;
@@ -380,66 +429,33 @@ static void arm_smmu_tlb_inv_vmid_nosync(unsigned long iova, size_t size,
arm_smmu_gr0_write(smmu, ARM_SMMU_GR0_TLBIVMID, smmu_domain->cfg.vmid);
}
-static void arm_smmu_tlb_inv_walk(unsigned long iova, size_t size,
- size_t granule, void *cookie)
-{
- struct arm_smmu_domain *smmu_domain = cookie;
- const struct arm_smmu_flush_ops *ops = smmu_domain->flush_ops;
-
- ops->tlb_inv_range(iova, size, granule, false, cookie);
- ops->tlb_sync(cookie);
-}
-
-static void arm_smmu_tlb_inv_leaf(unsigned long iova, size_t size,
- size_t granule, void *cookie)
-{
- struct arm_smmu_domain *smmu_domain = cookie;
- const struct arm_smmu_flush_ops *ops = smmu_domain->flush_ops;
-
- ops->tlb_inv_range(iova, size, granule, true, cookie);
- ops->tlb_sync(cookie);
-}
-
-static void arm_smmu_tlb_add_page(struct iommu_iotlb_gather *gather,
- unsigned long iova, size_t granule,
- void *cookie)
-{
- struct arm_smmu_domain *smmu_domain = cookie;
- const struct arm_smmu_flush_ops *ops = smmu_domain->flush_ops;
-
- ops->tlb_inv_range(iova, granule, granule, true, cookie);
-}
-
static const struct arm_smmu_flush_ops arm_smmu_s1_tlb_ops = {
.tlb = {
.tlb_flush_all = arm_smmu_tlb_inv_context_s1,
- .tlb_flush_walk = arm_smmu_tlb_inv_walk,
- .tlb_flush_leaf = arm_smmu_tlb_inv_leaf,
- .tlb_add_page = arm_smmu_tlb_add_page,
+ .tlb_flush_walk = arm_smmu_tlb_inv_walk_s1,
+ .tlb_flush_leaf = arm_smmu_tlb_inv_leaf_s1,
+ .tlb_add_page = arm_smmu_tlb_add_page_s1,
},
- .tlb_inv_range = arm_smmu_tlb_inv_range_s1,
.tlb_sync = arm_smmu_tlb_sync_context,
};
static const struct arm_smmu_flush_ops arm_smmu_s2_tlb_ops_v2 = {
.tlb = {
.tlb_flush_all = arm_smmu_tlb_inv_context_s2,
- .tlb_flush_walk = arm_smmu_tlb_inv_walk,
- .tlb_flush_leaf = arm_smmu_tlb_inv_leaf,
- .tlb_add_page = arm_smmu_tlb_add_page,
+ .tlb_flush_walk = arm_smmu_tlb_inv_walk_s2,
+ .tlb_flush_leaf = arm_smmu_tlb_inv_leaf_s2,
+ .tlb_add_page = arm_smmu_tlb_add_page_s2,
},
- .tlb_inv_range = arm_smmu_tlb_inv_range_s2,
.tlb_sync = arm_smmu_tlb_sync_context,
};
static const struct arm_smmu_flush_ops arm_smmu_s2_tlb_ops_v1 = {
.tlb = {
.tlb_flush_all = arm_smmu_tlb_inv_context_s2,
- .tlb_flush_walk = arm_smmu_tlb_inv_walk,
- .tlb_flush_leaf = arm_smmu_tlb_inv_leaf,
- .tlb_add_page = arm_smmu_tlb_add_page,
+ .tlb_flush_walk = arm_smmu_tlb_inv_any_s2_v1,
+ .tlb_flush_leaf = arm_smmu_tlb_inv_any_s2_v1,
+ .tlb_add_page = arm_smmu_tlb_add_page_s2_v1,
},
- .tlb_inv_range = arm_smmu_tlb_inv_vmid_nosync,
.tlb_sync = arm_smmu_tlb_sync_vmid,
};
diff --git a/drivers/iommu/arm-smmu.h b/drivers/iommu/arm-smmu.h
index b19b6cae9b5e..6edd35ca983c 100644
--- a/drivers/iommu/arm-smmu.h
+++ b/drivers/iommu/arm-smmu.h
@@ -306,8 +306,6 @@ enum arm_smmu_domain_stage {
struct arm_smmu_flush_ops {
struct iommu_flush_ops tlb;
- void (*tlb_inv_range)(unsigned long iova, size_t size, size_t granule,
- bool leaf, void *cookie);
void (*tlb_sync)(void *cookie);
};
--
2.21.0.dirty
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 2/4] iommu/arm-smmu: Remove "leaf" indirection
From: Robin Murphy @ 2019-09-18 16:17 UTC (permalink / raw)
To: will; +Cc: iommu, joro, linux-arm-kernel
In-Reply-To: <cover.1568820087.git.robin.murphy@arm.com>
Now that the "leaf" flag is no longer part of an external interface,
there's no need to use it to infer a register offset at runtime when
we can just as easily encode the offset directly in its place.
Signed-off-by: Robin Murphy <robin.murphy@arm.com>
---
drivers/iommu/arm-smmu.c | 29 ++++++++++++++++-------------
1 file changed, 16 insertions(+), 13 deletions(-)
diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
index f2b81b1ce224..b5b4cd4cae19 100644
--- a/drivers/iommu/arm-smmu.c
+++ b/drivers/iommu/arm-smmu.c
@@ -312,18 +312,16 @@ static void arm_smmu_tlb_inv_context_s2(void *cookie)
}
static void arm_smmu_tlb_inv_range_s1(unsigned long iova, size_t size,
- size_t granule, void *cookie, bool leaf)
+ size_t granule, void *cookie, int reg)
{
struct arm_smmu_domain *smmu_domain = cookie;
struct arm_smmu_device *smmu = smmu_domain->smmu;
struct arm_smmu_cfg *cfg = &smmu_domain->cfg;
- int reg, idx = cfg->cbndx;
+ int idx = cfg->cbndx;
if (smmu->features & ARM_SMMU_FEAT_COHERENT_WALK)
wmb();
- reg = leaf ? ARM_SMMU_CB_S1_TLBIVAL : ARM_SMMU_CB_S1_TLBIVA;
-
if (cfg->fmt != ARM_SMMU_CTX_FMT_AARCH64) {
iova = (iova >> 12) << 12;
iova |= cfg->asid;
@@ -342,16 +340,15 @@ static void arm_smmu_tlb_inv_range_s1(unsigned long iova, size_t size,
}
static void arm_smmu_tlb_inv_range_s2(unsigned long iova, size_t size,
- size_t granule, void *cookie, bool leaf)
+ size_t granule, void *cookie, int reg)
{
struct arm_smmu_domain *smmu_domain = cookie;
struct arm_smmu_device *smmu = smmu_domain->smmu;
- int reg, idx = smmu_domain->cfg.cbndx;
+ int idx = smmu_domain->cfg.cbndx;
if (smmu->features & ARM_SMMU_FEAT_COHERENT_WALK)
wmb();
- reg = leaf ? ARM_SMMU_CB_S2_TLBIIPAS2L : ARM_SMMU_CB_S2_TLBIIPAS2;
iova >>= 12;
do {
if (smmu_domain->cfg.fmt == ARM_SMMU_CTX_FMT_AARCH64)
@@ -365,14 +362,16 @@ static void arm_smmu_tlb_inv_range_s2(unsigned long iova, size_t size,
static void arm_smmu_tlb_inv_walk_s1(unsigned long iova, size_t size,
size_t granule, void *cookie)
{
- arm_smmu_tlb_inv_range_s1(iova, size, granule, cookie, false);
+ arm_smmu_tlb_inv_range_s1(iova, size, granule, cookie,
+ ARM_SMMU_CB_S1_TLBIVA);
arm_smmu_tlb_sync_context(cookie);
}
static void arm_smmu_tlb_inv_leaf_s1(unsigned long iova, size_t size,
size_t granule, void *cookie)
{
- arm_smmu_tlb_inv_range_s1(iova, size, granule, cookie, true);
+ arm_smmu_tlb_inv_range_s1(iova, size, granule, cookie,
+ ARM_SMMU_CB_S1_TLBIVAL);
arm_smmu_tlb_sync_context(cookie);
}
@@ -380,20 +379,23 @@ static void arm_smmu_tlb_add_page_s1(struct iommu_iotlb_gather *gather,
unsigned long iova, size_t granule,
void *cookie)
{
- arm_smmu_tlb_inv_range_s1(iova, granule, granule, cookie, true);
+ arm_smmu_tlb_inv_range_s1(iova, granule, granule, cookie,
+ ARM_SMMU_CB_S1_TLBIVAL);
}
static void arm_smmu_tlb_inv_walk_s2(unsigned long iova, size_t size,
size_t granule, void *cookie)
{
- arm_smmu_tlb_inv_range_s2(iova, size, granule, cookie, false);
+ arm_smmu_tlb_inv_range_s2(iova, size, granule, cookie,
+ ARM_SMMU_CB_S2_TLBIIPAS2);
arm_smmu_tlb_sync_context(cookie);
}
static void arm_smmu_tlb_inv_leaf_s2(unsigned long iova, size_t size,
size_t granule, void *cookie)
{
- arm_smmu_tlb_inv_range_s2(iova, size, granule, cookie, true);
+ arm_smmu_tlb_inv_range_s2(iova, size, granule, cookie,
+ ARM_SMMU_CB_S2_TLBIIPAS2L);
arm_smmu_tlb_sync_context(cookie);
}
@@ -401,7 +403,8 @@ static void arm_smmu_tlb_add_page_s2(struct iommu_iotlb_gather *gather,
unsigned long iova, size_t granule,
void *cookie)
{
- arm_smmu_tlb_inv_range_s2(iova, granule, granule, cookie, true);
+ arm_smmu_tlb_inv_range_s2(iova, granule, granule, cookie,
+ ARM_SMMU_CB_S2_TLBIIPAS2L);
}
static void arm_smmu_tlb_inv_any_s2_v1(unsigned long iova, size_t size,
--
2.21.0.dirty
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 4/4] iommu/arm-smmu: Remove arm_smmu_flush_ops
From: Robin Murphy @ 2019-09-18 16:17 UTC (permalink / raw)
To: will; +Cc: iommu, joro, linux-arm-kernel
In-Reply-To: <cover.1568820087.git.robin.murphy@arm.com>
Now it's just an empty wrapper.
Signed-off-by: Robin Murphy <robin.murphy@arm.com>
---
drivers/iommu/arm-smmu.c | 40 +++++++++++++++++-----------------------
drivers/iommu/arm-smmu.h | 6 +-----
2 files changed, 18 insertions(+), 28 deletions(-)
diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
index cc3b7517458d..68e8d9d1902b 100644
--- a/drivers/iommu/arm-smmu.c
+++ b/drivers/iommu/arm-smmu.c
@@ -427,31 +427,25 @@ static void arm_smmu_tlb_add_page_s2_v1(struct iommu_iotlb_gather *gather,
arm_smmu_gr0_write(smmu, ARM_SMMU_GR0_TLBIVMID, smmu_domain->cfg.vmid);
}
-static const struct arm_smmu_flush_ops arm_smmu_s1_tlb_ops = {
- .tlb = {
- .tlb_flush_all = arm_smmu_tlb_inv_context_s1,
- .tlb_flush_walk = arm_smmu_tlb_inv_walk_s1,
- .tlb_flush_leaf = arm_smmu_tlb_inv_leaf_s1,
- .tlb_add_page = arm_smmu_tlb_add_page_s1,
- },
+static const struct iommu_flush_ops arm_smmu_s1_tlb_ops = {
+ .tlb_flush_all = arm_smmu_tlb_inv_context_s1,
+ .tlb_flush_walk = arm_smmu_tlb_inv_walk_s1,
+ .tlb_flush_leaf = arm_smmu_tlb_inv_leaf_s1,
+ .tlb_add_page = arm_smmu_tlb_add_page_s1,
};
-static const struct arm_smmu_flush_ops arm_smmu_s2_tlb_ops_v2 = {
- .tlb = {
- .tlb_flush_all = arm_smmu_tlb_inv_context_s2,
- .tlb_flush_walk = arm_smmu_tlb_inv_walk_s2,
- .tlb_flush_leaf = arm_smmu_tlb_inv_leaf_s2,
- .tlb_add_page = arm_smmu_tlb_add_page_s2,
- },
+static const struct iommu_flush_ops arm_smmu_s2_tlb_ops_v2 = {
+ .tlb_flush_all = arm_smmu_tlb_inv_context_s2,
+ .tlb_flush_walk = arm_smmu_tlb_inv_walk_s2,
+ .tlb_flush_leaf = arm_smmu_tlb_inv_leaf_s2,
+ .tlb_add_page = arm_smmu_tlb_add_page_s2,
};
-static const struct arm_smmu_flush_ops arm_smmu_s2_tlb_ops_v1 = {
- .tlb = {
- .tlb_flush_all = arm_smmu_tlb_inv_context_s2,
- .tlb_flush_walk = arm_smmu_tlb_inv_any_s2_v1,
- .tlb_flush_leaf = arm_smmu_tlb_inv_any_s2_v1,
- .tlb_add_page = arm_smmu_tlb_add_page_s2_v1,
- },
+static const struct iommu_flush_ops arm_smmu_s2_tlb_ops_v1 = {
+ .tlb_flush_all = arm_smmu_tlb_inv_context_s2,
+ .tlb_flush_walk = arm_smmu_tlb_inv_any_s2_v1,
+ .tlb_flush_leaf = arm_smmu_tlb_inv_any_s2_v1,
+ .tlb_add_page = arm_smmu_tlb_add_page_s2_v1,
};
static irqreturn_t arm_smmu_context_fault(int irq, void *dev)
@@ -781,7 +775,7 @@ static int arm_smmu_init_domain_context(struct iommu_domain *domain,
.ias = ias,
.oas = oas,
.coherent_walk = smmu->features & ARM_SMMU_FEAT_COHERENT_WALK,
- .tlb = &smmu_domain->flush_ops->tlb,
+ .tlb = smmu_domain->flush_ops,
.iommu_dev = smmu->dev,
};
@@ -1210,7 +1204,7 @@ static void arm_smmu_flush_iotlb_all(struct iommu_domain *domain)
if (smmu_domain->flush_ops) {
arm_smmu_rpm_get(smmu);
- smmu_domain->flush_ops->tlb.tlb_flush_all(smmu_domain);
+ smmu_domain->flush_ops->tlb_flush_all(smmu_domain);
arm_smmu_rpm_put(smmu);
}
}
diff --git a/drivers/iommu/arm-smmu.h b/drivers/iommu/arm-smmu.h
index 5032102f05b7..ba0f05952dd9 100644
--- a/drivers/iommu/arm-smmu.h
+++ b/drivers/iommu/arm-smmu.h
@@ -304,14 +304,10 @@ enum arm_smmu_domain_stage {
ARM_SMMU_DOMAIN_BYPASS,
};
-struct arm_smmu_flush_ops {
- struct iommu_flush_ops tlb;
-};
-
struct arm_smmu_domain {
struct arm_smmu_device *smmu;
struct io_pgtable_ops *pgtbl_ops;
- const struct arm_smmu_flush_ops *flush_ops;
+ const struct iommu_flush_ops *flush_ops;
struct arm_smmu_cfg cfg;
enum arm_smmu_domain_stage stage;
bool non_strict;
--
2.21.0.dirty
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 3/4] iommu/arm-smmu: Move .tlb_sync method to implementation
From: Robin Murphy @ 2019-09-18 16:17 UTC (permalink / raw)
To: will; +Cc: iommu, joro, linux-arm-kernel
In-Reply-To: <cover.1568820087.git.robin.murphy@arm.com>
With the .tlb_sync interface no longer exposed directly to io-pgtable,
strip away the remains of that abstraction layer. Retain the callback
in spirit, though, by transforming it into an implementation override
for the low-level sync routine itself, for which we will have at least
one user.
Signed-off-by: Robin Murphy <robin.murphy@arm.com>
---
drivers/iommu/arm-smmu.c | 33 +++++++++++++++------------------
drivers/iommu/arm-smmu.h | 3 ++-
2 files changed, 17 insertions(+), 19 deletions(-)
diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
index b5b4cd4cae19..cc3b7517458d 100644
--- a/drivers/iommu/arm-smmu.c
+++ b/drivers/iommu/arm-smmu.c
@@ -244,6 +244,9 @@ static void __arm_smmu_tlb_sync(struct arm_smmu_device *smmu, int page,
unsigned int spin_cnt, delay;
u32 reg;
+ if (smmu->impl && unlikely(smmu->impl->tlb_sync))
+ return smmu->impl->tlb_sync(smmu, page, sync, status);
+
arm_smmu_writel(smmu, page, sync, QCOM_DUMMY_VAL);
for (delay = 1; delay < TLB_LOOP_TIMEOUT; delay *= 2) {
for (spin_cnt = TLB_SPIN_COUNT; spin_cnt > 0; spin_cnt--) {
@@ -268,9 +271,8 @@ static void arm_smmu_tlb_sync_global(struct arm_smmu_device *smmu)
spin_unlock_irqrestore(&smmu->global_sync_lock, flags);
}
-static void arm_smmu_tlb_sync_context(void *cookie)
+static void arm_smmu_tlb_sync_context(struct arm_smmu_domain *smmu_domain)
{
- struct arm_smmu_domain *smmu_domain = cookie;
struct arm_smmu_device *smmu = smmu_domain->smmu;
unsigned long flags;
@@ -280,13 +282,6 @@ static void arm_smmu_tlb_sync_context(void *cookie)
spin_unlock_irqrestore(&smmu_domain->cb_lock, flags);
}
-static void arm_smmu_tlb_sync_vmid(void *cookie)
-{
- struct arm_smmu_domain *smmu_domain = cookie;
-
- arm_smmu_tlb_sync_global(smmu_domain->smmu);
-}
-
static void arm_smmu_tlb_inv_context_s1(void *cookie)
{
struct arm_smmu_domain *smmu_domain = cookie;
@@ -297,7 +292,7 @@ static void arm_smmu_tlb_inv_context_s1(void *cookie)
wmb();
arm_smmu_cb_write(smmu_domain->smmu, smmu_domain->cfg.cbndx,
ARM_SMMU_CB_S1_TLBIASID, smmu_domain->cfg.asid);
- arm_smmu_tlb_sync_context(cookie);
+ arm_smmu_tlb_sync_context(smmu_domain);
}
static void arm_smmu_tlb_inv_context_s2(void *cookie)
@@ -439,7 +434,6 @@ static const struct arm_smmu_flush_ops arm_smmu_s1_tlb_ops = {
.tlb_flush_leaf = arm_smmu_tlb_inv_leaf_s1,
.tlb_add_page = arm_smmu_tlb_add_page_s1,
},
- .tlb_sync = arm_smmu_tlb_sync_context,
};
static const struct arm_smmu_flush_ops arm_smmu_s2_tlb_ops_v2 = {
@@ -449,7 +443,6 @@ static const struct arm_smmu_flush_ops arm_smmu_s2_tlb_ops_v2 = {
.tlb_flush_leaf = arm_smmu_tlb_inv_leaf_s2,
.tlb_add_page = arm_smmu_tlb_add_page_s2,
},
- .tlb_sync = arm_smmu_tlb_sync_context,
};
static const struct arm_smmu_flush_ops arm_smmu_s2_tlb_ops_v1 = {
@@ -459,7 +452,6 @@ static const struct arm_smmu_flush_ops arm_smmu_s2_tlb_ops_v1 = {
.tlb_flush_leaf = arm_smmu_tlb_inv_any_s2_v1,
.tlb_add_page = arm_smmu_tlb_add_page_s2_v1,
},
- .tlb_sync = arm_smmu_tlb_sync_vmid,
};
static irqreturn_t arm_smmu_context_fault(int irq, void *dev)
@@ -1229,11 +1221,16 @@ static void arm_smmu_iotlb_sync(struct iommu_domain *domain,
struct arm_smmu_domain *smmu_domain = to_smmu_domain(domain);
struct arm_smmu_device *smmu = smmu_domain->smmu;
- if (smmu_domain->flush_ops) {
- arm_smmu_rpm_get(smmu);
- smmu_domain->flush_ops->tlb_sync(smmu_domain);
- arm_smmu_rpm_put(smmu);
- }
+ if (!smmu)
+ return;
+
+ arm_smmu_rpm_get(smmu);
+ if (smmu->version == ARM_SMMU_V2 ||
+ smmu_domain->stage == ARM_SMMU_DOMAIN_S1)
+ arm_smmu_tlb_sync_context(smmu_domain);
+ else
+ arm_smmu_tlb_sync_global(smmu);
+ arm_smmu_rpm_put(smmu);
}
static phys_addr_t arm_smmu_iova_to_phys_hard(struct iommu_domain *domain,
diff --git a/drivers/iommu/arm-smmu.h b/drivers/iommu/arm-smmu.h
index 6edd35ca983c..5032102f05b7 100644
--- a/drivers/iommu/arm-smmu.h
+++ b/drivers/iommu/arm-smmu.h
@@ -306,7 +306,6 @@ enum arm_smmu_domain_stage {
struct arm_smmu_flush_ops {
struct iommu_flush_ops tlb;
- void (*tlb_sync)(void *cookie);
};
struct arm_smmu_domain {
@@ -333,6 +332,8 @@ struct arm_smmu_impl {
int (*cfg_probe)(struct arm_smmu_device *smmu);
int (*reset)(struct arm_smmu_device *smmu);
int (*init_context)(struct arm_smmu_domain *smmu_domain);
+ void (*tlb_sync)(struct arm_smmu_device *smmu, int page, int sync,
+ int status);
};
static inline void __iomem *arm_smmu_page(struct arm_smmu_device *smmu, int n)
--
2.21.0.dirty
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH V2 2/2] mm/pgtable/debug: Add test validating architecture page table helpers
From: Christophe Leroy @ 2019-09-18 16:26 UTC (permalink / raw)
To: Anshuman Khandual, linux-mm
Cc: Mark Rutland, linux-ia64, linux-sh, Peter Zijlstra, James Hogan,
Heiko Carstens, Michal Hocko, Dave Hansen, Paul Mackerras,
sparclinux, Thomas Gleixner, linux-s390, Jason Gunthorpe,
Michael Ellerman, x86, Russell King - ARM Linux, Matthew Wilcox,
Steven Price, Tetsuo Handa, Gerald Schaefer, linux-snps-arc,
Kees Cook, Masahiro Yamada, Mark Brown, Kirill A . Shutemov,
Dan Williams, Vlastimil Babka, linux-arm-kernel,
Sri Krishna chowdary, Ard Biesheuvel, Greg Kroah-Hartman,
linux-mips, Ralf Baechle, linux-kernel, Paul Burton,
Mike Rapoport, Vineet Gupta, Martin Schwidefsky, Andrew Morton,
linuxppc-dev, David S. Miller
In-Reply-To: <f872e6f4-a5cb-069d-2034-78961930cb9f@arm.com>
Le 18/09/2019 à 07:04, Anshuman Khandual a écrit :
>
>
> On 09/13/2019 03:31 PM, Christophe Leroy wrote:
>>
>>
>> Le 13/09/2019 à 11:02, Anshuman Khandual a écrit :
>>>
>>>>> +#if !defined(__PAGETABLE_PMD_FOLDED) && !defined(__ARCH_HAS_4LEVEL_HACK)
>>>>
>>>> #ifdefs have to be avoided as much as possible, see below
>>>
>>> Yeah but it has been bit difficult to avoid all these $ifdef because of the
>>> availability (or lack of it) for all these pgtable helpers in various config
>>> combinations on all platforms.
>>
>> As far as I can see these pgtable helpers should exist everywhere at least via asm-generic/ files.
>
> But they might not actually do the right thing.
>
>>
>> Can you spot a particular config which fails ?
>
> Lets consider the following example (after removing the $ifdefs around it)
> which though builds successfully but fails to pass the intended test. This
> is with arm64 config 4K pages sizes with 39 bits VA space which ends up
> with a 3 level page table arrangement.
>
> static void __init p4d_clear_tests(p4d_t *p4dp)
> {
> p4d_t p4d = READ_ONCE(*p4dp);
My suggestion was not to completely drop the #ifdef but to do like you
did in pgd_clear_tests() for instance, ie to add the following test on
top of the function:
if (mm_pud_folded(mm) || is_defined(__ARCH_HAS_5LEVEL_HACK))
return;
>
> p4d = __p4d(p4d_val(p4d) | RANDOM_ORVALUE);
> WRITE_ONCE(*p4dp, p4d);
> p4d_clear(p4dp);
> p4d = READ_ONCE(*p4dp);
> WARN_ON(!p4d_none(p4d));
> }
>
> The following test hits an error at WARN_ON(!p4d_none(p4d))
>
> [ 16.757333] ------------[ cut here ]------------
> [ 16.758019] WARNING: CPU: 11 PID: 1 at mm/arch_pgtable_test.c:187 arch_pgtable_tests_init+0x24c/0x474
> [ 16.759455] Modules linked in:
> [ 16.759952] CPU: 11 PID: 1 Comm: swapper/0 Not tainted 5.3.0-next-20190916-00005-g61c218153bb8-dirty #222
> [ 16.761449] Hardware name: linux,dummy-virt (DT)
> [ 16.762185] pstate: 00400005 (nzcv daif +PAN -UAO)
> [ 16.762964] pc : arch_pgtable_tests_init+0x24c/0x474
> [ 16.763750] lr : arch_pgtable_tests_init+0x174/0x474
> [ 16.764534] sp : ffffffc011d7bd50
> [ 16.765065] x29: ffffffc011d7bd50 x28: ffffffff1756bac0
> [ 16.765908] x27: ffffff85ddaf3000 x26: 00000000000002e8
> [ 16.766767] x25: ffffffc0111ce000 x24: ffffff85ddaf32e8
> [ 16.767606] x23: ffffff85ddaef278 x22: 00000045cc844000
> [ 16.768445] x21: 000000065daef003 x20: ffffffff17540000
> [ 16.769283] x19: ffffff85ddb60000 x18: 0000000000000014
> [ 16.770122] x17: 00000000980426bb x16: 00000000698594c6
> [ 16.770976] x15: 0000000066e25a88 x14: 0000000000000000
> [ 16.771813] x13: ffffffff17540000 x12: 000000000000000a
> [ 16.772651] x11: ffffff85fcfd0a40 x10: 0000000000000001
> [ 16.773488] x9 : 0000000000000008 x8 : ffffffc01143ab26
> [ 16.774336] x7 : 0000000000000000 x6 : 0000000000000000
> [ 16.775180] x5 : 0000000000000000 x4 : 0000000000000000
> [ 16.776018] x3 : ffffffff1756bbe8 x2 : 000000065daeb003
> [ 16.776856] x1 : 000000000065daeb x0 : fffffffffffff000
> [ 16.777693] Call trace:
> [ 16.778092] arch_pgtable_tests_init+0x24c/0x474
> [ 16.778843] do_one_initcall+0x74/0x1b0
> [ 16.779458] kernel_init_freeable+0x1cc/0x290
> [ 16.780151] kernel_init+0x10/0x100
> [ 16.780710] ret_from_fork+0x10/0x18
> [ 16.781282] ---[ end trace 042e6c40c0a3b038 ]---
>
> On arm64 (4K page size|39 bits VA|3 level page table)
>
> #elif CONFIG_PGTABLE_LEVELS == 3 /* Applicable here */
> #define __ARCH_USE_5LEVEL_HACK
> #include <asm-generic/pgtable-nopud.h>
>
> Which pulls in
>
> #include <asm-generic/pgtable-nop4d-hack.h>
>
> which pulls in
>
> #include <asm-generic/5level-fixup.h>
>
> which defines
>
> static inline int p4d_none(p4d_t p4d)
> {
> return 0;
> }
>
> which will invariably trigger WARN_ON(!p4d_none(p4d)).
>
> Similarly for next test p4d_populate_tests() which will always be
> successful because p4d_bad() invariably returns negative.
>
> static inline int p4d_bad(p4d_t p4d)
> {
> return 0;
> }
>
> static void __init p4d_populate_tests(struct mm_struct *mm, p4d_t *p4dp,
> pud_t *pudp)
> {
> p4d_t p4d;
>
> /*
> * This entry points to next level page table page.
> * Hence this must not qualify as p4d_bad().
> */
> pud_clear(pudp);
> p4d_clear(p4dp);
> p4d_populate(mm, p4dp, pudp);
> p4d = READ_ONCE(*p4dp);
> WARN_ON(p4d_bad(p4d));
> }
>
> We should not run these tests for the above config because they are
> not applicable and will invariably produce same result.
>
>>
>>>
>>>>
>>
>> [...]
>>
>>>>> +#if !defined(__PAGETABLE_PUD_FOLDED) && !defined(__ARCH_HAS_5LEVEL_HACK)
>>>>
>>>> The same can be done here.
>>>
>>> IIRC not only the page table helpers but there are data types (pxx_t) which
>>> were not present on various configs and these wrappers help prevent build
>>> failures. Any ways will try and see if this can be improved further. But
>>> meanwhile if you have some suggestions, please do let me know.
>>
>> pgt_t and pmd_t are everywhere I guess.
>> then pud_t and p4d_t have fallbacks in asm-generic files.
>
> Lets take another example where it fails to compile. On arm64 with 16K
> page size, 48 bits VA, 4 level page table arrangement in the following
> test, pgd_populate() does not have the required signature.
>
> static void pgd_populate_tests(struct mm_struct *mm, pgd_t *pgdp, p4d_t *p4dp)
> {
> pgd_t pgd;
>
> if (mm_p4d_folded(mm))
> return;
>
> /*
> * This entry points to next level page table page.
> * Hence this must not qualify as pgd_bad().
> */
> p4d_clear(p4dp);
> pgd_clear(pgdp);
> pgd_populate(mm, pgdp, p4dp);
> pgd = READ_ONCE(*pgdp);
> WARN_ON(pgd_bad(pgd));
> }
>
> mm/arch_pgtable_test.c: In function ‘pgd_populate_tests’:
> mm/arch_pgtable_test.c:254:25: error: passing argument 3 of ‘pgd_populate’ from incompatible pointer type [-Werror=incompatible-pointer-types]
> pgd_populate(mm, pgdp, p4dp);
> ^~~~
> In file included from mm/arch_pgtable_test.c:27:0:
> ./arch/arm64/include/asm/pgalloc.h:81:20: note: expected ‘pud_t * {aka struct <anonymous> *}’ but argument is of type ‘pgd_t * {aka struct <anonymous> *}’
> static inline void pgd_populate(struct mm_struct *mm, pgd_t *pgdp, pud_t *pudp)
>
> The build failure is because p4d_t * maps to pgd_t * but the applicable
> (it does not fallback on generic ones) pgd_populate() expects a pud_t *.
>
> Except for archs which have 5 level page able, pgd_populate() always accepts
> lower level page table pointers as the last argument as they dont have that
> many levels.
>
> arch/x86/include/asm/pgalloc.h:static inline void pgd_populate(struct mm_struct *mm, pgd_t *pgd, p4d_t *p4d)
> arch/s390/include/asm/pgalloc.h:static inline void pgd_populate(struct mm_struct *mm, pgd_t *pgd, p4d_t *p4d)
>
> But others
>
> arch/arm64/include/asm/pgalloc.h:static inline void pgd_populate(struct mm_struct *mm, pgd_t *pgdp, pud_t *pudp)
> arch/m68k/include/asm/motorola_pgalloc.h:static inline void pgd_populate(struct mm_struct *mm, pgd_t *pgd, pmd_t *pmd)
> arch/mips/include/asm/pgalloc.h:static inline void pgd_populate(struct mm_struct *mm, pgd_t *pgd, pud_t *pud)
> arch/powerpc/include/asm/book3s/64/pgalloc.h:static inline void pgd_populate(struct mm_struct *mm, pgd_t *pgd, pud_t *pud)
>
> I remember going through all these combinations before arriving at the
> current state of #ifdef exclusions. Probably, to solved this all platforms
> have to define pxx_populate() helpers assuming they support 5 level page
> table.
>
>>
>> So it shouldn't be an issue. Maybe if a couple of arches miss them, the best would be to fix the arches, since that's the purpose of your testsuite isn't it ?
>
> The run time failures as explained previously is because of the folding which
> needs to be protected as they are not even applicable. The compile time
> failures are because pxx_populate() signatures are platform specific depending
> on how many page table levels they really support.
>
So IIUC, the compiletime problem is around __ARCH_HAS_5LEVEL_HACK. For
all #if !defined(__PAGETABLE_PXX_FOLDED), something equivalent to the
following should make the trick.
if (mm_pxx_folded())
return;
For the __ARCH_HAS_5LEVEL_HACK stuff, I think we should be able to
regroup all impacted functions inside a single #ifdef
__ARCH_HAS_5LEVEL_HACK
Christophe
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] hwrng: iproc-rng200 - Use devm_platform_ioremap_resource() in iproc_rng200_probe()
From: Ray Jui @ 2019-09-18 16:37 UTC (permalink / raw)
To: Markus Elfring, linux-crypto, linux-arm-kernel,
bcm-kernel-feedback-list, Arnd Bergmann, Florian Fainelli,
Greg Kroah-Hartman, Herbert Xu, Matt Mackall, Ray Jui,
Scott Branden
Cc: Bartosz Golaszewski, kernel-janitors, LKML, Himanshu Jha
In-Reply-To: <0ecb0679-0558-6cbe-af2f-6ee9122a4a7e@web.de>
On 9/18/19 12:19 AM, Markus Elfring wrote:
> From: Markus Elfring <elfring@users.sourceforge.net>
> Date: Wed, 18 Sep 2019 09:09:22 +0200
>
> Simplify this function implementation by using a known wrapper function.
>
> This issue was detected by using the Coccinelle software.
>
> Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
> ---
> drivers/char/hw_random/iproc-rng200.c | 9 +--------
> 1 file changed, 1 insertion(+), 8 deletions(-)
>
> diff --git a/drivers/char/hw_random/iproc-rng200.c b/drivers/char/hw_random/iproc-rng200.c
> index 92be1c0ab99f..899ff25f4f28 100644
> --- a/drivers/char/hw_random/iproc-rng200.c
> +++ b/drivers/char/hw_random/iproc-rng200.c
> @@ -181,7 +181,6 @@ static void iproc_rng200_cleanup(struct hwrng *rng)
> static int iproc_rng200_probe(struct platform_device *pdev)
> {
> struct iproc_rng200_dev *priv;
> - struct resource *res;
> struct device *dev = &pdev->dev;
> int ret;
>
> @@ -190,13 +189,7 @@ static int iproc_rng200_probe(struct platform_device *pdev)
> return -ENOMEM;
>
> /* Map peripheral */
> - res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> - if (!res) {
> - dev_err(dev, "failed to get rng resources\n");
> - return -EINVAL;
> - }
> -
> - priv->base = devm_ioremap_resource(dev, res);
> + priv->base = devm_platform_ioremap_resource(pdev, 0);
> if (IS_ERR(priv->base)) {
> dev_err(dev, "failed to remap rng regs\n");
> return PTR_ERR(priv->base);
> --
> 2.23.0
>
Change looks good to me, thanks!
Reviewed-by: Ray Jui <ray.jui@broadcom.com>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v4 1/3] arm64: cpufeature: introduce helper cpu_has_hw_af()
From: Catalin Marinas @ 2019-09-18 16:45 UTC (permalink / raw)
To: Suzuki K Poulose
Cc: Mark Rutland, Kaly Xin, Ralph Campbell, Jia He, Andrew Morton,
Anshuman Khandual, Marc Zyngier, linux-kernel, Matthew Wilcox,
Jun Yao, linux-mm, Jérôme Glisse, James Morse,
linux-arm-kernel, Punit Agrawal, hejianet, Thomas Gleixner,
Will Deacon, Alex Van Brunt, Kirill A. Shutemov, Robin Murphy
In-Reply-To: <78881acb-5871-9534-c8cc-6f54937be3fd@arm.com>
On Wed, Sep 18, 2019 at 03:20:41PM +0100, Suzuki K Poulose wrote:
> On 18/09/2019 14:19, Jia He wrote:
> > diff --git a/arch/arm64/include/asm/cpufeature.h b/arch/arm64/include/asm/cpufeature.h
> > index c96ffa4722d3..206b6e3954cf 100644
> > --- a/arch/arm64/include/asm/cpufeature.h
> > +++ b/arch/arm64/include/asm/cpufeature.h
> > @@ -390,6 +390,7 @@ extern DECLARE_BITMAP(boot_capabilities, ARM64_NPATCHABLE);
> > for_each_set_bit(cap, cpu_hwcaps, ARM64_NCAPS)
> > bool this_cpu_has_cap(unsigned int cap);
> > +bool cpu_has_hw_af(void);
> > void cpu_set_feature(unsigned int num);
> > bool cpu_have_feature(unsigned int num);
> > unsigned long cpu_get_elf_hwcap(void);
> > diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
> > index b1fdc486aed8..c5097f58649d 100644
> > --- a/arch/arm64/kernel/cpufeature.c
> > +++ b/arch/arm64/kernel/cpufeature.c
> > @@ -1141,6 +1141,12 @@ static bool has_hw_dbm(const struct arm64_cpu_capabilities *cap,
> > return true;
> > }
> > +/* Decouple AF from AFDBM. */
> > +bool cpu_has_hw_af(void)
> > +{
> Sorry for not having asked this earlier. Are we interested in,
>
> "whether *this* CPU has AF support ?" or "whether *at least one*
> CPU has the AF support" ? The following code does the former.
>
> > + return (read_cpuid(ID_AA64MMFR1_EL1) & 0xf);
In a non-preemptible context, the former is ok (per-CPU).
--
Catalin
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v4 1/3] arm64: cpufeature: introduce helper cpu_has_hw_af()
From: Catalin Marinas @ 2019-09-18 16:49 UTC (permalink / raw)
To: Matthew Wilcox
Cc: Mark Rutland, Kaly Xin, Ralph Campbell, Jia He, Andrew Morton,
Suzuki Poulose, Marc Zyngier, Anshuman Khandual, linux-kernel,
Jun Yao, linux-mm, Jérôme Glisse, James Morse,
linux-arm-kernel, Punit Agrawal, hejianet, Thomas Gleixner,
Will Deacon, Alex Van Brunt, Kirill A. Shutemov, Robin Murphy
In-Reply-To: <20190918142017.GC9880@bombadil.infradead.org>
On Wed, Sep 18, 2019 at 07:20:17AM -0700, Matthew Wilcox wrote:
> On Wed, Sep 18, 2019 at 09:19:12PM +0800, Jia He wrote:
> > +/* Decouple AF from AFDBM. */
> > +bool cpu_has_hw_af(void)
> > +{
> > + return (read_cpuid(ID_AA64MMFR1_EL1) & 0xf);
> > +}
> > +
>
> Do you really want to call read_cpuid() every time? I would have thought
> you'd want to use the static branch mechanism to do the right thing at
> boot time. See Documentation/static-keys.txt.
We do have a static branch mechanism for other CPU features but mostly
because on some big.LITTLE systems, the CPUs may differ slightly so we
only advertise the common features.
I guess here the additional instructions for reading and checking the
CPUID here would be lost in the noise compared to the actual page
copying.
--
Catalin
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
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