[LKP] [rcutorture] 894b343aa8: WARNING:at_kernel/rcu/rcutorture.c:#rcu_torture_fwd_prog
FYI, we noticed the following commit (built with gcc-7):
commit: 894b343aa8bec5ee732329f1db09b9f5c2794de5 ("rcutorture: Add call_rcu()
flooding forward-progress tests")
https://git.kernel.org/cgit/linux/kernel/git/paulmck/linux-rcu.git
dev.2018.08.30a
in testcase: trinity
with following parameters:
runtime: 300s
test-description: Trinity is a linux system call fuzz tester.
test-url: http://codemonkey.org.uk/projects/trinity/
on test machine: qemu-system-x86_64 -enable-kvm -cpu Haswell,+smep,+smap -smp 2
-m 512M
caused below changes (please refer to attached dmesg/kmsg for entire
log/backtrace):
+--+++
| | 93fd89934b
| 894b343aa8 |
+--+++
| boot_successes | 24
| 18 |
| boot_failures| 1
| 12 |
| invoked_oom-killer:gfp_mask=0x | 1
| 2 |
| Mem-Info | 1
| 2 |
| Out_of_memory:Kill_process | 1
||
| Kernel_panic-not_syncing:Out_of_memory_and_no_killable_processes | 0
| 2 |
| RIP:rcu_torture_fwd_prog | 0
| 10 |
| WARNING:at_kernel/rcu/rcutorture.c:#rcu_torture_fwd_prog | 0
| 9 |
+--+++
[ 307.810166] WARNING: CPU: 1 PID: 54 at kernel/rcu/rcutorture.c:1840
rcu_torture_fwd_prog+0x41f/0x542
[ 307.832010] Modules linked in:
[ 307.837737] CPU: 1 PID: 54 Comm: rcu_torture_fwd Tainted: GT
4.19.0-rc1-00151-g894b343 #1
[ 307.856076] RIP: 0010:rcu_torture_fwd_prog+0x41f/0x542
[ 307.866058] Code: b8 0e 00 eb e2 48 c7 05 c9 25 35 01 f0 fa 78 83 c6 05 92
99 67 02 00 e8 29 6c 09 00 84 c0 0f 85 af 00 00 00 49 83 fc 63 7f 02 <0f> 0b 48
8b 45 88 4f 8d 44 3d 00 4d 89 e9 48 c7 c6 a0 34 e2 81 48
[ 307.902163] RSP: 0018:88000c1cbe80 EFLAGS: 00010293
[ 307.912698] RAX: RBX: 0001 RCX: 88001046c080
[ 307.926369] RDX: 0017 RSI: 811c173d RDI: 88001046c080
[ 307.940082] RBP: 88000c1cbf00 R08: 0020 R09: 8800053e4ce0
[ 307.953984] R10: 8800053e4260 R11: 8800053e4d40 R12:
[ 307.968462] R13: 0003 R14: R15: 0083
[ 307.982466] FS: () GS:88001c40()
knlGS:
[ 307.998082] CS: 0010 DS: ES: CR0: 80050033
[ 308.009554] CR2: 7ffc7538e000 CR3: 02411004 CR4: 000206a0
[ 308.023264] Call Trace:
[ 308.028512] ? _raw_spin_unlock_irqrestore+0x45/0x4f
[ 308.038529] ? rcu_torture_stall+0x12d/0x12d
[ 308.047149] ? kthread+0x114/0x123
[ 308.054115] ? kthread+0x114/0x123
[ 308.060625] ? kthread_create_worker_on_cpu+0x5f/0x5f
[ 308.069703] ? ret_from_fork+0x3a/0x50
[ 308.076537] irq event stamp: 3048
[ 308.082507] hardirqs last enabled at (3047): []
kfree+0x125/0x136
[ 308.097831] hardirqs last disabled at (3048): []
trace_hardirqs_off_thunk+0x1a/0x1c
[ 308.115656] softirqs last enabled at (56): []
__do_softirq+0x359/0x39b
[ 308.130979] softirqs last disabled at (49): []
irq_exit+0x59/0x75
[ 308.145115] ---[ end trace 3654c8b0e1b99cb1 ]---
To reproduce:
git clone https://github.com/intel/lkp-tests.git
cd lkp-tests
bin/lkp qemu -k job-script # job-script is attached in this
email
Thanks,
Rong, Chen
#
# Automatically generated file; DO NOT EDIT.
# Linux/x86_64 4.19.0-rc1 Kernel Configuration
#
#
# Compiler: gcc-7 (Debian 7.3.0-16) 7.3.0
#
CONFIG_CC_IS_GCC=y
CONFIG_GCC_VERSION=70300
CONFIG_CLANG_VERSION=0
CONFIG_CONSTRUCTORS=y
CONFIG_IRQ_WORK=y
CONFIG_BUILDTIME_EXTABLE_SORT=y
CONFIG_THREAD_INFO_IN_TASK=y
#
# General setup
#
CONFIG_INIT_ENV_ARG_LIMIT=32
# CONFIG_COMPILE_TEST is not set
CONFIG_LOCALVERSION=""
CONFIG_LOCALVERSION_AUTO=y
CONFIG_BUILD_SALT=""
CONFIG_HAVE_KERNEL_GZIP=y
CONFIG_HAVE_KERNEL_BZIP2=y
CONFIG_HAVE_KERNEL_LZMA=y
CONFIG_HAVE_KERNEL_XZ=y
CONFIG_HAVE_KERNEL_LZO=y
CONFIG_HAVE_KERNEL_LZ4=y
CONFIG_KERNEL_GZIP=y
# CONFIG_KERNEL_BZIP2 is not set
# CONFIG_KERNEL_LZMA is not set
# CONFIG_KERNEL_XZ is not set
# CONFIG_KERNEL_LZO is not set
# CONFIG_KERNEL_LZ4 is not set
CONFIG_DEFAULT_HOSTNAME="(none)"
# CONFIG_SYSVIPC is not set
# CONFIG_POSIX_MQUEUE is not set
CONFIG_CROSS_MEMORY_ATTACH=y
CONFIG_USELIB=y
# CONFIG_AUDIT is not set
CONFIG_HAVE_ARCH_AUDITSYSCALL=y
#
# IRQ subsystem
#
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_GENERIC_IRQ_SHOW=y
Re: [PATCH V3 06/26] csky: Cache and TLB routines
On Thu, Sep 06, 2018 at 04:31:16PM +0200, Arnd Bergmann wrote: > On Wed, Sep 5, 2018 at 2:08 PM Guo Ren wrote: > > > diff --git a/arch/csky/include/asm/io.h b/arch/csky/include/asm/io.h > > new file mode 100644 > > index 000..fcb2142 > > --- /dev/null > > +++ b/arch/csky/include/asm/io.h > > @@ -0,0 +1,23 @@ > > +// SPDX-License-Identifier: GPL-2.0 > > +// Copyright (C) 2018 Hangzhou C-SKY Microsystems co.,ltd. > > +#ifndef __ASM_CSKY_IO_H > > +#define __ASM_CSKY_IO_H > > + > > +#include > > +#include > > +#include > > + > > +extern void __iomem *ioremap(phys_addr_t offset, size_t size); > > + > > +extern void iounmap(void *addr); > > + > > +extern int remap_area_pages(unsigned long address, phys_addr_t phys_addr, > > + size_t size, unsigned long flags); > > + > > +#define ioremap_nocache(phy, sz) ioremap(phy, sz) > > +#define ioremap_wc ioremap_nocache > > +#define ioremap_wt ioremap_nocache > > + > > +#include > > It is very unusual for an architecture to not need special handling in > asm/io.h, > to do the proper barriers etc. > > Can you describe how C-Sky hardware implements MMIO? Our mmio is uncachable and strong-order address, so there is no need barriers for access these io addr. #define ioremap_wc ioremap_nocache #define ioremap_wt ioremap_nocache Current ioremap_wc and ioremap_wt implementation are too simple and we'll improve it in future. > In particular: > > - Is a read from uncached memory always serialized with DMA, and with > other CPUs doing MMIO access to a different address? CPU use ld.w to get data from uncached strong order memory. Other CPUs use the same mmio vaddr to access the uncachable strong order memory paddr. > - How does endianess work? Are there any buses that flip bytes around > when running big-endian, or do you always do that in software? Currently we only support little-endian and soc will follow it. Guo Ren
linux-next: manual merge of the kspp tree with the tip tree
Hi Kees,
Today's linux-next merge of the kspp tree got a conflict in:
drivers/misc/lkdtm/core.c
between commit:
bef459026b16 ("lkdtm: Test copy_to_user() on bad kernel pointer under
KERNEL_DS")
from the tip tree and commit:
f90d1e0c7804 ("lkdtm: Add a test for STACKLEAK")
from the kspp tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc drivers/misc/lkdtm/core.c
index 5a755590d3dc,aca26d81e9b8..
--- a/drivers/misc/lkdtm/core.c
+++ b/drivers/misc/lkdtm/core.c
@@@ -183,7 -183,7 +183,8 @@@ static const struct crashtype crashtype
CRASHTYPE(USERCOPY_STACK_FRAME_FROM),
CRASHTYPE(USERCOPY_STACK_BEYOND),
CRASHTYPE(USERCOPY_KERNEL),
+ CRASHTYPE(USERCOPY_KERNEL_DS),
+ CRASHTYPE(STACKLEAK_ERASING),
};
pgpc_R5k95RSd.pgp
Description: OpenPGP digital signature
Re: [PATCH V3 09/26] csky: VDSO and rt_sigreturn
On Thu, Sep 06, 2018 at 04:02:42PM +0200, Arnd Bergmann wrote:
> On Wed, Sep 5, 2018 at 2:08 PM Guo Ren wrote:
>
> > +
> > + /*
> > +* __NR_rt_sigreturn must be 173
> > +* Because gcc/config/csky/linux-unwind.h use hard code to parse
> > rt_sigframe.
> > +*/
> > + err = setup_vdso_page(vdso->rt_signal_retcode);
> > + if (err) panic("Cannot set signal return code, err: %x.", err);
>
> __NR_rt_sigreturn is 139
Yes, we've changed to use asm-generic define, and I forgot to update the
comment.
Guo Ren
Re: [PATCH] ASoC: max98373: usleep_range() needs include/delay.h
Hi Grant, On Thu, Sep 06, 2018 at 05:27:28PM -0700, Grant Grundler wrote: > Commit ca917f9fe1a0fab added use of usleep_range() but not > the corresponding "include ". The result is > with Chrome OS won't build because warnings are forced > to be errors: > mnt/host/source/src/third_party/kernel/v4.4/sound/soc/codecs/max98373.c:734:2: > error: implicit declaration of function 'usleep_range' > [-Werror,-Wimplicit-function-declaration] > usleep_range(1, 11000); > ^ > > Including delay.h "fixes" this. > > Signed-off-by: Grant Grundler Reviewed-by: Benson Leung Thanks! -- Benson Leung Staff Software Engineer Chrome OS Kernel Google Inc. ble...@google.com Chromium OS Project ble...@chromium.org signature.asc Description: PGP signature
[PATCH] lib: rbtree: Fixed assign coding style issue
Fixed coding style issue.
Signed-off-by: Pablo Pellecchia
---
lib/rbtree.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/rbtree.c b/lib/rbtree.c
index d3ff682fd4b8..c47745c39671 100644
--- a/lib/rbtree.c
+++ b/lib/rbtree.c
@@ -539,7 +539,7 @@ struct rb_node *rb_next(const struct rb_node *node)
if (node->rb_right) {
node = node->rb_right;
while (node->rb_left)
- node=node->rb_left;
+ node = node->rb_left;
return (struct rb_node *)node;
}
--
2.14.1
[PATCH v11 1/2] leds: core: Introduce LED pattern trigger
This patch adds one new led trigger that LED device can configure the software or hardware pattern and trigger it. Consumers can write 'pattern' file to enable the software pattern which alters the brightness for the specified duration with one software timer. Moreover consumers can write 'hw_pattern' file to enable the hardware pattern for some LED controllers which can autonomously control brightness over time, according to some preprogrammed hardware patterns. Signed-off-by: Raphael Teysseyre Signed-off-by: Baolin Wang --- Changes from v10: - Change 'int' to 'u32' for delta_t field. Changes from v9: - None. Changes from v8: - None. Changes from v7: - Move the SC27XX hardware patterns description into its own ABI file. Changes from v6: - Improve commit message. - Optimize the description of the hw_pattern file. - Simplify some logics. Changes from v5: - Add one 'hw_pattern' file for hardware patterns. Changes from v4: - Change the repeat file to return the originally written number. - Improve comments. - Fix some build warnings. Changes from v3: - Reset pattern number to 0 if user provides incorrect pattern string. - Support one pattern. Changes from v2: - Remove hardware_pattern boolen. - Chnage the pattern string format. Changes from v1: - Use ATTRIBUTE_GROUPS() to define attributes. - Introduce hardware_pattern flag to determine if software pattern or hardware pattern. - Re-implement pattern_trig_store_pattern() function. - Remove pattern_get() interface. - Improve comments. - Other small optimization. --- .../ABI/testing/sysfs-class-led-trigger-pattern| 38 +++ drivers/leds/trigger/Kconfig |7 + drivers/leds/trigger/Makefile |1 + drivers/leds/trigger/ledtrig-pattern.c | 337 include/linux/leds.h | 16 + 5 files changed, 399 insertions(+) create mode 100644 Documentation/ABI/testing/sysfs-class-led-trigger-pattern create mode 100644 drivers/leds/trigger/ledtrig-pattern.c diff --git a/Documentation/ABI/testing/sysfs-class-led-trigger-pattern b/Documentation/ABI/testing/sysfs-class-led-trigger-pattern new file mode 100644 index 000..8cc5099 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-class-led-trigger-pattern @@ -0,0 +1,38 @@ +What: /sys/class/leds//pattern +Date: September 2018 +KernelVersion: 4.20 +Description: + Specify a software pattern for the LED, that supports altering + the brightness for the specified duration with one software + timer. + + The pattern is given by a series of tuples, of brightness and + duration (ms). The LED is expected to traverse the series and + each brightness value for the specified duration. Duration of + 0 means brightness should immediately change to new value. + + The format of the software pattern values should be: + "brightness_1 duration_1 brightness_2 duration_2 brightness_3 + duration_3 ...". + +What: /sys/class/leds//hw_pattern +Date: September 2018 +KernelVersion: 4.20 +Description: + Specify a hardware pattern for the LED, for LED hardware that + supports autonomously controlling brightness over time, according + to some preprogrammed hardware patterns. + + Since different LED hardware can have different semantics of + hardware patterns, each driver is expected to provide its own + description for the hardware patterns in their ABI documentation + file. + +What: /sys/class/leds//repeat +Date: September 2018 +KernelVersion: 4.20 +Description: + Specify a pattern repeat number. 0 means repeat indefinitely. + + This file will always return the originally written repeat + number. diff --git a/drivers/leds/trigger/Kconfig b/drivers/leds/trigger/Kconfig index 4018af7..b76fc3c 100644 --- a/drivers/leds/trigger/Kconfig +++ b/drivers/leds/trigger/Kconfig @@ -129,4 +129,11 @@ config LEDS_TRIGGER_NETDEV This allows LEDs to be controlled by network device activity. If unsure, say Y. +config LEDS_TRIGGER_PATTERN + tristate "LED Pattern Trigger" + help + This allows LEDs to be controlled by a software or hardware pattern + which is a series of tuples, of brightness and duration (ms). + If unsure, say N + endif # LEDS_TRIGGERS diff --git a/drivers/leds/trigger/Makefile b/drivers/leds/trigger/Makefile index f3cfe19..9bcb64e 100644 --- a/drivers/leds/trigger/Makefile +++ b/drivers/leds/trigger/Makefile @@ -13,3 +13,4 @@ obj-$(CONFIG_LEDS_TRIGGER_TRANSIENT) += ledtrig-transient.o obj-$(CONFIG_LEDS_TRIGGER_CAMERA) += ledtrig-camera.o obj-$(CONFIG_LEDS_TRIGGER_PANIC) += ledtrig-panic.o
Re: [PATCH v2 1/8] perf/x86: add a function to get the lbr stack
> +int perf_get_lbr_stack(struct perf_lbr_stack *stack)
> +{
> + stack->lbr_nr = x86_pmu.lbr_nr;
> + stack->lbr_tos = x86_pmu.lbr_tos;
> + stack->lbr_from = x86_pmu.lbr_from;
> + stack->lbr_to = x86_pmu.lbr_to;
> +
> + if (x86_pmu.intel_cap.lbr_format == LBR_FORMAT_INFO)
> + stack->lbr_info = MSR_LBR_INFO_0;
> + else
> + stack->lbr_info = 0;
Seems weird to export the enum value if the enum isn't exported.
How can it be used?
-Andi
[PATCH v11 2/2] leds: sc27xx: Add pattern_set/clear interfaces for LED controller
This patch implements the 'pattern_set'and 'pattern_clear'
interfaces to support SC27XX LED breathing mode.
Signed-off-by: Baolin Wang
Acked-by: Pavel Machek
---
Changes from v10:
- Add duration alignment function suggested by Jacek.
- Add acked tag from Pavel.
Changes from v9:
- Optimize the ABI documentation file.
- Update the brightness value in hardware pattern mode.
Changes from v8:
- Optimize the ABI documentation file.
Changes from v7:
- Add its own ABI documentation file.
Changes from v6:
- None.
Changes from v5:
- None.
Changes from v4:
- None.
Changes from v3:
- None.
Changes from v2:
- None.
Changes from v1:
- Remove pattern_get interface.
---
.../ABI/testing/sysfs-class-led-driver-sc27xx | 22
drivers/leds/leds-sc27xx-bltc.c| 121
2 files changed, 143 insertions(+)
create mode 100644 Documentation/ABI/testing/sysfs-class-led-driver-sc27xx
diff --git a/Documentation/ABI/testing/sysfs-class-led-driver-sc27xx
b/Documentation/ABI/testing/sysfs-class-led-driver-sc27xx
new file mode 100644
index 000..45b1e60
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-class-led-driver-sc27xx
@@ -0,0 +1,22 @@
+What: /sys/class/leds//hw_pattern
+Date: September 2018
+KernelVersion: 4.20
+Description:
+ Specify a hardware pattern for the SC27XX LED. For the SC27XX
+ LED controller, it only supports 4 stages to make a single
+ hardware pattern, which is used to configure the rise time,
+ high time, fall time and low time for the breathing mode.
+
+ For the breathing mode, the SC27XX LED only expects one
brightness
+ for the high stage. To be compatible with the hardware pattern
+ format, we should set brightness as 0 for rise stage, fall
+ stage and low stage.
+
+ Min stage duration: 125 ms
+ Max stage duration: 31875 ms
+
+ Since the stage duration step is 125 ms, the duration should be
+ a multiplier of 125, like 125ms, 250ms, 375ms, 500ms ...
31875ms.
+
+ Thus the format of the hardware pattern values should be:
+ "0 rise_duration brightness high_duration 0 fall_duration 0
low_duration".
diff --git a/drivers/leds/leds-sc27xx-bltc.c b/drivers/leds/leds-sc27xx-bltc.c
index 9d9b7aa..271e028 100644
--- a/drivers/leds/leds-sc27xx-bltc.c
+++ b/drivers/leds/leds-sc27xx-bltc.c
@@ -32,8 +32,18 @@
#define SC27XX_DUTY_MASK GENMASK(15, 0)
#define SC27XX_MOD_MASKGENMASK(7, 0)
+#define SC27XX_CURVE_SHIFT 8
+#define SC27XX_CURVE_L_MASKGENMASK(7, 0)
+#define SC27XX_CURVE_H_MASKGENMASK(15, 8)
+
#define SC27XX_LEDS_OFFSET 0x10
#define SC27XX_LEDS_MAX3
+#define SC27XX_LEDS_PATTERN_CNT4
+/* Stage duration step, in milliseconds */
+#define SC27XX_LEDS_STEP 125
+/* Minimum and maximum duration, in milliseconds */
+#define SC27XX_DELTA_T_MIN SC27XX_LEDS_STEP
+#define SC27XX_DELTA_T_MAX (SC27XX_LEDS_STEP * 255)
struct sc27xx_led {
char name[LED_MAX_NAME_SIZE];
@@ -122,6 +132,113 @@ static int sc27xx_led_set(struct led_classdev *ldev, enum
led_brightness value)
return err;
}
+static void sc27xx_led_clamp_align_delta_t(u32 *delta_t)
+{
+ u32 v, offset, t = *delta_t;
+
+ v = t + SC27XX_LEDS_STEP / 2;
+ v = clamp_t(u32, v, SC27XX_DELTA_T_MIN, SC27XX_DELTA_T_MAX);
+ offset = v - SC27XX_DELTA_T_MIN;
+ offset = SC27XX_LEDS_STEP * (offset / SC27XX_LEDS_STEP);
+
+ *delta_t = SC27XX_DELTA_T_MIN + offset;
+}
+
+static int sc27xx_led_pattern_clear(struct led_classdev *ldev)
+{
+ struct sc27xx_led *leds = to_sc27xx_led(ldev);
+ struct regmap *regmap = leds->priv->regmap;
+ u32 base = sc27xx_led_get_offset(leds);
+ u32 ctrl_base = leds->priv->base + SC27XX_LEDS_CTRL;
+ u8 ctrl_shift = SC27XX_CTRL_SHIFT * leds->line;
+ int err;
+
+ mutex_lock(>priv->lock);
+
+ /* Reset the rise, high, fall and low time to zero. */
+ regmap_write(regmap, base + SC27XX_LEDS_CURVE0, 0);
+ regmap_write(regmap, base + SC27XX_LEDS_CURVE1, 0);
+
+ err = regmap_update_bits(regmap, ctrl_base,
+ (SC27XX_LED_RUN | SC27XX_LED_TYPE) << ctrl_shift, 0);
+
+ ldev->brightness = LED_OFF;
+
+ mutex_unlock(>priv->lock);
+
+ return err;
+}
+
+static int sc27xx_led_pattern_set(struct led_classdev *ldev,
+ struct led_pattern *pattern,
+ int len, u32 repeat)
+{
+ struct sc27xx_led *leds = to_sc27xx_led(ldev);
+ u32 base = sc27xx_led_get_offset(leds);
+ u32 ctrl_base = leds->priv->base + SC27XX_LEDS_CTRL;
+ u8 ctrl_shift = SC27XX_CTRL_SHIFT * leds->line;
+ struct regmap *regmap = leds->priv->regmap;
+ int err;
+
+ /*
+* Must contain 4
Re: [PATCH v2 6/8] perf/x86/intel/lbr: guest requesting KVM for lbr stack save/restore
On Thu, Sep 06, 2018 at 07:30:54PM +0800, Wei Wang wrote: > This patch adds an interface to enable a guest to request KVM to save > and restore the lbr stack on vCPU context switching. > > KVM couldn't capture the info about whether the guest is actively using > the lbr feature via the lbr enable bit in the debugctl MSR, because that > control bit is frequently enabled and disabled by the guest, and in some > csaes, it is disabled even when the guest is actively using the lbr > feature. For example, perf_pmu_sched_task in the guest disables the bit > before reading out the lbr stack. In this case, the bit is disabled though > the guest is still using the lbr feature. > > So, a KVM-specific MSR, MSR_KVM_PV_LBR_CTRL, is used by the guest at a > proper place to tell KVM if the LBR is actively in use or not. Basically, > the lbr user callstack mode needs the lbr stack to be saved/restored on a > context switching, so we set the ACTIVE bit of MSR_KVM_PV_LBR_CTRL only > when the user callstack mode is used. The KVM hypervisor will add the lbr > stack save/restore support on vCPU switching after the ACTIVE bit is set. PV is difficult because it requires changing all the users. Maybe a better approach would be a lazy restore of the LBRs: Don't restore the LBRs on context switch, but set the LBR MSRs to intercept. Then on the first access restore the LBRs and allow direct access to the MSRs again. Also when the LBRs haven't been set to direct access the state doesn't need to be saved. -Andi
Re: KASAN: null-ptr-deref Write in binder_update_page_range
Thanks, Martijn,
Greg, could you have a look to pick up?
On Mon, Aug 27, 2018 at 03:35:24PM +0200, Martijn Coenen wrote:
> Thanks Minchan!
>
> On Thu, Aug 23, 2018 at 7:29 AM, Minchan Kim wrote:
> > Signed-off-by: Todd Kjos
> > Signed-off-by: Minchan Kim
> Reviewed-by: Martijn Coenen
>
> > ---
> > drivers/android/binder_alloc.c | 43 +++---
> > 1 file changed, 35 insertions(+), 8 deletions(-)
> >
> > diff --git a/drivers/android/binder_alloc.c b/drivers/android/binder_alloc.c
> > index 3f3b7b253445..64fd96eada31 100644
> > --- a/drivers/android/binder_alloc.c
> > +++ b/drivers/android/binder_alloc.c
> > @@ -332,6 +332,35 @@ static int binder_update_page_range(struct
> > binder_alloc *alloc, int allocate,
> > return vma ? -ENOMEM : -ESRCH;
> > }
> >
> > +
> > +static inline void binder_alloc_set_vma(struct binder_alloc *alloc,
> > + struct vm_area_struct *vma)
> > +{
> > + if (vma)
> > + alloc->vma_vm_mm = vma->vm_mm;
> > + /*
> > +* If we see alloc->vma is not NULL, buffer data structures set up
> > +* completely. Look at smp_rmb side binder_alloc_get_vma.
> > +* We also want to guarantee new alloc->vma_vm_mm is always visible
> > +* if alloc->vma is set.
> > +*/
> > + smp_wmb();
> > + alloc->vma = vma;
> > +}
> > +
> > +static inline struct vm_area_struct *binder_alloc_get_vma(
> > + struct binder_alloc *alloc)
> > +{
> > + struct vm_area_struct *vma = NULL;
> > +
> > + if (alloc->vma) {
> > + /* Look at description in binder_alloc_set_vma */
> > + smp_rmb();
> > + vma = alloc->vma;
> > + }
> > + return vma;
> > +}
> > +
> > static struct binder_buffer *binder_alloc_new_buf_locked(
> > struct binder_alloc *alloc,
> > size_t data_size,
> > @@ -348,7 +377,7 @@ static struct binder_buffer
> > *binder_alloc_new_buf_locked(
> > size_t size, data_offsets_size;
> > int ret;
> >
> > - if (alloc->vma == NULL) {
> > + if (!binder_alloc_get_vma(alloc)) {
> > binder_alloc_debug(BINDER_DEBUG_USER_ERROR,
> >"%d: binder_alloc_buf, no vma\n",
> >alloc->pid);
> > @@ -723,9 +752,7 @@ int binder_alloc_mmap_handler(struct binder_alloc
> > *alloc,
> > buffer->free = 1;
> > binder_insert_free_buffer(alloc, buffer);
> > alloc->free_async_space = alloc->buffer_size / 2;
> > - barrier();
> > - alloc->vma = vma;
> > - alloc->vma_vm_mm = vma->vm_mm;
> > + binder_alloc_set_vma(alloc, vma);
> > mmgrab(alloc->vma_vm_mm);
> >
> > return 0;
> > @@ -754,10 +781,10 @@ void binder_alloc_deferred_release(struct
> > binder_alloc *alloc)
> > int buffers, page_count;
> > struct binder_buffer *buffer;
> >
> > - BUG_ON(alloc->vma);
> > -
> > buffers = 0;
> > mutex_lock(>mutex);
> > + BUG_ON(alloc->vma);
> > +
> > while ((n = rb_first(>allocated_buffers))) {
> > buffer = rb_entry(n, struct binder_buffer, rb_node);
> >
> > @@ -900,7 +927,7 @@ int binder_alloc_get_allocated_count(struct
> > binder_alloc *alloc)
> > */
> > void binder_alloc_vma_close(struct binder_alloc *alloc)
> > {
> > - WRITE_ONCE(alloc->vma, NULL);
> > + binder_alloc_set_vma(alloc, NULL);
> > }
> >
> > /**
> > @@ -935,7 +962,7 @@ enum lru_status binder_alloc_free_page(struct list_head
> > *item,
> >
> > index = page - alloc->pages;
> > page_addr = (uintptr_t)alloc->buffer + index * PAGE_SIZE;
> > - vma = alloc->vma;
> > + vma = binder_alloc_get_vma(alloc);
> > if (vma) {
> > if (!mmget_not_zero(alloc->vma_vm_mm))
> > goto err_mmget;
> > --
> > 2.18.0.1017.ga543ac7ca45-goog
> >
> >
> >
> >
Re: linux-next: build warnings from the build of Linus' tree
Hi Peter, On Fri, 7 Sep 2018 08:14:40 +1000 Stephen Rothwell wrote: > > On Thu, 6 Sep 2018 12:49:39 +0200 Peter Oberparleiter > wrote: > > > > I've attached a quick fix that should address both problems. I'd > > appreciate if this patch could get some testing before I post proper fix > > patches. > > I have added that into linux-next today ... I will let you know this > afternoon how it went (it looks sensible, though). It certainly gets rid of the PowerPC linker messages, thanks. -- Cheers, Stephen Rothwell pgpT8rFj9k9KF.pgp Description: OpenPGP digital signature
Re: [LKP] [rcutorture] 894b343aa8: WARNING:at_kernel/rcu/rcutorture.c:#rcu_torture_fwd_prog
On Fri, Sep 07, 2018 at 11:01:56AM +0800, kernel test robot wrote:
> FYI, we noticed the following commit (built with gcc-7):
>
> commit: 894b343aa8bec5ee732329f1db09b9f5c2794de5 ("rcutorture: Add call_rcu()
> flooding forward-progress tests")
> https://git.kernel.org/cgit/linux/kernel/git/paulmck/linux-rcu.git
> dev.2018.08.30a
>
> in testcase: trinity
> with following parameters:
>
> runtime: 300s
>
> test-description: Trinity is a linux system call fuzz tester.
> test-url: http://codemonkey.org.uk/projects/trinity/
This one is real, and I have been working on it.
I added forward-progress testing, and am still working out the kinks.
It might be a little bit.
Thanx, Paul
> on test machine: qemu-system-x86_64 -enable-kvm -cpu Haswell,+smep,+smap -smp
> 2 -m 512M
>
> caused below changes (please refer to attached dmesg/kmsg for entire
> log/backtrace):
>
>
> +--+++
> | |
> 93fd89934b | 894b343aa8 |
> +--+++
> | boot_successes | 24
> | 18 |
> | boot_failures| 1
> | 12 |
> | invoked_oom-killer:gfp_mask=0x | 1
> | 2 |
> | Mem-Info | 1
> | 2 |
> | Out_of_memory:Kill_process | 1
> ||
> | Kernel_panic-not_syncing:Out_of_memory_and_no_killable_processes | 0
> | 2 |
> | RIP:rcu_torture_fwd_prog | 0
> | 10 |
> | WARNING:at_kernel/rcu/rcutorture.c:#rcu_torture_fwd_prog | 0
> | 9 |
> +--+++
>
>
>
> [ 307.810166] WARNING: CPU: 1 PID: 54 at kernel/rcu/rcutorture.c:1840
> rcu_torture_fwd_prog+0x41f/0x542
> [ 307.832010] Modules linked in:
> [ 307.837737] CPU: 1 PID: 54 Comm: rcu_torture_fwd Tainted: G
> T 4.19.0-rc1-00151-g894b343 #1
> [ 307.856076] RIP: 0010:rcu_torture_fwd_prog+0x41f/0x542
> [ 307.866058] Code: b8 0e 00 eb e2 48 c7 05 c9 25 35 01 f0 fa 78 83 c6 05 92
> 99 67 02 00 e8 29 6c 09 00 84 c0 0f 85 af 00 00 00 49 83 fc 63 7f 02 <0f> 0b
> 48 8b 45 88 4f 8d 44 3d 00 4d 89 e9 48 c7 c6 a0 34 e2 81 48
> [ 307.902163] RSP: 0018:88000c1cbe80 EFLAGS: 00010293
> [ 307.912698] RAX: RBX: 0001 RCX:
> 88001046c080
> [ 307.926369] RDX: 0017 RSI: 811c173d RDI:
> 88001046c080
> [ 307.940082] RBP: 88000c1cbf00 R08: 0020 R09:
> 8800053e4ce0
> [ 307.953984] R10: 8800053e4260 R11: 8800053e4d40 R12:
>
> [ 307.968462] R13: 0003 R14: R15:
> 0083
> [ 307.982466] FS: () GS:88001c40()
> knlGS:
> [ 307.998082] CS: 0010 DS: ES: CR0: 80050033
> [ 308.009554] CR2: 7ffc7538e000 CR3: 02411004 CR4:
> 000206a0
> [ 308.023264] Call Trace:
> [ 308.028512] ? _raw_spin_unlock_irqrestore+0x45/0x4f
> [ 308.038529] ? rcu_torture_stall+0x12d/0x12d
> [ 308.047149] ? kthread+0x114/0x123
> [ 308.054115] ? kthread+0x114/0x123
> [ 308.060625] ? kthread_create_worker_on_cpu+0x5f/0x5f
> [ 308.069703] ? ret_from_fork+0x3a/0x50
> [ 308.076537] irq event stamp: 3048
> [ 308.082507] hardirqs last enabled at (3047): []
> kfree+0x125/0x136
> [ 308.097831] hardirqs last disabled at (3048): []
> trace_hardirqs_off_thunk+0x1a/0x1c
> [ 308.115656] softirqs last enabled at (56): []
> __do_softirq+0x359/0x39b
> [ 308.130979] softirqs last disabled at (49): []
> irq_exit+0x59/0x75
> [ 308.145115] ---[ end trace 3654c8b0e1b99cb1 ]---
>
>
> To reproduce:
>
> git clone https://github.com/intel/lkp-tests.git
> cd lkp-tests
> bin/lkp qemu -k job-script # job-script is attached in this
> email
>
>
>
> Thanks,
> Rong, Chen
> #
> # Automatically generated file; DO NOT EDIT.
> # Linux/x86_64 4.19.0-rc1 Kernel Configuration
> #
>
> #
> # Compiler: gcc-7 (Debian 7.3.0-16) 7.3.0
> #
> CONFIG_CC_IS_GCC=y
> CONFIG_GCC_VERSION=70300
> CONFIG_CLANG_VERSION=0
> CONFIG_CONSTRUCTORS=y
> CONFIG_IRQ_WORK=y
> CONFIG_BUILDTIME_EXTABLE_SORT=y
> CONFIG_THREAD_INFO_IN_TASK=y
>
> #
> # General setup
> #
> CONFIG_INIT_ENV_ARG_LIMIT=32
> # CONFIG_COMPILE_TEST is not set
> CONFIG_LOCALVERSION=""
> CONFIG_LOCALVERSION_AUTO=y
> CONFIG_BUILD_SALT=""
> CONFIG_HAVE_KERNEL_GZIP=y
> CONFIG_HAVE_KERNEL_BZIP2=y
> CONFIG_HAVE_KERNEL_LZMA=y
>
Re: [PATCH v5 5/5] x86/kvm: Avoid dynamic allocation of pvclock data when SEV is active
On 9/6/18 1:50 PM, Brijesh Singh wrote: ... >> >> #define HVC_DECRYPTED_ARRAY_SIZE \ >> PAGE_ALIGN((NR_CPUS - HVC_BOOT_ARRAY_SIZE) * \ >> sizeof(struct pvclock_vsyscall_time_info)) >> > Since the hv_clock_aux array will have NR_CPUS elements hence the following definition is all we need. #ifdef CONFIG_AMD_MEM_ENCRYPT static struct pvclock_vsyscall_time_info hv_clock_aux[NR_CPUS] __decrypted_aux; #endif > Sure works for me. > >>> +static struct pvclock_vsyscall_time_info >>> + hv_clock_dec[HVC_DECRYPTED_ARRAY_SIZE] >>> __decrypted_hvclock; >>> +
Re: [PATCH 2/2] pci: dwc: add UniPhier PCIe host controller support
Hi Bjorn, On Thu, 6 Sep 2018 09:09:27 -0500 wrote: > On Thu, Sep 06, 2018 at 10:38:20AM +0900, Kunihiko Hayashi wrote: > > > > +++ b/drivers/pci/controller/dwc/pcie-uniphier.c > > > > @@ -0,0 +1,464 @@ > > > > +// SPDX-License-Identifier: GPL-2.0 > > > > +// > > > > +// PCI-express host controller driver for UniPhier SoCs > > > > +// Copyright 2018 Socionext Inc. > > > > +// Author: Kunihiko Hayashi > > > > > > Use /* ... */ comments except for the SPDX line. > > > > Okay, although I wondered which way to put, I'll replace the header next. > > The easiest thing is to look at similar files already in the tree and > follow their style. The details are here: > > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/coding-style.rst#n540 > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/license-rules.rst#n74 Thanks for your advice. Although I've found both styles in some sub-systems, these are helpful for me. I replaced it in posted v2. Thank you, --- Best Regards, Kunihiko Hayashi
Re: [PATCH 4.19 regression fix] printk: For early boot messages check loglevel when flushing the buffer
On (09/06/18 16:28), Petr Mladek wrote: > On Thu 2018-09-06 16:29:40, Sergey Senozhatsky wrote: > > On (09/05/18 13:02), Petr Mladek wrote: > > > Note that the first registered console prints all messages > > > even without this flag. > > > > Hmm, OK, interesting point. > > > > I assumed that the first console usually has CON_PRINTBUFFER bit set. > > Or even a CON_PRINTBUFFER | CON_ANYTIME combo. E.g. 8250. It sort of > > makes sense to have CON_PRINTBUFFER for the first console. Any later > > consoles [e.g. fbcon, netcon] don't necessarily have CON_PRINTBUFFER. > > > > And the first console has CON_PRINTBUFFER bit set. Well, just because > > it sounds reasonable. Those were the main assumptions behind my code > > snippet. Was any of those assumptions wrong? > > This assumption makes sense. In fact, I was wrong. I thought that > console_seq/console_idx were not updated until the first console > was registered. But it is not the case. > > It means that the hack with exclusive_console might be usable. Yeah, it is a hack. But not as dirty as it might appear, I think. In some sense it's aligned with what we do for exlusive_consoles - we treat exclusive consoles specially. So specially that even if the system panics while we re-flush logbuf messages to a new exclusive console, we flush_on_panic() only to that exclusive console, ignoring the rest of them. Not sure if it's totally right. There can be a netcon, for instance, available, which will not see panic flush() because of a exclusive console: --- diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c index c036f128cdc3..ede29a7ba6db 100644 --- a/kernel/printk/printk.c +++ b/kernel/printk/printk.c @@ -2545,6 +2545,7 @@ void console_flush_on_panic(void) * ensure may_schedule is cleared. */ console_trylock(); + exclusive_console = NULL; console_may_schedule = 0; console_unlock(); } --- Opinions? > But I would prefer to do it a cleaner way. OK. > But it is rather complicated, still hacky, ... Right. > > > > I can agree, definitely. That's one of the options. > > I prefer the revert for now. OK, agreed. IIRC I didn't see any upstream code which would have been fixed by the commit in question. -ss
Re: [PATCH] leds: pwm: silently error out on EPROBE_DEFER
On Thu 2018-09-06 15:59:04, Jerome Brunet wrote:
> When probing, if we fail to get the pwm due to probe deferal, we shouldn't
> print an error message. Just be silent in this case.
>
> Signed-off-by: Jerome Brunet
> ---
> drivers/leds/leds-pwm.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/leds/leds-pwm.c b/drivers/leds/leds-pwm.c
> index df80c89ebe7f..5d3faae51d59 100644
> --- a/drivers/leds/leds-pwm.c
> +++ b/drivers/leds/leds-pwm.c
> @@ -100,8 +100,9 @@ static int led_pwm_add(struct device *dev, struct
> led_pwm_priv *priv,
> led_data->pwm = devm_pwm_get(dev, led->name);
> if (IS_ERR(led_data->pwm)) {
> ret = PTR_ERR(led_data->pwm);
> - dev_err(dev, "unable to request PWM for %s: %d\n",
> - led->name, ret);
> + if (ret != -EPROBE_DEFER)
> + dev_err(dev, "unable to request PWM for %s: %d\n",
> + led->name, ret);
> return ret;
> }
Hmm, sometimes probing is deffered forever, and in such case debug
message is useful.
Do you see excessive number of these?
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 3/4] PCI/portdrv: Check platform supported service IRQ's
> Subject: Re: [PATCH 3/4] PCI/portdrv: Check platform supported service IRQ's
>
> On Fri, Aug 10, 2018 at 09:09:39PM +0530, Bharat Kumar Gogada wrote:
> > Platforms may have dedicated IRQ lines for PCIe services like AER/PME
> > etc., check for such IRQ lines.
> > Check mask and fill legacy irq line for services other than
>
> Capitalize "IRQ" consistently in English text like this.
>
> Insert blank lines between paragraphs.
>
> Add a reference to the relevant spec sections. PCIe r4.0, sec 6.2.4.1.2,
> 6.2.6,
> 7.5.3.12 seem pertinent.
>
Agreed, will do in next patch.
> > platform supported service IRQ number.
> >
> > Signed-off-by: Bharat Kumar Gogada
> > ---
> > drivers/pci/pcie/portdrv_core.c | 19 +--
> > 1 files changed, 17 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/pci/pcie/portdrv_core.c
> > b/drivers/pci/pcie/portdrv_core.c index e0261ad..a7d024c 100644
> > --- a/drivers/pci/pcie/portdrv_core.c
> > +++ b/drivers/pci/pcie/portdrv_core.c
> > @@ -166,6 +166,19 @@ static int pcie_init_service_irqs(struct pci_dev
> *dev, int *irqs, int mask)
> > irqs[i] = -1;
> >
> > /*
> > +* Some platforms have dedicated interrupt line from root complex
> to
> > +* interrupt controller for PCIe services like AER/PME etc., check
> > +* if platform registered with any such IRQ.
> > +*/
> > + if (pci_pcie_type(dev) == PCI_EXP_TYPE_ROOT_PORT) {
> > + int plat_mask;
> > +
> > + plat_mask = pci_check_platform_service_irqs(dev, irqs,
> mask);
> > + if (plat_mask > 0)
>
> Masks should be unsigned and tested for zero or "mask & bit". The rest of
> this file uses "int", which is sloppy because it does the wrong thing if we
> happen to use the high-order bit in the mask.
>
> > + mask = mask & plat_mask;
> > + }
>
> I think these platform IRQs are neither MSI-X/MSI nor PCI INTx wires.
> But as written, I think this patch executes pcie_port_enable_irq_vec(), which
> only does MSI-X/MSI stuff. So this must rely on that failing?
>
> And then we fall through to run pci_alloc_irq_vectors(), which is for PCI INTx
> interrupts, which doesn't seem appropriate either.
>
> It seems like this platform IRQ case should be completely separated from the
> other MSI/INTx cases, i.e., set irqs[PCIE_PORT_SERVICE_AER_SHIFT] directly
> (I think you already do this inside pci_check_platform_service_irqs()) and
> immediately return.
> Then I think you wouldn't need the other hunk below.
Agreed if we check platform service irqs here we need to deal with different
combination
of service IRQ's like AER MSI, pme platform .. and change code accordingly to
fill irqs[i].
yes it is better to call platform IRQ separately to avoid code changes in
different scenarios and
chunk below.
Can we do the following code flow:
int pcie_port_device_register(struct pci_dev *dev)
{
...
status = pcie_init_service_irqs(dev, irqs, capabilities);
if (status) {
...
}
pci_check_platform_service_irqs(dev, irqs, capabilities);
Thanks,
Bharat
RE: [PATCH v5 1/4] edac: synps: Add platform specific structures for ddrc controller
Hi Boris,
Thanks a lot for the review. Please see my comments inline.
> -Original Message-
> From: Borislav Petkov [mailto:b...@alien8.de]
> Sent: Tuesday, September 4, 2018 10:28 PM
> To: Manish Narani
> Cc: robh...@kernel.org; mark.rutl...@arm.com; Michal Simek
> ; mche...@kernel.org; leoyang...@nxp.com;
> amit.kuche...@linaro.org; o...@lixom.net; Srinivas Goud ;
> Anirudha Sarangi ; linux-kernel@vger.kernel.org;
> devicet...@vger.kernel.org; linux-arm-ker...@lists.infradead.org; linux-
> e...@vger.kernel.org
> Subject: Re: [PATCH v5 1/4] edac: synps: Add platform specific structures for
> ddrc controller
>
> On Fri, Aug 31, 2018 at 06:57:47PM +0530, Manish Narani wrote:
> > Add platform specific structures, so that we can add different IP
> > support later using quirks.
> >
> > Signed-off-by: Manish Narani
> > ---
> > drivers/edac/synopsys_edac.c | 78
> > +---
> > 1 file changed, 59 insertions(+), 19 deletions(-)
> >
> > diff --git a/drivers/edac/synopsys_edac.c
> > b/drivers/edac/synopsys_edac.c index 0c9c59e..2470d35 100644
> > --- a/drivers/edac/synopsys_edac.c
> > +++ b/drivers/edac/synopsys_edac.c
> >
> > /**
> > + * struct synps_platform_data - synps platform data structure
> > + * @edac_geterror_info:function pointer to synps edac error info
> > + * @edac_get_mtype:function pointer to synps edac mtype
> > + * @edac_get_dtype:function pointer to synps edac dtype
> > + * @edac_get_eccstate: function pointer to synps edac eccstate
> > + * @quirks:to differentiate IPs
>
> Kill all that "function pointer" fluff. Here's how I've changed it:
>
> /**
> * struct synps_platform_data - synps platform data structure
> * @edac_geterror_info: edac error info
> * @edac_get_mtype: get mtype
> * @edac_get_dtype: get dtype
> * @edac_get_eccstate: get ECC state
> * @quirks: to differentiate IPs
> */
>
> Shorter, quicker to read/scan/etc...
Okay. I will update this way throughout all the patches.
>
> > +/**
> > * synps_edac_geterror_info - Get the current ecc error info
> > - * @base: Pointer to the base address of the ddr memory controller
> > - * @p: Pointer to the synopsys ecc status structure
> > + * @priv: Pointer to DDR memory controller private instance data
> > *
> > * Determines there is any ecc error or not
>
> All sentences end with a fullstop. Check all your patches.
Okay.
>
> Also, it is not "ecc" it is "ECC". Also go over all your patches.
Okay. I updated this in (3/4), but I will update this as a separate patch in v6.
>
> > *
> > * Return: one if there is no error otherwise returns zero
> > */
> > -static int synps_edac_geterror_info(void __iomem *base,
> > - struct synps_ecc_status *p)
> > +static int synps_edac_geterror_info(struct synps_edac_priv *priv)
> > {
> > + void __iomem *base;
> > + struct synps_ecc_status *p;
> > u32 regval, clearval = 0;
>
> Please sort function local variables declaration in a reverse christmas tree
> order:
>
>longest_variable_name;
>shorter_var_name;
>even_shorter;
>i;
>
Okay.
> >
> > + if (!priv)
> > + return 1;
>
> Why are you even checking this here?
>
> synps_edac_check() is merrily dereferencing it - if anything we will explode
> there already.
Okay. I will remove this in v6.
>
> >
> > @@ -370,12 +398,12 @@ static int synps_edac_init_csrows(struct
> > mem_ctl_info *mci)
>
> That function returns 0 unconditionally. Make it a void in a prepatch.
Sure.
>
> > - if (!synps_edac_get_eccstate(baseaddr)) {
> > + p_data = of_device_get_match_data(>dev);
> > + if (!(p_data->edac_get_eccstate(baseaddr))) {
>
> Too many parentheses:
>
> if (!p_data->...
>
> is enough.
Okay.
Thanks,
Manish Narani
Re: linux-next test error
On Thu, Sep 06, 2018 at 09:12:12AM -0400, Theodore Y. Ts'o wrote: > So I don't see the point of changing return value block_page_mkwrite() > (although to be honest I haven't see the value of the vm_fault_t > change at all in the first place, at least not compared to the pain it > has caused) but no, I don't think it's worth it. You have a sampling bias though; you've only seen the filesystem patches. Filesystem fault handlers are generally more complex and written by people who have more Linux expertise. For the device drivers, it's been far more useful; bugs have been fixed and a lot of cargo-culted code has been deleted. > So what we do for functions that need to either return an error or a > pointer is to call encode the error as a "pointer" by using ERR_PTR(), > and the caller can determine whether or not it is a valid pointer or > an error code by using IS_ERR_VALUE() and turning it back into an > error by using PTR_ERR(). See include/linux/err.h. That's _usually_ the convention when a function might return a pointer or an error. Sometimes we return NULL to mean "an error happened". Sometimes that NULL means -ENOMEM. Sometimes we return ZERO_SIZE_PTR instead of -EINVAL. Sometimes we return a POISON value. It's all pretty ad-hoc, which wouldn't be as bad if it were better documented. > Similarly, all valid vm_fault_t's composed of VM_FAULT_xxx are > positive integers, and all errors are passed using the kernel's > convention of using a negative error code. So going through lots of > machinations to return both an error code and a vm_fault_t *really* > wasn't necessary. Not necessary from the point of view that there are enough bits to be able to distinguish the two, I agree. But from the mm point of view, it rather does matter that you can distinguish between SIGBUS, SIGSEGV, HWPOISON and OOM (although -ENOMEM and VM_FAULT_OOM do have the same meaning). > The issue, as near as I can understand things, for why we're going > through all of this churn, was there was a concern that in the mm > code, that all of the places which received a vm_fault_t would > sometimes see a negative error code. The proposal here is to just > *accept* that this will happen, and just simply have them *check* to > see if it's a negative error code, and convert it to the appropriate > vm_fault_t in that case. It puts the onus of the change on the mm > layer, where as the "blast radius" of the vm_fault_t "cleanup" is > spread out across a large number of subsystems. > > Which I wouldn't mind, if it wasn't causing pain. But it *is* causing > pain. As I said earlier, your sample bias shows only pain, but there are genuine improvements in the patches you haven't seen and don't care about. > And it's common kernel convention to overload an error and a pointer > using the exact same trick. We do it *all* over the place, and quite > frankly, it's less error prone than changing functions to return a > pointer and an error. No one has said, "let's do to the ERR_PTR > convention what we've done to the vm_fault_t -- it's too confusing > that a pointer might be an error, since people might forget to check > for it." If they did that, it would be NACK'ed right, left and > center. But yet it's a good idea for vm_fault_t? I actually think it would be a good idea to mark functions which return either-an-errno-or-a-pointer as returning an errptr_t. The downside is that we'd lose the type information (we'd only know that it's a void * or an errno, not that it's a struct ext4_foo * or an errno). Just like we gradually introduced 'bool' instead of 'int' for functions which only returned true/false.
Re: [PATCH] wil6210: fix unsigned cid comparison with >= 0
"Gustavo A. R. Silva" wrote:
> The comparison of cid >= 0 is always true because cid is of type u8
> (8 bits, unsigned).
>
> Fix this by removing such comparison and updating the type of
> variable cid to u8 in the caller function.
>
> Addresses-Coverity-ID: 1473079 ("Unsigned compared against 0")
> Fixes: b9010f105f21 ("wil6210: add FT roam support for AP and station")
> Signed-off-by: Gustavo A. R. Silva
> Signed-off-by: Kalle Valo
Patch applied to ath-next branch of ath.git, thanks.
49925f247016 wil6210: fix unsigned cid comparison with >= 0
--
https://patchwork.kernel.org/patch/10580739/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: [PATCH] arm64: dts: qcom: Add AOSS reset driver node for SDM845
Hi, On Sat, Sep 1, 2018 at 3:23 PM, Bjorn Andersson wrote: > From: Sibi Sankar > > This patch adds the node to support AOSS reset driver on > SDM845 > > Signed-off-by: Sibi Sankar > [bjorn: Updated addresses to match the binding that was merged] > Signed-off-by: Bjorn Andersson > --- > arch/arm64/boot/dts/qcom/sdm845.dtsi | 7 +++ > 1 file changed, 7 insertions(+) > > diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi > b/arch/arm64/boot/dts/qcom/sdm845.dtsi > index 0c9a2aa6a1b5..077760792cf0 100644 > --- a/arch/arm64/boot/dts/qcom/sdm845.dtsi > +++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi > @@ -9,6 +9,7 @@ > #include > #include > #include > +#include nit: please sort alphabetically. "reset" comes before "soc" ...other than that this looks sane to me. Feel free to add my Reviewed-by tag. -Doug
Re: [PATCH v2 1/2] mm: Move page struct poisoning to CONFIG_DEBUG_VM_PAGE_INIT_POISON
On Thu, Sep 6, 2018 at 8:13 AM Michal Hocko wrote: > > On Thu 06-09-18 07:59:03, Dave Hansen wrote: > > On 09/05/2018 10:47 PM, Michal Hocko wrote: > > > why do you have to keep DEBUG_VM enabled for workloads where the boot > > > time matters so much that few seconds matter? > > > > There are a number of distributions that run with it enabled in the > > default build. Fedora, for one. We've basically assumed for a while > > that we have to live with it in production environments. > > > > So, where does leave us? I think we either need a _generic_ debug > > option like: > > > > CONFIG_DEBUG_VM_SLOW_AS_HECK > > > > under which we can put this an other really slow VM debugging. Or, we > > need some kind of boot-time parameter to trigger the extra checking > > instead of a new CONFIG option. > > I strongly suspect nobody will ever enable such a scary looking config > TBH. Besides I am not sure what should go under that config option. > Something that takes few cycles but it is called often or one time stuff > that takes quite a long but less than aggregated overhead of the former? > > Just consider this particular case. It basically re-adds an overhead > that has always been there before the struct page init optimization > went it. The poisoning just returns it in a different form to catch > potential left overs. And we would like to have as many people willing > to running in debug mode to test for those paths because they are > basically impossible to review by the code inspection. More importantnly > the major overhead is boot time so my question still stands. Is this > worth a separate config option almost nobody is going to enable? > > Enabling DEBUG_VM by Fedora and others serves us a very good testing > coverage and I appreciate that because it has generated some useful bug > reports. Those people are paying quite a lot of overhead in runtime > which can aggregate over time is it so much to ask about one time boot > overhead? The kind of boot time add-on I saw as a result of this was about 170 seconds, or 2 minutes and 50 seconds on a 12TB system. I spent a couple minutes wondering if I had built a bad kernel or not as I was staring at a dead console the entire time after the grub prompt since I hit this so early in the boot. That is the reason why I am so eager to slice this off and make it something separate. I could easily see this as something that would get in the way of other debugging that is going on in a system. If we don't want to do a config option, then what about adding a kernel parameter to put a limit on how much memory we will initialize like this before we just start skipping it. We could put a default limit on it like 256GB and then once we cross that threshold we just don't bother poisoning any more memory. With that we would probably be able to at least cover most of the early memory init, and that value should cover most systems without getting into delays on the order of minutes. - Alex
Re: [PATCH v3 3/8] arm64: dts: qcom: msm8998: Add tsens and thermal-zones
On Thu 06 Sep 06:53 PDT 2018, Amit Kucheria wrote:
> On Tue, Sep 4, 2018 at 10:31 AM, Bjorn Andersson
> > diff --git a/arch/arm64/boot/dts/qcom/msm8998-mtp.dtsi
> > b/arch/arm64/boot/dts/qcom/msm8998-mtp.dtsi
[..]
> > + tsens0: thermal@10aa000 {
> > + compatible = "qcom,msm8998-tsens", "qcom,tsens-v2";
> > + reg = <0x10aa000 0x2000>;
> > +
>
> use the SROT and TM split for v2?
>
You're right, lets use the new style from the beginning.
Thanks,
Bjorn
Re: Widespread crashes in next-20180906
On Thu, Sep 06, 2018 at 10:04:13AM -0400, Theodore Y. Ts'o wrote: > On Thu, Sep 06, 2018 at 06:45:15AM -0700, Guenter Roeck wrote: > > Build results: > > total: 134 pass: 133 fail: 1 > > Failed builds: > > sparc32:allmodconfig > > Qemu test results: > > total: 311 pass: 76 fail: 235 > > Failed builds: > > > > > > Error message is always something like > > > > Filesystem requires source device > > VFS: Cannot open root device "hda" or unknown-block(3,0): error -2 > > > > The only variance is the boot device. Logs in full glory are available > > at https://kerneltests.org/builders/, in the "next" column. > > > > I did not run bisect, but the recent filesystem changes are a definite > > suspect. > > Yes, this is the vm_fault_t changes. See the other thread on LKML. > The guilty commit was: 83c0adddcc6e: fs: convert return type int to > vm_fault_t > That thing is just asking for trouble. Why not leave return type and value alone and add vm_fault_t * (assuming it really adds value) as another parameter ? Is it really a good idea to deviate from "return well defined error as integer" as used everywhere else in the kernel ? Do we really need "my_favored_error_return_t" in every subsystem going forward ? Oh well, I guess (hope) that is all discussed in the other thread. > This is the *second* time vm_fault_t patches have broken things. The > first time it went through the ext4 tree, and I NACK'ed it after > running a 60 second smoke test showed it was broken. The seocnd time > the problem was supposedly fixed, but it went through the mm tree, and > so I didn't have a chance regression test or stop it... > Looking at the patch, NACK seems like the proper response to me, maybe augmented with "please refrain from shooting yourself (and everyone else) in the foot". Guenter
Re: [PATCH v2 2/3] arm64: dts: msm8916: Drop model and compatible
On Wed 05 Sep 11:35 PDT 2018, Niklas Cassel wrote:
> DTS board files should always specify model and compatible.
>
> All DTS board files that includes msm8916.dtsi
> already specifies model and compatible, and will thus
> override the model and compatible in msm8916.dtsi.
>
> Drop model and compatible from msm8916.dtsi,
> since they are only a source of confusion.
>
> Signed-off-by: Niklas Cassel
Reviewed-by: Bjorn Andersson
Regards,
Bjorn
> ---
> arch/arm64/boot/dts/qcom/msm8916.dtsi | 3 ---
> 1 file changed, 3 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/qcom/msm8916.dtsi
> b/arch/arm64/boot/dts/qcom/msm8916.dtsi
> index 7b32b8990d62..726a45960742 100644
> --- a/arch/arm64/boot/dts/qcom/msm8916.dtsi
> +++ b/arch/arm64/boot/dts/qcom/msm8916.dtsi
> @@ -18,9 +18,6 @@
> #include
>
> / {
> - model = "Qualcomm Technologies, Inc. MSM8916";
> - compatible = "qcom,msm8916";
> -
> interrupt-parent = <>;
>
> #address-cells = <2>;
> --
> 2.17.1
>
Re: [PATCH] efi_stub: update documentation on dtb= parameter
On Wed, 5 Sep 2018 20:07:50 +0100 Grant Likely wrote: > The dtb= parameter is no longer the primary mechanism for providing a > devicetree to the kernel. Now either firmware or the boot selector (ex. > Grub) should provide the devicetree and dtb= should only be used for > debug or when using firmware that doesn't understand DT. > Update the EFI stub documentation to reflect the current usage. So I hate to be obnoxious, but... > IMPORTANT NOTICE: The contents of this email and any attachments are > confidential and may also be privileged. If you are not the intended > recipient, please notify the sender immediately and do not disclose the > contents to any other person, use it for any purpose, or store or copy > the information in any medium. Thank you. Can I get a version of the patch without this language? Then I'll be glad to apply it. Thanks, jon
Re: [PATCH v2 3/3] arm64: dts: msm8996: Drop model
On Wed 05 Sep 11:35 PDT 2018, Niklas Cassel wrote:
> DTS board files should always specify model and compatible.
>
> All DTS board files that includes msm8996.dtsi
> already specifies model and compatible, and will thus
> override the model and compatible in msm8996.dtsi.
>
> Drop model from msm8916.dtsi, since it is only a source of confusion.
>
> Signed-off-by: Niklas Cassel
Reviewed-by: Bjorn Andersson
Regards,
Bjorn
> ---
> arch/arm64/boot/dts/qcom/msm8996.dtsi | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/qcom/msm8996.dtsi
> b/arch/arm64/boot/dts/qcom/msm8996.dtsi
> index cd3865e7a270..b4d635bb81ac 100644
> --- a/arch/arm64/boot/dts/qcom/msm8996.dtsi
> +++ b/arch/arm64/boot/dts/qcom/msm8996.dtsi
> @@ -16,8 +16,6 @@
> #include
>
> / {
> - model = "Qualcomm Technologies, Inc. MSM8996";
> -
> interrupt-parent = <>;
>
> #address-cells = <2>;
> --
> 2.17.1
>
tty locking issues? (v4.19-rc2)
Hi, While fuzzing arm64 v4.19-rc2 with Syzkaller, I'm seeing a number of splats (e.g. use-after-frees) in tty ioctl handling, e.g. n_tty_set_termios. I've included one such splat at the end of this email. It looks like syzbot has been hitting these (e.g. [1]) for a number of months, so I guess this isn't a new issue. I started to take a look, and it seems like we may have a locking issue in the tty layer. The comment above n_tty_set_termios states: Locking: Caller holds tty->termios_rwsem ... is that still expected, or is the comment out-of-date? Assuming it was accurate, I tried adding a corresponding lockdep assert: lockdep_assert_held(>termios_rwsem); ... but this fires immediately at boot time: [3.672047] WARNING: CPU: 1 PID: 1 at drivers/tty/n_tty.c:1783 n_tty_set_termios+0xb8c/0xd80 [3.673589] CPU: 1 PID: 1 Comm: swapper/0 Not tainted 4.19.0-rc2-1-g507d1a6f0b88-dirty #1 [3.675542] Hardware name: linux,dummy-virt (DT) [3.676594] pstate: 8045 (Nzcv daif +PAN -UAO) [3.677674] pc : n_tty_set_termios+0xb8c/0xd80 [3.678678] lr : n_tty_set_termios+0xb8c/0xd80 [3.679686] sp : 80006a44f630 [3.680442] x29: 80006a44f630 x28: 2d960780 [3.681636] x27: 006000c0 x26: [3.682849] x25: 2ca20f60 x24: [3.684042] x23: 800066aa5958 x22: 2f43d820 [3.685248] x21: x20: 2f9c7000 [3.686464] x19: 800066aa5500 x18: dfff2000 [3.687683] x17: cf3cf3cf3cf3cf3d x16: [3.67] x15: 2e02f000 x14: 2d478000 [3.690106] x13: 2d478ae0 x12: 2ebc1000 [3.691378] x11: 2ebc1b80 x10: dfff2000 [3.692587] x9 : x8 : 1d489e9e [3.693810] x7 : f1f1f1f1 x6 : 1fffe40001a8f15c [3.695035] x5 : 80006a44 x4 : [3.696262] x3 : 2963f2a4 x2 : [3.697487] x1 : 80006a44 x0 : [3.698713] Call trace: [3.699312] n_tty_set_termios+0xb8c/0xd80 [3.700257] n_tty_open+0xfc/0x148 [3.701041] tty_ldisc_open.isra.3+0xd8/0x160 [3.702030] tty_ldisc_setup+0x44/0x100 [3.702912] tty_init_dev+0x180/0x3f8 [3.703773] tty_open+0x55c/0x8f0 [3.704542] chrdev_open+0x138/0x3e8 [3.705368] do_dentry_open+0x4b4/0xbc8 [3.706247] vfs_open+0x90/0xc0 [3.706978] path_openat+0xb78/0x27d0 [3.707822] do_filp_open+0x14c/0x208 [3.708662] do_sys_open+0x358/0x470 [3.709484] kernel_init_freeable+0xdb4/0xe58 [3.710472] kernel_init+0x14/0x1bc [3.711280] ret_from_fork+0x10/0x18 [3.712089] irq event stamp: 419648 [3.712893] hardirqs last enabled at (419647): [] get_page_from_freelist+0x1160/0x4190 [3.714994] hardirqs last disabled at (419648): [] do_debug_exception+0x2dc/0x430 [3.754992] softirqs last enabled at (419544): [] __do_softirq+0xa1c/0xf2c [3.757122] softirqs last disabled at (419537): [] irq_exit+0x2a4/0x318 [3.759573] ---[ end trace e5aa01f18f5a2204 ]--- ... perhaps that expected at boot time, but never thereafter? Are the locking comments in drivers/tty/n_tty.c accurate (at least in intent)? If so, can we turn those into lockdep asserts so that they get tested? I'm not all that familiar with the tty layer, so I'm not sure how to debug this much further. Thanks, Mark. [1] https://syzkaller.appspot.com/bug?id=1e850009fca0b64ce49dc16499bda4f7de0ab1a5 Syzkaller hit 'KASAN: user-memory-access Write in n_tty_set_termios' bug. IPv6: ADDRCONF(NETDEV_UP): veth0: link is not ready IPv6: ADDRCONF(NETDEV_UP): veth1: link is not ready IPv6: ADDRCONF(NETDEV_CHANGE): veth1: link becomes ready IPv6: ADDRCONF(NETDEV_CHANGE): veth0: link becomes ready == BUG: KASAN: user-memory-access in memset include/linux/string.h:330 [inline] BUG: KASAN: user-memory-access in bitmap_zero include/linux/bitmap.h:216 [inline] BUG: KASAN: user-memory-access in n_tty_set_termios+0xe4/0xd08 drivers/tty/n_tty.c:1784 Write of size 512 at addr 1060 by task syz-executor0/3007 CPU: 1 PID: 3007 Comm: syz-executor0 Not tainted 4.19.0-rc2-dirty #4 Hardware name: linux,dummy-virt (DT) Call trace: dump_backtrace+0x0/0x340 arch/arm64/include/asm/ptrace.h:270 show_stack+0x20/0x30 arch/arm64/kernel/traps.c:152 __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0xec/0x150 lib/dump_stack.c:113 kasan_report_error mm/kasan/report.c:352 [inline] kasan_report+0x228/0x360 mm/kasan/report.c:412 check_memory_region_inline mm/kasan/kasan.c:253 [inline] check_memory_region+0x114/0x1c8 mm/kasan/kasan.c:267 memset+0x2c/0x50 mm/kasan/kasan.c:285 memset include/linux/string.h:330 [inline] bitmap_zero include/linux/bitmap.h:216 [inline] n_tty_set_termios+0xe4/0xd08 drivers/tty/n_tty.c:1784 tty_set_termios+0x538/0x760
Re: Ensuring wall_to_monotonic is not positive breaks use case
Rick, On Wed, 5 Sep 2018, Rick Ratzel wrote: > We're looking for suggestions on how best to proceed with a new change > that ideally both supports the use case described above, as well as > addresses the symptoms brought up in the initial commit (negative boot > time causes get_expiry() to overflow time_t, and show_stat() uses > "unsigned long" to print negative btime). Any thoughts on this would be > greatly appreciated. Those symptoms are just the tip of the iceberg. For sure it screws up everything around boot time and a lot of things use boottime nowadays. So reverting this is not really an option. Chosing a PTP grandmaster which populates random time is a really great idea. Why has this industry the tendency to turn everything into a trainwreck? Thanks, tglx
[PATCH v2 1/2] soc: qcom: geni: Don't ignore clk_round_rate() errors in geni_se_clk_tbl_get()
The function clk_round_rate() is defined to return a "long", not an
"unsigned long". That's because it might return a negative error
code. Change the call in geni_se_clk_tbl_get() to check for errors.
While we're at it, get rid of a useless init of "freq".
NOTE: overall the idea that we should iterate over clk_round_rate() to
try to reconstruct a table already present in the clock driver is
questionable. Specifically:
- This method relies on "clk_round_rate()" rounding up.
- This method only works if the table is sorted and has no duplicates.
...this patch doesn't try to fix those problems, it just makes the
error handling more correct.
Fixes: eddac5af0654 ("soc: qcom: Add GENI based QUP Wrapper driver")
Signed-off-by: Douglas Anderson
Reviewed-by: Matthias Kaehlcke
---
Changes in v2:
- Get rid of unneeded init of "freq" (Matthias).
- Add Matthias tag.
drivers/soc/qcom/qcom-geni-se.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/soc/qcom/qcom-geni-se.c b/drivers/soc/qcom/qcom-geni-se.c
index feed3db21c10..d2d97f1d7428 100644
--- a/drivers/soc/qcom/qcom-geni-se.c
+++ b/drivers/soc/qcom/qcom-geni-se.c
@@ -513,7 +513,7 @@ EXPORT_SYMBOL(geni_se_resources_on);
*/
int geni_se_clk_tbl_get(struct geni_se *se, unsigned long **tbl)
{
- unsigned long freq = 0;
+ long freq;
int i;
if (se->clk_perf_tbl) {
@@ -529,7 +529,7 @@ int geni_se_clk_tbl_get(struct geni_se *se, unsigned long
**tbl)
for (i = 0; i < MAX_CLK_PERF_LEVEL; i++) {
freq = clk_round_rate(se->clk, freq + 1);
- if (!freq || freq == se->clk_perf_tbl[i - 1])
+ if (freq <= 0 || freq == se->clk_perf_tbl[i - 1])
break;
se->clk_perf_tbl[i] = freq;
}
--
2.19.0.rc1.350.ge57e33dbd1-goog
Re: [PATCH 1/2] soc: qcom: geni: Don't ignore clk_round_rate() errors in geni_se_clk_tbl_get()
Hi,
On Wed, Sep 5, 2018 at 4:37 PM, Matthias Kaehlcke wrote:
>> int geni_se_clk_tbl_get(struct geni_se *se, unsigned long **tbl)
>> {
>> - unsigned long freq = 0;
>> + long freq = 0;
>
> nit: Since you are already touching this you could also remove the
> pointless initialization, 'freq' is always assigned before it is used.
Done.
-Doug
possible deadlock in ext4_evict_inode
Hello,
syzbot found the following crash on:
HEAD commit:b36fdc6853a3 Merge tag 'gpio-v4.19-2' of git://git.kernel...
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=1716bc9e40
kernel config: https://syzkaller.appspot.com/x/.config?x=6c9564cd177daf0c
dashboard link: https://syzkaller.appspot.com/bug?extid=0eefc1e06a77d327a056
compiler: gcc (GCC) 8.0.1 20180413 (experimental)
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=13db48be40
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+0eefc1e06a77d327a...@syzkaller.appspotmail.com
8021q: adding VLAN 0 to HW filter on device team0
8021q: adding VLAN 0 to HW filter on device team0
syz-executor0 (11193) used greatest stack depth: 15352 bytes left
==
WARNING: possible circular locking dependency detected
4.19.0-rc2+ #1 Not tainted
--
syz-executor3/11182 is trying to acquire lock:
c157b042 (sb_internal){.+.+}, at: sb_start_intwrite
include/linux/fs.h:1613 [inline]
c157b042 (sb_internal){.+.+}, at: ext4_evict_inode+0x588/0x19b0
fs/ext4/inode.c:250
but task is already holding lock:
128cdd3b (fs_reclaim){+.+.}, at:
fs_reclaim_acquire.part.98+0x0/0x30 mm/page_alloc.c:463
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #3 (fs_reclaim){+.+.}:
__fs_reclaim_acquire mm/page_alloc.c:3728 [inline]
fs_reclaim_acquire.part.98+0x24/0x30 mm/page_alloc.c:3739
fs_reclaim_acquire+0x14/0x20 mm/page_alloc.c:3740
slab_pre_alloc_hook mm/slab.h:418 [inline]
slab_alloc mm/slab.c:3378 [inline]
kmem_cache_alloc_trace+0x2d/0x730 mm/slab.c:3618
kmalloc include/linux/slab.h:513 [inline]
kzalloc include/linux/slab.h:707 [inline]
smk_fetch.part.24+0x5a/0xf0 security/smack/smack_lsm.c:273
smk_fetch security/smack/smack_lsm.c:3548 [inline]
smack_d_instantiate+0x946/0xea0 security/smack/smack_lsm.c:3502
security_d_instantiate+0x5c/0xf0 security/security.c:1287
d_instantiate+0x5e/0xa0 fs/dcache.c:1870
shmem_mknod+0x189/0x1f0 mm/shmem.c:2812
vfs_mknod+0x447/0x800 fs/namei.c:3719
handle_create+0x1ff/0x7c0 drivers/base/devtmpfs.c:211
handle drivers/base/devtmpfs.c:374 [inline]
devtmpfsd+0x27f/0x4c0 drivers/base/devtmpfs.c:400
kthread+0x35a/0x420 kernel/kthread.c:246
ret_from_fork+0x3a/0x50 arch/x86/entry/entry_64.S:413
-> #2 (>smk_lock){+.+.}:
__mutex_lock_common kernel/locking/mutex.c:925 [inline]
__mutex_lock+0x171/0x1700 kernel/locking/mutex.c:1073
mutex_lock_nested+0x16/0x20 kernel/locking/mutex.c:1088
smack_d_instantiate+0x130/0xea0 security/smack/smack_lsm.c:3369
security_d_instantiate+0x5c/0xf0 security/security.c:1287
d_instantiate_new+0x7e/0x160 fs/dcache.c:1889
ext4_add_nondir+0x81/0x90 fs/ext4/namei.c:2415
ext4_symlink+0x761/0x1170 fs/ext4/namei.c:3162
vfs_symlink+0x37a/0x5d0 fs/namei.c:4127
do_symlinkat+0x242/0x2d0 fs/namei.c:4154
__do_sys_symlink fs/namei.c:4173 [inline]
__se_sys_symlink fs/namei.c:4171 [inline]
__x64_sys_symlink+0x59/0x80 fs/namei.c:4171
do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
entry_SYSCALL_64_after_hwframe+0x49/0xbe
-> #1 (jbd2_handle){}:
start_this_handle+0x5c0/0x1260 fs/jbd2/transaction.c:385
jbd2__journal_start+0x3c9/0x9f0 fs/jbd2/transaction.c:439
__ext4_journal_start_sb+0x18d/0x590 fs/ext4/ext4_jbd2.c:81
ext4_sample_last_mounted fs/ext4/file.c:414 [inline]
ext4_file_open+0x552/0x7b0 fs/ext4/file.c:439
do_dentry_open+0x499/0x1250 fs/open.c:771
vfs_open+0xa0/0xd0 fs/open.c:880
do_last fs/namei.c:3418 [inline]
path_openat+0x130f/0x5340 fs/namei.c:3534
do_filp_open+0x255/0x380 fs/namei.c:3564
do_open_execat+0x221/0x8e0 fs/exec.c:853
__do_execve_file.isra.35+0x1707/0x2460 fs/exec.c:1755
do_execveat_common fs/exec.c:1866 [inline]
do_execve fs/exec.c:1883 [inline]
__do_sys_execve fs/exec.c:1964 [inline]
__se_sys_execve fs/exec.c:1959 [inline]
__x64_sys_execve+0x8f/0xc0 fs/exec.c:1959
do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
entry_SYSCALL_64_after_hwframe+0x49/0xbe
-> #0 (sb_internal){.+.+}:
lock_acquire+0x1e4/0x4f0 kernel/locking/lockdep.c:3901
percpu_down_read_preempt_disable include/linux/percpu-rwsem.h:36
[inline]
percpu_down_read include/linux/percpu-rwsem.h:59 [inline]
__sb_start_write+0x1e9/0x300 fs/super.c:1387
sb_start_intwrite include/linux/fs.h:1613 [inline]
ext4_evict_inode+0x588/0x19b0 fs/ext4/inode.c:250
evict+0x4ae/0x990 fs/inode.c:558
iput_final fs/inode.c:1547 [inline]
[PATCH] arm64: dts: rockchip: add i2s and spdif endpoint of rk3328
This patch adds port and endpoint of i2s and spdif nodes for rk3328.
Because to use modern sound card interface such as audio-graph-card.
Signed-off-by: Katsuhiro Suzuki
---
arch/arm64/boot/dts/rockchip/rk3328.dtsi | 24
1 file changed, 24 insertions(+)
diff --git a/arch/arm64/boot/dts/rockchip/rk3328.dtsi
b/arch/arm64/boot/dts/rockchip/rk3328.dtsi
index d3ef6566325e..41f0a20b73ed 100644
--- a/arch/arm64/boot/dts/rockchip/rk3328.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3328.dtsi
@@ -179,7 +179,13 @@
clock-names = "i2s_clk", "i2s_hclk";
dmas = < 11>, < 12>;
dma-names = "tx", "rx";
+ #sound-dai-cells = <0>;
status = "disabled";
+
+ i2s0_p0: port@0 {
+ i2s0_p0_0: endpoint {
+ };
+ };
};
i2s1: i2s@ff01 {
@@ -190,7 +196,13 @@
clock-names = "i2s_clk", "i2s_hclk";
dmas = < 14>, < 15>;
dma-names = "tx", "rx";
+ #sound-dai-cells = <0>;
status = "disabled";
+
+ i2s1_p0: port@0 {
+ i2s1_p0_0: endpoint {
+ };
+ };
};
i2s2: i2s@ff02 {
@@ -201,7 +213,13 @@
clock-names = "i2s_clk", "i2s_hclk";
dmas = < 0>, < 1>;
dma-names = "tx", "rx";
+ #sound-dai-cells = <0>;
status = "disabled";
+
+ i2s2_p0: port@0 {
+ i2s2_p0_0: endpoint {
+ };
+ };
};
spdif: spdif@ff03 {
@@ -214,7 +232,13 @@
dma-names = "tx";
pinctrl-names = "default";
pinctrl-0 = <_tx>;
+ #sound-dai-cells = <0>;
status = "disabled";
+
+ spdif_p0: port@0 {
+ spdif_p0_0: endpoint {
+ };
+ };
};
pdm: pdm@ff04 {
--
2.18.0
Re: [PATCH v2 0/6] x86/alternatives: text_poke() fixes
at 3:16 AM, Peter Zijlstra wrote:
> On Thu, Sep 06, 2018 at 10:13:00AM +0200, Peter Zijlstra wrote:
>> No, you got it the first time. There are in fact more fixmap abusers;
>> see drivers/acpi/apei/ghes.c. Also, as long as set_fixmap() allows
>> overwriting a _PAGE_PRESENT pte and has that dodgy
>> __flush_tlb_one_kernel() in it, the broken remains (and can return).
>>
>> So we need to fix fixmap, to either disallow overwriting a _PAGE_PRESENT
>> pte, or to issue a full TLB invalidate.
>>
>> Either fix will terminally break GHES, but that's OK, they've known
>> about this issue since 2015 and haven't cared, so I can't be bothered
>> about them.
>
> In fact, the below seems to cure all woes..
>
> diff --git a/arch/x86/kernel/alternative.c b/arch/x86/kernel/alternative.c
> index b9d5e7c9ef43..00f1c9e4f0a3 100644
> --- a/arch/x86/kernel/alternative.c
> +++ b/arch/x86/kernel/alternative.c
> @@ -709,22 +709,25 @@ void *text_poke(void *addr, const void *opcode, size_t
> len)
> pages[1] = virt_to_page(addr + PAGE_SIZE);
> }
> BUG_ON(!pages[0]);
> - local_irq_save(flags);
> +
> set_fixmap(FIX_TEXT_POKE0, page_to_phys(pages[0]));
> if (pages[1])
> set_fixmap(FIX_TEXT_POKE1, page_to_phys(pages[1]));
> +
> + local_irq_save(flags);
> vaddr = (char *)fix_to_virt(FIX_TEXT_POKE0);
> memcpy([(unsigned long)addr & ~PAGE_MASK], opcode, len);
> - clear_fixmap(FIX_TEXT_POKE0);
> - if (pages[1])
> - clear_fixmap(FIX_TEXT_POKE1);
> - local_flush_tlb();
> sync_core();
> /* Could also do a CLFLUSH here to speed up CPU recovery; but
> that causes hangs on some VIA CPUs. */
> for (i = 0; i < len; i++)
> BUG_ON(((char *)addr)[i] != ((char *)opcode)[i]);
> local_irq_restore(flags);
> +
> + clear_fixmap(FIX_TEXT_POKE0);
> + if (pages[1])
> + clear_fixmap(FIX_TEXT_POKE1);
> +
> return addr;
> }
>
> diff --git a/arch/x86/mm/init_64.c b/arch/x86/mm/init_64.c
> index dd519f372169..fd6af66bc400 100644
> --- a/arch/x86/mm/init_64.c
> +++ b/arch/x86/mm/init_64.c
> @@ -260,14 +260,28 @@ static void __set_pte_vaddr(pud_t *pud, unsigned long
> vaddr, pte_t new_pte)
> {
> pmd_t *pmd = fill_pmd(pud, vaddr);
> pte_t *pte = fill_pte(pmd, vaddr);
> + pte_t old_pte = *pte;
>
> set_pte(pte, new_pte);
>
> /*
> - * It's enough to flush this one mapping.
> - * (PGE mappings get flushed as well)
> + * If it was present and changes, we need to invalidate TLBs.
>*/
> - __flush_tlb_one_kernel(vaddr);
> + if (!(pte_present(old_pte) && !pte_same(old_pte, new_pte)))
> + return;
> +
> + if (WARN(irqs_disabled(), "broken set_fixmap(%d, %lx), was: %lx",
> + (int)__virt_to_fix(vaddr),
> + pte_val(new_pte), pte_val(old_pte))) {
> + /*
> + * It is _NOT_ enough to flush just the local mapping;
> + * it might mostly work, but there is no guarantee a remote
> + * CPU didn't load this entry into its TLB.
> + */
> + __flush_tlb_one_kernel(vaddr);
> + } else {
> + flush_tlb_kernel_range(vaddr, vaddr + PAGE_SIZE);
> + }
> }
>
> void set_pte_vaddr_p4d(p4d_t *p4d_page, unsigned long vaddr, pte_t new_pte)
> diff --git a/drivers/acpi/apei/Kconfig b/drivers/acpi/apei/Kconfig
> index 52ae5438edeb..e3c415bdbfbf 100644
> --- a/drivers/acpi/apei/Kconfig
> +++ b/drivers/acpi/apei/Kconfig
> @@ -19,6 +19,7 @@ config ACPI_APEI
>
> config ACPI_APEI_GHES
> bool "APEI Generic Hardware Error Source"
> + depends on BROKEN if X86
> depends on ACPI_APEI
> select ACPI_HED
> select IRQ_WORK
Indeed, I missed these other instances that use the fixmap.
I’ll give your patch a try once my server goes back online. I was (and still
am) worried that interrupts would be disabled when __set_pte_vaddr() is
called, which would make the fix more complicated.
In addition, there might be a couple of issues with your fix:
1. __set_pte_vaddr() is not used exclusive by set_fixmap(). This means
the warning might be wrong, but also means that these code patches (Xen’s
set_pte_mfn(), CPU-entry-area setup) needs to be checked. And as you said
before, someone might use this function for other purposes as well.
2. Printing the virtual address can break KASLR.
3. The WARN() can introduce some overhead since checking if IRQs are
disabled takes considerably long time. Perhaps VM_WARN() or something is
better. I realize this code-path is not on the hot-path though...
4. I guess flush_tlb_kernel_range() should also have something like
VM_WARN_ON(irqs_disabled()), just as an additional general sanity check.
Let me know if you want me to make these changes and include your patch in
the set.
Regards,
Nadav
Re: [PATCH v2 1/2] mm: Move page struct poisoning to CONFIG_DEBUG_VM_PAGE_INIT_POISON
On Thu 06-09-18 09:09:46, Dave Hansen wrote: [...] > Has anyone ever seen a single in-the-wild report from this mechanism? Yes. See the list from Pavel. And I wouldn't push for it otherwise. There are some questionable asserts with an overhead which is not directly visible but it just adds up. This is different that it is one time boot rare thing. Anyway, I guess I have put all my arguments on the table. I will leave the decision to you guys. If there is a strong concensus about a config option, then I can live with that and will enable it. -- Michal Hocko SUSE Labs
Re: [PATCH v2] firmware: arm_scmi: fix divide by zero when sustained_perf_level is zero
On 06/09/18 17:59, Olof Johansson wrote:
> Hi,
>
> On Thu, Sep 06, 2018 at 04:10:39PM +0100, Sudeep Holla wrote:
>> Firmware can provide zero as values for sustained performance level and
>> corresponding sustained frequency in kHz in order to hide the actual
>> frequencies and provide only abstract values. It may endup with divide
>> by zero scenario resulting in kernel panic.
>>
>> Let's set the multiplication factor to one if either one or both of them
>> (sustained_perf_level and sustained_freq) are set to zero.
>>
>> Fixes: a9e3fbfaa0ff ("firmware: arm_scmi: add initial support for
>> performance protocol")
>> Reported-by: Ionela Voinescu
>> Signed-off-by: Sudeep Holla
>> ---
>> drivers/firmware/arm_scmi/perf.c | 8 +++-
>> 1 file changed, 7 insertions(+), 1 deletion(-)
>>
>> Hi ARM SoC team,
>>
>> Can you pick this patch directly ?
>
> Applied, however:
>
Thanks.
>> diff --git a/drivers/firmware/arm_scmi/perf.c
>> b/drivers/firmware/arm_scmi/perf.c
>> index 721e6c57beae..64342944d917 100644
>> --- a/drivers/firmware/arm_scmi/perf.c
>> +++ b/drivers/firmware/arm_scmi/perf.c
>> @@ -166,7 +166,13 @@ scmi_perf_domain_attributes_get(const struct
>> scmi_handle *handle, u32 domain,
>> le32_to_cpu(attr->sustained_freq_khz);
>> dom_info->sustained_perf_level =
>> le32_to_cpu(attr->sustained_perf_level);
>> -dom_info->mult_factor = (dom_info->sustained_freq_khz * 1000) /
>> +if (!dom_info->sustained_freq_khz ||
>> +!dom_info->sustained_perf_level)
>> +/* CPUFreq converts to kHz, hence default 1000 */
>> +dom_info->mult_factor = 1000;
>> +else
>> +dom_info->mult_factor =
>> +(dom_info->sustained_freq_khz * 1000) /
>> dom_info->sustained_perf_level;
>> memcpy(dom_info->name, attr->name, SCMI_MAX_STR_SIZE);
>
> I noticed you do memcpy of these name strings in a few places, and use
> it as a string. Any firmware that would return a non-terminated string
> would cause problems later on. strlcpy() might be a better approach.
>
I seem to have assumed firmware always conforms to the definition: "Null
terminated ASCII string of up to 16 bytes in length" when I initially
wrote this.
Thanks for the finding this and the suggestion, it's always safer to
protect against firmware bugs. I will find all the occurrences and fix them.
--
Regards,
Sudeep
[PATCH] apparmor: Fix network performance issue in aa_label_sk_perm
The netperf benchmark shows a 5.73% reduction in throughput for
small (64 byte) transfers by unconfined tasks.
DEFINE_AUDIT_SK() in aa_label_sk_perm() should not be performed
unconditionally, rather only when the label is confined.
netperf-tcp
56974a6fc^ 56974a6fc
Min 64 563.48 ( 0.00%) 531.17 ( -5.73%)
Min 128 1056.92 ( 0.00%) 999.44 ( -5.44%)
Min 256 1945.95 ( 0.00%) 1867.97 ( -4.01%)
Min 1024 6761.40 ( 0.00%) 6364.23 ( -5.87%)
Min 2048 0.53 ( 0.00%)10606.20 ( -4.54%)
Min 3312 13692.67 ( 0.00%)13158.41 ( -3.90%)
Min 4096 14926.29 ( 0.00%)14457.46 ( -3.14%)
Min 8192 18399.34 ( 0.00%)18091.65 ( -1.67%)
Min 1638421384.13 ( 0.00%)21158.05 ( -1.06%)
Hmean 64 564.96 ( 0.00%) 534.38 ( -5.41%)
Hmean 128 1064.42 ( 0.00%) 1010.12 ( -5.10%)
Hmean 256 1965.85 ( 0.00%) 1879.16 ( -4.41%)
Hmean 1024 6839.77 ( 0.00%) 6478.70 ( -5.28%)
Hmean 2048 11154.80 ( 0.00%)10671.13 ( -4.34%)
Hmean 3312 13838.12 ( 0.00%)13249.01 ( -4.26%)
Hmean 4096 15009.99 ( 0.00%)14561.36 ( -2.99%)
Hmean 8192 18975.57 ( 0.00%)18326.54 ( -3.42%)
Hmean 1638421440.44 ( 0.00%)21324.59 ( -0.54%)
Stddev64 1.24 ( 0.00%)2.85 (-130.64%)
Stddev128 4.51 ( 0.00%)6.53 ( -44.84%)
Stddev256 11.67 ( 0.00%)8.50 ( 27.16%)
Stddev102448.33 ( 0.00%) 75.07 ( -55.34%)
Stddev204854.82 ( 0.00%) 65.16 ( -18.86%)
Stddev3312 153.57 ( 0.00%) 56.29 ( 63.35%)
Stddev4096 100.25 ( 0.00%) 88.50 ( 11.72%)
Stddev8192 358.13 ( 0.00%) 169.99 ( 52.54%)
Stddev16384 43.99 ( 0.00%) 141.82 (-222.39%)
Signed-off-by: Tony Jones
Fixes: 56974a6fcfef ("apparmor: add base infastructure for socket
mediation")
---
security/apparmor/net.c | 15 +--
1 file changed, 9 insertions(+), 6 deletions(-)
diff --git a/security/apparmor/net.c b/security/apparmor/net.c
index bb24cfa0a164..d5d72dd1ca1f 100644
--- a/security/apparmor/net.c
+++ b/security/apparmor/net.c
@@ -146,17 +146,20 @@ int aa_af_perm(struct aa_label *label, const char *op,
u32 request, u16 family,
static int aa_label_sk_perm(struct aa_label *label, const char *op, u32
request,
struct sock *sk)
{
- struct aa_profile *profile;
- DEFINE_AUDIT_SK(sa, op, sk);
+ int error = 0;
AA_BUG(!label);
AA_BUG(!sk);
- if (unconfined(label))
- return 0;
+ if (!unconfined(label)) {
+ struct aa_profile *profile;
+ DEFINE_AUDIT_SK(sa, op, sk);
- return fn_for_each_confined(label, profile,
- aa_profile_af_sk_perm(profile, , request, sk));
+ error = fn_for_each_confined(label, profile,
+ aa_profile_af_sk_perm(profile, , request, sk));
+ }
+
+ return error;
}
int aa_sk_perm(const char *op, u32 request, struct sock *sk)
--
2.18.0
Re: [PATCH v2 0/5] watchdog: hpwdt: Bug Fixes/Enhancement
On Wed, Aug 08, 2018 at 01:13:22PM -0600, Jerry Hoemann wrote: > Changes for v2 > > 1) Patch 0001: Simplify initialization of pretimeout removing #ifdef. > 2) Patch 0002: Loosen check on mynmi to accommodate potential FW issue. > 3) Patch 0003: Split dev_info into mulitple calls as output was getting long. > 4) Patch 0004: New: Add alias to module parameter soft_margin. > Wim, I would like to get our Distro partners to back port these changes, but they must first be upstream. :) Do you know when you will include these in a pull request so that I can pass on to them when to schedule the work? Thanks The patch e-mails are at: https://lkml.org/lkml/2018/8/8/769 Jerry > > - > > Two defect fixes and one enhancement. > > 0001: Initialize pretimeout from module parameter. > > Bug Fix. > > Pretimeout was getting programmed correctly in the hardware, > but this issue caused it to not be displayed correctly > in sysfs. > > > > 0002: Claim NMI from iLO > > Bug Fix. > > Default configuration worked, but if user were to disable the > pretimeout for the watchdog, then an explicit request to NMI > the system from the iLO virutal button would fail. > > > 0003: Display module parameters > > Enhancement. > > Display all the module parameters when loading the driver. > Makes it easier to diagnose problems. > > > Jerry > > > Jerry Hoemann (5): > watchdog: hpwdt: Initialize pretimeout from module parameter. > watchdog: hpwdt: Claim NMI from iLO > watchdog: hpwdt: Display module parameters. > watchdog: hpwdt: Module paramerter alias. > watchdog: hpwdt: Update version number. > > drivers/watchdog/hpwdt.c | 20 +--- > 1 file changed, 13 insertions(+), 7 deletions(-) > > -- > 1.8.3.1 -- - Jerry Hoemann Software Engineer Hewlett Packard Enterprise -
Re: [PATCH v7 0/2]: perf: reduce data loss when profiling highly parallel CPU bound workloads
Hi, On 05.09.2018 21:51, Arnaldo Carvalho de Melo wrote: > Em Wed, Sep 05, 2018 at 08:37:32PM +0300, Alexey Budankov escreveu: >> On 05.09.2018 14:28, Jiri Olsa wrote: >>> can't apply this version on Arnaldo's perf/core... > >> my git remote -v > >> origin git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip (fetch) >> origin git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip (push) > >> branch is perf/core, according to MAINTAINERS content. > >> What is Arnaldo's perf/core? This one? > >> git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux > >> and branch is perf/core? > > yes. Is this the actual one for the tool development? Am I missing something? Thanks, Alexey > > - Arnaldo >
Re: [PATCH 08/11] UAPI: sound: Fix use of u32 and co. in UAPI headers
Hi, On Sep 6 2018 00:55, David Howells wrote: Fix the use of u32 and co. in UAPI headers as these are not defined. Switch to using the __u32-style equivalents instead. Signed-off-by: David Howells cc: Jaroslav Kysela cc: Takashi Iwai cc: alsa-de...@alsa-project.org (moderated for non-subscribers) --- include/uapi/sound/skl-tplg-interface.h | 106 --- 1 file changed, 54 insertions(+), 52 deletions(-) A similar patch was already proposed[1] and has been applied by Mark to his tree[2]. Your issue (3) is going to be solved soon for v4.19 kernel. [1] [alsa-devel] [PATCH] uapi: fix sound/skl-tplg-interface.h userspace compilation errors http://mailman.alsa-project.org/pipermail/alsa-devel/2018-August/139392.html [2] ASoC: uapi: fix sound/skl-tplg-interface.h userspace compilation errors https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git/log/?h=for-4.19 Thanks Takashi Sakamoto
[PATCH] scsi: zfcp: remove redundant put_device
device_unregister will put device, do not need to do it one more time Signed-off-by: Ding Xiang --- drivers/s390/scsi/zfcp_unit.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/s390/scsi/zfcp_unit.c b/drivers/s390/scsi/zfcp_unit.c index 1bf0a09..6b50084 100644 --- a/drivers/s390/scsi/zfcp_unit.c +++ b/drivers/s390/scsi/zfcp_unit.c @@ -249,8 +249,6 @@ int zfcp_unit_remove(struct zfcp_port *port, u64 fcp_lun) scsi_device_put(sdev); } - put_device(>dev); - device_unregister(>dev); return 0; -- 1.9.1
Re: [PATCH] mm,page_alloc: PF_WQ_WORKER threads must sleep at should_reclaim_retry().
Michal Hocko wrote: > > I assert that we should fix af5679fbc669f31f. > > If you can come up with reasonable patch which doesn't complicate the > code and it is a clear win for both this particular workload as well as > others then why not. Why can't we do "at least MMF_OOM_SKIP should be set under the lock to prevent from races" ? diff --git a/mm/mmap.c b/mm/mmap.c index 5f2b2b1..e096bb8 100644 --- a/mm/mmap.c +++ b/mm/mmap.c @@ -3065,7 +3065,9 @@ void exit_mmap(struct mm_struct *mm) */ (void)__oom_reap_task_mm(mm); + mutex_lock(_lock); set_bit(MMF_OOM_SKIP, >flags); + mutex_unlock(_lock); down_write(>mmap_sem); up_write(>mmap_sem); } diff --git a/mm/oom_kill.c b/mm/oom_kill.c index f10aa53..b2a94c1 100644 --- a/mm/oom_kill.c +++ b/mm/oom_kill.c @@ -606,7 +606,9 @@ static void oom_reap_task(struct task_struct *tsk) * Hide this mm from OOM killer because it has been either reaped or * somebody can't call up_write(mmap_sem). */ + mutex_lock(_lock); set_bit(MMF_OOM_SKIP, >flags); + mutex_unlock(_lock); /* Drop a reference taken by wake_oom_reaper */ put_task_struct(tsk);
[PATCH RESEND] zlib: remove fall through warnings
This patch remove all following fall through warnings by
adding /* fall through */ markers.
Note that we cannot add "__attribute__ ((fallthrough));" due to it is GCC7 only
arch/arm/boot/compressed/../../../../lib/zlib_inflate/inflate.c:384:25:
warning: this statement may fall through [-Wimplicit-fallthrough=]
arch/arm/boot/compressed/../../../../lib/zlib_inflate/inflate.c:391:25:
warning: this statement may fall through [-Wimplicit-fallthrough=]
arch/arm/boot/compressed/../../../../lib/zlib_inflate/inflate.c:393:16:
warning: this statement may fall through [-Wimplicit-fallthrough=]
arch/arm/boot/compressed/../../../../lib/zlib_inflate/inflate.c:430:25:
warning: this statement may fall through [-Wimplicit-fallthrough=]
arch/arm/boot/compressed/../../../../lib/zlib_inflate/inflate.c:556:25:
warning: this statement may fall through [-Wimplicit-fallthrough=]
arch/arm/boot/compressed/../../../../lib/zlib_inflate/inflate.c:595:25:
warning: this statement may fall through [-Wimplicit-fallthrough=]
arch/arm/boot/compressed/../../../../lib/zlib_inflate/inflate.c:602:25:
warning: this statement may fall through [-Wimplicit-fallthrough=]
arch/arm/boot/compressed/../../../../lib/zlib_inflate/inflate.c:627:25:
warning: this statement may fall through [-Wimplicit-fallthrough=]
arch/arm/boot/compressed/../../../../lib/zlib_inflate/inflate.c:646:25:
warning: this statement may fall through [-Wimplicit-fallthrough=]
arch/arm/boot/compressed/../../../../lib/zlib_inflate/inflate.c:696:25:
warning: this statement may fall through [-Wimplicit-fallthrough=]
It is easy to see that thoses fall through are needed since in each case
state->mode are set to the case value just below.
Signed-off-by: Corentin Labbe
---
lib/zlib_inflate/inflate.c | 12
1 file changed, 12 insertions(+)
diff --git a/lib/zlib_inflate/inflate.c b/lib/zlib_inflate/inflate.c
index 58a733b10387..48f14cd58c77 100644
--- a/lib/zlib_inflate/inflate.c
+++ b/lib/zlib_inflate/inflate.c
@@ -382,6 +382,7 @@ int zlib_inflate(z_streamp strm, int flush)
strm->adler = state->check = REVERSE(hold);
INITBITS();
state->mode = DICT;
+ /* fall through */
case DICT:
if (state->havedict == 0) {
RESTORE();
@@ -389,8 +390,10 @@ int zlib_inflate(z_streamp strm, int flush)
}
strm->adler = state->check = zlib_adler32(0L, NULL, 0);
state->mode = TYPE;
+ /* fall through */
case TYPE:
if (flush == Z_BLOCK) goto inf_leave;
+ /* fall through */
case TYPEDO:
if (state->last) {
BYTEBITS();
@@ -428,6 +431,7 @@ int zlib_inflate(z_streamp strm, int flush)
state->length = (unsigned)hold & 0x;
INITBITS();
state->mode = COPY;
+ /* fall through */
case COPY:
copy = state->length;
if (copy) {
@@ -461,6 +465,7 @@ int zlib_inflate(z_streamp strm, int flush)
#endif
state->have = 0;
state->mode = LENLENS;
+ /* fall through */
case LENLENS:
while (state->have < state->ncode) {
NEEDBITS(3);
@@ -481,6 +486,7 @@ int zlib_inflate(z_streamp strm, int flush)
}
state->have = 0;
state->mode = CODELENS;
+ /* fall through */
case CODELENS:
while (state->have < state->nlen + state->ndist) {
for (;;) {
@@ -554,6 +560,7 @@ int zlib_inflate(z_streamp strm, int flush)
break;
}
state->mode = LEN;
+ /* fall through */
case LEN:
if (have >= 6 && left >= 258) {
RESTORE();
@@ -593,6 +600,7 @@ int zlib_inflate(z_streamp strm, int flush)
}
state->extra = (unsigned)(this.op) & 15;
state->mode = LENEXT;
+ /* fall through */
case LENEXT:
if (state->extra) {
NEEDBITS(state->extra);
@@ -600,6 +608,7 @@ int zlib_inflate(z_streamp strm, int flush)
DROPBITS(state->extra);
}
state->mode = DIST;
+ /* fall through */
case DIST:
for (;;) {
this = state->distcode[BITS(state->distbits)];
@@ -625,6 +634,7 @@ int zlib_inflate(z_streamp strm, int flush)
state->offset = (unsigned)this.val;
state->extra = (unsigned)(this.op) & 15;
state->mode = DISTEXT;
+ /* fall through */
case DISTEXT:
if (state->extra) {
NEEDBITS(state->extra);
@@ -644,6 +654,7 @@ int zlib_inflate(z_streamp strm, int flush)
break;
}
state->mode = MATCH;
+ /* fall through */
case MATCH:
if (left == 0) goto inf_leave;
copy = out - left;
@@ -694,6 +705,7 @@
Re: [PATCH] scsi: zfcp: remove redundant put_device
On 9/6/2018 2:24 PM, Heiko Carstens wrote: On Thu, Sep 06, 2018 at 02:16:27PM +0800, Ding Xiang wrote: device_unregister will put device, do not need to do it one more time Signed-off-by: Ding Xiang --- drivers/s390/scsi/zfcp_unit.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/s390/scsi/zfcp_unit.c b/drivers/s390/scsi/zfcp_unit.c index 1bf0a09..6b50084 100644 --- a/drivers/s390/scsi/zfcp_unit.c +++ b/drivers/s390/scsi/zfcp_unit.c @@ -249,8 +249,6 @@ int zfcp_unit_remove(struct zfcp_port *port, u64 fcp_lun) scsi_device_put(sdev); } - put_device(>dev); - device_unregister(>dev); return 0; I'm quite sure this change is wrong, since the put_device() here seems to pair with the get_device() in _zfcp_unit_find(). So we would end up with a memory leak. Indeed，please ignore this patch. Adding Steffen and Benjamin.
Re: [PATCH v6 04/14] PM / EM: Expose the Energy Model in sysfs
On 08/20/2018 02:44 AM, Quentin Perret wrote: Expose the Energy Model (read-only) of all performance domains in sysfs for convenience. To do so, add a kobject to the CPU subsystem under the umbrella of which a kobject for each performance domain is attached. The resulting hierarchy is as follows for a platform with two performance domains for example: /sys/devices/system/cpu/energy_model ├── pd0 │ ├── cost │ ├── cpus │ ├── frequency │ └── power cpus (cpumask of the perf domain), frequency (OPP's of the perf domain) and power (values at those OPP's) are somehow easy to grasp, cost is definitely not. You have this nice description in em_pd_energy() what cost actually is. IMHO, might be worth repeating this at least in the patch header here. [...]
Re: [PATCH] mm,page_alloc: PF_WQ_WORKER threads must sleep at should_reclaim_retry().
Tetsuo Handa wrote: > Michal Hocko wrote: > > > I assert that we should fix af5679fbc669f31f. > > > > If you can come up with reasonable patch which doesn't complicate the > > code and it is a clear win for both this particular workload as well as > > others then why not. > > Why can't we do "at least MMF_OOM_SKIP should be set under the lock to > prevent from races" ? > Well, serializing setting of MMF_OOM_SKIP using oom_lock was not sufficient. It seems that some more moment is needed for allowing last second allocation attempt at __alloc_pages_may_oom() to succeed. We need to migrate to "mm, oom: fix unnecessary killing of additional processes" thread. [ 702.895936] a.out invoked oom-killer: gfp_mask=0x6280ca(GFP_HIGHUSER_MOVABLE|__GFP_ZERO), nodemask=(null), order=0, oom_score_adj=0 [ 702.900717] a.out cpuset=/ mems_allowed=0 [ 702.903210] CPU: 1 PID: 3359 Comm: a.out Tainted: GT 4.19.0-rc2+ #692 [ 702.906630] Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 05/19/2017 [ 702.910771] Call Trace: [ 702.912681] dump_stack+0x85/0xcb [ 702.914918] dump_header+0x69/0x2fe [ 702.917387] ? _raw_spin_unlock_irqrestore+0x41/0x70 [ 702.921267] oom_kill_process+0x307/0x390 [ 702.923809] out_of_memory+0x2f3/0x5d0 [ 702.926208] __alloc_pages_slowpath+0xc01/0x1030 [ 702.928817] __alloc_pages_nodemask+0x333/0x390 [ 702.931270] alloc_pages_vma+0x77/0x1f0 [ 702.933618] __handle_mm_fault+0x81c/0xf40 [ 702.935962] handle_mm_fault+0x1b7/0x3c0 [ 702.938215] __do_page_fault+0x2a6/0x580 [ 702.940481] do_page_fault+0x32/0x270 [ 702.942753] ? page_fault+0x8/0x30 [ 702.944860] page_fault+0x1e/0x30 [ 702.947138] RIP: 0033:0x4008d8 [ 702.949722] Code: Bad RIP value. [ 702.952000] RSP: 002b:7ffc21fd99c0 EFLAGS: 00010206 [ 702.954570] RAX: 7fb3457cc010 RBX: 0001 RCX: [ 702.957631] RDX: b0b24000 RSI: 0002 RDI: 00020050 [ 702.960599] RBP: 7fb3457cc010 R08: 00021000 R09: 00021000 [ 702.963531] R10: 0022 R11: 1000 R12: 0006 [ 702.966518] R13: 7ffc21fd9ab0 R14: R15: [ 702.971186] Mem-Info: [ 702.976959] active_anon:788641 inactive_anon:3457 isolated_anon:0 [ 702.976959] active_file:0 inactive_file:77 isolated_file:0 [ 702.976959] unevictable:0 dirty:0 writeback:0 unstable:0 [ 702.976959] slab_reclaimable:8152 slab_unreclaimable:24616 [ 702.976959] mapped:2806 shmem:3704 pagetables:4355 bounce:0 [ 702.976959] free:20831 free_pcp:136 free_cma:0 [ 703.007374] Node 0 active_anon:3154564kB inactive_anon:13828kB active_file:304kB inactive_file:112kB unevictable:0kB isolated(anon):0kB isolated(file):0kB mapped:11028kB dirty:0kB writeback:0kB shmem:14816kB shmem_thp: 0kB shmem_pmdmapped: 0kB anon_thp: 2846720kB writeback_tmp:0kB unstable:0kB all_unreclaimable? no [ 703.029994] Node 0 DMA free:13816kB min:308kB low:384kB high:460kB active_anon:1976kB inactive_anon:0kB active_file:0kB inactive_file:0kB unevictable:0kB writepending:0kB present:15960kB managed:15876kB mlocked:0kB kernel_stack:0kB pagetables:4kB bounce:0kB free_pcp:0kB local_pcp:0kB free_cma:0kB [ 703.055331] lowmem_reserve[]: 0 2717 3378 3378 [ 703.062881] Node 0 DMA32 free:58152kB min:54108kB low:67632kB high:81156kB active_anon:2718364kB inactive_anon:12kB active_file:424kB inactive_file:852kB unevictable:0kB writepending:0kB present:3129152kB managed:2782296kB mlocked:0kB kernel_stack:352kB pagetables:388kB bounce:0kB free_pcp:728kB local_pcp:0kB free_cma:0kB [ 703.091529] lowmem_reserve[]: 0 0 661 661 [ 703.096552] Node 0 Normal free:12900kB min:13164kB low:16452kB high:19740kB active_anon:434248kB inactive_anon:13816kB active_file:0kB inactive_file:48kB unevictable:0kB writepending:0kB present:1048576kB managed:676908kB mlocked:0kB kernel_stack:6720kB pagetables:17028kB bounce:0kB free_pcp:0kB local_pcp:0kB free_cma:0kB [ 703.123046] lowmem_reserve[]: 0 0 0 0 [ 703.127490] Node 0 DMA: 0*4kB 1*8kB (M) 1*16kB (U) 3*32kB (U) 4*64kB (UM) 1*128kB (U) 0*256kB 0*512kB 1*1024kB (U) 0*2048kB 3*4096kB (M) = 13816kB [ 703.134763] Node 0 DMA32: 85*4kB (UM) 59*8kB (UM) 61*16kB (UM) 65*32kB (UME) 47*64kB (UE) 44*128kB (UME) 41*256kB (UME) 27*512kB (UME) 20*1024kB (ME) 0*2048kB 0*4096kB = 57308kB [ 703.144076] Node 0 Normal: 119*4kB (UM) 69*8kB (UM) 156*16kB (UME) 179*32kB (UME) 44*64kB (UE) 9*128kB (UE) 1*256kB (E) 0*512kB 0*1024kB 0*2048kB 0*4096kB = 13476kB [ 703.151746] Node 0 hugepages_total=0 hugepages_free=0 hugepages_surp=0 hugepages_size=2048kB [ 703.156537] 3744 total pagecache pages [ 703.159017] 0 pages in swap cache [ 703.163209] Swap cache stats: add 0, delete 0, find 0/0 [ 703.167254] Free swap = 0kB [ 703.170577] Total swap = 0kB [ 703.173758] 1048422 pages RAM [ 703.176843] 0 pages HighMem/MovableOnly [ 703.180380] 179652 pages reserved [ 703.183718] 0
RE: [PATCH 4/7] dt-bindings: spi: add binding file for NXP FlexSPI driver
Hi Boris,
Currently FlexSPI controller is present in ARM SoC but NXP is coming with
PowerPC SoC with same FlexSPI controller.
We are trying to use same binding as defined in this patch-set(tested on ARM64
processors) for PowerPC.
Unfortunately, It is showing issue when driver tries to parse 'fspi_mmap'.
We did some investigation and figured out that for ARM device trees Peripherals
nodes inside 'soc' node have absolute addresses. For in general NXP's PowerPC
device trees, Peripheral nodes have the relative addresses to the unit-address
of the parent 'soc' node.
This creates issue for PowerPC if we follow implementation in this patch-set.
Example of device tree used for upcoming PowerPC SoC with FlexSPI controller.
soc@f800 {
ranges = <0x0 0x0 0xf800 0x400>;
.
fspi0: flexspi@20c {
compatible = "nxp,XXX-fspi";
reg = <0x20c 0x1>, <0xC000 0x1000>;
reg-names = "fspi_base", "fspi_mmap";
.
.
}
}
As we can see, Final address of 'fspi_base' (0xf800 + 0x20c) falls into
the parent 'soc' range(CCSR) but
for 'fspi_mmap', It is outside of 'soc' range(CCSR). It creates issue when
driver tries to parse 'fspi_mmap'.
As per definition of ranges, this field can't be used to solve this problem.
Please suggest how to implement the "fspi_mmap"(memory mapping address and
length) in case of PowerPC.
Thanks,
Jagdish
> -Original Message-
> From: linux-kernel-ow...@vger.kernel.org ow...@vger.kernel.org> On Behalf Of Boris Brezillon
> Sent: Tuesday, September 4, 2018 6:16 PM
> To: Prabhakar Kushwaha
> Cc: Yogesh Narayan Gaur ; linux-
> m...@lists.infradead.org; marek.va...@gmail.com; linux-
> s...@vger.kernel.org; devicet...@vger.kernel.org; r...@kernel.org;
> mark.rutl...@arm.com; shawn...@kernel.org; linux-arm-
> ker...@lists.infradead.org; computersforpe...@gmail.com;
> frieder.schre...@exceet.de; linux-kernel@vger.kernel.org
> Subject: Re: [PATCH 4/7] dt-bindings: spi: add binding file for NXP FlexSPI
> driver
>
> On Mon, 3 Sep 2018 09:54:08 +
> Prabhakar Kushwaha wrote:
>
> > Dear Yogesh,
> >
> > > -Original Message-
> > > From: linux-kernel-ow...@vger.kernel.org > > ow...@vger.kernel.org> On Behalf Of Yogesh Gaur
> > > Sent: Friday, August 31, 2018 4:00 PM
> > > To: linux-...@lists.infradead.org; boris.brezil...@bootlin.com;
> > > marek.va...@gmail.com; linux-...@vger.kernel.org;
> > > devicet...@vger.kernel.org
> > > Cc: r...@kernel.org; mark.rutl...@arm.com; shawn...@kernel.org;
> > > linux- arm-ker...@lists.infradead.org; computersforpe...@gmail.com;
> > > frieder.schre...@exceet.de; linux-kernel@vger.kernel.org; Yogesh
> > > Narayan Gaur
> > > Subject: [PATCH 4/7] dt-bindings: spi: add binding file for NXP
> > > FlexSPI driver
> > >
> > > Add binding file for NXP FlexSPI driver.
> > >
> > > Signed-off-by: Yogesh Gaur
> > > ---
> > > .../devicetree/bindings/spi/spi-nxp-fspi.txt | 42
> > > ++
> > > 1 file changed, 42 insertions(+)
> > > create mode 100644 Documentation/devicetree/bindings/spi/spi-nxp-
> > > fspi.txt
> > >
> > > diff --git a/Documentation/devicetree/bindings/spi/spi-nxp-fspi.txt
> > > b/Documentation/devicetree/bindings/spi/spi-nxp-fspi.txt
> > > new file mode 100644
> > > index 000..9f07116
> > > --- /dev/null
> > > +++ b/Documentation/devicetree/bindings/spi/spi-nxp-fspi.txt
> > > @@ -0,0 +1,42 @@
> > > +* NXP Flex Serial Peripheral Interface (FSPI)
> > > +
> > > +Required properties:
> > > + - compatible : Should be "nxp,lx2160a-fspi"
> > > + - reg :First contains the register location and length,
> > > + Second contains the memory mapping address and
> > > +length
> >
> > Why are we overriding reg property. Is there any special requirement.
> >
> > Can we use "reg" and "ranges" property in device tree.
> > Here "reg" represents controller registers and "ranges" represent the
> memory address of flash.
>
> No, ranges is not used for that. It's used when you need to convert from one
> address space to another, which is not what you're describing here. Check
> section 2.38 of this document [1] for more details.
>
> [1]https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fe
> linux.org%2Fimages%2Fc%2Fcf%2FPower_ePAPR_APPROVED_v1.1.pdf
> data=02%7C01%7Cjagdish.gediya%40nxp.com%7C5bdb57713bd4403a39e90
> 8d6126472a0%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C63671
> 6619958727753sdata=TB4mbWEm0opk58oPAVEOQFM0xeAFxCsqdzw
> 37BPuE3A%3Dreserved=0
Re: [PATCH] i2c: xiic: Make the start and the byte count write atomic
Hi, On Tue, Sep 4, 2018 at 9:41 PM Wolfram Sang wrote: > > On Mon, Sep 03, 2018 at 03:11:11PM +0530, shubhrajyoti.da...@gmail.com wrote: > > From: Shubhrajyoti Datta > > > > Disable interrupts while configuring the transfer and enable them back. > > > > We have below as the programming sequence > > 1. start and slave address > > 2. byte count and stop > > > > In some customer platform there was a lot of interrupts between 1 and 2 > > and after slave address (around 7 clock cyles) if 2 is not executed > > then the transaction is nacked. > > > > To fix this case make the 2 writes atomic. > > > > Signed-off-by: Shubhrajyoti Datta > > Signed-off-by: Michal Simek > > I assume simply changing the order of the register writes won't fix it? No that is not possible. > > I also assume this is stable material? > Yes let me know if you want me to resend with the stable tag?
Re: [PATCH v2] HID: i2c-hid: Don't reset device upon system resume
On Thu, Sep 6, 2018 at 4:55 AM Kai-Heng Feng
wrote:
>
> Raydium touchscreen triggers interrupt storm after system-wide suspend:
> [ 179.085033] i2c_hid i2c-CUST:00: i2c_hid_get_input: incomplete
> report (58/65535)
>
> According to Raydium, Windows driver does not reset the device after
> system resume.
>
> The HID over I2C spec does specify a reset should be used at
> intialization, but it doesn't specify if reset is required for system
> suspend.
>
> Tested this patch on other i2c-hid touchpanels I have and those
> touchpanels do work after S3 without doing reset. If any regression
> happens to other touchpanel vendors, we can use quirk for Raydium
> devices.
>
> There's still one device uses I2C_HID_QUIRK_RESEND_REPORT_DESCR so keep
> it there.
>
> Cc: Aaron Ma
> Cc: AceLan Kao
> Signed-off-by: Kai-Heng Feng
Reviewed-by: Benjamin Tissoires
Jiri, note that this will replace https://patchwork.kernel.org/patch/10583481/
Cheers,
Benjamin
> ---
> v2:
> Remove Raydium devices' ID and quirk.
> Rewording.
>
> drivers/hid/hid-ids.h | 4
> drivers/hid/i2c-hid/i2c-hid.c | 13 +++--
> 2 files changed, 7 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
> index 7da93d789080..e254ae802688 100644
> --- a/drivers/hid/hid-ids.h
> +++ b/drivers/hid/hid-ids.h
> @@ -530,10 +530,6 @@
> #define I2C_VENDOR_ID_HANTICK 0x0911
> #define I2C_PRODUCT_ID_HANTICK_52880x5288
>
> -#define I2C_VENDOR_ID_RAYD 0x2386
> -#define I2C_PRODUCT_ID_RAYD_3118 0x3118
> -#define I2C_PRODUCT_ID_RAYD_4B33 0x4B33
> -
> #define USB_VENDOR_ID_HANWANG 0x0b57
> #define USB_DEVICE_ID_HANWANG_TABLET_FIRST 0x5000
> #define USB_DEVICE_ID_HANWANG_TABLET_LAST 0x8fff
> diff --git a/drivers/hid/i2c-hid/i2c-hid.c b/drivers/hid/i2c-hid/i2c-hid.c
> index 57126f6837bb..f3076659361a 100644
> --- a/drivers/hid/i2c-hid/i2c-hid.c
> +++ b/drivers/hid/i2c-hid/i2c-hid.c
> @@ -170,12 +170,8 @@ static const struct i2c_hid_quirks {
> I2C_HID_QUIRK_SET_PWR_WAKEUP_DEV },
> { I2C_VENDOR_ID_HANTICK, I2C_PRODUCT_ID_HANTICK_5288,
> I2C_HID_QUIRK_NO_IRQ_AFTER_RESET },
> - { I2C_VENDOR_ID_RAYD, I2C_PRODUCT_ID_RAYD_3118,
> - I2C_HID_QUIRK_RESEND_REPORT_DESCR },
> { USB_VENDOR_ID_SIS_TOUCH, USB_DEVICE_ID_SIS10FB_TOUCH,
> I2C_HID_QUIRK_RESEND_REPORT_DESCR },
> - { I2C_VENDOR_ID_RAYD, I2C_PRODUCT_ID_RAYD_4B33,
> - I2C_HID_QUIRK_RESEND_REPORT_DESCR },
> { 0, 0 }
> };
>
> @@ -1237,11 +1233,16 @@ static int i2c_hid_resume(struct device *dev)
> pm_runtime_enable(dev);
>
> enable_irq(client->irq);
> - ret = i2c_hid_hwreset(client);
> +
> + /* Instead of resetting device, simply powers the device on. This
> +* solves "incomplete reports" on Raydium devices 2386:3118 and
> +* 2386:4B33
> +*/
> + ret = i2c_hid_set_power(client, I2C_HID_PWR_ON);
> if (ret)
> return ret;
>
> - /* RAYDIUM device (2386:3118) need to re-send report descr cmd
> + /* Some devices need to re-send report descr cmd
> * after resume, after this it will be back normal.
> * otherwise it issues too many incomplete reports.
> */
> --
> 2.17.1
>
Re: [PATCH v6 07/14] sched/topology: Introduce sched_energy_present static key
On 08/20/2018 02:44 AM, Quentin Perret wrote: In order to ensure a minimal performance impact on non-energy-aware systems, introduce a static_key guarding the access to Energy-Aware Scheduling (EAS) code. The static key is set iff all the following conditions are met for at least one root domain: 1. all online CPUs of the root domain are covered by the Energy Model (EM); 2. the complexity of the root domain's EM is low enough to keep scheduling overheads low; 3. the root domain has an asymmetric CPU capacity topology (detected by looking for the SD_ASYM_CPUCAPACITY flag in the sched_domain hierarchy). This is pretty much the list (+ is schedutil running) of conditions to set rd->pd != NULL in build_perf_domains(). So when testing 'static_branch_unlikely(_energy_present) && rcu_dereference(rd->pd)' don't you test two times the same thing? Also, if let's say somebody wants to run another EM user (e.g. a thermal governor, like IPA) but not EAS on a asymmetric CPU capacity system. This can't be achieved with the current static branch approach So what about using a (disabled by default ?) sched_feature + rd->pd != NULL instead? [...]
Re: [PATCH] scsi: zfcp: remove redundant put_device
On Thu, Sep 06, 2018 at 02:16:27PM +0800, Ding Xiang wrote: > device_unregister will put device, do not need to do it one more time > > Signed-off-by: Ding Xiang > --- > drivers/s390/scsi/zfcp_unit.c | 2 -- > 1 file changed, 2 deletions(-) > > diff --git a/drivers/s390/scsi/zfcp_unit.c b/drivers/s390/scsi/zfcp_unit.c > index 1bf0a09..6b50084 100644 > --- a/drivers/s390/scsi/zfcp_unit.c > +++ b/drivers/s390/scsi/zfcp_unit.c > @@ -249,8 +249,6 @@ int zfcp_unit_remove(struct zfcp_port *port, u64 fcp_lun) > scsi_device_put(sdev); > } > > - put_device(>dev); > - > device_unregister(>dev); > > return 0; I'm quite sure this change is wrong, since the put_device() here seems to pair with the get_device() in _zfcp_unit_find(). So we would end up with a memory leak. Adding Steffen and Benjamin.
Re: [PATCH] x86/mm/pat: Fix L1TF stable backport for CPA
On 08/25/2018, 03:50 PM, Andi Kleen wrote: > From: Andi Kleen > > Patch for stable only to fix boot resets caused by the L1TF patches. > > Stable trees reverted the following patch > > Revert "x86/mm/pat: Ensure cpa->pfn only contains page frame numbers" > > This reverts commit 87e2bd898d3a79a8c609f183180adac47879a2a4 which is > commit edc3b9129cecd0f0857112136f5b8b1bc1d45918 upstream. > > but the L1TF patch backported here > >x86/mm/pat: Make set_memory_np() L1TF safe > > commit 958f79b9ee55dfaf00c8106ed1c22a2919e0028b upstream > > set_memory_np() is used to mark kernel mappings not present, but it has > it's own open coded mechanism which does not have the L1TF protection of > inverting the address bits. > > assumed that cpa->pfn contains a PFN. With the above patch reverted > it does not, which causes the PMD to be set to an incorrect address > shifted by 12 bits, which can cause early boot reset on some > systems, like an Apollo Lake embedded system. > > Convert the address to a PFN before passing it to pmd_pfn() > > Thanks to Bernhard for bisecting and testing. > > Cc: sta...@vger.kernel.org # 4.4 and 4.9 > Reported-by: Bernhard Kaindl > Tested-by: Bernhard Kaindl > Signed-off-by: Andi Kleen > --- > arch/x86/mm/pageattr.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/arch/x86/mm/pageattr.c b/arch/x86/mm/pageattr.c > index 27610c2d1821..1007fa80f5a6 100644 > --- a/arch/x86/mm/pageattr.c > +++ b/arch/x86/mm/pageattr.c > @@ -1006,7 +1006,7 @@ static int populate_pmd(struct cpa_data *cpa, > > pmd = pmd_offset(pud, start); > > - set_pmd(pmd, pmd_mkhuge(pfn_pmd(cpa->pfn, > + set_pmd(pmd, pmd_mkhuge(pfn_pmd(cpa->pfn >> PAGE_SHIFT, > canon_pgprot(pmd_pgprot; And what about populate_pud? set_pud(pud, pud_mkhuge(pfn_pud(cpa->pfn, canon_pgprot(pud_pgprot; start += PUD_SIZE; cpa->pfn += PUD_SIZE; thanks, -- js suse labs
Re: [PATCH v7 0/2]: perf: reduce data loss when profiling highly parallel CPU bound workloads
Hi,
On 05.09.2018 14:28, Jiri Olsa wrote:
> On Wed, Sep 05, 2018 at 10:16:42AM +0300, Alexey Budankov wrote:
>>
>> Currently in record mode the tool implements trace writing serially.
>> The algorithm loops over mapped per-cpu data buffers and stores
>> ready data chunks into a trace file using write() system call.
>>
>> At some circumstances the kernel may lack free space in a buffer
>> because the other buffer's half is not yet written to disk due to
>> some other buffer's data writing by the tool at the moment.
>>
>> Thus serial trace writing implementation may cause the kernel
>> to loose profiling data and that is what observed when profiling
>> highly parallel CPU bound workloads on machines with big number
>> of cores.
>>
>> Experiment with profiling matrix multiplication code executing 128
>> threads on Intel Xeon Phi (KNM) with 272 cores, like below,
>> demonstrates data loss metrics value of 98%:
>>
>> /usr/bin/time perf record -o /tmp/perf-ser.data -a -N -B -T -R -g \
>> --call-graph dwarf,1024 --user-regs=IP,SP,BP \
>> --switch-events -e
>> cycles,instructions,ref-cycles,software/period=1,name=cs,config=0x3/Duk -- \
>> matrix.gcc
>>
>> Data loss metrics is the ratio lost_time/elapsed_time where
>> lost_time is the sum of time intervals containing PERF_RECORD_LOST
>> records and elapsed_time is the elapsed application run time
>> under profiling.
>>
>> Applying asynchronous trace streaming thru Posix AIO API
>> (http://man7.org/linux/man-pages/man7/aio.7.html)
>> lowers data loss metrics value providing 2x improvement -
>> lowering 98% loss to almost 0%.
>>
>> ---
>> Alexey Budankov (2):
>> perf util: map data buffer for preserving collected data
>> perf record: enable asynchronous trace writing
>>
>> tools/perf/builtin-record.c | 197
>> +++-
>> tools/perf/perf.h | 1 +
>> tools/perf/util/evlist.c| 7 +-
>> tools/perf/util/evlist.h| 3 +-
>> tools/perf/util/mmap.c | 110 +
>> tools/perf/util/mmap.h | 10 ++-
>> 6 files changed, 302 insertions(+), 26 deletions(-)
>>
>> ---
>> Changes in v7:
>> - implemented handling record.aio setting from perfconfig file
>
> can't apply this version on Arnaldo's perf/core...
>
> [jolsa@krava linux-perf]$ git am /tmp/ab/
> Applying: perf util: map data buffer for preserving collected data
> error: patch failed: tools/perf/util/mmap.c:166
> error: tools/perf/util/mmap.c: patch does not apply
Here it is:
tools/perf/builtin-record.c | 197 +++-
tools/perf/perf.h | 1 +
tools/perf/util/evlist.c| 7 +-
tools/perf/util/evlist.h| 3 +-
tools/perf/util/mmap.c | 110 +
tools/perf/util/mmap.h | 10 ++-
6 files changed, 302 insertions(+), 26 deletions(-)
diff --git a/tools/perf/builtin-record.c b/tools/perf/builtin-record.c
index 9853552bcf16..0f1324549e35 100644
--- a/tools/perf/builtin-record.c
+++ b/tools/perf/builtin-record.c
@@ -121,6 +121,91 @@ static int record__write(struct record *rec, void *bf,
size_t size)
return 0;
}
+static int record__aio_write(struct aiocb *cblock, int trace_fd,
+ void *buf, size_t size, off_t off)
+{
+ int rc;
+
+ cblock->aio_fildes = trace_fd;
+ cblock->aio_buf= buf;
+ cblock->aio_nbytes = size;
+ cblock->aio_offset = off;
+ cblock->aio_sigevent.sigev_notify = SIGEV_NONE;
+
+ do {
+ rc = aio_write(cblock);
+ if (rc == 0) {
+ break;
+ } else if (errno != EAGAIN) {
+ cblock->aio_fildes = -1;
+ pr_err("failed to queue perf data, error: %m\n");
+ break;
+ }
+ } while (1);
+
+ return rc;
+}
+
+static int record__aio_sync(struct perf_mmap *md)
+{
+ void *rem_buf;
+ off_t rem_off;
+ size_t rem_size;
+ ssize_t aio_ret, written;
+ int i, aio_errno, do_suspend, idx = -1;
+ struct aiocb **cblocks = md->cblocks;
+ struct timespec timeout = { 0, 1000 * 1000 * 1 }; // 1ms
+
+ for (i = 0; i < md->nr_cblocks; ++i)
+ if (cblocks[i]->aio_fildes == -1)
+ return i;
+
+ do {
+ do_suspend = 0;
+ if (aio_suspend((const struct aiocb**)cblocks, md->nr_cblocks,
)) {
+ if (!(errno == EAGAIN || errno == EINTR))
+ pr_err("failed to sync perf data, error: %m\n");
+ do_suspend = 1;
+ continue;
+ }
+ for (i = 0; i < md->nr_cblocks; ++i) {
+ aio_errno = aio_error(cblocks[i]);
+ if (aio_errno == EINPROGRESS)
+ continue;
+ written = aio_ret = aio_return(cblocks[i]);
+
Re: [PATCH v7 0/2]: perf: reduce data loss when profiling highly parallel CPU bound workloads
Hi, On 05.09.2018 21:51, Arnaldo Carvalho de Melo wrote: > Em Wed, Sep 05, 2018 at 08:37:32PM +0300, Alexey Budankov escreveu: >> On 05.09.2018 14:28, Jiri Olsa wrote: >>> can't apply this version on Arnaldo's perf/core... > >> my git remote -v > >> origin git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip (fetch) >> origin git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip (push) > >> branch is perf/core, according to MAINTAINERS content. > >> What is Arnaldo's perf/core? This one? > >> git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux > >> and branch is perf/core? > > yes. See patch on top of this branch in answer to Jiri. > > - Arnaldo >
[BUG BISECT] NFS root failure (NULL pointer)
Hi, Today's next fails to mount NFS root under my ARM targets and fails to mount root from file image under QMU. [ 21.512866] Unable to handle kernel NULL pointer dereference at virtual address [ 21.695484] [] (nfs_fs_mount) from [] (legacy_get_tree+0x34/0xec) [ 21.703225] [] (legacy_get_tree) from [] (vfs_get_tree+0x64/0x180) [ 21.79] [] (vfs_get_tree) from [] (do_mount+0x21c/0x958) [ 21.718478] [] (do_mount) from [] (ksys_mount+0x8c/0xbc) [ 21.725513] [] (ksys_mount) from [] (ret_fast_syscall+0x0/0x28) Full log from ARM (NFS root): https://krzk.eu/#/builders/25/builds/750/steps/12/logs/serial0 The NFS root failure bisected to: bae551929c5433bd56ec4dcb97c7d4a50153d357 is the first bad commit commit bae551929c5433bd56ec4dcb97c7d4a50153d357 Author: David Howells Date: Tue Jul 10 21:43:37 2018 +0100 vfs: Separate changing mount flags full remount Separate just the changing of mount flags (MS_REMOUNT|MS_BIND) from full remount because the mount data will get parsed with the new fs_context stuff prior to doing a remount - and this causes the syscall to fail under some circumstances. The QEMU issue seems slightly different and I did not bisect it. The QEMU just cannot find rootfs: [1.008052] Filesystem requires source device [1.008513] VFS: Cannot open root device "mmcblk0" or unknown-block(179,0): error -2 [1.008790] Please append a correct "root=" boot option; here are the available partitions: [1.009300] 0100 16384 ram0 [1.009337] (driver?) [1.009806] fe005120 vda [1.009843] driver: virtio_blk [1.010296] b300 110592 mmcblk0 [1.010319] driver: mmcblk [1.010859] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(179,0) [1.011580] ---[ end Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(179,0) ]--- Boards config: 1. Arch ARM Linux 2. exynos_defconfig - Odroid HC1 ARMv7, octa-core (Cortex-A7+A15), Exynos5422 SoC Systemd: v239 - Odroid U3 ARMv7, quad-core, Exynos4412 SoC Systemd: v238 - Odroid XU ARMv7, octa-core (Cortex-A7+A15) but only A15 working, Exynos5410 SoC Systemd: v236 - Odroid XU3 ARMv7, octa-core (Cortex-A7+A15), Exynos5422 SoC Systemd: v236 3. Custom VF50 defconfig - Toradex Colibri VF50 on Iris board ARMv7, UP, Cortext-A5, NXP VF500 Systemd: v232 4. All boards boot from TFTP with NFS root (NFSv4) 5. QEMU ARMv7, vexpress-v2p-ca9, 128 MB RAM Best regards, Krzysztof
Re: [PATCH 05/11] UAPI: coda: Don't use internal kernel structs in UAPI
Yann Droneaud wrote: > This structure should not have been exposed to userspace in the first > place: it's unusable by userspace as it is. It was incorrect to have it > outside of #ifdef __KERNEL__ before commit 607ca46e97a1b ... > ... > All CODA_REQ_* defines internals to kernel side and not exchanged with > userspace. > > Please move them back to Is there any reason coda_psdev.h needs to be in include/linux/ rather than fs/coda/? David
Re: [RFC] UAPI: Check headers by compiling all together as C++
Le mercredi 05 septembre 2018 à 19:33 +0200, Yann Droneaud a écrit :
> Le mercredi 05 septembre 2018 à 18:55 +0200, Greg KH a écrit :
> > On Wed, Sep 05, 2018 at 04:54:27PM +0100, David Howells wrote:
> > >
> > > Here's a set of patches that inserts a step into the build
> > > process to make
> > > sure that the UAPI headers can all be built together with C++ (if
> > > the
> > > compiler being used supports C++). All but the final patch
> > > perform fixups,
> > > including:
> >
> > Wait, why do we care? What has recently changed to start to
> > directly
> > import kernel uapi files into C++ code?
> >
> > And if userspace wants to do this, can't they do the C namespace
> > trick
> > themselves when they do the import? That must be how they are
> > doing it
> > today, right?
> >
>
> They can't.
>
>
> Adding extern "C" { } doesn't magically make "class" a non keyword.
> Even if it was the case, writing C++ code using whatever->class would
> probably broke because class is a keyword in C++.
>
For the record, libX11 has to handle the kink pf issue with C++
keyword:
https://gitlab.freedesktop.org/xorg/lib/libx11/blob/733f64bfeb311c1d040b2f751bfdef9c9d0f89ef/include/X11/Xlib.h#L227
typedef struct {
XExtData *ext_data; /* hook for extension to hang data */
VisualID visualid; /* visual id of this visual */
#if defined(__cplusplus) || defined(c_plusplus)
int c_class;/* C++ class of screen (monochrome, etc.) */
#else
int class; /* class of screen (monochrome, etc.) */
#endif
unsigned long red_mask, green_mask, blue_mask; /* mask values */
int bits_per_rgb; /* log base 2 of distinct color values */
int map_entries;/* color map entries */
} Visual;
Regards.
--
Yann Droneaud
OPTEYA
[PATCH AUTOSEL 3.18 13/19] fbdev: Distinguish between interlaced and progressive modes
From: Fredrik Noring
[ Upstream commit 1ba0a59cea41ea05fda92daaf2a2958a2246b9cf ]
I discovered the problem when developing a frame buffer driver for the
PlayStation 2 (not yet merged), using the following video modes for the
PlayStation 3 in drivers/video/fbdev/ps3fb.c:
}, {
/* 1080if */
"1080if", 50, 1920, 1080, 13468, 148, 484, 36, 4, 88, 5,
FB_SYNC_BROADCAST, FB_VMODE_INTERLACED
}, {
/* 1080pf */
"1080pf", 50, 1920, 1080, 6734, 148, 484, 36, 4, 88, 5,
FB_SYNC_BROADCAST, FB_VMODE_NONINTERLACED
},
In ps3fb_probe, the mode_option module parameter is used with fb_find_mode
but it can only select the interlaced variant of 1920x1080 since the loop
matching the modes does not take the difference between interlaced and
progressive modes into account.
In short, without the patch, progressive 1920x1080 cannot be chosen as a
mode_option parameter since fb_find_mode (falsely) thinks interlace is a
perfect match.
Signed-off-by: Fredrik Noring
Cc: "Maciej W. Rozycki"
[b.zolnierkie: updated patch description]
Signed-off-by: Bartlomiej Zolnierkiewicz
Signed-off-by: Sasha Levin
---
drivers/video/fbdev/core/modedb.c | 41 ++-
1 file changed, 30 insertions(+), 11 deletions(-)
diff --git a/drivers/video/fbdev/core/modedb.c
b/drivers/video/fbdev/core/modedb.c
index 388f7971494b..620d9ec664e1 100644
--- a/drivers/video/fbdev/core/modedb.c
+++ b/drivers/video/fbdev/core/modedb.c
@@ -533,7 +533,7 @@ static int fb_try_mode(struct fb_var_screeninfo *var,
struct fb_info *info,
*
* Valid mode specifiers for @mode_option:
*
- * x[M][R][-][@][i][m] or
+ * x[M][R][-][@][i][p][m] or
* [-][@]
*
* with , , and decimal numbers and
@@ -542,10 +542,10 @@ static int fb_try_mode(struct fb_var_screeninfo *var,
struct fb_info *info,
* If 'M' is present after yres (and before refresh/bpp if present),
* the function will compute the timings using VESA(tm) Coordinated
* Video Timings (CVT). If 'R' is present after 'M', will compute with
- * reduced blanking (for flatpanels). If 'i' is present, compute
- * interlaced mode. If 'm' is present, add margins equal to 1.8%
- * of xres rounded down to 8 pixels, and 1.8% of yres. The char
- * 'i' and 'm' must be after 'M' and 'R'. Example:
+ * reduced blanking (for flatpanels). If 'i' or 'p' are present, compute
+ * interlaced or progressive mode. If 'm' is present, add margins equal
+ * to 1.8% of xres rounded down to 8 pixels, and 1.8% of yres. The chars
+ * 'i', 'p' and 'm' must be after 'M' and 'R'. Example:
*
* 1024x768MR-8@60m - Reduced blank with margins at 60Hz.
*
@@ -586,7 +586,8 @@ int fb_find_mode(struct fb_var_screeninfo *var,
unsigned int namelen = strlen(name);
int res_specified = 0, bpp_specified = 0, refresh_specified = 0;
unsigned int xres = 0, yres = 0, bpp = default_bpp, refresh = 0;
- int yres_specified = 0, cvt = 0, rb = 0, interlace = 0;
+ int yres_specified = 0, cvt = 0, rb = 0;
+ int interlace_specified = 0, interlace = 0;
int margins = 0;
u32 best, diff, tdiff;
@@ -637,9 +638,17 @@ int fb_find_mode(struct fb_var_screeninfo *var,
if (!cvt)
margins = 1;
break;
+ case 'p':
+ if (!cvt) {
+ interlace = 0;
+ interlace_specified = 1;
+ }
+ break;
case 'i':
- if (!cvt)
+ if (!cvt) {
interlace = 1;
+ interlace_specified = 1;
+ }
break;
default:
goto done;
@@ -708,11 +717,21 @@ int fb_find_mode(struct fb_var_screeninfo *var,
if ((name_matches(db[i], name, namelen) ||
(res_specified && res_matches(db[i], xres, yres)))
&&
!fb_try_mode(var, info, [i], bpp)) {
- if (refresh_specified && db[i].refresh ==
refresh)
- return 1;
+ const int db_interlace = (db[i].vmode &
+ FB_VMODE_INTERLACED ? 1 : 0);
+ int score = abs(db[i].refresh - refresh);
+
+ if (interlace_specified)
+ score += abs(db_interlace - interlace);
+
+ if (!interlace_specified ||
+
[PATCH AUTOSEL 4.4 22/30] powerpc/powernv: opal_put_chars partial write fix
From: Nicholas Piggin
[ Upstream commit bd90284cc6c1c9e8e48c8eadd0c79574fcce0b81 ]
The intention here is to consume and discard the remaining buffer
upon error. This works if there has not been a previous partial write.
If there has been, then total_len is no longer total number of bytes
to copy. total_len is always "bytes left to copy", so it should be
added to written bytes.
This code may not be exercised any more if partial writes will not be
hit, but this is a small bugfix before a larger change.
Reviewed-by: Benjamin Herrenschmidt
Signed-off-by: Nicholas Piggin
Signed-off-by: Michael Ellerman
Signed-off-by: Sasha Levin
---
arch/powerpc/platforms/powernv/opal.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/platforms/powernv/opal.c
b/arch/powerpc/platforms/powernv/opal.c
index e48826aa314c..b40606051efe 100644
--- a/arch/powerpc/platforms/powernv/opal.c
+++ b/arch/powerpc/platforms/powernv/opal.c
@@ -371,7 +371,7 @@ int opal_put_chars(uint32_t vtermno, const char *data, int
total_len)
/* Closed or other error drop */
if (rc != OPAL_SUCCESS && rc != OPAL_BUSY &&
rc != OPAL_BUSY_EVENT) {
- written = total_len;
+ written += total_len;
break;
}
if (rc == OPAL_SUCCESS) {
--
2.17.1
[PATCH AUTOSEL 3.18 07/19] gfs2: Don't reject a supposedly full bitmap if we have blocks reserved
From: Bob Peterson
[ Upstream commit e79e0e1428188b24c3b57309ffa54a33c4ae40c4 ]
Before this patch, you could get into situations like this:
1. Process 1 searches for X free blocks, finds them, makes a reservation
2. Process 2 searches for free blocks in the same rgrp, but now the
bitmap is full because process 1's reservation is skipped over.
So it marks the bitmap as GBF_FULL.
3. Process 1 tries to allocate blocks from its own reservation, but
since the GBF_FULL bit is set, it skips over the rgrp and searches
elsewhere, thus not using its own reservation.
This patch adds an additional check to allow processes to use their
own reservations.
Signed-off-by: Bob Peterson
Signed-off-by: Andreas Gruenbacher
Signed-off-by: Sasha Levin
---
fs/gfs2/rgrp.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/fs/gfs2/rgrp.c b/fs/gfs2/rgrp.c
index 7474c413ffd1..54bc68acc10c 100644
--- a/fs/gfs2/rgrp.c
+++ b/fs/gfs2/rgrp.c
@@ -1643,7 +1643,8 @@ static int gfs2_rbm_find(struct gfs2_rbm *rbm, u8 state,
u32 *minext,
while(1) {
bi = rbm_bi(rbm);
- if (test_bit(GBF_FULL, >bi_flags) &&
+ if ((ip == NULL || !gfs2_rs_active(>i_res)) &&
+ test_bit(GBF_FULL, >bi_flags) &&
(state == GFS2_BLKST_FREE))
goto next_bitmap;
--
2.17.1
[PATCH AUTOSEL 3.18 02/19] ALSA: usb-audio: Fix multiple definitions in AU0828_DEVICE() macro
From: Takashi Iwai
[ Upstream commit bd1cd0eb2ce9141100628d476ead4de485501b29 ]
AU0828_DEVICE() macro in quirks-table.h uses USB_DEVICE_VENDOR_SPEC()
for expanding idVendor and idProduct fields. However, the latter
macro adds also match_flags and bInterfaceClass, which are different
from the values AU0828_DEVICE() macro sets after that.
For fixing them, just expand idVendor and idProduct fields manually in
AU0828_DEVICE().
This fixes sparse warnings like:
sound/usb/quirks-table.h:2892:1: warning: Initializer entry defined twice
Signed-off-by: Takashi Iwai
Signed-off-by: Sasha Levin
---
sound/usb/quirks-table.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/sound/usb/quirks-table.h b/sound/usb/quirks-table.h
index adec087725d1..e86fecaa26ec 100644
--- a/sound/usb/quirks-table.h
+++ b/sound/usb/quirks-table.h
@@ -2910,7 +2910,8 @@ YAMAHA_DEVICE(0x7010, "UB99"),
*/
#define AU0828_DEVICE(vid, pid, vname, pname) { \
- USB_DEVICE_VENDOR_SPEC(vid, pid), \
+ .idVendor = vid, \
+ .idProduct = pid, \
.match_flags = USB_DEVICE_ID_MATCH_DEVICE | \
USB_DEVICE_ID_MATCH_INT_CLASS | \
USB_DEVICE_ID_MATCH_INT_SUBCLASS, \
--
2.17.1
[PATCH AUTOSEL 3.18 01/19] ALSA: msnd: Fix the default sample sizes
From: Takashi Iwai
[ Upstream commit 7c500f9ea139d0c9b80fdea5a9c911db3166ea54 ]
The default sample sizes set by msnd driver are bogus; it sets ALSA
PCM format, not the actual bit width.
Signed-off-by: Takashi Iwai
Signed-off-by: Sasha Levin
---
sound/isa/msnd/msnd_pinnacle.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/sound/isa/msnd/msnd_pinnacle.c b/sound/isa/msnd/msnd_pinnacle.c
index cf70dba80124..741714332365 100644
--- a/sound/isa/msnd/msnd_pinnacle.c
+++ b/sound/isa/msnd/msnd_pinnacle.c
@@ -82,10 +82,10 @@
static void set_default_audio_parameters(struct snd_msnd *chip)
{
- chip->play_sample_size = DEFSAMPLESIZE;
+ chip->play_sample_size = snd_pcm_format_width(DEFSAMPLESIZE);
chip->play_sample_rate = DEFSAMPLERATE;
chip->play_channels = DEFCHANNELS;
- chip->capture_sample_size = DEFSAMPLESIZE;
+ chip->capture_sample_size = snd_pcm_format_width(DEFSAMPLESIZE);
chip->capture_sample_rate = DEFSAMPLERATE;
chip->capture_channels = DEFCHANNELS;
}
--
2.17.1
[PATCH AUTOSEL 4.4 29/30] platform/x86: toshiba_acpi: Fix defined but not used build warnings
From: Randy Dunlap
[ Upstream commit c2e2a618eb7104e18fdcf739d4d911563812a81c ]
Fix a build warning in toshiba_acpi.c when CONFIG_PROC_FS is not enabled
by marking the unused function as __maybe_unused.
../drivers/platform/x86/toshiba_acpi.c:1685:12: warning: 'version_proc_show'
defined but not used [-Wunused-function]
Signed-off-by: Randy Dunlap
Cc: Azael Avalos
Cc: platform-driver-...@vger.kernel.org
Cc: Andy Shevchenko
Signed-off-by: Darren Hart (VMware)
Signed-off-by: Sasha Levin
---
drivers/platform/x86/toshiba_acpi.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/platform/x86/toshiba_acpi.c
b/drivers/platform/x86/toshiba_acpi.c
index f774cb576ffa..1ff95b5a429d 100644
--- a/drivers/platform/x86/toshiba_acpi.c
+++ b/drivers/platform/x86/toshiba_acpi.c
@@ -34,6 +34,7 @@
#define TOSHIBA_ACPI_VERSION "0.23"
#define PROC_INTERFACE_VERSION 1
+#include
#include
#include
#include
@@ -1472,7 +1473,7 @@ static const struct file_operations keys_proc_fops = {
.write = keys_proc_write,
};
-static int version_proc_show(struct seq_file *m, void *v)
+static int __maybe_unused version_proc_show(struct seq_file *m, void *v)
{
seq_printf(m, "driver: %s\n", TOSHIBA_ACPI_VERSION);
seq_printf(m, "proc_interface: %d\n", PROC_INTERFACE_VERSION);
--
2.17.1
[PATCH AUTOSEL 4.4 24/30] mac80211: restrict delayed tailroom needed decrement
From: Manikanta Pubbisetty
[ Upstream commit 133bf90dbb8b873286f8ec2e81ba26e863114b8c ]
As explained in ieee80211_delayed_tailroom_dec(), during roam,
keys of the old AP will be destroyed and new keys will be
installed. Deletion of the old key causes
crypto_tx_tailroom_needed_cnt to go from 1 to 0 and the new key
installation causes a transition from 0 to 1.
Whenever crypto_tx_tailroom_needed_cnt transitions from 0 to 1,
we invoke synchronize_net(); the reason for doing this is to avoid
a race in the TX path as explained in increment_tailroom_need_count().
This synchronize_net() operation can be slow and can affect the station
roam time. To avoid this, decrementing the crypto_tx_tailroom_needed_cnt
is delayed for a while so that upon installation of new key the
transition would be from 1 to 2 instead of 0 to 1 and thereby
improving the roam time.
This is all correct for a STA iftype, but deferring the tailroom_needed
decrement for other iftypes may be unnecessary.
For example, let's consider the case of a 4-addr client connecting to
an AP for which AP_VLAN interface is also created, let the initial
value for tailroom_needed on the AP be 1.
* 4-addr client connects to the AP (AP: tailroom_needed = 1)
* AP will clear old keys, delay decrement of tailroom_needed count
* AP_VLAN is created, it takes the tailroom count from master
(AP_VLAN: tailroom_needed = 1, AP: tailroom_needed = 1)
* Install new key for the station, assume key is plumbed in the HW,
there won't be any change in tailroom_needed count on AP iface
* Delayed decrement of tailroom_needed count on AP
(AP: tailroom_needed = 0, AP_VLAN: tailroom_needed = 1)
Because of the delayed decrement on AP iface, tailroom_needed count goes
out of sync between AP(master iface) and AP_VLAN(slave iface) and
there would be unnecessary tailroom created for the packets going
through AP_VLAN iface.
Also, WARN_ONs were observed while trying to bring down the AP_VLAN
interface:
(warn_slowpath_common) (warn_slowpath_null+0x18/0x20)
(warn_slowpath_null) (ieee80211_free_keys+0x114/0x1e4)
(ieee80211_free_keys) (ieee80211_del_virtual_monitor+0x51c/0x850)
(ieee80211_del_virtual_monitor) (ieee80211_stop+0x30/0x3c)
(ieee80211_stop) (__dev_close_many+0x94/0xb8)
(__dev_close_many) (dev_close_many+0x5c/0xc8)
Restricting delayed decrement to station interface alone fixes the problem
and it makes sense to do so because delayed decrement is done to improve
roam time which is applicable only for client devices.
Signed-off-by: Manikanta Pubbisetty
Signed-off-by: Johannes Berg
Signed-off-by: Sasha Levin
---
net/mac80211/cfg.c | 2 +-
net/mac80211/key.c | 24 +++-
2 files changed, 16 insertions(+), 10 deletions(-)
diff --git a/net/mac80211/cfg.c b/net/mac80211/cfg.c
index 00a8cc572a22..1f930032253a 100644
--- a/net/mac80211/cfg.c
+++ b/net/mac80211/cfg.c
@@ -286,7 +286,7 @@ static int ieee80211_del_key(struct wiphy *wiphy, struct
net_device *dev,
goto out_unlock;
}
- ieee80211_key_free(key, true);
+ ieee80211_key_free(key, sdata->vif.type == NL80211_IFTYPE_STATION);
ret = 0;
out_unlock:
diff --git a/net/mac80211/key.c b/net/mac80211/key.c
index 4a72c0d1e56f..91a4e606edcd 100644
--- a/net/mac80211/key.c
+++ b/net/mac80211/key.c
@@ -647,11 +647,15 @@ int ieee80211_key_link(struct ieee80211_key *key,
{
struct ieee80211_local *local = sdata->local;
struct ieee80211_key *old_key;
- int idx, ret;
- bool pairwise;
-
- pairwise = key->conf.flags & IEEE80211_KEY_FLAG_PAIRWISE;
- idx = key->conf.keyidx;
+ int idx = key->conf.keyidx;
+ bool pairwise = key->conf.flags & IEEE80211_KEY_FLAG_PAIRWISE;
+ /*
+* We want to delay tailroom updates only for station - in that
+* case it helps roaming speed, but in other cases it hurts and
+* can cause warnings to appear.
+*/
+ bool delay_tailroom = sdata->vif.type == NL80211_IFTYPE_STATION;
+ int ret;
mutex_lock(>local->key_mtx);
@@ -679,14 +683,14 @@ int ieee80211_key_link(struct ieee80211_key *key,
increment_tailroom_need_count(sdata);
ieee80211_key_replace(sdata, sta, pairwise, old_key, key);
- ieee80211_key_destroy(old_key, true);
+ ieee80211_key_destroy(old_key, delay_tailroom);
ieee80211_debugfs_key_add(key);
if (!local->wowlan) {
ret = ieee80211_key_enable_hw_accel(key);
if (ret)
- ieee80211_key_free(key, true);
+ ieee80211_key_free(key, delay_tailroom);
} else {
ret = 0;
}
@@ -874,7 +878,8 @@ void ieee80211_free_sta_keys(struct ieee80211_local *local,
ieee80211_key_replace(key->sdata, key->sta,
key->conf.flags & IEEE80211_KEY_FLAG_PAIRWISE,
key, NULL);
- __ieee80211_key_destroy(key, true);
+
[PATCH AUTOSEL 4.4 19/30] fbdev: Distinguish between interlaced and progressive modes
From: Fredrik Noring
[ Upstream commit 1ba0a59cea41ea05fda92daaf2a2958a2246b9cf ]
I discovered the problem when developing a frame buffer driver for the
PlayStation 2 (not yet merged), using the following video modes for the
PlayStation 3 in drivers/video/fbdev/ps3fb.c:
}, {
/* 1080if */
"1080if", 50, 1920, 1080, 13468, 148, 484, 36, 4, 88, 5,
FB_SYNC_BROADCAST, FB_VMODE_INTERLACED
}, {
/* 1080pf */
"1080pf", 50, 1920, 1080, 6734, 148, 484, 36, 4, 88, 5,
FB_SYNC_BROADCAST, FB_VMODE_NONINTERLACED
},
In ps3fb_probe, the mode_option module parameter is used with fb_find_mode
but it can only select the interlaced variant of 1920x1080 since the loop
matching the modes does not take the difference between interlaced and
progressive modes into account.
In short, without the patch, progressive 1920x1080 cannot be chosen as a
mode_option parameter since fb_find_mode (falsely) thinks interlace is a
perfect match.
Signed-off-by: Fredrik Noring
Cc: "Maciej W. Rozycki"
[b.zolnierkie: updated patch description]
Signed-off-by: Bartlomiej Zolnierkiewicz
Signed-off-by: Sasha Levin
---
drivers/video/fbdev/core/modedb.c | 41 ++-
1 file changed, 30 insertions(+), 11 deletions(-)
diff --git a/drivers/video/fbdev/core/modedb.c
b/drivers/video/fbdev/core/modedb.c
index 2510fa728d77..de119f11b78f 100644
--- a/drivers/video/fbdev/core/modedb.c
+++ b/drivers/video/fbdev/core/modedb.c
@@ -644,7 +644,7 @@ static int fb_try_mode(struct fb_var_screeninfo *var,
struct fb_info *info,
*
* Valid mode specifiers for @mode_option:
*
- * x[M][R][-][@][i][m] or
+ * x[M][R][-][@][i][p][m] or
* [-][@]
*
* with , , and decimal numbers and
@@ -653,10 +653,10 @@ static int fb_try_mode(struct fb_var_screeninfo *var,
struct fb_info *info,
* If 'M' is present after yres (and before refresh/bpp if present),
* the function will compute the timings using VESA(tm) Coordinated
* Video Timings (CVT). If 'R' is present after 'M', will compute with
- * reduced blanking (for flatpanels). If 'i' is present, compute
- * interlaced mode. If 'm' is present, add margins equal to 1.8%
- * of xres rounded down to 8 pixels, and 1.8% of yres. The char
- * 'i' and 'm' must be after 'M' and 'R'. Example:
+ * reduced blanking (for flatpanels). If 'i' or 'p' are present, compute
+ * interlaced or progressive mode. If 'm' is present, add margins equal
+ * to 1.8% of xres rounded down to 8 pixels, and 1.8% of yres. The chars
+ * 'i', 'p' and 'm' must be after 'M' and 'R'. Example:
*
* 1024x768MR-8@60m - Reduced blank with margins at 60Hz.
*
@@ -697,7 +697,8 @@ int fb_find_mode(struct fb_var_screeninfo *var,
unsigned int namelen = strlen(name);
int res_specified = 0, bpp_specified = 0, refresh_specified = 0;
unsigned int xres = 0, yres = 0, bpp = default_bpp, refresh = 0;
- int yres_specified = 0, cvt = 0, rb = 0, interlace = 0;
+ int yres_specified = 0, cvt = 0, rb = 0;
+ int interlace_specified = 0, interlace = 0;
int margins = 0;
u32 best, diff, tdiff;
@@ -748,9 +749,17 @@ int fb_find_mode(struct fb_var_screeninfo *var,
if (!cvt)
margins = 1;
break;
+ case 'p':
+ if (!cvt) {
+ interlace = 0;
+ interlace_specified = 1;
+ }
+ break;
case 'i':
- if (!cvt)
+ if (!cvt) {
interlace = 1;
+ interlace_specified = 1;
+ }
break;
default:
goto done;
@@ -819,11 +828,21 @@ int fb_find_mode(struct fb_var_screeninfo *var,
if ((name_matches(db[i], name, namelen) ||
(res_specified && res_matches(db[i], xres, yres)))
&&
!fb_try_mode(var, info, [i], bpp)) {
- if (refresh_specified && db[i].refresh ==
refresh)
- return 1;
+ const int db_interlace = (db[i].vmode &
+ FB_VMODE_INTERLACED ? 1 : 0);
+ int score = abs(db[i].refresh - refresh);
+
+ if (interlace_specified)
+ score += abs(db_interlace - interlace);
+
+ if (!interlace_specified ||
+
[PATCH AUTOSEL 4.4 30/30] crypto: sharah - Unregister correct algorithms for SAHARA 3
From: Michael Müller [ Upstream commit 0e7d4d932ffc23f75efb31a8c2ac2396c1b81c55 ] This patch fixes two typos related to unregistering algorithms supported by SAHARAH 3. In sahara_register_algs the wrong algorithms are unregistered in case of an error. In sahara_unregister_algs the wrong array is used to determine the iteration count. Signed-off-by: Michael Müller Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin --- drivers/crypto/sahara.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/crypto/sahara.c b/drivers/crypto/sahara.c index f68c24a98277..dedfc96acc66 100644 --- a/drivers/crypto/sahara.c +++ b/drivers/crypto/sahara.c @@ -1363,7 +1363,7 @@ static int sahara_register_algs(struct sahara_dev *dev) err_sha_v3_algs: for (j = 0; j < k; j++) - crypto_unregister_ahash(_v4_algs[j]); + crypto_unregister_ahash(_v3_algs[j]); err_aes_algs: for (j = 0; j < i; j++) @@ -1379,7 +1379,7 @@ static void sahara_unregister_algs(struct sahara_dev *dev) for (i = 0; i < ARRAY_SIZE(aes_algs); i++) crypto_unregister_alg(_algs[i]); - for (i = 0; i < ARRAY_SIZE(sha_v4_algs); i++) + for (i = 0; i < ARRAY_SIZE(sha_v3_algs); i++) crypto_unregister_ahash(_v3_algs[i]); if (dev->version > SAHARA_VERSION_3) -- 2.17.1
[PATCH AUTOSEL 4.4 09/30] dmaengine: pl330: fix irq race with terminate_all
From: John Keeping [ Upstream commit e49756544a21f5625b379b3871d27d8500764670 ] In pl330_update() when checking if a channel has been aborted, the channel's lock is not taken, only the overall pl330_dmac lock. But in pl330_terminate_all() the aborted flag (req_running==-1) is set under the channel lock and not the pl330_dmac lock. With threaded interrupts, this leads to a potential race: pl330_terminate_all pl330_update --- lock channel entry lock pl330 _stop channel unlock pl330 lock pl330 check req_running != -1 req_running = -1 _start channel Signed-off-by: John Keeping Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin --- drivers/dma/pl330.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/dma/pl330.c b/drivers/dma/pl330.c index 8db791ef2027..95619ee33112 100644 --- a/drivers/dma/pl330.c +++ b/drivers/dma/pl330.c @@ -2132,13 +2132,14 @@ static int pl330_terminate_all(struct dma_chan *chan) pm_runtime_get_sync(pl330->ddma.dev); spin_lock_irqsave(>lock, flags); + spin_lock(>lock); _stop(pch->thread); - spin_unlock(>lock); - pch->thread->req[0].desc = NULL; pch->thread->req[1].desc = NULL; pch->thread->req_running = -1; + spin_unlock(>lock); + power_down = pch->active; pch->active = false; -- 2.17.1
[PATCH AUTOSEL 4.4 28/30] s390/qeth: reset layer2 attribute on layer switch
From: Julian Wiedmann
[ Upstream commit 70551dc46ffa3555a0b5f3545b0cd87ab67fd002 ]
After the subdriver's remove() routine has completed, the card's layer
mode is undetermined again. Reflect this in the layer2 field.
If qeth_dev_layer2_store() hits an error after remove() was called, the
card _always_ requires a setup(), even if the previous layer mode is
requested again.
But qeth_dev_layer2_store() bails out early if the requested layer mode
still matches the current one. So unless we reset the layer2 field,
re-probing the card back to its previous mode is currently not possible.
Signed-off-by: Julian Wiedmann
Signed-off-by: David S. Miller
Signed-off-by: Sasha Levin
---
drivers/s390/net/qeth_core_sys.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/s390/net/qeth_core_sys.c b/drivers/s390/net/qeth_core_sys.c
index fa844b0ff847..7bcf0dae3a65 100644
--- a/drivers/s390/net/qeth_core_sys.c
+++ b/drivers/s390/net/qeth_core_sys.c
@@ -419,6 +419,7 @@ static ssize_t qeth_dev_layer2_store(struct device *dev,
if (card->discipline) {
card->discipline->remove(card->gdev);
qeth_core_free_discipline(card);
+ card->options.layer2 = -1;
}
rc = qeth_core_load_discipline(card, newdis);
--
2.17.1
[PATCH AUTOSEL 3.18 06/19] mtd/maps: fix solutionengine.c printk format warnings
From: Randy Dunlap
[ Upstream commit 1d25e3eeed1d987404e2d2e451eebac8c15cecc1 ]
Fix 2 printk format warnings (this driver is currently only used by
arch/sh/) by using "%pap" instead of "%lx".
Fixes these build warnings:
../drivers/mtd/maps/solutionengine.c: In function 'init_soleng_maps':
../include/linux/kern_levels.h:5:18: warning: format '%lx' expects argument of
type 'long unsigned int', but argument 2 has type 'resource_size_t' {aka
'unsigned int'} [-Wformat=]
../drivers/mtd/maps/solutionengine.c:62:54: note: format string is defined here
printk(KERN_NOTICE "Solution Engine: Flash at 0x%08lx, EPROM at 0x%08lx\n",
^
%08x
../include/linux/kern_levels.h:5:18: warning: format '%lx' expects argument of
type 'long unsigned int', but argument 3 has type 'resource_size_t' {aka
'unsigned int'} [-Wformat=]
../drivers/mtd/maps/solutionengine.c:62:72: note: format string is defined here
printk(KERN_NOTICE "Solution Engine: Flash at 0x%08lx, EPROM at 0x%08lx\n",
^
%08x
Cc: David Woodhouse
Cc: Brian Norris
Cc: Boris Brezillon
Cc: Marek Vasut
Cc: Richard Weinberger
Cc: linux-...@lists.infradead.org
Cc: Yoshinori Sato
Cc: Rich Felker
Cc: linux...@vger.kernel.org
Cc: Sergei Shtylyov
Signed-off-by: Randy Dunlap
Signed-off-by: Boris Brezillon
Signed-off-by: Sasha Levin
---
drivers/mtd/maps/solutionengine.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/mtd/maps/solutionengine.c
b/drivers/mtd/maps/solutionengine.c
index bb580bc16445..c07f21b20463 100644
--- a/drivers/mtd/maps/solutionengine.c
+++ b/drivers/mtd/maps/solutionengine.c
@@ -59,9 +59,9 @@ static int __init init_soleng_maps(void)
return -ENXIO;
}
}
- printk(KERN_NOTICE "Solution Engine: Flash at 0x%08lx, EPROM at
0x%08lx\n",
- soleng_flash_map.phys & 0x1fff,
- soleng_eprom_map.phys & 0x1fff);
+ printk(KERN_NOTICE "Solution Engine: Flash at 0x%pap, EPROM at
0x%pap\n",
+ _flash_map.phys,
+ _eprom_map.phys);
flash_mtd->owner = THIS_MODULE;
eprom_mtd = do_map_probe("map_rom", _eprom_map);
--
2.17.1
[PATCH AUTOSEL 4.4 23/30] MIPS: jz4740: Bump zload address
From: Paul Cercueil [ Upstream commit c6ea7e9747318e5a6774995f4f8e3e0f7c0fa8ba ] Having the zload address at 0x8060. means the size of the uncompressed kernel cannot be bigger than around 6 MiB, as it is deflated at address 0x8001.. This limit is too small; a kernel with some built-in drivers and things like debugfs enabled will already be over 6 MiB in size, and so will fail to extract properly. To fix this, we bump the zload address from 0x8060. to 0x8100.. This is fine, as all the boards featuring Ingenic JZ SoCs have at least 32 MiB of RAM, and use u-boot or compatible bootloaders which won't hardcode the load address but read it from the uImage's header. Signed-off-by: Paul Cercueil Signed-off-by: Paul Burton Patchwork: https://patchwork.linux-mips.org/patch/19787/ Cc: Ralf Baechle Cc: James Hogan Cc: linux-m...@linux-mips.org Cc: linux-kernel@vger.kernel.org Signed-off-by: Sasha Levin --- arch/mips/jz4740/Platform | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/mips/jz4740/Platform b/arch/mips/jz4740/Platform index 28448d358c10..a2a5a85ea1f9 100644 --- a/arch/mips/jz4740/Platform +++ b/arch/mips/jz4740/Platform @@ -1,4 +1,4 @@ platform-$(CONFIG_MACH_INGENIC)+= jz4740/ cflags-$(CONFIG_MACH_INGENIC) += -I$(srctree)/arch/mips/include/asm/mach-jz4740 load-$(CONFIG_MACH_INGENIC)+= 0x8001 -zload-$(CONFIG_MACH_INGENIC) += 0x8060 +zload-$(CONFIG_MACH_INGENIC) += 0x8100 -- 2.17.1
[PATCH AUTOSEL 4.9 10/43] media: tw686x: Fix oops on buffer alloc failure
From: Krzysztof Ha?asa
[ Upstream commit 5a1a2f63d840dc2631505b607e11ff65ac1b7d3c ]
The error path currently calls tw686x_video_free() which requires
vc->dev to be initialized, causing a NULL dereference on uninitizalized
channels.
Fix this by setting the vc->dev fields for all the channels first.
Fixes: f8afaa8dbc0d ("[media] tw686x: Introduce an interface to support
multiple DMA modes")
Signed-off-by: Krzysztof Ha?asa
Signed-off-by: Hans Verkuil
Signed-off-by: Mauro Carvalho Chehab
Signed-off-by: Sasha Levin
---
drivers/media/pci/tw686x/tw686x-video.c | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/drivers/media/pci/tw686x/tw686x-video.c
b/drivers/media/pci/tw686x/tw686x-video.c
index 0ea8dd44026c..3a06c000f97b 100644
--- a/drivers/media/pci/tw686x/tw686x-video.c
+++ b/drivers/media/pci/tw686x/tw686x-video.c
@@ -1190,6 +1190,14 @@ int tw686x_video_init(struct tw686x_dev *dev)
return err;
}
+ /* Initialize vc->dev and vc->ch for the error path */
+ for (ch = 0; ch < max_channels(dev); ch++) {
+ struct tw686x_video_channel *vc = >video_channels[ch];
+
+ vc->dev = dev;
+ vc->ch = ch;
+ }
+
for (ch = 0; ch < max_channels(dev); ch++) {
struct tw686x_video_channel *vc = >video_channels[ch];
struct video_device *vdev;
@@ -1198,9 +1206,6 @@ int tw686x_video_init(struct tw686x_dev *dev)
spin_lock_init(>qlock);
INIT_LIST_HEAD(>vidq_queued);
- vc->dev = dev;
- vc->ch = ch;
-
/* default settings */
err = tw686x_set_standard(vc, V4L2_STD_NTSC);
if (err)
--
2.17.1
[PATCH AUTOSEL 4.14 48/67] Smack: Fix handling of IPv4 traffic received by PF_INET6 sockets
From: Piotr Sawicki
[ Upstream commit 129a99890936766f4b69b9da7ed88366313a9210 ]
A socket which has sk_family set to PF_INET6 is able to receive not
only IPv6 but also IPv4 traffic (IPv4-mapped IPv6 addresses).
Prior to this patch, the smk_skb_to_addr_ipv6() could have been
called for socket buffers containing IPv4 packets, in result such
traffic was allowed.
Signed-off-by: Piotr Sawicki
Signed-off-by: Casey Schaufler
Signed-off-by: Sasha Levin
---
security/smack/smack_lsm.c | 14 +-
1 file changed, 9 insertions(+), 5 deletions(-)
diff --git a/security/smack/smack_lsm.c b/security/smack/smack_lsm.c
index fdf01bfd1b07..c8fd5c10b7c6 100644
--- a/security/smack/smack_lsm.c
+++ b/security/smack/smack_lsm.c
@@ -3960,15 +3960,19 @@ static int smack_socket_sock_rcv_skb(struct sock *sk,
struct sk_buff *skb)
struct smack_known *skp = NULL;
int rc = 0;
struct smk_audit_info ad;
+ u16 family = sk->sk_family;
#ifdef CONFIG_AUDIT
struct lsm_network_audit net;
#endif
#if IS_ENABLED(CONFIG_IPV6)
struct sockaddr_in6 sadd;
int proto;
+
+ if (family == PF_INET6 && skb->protocol == htons(ETH_P_IP))
+ family = PF_INET;
#endif /* CONFIG_IPV6 */
- switch (sk->sk_family) {
+ switch (family) {
case PF_INET:
#ifdef CONFIG_SECURITY_SMACK_NETFILTER
/*
@@ -3986,7 +3990,7 @@ static int smack_socket_sock_rcv_skb(struct sock *sk,
struct sk_buff *skb)
*/
netlbl_secattr_init();
- rc = netlbl_skbuff_getattr(skb, sk->sk_family, );
+ rc = netlbl_skbuff_getattr(skb, family, );
if (rc == 0)
skp = smack_from_secattr(, ssp);
else
@@ -3999,7 +4003,7 @@ static int smack_socket_sock_rcv_skb(struct sock *sk,
struct sk_buff *skb)
#endif
#ifdef CONFIG_AUDIT
smk_ad_init_net(, __func__, LSM_AUDIT_DATA_NET, );
- ad.a.u.net->family = sk->sk_family;
+ ad.a.u.net->family = family;
ad.a.u.net->netif = skb->skb_iif;
ipv4_skb_to_auditdata(skb, , NULL);
#endif
@@ -4013,7 +4017,7 @@ static int smack_socket_sock_rcv_skb(struct sock *sk,
struct sk_buff *skb)
rc = smk_bu_note("IPv4 delivery", skp, ssp->smk_in,
MAY_WRITE, rc);
if (rc != 0)
- netlbl_skbuff_err(skb, sk->sk_family, rc, 0);
+ netlbl_skbuff_err(skb, family, rc, 0);
break;
#if IS_ENABLED(CONFIG_IPV6)
case PF_INET6:
@@ -4029,7 +4033,7 @@ static int smack_socket_sock_rcv_skb(struct sock *sk,
struct sk_buff *skb)
skp = smack_net_ambient;
#ifdef CONFIG_AUDIT
smk_ad_init_net(, __func__, LSM_AUDIT_DATA_NET, );
- ad.a.u.net->family = sk->sk_family;
+ ad.a.u.net->family = family;
ad.a.u.net->netif = skb->skb_iif;
ipv6_skb_to_auditdata(skb, , NULL);
#endif /* CONFIG_AUDIT */
--
2.17.1
[PATCH AUTOSEL 4.9 04/43] ALSA: usb-audio: Fix multiple definitions in AU0828_DEVICE() macro
From: Takashi Iwai
[ Upstream commit bd1cd0eb2ce9141100628d476ead4de485501b29 ]
AU0828_DEVICE() macro in quirks-table.h uses USB_DEVICE_VENDOR_SPEC()
for expanding idVendor and idProduct fields. However, the latter
macro adds also match_flags and bInterfaceClass, which are different
from the values AU0828_DEVICE() macro sets after that.
For fixing them, just expand idVendor and idProduct fields manually in
AU0828_DEVICE().
This fixes sparse warnings like:
sound/usb/quirks-table.h:2892:1: warning: Initializer entry defined twice
Signed-off-by: Takashi Iwai
Signed-off-by: Sasha Levin
---
sound/usb/quirks-table.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/sound/usb/quirks-table.h b/sound/usb/quirks-table.h
index 69bf5cf1e91e..15cbe2565703 100644
--- a/sound/usb/quirks-table.h
+++ b/sound/usb/quirks-table.h
@@ -2875,7 +2875,8 @@ YAMAHA_DEVICE(0x7010, "UB99"),
*/
#define AU0828_DEVICE(vid, pid, vname, pname) { \
- USB_DEVICE_VENDOR_SPEC(vid, pid), \
+ .idVendor = vid, \
+ .idProduct = pid, \
.match_flags = USB_DEVICE_ID_MATCH_DEVICE | \
USB_DEVICE_ID_MATCH_INT_CLASS | \
USB_DEVICE_ID_MATCH_INT_SUBCLASS, \
--
2.17.1
[PATCH AUTOSEL 4.14 52/67] efi/arm: preserve early mapping of UEFI memory map longer for BGRT
From: Ard Biesheuvel
[ Upstream commit 3ea86495aef2f6de26b7cb1599ba350dd6a0c521 ]
The BGRT code validates the contents of the table against the UEFI
memory map, and so it expects it to be mapped when the code runs.
On ARM, this is currently not the case, since we tear down the early
mapping after efi_init() completes, and only create the permanent
mapping in arm_enable_runtime_services(), which executes as an early
initcall, but still leaves a window where the UEFI memory map is not
mapped.
So move the call to efi_memmap_unmap() from efi_init() to
arm_enable_runtime_services().
Signed-off-by: Ard Biesheuvel
[will: fold in EFI_MEMMAP attribute check from Ard]
Signed-off-by: Will Deacon
Signed-off-by: Sasha Levin
---
drivers/firmware/efi/arm-init.c| 1 -
drivers/firmware/efi/arm-runtime.c | 4 +++-
2 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/firmware/efi/arm-init.c b/drivers/firmware/efi/arm-init.c
index 80d1a885def5..a7c522eac640 100644
--- a/drivers/firmware/efi/arm-init.c
+++ b/drivers/firmware/efi/arm-init.c
@@ -259,7 +259,6 @@ void __init efi_init(void)
reserve_regions();
efi_esrt_init();
- efi_memmap_unmap();
memblock_reserve(params.mmap & PAGE_MASK,
PAGE_ALIGN(params.mmap_size +
diff --git a/drivers/firmware/efi/arm-runtime.c
b/drivers/firmware/efi/arm-runtime.c
index 86a1ad17a32e..8995a48bd067 100644
--- a/drivers/firmware/efi/arm-runtime.c
+++ b/drivers/firmware/efi/arm-runtime.c
@@ -122,11 +122,13 @@ static int __init arm_enable_runtime_services(void)
{
u64 mapsize;
- if (!efi_enabled(EFI_BOOT)) {
+ if (!efi_enabled(EFI_BOOT) || !efi_enabled(EFI_MEMMAP)) {
pr_info("EFI services will not be available.\n");
return 0;
}
+ efi_memmap_unmap();
+
if (efi_runtime_disabled()) {
pr_info("EFI runtime services will be disabled.\n");
return 0;
--
2.17.1
[PATCH AUTOSEL 4.14 50/67] arm64: fix possible spectre-v1 write in ptrace_hbp_set_event()
From: Mark Rutland
[ Upstream commit 14d6e289a89780377f8bb09de8926d3c62d763cd ]
It's possible for userspace to control idx. Sanitize idx when using it
as an array index, to inhibit the potential spectre-v1 write gadget.
Found by smatch.
Signed-off-by: Mark Rutland
Cc: Catalin Marinas
Cc: Will Deacon
Signed-off-by: Will Deacon
Signed-off-by: Sasha Levin
---
arch/arm64/kernel/ptrace.c | 19 +++
1 file changed, 11 insertions(+), 8 deletions(-)
diff --git a/arch/arm64/kernel/ptrace.c b/arch/arm64/kernel/ptrace.c
index edaf346d13d5..34d915b6974b 100644
--- a/arch/arm64/kernel/ptrace.c
+++ b/arch/arm64/kernel/ptrace.c
@@ -274,19 +274,22 @@ static int ptrace_hbp_set_event(unsigned int note_type,
switch (note_type) {
case NT_ARM_HW_BREAK:
- if (idx < ARM_MAX_BRP) {
- tsk->thread.debug.hbp_break[idx] = bp;
- err = 0;
- }
+ if (idx >= ARM_MAX_BRP)
+ goto out;
+ idx = array_index_nospec(idx, ARM_MAX_BRP);
+ tsk->thread.debug.hbp_break[idx] = bp;
+ err = 0;
break;
case NT_ARM_HW_WATCH:
- if (idx < ARM_MAX_WRP) {
- tsk->thread.debug.hbp_watch[idx] = bp;
- err = 0;
- }
+ if (idx >= ARM_MAX_WRP)
+ goto out;
+ idx = array_index_nospec(idx, ARM_MAX_WRP);
+ tsk->thread.debug.hbp_watch[idx] = bp;
+ err = 0;
break;
}
+out:
return err;
}
--
2.17.1
[PATCH AUTOSEL 4.9 07/43] clk: imx6ul: fix missing of_node_put()
From: Nicholas Mc Guire
[ Upstream commit 11177e7a7aaef95935592072985526ebf0a3df43 ]
of_find_compatible_node() is returning a device node with refcount
incremented and must be explicitly decremented after the last use
which is right after the us in of_iomap() here.
Signed-off-by: Nicholas Mc Guire
Fixes: 787b4271a6a0 ("clk: imx: add imx6ul clk tree support")
Signed-off-by: Stephen Boyd
Signed-off-by: Sasha Levin
---
drivers/clk/imx/clk-imx6ul.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/clk/imx/clk-imx6ul.c b/drivers/clk/imx/clk-imx6ul.c
index d1d7787ce211..db2901646403 100644
--- a/drivers/clk/imx/clk-imx6ul.c
+++ b/drivers/clk/imx/clk-imx6ul.c
@@ -120,6 +120,7 @@ static void __init imx6ul_clocks_init(struct device_node
*ccm_node)
np = of_find_compatible_node(NULL, NULL, "fsl,imx6ul-anatop");
base = of_iomap(np, 0);
+ of_node_put(np);
WARN_ON(!base);
clks[IMX6UL_PLL1_BYPASS_SRC] = imx_clk_mux("pll1_bypass_src", base +
0x00, 14, 1, pll_bypass_src_sels, ARRAY_SIZE(pll_bypass_src_sels));
--
2.17.1
[PATCH AUTOSEL 4.9 09/43] kbuild: add .DELETE_ON_ERROR special target
From: Masahiro Yamada [ Upstream commit 9c2af1c7377a8a6ef86e5cabf80978f3dbbb25c0 ] If Make gets a fatal signal while a shell is executing, it may delete the target file that the recipe was supposed to update. This is needed to make sure that it is remade from scratch when Make is next run; if Make is interrupted after the recipe has begun to write the target file, it results in an incomplete file whose time stamp is newer than that of the prerequisites files. Make automatically deletes the incomplete file on interrupt unless the target is marked .PRECIOUS. The situation is just the same as when the shell fails for some reasons. Usually when a recipe line fails, if it has changed the target file at all, the file is corrupted, or at least it is not completely updated. Yet the file’s time stamp says that it is now up to date, so the next time Make runs, it will not try to update that file. However, Make does not cater to delete the incomplete target file in this case. We need to add .DELETE_ON_ERROR somewhere in the Makefile to request it. scripts/Kbuild.include seems a suitable place to add it because it is included from almost all sub-makes. Please note .DELETE_ON_ERROR is not effective for phony targets. The external module building should never ever touch the kernel tree. The following recipe fails if include/generated/autoconf.h is missing. However, include/config/auto.conf is not deleted since it is a phony target. PHONY += include/config/auto.conf include/config/auto.conf: $(Q)test -e include/generated/autoconf.h -a -e $@ || ( \ echo >&2; \ echo >&2 " ERROR: Kernel configuration is invalid."; \ echo >&2 " include/generated/autoconf.h or $@ are missing.";\ echo >&2 " Run 'make oldconfig && make prepare' on kernel src to fix it."; \ echo >&2 ; \ /bin/false) Signed-off-by: Masahiro Yamada Signed-off-by: Sasha Levin --- scripts/Kbuild.include | 3 +++ 1 file changed, 3 insertions(+) diff --git a/scripts/Kbuild.include b/scripts/Kbuild.include index 63774307a751..8f8965608ee3 100644 --- a/scripts/Kbuild.include +++ b/scripts/Kbuild.include @@ -394,3 +394,6 @@ endif endef # ### + +# delete partially updated (i.e. corrupted) files on error +.DELETE_ON_ERROR: -- 2.17.1
Re: [PATCH v13 11/13] platform/x86: Intel SGX driver
On Thu, 2018-09-06 at 19:35 +0200, Miguel Ojeda wrote:
> > Which one is right and why the kernel tree is polluted with C99-headers
> > when they do not pass checkpatch.pl?
checkpatch ignores c99 headers since 2016.
$ git log --stat -p -1 dadf680de3c2eb4cba9840619991eda0cfe98778
commit dadf680de3c2eb4cba9840619991eda0cfe98778
Author: Joe Perches
Date: Tue Aug 2 14:04:33 2016 -0700
checkpatch: allow c99 style // comments
Sanitise the lines that contain c99 comments so that the error doesn't
get emitted.
Link:
http://lkml.kernel.org/r/d4d22c34ad7bcc1bceb52f0742f76b7a6d585235.1468368420.git@perches.com
Signed-off-by: Joe Perches
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
---
scripts/checkpatch.pl | 6 ++
1 file changed, 6 insertions(+)
diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index a4476b61e93f..79273003d5e7 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -55,6 +55,7 @@ my $spelling_file = "$D/spelling.txt";
my $codespell = 0;
my $codespellfile = "/usr/share/codespell/dictionary.txt";
my $color = 1;
+my $allow_c99_comments = 1;
sub help {
my ($exitcode) = @_;
@@ -1144,6 +1145,11 @@ sub sanitise_line {
$res =~ s@(\#\s*(?:error|warning)\s+).*@$1$clean@;
}
+ if ($allow_c99_comments && $res =~ m@(//.*$)@) {
+ my $match = $1;
+ $res =~ s/\Q$match\E/"$;" x length($match)/e;
+ }
+
return $res;
}
[PATCH AUTOSEL 4.14 37/67] fbdev: Distinguish between interlaced and progressive modes
From: Fredrik Noring
[ Upstream commit 1ba0a59cea41ea05fda92daaf2a2958a2246b9cf ]
I discovered the problem when developing a frame buffer driver for the
PlayStation 2 (not yet merged), using the following video modes for the
PlayStation 3 in drivers/video/fbdev/ps3fb.c:
}, {
/* 1080if */
"1080if", 50, 1920, 1080, 13468, 148, 484, 36, 4, 88, 5,
FB_SYNC_BROADCAST, FB_VMODE_INTERLACED
}, {
/* 1080pf */
"1080pf", 50, 1920, 1080, 6734, 148, 484, 36, 4, 88, 5,
FB_SYNC_BROADCAST, FB_VMODE_NONINTERLACED
},
In ps3fb_probe, the mode_option module parameter is used with fb_find_mode
but it can only select the interlaced variant of 1920x1080 since the loop
matching the modes does not take the difference between interlaced and
progressive modes into account.
In short, without the patch, progressive 1920x1080 cannot be chosen as a
mode_option parameter since fb_find_mode (falsely) thinks interlace is a
perfect match.
Signed-off-by: Fredrik Noring
Cc: "Maciej W. Rozycki"
[b.zolnierkie: updated patch description]
Signed-off-by: Bartlomiej Zolnierkiewicz
Signed-off-by: Sasha Levin
---
drivers/video/fbdev/core/modedb.c | 41 ++-
1 file changed, 30 insertions(+), 11 deletions(-)
diff --git a/drivers/video/fbdev/core/modedb.c
b/drivers/video/fbdev/core/modedb.c
index 2510fa728d77..de119f11b78f 100644
--- a/drivers/video/fbdev/core/modedb.c
+++ b/drivers/video/fbdev/core/modedb.c
@@ -644,7 +644,7 @@ static int fb_try_mode(struct fb_var_screeninfo *var,
struct fb_info *info,
*
* Valid mode specifiers for @mode_option:
*
- * x[M][R][-][@][i][m] or
+ * x[M][R][-][@][i][p][m] or
* [-][@]
*
* with , , and decimal numbers and
@@ -653,10 +653,10 @@ static int fb_try_mode(struct fb_var_screeninfo *var,
struct fb_info *info,
* If 'M' is present after yres (and before refresh/bpp if present),
* the function will compute the timings using VESA(tm) Coordinated
* Video Timings (CVT). If 'R' is present after 'M', will compute with
- * reduced blanking (for flatpanels). If 'i' is present, compute
- * interlaced mode. If 'm' is present, add margins equal to 1.8%
- * of xres rounded down to 8 pixels, and 1.8% of yres. The char
- * 'i' and 'm' must be after 'M' and 'R'. Example:
+ * reduced blanking (for flatpanels). If 'i' or 'p' are present, compute
+ * interlaced or progressive mode. If 'm' is present, add margins equal
+ * to 1.8% of xres rounded down to 8 pixels, and 1.8% of yres. The chars
+ * 'i', 'p' and 'm' must be after 'M' and 'R'. Example:
*
* 1024x768MR-8@60m - Reduced blank with margins at 60Hz.
*
@@ -697,7 +697,8 @@ int fb_find_mode(struct fb_var_screeninfo *var,
unsigned int namelen = strlen(name);
int res_specified = 0, bpp_specified = 0, refresh_specified = 0;
unsigned int xres = 0, yres = 0, bpp = default_bpp, refresh = 0;
- int yres_specified = 0, cvt = 0, rb = 0, interlace = 0;
+ int yres_specified = 0, cvt = 0, rb = 0;
+ int interlace_specified = 0, interlace = 0;
int margins = 0;
u32 best, diff, tdiff;
@@ -748,9 +749,17 @@ int fb_find_mode(struct fb_var_screeninfo *var,
if (!cvt)
margins = 1;
break;
+ case 'p':
+ if (!cvt) {
+ interlace = 0;
+ interlace_specified = 1;
+ }
+ break;
case 'i':
- if (!cvt)
+ if (!cvt) {
interlace = 1;
+ interlace_specified = 1;
+ }
break;
default:
goto done;
@@ -819,11 +828,21 @@ int fb_find_mode(struct fb_var_screeninfo *var,
if ((name_matches(db[i], name, namelen) ||
(res_specified && res_matches(db[i], xres, yres)))
&&
!fb_try_mode(var, info, [i], bpp)) {
- if (refresh_specified && db[i].refresh ==
refresh)
- return 1;
+ const int db_interlace = (db[i].vmode &
+ FB_VMODE_INTERLACED ? 1 : 0);
+ int score = abs(db[i].refresh - refresh);
+
+ if (interlace_specified)
+ score += abs(db_interlace - interlace);
+
+ if (!interlace_specified ||
+
[PATCH AUTOSEL 4.14 31/67] fbdev: omapfb: off by one in omapfb_register_client()
From: Dan Carpenter
[ Upstream commit 5ec1ec35b2979b59d0b33381e7c9aac17e159d16 ]
The omapfb_register_client[] array has OMAPFB_PLANE_NUM elements so the
> should be >= or we are one element beyond the end of the array.
Fixes: 8b08cf2b64f5 ("OMAP: add TI OMAP framebuffer driver")
Signed-off-by: Dan Carpenter
Cc: Imre Deak
Signed-off-by: Bartlomiej Zolnierkiewicz
Signed-off-by: Sasha Levin
---
drivers/video/fbdev/omap/omapfb_main.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/video/fbdev/omap/omapfb_main.c
b/drivers/video/fbdev/omap/omapfb_main.c
index 3479a47a3082..0eee8a29d28d 100644
--- a/drivers/video/fbdev/omap/omapfb_main.c
+++ b/drivers/video/fbdev/omap/omapfb_main.c
@@ -958,7 +958,7 @@ int omapfb_register_client(struct omapfb_notifier_block
*omapfb_nb,
{
int r;
- if ((unsigned)omapfb_nb->plane_idx > OMAPFB_PLANE_NUM)
+ if ((unsigned)omapfb_nb->plane_idx >= OMAPFB_PLANE_NUM)
return -EINVAL;
if (!notifier_inited) {
--
2.17.1
[PATCH AUTOSEL 4.14 42/67] powerpc/powernv: opal_put_chars partial write fix
From: Nicholas Piggin
[ Upstream commit bd90284cc6c1c9e8e48c8eadd0c79574fcce0b81 ]
The intention here is to consume and discard the remaining buffer
upon error. This works if there has not been a previous partial write.
If there has been, then total_len is no longer total number of bytes
to copy. total_len is always "bytes left to copy", so it should be
added to written bytes.
This code may not be exercised any more if partial writes will not be
hit, but this is a small bugfix before a larger change.
Reviewed-by: Benjamin Herrenschmidt
Signed-off-by: Nicholas Piggin
Signed-off-by: Michael Ellerman
Signed-off-by: Sasha Levin
---
arch/powerpc/platforms/powernv/opal.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/platforms/powernv/opal.c
b/arch/powerpc/platforms/powernv/opal.c
index 65c79ecf5a4d..c8a743af6bf5 100644
--- a/arch/powerpc/platforms/powernv/opal.c
+++ b/arch/powerpc/platforms/powernv/opal.c
@@ -388,7 +388,7 @@ int opal_put_chars(uint32_t vtermno, const char *data, int
total_len)
/* Closed or other error drop */
if (rc != OPAL_SUCCESS && rc != OPAL_BUSY &&
rc != OPAL_BUSY_EVENT) {
- written = total_len;
+ written += total_len;
break;
}
if (rc == OPAL_SUCCESS) {
--
2.17.1
[PATCH AUTOSEL 4.9 14/43] IB/rxe: Drop QP0 silently
From: Zhu Yanjun
[ Upstream commit 536ca245c512aedfd84cde072d7b3ca14b6e1792 ]
According to "Annex A16: RDMA over Converged Ethernet (RoCE)":
A16.4.3 MANAGEMENT INTERFACES
As defined in the base specification, a special Queue Pair, QP0 is defined
solely for communication between subnet manager(s) and subnet management
agents. Since such an IB-defined subnet management architecture is outside
the scope of this annex, it follows that there is also no requirement that
a port which conforms to this annex be associated with a QP0. Thus, for
end nodes designed to conform to this annex, the concept of QP0 is
undefined and unused for any port connected to an Ethernet network.
CA16-8: A packet arriving at a RoCE port containing a BTH with the
destination QP field set to QP0 shall be silently dropped.
Signed-off-by: Zhu Yanjun
Acked-by: Moni Shoua
Reviewed-by: Yuval Shaia
Signed-off-by: Jason Gunthorpe
Signed-off-by: Sasha Levin
---
drivers/infiniband/sw/rxe/rxe_recv.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/infiniband/sw/rxe/rxe_recv.c
b/drivers/infiniband/sw/rxe/rxe_recv.c
index 46f062842a9a..db6bb026ae90 100644
--- a/drivers/infiniband/sw/rxe/rxe_recv.c
+++ b/drivers/infiniband/sw/rxe/rxe_recv.c
@@ -225,9 +225,14 @@ static int hdr_check(struct rxe_pkt_info *pkt)
goto err1;
}
+ if (unlikely(qpn == 0)) {
+ pr_warn_once("QP 0 not supported");
+ goto err1;
+ }
+
if (qpn != IB_MULTICAST_QPN) {
- index = (qpn == 0) ? port->qp_smi_index :
- ((qpn == 1) ? port->qp_gsi_index : qpn);
+ index = (qpn == 1) ? port->qp_gsi_index : qpn;
+
qp = rxe_pool_get_index(>qp_pool, index);
if (unlikely(!qp)) {
pr_warn_ratelimited("no qp matches qpn 0x%x\n", qpn);
--
2.17.1
[PATCH AUTOSEL 4.9 11/43] dmaengine: pl330: fix irq race with terminate_all
From: John Keeping [ Upstream commit e49756544a21f5625b379b3871d27d8500764670 ] In pl330_update() when checking if a channel has been aborted, the channel's lock is not taken, only the overall pl330_dmac lock. But in pl330_terminate_all() the aborted flag (req_running==-1) is set under the channel lock and not the pl330_dmac lock. With threaded interrupts, this leads to a potential race: pl330_terminate_all pl330_update --- lock channel entry lock pl330 _stop channel unlock pl330 lock pl330 check req_running != -1 req_running = -1 _start channel Signed-off-by: John Keeping Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin --- drivers/dma/pl330.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/dma/pl330.c b/drivers/dma/pl330.c index b9dad4e40bb8..6d7e3cd4aba4 100644 --- a/drivers/dma/pl330.c +++ b/drivers/dma/pl330.c @@ -2167,13 +2167,14 @@ static int pl330_terminate_all(struct dma_chan *chan) pm_runtime_get_sync(pl330->ddma.dev); spin_lock_irqsave(>lock, flags); + spin_lock(>lock); _stop(pch->thread); - spin_unlock(>lock); - pch->thread->req[0].desc = NULL; pch->thread->req[1].desc = NULL; pch->thread->req_running = -1; + spin_unlock(>lock); + power_down = pch->active; pch->active = false; -- 2.17.1
[PATCH AUTOSEL 4.9 02/43] iommu/arm-smmu-v3: sync the OVACKFLG to PRIQ consumer register
From: Miao Zhong [ Upstream commit 0d535967ac658966c6ade8f82b5799092f7d5441 ] When PRI queue occurs overflow, driver should update the OVACKFLG to the PRIQ consumer register, otherwise subsequent PRI requests will not be processed. Cc: Will Deacon Cc: Robin Murphy Signed-off-by: Miao Zhong Signed-off-by: Will Deacon Signed-off-by: Sasha Levin --- drivers/iommu/arm-smmu-v3.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/iommu/arm-smmu-v3.c b/drivers/iommu/arm-smmu-v3.c index 7f294f785ce6..ff4be1174ff0 100644 --- a/drivers/iommu/arm-smmu-v3.c +++ b/drivers/iommu/arm-smmu-v3.c @@ -1233,6 +1233,7 @@ static irqreturn_t arm_smmu_priq_thread(int irq, void *dev) /* Sync our overflow flag, as we believe we're up to speed */ q->cons = Q_OVF(q, q->prod) | Q_WRP(q, q->cons) | Q_IDX(q, q->cons); + writel(q->cons, q->cons_reg); return IRQ_HANDLED; } -- 2.17.1
[PATCH AUTOSEL 4.9 13/43] media: videobuf2-core: check for q->error in vb2_core_qbuf()
From: Hans Verkuil
[ Upstream commit b509d733d337417bcb7fa4a35be3b9a49332b724 ]
The vb2_core_qbuf() function didn't check if q->error was set. It is
checked in __buf_prepare(), but that function isn't called if the buffer
was already prepared before with VIDIOC_PREPARE_BUF.
So check it at the start of vb2_core_qbuf() as well.
Signed-off-by: Hans Verkuil
Acked-by: Sakari Ailus
Signed-off-by: Hans Verkuil
Signed-off-by: Mauro Carvalho Chehab
Signed-off-by: Sasha Levin
---
drivers/media/v4l2-core/videobuf2-core.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/media/v4l2-core/videobuf2-core.c
b/drivers/media/v4l2-core/videobuf2-core.c
index b3a9fa75e8e7..f7ca1fab4808 100644
--- a/drivers/media/v4l2-core/videobuf2-core.c
+++ b/drivers/media/v4l2-core/videobuf2-core.c
@@ -1375,6 +1375,11 @@ int vb2_core_qbuf(struct vb2_queue *q, unsigned int
index, void *pb)
struct vb2_buffer *vb;
int ret;
+ if (q->error) {
+ dprintk(1, "fatal error occurred on queue\n");
+ return -EIO;
+ }
+
vb = q->bufs[index];
switch (vb->state) {
--
2.17.1
[PATCH AUTOSEL 4.9 03/43] ALSA: msnd: Fix the default sample sizes
From: Takashi Iwai
[ Upstream commit 7c500f9ea139d0c9b80fdea5a9c911db3166ea54 ]
The default sample sizes set by msnd driver are bogus; it sets ALSA
PCM format, not the actual bit width.
Signed-off-by: Takashi Iwai
Signed-off-by: Sasha Levin
---
sound/isa/msnd/msnd_pinnacle.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/sound/isa/msnd/msnd_pinnacle.c b/sound/isa/msnd/msnd_pinnacle.c
index a31ea6c22d19..2d7379dec1f0 100644
--- a/sound/isa/msnd/msnd_pinnacle.c
+++ b/sound/isa/msnd/msnd_pinnacle.c
@@ -82,10 +82,10 @@
static void set_default_audio_parameters(struct snd_msnd *chip)
{
- chip->play_sample_size = DEFSAMPLESIZE;
+ chip->play_sample_size = snd_pcm_format_width(DEFSAMPLESIZE);
chip->play_sample_rate = DEFSAMPLERATE;
chip->play_channels = DEFCHANNELS;
- chip->capture_sample_size = DEFSAMPLESIZE;
+ chip->capture_sample_size = snd_pcm_format_width(DEFSAMPLESIZE);
chip->capture_sample_rate = DEFSAMPLERATE;
chip->capture_channels = DEFCHANNELS;
}
--
2.17.1
[PATCH AUTOSEL 4.9 08/43] clk: clk-fixed-factor: Clear OF_POPULATED flag in case of failure
From: Rajan Vaja
[ Upstream commit f6dab4233d6b64d719109040503b567f71fbfa01 ]
Fixed factor clock has two initializations at of_clk_init() time
and during platform driver probe. Before of_clk_init() call,
node is marked as populated and so its probe never gets called.
During of_clk_init() fixed factor clock registration may fail if
any of its parent clock is not registered. In this case, it doesn't
get chance to retry registration from probe. Clear OF_POPULATED
flag if fixed factor clock registration fails so that clock
registration is attempted again from probe.
Signed-off-by: Rajan Vaja
Signed-off-by: Stephen Boyd
Signed-off-by: Sasha Levin
---
drivers/clk/clk-fixed-factor.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/clk/clk-fixed-factor.c b/drivers/clk/clk-fixed-factor.c
index a5d402de5584..20724abd38bd 100644
--- a/drivers/clk/clk-fixed-factor.c
+++ b/drivers/clk/clk-fixed-factor.c
@@ -177,8 +177,15 @@ static struct clk *_of_fixed_factor_clk_setup(struct
device_node *node)
clk = clk_register_fixed_factor(NULL, clk_name, parent_name, flags,
mult, div);
- if (IS_ERR(clk))
+ if (IS_ERR(clk)) {
+ /*
+* If parent clock is not registered, registration would fail.
+* Clear OF_POPULATED flag so that clock registration can be
+* attempted again from probe function.
+*/
+ of_node_clear_flag(node, OF_POPULATED);
return clk;
+ }
ret = of_clk_add_provider(node, of_clk_src_simple_get, clk);
if (ret) {
--
2.17.1
[PATCH AUTOSEL 4.14 67/67] x86/mm/pti: Add an overflow check to pti_clone_pmds()
From: Joerg Roedel [ Upstream commit 935232ce28dfabff1171e5a7113b2d865fa9ee63 ] The addr counter will overflow if the last PMD of the address space is cloned, resulting in an endless loop. Check for that and bail out of the loop when it happens. Signed-off-by: Joerg Roedel Signed-off-by: Thomas Gleixner Tested-by: Pavel Machek Cc: "H . Peter Anvin" Cc: linux...@kvack.org Cc: Linus Torvalds Cc: Andy Lutomirski Cc: Dave Hansen Cc: Josh Poimboeuf Cc: Juergen Gross Cc: Peter Zijlstra Cc: Borislav Petkov Cc: Jiri Kosina Cc: Boris Ostrovsky Cc: Brian Gerst Cc: David Laight Cc: Denys Vlasenko Cc: Eduardo Valentin Cc: Greg KH Cc: Will Deacon Cc: aligu...@amazon.com Cc: daniel.gr...@iaik.tugraz.at Cc: hu...@google.com Cc: keesc...@google.com Cc: Andrea Arcangeli Cc: Waiman Long Cc: "David H . Gutteridge" Cc: j...@8bytes.org Link: https://lkml.kernel.org/r/1531906876-13451-25-git-send-email-j...@8bytes.org Signed-off-by: Sasha Levin --- arch/x86/mm/pti.c | 4 1 file changed, 4 insertions(+) diff --git a/arch/x86/mm/pti.c b/arch/x86/mm/pti.c index 7786ab306225..b07e3ffc5ac5 100644 --- a/arch/x86/mm/pti.c +++ b/arch/x86/mm/pti.c @@ -291,6 +291,10 @@ pti_clone_pmds(unsigned long start, unsigned long end, pmdval_t clear) p4d_t *p4d; pud_t *pud; + /* Overflow check */ + if (addr < start) + break; + pgd = pgd_offset_k(addr); if (WARN_ON(pgd_none(*pgd))) return; -- 2.17.1
[PATCH AUTOSEL 4.9 05/43] xfrm: fix 'passing zero to ERR_PTR()' warning
From: YueHaibing
[ Upstream commit 934ffce1343f22ed5e2d0bd6da4440f4848074de ]
Fix a static code checker warning:
net/xfrm/xfrm_policy.c:1836 xfrm_resolve_and_create_bundle() warn: passing
zero to 'ERR_PTR'
xfrm_tmpl_resolve return 0 just means no xdst found, return NULL
instead of passing zero to ERR_PTR.
Fixes: d809ec895505 ("xfrm: do not assume that template resolving always
returns xfrms")
Signed-off-by: YueHaibing
Signed-off-by: Steffen Klassert
Signed-off-by: Sasha Levin
---
net/xfrm/xfrm_policy.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/net/xfrm/xfrm_policy.c b/net/xfrm/xfrm_policy.c
index 5b8fa6832687..f02fc03dc964 100644
--- a/net/xfrm/xfrm_policy.c
+++ b/net/xfrm/xfrm_policy.c
@@ -1873,7 +1873,10 @@ xfrm_resolve_and_create_bundle(struct xfrm_policy
**pols, int num_pols,
/* Try to instantiate a bundle */
err = xfrm_tmpl_resolve(pols, num_pols, fl, xfrm, family);
if (err <= 0) {
- if (err != 0 && err != -EAGAIN)
+ if (err == 0)
+ return NULL;
+
+ if (err != -EAGAIN)
XFRM_INC_STATS(net, LINUX_MIB_XFRMOUTPOLERROR);
return ERR_PTR(err);
}
--
2.17.1
[PATCH AUTOSEL 4.14 49/67] wan/fsl_ucc_hdlc: use IS_ERR_VALUE() to check return value of qe_muram_alloc
From: YueHaibing
[ Upstream commit fd800f646402c0f85547166b59ca065175928b7b ]
qe_muram_alloc return a unsigned long integer,which should not
compared with zero. check it using IS_ERR_VALUE() to fix this.
Fixes: c19b6d246a35 ("drivers/net: support hdlc function for QE-UCC")
Signed-off-by: YueHaibing
Signed-off-by: David S. Miller
Signed-off-by: Sasha Levin
---
drivers/net/wan/fsl_ucc_hdlc.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/net/wan/fsl_ucc_hdlc.c b/drivers/net/wan/fsl_ucc_hdlc.c
index 33df76405b86..18b648648adb 100644
--- a/drivers/net/wan/fsl_ucc_hdlc.c
+++ b/drivers/net/wan/fsl_ucc_hdlc.c
@@ -192,7 +192,7 @@ static int uhdlc_init(struct ucc_hdlc_private *priv)
priv->ucc_pram_offset = qe_muram_alloc(sizeof(struct ucc_hdlc_param),
ALIGNMENT_OF_UCC_HDLC_PRAM);
- if (priv->ucc_pram_offset < 0) {
+ if (IS_ERR_VALUE(priv->ucc_pram_offset)) {
dev_err(priv->dev, "Can not allocate MURAM for hdlc
parameter.\n");
ret = -ENOMEM;
goto free_tx_bd;
@@ -228,14 +228,14 @@ static int uhdlc_init(struct ucc_hdlc_private *priv)
/* Alloc riptr, tiptr */
riptr = qe_muram_alloc(32, 32);
- if (riptr < 0) {
+ if (IS_ERR_VALUE(riptr)) {
dev_err(priv->dev, "Cannot allocate MURAM mem for Receive
internal temp data pointer\n");
ret = -ENOMEM;
goto free_tx_skbuff;
}
tiptr = qe_muram_alloc(32, 32);
- if (tiptr < 0) {
+ if (IS_ERR_VALUE(tiptr)) {
dev_err(priv->dev, "Cannot allocate MURAM mem for Transmit
internal temp data pointer\n");
ret = -ENOMEM;
goto free_riptr;
--
2.17.1
[PATCH AUTOSEL 4.14 13/67] clk: core: Potentially free connection id
From: Mikko Perttunen
[ Upstream commit 365f7a89c881e84f1ebc925f65f899d5d7ce547e ]
Patch "clk: core: Copy connection id" made it so that the connector id
'con_id' is kstrdup_const()ed to cater to drivers that pass non-constant
connection ids. The patch added the corresponding kfree_const to
__clk_free_clk(), but struct clk's can be freed also via __clk_put().
Add the kfree_const call to __clk_put() and add comments to both
functions to remind that the logic in them should be kept in sync.
Fixes: 253160a8ad06 ("clk: core: Copy connection id")
Signed-off-by: Mikko Perttunen
Reviewed-by: Leonard Crestez
Signed-off-by: Stephen Boyd
Signed-off-by: Sasha Levin
---
drivers/clk/clk.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
index 6f4c98ca6e50..a3f52f678211 100644
--- a/drivers/clk/clk.c
+++ b/drivers/clk/clk.c
@@ -2557,6 +2557,7 @@ struct clk *__clk_create_clk(struct clk_hw *hw, const
char *dev_id,
return clk;
}
+/* keep in sync with __clk_put */
void __clk_free_clk(struct clk *clk)
{
clk_prepare_lock();
@@ -2922,6 +2923,7 @@ int __clk_get(struct clk *clk)
return 1;
}
+/* keep in sync with __clk_free_clk */
void __clk_put(struct clk *clk)
{
struct module *owner;
@@ -2943,6 +2945,7 @@ void __clk_put(struct clk *clk)
module_put(owner);
+ kfree_const(clk->con_id);
kfree(clk);
}
--
2.17.1
[PATCH AUTOSEL 4.14 14/67] clk: clk-fixed-factor: Clear OF_POPULATED flag in case of failure
From: Rajan Vaja
[ Upstream commit f6dab4233d6b64d719109040503b567f71fbfa01 ]
Fixed factor clock has two initializations at of_clk_init() time
and during platform driver probe. Before of_clk_init() call,
node is marked as populated and so its probe never gets called.
During of_clk_init() fixed factor clock registration may fail if
any of its parent clock is not registered. In this case, it doesn't
get chance to retry registration from probe. Clear OF_POPULATED
flag if fixed factor clock registration fails so that clock
registration is attempted again from probe.
Signed-off-by: Rajan Vaja
Signed-off-by: Stephen Boyd
Signed-off-by: Sasha Levin
---
drivers/clk/clk-fixed-factor.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/clk/clk-fixed-factor.c b/drivers/clk/clk-fixed-factor.c
index a5d402de5584..20724abd38bd 100644
--- a/drivers/clk/clk-fixed-factor.c
+++ b/drivers/clk/clk-fixed-factor.c
@@ -177,8 +177,15 @@ static struct clk *_of_fixed_factor_clk_setup(struct
device_node *node)
clk = clk_register_fixed_factor(NULL, clk_name, parent_name, flags,
mult, div);
- if (IS_ERR(clk))
+ if (IS_ERR(clk)) {
+ /*
+* If parent clock is not registered, registration would fail.
+* Clear OF_POPULATED flag so that clock registration can be
+* attempted again from probe function.
+*/
+ of_node_clear_flag(node, OF_POPULATED);
return clk;
+ }
ret = of_clk_add_provider(node, of_clk_src_simple_get, clk);
if (ret) {
--
2.17.1
[PATCH AUTOSEL 4.14 11/67] gfs2: Special-case rindex for gfs2_grow
From: Andreas Gruenbacher [ Upstream commit 776125785a87ff05d49938bd5b9f336f2a05bff6 ] To speed up the common case of appending to a file, gfs2_write_alloc_required presumes that writing beyond the end of a file will always require additional blocks to be allocated. This assumption is incorrect for preallocates files, but there are no negative consequences as long as *some* space is still left on the filesystem. One special file that always has some space preallocated beyond the end of the file is the rindex: when growing a filesystem, gfs2_grow adds one or more new resource groups and appends records describing those resource groups to the rindex; the preallocated space ensures that this is always possible. However, when a filesystem is completely full, gfs2_write_alloc_required will indicate that an additional allocation is required, and appending the next record to the rindex will fail even though space for that record has already been preallocated. To fix that, skip the incorrect optimization in gfs2_write_alloc_required, but for the rindex only. Other writes to preallocated space beyond the end of the file are still allowed to fail on completely full filesystems. Signed-off-by: Andreas Gruenbacher Reviewed-by: Bob Peterson Signed-off-by: Sasha Levin --- fs/gfs2/bmap.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/gfs2/bmap.c b/fs/gfs2/bmap.c index 3dd0cceefa43..bc8787718feb 100644 --- a/fs/gfs2/bmap.c +++ b/fs/gfs2/bmap.c @@ -1680,7 +1680,7 @@ int gfs2_write_alloc_required(struct gfs2_inode *ip, u64 offset, end_of_file = (i_size_read(>i_inode) + sdp->sd_sb.sb_bsize - 1) >> shift; lblock = offset >> shift; lblock_stop = (offset + len + sdp->sd_sb.sb_bsize - 1) >> shift; - if (lblock_stop > end_of_file) + if (lblock_stop > end_of_file && ip != GFS2_I(sdp->sd_rindex)) return 1; size = (lblock_stop - lblock) << shift; -- 2.17.1
Re: Plumbers 2018 - Performance and Scalability Microconference
On Thu, Sep 6, 2018 at 2:36 PM Mike Kravetz wrote: > > On 09/05/2018 06:58 PM, Huang, Ying wrote: > > Hi, Christopher, > > > > Christopher Lameter writes: > > > >> On Tue, 4 Sep 2018, Daniel Jordan wrote: > >> > >>> - Promoting huge page usage: With memory sizes becoming ever larger, > >>> huge > >>> pages are becoming more and more important to reduce TLB misses and the > >>> overhead of memory management itself--that is, to make the system scalable > >>> with the memory size. But there are still some remaining gaps that > >>> prevent > >>> huge pages from being deployed in some situations, such as huge page > >>> allocation latency and memory fragmentation. > >> > >> You forgot the major issue that huge pages in the page cache are not > >> supported and thus we have performance issues with fast NVME drives that > >> are now able to do 3Gbytes per sec that are only possible to reach with > >> directio and huge pages. > > > > Yes. That is an important gap for huge page. Although we have huge > > page cache support for tmpfs, we lacks that for normal file systems. > > > >> IMHO the huge page issue is just the reflection of a certain hardware > >> manufacturer inflicting pain for over a decade on its poor users by not > >> supporting larger base page sizes than 4k. No such workarounds needed on > >> platforms that support large sizes. Things just zoom along without > >> contortions necessary to deal with huge pages etc. > >> > >> Can we come up with a 2M base page VM or something? We have possible > >> memory sizes of a couple TB now. That should give us a million or so 2M > >> pages to work with. > > > > That sounds a good idea. Don't know whether someone has tried this. > > IIRC, Hugh Dickins and some others at Google tried going down this path. > There was a brief discussion at LSF/MM. It is something I too would like > to explore in my spare time. Almost: I never tried that path myself, but mentioned that Greg Thelen had. Hugh
[PATCH AUTOSEL 4.14 27/67] ARM: exynos: Define EINT_WAKEUP_MASK registers for S5Pv210 and Exynos5433
From: Krzysztof Kozlowski
[ Upstream commit e5cda42c16d89720c29678f51d95a119490ef7d8 ]
S5Pv210 and Exynos5433/Exynos7 have different address of
EINT_WAKEUP_MASK register. Rename existing S5P_EINT_WAKEUP_MASK to
avoid confusion and add new ones.
Signed-off-by: Krzysztof Kozlowski
Cc: Tomasz Figa
Cc: Sylwester Nawrocki
Acked-by: Tomasz Figa
Tested-by: Marek Szyprowski
Signed-off-by: Sasha Levin
---
arch/arm/mach-exynos/suspend.c | 2 +-
include/linux/soc/samsung/exynos-regs-pmu.h | 6 +-
2 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-exynos/suspend.c b/arch/arm/mach-exynos/suspend.c
index b529ba04ed16..a6a4ba334147 100644
--- a/arch/arm/mach-exynos/suspend.c
+++ b/arch/arm/mach-exynos/suspend.c
@@ -279,7 +279,7 @@ static int exynos5420_cpu_suspend(unsigned long arg)
static void exynos_pm_set_wakeup_mask(void)
{
/* Set wake-up mask registers */
- pmu_raw_writel(exynos_get_eint_wake_mask(), S5P_EINT_WAKEUP_MASK);
+ pmu_raw_writel(exynos_get_eint_wake_mask(), EXYNOS_EINT_WAKEUP_MASK);
pmu_raw_writel(exynos_irqwake_intmask & ~(1 << 31), S5P_WAKEUP_MASK);
}
diff --git a/include/linux/soc/samsung/exynos-regs-pmu.h
b/include/linux/soc/samsung/exynos-regs-pmu.h
index bebdde5dccd6..f248e7e079b7 100644
--- a/include/linux/soc/samsung/exynos-regs-pmu.h
+++ b/include/linux/soc/samsung/exynos-regs-pmu.h
@@ -46,7 +46,7 @@
#define EXYNOS_SWRESET 0x0400
#define S5P_WAKEUP_STAT0x0600
-#define S5P_EINT_WAKEUP_MASK 0x0604
+#define EXYNOS_EINT_WAKEUP_MASK0x0604
#define S5P_WAKEUP_MASK0x0608
#define S5P_WAKEUP_MASK2 0x0614
@@ -184,6 +184,9 @@
#define S5P_CORE_WAKEUP_FROM_LOCAL_CFG (0x3 << 8)
#define S5P_CORE_AUTOWAKEUP_EN (1 << 31)
+/* Only for S5Pv210 */
+#define S5PV210_EINT_WAKEUP_MASK 0xC004
+
/* Only for EXYNOS4210 */
#define S5P_CMU_CLKSTOP_LCD1_LOWPWR0x1154
#define S5P_CMU_RESET_LCD1_LOWPWR 0x1174
@@ -645,6 +648,7 @@
| EXYNOS5420_KFC_USE_STANDBY_WFI3)
/* For EXYNOS5433 */
+#define EXYNOS5433_EINT_WAKEUP_MASK(0x060C)
#define EXYNOS5433_USBHOST30_PHY_CONTROL (0x0728)
#define EXYNOS5433_PAD_RETENTION_AUD_OPTION(0x3028)
#define EXYNOS5433_PAD_RETENTION_MMC2_OPTION (0x30C8)
--
2.17.1
[PATCH AUTOSEL 4.14 17/67] dmaengine: pl330: fix irq race with terminate_all
From: John Keeping [ Upstream commit e49756544a21f5625b379b3871d27d8500764670 ] In pl330_update() when checking if a channel has been aborted, the channel's lock is not taken, only the overall pl330_dmac lock. But in pl330_terminate_all() the aborted flag (req_running==-1) is set under the channel lock and not the pl330_dmac lock. With threaded interrupts, this leads to a potential race: pl330_terminate_all pl330_update --- lock channel entry lock pl330 _stop channel unlock pl330 lock pl330 check req_running != -1 req_running = -1 _start channel Signed-off-by: John Keeping Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin --- drivers/dma/pl330.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/dma/pl330.c b/drivers/dma/pl330.c index d19862f4dc9a..6afd42cfbf5d 100644 --- a/drivers/dma/pl330.c +++ b/drivers/dma/pl330.c @@ -2142,13 +2142,14 @@ static int pl330_terminate_all(struct dma_chan *chan) pm_runtime_get_sync(pl330->ddma.dev); spin_lock_irqsave(>lock, flags); + spin_lock(>lock); _stop(pch->thread); - spin_unlock(>lock); - pch->thread->req[0].desc = NULL; pch->thread->req[1].desc = NULL; pch->thread->req_running = -1; + spin_unlock(>lock); + power_down = pch->active; pch->active = false; -- 2.17.1
[PATCH AUTOSEL 4.14 12/67] clk: imx6ul: fix missing of_node_put()
From: Nicholas Mc Guire
[ Upstream commit 11177e7a7aaef95935592072985526ebf0a3df43 ]
of_find_compatible_node() is returning a device node with refcount
incremented and must be explicitly decremented after the last use
which is right after the us in of_iomap() here.
Signed-off-by: Nicholas Mc Guire
Fixes: 787b4271a6a0 ("clk: imx: add imx6ul clk tree support")
Signed-off-by: Stephen Boyd
Signed-off-by: Sasha Levin
---
drivers/clk/imx/clk-imx6ul.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/clk/imx/clk-imx6ul.c b/drivers/clk/imx/clk-imx6ul.c
index 41c08fc892b9..5cc5ff1b4e1f 100644
--- a/drivers/clk/imx/clk-imx6ul.c
+++ b/drivers/clk/imx/clk-imx6ul.c
@@ -135,6 +135,7 @@ static void __init imx6ul_clocks_init(struct device_node
*ccm_node)
np = of_find_compatible_node(NULL, NULL, "fsl,imx6ul-anatop");
base = of_iomap(np, 0);
+ of_node_put(np);
WARN_ON(!base);
clks[IMX6UL_PLL1_BYPASS_SRC] = imx_clk_mux("pll1_bypass_src", base +
0x00, 14, 1, pll_bypass_src_sels, ARRAY_SIZE(pll_bypass_src_sels));
--
2.17.1
[PATCH AUTOSEL 4.14 05/67] iommu/io-pgtable-arm-v7s: Abort allocation when table address overflows the PTE
From: Jean-Philippe Brucker
[ Upstream commit 29859aeb8a6ea17ba207933a81b6b77b4d4df81a ]
When run on a 64-bit system in selftest, the v7s driver may obtain page
table with physical addresses larger than 32-bit. Level-2 tables are 1KB
and are are allocated with slab, which doesn't accept the GFP_DMA32
flag. Currently map() truncates the address written in the PTE, causing
iova_to_phys() or unmap() to access invalid memory. Kasan reports it as
a use-after-free. To avoid any nasty surprise, test if the physical
address fits in a PTE before returning a new table. 32-bit systems,
which are the main users of this page table format, shouldn't see any
difference.
Signed-off-by: Jean-Philippe Brucker
Signed-off-by: Will Deacon
Signed-off-by: Sasha Levin
---
drivers/iommu/io-pgtable-arm-v7s.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/iommu/io-pgtable-arm-v7s.c
b/drivers/iommu/io-pgtable-arm-v7s.c
index 6961fc393f0b..29b7a6755fcd 100644
--- a/drivers/iommu/io-pgtable-arm-v7s.c
+++ b/drivers/iommu/io-pgtable-arm-v7s.c
@@ -192,6 +192,7 @@ static void *__arm_v7s_alloc_table(int lvl, gfp_t gfp,
{
struct io_pgtable_cfg *cfg = >iop.cfg;
struct device *dev = cfg->iommu_dev;
+ phys_addr_t phys;
dma_addr_t dma;
size_t size = ARM_V7S_TABLE_SIZE(lvl);
void *table = NULL;
@@ -200,6 +201,10 @@ static void *__arm_v7s_alloc_table(int lvl, gfp_t gfp,
table = (void *)__get_dma_pages(__GFP_ZERO, get_order(size));
else if (lvl == 2)
table = kmem_cache_zalloc(data->l2_tables, gfp | GFP_DMA);
+ phys = virt_to_phys(table);
+ if (phys != (arm_v7s_iopte)phys)
+ /* Doesn't fit in PTE */
+ goto out_free;
if (table && !(cfg->quirks & IO_PGTABLE_QUIRK_NO_DMA)) {
dma = dma_map_single(dev, table, size, DMA_TO_DEVICE);
if (dma_mapping_error(dev, dma))
@@ -209,7 +214,7 @@ static void *__arm_v7s_alloc_table(int lvl, gfp_t gfp,
* address directly, so if the DMA layer suggests otherwise by
* translating or truncating them, that bodes very badly...
*/
- if (dma != virt_to_phys(table))
+ if (dma != phys)
goto out_unmap;
}
kmemleak_ignore(table);
--
2.17.1
[PATCH AUTOSEL 4.14 23/67] mtd/maps: fix solutionengine.c printk format warnings
From: Randy Dunlap
[ Upstream commit 1d25e3eeed1d987404e2d2e451eebac8c15cecc1 ]
Fix 2 printk format warnings (this driver is currently only used by
arch/sh/) by using "%pap" instead of "%lx".
Fixes these build warnings:
../drivers/mtd/maps/solutionengine.c: In function 'init_soleng_maps':
../include/linux/kern_levels.h:5:18: warning: format '%lx' expects argument of
type 'long unsigned int', but argument 2 has type 'resource_size_t' {aka
'unsigned int'} [-Wformat=]
../drivers/mtd/maps/solutionengine.c:62:54: note: format string is defined here
printk(KERN_NOTICE "Solution Engine: Flash at 0x%08lx, EPROM at 0x%08lx\n",
^
%08x
../include/linux/kern_levels.h:5:18: warning: format '%lx' expects argument of
type 'long unsigned int', but argument 3 has type 'resource_size_t' {aka
'unsigned int'} [-Wformat=]
../drivers/mtd/maps/solutionengine.c:62:72: note: format string is defined here
printk(KERN_NOTICE "Solution Engine: Flash at 0x%08lx, EPROM at 0x%08lx\n",
^
%08x
Cc: David Woodhouse
Cc: Brian Norris
Cc: Boris Brezillon
Cc: Marek Vasut
Cc: Richard Weinberger
Cc: linux-...@lists.infradead.org
Cc: Yoshinori Sato
Cc: Rich Felker
Cc: linux...@vger.kernel.org
Cc: Sergei Shtylyov
Signed-off-by: Randy Dunlap
Signed-off-by: Boris Brezillon
Signed-off-by: Sasha Levin
---
drivers/mtd/maps/solutionengine.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/mtd/maps/solutionengine.c
b/drivers/mtd/maps/solutionengine.c
index bb580bc16445..c07f21b20463 100644
--- a/drivers/mtd/maps/solutionengine.c
+++ b/drivers/mtd/maps/solutionengine.c
@@ -59,9 +59,9 @@ static int __init init_soleng_maps(void)
return -ENXIO;
}
}
- printk(KERN_NOTICE "Solution Engine: Flash at 0x%08lx, EPROM at
0x%08lx\n",
- soleng_flash_map.phys & 0x1fff,
- soleng_eprom_map.phys & 0x1fff);
+ printk(KERN_NOTICE "Solution Engine: Flash at 0x%pap, EPROM at
0x%pap\n",
+ _flash_map.phys,
+ _eprom_map.phys);
flash_mtd->owner = THIS_MODULE;
eprom_mtd = do_map_probe("map_rom", _eprom_map);
--
2.17.1
