Re: [PATCH RFC v2 02/18] irq/dev-msi: Add support for a new DEV_MSI irq domain
Hi Thomas, On 8/7/2020 9:47 AM, Thomas Gleixner wrote: Jason Gunthorpe writes: Though it is more of a rational and a cookbook on how to combine existing technology pieces. (eg PASID, platform_msi, etc) The basic approach of SIOV's IMS is that there is no longer a generic interrupt indirection from numbers to addr/data pairs like IOAPIC/MSI/MSI-X owned by the common OS code. Instead the driver itself is responsible to set the addr/data pair into the device in a device specific way, deal with masking, etc. This lets the device use an implementation that is not limited by the harsh MSI-X semantics. In Linux we already have 'IMS' it is called platform_msi and a few embedded drivers already work like this. The idea here is to bring it to PCI. platform_msi as it exists today is a crutch and in hindsight I should have payed more attention back then and shoot it down before it got merged. IMS can be somehow mapped to platform MSI but the proposed approach to extend platform MSI with the extra bolts for IMS (valid for one particular incarnation) is just going into the wrong direction. We've been there and the main reason why hierarchical irq domains exist is that we needed to make a clear cut between the involved hardware pieces and their drivers. The pre hierarchy model was a maze of stuff calling back and forth between layers with lots of duct tape added to make it "work". This finally fell apart when Intel tried to support I/O-APIC hotplug. The ARM people had similar issues with all the special irq related SoC specific IP blocks which are placed between the CPU level interrupt controller and the device. The hierarchy strictly seperates the per layer resource management and each layer can work mostly independent of the actual available parent layer. Now looking at IMS. It's a subsystem inside a physical device. It has slot management (where to place the Message) and mask/unmask. Resource management at that level is what irq domains are for and mask/unmask is what a irq chip handles. So the right thing to do is to create shared infrastructure which is utilized by the device drivers by providing a few bog standard data structures and the handful of device specific domain and irq functions. That keeps the functionality common, but avoids that we end up with - msi_desc becoming a dump ground for random driver data - a zoo of platform callbacks - glued on driver specific resource management and all the great hacks which it requires to work on hundreds of different devices which all implement IMS differently. I'm all for sharing code and making the life of driver writers simple because that makes my life simple as well, but not by creating a layer at the wrong level and then hacking it into submission until it finally collapses. Designing the infrastructure following the clear layering rules of hierarchical domains so it works for IMS and also replaces the platform MSI hack is the only sane way to go forward, not the other way round. From what I've gathered, I need to: 1. Get rid of the mantra that "IMS" is an extension of platform-msi. 2. Make this new infra devoid of any platform-msi references 3. Come up with a ground up approach which adheres to the layering constraints of the IRQ subsystem 4. Have common code (drivers/irqchip maybe??) where we put in all the generic ims-specific bits for the IRQ chip and domain which can be used by all device drivers belonging to this "IMS"class. 5. Have the device driver do the rest: create the chip/domain (one chip/domain per device?) provide device specific callbacks for masking, unmasking, write message So from the hierarchical domain standpoint, we will have: - For DSA device: vector->intel-IR->IDXD - For Jason's device: root domain-> domain A-> Jason's device's IRQ domain - For any other intel IMS device in the future which does not require interrupt remapping: vector->new device IRQ domain requires interrupt remapping: vector->intel-IR->new device IRQ domain (i.e. create a new domain even though IDXD is already present?) Please let me know if my understanding is correct. What I still don't understand fully is what if all the IMS devices need the same domain ops and chip callbacks, we will be creating various instances of the same IRQ chip and domain right? Is that ok? Currently the creation of the IRQ domain happens at the IR level so that we can reuse the same domain but if it advisable to have a per device interrupt domain, I will shift this to the device driver. Thanks, tglx
Re: [PATCH] KVM: SVM: Mark SEV launch secret pages as dirty.
On Thu, 6 Aug 2020, Cfir Cohen wrote: > The LAUNCH_SECRET command performs encryption of the > launch secret memory contents. Mark pinned pages as > dirty, before unpinning them. > This matches the logic in sev_launch_update(). > > Signed-off-by: Cfir Cohen Acked-by: David Rientjes
Re: [PATCH v2] arm64: kaslr: Use standard early random function
On Fri, Aug 7, 2020 at 10:35 AM Catalin Marinas wrote: > > Acked-by: Catalin Marinas > > Linus, could you please pick this up directly? Otherwise, it will wait > until we reach -rc1 to avoid basing a branch on a random commit. Already done, since I was the cause of the mess. But because I did it early, your Acked-by didn't get in. Linus
Re: [PATCH v4] kvm,x86: Exit to user space in case page fault error
On Mon, Jul 20, 2020 at 05:13:59PM -0400, Vivek Goyal wrote:
> Page fault error handling behavior in kvm seems little inconsistent when
> page fault reports error. If we are doing fault synchronously
> then we capture error (-EFAULT) returned by __gfn_to_pfn_memslot() and
> exit to user space and qemu reports error, "error: kvm run failed Bad
> address".
Hi Paolo,
Ping. I am wondering what do you think about this patch. Can it be
merged?
Thanks
Vivek
>
> But if we are doing async page fault, then async_pf_execute() will simply
> ignore the error reported by get_user_pages_remote() or
> by kvm_mmu_do_page_fault(). It is assumed that page fault was successful
> and either a page ready event is injected in guest or guest is brought
> out of artificial halt state and run again. In both the cases when guest
> retries the instruction, it takes exit again as page fault was not
> successful in previous attempt. And then this infinite loop continues
> forever.
>
> Trying fault in a loop will make sense if error is temporary and will
> be resolved on retry. But I don't see any intention in the code to
> determine if error is temporary or not. Whether to do fault synchronously
> or asynchronously, depends on so many variables but none of the varibales
> is whether error is temporary or not. (kvm_can_do_async_pf()).
>
> And that makes it very inconsistent or unpredictable to figure out whether
> kvm will exit to qemu with error or it will just retry and go into an
> infinite loop.
>
> This patch tries to make this behavior consistent. That is instead of
> getting into infinite loop of retrying page fault, exit to user space
> and stop VM if page fault error happens.
>
> In future this can be improved by injecting errors into guest. As of
> now we don't have any race free method to inject errors in guest.
>
> When page fault error happens in async path save that pfn and when next
> time guest retries, do a sync fault instead of async fault. So that if error
> is encountered, we exit to qemu and avoid infinite loop.
>
> We maintain a cache of error gfns and force sync fault if a gfn is
> found in cache of error gfn. There is a small possibility that we
> miss an error gfn (as it got overwritten by a new error gfn). But
> its just a hint and sooner or later some error pfn will match
> and we will force sync fault and exit to user space.
>
> Changes from v3:
> - Added function kvm_find_and_remove_error_gfn() and removed
> kvm_find_error_gfn() and kvm_del_error_gfn(). (Vitaly)
>
> - Added a macro GFN_INVALID (Vitaly).
>
> - Used gpa_to_gfn() to convert gpa to gfn (Vitaly)
>
> Change from v2:
> - Fixed a warning by converting kvm_find_error_gfn() static.
>
> Change from v1:
> - Maintain a cache of error gfns, instead of single gfn. (Vitaly)
>
> Signed-off-by: Vivek Goyal
> ---
> arch/x86/include/asm/kvm_host.h | 2 ++
> arch/x86/kvm/mmu.h | 2 +-
> arch/x86/kvm/mmu/mmu.c | 2 +-
> arch/x86/kvm/x86.c | 54 +++--
> include/linux/kvm_types.h | 1 +
> 5 files changed, 56 insertions(+), 5 deletions(-)
>
> diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
> index be5363b21540..e6f8d3f1a377 100644
> --- a/arch/x86/include/asm/kvm_host.h
> +++ b/arch/x86/include/asm/kvm_host.h
> @@ -137,6 +137,7 @@ static inline gfn_t gfn_to_index(gfn_t gfn, gfn_t
> base_gfn, int level)
> #define KVM_NR_VAR_MTRR 8
>
> #define ASYNC_PF_PER_VCPU 64
> +#define ERROR_GFN_PER_VCPU 64
>
> enum kvm_reg {
> VCPU_REGS_RAX = __VCPU_REGS_RAX,
> @@ -778,6 +779,7 @@ struct kvm_vcpu_arch {
> unsigned long nested_apf_token;
> bool delivery_as_pf_vmexit;
> bool pageready_pending;
> + gfn_t error_gfns[ERROR_GFN_PER_VCPU];
> } apf;
>
> /* OSVW MSRs (AMD only) */
> diff --git a/arch/x86/kvm/mmu.h b/arch/x86/kvm/mmu.h
> index 444bb9c54548..d0a2a12c7bb6 100644
> --- a/arch/x86/kvm/mmu.h
> +++ b/arch/x86/kvm/mmu.h
> @@ -60,7 +60,7 @@ void kvm_init_mmu(struct kvm_vcpu *vcpu, bool reset_roots);
> void kvm_init_shadow_mmu(struct kvm_vcpu *vcpu, u32 cr0, u32 cr4, u32 efer);
> void kvm_init_shadow_ept_mmu(struct kvm_vcpu *vcpu, bool execonly,
>bool accessed_dirty, gpa_t new_eptp);
> -bool kvm_can_do_async_pf(struct kvm_vcpu *vcpu);
> +bool kvm_can_do_async_pf(struct kvm_vcpu *vcpu, gfn_t gfn);
> int kvm_handle_page_fault(struct kvm_vcpu *vcpu, u64 error_code,
> u64 fault_address, char *insn, int insn_len);
>
> diff --git a/arch/x86/kvm/mmu/mmu.c b/arch/x86/kvm/mmu/mmu.c
> index 6d6a0ae7800c..b51d4aa405e0 100644
> --- a/arch/x86/kvm/mmu/mmu.c
> +++ b/arch/x86/kvm/mmu/mmu.c
> @@ -4078,7 +4078,7 @@ static bool try_async_pf(struct kvm_vcpu *vcpu, bool
> prefault, gfn_t gfn,
> if (!async)
> return false; /* *pfn has correct page already */
>
> - if (!prefault && kvm_can_do_async_pf(vcpu)
Re: wine fails to start with seccomp updates for v5.9-rc1
Excerpts from Thadeu Lima de Souza Cascardo's message of August 7, 2020 1:36 pm:
> On Fri, Aug 07, 2020 at 08:48:46AM -0700, Linus Torvalds wrote:
>> On Fri, Aug 7, 2020 at 8:19 AM Alex Xu (Hello71) wrote:
>> >
>> > On Linus' master, wine fails to start with the following error:
>> >
>> > wine client error:0: write: Bad file descriptor
>> >
>> > This issue is not present on 5.8. It appears to be caused by failure to
>> > write to a pipe FD received via SCM_RIGHTS. Therefore, I tried reverting
>> > 9ecc6ea491f0, which resolved the issue.
>>
>> Would you mind trying to bisect exactly where it happens?
>>
>
> This report [1] seemed related and pointed out at c0029de50982 ("net/scm:
> Regularize compat handling of scm_detach_fds()"). The use of CMSG_USER_DATA
> instead of CMSG_COMPAT_DATA seems fishy.
>
> Alex, can you try applying the patch below?
>
> Cascardo.
>
> [1] https://lists.ozlabs.org/pipermail/linuxppc-dev/2020-August/216156.html
>
>> I don't think any of the commits in that pull are supposed to change
>> semantics, and while reverting the whole merge shows that yes, that's
>> what brought in the problems, it would be good to pinpoint just which
>> change breaks so that we can fix just that thing.
>>
>> Kees, ideas?
>>
>> Linus
>
> ---
> diff --git a/net/compat.c b/net/compat.c
> index 703acb51c698..95ce707a30a3 100644
> --- a/net/compat.c
> +++ b/net/compat.c
> @@ -294,7 +294,7 @@ void scm_detach_fds_compat(struct msghdr *msg, struct
> scm_cookie *scm)
> (struct compat_cmsghdr __user *)msg->msg_control;
> unsigned int o_flags = (msg->msg_flags & MSG_CMSG_CLOEXEC) ? O_CLOEXEC
> : 0;
> int fdmax = min_t(int, scm_max_fds_compat(msg), scm->fp->count);
> - int __user *cmsg_data = CMSG_USER_DATA(cm);
> + int __user *cmsg_data = CMSG_COMPAT_DATA(cm);
> int err = 0, i;
>
> for (i = 0; i < fdmax; i++) {
>
Yes, this seems to work.
Tested-by: Alex Xu (Hello71)
Thanks!
Re: [PATCH 1/2 v2] rseq/membarrier: add MEMBARRIER_CMD_PRIVATE_RESTART_RSEQ_ON_CPU
On Fri, Aug 7, 2020 at 6:38 AM wrote:
>
[...]
> I'm thinking even this is a problem, we can end up sending IPIs to CPUs
> outside out partition (they might be NOHZ_FULL) and that's a no-no too.
>
> Something like so perhaps... that really limits it to CPUs that match
> our mm.
Thanks for the suggestion - I'll prepare a v3 based on your and
Mathieu's feedback.
>
> diff --git a/include/linux/sched/mm.h b/include/linux/sched/mm.h
> index 6be66f52a2ad..bee5e98e6774 100644
> --- a/include/linux/sched/mm.h
> +++ b/include/linux/sched/mm.h
> @@ -356,6 +356,7 @@ enum {
>
> enum {
> MEMBARRIER_FLAG_SYNC_CORE = (1U << 0),
> + MEMBARRIER_FLAG_RSEQ= (1U << 1),
> };
>
> #ifdef CONFIG_ARCH_HAS_MEMBARRIER_CALLBACKS
> diff --git a/kernel/sched/membarrier.c b/kernel/sched/membarrier.c
> index 168479a7d61b..4d9b22c2f5e2 100644
> --- a/kernel/sched/membarrier.c
> +++ b/kernel/sched/membarrier.c
> @@ -27,6 +27,11 @@
>
> static void ipi_mb(void *info)
> {
> + int *flags = info;
> +
> + if (flags && (*flags & MEMBARRIER_FLAG_RSEQ))
> + rseq_preempt(current);
> +
> smp_mb(); /* IPIs should be serializing but paranoid. */
> }
>
> @@ -129,11 +134,11 @@ static int membarrier_global_expedited(void)
> return 0;
> }
>
> -static int membarrier_private_expedited(int flags)
> +static int membarrier_private_expedited(int flags, int cpu_id)
> {
> - int cpu;
> - cpumask_var_t tmpmask;
> struct mm_struct *mm = current->mm;
> + cpumask_var_t tmpmask;
> + int cpu;
>
> if (flags & MEMBARRIER_FLAG_SYNC_CORE) {
> if (!IS_ENABLED(CONFIG_ARCH_HAS_MEMBARRIER_SYNC_CORE))
> @@ -174,6 +179,10 @@ static int membarrier_private_expedited(int flags)
> */
> if (cpu == raw_smp_processor_id())
> continue;
> +
> + if (cpu_id >= 0 && cpu != cpu_id)
> + continue;
> +
> p = rcu_dereference(cpu_rq(cpu)->curr);
> if (p && p->mm == mm)
> __cpumask_set_cpu(cpu, tmpmask);
> @@ -181,7 +190,7 @@ static int membarrier_private_expedited(int flags)
> rcu_read_unlock();
>
> preempt_disable();
> - smp_call_function_many(tmpmask, ipi_mb, NULL, 1);
> + smp_call_function_many(tmpmask, ipi_mb, &flags, 1);
> preempt_enable();
>
> free_cpumask_var(tmpmask);
> @@ -362,11 +371,13 @@ SYSCALL_DEFINE2(membarrier, int, cmd, int, flags)
> case MEMBARRIER_CMD_REGISTER_GLOBAL_EXPEDITED:
> return membarrier_register_global_expedited();
> case MEMBARRIER_CMD_PRIVATE_EXPEDITED:
> - return membarrier_private_expedited(0);
> + return membarrier_private_expedited(0, -1);
> case MEMBARRIER_CMD_REGISTER_PRIVATE_EXPEDITED:
> return membarrier_register_private_expedited(0);
> case MEMBARRIER_CMD_PRIVATE_EXPEDITED_SYNC_CORE:
> - return
> membarrier_private_expedited(MEMBARRIER_FLAG_SYNC_CORE);
> + return
> membarrier_private_expedited(MEMBARRIER_FLAG_SYNC_CORE, -1);
> + case MEMBERRIER_CMD_PRIVATE_EXPEDITED_RSEQ:
> + return membarrier_private_expedited(MEMBARRIER_FLAG_RSEQ,
> flags);
> case MEMBARRIER_CMD_REGISTER_PRIVATE_EXPEDITED_SYNC_CORE:
> return
> membarrier_register_private_expedited(MEMBARRIER_FLAG_SYNC_CORE);
> default:
[PATCH 6/7] ARM: dts: r8a7742: Add LVDS support
Add LVDS encoder node to r8a7742 SoC DT.
Signed-off-by: Lad Prabhakar
Reviewed-by: Marian-Cristian Rotariu
---
arch/arm/boot/dts/r8a7742.dtsi | 54 ++
1 file changed, 54 insertions(+)
diff --git a/arch/arm/boot/dts/r8a7742.dtsi b/arch/arm/boot/dts/r8a7742.dtsi
index a979a4b3de61..a7e66220d63a 100644
--- a/arch/arm/boot/dts/r8a7742.dtsi
+++ b/arch/arm/boot/dts/r8a7742.dtsi
@@ -1534,11 +1534,65 @@
port@1 {
reg = <1>;
du_out_lvds0: endpoint {
+ remote-endpoint = <&lvds0_in>;
};
};
port@2 {
reg = <2>;
du_out_lvds1: endpoint {
+ remote-endpoint = <&lvds1_in>;
+ };
+ };
+ };
+ };
+
+ lvds0: lvds@feb9 {
+ compatible = "renesas,r8a7742-lvds";
+ reg = <0 0xfeb9 0 0x1c>;
+ clocks = <&cpg CPG_MOD 726>;
+ power-domains = <&sysc R8A7742_PD_ALWAYS_ON>;
+ resets = <&cpg 726>;
+ status = "disabled";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ lvds0_in: endpoint {
+ remote-endpoint =
<&du_out_lvds0>;
+ };
+ };
+ port@1 {
+ reg = <1>;
+ lvds0_out: endpoint {
+ };
+ };
+ };
+ };
+
+ lvds1: lvds@feb94000 {
+ compatible = "renesas,r8a7742-lvds";
+ reg = <0 0xfeb94000 0 0x1c>;
+ clocks = <&cpg CPG_MOD 725>;
+ power-domains = <&sysc R8A7742_PD_ALWAYS_ON>;
+ resets = <&cpg 725>;
+ status = "disabled";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ lvds1_in: endpoint {
+ remote-endpoint =
<&du_out_lvds1>;
+ };
+ };
+ port@1 {
+ reg = <1>;
+ lvds1_out: endpoint {
};
};
};
--
2.17.1
[PATCH 5/7] ARM: dts: r8a7742: Add DU support
Add du node to r8a7742 SoC DT. Boards that want to enable the DU
need to specify the output topology.
Signed-off-by: Lad Prabhakar
Reviewed-by: Marian-Cristian Rotariu
---
arch/arm/boot/dts/r8a7742.dtsi | 35 ++
1 file changed, 35 insertions(+)
diff --git a/arch/arm/boot/dts/r8a7742.dtsi b/arch/arm/boot/dts/r8a7742.dtsi
index 4a8d27dff9f7..a979a4b3de61 100644
--- a/arch/arm/boot/dts/r8a7742.dtsi
+++ b/arch/arm/boot/dts/r8a7742.dtsi
@@ -1509,6 +1509,41 @@
resets = <&cpg 408>;
};
+ du: display@feb0 {
+ compatible = "renesas,du-r8a7742";
+ reg = <0 0xfeb0 0 0x7>;
+ interrupts = ,
+,
+;
+ clocks = <&cpg CPG_MOD 724>, <&cpg CPG_MOD 723>,
+<&cpg CPG_MOD 722>;
+ clock-names = "du.0", "du.1", "du.2";
+ resets = <&cpg 724>;
+ reset-names = "du.0";
+ status = "disabled";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ du_out_rgb: endpoint {
+ };
+ };
+ port@1 {
+ reg = <1>;
+ du_out_lvds0: endpoint {
+ };
+ };
+ port@2 {
+ reg = <2>;
+ du_out_lvds1: endpoint {
+ };
+ };
+ };
+ };
+
prr: chipid@ff44 {
compatible = "renesas,prr";
reg = <0 0xff44 0 4>;
--
2.17.1
[PATCH 2/7] drm: rcar-du: Add r8a7742 support
Add direct support for the r8a7742 (RZ/G1H).
The RZ/G1H shares a common, compatible configuration with the r8a7790
(R-Car H2) so that device info structure is reused, the only difference
being TCON is unsupported on RZ/G1H (Currently unsupported by the driver).
Signed-off-by: Lad Prabhakar
Reviewed-by: Marian-Cristian Rotariu
---
drivers/gpu/drm/rcar-du/rcar_du_drv.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_drv.c
b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
index 3e67cf70f040..7e286c7a7a6c 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_drv.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
@@ -216,8 +216,8 @@ static const struct rcar_du_device_info
rcar_du_r8a7790_info = {
.channels_mask = BIT(2) | BIT(1) | BIT(0),
.routes = {
/*
-* R8A7790 has one RGB output, two LVDS outputs and one
-* (currently unsupported) TCON output.
+* R8A7742 and R8A7790 each have one RGB output and two LVDS
outputs. Additionally
+* R8A7790 supports one TCON output (currently unsupported by
the driver).
*/
[RCAR_DU_OUTPUT_DPAD0] = {
.possible_crtcs = BIT(2) | BIT(1) | BIT(0),
@@ -443,6 +443,7 @@ static const struct rcar_du_device_info
rcar_du_r8a7799x_info = {
};
static const struct of_device_id rcar_du_of_table[] = {
+ { .compatible = "renesas,du-r8a7742", .data = &rcar_du_r8a7790_info },
{ .compatible = "renesas,du-r8a7743", .data = &rzg1_du_r8a7743_info },
{ .compatible = "renesas,du-r8a7744", .data = &rzg1_du_r8a7743_info },
{ .compatible = "renesas,du-r8a7745", .data = &rzg1_du_r8a7745_info },
--
2.17.1
[PATCH 3/7] dt-bindings: display: renesas,lvds: Document r8a7742 bindings
Document the RZ/G1H (R8A7742) LVDS bindings. Signed-off-by: Lad Prabhakar Reviewed-by: Marian-Cristian Rotariu --- .../devicetree/bindings/display/bridge/renesas,lvds.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/display/bridge/renesas,lvds.txt b/Documentation/devicetree/bindings/display/bridge/renesas,lvds.txt index c62ce2494ed9..40aa809f41cd 100644 --- a/Documentation/devicetree/bindings/display/bridge/renesas,lvds.txt +++ b/Documentation/devicetree/bindings/display/bridge/renesas,lvds.txt @@ -7,6 +7,7 @@ Gen2, R-Car Gen3 and RZ/G SoCs. Required properties: - compatible : Shall contain one of + - "renesas,r8a7742-lvds" for R8A7742 (RZ/G1H) compatible LVDS encoders - "renesas,r8a7743-lvds" for R8A7743 (RZ/G1M) compatible LVDS encoders - "renesas,r8a7744-lvds" for R8A7744 (RZ/G1N) compatible LVDS encoders - "renesas,r8a774a1-lvds" for R8A774A1 (RZ/G2M) compatible LVDS encoders -- 2.17.1
[PATCH 7/7] ARM: dts: r8a7742-iwg21d-q7: Add LCD support
The iwg21d comes with a 7" capacitive touch screen, therefore
add support for it.
Signed-off-by: Lad Prabhakar
Reviewed-by: Marian-Cristian Rotariu
---
arch/arm/boot/dts/r8a7742-iwg21d-q7.dts | 84 +
1 file changed, 84 insertions(+)
diff --git a/arch/arm/boot/dts/r8a7742-iwg21d-q7.dts
b/arch/arm/boot/dts/r8a7742-iwg21d-q7.dts
index b3461a61a4bf..cf59fd61e422 100644
--- a/arch/arm/boot/dts/r8a7742-iwg21d-q7.dts
+++ b/arch/arm/boot/dts/r8a7742-iwg21d-q7.dts
@@ -30,6 +30,7 @@
/dts-v1/;
#include "r8a7742-iwg21m.dtsi"
+#include
/ {
model = "iWave Systems RainboW-G21D-Qseven board based on RZ/G1H";
@@ -52,6 +53,50 @@
clock-frequency = <2600>;
};
+ lcd_backlight: backlight {
+ compatible = "pwm-backlight";
+ pwms = <&tpu 2 500 0>;
+ brightness-levels = <0 4 8 16 32 64 128 255>;
+ pinctrl-0 = <&backlight_pins>;
+ pinctrl-names = "default";
+ default-brightness-level = <7>;
+ enable-gpios = <&gpio3 11 GPIO_ACTIVE_HIGH>;
+ };
+
+ lvds-receiver {
+ compatible = "ti,ds90cf384a", "lvds-decoder";
+ powerdown-gpios = <&gpio5 28 GPIO_ACTIVE_LOW>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ lvds_receiver_in: endpoint {
+ remote-endpoint = <&lvds0_out>;
+ };
+ };
+ port@1 {
+ reg = <1>;
+ lvds_receiver_out: endpoint {
+ remote-endpoint = <&panel_in>;
+ };
+ };
+ };
+ };
+
+ panel {
+ compatible = "edt,etm0700g0dh6";
+ backlight = <&lcd_backlight>;
+
+ port {
+ panel_in: endpoint {
+ remote-endpoint = <&lvds_receiver_out>;
+ };
+ };
+ };
+
reg_1p5v: 1p5v {
compatible = "regulator-fixed";
regulator-name = "1P5V";
@@ -129,12 +174,31 @@
VDDIO-supply = <®_3p3v>;
VDDD-supply = <®_1p5v>;
};
+
+ touch: touchpanel@38 {
+ compatible = "edt,edt-ft5406";
+ reg = <0x38>;
+ interrupt-parent = <&gpio0>;
+ interrupts = <24 IRQ_TYPE_EDGE_FALLING>;
+ };
};
&cmt0 {
status = "okay";
};
+&du {
+ status = "okay";
+};
+
+&gpio0 {
+ touch-interrupt {
+ gpio-hog;
+ gpios = <24 GPIO_ACTIVE_LOW>;
+ input;
+ };
+};
+
&hsusb {
pinctrl-0 = <&usb0_pins>;
pinctrl-names = "default";
@@ -165,6 +229,11 @@
function = "avb";
};
+ backlight_pins: backlight {
+ groups = "tpu0_to2";
+ function = "tpu0";
+ };
+
i2c2_pins: i2c2 {
groups = "i2c2_b";
function = "i2c2";
@@ -208,6 +277,17 @@
};
};
+&lvds0 {
+ status = "okay";
+ ports {
+ port@1 {
+ lvds0_out: endpoint {
+ remote-endpoint = <&lvds_receiver_in>;
+ };
+ };
+ };
+};
+
&rcar_sound {
pinctrl-0 = <&sound_pins>;
pinctrl-names = "default";
@@ -261,6 +341,10 @@
shared-pin;
};
+&tpu {
+ status = "okay";
+};
+
&usbphy {
status = "okay";
};
--
2.17.1
[PATCH 4/7] drm: rcar-du: lvds: Add r8a7742 support
The LVDS encoders on RZ/G1H SoC is identical to the R-Car Gen2 family. Add
support for RZ/G1H (R8A7742) SoC to the LVDS encoder driver.
Signed-off-by: Lad Prabhakar
Reviewed-by: Marian-Cristian Rotariu
---
drivers/gpu/drm/rcar-du/rcar_lvds.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/rcar-du/rcar_lvds.c
b/drivers/gpu/drm/rcar-du/rcar_lvds.c
index ab0d49618cf9..34b833cc05be 100644
--- a/drivers/gpu/drm/rcar-du/rcar_lvds.c
+++ b/drivers/gpu/drm/rcar-du/rcar_lvds.c
@@ -982,6 +982,7 @@ static const struct rcar_lvds_device_info
rcar_lvds_r8a77995_info = {
};
static const struct of_device_id rcar_lvds_of_table[] = {
+ { .compatible = "renesas,r8a7742-lvds", .data = &rcar_lvds_gen2_info },
{ .compatible = "renesas,r8a7743-lvds", .data = &rcar_lvds_gen2_info },
{ .compatible = "renesas,r8a7744-lvds", .data = &rcar_lvds_gen2_info },
{ .compatible = "renesas,r8a774a1-lvds", .data = &rcar_lvds_gen3_info },
--
2.17.1
[PATCH 0/7] r8a7742: Enable DU and LVDS
Hi All, This patch series adds support for DU and LVDS to r8a7742 SoC and enables LCD support on r8a7742-iwg21d-q7 board. This patch series applies on top of [1]. [1] https://git.kernel.org/pub/scm/linux/kernel/git/geert/ renesas-devel.git/log/?h=renesas-arm-dt-for-v5.10 Cheers, Prabhakar Lad Prabhakar (7): dt-bindings: display: renesas,du: Document the r8a7742 bindings drm: rcar-du: Add r8a7742 support dt-bindings: display: renesas,lvds: Document r8a7742 bindings drm: rcar-du: lvds: Add r8a7742 support ARM: dts: r8a7742: Add DU support ARM: dts: r8a7742: Add LVDS support ARM: dts: r8a7742-iwg21d-q7: Add LCD support .../bindings/display/bridge/renesas,lvds.txt | 1 + .../bindings/display/renesas,du.txt | 2 + arch/arm/boot/dts/r8a7742-iwg21d-q7.dts | 84 + arch/arm/boot/dts/r8a7742.dtsi| 89 +++ drivers/gpu/drm/rcar-du/rcar_du_drv.c | 5 +- drivers/gpu/drm/rcar-du/rcar_lvds.c | 1 + 6 files changed, 180 insertions(+), 2 deletions(-) -- 2.17.1
[PATCH 1/7] dt-bindings: display: renesas,du: Document the r8a7742 bindings
Document the RZ/G1H (R8A7742) SoC in the R-Car DU bindings. Signed-off-by: Lad Prabhakar Reviewed-by: Marian-Cristian Rotariu --- Documentation/devicetree/bindings/display/renesas,du.txt | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/devicetree/bindings/display/renesas,du.txt b/Documentation/devicetree/bindings/display/renesas,du.txt index 51cd4d162770..3f1e3ca4bea9 100644 --- a/Documentation/devicetree/bindings/display/renesas,du.txt +++ b/Documentation/devicetree/bindings/display/renesas,du.txt @@ -3,6 +3,7 @@ Required Properties: - compatible: must be one of the following. +- "renesas,du-r8a7742" for R8A7742 (RZ/G1H) compatible DU - "renesas,du-r8a7743" for R8A7743 (RZ/G1M) compatible DU - "renesas,du-r8a7744" for R8A7744 (RZ/G1N) compatible DU - "renesas,du-r8a7745" for R8A7745 (RZ/G1E) compatible DU @@ -68,6 +69,7 @@ corresponding to each DU output. Port0 Port1 Port2 Port3 - + R8A7742 (RZ/G1H) DPAD 0 LVDS 0 LVDS 1 - R8A7743 (RZ/G1M) DPAD 0 LVDS 0 - - R8A7744 (RZ/G1N) DPAD 0 LVDS 0 - - R8A7745 (RZ/G1E) DPAD 0 DPAD 1 - - -- 2.17.1
Re: [PATCH 1/2] membarrier: add MEMBARRIER_CMD_PRIVATE_RESTART_RSEQ_ON_CPU
On Thu, Aug 6, 2020 at 10:37 AM Mathieu Desnoyers wrote: > > >> > >> This is an unpriv IPI the world. That's a big no-no. > > > > removed in v2. > > I don't think the feature must be removed, but its implementation needs > adjustment. > > How about we simply piggy-back on the membarrier schemes we already have, and > implement: > > membarrier_register_private_expedited(MEMBARRIER_FLAG_RSEQ) > membarrier_private_expedited(MEMBARRIER_FLAG_RSEQ) > > All the logic is there to prevent sending IPIs to runqueues which are not > running > threads associated with the same mm. Considering that preemption does an rseq > abort, > running a thread belonging to a different mm should mean that this CPU is not > currently executing an rseq critical section, or if it was, it has already > been > aborted, so it is quiescent. > > Then you'll probably want to change membarrier_private_expedited so it takes > an > extra "cpu" argument. If cpu=-1, iterate on all runqueues like we currently > do. > If cpu >= 0, only IPI that CPU if the thread currently running has the same > mm. > Thanks, Mathieu! I'll prepare something based on your and Peter's feedback. > Also, should this belong to the membarrier or the rseq system call ? It just > looks like the membarrier happens to implement very similar things for > barriers, > but arguably this is really about rseq. I wonder if we should expose this > through > rseq instead, even if we end up using membarrier code. Yes, this is more about rseq; on the other hand, the high-level API/behavior looks closer to that membarrier, and a lot of code will be shared. As you are the maintainer for both rseq and membarrier, this is for you to decide, I guess... :)
drivers/gpu/drm/nouveau/nouveau_bo5039.c:39 nv50_bo_move_m2mf() warn: should 'new_reg->num_pages << 12' be a 64 bit
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: 86cfccb66937dd6cbf26ed619958b9e587e6a115
commit: 8b9d5d63a7193156b6b397c4f5078efbc200695f drm/nouveau/bo: split buffer
move functions into their own source files
date: 2 weeks ago
config: i386-randconfig-m021-20200807 (attached as .config)
compiler: gcc-9 (Debian 9.3.0-15) 9.3.0
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
smatch warnings:
drivers/gpu/drm/nouveau/nouveau_bo5039.c:39 nv50_bo_move_m2mf() warn: should
'new_reg->num_pages << 12' be a 64 bit type?
vim +39 drivers/gpu/drm/nouveau/nouveau_bo5039.c
33
34 int
35 nv50_bo_move_m2mf(struct nouveau_channel *chan, struct
ttm_buffer_object *bo,
36struct ttm_mem_reg *old_reg, struct ttm_mem_reg
*new_reg)
37 {
38 struct nouveau_mem *mem = nouveau_mem(old_reg);
> 39 u64 length = (new_reg->num_pages << PAGE_SHIFT);
40 u64 src_offset = mem->vma[0].addr;
41 u64 dst_offset = mem->vma[1].addr;
42 int src_tiled = !!mem->kind;
43 int dst_tiled = !!nouveau_mem(new_reg)->kind;
44 int ret;
45
46 while (length) {
47 u32 amount, stride, height;
48
49 ret = RING_SPACE(chan, 18 + 6 * (src_tiled +
dst_tiled));
50 if (ret)
51 return ret;
52
53 amount = min(length, (u64)(4 * 1024 * 1024));
54 stride = 16 * 4;
55 height = amount / stride;
56
57 if (src_tiled) {
58 BEGIN_NV04(chan, NvSubCopy, 0x0200, 7);
59 OUT_RING (chan, 0);
60 OUT_RING (chan, 0);
61 OUT_RING (chan, stride);
62 OUT_RING (chan, height);
63 OUT_RING (chan, 1);
64 OUT_RING (chan, 0);
65 OUT_RING (chan, 0);
66 } else {
67 BEGIN_NV04(chan, NvSubCopy, 0x0200, 1);
68 OUT_RING (chan, 1);
69 }
70 if (dst_tiled) {
71 BEGIN_NV04(chan, NvSubCopy, 0x021c, 7);
72 OUT_RING (chan, 0);
73 OUT_RING (chan, 0);
74 OUT_RING (chan, stride);
75 OUT_RING (chan, height);
76 OUT_RING (chan, 1);
77 OUT_RING (chan, 0);
78 OUT_RING (chan, 0);
79 } else {
80 BEGIN_NV04(chan, NvSubCopy, 0x021c, 1);
81 OUT_RING (chan, 1);
82 }
83
84 BEGIN_NV04(chan, NvSubCopy, 0x0238, 2);
85 OUT_RING (chan, upper_32_bits(src_offset));
86 OUT_RING (chan, upper_32_bits(dst_offset));
87 BEGIN_NV04(chan, NvSubCopy, 0x030c, 8);
88 OUT_RING (chan, lower_32_bits(src_offset));
89 OUT_RING (chan, lower_32_bits(dst_offset));
90 OUT_RING (chan, stride);
91 OUT_RING (chan, stride);
92 OUT_RING (chan, stride);
93 OUT_RING (chan, height);
94 OUT_RING (chan, 0x0101);
95 OUT_RING (chan, 0x);
96 BEGIN_NV04(chan, NvSubCopy,
NV_MEMORY_TO_MEMORY_FORMAT_NOP, 1);
97 OUT_RING (chan, 0);
98
99 length -= amount;
100 src_offset += amount;
101 dst_offset += amount;
102 }
103
104 return 0;
105 }
106
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
.config.gz
Description: application/gzip
Re: [git pull] regset work
The pull request you sent on Thu, 6 Aug 2020 15:10:44 +0100: > git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git work.regset has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/19b39c38abf68591edbd698740d410c37ee075cc Thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/prtracker.html
Re: [GIT PULL] RISC-V Patches for the 5.9 Merge Window, Part 1
The pull request you sent on Thu, 06 Aug 2020 16:17:49 -0700 (PDT): > git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux.git > tags/riscv-for-linus-5.9-mw0 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/dbf83817315d9ce93b3e5b1c83a167f537245bd8 Thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/prtracker.html
Re: [git pull] Christoph's init series
The pull request you sent on Wed, 5 Aug 2020 05:21:44 +0100: > git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git hch.init_path has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/e1ec517e18acc0aa9795ff92c15f0adabcb12db9 Thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/prtracker.html
Re: [git pull] m68knommu changes for v5.9
The pull request you sent on Fri, 7 Aug 2020 14:56:52 +1000: > git://git.kernel.org/pub/scm/linux/kernel/git/gerg/m68knommu.git > tags/m68knommu-for-v5.9 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/60e76bb8a4e4c5398ea9053535e1fd0c9d6bb06e Thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/prtracker.html
Re: [Latest Git kernel/Linux-next kernel] Xorg doesn't start after the seccomp updates v5.9-rc1
On Fri, Aug 07, 2020 at 04:45:14PM +0200, Christian Zigotzky wrote: > But Xorg works on Ubuntu 10.04.4 (PowerPC 32-bit), openSUSE Tumbleweed > 20190722 PPC64 and on Fedora 27 PPC64 with the latest Git kernel. > > I bisected today [4]. > > Result: net/scm: Regularize compat handling of scm_detach_fds() > (c0029de50982c1fb215330a5f9d433cec0cfd8cc) [5] is the first bad commit. > > This commit has been merged with the seccomp updates v5.9-rc1 on 2020-08-04 > 14:11:08 -0700 [1]. Since these updates, Xorg doesn't start anymore on some > Linux distributions. Hi! Thanks for bisecting; yes, sorry for the trouble (I'm still trying to understand why my compat tests _passed_...). Regardless, can you try this patch: https://lore.kernel.org/lkml/20200807173609.GJ4402@mussarela/ -- Kees Cook
Very slow qemu device access
Everything starts going very slowly after this commit: commit 37f4a24c2469a10a4c16c641671bd766e276cf9f (refs/bisect/bad) Author: Ming Lei Date: Tue Jun 30 22:03:57 2020 +0800 blk-mq: centralise related handling into blk_mq_get_driver_tag Move .nr_active update and request assignment into blk_mq_get_driver_tag(), all are good to do during getting driver tag. Meantime blk-flush related code is simplified and flush request needn't to update the request table manually any more. Signed-off-by: Ming Lei Cc: Christoph Hellwig Signed-off-by: Jens Axboe By the time xfstests gets to generic/007, things are blocking trying to get tags: root@bobo-kvm:~# cat /proc/9530/stack [<0>] blk_mq_get_tag+0x109/0x250 [<0>] __blk_mq_alloc_request+0x67/0xf0 [<0>] blk_mq_submit_bio+0xee/0x560 [<0>] submit_bio_noacct+0x3a3/0x410 [<0>] submit_bio+0x33/0xf0 [<0>] submit_bh_wbc.isra.0+0x139/0x160 [<0>] block_read_full_page+0x357/0x4a0 [<0>] blkdev_readpage+0x13/0x20 [<0>] do_read_cache_page+0x557/0x860 ... maybe tags aren't getting freed properly? Or things aren't being woken up promptly? (that trace is from current linus head; i bisected back to this commit)
Re: [PATCH 13/13] MAINTAINERS: Update paths to Ingenic platform code
在 2020/8/8 上午1:22, Zhou Yanjie 写道: Hi Paul, 在 2020/8/4 上午1:01, Paul Cercueil 写道: Support for Ingenic chips has been moved to the generic MIPS platform. Update the paths accordingly. The modification to "cu1830-neo_defconfig" seems to be missed here. Sorry, this should be a reply to [12/13] :( Thanks and best regards! Signed-off-by: Paul Cercueil --- MAINTAINERS | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index bddc79ae76e6..1d89029cb89a 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -8508,8 +8508,8 @@ INGENIC JZ47xx SoCs M: Paul Cercueil S: Maintained F: arch/mips/boot/dts/ingenic/ -F: arch/mips/include/asm/mach-jz4740/ -F: arch/mips/jz4740/ +F: arch/mips/generic/board-ingenic.c +F: arch/mips/ingenic/Kconfig F: drivers/clk/ingenic/ F: drivers/dma/dma-jz4780.c F: drivers/gpu/drm/ingenic/
Re: [PATCH v2 09/41] usb: gadget: s3c-hsudc: remove platform header dependency
On Fri, Aug 7, 2020 at 3:59 PM Felipe Balbi wrote: > Krzysztof Kozlowski writes: > > +#include > > + > > #define S3C2443_CLKREG(x)((x) + S3C24XX_VA_CLKPWR) > > > > #define S3C2443_PLLCON_MDIVSHIFT 16 > > @@ -184,5 +186,52 @@ s3c2443_get_epll(unsigned int pllval, unsigned int > > baseclk) > > return (unsigned int)fvco; > > } > > > > +static inline void s3c_hsudc_init_phy(void) > > This should, really, be a PHY driver under drivers/phy, since the goal > is to make this platform-independent, might as well take the opportunity > to introduce a proper driver, no? In theory, this is absolutely correct. I fear it will be hard to find anyone to make a larger scale cleanup of the file however. As my old changelog text says, there is only one board (smdk2416) in the kernel that registers the device. My change was the minimum to keep it working during the move to a multiplatform configuration, but if there is someone who has the hardware and volunteers to make a proper phy driver, that would also work. As the board only exists as a reference for other boards, but none of those made it into the kernel, we could alternatively just decide to drop the driver. There is also a .dts file for the board, which is lacking a device node for the udc (and the driver lacks DT support), so that board file could also be dropped then, leaving only the DT version as a reference for the SoC. Arnd
Re: wine fails to start with seccomp updates for v5.9-rc1
On Fri, Aug 07, 2020 at 02:36:09PM -0300, Thadeu Lima de Souza Cascardo wrote:
> On Fri, Aug 07, 2020 at 08:48:46AM -0700, Linus Torvalds wrote:
> > On Fri, Aug 7, 2020 at 8:19 AM Alex Xu (Hello71) wrote:
> > >
> > > On Linus' master, wine fails to start with the following error:
> > >
> > > wine client error:0: write: Bad file descriptor
> > >
> > > This issue is not present on 5.8. It appears to be caused by failure to
> > > write to a pipe FD received via SCM_RIGHTS. Therefore, I tried reverting
> > > 9ecc6ea491f0, which resolved the issue.
> >
> > Would you mind trying to bisect exactly where it happens?
> >
>
> This report [1] seemed related and pointed out at c0029de50982 ("net/scm:
> Regularize compat handling of scm_detach_fds()"). The use of CMSG_USER_DATA
> instead of CMSG_COMPAT_DATA seems fishy.
Argh; yes. Thank you for finding that! That's what I get for trying to
regularize the compat path. :(
> Alex, can you try applying the patch below?
>
> Cascardo.
>
> [1] https://lists.ozlabs.org/pipermail/linuxppc-dev/2020-August/216156.html
>
> > I don't think any of the commits in that pull are supposed to change
> > semantics, and while reverting the whole merge shows that yes, that's
> > what brought in the problems, it would be good to pinpoint just which
> > change breaks so that we can fix just that thing.
> >
> > Kees, ideas?
> >
> > Linus
>
> ---
> diff --git a/net/compat.c b/net/compat.c
> index 703acb51c698..95ce707a30a3 100644
> --- a/net/compat.c
> +++ b/net/compat.c
> @@ -294,7 +294,7 @@ void scm_detach_fds_compat(struct msghdr *msg, struct
> scm_cookie *scm)
> (struct compat_cmsghdr __user *)msg->msg_control;
> unsigned int o_flags = (msg->msg_flags & MSG_CMSG_CLOEXEC) ? O_CLOEXEC
> : 0;
> int fdmax = min_t(int, scm_max_fds_compat(msg), scm->fp->count);
> - int __user *cmsg_data = CMSG_USER_DATA(cm);
> + int __user *cmsg_data = CMSG_COMPAT_DATA(cm);
> int err = 0, i;
>
> for (i = 0; i < fdmax; i++) {
That almost certainly will fix the problem.
--
Kees Cook
Re: [PATCH v2] hwmon/pmbus: use simple i2c probe function
On Fri, 7 Aug 2020 08:23:29 -0700, Guenter Roeck wrote:
> On 8/7/20 12:45 AM, Stephen Kitt wrote:
> > pmbus_do_probe doesn't use the id information provided in its second
> > argument, so this can be removed, which then allows using the
> > single-parameter i2c probe function ("probe_new") for probes.
> >
> > This avoids scanning the identifier tables during probes.
> >
> > Drivers which didn't use the id are converted as-is; drivers which did
> > are modified as follows:
> >
> > * if the information in i2c_client is sufficient, that's used instead
> > (client->name);
> > * configured v. probed comparisons are performed by comparing the
> > configured name to the detected name, instead of the ids; this
> > involves strcmp but is still cheaper than comparing all the device
> > names when scanning the tables;
> > * anything else is handled by calling i2c_match_id() with the same
> > level of error-handling (if any) as before.
> >
> > Signed-off-by: Stephen Kitt
>
> Please also update the documentation.
>
> Documentation/hwmon/pmbus-core.rst: int pmbus_do_probe(struct i2c_client
> *client, const struct i2c_device_id *id, Documentation/hwmon/pmbus.rst:
> return pmbus_do_probe(client, id, &ds1200_info);
Aargh, I usually *start* from the documentation, but I didn’t think to check
in this case.
> Also, please fix the checkpatch issue reported by Wolfram.
Will do, v3 on its way.
Thanks for the reviews!
Regards,
Stephen
pgpDssvachgtn.pgp
Description: OpenPGP digital signature
drivers/firmware/tegra/bpmp-debugfs.c:335:11-18: WARNING opportunity for memdup_user
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: 86cfccb66937dd6cbf26ed619958b9e587e6a115
commit: 5e37b9c137ee5a3a9dc2815ca51f71746c2609a6 firmware: tegra: Add support
for in-band debug
date: 3 weeks ago
config: arm64-randconfig-c003-20200807 (attached as .config)
compiler: aarch64-linux-gcc (GCC) 9.3.0
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
coccinelle warnings: (new ones prefixed by >>)
>> drivers/firmware/tegra/bpmp-debugfs.c:335:11-18: WARNING opportunity for
>> memdup_user
vim +335 drivers/firmware/tegra/bpmp-debugfs.c
320
321 static ssize_t bpmp_debug_store(struct file *file, const char __user
*buf,
322 size_t count, loff_t *f_pos)
323 {
324 struct inode *inode = file_inode(file);
325 struct tegra_bpmp *bpmp = inode->i_private;
326 char *databuf = NULL;
327 char fnamebuf[256];
328 const char *filename;
329 ssize_t err;
330
331 filename = get_filename(bpmp, file, fnamebuf, sizeof(fnamebuf));
332 if (!filename)
333 return -ENOENT;
334
> 335 databuf = kmalloc(count, GFP_KERNEL);
336 if (!databuf)
337 return -ENOMEM;
338
339 if (copy_from_user(databuf, buf, count)) {
340 err = -EFAULT;
341 goto free_ret;
342 }
343
344 err = mrq_debug_write(bpmp, filename, databuf, count);
345
346 free_ret:
347 kfree(databuf);
348
349 return err ?: count;
350 }
351
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
.config.gz
Description: application/gzip
Re: [PATCH] i2c: iproc: fix race between client unreg and isr
Ray Jui wrote: > > Any progress yet? > > I don't know if Dhananjay is actively working on this or not. > > Rayagonda, given that you have the I2C slave setup already, do you think > you can help to to test and above sequence from Wolfram (by using the > widened delay window as instructed)? > > Thanks, > > Ray Sorry I was out for a while, I've tested the fix with delay and original i2c client test, will send v2 patch shortly. Thanks, Dhananjay
Re: wine fails to start with seccomp updates for v5.9-rc1
On Fri, Aug 07, 2020 at 08:48:46AM -0700, Linus Torvalds wrote:
> On Fri, Aug 7, 2020 at 8:19 AM Alex Xu (Hello71) wrote:
> >
> > On Linus' master, wine fails to start with the following error:
> >
> > wine client error:0: write: Bad file descriptor
> >
> > This issue is not present on 5.8. It appears to be caused by failure to
> > write to a pipe FD received via SCM_RIGHTS. Therefore, I tried reverting
> > 9ecc6ea491f0, which resolved the issue.
>
> Would you mind trying to bisect exactly where it happens?
>
This report [1] seemed related and pointed out at c0029de50982 ("net/scm:
Regularize compat handling of scm_detach_fds()"). The use of CMSG_USER_DATA
instead of CMSG_COMPAT_DATA seems fishy.
Alex, can you try applying the patch below?
Cascardo.
[1] https://lists.ozlabs.org/pipermail/linuxppc-dev/2020-August/216156.html
> I don't think any of the commits in that pull are supposed to change
> semantics, and while reverting the whole merge shows that yes, that's
> what brought in the problems, it would be good to pinpoint just which
> change breaks so that we can fix just that thing.
>
> Kees, ideas?
>
> Linus
---
diff --git a/net/compat.c b/net/compat.c
index 703acb51c698..95ce707a30a3 100644
--- a/net/compat.c
+++ b/net/compat.c
@@ -294,7 +294,7 @@ void scm_detach_fds_compat(struct msghdr *msg, struct
scm_cookie *scm)
(struct compat_cmsghdr __user *)msg->msg_control;
unsigned int o_flags = (msg->msg_flags & MSG_CMSG_CLOEXEC) ? O_CLOEXEC
: 0;
int fdmax = min_t(int, scm_max_fds_compat(msg), scm->fp->count);
- int __user *cmsg_data = CMSG_USER_DATA(cm);
+ int __user *cmsg_data = CMSG_COMPAT_DATA(cm);
int err = 0, i;
for (i = 0; i < fdmax; i++) {
Re: [PATCH v2] arm64: kaslr: Use standard early random function
On Fri, Aug 07, 2020 at 07:45:21AM -0700, Guenter Roeck wrote:
> Commit 585524081ecd ("random: random.h should include archrandom.h, not
> the other way around") tries to fix a problem with recursive inclusion
> of linux/random.h and arch/archrandom.h for arm64. Unfortunately, this
> results in the following compile error if ARCH_RANDOM is disabled.
>
> arch/arm64/kernel/kaslr.c: In function 'kaslr_early_init':
> arch/arm64/kernel/kaslr.c:128:6: error: implicit declaration of function
> '__early_cpu_has_rndr'; did you mean '__early_pfn_to_nid'?
> [-Werror=implicit-function-declaration]
> if (__early_cpu_has_rndr()) {
> ^~~~
> __early_pfn_to_nid
> arch/arm64/kernel/kaslr.c:131:7: error: implicit declaration of function
> '__arm64_rndr' [-Werror=implicit-function-declaration]
>if (__arm64_rndr(&raw))
>^~~~
>
> Problem is that arch/archrandom.h is only included from linux/random.h if
> ARCH_RANDOM is enabled. If not, __arm64_rndr() and __early_cpu_has_rndr()
> are undeclared, causing the problem.
>
> Use arch_get_random_seed_long_early() instead of arm64 specific functions
> to solve the problem.
>
> Reported-by: Qian Cai
> Fixes: 585524081ecd ("random: random.h should include archrandom.h, not the
> other way around")
> Cc: Qian Cai
> Cc: Mark Brown
> Reviewed-by: Mark Rutland
> Reviewed-by: Mark Brown
> Tested-by: Mark Brown
> Signed-off-by: Guenter Roeck
Acked-by: Catalin Marinas
Linus, could you please pick this up directly? Otherwise, it will wait
until we reach -rc1 to avoid basing a branch on a random commit.
(at the moment I can't build Linus' tree at all, fails early with some
device tree errors)
Thanks.
--
Catalin
Re: [PATCH v3] hwmon/pmbus: use simple i2c probe function
On Fri, Aug 07, 2020 at 06:28:01PM +0200, Stephen Kitt wrote:
> pmbus_do_probe doesn't use the id information provided in its second
> argument, so this can be removed, which then allows using the
> single-parameter i2c probe function ("probe_new") for probes.
>
> This avoids scanning the identifier tables during probes.
>
> Drivers which didn't use the id are converted as-is; drivers which did
> are modified as follows:
>
> * if the information in i2c_client is sufficient, that's used instead
> (client->name);
> * configured v. probed comparisons are performed by comparing the
> configured name to the detected name, instead of the ids; this
> involves strcmp but is still cheaper than comparing all the device
> names when scanning the tables;
> * anything else is handled by calling i2c_match_id() with the same
> level of error-handling (if any) as before.
>
> Signed-off-by: Stephen Kitt
> ---
> Changes since v1:
> - i2c_device_id declarations are left unchanged;
> - all drivers are converted, using client info or i2c_match_id().
> Changes since v2:
> - updated the documentation;
> - fixed unbalanced braces around the modified else in ibm-cffps.c.
>
[ ... ]
>
> -static int ltc2978_probe(struct i2c_client *client,
> - const struct i2c_device_id *id)
> +static int ltc2978_probe(struct i2c_client *client)
> {
> int i, chip_id;
> struct ltc2978_data *data;
> @@ -670,10 +669,10 @@ static int ltc2978_probe(struct i2c_client *client,
> return chip_id;
>
> data->id = chip_id;
> - if (data->id != id->driver_data)
> + if (strcmp(client->name, ltc2978_id[data->id].name) != 0)
I was about to apply this patch, but this is problematic: It assumes that
__stringify(id) == ltc2978_id[id].name and that ltc2978_id[id].driver_data
== id. While that is curently the case (as far as I can see), it is still
unsafe. I think it would be much safer to use i2c_match_id() here.
Thanks,
Guenter
Re: [dm-devel] [RFC PATCH v5 00/11] Integrity Policy Enforcement LSM (IPE)
On Sat, 2020-08-08 at 02:41 +1000, James Morris wrote: > On Thu, 6 Aug 2020, Mimi Zohar wrote: > > > On Thu, 2020-08-06 at 09:51 +1000, James Morris wrote: > > > On Wed, 5 Aug 2020, Mimi Zohar wrote: > > > > > > > If block layer integrity was enough, there wouldn't have been a need > > > > for fs-verity. Even fs-verity is limited to read only filesystems, > > > > which makes validating file integrity so much easier. From the > > > > beginning, we've said that fs-verity signatures should be included in > > > > the measurement list. (I thought someone signed on to add that support > > > > to IMA, but have not yet seen anything.) > > > > > > > > Going forward I see a lot of what we've accomplished being incorporated > > > > into the filesystems. When IMA will be limited to defining a system > > > > wide policy, I'll have completed my job. > > > > > > What are your thoughts on IPE being a standalone LSM? Would you prefer to > > > see its functionality integrated into IMA? > > > > Improving the integrity subsystem would be preferred. > > > > Are you planning to attend Plumbers? Perhaps we could propose a BoF > session on this topic. That sounds like a good idea. Mimi
Re: [PATCH 1/2] mm/slub: Introduce two counters for the partial objects
Hi Christopher, On Fri, 7 Aug 2020, Pekka Enberg wrote: > > I think we can just default to the counters. After all, if I > > understood correctly, we're talking about up to 100 ms time period > > with IRQs disabled when count_partial() is called. As this is > > triggerable from user space, that's a performance bug whatever way you > > look at it. On Fri, Aug 7, 2020 at 4:02 PM Christopher Lameter wrote: > Well yes under extreme conditions and this is only happening for sysfs > counter retrieval. You will likely get some stall even in less extreme conditions, and in any case, the kernel should not allow user space to trigger such a stall. On Fri, Aug 7, 2020 at 4:02 PM Christopher Lameter wrote: > There could be other solutions to this. This solution here is penalizing > evertu hotpath slab allocation for the sake of relatively infrequently > used counter monitoring. There the possibility of not traversing the list > ande simply estimating the value based on the number of slab pages > allocated on that node. Why do you consider this to be a fast path? This is all partial list accounting when we allocate/deallocate a slab, no? Just like ___slab_alloc() says, I assumed this to be the slow path... What am I missing? No objections to alternative fixes, of course, but wrapping the counters under CONFIG_DEBUG seems like just hiding the actual issue... - Pekka
Re: [PATCH 13/13] MAINTAINERS: Update paths to Ingenic platform code
Hi Paul, 在 2020/8/4 上午1:01, Paul Cercueil 写道: Support for Ingenic chips has been moved to the generic MIPS platform. Update the paths accordingly. The modification to "cu1830-neo_defconfig" seems to be missed here. Thanks and best regards! Signed-off-by: Paul Cercueil --- MAINTAINERS | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index bddc79ae76e6..1d89029cb89a 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -8508,8 +8508,8 @@ INGENIC JZ47xx SoCs M:Paul Cercueil S:Maintained F:arch/mips/boot/dts/ingenic/ -F: arch/mips/include/asm/mach-jz4740/ -F: arch/mips/jz4740/ +F: arch/mips/generic/board-ingenic.c +F: arch/mips/ingenic/Kconfig F:drivers/clk/ingenic/ F:drivers/dma/dma-jz4780.c F:drivers/gpu/drm/ingenic/
Re: Odd-sized kmem_cache_alloc and slub_debug=Z
On Fri, Aug 07, 2020 at 10:16AM -0700, Kees Cook wrote:
> On Fri, Aug 07, 2020 at 06:06:27PM +0200, Marco Elver wrote:
> > I found that the below debug-code using kmem_cache_alloc(), when using
> > slub_debug=Z, results in the following crash:
> >
> > general protection fault, probably for non-canonical address
> > 0xcca41caea170: [#1] PREEMPT SMP PTI
> > CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.8.0+ #1
> > Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1
> > 04/01/2014
> > RIP: 0010:freelist_dereference mm/slub.c:272 [inline]
> > RIP: 0010:get_freepointer mm/slub.c:278 [inline]
>
> That really looks like more fun from my moving the freelist pointer...
>
> > R13: cca41caea160 R14: e7c6a072ba80 R15: a3a41c96d540
>
> Except that it's all at the start, which doesn't look like "data"
> nor the hardened freelist obfuscation.
>
> > FS: () GS:a3a41fc0()
> > knlGS:
> > CS: 0010 DS: ES: CR0: 80050033
> > CR2: a3a051c01000 CR3: 00045140a001 CR4: 00770ef0
> > DR0: DR1: DR2:
> > DR3: DR6: fffe0ff0 DR7: 0400
> > PKRU:
> > Call Trace:
> > ___slab_alloc+0x336/0x340 mm/slub.c:2690
> > __slab_alloc mm/slub.c:2714 [inline]
> > slab_alloc_node mm/slub.c:2788 [inline]
> > slab_alloc mm/slub.c:2832 [inline]
> > kmem_cache_alloc+0x135/0x200 mm/slub.c:2837
> > start_kernel+0x3d6/0x44e init/main.c:1049
> > secondary_startup_64+0xb6/0xc0 arch/x86/kernel/head_64.S:243
> >
> > Any ideas what might be wrong?
> >
> > This does not crash when redzones are not enabled.
> >
> > Thanks,
> > -- Marco
> >
> > -- >8 --
> >
> > diff --git a/init/main.c b/init/main.c
> > index 15bd0efff3df..f4aa5bb3f2ec 100644
> > --- a/init/main.c
> > +++ b/init/main.c
> > @@ -1041,6 +1041,16 @@ asmlinkage __visible void __init start_kernel(void)
> > sfi_init_late();
> > kcsan_init();
> >
> > + /* DEBUG CODE */
> > + {
> > + struct kmem_cache *c = kmem_cache_create("test", 21, 1, 0,
> > NULL);
> > + char *buf;
> > + BUG_ON(!c);
> > + buf = kmem_cache_alloc(c, GFP_KERNEL);
> > + kmem_cache_free(c, buf);
> > + kmem_cache_destroy(c);
> > + }
> > +
> > /* Do the rest non-__init'ed, we're now alive */
> > arch_call_rest_init();
> >
>
> Which kernel version? Can you send your CONFIG too?
Sorry, didn't see this before I replied to the other -- it's here:
https://lkml.kernel.org/r/20200807171849.ga1467...@elver.google.com
Thanks,
-- Marco
Re: [PATCH v4 00/10] Function Granular KASLR
On Fri, Aug 07, 2020 at 09:38:11AM -0700, Kristen Carlson Accardi wrote: > Thanks for testing. Yes, Josh and I have been discussing the orc_unwind > issues. I've root caused one issue already, in that objtool places an > orc_unwind_ip address just outside the section, so my algorithm fails > to relocate this address. There are other issues as well that I still > haven't root caused. I'll be addressing this in v5 and plan to have > something that passes livepatch testing with that version. FWIW, I'm okay with seeing fgkaslr be developed progressively. Getting it working with !livepatching would be fine as a first step. There's value in getting the general behavior landed, and then continuing to improve it. -- Kees Cook
[PATCH bpf-next] bpf: fix segmentation fault of test_progs
test_progs reports the segmentation fault as below
$ sudo ./test_progs -t mmap --verbose
test_mmap:PASS:skel_open_and_load 0 nsec
..
test_mmap:PASS:adv_mmap1 0 nsec
test_mmap:PASS:adv_mmap2 0 nsec
test_mmap:PASS:adv_mmap3 0 nsec
test_mmap:PASS:adv_mmap4 0 nsec
Segmentation fault
This issue was triggered because mmap() and munmap() used inconsistent
length parameters; mmap() creates a new mapping of 3*page_size, but the
length parameter set in the subsequent re-map and munmap() functions is
4*page_size; this leads to the destruction of the process space.
Another issue is that when unmap the second page fails, the length
parameter to delete tmp1 mappings should be 3*page_size.
Signed-off-by: Jianlin Lv
---
tools/testing/selftests/bpf/prog_tests/mmap.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/tools/testing/selftests/bpf/prog_tests/mmap.c
b/tools/testing/selftests/bpf/prog_tests/mmap.c
index 43d0b5578f46..2070cfe19cac 100644
--- a/tools/testing/selftests/bpf/prog_tests/mmap.c
+++ b/tools/testing/selftests/bpf/prog_tests/mmap.c
@@ -192,7 +192,7 @@ void test_mmap(void)
/* unmap second page: pages 1, 3 mapped */
err = munmap(tmp1 + page_size, page_size);
if (CHECK(err, "adv_mmap2", "errno %d\n", errno)) {
- munmap(tmp1, map_sz);
+ munmap(tmp1, 3 * page_size);
goto cleanup;
}
@@ -207,8 +207,8 @@ void test_mmap(void)
CHECK(tmp1 + page_size != tmp2, "adv_mmap4",
"tmp1: %p, tmp2: %p\n", tmp1, tmp2);
- /* re-map all 4 pages */
- tmp2 = mmap(tmp1, 4 * page_size, PROT_READ, MAP_SHARED | MAP_FIXED,
+ /* re-map all 3 pages */
+ tmp2 = mmap(tmp1, 3 * page_size, PROT_READ, MAP_SHARED | MAP_FIXED,
data_map_fd, 0);
if (CHECK(tmp2 == MAP_FAILED, "adv_mmap5", "errno %d\n", errno)) {
munmap(tmp1, 3 * page_size); /* unmap page 1 */
@@ -226,7 +226,7 @@ void test_mmap(void)
CHECK_FAIL(map_data->val[2] != 321);
CHECK_FAIL(map_data->val[far] != 3 * 321);
- munmap(tmp2, 4 * page_size);
+ munmap(tmp2, 3 * page_size);
/* map all 4 pages, but with pg_off=1 page, should fail */
tmp1 = mmap(NULL, 4 * page_size, PROT_READ, MAP_SHARED | MAP_FIXED,
--
2.17.1
Re: [PATCH 00/13] MIPS: Convert Ingenic to a generic board
Hi Paul,
在 2020/8/8 上午12:45, Paul Cercueil 写道:
Hi Zhou,
Le sam. 8 août 2020 à 0:23, Zhou Yanjie a
écrit :
Hi Paul,
I'm not too sure if remove "cpu-feature-overrides.h" will cause some
problems for X2000, because according to my current test on X2000, I
found that it is somewhat different from the SoCs using XBurst1 CPU
core, with the kernel source code provided by Ingenic, for example,
we must configure "#define cpu_has_tlbinv 1" in
"cpu-feature-overrides.h" to make the X2000 work normally, otherwise
the kernel will get stuck. And X2000's interrupt controller has also
been redesigned. If these differences make it impossible to share
code, should we set a subdirectory of "xburst" and "xburst2" in
"arch/mips/ingenic"? (I am just worried about this situation, so far
I have not been able to successfully run the mainline kernel on X2000).
The is kind of a hack, to hardcode settings
in case the CPU is not properly detected. The cpu-probe.c should be
able to auto-detect these settings, including the inverted TLB that
the X2000 has, reading from the CPU config registers ("TLB INV" info
should be in config4). Right now cpu_probe_ingenic() doesn't read
config4 (not present on older SoCs) but that's trivial to add.
As for your other question, I don't see any reason why we wouldn't be
able to support the X2000 aside the others in a generic kernel, so
don't worry :)
OK, this is good news for me.
Cheers,
-Paul
I have added some related engineers from Ingenic to CC
Thanks and best regards!
在 2020/8/4 上午1:01, Paul Cercueil 写道:
Hi Thomas & list,
Here is a set of patches for 5.10 (no rush) to move Ingenic support
from
arch/mips/jz4740/ to arch/mips/generic/.
There are some Kconfig changes that I think should be reviewed in
detail
to avoid breakages elsewhere. The idea behind these changes is to allow
the Ingenic "generic" code to be built in a non-generic kernel, since
generic kernels bring lots of dependencies which result in a +7% size
increase.
Support for booting the generic kernel with a built-in and/or appended
devicetree, as well as support for compressed (vmlinuz) kernels, has
been added as well.
Cheers,
-Paul
Paul Cercueil (13):
MIPS: cpu-probe: Set Ingenic's writecombine to _CACHE_CACHABLE_WA
MIPS: cpu-probe: Mark XBurst CPU as having vtagged caches
MIPS: cpu-probe: ingenic: Fix broken BUG_ON
MIPS: Kconfig: add MIPS_GENERIC_KERNEL symbol
MIPS: machine: Add get_system_type callback
MIPS: generic: Call the machine's .get_system_type callback if
provided
MIPS: generic: Support booting with built-in or appended DTB
MIPS: generic: Add support for zboot
MIPS: generic: Increase NR_IRQS to 256
MIPS: generic: Add support for Ingenic SoCs
MIPS: jz4740: Drop folder
MIPS: configs: Regenerate configs of Ingenic boards
MAINTAINERS: Update paths to Ingenic platform code
MAINTAINERS | 4 +-
arch/mips/Kbuild.platforms | 1 -
arch/mips/Kconfig | 43 --
arch/mips/configs/ci20_defconfig | 4 +-
arch/mips/configs/cu1000-neo_defconfig | 16 +-
arch/mips/configs/gcw0_defconfig | 2 +-
arch/mips/configs/qi_lb60_defconfig | 5 +-
arch/mips/configs/rs90_defconfig | 4 +-
arch/mips/generic/Kconfig | 8 +-
arch/mips/generic/Makefile | 2 +-
arch/mips/generic/Platform | 1 +
arch/mips/generic/board-ingenic.c | 108 +
arch/mips/generic/init.c | 28 +++-
arch/mips/generic/proc.c | 25 ---
arch/mips/include/asm/mach-generic/irq.h | 2 +-
.../asm/mach-jz4740/cpu-feature-overrides.h | 50 --
arch/mips/include/asm/mach-jz4740/irq.h | 13 --
arch/mips/include/asm/machine.h | 1 +
arch/mips/include/asm/pgtable-bits.h | 5 -
arch/mips/{jz4740 => ingenic}/Kconfig | 16 +-
arch/mips/jz4740/Makefile | 9 --
arch/mips/jz4740/Platform | 3 -
arch/mips/jz4740/setup.c | 145
--
arch/mips/kernel/cpu-probe.c | 8 +-
24 files changed, 198 insertions(+), 305 deletions(-)
create mode 100644 arch/mips/generic/board-ingenic.c
delete mode 100644 arch/mips/generic/proc.c
delete mode 100644
arch/mips/include/asm/mach-jz4740/cpu-feature-overrides.h
delete mode 100644 arch/mips/include/asm/mach-jz4740/irq.h
rename arch/mips/{jz4740 => ingenic}/Kconfig (91%)
delete mode 100644 arch/mips/jz4740/Makefile
delete mode 100644 arch/mips/jz4740/Platform
delete mode 100644 arch/mips/jz4740/setup.c
Re: Odd-sized kmem_cache_alloc and slub_debug=Z
On Fri, Aug 07, 2020 at 08:06PM +0300, Pekka Enberg wrote:
> Hi Marco,
>
> On Fri, Aug 7, 2020 at 7:07 PM Marco Elver wrote:
> > I found that the below debug-code using kmem_cache_alloc(), when using
> > slub_debug=Z, results in the following crash:
> >
> > general protection fault, probably for non-canonical address
> > 0xcca41caea170: [#1] PREEMPT SMP PTI
> > CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.8.0+ #1
> > Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
> > 1.13.0-1 04/01/2014
> > RIP: 0010:freelist_dereference mm/slub.c:272 [inline]
> > RIP: 0010:get_freepointer mm/slub.c:278 [inline]
> > RIP: 0010:deactivate_slab+0x54/0x460 mm/slub.c:2111
> > Code: 8b bc c7 e0 00 00 00 48 85 d2 0f 84 00 01 00 00 49 89 d5 31
> > c0 48 89 44 24 08 66 66 2e 0f 1f 84 00 00 00 00 00 90 44 8b 43 20 <4b> 8b
> > 44 05 00 48 85 c0 0f 84 1e 01 00 00 4c 89 ed 49 89 c5 8b 43
> > RSP: :a7e03e18 EFLAGS: 00010046
> > RAX: RBX: a3a41c972340 RCX:
> > RDX: cca41caea160 RSI: e7c6a072ba80 RDI: a3a41c972340
> > RBP: a3a41caea008 R08: 0010 R09: a3a41caea01d
> > R10: a7f8dc50 R11: a68f44c0 R12: a3a41c972340
> > R13: cca41caea160 R14: e7c6a072ba80 R15: a3a41c96d540
> > FS: () GS:a3a41fc0()
> > knlGS:
> > CS: 0010 DS: ES: CR0: 80050033
> > CR2: a3a051c01000 CR3: 00045140a001 CR4: 00770ef0
> > DR0: DR1: DR2:
> > DR3: DR6: fffe0ff0 DR7: 0400
> > PKRU:
> > Call Trace:
> > ___slab_alloc+0x336/0x340 mm/slub.c:2690
> > __slab_alloc mm/slub.c:2714 [inline]
> > slab_alloc_node mm/slub.c:2788 [inline]
> > slab_alloc mm/slub.c:2832 [inline]
> > kmem_cache_alloc+0x135/0x200 mm/slub.c:2837
> > start_kernel+0x3d6/0x44e init/main.c:1049
> > secondary_startup_64+0xb6/0xc0 arch/x86/kernel/head_64.S:243
> >
> > Any ideas what might be wrong?
> >
> > This does not crash when redzones are not enabled.
> >
> > Thanks,
> > -- Marco
> >
> > -- >8 --
> >
> > diff --git a/init/main.c b/init/main.c
> > index 15bd0efff3df..f4aa5bb3f2ec 100644
> > --- a/init/main.c
> > +++ b/init/main.c
> > @@ -1041,6 +1041,16 @@ asmlinkage __visible void __init start_kernel(void)
> > sfi_init_late();
> > kcsan_init();
> >
> > + /* DEBUG CODE */
> > + {
> > + struct kmem_cache *c = kmem_cache_create("test", 21, 1, 0,
> > NULL);
> > + char *buf;
> > + BUG_ON(!c);
> > + buf = kmem_cache_alloc(c, GFP_KERNEL);
> > + kmem_cache_free(c, buf);
> > + kmem_cache_destroy(c);
> > + }
> > +
> > /* Do the rest non-__init'ed, we're now alive */
> > arch_call_rest_init();
>
> Anything interesting in your .config? The fault does not reproduce
> with 5.8.0 + x86-64 defconfig.
It's quite close to defconfig, just some extra options for my test
environment. But none that I'd imagine change this behaviour -- but
maybe I missed something. I've attached my config. Also, just in case,
I'm on mainline from Tuesday: 2324d50d051ec0f14a548e78554fb02513d6dcef.
Thanks,
-- Marco
> - Pekka
#
# Automatically generated file; DO NOT EDIT.
# Linux/x86 5.8.0 Kernel Configuration
#
CONFIG_CC_VERSION_TEXT="gcc (GCC) 10.1.0"
CONFIG_CC_IS_GCC=y
CONFIG_GCC_VERSION=100100
CONFIG_LD_VERSION=23400
CONFIG_CLANG_VERSION=0
CONFIG_CC_CAN_LINK=y
CONFIG_CC_CAN_LINK_STATIC=y
CONFIG_CC_HAS_ASM_GOTO=y
CONFIG_CC_HAS_ASM_INLINE=y
CONFIG_IRQ_WORK=y
CONFIG_BUILDTIME_TABLE_SORT=y
CONFIG_THREAD_INFO_IN_TASK=y
#
# General setup
#
CONFIG_INIT_ENV_ARG_LIMIT=32
# CONFIG_COMPILE_TEST is not set
CONFIG_LOCALVERSION=""
# CONFIG_LOCALVERSION_AUTO is not set
CONFIG_BUILD_SALT=""
CONFIG_HAVE_KERNEL_GZIP=y
CONFIG_HAVE_KERNEL_BZIP2=y
CONFIG_HAVE_KERNEL_LZMA=y
CONFIG_HAVE_KERNEL_XZ=y
CONFIG_HAVE_KERNEL_LZO=y
CONFIG_HAVE_KERNEL_LZ4=y
CONFIG_HAVE_KERNEL_ZSTD=y
CONFIG_KERNEL_GZIP=y
# CONFIG_KERNEL_BZIP2 is not set
# CONFIG_KERNEL_LZMA is not set
# CONFIG_KERNEL_XZ is not set
# CONFIG_KERNEL_LZO is not set
# CONFIG_KERNEL_LZ4 is not set
# CONFIG_KERNEL_ZSTD is not set
CONFIG_DEFAULT_INIT=""
CONFIG_DEFAULT_HOSTNAME="(none)"
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
CONFIG_SYSVIPC_SYSCTL=y
CONFIG_POSIX_MQUEUE=y
CONFIG_POSIX_MQUEUE_SYSCTL=y
# CONFIG_WATCH_QUEUE is not set
CONFIG_CROSS_MEMORY_ATTACH=y
CONFIG_USELIB=y
CONFIG_AUDIT=y
CONFIG_HAVE_ARCH_AUDITSYSCALL=y
CONFIG_AUDITSYSCALL=y
#
# IRQ subsystem
#
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_GENERIC_IRQ_SHOW=y
CONFIG_GENERIC_IRQ_EFFECTIVE_AFF_MASK=y
CONFIG_GENERIC_PENDING_IRQ=y
CONFIG_GENERIC_IRQ_MIGRATION=y
CONFIG_HARDIRQS_SW_RESEND=y
C
Re: Odd-sized kmem_cache_alloc and slub_debug=Z
On Fri, Aug 07, 2020 at 06:06:27PM +0200, Marco Elver wrote:
> I found that the below debug-code using kmem_cache_alloc(), when using
> slub_debug=Z, results in the following crash:
>
> general protection fault, probably for non-canonical address
> 0xcca41caea170: [#1] PREEMPT SMP PTI
> CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.8.0+ #1
> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1
> 04/01/2014
> RIP: 0010:freelist_dereference mm/slub.c:272 [inline]
> RIP: 0010:get_freepointer mm/slub.c:278 [inline]
That really looks like more fun from my moving the freelist pointer...
> R13: cca41caea160 R14: e7c6a072ba80 R15: a3a41c96d540
Except that it's all at the start, which doesn't look like "data"
nor the hardened freelist obfuscation.
> FS: () GS:a3a41fc0()
> knlGS:
> CS: 0010 DS: ES: CR0: 80050033
> CR2: a3a051c01000 CR3: 00045140a001 CR4: 00770ef0
> DR0: DR1: DR2:
> DR3: DR6: fffe0ff0 DR7: 0400
> PKRU:
> Call Trace:
>___slab_alloc+0x336/0x340 mm/slub.c:2690
>__slab_alloc mm/slub.c:2714 [inline]
>slab_alloc_node mm/slub.c:2788 [inline]
>slab_alloc mm/slub.c:2832 [inline]
>kmem_cache_alloc+0x135/0x200 mm/slub.c:2837
>start_kernel+0x3d6/0x44e init/main.c:1049
>secondary_startup_64+0xb6/0xc0 arch/x86/kernel/head_64.S:243
>
> Any ideas what might be wrong?
>
> This does not crash when redzones are not enabled.
>
> Thanks,
> -- Marco
>
> -- >8 --
>
> diff --git a/init/main.c b/init/main.c
> index 15bd0efff3df..f4aa5bb3f2ec 100644
> --- a/init/main.c
> +++ b/init/main.c
> @@ -1041,6 +1041,16 @@ asmlinkage __visible void __init start_kernel(void)
> sfi_init_late();
> kcsan_init();
>
> + /* DEBUG CODE */
> + {
> + struct kmem_cache *c = kmem_cache_create("test", 21, 1, 0,
> NULL);
> + char *buf;
> + BUG_ON(!c);
> + buf = kmem_cache_alloc(c, GFP_KERNEL);
> + kmem_cache_free(c, buf);
> + kmem_cache_destroy(c);
> + }
> +
> /* Do the rest non-__init'ed, we're now alive */
> arch_call_rest_init();
>
Which kernel version? Can you send your CONFIG too?
--
Kees Cook
Re: [PATCH ghak90 V9 11/13] audit: contid check descendancy and nesting
On 2020-07-05 11:11, Paul Moore wrote:
> On Sat, Jun 27, 2020 at 9:23 AM Richard Guy Briggs wrote:
> > Require the target task to be a descendant of the container
> > orchestrator/engine.
> >
> > You would only change the audit container ID from one set or inherited
> > value to another if you were nesting containers.
> >
> > If changing the contid, the container orchestrator/engine must be a
> > descendant and not same orchestrator as the one that set it so it is not
> > possible to change the contid of another orchestrator's container.
Are we able to agree on the premises above? Is anything asserted that
should not be and is there anything missing?
I've been sitting on my response below for more than a week trying to
understand the issues raised and to give it the proper attention to a
reply. Please excuse my tardiness at replying on this issue since I'm
still having trouble thinking through all the scenarios for nesting.
> > Since the task_is_descendant() function is used in YAMA and in audit,
> > remove the duplication and pull the function into kernel/core/sched.c
> >
> > Signed-off-by: Richard Guy Briggs
> > ---
> > include/linux/sched.h| 3 +++
> > kernel/audit.c | 23 +--
> > kernel/sched/core.c | 33 +
> > security/yama/yama_lsm.c | 33 -
> > 4 files changed, 57 insertions(+), 35 deletions(-)
> >
> > diff --git a/include/linux/sched.h b/include/linux/sched.h
> > index 2213ac670386..06938d0b9e0c 100644
> > --- a/include/linux/sched.h
> > +++ b/include/linux/sched.h
> > @@ -2047,4 +2047,7 @@ static inline void rseq_syscall(struct pt_regs *regs)
> >
> > const struct cpumask *sched_trace_rd_span(struct root_domain *rd);
> >
> > +extern int task_is_descendant(struct task_struct *parent,
> > + struct task_struct *child);
> > +
> > #endif
> > diff --git a/kernel/audit.c b/kernel/audit.c
> > index a862721dfd9b..efa65ec01239 100644
> > --- a/kernel/audit.c
> > +++ b/kernel/audit.c
> > @@ -2713,6 +2713,20 @@ int audit_signal_info(int sig, struct task_struct *t)
> > return audit_signal_info_syscall(t);
> > }
> >
> > +static bool audit_contid_isnesting(struct task_struct *tsk)
> > +{
> > + bool isowner = false;
> > + bool ownerisparent = false;
> > +
> > + rcu_read_lock();
> > + if (tsk->audit && tsk->audit->cont) {
> > + isowner = current == tsk->audit->cont->owner;
> > + ownerisparent = task_is_descendant(tsk->audit->cont->owner,
> > current);
>
> I want to make sure I'm understanding this correctly and I keep
> mentally tripping over something: it seems like for a given audit
> container ID a task is either the owner or a descendent, there is no
> third state, is that correct?
Sure there is. It could be another owner (which is addressed when we
search for an existing contobj match), or in the next patch, the
owner's parent if nested or a peer.
> Assuming that is true, can the descendent check simply be a negative
> owner check given they both have the same audit container ID?
There isn't actually a check in my code for the orchestrator contid and
task contid being the same. Maybe I was making this check more
complicated than necessary, and still incomplete, but see below for more...
> > + }
> > + rcu_read_unlock();
> > + return !isowner && ownerisparent;
> > +}
> > +
> > /*
> > * audit_set_contid - set current task's audit contid
> > * @task: target task
> > @@ -2755,8 +2769,13 @@ int audit_set_contid(struct task_struct *task, u64
> > contid)
> > rc = -EBUSY;
> > goto unlock;
> > }
> > - /* if contid is already set, deny */
> > - if (audit_contid_set(task))
> > + /* if task is not descendant, block */
> > + if (task == current || !task_is_descendant(current, task)) {
>
> I'm also still fuzzy on why we can't let a task set it's own audit
> container ID, assuming it meets all the criteria established in patch
> 2/13. It somewhat made sense when you were tracking inherited vs
> explicitly set audit container IDs, but that doesn't appear to be the
> case so far in this patchset, yes?
I'm still having a strong reluctance to permit this but can't come up
with a solid technical reason right now, but it feels like a layer
violation. If we forbid it and discover it necessary and harmless, then
permitting it won't break the API. If we permit it and later discover a
reason it causes a problem, then blocking it will break the API. I have
heard that there are cases where there is no orchestrator/engine, so in
those cases I conclude that a process would need to set its own contid
but I'm having trouble recalling what those circumstances are.
I also was seriously considering blocking any contid set on the initial
user or PID namespaces to avoid polluting them, and even had a tested
patch to implement it, but this starts
Re: [RFC PATCH 0/7] metricfs metric file system and examples
On 8/5/20 5:14 PM, Jonathan Adams wrote: > To try to restart the discussion of kernel statistics started by the > statsfs patchsets (https://lkml.org/lkml/2020/5/26/332), I wanted > to share the following set of patches which are Google's 'metricfs' > implementation and some example uses. Google has been using metricfs > internally since 2012 as a way to export various statistics to our > telemetry systems (similar to OpenTelemetry), and we have over 200 > statistics exported on a typical machine. > Hi, AFAIK all Linux filesystems (including pseudo/synthetic ones) live under fs/, not in kernel/. Therefore I think that this patch series needs more exposure, i.e., Cc: it to linux-fsde...@vger.kernel.org and net...@vger.kernel.org. oh, and to gregkh. > Jonathan Adams (5): > core/metricfs: add support for percpu metricfs files > core/metricfs: metric for kernel warnings > core/metricfs: expose softirq information through metricfs > core/metricfs: expose scheduler stat information through metricfs > core/metricfs: expose x86-specific irq information through metricfs > > Justin TerAvest (1): > core/metricfs: Create metricfs, standardized files under debugfs. > > Laurent Chavey (1): > net-metricfs: Export /proc/net/dev via metricfs. > > arch/x86/kernel/irq.c | 80 > fs/proc/stat.c | 57 +++ > include/linux/metricfs.h | 131 +++ > kernel/Makefile| 2 + > kernel/metricfs.c | 775 + > kernel/metricfs_examples.c | 151 > kernel/panic.c | 131 +++ > kernel/softirq.c | 45 +++ > lib/Kconfig.debug | 18 + > net/core/Makefile | 1 + > net/core/net_metricfs.c| 194 ++ > 11 files changed, 1585 insertions(+) > create mode 100644 include/linux/metricfs.h > create mode 100644 kernel/metricfs.c > create mode 100644 kernel/metricfs_examples.c > create mode 100644 net/core/net_metricfs.c thanks. -- ~Randy
[PATCH v4 4/5] rcutorture: Force synchronizing of RCU flavor from hotplug notifier
RCU has had deadlocks in the past related to synchronizing in a hotplug
notifier. Typically, this has occurred because timer callbacks did not get
migrated before the CPU hotplug notifier requesting RCU's services is
called. If RCU's grace period processing has a timer callback queued in
the meanwhile, it may never get called causing RCU stalls.
These issues have been fixed by removing such dependencies from grace
period processing, however there are no testing scenarios for such
cases.
This commit therefore reuses rcutorture's existing hotplug notifier to
invoke the flavor-specific synchronize callback. If anything locks up,
we expect stall warnings and/or other splats.
Obviously, we need not test for rcu_barrier from a notifier, since those
are not allowed from notifiers. This fact is already detailed in the
documentation as well.
Signed-off-by: Joel Fernandes (Google)
---
kernel/rcu/rcutorture.c | 81 +
1 file changed, 42 insertions(+), 39 deletions(-)
diff --git a/kernel/rcu/rcutorture.c b/kernel/rcu/rcutorture.c
index 92cb79620939..083b65e4877d 100644
--- a/kernel/rcu/rcutorture.c
+++ b/kernel/rcu/rcutorture.c
@@ -1645,12 +1645,37 @@ rcu_torture_print_module_parms(struct rcu_torture_ops
*cur_ops, const char *tag)
read_exit_delay, read_exit_burst);
}
-static int rcutorture_booster_cleanup(unsigned int cpu)
+static bool rcu_torture_can_boost(void)
+{
+ static int boost_warn_once;
+ int prio;
+
+ if (!(test_boost == 1 && cur_ops->can_boost) && test_boost != 2)
+ return false;
+
+ prio = rcu_get_gp_kthreads_prio();
+ if (!prio)
+ return false;
+
+ if (prio < 2) {
+ if (boost_warn_once == 1)
+ return false;
+
+ pr_alert("%s: WARN: RCU kthread priority too low to test
boosting. Skipping RCU boost test. Try passing rcutree.kthread_prio > 1 on the
kernel command line.\n", KBUILD_MODNAME);
+ boost_warn_once = 1;
+ return false;
+ }
+
+ return true;
+}
+
+static int rcutorture_hp_cleanup(unsigned int cpu)
{
struct task_struct *t;
- if (boost_tasks[cpu] == NULL)
+ if (!rcu_torture_can_boost() || boost_tasks[cpu] == NULL)
return 0;
+
mutex_lock(&boost_mutex);
t = boost_tasks[cpu];
boost_tasks[cpu] = NULL;
@@ -1662,11 +1687,14 @@ static int rcutorture_booster_cleanup(unsigned int cpu)
return 0;
}
-static int rcutorture_booster_init(unsigned int cpu)
+static int rcutorture_hp_init(unsigned int cpu)
{
int retval;
- if (boost_tasks[cpu] != NULL)
+ /* Force synchronizing from hotplug notifier to ensure it is safe. */
+ cur_ops->sync();
+
+ if (!rcu_torture_can_boost() || boost_tasks[cpu] != NULL)
return 0; /* Already created, nothing more to do. */
/* Don't allow time recalculation while creating a new task. */
@@ -2336,30 +2364,6 @@ static void rcu_torture_barrier_cleanup(void)
}
}
-static bool rcu_torture_can_boost(void)
-{
- static int boost_warn_once;
- int prio;
-
- if (!(test_boost == 1 && cur_ops->can_boost) && test_boost != 2)
- return false;
-
- prio = rcu_get_gp_kthreads_prio();
- if (!prio)
- return false;
-
- if (prio < 2) {
- if (boost_warn_once == 1)
- return false;
-
- pr_alert("%s: WARN: RCU kthread priority too low to test
boosting. Skipping RCU boost test. Try passing rcutree.kthread_prio > 1 on the
kernel command line.\n", KBUILD_MODNAME);
- boost_warn_once = 1;
- return false;
- }
-
- return true;
-}
-
static bool read_exit_child_stop;
static bool read_exit_child_stopped;
static wait_queue_head_t read_exit_wq;
@@ -2503,8 +2507,7 @@ rcu_torture_cleanup(void)
rcutorture_seq_diff(gp_seq, start_gp_seq));
torture_stop_kthread(rcu_torture_stats, stats_task);
torture_stop_kthread(rcu_torture_fqs, fqs_task);
- if (rcu_torture_can_boost())
- cpuhp_remove_state(rcutor_hp);
+ cpuhp_remove_state(rcutor_hp);
/*
* Wait for all RCU callbacks to fire, then do torture-type-specific
@@ -2773,21 +2776,21 @@ rcu_torture_init(void)
if (firsterr)
goto unwind;
}
+
+ firsterr = cpuhp_setup_state(CPUHP_AP_ONLINE_DYN, "RCU_TORTURE",
+ rcutorture_hp_init,
+ rcutorture_hp_cleanup);
+ if (firsterr < 0)
+ goto unwind;
+ rcutor_hp = firsterr;
+
if (test_boost_interval < 1)
test_boost_interval = 1;
if (test_boost_duration < 2)
test_boost_duration = 2;
- if (rcu_torture_can_boost()) {
-
+ if (rcu_torture_can_boost())
boost_starttime =
[PATCH v4 2/5] rcu/tree: Clarify comments about FQS loop reporting quiescent states
At least since v4.19, the FQS loop no longer reports quiescent states
for offline CPUs unless it is an emergency.
This commit therefore fixes the comment in rcu_gp_init() to match the
current code.
Signed-off-by: Joel Fernandes (Google)
---
kernel/rcu/tree.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c
index a49fa3b60faa..2fb66cdbfa25 100644
--- a/kernel/rcu/tree.c
+++ b/kernel/rcu/tree.c
@@ -1701,9 +1701,11 @@ static bool rcu_gp_init(void)
/*
* Apply per-leaf buffered online and offline operations to the
-* rcu_node tree. Note that this new grace period need not wait
-* for subsequent online CPUs, and that quiescent-state forcing
-* will handle subsequent offline CPUs.
+* rcu_node tree. Note that this new grace period need not wait for
+* subsequent online CPUs, and that RCU hooks in the CPU offlining
+* path, when combined with checks in this function, will handle CPUs
+* that are currently going offline or that go offline later. Refer to
+* RCU's Requirements documentation about hotplug requirements as well.
*/
rcu_state.gp_state = RCU_GP_ONOFF;
rcu_for_each_leaf_node(rnp) {
--
2.28.0.236.gb10cc79966-goog
[PATCH v4 3/5] rcu/tree: Make FQS complaining about offline CPU more aggressive
The FQS loop detecting that an offline CPU has not yet reported a
quiescent state, is a serious problem. The current interaction between
RCU quiescent-state reporting and CPU-hotplug operations means that the
FQS loop should never find that an offline CPU (by RCU's understanding
of what is offline or not) has not yet reported a quiescent state.
First, the outgoing CPU explicitly reports a quiescent state if needed
in rcu_report_dead(). Second, the race where the CPU is leaving just as
RCU is initializing a new grace period is handled by an explicit check
for this condition in rcu_gp_init(). Third, the CPU's leaf rcu_node
structure's ->lock serializes these modifications and checks.
At the moment, the FQS loop detections this anomaly but only reports it
after a second has elapsed.
This commit therefore makes the warning more aggressive such that we fail
immediately when the FQS loop scan happens and bring the problem to
everyone's attention.
Light testing with TREE03 and hotplug shows no warnings. Converted the
warning as well to WARN_ON_ONCE() to reduce log spam.
Signed-off-by: Joel Fernandes (Google)
---
kernel/rcu/tree.c | 22 ++
1 file changed, 18 insertions(+), 4 deletions(-)
diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c
index 2fb66cdbfa25..850628aba813 100644
--- a/kernel/rcu/tree.c
+++ b/kernel/rcu/tree.c
@@ -1208,13 +1208,27 @@ static int rcu_implicit_dynticks_qs(struct rcu_data
*rdp)
return 1;
}
- /* If waiting too long on an offline CPU, complain. */
- if (!(rdp->grpmask & rcu_rnp_online_cpus(rnp)) &&
- time_after(jiffies, rcu_state.gp_start + HZ)) {
+ /*
+* Complain if an offline CPU by RCU's hotplug bookkeeping has not
+* reported a quiescent state yet.
+*
+* Either a quiescent state for the offline CPU should have been
+* reported during CPU offlining, or during rcu_gp_init() if it
+* detected a race with either CPU offlining or task unblocking on a
+* node with all of its CPUs previously offlined. If neither of these
+* happened, we have a problem.
+*
+* The node lock is held here, ensuring exclusion from the
+* modification/checking of RCU's hotplug books by RCU's hotplug
+* notifier hooks and grace period initialization code.
+*
+* Refer to RCU's Requirements documentation about hotplug requirements
+* as well.
+*/
+ if (WARN_ON_ONCE(!(rdp->grpmask & rcu_rnp_online_cpus(rnp {
bool onl;
struct rcu_node *rnp1;
- WARN_ON(1); /* Offline CPUs are supposed to report QS! */
pr_info("%s: grp: %d-%d level: %d ->gp_seq %ld ->completedqs
%ld\n",
__func__, rnp->grplo, rnp->grphi, rnp->level,
(long)rnp->gp_seq, (long)rnp->completedqs);
--
2.28.0.236.gb10cc79966-goog
[PATCH v4 5/5] docs: Update RCU's hotplug requirements with a bit about design
RCU's hotplug design will help understand the requirements an RCU implementation needs to fullfill, such as dead-lock avoidance. The rcu_barrier() section of the "Hotplug CPU" section already talks about deadlocks, however the description of what else can deadlock other than rcu_barrier is rather incomplete. This commit therefore continues the section by describing how RCU's design handles CPU hotplug in a deadlock-free way. Signed-off-by: Joel Fernandes (Google) --- .../RCU/Design/Requirements/Requirements.rst | 22 +++ 1 file changed, 22 insertions(+) diff --git a/Documentation/RCU/Design/Requirements/Requirements.rst b/Documentation/RCU/Design/Requirements/Requirements.rst index 16c64a2eff93..0a4148b9f743 100644 --- a/Documentation/RCU/Design/Requirements/Requirements.rst +++ b/Documentation/RCU/Design/Requirements/Requirements.rst @@ -1940,6 +1940,28 @@ deadlock. Furthermore, ``rcu_barrier()`` blocks CPU-hotplug operations during its execution, which results in another type of deadlock when invoked from a CPU-hotplug notifier. +Also, RCU's implementation avoids serious deadlocks which could occur due to +interaction between hotplug, timers and grace period processing. It does so by +maintaining its own bookkeeping of every CPU's hotplug state, independent of +the various CPU masks and by reporting quiescent states at explicit points. It +may come across as a surprise, but the force quiescent state loop (FQS) does +not report quiescent states for offline CPUs and is not required to. + +For an offline CPU, the quiescent state will be reported in either of: +1. During CPU offlining, using RCU's hotplug notifier (``rcu_report_dead()``). +2. During grace period initialization (``rcu_gp_init``) if it detected a race + with CPU offlining, or a race with a task unblocking on a node which + previously had all of its CPUs offlined. + +The CPU onlining path (``rcu_cpu_starting``) does not need to a report +quiescent state for an offline CPU in fact it would trigger a warning if a +quiescent state was not already reported for that CPU. + +During the checking/modification of RCU's hotplug bookkeeping, the +corresponding CPU's leaf node lock is held. This avoids race conditions between +RCU's hotplug notifier hooks, grace period initialization code and the FQS loop +which can concurrently refer to or modify the bookkeeping. + Scheduler and RCU ~ -- 2.28.0.236.gb10cc79966-goog
[PATCH v4 0/5] option-subject: RCU and CPU hotplug checks and docs
This series improves/adds to RCU's warnings about CPU hotplug and adds documentation and testing. v3->v4: Minor cleanups. Joel Fernandes (Google) (5): rcu/tree: Add a warning if CPU being onlined did not report QS already rcu/tree: Clarify comments about FQS loop reporting quiescent states rcu/tree: Make FQS complaining about offline CPU more aggressive rcutorture: Force synchronizing of RCU flavor from hotplug notifier docs: Update RCU's hotplug requirements with a bit about design .../RCU/Design/Requirements/Requirements.rst | 22 + kernel/rcu/rcutorture.c | 81 ++- kernel/rcu/tree.c | 39 +++-- 3 files changed, 95 insertions(+), 47 deletions(-) -- 2.28.0.236.gb10cc79966-goog
[PATCH v4 1/5] rcu/tree: Add a warning if CPU being onlined did not report QS already
Currently, rcu_cpu_starting() checks to see if the RCU core expects a
quiescent state from the incoming CPU. However, the current interaction
between RCU quiescent-state reporting and CPU-hotplug operations should
mean that the incoming CPU never needs to report a quiescent state.
First, the outgoing CPU reports a quiescent state if needed. Second,
the race where the CPU is leaving just as RCU is initializing a new
grace period is handled by an explicit check for this condition. Third,
the CPU's leaf rcu_node structure's ->lock serializes these checks.
This means that if rcu_cpu_starting() ever feels the need to report
a quiescent state, then there is a bug somewhere in the CPU hotplug
code or the RCU grace-period handling code. This commit therefore
adds a WARN_ON_ONCE() to bring that bug to everyone's attention.
Cc: Paul E. McKenney
Cc: Neeraj Upadhyay
Suggested-by: Paul E. McKenney
Signed-off-by: Joel Fernandes (Google)
---
kernel/rcu/tree.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c
index 65e1b5e92319..a49fa3b60faa 100644
--- a/kernel/rcu/tree.c
+++ b/kernel/rcu/tree.c
@@ -3996,7 +3996,14 @@ void rcu_cpu_starting(unsigned int cpu)
rcu_gpnum_ovf(rnp, rdp); /* Offline-induced counter wrap? */
rdp->rcu_onl_gp_seq = READ_ONCE(rcu_state.gp_seq);
rdp->rcu_onl_gp_flags = READ_ONCE(rcu_state.gp_flags);
- if (rnp->qsmask & mask) { /* RCU waiting on incoming CPU? */
+
+ /*
+* XXX: The following rcu_report_qs_rnp() is redundant. If the below
+* warning does not fire, consider replacing it with the "else" block,
+* by June 2021 or so (while keeping the warning). Refer to RCU's
+* Requirements documentation for the rationale.
+*/
+ if (WARN_ON_ONCE(rnp->qsmask & mask)) { /* RCU waiting on incoming CPU?
*/
rcu_disable_urgency_upon_qs(rdp);
/* Report QS -after- changing ->qsmaskinitnext! */
rcu_report_qs_rnp(mask, rnp, rnp->gp_seq, flags);
--
2.28.0.236.gb10cc79966-goog
Re: [PATCH] kcsan: Treat runtime as NMI-like with interrupt tracing
On Fri, Aug 07, 2020 at 11:00:31AM +0200, Marco Elver wrote:
> Since KCSAN instrumentation is everywhere, we need to treat the hooks
> NMI-like for interrupt tracing. In order to present an as 'normal' as
> possible context to the code called by KCSAN when reporting errors, we
> need to update the IRQ-tracing state.
>
> Tested: Several runs through kcsan-test with different configuration
> (PROVE_LOCKING on/off), as well as hours of syzbot testing with the
> original config that caught the problem (without CONFIG_PARAVIRT=y,
> which appears to cause IRQ state tracking inconsistencies even when
> KCSAN remains off, see Link).
>
> Link: https://lkml.kernel.org/r/7d3b2d05ac1c3...@google.com
> Fixes: 248591f5d257 ("kcsan: Make KCSAN compatible with new IRQ state
> tracking")
> Reported-by: syzbot+8db9e1ecde74e590a...@syzkaller.appspotmail.com
> Co-developed-by: Peter Zijlstra (Intel)
> Signed-off-by: Marco Elver
> ---
> Patch Note: This patch applies to latest mainline. While current
> mainline suffers from the above problem, the configs required to hit the
> issue are likely not enabled too often (of course with PROVE_LOCKING on;
> we hit it on syzbot though). It'll probably be wise to queue this as
> normal on -rcu, just in case something is still off, given the
> non-trivial nature of the issue. (If it should instead go to mainline
> right now as a fix, I'd like some more test time on syzbot.)
The usual, please let me know when/if you would like me to apply
to -rcu. And have a great weekend!
Thanx, Paul
> ---
> kernel/kcsan/core.c | 79 ++--
> kernel/kcsan/kcsan.h | 3 +-
> 2 files changed, 62 insertions(+), 20 deletions(-)
>
> diff --git a/kernel/kcsan/core.c b/kernel/kcsan/core.c
> index 9147ff6a12e5..6202a645f1e2 100644
> --- a/kernel/kcsan/core.c
> +++ b/kernel/kcsan/core.c
> @@ -291,13 +291,28 @@ static inline unsigned int get_delay(void)
> 0);
> }
>
> -void kcsan_save_irqtrace(struct task_struct *task)
> -{
> +/*
> + * KCSAN instrumentation is everywhere, which means we must treat the hooks
> + * NMI-like for interrupt tracing. In order to present a 'normal' as possible
> + * context to the code called by KCSAN when reporting errors we need to
> update
> + * the IRQ-tracing state.
> + *
> + * Save and restore the IRQ state trace touched by KCSAN, since KCSAN's
> + * runtime is entered for every memory access, and potentially useful
> + * information is lost if dirtied by KCSAN.
> + */
> +
> +struct kcsan_irq_state {
> + unsigned long flags;
> #ifdef CONFIG_TRACE_IRQFLAGS
> - task->kcsan_save_irqtrace = task->irqtrace;
> + int hardirqs_enabled;
> #endif
> -}
> +};
>
> +/*
> + * This is also called by the reporting task for the other task, to generate
> the
> + * right report with CONFIG_KCSAN_VERBOSE. No harm in restoring more than
> once.
> + */
> void kcsan_restore_irqtrace(struct task_struct *task)
> {
> #ifdef CONFIG_TRACE_IRQFLAGS
> @@ -305,6 +320,41 @@ void kcsan_restore_irqtrace(struct task_struct *task)
> #endif
> }
>
> +/*
> + * Saves/restores IRQ state (see comment above). Need noinline to work around
> + * unfortunate code-gen upon inlining, resulting in objtool getting confused
> as
> + * well as losing stack trace information.
> + */
> +static noinline void kcsan_irq_save(struct kcsan_irq_state *irq_state)
> +{
> +#ifdef CONFIG_TRACE_IRQFLAGS
> + current->kcsan_save_irqtrace = current->irqtrace;
> + irq_state->hardirqs_enabled = lockdep_hardirqs_enabled();
> +#endif
> + if (!kcsan_interrupt_watcher) {
> + kcsan_disable_current(); /* Lockdep might WARN, etc. */
> + raw_local_irq_save(irq_state->flags);
> + lockdep_hardirqs_off(_RET_IP_);
> + kcsan_enable_current();
> + }
> +}
> +
> +static noinline void kcsan_irq_restore(struct kcsan_irq_state *irq_state)
> +{
> + if (!kcsan_interrupt_watcher) {
> + kcsan_disable_current(); /* Lockdep might WARN, etc. */
> +#ifdef CONFIG_TRACE_IRQFLAGS
> + if (irq_state->hardirqs_enabled) {
> + lockdep_hardirqs_on_prepare(_RET_IP_);
> + lockdep_hardirqs_on(_RET_IP_);
> + }
> +#endif
> + raw_local_irq_restore(irq_state->flags);
> + kcsan_enable_current();
> + }
> + kcsan_restore_irqtrace(current);
> +}
> +
> /*
> * Pull everything together: check_access() below contains the performance
> * critical operations; the fast-path (including check_access) functions
> should
> @@ -350,11 +400,13 @@ static noinline void kcsan_found_watchpoint(const
> volatile void *ptr,
> flags = user_access_save();
>
> if (consumed) {
> - kcsan_save_irqtrace(current);
> + struct kcsan_irq_state irqstate;
> +
> + kcsan_irq_save(&irqstate);
>
Re: Odd-sized kmem_cache_alloc and slub_debug=Z
Hi Marco,
On Fri, Aug 7, 2020 at 7:07 PM Marco Elver wrote:
> I found that the below debug-code using kmem_cache_alloc(), when using
> slub_debug=Z, results in the following crash:
>
> general protection fault, probably for non-canonical address
> 0xcca41caea170: [#1] PREEMPT SMP PTI
> CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.8.0+ #1
> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1
> 04/01/2014
> RIP: 0010:freelist_dereference mm/slub.c:272 [inline]
> RIP: 0010:get_freepointer mm/slub.c:278 [inline]
> RIP: 0010:deactivate_slab+0x54/0x460 mm/slub.c:2111
> Code: 8b bc c7 e0 00 00 00 48 85 d2 0f 84 00 01 00 00 49 89 d5 31 c0
> 48 89 44 24 08 66 66 2e 0f 1f 84 00 00 00 00 00 90 44 8b 43 20 <4b> 8b 44 05
> 00 48 85 c0 0f 84 1e 01 00 00 4c 89 ed 49 89 c5 8b 43
> RSP: :a7e03e18 EFLAGS: 00010046
> RAX: RBX: a3a41c972340 RCX:
> RDX: cca41caea160 RSI: e7c6a072ba80 RDI: a3a41c972340
> RBP: a3a41caea008 R08: 0010 R09: a3a41caea01d
> R10: a7f8dc50 R11: a68f44c0 R12: a3a41c972340
> R13: cca41caea160 R14: e7c6a072ba80 R15: a3a41c96d540
> FS: () GS:a3a41fc0()
> knlGS:
> CS: 0010 DS: ES: CR0: 80050033
> CR2: a3a051c01000 CR3: 00045140a001 CR4: 00770ef0
> DR0: DR1: DR2:
> DR3: DR6: fffe0ff0 DR7: 0400
> PKRU:
> Call Trace:
> ___slab_alloc+0x336/0x340 mm/slub.c:2690
> __slab_alloc mm/slub.c:2714 [inline]
> slab_alloc_node mm/slub.c:2788 [inline]
> slab_alloc mm/slub.c:2832 [inline]
> kmem_cache_alloc+0x135/0x200 mm/slub.c:2837
> start_kernel+0x3d6/0x44e init/main.c:1049
> secondary_startup_64+0xb6/0xc0 arch/x86/kernel/head_64.S:243
>
> Any ideas what might be wrong?
>
> This does not crash when redzones are not enabled.
>
> Thanks,
> -- Marco
>
> -- >8 --
>
> diff --git a/init/main.c b/init/main.c
> index 15bd0efff3df..f4aa5bb3f2ec 100644
> --- a/init/main.c
> +++ b/init/main.c
> @@ -1041,6 +1041,16 @@ asmlinkage __visible void __init start_kernel(void)
> sfi_init_late();
> kcsan_init();
>
> + /* DEBUG CODE */
> + {
> + struct kmem_cache *c = kmem_cache_create("test", 21, 1, 0,
> NULL);
> + char *buf;
> + BUG_ON(!c);
> + buf = kmem_cache_alloc(c, GFP_KERNEL);
> + kmem_cache_free(c, buf);
> + kmem_cache_destroy(c);
> + }
> +
> /* Do the rest non-__init'ed, we're now alive */
> arch_call_rest_init();
Anything interesting in your .config? The fault does not reproduce
with 5.8.0 + x86-64 defconfig.
- Pekka
Re: [PATCH] clk: samsung: Prevent potential endless loop in the PLL set_rate ops
Hi Tomasz,
On 8/6/20 18:11, Tomasz Figa wrote:
>> --- a/drivers/clk/samsung/clk-pll.c
>> +++ b/drivers/clk/samsung/clk-pll.c
>> @@ -63,6 +63,27 @@ static long samsung_pll_round_rate(struct clk_hw *hw,
>> return rate_table[i - 1].rate;
>> }
>>
>> +static int samsung_pll_lock_wait(struct samsung_clk_pll *pll,
>> +unsigned int reg_mask)
>> +{
>> + ktime_t timeout;
>> +
>> + /* Wait until the PLL is in steady locked state */
>> + timeout = ktime_add_ms(ktime_get(), PLL_TIMEOUT_MS);
>> +
>> + while (!(readl_relaxed(pll->con_reg) & reg_mask)) {
>> + if (ktime_after(ktime_get(), timeout)) {
>> + pr_err("%s: Could not lock PLL %s\n",
>> + __func__, clk_hw_get_name(&pll->hw));
>> + return -EFAULT;
>> + }
>> +
>> + cpu_relax();
>> + }
> Thanks for the patch! Good to have this consolidated. How about going
> one step further and using the generic
> readl_relaxed_poll_timeout_atomic() helper?
Might be a good suggestion, I was considering those helpers but ended
up not using them in the patch. The cpu_relax() call might also not be
really needed now, when there is the ktime code within the loop.
Having multiple occurrences of readl_relaxed_poll_timeout_atomic() could
increase the code size due to inlining. How about keeping the
samsung_pll_lock_wait() function and just changing its implementation?
--
Thanks,
Sylwester
Re: [PATCH] kernel: bpf: delete repeated words in comments
On 8/7/20 5:31 AM, Randy Dunlap wrote:
Drop repeated words in kernel/bpf/.
{has, the}
Signed-off-by: Randy Dunlap
Cc: Alexei Starovoitov
Cc: Daniel Borkmann
Cc: net...@vger.kernel.org
Cc: b...@vger.kernel.org
Applied, thanks!
Re: [PATCH bpf] bpf: doc: remove references to warning message when using bpf_trace_printk()
On 8/7/20 1:50 PM, Alan Maguire wrote:
The BPF helper bpf_trace_printk() no longer uses trace_printk();
it is now triggers a dedicated trace event. Hence the described
warning is no longer present, so remove the discussion of it as
it may confuse people.
Fixes: ac5a72ea5c89 ("bpf: Use dedicated bpf_trace_printk event instead of
trace_printk()")
Signed-off-by: Alan Maguire
Applied, thanks!
[PATCH] security: keys: delete repeated words in comments
Drop repeated words in comments.
{to, will, the}
Signed-off-by: Randy Dunlap
Cc: David Howells
Cc: Jarkko Sakkinen
Cc: keyri...@vger.kernel.org
Cc: James Morris
Cc: "Serge E. Hallyn"
Cc: linux-security-mod...@vger.kernel.org
---
security/keys/keyctl.c |2 +-
security/keys/keyring.c |4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
--- linux-next-20200731.orig/security/keys/keyctl.c
+++ linux-next-20200731/security/keys/keyctl.c
@@ -506,7 +506,7 @@ error:
* keyring, otherwise replace the link to the matching key with a link to the
* new key.
*
- * The key must grant the caller Link permission and the the keyring must grant
+ * The key must grant the caller Link permission and the keyring must grant
* the caller Write permission. Furthermore, if an additional link is created,
* the keyring's quota will be extended.
*
--- linux-next-20200731.orig/security/keys/keyring.c
+++ linux-next-20200731/security/keys/keyring.c
@@ -881,7 +881,7 @@ found:
*
* Keys are matched to the type provided and are then filtered by the match
* function, which is given the description to use in any way it sees fit. The
- * match function may use any attributes of a key that it wishes to to
+ * match function may use any attributes of a key that it wishes to
* determine the match. Normally the match function from the key type would be
* used.
*
@@ -1204,7 +1204,7 @@ static int keyring_detect_cycle_iterator
}
/*
- * See if a cycle will will be created by inserting acyclic tree B in acyclic
+ * See if a cycle will be created by inserting acyclic tree B in acyclic
* tree A at the topmost level (ie: as a direct child of A).
*
* Since we are adding B to A at the top level, checking for cycles should just
[PATCH] security: selinux: delete repeated words in comments
Drop a repeated word in comments.
{open, is, then}
Signed-off-by: Randy Dunlap
Cc: Paul Moore
Cc: Stephen Smalley
Cc: Eric Paris
Cc: seli...@vger.kernel.org
Cc: James Morris
Cc: "Serge E. Hallyn"
Cc: linux-security-mod...@vger.kernel.org
---
security/selinux/hooks.c |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
--- linux-next-20200731.orig/security/selinux/hooks.c
+++ linux-next-20200731/security/selinux/hooks.c
@@ -1978,7 +1978,7 @@ static inline u32 file_to_av(struct file
}
/*
- * Convert a file to an access vector and include the correct open
+ * Convert a file to an access vector and include the correct
* open permission.
*/
static inline u32 open_file_to_av(struct file *file)
@@ -,7 +,7 @@ static int selinux_skb_peerlbl_sid(struc
*
* If @skb_sid is valid then the user:role:type information from @sk_sid is
* combined with the MLS information from @skb_sid in order to create
- * @conn_sid. If @skb_sid is not valid then then @conn_sid is simply a copy
+ * @conn_sid. If @skb_sid is not valid then @conn_sid is simply a copy
* of @sk_sid. Returns zero on success, negative values on failure.
*
*/
@@ -5314,7 +5314,7 @@ static int selinux_sctp_bind_connect(str
/* As selinux_sctp_bind_connect() is called by the
* SCTP protocol layer, the socket is already locked,
-* therefore selinux_netlbl_socket_connect_locked() is
+* therefore selinux_netlbl_socket_connect_locked()
* is called here. The situations handled are:
* sctp_connectx(3), sctp_sendmsg(3), sendmsg(2),
* whenever a new IP address is added or when a new
[PATCH] security: ima: delete a repeated word in comments
Drop a repeated word in comments.
{the}
Signed-off-by: Randy Dunlap
Cc: Mimi Zohar
Cc: Dmitry Kasatkin
Cc: linux-integr...@vger.kernel.org
Cc: James Morris
Cc: "Serge E. Hallyn"
Cc: linux-security-mod...@vger.kernel.org
---
security/integrity/ima/ima_policy.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- linux-next-20200731.orig/security/integrity/ima/ima_policy.c
+++ linux-next-20200731/security/integrity/ima/ima_policy.c
@@ -719,7 +719,7 @@ static int __init ima_init_arch_policy(v
* ima_init_policy - initialize the default measure rules.
*
* ima_rules points to either the ima_default_rules or the
- * the new ima_policy_rules.
+ * new ima_policy_rules.
*/
void __init ima_init_policy(void)
{
[PATCH] security: apparmor: delete repeated words in comments
Drop repeated words in comments.
{a, then, to}
Signed-off-by: Randy Dunlap
Cc: John Johansen
Cc: appar...@lists.ubuntu.com
Cc: James Morris
Cc: "Serge E. Hallyn"
Cc: linux-security-mod...@vger.kernel.org
---
security/apparmor/include/file.h |2 +-
security/apparmor/path.c |2 +-
security/apparmor/policy_unpack.c |2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
--- linux-next-20200731.orig/security/apparmor/include/file.h
+++ linux-next-20200731/security/apparmor/include/file.h
@@ -167,7 +167,7 @@ int aa_audit_file(struct aa_profile *pro
* @perms: permission table indexed by the matched state accept entry of @dfa
* @trans: transition table for indexed by named x transitions
*
- * File permission are determined by matching a path against @dfa and then
+ * File permission are determined by matching a path against @dfa and
* then using the value of the accept entry for the matching state as
* an index into @perms. If a named exec transition is required it is
* looked up in the transition table.
--- linux-next-20200731.orig/security/apparmor/path.c
+++ linux-next-20200731/security/apparmor/path.c
@@ -83,7 +83,7 @@ static int disconnect(const struct path
*
* Returns: %0 else error code if path lookup fails
* When no error the path name is returned in @name which points to
- * to a position in @buf
+ * a position in @buf
*/
static int d_namespace_path(const struct path *path, char *buf, char **name,
int flags, const char *disconnected)
--- linux-next-20200731.orig/security/apparmor/policy_unpack.c
+++ linux-next-20200731/security/apparmor/policy_unpack.c
@@ -39,7 +39,7 @@
/*
* The AppArmor interface treats data as a type byte followed by the
- * actual data. The interface has the notion of a a named entry
+ * actual data. The interface has the notion of a named entry
* which has a name (AA_NAME typecode followed by name string) followed by
* the entries typecode and data. Named types allow for optional
* elements and extensions to be added and tested for without breaking
[PATCH 2/2] perf sched timehist: Fix use of CPU list with summary option
Do not update thread stats or show idle summary unless CPU is in
the list of interest.
Fixes: c30d630d1bcf ("perf sched timehist: Add support for filtering on CPU")
Signed-off-by: David Ahern
---
tools/perf/builtin-sched.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/tools/perf/builtin-sched.c b/tools/perf/builtin-sched.c
index 0c7d599fa555..82ee0dfd1831 100644
--- a/tools/perf/builtin-sched.c
+++ b/tools/perf/builtin-sched.c
@@ -2575,7 +2575,8 @@ static int timehist_sched_change_event(struct perf_tool
*tool,
}
if (!sched->idle_hist || thread->tid == 0) {
- timehist_update_runtime_stats(tr, t, tprev);
+ if (!cpu_list || test_bit(sample->cpu, cpu_bitmap))
+ timehist_update_runtime_stats(tr, t, tprev);
if (sched->idle_hist) {
struct idle_thread_runtime *itr = (void *)tr;
@@ -2848,6 +2849,9 @@ static void timehist_print_summary(struct perf_sched
*sched,
printf("\nIdle stats:\n");
for (i = 0; i < idle_max_cpu; ++i) {
+ if (!test_bit(i, cpu_bitmap))
+ continue;
+
t = idle_threads[i];
if (!t)
continue;
--
2.17.1
[PATCH 1/2] perf sched: Prefer sched_waking event when it exists
Commit fbd705a0c618 ("sched: Introduce the 'trace_sched_waking' tracepoint")
added sched_waking tracepoint which should be preferred over sched_wakeup
when analyzing scheduling delays.
Update 'perf sched record' to collect sched_waking events if it exists
and fallback to sched_wakeup if it does not. Similarly, update timehist
command to skip sched_wakeup events if the session includes
sched_waking (ie., sched_waking is preferred over sched_wakeup).
Signed-off-by: David Ahern
---
tools/perf/builtin-sched.c | 32 +---
1 file changed, 29 insertions(+), 3 deletions(-)
diff --git a/tools/perf/builtin-sched.c b/tools/perf/builtin-sched.c
index 459e4229945e..0c7d599fa555 100644
--- a/tools/perf/builtin-sched.c
+++ b/tools/perf/builtin-sched.c
@@ -2398,6 +2398,15 @@ static void timehist_print_wakeup_event(struct
perf_sched *sched,
printf("\n");
}
+static int timehist_sched_wakeup_ignore(struct perf_tool *tool __maybe_unused,
+ union perf_event *event __maybe_unused,
+ struct evsel *evsel __maybe_unused,
+ struct perf_sample *sample
__maybe_unused,
+ struct machine *machine __maybe_unused)
+{
+ return 0;
+}
+
static int timehist_sched_wakeup_event(struct perf_tool *tool,
union perf_event *event __maybe_unused,
struct evsel *evsel,
@@ -2958,9 +2967,10 @@ static int timehist_check_attr(struct perf_sched *sched,
static int perf_sched__timehist(struct perf_sched *sched)
{
- const struct evsel_str_handler handlers[] = {
+ struct evsel_str_handler handlers[] = {
{ "sched:sched_switch", timehist_sched_switch_event, },
{ "sched:sched_wakeup", timehist_sched_wakeup_event, },
+ { "sched:sched_waking", timehist_sched_wakeup_event, },
{ "sched:sched_wakeup_new", timehist_sched_wakeup_event, },
};
const struct evsel_str_handler migrate_handlers[] = {
@@ -3018,6 +3028,11 @@ static int perf_sched__timehist(struct perf_sched *sched)
setup_pager();
+ /* prefer sched_waking if it is captured */
+ if (perf_evlist__find_tracepoint_by_name(session->evlist,
+ "sched:sched_waking"))
+ handlers[1].handler = timehist_sched_wakeup_ignore;
+
/* setup per-evsel handlers */
if (perf_session__set_tracepoints_handlers(session, handlers))
goto out;
@@ -3330,12 +3345,16 @@ static int __cmd_record(int argc, const char **argv)
"-e", "sched:sched_stat_iowait",
"-e", "sched:sched_stat_runtime",
"-e", "sched:sched_process_fork",
- "-e", "sched:sched_wakeup",
"-e", "sched:sched_wakeup_new",
"-e", "sched:sched_migrate_task",
};
+ struct tep_event *waking_event;
- rec_argc = ARRAY_SIZE(record_args) + argc - 1;
+ /*
+* +2 for either "-e", "sched:sched_wakeup" or
+* "-e", "sched:sched_waking"
+*/
+ rec_argc = ARRAY_SIZE(record_args) + 2 + argc - 1;
rec_argv = calloc(rec_argc + 1, sizeof(char *));
if (rec_argv == NULL)
@@ -3344,6 +3363,13 @@ static int __cmd_record(int argc, const char **argv)
for (i = 0; i < ARRAY_SIZE(record_args); i++)
rec_argv[i] = strdup(record_args[i]);
+ rec_argv[i++] = "-e";
+ waking_event = trace_event__tp_format("sched", "sched_waking");
+ if (!IS_ERR(waking_event))
+ rec_argv[i++] = strdup("sched:sched_waking");
+ else
+ rec_argv[i++] = strdup("sched:sched_wakeup");
+
for (j = 1; j < (unsigned int)argc; j++, i++)
rec_argv[i] = argv[j];
--
2.17.1
Re: [PATCH v2] mm, dump_page: do not crash with bad compound_mapcount()
On Fri, Aug 07, 2020 at 04:10:29PM +0100, Matthew Wilcox wrote:
> On Fri, Aug 07, 2020 at 05:35:04PM +0300, Kirill A. Shutemov wrote:
> > On Tue, Aug 04, 2020 at 02:48:07PM -0700, John Hubbard wrote:
> > > If a compound page is being split while dump_page() is being run on that
> > > page, we can end up calling compound_mapcount() on a page that is no
> > > longer compound. This leads to a crash (already seen at least once in
> > > the field), due to the VM_BUG_ON_PAGE() assertion inside
> > > compound_mapcount().
>
> [...]
> > > +static inline int head_mapcount(struct page *head)
> > > +{
> >
> > Do we want VM_BUG_ON_PAGE(!PageHead(head), head) here?
>
> Well, no. That was the point of the bug report -- by the time we called
> compound_mapcount, the page was no longer a head page.
Right. VM_BUG_ON_PAGE(PageTail(head), head)?
> > > A similar problem is possible, via compound_pincount() instead of
> > > compound_mapcount().
> > >
> > > In order to avoid this kind of crash, make dump_page() slightly more
> > > robust, by providing a pair of simpler routines that don't contain
> > > assertions: head_mapcount() and head_pincount().
> >
> > I find naming misleading. head_mapcount() and head_pincount() sounds like
> > a mapcount/pincount of the head page, but it's not. It's mapcount and
> > pincount of the compound page.
>
> OK, point taken. I might go for head_compound_mapcount()? Or as I
> originally suggested, just opencoding it like we do in __page_mapcount().
I'm fine either way.
--
Kirill A. Shutemov
Re: [PATCH RFC v2 02/18] irq/dev-msi: Add support for a new DEV_MSI irq domain
Jason Gunthorpe writes: > Though it is more of a rational and a cookbook on how to combine > existing technology pieces. (eg PASID, platform_msi, etc) > > The basic approach of SIOV's IMS is that there is no longer a generic > interrupt indirection from numbers to addr/data pairs like > IOAPIC/MSI/MSI-X owned by the common OS code. > > Instead the driver itself is responsible to set the addr/data pair > into the device in a device specific way, deal with masking, etc. > > This lets the device use an implementation that is not limited by the > harsh MSI-X semantics. > > In Linux we already have 'IMS' it is called platform_msi and a few > embedded drivers already work like this. The idea here is to bring it > to PCI. platform_msi as it exists today is a crutch and in hindsight I should have payed more attention back then and shoot it down before it got merged. IMS can be somehow mapped to platform MSI but the proposed approach to extend platform MSI with the extra bolts for IMS (valid for one particular incarnation) is just going into the wrong direction. We've been there and the main reason why hierarchical irq domains exist is that we needed to make a clear cut between the involved hardware pieces and their drivers. The pre hierarchy model was a maze of stuff calling back and forth between layers with lots of duct tape added to make it "work". This finally fell apart when Intel tried to support I/O-APIC hotplug. The ARM people had similar issues with all the special irq related SoC specific IP blocks which are placed between the CPU level interrupt controller and the device. The hierarchy strictly seperates the per layer resource management and each layer can work mostly independent of the actual available parent layer. Now looking at IMS. It's a subsystem inside a physical device. It has slot management (where to place the Message) and mask/unmask. Resource management at that level is what irq domains are for and mask/unmask is what a irq chip handles. So the right thing to do is to create shared infrastructure which is utilized by the device drivers by providing a few bog standard data structures and the handful of device specific domain and irq functions. That keeps the functionality common, but avoids that we end up with - msi_desc becoming a dump ground for random driver data - a zoo of platform callbacks - glued on driver specific resource management and all the great hacks which it requires to work on hundreds of different devices which all implement IMS differently. I'm all for sharing code and making the life of driver writers simple because that makes my life simple as well, but not by creating a layer at the wrong level and then hacking it into submission until it finally collapses. Designing the infrastructure following the clear layering rules of hierarchical domains so it works for IMS and also replaces the platform MSI hack is the only sane way to go forward, not the other way round. Thanks, tglx
Re: [RFC PATCH v2 6/6] sched/fair: Implement starvation monitor
On 8/7/20 4:11 PM, pet...@infradead.org wrote: > But I shelved all that after I heard about that other balancer idea > Danial was suppose to be working on ;-))) The PhD bureaucracy (and behind the scenes) were blocking me... but I am free man now and will catch up on that ;-). [ also because I made enough progress on this: https://github.com/bristot/rtsl/ and can start other things. ] -- Daniel
BUG: corrupted list in kobject_add_internal
Hello,
syzbot found the following issue on:
HEAD commit:5a30a789 Merge tag 'x86-urgent-2020-08-02' of git://git.ke..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=1660c85890
kernel config: https://syzkaller.appspot.com/x/.config?x=c0cfcf935bcc94d2
dashboard link: https://syzkaller.appspot.com/bug?extid=dd768a260f7358adbaf9
compiler: gcc (GCC) 10.1.0-syz 20200507
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=14b73afc90
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=124893a490
The issue was bisected to:
commit 4f40afc6c76451daff7d0dcfc8a3d113ccf65bfc
Author: Abhishek Pandit-Subedi
Date: Wed Mar 11 15:54:01 2020 +
Bluetooth: Handle BR/EDR devices during suspend
bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=11cb1e0a90
final oops: https://syzkaller.appspot.com/x/report.txt?x=13cb1e0a90
console output: https://syzkaller.appspot.com/x/log.txt?x=15cb1e0a90
IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+dd768a260f7358adb...@syzkaller.appspotmail.com
Fixes: 4f40afc6c764 ("Bluetooth: Handle BR/EDR devices during suspend")
debugfs: Directory '200' with parent 'hci0' already present!
list_add double add: new=88808e9b6418, prev=88808e9b6418,
next=8880a973ef00.
[ cut here ]
kernel BUG at lib/list_debug.c:29!
invalid opcode: [#1] PREEMPT SMP KASAN
CPU: 1 PID: 6882 Comm: kworker/u5:1 Not tainted 5.8.0-rc7-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google
01/01/2011
Workqueue: hci0 hci_rx_work
RIP: 0010:__list_add_valid.cold+0x26/0x3c lib/list_debug.c:29
Code: 57 ff ff ff 4c 89 e1 48 c7 c7 20 92 93 88 e8 b1 f1 c1 fd 0f 0b 48 89 f2
4c 89 e1 48 89 ee 48 c7 c7 60 93 93 88 e8 9a f1 c1 fd <0f> 0b 48 89 f1 48 c7 c7
e0 92 93 88 4c 89 e6 e8 86 f1 c1 fd 0f 0b
RSP: 0018:c90001777830 EFLAGS: 00010282
RAX: 0058 RBX: 8880a973ef00 RCX:
RDX: 888094f1c200 RSI: 815d4ef7 RDI: f520002eeef8
RBP: 88808e9b6418 R08: 0058 R09: 8880ae7318e7
R10: R11: R12: 8880a973ef00
R13: 888087315270 R14: 88808e9b6430 R15: 88808e9b6418
FS: () GS:8880ae70() knlGS:
CS: 0010 DS: ES: CR0: 80050033
CR2: 7ffdcd6db747 CR3: 9ba09000 CR4: 001406e0
DR0: DR1: DR2:
DR3: DR6: fffe0ff0 DR7: 0400
Call Trace:
__list_add include/linux/list.h:67 [inline]
list_add_tail include/linux/list.h:100 [inline]
kobj_kset_join lib/kobject.c:196 [inline]
kobject_add_internal+0x18d/0x940 lib/kobject.c:246
kobject_add_varg lib/kobject.c:390 [inline]
kobject_add+0x150/0x1c0 lib/kobject.c:442
device_add+0x35a/0x1be0 drivers/base/core.c:2633
hci_conn_add_sysfs+0x84/0xe0 net/bluetooth/hci_sysfs.c:53
hci_conn_complete_evt net/bluetooth/hci_event.c:2607 [inline]
hci_event_packet+0xe0b/0x86f5 net/bluetooth/hci_event.c:6033
hci_rx_work+0x22e/0xb10 net/bluetooth/hci_core.c:4705
process_one_work+0x94c/0x1670 kernel/workqueue.c:2269
worker_thread+0x64c/0x1120 kernel/workqueue.c:2415
kthread+0x3b5/0x4a0 kernel/kthread.c:291
ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:293
Modules linked in:
---[ end trace b1bcc552c32d25e9 ]---
RIP: 0010:__list_add_valid.cold+0x26/0x3c lib/list_debug.c:29
Code: 57 ff ff ff 4c 89 e1 48 c7 c7 20 92 93 88 e8 b1 f1 c1 fd 0f 0b 48 89 f2
4c 89 e1 48 89 ee 48 c7 c7 60 93 93 88 e8 9a f1 c1 fd <0f> 0b 48 89 f1 48 c7 c7
e0 92 93 88 4c 89 e6 e8 86 f1 c1 fd 0f 0b
RSP: 0018:c90001777830 EFLAGS: 00010282
RAX: 0058 RBX: 8880a973ef00 RCX:
RDX: 888094f1c200 RSI: 815d4ef7 RDI: f520002eeef8
RBP: 88808e9b6418 R08: 0058 R09: 8880ae7318e7
R10: R11: R12: 8880a973ef00
R13: 888087315270 R14: 88808e9b6430 R15: 88808e9b6418
FS: () GS:8880ae70() knlGS:
CS: 0010 DS: ES: CR0: 80050033
CR2: 7ffdcd6db747 CR3: 09a79000 CR4: 001406e0
DR0: DR1: DR2:
DR3: DR6: fffe0ff0 DR7: 0400
---
This report is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkal...@googlegroups.com.
syzbot will keep track of this issue. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
For information about bisection process see: https://goo.gl/tpsmEJ#bisection
syzbot can test patches for this issue, for details see:
https://goo.gl/tpsmEJ#testing-patches
Re: [PATCH 00/13] MIPS: Convert Ingenic to a generic board
Hi Zhou,
Le sam. 8 août 2020 à 0:23, Zhou Yanjie a
écrit :
Hi Paul,
I'm not too sure if remove "cpu-feature-overrides.h" will cause some
problems for X2000, because according to my current test on X2000, I
found that it is somewhat different from the SoCs using XBurst1 CPU
core, with the kernel source code provided by Ingenic, for example,
we must configure "#define cpu_has_tlbinv 1" in
"cpu-feature-overrides.h" to make the X2000 work normally, otherwise
the kernel will get stuck. And X2000's interrupt controller has also
been redesigned. If these differences make it impossible to share
code, should we set a subdirectory of "xburst" and "xburst2" in
"arch/mips/ingenic"? (I am just worried about this situation, so far
I have not been able to successfully run the mainline kernel on
X2000).
The is kind of a hack, to hardcode settings
in case the CPU is not properly detected. The cpu-probe.c should be
able to auto-detect these settings, including the inverted TLB that the
X2000 has, reading from the CPU config registers ("TLB INV" info should
be in config4). Right now cpu_probe_ingenic() doesn't read config4 (not
present on older SoCs) but that's trivial to add.
As for your other question, I don't see any reason why we wouldn't be
able to support the X2000 aside the others in a generic kernel, so
don't worry :)
Cheers,
-Paul
I have added some related engineers from Ingenic to CC
Thanks and best regards!
在 2020/8/4 上午1:01, Paul Cercueil 写道:
Hi Thomas & list,
Here is a set of patches for 5.10 (no rush) to move Ingenic support
from
arch/mips/jz4740/ to arch/mips/generic/.
There are some Kconfig changes that I think should be reviewed in
detail
to avoid breakages elsewhere. The idea behind these changes is to
allow
the Ingenic "generic" code to be built in a non-generic kernel, since
generic kernels bring lots of dependencies which result in a +7% size
increase.
Support for booting the generic kernel with a built-in and/or
appended
devicetree, as well as support for compressed (vmlinuz) kernels, has
been added as well.
Cheers,
-Paul
Paul Cercueil (13):
MIPS: cpu-probe: Set Ingenic's writecombine to _CACHE_CACHABLE_WA
MIPS: cpu-probe: Mark XBurst CPU as having vtagged caches
MIPS: cpu-probe: ingenic: Fix broken BUG_ON
MIPS: Kconfig: add MIPS_GENERIC_KERNEL symbol
MIPS: machine: Add get_system_type callback
MIPS: generic: Call the machine's .get_system_type callback if
provided
MIPS: generic: Support booting with built-in or appended DTB
MIPS: generic: Add support for zboot
MIPS: generic: Increase NR_IRQS to 256
MIPS: generic: Add support for Ingenic SoCs
MIPS: jz4740: Drop folder
MIPS: configs: Regenerate configs of Ingenic boards
MAINTAINERS: Update paths to Ingenic platform code
MAINTAINERS | 4 +-
arch/mips/Kbuild.platforms| 1 -
arch/mips/Kconfig | 43 --
arch/mips/configs/ci20_defconfig | 4 +-
arch/mips/configs/cu1000-neo_defconfig| 16 +-
arch/mips/configs/gcw0_defconfig | 2 +-
arch/mips/configs/qi_lb60_defconfig | 5 +-
arch/mips/configs/rs90_defconfig | 4 +-
arch/mips/generic/Kconfig | 8 +-
arch/mips/generic/Makefile| 2 +-
arch/mips/generic/Platform| 1 +
arch/mips/generic/board-ingenic.c | 108 +
arch/mips/generic/init.c | 28 +++-
arch/mips/generic/proc.c | 25 ---
arch/mips/include/asm/mach-generic/irq.h | 2 +-
.../asm/mach-jz4740/cpu-feature-overrides.h | 50 --
arch/mips/include/asm/mach-jz4740/irq.h | 13 --
arch/mips/include/asm/machine.h | 1 +
arch/mips/include/asm/pgtable-bits.h | 5 -
arch/mips/{jz4740 => ingenic}/Kconfig | 16 +-
arch/mips/jz4740/Makefile | 9 --
arch/mips/jz4740/Platform | 3 -
arch/mips/jz4740/setup.c | 145
--
arch/mips/kernel/cpu-probe.c | 8 +-
24 files changed, 198 insertions(+), 305 deletions(-)
create mode 100644 arch/mips/generic/board-ingenic.c
delete mode 100644 arch/mips/generic/proc.c
delete mode 100644
arch/mips/include/asm/mach-jz4740/cpu-feature-overrides.h
delete mode 100644 arch/mips/include/asm/mach-jz4740/irq.h
rename arch/mips/{jz4740 => ingenic}/Kconfig (91%)
delete mode 100644 arch/mips/jz4740/Makefile
delete mode 100644 arch/mips/jz4740/Platform
delete mode 100644 arch/mips/jz4740/setup.c
Re: [dm-devel] [RFC PATCH v5 00/11] Integrity Policy Enforcement LSM (IPE)
On Thu, 6 Aug 2020, Mimi Zohar wrote: > On Thu, 2020-08-06 at 09:51 +1000, James Morris wrote: > > On Wed, 5 Aug 2020, Mimi Zohar wrote: > > > > > If block layer integrity was enough, there wouldn't have been a need > > > for fs-verity. Even fs-verity is limited to read only filesystems, > > > which makes validating file integrity so much easier. From the > > > beginning, we've said that fs-verity signatures should be included in > > > the measurement list. (I thought someone signed on to add that support > > > to IMA, but have not yet seen anything.) > > > > > > Going forward I see a lot of what we've accomplished being incorporated > > > into the filesystems. When IMA will be limited to defining a system > > > wide policy, I'll have completed my job. > > > > What are your thoughts on IPE being a standalone LSM? Would you prefer to > > see its functionality integrated into IMA? > > Improving the integrity subsystem would be preferred. > Are you planning to attend Plumbers? Perhaps we could propose a BoF session on this topic. -- James Morris
Re: [PATCH] drm/panfrost: perfcnt: fix ref count leak in panfrost_perfcnt_enable_locked
On Sun, Jun 14, 2020 at 12:36 AM Navid Emamdoost wrote: > > in panfrost_perfcnt_enable_locked, pm_runtime_get_sync is called which > increments the counter even in case of failure, leading to incorrect > ref count. In case of failure, decrement the ref count before returning. > > Signed-off-by: Navid Emamdoost > --- > drivers/gpu/drm/panfrost/panfrost_perfcnt.c | 10 +++--- > 1 file changed, 7 insertions(+), 3 deletions(-) Applied. Rob
Re: [PATCH] i2c: iproc: fix race between client unreg and isr
Hi Rayagonda/Dhananjay, On 8/5/2020 2:17 AM, Wolfram Sang wrote: > On Mon, Jul 27, 2020 at 01:43:40PM -0700, Ray Jui wrote: >> >> >> On 7/27/2020 1:26 PM, Wolfram Sang wrote: >>> On Mon, Jul 27, 2020 at 08:13:46PM +0200, Wolfram Sang wrote: > Can you confirm that even if we have irq pending at the i2c IP core > level, as long as we execute Step 2. below (to disable/mask all slave > interrupts), after 'enable_irq' is called, we still will not receive any > further i2c slave interrupt? This is HW dependant. From my tests with Renesas HW, this is not the case. But the actual error case was impossible to trigger for me, so far. I might try again later. But even in the worst case, I would only get a "spurious interrupt" and not an NULL-ptr OOPS. >>> >>> Let me explain how I verified this: >>> >>> 0) add a debug print whenever the slave irq part is called >>> >>> 1) Put a 2 second delay after disable_irq() and before clearing >>> interrupt enable register >>> >>> 2) unbind the slave driver in the background, triggering the 2s delay >>> >>> 3) during the delay, try to read from the to-be-unbound slave in the >>>foreground >>> >>> 4) ensure there is no prinout from the slave irq >>> >>> Worked fine for me with the Renesas R-Car I2C IP interface. As mentioned >>> before, I couldn't trigger a bad case with my setup. So, I hope this new >>> fix will work for Rayagonda's test case, too! >>> >> >> Sure. I suggest Dhananjay gives the sequence you proposed here a try >> (with delay added during the testing to widen the window to cover corner >> cases). If it works, we can just go with your proposed sequence here. > > Any progress yet? > I don't know if Dhananjay is actively working on this or not. Rayagonda, given that you have the I2C slave setup already, do you think you can help to to test and above sequence from Wolfram (by using the widened delay window as instructed)? Thanks, Ray
Re: [PATCH v4 00/10] Function Granular KASLR
On Tue, 2020-08-04 at 14:23 -0400, Joe Lawrence wrote: > On Fri, Jul 17, 2020 at 09:59:57AM -0700, Kristen Carlson Accardi > wrote: > > Function Granular Kernel Address Space Layout Randomization > > (fgkaslr) > > - > > > > > > This patch set is an implementation of finer grained kernel address > > space > > randomization. It rearranges your kernel code at load time > > on a per-function level granularity, with only around a second > > added to > > boot time. > > > > Changes in v4: > > - > > * dropped the patch to split out change to STATIC definition in > > x86/boot/compressed/misc.c and replaced with a patch authored > > by Kees Cook to avoid the duplicate malloc definitions > > * Added a section to Documentation/admin-guide/kernel- > > parameters.txt > > to document the fgkaslr boot option. > > * redesigned the patch to hide the new layout when reading > > /proc/kallsyms. The previous implementation utilized a > > dynamically > > allocated linked list to display the kernel and module symbols > > in alphabetical order. The new implementation uses a randomly > > shuffled index array to display the kernel and module symbols > > in a random order. > > > > Changes in v3: > > - > > * Makefile changes to accommodate > > CONFIG_LD_DEAD_CODE_DATA_ELIMINATION > > * removal of extraneous ALIGN_PAGE from _etext changes > > * changed variable names in x86/tools/relocs to be less confusing > > * split out change to STATIC definition in > > x86/boot/compressed/misc.c > > * Updates to Documentation to make it more clear what is preserved > > in .text > > * much more detailed commit message for function granular KASLR > > patch > > * minor tweaks and changes that make for more readable code > > * this cover letter updated slightly to add additional details > > > > Changes in v2: > > -- > > * Fix to address i386 build failure > > * Allow module reordering patch to be configured separately so that > > arm (or other non-x86_64 arches) can take advantage of module > > function > > reordering. This support has not be tested by me, but smoke > > tested by > > Ard Biesheuvel on arm. > > * Fix build issue when building on arm as reported by > > Ard Biesheuvel > > > > Patches to objtool are included because they are dependencies for > > this > > patchset, however they have been submitted by their maintainer > > separately. > > > > Background > > -- > > KASLR was merged into the kernel with the objective of increasing > > the > > difficulty of code reuse attacks. Code reuse attacks reused > > existing code > > snippets to get around existing memory protections. They exploit > > software bugs > > which expose addresses of useful code snippets to control the flow > > of > > execution for their own nefarious purposes. KASLR moves the entire > > kernel > > code text as a unit at boot time in order to make addresses less > > predictable. > > The order of the code within the segment is unchanged - only the > > base address > > is shifted. There are a few shortcomings to this algorithm. > > > > 1. Low Entropy - there are only so many locations the kernel can > > fit in. This > >means an attacker could guess without too much trouble. > > 2. Knowledge of a single address can reveal the offset of the base > > address, > >exposing all other locations for a published/known kernel image. > > 3. Info leaks abound. > > > > Finer grained ASLR has been proposed as a way to make ASLR more > > resistant > > to info leaks. It is not a new concept at all, and there are many > > variations > > possible. Function reordering is an implementation of finer grained > > ASLR > > which randomizes the layout of an address space on a function level > > granularity. We use the term "fgkaslr" in this document to refer to > > the > > technique of function reordering when used with KASLR, as well as > > finer grained > > KASLR in general. > > > > Proposed Improvement > > > > This patch set proposes adding function reordering on top of the > > existing > > KASLR base address randomization. The over-arching objective is > > incremental > > improvement over what we already have. It is designed to work in > > combination > > with the existing solution. The implementation is really pretty > > simple, and > > there are 2 main area where changes occur: > > > > * Build time > > > > GCC has had an option to place functions into individual .text > > sections for > > many years now. This option can be used to implement function > > reordering at > > load time. The final compiled vmlinux retains all the section > > headers, which > > can be used to help find the address ranges of each function. Using > > this > > information and an expanded table of relocation addresses, > > individual text > > sections can be suffled immediately after decompression. Some data > > tables > > inside the kernel that
AW: AW: [PATCH 5/5] Add manpage for fsconfig(2)
found it, next i will look for version not varsion Von: David Howells [dhowe...@redhat.com] Gesendet: Freitag, 7. August 2020 18:27 An: Walter Harms Cc: dhowe...@redhat.com; mtk.manpa...@gmail.com; linux-fsde...@vger.kernel.org; christian.brau...@ubuntu.com; linux-...@vger.kernel.org; linux-...@vger.kernel.org; linux-kernel@vger.kernel.org Betreff: Re: AW: [PATCH 5/5] Add manpage for fsconfig(2) Walter Harms wrote: > maybe it is obvious but i did not see it .. > starting with what kernel version are these features available ? See: +.SH VERSIONS +.BR fsconfig () +was added to Linux in kernel 5.1. David
Re: [PATCH v5 00/14] Add regulator devfreq support to Panfrost
On Fri, 7 Aug 2020 at 18:28, Clément Péron wrote: > > Hi Rob, > > On Fri, 7 Aug 2020 at 18:13, Rob Herring wrote: > > > > On Fri, Jul 10, 2020 at 3:54 AM Clément Péron wrote: > > > > > > Hi, > > > > > > This serie cleans and adds regulator support to Panfrost devfreq. > > > This is mostly based on comment for the freshly introduced lima > > > devfreq. > > > > > > We need to add regulator support because on Allwinner the GPU OPP > > > table defines both frequencies and voltages. > > > > > > First patches [01-07] should not change the actual behavior > > > and introduce a proper panfrost_devfreq struct. > > > > > > Regards, > > > Clément > > > > > > Changes since v4: > > > - Fix missed a pfdev to &pfdev->devfreq during rebase > > > > > > Changes since v3: > > > - Collect Steven Price reviewed-by tags > > > - Rebase on next/master (next-20200709) > > > > > > Changes since v2: > > > - Collect Alyssa Rosenzweig reviewed-by tags > > > - Fix opp_set_regulator before adding opp_table (introduce in v2) > > > - Call err_fini in case opp_add_table failed > > > > > > Changes since v1: > > > - Collect Steven Price reviewed-by tags > > > - Fix spinlock comment > > > - Drop OPP clock-name patch > > > - Drop device_property_test patch > > > - Add rename error labels patch > > > > > > Clément Péron (14): > > > drm/panfrost: avoid static declaration > > > drm/panfrost: clean headers in devfreq > > > drm/panfrost: don't use pfdevfreq.busy_count to know if hw is idle > > > drm/panfrost: introduce panfrost_devfreq struct > > > drm/panfrost: use spinlock instead of atomic > > > drm/panfrost: properly handle error in probe > > > drm/panfrost: rename error labels in device_init > > > drm/panfrost: move devfreq_init()/fini() in device > > > drm/panfrost: dynamically alloc regulators > > > drm/panfrost: add regulators to devfreq > > > arm64: defconfig: Enable devfreq cooling device > > > arm64: dts: allwinner: h6: Add cooling map for GPU > > > [DO NOT MERGE] arm64: dts: allwinner: h6: Add GPU OPP table > > > [DO NOT MERGE] arm64: dts: allwinner: force GPU regulator to be always > > > > Patches 1-10 applied to drm-misc. > > This serie has been superseded by v5. > > Could you apply the v5 instead. Oups forget my email I got an issue with my gmail... Thanks > > Thanks > Clément > > > > > Rob
[PATCH v3] hwmon/pmbus: use simple i2c probe function
pmbus_do_probe doesn't use the id information provided in its second
argument, so this can be removed, which then allows using the
single-parameter i2c probe function ("probe_new") for probes.
This avoids scanning the identifier tables during probes.
Drivers which didn't use the id are converted as-is; drivers which did
are modified as follows:
* if the information in i2c_client is sufficient, that's used instead
(client->name);
* configured v. probed comparisons are performed by comparing the
configured name to the detected name, instead of the ids; this
involves strcmp but is still cheaper than comparing all the device
names when scanning the tables;
* anything else is handled by calling i2c_match_id() with the same
level of error-handling (if any) as before.
Signed-off-by: Stephen Kitt
---
Changes since v1:
- i2c_device_id declarations are left unchanged;
- all drivers are converted, using client info or i2c_match_id().
Changes since v2:
- updated the documentation;
- fixed unbalanced braces around the modified else in ibm-cffps.c.
Documentation/hwmon/pmbus-core.rst | 3 +--
Documentation/hwmon/pmbus.rst | 7 +++
drivers/hwmon/pmbus/adm1275.c | 11 +--
drivers/hwmon/pmbus/bel-pfe.c | 11 ++-
drivers/hwmon/pmbus/ibm-cffps.c| 19 ---
drivers/hwmon/pmbus/inspur-ipsps.c | 7 +++
drivers/hwmon/pmbus/ir35221.c | 7 +++
drivers/hwmon/pmbus/ir38064.c | 7 +++
drivers/hwmon/pmbus/irps5401.c | 7 +++
drivers/hwmon/pmbus/isl68137.c | 11 ++-
drivers/hwmon/pmbus/lm25066.c | 11 ++-
drivers/hwmon/pmbus/ltc2978.c | 11 +--
drivers/hwmon/pmbus/ltc3815.c | 7 +++
drivers/hwmon/pmbus/max16064.c | 7 +++
drivers/hwmon/pmbus/max16601.c | 7 +++
drivers/hwmon/pmbus/max20730.c | 11 ++-
drivers/hwmon/pmbus/max20751.c | 7 +++
drivers/hwmon/pmbus/max31785.c | 9 -
drivers/hwmon/pmbus/max34440.c | 13 +++--
drivers/hwmon/pmbus/max8688.c | 7 +++
drivers/hwmon/pmbus/pmbus.c| 11 ++-
drivers/hwmon/pmbus/pmbus.h| 3 +--
drivers/hwmon/pmbus/pmbus_core.c | 3 +--
drivers/hwmon/pmbus/pxe1610.c | 7 +++
drivers/hwmon/pmbus/tps40422.c | 7 +++
drivers/hwmon/pmbus/tps53679.c | 11 ++-
drivers/hwmon/pmbus/ucd9000.c | 13 ++---
drivers/hwmon/pmbus/ucd9200.c | 13 ++---
drivers/hwmon/pmbus/xdpe12284.c| 7 +++
drivers/hwmon/pmbus/zl6100.c | 11 +--
30 files changed, 128 insertions(+), 138 deletions(-)
diff --git a/Documentation/hwmon/pmbus-core.rst
b/Documentation/hwmon/pmbus-core.rst
index 501b37b0610d..e22c4f6808bc 100644
--- a/Documentation/hwmon/pmbus-core.rst
+++ b/Documentation/hwmon/pmbus-core.rst
@@ -270,8 +270,7 @@ obtain the chip status. Therefore, it must _not_ be called
from that function.
::
- int pmbus_do_probe(struct i2c_client *client, const struct i2c_device_id *id,
-struct pmbus_driver_info *info);
+ int pmbus_do_probe(struct i2c_client *client, struct pmbus_driver_info
*info);
Execute probe function. Similar to standard probe function for other drivers,
with the pointer to struct pmbus_driver_info as additional argument. Calls
diff --git a/Documentation/hwmon/pmbus.rst b/Documentation/hwmon/pmbus.rst
index 2658ddee70eb..1f31317fe186 100644
--- a/Documentation/hwmon/pmbus.rst
+++ b/Documentation/hwmon/pmbus.rst
@@ -143,10 +143,9 @@ Emerson DS1200 power modules might look as follows::
| PMBUS_HAVE_FAN12 | PMBUS_HAVE_STATUS_FAN12,
};
- static int ds1200_probe(struct i2c_client *client,
- const struct i2c_device_id *id)
+ static int ds1200_probe(struct i2c_client *client)
{
- return pmbus_do_probe(client, id, &ds1200_info);
+ return pmbus_do_probe(client, &ds1200_info);
}
static int ds1200_remove(struct i2c_client *client)
@@ -166,7 +165,7 @@ Emerson DS1200 power modules might look as follows::
.driver = {
.name = "ds1200",
},
- .probe = ds1200_probe,
+ .probe_new = ds1200_probe,
.remove = ds1200_remove,
.id_table = ds1200_id,
};
diff --git a/drivers/hwmon/pmbus/adm1275.c b/drivers/hwmon/pmbus/adm1275.c
index 19317575d1c6..7fc3a3b1b55c 100644
--- a/drivers/hwmon/pmbus/adm1275.c
+++ b/drivers/hwmon/pmbus/adm1275.c
@@ -462,8 +462,7 @@ static const struct i2c_device_id adm1275_id[] = {
};
MODULE_DEVICE_TABLE(i2c, adm1275_id);
-static int adm1275_probe(struct i2c_client *client,
-const struct i2c_device_id *id)
+static int adm1275_probe(struct i2c_client *client)
{
s32 (*config_read_fn)(const struct i2c_client *client, u8 reg);
u8 block_buffer[I2C_SMBUS_BLOCK_MAX + 1];
@@ -506,10 +505,10 @@ static int adm1275_probe(struct i2c_client *client,
retur
Re: [PATCH v5 00/14] Add regulator devfreq support to Panfrost
Hi Rob, On Fri, 7 Aug 2020 at 18:13, Rob Herring wrote: > > On Fri, Jul 10, 2020 at 3:54 AM Clément Péron wrote: > > > > Hi, > > > > This serie cleans and adds regulator support to Panfrost devfreq. > > This is mostly based on comment for the freshly introduced lima > > devfreq. > > > > We need to add regulator support because on Allwinner the GPU OPP > > table defines both frequencies and voltages. > > > > First patches [01-07] should not change the actual behavior > > and introduce a proper panfrost_devfreq struct. > > > > Regards, > > Clément > > > > Changes since v4: > > - Fix missed a pfdev to &pfdev->devfreq during rebase > > > > Changes since v3: > > - Collect Steven Price reviewed-by tags > > - Rebase on next/master (next-20200709) > > > > Changes since v2: > > - Collect Alyssa Rosenzweig reviewed-by tags > > - Fix opp_set_regulator before adding opp_table (introduce in v2) > > - Call err_fini in case opp_add_table failed > > > > Changes since v1: > > - Collect Steven Price reviewed-by tags > > - Fix spinlock comment > > - Drop OPP clock-name patch > > - Drop device_property_test patch > > - Add rename error labels patch > > > > Clément Péron (14): > > drm/panfrost: avoid static declaration > > drm/panfrost: clean headers in devfreq > > drm/panfrost: don't use pfdevfreq.busy_count to know if hw is idle > > drm/panfrost: introduce panfrost_devfreq struct > > drm/panfrost: use spinlock instead of atomic > > drm/panfrost: properly handle error in probe > > drm/panfrost: rename error labels in device_init > > drm/panfrost: move devfreq_init()/fini() in device > > drm/panfrost: dynamically alloc regulators > > drm/panfrost: add regulators to devfreq > > arm64: defconfig: Enable devfreq cooling device > > arm64: dts: allwinner: h6: Add cooling map for GPU > > [DO NOT MERGE] arm64: dts: allwinner: h6: Add GPU OPP table > > [DO NOT MERGE] arm64: dts: allwinner: force GPU regulator to be always > > Patches 1-10 applied to drm-misc. This serie has been superseded by v5. Could you apply the v5 instead. Thanks Clément > > Rob
Re: AW: [PATCH 5/5] Add manpage for fsconfig(2)
Walter Harms wrote: > maybe it is obvious but i did not see it .. > starting with what kernel version are these features available ? See: +.SH VERSIONS +.BR fsconfig () +was added to Linux in kernel 5.1. David
Re: [Patch v2 4/4] arm64: tegra: Add GPCDMA node in dt
On 06/08/2020 08:30, Rajesh Gumasta wrote:
> Add device tree node for GPCDMA controller on Tegra186 target
> and Tegra194 target.
>
> Signed-off-by: Rajesh Gumasta
> ---
> arch/arm64/boot/dts/nvidia/tegra186-p3310.dtsi | 4 +++
> arch/arm64/boot/dts/nvidia/tegra186.dtsi | 46
> ++
> arch/arm64/boot/dts/nvidia/tegra194.dtsi | 44
> 3 files changed, 94 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/nvidia/tegra186-p3310.dtsi
> b/arch/arm64/boot/dts/nvidia/tegra186-p3310.dtsi
> index 2fcaa2e..56ed8d8 100644
> --- a/arch/arm64/boot/dts/nvidia/tegra186-p3310.dtsi
> +++ b/arch/arm64/boot/dts/nvidia/tegra186-p3310.dtsi
> @@ -54,6 +54,10 @@
> };
> };
>
> + dma@260 {
> + status = "okay";
> + };
> +
> memory-controller@2c0 {
> status = "okay";
> };
> diff --git a/arch/arm64/boot/dts/nvidia/tegra186.dtsi
> b/arch/arm64/boot/dts/nvidia/tegra186.dtsi
> index 58100fb..91bb17e 100644
> --- a/arch/arm64/boot/dts/nvidia/tegra186.dtsi
> +++ b/arch/arm64/boot/dts/nvidia/tegra186.dtsi
> @@ -70,6 +70,52 @@
> snps,rxpbl = <8>;
> };
>
> + gpcdma: dma@260 {
> + compatible = "nvidia,tegra186-gpcdma";
> + reg = <0x0 0x260 0x0 0x21>;
> + resets = <&bpmp TEGRA186_RESET_GPCDMA>;
> + reset-names = "gpcdma";
> + interrupts = ,
> + ,
> + ,
> + ,
> + ,
> + ,
> + ,
> + ,
> + ,
> + ,
> + ,
> + ,
> + ,
> + ,
> + ,
> + ,
> + ,
> + ,
> + ,
> + ,
> + ,
> + ,
> + ,
> + ,
> + ,
> + ,
> + ,
> + ,
> + ,
> + ,
> + ,
> + ,
> + ;
> + #dma-cells = <1>;
> + iommus = <&smmu TEGRA186_SID_GPCDMA_0>;
> + dma-coherent;
> + nvidia,start-dma-channel-index = <1>;
> + dma-channels = <31>;
The above two properties are not mentioned in the dt-binding doc. I
really don't think we want these, especially the first as this is not
describing the h/w.
Jon
--
nvpublic
Re: [Patch v2 2/4] dmaengine: tegra: Add Tegra GPC DMA driver
On 06/08/2020 08:30, Rajesh Gumasta wrote:
> Adding GPC DMA controller driver for Tegra186 and Tegra194. The driver
> supports dma transfers between memory to memory, IO peripheral to memory
> and memory to IO peripheral.
>
> Signed-off-by: Pavan Kunapuli
> Signed-off-by: Rajesh Gumasta
> ---
> drivers/dma/Kconfig | 12 +
> drivers/dma/Makefile|1 +
> drivers/dma/tegra-gpc-dma.c | 1472
> +++
> 3 files changed, 1485 insertions(+)
> create mode 100644 drivers/dma/tegra-gpc-dma.c
> +static void tegra_dma_desc_free(struct virt_dma_desc *vd)
> +{
> + struct tegra_dma_desc *dma_desc = vd_to_tegra_dma_desc(vd);
> + struct tegra_dma_channel *tdc = dma_desc->tdc;
> + unsigned long flags;
> +
> + if (!dma_desc)
> + return;
Personally, I would do this the other way around. If dma_desc is valid
then do the below.
> + raw_spin_lock_irqsave(&tdc->lock, flags);
> + kfree(dma_desc);
> + raw_spin_unlock_irqrestore(&tdc->lock, flags);
> +}
> +
> +static int tegra_dma_slave_config(struct dma_chan *dc,
> + struct dma_slave_config *sconfig)
> +{
> + struct tegra_dma_channel *tdc = to_tegra_dma_chan(dc);
> +
> + if (!list_empty(&tdc->pending_sg_req)) {
> + dev_err(tdc2dev(tdc), "Configuration not allowed\n");
> + return -EBUSY;
> + }
> +
> + memcpy(&tdc->dma_sconfig, sconfig, sizeof(*sconfig));
> + if (tdc->slave_id == -1)
> + tdc->slave_id = sconfig->slave_id;
> + tdc->config_init = true;
> + return 0;
> +}
> +
> +static int tegra_dma_pause(struct tegra_dma_channel *tdc)
> +{
> + u32 val;
> + int ret;
> +
> + tdc_write(tdc, TEGRA_GPCDMA_CHAN_CSRE, TEGRA_GPCDMA_CHAN_CSRE_PAUSE);
> +
> + /* Wait until busy bit is de-asserted */
> + ret = readl_relaxed_poll_timeout_atomic(tdc->tdma->base_addr +
> + tdc->chan_base_offset + TEGRA_GPCDMA_CHAN_STATUS,
> + val,
> + !(val & TEGRA_GPCDMA_STATUS_BUSY),
> + TEGRA_GPCDMA_BURST_COMPLETE_TIME,
> + TEGRA_GPCDMA_BURST_COMPLETION_TIMEOUT);
> +
> + if (ret) {
> + dev_err(tdc2dev(tdc), "DMA pause timed out\n");
> + return ret;
No need to return here.
> + }
> +
> + return ret;
> +}
...
> +static irqreturn_t tegra_dma_isr(int irq, void *dev_id)
> +{
> + struct tegra_dma_channel *tdc = dev_id;
> + unsigned int err_status;
> + unsigned long status;
> +
> + raw_spin_lock(&tdc->lock);
> +
> + status = tdc_read(tdc, TEGRA_GPCDMA_CHAN_STATUS);
> + err_status = tdc_read(tdc, TEGRA_GPCDMA_CHAN_ERR_STATUS);
> +
> + if (err_status) {
> + tegra_dma_chan_decode_error(tdc, err_status);
> + tegra_dma_dump_chan_regs(tdc);
> + tdc_write(tdc, TEGRA_GPCDMA_CHAN_ERR_STATUS, 0x);
> + }
> +
> + if (status & TEGRA_GPCDMA_STATUS_ISE_EOC) {
> + tdc_write(tdc, TEGRA_GPCDMA_CHAN_STATUS,
> + TEGRA_GPCDMA_STATUS_ISE_EOC);
> + if (tdc->isr_handler) {
> + tdc->isr_handler(tdc, false);
> + } else {
> + dev_err(tdc->tdma->dev,
> + "GPCDMA CH%d: status %lx ISR handler absent!\n",
> + tdc->id, status);
> + tegra_dma_dump_chan_regs(tdc);
> + }
> + raw_spin_unlock(&tdc->lock);
> + return IRQ_HANDLED;
It is usually better to init a return value to IRQ_NONE at the beginning
and then update the variable here and just have one return point.
> + }
> +
> + raw_spin_unlock(&tdc->lock);
> + return IRQ_NONE;
> +}
...
> +static inline int get_bus_width(struct tegra_dma_channel *tdc,
> + enum dma_slave_buswidth slave_bw)
> +{
> + switch (slave_bw) {
> + case DMA_SLAVE_BUSWIDTH_1_BYTE:
> + return TEGRA_GPCDMA_MMIOSEQ_BUS_WIDTH_8;
> + case DMA_SLAVE_BUSWIDTH_2_BYTES:
> + return TEGRA_GPCDMA_MMIOSEQ_BUS_WIDTH_16;
> + case DMA_SLAVE_BUSWIDTH_4_BYTES:
> + return TEGRA_GPCDMA_MMIOSEQ_BUS_WIDTH_32;
> + case DMA_SLAVE_BUSWIDTH_8_BYTES:
> + return TEGRA_GPCDMA_MMIOSEQ_BUS_WIDTH_64;
> + default:
> + dev_warn(tdc2dev(tdc),
> + "slave bw is not supported, using 32bits\n");
> + return TEGRA_GPCDMA_MMIOSEQ_BUS_WIDTH_32;
This is an error and so please return an error. I doubtful that there is
any point in trying to continue.
> + }
> +}
> +
> +static inline int get_burst_size(struct tegra_dma_channel *tdc,
> + u32 burst_size,
> + enum dma_slave_buswidth slave_bw,
> + int len)
> +{
> + int burst_mmio_width;
> + int burst_byte;
> +
> + /*
> + * burst
Re: [PATCH 00/13] MIPS: Convert Ingenic to a generic board
Hi Paul,
I'm not too sure if remove "cpu-feature-overrides.h" will cause some
problems for X2000, because according to my current test on X2000, I
found that it is somewhat different from the SoCs using XBurst1 CPU
core, with the kernel source code provided by Ingenic, for example, we
must configure "#define cpu_has_tlbinv 1" in "cpu-feature-overrides.h"
to make the X2000 work normally, otherwise the kernel will get stuck.
And X2000's interrupt controller has also been redesigned. If these
differences make it impossible to share code, should we set a
subdirectory of "xburst" and "xburst2" in "arch/mips/ingenic"? (I am
just worried about this situation, so far I have not been able to
successfully run the mainline kernel on X2000).
I have added some related engineers from Ingenic to CC
Thanks and best regards!
在 2020/8/4 上午1:01, Paul Cercueil 写道:
Hi Thomas & list,
Here is a set of patches for 5.10 (no rush) to move Ingenic support from
arch/mips/jz4740/ to arch/mips/generic/.
There are some Kconfig changes that I think should be reviewed in detail
to avoid breakages elsewhere. The idea behind these changes is to allow
the Ingenic "generic" code to be built in a non-generic kernel, since
generic kernels bring lots of dependencies which result in a +7% size
increase.
Support for booting the generic kernel with a built-in and/or appended
devicetree, as well as support for compressed (vmlinuz) kernels, has
been added as well.
Cheers,
-Paul
Paul Cercueil (13):
MIPS: cpu-probe: Set Ingenic's writecombine to _CACHE_CACHABLE_WA
MIPS: cpu-probe: Mark XBurst CPU as having vtagged caches
MIPS: cpu-probe: ingenic: Fix broken BUG_ON
MIPS: Kconfig: add MIPS_GENERIC_KERNEL symbol
MIPS: machine: Add get_system_type callback
MIPS: generic: Call the machine's .get_system_type callback if
provided
MIPS: generic: Support booting with built-in or appended DTB
MIPS: generic: Add support for zboot
MIPS: generic: Increase NR_IRQS to 256
MIPS: generic: Add support for Ingenic SoCs
MIPS: jz4740: Drop folder
MIPS: configs: Regenerate configs of Ingenic boards
MAINTAINERS: Update paths to Ingenic platform code
MAINTAINERS | 4 +-
arch/mips/Kbuild.platforms| 1 -
arch/mips/Kconfig | 43 --
arch/mips/configs/ci20_defconfig | 4 +-
arch/mips/configs/cu1000-neo_defconfig| 16 +-
arch/mips/configs/gcw0_defconfig | 2 +-
arch/mips/configs/qi_lb60_defconfig | 5 +-
arch/mips/configs/rs90_defconfig | 4 +-
arch/mips/generic/Kconfig | 8 +-
arch/mips/generic/Makefile| 2 +-
arch/mips/generic/Platform| 1 +
arch/mips/generic/board-ingenic.c | 108 +
arch/mips/generic/init.c | 28 +++-
arch/mips/generic/proc.c | 25 ---
arch/mips/include/asm/mach-generic/irq.h | 2 +-
.../asm/mach-jz4740/cpu-feature-overrides.h | 50 --
arch/mips/include/asm/mach-jz4740/irq.h | 13 --
arch/mips/include/asm/machine.h | 1 +
arch/mips/include/asm/pgtable-bits.h | 5 -
arch/mips/{jz4740 => ingenic}/Kconfig | 16 +-
arch/mips/jz4740/Makefile | 9 --
arch/mips/jz4740/Platform | 3 -
arch/mips/jz4740/setup.c | 145 --
arch/mips/kernel/cpu-probe.c | 8 +-
24 files changed, 198 insertions(+), 305 deletions(-)
create mode 100644 arch/mips/generic/board-ingenic.c
delete mode 100644 arch/mips/generic/proc.c
delete mode 100644 arch/mips/include/asm/mach-jz4740/cpu-feature-overrides.h
delete mode 100644 arch/mips/include/asm/mach-jz4740/irq.h
rename arch/mips/{jz4740 => ingenic}/Kconfig (91%)
delete mode 100644 arch/mips/jz4740/Makefile
delete mode 100644 arch/mips/jz4740/Platform
delete mode 100644 arch/mips/jz4740/setup.c
[PATCH 10/22] crypto: atmel-aes - add check for xts input length equal to zero
From: Andrei Botila Standardize the way input lengths equal to 0 are handled in all skcipher algorithms. All the algorithms return 0 for input lengths equal to zero. Cc: Nicolas Ferre Cc: Alexandre Belloni Cc: Ludovic Desroches Signed-off-by: Andrei Botila --- drivers/crypto/atmel-aes.c | 4 1 file changed, 4 insertions(+) diff --git a/drivers/crypto/atmel-aes.c b/drivers/crypto/atmel-aes.c index a6e14491e080..af789ac73478 100644 --- a/drivers/crypto/atmel-aes.c +++ b/drivers/crypto/atmel-aes.c @@ -1107,6 +1107,10 @@ static int atmel_aes_crypt(struct skcipher_request *req, unsigned long mode) ctx->block_size = CFB64_BLOCK_SIZE; break; + case AES_FLAGS_XTS: + if (!req->cryptlen) + return 0; + default: ctx->block_size = AES_BLOCK_SIZE; break; -- 2.17.1
[PATCH 19/22] crypto: inside-secure - add check for xts input length equal to zero
From: Andrei Botila
Standardize the way input lengths equal to 0 are handled in all skcipher
algorithms. All the algorithms return 0 for input lengths equal to zero.
Cc: Antoine Tenart
Signed-off-by: Andrei Botila
---
drivers/crypto/inside-secure/safexcel_cipher.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/crypto/inside-secure/safexcel_cipher.c
b/drivers/crypto/inside-secure/safexcel_cipher.c
index 1ac3253b7903..03d06556ea98 100644
--- a/drivers/crypto/inside-secure/safexcel_cipher.c
+++ b/drivers/crypto/inside-secure/safexcel_cipher.c
@@ -2533,6 +2533,9 @@ static int safexcel_skcipher_aes_xts_cra_init(struct
crypto_tfm *tfm)
static int safexcel_encrypt_xts(struct skcipher_request *req)
{
+ if (!req->cryptlen)
+ return 0;
+
if (req->cryptlen < XTS_BLOCK_SIZE)
return -EINVAL;
return safexcel_queue_req(&req->base, skcipher_request_ctx(req),
@@ -2541,6 +2544,9 @@ static int safexcel_encrypt_xts(struct skcipher_request
*req)
static int safexcel_decrypt_xts(struct skcipher_request *req)
{
+ if (!req->cryptlen)
+ return 0;
+
if (req->cryptlen < XTS_BLOCK_SIZE)
return -EINVAL;
return safexcel_queue_req(&req->base, skcipher_request_ctx(req),
--
2.17.1
[PATCH 12/22] crypto: bcm - add check for xts input length equal to zero
From: Andrei Botila
Standardize the way input lengths equal to 0 are handled in all skcipher
algorithms. All the algorithms return 0 for input lengths equal to zero.
Cc: Zhang Shengju
Cc: Tang Bin
Signed-off-by: Andrei Botila
---
drivers/crypto/bcm/cipher.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/crypto/bcm/cipher.c b/drivers/crypto/bcm/cipher.c
index 8a7fa1ae1ade..8a6f225f4db7 100644
--- a/drivers/crypto/bcm/cipher.c
+++ b/drivers/crypto/bcm/cipher.c
@@ -1754,6 +1754,9 @@ static int skcipher_enqueue(struct skcipher_request *req,
bool encrypt)
crypto_skcipher_ctx(crypto_skcipher_reqtfm(req));
int err;
+ if (!req->cryptlen && ctx->cipher.mode == CIPHER_MODE_XTS)
+ return 0;
+
flow_log("%s() enc:%u\n", __func__, encrypt);
rctx->gfp = (req->base.flags & (CRYPTO_TFM_REQ_MAY_BACKLOG |
--
2.17.1
[PATCH 13/22] crypto: cavium/cpt - add check for xts input length equal to zero
From: Andrei Botila
Standardize the way input lengths equal to 0 are handled in all skcipher
algorithms. All the algorithms return 0 for input lengths equal to zero.
Cc: George Cherian
Signed-off-by: Andrei Botila
---
drivers/crypto/cavium/cpt/cptvf_algs.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/crypto/cavium/cpt/cptvf_algs.c
b/drivers/crypto/cavium/cpt/cptvf_algs.c
index 5af0dc2a8909..edc18c8dd571 100644
--- a/drivers/crypto/cavium/cpt/cptvf_algs.c
+++ b/drivers/crypto/cavium/cpt/cptvf_algs.c
@@ -193,6 +193,7 @@ static inline void create_output_list(struct
skcipher_request *req,
static inline int cvm_enc_dec(struct skcipher_request *req, u32 enc)
{
struct crypto_skcipher *tfm = crypto_skcipher_reqtfm(req);
+ struct cvm_enc_ctx *ctx = crypto_skcipher_ctx(tfm);
struct cvm_req_ctx *rctx = skcipher_request_ctx(req);
u32 enc_iv_len = crypto_skcipher_ivsize(tfm);
struct fc_context *fctx = &rctx->fctx;
@@ -200,6 +201,9 @@ static inline int cvm_enc_dec(struct skcipher_request *req,
u32 enc)
void *cdev = NULL;
int status;
+ if (!req->cryptlen && ctx->cipher_type == AES_XTS)
+ return 0;
+
memset(req_info, 0, sizeof(struct cpt_request_info));
req_info->may_sleep = (req->base.flags & CRYPTO_TFM_REQ_MAY_SLEEP) != 0;
memset(fctx, 0, sizeof(struct fc_context));
--
2.17.1
[PATCH 20/22] crypto: octeontx - add check for xts input length equal to zero
From: Andrei Botila
Standardize the way input lengths equal to 0 are handled in all skcipher
algorithms. All the algorithms return 0 for input lengths equal to zero.
Cc: Boris Brezillon
Cc: Arnaud Ebalard
Cc: Srujana Challa
Signed-off-by: Andrei Botila
---
drivers/crypto/marvell/octeontx/otx_cptvf_algs.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/crypto/marvell/octeontx/otx_cptvf_algs.c
b/drivers/crypto/marvell/octeontx/otx_cptvf_algs.c
index 90bb31329d4b..ec13bc3f1766 100644
--- a/drivers/crypto/marvell/octeontx/otx_cptvf_algs.c
+++ b/drivers/crypto/marvell/octeontx/otx_cptvf_algs.c
@@ -340,11 +340,16 @@ static inline int cpt_enc_dec(struct skcipher_request
*req, u32 enc)
{
struct crypto_skcipher *stfm = crypto_skcipher_reqtfm(req);
struct otx_cpt_req_ctx *rctx = skcipher_request_ctx(req);
+ struct crypto_tfm *tfm = crypto_skcipher_tfm(stfm);
+ struct otx_cpt_enc_ctx *ctx = crypto_tfm_ctx(tfm);
struct otx_cpt_req_info *req_info = &rctx->cpt_req;
u32 enc_iv_len = crypto_skcipher_ivsize(stfm);
struct pci_dev *pdev;
int status, cpu_num;
+ if (!req->cryptlen && ctx->cipher_type == OTX_CPT_AES_XTS)
+ return 0;
+
/* Validate that request doesn't exceed maximum CPT supported size */
if (req->cryptlen > OTX_CPT_MAX_REQ_SIZE)
return -E2BIG;
--
2.17.1
[PATCH 16/22] crypto: ccree - add check for xts input length equal to zero
From: Andrei Botila
Standardize the way input lengths equal to 0 are handled in all skcipher
algorithms. All the algorithms return 0 for input lengths equal to zero.
This change has implications not only for xts(aes) but also for cts(cbc(aes))
and cts(cbc(paes)).
Cc: Gilad Ben-Yossef
Signed-off-by: Andrei Botila
---
drivers/crypto/ccree/cc_cipher.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/drivers/crypto/ccree/cc_cipher.c b/drivers/crypto/ccree/cc_cipher.c
index 076669dc1035..112bb8b4dce6 100644
--- a/drivers/crypto/ccree/cc_cipher.c
+++ b/drivers/crypto/ccree/cc_cipher.c
@@ -912,17 +912,18 @@ static int cc_cipher_process(struct skcipher_request *req,
/* STAT_PHASE_0: Init and sanity checks */
- if (validate_data_size(ctx_p, nbytes)) {
- dev_dbg(dev, "Unsupported data size %d.\n", nbytes);
- rc = -EINVAL;
- goto exit_process;
- }
if (nbytes == 0) {
/* No data to process is valid */
rc = 0;
goto exit_process;
}
+ if (validate_data_size(ctx_p, nbytes)) {
+ dev_dbg(dev, "Unsupported data size %d.\n", nbytes);
+ rc = -EINVAL;
+ goto exit_process;
+ }
+
if (ctx_p->fallback_on) {
struct skcipher_request *subreq = skcipher_request_ctx(req);
--
2.17.1
[PATCH 18/22] crypto: hisilicon/sec - add check for xts input length equal to zero
From: Andrei Botila Standardize the way input lengths equal to 0 are handled in all skcipher algorithms. All the algorithms return 0 for input lengths equal to zero. Signed-off-by: Andrei Botila --- drivers/crypto/hisilicon/sec/sec_algs.c | 4 1 file changed, 4 insertions(+) diff --git a/drivers/crypto/hisilicon/sec/sec_algs.c b/drivers/crypto/hisilicon/sec/sec_algs.c index 8ca945ac297e..419ec4f23164 100644 --- a/drivers/crypto/hisilicon/sec/sec_algs.c +++ b/drivers/crypto/hisilicon/sec/sec_algs.c @@ -723,6 +723,10 @@ static int sec_alg_skcipher_crypto(struct skcipher_request *skreq, bool split = skreq->src != skreq->dst; gfp_t gfp = skreq->base.flags & CRYPTO_TFM_REQ_MAY_SLEEP ? GFP_KERNEL : GFP_ATOMIC; + if (!skreq->cryptlen && (ctx->cipher_alg == SEC_C_AES_XTS_128 || +ctx->cipher_alg == SEC_C_AES_XTS_256)) + return 0; + mutex_init(&sec_req->lock); sec_req->req_base = &skreq->base; sec_req->err = 0; -- 2.17.1
[PATCH 21/22] crypto: qce - add check for xts input length equal to zero
From: Andrei Botila Standardize the way input lengths equal to 0 are handled in all skcipher algorithms. All the algorithms return 0 for input lengths equal to zero. Signed-off-by: Andrei Botila --- drivers/crypto/qce/skcipher.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/crypto/qce/skcipher.c b/drivers/crypto/qce/skcipher.c index 5630c5addd28..887fd4dc9b43 100644 --- a/drivers/crypto/qce/skcipher.c +++ b/drivers/crypto/qce/skcipher.c @@ -223,6 +223,9 @@ static int qce_skcipher_crypt(struct skcipher_request *req, int encrypt) int keylen; int ret; + if (!req->cryptlen && IS_XTS(rctx->flags)) + return 0; + rctx->flags = tmpl->alg_flags; rctx->flags |= encrypt ? QCE_ENCRYPT : QCE_DECRYPT; keylen = IS_XTS(rctx->flags) ? ctx->enc_keylen >> 1 : ctx->enc_keylen; -- 2.17.1
[PATCH 17/22] crypto: chelsio - add check for xts input length equal to zero
From: Andrei Botila Standardize the way input lengths equal to 0 are handled in all skcipher algorithms. All the algorithms return 0 for input lengths equal to zero. Cc: Ayush Sawal Cc: Vinay Kumar Yadav Cc: Rohit Maheshwari Signed-off-by: Andrei Botila --- drivers/crypto/chelsio/chcr_algo.c | 4 1 file changed, 4 insertions(+) diff --git a/drivers/crypto/chelsio/chcr_algo.c b/drivers/crypto/chelsio/chcr_algo.c index 13b908ea4873..e9746580870a 100644 --- a/drivers/crypto/chelsio/chcr_algo.c +++ b/drivers/crypto/chelsio/chcr_algo.c @@ -1372,8 +1372,12 @@ static int chcr_aes_encrypt(struct skcipher_request *req) int err; struct uld_ctx *u_ctx = ULD_CTX(c_ctx(tfm)); struct chcr_context *ctx = c_ctx(tfm); + int subtype = get_cryptoalg_subtype(tfm); unsigned int cpu; + if (!req->cryptlen && subtype == CRYPTO_ALG_SUB_TYPE_XTS) + return 0; + cpu = get_cpu(); reqctx->txqidx = cpu % ctx->ntxq; reqctx->rxqidx = cpu % ctx->nrxq; -- 2.17.1
Re: srvfs: file system for posting open file descriptors into fs namespace
On Fri, Aug 07, 2020 at 01:09:30PM +0200, Enrico Weigelt, metux IT consult wrote: > Hello folks, > > > here's the first version of my "srvfs" implementation - a synthentic > filesystem which allows a process to "publish" an open file descriptor > into the file system, so other processes can continue from there, with > whatever state the fd is already in. > > This is a concept from Plan9. The main purpose is allowing applications > "dialing" some connection, do initial handshakes (eg. authentication) > and then publish the connection to other applications, that now can now > make use of the already dialed connection. Yeah, but... Linux open() always gets a new struct file instance; how do you work around that? Some variant of ->atomic_open() API change? Details, please.
[PATCH 15/22] crypto: ccp - add check for xts input length equal to zero
From: Andrei Botila Standardize the way input lengths equal to 0 are handled in all skcipher algorithms. All the algorithms return 0 for input lengths equal to zero. Cc: Tom Lendacky Cc: John Allen Signed-off-by: Andrei Botila --- drivers/crypto/ccp/ccp-crypto-aes-xts.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/crypto/ccp/ccp-crypto-aes-xts.c b/drivers/crypto/ccp/ccp-crypto-aes-xts.c index 6849261ca47d..6a93b54d388a 100644 --- a/drivers/crypto/ccp/ccp-crypto-aes-xts.c +++ b/drivers/crypto/ccp/ccp-crypto-aes-xts.c @@ -113,6 +113,9 @@ static int ccp_aes_xts_crypt(struct skcipher_request *req, u32 unit_size; int ret; + if (!req->cryptlen) + return 0; + if (!ctx->u.aes.key_len) return -EINVAL; -- 2.17.1
[PATCH 08/22] crypto: x86/glue_helper - add check for xts input length equal to zero
From: Andrei Botila Standardize the way input lengths equal to 0 are handled in all skcipher algorithms. All the algorithms return 0 for input lengths equal to zero. Cc: Thomas Gleixner Cc: Ingo Molnar Cc: Borislav Petkov Cc: "H. Peter Anvin" Signed-off-by: Andrei Botila --- arch/x86/crypto/glue_helper.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/arch/x86/crypto/glue_helper.c b/arch/x86/crypto/glue_helper.c index d3d91a0abf88..cc5042c72910 100644 --- a/arch/x86/crypto/glue_helper.c +++ b/arch/x86/crypto/glue_helper.c @@ -275,6 +275,9 @@ int glue_xts_req_128bit(const struct common_glue_ctx *gctx, unsigned int nbytes, tail; int err; + if (!req->cryptlen) + return 0; + if (req->cryptlen < XTS_BLOCK_SIZE) return -EINVAL; -- 2.17.1
[PATCH 01/22] crypto: arm/aes-ce - add check for xts input length equal to zero
From: Andrei Botila Standardize the way input lengths equal to 0 are handled in all skcipher algorithms. All the algorithms return 0 for input lengths equal to zero. Cc: Russell King Signed-off-by: Andrei Botila --- arch/arm/crypto/aes-ce-glue.c | 6 ++ 1 file changed, 6 insertions(+) diff --git a/arch/arm/crypto/aes-ce-glue.c b/arch/arm/crypto/aes-ce-glue.c index b668c97663ec..57a9cf7fe98a 100644 --- a/arch/arm/crypto/aes-ce-glue.c +++ b/arch/arm/crypto/aes-ce-glue.c @@ -452,6 +452,9 @@ static int xts_encrypt(struct skcipher_request *req) struct scatterlist *src, *dst; struct skcipher_walk walk; + if (!req->cryptlen) + return 0; + if (req->cryptlen < AES_BLOCK_SIZE) return -EINVAL; @@ -524,6 +527,9 @@ static int xts_decrypt(struct skcipher_request *req) struct scatterlist *src, *dst; struct skcipher_walk walk; + if (!req->cryptlen) + return 0; + if (req->cryptlen < AES_BLOCK_SIZE) return -EINVAL; -- 2.17.1
[PATCH 22/22] crypto: vmx - add check for xts input length equal to zero
From: Andrei Botila Standardize the way input lengths equal to 0 are handled in all skcipher algorithms. All the algorithms return 0 for input lengths equal to zero. Cc: "Breno Leitão" Cc: Nayna Jain Cc: Paulo Flabiano Smorigo Cc: Benjamin Herrenschmidt Cc: Paul Mackerras Cc: Michael Ellerman Signed-off-by: Andrei Botila --- drivers/crypto/vmx/aes_xts.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/crypto/vmx/aes_xts.c b/drivers/crypto/vmx/aes_xts.c index 9fee1b1532a4..33107c9e2656 100644 --- a/drivers/crypto/vmx/aes_xts.c +++ b/drivers/crypto/vmx/aes_xts.c @@ -84,6 +84,9 @@ static int p8_aes_xts_crypt(struct skcipher_request *req, int enc) u8 tweak[AES_BLOCK_SIZE]; int ret; + if (!req->cryptlen) + return 0; + if (req->cryptlen < AES_BLOCK_SIZE) return -EINVAL; -- 2.17.1
[PATCH 11/22] crypto: artpec6 - add check for xts input length equal to zero
From: Andrei Botila
Standardize the way input lengths equal to 0 are handled in all skcipher
algorithms. All the algorithms return 0 for input lengths equal to zero.
Cc: Jesper Nilsson
Cc: Lars Persson
Signed-off-by: Andrei Botila
---
drivers/crypto/axis/artpec6_crypto.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/crypto/axis/artpec6_crypto.c
b/drivers/crypto/axis/artpec6_crypto.c
index 1a46eeddf082..243880c97629 100644
--- a/drivers/crypto/axis/artpec6_crypto.c
+++ b/drivers/crypto/axis/artpec6_crypto.c
@@ -1090,6 +1090,9 @@ static int artpec6_crypto_encrypt(struct skcipher_request
*req)
void (*complete)(struct crypto_async_request *req);
int ret;
+ if (!req->cryptlen)
+ return 0;
+
req_ctx = skcipher_request_ctx(req);
switch (ctx->crypto_type) {
@@ -1135,6 +1138,9 @@ static int artpec6_crypto_decrypt(struct skcipher_request
*req)
struct artpec6_crypto_request_context *req_ctx = NULL;
void (*complete)(struct crypto_async_request *req);
+ if (!req->cryptlen)
+ return 0;
+
req_ctx = skcipher_request_ctx(req);
switch (ctx->crypto_type) {
--
2.17.1
[PATCH 07/22] crypto: s390/paes - add check for xts input length equal to zero
From: Andrei Botila Standardize the way input lengths equal to 0 are handled in all skcipher algorithms. All the algorithms return 0 for input lengths equal to zero. Cc: Heiko Carstens Cc: Vasily Gorbik Cc: Christian Borntraeger Signed-off-by: Andrei Botila --- arch/s390/crypto/paes_s390.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/arch/s390/crypto/paes_s390.c b/arch/s390/crypto/paes_s390.c index f3caeb17c85b..7f0861c6f019 100644 --- a/arch/s390/crypto/paes_s390.c +++ b/arch/s390/crypto/paes_s390.c @@ -494,6 +494,9 @@ static int xts_paes_crypt(struct skcipher_request *req, unsigned long modifier) u8 init[16]; } xts_param; + if (!req->cryptlen) + return 0; + ret = skcipher_walk_virt(&walk, req, false); if (ret) return ret; -- 2.17.1
[PATCH 09/22] crypto: xts - add check for block length equal to zero
From: Andrei Botila Standardize the way input lengths equal to 0 are handled in all skcipher algorithms. All the algorithms return 0 for input lengths equal to zero. Signed-off-by: Andrei Botila --- crypto/xts.c | 6 ++ 1 file changed, 6 insertions(+) diff --git a/crypto/xts.c b/crypto/xts.c index 3c3ed02c7663..7df68f52fddc 100644 --- a/crypto/xts.c +++ b/crypto/xts.c @@ -263,6 +263,9 @@ static int xts_encrypt(struct skcipher_request *req) struct skcipher_request *subreq = &rctx->subreq; int err; + if (!req->cryptlen) + return 0; + err = xts_init_crypt(req, xts_encrypt_done) ?: xts_xor_tweak_pre(req, true) ?: crypto_skcipher_encrypt(subreq) ?: @@ -280,6 +283,9 @@ static int xts_decrypt(struct skcipher_request *req) struct skcipher_request *subreq = &rctx->subreq; int err; + if (!req->cryptlen) + return 0; + err = xts_init_crypt(req, xts_decrypt_done) ?: xts_xor_tweak_pre(req, false) ?: crypto_skcipher_decrypt(subreq) ?: -- 2.17.1
[PATCH 14/22] crypto: cavium/nitrox - add check for xts input length equal to zero
From: Andrei Botila Standardize the way input lengths equal to 0 are handled in all skcipher algorithms. All the algorithms return 0 for input lengths equal to zero. Cc: Srikanth Jampala Cc: Nagadheeraj Rottela Signed-off-by: Andrei Botila --- drivers/crypto/cavium/nitrox/nitrox_skcipher.c | 6 ++ 1 file changed, 6 insertions(+) diff --git a/drivers/crypto/cavium/nitrox/nitrox_skcipher.c b/drivers/crypto/cavium/nitrox/nitrox_skcipher.c index a553ac65f324..d76589ebe354 100644 --- a/drivers/crypto/cavium/nitrox/nitrox_skcipher.c +++ b/drivers/crypto/cavium/nitrox/nitrox_skcipher.c @@ -249,10 +249,16 @@ static int nitrox_skcipher_crypt(struct skcipher_request *skreq, bool enc) struct crypto_skcipher *cipher = crypto_skcipher_reqtfm(skreq); struct nitrox_crypto_ctx *nctx = crypto_skcipher_ctx(cipher); struct nitrox_kcrypt_request *nkreq = skcipher_request_ctx(skreq); + struct crypto_tfm *tfm = crypto_skcipher_tfm(cipher); int ivsize = crypto_skcipher_ivsize(cipher); struct se_crypto_request *creq; + const char *name; int ret; + name = crypto_tfm_alg_name(tfm); + if (!skreq->cryptlen && flexi_cipher_type(name) == CIPHER_AES_XTS) + return 0; + creq = &nkreq->creq; creq->flags = skreq->base.flags; creq->gfp = (skreq->base.flags & CRYPTO_TFM_REQ_MAY_SLEEP) ? -- 2.17.1
Re: [PATCH] drivers: watchdog: rdc321x_wdt: Fix race condition bugs
On Fri, Aug 07, 2020 at 04:59:02PM +0530, madhuparnabhowmi...@gmail.com wrote:
> From: Madhuparna Bhowmik
>
> In rdc321x_wdt_probe(), rdc321x_wdt_device.queue is initialized
> after misc_register(), hence if ioctl is called before its
> initialization which can call rdc321x_wdt_start() function,
> it will see an uninitialized value of rdc321x_wdt_device.queue,
> hence initialize it before misc_register().
> Also, rdc321x_wdt_device.default_ticks is accessed in reset()
> function called from write callback, thus initialize it before
> misc_register().
>
> Found by Linux Driver Verification project (linuxtesting.org).
>
> Signed-off-by: Madhuparna Bhowmik
Reviewed-by: Guenter Roeck
Having said that ... this is yet another potentially obsolete driver.
You are really wasting your (and, fwiw, my) time.
Florian, any thoughts if support for this chip can/should be deprecated
or even removed ?
Guenter
> ---
> drivers/watchdog/rdc321x_wdt.c | 5 ++---
> 1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/watchdog/rdc321x_wdt.c b/drivers/watchdog/rdc321x_wdt.c
> index 57187efeb86f..f0c94ea51c3e 100644
> --- a/drivers/watchdog/rdc321x_wdt.c
> +++ b/drivers/watchdog/rdc321x_wdt.c
> @@ -231,6 +231,8 @@ static int rdc321x_wdt_probe(struct platform_device *pdev)
>
> rdc321x_wdt_device.sb_pdev = pdata->sb_pdev;
> rdc321x_wdt_device.base_reg = r->start;
> + rdc321x_wdt_device.queue = 0;
> + rdc321x_wdt_device.default_ticks = ticks;
>
> err = misc_register(&rdc321x_wdt_misc);
> if (err < 0) {
> @@ -245,14 +247,11 @@ static int rdc321x_wdt_probe(struct platform_device
> *pdev)
> rdc321x_wdt_device.base_reg, RDC_WDT_RST);
>
> init_completion(&rdc321x_wdt_device.stop);
> - rdc321x_wdt_device.queue = 0;
>
> clear_bit(0, &rdc321x_wdt_device.inuse);
>
> timer_setup(&rdc321x_wdt_device.timer, rdc321x_wdt_trigger, 0);
>
> - rdc321x_wdt_device.default_ticks = ticks;
> -
> dev_info(&pdev->dev, "watchdog init success\n");
>
> return 0;
> --
> 2.17.1
>
[PATCH 02/22] crypto: arm/aes-neonbs - add check for xts input length equal to zero
From: Andrei Botila Standardize the way input lengths equal to 0 are handled in all skcipher algorithms. All the algorithms return 0 for input lengths equal to zero. Cc: Russell King Signed-off-by: Andrei Botila --- arch/arm/crypto/aes-neonbs-glue.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/arch/arm/crypto/aes-neonbs-glue.c b/arch/arm/crypto/aes-neonbs-glue.c index e6fd32919c81..98ca6e6cca90 100644 --- a/arch/arm/crypto/aes-neonbs-glue.c +++ b/arch/arm/crypto/aes-neonbs-glue.c @@ -339,6 +339,9 @@ static int __xts_crypt(struct skcipher_request *req, bool encrypt, struct skcipher_walk walk; int err; + if (!req->cryptlen) + return 0; + if (req->cryptlen < AES_BLOCK_SIZE) return -EINVAL; -- 2.17.1
[PATCH 05/22] crypto: powerpc/aes-spe - add check for xts input length equal to zero
From: Andrei Botila Standardize the way input lengths equal to 0 are handled in all skcipher algorithms. All the algorithms return 0 for input lengths equal to zero. Cc: Benjamin Herrenschmidt Cc: Paul Mackerras Cc: Michael Ellerman Signed-off-by: Andrei Botila --- arch/powerpc/crypto/aes-spe-glue.c | 6 ++ 1 file changed, 6 insertions(+) diff --git a/arch/powerpc/crypto/aes-spe-glue.c b/arch/powerpc/crypto/aes-spe-glue.c index c2b23b69d7b1..f37d8bef322b 100644 --- a/arch/powerpc/crypto/aes-spe-glue.c +++ b/arch/powerpc/crypto/aes-spe-glue.c @@ -327,6 +327,9 @@ static int ppc_xts_encrypt(struct skcipher_request *req) u8 b[2][AES_BLOCK_SIZE]; int err; + if (!req->cryptlen) + return 0; + if (req->cryptlen < AES_BLOCK_SIZE) return -EINVAL; @@ -366,6 +369,9 @@ static int ppc_xts_decrypt(struct skcipher_request *req) le128 twk; int err; + if (!req->cryptlen) + return 0; + if (req->cryptlen < AES_BLOCK_SIZE) return -EINVAL; -- 2.17.1
[PATCH 03/22] crypto: arm64/aes - add check for xts input length equal to zero
From: Andrei Botila Standardize the way input lengths equal to 0 are handled in all skcipher algorithms. All the algorithms return 0 for input lengths equal to zero. Cc: Catalin Marinas Cc: Will Deacon Signed-off-by: Andrei Botila --- arch/arm64/crypto/aes-glue.c | 6 ++ 1 file changed, 6 insertions(+) diff --git a/arch/arm64/crypto/aes-glue.c b/arch/arm64/crypto/aes-glue.c index 395bbf64b2ab..44c9644c74b1 100644 --- a/arch/arm64/crypto/aes-glue.c +++ b/arch/arm64/crypto/aes-glue.c @@ -515,6 +515,9 @@ static int __maybe_unused xts_encrypt(struct skcipher_request *req) struct scatterlist *src, *dst; struct skcipher_walk walk; + if (!req->cryptlen) + return 0; + if (req->cryptlen < AES_BLOCK_SIZE) return -EINVAL; @@ -587,6 +590,9 @@ static int __maybe_unused xts_decrypt(struct skcipher_request *req) struct scatterlist *src, *dst; struct skcipher_walk walk; + if (!req->cryptlen) + return 0; + if (req->cryptlen < AES_BLOCK_SIZE) return -EINVAL; -- 2.17.1
[PATCH 06/22] crypto: s390/aes - add check for xts input length equal to zero
From: Andrei Botila Standardize the way input lengths equal to 0 are handled in all skcipher algorithms. All the algorithms return 0 for input lengths equal to zero. Cc: Heiko Carstens Cc: Vasily Gorbik Cc: Christian Borntraeger Signed-off-by: Andrei Botila --- arch/s390/crypto/aes_s390.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/arch/s390/crypto/aes_s390.c b/arch/s390/crypto/aes_s390.c index 73044634d342..bc8855f4b7d1 100644 --- a/arch/s390/crypto/aes_s390.c +++ b/arch/s390/crypto/aes_s390.c @@ -437,6 +437,9 @@ static int xts_aes_crypt(struct skcipher_request *req, unsigned long modifier) u8 init[16]; } xts_param; + if (!req->cryptlen) + return 0; + if (req->cryptlen < AES_BLOCK_SIZE) return -EINVAL; -- 2.17.1
[PATCH 04/22] crypto: arm64/aes-neonbs - add check for xts input length equal to zero
From: Andrei Botila Standardize the way input lengths equal to 0 are handled in all skcipher algorithms. All the algorithms return 0 for input lengths equal to zero. Cc: Catalin Marinas Cc: Will Deacon Signed-off-by: Andrei Botila --- arch/arm64/crypto/aes-neonbs-glue.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/arch/arm64/crypto/aes-neonbs-glue.c b/arch/arm64/crypto/aes-neonbs-glue.c index fb507d569922..197bf24e7dae 100644 --- a/arch/arm64/crypto/aes-neonbs-glue.c +++ b/arch/arm64/crypto/aes-neonbs-glue.c @@ -330,6 +330,9 @@ static int __xts_crypt(struct skcipher_request *req, bool encrypt, int first = 1; u8 *out, *in; + if (!req->cryptlen) + return 0; + if (req->cryptlen < AES_BLOCK_SIZE) return -EINVAL; -- 2.17.1
