* Re: [PATCH] parisc: io: Improve the outb(), outw() and outl() macros
From: Bart Van Assche @ 2022-01-05 21:29 UTC (permalink / raw)
To: James E . J . Bottomley; +Cc: deller, linux-parisc
In-Reply-To: <20211012222936.3810578-1-bvanassche@acm.org>
On 10/12/21 15:29, Bart Van Assche wrote:
> This patch fixes the following build error for source file
> drivers/scsi/pcmcia/sym53c500_cs.c:
>
> In file included from ./include/linux/bug.h:5,
> from ./include/linux/cpumask.h:14,
> from ./include/linux/mm_types_task.h:14,
> from ./include/linux/mm_types.h:5,
> from ./include/linux/buildid.h:5,
> from ./include/linux/module.h:14,
> from drivers/scsi/pcmcia/sym53c500_cs.c:42:
> drivers/scsi/pcmcia/sym53c500_cs.c: In function ‘SYM53C500_intr’:
> ./arch/parisc/include/asm/bug.h:28:2: error: expected expression before ‘do’
> 28 | do { \
> | ^~
> ./arch/parisc/include/asm/io.h:276:20: note: in expansion of macro ‘BUG’
> 276 | #define outb(x, y) BUG()
> | ^~~
> drivers/scsi/pcmcia/sym53c500_cs.c:124:19: note: in expansion of macro ‘outb’
> 124 | #define REG0(x) (outb(C4_IMG, (x) + CONFIG4))
> | ^~~~
> drivers/scsi/pcmcia/sym53c500_cs.c:362:2: note: in expansion of macro ‘REG0’
> 362 | REG0(port_base);
> | ^~~~
>
> Signed-off-by: Bart Van Assche <bvanassche@acm.org>
> ---
> arch/parisc/include/asm/io.h | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/arch/parisc/include/asm/io.h b/arch/parisc/include/asm/io.h
> index 0b5259102319..837ddddbac6a 100644
> --- a/arch/parisc/include/asm/io.h
> +++ b/arch/parisc/include/asm/io.h
> @@ -273,9 +273,9 @@ static inline int inl(unsigned long addr)
> return -1;
> }
>
> -#define outb(x, y) BUG()
> -#define outw(x, y) BUG()
> -#define outl(x, y) BUG()
> +#define outb(x, y) ({(void)(x); (void)(y); BUG(); 0;})
> +#define outw(x, y) ({(void)(x); (void)(y); BUG(); 0;})
> +#define outl(x, y) ({(void)(x); (void)(y); BUG(); 0;})
> #endif
>
> /*
>
(+Helge Deller and linux-parisc)
Ping?
^ permalink raw reply
* [PATCH v2 12/18] pnv_phb4_pec.c: move pnv_pec_phb_offset() to pnv_phb4.c
From: Daniel Henrique Barboza @ 2022-01-05 21:23 UTC (permalink / raw)
To: qemu-devel; +Cc: danielhb413, qemu-ppc, clg, david
In-Reply-To: <20220105212338.49899-1-danielhb413@gmail.com>
The logic inside pnv_pec_phb_offset() will be useful in the next patch
to determine the stack that should contain a PHB4 device.
Move the function to pnv_phb4.c and make it public since there's no
pnv_phb4_pec.h header. While we're at it, add 'stack_index' as a
parameter and make the function return 'phb-id' directly. And rename it
to pnv_phb4_pec_get_phb_id() to be even clearer about the function
intent.
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
---
hw/pci-host/pnv_phb4.c | 17 +++++++++++++++++
hw/pci-host/pnv_phb4_pec.c | 15 +--------------
include/hw/pci-host/pnv_phb4.h | 2 ++
3 files changed, 20 insertions(+), 14 deletions(-)
diff --git a/hw/pci-host/pnv_phb4.c b/hw/pci-host/pnv_phb4.c
index 6c1a33bc66..4c785bbe4c 100644
--- a/hw/pci-host/pnv_phb4.c
+++ b/hw/pci-host/pnv_phb4.c
@@ -1158,6 +1158,23 @@ static AddressSpace *pnv_phb4_dma_iommu(PCIBus *bus, void *opaque, int devfn)
return &ds->dma_as;
}
+/*
+ * Return the index/phb-id of a PHB4 that belongs to a
+ * pec->stacks[stack_index] stack.
+ */
+int pnv_phb4_pec_get_phb_id(PnvPhb4PecState *pec, int stack_index)
+{
+ PnvPhb4PecClass *pecc = PNV_PHB4_PEC_GET_CLASS(pec);
+ int index = pec->index;
+ int offset = 0;
+
+ while (index--) {
+ offset += pecc->num_stacks[index];
+ }
+
+ return offset + stack_index;
+}
+
/*
* Set the object properties of a phb in relation with its stack.
*
diff --git a/hw/pci-host/pnv_phb4_pec.c b/hw/pci-host/pnv_phb4_pec.c
index 057d4b07fb..e47d19dfff 100644
--- a/hw/pci-host/pnv_phb4_pec.c
+++ b/hw/pci-host/pnv_phb4_pec.c
@@ -374,19 +374,6 @@ static void pnv_pec_instance_init(Object *obj)
}
}
-static int pnv_pec_phb_offset(PnvPhb4PecState *pec)
-{
- PnvPhb4PecClass *pecc = PNV_PHB4_PEC_GET_CLASS(pec);
- int index = pec->index;
- int offset = 0;
-
- while (index--) {
- offset += pecc->num_stacks[index];
- }
-
- return offset;
-}
-
static void pnv_pec_realize(DeviceState *dev, Error **errp)
{
PnvPhb4PecState *pec = PNV_PHB4_PEC(dev);
@@ -405,7 +392,7 @@ static void pnv_pec_realize(DeviceState *dev, Error **errp)
for (i = 0; i < pec->num_stacks; i++) {
PnvPhb4PecStack *stack = &pec->stacks[i];
Object *stk_obj = OBJECT(stack);
- int phb_id = pnv_pec_phb_offset(pec) + i;
+ int phb_id = pnv_phb4_pec_get_phb_id(pec, i);
object_property_set_int(stk_obj, "stack-no", i, &error_abort);
object_property_set_int(stk_obj, "phb-id", phb_id, &error_abort);
diff --git a/include/hw/pci-host/pnv_phb4.h b/include/hw/pci-host/pnv_phb4.h
index 7f5b9cc0ac..b2c4a6b263 100644
--- a/include/hw/pci-host/pnv_phb4.h
+++ b/include/hw/pci-host/pnv_phb4.h
@@ -15,6 +15,7 @@
#include "hw/ppc/xive.h"
#include "qom/object.h"
+typedef struct PnvPhb4PecState PnvPhb4PecState;
typedef struct PnvPhb4PecStack PnvPhb4PecStack;
typedef struct PnvPHB4 PnvPHB4;
typedef struct PnvChip PnvChip;
@@ -132,6 +133,7 @@ struct PnvPHB4 {
void pnv_phb4_pic_print_info(PnvPHB4 *phb, Monitor *mon);
void pnv_phb4_update_regions(PnvPhb4PecStack *stack);
void pnv_phb4_set_stack_phb_props(PnvPhb4PecStack *stack, PnvPHB4 *phb);
+int pnv_phb4_pec_get_phb_id(PnvPhb4PecState *pec, int stack_index);
extern const MemoryRegionOps pnv_phb4_xscom_ops;
/*
--
2.33.1
^ permalink raw reply related
* [PATCH v2 02/18] pnv_phb4.c: add unique chassis and slot for pnv_phb4_root_port
From: Daniel Henrique Barboza @ 2022-01-05 21:23 UTC (permalink / raw)
To: qemu-devel; +Cc: danielhb413, qemu-ppc, clg, david
In-Reply-To: <20220105212338.49899-1-danielhb413@gmail.com>
A similar situation as described previously with pnv_phb3_root_port
devices also happens with pnv_phb4_root_ports.
The solution is the same: assign an unique chassis/slot combo for them.
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
---
hw/pci-host/pnv_phb4.c | 15 +++++++++++++++
1 file changed, 15 insertions(+)
diff --git a/hw/pci-host/pnv_phb4.c b/hw/pci-host/pnv_phb4.c
index 5ba26e250a..836b0c156c 100644
--- a/hw/pci-host/pnv_phb4.c
+++ b/hw/pci-host/pnv_phb4.c
@@ -1338,8 +1338,23 @@ static void pnv_phb4_root_port_reset(DeviceState *dev)
static void pnv_phb4_root_port_realize(DeviceState *dev, Error **errp)
{
PCIERootPortClass *rpc = PCIE_ROOT_PORT_GET_CLASS(dev);
+ PCIDevice *pci = PCI_DEVICE(dev);
+ PCIBus *bus = pci_get_bus(pci);
+ PnvPHB4 *phb = NULL;
Error *local_err = NULL;
+ phb = (PnvPHB4 *) object_dynamic_cast(OBJECT(bus->qbus.parent),
+ TYPE_PNV_PHB4);
+
+ if (!phb) {
+ error_setg(errp, "%s must be connected to pnv-phb4 buses", dev->id);
+ return;
+ }
+
+ /* Set unique chassis/slot values for the root port */
+ qdev_prop_set_uint8(&pci->qdev, "chassis", phb->chip_id);
+ qdev_prop_set_uint16(&pci->qdev, "slot", phb->phb_id);
+
rpc->parent_realize(dev, &local_err);
if (local_err) {
error_propagate(errp, local_err);
--
2.33.1
^ permalink raw reply related
* [lttng-dev] [RELEASE] LTTng-UST 2.12.3 and 2.11.5 (Linux user-space tracer)
From: Mathieu Desnoyers via lttng-dev @ 2022-01-05 21:27 UTC (permalink / raw)
To: lttng-dev, diamon-discuss, linux-trace-users
Hi,
This is a release announcement for the LTTng-UST 2.12.3 and 2.11.5
tracer. Those are bug fix releases.
The 2.11.5 release marks the end of life (EOL) of the stable-2.11 branch.
Users experiencing issues with the 2.11 branch are expected to upgrade to
either 2.12.3 or 2.13.1.
Note that the latest stable branch is 2.13 (its most recent release
is 2.13.1, released on December 10, 2021).
* Notable changes in 2.12.3:
Two notable fixes are "Fix: nestable pthread cancelstate" and
"Fix: abort on decrement_sem_count during concurrent tracing start and teardown",
which fix a rare deadlock scenario at application exit.
Another notable fix is "fix: liblttng-ust-fd async-signal-safe close()", which
ensures that the implementation of the symbol interposition for "close" is
async-signal safe, as it should be.
Please refer to the change logs below for the fixes contained in those
two releases.
Feedback is welcome,
Thanks,
Mathieu
Project website: https://lttng.org
Documentation: https://lttng.org/docs
Download link: https://lttng.org/download
2022-01-05 (National Bird Day) lttng-ust 2.12.3
* Fix: ust-cancelstate: include string.h for strerror
* Fix: lttng-ust-fd: remove lttng_ust_common_ctor call
* Fix: nestable pthread cancelstate
* Fix: abort on decrement_sem_count during concurrent tracing start and teardown
* fix: liblttng-ust-fd async-signal-safe close()
* Set git-review branch to stable-2.12
* fix: link benchmark with pthread
* Fix: liblttng-ust-ctl have dependencies on liburcu
* Fix: add extern "C" to two header files
2022-01-05 (National Bird Day) lttng-ust 2.11.5
* Set git-review branch to stable-2.11
* fix: allow building with userspace-rcu 0.13
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
_______________________________________________
lttng-dev mailing list
lttng-dev@lists.lttng.org
https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
^ permalink raw reply
* [RELEASE] LTTng-UST 2.12.3 and 2.11.5 (Linux user-space tracer)
From: Mathieu Desnoyers @ 2022-01-05 21:27 UTC (permalink / raw)
To: lttng-dev, diamon-discuss, linux-trace-users
Hi,
This is a release announcement for the LTTng-UST 2.12.3 and 2.11.5
tracer. Those are bug fix releases.
The 2.11.5 release marks the end of life (EOL) of the stable-2.11 branch.
Users experiencing issues with the 2.11 branch are expected to upgrade to
either 2.12.3 or 2.13.1.
Note that the latest stable branch is 2.13 (its most recent release
is 2.13.1, released on December 10, 2021).
* Notable changes in 2.12.3:
Two notable fixes are "Fix: nestable pthread cancelstate" and
"Fix: abort on decrement_sem_count during concurrent tracing start and teardown",
which fix a rare deadlock scenario at application exit.
Another notable fix is "fix: liblttng-ust-fd async-signal-safe close()", which
ensures that the implementation of the symbol interposition for "close" is
async-signal safe, as it should be.
Please refer to the change logs below for the fixes contained in those
two releases.
Feedback is welcome,
Thanks,
Mathieu
Project website: https://lttng.org
Documentation: https://lttng.org/docs
Download link: https://lttng.org/download
2022-01-05 (National Bird Day) lttng-ust 2.12.3
* Fix: ust-cancelstate: include string.h for strerror
* Fix: lttng-ust-fd: remove lttng_ust_common_ctor call
* Fix: nestable pthread cancelstate
* Fix: abort on decrement_sem_count during concurrent tracing start and teardown
* fix: liblttng-ust-fd async-signal-safe close()
* Set git-review branch to stable-2.12
* fix: link benchmark with pthread
* Fix: liblttng-ust-ctl have dependencies on liburcu
* Fix: add extern "C" to two header files
2022-01-05 (National Bird Day) lttng-ust 2.11.5
* Set git-review branch to stable-2.11
* fix: allow building with userspace-rcu 0.13
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
^ permalink raw reply
* [diamon-discuss] [RELEASE] LTTng-UST 2.12.3 and 2.11.5 (Linux user-space tracer)
From: Mathieu Desnoyers @ 2022-01-05 21:27 UTC (permalink / raw)
To: lttng-dev, diamon-discuss, linux-trace-users
Hi,
This is a release announcement for the LTTng-UST 2.12.3 and 2.11.5
tracer. Those are bug fix releases.
The 2.11.5 release marks the end of life (EOL) of the stable-2.11 branch.
Users experiencing issues with the 2.11 branch are expected to upgrade to
either 2.12.3 or 2.13.1.
Note that the latest stable branch is 2.13 (its most recent release
is 2.13.1, released on December 10, 2021).
* Notable changes in 2.12.3:
Two notable fixes are "Fix: nestable pthread cancelstate" and
"Fix: abort on decrement_sem_count during concurrent tracing start and teardown",
which fix a rare deadlock scenario at application exit.
Another notable fix is "fix: liblttng-ust-fd async-signal-safe close()", which
ensures that the implementation of the symbol interposition for "close" is
async-signal safe, as it should be.
Please refer to the change logs below for the fixes contained in those
two releases.
Feedback is welcome,
Thanks,
Mathieu
Project website: https://lttng.org
Documentation: https://lttng.org/docs
Download link: https://lttng.org/download
2022-01-05 (National Bird Day) lttng-ust 2.12.3
* Fix: ust-cancelstate: include string.h for strerror
* Fix: lttng-ust-fd: remove lttng_ust_common_ctor call
* Fix: nestable pthread cancelstate
* Fix: abort on decrement_sem_count during concurrent tracing start and teardown
* fix: liblttng-ust-fd async-signal-safe close()
* Set git-review branch to stable-2.12
* fix: link benchmark with pthread
* Fix: liblttng-ust-ctl have dependencies on liburcu
* Fix: add extern "C" to two header files
2022-01-05 (National Bird Day) lttng-ust 2.11.5
* Set git-review branch to stable-2.11
* fix: allow building with userspace-rcu 0.13
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
^ permalink raw reply
* [PATCH v2 01/18] pnv_phb3.c: add unique chassis and slot for pnv_phb3_root_port
From: Daniel Henrique Barboza @ 2022-01-05 21:23 UTC (permalink / raw)
To: qemu-devel; +Cc: danielhb413, qemu-ppc, clg, david
In-Reply-To: <20220105212338.49899-1-danielhb413@gmail.com>
When creating a pnv_phb3_root_port using the command line, the first
root port is created successfully, but the second fails with the
following error:
qemu-system-ppc64: -device pnv-phb3-root-port,bus=phb3-root.0,id=pcie.3:
Can't add chassis slot, error -16
This error comes from the realize() function of its parent type,
rp_realize() from TYPE_PCIE_ROOT_PORT. pcie_chassis_add_slot() fails
with -EBUSY if there's an existing PCIESlot that has the same
chassis/slot value, regardless of being in a different bus.
One way to prevent this error is simply set chassis and slot values in
the command line. However, since phb3 root buses only supports a single
root port, we can just get an unique chassis/slot value by checking
which root bus the pnv_phb3_root_port is going to be attached, get the
equivalent phb3 device and use its chip-id and index values, which are
guaranteed to be unique.
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
---
hw/pci-host/pnv_phb3.c | 16 ++++++++++++++++
1 file changed, 16 insertions(+)
diff --git a/hw/pci-host/pnv_phb3.c b/hw/pci-host/pnv_phb3.c
index c78084cce7..3467bbb5d9 100644
--- a/hw/pci-host/pnv_phb3.c
+++ b/hw/pci-host/pnv_phb3.c
@@ -1142,8 +1142,24 @@ static const TypeInfo pnv_phb3_root_bus_info = {
static void pnv_phb3_root_port_realize(DeviceState *dev, Error **errp)
{
PCIERootPortClass *rpc = PCIE_ROOT_PORT_GET_CLASS(dev);
+ PCIDevice *pci = PCI_DEVICE(dev);
+ PCIBus *bus = pci_get_bus(pci);
+ PnvPHB3 *phb = NULL;
Error *local_err = NULL;
+ phb = (PnvPHB3 *) object_dynamic_cast(OBJECT(bus->qbus.parent),
+ TYPE_PNV_PHB3);
+
+ if (!phb) {
+ error_setg(errp,
+"pnv_phb3_root_port devices must be connected to pnv-phb3 buses");
+ return;
+ }
+
+ /* Set unique chassis/slot values for the root port */
+ qdev_prop_set_uint8(&pci->qdev, "chassis", phb->chip_id);
+ qdev_prop_set_uint16(&pci->qdev, "slot", phb->phb_id);
+
rpc->parent_realize(dev, &local_err);
if (local_err) {
error_propagate(errp, local_err);
--
2.33.1
^ permalink raw reply related
* [PATCH v2 00/18] user creatable pnv-phb3/pnv-phb4 devices
From: Daniel Henrique Barboza @ 2022-01-05 21:23 UTC (permalink / raw)
To: qemu-devel; +Cc: danielhb413, qemu-ppc, clg, david
Hi,
This second version was rebased with upstream and includes fixed/amended
versions of relevant patches that were sent to the mailing list and aren't
upstream yet. In this process 4 patches from v1 were discarded, becoming
either irrelevant or squashed into others.
The patches are organized as follows:
- patches 1-4: enable user creatable phb3/phb4 root ports
- patches 5-10: enable user creatable pnv-phb3 devices
- patches 11-18: enable user creatable pnv-phb4 devices
Here are some examples of what we're able to do with this series:
* powernv8 machine with -nodefaults,2 pnv-phb3s with 'pcie.N' name,
one of them with a root port and a netcard:
$ qemu-system-ppc64 -m 4G -machine powernv8,accel=tcg -smp 2,cores=2,threads=1 \
-bios skiboot.lid -kernel vmlinux -initrd buildroot.rootfs.cpio \
-append 'console=hvc0 ro xmon=on' \
-nodefaults \
-serial mon:stdio -nographic \
-device pnv-phb3,chip-id=0,index=0,id=pcie.0 \
-device pnv-phb3,chip-id=0,index=2,id=pcie.2 \
-device pnv-phb3-root-port,bus=pcie.2,id=pcie.5 \
-netdev bridge,helper=/usr/libexec/qemu-bridge-helper,br=virbr0,id=net0 \
-device e1000e,netdev=net0,mac=C0:ff:EE:00:01:04,bus=pcie.5,addr=0x0
* powernv9 machine with -nodefaults, 3 of the available 12 pnv-phb4 devices
created, 2 root ports, one of the port with a pcie-pci-bridge and
devices connected in the bridge:
$ qemu-system-ppc64 -m 4G -machine powernv9 \
-smp 2,sockets=2,cores=1,threads=1 \
-accel tcg,thread=multi -bios skiboot.lid \
-kernel vmlinux -initrd buildroot.rootfs.cpio \
-append 'console=hvc0 ro xmon=on' \
-nodefaults \
-serial mon:stdio -nographic \
-device pnv-phb4,chip-id=0,index=0,id=pcie.0 \
-device pnv-phb4,chip-id=0,index=4,id=pcie.1 \
-device pnv-phb4,chip-id=1,index=3,id=pcie.2 \
-device pnv-phb4-root-port,id=root0,bus=pcie.2 \
-device pnv-phb4-root-port,id=root1,bus=pcie.1 \
-device pcie-pci-bridge,id=bridge1,bus=root0,addr=0x0 \
-device nvme,bus=bridge1,addr=0x1,drive=drive0,serial=1234 \
-drive file=./simics-disk.raw,if=none,id=drive0,format=raw,cache=none \
-device e1000e,netdev=net0,mac=C0:ff:EE:00:01:04,bus=bridge1,addr=0x3 \
-netdev bridge,helper=/usr/libexec/qemu-bridge-helper,br=virbr0,id=net0 \
-device nec-usb-xhci,bus=bridge1,addr=0x2
* powernv8/9 with default settings can be used as usual. The work done
in this series didn't change the name of the buses created by the
default root ports (named pcie.0...N):
$ qemu-system-ppc64 -m 4G \
-machine powernv9 -smp 2,sockets=2,cores=1,threads=1 \
-accel tcg,thread=multi -bios skiboot.lid \
-kernel vmlinux -initrd buildroot.rootfs.cpio \
-append 'console=hvc0 ro xmon=on' \
-serial mon:stdio -nographic \
-device pcie-pci-bridge,id=bridge1,bus=pcie.0,addr=0x0 \
-device nvme,bus=bridge1,addr=0x1,drive=drive0,serial=1234 \
-drive file=./simics-disk.raw,if=none,id=drive0,format=raw,cache=none \
-device e1000e,netdev=net0,mac=C0:ff:EE:00:01:04,bus=bridge1,addr=0x3 \
-netdev bridge,helper=/usr/libexec/qemu-bridge-helper,br=virbr0,id=net0 \
-device nec-usb-xhci,bus=bridge1,addr=0x2
Changes from v1:
- rebased with upstream at 7d4ae4d497807
- added relevant patches that aren't upstream yet from "ppc/pnv:
Preliminary cleanups before user created PHBs" [1] and "ppc/pnv: Add
support for user created PHB3/PHB4 devices" [2] series
- renamed phb3/phb4 default buses name to 'pnv-phb3-root' and
'pnv-phb4-root'
- renamed pnv_pec_get_phb_id() to pnv_phb4_pec_get_phb_id()
- patch 'introduce pnv_pec_init_stack_xscom()' moved to patch 16 to
be closer with patch 17 that uses it
- v1 link: https://lists.gnu.org/archive/html/qemu-devel/2021-12/msg04427.html
[1] https://lists.gnu.org/archive/html/qemu-devel/2021-12/msg03810.html
[2] https://lists.gnu.org/archive/html/qemu-devel/2021-12/msg01548.html
Cédric Le Goater (5):
ppc/pnv: Attach PHB3 root port device when defaults are enabled
ppc/pnv: Introduce support for user created PHB3 devices
ppc/pnv: Reparent user created PHB3 devices to the PnvChip
ppc/pnv: Complete user created PHB3 devices
ppc/pnv: Move num_phbs under Pnv8Chip
Daniel Henrique Barboza (13):
pnv_phb3.c: add unique chassis and slot for pnv_phb3_root_port
pnv_phb4.c: add unique chassis and slot for pnv_phb4_root_port
pnv_phb4.c: make pnv-phb4-root-port user creatable
pnv_phb4.c: check if root port exists in rc_config functions
pnv_phb3.h: change TYPE_PNV_PHB3_ROOT_BUS name
pnv_phb4.c: introduce pnv_phb4_set_stack_phb_props()
pnv_phb4_pec.c: move pnv_pec_phb_offset() to pnv_phb4.c
pnv_phb4_pec: use pnv_phb4_pec_get_phb_id() in pnv_pec_dt_xscom()
pnv_phb4.h: turn phb into a pointer in struct PnvPhb4PecStack
pnv_phb4_pec.c: use 'default_enabled()' to init stack->phb
pnv_phb4.c: introduce pnv_pec_init_stack_xscom()
ppc/pnv: Introduce user creatable pnv-phb4 devices
pnv_phb4.c: change TYPE_PNV_PHB4_ROOT_BUS name
hw/pci-host/pnv_phb3.c | 57 ++++++++--
hw/pci-host/pnv_phb4.c | 193 ++++++++++++++++++++++++++++++---
hw/pci-host/pnv_phb4_pec.c | 86 ++++++---------
hw/ppc/pnv.c | 55 ++++++++--
include/hw/pci-host/pnv_phb3.h | 4 +-
include/hw/pci-host/pnv_phb4.h | 15 ++-
include/hw/ppc/pnv.h | 8 +-
7 files changed, 322 insertions(+), 96 deletions(-)
--
2.33.1
^ permalink raw reply
* Re: [PATCH v2] drm/amd/display: explicitly update clocks when DC is set to D3 in s0i3
From: Harry Wentland @ 2022-01-05 21:26 UTC (permalink / raw)
To: Mario Limonciello, amd-gfx
Cc: Qingqing Zhuo, Scott Bruce, spasswolf, Chris Hixon
In-Reply-To: <20220105170656.2121-1-mario.limonciello@amd.com>
On 2022-01-05 12:06, Mario Limonciello wrote:
> The WA from commit 5965280abd30 ("drm/amd/display: Apply w/a for
> hard hang on HPD") causes a regression in s0ix where the system will
> fail to resume properly. This may be because an HPD was active the last
> time clocks were updated but clocks didn't get updated again during s0ix.
>
> So add an extra call to update clocks as part of the suspend routine:
> dm_suspend->dc_set_power_state->clk_mgr_optimize_pwr_state
>
> In case HPD is set during this time, also check if the call happened during
> suspend to allow overriding the WA.
>
> Cc: Qingqing Zhuo <qingqing.zhuo@amd.com>
> Reported-by: Scott Bruce <smbruce@gmail.com>
> Reported-by: Chris Hixon <linux-kernel-bugs@hixontech.com>
> Reported-by: spasswolf@web.de
> BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=215436
> BugLink: https://gitlab.freedesktop.org/drm/amd/-/issues/1821
> BugLink: https://gitlab.freedesktop.org/drm/amd/-/issues/1852
> Fixes: 5965280abd30 ("drm/amd/display: Apply w/a for hard hang on HPD")
> Fixes: 1bd3bc745e7f ("drm/amd/display: Extend w/a for hard hang on HPD to dcn20")
> Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
> ---
> changes from v1->v2:
> * Add fallthrough statement
> * Extend case to check if call was explicitly in s0ix since #1852 showed hpd_state
> can be set at this time too
> * Adjust commit message and title
> * Add extra commit and bug fixed to metadata
> drivers/gpu/drm/amd/display/dc/clk_mgr/dcn21/rn_clk_mgr.c | 5 ++++-
> drivers/gpu/drm/amd/display/dc/core/dc.c | 3 +++
> 2 files changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/display/dc/clk_mgr/dcn21/rn_clk_mgr.c b/drivers/gpu/drm/amd/display/dc/clk_mgr/dcn21/rn_clk_mgr.c
> index fbda42313bfe..fa5efe10b779 100644
> --- a/drivers/gpu/drm/amd/display/dc/clk_mgr/dcn21/rn_clk_mgr.c
> +++ b/drivers/gpu/drm/amd/display/dc/clk_mgr/dcn21/rn_clk_mgr.c
> @@ -23,6 +23,8 @@
> *
> */
>
> +#include "amdgpu.h"
> +
> #include "dccg.h"
> #include "clk_mgr_internal.h"
>
> @@ -126,6 +128,7 @@ static void rn_update_clocks(struct clk_mgr *clk_mgr_base,
> bool safe_to_lower)
> {
> struct clk_mgr_internal *clk_mgr = TO_CLK_MGR_INTERNAL(clk_mgr_base);
> + struct amdgpu_device *adev = clk_mgr_base->ctx->driver_context;
DC code is shared on other OSes. driver_context won't be an instance
of amdgpu_device in those cases.
If we need adev->in_s0ix we need to find a way to plumb it through
DC structs and interfaces.
Harry
> struct dc_clocks *new_clocks = &context->bw_ctx.bw.dcn.clk;
> struct dc *dc = clk_mgr_base->ctx->dc;
> int display_count;
> @@ -157,7 +160,7 @@ static void rn_update_clocks(struct clk_mgr *clk_mgr_base,
> }
>
> /* if we can go lower, go lower */
> - if (display_count == 0 && !hpd_state) {
> + if (display_count == 0 && (adev->in_s0ix || !hpd_state)) {
> rn_vbios_smu_set_dcn_low_power_state(clk_mgr, DCN_PWR_STATE_LOW_POWER);
> /* update power state */
> clk_mgr_base->clks.pwr_state = DCN_PWR_STATE_LOW_POWER;
> diff --git a/drivers/gpu/drm/amd/display/dc/core/dc.c b/drivers/gpu/drm/amd/display/dc/core/dc.c
> index 91c4874473d6..8e0c820f6892 100644
> --- a/drivers/gpu/drm/amd/display/dc/core/dc.c
> +++ b/drivers/gpu/drm/amd/display/dc/core/dc.c
> @@ -3299,6 +3299,9 @@ void dc_set_power_state(
> }
>
> break;
> + case DC_ACPI_CM_POWER_STATE_D3:
> + clk_mgr_optimize_pwr_state(dc, dc->clk_mgr);
> + fallthrough;
> default:
> ASSERT(dc->current_state->stream_count == 0);
> /* Zero out the current context so that on resume we start with
^ permalink raw reply
* [Bug 210263] brightness device returns ENXIO (?) on brightness restore at boot, with bootoption "quiet"
From: bugzilla-daemon @ 2022-01-05 21:25 UTC (permalink / raw)
To: dri-devel
In-Reply-To: <bug-210263-2300@https.bugzilla.kernel.org/>
https://bugzilla.kernel.org/show_bug.cgi?id=210263
jaromir.obr@gmail.com changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jaromir.obr@gmail.com
--- Comment #6 from jaromir.obr@gmail.com ---
@Fabian
I have the same experience. I was running kernel 5.13 on Ubuntu 21.10 and when
I upgraded to mainline kernel 5.15.13 (using
https://github.com/pimlie/ubuntu-mainline-kernel.sh), the service
"systemd-backlight@backlight:amdgpu_bl0.service" starts as expected and
backlight seems to be restored.
With kernel 5.13 it failed: "Failed to start Load/Save Screen Backlight
Brightness of backlight:amdgpu_bl0" and I was not able to start it manually.
--
You may reply to this email to add a comment.
You are receiving this mail because:
You are watching the assignee of the bug.
^ permalink raw reply
* [PATCH v3] drm/mediatek: Set default value for Panel Orientation connector prop.
From: Mark Yacoub @ 2022-01-05 21:23 UTC (permalink / raw)
To: linux-mediatek
Cc: seanpaul, markyacoub, markyacoub, chunkuang.hu, p.zabel,
matthias.bgg, jason-jh.lin, tzungbi, David Airlie, Daniel Vetter,
dri-devel, linux-arm-kernel, linux-kernel
In-Reply-To: <20211229184420.793234-1-markyacoub@chromium.org>
[Why]
Creating the prop uses UNKNOWN as the initial value, which is not a
supported value if the prop is to be supported.
[How]
Set the panel orientation default value to NORMAL right after creating
the prop if no DSI panel exists.
Panels have their own orientations, and panel orientation can't be
overriden once initialized to a value.
v2:
Move to the latest code where struct mtk_dsi{} has no member 'panel'.
v1:
Set panel orientation only if DSI panel does not exist.
Tested on Jacuzzi(MTK)
Fixes IGT@kms_properties@get_properties-sanity-{atomic,non-atomic}
Signed-off-by: Mark Yacoub <markyacoub@chromium.org>
---
drivers/gpu/drm/mediatek/mtk_dsi.c | 18 +++++++++++++-----
1 file changed, 13 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c b/drivers/gpu/drm/mediatek/mtk_dsi.c
index 5d90d2eb00193..9e1d4e297ca48 100644
--- a/drivers/gpu/drm/mediatek/mtk_dsi.c
+++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
@@ -941,8 +941,10 @@ static const struct mipi_dsi_host_ops mtk_dsi_ops = {
.transfer = mtk_dsi_host_transfer,
};
-static int mtk_dsi_encoder_init(struct drm_device *drm, struct mtk_dsi *dsi)
+static int mtk_dsi_encoder_init(struct device *dev, struct drm_device *drm)
{
+ struct mtk_dsi *dsi = dev_get_drvdata(dev);
+ struct drm_panel *panel;
int ret;
ret = drm_simple_encoder_init(drm, &dsi->encoder,
@@ -967,6 +969,15 @@ static int mtk_dsi_encoder_init(struct drm_device *drm, struct mtk_dsi *dsi)
}
drm_connector_attach_encoder(dsi->connector, &dsi->encoder);
+ ret = drm_of_find_panel_or_bridge(dev->of_node, 0, 0, &panel,
+ &dsi->next_bridge);
+ /* A drm_panel can have its own orientation. If there is no panel, set the
+ * orientation to NORMAL. */
+ if (ret || !panel) {
+ drm_connector_set_panel_orientation(
+ dsi->connector, DRM_MODE_PANEL_ORIENTATION_NORMAL);
+ }
+
return 0;
err_cleanup_encoder:
@@ -976,11 +987,8 @@ static int mtk_dsi_encoder_init(struct drm_device *drm, struct mtk_dsi *dsi)
static int mtk_dsi_bind(struct device *dev, struct device *master, void *data)
{
- int ret;
struct drm_device *drm = data;
- struct mtk_dsi *dsi = dev_get_drvdata(dev);
-
- ret = mtk_dsi_encoder_init(drm, dsi);
+ int ret = mtk_dsi_encoder_init(dev, drm);
if (ret)
return ret;
--
2.34.1.448.ga2b2bfdf31-goog
_______________________________________________
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 v3] drm/mediatek: Set default value for Panel Orientation connector prop.
From: Mark Yacoub @ 2022-01-05 21:23 UTC (permalink / raw)
To: linux-mediatek
Cc: seanpaul, markyacoub, markyacoub, chunkuang.hu, p.zabel,
matthias.bgg, jason-jh.lin, tzungbi, David Airlie, Daniel Vetter,
dri-devel, linux-arm-kernel, linux-kernel
In-Reply-To: <20211229184420.793234-1-markyacoub@chromium.org>
[Why]
Creating the prop uses UNKNOWN as the initial value, which is not a
supported value if the prop is to be supported.
[How]
Set the panel orientation default value to NORMAL right after creating
the prop if no DSI panel exists.
Panels have their own orientations, and panel orientation can't be
overriden once initialized to a value.
v2:
Move to the latest code where struct mtk_dsi{} has no member 'panel'.
v1:
Set panel orientation only if DSI panel does not exist.
Tested on Jacuzzi(MTK)
Fixes IGT@kms_properties@get_properties-sanity-{atomic,non-atomic}
Signed-off-by: Mark Yacoub <markyacoub@chromium.org>
---
drivers/gpu/drm/mediatek/mtk_dsi.c | 18 +++++++++++++-----
1 file changed, 13 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c b/drivers/gpu/drm/mediatek/mtk_dsi.c
index 5d90d2eb00193..9e1d4e297ca48 100644
--- a/drivers/gpu/drm/mediatek/mtk_dsi.c
+++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
@@ -941,8 +941,10 @@ static const struct mipi_dsi_host_ops mtk_dsi_ops = {
.transfer = mtk_dsi_host_transfer,
};
-static int mtk_dsi_encoder_init(struct drm_device *drm, struct mtk_dsi *dsi)
+static int mtk_dsi_encoder_init(struct device *dev, struct drm_device *drm)
{
+ struct mtk_dsi *dsi = dev_get_drvdata(dev);
+ struct drm_panel *panel;
int ret;
ret = drm_simple_encoder_init(drm, &dsi->encoder,
@@ -967,6 +969,15 @@ static int mtk_dsi_encoder_init(struct drm_device *drm, struct mtk_dsi *dsi)
}
drm_connector_attach_encoder(dsi->connector, &dsi->encoder);
+ ret = drm_of_find_panel_or_bridge(dev->of_node, 0, 0, &panel,
+ &dsi->next_bridge);
+ /* A drm_panel can have its own orientation. If there is no panel, set the
+ * orientation to NORMAL. */
+ if (ret || !panel) {
+ drm_connector_set_panel_orientation(
+ dsi->connector, DRM_MODE_PANEL_ORIENTATION_NORMAL);
+ }
+
return 0;
err_cleanup_encoder:
@@ -976,11 +987,8 @@ static int mtk_dsi_encoder_init(struct drm_device *drm, struct mtk_dsi *dsi)
static int mtk_dsi_bind(struct device *dev, struct device *master, void *data)
{
- int ret;
struct drm_device *drm = data;
- struct mtk_dsi *dsi = dev_get_drvdata(dev);
-
- ret = mtk_dsi_encoder_init(drm, dsi);
+ int ret = mtk_dsi_encoder_init(dev, drm);
if (ret)
return ret;
--
2.34.1.448.ga2b2bfdf31-goog
_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek
^ permalink raw reply related
* [PATCH v3] drm/mediatek: Set default value for Panel Orientation connector prop.
From: Mark Yacoub @ 2022-01-05 21:23 UTC (permalink / raw)
To: linux-mediatek
Cc: seanpaul, markyacoub, markyacoub, chunkuang.hu, p.zabel,
matthias.bgg, jason-jh.lin, tzungbi, David Airlie, Daniel Vetter,
dri-devel, linux-arm-kernel, linux-kernel
In-Reply-To: <20211229184420.793234-1-markyacoub@chromium.org>
[Why]
Creating the prop uses UNKNOWN as the initial value, which is not a
supported value if the prop is to be supported.
[How]
Set the panel orientation default value to NORMAL right after creating
the prop if no DSI panel exists.
Panels have their own orientations, and panel orientation can't be
overriden once initialized to a value.
v2:
Move to the latest code where struct mtk_dsi{} has no member 'panel'.
v1:
Set panel orientation only if DSI panel does not exist.
Tested on Jacuzzi(MTK)
Fixes IGT@kms_properties@get_properties-sanity-{atomic,non-atomic}
Signed-off-by: Mark Yacoub <markyacoub@chromium.org>
---
drivers/gpu/drm/mediatek/mtk_dsi.c | 18 +++++++++++++-----
1 file changed, 13 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c b/drivers/gpu/drm/mediatek/mtk_dsi.c
index 5d90d2eb00193..9e1d4e297ca48 100644
--- a/drivers/gpu/drm/mediatek/mtk_dsi.c
+++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
@@ -941,8 +941,10 @@ static const struct mipi_dsi_host_ops mtk_dsi_ops = {
.transfer = mtk_dsi_host_transfer,
};
-static int mtk_dsi_encoder_init(struct drm_device *drm, struct mtk_dsi *dsi)
+static int mtk_dsi_encoder_init(struct device *dev, struct drm_device *drm)
{
+ struct mtk_dsi *dsi = dev_get_drvdata(dev);
+ struct drm_panel *panel;
int ret;
ret = drm_simple_encoder_init(drm, &dsi->encoder,
@@ -967,6 +969,15 @@ static int mtk_dsi_encoder_init(struct drm_device *drm, struct mtk_dsi *dsi)
}
drm_connector_attach_encoder(dsi->connector, &dsi->encoder);
+ ret = drm_of_find_panel_or_bridge(dev->of_node, 0, 0, &panel,
+ &dsi->next_bridge);
+ /* A drm_panel can have its own orientation. If there is no panel, set the
+ * orientation to NORMAL. */
+ if (ret || !panel) {
+ drm_connector_set_panel_orientation(
+ dsi->connector, DRM_MODE_PANEL_ORIENTATION_NORMAL);
+ }
+
return 0;
err_cleanup_encoder:
@@ -976,11 +987,8 @@ static int mtk_dsi_encoder_init(struct drm_device *drm, struct mtk_dsi *dsi)
static int mtk_dsi_bind(struct device *dev, struct device *master, void *data)
{
- int ret;
struct drm_device *drm = data;
- struct mtk_dsi *dsi = dev_get_drvdata(dev);
-
- ret = mtk_dsi_encoder_init(drm, dsi);
+ int ret = mtk_dsi_encoder_init(dev, drm);
if (ret)
return ret;
--
2.34.1.448.ga2b2bfdf31-goog
^ permalink raw reply related
* Re: [PATCH] alpha: Remove usage of the deprecated "pci-dma-compat.h" API
From: Christophe JAILLET @ 2022-01-05 21:23 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Richard Henderson, Ivan Kokshaysky, Matt Turner, Logan Gunthorpe,
Andrew Morton, Mike Rapoport, David Hildenbrand, martin.oliveira,
alpha, Linux Kernel Mailing List, kernel-janitors
In-Reply-To: <CAK8P3a2XwFveAd8nSCexZG3_UZga2PQ+EXHxQLGaWkLjCwrBxQ@mail.gmail.com>
Le 03/01/2022 à 02:51, Arnd Bergmann a écrit :
> On Sun, Jan 2, 2022 at 10:32 AM Christophe JAILLET
> <christophe.jaillet@wanadoo.fr> wrote:
>>
>> In [1], Christoph Hellwig has proposed to remove the wrappers in
>> include/linux/pci-dma-compat.h.
>>
>> Some reasons why this API should be removed have been given by Julia
>> Lawall in [2].
>>
>> A coccinelle script has been used to perform the needed transformation.
>> Only relevant parts are given below.
>>
>>
>> [1]: https://lore.kernel.org/kernel-janitors/20200421081257.GA131897@infradead.org/
>> [2]: https://lore.kernel.org/kernel-janitors/alpine.DEB.2.22.394.2007120902170.2424@hadrien/
>>
>> Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
>
> Reviewed-by: Arnd Bergmann <arnd@arndb.de>
>
> It looks like the number of remaining files that use the old
> interfaces has gone down
> a lot more since you last sent these patches. I would suggest you send them as a
> series that includes the patch to remove the header as the last change, and
> ask Andrew to pick up the ones that remain after this resend into the -mm tree,
> possibly after the next -rc1. How many patches do you have left?
>
> Arnd
>
Hi,
This would be ~ 10 patches.
I sent recently some missing ones because I was not aware of
--include-headers. So .h files were missing in my previous patches.
The main remaining issue is linked to files in message/fusion.
The patches are big.
They have to be looked at carefully because it touches some GFP flags
when s/pci_alloc_consistent/dma_alloc_coherent/.
My last try did not get any attention.
Even [1] which is purely mechanical
I'll try another approach without trying to turn some (hidden)
GFP_ATOMIC into GFP_KERNEL.
1st patch: only mechanical changes done with coccinelle, leaving GFP_ATOMIC
2nd patch: add some FIXME comments explaining why some could be turned
into GFP_KERNEL
3rd patch: remove the comments and update the GFP flags accordingly.
So, a maintainer could either apply 1 (no risk at all, should even
generate the same .o file), or 1+2 (only FIXME comments for future
analysis) or 1+2+3 for full clean-up (if he trusts me and/or has time to
check my explanations).
This way, I hope that some could at least apply the first one.
Being able to axe this deprecated API and .h file would be my
contribution to Ingo Molnar's "Fast Kernel Headers" tree :)
CJ
[1]:
https://lore.kernel.org/kernel-janitors/db5aa78d7d44b809ab83ba6fb4880d698517bfec.1623580326.git.christophe.jaillet@wanadoo.fr/
^ permalink raw reply
* [PATCH v3] drm/mediatek: Set default value for Panel Orientation connector prop.
From: Mark Yacoub @ 2022-01-05 21:23 UTC (permalink / raw)
To: linux-mediatek
Cc: chunkuang.hu, David Airlie, markyacoub, linux-kernel, dri-devel,
tzungbi, seanpaul, jason-jh.lin, matthias.bgg, linux-arm-kernel,
markyacoub
In-Reply-To: <20211229184420.793234-1-markyacoub@chromium.org>
[Why]
Creating the prop uses UNKNOWN as the initial value, which is not a
supported value if the prop is to be supported.
[How]
Set the panel orientation default value to NORMAL right after creating
the prop if no DSI panel exists.
Panels have their own orientations, and panel orientation can't be
overriden once initialized to a value.
v2:
Move to the latest code where struct mtk_dsi{} has no member 'panel'.
v1:
Set panel orientation only if DSI panel does not exist.
Tested on Jacuzzi(MTK)
Fixes IGT@kms_properties@get_properties-sanity-{atomic,non-atomic}
Signed-off-by: Mark Yacoub <markyacoub@chromium.org>
---
drivers/gpu/drm/mediatek/mtk_dsi.c | 18 +++++++++++++-----
1 file changed, 13 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c b/drivers/gpu/drm/mediatek/mtk_dsi.c
index 5d90d2eb00193..9e1d4e297ca48 100644
--- a/drivers/gpu/drm/mediatek/mtk_dsi.c
+++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
@@ -941,8 +941,10 @@ static const struct mipi_dsi_host_ops mtk_dsi_ops = {
.transfer = mtk_dsi_host_transfer,
};
-static int mtk_dsi_encoder_init(struct drm_device *drm, struct mtk_dsi *dsi)
+static int mtk_dsi_encoder_init(struct device *dev, struct drm_device *drm)
{
+ struct mtk_dsi *dsi = dev_get_drvdata(dev);
+ struct drm_panel *panel;
int ret;
ret = drm_simple_encoder_init(drm, &dsi->encoder,
@@ -967,6 +969,15 @@ static int mtk_dsi_encoder_init(struct drm_device *drm, struct mtk_dsi *dsi)
}
drm_connector_attach_encoder(dsi->connector, &dsi->encoder);
+ ret = drm_of_find_panel_or_bridge(dev->of_node, 0, 0, &panel,
+ &dsi->next_bridge);
+ /* A drm_panel can have its own orientation. If there is no panel, set the
+ * orientation to NORMAL. */
+ if (ret || !panel) {
+ drm_connector_set_panel_orientation(
+ dsi->connector, DRM_MODE_PANEL_ORIENTATION_NORMAL);
+ }
+
return 0;
err_cleanup_encoder:
@@ -976,11 +987,8 @@ static int mtk_dsi_encoder_init(struct drm_device *drm, struct mtk_dsi *dsi)
static int mtk_dsi_bind(struct device *dev, struct device *master, void *data)
{
- int ret;
struct drm_device *drm = data;
- struct mtk_dsi *dsi = dev_get_drvdata(dev);
-
- ret = mtk_dsi_encoder_init(drm, dsi);
+ int ret = mtk_dsi_encoder_init(dev, drm);
if (ret)
return ret;
--
2.34.1.448.ga2b2bfdf31-goog
^ permalink raw reply related
* Re: [PATCH] submodule.h: use a named enum for RECURSE_SUBMODULES_*
From: Junio C Hamano @ 2022-01-05 21:20 UTC (permalink / raw)
To: Philippe Blain via GitGitGadget
Cc: git, Emily Shaffer, Glen Choo, Philippe Blain
In-Reply-To: <pull.1111.git.1641410782015.gitgitgadget@gmail.com>
"Philippe Blain via GitGitGadget" <gitgitgadget@gmail.com> writes:
> From: Philippe Blain <levraiphilippeblain@gmail.com>
>
> Using a named enum allows casting an integer to the enum type in both
> GDB and LLDB:
>
> (gdb) p (enum diff_submodule_format) options->submodule_format
> $1 = DIFF_SUBMODULE_LOG
Hmph, this was somewhat unexpected and quite disappointing.
Because that's not what those "Let's move away from #define'd
constants and use more enums" said when they sold their "enum" to
us. In the diff_options struct, the .submodule_format member is of
type enum already, so, if we trust what they told us when they sold
their enums, "p options->submodule_format" should be enough to give
us "DIFF_SUBMODULE_LOG", not "1", as its output. Do you really need
the cast in the above example?
> Name the enum listing the different RECURSE_SUBMODULES_* modes, to make
> debugging easier.
Even though this patch may be a good single step in the right
direction, until it is _used_ to declare a variable or a member of a
struct of that enum type, it probably is not useful as much as it
could be. The user needs to know which enum is stored in that "int"
variable or member the user is interested in to cast it to.
That is, many changes like this one.
diff --git i/builtin/pull.c w/builtin/pull.c
index c8457619d8..f2fd4784df 100644
--- i/builtin/pull.c
+++ w/builtin/pull.c
@@ -71,7 +71,7 @@ static const char * const pull_usage[] = {
/* Shared options */
static int opt_verbosity;
static char *opt_progress;
-static int recurse_submodules = RECURSE_SUBMODULES_DEFAULT;
+static enum submodule_recurse_mode recurse_submodules = RECURSE_SUBMODULES_DEFAULT;
/* Options passed to git-merge or git-rebase */
static enum rebase_type opt_rebase = -1;
^ permalink raw reply related
* Re: [PATCH v9 09/10] xfs: Implement ->notify_failure() for XFS
From: Dan Williams @ 2022-01-05 21:17 UTC (permalink / raw)
To: Darrick J. Wong
Cc: Shiyang Ruan, Linux Kernel Mailing List, linux-xfs, Linux NVDIMM,
Linux MM, linux-fsdevel, david, Christoph Hellwig, Jane Chu
In-Reply-To: <20220105185334.GD398655@magnolia>
On Wed, Jan 5, 2022 at 10:53 AM Darrick J. Wong <djwong@kernel.org> wrote:
>
> On Sun, Dec 26, 2021 at 10:34:38PM +0800, Shiyang Ruan wrote:
> > Introduce xfs_notify_failure.c to handle failure related works, such as
> > implement ->notify_failure(), register/unregister dax holder in xfs, and
> > so on.
> >
> > If the rmap feature of XFS enabled, we can query it to find files and
> > metadata which are associated with the corrupt data. For now all we do
> > is kill processes with that file mapped into their address spaces, but
> > future patches could actually do something about corrupt metadata.
> >
> > After that, the memory failure needs to notify the processes who are
> > using those files.
> >
> > Signed-off-by: Shiyang Ruan <ruansy.fnst@fujitsu.com>
> > ---
> > fs/xfs/Makefile | 1 +
> > fs/xfs/xfs_buf.c | 15 +++
> > fs/xfs/xfs_fsops.c | 3 +
> > fs/xfs/xfs_mount.h | 1 +
> > fs/xfs/xfs_notify_failure.c | 189 ++++++++++++++++++++++++++++++++++++
> > fs/xfs/xfs_notify_failure.h | 10 ++
> > 6 files changed, 219 insertions(+)
> > create mode 100644 fs/xfs/xfs_notify_failure.c
> > create mode 100644 fs/xfs/xfs_notify_failure.h
> >
> > diff --git a/fs/xfs/Makefile b/fs/xfs/Makefile
> > index 04611a1068b4..389970b3e13b 100644
> > --- a/fs/xfs/Makefile
> > +++ b/fs/xfs/Makefile
> > @@ -84,6 +84,7 @@ xfs-y += xfs_aops.o \
> > xfs_message.o \
> > xfs_mount.o \
> > xfs_mru_cache.o \
> > + xfs_notify_failure.o \
> > xfs_pwork.o \
> > xfs_reflink.o \
> > xfs_stats.o \
> > diff --git a/fs/xfs/xfs_buf.c b/fs/xfs/xfs_buf.c
> > index bbb0fbd34e64..d0df7604fa9e 100644
> > --- a/fs/xfs/xfs_buf.c
> > +++ b/fs/xfs/xfs_buf.c
> > @@ -19,6 +19,7 @@
> > #include "xfs_errortag.h"
> > #include "xfs_error.h"
> > #include "xfs_ag.h"
> > +#include "xfs_notify_failure.h"
> >
> > static struct kmem_cache *xfs_buf_cache;
> >
> > @@ -1892,6 +1893,8 @@ xfs_free_buftarg(
> > list_lru_destroy(&btp->bt_lru);
> >
> > blkdev_issue_flush(btp->bt_bdev);
> > + if (btp->bt_daxdev)
> > + dax_unregister_holder(btp->bt_daxdev);
> > fs_put_dax(btp->bt_daxdev);
> >
> > kmem_free(btp);
> > @@ -1946,6 +1949,18 @@ xfs_alloc_buftarg(
> > btp->bt_dev = bdev->bd_dev;
> > btp->bt_bdev = bdev;
> > btp->bt_daxdev = fs_dax_get_by_bdev(bdev, &btp->bt_dax_part_off);
> > + if (btp->bt_daxdev) {
> > + dax_write_lock(btp->bt_daxdev);
> > + if (dax_get_holder(btp->bt_daxdev)) {
> > + dax_write_unlock(btp->bt_daxdev);
> > + xfs_err(mp, "DAX device already in use?!");
> > + goto error_free;
> > + }
> > +
> > + dax_register_holder(btp->bt_daxdev, mp,
> > + &xfs_dax_holder_operations);
> > + dax_write_unlock(btp->bt_daxdev);
> > + }
> >
> > /*
> > * Buffer IO error rate limiting. Limit it to no more than 10 messages
> > diff --git a/fs/xfs/xfs_fsops.c b/fs/xfs/xfs_fsops.c
> > index 33e26690a8c4..d4d36c5bef11 100644
> > --- a/fs/xfs/xfs_fsops.c
> > +++ b/fs/xfs/xfs_fsops.c
> > @@ -542,6 +542,9 @@ xfs_do_force_shutdown(
> > } else if (flags & SHUTDOWN_CORRUPT_INCORE) {
> > tag = XFS_PTAG_SHUTDOWN_CORRUPT;
> > why = "Corruption of in-memory data";
> > + } else if (flags & SHUTDOWN_CORRUPT_ONDISK) {
> > + tag = XFS_PTAG_SHUTDOWN_CORRUPT;
> > + why = "Corruption of on-disk metadata";
> > } else {
> > tag = XFS_PTAG_SHUTDOWN_IOERROR;
> > why = "Metadata I/O Error";
> > diff --git a/fs/xfs/xfs_mount.h b/fs/xfs/xfs_mount.h
> > index 00720a02e761..47ff4ac53c4c 100644
> > --- a/fs/xfs/xfs_mount.h
> > +++ b/fs/xfs/xfs_mount.h
> > @@ -435,6 +435,7 @@ void xfs_do_force_shutdown(struct xfs_mount *mp, int flags, char *fname,
> > #define SHUTDOWN_LOG_IO_ERROR 0x0002 /* write attempt to the log failed */
> > #define SHUTDOWN_FORCE_UMOUNT 0x0004 /* shutdown from a forced unmount */
> > #define SHUTDOWN_CORRUPT_INCORE 0x0008 /* corrupt in-memory data structures */
> > +#define SHUTDOWN_CORRUPT_ONDISK 0x0010 /* corrupt metadata on device */
> >
> > #define XFS_SHUTDOWN_STRINGS \
> > { SHUTDOWN_META_IO_ERROR, "metadata_io" }, \
> > diff --git a/fs/xfs/xfs_notify_failure.c b/fs/xfs/xfs_notify_failure.c
> > new file mode 100644
> > index 000000000000..a87bd08365f4
> > --- /dev/null
> > +++ b/fs/xfs/xfs_notify_failure.c
> > @@ -0,0 +1,189 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/*
> > + * Copyright (c) 2021 Fujitsu. All Rights Reserved.
> > + */
> > +
> > +#include "xfs.h"
> > +#include "xfs_shared.h"
> > +#include "xfs_format.h"
> > +#include "xfs_log_format.h"
> > +#include "xfs_trans_resv.h"
> > +#include "xfs_mount.h"
> > +#include "xfs_alloc.h"
> > +#include "xfs_bit.h"
> > +#include "xfs_btree.h"
> > +#include "xfs_inode.h"
> > +#include "xfs_icache.h"
> > +#include "xfs_rmap.h"
> > +#include "xfs_rmap_btree.h"
> > +#include "xfs_rtalloc.h"
> > +#include "xfs_trans.h"
> > +
> > +#include <linux/mm.h>
> > +#include <linux/dax.h>
> > +
> > +struct failure_info {
> > + xfs_agblock_t startblock;
> > + xfs_filblks_t blockcount;
> > + int mf_flags;
>
> Why is blockcount a 64-bit quantity, when the failure information is
> dealt with on a per-AG basis? I think "xfs_extlen_t blockcount" should
> be large enough here. (I'll get back to this further down.)
>
> > +};
> > +
> > +static pgoff_t
> > +xfs_failure_pgoff(
> > + struct xfs_mount *mp,
> > + const struct xfs_rmap_irec *rec,
> > + const struct failure_info *notify)
> > +{
> > + uint64_t pos = rec->rm_offset;
>
> Nit: indenting ^^^^^ here.
>
> > +
> > + if (notify->startblock > rec->rm_startblock)
> > + pos += XFS_FSB_TO_B(mp,
> > + notify->startblock - rec->rm_startblock);
> > + return pos >> PAGE_SHIFT;
> > +}
> > +
> > +static unsigned long
> > +xfs_failure_pgcnt(
> > + struct xfs_mount *mp,
> > + const struct xfs_rmap_irec *rec,
> > + const struct failure_info *notify)
> > +{
> > + xfs_agblock_t start_rec = rec->rm_startblock;
> > + xfs_agblock_t end_rec = rec->rm_startblock + rec->rm_blockcount;
> > + xfs_agblock_t start_notify = notify->startblock;
> > + xfs_agblock_t end_notify = notify->startblock + notify->blockcount;
> > + xfs_agblock_t start_cross = max(start_rec, start_notify);
> > + xfs_agblock_t end_cross = min(end_rec, end_notify);
>
> Indenting and rather more local variables than we need?
>
> static unsigned long
> xfs_failure_pgcnt(
> struct xfs_mount *mp,
> const struct xfs_rmap_irec *rec,
> const struct failure_info *notify)
> {
> xfs_agblock_t end_rec;
> xfs_agblock_t end_notify;
> xfs_agblock_t start_cross;
> xfs_agblock_t end_cross;
>
> start_cross = max(rec->rm_startblock, notify->startblock);
>
> end_rec = rec->rm_startblock + rec->rm_blockcount;
> end_notify = notify->startblock + notify->blockcount;
> end_cross = min(end_rec, end_notify);
>
> return XFS_FSB_TO_B(mp, end_cross - start_cross) >> PAGE_SHIFT;
> }
>
> > +
> > + return XFS_FSB_TO_B(mp, end_cross - start_cross) >> PAGE_SHIFT;
> > +}
> > +
> > +static int
> > +xfs_dax_failure_fn(
> > + struct xfs_btree_cur *cur,
> > + const struct xfs_rmap_irec *rec,
> > + void *data)
> > +{
> > + struct xfs_mount *mp = cur->bc_mp;
> > + struct xfs_inode *ip;
> > + struct address_space *mapping;
> > + struct failure_info *notify = data;
> > + int error = 0;
> > +
> > + if (XFS_RMAP_NON_INODE_OWNER(rec->rm_owner) ||
> > + (rec->rm_flags & (XFS_RMAP_ATTR_FORK | XFS_RMAP_BMBT_BLOCK))) {
> > + /* TODO check and try to fix metadata */
> > + xfs_force_shutdown(mp, SHUTDOWN_CORRUPT_ONDISK);
> > + return -EFSCORRUPTED;
> > + }
> > +
> > + /* Get files that incore, filter out others that are not in use. */
> > + error = xfs_iget(mp, cur->bc_tp, rec->rm_owner, XFS_IGET_INCORE,
> > + 0, &ip);
> > + /* Continue the rmap query if the inode isn't incore */
> > + if (error == -ENODATA)
> > + return 0;
> > + if (error)
> > + return error;
> > +
> > + mapping = VFS_I(ip)->i_mapping;
> > + if (IS_ENABLED(CONFIG_MEMORY_FAILURE)) {
>
> Is there a situation where we can receive media failure notices from DAX
> but CONFIG_MEMORY_FAILURE is not enabled? (I think the answer is yes?)
Good catch, yes, I was planning to reuse this notification
infrastructure for the "whoops you ripped out your CXL card that was
being used with FSDAX" case. Although, if someone builds the kernel
with CONFIG_MEMORY_FAILURE=n then I think a lack of notification for
that case is to be expected? Perhaps CONFIG_FSDAX should just depend
on CONFIG_MEMORY_FAILURE when that "hot remove" failure case is added.
For now, CONFIG_MEMORY_FAILURE is the only source of errors.
>
> > + pgoff_t off = xfs_failure_pgoff(mp, rec, notify);
> > + unsigned long cnt = xfs_failure_pgcnt(mp, rec, notify);
> > +
> > + error = mf_dax_kill_procs(mapping, off, cnt, notify->mf_flags);
> > + }
>
> If so, then we ought to do /something/ besides silently dropping the
> error, right? Even if that something is rudely shutting down the fs,
> like we do for attr/bmbt mappings above?
>
> What I'm getting at is that I think this function should be:
>
> #if IS_ENABLED(CONFIG_MEMORY_FAILURE)
> static int
> xfs_dax_failure_fn(
> struct xfs_btree_cur *cur,
> const struct xfs_rmap_irec *rec,
> void *data)
> {
> /* shut down if attr/bmbt record like above */
>
> error = xfs_iget(...);
> if (error == -ENODATA)
> return 0;
> if (error)
> return error;
>
> off = xfs_failure_pgoff(mp, rec, notify);
> cnt = xfs_failure_pgcnt(mp, rec, notify);
>
> error = mf_dax_kill_procs(mapping, off, cnt, notify->mf_flags);
> xfs_irele(ip);
> return error;
> }
> #else
> static int
> xfs_dax_failure_fn(
> struct xfs_btree_cur *cur,
> const struct xfs_rmap_irec *rec,
> void *data)
> {
> /* No other option besides shutting down the fs. */
> xfs_force_shutdown(mp, SHUTDOWN_CORRUPT_ONDISK);
> return -EFSCORRUPTED;
> }
> #endif /* CONFIG_MEMORY_FAILURE */
Oh, yeah that makes sense to me.
^ permalink raw reply
* Re: [PATCH V7 19/29] vfio-pci: cpr part 1 (fd and dma)
From: Michael S. Tsirkin @ 2022-01-05 21:14 UTC (permalink / raw)
To: Steven Sistare
Cc: Daniel P. Berrange, Juan Quintela, Jason Zeng, Alex Bennée,
qemu-devel, Eric Blake, Dr. David Alan Gilbert, Zheng Chuan,
Alex Williamson, Stefan Hajnoczi, Marc-André Lureau,
Paolo Bonzini, Philippe Mathieu-Daudé, Markus Armbruster
In-Reply-To: <f1cadf51-795b-200c-8abb-f8f97b34c228@oracle.com>
On Wed, Jan 05, 2022 at 12:24:21PM -0500, Steven Sistare wrote:
> On 12/22/2021 6:15 PM, Michael S. Tsirkin wrote:
> > On Wed, Dec 22, 2021 at 11:05:24AM -0800, Steve Sistare wrote:
> >> Enable vfio-pci devices to be saved and restored across an exec restart
> >> of qemu.
> >>
> >> At vfio creation time, save the value of vfio container, group, and device
> >> descriptors in cpr state.
> >>
> >> In cpr-save and cpr-exec, suspend the use of virtual addresses in DMA
> >> mappings with VFIO_DMA_UNMAP_FLAG_VADDR, because guest ram will be remapped
> >> at a different VA after exec. DMA to already-mapped pages continues. Save
> >> the msi message area as part of vfio-pci vmstate, save the interrupt and
> >> notifier eventfd's in cpr state, and clear the close-on-exec flag for the
> >> vfio descriptors. The flag is not cleared earlier because the descriptors
> >> should not persist across miscellaneous fork and exec calls that may be
> >> performed during normal operation.
> >>
> >> On qemu restart, vfio_realize() finds the saved descriptors, uses
> >> the descriptors, and notes that the device is being reused. Device and
> >> iommu state is already configured, so operations in vfio_realize that
> >> would modify the configuration are skipped for a reused device, including
> >> vfio ioctl's and writes to PCI configuration space. The result is that
> >> vfio_realize constructs qemu data structures that reflect the current
> >> state of the device. However, the reconstruction is not complete until
> >> cpr-load is called. cpr-load loads the msi data and finds eventfds in cpr
> >> state. It rebuilds vector data structures and attaches the interrupts to
> >> the new KVM instance. cpr-load then invokes the main vfio listener callback,
> >> which walks the flattened ranges of the vfio_address_spaces and calls
> >> VFIO_DMA_MAP_FLAG_VADDR to inform the kernel of the new VA's. Lastly, it
> >> starts the VM and suppresses vfio pci device reset.
> >>
> >> This functionality is delivered by 3 patches for clarity. Part 1 handles
> >> device file descriptors and DMA. Part 2 adds eventfd and MSI/MSI-X vector
> >> support. Part 3 adds INTX support.
> >>
> >> Signed-off-by: Steve Sistare <steven.sistare@oracle.com>
> >> ---
> >> MAINTAINERS | 1 +
> >> hw/pci/pci.c | 10 ++++
> >> hw/vfio/common.c | 115 ++++++++++++++++++++++++++++++++++++++----
> >> hw/vfio/cpr.c | 94 ++++++++++++++++++++++++++++++++++
> >> hw/vfio/meson.build | 1 +
> >> hw/vfio/pci.c | 77 ++++++++++++++++++++++++++++
> >> hw/vfio/trace-events | 1 +
> >> include/hw/pci/pci.h | 1 +
> >> include/hw/vfio/vfio-common.h | 8 +++
> >> include/migration/cpr.h | 3 ++
> >> migration/cpr.c | 10 +++-
> >> migration/target.c | 14 +++++
> >> 12 files changed, 324 insertions(+), 11 deletions(-)
> >> create mode 100644 hw/vfio/cpr.c
> >>
> >> diff --git a/MAINTAINERS b/MAINTAINERS
> >> index cfe7480..feed239 100644
> >> --- a/MAINTAINERS
> >> +++ b/MAINTAINERS
> >> @@ -2992,6 +2992,7 @@ CPR
> >> M: Steve Sistare <steven.sistare@oracle.com>
> >> M: Mark Kanda <mark.kanda@oracle.com>
> >> S: Maintained
> >> +F: hw/vfio/cpr.c
> >> F: include/migration/cpr.h
> >> F: migration/cpr.c
> >> F: qapi/cpr.json
> >> diff --git a/hw/pci/pci.c b/hw/pci/pci.c
> >> index 0fd21e1..e35df4f 100644
> >> --- a/hw/pci/pci.c
> >> +++ b/hw/pci/pci.c
> >> @@ -307,6 +307,16 @@ static void pci_do_device_reset(PCIDevice *dev)
> >> {
> >> int r;
> >>
> >> + /*
> >> + * A reused vfio-pci device is already configured, so do not reset it
> >> + * during qemu_system_reset prior to cpr-load, else interrupts may be
> >> + * lost. By contrast, pure-virtual pci devices may be reset here and
> >> + * updated with new state in cpr-load with no ill effects.
> >> + */
> >> + if (dev->reused) {
> >> + return;
> >> + }
> >> +
> >> pci_device_deassert_intx(dev);
> >> assert(dev->irq_state == 0);
> >>
> >
> >
> > Hmm that's a weird thing to do. I suspect this works because
> > "reused" means something like "in the process of being restored"?
> > Because clearly, we do not want to skip this part e.g. when
> > guest resets the device.
>
> Exactly. vfio_realize sets the flag if it detects the device is reused during
> a restart, and vfio_pci_post_load clears the reused flag.
>
> > So a better name could be called for, but really I don't
> > love how vfio gets to poke at internal PCI state.
> > I'd rather we found a way just not to call this function.
> > If we can't, maybe an explicit API, and make it
> > actually say what it's doing?
>
> How about:
>
> pci_set_restore(PCIDevice *dev) { dev->restore = true; }
> pci_clr_restore(PCIDevice *dev) { dev->restore = false; }
>
> vfio_realize()
> pci_set_restore(pdev)
>
> vfio_pci_post_load()
> pci_clr_restore(pdev)
>
> pci_do_device_reset()
> if (dev->restore)
> return;
>
> - Steve
Not too bad. I'd like a better definition of what dev->restore is
exactly and to add them in comments near where it
is defined and used.
E.g. does this mean "device is being restored because of qemu restart"?
Do we need a per device flag for this thing or would a global
"qemu restart in progress" flag be enough?
--
MST
^ permalink raw reply
* Re: [PATCH] drm/msm/dp: stop link training after link training 2 failed
From: Stephen Boyd @ 2022-01-05 21:16 UTC (permalink / raw)
To: Kuogee Hsieh, agross, airlied, bjorn.andersson, daniel,
dmitry.baryshkov, robdclark, sean, vkoul
Cc: quic_abhinavk, aravindh, quic_sbillaka, freedreno, dri-devel,
linux-arm-msm, linux-kernel
In-Reply-To: <1641340327-2261-1-git-send-email-quic_khsieh@quicinc.com>
Quoting Kuogee Hsieh (2022-01-04 15:52:07)
> Each DP link training contains link training 1 followed by link
> training 2. There is maximum of 5 retries of DP link training
> before declared link training failed. It is required to stop link
> training at end of link training 2 if it is failed so that next
> link training 1 can start freshly. This patch fixes link compliance
> test case 4.3.1.13 (Source Device Link Training EQ Fallback Test).
>
> Fixes: 2e0adc765d88 ("drm/msm/dp: do not end dp link training until video is ready")
> Signed-off-by: Kuogee Hsieh <quic_khsieh@quicinc.com>
> ---
Reviewed-by: Stephen Boyd <swboyd@chromium.org>
^ permalink raw reply
* Re: [PATCH] drm/msm/dp: stop link training after link training 2 failed
From: Stephen Boyd @ 2022-01-05 21:16 UTC (permalink / raw)
To: Kuogee Hsieh, agross, airlied, bjorn.andersson, daniel,
dmitry.baryshkov, robdclark, sean, vkoul
Cc: quic_sbillaka, linux-arm-msm, quic_abhinavk, dri-devel,
linux-kernel, aravindh, freedreno
In-Reply-To: <1641340327-2261-1-git-send-email-quic_khsieh@quicinc.com>
Quoting Kuogee Hsieh (2022-01-04 15:52:07)
> Each DP link training contains link training 1 followed by link
> training 2. There is maximum of 5 retries of DP link training
> before declared link training failed. It is required to stop link
> training at end of link training 2 if it is failed so that next
> link training 1 can start freshly. This patch fixes link compliance
> test case 4.3.1.13 (Source Device Link Training EQ Fallback Test).
>
> Fixes: 2e0adc765d88 ("drm/msm/dp: do not end dp link training until video is ready")
> Signed-off-by: Kuogee Hsieh <quic_khsieh@quicinc.com>
> ---
Reviewed-by: Stephen Boyd <swboyd@chromium.org>
^ permalink raw reply
* ReleaseNotes for 0.6.4: one year off
From: Bernhard Voelker @ 2022-01-05 21:16 UTC (permalink / raw)
To: linux-sparse
https://sparse.docs.kernel.org/en/latest/release-notes/v0.6.4.html
says that the release was 2020-09-06, while it was 2021-09-06.
This also looks a bit odd in the Release Notes menue item in the navigation of the home page:
https://sparse.docs.kernel.org/en/latest/release-notes/index.html
Release Notes
v0.6.4 (2020-09-06)
v0.6.3 (2020-10-17)
v0.6.2 (2020-06-21)
...
Have a nice day,
Berny
^ permalink raw reply
* [PATCH 1/3] libsepol/cil: Do not copy blockabstracts when inheriting a block
From: James Carter @ 2022-01-05 21:16 UTC (permalink / raw)
To: selinux; +Cc: James Carter
Do not copy any blockabstract statements when copying a block to
resolve a blockinherit statement. Inheriting a block from what was
just inherited does not work, so there is no reason to create an
abstract block.
Signed-off-by: James Carter <jwcart2@gmail.com>
---
libsepol/cil/src/cil_copy_ast.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/libsepol/cil/src/cil_copy_ast.c b/libsepol/cil/src/cil_copy_ast.c
index 2fad972c..a4ead9db 100644
--- a/libsepol/cil/src/cil_copy_ast.c
+++ b/libsepol/cil/src/cil_copy_ast.c
@@ -1725,6 +1725,12 @@ int __cil_copy_node_helper(struct cil_tree_node *orig, uint32_t *finished, void
copy_func = &cil_copy_block;
break;
case CIL_BLOCKABSTRACT:
+ if (args->orig_dest->flavor == CIL_BLOCKINHERIT) {
+ /* When inheriting a block, don't copy any blockabstract
+ * statements. Inheriting a block from a block that was
+ * just inherited never worked. */
+ return SEPOL_OK;
+ }
copy_func = &cil_copy_blockabstract;
break;
case CIL_BLOCKINHERIT:
--
2.31.1
^ permalink raw reply related
* [PATCH 3/3] libsepol/cil: Do not resolve names to declarations in abstract blocks
From: James Carter @ 2022-01-05 21:16 UTC (permalink / raw)
To: selinux; +Cc: James Carter
In-Reply-To: <20220105211602.359300-1-jwcart2@gmail.com>
Since abstract blocks will not appear in the final policy, do not
resolve names to a declaration inside one.
When resolving blockabstract rules, they must be collected in a list
and processed at the end of the pass because if a parent block is
marked as abstract, then a blockabstract rule for a sub-block will
fail to resolve.
Found by oss-fuzz (#42981)
Signed-off-by: James Carter <jwcart2@gmail.com>
---
libsepol/cil/src/cil_resolve_ast.c | 24 ++++++++++++++++++++----
1 file changed, 20 insertions(+), 4 deletions(-)
diff --git a/libsepol/cil/src/cil_resolve_ast.c b/libsepol/cil/src/cil_resolve_ast.c
index 0288b7dc..73115c55 100644
--- a/libsepol/cil/src/cil_resolve_ast.c
+++ b/libsepol/cil/src/cil_resolve_ast.c
@@ -65,6 +65,7 @@ struct cil_args_resolve {
struct cil_list *sensitivityorder_lists;
struct cil_list *in_list_before;
struct cil_list *in_list_after;
+ struct cil_list *abstract_blocks;
};
static struct cil_name * __cil_insert_name(struct cil_db *db, hashtab_key_t key, struct cil_tree_node *ast_node)
@@ -2397,6 +2398,7 @@ int cil_resolve_blockabstract(struct cil_tree_node *current, void *extra_args)
struct cil_blockabstract *abstract = current->data;
struct cil_symtab_datum *block_datum = NULL;
struct cil_tree_node *block_node = NULL;
+ struct cil_args_resolve *args = extra_args;
int rc = SEPOL_ERR;
rc = cil_resolve_name(current, abstract->block_str, CIL_SYM_BLOCKS, extra_args, &block_datum);
@@ -2411,7 +2413,7 @@ int cil_resolve_blockabstract(struct cil_tree_node *current, void *extra_args)
goto exit;
}
- cil_mark_subtree_abstract(block_node);
+ cil_list_append(args->abstract_blocks, CIL_NODE, block_node);
return SEPOL_OK;
@@ -4097,6 +4099,7 @@ int cil_resolve_ast(struct cil_db *db, struct cil_tree_node *current)
extra_args.sensitivityorder_lists = NULL;
extra_args.in_list_before = NULL;
extra_args.in_list_after = NULL;
+ extra_args.abstract_blocks = NULL;
cil_list_init(&extra_args.to_destroy, CIL_NODE);
cil_list_init(&extra_args.sidorder_lists, CIL_LIST_ITEM);
@@ -4106,6 +4109,7 @@ int cil_resolve_ast(struct cil_db *db, struct cil_tree_node *current)
cil_list_init(&extra_args.sensitivityorder_lists, CIL_LIST_ITEM);
cil_list_init(&extra_args.in_list_before, CIL_IN);
cil_list_init(&extra_args.in_list_after, CIL_IN);
+ cil_list_init(&extra_args.abstract_blocks, CIL_NODE);
for (pass = CIL_PASS_TIF; pass < CIL_PASS_NUM; pass++) {
extra_args.pass = pass;
@@ -4129,6 +4133,13 @@ int cil_resolve_ast(struct cil_db *db, struct cil_tree_node *current)
cil_list_destroy(&extra_args.in_list_after, CIL_FALSE);
}
+ if (pass == CIL_PASS_BLKABS) {
+ struct cil_list_item *item;
+ cil_list_for_each(item, extra_args.abstract_blocks) {
+ cil_mark_subtree_abstract(item->data);
+ }
+ }
+
if (pass == CIL_PASS_BLKIN_LINK) {
rc = cil_check_for_bad_inheritance(current);
if (rc != SEPOL_OK) {
@@ -4247,6 +4258,7 @@ exit:
cil_list_destroy(&extra_args.to_destroy, CIL_FALSE);
cil_list_destroy(&extra_args.in_list_before, CIL_FALSE);
cil_list_destroy(&extra_args.in_list_after, CIL_FALSE);
+ cil_list_destroy(&extra_args.abstract_blocks, CIL_FALSE);
return rc;
}
@@ -4268,9 +4280,13 @@ static int __cil_resolve_name_with_parents(struct cil_tree_node *node, char *nam
case CIL_ROOT:
goto exit;
break;
- case CIL_BLOCK:
- symtab = &((struct cil_block*)node->data)->symtab[sym_index];
- rc = cil_symtab_get_datum(symtab, name, datum);
+ case CIL_BLOCK: {
+ struct cil_block *block = node->data;
+ if (!block->is_abstract) {
+ symtab = &block->symtab[sym_index];
+ rc = cil_symtab_get_datum(symtab, name, datum);
+ }
+ }
break;
case CIL_BLOCKINHERIT: {
struct cil_blockinherit *inherit = node->data;
--
2.31.1
^ permalink raw reply related
* [PATCH 2/3] libsepol/cil: Mark as abstract all sub-blocks of an abstract block
From: James Carter @ 2022-01-05 21:16 UTC (permalink / raw)
To: selinux; +Cc: James Carter
In-Reply-To: <20220105211602.359300-1-jwcart2@gmail.com>
If a block is marked as abstract, then it will be skipped during
every pass after blockabstracts are resolved (only tunables,
in-befores, and blockinherits are before blockabstracts), so mark
all of its sub-blocks as abstract to reflect their actual status.
Signed-off-by: James Carter <jwcart2@gmail.com>
---
libsepol/cil/src/cil_resolve_ast.c | 15 ++++++++++++++-
1 file changed, 14 insertions(+), 1 deletion(-)
diff --git a/libsepol/cil/src/cil_resolve_ast.c b/libsepol/cil/src/cil_resolve_ast.c
index e97a9f46..0288b7dc 100644
--- a/libsepol/cil/src/cil_resolve_ast.c
+++ b/libsepol/cil/src/cil_resolve_ast.c
@@ -2379,6 +2379,19 @@ exit:
return rc;
}
+static void cil_mark_subtree_abstract(struct cil_tree_node *node)
+{
+ struct cil_block *block = node->data;
+
+ block->is_abstract = CIL_TRUE;
+
+ for (node = node->cl_head; node; node = node->next) {
+ if (node->flavor == CIL_BLOCK) {
+ cil_mark_subtree_abstract(node);
+ }
+ }
+}
+
int cil_resolve_blockabstract(struct cil_tree_node *current, void *extra_args)
{
struct cil_blockabstract *abstract = current->data;
@@ -2398,7 +2411,7 @@ int cil_resolve_blockabstract(struct cil_tree_node *current, void *extra_args)
goto exit;
}
- ((struct cil_block*)block_datum)->is_abstract = CIL_TRUE;
+ cil_mark_subtree_abstract(block_node);
return SEPOL_OK;
--
2.31.1
^ permalink raw reply related
* Re: [meta-arm] building gcc-arm-none-eabi from source
From: Alexander Kanavin @ 2022-01-05 21:14 UTC (permalink / raw)
To: Richard Purdie; +Cc: meta-arm, Stefan Herbrechtsmeier
In-Reply-To: <283cdfc898038fee9465d4f24bd0113ec712dbb1.camel@linuxfoundation.org>
[-- Attachment #1: Type: text/plain, Size: 1129 bytes --]
On Tue, 4 Jan 2022 at 10:24, Richard Purdie <
richard.purdie@linuxfoundation.org> wrote:
> It is true that you'd need a different target variant for the second
> option I
> mentioned.
>
> I did have something slightly similar with extensions to the gcc/binutils
> recipes for a cross AVR toolchain that runs on an arm target. I found some
> copies here, based on daisy which whilst old, gives the idea:
>
>
> https://git.yoctoproject.org/poky-contrib/commit/?h=rpurdie/daisy&id=f58f90257a5af3e6b6974090e62cad9d90d53ae5
>
> I definitely have something more recent locally too (pyro, can't remember
> if I
> made it to dunfell with that code), I can dig that out if it is
> interesting. I
> thought somewhere I had a BBCLASSEXTEND recipe which added multiple cross
> compiler arches on target but I can't find that one :/.
>
After poking at the vendor toolchain a bit, I don't think building that
from source is a great option either. Perhaps the best solution is to use
the mcextend class to do the needed tweaks directly inside the binutils/gcc
recipes (or as bbappends in meta-arm perhaps). Does that sound about right?
Alex
[-- Attachment #2: Type: text/html, Size: 1712 bytes --]
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.