* [PATCH 1/2] coresight: tmc: Make memory width mask computation into a function
From: Mathieu Poirier @ 2019-08-22 22:09 UTC (permalink / raw)
To: yabinc, suzuki.poulose, leo.yan
Cc: mike.leach, alexander.shishkin, linux-arm-kernel, linux-kernel
In-Reply-To: <20190822220915.8876-1-mathieu.poirier@linaro.org>
Make the computation of a memory ask representing the width of the memory
bus into a function so that it can be re-used by the ETR driver.
Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
---
.../hwtracing/coresight/coresight-tmc-etf.c | 23 ++-------------
drivers/hwtracing/coresight/coresight-tmc.c | 28 +++++++++++++++++++
drivers/hwtracing/coresight/coresight-tmc.h | 1 +
3 files changed, 31 insertions(+), 21 deletions(-)
diff --git a/drivers/hwtracing/coresight/coresight-tmc-etf.c b/drivers/hwtracing/coresight/coresight-tmc-etf.c
index 23b7ff00af5c..807416b75ecc 100644
--- a/drivers/hwtracing/coresight/coresight-tmc-etf.c
+++ b/drivers/hwtracing/coresight/coresight-tmc-etf.c
@@ -479,30 +479,11 @@ static unsigned long tmc_update_etf_buffer(struct coresight_device *csdev,
* traces.
*/
if (!buf->snapshot && to_read > handle->size) {
- u32 mask = 0;
-
- /*
- * The value written to RRP must be byte-address aligned to
- * the width of the trace memory databus _and_ to a frame
- * boundary (16 byte), whichever is the biggest. For example,
- * for 32-bit, 64-bit and 128-bit wide trace memory, the four
- * LSBs must be 0s. For 256-bit wide trace memory, the five
- * LSBs must be 0s.
- */
- switch (drvdata->memwidth) {
- case TMC_MEM_INTF_WIDTH_32BITS:
- case TMC_MEM_INTF_WIDTH_64BITS:
- case TMC_MEM_INTF_WIDTH_128BITS:
- mask = GENMASK(31, 4);
- break;
- case TMC_MEM_INTF_WIDTH_256BITS:
- mask = GENMASK(31, 5);
- break;
- }
+ u32 mask = tmc_get_memwidth_mask(drvdata);
/*
* Make sure the new size is aligned in accordance with the
- * requirement explained above.
+ * requirement explained in function tmc_get_memwidth_mask().
*/
to_read = handle->size & mask;
/* Move the RAM read pointer up */
diff --git a/drivers/hwtracing/coresight/coresight-tmc.c b/drivers/hwtracing/coresight/coresight-tmc.c
index 3055bf8e2236..1cf82fa58289 100644
--- a/drivers/hwtracing/coresight/coresight-tmc.c
+++ b/drivers/hwtracing/coresight/coresight-tmc.c
@@ -70,6 +70,34 @@ void tmc_disable_hw(struct tmc_drvdata *drvdata)
writel_relaxed(0x0, drvdata->base + TMC_CTL);
}
+u32 tmc_get_memwidth_mask(struct tmc_drvdata *drvdata)
+{
+ u32 mask = 0;
+
+ /*
+ * When moving RRP or an offset address forward, the new values must
+ * be byte-address aligned to the width of the trace memory databus
+ * _and_ to a frame boundary (16 byte), whichever is the biggest. For
+ * example, for 32-bit, 64-bit and 128-bit wide trace memory, the four
+ * LSBs must be 0s. For 256-bit wide trace memory, the five LSBs must
+ * be 0s.
+ */
+ switch (drvdata->memwidth) {
+ case TMC_MEM_INTF_WIDTH_32BITS:
+ /* fallthrough */
+ case TMC_MEM_INTF_WIDTH_64BITS:
+ /* fallthrough */
+ case TMC_MEM_INTF_WIDTH_128BITS:
+ mask = GENMASK(31, 4);
+ break;
+ case TMC_MEM_INTF_WIDTH_256BITS:
+ mask = GENMASK(31, 5);
+ break;
+ }
+
+ return mask;
+}
+
static int tmc_read_prepare(struct tmc_drvdata *drvdata)
{
int ret = 0;
diff --git a/drivers/hwtracing/coresight/coresight-tmc.h b/drivers/hwtracing/coresight/coresight-tmc.h
index 9dbcdf453e22..71de978575f3 100644
--- a/drivers/hwtracing/coresight/coresight-tmc.h
+++ b/drivers/hwtracing/coresight/coresight-tmc.h
@@ -255,6 +255,7 @@ void tmc_wait_for_tmcready(struct tmc_drvdata *drvdata);
void tmc_flush_and_stop(struct tmc_drvdata *drvdata);
void tmc_enable_hw(struct tmc_drvdata *drvdata);
void tmc_disable_hw(struct tmc_drvdata *drvdata);
+u32 tmc_get_memwidth_mask(struct tmc_drvdata *drvdata);
/* ETB/ETF functions */
int tmc_read_prepare_etb(struct tmc_drvdata *drvdata);
--
2.17.1
^ permalink raw reply related
* [PATCH 2/2] coresight: tmc-etr: Add barrier packet when moving offset forward
From: Mathieu Poirier @ 2019-08-22 22:09 UTC (permalink / raw)
To: yabinc, suzuki.poulose, leo.yan
Cc: mike.leach, alexander.shishkin, linux-arm-kernel, linux-kernel
In-Reply-To: <20190822220915.8876-1-mathieu.poirier@linaro.org>
This patch adds barrier packets in the trace stream when the offset in the
data buffer needs to be moved forward. Otherwise the decoder isn't aware
of the break in the stream and can't synchronise itself with the trace
data.
Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
---
.../hwtracing/coresight/coresight-tmc-etr.c | 43 ++++++++++++++-----
1 file changed, 33 insertions(+), 10 deletions(-)
diff --git a/drivers/hwtracing/coresight/coresight-tmc-etr.c b/drivers/hwtracing/coresight/coresight-tmc-etr.c
index 4f000a03152e..0e4cd6ec5f28 100644
--- a/drivers/hwtracing/coresight/coresight-tmc-etr.c
+++ b/drivers/hwtracing/coresight/coresight-tmc-etr.c
@@ -946,10 +946,6 @@ static void tmc_sync_etr_buf(struct tmc_drvdata *drvdata)
WARN_ON(!etr_buf->ops || !etr_buf->ops->sync);
etr_buf->ops->sync(etr_buf, rrp, rwp);
-
- /* Insert barrier packets at the beginning, if there was an overflow */
- if (etr_buf->full)
- tmc_etr_buf_insert_barrier_packet(etr_buf, etr_buf->offset);
}
static void __tmc_etr_enable_hw(struct tmc_drvdata *drvdata)
@@ -1415,10 +1411,11 @@ static void tmc_free_etr_buffer(void *config)
* buffer to the perf ring buffer.
*/
static void tmc_etr_sync_perf_buffer(struct etr_perf_buffer *etr_perf,
+ unsigned long src_offset,
unsigned long to_copy)
{
long bytes;
- long pg_idx, pg_offset, src_offset;
+ long pg_idx, pg_offset;
unsigned long head = etr_perf->head;
char **dst_pages, *src_buf;
struct etr_buf *etr_buf = etr_perf->etr_buf;
@@ -1427,7 +1424,6 @@ static void tmc_etr_sync_perf_buffer(struct etr_perf_buffer *etr_perf,
pg_idx = head >> PAGE_SHIFT;
pg_offset = head & (PAGE_SIZE - 1);
dst_pages = (char **)etr_perf->pages;
- src_offset = etr_buf->offset + etr_buf->len - to_copy;
while (to_copy > 0) {
/*
@@ -1475,7 +1471,7 @@ tmc_update_etr_buffer(struct coresight_device *csdev,
void *config)
{
bool lost = false;
- unsigned long flags, size = 0;
+ unsigned long flags, offset, size = 0;
struct tmc_drvdata *drvdata = dev_get_drvdata(csdev->dev.parent);
struct etr_perf_buffer *etr_perf = config;
struct etr_buf *etr_buf = etr_perf->etr_buf;
@@ -1503,11 +1499,39 @@ tmc_update_etr_buffer(struct coresight_device *csdev,
spin_unlock_irqrestore(&drvdata->spinlock, flags);
size = etr_buf->len;
+ offset = etr_buf->offset;
+ lost |= etr_buf->full;
+
+ /*
+ * The ETR buffer may be bigger than the space available in the
+ * perf ring buffer (handle->size). If so advance the offset so that we
+ * get the latest trace data. In snapshot mode none of that matters
+ * since we are expected to clobber stale data in favour of the latest
+ * traces.
+ */
if (!etr_perf->snapshot && size > handle->size) {
- size = handle->size;
+ u32 mask = tmc_get_memwidth_mask(drvdata);
+
+ /*
+ * Make sure the new size is aligned in accordance with the
+ * requirement explained in function tmc_get_memwidth_mask().
+ */
+ size = handle->size & mask;
+ offset = etr_buf->offset + etr_buf->len - size;
+
+ if (offset >= etr_buf->size)
+ offset -= etr_buf->size;
lost = true;
}
- tmc_etr_sync_perf_buffer(etr_perf, size);
+
+ /*
+ * Insert barrier packets at the beginning, if there was an overflow
+ * or if the offset had to be brought forward.
+ */
+ if (lost)
+ tmc_etr_buf_insert_barrier_packet(etr_buf, offset);
+
+ tmc_etr_sync_perf_buffer(etr_perf, offset, size);
/*
* In snapshot mode we simply increment the head by the number of byte
@@ -1518,7 +1542,6 @@ tmc_update_etr_buffer(struct coresight_device *csdev,
if (etr_perf->snapshot)
handle->head += size;
- lost |= etr_buf->full;
out:
/*
* Don't set the TRUNCATED flag in snapshot mode because 1) the
--
2.17.1
^ permalink raw reply related
* [PATCH 0/2] coresight: Add barrier packet when moving offset forward
From: Mathieu Poirier @ 2019-08-22 22:09 UTC (permalink / raw)
To: yabinc, suzuki.poulose, leo.yan
Cc: mike.leach, alexander.shishkin, linux-arm-kernel, linux-kernel
Hi Yabin,
When doing more tests on your patch that adjust the offset to fit the
available space in the perf ring buffer[1], I noticed the decoder wasn't
able to decode the traces that had been collected. The issue was observed
in CPU wide scenarios but I also suspect they would have showed up in
per-thread mode given the right conditions.
I traced the problem to the moving forward of the offset in the trace
buffer. Doing so skips over the barrier packets originally inserted in
function tmc_sync_etr_buf(), which in turn prevents the decoder from
properly synchronising with the trace packets.
I fixed the condition by inserting barrier packets once the offset has been
moved forward, making sure that alignment rules are respected.
I'd be grateful if you could review and test my changes to make sure things
still work on your side.
Applies cleanly on the coresight next branch.
Best regards,
Mathieu
[1]. https://lkml.org/lkml/2019/8/14/1336
Mathieu Poirier (2):
coresight: tmc: Make memory width mask computation into a function
coresight: tmc-etr: Add barrier packet when moving offset forward
.../hwtracing/coresight/coresight-tmc-etf.c | 23 +---------
.../hwtracing/coresight/coresight-tmc-etr.c | 43 ++++++++++++++-----
drivers/hwtracing/coresight/coresight-tmc.c | 28 ++++++++++++
drivers/hwtracing/coresight/coresight-tmc.h | 1 +
4 files changed, 64 insertions(+), 31 deletions(-)
--
2.17.1
^ permalink raw reply
* Re: linux-next: build warning after merge of the drm-fixes tree
From: Alex Deucher @ 2019-08-22 22:08 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Dave Airlie, DRI, Alex Deucher, Linux Next Mailing List,
Linux Kernel Mailing List, Kevin Wang
In-Reply-To: <20190823080604.5164f8c4@canb.auug.org.au>
On Thu, Aug 22, 2019 at 6:06 PM Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Hi all,
>
> After merging the drm-fixes tree, today's linux-next build (KCONFIG_NAME)
> produced this warning:
>
> drivers/gpu/drm/amd/amdgpu/../powerplay/smu_v11_0.c: In function 'smu_v11_0_setup_pptable':
> drivers/gpu/drm/amd/amdgpu/../powerplay/smu_v11_0.c:368:40: warning: 'size' may be used uninitialized in this function [-Wmaybe-uninitialized]
> smu->smu_table.power_play_table_size = size;
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~
>
> Introduced by commit
>
> 00430144ff73 ("drm/amd/powerplay: fix variable type errors in smu_v11_0_setup_pptable")
>
> Looks like a false positive.
Silenced here:
https://patchwork.freedesktop.org/patch/325728/
Alex
>
> --
> Cheers,
> Stephen Rothwell
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [PATCH] /dev/mem: Bail out upon SIGKILL when reading memory.
From: Linus Torvalds @ 2019-08-22 22:08 UTC (permalink / raw)
To: Tetsuo Handa
Cc: Arnd Bergmann, Greg Kroah-Hartman, Linux List Kernel Mailing,
syzbot
In-Reply-To: <1566338811-4464-1-git-send-email-penguin-kernel@I-love.SAKURA.ne.jp>
[-- Attachment #1: Type: text/plain, Size: 1104 bytes --]
On Tue, Aug 20, 2019 at 3:07 PM Tetsuo Handa
<penguin-kernel@i-love.sakura.ne.jp> wrote:
>
> syzbot found that a thread can stall for minutes inside read_mem()
> after that thread was killed by SIGKILL [1]. Reading 2GB at one read()
> is legal, but delaying termination of killed thread for minutes is bad.
Side note: we might even just allow regular signals to interrupt
/dev/mem reads. We already do that for /dev/zero, and the risk of
breaking something is likely fairly low since nothing should use that
thing anyway.
Also, if it takes minutes to delay killing things, that implies that
we're probably still faulting in pages for the read_mem(). Which
points to another possible thing we could do in general: just don't
bother to handle page faults when a fatal signal is pending.
That situation might happen for other random cases too, and is not
limited to /dev/mem. So maybe it's worth trying? Does that essentially
fix the /dev/mem read case too in practice?
COMPLETELY untested patch attached, it may or may not make a
difference (and it may or may not work at all ;)
Linus
[-- Attachment #2: patch.diff --]
[-- Type: text/x-patch, Size: 1892 bytes --]
arch/x86/mm/fault.c | 15 ++++++++++++---
mm/memory.c | 5 +++++
2 files changed, 17 insertions(+), 3 deletions(-)
diff --git a/arch/x86/mm/fault.c b/arch/x86/mm/fault.c
index 9ceacd1156db..d6c029a6cb90 100644
--- a/arch/x86/mm/fault.c
+++ b/arch/x86/mm/fault.c
@@ -1033,8 +1033,15 @@ static noinline void
mm_fault_error(struct pt_regs *regs, unsigned long error_code,
unsigned long address, vm_fault_t fault)
{
- if (fatal_signal_pending(current) && !(error_code & X86_PF_USER)) {
- no_context(regs, error_code, address, 0, 0);
+ /*
+ * If we already have a fatal signal, don't bother adding
+ * a new one. If it's a kernel access, just make it fail,
+ * and if it's a user access just return to let the process
+ * die.
+ */
+ if (fatal_signal_pending(current)) {
+ if (!(error_code & X86_PF_USER))
+ no_context(regs, error_code, address, 0, 0);
return;
}
@@ -1389,7 +1396,8 @@ void do_user_addr_fault(struct pt_regs *regs,
return;
}
retry:
- down_read(&mm->mmap_sem);
+ if (down_read_killable(&mm->mmap_sem))
+ goto fatal_signal;
} else {
/*
* The above down_read_trylock() might have succeeded in
@@ -1455,6 +1463,7 @@ void do_user_addr_fault(struct pt_regs *regs,
goto retry;
}
+fatal_signal:
/* User mode? Just return to handle the fatal exception */
if (flags & FAULT_FLAG_USER)
return;
diff --git a/mm/memory.c b/mm/memory.c
index e2bb51b6242e..7ad62f96b08e 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -3988,6 +3988,11 @@ vm_fault_t handle_mm_fault(struct vm_area_struct *vma, unsigned long address,
flags & FAULT_FLAG_REMOTE))
return VM_FAULT_SIGSEGV;
+ if (flags & FAULT_FLAG_KILLABLE) {
+ if (fatal_signal_pending(current))
+ return VM_FAULT_SIGSEGV;
+ }
+
/*
* Enable the memcg OOM handling for faults triggered in user
* space. Kernel faults are handled more gracefully.
^ permalink raw reply related
* linux-next: build warning after merge of the drm-fixes tree
From: Stephen Rothwell @ 2019-08-22 22:06 UTC (permalink / raw)
To: Dave Airlie, DRI
Cc: Linux Next Mailing List, Linux Kernel Mailing List, Kevin Wang,
Alex Deucher
[-- Attachment #1: Type: text/plain, Size: 629 bytes --]
Hi all,
After merging the drm-fixes tree, today's linux-next build (KCONFIG_NAME)
produced this warning:
drivers/gpu/drm/amd/amdgpu/../powerplay/smu_v11_0.c: In function 'smu_v11_0_setup_pptable':
drivers/gpu/drm/amd/amdgpu/../powerplay/smu_v11_0.c:368:40: warning: 'size' may be used uninitialized in this function [-Wmaybe-uninitialized]
smu->smu_table.power_play_table_size = size;
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~
Introduced by commit
00430144ff73 ("drm/amd/powerplay: fix variable type errors in smu_v11_0_setup_pptable")
Looks like a false positive.
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH 5.2 000/135] 5.2.10-stable review
From: Stefan Lippers-Hollmann @ 2019-08-22 22:05 UTC (permalink / raw)
To: Greg KH; +Cc: Sasha Levin, linux-kernel, stable
In-Reply-To: <20190822172619.GA22458@kroah.com>
Hi
On 2019-08-22, Greg KH wrote:
> On Thu, Aug 22, 2019 at 01:05:56PM -0400, Sasha Levin wrote:
> >
> > This is the start of the stable review cycle for the 5.2.10 release.
[...]
> > The whole patch series can be found in one patch at:
> > https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-5.2.10-rc1.gz
^v5.x
[...]
> If anyone notices anything that we messed up, please let us know.
It might be down to kernel.org mirroring, but the patch file doesn't
seem to be available yet (404), both in the wrong location listed
above - and the expected one under
https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.2.10-rc1.gz
or
https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.2.10-rc1.xz
The v4.x based patches can be found just fine:
https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.4.190-rc1.gz
https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.9.190-rc1.gz
https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.14.140-rc1.gz
https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.19.68-rc1.gz
Regards
Stefan Lippers-Hollmann
^ permalink raw reply
* [PATCH] ipw2x00: fix spelling mistake "initializationg" -> "initialization"
From: Colin King @ 2019-08-22 22:00 UTC (permalink / raw)
To: Stanislav Yakovlev, Kalle Valo, David S . Miller, linux-wireless,
netdev
Cc: kernel-janitors, linux-kernel
From: Colin Ian King <colin.king@canonical.com>
There is a spelling mistake in an IPW_DEBUG_INFO message. Fix it.
Signed-off-by: Colin Ian King <colin.king@canonical.com>
---
drivers/net/wireless/intel/ipw2x00/ipw2200.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/intel/ipw2x00/ipw2200.c b/drivers/net/wireless/intel/ipw2x00/ipw2200.c
index fa55d2ccbfab..ed0f06532d5e 100644
--- a/drivers/net/wireless/intel/ipw2x00/ipw2200.c
+++ b/drivers/net/wireless/intel/ipw2x00/ipw2200.c
@@ -2721,7 +2721,7 @@ static void ipw_eeprom_init_sram(struct ipw_priv *priv)
/* Do not load eeprom data on fatal error or suspend */
ipw_write32(priv, IPW_EEPROM_LOAD_DISABLE, 0);
} else {
- IPW_DEBUG_INFO("Enabling FW initializationg of SRAM\n");
+ IPW_DEBUG_INFO("Enabling FW initialization of SRAM\n");
/* Load eeprom data on fatal error or suspend */
ipw_write32(priv, IPW_EEPROM_LOAD_DISABLE, 1);
--
2.20.1
^ permalink raw reply related
* [PATCH] seccomp: fix compilation errors in seccomp-bpf kselftest
From: Alakesh Haloi @ 2019-08-22 21:58 UTC (permalink / raw)
To: Kees Cook, Andy Lutomirski, Will Drewry, Shuah Khan,
Alexei Starovoitov, Daniel Borkmann, Martin KaFai Lau, Song Liu,
Yonghong Song
Cc: linux-kselftest, netdev, bpf, linux-kernel
Without this patch we see following error while building and kselftest
for secccomp_bpf fails.
seccomp_bpf.c:1787:20: error: ‘PTRACE_EVENTMSG_SYSCALL_ENTRY’ undeclared (first use in this function);
seccomp_bpf.c:1788:6: error: ‘PTRACE_EVENTMSG_SYSCALL_EXIT’ undeclared (first use in this function);
Signed-off-by: Alakesh Haloi <alakesh.haloi@gmail.com>
---
tools/testing/selftests/seccomp/seccomp_bpf.c | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/tools/testing/selftests/seccomp/seccomp_bpf.c b/tools/testing/selftests/seccomp/seccomp_bpf.c
index 6ef7f16c4cf5..2e619760fc3e 100644
--- a/tools/testing/selftests/seccomp/seccomp_bpf.c
+++ b/tools/testing/selftests/seccomp/seccomp_bpf.c
@@ -1353,6 +1353,14 @@ TEST_F(precedence, log_is_fifth_in_any_order)
#define PTRACE_EVENT_SECCOMP 7
#endif
+#ifndef PTRACE_EVENTMSG_SYSCALL_ENTRY
+#define PTRACE_EVENTMSG_SYSCALL_ENTRY 1
+#endif
+
+#ifndef PTRACE_EVENTMSG_SYSCALL_EXIT
+#define PTRACE_EVENTMSG_SYSCALL_EXIT 2
+#endif
+
#define IS_SECCOMP_EVENT(status) ((status >> 16) == PTRACE_EVENT_SECCOMP)
bool tracer_running;
void tracer_stop(int sig)
--
2.17.1
^ permalink raw reply related
* Re: [RFC] mm: Proactive compaction
From: Nitin Gupta @ 2019-08-22 21:57 UTC (permalink / raw)
To: Mel Gorman
Cc: akpm@linux-foundation.org, vbabka@suse.cz, mhocko@suse.com,
dan.j.williams@intel.com, Yu Zhao, Matthew Wilcox, Qian Cai,
Andrey Ryabinin, Roman Gushchin, Greg Kroah-Hartman, Kees Cook,
Jann Horn, Johannes Weiner, Arun KS, Janne Huttunen,
Konstantin Khlebnikov, linux-kernel@vger.kernel.org,
linux-mm@kvack.org
In-Reply-To: <20190822085135.GS2739@techsingularity.net>
> -----Original Message-----
> From: owner-linux-mm@kvack.org <owner-linux-mm@kvack.org> On Behalf
> Of Mel Gorman
> Sent: Thursday, August 22, 2019 1:52 AM
> To: Nitin Gupta <nigupta@nvidia.com>
> Cc: akpm@linux-foundation.org; vbabka@suse.cz; mhocko@suse.com;
> dan.j.williams@intel.com; Yu Zhao <yuzhao@google.com>; Matthew Wilcox
> <willy@infradead.org>; Qian Cai <cai@lca.pw>; Andrey Ryabinin
> <aryabinin@virtuozzo.com>; Roman Gushchin <guro@fb.com>; Greg Kroah-
> Hartman <gregkh@linuxfoundation.org>; Kees Cook
> <keescook@chromium.org>; Jann Horn <jannh@google.com>; Johannes
> Weiner <hannes@cmpxchg.org>; Arun KS <arunks@codeaurora.org>; Janne
> Huttunen <janne.huttunen@nokia.com>; Konstantin Khlebnikov
> <khlebnikov@yandex-team.ru>; linux-kernel@vger.kernel.org; linux-
> mm@kvack.org
> Subject: Re: [RFC] mm: Proactive compaction
>
> On Fri, Aug 16, 2019 at 02:43:30PM -0700, Nitin Gupta wrote:
> > For some applications we need to allocate almost all memory as
> > hugepages. However, on a running system, higher order allocations can
> > fail if the memory is fragmented. Linux kernel currently does
> > on-demand compaction as we request more hugepages but this style of
> > compaction incurs very high latency. Experiments with one-time full
> > memory compaction (followed by hugepage allocations) shows that kernel
> > is able to restore a highly fragmented memory state to a fairly
> > compacted memory state within <1 sec for a 32G system. Such data
> > suggests that a more proactive compaction can help us allocate a large
> > fraction of memory as hugepages keeping allocation latencies low.
> >
>
> Note that proactive compaction may reduce allocation latency but it is not
> free either. Even though the scanning and migration may happen in a kernel
> thread, tasks can incur faults while waiting for compaction to complete if the
> task accesses data being migrated. This means that costs are incurred by
> applications on a system that may never care about high-order allocation
> latency -- particularly if the allocations typically happen at application
> initialisation time. I recognise that kcompactd makes a bit of effort to
> compact memory out-of-band but it also is typically triggered in response to
> reclaim that was triggered by a high-order allocation request. i.e. the work
> done by the thread is triggered by an allocation request that hit the slow
> paths and not a preemptive measure.
>
Hitting the slow path for every higher-order allocation is a signification
performance/latency issue for applications that requires a large number of
these allocations to succeed in bursts. To get some concrete numbers, I
made a small driver that allocates as many hugepages as possible and
measures allocation latency:
The driver first tries to allocate hugepage using GFP_TRANSHUGE_LIGHT
(referred to as "Light" in the table below) and if that fails, tries to
allocate with `GFP_TRANSHUGE | __GFP_RETRY_MAYFAIL` (referred to as
"Fallback" in table below). We stop the allocation loop if both methods
fail.
Table-1: hugepage allocation latencies on vanilla 5.3.0-rc5. All latencies
are in microsec.
| GFP/Stat | Any | Light | Fallback |
|--------: | ---------: | ------: | ---------: |
| count | 9908 | 788 | 9120 |
| min | 0.0 | 0.0 | 1726.0 |
| max | 135387.0 | 142.0 | 135387.0 |
| mean | 5494.66 | 1.83 | 5969.26 |
| stddev | 21624.04 | 7.58 | 22476.06 |
As you can see, the mean and stddev of allocation is extremely high with
the current approach of on-demand compaction.
The system was fragmented from a userspace program as I described in this
patch description. The workload is mainly anonymous userspace pages which
as easy to move around. I intentionally avoided unmovable pages in this
test to see how much latency do we incur just by hitting the slow path for
a majority of allocations.
> > For a more proactive compaction, the approach taken here is to define
> > per page-order external fragmentation thresholds and let kcompactd
> > threads act on these thresholds.
> >
> > The low and high thresholds are defined per page-order and exposed
> > through sysfs:
> >
> > /sys/kernel/mm/compaction/order-[1..MAX_ORDER]/extfrag_{low,high}
> >
>
> These will be difficult for an admin to tune that is not extremely familiar with
> how external fragmentation is defined. If an admin asked "how much will
> stalls be reduced by setting this to a different value?", the answer will always
> be "I don't know, maybe some, maybe not".
>
Yes, this is my main worry. These values can be set to emperically
determined values on highly specialized systems like database appliances.
However, on a generic system, there is no real reasonable value.
Still, at the very least, I would like an interface that allows compacting
system to a reasonable state. Something like:
compact_extfrag(node, zone, order, high, low)
which start compaction if extfrag > high, and goes on till extfrag < low.
It's possible that there are too many unmovable pages mixed around for
compaction to succeed, still it's a reasonable interface to expose rather
than forced on-demand style of compaction (please see data below).
How (and if) to expose it to userspace (sysfs etc.) can be a separate
discussion.
> > Per-node kcompactd thread is woken up every few seconds to check if
> > any zone on its node has extfrag above the extfrag_high threshold for
> > any order, in which case the thread starts compaction in the backgrond
> > till all zones are below extfrag_low level for all orders. By default
> > both these thresolds are set to 100 for all orders which essentially
> > disables kcompactd.
> >
> > To avoid wasting CPU cycles when compaction cannot help, such as when
> > memory is full, we check both, extfrag > extfrag_high and
> > compaction_suitable(zone). This allows kcomapctd thread to stays
> > inactive even if extfrag thresholds are not met.
> >
>
> There is still a risk that if a system is completely fragmented that it may
> consume CPU on pointless compaction cycles. This is why compaction from
> kernel thread context makes no special effort and bails relatively quickly and
> assumes that if an application really needs high-order pages that it'll incur
> the cost at allocation time.
>
As data in Table-1 shows, on-demand compaction can add high latency to
every single allocation. I think it would be a significant improvement (see
Table-2) to at least expose an interface to allow proactive compaction
(like compaction_extfrag), which a driver can itself run in background. This
way, we need not add any tunables to the kernel itself and leave compaction
decision to specialized kernel/userspace monitors.
> > This patch is largely based on ideas from Michal Hocko posted here:
> > https://lore.kernel.org/linux-
> mm/20161230131412.GI13301@dhcp22.suse.cz
> > /
> >
> > Testing done (on x86):
> > - Set /sys/kernel/mm/compaction/order-9/extfrag_{low,high} = {25, 30}
> > respectively.
> > - Use a test program to fragment memory: the program allocates all
> > memory and then for each 2M aligned section, frees 3/4 of base pages
> > using munmap.
> > - kcompactd0 detects fragmentation for order-9 > extfrag_high and
> > starts compaction till extfrag < extfrag_low for order-9.
> >
>
> This is a somewhat optimisitic allocation scenario. The interesting ones are
> when a system is fragmenteed in a manner that is not trivial to resolve -- e.g.
> after a prolonged period of time with unmovable/reclaimable allocations
> stealing pageblocks. It's also fairly difficult to analyse if this is helping
> because you cannot measure after the fact how much time was saved in
> allocation time due to the work done by kcompactd. It is also hard to
> determine if the sum of the stalls incurred by proactive compaction is lower
> than the time saved at allocation time.
>
> I fear that the user-visible effect will be times when there are very short but
> numerous stalls due to proactive compaction running in the background that
> will be hard to detect while the benefits may be invisible.
>
Pro-active compaction can be done in a non-time-critical context, so to
estimate its benefits we can just compare data from Table-1 the same run,
under a similar fragmentation state, but with this patch applied:
Table-2: hugepage allocation latencies with this patch applied on
5.3.0-rc5.
| GFP_Stat | Any | Light | Fallback |
| --------:| ----------:| ---------:| ----------:|
| count | 12197.0 | 11167.0 | 1030.0 |
| min | 2.0 | 2.0 | 5.0 |
| max | 361727.0 | 26.0 | 361727.0 |
| mean | 366.05 | 4.48 | 4286.13 |
| stddev | 4575.53 | 1.41 | 15209.63 |
We can see that mean latency dropped to 366us compared with 5494us before.
This is an optimistic scenario where there was a little mix of unmovable
pages but still the data shows that in case compaction can succeed,
pro-active compaction can give signification reduction higher-order
allocation latencies.
> > The patch has plenty of rough edges but posting it early to see if I'm
> > going in the right direction and to get some early feedback.
> >
>
> As unappealing as it sounds, I think it is better to try improve the allocation
> latency itself instead of trying to hide the cost in a kernel thread. It's far
> harder to implement as compaction is not easy but it would be more
> obvious what the savings are by looking at a histogram of allocation latencies
> -- there are other metrics that could be considered but that's the obvious
> one.
>
Improving allocation latencies in itself would be a separate effort. In
case memory is full or fragmented we have to deal with reclaim or
compaction to make allocation (esp. higher-order) succeed. In particular,
forcing compaction to be done only on-demand is in my opinion not the right
approach. As I detailed above, at the very minimum, we need an interface
like `compact_extfrag` which can leave the decision on specific
kernel/userspace drivers on how pro-active you want compaction to be.
^ permalink raw reply
* [PATCH] scsi: qla2xxx: fix spelling mistake "initializatin" -> "initialization"
From: Colin King @ 2019-08-22 21:56 UTC (permalink / raw)
To: qla2xxx-upstream, James E . J . Bottomley, Martin K . Petersen,
linux-scsi
Cc: kernel-janitors, linux-kernel
From: Colin Ian King <colin.king@canonical.com>
There is a spelling mistake in a ql_log message. Fix it.
Signed-off-by: Colin Ian King <colin.king@canonical.com>
---
drivers/scsi/qla2xxx/qla_nx.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/scsi/qla2xxx/qla_nx.c b/drivers/scsi/qla2xxx/qla_nx.c
index 372355bfcbb6..65a675906188 100644
--- a/drivers/scsi/qla2xxx/qla_nx.c
+++ b/drivers/scsi/qla2xxx/qla_nx.c
@@ -1977,7 +1977,7 @@ qla82xx_check_rcvpeg_state(struct qla_hw_data *ha)
} while (--retries);
ql_log(ql_log_fatal, vha, 0x00ac,
- "Rcv Peg initializatin failed: 0x%x.\n", val);
+ "Rcv Peg initialization failed: 0x%x.\n", val);
read_lock(&ha->hw_lock);
qla82xx_wr_32(ha, CRB_RCVPEG_STATE, PHAN_INITIALIZE_FAILED);
read_unlock(&ha->hw_lock);
--
2.20.1
^ permalink raw reply related
* [PATCH] tty: n_gsm: avoid recursive locking with async port hangup
From: Martin Hundebøll @ 2019-08-22 21:56 UTC (permalink / raw)
To: Greg Kroah-Hartman, Jiri Slaby, Alan Cox, linux-kernel
Cc: Martin Hundebøll, Sean Nyekjær, Esben Haabendal
When tearing down the n_gsm ldisc while one or more of its child ports
are open, a lock dep warning occurs:
[ 56.254258] ======================================================
[ 56.260447] WARNING: possible circular locking dependency detected
[ 56.266641] 5.2.0-00118-g1fd58e20e5b0 #30 Not tainted
[ 56.271701] ------------------------------------------------------
[ 56.277890] cmux/271 is trying to acquire lock:
[ 56.282436] 8215283a (&tty->legacy_mutex){+.+.}, at: __tty_hangup.part.0+0x58/0x27c
[ 56.290128]
[ 56.290128] but task is already holding lock:
[ 56.295970] e9e2b842 (&gsm->mutex){+.+.}, at: gsm_cleanup_mux+0x9c/0x15c
[ 56.302699]
[ 56.302699] which lock already depends on the new lock.
[ 56.302699]
[ 56.310884]
[ 56.310884] the existing dependency chain (in reverse order) is:
[ 56.318372]
[ 56.318372] -> #2 (&gsm->mutex){+.+.}:
[ 56.323624] mutex_lock_nested+0x1c/0x24
[ 56.328079] gsm_cleanup_mux+0x9c/0x15c
[ 56.332448] gsmld_ioctl+0x418/0x4e8
[ 56.336554] tty_ioctl+0x96c/0xcb0
[ 56.340492] do_vfs_ioctl+0x41c/0xa5c
[ 56.344685] ksys_ioctl+0x34/0x60
[ 56.348535] ret_fast_syscall+0x0/0x28
[ 56.352815] 0xbe97cc04
[ 56.355791]
[ 56.355791] -> #1 (&tty->ldisc_sem){++++}:
[ 56.361388] tty_ldisc_lock+0x50/0x74
[ 56.365581] tty_init_dev+0x88/0x1c4
[ 56.369687] tty_open+0x1c8/0x430
[ 56.373536] chrdev_open+0xa8/0x19c
[ 56.377560] do_dentry_open+0x118/0x3c4
[ 56.381928] path_openat+0x2fc/0x1190
[ 56.386123] do_filp_open+0x68/0xd4
[ 56.390146] do_sys_open+0x164/0x220
[ 56.394257] kernel_init_freeable+0x328/0x3e4
[ 56.399146] kernel_init+0x8/0x110
[ 56.403078] ret_from_fork+0x14/0x20
[ 56.407183] 0x0
[ 56.409548]
[ 56.409548] -> #0 (&tty->legacy_mutex){+.+.}:
[ 56.415402] __mutex_lock+0x64/0x90c
[ 56.419508] mutex_lock_nested+0x1c/0x24
[ 56.423961] __tty_hangup.part.0+0x58/0x27c
[ 56.428676] gsm_cleanup_mux+0xe8/0x15c
[ 56.433043] gsmld_close+0x48/0x90
[ 56.436979] tty_ldisc_kill+0x2c/0x6c
[ 56.441173] tty_ldisc_release+0x88/0x194
[ 56.445715] tty_release_struct+0x14/0x44
[ 56.450254] tty_release+0x36c/0x43c
[ 56.454365] __fput+0x94/0x1e8
Avoid the warning by doing the port hangup asynchronously.
Signed-off-by: Martin Hundebøll <martin@geanix.com>
---
drivers/tty/n_gsm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/tty/n_gsm.c b/drivers/tty/n_gsm.c
index d30525946892..36a3eb4ad4c5 100644
--- a/drivers/tty/n_gsm.c
+++ b/drivers/tty/n_gsm.c
@@ -1716,7 +1716,7 @@ static void gsm_dlci_release(struct gsm_dlci *dlci)
gsm_destroy_network(dlci);
mutex_unlock(&dlci->mutex);
- tty_vhangup(tty);
+ tty_hangup(tty);
tty_port_tty_set(&dlci->port, NULL);
tty_kref_put(tty);
--
2.22.1
^ permalink raw reply related
* [PATCH] ntfs: mft: fix spelling mistake "initiailized" -> "initialized"
From: Colin King @ 2019-08-22 21:53 UTC (permalink / raw)
To: Anton Altaparmakov, linux-ntfs-dev; +Cc: kernel-janitors, linux-kernel
From: Colin Ian King <colin.king@canonical.com>
There is a spelling mistake in a ntfs_debug message, fix it.
Signed-off-by: Colin Ian King <colin.king@canonical.com>
---
fs/ntfs/mft.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/ntfs/mft.c b/fs/ntfs/mft.c
index 20c841a906f2..218984422f49 100644
--- a/fs/ntfs/mft.c
+++ b/fs/ntfs/mft.c
@@ -1580,7 +1580,7 @@ static int ntfs_mft_bitmap_extend_initialized_nolock(ntfs_volume *vol)
ATTR_RECORD *a;
int ret;
- ntfs_debug("Extending mft bitmap initiailized (and data) size.");
+ ntfs_debug("Extending mft bitmap initialized (and data) size.");
mft_ni = NTFS_I(vol->mft_ino);
mftbmp_vi = vol->mftbmp_ino;
mftbmp_ni = NTFS_I(mftbmp_vi);
--
2.20.1
^ permalink raw reply related
* Re: [RFC v4 07/18] objtool: Introduce INSN_UNKNOWN type
From: Josh Poimboeuf @ 2019-08-22 21:51 UTC (permalink / raw)
To: Julien
Cc: Raphael Gault, linux-arm-kernel, linux-kernel, peterz,
catalin.marinas, will.deacon, raph.gault+kdev
In-Reply-To: <3c4e3227-eeb3-371a-d015-a0e0e60e5332@gmail.com>
On Thu, Aug 22, 2019 at 09:45:00PM +0100, Julien wrote:
> Hi Josh,
>
> On 22/08/19 21:04, Josh Poimboeuf wrote:
> > On Fri, Aug 16, 2019 at 01:23:52PM +0100, Raphael Gault wrote:
> > > On arm64 some object files contain data stored in the .text section.
> > > This data is interpreted by objtool as instruction but can't be
> > > identified as a valid one. In order to keep analysing those files we
> > > introduce INSN_UNKNOWN type. The "unknown instruction" warning will thus
> > > only be raised if such instructions are uncountered while validating an
> > > execution branch.
> > >
> > > This change doesn't impact the x86 decoding logic since 0 is still used
> > > as a way to specify an unknown type, raising the "unknown instruction"
> > > warning during the decoding phase still.
> > >
> > > Signed-off-by: Raphael Gault <raphael.gault@arm.com>
> >
> > Is there a reason such data can't be moved to .rodata? That would seem
> > like the proper fix.
> >
>
> Raphaël can confirm, if I remember correctly, that issue was encountered on
> assembly files implementing crypto algorithms were some words/double-words
> of data were in the middle of the .text. I think it is done this way to make
> sure the data can be loaded in a single instruction. So moving it to another
> section could impact the crypto performance depending on the relocations.
>
> That was my understanding at least.
Thanks. If that's the case then that would be useful information to put
in the patch description. A code excerpt of an example code site would
be useful too.
I'm not sure INSN_UNKNOWN is the right name though, since the decoder
does actually know about it. Maybe INSN_DATA or something?
--
Josh
^ permalink raw reply
* RE: [PATCH 0/5] Further sanitize INTEL_FAM6 naming
From: Luck, Tony @ 2019-08-22 21:50 UTC (permalink / raw)
To: Luck, Tony, Peter Zijlstra; +Cc: linux-kernel@vger.kernel.org
In-Reply-To: <20190822205312.GA10757@agluck-desk2.amr.corp.intel.com>
> Looks like your scripts didn't anticipate the CPP gymnastics like:
>
> #define VULNWL_INTEL(model, whitelist) \
> VULNWL(INTEL, 6, INTEL_FAM6_##model, whitelist)
Also INTEL_CPU_FAM6() macro
-Tony
^ permalink raw reply
* Re: [f2fs-dev] [PATCH v2] f2fs: fix to writeout dirty inode during node flush
From: Eric Biggers @ 2019-08-22 21:49 UTC (permalink / raw)
To: Chao Yu; +Cc: jaegeuk, linux-kernel, linux-f2fs-devel
In-Reply-To: <20190822121756.107187-1-yuchao0@huawei.com>
On Thu, Aug 22, 2019 at 08:17:56PM +0800, Chao Yu wrote:
> As Eric reported:
>
> On xfstest generic/204 on f2fs, I'm getting a kernel BUG.
>
> allocate_segment_by_default+0x9d/0x100 [f2fs]
> f2fs_allocate_data_block+0x3c0/0x5c0 [f2fs]
> do_write_page+0x62/0x110 [f2fs]
> f2fs_do_write_node_page+0x2b/0xa0 [f2fs]
> __write_node_page+0x2ec/0x590 [f2fs]
> f2fs_sync_node_pages+0x756/0x7e0 [f2fs]
> block_operations+0x25b/0x350 [f2fs]
> f2fs_write_checkpoint+0x104/0x1150 [f2fs]
> f2fs_sync_fs+0xa2/0x120 [f2fs]
> f2fs_balance_fs_bg+0x33c/0x390 [f2fs]
> f2fs_write_node_pages+0x4c/0x1f0 [f2fs]
> do_writepages+0x1c/0x70
> __writeback_single_inode+0x45/0x320
> writeback_sb_inodes+0x273/0x5c0
> wb_writeback+0xff/0x2e0
> wb_workfn+0xa1/0x370
> process_one_work+0x138/0x350
> worker_thread+0x4d/0x3d0
> kthread+0x109/0x140
>
> The root cause of this issue is, in a very small partition, e.g.
> in generic/204 testcase of fstest suit, filesystem's free space
> is 50MB, so at most we can write 12800 inline inode with command:
> `echo XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX > $SCRATCH_MNT/$i`,
> then filesystem will have:
> - 12800 dirty inline data page
> - 12800 dirty inode page
> - and 12800 dirty imeta (dirty inode)
>
> When we flush node-inode's page cache, we can also flush inline
> data with each inode page, however it will run out-of-free-space
> in device, then once it triggers checkpoint, there is no room for
> huge number of imeta, at this time, GC is useless, as there is no
> dirty segment at all.
>
> In order to fix this, we try to recognize inode page during
> node_inode's page flushing, and update inode page from dirty inode,
> so that later another imeta (dirty inode) flush can be avoided.
>
> Reported-by: Eric Biggers <ebiggers@kernel.org>
> Signed-off-by: Chao Yu <yuchao0@huawei.com>
> ---
> v2: fix potential deadlock
> fs/f2fs/node.c | 49 +++++++++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 49 insertions(+)
>
> diff --git a/fs/f2fs/node.c b/fs/f2fs/node.c
> index d9ba1db2d01e..e5044eec8097 100644
> --- a/fs/f2fs/node.c
> +++ b/fs/f2fs/node.c
> @@ -1762,6 +1762,47 @@ int f2fs_fsync_node_pages(struct f2fs_sb_info *sbi, struct inode *inode,
> return ret ? -EIO: 0;
> }
>
> +static int f2fs_match_ino(struct inode *inode, unsigned long ino, void *data)
> +{
> + struct f2fs_sb_info *sbi = F2FS_I_SB(inode);
> + bool clean;
> +
> + if (inode->i_ino != ino)
> + return 0;
> +
> + if (!is_inode_flag_set(inode, FI_DIRTY_INODE))
> + return 0;
> +
> + spin_lock(&sbi->inode_lock[DIRTY_META]);
> + clean = list_empty(&F2FS_I(inode)->gdirty_list);
> + spin_unlock(&sbi->inode_lock[DIRTY_META]);
> +
> + if (clean)
> + return 0;
> +
> + inode = igrab(inode);
> + if (!inode)
> + return 0;
> + return 1;
> +}
> +
> +static bool flush_dirty_inode(struct page *page)
> +{
> + struct f2fs_sb_info *sbi = F2FS_P_SB(page);
> + struct inode *inode;
> + nid_t ino = ino_of_node(page);
> +
> + inode = find_inode_nowait(sbi->sb, ino, f2fs_match_ino, NULL);
> + if (!inode)
> + return false;
> +
> + f2fs_update_inode(inode, page);
> + unlock_page(page);
> +
> + iput(inode);
> + return true;
> +}
> +
> int f2fs_sync_node_pages(struct f2fs_sb_info *sbi,
> struct writeback_control *wbc,
> bool do_balance, enum iostat_type io_type)
> @@ -1785,6 +1826,7 @@ int f2fs_sync_node_pages(struct f2fs_sb_info *sbi,
> for (i = 0; i < nr_pages; i++) {
> struct page *page = pvec.pages[i];
> bool submitted = false;
> + bool may_dirty = true;
>
> /* give a priority to WB_SYNC threads */
> if (atomic_read(&sbi->wb_sync_req[NODE]) &&
> @@ -1832,6 +1874,13 @@ int f2fs_sync_node_pages(struct f2fs_sb_info *sbi,
> goto lock_node;
> }
>
> + /* flush dirty inode */
> + if (IS_INODE(page) && may_dirty) {
> + may_dirty = false;
> + if (flush_dirty_inode(page))
> + goto lock_node;
> + }
> +
> f2fs_wait_on_page_writeback(page, NODE, true, true);
>
> if (!clear_page_dirty_for_io(page))
> --
> 2.18.0.rc1
>
Thanks, the test passes for me with this patch applied.
Tested-by: Eric Biggers <ebiggers@kernel.org>
^ permalink raw reply
* Re: [PATCH v2 3/3] fuse: kmemcg account fs data
From: Shakeel Butt @ 2019-08-22 21:43 UTC (permalink / raw)
To: Khazhismel Kumykov; +Cc: miklos, linux-fsdevel, LKML
In-Reply-To: <20190822200030.141272-3-khazhy@google.com>
On Thu, Aug 22, 2019 at 1:00 PM Khazhismel Kumykov <khazhy@google.com> wrote:
>
> account per-file, dentry, and inode data
>
> accounts the per-file reserved request, adding new
> fuse_request_alloc_account()
>
> blockdev/superblock and temporary per-request data was left alone, as
> this usually isn't accounted
>
> Signed-off-by: Khazhismel Kumykov <khazhy@google.com>
Reviewed-by: Shakeel Butt <shakeelb@google.com>
> ---
> fs/fuse/dir.c | 3 ++-
> fs/fuse/file.c | 4 ++--
> fs/fuse/inode.c | 3 ++-
> 3 files changed, 6 insertions(+), 4 deletions(-)
>
> diff --git a/fs/fuse/dir.c b/fs/fuse/dir.c
> index f9c59a296568..2013e1222de7 100644
> --- a/fs/fuse/dir.c
> +++ b/fs/fuse/dir.c
> @@ -258,7 +258,8 @@ static int fuse_dentry_revalidate(struct dentry *entry, unsigned int flags)
> #if BITS_PER_LONG < 64
> static int fuse_dentry_init(struct dentry *dentry)
> {
> - dentry->d_fsdata = kzalloc(sizeof(union fuse_dentry), GFP_KERNEL);
> + dentry->d_fsdata = kzalloc(sizeof(union fuse_dentry),
> + GFP_KERNEL_ACCOUNT | __GFP_RECLAIMABLE);
>
> return dentry->d_fsdata ? 0 : -ENOMEM;
> }
> diff --git a/fs/fuse/file.c b/fs/fuse/file.c
> index 572d8347ebcb..ae8c8016bb8e 100644
> --- a/fs/fuse/file.c
> +++ b/fs/fuse/file.c
> @@ -45,12 +45,12 @@ struct fuse_file *fuse_file_alloc(struct fuse_conn *fc)
> {
> struct fuse_file *ff;
>
> - ff = kzalloc(sizeof(struct fuse_file), GFP_KERNEL);
> + ff = kzalloc(sizeof(struct fuse_file), GFP_KERNEL_ACCOUNT);
> if (unlikely(!ff))
> return NULL;
>
> ff->fc = fc;
> - ff->reserved_req = fuse_request_alloc(0, GFP_KERNEL);
> + ff->reserved_req = fuse_request_alloc(0, GFP_KERNEL_ACCOUNT);
> if (unlikely(!ff->reserved_req)) {
> kfree(ff);
> return NULL;
> diff --git a/fs/fuse/inode.c b/fs/fuse/inode.c
> index 5afd1872b8b1..ad92e93eaddd 100644
> --- a/fs/fuse/inode.c
> +++ b/fs/fuse/inode.c
> @@ -76,7 +76,8 @@ struct fuse_mount_data {
>
> struct fuse_forget_link *fuse_alloc_forget(void)
> {
> - return kzalloc(sizeof(struct fuse_forget_link), GFP_KERNEL);
> + return kzalloc(sizeof(struct fuse_forget_link),
> + GFP_KERNEL_ACCOUNT | __GFP_RECLAIMABLE);
> }
>
> static struct inode *fuse_alloc_inode(struct super_block *sb)
> --
> 2.23.0.187.g17f5b7556c-goog
>
^ permalink raw reply
* Re: [PATCH v2 2/3] fuse: pass gfp flags to fuse_request_alloc
From: Shakeel Butt @ 2019-08-22 21:42 UTC (permalink / raw)
To: Khazhismel Kumykov; +Cc: miklos, linux-fsdevel, LKML
In-Reply-To: <20190822200030.141272-2-khazhy@google.com>
On Thu, Aug 22, 2019 at 1:00 PM Khazhismel Kumykov <khazhy@google.com> wrote:
>
> Instead of having a helper per flag
>
> Signed-off-by: Khazhismel Kumykov <khazhy@google.com>
Reviewed-by: Shakeel Butt <shakeelb@google.com>
> ---
> fs/fuse/dev.c | 16 +++-------------
> fs/fuse/file.c | 6 +++---
> fs/fuse/fuse_i.h | 4 +---
> fs/fuse/inode.c | 4 ++--
> 4 files changed, 9 insertions(+), 21 deletions(-)
>
> diff --git a/fs/fuse/dev.c b/fs/fuse/dev.c
> index ea8237513dfa..c957620ce7ba 100644
> --- a/fs/fuse/dev.c
> +++ b/fs/fuse/dev.c
> @@ -66,7 +66,7 @@ static struct page **fuse_req_pages_alloc(unsigned int npages, gfp_t flags,
> return pages;
> }
>
> -static struct fuse_req *__fuse_request_alloc(unsigned npages, gfp_t flags)
> +struct fuse_req *fuse_request_alloc(unsigned int npages, gfp_t flags)
> {
> struct fuse_req *req = kmem_cache_zalloc(fuse_req_cachep, flags);
> if (req) {
> @@ -90,18 +90,8 @@ static struct fuse_req *__fuse_request_alloc(unsigned npages, gfp_t flags)
> }
> return req;
> }
> -
> -struct fuse_req *fuse_request_alloc(unsigned npages)
> -{
> - return __fuse_request_alloc(npages, GFP_KERNEL);
> -}
> EXPORT_SYMBOL_GPL(fuse_request_alloc);
>
> -struct fuse_req *fuse_request_alloc_nofs(unsigned npages)
> -{
> - return __fuse_request_alloc(npages, GFP_NOFS);
> -}
> -
> static void fuse_req_pages_free(struct fuse_req *req)
> {
> if (req->pages != req->inline_pages)
> @@ -201,7 +191,7 @@ static struct fuse_req *__fuse_get_req(struct fuse_conn *fc, unsigned npages,
> if (fc->conn_error)
> goto out;
>
> - req = fuse_request_alloc(npages);
> + req = fuse_request_alloc(npages, GFP_KERNEL);
> err = -ENOMEM;
> if (!req) {
> if (for_background)
> @@ -310,7 +300,7 @@ struct fuse_req *fuse_get_req_nofail_nopages(struct fuse_conn *fc,
> wait_event(fc->blocked_waitq, fc->initialized);
> /* Matches smp_wmb() in fuse_set_initialized() */
> smp_rmb();
> - req = fuse_request_alloc(0);
> + req = fuse_request_alloc(0, GFP_KERNEL);
> if (!req)
> req = get_reserved_req(fc, file);
>
> diff --git a/fs/fuse/file.c b/fs/fuse/file.c
> index 5ae2828beb00..572d8347ebcb 100644
> --- a/fs/fuse/file.c
> +++ b/fs/fuse/file.c
> @@ -50,7 +50,7 @@ struct fuse_file *fuse_file_alloc(struct fuse_conn *fc)
> return NULL;
>
> ff->fc = fc;
> - ff->reserved_req = fuse_request_alloc(0);
> + ff->reserved_req = fuse_request_alloc(0, GFP_KERNEL);
> if (unlikely(!ff->reserved_req)) {
> kfree(ff);
> return NULL;
> @@ -1703,7 +1703,7 @@ static int fuse_writepage_locked(struct page *page)
>
> set_page_writeback(page);
>
> - req = fuse_request_alloc_nofs(1);
> + req = fuse_request_alloc(1, GFP_NOFS);
> if (!req)
> goto err;
>
> @@ -1923,7 +1923,7 @@ static int fuse_writepages_fill(struct page *page,
> struct fuse_inode *fi = get_fuse_inode(inode);
>
> err = -ENOMEM;
> - req = fuse_request_alloc_nofs(FUSE_REQ_INLINE_PAGES);
> + req = fuse_request_alloc(FUSE_REQ_INLINE_PAGES, GFP_NOFS);
> if (!req) {
> __free_page(tmp_page);
> goto out_unlock;
> diff --git a/fs/fuse/fuse_i.h b/fs/fuse/fuse_i.h
> index 24dbca777775..8080a51096e9 100644
> --- a/fs/fuse/fuse_i.h
> +++ b/fs/fuse/fuse_i.h
> @@ -902,9 +902,7 @@ void __exit fuse_ctl_cleanup(void);
> /**
> * Allocate a request
> */
> -struct fuse_req *fuse_request_alloc(unsigned npages);
> -
> -struct fuse_req *fuse_request_alloc_nofs(unsigned npages);
> +struct fuse_req *fuse_request_alloc(unsigned int npages, gfp_t flags);
>
> bool fuse_req_realloc_pages(struct fuse_conn *fc, struct fuse_req *req,
> gfp_t flags);
> diff --git a/fs/fuse/inode.c b/fs/fuse/inode.c
> index 4bb885b0f032..5afd1872b8b1 100644
> --- a/fs/fuse/inode.c
> +++ b/fs/fuse/inode.c
> @@ -1177,13 +1177,13 @@ static int fuse_fill_super(struct super_block *sb, void *data, int silent)
> /* Root dentry doesn't have .d_revalidate */
> sb->s_d_op = &fuse_dentry_operations;
>
> - init_req = fuse_request_alloc(0);
> + init_req = fuse_request_alloc(0, GFP_KERNEL);
> if (!init_req)
> goto err_put_root;
> __set_bit(FR_BACKGROUND, &init_req->flags);
>
> if (is_bdev) {
> - fc->destroy_req = fuse_request_alloc(0);
> + fc->destroy_req = fuse_request_alloc(0, GFP_KERNEL);
> if (!fc->destroy_req)
> goto err_free_init_req;
> }
> --
> 2.23.0.187.g17f5b7556c-goog
>
^ permalink raw reply
* linux-next: Signed-off-by missing for commit in the sunxi tree
From: Stephen Rothwell @ 2019-08-22 21:36 UTC (permalink / raw)
To: Maxime Ripard, Chen-Yu Tsai
Cc: Linux Next Mailing List, Linux Kernel Mailing List
[-- Attachment #1: Type: text/plain, Size: 186 bytes --]
Hi all,
Commit
c60e09f77c83 ("ARM: dts: sun8i: a83t: Enable HDMI output on Cubietruck Plus")
is missing a Signed-off-by from its committer.
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* [PATCH] ARM: dts: pbab01: correct rtc vendor
From: Alexandre Belloni @ 2019-08-22 21:35 UTC (permalink / raw)
To: Shawn Guo
Cc: kernel, Fabio Estevam, NXP Linux Team, linux-arm-kernel,
linux-kernel, Alexandre Belloni
The rtc8564 is made by Epson but is similar to the NXP pcf8563. Use the
correct vendor name.
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
---
arch/arm/boot/dts/imx6qdl-phytec-pbab01.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/imx6qdl-phytec-pbab01.dtsi b/arch/arm/boot/dts/imx6qdl-phytec-pbab01.dtsi
index 82802f8ce7a0..d434868e870a 100644
--- a/arch/arm/boot/dts/imx6qdl-phytec-pbab01.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-phytec-pbab01.dtsi
@@ -128,7 +128,7 @@
};
rtc@51 {
- compatible = "nxp,rtc8564";
+ compatible = "epson,rtc8564";
reg = <0x51>;
};
--
2.21.0
^ permalink raw reply related
* page_alloc.shuffle=1 + CONFIG_PROVE_LOCKING=y = arm64 hang
From: Qian Cai @ 2019-08-22 21:33 UTC (permalink / raw)
To: Catalin Marinas, Will Deacon
Cc: Dan Williams, linux-mm, linux-kernel, linux-arm-kernel,
Peter Zijlstra
https://raw.githubusercontent.com/cailca/linux-mm/master/arm64.config
Booting an arm64 ThunderX2 server with page_alloc.shuffle=1 [1] +
CONFIG_PROVE_LOCKING=y results in hanging.
[1] https://lore.kernel.org/linux-mm/154899811208.3165233.17623209031065121886.s
tgit@dwillia2-desk3.amr.corp.intel.com/
...
[ 125.142689][ T1] arm-smmu-v3 arm-smmu-v3.2.auto: option mask 0x2
[ 125.149687][ T1] arm-smmu-v3 arm-smmu-v3.2.auto: ias 44-bit, oas 44-bit
(features 0x0000170d)
[ 125.165198][ T1] arm-smmu-v3 arm-smmu-v3.2.auto: allocated 524288 entries
for cmdq
[ 125.239425][ [ 125.251484][ T1] arm-smmu-v3 arm-smmu-v3.3.auto: option
mask 0x2
[ 125.258233][ T1] arm-smmu-v3 arm-smmu-v3.3.auto: ias 44-bit, oas 44-bit
(features 0x0000170d)
[ 125.282750][ T1] arm-smmu-v3 arm-smmu-v3.3.auto: allocated 524288 entries
for cmdq
[ 125.320097][ T1] arm-smmu-v3 arm-smmu-v3.3.auto: allocated 524288 entries
for evtq
[ 125.332667][ T1] arm-smmu-v3 arm-smmu-v3.4.auto: option mask 0x2
[ 125.339427][ T1] arm-smmu-v3 arm-smmu-v3.4.auto: ias 44-bit, oas 44-bit
(features 0x0000170d)
[ 125.354846][ T1] arm-smmu-v3 arm-smmu-v3.4.auto: allocated 524288 entries
for cmdq
[ 125.375295][ T1] arm-smmu-v3 arm-smmu-v3.4.auto: allocated 524288 entries
for evtq
[ 125.387371][ T1] arm-smmu-v3 arm-smmu-v3.5.auto: option mask 0x2
[ 125.393955][ T1] arm-smmu-v3 arm-smmu-v3.5.auto: ias 44-bit, oas 44-bit
(features 0x0000170d)
[ 125.522605][ T1] arm-smmu-v3 arm-smmu-v3.5.auto: allocated 524288 entries
for cmdq
[ 125.543338][ T1] arm-smmu-v3 arm-smmu-v3.5.auto: allocated 524288 entries
for evtq
[ 126.694742][ T1] EFI Variables Facility v0.08 2004-May-17
[ 126.799291][ T1] NET: Registered protocol family 17
[ 126.978632][ T1] zswap: loaded using pool lzo/zbud
[ 126.989168][ T1] kmemleak: Kernel memory leak detector initialized
[ 126.989191][ T1577] kmemleak: Automatic memory scanning thread started
[ 127.044079][ T1335] pcieport 0000:0f:00.0: Adding to iommu group 0
[ 127.388074][ T1] Freeing unused kernel memory: 22528K
[ 133.527005][ T1] Checked W+X mappings: passed, no W+X pages found
[ 133.533474][ T1] Run /init as init process
[ 133.727196][ T1] systemd[1]: System time before build time, advancing
clock.
[ 134.576021][ T1587] modprobe (1587) used greatest stack depth: 27056 bytes
left
[ 134.764026][ T1] systemd[1]: systemd 239 running in system mode. (+PAM
+AUDIT +SELINUX +IMA -APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT
+GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD +IDN2 -IDN +PCRE2 default-
hierarchy=legacy)
[ 134.799044][ T1] systemd[1]: Detected architecture arm64.
[ 134.804818][ T1] systemd[1]: Running in initial RAM disk.
<...hang...>
Fix it by either set page_alloc.shuffle=0 or CONFIG_PROVE_LOCKING=n which allow
it to continue successfully.
[ 121.093846][ T1] systemd[1]: Set hostname to <hpe-apollo-cn99xx>.
[ 123.157524][ T1] random: systemd: uninitialized urandom read (16 bytes
read)
[ 123.168562][ T1] systemd[1]: Listening on Journal Socket.
[ OK ] Listening on Journal Socket.
[ 123.203932][ T1] random: systemd: uninitialized urandom read (16 bytes
read)
[ 123.212813][ T1] systemd[1]: Listening on udev Kernel Socket.
[ OK ] Listening on udev Kernel Socket.
...
^ permalink raw reply
* Re: [PATCH] /dev/mem: Bail out upon SIGKILL when reading memory.
From: Linus Torvalds @ 2019-08-22 21:29 UTC (permalink / raw)
To: Tetsuo Handa
Cc: Arnd Bergmann, Greg Kroah-Hartman, Linux List Kernel Mailing,
syzbot
In-Reply-To: <1566338811-4464-1-git-send-email-penguin-kernel@I-love.SAKURA.ne.jp>
On Tue, Aug 20, 2019 at 3:07 PM Tetsuo Handa
<penguin-kernel@i-love.sakura.ne.jp> wrote:
>
> - while (count > 0) {
> + while (count > 0 && !fatal_signal_pending(current)) {
Please just use the normal pattern of doing
if (fatal_signal_pending(current))
return -EINTR;
inside the loop instead.
(Ok, in this case I think it wants
err = -EINTR;
if (fatal_signal_pending(current))
break;
instead, but the point is to make it look like signal handling, just
with the special "fatal signals can sometimes be handled even when
regular signals might not make it through".
Linus
^ permalink raw reply
* Re: [PATCH 0/3] Perf uninitialized value fixes
From: Ian Rogers @ 2019-08-22 21:29 UTC (permalink / raw)
To: Arnaldo Carvalho de Melo
Cc: Numfor Mbiziwo-Tiapo, Peter Zijlstra, Ingo Molnar,
Alexander Shishkin, Jiri Olsa, Namhyung Kim, Song Liu, mbd, LKML,
Stephane Eranian
In-Reply-To: <20190807203812.GA20129@kernel.org>
On Wed, Aug 7, 2019 at 1:38 PM Arnaldo Carvalho de Melo
<arnaldo.melo@gmail.com> wrote:
>
> Em Wed, Jul 24, 2019 at 04:44:57PM -0700, Numfor Mbiziwo-Tiapo escreveu:
> > These patches are all warnings that the MSAN (Memory Sanitizer) build
> > of perf has caught.
> >
> > To build perf with MSAN enabled run:
> > make -C tools/perf CLANG=1 CC=clang EXTRA_CFLAGS="-fsanitize=memory\
> > -fsanitize-memory-track-origins"
> >
> > (The -fsanitizer-memory-track-origins makes the bugs clearer but
> > isn't strictly necessary.)
> >
> > (Additionally, llvm might have to be installed and clang might have to
> > be specified as the compiler - export CC=/usr/bin/clang).
> >
> > The patches "Fix util.c use of uninitialized value warning" and "Fix
> > annotate.c use of uninitialized value error" build on top of each other
> > (the changes in Fix util.c use of uninitialized value warning must be
> > made first).
> >
> > When running the commands provided in the repro instructions, MSAN will
> > generate false positive uninitialized memory errors. This is happening
> > because libc is not MSAN-instrumented. Finding a way to build libc with
> > MSAN will get rid of these false positives and allow the real warnings
> > mentioned in the patches to be shown.
>
> So this is because I'm not running a glibc linked with MSAN? Do you have
> any pointer to help building glibc with MSAN? I want to do that inside a
> container so that I can use these sanitizers, thanks,
>
> [root@quaco ~]# perf record -o - ls / | perf --no-pager annotate -i - --stdio
> ==29732==WARNING: MemorySanitizer: use-of-uninitialized-value
> ==29733==WARNING: MemorySanitizer: use-of-uninitialized-value
> #0 0xcc136d in add_path /home/acme/git/perf/tools/lib/subcmd/exec-cmd.c:130:6
> #1 0xcc075e in setup_path /home/acme/git/perf/tools/lib/subcmd/exec-cmd.c:146:2
> #2 0x71298d in main /home/acme/git/perf/tools/perf/perf.c:512:2
> #0 0xcc136d in add_path /home/acme/git/perf/tools/lib/subcmd/exec-cmd.c:130:6
> #1 0xcc075e in setup_path /home/acme/git/perf/tools/lib/subcmd/exec-cmd.c:146:2
> #2 0x71298d in main /home/acme/git/perf/tools/perf/perf.c:512:2
> #3 0x7f45b9e29f32 in __libc_start_main (/lib64/libc.so.6+0x23f32)
> #4 0x447dcd in _start (/home/acme/bin/perf+0x447dcd)
>
> Uninitialized value was created by a heap allocation
> #3 0x7fd6433cff32 in __libc_start_main (/lib64/libc.so.6+0x23f32)
> #4 0x447dcd in _start (/home/acme/bin/perf+0x447dcd)
>
> Uninitialized value was created by a heap allocation
> #0 0x4507d2 in malloc /home/acme/git/llvm/projects/compiler-rt/lib/msan/msan_interceptors.cc:916:3
> #1 0x7f45b9e7fc47 in __vasprintf_internal (/lib64/libc.so.6+0x79c47)
>
> SUMMARY: MemorySanitizer: use-of-uninitialized-value /home/acme/git/perf/tools/lib/subcmd/exec-cmd.c:130:6 in add_path
> Exiting
> #0 0x4507d2 in malloc /home/acme/git/llvm/projects/compiler-rt/lib/msan/msan_interceptors.cc:916:3
> #1 0x7fd643425c47 in __vasprintf_internal (/lib64/libc.so.6+0x79c47)
>
> SUMMARY: MemorySanitizer: use-of-uninitialized-value /home/acme/git/perf/tools/lib/subcmd/exec-cmd.c:130:6 in add_path
> Exiting
> [root@quaco ~]#
>
> > Numfor Mbiziwo-Tiapo (3):
> > Fix util.c use of uninitialized value warning
> > Fix annotate.c use of uninitialized value error
> > Fix sched-messaging.c use of uninitialized value errors
> >
> > tools/perf/bench/sched-messaging.c | 3 ++-
> > tools/perf/util/annotate.c | 15 +++++++++++----
> > tools/perf/util/header.c | 2 +-
> > 3 files changed, 14 insertions(+), 6 deletions(-)
Thanks Arnaldo! Debugging the issue it isn't down glibc, there are
interceptors in the sanitizers for asprintf to recognize it as a
source of memory allocation. The problem is the sanitizers don't
support _FORTIFY_SOURCE [1] and this is causing the false positives.
The following patch works to resolve the false-positive issue for me:
-----
--- a/tools/lib/subcmd/Makefile
+++ b/tools/lib/subcmd/Makefile
@@ -20,7 +20,13 @@ MAKEFLAGS += --no-print-directory
LIBFILE = $(OUTPUT)libsubcmd.a
CFLAGS := $(EXTRA_WARNINGS) $(EXTRA_CFLAGS)
-CFLAGS += -ggdb3 -Wall -Wextra -std=gnu99 -U_FORTIFY_SOURCE
-D_FORTIFY_SOURCE=2 -fPIC
+CFLAGS += -ggdb3 -Wall -Wextra -std=gnu99 -fPIC
+
+ifeq ($(DEBUG),0)
+ ifeq ($(feature-fortify-source), 1)
+ CFLAGS += -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2
+ endif
+endif
ifeq ($(CC_NO_CLANG), 0)
CFLAGS += -O3
-----
Thanks,
Ian
[1] https://github.com/google/sanitizers/wiki/AddressSanitizer#faq
> > --
> > 2.22.0.657.g960e92d24f-goog
>
> --
>
> - Arnaldo
^ permalink raw reply
* [PATCH 1/1] spi: spi-fsl-dspi: Exit the ISR with IRQ_NONE when it's not ours
From: Vladimir Oltean @ 2019-08-22 21:24 UTC (permalink / raw)
To: broonie; +Cc: linux-spi, linux-kernel, Vladimir Oltean
In-Reply-To: <20190822212450.21420-1-olteanv@gmail.com>
The DSPI interrupt can be shared between two controllers at least on the
LX2160A. In that case, the driver for one controller might misbehave and
consume the other's interrupt. Fix this by actually checking if any of
the bits in the status register have been asserted.
Fixes: 13aed2392741 ("spi: spi-fsl-dspi: use IRQF_SHARED mode to request IRQ")
Signed-off-by: Vladimir Oltean <olteanv@gmail.com>
---
drivers/spi/spi-fsl-dspi.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/spi/spi-fsl-dspi.c b/drivers/spi/spi-fsl-dspi.c
index 5e10dc5c93a5..6c2a30f9d85b 100644
--- a/drivers/spi/spi-fsl-dspi.c
+++ b/drivers/spi/spi-fsl-dspi.c
@@ -874,9 +874,11 @@ static irqreturn_t dspi_interrupt(int irq, void *dev_id)
trans_mode);
}
}
+
+ return IRQ_HANDLED;
}
- return IRQ_HANDLED;
+ return IRQ_NONE;
}
static const struct of_device_id fsl_dspi_dt_ids[] = {
--
2.17.1
^ permalink raw reply related
* [PATCH 0/1] Fix shared IRQ behavior in spi-fsl-dspi
From: Vladimir Oltean @ 2019-08-22 21:24 UTC (permalink / raw)
To: broonie; +Cc: linux-spi, linux-kernel, Vladimir Oltean
This patch is taken out of the "Poll mode for NXP DSPI driver" series
and respun against the "for-4.20" branch.
$(git describe --tags 13aed2392741) shows:
v4.20-rc1-18-g13aed2392741
Vladimir Oltean (1):
spi: spi-fsl-dspi: Exit the ISR with IRQ_NONE when it's not ours
drivers/spi/spi-fsl-dspi.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
--
2.17.1
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox