Tomas Charvat <tc(a)excello.cz> wrote:
[ CC stable, Steffen ]
> Hi Florian and David, I'm running several servers that use XFRM ipsec.
> It do work well on all kernels bellow 4.14.0.
>
> It doesnt work on 4.14.0-2. There is no any error in dmesg or in
> userspace when I do configure policies.
>
> Since there is not much info about XFRM in dmesg I have no clue, where
> to start when I want to debug this issue.
David, please consider picking up
94802151894d482e82c324edf2c658f8e6b96508
("Revert "xfrm: Fix stack-out-of-bounds read in xfrm_state_find.")
for the 4.14.y stable queue.
I think its a pretty safe bet that this fixes the problem, it broke
transport mode wildcard policy lookup.
> I have seen that you have removed flow-cache that we have fixed 2 time.
> Do you have clue where to start with debug of this issue ?
If the revert doesn't help, please do a bug report to
netdev(a)vger.kernel.org and provide /proc/net/xfrm_stat content
and the list of policies/SAs.
[BUG]
fstrim on some btrfs only trims the unallocated space, not trimming any
space in existing block groups.
[CAUSE]
Before fstrim_range passed to btrfs_trim_fs(), it get truncated to
range [0, super->total_bytes).
So later btrfs_trim_fs() will only be able to trim block groups in range
[0, super->total_bytes).
While for btrfs, any bytenr aligned to sector size is valid, since btrfs use
its logical address space, there is nothing limiting the location where
we put block groups.
For btrfs with routine balance, it's quite easy to relocate all
block groups and bytenr of block groups will start beyond super->total_bytes.
In that case, btrfs will not trim existing block groups.
[FIX]
Just remove the truncation in btrfs_ioctl_fitrim(), so btrfs_trim_fs()
can get the unmodified range, which is normally set to [0, U64_MAX].
Reported-by: Chris Murphy <lists(a)colorremedies.com>
Fixes: f4c697e6406d ("btrfs: return EINVAL if start > total_bytes in fitrim ioctl")
Cc: <stable(a)vger.kernel.org> # v4.0+
Signed-off-by: Qu Wenruo <wqu(a)suse.com>
---
changelog:
v2:
Locate the root cause in btrfs_ioctl_fitrim(), remove the truncation
so we can still allow user to trim custom range.
---
fs/btrfs/ioctl.c | 11 +++++++----
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/fs/btrfs/ioctl.c b/fs/btrfs/ioctl.c
index fd172a93d11a..017fda31400d 100644
--- a/fs/btrfs/ioctl.c
+++ b/fs/btrfs/ioctl.c
@@ -365,7 +365,6 @@ static noinline int btrfs_ioctl_fitrim(struct file *file, void __user *arg)
struct fstrim_range range;
u64 minlen = ULLONG_MAX;
u64 num_devices = 0;
- u64 total_bytes = btrfs_super_total_bytes(fs_info->super_copy);
int ret;
if (!capable(CAP_SYS_ADMIN))
@@ -389,11 +388,15 @@ static noinline int btrfs_ioctl_fitrim(struct file *file, void __user *arg)
return -EOPNOTSUPP;
if (copy_from_user(&range, arg, sizeof(range)))
return -EFAULT;
- if (range.start > total_bytes ||
- range.len < fs_info->sb->s_blocksize)
+
+ /*
+ * NOTE: Don't truncate the range using super->total_bytes.
+ * Bytenr of btrfs block group is in btrfs logical address space,
+ * which can be any sector size aligned bytenr in [0, U64_MAX].
+ */
+ if (range.len < fs_info->sb->s_blocksize)
return -EINVAL;
- range.len = min(range.len, total_bytes - range.start);
range.minlen = max(range.minlen, minlen);
ret = btrfs_trim_fs(fs_info, &range);
if (ret < 0)
--
2.15.0
From: "Kirill A. Shutemov" <kirill.shutemov(a)linux.intel.com>
Subject: mm/hugetlb: fix NULL-pointer dereference on 5-level paging machine
I made a mistake during converting hugetlb code to 5-level paging: in
huge_pte_alloc() we have to use p4d_alloc(), not p4d_offset(). Otherwise
it leads to crash -- NULL-pointer dereference in pud_alloc() if p4d table
is not yet allocated.
It only can happen in 5-level paging mode. In 4-level paging mode
p4d_offset() always returns pgd, so we are fine.
Link: http://lkml.kernel.org/r/20171122121921.64822-1-kirill.shutemov@linux.intel…
Fixes: c2febafc6773 ("mm: convert generic code to 5-level paging")
Signed-off-by: Kirill A. Shutemov <kirill.shutemov(a)linux.intel.com>
Acked-by: Vlastimil Babka <vbabka(a)suse.cz>
Acked-by: Michal Hocko <mhocko(a)suse.com>
Cc: <stable(a)vger.kernel.org> [4.11+]
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
---
mm/hugetlb.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff -puN mm/hugetlb.c~mm-hugetlb-fix-null-pointer-dereference-on-5-level-paging-machine mm/hugetlb.c
--- a/mm/hugetlb.c~mm-hugetlb-fix-null-pointer-dereference-on-5-level-paging-machine
+++ a/mm/hugetlb.c
@@ -4635,7 +4635,9 @@ pte_t *huge_pte_alloc(struct mm_struct *
pte_t *pte = NULL;
pgd = pgd_offset(mm, addr);
- p4d = p4d_offset(pgd, addr);
+ p4d = p4d_alloc(mm, pgd, addr);
+ if (!p4d)
+ return NULL;
pud = pud_alloc(mm, p4d, addr);
if (pud) {
if (sz == PUD_SIZE) {
_
From: Ian Kent <raven(a)themaw.net>
Subject: autofs: revert "autofs: fix AT_NO_AUTOMOUNT not being honored"
42f4614821 ("autofs: fix AT_NO_AUTOMOUNT not being honored") allowed the
fstatat(2) system call to properly honor the AT_NO_AUTOMOUNT flag but
introduced a semantic change.
In order to honor AT_NO_AUTOMOUNT a semantic change was made to the
negative dentry case for stat family system calls in follow_automount().
This changed the unconditional triggering of an automount in this case to
no longer be done and an error returned instead.
This has caused more problems than I expected so reverting the change is
needed.
In a discussion with Neil Brown it was concluded that the automount(8)
daemon can implement this change without kernel modifications. So that
will be done instead and the autofs module documentation updated with a
description of the problem and what needs to be done by module users for
this specific case.
Link: http://lkml.kernel.org/r/151174730120.6162.3848002191530283984.stgit@pluto.…
Fixes: 42f4614821 ("autofs: fix AT_NO_AUTOMOUNT not being honored")
Signed-off-by: Ian Kent <raven(a)themaw.net>
Cc: Neil Brown <neilb(a)suse.com>
Cc: Al Viro <viro(a)ZenIV.linux.org.uk>
Cc: David Howells <dhowells(a)redhat.com>
Cc: Colin Walters <walters(a)redhat.com>
Cc: Ondrej Holy <oholy(a)redhat.com>
Cc: <stable(a)vger.kernel.org> [4.11+]
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
---
fs/namei.c | 15 +++------------
include/linux/fs.h | 3 ++-
2 files changed, 5 insertions(+), 13 deletions(-)
diff -puN fs/namei.c~autofs-revert-fix-at_no_automount-not-being-honored fs/namei.c
--- a/fs/namei.c~autofs-revert-fix-at_no_automount-not-being-honored
+++ a/fs/namei.c
@@ -1129,18 +1129,9 @@ static int follow_automount(struct path
* of the daemon to instantiate them before they can be used.
*/
if (!(nd->flags & (LOOKUP_PARENT | LOOKUP_DIRECTORY |
- LOOKUP_OPEN | LOOKUP_CREATE |
- LOOKUP_AUTOMOUNT))) {
- /* Positive dentry that isn't meant to trigger an
- * automount, EISDIR will allow it to be used,
- * otherwise there's no mount here "now" so return
- * ENOENT.
- */
- if (path->dentry->d_inode)
- return -EISDIR;
- else
- return -ENOENT;
- }
+ LOOKUP_OPEN | LOOKUP_CREATE | LOOKUP_AUTOMOUNT)) &&
+ path->dentry->d_inode)
+ return -EISDIR;
if (path->dentry->d_sb->s_user_ns != &init_user_ns)
return -EACCES;
diff -puN include/linux/fs.h~autofs-revert-fix-at_no_automount-not-being-honored include/linux/fs.h
--- a/include/linux/fs.h~autofs-revert-fix-at_no_automount-not-being-honored
+++ a/include/linux/fs.h
@@ -3088,7 +3088,8 @@ static inline int vfs_lstat(const char _
static inline int vfs_fstatat(int dfd, const char __user *filename,
struct kstat *stat, int flags)
{
- return vfs_statx(dfd, filename, flags, stat, STATX_BASIC_STATS);
+ return vfs_statx(dfd, filename, flags | AT_NO_AUTOMOUNT,
+ stat, STATX_BASIC_STATS);
}
static inline int vfs_fstat(int fd, struct kstat *stat)
{
_
From: Ian Kent <raven(a)themaw.net>
Subject: autofs: revert "autofs: take more care to not update last_used on path walk"
While 092a53452b ("autofs: take more care to not update last_used on path
walk") helped (partially) resolve a problem where automounts were not
expiring due to aggressive accesses from user space it has a side effect
for very large environments.
This change helps with the expire problem by making the expire more
aggressive but, for very large environments, that means more mount
requests from clients. When there are a lot of clients that can mean
fairly significant server load increases.
It turns out I put the last_used in this position to solve this very
problem and failed to update my own thinking of the autofs expire policy.
So the patch being reverted introduces a regression which should be fixed.
Link: http://lkml.kernel.org/r/151174729420.6162.1832622523537052460.stgit@pluto.…
Fixes: 092a53452b ("autofs: take more care to not update last_used on path walk")
Signed-off-by: Ian Kent <raven(a)themaw.net>
Reviewed-by: NeilBrown <neilb(a)suse.com>
Cc: Al Viro <viro(a)ZenIV.linux.org.uk>
Cc: <stable(a)vger.kernel.org> [4.11+]
Cc: Colin Walters <walters(a)redhat.com>
Cc: David Howells <dhowells(a)redhat.com>
Cc: Ondrej Holy <oholy(a)redhat.com>
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
---
fs/autofs4/root.c | 17 ++++++-----------
1 file changed, 6 insertions(+), 11 deletions(-)
diff -puN fs/autofs4/root.c~autofs-revert-take-more-care-to-not-update-last_used-on-path-walk fs/autofs4/root.c
--- a/fs/autofs4/root.c~autofs-revert-take-more-care-to-not-update-last_used-on-path-walk
+++ a/fs/autofs4/root.c
@@ -281,8 +281,8 @@ static int autofs4_mount_wait(const stru
pr_debug("waiting for mount name=%pd\n", path->dentry);
status = autofs4_wait(sbi, path, NFY_MOUNT);
pr_debug("mount wait done status=%d\n", status);
- ino->last_used = jiffies;
}
+ ino->last_used = jiffies;
return status;
}
@@ -321,21 +321,16 @@ static struct dentry *autofs4_mountpoint
*/
if (autofs_type_indirect(sbi->type) && d_unhashed(dentry)) {
struct dentry *parent = dentry->d_parent;
+ struct autofs_info *ino;
struct dentry *new;
new = d_lookup(parent, &dentry->d_name);
if (!new)
return NULL;
- if (new == dentry)
- dput(new);
- else {
- struct autofs_info *ino;
-
- ino = autofs4_dentry_ino(new);
- ino->last_used = jiffies;
- dput(path->dentry);
- path->dentry = new;
- }
+ ino = autofs4_dentry_ino(new);
+ ino->last_used = jiffies;
+ dput(path->dentry);
+ path->dentry = new;
}
return path->dentry;
}
_
From: Shakeel Butt <shakeelb(a)google.com>
Subject: mm, memcg: fix mem_cgroup_swapout() for THPs
d6810d730022 ("memcg, THP, swap: make mem_cgroup_swapout() support THP")
changed mem_cgroup_swapout() to support transparent huge page (THP).
However the patch missed one location which should be changed for
correctly handling THPs. The resulting bug will cause the memory cgroups
whose THPs were swapped out to become zombies on deletion.
Link: http://lkml.kernel.org/r/20171128161941.20931-1-shakeelb@google.com
Fixes: d6810d730022 ("memcg, THP, swap: make mem_cgroup_swapout() support THP")
Signed-off-by: Shakeel Butt <shakeelb(a)google.com>
Acked-by: Johannes Weiner <hannes(a)cmpxchg.org>
Acked-by: Michal Hocko <mhocko(a)suse.com>
Cc: Huang Ying <ying.huang(a)intel.com>
Cc: Vladimir Davydov <vdavydov.dev(a)gmail.com>
Cc: Greg Thelen <gthelen(a)google.com>
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
---
mm/memcontrol.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff -puN mm/memcontrol.c~mm-memcg-fix-mem_cgroup_swapout-for-thps mm/memcontrol.c
--- a/mm/memcontrol.c~mm-memcg-fix-mem_cgroup_swapout-for-thps
+++ a/mm/memcontrol.c
@@ -6044,7 +6044,7 @@ void mem_cgroup_swapout(struct page *pag
memcg_check_events(memcg, page);
if (!mem_cgroup_is_root(memcg))
- css_put(&memcg->css);
+ css_put_many(&memcg->css, nr_entries);
}
/**
_
From: chenjie <chenjie6(a)huawei.com>
Subject: mm/madvise.c: fix madvise() infinite loop under special circumstances
MADVISE_WILLNEED has always been a noop for DAX (formerly XIP) mappings.
Unfortunately madvise_willneed() doesn't communicate this information
properly to the generic madvise syscall implementation. The calling
convention is quite subtle there. madvise_vma() is supposed to either
return an error or update &prev otherwise the main loop will never advance
to the next vma and it will keep looping for ever without a way to get out
of the kernel.
It seems this has been broken since introduction. Nobody has noticed
because nobody seems to be using MADVISE_WILLNEED on these DAX mappings.
[mhocko(a)suse.com: rewrite changelog]
Link: http://lkml.kernel.org/r/20171127115318.911-1-guoxuenan@huawei.com
Fixes: fe77ba6f4f97 ("[PATCH] xip: madvice/fadvice: execute in place")
Signed-off-by: chenjie <chenjie6(a)huawei.com>
Signed-off-by: guoxuenan <guoxuenan(a)huawei.com>
Acked-by: Michal Hocko <mhocko(a)suse.com>
Cc: Minchan Kim <minchan(a)kernel.org>
Cc: zhangyi (F) <yi.zhang(a)huawei.com>
Cc: Miao Xie <miaoxie(a)huawei.com>
Cc: Mike Rapoport <rppt(a)linux.vnet.ibm.com>
Cc: Shaohua Li <shli(a)fb.com>
Cc: Andrea Arcangeli <aarcange(a)redhat.com>
Cc: Mel Gorman <mgorman(a)techsingularity.net>
Cc: Kirill A. Shutemov <kirill.shutemov(a)linux.intel.com>
Cc: David Rientjes <rientjes(a)google.com>
Cc: Anshuman Khandual <khandual(a)linux.vnet.ibm.com>
Cc: Rik van Riel <riel(a)redhat.com>
Cc: Carsten Otte <cotte(a)de.ibm.com>
Cc: Dan Williams <dan.j.williams(a)intel.com>
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
---
mm/madvise.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff -puN mm/madvise.c~mmmadvise-bugfix-of-madvise-systemcall-infinite-loop-under-special-circumstances mm/madvise.c
--- a/mm/madvise.c~mmmadvise-bugfix-of-madvise-systemcall-infinite-loop-under-special-circumstances
+++ a/mm/madvise.c
@@ -276,15 +276,14 @@ static long madvise_willneed(struct vm_a
{
struct file *file = vma->vm_file;
+ *prev = vma;
#ifdef CONFIG_SWAP
if (!file) {
- *prev = vma;
force_swapin_readahead(vma, start, end);
return 0;
}
if (shmem_mapping(file->f_mapping)) {
- *prev = vma;
force_shm_swapin_readahead(vma, start, end,
file->f_mapping);
return 0;
@@ -299,7 +298,6 @@ static long madvise_willneed(struct vm_a
return 0;
}
- *prev = vma;
start = ((start - vma->vm_start) >> PAGE_SHIFT) + vma->vm_pgoff;
if (end > vma->vm_end)
end = vma->vm_end;
_
From: Kees Cook <keescook(a)chromium.org>
Subject: exec: avoid RLIMIT_STACK races with prlimit()
While the defense-in-depth RLIMIT_STACK limit on setuid processes was
protected against races from other threads calling setrlimit(), I missed
protecting it against races from external processes calling prlimit().
This adds locking around the change and makes sure that rlim_max is set
too.
Link: http://lkml.kernel.org/r/20171127193457.GA11348@beast
Fixes: 64701dee4178e ("exec: Use sane stack rlimit under secureexec")
Signed-off-by: Kees Cook <keescook(a)chromium.org>
Reported-by: Ben Hutchings <ben.hutchings(a)codethink.co.uk>
Reported-by: Brad Spengler <spender(a)grsecurity.net>
Acked-by: Serge Hallyn <serge(a)hallyn.com>
Cc: James Morris <james.l.morris(a)oracle.com>
Cc: Andy Lutomirski <luto(a)kernel.org>
Cc: Oleg Nesterov <oleg(a)redhat.com>
Cc: Jiri Slaby <jslaby(a)suse.cz>
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
---
fs/exec.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff -puN fs/exec.c~exec-avoid-rlimit_stack-races-with-prlimit fs/exec.c
--- a/fs/exec.c~exec-avoid-rlimit_stack-races-with-prlimit
+++ a/fs/exec.c
@@ -1340,10 +1340,15 @@ void setup_new_exec(struct linux_binprm
* avoid bad behavior from the prior rlimits. This has to
* happen before arch_pick_mmap_layout(), which examines
* RLIMIT_STACK, but after the point of no return to avoid
- * needing to clean up the change on failure.
+ * races from other threads changing the limits. This also
+ * must be protected from races with prlimit() calls.
*/
+ task_lock(current->group_leader);
if (current->signal->rlim[RLIMIT_STACK].rlim_cur > _STK_LIM)
current->signal->rlim[RLIMIT_STACK].rlim_cur = _STK_LIM;
+ if (current->signal->rlim[RLIMIT_STACK].rlim_max > _STK_LIM)
+ current->signal->rlim[RLIMIT_STACK].rlim_max = _STK_LIM;
+ task_unlock(current->group_leader);
}
arch_pick_mmap_layout(current->mm);
_
From: Dan Williams <dan.j.williams(a)intel.com>
Subject: IB/core: disable memory registration of filesystem-dax vmas
Until there is a solution to the dma-to-dax vs truncate problem it is not
safe to allow RDMA to create long standing memory registrations against
filesytem-dax vmas.
Link: http://lkml.kernel.org/r/151068941011.7446.7766030590347262502.stgit@dwilli…
Fixes: 3565fce3a659 ("mm, x86: get_user_pages() for dax mappings")
Signed-off-by: Dan Williams <dan.j.williams(a)intel.com>
Reported-by: Christoph Hellwig <hch(a)lst.de>
Reviewed-by: Christoph Hellwig <hch(a)lst.de>
Acked-by: Jason Gunthorpe <jgg(a)mellanox.com>
Cc: Sean Hefty <sean.hefty(a)intel.com>
Cc: Doug Ledford <dledford(a)redhat.com>
Cc: Hal Rosenstock <hal.rosenstock(a)gmail.com>
Cc: Jeff Moyer <jmoyer(a)redhat.com>
Cc: Ross Zwisler <ross.zwisler(a)linux.intel.com>
Cc: Inki Dae <inki.dae(a)samsung.com>
Cc: Jan Kara <jack(a)suse.cz>
Cc: Joonyoung Shim <jy0922.shim(a)samsung.com>
Cc: Kyungmin Park <kyungmin.park(a)samsung.com>
Cc: Mauro Carvalho Chehab <mchehab(a)kernel.org>
Cc: Mel Gorman <mgorman(a)suse.de>
Cc: Seung-Woo Kim <sw0312.kim(a)samsung.com>
Cc: Vlastimil Babka <vbabka(a)suse.cz>
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
---
drivers/infiniband/core/umem.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff -puN drivers/infiniband/core/umem.c~ib-core-disable-memory-registration-of-fileystem-dax-vmas drivers/infiniband/core/umem.c
--- a/drivers/infiniband/core/umem.c~ib-core-disable-memory-registration-of-fileystem-dax-vmas
+++ a/drivers/infiniband/core/umem.c
@@ -191,7 +191,7 @@ struct ib_umem *ib_umem_get(struct ib_uc
sg_list_start = umem->sg_head.sgl;
while (npages) {
- ret = get_user_pages(cur_base,
+ ret = get_user_pages_longterm(cur_base,
min_t(unsigned long, npages,
PAGE_SIZE / sizeof (struct page *)),
gup_flags, page_list, vma_list);
_
From: Dan Williams <dan.j.williams(a)intel.com>
Subject: v4l2: disable filesystem-dax mapping support
V4L2 memory registrations are incompatible with filesystem-dax that needs
the ability to revoke dma access to a mapping at will, or otherwise allow
the kernel to wait for completion of DMA. The filesystem-dax
implementation breaks the traditional solution of truncate of active file
backed mappings since there is no page-cache page we can orphan to sustain
ongoing DMA.
If v4l2 wants to support long lived DMA mappings it needs to arrange to
hold a file lease or use some other mechanism so that the kernel can
coordinate revoking DMA access when the filesystem needs to truncate
mappings.
Link: http://lkml.kernel.org/r/151068940499.7446.12846708245365671207.stgit@dwill…
Fixes: 3565fce3a659 ("mm, x86: get_user_pages() for dax mappings")
Signed-off-by: Dan Williams <dan.j.williams(a)intel.com>
Reported-by: Jan Kara <jack(a)suse.cz>
Reviewed-by: Jan Kara <jack(a)suse.cz>
Cc: Mauro Carvalho Chehab <mchehab(a)kernel.org>
Cc: Christoph Hellwig <hch(a)lst.de>
Cc: Doug Ledford <dledford(a)redhat.com>
Cc: Hal Rosenstock <hal.rosenstock(a)gmail.com>
Cc: Inki Dae <inki.dae(a)samsung.com>
Cc: Jason Gunthorpe <jgg(a)mellanox.com>
Cc: Jeff Moyer <jmoyer(a)redhat.com>
Cc: Joonyoung Shim <jy0922.shim(a)samsung.com>
Cc: Kyungmin Park <kyungmin.park(a)samsung.com>
Cc: Mel Gorman <mgorman(a)suse.de>
Cc: Ross Zwisler <ross.zwisler(a)linux.intel.com>
Cc: Sean Hefty <sean.hefty(a)intel.com>
Cc: Seung-Woo Kim <sw0312.kim(a)samsung.com>
Cc: Vlastimil Babka <vbabka(a)suse.cz>
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
---
drivers/media/v4l2-core/videobuf-dma-sg.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff -puN drivers/media/v4l2-core/videobuf-dma-sg.c~v4l2-disable-filesystem-dax-mapping-support drivers/media/v4l2-core/videobuf-dma-sg.c
--- a/drivers/media/v4l2-core/videobuf-dma-sg.c~v4l2-disable-filesystem-dax-mapping-support
+++ a/drivers/media/v4l2-core/videobuf-dma-sg.c
@@ -185,12 +185,13 @@ static int videobuf_dma_init_user_locked
dprintk(1, "init user [0x%lx+0x%lx => %d pages]\n",
data, size, dma->nr_pages);
- err = get_user_pages(data & PAGE_MASK, dma->nr_pages,
+ err = get_user_pages_longterm(data & PAGE_MASK, dma->nr_pages,
flags, dma->pages, NULL);
if (err != dma->nr_pages) {
dma->nr_pages = (err >= 0) ? err : 0;
- dprintk(1, "get_user_pages: err=%d [%d]\n", err, dma->nr_pages);
+ dprintk(1, "get_user_pages_longterm: err=%d [%d]\n", err,
+ dma->nr_pages);
return err < 0 ? err : -EINVAL;
}
return 0;
_
From: Dan Williams <dan.j.williams(a)intel.com>
Subject: mm: fail get_vaddr_frames() for filesystem-dax mappings
Until there is a solution to the dma-to-dax vs truncate problem it is not
safe to allow V4L2, Exynos, and other frame vector users to create long
standing / irrevocable memory registrations against filesytem-dax vmas.
[dan.j.williams(a)intel.com: add comment for vma_is_fsdax() check in get_vaddr_frames(), per Jan]
Link: http://lkml.kernel.org/r/151197874035.26211.4061781453123083667.stgit@dwill…
Link: http://lkml.kernel.org/r/151068939985.7446.15684639617389154187.stgit@dwill…
Fixes: 3565fce3a659 ("mm, x86: get_user_pages() for dax mappings")
Signed-off-by: Dan Williams <dan.j.williams(a)intel.com>
Reviewed-by: Jan Kara <jack(a)suse.cz>
Cc: Inki Dae <inki.dae(a)samsung.com>
Cc: Seung-Woo Kim <sw0312.kim(a)samsung.com>
Cc: Joonyoung Shim <jy0922.shim(a)samsung.com>
Cc: Kyungmin Park <kyungmin.park(a)samsung.com>
Cc: Mauro Carvalho Chehab <mchehab(a)kernel.org>
Cc: Mel Gorman <mgorman(a)suse.de>
Cc: Vlastimil Babka <vbabka(a)suse.cz>
Cc: Christoph Hellwig <hch(a)lst.de>
Cc: Doug Ledford <dledford(a)redhat.com>
Cc: Hal Rosenstock <hal.rosenstock(a)gmail.com>
Cc: Jason Gunthorpe <jgg(a)mellanox.com>
Cc: Jeff Moyer <jmoyer(a)redhat.com>
Cc: Ross Zwisler <ross.zwisler(a)linux.intel.com>
Cc: Sean Hefty <sean.hefty(a)intel.com>
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
---
mm/frame_vector.c | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff -puN mm/frame_vector.c~mm-fail-get_vaddr_frames-for-filesystem-dax-mappings mm/frame_vector.c
--- a/mm/frame_vector.c~mm-fail-get_vaddr_frames-for-filesystem-dax-mappings
+++ a/mm/frame_vector.c
@@ -53,6 +53,18 @@ int get_vaddr_frames(unsigned long start
ret = -EFAULT;
goto out;
}
+
+ /*
+ * While get_vaddr_frames() could be used for transient (kernel
+ * controlled lifetime) pinning of memory pages all current
+ * users establish long term (userspace controlled lifetime)
+ * page pinning. Treat get_vaddr_frames() like
+ * get_user_pages_longterm() and disallow it for filesystem-dax
+ * mappings.
+ */
+ if (vma_is_fsdax(vma))
+ return -EOPNOTSUPP;
+
if (!(vma->vm_flags & (VM_IO | VM_PFNMAP))) {
vec->got_ref = true;
vec->is_pfns = false;
_
From: Dan Williams <dan.j.williams(a)intel.com>
Subject: mm: introduce get_user_pages_longterm
Patch series "introduce get_user_pages_longterm()", v2.
Here is a new get_user_pages api for cases where a driver intends to keep
an elevated page count indefinitely. This is distinct from usages like
iov_iter_get_pages where the elevated page counts are transient. The
iov_iter_get_pages cases immediately turn around and submit the pages to a
device driver which will put_page when the i/o operation completes (under
kernel control).
In the longterm case userspace is responsible for dropping the page
reference at some undefined point in the future. This is untenable for
filesystem-dax case where the filesystem is in control of the lifetime of
the block / page and needs reasonable limits on how long it can wait for
pages in a mapping to become idle.
Fixing filesystems to actually wait for dax pages to be idle before blocks
from a truncate/hole-punch operation are repurposed is saved for a later
patch series.
Also, allowing longterm registration of dax mappings is a future patch
series that introduces a "map with lease" semantic where the kernel can
revoke a lease and force userspace to drop its page references.
I have also tagged these for -stable to purposely break cases that might
assume that longterm memory registrations for filesystem-dax mappings were
supported by the kernel. The behavior regression this policy change
implies is one of the reasons we maintain the "dax enabled. Warning:
EXPERIMENTAL, use at your own risk" notification when mounting a
filesystem in dax mode.
It is worth noting the device-dax interface does not suffer the same
constraints since it does not support file space management operations
like hole-punch.
This patch (of 4):
Until there is a solution to the dma-to-dax vs truncate problem it is not
safe to allow long standing memory registrations against filesytem-dax
vmas. Device-dax vmas do not have this problem and are explicitly
allowed.
This is temporary until a "memory registration with layout-lease"
mechanism can be implemented for the affected sub-systems (RDMA and V4L2).
[akpm(a)linux-foundation.org: use kcalloc()]
Link: http://lkml.kernel.org/r/151068939435.7446.13560129395419350737.stgit@dwill…
Fixes: 3565fce3a659 ("mm, x86: get_user_pages() for dax mappings")
Signed-off-by: Dan Williams <dan.j.williams(a)intel.com>
Suggested-by: Christoph Hellwig <hch(a)lst.de>
Cc: Doug Ledford <dledford(a)redhat.com>
Cc: Hal Rosenstock <hal.rosenstock(a)gmail.com>
Cc: Inki Dae <inki.dae(a)samsung.com>
Cc: Jan Kara <jack(a)suse.cz>
Cc: Jason Gunthorpe <jgg(a)mellanox.com>
Cc: Jeff Moyer <jmoyer(a)redhat.com>
Cc: Joonyoung Shim <jy0922.shim(a)samsung.com>
Cc: Kyungmin Park <kyungmin.park(a)samsung.com>
Cc: Mauro Carvalho Chehab <mchehab(a)kernel.org>
Cc: Mel Gorman <mgorman(a)suse.de>
Cc: Ross Zwisler <ross.zwisler(a)linux.intel.com>
Cc: Sean Hefty <sean.hefty(a)intel.com>
Cc: Seung-Woo Kim <sw0312.kim(a)samsung.com>
Cc: Vlastimil Babka <vbabka(a)suse.cz>
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
---
include/linux/fs.h | 14 +++++++++
include/linux/mm.h | 13 ++++++++
mm/gup.c | 64 +++++++++++++++++++++++++++++++++++++++++++
3 files changed, 91 insertions(+)
diff -puN include/linux/fs.h~mm-introduce-get_user_pages_longterm include/linux/fs.h
--- a/include/linux/fs.h~mm-introduce-get_user_pages_longterm
+++ a/include/linux/fs.h
@@ -3194,6 +3194,20 @@ static inline bool vma_is_dax(struct vm_
return vma->vm_file && IS_DAX(vma->vm_file->f_mapping->host);
}
+static inline bool vma_is_fsdax(struct vm_area_struct *vma)
+{
+ struct inode *inode;
+
+ if (!vma->vm_file)
+ return false;
+ if (!vma_is_dax(vma))
+ return false;
+ inode = file_inode(vma->vm_file);
+ if (inode->i_mode == S_IFCHR)
+ return false; /* device-dax */
+ return true;
+}
+
static inline int iocb_flags(struct file *file)
{
int res = 0;
diff -puN include/linux/mm.h~mm-introduce-get_user_pages_longterm include/linux/mm.h
--- a/include/linux/mm.h~mm-introduce-get_user_pages_longterm
+++ a/include/linux/mm.h
@@ -1380,6 +1380,19 @@ long get_user_pages_locked(unsigned long
unsigned int gup_flags, struct page **pages, int *locked);
long get_user_pages_unlocked(unsigned long start, unsigned long nr_pages,
struct page **pages, unsigned int gup_flags);
+#ifdef CONFIG_FS_DAX
+long get_user_pages_longterm(unsigned long start, unsigned long nr_pages,
+ unsigned int gup_flags, struct page **pages,
+ struct vm_area_struct **vmas);
+#else
+static inline long get_user_pages_longterm(unsigned long start,
+ unsigned long nr_pages, unsigned int gup_flags,
+ struct page **pages, struct vm_area_struct **vmas)
+{
+ return get_user_pages(start, nr_pages, gup_flags, pages, vmas);
+}
+#endif /* CONFIG_FS_DAX */
+
int get_user_pages_fast(unsigned long start, int nr_pages, int write,
struct page **pages);
diff -puN mm/gup.c~mm-introduce-get_user_pages_longterm mm/gup.c
--- a/mm/gup.c~mm-introduce-get_user_pages_longterm
+++ a/mm/gup.c
@@ -1095,6 +1095,70 @@ long get_user_pages(unsigned long start,
}
EXPORT_SYMBOL(get_user_pages);
+#ifdef CONFIG_FS_DAX
+/*
+ * This is the same as get_user_pages() in that it assumes we are
+ * operating on the current task's mm, but it goes further to validate
+ * that the vmas associated with the address range are suitable for
+ * longterm elevated page reference counts. For example, filesystem-dax
+ * mappings are subject to the lifetime enforced by the filesystem and
+ * we need guarantees that longterm users like RDMA and V4L2 only
+ * establish mappings that have a kernel enforced revocation mechanism.
+ *
+ * "longterm" == userspace controlled elevated page count lifetime.
+ * Contrast this to iov_iter_get_pages() usages which are transient.
+ */
+long get_user_pages_longterm(unsigned long start, unsigned long nr_pages,
+ unsigned int gup_flags, struct page **pages,
+ struct vm_area_struct **vmas_arg)
+{
+ struct vm_area_struct **vmas = vmas_arg;
+ struct vm_area_struct *vma_prev = NULL;
+ long rc, i;
+
+ if (!pages)
+ return -EINVAL;
+
+ if (!vmas) {
+ vmas = kcalloc(nr_pages, sizeof(struct vm_area_struct *),
+ GFP_KERNEL);
+ if (!vmas)
+ return -ENOMEM;
+ }
+
+ rc = get_user_pages(start, nr_pages, gup_flags, pages, vmas);
+
+ for (i = 0; i < rc; i++) {
+ struct vm_area_struct *vma = vmas[i];
+
+ if (vma == vma_prev)
+ continue;
+
+ vma_prev = vma;
+
+ if (vma_is_fsdax(vma))
+ break;
+ }
+
+ /*
+ * Either get_user_pages() failed, or the vma validation
+ * succeeded, in either case we don't need to put_page() before
+ * returning.
+ */
+ if (i >= rc)
+ goto out;
+
+ for (i = 0; i < rc; i++)
+ put_page(pages[i]);
+ rc = -EOPNOTSUPP;
+out:
+ if (vmas != vmas_arg)
+ kfree(vmas);
+ return rc;
+}
+EXPORT_SYMBOL(get_user_pages_longterm);
+#endif /* CONFIG_FS_DAX */
+
/**
* populate_vma_page_range() - populate a range of pages in the vma.
* @vma: target vma
_
From: Dan Williams <dan.j.williams(a)intel.com>
Subject: mm, hugetlbfs: introduce ->split() to vm_operations_struct
Patch series "device-dax: fix unaligned munmap handling"
When device-dax is operating in huge-page mode we want it to behave like
hugetlbfs and fail attempts to split vmas into unaligned ranges. It would
be messy to teach the munmap path about device-dax alignment constraints
in the same (hstate) way that hugetlbfs communicates this constraint.
Instead, these patches introduce a new ->split() vm operation.
This patch (of 2):
The device-dax interface has similar constraints as hugetlbfs in that it
requires the munmap path to unmap in huge page aligned units. Rather than
add more custom vma handling code in __split_vma() introduce a new vm
operation to perform this vma specific check.
Link: http://lkml.kernel.org/r/151130418135.4029.6783191281930729710.stgit@dwilli…
Fixes: dee410792419 ("/dev/dax, core: file operations and dax-mmap")
Signed-off-by: Dan Williams <dan.j.williams(a)intel.com>
Cc: Jeff Moyer <jmoyer(a)redhat.com>
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
---
include/linux/mm.h | 1 +
mm/hugetlb.c | 8 ++++++++
mm/mmap.c | 8 +++++---
3 files changed, 14 insertions(+), 3 deletions(-)
diff -puN include/linux/mm.h~mm-hugetlbfs-introduce-split-to-vm_operations_struct include/linux/mm.h
--- a/include/linux/mm.h~mm-hugetlbfs-introduce-split-to-vm_operations_struct
+++ a/include/linux/mm.h
@@ -377,6 +377,7 @@ enum page_entry_size {
struct vm_operations_struct {
void (*open)(struct vm_area_struct * area);
void (*close)(struct vm_area_struct * area);
+ int (*split)(struct vm_area_struct * area, unsigned long addr);
int (*mremap)(struct vm_area_struct * area);
int (*fault)(struct vm_fault *vmf);
int (*huge_fault)(struct vm_fault *vmf, enum page_entry_size pe_size);
diff -puN mm/hugetlb.c~mm-hugetlbfs-introduce-split-to-vm_operations_struct mm/hugetlb.c
--- a/mm/hugetlb.c~mm-hugetlbfs-introduce-split-to-vm_operations_struct
+++ a/mm/hugetlb.c
@@ -3125,6 +3125,13 @@ static void hugetlb_vm_op_close(struct v
}
}
+static int hugetlb_vm_op_split(struct vm_area_struct *vma, unsigned long addr)
+{
+ if (addr & ~(huge_page_mask(hstate_vma(vma))))
+ return -EINVAL;
+ return 0;
+}
+
/*
* We cannot handle pagefaults against hugetlb pages at all. They cause
* handle_mm_fault() to try to instantiate regular-sized pages in the
@@ -3141,6 +3148,7 @@ const struct vm_operations_struct hugetl
.fault = hugetlb_vm_op_fault,
.open = hugetlb_vm_op_open,
.close = hugetlb_vm_op_close,
+ .split = hugetlb_vm_op_split,
};
static pte_t make_huge_pte(struct vm_area_struct *vma, struct page *page,
diff -puN mm/mmap.c~mm-hugetlbfs-introduce-split-to-vm_operations_struct mm/mmap.c
--- a/mm/mmap.c~mm-hugetlbfs-introduce-split-to-vm_operations_struct
+++ a/mm/mmap.c
@@ -2555,9 +2555,11 @@ int __split_vma(struct mm_struct *mm, st
struct vm_area_struct *new;
int err;
- if (is_vm_hugetlb_page(vma) && (addr &
- ~(huge_page_mask(hstate_vma(vma)))))
- return -EINVAL;
+ if (vma->vm_ops && vma->vm_ops->split) {
+ err = vma->vm_ops->split(vma, addr);
+ if (err)
+ return err;
+ }
new = kmem_cache_alloc(vm_area_cachep, GFP_KERNEL);
if (!new)
_
From: Dan Williams <dan.j.williams(a)intel.com>
Subject: mm: fix device-dax pud write-faults triggered by get_user_pages()
Currently only get_user_pages_fast() can safely handle the writable gup
case due to its use of pud_access_permitted() to check whether the pud
entry is writable. In the gup slow path pud_write() is used instead of
pud_access_permitted() and to date it has been unimplemented, just calls
BUG_ON().
kernel BUG at ./include/linux/hugetlb.h:244!
[..]
RIP: 0010:follow_devmap_pud+0x482/0x490
[..]
Call Trace:
follow_page_mask+0x28c/0x6e0
__get_user_pages+0xe4/0x6c0
get_user_pages_unlocked+0x130/0x1b0
get_user_pages_fast+0x89/0xb0
iov_iter_get_pages_alloc+0x114/0x4a0
nfs_direct_read_schedule_iovec+0xd2/0x350
? nfs_start_io_direct+0x63/0x70
nfs_file_direct_read+0x1e0/0x250
nfs_file_read+0x90/0xc0
For now this just implements a simple check for the _PAGE_RW bit similar
to pmd_write. However, this implies that the gup-slow-path check is
missing the extra checks that the gup-fast-path performs with
pud_access_permitted. Later patches will align all checks to use the
'access_permitted' helper if the architecture provides it. Note that the
generic 'access_permitted' helper fallback is the simple _PAGE_RW check on
architectures that do not define the 'access_permitted' helper(s).
[dan.j.williams(a)intel.com: fix powerpc compile error]
Link: http://lkml.kernel.org/r/151129126165.37405.16031785266675461397.stgit@dwil…
Link: http://lkml.kernel.org/r/151043109938.2842.14834662818213616199.stgit@dwill…
Fixes: a00cc7d9dd93 ("mm, x86: add support for PUD-sized transparent hugepages")
Signed-off-by: Dan Williams <dan.j.williams(a)intel.com>
Reported-by: Stephen Rothwell <sfr(a)canb.auug.org.au>
Acked-by: Thomas Gleixner <tglx(a)linutronix.de> [x86]
Cc: Kirill A. Shutemov <kirill.shutemov(a)linux.intel.com>
Cc: Catalin Marinas <catalin.marinas(a)arm.com>
Cc: "David S. Miller" <davem(a)davemloft.net>
Cc: Dave Hansen <dave.hansen(a)intel.com>
Cc: Will Deacon <will.deacon(a)arm.com>
Cc: "H. Peter Anvin" <hpa(a)zytor.com>
Cc: Ingo Molnar <mingo(a)redhat.com>
Cc: Arnd Bergmann <arnd(a)arndb.de>
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
---
arch/x86/include/asm/pgtable.h | 6 ++++++
include/asm-generic/pgtable.h | 8 ++++++++
include/linux/hugetlb.h | 8 --------
3 files changed, 14 insertions(+), 8 deletions(-)
diff -puN arch/x86/include/asm/pgtable.h~mm-fix-device-dax-pud-write-faults-triggered-by-get_user_pages arch/x86/include/asm/pgtable.h
--- a/arch/x86/include/asm/pgtable.h~mm-fix-device-dax-pud-write-faults-triggered-by-get_user_pages
+++ a/arch/x86/include/asm/pgtable.h
@@ -1088,6 +1088,12 @@ static inline void pmdp_set_wrprotect(st
clear_bit(_PAGE_BIT_RW, (unsigned long *)pmdp);
}
+#define pud_write pud_write
+static inline int pud_write(pud_t pud)
+{
+ return pud_flags(pud) & _PAGE_RW;
+}
+
/*
* clone_pgd_range(pgd_t *dst, pgd_t *src, int count);
*
diff -puN include/asm-generic/pgtable.h~mm-fix-device-dax-pud-write-faults-triggered-by-get_user_pages include/asm-generic/pgtable.h
--- a/include/asm-generic/pgtable.h~mm-fix-device-dax-pud-write-faults-triggered-by-get_user_pages
+++ a/include/asm-generic/pgtable.h
@@ -814,6 +814,14 @@ static inline int pmd_write(pmd_t pmd)
#endif /* __HAVE_ARCH_PMD_WRITE */
#endif /* CONFIG_TRANSPARENT_HUGEPAGE */
+#ifndef pud_write
+static inline int pud_write(pud_t pud)
+{
+ BUG();
+ return 0;
+}
+#endif /* pud_write */
+
#if !defined(CONFIG_TRANSPARENT_HUGEPAGE) || \
(defined(CONFIG_TRANSPARENT_HUGEPAGE) && \
!defined(CONFIG_HAVE_ARCH_TRANSPARENT_HUGEPAGE_PUD))
diff -puN include/linux/hugetlb.h~mm-fix-device-dax-pud-write-faults-triggered-by-get_user_pages include/linux/hugetlb.h
--- a/include/linux/hugetlb.h~mm-fix-device-dax-pud-write-faults-triggered-by-get_user_pages
+++ a/include/linux/hugetlb.h
@@ -239,14 +239,6 @@ static inline int pgd_write(pgd_t pgd)
}
#endif
-#ifndef pud_write
-static inline int pud_write(pud_t pud)
-{
- BUG();
- return 0;
-}
-#endif
-
#define HUGETLB_ANON_FILE "anon_hugepage"
enum {
_
From: Mike Kravetz <mike.kravetz(a)oracle.com>
Subject: mm/cma: fix alloc_contig_range ret code/potential leak
If the call __alloc_contig_migrate_range() in alloc_contig_range returns
-EBUSY, processing continues so that test_pages_isolated() is called where
there is a tracepoint to identify the busy pages. However, it is possible
for busy pages to become available between the calls to these two
routines. In this case, the range of pages may be allocated.
Unfortunately, the original return code (ret == -EBUSY) is still set and
returned to the caller. Therefore, the caller believes the pages were not
allocated and they are leaked.
Update comment to indicate that allocation is still possible even if
__alloc_contig_migrate_range returns -EBUSY. Also, clear return code in
this case so that it is not accidentally used or returned to caller.
Link: http://lkml.kernel.org/r/20171122185214.25285-1-mike.kravetz@oracle.com
Fixes: 8ef5849fa8a2 ("mm/cma: always check which page caused allocation failure")
Signed-off-by: Mike Kravetz <mike.kravetz(a)oracle.com>
Acked-by: Vlastimil Babka <vbabka(a)suse.cz>
Acked-by: Michal Hocko <mhocko(a)suse.com>
Acked-by: Johannes Weiner <hannes(a)cmpxchg.org>
Acked-by: Joonsoo Kim <iamjoonsoo.kim(a)lge.com>
Cc: Michal Nazarewicz <mina86(a)mina86.com>
Cc: Laura Abbott <labbott(a)redhat.com>
Cc: Michal Hocko <mhocko(a)suse.com>
Cc: Mel Gorman <mgorman(a)techsingularity.net>
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
---
mm/page_alloc.c | 9 ++++++++-
1 file changed, 8 insertions(+), 1 deletion(-)
diff -puN mm/page_alloc.c~mm-cma-fix-alloc_contig_range-ret-code-potential-leak-v2 mm/page_alloc.c
--- a/mm/page_alloc.c~mm-cma-fix-alloc_contig_range-ret-code-potential-leak-v2
+++ a/mm/page_alloc.c
@@ -7652,11 +7652,18 @@ int alloc_contig_range(unsigned long sta
/*
* In case of -EBUSY, we'd like to know which page causes problem.
- * So, just fall through. We will check it in test_pages_isolated().
+ * So, just fall through. test_pages_isolated() has a tracepoint
+ * which will report the busy page.
+ *
+ * It is possible that busy pages could become available before
+ * the call to test_pages_isolated, and the range will actually be
+ * allocated. So, if we fall through be sure to clear ret so that
+ * -EBUSY is not accidentally used or returned to caller.
*/
ret = __alloc_contig_migrate_range(&cc, start, end);
if (ret && ret != -EBUSY)
goto done;
+ ret =0;
/*
* Pages from [start, end) are within a MAX_ORDER_NR_PAGES
_
From: Wang Nan <wangnan0(a)huawei.com>
Subject: mm, oom_reaper: gather each vma to prevent leaking TLB entry
tlb_gather_mmu(&tlb, mm, 0, -1) means gathering the whole virtual memory
space. In this case, tlb->fullmm is true. Some archs like arm64 doesn't
flush TLB when tlb->fullmm is true:
commit 5a7862e83000 ("arm64: tlbflush: avoid flushing when fullmm == 1").
Which causes leaking of tlb entries.
Will clarifies his patch:
: Basically, we tag each address space with an ASID (PCID on x86) which
: is resident in the TLB. This means we can elide TLB invalidation when
: pulling down a full mm because we won't ever assign that ASID to another mm
: without doing TLB invalidation elsewhere (which actually just nukes the
: whole TLB).
:
: I think that means that we could potentially not fault on a kernel uaccess,
: because we could hit in the TLB.
There could be a window between complete_signal() sending IPI to other
cores and all threads sharing this mm are really kicked off from cores.
In this window, the oom reaper may calls tlb_flush_mmu_tlbonly() to flush
TLB then frees pages. However, due to the above problem, the TLB entries
are not really flushed on arm64. Other threads are possible to access
these pages through TLB entries. Moreover, a copy_to_user() can also
write to these pages without generating page fault, causes use-after-free
bugs.
This patch gathers each vma instead of gathering full vm space. In this
case tlb->fullmm is not true. The behavior of oom reaper become similar
to munmapping before do_exit, which should be safe for all archs.
Link: http://lkml.kernel.org/r/20171107095453.179940-1-wangnan0@huawei.com
Fixes: aac453635549 ("mm, oom: introduce oom reaper")
Signed-off-by: Wang Nan <wangnan0(a)huawei.com>
Acked-by: Michal Hocko <mhocko(a)suse.com>
Acked-by: David Rientjes <rientjes(a)google.com>
Cc: Minchan Kim <minchan(a)kernel.org>
Cc: Will Deacon <will.deacon(a)arm.com>
Cc: Bob Liu <liubo95(a)huawei.com>
Cc: Ingo Molnar <mingo(a)kernel.org>
Cc: Roman Gushchin <guro(a)fb.com>
Cc: Konstantin Khlebnikov <khlebnikov(a)yandex-team.ru>
Cc: Andrea Arcangeli <aarcange(a)redhat.com>
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
---
mm/oom_kill.c | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
diff -puN mm/oom_kill.c~mm-oom_reaper-gather-each-vma-to-prevent-leaking-tlb-entry mm/oom_kill.c
--- a/mm/oom_kill.c~mm-oom_reaper-gather-each-vma-to-prevent-leaking-tlb-entry
+++ a/mm/oom_kill.c
@@ -550,7 +550,6 @@ static bool __oom_reap_task_mm(struct ta
*/
set_bit(MMF_UNSTABLE, &mm->flags);
- tlb_gather_mmu(&tlb, mm, 0, -1);
for (vma = mm->mmap ; vma; vma = vma->vm_next) {
if (!can_madv_dontneed_vma(vma))
continue;
@@ -565,11 +564,13 @@ static bool __oom_reap_task_mm(struct ta
* we do not want to block exit_mmap by keeping mm ref
* count elevated without a good reason.
*/
- if (vma_is_anonymous(vma) || !(vma->vm_flags & VM_SHARED))
+ if (vma_is_anonymous(vma) || !(vma->vm_flags & VM_SHARED)) {
+ tlb_gather_mmu(&tlb, mm, vma->vm_start, vma->vm_end);
unmap_page_range(&tlb, vma, vma->vm_start, vma->vm_end,
NULL);
+ tlb_finish_mmu(&tlb, vma->vm_start, vma->vm_end);
+ }
}
- tlb_finish_mmu(&tlb, 0, -1);
pr_info("oom_reaper: reaped process %d (%s), now anon-rss:%lukB, file-rss:%lukB, shmem-rss:%lukB\n",
task_pid_nr(tsk), tsk->comm,
K(get_mm_counter(mm, MM_ANONPAGES)),
_
From: Michal Hocko <mhocko(a)suse.com>
Subject: mm, memory_hotplug: do not back off draining pcp free pages from kworker context
drain_all_pages backs off when called from a kworker context since
0ccce3b924212 ("mm, page_alloc: drain per-cpu pages from workqueue
context") because the original IPI based pcp draining has been replaced by
a WQ based one and the check wanted to prevent from recursion and inter
workers dependencies. This has made some sense at the time because the
system WQ has been used and one worker holding the lock could be blocked
while waiting for new workers to emerge which can be a problem under OOM
conditions.
Since then ce612879ddc7 ("mm: move pcp and lru-pcp draining into single
wq") has moved draining to a dedicated (mm_percpu_wq) WQ with a rescuer so
we shouldn't depend on any other WQ activity to make a forward progress so
calling drain_all_pages from a worker context is safe as long as this
doesn't happen from mm_percpu_wq itself which is not the case because all
workers are required to _not_ depend on any MM locks.
Why is this a problem in the first place? ACPI driven memory hot-remove
(acpi_device_hotplug) is executed from the worker context. We end up
calling __offline_pages to free all the pages and that requires both
lru_add_drain_all_cpuslocked and drain_all_pages to do their job otherwise
we can have dangling pages on pcp lists and fail the offline operation
(__test_page_isolated_in_pageblock would see a page with 0 ref. count but
without PageBuddy set).
Fix the issue by removing the worker check in drain_all_pages.
lru_add_drain_all_cpuslocked doesn't have this restriction so it works as
expected.
Link: http://lkml.kernel.org/r/20170828093341.26341-1-mhocko@kernel.org
Fixes: 0ccce3b924212 ("mm, page_alloc: drain per-cpu pages from workqueue context")
Signed-off-by: Michal Hocko <mhocko(a)suse.com>
Cc: Mel Gorman <mgorman(a)suse.de>
Cc: Tejun Heo <tj(a)kernel.org>
Cc: <stable(a)vger.kernel.org> [4.11+]
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
---
mm/page_alloc.c | 4 ----
1 file changed, 4 deletions(-)
diff -puN mm/page_alloc.c~mm-memory_hotplug-do-not-back-off-draining-pcp-free-pages-from-kworker-context mm/page_alloc.c
--- a/mm/page_alloc.c~mm-memory_hotplug-do-not-back-off-draining-pcp-free-pages-from-kworker-context
+++ a/mm/page_alloc.c
@@ -2507,10 +2507,6 @@ void drain_all_pages(struct zone *zone)
if (WARN_ON_ONCE(!mm_percpu_wq))
return;
- /* Workqueues cannot recurse */
- if (current->flags & PF_WQ_WORKER)
- return;
-
/*
* Do not drain if one is already in progress unless it's specific to
* a zone. Such callers are primarily CMA and memory hotplug and need
_
Fix an API loophole introduced with commit 9791554b45a2 ("MIPS,prctl:
add PR_[GS]ET_FP_MODE prctl options for MIPS"), where the caller of
prctl(2) is incorrectly allowed to make a change to CP0.Status.FR or
CP0.Config5.FRE register bits even if CONFIG_MIPS_O32_FP64_SUPPORT has
not been enabled, despite that an executable requesting the mode
requested via ELF file annotation would not be allowed to run in the
first place, or for n64 and n64 ABI tasks which do not have non-default
modes defined at all. Add suitable checks to `mips_set_process_fp_mode'
and bail out if an invalid mode change has been requested for the ABI in
effect, even if the FPU hardware or emulation would otherwise allow it.
Always succeed however without taking any further action if the mode
requested is the same as one already in effect, regardless of whether
any mode change, should it be requested, would actually be allowed for
the task concerned.
Cc: stable(a)vger.kernel.org # 4.0+
Fixes: 9791554b45a2 ("MIPS,prctl: add PR_[GS]ET_FP_MODE prctl options for MIPS")
Signed-off-by: Maciej W. Rozycki <macro(a)mips.com>
---
arch/mips/kernel/process.c | 12 ++++++++++++
1 file changed, 12 insertions(+)
linux-mips-prctl-fp-mode-o32-fp64.diff
Index: linux-sfr-test/arch/mips/kernel/process.c
===================================================================
--- linux-sfr-test.orig/arch/mips/kernel/process.c 2017-11-25 12:40:55.868109000 +0000
+++ linux-sfr-test/arch/mips/kernel/process.c 2017-11-25 12:41:56.411578000 +0000
@@ -705,6 +705,18 @@ int mips_set_process_fp_mode(struct task
struct task_struct *t;
int max_users;
+ /* If nothing to change, return right away, successfully. */
+ if (value == mips_get_process_fp_mode(task))
+ return 0;
+
+ /* Only accept a mode change if 64-bit FP enabled for o32. */
+ if (!IS_ENABLED(CONFIG_MIPS_O32_FP64_SUPPORT))
+ return -EOPNOTSUPP;
+
+ /* And only for o32 tasks. */
+ if (IS_ENABLED(CONFIG_64BIT) && !test_thread_flag(TIF_32BIT_REGS))
+ return -EOPNOTSUPP;
+
/* Check the value is valid */
if (value & ~known_bits)
return -EOPNOTSUPP;
From: Ville Syrjälä <ville.syrjala(a)linux.intel.com>
Previously I was under the impression that the scanline counter
reads 0 when the pipe is off. Turns out that's not correct, and
instead the scanline counter simply stops when the pipe stops, and
it retains it's last value until the pipe starts up again, at which
point the scanline counter jumps to vblank start.
These jumps can cause the timestamp to jump backwards by one frame.
Since we use the timestamps to guesstimage also the frame counter
value on gen2, that would cause the frame counter to also jump
backwards, which leads to a massice difference from the previous value.
The end result is that flips/vblank events don't appear to complete as
they're stuck waiting for the frame counter to catch up to that massive
difference.
Fix the problem properly by actually making sure the scanline counter
has started to move before we assume that it's safe to enable vblank
processing.
v2: Less pointless duplication in the code (Chris)
Cc: stable(a)vger.kernel.org
Cc: Daniel Vetter <daniel.vetter(a)ffwll.ch>
Cc: Chris Wilson <chris(a)chris-wilson.co.uk>
Reviewed-by: Chris Wilson <chris(a)chris-wilson.co.uk> #v1
Fixes: b7792d8b54cc ("drm/i915: Wait for pipe to start before sampling vblank timestamps on gen2")
Signed-off-by: Ville Syrjälä <ville.syrjala(a)linux.intel.com>
---
drivers/gpu/drm/i915/intel_display.c | 51 +++++++++++++++++++++++++-----------
1 file changed, 35 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
index f7dc7b7fed80..7280dd699316 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -998,7 +998,8 @@ enum transcoder intel_pipe_to_cpu_transcoder(struct drm_i915_private *dev_priv,
return crtc->config->cpu_transcoder;
}
-static bool pipe_dsl_stopped(struct drm_i915_private *dev_priv, enum pipe pipe)
+static bool pipe_scanline_is_moving(struct drm_i915_private *dev_priv,
+ enum pipe pipe)
{
i915_reg_t reg = PIPEDSL(pipe);
u32 line1, line2;
@@ -1013,7 +1014,28 @@ static bool pipe_dsl_stopped(struct drm_i915_private *dev_priv, enum pipe pipe)
msleep(5);
line2 = I915_READ(reg) & line_mask;
- return line1 == line2;
+ return line1 != line2;
+}
+
+static void wait_for_pipe_scanline_moving(struct intel_crtc *crtc, bool state)
+{
+ struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
+ enum pipe pipe = crtc->pipe;
+
+ /* Wait for the display line to settle/start moving */
+ if (wait_for(pipe_scanline_is_moving(dev_priv, pipe) == state, 100))
+ DRM_ERROR("pipe %c scanline %s wait timed out\n",
+ pipe_name(pipe), onoff(state));
+}
+
+static void intel_wait_for_pipe_scanline_stopped(struct intel_crtc *crtc)
+{
+ wait_for_pipe_scanline_moving(crtc, false);
+}
+
+static void intel_wait_for_pipe_scanline_moving(struct intel_crtc *crtc)
+{
+ wait_for_pipe_scanline_moving(crtc, true);
}
/*
@@ -1036,7 +1058,6 @@ static void intel_wait_for_pipe_off(struct intel_crtc *crtc)
{
struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
enum transcoder cpu_transcoder = crtc->config->cpu_transcoder;
- enum pipe pipe = crtc->pipe;
if (INTEL_GEN(dev_priv) >= 4) {
i915_reg_t reg = PIPECONF(cpu_transcoder);
@@ -1047,9 +1068,7 @@ static void intel_wait_for_pipe_off(struct intel_crtc *crtc)
100))
WARN(1, "pipe_off wait timed out\n");
} else {
- /* Wait for the display line to settle */
- if (wait_for(pipe_dsl_stopped(dev_priv, pipe), 100))
- WARN(1, "pipe_off wait timed out\n");
+ intel_wait_for_pipe_scanline_stopped(crtc);
}
}
@@ -1862,15 +1881,14 @@ static void intel_enable_pipe(struct intel_crtc *crtc)
POSTING_READ(reg);
/*
- * Until the pipe starts DSL will read as 0, which would cause
- * an apparent vblank timestamp jump, which messes up also the
- * frame count when it's derived from the timestamps. So let's
- * wait for the pipe to start properly before we call
- * drm_crtc_vblank_on()
+ * Until the pipe starts PIPEDSL reads will return a stale value,
+ * which causes an apparent vblank timestamp jump when PIPEDSL
+ * resets to its proper value. That also messes up the frame count
+ * when it's derived from the timestamps. So let's wait for the
+ * pipe to start properly before we call drm_crtc_vblank_on()
*/
- if (dev->max_vblank_count == 0 &&
- wait_for(intel_get_crtc_scanline(crtc) != crtc->scanline_offset, 50))
- DRM_ERROR("pipe %c didn't start\n", pipe_name(pipe));
+ if (dev->max_vblank_count == 0)
+ intel_wait_for_pipe_scanline_moving(crtc);
}
/**
@@ -14728,6 +14746,8 @@ void i830_enable_pipe(struct drm_i915_private *dev_priv, enum pipe pipe)
void i830_disable_pipe(struct drm_i915_private *dev_priv, enum pipe pipe)
{
+ struct intel_crtc *crtc = intel_get_crtc_for_pipe(dev_priv, pipe);
+
DRM_DEBUG_KMS("disabling pipe %c due to force quirk\n",
pipe_name(pipe));
@@ -14737,8 +14757,7 @@ void i830_disable_pipe(struct drm_i915_private *dev_priv, enum pipe pipe)
I915_WRITE(PIPECONF(pipe), 0);
POSTING_READ(PIPECONF(pipe));
- if (wait_for(pipe_dsl_stopped(dev_priv, pipe), 100))
- DRM_ERROR("pipe %c off wait timed out\n", pipe_name(pipe));
+ intel_wait_for_pipe_scanline_stopped(crtc);
I915_WRITE(DPLL(pipe), DPLL_VGA_MODE_DIS);
POSTING_READ(DPLL(pipe));
--
2.13.6
On Wed, Nov 29, 2017 at 10:07:02AM +0000, Mark Brown wrote:
> On Wed, Nov 29, 2017 at 09:07:45AM +0100, Greg Kroah-Hartman wrote:
> > On Tue, Nov 28, 2017 at 11:07:01PM +0530, Naresh Kamboju wrote:
>
> > > Results from Linaro’s test farm.
> > > No regressions on arm64, arm and x86_64.
>
> > Thanks for testing.
>
> > What is up with the odd email subject prefix?
>
> There's another internal list for looking at LKFT been set up and
> they've set it up as a mailman list adding subject prefixes :(
That's a pretty horrid thing to spam the public with :(
I'm going to drop the linaro.org address from my -rc announcements now
until someone learns how to properly sort their mailing lists by mail
headers, and not email subjects...
greg k-h
Some drivers like i915 start with crtc's enabled, but with deferred
fbcon setup they were no longer disabled as part of fbdev setup.
Headless units could no longer enter pc3 state because the crtc was
still enabled.
Fix this by calling restore_fbdev_mode when we would have called
it otherwise once during initial fbdev setup.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst(a)linux.intel.com>
Fixes: ca91a2758fce ("drm/fb-helper: Support deferred setup")
Cc: <stable(a)vger.kernel.org> # v4.14+
Reported-by: Thomas Voegtle <tv(a)lio96.de>
---
drivers/gpu/drm/drm_fb_helper.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 07374008f146..e56166334455 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -1809,6 +1809,10 @@ static int drm_fb_helper_single_fb_probe(struct drm_fb_helper *fb_helper,
if (crtc_count == 0 || sizes.fb_width == -1 || sizes.fb_height == -1) {
DRM_INFO("Cannot find any crtc or sizes\n");
+
+ /* First time: disable all crtc's.. */
+ if (!fb_helper->deferred_setup && !READ_ONCE(fb_helper->dev->master))
+ restore_fbdev_mode(fb_helper);
return -EAGAIN;
}
--
2.15.0
From: Daniel Jurgens <danielj(a)mellanox.com>
For now the only LSM security enforcement mechanism available is
specific to InfiniBand. Bypass enforcement for non-IB link types.
This fixes a regression where modify_qp fails for iWARP because
querying the PKEY returns -EINVAL.
Cc: Paul Moore <paul(a)paul-moore.com>
Cc: Don Dutile <ddutile(a)redhat.com>
Cc: stable(a)vger.kernel.org
Reported-by: Potnuri Bharat Teja <bharat(a)chelsio.com>
Fixes: d291f1a65232("IB/core: Enforce PKey security on QPs")
Fixes: 47a2b338fe63("IB/core: Enforce security on management datagrams")
Signed-off-by: Daniel Jurgens <danielj(a)mellanox.com>
Reviewed-by: Parav Pandit <parav(a)mellanox.com>
Tested-by: Potnuri Bharat Teja <bharat(a)chelsio.com>
Signed-off-by: Leon Romanovsky <leon(a)kernel.org>
---
Changelog:
v2->v3: Fix build warning
v1->v2: Fixed build errors
v0->v1: Added proper SElinux patch
---
drivers/infiniband/core/security.c | 47 +++++++++++++++++++++++++++++++++++---
1 file changed, 44 insertions(+), 3 deletions(-)
diff --git a/drivers/infiniband/core/security.c b/drivers/infiniband/core/security.c
index 209d057..5bc323f 100644
--- a/drivers/infiniband/core/security.c
+++ b/drivers/infiniband/core/security.c
@@ -417,8 +417,17 @@ void ib_close_shared_qp_security(struct ib_qp_security *sec)
int ib_create_qp_security(struct ib_qp *qp, struct ib_device *dev)
{
+ u8 i = rdma_start_port(dev);
+ bool is_ib = false;
int ret;
+ while (i <= rdma_end_port(dev) && !is_ib)
+ is_ib = rdma_protocol_ib(dev, i++);
+
+ /* If this isn't an IB device don't create the security context */
+ if (!is_ib)
+ return 0;
+
qp->qp_sec = kzalloc(sizeof(*qp->qp_sec), GFP_KERNEL);
if (!qp->qp_sec)
return -ENOMEM;
@@ -441,6 +450,10 @@ int ib_create_qp_security(struct ib_qp *qp, struct ib_device *dev)
void ib_destroy_qp_security_begin(struct ib_qp_security *sec)
{
+ /* Return if not IB */
+ if (!sec)
+ return;
+
mutex_lock(&sec->mutex);
/* Remove the QP from the lists so it won't get added to
@@ -470,6 +483,10 @@ void ib_destroy_qp_security_abort(struct ib_qp_security *sec)
int ret;
int i;
+ /* Return if not IB */
+ if (!sec)
+ return;
+
/* If a concurrent cache update is in progress this
* QP security could be marked for an error state
* transition. Wait for this to complete.
@@ -505,6 +522,10 @@ void ib_destroy_qp_security_end(struct ib_qp_security *sec)
{
int i;
+ /* Return if not IB */
+ if (!sec)
+ return;
+
/* If a concurrent cache update is occurring we must
* wait until this QP security structure is processed
* in the QP to error flow before destroying it because
@@ -557,7 +578,7 @@ int ib_security_modify_qp(struct ib_qp *qp,
{
int ret = 0;
struct ib_ports_pkeys *tmp_pps;
- struct ib_ports_pkeys *new_pps;
+ struct ib_ports_pkeys *new_pps = NULL;
struct ib_qp *real_qp = qp->real_qp;
bool special_qp = (real_qp->qp_type == IB_QPT_SMI ||
real_qp->qp_type == IB_QPT_GSI ||
@@ -565,17 +586,25 @@ int ib_security_modify_qp(struct ib_qp *qp,
bool pps_change = ((qp_attr_mask & (IB_QP_PKEY_INDEX | IB_QP_PORT)) ||
(qp_attr_mask & IB_QP_ALT_PATH));
+ WARN_ONCE((qp_attr_mask & IB_QP_PORT &&
+ rdma_protocol_ib(real_qp->device, qp_attr->port_num) &&
+ !real_qp->qp_sec),
+ "%s: QP security is not initialized for IB QP: %d\n",
+ __func__, real_qp->qp_num);
+
/* The port/pkey settings are maintained only for the real QP. Open
* handles on the real QP will be in the shared_qp_list. When
* enforcing security on the real QP all the shared QPs will be
* checked as well.
*/
- if (pps_change && !special_qp) {
+ if (pps_change && !special_qp && real_qp->qp_sec) {
mutex_lock(&real_qp->qp_sec->mutex);
new_pps = get_new_pps(real_qp,
qp_attr,
qp_attr_mask);
+ if (!new_pps)
+ return -ENOMEM;
/* Add this QP to the lists for the new port
* and pkey settings before checking for permission
@@ -600,7 +629,7 @@ int ib_security_modify_qp(struct ib_qp *qp,
qp_attr_mask,
udata);
- if (pps_change && !special_qp) {
+ if (new_pps) {
/* Clean up the lists and free the appropriate
* ports_pkeys structure.
*/
@@ -630,6 +659,9 @@ static int ib_security_pkey_access(struct ib_device *dev,
u16 pkey;
int ret;
+ if (!rdma_protocol_ib(dev, port_num))
+ return 0;
+
ret = ib_get_cached_pkey(dev, port_num, pkey_index, &pkey);
if (ret)
return ret;
@@ -663,6 +695,9 @@ int ib_mad_agent_security_setup(struct ib_mad_agent *agent,
{
int ret;
+ if (!rdma_protocol_ib(agent->device, agent->port_num))
+ return 0;
+
ret = security_ib_alloc_security(&agent->security);
if (ret)
return ret;
@@ -688,6 +723,9 @@ int ib_mad_agent_security_setup(struct ib_mad_agent *agent,
void ib_mad_agent_security_cleanup(struct ib_mad_agent *agent)
{
+ if (!rdma_protocol_ib(agent->device, agent->port_num))
+ return;
+
security_ib_free_security(agent->security);
if (agent->lsm_nb_reg)
unregister_lsm_notifier(&agent->lsm_nb);
@@ -695,6 +733,9 @@ void ib_mad_agent_security_cleanup(struct ib_mad_agent *agent)
int ib_mad_enforce_security(struct ib_mad_agent_private *map, u16 pkey_index)
{
+ if (!rdma_protocol_ib(map->agent.device, map->agent.port_num))
+ return 0;
+
if (map->agent.qp->qp_type == IB_QPT_SMI && !map->agent.smp_allowed)
return -EACCES;
--
1.8.3.1
The direction_output callback of the gpio_chip structure is supposed to
set the output direction but also to set the value of the gpio. For the
armada-37xx driver this callback acted as the gpio_set_direction callback
for the pinctrl.
This patch fixes the behavior of the direction_output callback by also
applying the value received as parameter.
Cc: stable(a)vger.kernel.org
Fixes: 5715092a458c ("pinctrl: armada-37xx: Add gpio support")
Reported-by: Alexandre Belloni <alexandre.belloni(a)free-electrons.com>
Signed-off-by: Gregory CLEMENT <gregory.clement(a)free-electrons.com>
---
drivers/pinctrl/mvebu/pinctrl-armada-37xx.c | 13 +++++++++++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/drivers/pinctrl/mvebu/pinctrl-armada-37xx.c b/drivers/pinctrl/mvebu/pinctrl-armada-37xx.c
index 71b944748304..c5fe7d4a9065 100644
--- a/drivers/pinctrl/mvebu/pinctrl-armada-37xx.c
+++ b/drivers/pinctrl/mvebu/pinctrl-armada-37xx.c
@@ -408,12 +408,21 @@ static int armada_37xx_gpio_direction_output(struct gpio_chip *chip,
{
struct armada_37xx_pinctrl *info = gpiochip_get_data(chip);
unsigned int reg = OUTPUT_EN;
- unsigned int mask;
+ unsigned int mask, val, ret;
armada_37xx_update_reg(®, offset);
mask = BIT(offset);
- return regmap_update_bits(info->regmap, reg, mask, mask);
+ ret = regmap_update_bits(info->regmap, reg, mask, mask);
+
+ if (ret)
+ return ret;
+
+ reg = OUTPUT_VAL;
+ val = value ? mask : 0;
+ regmap_update_bits(info->regmap, reg, mask, val);
+
+ return 0;
}
static int armada_37xx_gpio_get(struct gpio_chip *chip, unsigned int offset)
--
2.14.2
Fix child-node lookup during probe, which ended up searching the whole
device tree depth-first starting at the parent rather than just matching
on its children.
This would only cause trouble if the child node is missing while there
is an unrelated node named "backlight" elsewhere in the tree.
Fixes: eebfdc17cc6c ("backlight: Add TPS65217 WLED driver")
Cc: stable <stable(a)vger.kernel.org> # 3.7
Cc: Matthias Kaehlcke <matthias(a)kaehlcke.net>
Signed-off-by: Johan Hovold <johan(a)kernel.org>
---
drivers/video/backlight/tps65217_bl.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/video/backlight/tps65217_bl.c b/drivers/video/backlight/tps65217_bl.c
index 380917c86276..762e3feed097 100644
--- a/drivers/video/backlight/tps65217_bl.c
+++ b/drivers/video/backlight/tps65217_bl.c
@@ -184,11 +184,11 @@ static struct tps65217_bl_pdata *
tps65217_bl_parse_dt(struct platform_device *pdev)
{
struct tps65217 *tps = dev_get_drvdata(pdev->dev.parent);
- struct device_node *node = of_node_get(tps->dev->of_node);
+ struct device_node *node;
struct tps65217_bl_pdata *pdata, *err;
u32 val;
- node = of_find_node_by_name(node, "backlight");
+ node = of_get_child_by_name(tps->dev->of_node, "backlight");
if (!node)
return ERR_PTR(-ENODEV);
--
2.15.0
A helper purported to look up a child node based on its name was using
the wrong of-helper and ended up prematurely freeing the parent of-node
while leaking any matching node.
To make things worse, any matching node would not even necessarily be a
child node as the whole device tree was searched depth-first starting at
the parent.
Fixes: 019a7e6b7b31 ("mfd: twl4030-audio: Add DT support")
Cc: stable <stable(a)vger.kernel.org> # 3.7
Cc: Peter Ujfalusi <peter.ujfalusi(a)ti.com>
---
drivers/mfd/twl4030-audio.c | 9 +++++++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/mfd/twl4030-audio.c b/drivers/mfd/twl4030-audio.c
index da16bf45fab4..dc94ffc6321a 100644
--- a/drivers/mfd/twl4030-audio.c
+++ b/drivers/mfd/twl4030-audio.c
@@ -159,13 +159,18 @@ unsigned int twl4030_audio_get_mclk(void)
EXPORT_SYMBOL_GPL(twl4030_audio_get_mclk);
static bool twl4030_audio_has_codec(struct twl4030_audio_data *pdata,
- struct device_node *node)
+ struct device_node *parent)
{
+ struct device_node *node;
+
if (pdata && pdata->codec)
return true;
- if (of_find_node_by_name(node, "codec"))
+ node = of_get_child_by_name(parent, "codec");
+ if (node) {
+ of_node_put(node);
return true;
+ }
return false;
}
--
2.15.0
On the Tegra124 Nyan-Big chromebook the very first SPI message sent to
the EC is failing.
The Tegra SPI driver configures the SPI chip-selects to be active-high
by default (and always has for many years). The EC SPI requires an
active-low chip-select and so the Tegra chip-select is reconfigured to
be active-low when the EC SPI driver calls spi_setup(). The problem is
that if the first SPI message to the EC is sent too soon after
reconfiguring the SPI chip-select, it fails.
The EC SPI driver prevents back-to-back SPI messages being sent too
soon by keeping track of the time the last transfer was sent via the
variable 'last_transfer_ns'. To prevent the very first transfer being
sent too soon, initialise the 'last_transfer_ns' variable after calling
spi_setup() and before sending the first SPI message.
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Jon Hunter <jonathanh(a)nvidia.com>
Reviewed-by: Brian Norris <briannorris(a)chromium.org>
---
Changes since V1:
- Added stable-tag and Brian's reviewed-by.
Looks like this issue has been around for several Linux releases now
and it just depends on timing if this issue is seen or not and so there
is no specific commit this fixes. However, would be good to include for
v4.15.
drivers/mfd/cros_ec_spi.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/mfd/cros_ec_spi.c b/drivers/mfd/cros_ec_spi.c
index c9714072e224..a14196e95e9b 100644
--- a/drivers/mfd/cros_ec_spi.c
+++ b/drivers/mfd/cros_ec_spi.c
@@ -667,6 +667,7 @@ static int cros_ec_spi_probe(struct spi_device *spi)
sizeof(struct ec_response_get_protocol_info);
ec_dev->dout_size = sizeof(struct ec_host_request);
+ ec_spi->last_transfer_ns = ktime_get_ns();
err = cros_ec_register(ec_dev);
if (err) {
--
2.7.4
The commit d6810d730022 ("memcg, THP, swap: make mem_cgroup_swapout()
support THP") changed mem_cgroup_swapout() to support transparent huge
page (THP). However the patch missed one location which should be
changed for correctly handling THPs. The resulting bug will cause the
memory cgroups whose THPs were swapped out to become zombies on
deletion.
Fixes: d6810d730022 ("memcg, THP, swap: make mem_cgroup_swapout() support THP")
Signed-off-by: Shakeel Butt <shakeelb(a)google.com>
Cc: stable(a)vger.kernel.org
---
mm/memcontrol.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/mm/memcontrol.c b/mm/memcontrol.c
index 50e6906314f8..ac2ffd5e02b9 100644
--- a/mm/memcontrol.c
+++ b/mm/memcontrol.c
@@ -6044,7 +6044,7 @@ void mem_cgroup_swapout(struct page *page, swp_entry_t entry)
memcg_check_events(memcg, page);
if (!mem_cgroup_is_root(memcg))
- css_put(&memcg->css);
+ css_put_many(&memcg->css, nr_entries);
}
/**
--
2.15.0.417.g466bffb3ac-goog
This is the start of the stable review cycle for the 3.18.85 release.
There are 67 patches in this series, all will be posted as a response
to this one. If anyone has any issues with these being applied, please
let me know.
Responses should be made by Thu Nov 30 10:03:41 UTC 2017.
Anything received after that time might be too late.
The whole patch series can be found in one patch at:
kernel.org/pub/linux/kernel/v3.x/stable-review/patch-3.18.85-rc1.gz
or in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-3.18.y
and the diffstat can be found below.
thanks,
greg k-h
-------------
Pseudo-Shortlog of commits:
Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Linux 3.18.85-rc1
Juergen Gross <jgross(a)suse.com>
xen: xenbus driver must not accept invalid transaction ids
Heiko Carstens <heiko.carstens(a)de.ibm.com>
s390/kbuild: enable modversions for symbols exported from asm
Richard Fitzgerald <rf(a)opensource.wolfsonmicro.com>
ASoC: wm_adsp: Don't overrun firmware file buffer when reading region data
Pan Bian <bianpan2016(a)163.com>
btrfs: return the actual error value from from btrfs_uuid_tree_iterate
Florian Westphal <fw(a)strlen.de>
netfilter: nf_tables: fix oob access
Pablo Neira Ayuso <pablo(a)netfilter.org>
netfilter: nft_queue: use raw_smp_processor_id()
Pan Bian <bianpan2016(a)163.com>
staging: iio: cdc: fix improper return value
Masashi Honma <masashi.honma(a)gmail.com>
mac80211: Suppress NEW_PEER_CANDIDATE event if no room
Masashi Honma <masashi.honma(a)gmail.com>
mac80211: Remove invalid flag operations in mesh TSF synchronization
Gabriele Mazzotta <gabriele.mzt(a)gmail.com>
ALSA: hda - Apply ALC269_FIXUP_NO_SHUTUP on HDA_FIXUP_ACT_PROBE
Daniel Vetter <daniel.vetter(a)ffwll.ch>
drm/armada: Fix compile fail
Thomas Preisner <thomas.preisner+linux(a)fau.de>
net: 3com: typhoon: typhoon_init_one: fix incorrect return values
Thomas Preisner <thomas.preisner+linux(a)fau.de>
net: 3com: typhoon: typhoon_init_one: make return values more specific
Bjorn Helgaas <bhelgaas(a)google.com>
PCI: Apply _HPX settings only to relevant devices
Santosh Shilimkar <santosh.shilimkar(a)oracle.com>
RDS: RDMA: return appropriate error on rdma map failures
Benjamin Poirier <bpoirier(a)suse.com>
e1000e: Separate signaling for link check/link up
Benjamin Poirier <bpoirier(a)suse.com>
e1000e: Fix return value test
Benjamin Poirier <bpoirier(a)suse.com>
e1000e: Fix error path in link detection
Ben Hutchings <ben.hutchings(a)codethink.co.uk>
iio: iio-trig-periodic-rtc: Free trigger resource correctly
Oliver Neukum <oneukum(a)suse.com>
USB: fix buffer overflows with parsing CDC headers
Brent Taylor <motobud(a)gmail.com>
mtd: nand: Fix writing mtdoops to nand flash.
Tuomas Tynkkynen <tuomas(a)tuxera.com>
net/9p: Switch to wait_event_killable()
Ricardo Ribalda Delgado <ricardo.ribalda(a)gmail.com>
media: v4l2-ctrl: Fix flags field on Control events
Sean Young <sean(a)mess.org>
media: rc: check for integer overflow
Michele Baldessari <michele(a)acksyn.org>
media: Don't do DMA on stack for firmware upload in the AS102 driver
Naveen N. Rao <naveen.n.rao(a)linux.vnet.ibm.com>
powerpc/signal: Properly handle return value from uprobe_deny_signal()
John David Anglin <dave.anglin(a)bell.net>
parisc: Fix validity check of pointer size argument in new CAS implementation
Brian King <brking(a)linux.vnet.ibm.com>
ixgbe: Fix skb list corruption on Power systems
Brian King <brking(a)linux.vnet.ibm.com>
fm10k: Use smp_rmb rather than read_barrier_depends
Brian King <brking(a)linux.vnet.ibm.com>
i40evf: Use smp_rmb rather than read_barrier_depends
Brian King <brking(a)linux.vnet.ibm.com>
ixgbevf: Use smp_rmb rather than read_barrier_depends
Brian King <brking(a)linux.vnet.ibm.com>
igbvf: Use smp_rmb rather than read_barrier_depends
Brian King <brking(a)linux.vnet.ibm.com>
igb: Use smp_rmb rather than read_barrier_depends
Brian King <brking(a)linux.vnet.ibm.com>
i40e: Use smp_rmb rather than read_barrier_depends
Wang YanQing <udknight(a)gmail.com>
time: Always make sure wall_to_monotonic isn't positive
Johan Hovold <johan(a)kernel.org>
NFC: fix device-allocation error return
Bart Van Assche <bart.vanassche(a)wdc.com>
IB/srpt: Do not accept invalid initiator port names
Johan Hovold <johan(a)kernel.org>
clk: ti: dra7-atl-clock: fix child-node lookups
Peter Ujfalusi <peter.ujfalusi(a)ti.com>
clk: ti: dra7-atl-clock: Fix of_node reference counting
Paolo Bonzini <pbonzini(a)redhat.com>
KVM: SVM: obey guest PAT
Ladi Prosek <lprosek(a)redhat.com>
KVM: nVMX: set IDTR and GDTR limits when loading L1 host state
Nicholas Bellinger <nab(a)linux-iscsi.org>
iscsi-target: Fix non-immediate TMR reference leak
Tuomas Tynkkynen <tuomas(a)tuxera.com>
fs/9p: Compare qid.path in v9fs_test_inode
Takashi Iwai <tiwai(a)suse.de>
ALSA: timer: Remove kernel warning at compat ioctl error paths
Takashi Iwai <tiwai(a)suse.de>
ALSA: usb-audio: Add sanity checks in v2 clock parsers
Takashi Iwai <tiwai(a)suse.de>
ALSA: usb-audio: Fix potential out-of-bound access at parsing SU
Takashi Iwai <tiwai(a)suse.de>
ALSA: usb-audio: Add sanity checks to FE parser
Theodore Ts'o <tytso(a)mit.edu>
ext4: fix interaction between i_size, fallocate, and delalloc after a crash
Andrew Elble <aweits(a)rit.edu>
nfsd: deal with revoked delegations appropriately
Chuck Lever <chuck.lever(a)oracle.com>
nfs: Fix ugly referral attributes
Joshua Watt <jpewhacker(a)gmail.com>
NFS: Fix typo in nomigration mount option
Arnd Bergmann <arnd(a)arndb.de>
isofs: fix timestamps beyond 2027
Coly Li <colyli(a)suse.de>
bcache: check ca->alloc_thread initialized before wake up it
Dan Carpenter <dan.carpenter(a)oracle.com>
eCryptfs: use after free in ecryptfs_release_messaging()
Andreas Rohner <andreas.rohner(a)gmx.net>
nilfs2: fix race condition that causes file system corruption
NeilBrown <neilb(a)suse.com>
autofs: don't fail mount for transient error
Mirko Parthey <mirko.parthey(a)web.de>
MIPS: BCM47XX: Fix LED inversion for WRT54GSv1
Maciej W. Rozycki <macro(a)mips.com>
MIPS: Fix an n32 core file generation regset support regression
Hou Tao <houtao1(a)huawei.com>
dm: fix race between dm_get_from_kobject() and __dm_destroy()
Eric Biggers <ebiggers(a)google.com>
dm bufio: fix integer overflow when limiting maximum cache size
Vijendar Mukunda <Vijendar.Mukunda(a)amd.com>
ALSA: hda: Add Raven PCI ID
Philip Derrin <philip(a)cog.systems>
ARM: 8721/1: mm: dump: check hardware RO bit for LPAE
Masami Hiramatsu <mhiramat(a)kernel.org>
x86/decoder: Add new TEST instruction pattern
Eric Biggers <ebiggers(a)google.com>
lib/mpi: call cond_resched() from mpi_powm() loop
Paul E. McKenney <paulmck(a)linux.vnet.ibm.com>
sched: Make resched_cpu() unconditional
WANG Cong <xiyou.wangcong(a)gmail.com>
ipv6: only call ip6_route_dev_notify() once for NETDEV_UNREGISTER
Vasily Gorbik <gor(a)linux.vnet.ibm.com>
s390/disassembler: increase show_code buffer size
-------------
Diffstat:
Makefile | 4 ++--
arch/arm/mm/dump.c | 4 ++--
arch/mips/bcm47xx/leds.c | 2 +-
arch/mips/kernel/ptrace.c | 17 +++++++++++++
arch/parisc/kernel/syscall.S | 6 ++---
arch/powerpc/kernel/signal.c | 2 +-
arch/s390/include/asm/asm-prototypes.h | 8 +++++++
arch/s390/kernel/dis.c | 4 ++--
arch/x86/kvm/svm.c | 7 ++++++
arch/x86/kvm/vmx.c | 2 ++
arch/x86/lib/x86-opcode-map.txt | 2 +-
drivers/clk/ti/clk-dra7-atl.c | 3 ++-
drivers/gpu/drm/armada/Makefile | 2 ++
drivers/infiniband/ulp/srpt/ib_srpt.c | 9 ++++---
drivers/md/bcache/alloc.c | 3 ++-
drivers/md/dm-bufio.c | 15 +++++-------
drivers/md/dm.c | 12 ++++++----
drivers/media/rc/ir-lirc-codec.c | 9 ++++---
drivers/media/usb/as102/as102_fw.c | 28 +++++++++++++---------
drivers/media/v4l2-core/v4l2-ctrls.c | 16 +++++++++----
drivers/mtd/nand/nand_base.c | 9 ++++---
drivers/net/ethernet/3com/typhoon.c | 25 ++++++++++---------
drivers/net/ethernet/intel/e1000e/mac.c | 11 ++++++---
drivers/net/ethernet/intel/e1000e/netdev.c | 4 ++--
drivers/net/ethernet/intel/e1000e/phy.c | 7 +++---
drivers/net/ethernet/intel/fm10k/fm10k_main.c | 2 +-
drivers/net/ethernet/intel/i40e/i40e_main.c | 2 +-
drivers/net/ethernet/intel/i40e/i40e_txrx.c | 2 +-
drivers/net/ethernet/intel/i40evf/i40e_txrx.c | 2 +-
drivers/net/ethernet/intel/igb/igb_main.c | 2 +-
drivers/net/ethernet/intel/igbvf/netdev.c | 2 +-
drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 2 +-
drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c | 2 +-
drivers/net/usb/cdc_ether.c | 9 ++++++-
drivers/pci/probe.c | 15 ++++++++++--
drivers/staging/iio/cdc/ad7150.c | 2 +-
.../staging/iio/trigger/iio-trig-periodic-rtc.c | 6 ++---
drivers/target/iscsi/iscsi_target.c | 8 ++++---
drivers/usb/class/cdc-acm.c | 2 +-
drivers/usb/class/cdc-wdm.c | 2 ++
drivers/xen/xenbus/xenbus_dev_frontend.c | 2 +-
fs/9p/vfs_inode.c | 3 +++
fs/9p/vfs_inode_dotl.c | 3 +++
fs/autofs4/waitq.c | 15 +++++++++++-
fs/btrfs/uuid-tree.c | 4 +---
fs/ecryptfs/messaging.c | 7 +++---
fs/ext4/extents.c | 6 +++--
fs/isofs/isofs.h | 2 +-
fs/isofs/rock.h | 2 +-
fs/isofs/util.c | 2 +-
fs/nfs/nfs4proc.c | 18 +++++++-------
fs/nfs/super.c | 2 +-
fs/nfsd/nfs4state.c | 25 ++++++++++++++++++-
fs/nilfs2/segment.c | 6 +++--
kernel/sched/core.c | 3 +--
kernel/time/timekeeping.c | 13 +++++++---
lib/mpi/mpi-pow.c | 2 ++
net/9p/client.c | 3 +--
net/9p/trans_virtio.c | 13 +++++-----
net/ipv6/route.c | 6 ++++-
net/mac80211/ieee80211_i.h | 1 -
net/mac80211/mesh.c | 3 ---
net/mac80211/mesh_plink.c | 14 ++++++-----
net/mac80211/mesh_sync.c | 11 ---------
net/netfilter/nf_tables_api.c | 2 +-
net/netfilter/nft_queue.c | 2 +-
net/nfc/core.c | 2 +-
net/rds/send.c | 11 ++++++++-
sound/core/timer_compat.c | 12 +++++-----
sound/pci/hda/hda_intel.c | 3 +++
sound/pci/hda/patch_realtek.c | 2 +-
sound/soc/codecs/wm_adsp.c | 25 ++++++++++++++++++-
sound/usb/clock.c | 9 ++++---
sound/usb/mixer.c | 15 +++++++++++-
74 files changed, 350 insertions(+), 170 deletions(-)
If the call __alloc_contig_migrate_range() in alloc_contig_range
returns -EBUSY, processing continues so that test_pages_isolated()
is called where there is a tracepoint to identify the busy pages.
However, it is possible for busy pages to become available between
the calls to these two routines. In this case, the range of pages
may be allocated. Unfortunately, the original return code (ret
== -EBUSY) is still set and returned to the caller. Therefore,
the caller believes the pages were not allocated and they are leaked.
Update the return code with the value from test_pages_isolated().
Fixes: 8ef5849fa8a2 ("mm/cma: always check which page caused allocation failure")
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Mike Kravetz <mike.kravetz(a)oracle.com>
---
mm/page_alloc.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 77e4d3c5c57b..3605ca82fd29 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -7632,10 +7632,10 @@ int alloc_contig_range(unsigned long start, unsigned long end,
}
/* Make sure the range is really isolated. */
- if (test_pages_isolated(outer_start, end, false)) {
+ ret = test_pages_isolated(outer_start, end, false);
+ if (ret) {
pr_info_ratelimited("%s: [%lx, %lx) PFNs busy\n",
__func__, outer_start, end);
- ret = -EBUSY;
goto done;
}
--
2.13.6
From: Eric Biggers <ebiggers(a)google.com>
When asked to encrypt or decrypt 0 bytes, both the generic and x86
implementations of Salsa20 crash in blkcipher_walk_done(), either when
doing 'kfree(walk->buffer)' or 'free_page((unsigned long)walk->page)',
because walk->buffer and walk->page have not been initialized.
The bug is that Salsa20 is calling blkcipher_walk_done() even when
nothing is in 'walk.nbytes'. But blkcipher_walk_done() is only meant to
be called when a nonzero number of bytes have been provided.
The broken code is part of an optimization that tries to make only one
call to salsa20_encrypt_bytes() to process inputs that are not evenly
divisible by 64 bytes. To fix the bug, just remove this "optimization"
and use the blkcipher_walk API the same way all the other users do.
Reproducer:
#include <linux/if_alg.h>
#include <sys/socket.h>
#include <unistd.h>
int main()
{
int algfd, reqfd;
struct sockaddr_alg addr = {
.salg_type = "skcipher",
.salg_name = "salsa20",
};
char key[16] = { 0 };
algfd = socket(AF_ALG, SOCK_SEQPACKET, 0);
bind(algfd, (void *)&addr, sizeof(addr));
reqfd = accept(algfd, 0, 0);
setsockopt(algfd, SOL_ALG, ALG_SET_KEY, key, sizeof(key));
read(reqfd, key, sizeof(key));
}
Reported-by: syzbot <syzkaller(a)googlegroups.com>
Fixes: eb6f13eb9f81 ("[CRYPTO] salsa20_generic: Fix multi-page processing")
Cc: <stable(a)vger.kernel.org> # v2.6.25+
Signed-off-by: Eric Biggers <ebiggers(a)google.com>
---
arch/x86/crypto/salsa20_glue.c | 7 -------
crypto/salsa20_generic.c | 7 -------
2 files changed, 14 deletions(-)
diff --git a/arch/x86/crypto/salsa20_glue.c b/arch/x86/crypto/salsa20_glue.c
index 399a29d067d6..cb91a64a99e7 100644
--- a/arch/x86/crypto/salsa20_glue.c
+++ b/arch/x86/crypto/salsa20_glue.c
@@ -59,13 +59,6 @@ static int encrypt(struct blkcipher_desc *desc,
salsa20_ivsetup(ctx, walk.iv);
- if (likely(walk.nbytes == nbytes))
- {
- salsa20_encrypt_bytes(ctx, walk.src.virt.addr,
- walk.dst.virt.addr, nbytes);
- return blkcipher_walk_done(desc, &walk, 0);
- }
-
while (walk.nbytes >= 64) {
salsa20_encrypt_bytes(ctx, walk.src.virt.addr,
walk.dst.virt.addr,
diff --git a/crypto/salsa20_generic.c b/crypto/salsa20_generic.c
index f550b5d94630..d7da0eea5622 100644
--- a/crypto/salsa20_generic.c
+++ b/crypto/salsa20_generic.c
@@ -188,13 +188,6 @@ static int encrypt(struct blkcipher_desc *desc,
salsa20_ivsetup(ctx, walk.iv);
- if (likely(walk.nbytes == nbytes))
- {
- salsa20_encrypt_bytes(ctx, walk.dst.virt.addr,
- walk.src.virt.addr, nbytes);
- return blkcipher_walk_done(desc, &walk, 0);
- }
-
while (walk.nbytes >= 64) {
salsa20_encrypt_bytes(ctx, walk.dst.virt.addr,
walk.src.virt.addr,
--
2.15.0
From: Eric Biggers <ebiggers(a)google.com>
Because the HMAC template didn't check that its underlying hash
algorithm is unkeyed, trying to use "hmac(hmac(sha3-512-generic))"
through AF_ALG or through KEYCTL_DH_COMPUTE resulted in the inner HMAC
being used without having been keyed, resulting in sha3_update() being
called without sha3_init(), causing a stack buffer overflow.
This is a very old bug, but it seems to have only started causing real
problems when SHA-3 support was added (requires CONFIG_CRYPTO_SHA3)
because the innermost hash's state is ->import()ed from a zeroed buffer,
and it just so happens that other hash algorithms are fine with that,
but SHA-3 is not. However, there could be arch or hardware-dependent
hash algorithms also affected; I couldn't test everything.
Fix the bug by introducing a function crypto_shash_alg_has_setkey()
which tests whether a shash algorithm is keyed. Then update the HMAC
template to require that its underlying hash algorithm is unkeyed.
Here is a reproducer:
#include <linux/if_alg.h>
#include <sys/socket.h>
int main()
{
int algfd;
struct sockaddr_alg addr = {
.salg_type = "hash",
.salg_name = "hmac(hmac(sha3-512-generic))",
};
char key[4096] = { 0 };
algfd = socket(AF_ALG, SOCK_SEQPACKET, 0);
bind(algfd, (const struct sockaddr *)&addr, sizeof(addr));
setsockopt(algfd, SOL_ALG, ALG_SET_KEY, key, sizeof(key));
}
Here was the KASAN report from syzbot:
BUG: KASAN: stack-out-of-bounds in memcpy include/linux/string.h:341 [inline]
BUG: KASAN: stack-out-of-bounds in sha3_update+0xdf/0x2e0 crypto/sha3_generic.c:161
Write of size 4096 at addr ffff8801cca07c40 by task syzkaller076574/3044
CPU: 1 PID: 3044 Comm: syzkaller076574 Not tainted 4.14.0-mm1+ #25
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
Call Trace:
__dump_stack lib/dump_stack.c:17 [inline]
dump_stack+0x194/0x257 lib/dump_stack.c:53
print_address_description+0x73/0x250 mm/kasan/report.c:252
kasan_report_error mm/kasan/report.c:351 [inline]
kasan_report+0x25b/0x340 mm/kasan/report.c:409
check_memory_region_inline mm/kasan/kasan.c:260 [inline]
check_memory_region+0x137/0x190 mm/kasan/kasan.c:267
memcpy+0x37/0x50 mm/kasan/kasan.c:303
memcpy include/linux/string.h:341 [inline]
sha3_update+0xdf/0x2e0 crypto/sha3_generic.c:161
crypto_shash_update+0xcb/0x220 crypto/shash.c:109
shash_finup_unaligned+0x2a/0x60 crypto/shash.c:151
crypto_shash_finup+0xc4/0x120 crypto/shash.c:165
hmac_finup+0x182/0x330 crypto/hmac.c:152
crypto_shash_finup+0xc4/0x120 crypto/shash.c:165
shash_digest_unaligned+0x9e/0xd0 crypto/shash.c:172
crypto_shash_digest+0xc4/0x120 crypto/shash.c:186
hmac_setkey+0x36a/0x690 crypto/hmac.c:66
crypto_shash_setkey+0xad/0x190 crypto/shash.c:64
shash_async_setkey+0x47/0x60 crypto/shash.c:207
crypto_ahash_setkey+0xaf/0x180 crypto/ahash.c:200
hash_setkey+0x40/0x90 crypto/algif_hash.c:446
alg_setkey crypto/af_alg.c:221 [inline]
alg_setsockopt+0x2a1/0x350 crypto/af_alg.c:254
SYSC_setsockopt net/socket.c:1851 [inline]
SyS_setsockopt+0x189/0x360 net/socket.c:1830
entry_SYSCALL_64_fastpath+0x1f/0x96
Reported-by: syzbot <syzkaller(a)googlegroups.com>
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Eric Biggers <ebiggers(a)google.com>
---
crypto/hmac.c | 6 +++++-
crypto/shash.c | 5 +++--
include/crypto/internal/hash.h | 8 ++++++++
3 files changed, 16 insertions(+), 3 deletions(-)
diff --git a/crypto/hmac.c b/crypto/hmac.c
index 92871dc2a63e..e74730224f0a 100644
--- a/crypto/hmac.c
+++ b/crypto/hmac.c
@@ -195,11 +195,15 @@ static int hmac_create(struct crypto_template *tmpl, struct rtattr **tb)
salg = shash_attr_alg(tb[1], 0, 0);
if (IS_ERR(salg))
return PTR_ERR(salg);
+ alg = &salg->base;
+ /* The underlying hash algorithm must be unkeyed */
err = -EINVAL;
+ if (crypto_shash_alg_has_setkey(salg))
+ goto out_put_alg;
+
ds = salg->digestsize;
ss = salg->statesize;
- alg = &salg->base;
if (ds > alg->cra_blocksize ||
ss < alg->cra_blocksize)
goto out_put_alg;
diff --git a/crypto/shash.c b/crypto/shash.c
index 325a14da5827..e849d3ee2e27 100644
--- a/crypto/shash.c
+++ b/crypto/shash.c
@@ -25,11 +25,12 @@
static const struct crypto_type crypto_shash_type;
-static int shash_no_setkey(struct crypto_shash *tfm, const u8 *key,
- unsigned int keylen)
+int shash_no_setkey(struct crypto_shash *tfm, const u8 *key,
+ unsigned int keylen)
{
return -ENOSYS;
}
+EXPORT_SYMBOL_GPL(shash_no_setkey);
static int shash_setkey_unaligned(struct crypto_shash *tfm, const u8 *key,
unsigned int keylen)
diff --git a/include/crypto/internal/hash.h b/include/crypto/internal/hash.h
index f0b44c16e88f..c2bae8da642c 100644
--- a/include/crypto/internal/hash.h
+++ b/include/crypto/internal/hash.h
@@ -82,6 +82,14 @@ int ahash_register_instance(struct crypto_template *tmpl,
struct ahash_instance *inst);
void ahash_free_instance(struct crypto_instance *inst);
+int shash_no_setkey(struct crypto_shash *tfm, const u8 *key,
+ unsigned int keylen);
+
+static inline bool crypto_shash_alg_has_setkey(struct shash_alg *alg)
+{
+ return alg->setkey != shash_no_setkey;
+}
+
int crypto_init_ahash_spawn(struct crypto_ahash_spawn *spawn,
struct hash_alg_common *alg,
struct crypto_instance *inst);
--
2.15.0
The patch titled
Subject: mm/cma: fix alloc_contig_range ret code/potential leak
has been added to the -mm tree. Its filename is
mm-cma-fix-alloc_contig_range-ret-code-potential-leak-v2.patch
This patch should soon appear at
http://ozlabs.org/~akpm/mmots/broken-out/mm-cma-fix-alloc_contig_range-ret-…
and later at
http://ozlabs.org/~akpm/mmotm/broken-out/mm-cma-fix-alloc_contig_range-ret-…
Before you just go and hit "reply", please:
a) Consider who else should be cc'ed
b) Prefer to cc a suitable mailing list as well
c) Ideally: find the original patch on the mailing list and do a
reply-to-all to that, adding suitable additional cc's
*** Remember to use Documentation/SubmitChecklist when testing your code ***
The -mm tree is included into linux-next and is updated
there every 3-4 working days
------------------------------------------------------
From: Mike Kravetz <mike.kravetz(a)oracle.com>
Subject: mm/cma: fix alloc_contig_range ret code/potential leak
If the call __alloc_contig_migrate_range() in alloc_contig_range returns
-EBUSY, processing continues so that test_pages_isolated() is called where
there is a tracepoint to identify the busy pages. However, it is possible
for busy pages to become available between the calls to these two
routines. In this case, the range of pages may be allocated.
Unfortunately, the original return code (ret == -EBUSY) is still set and
returned to the caller. Therefore, the caller believes the pages were not
allocated and they are leaked.
Update comment to indicate that allocation is still possible even if
__alloc_contig_migrate_range returns -EBUSY. Also, clear return code in
this case so that it is not accidentally used or returned to caller.
Link: http://lkml.kernel.org/r/20171122185214.25285-1-mike.kravetz@oracle.com
Fixes: 8ef5849fa8a2 ("mm/cma: always check which page caused allocation failure")
Signed-off-by: Mike Kravetz <mike.kravetz(a)oracle.com>
Acked-by: Vlastimil Babka <vbabka(a)suse.cz>
Acked-by: Michal Hocko <mhocko(a)suse.com>
Acked-by: Johannes Weiner <hannes(a)cmpxchg.org>
Cc: Michal Nazarewicz <mina86(a)mina86.com>
Cc: Joonsoo Kim <iamjoonsoo.kim(a)lge.com>
Cc: Laura Abbott <labbott(a)redhat.com>
Cc: Michal Hocko <mhocko(a)suse.com>
Cc: Mel Gorman <mgorman(a)techsingularity.net>
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
---
mm/page_alloc.c | 9 ++++++++-
1 file changed, 8 insertions(+), 1 deletion(-)
diff -puN mm/page_alloc.c~mm-cma-fix-alloc_contig_range-ret-code-potential-leak-v2 mm/page_alloc.c
--- a/mm/page_alloc.c~mm-cma-fix-alloc_contig_range-ret-code-potential-leak-v2
+++ a/mm/page_alloc.c
@@ -7652,11 +7652,18 @@ int alloc_contig_range(unsigned long sta
/*
* In case of -EBUSY, we'd like to know which page causes problem.
- * So, just fall through. We will check it in test_pages_isolated().
+ * So, just fall through. test_pages_isolated() has a tracepoint
+ * which will report the busy page.
+ *
+ * It is possible that busy pages could become available before
+ * the call to test_pages_isolated, and the range will actually be
+ * allocated. So, if we fall through be sure to clear ret so that
+ * -EBUSY is not accidentally used or returned to caller.
*/
ret = __alloc_contig_migrate_range(&cc, start, end);
if (ret && ret != -EBUSY)
goto done;
+ ret =0;
/*
* Pages from [start, end) are within a MAX_ORDER_NR_PAGES
_
Patches currently in -mm which might be from mike.kravetz(a)oracle.com are
mm-cma-fix-alloc_contig_range-ret-code-potential-leak-v2.patch
The patch titled
Subject: mm/cma: fix alloc_contig_range ret code/potential leak
has been removed from the -mm tree. Its filename was
mm-cma-fix-alloc_contig_range-ret-code-potential-leak.patch
This patch was dropped because an updated version will be merged
------------------------------------------------------
From: Mike Kravetz <mike.kravetz(a)oracle.com>
Subject: mm/cma: fix alloc_contig_range ret code/potential leak
In an attempt to make contiguous allocation routines more available to
drivers, I have been experimenting with code similar to that used by
alloc_gigantic_page(). While stressing this code with many other
allocations and frees in progress, I would sometimes notice large
'leaks' of page ranges.
I traced this down to the routine alloc_contig_range() itself. In
8ef5849fa8a2 ("mm/cma: always check which page caused allocation
failure") the code was changed so that an -EBUSY returned by
__alloc_contig_migrate_range() would not immediately return to the
caller. Rather, processing continues so that test_pages_isolated() is
eventually called. This is done because test_pages_isolated() has a
tracepoint to identify the busy pages.
However, it is possible (observed in my testing) that pages which were
busy when __alloc_contig_migrate_range was called may become available
by the time test_pages_isolated is called. Further, it is possible
that the entire range can actually be allocated. Unfortunately, in
this case the return code originally set by
__alloc_contig_migrate_range (-EBUSY) is returned to the calller.
Therefore, the caller assumes the range was not allocated and the pages
are essentially leaked.
The following patch simply updates the return code based on the value
returned from test_pages_isolated.
It is unlikely that we will hit this issue today based on the limited
number of callers to alloc_contig_range. However, I have Cc'ed stable
because if we do hit this issue it has the potential to leak a large
number of pages.
If the call __alloc_contig_migrate_range() in alloc_contig_range returns
-EBUSY, processing continues so that test_pages_isolated() is called where
there is a tracepoint to identify the busy pages. However, it is possible
for busy pages to become available between the calls to these two
routines. In this case, the range of pages may be allocated.
Unfortunately, the original return code (ret == -EBUSY) is still set and
returned to the caller. Therefore, the caller believes the pages were not
allocated and they are leaked.
Update the return code with the value from test_pages_isolated().
Link: http://lkml.kernel.org/r/20171120193930.23428-2-mike.kravetz@oracle.com
Fixes: 8ef5849fa8a2 ("mm/cma: always check which page caused allocation failure")
Signed-off-by: Mike Kravetz <mike.kravetz(a)oracle.com>
Acked-by: Michal Hocko <mhocko(a)suse.com>
Acked-by: Michal Nazarewicz <mina86(a)mina86.com>
Acked-by: Vlastimil Babka <vbabka(a)suse.cz>
Cc: Joonsoo Kim <iamjoonsoo.kim(a)lge.com>
Cc: Laura Abbott <labbott(a)redhat.com>
Cc: Michal Hocko <mhocko(a)suse.com>
Cc: Mel Gorman <mgorman(a)techsingularity.net>
Cc: Johannes Weiner <hannes(a)cmpxchg.org>
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
---
mm/page_alloc.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff -puN mm/page_alloc.c~mm-cma-fix-alloc_contig_range-ret-code-potential-leak mm/page_alloc.c
--- a/mm/page_alloc.c~mm-cma-fix-alloc_contig_range-ret-code-potential-leak
+++ a/mm/page_alloc.c
@@ -7702,10 +7702,10 @@ int alloc_contig_range(unsigned long sta
}
/* Make sure the range is really isolated. */
- if (test_pages_isolated(outer_start, end, false)) {
+ ret = test_pages_isolated(outer_start, end, false);
+ if (ret) {
pr_info_ratelimited("%s: [%lx, %lx) PFNs busy\n",
__func__, outer_start, end);
- ret = -EBUSY;
goto done;
}
_
Patches currently in -mm which might be from mike.kravetz(a)oracle.com are
mm-cma-fix-alloc_contig_range-ret-code-potential-leak-v2.patch
The patch titled
Subject: mm/hugetlb: fix NULL-pointer dereference on 5-level paging machine
has been added to the -mm tree. Its filename is
mm-hugetlb-fix-null-pointer-dereference-on-5-level-paging-machine.patch
This patch should soon appear at
http://ozlabs.org/~akpm/mmots/broken-out/mm-hugetlb-fix-null-pointer-derefe…
and later at
http://ozlabs.org/~akpm/mmotm/broken-out/mm-hugetlb-fix-null-pointer-derefe…
Before you just go and hit "reply", please:
a) Consider who else should be cc'ed
b) Prefer to cc a suitable mailing list as well
c) Ideally: find the original patch on the mailing list and do a
reply-to-all to that, adding suitable additional cc's
*** Remember to use Documentation/SubmitChecklist when testing your code ***
The -mm tree is included into linux-next and is updated
there every 3-4 working days
------------------------------------------------------
From: "Kirill A. Shutemov" <kirill.shutemov(a)linux.intel.com>
Subject: mm/hugetlb: fix NULL-pointer dereference on 5-level paging machine
I made a mistake during converting hugetlb code to 5-level paging: in
huge_pte_alloc() we have to use p4d_alloc(), not p4d_offset(). Otherwise
it leads to crash -- NULL-pointer dereference in pud_alloc() if p4d table
is not yet allocated.
It only can happen in 5-level paging mode. In 4-level paging mode
p4d_offset() always returns pgd, so we are fine.
Link: http://lkml.kernel.org/r/20171122121921.64822-1-kirill.shutemov@linux.intel…
Fixes: c2febafc6773 ("mm: convert generic code to 5-level paging")
Signed-off-by: Kirill A. Shutemov <kirill.shutemov(a)linux.intel.com>
Acked-by: Vlastimil Babka <vbabka(a)suse.cz>
Acked-by: Michal Hocko <mhocko(a)suse.com>
Cc: <stable(a)vger.kernel.org> [4.11+]
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
---
mm/hugetlb.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff -puN mm/hugetlb.c~mm-hugetlb-fix-null-pointer-dereference-on-5-level-paging-machine mm/hugetlb.c
--- a/mm/hugetlb.c~mm-hugetlb-fix-null-pointer-dereference-on-5-level-paging-machine
+++ a/mm/hugetlb.c
@@ -4635,7 +4635,9 @@ pte_t *huge_pte_alloc(struct mm_struct *
pte_t *pte = NULL;
pgd = pgd_offset(mm, addr);
- p4d = p4d_offset(pgd, addr);
+ p4d = p4d_alloc(mm, pgd, addr);
+ if (!p4d)
+ return NULL;
pud = pud_alloc(mm, p4d, addr);
if (pud) {
if (sz == PUD_SIZE) {
_
Patches currently in -mm which might be from kirill.shutemov(a)linux.intel.com are
mm-hugetlb-fix-null-pointer-dereference-on-5-level-paging-machine.patch
The patch titled
Subject: autofs: revert "autofs: fix AT_NO_AUTOMOUNT not being honored"
has been added to the -mm tree. Its filename is
autofs-revert-fix-at_no_automount-not-being-honored.patch
This patch should soon appear at
http://ozlabs.org/~akpm/mmots/broken-out/autofs-revert-fix-at_no_automount-…
and later at
http://ozlabs.org/~akpm/mmotm/broken-out/autofs-revert-fix-at_no_automount-…
Before you just go and hit "reply", please:
a) Consider who else should be cc'ed
b) Prefer to cc a suitable mailing list as well
c) Ideally: find the original patch on the mailing list and do a
reply-to-all to that, adding suitable additional cc's
*** Remember to use Documentation/SubmitChecklist when testing your code ***
The -mm tree is included into linux-next and is updated
there every 3-4 working days
------------------------------------------------------
From: Ian Kent <raven(a)themaw.net>
Subject: autofs: revert "autofs: fix AT_NO_AUTOMOUNT not being honored"
42f4614821 ("autofs: fix AT_NO_AUTOMOUNT not being honored") allowed the
fstatat(2) system call to properly honor the AT_NO_AUTOMOUNT flag but
introduced a semantic change.
In order to honor AT_NO_AUTOMOUNT a semantic change was made to the
negative dentry case for stat family system calls in follow_automount().
This changed the unconditional triggering of an automount in this case to
no longer be done and an error returned instead.
This has caused more problems than I expected so reverting the change is
needed.
In a discussion with Neil Brown it was concluded that the automount(8)
daemon can implement this change without kernel modifications. So that
will be done instead and the autofs module documentation updated with a
description of the problem and what needs to be done by module users for
this specific case.
Link: http://lkml.kernel.org/r/151174730120.6162.3848002191530283984.stgit@pluto.…
Fixes: 42f4614821 ("autofs: fix AT_NO_AUTOMOUNT not being honored")
Signed-off-by: Ian Kent <raven(a)themaw.net>
Cc: Neil Brown <neilb(a)suse.com>
Cc: Al Viro <viro(a)ZenIV.linux.org.uk>
Cc: David Howells <dhowells(a)redhat.com>
Cc: Colin Walters <walters(a)redhat.com>
Cc: Ondrej Holy <oholy(a)redhat.com>
Cc: <stable(a)vger.kernel.org> [4.11+]
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
---
fs/namei.c | 15 +++------------
include/linux/fs.h | 3 ++-
2 files changed, 5 insertions(+), 13 deletions(-)
diff -puN fs/namei.c~autofs-revert-fix-at_no_automount-not-being-honored fs/namei.c
--- a/fs/namei.c~autofs-revert-fix-at_no_automount-not-being-honored
+++ a/fs/namei.c
@@ -1129,18 +1129,9 @@ static int follow_automount(struct path
* of the daemon to instantiate them before they can be used.
*/
if (!(nd->flags & (LOOKUP_PARENT | LOOKUP_DIRECTORY |
- LOOKUP_OPEN | LOOKUP_CREATE |
- LOOKUP_AUTOMOUNT))) {
- /* Positive dentry that isn't meant to trigger an
- * automount, EISDIR will allow it to be used,
- * otherwise there's no mount here "now" so return
- * ENOENT.
- */
- if (path->dentry->d_inode)
- return -EISDIR;
- else
- return -ENOENT;
- }
+ LOOKUP_OPEN | LOOKUP_CREATE | LOOKUP_AUTOMOUNT)) &&
+ path->dentry->d_inode)
+ return -EISDIR;
if (path->dentry->d_sb->s_user_ns != &init_user_ns)
return -EACCES;
diff -puN include/linux/fs.h~autofs-revert-fix-at_no_automount-not-being-honored include/linux/fs.h
--- a/include/linux/fs.h~autofs-revert-fix-at_no_automount-not-being-honored
+++ a/include/linux/fs.h
@@ -3088,7 +3088,8 @@ static inline int vfs_lstat(const char _
static inline int vfs_fstatat(int dfd, const char __user *filename,
struct kstat *stat, int flags)
{
- return vfs_statx(dfd, filename, flags, stat, STATX_BASIC_STATS);
+ return vfs_statx(dfd, filename, flags | AT_NO_AUTOMOUNT,
+ stat, STATX_BASIC_STATS);
}
static inline int vfs_fstat(int fd, struct kstat *stat)
{
_
Patches currently in -mm which might be from raven(a)themaw.net are
autofs-revert-take-more-care-to-not-update-last_used-on-path-walk.patch
autofs-revert-fix-at_no_automount-not-being-honored.patch
The patch titled
Subject: autofs: revert "autofs: take more care to not update last_used on path walk"
has been added to the -mm tree. Its filename is
autofs-revert-take-more-care-to-not-update-last_used-on-path-walk.patch
This patch should soon appear at
http://ozlabs.org/~akpm/mmots/broken-out/autofs-revert-take-more-care-to-no…
and later at
http://ozlabs.org/~akpm/mmotm/broken-out/autofs-revert-take-more-care-to-no…
Before you just go and hit "reply", please:
a) Consider who else should be cc'ed
b) Prefer to cc a suitable mailing list as well
c) Ideally: find the original patch on the mailing list and do a
reply-to-all to that, adding suitable additional cc's
*** Remember to use Documentation/SubmitChecklist when testing your code ***
The -mm tree is included into linux-next and is updated
there every 3-4 working days
------------------------------------------------------
From: Ian Kent <raven(a)themaw.net>
Subject: autofs: revert "autofs: take more care to not update last_used on path walk"
While 092a53452b ("autofs: take more care to not update last_used on path
walk") helped (partially) resolve a problem where automounts were not
expiring due to aggressive accesses from user space it has a side effect
for very large environments.
This change helps with the expire problem by making the expire more
aggressive but, for very large environments, that means more mount
requests from clients. When there are a lot of clients that can mean
fairly significant server load increases.
It turns out I put the last_used in this position to solve this very
problem and failed to update my own thinking of the autofs expire policy.
So the patch being reverted introduces a regression which should be fixed.
Link: http://lkml.kernel.org/r/151174729420.6162.1832622523537052460.stgit@pluto.…
Fixes: 092a53452b ("autofs: take more care to not update last_used on path walk")
Signed-off-by: Ian Kent <raven(a)themaw.net>
Reviewed-by: NeilBrown <neilb(a)suse.com>
Cc: Al Viro <viro(a)ZenIV.linux.org.uk>
Cc: <stable(a)vger.kernel.org> [4.11+]
Cc: Colin Walters <walters(a)redhat.com>
Cc: David Howells <dhowells(a)redhat.com>
Cc: Ondrej Holy <oholy(a)redhat.com>
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
---
fs/autofs4/root.c | 17 ++++++-----------
1 file changed, 6 insertions(+), 11 deletions(-)
diff -puN fs/autofs4/root.c~autofs-revert-take-more-care-to-not-update-last_used-on-path-walk fs/autofs4/root.c
--- a/fs/autofs4/root.c~autofs-revert-take-more-care-to-not-update-last_used-on-path-walk
+++ a/fs/autofs4/root.c
@@ -281,8 +281,8 @@ static int autofs4_mount_wait(const stru
pr_debug("waiting for mount name=%pd\n", path->dentry);
status = autofs4_wait(sbi, path, NFY_MOUNT);
pr_debug("mount wait done status=%d\n", status);
- ino->last_used = jiffies;
}
+ ino->last_used = jiffies;
return status;
}
@@ -321,21 +321,16 @@ static struct dentry *autofs4_mountpoint
*/
if (autofs_type_indirect(sbi->type) && d_unhashed(dentry)) {
struct dentry *parent = dentry->d_parent;
+ struct autofs_info *ino;
struct dentry *new;
new = d_lookup(parent, &dentry->d_name);
if (!new)
return NULL;
- if (new == dentry)
- dput(new);
- else {
- struct autofs_info *ino;
-
- ino = autofs4_dentry_ino(new);
- ino->last_used = jiffies;
- dput(path->dentry);
- path->dentry = new;
- }
+ ino = autofs4_dentry_ino(new);
+ ino->last_used = jiffies;
+ dput(path->dentry);
+ path->dentry = new;
}
return path->dentry;
}
_
Patches currently in -mm which might be from raven(a)themaw.net are
autofs-revert-take-more-care-to-not-update-last_used-on-path-walk.patch
autofs-revert-fix-at_no_automount-not-being-honored.patch
The patch titled
Subject: fat: Fix sb_rdonly() change
has been added to the -mm tree. Its filename is
fat-fix-sb_rdonly-change.patch
This patch should soon appear at
http://ozlabs.org/~akpm/mmots/broken-out/fat-fix-sb_rdonly-change.patch
and later at
http://ozlabs.org/~akpm/mmotm/broken-out/fat-fix-sb_rdonly-change.patch
Before you just go and hit "reply", please:
a) Consider who else should be cc'ed
b) Prefer to cc a suitable mailing list as well
c) Ideally: find the original patch on the mailing list and do a
reply-to-all to that, adding suitable additional cc's
*** Remember to use Documentation/SubmitChecklist when testing your code ***
The -mm tree is included into linux-next and is updated
there every 3-4 working days
------------------------------------------------------
From: OGAWA Hirofumi <hirofumi(a)mail.parknet.co.jp>
Subject: fat: Fix sb_rdonly() change
bc98a42c1f7d0f ("VFS: Convert sb->s_flags & MS_RDONLY to sb_rdonly(sb)")
converted fat_remount():new_rdonly from a bool to an int. However
fat_remount() depends upon the compiler's conversion of a non-zero integer
into boolean `true'.
Fix it by switching `new_rdonly' back into a bool.
Link: http://lkml.kernel.org/r/87mv3d5x51.fsf@mail.parknet.co.jp
Fixes: bc98a42c1f7d0f8 ("VFS: Convert sb->s_flags & MS_RDONLY to sb_rdonly(sb)")
Signed-off-by: OGAWA Hirofumi <hirofumi(a)mail.parknet.co.jp>
Cc: Joe Perches <joe(a)perches.com>
Cc: David Howells <dhowells(a)redhat.com>
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
---
fs/fat/inode.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff -puN fs/fat/inode.c~fat-fix-sb_rdonly-change fs/fat/inode.c
--- a/fs/fat/inode.c~fat-fix-sb_rdonly-change
+++ a/fs/fat/inode.c
@@ -779,7 +779,7 @@ static void __exit fat_destroy_inodecach
static int fat_remount(struct super_block *sb, int *flags, char *data)
{
- int new_rdonly;
+ bool new_rdonly;
struct msdos_sb_info *sbi = MSDOS_SB(sb);
*flags |= SB_NODIRATIME | (sbi->options.isvfat ? 0 : SB_NOATIME);
_
Patches currently in -mm which might be from hirofumi(a)mail.parknet.co.jp are
fat-fix-sb_rdonly-change.patch
The patch titled
Subject: kernel/async.c: revert "async: simplify lowest_in_progress()"
has been added to the -mm tree. Its filename is
revert-async-simplify-lowest_in_progress.patch
This patch should soon appear at
http://ozlabs.org/~akpm/mmots/broken-out/revert-async-simplify-lowest_in_pr…
and later at
http://ozlabs.org/~akpm/mmotm/broken-out/revert-async-simplify-lowest_in_pr…
Before you just go and hit "reply", please:
a) Consider who else should be cc'ed
b) Prefer to cc a suitable mailing list as well
c) Ideally: find the original patch on the mailing list and do a
reply-to-all to that, adding suitable additional cc's
*** Remember to use Documentation/SubmitChecklist when testing your code ***
The -mm tree is included into linux-next and is updated
there every 3-4 working days
------------------------------------------------------
From: Rasmus Villemoes <linux(a)rasmusvillemoes.dk>
Subject: kernel/async.c: revert "async: simplify lowest_in_progress()"
This reverts 92266d6ef60c2381 ("async: simplify lowest_in_progress()"),
which was simply wrong: In the case where domain is NULL, we now use the
wrong offsetof() in the list_first_entry macro, so we don't actually fetch
the ->cookie value, but rather the eight bytes located sizeof(struct
list_head) further into the struct async_entry.
On 64 bit, that's the data member, while on 32 bit, that's a u64 built
from func and data in some order.
I think the bug happens to be harmless in practice: It obviously only
affects callers which pass a NULL domain, and AFAICT the only such caller
is
async_synchronize_full() ->
async_synchronize_full_domain(NULL) ->
async_synchronize_cookie_domain(ASYNC_COOKIE_MAX, NULL)
and the ASYNC_COOKIE_MAX means that in practice we end up waiting for the
async_global_pending list to be empty - but it would break if somebody
happened to pass (void*)-1 as the data element to async_schedule, and of
course also if somebody ever does a async_synchronize_cookie_domain(,
NULL) with a "finite" cookie value.
Maybe the "harmless in practice" means this isn't -stable material. But
I'm not completely confident my quick git grep'ing is enough, and there
might be affected code in one of the earlier kernels that has since been
removed, so I'll leave the decision to the stable guys.
Link: http://lkml.kernel.org/r/20171128104938.3921-1-linux@rasmusvillemoes.dk
Fixes: 92266d6ef60c "async: simplify lowest_in_progress()"
Signed-off-by: Rasmus Villemoes <linux(a)rasmusvillemoes.dk>
Acked-by: Tejun Heo <tj(a)kernel.org>
Cc: Arjan van de Ven <arjan(a)linux.intel.com>
Cc: Adam Wallis <awallis(a)codeaurora.org>
Cc: Lai Jiangshan <laijs(a)cn.fujitsu.com>
Cc: <stable(a)vger.kernel.org> [3.10+]
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
---
kernel/async.c | 20 ++++++++++++--------
1 file changed, 12 insertions(+), 8 deletions(-)
diff -puN kernel/async.c~revert-async-simplify-lowest_in_progress kernel/async.c
--- a/kernel/async.c~revert-async-simplify-lowest_in_progress
+++ a/kernel/async.c
@@ -84,20 +84,24 @@ static atomic_t entry_count;
static async_cookie_t lowest_in_progress(struct async_domain *domain)
{
- struct list_head *pending;
+ struct async_entry *first = NULL;
async_cookie_t ret = ASYNC_COOKIE_MAX;
unsigned long flags;
spin_lock_irqsave(&async_lock, flags);
- if (domain)
- pending = &domain->pending;
- else
- pending = &async_global_pending;
+ if (domain) {
+ if (!list_empty(&domain->pending))
+ first = list_first_entry(&domain->pending,
+ struct async_entry, domain_list);
+ } else {
+ if (!list_empty(&async_global_pending))
+ first = list_first_entry(&async_global_pending,
+ struct async_entry, global_list);
+ }
- if (!list_empty(pending))
- ret = list_first_entry(pending, struct async_entry,
- domain_list)->cookie;
+ if (first)
+ ret = first->cookie;
spin_unlock_irqrestore(&async_lock, flags);
return ret;
_
Patches currently in -mm which might be from linux(a)rasmusvillemoes.dk are
revert-async-simplify-lowest_in_progress.patch
The patch titled
Subject: mm, memcg: fix mem_cgroup_swapout() for THPs
has been added to the -mm tree. Its filename is
mm-memcg-fix-mem_cgroup_swapout-for-thps.patch
This patch should soon appear at
http://ozlabs.org/~akpm/mmots/broken-out/mm-memcg-fix-mem_cgroup_swapout-fo…
and later at
http://ozlabs.org/~akpm/mmotm/broken-out/mm-memcg-fix-mem_cgroup_swapout-fo…
Before you just go and hit "reply", please:
a) Consider who else should be cc'ed
b) Prefer to cc a suitable mailing list as well
c) Ideally: find the original patch on the mailing list and do a
reply-to-all to that, adding suitable additional cc's
*** Remember to use Documentation/SubmitChecklist when testing your code ***
The -mm tree is included into linux-next and is updated
there every 3-4 working days
------------------------------------------------------
From: Shakeel Butt <shakeelb(a)google.com>
Subject: mm, memcg: fix mem_cgroup_swapout() for THPs
d6810d730022 ("memcg, THP, swap: make mem_cgroup_swapout() support THP")
changed mem_cgroup_swapout() to support transparent huge page (THP).
However the patch missed one location which should be changed for
correctly handling THPs. The resulting bug will cause the memory cgroups
whose THPs were swapped out to become zombies on deletion.
Link: http://lkml.kernel.org/r/20171128161941.20931-1-shakeelb@google.com
Fixes: d6810d730022 ("memcg, THP, swap: make mem_cgroup_swapout() support THP")
Signed-off-by: Shakeel Butt <shakeelb(a)google.com>
Acked-by: Michal Hocko <mhocko(a)suse.com>
Cc: Huang Ying <ying.huang(a)intel.com>
Cc: Vladimir Davydov <vdavydov.dev(a)gmail.com>
Cc: Greg Thelen <gthelen(a)google.com>
Cc: Johannes Weiner <hannes(a)cmpxchg.org>
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
---
mm/memcontrol.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff -puN mm/memcontrol.c~mm-memcg-fix-mem_cgroup_swapout-for-thps mm/memcontrol.c
--- a/mm/memcontrol.c~mm-memcg-fix-mem_cgroup_swapout-for-thps
+++ a/mm/memcontrol.c
@@ -6044,7 +6044,7 @@ void mem_cgroup_swapout(struct page *pag
memcg_check_events(memcg, page);
if (!mem_cgroup_is_root(memcg))
- css_put(&memcg->css);
+ css_put_many(&memcg->css, nr_entries);
}
/**
_
Patches currently in -mm which might be from shakeelb(a)google.com are
mm-memcg-fix-mem_cgroup_swapout-for-thps.patch
mm-mlock-vmscan-no-more-skipping-pagevecs.patch
vfs-remove-might_sleep-from-clear_inode.patch
From: Daniel Jurgens <danielj(a)mellanox.com>
For now the only LSM security enforcement mechanism available is
specific to InfiniBand. Bypass enforcement for non-IB link types.
This fixes a regression where modify_qp fails for iWARP because
querying the PKEY returns -EINVAL.
Cc: Paul Moore <paul(a)paul-moore.com>
Cc: Don Dutile <ddutile(a)redhat.com>
Cc: stable(a)vger.kernel.org
Reported-by: Potnuri Bharat Teja <bharat(a)chelsio.com>
Fixes: d291f1a65232("IB/core: Enforce PKey security on QPs")
Fixes: 47a2b338fe63("IB/core: Enforce security on management datagrams")
Signed-off-by: Daniel Jurgens <danielj(a)mellanox.com>
Reviewed-by: Parav Pandit <parav(a)mellanox.com>
Tested-by: Potnuri Bharat Teja <bharat(a)chelsio.com>
Signed-off-by: Leon Romanovsky <leon(a)kernel.org>
---
Changelog:
v1->v2: Fixed build errors
v0->v1: Added proper SElinux patch
---
drivers/infiniband/core/security.c | 43 ++++++++++++++++++++++++++++++++++++--
1 file changed, 41 insertions(+), 2 deletions(-)
diff --git a/drivers/infiniband/core/security.c b/drivers/infiniband/core/security.c
index 23278ed5be45..06c608c07b65 100644
--- a/drivers/infiniband/core/security.c
+++ b/drivers/infiniband/core/security.c
@@ -417,8 +417,17 @@ void ib_close_shared_qp_security(struct ib_qp_security *sec)
int ib_create_qp_security(struct ib_qp *qp, struct ib_device *dev)
{
+ u8 i = rdma_start_port(dev);
+ bool is_ib = false;
int ret;
+ while (i <= rdma_end_port(dev) && !is_ib)
+ is_ib = rdma_protocol_ib(dev, i++);
+
+ /* If this isn't an IB device don't create the security context */
+ if (!is_ib)
+ return 0;
+
qp->qp_sec = kzalloc(sizeof(*qp->qp_sec), GFP_KERNEL);
if (!qp->qp_sec)
return -ENOMEM;
@@ -441,6 +450,10 @@ EXPORT_SYMBOL(ib_create_qp_security);
void ib_destroy_qp_security_begin(struct ib_qp_security *sec)
{
+ /* Return if not IB */
+ if (!sec)
+ return;
+
mutex_lock(&sec->mutex);
/* Remove the QP from the lists so it won't get added to
@@ -470,6 +483,10 @@ void ib_destroy_qp_security_abort(struct ib_qp_security *sec)
int ret;
int i;
+ /* Return if not IB */
+ if (!sec)
+ return;
+
/* If a concurrent cache update is in progress this
* QP security could be marked for an error state
* transition. Wait for this to complete.
@@ -505,6 +522,10 @@ void ib_destroy_qp_security_end(struct ib_qp_security *sec)
{
int i;
+ /* Return if not IB */
+ if (!sec)
+ return;
+
/* If a concurrent cache update is occurring we must
* wait until this QP security structure is processed
* in the QP to error flow before destroying it because
@@ -565,13 +586,19 @@ int ib_security_modify_qp(struct ib_qp *qp,
bool pps_change = ((qp_attr_mask & (IB_QP_PKEY_INDEX | IB_QP_PORT)) ||
(qp_attr_mask & IB_QP_ALT_PATH));
+ WARN_ONCE((qp_attr_mask & IB_QP_PORT &&
+ rdma_protocol_ib(real_qp->device, qp_attr->port_num) &&
+ !real_qp->qp_sec),
+ "%s: QP security is not initialized for IB QP: %d\n",
+ __func__, real_qp->qp_num);
+
/* The port/pkey settings are maintained only for the real QP. Open
* handles on the real QP will be in the shared_qp_list. When
* enforcing security on the real QP all the shared QPs will be
* checked as well.
*/
- if (pps_change && !special_qp) {
+ if (pps_change && !special_qp && real_qp->qp_sec) {
mutex_lock(&real_qp->qp_sec->mutex);
new_pps = get_new_pps(real_qp,
qp_attr,
@@ -600,7 +627,7 @@ int ib_security_modify_qp(struct ib_qp *qp,
qp_attr_mask,
udata);
- if (pps_change && !special_qp) {
+ if (pps_change && !special_qp && real_qp->qp_sec) {
/* Clean up the lists and free the appropriate
* ports_pkeys structure.
*/
@@ -631,6 +658,9 @@ int ib_security_pkey_access(struct ib_device *dev,
u16 pkey;
int ret;
+ if (!rdma_protocol_ib(dev, port_num))
+ return 0;
+
ret = ib_get_cached_pkey(dev, port_num, pkey_index, &pkey);
if (ret)
return ret;
@@ -665,6 +695,9 @@ int ib_mad_agent_security_setup(struct ib_mad_agent *agent,
{
int ret;
+ if (!rdma_protocol_ib(agent->device, agent->port_num))
+ return 0;
+
ret = security_ib_alloc_security(&agent->security);
if (ret)
return ret;
@@ -690,6 +723,9 @@ int ib_mad_agent_security_setup(struct ib_mad_agent *agent,
void ib_mad_agent_security_cleanup(struct ib_mad_agent *agent)
{
+ if (!rdma_protocol_ib(agent->device, agent->port_num))
+ return;
+
security_ib_free_security(agent->security);
if (agent->lsm_nb_reg)
unregister_lsm_notifier(&agent->lsm_nb);
@@ -697,6 +733,9 @@ void ib_mad_agent_security_cleanup(struct ib_mad_agent *agent)
int ib_mad_enforce_security(struct ib_mad_agent_private *map, u16 pkey_index)
{
+ if (!rdma_protocol_ib(map->agent.device, map->agent.port_num))
+ return 0;
+
if (map->agent.qp->qp_type == IB_QPT_SMI && !map->agent.smp_allowed)
return -EACCES;
--
2.15.0
From: Eric Biggers <ebiggers(a)google.com>
When the request_key() syscall is not passed a destination keyring, it
links the requested key (if constructed) into the "default" request-key
keyring. This should require Write permission to the keyring. However,
there is actually no permission check.
This can be abused to add keys to any keyring to which only Search
permission is granted. This is because Search permission allows joining
the keyring. keyctl_set_reqkey_keyring(KEY_REQKEY_DEFL_SESSION_KEYRING)
then will set the default request-key keyring to the session keyring.
Then, request_key() can be used to add keys to the keyring.
Both negatively and positively instantiated keys can be added using this
method. Adding negative keys is trivial. Adding a positive key is a
bit trickier. It requires that either /sbin/request-key positively
instantiates the key, or that another thread adds the key to the process
keyring at just the right time, such that request_key() misses it
initially but then finds it in construct_alloc_key().
Fix this bug by checking for Write permission to the keyring in
construct_get_dest_keyring() when the default keyring is being used.
We don't do the permission check for non-default keyrings because that
was already done by the earlier call to lookup_user_key(). Also,
request_key_and_link() is currently passed a 'struct key *' rather than
a key_ref_t, so the "possessed" bit is unavailable.
We also don't do the permission check for the "requestor keyring", to
continue to support the use case described by commit 8bbf4976b59f
("KEYS: Alter use of key instantiation link-to-keyring argument") where
/sbin/request-key recursively calls request_key() to add keys to the
original requestor's destination keyring. (I don't know of any users
who actually do that, though...)
Fixes: 3e30148c3d52 ("[PATCH] Keys: Make request-key create an authorisation key")
Cc: <stable(a)vger.kernel.org> # v2.6.13+
Signed-off-by: Eric Biggers <ebiggers(a)google.com>
---
v2: also skip permission check if default dest_keyring is NULL
security/keys/request_key.c | 46 ++++++++++++++++++++++++++++++++++++---------
1 file changed, 37 insertions(+), 9 deletions(-)
diff --git a/security/keys/request_key.c b/security/keys/request_key.c
index e8036cd0ad54..7dc741382154 100644
--- a/security/keys/request_key.c
+++ b/security/keys/request_key.c
@@ -251,11 +251,12 @@ static int construct_key(struct key *key, const void *callout_info,
* The keyring selected is returned with an extra reference upon it which the
* caller must release.
*/
-static void construct_get_dest_keyring(struct key **_dest_keyring)
+static int construct_get_dest_keyring(struct key **_dest_keyring)
{
struct request_key_auth *rka;
const struct cred *cred = current_cred();
struct key *dest_keyring = *_dest_keyring, *authkey;
+ int ret;
kenter("%p", dest_keyring);
@@ -264,6 +265,8 @@ static void construct_get_dest_keyring(struct key **_dest_keyring)
/* the caller supplied one */
key_get(dest_keyring);
} else {
+ bool do_perm_check = true;
+
/* use a default keyring; falling through the cases until we
* find one that we actually have */
switch (cred->jit_keyring) {
@@ -278,8 +281,10 @@ static void construct_get_dest_keyring(struct key **_dest_keyring)
dest_keyring =
key_get(rka->dest_keyring);
up_read(&authkey->sem);
- if (dest_keyring)
+ if (dest_keyring) {
+ do_perm_check = false;
break;
+ }
}
case KEY_REQKEY_DEFL_THREAD_KEYRING:
@@ -314,11 +319,29 @@ static void construct_get_dest_keyring(struct key **_dest_keyring)
default:
BUG();
}
+
+ /*
+ * Require Write permission on the keyring. This is essential
+ * because the default keyring may be the session keyring, and
+ * joining a keyring only requires Search permission.
+ *
+ * However, this check is skipped for the "requestor keyring" so
+ * that /sbin/request-key can itself use request_key() to add
+ * keys to the original requestor's destination keyring.
+ */
+ if (dest_keyring && do_perm_check) {
+ ret = key_permission(make_key_ref(dest_keyring, 1),
+ KEY_NEED_WRITE);
+ if (ret) {
+ key_put(dest_keyring);
+ return ret;
+ }
+ }
}
*_dest_keyring = dest_keyring;
kleave(" [dk %d]", key_serial(dest_keyring));
- return;
+ return 0;
}
/*
@@ -444,11 +467,15 @@ static struct key *construct_key_and_link(struct keyring_search_context *ctx,
if (ctx->index_key.type == &key_type_keyring)
return ERR_PTR(-EPERM);
- user = key_user_lookup(current_fsuid());
- if (!user)
- return ERR_PTR(-ENOMEM);
+ ret = construct_get_dest_keyring(&dest_keyring);
+ if (ret)
+ goto error;
- construct_get_dest_keyring(&dest_keyring);
+ user = key_user_lookup(current_fsuid());
+ if (!user) {
+ ret = -ENOMEM;
+ goto error_put_dest_keyring;
+ }
ret = construct_alloc_key(ctx, dest_keyring, flags, user, &key);
key_user_put(user);
@@ -463,7 +490,7 @@ static struct key *construct_key_and_link(struct keyring_search_context *ctx,
} else if (ret == -EINPROGRESS) {
ret = 0;
} else {
- goto couldnt_alloc_key;
+ goto error_put_dest_keyring;
}
key_put(dest_keyring);
@@ -473,8 +500,9 @@ static struct key *construct_key_and_link(struct keyring_search_context *ctx,
construction_failed:
key_negate_and_link(key, key_negative_timeout, NULL, NULL);
key_put(key);
-couldnt_alloc_key:
+error_put_dest_keyring:
key_put(dest_keyring);
+error:
kleave(" = %d", ret);
return ERR_PTR(ret);
}
--
2.15.0.417.g466bffb3ac-goog
From: Eric Biggers <ebiggers(a)google.com>
When the request_key() syscall is not passed a destination keyring, it
links the requested key (if constructed) into the "default" request-key
keyring. This should require Write permission to the keyring. However,
there is actually no permission check.
This can be abused to add keys to any keyring to which only Search
permission is granted. This is because Search permission allows joining
the keyring. keyctl_set_reqkey_keyring(KEY_REQKEY_DEFL_SESSION_KEYRING)
then will set the default request-key keyring to the session keyring.
Then, request_key() can be used to add keys to the keyring.
Both negatively and positively instantiated keys can be added using this
method. Adding negative keys is trivial. Adding a positive key is a
bit trickier. It requires that either /sbin/request-key positively
instantiates the key, or that another thread adds the key to the process
keyring at just the right time, such that request_key() misses it
initially but then finds it in construct_alloc_key().
Fix this bug by checking for Write permission to the keyring in
construct_get_dest_keyring() when the default keyring is being used.
We don't do the permission check for non-default keyrings because that
was already done by the earlier call to lookup_user_key(). Also,
request_key_and_link() is currently passed a 'struct key *' rather than
a key_ref_t, so the "possessed" bit is unavailable.
We also don't do the permission check for the "requestor keyring", to
continue to support the use case described by commit 8bbf4976b59f
("KEYS: Alter use of key instantiation link-to-keyring argument") where
/sbin/request-key recursively calls request_key() to add keys to the
original requestor's destination keyring. (I don't know of any users
who actually do that, though...)
Fixes: 3e30148c3d52 ("[PATCH] Keys: Make request-key create an authorisation key")
Cc: <stable(a)vger.kernel.org> # v2.6.13+
Signed-off-by: Eric Biggers <ebiggers(a)google.com>
---
security/keys/request_key.c | 46 ++++++++++++++++++++++++++++++++++++---------
1 file changed, 37 insertions(+), 9 deletions(-)
diff --git a/security/keys/request_key.c b/security/keys/request_key.c
index c6880af8b411..4557c1c368aa 100644
--- a/security/keys/request_key.c
+++ b/security/keys/request_key.c
@@ -251,11 +251,12 @@ static int construct_key(struct key *key, const void *callout_info,
* The keyring selected is returned with an extra reference upon it which the
* caller must release.
*/
-static void construct_get_dest_keyring(struct key **_dest_keyring)
+static int construct_get_dest_keyring(struct key **_dest_keyring)
{
struct request_key_auth *rka;
const struct cred *cred = current_cred();
struct key *dest_keyring = *_dest_keyring, *authkey;
+ int ret;
kenter("%p", dest_keyring);
@@ -264,6 +265,8 @@ static void construct_get_dest_keyring(struct key **_dest_keyring)
/* the caller supplied one */
key_get(dest_keyring);
} else {
+ bool do_perm_check = true;
+
/* use a default keyring; falling through the cases until we
* find one that we actually have */
switch (cred->jit_keyring) {
@@ -278,8 +281,10 @@ static void construct_get_dest_keyring(struct key **_dest_keyring)
dest_keyring =
key_get(rka->dest_keyring);
up_read(&authkey->sem);
- if (dest_keyring)
+ if (dest_keyring) {
+ do_perm_check = false;
break;
+ }
}
case KEY_REQKEY_DEFL_THREAD_KEYRING:
@@ -314,11 +319,29 @@ static void construct_get_dest_keyring(struct key **_dest_keyring)
default:
BUG();
}
+
+ /*
+ * Require Write permission on the keyring. This is essential
+ * because the default keyring may be the session keyring, and
+ * joining a keyring only requires Search permission.
+ *
+ * However, this check is skipped for the "requestor keyring" so
+ * that /sbin/request-key can itself use request_key() to add
+ * keys to the original requestor's destination keyring.
+ */
+ if (do_perm_check) {
+ ret = key_permission(make_key_ref(dest_keyring, 1),
+ KEY_NEED_WRITE);
+ if (ret) {
+ key_put(dest_keyring);
+ return ret;
+ }
+ }
}
*_dest_keyring = dest_keyring;
kleave(" [dk %d]", key_serial(dest_keyring));
- return;
+ return 0;
}
/*
@@ -444,11 +467,15 @@ static struct key *construct_key_and_link(struct keyring_search_context *ctx,
if (ctx->index_key.type == &key_type_keyring)
return ERR_PTR(-EPERM);
- user = key_user_lookup(current_fsuid());
- if (!user)
- return ERR_PTR(-ENOMEM);
+ ret = construct_get_dest_keyring(&dest_keyring);
+ if (ret)
+ goto error;
- construct_get_dest_keyring(&dest_keyring);
+ user = key_user_lookup(current_fsuid());
+ if (!user) {
+ ret = -ENOMEM;
+ goto error_put_dest_keyring;
+ }
ret = construct_alloc_key(ctx, dest_keyring, flags, user, &key);
key_user_put(user);
@@ -463,7 +490,7 @@ static struct key *construct_key_and_link(struct keyring_search_context *ctx,
} else if (ret == -EINPROGRESS) {
ret = 0;
} else {
- goto couldnt_alloc_key;
+ goto error_put_dest_keyring;
}
key_put(dest_keyring);
@@ -473,8 +500,9 @@ static struct key *construct_key_and_link(struct keyring_search_context *ctx,
construction_failed:
key_negate_and_link(key, key_negative_timeout, NULL, NULL);
key_put(key);
-couldnt_alloc_key:
+error_put_dest_keyring:
key_put(dest_keyring);
+error:
kleave(" = %d", ret);
return ERR_PTR(ret);
}
--
2.15.0.448.gf294e3d99a-goog
From: Eric Biggers <ebiggers(a)google.com>
->pkey_algo used to be an enum, but was changed to a string by commit
4e8ae72a75aa ("X.509: Make algo identifiers text instead of enum"). But
two comparisons were not updated. Fix them to use strcmp().
This bug broke signature verification in certain configurations,
depending on whether the string constants were deduplicated or not.
Fixes: 4e8ae72a75aa ("X.509: Make algo identifiers text instead of enum")
Cc: <stable(a)vger.kernel.org> # v4.6+
Signed-off-by: Eric Biggers <ebiggers(a)google.com>
---
v2: use != 0 in comparisons
crypto/asymmetric_keys/pkcs7_verify.c | 2 +-
crypto/asymmetric_keys/x509_public_key.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/crypto/asymmetric_keys/pkcs7_verify.c b/crypto/asymmetric_keys/pkcs7_verify.c
index 2d93d9eccb4d..986033e64a83 100644
--- a/crypto/asymmetric_keys/pkcs7_verify.c
+++ b/crypto/asymmetric_keys/pkcs7_verify.c
@@ -150,7 +150,7 @@ static int pkcs7_find_key(struct pkcs7_message *pkcs7,
pr_devel("Sig %u: Found cert serial match X.509[%u]\n",
sinfo->index, certix);
- if (x509->pub->pkey_algo != sinfo->sig->pkey_algo) {
+ if (strcmp(x509->pub->pkey_algo, sinfo->sig->pkey_algo) != 0) {
pr_warn("Sig %u: X.509 algo and PKCS#7 sig algo don't match\n",
sinfo->index);
continue;
diff --git a/crypto/asymmetric_keys/x509_public_key.c b/crypto/asymmetric_keys/x509_public_key.c
index c9013582c026..3d6f124a8b34 100644
--- a/crypto/asymmetric_keys/x509_public_key.c
+++ b/crypto/asymmetric_keys/x509_public_key.c
@@ -135,7 +135,7 @@ int x509_check_for_self_signed(struct x509_certificate *cert)
}
ret = -EKEYREJECTED;
- if (cert->pub->pkey_algo != cert->sig->pkey_algo)
+ if (strcmp(cert->pub->pkey_algo, cert->sig->pkey_algo) != 0)
goto out;
ret = public_key_verify_signature(cert->pub, cert->sig);
--
2.15.0.417.g466bffb3ac-goog
This is a note to let you know that I've just added the patch titled
fpga: region: release of_parse_phandle nodes after use
to my char-misc git tree which can be found at
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc.git
in the char-misc-next branch.
The patch will show up in the next release of the linux-next tree
(usually sometime within the next 24 hours during the week.)
The patch will also be merged in the next major kernel release
during the merge window.
If you have any questions about this process, please let me know.
>From 0f5eb1545907edeea7672a9c1652c4231150ff22 Mon Sep 17 00:00:00 2001
From: Ian Abbott <abbotti(a)mev.co.uk>
Date: Wed, 15 Nov 2017 16:33:12 -0600
Subject: fpga: region: release of_parse_phandle nodes after use
Both fpga_region_get_manager() and fpga_region_get_bridges() call
of_parse_phandle(), but nothing calls of_node_put() on the returned
struct device_node pointers. Make sure to do that to stop their
reference counters getting out of whack.
Fixes: 0fa20cdfcc1f ("fpga: fpga-region: device tree control for FPGA")
Cc: <stable(a)vger.kernel.org> # 4.10+
Signed-off-by: Ian Abbott <abbotti(a)mev.co.uk>
Signed-off-by: Alan Tull <atull(a)kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/fpga/of-fpga-region.c | 13 ++++++++++---
1 file changed, 10 insertions(+), 3 deletions(-)
diff --git a/drivers/fpga/of-fpga-region.c b/drivers/fpga/of-fpga-region.c
index c6b21194dcbc..119ff75522f1 100644
--- a/drivers/fpga/of-fpga-region.c
+++ b/drivers/fpga/of-fpga-region.c
@@ -73,6 +73,7 @@ static struct fpga_manager *of_fpga_region_get_mgr(struct device_node *np)
mgr_node = of_parse_phandle(np, "fpga-mgr", 0);
if (mgr_node) {
mgr = of_fpga_mgr_get(mgr_node);
+ of_node_put(mgr_node);
of_node_put(np);
return mgr;
}
@@ -120,10 +121,13 @@ static int of_fpga_region_get_bridges(struct fpga_region *region)
parent_br = region_np->parent;
/* If overlay has a list of bridges, use it. */
- if (of_parse_phandle(info->overlay, "fpga-bridges", 0))
+ br = of_parse_phandle(info->overlay, "fpga-bridges", 0);
+ if (br) {
+ of_node_put(br);
np = info->overlay;
- else
+ } else {
np = region_np;
+ }
for (i = 0; ; i++) {
br = of_parse_phandle(np, "fpga-bridges", i);
@@ -131,12 +135,15 @@ static int of_fpga_region_get_bridges(struct fpga_region *region)
break;
/* If parent bridge is in list, skip it. */
- if (br == parent_br)
+ if (br == parent_br) {
+ of_node_put(br);
continue;
+ }
/* If node is a bridge, get it and add to list */
ret = of_fpga_bridge_get_to_list(br, info,
®ion->bridge_list);
+ of_node_put(br);
/* If any of the bridges are in use, give up */
if (ret == -EBUSY) {
--
2.15.0
This is a note to let you know that I've just added the patch titled
firmware: vpd: Tie firmware kobject to device lifetime
to my char-misc git tree which can be found at
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc.git
in the char-misc-linus branch.
The patch will show up in the next release of the linux-next tree
(usually sometime within the next 24 hours during the week.)
The patch will hopefully also be merged in Linus's tree for the
next -rc kernel release.
If you have any questions about this process, please let me know.
>From e4b28b3c3a405b251fa25db58abe1512814a680a Mon Sep 17 00:00:00 2001
From: Guenter Roeck <linux(a)roeck-us.net>
Date: Wed, 15 Nov 2017 13:00:44 -0800
Subject: firmware: vpd: Tie firmware kobject to device lifetime
It doesn't make sense to have /sys/firmware/vpd if the device is not
instantiated, so tie its lifetime to the device.
Fixes: 049a59db34eb ("firmware: Google VPD sysfs driver")
Signed-off-by: Guenter Roeck <linux(a)roeck-us.net>
Cc: stable <stable(a)vger.kernel.org>
Reviewed-by: Dmitry Torokhov <dmitry.torokhov(a)gmail.com>
Tested-by: Randy Dunlap <rdunlap(a)infradead.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/firmware/google/vpd.c | 19 +++++++++++++------
1 file changed, 13 insertions(+), 6 deletions(-)
diff --git a/drivers/firmware/google/vpd.c b/drivers/firmware/google/vpd.c
index 84217172297b..942e358efa60 100644
--- a/drivers/firmware/google/vpd.c
+++ b/drivers/firmware/google/vpd.c
@@ -295,7 +295,17 @@ static int vpd_probe(struct platform_device *pdev)
if (ret)
return ret;
- return vpd_sections_init(entry.cbmem_addr);
+ vpd_kobj = kobject_create_and_add("vpd", firmware_kobj);
+ if (!vpd_kobj)
+ return -ENOMEM;
+
+ ret = vpd_sections_init(entry.cbmem_addr);
+ if (ret) {
+ kobject_put(vpd_kobj);
+ return ret;
+ }
+
+ return 0;
}
static int vpd_remove(struct platform_device *pdev)
@@ -303,6 +313,8 @@ static int vpd_remove(struct platform_device *pdev)
vpd_section_destroy(&ro_vpd);
vpd_section_destroy(&rw_vpd);
+ kobject_put(vpd_kobj);
+
return 0;
}
@@ -322,10 +334,6 @@ static int __init vpd_platform_init(void)
if (IS_ERR(pdev))
return PTR_ERR(pdev);
- vpd_kobj = kobject_create_and_add("vpd", firmware_kobj);
- if (!vpd_kobj)
- return -ENOMEM;
-
platform_driver_register(&vpd_driver);
return 0;
@@ -333,7 +341,6 @@ static int __init vpd_platform_init(void)
static void __exit vpd_platform_exit(void)
{
- kobject_put(vpd_kobj);
}
module_init(vpd_platform_init);
--
2.15.0
This is a note to let you know that I've just added the patch titled
firmware: vpd: Fix platform driver and device
to my char-misc git tree which can be found at
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc.git
in the char-misc-linus branch.
The patch will show up in the next release of the linux-next tree
(usually sometime within the next 24 hours during the week.)
The patch will hopefully also be merged in Linus's tree for the
next -rc kernel release.
If you have any questions about this process, please let me know.
>From 0631fb8b027f5968c2f5031f0b3ff7be3e4bebcc Mon Sep 17 00:00:00 2001
From: Guenter Roeck <linux(a)roeck-us.net>
Date: Wed, 15 Nov 2017 13:00:45 -0800
Subject: firmware: vpd: Fix platform driver and device
registration/unregistration
The driver exit function needs to unregister both platform device and
driver. Also, during registration, register driver first and perform
error checks.
Fixes: 049a59db34eb ("firmware: Google VPD sysfs driver")
Signed-off-by: Guenter Roeck <linux(a)roeck-us.net>
Cc: stable <stable(a)vger.kernel.org>
Tested-by: Randy Dunlap <rdunlap(a)infradead.org>
Reviewed-by: Dmitry Torokhov <dmitry.torokhov(a)gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/firmware/google/vpd.c | 18 +++++++++++++-----
1 file changed, 13 insertions(+), 5 deletions(-)
diff --git a/drivers/firmware/google/vpd.c b/drivers/firmware/google/vpd.c
index 942e358efa60..e4b40f2b4627 100644
--- a/drivers/firmware/google/vpd.c
+++ b/drivers/firmware/google/vpd.c
@@ -326,21 +326,29 @@ static struct platform_driver vpd_driver = {
},
};
+static struct platform_device *vpd_pdev;
+
static int __init vpd_platform_init(void)
{
- struct platform_device *pdev;
+ int ret;
- pdev = platform_device_register_simple("vpd", -1, NULL, 0);
- if (IS_ERR(pdev))
- return PTR_ERR(pdev);
+ ret = platform_driver_register(&vpd_driver);
+ if (ret)
+ return ret;
- platform_driver_register(&vpd_driver);
+ vpd_pdev = platform_device_register_simple("vpd", -1, NULL, 0);
+ if (IS_ERR(vpd_pdev)) {
+ platform_driver_unregister(&vpd_driver);
+ return PTR_ERR(vpd_pdev);
+ }
return 0;
}
static void __exit vpd_platform_exit(void)
{
+ platform_device_unregister(vpd_pdev);
+ platform_driver_unregister(&vpd_driver);
}
module_init(vpd_platform_init);
--
2.15.0
This is a note to let you know that I've just added the patch titled
firmware: vpd: Destroy vpd sections in remove function
to my char-misc git tree which can be found at
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc.git
in the char-misc-linus branch.
The patch will show up in the next release of the linux-next tree
(usually sometime within the next 24 hours during the week.)
The patch will hopefully also be merged in Linus's tree for the
next -rc kernel release.
If you have any questions about this process, please let me know.
>From 811d7e0215fb738fb9a9f0bcb1276516ad161ed1 Mon Sep 17 00:00:00 2001
From: Guenter Roeck <linux(a)roeck-us.net>
Date: Wed, 15 Nov 2017 13:00:43 -0800
Subject: firmware: vpd: Destroy vpd sections in remove function
vpd sections are initialized during probe and thus should be destroyed
in the remove function.
Fixes: 049a59db34eb ("firmware: Google VPD sysfs driver")
Cc: stable <stable(a)vger.kernel.org>
Signed-off-by: Guenter Roeck <linux(a)roeck-us.net>
Reviewed-by: Dmitry Torokhov <dmitry.torokhov(a)gmail.com>
Tested-by: Randy Dunlap <rdunlap(a)infradead.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/firmware/google/vpd.c | 11 +++++++++--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/drivers/firmware/google/vpd.c b/drivers/firmware/google/vpd.c
index 35e553b3b190..84217172297b 100644
--- a/drivers/firmware/google/vpd.c
+++ b/drivers/firmware/google/vpd.c
@@ -298,8 +298,17 @@ static int vpd_probe(struct platform_device *pdev)
return vpd_sections_init(entry.cbmem_addr);
}
+static int vpd_remove(struct platform_device *pdev)
+{
+ vpd_section_destroy(&ro_vpd);
+ vpd_section_destroy(&rw_vpd);
+
+ return 0;
+}
+
static struct platform_driver vpd_driver = {
.probe = vpd_probe,
+ .remove = vpd_remove,
.driver = {
.name = "vpd",
},
@@ -324,8 +333,6 @@ static int __init vpd_platform_init(void)
static void __exit vpd_platform_exit(void)
{
- vpd_section_destroy(&ro_vpd);
- vpd_section_destroy(&rw_vpd);
kobject_put(vpd_kobj);
}
--
2.15.0
This is a note to let you know that I've just added the patch titled
ANDROID: binder: fix transaction leak.
to my char-misc git tree which can be found at
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc.git
in the char-misc-linus branch.
The patch will show up in the next release of the linux-next tree
(usually sometime within the next 24 hours during the week.)
The patch will hopefully also be merged in Linus's tree for the
next -rc kernel release.
If you have any questions about this process, please let me know.
>From fb2c445277e7b0b4ffe10de8114bad4eccaca948 Mon Sep 17 00:00:00 2001
From: Martijn Coenen <maco(a)android.com>
Date: Mon, 13 Nov 2017 10:06:08 +0100
Subject: ANDROID: binder: fix transaction leak.
If a call to put_user() fails, we failed to
properly free a transaction and send a failed
reply (if necessary).
Signed-off-by: Martijn Coenen <maco(a)android.com>
Cc: stable <stable(a)vger.kernel.org> # 4.14
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/android/binder.c | 40 +++++++++++++++++++++++++++++++---------
1 file changed, 31 insertions(+), 9 deletions(-)
diff --git a/drivers/android/binder.c b/drivers/android/binder.c
index a73596a4f804..bccec9de0533 100644
--- a/drivers/android/binder.c
+++ b/drivers/android/binder.c
@@ -1947,6 +1947,26 @@ static void binder_send_failed_reply(struct binder_transaction *t,
}
}
+/**
+ * binder_cleanup_transaction() - cleans up undelivered transaction
+ * @t: transaction that needs to be cleaned up
+ * @reason: reason the transaction wasn't delivered
+ * @error_code: error to return to caller (if synchronous call)
+ */
+static void binder_cleanup_transaction(struct binder_transaction *t,
+ const char *reason,
+ uint32_t error_code)
+{
+ if (t->buffer->target_node && !(t->flags & TF_ONE_WAY)) {
+ binder_send_failed_reply(t, error_code);
+ } else {
+ binder_debug(BINDER_DEBUG_DEAD_TRANSACTION,
+ "undelivered transaction %d, %s\n",
+ t->debug_id, reason);
+ binder_free_transaction(t);
+ }
+}
+
/**
* binder_validate_object() - checks for a valid metadata object in a buffer.
* @buffer: binder_buffer that we're parsing.
@@ -4015,12 +4035,20 @@ static int binder_thread_read(struct binder_proc *proc,
if (put_user(cmd, (uint32_t __user *)ptr)) {
if (t_from)
binder_thread_dec_tmpref(t_from);
+
+ binder_cleanup_transaction(t, "put_user failed",
+ BR_FAILED_REPLY);
+
return -EFAULT;
}
ptr += sizeof(uint32_t);
if (copy_to_user(ptr, &tr, sizeof(tr))) {
if (t_from)
binder_thread_dec_tmpref(t_from);
+
+ binder_cleanup_transaction(t, "copy_to_user failed",
+ BR_FAILED_REPLY);
+
return -EFAULT;
}
ptr += sizeof(tr);
@@ -4090,15 +4118,9 @@ static void binder_release_work(struct binder_proc *proc,
struct binder_transaction *t;
t = container_of(w, struct binder_transaction, work);
- if (t->buffer->target_node &&
- !(t->flags & TF_ONE_WAY)) {
- binder_send_failed_reply(t, BR_DEAD_REPLY);
- } else {
- binder_debug(BINDER_DEBUG_DEAD_TRANSACTION,
- "undelivered transaction %d\n",
- t->debug_id);
- binder_free_transaction(t);
- }
+
+ binder_cleanup_transaction(t, "process died.",
+ BR_DEAD_REPLY);
} break;
case BINDER_WORK_RETURN_ERROR: {
struct binder_error *e = container_of(
--
2.15.0
This is a note to let you know that I've just added the patch titled
MIPS: Add custom serial.h with BASE_BAUD override for generic kernel
to my tty git tree which can be found at
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty.git
in the tty-linus branch.
The patch will show up in the next release of the linux-next tree
(usually sometime within the next 24 hours during the week.)
The patch will hopefully also be merged in Linus's tree for the
next -rc kernel release.
If you have any questions about this process, please let me know.
>From c8ec2041f549e7f2dee0c34d25381be6f7805f99 Mon Sep 17 00:00:00 2001
From: Matt Redfearn <matt.redfearn(a)mips.com>
Date: Tue, 28 Nov 2017 15:22:20 +0000
Subject: MIPS: Add custom serial.h with BASE_BAUD override for generic kernel
Add a custom serial.h header for MIPS, allowing platforms to override
the asm-generic version if required.
The generic platform uses this header to set BASE_BAUD to 0. The
generic platform supports multiple boards, which may have different
UART clocks. Also one of the boards supported is the Boston FPGA board,
where the UART clock depends on the loaded FPGA bitfile. As such there
is no way that the generic kernel can set a compile time default
BASE_BAUD.
Commit 31cb9a8575ca ("earlycon: initialise baud field of earlycon device
structure") changed the behavior of of_setup_earlycon such that any baud
rate set in the device tree is now set in the earlycon structure. The
UART driver will then calculate a divisor based on BASE_BAUD and set it.
With MIPS generic kernels this resulted in garbage output due to the
incorrect uart clock rate being used to calculate a divisor. This
commit, combined with "serial: 8250_early: Only set divisor if valid clk
& baud" prevents the earlycon code setting a bad divisor and restores
earlycon output.
Fixes: 31cb9a8575ca ("earlycon: initialise baud field of earlycon device structure")
Cc: stable <stable(a)vger.kernel.org> # 4.14
Signed-off-by: Matt Redfearn <matt.redfearn(a)mips.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/mips/include/asm/Kbuild | 1 -
arch/mips/include/asm/serial.h | 22 ++++++++++++++++++++++
2 files changed, 22 insertions(+), 1 deletion(-)
create mode 100644 arch/mips/include/asm/serial.h
diff --git a/arch/mips/include/asm/Kbuild b/arch/mips/include/asm/Kbuild
index 7c8aab23bce8..b1f66699677d 100644
--- a/arch/mips/include/asm/Kbuild
+++ b/arch/mips/include/asm/Kbuild
@@ -16,7 +16,6 @@ generic-y += qrwlock.h
generic-y += qspinlock.h
generic-y += sections.h
generic-y += segment.h
-generic-y += serial.h
generic-y += trace_clock.h
generic-y += unaligned.h
generic-y += user.h
diff --git a/arch/mips/include/asm/serial.h b/arch/mips/include/asm/serial.h
new file mode 100644
index 000000000000..1d830c6666c2
--- /dev/null
+++ b/arch/mips/include/asm/serial.h
@@ -0,0 +1,22 @@
+/*
+ * Copyright (C) 2017 MIPS Tech, LLC
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ */
+#ifndef __ASM__SERIAL_H
+#define __ASM__SERIAL_H
+
+#ifdef CONFIG_MIPS_GENERIC
+/*
+ * Generic kernels cannot know a correct value for all platforms at
+ * compile time. Set it to 0 to prevent 8250_early using it
+ */
+#define BASE_BAUD 0
+#else
+#include <asm-generic/serial.h>
+#endif
+
+#endif /* __ASM__SERIAL_H */
--
2.15.0
This is a note to let you know that I've just added the patch titled
firmware: cleanup FIRMWARE_IN_KERNEL message
to my driver-core git tree which can be found at
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core.git
in the driver-core-linus branch.
The patch will show up in the next release of the linux-next tree
(usually sometime within the next 24 hours during the week.)
The patch will hopefully also be merged in Linus's tree for the
next -rc kernel release.
If you have any questions about this process, please let me know.
>From 0946b2fb38fdb6585a5ac3ca84ac73924f645952 Mon Sep 17 00:00:00 2001
From: "Robin H. Johnson" <robbat2(a)gentoo.org>
Date: Thu, 16 Nov 2017 14:36:12 -0800
Subject: firmware: cleanup FIRMWARE_IN_KERNEL message
The help for FIRMWARE_IN_KERNEL still references the firmware_install
command that was recently removed by commit 5620a0d1aacd ("firmware:
delete in-kernel firmware").
Clean up the message to direct the user to their distribution's
linux-firmware package, and remove any reference to firmware being
included in the kernel source tree.
Fixes: 5620a0d1aacd ("firmware: delete in-kernel firmware").
Cc: Masahiro Yamada <yamada.masahiro(a)socionext.com>
Cc: stable <stable(a)vger.kernel.org>
Cc: David Woodhouse <dwmw2(a)infradead.org>
Signed-off-by: Robin H. Johnson <robbat2(a)gentoo.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/base/Kconfig | 25 +++++++++++++------------
1 file changed, 13 insertions(+), 12 deletions(-)
diff --git a/drivers/base/Kconfig b/drivers/base/Kconfig
index 2f6614c9a229..bdc87907d6a1 100644
--- a/drivers/base/Kconfig
+++ b/drivers/base/Kconfig
@@ -91,22 +91,23 @@ config FIRMWARE_IN_KERNEL
depends on FW_LOADER
default y
help
- The kernel source tree includes a number of firmware 'blobs'
- that are used by various drivers. The recommended way to
- use these is to run "make firmware_install", which, after
- converting ihex files to binary, copies all of the needed
- binary files in firmware/ to /lib/firmware/ on your system so
- that they can be loaded by userspace helpers on request.
+ Various drivers in the kernel source tree may require firmware,
+ which is generally available in your distribution's linux-firmware
+ package.
+
+ The linux-firmware package should install firmware into
+ /lib/firmware/ on your system, so they can be loaded by userspace
+ helpers on request.
Enabling this option will build each required firmware blob
- into the kernel directly, where request_firmware() will find
- them without having to call out to userspace. This may be
- useful if your root file system requires a device that uses
- such firmware and do not wish to use an initrd.
+ specified by EXTRA_FIRMWARE into the kernel directly, where
+ request_firmware() will find them without having to call out to
+ userspace. This may be useful if your root file system requires a
+ device that uses such firmware and you do not wish to use an
+ initrd.
This single option controls the inclusion of firmware for
- every driver that uses request_firmware() and ships its
- firmware in the kernel source tree, which avoids a
+ every driver that uses request_firmware(), which avoids a
proliferation of 'Include firmware for xxx device' options.
Say 'N' and let firmware be loaded from userspace.
--
2.15.0
This is a note to let you know that I've just added the patch titled
isa: Prevent NULL dereference in isa_bus driver callbacks
to my driver-core git tree which can be found at
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core.git
in the driver-core-linus branch.
The patch will show up in the next release of the linux-next tree
(usually sometime within the next 24 hours during the week.)
The patch will hopefully also be merged in Linus's tree for the
next -rc kernel release.
If you have any questions about this process, please let me know.
>From 5a244727f428a06634f22bb890e78024ab0c89f3 Mon Sep 17 00:00:00 2001
From: William Breathitt Gray <vilhelm.gray(a)gmail.com>
Date: Wed, 8 Nov 2017 10:23:11 -0500
Subject: isa: Prevent NULL dereference in isa_bus driver callbacks
The isa_driver structure for an isa_bus device is stored in the device
platform_data member of the respective device structure. This
platform_data member may be reset to NULL if isa_driver match callback
for the device fails, indicating a device unsupported by the ISA driver.
This patch fixes a possible NULL pointer dereference if one of the
isa_driver callbacks to attempted for an unsupported device. This error
should not occur in practice since ISA devices are typically manually
configured and loaded by the users, but we may as well prevent this
error from popping up for the 0day testers.
Fixes: a5117ba7da37 ("[PATCH] Driver model: add ISA bus")
Signed-off-by: William Breathitt Gray <vilhelm.gray(a)gmail.com>
Cc: stable <stable(a)vger.kernel.org>
Acked-by: Linus Torvalds <torvalds(a)linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/base/isa.c | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/base/isa.c b/drivers/base/isa.c
index cd6ccdcf9df0..372d10af2600 100644
--- a/drivers/base/isa.c
+++ b/drivers/base/isa.c
@@ -39,7 +39,7 @@ static int isa_bus_probe(struct device *dev)
{
struct isa_driver *isa_driver = dev->platform_data;
- if (isa_driver->probe)
+ if (isa_driver && isa_driver->probe)
return isa_driver->probe(dev, to_isa_dev(dev)->id);
return 0;
@@ -49,7 +49,7 @@ static int isa_bus_remove(struct device *dev)
{
struct isa_driver *isa_driver = dev->platform_data;
- if (isa_driver->remove)
+ if (isa_driver && isa_driver->remove)
return isa_driver->remove(dev, to_isa_dev(dev)->id);
return 0;
@@ -59,7 +59,7 @@ static void isa_bus_shutdown(struct device *dev)
{
struct isa_driver *isa_driver = dev->platform_data;
- if (isa_driver->shutdown)
+ if (isa_driver && isa_driver->shutdown)
isa_driver->shutdown(dev, to_isa_dev(dev)->id);
}
@@ -67,7 +67,7 @@ static int isa_bus_suspend(struct device *dev, pm_message_t state)
{
struct isa_driver *isa_driver = dev->platform_data;
- if (isa_driver->suspend)
+ if (isa_driver && isa_driver->suspend)
return isa_driver->suspend(dev, to_isa_dev(dev)->id, state);
return 0;
@@ -77,7 +77,7 @@ static int isa_bus_resume(struct device *dev)
{
struct isa_driver *isa_driver = dev->platform_data;
- if (isa_driver->resume)
+ if (isa_driver && isa_driver->resume)
return isa_driver->resume(dev, to_isa_dev(dev)->id);
return 0;
--
2.15.0
This is a note to let you know that I've just added the patch titled
fpga: region: release of_parse_phandle nodes after use
to my char-misc git tree which can be found at
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc.git
in the char-misc-testing branch.
The patch will show up in the next release of the linux-next tree
(usually sometime within the next 24 hours during the week.)
The patch will be merged to the char-misc-next branch sometime soon,
after it passes testing, and the merge window is open.
If you have any questions about this process, please let me know.
>From 0f5eb1545907edeea7672a9c1652c4231150ff22 Mon Sep 17 00:00:00 2001
From: Ian Abbott <abbotti(a)mev.co.uk>
Date: Wed, 15 Nov 2017 16:33:12 -0600
Subject: fpga: region: release of_parse_phandle nodes after use
Both fpga_region_get_manager() and fpga_region_get_bridges() call
of_parse_phandle(), but nothing calls of_node_put() on the returned
struct device_node pointers. Make sure to do that to stop their
reference counters getting out of whack.
Fixes: 0fa20cdfcc1f ("fpga: fpga-region: device tree control for FPGA")
Cc: <stable(a)vger.kernel.org> # 4.10+
Signed-off-by: Ian Abbott <abbotti(a)mev.co.uk>
Signed-off-by: Alan Tull <atull(a)kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/fpga/of-fpga-region.c | 13 ++++++++++---
1 file changed, 10 insertions(+), 3 deletions(-)
diff --git a/drivers/fpga/of-fpga-region.c b/drivers/fpga/of-fpga-region.c
index c6b21194dcbc..119ff75522f1 100644
--- a/drivers/fpga/of-fpga-region.c
+++ b/drivers/fpga/of-fpga-region.c
@@ -73,6 +73,7 @@ static struct fpga_manager *of_fpga_region_get_mgr(struct device_node *np)
mgr_node = of_parse_phandle(np, "fpga-mgr", 0);
if (mgr_node) {
mgr = of_fpga_mgr_get(mgr_node);
+ of_node_put(mgr_node);
of_node_put(np);
return mgr;
}
@@ -120,10 +121,13 @@ static int of_fpga_region_get_bridges(struct fpga_region *region)
parent_br = region_np->parent;
/* If overlay has a list of bridges, use it. */
- if (of_parse_phandle(info->overlay, "fpga-bridges", 0))
+ br = of_parse_phandle(info->overlay, "fpga-bridges", 0);
+ if (br) {
+ of_node_put(br);
np = info->overlay;
- else
+ } else {
np = region_np;
+ }
for (i = 0; ; i++) {
br = of_parse_phandle(np, "fpga-bridges", i);
@@ -131,12 +135,15 @@ static int of_fpga_region_get_bridges(struct fpga_region *region)
break;
/* If parent bridge is in list, skip it. */
- if (br == parent_br)
+ if (br == parent_br) {
+ of_node_put(br);
continue;
+ }
/* If node is a bridge, get it and add to list */
ret = of_fpga_bridge_get_to_list(br, info,
®ion->bridge_list);
+ of_node_put(br);
/* If any of the bridges are in use, give up */
if (ret == -EBUSY) {
--
2.15.0
Add a custom serial.h header for MIPS, allowing platforms to override
the asm-generic version if required.
The generic platform uses this header to set BASE_BAUD to 0. The
generic platform supports multiple boards, which may have different
UART clocks. Also one of the boards supported is the Boston FPGA board,
where the UART clock depends on the loaded FPGA bitfile. As such there
is no way that the generic kernel can set a compile time default
BASE_BAUD.
Commit 31cb9a8575ca ("earlycon: initialise baud field of earlycon device
structure") changed the behavior of of_setup_earlycon such that any baud
rate set in the device tree is now set in the earlycon structure. The
UART driver will then calculate a divisor based on BASE_BAUD and set it.
With MIPS generic kernels this resulted in garbage output due to the
incorrect uart clock rate being used to calculate a divisor. This
commit, combined with "serial: 8250_early: Only set divisor if valid clk
& baud" prevents the earlycon code setting a bad divisor and restores
earlycon output.
Fixes: 31cb9a8575ca ("earlycon: initialise baud field of earlycon device structure")
Cc: stable <stable(a)vger.kernel.org> # 4.14
Signed-off-by: Matt Redfearn <matt.redfearn(a)mips.com>
---
Changes in v2:
GPL v2
arch/mips/include/asm/Kbuild | 1 -
arch/mips/include/asm/serial.h | 22 ++++++++++++++++++++++
2 files changed, 22 insertions(+), 1 deletion(-)
create mode 100644 arch/mips/include/asm/serial.h
diff --git a/arch/mips/include/asm/Kbuild b/arch/mips/include/asm/Kbuild
index 7c8aab23bce8..b1f66699677d 100644
--- a/arch/mips/include/asm/Kbuild
+++ b/arch/mips/include/asm/Kbuild
@@ -16,7 +16,6 @@ generic-y += qrwlock.h
generic-y += qspinlock.h
generic-y += sections.h
generic-y += segment.h
-generic-y += serial.h
generic-y += trace_clock.h
generic-y += unaligned.h
generic-y += user.h
diff --git a/arch/mips/include/asm/serial.h b/arch/mips/include/asm/serial.h
new file mode 100644
index 000000000000..1d830c6666c2
--- /dev/null
+++ b/arch/mips/include/asm/serial.h
@@ -0,0 +1,22 @@
+/*
+ * Copyright (C) 2017 MIPS Tech, LLC
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ */
+#ifndef __ASM__SERIAL_H
+#define __ASM__SERIAL_H
+
+#ifdef CONFIG_MIPS_GENERIC
+/*
+ * Generic kernels cannot know a correct value for all platforms at
+ * compile time. Set it to 0 to prevent 8250_early using it
+ */
+#define BASE_BAUD 0
+#else
+#include <asm-generic/serial.h>
+#endif
+
+#endif /* __ASM__SERIAL_H */
--
2.7.4
If either uartclk or baud are 0, avoid calculating and setting a divisor
based on them since the output will almost certainly be garbage.
This also allows platforms such as the MIPS generic kernel, which has no
way to know a valid BASE_BASE for the board it is actually booted on at
compile time, to set BASE_BAUD to 0 and avoid early_8250 setting a bad
divisor.
This fixes a regression caused by commit 31cb9a8575ca ("earlycon:
initialise baud field of earlycon device structure"), which changed the
behavior of of_setup_earlycon such that it sets a baud rate in the
earlycon structure where previously it was left as 0. All boards
supported by the MIPS generic kernel started outputting garbage from the
boot console due to an incorrect divisor being set.
Fixes: 31cb9a8575ca ("earlycon: initialise baud field of earlycon device structure")
Cc: stable <stable(a)vger.kernel.org> # 4.14
Signed-off-by: Matt Redfearn <matt.redfearn(a)mips.com>
---
drivers/tty/serial/8250/8250_early.c | 14 ++++++++------
1 file changed, 8 insertions(+), 6 deletions(-)
diff --git a/drivers/tty/serial/8250/8250_early.c b/drivers/tty/serial/8250/8250_early.c
index af72ec32e404..f135c1846477 100644
--- a/drivers/tty/serial/8250/8250_early.c
+++ b/drivers/tty/serial/8250/8250_early.c
@@ -125,12 +125,14 @@ static void __init init_port(struct earlycon_device *device)
serial8250_early_out(port, UART_FCR, 0); /* no fifo */
serial8250_early_out(port, UART_MCR, 0x3); /* DTR + RTS */
- divisor = DIV_ROUND_CLOSEST(port->uartclk, 16 * device->baud);
- c = serial8250_early_in(port, UART_LCR);
- serial8250_early_out(port, UART_LCR, c | UART_LCR_DLAB);
- serial8250_early_out(port, UART_DLL, divisor & 0xff);
- serial8250_early_out(port, UART_DLM, (divisor >> 8) & 0xff);
- serial8250_early_out(port, UART_LCR, c & ~UART_LCR_DLAB);
+ if (port->uartclk && device->baud) {
+ divisor = DIV_ROUND_CLOSEST(port->uartclk, 16 * device->baud);
+ c = serial8250_early_in(port, UART_LCR);
+ serial8250_early_out(port, UART_LCR, c | UART_LCR_DLAB);
+ serial8250_early_out(port, UART_DLL, divisor & 0xff);
+ serial8250_early_out(port, UART_DLM, (divisor >> 8) & 0xff);
+ serial8250_early_out(port, UART_LCR, c & ~UART_LCR_DLAB);
+ }
}
int __init early_serial8250_setup(struct earlycon_device *device,
--
2.7.4
On Thu, Nov 23, 2017 at 09:55:37AM +0100, Milian Wolff wrote:
>On Wednesday, November 22, 2017 11:25:40 PM CET alexander.levin(a)verizon.com
>wrote:
>> From: Milian Wolff <milian.wolff(a)kdab.com>
>>
>> [ Upstream commit 9856240ad3269f2fdab0b2fa4400ef8aab792061 ]
>
>Hello Alexander,
>
>this is the first time I encounter AUTOSEL. I just want to check: The patch
>below depends on others in a whole series that reworks the handling of inline
>frames. Why is only this one getting selected? I don't even think it can work
>stand-alone?
AUTOSEL just means that it was automatically selected, but I reviewed
it before sending.
Thanks for the comments, I'll drop the patch.
--
Thanks,
Sasha
This is a note to let you know that I've just added the patch titled
serdev: ttyport: fix tty locking in close
to my tty git tree which can be found at
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty.git
in the tty-linus branch.
The patch will show up in the next release of the linux-next tree
(usually sometime within the next 24 hours during the week.)
The patch will hopefully also be merged in Linus's tree for the
next -rc kernel release.
If you have any questions about this process, please let me know.
>From 90dbad8cd6efccbdce109d5ef0724f8434a6cdde Mon Sep 17 00:00:00 2001
From: Johan Hovold <johan(a)kernel.org>
Date: Fri, 3 Nov 2017 15:30:56 +0100
Subject: serdev: ttyport: fix tty locking in close
Make sure to hold the tty lock as required when calling tty-driver
close() (e.g. to avoid racing with hangup()).
Note that the serport active flag is currently set under the lock at
controller open, but really isn't protected by it.
Fixes: cd6484e1830b ("serdev: Introduce new bus for serial attached devices")
Signed-off-by: Johan Hovold <johan(a)kernel.org>
Cc: stable <stable(a)vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/tty/serdev/serdev-ttyport.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/tty/serdev/serdev-ttyport.c b/drivers/tty/serdev/serdev-ttyport.c
index 12cb9139073e..247788a16f0b 100644
--- a/drivers/tty/serdev/serdev-ttyport.c
+++ b/drivers/tty/serdev/serdev-ttyport.c
@@ -154,8 +154,10 @@ static void ttyport_close(struct serdev_controller *ctrl)
clear_bit(SERPORT_ACTIVE, &serport->flags);
+ tty_lock(tty);
if (tty->ops->close)
tty->ops->close(tty, NULL);
+ tty_unlock(tty);
tty_release_struct(tty, serport->tty_idx);
}
--
2.15.0
This is a note to let you know that I've just added the patch titled
serdev: ttyport: fix NULL-deref on hangup
to my tty git tree which can be found at
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty.git
in the tty-linus branch.
The patch will show up in the next release of the linux-next tree
(usually sometime within the next 24 hours during the week.)
The patch will hopefully also be merged in Linus's tree for the
next -rc kernel release.
If you have any questions about this process, please let me know.
>From 8bcd4e6a8decac251d55c4377e2e67f052777ce0 Mon Sep 17 00:00:00 2001
From: Johan Hovold <johan(a)kernel.org>
Date: Fri, 3 Nov 2017 15:30:55 +0100
Subject: serdev: ttyport: fix NULL-deref on hangup
Make sure to use a properly refcounted tty_struct in write_wake up to
avoid dereferencing a NULL-pointer when a port is being hung up.
Fixes: bed35c6dfa6a ("serdev: add a tty port controller driver")
Cc: stable <stable(a)vger.kernel.org> # 4.11
Signed-off-by: Johan Hovold <johan(a)kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/tty/serdev/serdev-ttyport.c | 11 +++++++++--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/drivers/tty/serdev/serdev-ttyport.c b/drivers/tty/serdev/serdev-ttyport.c
index 09fbdd52a561..12cb9139073e 100644
--- a/drivers/tty/serdev/serdev-ttyport.c
+++ b/drivers/tty/serdev/serdev-ttyport.c
@@ -49,12 +49,19 @@ static void ttyport_write_wakeup(struct tty_port *port)
{
struct serdev_controller *ctrl = port->client_data;
struct serport *serport = serdev_controller_get_drvdata(ctrl);
+ struct tty_struct *tty;
+
+ tty = tty_port_tty_get(port);
+ if (!tty)
+ return;
- if (test_and_clear_bit(TTY_DO_WRITE_WAKEUP, &port->tty->flags) &&
+ if (test_and_clear_bit(TTY_DO_WRITE_WAKEUP, &tty->flags) &&
test_bit(SERPORT_ACTIVE, &serport->flags))
serdev_controller_write_wakeup(ctrl);
- wake_up_interruptible_poll(&port->tty->write_wait, POLLOUT);
+ wake_up_interruptible_poll(&tty->write_wait, POLLOUT);
+
+ tty_kref_put(tty);
}
static const struct tty_port_client_operations client_ops = {
--
2.15.0
This is a note to let you know that I've just added the patch titled
serdev: ttyport: add missing receive_buf sanity checks
to my tty git tree which can be found at
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty.git
in the tty-linus branch.
The patch will show up in the next release of the linux-next tree
(usually sometime within the next 24 hours during the week.)
The patch will hopefully also be merged in Linus's tree for the
next -rc kernel release.
If you have any questions about this process, please let me know.
>From eb281683621b71ab9710d9dccbbef0c2e1769c97 Mon Sep 17 00:00:00 2001
From: Johan Hovold <johan(a)kernel.org>
Date: Fri, 3 Nov 2017 15:30:52 +0100
Subject: serdev: ttyport: add missing receive_buf sanity checks
The receive_buf tty-port callback should return the number of bytes
accepted and must specifically never return a negative errno (or a value
larger than the buffer size) to the tty layer.
A serdev driver not providing a receive_buf callback would currently
cause the flush_to_ldisc() worker to spin in a tight loop when the tty
buffer pointers are incremented with -EINVAL (-22) after data has been
received.
A serdev driver occasionally returning a negative errno (or a too large
byte count) could cause information leaks or crashes when accessing
memory outside the tty buffers in consecutive callbacks.
Fixes: cd6484e1830b ("serdev: Introduce new bus for serial attached devices")
Cc: stable <stable(a)vger.kernel.org> # 4.11
Signed-off-by: Johan Hovold <johan(a)kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/tty/serdev/serdev-ttyport.c | 13 ++++++++++++-
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/drivers/tty/serdev/serdev-ttyport.c b/drivers/tty/serdev/serdev-ttyport.c
index ce7ad0acee7a..09fbdd52a561 100644
--- a/drivers/tty/serdev/serdev-ttyport.c
+++ b/drivers/tty/serdev/serdev-ttyport.c
@@ -27,11 +27,22 @@ static int ttyport_receive_buf(struct tty_port *port, const unsigned char *cp,
{
struct serdev_controller *ctrl = port->client_data;
struct serport *serport = serdev_controller_get_drvdata(ctrl);
+ int ret;
if (!test_bit(SERPORT_ACTIVE, &serport->flags))
return 0;
- return serdev_controller_receive_buf(ctrl, cp, count);
+ ret = serdev_controller_receive_buf(ctrl, cp, count);
+
+ dev_WARN_ONCE(&ctrl->dev, ret < 0 || ret > count,
+ "receive_buf returns %d (count = %zu)\n",
+ ret, count);
+ if (ret < 0)
+ return 0;
+ else if (ret > count)
+ return count;
+
+ return ret;
}
static void ttyport_write_wakeup(struct tty_port *port)
--
2.15.0
This is a note to let you know that I've just added the patch titled
serial: 8250_early: Only set divisor if valid clk & baud
to my tty git tree which can be found at
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty.git
in the tty-linus branch.
The patch will show up in the next release of the linux-next tree
(usually sometime within the next 24 hours during the week.)
The patch will hopefully also be merged in Linus's tree for the
next -rc kernel release.
If you have any questions about this process, please let me know.
>From 0ff3ab701963a845d52337ded7eebf2d1a14fe00 Mon Sep 17 00:00:00 2001
From: Matt Redfearn <matt.redfearn(a)mips.com>
Date: Wed, 22 Nov 2017 09:57:28 +0000
Subject: serial: 8250_early: Only set divisor if valid clk & baud
If either uartclk or baud are 0, avoid calculating and setting a divisor
based on them since the output will almost certainly be garbage.
This also allows platforms such as the MIPS generic kernel, which has no
way to know a valid BASE_BASE for the board it is actually booted on at
compile time, to set BASE_BAUD to 0 and avoid early_8250 setting a bad
divisor.
This fixes a regression caused by commit 31cb9a8575ca ("earlycon:
initialise baud field of earlycon device structure"), which changed the
behavior of of_setup_earlycon such that it sets a baud rate in the
earlycon structure where previously it was left as 0. All boards
supported by the MIPS generic kernel started outputting garbage from the
boot console due to an incorrect divisor being set.
Fixes: 31cb9a8575ca ("earlycon: initialise baud field of earlycon device structure")
Cc: stable <stable(a)vger.kernel.org> # 4.14
Signed-off-by: Matt Redfearn <matt.redfearn(a)mips.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/tty/serial/8250/8250_early.c | 14 ++++++++------
1 file changed, 8 insertions(+), 6 deletions(-)
diff --git a/drivers/tty/serial/8250/8250_early.c b/drivers/tty/serial/8250/8250_early.c
index 362c25ff188a..ae6a256524d8 100644
--- a/drivers/tty/serial/8250/8250_early.c
+++ b/drivers/tty/serial/8250/8250_early.c
@@ -122,12 +122,14 @@ static void __init init_port(struct earlycon_device *device)
serial8250_early_out(port, UART_FCR, 0); /* no fifo */
serial8250_early_out(port, UART_MCR, 0x3); /* DTR + RTS */
- divisor = DIV_ROUND_CLOSEST(port->uartclk, 16 * device->baud);
- c = serial8250_early_in(port, UART_LCR);
- serial8250_early_out(port, UART_LCR, c | UART_LCR_DLAB);
- serial8250_early_out(port, UART_DLL, divisor & 0xff);
- serial8250_early_out(port, UART_DLM, (divisor >> 8) & 0xff);
- serial8250_early_out(port, UART_LCR, c & ~UART_LCR_DLAB);
+ if (port->uartclk && device->baud) {
+ divisor = DIV_ROUND_CLOSEST(port->uartclk, 16 * device->baud);
+ c = serial8250_early_in(port, UART_LCR);
+ serial8250_early_out(port, UART_LCR, c | UART_LCR_DLAB);
+ serial8250_early_out(port, UART_DLL, divisor & 0xff);
+ serial8250_early_out(port, UART_DLM, (divisor >> 8) & 0xff);
+ serial8250_early_out(port, UART_LCR, c & ~UART_LCR_DLAB);
+ }
}
int __init early_serial8250_setup(struct earlycon_device *device,
--
2.15.0
This is a note to let you know that I've just added the patch titled
serial: 8250_pci: Add Amazon PCI serial device ID
to my tty git tree which can be found at
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty.git
in the tty-linus branch.
The patch will show up in the next release of the linux-next tree
(usually sometime within the next 24 hours during the week.)
The patch will hopefully also be merged in Linus's tree for the
next -rc kernel release.
If you have any questions about this process, please let me know.
>From 3bfd1300abfe3adb18e84a89d97a0e82a22124bb Mon Sep 17 00:00:00 2001
From: Matt Wilson <msw(a)amazon.com>
Date: Mon, 13 Nov 2017 11:31:31 -0800
Subject: serial: 8250_pci: Add Amazon PCI serial device ID
This device will be used in future Amazon EC2 instances as the primary
serial port (i.e., data sent to this port will be available via the
GetConsoleOuput [1] EC2 API).
[1] http://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_GetConsoleOutput.…
Cc: stable <stable(a)vger.kernel.org>
Signed-off-by: Matt Wilson <msw(a)amazon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/tty/serial/8250/8250_pci.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/tty/serial/8250/8250_pci.c b/drivers/tty/serial/8250/8250_pci.c
index b7e0e3416641..54adf8d56350 100644
--- a/drivers/tty/serial/8250/8250_pci.c
+++ b/drivers/tty/serial/8250/8250_pci.c
@@ -5135,6 +5135,9 @@ static const struct pci_device_id serial_pci_tbl[] = {
{ PCI_DEVICE(0x1601, 0x0800), .driver_data = pbn_b0_4_1250000 },
{ PCI_DEVICE(0x1601, 0xa801), .driver_data = pbn_b0_4_1250000 },
+ /* Amazon PCI serial device */
+ { PCI_DEVICE(0x1d0f, 0x8250), .driver_data = pbn_b0_1_115200 },
+
/*
* These entries match devices with class COMMUNICATION_SERIAL,
* COMMUNICATION_MODEM or COMMUNICATION_MULTISERIAL
--
2.15.0
On Tue, Nov 28, 2017 at 03:30:56PM +0100, Paul Kocialkowski wrote:
> I would like to request that the patch with subject:
> ARM: tegra: Select appropriate DMA options for LPAE
> and git commit id 6aa26c5d66595494e810c791602d87a572c78808
> be applied to the stable branches for kernel versions v4.12 and v4.13.
Both of those branches are "end of life", so there's nothing I can do
here, everyone should have already moved to 4.14 by now.
thanks,
greg k-h
Right now we seem to be passing index as "lowerdentry" and origin.dentry
as "upperdentry". IIUC, we should pass these parameters in reversed order
and this looks like a bug.
Fixes: caf70cb2ba5d ("ovl: cleanup orphan index entries")
Cc: <stable(a)vger.kernel.org> #4.13
Signed-off-by: Vivek Goyal <vgoyal(a)redhat.com>
---
fs/overlayfs/namei.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/overlayfs/namei.c b/fs/overlayfs/namei.c
index 625ed8066570..5ef69bc09e0c 100644
--- a/fs/overlayfs/namei.c
+++ b/fs/overlayfs/namei.c
@@ -435,7 +435,7 @@ int ovl_verify_index(struct dentry *index, struct ovl_path *lower,
/* Check if index is orphan and don't warn before cleaning it */
if (d_inode(index)->i_nlink == 1 &&
- ovl_get_nlink(index, origin.dentry, 0) == 0)
+ ovl_get_nlink(origin.dentry, index, 0) == 0)
err = -ENOENT;
dput(origin.dentry);
This is a note to let you know that I've just added the patch titled
usb: quirks: Add no-lpm quirk for KY-688 USB 3.1 Type-C Hub
to my usb git tree which can be found at
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git
in the usb-linus branch.
The patch will show up in the next release of the linux-next tree
(usually sometime within the next 24 hours during the week.)
The patch will hopefully also be merged in Linus's tree for the
next -rc kernel release.
If you have any questions about this process, please let me know.
>From e43a12f1793ae1fe006e26fe9327a8840a92233c Mon Sep 17 00:00:00 2001
From: Kai-Heng Feng <kai.heng.feng(a)canonical.com>
Date: Tue, 14 Nov 2017 01:31:15 -0500
Subject: usb: quirks: Add no-lpm quirk for KY-688 USB 3.1 Type-C Hub
KY-688 USB 3.1 Type-C Hub internally uses a Genesys Logic hub to connect
to Realtek r8153.
Similar to commit ("7496cfe5431f2 usb: quirks: Add no-lpm quirk for Moshi
USB to Ethernet Adapter"), no-lpm can make r8153 ethernet work.
Signed-off-by: Kai-Heng Feng <kai.heng.feng(a)canonical.com>
Cc: stable <stable(a)vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/usb/core/quirks.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/usb/core/quirks.c b/drivers/usb/core/quirks.c
index f1dbab6f798f..a10b346b9777 100644
--- a/drivers/usb/core/quirks.c
+++ b/drivers/usb/core/quirks.c
@@ -146,6 +146,9 @@ static const struct usb_device_id usb_quirk_list[] = {
/* appletouch */
{ USB_DEVICE(0x05ac, 0x021a), .driver_info = USB_QUIRK_RESET_RESUME },
+ /* Genesys Logic hub, internally used by KY-688 USB 3.1 Type-C Hub */
+ { USB_DEVICE(0x05e3, 0x0612), .driver_info = USB_QUIRK_NO_LPM },
+
/* Genesys Logic hub, internally used by Moshi USB to Ethernet Adapter */
{ USB_DEVICE(0x05e3, 0x0616), .driver_info = USB_QUIRK_NO_LPM },
--
2.15.0
This is a note to let you know that I've just added the patch titled
uas: Always apply US_FL_NO_ATA_1X quirk to Seagate devices
to my usb git tree which can be found at
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git
in the usb-linus branch.
The patch will show up in the next release of the linux-next tree
(usually sometime within the next 24 hours during the week.)
The patch will hopefully also be merged in Linus's tree for the
next -rc kernel release.
If you have any questions about this process, please let me know.
>From 7fee72d5e8f1e7b8d8212e28291b1a0243ecf2f1 Mon Sep 17 00:00:00 2001
From: Hans de Goede <hdegoede(a)redhat.com>
Date: Tue, 14 Nov 2017 19:27:22 +0100
Subject: uas: Always apply US_FL_NO_ATA_1X quirk to Seagate devices
We've been adding this as a quirk on a per device basis hoping that
newer disk enclosures would do better, but that has not happened,
so simply apply this quirk to all Seagate devices.
Signed-off-by: Hans de Goede <hdegoede(a)redhat.com>
Cc: stable <stable(a)vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/usb/storage/uas-detect.h | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/usb/storage/uas-detect.h b/drivers/usb/storage/uas-detect.h
index 1fcd758a961f..3734a25e09e5 100644
--- a/drivers/usb/storage/uas-detect.h
+++ b/drivers/usb/storage/uas-detect.h
@@ -112,6 +112,10 @@ static int uas_use_uas_driver(struct usb_interface *intf,
}
}
+ /* All Seagate disk enclosures have broken ATA pass-through support */
+ if (le16_to_cpu(udev->descriptor.idVendor) == 0x0bc2)
+ flags |= US_FL_NO_ATA_1X;
+
usb_stor_adjust_quirks(udev, &flags);
if (flags & US_FL_IGNORE_UAS) {
--
2.15.0
This is a note to let you know that I've just added the patch titled
usb: hub: Cycle HUB power when initialization fails
to my usb git tree which can be found at
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git
in the usb-linus branch.
The patch will show up in the next release of the linux-next tree
(usually sometime within the next 24 hours during the week.)
The patch will hopefully also be merged in Linus's tree for the
next -rc kernel release.
If you have any questions about this process, please let me know.
>From 973593a960ddac0f14f0d8877d2d0abe0afda795 Mon Sep 17 00:00:00 2001
From: Mike Looijmans <mike.looijmans(a)topic.nl>
Date: Thu, 9 Nov 2017 13:16:46 +0100
Subject: usb: hub: Cycle HUB power when initialization fails
Sometimes the USB device gets confused about the state of the initialization and
the connection fails. In particular, the device thinks that it's already set up
and running while the host thinks the device still needs to be configured. To
work around this issue, power-cycle the hub's output to issue a sort of "reset"
to the device. This makes the device restart its state machine and then the
initialization succeeds.
This fixes problems where the kernel reports a list of errors like this:
usb 1-1.3: device not accepting address 19, error -71
The end result is a non-functioning device. After this patch, the sequence
becomes like this:
usb 1-1.3: new high-speed USB device number 18 using ci_hdrc
usb 1-1.3: device not accepting address 18, error -71
usb 1-1.3: new high-speed USB device number 19 using ci_hdrc
usb 1-1.3: device not accepting address 19, error -71
usb 1-1-port3: attempt power cycle
usb 1-1.3: new high-speed USB device number 21 using ci_hdrc
usb-storage 1-1.3:1.2: USB Mass Storage device detected
Signed-off-by: Mike Looijmans <mike.looijmans(a)topic.nl>
Acked-by: Alan Stern <stern(a)rowland.harvard.edu>
Cc: stable <stable(a)vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/usb/core/hub.c | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
index 7ccdd3d4db84..cf7bbcb9a63c 100644
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -4948,6 +4948,15 @@ static void hub_port_connect(struct usb_hub *hub, int port1, u16 portstatus,
usb_put_dev(udev);
if ((status == -ENOTCONN) || (status == -ENOTSUPP))
break;
+
+ /* When halfway through our retry count, power-cycle the port */
+ if (i == (SET_CONFIG_TRIES / 2) - 1) {
+ dev_info(&port_dev->dev, "attempt power cycle\n");
+ usb_hub_set_port_power(hdev, hub, port1, false);
+ msleep(2 * hub_power_on_good_delay(hub));
+ usb_hub_set_port_power(hdev, hub, port1, true);
+ msleep(hub_power_on_good_delay(hub));
+ }
}
if (hub->hdev->parent ||
!hcd->driver->port_handed_over ||
--
2.15.0
This is a note to let you know that I've just added the patch titled
USB: core: Add type-specific length check of BOS descriptors
to my usb git tree which can be found at
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git
in the usb-linus branch.
The patch will show up in the next release of the linux-next tree
(usually sometime within the next 24 hours during the week.)
The patch will hopefully also be merged in Linus's tree for the
next -rc kernel release.
If you have any questions about this process, please let me know.
>From 81cf4a45360f70528f1f64ba018d61cb5767249a Mon Sep 17 00:00:00 2001
From: Masakazu Mokuno <masakazu.mokuno(a)gmail.com>
Date: Fri, 10 Nov 2017 01:25:50 +0900
Subject: USB: core: Add type-specific length check of BOS descriptors
As most of BOS descriptors are longer in length than their header
'struct usb_dev_cap_header', comparing solely with it is not sufficient
to avoid out-of-bounds access to BOS descriptors.
This patch adds descriptor type specific length check in
usb_get_bos_descriptor() to fix the issue.
Signed-off-by: Masakazu Mokuno <masakazu.mokuno(a)gmail.com>
Cc: stable <stable(a)vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/usb/core/config.c | 28 ++++++++++++++++++++++++----
include/uapi/linux/usb/ch9.h | 3 +++
2 files changed, 27 insertions(+), 4 deletions(-)
diff --git a/drivers/usb/core/config.c b/drivers/usb/core/config.c
index da8acd980fc6..55b198ba629b 100644
--- a/drivers/usb/core/config.c
+++ b/drivers/usb/core/config.c
@@ -905,14 +905,25 @@ void usb_release_bos_descriptor(struct usb_device *dev)
}
}
+static const __u8 bos_desc_len[256] = {
+ [USB_CAP_TYPE_WIRELESS_USB] = USB_DT_USB_WIRELESS_CAP_SIZE,
+ [USB_CAP_TYPE_EXT] = USB_DT_USB_EXT_CAP_SIZE,
+ [USB_SS_CAP_TYPE] = USB_DT_USB_SS_CAP_SIZE,
+ [USB_SSP_CAP_TYPE] = USB_DT_USB_SSP_CAP_SIZE(1),
+ [CONTAINER_ID_TYPE] = USB_DT_USB_SS_CONTN_ID_SIZE,
+ [USB_PTM_CAP_TYPE] = USB_DT_USB_PTM_ID_SIZE,
+};
+
/* Get BOS descriptor set */
int usb_get_bos_descriptor(struct usb_device *dev)
{
struct device *ddev = &dev->dev;
struct usb_bos_descriptor *bos;
struct usb_dev_cap_header *cap;
+ struct usb_ssp_cap_descriptor *ssp_cap;
unsigned char *buffer;
- int length, total_len, num, i;
+ int length, total_len, num, i, ssac;
+ __u8 cap_type;
int ret;
bos = kzalloc(sizeof(struct usb_bos_descriptor), GFP_KERNEL);
@@ -965,7 +976,13 @@ int usb_get_bos_descriptor(struct usb_device *dev)
dev->bos->desc->bNumDeviceCaps = i;
break;
}
+ cap_type = cap->bDevCapabilityType;
length = cap->bLength;
+ if (bos_desc_len[cap_type] && length < bos_desc_len[cap_type]) {
+ dev->bos->desc->bNumDeviceCaps = i;
+ break;
+ }
+
total_len -= length;
if (cap->bDescriptorType != USB_DT_DEVICE_CAPABILITY) {
@@ -973,7 +990,7 @@ int usb_get_bos_descriptor(struct usb_device *dev)
continue;
}
- switch (cap->bDevCapabilityType) {
+ switch (cap_type) {
case USB_CAP_TYPE_WIRELESS_USB:
/* Wireless USB cap descriptor is handled by wusb */
break;
@@ -986,8 +1003,11 @@ int usb_get_bos_descriptor(struct usb_device *dev)
(struct usb_ss_cap_descriptor *)buffer;
break;
case USB_SSP_CAP_TYPE:
- dev->bos->ssp_cap =
- (struct usb_ssp_cap_descriptor *)buffer;
+ ssp_cap = (struct usb_ssp_cap_descriptor *)buffer;
+ ssac = (le32_to_cpu(ssp_cap->bmAttributes) &
+ USB_SSP_SUBLINK_SPEED_ATTRIBS) + 1;
+ if (length >= USB_DT_USB_SSP_CAP_SIZE(ssac))
+ dev->bos->ssp_cap = ssp_cap;
break;
case CONTAINER_ID_TYPE:
dev->bos->ss_id =
diff --git a/include/uapi/linux/usb/ch9.h b/include/uapi/linux/usb/ch9.h
index 41a0a81b01e6..c4c79aa331bd 100644
--- a/include/uapi/linux/usb/ch9.h
+++ b/include/uapi/linux/usb/ch9.h
@@ -880,6 +880,8 @@ struct usb_wireless_cap_descriptor { /* Ultra Wide Band */
__u8 bReserved;
} __attribute__((packed));
+#define USB_DT_USB_WIRELESS_CAP_SIZE 11
+
/* USB 2.0 Extension descriptor */
#define USB_CAP_TYPE_EXT 2
@@ -1072,6 +1074,7 @@ struct usb_ptm_cap_descriptor {
__u8 bDevCapabilityType;
} __attribute__((packed));
+#define USB_DT_USB_PTM_ID_SIZE 3
/*
* The size of the descriptor for the Sublink Speed Attribute Count
* (SSAC) specified in bmAttributes[4:0].
--
2.15.0
This is a note to let you know that I've just added the patch titled
usb: host: fix incorrect updating of offset
to my usb git tree which can be found at
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git
in the usb-linus branch.
The patch will show up in the next release of the linux-next tree
(usually sometime within the next 24 hours during the week.)
The patch will hopefully also be merged in Linus's tree for the
next -rc kernel release.
If you have any questions about this process, please let me know.
>From 1d5a31582ef046d3b233f0da1a68ae26519b2f0a Mon Sep 17 00:00:00 2001
From: Colin Ian King <colin.king(a)canonical.com>
Date: Tue, 7 Nov 2017 16:45:04 +0000
Subject: usb: host: fix incorrect updating of offset
The variable temp is incorrectly being updated, instead it should
be offset otherwise the loop just reads the same capability value
and loops forever. Thanks to Alan Stern for pointing out the
correct fix to my original fix. Fix also cleans up clang warning:
drivers/usb/host/ehci-dbg.c:840:4: warning: Value stored to 'temp'
is never read
Fixes: d49d43174400 ("USB: misc ehci updates")
Cc: stable <stable(a)vger.kernel.org>
Signed-off-by: Colin Ian King <colin.king(a)canonical.com>
Acked-by: Alan Stern <stern(a)rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/usb/host/ehci-dbg.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/host/ehci-dbg.c b/drivers/usb/host/ehci-dbg.c
index 19f00424f53e..3ed75aaa09d9 100644
--- a/drivers/usb/host/ehci-dbg.c
+++ b/drivers/usb/host/ehci-dbg.c
@@ -827,7 +827,7 @@ static ssize_t fill_registers_buffer(struct debug_buffer *buf)
default: /* unknown */
break;
}
- temp = (cap >> 8) & 0xff;
+ offset = (cap >> 8) & 0xff;
}
}
#endif
--
2.15.0
This is a note to let you know that I've just added the patch titled
USB: ulpi: fix bus-node lookup
to my usb git tree which can be found at
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git
in the usb-linus branch.
The patch will show up in the next release of the linux-next tree
(usually sometime within the next 24 hours during the week.)
The patch will hopefully also be merged in Linus's tree for the
next -rc kernel release.
If you have any questions about this process, please let me know.
>From 33c309ebc797b908029fd3a0851aefe697e9b598 Mon Sep 17 00:00:00 2001
From: Johan Hovold <johan(a)kernel.org>
Date: Sat, 11 Nov 2017 16:31:18 +0100
Subject: USB: ulpi: fix bus-node lookup
Fix bus-node lookup during registration, which ended up searching the whole
device tree depth-first starting at the parent (or grand parent) rather
than just matching on its children.
To make things worse, the parent (or grand-parent) node could end being
prematurely freed as well.
Fixes: ef6a7bcfb01c ("usb: ulpi: Support device discovery via DT")
Reported-by: Peter Robinson <pbrobinson(a)gmail.com>
Reported-by: Stephen Boyd <sboyd(a)codeaurora.org>
Cc: stable <stable(a)vger.kernel.org> # 4.10
Signed-off-by: Johan Hovold <johan(a)kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/usb/common/ulpi.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/common/ulpi.c b/drivers/usb/common/ulpi.c
index 8b351444cc40..9a2ab6751a23 100644
--- a/drivers/usb/common/ulpi.c
+++ b/drivers/usb/common/ulpi.c
@@ -180,9 +180,9 @@ static int ulpi_of_register(struct ulpi *ulpi)
/* Find a ulpi bus underneath the parent or the grandparent */
parent = ulpi->dev.parent;
if (parent->of_node)
- np = of_find_node_by_name(parent->of_node, "ulpi");
+ np = of_get_child_by_name(parent->of_node, "ulpi");
else if (parent->parent && parent->parent->of_node)
- np = of_find_node_by_name(parent->parent->of_node, "ulpi");
+ np = of_get_child_by_name(parent->parent->of_node, "ulpi");
if (!np)
return 0;
--
2.15.0
This is a note to let you know that I've just added the patch titled
USB: usbfs: Filter flags passed in from user space
to my usb git tree which can be found at
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git
in the usb-linus branch.
The patch will show up in the next release of the linux-next tree
(usually sometime within the next 24 hours during the week.)
The patch will hopefully also be merged in Linus's tree for the
next -rc kernel release.
If you have any questions about this process, please let me know.
>From 446f666da9f019ce2ffd03800995487e79a91462 Mon Sep 17 00:00:00 2001
From: Oliver Neukum <oneukum(a)suse.com>
Date: Thu, 23 Nov 2017 16:39:52 +0100
Subject: USB: usbfs: Filter flags passed in from user space
USBDEVFS_URB_ISO_ASAP must be accepted only for ISO endpoints.
Improve sanity checking.
Reported-by: Andrey Konovalov <andreyknvl(a)google.com>
Signed-off-by: Oliver Neukum <oneukum(a)suse.com>
Cc: stable <stable(a)vger.kernel.org>
Acked-by: Alan Stern <stern(a)rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/usb/core/devio.c | 14 +++++++++-----
1 file changed, 9 insertions(+), 5 deletions(-)
diff --git a/drivers/usb/core/devio.c b/drivers/usb/core/devio.c
index 705c573d0257..a3fad4ec9870 100644
--- a/drivers/usb/core/devio.c
+++ b/drivers/usb/core/devio.c
@@ -1442,14 +1442,18 @@ static int proc_do_submiturb(struct usb_dev_state *ps, struct usbdevfs_urb *uurb
int number_of_packets = 0;
unsigned int stream_id = 0;
void *buf;
-
- if (uurb->flags & ~(USBDEVFS_URB_ISO_ASAP |
- USBDEVFS_URB_SHORT_NOT_OK |
+ unsigned long mask = USBDEVFS_URB_SHORT_NOT_OK |
USBDEVFS_URB_BULK_CONTINUATION |
USBDEVFS_URB_NO_FSBR |
USBDEVFS_URB_ZERO_PACKET |
- USBDEVFS_URB_NO_INTERRUPT))
- return -EINVAL;
+ USBDEVFS_URB_NO_INTERRUPT;
+ /* USBDEVFS_URB_ISO_ASAP is a special case */
+ if (uurb->type == USBDEVFS_URB_TYPE_ISO)
+ mask |= USBDEVFS_URB_ISO_ASAP;
+
+ if (uurb->flags & ~mask)
+ return -EINVAL;
+
if ((unsigned int)uurb->buffer_length >= USBFS_XFER_MAX)
return -EINVAL;
if (uurb->buffer_length > 0 && !uurb->buffer)
--
2.15.0
On Apollo Lake devices the BIOS does not set up IRQ routing for the i801
SMBUS controller IRQ, so we end up with dev->irq set to IRQ_NOTCONNECTED.
Detect this and do not try to use the irq in this case silencing:
i801_smbus 0000:00:1f.1: Failed to allocate irq -2147483648: -107
Cc: stable(a)vger.kernel.org
BugLink: https://communities.intel.com/thread/114759
Signed-off-by: Hans de Goede <hdegoede(a)redhat.com>
---
drivers/i2c/busses/i2c-i801.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/i2c/busses/i2c-i801.c b/drivers/i2c/busses/i2c-i801.c
index 9e12a53ef7b8..8eac00efadc1 100644
--- a/drivers/i2c/busses/i2c-i801.c
+++ b/drivers/i2c/busses/i2c-i801.c
@@ -1617,6 +1617,9 @@ static int i801_probe(struct pci_dev *dev, const struct pci_device_id *id)
/* Default timeout in interrupt mode: 200 ms */
priv->adapter.timeout = HZ / 5;
+ if (dev->irq == IRQ_NOTCONNECTED)
+ priv->features &= ~FEATURE_IRQ;
+
if (priv->features & FEATURE_IRQ) {
u16 pcictl, pcists;
--
2.14.3
This is a note to let you know that I've just added the patch titled
staging: ccree: fix leak of import() after init()
to my staging git tree which can be found at
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git
in the staging-linus branch.
The patch will show up in the next release of the linux-next tree
(usually sometime within the next 24 hours during the week.)
The patch will hopefully also be merged in Linus's tree for the
next -rc kernel release.
If you have any questions about this process, please let me know.
>From c5f39d07860c35e5e4c63188139465af790f86ce Mon Sep 17 00:00:00 2001
From: Gilad Ben-Yossef <gilad(a)benyossef.com>
Date: Thu, 9 Nov 2017 09:16:09 +0000
Subject: staging: ccree: fix leak of import() after init()
crypto_ahash_import() may be called either after
crypto_ahash_init() or without such call. Right now
we always internally call init() as part of
import(), thus leaking memory and mappings if the
user has already called init() herself.
Fix this by only calling init() internally if the
state is not already initialized.
Fixes: commit 454527d0d94f ("staging: ccree: fix hash import/export")
Cc: stable <stable(a)vger.kernel.org>
Signed-off-by: Gilad Ben-Yossef <gilad(a)benyossef.com>
Reviewed-by: Dan Carpenter <dan.carpenter(a)oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/staging/ccree/ssi_hash.c | 9 ++++++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/ccree/ssi_hash.c b/drivers/staging/ccree/ssi_hash.c
index d79090ed7f9c..1799d3f26a9e 100644
--- a/drivers/staging/ccree/ssi_hash.c
+++ b/drivers/staging/ccree/ssi_hash.c
@@ -1778,9 +1778,12 @@ static int ssi_ahash_import(struct ahash_request *req, const void *in)
}
in += sizeof(u32);
- rc = ssi_hash_init(state, ctx);
- if (rc)
- goto out;
+ /* call init() to allocate bufs if the user hasn't */
+ if (!state->digest_buff) {
+ rc = ssi_hash_init(state, ctx);
+ if (rc)
+ goto out;
+ }
dma_sync_single_for_cpu(dev, state->digest_buff_dma_addr,
ctx->inter_digestsize, DMA_BIDIRECTIONAL);
--
2.15.0
This is a note to let you know that I've just added the patch titled
Revert "sctp: do not peel off an assoc from one netns to another one"
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
revert-sctp-do-not-peel-off-an-assoc-from-one-netns-to.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From c76eb04f0895952a58f0029223f181854901e52e Mon Sep 17 00:00:00 2001
From: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Date: Tue, 28 Nov 2017 12:29:45 +0100
Subject: Revert "sctp: do not peel off an assoc from one netns to another one"
From: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
This reverts commit 2a0e60907e54dad75e9b3568d02bec11d6e74f6b which is
commit df80cd9b28b9ebaa284a41df611dbf3a2d05ca74 upstream as I messed up
by applying it to the tree twice.
Reported-by: Michal Kubecek <mkubecek(a)suse.cz>
Cc: ChunYu Wang <chunwang(a)redhat.com>
Cc: Xin Long <lucien.xin(a)gmail.com>
Cc: Marcelo Ricardo Leitner <marcelo.leitner(a)gmail.com>
Cc: Neil Horman <nhorman(a)tuxdriver.com>
Cc: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/sctp/socket.c | 4 ----
1 file changed, 4 deletions(-)
--- a/net/sctp/socket.c
+++ b/net/sctp/socket.c
@@ -4457,10 +4457,6 @@ int sctp_do_peeloff(struct sock *sk, sct
if (!net_eq(current->nsproxy->net_ns, sock_net(sk)))
return -EINVAL;
- /* Do not peel off from one netns to another one. */
- if (!net_eq(current->nsproxy->net_ns, sock_net(sk)))
- return -EINVAL;
-
if (!asoc)
return -EINVAL;
Patches currently in stable-queue which might be from gregkh(a)linuxfoundation.org are
queue-4.4/sched-make-resched_cpu-unconditional.patch
queue-4.4/media-rc-check-for-integer-overflow.patch
queue-4.4/af_vsock-shrink-the-area-influenced-by-prepare_to_wait.patch
queue-4.4/dmaengine-zx-set-dma_cyclic-cap_mask-bit.patch
queue-4.4/kvm-nvmx-set-idtr-and-gdtr-limits-when-loading-l1-host-state.patch
queue-4.4/rtlwifi-fix-uninitialized-rtlhal-last_suspend_sec-time.patch
queue-4.4/mips-fix-an-n32-core-file-generation-regset-support-regression.patch
queue-4.4/x86-decoder-add-new-test-instruction-pattern.patch
queue-4.4/i40evf-use-smp_rmb-rather-than-read_barrier_depends.patch
queue-4.4/ecryptfs-use-after-free-in-ecryptfs_release_messaging.patch
queue-4.4/iio-light-fix-improper-return-value.patch
queue-4.4/net-allow-ip_multicast_if-to-set-index-to-l3-slave.patch
queue-4.4/s390-disassembler-add-missing-end-marker-for-e7-table.patch
queue-4.4/kvm-svm-obey-guest-pat.patch
queue-4.4/asoc-rsnd-don-t-double-free-kctrl.patch
queue-4.4/cx231xx-cards-fix-null-deref-on-missing-association-descriptor.patch
queue-4.4/s390-disassembler-increase-show_code-buffer-size.patch
queue-4.4/alsa-timer-remove-kernel-warning-at-compat-ioctl-error-paths.patch
queue-4.4/igb-use-smp_rmb-rather-than-read_barrier_depends.patch
queue-4.4/s390-kbuild-enable-modversions-for-symbols-exported-from-asm.patch
queue-4.4/pci-apply-_hpx-settings-only-to-relevant-devices.patch
queue-4.4/s390-fix-transactional-execution-control-register-handling.patch
queue-4.4/netfilter-nf_tables-fix-oob-access.patch
queue-4.4/lib-mpi-call-cond_resched-from-mpi_powm-loop.patch
queue-4.4/alsa-hda-add-raven-pci-id.patch
queue-4.4/netfilter-nft_queue-use-raw_smp_processor_id.patch
queue-4.4/dm-fix-race-between-dm_get_from_kobject-and-__dm_destroy.patch
queue-4.4/net-3com-typhoon-typhoon_init_one-fix-incorrect-return-values.patch
queue-4.4/clk-ti-dra7-atl-clock-fix-child-node-lookups.patch
queue-4.4/arm-8722-1-mm-make-strict_kernel_rwx-effective-for-lpae.patch
queue-4.4/nfs-fix-ugly-referral-attributes.patch
queue-4.4/target-fix-queue_full-scsi-task-attribute-handling.patch
queue-4.4/mips-bcm47xx-fix-led-inversion-for-wrt54gsv1.patch
queue-4.4/mac80211-suppress-new_peer_candidate-event-if-no-room.patch
queue-4.4/vsock-use-new-wait-api-for-vsock_stream_sendmsg.patch
queue-4.4/autofs-don-t-fail-mount-for-transient-error.patch
queue-4.4/net-9p-switch-to-wait_event_killable.patch
queue-4.4/media-v4l2-ctrl-fix-flags-field-on-control-events.patch
queue-4.4/e1000e-fix-error-path-in-link-detection.patch
queue-4.4/mips-ralink-fix-mt7628-pinmux.patch
queue-4.4/e1000e-separate-signaling-for-link-check-link-up.patch
queue-4.4/iscsi-target-fix-non-immediate-tmr-reference-leak.patch
queue-4.4/alsa-usb-audio-add-sanity-checks-in-v2-clock-parsers.patch
queue-4.4/isofs-fix-timestamps-beyond-2027.patch
queue-4.4/nfs-fix-typo-in-nomigration-mount-option.patch
queue-4.4/fs-9p-compare-qid.path-in-v9fs_test_inode.patch
queue-4.4/alsa-hda-apply-alc269_fixup_no_shutup-on-hda_fixup_act_probe.patch
queue-4.4/alsa-hda-realtek-fix-alc700-family-no-sound-issue.patch
queue-4.4/pm-opp-add-missing-of_node_put-np.patch
queue-4.4/ixgbevf-use-smp_rmb-rather-than-read_barrier_depends.patch
queue-4.4/sched-rt-simplify-the-ipi-based-rt-balancing-logic.patch
queue-4.4/igbvf-use-smp_rmb-rather-than-read_barrier_depends.patch
queue-4.4/asoc-wm_adsp-don-t-overrun-firmware-file-buffer-when-reading-region-data.patch
queue-4.4/e1000e-fix-return-value-test.patch
queue-4.4/s390-runtime-instrumention-fix-possible-memory-corruption.patch
queue-4.4/nfsd-deal-with-revoked-delegations-appropriately.patch
queue-4.4/arm-8721-1-mm-dump-check-hardware-ro-bit-for-lpae.patch
queue-4.4/ath10k-fix-incorrect-txpower-set-by-p2p_device-interface.patch
queue-4.4/ata-fixes-kernel-crash-while-tracing-ata_eh_link_autopsy-event.patch
queue-4.4/ipv6-only-call-ip6_route_dev_notify-once-for-netdev_unregister.patch
queue-4.4/fm10k-use-smp_rmb-rather-than-read_barrier_depends.patch
queue-4.4/ath10k-fix-potential-memory-leak-in-ath10k_wmi_tlv_op_pull_fw_stats.patch
queue-4.4/bcache-check-ca-alloc_thread-initialized-before-wake-up-it.patch
queue-4.4/ixgbe-fix-skb-list-corruption-on-power-systems.patch
queue-4.4/net-3com-typhoon-typhoon_init_one-make-return-values-more-specific.patch
queue-4.4/alsa-usb-audio-fix-potential-out-of-bound-access-at-parsing-su.patch
queue-4.4/alsa-pcm-update-tstamp-only-if-audio_tstamp-changed.patch
queue-4.4/fscrypt-lock-mutex-before-checking-for-bounce-page-pool.patch
queue-4.4/parisc-fix-validity-check-of-pointer-size-argument-in-new-cas-implementation.patch
queue-4.4/revert-sctp-do-not-peel-off-an-assoc-from-one-netns-to.patch
queue-4.4/fix-a-page-leak-in-vhost_scsi_iov_to_sgl-error-recovery.patch
queue-4.4/btrfs-return-the-actual-error-value-from-from-btrfs_uuid_tree_iterate.patch
queue-4.4/mips-ralink-fix-typo-in-mt7628-pinmux-function.patch
queue-4.4/drm-armada-fix-compile-fail.patch
queue-4.4/rds-rdma-return-appropriate-error-on-rdma-map-failures.patch
queue-4.4/powerpc-signal-properly-handle-return-value-from-uprobe_deny_signal.patch
queue-4.4/ath10k-ignore-configuring-the-incorrect-board_id.patch
queue-4.4/ath10k-set-cts-protection-vdev-param-only-if-vdev-is-up.patch
queue-4.4/dm-bufio-fix-integer-overflow-when-limiting-maximum-cache-size.patch
queue-4.4/nilfs2-fix-race-condition-that-causes-file-system-corruption.patch
queue-4.4/spi-spi_fsl_dspi-should-depend-on-has_dma.patch
queue-4.4/staging-iio-cdc-fix-improper-return-value.patch
queue-4.4/ib-srp-avoid-that-a-cable-pull-can-trigger-a-kernel-crash.patch
queue-4.4/libnvdimm-namespace-make-resource-attribute-only-readable-by-root.patch
queue-4.4/ib-srpt-do-not-accept-invalid-initiator-port-names.patch
queue-4.4/nfc-fix-device-allocation-error-return.patch
queue-4.4/rtlwifi-rtl8192ee-fix-memory-leak-when-loading-firmware.patch
queue-4.4/clk-ti-dra7-atl-clock-fix-of_node-reference-counting.patch
queue-4.4/xen-xenbus-driver-must-not-accept-invalid-transaction-ids.patch
queue-4.4/media-don-t-do-dma-on-stack-for-firmware-upload-in-the-as102-driver.patch
queue-4.4/i40e-use-smp_rmb-rather-than-read_barrier_depends.patch
queue-4.4/libnvdimm-namespace-fix-label-initialization-to-use-valid-seq-numbers.patch
queue-4.4/alsa-usb-audio-add-sanity-checks-to-fe-parser.patch
queue-4.4/sunrpc-fix-tracepoint-storage-issues-with-svc_recv-and-svc_rqst_status.patch
queue-4.4/ext4-fix-interaction-between-i_size-fallocate-and-delalloc-after-a-crash.patch
queue-4.4/drm-apply-range-restriction-after-color-adjustment-when-allocation.patch
queue-4.4/mac80211-remove-invalid-flag-operations-in-mesh-tsf-synchronization.patch
Hello,
I noticed that mainline commit df80cd9b28b9 ("sctp: do not peel off an
assoc from one netns to another one") has been backported to stable 4.4
branch twice:
- first as commit 46bdabbca02e in 4.4.100
- then again as commit 2a0e60907e54 in 4.4.101
so that the check it adds in sctp_do_peeloff() is now performed twice.
Michal Kubecek
From: Eric Biggers <ebiggers(a)google.com>
->pkey_algo used to be an enum, but was changed to a string by commit
4e8ae72a75aa ("X.509: Make algo identifiers text instead of enum"). But
two comparisons were not updated. Fix them to use strcmp().
This bug broke signature verification in certain configurations,
depending on whether the string constants were deduplicated or not.
Fixes: 4e8ae72a75aa ("X.509: Make algo identifiers text instead of enum")
Cc: <stable(a)vger.kernel.org> # v4.6+
Signed-off-by: Eric Biggers <ebiggers(a)google.com>
---
crypto/asymmetric_keys/pkcs7_verify.c | 2 +-
crypto/asymmetric_keys/x509_public_key.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/crypto/asymmetric_keys/pkcs7_verify.c b/crypto/asymmetric_keys/pkcs7_verify.c
index 2d93d9eccb4d..063d6745c741 100644
--- a/crypto/asymmetric_keys/pkcs7_verify.c
+++ b/crypto/asymmetric_keys/pkcs7_verify.c
@@ -150,7 +150,7 @@ static int pkcs7_find_key(struct pkcs7_message *pkcs7,
pr_devel("Sig %u: Found cert serial match X.509[%u]\n",
sinfo->index, certix);
- if (x509->pub->pkey_algo != sinfo->sig->pkey_algo) {
+ if (strcmp(x509->pub->pkey_algo, sinfo->sig->pkey_algo)) {
pr_warn("Sig %u: X.509 algo and PKCS#7 sig algo don't match\n",
sinfo->index);
continue;
diff --git a/crypto/asymmetric_keys/x509_public_key.c b/crypto/asymmetric_keys/x509_public_key.c
index c9013582c026..9db20abe78a0 100644
--- a/crypto/asymmetric_keys/x509_public_key.c
+++ b/crypto/asymmetric_keys/x509_public_key.c
@@ -135,7 +135,7 @@ int x509_check_for_self_signed(struct x509_certificate *cert)
}
ret = -EKEYREJECTED;
- if (cert->pub->pkey_algo != cert->sig->pkey_algo)
+ if (strcmp(cert->pub->pkey_algo, cert->sig->pkey_algo))
goto out;
ret = public_key_verify_signature(cert->pub, cert->sig);
--
2.15.0
This reverts commit 92266d6ef60c2381c980c6cdcb2a5c1667b36b49, which
was simply wrong: In the case where domain is NULL, we now use the
wrong offsetof() in the list_first_entry macro, so we don't actually
fetch the ->cookie value, but rather the eight bytes located
sizeof(struct list_head) further into the struct async_entry.
On 64 bit, that's the data member, while on 32 bit, we get a u64 built
from func and data in some order.
I think the bug happens to be harmless in practice: It obviously only
affects callers which pass a NULL domain, and AFAICT the only such
caller is
async_synchronize_full() ->
async_synchronize_full_domain(NULL) ->
async_synchronize_cookie_domain(ASYNC_COOKIE_MAX, NULL)
and the ASYNC_COOKIE_MAX means that in practice we end up waiting for
the async_global_pending list to be empty - but it would break if
somebody happened to pass (void*)-1 as the data element to
async_schedule, and of course also if somebody ever does a
async_synchronize_cookie_domain(, NULL) with a "finite" cookie value.
Cc: stable(a)vger.kernel.org # 3.10+
Signed-off-by: Rasmus Villemoes <linux(a)rasmusvillemoes.dk>
---
Maybe the "harmless in practice" means this isn't -stable
material. But I'm not completely confident my quick git grep'ing is
enough, and there might be affected code in one of the earlier kernels
that has since been removed, so I'll leave the decision to the stable
guys.
kernel/async.c | 20 ++++++++++++--------
1 file changed, 12 insertions(+), 8 deletions(-)
diff --git a/kernel/async.c b/kernel/async.c
index 2cbd3dd5940d..a893d6170944 100644
--- a/kernel/async.c
+++ b/kernel/async.c
@@ -84,20 +84,24 @@ static atomic_t entry_count;
static async_cookie_t lowest_in_progress(struct async_domain *domain)
{
- struct list_head *pending;
+ struct async_entry *first = NULL;
async_cookie_t ret = ASYNC_COOKIE_MAX;
unsigned long flags;
spin_lock_irqsave(&async_lock, flags);
- if (domain)
- pending = &domain->pending;
- else
- pending = &async_global_pending;
+ if (domain) {
+ if (!list_empty(&domain->pending))
+ first = list_first_entry(&domain->pending,
+ struct async_entry, domain_list);
+ } else {
+ if (!list_empty(&async_global_pending))
+ first = list_first_entry(&async_global_pending,
+ struct async_entry, global_list);
+ }
- if (!list_empty(pending))
- ret = list_first_entry(pending, struct async_entry,
- domain_list)->cookie;
+ if (first)
+ ret = first->cookie;
spin_unlock_irqrestore(&async_lock, flags);
return ret;
--
2.11.0
This is a note to let you know that I've just added the patch titled
e1000e: fix buffer overrun while the I219 is processing DMA transactions
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
e1000e-fix-buffer-overrun-while-the-i219-is-processing-dma-transactions.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From b10effb92e272051dd1ec0d7be56bf9ca85ab927 Mon Sep 17 00:00:00 2001
From: Sasha Neftin <sasha.neftin(a)intel.com>
Date: Sun, 6 Aug 2017 16:49:18 +0300
Subject: e1000e: fix buffer overrun while the I219 is processing DMA transactions
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
From: Sasha Neftin <sasha.neftin(a)intel.com>
commit b10effb92e272051dd1ec0d7be56bf9ca85ab927 upstream.
Intel® 100/200 Series Chipset platforms reduced the round-trip
latency for the LAN Controller DMA accesses, causing in some high
performance cases a buffer overrun while the I219 LAN Connected
Device is processing the DMA transactions. I219LM and I219V devices
can fall into unrecovered Tx hang under very stressfully UDP traffic
and multiple reconnection of Ethernet cable. This Tx hang of the LAN
Controller is only recovered if the system is rebooted. Slightly slow
down DMA access by reducing the number of outstanding requests.
This workaround could have an impact on TCP traffic performance
on the platform. Disabling TSO eliminates performance loss for TCP
traffic without a noticeable impact on CPU performance.
Please, refer to I218/I219 specification update:
https://www.intel.com/content/www/us/en/embedded/products/networking/
ethernet-connection-i218-family-documentation.html
Signed-off-by: Sasha Neftin <sasha.neftin(a)intel.com>
Reviewed-by: Dima Ruinskiy <dima.ruinskiy(a)intel.com>
Reviewed-by: Raanan Avargil <raanan.avargil(a)intel.com>
Tested-by: Aaron Brown <aaron.f.brown(a)intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher(a)intel.com>
Signed-off-by: Amit Pundir <amit.pundir(a)linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/ethernet/intel/e1000e/netdev.c | 8 +++++---
1 file changed, 5 insertions(+), 3 deletions(-)
--- a/drivers/net/ethernet/intel/e1000e/netdev.c
+++ b/drivers/net/ethernet/intel/e1000e/netdev.c
@@ -3021,8 +3021,8 @@ static void e1000_configure_tx(struct e1
hw->mac.ops.config_collision_dist(hw);
- /* SPT and CNP Si errata workaround to avoid data corruption */
- if (hw->mac.type >= e1000_pch_spt) {
+ /* SPT and KBL Si errata workaround to avoid data corruption */
+ if (hw->mac.type == e1000_pch_spt) {
u32 reg_val;
reg_val = er32(IOSFPC);
@@ -3030,7 +3030,9 @@ static void e1000_configure_tx(struct e1
ew32(IOSFPC, reg_val);
reg_val = er32(TARC(0));
- reg_val |= E1000_TARC0_CB_MULTIQ_3_REQ;
+ /* SPT and KBL Si errata workaround to avoid Tx hang */
+ reg_val &= ~BIT(28);
+ reg_val |= BIT(29);
ew32(TARC(0), reg_val);
}
}
Patches currently in stable-queue which might be from sasha.neftin(a)intel.com are
queue-4.14/e1000e-fix-buffer-overrun-while-the-i219-is-processing-dma-transactions.patch
This is a note to let you know that I've just added the patch titled
xen: xenbus driver must not accept invalid transaction ids
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=sum…
The filename of the patch is:
xen-xenbus-driver-must-not-accept-invalid-transaction-ids.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(a)vger.kernel.org> know about it.
>From foo@baz Tue Nov 28 10:58:31 CET 2017
From: Juergen Gross <jgross(a)suse.com>
Date: Thu, 22 Dec 2016 08:19:46 +0100
Subject: xen: xenbus driver must not accept invalid transaction ids
From: Juergen Gross <jgross(a)suse.com>
[ Upstream commit 639b08810d6ad74ded2c5f6e233c4fcb9d147168 ]
When accessing Xenstore in a transaction the user is specifying a
transaction id which he normally obtained from Xenstore when starting
the transaction. Xenstore is validating a transaction id against all
known transaction ids of the connection the request came in. As all
requests of a domain not being the one where Xenstore lives share
one connection, validation of transaction ids of different users of
Xenstore in that domain should be done by the kernel of that domain
being the multiplexer between the Xenstore users in that domain and
Xenstore.
In order to prohibit one Xenstore user "hijacking" a transaction from
another user the xenbus driver has to verify a given transaction id
against all known transaction ids of the user before forwarding it to
Xenstore.
Signed-off-by: Juergen Gross <jgross(a)suse.com>
Reviewed-by: Boris Ostrovsky <boris.ostrovsky(a)oracle.com>
Signed-off-by: Juergen Gross <jgross(a)suse.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/xen/xenbus/xenbus_dev_frontend.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/xen/xenbus/xenbus_dev_frontend.c
+++ b/drivers/xen/xenbus/xenbus_dev_frontend.c
@@ -316,7 +316,7 @@ static int xenbus_write_transaction(unsi
rc = -ENOMEM;
goto out;
}
- } else if (msg_type == XS_TRANSACTION_END) {
+ } else if (u->u.msg.tx_id != 0) {
list_for_each_entry(trans, &u->transactions, list)
if (trans->handle.id == u->u.msg.tx_id)
break;
Patches currently in stable-queue which might be from jgross(a)suse.com are
queue-3.18/xen-xenbus-driver-must-not-accept-invalid-transaction-ids.patch
This is a note to let you know that I've just added the patch titled
staging: iio: cdc: fix improper return value
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=sum…
The filename of the patch is:
staging-iio-cdc-fix-improper-return-value.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(a)vger.kernel.org> know about it.
>From foo@baz Tue Nov 28 10:58:31 CET 2017
From: Pan Bian <bianpan2016(a)163.com>
Date: Sat, 3 Dec 2016 21:44:30 +0800
Subject: staging: iio: cdc: fix improper return value
From: Pan Bian <bianpan2016(a)163.com>
[ Upstream commit 91ca1a8c584f55857b1f6ab20a1d3a1ce7a559bb ]
At the end of function ad7150_write_event_config(), directly returns 0.
As a result, the errors will be ignored by the callers. It may be better
to return variable "ret".
Signed-off-by: Pan Bian <bianpan2016(a)163.com>
Signed-off-by: Jonathan Cameron <jic23(a)kernel.org>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/staging/iio/cdc/ad7150.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/staging/iio/cdc/ad7150.c
+++ b/drivers/staging/iio/cdc/ad7150.c
@@ -275,7 +275,7 @@ static int ad7150_write_event_config(str
error_ret:
mutex_unlock(&chip->state_lock);
- return 0;
+ return ret;
}
static int ad7150_read_event_value(struct iio_dev *indio_dev,
Patches currently in stable-queue which might be from bianpan2016(a)163.com are
queue-3.18/net-3com-typhoon-typhoon_init_one-fix-incorrect-return-values.patch
queue-3.18/btrfs-return-the-actual-error-value-from-from-btrfs_uuid_tree_iterate.patch
queue-3.18/staging-iio-cdc-fix-improper-return-value.patch
This is a note to let you know that I've just added the patch titled
s390/kbuild: enable modversions for symbols exported from asm
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=sum…
The filename of the patch is:
s390-kbuild-enable-modversions-for-symbols-exported-from-asm.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(a)vger.kernel.org> know about it.
>From foo@baz Tue Nov 28 10:58:31 CET 2017
From: Heiko Carstens <heiko.carstens(a)de.ibm.com>
Date: Tue, 20 Dec 2016 12:58:10 +0100
Subject: s390/kbuild: enable modversions for symbols exported from asm
From: Heiko Carstens <heiko.carstens(a)de.ibm.com>
[ Upstream commit cabab3f9f5ca077535080b3252e6168935b914af ]
s390 version of commit 334bb7738764 ("x86/kbuild: enable modversions
for symbols exported from asm") so we get also rid of all these
warnings:
WARNING: EXPORT symbol "_mcount" [vmlinux] version generation failed, symbol will not be versioned.
WARNING: EXPORT symbol "memcpy" [vmlinux] version generation failed, symbol will not be versioned.
WARNING: EXPORT symbol "memmove" [vmlinux] version generation failed, symbol will not be versioned.
WARNING: EXPORT symbol "memset" [vmlinux] version generation failed, symbol will not be versioned.
WARNING: EXPORT symbol "save_fpu_regs" [vmlinux] version generation failed, symbol will not be versioned.
WARNING: EXPORT symbol "sie64a" [vmlinux] version generation failed, symbol will not be versioned.
WARNING: EXPORT symbol "sie_exit" [vmlinux] version generation failed, symbol will not be versioned.
Signed-off-by: Heiko Carstens <heiko.carstens(a)de.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky(a)de.ibm.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/s390/include/asm/asm-prototypes.h | 8 ++++++++
1 file changed, 8 insertions(+)
create mode 100644 arch/s390/include/asm/asm-prototypes.h
--- /dev/null
+++ b/arch/s390/include/asm/asm-prototypes.h
@@ -0,0 +1,8 @@
+#ifndef _ASM_S390_PROTOTYPES_H
+
+#include <linux/kvm_host.h>
+#include <linux/ftrace.h>
+#include <asm/fpu/api.h>
+#include <asm-generic/asm-prototypes.h>
+
+#endif /* _ASM_S390_PROTOTYPES_H */
Patches currently in stable-queue which might be from heiko.carstens(a)de.ibm.com are
queue-3.18/s390-kbuild-enable-modversions-for-symbols-exported-from-asm.patch
This is a note to let you know that I've just added the patch titled
RDS: RDMA: return appropriate error on rdma map failures
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=sum…
The filename of the patch is:
rds-rdma-return-appropriate-error-on-rdma-map-failures.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(a)vger.kernel.org> know about it.
>From foo@baz Tue Nov 28 10:58:31 CET 2017
From: Santosh Shilimkar <santosh.shilimkar(a)oracle.com>
Date: Mon, 4 Jul 2016 17:04:37 -0700
Subject: RDS: RDMA: return appropriate error on rdma map failures
From: Santosh Shilimkar <santosh.shilimkar(a)oracle.com>
[ Upstream commit 584a8279a44a800dea5a5c1e9d53a002e03016b4 ]
The first message to a remote node should prompt a new
connection even if it is RDMA operation. For RDMA operation
the MR mapping can fail because connections is not yet up.
Since the connection establishment is asynchronous,
we make sure the map failure because of unavailable
connection reach to the user by appropriate error code.
Before returning to the user, lets trigger the connection
so that its ready for the next retry.
Signed-off-by: Santosh Shilimkar <santosh.shilimkar(a)oracle.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/rds/send.c | 11 ++++++++++-
1 file changed, 10 insertions(+), 1 deletion(-)
--- a/net/rds/send.c
+++ b/net/rds/send.c
@@ -903,6 +903,11 @@ static int rds_cmsg_send(struct rds_sock
ret = rds_cmsg_rdma_map(rs, rm, cmsg);
if (!ret)
*allocated_mr = 1;
+ else if (ret == -ENODEV)
+ /* Accommodate the get_mr() case which can fail
+ * if connection isn't established yet.
+ */
+ ret = -EAGAIN;
break;
case RDS_CMSG_ATOMIC_CSWP:
case RDS_CMSG_ATOMIC_FADD:
@@ -1011,8 +1016,12 @@ int rds_sendmsg(struct kiocb *iocb, stru
/* Parse any control messages the user may have included. */
ret = rds_cmsg_send(rs, rm, msg, &allocated_mr);
- if (ret)
+ if (ret) {
+ /* Trigger connection so that its ready for the next retry */
+ if (ret == -EAGAIN)
+ rds_conn_connect_if_down(conn);
goto out;
+ }
if (rm->rdma.op_active && !conn->c_trans->xmit_rdma) {
printk_ratelimited(KERN_NOTICE "rdma_op %p conn xmit_rdma %p\n",
Patches currently in stable-queue which might be from santosh.shilimkar(a)oracle.com are
queue-3.18/rds-rdma-return-appropriate-error-on-rdma-map-failures.patch