Re: [PATCH] powerpc/mm/radix: add missing braces for single statement block
On 04/08/2018 12:44 PM, Mathieu Malaterre wrote:
> In commit 7a22d6321c3d ("powerpc/mm/radix: Update command line parsing for
> disable_radix") an `if` statement was added for a possible empty body
> (prom_debug).
>
> Fix the following warning, treated as error with W=1:
>
> arch/powerpc/kernel/prom_init.c:656:46: error: suggest braces around empty
> body in an ‘if’ statement [-Werror=empty-body]
>
> Signed-off-by: Mathieu Malaterre
> ---
> arch/powerpc/kernel/prom_init.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/arch/powerpc/kernel/prom_init.c b/arch/powerpc/kernel/prom_init.c
> index 5ae153b97d0a..f0e802495530 100644
> --- a/arch/powerpc/kernel/prom_init.c
> +++ b/arch/powerpc/kernel/prom_init.c
> @@ -652,8 +652,9 @@ static void __init early_cmdline_parse(void)
> } else
> prom_radix_disable = true;
> }
> - if (prom_radix_disable)
> + if (prom_radix_disable) {
> prom_debug("Radix disabled from cmdline\n");
Looks like the macro for #prom_debug() should be fixed instead.
> + }
> }
>
> #if defined(CONFIG_PPC_PSERIES) || defined(CONFIG_PPC_POWERNV)
>
--
~Randy
[PATCH 2/2] firmware: bcm47xx_nvram: support small (0x6000 B) NVRAM partitions
From: Rafał Miłecki
Some old devices with 4 MiB flashes were using 0x1000 block size and
could use smaller (0x6000 bytes) flash partition for storing NVRAM
content. This adds support for reading NVRAM on Netgear WNR1000 V3.
Signed-off-by: Rafał Miłecki
---
drivers/firmware/broadcom/bcm47xx_nvram.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/firmware/broadcom/bcm47xx_nvram.c
b/drivers/firmware/broadcom/bcm47xx_nvram.c
index 0b631e5b5b84..d25f080fcb0d 100644
--- a/drivers/firmware/broadcom/bcm47xx_nvram.c
+++ b/drivers/firmware/broadcom/bcm47xx_nvram.c
@@ -36,7 +36,7 @@ struct nvram_header {
static char nvram_buf[NVRAM_SPACE];
static size_t nvram_len;
-static const u32 nvram_sizes[] = {0x8000, 0xF000, 0x1};
+static const u32 nvram_sizes[] = {0x6000, 0x8000, 0xF000, 0x1};
static u32 find_nvram_size(void __iomem *end)
{
--
2.11.0
[PATCH 1/2] MIPS: BCM47XX: Add support for Netgear WNR1000 V3
From: Rafał Miłecki
This adds support for detecting this model board and registers some LEDs
and buttons.
There are two uncommon things regarding this device:
1) It can use two different "board_id" ID values.
Unit I have uses "U12H139T00_NETGEAR" value. This magic is also used
in firmware file header. There are two reports (one from an OpenWrt
user) of a different "U12H139T50_NETGEAR" magic though.
2) Power LEDs share GPIOs with buttons.
Amber one seems to share GPIO 2 with WPS button and green one seems
to share GPIO 3 with reset button. It remains unknown how to support
them and handle buttons at the same time. For that reason they aren't
added to the list of supported LEDs.
Signed-off-by: Rafał Miłecki
---
arch/mips/bcm47xx/board.c | 2 ++
arch/mips/bcm47xx/buttons.c| 9 +
arch/mips/bcm47xx/leds.c | 9 +
arch/mips/include/asm/mach-bcm47xx/bcm47xx_board.h | 1 +
4 files changed, 21 insertions(+)
diff --git a/arch/mips/bcm47xx/board.c b/arch/mips/bcm47xx/board.c
index edfaef0d73a4..a80910d2738c 100644
--- a/arch/mips/bcm47xx/board.c
+++ b/arch/mips/bcm47xx/board.c
@@ -172,6 +172,8 @@ struct bcm47xx_board_type_list1
bcm47xx_board_list_board_id[] __initconst = {
{{BCM47XX_BOARD_NETGEAR_WNDR4000, "Netgear WNDR4000"},
"U12H181T00_NETGEAR"},
{{BCM47XX_BOARD_NETGEAR_WNDR4500V1, "Netgear WNDR4500 V1"},
"U12H189T00_NETGEAR"},
{{BCM47XX_BOARD_NETGEAR_WNDR4500V2, "Netgear WNDR4500 V2"},
"U12H224T00_NETGEAR"},
+ {{BCM47XX_BOARD_NETGEAR_WNR1000_V3, "Netgear WNR1000 V3"},
"U12H139T00_NETGEAR"},
+ {{BCM47XX_BOARD_NETGEAR_WNR1000_V3, "Netgear WNR1000 V3"},
"U12H139T50_NETGEAR"},
{{BCM47XX_BOARD_NETGEAR_WNR2000, "Netgear WNR2000"},
"U12H114T00_NETGEAR"},
{{BCM47XX_BOARD_NETGEAR_WNR3500L, "Netgear WNR3500L"},
"U12H136T99_NETGEAR"},
{{BCM47XX_BOARD_NETGEAR_WNR3500U, "Netgear WNR3500U"},
"U12H136T00_NETGEAR"},
diff --git a/arch/mips/bcm47xx/buttons.c b/arch/mips/bcm47xx/buttons.c
index 88d400d256c4..977990a609ba 100644
--- a/arch/mips/bcm47xx/buttons.c
+++ b/arch/mips/bcm47xx/buttons.c
@@ -412,6 +412,12 @@ bcm47xx_buttons_netgear_wndr4500v1[] __initconst = {
};
static const struct gpio_keys_button
+bcm47xx_buttons_netgear_wnr1000_v3[] __initconst = {
+ BCM47XX_GPIO_KEY(2, KEY_WPS_BUTTON),
+ BCM47XX_GPIO_KEY(3, KEY_RESTART),
+};
+
+static const struct gpio_keys_button
bcm47xx_buttons_netgear_wnr3500lv1[] __initconst = {
BCM47XX_GPIO_KEY(4, KEY_RESTART),
BCM47XX_GPIO_KEY(6, KEY_WPS_BUTTON),
@@ -670,6 +676,9 @@ int __init bcm47xx_buttons_register(void)
case BCM47XX_BOARD_NETGEAR_WNDR4500V1:
err = bcm47xx_copy_bdata(bcm47xx_buttons_netgear_wndr4500v1);
break;
+ case BCM47XX_BOARD_NETGEAR_WNR1000_V3:
+ err = bcm47xx_copy_bdata(bcm47xx_buttons_netgear_wnr1000_v3);
+ break;
case BCM47XX_BOARD_NETGEAR_WNR3500L:
err = bcm47xx_copy_bdata(bcm47xx_buttons_netgear_wnr3500lv1);
break;
diff --git a/arch/mips/bcm47xx/leds.c b/arch/mips/bcm47xx/leds.c
index 34a7b3fbdfd9..3fe015602945 100644
--- a/arch/mips/bcm47xx/leds.c
+++ b/arch/mips/bcm47xx/leds.c
@@ -498,6 +498,12 @@ bcm47xx_leds_netgear_wndr4500v1[] __initconst = {
};
static const struct gpio_led
+bcm47xx_leds_netgear_wnr1000_v3[] __initconst = {
+ BCM47XX_GPIO_LED(0, "blue", "wlan", 0, LEDS_GPIO_DEFSTATE_OFF),
+ BCM47XX_GPIO_LED(1, "green", "wps", 0, LEDS_GPIO_DEFSTATE_OFF),
+};
+
+static const struct gpio_led
bcm47xx_leds_netgear_wnr3500lv1[] __initconst = {
BCM47XX_GPIO_LED(0, "blue", "wlan", 1, LEDS_GPIO_DEFSTATE_OFF),
BCM47XX_GPIO_LED(1, "green", "wps", 1, LEDS_GPIO_DEFSTATE_OFF),
@@ -758,6 +764,9 @@ void __init bcm47xx_leds_register(void)
case BCM47XX_BOARD_NETGEAR_WNDR4500V1:
bcm47xx_set_pdata(bcm47xx_leds_netgear_wndr4500v1);
break;
+ case BCM47XX_BOARD_NETGEAR_WNR1000_V3:
+ bcm47xx_set_pdata(bcm47xx_leds_netgear_wnr1000_v3);
+ break;
case BCM47XX_BOARD_NETGEAR_WNR3500L:
bcm47xx_set_pdata(bcm47xx_leds_netgear_wnr3500lv1);
break;
diff --git a/arch/mips/include/asm/mach-bcm47xx/bcm47xx_board.h
b/arch/mips/include/asm/mach-bcm47xx/bcm47xx_board.h
index cbf9da7f2f94..0ef8893e07f8 100644
--- a/arch/mips/include/asm/mach-bcm47xx/bcm47xx_board.h
+++ b/arch/mips/include/asm/mach-bcm47xx/bcm47xx_board.h
@@ -110,6 +110,7 @@ enum bcm47xx_board {
BCM47XX_BOARD_NETGEAR_WNDR4000,
BCM47XX_BOARD_NETGEAR_WNDR4500V1,
BCM47XX_BOARD_NETGEAR_WNDR4500V2,
+ BCM47XX_BOARD_NETGEAR_WNR1000_V3,
BCM47XX_BOARD_NETGEAR_WNR2000,
BCM47XX_BOARD_NETGEAR_WNR3500L,
BCM47XX_BOARD_NETGEAR_WNR3500U,
--
2.11.0
Re: rcu_process_callbacks irqsoff latency caused by taking spinlock with irqs disabled
On Sat, Apr 07, 2018 at 07:40:42AM +1000, Nicholas Piggin wrote:
> On Thu, 5 Apr 2018 08:53:20 -0700
> "Paul E. McKenney" wrote:
>
> > On Thu, Apr 05, 2018 at 10:45:12AM +1000, Nicholas Piggin wrote:
> > > On Wed, 4 Apr 2018 17:13:58 -0700
> > > "Paul E. McKenney" wrote:
> > >
> > > > On Thu, Apr 05, 2018 at 09:34:14AM +1000, Nicholas Piggin wrote:
> > > > > Hi Paul,
> > > > >
> > > > > Just looking at latencies, and RCU showed up as one of the maximums.
> > > > > This is a 2 socket system with (176 CPU threads). Just doing a
> > > > > `make -j 352` kernel build. Got a max latency of 3ms. I don't think
> > > > > that's anything to worry about really, but I wanted to check the
> > > > > cause.
> > > >
> > > > Well, that 3 milliseconds would cause serious problems for some
> > > > workloads...
> > >
> > > True.
> > >
> > > > > # tracer: irqsoff
> > > > > #
> > > > > # irqsoff latency trace v1.1.5 on 4.16.0-01530-g43d1859f0994
> > > > > #
> > > > > # latency: 3055 us, #19/19, CPU#135 | (M:server VP:0, KP:0, SP:0 HP:0
> > > > > #P:176)
> > > > > #-
> > > > > #| task: cc1-58689 (uid:1003 nice:0 policy:0 rt_prio:0)
> > > > > #-
> > > > > # => started at: rcu_process_callbacks
> > > > > # => ended at: _raw_spin_unlock_irqrestore
> > > > > #
> > > > > #
> > > > > # _--=> CPU#
> > > > > # / _-=> irqs-off
> > > > > #| / _=> need-resched
> > > > > #|| / _---=> hardirq/softirq
> > > > > #||| / _--=> preempt-depth
> > > > > # / delay
> > > > > # cmd pid | time | caller
> > > > > # \ / | \| /
> > > > ><...>-58689 135d.s.0us : rcu_process_callbacks
> > > > ><...>-58689 135d.s.1us : cpu_needs_another_gp
> > > > > <-rcu_process_callbacks
> > > > ><...>-58689 135d.s.2us : rcu_segcblist_future_gp_needed
> > > > > <-cpu_needs_another_gp
> > > > ><...>-58689 135d.s.3us#: _raw_spin_lock <-rcu_process_callbacks
> > > > ><...>-58689 135d.s. 3047us : rcu_start_gp <-rcu_process_callbacks
> > > > ><...>-58689 135d.s. 3048us : rcu_advance_cbs <-rcu_start_gp
> > > > ><...>-58689 135d.s. 3049us : rcu_segcblist_pend_cbs
> > > > > <-rcu_advance_cbs
> > > > ><...>-58689 135d.s. 3049us : rcu_segcblist_advance
> > > > > <-rcu_advance_cbs
> > > > ><...>-58689 135d.s. 3050us : rcu_accelerate_cbs <-rcu_start_gp
> > > > ><...>-58689 135d.s. 3050us : rcu_segcblist_pend_cbs
> > > > > <-rcu_accelerate_cbs
> > > > ><...>-58689 135d.s. 3051us : rcu_segcblist_accelerate
> > > > > <-rcu_accelerate_cbs
> > > > ><...>-58689 135d.s. 3052us : trace_rcu_future_gp.isra.0
> > > > > <-rcu_accelerate_cbs
> > > > ><...>-58689 135d.s. 3052us : trace_rcu_future_gp.isra.0
> > > > > <-rcu_accelerate_cbs
> > > > ><...>-58689 135d.s. 3053us : rcu_start_gp_advanced.isra.35
> > > > > <-rcu_start_gp
> > > > ><...>-58689 135d.s. 3053us : cpu_needs_another_gp
> > > > > <-rcu_start_gp_advanced.isra.35
> > > > ><...>-58689 135d.s. 3054us : _raw_spin_unlock_irqrestore
> > > > > <-rcu_process_callbacks
> > > > ><...>-58689 135d.s. 3055us : _raw_spin_unlock_irqrestore
> > > > ><...>-58689 135d.s. 3056us : trace_hardirqs_on
> > > > > <-_raw_spin_unlock_irqrestore
> > > > ><...>-58689 135d.s. 3061us :
> > > > >
> > > > > So it's taking a contende lock with interrupts disabled:
> > > > >
> > > > > static void
> > > > > __rcu_process_callbacks(struct rcu_state *rsp)
> > > > > {
> > > > > unsigned long flags;
> > > > > bool needwake;
> > > > > struct rcu_data *rdp = raw_cpu_ptr(rsp->rda);
> > > > >
> > > > > WARN_ON_ONCE(!rdp->beenonline);
> > > > >
> > > > > /* Update RCU state based on any recent quiescent states. */
> > > > > rcu_check_quiescent_state(rsp, rdp);
> > > > >
> > > > > /* Does this CPU require a not-yet-started grace period? */
> > > > > local_irq_save(flags);
> > > > > if (cpu_needs_another_gp(rsp, rdp)) {
> > > > > raw_spin_lock_rcu_node(rcu_get_root(rsp)); /* irqs
> > > > > disabled. */
> > > > > needwake = rcu_start_gp(rsp);
> > > > >
> > > > > raw_spin_unlock_irqrestore_rcu_node(rcu_get_root(rsp), flags);
> > > > > if (needwake)
> > > > > rcu_gp_kthread_wake(rsp);
> > > > > } else {
> > > > > local_irq_restore(flags);
> > > > > }
> > > > >
> > > > > Because irqs are disabled before taking the lock, we can't spin with
> > > > > interrupts enabled.
> > > > >
> > > > > cpu_needs_another_gp needs interrupts off to prevent races with normal
> > > > > callback registry, but that doesn't seem to be preventing any wider
> > > >
Re: [PATCH bpf-next v8 05/11] seccomp,landlock: Enforce Landlock programs per process hierarchy
On Sun, Apr 8, 2018 at 6:13 AM, Mickaël Salaün wrote:
>
> On 02/27/2018 10:48 PM, Mickaël Salaün wrote:
>>
>> On 27/02/2018 17:39, Andy Lutomirski wrote:
>>> On Tue, Feb 27, 2018 at 5:32 AM, Alexei Starovoitov
>>> wrote:
On Tue, Feb 27, 2018 at 05:20:55AM +, Andy Lutomirski wrote:
> On Tue, Feb 27, 2018 at 4:54 AM, Alexei Starovoitov
> wrote:
>> On Tue, Feb 27, 2018 at 04:40:34AM +, Andy Lutomirski wrote:
>>> On Tue, Feb 27, 2018 at 2:08 AM, Alexei Starovoitov
>>> wrote:
On Tue, Feb 27, 2018 at 01:41:15AM +0100, Mickaël Salaün wrote:
> The seccomp(2) syscall can be used by a task to apply a Landlock
> program
> to itself. As a seccomp filter, a Landlock program is enforced for the
> current task and all its future children. A program is immutable and a
> task can only add new restricting programs to itself, forming a list
> of
> programss.
>
> A Landlock program is tied to a Landlock hook. If the action on a
> kernel
> object is allowed by the other Linux security mechanisms (e.g. DAC,
> capabilities, other LSM), then a Landlock hook related to this kind of
> object is triggered. The list of programs for this hook is then
> evaluated. Each program return a 32-bit value which can deny the
> action
> on a kernel object with a non-zero value. If every programs of the
> list
> return zero, then the action on the object is allowed.
>
> Multiple Landlock programs can be chained to share a 64-bits value
> for a
> call chain (e.g. evaluating multiple elements of a file path). This
> chaining is restricted when a process construct this chain by loading
> a
> program, but additional checks are performed when it requests to apply
> this chain of programs to itself. The restrictions ensure that it is
> not possible to call multiple programs in a way that would imply to
> handle multiple shared values (i.e. cookies) for one chain. For now,
> only a fs_pick program can be chained to the same type of program,
> because it may make sense if they have different triggers (cf. next
> commits). This restrictions still allows to reuse Landlock programs
> in
> a safe way (e.g. use the same loaded fs_walk program with multiple
> chains of fs_pick programs).
>
> Signed-off-by: Mickaël Salaün
...
> +struct landlock_prog_set *landlock_prepend_prog(
> + struct landlock_prog_set *current_prog_set,
> + struct bpf_prog *prog)
> +{
> + struct landlock_prog_set *new_prog_set = current_prog_set;
> + unsigned long pages;
> + int err;
> + size_t i;
> + struct landlock_prog_set tmp_prog_set = {};
> +
> + if (prog->type != BPF_PROG_TYPE_LANDLOCK_HOOK)
> + return ERR_PTR(-EINVAL);
> +
> + /* validate memory size allocation */
> + pages = prog->pages;
> + if (current_prog_set) {
> + size_t i;
> +
> + for (i = 0; i < ARRAY_SIZE(current_prog_set->programs);
> i++) {
> + struct landlock_prog_list *walker_p;
> +
> + for (walker_p = current_prog_set->programs[i];
> + walker_p; walker_p =
> walker_p->prev)
> + pages += walker_p->prog->pages;
> + }
> + /* count a struct landlock_prog_set if we need to
> allocate one */
> + if (refcount_read(¤t_prog_set->usage) != 1)
> + pages += round_up(sizeof(*current_prog_set),
> PAGE_SIZE)
> + / PAGE_SIZE;
> + }
> + if (pages > LANDLOCK_PROGRAMS_MAX_PAGES)
> + return ERR_PTR(-E2BIG);
> +
> + /* ensure early that we can allocate enough memory for the new
> + * prog_lists */
> + err = store_landlock_prog(&tmp_prog_set, current_prog_set,
> prog);
> + if (err)
> + return ERR_PTR(err);
> +
> + /*
> + * Each task_struct points to an array of prog list pointers.
> These
> + * tables are duplicated when additions are made (which means
> each
> + * table needs to be refcounted for the processes using it).
> When a new
> + * table is created, all the refcounters on the prog_list are
> bumped (to
> + * track each table that references the prog). When a new prog
>>>
Re: [PATCH v4 1/3] locking: Document the semantics of spin_is_locked()
On Fri, Apr 06, 2018 at 11:58:25PM +0200, Andrea Parri wrote:
> On Fri, Apr 06, 2018 at 02:08:16PM -0700, Randy Dunlap wrote:
> > On 04/06/2018 02:07 PM, Paul E. McKenney wrote:
> > > On Fri, Apr 06, 2018 at 02:01:41PM -0700, Randy Dunlap wrote:
> > >> On 04/06/2018 12:47 PM, Andrea Parri wrote:
> > >>> There appeared to be a certain, recurrent uncertainty concerning the
> > >>> semantics of spin_is_locked(), likely a consequence of the fact that
> > >>> this semantics remains undocumented or that it has been historically
> > >>> linked to the (likewise unclear) semantics of spin_unlock_wait().
> > >>>
> > >>> A recent auditing [1] of the callers of the primitive confirmed that
> > >>> none of them are relying on particular ordering guarantees; document
> > >>> this semantics by adding a docbook header to spin_is_locked(). Also,
> > >>> describe behaviors specific to certain CONFIG_SMP=n builds.
> > >>>
> > >>> [1] https://marc.info/?l=linux-kernel&m=151981440005264&w=2
> > >>> https://marc.info/?l=linux-kernel&m=152042843808540&w=2
> > >>> https://marc.info/?l=linux-kernel&m=152043346110262&w=2
> > >>>
> > >>> Co-Developed-by: Andrea Parri
> > >>> Co-Developed-by: Alan Stern
> > >>> Co-Developed-by: David Howells
> > >>> Signed-off-by: Andrea Parri
> > >>> Signed-off-by: Alan Stern
> > >>> Signed-off-by: David Howells
> > >>> Cc: Will Deacon
> > >>> Cc: Peter Zijlstra
> > >>> Cc: Boqun Feng
> > >>> Cc: Nicholas Piggin
> > >>> Cc: Jade Alglave
> > >>> Cc: Luc Maranget
> > >>> Cc: "Paul E. McKenney"
> > >>> Cc: Akira Yokosawa
> > >>> Cc: Ingo Molnar
> > >>> ---
> > >>> include/linux/spinlock.h | 18 ++
> > >>> 1 file changed, 18 insertions(+)
> > >>>
> > >>> diff --git a/include/linux/spinlock.h b/include/linux/spinlock.h
> > >>> index 4894d322d2584..1e8a464358384 100644
> > >>> --- a/include/linux/spinlock.h
> > >>> +++ b/include/linux/spinlock.h
> > >>> @@ -380,6 +380,24 @@ static __always_inline int
> > >>> spin_trylock_irq(spinlock_t *lock)
> > >>> raw_spin_trylock_irqsave(spinlock_check(lock), flags); \
> > >>> })
> > >>>
> > >>> +/**
> > >>> + * spin_is_locked() - Check whether a spinlock is locked.
> > >>> + * @lock: Pointer to the spinlock.
> > >>> + *
> > >>> + * This function is NOT required to provide any memory ordering
> > >>> + * guarantees; it could be used for debugging purposes or, when
> > >>> + * additional synchronization is needed, accompanied with other
> > >>> + * constructs (memory barriers) enforcing the synchronization.
> > >>> + *
> > >>> + * Returns: 1 if @lock is locked, 0 otherwise.
> > >>
> > >> Sorry, minor nit:
> > >> s/Returns:/Return:/
> > >> (according to kernel-doc.rst)
> > >>
> > >> although I agree that "Returns:" is better.
> > >> [I should have changed that years ago.]
> > >
> > > Agreed, English grammar and templates often seem to conflict.
> > >
> > > So should we change this comment, or are you instead proposing to add
> > > "Returns:" as valid kernel-doc?
> >
> > Please change this patch to current doc syntax.
> > Any changes to kernel-doc syntax would come later.
Are you sure?
$ git grep "\* Returns:" | wc -l
2470
$ git grep "\* Return:" | wc -l
4144
Looks like more than a third of them are already "Returns:". ;-)
> Paul: I understand that you're going to do this change "in place"; please
> let me know if I'm wrong/if you need a new submission.
If Randy is certain that he would like to continue propagating
this grammatical infelicity, sure. ;-)
Thanx, Paul
> Thanks,
> Andrea
>
>
> >
> > Thanks.
> >
> > > Thanx, Paul
> > >
> > >>> + *
> > >>> + * Note that the function only tells you that the spinlock is
> > >>> + * seen to be locked, not that it is locked on your CPU.
> > >>> + *
> > >>> + * Further, on CONFIG_SMP=n builds with CONFIG_DEBUG_SPINLOCK=n,
> > >>> + * the return value is always 0 (see include/linux/spinlock_up.h).
> > >>> + * Therefore you should not rely heavily on the return value.
> > >>> + */
> > >>> static __always_inline int spin_is_locked(spinlock_t *lock)
> > >>> {
> > >>> return raw_spin_is_locked(&lock->rlock);
> > >>>
> > >>
> > >>
> > >> --
> > >> ~Randy
> > >>
> > >
> >
> >
> > --
> > ~Randy
>
Re: [PATCH] tools/memory-model: Update required version of herdtools7
On Sun, Apr 08, 2018 at 09:18:08AM +0900, Akira Yokosawa wrote: > >From 64542a47acf159d26b8290480c0af9c2a05d20d6 Mon Sep 17 00:00:00 2001 > From: Akira Yokosawa > Date: Sun, 8 Apr 2018 07:44:55 +0900 > Subject: [PATCH] tools/memory-model: Update required version of herdtools7 > > Code generated by klitmus7 version 7.48 doesn't compile with kernel > header of 4.15 and later due to the absence of ACCESS_ONCE(). > As the issue has been resolved in herdtools7 7.49, bump the required > version number in README. > > Signed-off-by: Akira Yokosawa > Cc: Alan Stern > Cc: Andrea Parri > Cc: Will Deacon > Cc: Peter Zijlstra > Cc: Boqun Feng > Cc: Nicholas Piggin > Cc: David Howells > Cc: Jade Alglave > Cc: Luc Maranget > Cc: "Paul E. McKenney" > Cc: Ingo Molnar > --- > Hi Paul, > > I think this is a 4.17 matter. > Thoughts? Good catch, queued and pushed, thank you! I don't believe that this needs to go into the current merge window, given that there is an easy workaround and that people running into this will likely find your patch via web-seach, at which point they can update their herdtools. But it should definitely go into v4.18! Thanx, Paul > Thanks, Akira > -- > tools/memory-model/README | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/tools/memory-model/README b/tools/memory-model/README > index 0b3a5f3..734f7fe 100644 > --- a/tools/memory-model/README > +++ b/tools/memory-model/README > @@ -20,7 +20,7 @@ that litmus test to be exercised within the Linux kernel. > REQUIREMENTS > > > -Version 7.48 of the "herd7" and "klitmus7" tools must be downloaded > +Version 7.49 of the "herd7" and "klitmus7" tools must be downloaded > separately: > >https://github.com/herd/herdtools7 > -- > 2.7.4 >
[PATCH] crypto: DRBG - guard uninstantion by lock
Am Sonntag, 8. April 2018, 17:41:17 CEST schrieb Dmitry Vyukov: Hi Dmitry, > > Hi, > > Here is config and kernel commit: > https://groups.google.com/d/msg/syzkaller-bugs/PINYyzoaG1s/ntZPOZdcCAAJ > You can also find compiler and image here if necessary: > https://github.com/google/syzkaller/blob/master/docs/syzbot.md > > And note that the program needs to be compiled with -m32. The bugs is > probably not-compat specific, but the program injects fault into a > particular malloc invocation and maybe malloc numbering is affected by > compat path. I am unable to reproduce the issue. But since you mention that you induce errors, I could see that the unlocking of the DRBG context is too soon. Can you please check whether the attached patch fixes the issue? Thanks ---8<--- In the error code path, the uninstantiation must be guarded by a lock to ensure that the modification of the context is fully atomic. Signed-off-by: Stephan Mueller Reported-by: syzkaller --- crypto/drbg.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/crypto/drbg.c b/crypto/drbg.c index 4faa2781c964..68c1949a253f 100644 --- a/crypto/drbg.c +++ b/crypto/drbg.c @@ -1510,8 +1510,8 @@ static int drbg_instantiate(struct drbg_state *drbg, struct drbg_string *pers, return ret; free_everything: - mutex_unlock(&drbg->drbg_mutex); drbg_uninstantiate(drbg); + mutex_unlock(&drbg->drbg_mutex); return ret; } -- 2.14.3
Re: [PATCH] MIPS: lantiq: gphy: Drop reboot/remove reset asserts
On Sun, Apr 8, 2018 at 10:30 AM, Mathias Kresin wrote:
> While doing a global software reset, these bits are not cleared and let
> some bootloader fail to initialise the GPHYs. The bootloader don't
> expect the GPHYs in reset, as they aren't during power on.
>
> The asserts were a workaround for a wrong syscon-reboot mask. With a
> mask set which includes the GPHY resets, these resets aren't required
> any more.
>
> Fixes: 126534141b45 ("MIPS: lantiq: Add a GPHY driver which uses the RCU
> syscon-mfd")
> Cc: sta...@vger.kernel.org # 4.14+
> Signed-off-by: Mathias Kresin
Acked-by: Martin Blumenstingl
thank you Mathias!
@Hauke: maybe you can also review this and give feedback?
> ---
> drivers/soc/lantiq/gphy.c | 34 --
> 1 file changed, 34 deletions(-)
>
> diff --git a/drivers/soc/lantiq/gphy.c b/drivers/soc/lantiq/gphy.c
> index 8d86594..8c31ae7 100644
> --- a/drivers/soc/lantiq/gphy.c
> +++ b/drivers/soc/lantiq/gphy.c
> @@ -30,7 +30,6 @@ struct xway_gphy_priv {
> struct clk *gphy_clk_gate;
> struct reset_control *gphy_reset;
> struct reset_control *gphy_reset2;
> - struct notifier_block gphy_reboot_nb;
> void __iomem *membase;
> char *fw_name;
> };
> @@ -64,24 +63,6 @@ static const struct of_device_id xway_gphy_match[] = {
> };
> MODULE_DEVICE_TABLE(of, xway_gphy_match);
>
> -static struct xway_gphy_priv *to_xway_gphy_priv(struct notifier_block *nb)
> -{
> - return container_of(nb, struct xway_gphy_priv, gphy_reboot_nb);
> -}
> -
> -static int xway_gphy_reboot_notify(struct notifier_block *reboot_nb,
> - unsigned long code, void *unused)
> -{
> - struct xway_gphy_priv *priv = to_xway_gphy_priv(reboot_nb);
> -
> - if (priv) {
> - reset_control_assert(priv->gphy_reset);
> - reset_control_assert(priv->gphy_reset2);
> - }
> -
> - return NOTIFY_DONE;
> -}
> -
> static int xway_gphy_load(struct device *dev, struct xway_gphy_priv *priv,
> dma_addr_t *dev_addr)
> {
> @@ -205,14 +186,6 @@ static int xway_gphy_probe(struct platform_device *pdev)
> reset_control_deassert(priv->gphy_reset);
> reset_control_deassert(priv->gphy_reset2);
>
> - /* assert the gphy reset because it can hang after a reboot: */
> - priv->gphy_reboot_nb.notifier_call = xway_gphy_reboot_notify;
> - priv->gphy_reboot_nb.priority = -1;
> -
> - ret = register_reboot_notifier(&priv->gphy_reboot_nb);
> - if (ret)
> - dev_warn(dev, "Failed to register reboot notifier\n");
> -
> platform_set_drvdata(pdev, priv);
>
> return ret;
> @@ -224,17 +197,10 @@ static int xway_gphy_remove(struct platform_device
> *pdev)
> struct xway_gphy_priv *priv = platform_get_drvdata(pdev);
> int ret;
>
> - reset_control_assert(priv->gphy_reset);
> - reset_control_assert(priv->gphy_reset2);
> -
> iowrite32be(0, priv->membase);
>
> clk_disable_unprepare(priv->gphy_clk_gate);
>
> - ret = unregister_reboot_notifier(&priv->gphy_reboot_nb);
> - if (ret)
> - dev_warn(dev, "Failed to unregister reboot notifier\n");
> -
> return 0;
> }
>
> --
> 2.7.4
>
Re: [PATCH v4 1/3] locking: Document the semantics of spin_is_locked()
On 04/08/2018 02:14 PM, Paul E. McKenney wrote: > On Fri, Apr 06, 2018 at 11:58:25PM +0200, Andrea Parri wrote: >> On Fri, Apr 06, 2018 at 02:08:16PM -0700, Randy Dunlap wrote: >>> On 04/06/2018 02:07 PM, Paul E. McKenney wrote: On Fri, Apr 06, 2018 at 02:01:41PM -0700, Randy Dunlap wrote: > On 04/06/2018 12:47 PM, Andrea Parri wrote: >> There appeared to be a certain, recurrent uncertainty concerning the >> semantics of spin_is_locked(), likely a consequence of the fact that >> this semantics remains undocumented or that it has been historically >> linked to the (likewise unclear) semantics of spin_unlock_wait(). >> >> A recent auditing [1] of the callers of the primitive confirmed that >> none of them are relying on particular ordering guarantees; document >> this semantics by adding a docbook header to spin_is_locked(). Also, >> describe behaviors specific to certain CONFIG_SMP=n builds. >> >> [1] https://marc.info/?l=linux-kernel&m=151981440005264&w=2 >> https://marc.info/?l=linux-kernel&m=152042843808540&w=2 >> https://marc.info/?l=linux-kernel&m=152043346110262&w=2 >> >> Co-Developed-by: Andrea Parri >> Co-Developed-by: Alan Stern >> Co-Developed-by: David Howells >> Signed-off-by: Andrea Parri >> Signed-off-by: Alan Stern >> Signed-off-by: David Howells >> Cc: Will Deacon >> Cc: Peter Zijlstra >> Cc: Boqun Feng >> Cc: Nicholas Piggin >> Cc: Jade Alglave >> Cc: Luc Maranget >> Cc: "Paul E. McKenney" >> Cc: Akira Yokosawa >> Cc: Ingo Molnar >> --- >> include/linux/spinlock.h | 18 ++ >> 1 file changed, 18 insertions(+) >> >> diff --git a/include/linux/spinlock.h b/include/linux/spinlock.h >> index 4894d322d2584..1e8a464358384 100644 >> --- a/include/linux/spinlock.h >> +++ b/include/linux/spinlock.h >> @@ -380,6 +380,24 @@ static __always_inline int >> spin_trylock_irq(spinlock_t *lock) >> raw_spin_trylock_irqsave(spinlock_check(lock), flags); \ >> }) >> >> +/** >> + * spin_is_locked() - Check whether a spinlock is locked. >> + * @lock: Pointer to the spinlock. >> + * >> + * This function is NOT required to provide any memory ordering >> + * guarantees; it could be used for debugging purposes or, when >> + * additional synchronization is needed, accompanied with other >> + * constructs (memory barriers) enforcing the synchronization. >> + * >> + * Returns: 1 if @lock is locked, 0 otherwise. > > Sorry, minor nit: > s/Returns:/Return:/ > (according to kernel-doc.rst) > > although I agree that "Returns:" is better. > [I should have changed that years ago.] Agreed, English grammar and templates often seem to conflict. So should we change this comment, or are you instead proposing to add "Returns:" as valid kernel-doc? >>> >>> Please change this patch to current doc syntax. >>> Any changes to kernel-doc syntax would come later. > > Are you sure? > > $ git grep "\* Returns:" | wc -l > 2470 > $ git grep "\* Return:" | wc -l > 4144 > > Looks like more than a third of them are already "Returns:". ;-) > >> Paul: I understand that you're going to do this change "in place"; please >> let me know if I'm wrong/if you need a new submission. > > If Randy is certain that he would like to continue propagating > this grammatical infelicity, sure. ;-) eh? Well, Documentation/doc-guide/kernel-doc.rst says "Return:", but it appears that it does not matter to scripts/kernel-doc -- it's just the name of a "section" of the documentation and can be spelled any way! oh well. :) Acked-by: Randy Dunlap Thanks. -- ~Randy
[PATCH v2] Kbuild: fix # escaping in .cmd files for future Make
I tried building using a freshly built Make (4.2.1-69-g8a731d1), but
already the objtool build broke with
orc_dump.c: In function ‘orc_dump’:
orc_dump.c:106:2: error: ‘elf_getshnum’ is deprecated
[-Werror=deprecated-declarations]
if (elf_getshdrnum(elf, &nr_sections)) {
Turns out that with that new Make, the backslash was not removed, so cpp
didn't see a #include directive, grep found nothing, and
-DLIBELF_USE_DEPRECATED was wrongly put in CFLAGS.
Now, that new Make behaviour is documented in their NEWS file:
* WARNING: Backward-incompatibility!
Number signs (#) appearing inside a macro reference or function invocation
no longer introduce comments and should not be escaped with backslashes:
thus a call such as:
foo := $(shell echo '#')
is legal. Previously the number sign needed to be escaped, for example:
foo := $(shell echo '\#')
Now this latter will resolve to "\#". If you want to write makefiles
portable to both versions, assign the number sign to a variable:
C := \#
foo := $(shell echo '$C')
This was claimed to be fixed in 3.81, but wasn't, for some reason.
To detect this change search for 'nocomment' in the .FEATURES variable.
This also fixes up the two make-cmd instances to replace # with $(pound)
rather than with \#. There might very well be other places that need
similar fixup in preparation for whatever future Make release contains
the above change, but at least this builds an x86_64 defconfig with the
new make.
Fixes: https://bugzilla.kernel.org/show_bug.cgi?id=197847
Cc: Randy Dunlap
Signed-off-by: Rasmus Villemoes
---
v2:
- squash the original objtool-only patch with the patch fixing up
make-cmd, to avoid repeating the reference to the Make NEWS.
- use $(pound) in .cmd files to avoid backslash-counting issues (Masahiro).
- add bugzilla link (Randy).
scripts/Kbuild.include | 5 +++--
tools/build/Build.include | 5 +++--
tools/objtool/Makefile | 2 +-
tools/scripts/Makefile.include | 2 ++
4 files changed, 9 insertions(+), 5 deletions(-)
diff --git a/scripts/Kbuild.include b/scripts/Kbuild.include
index cce31ee876b6..50cee534fd64 100644
--- a/scripts/Kbuild.include
+++ b/scripts/Kbuild.include
@@ -10,6 +10,7 @@ space := $(empty) $(empty)
space_escape := _-_SPACE_-_
right_paren := )
left_paren := (
+pound := \#
###
# Name of target with a '.' as filename prefix. foo/bar.o => foo/.bar.o
@@ -322,11 +323,11 @@ endif
# Replace >$< with >$$< to preserve $ when reloading the .cmd file
# (needed for make)
-# Replace >#< with >\#< to avoid starting a comment in the .cmd file
+# Replace >#< with >$(pound)< to avoid starting a comment in the .cmd file
# (needed for make)
# Replace >'< with >'\''< to be able to enclose the whole string in '...'
# (needed for the shell)
-make-cmd = $(call escsq,$(subst \#,\\\#,$(subst $$,,$(cmd_$(1)
+make-cmd = $(call escsq,$(subst $(pound),$$(pound),$(subst
$$,,$(cmd_$(1)
# Find any prerequisites that is newer than target or that does not exist.
# PHONY targets skipped in both cases.
diff --git a/tools/build/Build.include b/tools/build/Build.include
index 418871d02ebf..a4bbb984941d 100644
--- a/tools/build/Build.include
+++ b/tools/build/Build.include
@@ -12,6 +12,7 @@
# Convenient variables
comma := ,
squote := '
+pound := \#
###
# Name of target with a '.' as filename prefix. foo/bar.o => foo/.bar.o
@@ -43,11 +44,11 @@ echo-cmd = $(if $($(quiet)cmd_$(1)),\
###
# Replace >$< with >$$< to preserve $ when reloading the .cmd file
# (needed for make)
-# Replace >#< with >\#< to avoid starting a comment in the .cmd file
+# Replace >#< with >$(pound)< to avoid starting a comment in the .cmd file
# (needed for make)
# Replace >'< with >'\''< to be able to enclose the whole string in '...'
# (needed for the shell)
-make-cmd = $(call escsq,$(subst \#,\\\#,$(subst $$,,$(cmd_$(1)
+make-cmd = $(call escsq,$(subst $(pound),$$(pound),$(subst
$$,,$(cmd_$(1)
###
# Find any prerequisites that is newer than target or that does not exist.
diff --git a/tools/objtool/Makefile b/tools/objtool/Makefile
index e6acc281dd37..8ae824dbfca3 100644
--- a/tools/objtool/Makefile
+++ b/tools/objtool/Makefile
@@ -35,7 +35,7 @@ CFLAGS += -Wall -Werror $(WARNINGS) -fomit-frame-pointer
-O2 -g $(INCLUDES)
LDFLAGS += -lelf $(LIBSUBCMD)
# Allow old libelf to be used:
-elfshdr := $(shell echo '\#include ' | $(CC) $(CFLAGS) -x c -E - |
grep elf_getshdr)
+elfshdr := $(shell echo '$(pound)include ' | $(CC) $(CFLAGS) -x c -E
- | grep elf_getshdr)
CFLAGS += $(if $(elfshdr),,-DLIBELF_USE_DEPRECATED)
AWK = awk
diff --git a/tools/scripts/Makefile.include b/tools/scripts/Makefile.include
index dd614463d4d6..495066bafbe3 100644
--- a/tools/scripts/Makefile.include
+++ b/tools/scripts/Makefile.include
@@ -120,3 +120,5 @@ ifneq ($(silent),1)
QUIET_UNINST = @printf ' UNINST %s\n' $1;
endif
endif
+
+pound := \#
--
2.15.1
Re: BUG: please report to d...@vger.kernel.org => prev = 0, last = 0 at net/dccp/ccids/lib/packet_history.c:LINE/tfrc_rx_hist_sample_rtt()
On Thu, Jan 18, 2018 at 01:34:02AM -0800, syzbot wrote:
> syzbot has found reproducer for the following crash on linux-next commit
> a362f6d2cdbd089dd7040ba66dcb0ad276a20cf7 (Thu Jan 18 07:07:54 2018 +)
> Add linux-next specific files for 20180118
>
> So far this crash happened 185 times on linux-next, mmots, net-next,
> upstream.
> C reproducer is attached.
> syzkaller reproducer is attached.
> Raw console output is attached.
> compiler: gcc (GCC) 7.1.1 20170620
> .config is attached.
>
> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> Reported-by:
> syzbot+3ca02e1a9272a28e8959b32039154c5605164...@syzkaller.appspotmail.com
> It will help syzbot understand when the bug is fixed.
>
> BUG: please report to d...@vger.kernel.org => prev = 0, last = 0 at
> net/dccp/ccids/lib/packet_history.c:425/tfrc_rx_hist_sample_rtt()
> CPU: 1 PID: 6246 Comm: syzkaller158939 Not tainted 4.15.0-rc8-next-20180118+
> #100
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> Google 01/01/2011
> Call Trace:
>
> __dump_stack lib/dump_stack.c:17 [inline]
> dump_stack+0x194/0x257 lib/dump_stack.c:53
> tfrc_rx_hist_sample_rtt+0x407/0x4d0 net/dccp/ccids/lib/packet_history.c:422
> ccid3_hc_rx_packet_recv+0x696/0xeb3 net/dccp/ccids/ccid3.c:765
> ccid_hc_rx_packet_recv net/dccp/ccid.h:185 [inline]
> dccp_deliver_input_to_ccids+0xd9/0x250 net/dccp/input.c:180
> dccp_rcv_established+0x88/0xb0 net/dccp/input.c:378
> dccp_v4_do_rcv+0x135/0x160 net/dccp/ipv4.c:653
> sk_backlog_rcv include/net/sock.h:908 [inline]
> __sk_receive_skb+0x33e/0xc10 net/core/sock.c:513
> dccp_v4_rcv+0xf5f/0x1c80 net/dccp/ipv4.c:874
> ip_local_deliver_finish+0x2f1/0xc50 net/ipv4/ip_input.c:216
> NF_HOOK include/linux/netfilter.h:288 [inline]
> ip_local_deliver+0x1ce/0x6e0 net/ipv4/ip_input.c:257
> dst_input include/net/dst.h:449 [inline]
> ip_rcv_finish+0x953/0x1e30 net/ipv4/ip_input.c:397
> NF_HOOK include/linux/netfilter.h:288 [inline]
> ip_rcv+0xc5a/0x1840 net/ipv4/ip_input.c:493
> __netif_receive_skb_core+0x1a41/0x3460 net/core/dev.c:4537
> __netif_receive_skb+0x2c/0x1b0 net/core/dev.c:4602
> process_backlog+0x203/0x740 net/core/dev.c:5282
> napi_poll net/core/dev.c:5680 [inline]
> net_rx_action+0x792/0x1910 net/core/dev.c:5746
> __do_softirq+0x2d7/0xb85 kernel/softirq.c:285
> do_softirq_own_stack+0x2a/0x40 arch/x86/entry/entry_64.S:1150
>
> do_softirq.part.19+0x14d/0x190 kernel/softirq.c:329
> do_softirq kernel/softirq.c:177 [inline]
> __local_bh_enable_ip+0x1ee/0x230 kernel/softirq.c:182
> local_bh_enable include/linux/bottom_half.h:32 [inline]
> rcu_read_unlock_bh include/linux/rcupdate.h:726 [inline]
> ip_finish_output2+0x962/0x1550 net/ipv4/ip_output.c:231
> ip_finish_output+0x864/0xd10 net/ipv4/ip_output.c:317
> NF_HOOK_COND include/linux/netfilter.h:277 [inline]
> ip_output+0x1d2/0x860 net/ipv4/ip_output.c:405
> dst_output include/net/dst.h:443 [inline]
> ip_local_out+0x95/0x160 net/ipv4/ip_output.c:124
> ip_queue_xmit+0x8c0/0x18e0 net/ipv4/ip_output.c:504
> dccp_transmit_skb+0x9ac/0x10f0 net/dccp/output.c:142
> dccp_xmit_packet+0x215/0x740 net/dccp/output.c:281
> dccp_write_xmit+0x17d/0x1d0 net/dccp/output.c:363
> dccp_sendmsg+0x95f/0xdc0 net/dccp/proto.c:813
> inet_sendmsg+0x11f/0x5e0 net/ipv4/af_inet.c:764
> sock_sendmsg_nosec net/socket.c:630 [inline]
> sock_sendmsg+0xca/0x110 net/socket.c:640
> ___sys_sendmsg+0x767/0x8b0 net/socket.c:2020
> __sys_sendmsg+0xe5/0x210 net/socket.c:2054
> SYSC_sendmsg net/socket.c:2065 [inline]
> SyS_sendmsg+0x2d/0x50 net/socket.c:2061
> entry_SYSCALL_64_fastpath+0x29/0xa0
> RIP: 0033:0x446469
> RSP: 002b:7fcecb23bda8 EFLAGS: 0293 ORIG_RAX: 002e
> RAX: ffda RBX: 006dbc3c RCX: 00446469
> RDX: 0080 RSI: 206c8000 RDI: 0005
> RBP: 006dbc38 R08: R09:
> R10: R11: 0293 R12: f8e4cbe49e572d45
> R13: 54c1b85d98aba1df R14: a6eaa24dbeb18c29 R15: 000c
>
This is still happening. It *might* be related to the other bug "suspicious RCU
usage at ./include/net/inet_sock.h:LINE". Here's a simplified reproducer for
this one:
#include
#include
#include
#include
#include
int main()
{
struct sockaddr_in addr = { .sin_family = AF_INET };
socklen_t addrlen = sizeof(addr);
int fd;
while (fork())
wait(NULL);
fd = socket(AF_INET, SOCK_DCCP, 0);
bind(fd, (void *)&addr, addrlen);
getsockname(fd, (void *)&addr, &addrlen);
listen(fd, 100);
if (fork()) {
fd = socket(AF_INET, SOCK_DCCP, 0);
setsockopt(fd, SOL_DCCP, DCCP_SOCKOPT_CCID, "\x03", 1);
connect(fd, (void *)&addr, sizeof(addr));
} else {
fd = accept(fd, NULL, 0);
}
for (int i = 0; i < 1000; i++)
write(fd, "X", 1);
}
Re: [PATCH] mtd: spi-nor: clear Extended Address Reg on switch to 3-byte addressing.
On Sun, Apr 08 2018, Marek Vasut wrote:
> On 04/08/2018 09:04 AM, NeilBrown wrote:
>>
>> According to section
>>8.2.7 Write Extended Address Register (C5h)
>>
>> of the Winbond W25Q256FV data sheet (256M-BIT SPI flash)
>>
>>The Extended Address Register is only effective when the device is
>>in the 3-Byte Address Mode. When the device operates in the 4-Byte
>>Address Mode (ADS=1), any command with address input of A31-A24
>>will replace the Extended Address Register values. It is
>>recommended to check and update the Extended Address Register if
>>necessary when the device is switched from 4-Byte to 3-Byte Address
>>Mode.
>>
>> This patch adds code to implement that recommendation. Without this,
>> my GNUBEE-PC1 will not successfully reboot, as the Extended Address
>> Register is left with a value of '1'. When the SOC attempts to read
>> (in 3-byte address mode) the boot loader, it reads from the wrong
>> location.
>
> Your board is broken by design and does not implement proper reset logic
> for the SPI NOR chip, right ? That is, when the CPU resets, the SPI NOR
> is left in some random undefined state instead of being reset too, yes?
Thanks for the reply.
"Broken" is an emotive word :-) Certain the board *doesn't* reset the NOR
chip on reset.
However the NOR chip doesn't have a dedicated RESET pin. It has a pin
that defaults to "HOLD" and can be programmed to act as "RESET". This
pin is tied to 3V3 on my board. If it were tied to a reset line, it
would still need code changes to work (or switch from the default).
A few month ago:
Commit: 8dee1d971af9 ("mtd: spi-nor: add an API to restore the status of SPI
flash chip")
Commit: 59b356ffd0b0 ("mtd: m25p80: restore the status of SPI flash when
exiting")
were added to Linux. They appear to be designed to address a very
similar situation to mine. Unfortunately they aren't complete as the
code to disable 4-byte addressing doesn't follow documented requirements
(at least for winbond) and doesn't work as intended (at least in one
case - mine). This code should either be fixed (e.g. with my patch), or removed.
>
> Doesn't this chip support 4-byte addressing opcodes ? If so, we should
> use those and keep the chip in 3-byte addressing mode. Would that work?
Yes and no.
If I
- { "w25q256", INFO(0xef4019, 0, 64 * 1024, 512, SECT_4K |
SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) },
+ { "w25q256", INFO(0xef4019, 0, 64 * 1024, 512,
+ SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ |
+ SPI_NOR_4B_OPCODES) },
then I can still read all the flash and it never gets switched to
4-byte mode.
However, if the last address read from the flash is beyond 16M, the
extended address register gets implicitly set to 1, and reboot doesn't
work.
i.e. the problem isn't 4-byte mode exactly. The problem is the Extended
Address Register being set implicitly, and not being zero at reboot.
It looks like we need to clear the extended address register before
reboot, either by:
- software-reset the flash at shutdown
- write '0' in the shutdown handler
- write '0' after every transfer (or every transfer beyond 16M).
Which would you prefer, or is there another option?
Thanks,
NeilBrown
>
>> Signed-off-by: NeilBrown
>> ---
>> drivers/mtd/spi-nor/spi-nor.c | 10 ++
>> include/linux/mtd/spi-nor.h | 2 ++
>> 2 files changed, 12 insertions(+)
>>
>> diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c
>> index d445a4d3b770..c303bf0d2982 100644
>> --- a/drivers/mtd/spi-nor/spi-nor.c
>> +++ b/drivers/mtd/spi-nor/spi-nor.c
>> @@ -269,6 +269,7 @@ static inline int set_4byte(struct spi_nor *nor, const
>> struct flash_info *info,
>> int status;
>> bool need_wren = false;
>> u8 cmd;
>> +u8 val;
>>
>> switch (JEDEC_MFR(info)) {
>> case SNOR_MFR_MICRON:
>> @@ -283,6 +284,15 @@ static inline int set_4byte(struct spi_nor *nor, const
>> struct flash_info *info,
>> status = nor->write_reg(nor, cmd, NULL, 0);
>> if (need_wren)
>> write_disable(nor);
>> +if (!status && !enable &&
>> +nor->read_reg(nor, SPINOR_OP_RDXA, &val, 1) == 0 &&
>> +val != 0) {
>> +/* need to reset the Extended Address Register */
>> +write_enable(nor);
>> +val = 0;
>> +nor->write_reg(nor, SPINOR_OP_WRXA, &val, 1);
>> +write_disable(nor);
>> +}
>>
>> return status;
>> default:
>> diff --git a/include/linux/mtd/spi-nor.h b/include/linux/mtd/spi-nor.h
>> index de36969eb359..42954419cfdf 100644
>> --- a/include/linux/mtd/spi-nor.h
>> +++ b/include/linux/mtd/spi-nor.h
>> @@ -62,6 +62,8 @@
>> #define SPINOR_OP_RDCR 0x35/* Read configuration register
>> */
>> #define SPINOR_OP_RDFSR 0x70/* Read flag status register */
[RESEND PATCH] drivers: change struct device_driver::coredump() return type to void
Upon submitting a patch for mwifiex [1] it was discussed whether this
callback function could fail. To keep things simple there is no need
for the error code so the driver can do the task synchronous or not
without worries. Currently the device driver core already ignores the
return value so changing it to void.
[1] https://patchwork.kernel.org/patch/10231933/
Signed-off-by: Arend van Spriel
---
Hi Greg,
Here is a resend of my patch that got lost. See if it makes it
this time ;-)
Regards,
Arend
---
include/linux/device.h | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/include/linux/device.h b/include/linux/device.h
index 0059b99..4779569 100644
--- a/include/linux/device.h
+++ b/include/linux/device.h
@@ -256,7 +256,9 @@ enum probe_type {
* automatically.
* @pm:Power management operations of the device which matched
* this driver.
- * @coredump: Called through sysfs to initiate a device coredump.
+ * @coredump: Called when sysfs entry is written to. The device driver
+ * is expected to call the dev_coredump API resulting in a
+ * uevent.
* @p: Driver core's private data, no one other than the driver
* core can touch this.
*
@@ -288,7 +290,7 @@ struct device_driver {
const struct attribute_group **groups;
const struct dev_pm_ops *pm;
- int (*coredump) (struct device *dev);
+ void (*coredump) (struct device *dev);
struct driver_private *p;
};
--
2.7.4
Re: [PATCH v4 1/3] locking: Document the semantics of spin_is_locked()
On Sun, Apr 08, 2018 at 02:32:53PM -0700, Randy Dunlap wrote: > On 04/08/2018 02:14 PM, Paul E. McKenney wrote: > > On Fri, Apr 06, 2018 at 11:58:25PM +0200, Andrea Parri wrote: > >> On Fri, Apr 06, 2018 at 02:08:16PM -0700, Randy Dunlap wrote: > >>> On 04/06/2018 02:07 PM, Paul E. McKenney wrote: > On Fri, Apr 06, 2018 at 02:01:41PM -0700, Randy Dunlap wrote: > > On 04/06/2018 12:47 PM, Andrea Parri wrote: > >> There appeared to be a certain, recurrent uncertainty concerning the > >> semantics of spin_is_locked(), likely a consequence of the fact that > >> this semantics remains undocumented or that it has been historically > >> linked to the (likewise unclear) semantics of spin_unlock_wait(). > >> > >> A recent auditing [1] of the callers of the primitive confirmed that > >> none of them are relying on particular ordering guarantees; document > >> this semantics by adding a docbook header to spin_is_locked(). Also, > >> describe behaviors specific to certain CONFIG_SMP=n builds. > >> > >> [1] https://marc.info/?l=linux-kernel&m=151981440005264&w=2 > >> https://marc.info/?l=linux-kernel&m=152042843808540&w=2 > >> https://marc.info/?l=linux-kernel&m=152043346110262&w=2 > >> > >> Co-Developed-by: Andrea Parri > >> Co-Developed-by: Alan Stern > >> Co-Developed-by: David Howells > >> Signed-off-by: Andrea Parri > >> Signed-off-by: Alan Stern > >> Signed-off-by: David Howells > >> Cc: Will Deacon > >> Cc: Peter Zijlstra > >> Cc: Boqun Feng > >> Cc: Nicholas Piggin > >> Cc: Jade Alglave > >> Cc: Luc Maranget > >> Cc: "Paul E. McKenney" > >> Cc: Akira Yokosawa > >> Cc: Ingo Molnar > >> --- > >> include/linux/spinlock.h | 18 ++ > >> 1 file changed, 18 insertions(+) > >> > >> diff --git a/include/linux/spinlock.h b/include/linux/spinlock.h > >> index 4894d322d2584..1e8a464358384 100644 > >> --- a/include/linux/spinlock.h > >> +++ b/include/linux/spinlock.h > >> @@ -380,6 +380,24 @@ static __always_inline int > >> spin_trylock_irq(spinlock_t *lock) > >>raw_spin_trylock_irqsave(spinlock_check(lock), flags); \ > >> }) > >> > >> +/** > >> + * spin_is_locked() - Check whether a spinlock is locked. > >> + * @lock: Pointer to the spinlock. > >> + * > >> + * This function is NOT required to provide any memory ordering > >> + * guarantees; it could be used for debugging purposes or, when > >> + * additional synchronization is needed, accompanied with other > >> + * constructs (memory barriers) enforcing the synchronization. > >> + * > >> + * Returns: 1 if @lock is locked, 0 otherwise. > > > > Sorry, minor nit: > > s/Returns:/Return:/ > > (according to kernel-doc.rst) > > > > although I agree that "Returns:" is better. > > [I should have changed that years ago.] > > Agreed, English grammar and templates often seem to conflict. > > So should we change this comment, or are you instead proposing to add > "Returns:" as valid kernel-doc? > >>> > >>> Please change this patch to current doc syntax. > >>> Any changes to kernel-doc syntax would come later. > > > > Are you sure? > > > > $ git grep "\* Returns:" | wc -l > > 2470 > > $ git grep "\* Return:" | wc -l > > 4144 > > > > Looks like more than a third of them are already "Returns:". ;-) > > > >> Paul: I understand that you're going to do this change "in place"; please > >> let me know if I'm wrong/if you need a new submission. > > > > If Randy is certain that he would like to continue propagating > > this grammatical infelicity, sure. ;-) > > eh? > Well, Documentation/doc-guide/kernel-doc.rst says "Return:", but it appears > that it does not matter to scripts/kernel-doc -- it's just the name of a > "section" of the documentation and can be spelled any way! oh well. :) > > Acked-by: Randy Dunlap Applied, thank you both! Thanx, Paul
Re: [GIT PULL] Kernel lockdown for secure boot
Hi! > > What I'm afraid of is this turning into a "security" feature that ends up > > being circumvented in most scenarios where it's currently deployed - eg, > > module signatures are mostly worthless in the non-lockdown case because you > > can just grab the sig_enforce symbol address and then kexec a preamble that > > flips it back to N regardless of the kernel config. > > Whoa. Why doesn't lockdown prevent kexec? Put another away, why > isn't this a problem for people who are fearful that Linux could be > used as part of a Windows boot virus in a Secure UEFI context? > > If lockdown simply included a requirement for a signed kernel for > kexec --- and if kernel signing aren't available, to simply not alow > kexec, wouldn't that take care of this case? > > This wouldn't even be all that much of a burden for non-distro users > with lockdown enabled, since in my experience outside of enterprise > and data center use cases, kexec isn't used --- and in fact, very > often kexec doesn't even work outside of a very carefully selected and > bug-fixed set of device drivers. (It often doesn't work in non-distro > kernels because very few upstream developers really care about kexec.) I do have Motorola Droid 4 here (cellphone). It uses safestrap.. and than it turn kexec's a lot (so that you can select Android vs. Jolla vs. ... during boot). So yes, kexec shows even in unexpected places. And BTW.. the cellphone thingie is a situation where manufacturer works against it users. Motorola does _not_ want me to run my own kernels here. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html signature.asc Description: Digital signature
Re: [PATCH bpf-next v8 05/11] seccomp,landlock: Enforce Landlock programs per process hierarchy
On 04/08/2018 11:06 PM, Andy Lutomirski wrote:
> On Sun, Apr 8, 2018 at 6:13 AM, Mickaël Salaün wrote:
>>
>> On 02/27/2018 10:48 PM, Mickaël Salaün wrote:
>>>
>>> On 27/02/2018 17:39, Andy Lutomirski wrote:
On Tue, Feb 27, 2018 at 5:32 AM, Alexei Starovoitov
wrote:
> On Tue, Feb 27, 2018 at 05:20:55AM +, Andy Lutomirski wrote:
>> On Tue, Feb 27, 2018 at 4:54 AM, Alexei Starovoitov
>> wrote:
>>> On Tue, Feb 27, 2018 at 04:40:34AM +, Andy Lutomirski wrote:
On Tue, Feb 27, 2018 at 2:08 AM, Alexei Starovoitov
wrote:
> On Tue, Feb 27, 2018 at 01:41:15AM +0100, Mickaël Salaün wrote:
>> The seccomp(2) syscall can be used by a task to apply a Landlock
>> program
>> to itself. As a seccomp filter, a Landlock program is enforced for
>> the
>> current task and all its future children. A program is immutable and
>> a
>> task can only add new restricting programs to itself, forming a list
>> of
>> programss.
>>
>> A Landlock program is tied to a Landlock hook. If the action on a
>> kernel
>> object is allowed by the other Linux security mechanisms (e.g. DAC,
>> capabilities, other LSM), then a Landlock hook related to this kind
>> of
>> object is triggered. The list of programs for this hook is then
>> evaluated. Each program return a 32-bit value which can deny the
>> action
>> on a kernel object with a non-zero value. If every programs of the
>> list
>> return zero, then the action on the object is allowed.
>>
>> Multiple Landlock programs can be chained to share a 64-bits value
>> for a
>> call chain (e.g. evaluating multiple elements of a file path). This
>> chaining is restricted when a process construct this chain by
>> loading a
>> program, but additional checks are performed when it requests to
>> apply
>> this chain of programs to itself. The restrictions ensure that it is
>> not possible to call multiple programs in a way that would imply to
>> handle multiple shared values (i.e. cookies) for one chain. For now,
>> only a fs_pick program can be chained to the same type of program,
>> because it may make sense if they have different triggers (cf. next
>> commits). This restrictions still allows to reuse Landlock programs
>> in
>> a safe way (e.g. use the same loaded fs_walk program with multiple
>> chains of fs_pick programs).
>>
>> Signed-off-by: Mickaël Salaün
>
> ...
>
>> +struct landlock_prog_set *landlock_prepend_prog(
>> + struct landlock_prog_set *current_prog_set,
>> + struct bpf_prog *prog)
>> +{
>> + struct landlock_prog_set *new_prog_set = current_prog_set;
>> + unsigned long pages;
>> + int err;
>> + size_t i;
>> + struct landlock_prog_set tmp_prog_set = {};
>> +
>> + if (prog->type != BPF_PROG_TYPE_LANDLOCK_HOOK)
>> + return ERR_PTR(-EINVAL);
>> +
>> + /* validate memory size allocation */
>> + pages = prog->pages;
>> + if (current_prog_set) {
>> + size_t i;
>> +
>> + for (i = 0; i <
>> ARRAY_SIZE(current_prog_set->programs); i++) {
>> + struct landlock_prog_list *walker_p;
>> +
>> + for (walker_p = current_prog_set->programs[i];
>> + walker_p; walker_p =
>> walker_p->prev)
>> + pages += walker_p->prog->pages;
>> + }
>> + /* count a struct landlock_prog_set if we need to
>> allocate one */
>> + if (refcount_read(¤t_prog_set->usage) != 1)
>> + pages += round_up(sizeof(*current_prog_set),
>> PAGE_SIZE)
>> + / PAGE_SIZE;
>> + }
>> + if (pages > LANDLOCK_PROGRAMS_MAX_PAGES)
>> + return ERR_PTR(-E2BIG);
>> +
>> + /* ensure early that we can allocate enough memory for the new
>> + * prog_lists */
>> + err = store_landlock_prog(&tmp_prog_set, current_prog_set,
>> prog);
>> + if (err)
>> + return ERR_PTR(err);
>> +
>> + /*
>> + * Each task_struct points to an array of prog list pointers.
>> These
>> + * tables are duplicated when additions are made (which means
>> each
>> + * table needs to be refcounted for the processes using it).
Re: WARNING in binder_send_failed_reply
On Tue, Dec 26, 2017 at 02:20:01PM -0800, syzbot wrote: > syzkaller has found reproducer for the following crash on > 0e08c463db387a2adcb0243b15ab868a73f87807 > git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/master > compiler: gcc (GCC) 7.1.1 20170620 > .config is attached > Raw console output is attached. > C reproducer is attached > syzkaller reproducer is attached. See https://goo.gl/kgGztJ > for information about syzkaller reproducers > > > IMPORTANT: if you fix the bug, please add the following tag to the commit: > Reported-by: > > It will help syzbot understand when the bug is fixed. > > binder: undelivered TRANSACTION_COMPLETE > binder: undelivered TRANSACTION_ERROR: 29189 > binder: send failed reply for transaction 844 to 4059:4061 > [ cut here ] > Unexpected reply error: 29189 > WARNING: CPU: 0 PID: 1409 at drivers/android/binder.c:1998 > binder_send_failed_reply+0x13b/0x390 drivers/android/binder.c:1997 > Kernel panic - not syncing: panic_on_warn set ... > > CPU: 0 PID: 1409 Comm: kworker/0:2 Not tainted 4.15.0-rc4-next-20171221+ #78 > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS > Google 01/01/2011 > Workqueue: events binder_deferred_func > Call Trace: > __dump_stack lib/dump_stack.c:17 [inline] > dump_stack+0x194/0x257 lib/dump_stack.c:53 > panic+0x1e4/0x41c kernel/panic.c:183 > __warn+0x1dc/0x200 kernel/panic.c:547 > report_bug+0x211/0x2d0 lib/bug.c:184 > fixup_bug.part.11+0x37/0x80 arch/x86/kernel/traps.c:177 > fixup_bug arch/x86/kernel/traps.c:246 [inline] > do_error_trap+0x2d7/0x3e0 arch/x86/kernel/traps.c:295 > do_invalid_op+0x1b/0x20 arch/x86/kernel/traps.c:314 > invalid_op+0x22/0x40 arch/x86/entry/entry_64.S:1079 > RIP: 0010:binder_send_failed_reply+0x13b/0x390 drivers/android/binder.c:1997 > RSP: 0018:8801d3887128 EFLAGS: 00010286 > RAX: dc08 RBX: 8801c2fbce00 RCX: 8159f9ce > RDX: RSI: 11003a70c91d RDI: 0293 > RBP: 8801d3887150 R08: 11003a710db8 R09: > R10: 8801d3886fa0 R11: R12: 8801bf73a840 > R13: 7205 R14: 7205 R15: 0fdb > binder_cleanup_transaction+0xd2/0x140 drivers/android/binder.c:2035 > binder_release_work+0x340/0x490 drivers/android/binder.c:4198 > binder_deferred_release drivers/android/binder.c:4951 [inline] > binder_deferred_func+0xe42/0x1340 drivers/android/binder.c:4996 > process_one_work+0xbbf/0x1af0 kernel/workqueue.c:2112 > worker_thread+0x223/0x1990 kernel/workqueue.c:2246 > kthread+0x33c/0x400 kernel/kthread.c:238 > ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:524 > Dumping ftrace buffer: >(ftrace buffer empty) > Kernel Offset: disabled > Rebooting in 86400 seconds.. > syzbot is no longer hitting this because the WARN() was removed by commit e46a3b3ba7509c: #syz fix: ANDROID: binder: remove WARN() for redundant txn error - Eric
Re: [GIT PULL] SELinux patches for v4.17
On Sun, 2018-04-08 at 19:59 +0100, Richard Haines via Selinux wrote: > On Mon, 2018-04-09 at 01:43 +0800, Xin Long wrote: > > On Sun, Apr 8, 2018 at 10:09 PM, Richard Haines > > wrote: > > > On Sun, 2018-04-08 at 08:50 -0400, Paul Moore wrote: > > > > On April 7, 2018 1:03:57 PM Linus Torvalds > > > da > > > > tion > > > > .org> wrote: > > > > On Sat, Apr 7, 2018 at 9:54 AM, Richard Haines > > > > wrote: > > > > > > > > So please check my resolution, but also somebody should tell me > > > > "Linus, you're a cretin, sctp_connect() doesn't want that > > > > security_sctp_bind_connect() at all because it was already done > > > > by > > > > XYZ" > > > > > > > > sctp_connect() or __sctp_connect() do not need to call > > > > security_sctp_bind_connect(). This is because the connect(2) > > > > call > > > > will > > > > handle the checks required via security_socket_connect(): > > > > > > > > Ok, thanks, that's exactly what I wanted to get. > > > > > > > > Anyway, somebody should still verify that it all looks good in > > > > my > > > > tree, but I don't actually expect the merge to have had any > > > > issues > > > > even if the refactoring made it a bit more complex than most > > > > merges > > > > are. > > > > > > > > Thanks for the quick response Richard. > > > > > > > > Xin Long looked it over and gave it the thumbs up, I'll take a > > > > look > > > > too, but to be honest I trust his SCTP understanding much more > > > > than > > > > mine. I also do weekly tests of each rcX release at a minimum > > > > so > > > > if > > > > something odd pops up I'll make sure you get a fix. > > > > > > > > Thanks again everyone. > > > > > > I built the kernel this morning and sorry to spoil the party, but > > > I've > > > run into a problem with lksctp-tools when running the func_tests: > > > > > > make v6test > > > .. > > > .. > > > ./test_timetolive_v6 > > > test_timetolive.c 0 INFO : Creating fillmsg of size 3087 > > > test_timetolive.c 1 PASS : Send a message with timeout > > > test_timetolive.c 2 PASS : Send a message with no timeout > > > test_timetolive.c 3 PASS : Send a fragmented message with > > > timeout > > > test_timetolive.c 0 INFO : ** SLEEPING for 3 seconds ** > > > test_timetolive.c 4 BROK : Got a datamsg of unexpected > > > length:23, > > > expected length:27 > > > DUMP_CORE sctputil.c: 247 > > > /bin/sh: line 1: 30981 Segmentation fault (core dumped) ./$a > > > test_timetolive_v6 fails > > > > > > make v4 test fails the same way. I'm using lksctp-tools from [1]. > > > I > > > have not investigated the cause yet as just found this and > > > thought > > > I > > > should flag first just in case someone has the answer !!! > > > > test_timetolive(_v6) works for me, In lksctp-tools/src/func_tests, > > I > > had > > another case failed,./test_1_to_1_events, it's caused by: > > commit 30f6ebf65bc46161c5aaff1db2e6e7c76aa4a06b > > Author: Xin Long > > Date: Wed Mar 14 19:05:34 2018 +0800 > > > > sctp: add SCTP_AUTH_NO_AUTH type for AUTHENTICATION_EVENT > > > > It's not kernel's issue, after that commit, ./test_1_to_1_events > > should > > have been improved. or avoid it by 'sysctl -w > > net.sctp.auth_enable=1' > > > > I'm not sure why test_timetolive(_v6) is not working in your env. > > It appears to depend on the run sequence of the tests. I rebooted the > system, ran test_timetolive_v6, it worked okay. > Ran "sctp-tests run" on a terminal, then ran test_timetolive_v6 at > various intervals on another terminal. Once sctp-tests started the > "=== > ndatasched ===" sequence, test_timetolive_v6 failed. 1) When SCTP is initialised /proc/sys/net/sctp/prsctp_enable = 1 2) When sctp-tests/testcase/regression/extoverflow/test.sh is executed, on exit it sets prsctp_enable = 0. This seems to be causing the issue I'm seeing. I can now simulate the problem: Running from fresh boot: checksctp cat /proc/sys/net/sctp/prsctp_enable 1 ./test_timetolive_v6 passes echo 0 > /proc/sys/net/sctp/prsctp_enable ./test_timetolive_v6 fails echo 1 > /proc/sys/net/sctp/prsctp_enable ./test_timetolive_v6 passes I've no idea why as yet !!! > > > > > > > > > On the bright side, I've run the sctp-tests from [2] with no > > > problems > > > and also the selinux-testsuite with my SCTP patch from [3] using > > > an > > > updated Fedora policy from [4] (with sctp support added), all in > > > enforcing mode. > > > > > > Also the LTP test passed: > > > cd /opt/ltp/ > > > cat runtest/syscalls |grep connect01>runtest/connect-syscall > > > ./runltp -pq -f connect-syscall > > > > > > > > > [1] https://github.com/sctp/lksctp-tools > > > [2] https://github.com/sctp/sctp-tests > > > [3] https://marc.info/?l=selinux&m=152156947715709&w=2 > > > [4] https://github.com/fedora-selinux/selinux-policy > > > > > > > > > > > > > > -- > > > > paul moore > > > > www.paul-moore.com > > > > > > > > > > > > > > > > -- > > To unsubscribe from this list: send the line "unsubscribe linux- > > security-module" in >
Re: [PATCH] crypto: DRBG - guard uninstantion by lock
On Sun, Apr 08, 2018 at 09:07:03PM +0200, Stephan Müller wrote: > Can you please check whether the attached patch fixes the issue? > Stephan, FYI, if you incude in your e-mail "#syz test " as the first line of your patch and the syzbot e-mail is cc'ed, the syzbot will automatically apply the patch in the e-mail against the git tree/branch specified in the "#syz test" line, and then try to see if the problem it discovered still reproduces --- and then send you e-mail one way or another. So the syzbot will run while the patch goes through the normal e-mail review process, which is kind of neat. :-) Cheers, - Ted
Re: INFO: task hung in exit_aio
[+Cc linux-crypto]
On Sun, Dec 10, 2017 at 05:33:01AM -0800, syzbot wrote:
> Hello,
>
> syzkaller hit the following crash on
> 82bcf1def3b5f1251177ad47c44f7e17af039b4b
> git://git.cmpxchg.org/linux-mmots.git/master
> compiler: gcc (GCC) 7.1.1 20170620
> .config is attached
> Raw console output is attached.
> C reproducer is attached
> syzkaller reproducer is attached. See https://goo.gl/kgGztJ
> for information about syzkaller reproducers
>
>
> INFO: task syzkaller265413:3189 blocked for more than 120 seconds.
> Not tainted 4.15.0-rc2-mm1+ #39
> "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
> syzkaller265413 D24320 3189 3150 0x8000
> Call Trace:
> context_switch kernel/sched/core.c:2800 [inline]
> __schedule+0x8eb/0x2060 kernel/sched/core.c:3376
> schedule+0xf5/0x430 kernel/sched/core.c:3435
> schedule_timeout+0x43a/0x560 kernel/time/timer.c:1776
> do_wait_for_common kernel/sched/completion.c:91 [inline]
> __wait_for_common kernel/sched/completion.c:112 [inline]
> wait_for_common kernel/sched/completion.c:123 [inline]
> wait_for_completion+0x44b/0x7b0 kernel/sched/completion.c:144
> exit_aio+0x47f/0x530 fs/aio.c:903
> __mmput kernel/fork.c:968 [inline]
> mmput+0x1b1/0x6c0 kernel/fork.c:992
> exit_mm kernel/exit.c:544 [inline]
> do_exit+0x90a/0x1ae0 kernel/exit.c:856
> do_group_exit+0x149/0x400 kernel/exit.c:972
> SYSC_exit_group kernel/exit.c:983 [inline]
> SyS_exit_group+0x1d/0x20 kernel/exit.c:981
> entry_SYSCALL_64_fastpath+0x1f/0x96
> RIP: 0033:0x440a99
> RSP: 002b:7ffc5abebf68 EFLAGS: 0202 ORIG_RAX: 00e7
> RAX: ffda RBX: RCX: 00440a99
> RDX: 00440a99 RSI: 0058 RDI:
> RBP: 0001cbc8 R08: 5abec108 R09: 00401fd0
> R10: 5abec108 R11: 0202 R12:
> R13: 00401fd0 R14: R15:
>
> Showing all locks held in the system:
> 2 locks held by khungtaskd/673:
> #0: (rcu_read_lock){}, at: []
> check_hung_uninterruptible_tasks kernel/hung_task.c:175 [inline]
> #0: (rcu_read_lock){}, at: [] watchdog+0x1c5/0xd60
> kernel/hung_task.c:249
> #1: (tasklist_lock){.+.+}, at: [<36eecee2>]
> debug_show_all_locks+0xd3/0x400 kernel/locking/lockdep.c:4554
> 2 locks held by getty/3117:
> #0: (&tty->ldisc_sem){}, at: [<8d3f9495>]
> ldsem_down_read+0x37/0x40 drivers/tty/tty_ldsem.c:365
> #1: (&ldata->atomic_read_lock){+.+.}, at: []
> n_tty_read+0x2f2/0x1a10 drivers/tty/n_tty.c:2131
> 2 locks held by getty/3118:
> #0: (&tty->ldisc_sem){}, at: [<8d3f9495>]
> ldsem_down_read+0x37/0x40 drivers/tty/tty_ldsem.c:365
> #1: (&ldata->atomic_read_lock){+.+.}, at: []
> n_tty_read+0x2f2/0x1a10 drivers/tty/n_tty.c:2131
> 2 locks held by getty/3119:
> #0: (&tty->ldisc_sem){}, at: [<8d3f9495>]
> ldsem_down_read+0x37/0x40 drivers/tty/tty_ldsem.c:365
> #1: (&ldata->atomic_read_lock){+.+.}, at: []
> n_tty_read+0x2f2/0x1a10 drivers/tty/n_tty.c:2131
> 2 locks held by getty/3120:
> #0: (&tty->ldisc_sem){}, at: [<8d3f9495>]
> ldsem_down_read+0x37/0x40 drivers/tty/tty_ldsem.c:365
> #1: (&ldata->atomic_read_lock){+.+.}, at: []
> n_tty_read+0x2f2/0x1a10 drivers/tty/n_tty.c:2131
> 2 locks held by getty/3121:
> #0: (&tty->ldisc_sem){}, at: [<8d3f9495>]
> ldsem_down_read+0x37/0x40 drivers/tty/tty_ldsem.c:365
> #1: (&ldata->atomic_read_lock){+.+.}, at: []
> n_tty_read+0x2f2/0x1a10 drivers/tty/n_tty.c:2131
> 2 locks held by getty/3122:
> #0: (&tty->ldisc_sem){}, at: [<8d3f9495>]
> ldsem_down_read+0x37/0x40 drivers/tty/tty_ldsem.c:365
> #1: (&ldata->atomic_read_lock){+.+.}, at: []
> n_tty_read+0x2f2/0x1a10 drivers/tty/n_tty.c:2131
> 2 locks held by getty/3123:
> #0: (&tty->ldisc_sem){}, at: [<8d3f9495>]
> ldsem_down_read+0x37/0x40 drivers/tty/tty_ldsem.c:365
> #1: (&ldata->atomic_read_lock){+.+.}, at: []
> n_tty_read+0x2f2/0x1a10 drivers/tty/n_tty.c:2131
>
> =
>
> NMI backtrace for cpu 1
> CPU: 1 PID: 673 Comm: khungtaskd Not tainted 4.15.0-rc2-mm1+ #39
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> Google 01/01/2011
> Call Trace:
> __dump_stack lib/dump_stack.c:17 [inline]
> dump_stack+0x194/0x257 lib/dump_stack.c:53
> nmi_cpu_backtrace+0x1d2/0x210 lib/nmi_backtrace.c:103
> nmi_trigger_cpumask_backtrace+0x122/0x180 lib/nmi_backtrace.c:62
> arch_trigger_cpumask_backtrace+0x14/0x20 arch/x86/kernel/apic/hw_nmi.c:38
> trigger_all_cpu_backtrace include/linux/nmi.h:138 [inline]
> check_hung_task kernel/hung_task.c:132 [inline]
> check_hung_uninterruptible_tasks kernel/hung_task.c:190 [inline]
> watchdog+0x90c/0xd60 kernel/hung_task.c:249
> kthread
Re: KASAN: use-after-free Read in inet_create
[+RDS list and maintainer] On Sat, Dec 09, 2017 at 12:50:01PM -0800, syzbot wrote: > Hello, > > syzkaller hit the following crash on > 82bcf1def3b5f1251177ad47c44f7e17af039b4b > git://git.cmpxchg.org/linux-mmots.git/master > compiler: gcc (GCC) 7.1.1 20170620 > .config is attached > Raw console output is attached. > > Unfortunately, I don't have any reproducer for this bug yet. > > > == > BUG: KASAN: use-after-free in inet_create+0xda0/0xf50 net/ipv4/af_inet.c:338 > Read of size 4 at addr 8801bde28554 by task kworker/u4:5/3492 > > CPU: 0 PID: 3492 Comm: kworker/u4:5 Not tainted 4.15.0-rc2-mm1+ #39 > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS > Google 01/01/2011 > Workqueue: krdsd rds_connect_worker > Call Trace: > __dump_stack lib/dump_stack.c:17 [inline] > dump_stack+0x194/0x257 lib/dump_stack.c:53 > print_address_description+0x73/0x250 mm/kasan/report.c:252 > kasan_report_error mm/kasan/report.c:351 [inline] > kasan_report+0x25b/0x340 mm/kasan/report.c:409 > __asan_report_load4_noabort+0x14/0x20 mm/kasan/report.c:429 > inet_create+0xda0/0xf50 net/ipv4/af_inet.c:338 > __sock_create+0x4d4/0x850 net/socket.c:1265 > sock_create_kern+0x3f/0x50 net/socket.c:1311 > rds_tcp_conn_path_connect+0x26f/0x920 net/rds/tcp_connect.c:108 > rds_connect_worker+0x156/0x1f0 net/rds/threads.c:165 > process_one_work+0xbfd/0x1bc0 kernel/workqueue.c:2113 > worker_thread+0x223/0x1990 kernel/workqueue.c:2247 > kthread+0x37a/0x440 kernel/kthread.c:238 > ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:524 > > Allocated by task 3362: > save_stack+0x43/0xd0 mm/kasan/kasan.c:447 > set_track mm/kasan/kasan.c:459 [inline] > kasan_kmalloc+0xad/0xe0 mm/kasan/kasan.c:551 > kasan_slab_alloc+0x12/0x20 mm/kasan/kasan.c:489 > kmem_cache_alloc+0x12e/0x760 mm/slab.c:3548 > kmem_cache_zalloc include/linux/slab.h:695 [inline] > net_alloc net/core/net_namespace.c:362 [inline] > copy_net_ns+0x196/0x580 net/core/net_namespace.c:402 > create_new_namespaces+0x425/0x880 kernel/nsproxy.c:107 > unshare_nsproxy_namespaces+0xae/0x1e0 kernel/nsproxy.c:206 > SYSC_unshare kernel/fork.c:2421 [inline] > SyS_unshare+0x653/0xfa0 kernel/fork.c:2371 > entry_SYSCALL_64_fastpath+0x1f/0x96 > > Freed by task 35: > save_stack+0x43/0xd0 mm/kasan/kasan.c:447 > set_track mm/kasan/kasan.c:459 [inline] > kasan_slab_free+0x71/0xc0 mm/kasan/kasan.c:524 > __cache_free mm/slab.c:3492 [inline] > kmem_cache_free+0x77/0x280 mm/slab.c:3750 > net_free+0xca/0x110 net/core/net_namespace.c:378 > net_drop_ns.part.11+0x26/0x30 net/core/net_namespace.c:385 > net_drop_ns net/core/net_namespace.c:384 [inline] > cleanup_net+0x895/0xb60 net/core/net_namespace.c:502 > process_one_work+0xbfd/0x1bc0 kernel/workqueue.c:2113 > worker_thread+0x223/0x1990 kernel/workqueue.c:2247 > kthread+0x37a/0x440 kernel/kthread.c:238 > ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:524 > > The buggy address belongs to the object at 8801bde28080 > which belongs to the cache net_namespace of size 6272 > The buggy address is located 1236 bytes inside of > 6272-byte region [8801bde28080, 8801bde29900) > The buggy address belongs to the page: > page:df6a4dc0 count:1 mapcount:0 mapping:553659f1 index:0x0 > compound_mapcount: 0 > flags: 0x2fffc008100(slab|head) > raw: 02fffc008100 8801bde28080 00010001 > raw: ea0006f75da0 ea0006f60220 8801d989fe00 > page dumped because: kasan: bad access detected > > Memory state around the buggy address: > 8801bde28400: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb > 8801bde28480: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb > > 8801bde28500: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb > ^ > 8801bde28580: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb > 8801bde28600: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb > == > > > --- > This bug is generated by a dumb bot. It may contain errors. > See https://goo.gl/tpsmEJ for details. > Direct all questions to syzkal...@googlegroups.com. > Please credit me with: Reported-by: syzbot > > syzbot will keep track of this bug report. > Once a fix for this bug is merged into any tree, reply to this email with: > #syz fix: exact-commit-title > To mark this as a duplicate of another syzbot report, please reply with: > #syz dup: exact-subject-of-another-report > If it's a one-off invalid bug report, please reply with: > #syz invalid > Note: if the crash happens again, it will cause creation of a new bug > report. > Note: all commands must start from beginning of the line in the email body. > This is still happening regularly, though syzbot hasn't been able to generate a reproducer yet. All the reports seem to involve rds_connect_worker() encountering a free
Re: [PATCH 1/2] tty: n_gsm: Fix long delays with control frame timeouts in ADM mode
* Pavel Machek [180408 19:07]:
> Hi!
>
> > > Do you have a tool to use and a script?
> >
> > Yes I used the shell script I posted earlier, but forgot it also
> > needs the ldattach done.
> >
> > Anyways, last night and today I wrote a quick test utility called
> > droid4-ngsm that initializes things and I can use to do some
> > experiments to get the ts27010 channel proxying to W3GLTE also
> > going:
> >
> > http://github.com/tmlind/droid4-ngsm/
>
> Ok, now i'm confused. It wants to bind to ttyS0, but modem is on
> ttyUSB4 AFAICT? Or is the modem connected to serial port, too? (Do I
> need to enable some more drivers for that?)
>
> I do have ttyS0, but I don't think there's anything attached there. Or
> is ttyS0 for the LTE modem?
The ttyS0 is connected to mdm6600, and ttyUSB4 seems to be
some buggy subset of ttyS0 n_gsm dlci1. You need need at least
the following commits in current mainline kernel:
984c7706ff18 ("ARM: dts: omap4-droid4: Configure uart1 pins")
e5b9fd7bdeb5 ("ARM: dts: omap4-droid4: Configure MDM6600 USB PHY")
And then you need PHY_MAPPHONE_MDM6600 and CONFIG_N_GSM enabled.
Regards,
Tony
[PATCH] ASoC: fsl_esai: Fix divisor calculation failure at lower ratio
When the desired ratio is less than 256, the savesub (tolerance)
in the calculation would become 0. This will then fail the loop-
search immediately without reporting any errors.
But if the ratio is smaller enough, there is no need to calculate
the tolerance because PM divisor alone is enough to get the ratio.
So a simple fix could be just to set PM directly instead of going
into the loop-search.
Reported-by: Marek Vasut
Signed-off-by: Nicolin Chen
Cc: Marek Vasut
---
sound/soc/fsl/fsl_esai.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/sound/soc/fsl/fsl_esai.c b/sound/soc/fsl/fsl_esai.c
index 40a7004..da8fd98 100644
--- a/sound/soc/fsl/fsl_esai.c
+++ b/sound/soc/fsl/fsl_esai.c
@@ -144,6 +144,13 @@ static int fsl_esai_divisor_cal(struct snd_soc_dai *dai,
bool tx, u32 ratio,
psr = ratio <= 256 * maxfp ? ESAI_xCCR_xPSR_BYPASS :
ESAI_xCCR_xPSR_DIV8;
+ /* Do not loop-search if PM (1 ~ 256) alone can serve the ratio */
+ if (ratio <= 256) {
+ pm = ratio;
+ fp = 1;
+ goto out;
+ }
+
/* Set the max fluctuation -- 0.1% of the max devisor */
savesub = (psr ? 1 : 8) * 256 * maxfp / 1000;
--
2.7.4
Re: [PATCH v3] dp83640: Ensure against premature access to PHY registers after reset
From: Esben Haabendal Date: Sun, 8 Apr 2018 22:17:01 +0200 > From: Esben Haabendal > > The datasheet specifies a 3uS pause after performing a software > reset. The default implementation of genphy_soft_reset() does not > provide this, so implement soft_reset with the needed pause. > > Signed-off-by: Esben Haabendal > Reviewed-by: Andrew Lunn Applied, thank you.
Re: [PATCH] Fixed typo in onewire generic doc
Hi everyone I'm really sorry for that long delay. Was this patch accepted or should I push it upstream? 20.12.2017, 22:09, "Gergo Huszty" : > Onewire devices has 6 byte long unique serial numbers, 1 byte family > code and 1 byte CRC. Linux sysfs presents the device folder in the > form of familyID-deviceID, so CRC is not shown. The consequence is > that the device serial number is always a 12 long hex-string, but > doc says 13 in one place. This is corrected by this change. > Reference: https://en.wikipedia.org/wiki/1-Wire > > Signed-off-by: Gergo Huszty > --- > Documentation/w1/w1.generic | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/Documentation/w1/w1.generic b/Documentation/w1/w1.generic > index b3ffaf8cfab2..c51b1ab012d0 100644 > --- a/Documentation/w1/w1.generic > +++ b/Documentation/w1/w1.generic > @@ -76,7 +76,7 @@ See struct w1_bus_master definition in w1.h for details. > > w1 master sysfs interface > -- > - - A directory for a found device. The format is > family-serial > + - A directory for a found device. The format is > family-serial > bus - (standard) symlink to the w1 bus > driver - (standard) symlink to the w1 driver > w1_master_add - (rw) manually register a slave device > -- > 2.15.1
[PATCH AUTOSEL for 4.15 012/189] KVM: PPC: Book3S HV: Enable migration of decrementer register
From: Paul Mackerras
[ Upstream commit 5855564c8ab2d9cefca7b2933bd19818eb795e40 ]
This adds a register identifier for use with the one_reg interface
to allow the decrementer expiry time to be read and written by
userspace. The decrementer expiry time is in guest timebase units
and is equal to the sum of the decrementer and the guest timebase.
(The expiry time is used rather than the decrementer value itself
because the expiry time is not constantly changing, though the
decrementer value is, while the guest vcpu is not running.)
Without this, a guest vcpu migrated to a new host will see its
decrementer set to some random value. On POWER8 and earlier, the
decrementer is 32 bits wide and counts down at 512MHz, so the
guest vcpu will potentially see no decrementer interrupts for up
to about 4 seconds, which will lead to a stall. With POWER9, the
decrementer is now 56 bits side, so the stall can be much longer
(up to 2.23 years) and more noticeable.
To help work around the problem in cases where userspace has not been
updated to migrate the decrementer expiry time, we now set the
default decrementer expiry at vcpu creation time to the current time
rather than the maximum possible value. This should mean an
immediate decrementer interrupt when a migrated vcpu starts
running. In cases where the decrementer is 32 bits wide and more
than 4 seconds elapse between the creation of the vcpu and when it
first runs, the decrementer would have wrapped around to positive
values and there may still be a stall - but this is no worse than
the current situation. In the large-decrementer case, we are sure
to get an immediate decrementer interrupt (assuming the time from
vcpu creation to first run is less than 2.23 years) and we thus
avoid a very long stall.
Signed-off-by: Paul Mackerras
Signed-off-by: Sasha Levin
---
Documentation/virtual/kvm/api.txt | 1 +
arch/powerpc/include/uapi/asm/kvm.h | 2 ++
arch/powerpc/kvm/book3s_hv.c| 8
arch/powerpc/kvm/powerpc.c | 2 +-
4 files changed, 12 insertions(+), 1 deletion(-)
diff --git a/Documentation/virtual/kvm/api.txt
b/Documentation/virtual/kvm/api.txt
index fc3ae951bc07..d225ec217ebb 100644
--- a/Documentation/virtual/kvm/api.txt
+++ b/Documentation/virtual/kvm/api.txt
@@ -1841,6 +1841,7 @@ registers, find a list below:
PPC | KVM_REG_PPC_DBSR | 32
PPC | KVM_REG_PPC_TIDR | 64
PPC | KVM_REG_PPC_PSSCR | 64
+ PPC | KVM_REG_PPC_DEC_EXPIRY| 64
PPC | KVM_REG_PPC_TM_GPR0 | 64
...
PPC | KVM_REG_PPC_TM_GPR31 | 64
diff --git a/arch/powerpc/include/uapi/asm/kvm.h
b/arch/powerpc/include/uapi/asm/kvm.h
index 637b7263cb86..833ed9a16adf 100644
--- a/arch/powerpc/include/uapi/asm/kvm.h
+++ b/arch/powerpc/include/uapi/asm/kvm.h
@@ -632,6 +632,8 @@ struct kvm_ppc_cpu_char {
#define KVM_REG_PPC_TIDR (KVM_REG_PPC | KVM_REG_SIZE_U64 | 0xbc)
#define KVM_REG_PPC_PSSCR (KVM_REG_PPC | KVM_REG_SIZE_U64 | 0xbd)
+#define KVM_REG_PPC_DEC_EXPIRY (KVM_REG_PPC | KVM_REG_SIZE_U64 | 0xbe)
+
/* Transactional Memory checkpointed state:
* This is all GPRs, all VSX regs and a subset of SPRs
*/
diff --git a/arch/powerpc/kvm/book3s_hv.c b/arch/powerpc/kvm/book3s_hv.c
index 6c402f6c4940..deffe36d8a2b 100644
--- a/arch/powerpc/kvm/book3s_hv.c
+++ b/arch/powerpc/kvm/book3s_hv.c
@@ -1504,6 +1504,10 @@ static int kvmppc_get_one_reg_hv(struct kvm_vcpu *vcpu,
u64 id,
case KVM_REG_PPC_ARCH_COMPAT:
*val = get_reg_val(id, vcpu->arch.vcore->arch_compat);
break;
+ case KVM_REG_PPC_DEC_EXPIRY:
+ *val = get_reg_val(id, vcpu->arch.dec_expires +
+ vcpu->arch.vcore->tb_offset);
+ break;
default:
r = -EINVAL;
break;
@@ -1731,6 +1735,10 @@ static int kvmppc_set_one_reg_hv(struct kvm_vcpu *vcpu,
u64 id,
case KVM_REG_PPC_ARCH_COMPAT:
r = kvmppc_set_arch_compat(vcpu, set_reg_val(id, *val));
break;
+ case KVM_REG_PPC_DEC_EXPIRY:
+ vcpu->arch.dec_expires = set_reg_val(id, *val) -
+ vcpu->arch.vcore->tb_offset;
+ break;
default:
r = -EINVAL;
break;
diff --git a/arch/powerpc/kvm/powerpc.c b/arch/powerpc/kvm/powerpc.c
index 0a7c88786ec0..f3a7a2fc3d70 100644
--- a/arch/powerpc/kvm/powerpc.c
+++ b/arch/powerpc/kvm/powerpc.c
@@ -763,7 +763,7 @@ int kvm_arch_vcpu_init(struct kvm_vcpu *vcpu)
hrtimer_init(&vcpu->arch.dec_timer, CLOCK_REALTIME, HRTIMER_MODE_ABS);
vcpu->arch.dec_timer.function = kvmppc_decrementer_wakeup;
- vcpu->arch.dec_expires = ~(u64)0;
+ vcpu->arch.dec_expires = get_tb();
#ifdef CONFIG_KVM_EXIT_TIMING
mutex_init(&vcpu->arch.exit_timing_lock);
--
2.15.1
[PATCH AUTOSEL for 4.15 020/189] selftest: ftrace: Fix to pick text symbols for kprobes
From: Masami Hiramatsu
[ Upstream commit 5e46664703b364434a2cbda3e6988fc24ae0ced5 ]
Fix to pick text symbols for multiple kprobe testcase.
kallsyms shows text symbols with " t " or " T " but
current testcase picks all symbols including "t",
so it picks data symbols if it includes 't' (e.g. "str").
This fixes it to find symbol lines with " t " or " T "
(including spaces).
Signed-off-by: Masami Hiramatsu
Reported-by: Russell King
Acked-by: Steven Rostedt (VMware)
Signed-off-by: Shuah Khan
Signed-off-by: Sasha Levin
---
tools/testing/selftests/ftrace/test.d/kprobe/multiple_kprobes.tc | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/tools/testing/selftests/ftrace/test.d/kprobe/multiple_kprobes.tc
b/tools/testing/selftests/ftrace/test.d/kprobe/multiple_kprobes.tc
index bb16cf91f1b5..e297bd7a2e79 100644
--- a/tools/testing/selftests/ftrace/test.d/kprobe/multiple_kprobes.tc
+++ b/tools/testing/selftests/ftrace/test.d/kprobe/multiple_kprobes.tc
@@ -12,8 +12,8 @@ case `uname -m` in
*) OFFS=0;;
esac
-echo "Setup up to 256 kprobes"
-grep t /proc/kallsyms | cut -f3 -d" " | grep -v .*\\..* | \
+echo "Setup up kprobes on first 256 text symbols"
+grep -i " t " /proc/kallsyms | cut -f3 -d" " | grep -v .*\\..* | \
head -n 256 | while read i; do echo p ${i}+${OFFS} ; done > kprobe_events ||:
echo 1 > events/kprobes/enable
--
2.15.1
[PATCH AUTOSEL for 4.15 029/189] tools lib traceevent: Simplify pointer print logic and fix %pF
From: "Steven Rostedt (VMware)"
[ Upstream commit 38d70b7ca1769f26c0b79f3c08ff2cc949712b59 ]
When processing %pX in pretty_print(), simplify the logic slightly by
incrementing the ptr to the format string if isalnum(ptr[1]) is true.
This follows the logic a bit more closely to what is in the kernel.
Also, this fixes a small bug where %pF was not giving the offset of the
function.
Signed-off-by: Steven Rostedt
Acked-by: Namhyung Kim
Cc: Andrew Morton
Link: http://lkml.kernel.org/r/20180112004822.260262...@goodmis.org
Signed-off-by: Arnaldo Carvalho de Melo
Signed-off-by: Sasha Levin
---
tools/lib/traceevent/event-parse.c | 17 +
1 file changed, 9 insertions(+), 8 deletions(-)
diff --git a/tools/lib/traceevent/event-parse.c
b/tools/lib/traceevent/event-parse.c
index 7ce724fc0544..9a17bc27296e 100644
--- a/tools/lib/traceevent/event-parse.c
+++ b/tools/lib/traceevent/event-parse.c
@@ -4949,21 +4949,22 @@ static void pretty_print(struct trace_seq *s, void
*data, int size, struct event
else
ls = 2;
- if (*(ptr+1) == 'F' || *(ptr+1) == 'f' ||
- *(ptr+1) == 'S' || *(ptr+1) == 's') {
+ if (isalnum(ptr[1]))
ptr++;
+
+ if (*ptr == 'F' || *ptr == 'f' ||
+ *ptr == 'S' || *ptr == 's') {
show_func = *ptr;
- } else if (*(ptr+1) == 'M' || *(ptr+1) == 'm') {
- print_mac_arg(s, *(ptr+1), data, size,
event, arg);
- ptr++;
+ } else if (*ptr == 'M' || *ptr == 'm') {
+ print_mac_arg(s, *ptr, data, size,
event, arg);
arg = arg->next;
break;
- } else if (*(ptr+1) == 'I' || *(ptr+1) == 'i') {
+ } else if (*ptr == 'I' || *ptr == 'i') {
int n;
- n = print_ip_arg(s, ptr+1, data, size,
event, arg);
+ n = print_ip_arg(s, ptr, data, size,
event, arg);
if (n > 0) {
- ptr += n;
+ ptr += n - 1;
arg = arg->next;
break;
}
--
2.15.1
[PATCH AUTOSEL for 4.15 026/189] i40iw: Zero-out consumer key on allocate stag for FMR
From: Shiraz Saleem
[ Upstream commit 6376e926af1a8661dd1b2e6d0896e07f84a35844 ]
If the application invalidates the MR before the FMR WR, HW parses the
consumer key portion of the stag and returns an invalid stag key
Asynchronous Event (AE) that tears down the QP.
Fix this by zeroing-out the consumer key portion of the allocated stag
returned to application for FMR.
Fixes: ee855d3b93f3 ("RDMA/i40iw: Add base memory management extensions")
Signed-off-by: Shiraz Saleem
Signed-off-by: Jason Gunthorpe
Signed-off-by: Sasha Levin
---
drivers/infiniband/hw/i40iw/i40iw_verbs.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/infiniband/hw/i40iw/i40iw_verbs.c
b/drivers/infiniband/hw/i40iw/i40iw_verbs.c
index 6aa613835405..896c4f82e5ef 100644
--- a/drivers/infiniband/hw/i40iw/i40iw_verbs.c
+++ b/drivers/infiniband/hw/i40iw/i40iw_verbs.c
@@ -1638,6 +1638,7 @@ static struct ib_mr *i40iw_alloc_mr(struct ib_pd *pd,
err_code = -EOVERFLOW;
goto err;
}
+ stag &= ~I40IW_CQPSQ_STAG_KEY_MASK;
iwmr->stag = stag;
iwmr->ibmr.rkey = stag;
iwmr->ibmr.lkey = stag;
--
2.15.1
[PATCH AUTOSEL for 4.15 052/189] ARM: 8738/1: Disable CONFIG_DEBUG_VIRTUAL for NOMMU
From: Vladimir Murzin
[ Upstream commit c7780ab56c091a9ba95a3278e6e1d9c73afb5052 ]
While running MPS2 platform (NOMMU) with DTB placed below PHYS_OFFSET
following warning poped up:
[ cut here ]
WARNING: CPU: 0 PID: 0 at arch/arm/mm/physaddr.c:42 __virt_to_phys+0x2f/0x40
virt_to_phys used for non-linear address: 4000 (0x4000)
CPU: 0 PID: 0 Comm: swapper Not tainted 4.15.0-rc1-5a31bf2-clean+ #2767
Hardware name: MPS2 (Device Tree Support)
[<2100bf39>] (unwind_backtrace) from [<2100b3ff>] (show_stack+0xb/0xc)
[<2100b3ff>] (show_stack) from [<2100e697>] (__warn+0x87/0xac)
[<2100e697>] (__warn) from [<2100e6db>] (warn_slowpath_fmt+0x1f/0x28)
[<2100e6db>] (warn_slowpath_fmt) from [<2100c603>] (__virt_to_phys+0x2f/0x40)
[<2100c603>] (__virt_to_phys) from [<2116a499>]
(early_init_fdt_reserve_self+0xd/0x24)
[<2116a499>] (early_init_fdt_reserve_self) from [<2116222d>]
(arm_memblock_init+0xb5/0xf8)
[<2116222d>] (arm_memblock_init) from [<21161cad>] (setup_arch+0x38b/0x50e)
[<21161cad>] (setup_arch) from [<21160455>] (start_kernel+0x31/0x280)
[<21160455>] (start_kernel) from [<>] ( (null))
random: get_random_bytes called from init_oops_id+0x17/0x2c with crng_init=0
---[ end trace ]---
Platforms without MMU support run with 1:1 (i.e. linear) memory
mapping, so disable CONFIG_DEBUG_VIRTUAL.
Fixes: e377cd8221eb ("ARM: 8640/1: Add support for CONFIG_DEBUG_VIRTUAL")
Signed-off-by: Vladimir Murzin
Signed-off-by: Russell King
Signed-off-by: Sasha Levin
---
arch/arm/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 51c8df561077..2c7e23e206da 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -4,7 +4,7 @@ config ARM
default y
select ARCH_CLOCKSOURCE_DATA
select ARCH_DISCARD_MEMBLOCK if !HAVE_ARCH_PFN_VALID
- select ARCH_HAS_DEBUG_VIRTUAL
+ select ARCH_HAS_DEBUG_VIRTUAL if MMU
select ARCH_HAS_DEVMEM_IS_ALLOWED
select ARCH_HAS_ELF_RANDOMIZE
select ARCH_HAS_SET_MEMORY
--
2.15.1
[PATCH AUTOSEL for 4.15 051/189] watchdog: sp5100_tco: Fix watchdog disable bit
From: Guenter Roeck [ Upstream commit f541c09ebfc61697b586b38c9ebaf4b70defb278 ] According to all published information, the watchdog disable bit for SB800 compatible controllers is bit 1 of PM register 0x48, not bit 2. For the most part that doesn't matter in practice, since the bit has to be cleared to enable watchdog address decoding, which is the default setting, but it still needs to be fixed. Cc: Zoltán Böszörményi Signed-off-by: Guenter Roeck Signed-off-by: Wim Van Sebroeck Signed-off-by: Sasha Levin --- drivers/watchdog/sp5100_tco.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/watchdog/sp5100_tco.h b/drivers/watchdog/sp5100_tco.h index 1af4dee71337..0e242d1110ce 100644 --- a/drivers/watchdog/sp5100_tco.h +++ b/drivers/watchdog/sp5100_tco.h @@ -55,7 +55,7 @@ #define SB800_PM_WATCHDOG_CONFIG 0x4C #define SB800_PCI_WATCHDOG_DECODE_EN (1 << 0) -#define SB800_PM_WATCHDOG_DISABLE (1 << 2) +#define SB800_PM_WATCHDOG_DISABLE (1 << 1) #define SB800_PM_WATCHDOG_SECOND_RES (3 << 0) #define SB800_ACPI_MMIO_DECODE_EN (1 << 0) #define SB800_ACPI_MMIO_SEL(1 << 1) -- 2.15.1
[PATCH AUTOSEL for 4.15 055/189] kconfig: Fix automatic menu creation mem leak
From: Ulf Magnusson
[ Upstream commit ae7440ef0c8013d68c00dad6900e7cce5311bb1c ]
expr_trans_compare() always allocates and returns a new expression,
giving the following leak outline:
...
*Allocate*
basedep = expr_trans_compare(basedep, E_UNEQUAL, &symbol_no);
...
for (menu = parent->next; menu; menu = menu->next) {
...
*Copy*
dep2 = expr_copy(basedep);
...
*Free copy*
expr_free(dep2);
}
*basedep lost!*
Fix by freeing 'basedep' after the loop.
Summary from Valgrind on 'menuconfig' (ARCH=x86) before the fix:
LEAK SUMMARY:
definitely lost: 344,376 bytes in 14,349 blocks
...
Summary after the fix:
LEAK SUMMARY:
definitely lost: 44,448 bytes in 1,852 blocks
...
Signed-off-by: Ulf Magnusson
Signed-off-by: Masahiro Yamada
Signed-off-by: Sasha Levin
---
scripts/kconfig/menu.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/scripts/kconfig/menu.c b/scripts/kconfig/menu.c
index e9357931b47d..749c2bd5fc51 100644
--- a/scripts/kconfig/menu.c
+++ b/scripts/kconfig/menu.c
@@ -372,6 +372,7 @@ void menu_finalize(struct menu *parent)
menu->parent = parent;
last_menu = menu;
}
+ expr_free(basedep);
if (last_menu) {
parent->list = parent->next;
parent->next = last_menu->next;
--
2.15.1
[PATCH AUTOSEL for 4.15 082/189] KVM: s390: vsie: use READ_ONCE to access some SCB fields
From: David Hildenbrand
[ Upstream commit b3ecd4aa8632a86428605ab73393d14779019d82 ]
Another VCPU might try to modify the SCB while we are creating the
shadow SCB. In general this is no problem - unless the compiler decides
to not load values once, but e.g. twice.
For us, this is only relevant when checking/working with such values.
E.g. the prefix value, the mso, state of transactional execution and
addresses of satellite blocks.
E.g. if we blindly forward values (e.g. general purpose registers or
execution controls after masking), we don't care.
Leaving unpin_blocks() untouched for now, will handle it separately.
The worst thing right now that I can see would be a missed prefix
un/remap (mso, prefix, tx) or using wrong guest addresses. Nothing
critical, but let's try to avoid unpredictable behavior.
Signed-off-by: David Hildenbrand
Message-Id: <20180116171526.12343-2-da...@redhat.com>
Reviewed-by: Christian Borntraeger
Acked-by: Cornelia Huck
Signed-off-by: Christian Borntraeger
Signed-off-by: Sasha Levin
---
arch/s390/kvm/vsie.c | 50 +++---
1 file changed, 31 insertions(+), 19 deletions(-)
diff --git a/arch/s390/kvm/vsie.c b/arch/s390/kvm/vsie.c
index 751348348477..11fc525e6e7f 100644
--- a/arch/s390/kvm/vsie.c
+++ b/arch/s390/kvm/vsie.c
@@ -28,7 +28,11 @@ struct vsie_page {
* the same offset as that in struct sie_page!
*/
struct mcck_volatile_info mcck_info;/* 0x0200 */
- /* the pinned originial scb */
+ /*
+* The pinned original scb. Be aware that other VCPUs can modify
+* it while we read from it. Values that are used for conditions or
+* are reused conditionally, should be accessed via READ_ONCE.
+*/
struct kvm_s390_sie_block *scb_o; /* 0x0218 */
/* the shadow gmap in use by the vsie_page */
struct gmap *gmap; /* 0x0220 */
@@ -140,12 +144,13 @@ static int shadow_crycb(struct kvm_vcpu *vcpu, struct
vsie_page *vsie_page)
{
struct kvm_s390_sie_block *scb_s = &vsie_page->scb_s;
struct kvm_s390_sie_block *scb_o = vsie_page->scb_o;
- u32 crycb_addr = scb_o->crycbd & 0x7ff8U;
+ const uint32_t crycbd_o = READ_ONCE(scb_o->crycbd);
+ const u32 crycb_addr = crycbd_o & 0x7ff8U;
unsigned long *b1, *b2;
u8 ecb3_flags;
scb_s->crycbd = 0;
- if (!(scb_o->crycbd & vcpu->arch.sie_block->crycbd & CRYCB_FORMAT1))
+ if (!(crycbd_o & vcpu->arch.sie_block->crycbd & CRYCB_FORMAT1))
return 0;
/* format-1 is supported with message-security-assist extension 3 */
if (!test_kvm_facility(vcpu->kvm, 76))
@@ -183,12 +188,15 @@ static void prepare_ibc(struct kvm_vcpu *vcpu, struct
vsie_page *vsie_page)
{
struct kvm_s390_sie_block *scb_s = &vsie_page->scb_s;
struct kvm_s390_sie_block *scb_o = vsie_page->scb_o;
+ /* READ_ONCE does not work on bitfields - use a temporary variable */
+ const uint32_t __new_ibc = scb_o->ibc;
+ const uint32_t new_ibc = READ_ONCE(__new_ibc) & 0x0fffU;
__u64 min_ibc = (sclp.ibc >> 16) & 0x0fffU;
scb_s->ibc = 0;
/* ibc installed in g2 and requested for g3 */
- if (vcpu->kvm->arch.model.ibc && (scb_o->ibc & 0x0fffU)) {
- scb_s->ibc = scb_o->ibc & 0x0fffU;
+ if (vcpu->kvm->arch.model.ibc && new_ibc) {
+ scb_s->ibc = new_ibc;
/* takte care of the minimum ibc level of the machine */
if (scb_s->ibc < min_ibc)
scb_s->ibc = min_ibc;
@@ -259,6 +267,10 @@ static int shadow_scb(struct kvm_vcpu *vcpu, struct
vsie_page *vsie_page)
{
struct kvm_s390_sie_block *scb_o = vsie_page->scb_o;
struct kvm_s390_sie_block *scb_s = &vsie_page->scb_s;
+ /* READ_ONCE does not work on bitfields - use a temporary variable */
+ const uint32_t __new_prefix = scb_o->prefix;
+ const uint32_t new_prefix = READ_ONCE(__new_prefix);
+ const bool wants_tx = READ_ONCE(scb_o->ecb) & ECB_TE;
bool had_tx = scb_s->ecb & ECB_TE;
unsigned long new_mso = 0;
int rc;
@@ -306,14 +318,14 @@ static int shadow_scb(struct kvm_vcpu *vcpu, struct
vsie_page *vsie_page)
scb_s->icpua = scb_o->icpua;
if (!(atomic_read(&scb_s->cpuflags) & CPUSTAT_SM))
- new_mso = scb_o->mso & 0xfff0UL;
+ new_mso = READ_ONCE(scb_o->mso) & 0xfff0UL;
/* if the hva of the prefix changes, we have to remap the prefix */
- if (scb_s->mso != new_mso || scb_s->prefix != scb_o->prefix)
+ if (scb_s->mso != new_mso || scb_s->prefix != new_prefix)
prefix_unmapped(vsie_page);
/* SIE will do mso/msl validity and exception checks for us */
scb_s->msl = scb_o->msl & 0xfff0UL;
scb_s->mso = new_mso;
- scb_s->prefix = scb_o->prefix;
+ sc
[PATCH AUTOSEL for 4.15 071/189] scsi: fas216: fix sense buffer initialization
From: Arnd Bergmann
[ Upstream commit 96d5eaa9bb74d299508d811d865c2c41b38b0301 ]
While testing with the ARM specific memset() macro removed, I ran into a
compiler warning that shows an old bug:
drivers/scsi/arm/fas216.c: In function 'fas216_rq_sns_done':
drivers/scsi/arm/fas216.c:2014:40: error: argument to 'sizeof' in 'memset' call
is the same expression as the destination; did you mean to provide an explicit
length? [-Werror=sizeof-pointer-memaccess]
It turns out that the definition of the scsi_cmd structure changed back
in linux-2.6.25, so now we clear only four bytes (sizeof(pointer))
instead of 96 (SCSI_SENSE_BUFFERSIZE). I did not check whether we
actually need to initialize the buffer here, but it's clear that if we
do it, we should use the correct size.
Fixes: de25deb18016 ("[SCSI] use dynamically allocated sense buffer")
Signed-off-by: Arnd Bergmann
Signed-off-by: Martin K. Petersen
Signed-off-by: Sasha Levin
---
drivers/scsi/arm/fas216.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/scsi/arm/fas216.c b/drivers/scsi/arm/fas216.c
index f4775ca70bab..27bda2b05de6 100644
--- a/drivers/scsi/arm/fas216.c
+++ b/drivers/scsi/arm/fas216.c
@@ -2011,7 +2011,7 @@ static void fas216_rq_sns_done(FAS216_Info *info, struct
scsi_cmnd *SCpnt,
* have valid data in the sense buffer that could
* confuse the higher levels.
*/
- memset(SCpnt->sense_buffer, 0, sizeof(SCpnt->sense_buffer));
+ memset(SCpnt->sense_buffer, 0, SCSI_SENSE_BUFFERSIZE);
//printk("scsi%d.%c: sense buffer: ", info->host->host_no, '0' +
SCpnt->device->id);
//{ int i; for (i = 0; i < 32; i++) printk("%02x ", SCpnt->sense_buffer[i]);
printk("\n"); }
/*
--
2.15.1
[PATCH AUTOSEL for 4.15 080/189] i40e: Fix channel addition in reset flow
From: Amritha Nambiar
[ Upstream commit bbf0bdd41fbf71a008325bdcf0df63ab088bf532 ]
Fix recreating the channel VSIs during the reset flow to reconfigure
the Tx rings and the queue context associated with the channel VSI.
Also update the next_base_queue for the VSI while rebuilding the
channel VSIs after a reset.
Signed-off-by: Amritha Nambiar
Tested-by: Andrew Bowers
Signed-off-by: Jeff Kirsher
Signed-off-by: Sasha Levin
---
drivers/net/ethernet/intel/i40e/i40e_main.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/net/ethernet/intel/i40e/i40e_main.c
b/drivers/net/ethernet/intel/i40e/i40e_main.c
index af792112a2d3..973bad818e81 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_main.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_main.c
@@ -9077,6 +9077,17 @@ static int i40e_rebuild_channels(struct i40e_vsi *vsi)
vsi->uplink_seid);
return ret;
}
+ /* Reconfigure TX queues using QTX_CTL register */
+ ret = i40e_channel_config_tx_ring(vsi->back, vsi, ch);
+ if (ret) {
+ dev_info(&vsi->back->pdev->dev,
+"failed to configure TX rings for channel
%u\n",
+ch->seid);
+ return ret;
+ }
+ /* update 'next_base_queue' */
+ vsi->next_base_queue = vsi->next_base_queue +
+ ch->num_queue_pairs;
if (ch->max_tx_rate) {
u64 credits = ch->max_tx_rate;
--
2.15.1
[PATCH AUTOSEL for 4.15 105/189] ntb_transport: Fix bug with max_mw_size parameter
From: Logan Gunthorpe
[ Upstream commit cbd27448faff4843ac4b66cc71445a10623ff48d ]
When using the max_mw_size parameter of ntb_transport to limit the size of
the Memory windows, communication cannot be established and the queues
freeze.
This is because the mw_size that's reported to the peer is correctly
limited but the size used locally is not. So the MW is initialized
with a buffer smaller than the window but the TX side is using the
full window. This means the TX side will be writing to a region of the
window that points nowhere.
This is easily fixed by applying the same limit to tx_size in
ntb_transport_init_queue().
Fixes: e26a5843f7f5 ("NTB: Split ntb_hw_intel and ntb_transport drivers")
Signed-off-by: Logan Gunthorpe
Acked-by: Allen Hubbe
Cc: Dave Jiang
Signed-off-by: Jon Mason
Signed-off-by: Sasha Levin
---
drivers/ntb/ntb_transport.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/ntb/ntb_transport.c b/drivers/ntb/ntb_transport.c
index 045e3dd4750e..9878c48826e3 100644
--- a/drivers/ntb/ntb_transport.c
+++ b/drivers/ntb/ntb_transport.c
@@ -1003,6 +1003,9 @@ static int ntb_transport_init_queue(struct
ntb_transport_ctx *nt,
mw_base = nt->mw_vec[mw_num].phys_addr;
mw_size = nt->mw_vec[mw_num].phys_size;
+ if (max_mw_size && mw_size > max_mw_size)
+ mw_size = max_mw_size;
+
tx_size = (unsigned int)mw_size / num_qps_mw;
qp_offset = tx_size * (qp_num / mw_count);
--
2.15.1
[PATCH AUTOSEL for 4.15 081/189] platform/x86: thinkpad_acpi: suppress warning about palm detection
From: David Herrmann
[ Upstream commit 587d8628fb71c3bfae29fb2bbe84c1478c59bac8 ]
This patch prevents the thinkpad_acpi driver from warning about 2 event
codes returned for keyboard palm-detection. No behavioral changes,
other than suppressing the warning in the kernel log. The events are
still forwarded via acpi-netlink channels.
We could, optionally, decide to forward the event through a
input-switch on the tpacpi input device. However, so far no suitable
input-code exists, and no similar drivers report such events. Hence,
leave it an acpi event for now.
Note that the event-codes are named based on empirical studies. On the
ThinkPad X1 5th Gen the sensor can be found underneath the arrow key.
Cc: Matthew Thode
Signed-off-by: David Herrmann
Acked-by: Henrique de Moraes Holschuh
Signed-off-by: Andy Shevchenko
Signed-off-by: Sasha Levin
---
drivers/platform/x86/thinkpad_acpi.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/platform/x86/thinkpad_acpi.c
b/drivers/platform/x86/thinkpad_acpi.c
index 117be48ff4de..128f91af716e 100644
--- a/drivers/platform/x86/thinkpad_acpi.c
+++ b/drivers/platform/x86/thinkpad_acpi.c
@@ -214,6 +214,10 @@ enum tpacpi_hkey_event_t {
/* AC-related events */
TP_HKEY_EV_AC_CHANGED = 0x6040, /* AC status changed */
+ /* Further user-interface events */
+ TP_HKEY_EV_PALM_DETECTED= 0x60b0, /* palm hoveres keyboard */
+ TP_HKEY_EV_PALM_UNDETECTED = 0x60b1, /* palm removed */
+
/* Misc */
TP_HKEY_EV_RFKILL_CHANGED = 0x7000, /* rfkill switch changed */
};
@@ -4079,6 +4083,12 @@ static bool hotkey_notify_6xxx(const u32 hkey,
*send_acpi_ev = false;
break;
+ case TP_HKEY_EV_PALM_DETECTED:
+ case TP_HKEY_EV_PALM_UNDETECTED:
+ /* palm detected hovering the keyboard, forward to user-space
+* via netlink for consumption */
+ return true;
+
default:
pr_warn("unknown possible thermal alarm or keyboard event
received\n");
known = false;
--
2.15.1
[PATCH AUTOSEL for 4.15 115/189] fs/dax.c: release PMD lock even when there is no PMD support in DAX
From: Jan H. Schönherr
[ Upstream commit ee190ca6516bc8257e3d36187ca6f0f71a9ec477 ]
follow_pte_pmd() can theoretically return after having acquired a PMD
lock, even when DAX was not compiled with CONFIG_FS_DAX_PMD.
Release the PMD lock unconditionally.
Link: http://lkml.kernel.org/r/20180118133839.20587-1-jscho...@amazon.de
Fixes: f729c8c9b24f ("dax: wrprotect pmd_t in dax_mapping_entry_mkclean")
Signed-off-by: Jan H. Schönherr
Reviewed-by: Ross Zwisler
Reviewed-by: Andrew Morton
Cc: Matthew Wilcox
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
Signed-off-by: Sasha Levin
---
fs/dax.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/dax.c b/fs/dax.c
index 95981591977a..c2ebf10b70da 100644
--- a/fs/dax.c
+++ b/fs/dax.c
@@ -636,8 +636,8 @@ static void dax_mapping_entry_mkclean(struct address_space
*mapping,
pmd = pmd_mkclean(pmd);
set_pmd_at(vma->vm_mm, address, pmdp, pmd);
unlock_pmd:
- spin_unlock(ptl);
#endif
+ spin_unlock(ptl);
} else {
if (pfn != pte_pfn(*ptep))
goto unlock_pte;
--
2.15.1
[PATCH AUTOSEL for 4.15 120/189] mm/mempolicy: add nodes_empty check in SYSC_migrate_pages
From: Yisheng Xie
[ Upstream commit 0486a38bcc4749808edbc848f1bcf232042770fc ]
As in manpage of migrate_pages, the errno should be set to EINVAL when
none of the node IDs specified by new_nodes are on-line and allowed by
the process's current cpuset context, or none of the specified nodes
contain memory. However, when test by following case:
new_nodes = 0;
old_nodes = 0xf;
ret = migrate_pages(pid, old_nodes, new_nodes, MAX);
The ret will be 0 and no errno is set. As the new_nodes is empty, we
should expect EINVAL as documented.
To fix the case like above, this patch check whether target nodes AND
current task_nodes is empty, and then check whether AND
node_states[N_MEMORY] is empty.
Link:
http://lkml.kernel.org/r/1510882624-44342-4-git-send-email-xieyishe...@huawei.com
Signed-off-by: Yisheng Xie
Acked-by: Vlastimil Babka
Cc: Andi Kleen
Cc: Chris Salls
Cc: Christopher Lameter
Cc: David Rientjes
Cc: Ingo Molnar
Cc: Naoya Horiguchi
Cc: Tan Xiaojun
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
Signed-off-by: Sasha Levin
---
mm/mempolicy.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/mm/mempolicy.c b/mm/mempolicy.c
index c9b807eca74c..277b6454954e 100644
--- a/mm/mempolicy.c
+++ b/mm/mempolicy.c
@@ -1435,10 +1435,14 @@ SYSCALL_DEFINE4(migrate_pages, pid_t, pid, unsigned
long, maxnode,
goto out_put;
}
- if (!nodes_subset(*new, node_states[N_MEMORY])) {
- err = -EINVAL;
+ task_nodes = cpuset_mems_allowed(current);
+ nodes_and(*new, *new, task_nodes);
+ if (nodes_empty(*new))
+ goto out_put;
+
+ nodes_and(*new, *new, node_states[N_MEMORY]);
+ if (nodes_empty(*new))
goto out_put;
- }
err = security_task_movememory(task);
if (err)
--
2.15.1
[PATCH AUTOSEL for 4.15 133/189] IB/ipoib: Fix for potential no-carrier state
From: Alex Estrin
[ Upstream commit 1029361084d18cc270f64dfd39529fafa10cfe01 ]
On reboot SM can program port pkey table before ipoib registered its
event handler, which could result in missing pkey event and leave root
interface with initial pkey value from index 0.
Since OPA port starts with invalid pkey in index 0, root interface will
fail to initialize and stay down with no-carrier flag.
For IB ipoib interface may end up with pkey different from value
opensm put in pkey table idx 0, resulting in connectivity issues
(different mcast groups, for example).
Close the window by calling event handler after registration
to make sure ipoib pkey is in sync with port pkey table.
Reviewed-by: Mike Marciniszyn
Reviewed-by: Ira Weiny
Signed-off-by: Alex Estrin
Signed-off-by: Dennis Dalessandro
Signed-off-by: Jason Gunthorpe
Signed-off-by: Sasha Levin
---
drivers/infiniband/ulp/ipoib/ipoib_main.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/infiniband/ulp/ipoib/ipoib_main.c
b/drivers/infiniband/ulp/ipoib/ipoib_main.c
index 160c5d9bca4c..4e75848f7a35 100644
--- a/drivers/infiniband/ulp/ipoib/ipoib_main.c
+++ b/drivers/infiniband/ulp/ipoib/ipoib_main.c
@@ -2287,6 +2287,9 @@ static struct net_device *ipoib_add_port(const char
*format,
priv->ca, ipoib_event);
ib_register_event_handler(&priv->event_handler);
+ /* call event handler to ensure pkey in sync */
+ queue_work(ipoib_workqueue, &priv->flush_heavy);
+
result = register_netdev(priv->dev);
if (result) {
printk(KERN_WARNING "%s: couldn't register ipoib port %d; error
%d\n",
--
2.15.1
[PATCH AUTOSEL for 4.15 145/189] ACPI / scan: Use acpi_bus_get_status() to initialize ACPI_TYPE_DEVICE devs
From: Hans de Goede [ Upstream commit 63347db0affadcbccd5613116ea8431c70139b3e ] The acpi_get_bus_status wrapper for acpi_bus_get_status_handle has some code to handle certain device quirks, in some cases we also need this quirk handling for the initial _STA call. Specifically on some devices calling _STA before all _DEP dependencies are met results in errors like these: [0.123579] ACPI Error: No handler for Region [ECRM] (ba9edc4c) [GenericSerialBus] (20170831/evregion-166) [0.123601] ACPI Error: Region GenericSerialBus (ID=9) has no handler (20170831/exfldio-299) [0.123618] ACPI Error: Method parse/execution failed \_SB.I2C1.BAT1._STA, AE_NOT_EXIST (20170831/psparse-550) acpi_get_bus_status already has code to avoid this, so by using it we also silence these errors from the initial _STA call. Note that in order for the acpi_get_bus_status handling for this to work, we initialize dep_unmet to 1 until acpi_device_dep_initialize gets called, this means that battery devices will be instantiated with an initial status of 0. This is not a problem, acpi_bus_attach will get called soon after the instantiation anyways and it will update the status as first point of order. Signed-off-by: Hans de Goede Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin --- drivers/acpi/scan.c | 20 +--- 1 file changed, 17 insertions(+), 3 deletions(-) diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c index b0fe5272c76a..8e63d937babb 100644 --- a/drivers/acpi/scan.c +++ b/drivers/acpi/scan.c @@ -1565,6 +1565,8 @@ void acpi_init_device_object(struct acpi_device *device, acpi_handle handle, device_initialize(&device->dev); dev_set_uevent_suppress(&device->dev, true); acpi_init_coherency(device); + /* Assume there are unmet deps until acpi_device_dep_initialize() runs */ + device->dep_unmet = 1; } void acpi_device_add_finalize(struct acpi_device *device) @@ -1588,6 +1590,14 @@ static int acpi_add_single_object(struct acpi_device **child, } acpi_init_device_object(device, handle, type, sta); + /* +* For ACPI_BUS_TYPE_DEVICE getting the status is delayed till here so +* that we can call acpi_bus_get_status() and use its quirk handling. +* Note this must be done before the get power-/wakeup_dev-flags calls. +*/ + if (type == ACPI_BUS_TYPE_DEVICE) + acpi_bus_get_status(device); + acpi_bus_get_power_flags(device); acpi_bus_get_wakeup_device_flags(device); @@ -1660,9 +1670,11 @@ static int acpi_bus_type_and_status(acpi_handle handle, int *type, return -ENODEV; *type = ACPI_BUS_TYPE_DEVICE; - status = acpi_bus_get_status_handle(handle, sta); - if (ACPI_FAILURE(status)) - *sta = 0; + /* +* acpi_add_single_object updates this once we've an acpi_device +* so that acpi_bus_get_status' quirk handling can be used. +*/ + *sta = 0; break; case ACPI_TYPE_PROCESSOR: *type = ACPI_BUS_TYPE_PROCESSOR; @@ -1760,6 +1772,8 @@ static void acpi_device_dep_initialize(struct acpi_device *adev) acpi_status status; int i; + adev->dep_unmet = 0; + if (!acpi_has_method(adev->handle, "_DEP")) return; -- 2.15.1
[PATCH AUTOSEL for 4.15 116/189] ocfs2: return -EROFS to mount.ocfs2 if inode block is invalid
From: piaojun
[ Upstream commit 025bcbde3634b2c9b316f227fed13ad6ad6817fb ]
If metadata is corrupted such as 'invalid inode block', we will get
failed by calling 'mount()' and then set filesystem readonly as below:
ocfs2_mount
ocfs2_initialize_super
ocfs2_init_global_system_inodes
ocfs2_iget
ocfs2_read_locked_inode
ocfs2_validate_inode_block
ocfs2_error
ocfs2_handle_error
ocfs2_set_ro_flag(osb, 0); // set readonly
In this situation we need return -EROFS to 'mount.ocfs2', so that user
can fix it by fsck. And then mount again. In addition, 'mount.ocfs2'
should be updated correspondingly as it only return 1 for all errno.
And I will post a patch for 'mount.ocfs2' too.
Link: http://lkml.kernel.org/r/5a4302fa.2010...@huawei.com
Signed-off-by: Jun Piao
Reviewed-by: Alex Chen
Reviewed-by: Joseph Qi
Reviewed-by: Changwei Ge
Reviewed-by: Gang He
Cc: Mark Fasheh
Cc: Joel Becker
Cc: Junxiao Bi
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
Signed-off-by: Sasha Levin
---
fs/ocfs2/super.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/fs/ocfs2/super.c b/fs/ocfs2/super.c
index 80efa5699fb0..63b3fa519758 100644
--- a/fs/ocfs2/super.c
+++ b/fs/ocfs2/super.c
@@ -474,9 +474,8 @@ static int ocfs2_init_global_system_inodes(struct
ocfs2_super *osb)
new = ocfs2_get_system_file_inode(osb, i, osb->slot_num);
if (!new) {
ocfs2_release_system_inodes(osb);
- status = -EINVAL;
+ status = ocfs2_is_soft_readonly(osb) ? -EROFS : -EINVAL;
mlog_errno(status);
- /* FIXME: Should ERROR_RO_FS */
mlog(ML_ERROR, "Unable to load system inode %d, "
"possibly corrupt fs?", i);
goto bail;
@@ -505,7 +504,7 @@ static int ocfs2_init_local_system_inodes(struct
ocfs2_super *osb)
new = ocfs2_get_system_file_inode(osb, i, osb->slot_num);
if (!new) {
ocfs2_release_system_inodes(osb);
- status = -EINVAL;
+ status = ocfs2_is_soft_readonly(osb) ? -EROFS : -EINVAL;
mlog(ML_ERROR, "status=%d, sysfile=%d, slot=%d\n",
status, i, osb->slot_num);
goto bail;
--
2.15.1
[PATCH AUTOSEL for 4.15 143/189] ACPI: processor_perflib: Do not send _PPC change notification if not ready
From: Chen Yu
[ Upstream commit ba1edb9a5125a617d612f98eead14b9b84e75c3a ]
The following warning was triggered after resumed from S3 -
if all the nonboot CPUs were put offline before suspend:
[ 1840.329515] unchecked MSR access error: RDMSR from 0x771 at rIP:
0x86061e3a (native_read_msr+0xa/0x30)
[ 1840.329516] Call Trace:
[ 1840.329521] __rdmsr_on_cpu+0x33/0x50
[ 1840.329525] generic_exec_single+0x81/0xb0
[ 1840.329527] smp_call_function_single+0xd2/0x100
[ 1840.329530] ? acpi_ds_result_pop+0xdd/0xf2
[ 1840.329532] ? acpi_ds_create_operand+0x215/0x23c
[ 1840.329534] rdmsrl_on_cpu+0x57/0x80
[ 1840.329536] ? cpumask_next+0x1b/0x20
[ 1840.329538] ? rdmsrl_on_cpu+0x57/0x80
[ 1840.329541] intel_pstate_update_perf_limits+0xf3/0x220
[ 1840.329544] ? notifier_call_chain+0x4a/0x70
[ 1840.329546] intel_pstate_set_policy+0x4e/0x150
[ 1840.329548] cpufreq_set_policy+0xcd/0x2f0
[ 1840.329550] cpufreq_update_policy+0xb2/0x130
[ 1840.329552] ? cpufreq_update_policy+0x130/0x130
[ 1840.329556] acpi_processor_ppc_has_changed+0x65/0x80
[ 1840.329558] acpi_processor_notify+0x80/0x100
[ 1840.329561] acpi_ev_notify_dispatch+0x44/0x5c
[ 1840.329563] acpi_os_execute_deferred+0x14/0x20
[ 1840.329565] process_one_work+0x193/0x3c0
[ 1840.329567] worker_thread+0x35/0x3b0
[ 1840.329569] kthread+0x125/0x140
[ 1840.329571] ? process_one_work+0x3c0/0x3c0
[ 1840.329572] ? kthread_park+0x60/0x60
[ 1840.329575] ? do_syscall_64+0x67/0x180
[ 1840.329577] ret_from_fork+0x25/0x30
[ 1840.329585] unchecked MSR access error: WRMSR to 0x774 (tried to write
0x) at rIP: 0x86061f78 (native_write_msr+0x8/0x30)
[ 1840.329586] Call Trace:
[ 1840.329587] __wrmsr_on_cpu+0x37/0x40
[ 1840.329589] generic_exec_single+0x81/0xb0
[ 1840.329592] smp_call_function_single+0xd2/0x100
[ 1840.329594] ? acpi_ds_create_operand+0x215/0x23c
[ 1840.329595] ? cpumask_next+0x1b/0x20
[ 1840.329597] wrmsrl_on_cpu+0x57/0x70
[ 1840.329598] ? rdmsrl_on_cpu+0x57/0x80
[ 1840.329599] ? wrmsrl_on_cpu+0x57/0x70
[ 1840.329602] intel_pstate_hwp_set+0xd3/0x150
[ 1840.329604] intel_pstate_set_policy+0x119/0x150
[ 1840.329606] cpufreq_set_policy+0xcd/0x2f0
[ 1840.329607] cpufreq_update_policy+0xb2/0x130
[ 1840.329610] ? cpufreq_update_policy+0x130/0x130
[ 1840.329613] acpi_processor_ppc_has_changed+0x65/0x80
[ 1840.329615] acpi_processor_notify+0x80/0x100
[ 1840.329617] acpi_ev_notify_dispatch+0x44/0x5c
[ 1840.329619] acpi_os_execute_deferred+0x14/0x20
[ 1840.329620] process_one_work+0x193/0x3c0
[ 1840.329622] worker_thread+0x35/0x3b0
[ 1840.329624] kthread+0x125/0x140
[ 1840.329625] ? process_one_work+0x3c0/0x3c0
[ 1840.329626] ? kthread_park+0x60/0x60
[ 1840.329628] ? do_syscall_64+0x67/0x180
[ 1840.329631] ret_from_fork+0x25/0x30
This is because if there's only one online CPU, the MSR_PM_ENABLE
(package wide)can not be enabled after resumed, due to
intel_pstate_hwp_enable() will only be invoked on AP's online
process after resumed - if there's no AP online, the HWP remains
disabled after resumed (BIOS has disabled it in S3). Then if
there comes a _PPC change notification which touches HWP register
during this stage, the warning is triggered.
Since we don't call acpi_processor_register_performance() when
HWP is enabled, the pr->performance will be NULL. When this is
NULL we don't need to do _PPC change notification.
Reported-by: Doug Smythies
Suggested-by: Srinivas Pandruvada
Signed-off-by: Yu Chen
Signed-off-by: Rafael J. Wysocki
Signed-off-by: Sasha Levin
---
drivers/acpi/processor_perflib.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/acpi/processor_perflib.c b/drivers/acpi/processor_perflib.c
index 18b72eec3507..c7cf48ad5cb9 100644
--- a/drivers/acpi/processor_perflib.c
+++ b/drivers/acpi/processor_perflib.c
@@ -159,7 +159,7 @@ void acpi_processor_ppc_has_changed(struct acpi_processor
*pr, int event_flag)
{
int ret;
- if (ignore_ppc) {
+ if (ignore_ppc || !pr->performance) {
/*
* Only when it is notification event, the _OST object
* will be evaluated. Otherwise it is skipped.
--
2.15.1
[PATCH AUTOSEL for 4.15 151/189] perf evsel: Fix period/freq terms setup
From: Jiri Olsa
[ Upstream commit 49c0ae80eb32426fa133246200628e529067c595 ]
Stephane reported that we don't set properly PERIOD sample type for
events with period term defined.
Before:
$ perf record -e cpu/cpu-cycles,period=1000/u ls
$ perf evlist -v
cpu/cpu-cycles,period=1000/u: ... sample_type: IP|TID|TIME|PERIOD, ...
After:
$ perf record -e cpu/cpu-cycles,period=1000/u ls
$ perf evlist -v
cpu/cpu-cycles,period=1000/u: ... sample_type: IP|TID|TIME, ...
Setting PERIOD sample type based on period term setup.
Committer note:
When we use -c or a period=N term in the event definition, then we don't
need to ask the kernel, for this event, via perf_event_attr.sample_type
|= PERF_SAMPLE_PERIOD, to put the event period in each sample for this
event, as we know it already, it is in perf_event_attr.sample_period.
Reported-by: Stephane Eranian
Signed-off-by: Jiri Olsa
Tested-by: Stephane Eranian
Cc: Alexander Shishkin
Cc: Andi Kleen
Cc: David Ahern
Cc: Namhyung Kim
Cc: Peter Zijlstra
Link: http://lkml.kernel.org/r/20180201083812.11359-2-jo...@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo
Signed-off-by: Sasha Levin
---
tools/perf/util/evsel.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/tools/perf/util/evsel.c b/tools/perf/util/evsel.c
index d23a8c51b307..7349a5d22464 100644
--- a/tools/perf/util/evsel.c
+++ b/tools/perf/util/evsel.c
@@ -736,12 +736,14 @@ static void apply_config_terms(struct perf_evsel *evsel,
if (!(term->weak && opts->user_interval != ULLONG_MAX))
{
attr->sample_period = term->val.period;
attr->freq = 0;
+ perf_evsel__reset_sample_bit(evsel, PERIOD);
}
break;
case PERF_EVSEL__CONFIG_TERM_FREQ:
if (!(term->weak && opts->user_freq != UINT_MAX)) {
attr->sample_freq = term->val.freq;
attr->freq = 1;
+ perf_evsel__set_sample_bit(evsel, PERIOD);
}
break;
case PERF_EVSEL__CONFIG_TERM_TIME:
--
2.15.1
[PATCH AUTOSEL for 4.15 180/189] PM / wakeirq: Fix unbalanced IRQ enable for wakeirq
From: Tony Lindgren
[ Upstream commit 69728051f5bf15efaf6edfbcfe1b5a49a2437918 ]
If a device is runtime PM suspended when we enter suspend and has
a dedicated wake IRQ, we can get the following warning:
WARNING: CPU: 0 PID: 108 at kernel/irq/manage.c:526 enable_irq+0x40/0x94
[ 102.087860] Unbalanced enable for IRQ 147
...
(enable_irq) from [] (dev_pm_arm_wake_irq+0x4c/0x60)
(dev_pm_arm_wake_irq) from []
(device_wakeup_arm_wake_irqs+0x58/0x9c)
(device_wakeup_arm_wake_irqs) from []
(dpm_suspend_noirq+0x10/0x48)
(dpm_suspend_noirq) from []
(suspend_devices_and_enter+0x30c/0xf14)
(suspend_devices_and_enter) from []
(enter_state+0xad4/0xbd8)
(enter_state) from [] (pm_suspend+0x38/0x98)
(pm_suspend) from [] (state_store+0x68/0xc8)
This is because the dedicated wake IRQ for the device may have been
already enabled earlier by dev_pm_enable_wake_irq_check(). Fix the
issue by checking for runtime PM suspended status.
This issue can be easily reproduced by setting serial console log level
to zero, letting the serial console idle, and suspend the system from
an ssh terminal. On resume, dmesg will have the warning above.
The reason why I have not run into this issue earlier has been that I
typically run my PM test cases from on a serial console instead over ssh.
Fixes: c84345597558 (PM / wakeirq: Enable dedicated wakeirq for suspend)
Signed-off-by: Tony Lindgren
Signed-off-by: Rafael J. Wysocki
Signed-off-by: Sasha Levin
---
drivers/base/power/wakeirq.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/base/power/wakeirq.c b/drivers/base/power/wakeirq.c
index ae0429827f31..67c50738834b 100644
--- a/drivers/base/power/wakeirq.c
+++ b/drivers/base/power/wakeirq.c
@@ -323,7 +323,8 @@ void dev_pm_arm_wake_irq(struct wake_irq *wirq)
return;
if (device_may_wakeup(wirq->dev)) {
- if (wirq->status & WAKE_IRQ_DEDICATED_ALLOCATED)
+ if (wirq->status & WAKE_IRQ_DEDICATED_ALLOCATED &&
+ !pm_runtime_status_suspended(wirq->dev))
enable_irq(wirq->irq);
enable_irq_wake(wirq->irq);
@@ -345,7 +346,8 @@ void dev_pm_disarm_wake_irq(struct wake_irq *wirq)
if (device_may_wakeup(wirq->dev)) {
disable_irq_wake(wirq->irq);
- if (wirq->status & WAKE_IRQ_DEDICATED_ALLOCATED)
+ if (wirq->status & WAKE_IRQ_DEDICATED_ALLOCATED &&
+ !pm_runtime_status_suspended(wirq->dev))
disable_irq_nosync(wirq->irq);
}
}
--
2.15.1
[PATCH AUTOSEL for 4.15 161/189] bcache: fix for allocator and register thread race
From: Tang Junhui
[ Upstream commit 682811b3ce1a5a4e20d700939a9042f01dbc66c4 ]
After long time running of random small IO writing,
I reboot the machine, and after the machine power on,
I found bcache got stuck, the stack is:
[root@ceph153 ~]# cat /proc/2510/task/*/stack
[] closure_sync+0x25/0x90 [bcache]
[] bch_journal+0x118/0x2b0 [bcache]
[] bch_journal_meta+0x47/0x70 [bcache]
[] bch_prio_write+0x237/0x340 [bcache]
[] bch_allocator_thread+0x3c8/0x3d0 [bcache]
[] kthread+0xcf/0xe0
[] ret_from_fork+0x58/0x90
[] 0x
[root@ceph153 ~]# cat /proc/2038/task/*/stack
[] __bch_btree_map_nodes+0x12d/0x150 [bcache]
[] bch_btree_insert+0xf1/0x170 [bcache]
[] bch_journal_replay+0x13f/0x230 [bcache]
[] run_cache_set+0x79a/0x7c2 [bcache]
[] register_bcache+0xd48/0x1310 [bcache]
[] kobj_attr_store+0xf/0x20
[] sysfs_write_file+0xc6/0x140
[] vfs_write+0xbd/0x1e0
[] SyS_write+0x7f/0xe0
[] system_call_fastpath+0x16/0x1
The stack shows the register thread and allocator thread
were getting stuck when registering cache device.
I reboot the machine several times, the issue always
exsit in this machine.
I debug the code, and found the call trace as bellow:
register_bcache()
==>run_cache_set()
==>bch_journal_replay()
==>bch_btree_insert()
==>__bch_btree_map_nodes()
==>btree_insert_fn()
==>btree_split() //node need split
==>btree_check_reserve()
In btree_check_reserve(), It will check if there is enough buckets
of RESERVE_BTREE type, since allocator thread did not work yet, so
no buckets of RESERVE_BTREE type allocated, so the register thread
waits on c->btree_cache_wait, and goes to sleep.
Then the allocator thread initialized, the call trace is bellow:
bch_allocator_thread()
==>bch_prio_write()
==>bch_journal_meta()
==>bch_journal()
==>journal_wait_for_write()
In journal_wait_for_write(), It will check if journal is full by
journal_full(), but the long time random small IO writing
causes the exhaustion of journal buckets(journal.blocks_free=0),
In order to release the journal buckets,
the allocator calls btree_flush_write() to flush keys to
btree nodes, and waits on c->journal.wait until btree nodes writing
over or there has already some journal buckets space, then the
allocator thread goes to sleep. but in btree_flush_write(), since
bch_journal_replay() is not finished, so no btree nodes have journal
(condition "if (btree_current_write(b)->journal)" never satisfied),
so we got no btree node to flush, no journal bucket released,
and allocator sleep all the times.
Through the above analysis, we can see that:
1) Register thread wait for allocator thread to allocate buckets of
RESERVE_BTREE type;
2) Alloctor thread wait for register thread to replay journal, so it
can flush btree nodes and get journal bucket.
then they are all got stuck by waiting for each other.
Hua Rui provided a patch for me, by allocating some buckets of
RESERVE_BTREE type in advance, so the register thread can get bucket
when btree node splitting and no need to waiting for the allocator
thread. I tested it, it has effect, and register thread run a step
forward, but finally are still got stuck, the reason is only 8 bucket
of RESERVE_BTREE type were allocated, and in bch_journal_replay(),
after 2 btree nodes splitting, only 4 bucket of RESERVE_BTREE type left,
then btree_check_reserve() is not satisfied anymore, so it goes to sleep
again, and in the same time, alloctor thread did not flush enough btree
nodes to release a journal bucket, so they all got stuck again.
So we need to allocate more buckets of RESERVE_BTREE type in advance,
but how much is enough? By experience and test, I think it should be
as much as journal buckets. Then I modify the code as this patch,
and test in the machine, and it works.
This patch modified base on Hua Rui’s patch, and allocate more buckets
of RESERVE_BTREE type in advance to avoid register thread and allocate
thread going to wait for each other.
[patch v2] ca->sb.njournal_buckets would be 0 in the first time after
cache creation, and no journal exists, so just 8 btree buckets is OK.
Signed-off-by: Hua Rui
Signed-off-by: Tang Junhui
Reviewed-by: Michael Lyle
Signed-off-by: Jens Axboe
Signed-off-by: Sasha Levin
---
drivers/md/bcache/btree.c | 9 ++---
drivers/md/bcache/super.c | 13 -
2 files changed, 18 insertions(+), 4 deletions(-)
diff --git a/drivers/md/bcache/btree.c b/drivers/md/bcache/btree.c
index 81e8dc3dbe5e..45561f28e58a 100644
--- a/drivers/md/bcache/btree.c
+++ b/drivers/md/bcache/btree.c
@@ -1871,14 +1871,17 @@ void bch_initial_gc_finish(struct cache_set *c)
*/
for_each_cache(ca, c, i) {
for_each_bucket(b, ca) {
- if (fifo_full(&ca->free[RESERVE_PRIO]))
+ if (fifo_full(&ca->free[RESERVE_PRIO]) &&
+ fifo_full(&ca->free[RESERVE_BTREE]))
[PATCH AUTOSEL for 4.14 021/161] i40iw: Free IEQ resources
From: Mustafa Ismail
[ Upstream commit f20d429511affab6a2a9129f46042f43e6ffe396 ]
The iWARP Exception Queue (IEQ) resources are not freed when a QP is
destroyed. Fix this by freeing IEQ resources when freeing QP resources.
Fixes: d37498417947 ("i40iw: add files for iwarp interface")
Signed-off-by: Mustafa Ismail
Signed-off-by: Shiraz Saleem
Signed-off-by: Jason Gunthorpe
Signed-off-by: Sasha Levin
---
drivers/infiniband/hw/i40iw/i40iw_puda.c | 3 +--
drivers/infiniband/hw/i40iw/i40iw_puda.h | 1 +
drivers/infiniband/hw/i40iw/i40iw_verbs.c | 1 +
3 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/infiniband/hw/i40iw/i40iw_puda.c
b/drivers/infiniband/hw/i40iw/i40iw_puda.c
index 59f70676f0e0..74c7f6879084 100644
--- a/drivers/infiniband/hw/i40iw/i40iw_puda.c
+++ b/drivers/infiniband/hw/i40iw/i40iw_puda.c
@@ -48,7 +48,6 @@ static void i40iw_ieq_tx_compl(struct i40iw_sc_vsi *vsi, void
*sqwrid);
static void i40iw_ilq_putback_rcvbuf(struct i40iw_sc_qp *qp, u32 wqe_idx);
static enum i40iw_status_code i40iw_puda_replenish_rq(struct i40iw_puda_rsrc
*rsrc, bool initial);
-static void i40iw_ieq_cleanup_qp(struct i40iw_puda_rsrc *ieq, struct
i40iw_sc_qp *qp);
/**
* i40iw_puda_get_listbuf - get buffer from puda list
* @list: list to use for buffers (ILQ or IEQ)
@@ -1480,7 +1479,7 @@ static void i40iw_ieq_tx_compl(struct i40iw_sc_vsi *vsi,
void *sqwrid)
* @ieq: ieq resource
* @qp: all pending fpdu buffers
*/
-static void i40iw_ieq_cleanup_qp(struct i40iw_puda_rsrc *ieq, struct
i40iw_sc_qp *qp)
+void i40iw_ieq_cleanup_qp(struct i40iw_puda_rsrc *ieq, struct i40iw_sc_qp *qp)
{
struct i40iw_puda_buf *buf;
struct i40iw_pfpdu *pfpdu = &qp->pfpdu;
diff --git a/drivers/infiniband/hw/i40iw/i40iw_puda.h
b/drivers/infiniband/hw/i40iw/i40iw_puda.h
index dba05ce7d392..ebe37f157d90 100644
--- a/drivers/infiniband/hw/i40iw/i40iw_puda.h
+++ b/drivers/infiniband/hw/i40iw/i40iw_puda.h
@@ -186,4 +186,5 @@ enum i40iw_status_code i40iw_cqp_qp_create_cmd(struct
i40iw_sc_dev *dev, struct
enum i40iw_status_code i40iw_cqp_cq_create_cmd(struct i40iw_sc_dev *dev,
struct i40iw_sc_cq *cq);
void i40iw_cqp_qp_destroy_cmd(struct i40iw_sc_dev *dev, struct i40iw_sc_qp
*qp);
void i40iw_cqp_cq_destroy_cmd(struct i40iw_sc_dev *dev, struct i40iw_sc_cq
*cq);
+void i40iw_ieq_cleanup_qp(struct i40iw_puda_rsrc *ieq, struct i40iw_sc_qp *qp);
#endif
diff --git a/drivers/infiniband/hw/i40iw/i40iw_verbs.c
b/drivers/infiniband/hw/i40iw/i40iw_verbs.c
index 62be0a41ad0b..9e7ae7161d2f 100644
--- a/drivers/infiniband/hw/i40iw/i40iw_verbs.c
+++ b/drivers/infiniband/hw/i40iw/i40iw_verbs.c
@@ -428,6 +428,7 @@ void i40iw_free_qp_resources(struct i40iw_device *iwdev,
{
struct i40iw_pbl *iwpbl = &iwqp->iwpbl;
+ i40iw_ieq_cleanup_qp(iwdev->vsi.ieq, &iwqp->sc_qp);
i40iw_dealloc_push_page(iwdev, &iwqp->sc_qp);
if (qp_num)
i40iw_free_resource(iwdev, iwdev->allocated_qps, qp_num);
--
2.15.1
[PATCH AUTOSEL for 4.14 037/161] net: stmmac: dwmac-meson8b: propagate rate changes to the parent clock
From: Martin Blumenstingl
[ Upstream commit fb7d38a70e1d8ffd54f7a7464dcc4889d7e490ad ]
On Meson8b the only valid input clock is MPLL2. The bootloader
configures that to run at 52394Hz which cannot be divided evenly
down to 125MHz using the m250_div clock. Currently the common clock
framework chooses a m250_div of 2 - with the internal fixed
"divide by 10" this results in a RGMII TX clock of 125001197Hz (120Hz
above the requested 125MHz).
Letting the common clock framework propagate the rate changes up to the
parent of m250_mux allows us to get the best possible clock rate. With
this patch the common clock framework calculates a rate of
very-close-to-250MHz (24701Hz to be exact) for the MPLL2 clock
(which is the mux input). Dividing that by 2 (which is an internal,
fixed divider for the RGMII TX clock) gives us an RGMII TX clock of
124999850Hz (which is only 150Hz off the requested 125MHz, compared to
1197Hz based on the MPLL2 rate set by u-boot and the Amlogic GPL kernel
sources).
SoCs from the Meson GX series are not affected by this change because
the input clock is FCLK_DIV2 whose rate cannot be changed (which is fine
since it's running at 1GHz, so it's already a multiple of 250MHz and
125MHz).
Fixes: 566e8251625304 ("net: stmmac: add a glue driver for the Amlogic Meson 8b
/ GXBB DWMAC")
Suggested-by: Jerome Brunet
Signed-off-by: Martin Blumenstingl
Reviewed-by: Jerome Brunet
Tested-by: Jerome Brunet
Signed-off-by: David S. Miller
Signed-off-by: Sasha Levin
---
drivers/net/ethernet/stmicro/stmmac/dwmac-meson8b.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-meson8b.c
b/drivers/net/ethernet/stmicro/stmmac/dwmac-meson8b.c
index 157e12e15f28..8be4b32544ef 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-meson8b.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-meson8b.c
@@ -116,7 +116,7 @@ static int meson8b_init_clk(struct meson8b_dwmac *dwmac)
snprintf(clk_name, sizeof(clk_name), "%s#m250_sel", dev_name(dev));
init.name = clk_name;
init.ops = &clk_mux_ops;
- init.flags = 0;
+ init.flags = CLK_SET_RATE_PARENT;
init.parent_names = mux_parent_names;
init.num_parents = MUX_CLK_NUM_PARENTS;
--
2.15.1
[PATCH AUTOSEL for 4.14 032/161] dm thin: fix documentation relative to low water mark threshold
From: mulhern [ Upstream commit 9b28a1102efc75d81298198166ead87d643a29ce ] Fixes: 1. The use of "exceeds" when the opposite of exceeds, falls below, was meant. 2. Properly speaking, a table can not exceed a threshold. It emphasizes the important point, which is that it is the userspace daemon's responsibility to check for low free space when a device is resumed, since it won't get a special event indicating low free space in that situation. Signed-off-by: mulhern Signed-off-by: Mike Snitzer Signed-off-by: Sasha Levin --- Documentation/device-mapper/thin-provisioning.txt | 8 +--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/Documentation/device-mapper/thin-provisioning.txt b/Documentation/device-mapper/thin-provisioning.txt index 1699a55b7b70..ef639960b272 100644 --- a/Documentation/device-mapper/thin-provisioning.txt +++ b/Documentation/device-mapper/thin-provisioning.txt @@ -112,9 +112,11 @@ $low_water_mark is expressed in blocks of size $data_block_size. If free space on the data device drops below this level then a dm event will be triggered which a userspace daemon should catch allowing it to extend the pool device. Only one such event will be sent. -Resuming a device with a new table itself triggers an event so the -userspace daemon can use this to detect a situation where a new table -already exceeds the threshold. + +No special event is triggered if a just resumed device's free space is below +the low water mark. However, resuming a device always triggers an +event; a userspace daemon should verify that free space exceeds the low +water mark when handling this event. A low water mark for the metadata device is maintained in the kernel and will trigger a dm event if free space on the metadata device drops below -- 2.15.1
[PATCH AUTOSEL for 4.14 005/161] ALSA: hda - Use IS_REACHABLE() for dependency on input
From: Takashi Iwai
[ Upstream commit c469652bb5e8fb715db7d152f46d33b3740c9b87 ]
The commit ffcd28d88e4f ("ALSA: hda - Select INPUT for Realtek
HD-audio codec") introduced the reverse-selection of CONFIG_INPUT for
Realtek codec in order to avoid the mess with dependency between
built-in and modules. Later on, we obtained IS_REACHABLE() macro
exactly for this kind of problems, and now we can remove th INPUT
selection in Kconfig and put IS_REACHABLE(INPUT) to the appropriate
places in the code, so that the driver doesn't need to select other
subsystem forcibly.
Fixes: ffcd28d88e4f ("ALSA: hda - Select INPUT for Realtek HD-audio codec")
Reported-by: Randy Dunlap
Acked-by: Randy Dunlap # and build-tested
Signed-off-by: Takashi Iwai
Signed-off-by: Sasha Levin
---
sound/pci/hda/Kconfig | 1 -
sound/pci/hda/patch_realtek.c | 5 +
2 files changed, 5 insertions(+), 1 deletion(-)
diff --git a/sound/pci/hda/Kconfig b/sound/pci/hda/Kconfig
index 7f3b5ed81995..f7a492c382d9 100644
--- a/sound/pci/hda/Kconfig
+++ b/sound/pci/hda/Kconfig
@@ -88,7 +88,6 @@ config SND_HDA_PATCH_LOADER
config SND_HDA_CODEC_REALTEK
tristate "Build Realtek HD-audio codec support"
select SND_HDA_GENERIC
- select INPUT
help
Say Y or M here to include Realtek HD-audio codec support in
snd-hda-intel driver, such as ALC880.
diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c
index e44a9758f2eb..0cf552a0d5c5 100644
--- a/sound/pci/hda/patch_realtek.c
+++ b/sound/pci/hda/patch_realtek.c
@@ -3721,6 +3721,7 @@ static void alc280_fixup_hp_gpio4(struct hda_codec *codec,
}
}
+#if IS_REACHABLE(INPUT)
static void gpio2_mic_hotkey_event(struct hda_codec *codec,
struct hda_jack_callback *event)
{
@@ -3853,6 +3854,10 @@ static void alc233_fixup_lenovo_line2_mic_hotkey(struct
hda_codec *codec,
spec->kb_dev = NULL;
}
}
+#else /* INPUT */
+#define alc280_fixup_hp_gpio2_mic_hotkey NULL
+#define alc233_fixup_lenovo_line2_mic_hotkey NULL
+#endif /* INPUT */
static void alc269_fixup_hp_line1_mic1_led(struct hda_codec *codec,
const struct hda_fixup *fix, int action)
--
2.15.1
[PATCH AUTOSEL for 4.14 020/161] Input: synaptics - reset the ABS_X/Y fuzz after initializing MT axes
From: Peter Hutterer [ Upstream commit 19eb4ed1141bd1096b9bc84ba9c4d03d5830c143 ] input_mt_init_slots() resets the ABS_X/Y fuzz to 0 and expects the driver to call input_mt_report_pointer_emulation(). That is based on the MT position bits which are already defuzzed - hence a fuzz of 0. In the case of synaptics semi-mt devices, we report the ABS_X/Y axes manually. This results in the MT position being defuzzed but the single-touch emulation missing that defuzzing. Work around this by re-initializing the ABS_X/Y axes after the MT axis to get the same fuzz value back. https://bugs.freedesktop.org/show_bug.cgi?id=104533 Signed-off-by: Peter Hutterer Signed-off-by: Dmitry Torokhov Signed-off-by: Sasha Levin --- drivers/input/mouse/synaptics.c | 10 ++ 1 file changed, 10 insertions(+) diff --git a/drivers/input/mouse/synaptics.c b/drivers/input/mouse/synaptics.c index ee5466a374bf..a246fc686bb7 100644 --- a/drivers/input/mouse/synaptics.c +++ b/drivers/input/mouse/synaptics.c @@ -1280,6 +1280,16 @@ static void set_input_params(struct psmouse *psmouse, INPUT_MT_POINTER | (cr48_profile_sensor ? INPUT_MT_TRACK : INPUT_MT_SEMI_MT)); + + /* +* For semi-mt devices we send ABS_X/Y ourselves instead of +* input_mt_report_pointer_emulation. But +* input_mt_init_slots() resets the fuzz to 0, leading to a +* filtered ABS_MT_POSITION_X but an unfiltered ABS_X +* position. Let's re-initialize ABS_X/Y here. +*/ + if (!cr48_profile_sensor) + set_abs_position_params(dev, &priv->info, ABS_X, ABS_Y); } if (SYN_CAP_PALMDETECT(info->capabilities)) -- 2.15.1
[PATCH AUTOSEL for 4.14 059/161] scsi: devinfo: fix format of the device list
From: Xose Vazquez Perez
[ Upstream commit 3f884a0a8bdf28cfd1e9987d54d83350096cdd46 ]
Replace "" with NULL for product revision level, and merge TEXEL
duplicate entries.
Cc: Hannes Reinecke
Cc: Martin K. Petersen
Cc: James E.J. Bottomley
Cc: SCSI ML
Signed-off-by: Xose Vazquez Perez
Signed-off-by: Martin K. Petersen
Signed-off-by: Sasha Levin
---
drivers/scsi/scsi_devinfo.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/scsi/scsi_devinfo.c b/drivers/scsi/scsi_devinfo.c
index cfc095f45e26..ea947a7c2596 100644
--- a/drivers/scsi/scsi_devinfo.c
+++ b/drivers/scsi/scsi_devinfo.c
@@ -109,8 +109,8 @@ static struct {
* seagate controller, which causes SCSI code to reset bus.
*/
{"HP", "C1750A", "3226", BLIST_NOLUN}, /* scanjet iic */
- {"HP", "C1790A", "", BLIST_NOLUN}, /* scanjet iip */
- {"HP", "C2500A", "", BLIST_NOLUN}, /* scanjet iicx */
+ {"HP", "C1790A", NULL, BLIST_NOLUN},/* scanjet iip */
+ {"HP", "C2500A", NULL, BLIST_NOLUN},/* scanjet iicx */
{"MEDIAVIS", "CDR-H93MV", "1.31", BLIST_NOLUN}, /* locks up */
{"MICROTEK", "ScanMaker II", "5.61", BLIST_NOLUN}, /* responds to
all lun */
{"MITSUMI", "CD-R CR-2201CS", "6119", BLIST_NOLUN}, /* locks up */
@@ -120,7 +120,7 @@ static struct {
{"QUANTUM", "FIREBALL ST4.3S", "0F0C", BLIST_NOLUN},/* locks up */
{"RELISYS", "Scorpio", NULL, BLIST_NOLUN}, /* responds to all lun
*/
{"SANKYO", "CP525", "6.64", BLIST_NOLUN}, /* causes failed REQ
SENSE, extra reset */
- {"TEXEL", "CD-ROM", "1.06", BLIST_NOLUN},
+ {"TEXEL", "CD-ROM", "1.06", BLIST_NOLUN | BLIST_BORKEN},
{"transtec", "T5008", "0001", BLIST_NOREPORTLUN },
{"YAMAHA", "CDR100", "1.00", BLIST_NOLUN}, /* locks up */
{"YAMAHA", "CDR102", "1.00", BLIST_NOLUN}, /* locks up */
@@ -255,7 +255,6 @@ static struct {
{"ST650211", "CF", NULL, BLIST_RETRY_HWERROR},
{"SUN", "T300", "*", BLIST_SPARSELUN},
{"SUN", "T4", "*", BLIST_SPARSELUN},
- {"TEXEL", "CD-ROM", "1.06", BLIST_BORKEN},
{"Tornado-", "F4", "*", BLIST_NOREPORTLUN},
{"TOSHIBA", "CDROM", NULL, BLIST_ISROM},
{"TOSHIBA", "CD-ROM", NULL, BLIST_ISROM},
--
2.15.1
[PATCH AUTOSEL for 4.14 049/161] mac80211_hwsim: fix possible memory leak in hwsim_new_radio_nl()
From: "weiyongjun (A)"
[ Upstream commit 0ddcff49b672239dda94d70d0fcf50317a9f4b51 ]
'hwname' is malloced in hwsim_new_radio_nl() and should be freed
before leaving from the error handling cases, otherwise it will cause
memory leak.
Fixes: ff4dd73dd2b4 ("mac80211_hwsim: check HWSIM_ATTR_RADIO_NAME length")
Signed-off-by: Wei Yongjun
Reviewed-by: Ben Hutchings
Signed-off-by: Johannes Berg
Signed-off-by: Sasha Levin
---
drivers/net/wireless/mac80211_hwsim.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/mac80211_hwsim.c
b/drivers/net/wireless/mac80211_hwsim.c
index d148dbf3beeb..977fd7aa2082 100644
--- a/drivers/net/wireless/mac80211_hwsim.c
+++ b/drivers/net/wireless/mac80211_hwsim.c
@@ -3153,8 +3153,10 @@ static int hwsim_new_radio_nl(struct sk_buff *msg,
struct genl_info *info)
if (info->attrs[HWSIM_ATTR_REG_CUSTOM_REG]) {
u32 idx = nla_get_u32(info->attrs[HWSIM_ATTR_REG_CUSTOM_REG]);
- if (idx >= ARRAY_SIZE(hwsim_world_regdom_custom))
+ if (idx >= ARRAY_SIZE(hwsim_world_regdom_custom)) {
+ kfree(hwname);
return -EINVAL;
+ }
param.regd = hwsim_world_regdom_custom[idx];
}
--
2.15.1
[PATCH AUTOSEL for 4.14 062/161] HID: roccat: prevent an out of bounds read in kovaplus_profile_activated()
From: Dan Carpenter
[ Upstream commit 7ad81482cad67cbe1ec808490d1ddfc420c42008 ]
We get the "new_profile_index" value from the mouse device when we're
handling raw events. Smatch taints it as untrusted data and complains
that we need a bounds check. This seems like a reasonable warning
otherwise there is a small read beyond the end of the array.
Fixes: 0e70f97f257e ("HID: roccat: Add support for Kova[+] mouse")
Signed-off-by: Dan Carpenter
Acked-by: Silvan Jegen
Signed-off-by: Jiri Kosina
Signed-off-by: Sasha Levin
---
drivers/hid/hid-roccat-kovaplus.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/hid/hid-roccat-kovaplus.c
b/drivers/hid/hid-roccat-kovaplus.c
index 43617fb28b87..317c9c2c0a7c 100644
--- a/drivers/hid/hid-roccat-kovaplus.c
+++ b/drivers/hid/hid-roccat-kovaplus.c
@@ -37,6 +37,8 @@ static uint kovaplus_convert_event_cpi(uint value)
static void kovaplus_profile_activated(struct kovaplus_device *kovaplus,
uint new_profile_index)
{
+ if (new_profile_index >= ARRAY_SIZE(kovaplus->profile_settings))
+ return;
kovaplus->actual_profile = new_profile_index;
kovaplus->actual_cpi =
kovaplus->profile_settings[new_profile_index].cpi_startup_level;
kovaplus->actual_x_sensitivity =
kovaplus->profile_settings[new_profile_index].sensitivity_x;
--
2.15.1
[PATCH AUTOSEL for 4.14 035/161] ubifs: Fix uninitialized variable in search_dh_cookie()
From: Geert Uytterhoeven
[ Upstream commit c877154d307f4a91e0b5b85b75535713dab945ae ]
fs/ubifs/tnc.c: In function ‘search_dh_cookie’:
fs/ubifs/tnc.c:1893: warning: ‘err’ is used uninitialized in this function
Indeed, err is always used uninitialized.
According to an original review comment from Hyunchul, acknowledged by
Richard, err should be initialized to -ENOENT to avoid the first call to
tnc_next(). But we can achieve the same by reordering the code.
Fixes: 781f675e2d7e ("ubifs: Fix unlink code wrt. double hash lookups")
Reported-by: Hyunchul Lee
Signed-off-by: Geert Uytterhoeven
Signed-off-by: Richard Weinberger
Signed-off-by: Sasha Levin
---
fs/ubifs/tnc.c | 21 +++--
1 file changed, 7 insertions(+), 14 deletions(-)
diff --git a/fs/ubifs/tnc.c b/fs/ubifs/tnc.c
index 0a213dcba2a1..ba3d0e0f8615 100644
--- a/fs/ubifs/tnc.c
+++ b/fs/ubifs/tnc.c
@@ -1890,35 +1890,28 @@ static int search_dh_cookie(struct ubifs_info *c, const
union ubifs_key *key,
union ubifs_key *dkey;
for (;;) {
- if (!err) {
- err = tnc_next(c, &znode, n);
- if (err)
- goto out;
- }
-
zbr = &znode->zbranch[*n];
dkey = &zbr->key;
if (key_inum(c, dkey) != key_inum(c, key) ||
key_type(c, dkey) != key_type(c, key)) {
- err = -ENOENT;
- goto out;
+ return -ENOENT;
}
err = tnc_read_hashed_node(c, zbr, dent);
if (err)
- goto out;
+ return err;
if (key_hash(c, key) == key_hash(c, dkey) &&
le32_to_cpu(dent->cookie) == cookie) {
*zn = znode;
- goto out;
+ return 0;
}
- }
-
-out:
- return err;
+ err = tnc_next(c, &znode, n);
+ if (err)
+ return err;
+ }
}
static int do_lookup_dh(struct ubifs_info *c, const union ubifs_key *key,
--
2.15.1
[PATCH AUTOSEL for 4.14 076/161] tty: serial: exar: Relocate sleep wake-up handling
From: Aaron Sierra
[ Upstream commit c7e1b4059075c9e8eed101d7cc5da43e95eb5e18 ]
Exar sleep wake-up handling has been done on a per-channel basis by
virtue of INT0 being accessible from each channel's address space. I
believe this was initially done out of necessity, but now that Exar
devices have their own driver, we can do things more efficiently by
registering a dedicated INT0 handler at the PCI device level.
I see this change providing the following benefits:
1. If more than one port is active, eliminates the redundant bus
cycles for reading INT0 on every interrupt.
2. This note associated with hooking in the per-channel handler in
8250_port.c is resolved:
/* Fixme: probably not the best place for this */
Cc: Matt Schulte
Signed-off-by: Aaron Sierra
Signed-off-by: Greg Kroah-Hartman
Signed-off-by: Sasha Levin
---
drivers/tty/serial/8250/8250_exar.c | 34 ++
drivers/tty/serial/8250/8250_port.c | 26 --
2 files changed, 30 insertions(+), 30 deletions(-)
diff --git a/drivers/tty/serial/8250/8250_exar.c
b/drivers/tty/serial/8250/8250_exar.c
index c55624703fdf..e0aa5f03004c 100644
--- a/drivers/tty/serial/8250/8250_exar.c
+++ b/drivers/tty/serial/8250/8250_exar.c
@@ -37,6 +37,7 @@
#define PCI_DEVICE_ID_EXAR_XR17V4358 0x4358
#define PCI_DEVICE_ID_EXAR_XR17V8358 0x8358
+#define UART_EXAR_INT0 0x80
#define UART_EXAR_8XMODE 0x88/* 8X sampling rate select */
#define UART_EXAR_FCTR 0x08/* Feature Control Register */
@@ -124,6 +125,7 @@ struct exar8250_board {
struct exar8250 {
unsigned intnr;
struct exar8250_board *board;
+ void __iomem*virt;
int line[0];
};
@@ -134,12 +136,9 @@ static int default_setup(struct exar8250 *priv, struct
pci_dev *pcidev,
const struct exar8250_board *board = priv->board;
unsigned int bar = 0;
- if (!pcim_iomap_table(pcidev)[bar] && !pcim_iomap(pcidev, bar, 0))
- return -ENOMEM;
-
port->port.iotype = UPIO_MEM;
port->port.mapbase = pci_resource_start(pcidev, bar) + offset;
- port->port.membase = pcim_iomap_table(pcidev)[bar] + offset;
+ port->port.membase = priv->virt + offset;
port->port.regshift = board->reg_shift;
return 0;
@@ -423,6 +422,25 @@ static void pci_xr17v35x_exit(struct pci_dev *pcidev)
port->port.private_data = NULL;
}
+/*
+ * These Exar UARTs have an extra interrupt indicator that could fire for a
+ * few interrupts that are not presented/cleared through IIR. One of which is
+ * a wakeup interrupt when coming out of sleep. These interrupts are only
+ * cleared by reading global INT0 or INT1 registers as interrupts are
+ * associated with channel 0. The INT[3:0] registers _are_ accessible from each
+ * channel's address space, but for the sake of bus efficiency we register a
+ * dedicated handler at the PCI device level to handle them.
+ */
+static irqreturn_t exar_misc_handler(int irq, void *data)
+{
+ struct exar8250 *priv = data;
+
+ /* Clear all PCI interrupts by reading INT0. No effect on IIR */
+ ioread8(priv->virt + UART_EXAR_INT0);
+
+ return IRQ_HANDLED;
+}
+
static int
exar_pci_probe(struct pci_dev *pcidev, const struct pci_device_id *ent)
{
@@ -451,6 +469,9 @@ exar_pci_probe(struct pci_dev *pcidev, const struct
pci_device_id *ent)
return -ENOMEM;
priv->board = board;
+ priv->virt = pcim_iomap(pcidev, bar, 0);
+ if (!priv->virt)
+ return -ENOMEM;
pci_set_master(pcidev);
@@ -464,6 +485,11 @@ exar_pci_probe(struct pci_dev *pcidev, const struct
pci_device_id *ent)
uart.port.irq = pci_irq_vector(pcidev, 0);
uart.port.dev = &pcidev->dev;
+ rc = devm_request_irq(&pcidev->dev, uart.port.irq, exar_misc_handler,
+IRQF_SHARED, "exar_uart", priv);
+ if (rc)
+ return rc;
+
for (i = 0; i < nr_ports && i < maxnr; i++) {
rc = board->setup(priv, pcidev, &uart, i);
if (rc) {
diff --git a/drivers/tty/serial/8250/8250_port.c
b/drivers/tty/serial/8250/8250_port.c
index 8dcfd4978a03..e9d4420869dd 100644
--- a/drivers/tty/serial/8250/8250_port.c
+++ b/drivers/tty/serial/8250/8250_port.c
@@ -445,7 +445,6 @@ static void io_serial_out(struct uart_port *p, int offset,
int value)
}
static int serial8250_default_handle_irq(struct uart_port *port);
-static int exar_handle_irq(struct uart_port *port);
static void set_io_from_upio(struct uart_port *p)
{
@@ -1890,26 +1889,6 @@ static int serial8250_default_handle_irq(struct
uart_port *port)
return ret;
}
-/*
- * These Exar UARTs have an extra interrupt indicator that could
- * fire for a few unimplemented interrupts. One of which is a
- * wakeup event when coming out of sleep. Put this here just
[PATCH AUTOSEL for 4.14 111/161] IB/core: Map iWarp AH type to undefined in rdma_ah_find_type
From: Don Hiatt
[ Upstream commit 87daac68f77a3e21a1113f816e6a7be0b38bdde8 ]
iWarp devices do not support the creation of address handles
so return AH_ATTR_TYPE_UNDEFINED for all iWarp devices.
While we are here reduce the size of port_num to u8 and add
a comment.
Fixes: 44c58487d51a ("IB/core: Define 'ib' and 'roce' rdma_ah_attr types")
Reported-by: Parav Pandit
CC: Sean Hefty
Reviewed-by: Ira Weiny
Reviewed-by: Shiraz Saleem
Signed-off-by: Don Hiatt
Signed-off-by: Dennis Dalessandro
Signed-off-by: Jason Gunthorpe
Signed-off-by: Sasha Levin
---
include/rdma/ib_verbs.h | 20 ++--
1 file changed, 14 insertions(+), 6 deletions(-)
diff --git a/include/rdma/ib_verbs.h b/include/rdma/ib_verbs.h
index a9fae49a1883..08f3d8699a27 100644
--- a/include/rdma/ib_verbs.h
+++ b/include/rdma/ib_verbs.h
@@ -866,6 +866,7 @@ struct ib_mr_status {
__attribute_const__ enum ib_rate mult_to_ib_rate(int mult);
enum rdma_ah_attr_type {
+ RDMA_AH_ATTR_TYPE_UNDEFINED,
RDMA_AH_ATTR_TYPE_IB,
RDMA_AH_ATTR_TYPE_ROCE,
RDMA_AH_ATTR_TYPE_OPA,
@@ -3762,17 +3763,24 @@ static inline void rdma_ah_set_grh(struct rdma_ah_attr
*attr,
grh->traffic_class = traffic_class;
}
-/*Get AH type */
+/**
+ * rdma_ah_find_type - Return address handle type.
+ *
+ * @dev: Device to be checked
+ * @port_num: Port number
+ */
static inline enum rdma_ah_attr_type rdma_ah_find_type(struct ib_device *dev,
- u32 port_num)
+ u8 port_num)
{
if (rdma_protocol_roce(dev, port_num))
return RDMA_AH_ATTR_TYPE_ROCE;
- else if ((rdma_protocol_ib(dev, port_num)) &&
-(rdma_cap_opa_ah(dev, port_num)))
- return RDMA_AH_ATTR_TYPE_OPA;
- else
+ if (rdma_protocol_ib(dev, port_num)) {
+ if (rdma_cap_opa_ah(dev, port_num))
+ return RDMA_AH_ATTR_TYPE_OPA;
return RDMA_AH_ATTR_TYPE_IB;
+ }
+
+ return RDMA_AH_ATTR_TYPE_UNDEFINED;
}
/**
--
2.15.1
[PATCH AUTOSEL for 4.14 101/161] asm-generic: provide generic_pmdp_establish()
From: "Kirill A. Shutemov"
[ Upstream commit c58f0bb77ed8bf93dfdde762b01cb67eebbdfc29 ]
Patch series "Do not lose dirty bit on THP pages", v4.
Vlastimil noted that pmdp_invalidate() is not atomic and we can lose
dirty and access bits if CPU sets them after pmdp dereference, but
before set_pmd_at().
The bug can lead to data loss, but the race window is tiny and I haven't
seen any reports that suggested that it happens in reality. So I don't
think it worth sending it to stable.
Unfortunately, there's no way to address the issue in a generic way. We
need to fix all architectures that support THP one-by-one.
All architectures that have THP supported have to provide atomic
pmdp_invalidate() that returns previous value.
If generic implementation of pmdp_invalidate() is used, architecture
needs to provide atomic pmdp_estabish().
pmdp_estabish() is not used out-side generic implementation of
pmdp_invalidate() so far, but I think this can change in the future.
This patch (of 12):
This is an implementation of pmdp_establish() that is only suitable for
an architecture that doesn't have hardware dirty/accessed bits. In this
case we can't race with CPU which sets these bits and non-atomic
approach is fine.
Link:
http://lkml.kernel.org/r/20171213105756.69879-2-kirill.shute...@linux.intel.com
Signed-off-by: Kirill A. Shutemov
Cc: Vlastimil Babka
Cc: Andrea Arcangeli
Cc: Michal Hocko
Cc: Aneesh Kumar K.V
Cc: Catalin Marinas
Cc: David Daney
Cc: David Miller
Cc: H. Peter Anvin
Cc: Hugh Dickins
Cc: Ingo Molnar
Cc: Martin Schwidefsky
Cc: Nitin Gupta
Cc: Ralf Baechle
Cc: Thomas Gleixner
Cc: Vineet Gupta
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
Signed-off-by: Sasha Levin
---
include/asm-generic/pgtable.h | 15 +++
1 file changed, 15 insertions(+)
diff --git a/include/asm-generic/pgtable.h b/include/asm-generic/pgtable.h
index 77b891a8f191..2142bceaeb75 100644
--- a/include/asm-generic/pgtable.h
+++ b/include/asm-generic/pgtable.h
@@ -309,6 +309,21 @@ extern void pgtable_trans_huge_deposit(struct mm_struct
*mm, pmd_t *pmdp,
extern pgtable_t pgtable_trans_huge_withdraw(struct mm_struct *mm, pmd_t
*pmdp);
#endif
+#ifdef CONFIG_TRANSPARENT_HUGEPAGE
+/*
+ * This is an implementation of pmdp_establish() that is only suitable for an
+ * architecture that doesn't have hardware dirty/accessed bits. In this case we
+ * can't race with CPU which sets these bits and non-atomic aproach is fine.
+ */
+static inline pmd_t generic_pmdp_establish(struct vm_area_struct *vma,
+ unsigned long address, pmd_t *pmdp, pmd_t pmd)
+{
+ pmd_t old_pmd = *pmdp;
+ set_pmd_at(vma->vm_mm, address, pmdp, pmd);
+ return old_pmd;
+}
+#endif
+
#ifndef __HAVE_ARCH_PMDP_INVALIDATE
extern void pmdp_invalidate(struct vm_area_struct *vma, unsigned long address,
pmd_t *pmdp);
--
2.15.1
[PATCH AUTOSEL for 4.14 095/161] fs/dax.c: release PMD lock even when there is no PMD support in DAX
From: Jan H. Schönherr
[ Upstream commit ee190ca6516bc8257e3d36187ca6f0f71a9ec477 ]
follow_pte_pmd() can theoretically return after having acquired a PMD
lock, even when DAX was not compiled with CONFIG_FS_DAX_PMD.
Release the PMD lock unconditionally.
Link: http://lkml.kernel.org/r/20180118133839.20587-1-jscho...@amazon.de
Fixes: f729c8c9b24f ("dax: wrprotect pmd_t in dax_mapping_entry_mkclean")
Signed-off-by: Jan H. Schönherr
Reviewed-by: Ross Zwisler
Reviewed-by: Andrew Morton
Cc: Matthew Wilcox
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
Signed-off-by: Sasha Levin
---
fs/dax.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/dax.c b/fs/dax.c
index 191306cd8b6b..ddb4981ae32e 100644
--- a/fs/dax.c
+++ b/fs/dax.c
@@ -630,8 +630,8 @@ static void dax_mapping_entry_mkclean(struct address_space
*mapping,
set_pmd_at(vma->vm_mm, address, pmdp, pmd);
mmu_notifier_invalidate_range(vma->vm_mm, start, end);
unlock_pmd:
- spin_unlock(ptl);
#endif
+ spin_unlock(ptl);
} else {
if (pfn != pte_pfn(*ptep))
goto unlock_pte;
--
2.15.1
[PATCH AUTOSEL for 4.14 079/161] RDMA/uverbs: Use an unambiguous errno for method not supported
From: Jason Gunthorpe
[ Upstream commit 3624a8f02568f08aef299d3b117f2226f621177d ]
Returning EOPNOTSUPP is problematic because it can also be
returned by the method function, and we use it in quite a few
places in drivers these days.
Instead, dedicate EPROTONOSUPPORT to indicate that the ioctl framework
is enabled but the requested object and method are not supported by
the kernel. No other case will return this code, and it lets userspace
know to fall back to write().
grep says we do not use it today in drivers/infiniband subsystem.
Signed-off-by: Jason Gunthorpe
Reviewed-by: Matan Barak
Signed-off-by: Doug Ledford
Signed-off-by: Sasha Levin
---
drivers/infiniband/core/uverbs_ioctl.c | 19 +--
1 file changed, 13 insertions(+), 6 deletions(-)
diff --git a/drivers/infiniband/core/uverbs_ioctl.c
b/drivers/infiniband/core/uverbs_ioctl.c
index 5286ad57d903..8f2dc79ad4ec 100644
--- a/drivers/infiniband/core/uverbs_ioctl.c
+++ b/drivers/infiniband/core/uverbs_ioctl.c
@@ -245,16 +245,13 @@ static long ib_uverbs_cmd_verbs(struct ib_device *ib_dev,
uintptr_t data[UVERBS_OPTIMIZE_USING_STACK_SZ / sizeof(uintptr_t)];
#endif
- if (hdr->reserved)
- return -EINVAL;
-
object_spec = uverbs_get_object(ib_dev, hdr->object_id);
if (!object_spec)
- return -EOPNOTSUPP;
+ return -EPROTONOSUPPORT;
method_spec = uverbs_get_method(object_spec, hdr->method_id);
if (!method_spec)
- return -EOPNOTSUPP;
+ return -EPROTONOSUPPORT;
if ((method_spec->flags & UVERBS_ACTION_FLAG_CREATE_ROOT) ^
!file->ucontext)
return -EINVAL;
@@ -310,6 +307,16 @@ static long ib_uverbs_cmd_verbs(struct ib_device *ib_dev,
err = uverbs_handle_method(buf, ctx->uattrs, hdr->num_attrs, ib_dev,
file, method_spec, ctx->uverbs_attr_bundle);
+
+ /*
+* EPROTONOSUPPORT is ONLY to be returned if the ioctl framework can
+* not invoke the method because the request is not supported. No
+* other cases should return this code.
+ */
+ if (unlikely(err == -EPROTONOSUPPORT)) {
+ WARN_ON_ONCE(err == -EPROTONOSUPPORT);
+ err = -EINVAL;
+ }
out:
#ifdef UVERBS_OPTIMIZE_USING_STACK_SZ
if (ctx_size > UVERBS_OPTIMIZE_USING_STACK_SZ)
@@ -348,7 +355,7 @@ long ib_uverbs_ioctl(struct file *filp, unsigned int cmd,
unsigned long arg)
}
if (hdr.reserved) {
- err = -EOPNOTSUPP;
+ err = -EPROTONOSUPPORT;
goto out;
}
--
2.15.1
[PATCH AUTOSEL for 4.14 113/161] s390/eadm: fix CONFIG_BLOCK include dependency
From: Sebastian Ott
[ Upstream commit 366b77ae43c5a3bf1a367f15ec8bc16e05035f14 ]
Commit 2a842acab109 ("block: introduce new block status code type")
added blk_status_t usage to the eadm subchannel driver. However
blk_status_t is unknown when included via for CONFIG_BLOCK=n.
Only include since this is the only dependency eadm has.
This fixes build failures like below:
In file included from drivers/s390/cio/eadm_sch.c:24:0:
./arch/s390/include/asm/eadm.h:111:4: error: unknown type name 'blk_status_t';
did you mean 'si_status'?
blk_status_t error);
Reported-by: Heiko Carstens
Signed-off-by: Sebastian Ott
Signed-off-by: Martin Schwidefsky
Signed-off-by: Sasha Levin
---
arch/s390/include/asm/eadm.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/s390/include/asm/eadm.h b/arch/s390/include/asm/eadm.h
index eb5323161f11..bb63b2afdf6f 100644
--- a/arch/s390/include/asm/eadm.h
+++ b/arch/s390/include/asm/eadm.h
@@ -4,7 +4,7 @@
#include
#include
-#include
+#include
struct arqb {
u64 data;
--
2.15.1
[PATCH AUTOSEL for 4.14 110/161] IB/ipoib: Fix for potential no-carrier state
From: Alex Estrin
[ Upstream commit 1029361084d18cc270f64dfd39529fafa10cfe01 ]
On reboot SM can program port pkey table before ipoib registered its
event handler, which could result in missing pkey event and leave root
interface with initial pkey value from index 0.
Since OPA port starts with invalid pkey in index 0, root interface will
fail to initialize and stay down with no-carrier flag.
For IB ipoib interface may end up with pkey different from value
opensm put in pkey table idx 0, resulting in connectivity issues
(different mcast groups, for example).
Close the window by calling event handler after registration
to make sure ipoib pkey is in sync with port pkey table.
Reviewed-by: Mike Marciniszyn
Reviewed-by: Ira Weiny
Signed-off-by: Alex Estrin
Signed-off-by: Dennis Dalessandro
Signed-off-by: Jason Gunthorpe
Signed-off-by: Sasha Levin
---
drivers/infiniband/ulp/ipoib/ipoib_main.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/infiniband/ulp/ipoib/ipoib_main.c
b/drivers/infiniband/ulp/ipoib/ipoib_main.c
index a009e943362a..6bc9a768f721 100644
--- a/drivers/infiniband/ulp/ipoib/ipoib_main.c
+++ b/drivers/infiniband/ulp/ipoib/ipoib_main.c
@@ -2273,6 +2273,9 @@ static struct net_device *ipoib_add_port(const char
*format,
priv->ca, ipoib_event);
ib_register_event_handler(&priv->event_handler);
+ /* call event handler to ensure pkey in sync */
+ queue_work(ipoib_workqueue, &priv->flush_heavy);
+
result = register_netdev(priv->dev);
if (result) {
printk(KERN_WARNING "%s: couldn't register ipoib port %d; error
%d\n",
--
2.15.1
[PATCH AUTOSEL for 4.14 124/161] MIPS: TXx9: use IS_BUILTIN() for CONFIG_LEDS_CLASS
From: Matt Redfearn
[ Upstream commit 0cde5b44a30f1daaef1c34e08191239dc63271c4 ]
When commit b27311e1cace ("MIPS: TXx9: Add RBTX4939 board support")
added board support for the RBTX4939, it added a call to
led_classdev_register even if the LED class is built as a module.
Built-in arch code cannot call module code directly like this. Commit
b33b44073734 ("MIPS: TXX9: use IS_ENABLED() macro") subsequently
changed the inclusion of this code to a single check that
CONFIG_LEDS_CLASS is either builtin or a module, but the same issue
remains.
This leads to MIPS allmodconfig builds failing when CONFIG_MACH_TX49XX=y
is set:
arch/mips/txx9/rbtx4939/setup.o: In function `rbtx4939_led_probe':
setup.c:(.init.text+0xc0): undefined reference to `of_led_classdev_register'
make: *** [Makefile:999: vmlinux] Error 1
Fix this by using the IS_BUILTIN() macro instead.
Fixes: b27311e1cace ("MIPS: TXx9: Add RBTX4939 board support")
Signed-off-by: Matt Redfearn
Reviewed-by: James Hogan
Cc: Ralf Baechle
Cc: linux-m...@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/18544/
Signed-off-by: James Hogan
Signed-off-by: Sasha Levin
---
arch/mips/txx9/rbtx4939/setup.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/mips/txx9/rbtx4939/setup.c b/arch/mips/txx9/rbtx4939/setup.c
index 8b937300fb7f..fd26fadc8617 100644
--- a/arch/mips/txx9/rbtx4939/setup.c
+++ b/arch/mips/txx9/rbtx4939/setup.c
@@ -186,7 +186,7 @@ static void __init rbtx4939_update_ioc_pen(void)
#define RBTX4939_MAX_7SEGLEDS 8
-#if IS_ENABLED(CONFIG_LEDS_CLASS)
+#if IS_BUILTIN(CONFIG_LEDS_CLASS)
static u8 led_val[RBTX4939_MAX_7SEGLEDS];
struct rbtx4939_led_data {
struct led_classdev cdev;
@@ -261,7 +261,7 @@ static inline void rbtx4939_led_setup(void)
static void __rbtx4939_7segled_putc(unsigned int pos, unsigned char val)
{
-#if IS_ENABLED(CONFIG_LEDS_CLASS)
+#if IS_BUILTIN(CONFIG_LEDS_CLASS)
unsigned long flags;
local_irq_save(flags);
/* bit7: reserved for LED class */
--
2.15.1
[PATCH AUTOSEL for 4.14 130/161] bpf: sockmap, fix leaking maps with attached but not detached progs
From: John Fastabend
[ Upstream commit 3d9e952697de89b53227f06d4241f275eb99cfc4 ]
When a program is attached to a map we increment the program refcnt
to ensure that the program is not removed while it is potentially
being referenced from sockmap side. However, if this same program
also references the map (this is a reasonably common pattern in
my programs) then the verifier will also increment the maps refcnt
from the verifier. This is to ensure the map doesn't get garbage
collected while the program has a reference to it.
So we are left in a state where the map holds the refcnt on the
program stopping it from being removed and releasing the map refcnt.
And vice versa the program holds a refcnt on the map stopping it
from releasing the refcnt on the prog.
All this is fine as long as users detach the program while the
map fd is still around. But, if the user omits this detach command
we are left with a dangling map we can no longer release.
To resolve this when the map fd is released decrement the program
references and remove any reference from the map to the program.
This fixes the issue with possibly dangling map and creates a
user side API constraint. That is, the map fd must be held open
for programs to be attached to a map.
Fixes: 174a79ff9515 ("bpf: sockmap with sk redirect support")
Signed-off-by: John Fastabend
Signed-off-by: Daniel Borkmann
Signed-off-by: Sasha Levin
---
kernel/bpf/sockmap.c | 19 ++-
1 file changed, 14 insertions(+), 5 deletions(-)
diff --git a/kernel/bpf/sockmap.c b/kernel/bpf/sockmap.c
index 1890be7ea9cd..53a4787c08d8 100644
--- a/kernel/bpf/sockmap.c
+++ b/kernel/bpf/sockmap.c
@@ -601,11 +601,6 @@ static void sock_map_free(struct bpf_map *map)
}
rcu_read_unlock();
- if (stab->bpf_verdict)
- bpf_prog_put(stab->bpf_verdict);
- if (stab->bpf_parse)
- bpf_prog_put(stab->bpf_parse);
-
sock_map_remove_complete(stab);
}
@@ -877,6 +872,19 @@ static int sock_map_update_elem(struct bpf_map *map,
return err;
}
+static void sock_map_release(struct bpf_map *map, struct file *map_file)
+{
+ struct bpf_stab *stab = container_of(map, struct bpf_stab, map);
+ struct bpf_prog *orig;
+
+ orig = xchg(&stab->bpf_parse, NULL);
+ if (orig)
+ bpf_prog_put(orig);
+ orig = xchg(&stab->bpf_verdict, NULL);
+ if (orig)
+ bpf_prog_put(orig);
+}
+
const struct bpf_map_ops sock_map_ops = {
.map_alloc = sock_map_alloc,
.map_free = sock_map_free,
@@ -884,6 +892,7 @@ const struct bpf_map_ops sock_map_ops = {
.map_get_next_key = sock_map_get_next_key,
.map_update_elem = sock_map_update_elem,
.map_delete_elem = sock_map_delete_elem,
+ .map_release = sock_map_release,
};
BPF_CALL_4(bpf_sock_map_update, struct bpf_sock_ops_kern *, bpf_sock,
--
2.15.1
[PATCH AUTOSEL for 4.14 141/161] selftests/ftrace: Add some missing glob checks
From: "Steven Rostedt (VMware)" [ Upstream commit 97fe22adf33f06519bfdf7dad33bcd562e366c8f ] Al Viro discovered a bug in the glob ftrace filtering code where "*a*b" is treated the same as "a*b", and functions that would be selected by "*a*b" but not "a*b" are not selected with "*a*b". Add tests for patterns "*a*b" and "a*b*" to the glob selftest. Link: http://lkml.kernel.org/r/20180127170748.gf13...@zeniv.linux.org.uk Cc: Shuah Khan Acked-by: Masami Hiramatsu Signed-off-by: Steven Rostedt (VMware) Signed-off-by: Sasha Levin --- tools/testing/selftests/ftrace/test.d/ftrace/func-filter-glob.tc | 6 ++ 1 file changed, 6 insertions(+) diff --git a/tools/testing/selftests/ftrace/test.d/ftrace/func-filter-glob.tc b/tools/testing/selftests/ftrace/test.d/ftrace/func-filter-glob.tc index 589d52b211b7..27a54a17da65 100644 --- a/tools/testing/selftests/ftrace/test.d/ftrace/func-filter-glob.tc +++ b/tools/testing/selftests/ftrace/test.d/ftrace/func-filter-glob.tc @@ -29,6 +29,12 @@ ftrace_filter_check '*schedule*' '^.*schedule.*$' # filter by *, end match ftrace_filter_check 'schedule*' '^schedule.*$' +# filter by *mid*end +ftrace_filter_check '*aw*lock' '.*aw.*lock$' + +# filter by start*mid* +ftrace_filter_check 'mutex*try*' '^mutex.*try.*' + # Advanced full-glob matching feature is recently supported. # Skip the tests if we are sure the kernel does not support it. if grep -q 'accepts: .* glob-matching-pattern' README ; then -- 2.15.1
[PATCH AUTOSEL for 4.9 005/293] e1000e: Undo e1000e_pm_freeze if __e1000_shutdown fails
From: Chris Wilson
[ Upstream commit 833521ebc65b1c3092e5c0d8a97092f98eec595d ]
An error during suspend (e100e_pm_suspend),
[ 429.994338] ACPI : EC: event blocked
[ 429.994633] e1000e: EEE TX LPI TIMER: 0011
[ 430.955451] pci_pm_suspend(): e1000e_pm_suspend+0x0/0x30 [e1000e] returns -2
[ 430.955454] dpm_run_callback(): pci_pm_suspend+0x0/0x140 returns -2
[ 430.955458] PM: Device :00:19.0 failed to suspend async: error -2
[ 430.955581] PM: Some devices failed to suspend, or early wake event detected
[ 430.957709] ACPI : EC: event unblocked
lead to complete failure:
[ 432.585002] [ cut here ]
[ 432.585013] WARNING: CPU: 3 PID: 8372 at kernel/irq/manage.c:1478
__free_irq+0x9f/0x280
[ 432.585015] Trying to free already-free IRQ 20
[ 432.585016] Modules linked in: cdc_ncm usbnet x86_pkg_temp_thermal
intel_powerclamp coretemp mii crct10dif_pclmul crc32_pclmul ghash_clmulni_intel
snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_generic snd_hda_intel
snd_hda_codec snd_hwdep lpc_ich snd_hda_core snd_pcm mei_me mei sdhci_pci sdhci
i915 mmc_core e1000e ptp pps_core prime_numbers
[ 432.585042] CPU: 3 PID: 8372 Comm: kworker/u16:40 Tainted: G U
4.10.0-rc8-CI-Patchwork_3870+ #1
[ 432.585044] Hardware name: LENOVO 2356GCG/2356GCG, BIOS G7ET31WW (1.13 )
07/02/2012
[ 432.585050] Workqueue: events_unbound async_run_entry_fn
[ 432.585051] Call Trace:
[ 432.585058] dump_stack+0x67/0x92
[ 432.585062] __warn+0xc6/0xe0
[ 432.585065] warn_slowpath_fmt+0x4a/0x50
[ 432.585070] ? _raw_spin_lock_irqsave+0x49/0x60
[ 432.585072] __free_irq+0x9f/0x280
[ 432.585075] free_irq+0x34/0x80
[ 432.585089] e1000_free_irq+0x65/0x70 [e1000e]
[ 432.585098] e1000e_pm_freeze+0x7a/0xb0 [e1000e]
[ 432.585106] e1000e_pm_suspend+0x21/0x30 [e1000e]
[ 432.585113] pci_pm_suspend+0x71/0x140
[ 432.585118] dpm_run_callback+0x6f/0x330
[ 432.585122] ? pci_pm_freeze+0xe0/0xe0
[ 432.585125] __device_suspend+0xea/0x330
[ 432.585128] async_suspend+0x1a/0x90
[ 432.585132] async_run_entry_fn+0x34/0x160
[ 432.585137] process_one_work+0x1f4/0x6d0
[ 432.585140] ? process_one_work+0x16e/0x6d0
[ 432.585143] worker_thread+0x49/0x4a0
[ 432.585145] kthread+0x107/0x140
[ 432.585148] ? process_one_work+0x6d0/0x6d0
[ 432.585150] ? kthread_create_on_node+0x40/0x40
[ 432.585154] ret_from_fork+0x2e/0x40
[ 432.585156] ---[ end trace 6712df7f8c4b9124 ]---
The unwind failures stems from commit 2800209994f8 ("e1000e: Refactor PM
flows"), but it may be a later patch that introduced the non-recoverable
behaviour.
Fixes: 2800209994f8 ("e1000e: Refactor PM flows")
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99847
Signed-off-by: Chris Wilson
Signed-off-by: Jani Nikula
Tested-by: Aaron Brown
Signed-off-by: Jeff Kirsher
Signed-off-by: Sasha Levin
---
drivers/net/ethernet/intel/e1000e/netdev.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/intel/e1000e/netdev.c
b/drivers/net/ethernet/intel/e1000e/netdev.c
index 528a926dd979..87cbefb16050 100644
--- a/drivers/net/ethernet/intel/e1000e/netdev.c
+++ b/drivers/net/ethernet/intel/e1000e/netdev.c
@@ -6645,12 +6645,17 @@ static int e1000e_pm_thaw(struct device *dev)
static int e1000e_pm_suspend(struct device *dev)
{
struct pci_dev *pdev = to_pci_dev(dev);
+ int rc;
e1000e_flush_lpic(pdev);
e1000e_pm_freeze(dev);
- return __e1000_shutdown(pdev, false);
+ rc = __e1000_shutdown(pdev, false);
+ if (rc)
+ e1000e_pm_thaw(dev);
+
+ return rc;
}
static int e1000e_pm_resume(struct device *dev)
--
2.15.1
[PATCH AUTOSEL for 4.14 148/161] SUNRPC: Don't call __UDPX_INC_STATS() from a preemptible context
From: Trond Myklebust
[ Upstream commit 0afa6b4412988019db14c6bfb8c6cbdf120ca9ad ]
Calling __UDPX_INC_STATS() from a preemptible context leads to a
warning of the form:
BUG: using __this_cpu_add() in preemptible [] code: kworker/u5:0/31
caller is xs_udp_data_receive_workfn+0x194/0x270
CPU: 1 PID: 31 Comm: kworker/u5:0 Not tainted 4.15.0-rc8-00076-g90ea9f1 #2
Workqueue: xprtiod xs_udp_data_receive_workfn
Call Trace:
dump_stack+0x85/0xc1
check_preemption_disabled+0xce/0xe0
xs_udp_data_receive_workfn+0x194/0x270
process_one_work+0x318/0x620
worker_thread+0x20a/0x390
? process_one_work+0x620/0x620
kthread+0x120/0x130
? __kthread_bind_mask+0x60/0x60
ret_from_fork+0x24/0x30
Since we're taking a spinlock in those functions anyway, let's fix the
issue by moving the call so that it occurs under the spinlock.
Reported-by: kernel test robot
Signed-off-by: Trond Myklebust
Signed-off-by: Sasha Levin
---
net/sunrpc/xprtsock.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/sunrpc/xprtsock.c b/net/sunrpc/xprtsock.c
index 8cb40f8ffa5b..30192abfdc3b 100644
--- a/net/sunrpc/xprtsock.c
+++ b/net/sunrpc/xprtsock.c
@@ -1069,18 +1069,18 @@ static void xs_udp_data_read_skb(struct rpc_xprt *xprt,
/* Suck it into the iovec, verify checksum if not done by hw. */
if (csum_partial_copy_to_xdr(&rovr->rq_private_buf, skb)) {
- __UDPX_INC_STATS(sk, UDP_MIB_INERRORS);
spin_lock(&xprt->recv_lock);
+ __UDPX_INC_STATS(sk, UDP_MIB_INERRORS);
goto out_unpin;
}
- __UDPX_INC_STATS(sk, UDP_MIB_INDATAGRAMS);
spin_lock_bh(&xprt->transport_lock);
xprt_adjust_cwnd(xprt, task, copied);
spin_unlock_bh(&xprt->transport_lock);
spin_lock(&xprt->recv_lock);
xprt_complete_rqst(task, copied);
+ __UDPX_INC_STATS(sk, UDP_MIB_INDATAGRAMS);
out_unpin:
xprt_unpin_rqst(rovr);
out_unlock:
--
2.15.1
[PATCH AUTOSEL for 4.14 136/161] bcache: properly set task state in bch_writeback_thread()
From: Coly Li
[ Upstream commit 99361bbf26337186f02561109c17a4c4b1a7536a ]
Kernel thread routine bch_writeback_thread() has the following code block,
447 down_write(&dc->writeback_lock);
448~450 if (check conditions) {
451 up_write(&dc->writeback_lock);
452 set_current_state(TASK_INTERRUPTIBLE);
453
454 if (kthread_should_stop())
455 return 0;
456
457 schedule();
458 continue;
459 }
If condition check is true, its task state is set to TASK_INTERRUPTIBLE
and call schedule() to wait for others to wake up it.
There are 2 issues in current code,
1, Task state is set to TASK_INTERRUPTIBLE after the condition checks, if
another process changes the condition and call wake_up_process(dc->
writeback_thread), then at line 452 task state is set back to
TASK_INTERRUPTIBLE, the writeback kernel thread will lose a chance to be
waken up.
2, At line 454 if kthread_should_stop() is true, writeback kernel thread
will return to kernel/kthread.c:kthread() with TASK_INTERRUPTIBLE and
call do_exit(). It is not good to enter do_exit() with task state
TASK_INTERRUPTIBLE, in following code path might_sleep() is called and a
warning message is reported by __might_sleep(): "WARNING: do not call
blocking ops when !TASK_RUNNING; state=1 set at []".
For the first issue, task state should be set before condition checks.
Ineed because dc->writeback_lock is required when modifying all the
conditions, calling set_current_state() inside code block where dc->
writeback_lock is hold is safe. But this is quite implicit, so I still move
set_current_state() before all the condition checks.
For the second issue, frankley speaking it does not hurt when kernel thread
exits with TASK_INTERRUPTIBLE state, but this warning message scares users,
makes them feel there might be something risky with bcache and hurt their
data. Setting task state to TASK_RUNNING before returning fixes this
problem.
In alloc.c:allocator_wait(), there is also a similar issue, and is also
fixed in this patch.
Changelog:
v3: merge two similar fixes into one patch
v2: fix the race issue in v1 patch.
v1: initial buggy fix.
Signed-off-by: Coly Li
Reviewed-by: Hannes Reinecke
Reviewed-by: Michael Lyle
Cc: Michael Lyle
Cc: Junhui Tang
Signed-off-by: Jens Axboe
Signed-off-by: Sasha Levin
---
drivers/md/bcache/alloc.c | 4 +++-
drivers/md/bcache/writeback.c | 7 +--
2 files changed, 8 insertions(+), 3 deletions(-)
diff --git a/drivers/md/bcache/alloc.c b/drivers/md/bcache/alloc.c
index 934b1fce4ce1..02b576d55758 100644
--- a/drivers/md/bcache/alloc.c
+++ b/drivers/md/bcache/alloc.c
@@ -287,8 +287,10 @@ do {
\
break; \
\
mutex_unlock(&(ca)->set->bucket_lock); \
- if (kthread_should_stop()) \
+ if (kthread_should_stop()) {\
+ set_current_state(TASK_RUNNING);\
return 0; \
+ } \
\
schedule(); \
mutex_lock(&(ca)->set->bucket_lock);\
diff --git a/drivers/md/bcache/writeback.c b/drivers/md/bcache/writeback.c
index 70454f2ad2fa..f046dedc59ab 100644
--- a/drivers/md/bcache/writeback.c
+++ b/drivers/md/bcache/writeback.c
@@ -420,18 +420,21 @@ static int bch_writeback_thread(void *arg)
while (!kthread_should_stop()) {
down_write(&dc->writeback_lock);
+ set_current_state(TASK_INTERRUPTIBLE);
if (!atomic_read(&dc->has_dirty) ||
(!test_bit(BCACHE_DEV_DETACHING, &dc->disk.flags) &&
!dc->writeback_running)) {
up_write(&dc->writeback_lock);
- set_current_state(TASK_INTERRUPTIBLE);
- if (kthread_should_stop())
+ if (kthread_should_stop()) {
+ set_current_state(TASK_RUNNING);
return 0;
+ }
schedule();
continue;
}
+ set_current_state(TASK_RUNNING);
searched_full_index = refill_dirty(dc);
--
2.15.1
[PATCH AUTOSEL for 4.9 023/293] stmmac: fix ptp header for GMAC3 hw timestamp
From: Mario Molitor
[ Upstream commit fd6720aefde06eacf17404eed2cad65c6ec103e1 ]
According the CYCLON V documention only the bit 16 of snaptypesel should
set.
(more information see Table 17-20 (cv_5v4.pdf) :
Timestamp Snapshot Dependency on Register Bits)
Fixes: d2042052a0aa ("stmmac: update the PTP header file")
Signed-off-by: Mario Molitor
Signed-off-by: David S. Miller
Signed-off-by: Sasha Levin
---
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 15 ---
drivers/net/ethernet/stmicro/stmmac/stmmac_ptp.h | 3 ++-
2 files changed, 14 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index 98bbb91336e4..c212d1dd8bfd 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -478,7 +478,10 @@ static int stmmac_hwtstamp_ioctl(struct net_device *dev,
struct ifreq *ifr)
/* PTP v1, UDP, any kind of event packet */
config.rx_filter = HWTSTAMP_FILTER_PTP_V1_L4_EVENT;
/* take time stamp for all event messages */
- snap_type_sel = PTP_TCR_SNAPTYPSEL_1;
+ if (priv->plat->has_gmac4)
+ snap_type_sel = PTP_GMAC4_TCR_SNAPTYPSEL_1;
+ else
+ snap_type_sel = PTP_TCR_SNAPTYPSEL_1;
ptp_over_ipv4_udp = PTP_TCR_TSIPV4ENA;
ptp_over_ipv6_udp = PTP_TCR_TSIPV6ENA;
@@ -510,7 +513,10 @@ static int stmmac_hwtstamp_ioctl(struct net_device *dev,
struct ifreq *ifr)
config.rx_filter = HWTSTAMP_FILTER_PTP_V2_L4_EVENT;
ptp_v2 = PTP_TCR_TSVER2ENA;
/* take time stamp for all event messages */
- snap_type_sel = PTP_TCR_SNAPTYPSEL_1;
+ if (priv->plat->has_gmac4)
+ snap_type_sel = PTP_GMAC4_TCR_SNAPTYPSEL_1;
+ else
+ snap_type_sel = PTP_TCR_SNAPTYPSEL_1;
ptp_over_ipv4_udp = PTP_TCR_TSIPV4ENA;
ptp_over_ipv6_udp = PTP_TCR_TSIPV6ENA;
@@ -544,7 +550,10 @@ static int stmmac_hwtstamp_ioctl(struct net_device *dev,
struct ifreq *ifr)
config.rx_filter = HWTSTAMP_FILTER_PTP_V2_EVENT;
ptp_v2 = PTP_TCR_TSVER2ENA;
/* take time stamp for all event messages */
- snap_type_sel = PTP_TCR_SNAPTYPSEL_1;
+ if (priv->plat->has_gmac4)
+ snap_type_sel = PTP_GMAC4_TCR_SNAPTYPSEL_1;
+ else
+ snap_type_sel = PTP_TCR_SNAPTYPSEL_1;
ptp_over_ipv4_udp = PTP_TCR_TSIPV4ENA;
ptp_over_ipv6_udp = PTP_TCR_TSIPV6ENA;
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_ptp.h
b/drivers/net/ethernet/stmicro/stmmac/stmmac_ptp.h
index c06938c47af5..174777cd888e 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_ptp.h
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_ptp.h
@@ -63,7 +63,8 @@
/* Enable Snapshot for Messages Relevant to Master */
#definePTP_TCR_TSMSTRENA BIT(15)
/* Select PTP packets for Taking Snapshots */
-#definePTP_TCR_SNAPTYPSEL_1GENMASK(17, 16)
+#definePTP_TCR_SNAPTYPSEL_1BIT(16)
+#definePTP_GMAC4_TCR_SNAPTYPSEL_1 GENMASK(17, 16)
/* Enable MAC address for PTP Frame Filtering */
#definePTP_TCR_TSENMACADDR BIT(18)
--
2.15.1
[PATCH AUTOSEL for 4.9 024/293] geneve: add missing rx stats accounting
From: Girish Moodalbail
[ Upstream commit fe741e2362f33bbea813bcc3a921de356c6653db ]
There are few places on the receive path where packet drops and packet
errors were not accounted for. This patch fixes that issue.
Signed-off-by: Girish Moodalbail
Signed-off-by: David S. Miller
Signed-off-by: Sasha Levin
---
drivers/net/geneve.c | 36
1 file changed, 24 insertions(+), 12 deletions(-)
diff --git a/drivers/net/geneve.c b/drivers/net/geneve.c
index 3c1f89ab0110..92ad43e53c72 100644
--- a/drivers/net/geneve.c
+++ b/drivers/net/geneve.c
@@ -209,6 +209,7 @@ static void geneve_rx(struct geneve_dev *geneve, struct
geneve_sock *gs,
struct genevehdr *gnvh = geneve_hdr(skb);
struct metadata_dst *tun_dst = NULL;
struct pcpu_sw_netstats *stats;
+ unsigned int len;
int err = 0;
void *oiph;
@@ -222,8 +223,10 @@ static void geneve_rx(struct geneve_dev *geneve, struct
geneve_sock *gs,
tun_dst = udp_tun_rx_dst(skb, geneve_get_sk_family(gs), flags,
vni_to_tunnel_id(gnvh->vni),
gnvh->opt_len * 4);
- if (!tun_dst)
+ if (!tun_dst) {
+ geneve->dev->stats.rx_dropped++;
goto drop;
+ }
/* Update tunnel dst according to Geneve options. */
ip_tunnel_info_opts_set(&tun_dst->u.tun_info,
gnvh->options, gnvh->opt_len * 4);
@@ -231,8 +234,11 @@ static void geneve_rx(struct geneve_dev *geneve, struct
geneve_sock *gs,
/* Drop packets w/ critical options,
* since we don't support any...
*/
- if (gnvh->critical)
+ if (gnvh->critical) {
+ geneve->dev->stats.rx_frame_errors++;
+ geneve->dev->stats.rx_errors++;
goto drop;
+ }
}
skb_reset_mac_header(skb);
@@ -243,8 +249,10 @@ static void geneve_rx(struct geneve_dev *geneve, struct
geneve_sock *gs,
skb_dst_set(skb, &tun_dst->dst);
/* Ignore packet loops (and multicast echo) */
- if (ether_addr_equal(eth_hdr(skb)->h_source, geneve->dev->dev_addr))
+ if (ether_addr_equal(eth_hdr(skb)->h_source, geneve->dev->dev_addr)) {
+ geneve->dev->stats.rx_errors++;
goto drop;
+ }
oiph = skb_network_header(skb);
skb_reset_network_header(skb);
@@ -276,13 +284,15 @@ static void geneve_rx(struct geneve_dev *geneve, struct
geneve_sock *gs,
}
}
- stats = this_cpu_ptr(geneve->dev->tstats);
- u64_stats_update_begin(&stats->syncp);
- stats->rx_packets++;
- stats->rx_bytes += skb->len;
- u64_stats_update_end(&stats->syncp);
-
- gro_cells_receive(&geneve->gro_cells, skb);
+ len = skb->len;
+ err = gro_cells_receive(&geneve->gro_cells, skb);
+ if (likely(err == NET_RX_SUCCESS)) {
+ stats = this_cpu_ptr(geneve->dev->tstats);
+ u64_stats_update_begin(&stats->syncp);
+ stats->rx_packets++;
+ stats->rx_bytes += len;
+ u64_stats_update_end(&stats->syncp);
+ }
return;
drop:
/* Consume bad packet */
@@ -332,7 +342,7 @@ static int geneve_udp_encap_recv(struct sock *sk, struct
sk_buff *skb)
struct geneve_sock *gs;
int opts_len;
- /* Need Geneve and inner Ethernet header to be present */
+ /* Need UDP and Geneve header to be present */
if (unlikely(!pskb_may_pull(skb, GENEVE_BASE_HLEN)))
goto drop;
@@ -355,8 +365,10 @@ static int geneve_udp_encap_recv(struct sock *sk, struct
sk_buff *skb)
opts_len = geneveh->opt_len * 4;
if (iptunnel_pull_header(skb, GENEVE_BASE_HLEN + opts_len,
htons(ETH_P_TEB),
-!net_eq(geneve->net, dev_net(geneve->dev
+!net_eq(geneve->net, dev_net(geneve->dev {
+ geneve->dev->stats.rx_dropped++;
goto drop;
+ }
geneve_rx(geneve, gs, skb);
return 0;
--
2.15.1
[PATCH AUTOSEL for 4.9 052/293] scsi: lpfc: Fix return value of board_mode store routine in case of online failure
From: James Smart
[ Upstream commit 522dceeb62ded1a7b538d2f1f61cc69a1402537d ]
On hbacmd reset failure, observing wrong string "nline" in kernel log.
On failure, non negative value (1) is returned from sysfs store
routine. It is interpreted as count by kernel and store routine is
called again with the remaining characters as input.
Fix: Return negative error code (-EIO) in case of failure.
Signed-off-by: Dick Kennedy
Signed-off-by: James Smart
Signed-off-by: Martin K. Petersen
Signed-off-by: Sasha Levin
---
drivers/scsi/lpfc/lpfc_attr.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/scsi/lpfc/lpfc_attr.c b/drivers/scsi/lpfc/lpfc_attr.c
index 453299095847..94982fc5f2c4 100644
--- a/drivers/scsi/lpfc/lpfc_attr.c
+++ b/drivers/scsi/lpfc/lpfc_attr.c
@@ -1091,6 +1091,8 @@ lpfc_board_mode_store(struct device *dev, struct
device_attribute *attr,
goto board_mode_out;
}
wait_for_completion(&online_compl);
+ if (status)
+ status = -EIO;
} else if (strncmp(buf, "offline", sizeof("offline") - 1) == 0)
status = lpfc_do_offline(phba, LPFC_EVT_OFFLINE);
else if (strncmp(buf, "warm", sizeof("warm") - 1) == 0)
--
2.15.1
[PATCH AUTOSEL for 4.9 057/293] PCI: Add domain number check to find_smbios_instance_string()
From: Sujith Pandel
[ Upstream commit 6c51c82c60991bdbfb937f3bf0cdbe68d042073d ]
The function find_smbios_instance_string() does not consider the
PCI domain number. As a result, SMBIOS type 41 device type instance
would be exported to sysfs for all the PCI domains which have a
PCI device with same bus/device/function, though PCI bus/device/func
from a specific PCI domain has SMBIOS type 41 device type instance
defined.
Address the issue by making find_smbios_instance_string() check PCI domain
number as well.
Reported-by: Shai Fultheim
Suggested-by: Shai Fultheim
Tested-by: Shai Fultheim
Signed-off-by: Sujith Pandel
Signed-off-by: Narendra K
Signed-off-by: Bjorn Helgaas
Signed-off-by: Sasha Levin
---
drivers/pci/pci-label.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/pci/pci-label.c b/drivers/pci/pci-label.c
index 51357377efbc..1d828a614ac0 100644
--- a/drivers/pci/pci-label.c
+++ b/drivers/pci/pci-label.c
@@ -43,9 +43,11 @@ static size_t find_smbios_instance_string(struct pci_dev
*pdev, char *buf,
{
const struct dmi_device *dmi;
struct dmi_dev_onboard *donboard;
+ int domain_nr;
int bus;
int devfn;
+ domain_nr = pci_domain_nr(pdev->bus);
bus = pdev->bus->number;
devfn = pdev->devfn;
@@ -53,8 +55,9 @@ static size_t find_smbios_instance_string(struct pci_dev
*pdev, char *buf,
while ((dmi = dmi_find_device(DMI_DEV_TYPE_DEV_ONBOARD,
NULL, dmi)) != NULL) {
donboard = dmi->device_data;
- if (donboard && donboard->bus == bus &&
- donboard->devfn == devfn) {
+ if (donboard && donboard->segment == domain_nr &&
+ donboard->bus == bus &&
+ donboard->devfn == devfn) {
if (buf) {
if (attribute == SMBIOS_ATTR_INSTANCE_SHOW)
return scnprintf(buf, PAGE_SIZE,
--
2.15.1
[PATCH AUTOSEL for 4.9 068/293] ixgbe: fix race condition with PTP_TX_IN_PROGRESS bits
From: Jacob Keller
[ Upstream commit aaebaf50b502648b1d4d8c93b4be133944c2bbd0 ]
Hardware related to the ixgbe driver is limited to handling a single Tx
timestamp request at a time. Thus, the driver ignores requests for Tx
timestamp while waiting for the current request to finish. It uses
a state bit lock which enforces that only one timestamp request is
honored at a time.
Unfortunately this suffers from a simple race condition. The bit lock is
not cleared until after skb_tstamp_tx() is called notifying applications
of a new Tx timestamp. Even a well behaved application sending only one
packet at a time and waiting for a response can wake up and send a new
packet before the bit lock is cleared. This results in needlessly
dropping some Tx timestamp requests.
We can fix this by unlocking the state bit as soon as we read the
Timestamp register, as this is the first point at which it is safe to
unlock.
To avoid issues with the skb pointer, we'll use a copy of the pointer
and set the global variable in the driver structure to NULL first. This
ensures that the next timestamp request does not modify our local copy
of the skb pointer.
This ensures that well behaved applications do not accidentally race
with the unlock bit. Obviously an application which sends multiple Tx
timestamp requests at once will still only timestamp one packet at
a time. Unfortunately there is nothing we can do about this.
Reported-by: David Mirabito
Signed-off-by: Jacob Keller
Tested-by: Andrew Bowers
Signed-off-by: Jeff Kirsher
Signed-off-by: Sasha Levin
---
drivers/net/ethernet/intel/ixgbe/ixgbe_ptp.c | 15 ---
1 file changed, 12 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_ptp.c
b/drivers/net/ethernet/intel/ixgbe/ixgbe_ptp.c
index a92277683a64..079fe5ecb39c 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_ptp.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_ptp.c
@@ -672,17 +672,26 @@ static void ixgbe_ptp_clear_tx_timestamp(struct
ixgbe_adapter *adapter)
*/
static void ixgbe_ptp_tx_hwtstamp(struct ixgbe_adapter *adapter)
{
+ struct sk_buff *skb = adapter->ptp_tx_skb;
struct ixgbe_hw *hw = &adapter->hw;
struct skb_shared_hwtstamps shhwtstamps;
u64 regval = 0;
regval |= (u64)IXGBE_READ_REG(hw, IXGBE_TXSTMPL);
regval |= (u64)IXGBE_READ_REG(hw, IXGBE_TXSTMPH) << 32;
-
ixgbe_ptp_convert_to_hwtstamp(adapter, &shhwtstamps, regval);
- skb_tstamp_tx(adapter->ptp_tx_skb, &shhwtstamps);
- ixgbe_ptp_clear_tx_timestamp(adapter);
+ /* Handle cleanup of the ptp_tx_skb ourselves, and unlock the state
+* bit prior to notifying the stack via skb_tstamp_tx(). This prevents
+* well behaved applications from attempting to timestamp again prior
+* to the lock bit being clear.
+*/
+ adapter->ptp_tx_skb = NULL;
+ clear_bit_unlock(__IXGBE_PTP_TX_IN_PROGRESS, &adapter->state);
+
+ /* Notify the stack and then free the skb after we've unlocked */
+ skb_tstamp_tx(skb, &shhwtstamps);
+ dev_kfree_skb_any(skb);
}
/**
--
2.15.1
[PATCH AUTOSEL for 4.9 063/293] tpm_tis: Fix IRQ autoprobing when using platform_device
From: Jason Gunthorpe
[ Upstream commit d27f81f061bbde627ac4fbd735114f9ea2c63615 ]
The test was backwards, triggering IRQ autoprobing if the firmware
did not specify an IRQ, instead of triggering it only when the
module force parameter was specified.
Since autoprobing is not enabled on !x86 and the platform device is
currently only used on !x86, or with force, this has gone unnoticed.
Fixes: 00194826e6be ("tpm_tis: Clean up the force=1 module parameter")
Signed-off-by: Jason Gunthorpe
Reviewed-by: Jarkko Sakkinen
Tested-by: Jerry Snitselaar (with TPM 2.0)
Tested-by: Jarkko Sakkinen (with TPM 1.2)
Signed-off-by: Jarkko Sakkinen
Signed-off-by: Sasha Levin
---
drivers/char/tpm/tpm_tis.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/char/tpm/tpm_tis.c b/drivers/char/tpm/tpm_tis.c
index 06173d2e316f..2721f9c2e70a 100644
--- a/drivers/char/tpm/tpm_tis.c
+++ b/drivers/char/tpm/tpm_tis.c
@@ -334,7 +334,7 @@ static int tpm_tis_plat_probe(struct platform_device *pdev)
if (res) {
tpm_info.irq = res->start;
} else {
- if (pdev == force_pdev)
+ if (pdev != force_pdev)
tpm_info.irq = -1;
else
/* When forcing auto probe the IRQ */
--
2.15.1
[PATCH AUTOSEL for 4.9 071/293] x86/mce: Don't disable MCA banks when offlining a CPU on AMD
From: Yazen Ghannam
[ Upstream commit ec33838244c8535b23b8d24b167996fd1318bb68 ]
AMD systems have non-core, shared MCA banks within a die. These banks
are controlled by a master CPU per die. If this CPU is offlined then all
the shared banks are disabled in addition to the CPU's core banks.
Also, Fam17h systems may have SMT enabled. The MCA_CTL register is shared
between SMT thread siblings. If a CPU is offlined then all its sibling's
MCA banks are also disabled.
Extend the existing vendor check to AMD too.
Signed-off-by: Yazen Ghannam
[ Fix up comment. ]
Signed-off-by: Borislav Petkov
Cc: Borislav Petkov
Cc: Linus Torvalds
Cc: Peter Zijlstra
Cc: Thomas Gleixner
Cc: Tony Luck
Cc: linux-edac
Link: http://lkml.kernel.org/r/20170613162835.30750-8...@alien8.de
Signed-off-by: Ingo Molnar
Signed-off-by: Sasha Levin
---
arch/x86/kernel/cpu/mcheck/mce.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/arch/x86/kernel/cpu/mcheck/mce.c b/arch/x86/kernel/cpu/mcheck/mce.c
index 7bbd50fa72ad..0a8ba9adb04a 100644
--- a/arch/x86/kernel/cpu/mcheck/mce.c
+++ b/arch/x86/kernel/cpu/mcheck/mce.c
@@ -2187,12 +2187,13 @@ static void mce_disable_error_reporting(void)
static void vendor_disable_error_reporting(void)
{
/*
-* Don't clear on Intel CPUs. Some of these MSRs are socket-wide.
+* Don't clear on Intel or AMD CPUs. Some of these MSRs are socket-wide.
* Disabling them for just a single offlined CPU is bad, since it will
* inhibit reporting for all shared resources on the socket like the
* last level cache (LLC), the integrated memory controller (iMC), etc.
*/
- if (boot_cpu_data.x86_vendor == X86_VENDOR_INTEL)
+ if (boot_cpu_data.x86_vendor == X86_VENDOR_INTEL ||
+ boot_cpu_data.x86_vendor == X86_VENDOR_AMD)
return;
mce_disable_error_reporting();
--
2.15.1
[PATCH AUTOSEL for 4.9 083/293] drm/mgag200: Fix to always set HiPri for G200e4 V2
From: Mathieu Larouche
[ Upstream commit 0cbb738108927916a659b5b0b96e386fcd7cc6e1 ]
- Changed the HiPri value for G200e4 to always be 0.
- Added Bandwith limitation to block resolution above 1920x1200x60Hz
Signed-off-by: Mathieu Larouche
Acked-by: Dave Airlie
[seanpaul removed some trailing whitespace from the patch]
Signed-off-by: Sean Paul
Link:
http://patchwork.freedesktop.org/patch/msgid/ec0f8568d7ec41904dfe593c5deccf3f062d7bd8.1497450944.git.mathieu.larou...@matrox.com
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/mgag200/mgag200_mode.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/mgag200/mgag200_mode.c
b/drivers/gpu/drm/mgag200/mgag200_mode.c
index 6b21cb27e1cc..e27ae5437089 100644
--- a/drivers/gpu/drm/mgag200/mgag200_mode.c
+++ b/drivers/gpu/drm/mgag200/mgag200_mode.c
@@ -1133,7 +1133,10 @@ static int mga_crtc_mode_set(struct drm_crtc *crtc,
if (IS_G200_SE(mdev)) {
- if (mdev->unique_rev_id >= 0x02) {
+ if (mdev->unique_rev_id >= 0x04) {
+ WREG8(MGAREG_CRTCEXT_INDEX, 0x06);
+ WREG8(MGAREG_CRTCEXT_DATA, 0);
+ } else if (mdev->unique_rev_id >= 0x02) {
u8 hi_pri_lvl;
u32 bpp;
u32 mb;
@@ -1598,6 +1601,10 @@ static int mga_vga_mode_valid(struct drm_connector
*connector,
if (mga_vga_calculate_mode_bandwidth(mode, bpp)
> (30100 * 1024))
return MODE_BANDWIDTH;
+ } else {
+ if (mga_vga_calculate_mode_bandwidth(mode, bpp)
+ > (55000 * 1024))
+ return MODE_BANDWIDTH;
}
} else if (mdev->type == G200_WB) {
if (mode->hdisplay > 1280)
--
2.15.1
[PATCH AUTOSEL for 4.9 084/293] r8152: add byte_enable for ocp_read_word function
From: hayeswang
[ Upstream commit d8fbd27469fc02049c674de296a3263bef089131 ]
Add byte_enable for ocp_read_word() to replace reading 4
bytes data with reading the desired 2 bytes data.
This is used to avoid the issue which is described in
commit b4d99def0938 ("r8152: remove sram_read"). The
original method always reads 4 bytes data, and it may
have problem when reading the PHY registers.
The new method is supported since RTL8153B, but it
doesn't influence the previous chips. The bits of the
byte_enable for the previous chips are the reserved
bits, and the hw would ignore them.
Signed-off-by: Hayes Wang
Signed-off-by: David S. Miller
Signed-off-by: Sasha Levin
---
drivers/net/usb/r8152.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index b2d7c7e32250..29b7eb9085ab 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -871,11 +871,13 @@ static u16 ocp_read_word(struct r8152 *tp, u16 type, u16
index)
{
u32 data;
__le32 tmp;
+ u16 byen = BYTE_EN_WORD;
u8 shift = index & 2;
index &= ~3;
+ byen <<= shift;
- generic_ocp_read(tp, index, sizeof(tmp), &tmp, type);
+ generic_ocp_read(tp, index, sizeof(tmp), &tmp, type | byen);
data = __le32_to_cpu(tmp);
data >>= (shift * 8);
--
2.15.1
[PATCH AUTOSEL for 4.9 093/293] Btrfs: tolerate errors if we have retried successfully
From: Liu Bo
[ Upstream commit e3d37faba2eb19a1d459917bbf54ac1c65711510 ]
With raid1 profile, dio read isn't tolerating IO errors if read length is
less than the stripe length (64K).
Our bio didn't get split in btrfs_submit_direct_hook() if (dip->flags &
BTRFS_DIO_ORIG_BIO_SUBMITTED) is true and that happens when the read
length is less than 64k. In this case, if the underlying device returns
error somehow, bio->bi_error has recorded that error.
If we could recover the correct data from another copy in profile raid1/10/5/6,
with btrfs_subio_endio_read() returning 0, bio would have the correct data in
its vector, but bio->bi_error is not updated accordingly so that the following
dio_end_io(dio_bio, bio->bi_error) makes directIO think this read has failed.
This fixes the problem by setting bio's error to 0 if a good copy has been
found.
Signed-off-by: Liu Bo
Reviewed-by: David Sterba
Signed-off-by: David Sterba
Signed-off-by: Sasha Levin
---
fs/btrfs/inode.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/fs/btrfs/inode.c b/fs/btrfs/inode.c
index ffd5831ca15c..389ffaff72bf 100644
--- a/fs/btrfs/inode.c
+++ b/fs/btrfs/inode.c
@@ -8219,8 +8219,11 @@ static void btrfs_endio_direct_read(struct bio *bio)
struct btrfs_io_bio *io_bio = btrfs_io_bio(bio);
int err = bio->bi_error;
- if (dip->flags & BTRFS_DIO_ORIG_BIO_SUBMITTED)
+ if (dip->flags & BTRFS_DIO_ORIG_BIO_SUBMITTED) {
err = btrfs_subio_endio_read(inode, io_bio, err);
+ if (!err)
+ bio->bi_error = 0;
+ }
unlock_extent(&BTRFS_I(inode)->io_tree, dip->logical_offset,
dip->logical_offset + dip->bytes - 1);
--
2.15.1
[PATCH AUTOSEL for 4.9 101/293] mmc: sdhci-esdhc: Add SDHCI_QUIRK_32BIT_DMA_ADDR
From: Benoît Thébaudeau [ Upstream commit cbb4509374963bea440c15ff26e2501d15e7927a ] The eSDHC can only DMA from 32-bit-aligned addresses. This fixes the following test cases of mmc_test: 11: Badly aligned write 12: Badly aligned read 13: Badly aligned multi-block write 14: Badly aligned multi-block read Signed-off-by: Benoît Thébaudeau Acked-by: Adrian Hunter Reviewed-by: Fabio Estevam Signed-off-by: Ulf Hansson Signed-off-by: Sasha Levin --- drivers/mmc/host/sdhci-esdhc.h | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/mmc/host/sdhci-esdhc.h b/drivers/mmc/host/sdhci-esdhc.h index de132e281753..3d6a005ad896 100644 --- a/drivers/mmc/host/sdhci-esdhc.h +++ b/drivers/mmc/host/sdhci-esdhc.h @@ -19,6 +19,7 @@ */ #define ESDHC_DEFAULT_QUIRKS (SDHCI_QUIRK_FORCE_BLK_SZ_2048 | \ + SDHCI_QUIRK_32BIT_DMA_ADDR | \ SDHCI_QUIRK_NO_BUSY_IRQ | \ SDHCI_QUIRK_DATA_TIMEOUT_USES_SDCLK | \ SDHCI_QUIRK_PIO_NEEDS_DELAY | \ -- 2.15.1
[PATCH AUTOSEL for 4.9 120/293] arm64: ptrace: Flush user-RW TLS reg to thread_struct before reading
From: Dave Martin
[ Upstream commit 936eb65ca22ad856cb3a995e8cd742e982dc2dd0 ]
When reading current's user-writable TLS register (which occurs
when dumping core for native tasks), it is possible that userspace
has modified it since the time the task was last scheduled out.
The new TLS register value is not guaranteed to have been written
immediately back to thread_struct in this case.
As a result, a coredump can capture stale data for this register.
Reading the register for a stopped task via ptrace is unaffected.
For native tasks, this patch explicitly flushes the TPIDR_EL0
register back to thread_struct before dumping when operating on
current, thus ensuring that coredump contents are up to date. For
compat tasks, the TLS register is not user-writable and so cannot
be out of sync, so no flush is required in compat_tls_get().
Signed-off-by: Dave Martin
Signed-off-by: Will Deacon
Signed-off-by: Sasha Levin
---
arch/arm64/include/asm/processor.h | 3 +++
arch/arm64/kernel/process.c| 8 ++--
arch/arm64/kernel/ptrace.c | 4
3 files changed, 13 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/include/asm/processor.h
b/arch/arm64/include/asm/processor.h
index 60e34824e18c..b3ac6e5a70b9 100644
--- a/arch/arm64/include/asm/processor.h
+++ b/arch/arm64/include/asm/processor.h
@@ -102,6 +102,9 @@ struct thread_struct {
#define task_user_tls(t) (&(t)->thread.tp_value)
#endif
+/* Sync TPIDR_EL0 back to thread_struct for current */
+void tls_preserve_current_state(void);
+
#define INIT_THREAD { }
static inline void start_thread_common(struct pt_regs *regs, unsigned long pc)
diff --git a/arch/arm64/kernel/process.c b/arch/arm64/kernel/process.c
index 0e7394915c70..90e2823e5081 100644
--- a/arch/arm64/kernel/process.c
+++ b/arch/arm64/kernel/process.c
@@ -304,12 +304,16 @@ int copy_thread(unsigned long clone_flags, unsigned long
stack_start,
return 0;
}
+void tls_preserve_current_state(void)
+{
+ *task_user_tls(current) = read_sysreg(tpidr_el0);
+}
+
static void tls_thread_switch(struct task_struct *next)
{
unsigned long tpidr, tpidrro;
- tpidr = read_sysreg(tpidr_el0);
- *task_user_tls(current) = tpidr;
+ tls_preserve_current_state();
tpidr = *task_user_tls(next);
tpidrro = is_compat_thread(task_thread_info(next)) ?
diff --git a/arch/arm64/kernel/ptrace.c b/arch/arm64/kernel/ptrace.c
index 8eedeef375d6..d1fd560b3a2a 100644
--- a/arch/arm64/kernel/ptrace.c
+++ b/arch/arm64/kernel/ptrace.c
@@ -646,6 +646,10 @@ static int tls_get(struct task_struct *target, const
struct user_regset *regset,
void *kbuf, void __user *ubuf)
{
unsigned long *tls = &target->thread.tp_value;
+
+ if (target == current)
+ tls_preserve_current_state();
+
return user_regset_copyout(&pos, &count, &kbuf, &ubuf, tls, 0, -1);
}
--
2.15.1
[PATCH AUTOSEL for 4.9 115/293] rtlwifi: btcoex: rtl8723be: fix ant_sel not work
From: Ping-Ke Shih
[ Upstream commit f95d95a7cd5514549dcf6ba754f0ee834cce3e1f ]
To make ant_sel work, we should call power_on_setting to set antenna
correctly.
Signed-off-by: Ping-Ke Shih
Signed-off-by: Larry Finger
Cc: Yan-Hsuan Chuang
Cc: Birming Chiu
Cc: Shaofu
Cc: Steven Ting
Signed-off-by: Kalle Valo
Signed-off-by: Sasha Levin
---
drivers/net/wireless/realtek/rtlwifi/rtl8723be/hw.c | 3 +++
drivers/net/wireless/realtek/rtlwifi/wifi.h | 1 +
2 files changed, 4 insertions(+)
diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8723be/hw.c
b/drivers/net/wireless/realtek/rtlwifi/rtl8723be/hw.c
index 618e509e75d6..402977745aa7 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8723be/hw.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8723be/hw.c
@@ -848,6 +848,9 @@ static bool _rtl8723be_init_mac(struct ieee80211_hw *hw)
return false;
}
+ if (rtlpriv->cfg->ops->get_btc_status())
+ rtlpriv->btcoexist.btc_ops->btc_power_on_setting(rtlpriv);
+
bytetmp = rtl_read_byte(rtlpriv, REG_MULTI_FUNC_CTRL);
rtl_write_byte(rtlpriv, REG_MULTI_FUNC_CTRL, bytetmp | BIT(3));
diff --git a/drivers/net/wireless/realtek/rtlwifi/wifi.h
b/drivers/net/wireless/realtek/rtlwifi/wifi.h
index 340e7b324ef8..7c0fd17dbcca 100644
--- a/drivers/net/wireless/realtek/rtlwifi/wifi.h
+++ b/drivers/net/wireless/realtek/rtlwifi/wifi.h
@@ -2525,6 +2525,7 @@ struct bt_coexist_info {
struct rtl_btc_ops {
void (*btc_init_variables) (struct rtl_priv *rtlpriv);
void (*btc_init_hal_vars) (struct rtl_priv *rtlpriv);
+ void (*btc_power_on_setting)(struct rtl_priv *rtlpriv);
void (*btc_init_hw_config) (struct rtl_priv *rtlpriv);
void (*btc_ips_notify) (struct rtl_priv *rtlpriv, u8 type);
void (*btc_lps_notify)(struct rtl_priv *rtlpriv, u8 type);
--
2.15.1
[PATCH AUTOSEL for 4.9 119/293] irqchip/armada-370-xp: Re-enable per-CPU interrupts at resume time
From: Thomas Petazzoni
[ Upstream commit 0fa4ce746d1d8c8aa3d09fbc675497fa4c4a5475 ]
Commit d17cab4451df1 ("irqchip: Kill off set_irq_flags usage") changed
the code of armada_370_xp_mpic_irq_map() from using set_irq_flags() to
irq_set_probe().
While the commit log seems to imply that there are no functional
changes, there are indeed functional changes introduced by this commit:
the IRQ_NOAUTOEN flag is no longer cleared. This functional change
caused a regression on Armada XP, which no longer works properly after
suspend/resume because per-CPU interrupts remain disabled. This
regression was temporarly worked around in commit
353d6d6c82e5d ("irqchip/armada-370-xp: Fix regression by clearing
IRQ_NOAUTOEN"), but it is not the most satisfying solution. This commit
implements the solution that was initially discussed with Thomas
Gleixner.
Due to how the hardware registers work, the irq-armada-370-xp cannot
simply save/restore a bunch of registers at suspend/resume to make sure
that the interrupts remain in the same state after resuming. Therefore,
it relies on the kernel to say whether the interrupt is disabled or not,
using the irqd_irq_disabled() function. This was all working fine while
the IRQ_NOAUTOEN flag was cleared.
With the change introduced by Rob Herring in d17cab4451df1, the
IRQ_NOAUTOEN flag is now set for all interrupts. irqd_irq_disabled()
returns false for per-CPU interrupts, and therefore our per-CPU
interrupts are no longer re-enabled after resume.
This commit fixes that by using irqd_irq_disabled() only for global
interrupts, and using the newly introduced irq_percpu_is_enabled() for
per-CPU interrupts.
Also, it fixes a related problems that per-CPU interrupts were only
re-enabled on the boot CPU and not other CPUs. Until now this wasn't a
problem since on this platform, only the local timers are using per-CPU
interrupts and the local timers of secondary CPUs are turned off/on
during CPU hotplug before suspend, after after resume. However, since
Linux 4.4, we are also be using per-CPU interrupts for the network
controller, so we need to properly restore the per-CPU interrupts on
secondary CPUs as well.
Signed-off-by: Thomas Petazzoni
Signed-off-by: Marc Zyngier
Signed-off-by: Sasha Levin
---
drivers/irqchip/irq-armada-370-xp.c | 46 -
1 file changed, 40 insertions(+), 6 deletions(-)
diff --git a/drivers/irqchip/irq-armada-370-xp.c
b/drivers/irqchip/irq-armada-370-xp.c
index 8bcee65a0b8c..08cd669dc1e2 100644
--- a/drivers/irqchip/irq-armada-370-xp.c
+++ b/drivers/irqchip/irq-armada-370-xp.c
@@ -281,7 +281,6 @@ static int armada_370_xp_mpic_irq_map(struct irq_domain *h,
irq_set_percpu_devid(virq);
irq_set_chip_and_handler(virq, &armada_370_xp_irq_chip,
handle_percpu_devid_irq);
-
} else {
irq_set_chip_and_handler(virq, &armada_370_xp_irq_chip,
handle_level_irq);
@@ -345,16 +344,40 @@ static void armada_mpic_send_doorbell(const struct
cpumask *mask,
ARMADA_370_XP_SW_TRIG_INT_OFFS);
}
+static void armada_xp_mpic_reenable_percpu(void)
+{
+ unsigned int irq;
+
+ /* Re-enable per-CPU interrupts that were enabled before suspend */
+ for (irq = 0; irq < ARMADA_370_XP_MAX_PER_CPU_IRQS; irq++) {
+ struct irq_data *data;
+ int virq;
+
+ virq = irq_linear_revmap(armada_370_xp_mpic_domain, irq);
+ if (virq == 0)
+ continue;
+
+ data = irq_get_irq_data(virq);
+
+ if (!irq_percpu_is_enabled(virq))
+ continue;
+
+ armada_370_xp_irq_unmask(data);
+ }
+}
+
static int armada_xp_mpic_starting_cpu(unsigned int cpu)
{
armada_xp_mpic_perf_init();
armada_xp_mpic_smp_cpu_init();
+ armada_xp_mpic_reenable_percpu();
return 0;
}
static int mpic_cascaded_starting_cpu(unsigned int cpu)
{
armada_xp_mpic_perf_init();
+ armada_xp_mpic_reenable_percpu();
enable_percpu_irq(parent_irq, IRQ_TYPE_NONE);
return 0;
}
@@ -502,16 +525,27 @@ static void armada_370_xp_mpic_resume(void)
if (virq == 0)
continue;
- if (!is_percpu_irq(irq))
+ data = irq_get_irq_data(virq);
+
+ if (!is_percpu_irq(irq)) {
+ /* Non per-CPU interrupts */
writel(irq, per_cpu_int_base +
ARMADA_370_XP_INT_CLEAR_MASK_OFFS);
- else
+ if (!irqd_irq_disabled(data))
+ armada_370_xp_irq_unmask(data);
+ } else {
+ /* Per-CPU interrupts */
writel(irq, main_int_base +
ARMADA_370_XP_INT_SET_ENABLE_OFFS);
- data = i
[PATCH AUTOSEL for 4.9 148/293] scsi: bnx2i: missing error code in bnx2i_ep_connect()
From: Dan Carpenter
[ Upstream commit 1d32a62c74b3bcb69822b0f4745af5410cfec3a7 ]
If bnx2i_map_ep_dbell_regs() then we accidentally return NULL instead of
an error pointer. It results in a NULL dereference in
iscsi_if_ep_connect().
Fixes: cf4e6363859d ("[SCSI] bnx2i: Add bnx2i iSCSI driver.")
Signed-off-by: Dan Carpenter
Reviewed-by: Johannes Thumshirn
Signed-off-by: Martin K. Petersen
Signed-off-by: Sasha Levin
---
drivers/scsi/bnx2i/bnx2i_iscsi.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/scsi/bnx2i/bnx2i_iscsi.c b/drivers/scsi/bnx2i/bnx2i_iscsi.c
index 133901fd3e35..24c920d3ffb2 100644
--- a/drivers/scsi/bnx2i/bnx2i_iscsi.c
+++ b/drivers/scsi/bnx2i/bnx2i_iscsi.c
@@ -1909,7 +1909,8 @@ static struct iscsi_endpoint *bnx2i_ep_connect(struct
Scsi_Host *shost,
bnx2i_ep_active_list_add(hba, bnx2i_ep);
- if (bnx2i_map_ep_dbell_regs(bnx2i_ep))
+ rc = bnx2i_map_ep_dbell_regs(bnx2i_ep);
+ if (rc)
goto del_active_ep;
mutex_unlock(&hba->net_dev_lock);
--
2.15.1
[PATCH AUTOSEL for 4.9 147/293] seccomp: Adjust selftests to avoid double-join
From: Kees Cook
[ Upstream commit 93bd70e3330be45542c455dde11d8dc657ab3044 ]
While glibc's pthread implementation is rather forgiving about repeat
thread joining, Bionic has recently become much more strict. To deal with
this, actually track which threads have been successfully joined and kill
the rest at teardown.
Based on a patch from Paul Lawrence.
Cc: Paul Lawrence
Signed-off-by: Kees Cook
Signed-off-by: Sasha Levin
---
tools/testing/selftests/seccomp/seccomp_bpf.c | 51 ++-
1 file changed, 34 insertions(+), 17 deletions(-)
diff --git a/tools/testing/selftests/seccomp/seccomp_bpf.c
b/tools/testing/selftests/seccomp/seccomp_bpf.c
index f68998149351..68d0a329371f 100644
--- a/tools/testing/selftests/seccomp/seccomp_bpf.c
+++ b/tools/testing/selftests/seccomp/seccomp_bpf.c
@@ -1830,6 +1830,23 @@ struct tsync_sibling {
struct __test_metadata *metadata;
};
+/*
+ * To avoid joining joined threads (which is not allowed by Bionic),
+ * make sure we both successfully join and clear the tid to skip a
+ * later join attempt during fixture teardown. Any remaining threads
+ * will be directly killed during teardown.
+ */
+#define PTHREAD_JOIN(tid, status) \
+ do {\
+ int _rc = pthread_join(tid, status);\
+ if (_rc) { \
+ TH_LOG("pthread_join of tid %u failed: %d\n", \
+ (unsigned int)tid, _rc);\
+ } else {\
+ tid = 0;\
+ } \
+ } while (0)
+
FIXTURE_DATA(TSYNC) {
struct sock_fprog root_prog, apply_prog;
struct tsync_sibling sibling[TSYNC_SIBLINGS];
@@ -1898,14 +1915,14 @@ FIXTURE_TEARDOWN(TSYNC)
for ( ; sib < self->sibling_count; ++sib) {
struct tsync_sibling *s = &self->sibling[sib];
- void *status;
if (!s->tid)
continue;
- if (pthread_kill(s->tid, 0)) {
- pthread_cancel(s->tid);
- pthread_join(s->tid, &status);
- }
+ /*
+* If a thread is still running, it may be stuck, so hit
+* it over the head really hard.
+*/
+ pthread_kill(s->tid, 9);
}
pthread_mutex_destroy(&self->mutex);
pthread_cond_destroy(&self->cond);
@@ -1995,9 +2012,9 @@ TEST_F(TSYNC, siblings_fail_prctl)
pthread_mutex_unlock(&self->mutex);
/* Ensure diverging sibling failed to call prctl. */
- pthread_join(self->sibling[0].tid, &status);
+ PTHREAD_JOIN(self->sibling[0].tid, &status);
EXPECT_EQ(SIBLING_EXIT_FAILURE, (long)status);
- pthread_join(self->sibling[1].tid, &status);
+ PTHREAD_JOIN(self->sibling[1].tid, &status);
EXPECT_EQ(SIBLING_EXIT_UNKILLED, (long)status);
}
@@ -2037,9 +2054,9 @@ TEST_F(TSYNC, two_siblings_with_ancestor)
}
pthread_mutex_unlock(&self->mutex);
/* Ensure they are both killed and don't exit cleanly. */
- pthread_join(self->sibling[0].tid, &status);
+ PTHREAD_JOIN(self->sibling[0].tid, &status);
EXPECT_EQ(0x0, (long)status);
- pthread_join(self->sibling[1].tid, &status);
+ PTHREAD_JOIN(self->sibling[1].tid, &status);
EXPECT_EQ(0x0, (long)status);
}
@@ -2063,9 +2080,9 @@ TEST_F(TSYNC, two_sibling_want_nnp)
pthread_mutex_unlock(&self->mutex);
/* Ensure they are both upset about lacking nnp. */
- pthread_join(self->sibling[0].tid, &status);
+ PTHREAD_JOIN(self->sibling[0].tid, &status);
EXPECT_EQ(SIBLING_EXIT_NEWPRIVS, (long)status);
- pthread_join(self->sibling[1].tid, &status);
+ PTHREAD_JOIN(self->sibling[1].tid, &status);
EXPECT_EQ(SIBLING_EXIT_NEWPRIVS, (long)status);
}
@@ -2103,9 +2120,9 @@ TEST_F(TSYNC, two_siblings_with_no_filter)
pthread_mutex_unlock(&self->mutex);
/* Ensure they are both killed and don't exit cleanly. */
- pthread_join(self->sibling[0].tid, &status);
+ PTHREAD_JOIN(self->sibling[0].tid, &status);
EXPECT_EQ(0x0, (long)status);
- pthread_join(self->sibling[1].tid, &status);
+ PTHREAD_JOIN(self->sibling[1].tid, &status);
EXPECT_EQ(0x0, (long)status);
}
@@ -2148,9 +2165,9 @@ TEST_F(TSYNC, two_siblings_with_one_divergence)
pthread_mutex_unlock(&self->mutex);
/* Ensure they are both unkilled. */
- pthread_join(self->sibling[0].tid, &status);
+ PTHREAD_JOIN(self->sibling[0].tid, &status);
EXPECT_EQ(SIBLING_EXIT_UNKILLED, (long)status);
- pthread_join(self-
[PATCH AUTOSEL for 4.9 128/293] iwlwifi: mvm: use scnprintf() instead of snprintf()
From: Johannes Berg
[ Upstream commit 40e86a3619a1e84ad73c716c943f65fc38eb1e28 ]
It's safer to use scnprintf() here because the buffer might
be too short for the full format strings. In most cases
this isn't true because of external limits on the values.
In one case, this fixes a stack data leak.
Signed-off-by: Johannes Berg
Signed-off-by: Luca Coelho
Signed-off-by: Sasha Levin
---
.../net/wireless/intel/iwlwifi/mvm/debugfs-vif.c | 22 --
1 file changed, 12 insertions(+), 10 deletions(-)
diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/debugfs-vif.c
b/drivers/net/wireless/intel/iwlwifi/mvm/debugfs-vif.c
index f4d75ffe3d8a..41a105116d14 100644
--- a/drivers/net/wireless/intel/iwlwifi/mvm/debugfs-vif.c
+++ b/drivers/net/wireless/intel/iwlwifi/mvm/debugfs-vif.c
@@ -7,7 +7,7 @@
*
* Copyright(c) 2012 - 2014 Intel Corporation. All rights reserved.
* Copyright(c) 2013 - 2015 Intel Mobile Communications GmbH
- * Copyright(c) 2016Intel Deutschland GmbH
+ * Copyright(c) 2016 - 2017 Intel Deutschland GmbH
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of version 2 of the GNU General Public License as
@@ -34,7 +34,7 @@
*
* Copyright(c) 2012 - 2014 Intel Corporation. All rights reserved.
* Copyright(c) 2013 - 2015 Intel Mobile Communications GmbH
- * Copyright(c) 2016Intel Deutschland GmbH
+ * Copyright(c) 2016 - 2017 Intel Deutschland GmbH
* All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
@@ -1304,11 +1304,11 @@ static ssize_t iwl_dbgfs_low_latency_read(struct file
*file,
char buf[30] = {};
int len;
- len = snprintf(buf, sizeof(buf) - 1,
- "traffic=%d\ndbgfs=%d\nvcmd=%d\n",
- mvmvif->low_latency_traffic,
- mvmvif->low_latency_dbgfs,
- mvmvif->low_latency_vcmd);
+ len = scnprintf(buf, sizeof(buf) - 1,
+ "traffic=%d\ndbgfs=%d\nvcmd=%d\n",
+ mvmvif->low_latency_traffic,
+ mvmvif->low_latency_dbgfs,
+ mvmvif->low_latency_vcmd);
return simple_read_from_buffer(user_buf, count, ppos, buf, len);
}
@@ -1385,10 +1385,12 @@ static ssize_t iwl_dbgfs_rx_phyinfo_read(struct file
*file,
struct ieee80211_vif *vif = file->private_data;
struct iwl_mvm_vif *mvmvif = iwl_mvm_vif_from_mac80211(vif);
char buf[8];
+ int len;
- snprintf(buf, sizeof(buf), "0x%04x\n", mvmvif->mvm->dbgfs_rx_phyinfo);
+ len = scnprintf(buf, sizeof(buf), "0x%04x\n",
+ mvmvif->mvm->dbgfs_rx_phyinfo);
- return simple_read_from_buffer(user_buf, count, ppos, buf, sizeof(buf));
+ return simple_read_from_buffer(user_buf, count, ppos, buf, len);
}
static void iwl_dbgfs_quota_check(void *data, u8 *mac,
@@ -1439,7 +1441,7 @@ static ssize_t iwl_dbgfs_quota_min_read(struct file *file,
char buf[10];
int len;
- len = snprintf(buf, sizeof(buf), "%d\n", mvmvif->dbgfs_quota_min);
+ len = scnprintf(buf, sizeof(buf), "%d\n", mvmvif->dbgfs_quota_min);
return simple_read_from_buffer(user_buf, count, ppos, buf, len);
}
--
2.15.1
[PATCH AUTOSEL for 4.9 175/293] MIPS: VDSO: Add implementation of gettimeofday() fallback
From: Goran Ferenc
[ Upstream commit 0b523a85e134d41f57ddd8c5193bd9f0a5e20b0d ]
This patch adds gettimeofday_fallback() function that wraps assembly
invocation of gettimeofday() syscall using __NR_gettimeofday.
This function is used if pure VDSO implementation gettimeofday()
does not succeed for any reason. Its imeplementation is enclosed in
"#ifdef CONFIG_MIPS_CLOCK_VSYSCALL" to be in sync with the similar
arrangement for __vdso_gettimeofday().
If syscall invocation via __NR_gettimeofday fails, register a3 will
be set. So, after the syscall, register a3 is tested and the return
valuem is negated if it's set.
Signed-off-by: Goran Ferenc
Signed-off-by: Miodrag Dinic
Signed-off-by: Aleksandar Markovic
Cc: Douglas Leung
Cc: James Hogan
Cc: Paul Burton
Cc: Petar Jovanovic
Cc: Raghu Gandham
Cc: linux-m...@linux-mips.org
Cc: linux-kernel@vger.kernel.org
Patchwork: https://patchwork.linux-mips.org/patch/16640/
Signed-off-by: Ralf Baechle
Signed-off-by: Sasha Levin
---
arch/mips/vdso/gettimeofday.c | 24 +++-
1 file changed, 23 insertions(+), 1 deletion(-)
diff --git a/arch/mips/vdso/gettimeofday.c b/arch/mips/vdso/gettimeofday.c
index 5f6337545ee2..23305bf6c7a2 100644
--- a/arch/mips/vdso/gettimeofday.c
+++ b/arch/mips/vdso/gettimeofday.c
@@ -20,6 +20,28 @@
#include
#include
+#ifdef CONFIG_MIPS_CLOCK_VSYSCALL
+
+static __always_inline long gettimeofday_fallback(struct timeval *_tv,
+ struct timezone *_tz)
+{
+ register struct timezone *tz asm("a1") = _tz;
+ register struct timeval *tv asm("a0") = _tv;
+ register long ret asm("v0");
+ register long nr asm("v0") = __NR_gettimeofday;
+ register long error asm("a3");
+
+ asm volatile(
+ " syscall\n"
+ : "=r" (ret), "=r" (error)
+ : "r" (tv), "r" (tz), "r" (nr)
+ : "memory");
+
+ return error ? -ret : ret;
+}
+
+#endif
+
static __always_inline long clock_gettime_fallback(clockid_t _clkid,
struct timespec *_ts)
{
@@ -205,7 +227,7 @@ int __vdso_gettimeofday(struct timeval *tv, struct timezone
*tz)
ret = do_realtime(&ts, data);
if (ret)
- return ret;
+ return gettimeofday_fallback(tv, tz);
if (tv) {
tv->tv_sec = ts.tv_sec;
--
2.15.1
[PATCH AUTOSEL for 4.9 182/293] netfilter: ebt_nflog: fix unexpected truncated packet
From: Liping Zhang
[ Upstream commit 91af6ba7ff16bd7e5919aedfe70aad73a3375619 ]
"struct nf_loginfo li;" is a local variable, so we should set the flags
to 0 explicitly, else, packets maybe truncated unexpectedly when copied
to the userspace.
Fixes: 7643507fe8b5 ("netfilter: xt_NFLOG: nflog-range does not truncate
packets")
Cc: Vishwanath Pai
Signed-off-by: Liping Zhang
Signed-off-by: Pablo Neira Ayuso
Signed-off-by: Sasha Levin
---
net/bridge/netfilter/ebt_nflog.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/net/bridge/netfilter/ebt_nflog.c b/net/bridge/netfilter/ebt_nflog.c
index 54816150608e..16d3c8261b9d 100644
--- a/net/bridge/netfilter/ebt_nflog.c
+++ b/net/bridge/netfilter/ebt_nflog.c
@@ -30,6 +30,7 @@ ebt_nflog_tg(struct sk_buff *skb, const struct
xt_action_param *par)
li.u.ulog.copy_len = info->len;
li.u.ulog.group = info->group;
li.u.ulog.qthreshold = info->threshold;
+ li.u.ulog.flags = 0;
nf_log_packet(net, PF_BRIDGE, par->hooknum, skb, par->in,
par->out, &li, "%s", info->prefix);
--
2.15.1
[PATCH AUTOSEL for 4.9 177/293] iwlwifi: mvm: fix deduplication start logic
From: Johannes Berg
[ Upstream commit 92c4dca6f5fd3d29d8c1daf02e210dd48dc756ac ]
If the first frame on a given TID is received with seqno 0 and needed
to be retransmitted, we erroneously drop it because the deduplication
data is initialized to zero, and then comparing
if (unlikely(ieee80211_has_retry(hdr->frame_control) &&
dup_data->last_seq[tid] == hdr->seq_ctrl &&
dup_data->last_sub_frame[tid] >= sub_frame_idx))
return true;
will return in iwl_mvm_is_dup() since last_sub_frame is also set to
zero, and sub_frame_idx is usually zero since this only covers the
relatively rare case of A-MSDU.
Fix this by initializing the last_seq array to 0x, which is an
impossible value for hdr->seq_ctrl to have here because the lower
four bits are the fragment number, and fragments aren't handled in
this code but go to mac80211 instead.
Fixes: a571f5f635ef ("iwlwifi: mvm: add duplicate packet detection per rx
queue")
Signed-off-by: Johannes Berg
Signed-off-by: Luca Coelho
Signed-off-by: Sasha Levin
---
drivers/net/wireless/intel/iwlwifi/mvm/sta.c | 17 +++--
1 file changed, 15 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/sta.c
b/drivers/net/wireless/intel/iwlwifi/mvm/sta.c
index bdd1deed55a4..8efe965cab0d 100644
--- a/drivers/net/wireless/intel/iwlwifi/mvm/sta.c
+++ b/drivers/net/wireless/intel/iwlwifi/mvm/sta.c
@@ -1259,11 +1259,24 @@ int iwl_mvm_add_sta(struct iwl_mvm *mvm,
if (iwl_mvm_has_new_rx_api(mvm) &&
!test_bit(IWL_MVM_STATUS_IN_HW_RESTART, &mvm->status)) {
+ int q;
+
dup_data = kcalloc(mvm->trans->num_rx_queues,
- sizeof(*dup_data),
- GFP_KERNEL);
+ sizeof(*dup_data), GFP_KERNEL);
if (!dup_data)
return -ENOMEM;
+ /*
+* Initialize all the last_seq values to 0x which can never
+* compare equal to the frame's seq_ctrl in the check in
+* iwl_mvm_is_dup() since the lower 4 bits are the fragment
+* number and fragmented packets don't reach that function.
+*
+* This thus allows receiving a packet with seqno 0 and the
+* retry bit set as the very first packet on a new TID.
+*/
+ for (q = 0; q < mvm->trans->num_rx_queues; q++)
+ memset(dup_data[q].last_seq, 0xff,
+ sizeof(dup_data[q].last_seq));
mvm_sta->dup_data = dup_data;
}
--
2.15.1
[PATCH AUTOSEL for 4.9 209/293] vmlfb: Fix error handling in cr_pll_init()
From: Alexey Khoroshilov
[ Upstream commit 6af574e826740bf17663b48ba3f8fadb81d2113f ]
There is an error path, where iomemory is left mapped.
Found by Linux Driver Verification project (linuxtesting.org).
Signed-off-by: Alexey Khoroshilov
Cc: Alan Hourihane
Signed-off-by: Bartlomiej Zolnierkiewicz
Signed-off-by: Sasha Levin
---
drivers/video/fbdev/vermilion/cr_pll.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/video/fbdev/vermilion/cr_pll.c
b/drivers/video/fbdev/vermilion/cr_pll.c
index ebc6e6e0dd0f..ba105c876bed 100644
--- a/drivers/video/fbdev/vermilion/cr_pll.c
+++ b/drivers/video/fbdev/vermilion/cr_pll.c
@@ -185,6 +185,7 @@ static int __init cr_pll_init(void)
if (err) {
printk(KERN_ERR
"Carillo Ranch failed to initialize vml_sys.\n");
+ iounmap(mch_regs_base);
pci_dev_put(mch_dev);
return err;
}
--
2.15.1
[PATCH AUTOSEL for 4.9 200/293] ext4: change fast symlink test to not rely on i_blocks
From: Tahsin Erdogan
[ Upstream commit 407cd7fb83c0ebabb490190e673d8c71ee7df97e ]
ext4_inode_info->i_data is the storage area for 4 types of data:
a) Extents data
b) Inline data
c) Block map
d) Fast symlink data (symlink length < 60)
Extents data case is positively identified by EXT4_INODE_EXTENTS flag.
Inline data case is also obvious because of EXT4_INODE_INLINE_DATA
flag.
Distinguishing c) and d) however requires additional logic. This
currently relies on i_blocks count. After subtracting external xattr
block from i_blocks, if it is greater than 0 then we know that some
data blocks exist, so there must be a block map.
This logic got broken after ea_inode feature was added. That feature
charges the data blocks of external xattr inodes to the referencing
inode and so adds them to the i_blocks. To fix this, we could subtract
ea_inode blocks by iterating through all xattr entries and then check
whether remaining i_blocks count is zero. Besides being complicated,
this won't change the fact that the current way of distinguishing
between c) and d) is fragile.
The alternative solution is to test whether i_size is less than 60 to
determine fast symlink case. ext4_symlink() uses the same test to decide
whether to store the symlink in i_data. There is one caveat to address
before this can work though.
If an inode's i_nlink is zero during eviction, its i_size is set to
zero and its data is truncated. If system crashes before inode is removed
from the orphan list, next boot orphan cleanup may find the inode with
zero i_size. So, a symlink that had its data stored in a block may now
appear to be a fast symlink. The solution used in this patch is to treat
i_size = 0 as a non-fast symlink case. A zero sized symlink is not legal
so the only time this can happen is the mentioned scenario. This is also
logically correct because a i_size = 0 symlink has no data stored in
i_data.
Suggested-by: Andreas Dilger
Signed-off-by: Tahsin Erdogan
Signed-off-by: Theodore Ts'o
Reviewed-by: Andreas Dilger
Signed-off-by: Sasha Levin
---
fs/ext4/inode.c | 20 +---
1 file changed, 13 insertions(+), 7 deletions(-)
diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c
index 58d57c56ec62..1c6c75ad1c60 100644
--- a/fs/ext4/inode.c
+++ b/fs/ext4/inode.c
@@ -143,16 +143,12 @@ static int ext4_meta_trans_blocks(struct inode *inode,
int lblocks,
/*
* Test whether an inode is a fast symlink.
+ * A fast symlink has its symlink data stored in ext4_inode_info->i_data.
*/
int ext4_inode_is_fast_symlink(struct inode *inode)
{
-int ea_blocks = EXT4_I(inode)->i_file_acl ?
- EXT4_CLUSTER_SIZE(inode->i_sb) >> 9 : 0;
-
- if (ext4_has_inline_data(inode))
- return 0;
-
- return (S_ISLNK(inode->i_mode) && inode->i_blocks - ea_blocks == 0);
+ return S_ISLNK(inode->i_mode) && inode->i_size &&
+ (inode->i_size < EXT4_N_BLOCKS * 4);
}
/*
@@ -253,6 +249,16 @@ void ext4_evict_inode(struct inode *inode)
if (IS_SYNC(inode))
ext4_handle_sync(handle);
+
+ /*
+* Set inode->i_size to 0 before calling ext4_truncate(). We need
+* special handling of symlinks here because i_size is used to
+* determine whether ext4_inode_info->i_data contains symlink data or
+* block mappings. Setting i_size to 0 will remove its fast symlink
+* status. Erase i_data so that it becomes a valid empty block map.
+*/
+ if (ext4_inode_is_fast_symlink(inode))
+ memset(EXT4_I(inode)->i_data, 0, sizeof(EXT4_I(inode)->i_data));
inode->i_size = 0;
err = ext4_mark_inode_dirty(handle, inode);
if (err) {
--
2.15.1
[PATCH AUTOSEL for 4.9 219/293] Input: psmouse - fix Synaptics detection when protocol is disabled
From: Dmitry Torokhov
[ Upstream commit 2bc4298f59d2f15175bb568e2d356b5912d0cdd9 ]
When Synaptics protocol is disabled, we still need to try and detect the
hardware, so we can switch to SMBus device if SMbus is detected, or we know
that it is Synaptics device and reset it properly for the bare PS/2
protocol.
Fixes: c378b5119eb0 ("Input: psmouse - factor out common protocol probing code")
Reported-by: Matteo Croce
Tested-by: Matteo Croce
Signed-off-by: Dmitry Torokhov
Signed-off-by: Sasha Levin
---
drivers/input/mouse/psmouse-base.c | 34 +-
1 file changed, 21 insertions(+), 13 deletions(-)
diff --git a/drivers/input/mouse/psmouse-base.c
b/drivers/input/mouse/psmouse-base.c
index bee267424972..5cbf17aa8443 100644
--- a/drivers/input/mouse/psmouse-base.c
+++ b/drivers/input/mouse/psmouse-base.c
@@ -937,6 +937,21 @@ static void psmouse_apply_defaults(struct psmouse *psmouse)
psmouse->pt_deactivate = NULL;
}
+static bool psmouse_do_detect(int (*detect)(struct psmouse *, bool),
+ struct psmouse *psmouse, bool allow_passthrough,
+ bool set_properties)
+{
+ if (psmouse->ps2dev.serio->id.type == SERIO_PS_PSTHRU &&
+ !allow_passthrough) {
+ return false;
+ }
+
+ if (set_properties)
+ psmouse_apply_defaults(psmouse);
+
+ return detect(psmouse, set_properties) == 0;
+}
+
static bool psmouse_try_protocol(struct psmouse *psmouse,
enum psmouse_type type,
unsigned int *max_proto,
@@ -948,15 +963,8 @@ static bool psmouse_try_protocol(struct psmouse *psmouse,
if (!proto)
return false;
- if (psmouse->ps2dev.serio->id.type == SERIO_PS_PSTHRU &&
- !proto->try_passthru) {
- return false;
- }
-
- if (set_properties)
- psmouse_apply_defaults(psmouse);
-
- if (proto->detect(psmouse, set_properties) != 0)
+ if (!psmouse_do_detect(proto->detect, psmouse, proto->try_passthru,
+ set_properties))
return false;
if (set_properties && proto->init && init_allowed) {
@@ -988,8 +996,8 @@ static int psmouse_extensions(struct psmouse *psmouse,
* Always check for focaltech, this is safe as it uses pnp-id
* matching.
*/
- if (psmouse_try_protocol(psmouse, PSMOUSE_FOCALTECH,
-&max_proto, set_properties, false)) {
+ if (psmouse_do_detect(focaltech_detect,
+ psmouse, false, set_properties)) {
if (max_proto > PSMOUSE_IMEX &&
IS_ENABLED(CONFIG_MOUSE_PS2_FOCALTECH) &&
(!set_properties || focaltech_init(psmouse) == 0)) {
@@ -1035,8 +1043,8 @@ static int psmouse_extensions(struct psmouse *psmouse,
* probing for IntelliMouse.
*/
if (max_proto > PSMOUSE_PS2 &&
- psmouse_try_protocol(psmouse, PSMOUSE_SYNAPTICS, &max_proto,
-set_properties, false)) {
+ psmouse_do_detect(synaptics_detect,
+ psmouse, false, set_properties)) {
synaptics_hardware = true;
if (max_proto > PSMOUSE_IMEX) {
--
2.15.1
[PATCH AUTOSEL for 4.9 227/293] net: stmmac: dwmac-meson8b: fix setting the RGMII TX clock on Meson8b
From: Martin Blumenstingl
[ Upstream commit 433c6cab9d298687c097f6ee82e49157044dc7c6 ]
Meson8b only supports MPLL2 as clock input. The rate of the MPLL2 clock
set by Odroid-C1's u-boot is close to (but not exactly) 500MHz. The
exact rate is 52394Hz, which is calculated in
drivers/clk/meson/clk-mpll.c using the following formula:
DIV_ROUND_UP_ULL((u64)parent_rate * SDM_DEN, (SDM_DEN * n2) + sdm)
Odroid-C1's u-boot configures MPLL2 with the following values:
- SDM_DEN = 16384
- SDM = 1638
- N2 = 5
The 250MHz clock (m250_div) inside dwmac-meson8b driver is derived from
the MPLL2 clock. Due to MPLL2 running slightly faster than 500MHz the
common clock framework chooses a divider which is too big to generate
the 250MHz clock (a divider of 2 would be needed, but this is rounded up
to a divider of 3). This breaks the RTL8211F RGMII PHY on Odroid-C1
because it requires a (close to) 125MHz RGMII TX clock (on Gbit speeds,
the IP block internally divides that down to 25MHz on 100Mbit/s
connections and 2.5MHz on 10Mbit/s connections - we don't need any
special configuration for that).
Round the divider to the closest value to prevent this issue on Meson8b.
This means we'll now end up with a clock rate for the RGMII TX clock of
125001197Hz (= 125MHz plus 1197Hz), which is close-enough to 125MHz.
This has no effect on the Meson GX SoCs since there fclk_div2 is used as
input clock, which has a rate of 1000MHz (and thus is divisible cleanly
to 250MHz and 125MHz).
Fixes: 566e8251625304 ("net: stmmac: add a glue driver for the Amlogic Meson 8b
/ GXBB DWMAC")
Reported-by: Emiliano Ingrassia
Signed-off-by: Martin Blumenstingl
Reviewed-by: Jerome Brunet
Tested-by: Jerome Brunet
Signed-off-by: David S. Miller
Signed-off-by: Sasha Levin
---
drivers/net/ethernet/stmicro/stmmac/dwmac-meson8b.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-meson8b.c
b/drivers/net/ethernet/stmicro/stmmac/dwmac-meson8b.c
index ffaed1f35efe..923033867a4d 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-meson8b.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-meson8b.c
@@ -146,7 +146,9 @@ static int meson8b_init_clk(struct meson8b_dwmac *dwmac)
dwmac->m250_div.shift = PRG_ETH0_CLK_M250_DIV_SHIFT;
dwmac->m250_div.width = PRG_ETH0_CLK_M250_DIV_WIDTH;
dwmac->m250_div.hw.init = &init;
- dwmac->m250_div.flags = CLK_DIVIDER_ONE_BASED | CLK_DIVIDER_ALLOW_ZERO;
+ dwmac->m250_div.flags = CLK_DIVIDER_ONE_BASED |
+ CLK_DIVIDER_ALLOW_ZERO |
+ CLK_DIVIDER_ROUND_CLOSEST;
dwmac->m250_div_clk = devm_clk_register(dev, &dwmac->m250_div.hw);
if (WARN_ON(IS_ERR(dwmac->m250_div_clk)))
--
2.15.1
[PATCH AUTOSEL for 4.9 240/293] btrfs: fail mount when sb flag is not in BTRFS_SUPER_FLAG_SUPP
From: Anand Jain
[ Upstream commit 6f794e3c5c8f8fdd3b5bb20d9ded894e685b5bbe ]
It appears from the original commit [1] that there isn't any design
specific reason not to fail the mount instead of just warning. This
patch will change it to fail.
[1]
commit 319e4d0661e5323c9f9945f0f8fb5905e5fe74c3
btrfs: Enhance super validation check
Fixes: 319e4d0661e5323 ("btrfs: Enhance super validation check")
Signed-off-by: Anand Jain
Reviewed-by: Qu Wenruo
Reviewed-by: David Sterba
Signed-off-by: David Sterba
Signed-off-by: Sasha Levin
---
fs/btrfs/disk-io.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/fs/btrfs/disk-io.c b/fs/btrfs/disk-io.c
index 1cd325765aaa..e30aeedd326e 100644
--- a/fs/btrfs/disk-io.c
+++ b/fs/btrfs/disk-io.c
@@ -4142,9 +4142,11 @@ static int btrfs_check_super_valid(struct btrfs_fs_info
*fs_info,
btrfs_err(fs_info, "no valid FS found");
ret = -EINVAL;
}
- if (btrfs_super_flags(sb) & ~BTRFS_SUPER_FLAG_SUPP)
- btrfs_warn(fs_info, "unrecognized super flag: %llu",
+ if (btrfs_super_flags(sb) & ~BTRFS_SUPER_FLAG_SUPP) {
+ btrfs_err(fs_info, "unrecognized or unsupported super flag:
%llu",
btrfs_super_flags(sb) & ~BTRFS_SUPER_FLAG_SUPP);
+ ret = -EINVAL;
+ }
if (btrfs_super_root_level(sb) >= BTRFS_MAX_LEVEL) {
btrfs_err(fs_info, "tree_root level too big: %d >= %d",
btrfs_super_root_level(sb), BTRFS_MAX_LEVEL);
--
2.15.1
[PATCH AUTOSEL for 4.9 237/293] Btrfs: set plug for fsync
From: Liu Bo
[ Upstream commit 343e4fc1c60971b0734de26dbbd475d433950982 ]
Setting plug can merge adjacent IOs before dispatching IOs to the disk
driver.
Without plug, it'd not be a problem for single disk usecases, but for
multiple disks using raid profile, a large IO can be split to several
IOs of stripe length, and plug can be helpful to bring them together
for each disk so that we can save several disk access.
Moreover, fsync issues synchronous writes, so plug can really take
effect.
Signed-off-by: Liu Bo
Reviewed-by: David Sterba
Signed-off-by: David Sterba
Signed-off-by: Sasha Levin
---
fs/btrfs/file.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/fs/btrfs/file.c b/fs/btrfs/file.c
index c95ff096cd24..437544846e4e 100644
--- a/fs/btrfs/file.c
+++ b/fs/btrfs/file.c
@@ -1912,10 +1912,19 @@ int btrfs_release_file(struct inode *inode, struct file
*filp)
static int start_ordered_ops(struct inode *inode, loff_t start, loff_t end)
{
int ret;
+ struct blk_plug plug;
+ /*
+* This is only called in fsync, which would do synchronous writes, so
+* a plug can merge adjacent IOs as much as possible. Esp. in case of
+* multiple disks using raid profile, a large IO can be split to
+* several segments of stripe length (currently 64K).
+*/
+ blk_start_plug(&plug);
atomic_inc(&BTRFS_I(inode)->sync_writers);
ret = btrfs_fdatawrite_range(inode, start, end);
atomic_dec(&BTRFS_I(inode)->sync_writers);
+ blk_finish_plug(&plug);
return ret;
}
--
2.15.1
[PATCH AUTOSEL for 4.9 269/293] firmware: dmi_scan: Fix handling of empty DMI strings
From: Jean Delvare
[ Upstream commit a7770ae194569e96a93c48aceb304edded9cc648 ]
The handling of empty DMI strings looks quite broken to me:
* Strings from 1 to 7 spaces are not considered empty.
* True empty DMI strings (string index set to 0) are not considered
empty, and result in allocating a 0-char string.
* Strings with invalid index also result in allocating a 0-char
string.
* Strings starting with 8 spaces are all considered empty, even if
non-space characters follow (sounds like a weird thing to do, but
I have actually seen occurrences of this in DMI tables before.)
* Strings which are considered empty are reported as 8 spaces,
instead of being actually empty.
Some of these issues are the result of an off-by-one error in memcmp,
the rest is incorrect by design.
So let's get it square: missing strings and strings made of only
spaces, regardless of their length, should be treated as empty and
no memory should be allocated for them. All other strings are
non-empty and should be allocated.
Signed-off-by: Jean Delvare
Fixes: 79da4721117f ("x86: fix DMI out of memory problems")
Cc: Parag Warudkar
Cc: Ingo Molnar
Cc: Thomas Gleixner
Signed-off-by: Sasha Levin
---
drivers/firmware/dmi_scan.c | 22 +-
1 file changed, 9 insertions(+), 13 deletions(-)
diff --git a/drivers/firmware/dmi_scan.c b/drivers/firmware/dmi_scan.c
index 18afa448bb9a..659d5b29952f 100644
--- a/drivers/firmware/dmi_scan.c
+++ b/drivers/firmware/dmi_scan.c
@@ -18,7 +18,7 @@ EXPORT_SYMBOL_GPL(dmi_kobj);
* of and an antecedent to, SMBIOS, which stands for System
* Management BIOS. See further: http://www.dmtf.org/standards
*/
-static const char dmi_empty_string[] = "";
+static const char dmi_empty_string[] = "";
static u32 dmi_ver __initdata;
static u32 dmi_len;
@@ -44,25 +44,21 @@ static int dmi_memdev_nr;
static const char * __init dmi_string_nosave(const struct dmi_header *dm, u8 s)
{
const u8 *bp = ((u8 *) dm) + dm->length;
+ const u8 *nsp;
if (s) {
- s--;
- while (s > 0 && *bp) {
+ while (--s > 0 && *bp)
bp += strlen(bp) + 1;
- s--;
- }
-
- if (*bp != 0) {
- size_t len = strlen(bp)+1;
- size_t cmp_len = len > 8 ? 8 : len;
- if (!memcmp(bp, dmi_empty_string, cmp_len))
- return dmi_empty_string;
+ /* Strings containing only spaces are considered empty */
+ nsp = bp;
+ while (*nsp == ' ')
+ nsp++;
+ if (*nsp != '\0')
return bp;
- }
}
- return "";
+ return dmi_empty_string;
}
static const char * __init dmi_string(const struct dmi_header *dm, u8 s)
--
2.15.1
[PATCH AUTOSEL for 4.9 291/293] irqchip/gic-v3: Ignore disabled ITS nodes
From: Stephen Boyd
[ Upstream commit 95a2562590c2f64a0398183f978d5cf3db6d0284 ]
On some platforms there's an ITS available but it's not enabled
because reading or writing the registers is denied by the
firmware. In fact, reading or writing them will cause the system
to reset. We could remove the node from DT in such a case, but
it's better to skip nodes that are marked as "disabled" in DT so
that we can describe the hardware that exists and use the status
property to indicate how the firmware has configured things.
Cc: Stuart Yoder
Cc: Laurentiu Tudor
Cc: Greg Kroah-Hartman
Cc: Marc Zyngier
Cc: Rajendra Nayak
Signed-off-by: Stephen Boyd
Signed-off-by: Marc Zyngier
Signed-off-by: Sasha Levin
---
drivers/irqchip/irq-gic-v3-its-pci-msi.c | 2 ++
drivers/irqchip/irq-gic-v3-its-platform-msi.c | 2 ++
drivers/irqchip/irq-gic-v3-its.c | 2 ++
drivers/staging/fsl-mc/bus/irq-gic-v3-its-fsl-mc-msi.c | 2 ++
4 files changed, 8 insertions(+)
diff --git a/drivers/irqchip/irq-gic-v3-its-pci-msi.c
b/drivers/irqchip/irq-gic-v3-its-pci-msi.c
index 77931214d954..6b5f50e1fc72 100644
--- a/drivers/irqchip/irq-gic-v3-its-pci-msi.c
+++ b/drivers/irqchip/irq-gic-v3-its-pci-msi.c
@@ -132,6 +132,8 @@ static int __init its_pci_of_msi_init(void)
for (np = of_find_matching_node(NULL, its_device_id); np;
np = of_find_matching_node(np, its_device_id)) {
+ if (!of_device_is_available(np))
+ continue;
if (!of_property_read_bool(np, "msi-controller"))
continue;
diff --git a/drivers/irqchip/irq-gic-v3-its-platform-msi.c
b/drivers/irqchip/irq-gic-v3-its-platform-msi.c
index 470b4aa7d62c..e4768fcdc672 100644
--- a/drivers/irqchip/irq-gic-v3-its-platform-msi.c
+++ b/drivers/irqchip/irq-gic-v3-its-platform-msi.c
@@ -80,6 +80,8 @@ static int __init its_pmsi_init(void)
for (np = of_find_matching_node(NULL, its_device_id); np;
np = of_find_matching_node(np, its_device_id)) {
+ if (!of_device_is_available(np))
+ continue;
if (!of_property_read_bool(np, "msi-controller"))
continue;
diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c
index ac15e5d5d9b2..558c7589c329 100644
--- a/drivers/irqchip/irq-gic-v3-its.c
+++ b/drivers/irqchip/irq-gic-v3-its.c
@@ -1807,6 +1807,8 @@ static int __init its_of_probe(struct device_node *node)
for (np = of_find_matching_node(node, its_device_id); np;
np = of_find_matching_node(np, its_device_id)) {
+ if (!of_device_is_available(np))
+ continue;
if (!of_property_read_bool(np, "msi-controller")) {
pr_warn("%s: no msi-controller property, ITS ignored\n",
np->full_name);
diff --git a/drivers/staging/fsl-mc/bus/irq-gic-v3-its-fsl-mc-msi.c
b/drivers/staging/fsl-mc/bus/irq-gic-v3-its-fsl-mc-msi.c
index eaeb3c51e14b..cb95c3e940f1 100644
--- a/drivers/staging/fsl-mc/bus/irq-gic-v3-its-fsl-mc-msi.c
+++ b/drivers/staging/fsl-mc/bus/irq-gic-v3-its-fsl-mc-msi.c
@@ -75,6 +75,8 @@ int __init its_fsl_mc_msi_init(void)
for (np = of_find_matching_node(NULL, its_device_id); np;
np = of_find_matching_node(np, its_device_id)) {
+ if (!of_device_is_available(np))
+ continue;
if (!of_property_read_bool(np, "msi-controller"))
continue;
--
2.15.1
[PATCH AUTOSEL for 4.4 018/162] ACPICA: Events: Add runtime stub support for event APIs
From: Lv Zheng
[ Upstream commit 861ba6351c520328e94a78c923b415faa9116287 ]
ACPICA commit 99bc3beca92c6574ea1d69de42e54f872e6373ce
It is reported that on Linux, RTC driver complains wrong errors on
hardware reduced platform:
[4.085420] ACPI Warning: Could not enable fixed event - real_time_clock
(4) (20160422/evxface-654)
This patch fixes this by correctly adding runtime reduced hardware check.
Reported by Chandan Tagore, fixed by Lv Zheng.
Link: https://github.com/acpica/acpica/commit/99bc3bec
Tested-by: Chandan Tagore
Signed-off-by: Lv Zheng
Signed-off-by: Bob Moore
Signed-off-by: Rafael J. Wysocki
Signed-off-by: Sasha Levin
---
drivers/acpi/acpica/evxfevnt.c | 18 ++
1 file changed, 18 insertions(+)
diff --git a/drivers/acpi/acpica/evxfevnt.c b/drivers/acpi/acpica/evxfevnt.c
index 10ce48e16ebf..d830705f8a18 100644
--- a/drivers/acpi/acpica/evxfevnt.c
+++ b/drivers/acpi/acpica/evxfevnt.c
@@ -180,6 +180,12 @@ acpi_status acpi_enable_event(u32 event, u32 flags)
ACPI_FUNCTION_TRACE(acpi_enable_event);
+ /* If Hardware Reduced flag is set, there are no fixed events */
+
+ if (acpi_gbl_reduced_hardware) {
+ return_ACPI_STATUS(AE_OK);
+ }
+
/* Decode the Fixed Event */
if (event > ACPI_EVENT_MAX) {
@@ -237,6 +243,12 @@ acpi_status acpi_disable_event(u32 event, u32 flags)
ACPI_FUNCTION_TRACE(acpi_disable_event);
+ /* If Hardware Reduced flag is set, there are no fixed events */
+
+ if (acpi_gbl_reduced_hardware) {
+ return_ACPI_STATUS(AE_OK);
+ }
+
/* Decode the Fixed Event */
if (event > ACPI_EVENT_MAX) {
@@ -290,6 +302,12 @@ acpi_status acpi_clear_event(u32 event)
ACPI_FUNCTION_TRACE(acpi_clear_event);
+ /* If Hardware Reduced flag is set, there are no fixed events */
+
+ if (acpi_gbl_reduced_hardware) {
+ return_ACPI_STATUS(AE_OK);
+ }
+
/* Decode the Fixed Event */
if (event > ACPI_EVENT_MAX) {
--
2.15.1
[PATCH AUTOSEL for 4.9 265/293] IB/ipoib: Fix for potential no-carrier state
From: Alex Estrin
[ Upstream commit 1029361084d18cc270f64dfd39529fafa10cfe01 ]
On reboot SM can program port pkey table before ipoib registered its
event handler, which could result in missing pkey event and leave root
interface with initial pkey value from index 0.
Since OPA port starts with invalid pkey in index 0, root interface will
fail to initialize and stay down with no-carrier flag.
For IB ipoib interface may end up with pkey different from value
opensm put in pkey table idx 0, resulting in connectivity issues
(different mcast groups, for example).
Close the window by calling event handler after registration
to make sure ipoib pkey is in sync with port pkey table.
Reviewed-by: Mike Marciniszyn
Reviewed-by: Ira Weiny
Signed-off-by: Alex Estrin
Signed-off-by: Dennis Dalessandro
Signed-off-by: Jason Gunthorpe
Signed-off-by: Sasha Levin
---
drivers/infiniband/ulp/ipoib/ipoib_main.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/infiniband/ulp/ipoib/ipoib_main.c
b/drivers/infiniband/ulp/ipoib/ipoib_main.c
index 0df7d4504c06..17c5bc7e8957 100644
--- a/drivers/infiniband/ulp/ipoib/ipoib_main.c
+++ b/drivers/infiniband/ulp/ipoib/ipoib_main.c
@@ -2119,6 +2119,9 @@ static struct net_device *ipoib_add_port(const char
*format,
goto event_failed;
}
+ /* call event handler to ensure pkey in sync */
+ queue_work(ipoib_workqueue, &priv->flush_heavy);
+
result = register_netdev(priv->dev);
if (result) {
printk(KERN_WARNING "%s: couldn't register ipoib port %d; error
%d\n",
--
2.15.1
[PATCH AUTOSEL for 4.9 275/293] xen-netfront: Fix race between device setup and open
From: Ross Lagerwall
[ Upstream commit f599c64fdf7d9c108e8717fb04bc41c680120da4 ]
When a netfront device is set up it registers a netdev fairly early on,
before it has set up the queues and is actually usable. A userspace tool
like NetworkManager will immediately try to open it and access its state
as soon as it appears. The bug can be reproduced by hotplugging VIFs
until the VM runs out of grant refs. It registers the netdev but fails
to set up any queues (since there are no more grant refs). In the
meantime, NetworkManager opens the device and the kernel crashes trying
to access the queues (of which there are none).
Fix this in two ways:
* For initial setup, register the netdev much later, after the queues
are setup. This avoids the race entirely.
* During a suspend/resume cycle, the frontend reconnects to the backend
and the queues are recreated. It is possible (though highly unlikely) to
race with something opening the device and accessing the queues after
they have been destroyed but before they have been recreated. Extend the
region covered by the rtnl semaphore to protect against this race. There
is a possibility that we fail to recreate the queues so check for this
in the open function.
Signed-off-by: Ross Lagerwall
Reviewed-by: Boris Ostrovsky
Signed-off-by: Juergen Gross
Signed-off-by: Sasha Levin
---
drivers/net/xen-netfront.c | 46 --
1 file changed, 24 insertions(+), 22 deletions(-)
diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c
index b09c81e882b4..9a583f862109 100644
--- a/drivers/net/xen-netfront.c
+++ b/drivers/net/xen-netfront.c
@@ -350,6 +350,9 @@ static int xennet_open(struct net_device *dev)
unsigned int i = 0;
struct netfront_queue *queue = NULL;
+ if (!np->queues)
+ return -ENODEV;
+
for (i = 0; i < num_queues; ++i) {
queue = &np->queues[i];
napi_enable(&queue->napi);
@@ -1377,18 +1380,8 @@ static int netfront_probe(struct xenbus_device *dev,
#ifdef CONFIG_SYSFS
info->netdev->sysfs_groups[0] = &xennet_dev_group;
#endif
- err = register_netdev(info->netdev);
- if (err) {
- pr_warn("%s: register_netdev err=%d\n", __func__, err);
- goto fail;
- }
return 0;
-
- fail:
- xennet_free_netdev(netdev);
- dev_set_drvdata(&dev->dev, NULL);
- return err;
}
static void xennet_end_access(int ref, void *page)
@@ -1757,8 +1750,6 @@ static void xennet_destroy_queues(struct netfront_info
*info)
{
unsigned int i;
- rtnl_lock();
-
for (i = 0; i < info->netdev->real_num_tx_queues; i++) {
struct netfront_queue *queue = &info->queues[i];
@@ -1767,8 +1758,6 @@ static void xennet_destroy_queues(struct netfront_info
*info)
netif_napi_del(&queue->napi);
}
- rtnl_unlock();
-
kfree(info->queues);
info->queues = NULL;
}
@@ -1784,8 +1773,6 @@ static int xennet_create_queues(struct netfront_info
*info,
if (!info->queues)
return -ENOMEM;
- rtnl_lock();
-
for (i = 0; i < *num_queues; i++) {
struct netfront_queue *queue = &info->queues[i];
@@ -1794,7 +1781,7 @@ static int xennet_create_queues(struct netfront_info
*info,
ret = xennet_init_queue(queue);
if (ret < 0) {
- dev_warn(&info->netdev->dev,
+ dev_warn(&info->xbdev->dev,
"only created %d queues\n", i);
*num_queues = i;
break;
@@ -1808,10 +1795,8 @@ static int xennet_create_queues(struct netfront_info
*info,
netif_set_real_num_tx_queues(info->netdev, *num_queues);
- rtnl_unlock();
-
if (*num_queues == 0) {
- dev_err(&info->netdev->dev, "no queues\n");
+ dev_err(&info->xbdev->dev, "no queues\n");
return -EINVAL;
}
return 0;
@@ -1853,6 +1838,7 @@ static int talk_to_netback(struct xenbus_device *dev,
goto out;
}
+ rtnl_lock();
if (info->queues)
xennet_destroy_queues(info);
@@ -1863,6 +1849,7 @@ static int talk_to_netback(struct xenbus_device *dev,
info->queues = NULL;
goto out;
}
+ rtnl_unlock();
/* Create shared ring, alloc event channel -- for each queue */
for (i = 0; i < num_queues; ++i) {
@@ -1959,8 +1946,10 @@ abort_transaction_no_dev_fatal:
xenbus_transaction_end(xbt, 1);
destroy_ring:
xennet_disconnect_backend(info);
+ rtnl_lock();
xennet_destroy_queues(info);
out:
+ rtnl_unlock();
device_unregister(&dev->dev);
return err;
}
@@ -1996,6 +1985,15 @@ static int xennet_connect(struct net_device *dev)
netdev_update_features(dev);
rtnl_unlock();
