* Re: [PATCH] fork: fix kmemleak false positive due to thread stacks caching
From: Luis Henriques @ 2017-05-26 15:06 UTC (permalink / raw)
To: Catalin Marinas
Cc: Andy Lutomirski, Ingo Molnar, Andrew Morton, Michal Hocko,
Thomas Gleixner, Eric W . Biederman, Peter Zijlstra,
Oleg Nesterov, Mateusz Guzik, linux-kernel, stable
In-Reply-To: <20170526142254.GB30853@e104818-lin.cambridge.arm.com>
On Fri, May 26, 2017 at 03:22:54PM +0100, Catalin Marinas wrote:
> On Fri, May 26, 2017 at 02:49:49PM +0100, Luis Henriques wrote:
> > kmemleak has been reporting memory leaks since commit ac496bf48d97 ("fork:
> > Optimize task creation by caching two thread stacks per CPU if
> > CONFIG_VMAP_STACK=y"):
> >
> > unreferenced object 0xffffc900002b0000 (size 16384):
> > comm "init", pid 147, jiffies 4294893306 (age 11.292s)
> > hex dump (first 32 bytes):
> > 9d 6e ac 57 00 00 00 00 00 00 00 00 00 00 00 00 .n.W............
> > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
> > backtrace:
> > [<ffffffff815b481e>] kmemleak_alloc+0x4e/0xb0
> > [<ffffffff8112a8b0>] __vmalloc_node_range+0x160/0x240
> > [<ffffffff8104a328>] copy_process.part.8+0x478/0x1630
> > [<ffffffff8104b69a>] _do_fork+0xca/0x330
> > [<ffffffff8104b9a9>] SyS_clone+0x19/0x20
> > [<ffffffff8100199c>] do_syscall_64+0x4c/0xb0
> > [<ffffffff815b8d06>] return_from_SYSCALL_64+0x0/0x6a
> > [<ffffffffffffffff>] 0xffffffffffffffff
> >
> > This is because this commit started caching 2 thread stacks per CPU, and
> > kmemleak assumes its memory is never freed. Report these stacks as not
> > being memory leaks using kmemleak_not_leak().
> >
> > Cc: stable@vger.kernel.org
> > Fixes: ac496bf48d97 ("fork: Optimize task creation by caching two thread stacks per CPU if CONFIG_VMAP_STACK=y")
> > Signed-off-by: Luis Henriques <lhenriques@suse.com>
>
> I guess that's meant as a 4.12 and earlier fix until the
> kmemleak_vmalloc() patches go in
> (http://lkml.kernel.org/r/1495726937-23557-1-git-send-email-catalin.marinas@arm.com)
>
> > diff --git a/kernel/fork.c b/kernel/fork.c
> > index aa1076c5e4a9..c4d79ad0f5bc 100644
> > --- a/kernel/fork.c
> > +++ b/kernel/fork.c
> > @@ -255,6 +255,7 @@ static inline void free_thread_stack(struct task_struct *tsk)
> >
> > this_cpu_write(cached_stacks[i], tsk->stack_vm_area);
> > local_irq_restore(flags);
> > + kmemleak_not_leak(tsk->stack);
>
> I would add a comment here on why the annotation is needed.
>
> The disadvantage is that such objects would no longer be detected as
> leaks since kmemleak doesn't have a way to "unignore" an object (I have
> a patch but not worth merging since we'll fix the above with a dedicated
> kmemleak_vmalloc() API). We could however work around this with the
> current kmemleak API as in this patch:
>
> http://lkml.kernel.org/r/20170516133925.GA9453@e104818-lin.cambridge.arm.com
Ok, looks like I need to improve my lkml search-fu -- I totally missed
this discussion and the patchset with the new API!
So, I guess it only makes sense to work around this issue with the current
API when backporting the fix to stable kernels, in case you think it's
worth fixing this in older kernels, of course. (Or maybe if this new API
doesn't make it into 4.12...)
Anyway, thanks for pointing me at this patchset Catalin. I'll have a look
at it.
Cheers,
--
Lu�s
^ permalink raw reply
* Re: + mm-migrate-fix-ref-count-handling-when-hugepage_migration_supported-v2.patch added to -mm tree
From: Mel Gorman @ 2017-05-26 15:33 UTC (permalink / raw)
To: Punit Agrawal
Cc: akpm, cl, iamjoonsoo.kim, manoj.iyer, n-horiguchi, stable,
wanpeng.li, mm-commits
In-Reply-To: <87bmqfd61m.fsf@e105922-lin.cambridge.arm.com>
On Fri, May 26, 2017 at 03:52:21PM +0100, Punit Agrawal wrote:
> > I've never looked too closely at how hardware poisoning and hugetlb pages
> > migration is handled so I could easily have missed something but this
> > changelog and patch confuses me.
> >
> > Surely if the inconsistency is between hugepage_migration_supported and
> > !hugepage_migration_supported then the check in soft_offline_huge_page()
> > should also be related to hugepage_migration_supported either in
> > soft_offline_huge_page() or in putback_movable_pages()?
>
> The first version of the patch did indeed make a change that was around
> !hugepage_migration_supported() [0] which was effectively a revert of
> 32665f2bbfed ("mm/migrate: correct failure handling if
> !hugepage_migration_support()").
>
> But Horiguchi-san suggested that dropping the putback_active_hugepage()
> from unmap_and_move_hugepage() will bring back the issue that
> 32665f2bbfed addressed it was safer to take the current approach. It
> also matches the pattern followed for !hugepage.
>
> I did update the changelog but perhaps not enough - would updating the
> changelog to reflect this help make it clearer?
>
Ok, I see what the patch is doing now. I don't think you need to alter
the changelog as I think the patch is ok.
Thanks for clarifying.
--
Mel Gorman
SUSE Labs
^ permalink raw reply
* [PATCH] dax: improve fix for colliding PMD & PTE entries
From: Ross Zwisler @ 2017-05-26 19:59 UTC (permalink / raw)
To: Andrew Morton, linux-kernel
Cc: Ross Zwisler, Darrick J. Wong, Alexander Viro, Christoph Hellwig,
Dan Williams, Dave Hansen, Jan Kara, Matthew Wilcox,
linux-fsdevel, linux-mm, linux-nvdimm, Kirill A . Shutemov,
Pawel Lebioda, Dave Jiang, Xiong Zhou, Eryu Guan, stable
In-Reply-To: <20170522215749.23516-2-ross.zwisler@linux.intel.com>
This commit, which has not yet made it upstream but is in the -mm tree:
dax: Fix race between colliding PMD & PTE entries
fixed a pair of race conditions where racing DAX PTE and PMD faults could
corrupt page tables. This fix had two shortcomings which are addressed by
this patch:
1) In the PTE fault handler we only checked for a collision using
pmd_devmap(). The pmd_devmap() check will trigger when we have raced with
a PMD that has real DAX storage, but to account for the case where we
collide with a huge zero page entry we also need to check for
pmd_trans_huge().
2) In the PMD fault handler we only continued with the fault if no PMD at
all was present (pmd_none()). This is the case when we are faulting in a
PMD for the first time, but there are two other cases to consider. The
first is that we are servicing a write fault over a PMD huge zero page,
which we detect with pmd_trans_huge(). The second is that we are servicing
a write fault over a DAX PMD with real storage, which we address with
pmd_devmap().
Fix both of these, and instead of manually triggering a fallback in the PMD
collision case instead be consistent with the other collision detection
code in the fault handlers and just retry.
Signed-off-by: Ross Zwisler <ross.zwisler@linux.intel.com>
Cc: stable@vger.kernel.org
---
For both the -mm tree and for stable, feel free to squash this with the
original commit if you think that is appropriate.
This has passed targeted testing and an xfstests run.
---
fs/dax.c | 11 +++++++----
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/fs/dax.c b/fs/dax.c
index fc62f36..2a6889b 100644
--- a/fs/dax.c
+++ b/fs/dax.c
@@ -1160,7 +1160,7 @@ static int dax_iomap_pte_fault(struct vm_fault *vmf,
* the PTE we need to set up. If so just return and the fault will be
* retried.
*/
- if (pmd_devmap(*vmf->pmd)) {
+ if (pmd_trans_huge(*vmf->pmd) || pmd_devmap(*vmf->pmd)) {
vmf_ret = VM_FAULT_NOPAGE;
goto unlock_entry;
}
@@ -1411,11 +1411,14 @@ static int dax_iomap_pmd_fault(struct vm_fault *vmf,
/*
* It is possible, particularly with mixed reads & writes to private
* mappings, that we have raced with a PTE fault that overlaps with
- * the PMD we need to set up. If so we just fall back to a PTE fault
- * ourselves.
+ * the PMD we need to set up. If so just return and the fault will be
+ * retried.
*/
- if (!pmd_none(*vmf->pmd))
+ if (!pmd_none(*vmf->pmd) && !pmd_trans_huge(*vmf->pmd) &&
+ !pmd_devmap(*vmf->pmd)) {
+ result = 0;
goto unlock_entry;
+ }
/*
* Note that we don't use iomap_apply here. We aren't doing I/O, only
--
2.9.4
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply related
* [stable backport PATCH] usercopy: Adjust tests to deal with SMAP/PAN
From: Arnd Bergmann @ 2017-05-26 20:40 UTC (permalink / raw)
To: stable, Kees Cook, Arnd Bergmann
Cc: linux-arm-kernel, mark.rutland, gregkh, linux-kernel
From: Kees Cook <keescook@chromium.org>
Commit f5f893c57e37ca730808cb2eee3820abd05e7507 upstream.
Under SMAP/PAN/etc, we cannot write directly to userspace memory, so
this rearranges the test bytes to get written through copy_to_user().
Additionally drops the bad copy_from_user() test that would trigger a
memcpy() against userspace on failure.
[arnd: the test module was added in 3.14, and this backported patch
should apply cleanly on all version from 3.14 to 4.10.
The original patch was in 4.11 on top of a context change.
I saw the bug triggered with kselftest on a 4.4.y stable kernel]
Signed-off-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
lib/test_user_copy.c | 21 +++++++++++++++++++--
1 file changed, 19 insertions(+), 2 deletions(-)
diff --git a/lib/test_user_copy.c b/lib/test_user_copy.c
index 0ecef3e4690e..b16891d01112 100644
--- a/lib/test_user_copy.c
+++ b/lib/test_user_copy.c
@@ -58,7 +58,9 @@ static int __init test_user_copy_init(void)
usermem = (char __user *)user_addr;
bad_usermem = (char *)user_addr;
- /* Legitimate usage: none of these should fail. */
+ /*
+ * Legitimate usage: none of these copies should fail.
+ */
ret |= test(copy_from_user(kmem, usermem, PAGE_SIZE),
"legitimate copy_from_user failed");
ret |= test(copy_to_user(usermem, kmem, PAGE_SIZE),
@@ -68,19 +70,34 @@ static int __init test_user_copy_init(void)
ret |= test(put_user(value, (unsigned long __user *)usermem),
"legitimate put_user failed");
- /* Invalid usage: none of these should succeed. */
+ /*
+ * Invalid usage: none of these copies should succeed.
+ */
+
+ /* Reject kernel-to-kernel copies through copy_from_user(). */
ret |= test(!copy_from_user(kmem, (char __user *)(kmem + PAGE_SIZE),
PAGE_SIZE),
"illegal all-kernel copy_from_user passed");
+
+#if 0
+ /*
+ * When running with SMAP/PAN/etc, this will Oops the kernel
+ * due to the zeroing of userspace memory on failure. This needs
+ * to be tested in LKDTM instead, since this test module does not
+ * expect to explode.
+ */
ret |= test(!copy_from_user(bad_usermem, (char __user *)kmem,
PAGE_SIZE),
"illegal reversed copy_from_user passed");
+#endif
ret |= test(!copy_to_user((char __user *)kmem, kmem + PAGE_SIZE,
PAGE_SIZE),
"illegal all-kernel copy_to_user passed");
ret |= test(!copy_to_user((char __user *)kmem, bad_usermem,
PAGE_SIZE),
"illegal reversed copy_to_user passed");
+
+ value = 0x5a;
ret |= test(!get_user(value, (unsigned long __user *)kmem),
"illegal get_user passed");
ret |= test(!put_user(value, (unsigned long __user *)kmem),
--
2.9.0
^ permalink raw reply related
* Re: [stable backport PATCH] usercopy: Adjust tests to deal with SMAP/PAN
From: Kees Cook @ 2017-05-26 20:53 UTC (permalink / raw)
To: Arnd Bergmann
Cc: # 3.4.x, Mark Rutland, Greg KH, LKML,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <20170526204040.1953914-1-arnd@arndb.de>
On Fri, May 26, 2017 at 1:40 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> From: Kees Cook <keescook@chromium.org>
>
> Commit f5f893c57e37ca730808cb2eee3820abd05e7507 upstream.
>
> Under SMAP/PAN/etc, we cannot write directly to userspace memory, so
> this rearranges the test bytes to get written through copy_to_user().
> Additionally drops the bad copy_from_user() test that would trigger a
> memcpy() against userspace on failure.
>
> [arnd: the test module was added in 3.14, and this backported patch
> should apply cleanly on all version from 3.14 to 4.10.
> The original patch was in 4.11 on top of a context change.
> I saw the bug triggered with kselftest on a 4.4.y stable kernel]
>
> Signed-off-by: Kees Cook <keescook@chromium.org>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
> lib/test_user_copy.c | 21 +++++++++++++++++++--
> 1 file changed, 19 insertions(+), 2 deletions(-)
>
> diff --git a/lib/test_user_copy.c b/lib/test_user_copy.c
> index 0ecef3e4690e..b16891d01112 100644
> --- a/lib/test_user_copy.c
> +++ b/lib/test_user_copy.c
> @@ -58,7 +58,9 @@ static int __init test_user_copy_init(void)
> usermem = (char __user *)user_addr;
> bad_usermem = (char *)user_addr;
>
> - /* Legitimate usage: none of these should fail. */
> + /*
> + * Legitimate usage: none of these copies should fail.
> + */
> ret |= test(copy_from_user(kmem, usermem, PAGE_SIZE),
> "legitimate copy_from_user failed");
> ret |= test(copy_to_user(usermem, kmem, PAGE_SIZE),
> @@ -68,19 +70,34 @@ static int __init test_user_copy_init(void)
> ret |= test(put_user(value, (unsigned long __user *)usermem),
> "legitimate put_user failed");
>
> - /* Invalid usage: none of these should succeed. */
> + /*
> + * Invalid usage: none of these copies should succeed.
> + */
> +
> + /* Reject kernel-to-kernel copies through copy_from_user(). */
> ret |= test(!copy_from_user(kmem, (char __user *)(kmem + PAGE_SIZE),
> PAGE_SIZE),
> "illegal all-kernel copy_from_user passed");
> +
> +#if 0
> + /*
> + * When running with SMAP/PAN/etc, this will Oops the kernel
> + * due to the zeroing of userspace memory on failure. This needs
> + * to be tested in LKDTM instead, since this test module does not
> + * expect to explode.
> + */
> ret |= test(!copy_from_user(bad_usermem, (char __user *)kmem,
> PAGE_SIZE),
> "illegal reversed copy_from_user passed");
> +#endif
> ret |= test(!copy_to_user((char __user *)kmem, kmem + PAGE_SIZE,
> PAGE_SIZE),
> "illegal all-kernel copy_to_user passed");
> ret |= test(!copy_to_user((char __user *)kmem, bad_usermem,
> PAGE_SIZE),
> "illegal reversed copy_to_user passed");
> +
> + value = 0x5a;
I don't think this "value" bit wanted, but it should be harmless.
-Kees
> ret |= test(!get_user(value, (unsigned long __user *)kmem),
> "illegal get_user passed");
> ret |= test(!put_user(value, (unsigned long __user *)kmem),
> --
> 2.9.0
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
Kees Cook
Pixel Security
^ permalink raw reply
* [stable backport PATCH v2] usercopy: Adjust tests to deal with SMAP/PAN
From: Arnd Bergmann @ 2017-05-26 20:56 UTC (permalink / raw)
To: stable
Cc: linux-arm-kernel, mark.rutland, keescook, gregkh, Arnd Bergmann,
linux-kernel
From: Kees Cook <keescook@chromium.org>
Commit f5f893c57e37ca730808cb2eee3820abd05e7507 upstream.
Under SMAP/PAN/etc, we cannot write directly to userspace memory, so
this rearranges the test bytes to get written through copy_to_user().
Additionally drops the bad copy_from_user() test that would trigger a
memcpy() against userspace on failure.
[arnd: the test module was added in 3.14, and this backported patch
should apply cleanly on all version from 3.14 to 4.10.
The original patch was in 4.11 on top of a context change
I saw the bug triggered with kselftest on a 4.4.y stable kernel]
Signed-off-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
v2: remove a line that accidentally ended up from upstream version
but is not part of the fix.
---
lib/test_user_copy.c | 20 ++++++++++++++++++--
1 file changed, 18 insertions(+), 2 deletions(-)
diff --git a/lib/test_user_copy.c b/lib/test_user_copy.c
index 0ecef3e4690e..5e6db6b1e3bd 100644
--- a/lib/test_user_copy.c
+++ b/lib/test_user_copy.c
@@ -58,7 +58,9 @@ static int __init test_user_copy_init(void)
usermem = (char __user *)user_addr;
bad_usermem = (char *)user_addr;
- /* Legitimate usage: none of these should fail. */
+ /*
+ * Legitimate usage: none of these copies should fail.
+ */
ret |= test(copy_from_user(kmem, usermem, PAGE_SIZE),
"legitimate copy_from_user failed");
ret |= test(copy_to_user(usermem, kmem, PAGE_SIZE),
@@ -68,19 +70,33 @@ static int __init test_user_copy_init(void)
ret |= test(put_user(value, (unsigned long __user *)usermem),
"legitimate put_user failed");
- /* Invalid usage: none of these should succeed. */
+ /*
+ * Invalid usage: none of these copies should succeed.
+ */
+
+ /* Reject kernel-to-kernel copies through copy_from_user(). */
ret |= test(!copy_from_user(kmem, (char __user *)(kmem + PAGE_SIZE),
PAGE_SIZE),
"illegal all-kernel copy_from_user passed");
+
+#if 0
+ /*
+ * When running with SMAP/PAN/etc, this will Oops the kernel
+ * due to the zeroing of userspace memory on failure. This needs
+ * to be tested in LKDTM instead, since this test module does not
+ * expect to explode.
+ */
ret |= test(!copy_from_user(bad_usermem, (char __user *)kmem,
PAGE_SIZE),
"illegal reversed copy_from_user passed");
+#endif
ret |= test(!copy_to_user((char __user *)kmem, kmem + PAGE_SIZE,
PAGE_SIZE),
"illegal all-kernel copy_to_user passed");
ret |= test(!copy_to_user((char __user *)kmem, bad_usermem,
PAGE_SIZE),
"illegal reversed copy_to_user passed");
+
ret |= test(!get_user(value, (unsigned long __user *)kmem),
"illegal get_user passed");
ret |= test(!put_user(value, (unsigned long __user *)kmem),
--
2.9.0
^ permalink raw reply related
* Re: [stable backport PATCH] usercopy: Adjust tests to deal with SMAP/PAN
From: Arnd Bergmann @ 2017-05-26 20:57 UTC (permalink / raw)
To: Kees Cook
Cc: # 3.4.x, Mark Rutland, Greg KH, LKML,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <CAGXu5jLa2QEcg9DcKtkqxL1fCzGznhg586-ZDOoXzjF8z0FE1Q@mail.gmail.com>
On Fri, May 26, 2017 at 10:53 PM, Kees Cook <keescook@chromium.org> wrote:
>> +
>> + value = 0x5a;
>
> I don't think this "value" bit wanted, but it should be harmless.
>
Right, that should not be there, it came from a different patch.
I've sent a new version of the backport now. Thanks for taking a look.
Arnd
^ permalink raw reply
* Re: [PATCH] ext4: Fix data corruption with EXT4_GET_BLOCKS_ZERO
From: Theodore Ts'o @ 2017-05-26 21:44 UTC (permalink / raw)
To: Jan Kara; +Cc: linux-ext4, Ross Zwisler, stable
In-Reply-To: <20170525084313.29894-1-jack@suse.cz>
On Thu, May 25, 2017 at 10:43:13AM +0200, Jan Kara wrote:
> When ext4_map_blocks() is called with EXT4_GET_BLOCKS_ZERO to zero-out
> allocated blocks and these blocks are actually converted from unwritten
> extent the following race can happen:
>
> CPU0 CPU1
>
> page fault page fault
> ... ...
> ext4_map_blocks()
> ext4_ext_map_blocks()
> ext4_ext_handle_unwritten_extents()
> ext4_ext_convert_to_initialized()
> - zero out converted extent
> ext4_zeroout_es()
> - inserts extent as initialized in status tree
>
> ext4_map_blocks()
> ext4_es_lookup_extent()
> - finds initialized extent
> write data
> ext4_issue_zeroout()
> - zeroes out new extent overwriting data
>
> This problem can be reproduced by generic/340 for the fallocated case
> for the last block in the file.
>
> Fix the problem by avoiding zeroing out the area we are mapping with
> ext4_map_blocks() in ext4_ext_convert_to_initialized(). It is pointless
> to zero out this area in the first place as the caller asked us to
> convert the area to initialized because he is just going to write data
> there before the transaction finishes. To achieve this we delete the
> special case of zeroing out full extent as that will be handled by the
> cases below zeroing only the part of the extent that needs it. We also
> instruct ext4_split_extent() that the middle of extent being split
> contains data so that ext4_split_extent_at() cannot zero out full extent
> in case of ENOSPC.
>
> CC: stable@vger.kernel.org
> Fixes: 12735f881952c32b31bc4e433768f18489f79ec9
> Signed-off-by: Jan Kara <jack@suse.cz>
Thanks, applied.
- Ted
^ permalink raw reply
* Re: [PATCH] ext4: Fix data corruption for mmap writes
From: Theodore Ts'o @ 2017-05-26 23:02 UTC (permalink / raw)
To: Jan Kara; +Cc: linux-ext4, Michael Zimmer, stable
In-Reply-To: <20170525114622.1543-1-jack@suse.cz>
On Thu, May 25, 2017 at 01:46:22PM +0200, Jan Kara wrote:
> mpage_submit_page() can race with another process growing i_size and
> writing data via mmap to the written-back page. As mpage_submit_page()
> samples i_size too early, it may happen that ext4_bio_write_page()
> zeroes out too large tail of the page and thus corrupts user data.
>
> Fix the problem by sampling i_size only after the page has been
> write-protected in page tables by clear_page_dirty_for_io() call.
>
> Reported-by: Michael Zimmer <michael@swarm64.com>
> CC: stable@vger.kernel.org
> Fixes: cb20d5188366f04d96d2e07b1240cc92170ade40
> Signed-off-by: Jan Kara <jack@suse.cz>
Thanks, applied.
- Ted
^ permalink raw reply
* [PATCH 1/5] ftrace: Fix memory leak in ftrace_graph_release()
From: Steven Rostedt @ 2017-05-27 2:48 UTC (permalink / raw)
To: linux-kernel
Cc: Linus Torvalds, Ingo Molnar, Andrew Morton, Thomas Gleixner,
Masami Hiramatsu, stable, Luis Henriques
In-Reply-To: <20170527024813.934870008@goodmis.org>
[-- Attachment #1: 0001-ftrace-Fix-memory-leak-in-ftrace_graph_release.patch --]
[-- Type: text/plain, Size: 1900 bytes --]
From: Luis Henriques <lhenriques@suse.com>
ftrace_hash is being kfree'ed in ftrace_graph_release(), however the
->buckets field is not. This results in a memory leak that is easily
captured by kmemleak:
unreferenced object 0xffff880038afe000 (size 8192):
comm "trace-cmd", pid 238, jiffies 4294916898 (age 9.736s)
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
backtrace:
[<ffffffff815f561e>] kmemleak_alloc+0x4e/0xb0
[<ffffffff8113964d>] __kmalloc+0x12d/0x1a0
[<ffffffff810bf6d1>] alloc_ftrace_hash+0x51/0x80
[<ffffffff810c0523>] __ftrace_graph_open.isra.39.constprop.46+0xa3/0x100
[<ffffffff810c05e8>] ftrace_graph_open+0x68/0xa0
[<ffffffff8114003d>] do_dentry_open.isra.1+0x1bd/0x2d0
[<ffffffff81140df7>] vfs_open+0x47/0x60
[<ffffffff81150f95>] path_openat+0x2a5/0x1020
[<ffffffff81152d6a>] do_filp_open+0x8a/0xf0
[<ffffffff811411df>] do_sys_open+0x12f/0x200
[<ffffffff811412ce>] SyS_open+0x1e/0x20
[<ffffffff815fa6e0>] entry_SYSCALL_64_fastpath+0x13/0x94
[<ffffffffffffffff>] 0xffffffffffffffff
Link: http://lkml.kernel.org/r/20170525152038.7661-1-lhenriques@suse.com
Cc: stable@vger.kernel.org
Fixes: b9b0c831bed2 ("ftrace: Convert graph filter to use hash tables")
Signed-off-by: Luis Henriques <lhenriques@suse.com>
Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
---
kernel/trace/ftrace.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/trace/ftrace.c b/kernel/trace/ftrace.c
index 74fdfe9ed3db..9e5841dc14b5 100644
--- a/kernel/trace/ftrace.c
+++ b/kernel/trace/ftrace.c
@@ -5063,7 +5063,7 @@ ftrace_graph_release(struct inode *inode, struct file *file)
}
out:
- kfree(fgd->new_hash);
+ free_ftrace_hash(fgd->new_hash);
kfree(fgd);
return ret;
--
2.10.2
^ permalink raw reply related
* Re: [PATCH] fs: pass on flags in compat_writev
From: Christoph Hellwig @ 2017-05-27 8:14 UTC (permalink / raw)
To: Christoph Hellwig; +Cc: viro, linux-fsdevel, stable
In-Reply-To: <20170510063748.1088-1-hch@lst.de>
ping? I think this fix is something for 4.12-rc and stable.
And also needed for the series I'm about to send :)
On Wed, May 10, 2017 at 08:37:48AM +0200, Christoph Hellwig wrote:
> Fixes: 793b80ef ("vfs: pass a flags argument to vfs_readv/vfs_writev")
> Signed-off-by: Christoph Hellwig <hch@lst.de>
> Cc: stable@vger.kernel.org
> ---
> fs/read_write.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/fs/read_write.c b/fs/read_write.c
> index 47c1d4484df9..19d4d88fa285 100644
> --- a/fs/read_write.c
> +++ b/fs/read_write.c
> @@ -1285,7 +1285,7 @@ static size_t compat_writev(struct file *file,
> if (!(file->f_mode & FMODE_CAN_WRITE))
> goto out;
>
> - ret = compat_do_readv_writev(WRITE, file, vec, vlen, pos, 0);
> + ret = compat_do_readv_writev(WRITE, file, vec, vlen, pos, flags);
>
> out:
> if (ret > 0)
> --
> 2.11.0
>
---end quoted text---
^ permalink raw reply
* [PATCH 01/10] fs: pass on flags in compat_writev
From: Christoph Hellwig @ 2017-05-27 8:16 UTC (permalink / raw)
To: Alexander Viro
Cc: J. Bruce Fields, Jeff Layton, linux-nfs, linux-fsdevel, stable
In-Reply-To: <20170527081654.15957-1-hch@lst.de>
Fixes: 793b80ef ("vfs: pass a flags argument to vfs_readv/vfs_writev")
Signed-off-by: Christoph Hellwig <hch@lst.de>
Cc: stable@vger.kernel.org
---
fs/read_write.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/read_write.c b/fs/read_write.c
index 47c1d4484df9..19d4d88fa285 100644
--- a/fs/read_write.c
+++ b/fs/read_write.c
@@ -1285,7 +1285,7 @@ static size_t compat_writev(struct file *file,
if (!(file->f_mode & FMODE_CAN_WRITE))
goto out;
- ret = compat_do_readv_writev(WRITE, file, vec, vlen, pos, 0);
+ ret = compat_do_readv_writev(WRITE, file, vec, vlen, pos, flags);
out:
if (ret > 0)
--
2.11.0
^ permalink raw reply related
* Patch "Revert "stackprotector: Increase the per-task stack canary's random range from 32 bits to 64 bits on 64-bit platforms"" has been added to the 3.18-stable tree
From: gregkh @ 2017-05-27 10:13 UTC (permalink / raw)
To: gregkh, arjan, danielmicay, keescook, mingo, peterz, philm, riel,
tglx, torvalds
Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
Revert "stackprotector: Increase the per-task stack canary's random range from 32 bits to 64 bits on 64-bit platforms"
to the 3.18-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
revert-stackprotector-increase-the-per-task-stack-canary-s-random-range-from-32-bits-to-64-bits-on-64-bit-platforms.patch
and it can be found in the queue-3.18 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.
>From bc67a9f0ba89051916f192895317a0b5a431ad7e Mon Sep 17 00:00:00 2001
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date: Sat, 27 May 2017 12:09:37 +0200
Subject: Revert "stackprotector: Increase the per-task stack canary's random range from 32 bits to 64 bits on 64-bit platforms"
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This reverts commit 609a3e81550b0b4ea87197b0f59455a7bcff975a which is
commit 5ea30e4e58040cfd6434c2f33dc3ea76e2c15b05 upstream.
It shouldn't have been backported to 3.18, as we do not have
get_random_long() in that kernel tree.
Reported-by: Philip Müller <philm@manjaro.org>
Cc: Daniel Micay <danielmicay@gmail.com>
Cc: Arjan van de Ven <arjan@linux.intel.com>
Cc: Rik van Riel <riel@redhat.com>
Cc: Kees Cook <keescook@chromium.org>
Cc: Arjan van Ven <arjan@linux.intel.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: kernel-hardening@lists.openwall.com
Cc: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
kernel/fork.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/kernel/fork.c
+++ b/kernel/fork.c
@@ -338,7 +338,7 @@ static struct task_struct *dup_task_stru
set_task_stack_end_magic(tsk);
#ifdef CONFIG_CC_STACKPROTECTOR
- tsk->stack_canary = get_random_long();
+ tsk->stack_canary = get_random_int();
#endif
/*
Patches currently in stable-queue which might be from gregkh@linuxfoundation.org are
queue-3.18/revert-stackprotector-increase-the-per-task-stack-canary-s-random-range-from-32-bits-to-64-bits-on-64-bit-platforms.patch
^ permalink raw reply
* [PATCH] staging/lustre/lov: remove set_fs() call from lov_getstripe()
From: Oleg Drokin @ 2017-05-27 19:22 UTC (permalink / raw)
To: linux-stable
lov_getstripe() calls set_fs(KERNEL_DS) so that it can handle a struct
lov_user_md pointer from user- or kernel-space. This changes the
behavior of copy_from_user() on SPARC and may result in a misaligned
access exception which in turn oopses the kernel. In fact the
relevant argument to lov_getstripe() is never called with a
kernel-space pointer and so changing the address limits is unnecessary
and so we remove the calls to save, set, and restore the address
limits.
Signed-off-by: John L. Hammond <john.hammond@intel.com>
Reviewed-on: http://review.whamcloud.com/6150
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-3221
Reviewed-by: Andreas Dilger <andreas.dilger@intel.com>
Reviewed-by: Li Wei <wei.g.li@intel.com>
CC: linux-stable <stable@vger.kernel.org> # >= v3.11
Signed-off-by: Oleg Drokin <green@linuxhacker.ru>
---
drivers/staging/lustre/lustre/lov/lov_pack.c | 9 ---------
1 file changed, 9 deletions(-)
diff --git a/drivers/staging/lustre/lustre/lov/lov_pack.c b/drivers/staging/lustre/lustre/lov/lov_pack.c
index 2e1bd47..e6727ce 100644
--- a/drivers/staging/lustre/lustre/lov/lov_pack.c
+++ b/drivers/staging/lustre/lustre/lov/lov_pack.c
@@ -293,18 +293,10 @@ int lov_getstripe(struct lov_object *obj, struct lov_stripe_md *lsm,
size_t lmmk_size;
size_t lum_size;
int rc;
- mm_segment_t seg;
if (!lsm)
return -ENODATA;
- /*
- * "Switch to kernel segment" to allow copying from kernel space by
- * copy_{to,from}_user().
- */
- seg = get_fs();
- set_fs(KERNEL_DS);
-
if (lsm->lsm_magic != LOV_MAGIC_V1 && lsm->lsm_magic != LOV_MAGIC_V3) {
CERROR("bad LSM MAGIC: 0x%08X != 0x%08X nor 0x%08X\n",
lsm->lsm_magic, LOV_MAGIC_V1, LOV_MAGIC_V3);
@@ -406,6 +398,5 @@ int lov_getstripe(struct lov_object *obj, struct lov_stripe_md *lsm,
out_free:
kvfree(lmmk);
out:
- set_fs(seg);
return rc;
}
--
2.9.3
^ permalink raw reply related
* Re: [PATCH] staging/lustre/lov: remove set_fs() call from lov_getstripe()
From: Greg KH @ 2017-05-27 20:26 UTC (permalink / raw)
To: Oleg Drokin; +Cc: linux-stable
In-Reply-To: <B9839FA4-B361-4983-87E1-5F6BF9CCA6AD@linuxhacker.ru>
On Sat, May 27, 2017 at 03:22:18PM -0400, Oleg Drokin wrote:
> lov_getstripe() calls set_fs(KERNEL_DS) so that it can handle a struct
> lov_user_md pointer from user- or kernel-space. This changes the
> behavior of copy_from_user() on SPARC and may result in a misaligned
> access exception which in turn oopses the kernel. In fact the
> relevant argument to lov_getstripe() is never called with a
> kernel-space pointer and so changing the address limits is unnecessary
> and so we remove the calls to save, set, and restore the address
> limits.
>
> Signed-off-by: John L. Hammond <john.hammond@intel.com>
> Reviewed-on: http://review.whamcloud.com/6150
> Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-3221
> Reviewed-by: Andreas Dilger <andreas.dilger@intel.com>
> Reviewed-by: Li Wei <wei.g.li@intel.com>
> CC: linux-stable <stable@vger.kernel.org> # >= v3.11
> Signed-off-by: Oleg Drokin <green@linuxhacker.ru>
> ---
> drivers/staging/lustre/lustre/lov/lov_pack.c | 9 ---------
> 1 file changed, 9 deletions(-)
What was the git commit id of this patch in Linus's tree?
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH] staging/lustre/lov: remove set_fs() call from lov_getstripe()
From: Oleg Drokin @ 2017-05-27 22:38 UTC (permalink / raw)
To: Greg KH; +Cc: linux-stable
In-Reply-To: <20170527202629.GA16472@kroah.com>
On May 27, 2017, at 4:26 PM, Greg KH wrote:
> On Sat, May 27, 2017 at 03:22:18PM -0400, Oleg Drokin wrote:
>> lov_getstripe() calls set_fs(KERNEL_DS) so that it can handle a struct
>> lov_user_md pointer from user- or kernel-space. This changes the
>> behavior of copy_from_user() on SPARC and may result in a misaligned
>> access exception which in turn oopses the kernel. In fact the
>> relevant argument to lov_getstripe() is never called with a
>> kernel-space pointer and so changing the address limits is unnecessary
>> and so we remove the calls to save, set, and restore the address
>> limits.
>>
>> Signed-off-by: John L. Hammond <john.hammond@intel.com>
>> Reviewed-on: http://review.whamcloud.com/6150
>> Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-3221
>> Reviewed-by: Andreas Dilger <andreas.dilger@intel.com>
>> Reviewed-by: Li Wei <wei.g.li@intel.com>
>> CC: linux-stable <stable@vger.kernel.org> # >= v3.11
>> Signed-off-by: Oleg Drokin <green@linuxhacker.ru>
>> ---
>> drivers/staging/lustre/lustre/lov/lov_pack.c | 9 ---------
>> 1 file changed, 9 deletions(-)
>
> What was the git commit id of this patch in Linus's tree?
It's not in Linus tree yet.
I was just informed that this patch should go to stable by Al, so I added stable
to the list.
^ permalink raw reply
* Re: [PATCH] staging/lustre/lov: remove set_fs() call from lov_getstripe()
From: Greg KH @ 2017-05-28 5:29 UTC (permalink / raw)
To: Oleg Drokin; +Cc: linux-stable
In-Reply-To: <1E4800EB-B661-490B-B39F-6F1C65C47586@linuxhacker.ru>
On Sat, May 27, 2017 at 06:38:06PM -0400, Oleg Drokin wrote:
>
> On May 27, 2017, at 4:26 PM, Greg KH wrote:
>
> > On Sat, May 27, 2017 at 03:22:18PM -0400, Oleg Drokin wrote:
> >> lov_getstripe() calls set_fs(KERNEL_DS) so that it can handle a struct
> >> lov_user_md pointer from user- or kernel-space. This changes the
> >> behavior of copy_from_user() on SPARC and may result in a misaligned
> >> access exception which in turn oopses the kernel. In fact the
> >> relevant argument to lov_getstripe() is never called with a
> >> kernel-space pointer and so changing the address limits is unnecessary
> >> and so we remove the calls to save, set, and restore the address
> >> limits.
> >>
> >> Signed-off-by: John L. Hammond <john.hammond@intel.com>
> >> Reviewed-on: http://review.whamcloud.com/6150
> >> Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-3221
> >> Reviewed-by: Andreas Dilger <andreas.dilger@intel.com>
> >> Reviewed-by: Li Wei <wei.g.li@intel.com>
> >> CC: linux-stable <stable@vger.kernel.org> # >= v3.11
> >> Signed-off-by: Oleg Drokin <green@linuxhacker.ru>
> >> ---
> >> drivers/staging/lustre/lustre/lov/lov_pack.c | 9 ---------
> >> 1 file changed, 9 deletions(-)
> >
> > What was the git commit id of this patch in Linus's tree?
>
> It's not in Linus tree yet.
> I was just informed that this patch should go to stable by Al, so I added stable
> to the list.
<formletter>
This is not the correct way to submit patches for inclusion in the
stable kernel tree. Please read:
https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html
for how to do this properly.
</formletter>
^ permalink raw reply
* Re: [PATCH RESEND] drm: mxsfb_crtc: Reset the eLCDIF controller
From: Fabio Estevam @ 2017-05-28 13:12 UTC (permalink / raw)
To: Daniel Vetter, jani.nikula, Sean Paul
Cc: Marek Vasut, DRI mailing list, Fabio Estevam, #4 . 11 . x
In-Reply-To: <1495486427-8213-1-git-send-email-festevam@gmail.com>
On Mon, May 22, 2017 at 5:53 PM, Fabio Estevam <festevam@gmail.com> wrote:
> From: Fabio Estevam <fabio.estevam@nxp.com>
>
> According to the eLCDIF initialization steps listed in the MX6SX
> Reference Manual the eLCDIF block reset is mandatory.
>
> Without performing the eLCDIF reset the display shows garbage content
> when the kernel boots.
>
> In earlier tests this issue has not been observed because the bootloader
> was previously showing a splash screen and the bootloader display driver
> does properly implement the eLCDIF reset.
>
> Add the eLCDIF reset to the driver, so that it can operate correctly
> independently of the bootloader.
>
> Tested on a imx6sx-sdb board.
>
> Cc: <stable@vger.kernel.org> #4.11.x
> Signed-off-by: Fabio Estevam <fabio.estevam@nxp.com>
> Reviewed-by: Marek Vasut <marex@denx.de>
> ---
> Daniel,
>
> Marek suggested that this goes via drm-misc.
Sean/Jani/Daniel,
Any chance this could go via drm-misc?
Without this change the mxsfb driver is unusable on some platforms.
Thanks
>
> Thanks
>
> drivers/gpu/drm/mxsfb/mxsfb_crtc.c | 42 ++++++++++++++++++++++++++++++++++++++
> 1 file changed, 42 insertions(+)
>
> diff --git a/drivers/gpu/drm/mxsfb/mxsfb_crtc.c b/drivers/gpu/drm/mxsfb/mxsfb_crtc.c
> index 1144e0c..0abe776 100644
> --- a/drivers/gpu/drm/mxsfb/mxsfb_crtc.c
> +++ b/drivers/gpu/drm/mxsfb/mxsfb_crtc.c
> @@ -35,6 +35,13 @@
> #include "mxsfb_drv.h"
> #include "mxsfb_regs.h"
>
> +#define MXS_SET_ADDR 0x4
> +#define MXS_CLR_ADDR 0x8
> +#define MODULE_CLKGATE BIT(30)
> +#define MODULE_SFTRST BIT(31)
> +/* 1 second delay should be plenty of time for block reset */
> +#define RESET_TIMEOUT 1000000
> +
> static u32 set_hsync_pulse_width(struct mxsfb_drm_private *mxsfb, u32 val)
> {
> return (val & mxsfb->devdata->hs_wdth_mask) <<
> @@ -159,6 +166,36 @@ static void mxsfb_disable_controller(struct mxsfb_drm_private *mxsfb)
> clk_disable_unprepare(mxsfb->clk_disp_axi);
> }
>
> +/*
> + * Clear the bit and poll it cleared. This is usually called with
> + * a reset address and mask being either SFTRST(bit 31) or CLKGATE
> + * (bit 30).
> + */
> +static int clear_poll_bit(void __iomem *addr, u32 mask)
> +{
> + u32 reg;
> +
> + writel(mask, addr + MXS_CLR_ADDR);
> + return readl_poll_timeout(addr, reg, !(reg & mask), 0, RESET_TIMEOUT);
> +}
> +
> +static int mxsfb_reset_block(void __iomem *reset_addr)
> +{
> + int ret;
> +
> + ret = clear_poll_bit(reset_addr, MODULE_SFTRST);
> + if (ret)
> + return ret;
> +
> + writel(MODULE_CLKGATE, reset_addr + MXS_CLR_ADDR);
> +
> + ret = clear_poll_bit(reset_addr, MODULE_SFTRST);
> + if (ret)
> + return ret;
> +
> + return clear_poll_bit(reset_addr, MODULE_CLKGATE);
> +}
> +
> static void mxsfb_crtc_mode_set_nofb(struct mxsfb_drm_private *mxsfb)
> {
> struct drm_display_mode *m = &mxsfb->pipe.crtc.state->adjusted_mode;
> @@ -173,6 +210,11 @@ static void mxsfb_crtc_mode_set_nofb(struct mxsfb_drm_private *mxsfb)
> */
> mxsfb_enable_axi_clk(mxsfb);
>
> + /* Mandatory eLCDIF reset as per the Reference Manual */
> + err = mxsfb_reset_block(mxsfb->base);
> + if (err)
> + return;
> +
> /* Clear the FIFOs */
> writel(CTRL1_FIFO_CLEAR, mxsfb->base + LCDC_CTRL1 + REG_SET);
>
> --
> 2.7.4
>
^ permalink raw reply
* request for inclusion of 2 xfs patches
From: Nikolay Borisov @ 2017-05-29 9:27 UTC (permalink / raw)
To: stable; +Cc: sandeen, linux-xfs, Brian Foster
[-- Attachment #1: Type: text/plain, Size: 472 bytes --]
Hello,
I'd like to request the following two patches to be
included in 4.4 stable:
0facef7fb053 ("xfs: in _attrlist_by_handle, copy the cursor back to userspace")
2a6fba6d2311 ("xfs: only return -errno or success from attr ->put_listent")
The fix a failure in xfstest/269 and also enable the xfs' XFS_IOC_ATTRLIST_BY_HANDLE
ioctl to function properly. The first commit applies cleanly, whereas the second has
a minor conflict due t spacing. Backport is attached.
[-- Attachment #2: 0002-xfs-only-return-errno-or-success-from-attr-put_liste.patch --]
[-- Type: text/x-patch, Size: 3845 bytes --]
>From 42432ed1a893868c62df93005afab8a92de95986 Mon Sep 17 00:00:00 2001
From: Eric Sandeen <sandeen@sandeen.net>
Date: Wed, 6 Apr 2016 07:57:18 +1000
Subject: [PATCH 2/2] xfs: only return -errno or success from attr
->put_listent
Today, the put_listent formatters return either 1 or 0; if
they return 1, some callers treat this as an error and return
it up the stack, despite "1" not being a valid (negative)
error code.
The intent seems to be that if the input buffer is full,
we set seen_enough or set count = -1, and return 1;
but some callers check the return before checking the
seen_enough or count fields of the context.
Fix this by only returning non-zero for actual errors
encountered, and rely on the caller to first check the
return value, then check the values in the context to
decide what to do.
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Dave Chinner <david@fromorbit.com>
Acked-by: Nikolay Borisov <nborisov@suse.com>
Signed-off-by: Nikolay Borisov <nborisov@suse.com>
---
fs/xfs/xfs_attr.h | 1 +
fs/xfs/xfs_attr_list.c | 8 +++-----
fs/xfs/xfs_xattr.c | 15 ++++++++++-----
3 files changed, 14 insertions(+), 10 deletions(-)
diff --git a/fs/xfs/xfs_attr.h b/fs/xfs/xfs_attr.h
index dd4824589470..234331227c0c 100644
--- a/fs/xfs/xfs_attr.h
+++ b/fs/xfs/xfs_attr.h
@@ -112,6 +112,7 @@ typedef struct attrlist_cursor_kern {
*========================================================================*/
+/* Return 0 on success, or -errno; other state communicated via *context */
typedef int (*put_listent_func_t)(struct xfs_attr_list_context *, int,
unsigned char *, int, int, unsigned char *);
diff --git a/fs/xfs/xfs_attr_list.c b/fs/xfs/xfs_attr_list.c
index 4fa14820e2e2..c8be331a3196 100644
--- a/fs/xfs/xfs_attr_list.c
+++ b/fs/xfs/xfs_attr_list.c
@@ -108,16 +108,14 @@ xfs_attr_shortform_list(xfs_attr_list_context_t *context)
(int)sfe->namelen,
(int)sfe->valuelen,
&sfe->nameval[sfe->namelen]);
-
+ if (error)
+ return error;
/*
* Either search callback finished early or
* didn't fit it all in the buffer after all.
*/
if (context->seen_enough)
break;
-
- if (error)
- return error;
sfe = XFS_ATTR_SF_NEXTENTRY(sfe);
}
trace_xfs_attr_list_sf_all(context);
@@ -581,7 +579,7 @@ xfs_attr_put_listent(
trace_xfs_attr_list_full(context);
alist->al_more = 1;
context->seen_enough = 1;
- return 1;
+ return 0;
}
aep = (attrlist_ent_t *)&context->alist[context->firstu];
diff --git a/fs/xfs/xfs_xattr.c b/fs/xfs/xfs_xattr.c
index 839b35ca21c6..e6dae28dfa1a 100644
--- a/fs/xfs/xfs_xattr.c
+++ b/fs/xfs/xfs_xattr.c
@@ -180,7 +180,7 @@ xfs_xattr_put_listent(
arraytop = context->count + prefix_len + namelen + 1;
if (arraytop > context->firstu) {
context->count = -1; /* insufficient space */
- return 1;
+ return 0;
}
offset = (char *)context->alist + context->count;
strncpy(offset, xfs_xattr_prefix(flags), prefix_len);
@@ -222,12 +222,15 @@ list_one_attr(const char *name, const size_t len, void *data,
}
ssize_t
-xfs_vn_listxattr(struct dentry *dentry, char *data, size_t size)
+xfs_vn_listxattr(
+ struct dentry *dentry,
+ char *data,
+ size_t size)
{
struct xfs_attr_list_context context;
struct attrlist_cursor_kern cursor = { 0 };
- struct inode *inode = d_inode(dentry);
- int error;
+ struct inode *inode = d_inode(dentry);
+ int error;
/*
* First read the regular on-disk attributes.
@@ -245,7 +248,9 @@ xfs_vn_listxattr(struct dentry *dentry, char *data, size_t size)
else
context.put_listent = xfs_xattr_put_listent_sizes;
- xfs_attr_list_int(&context);
+ error = xfs_attr_list_int(&context);
+ if (error)
+ return error;
if (context.count < 0)
return -ERANGE;
--
2.7.4
^ permalink raw reply related
* Re: request for inclusion of 2 xfs patches
From: Nikolay Borisov @ 2017-05-29 9:28 UTC (permalink / raw)
To: stable; +Cc: sandeen, linux-xfs, Brian Foster
In-Reply-To: <89781cfb-b826-8d01-d054-f70b0e2d8439@suse.com>
On 29.05.2017 12:27, Nikolay Borisov wrote:
> Hello,
>
> I'd like to request the following two patches to be
> included in 4.4 stable:
>
> 0facef7fb053 ("xfs: in _attrlist_by_handle, copy the cursor back to userspace")
>
> 2a6fba6d2311 ("xfs: only return -errno or success from attr ->put_listent")
>
> The fix a failure in xfstest/269 and also enable the xfs' XFS_IOC_ATTRLIST_BY_HANDLE
> ioctl to function properly. The first commit applies cleanly, whereas the second has
> a minor conflict due t spacing. Backport is attached.
>
Please omit my Acked-by tagged when applying the backport
^ permalink raw reply
* Re: [PATCH] powerpc: sysdev: simple_gpio: fix Oops in gpio save_regs function
From: Linus Walleij @ 2017-05-29 9:37 UTC (permalink / raw)
To: Christophe Leroy
Cc: Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman,
Scott Wood, linux-kernel@vger.kernel.org,
linuxppc-dev@lists.ozlabs.org list, linux-gpio@vger.kernel.org,
stable
In-Reply-To: <20170524080156.1C4936EB78@pc13941vm.idsi0.si.c-s.fr>
On Wed, May 24, 2017 at 10:01 AM, Christophe Leroy
<christophe.leroy@c-s.fr> wrote:
> of_mm_gpiochip_add_data() generates an Oops for NULL pointer dereference.
>
> of_mm_gpiochip_add_data() calls mm_gc->save_regs() before
> setting the data, therefore ->save_regs() cannot use gpiochip_get_data()
>
> Fixes: 937daafca774b ("powerpc: simple-gpio: use gpiochip data pointer")
> Cc: stable@vger.kernel.org
>
> Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Sorry for any screwups I've caused...
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH] dax: improve fix for colliding PMD & PTE entries
From: Jan Kara @ 2017-05-29 12:17 UTC (permalink / raw)
To: Ross Zwisler
Cc: Andrew Morton, linux-kernel, Darrick J. Wong, Alexander Viro,
Christoph Hellwig, Dan Williams, Dave Hansen, Jan Kara,
Matthew Wilcox, linux-fsdevel, linux-mm, linux-nvdimm,
Kirill A . Shutemov, Pawel Lebioda, Dave Jiang, Xiong Zhou,
Eryu Guan, stable
In-Reply-To: <20170526195932.32178-1-ross.zwisler@linux.intel.com>
On Fri 26-05-17 13:59:32, Ross Zwisler wrote:
> This commit, which has not yet made it upstream but is in the -mm tree:
>
> dax: Fix race between colliding PMD & PTE entries
>
> fixed a pair of race conditions where racing DAX PTE and PMD faults could
> corrupt page tables. This fix had two shortcomings which are addressed by
> this patch:
>
> 1) In the PTE fault handler we only checked for a collision using
> pmd_devmap(). The pmd_devmap() check will trigger when we have raced with
> a PMD that has real DAX storage, but to account for the case where we
> collide with a huge zero page entry we also need to check for
> pmd_trans_huge().
>
> 2) In the PMD fault handler we only continued with the fault if no PMD at
> all was present (pmd_none()). This is the case when we are faulting in a
> PMD for the first time, but there are two other cases to consider. The
> first is that we are servicing a write fault over a PMD huge zero page,
> which we detect with pmd_trans_huge(). The second is that we are servicing
> a write fault over a DAX PMD with real storage, which we address with
> pmd_devmap().
>
> Fix both of these, and instead of manually triggering a fallback in the PMD
> collision case instead be consistent with the other collision detection
> code in the fault handlers and just retry.
>
> Signed-off-by: Ross Zwisler <ross.zwisler@linux.intel.com>
> Cc: stable@vger.kernel.org
Ugh, right. I forgot zero page in page tables will not pass the devmap
check... You can add:
Reviewed-by: Jan Kara <jack@suse.cz>
Honza
> ---
>
> For both the -mm tree and for stable, feel free to squash this with the
> original commit if you think that is appropriate.
>
> This has passed targeted testing and an xfstests run.
> ---
> fs/dax.c | 11 +++++++----
> 1 file changed, 7 insertions(+), 4 deletions(-)
>
> diff --git a/fs/dax.c b/fs/dax.c
> index fc62f36..2a6889b 100644
> --- a/fs/dax.c
> +++ b/fs/dax.c
> @@ -1160,7 +1160,7 @@ static int dax_iomap_pte_fault(struct vm_fault *vmf,
> * the PTE we need to set up. If so just return and the fault will be
> * retried.
> */
> - if (pmd_devmap(*vmf->pmd)) {
> + if (pmd_trans_huge(*vmf->pmd) || pmd_devmap(*vmf->pmd)) {
> vmf_ret = VM_FAULT_NOPAGE;
> goto unlock_entry;
> }
> @@ -1411,11 +1411,14 @@ static int dax_iomap_pmd_fault(struct vm_fault *vmf,
> /*
> * It is possible, particularly with mixed reads & writes to private
> * mappings, that we have raced with a PTE fault that overlaps with
> - * the PMD we need to set up. If so we just fall back to a PTE fault
> - * ourselves.
> + * the PMD we need to set up. If so just return and the fault will be
> + * retried.
> */
> - if (!pmd_none(*vmf->pmd))
> + if (!pmd_none(*vmf->pmd) && !pmd_trans_huge(*vmf->pmd) &&
> + !pmd_devmap(*vmf->pmd)) {
> + result = 0;
> goto unlock_entry;
> + }
>
> /*
> * Note that we don't use iomap_apply here. We aren't doing I/O, only
> --
> 2.9.4
>
--
Jan Kara <jack@suse.com>
SUSE Labs, CR
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* v4.1.40 build: 0 failures 43 warnings (v4.1.40)
From: Build bot for Mark Brown @ 2017-05-29 12:41 UTC (permalink / raw)
To: kernel-build-reports, linaro-kernel, stable
Tree/Branch: v4.1.40
Git describe: v4.1.40
Commit: 56d847e3ef Linux 4.1.40
Build Time: 66 min 41 sec
Passed: 9 / 9 (100.00 %)
Failed: 0 / 9 ( 0.00 %)
Errors: 0
Warnings: 43
Section Mismatches: 1
-------------------------------------------------------------------------------
defconfigs with issues (other than build errors):
35 warnings 3 mismatches : arm64-allmodconfig
3 warnings 0 mismatches : arm-multi_v5_defconfig
3 warnings 0 mismatches : arm-multi_v7_defconfig
2 warnings 0 mismatches : x86_64-defconfig
24 warnings 0 mismatches : arm-allmodconfig
1 warnings 0 mismatches : arm64-defconfig
-------------------------------------------------------------------------------
Warnings Summary: 43
8 ../include/linux/kernel.h:723:17: warning: comparison of distinct pointer types lacks a cast
6 ../net/ipv6/ip6_offload.c:261:25: warning: 'sit_gro_receive' defined but not used [-Wunused-function]
4 ../include/linux/blkdev.h:624:26: warning: switch condition has boolean value [-Wswitch-bool]
2 ../sound/pci/oxygen/oxygen_mixer.c:91:43: warning: logical not is only applied to the left hand side of comparison [-Wlogical-not-parentheses]
2 ../drivers/scsi/qla2xxx/qla_target.c:3086:6: warning: format '%llu' expects argument of type 'long long unsigned int', but argument 8 has type 'uint32_t {aka unsigned int}' [-Wformat=]
2 ../drivers/scsi/qla2xxx/qla_target.c:3083:17: warning: unused variable 'se_cmd' [-Wunused-variable]
2 ../drivers/scsi/ips.c:210:2: warning: #warning "This driver has only been tested on the x86/ia64/x86_64 platforms" [-Wcpp]
2 ../drivers/scsi/be2iscsi/be_main.c:3168:18: warning: logical not is only applied to the left hand side of comparison [-Wlogical-not-parentheses]
2 ../drivers/media/platform/s3c-camif/camif-capture.c:134:10: warning: logical not is only applied to the left hand side of comparison [-Wlogical-not-parentheses]
2 ../drivers/media/platform/s3c-camif/camif-capture.c:118:10: warning: logical not is only applied to the left hand side of comparison [-Wlogical-not-parentheses]
2 ../drivers/ata/pata_hpt366.c:382:9: warning: assignment discards 'const' qualifier from pointer target type [-Wdiscarded-array-qualifiers]
2 ../drivers/ata/pata_hpt366.c:379:9: warning: assignment discards 'const' qualifier from pointer target type [-Wdiscarded-array-qualifiers]
2 ../drivers/ata/pata_hpt366.c:376:9: warning: assignment discards 'const' qualifier from pointer target type [-Wdiscarded-array-qualifiers]
1 ../net/caif/cfpkt_skbuff.c:286:3: warning: this 'else' clause does not guard... [-Wmisleading-indentation]
1 ../include/trace/ftrace.h:28:0: warning: "TRACE_SYSTEM_STRING" redefined
1 ../drivers/usb/renesas_usbhs/common.c:492:25: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
1 ../drivers/staging/rtl8723au/core/rtw_wlan_util.c:525:2: warning: this 'else' clause does not guard... [-Wmisleading-indentation]
1 ../drivers/staging/iio/adc/ad7192.c:238:3: warning: this 'else' clause does not guard... [-Wmisleading-indentation]
1 ../drivers/scsi/megaraid/megaraid_sas_fusion.c:1723:3: warning: this 'if' clause does not guard... [-Wmisleading-indentation]
1 ../drivers/scsi/bfa/bfa_ioc.c:3673:4: warning: this 'if' clause does not guard... [-Wmisleading-indentation]
1 ../drivers/scsi/bfa/bfa_ioc.c:3665:3: warning: this 'if' clause does not guard... [-Wmisleading-indentation]
1 ../drivers/rtc/rtc-pcf8563.c:444:5: warning: 'alm_pending' may be used uninitialized in this function [-Wmaybe-uninitialized]
1 ../drivers/rtc/rtc-armada38x.c:91:22: warning: unused variable 'flags' [-Wunused-variable]
1 ../drivers/net/wireless/iwlegacy/3945.c:1022:5: warning: suggest explicit braces to avoid ambiguous 'else' [-Wparentheses]
1 ../drivers/net/wireless/brcm80211/brcmfmac/fwsignal.c:1478:8: warning: 'skb' may be used uninitialized in this function [-Wmaybe-uninitialized]
1 ../drivers/net/ethernet/dec/tulip/winbond-840.c:910:2: warning: #warning Processor architecture undefined [-Wcpp]
1 ../drivers/net/ethernet/dec/tulip/uli526x.c:1086:4: warning: this 'else' clause does not guard... [-Wmisleading-indentation]
1 ../drivers/net/ethernet/dec/tulip/tulip_core.c:101:2: warning: #warning Processor architecture undefined! [-Wcpp]
1 ../drivers/mtd/mtd_blkdevs.c:100:2: warning: switch condition has boolean value [-Wswitch-bool]
1 ../drivers/mmc/host/sh_mmcif.c:402:4: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
1 ../drivers/mmc/host/sh_mmcif.c:401:4: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
1 ../drivers/media/platform/coda/./trace.h:12:0: warning: "TRACE_SYSTEM_STRING" redefined
1 ../drivers/media/platform/am437x/am437x-vpfe.c:1723:27: warning: self-comparison always evaluates to true [-Wtautological-compare]
1 ../drivers/infiniband/hw/qib/qib_qp.c:44:0: warning: "BITS_PER_PAGE" redefined
1 ../drivers/infiniband/hw/cxgb4/mem.c:147:20: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
1 ../drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgm204.c:975:1: warning: the frame size of 1192 bytes is larger than 1024 bytes [-Wframe-larger-than=]
1 ../drivers/gpio/gpio-74xx-mmio.c:132:16: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
1 ../drivers/block/drbd/drbd_bitmap.c:483:0: warning: "BITS_PER_PAGE_MASK" redefined
1 ../drivers/block/drbd/drbd_bitmap.c:482:0: warning: "BITS_PER_PAGE" redefined
1 ../drivers/atm/iphase.c:1176:12: warning: this 'if' clause does not guard... [-Wmisleading-indentation]
1 ../arch/x86/kernel/cpu/mcheck/therm_throt.c:389:3: warning: right shift count >= width of type
1 ../arch/arm/mach-cns3xxx/pcie.c:266:1: warning: the frame size of 1088 bytes is larger than 1024 bytes [-Wframe-larger-than=]
1 ../arch/arm/include/asm/cmpxchg.h:205:3: warning: value computed is not used [-Wunused-value]
Section Mismatch Summary: 1
3 WARNING: drivers/staging/fsl-mc/bus/mc-bus-driver.o(.init.text+0x164): Section mismatch in reference from the function init_module() to the function .exit.text:dprc_driver_exit()
===============================================================================
Detailed per-defconfig build reports below:
-------------------------------------------------------------------------------
arm64-allmodconfig : PASS, 0 errors, 35 warnings, 3 section mismatches
Warnings:
../drivers/ata/pata_hpt366.c:376:9: warning: assignment discards 'const' qualifier from pointer target type [-Wdiscarded-array-qualifiers]
../drivers/ata/pata_hpt366.c:379:9: warning: assignment discards 'const' qualifier from pointer target type [-Wdiscarded-array-qualifiers]
../drivers/ata/pata_hpt366.c:382:9: warning: assignment discards 'const' qualifier from pointer target type [-Wdiscarded-array-qualifiers]
../drivers/atm/iphase.c:1176:12: warning: this 'if' clause does not guard... [-Wmisleading-indentation]
../net/caif/cfpkt_skbuff.c:286:3: warning: this 'else' clause does not guard... [-Wmisleading-indentation]
../sound/pci/oxygen/oxygen_mixer.c:91:43: warning: logical not is only applied to the left hand side of comparison [-Wlogical-not-parentheses]
../drivers/block/drbd/drbd_bitmap.c:482:0: warning: "BITS_PER_PAGE" redefined
../drivers/block/drbd/drbd_bitmap.c:483:0: warning: "BITS_PER_PAGE_MASK" redefined
../drivers/gpio/gpio-74xx-mmio.c:132:16: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
../net/ipv6/ip6_offload.c:261:25: warning: 'sit_gro_receive' defined but not used [-Wunused-function]
../drivers/infiniband/hw/qib/qib_qp.c:44:0: warning: "BITS_PER_PAGE" redefined
../drivers/mmc/host/sh_mmcif.c:401:4: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
../drivers/mmc/host/sh_mmcif.c:402:4: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
../drivers/mtd/mtd_blkdevs.c:100:2: warning: switch condition has boolean value [-Wswitch-bool]
../drivers/scsi/be2iscsi/be_main.c:3168:18: warning: logical not is only applied to the left hand side of comparison [-Wlogical-not-parentheses]
../drivers/scsi/bfa/bfa_ioc.c:3665:3: warning: this 'if' clause does not guard... [-Wmisleading-indentation]
../drivers/scsi/bfa/bfa_ioc.c:3673:4: warning: this 'if' clause does not guard... [-Wmisleading-indentation]
../drivers/media/platform/am437x/am437x-vpfe.c:1723:27: warning: self-comparison always evaluates to true [-Wtautological-compare]
../drivers/net/ethernet/dec/tulip/winbond-840.c:910:2: warning: #warning Processor architecture undefined [-Wcpp]
../drivers/net/ethernet/dec/tulip/tulip_core.c:101:2: warning: #warning Processor architecture undefined! [-Wcpp]
../drivers/net/ethernet/dec/tulip/uli526x.c:1086:4: warning: this 'else' clause does not guard... [-Wmisleading-indentation]
../drivers/media/platform/s3c-camif/camif-capture.c:118:10: warning: logical not is only applied to the left hand side of comparison [-Wlogical-not-parentheses]
../drivers/media/platform/s3c-camif/camif-capture.c:134:10: warning: logical not is only applied to the left hand side of comparison [-Wlogical-not-parentheses]
../drivers/scsi/megaraid/megaraid_sas_fusion.c:1723:3: warning: this 'if' clause does not guard... [-Wmisleading-indentation]
../drivers/scsi/qla2xxx/qla_target.c:3086:6: warning: format '%llu' expects argument of type 'long long unsigned int', but argument 8 has type 'uint32_t {aka unsigned int}' [-Wformat=]
../drivers/scsi/qla2xxx/qla_target.c:3083:17: warning: unused variable 'se_cmd' [-Wunused-variable]
../drivers/staging/iio/adc/ad7192.c:238:3: warning: this 'else' clause does not guard... [-Wmisleading-indentation]
../drivers/scsi/ips.c:210:2: warning: #warning "This driver has only been tested on the x86/ia64/x86_64 platforms" [-Wcpp]
../include/linux/kernel.h:723:17: warning: comparison of distinct pointer types lacks a cast
../include/linux/kernel.h:723:17: warning: comparison of distinct pointer types lacks a cast
../include/linux/kernel.h:723:17: warning: comparison of distinct pointer types lacks a cast
../include/linux/kernel.h:723:17: warning: comparison of distinct pointer types lacks a cast
../drivers/usb/renesas_usbhs/common.c:492:25: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
../drivers/staging/rtl8723au/core/rtw_wlan_util.c:525:2: warning: this 'else' clause does not guard... [-Wmisleading-indentation]
../drivers/net/wireless/iwlegacy/3945.c:1022:5: warning: suggest explicit braces to avoid ambiguous 'else' [-Wparentheses]
Section Mismatches:
WARNING: drivers/staging/fsl-mc/bus/mc-bus-driver.o(.init.text+0x164): Section mismatch in reference from the function init_module() to the function .exit.text:dprc_driver_exit()
WARNING: drivers/staging/fsl-mc/bus/mc-bus-driver.o(.init.text+0x164): Section mismatch in reference from the function init_module() to the function .exit.text:dprc_driver_exit()
WARNING: drivers/staging/fsl-mc/bus/mc-bus-driver.o(.init.text+0x164): Section mismatch in reference from the function init_module() to the function .exit.text:dprc_driver_exit()
-------------------------------------------------------------------------------
arm-multi_v5_defconfig : PASS, 0 errors, 3 warnings, 0 section mismatches
Warnings:
../include/linux/blkdev.h:624:26: warning: switch condition has boolean value [-Wswitch-bool]
../net/ipv6/ip6_offload.c:261:25: warning: 'sit_gro_receive' defined but not used [-Wunused-function]
../drivers/rtc/rtc-pcf8563.c:444:5: warning: 'alm_pending' may be used uninitialized in this function [-Wmaybe-uninitialized]
-------------------------------------------------------------------------------
arm-multi_v7_defconfig : PASS, 0 errors, 3 warnings, 0 section mismatches
Warnings:
../net/ipv6/ip6_offload.c:261:25: warning: 'sit_gro_receive' defined but not used [-Wunused-function]
../include/linux/blkdev.h:624:26: warning: switch condition has boolean value [-Wswitch-bool]
../drivers/net/wireless/brcm80211/brcmfmac/fwsignal.c:1478:8: warning: 'skb' may be used uninitialized in this function [-Wmaybe-uninitialized]
-------------------------------------------------------------------------------
x86_64-defconfig : PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
../arch/x86/kernel/cpu/mcheck/therm_throt.c:389:3: warning: right shift count >= width of type
../net/ipv6/ip6_offload.c:261:25: warning: 'sit_gro_receive' defined but not used [-Wunused-function]
-------------------------------------------------------------------------------
arm-allmodconfig : PASS, 0 errors, 24 warnings, 0 section mismatches
Warnings:
../arch/arm/mach-cns3xxx/pcie.c:266:1: warning: the frame size of 1088 bytes is larger than 1024 bytes [-Wframe-larger-than=]
../drivers/ata/pata_hpt366.c:376:9: warning: assignment discards 'const' qualifier from pointer target type [-Wdiscarded-array-qualifiers]
../drivers/ata/pata_hpt366.c:379:9: warning: assignment discards 'const' qualifier from pointer target type [-Wdiscarded-array-qualifiers]
../drivers/ata/pata_hpt366.c:382:9: warning: assignment discards 'const' qualifier from pointer target type [-Wdiscarded-array-qualifiers]
../arch/arm/include/asm/cmpxchg.h:205:3: warning: value computed is not used [-Wunused-value]
../include/linux/blkdev.h:624:26: warning: switch condition has boolean value [-Wswitch-bool]
../sound/pci/oxygen/oxygen_mixer.c:91:43: warning: logical not is only applied to the left hand side of comparison [-Wlogical-not-parentheses]
../net/ipv6/ip6_offload.c:261:25: warning: 'sit_gro_receive' defined but not used [-Wunused-function]
../drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgm204.c:975:1: warning: the frame size of 1192 bytes is larger than 1024 bytes [-Wframe-larger-than=]
../drivers/infiniband/hw/cxgb4/mem.c:147:20: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
../include/linux/blkdev.h:624:26: warning: switch condition has boolean value [-Wswitch-bool]
../include/trace/ftrace.h:28:0: warning: "TRACE_SYSTEM_STRING" redefined
../drivers/media/platform/coda/./trace.h:12:0: warning: "TRACE_SYSTEM_STRING" redefined
../drivers/media/platform/s3c-camif/camif-capture.c:118:10: warning: logical not is only applied to the left hand side of comparison [-Wlogical-not-parentheses]
../drivers/media/platform/s3c-camif/camif-capture.c:134:10: warning: logical not is only applied to the left hand side of comparison [-Wlogical-not-parentheses]
../drivers/rtc/rtc-armada38x.c:91:22: warning: unused variable 'flags' [-Wunused-variable]
../drivers/scsi/be2iscsi/be_main.c:3168:18: warning: logical not is only applied to the left hand side of comparison [-Wlogical-not-parentheses]
../drivers/scsi/qla2xxx/qla_target.c:3086:6: warning: format '%llu' expects argument of type 'long long unsigned int', but argument 8 has type 'uint32_t {aka unsigned int}' [-Wformat=]
../drivers/scsi/qla2xxx/qla_target.c:3083:17: warning: unused variable 'se_cmd' [-Wunused-variable]
../drivers/scsi/ips.c:210:2: warning: #warning "This driver has only been tested on the x86/ia64/x86_64 platforms" [-Wcpp]
../include/linux/kernel.h:723:17: warning: comparison of distinct pointer types lacks a cast
../include/linux/kernel.h:723:17: warning: comparison of distinct pointer types lacks a cast
../include/linux/kernel.h:723:17: warning: comparison of distinct pointer types lacks a cast
../include/linux/kernel.h:723:17: warning: comparison of distinct pointer types lacks a cast
-------------------------------------------------------------------------------
arm64-defconfig : PASS, 0 errors, 1 warnings, 0 section mismatches
Warnings:
../net/ipv6/ip6_offload.c:261:25: warning: 'sit_gro_receive' defined but not used [-Wunused-function]
-------------------------------------------------------------------------------
Passed with no errors, warnings or mismatches:
x86_64-allnoconfig
arm64-allnoconfig
arm-allnoconfig
^ permalink raw reply
* Re: [PATCH 0/2] nohz: Deal with clock reprogram skipping issues v3
From: Frederic Weisbecker @ 2017-05-29 13:55 UTC (permalink / raw)
To: Ingo Molnar
Cc: LKML, Peter Zijlstra, Rik van Riel, James Hartsock,
Thomas Gleixner, stable, Tim Wright, Pavel Machek
In-Reply-To: <20170526061320.uhl34walndqv6wo6@gmail.com>
On Fri, May 26, 2017 at 08:13:20AM +0200, Ingo Molnar wrote:
>
> * Frederic Weisbecker <fweisbec@gmail.com> wrote:
>
> > On Wed, May 24, 2017 at 09:16:28AM +0200, Ingo Molnar wrote:
> > > So the interdiff between your two patches and the 3 commits already queued up is:
> > >
> > > diff --git a/kernel/time/tick-sched.c b/kernel/time/tick-sched.c
> > > index e3043873fcdc..30253ed0380b 100644
> > > --- a/kernel/time/tick-sched.c
> > > +++ b/kernel/time/tick-sched.c
> > > @@ -150,12 +150,6 @@ static void tick_sched_handle(struct tick_sched *ts, struct pt_regs *regs)
> > > touch_softlockup_watchdog_sched();
> > > if (is_idle_task(current))
> > > ts->idle_jiffies++;
> > > - /*
> > > - * In case the current tick fired too early past its expected
> > > - * expiration, make sure we don't bypass the next clock reprogramming
> > > - * to the same deadline.
> > > - */
> > > - ts->next_tick = 0;
> > > }
> > > #endif
> > > update_process_times(user_mode(regs));
> > > @@ -1103,8 +1097,15 @@ static void tick_nohz_handler(struct clock_event_device *dev)
> > > tick_sched_handle(ts, regs);
> > >
> > > /* No need to reprogram if we are running tickless */
> > > - if (unlikely(ts->tick_stopped))
> > > + if (unlikely(ts->tick_stopped)) {
> > > + /*
> > > + * In case the current tick fired too early past its expected
> > > + * expiration, make sure we don't bypass the next clock reprogramming
> > > + * to the same deadline.
> > > + */
> > > + ts->next_tick = 0;
> > > return;
> > > + }
> > >
> > > hrtimer_forward(&ts->sched_timer, now, tick_period);
> > > tick_program_event(hrtimer_get_expires(&ts->sched_timer), 1);
> > > @@ -1202,12 +1203,17 @@ static enum hrtimer_restart tick_sched_timer(struct hrtimer *timer)
> > > */
> > > if (regs)
> > > tick_sched_handle(ts, regs);
> > > - else
> > > - ts->next_tick = 0;
> > >
> > > /* No need to reprogram if we are in idle or full dynticks mode */
> > > - if (unlikely(ts->tick_stopped))
> > > + if (unlikely(ts->tick_stopped)) {
> > > + /*
> > > + * In case the current tick fired too early past its expected
> > > + * expiration, make sure we don't bypass the next clock reprogramming
> > > + * to the same deadline.
> > > + */
> > > + ts->next_tick = 0;
> > > return HRTIMER_NORESTART;
> > > + }
> > >
> > > hrtimer_forward(timer, now, tick_period);
> > >
> > >
> > > ... so the two are not the same - I'd rather not rebase it, I'd like to keep what
> > > is working, we had problems with these changes before ...
> > >
> > > If you'd like the changes in this interdiff to be applied as well, please add a
> > > changelog to it and post it as a fourth patch.
> > >
> > > Thanks,
> > >
> > > Ingo
> >
> > So if you like, you can replace the top patch with the following. It's exactly
> > the same code, I've only added a comment and a changelog:
> >
> > ---
> > From 72956bf08c3b2e506a5ce5ec4faac9fd6b097307 Mon Sep 17 00:00:00 2001
> > From: Frederic Weisbecker <fweisbec@gmail.com>
> > Date: Mon, 15 May 2017 14:56:50 +0200
> > Subject: [PATCH] nohz: Reset next_tick cache even when the timer has no regs
> >
> > The tick IRQ regs can be NULL if hrtimer_interrupt() is called from
> > non-interrupt contexts (ex: hotplug CPU down). For such very special
> > path we forget to clean the cached next tick deadline. If we are in
> > dynticks mode and the actual timer deadline is ahead of us, we might
> > perform a buggy bypass of the next clock reprogramming.
> >
> > In fact since CPU down is the only user I'm aware of, this fix is likely
> > unnecessary as dying CPUs already clean their tick deadline cache. But
> > given how hard it is to debug such timer cache related issue, we should
> > never be short on paranoid measures.
> >
> > Signed-off-by: Frederic Weisbecker <fweisbec@gmail.com>
> > Cc: Linus Torvalds <torvalds@linux-foundation.org>
> > Cc: Peter Zijlstra <peterz@infradead.org>
> > Cc: Thomas Gleixner <tglx@linutronix.de>
> > Signed-off-by: Ingo Molnar <mingo@kernel.org>
> > ---
> > kernel/time/tick-sched.c | 11 ++++++++++-
> > 1 file changed, 10 insertions(+), 1 deletion(-)
> >
> > diff --git a/kernel/time/tick-sched.c b/kernel/time/tick-sched.c
> > index 764d290..ed18ca5 100644
> > --- a/kernel/time/tick-sched.c
> > +++ b/kernel/time/tick-sched.c
> > @@ -1200,8 +1200,17 @@ static enum hrtimer_restart tick_sched_timer(struct hrtimer *timer)
> > * Do not call, when we are not in irq context and have
> > * no valid regs pointer
> > */
> > - if (regs)
> > + if (regs) {
> > tick_sched_handle(ts, regs);
> > + } else {
> > + /*
> > + * IRQ regs are NULL if hrtimer_interrupt() is called from
> > + * non-interrupt contexts (ex: hotplug cpu down). Make sure to
> > + * clean the cached next tick deadline to avoid buggy bypass of
> > + * clock reprog.
> > + */
> > + ts->next_tick = 0;
> > + }
> >
> > /* No need to reprogram if we are in idle or full dynticks mode */
> > if (unlikely(ts->tick_stopped))
>
> Well, this does not answer my question: between latest tip:timers/nohz and the
> patches you posted there's a delta, so it's not just a pure rebase.
Yeah but like I said, you can forget the series I posted because the diff is
mostly cosmetic and things are actually ok as they are in tip:timers/nohz
The only thing that bothers me is the fact that the HEAD of this branch doesn't have
a changelog or even just a comment.
>
> I can do a rebase to resolve the bisectability problem (which isn't very serious
> by the way, only a single commit wide window, right?), but only if 'git diff
> old_branch new_branch' comes up empty.
>
> In every other case let's iterate the existing timers/nohz with additional
> patches, ok? I'd rather have a finegrained iteration with well-tested intermediate
> stages than break things again.
Ok so either we simply fixup HEAD~ with HEAD or we provide a changelog to the very last
patch. Which way do you prefer?
Thanks.
>
> Thanks,
>
> Ingo
^ permalink raw reply
* [PATCH 1/2] USB: core: fix device node leak
From: Johan Hovold @ 2017-05-29 14:32 UTC (permalink / raw)
To: Greg Kroah-Hartman; +Cc: linux-usb, Johan Hovold, stable, Peter Chen
In-Reply-To: <20170529143223.7397-1-johan@kernel.org>
Make sure to release any OF device-node reference taken when creating
the USB device.
Note that we currently do not hold a reference to the root hub
device-tree node (i.e. the parent controller node).
Fixes: 69bec7259853 ("USB: core: let USB device know device node")
Cc: stable <stable@vger.kernel.org> # v4.6
Cc: Peter Chen <peter.chen@nxp.com>
Signed-off-by: Johan Hovold <johan@kernel.org>
---
drivers/usb/core/usb.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/usb/core/usb.c b/drivers/usb/core/usb.c
index 28b053cacc90..62e1906bb2f3 100644
--- a/drivers/usb/core/usb.c
+++ b/drivers/usb/core/usb.c
@@ -416,6 +416,8 @@ static void usb_release_dev(struct device *dev)
usb_destroy_configuration(udev);
usb_release_bos_descriptor(udev);
+ if (udev->parent)
+ of_node_put(dev->of_node);
usb_put_hcd(hcd);
kfree(udev->product);
kfree(udev->manufacturer);
--
2.13.0
^ permalink raw reply related
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