Searched hist:8012 (Results 1 - 25 of 29) sorted by relevance

12

/linux-master/drivers/net/wireless/broadcom/brcm80211/brcmutil/
H A Dutils.cdiff 8012ec4a Sat May 27 05:49:54 MDT 2023 Juhee Kang <claudiajkang@gmail.com> wifi: brcmutil: use helper function pktq_empty() instead of open code

pktq_empty was added in commit 5b435de0d786 ("net: wireless: add brcm80211
drivers") but it is currently not being utilized in some areas. This commit
replaces the open code with the pktq_empty() function.

Signed-off-by: Juhee Kang <claudiajkang@gmail.com>
Reviewed-by: Simon Horman <simon.horman@corigine.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20230527114954.3281-2-claudiajkang@gmail.com
/linux-master/arch/arm/kernel/
H A Dcrash_dump.cdiff 8fad87bc Wed Mar 26 23:56:18 MDT 2014 Liu Hua <sdu.liu@huawei.com> ARM: 8012/1: kdump: Avoid overflow when converting pfn to physaddr

When we configure CONFIG_ARM_LPAE=y, pfn << PAGE_SHIFT will
overflow if pfn >= 0x100000 in copy_oldmem_page.
So use __pfn_to_phys for converting.

Signed-off-by: Liu Hua <sdu.liu@huawei.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
/linux-master/drivers/gpio/
H A Dgpio-nomadik.cdiff 5545d501 Tue Mar 05 15:09:04 MST 2024 Linus Walleij <linus.walleij@linaro.org> gpio: nomadik: Back out some managed resources

Several commits introduce managed resources (devm_*) into the
nmk_gpio_populate_chip() function.

This isn't always working because when called from the Nomadik pin
control driver we just want to populate some states for the device as
the same states are used by the pin control driver.

Some managed resources such as devm_kzalloc() etc will work, as the
passed in platform device will be used for lifecycle management,
but in some cases where we used the looked-up platform device
for the GPIO block, this will cause problems for the combined
pin control and GPIO driver, because it adds managed resources
to the GPIO device before it is probed, which is something that
the device core will not accept, and all of the GPIO blocks will
refuse to probe:

platform 8012e000.gpio: Resources present before probing
platform 8012e080.gpio: Resources present before probing
(...)

Fix this by not tying any managed resources to the looked-up
gpio_pdev/gpio_dev device, let's just live with the fact that
these need imperative resource management for now.

Drop in some notes and use a local *dev variable to clarify the
code.

Cc: Théo Lebrun <theo.lebrun@bootlin.com>
Fixes: 12410e95903c ("gpio: nomadik: use devm_platform_ioremap_resource() helper")
Link: https://lore.kernel.org/r/20240305-fix-nomadik-gpio-v2-1-e5d1fbdc3f5c@linaro.org
[Fixed some last minut print formatting]
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
diff 5545d501 Tue Mar 05 15:09:04 MST 2024 Linus Walleij <linus.walleij@linaro.org> gpio: nomadik: Back out some managed resources

Several commits introduce managed resources (devm_*) into the
nmk_gpio_populate_chip() function.

This isn't always working because when called from the Nomadik pin
control driver we just want to populate some states for the device as
the same states are used by the pin control driver.

Some managed resources such as devm_kzalloc() etc will work, as the
passed in platform device will be used for lifecycle management,
but in some cases where we used the looked-up platform device
for the GPIO block, this will cause problems for the combined
pin control and GPIO driver, because it adds managed resources
to the GPIO device before it is probed, which is something that
the device core will not accept, and all of the GPIO blocks will
refuse to probe:

platform 8012e000.gpio: Resources present before probing
platform 8012e080.gpio: Resources present before probing
(...)

Fix this by not tying any managed resources to the looked-up
gpio_pdev/gpio_dev device, let's just live with the fact that
these need imperative resource management for now.

Drop in some notes and use a local *dev variable to clarify the
code.

Cc: Théo Lebrun <theo.lebrun@bootlin.com>
Fixes: 12410e95903c ("gpio: nomadik: use devm_platform_ioremap_resource() helper")
Link: https://lore.kernel.org/r/20240305-fix-nomadik-gpio-v2-1-e5d1fbdc3f5c@linaro.org
[Fixed some last minut print formatting]
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
H A Dgpiolib.cdiff 9c10280d Wed May 25 02:56:03 MDT 2016 Linus Walleij <linus.walleij@linaro.org> gpio: flush direction status in gpiochip_lock_as_irq()

As irqchip and gpiochip functions are orthogonal, the IRQ
set-up or something else can have changed the direction of
the GPIO line from what the GPIO descriptor knows when we
get into gpiochip_lock_as_irq(). Make sure to re-read the
direction setting if we have the .get_direction() callback
enabled for the chip.

Else we get problems like this:

iio iio:device2: interrupts on the rising edge
gpio gpiochip2: (8012e080.gpio): gpiochip_lock_as_irq:
tried to flag a GPIO set as output for IRQ
gpio gpiochip2: (8012e080.gpio): unable to lock HW IRQ 0 for IRQ
genirq: Failed to request resources for l3g4200d-trigger
(irq 111) on irqchip nmk1-32-63
iio iio:device2: failed to request trigger IRQ.
st-gyro-i2c: probe of 2-0068 failed with error -22

Fixes: 72d320006177 ("gpio: set up initial state from .get_direction()")
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
diff 9c10280d Wed May 25 02:56:03 MDT 2016 Linus Walleij <linus.walleij@linaro.org> gpio: flush direction status in gpiochip_lock_as_irq()

As irqchip and gpiochip functions are orthogonal, the IRQ
set-up or something else can have changed the direction of
the GPIO line from what the GPIO descriptor knows when we
get into gpiochip_lock_as_irq(). Make sure to re-read the
direction setting if we have the .get_direction() callback
enabled for the chip.

Else we get problems like this:

iio iio:device2: interrupts on the rising edge
gpio gpiochip2: (8012e080.gpio): gpiochip_lock_as_irq:
tried to flag a GPIO set as output for IRQ
gpio gpiochip2: (8012e080.gpio): unable to lock HW IRQ 0 for IRQ
genirq: Failed to request resources for l3g4200d-trigger
(irq 111) on irqchip nmk1-32-63
iio iio:device2: failed to request trigger IRQ.
st-gyro-i2c: probe of 2-0068 failed with error -22

Fixes: 72d320006177 ("gpio: set up initial state from .get_direction()")
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
/linux-master/drivers/pinctrl/nomadik/
H A Dpinctrl-nomadik.cdiff b95e0bd2 Mon Oct 14 05:11:52 MDT 2019 Linus Walleij <linus.walleij@linaro.org> pinctrl: nomadik: Drop support for latent IRQ

The latent IRQs are IRQs that have occurred when the system
was down in deep sleep and the GPIO block was powered off.
The PRCMU (power reset and control unit) knows which GPIO
line offset fired an IRQ to wake the system up (if so
desired) and this second IRQ was used to replay the action
when the system came back online after suspend().

This is now known to be the wrong approach to solve this
problem: in a patch series Lina Iyer has suggested to
instead make it possible to model the IRQs as hierarchical
with double parents.

Also the current device trees do not contain the right
information to make this code work, the latent IRQ is not
specified nowadays giving noise like this in the console:

[ 0.612168] gpio 8012e000.gpio: IRQ index 1 not found
[ 0.622523] gpio 8012e080.gpio: IRQ index 1 not found

Let's delete the latent IRQ code and reimplement it properly
when we need it.

Cc: Ulf Hansson <ulf.hansson@linaro.org>
Cc: Lina Iyer <ilina@codeaurora.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20191014111154.9731-1-linus.walleij@linaro.org
diff b95e0bd2 Mon Oct 14 05:11:52 MDT 2019 Linus Walleij <linus.walleij@linaro.org> pinctrl: nomadik: Drop support for latent IRQ

The latent IRQs are IRQs that have occurred when the system
was down in deep sleep and the GPIO block was powered off.
The PRCMU (power reset and control unit) knows which GPIO
line offset fired an IRQ to wake the system up (if so
desired) and this second IRQ was used to replay the action
when the system came back online after suspend().

This is now known to be the wrong approach to solve this
problem: in a patch series Lina Iyer has suggested to
instead make it possible to model the IRQs as hierarchical
with double parents.

Also the current device trees do not contain the right
information to make this code work, the latent IRQ is not
specified nowadays giving noise like this in the console:

[ 0.612168] gpio 8012e000.gpio: IRQ index 1 not found
[ 0.622523] gpio 8012e080.gpio: IRQ index 1 not found

Let's delete the latent IRQ code and reimplement it properly
when we need it.

Cc: Ulf Hansson <ulf.hansson@linaro.org>
Cc: Lina Iyer <ilina@codeaurora.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20191014111154.9731-1-linus.walleij@linaro.org
diff 31ebe86d Mon Sep 19 02:17:32 MDT 2016 Linus Walleij <linus.walleij@linaro.org> pinctrl: nomadik: don't default-flag IRQs as falling

There is no point in adding any default trigger for these
GPIO interrupts: the device tree should contain all trigger
information and the platforms using the driver boots
exclusively from device tree.

Also the boot log is nagging me to fix this:

[ 0.771057] ------------[ cut here ]------------
[ 0.775695] WARNING: CPU: 0 PID: 1 at
../drivers/gpio/gpiolib.c:1622 _gpiochip_irqchip_add+0x138/0x160
[ 0.785034] /soc/gpio@8012e000: Ignoring 2 default trigger
(...)
[ 0.942962] gpio 8012e000.gpio: at address e08f8000
(etc ad nauseam)

Suggested-by: Marc Zyngier <marc.zyngier@arm.com>
Acked-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
diff 31ebe86d Mon Sep 19 02:17:32 MDT 2016 Linus Walleij <linus.walleij@linaro.org> pinctrl: nomadik: don't default-flag IRQs as falling

There is no point in adding any default trigger for these
GPIO interrupts: the device tree should contain all trigger
information and the platforms using the driver boots
exclusively from device tree.

Also the boot log is nagging me to fix this:

[ 0.771057] ------------[ cut here ]------------
[ 0.775695] WARNING: CPU: 0 PID: 1 at
../drivers/gpio/gpiolib.c:1622 _gpiochip_irqchip_add+0x138/0x160
[ 0.785034] /soc/gpio@8012e000: Ignoring 2 default trigger
(...)
[ 0.942962] gpio 8012e000.gpio: at address e08f8000
(etc ad nauseam)

Suggested-by: Marc Zyngier <marc.zyngier@arm.com>
Acked-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
/linux-master/include/linux/can/
H A Dskb.hdiff e940e089 Fri Feb 26 02:24:56 MST 2021 Oleksij Rempel <linux@rempel-privat.de> can: skb: can_skb_set_owner(): fix ref counting if socket was closed before setting skb ownership

There are two ref count variables controlling the free()ing of a socket:
- struct sock::sk_refcnt - which is changed by sock_hold()/sock_put()
- struct sock::sk_wmem_alloc - which accounts the memory allocated by
the skbs in the send path.

In case there are still TX skbs on the fly and the socket() is closed,
the struct sock::sk_refcnt reaches 0. In the TX-path the CAN stack
clones an "echo" skb, calls sock_hold() on the original socket and
references it. This produces the following back trace:

| WARNING: CPU: 0 PID: 280 at lib/refcount.c:25 refcount_warn_saturate+0x114/0x134
| refcount_t: addition on 0; use-after-free.
| Modules linked in: coda_vpu(E) v4l2_jpeg(E) videobuf2_vmalloc(E) imx_vdoa(E)
| CPU: 0 PID: 280 Comm: test_can.sh Tainted: G E 5.11.0-04577-gf8ff6603c617 #203
| Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree)
| Backtrace:
| [<80bafea4>] (dump_backtrace) from [<80bb0280>] (show_stack+0x20/0x24) r7:00000000 r6:600f0113 r5:00000000 r4:81441220
| [<80bb0260>] (show_stack) from [<80bb593c>] (dump_stack+0xa0/0xc8)
| [<80bb589c>] (dump_stack) from [<8012b268>] (__warn+0xd4/0x114) r9:00000019 r8:80f4a8c2 r7:83e4150c r6:00000000 r5:00000009 r4:80528f90
| [<8012b194>] (__warn) from [<80bb09c4>] (warn_slowpath_fmt+0x88/0xc8) r9:83f26400 r8:80f4a8d1 r7:00000009 r6:80528f90 r5:00000019 r4:80f4a8c2
| [<80bb0940>] (warn_slowpath_fmt) from [<80528f90>] (refcount_warn_saturate+0x114/0x134) r8:00000000 r7:00000000 r6:82b44000 r5:834e5600 r4:83f4d540
| [<80528e7c>] (refcount_warn_saturate) from [<8079a4c8>] (__refcount_add.constprop.0+0x4c/0x50)
| [<8079a47c>] (__refcount_add.constprop.0) from [<8079a57c>] (can_put_echo_skb+0xb0/0x13c)
| [<8079a4cc>] (can_put_echo_skb) from [<8079ba98>] (flexcan_start_xmit+0x1c4/0x230) r9:00000010 r8:83f48610 r7:0fdc0000 r6:0c080000 r5:82b44000 r4:834e5600
| [<8079b8d4>] (flexcan_start_xmit) from [<80969078>] (netdev_start_xmit+0x44/0x70) r9:814c0ba0 r8:80c8790c r7:00000000 r6:834e5600 r5:82b44000 r4:82ab1f00
| [<80969034>] (netdev_start_xmit) from [<809725a4>] (dev_hard_start_xmit+0x19c/0x318) r9:814c0ba0 r8:00000000 r7:82ab1f00 r6:82b44000 r5:00000000 r4:834e5600
| [<80972408>] (dev_hard_start_xmit) from [<809c6584>] (sch_direct_xmit+0xcc/0x264) r10:834e5600 r9:00000000 r8:00000000 r7:82b44000 r6:82ab1f00 r5:834e5600 r4:83f27400
| [<809c64b8>] (sch_direct_xmit) from [<809c6c0c>] (__qdisc_run+0x4f0/0x534)

To fix this problem, only set skb ownership to sockets which have still
a ref count > 0.

Fixes: 0ae89beb283a ("can: add destructor for self generated skbs")
Cc: Oliver Hartkopp <socketcan@hartkopp.net>
Cc: Andre Naujoks <nautsch2@gmail.com>
Link: https://lore.kernel.org/r/20210226092456.27126-1-o.rempel@pengutronix.de
Suggested-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de>
Reviewed-by: Oliver Hartkopp <socketcan@hartkopp.net>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
diff e940e089 Fri Feb 26 02:24:56 MST 2021 Oleksij Rempel <linux@rempel-privat.de> can: skb: can_skb_set_owner(): fix ref counting if socket was closed before setting skb ownership

There are two ref count variables controlling the free()ing of a socket:
- struct sock::sk_refcnt - which is changed by sock_hold()/sock_put()
- struct sock::sk_wmem_alloc - which accounts the memory allocated by
the skbs in the send path.

In case there are still TX skbs on the fly and the socket() is closed,
the struct sock::sk_refcnt reaches 0. In the TX-path the CAN stack
clones an "echo" skb, calls sock_hold() on the original socket and
references it. This produces the following back trace:

| WARNING: CPU: 0 PID: 280 at lib/refcount.c:25 refcount_warn_saturate+0x114/0x134
| refcount_t: addition on 0; use-after-free.
| Modules linked in: coda_vpu(E) v4l2_jpeg(E) videobuf2_vmalloc(E) imx_vdoa(E)
| CPU: 0 PID: 280 Comm: test_can.sh Tainted: G E 5.11.0-04577-gf8ff6603c617 #203
| Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree)
| Backtrace:
| [<80bafea4>] (dump_backtrace) from [<80bb0280>] (show_stack+0x20/0x24) r7:00000000 r6:600f0113 r5:00000000 r4:81441220
| [<80bb0260>] (show_stack) from [<80bb593c>] (dump_stack+0xa0/0xc8)
| [<80bb589c>] (dump_stack) from [<8012b268>] (__warn+0xd4/0x114) r9:00000019 r8:80f4a8c2 r7:83e4150c r6:00000000 r5:00000009 r4:80528f90
| [<8012b194>] (__warn) from [<80bb09c4>] (warn_slowpath_fmt+0x88/0xc8) r9:83f26400 r8:80f4a8d1 r7:00000009 r6:80528f90 r5:00000019 r4:80f4a8c2
| [<80bb0940>] (warn_slowpath_fmt) from [<80528f90>] (refcount_warn_saturate+0x114/0x134) r8:00000000 r7:00000000 r6:82b44000 r5:834e5600 r4:83f4d540
| [<80528e7c>] (refcount_warn_saturate) from [<8079a4c8>] (__refcount_add.constprop.0+0x4c/0x50)
| [<8079a47c>] (__refcount_add.constprop.0) from [<8079a57c>] (can_put_echo_skb+0xb0/0x13c)
| [<8079a4cc>] (can_put_echo_skb) from [<8079ba98>] (flexcan_start_xmit+0x1c4/0x230) r9:00000010 r8:83f48610 r7:0fdc0000 r6:0c080000 r5:82b44000 r4:834e5600
| [<8079b8d4>] (flexcan_start_xmit) from [<80969078>] (netdev_start_xmit+0x44/0x70) r9:814c0ba0 r8:80c8790c r7:00000000 r6:834e5600 r5:82b44000 r4:82ab1f00
| [<80969034>] (netdev_start_xmit) from [<809725a4>] (dev_hard_start_xmit+0x19c/0x318) r9:814c0ba0 r8:00000000 r7:82ab1f00 r6:82b44000 r5:00000000 r4:834e5600
| [<80972408>] (dev_hard_start_xmit) from [<809c6584>] (sch_direct_xmit+0xcc/0x264) r10:834e5600 r9:00000000 r8:00000000 r7:82b44000 r6:82ab1f00 r5:834e5600 r4:83f27400
| [<809c64b8>] (sch_direct_xmit) from [<809c6c0c>] (__qdisc_run+0x4f0/0x534)

To fix this problem, only set skb ownership to sockets which have still
a ref count > 0.

Fixes: 0ae89beb283a ("can: add destructor for self generated skbs")
Cc: Oliver Hartkopp <socketcan@hartkopp.net>
Cc: Andre Naujoks <nautsch2@gmail.com>
Link: https://lore.kernel.org/r/20210226092456.27126-1-o.rempel@pengutronix.de
Suggested-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de>
Reviewed-by: Oliver Hartkopp <socketcan@hartkopp.net>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
/linux-master/arch/mips/mti-malta/
H A Dmalta-int.cdiff 9eec1c01 Thu Apr 06 09:58:09 MDT 2017 Matt Redfearn <matt.redfearn@mips.com> MIPS: Malta: Fix i8259 irqchip setup

Since commit 4cfffcfa5106 ("irqchip/mips-gic: Fix local interrupts"),
the gic driver has been allocating virq's for local interrupts during
its initialisation. Unfortunately on Malta platforms, these are the
first IRQs to be allocated and so are allocated virqs 1-3. The i8259
driver uses a legacy irq domain which expects to map virqs 0-15. Probing
of that driver therefore fails because some of those virqs are already
taken, with the warning:

WARNING: CPU: 0 PID: 0 at kernel/irq/irqdomain.c:344
irq_domain_associate+0x1e8/0x228
error: virq1 is already associated
Modules linked in:
CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.10.0-rc6-00011-g4cfffcfa5106 #368
Stack : 00000000 00000000 807ae03a 0000004d 00000000 806c1010 0000000b ffff0a01
80725467 807258f4 806a64a4 00000000 00000000 807a9acc 00000100 80713e68
806d5598 8017593c 8072bf90 8072bf94 806ac358 00000000 806abb60 80713ce4
00000100 801b22d4 806d5598 8017593c 807ae03a 00000000 80713ce4 80720000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
...
Call Trace:
[<8010c480>] show_stack+0x88/0xa4
[<80376758>] dump_stack+0x88/0xd0
[<8012c4a8>] __warn+0x104/0x118
[<8012c4ec>] warn_slowpath_fmt+0x30/0x3c
[<8017edfc>] irq_domain_associate+0x1e8/0x228
[<8017efd0>] irq_domain_add_legacy+0x7c/0xb0
[<80764c50>] __init_i8259_irqs+0x64/0xa0
[<80764ca4>] i8259_of_init+0x18/0x74
[<8076ddc0>] of_irq_init+0x19c/0x310
[<80752dd8>] arch_init_irq+0x28/0x19c
[<80750a08>] start_kernel+0x2a8/0x434

Fix this by reserving the required i8259 virqs in malta platform code
before probing any irq chips.

Fixes: 4cfffcfa5106 ("irqchip/mips-gic: Fix local interrupts")
Signed-off-by: Matt Redfearn <matt.redfearn@imgtec.com>
Cc: James Hogan <james.hogan@imgtec.com>
Cc: Paul Burton <paul.burton@imgtec.com>
Cc: linux-mips@linux-mips.org
Cc: linux-kernel@vger.kernel.org
Patchwork: https://patchwork.linux-mips.org/patch/15919/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
diff 9eec1c01 Thu Apr 06 09:58:09 MDT 2017 Matt Redfearn <matt.redfearn@mips.com> MIPS: Malta: Fix i8259 irqchip setup

Since commit 4cfffcfa5106 ("irqchip/mips-gic: Fix local interrupts"),
the gic driver has been allocating virq's for local interrupts during
its initialisation. Unfortunately on Malta platforms, these are the
first IRQs to be allocated and so are allocated virqs 1-3. The i8259
driver uses a legacy irq domain which expects to map virqs 0-15. Probing
of that driver therefore fails because some of those virqs are already
taken, with the warning:

WARNING: CPU: 0 PID: 0 at kernel/irq/irqdomain.c:344
irq_domain_associate+0x1e8/0x228
error: virq1 is already associated
Modules linked in:
CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.10.0-rc6-00011-g4cfffcfa5106 #368
Stack : 00000000 00000000 807ae03a 0000004d 00000000 806c1010 0000000b ffff0a01
80725467 807258f4 806a64a4 00000000 00000000 807a9acc 00000100 80713e68
806d5598 8017593c 8072bf90 8072bf94 806ac358 00000000 806abb60 80713ce4
00000100 801b22d4 806d5598 8017593c 807ae03a 00000000 80713ce4 80720000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
...
Call Trace:
[<8010c480>] show_stack+0x88/0xa4
[<80376758>] dump_stack+0x88/0xd0
[<8012c4a8>] __warn+0x104/0x118
[<8012c4ec>] warn_slowpath_fmt+0x30/0x3c
[<8017edfc>] irq_domain_associate+0x1e8/0x228
[<8017efd0>] irq_domain_add_legacy+0x7c/0xb0
[<80764c50>] __init_i8259_irqs+0x64/0xa0
[<80764ca4>] i8259_of_init+0x18/0x74
[<8076ddc0>] of_irq_init+0x19c/0x310
[<80752dd8>] arch_init_irq+0x28/0x19c
[<80750a08>] start_kernel+0x2a8/0x434

Fix this by reserving the required i8259 virqs in malta platform code
before probing any irq chips.

Fixes: 4cfffcfa5106 ("irqchip/mips-gic: Fix local interrupts")
Signed-off-by: Matt Redfearn <matt.redfearn@imgtec.com>
Cc: James Hogan <james.hogan@imgtec.com>
Cc: Paul Burton <paul.burton@imgtec.com>
Cc: linux-mips@linux-mips.org
Cc: linux-kernel@vger.kernel.org
Patchwork: https://patchwork.linux-mips.org/patch/15919/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
diff 13b7ea63 Wed Oct 30 08:27:48 MDT 2013 Markos Chandras <markos.chandras@imgtec.com> MIPS: malta: Fix GIC interrupt offsets

The GIC interrupt offsets are calculated based on the value of NR_CPUS.
However, this is wrong because NR_CPUS may or may not contain the real
number of the actual cpus present in the system. We fix that by using
the 'nr_cpu_ids' variable which contains the real number of cpus in
the system. Previously, an MT core (eg with 8 VPEs) will fail to boot if
NR_CPUS was > 8 with the following errors:

------------[ cut here ]------------
WARNING: CPU: 0 PID: 0 at kernel/irq/chip.c:670 __irq_set_handler+0x15c/0x164()
Modules linked in:
CPU: 0 PID: 0 Comm: swapper/0 Tainted: G W 3.12.0-rc5-00087-gced5633 5
Stack : 00000006 00000004 00000000 00000000 00000000 00000000 807a4f36 00000053
807a0000 00000000 80173218 80565aa8 00000000 00000000 00000000 0000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 0000000
00000000 00000000 00000000 8054fd00 8054fd94 80500514 805657a7 8016eb4
807a0000 80500514 00000000 00000000 80565aa8 8079a5d8 80565766 8054fd0
...
Call Trace:
[<801098c0>] show_stack+0x64/0x7c
[<8049c6b0>] dump_stack+0x64/0x84
[<8012efc4>] warn_slowpath_common+0x84/0xb4
[<8012f00c>] warn_slowpath_null+0x18/0x24
[<80173218>] __irq_set_handler+0x15c/0x164
[<80587cf4>] arch_init_ipiirq+0x2c/0x3c
[<805880c8>] arch_init_irq+0x3c4/0x4bc
[<80588e28>] init_IRQ+0x3c/0x50
[<805847e8>] start_kernel+0x230/0x3d8

---[ end trace 4eaa2a86a8e2da26 ]---

This is now fixed and the Malta board can boot with any NR_CPUS value
which also helps supporting more processors in a single kernel binary.

Signed-off-by: Markos Chandras <markos.chandras@imgtec.com>
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/6091/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
diff 13b7ea63 Wed Oct 30 08:27:48 MDT 2013 Markos Chandras <markos.chandras@imgtec.com> MIPS: malta: Fix GIC interrupt offsets

The GIC interrupt offsets are calculated based on the value of NR_CPUS.
However, this is wrong because NR_CPUS may or may not contain the real
number of the actual cpus present in the system. We fix that by using
the 'nr_cpu_ids' variable which contains the real number of cpus in
the system. Previously, an MT core (eg with 8 VPEs) will fail to boot if
NR_CPUS was > 8 with the following errors:

------------[ cut here ]------------
WARNING: CPU: 0 PID: 0 at kernel/irq/chip.c:670 __irq_set_handler+0x15c/0x164()
Modules linked in:
CPU: 0 PID: 0 Comm: swapper/0 Tainted: G W 3.12.0-rc5-00087-gced5633 5
Stack : 00000006 00000004 00000000 00000000 00000000 00000000 807a4f36 00000053
807a0000 00000000 80173218 80565aa8 00000000 00000000 00000000 0000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 0000000
00000000 00000000 00000000 8054fd00 8054fd94 80500514 805657a7 8016eb4
807a0000 80500514 00000000 00000000 80565aa8 8079a5d8 80565766 8054fd0
...
Call Trace:
[<801098c0>] show_stack+0x64/0x7c
[<8049c6b0>] dump_stack+0x64/0x84
[<8012efc4>] warn_slowpath_common+0x84/0xb4
[<8012f00c>] warn_slowpath_null+0x18/0x24
[<80173218>] __irq_set_handler+0x15c/0x164
[<80587cf4>] arch_init_ipiirq+0x2c/0x3c
[<805880c8>] arch_init_irq+0x3c4/0x4bc
[<80588e28>] init_IRQ+0x3c/0x50
[<805847e8>] start_kernel+0x230/0x3d8

---[ end trace 4eaa2a86a8e2da26 ]---

This is now fixed and the Malta board can boot with any NR_CPUS value
which also helps supporting more processors in a single kernel binary.

Signed-off-by: Markos Chandras <markos.chandras@imgtec.com>
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/6091/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
/linux-master/drivers/gpu/drm/bridge/
H A Dmegachips-stdpxxxx-ge-b850v3-fw.cdiff 11632d4a Thu Nov 25 03:53:02 MST 2021 Martyn Welch <martyn.welch@collabora.com> drm/bridge: megachips: Ensure both bridges are probed before registration

In the configuration used by the b850v3, the STDP2690 is used to read EDID
data whilst it's the STDP4028 which can detect when monitors are connected.

This can result in problems at boot with monitors connected when the
STDP4028 is probed first, a monitor is detected and an attempt is made to
read the EDID data before the STDP2690 has probed:

[ 3.795721] Unable to handle kernel NULL pointer dereference at virtual address 00000018
[ 3.803845] pgd = (ptrval)
[ 3.806581] [00000018] *pgd=00000000
[ 3.810180] Internal error: Oops: 5 [#1] SMP ARM
[ 3.814813] Modules linked in:
[ 3.817879] CPU: 0 PID: 64 Comm: kworker/u4:1 Not tainted 5.15.0 #1
[ 3.824161] Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree)
[ 3.830705] Workqueue: events_unbound deferred_probe_work_func
[ 3.836565] PC is at stdp2690_get_edid+0x44/0x19c
[ 3.841286] LR is at ge_b850v3_lvds_get_modes+0x2c/0x5c
[ 3.846526] pc : [<805eae10>] lr : [<805eb138>] psr: 80000013
[ 3.852802] sp : 81c359d0 ip : 7dbb550b fp : 81c35a1c
[ 3.858037] r10: 81c73840 r9 : 81c73894 r8 : 816d9800
[ 3.863270] r7 : 00000000 r6 : 81c34000 r5 : 00000000 r4 : 810c35f0
[ 3.869808] r3 : 80e3e294 r2 : 00000080 r1 : 00000cc0 r0 : 81401180
[ 3.876349] Flags: Nzcv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none
[ 3.883499] Control: 10c5387d Table: 1000404a DAC: 00000051
[ 3.889254] Register r0 information: slab kmem_cache start 81401180 pointer offset 0
[ 3.897034] Register r1 information: non-paged memory
[ 3.902097] Register r2 information: non-paged memory
[ 3.907160] Register r3 information: non-slab/vmalloc memory
[ 3.912832] Register r4 information: non-slab/vmalloc memory
[ 3.918503] Register r5 information: NULL pointer
[ 3.923217] Register r6 information: non-slab/vmalloc memory
[ 3.928887] Register r7 information: NULL pointer
[ 3.933601] Register r8 information: slab kmalloc-1k start 816d9800 pointer offset 0 size 1024
[ 3.942244] Register r9 information: slab kmalloc-2k start 81c73800 pointer offset 148 size 2048
[ 3.951058] Register r10 information: slab kmalloc-2k start 81c73800 pointer offset 64 size 2048
[ 3.959873] Register r11 information: non-slab/vmalloc memory
[ 3.965632] Register r12 information: non-paged memory
[ 3.970781] Process kworker/u4:1 (pid: 64, stack limit = 0x(ptrval))
[ 3.977148] Stack: (0x81c359d0 to 0x81c36000)
[ 3.981517] 59c0: 80b2b668 80b2b5bc 000002e2 0000034e
[ 3.989712] 59e0: 81c35a8c 816d98e8 81c35a14 7dbb550b 805bfcd0 810c35f0 81c73840 824addc0
[ 3.997906] 5a00: 00001000 816d9800 81c73894 81c73840 81c35a34 81c35a20 805eb138 805eadd8
[ 4.006099] 5a20: 810c35f0 00000045 81c35adc 81c35a38 80594188 805eb118 80d7c788 80dd1848
[ 4.014292] 5a40: 00000000 81c35a50 80dca950 811194d3 80dca7c4 80dca944 80dca91c 816d9800
[ 4.022485] 5a60: 81c34000 81c760a8 816d9800 80c58c98 810c35f0 816d98e8 00001000 00001000
[ 4.030678] 5a80: 00000000 00000000 8017712c 81c60000 00000002 00000001 00000000 00000000
[ 4.038870] 5aa0: 816d9900 816d9900 00000000 7dbb550b 805c700c 00000008 826282c8 826282c8
[ 4.047062] 5ac0: 00001000 81e1ce40 00001000 00000002 81c35bf4 81c35ae0 805d9694 80593fc0
[ 4.055255] 5ae0: 8017a970 80179ad8 00000179 00000000 81c35bcc 81c35b00 80177108 8017a950
[ 4.063447] 5b00: 00000000 81c35b10 81c34000 00000000 81004fd8 81010a38 00000000 00000059
[ 4.071639] 5b20: 816d98d4 81fbb718 00000013 826282c8 8017a940 81c35b40 81134448 00000400
[ 4.079831] 5b40: 00000178 00000000 e063b9c1 00000000 c2000049 00000040 00000000 00000008
[ 4.088024] 5b60: 82628300 82628380 00000000 00000000 81c34000 00000000 81fbb700 82628340
[ 4.096216] 5b80: 826283c0 00001000 00000000 00000010 816d9800 826282c0 801766f8 00000000
[ 4.104408] 5ba0: 00000000 81004fd8 00000049 00000000 00000000 00000001 80dcf940 80178de4
[ 4.112601] 5bc0: 81c35c0c 7dbb550b 80178de4 81fbb700 00000010 00000010 810c35f4 81e1ce40
[ 4.120793] 5be0: 81c40908 0000000c 81c35c64 81c35bf8 805a7f18 805d94a0 81c35c3c 816d9800
[ 4.128985] 5c00: 00000010 81c34000 81c35c2c 81c35c18 8012fce0 805be90c 81c35c3c 81c35c28
[ 4.137178] 5c20: 805be90c 80173210 81fbb600 81fbb6b4 81c35c5c 7dbb550b 81c35c64 81fbb700
[ 4.145370] 5c40: 816d9800 00000010 810c35f4 81e1ce40 81c40908 0000000c 81c35c84 81c35c68
[ 4.153565] 5c60: 805a8c78 805a7ed0 816d9800 81fbb700 00000010 00000000 81c35cac 81c35c88
[ 4.161758] 5c80: 805a8dc4 805a8b68 816d9800 00000000 816d9800 00000000 8179f810 810c42d0
[ 4.169950] 5ca0: 81c35ccc 81c35cb0 805e47b0 805a8d18 824aa240 81e1ea80 81c40908 81126b60
[ 4.178144] 5cc0: 81c35d14 81c35cd0 8060db1c 805e46cc 81c35d14 81c35ce0 80dd90f8 810c4d58
[ 4.186338] 5ce0: 80dd90dc 81fe9740 fffffffe 81fe9740 81e1ea80 00000000 810c4d6c 80c4b95c
[ 4.194531] 5d00: 80dd9a3c 815c6810 81c35d34 81c35d18 8060dc9c 8060d8fc 8246b440 815c6800
[ 4.202724] 5d20: 815c6810 eefd8e00 81c35d44 81c35d38 8060dd80 8060dbec 81c35d6c 81c35d48
[ 4.210918] 5d40: 805e98a4 8060dd70 00000000 815c6810 810c45b0 81126e90 81126e90 80dd9a3c
[ 4.219112] 5d60: 81c35d8c 81c35d70 80619574 805e9808 815c6810 00000000 810c45b0 81126e90
[ 4.227305] 5d80: 81c35db4 81c35d90 806168dc 80619514 80625df0 80623c80 815c6810 810c45b0
[ 4.235498] 5da0: 81c35e6c 815c6810 81c35dec 81c35db8 80616d04 80616800 81c35de4 81c35dc8
[ 4.243691] 5dc0: 808382b0 80b2f444 8116e310 8116e314 81c35e6c 815c6810 00000003 80dd9a3c
[ 4.251884] 5de0: 81c35e14 81c35df0 80616ec8 80616c60 00000001 810c45b0 81c35e6c 815c6810
[ 4.260076] 5e00: 00000001 80dd9a3c 81c35e34 81c35e18 80617338 80616e90 00000000 81c35e6c
[ 4.268269] 5e20: 80617284 81c34000 81c35e64 81c35e38 80614730 80617290 81c35e64 8171a06c
[ 4.276461] 5e40: 81e220b8 7dbb550b 815c6810 81c34000 815c6854 81126e90 81c35e9c 81c35e68
[ 4.284654] 5e60: 8061673c 806146a8 8060f5e0 815c6810 00000001 7dbb550b 00000000 810c5080
[ 4.292847] 5e80: 810c5320 815c6810 81126e90 00000000 81c35eac 81c35ea0 80617554 80616650
[ 4.301040] 5ea0: 81c35ecc 81c35eb0 80615694 80617544 810c5080 810c5080 810c5094 81126e90
[ 4.309233] 5ec0: 81c35efc 81c35ed0 80615c6c 8061560c 80615bc0 810c50c0 817eeb00 81412800
[ 4.317425] 5ee0: 814c3000 00000000 814c300d 81119a60 81c35f3c 81c35f00 80141488 80615bcc
[ 4.325618] 5f00: 81c60000 81c34000 81c35f24 81c35f18 80143078 817eeb00 81412800 817eeb18
[ 4.333811] 5f20: 81412818 81003d00 00000088 81412800 81c35f74 81c35f40 80141a48 80141298
[ 4.342005] 5f40: 81c35f74 81c34000 801481ac 817efa40 817efc00 801417d8 817eeb00 00000000
[ 4.350199] 5f60: 815a7e7c 81c34000 81c35fac 81c35f78 80149b1c 801417e4 817efc20 817efc20
[ 4.358391] 5f80: ffffe000 817efa40 801499a8 00000000 00000000 00000000 00000000 00000000
[ 4.366583] 5fa0: 00000000 81c35fb0 80100130 801499b4 00000000 00000000 00000000 00000000
[ 4.374774] 5fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
[ 4.382966] 5fe0: 00000000 00000000 00000000 00000000 00000013 00000000 00000000 00000000
[ 4.391155] Backtrace:
[ 4.393613] [<805eadcc>] (stdp2690_get_edid) from [<805eb138>] (ge_b850v3_lvds_get_modes+0x2c/0x5c)
[ 4.402691] r10:81c73840 r9:81c73894 r8:816d9800 r7:00001000 r6:824addc0 r5:81c73840
[ 4.410534] r4:810c35f0
[ 4.413073] [<805eb10c>] (ge_b850v3_lvds_get_modes) from [<80594188>] (drm_helper_probe_single_connector_modes+0x1d4/0x84c)
[ 4.424240] r5:00000045 r4:810c35f0
[ 4.427822] [<80593fb4>] (drm_helper_probe_single_connector_modes) from [<805d9694>] (drm_client_modeset_probe+0x200/0x1384)
[ 4.439074] r10:00000002 r9:00001000 r8:81e1ce40 r7:00001000 r6:826282c8 r5:826282c8
[ 4.446917] r4:00000008
[ 4.449455] [<805d9494>] (drm_client_modeset_probe) from [<805a7f18>] (__drm_fb_helper_initial_config_and_unlock+0x54/0x5b4)
[ 4.460713] r10:0000000c r9:81c40908 r8:81e1ce40 r7:810c35f4 r6:00000010 r5:00000010
[ 4.468556] r4:81fbb700
[ 4.471095] [<805a7ec4>] (__drm_fb_helper_initial_config_and_unlock) from [<805a8c78>] (drm_fbdev_client_hotplug+0x11c/0x1b0)
[ 4.482434] r10:0000000c r9:81c40908 r8:81e1ce40 r7:810c35f4 r6:00000010 r5:816d9800
[ 4.490276] r4:81fbb700
[ 4.492814] [<805a8b5c>] (drm_fbdev_client_hotplug) from [<805a8dc4>] (drm_fbdev_generic_setup+0xb8/0x1a4)
[ 4.502494] r7:00000000 r6:00000010 r5:81fbb700 r4:816d9800
[ 4.508160] [<805a8d0c>] (drm_fbdev_generic_setup) from [<805e47b0>] (imx_drm_bind+0xf0/0x130)
[ 4.516805] r7:810c42d0 r6:8179f810 r5:00000000 r4:816d9800
[ 4.522474] [<805e46c0>] (imx_drm_bind) from [<8060db1c>] (try_to_bring_up_master+0x22c/0x2f0)
[ 4.531116] r7:81126b60 r6:81c40908 r5:81e1ea80 r4:824aa240
[ 4.536783] [<8060d8f0>] (try_to_bring_up_master) from [<8060dc9c>] (__component_add+0xbc/0x184)
[ 4.545597] r10:815c6810 r9:80dd9a3c r8:80c4b95c r7:810c4d6c r6:00000000 r5:81e1ea80
[ 4.553440] r4:81fe9740
[ 4.555980] [<8060dbe0>] (__component_add) from [<8060dd80>] (component_add+0x1c/0x20)
[ 4.563921] r7:eefd8e00 r6:815c6810 r5:815c6800 r4:8246b440
[ 4.569589] [<8060dd64>] (component_add) from [<805e98a4>] (dw_hdmi_imx_probe+0xa8/0xe8)
[ 4.577702] [<805e97fc>] (dw_hdmi_imx_probe) from [<80619574>] (platform_probe+0x6c/0xc8)
[ 4.585908] r9:80dd9a3c r8:81126e90 r7:81126e90 r6:810c45b0 r5:815c6810 r4:00000000
[ 4.593662] [<80619508>] (platform_probe) from [<806168dc>] (really_probe+0xe8/0x460)
[ 4.601524] r7:81126e90 r6:810c45b0 r5:00000000 r4:815c6810
[ 4.607191] [<806167f4>] (really_probe) from [<80616d04>] (__driver_probe_device+0xb0/0x230)
[ 4.615658] r7:815c6810 r6:81c35e6c r5:810c45b0 r4:815c6810
[ 4.621326] [<80616c54>] (__driver_probe_device) from [<80616ec8>] (driver_probe_device+0x44/0xe0)
[ 4.630313] r9:80dd9a3c r8:00000003 r7:815c6810 r6:81c35e6c r5:8116e314 r4:8116e310
[ 4.638068] [<80616e84>] (driver_probe_device) from [<80617338>] (__device_attach_driver+0xb4/0x12c)
[ 4.647227] r9:80dd9a3c r8:00000001 r7:815c6810 r6:81c35e6c r5:810c45b0 r4:00000001
[ 4.654981] [<80617284>] (__device_attach_driver) from [<80614730>] (bus_for_each_drv+0x94/0xd8)
[ 4.663794] r7:81c34000 r6:80617284 r5:81c35e6c r4:00000000
[ 4.669461] [<8061469c>] (bus_for_each_drv) from [<8061673c>] (__device_attach+0xf8/0x190)
[ 4.677753] r7:81126e90 r6:815c6854 r5:81c34000 r4:815c6810
[ 4.683419] [<80616644>] (__device_attach) from [<80617554>] (device_initial_probe+0x1c/0x20)
[ 4.691971] r8:00000000 r7:81126e90 r6:815c6810 r5:810c5320 r4:810c5080
[ 4.698681] [<80617538>] (device_initial_probe) from [<80615694>] (bus_probe_device+0x94/0x9c)
[ 4.707318] [<80615600>] (bus_probe_device) from [<80615c6c>] (deferred_probe_work_func+0xac/0xf0)
[ 4.716305] r7:81126e90 r6:810c5094 r5:810c5080 r4:810c5080
[ 4.721973] [<80615bc0>] (deferred_probe_work_func) from [<80141488>] (process_one_work+0x1fc/0x54c)
[ 4.731139] r10:81119a60 r9:814c300d r8:00000000 r7:814c3000 r6:81412800 r5:817eeb00
[ 4.738981] r4:810c50c0 r3:80615bc0
[ 4.742563] [<8014128c>] (process_one_work) from [<80141a48>] (worker_thread+0x270/0x570)
[ 4.750765] r10:81412800 r9:00000088 r8:81003d00 r7:81412818 r6:817eeb18 r5:81412800
[ 4.758608] r4:817eeb00
[ 4.761147] [<801417d8>] (worker_thread) from [<80149b1c>] (kthread+0x174/0x190)
[ 4.768574] r10:81c34000 r9:815a7e7c r8:00000000 r7:817eeb00 r6:801417d8 r5:817efc00
[ 4.776417] r4:817efa40
[ 4.778955] [<801499a8>] (kthread) from [<80100130>] (ret_from_fork+0x14/0x24)
[ 4.786201] Exception stack(0x81c35fb0 to 0x81c35ff8)
[ 4.791266] 5fa0: 00000000 00000000 00000000 00000000
[ 4.799459] 5fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
[ 4.807651] 5fe0: 00000000 00000000 00000000 00000000 00000013 00000000
[ 4.814279] r10:00000000 r9:00000000 r8:00000000 r7:00000000 r6:00000000 r5:801499a8
[ 4.822120] r4:817efa40
[ 4.824664] Code: e3a02080 e593001c e3a01d33 e3a05000 (e5979018)

Split the registration from the STDP4028 probe routine and only perform
registration once both the STDP4028 and STDP2690 have probed.

Signed-off-by: Martyn Welch <martyn.welch@collabora.com>
CC: Peter Senna Tschudin <peter.senna@gmail.com>
CC: Martyn Welch <martyn.welch@collabora.co.uk>
CC: Neil Armstrong <narmstrong@baylibre.com>
CC: Robert Foss <robert.foss@linaro.org>
CC: Laurent Pinchart <Laurent.pinchart@ideasonboard.com>
CC: Jonas Karlman <jonas@kwiboo.se>
CC: Jernej Skrabec <jernej.skrabec@gmail.com>
Signed-off-by: Robert Foss <robert.foss@linaro.org>
Link: https://patchwork.freedesktop.org/patch/msgid/43552c3404e8fdf92d8bc5658fac24e9f03c2c57.1637836606.git.martyn.welch@collabora.com
/linux-master/sound/soc/sh/rcar/
H A Dssiu.cdiff 8012c983 Tue Jan 05 14:38:41 MST 2016 Dan Carpenter <dan.carpenter@oracle.com> ASoC: rsnd: precedence error in rsnd_ssiu_init()

The bitwise OR has higher precedence than ?: so the val2 was always set
to 0x2.

Fixes: b4c83b171557 ('ASoC: rsnd: add Multi channel support')
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
/linux-master/arch/mips/include/asm/
H A Dcpu-features.hdiff cf5b2d23 Thu Aug 01 10:31:05 MDT 2013 Ralf Baechle <ralf@linux-mips.org> MIPS: oprofile: Fix BUG due to smp_processor_id() in preemptible code.

current_cpu_type() is not preemption-safe.
If CONFIG_PREEMPT is enabled then mipsxx_reg_setup() can be called from preemptible state.
Added get_cpu()/put_cpu() pair to make it preemption-safe.

This was found while testing oprofile with CONFIG_DEBUG_PREEMPT enable.

/usr/zntestsuite # opcontrol --init
/usr/zntestsuite # opcontrol --setup --event=L2_CACHE_ACCESSES:500 --event=L2_CACHE_MISSES:500 --no-vmlinux
/usr/zntestsuite # opcontrol --start
Using 2.6+ OProfile kernel interface.
BUG: using smp_processor_id() in preemptible [00000000] code: oprofiled/1362
caller is mipsxx_reg_setup+0x11c/0x164
CPU: 0 PID: 1362 Comm: oprofiled Not tainted 3.10.4 #18
Stack : 00000006 70757465 00000000 00000000 00000000 00000000 80b173f6 00000037
80b10000 00000000 80b21614 88f5a220 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 89c49c00 89c49c2c 80721254 807b7927 8012c1d0
80b10000 80721254 00000000 00000552 88f5a220 80b1335c 807b78e6 89c49ba8
...
Call Trace:
[<801099a4>] show_stack+0x64/0x7c
[<80665520>] dump_stack+0x20/0x2c
[<803a2250>] debug_smp_processor_id+0xe0/0xf0
[<8052df24>] mipsxx_reg_setup+0x11c/0x164
[<8052cd70>] op_mips_setup+0x24/0x4c
[<80529cfc>] oprofile_setup+0x5c/0x12c
[<8052b9f8>] event_buffer_open+0x78/0xf8
[<801c3150>] do_dentry_open.isra.15+0x2b8/0x3b0
[<801c3270>] finish_open+0x28/0x4c
[<801d49b8>] do_last.isra.41+0x2cc/0xd00
[<801d54a0>] path_openat+0xb4/0x4c4
[<801d5c44>] do_filp_open+0x3c/0xac
[<801c4744>] do_sys_open+0x110/0x1f4
[<8010f47c>] stack_done+0x20/0x44

Bug reported and original patch by Jerin Jacob <jerinjacobk@gmail.com>.

Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Acked-by: Jerin Jacob <jerinjacobk@gmail.com>
H A Dmipsregs.hdiff 63c2b681 Mon Mar 18 09:56:10 MDT 2013 Florian Fainelli <florian@openwrt.org> MIPS: Fix code generation for non-DSP capable CPUs

Commit 32a7ede (MIPS: dsp: Add assembler support for DSP ASEs) has
enabled the use of DSP ASE specific instructions such as rddsp and wrdsp
under the idea that all code path that will make use of these two
instructions are properly checking for cpu_has_dsp to ensure that the
particular CPU we are running on *actually* supports DSP ASE.

This commit actually causes the following oops on QEMU Malta emulating a
MIPS 24Kc without the DSP ASE implemented:

[ 7.960000] Reserved instruction in kernel
[ 7.960000] Cpu 0
[ 7.960000] $ 0 : 00000000 00000000 00000014 00000005
[ 7.960000] $ 4 : 8fc2de48 00000001 00000000 8f59ddb0
[ 7.960000] $ 8 : 8f5ceec4 00000018 00000c00 00800000
[ 7.960000] $12 : 00000100 00000200 00000000 00457b84
[ 7.960000] $16 : 00000000 8fc2ba78 8f4ec980 00000001
[ 7.960000] $20 : 80418f90 00000000 00000000 000002dd
[ 7.960000] $24 : 0000009c 7730d7b8
[ 7.960000] $28 : 8f59c000 8f59dd38 00000001 80104248
[ 7.960000] Hi : 0000001d
[ 7.960000] Lo : 0000000b
[ 7.960000] epc : 801041ec thread_saved_pc+0x2c/0x38
[ 7.960000] Not tainted
[ 7.960000] ra : 80104248 get_wchan+0x48/0xac
[ 7.960000] Status: 1000b703 KERNEL EXL IE
[ 7.960000] Cause : 10800028
[ 7.960000] PrId : 00019300 (MIPS 24Kc)
[ 7.960000] Modules linked in:
[ 7.960000] Process killall (pid: 1574, threadinfo=8f59c000,
task=8fd14558, tls=773aa440)
[ 7.960000] Stack : 8fc2ba78 8012b008 0000000c 0000001d 00000000
00000000 8f58a380
8f58a380 8fc2ba78 80202668 8f59de78 8f468600 8f59de28
801b2a3c 8f59df00 8f98ba20 74696e69
8f468600 8f59de28 801b7308 0081c007 00000000 00000000
00000000 00000000 00000000 00000000
00000000 8fc2bbb4 00000001 0000001d 0000000b 77f038cc
7fe80648 ffffffff ffffffff 00000000
00000001 0016e000 00000000 ...
[ 7.960000] Call Trace:
[ 7.960000] [<801041ec>] thread_saved_pc+0x2c/0x38
[ 7.960000] [<80104248>] get_wchan+0x48/0xac

The disassembly of thread_saved_pc points to the following:
000006d0 <thread_saved_pc>:
6d0: 8c820208 lw v0,520(a0)
6d4: 3c030000 lui v1,0x0
6d8: 24630000 addiu v1,v1,0
6dc: 10430008 beq v0,v1,700 <thread_saved_pc+0x30>
6e0: 00000000 nop
6e4: 3c020000 lui v0,0x0
6e8: 8c43000c lw v1,12(v0)
6ec: 04620004 bltzl v1,700 <thread_saved_pc+0x30>
6f0: 00001021 move v0,zero
6f4: 8c840200 lw a0,512(a0)
6f8: 00031080 sll v0,v1,0x2
6fc: 7c44100a lwx v0,a0(v0) <------------
700: 03e00008 jr ra
704: 00000000 nop

If we specifically disable -mdsp/-mdspr2 for arch/mips/kernel/process.o,
we get the following (non-crashing) assembly:

00000708 <thread_saved_pc>:
708: 8c820208 lw v0,520(a0)
70c: 3c030000 lui v1,0x0
710: 24630000 addiu v1,v1,0
714: 10430009 beq v0,v1,73c <thread_saved_pc+0x34>
718: 00000000 nop
71c: 3c020000 lui v0,0x0
720: 8c42000c lw v0,12(v0)
724: 04420005 bltzl v0,73c <thread_saved_pc+0x34>
728: 00001021 move v0,zero
72c: 8c830200 lw v1,512(a0)
730: 00021080 sll v0,v0,0x2
734: 00431021 addu v0,v0,v1
738: 8c420000 lw v0,0(v0)
73c: 03e00008 jr ra
740: 00000000 nop

The specific line that leads a different assembly being produced is:

unsigned long thread_saved_pc(struct task_struct *tsk)
...
return ((unsigned long *)t->reg29)[schedule_mfi.pc_offset]; <---

The problem here is that the compiler was given the right to use DSP
instructions with the -mdsp / -mdspr2 command-line switches and
performed some optimization for us and used DSP ASE instructions where
we are not checking that the running CPU actually supports DSP ASE.

This patch fixes the issue by partially reverting commit 32a7ede for
arch/mips/kernel/Makefile in order to remove the -mdsp / -mdspr2
compiler command-line switches such that we are now guaranteed that the
compiler will not optimize using DSP ASE reserved instructions. We also
need to fixup the rddsp/wrdsp and m{t,h}{hi,lo}{0,1,2,3} macros in
arch/mips/include/asm/mipsregs.h to tell the assembler that we are going
to explicitely use DSP ASE reserved instructions. The comment in
arch/mips/kernel/Makefile is also updated to reflect that.

Signed-off-by: Florian Fainelli <florian@openwrt.org>
Acked-by: Steven J. Hill <Steven.Hill@imgtec.com>
Cc: linux-mips@linux-mips.org
Cc: blogic@openwrt.org
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
/linux-master/arch/mips/kernel/
H A DMakefilediff 63c2b681 Mon Mar 18 09:56:10 MDT 2013 Florian Fainelli <florian@openwrt.org> MIPS: Fix code generation for non-DSP capable CPUs

Commit 32a7ede (MIPS: dsp: Add assembler support for DSP ASEs) has
enabled the use of DSP ASE specific instructions such as rddsp and wrdsp
under the idea that all code path that will make use of these two
instructions are properly checking for cpu_has_dsp to ensure that the
particular CPU we are running on *actually* supports DSP ASE.

This commit actually causes the following oops on QEMU Malta emulating a
MIPS 24Kc without the DSP ASE implemented:

[ 7.960000] Reserved instruction in kernel
[ 7.960000] Cpu 0
[ 7.960000] $ 0 : 00000000 00000000 00000014 00000005
[ 7.960000] $ 4 : 8fc2de48 00000001 00000000 8f59ddb0
[ 7.960000] $ 8 : 8f5ceec4 00000018 00000c00 00800000
[ 7.960000] $12 : 00000100 00000200 00000000 00457b84
[ 7.960000] $16 : 00000000 8fc2ba78 8f4ec980 00000001
[ 7.960000] $20 : 80418f90 00000000 00000000 000002dd
[ 7.960000] $24 : 0000009c 7730d7b8
[ 7.960000] $28 : 8f59c000 8f59dd38 00000001 80104248
[ 7.960000] Hi : 0000001d
[ 7.960000] Lo : 0000000b
[ 7.960000] epc : 801041ec thread_saved_pc+0x2c/0x38
[ 7.960000] Not tainted
[ 7.960000] ra : 80104248 get_wchan+0x48/0xac
[ 7.960000] Status: 1000b703 KERNEL EXL IE
[ 7.960000] Cause : 10800028
[ 7.960000] PrId : 00019300 (MIPS 24Kc)
[ 7.960000] Modules linked in:
[ 7.960000] Process killall (pid: 1574, threadinfo=8f59c000,
task=8fd14558, tls=773aa440)
[ 7.960000] Stack : 8fc2ba78 8012b008 0000000c 0000001d 00000000
00000000 8f58a380
8f58a380 8fc2ba78 80202668 8f59de78 8f468600 8f59de28
801b2a3c 8f59df00 8f98ba20 74696e69
8f468600 8f59de28 801b7308 0081c007 00000000 00000000
00000000 00000000 00000000 00000000
00000000 8fc2bbb4 00000001 0000001d 0000000b 77f038cc
7fe80648 ffffffff ffffffff 00000000
00000001 0016e000 00000000 ...
[ 7.960000] Call Trace:
[ 7.960000] [<801041ec>] thread_saved_pc+0x2c/0x38
[ 7.960000] [<80104248>] get_wchan+0x48/0xac

The disassembly of thread_saved_pc points to the following:
000006d0 <thread_saved_pc>:
6d0: 8c820208 lw v0,520(a0)
6d4: 3c030000 lui v1,0x0
6d8: 24630000 addiu v1,v1,0
6dc: 10430008 beq v0,v1,700 <thread_saved_pc+0x30>
6e0: 00000000 nop
6e4: 3c020000 lui v0,0x0
6e8: 8c43000c lw v1,12(v0)
6ec: 04620004 bltzl v1,700 <thread_saved_pc+0x30>
6f0: 00001021 move v0,zero
6f4: 8c840200 lw a0,512(a0)
6f8: 00031080 sll v0,v1,0x2
6fc: 7c44100a lwx v0,a0(v0) <------------
700: 03e00008 jr ra
704: 00000000 nop

If we specifically disable -mdsp/-mdspr2 for arch/mips/kernel/process.o,
we get the following (non-crashing) assembly:

00000708 <thread_saved_pc>:
708: 8c820208 lw v0,520(a0)
70c: 3c030000 lui v1,0x0
710: 24630000 addiu v1,v1,0
714: 10430009 beq v0,v1,73c <thread_saved_pc+0x34>
718: 00000000 nop
71c: 3c020000 lui v0,0x0
720: 8c42000c lw v0,12(v0)
724: 04420005 bltzl v0,73c <thread_saved_pc+0x34>
728: 00001021 move v0,zero
72c: 8c830200 lw v1,512(a0)
730: 00021080 sll v0,v0,0x2
734: 00431021 addu v0,v0,v1
738: 8c420000 lw v0,0(v0)
73c: 03e00008 jr ra
740: 00000000 nop

The specific line that leads a different assembly being produced is:

unsigned long thread_saved_pc(struct task_struct *tsk)
...
return ((unsigned long *)t->reg29)[schedule_mfi.pc_offset]; <---

The problem here is that the compiler was given the right to use DSP
instructions with the -mdsp / -mdspr2 command-line switches and
performed some optimization for us and used DSP ASE instructions where
we are not checking that the running CPU actually supports DSP ASE.

This patch fixes the issue by partially reverting commit 32a7ede for
arch/mips/kernel/Makefile in order to remove the -mdsp / -mdspr2
compiler command-line switches such that we are now guaranteed that the
compiler will not optimize using DSP ASE reserved instructions. We also
need to fixup the rddsp/wrdsp and m{t,h}{hi,lo}{0,1,2,3} macros in
arch/mips/include/asm/mipsregs.h to tell the assembler that we are going
to explicitely use DSP ASE reserved instructions. The comment in
arch/mips/kernel/Makefile is also updated to reflect that.

Signed-off-by: Florian Fainelli <florian@openwrt.org>
Acked-by: Steven J. Hill <Steven.Hill@imgtec.com>
Cc: linux-mips@linux-mips.org
Cc: blogic@openwrt.org
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
/linux-master/drivers/dax/
H A Dsuper.cdiff 8012b866 Thu Jun 02 23:37:25 MDT 2022 Shiyang Ruan <ruansy.fnst@fujitsu.com> dax: introduce holder for dax_device

Patch series "v14 fsdax-rmap + v11 fsdax-reflink", v2.

The patchset fsdax-rmap is aimed to support shared pages tracking for
fsdax.

It moves owner tracking from dax_assocaite_entry() to pmem device driver,
by introducing an interface ->memory_failure() for struct pagemap. This
interface is called by memory_failure() in mm, and implemented by pmem
device.

Then call holder operations to find the filesystem which the corrupted
data located in, and call filesystem handler to track files or metadata
associated with this page.

Finally we are able to try to fix the corrupted data in filesystem and do
other necessary processing, such as killing processes who are using the
files affected.

The call trace is like this:
memory_failure()
|* fsdax case
|------------
|pgmap->ops->memory_failure() => pmem_pgmap_memory_failure()
| dax_holder_notify_failure() =>
| dax_device->holder_ops->notify_failure() =>
| - xfs_dax_notify_failure()
| |* xfs_dax_notify_failure()
| |--------------------------
| | xfs_rmap_query_range()
| | xfs_dax_failure_fn()
| | * corrupted on metadata
| | try to recover data, call xfs_force_shutdown()
| | * corrupted on file data
| | try to recover data, call mf_dax_kill_procs()
|* normal case
|-------------
|mf_generic_kill_procs()


The patchset fsdax-reflink attempts to add CoW support for fsdax, and
takes XFS, which has both reflink and fsdax features, as an example.

One of the key mechanisms needed to be implemented in fsdax is CoW. Copy
the data from srcmap before we actually write data to the destination
iomap. And we just copy range in which data won't be changed.

Another mechanism is range comparison. In page cache case, readpage() is
used to load data on disk to page cache in order to be able to compare
data. In fsdax case, readpage() does not work. So, we need another
compare data with direct access support.

With the two mechanisms implemented in fsdax, we are able to make reflink
and fsdax work together in XFS.


This patch (of 14):

To easily track filesystem from a pmem device, we introduce a holder for
dax_device structure, and also its operation. This holder is used to
remember who is using this dax_device:

- When it is the backend of a filesystem, the holder will be the
instance of this filesystem.
- When this pmem device is one of the targets in a mapped device, the
holder will be this mapped device. In this case, the mapped device
has its own dax_device and it will follow the first rule. So that we
can finally track to the filesystem we needed.

The holder and holder_ops will be set when filesystem is being mounted,
or an target device is being activated.

Link: https://lkml.kernel.org/r/20220603053738.1218681-1-ruansy.fnst@fujitsu.com
Link: https://lkml.kernel.org/r/20220603053738.1218681-2-ruansy.fnst@fujitsu.com
Signed-off-by: Shiyang Ruan <ruansy.fnst@fujitsu.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Dan Williams <dan.j.wiliams@intel.com>
Reviewed-by: Darrick J. Wong <djwong@kernel.org>
Cc: Dave Chinner <david@fromorbit.com>
Cc: Jane Chu <jane.chu@oracle.com>
Cc: Goldwyn Rodrigues <rgoldwyn@suse.de>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Cc: Matthew Wilcox <willy@infradead.org>
Cc: Naoya Horiguchi <naoya.horiguchi@nec.com>
Cc: Miaohe Lin <linmiaohe@huawei.com>
Cc: Dan Williams <dan.j.williams@intel.com>
Cc: Goldwyn Rodrigues <rgoldwyn@suse.com>
Cc: Ritesh Harjani <riteshh@linux.ibm.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
/linux-master/drivers/scsi/lpfc/
H A Dlpfc_sli.hdiff 8012cc38 Wed Oct 31 12:44:49 MDT 2012 James Smart <james.smart@emulex.com> [SCSI] lpfc 8.3.36: Update DIF support for passthru/strip/insert

Signed-off-by: James Smart <james.smart@emulex.com>
Signed-off-by: James Bottomley <JBottomley@Parallels.com>
H A Dlpfc_hw4.hdiff 8012cc38 Wed Oct 31 12:44:49 MDT 2012 James Smart <james.smart@emulex.com> [SCSI] lpfc 8.3.36: Update DIF support for passthru/strip/insert

Signed-off-by: James Smart <james.smart@emulex.com>
Signed-off-by: James Bottomley <JBottomley@Parallels.com>
H A Dlpfc_scsi.cdiff 8012cc38 Wed Oct 31 12:44:49 MDT 2012 James Smart <james.smart@emulex.com> [SCSI] lpfc 8.3.36: Update DIF support for passthru/strip/insert

Signed-off-by: James Smart <james.smart@emulex.com>
Signed-off-by: James Bottomley <JBottomley@Parallels.com>
H A Dlpfc_sli.cdiff 8012cc38 Wed Oct 31 12:44:49 MDT 2012 James Smart <james.smart@emulex.com> [SCSI] lpfc 8.3.36: Update DIF support for passthru/strip/insert

Signed-off-by: James Smart <james.smart@emulex.com>
Signed-off-by: James Bottomley <JBottomley@Parallels.com>
/linux-master/include/linux/
H A Ddax.hdiff 8012b866 Thu Jun 02 23:37:25 MDT 2022 Shiyang Ruan <ruansy.fnst@fujitsu.com> dax: introduce holder for dax_device

Patch series "v14 fsdax-rmap + v11 fsdax-reflink", v2.

The patchset fsdax-rmap is aimed to support shared pages tracking for
fsdax.

It moves owner tracking from dax_assocaite_entry() to pmem device driver,
by introducing an interface ->memory_failure() for struct pagemap. This
interface is called by memory_failure() in mm, and implemented by pmem
device.

Then call holder operations to find the filesystem which the corrupted
data located in, and call filesystem handler to track files or metadata
associated with this page.

Finally we are able to try to fix the corrupted data in filesystem and do
other necessary processing, such as killing processes who are using the
files affected.

The call trace is like this:
memory_failure()
|* fsdax case
|------------
|pgmap->ops->memory_failure() => pmem_pgmap_memory_failure()
| dax_holder_notify_failure() =>
| dax_device->holder_ops->notify_failure() =>
| - xfs_dax_notify_failure()
| |* xfs_dax_notify_failure()
| |--------------------------
| | xfs_rmap_query_range()
| | xfs_dax_failure_fn()
| | * corrupted on metadata
| | try to recover data, call xfs_force_shutdown()
| | * corrupted on file data
| | try to recover data, call mf_dax_kill_procs()
|* normal case
|-------------
|mf_generic_kill_procs()


The patchset fsdax-reflink attempts to add CoW support for fsdax, and
takes XFS, which has both reflink and fsdax features, as an example.

One of the key mechanisms needed to be implemented in fsdax is CoW. Copy
the data from srcmap before we actually write data to the destination
iomap. And we just copy range in which data won't be changed.

Another mechanism is range comparison. In page cache case, readpage() is
used to load data on disk to page cache in order to be able to compare
data. In fsdax case, readpage() does not work. So, we need another
compare data with direct access support.

With the two mechanisms implemented in fsdax, we are able to make reflink
and fsdax work together in XFS.


This patch (of 14):

To easily track filesystem from a pmem device, we introduce a holder for
dax_device structure, and also its operation. This holder is used to
remember who is using this dax_device:

- When it is the backend of a filesystem, the holder will be the
instance of this filesystem.
- When this pmem device is one of the targets in a mapped device, the
holder will be this mapped device. In this case, the mapped device
has its own dax_device and it will follow the first rule. So that we
can finally track to the filesystem we needed.

The holder and holder_ops will be set when filesystem is being mounted,
or an target device is being activated.

Link: https://lkml.kernel.org/r/20220603053738.1218681-1-ruansy.fnst@fujitsu.com
Link: https://lkml.kernel.org/r/20220603053738.1218681-2-ruansy.fnst@fujitsu.com
Signed-off-by: Shiyang Ruan <ruansy.fnst@fujitsu.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Dan Williams <dan.j.wiliams@intel.com>
Reviewed-by: Darrick J. Wong <djwong@kernel.org>
Cc: Dave Chinner <david@fromorbit.com>
Cc: Jane Chu <jane.chu@oracle.com>
Cc: Goldwyn Rodrigues <rgoldwyn@suse.de>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Cc: Matthew Wilcox <willy@infradead.org>
Cc: Naoya Horiguchi <naoya.horiguchi@nec.com>
Cc: Miaohe Lin <linmiaohe@huawei.com>
Cc: Dan Williams <dan.j.williams@intel.com>
Cc: Goldwyn Rodrigues <rgoldwyn@suse.com>
Cc: Ritesh Harjani <riteshh@linux.ibm.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
/linux-master/fs/erofs/
H A Dsuper.cdiff 8012b866 Thu Jun 02 23:37:25 MDT 2022 Shiyang Ruan <ruansy.fnst@fujitsu.com> dax: introduce holder for dax_device

Patch series "v14 fsdax-rmap + v11 fsdax-reflink", v2.

The patchset fsdax-rmap is aimed to support shared pages tracking for
fsdax.

It moves owner tracking from dax_assocaite_entry() to pmem device driver,
by introducing an interface ->memory_failure() for struct pagemap. This
interface is called by memory_failure() in mm, and implemented by pmem
device.

Then call holder operations to find the filesystem which the corrupted
data located in, and call filesystem handler to track files or metadata
associated with this page.

Finally we are able to try to fix the corrupted data in filesystem and do
other necessary processing, such as killing processes who are using the
files affected.

The call trace is like this:
memory_failure()
|* fsdax case
|------------
|pgmap->ops->memory_failure() => pmem_pgmap_memory_failure()
| dax_holder_notify_failure() =>
| dax_device->holder_ops->notify_failure() =>
| - xfs_dax_notify_failure()
| |* xfs_dax_notify_failure()
| |--------------------------
| | xfs_rmap_query_range()
| | xfs_dax_failure_fn()
| | * corrupted on metadata
| | try to recover data, call xfs_force_shutdown()
| | * corrupted on file data
| | try to recover data, call mf_dax_kill_procs()
|* normal case
|-------------
|mf_generic_kill_procs()


The patchset fsdax-reflink attempts to add CoW support for fsdax, and
takes XFS, which has both reflink and fsdax features, as an example.

One of the key mechanisms needed to be implemented in fsdax is CoW. Copy
the data from srcmap before we actually write data to the destination
iomap. And we just copy range in which data won't be changed.

Another mechanism is range comparison. In page cache case, readpage() is
used to load data on disk to page cache in order to be able to compare
data. In fsdax case, readpage() does not work. So, we need another
compare data with direct access support.

With the two mechanisms implemented in fsdax, we are able to make reflink
and fsdax work together in XFS.


This patch (of 14):

To easily track filesystem from a pmem device, we introduce a holder for
dax_device structure, and also its operation. This holder is used to
remember who is using this dax_device:

- When it is the backend of a filesystem, the holder will be the
instance of this filesystem.
- When this pmem device is one of the targets in a mapped device, the
holder will be this mapped device. In this case, the mapped device
has its own dax_device and it will follow the first rule. So that we
can finally track to the filesystem we needed.

The holder and holder_ops will be set when filesystem is being mounted,
or an target device is being activated.

Link: https://lkml.kernel.org/r/20220603053738.1218681-1-ruansy.fnst@fujitsu.com
Link: https://lkml.kernel.org/r/20220603053738.1218681-2-ruansy.fnst@fujitsu.com
Signed-off-by: Shiyang Ruan <ruansy.fnst@fujitsu.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Dan Williams <dan.j.wiliams@intel.com>
Reviewed-by: Darrick J. Wong <djwong@kernel.org>
Cc: Dave Chinner <david@fromorbit.com>
Cc: Jane Chu <jane.chu@oracle.com>
Cc: Goldwyn Rodrigues <rgoldwyn@suse.de>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Cc: Matthew Wilcox <willy@infradead.org>
Cc: Naoya Horiguchi <naoya.horiguchi@nec.com>
Cc: Miaohe Lin <linmiaohe@huawei.com>
Cc: Dan Williams <dan.j.williams@intel.com>
Cc: Goldwyn Rodrigues <rgoldwyn@suse.com>
Cc: Ritesh Harjani <riteshh@linux.ibm.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
/linux-master/fs/ext2/
H A Dsuper.cdiff 8012b866 Thu Jun 02 23:37:25 MDT 2022 Shiyang Ruan <ruansy.fnst@fujitsu.com> dax: introduce holder for dax_device

Patch series "v14 fsdax-rmap + v11 fsdax-reflink", v2.

The patchset fsdax-rmap is aimed to support shared pages tracking for
fsdax.

It moves owner tracking from dax_assocaite_entry() to pmem device driver,
by introducing an interface ->memory_failure() for struct pagemap. This
interface is called by memory_failure() in mm, and implemented by pmem
device.

Then call holder operations to find the filesystem which the corrupted
data located in, and call filesystem handler to track files or metadata
associated with this page.

Finally we are able to try to fix the corrupted data in filesystem and do
other necessary processing, such as killing processes who are using the
files affected.

The call trace is like this:
memory_failure()
|* fsdax case
|------------
|pgmap->ops->memory_failure() => pmem_pgmap_memory_failure()
| dax_holder_notify_failure() =>
| dax_device->holder_ops->notify_failure() =>
| - xfs_dax_notify_failure()
| |* xfs_dax_notify_failure()
| |--------------------------
| | xfs_rmap_query_range()
| | xfs_dax_failure_fn()
| | * corrupted on metadata
| | try to recover data, call xfs_force_shutdown()
| | * corrupted on file data
| | try to recover data, call mf_dax_kill_procs()
|* normal case
|-------------
|mf_generic_kill_procs()


The patchset fsdax-reflink attempts to add CoW support for fsdax, and
takes XFS, which has both reflink and fsdax features, as an example.

One of the key mechanisms needed to be implemented in fsdax is CoW. Copy
the data from srcmap before we actually write data to the destination
iomap. And we just copy range in which data won't be changed.

Another mechanism is range comparison. In page cache case, readpage() is
used to load data on disk to page cache in order to be able to compare
data. In fsdax case, readpage() does not work. So, we need another
compare data with direct access support.

With the two mechanisms implemented in fsdax, we are able to make reflink
and fsdax work together in XFS.


This patch (of 14):

To easily track filesystem from a pmem device, we introduce a holder for
dax_device structure, and also its operation. This holder is used to
remember who is using this dax_device:

- When it is the backend of a filesystem, the holder will be the
instance of this filesystem.
- When this pmem device is one of the targets in a mapped device, the
holder will be this mapped device. In this case, the mapped device
has its own dax_device and it will follow the first rule. So that we
can finally track to the filesystem we needed.

The holder and holder_ops will be set when filesystem is being mounted,
or an target device is being activated.

Link: https://lkml.kernel.org/r/20220603053738.1218681-1-ruansy.fnst@fujitsu.com
Link: https://lkml.kernel.org/r/20220603053738.1218681-2-ruansy.fnst@fujitsu.com
Signed-off-by: Shiyang Ruan <ruansy.fnst@fujitsu.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Dan Williams <dan.j.wiliams@intel.com>
Reviewed-by: Darrick J. Wong <djwong@kernel.org>
Cc: Dave Chinner <david@fromorbit.com>
Cc: Jane Chu <jane.chu@oracle.com>
Cc: Goldwyn Rodrigues <rgoldwyn@suse.de>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Cc: Matthew Wilcox <willy@infradead.org>
Cc: Naoya Horiguchi <naoya.horiguchi@nec.com>
Cc: Miaohe Lin <linmiaohe@huawei.com>
Cc: Dan Williams <dan.j.williams@intel.com>
Cc: Goldwyn Rodrigues <rgoldwyn@suse.com>
Cc: Ritesh Harjani <riteshh@linux.ibm.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
/linux-master/drivers/scsi/
H A Dst.cdiff e7ac6c66 Wed Jul 01 18:01:10 MDT 2015 Seymour, Shane M <shane.seymour@hp.com> st: null pointer dereference panic caused by use after kref_put by st_open

Two SLES11 SP3 servers encountered similar crashes simultaneously
following some kind of SAN/tape target issue:

...
qla2xxx [0000:81:00.0]-801c:3: Abort command issued nexus=3:0:2 -- 1 2002.
qla2xxx [0000:81:00.0]-801c:3: Abort command issued nexus=3:0:2 -- 1 2002.
qla2xxx [0000:81:00.0]-8009:3: DEVICE RESET ISSUED nexus=3:0:2 cmd=ffff882f89c2c7c0.
qla2xxx [0000:81:00.0]-800c:3: do_reset failed for cmd=ffff882f89c2c7c0.
qla2xxx [0000:81:00.0]-800f:3: DEVICE RESET FAILED: Task management failed nexus=3:0:2 cmd=ffff882f89c2c7c0.
qla2xxx [0000:81:00.0]-8009:3: TARGET RESET ISSUED nexus=3:0:2 cmd=ffff882f89c2c7c0.
qla2xxx [0000:81:00.0]-800c:3: do_reset failed for cmd=ffff882f89c2c7c0.
qla2xxx [0000:81:00.0]-800f:3: TARGET RESET FAILED: Task management failed nexus=3:0:2 cmd=ffff882f89c2c7c0.
qla2xxx [0000:81:00.0]-8012:3: BUS RESET ISSUED nexus=3:0:2.
qla2xxx [0000:81:00.0]-802b:3: BUS RESET SUCCEEDED nexus=3:0:2.
qla2xxx [0000:81:00.0]-505f:3: Link is operational (8 Gbps).
qla2xxx [0000:81:00.0]-8018:3: ADAPTER RESET ISSUED nexus=3:0:2.
qla2xxx [0000:81:00.0]-00af:3: Performing ISP error recovery - ha=ffff88bf04d18000.
rport-3:0-0: blocked FC remote port time out: removing target and saving binding
qla2xxx [0000:81:00.0]-505f:3: Link is operational (8 Gbps).
qla2xxx [0000:81:00.0]-8017:3: ADAPTER RESET SUCCEEDED nexus=3:0:2.
rport-2:0-0: blocked FC remote port time out: removing target and saving binding
sg_rq_end_io: device detached
BUG: unable to handle kernel NULL pointer dereference at 00000000000002a8
IP: [<ffffffff8133b268>] __pm_runtime_idle+0x28/0x90
PGD 7e6586f067 PUD 7e5af06067 PMD 0 [1739975.390354] Oops: 0002 [#1] SMP
CPU 0
...
Supported: No, Proprietary modules are loaded [1739975.390463]
Pid: 27965, comm: ABCD Tainted: PF X 3.0.101-0.29-default #1 HP ProLiant DL580 Gen8
RIP: 0010:[<ffffffff8133b268>] [<ffffffff8133b268>] __pm_runtime_idle+0x28/0x90
RSP: 0018:ffff8839dc1e7c68 EFLAGS: 00010202
RAX: 0000000000000000 RBX: ffff883f0592fc00 RCX: 0000000000000090
RDX: 0000000000000000 RSI: 0000000000000004 RDI: 0000000000000138
RBP: 0000000000000138 R08: 0000000000000010 R09: ffffffff81bd39d0
R10: 00000000000009c0 R11: ffffffff81025790 R12: 0000000000000001
R13: ffff883022212b80 R14: 0000000000000004 R15: ffff883022212b80
FS: 00007f8e54560720(0000) GS:ffff88407f800000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: 00000000000002a8 CR3: 0000007e6ced6000 CR4: 00000000001407f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process ABCD (pid: 27965, threadinfo ffff8839dc1e6000, task ffff883592e0c640)
Stack:
ffff883f0592fc00 00000000fffffffa 0000000000000001 ffff883022212b80
ffff883eff772400 ffffffffa03fa309 0000000000000000 0000000000000000
ffffffffa04003a0 ffff883f063196c0 ffff887f0379a930 ffffffff8115ea1e
Call Trace:
[<ffffffffa03fa309>] st_open+0x129/0x240 [st]
[<ffffffff8115ea1e>] chrdev_open+0x13e/0x200
[<ffffffff811588a8>] __dentry_open+0x198/0x310
[<ffffffff81167d74>] do_last+0x1f4/0x800
[<ffffffff81168fe9>] path_openat+0xd9/0x420
[<ffffffff8116946c>] do_filp_open+0x4c/0xc0
[<ffffffff8115a00f>] do_sys_open+0x17f/0x250
[<ffffffff81468d92>] system_call_fastpath+0x16/0x1b
[<00007f8e4f617fd0>] 0x7f8e4f617fcf
Code: eb d3 90 48 83 ec 28 40 f6 c6 04 48 89 6c 24 08 4c 89 74 24 20 48 89 fd 48 89 1c 24 4c 89 64 24 10 41 89 f6 4c 89 6c 24 18 74 11 <f0> ff 8f 70 01 00 00 0f 94 c0 45 31 ed 84 c0 74 2b 4c 8d a5 a0
RIP [<ffffffff8133b268>] __pm_runtime_idle+0x28/0x90
RSP <ffff8839dc1e7c68>
CR2: 00000000000002a8

Analysis reveals the cause of the crash to be due to STp->device
being NULL. The pointer was NULLed via scsi_tape_put(STp) when it
calls scsi_tape_release(). In st_open() we jump to err_out after
scsi_block_when_processing_errors() completes and returns the
device as offline (sdev_state was SDEV_DEL):

1180 /* Open the device. Needs to take the BKL only because of incrementing the SCSI host
1181 module count. */
1182 static int st_open(struct inode *inode, struct file *filp)
1183 {
1184 int i, retval = (-EIO);
1185 int resumed = 0;
1186 struct scsi_tape *STp;
1187 struct st_partstat *STps;
1188 int dev = TAPE_NR(inode);
1189 char *name;
...
1217 if (scsi_autopm_get_device(STp->device) < 0) {
1218 retval = -EIO;
1219 goto err_out;
1220 }
1221 resumed = 1;
1222 if (!scsi_block_when_processing_errors(STp->device)) {
1223 retval = (-ENXIO);
1224 goto err_out;
1225 }
...
1264 err_out:
1265 normalize_buffer(STp->buffer);
1266 spin_lock(&st_use_lock);
1267 STp->in_use = 0;
1268 spin_unlock(&st_use_lock);
1269 scsi_tape_put(STp); <-- STp->device = 0 after this
1270 if (resumed)
1271 scsi_autopm_put_device(STp->device);
1272 return retval;

The ref count for the struct scsi_tape had already been reduced
to 1 when the .remove method of the st module had been called.
The kref_put() in scsi_tape_put() caused scsi_tape_release()
to be called:

0266 static void scsi_tape_put(struct scsi_tape *STp)
0267 {
0268 struct scsi_device *sdev = STp->device;
0269
0270 mutex_lock(&st_ref_mutex);
0271 kref_put(&STp->kref, scsi_tape_release); <-- calls this
0272 scsi_device_put(sdev);
0273 mutex_unlock(&st_ref_mutex);
0274 }

In scsi_tape_release() the struct scsi_device in the struct
scsi_tape gets set to NULL:

4273 static void scsi_tape_release(struct kref *kref)
4274 {
4275 struct scsi_tape *tpnt = to_scsi_tape(kref);
4276 struct gendisk *disk = tpnt->disk;
4277
4278 tpnt->device = NULL; <<<---- where the dev is nulled
4279
4280 if (tpnt->buffer) {
4281 normalize_buffer(tpnt->buffer);
4282 kfree(tpnt->buffer->reserved_pages);
4283 kfree(tpnt->buffer);
4284 }
4285
4286 disk->private_data = NULL;
4287 put_disk(disk);
4288 kfree(tpnt);
4289 return;
4290 }

Although the problem was reported on SLES11.3 the problem appears
in linux-next as well.

The crash is fixed by reordering the code so we no longer access
the struct scsi_tape after the kref_put() is done on it in st_open().

Signed-off-by: Shane Seymour <shane.seymour@hp.com>
Signed-off-by: Darren Lavender <darren.lavender@hp.com>
Reviewed-by: Johannes Thumshirn <jthumshirn@suse.com>
Acked-by: Kai Mäkisara <kai.makisara@kolumbus.fi>
Cc: stable@vger.kernel.org
Signed-off-by: James Bottomley <JBottomley@Odin.com>
/linux-master/fs/xfs/
H A Dxfs_buf.cdiff 8012b866 Thu Jun 02 23:37:25 MDT 2022 Shiyang Ruan <ruansy.fnst@fujitsu.com> dax: introduce holder for dax_device

Patch series "v14 fsdax-rmap + v11 fsdax-reflink", v2.

The patchset fsdax-rmap is aimed to support shared pages tracking for
fsdax.

It moves owner tracking from dax_assocaite_entry() to pmem device driver,
by introducing an interface ->memory_failure() for struct pagemap. This
interface is called by memory_failure() in mm, and implemented by pmem
device.

Then call holder operations to find the filesystem which the corrupted
data located in, and call filesystem handler to track files or metadata
associated with this page.

Finally we are able to try to fix the corrupted data in filesystem and do
other necessary processing, such as killing processes who are using the
files affected.

The call trace is like this:
memory_failure()
|* fsdax case
|------------
|pgmap->ops->memory_failure() => pmem_pgmap_memory_failure()
| dax_holder_notify_failure() =>
| dax_device->holder_ops->notify_failure() =>
| - xfs_dax_notify_failure()
| |* xfs_dax_notify_failure()
| |--------------------------
| | xfs_rmap_query_range()
| | xfs_dax_failure_fn()
| | * corrupted on metadata
| | try to recover data, call xfs_force_shutdown()
| | * corrupted on file data
| | try to recover data, call mf_dax_kill_procs()
|* normal case
|-------------
|mf_generic_kill_procs()


The patchset fsdax-reflink attempts to add CoW support for fsdax, and
takes XFS, which has both reflink and fsdax features, as an example.

One of the key mechanisms needed to be implemented in fsdax is CoW. Copy
the data from srcmap before we actually write data to the destination
iomap. And we just copy range in which data won't be changed.

Another mechanism is range comparison. In page cache case, readpage() is
used to load data on disk to page cache in order to be able to compare
data. In fsdax case, readpage() does not work. So, we need another
compare data with direct access support.

With the two mechanisms implemented in fsdax, we are able to make reflink
and fsdax work together in XFS.


This patch (of 14):

To easily track filesystem from a pmem device, we introduce a holder for
dax_device structure, and also its operation. This holder is used to
remember who is using this dax_device:

- When it is the backend of a filesystem, the holder will be the
instance of this filesystem.
- When this pmem device is one of the targets in a mapped device, the
holder will be this mapped device. In this case, the mapped device
has its own dax_device and it will follow the first rule. So that we
can finally track to the filesystem we needed.

The holder and holder_ops will be set when filesystem is being mounted,
or an target device is being activated.

Link: https://lkml.kernel.org/r/20220603053738.1218681-1-ruansy.fnst@fujitsu.com
Link: https://lkml.kernel.org/r/20220603053738.1218681-2-ruansy.fnst@fujitsu.com
Signed-off-by: Shiyang Ruan <ruansy.fnst@fujitsu.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Dan Williams <dan.j.wiliams@intel.com>
Reviewed-by: Darrick J. Wong <djwong@kernel.org>
Cc: Dave Chinner <david@fromorbit.com>
Cc: Jane Chu <jane.chu@oracle.com>
Cc: Goldwyn Rodrigues <rgoldwyn@suse.de>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Cc: Matthew Wilcox <willy@infradead.org>
Cc: Naoya Horiguchi <naoya.horiguchi@nec.com>
Cc: Miaohe Lin <linmiaohe@huawei.com>
Cc: Dan Williams <dan.j.williams@intel.com>
Cc: Goldwyn Rodrigues <rgoldwyn@suse.com>
Cc: Ritesh Harjani <riteshh@linux.ibm.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
/linux-master/drivers/scsi/qla2xxx/
H A Dqla_os.cdiff 0b7e7c53 Thu Feb 07 23:57:42 MST 2013 Andrew Vasquez <andrew.vasquez@qlogic.com> [SCSI] qla2xxx: Correct race in loop_state assignment during reset handling.

There's a subtle race in the loop/bus-reset handling whereby a
VHA's loop-state can get incorrectly set to 'down' after the
loop-reset and firmware's completion of link re-negotiation. The
original code incorrectly assumes that firmware AENs would arrive
only after mailbox-command execution to initiate the link-flap.

Here's a good case with the old code (AENs arrive after
mailbox-command completion):

qla2xxx [0000:03:00.1]-8012:91: BUS RESET ISSUED nexus=91:0:4.
qla2xxx [0000:03:00.1]-287d:91: FCPort state transitioned from ONLINE to LOST - portid=010100.
qla2xxx [0000:03:00.1]-580e:91: Asynchronous P2P MODE received.
qla2xxx [0000:03:00.1]-287d:91: FCPort state transitioned from ONLINE to LOST - portid=010400.
qla2xxx [0000:03:00.1]-802b:91: BUS RESET SUCCEEDED nexus=91:0:4.
qla2xxx [0000:03:00.1]-480b:91: Reset marker scheduled.
qla2xxx [0000:03:00.1]-5812:91: Port database changed ffff 0006 0000.
qla2xxx [0000:03:00.1]-505f:91: Link is operational (4 Gbps).
qla2xxx [0000:03:00.1]-480c:91: Reset marker end.
qla2xxx [0000:03:00.1]-480f:91: Loop resync scheduled.
qla2xxx [0000:03:00.1]-8837:91: F/W Ready - OK.
qla2xxx [0000:03:00.1]-883a:91: fw_state=3 (7, 0, 0, 0) curr time=170b8f315.
qla2xxx [0000:03:00.1]-280e:91: HBA in F P2P topology.
qla2xxx [0000:03:00.1]-2812:91: qla2x00_configure_hba success
qla2xxx [0000:03:00.1]-2814:91: Configure loop -- dpc flags = 0x5260.

notice how the 'Port database changed' (8014) arrived after the
bus-reset handler completed 'BUS RESET SUCCEEDED'.

Now, here's a failing case with the old code (AENs arrive before
mailbox-command completion):

qla2xxx [0000:03:00.1]-8012:91: BUS RESET ISSUED nexus=91:0:0.
qla2xxx [0000:03:00.1]-580e:91: Asynchronous P2P MODE received.
qla2xxx [0000:03:00.1]-287d:91: FCPort state transitioned from ONLINE to LOST - portid=010100.
qla2xxx [0000:03:00.1]-287d:91: FCPort state transitioned from ONLINE to LOST - portid=010400.
qla2xxx [0000:03:00.1]-4800:91: DPC handler sleeping.
qla2xxx [0000:03:00.1]-5812:91: Port database changed ffff 0006 0000.
qla2xxx [0000:03:00.1]-505f:91: Link is operational (4 Gbps).
qla2xxx [0000:03:00.1]-802b:91: BUS RESET SUCCEEDED nexus=91:0:0.
qla2xxx [0000:03:00.1]-480b:91: Reset marker scheduled.
qla2xxx [0000:03:00.1]-480c:91: Reset marker end.
qla2xxx [0000:03:00.1]-480f:91: Loop resync scheduled.
qla2xxx [0000:03:00.1]-8837:91: F/W Ready - OK.
qla2xxx [0000:03:00.1]-883a:91: fw_state=3 (7, 0, 0, 0) curr time=170be9eb2.
qla2xxx [0000:03:00.1]-280e:91: HBA in F P2P topology.
qla2xxx [0000:03:00.1]-2812:91: qla2x00_configure_hba success
qla2xxx [0000:03:00.1]-2814:91: Configure loop -- dpc flags = 0x5260.
qla2xxx [0000:03:00.1]-281e:91: Needs RSCN update and loop transition.
qla2xxx [0000:03:00.1]-286a:91: qla2x00_configure_loop *** FAILED ***.
qla2xxx [0000:03:00.1]-4810:91: Loop resync end.
qla2xxx [0000:03:00.1]-4800:91: DPC handler sleeping.

This race would ultimately lead to devices go unexpectedly
offline until another link-flap or chip-reset would cause driver
re-discovery to take place.

Signed-off-by: Andrew Vasquez <andrew.vasquez@qlogic.com>
Signed-off-by: Saurav Kashyap <saurav.kashyap@qlogic.com>
Signed-off-by: James Bottomley <JBottomley@Parallels.com>
diff 0b7e7c53 Thu Feb 07 23:57:42 MST 2013 Andrew Vasquez <andrew.vasquez@qlogic.com> [SCSI] qla2xxx: Correct race in loop_state assignment during reset handling.

There's a subtle race in the loop/bus-reset handling whereby a
VHA's loop-state can get incorrectly set to 'down' after the
loop-reset and firmware's completion of link re-negotiation. The
original code incorrectly assumes that firmware AENs would arrive
only after mailbox-command execution to initiate the link-flap.

Here's a good case with the old code (AENs arrive after
mailbox-command completion):

qla2xxx [0000:03:00.1]-8012:91: BUS RESET ISSUED nexus=91:0:4.
qla2xxx [0000:03:00.1]-287d:91: FCPort state transitioned from ONLINE to LOST - portid=010100.
qla2xxx [0000:03:00.1]-580e:91: Asynchronous P2P MODE received.
qla2xxx [0000:03:00.1]-287d:91: FCPort state transitioned from ONLINE to LOST - portid=010400.
qla2xxx [0000:03:00.1]-802b:91: BUS RESET SUCCEEDED nexus=91:0:4.
qla2xxx [0000:03:00.1]-480b:91: Reset marker scheduled.
qla2xxx [0000:03:00.1]-5812:91: Port database changed ffff 0006 0000.
qla2xxx [0000:03:00.1]-505f:91: Link is operational (4 Gbps).
qla2xxx [0000:03:00.1]-480c:91: Reset marker end.
qla2xxx [0000:03:00.1]-480f:91: Loop resync scheduled.
qla2xxx [0000:03:00.1]-8837:91: F/W Ready - OK.
qla2xxx [0000:03:00.1]-883a:91: fw_state=3 (7, 0, 0, 0) curr time=170b8f315.
qla2xxx [0000:03:00.1]-280e:91: HBA in F P2P topology.
qla2xxx [0000:03:00.1]-2812:91: qla2x00_configure_hba success
qla2xxx [0000:03:00.1]-2814:91: Configure loop -- dpc flags = 0x5260.

notice how the 'Port database changed' (8014) arrived after the
bus-reset handler completed 'BUS RESET SUCCEEDED'.

Now, here's a failing case with the old code (AENs arrive before
mailbox-command completion):

qla2xxx [0000:03:00.1]-8012:91: BUS RESET ISSUED nexus=91:0:0.
qla2xxx [0000:03:00.1]-580e:91: Asynchronous P2P MODE received.
qla2xxx [0000:03:00.1]-287d:91: FCPort state transitioned from ONLINE to LOST - portid=010100.
qla2xxx [0000:03:00.1]-287d:91: FCPort state transitioned from ONLINE to LOST - portid=010400.
qla2xxx [0000:03:00.1]-4800:91: DPC handler sleeping.
qla2xxx [0000:03:00.1]-5812:91: Port database changed ffff 0006 0000.
qla2xxx [0000:03:00.1]-505f:91: Link is operational (4 Gbps).
qla2xxx [0000:03:00.1]-802b:91: BUS RESET SUCCEEDED nexus=91:0:0.
qla2xxx [0000:03:00.1]-480b:91: Reset marker scheduled.
qla2xxx [0000:03:00.1]-480c:91: Reset marker end.
qla2xxx [0000:03:00.1]-480f:91: Loop resync scheduled.
qla2xxx [0000:03:00.1]-8837:91: F/W Ready - OK.
qla2xxx [0000:03:00.1]-883a:91: fw_state=3 (7, 0, 0, 0) curr time=170be9eb2.
qla2xxx [0000:03:00.1]-280e:91: HBA in F P2P topology.
qla2xxx [0000:03:00.1]-2812:91: qla2x00_configure_hba success
qla2xxx [0000:03:00.1]-2814:91: Configure loop -- dpc flags = 0x5260.
qla2xxx [0000:03:00.1]-281e:91: Needs RSCN update and loop transition.
qla2xxx [0000:03:00.1]-286a:91: qla2x00_configure_loop *** FAILED ***.
qla2xxx [0000:03:00.1]-4810:91: Loop resync end.
qla2xxx [0000:03:00.1]-4800:91: DPC handler sleeping.

This race would ultimately lead to devices go unexpectedly
offline until another link-flap or chip-reset would cause driver
re-discovery to take place.

Signed-off-by: Andrew Vasquez <andrew.vasquez@qlogic.com>
Signed-off-by: Saurav Kashyap <saurav.kashyap@qlogic.com>
Signed-off-by: James Bottomley <JBottomley@Parallels.com>
H A Dqla_isr.cdiff bc5c2aad Tue Dec 21 17:00:24 MST 2010 Andrew Vasquez <andrew.vasquez@qlogic.com> [SCSI] qla2xxx: Display mailbox register 4 during 8012 AEN for ISP82XX parts.

Signed-off-by: Andrew Vasquez <andrew.vasquez@qlogic.com>
Signed-off-by: Madhuranath Iyengar <Madhu.Iyengar@qlogic.com>
Signed-off-by: James Bottomley <James.Bottomley@suse.de>
/linux-master/drivers/md/
H A Ddm.cdiff 8012b866 Thu Jun 02 23:37:25 MDT 2022 Shiyang Ruan <ruansy.fnst@fujitsu.com> dax: introduce holder for dax_device

Patch series "v14 fsdax-rmap + v11 fsdax-reflink", v2.

The patchset fsdax-rmap is aimed to support shared pages tracking for
fsdax.

It moves owner tracking from dax_assocaite_entry() to pmem device driver,
by introducing an interface ->memory_failure() for struct pagemap. This
interface is called by memory_failure() in mm, and implemented by pmem
device.

Then call holder operations to find the filesystem which the corrupted
data located in, and call filesystem handler to track files or metadata
associated with this page.

Finally we are able to try to fix the corrupted data in filesystem and do
other necessary processing, such as killing processes who are using the
files affected.

The call trace is like this:
memory_failure()
|* fsdax case
|------------
|pgmap->ops->memory_failure() => pmem_pgmap_memory_failure()
| dax_holder_notify_failure() =>
| dax_device->holder_ops->notify_failure() =>
| - xfs_dax_notify_failure()
| |* xfs_dax_notify_failure()
| |--------------------------
| | xfs_rmap_query_range()
| | xfs_dax_failure_fn()
| | * corrupted on metadata
| | try to recover data, call xfs_force_shutdown()
| | * corrupted on file data
| | try to recover data, call mf_dax_kill_procs()
|* normal case
|-------------
|mf_generic_kill_procs()


The patchset fsdax-reflink attempts to add CoW support for fsdax, and
takes XFS, which has both reflink and fsdax features, as an example.

One of the key mechanisms needed to be implemented in fsdax is CoW. Copy
the data from srcmap before we actually write data to the destination
iomap. And we just copy range in which data won't be changed.

Another mechanism is range comparison. In page cache case, readpage() is
used to load data on disk to page cache in order to be able to compare
data. In fsdax case, readpage() does not work. So, we need another
compare data with direct access support.

With the two mechanisms implemented in fsdax, we are able to make reflink
and fsdax work together in XFS.


This patch (of 14):

To easily track filesystem from a pmem device, we introduce a holder for
dax_device structure, and also its operation. This holder is used to
remember who is using this dax_device:

- When it is the backend of a filesystem, the holder will be the
instance of this filesystem.
- When this pmem device is one of the targets in a mapped device, the
holder will be this mapped device. In this case, the mapped device
has its own dax_device and it will follow the first rule. So that we
can finally track to the filesystem we needed.

The holder and holder_ops will be set when filesystem is being mounted,
or an target device is being activated.

Link: https://lkml.kernel.org/r/20220603053738.1218681-1-ruansy.fnst@fujitsu.com
Link: https://lkml.kernel.org/r/20220603053738.1218681-2-ruansy.fnst@fujitsu.com
Signed-off-by: Shiyang Ruan <ruansy.fnst@fujitsu.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Dan Williams <dan.j.wiliams@intel.com>
Reviewed-by: Darrick J. Wong <djwong@kernel.org>
Cc: Dave Chinner <david@fromorbit.com>
Cc: Jane Chu <jane.chu@oracle.com>
Cc: Goldwyn Rodrigues <rgoldwyn@suse.de>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Cc: Matthew Wilcox <willy@infradead.org>
Cc: Naoya Horiguchi <naoya.horiguchi@nec.com>
Cc: Miaohe Lin <linmiaohe@huawei.com>
Cc: Dan Williams <dan.j.williams@intel.com>
Cc: Goldwyn Rodrigues <rgoldwyn@suse.com>
Cc: Ritesh Harjani <riteshh@linux.ibm.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>

Completed in 1822 milliseconds

12