* Re: [RFC PATCH 0/5] Removing support for 32bit KVM/arm host
From: Marek Szyprowski @ 2020-02-20 12:44 UTC (permalink / raw)
To: Marc Zyngier, linux-arm-kernel, kvmarm, kvm
Cc: Anders Berg, Vladimir Murzin, Russell King, Arnd Bergmann,
Quentin Perret, Suzuki K Poulose, Christoffer Dall,
Krzysztof Kozlowski, Bartlomiej Zolnierkiewicz, James Morse,
Paolo Bonzini, Will Deacon, Julien Thierry
In-Reply-To: <20200210141324.21090-1-maz@kernel.org>
Hi Marc,
On 10.02.2020 15:13, Marc Zyngier wrote:
> KVM/arm was merged just over 7 years ago, and has lived a very quiet
> life so far. It mostly works if you're prepared to deal with its
> limitations, it has been a good prototype for the arm64 version,
> but it suffers a few problems:
>
> - It is incomplete (no debug support, no PMU)
> - It hasn't followed any of the architectural evolutions
> - It has zero users (I don't count myself here)
> - It is more and more getting in the way of new arm64 developments
That is a bit sad information. Mainline Exynos finally got everything
that was needed to run it on the quite popular Samsung Exynos5422-based
Odroid XU4/HC1/MC1 boards. According to the Odroid related forums it is
being used. We also use it internally at Samsung.
> So here it is: unless someone screams and shows that they rely on
> KVM/arm to be maintained upsteam, I'll remove 32bit host support
> form the tree. One of the reasons that makes me confident nobody is
> using it is that I never receive *any* bug report. Yes, it is perfect.
> But if you depend on KVM/arm being available in mainline, please shout.
>
> To reiterate: 32bit guest support for arm64 stays, of course. Only
> 32bit host goes. Once this is merged, I plan to move virt/kvm/arm to
> arm64, and cleanup all the now unnecessary abstractions.
>
> The patches have been generated with the -D option to avoid spamming
> everyone with huge diffs, and there is a kvm-arm/goodbye branch in
> my kernel.org repository.
>
> Marc Zyngier (5):
> arm: Unplug KVM from the build system
> arm: Remove KVM from config files
> arm: Remove 32bit KVM host support
> arm: Remove HYP/Stage-2 page-table support
> arm: Remove GICv3 vgic compatibility macros
>
> Documentation/virt/kvm/arm/hyp-abi.txt | 5 +
> arch/arm/Kconfig | 2 -
> arch/arm/Makefile | 1 -
> arch/arm/configs/axm55xx_defconfig | 2 -
> arch/arm/include/asm/arch_gicv3.h | 114 --
> arch/arm/include/asm/kvm_arm.h | 239 ----
> arch/arm/include/asm/kvm_asm.h | 77 --
> arch/arm/include/asm/kvm_coproc.h | 36 -
> arch/arm/include/asm/kvm_emulate.h | 372 ------
> arch/arm/include/asm/kvm_host.h | 459 --------
> arch/arm/include/asm/kvm_hyp.h | 127 ---
> arch/arm/include/asm/kvm_mmu.h | 435 -------
> arch/arm/include/asm/kvm_ras.h | 14 -
> arch/arm/include/asm/pgtable-3level.h | 20 -
> arch/arm/include/asm/pgtable.h | 9 -
> arch/arm/include/asm/sections.h | 6 +-
> arch/arm/include/asm/stage2_pgtable.h | 75 --
> arch/arm/include/asm/virt.h | 12 -
> arch/arm/include/uapi/asm/kvm.h | 314 -----
> arch/arm/kernel/asm-offsets.c | 11 -
> arch/arm/kernel/vmlinux-xip.lds.S | 8 -
> arch/arm/kernel/vmlinux.lds.S | 8 -
> arch/arm/kernel/vmlinux.lds.h | 10 -
> arch/arm/kvm/Kconfig | 59 -
> arch/arm/kvm/Makefile | 43 -
> arch/arm/kvm/coproc.c | 1455 ------------------------
> arch/arm/kvm/coproc.h | 130 ---
> arch/arm/kvm/coproc_a15.c | 39 -
> arch/arm/kvm/coproc_a7.c | 42 -
> arch/arm/kvm/emulate.c | 166 ---
> arch/arm/kvm/guest.c | 387 -------
> arch/arm/kvm/handle_exit.c | 175 ---
> arch/arm/kvm/hyp/Makefile | 34 -
> arch/arm/kvm/hyp/banked-sr.c | 70 --
> arch/arm/kvm/hyp/cp15-sr.c | 72 --
> arch/arm/kvm/hyp/entry.S | 121 --
> arch/arm/kvm/hyp/hyp-entry.S | 295 -----
> arch/arm/kvm/hyp/s2-setup.c | 22 -
> arch/arm/kvm/hyp/switch.c | 242 ----
> arch/arm/kvm/hyp/tlb.c | 68 --
> arch/arm/kvm/hyp/vfp.S | 57 -
> arch/arm/kvm/init.S | 157 ---
> arch/arm/kvm/interrupts.S | 36 -
> arch/arm/kvm/irq.h | 16 -
> arch/arm/kvm/reset.c | 86 --
> arch/arm/kvm/trace.h | 86 --
> arch/arm/kvm/vgic-v3-coproc.c | 27 -
> arch/arm/mach-exynos/Kconfig | 2 +-
> arch/arm/mm/mmu.c | 26 -
> 49 files changed, 7 insertions(+), 6262 deletions(-)
> delete mode 100644 arch/arm/include/asm/kvm_arm.h
> delete mode 100644 arch/arm/include/asm/kvm_asm.h
> delete mode 100644 arch/arm/include/asm/kvm_coproc.h
> delete mode 100644 arch/arm/include/asm/kvm_emulate.h
> delete mode 100644 arch/arm/include/asm/kvm_host.h
> delete mode 100644 arch/arm/include/asm/kvm_hyp.h
> delete mode 100644 arch/arm/include/asm/kvm_mmu.h
> delete mode 100644 arch/arm/include/asm/kvm_ras.h
> delete mode 100644 arch/arm/include/asm/stage2_pgtable.h
> delete mode 100644 arch/arm/include/uapi/asm/kvm.h
> delete mode 100644 arch/arm/kvm/Kconfig
> delete mode 100644 arch/arm/kvm/Makefile
> delete mode 100644 arch/arm/kvm/coproc.c
> delete mode 100644 arch/arm/kvm/coproc.h
> delete mode 100644 arch/arm/kvm/coproc_a15.c
> delete mode 100644 arch/arm/kvm/coproc_a7.c
> delete mode 100644 arch/arm/kvm/emulate.c
> delete mode 100644 arch/arm/kvm/guest.c
> delete mode 100644 arch/arm/kvm/handle_exit.c
> delete mode 100644 arch/arm/kvm/hyp/Makefile
> delete mode 100644 arch/arm/kvm/hyp/banked-sr.c
> delete mode 100644 arch/arm/kvm/hyp/cp15-sr.c
> delete mode 100644 arch/arm/kvm/hyp/entry.S
> delete mode 100644 arch/arm/kvm/hyp/hyp-entry.S
> delete mode 100644 arch/arm/kvm/hyp/s2-setup.c
> delete mode 100644 arch/arm/kvm/hyp/switch.c
> delete mode 100644 arch/arm/kvm/hyp/tlb.c
> delete mode 100644 arch/arm/kvm/hyp/vfp.S
> delete mode 100644 arch/arm/kvm/init.S
> delete mode 100644 arch/arm/kvm/interrupts.S
> delete mode 100644 arch/arm/kvm/irq.h
> delete mode 100644 arch/arm/kvm/reset.c
> delete mode 100644 arch/arm/kvm/trace.h
> delete mode 100644 arch/arm/kvm/vgic-v3-coproc.c
>
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [dpdk-dev] [PATCH] doc/mlx5: clarify memory write combining attribute
From: Viacheslav Ovsiienko @ 2020-02-20 12:44 UTC (permalink / raw)
To: dev; +Cc: matan, rasland, orika
Just add the words about write combining attribute.
Signed-off-by: Viacheslav Ovsiienko <viacheslavo@mellanox.com>
---
doc/guides/nics/mlx5.rst | 9 +++++----
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/doc/guides/nics/mlx5.rst b/doc/guides/nics/mlx5.rst
index 5ab7c07..dd2fbde 100644
--- a/doc/guides/nics/mlx5.rst
+++ b/doc/guides/nics/mlx5.rst
@@ -568,16 +568,17 @@ Run-time configuration
The rdma core library can map doorbell register in two ways, depending on the
environment variable "MLX5_SHUT_UP_BF":
- - As regular cached memory, if the variable is either missing or set to zero.
+ - As regular cached memory (usually with write combining attribute), if the
+ variable is either missing or set to zero.
- As non-cached memory, if the variable is present and set to not "0" value.
The type of mapping may slightly affect the Tx performance, the optimal choice
is strongly relied on the host architecture and should be deduced practically.
If ``tx_db_nc`` is set to zero, the doorbell is forced to be mapped to regular
- memory, the PMD will perform the extra write memory barrier after writing to
- doorbell, it might increase the needed CPU clocks per packet to send, but
- latency might be improved.
+ memory (with write combining), the PMD will perform the extra write memory barrier
+ after writing to doorbell, it might increase the needed CPU clocks per packet
+ to send, but latency might be improved.
If ``tx_db_nc`` is set to one, the doorbell is forced to be mapped to non
cached memory, the PMD will not perform the extra write memory barrier
--
1.8.3.1
^ permalink raw reply related
* Re: [RFC PATCH 0/5] Removing support for 32bit KVM/arm host
From: Marek Szyprowski @ 2020-02-20 12:44 UTC (permalink / raw)
To: Marc Zyngier, linux-arm-kernel, kvmarm, kvm
Cc: Anders Berg, Vladimir Murzin, Russell King, Arnd Bergmann,
Suzuki K Poulose, Quentin Perret, Christoffer Dall, James Morse,
Paolo Bonzini, Will Deacon, Julien Thierry, Krzysztof Kozlowski,
Bartlomiej Zolnierkiewicz
In-Reply-To: <20200210141324.21090-1-maz@kernel.org>
Hi Marc,
On 10.02.2020 15:13, Marc Zyngier wrote:
> KVM/arm was merged just over 7 years ago, and has lived a very quiet
> life so far. It mostly works if you're prepared to deal with its
> limitations, it has been a good prototype for the arm64 version,
> but it suffers a few problems:
>
> - It is incomplete (no debug support, no PMU)
> - It hasn't followed any of the architectural evolutions
> - It has zero users (I don't count myself here)
> - It is more and more getting in the way of new arm64 developments
That is a bit sad information. Mainline Exynos finally got everything
that was needed to run it on the quite popular Samsung Exynos5422-based
Odroid XU4/HC1/MC1 boards. According to the Odroid related forums it is
being used. We also use it internally at Samsung.
> So here it is: unless someone screams and shows that they rely on
> KVM/arm to be maintained upsteam, I'll remove 32bit host support
> form the tree. One of the reasons that makes me confident nobody is
> using it is that I never receive *any* bug report. Yes, it is perfect.
> But if you depend on KVM/arm being available in mainline, please shout.
>
> To reiterate: 32bit guest support for arm64 stays, of course. Only
> 32bit host goes. Once this is merged, I plan to move virt/kvm/arm to
> arm64, and cleanup all the now unnecessary abstractions.
>
> The patches have been generated with the -D option to avoid spamming
> everyone with huge diffs, and there is a kvm-arm/goodbye branch in
> my kernel.org repository.
>
> Marc Zyngier (5):
> arm: Unplug KVM from the build system
> arm: Remove KVM from config files
> arm: Remove 32bit KVM host support
> arm: Remove HYP/Stage-2 page-table support
> arm: Remove GICv3 vgic compatibility macros
>
> Documentation/virt/kvm/arm/hyp-abi.txt | 5 +
> arch/arm/Kconfig | 2 -
> arch/arm/Makefile | 1 -
> arch/arm/configs/axm55xx_defconfig | 2 -
> arch/arm/include/asm/arch_gicv3.h | 114 --
> arch/arm/include/asm/kvm_arm.h | 239 ----
> arch/arm/include/asm/kvm_asm.h | 77 --
> arch/arm/include/asm/kvm_coproc.h | 36 -
> arch/arm/include/asm/kvm_emulate.h | 372 ------
> arch/arm/include/asm/kvm_host.h | 459 --------
> arch/arm/include/asm/kvm_hyp.h | 127 ---
> arch/arm/include/asm/kvm_mmu.h | 435 -------
> arch/arm/include/asm/kvm_ras.h | 14 -
> arch/arm/include/asm/pgtable-3level.h | 20 -
> arch/arm/include/asm/pgtable.h | 9 -
> arch/arm/include/asm/sections.h | 6 +-
> arch/arm/include/asm/stage2_pgtable.h | 75 --
> arch/arm/include/asm/virt.h | 12 -
> arch/arm/include/uapi/asm/kvm.h | 314 -----
> arch/arm/kernel/asm-offsets.c | 11 -
> arch/arm/kernel/vmlinux-xip.lds.S | 8 -
> arch/arm/kernel/vmlinux.lds.S | 8 -
> arch/arm/kernel/vmlinux.lds.h | 10 -
> arch/arm/kvm/Kconfig | 59 -
> arch/arm/kvm/Makefile | 43 -
> arch/arm/kvm/coproc.c | 1455 ------------------------
> arch/arm/kvm/coproc.h | 130 ---
> arch/arm/kvm/coproc_a15.c | 39 -
> arch/arm/kvm/coproc_a7.c | 42 -
> arch/arm/kvm/emulate.c | 166 ---
> arch/arm/kvm/guest.c | 387 -------
> arch/arm/kvm/handle_exit.c | 175 ---
> arch/arm/kvm/hyp/Makefile | 34 -
> arch/arm/kvm/hyp/banked-sr.c | 70 --
> arch/arm/kvm/hyp/cp15-sr.c | 72 --
> arch/arm/kvm/hyp/entry.S | 121 --
> arch/arm/kvm/hyp/hyp-entry.S | 295 -----
> arch/arm/kvm/hyp/s2-setup.c | 22 -
> arch/arm/kvm/hyp/switch.c | 242 ----
> arch/arm/kvm/hyp/tlb.c | 68 --
> arch/arm/kvm/hyp/vfp.S | 57 -
> arch/arm/kvm/init.S | 157 ---
> arch/arm/kvm/interrupts.S | 36 -
> arch/arm/kvm/irq.h | 16 -
> arch/arm/kvm/reset.c | 86 --
> arch/arm/kvm/trace.h | 86 --
> arch/arm/kvm/vgic-v3-coproc.c | 27 -
> arch/arm/mach-exynos/Kconfig | 2 +-
> arch/arm/mm/mmu.c | 26 -
> 49 files changed, 7 insertions(+), 6262 deletions(-)
> delete mode 100644 arch/arm/include/asm/kvm_arm.h
> delete mode 100644 arch/arm/include/asm/kvm_asm.h
> delete mode 100644 arch/arm/include/asm/kvm_coproc.h
> delete mode 100644 arch/arm/include/asm/kvm_emulate.h
> delete mode 100644 arch/arm/include/asm/kvm_host.h
> delete mode 100644 arch/arm/include/asm/kvm_hyp.h
> delete mode 100644 arch/arm/include/asm/kvm_mmu.h
> delete mode 100644 arch/arm/include/asm/kvm_ras.h
> delete mode 100644 arch/arm/include/asm/stage2_pgtable.h
> delete mode 100644 arch/arm/include/uapi/asm/kvm.h
> delete mode 100644 arch/arm/kvm/Kconfig
> delete mode 100644 arch/arm/kvm/Makefile
> delete mode 100644 arch/arm/kvm/coproc.c
> delete mode 100644 arch/arm/kvm/coproc.h
> delete mode 100644 arch/arm/kvm/coproc_a15.c
> delete mode 100644 arch/arm/kvm/coproc_a7.c
> delete mode 100644 arch/arm/kvm/emulate.c
> delete mode 100644 arch/arm/kvm/guest.c
> delete mode 100644 arch/arm/kvm/handle_exit.c
> delete mode 100644 arch/arm/kvm/hyp/Makefile
> delete mode 100644 arch/arm/kvm/hyp/banked-sr.c
> delete mode 100644 arch/arm/kvm/hyp/cp15-sr.c
> delete mode 100644 arch/arm/kvm/hyp/entry.S
> delete mode 100644 arch/arm/kvm/hyp/hyp-entry.S
> delete mode 100644 arch/arm/kvm/hyp/s2-setup.c
> delete mode 100644 arch/arm/kvm/hyp/switch.c
> delete mode 100644 arch/arm/kvm/hyp/tlb.c
> delete mode 100644 arch/arm/kvm/hyp/vfp.S
> delete mode 100644 arch/arm/kvm/init.S
> delete mode 100644 arch/arm/kvm/interrupts.S
> delete mode 100644 arch/arm/kvm/irq.h
> delete mode 100644 arch/arm/kvm/reset.c
> delete mode 100644 arch/arm/kvm/trace.h
> delete mode 100644 arch/arm/kvm/vgic-v3-coproc.c
>
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
^ permalink raw reply
* Re: [PATCH v4 07/16] hw/i386: Rename apicid_from_topo_ids to x86_apicid_from_topo_ids
From: Igor Mammedov @ 2020-02-20 12:43 UTC (permalink / raw)
To: Babu Moger; +Cc: ehabkost, mst, qemu-devel, pbonzini, rth
In-Reply-To: <158161783201.48948.10267676745424104315.stgit@naples-babu.amd.com>
On Thu, 13 Feb 2020 12:17:12 -0600
Babu Moger <babu.moger@amd.com> wrote:
> For consistancy rename apicid_from_topo_ids to x86_apicid_from_topo_ids.
> No functional change.
>
> Signed-off-by: Babu Moger <babu.moger@amd.com>
Reviewed-by: Igor Mammedov <imammedo@redhat.com>
> ---
> hw/i386/pc.c | 2 +-
> include/hw/i386/topology.h | 6 +++---
> 2 files changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/hw/i386/pc.c b/hw/i386/pc.c
> index 02fdb3d506..be72a49716 100644
> --- a/hw/i386/pc.c
> +++ b/hw/i386/pc.c
> @@ -1808,7 +1808,7 @@ static void pc_cpu_pre_plug(HotplugHandler *hotplug_dev,
> topo_ids.die_id = cpu->die_id;
> topo_ids.core_id = cpu->core_id;
> topo_ids.smt_id = cpu->thread_id;
> - cpu->apic_id = apicid_from_topo_ids(&topo_info, &topo_ids);
> + cpu->apic_id = x86_apicid_from_topo_ids(&topo_info, &topo_ids);
> }
>
> cpu_slot = pc_find_cpu_slot(MACHINE(pcms), cpu->apic_id, &idx);
> diff --git a/include/hw/i386/topology.h b/include/hw/i386/topology.h
> index 522c77e6a9..3158157430 100644
> --- a/include/hw/i386/topology.h
> +++ b/include/hw/i386/topology.h
> @@ -107,8 +107,8 @@ static inline unsigned apicid_pkg_offset(X86CPUTopoInfo *topo_info)
> *
> * The caller must make sure core_id < nr_cores and smt_id < nr_threads.
> */
> -static inline apic_id_t apicid_from_topo_ids(X86CPUTopoInfo *topo_info,
> - const X86CPUTopoIDs *topo_ids)
> +static inline apic_id_t x86_apicid_from_topo_ids(X86CPUTopoInfo *topo_info,
> + const X86CPUTopoIDs *topo_ids)
> {
> return (topo_ids->pkg_id << apicid_pkg_offset(topo_info)) |
> (topo_ids->die_id << apicid_die_offset(topo_info)) |
> @@ -160,7 +160,7 @@ static inline apic_id_t x86_apicid_from_cpu_idx(X86CPUTopoInfo *topo_info,
> {
> X86CPUTopoIDs topo_ids;
> x86_topo_ids_from_idx(topo_info, cpu_index, &topo_ids);
> - return apicid_from_topo_ids(topo_info, &topo_ids);
> + return x86_apicid_from_topo_ids(topo_info, &topo_ids);
> }
>
> #endif /* HW_I386_TOPOLOGY_H */
>
^ permalink raw reply
* Re: [dpdk-dev] [PATCH] net/mlx5: fix VLAN actions in meter
From: Raslan Darawsheh @ 2020-02-20 12:43 UTC (permalink / raw)
To: Suanming Mou, Slava Ovsiienko, Matan Azrad; +Cc: dev@dpdk.org, stable@dpdk.org
In-Reply-To: <1582184744-91629-1-git-send-email-suanmingm@mellanox.com>
Hi,
> -----Original Message-----
> From: Suanming Mou <suanmingm@mellanox.com>
> Sent: Thursday, February 20, 2020 9:46 AM
> To: Slava Ovsiienko <viacheslavo@mellanox.com>; Matan Azrad
> <matan@mellanox.com>
> Cc: dev@dpdk.org; Raslan Darawsheh <rasland@mellanox.com>;
> stable@dpdk.org
> Subject: [PATCH] net/mlx5: fix VLAN actions in meter
>
> Meter suffix subflow only has the port id and tag match item, if VLAN
> push and set VLAN id actions exist in the suffix subflow, the user
> defined VLAN items is required for the actions to set a correct VLAN
> id.
>
> Currently, the VLAN item stays in the meter prefix subflow. Without
> the VLAN item, VLAN id or pcp will not be inherited.
>
> Actions require the VLAN item as below:
> RTE_FLOW_ACTION_TYPE_OF_PUSH_VLAN
> RTE_FLOW_ACTION_TYPE_OF_SET_VLAN_VID
>
> Add a private VLAN item to copy the user defined VLAN item to the meter
> suffix subflow, so the suffix subflow will have the chance to get the
> correct original VLAN id and pcp value from the VLAN item.
>
> Fixes: 9ea9b049a960 ("net/mlx5: split meter flow")
> Cc: stable@dpdk.org
>
> Signed-off-by: Suanming Mou <suanmingm@mellanox.com>
> ---
> drivers/net/mlx5/mlx5_flow.c | 153 ++++++++++++++++++------------------
> ----
> drivers/net/mlx5/mlx5_flow.h | 4 ++
> drivers/net/mlx5/mlx5_flow_dv.c | 14 ++--
> 3 files changed, 82 insertions(+), 89 deletions(-)
>
> diff --git a/drivers/net/mlx5/mlx5_flow.c b/drivers/net/mlx5/mlx5_flow.c
> index e5d2e64..2a78c43 100644
> --- a/drivers/net/mlx5/mlx5_flow.c
> +++ b/drivers/net/mlx5/mlx5_flow.c
> @@ -2664,26 +2664,6 @@ uint32_t mlx5_flow_adjust_priority(struct
> rte_eth_dev *dev, int32_t priority,
> }
>
> /**
> - * Get port id item from the item list.
> - *
> - * @param[in] item
> - * Pointer to the list of items.
> - *
> - * @return
> - * Pointer to the port id item if exist, else return NULL.
> - */
> -static const struct rte_flow_item *
> -find_port_id_item(const struct rte_flow_item *item)
> -{
> - MLX5_ASSERT(item);
> - for (; item->type != RTE_FLOW_ITEM_TYPE_END; item++) {
> - if (item->type == RTE_FLOW_ITEM_TYPE_PORT_ID)
> - return item;
> - }
> - return NULL;
> -}
> -
> -/**
> * Get RSS action from the action list.
> *
> * @param[in] actions
> @@ -3502,6 +3482,10 @@ uint32_t mlx5_flow_adjust_priority(struct
> rte_eth_dev *dev, int32_t priority,
> *
> * @param dev
> * Pointer to Ethernet device.
> + * @param[in] items
> + * Pattern specification (list terminated by the END pattern item).
> + * @param[out] sfx_items
> + * Suffix flow match items (list terminated by the END pattern item).
> * @param[in] actions
> * Associated actions (list terminated by the END action).
> * @param[out] actions_sfx
> @@ -3518,70 +3502,60 @@ uint32_t mlx5_flow_adjust_priority(struct
> rte_eth_dev *dev, int32_t priority,
> */
> static int
> flow_meter_split_prep(struct rte_eth_dev *dev,
> + const struct rte_flow_item items[],
> + struct rte_flow_item sfx_items[],
> const struct rte_flow_action actions[],
> struct rte_flow_action actions_sfx[],
> struct rte_flow_action actions_pre[])
> {
> struct rte_flow_action *tag_action = NULL;
> + struct rte_flow_item *tag_item;
> struct mlx5_rte_flow_action_set_tag *set_tag;
> struct rte_flow_error error;
> const struct rte_flow_action_raw_encap *raw_encap;
> const struct rte_flow_action_raw_decap *raw_decap;
> + struct mlx5_rte_flow_item_tag *tag_spec;
> + struct mlx5_rte_flow_item_tag *tag_mask;
> uint32_t tag_id;
> + bool copy_vlan = false;
>
> /* Prepare the actions for prefix and suffix flow. */
> for (; actions->type != RTE_FLOW_ACTION_TYPE_END; actions++) {
> + struct rte_flow_action **action_cur = NULL;
> +
> switch (actions->type) {
> case RTE_FLOW_ACTION_TYPE_METER:
> /* Add the extra tag action first. */
> tag_action = actions_pre;
> tag_action->type =
> MLX5_RTE_FLOW_ACTION_TYPE_TAG;
> actions_pre++;
> - memcpy(actions_pre, actions,
> - sizeof(struct rte_flow_action));
> - actions_pre++;
> + action_cur = &actions_pre;
> break;
> case RTE_FLOW_ACTION_TYPE_VXLAN_DECAP:
> case RTE_FLOW_ACTION_TYPE_NVGRE_DECAP:
> - memcpy(actions_pre, actions,
> - sizeof(struct rte_flow_action));
> - actions_pre++;
> + action_cur = &actions_pre;
> break;
> case RTE_FLOW_ACTION_TYPE_RAW_ENCAP:
> raw_encap = actions->conf;
> - if (raw_encap->size >
> - (sizeof(struct rte_flow_item_eth) +
> - sizeof(struct rte_flow_item_ipv4))) {
> - memcpy(actions_sfx, actions,
> - sizeof(struct rte_flow_action));
> - actions_sfx++;
> - } else {
> - rte_memcpy(actions_pre, actions,
> - sizeof(struct rte_flow_action));
> - actions_pre++;
> - }
> + if (raw_encap->size <
> MLX5_ENCAPSULATION_DECISION_SIZE)
> + action_cur = &actions_pre;
> break;
> case RTE_FLOW_ACTION_TYPE_RAW_DECAP:
> raw_decap = actions->conf;
> - /* Size 0 decap means 50 bytes as vxlan decap. */
> - if (raw_decap->size && (raw_decap->size <
> - (sizeof(struct rte_flow_item_eth) +
> - sizeof(struct rte_flow_item_ipv4)))) {
> - memcpy(actions_sfx, actions,
> - sizeof(struct rte_flow_action));
> - actions_sfx++;
> - } else {
> - rte_memcpy(actions_pre, actions,
> - sizeof(struct rte_flow_action));
> - actions_pre++;
> - }
> + if (raw_decap->size >
> MLX5_ENCAPSULATION_DECISION_SIZE)
> + action_cur = &actions_pre;
> + break;
> + case RTE_FLOW_ACTION_TYPE_OF_PUSH_VLAN:
> + case RTE_FLOW_ACTION_TYPE_OF_SET_VLAN_VID:
> + copy_vlan = true;
> break;
> default:
> - memcpy(actions_sfx, actions,
> - sizeof(struct rte_flow_action));
> - actions_sfx++;
> break;
> }
> + if (!action_cur)
> + action_cur = &actions_sfx;
> + memcpy(*action_cur, actions, sizeof(struct
> rte_flow_action));
> + (*action_cur)++;
> }
> /* Add end action to the actions. */
> actions_sfx->type = RTE_FLOW_ACTION_TYPE_END;
> @@ -3597,6 +3571,42 @@ uint32_t mlx5_flow_adjust_priority(struct
> rte_eth_dev *dev, int32_t priority,
> set_tag->data = tag_id << MLX5_MTR_COLOR_BITS;
> assert(tag_action);
> tag_action->conf = set_tag;
> + /* Prepare the suffix subflow items. */
> + tag_item = sfx_items++;
> + for (; items->type != RTE_FLOW_ITEM_TYPE_END; items++) {
> + int item_type = items->type;
> +
> + switch (item_type) {
> + case RTE_FLOW_ITEM_TYPE_PORT_ID:
> + memcpy(sfx_items, items, sizeof(*sfx_items));
> + sfx_items++;
> + break;
> + case RTE_FLOW_ITEM_TYPE_VLAN:
> + if (copy_vlan) {
> + memcpy(sfx_items, items,
> sizeof(*sfx_items));
> + /*
> + * Convert to internal match item, it is used
> + * for vlan push and set vid.
> + */
> + sfx_items->type =
> MLX5_RTE_FLOW_ITEM_TYPE_VLAN;
> + sfx_items++;
> + }
> + break;
> + default:
> + break;
> + }
> + }
> + sfx_items->type = RTE_FLOW_ITEM_TYPE_END;
> + sfx_items++;
> + tag_spec = (struct mlx5_rte_flow_item_tag *)sfx_items;
> + tag_spec->data = tag_id << MLX5_MTR_COLOR_BITS;
> + tag_spec->id = mlx5_flow_get_reg_id(dev, MLX5_MTR_SFX, 0,
> &error);
> + tag_mask = tag_spec + 1;
> + tag_mask->data = 0xffffff00;
> + tag_item->type = MLX5_RTE_FLOW_ITEM_TYPE_TAG;
> + tag_item->spec = tag_spec;
> + tag_item->last = NULL;
> + tag_item->mask = tag_mask;
> return tag_id;
> }
>
> @@ -4023,7 +4033,6 @@ uint32_t mlx5_flow_adjust_priority(struct
> rte_eth_dev *dev, int32_t priority,
> struct rte_flow_action *sfx_actions = NULL;
> struct rte_flow_action *pre_actions = NULL;
> struct rte_flow_item *sfx_items = NULL;
> - const struct rte_flow_item *sfx_port_id_item;
> struct mlx5_flow *dev_flow = NULL;
> struct rte_flow_attr sfx_attr = *attr;
> uint32_t mtr = 0;
> @@ -4036,13 +4045,11 @@ uint32_t mlx5_flow_adjust_priority(struct
> rte_eth_dev *dev, int32_t priority,
> if (priv->mtr_en)
> actions_n = flow_check_meter_action(actions, &mtr);
> if (mtr) {
> - struct mlx5_rte_flow_item_tag *tag_spec;
> - struct mlx5_rte_flow_item_tag *tag_mask;
> /* The five prefix actions: meter, decap, encap, tag, end. */
> act_size = sizeof(struct rte_flow_action) * (actions_n + 5) +
> - sizeof(struct rte_flow_action_set_tag);
> - /* tag, end. */
> -#define METER_SUFFIX_ITEM 3
> + sizeof(struct mlx5_rte_flow_action_set_tag);
> + /* tag, vlan, port id, end. */
> +#define METER_SUFFIX_ITEM 4
> item_size = sizeof(struct rte_flow_item) *
> METER_SUFFIX_ITEM +
> sizeof(struct mlx5_rte_flow_item_tag) * 2;
> sfx_actions = rte_zmalloc(__func__, (act_size + item_size),
> 0);
> @@ -4051,9 +4058,12 @@ uint32_t mlx5_flow_adjust_priority(struct
> rte_eth_dev *dev, int32_t priority,
>
> RTE_FLOW_ERROR_TYPE_ACTION,
> NULL, "no memory to split "
> "meter flow");
> + sfx_items = (struct rte_flow_item *)((char *)sfx_actions +
> + act_size);
> pre_actions = sfx_actions + actions_n;
> - mtr_tag_id = flow_meter_split_prep(dev, actions,
> sfx_actions,
> - pre_actions);
> + mtr_tag_id = flow_meter_split_prep(dev, items, sfx_items,
> + actions, sfx_actions,
> + pre_actions);
> if (!mtr_tag_id) {
> ret = -rte_errno;
> goto exit;
> @@ -4067,29 +4077,6 @@ uint32_t mlx5_flow_adjust_priority(struct
> rte_eth_dev *dev, int32_t priority,
> goto exit;
> }
> dev_flow->mtr_flow_id = mtr_tag_id;
> - /* Prepare the suffix flow match pattern. */
> - sfx_items = (struct rte_flow_item *)((char *)sfx_actions +
> - act_size);
> - tag_spec = (struct mlx5_rte_flow_item_tag *)(sfx_items +
> - METER_SUFFIX_ITEM);
> - tag_spec->data = dev_flow->mtr_flow_id <<
> MLX5_MTR_COLOR_BITS;
> - tag_spec->id = mlx5_flow_get_reg_id(dev, MLX5_MTR_SFX,
> 0,
> - error);
> - tag_mask = tag_spec + 1;
> - tag_mask->data = 0xffffff00;
> - sfx_items->type = MLX5_RTE_FLOW_ITEM_TYPE_TAG;
> - sfx_items->spec = tag_spec;
> - sfx_items->last = NULL;
> - sfx_items->mask = tag_mask;
> - sfx_items++;
> - sfx_port_id_item = find_port_id_item(items);
> - if (sfx_port_id_item) {
> - memcpy(sfx_items, sfx_port_id_item,
> - sizeof(*sfx_items));
> - sfx_items++;
> - }
> - sfx_items->type = RTE_FLOW_ITEM_TYPE_END;
> - sfx_items -= sfx_port_id_item ? 2 : 1;
> /* Setting the sfx group atrr. */
> sfx_attr.group = sfx_attr.transfer ?
> (MLX5_FLOW_TABLE_LEVEL_SUFFIX - 1) :
> diff --git a/drivers/net/mlx5/mlx5_flow.h b/drivers/net/mlx5/mlx5_flow.h
> index 791f3bd..13c8589 100644
> --- a/drivers/net/mlx5/mlx5_flow.h
> +++ b/drivers/net/mlx5/mlx5_flow.h
> @@ -34,6 +34,7 @@ enum mlx5_rte_flow_item_type {
> MLX5_RTE_FLOW_ITEM_TYPE_END = INT_MIN,
> MLX5_RTE_FLOW_ITEM_TYPE_TAG,
> MLX5_RTE_FLOW_ITEM_TYPE_TX_QUEUE,
> + MLX5_RTE_FLOW_ITEM_TYPE_VLAN,
> };
>
> /* Private (internal) rte flow actions. */
> @@ -328,6 +329,9 @@ enum mlx5_feature_name {
> #define MLX5_GENEVE_OPT_LEN_0 14
> #define MLX5_GENEVE_OPT_LEN_1 63
>
> +#define MLX5_ENCAPSULATION_DECISION_SIZE (sizeof(struct
> rte_flow_item_eth) + \
> + sizeof(struct rte_flow_item_ipv4))
> +
> enum mlx5_flow_drv_type {
> MLX5_FLOW_TYPE_MIN,
> MLX5_FLOW_TYPE_DV,
> diff --git a/drivers/net/mlx5/mlx5_flow_dv.c
> b/drivers/net/mlx5/mlx5_flow_dv.c
> index 3fac288..2437e55 100644
> --- a/drivers/net/mlx5/mlx5_flow_dv.c
> +++ b/drivers/net/mlx5/mlx5_flow_dv.c
> @@ -54,8 +54,6 @@
> #define MLX5DV_DR_ACTION_FLAGS_ROOT_LEVEL 1
> #endif
>
> -#define MLX5_ENCAPSULATION_DECISION_SIZE (sizeof(struct
> rte_flow_item_eth) + \
> - sizeof(struct rte_flow_item_ipv4))
> /* VLAN header definitions */
> #define MLX5DV_FLOW_VLAN_PCP_SHIFT 13
> #define MLX5DV_FLOW_VLAN_PCP_MASK (0x7 <<
> MLX5DV_FLOW_VLAN_PCP_SHIFT)
> @@ -1757,10 +1755,14 @@ struct field_modify_info modify_tcp[] = {
>
> if (items == NULL)
> return;
> - for (; items->type != RTE_FLOW_ITEM_TYPE_END &&
> - items->type != RTE_FLOW_ITEM_TYPE_VLAN; items++)
> - ;
> - if (items->type == RTE_FLOW_ITEM_TYPE_VLAN) {
> + for (; items->type != RTE_FLOW_ITEM_TYPE_END; items++) {
> + int type = items->type;
> +
> + if (type == RTE_FLOW_ITEM_TYPE_VLAN ||
> + type == MLX5_RTE_FLOW_ITEM_TYPE_VLAN)
> + break;
> + }
> + if (items->type != RTE_FLOW_ITEM_TYPE_END) {
> const struct rte_flow_item_vlan *vlan_m = items->mask;
> const struct rte_flow_item_vlan *vlan_v = items->spec;
>
> --
> 1.8.3.1
Patch applied to next-net-mlx,
Kindest regards,
Raslan Darawsheh
^ permalink raw reply
* Re: w83627ehf crash in 5.6.0-rc2-00055-gca7e1fd1026c
From: Meelis Roos @ 2020-02-20 12:43 UTC (permalink / raw)
To: Dr. David Alan Gilbert; +Cc: linux-hwmon, LKML, Chen Zhou
In-Reply-To: <20200220121451.GA18071@gallifrey>
> It looks like not all chips have temp_label, so I think we need to change w83627ehf_is_visible
> which has:
>
> if (attr == hwmon_temp_input || attr == hwmon_temp_label)
> return 0444;
>
> to
> if (attr == hwmon_temp_input)
> return 0444;
> if (attr == hwmon_temp_label) {
> if (data->temp_label)
> return 0444;
> else
> return 0;
> }
>
> Does that work for you?
Yes, it works - sensors are displayed as they should be, with nothing in dmesg.
Thank you for so quick response!
--
Meelis Roos <mroos@linux.ee>
^ permalink raw reply
* [Intel-gfx] [PATCH v3 2/2] drm/i915/hdcp: Return 0 on config_stream_type() +ve return
From: Anshuman Gupta @ 2020-02-20 12:32 UTC (permalink / raw)
To: intel-gfx
In-Reply-To: <20200220123217.23635-1-anshuman.gupta@intel.com>
As DP shim's config_stream_type returns size of message
to be written in case of success therefore on
config_stream_type success return a zero success
value in order to succeed the HDCP auth.
CC: Ramalingam C <ramalingam.c@intel.com>
Signed-off-by: Anshuman Gupta <anshuman.gupta@intel.com>
---
drivers/gpu/drm/i915/display/intel_hdcp.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c b/drivers/gpu/drm/i915/display/intel_hdcp.c
index 75f60ca282fc..464ef7ba4db4 100644
--- a/drivers/gpu/drm/i915/display/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/display/intel_hdcp.c
@@ -1538,7 +1538,9 @@ static int hdcp2_authenticate_sink(struct intel_connector *connector)
ret = shim->config_stream_type(intel_dig_port,
hdcp->is_repeater,
hdcp->content_type);
- if (ret < 0)
+ if (ret >= 0)
+ ret = 0;
+ else
return ret;
}
--
2.24.0
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply related
* [Intel-gfx] [PATCH v3 1/2] drm/i915/hdcp: Mandate (seq_num_V==0) at first RecvId msg
From: Anshuman Gupta @ 2020-02-20 12:32 UTC (permalink / raw)
To: intel-gfx
In-Reply-To: <20200220123217.23635-1-anshuman.gupta@intel.com>
HDCP Repeater initializes seq_num_V to 0 at the beginning of
hdcp Session i.e. after AKE_init received, refer
HDCP 2.2 Spec HDMI PAGE 19, DP PAGE 20.
HDCP 2.2 Comp specs 1B-06 test verifies that whether DUT
considers failure of authentication if the repeater provides a
non-zero value in seq_num_V in the first,
RepeaterAuth_Send_ReceiverID_List message.
Make sure that HDCP repeater initializes seq_num_V to zero at
beginning of session i.e. after AKE_Init, fail the Auth if
there is non zero seq_num_V.
v2:
- Used existing hdcp2_encrypted flag instead of
declaring new flag. [Ram]
Cc: Ramalingam C <ramalingam.c@intel.com>
Reviewed-by: Ramalingam C <ramalingam.c@intel.com>
Signed-off-by: Anshuman Gupta <anshuman.gupta@intel.com>
---
drivers/gpu/drm/i915/display/intel_hdcp.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c b/drivers/gpu/drm/i915/display/intel_hdcp.c
index 30e0a3aa9d57..75f60ca282fc 100644
--- a/drivers/gpu/drm/i915/display/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/display/intel_hdcp.c
@@ -1462,6 +1462,12 @@ int hdcp2_authenticate_repeater_topology(struct intel_connector *connector)
seq_num_v =
drm_hdcp_be24_to_cpu((const u8 *)msgs.recvid_list.seq_num_v);
+ if (!hdcp->hdcp2_encrypted && seq_num_v) {
+ drm_dbg_kms(&dev_priv->drm,
+ "Non zero Seq_num_v at first RecvId_List msg\n");
+ return -EINVAL;
+ }
+
if (seq_num_v < hdcp->seq_num_v) {
/* Roll over of the seq_num_v from repeater. Reauthenticate. */
DRM_DEBUG_KMS("Seq_num_v roll over.\n");
--
2.24.0
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply related
* [Intel-gfx] [PATCH v3 0/2] HDCP 2.2 Comp fixes
From: Anshuman Gupta @ 2020-02-20 12:32 UTC (permalink / raw)
To: intel-gfx
Adding ram's RB on patch1 and a new patch to fix DP HDCP Auth.
Anshuman Gupta (2):
drm/i915/hdcp: Mandate (seq_num_V==0) at first RecvId msg
drm/i915/hdcp: Return 0 on config_stream_type() +ve return
drivers/gpu/drm/i915/display/intel_hdcp.c | 10 +++++++++-
1 file changed, 9 insertions(+), 1 deletion(-)
--
2.24.0
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply
* Re: [PATCH] babeltrace2: added 2.0.1
From: Alexander Kanavin @ 2020-02-20 12:42 UTC (permalink / raw)
To: Anders Wallin; +Cc: OE-core
In-Reply-To: <CAF2baFcN_2du6k_p2s_5RsExmkAuVvvJQOaak9GehMBQ=y4m6g@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1516 bytes --]
Generally this should be done by the person introducing the new recipe.
Also check that upstream version check works correctly for both:
devtool latest-version babeltrace (this should be probably limited to 1.x
versions)
devtool latest-version babeltrace2
Alex
On Thu, 20 Feb 2020 at 13:39, Anders Wallin <wallinux@gmail.com> wrote:
> Hi Alex,
>
> should I update the patch to include changes to maintainer file,
> packagegroup etc in the same way as for babeltrace or
> is it something you will do?
>
> Anders Wallin
>
>
> On Wed, Feb 19, 2020 at 5:02 PM Alexander Kanavin <alex.kanavin@gmail.com>
> wrote:
>
>> On Wed, 19 Feb 2020 at 16:56, Jonathan Rajotte-Julien <
>> jonathan.rajotte-julien@efficios.com> wrote:
>>
>>> > There are some things where the namespaces are quite specific (python
>>> > vs python3, gtk(+) 2/3/4, qt) but they're fairly few and far between.
>>> >
>>> > If babeltrace2 will replace babeltrace and become babeltrace, we
>>> > probably want to keep PN as babeltrace. If it will be known as
>>> > babeltrace2 always, we probably change PN.
>>>
>>> Babeltrace 2 executable will be forever named babeltrace2.
>>>
>>> Hope this clear up this part a bit.
>>>
>>
>> Right, then I'm fine with naming the recipe babeltrace2.
>>
>> Alex
>> --
>> _______________________________________________
>> Openembedded-core mailing list
>> Openembedded-core@lists.openembedded.org
>> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>>
>
[-- Attachment #2: Type: text/html, Size: 2867 bytes --]
^ permalink raw reply
* Re: [PATCH v2] xfs: fix iclog release error check race with shutdown
From: Brian Foster @ 2020-02-20 12:41 UTC (permalink / raw)
To: Darrick J. Wong; +Cc: Dave Chinner, linux-xfs
In-Reply-To: <20200219215141.GP9506@magnolia>
On Wed, Feb 19, 2020 at 01:51:41PM -0800, Darrick J. Wong wrote:
> On Wed, Feb 19, 2020 at 08:12:32AM -0500, Brian Foster wrote:
> > On Wed, Feb 19, 2020 at 08:52:43AM +1100, Dave Chinner wrote:
> > > On Tue, Feb 18, 2020 at 12:54:25PM -0500, Brian Foster wrote:
> > > > Prior to commit df732b29c8 ("xfs: call xlog_state_release_iclog with
> > > > l_icloglock held"), xlog_state_release_iclog() always performed a
> > > > locked check of the iclog error state before proceeding into the
> > > > sync state processing code. As of this commit, part of
> > > > xlog_state_release_iclog() was open-coded into
> > > > xfs_log_release_iclog() and as a result the locked error state check
> > > > was lost.
> > > >
> > > > The lockless check still exists, but this doesn't account for the
> > > > possibility of a race with a shutdown being performed by another
> > > > task causing the iclog state to change while the original task waits
> > > > on ->l_icloglock. This has reproduced very rarely via generic/475
> > > > and manifests as an assert failure in __xlog_state_release_iclog()
> > > > due to an unexpected iclog state.
> > > >
> > > > Restore the locked error state check in xlog_state_release_iclog()
> > > > to ensure that an iclog state update via shutdown doesn't race with
> > > > the iclog release state processing code.
> > > >
> > > > Fixes: df732b29c807 ("xfs: call xlog_state_release_iclog with l_icloglock held")
> > > > Reported-by: Zorro Lang <zlang@redhat.com>
> > > > Signed-off-by: Brian Foster <bfoster@redhat.com>
> > > > ---
> > > >
> > > > v2:
> > > > - Include Fixes tag.
> > > > - Use common error path to include shutdown call.
> > > > v1: https://lore.kernel.org/linux-xfs/20200214181528.24046-1-bfoster@redhat.com/
> > > >
> > > > fs/xfs/xfs_log.c | 13 +++++++++----
> > > > 1 file changed, 9 insertions(+), 4 deletions(-)
> > > >
> > > > diff --git a/fs/xfs/xfs_log.c b/fs/xfs/xfs_log.c
> > > > index f6006d94a581..796ff37d5bb5 100644
> > > > --- a/fs/xfs/xfs_log.c
> > > > +++ b/fs/xfs/xfs_log.c
> > > > @@ -605,18 +605,23 @@ xfs_log_release_iclog(
> > > > struct xlog *log = mp->m_log;
> > > > bool sync;
> > > >
> > > > - if (iclog->ic_state == XLOG_STATE_IOERROR) {
> > > > - xfs_force_shutdown(mp, SHUTDOWN_LOG_IO_ERROR);
> > > > - return -EIO;
> > > > - }
> > >
> > > hmmmm.
> > >
> > > xfs_force_shutdown() will does nothing if the iclog at the head of
> > > the log->iclog list is marked with XLOG_STATE_IOERROR before IO is
> > > submitted. In general, that is the case here as the head iclog is
> > > what xlog_state_get_iclog_space() returns.
> > >
> > > i.e. XLOG_STATE_IOERROR here implies the log has already been shut
> > > down because the state is IOERROR rather than ACTIVE or WANT_SYNC as
> > > was set when the iclog was obtained from
> > > xlog_state_get_iclog_space().
> > >
> >
> > I'm not sure that assumption is always true. If the iclog is (was)
> > WANT_SYNC, for example, then it's already been switched out from the
> > head of that list. That might only happen if a checkpoint happens to
> > align nicely with the end of an iclog, but that's certainly possible. We
> > also need to consider that ->l_icloglock cycles here and thus somebody
> > else could switch out the head iclog..
> >
> > > > + if (iclog->ic_state == XLOG_STATE_IOERROR)
> > > > + goto error;
> > > >
> > > > if (atomic_dec_and_lock(&iclog->ic_refcnt, &log->l_icloglock)) {
> > > > + if (iclog->ic_state == XLOG_STATE_IOERROR) {
> > > > + spin_unlock(&log->l_icloglock);
> > > > + goto error;
> > > > + }
> > > > sync = __xlog_state_release_iclog(log, iclog);
> > > > spin_unlock(&log->l_icloglock);
> > > > if (sync)
> > > > xlog_sync(log, iclog);
> > > > }
> > > > return 0;
> > > > +error:
> > > > + xfs_force_shutdown(mp, SHUTDOWN_LOG_IO_ERROR);
> > > > + return -EIO;
> > >
> > > Hence I suspect that this should be ASSERT(XLOG_FORCED_SHUTDOWN(log))
> > > just like is in xfs_log_force_umount() when this pre-existing log
> > > IO error condition is tripped over...
> > >
> >
> > I think this change is fundamentally correct based on the simple fact
> > that we only ever set XLOG_STATE_IOERROR in the shutdown path. That
> > said, the assert would be potentially racy against the shutdown path
> > without any ordering guarantee that the release path might see the iclog
> > state update prior to the log state update and lead to a potentially
> > false negative assert failure. I suspect this is why the shutdown call
> > might have been made from here in the first place (and partly why I
> > didn't bother with it in the restored locked state check).
> >
> > Given the context of this patch (fixing a regression) and the practical
> > history of this code (and the annoying process of identifying and
> > tracking down the source of these kind of shutdown buglets), I'm
> > inclined to have this patch preserve the historical and relatively
> > proven behavior as much as possible and consider further cleanups
> > separately...
>
> That sounds reasonable to me (who has at this point missed most of the
> discussion about this patch). Is there going to be a v3 of this patch?
> Or has all of the further discussion centered around further cleanups,
> and this one is good to go?
>
I wasn't planning on a v3. The discussion to this point has been
centered around the xfs_force_shutdown() call in the associated function
(which is orthogonal to the bug). v1 is technically correct, but
Christoph suggested to restore historical behavior wrt to the shutdown
call. v2 does that, but is a bit superfluous in that the iclog error
state with the lock held implies shutdown has already occurred. This is
harmless (unless we're worried about shutdown performance or
something..), but I think Dave indicated he preferred v1 based on that
reasoning.
Functionally I don't think it matters either way and at this point I
have no preference between v1 or v2. They fix the same problem. Do note
that v2 does have the Fixed: tag I missed with v1 (as well as a R-b)...
Brian
> --D
>
> > Brian
> >
> > > Cheers,
> > >
> > > Dave.
> > > --
> > > Dave Chinner
> > > david@fromorbit.com
> > >
> >
>
^ permalink raw reply
* Re: [PATCH 0/5] arm64: add the time namespace support
From: Vincenzo Frascino @ 2020-02-20 12:40 UTC (permalink / raw)
To: Andrei Vagin
Cc: Thomas Gleixner, linux-kernel, linux-arm-kernel, Dmitry Safonov
In-Reply-To: <20200204175913.74901-1-avagin@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2268 bytes --]
Hi Andrei,
On 04/02/2020 17:59, Andrei Vagin wrote:
> Allocate the time namespace page among VVAR pages and add the logic
> to handle faults on VVAR properly.
>
> If a task belongs to a time namespace then the VVAR page which contains
> the system wide VDSO data is replaced with a namespace specific page
> which has the same layout as the VVAR page. That page has vdso_data->seq
> set to 1 to enforce the slow path and vdso_data->clock_mode set to
> VCLOCK_TIMENS to enforce the time namespace handling path.
>
> The extra check in the case that vdso_data->seq is odd, e.g. a concurrent
> update of the VDSO data is in progress, is not really affecting regular
> tasks which are not part of a time namespace as the task is spin waiting
> for the update to finish and vdso_data->seq to become even again.
>
> If a time namespace task hits that code path, it invokes the corresponding
> time getter function which retrieves the real VVAR page, reads host time
> and then adds the offset for the requested clock which is stored in the
> special VVAR page.
>
Thank you for adding the arm64 support of time namespaces. Overall it looks fine
to me even if I have few comments. I will test it in the coming days just to
make sure I did not miss something major. I will keep you updated on the results.
> Cc: Vincenzo Frascino <vincenzo.frascino@arm.com>
> Cc: Thomas Gleixner <tglx@linutronix.de>
> Cc: Dmitry Safonov <dima@arista.com>
>
> Andrei Vagin (5):
> arm64/vdso: use the fault callback to map vvar pages
> arm64/vdso: Zap vvar pages when switching to a time namespace
> arm64/vdso: Add time napespace page
> arm64/vdso: Handle faults on timens page
> arm64/vdso: Restrict splitting VVAR VMA
>
> arch/arm64/Kconfig | 1 +
> .../include/asm/vdso/compat_gettimeofday.h | 11 ++
> arch/arm64/include/asm/vdso/gettimeofday.h | 8 ++
> arch/arm64/kernel/vdso.c | 134 ++++++++++++++++--
> arch/arm64/kernel/vdso/vdso.lds.S | 3 +-
> arch/arm64/kernel/vdso32/vdso.lds.S | 3 +-
> include/vdso/datapage.h | 1 +
> 7 files changed, 147 insertions(+), 14 deletions(-)
>
--
Regards,
Vincenzo
[-- Attachment #2: pEpkey.asc --]
[-- Type: application/pgp-keys, Size: 14291 bytes --]
[-- Attachment #3: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 0/5] arm64: add the time namespace support
From: Vincenzo Frascino @ 2020-02-20 12:40 UTC (permalink / raw)
To: Andrei Vagin
Cc: linux-arm-kernel, linux-kernel, Thomas Gleixner, Dmitry Safonov
In-Reply-To: <20200204175913.74901-1-avagin@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2268 bytes --]
Hi Andrei,
On 04/02/2020 17:59, Andrei Vagin wrote:
> Allocate the time namespace page among VVAR pages and add the logic
> to handle faults on VVAR properly.
>
> If a task belongs to a time namespace then the VVAR page which contains
> the system wide VDSO data is replaced with a namespace specific page
> which has the same layout as the VVAR page. That page has vdso_data->seq
> set to 1 to enforce the slow path and vdso_data->clock_mode set to
> VCLOCK_TIMENS to enforce the time namespace handling path.
>
> The extra check in the case that vdso_data->seq is odd, e.g. a concurrent
> update of the VDSO data is in progress, is not really affecting regular
> tasks which are not part of a time namespace as the task is spin waiting
> for the update to finish and vdso_data->seq to become even again.
>
> If a time namespace task hits that code path, it invokes the corresponding
> time getter function which retrieves the real VVAR page, reads host time
> and then adds the offset for the requested clock which is stored in the
> special VVAR page.
>
Thank you for adding the arm64 support of time namespaces. Overall it looks fine
to me even if I have few comments. I will test it in the coming days just to
make sure I did not miss something major. I will keep you updated on the results.
> Cc: Vincenzo Frascino <vincenzo.frascino@arm.com>
> Cc: Thomas Gleixner <tglx@linutronix.de>
> Cc: Dmitry Safonov <dima@arista.com>
>
> Andrei Vagin (5):
> arm64/vdso: use the fault callback to map vvar pages
> arm64/vdso: Zap vvar pages when switching to a time namespace
> arm64/vdso: Add time napespace page
> arm64/vdso: Handle faults on timens page
> arm64/vdso: Restrict splitting VVAR VMA
>
> arch/arm64/Kconfig | 1 +
> .../include/asm/vdso/compat_gettimeofday.h | 11 ++
> arch/arm64/include/asm/vdso/gettimeofday.h | 8 ++
> arch/arm64/kernel/vdso.c | 134 ++++++++++++++++--
> arch/arm64/kernel/vdso/vdso.lds.S | 3 +-
> arch/arm64/kernel/vdso32/vdso.lds.S | 3 +-
> include/vdso/datapage.h | 1 +
> 7 files changed, 147 insertions(+), 14 deletions(-)
>
--
Regards,
Vincenzo
[-- Attachment #2: pEpkey.asc --]
[-- Type: application/pgp-keys, Size: 14291 bytes --]
^ permalink raw reply
* Re: [Intel-gfx] [PATCH v17 3/7] drm/i915: Init obj state in intel_atomic_get_old/new_global_obj_state
From: Jani Nikula @ 2020-02-20 12:40 UTC (permalink / raw)
To: Stanislav Lisovskiy, intel-gfx
In-Reply-To: <20200220120741.6917-4-stanislav.lisovskiy@intel.com>
On Thu, 20 Feb 2020, Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> wrote:
> We might be willing to call intel_atomic_get_old_global_obj_state
> and intel_atomic_get_new_global_obj_state right away, however
> those are not initializing global obj state as
> intel_atomic_get_global_obj_state does.
> Extracted initializing part to separate function and now using this
> also in intel_atomic_get_old_global_obj_state and intel_atomic_get_new_global_obj_state
>
> v2: - Fixed typo in function call
>
> Signed-off-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
> ---
> drivers/gpu/drm/i915/display/intel_bw.c | 28 ++++++++++++++++++++++++-
> drivers/gpu/drm/i915/display/intel_bw.h | 9 ++++++++
> 2 files changed, 36 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_bw.c b/drivers/gpu/drm/i915/display/intel_bw.c
> index 58b264bc318d..ff57277e8880 100644
> --- a/drivers/gpu/drm/i915/display/intel_bw.c
> +++ b/drivers/gpu/drm/i915/display/intel_bw.c
> @@ -374,7 +374,33 @@ static unsigned int intel_bw_data_rate(struct drm_i915_private *dev_priv,
> return data_rate;
> }
>
> -static struct intel_bw_state *
> +struct intel_bw_state *
> +intel_atomic_get_old_bw_state(struct intel_atomic_state *state)
> +{
> + struct drm_i915_private *dev_priv = to_i915(state->base.dev);
> + struct intel_global_state *bw_state;
> +
> + bw_state = intel_atomic_get_old_global_obj_state(state, &dev_priv->bw_obj);
> + if (IS_ERR(bw_state))
> + return ERR_CAST(bw_state);
> +
> + return to_intel_bw_state(bw_state);
> +}
> +
> +struct intel_bw_state *
> +intel_atomic_get_new_bw_state(struct intel_atomic_state *state)
> +{
> + struct drm_i915_private *dev_priv = to_i915(state->base.dev);
> + struct intel_global_state *bw_state;
> + bw_state = intel_atomic_get_new_global_obj_state(state, &dev_priv->bw_obj);
> +
> + if (IS_ERR(bw_state))
> + return ERR_CAST(bw_state);
> +
> + return to_intel_bw_state(bw_state);
> +}
> +
> +struct intel_bw_state *
> intel_atomic_get_bw_state(struct intel_atomic_state *state)
> {
> struct drm_i915_private *dev_priv = to_i915(state->base.dev);
> diff --git a/drivers/gpu/drm/i915/display/intel_bw.h b/drivers/gpu/drm/i915/display/intel_bw.h
> index a8aa7624c5aa..ac004d6f4276 100644
> --- a/drivers/gpu/drm/i915/display/intel_bw.h
> +++ b/drivers/gpu/drm/i915/display/intel_bw.h
> @@ -24,6 +24,15 @@ struct intel_bw_state {
>
> #define to_intel_bw_state(x) container_of((x), struct intel_bw_state, base)
>
> +struct intel_bw_state *
> +intel_atomic_get_old_bw_state(struct intel_atomic_state *state);
> +
> +struct intel_bw_state *
> +intel_atomic_get_new_bw_state(struct intel_atomic_state *state);
> +
> +struct intel_bw_state *
> +intel_atomic_get_bw_state(struct intel_atomic_state *state);
> +
I'm trying to promote a convention that a module foo_bar.[ch] would
export functions prefixed foo_bar_. Here, intel_bw_* like below.
BR,
Jani.
> void intel_bw_init_hw(struct drm_i915_private *dev_priv);
> int intel_bw_init(struct drm_i915_private *dev_priv);
> int intel_bw_atomic_check(struct intel_atomic_state *state);
--
Jani Nikula, Intel Open Source Graphics Center
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply
* [MODERATED] Re: [PATCH 1/2] more sampling fun 1
From: Greg KH @ 2020-02-20 12:39 UTC (permalink / raw)
To: speck
In-Reply-To: <051675aa-0392-c7ad-1bca-3624972a3388@citrix.com>
On Thu, Feb 20, 2020 at 11:00:40AM +0000, speck for Andrew Cooper wrote:
> On 20/02/2020 10:13, speck for Borislav Petkov wrote:
> > On Thu, Feb 20, 2020 at 10:10:03AM +0000, speck for Andrew Cooper wrote:
> >> Because it is under embargo until May 12th.
> > Maybe 2/2 is - which I don't have in my mbox - but by staring only at
> > 1/2 there's nothing to embargo there AFAICT.
> >
>
> Right, but a lone patch (coming pre-reviewed even!) adding stepping
> support into the speculative model checking is going to be about as
> subtle as the KPTI work was :)
Don't pre-review it then. Just submit it like any other normal cleanup
patch.
thanks,
greg k-h
^ permalink raw reply
* Re: [Intel-gfx] [PATCH v3] drm/i915/psr: Force PSR probe only after full initialization
From: Mun, Gwan-gyeong @ 2020-02-20 12:39 UTC (permalink / raw)
To: intel-gfx@lists.freedesktop.org, Souza, Jose
Cc: Nikula, Jani, zwisler@google.com
In-Reply-To: <20200218203916.58636-1-jose.souza@intel.com>
On Tue, 2020-02-18 at 12:39 -0800, José Roberto de Souza wrote:
> Commit 60c6a14b489b ("drm/i915/display: Force the state compute phase
> once to enable PSR") was forcing the state compute too earlier
> causing errors because not everything was initialized, so here
> moving to i915_driver_register() when everything is ready and driver
> is registering into the rest of the system.
>
> Also fixing the place where it disarm the force probe as during the
> atomic check phase errors could happen like the ones due locking and
> it would cause PSR to never be enabled if that happens.
> Leaving the disarm to the atomic commit phase, intel_psr_enable() or
> intel_psr_update() will be called even if the current state do not
> allow PSR to be enabled.
>
> v2: Check if intel_dp is null in intel_psr_force_mode_changed_set()
> v3: Check intel_dp before get dev_priv
>
> Fixes: 60c6a14b489b ("drm/i915/display: Force the state compute phase
> once to enable PSR")
> Closes: https://gitlab.freedesktop.org/drm/intel/issues/1151
> Tested-by: Ross Zwisler <zwisler@google.com>
> Reported-by: Ross Zwisler <zwisler@google.com>
> Cc: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com>
> Cc: Jani Nikula <jani.nikula@intel.com>
> Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
> ---
> drivers/gpu/drm/i915/display/intel_psr.c | 22 ++++++++++++++++++++--
> drivers/gpu/drm/i915/display/intel_psr.h | 1 +
> drivers/gpu/drm/i915/i915_drv.c | 3 +++
> drivers/gpu/drm/i915/i915_drv.h | 2 +-
> 4 files changed, 25 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_psr.c
> b/drivers/gpu/drm/i915/display/intel_psr.c
> index b4942b6445ae..2a0f7354fba5 100644
> --- a/drivers/gpu/drm/i915/display/intel_psr.c
> +++ b/drivers/gpu/drm/i915/display/intel_psr.c
> @@ -936,6 +936,8 @@ void intel_psr_enable(struct intel_dp *intel_dp,
> {
> struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
>
> + intel_psr_force_mode_changed_set(intel_dp, false);
> +
Hi,
intel_psr_enable() and intel_psr_update already have checking routine
for CAN_PSR and has_psr.
therefore we don't need to check twice here.
And if there are no issues that moving "disarming force_mode_changed"
to intel_psr_compute_config(),
can we move them to intel_psr_compute_config()?
> if (!crtc_state->has_psr)
> return;
>
> @@ -1096,6 +1098,8 @@ void intel_psr_update(struct intel_dp
> *intel_dp,
> struct i915_psr *psr = &dev_priv->psr;
> bool enable, psr2_enable;
>
> + intel_psr_force_mode_changed_set(intel_dp, false);
> +
> if (!CAN_PSR(dev_priv) || READ_ONCE(psr->dp) != intel_dp)
> return;
>
> @@ -1629,7 +1633,7 @@ void intel_psr_atomic_check(struct
> drm_connector *connector,
> struct drm_crtc_state *crtc_state;
>
> if (!CAN_PSR(dev_priv) || !new_state->crtc ||
> - dev_priv->psr.initially_probed)
> + !dev_priv->psr.force_mode_changed)
> return;
>
> intel_connector = to_intel_connector(connector);
> @@ -1640,5 +1644,19 @@ void intel_psr_atomic_check(struct
> drm_connector *connector,
> crtc_state = drm_atomic_get_new_crtc_state(new_state->state,
> new_state->crtc);
> crtc_state->mode_changed = true;
> - dev_priv->psr.initially_probed = true;
> +}
> +
> +void intel_psr_force_mode_changed_set(struct intel_dp *intel_dp,
> bool set)
IMHO, it would be better intel_psr_set_force_mode_changed() as a
function name.
> +{
> + struct drm_i915_private *dev_priv;
> +
> + if (!intel_dp)
> + return;
> +
> + dev_priv = dp_to_i915(intel_dp);
> + if (!CAN_PSR(dev_priv) || !intel_dp_is_edp(intel_dp) ||
> + intel_dp != dev_priv->psr.dp)
> + return;
> +
> + dev_priv->psr.force_mode_changed = set;
> }
> diff --git a/drivers/gpu/drm/i915/display/intel_psr.h
> b/drivers/gpu/drm/i915/display/intel_psr.h
> index c58a1d438808..27a70468e2b9 100644
> --- a/drivers/gpu/drm/i915/display/intel_psr.h
> +++ b/drivers/gpu/drm/i915/display/intel_psr.h
> @@ -40,5 +40,6 @@ bool intel_psr_enabled(struct intel_dp *intel_dp);
> void intel_psr_atomic_check(struct drm_connector *connector,
> struct drm_connector_state *old_state,
> struct drm_connector_state *new_state);
> +void intel_psr_force_mode_changed_set(struct intel_dp *intel_dp,
> bool set);
>
> #endif /* __INTEL_PSR_H__ */
> diff --git a/drivers/gpu/drm/i915/i915_drv.c
> b/drivers/gpu/drm/i915/i915_drv.c
> index f7a1c33697b7..83791c197611 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -58,6 +58,7 @@
> #include "display/intel_hotplug.h"
> #include "display/intel_overlay.h"
> #include "display/intel_pipe_crc.h"
> +#include "display/intel_psr.h"
> #include "display/intel_sprite.h"
> #include "display/intel_vga.h"
>
> @@ -1256,6 +1257,8 @@ static void i915_driver_register(struct
> drm_i915_private *dev_priv)
>
> intel_audio_init(dev_priv);
>
> + intel_psr_force_mode_changed_set(dev_priv->psr.dp, true);
> +
> /*
> * Some ports require correctly set-up hpd registers for
> detection to
> * work properly (leading to ghost connected connector status),
> e.g. VGA
> diff --git a/drivers/gpu/drm/i915/i915_drv.h
> b/drivers/gpu/drm/i915/i915_drv.h
> index 3330b538d379..a546655072bd 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -505,7 +505,7 @@ struct i915_psr {
> bool dc3co_enabled;
> u32 dc3co_exit_delay;
> struct delayed_work dc3co_work;
> - bool initially_probed;
> + bool force_mode_changed;
> };
>
> #define QUIRK_LVDS_SSC_DISABLE (1<<1)
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply
* [Buildroot] [Bug 12571] ltp-testsuite : Build failure
From: bugzilla at busybox.net @ 2020-02-20 12:39 UTC (permalink / raw)
To: buildroot
In-Reply-To: <bug-12571-163@https.bugs.busybox.net/>
https://bugs.busybox.net/show_bug.cgi?id=12571
--- Comment #1 from learn2kab at gmail.com ---
Created attachment 8366
--> https://bugs.busybox.net/attachment.cgi?id=8366&action=edit
".config" file for "beaglebone_defconfig" configuration
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply
* Re: w83627ehf crash in 5.6.0-rc2-00055-gca7e1fd1026c
From: Dr. David Alan Gilbert @ 2020-02-20 12:14 UTC (permalink / raw)
To: Meelis Roos; +Cc: linux-hwmon, LKML, Chen Zhou
In-Reply-To: <434212bb-4eb9-7366-3255-79826d0e65bc@linux.ee>
* Meelis Roos (mroos@linux.ee) wrote:
> While reading w83627ehf sensors output on D425KT mainboard, I consistently get NULL dereference as below.
>
> 5.5.0 worked OK but gave a warning on driver load:
> [ 104.514954] w83627ehf: Found W83627DHG-P chip at 0x290
> [ 104.515634] w83627ehf w83627ehf.656: hwmon_device_register() is deprecated. Please convert the driver to use hwmon_device_register_with_info().
>
> This is dmesg from current git (loading the driver and reading sensors with lm-sensors - no driver loading warning any more):
>
> [ 764.718192] w83627ehf: Found W83627DHG-P chip at 0x290
> [ 774.574874] BUG: kernel NULL pointer dereference, address: 0000000000000000
> [ 774.574889] #PF: supervisor read access in kernel mode
> [ 774.574895] #PF: error_code(0x0000) - not-present page
> [ 774.574901] PGD 0 P4D 0
> [ 774.574909] Oops: 0000 [#1] SMP NOPTI
> [ 774.574917] CPU: 0 PID: 604 Comm: sensors Not tainted 5.6.0-rc2-00055-gca7e1fd1026c #29
> [ 774.574923] Hardware name: /D425KT, BIOS MWPNT10N.86A.0132.2013.0726.1534 07/26/2013
> [ 774.574939] RIP: 0010:w83627ehf_read_string+0x27/0x70 [w83627ehf]
> [ 774.574947] Code: 00 00 00 55 53 48 8d 64 24 f0 83 fa 15 48 8b 5f 78 75 29 83 fe 01 75 24 48 63 c9 48 8b 6b 58 48 83 f9 03 77 24 0f b6 44 0b 50 <48> 8b 44 c5 00 49 89 00 48 8d 64 24 10 5b 31 c0 5d c3 48 8d 64 24
> [ 774.574958] RSP: 0018:ffffb95980657df8 EFLAGS: 00010293
> [ 774.574965] RAX: 0000000000000000 RBX: ffff96caaa7f5218 RCX: 0000000000000000
> [ 774.574972] RDX: 0000000000000015 RSI: 0000000000000001 RDI: ffff96caa736ec08
> [ 774.574978] RBP: 0000000000000000 R08: ffffb95980657e20 R09: 0000000000000001
> [ 774.574985] R10: ffff96caaa635cc0 R11: 0000000000000000 R12: ffff96caa9f7cf00
> [ 774.574991] R13: ffff96caa9ec3d00 R14: ffff96caa9ec3d28 R15: ffff96caa9ec3d40
> [ 774.574999] FS: 00007fbc7c4e2740(0000) GS:ffff96caabc00000(0000) knlGS:0000000000000000
> [ 774.575008] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> [ 774.575015] CR2: 0000000000000000 CR3: 0000000129d58000 CR4: 00000000000006f0
> [ 774.575021] Call Trace:
> [ 774.575036] ? cp_new_stat+0x12d/0x160
> [ 774.575048] hwmon_attr_show_string+0x37/0x70 [hwmon]
Sorry about that!
It looks like not all chips have temp_label, so I think we need to change w83627ehf_is_visible
which has:
if (attr == hwmon_temp_input || attr == hwmon_temp_label)
return 0444;
to
if (attr == hwmon_temp_input)
return 0444;
if (attr == hwmon_temp_label) {
if (data->temp_label)
return 0444;
else
return 0;
}
Does that work for you?
Dave
> [ 774.575060] dev_attr_show+0x14/0x50
> [ 774.575071] sysfs_kf_seq_show+0xb5/0x1b0
> [ 774.575081] seq_read+0xcf/0x460
> [ 774.575091] vfs_read+0x9b/0x150
> [ 774.575100] ksys_read+0x5f/0xe0
> [ 774.575111] do_syscall_64+0x48/0x190
> [ 774.575121] entry_SYSCALL_64_after_hwframe+0x44/0xa9
> [ 774.575130] RIP: 0033:0x7fbc7c715871
> [ 774.575138] Code: fe ff ff 50 48 8d 3d 76 e5 09 00 e8 e9 ef 01 00 66 0f 1f 84 00 00 00 00 00 48 8d 05 69 3b 0d 00 8b 00 85 c0 75 13 31 c0 0f 05 <48> 3d 00 f0 ff ff 77 57 c3 66 0f 1f 44 00 00 48 83 ec 28 48 89 54
> [ 774.575151] RSP: 002b:00007ffe5092d848 EFLAGS: 00000246 ORIG_RAX: 0000000000000000
> [ 774.575161] RAX: ffffffffffffffda RBX: 00005630bdfb1330 RCX: 00007fbc7c715871
> [ 774.575168] RDX: 0000000000001000 RSI: 00007ffe5092d8e0 RDI: 0000000000000003
> [ 774.575175] RBP: 00007fbc7c7e5560 R08: 0000000000000003 R09: 00007fbc7c7e43b0
> [ 774.575182] R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000001000
> [ 774.575190] R13: 00007ffe5092d8e0 R14: 0000000000000d68 R15: 00007fbc7c7e4960
> [ 774.575199] Modules linked in: w83627ehf hwmon_vid snd_hda_codec_realtek snd_hda_codec_generic snd_hda_intel snd_intel_dspcfg snd_hda_codec snd_hwdep snd_pcsp snd_hda_core ir_rc6_decoder rc_rc6_mce uas r8169 mceusb snd_pcm
> iTCO_wdt rc_core snd_timer iTCO_vendor_support realtek snd libphy soundcore i2c_i801 lpc_ich parport_pc mfd_core parport coretemp hwmon autofs4
> [ 774.575247] CR2: 0000000000000000
> [ 774.575254] ---[ end trace 607462057ab8a988 ]---
> [ 774.575264] RIP: 0010:w83627ehf_read_string+0x27/0x70 [w83627ehf]
> [ 774.575273] Code: 00 00 00 55 53 48 8d 64 24 f0 83 fa 15 48 8b 5f 78 75 29 83 fe 01 75 24 48 63 c9 48 8b 6b 58 48 83 f9 03 77 24 0f b6 44 0b 50 <48> 8b 44 c5 00 49 89 00 48 8d 64 24 10 5b 31 c0 5d c3 48 8d 64 24
> [ 774.575287] RSP: 0018:ffffb95980657df8 EFLAGS: 00010293
> [ 774.575294] RAX: 0000000000000000 RBX: ffff96caaa7f5218 RCX: 0000000000000000
> [ 774.575301] RDX: 0000000000000015 RSI: 0000000000000001 RDI: ffff96caa736ec08
> [ 774.575308] RBP: 0000000000000000 R08: ffffb95980657e20 R09: 0000000000000001
> [ 774.575316] R10: ffff96caaa635cc0 R11: 0000000000000000 R12: ffff96caa9f7cf00
> [ 774.575323] R13: ffff96caa9ec3d00 R14: ffff96caa9ec3d28 R15: ffff96caa9ec3d40
> [ 774.575331] FS: 00007fbc7c4e2740(0000) GS:ffff96caabc00000(0000) knlGS:0000000000000000
> [ 774.575340] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> [ 774.575347] CR2: 0000000000000000 CR3: 0000000129d58000 CR4: 00000000000006f0
>
>
> --
> Meelis Roos <mroos@linux.ee>
--
-----Open up your eyes, open up your mind, open up your code -------
/ Dr. David Alan Gilbert | Running GNU/Linux | Happy \
\ dave @ treblig.org | | In Hex /
\ _________________________|_____ http://www.treblig.org |_______/
^ permalink raw reply
* Re: [CFT 6/8] net: macb: use resolved link config in mac_link_up()
From: Andrew Lunn @ 2020-02-20 12:38 UTC (permalink / raw)
To: Russell King - ARM Linux admin
Cc: Alexandre Belloni, Florian Fainelli, Heiner Kallweit,
David S. Miller, netdev, Nicolas Ferre
In-Reply-To: <20200220101828.GV25745@shell.armlinux.org.uk>
> Thanks, that looks reasonable to me. I'll replace my patch with this
> one if it's appropriate for net-next when I send this series for
> merging. However, I see most affected network driver maintainers
> haven't responded yet, which is rather disappointing. So, thanks
> for taking the time to look at this.
Hi Russell
I suspect most maintainers are lazy. Give them a branch to pull, and
they might be more likely to test.
Andrew
^ permalink raw reply
* Re: [PATCH] babeltrace2: added 2.0.1
From: Anders Wallin @ 2020-02-20 12:38 UTC (permalink / raw)
To: Alexander Kanavin; +Cc: OE-core
In-Reply-To: <CANNYZj9t2+ugT15XbYrqkgA23MHEQxy_9t=PnutoCQr2f0AA-A@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1122 bytes --]
Hi Alex,
should I update the patch to include changes to maintainer file,
packagegroup etc in the same way as for babeltrace or
is it something you will do?
Anders Wallin
On Wed, Feb 19, 2020 at 5:02 PM Alexander Kanavin <alex.kanavin@gmail.com>
wrote:
> On Wed, 19 Feb 2020 at 16:56, Jonathan Rajotte-Julien <
> jonathan.rajotte-julien@efficios.com> wrote:
>
>> > There are some things where the namespaces are quite specific (python
>> > vs python3, gtk(+) 2/3/4, qt) but they're fairly few and far between.
>> >
>> > If babeltrace2 will replace babeltrace and become babeltrace, we
>> > probably want to keep PN as babeltrace. If it will be known as
>> > babeltrace2 always, we probably change PN.
>>
>> Babeltrace 2 executable will be forever named babeltrace2.
>>
>> Hope this clear up this part a bit.
>>
>
> Right, then I'm fine with naming the recipe babeltrace2.
>
> Alex
> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>
[-- Attachment #2: Type: text/html, Size: 2099 bytes --]
^ permalink raw reply
* Re: switching ARC to 64-bit time_t (Re: [RFC v6 07/23] RISC-V: Use 64-bit time_t and off_t for RV32 and RV64)
From: Arnd Bergmann @ 2020-02-20 12:37 UTC (permalink / raw)
To: Lukasz Majewski
Cc: Florian Weimer, Helmut Grohne, GNU C Library, Vineet Gupta,
Palmer Dabbelt, Zong Li, debian-arm, Alistair Francis,
Adhemerval Zanella, Maciej W. Rozycki, Alistair Francis, arcml,
Joseph Myers
In-Reply-To: <20200220103716.2f526933@jawa>
On Thu, Feb 20, 2020 at 10:37 AM Lukasz Majewski <lukma@denx.de> wrote:
> > On Thu, Feb 20, 2020 at 12:11 AM Lukasz Majewski <lukma@denx.de>
> >
> > Would it be possible to take a snapshot of your glibc tree
>
> The description of the status of Y2038 supporting glibc on ARM 32 can
> be found here [1].
>
> The most recent patches for Y2038 supporting glibc can be always found
> in the 'y2038_edge' branch [2].
Ok.
> > and start testing this out with debian-rebootstrap [1]?
>
> I've been using OE/Yocto for testing as it allows building glibc
> sources for x86_64, x86, x86-x32, arm32 (probably also for ppc32 and
> mips - but not tested).
>...
> However, I did not yet tried debian-rebootstrap. I will look if this
> can be reused as well.
The reason I'm asking about debian-rebootstrap is less about testing
glibc itself than about testing the rest of user space to figure out better
what needs to be done when rebuilding with _TIME_BITS=64, and to
start fixing more upstream packages, with the hope of having enough
of it done in time for the Debian 11 release.
> > Are there any glibc issues that prevent it from working correctly,
>
> I think that the glibc wrappers for most important syscalls are now
> converted.
>
> What is missing:
>
> - NTPL (threads)
> - stat
Do you mean that code using these will fail to work correctly with
-D_TIME_BITS=64 at the moment, or that the interfaces are there
but they are not y2038 safe? Without pthreads or stat, we probably
wouldn't get too far in rebootstrap, but if the interfaces are there
and mostly work, then we don't need to rely on them being
y2038-safe just yet. An obvious next step would be to run the
resulting code with the RTC set 20 years ahead, and that requires
it all to work.
> - In-glibc test coverage when -D_TIME_BITS=64 is used. I do have
> some basic tests [4], but this may be not enough.
This is probably something where debian-rebootstrap could help,
as building and testing more user space packages will excercise
additional code paths in glibc as well. There is also some work
in Linaro to ensure that LTP tests the low-level syscall interfaces
in both the time32 and time64 variants.
Arnd
_______________________________________________
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
^ permalink raw reply
* Re: [PATCH v3 04/22] x86/doublefault: Make memmove() notrace/NOKPROBE
From: Peter Zijlstra @ 2020-02-20 12:37 UTC (permalink / raw)
To: Borislav Petkov
Cc: Steven Rostedt, linux-kernel, linux-arch, mingo, joel, gregkh,
gustavo, tglx, paulmck, josh, mathieu.desnoyers, jiangshanlai,
luto, tony.luck, frederic, dan.carpenter, mhiramat
In-Reply-To: <20200220121727.GB507@zn.tnic>
On Thu, Feb 20, 2020 at 01:17:27PM +0100, Borislav Petkov wrote:
> On Wed, Feb 19, 2020 at 04:57:15PM +0100, Peter Zijlstra wrote:
> > - memmove(&gpregs->ip, (void *)regs->sp, 5*8);
> > + for (i = 0; i < count; i++) {
> > + int idx = (dst <= src) ? i : count - i;
> > + dst[idx] = src[idx];
> > + }
>
> Or, you can actually unroll it. This way it even documents clearly what
> it does:
>
> diff --git a/arch/x86/kernel/traps.c b/arch/x86/kernel/traps.c
> index fe38015ed50a..2b790a574ba5 100644
> --- a/arch/x86/kernel/traps.c
> +++ b/arch/x86/kernel/traps.c
> @@ -298,6 +298,7 @@ dotraplinkage void do_double_fault(struct pt_regs *regs, long error_code, unsign
> regs->ip == (unsigned long)native_irq_return_iret)
> {
> struct pt_regs *gpregs = (struct pt_regs *)this_cpu_read(cpu_tss_rw.x86_tss.sp0) - 1;
> + unsigned long *p = (unsigned long *)regs->sp;
>
> /*
> * regs->sp points to the failing IRET frame on the
> @@ -305,7 +306,11 @@ dotraplinkage void do_double_fault(struct pt_regs *regs, long error_code, unsign
> * in gpregs->ss through gpregs->ip.
> *
> */
> - memmove(&gpregs->ip, (void *)regs->sp, 5*8);
> + gpregs->ip = *p;
> + gpregs->cs = *(p + 1);
> + gpregs->flags = *(p + 2);
> + gpregs->sp = *(p + 3);
> + gpregs->ss = *(p + 4);
> gpregs->orig_ax = 0; /* Missing (lost) #GP error code */
>
> /*
While I love that; is that actually correct? This is an unroll of
memcpy() not memmove(). IFF the ranges overlap, the above is buggered.
Was the original memmove() really needed?
^ permalink raw reply
* [Buildroot] [Bug 12571] New: ltp-testsuite : Build failure
From: bugzilla at busybox.net @ 2020-02-20 12:37 UTC (permalink / raw)
To: buildroot
https://bugs.busybox.net/show_bug.cgi?id=12571
Bug ID: 12571
Summary: ltp-testsuite : Build failure
Product: buildroot
Version: 2019.11.1
Hardware: All
OS: Linux
Status: NEW
Severity: normal
Priority: P5
Component: Other
Assignee: unassigned at buildroot.uclibc.org
Reporter: learn2kab at gmail.com
CC: buildroot at uclibc.org
Target Milestone: ---
Hello,
While trying to prepare images for Beaglebone Black with "ltp-testsuite"
included (keeping other parameters to their default values),the build process
breaks .
-----------------------------
Error Message with Default Settings:
-----------------------------
Allocating group tables: done
Writing inode tables: done
Creating journal (4096 blocks): done
Copying files into the device: __populate_fs: Could not allocate block in ext2
filesystem while writing file "fanotify10"
mkfs.ext4: Could not allocate block in ext2 filesystem while populating file
system
*** Maybe you need to increase the filesystem size
(BR2_TARGET_ROOTFS_EXT2_SIZE)
fs/ext2/ext2.mk:46: recipe for target
'/home/workpc/dir_buildroot/buildroot-2019.11.1/output/images/rootfs.ext2'
failed
make[1]: ***
[/home/workpc/dir_buildroot/buildroot-2019.11.1/output/images/rootfs.ext2]
Error 1
Makefile:84: recipe for target '_all' failed
make: *** [_all] Error 2
-----------------------------
Updated the value of "BR2_TARGET_ROOTFS_EXT2_SIZE" from 60M to 64G.
An error message mentioning
"part rootfs size (536870912) too small for rootfs.ext4 (68719476736)"
(as below) appears in the build log.
-------------------------------
Error Message with Modified Values:
-------------------------------
INFO: cmd: "find
'/home/workpc/dir_buildroot/buildroot-2019.11.1/output/build/genimage.tmp/root'
-depth -type d -printf '%P\0' | xargs -0 -I {} touch -r
'/tmp/tmp.7ROXYVc0KU/{}'
'/home/workpc/dir_buildroot/buildroot-2019.11.1/output/build/genimage.tmp/root/{}'"
(stderr):
ERROR: hdimage(sdcard.img): part rootfs size (536870912) too small for
rootfs.ext4 (68719476736)
Makefile:809: recipe for target 'target-post-image' failed
make[1]: *** [target-post-image] Error 1
Makefile:84: recipe for target '_all' failed
make: *** [_all] Error 2
--------------------------------
What would be the apt value for this parameter??
Should any other parameter be accordingly modified??
Please advice.
Regards,
Adarsh
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply
* [Intel-gfx] [PATCH 1/2] drm/i915: Double check bumping after the spinlock
From: Chris Wilson @ 2020-02-20 12:36 UTC (permalink / raw)
To: intel-gfx; +Cc: matthew.auld
In preparation for making GEM execbuf parallel, we need to be prepared
to handle very early declaration of dependencies -- even before our
signaler has itself been submitted.
References: a79ca656b648 ("drm/i915: Push the wakeref->count deferral to the backend")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
---
drivers/gpu/drm/i915/i915_scheduler.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_scheduler.c b/drivers/gpu/drm/i915/i915_scheduler.c
index 59f70b674665..be770f2419b1 100644
--- a/drivers/gpu/drm/i915/i915_scheduler.c
+++ b/drivers/gpu/drm/i915/i915_scheduler.c
@@ -363,6 +363,9 @@ static void __bump_priority(struct i915_sched_node *node, unsigned int bump)
{
struct i915_sched_attr attr = node->attr;
+ if (attr.priority & bump)
+ return;
+
attr.priority |= bump;
__i915_schedule(node, &attr);
}
--
2.25.1
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply related
* [Intel-gfx] [PATCH 2/2] drm/i915: Protect i915_request_await_start from early waits
From: Chris Wilson @ 2020-02-20 12:36 UTC (permalink / raw)
To: intel-gfx; +Cc: matthew.auld
In-Reply-To: <20200220123608.1666271-1-chris@chris-wilson.co.uk>
We need to be extremely careful inside i915_request_await_start() as it
needs to walk the list of requests in the foreign timeline with very
little protection. As we hold our own timeline mutex, we can not nest
inside the signaler's timeline mutex, so all that remains is our RCU
protection. However, to be safe we need to tell the compiler that we may
be traversing the list only under RCU protection, and furthermore we
need to start declaring requests as elements of the timeline from their
construction.
Fixes: 9ddc8ec027a3 ("drm/i915: Eliminate the trylock for awaiting an earlier request")
Fixes: 6a79d848403d ("drm/i915: Lock signaler timeline while navigating")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
---
drivers/gpu/drm/i915/i915_request.c | 43 ++++++++++++++++++++---------
1 file changed, 30 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_request.c b/drivers/gpu/drm/i915/i915_request.c
index d53af93b919b..28f135ebeaa0 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -290,7 +290,7 @@ bool i915_request_retire(struct i915_request *rq)
spin_unlock_irq(&rq->lock);
remove_from_client(rq);
- list_del(&rq->link);
+ list_del_rcu(&rq->link);
intel_context_exit(rq->context);
intel_context_unpin(rq->context);
@@ -736,6 +736,8 @@ __i915_request_create(struct intel_context *ce, gfp_t gfp)
rq->infix = rq->ring->emit; /* end of header; start of user payload */
intel_context_mark_active(ce);
+ list_add_tail_rcu(&rq->link, &tl->requests);
+
return rq;
err_unwind:
@@ -792,13 +794,21 @@ i915_request_await_start(struct i915_request *rq, struct i915_request *signal)
GEM_BUG_ON(i915_request_timeline(rq) ==
rcu_access_pointer(signal->timeline));
+ if (i915_request_started(signal))
+ return 0;
+
fence = NULL;
rcu_read_lock();
spin_lock_irq(&signal->lock);
- if (!i915_request_started(signal) &&
- !list_is_first(&signal->link,
- &rcu_dereference(signal->timeline)->requests)) {
- struct i915_request *prev = list_prev_entry(signal, link);
+ do {
+ struct list_head *pos = READ_ONCE(signal->link.prev);
+ struct i915_request *prev;
+
+ if (i915_request_started(signal))
+ break;
+
+ if (pos == &rcu_dereference(signal->timeline)->requests)
+ break;
/*
* Peek at the request before us in the timeline. That
@@ -806,13 +816,22 @@ i915_request_await_start(struct i915_request *rq, struct i915_request *signal)
* after acquiring a reference to it, confirm that it is
* still part of the signaler's timeline.
*/
- if (i915_request_get_rcu(prev)) {
- if (list_next_entry(prev, link) == signal)
- fence = &prev->fence;
- else
- i915_request_put(prev);
+ prev = list_entry(pos, typeof(*prev), link);
+ if (!i915_request_get_rcu(prev))
+ break;
+
+ if (i915_request_completed(prev)) {
+ i915_request_put(prev);
+ break;
}
- }
+
+ if (READ_ONCE(prev->link.next) != &signal->link) {
+ i915_request_put(prev);
+ break;
+ }
+
+ fence = &prev->fence;
+ } while (0);
spin_unlock_irq(&signal->lock);
rcu_read_unlock();
if (!fence)
@@ -1253,8 +1272,6 @@ __i915_request_add_to_timeline(struct i915_request *rq)
0);
}
- list_add_tail(&rq->link, &timeline->requests);
-
/*
* Make sure that no request gazumped us - if it was allocated after
* our i915_request_alloc() and called __i915_request_add() before
--
2.25.1
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply related
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.