Linux-stable-mirror

linux-stable-mirror@lists.linaro.org

3 participants
123729 discussions

[PATCH AUTOSEL 4.4 1/9] RDMA/mlx4: Initialize ib_spec on the stack

by Sasha Levin

From: Alaa Hleihel <alaa(a)mellanox.com> [ Upstream commit c08cfb2d8d78bfe81b37cc6ba84f0875bddd0d5c ] Initialize ib_spec on the stack before using it, otherwise we will have garbage values that will break creating default rules with invalid parsing error. Fixes: a37a1a428431 ("IB/mlx4: Add mechanism to support flow steering over IB links") Link: https://lore.kernel.org/r/20200413132235.930642-1-leon@kernel.org Signed-off-by: Alaa Hleihel <alaa(a)mellanox.com> Reviewed-by: Maor Gottlieb <maorg(a)mellanox.com> Signed-off-by: Leon Romanovsky <leonro(a)mellanox.com> Signed-off-by: Jason Gunthorpe <jgg(a)mellanox.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- drivers/infiniband/hw/mlx4/main.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/infiniband/hw/mlx4/main.c b/drivers/infiniband/hw/mlx4/main.c index 6968154a073e4..ac9f173c43111 100644 --- a/drivers/infiniband/hw/mlx4/main.c +++ b/drivers/infiniband/hw/mlx4/main.c @@ -1435,8 +1435,9 @@ static int __mlx4_ib_create_default_rules( int i; for (i = 0; i < ARRAY_SIZE(pdefault_rules->rules_create_list); i++) { + union ib_flow_spec ib_spec = {}; int ret; - union ib_flow_spec ib_spec; + switch (pdefault_rules->rules_create_list[i]) { case 0: /* no rule */ -- 2.20.1

5 years, 7 months

[PATCH AUTOSEL 4.9 01/11] RDMA/mlx4: Initialize ib_spec on the stack

by Sasha Levin

From: Alaa Hleihel <alaa(a)mellanox.com> [ Upstream commit c08cfb2d8d78bfe81b37cc6ba84f0875bddd0d5c ] Initialize ib_spec on the stack before using it, otherwise we will have garbage values that will break creating default rules with invalid parsing error. Fixes: a37a1a428431 ("IB/mlx4: Add mechanism to support flow steering over IB links") Link: https://lore.kernel.org/r/20200413132235.930642-1-leon@kernel.org Signed-off-by: Alaa Hleihel <alaa(a)mellanox.com> Reviewed-by: Maor Gottlieb <maorg(a)mellanox.com> Signed-off-by: Leon Romanovsky <leonro(a)mellanox.com> Signed-off-by: Jason Gunthorpe <jgg(a)mellanox.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- drivers/infiniband/hw/mlx4/main.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/infiniband/hw/mlx4/main.c b/drivers/infiniband/hw/mlx4/main.c index adc46b809ef2a..0555c939c948d 100644 --- a/drivers/infiniband/hw/mlx4/main.c +++ b/drivers/infiniband/hw/mlx4/main.c @@ -1589,8 +1589,9 @@ static int __mlx4_ib_create_default_rules( int i; for (i = 0; i < ARRAY_SIZE(pdefault_rules->rules_create_list); i++) { + union ib_flow_spec ib_spec = {}; int ret; - union ib_flow_spec ib_spec; + switch (pdefault_rules->rules_create_list[i]) { case 0: /* no rule */ -- 2.20.1

5 years, 7 months

[PATCH AUTOSEL 4.14 01/16] RDMA/mlx4: Initialize ib_spec on the stack

by Sasha Levin

From: Alaa Hleihel <alaa(a)mellanox.com> [ Upstream commit c08cfb2d8d78bfe81b37cc6ba84f0875bddd0d5c ] Initialize ib_spec on the stack before using it, otherwise we will have garbage values that will break creating default rules with invalid parsing error. Fixes: a37a1a428431 ("IB/mlx4: Add mechanism to support flow steering over IB links") Link: https://lore.kernel.org/r/20200413132235.930642-1-leon@kernel.org Signed-off-by: Alaa Hleihel <alaa(a)mellanox.com> Reviewed-by: Maor Gottlieb <maorg(a)mellanox.com> Signed-off-by: Leon Romanovsky <leonro(a)mellanox.com> Signed-off-by: Jason Gunthorpe <jgg(a)mellanox.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- drivers/infiniband/hw/mlx4/main.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/infiniband/hw/mlx4/main.c b/drivers/infiniband/hw/mlx4/main.c index 7e73a1a6cb671..3f8511104c5b6 100644 --- a/drivers/infiniband/hw/mlx4/main.c +++ b/drivers/infiniband/hw/mlx4/main.c @@ -1614,8 +1614,9 @@ static int __mlx4_ib_create_default_rules( int i; for (i = 0; i < ARRAY_SIZE(pdefault_rules->rules_create_list); i++) { + union ib_flow_spec ib_spec = {}; int ret; - union ib_flow_spec ib_spec; + switch (pdefault_rules->rules_create_list[i]) { case 0: /* no rule */ -- 2.20.1

5 years, 7 months

[PATCH AUTOSEL 4.19 01/20] RDMA/mlx4: Initialize ib_spec on the stack

by Sasha Levin

From: Alaa Hleihel <alaa(a)mellanox.com> [ Upstream commit c08cfb2d8d78bfe81b37cc6ba84f0875bddd0d5c ] Initialize ib_spec on the stack before using it, otherwise we will have garbage values that will break creating default rules with invalid parsing error. Fixes: a37a1a428431 ("IB/mlx4: Add mechanism to support flow steering over IB links") Link: https://lore.kernel.org/r/20200413132235.930642-1-leon@kernel.org Signed-off-by: Alaa Hleihel <alaa(a)mellanox.com> Reviewed-by: Maor Gottlieb <maorg(a)mellanox.com> Signed-off-by: Leon Romanovsky <leonro(a)mellanox.com> Signed-off-by: Jason Gunthorpe <jgg(a)mellanox.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- drivers/infiniband/hw/mlx4/main.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/infiniband/hw/mlx4/main.c b/drivers/infiniband/hw/mlx4/main.c index a19d3ad14dc37..eac4ade456119 100644 --- a/drivers/infiniband/hw/mlx4/main.c +++ b/drivers/infiniband/hw/mlx4/main.c @@ -1606,8 +1606,9 @@ static int __mlx4_ib_create_default_rules( int i; for (i = 0; i < ARRAY_SIZE(pdefault_rules->rules_create_list); i++) { + union ib_flow_spec ib_spec = {}; int ret; - union ib_flow_spec ib_spec; + switch (pdefault_rules->rules_create_list[i]) { case 0: /* no rule */ -- 2.20.1

5 years, 7 months

[PATCH v2] fork: prevent accidental access to clone3 features

by Christian Brauner

Jan reported an issue where an interaction between sign-extending clone's flag argument on ppc64le and the new CLONE_INTO_CGROUP feature causes clone() to consistently fail with EBADF. The whole story is a little longer. The legacy clone() syscall is odd in a bunch of ways and here two things interact. First, legacy clone's flag argument is word-size dependent, i.e. it's an unsigned long whereas most system calls with flag arguments use int or unsigned int. Second, legacy clone() ignores unknown and deprecated flags. The two of them taken together means that users on 64bit systems can pass garbage for the upper 32bit of the clone() syscall since forever and things would just work fine. Just try this on a 64bit kernel prior to v5.7-rc1 where this will succeed and on v5.7-rc1 where this will fail with EBADF: int main(int argc, char *argv[]) { pid_t pid; /* Note that legacy clone() has different argument ordering on * different architectures so this won't work everywhere. * * Only set the upper 32 bits. */ pid = syscall(__NR_clone, 0xffffffff00000000 | SIGCHLD, NULL, NULL, NULL, NULL); if (pid < 0) exit(EXIT_FAILURE); if (pid == 0) exit(EXIT_SUCCESS); if (wait(NULL) != pid) exit(EXIT_FAILURE); exit(EXIT_SUCCESS); } Since legacy clone() couldn't be extended this was not a problem so far and nobody really noticed or cared since nothing in the kernel ever bothered to look at the upper 32 bits. But once we introduced clone3() and expanded the flag argument in struct clone_args to 64 bit we opened this can of worms. With the first flag-based extension to clone3() making use of the upper 32 bits of the flag argument we've effectively made it possible for the legacy clone() syscall to reach clone3() only flags. The sign extension scenario is just the odd corner-case that we needed to figure this out. The reason we just realized this now and not already when we introduced CLONE_CLEAR_SIGHAND was that CLONE_INTO_CGROUP assumes that a valid cgroup file descriptor has been given. So the sign extension (or the user accidently passing garbage for the upper 32 bits) caused the CLONE_INTO_CGROUP bit to be raised and the kernel to error out when it didn't find a valid cgroup file descriptor. Let's fix this by always capping the upper 32 bits for all codepaths that are not aware of clone3() features. This ensures that we can't reach clone3() only features by accident via legacy clone as with the sign extension case and also that legacy clone() works exactly like before, i.e. ignoring any unknown flags. This solution risks no regressions and is also pretty clean. Reported-by: Jan Stancek <jstancek(a)redhat.com> Cc: Arnd Bergmann <arnd(a)arndb.de> Cc: Dmitry V. Levin <ldv(a)altlinux.org> Cc: Andreas Schwab <schwab(a)linux-m68k.org> Cc: Florian Weimer <fw(a)deneb.enyo.de> Cc: libc-alpha(a)sourceware.org Link: https://sourceware.org/pipermail/libc-alpha/2020-May/113596.html Fixes: 7f192e3cd316 ("fork: add clone3") Fixes: ef2c41cf38a7 ("clone3: allow spawning processes into cgroups") Cc: stable(a)vger.kernel.org # 5.3+ Signed-off-by: Christian Brauner <christian.brauner(a)ubuntu.com> --- /* v2 */ - Joe Perches <joe(a)perches.com>: - Use lower_32_bit() macro. - Christian Brauner <christian.brauner(a)ubuntu.com>: - Cap flag argument to 32 bits in every place that is not clone3() feature aware. - Cc stable. --- kernel/fork.c | 13 +++++++------ 1 file changed, 7 insertions(+), 6 deletions(-) diff --git a/kernel/fork.c b/kernel/fork.c index 8c700f881d92..48ed22774efa 100644 --- a/kernel/fork.c +++ b/kernel/fork.c @@ -2486,11 +2486,11 @@ long do_fork(unsigned long clone_flags, int __user *child_tidptr) { struct kernel_clone_args args = { - .flags = (clone_flags & ~CSIGNAL), + .flags = (lower_32_bits(clone_flags) & ~CSIGNAL), .pidfd = parent_tidptr, .child_tid = child_tidptr, .parent_tid = parent_tidptr, - .exit_signal = (clone_flags & CSIGNAL), + .exit_signal = (lower_32_bits(clone_flags) & CSIGNAL), .stack = stack_start, .stack_size = stack_size, }; @@ -2508,8 +2508,9 @@ long do_fork(unsigned long clone_flags, pid_t kernel_thread(int (*fn)(void *), void *arg, unsigned long flags) { struct kernel_clone_args args = { - .flags = ((flags | CLONE_VM | CLONE_UNTRACED) & ~CSIGNAL), - .exit_signal = (flags & CSIGNAL), + .flags = ((lower_32_bits(flags) | CLONE_VM | + CLONE_UNTRACED) & ~CSIGNAL), + .exit_signal = (lower_32_bits(flags) & CSIGNAL), .stack = (unsigned long)fn, .stack_size = (unsigned long)arg, }; @@ -2570,11 +2571,11 @@ SYSCALL_DEFINE5(clone, unsigned long, clone_flags, unsigned long, newsp, #endif { struct kernel_clone_args args = { - .flags = (clone_flags & ~CSIGNAL), + .flags = (lower_32_bits(clone_flags) & ~CSIGNAL), .pidfd = parent_tidptr, .child_tid = child_tidptr, .parent_tid = parent_tidptr, - .exit_signal = (clone_flags & CSIGNAL), + .exit_signal = (lower_32_bits(clone_flags) & CSIGNAL), .stack = newsp, .tls = tls, }; base-commit: 0e698dfa282211e414076f9dc7e83c1c288314fd -- 2.26.2

5 years, 7 months

Re: [PATCH] kretprobe: Prevent triggering kretprobe from within kprobe_flush_task

by Masami Hiramatsu

On Wed, 15 Apr 2020 11:05:07 +0200 Jiri Olsa <jolsa(a)redhat.com> wrote: > Ziqian reported lockup when adding retprobe on _raw_spin_lock_irqsave. > My test was also able to trigger lockdep output: > > ============================================ > WARNING: possible recursive locking detected > 5.6.0-rc6+ #6 Not tainted > -------------------------------------------- > sched-messaging/2767 is trying to acquire lock: > ffffffff9a492798 (&(kretprobe_table_locks[i].lock)){-.-.}, at: kretprobe_hash_lock+0x52/0xa0 > > but task is already holding lock: > ffffffff9a491a18 (&(kretprobe_table_locks[i].lock)){-.-.}, at: kretprobe_trampoline+0x0/0x50 > > other info that might help us debug this: > Possible unsafe locking scenario: > > CPU0 > ---- > lock(&(kretprobe_table_locks[i].lock)); > lock(&(kretprobe_table_locks[i].lock)); > > *** DEADLOCK *** > > May be due to missing lock nesting notation > > 1 lock held by sched-messaging/2767: > #0: ffffffff9a491a18 (&(kretprobe_table_locks[i].lock)){-.-.}, at: kretprobe_trampoline+0x0/0x50 > > stack backtrace: > CPU: 3 PID: 2767 Comm: sched-messaging Not tainted 5.6.0-rc6+ #6 > Call Trace: > dump_stack+0x96/0xe0 > __lock_acquire.cold.57+0x173/0x2b7 > ? native_queued_spin_lock_slowpath+0x42b/0x9e0 > ? lockdep_hardirqs_on+0x590/0x590 > ? __lock_acquire+0xf63/0x4030 > lock_acquire+0x15a/0x3d0 > ? kretprobe_hash_lock+0x52/0xa0 > _raw_spin_lock_irqsave+0x36/0x70 > ? kretprobe_hash_lock+0x52/0xa0 > kretprobe_hash_lock+0x52/0xa0 > trampoline_handler+0xf8/0x940 > ? kprobe_fault_handler+0x380/0x380 > ? find_held_lock+0x3a/0x1c0 > kretprobe_trampoline+0x25/0x50 > ? lock_acquired+0x392/0xbc0 > ? _raw_spin_lock_irqsave+0x50/0x70 > ? __get_valid_kprobe+0x1f0/0x1f0 > ? _raw_spin_unlock_irqrestore+0x3b/0x40 > ? finish_task_switch+0x4b9/0x6d0 > ? __switch_to_asm+0x34/0x70 > ? __switch_to_asm+0x40/0x70 > > The code within the kretprobe handler checks for probe reentrancy, > so we won't trigger any _raw_spin_lock_irqsave probe in there. > > The problem is in outside kprobe_flush_task, where we call: > > kprobe_flush_task > kretprobe_table_lock > raw_spin_lock_irqsave > _raw_spin_lock_irqsave > > where _raw_spin_lock_irqsave triggers the kretprobe and installs > kretprobe_trampoline handler on _raw_spin_lock_irqsave return. > > The kretprobe_trampoline handler is then executed with already > locked kretprobe_table_locks, and first thing it does is to > lock kretprobe_table_locks ;-) the whole lockup path like: > > kprobe_flush_task > kretprobe_table_lock > raw_spin_lock_irqsave > _raw_spin_lock_irqsave ---> probe triggered, kretprobe_trampoline installed > > ---> kretprobe_table_locks locked > > kretprobe_trampoline > trampoline_handler > kretprobe_hash_lock(current, &head, &flags); <--- deadlock > > Adding kprobe_busy_begin/end helpers that mark code with fake > probe installed to prevent triggering of another kprobe within > this code. > > Using these helpers in kprobe_flush_task, so the probe recursion > protection check is hit and the probe is never set to prevent > above lockup. > > Reported-by: "Ziqian SUN (Zamir)" <zsun(a)redhat.com> > Signed-off-by: Jiri Olsa <jolsa(a)kernel.org> Thanks Jiri and Ziqian! Looks good to me. Acked-by: Masami Hiramatsu <mhiramat(a)kernel.org> BTW, this is a kind of bugfix. So should it add a Fixes tag? Fixes: ef53d9c5e4da ('kprobes: improve kretprobe scalability with hashed locking') Cc: stable(a)vger.kernel.org Thank you, > --- > arch/x86/kernel/kprobes/core.c | 16 +++------------- > include/linux/kprobes.h | 4 ++++ > kernel/kprobes.c | 24 ++++++++++++++++++++++++ > 3 files changed, 31 insertions(+), 13 deletions(-) > > diff --git a/arch/x86/kernel/kprobes/core.c b/arch/x86/kernel/kprobes/core.c > index 4d7022a740ab..a12adbe1559d 100644 > --- a/arch/x86/kernel/kprobes/core.c > +++ b/arch/x86/kernel/kprobes/core.c > @@ -753,16 +753,11 @@ asm( > NOKPROBE_SYMBOL(kretprobe_trampoline); > STACK_FRAME_NON_STANDARD(kretprobe_trampoline); > > -static struct kprobe kretprobe_kprobe = { > - .addr = (void *)kretprobe_trampoline, > -}; > - > /* > * Called from kretprobe_trampoline > */ > __used __visible void *trampoline_handler(struct pt_regs *regs) > { > - struct kprobe_ctlblk *kcb; > struct kretprobe_instance *ri = NULL; > struct hlist_head *head, empty_rp; > struct hlist_node *tmp; > @@ -772,16 +767,12 @@ __used __visible void *trampoline_handler(struct pt_regs *regs) > void *frame_pointer; > bool skipped = false; > > - preempt_disable(); > - > /* > * Set a dummy kprobe for avoiding kretprobe recursion. > * Since kretprobe never run in kprobe handler, kprobe must not > * be running at this point. > */ > - kcb = get_kprobe_ctlblk(); > - __this_cpu_write(current_kprobe, &kretprobe_kprobe); > - kcb->kprobe_status = KPROBE_HIT_ACTIVE; > + kprobe_busy_begin(); > > INIT_HLIST_HEAD(&empty_rp); > kretprobe_hash_lock(current, &head, &flags); > @@ -857,7 +848,7 @@ __used __visible void *trampoline_handler(struct pt_regs *regs) > __this_cpu_write(current_kprobe, &ri->rp->kp); > ri->ret_addr = correct_ret_addr; > ri->rp->handler(ri, regs); > - __this_cpu_write(current_kprobe, &kretprobe_kprobe); > + __this_cpu_write(current_kprobe, &kprobe_busy); > } > > recycle_rp_inst(ri, &empty_rp); > @@ -873,8 +864,7 @@ __used __visible void *trampoline_handler(struct pt_regs *regs) > > kretprobe_hash_unlock(current, &flags); > > - __this_cpu_write(current_kprobe, NULL); > - preempt_enable(); > + kprobe_busy_end(); > > hlist_for_each_entry_safe(ri, tmp, &empty_rp, hlist) { > hlist_del(&ri->hlist); > diff --git a/include/linux/kprobes.h b/include/linux/kprobes.h > index 04bdaf01112c..645fd401c856 100644 > --- a/include/linux/kprobes.h > +++ b/include/linux/kprobes.h > @@ -350,6 +350,10 @@ static inline struct kprobe_ctlblk *get_kprobe_ctlblk(void) > return this_cpu_ptr(&kprobe_ctlblk); > } > > +extern struct kprobe kprobe_busy; > +void kprobe_busy_begin(void); > +void kprobe_busy_end(void); > + > kprobe_opcode_t *kprobe_lookup_name(const char *name, unsigned int offset); > int register_kprobe(struct kprobe *p); > void unregister_kprobe(struct kprobe *p); > diff --git a/kernel/kprobes.c b/kernel/kprobes.c > index 2625c241ac00..75bb4a8458e7 100644 > --- a/kernel/kprobes.c > +++ b/kernel/kprobes.c > @@ -1236,6 +1236,26 @@ __releases(hlist_lock) > } > NOKPROBE_SYMBOL(kretprobe_table_unlock); > > +struct kprobe kprobe_busy = { > + .addr = (void *) get_kprobe, > +}; > + > +void kprobe_busy_begin(void) > +{ > + struct kprobe_ctlblk *kcb; > + > + preempt_disable(); > + __this_cpu_write(current_kprobe, &kprobe_busy); > + kcb = get_kprobe_ctlblk(); > + kcb->kprobe_status = KPROBE_HIT_ACTIVE; > +} > + > +void kprobe_busy_end(void) > +{ > + __this_cpu_write(current_kprobe, NULL); > + preempt_enable(); > +} > + > /* > * This function is called from finish_task_switch when task tk becomes dead, > * so that we can recycle any function-return probe instances associated > @@ -1253,6 +1273,8 @@ void kprobe_flush_task(struct task_struct *tk) > /* Early boot. kretprobe_table_locks not yet initialized. */ > return; > > + kprobe_busy_begin(); > + > INIT_HLIST_HEAD(&empty_rp); > hash = hash_ptr(tk, KPROBE_HASH_BITS); > head = &kretprobe_inst_table[hash]; > @@ -1266,6 +1288,8 @@ void kprobe_flush_task(struct task_struct *tk) > hlist_del(&ri->hlist); > kfree(ri); > } > + > + kprobe_busy_end(); > } > NOKPROBE_SYMBOL(kprobe_flush_task); > > -- > 2.18.2 > -- Masami Hiramatsu <mhiramat(a)kernel.org>

5 years, 7 months

[PATCH] arm64: tegra: Fix ethernet phy-mode for Jetson Xavier

by Jon Hunter

The 'phy-mode' property is currently defined as 'rgmii' for Jetson Xavier. This indicates that the RGMII RX and TX delays are set by the MAC and the internal delays set by the PHY are not used. If the Marvell PHY driver is enabled, such that it is used and not the generic PHY, ethernet failures are seen (DHCP is failing to obtain an IP address) and this is caused because the Marvell PHY driver is disabling the internal RX and TX delays. For Jetson Xavier the internal PHY RX and TX delay should be used and so fix this by setting the 'phy-mode' to 'rgmii-id' and not 'rgmii'. Cc: stable(a)vger.kernel.org Signed-off-by: Jon Hunter <jonathanh(a)nvidia.com> --- arch/arm64/boot/dts/nvidia/tegra194-p2888.dtsi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm64/boot/dts/nvidia/tegra194-p2888.dtsi b/arch/arm64/boot/dts/nvidia/tegra194-p2888.dtsi index 623f7d7d216b..8e3136dfdd62 100644 --- a/arch/arm64/boot/dts/nvidia/tegra194-p2888.dtsi +++ b/arch/arm64/boot/dts/nvidia/tegra194-p2888.dtsi @@ -33,7 +33,7 @@ phy-reset-gpios = <&gpio TEGRA194_MAIN_GPIO(G, 5) GPIO_ACTIVE_LOW>; phy-handle = <&phy>; - phy-mode = "rgmii"; + phy-mode = "rgmii-id"; mdio { #address-cells = <1>; -- 2.17.1

5 years, 7 months

[PATCH 4/9] lpfc: Fix negation of else clause in lpfc_prep_node_fc4type

by James Smart

Implementation of a previous patch added a condition to an if check that always end up with the if test being true. Execution of the else clause was inadvertantly negated. The additional condition check was incorrect and unnecessary after the other modifications had been done in that patch. Remove the check from the if series. Fixes: b95b21193c85 ("scsi: lpfc: Fix loss of remote port after devloss due to lack of RPIs") Cc: <stable(a)vger.kernel.org> # v5.4+ Signed-off-by: Dick Kennedy <dick.kennedy(a)broadcom.com> Signed-off-by: James Smart <jsmart2021(a)gmail.com> --- drivers/scsi/lpfc/lpfc_ct.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/scsi/lpfc/lpfc_ct.c b/drivers/scsi/lpfc/lpfc_ct.c index 2aa578d20f8c..7fce73c39c1c 100644 --- a/drivers/scsi/lpfc/lpfc_ct.c +++ b/drivers/scsi/lpfc/lpfc_ct.c @@ -462,7 +462,6 @@ lpfc_prep_node_fc4type(struct lpfc_vport *vport, uint32_t Did, uint8_t fc4_type) struct lpfc_nodelist *ndlp; if ((vport->port_type != LPFC_NPIV_PORT) || - (fc4_type == FC_TYPE_FCP) || !(vport->ct_flags & FC_CT_RFF_ID) || !vport->cfg_restrict_login) { ndlp = lpfc_setup_disc_node(vport, Did); -- 2.26.1

5 years, 7 months

patch "usb: chipidea: msm: Ensure proper controller reset using role switch" added to usb-linus

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled usb: chipidea: msm: Ensure proper controller reset using role switch to my usb git tree which can be found at git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git in the usb-linus branch. The patch will show up in the next release of the linux-next tree (usually sometime within the next 24 hours during the week.) The patch will hopefully also be merged in Linus's tree for the next -rc kernel release. If you have any questions about this process, please let me know. >From 91edf63d5022bd0464788ffb4acc3d5febbaf81d Mon Sep 17 00:00:00 2001 From: Bryan O'Donoghue <bryan.odonoghue(a)linaro.org> Date: Thu, 7 May 2020 08:49:18 +0800 Subject: usb: chipidea: msm: Ensure proper controller reset using role switch API Currently we check to make sure there is no error state on the extcon handle for VBUS when writing to the HS_PHY_GENCONFIG_2 register. When using the USB role-switch API we still need to write to this register absent an extcon handle. This patch makes the appropriate update to ensure the write happens if role-switching is true. Fixes: 05559f10ed79 ("usb: chipidea: add role switch class support") Cc: stable <stable(a)vger.kernel.org> Cc: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Cc: Philipp Zabel <p.zabel(a)pengutronix.de> Cc: linux-usb(a)vger.kernel.org Cc: linux-kernel(a)vger.kernel.org Cc: Stephen Boyd <swboyd(a)chromium.org> Signed-off-by: Bryan O'Donoghue <bryan.odonoghue(a)linaro.org> Signed-off-by: Peter Chen <peter.chen(a)nxp.com> Link: https://lore.kernel.org/r/20200507004918.25975-2-peter.chen@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/usb/chipidea/ci_hdrc_msm.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/usb/chipidea/ci_hdrc_msm.c b/drivers/usb/chipidea/ci_hdrc_msm.c index af648ba6544d..46105457e1ca 100644 --- a/drivers/usb/chipidea/ci_hdrc_msm.c +++ b/drivers/usb/chipidea/ci_hdrc_msm.c @@ -114,7 +114,7 @@ static int ci_hdrc_msm_notify_event(struct ci_hdrc *ci, unsigned event) hw_write_id_reg(ci, HS_PHY_GENCONFIG_2, HS_PHY_ULPI_TX_PKT_EN_CLR_FIX, 0); - if (!IS_ERR(ci->platdata->vbus_extcon.edev)) { + if (!IS_ERR(ci->platdata->vbus_extcon.edev) || ci->role_switch) { hw_write_id_reg(ci, HS_PHY_GENCONFIG_2, HS_PHY_SESS_VLD_CTRL_EN, HS_PHY_SESS_VLD_CTRL_EN); -- 2.26.2

5 years, 7 months

stable-rc/linux-4.4.y boot: 43 boots: 2 failed, 33 passed with 2 offline, 4 untried/unknown, 2 conflicts (v4.4.222-166-g7ab45cabed0b)

by kernelci.org bot

stable-rc/linux-4.4.y boot: 43 boots: 2 failed, 33 passed with 2 offline, 4 untried/unknown, 2 conflicts (v4.4.222-166-g7ab45cabed0b) Full Boot Summary: https://kernelci.org/boot/all/job/stable-rc/branch/linux-4.4.y/kernel/v4.4.… Full Build Summary: https://kernelci.org/build/stable-rc/branch/linux-4.4.y/kernel/v4.4.222-166… Tree: stable-rc Branch: linux-4.4.y Git Describe: v4.4.222-166-g7ab45cabed0b Git Commit: 7ab45cabed0becc5018c917eb494b860da28dd02 Git URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git Tested: 34 unique boards, 10 SoC families, 14 builds out of 190 Boot Regressions Detected: arm: qcom_defconfig: gcc-8: qcom-apq8064-cm-qs600: lab-baylibre-seattle: failing since 88 days (last pass: v4.4.212-56-g758a39807529 - first fail: v4.4.213-28-ga3b43e6eae91) i386: i386_defconfig: gcc-8: qemu_i386: lab-baylibre: new failure (last pass: v4.4.222) x86_64: x86_64_defconfig: gcc-8: qemu_x86_64: lab-baylibre: new failure (last pass: v4.4.222) Boot Failures Detected: arm: multi_v5_defconfig: gcc-8: imx27-phytec-phycard-s-rdk: 1 failed lab imx_v4_v5_defconfig: gcc-8: imx27-phytec-phycard-s-rdk: 1 failed lab Offline Platforms: arm: qcom_defconfig: gcc-8 qcom-apq8064-cm-qs600: 1 offline lab exynos_defconfig: gcc-8 exynos5800-peach-pi: 1 offline lab Conflicting Boot Failures Detected: (These likely are not failures as other labs are reporting PASS. Needs review.) i386: i386_defconfig: qemu_i386: lab-baylibre: FAIL (gcc-8) lab-collabora: PASS (gcc-8) x86_64: x86_64_defconfig: qemu_x86_64: lab-baylibre: FAIL (gcc-8) lab-collabora: PASS (gcc-8) --- For more info write to <info(a)kernelci.org>

5 years, 7 months

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror