The following race occurs while accessing the dmabuf object exported as
file:
P1 P2
dma_buf_release() dmabuffs_dname()
[say lsof reading /proc/<P1 pid>/fd/<num>]
read dmabuf stored in dentry->d_fsdata
Free the dmabuf object
Start accessing the dmabuf structure
In the above description, the dmabuf object freed in P1 is being
accessed from P2 which is resulting into the use-after-free. Below is
the dump stack reported.
We are reading the dmabuf object stored in the dentry->d_fsdata but
there is no binding between the dentry and the dmabuf which means that
the dmabuf can be freed while it is being read from ->d_fsdata and
inuse. Reviews on the patch V1 says that protecting the dmabuf inuse
with an extra refcount is not a viable solution as the exported dmabuf
is already under file's refcount and keeping the multiple refcounts on
the same object coordinated is not possible.
As we are reading the dmabuf in ->d_fsdata just to get the user passed
name, we can directly store the name in d_fsdata thus can avoid the
reading of dmabuf altogether.
Call Trace:
kasan_report+0x12/0x20
__asan_report_load8_noabort+0x14/0x20
dmabuffs_dname+0x4f4/0x560
tomoyo_realpath_from_path+0x165/0x660
tomoyo_get_realpath
tomoyo_check_open_permission+0x2a3/0x3e0
tomoyo_file_open
tomoyo_file_open+0xa9/0xd0
security_file_open+0x71/0x300
do_dentry_open+0x37a/0x1380
vfs_open+0xa0/0xd0
path_openat+0x12ee/0x3490
do_filp_open+0x192/0x260
do_sys_openat2+0x5eb/0x7e0
do_sys_open+0xf2/0x180
Fixes: bb2bb9030425 ("dma-buf: add DMA_BUF_SET_NAME ioctls")
Reported-by: syzbot+3643a18836bce555bff6(a)syzkaller.appspotmail.com
Cc: <stable(a)vger.kernel.org> [5.3+]
Signed-off-by: Charan Teja Reddy <charante(a)codeaurora.org>
---
Changes in v2:
- Pass the user passed name in ->d_fsdata instead of dmabuf
- Improve the commit message
Changes in v1: (https://patchwork.kernel.org/patch/11514063/)
drivers/dma-buf/dma-buf.c | 17 ++++++++++-------
1 file changed, 10 insertions(+), 7 deletions(-)
diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index 01ce125..0071f7d 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -25,6 +25,7 @@
#include <linux/mm.h>
#include <linux/mount.h>
#include <linux/pseudo_fs.h>
+#include <linux/dcache.h>
#include <uapi/linux/dma-buf.h>
#include <uapi/linux/magic.h>
@@ -40,15 +41,13 @@ struct dma_buf_list {
static char *dmabuffs_dname(struct dentry *dentry, char *buffer, int buflen)
{
- struct dma_buf *dmabuf;
char name[DMA_BUF_NAME_LEN];
size_t ret = 0;
- dmabuf = dentry->d_fsdata;
- dma_resv_lock(dmabuf->resv, NULL);
- if (dmabuf->name)
- ret = strlcpy(name, dmabuf->name, DMA_BUF_NAME_LEN);
- dma_resv_unlock(dmabuf->resv);
+ spin_lock(&dentry->d_lock);
+ if (dentry->d_fsdata)
+ ret = strlcpy(name, dentry->d_fsdata, DMA_BUF_NAME_LEN);
+ spin_unlock(&dentry->d_lock);
return dynamic_dname(dentry, buffer, buflen, "/%s:%s",
dentry->d_name.name, ret > 0 ? name : "");
@@ -80,12 +79,16 @@ static int dma_buf_fs_init_context(struct fs_context *fc)
static int dma_buf_release(struct inode *inode, struct file *file)
{
struct dma_buf *dmabuf;
+ struct dentry *dentry = file->f_path.dentry;
if (!is_dma_buf_file(file))
return -EINVAL;
dmabuf = file->private_data;
+ spin_lock(&dentry->d_lock);
+ dentry->d_fsdata = NULL;
+ spin_unlock(&dentry->d_lock);
BUG_ON(dmabuf->vmapping_counter);
/*
@@ -343,6 +346,7 @@ static long dma_buf_set_name(struct dma_buf *dmabuf, const char __user *buf)
}
kfree(dmabuf->name);
dmabuf->name = name;
+ dmabuf->file->f_path.dentry->d_fsdata = name;
out_unlock:
dma_resv_unlock(dmabuf->resv);
@@ -446,7 +450,6 @@ static struct file *dma_buf_getfile(struct dma_buf *dmabuf, int flags)
goto err_alloc_file;
file->f_flags = flags & (O_ACCMODE | O_NONBLOCK);
file->private_data = dmabuf;
- file->f_path.dentry->d_fsdata = dmabuf;
return file;
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a
member of the Code Aurora Forum, hosted by The Linux Foundation
When doing an atomic modeset with ALLOW_MODESET drivers are allowed to
pull in arbitrary other resources, including CRTCs (e.g. when
reconfiguring global resources).
But in nonblocking mode userspace has then no idea this happened,
which can lead to spurious EBUSY calls, both:
- when that other CRTC is currently busy doing a page_flip the
ALLOW_MODESET commit can fail with an EBUSY
- on the other CRTC a normal atomic flip can fail with EBUSY because
of the additional commit inserted by the kernel without userspace's
knowledge
For blocking commits this isn't a problem, because everyone else will
just block until all the CRTC are reconfigured. Only thing userspace
can notice is the dropped frames without any reason for why frames got
dropped.
Consensus is that we need new uapi to handle this properly, but no one
has any idea what exactly the new uapi should look like. As a stop-gap
plug this problem by demoting nonblocking commits which might cause
issues by including CRTCs not in the original request to blocking
commits.
v2: Add comments and a WARN_ON to enforce this only when allowed - we
don't want to silently convert page flips into blocking plane updates
just because the driver is buggy.
v3: Fix inverted WARN_ON (Pekka).
References: https://lists.freedesktop.org/archives/dri-devel/2018-July/182281.html
Bugzilla: https://gitlab.freedesktop.org/wayland/weston/issues/24#note_9568
Cc: Daniel Stone <daniel(a)fooishbar.org>
Cc: Pekka Paalanen <pekka.paalanen(a)collabora.co.uk>
Cc: stable(a)vger.kernel.org
Reviewed-by: Daniel Stone <daniels(a)collabora.com>
Cc: Ville Syrjälä <ville.syrjala(a)linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter(a)intel.com>
--
Resending because last attempt failed CI and meanwhile the results are
lost :-/
-Daniel
---
drivers/gpu/drm/drm_atomic.c | 34 +++++++++++++++++++++++++++++++---
1 file changed, 31 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 965173fd0ac2..4f140ff6fb98 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -1362,15 +1362,43 @@ EXPORT_SYMBOL(drm_atomic_commit);
int drm_atomic_nonblocking_commit(struct drm_atomic_state *state)
{
struct drm_mode_config *config = &state->dev->mode_config;
- int ret;
+ unsigned requested_crtc = 0;
+ unsigned affected_crtc = 0;
+ struct drm_crtc *crtc;
+ struct drm_crtc_state *crtc_state;
+ bool nonblocking = true;
+ int ret, i;
+
+ /*
+ * For commits that allow modesets drivers can add other CRTCs to the
+ * atomic commit, e.g. when they need to reallocate global resources.
+ *
+ * But when userspace also requests a nonblocking commit then userspace
+ * cannot know that the commit affects other CRTCs, which can result in
+ * spurious EBUSY failures. Until we have better uapi plug this by
+ * demoting such commits to blocking mode.
+ */
+ for_each_new_crtc_in_state(state, crtc, crtc_state, i)
+ requested_crtc |= drm_crtc_mask(crtc);
ret = drm_atomic_check_only(state);
if (ret)
return ret;
- DRM_DEBUG_ATOMIC("committing %p nonblocking\n", state);
+ for_each_new_crtc_in_state(state, crtc, crtc_state, i)
+ affected_crtc |= drm_crtc_mask(crtc);
+
+ if (affected_crtc != requested_crtc) {
+ /* adding other CRTC is only allowed for modeset commits */
+ WARN_ON(!state->allow_modeset);
+
+ DRM_DEBUG_ATOMIC("demoting %p to blocking mode to avoid EBUSY\n", state);
+ nonblocking = false;
+ } else {
+ DRM_DEBUG_ATOMIC("committing %p nonblocking\n", state);
+ }
- return config->funcs->atomic_commit(state->dev, state, true);
+ return config->funcs->atomic_commit(state->dev, state, nonblocking);
}
EXPORT_SYMBOL(drm_atomic_nonblocking_commit);
--
2.25.1
From: Sriharsha Allenki <sallenki(a)codeaurora.org>
On platforms with IOMMU enabled, multiple SGs can be coalesced into one
by the IOMMU driver. In that case the SG list processing as part of the
completion of a urb on a bulk endpoint can result into a NULL pointer
dereference with the below stack dump.
<6> Unable to handle kernel NULL pointer dereference at virtual address 0000000c
<6> pgd = c0004000
<6> [0000000c] *pgd=00000000
<6> Internal error: Oops: 5 [#1] PREEMPT SMP ARM
<2> PC is at xhci_queue_bulk_tx+0x454/0x80c
<2> LR is at xhci_queue_bulk_tx+0x44c/0x80c
<2> pc : [<c08907c4>] lr : [<c08907bc>] psr: 000000d3
<2> sp : ca337c80 ip : 00000000 fp : ffffffff
<2> r10: 00000000 r9 : 50037000 r8 : 00004000
<2> r7 : 00000000 r6 : 00004000 r5 : 00000000 r4 : 00000000
<2> r3 : 00000000 r2 : 00000082 r1 : c2c1a200 r0 : 00000000
<2> Flags: nzcv IRQs off FIQs off Mode SVC_32 ISA ARM Segment none
<2> Control: 10c0383d Table: b412c06a DAC: 00000051
<6> Process usb-storage (pid: 5961, stack limit = 0xca336210)
<snip>
<2> [<c08907c4>] (xhci_queue_bulk_tx)
<2> [<c0881b3c>] (xhci_urb_enqueue)
<2> [<c0831068>] (usb_hcd_submit_urb)
<2> [<c08350b4>] (usb_sg_wait)
<2> [<c089f384>] (usb_stor_bulk_transfer_sglist)
<2> [<c089f2c0>] (usb_stor_bulk_srb)
<2> [<c089fe38>] (usb_stor_Bulk_transport)
<2> [<c089f468>] (usb_stor_invoke_transport)
<2> [<c08a11b4>] (usb_stor_control_thread)
<2> [<c014a534>] (kthread)
The above NULL pointer dereference is the result of block_len and the
sent_len set to zero after the first SG of the list when IOMMU driver
is enabled. Because of this the loop of processing the SGs has run
more than num_sgs which resulted in a sg_next on the last SG of the
list which has SG_END set.
Fix this by check for the sg before any attributes of the sg are
accessed.
[modified reason for null pointer dereference in commit message subject -Mathias]
Fixes: f9c589e142d04 ("xhci: TD-fragment, align the unsplittable case with a bounce buffer")
Cc: stable(a)vger.kernel.org
Signed-off-by: Sriharsha Allenki <sallenki(a)codeaurora.org>
Signed-off-by: Mathias Nyman <mathias.nyman(a)linux.intel.com>
---
drivers/usb/host/xhci-ring.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
index 0fda0c0f4d31..2c255d0620b0 100644
--- a/drivers/usb/host/xhci-ring.c
+++ b/drivers/usb/host/xhci-ring.c
@@ -3433,8 +3433,8 @@ int xhci_queue_bulk_tx(struct xhci_hcd *xhci, gfp_t mem_flags,
/* New sg entry */
--num_sgs;
sent_len -= block_len;
- if (num_sgs != 0) {
- sg = sg_next(sg);
+ sg = sg_next(sg);
+ if (num_sgs != 0 && sg) {
block_len = sg_dma_len(sg);
addr = (u64) sg_dma_address(sg);
addr += sent_len;
--
2.17.1
commit 86f8b1c01a0a537a73d2996615133be63cdf75db upstream
Prior to 1d27732f411d ("net: dsa: setup and teardown ports"), we would
not treat failures to set-up an user port as fatal, but after this
commit we would, which is a regression for some systems where interfaces
may be declared in the Device Tree, but the underlying hardware may not
be present (pluggable daughter cards for instance).
Fixes: 1d27732f411d ("net: dsa: setup and teardown ports")
Signed-off-by: Florian Fainelli <f.fainelli(a)gmail.com>
Reviewed-by: Andrew Lunn <andrew(a)lunn.ch>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
---
net/dsa/dsa2.c | 8 +-------
1 file changed, 1 insertion(+), 7 deletions(-)
diff --git a/net/dsa/dsa2.c b/net/dsa/dsa2.c
index 716d265ba8ca..0f7f38c29579 100644
--- a/net/dsa/dsa2.c
+++ b/net/dsa/dsa2.c
@@ -461,18 +461,12 @@ static int dsa_tree_setup_switches(struct dsa_switch_tree *dst)
err = dsa_port_setup(dp);
if (err)
- goto ports_teardown;
+ continue;
}
}
return 0;
-ports_teardown:
- for (i = 0; i < port; i++)
- dsa_port_teardown(&ds->ports[i]);
-
- dsa_switch_teardown(ds);
-
switch_teardown:
for (i = 0; i < device; i++) {
ds = dst->ds[i];
--
2.17.1
From: Roman Penyaev <rpenyaev(a)suse.de>
Subject: epoll: call final ep_events_available() check under the lock
There is a possible race when ep_scan_ready_list() leaves ->rdllist and
->obflist empty for a short period of time although some events are
pending. It is quite likely that ep_events_available() observes empty
lists and goes to sleep. Since 339ddb53d373 ("fs/epoll: remove
unnecessary wakeups of nested epoll") we are conservative in wakeups
(there is only one place for wakeup and this is ep_poll_callback()), thus
ep_events_available() must always observe correct state of two lists. The
easiest and correct way is to do the final check under the lock. This
does not impact the performance, since lock is taken anyway for adding a
wait entry to the wait queue.
The discussion of the problem can be found here:
https://lore.kernel.org/linux-fsdevel/a2f22c3c-c25a-4bda-8339-a7bdaf17849e@…
In this patch barrierless __set_current_state() is used. This is safe
since waitqueue_active() is called under the same lock on wakeup side.
Short-circuit for fatal signals (i.e. fatal_signal_pending() check) is
moved to the line just before actual events harvesting routine. This is
fully compliant to what is said in the comment of the patch where the
actual fatal_signal_pending() check was added: c257a340ede0 ("fs, epoll:
short circuit fetching events if thread has been killed").
Link: http://lkml.kernel.org/r/20200505145609.1865152-1-rpenyaev@suse.de
Fixes: 339ddb53d373 ("fs/epoll: remove unnecessary wakeups of nested epoll")
Signed-off-by: Roman Penyaev <rpenyaev(a)suse.de>
Reported-by: Jason Baron <jbaron(a)akamai.com>
Reviewed-by: Jason Baron <jbaron(a)akamai.com>
Cc: Khazhismel Kumykov <khazhy(a)google.com>
Cc: Alexander Viro <viro(a)zeniv.linux.org.uk>
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
---
fs/eventpoll.c | 48 +++++++++++++++++++++++++++--------------------
1 file changed, 28 insertions(+), 20 deletions(-)
--- a/fs/eventpoll.c~epoll-call-final-ep_events_available-check-under-the-lock
+++ a/fs/eventpoll.c
@@ -1879,34 +1879,33 @@ fetch_events:
* event delivery.
*/
init_wait(&wait);
- write_lock_irq(&ep->lock);
- __add_wait_queue_exclusive(&ep->wq, &wait);
- write_unlock_irq(&ep->lock);
+ write_lock_irq(&ep->lock);
/*
- * We don't want to sleep if the ep_poll_callback() sends us
- * a wakeup in between. That's why we set the task state
- * to TASK_INTERRUPTIBLE before doing the checks.
+ * Barrierless variant, waitqueue_active() is called under
+ * the same lock on wakeup ep_poll_callback() side, so it
+ * is safe to avoid an explicit barrier.
*/
- set_current_state(TASK_INTERRUPTIBLE);
+ __set_current_state(TASK_INTERRUPTIBLE);
+
/*
- * Always short-circuit for fatal signals to allow
- * threads to make a timely exit without the chance of
- * finding more events available and fetching
- * repeatedly.
+ * Do the final check under the lock. ep_scan_ready_list()
+ * plays with two lists (->rdllist and ->ovflist) and there
+ * is always a race when both lists are empty for short
+ * period of time although events are pending, so lock is
+ * important.
*/
- if (fatal_signal_pending(current)) {
- res = -EINTR;
- break;
+ eavail = ep_events_available(ep);
+ if (!eavail) {
+ if (signal_pending(current))
+ res = -EINTR;
+ else
+ __add_wait_queue_exclusive(&ep->wq, &wait);
}
+ write_unlock_irq(&ep->lock);
- eavail = ep_events_available(ep);
- if (eavail)
- break;
- if (signal_pending(current)) {
- res = -EINTR;
+ if (eavail || res)
break;
- }
if (!schedule_hrtimeout_range(to, slack, HRTIMER_MODE_ABS)) {
timed_out = 1;
@@ -1927,6 +1926,15 @@ fetch_events:
}
send_events:
+ if (fatal_signal_pending(current)) {
+ /*
+ * Always short-circuit for fatal signals to allow
+ * threads to make a timely exit without the chance of
+ * finding more events available and fetching
+ * repeatedly.
+ */
+ res = -EINTR;
+ }
/*
* Try to transfer events to user space. In case we get 0 events and
* there's still timeout left over, we go trying again in search of
_
From: Yafang Shao <laoar.shao(a)gmail.com>
Subject: mm, memcg: fix inconsistent oom event behavior
A recent commit 9852ae3fe529 ("mm, memcg: consider subtrees in
memory.events") changes the behavior of memcg events, which will consider
subtrees in memory.events. But oom_kill event is a special one as it is
used in both cgroup1 and cgroup2. In cgroup1, it is displayed in
memory.oom_control. The file memory.oom_control is in both root memcg and
non root memcg, that is different with memory.event as it only in non-root
memcg. That commit is okay for cgroup2, but it is not okay for cgroup1 as
it will cause inconsistent behavior between root memcg and non-root memcg.
Here's an example on why this behavior is inconsistent in cgroup1.
root memcg
/
memcg foo
/
memcg bar
Suppose there's an oom_kill in memcg bar, then the oon_kill will be
root memcg : memory.oom_control(oom_kill) 0
/
memcg foo : memory.oom_control(oom_kill) 1
/
memcg bar : memory.oom_control(oom_kill) 1
For the non-root memcg, its memory.oom_control(oom_kill) includes its
descendants' oom_kill, but for root memcg, it doesn't include its
descendants' oom_kill. That means, memory.oom_control(oom_kill) has
different meanings in different memcgs. That is inconsistent. Then the
user has to know whether the memcg is root or not.
If we can't fully support it in cgroup1, for example by adding
memory.events.local into cgroup1 as well, then let's don't touch its
original behavior.
Link: http://lkml.kernel.org/r/20200502141055.7378-1-laoar.shao@gmail.com
Fixes: 9852ae3fe529 ("mm, memcg: consider subtrees in memory.events")
Signed-off-by: Yafang Shao <laoar.shao(a)gmail.com>
Reviewed-by: Shakeel Butt <shakeelb(a)google.com>
Acked-by: Johannes Weiner <hannes(a)cmpxchg.org>
Acked-by: Chris Down <chris(a)chrisdown.name>
Acked-by: Michal Hocko <mhocko(a)suse.com>
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
---
include/linux/memcontrol.h | 2 ++
1 file changed, 2 insertions(+)
--- a/include/linux/memcontrol.h~mm-memcg-fix-inconsistent-oom-event-behavior
+++ a/include/linux/memcontrol.h
@@ -783,6 +783,8 @@ static inline void memcg_memory_event(st
atomic_long_inc(&memcg->memory_events[event]);
cgroup_file_notify(&memcg->events_file);
+ if (!cgroup_subsys_on_dfl(memory_cgrp_subsys))
+ break;
if (cgrp_dfl_root.flags & CGRP_ROOT_MEMORY_LOCAL_EVENTS)
break;
} while ((memcg = parent_mem_cgroup(memcg)) &&
_
This is the start of the stable review cycle for the 5.4.41 release.
There are 90 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 Fri, 15 May 2020 09:41:20 +0000.
Anything received after that time might be too late.
The whole patch series can be found in one patch at:
https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.4.41-rc1…
or in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.4.y
and the diffstat can be found below.
thanks,
greg k-h
-------------
Pseudo-Shortlog of commits:
Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Linux 5.4.41-rc1
Amir Goldstein <amir73il(a)gmail.com>
fanotify: merge duplicate events on parent and child
Amir Goldstein <amir73il(a)gmail.com>
fsnotify: replace inode pointer with an object id
Christoph Hellwig <hch(a)lst.de>
bdi: add a ->dev_name field to struct backing_dev_info
Christoph Hellwig <hch(a)lst.de>
bdi: move bdi_dev_name out of line
Yafang Shao <laoar.shao(a)gmail.com>
mm, memcg: fix error return value of mem_cgroup_css_alloc()
Ivan Delalande <colona(a)arista.com>
scripts/decodecode: fix trapping instruction formatting
Julia Lawall <Julia.Lawall(a)inria.fr>
iommu/virtio: Reverse arguments to list_add
Josh Poimboeuf <jpoimboe(a)redhat.com>
objtool: Fix stack offset tracking for indirect CFAs
Arnd Bergmann <arnd(a)arndb.de>
netfilter: nf_osf: avoid passing pointer to local var
Guillaume Nault <gnault(a)redhat.com>
netfilter: nat: never update the UDP checksum when it's 0
Janakarajan Natarajan <Janakarajan.Natarajan(a)amd.com>
arch/x86/kvm/svm/sev.c: change flag passed to GUP fast in sev_pin_memory()
Suravee Suthikulpanit <suravee.suthikulpanit(a)amd.com>
KVM: x86: Fixes posted interrupt check for IRQs delivery modes
Josh Poimboeuf <jpoimboe(a)redhat.com>
x86/unwind/orc: Fix premature unwind stoppage due to IRET frames
Josh Poimboeuf <jpoimboe(a)redhat.com>
x86/unwind/orc: Fix error path for bad ORC entry type
Josh Poimboeuf <jpoimboe(a)redhat.com>
x86/unwind/orc: Prevent unwinding before ORC initialization
Miroslav Benes <mbenes(a)suse.cz>
x86/unwind/orc: Don't skip the first frame for inactive tasks
Jann Horn <jannh(a)google.com>
x86/entry/64: Fix unwind hints in rewind_stack_do_exit()
Josh Poimboeuf <jpoimboe(a)redhat.com>
x86/entry/64: Fix unwind hints in kernel exit path
Josh Poimboeuf <jpoimboe(a)redhat.com>
x86/entry/64: Fix unwind hints in register clearing code
Xiyu Yang <xiyuyang19(a)fudan.edu.cn>
batman-adv: Fix refcnt leak in batadv_v_ogm_process
Xiyu Yang <xiyuyang19(a)fudan.edu.cn>
batman-adv: Fix refcnt leak in batadv_store_throughput_override
Xiyu Yang <xiyuyang19(a)fudan.edu.cn>
batman-adv: Fix refcnt leak in batadv_show_throughput_override
George Spelvin <lkml(a)sdf.org>
batman-adv: fix batadv_nc_random_weight_tq
Tejun Heo <tj(a)kernel.org>
iocost: protect iocg->abs_vdebt with iocg->waitq.lock
Vincent Chen <vincent.chen(a)sifive.com>
riscv: set max_pfn to the PFN of the last page
Luis Chamberlain <mcgrof(a)kernel.org>
coredump: fix crash when umh is disabled
Oscar Carter <oscar.carter(a)gmx.com>
staging: gasket: Check the return value of gasket_get_bar_index()
Luis Henriques <lhenriques(a)suse.com>
ceph: demote quotarealm lookup warning to a debug message
Jeff Layton <jlayton(a)kernel.org>
ceph: fix endianness bug when handling MDS session feature bits
Henry Willard <henry.willard(a)oracle.com>
mm: limit boost_watermark on small zones
David Hildenbrand <david(a)redhat.com>
mm/page_alloc: fix watchdog soft lockups during set_zone_contiguous()
Khazhismel Kumykov <khazhy(a)google.com>
eventpoll: fix missing wakeup for ovflist in ep_poll_callback
Roman Penyaev <rpenyaev(a)suse.de>
epoll: atomically remove wait entry on wake up
Oleg Nesterov <oleg(a)redhat.com>
ipc/mqueue.c: change __do_notify() to bypass check_kill_permission()
H. Nikolaus Schaller <hns(a)goldelico.com>
drm: ingenic-drm: add MODULE_DEVICE_TABLE
Mark Rutland <mark.rutland(a)arm.com>
arm64: hugetlb: avoid potential NULL dereference
Marc Zyngier <maz(a)kernel.org>
KVM: arm64: Fix 32bit PC wrap-around
Marc Zyngier <maz(a)kernel.org>
KVM: arm: vgic: Fix limit condition when writing to GICD_I[CS]ACTIVER
Sean Christopherson <sean.j.christopherson(a)intel.com>
KVM: VMX: Explicitly clear RFLAGS.CF and RFLAGS.ZF in VM-Exit RSB path
Christian Borntraeger <borntraeger(a)de.ibm.com>
KVM: s390: Remove false WARN_ON_ONCE for the PQAP instruction
Jason A. Donenfeld <Jason(a)zx2c4.com>
crypto: arch/nhpoly1305 - process in explicit 4k chunks
Steven Rostedt (VMware) <rostedt(a)goodmis.org>
tracing: Add a vmalloc_sync_mappings() for safe measure
Oliver Neukum <oneukum(a)suse.com>
USB: serial: garmin_gps: add sanity checking for data length
Bryan O'Donoghue <bryan.odonoghue(a)linaro.org>
usb: chipidea: msm: Ensure proper controller reset using role switch API
Oliver Neukum <oneukum(a)suse.com>
USB: uas: add quirk for LaCie 2Big Quadra
Jason Gerecke <killertofu(a)gmail.com>
HID: wacom: Report 2nd-gen Intuos Pro S center button status over BT
Alan Stern <stern(a)rowland.harvard.edu>
HID: usbhid: Fix race between usbhid_close() and usbhid_stop()
Jason Gerecke <killertofu(a)gmail.com>
Revert "HID: wacom: generic: read the number of expected touches on a per collection basis"
Jere Leppänen <jere.leppanen(a)nokia.com>
sctp: Fix bundling of SHUTDOWN with COOKIE-ACK
Jason Gerecke <jason.gerecke(a)wacom.com>
HID: wacom: Read HID_DG_CONTACTMAX directly for non-generic devices
Dan Carpenter <dan.carpenter(a)oracle.com>
net: mvpp2: cls: Prevent buffer overflow in mvpp2_ethtool_cls_rule_del()
Dan Carpenter <dan.carpenter(a)oracle.com>
net: mvpp2: prevent buffer overflow in mvpp22_rss_ctx()
Moshe Shemesh <moshe(a)mellanox.com>
net/mlx5: Fix command entry leak in Internal Error State
Moshe Shemesh <moshe(a)mellanox.com>
net/mlx5: Fix forced completion access non initialized command entry
Erez Shitrit <erezsh(a)mellanox.com>
net/mlx5: DR, On creation set CQ's arm_db member to right value
Michael Chan <michael.chan(a)broadcom.com>
bnxt_en: Fix VLAN acceleration handling in bnxt_fix_features().
Michael Chan <michael.chan(a)broadcom.com>
bnxt_en: Return error when allocating zero size context memory.
Michael Chan <michael.chan(a)broadcom.com>
bnxt_en: Improve AER slot reset.
Vasundhara Volam <vasundhara-v.volam(a)broadcom.com>
bnxt_en: Reduce BNXT_MSIX_VEC_MAX value to supported CQs per PF.
Michael Chan <michael.chan(a)broadcom.com>
bnxt_en: Fix VF anti-spoof filter setup.
Toke Høiland-Jørgensen <toke(a)redhat.com>
tunnel: Propagate ECT(1) when decapsulating as recommended by RFC6040
Tuong Lien <tuong.t.lien(a)dektech.com.au>
tipc: fix partial topology connection closure
Eric Dumazet <edumazet(a)google.com>
sch_sfq: validate silly quantum values
Eric Dumazet <edumazet(a)google.com>
sch_choke: avoid potential panic in choke_reset()
Qiushi Wu <wu000273(a)umn.edu>
nfp: abm: fix a memory leak bug
Matt Jolly <Kangie(a)footclan.ninja>
net: usb: qmi_wwan: add support for DW5816e
Xiyu Yang <xiyuyang19(a)fudan.edu.cn>
net/tls: Fix sk_psock refcnt leak when in tls_data_ready()
Xiyu Yang <xiyuyang19(a)fudan.edu.cn>
net/tls: Fix sk_psock refcnt leak in bpf_exec_tx_verdict()
Anthony Felice <tony.felice(a)timesys.com>
net: tc35815: Fix phydev supported/advertising mask
Willem de Bruijn <willemb(a)google.com>
net: stricter validation of untrusted gso packets
Eric Dumazet <edumazet(a)google.com>
net_sched: sch_skbprio: add message validation to skbprio_change()
Tariq Toukan <tariqt(a)mellanox.com>
net/mlx4_core: Fix use of ENOSPC around mlx4_counter_alloc()
Scott Dial <scott(a)scottdial.com>
net: macsec: preserve ingress frame ordering
Dejin Zheng <zhengdejin5(a)gmail.com>
net: macb: fix an issue about leak related system resources
Florian Fainelli <f.fainelli(a)gmail.com>
net: dsa: Do not leave DSA master with NULL netdev_ops
Roman Mashak <mrv(a)mojatatu.com>
neigh: send protocol value in neighbor create notification
Jiri Pirko <jiri(a)mellanox.com>
mlxsw: spectrum_acl_tcam: Position vchunk in a vregion list properly
David Ahern <dsahern(a)kernel.org>
ipv6: Use global sernum for dst validation with nexthop objects
Eric Dumazet <edumazet(a)google.com>
fq_codel: fix TCA_FQ_CODEL_DROP_BATCH_SIZE sanity checks
Julia Lawall <Julia.Lawall(a)inria.fr>
dp83640: reverse arguments to list_add_tail
Jakub Kicinski <kuba(a)kernel.org>
devlink: fix return value after hitting end in region read
Shubhrajyoti Datta <shubhrajyoti.datta(a)xilinx.com>
tty: xilinx_uartps: Fix missing id assignment to the console
Nicolas Pitre <nico(a)fluxnic.net>
vt: fix unicode console freeing with a common interface
Evan Quan <evan.quan(a)amd.com>
drm/amdgpu: drop redundant cg/pg ungate on runpm enter
Evan Quan <evan.quan(a)amd.com>
drm/amdgpu: move kfd suspend after ip_suspend_phase1
Andy Shevchenko <andriy.shevchenko(a)linux.intel.com>
net: macb: Fix runtime PM refcounting
Masami Hiramatsu <mhiramat(a)kernel.org>
tracing/kprobes: Fix a double initialization typo
Sagi Grimberg <sagi(a)grimberg.me>
nvme: fix possible hang when ns scanning fails during error recovery
Christoph Hellwig <hch(a)lst.de>
nvme: refactor nvme_identify_ns_descs error handling
Matt Jolly <Kangie(a)footclan.ninja>
USB: serial: qcserial: Add DW5816e support
-------------
Diffstat:
Makefile | 4 +-
arch/arm/crypto/nhpoly1305-neon-glue.c | 2 +-
arch/arm64/crypto/nhpoly1305-neon-glue.c | 2 +-
arch/arm64/kvm/guest.c | 7 ++
arch/arm64/mm/hugetlbpage.c | 2 +
arch/riscv/mm/init.c | 3 +-
arch/s390/kvm/priv.c | 4 +-
arch/x86/crypto/nhpoly1305-avx2-glue.c | 2 +-
arch/x86/crypto/nhpoly1305-sse2-glue.c | 2 +-
arch/x86/entry/calling.h | 40 +++----
arch/x86/entry/entry_64.S | 9 +-
arch/x86/include/asm/kvm_host.h | 4 +-
arch/x86/include/asm/unwind.h | 2 +-
arch/x86/kernel/unwind_orc.c | 61 ++++++++---
arch/x86/kvm/svm.c | 2 +-
arch/x86/kvm/vmx/vmenter.S | 3 +
block/blk-iocost.c | 117 +++++++++++++--------
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 7 +-
drivers/gpu/drm/ingenic/ingenic-drm.c | 1 +
drivers/hid/usbhid/hid-core.c | 37 +++++--
drivers/hid/usbhid/usbhid.h | 1 +
drivers/hid/wacom_sys.c | 4 +-
drivers/hid/wacom_wac.c | 88 ++++------------
drivers/iommu/virtio-iommu.c | 2 +-
drivers/net/ethernet/broadcom/bnxt/bnxt.c | 20 ++--
drivers/net/ethernet/broadcom/bnxt/bnxt.h | 1 -
drivers/net/ethernet/broadcom/bnxt/bnxt_devlink.h | 2 +-
drivers/net/ethernet/broadcom/bnxt/bnxt_sriov.c | 10 +-
drivers/net/ethernet/cadence/macb_main.c | 24 ++---
drivers/net/ethernet/marvell/mvpp2/mvpp2_cls.c | 3 +
drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c | 2 +
drivers/net/ethernet/mellanox/mlx4/main.c | 4 +-
drivers/net/ethernet/mellanox/mlx5/core/cmd.c | 6 +-
.../ethernet/mellanox/mlx5/core/steering/dr_send.c | 14 ++-
.../ethernet/mellanox/mlxsw/spectrum_acl_tcam.c | 12 ++-
drivers/net/ethernet/netronome/nfp/abm/main.c | 1 +
drivers/net/ethernet/toshiba/tc35815.c | 2 +-
drivers/net/macsec.c | 3 +-
drivers/net/phy/dp83640.c | 2 +-
drivers/net/usb/qmi_wwan.c | 1 +
drivers/nvme/host/core.c | 28 +++--
drivers/staging/gasket/gasket_core.c | 4 +
drivers/tty/serial/xilinx_uartps.c | 1 +
drivers/tty/vt/vt.c | 9 +-
drivers/usb/chipidea/ci_hdrc_msm.c | 2 +-
drivers/usb/serial/garmin_gps.c | 4 +-
drivers/usb/serial/qcserial.c | 1 +
drivers/usb/storage/unusual_uas.h | 7 ++
fs/ceph/mds_client.c | 8 +-
fs/ceph/quota.c | 4 +-
fs/coredump.c | 8 ++
fs/eventpoll.c | 61 ++++++-----
fs/notify/fanotify/fanotify.c | 9 +-
fs/notify/inotify/inotify_fsnotify.c | 4 +-
fs/notify/inotify/inotify_user.c | 2 +-
include/linux/backing-dev-defs.h | 1 +
include/linux/backing-dev.h | 9 +-
include/linux/fsnotify_backend.h | 7 +-
include/linux/virtio_net.h | 26 ++++-
include/net/inet_ecn.h | 57 +++++++++-
include/net/ip6_fib.h | 4 +
include/net/net_namespace.h | 7 ++
ipc/mqueue.c | 34 ++++--
kernel/trace/trace.c | 13 +++
kernel/trace/trace_kprobe.c | 2 +-
kernel/umh.c | 5 +
mm/backing-dev.c | 13 ++-
mm/memcontrol.c | 15 +--
mm/page_alloc.c | 9 ++
net/batman-adv/bat_v_ogm.c | 2 +-
net/batman-adv/network-coding.c | 9 +-
net/batman-adv/sysfs.c | 3 +-
net/core/devlink.c | 5 +
net/core/neighbour.c | 6 +-
net/dsa/master.c | 3 +-
net/ipv6/route.c | 25 +++++
net/netfilter/nf_nat_proto.c | 4 +-
net/netfilter/nfnetlink_osf.c | 12 ++-
net/sched/sch_choke.c | 3 +-
net/sched/sch_fq_codel.c | 2 +-
net/sched/sch_sfq.c | 9 ++
net/sched/sch_skbprio.c | 3 +
net/sctp/sm_statefuns.c | 6 +-
net/tipc/topsrv.c | 5 +-
net/tls/tls_sw.c | 7 +-
scripts/decodecode | 2 +-
tools/cgroup/iocost_monitor.py | 7 +-
tools/objtool/check.c | 2 +-
virt/kvm/arm/hyp/aarch32.c | 8 +-
virt/kvm/arm/vgic/vgic-mmio.c | 4 +-
90 files changed, 648 insertions(+), 346 deletions(-)
A recent review of the Sony Xperia Development kernel tree [0] resulted
in the discovery of various patches which have been backported from
Mainline in order to fix an array of issues. These patches should be
applied to Stable such that everyone can benefit from them.
Note: The review is still on-going (~50%) - more to follow.
[0] https://github.com/sonyxperiadev/kernel
Alexey Brodkin (1):
devres: Align data[] to ARCH_KMALLOC_MINALIGN
Arun KS (1):
arm64: Fix size of __early_cpu_boot_status
Austin Kim (1):
mm/vmalloc.c: move 'area->pages' after if statement
Chris Lew (1):
soc: qcom: smem: Use le32_to_cpu for comparison
Dedy Lansky (2):
wil6210: fix temperature debugfs
wil6210: rate limit wil_rx_refill error
Geert Uytterhoeven (1):
clk: Fix debugfs_create_*() usage
Hamad Kadmany (1):
wil6210: increase firmware ready timeout
Hans Verkuil (1):
drm_dp_mst_topology: fix broken
drm_dp_sideband_parse_remote_dpcd_read()
Joe Moriarty (1):
drm: NULL pointer dereference [null-pointer-deref] (CWE 476) problem
Lior David (1):
wil6210: fix length check in __wmi_send
Mohit Aggarwal (1):
rtc: pm8xxx: Fix issue in RTC write path
Rob Clark (1):
drm/msm: stop abusing dma_map/unmap for cache
Rob Herring (1):
of: fix missing kobject init for !SYSFS && OF_DYNAMIC config
Roger Quadros (1):
usb: dwc3: don't set gadget->is_otg flag
Subhash Jadavani (2):
scsi: ufs: Fix error handing during hibern8 enter
scsi: ufs: ufs-qcom: remove broken hci version quirk
Taniya Das (1):
clk: qcom: rcg: Return failure for RCG update
Timur Tabi (1):
Revert "gpio: set up initial state from .get_direction()"
Venkat Gopalakrishnan (1):
scsi: ufs: make sure all interrupts are processed
Will Deacon (1):
arm64: traps: Don't print stack or raw PC/LR values in backtraces
arch/arm64/kernel/head.S | 2 +-
arch/arm64/kernel/process.c | 8 +--
arch/arm64/kernel/traps.c | 74 +-------------------
drivers/base/devres.c | 10 ++-
drivers/clk/clk.c | 30 ++++----
drivers/clk/qcom/clk-rcg2.c | 2 +-
drivers/gpio/gpiolib.c | 31 ++------
drivers/gpu/drm/drm_dp_mst_topology.c | 9 ++-
drivers/gpu/drm/msm/msm_gem.c | 4 +-
drivers/net/wireless/ath/wil6210/debugfs.c | 7 +-
drivers/net/wireless/ath/wil6210/interrupt.c | 22 +++++-
drivers/net/wireless/ath/wil6210/main.c | 2 +-
drivers/net/wireless/ath/wil6210/txrx.c | 4 +-
drivers/net/wireless/ath/wil6210/wmi.c | 2 +-
drivers/of/base.c | 3 -
drivers/rtc/rtc-pm8xxx.c | 49 ++++++++++---
drivers/scsi/ufs/ufs-qcom.c | 2 +-
drivers/scsi/ufs/ufshcd.c | 46 ++++++++----
drivers/soc/qcom/smem.c | 2 +-
drivers/usb/dwc3/gadget.c | 1 -
mm/vmalloc.c | 8 ++-
21 files changed, 152 insertions(+), 166 deletions(-)
--
2.25.1
The patch below does not apply to the 4.9-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable(a)vger.kernel.org>.
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
>From 027d0c7101f50cf03aeea9eebf484afd4920c8d3 Mon Sep 17 00:00:00 2001
From: Mark Rutland <mark.rutland(a)arm.com>
Date: Tue, 5 May 2020 13:59:30 +0100
Subject: [PATCH] arm64: hugetlb: avoid potential NULL dereference
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
The static analyzer in GCC 10 spotted that in huge_pte_alloc() we may
pass a NULL pmdp into pte_alloc_map() when pmd_alloc() returns NULL:
| CC arch/arm64/mm/pageattr.o
| CC arch/arm64/mm/hugetlbpage.o
| from arch/arm64/mm/hugetlbpage.c:10:
| arch/arm64/mm/hugetlbpage.c: In function ‘huge_pte_alloc’:
| ./arch/arm64/include/asm/pgtable-types.h:28:24: warning: dereference of NULL ‘pmdp’ [CWE-690] [-Wanalyzer-null-dereference]
| ./arch/arm64/include/asm/pgtable.h:436:26: note: in expansion of macro ‘pmd_val’
| arch/arm64/mm/hugetlbpage.c:242:10: note: in expansion of macro ‘pte_alloc_map’
| |arch/arm64/mm/hugetlbpage.c:232:10:
| |./arch/arm64/include/asm/pgtable-types.h:28:24:
| ./arch/arm64/include/asm/pgtable.h:436:26: note: in expansion of macro ‘pmd_val’
| arch/arm64/mm/hugetlbpage.c:242:10: note: in expansion of macro ‘pte_alloc_map’
This can only occur when the kernel cannot allocate a page, and so is
unlikely to happen in practice before other systems start failing.
We can avoid this by bailing out if pmd_alloc() fails, as we do earlier
in the function if pud_alloc() fails.
Fixes: 66b3923a1a0f ("arm64: hugetlb: add support for PTE contiguous bit")
Signed-off-by: Mark Rutland <mark.rutland(a)arm.com>
Reported-by: Kyrill Tkachov <kyrylo.tkachov(a)arm.com>
Cc: <stable(a)vger.kernel.org> # 4.5.x-
Cc: Will Deacon <will(a)kernel.org>
Signed-off-by: Catalin Marinas <catalin.marinas(a)arm.com>
diff --git a/arch/arm64/mm/hugetlbpage.c b/arch/arm64/mm/hugetlbpage.c
index bbeb6a5a6ba6..0be3355e3499 100644
--- a/arch/arm64/mm/hugetlbpage.c
+++ b/arch/arm64/mm/hugetlbpage.c
@@ -230,6 +230,8 @@ pte_t *huge_pte_alloc(struct mm_struct *mm,
ptep = (pte_t *)pudp;
} else if (sz == (CONT_PTE_SIZE)) {
pmdp = pmd_alloc(mm, pudp, addr);
+ if (!pmdp)
+ return NULL;
WARN_ON(addr & (sz - 1));
/*
As kernelci.org is expanding its functional testing
capabilities, the concept of boot testing is now being
deprecated.
Next Monday 18th May, the web dashboard on https://kernelci.org
will be updated to primarily show functional test results
rather than boot results. The Boots tab will still be
available until 5th June to ease the transition.
The new equivalent to boot testing is the *baseline* test suite
which also runs sanity checks using dmesg and bootrr[1].
Boot email reports will eventually be replaced with baseline
reports. For those of you already familiar with the test email
reports, they will be simplified to only show regressions with
links to the dashboard for all the details.
Some functional tests are already being run by kernelci.org,
results have only been shared by email so far but they will
become visible on the web dashboard next week. In particular:
v4l2-compliance, i-g-t for DRM/KMS and Panfrost,
suspend/resume...
And of course, a lot of functional test suites are in the
process of being added: kselftest, KUnit, LTP, xfstests,
extended i-g-t coverage and many more.
The detailed schedule is available on a GitHub issue[2].
Please let us know if you have any questions, comments or
concerns either in this thread, on kernelci(a)groups.io or IRC
#kernelci on Freenode.
Stay tuned!
Thanks,
Guillaume
[1] bootrr: https://github.com/kernelci/bootrr
[2] schedule: https://github.com/kernelci/kernelci-backend/issues/238
This is a note to let you know that I've just added the patch titled
staging: greybus: Fix uninitialized scalar variable
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 34625c1931f8204c234c532b446b9f53c69f4b68 Mon Sep 17 00:00:00 2001
From: Oscar Carter <oscar.carter(a)gmx.com>
Date: Sun, 10 May 2020 12:14:26 +0200
Subject: staging: greybus: Fix uninitialized scalar variable
In the "gb_tty_set_termios" function the "newline" variable is declared
but not initialized. So the "flow_control" member is not initialized and
the OR / AND operations with itself results in an undefined value in
this member.
The purpose of the code is to set the flow control type, so remove the
OR / AND self operator and set the value directly.
Addresses-Coverity-ID: 1374016 ("Uninitialized scalar variable")
Fixes: e55c25206d5c9 ("greybus: uart: Handle CRTSCTS flag in termios")
Signed-off-by: Oscar Carter <oscar.carter(a)gmx.com>
Cc: stable <stable(a)vger.kernel.org>
Link: https://lore.kernel.org/r/20200510101426.23631-1-oscar.carter@gmx.com
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/staging/greybus/uart.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/greybus/uart.c b/drivers/staging/greybus/uart.c
index 55c51143bb09..4ffb334cd5cd 100644
--- a/drivers/staging/greybus/uart.c
+++ b/drivers/staging/greybus/uart.c
@@ -537,9 +537,9 @@ static void gb_tty_set_termios(struct tty_struct *tty,
}
if (C_CRTSCTS(tty) && C_BAUD(tty) != B0)
- newline.flow_control |= GB_SERIAL_AUTO_RTSCTS_EN;
+ newline.flow_control = GB_SERIAL_AUTO_RTSCTS_EN;
else
- newline.flow_control &= ~GB_SERIAL_AUTO_RTSCTS_EN;
+ newline.flow_control = 0;
if (memcmp(&gb_tty->line_coding, &newline, sizeof(newline))) {
memcpy(&gb_tty->line_coding, &newline, sizeof(newline));
--
2.26.2
This is a note to let you know that I've just added the patch titled
staging: wfx: unlock on error path
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 f0b9d875faa4499afe3381404c3795e9da84bc00 Mon Sep 17 00:00:00 2001
From: Dan Carpenter <dan.carpenter(a)oracle.com>
Date: Tue, 12 May 2020 11:36:56 +0300
Subject: staging: wfx: unlock on error path
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
We need to release the tx_lock on the error path before returning.
Fixes: d1c015b4ef6f ("staging: wfx: rewrite wfx_hw_scan()")
Signed-off-by: Dan Carpenter <dan.carpenter(a)oracle.com>
Cc: stable <stable(a)vger.kernel.org>
Reviewed-by: Jérôme Pouiller <jerome.pouiller(a)silabs.com>
Link: https://lore.kernel.org/r/20200512083656.GA251760@mwanda
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/staging/wfx/scan.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/staging/wfx/scan.c b/drivers/staging/wfx/scan.c
index 6e1e50048651..9aa14331affd 100644
--- a/drivers/staging/wfx/scan.c
+++ b/drivers/staging/wfx/scan.c
@@ -57,8 +57,10 @@ static int send_scan_req(struct wfx_vif *wvif,
wvif->scan_abort = false;
reinit_completion(&wvif->scan_complete);
timeout = hif_scan(wvif, req, start_idx, i - start_idx);
- if (timeout < 0)
+ if (timeout < 0) {
+ wfx_tx_unlock(wvif->wdev);
return timeout;
+ }
ret = wait_for_completion_timeout(&wvif->scan_complete, timeout);
if (req->channels[start_idx]->max_power != wvif->vif->bss_conf.txpower)
hif_set_output_power(wvif, wvif->vif->bss_conf.txpower);
--
2.26.2
This is a note to let you know that I've just added the patch titled
staging: kpc2000: fix error return code in kp2000_pcie_probe()
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 b17884ccf29e127b16bba6aea1438c851c9f5af1 Mon Sep 17 00:00:00 2001
From: Wei Yongjun <weiyongjun1(a)huawei.com>
Date: Wed, 6 May 2020 13:47:35 +0000
Subject: staging: kpc2000: fix error return code in kp2000_pcie_probe()
Fix to return a negative error code from the error handling
case instead of 0, as done elsewhere in this function. Also
removed var 'rv' since we can use 'err' instead.
Fixes: 7dc7967fc39a ("staging: kpc2000: add initial set of Daktronics drivers")
Signed-off-by: Wei Yongjun <weiyongjun1(a)huawei.com>
Cc: stable <stable(a)vger.kernel.org>
Reviewed-by: Dan Carpenter <dan.carpenter(a)oracle.com>
Link: https://lore.kernel.org/r/20200506134735.102041-1-weiyongjun1@huawei.com
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/staging/kpc2000/kpc2000/core.c | 9 ++++-----
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/drivers/staging/kpc2000/kpc2000/core.c b/drivers/staging/kpc2000/kpc2000/core.c
index 7b00d7069e21..358d7b2f4ad1 100644
--- a/drivers/staging/kpc2000/kpc2000/core.c
+++ b/drivers/staging/kpc2000/kpc2000/core.c
@@ -298,7 +298,6 @@ static int kp2000_pcie_probe(struct pci_dev *pdev,
{
int err = 0;
struct kp2000_device *pcard;
- int rv;
unsigned long reg_bar_phys_addr;
unsigned long reg_bar_phys_len;
unsigned long dma_bar_phys_addr;
@@ -445,11 +444,11 @@ static int kp2000_pcie_probe(struct pci_dev *pdev,
if (err < 0)
goto err_release_dma;
- rv = request_irq(pcard->pdev->irq, kp2000_irq_handler, IRQF_SHARED,
- pcard->name, pcard);
- if (rv) {
+ err = request_irq(pcard->pdev->irq, kp2000_irq_handler, IRQF_SHARED,
+ pcard->name, pcard);
+ if (err) {
dev_err(&pcard->pdev->dev,
- "%s: failed to request_irq: %d\n", __func__, rv);
+ "%s: failed to request_irq: %d\n", __func__, err);
goto err_disable_msi;
}
--
2.26.2
The patch below does not apply to the 4.14-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable(a)vger.kernel.org>.
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
>From 027d0c7101f50cf03aeea9eebf484afd4920c8d3 Mon Sep 17 00:00:00 2001
From: Mark Rutland <mark.rutland(a)arm.com>
Date: Tue, 5 May 2020 13:59:30 +0100
Subject: [PATCH] arm64: hugetlb: avoid potential NULL dereference
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
The static analyzer in GCC 10 spotted that in huge_pte_alloc() we may
pass a NULL pmdp into pte_alloc_map() when pmd_alloc() returns NULL:
| CC arch/arm64/mm/pageattr.o
| CC arch/arm64/mm/hugetlbpage.o
| from arch/arm64/mm/hugetlbpage.c:10:
| arch/arm64/mm/hugetlbpage.c: In function ‘huge_pte_alloc’:
| ./arch/arm64/include/asm/pgtable-types.h:28:24: warning: dereference of NULL ‘pmdp’ [CWE-690] [-Wanalyzer-null-dereference]
| ./arch/arm64/include/asm/pgtable.h:436:26: note: in expansion of macro ‘pmd_val’
| arch/arm64/mm/hugetlbpage.c:242:10: note: in expansion of macro ‘pte_alloc_map’
| |arch/arm64/mm/hugetlbpage.c:232:10:
| |./arch/arm64/include/asm/pgtable-types.h:28:24:
| ./arch/arm64/include/asm/pgtable.h:436:26: note: in expansion of macro ‘pmd_val’
| arch/arm64/mm/hugetlbpage.c:242:10: note: in expansion of macro ‘pte_alloc_map’
This can only occur when the kernel cannot allocate a page, and so is
unlikely to happen in practice before other systems start failing.
We can avoid this by bailing out if pmd_alloc() fails, as we do earlier
in the function if pud_alloc() fails.
Fixes: 66b3923a1a0f ("arm64: hugetlb: add support for PTE contiguous bit")
Signed-off-by: Mark Rutland <mark.rutland(a)arm.com>
Reported-by: Kyrill Tkachov <kyrylo.tkachov(a)arm.com>
Cc: <stable(a)vger.kernel.org> # 4.5.x-
Cc: Will Deacon <will(a)kernel.org>
Signed-off-by: Catalin Marinas <catalin.marinas(a)arm.com>
diff --git a/arch/arm64/mm/hugetlbpage.c b/arch/arm64/mm/hugetlbpage.c
index bbeb6a5a6ba6..0be3355e3499 100644
--- a/arch/arm64/mm/hugetlbpage.c
+++ b/arch/arm64/mm/hugetlbpage.c
@@ -230,6 +230,8 @@ pte_t *huge_pte_alloc(struct mm_struct *mm,
ptep = (pte_t *)pudp;
} else if (sz == (CONT_PTE_SIZE)) {
pmdp = pmd_alloc(mm, pudp, addr);
+ if (!pmdp)
+ return NULL;
WARN_ON(addr & (sz - 1));
/*
When driver is set to enable bb credit recovery, the switch displayed
the setting as inactive. If the link bounces, it switches to Active.
During link up processing, the driver currently does a MBX_READ_SPARAM
followed by a MBX_CONFIG_LINK. These mbox commands are queued to be
executed, one at a time and the completion is processed by the worker
thread. Since the MBX_READ_SPARAM is done BEFORE the MBX_CONFIG_LINK,
the BB_SC_N bit is never set the the returned values. BB Credit recovery
status only gets set after the driver requests the feature in
CONFIG_LINK, which is done after the link up. Thus the ordering of
READ_SPARAM needs to follow the CONFIG_LINK.
Fix by reordering so that READ_SPARAM is done after CONFIG_LINK.
Added a HBA_DEFER_FLOGI flag so that any FLOGI handling waits until
after the READ_SPARAM is done so that the proper BB credit value is
set in the FLOGI payload.
Fixes: 6bfb16208298 ("scsi: lpfc: Fix configuration of BB credit recovery in service parameters")
Cc: <stable(a)vger.kernel.org> # v5.4+
Signed-off-by: Dick Kennedy <dick.kennedy(a)broadcom.com>
Signed-off-by: James Smart <jsmart2021(a)gmail.com>
---
drivers/scsi/lpfc/lpfc.h | 1 +
drivers/scsi/lpfc/lpfc_hbadisc.c | 59 ++++++++++++++++++++++++++--------------
2 files changed, 40 insertions(+), 20 deletions(-)
diff --git a/drivers/scsi/lpfc/lpfc.h b/drivers/scsi/lpfc/lpfc.h
index 04d73e2be373..3f2cb17c4574 100644
--- a/drivers/scsi/lpfc/lpfc.h
+++ b/drivers/scsi/lpfc/lpfc.h
@@ -749,6 +749,7 @@ struct lpfc_hba {
* capability
*/
#define HBA_FLOGI_ISSUED 0x100000 /* FLOGI was issued */
+#define HBA_DEFER_FLOGI 0x800000 /* Defer FLOGI till read_sparm cmpl */
uint32_t fcp_ring_in_use; /* When polling test if intr-hndlr active*/
struct lpfc_dmabuf slim2p;
diff --git a/drivers/scsi/lpfc/lpfc_hbadisc.c b/drivers/scsi/lpfc/lpfc_hbadisc.c
index dcc8999c6a68..6a2bdae0e52a 100644
--- a/drivers/scsi/lpfc/lpfc_hbadisc.c
+++ b/drivers/scsi/lpfc/lpfc_hbadisc.c
@@ -1163,13 +1163,16 @@ lpfc_mbx_cmpl_local_config_link(struct lpfc_hba *phba, LPFC_MBOXQ_t *pmb)
}
/* Start discovery by sending a FLOGI. port_state is identically
- * LPFC_FLOGI while waiting for FLOGI cmpl
+ * LPFC_FLOGI while waiting for FLOGI cmpl. Check if sending
+ * the FLOGI is being deferred till after MBX_READ_SPARAM completes.
*/
- if (vport->port_state != LPFC_FLOGI)
- lpfc_initial_flogi(vport);
- else if (vport->fc_flag & FC_PT2PT)
- lpfc_disc_start(vport);
-
+ if (vport->port_state != LPFC_FLOGI) {
+ if (!(phba->hba_flag & HBA_DEFER_FLOGI))
+ lpfc_initial_flogi(vport);
+ } else {
+ if (vport->fc_flag & FC_PT2PT)
+ lpfc_disc_start(vport);
+ }
return;
out:
@@ -3094,6 +3097,14 @@ lpfc_mbx_cmpl_read_sparam(struct lpfc_hba *phba, LPFC_MBOXQ_t *pmb)
lpfc_mbuf_free(phba, mp->virt, mp->phys);
kfree(mp);
mempool_free(pmb, phba->mbox_mem_pool);
+
+ /* Check if sending the FLOGI is being deferred to after we get
+ * up to date CSPs from MBX_READ_SPARAM.
+ */
+ if (phba->hba_flag & HBA_DEFER_FLOGI) {
+ lpfc_initial_flogi(vport);
+ phba->hba_flag &= ~HBA_DEFER_FLOGI;
+ }
return;
out:
@@ -3224,6 +3235,23 @@ lpfc_mbx_process_link_up(struct lpfc_hba *phba, struct lpfc_mbx_read_top *la)
}
lpfc_linkup(phba);
+ sparam_mbox = NULL;
+
+ if (!(phba->hba_flag & HBA_FCOE_MODE)) {
+ cfglink_mbox = mempool_alloc(phba->mbox_mem_pool, GFP_KERNEL);
+ if (!cfglink_mbox)
+ goto out;
+ vport->port_state = LPFC_LOCAL_CFG_LINK;
+ lpfc_config_link(phba, cfglink_mbox);
+ cfglink_mbox->vport = vport;
+ cfglink_mbox->mbox_cmpl = lpfc_mbx_cmpl_local_config_link;
+ rc = lpfc_sli_issue_mbox(phba, cfglink_mbox, MBX_NOWAIT);
+ if (rc == MBX_NOT_FINISHED) {
+ mempool_free(cfglink_mbox, phba->mbox_mem_pool);
+ goto out;
+ }
+ }
+
sparam_mbox = mempool_alloc(phba->mbox_mem_pool, GFP_KERNEL);
if (!sparam_mbox)
goto out;
@@ -3244,20 +3272,7 @@ lpfc_mbx_process_link_up(struct lpfc_hba *phba, struct lpfc_mbx_read_top *la)
goto out;
}
- if (!(phba->hba_flag & HBA_FCOE_MODE)) {
- cfglink_mbox = mempool_alloc(phba->mbox_mem_pool, GFP_KERNEL);
- if (!cfglink_mbox)
- goto out;
- vport->port_state = LPFC_LOCAL_CFG_LINK;
- lpfc_config_link(phba, cfglink_mbox);
- cfglink_mbox->vport = vport;
- cfglink_mbox->mbox_cmpl = lpfc_mbx_cmpl_local_config_link;
- rc = lpfc_sli_issue_mbox(phba, cfglink_mbox, MBX_NOWAIT);
- if (rc == MBX_NOT_FINISHED) {
- mempool_free(cfglink_mbox, phba->mbox_mem_pool);
- goto out;
- }
- } else {
+ if (phba->hba_flag & HBA_FCOE_MODE) {
vport->port_state = LPFC_VPORT_UNKNOWN;
/*
* Add the driver's default FCF record at FCF index 0 now. This
@@ -3314,6 +3329,10 @@ lpfc_mbx_process_link_up(struct lpfc_hba *phba, struct lpfc_mbx_read_top *la)
}
/* Reset FCF roundrobin bmask for new discovery */
lpfc_sli4_clear_fcf_rr_bmask(phba);
+ } else {
+ if (phba->bbcredit_support && phba->cfg_enable_bbcr &&
+ !(phba->link_flag & LS_LOOPBACK_MODE))
+ phba->hba_flag |= HBA_DEFER_FLOGI;
}
/* Prepare for LINK up registrations */
--
2.13.7
Avi Kivity reports that on fuse filesystems running in a user namespace
asyncronous fsync fails with EOVERFLOW.
The reason is that f_ops->fsync() is called with the creds of the kthread
performing aio work instead of the creds of the process originally
submitting IOCB_CMD_FSYNC.
Fuse sends the creds of the caller in the request header and it needs to
translate the uid and gid into the server's user namespace. Since the
kthread is running in init_user_ns, the translation will fail and the
operation returns an error.
It can be argued that fsync doesn't actually need any creds, but just
zeroing out those fields in the header (as with requests that currently
don't take creds) is a backward compatibility risk.
Instead of working around this issue in fuse, solve the core of the problem
by calling the filesystem with the proper creds.
Reported-by: Avi Kivity <avi(a)scylladb.com>
Tested-by: Giuseppe Scrivano <gscrivan(a)redhat.com>
Fixes: c9582eb0ff7d ("fuse: Fail all requests with invalid uids or gids")
Cc: stable(a)vger.kernel.org # 4.18+
Signed-off-by: Miklos Szeredi <mszeredi(a)redhat.com>
---
fs/aio.c | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/fs/aio.c b/fs/aio.c
index 5f3d3d814928..6483f9274d5e 100644
--- a/fs/aio.c
+++ b/fs/aio.c
@@ -176,6 +176,7 @@ struct fsync_iocb {
struct file *file;
struct work_struct work;
bool datasync;
+ struct cred *creds;
};
struct poll_iocb {
@@ -1589,8 +1590,11 @@ static int aio_write(struct kiocb *req, const struct iocb *iocb,
static void aio_fsync_work(struct work_struct *work)
{
struct aio_kiocb *iocb = container_of(work, struct aio_kiocb, fsync.work);
+ const struct cred *old_cred = override_creds(iocb->fsync.creds);
iocb->ki_res.res = vfs_fsync(iocb->fsync.file, iocb->fsync.datasync);
+ revert_creds(old_cred);
+ put_cred(iocb->fsync.creds);
iocb_put(iocb);
}
@@ -1604,6 +1608,10 @@ static int aio_fsync(struct fsync_iocb *req, const struct iocb *iocb,
if (unlikely(!req->file->f_op->fsync))
return -EINVAL;
+ req->creds = prepare_creds();
+ if (!req->creds)
+ return -ENOMEM;
+
req->datasync = datasync;
INIT_WORK(&req->work, aio_fsync_work);
schedule_work(&req->work);
--
2.21.1
Hi Stable folks,
please apply commit
27ed14d0ecb38516b6f3c6fdcd62c25c9454f979
Revert "serial/8250: Add support for NI-Serial PXI/PXIe+485 devices"
also to the stable tree.
My Fedora cannot switch baudrate or write to my serial port and
that makes me so sad.
I have this problem with kernel v5.6.11.
Thanks!
Linus Walleij
This series is to backport the upstream patches that fixes busy detection
for long operation mmc commands by implementing Tegra specific timeout
callback to switch between finite and infinite HW busy detection wait
modes.
Sowjanya Komatineni (2):
sdhci: tegra: Implement Tegra specific set_timeout callback
sdhci: tegra: Enable MMC_CAP_WAIT_WHILE_BUSY host capability
drivers/mmc/host/sdhci-tegra.c | 33 +++++++++++++++++++++++++++++++++
1 file changed, 33 insertions(+)
--
2.7.4
From: Kees Cook <keescook(a)chromium.org>
commit 7be3cb019db1cbd5fd5ffe6d64a23fefa4b6f229 upstream.
When brk was moved for binaries without an interpreter, it should have
been limited to ET_DYN only. In other words, the special case was an
ET_DYN that lacks an INTERP, not just an executable that lacks INTERP.
The bug manifested for giant static executables, where the brk would end
up in the middle of the text area on 32-bit architectures.
Reported-and-tested-by: Richard Kojedzinszky <richard(a)kojedz.in>
Fixes: bbdc6076d2e5 ("binfmt_elf: move brk out of mmap when doing direct loader exec")
Cc: stable(a)vger.kernel.org
Signed-off-by: Kees Cook <keescook(a)chromium.org>
Signed-off-by: Linus Torvalds <torvalds(a)linux-foundation.org>
Signed-off-by: Nobuhiro Iwamatsu <nobuhiro1.iwamatsu(a)toshiba.co.jp>
---
fs/binfmt_elf.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/fs/binfmt_elf.c b/fs/binfmt_elf.c
index a6857e9bd4460..164e5fedd7b6a 100644
--- a/fs/binfmt_elf.c
+++ b/fs/binfmt_elf.c
@@ -1104,7 +1104,8 @@ static int load_elf_binary(struct linux_binprm *bprm)
* (since it grows up, and may collide early with the stack
* growing down), and into the unused ELF_ET_DYN_BASE region.
*/
- if (IS_ENABLED(CONFIG_ARCH_HAS_ELF_RANDOMIZE) && !interpreter)
+ if (IS_ENABLED(CONFIG_ARCH_HAS_ELF_RANDOMIZE) &&
+ loc->elf_ex.e_type == ET_DYN && !interpreter)
current->mm->brk = current->mm->start_brk =
ELF_ET_DYN_BASE;
--
2.26.0
From: Xing Li <lixing(a)loongson.cn>
If a CPU support more than 32bit vmbits (which is true for 64bit CPUs),
VPN2_MASK set to fixed 0xffffe000 will lead to a wrong EntryHi in some
functions such as _kvm_mips_host_tlb_inv().
The cpu_vmbits definition of 32bit CPU in cpu-features.h is 31, so we
still use the old definition.
Cc: stable(a)vger.kernel.org
Reviewed-by: Aleksandar Markovic <aleksandar.qemu.devel(a)gmail.com>
Signed-off-by: Xing Li <lixing(a)loongson.cn>
[Huacai: Improve commit messages]
Signed-off-by: Huacai Chen <chenhc(a)lemote.com>
---
arch/mips/include/asm/kvm_host.h | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/mips/include/asm/kvm_host.h b/arch/mips/include/asm/kvm_host.h
index a01cee9..caa2b936 100644
--- a/arch/mips/include/asm/kvm_host.h
+++ b/arch/mips/include/asm/kvm_host.h
@@ -274,7 +274,11 @@ enum emulation_result {
#define MIPS3_PG_SHIFT 6
#define MIPS3_PG_FRAME 0x3fffffc0
+#if defined(CONFIG_64BIT)
+#define VPN2_MASK GENMASK(cpu_vmbits - 1, 13)
+#else
#define VPN2_MASK 0xffffe000
+#endif
#define KVM_ENTRYHI_ASID cpu_asid_mask(&boot_cpu_data)
#define TLB_IS_GLOBAL(x) ((x).tlb_lo[0] & (x).tlb_lo[1] & ENTRYLO_G)
#define TLB_VPN2(x) ((x).tlb_hi & VPN2_MASK)
--
2.7.0
Not sure nand_cleanup() is the right function to call here but in any
case it is not nand_release(). Indeed, even a comment says that
calling nand_release() is a bit of a hack as there is no MTD device to
unregister. So switch to nand_cleanup() for now and drop this
comment.
There is no Fixes tag applying here as the use of nand_release()
in this driver predates by far the introduction of nand_cleanup() in
commit d44154f969a4 ("mtd: nand: Provide nand_cleanup() function to free NAND related resources")
which makes this change possible. However, pointing this commit as the
culprit for backporting purposes makes sense even if it did not intruce
any bug.
Fixes: d44154f969a4 ("mtd: nand: Provide nand_cleanup() function to free NAND related resources")
Signed-off-by: Miquel Raynal <miquel.raynal(a)bootlin.com>
Cc: stable(a)vger.kernel.org
---
drivers/mtd/nand/raw/diskonchip.c | 7 ++-----
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/drivers/mtd/nand/raw/diskonchip.c b/drivers/mtd/nand/raw/diskonchip.c
index c2a391ad2c35..baabc6633557 100644
--- a/drivers/mtd/nand/raw/diskonchip.c
+++ b/drivers/mtd/nand/raw/diskonchip.c
@@ -1609,13 +1609,10 @@ static int __init doc_probe(unsigned long physadr)
numchips = doc2001_init(mtd);
if ((ret = nand_scan(nand, numchips)) || (ret = doc->late_init(mtd))) {
- /* DBB note: i believe nand_release is necessary here, as
+ /* DBB note: i believe nand_cleanup is necessary here, as
buffers may have been allocated in nand_base. Check with
Thomas. FIX ME! */
- /* nand_release will call mtd_device_unregister, but we
- haven't yet added it. This is handled without incident by
- mtd_device_unregister, as far as I can tell. */
- nand_release(nand);
+ nand_cleanup(nand);
goto fail;
}
--
2.20.1
Here are some fixes that required backporting for 4.4. All of them
are already present in (or queued for) later stable branches.
Ben.
--
Ben Hutchings, Software Developer Codethink Ltd
https://www.codethink.co.uk/ Dale House, 35 Dale Street
Manchester, M1 2HF, United Kingdom
From: Marcos Paulo de Souza <mpdesouza(a)suse.com>
[PROBLEM]
Whenever a chown is executed, all capabilities of the file being touched are
lost. When doing incremental send with a file with capabilities, there is a
situation where the capability can be lost in the receiving side. The
sequence of actions bellow shows the problem:
$ mount /dev/sda fs1
$ mount /dev/sdb fs2
$ touch fs1/foo.bar
$ setcap cap_sys_nice+ep fs1/foo.bar
$ btrfs subvol snap -r fs1 fs1/snap_init
$ btrfs send fs1/snap_init | btrfs receive fs2
$ chgrp adm fs1/foo.bar
$ setcap cap_sys_nice+ep fs1/foo.bar
$ btrfs subvol snap -r fs1 fs1/snap_complete
$ btrfs subvol snap -r fs1 fs1/snap_incremental
$ btrfs send fs1/snap_complete | btrfs receive fs2
$ btrfs send -p fs1/snap_init fs1/snap_incremental | btrfs receive fs2
At this point, only a chown was emitted by "btrfs send" since only the group
was changed. This makes the cap_sys_nice capability to be dropped from
fs2/snap_incremental/foo.bar
[FIX]
Only emit capabilities after chown is emitted. The current code
first checks for xattrs that are new/changed, emits them, and later emit
the chown. Now, __process_new_xattr skips capabilities, letting only
finish_inode_if_needed to emit them, if they exist, for the inode being
processed.
This behavior was being worked around in "btrfs receive"
side by caching the capability and only applying it after chown. Now,
xattrs are only emmited _after_ chown, making that hack not needed
anymore.
Link: https://github.com/kdave/btrfs-progs/issues/202
CC: stable(a)vger.kernel.org
Suggested-by: Filipe Manana <fdmanana(a)suse.com>
Reviewed-by: Filipe Manana <fdmanana(a)suse.com>
Signed-off-by: Marcos Paulo de Souza <mpdesouza(a)suse.com>
---
Changes from v2:
* Tag Stable correctly
* Forgot to add v2 in the latest patch. Now set to v3 to avoid confusion
Changes from v1:
* Constify name var in send_capabilities function (suggested by Filipe)
* Changed btrfs_alloc_path -> alloc_path_for_send() in send_capabilities
(suggested by Filipe)
* Removed a redundant sentence in the commit message (suggested by Filipe)
* Added the Reviewed-By tag from Filipe
Changes from RFC:
* Explained about chown + drop capabilities problem in the commit message (suggested
by Filipe and David)
* Changed the commit message to show describe the fix (suggested by Filipe)
* Skip the xattr in __process_new_xattr if it's a capability, since it'll be
handled in finish_inode_if_needed now (suggested by Filipe).
* Created function send_capabilities to query if the inode has caps, and if
yes, emit them.
* Call send_capabilities in finish_inode_if_needed _after_ the needs_chown
check. (suggested by Filipe)
fs/btrfs/send.c | 69 +++++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 69 insertions(+)
diff --git a/fs/btrfs/send.c b/fs/btrfs/send.c
index 6b86841315be..2b378e32e7dc 100644
--- a/fs/btrfs/send.c
+++ b/fs/btrfs/send.c
@@ -23,6 +23,7 @@
#include "btrfs_inode.h"
#include "transaction.h"
#include "compression.h"
+#include "xattr.h"
/*
* Maximum number of references an extent can have in order for us to attempt to
@@ -4545,6 +4546,10 @@ static int __process_new_xattr(int num, struct btrfs_key *di_key,
struct fs_path *p;
struct posix_acl_xattr_header dummy_acl;
+ /* capabilities are emitted by finish_inode_if_needed */
+ if (!strncmp(name, XATTR_NAME_CAPS, name_len))
+ return 0;
+
p = fs_path_alloc();
if (!p)
return -ENOMEM;
@@ -5107,6 +5112,66 @@ static int send_extent_data(struct send_ctx *sctx,
return 0;
}
+/*
+ * Search for a capability xattr related to sctx->cur_ino. If the capability if
+ * found, call send_set_xattr function to emit it.
+ *
+ * Return %0 if there isn't a capability, or when the capability was emitted
+ * successfully, or < %0 if an error occurred.
+ */
+static int send_capabilities(struct send_ctx *sctx)
+{
+ struct fs_path *fspath = NULL;
+ struct btrfs_path *path;
+ struct btrfs_dir_item *di;
+ struct extent_buffer *leaf;
+ unsigned long data_ptr;
+ const char *name = XATTR_NAME_CAPS;
+ char *buf = NULL;
+ int buf_len;
+ int ret = 0;
+
+ path = alloc_path_for_send();
+ if (!path)
+ return -ENOMEM;
+
+ di = btrfs_lookup_xattr(NULL, sctx->send_root, path, sctx->cur_ino,
+ name, strlen(name), 0);
+ if (!di) {
+ /* there is no xattr for this inode */
+ goto out;
+ } else if (IS_ERR(di)) {
+ ret = PTR_ERR(di);
+ goto out;
+ }
+
+ leaf = path->nodes[0];
+ buf_len = btrfs_dir_data_len(leaf, di);
+
+ fspath = fs_path_alloc();
+ buf = kmalloc(buf_len, GFP_KERNEL);
+ if (!fspath || !buf) {
+ ret = -ENOMEM;
+ goto out;
+ }
+
+ ret = get_cur_path(sctx, sctx->cur_ino, sctx->cur_inode_gen, fspath);
+ if (ret < 0)
+ goto out;
+
+ data_ptr = (unsigned long)((char *)(di + 1) +
+ btrfs_dir_name_len(leaf, di));
+ read_extent_buffer(leaf, buf, data_ptr,
+ btrfs_dir_data_len(leaf, di));
+
+ ret = send_set_xattr(sctx, fspath, name, strlen(name), buf, buf_len);
+out:
+ kfree(buf);
+ fs_path_free(fspath);
+ btrfs_free_path(path);
+ return ret;
+}
+
static int clone_range(struct send_ctx *sctx,
struct clone_root *clone_root,
const u64 disk_byte,
@@ -6010,6 +6075,10 @@ static int finish_inode_if_needed(struct send_ctx *sctx, int at_end)
goto out;
}
+ ret = send_capabilities(sctx);
+ if (ret < 0)
+ goto out;
+
/*
* If other directory inodes depended on our current directory
* inode's move/rename, now do their move/rename operations.
--
2.25.1
nand_release() is supposed be called after MTD device registration.
Here, only nand_scan() happened, so use nand_cleanup() instead.
There is no real Fixes tag applying here as the use of nand_release()
in this driver predates by far the introduction of nand_cleanup() in
commit d44154f969a4 ("mtd: nand: Provide nand_cleanup() function to free NAND related resources")
which makes this change possible. However, pointing this commit as the
culprit for backporting purposes makes sense even if this commit is not
introducing any bug.
Fixes: d44154f969a4 ("mtd: nand: Provide nand_cleanup() function to free NAND related resources")
Signed-off-by: Miquel Raynal <miquel.raynal(a)bootlin.com>
Cc: stable(a)vger.kernel.org
---
drivers/mtd/nand/raw/tmio_nand.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/mtd/nand/raw/tmio_nand.c b/drivers/mtd/nand/raw/tmio_nand.c
index db030f1701ee..4e9a6d94f6e8 100644
--- a/drivers/mtd/nand/raw/tmio_nand.c
+++ b/drivers/mtd/nand/raw/tmio_nand.c
@@ -448,7 +448,7 @@ static int tmio_probe(struct platform_device *dev)
if (!retval)
return retval;
- nand_release(nand_chip);
+ nand_cleanup(nand_chip);
err_irq:
tmio_hw_stop(dev, tmio);
--
2.20.1
nand_release() is supposed be called after MTD device registration.
Here, only nand_scan() happened, so use nand_cleanup() instead.
There is no real Fixes tag applying here as the use of nand_release()
in this driver predates the introduction of nand_cleanup() in
commit d44154f969a4 ("mtd: nand: Provide nand_cleanup() function to free NAND related resources")
which makes this change possible. However, pointing this commit as the
culprit for backporting purposes makes sense even if this commit is not
introducing any bug.
Fixes: d44154f969a4 ("mtd: nand: Provide nand_cleanup() function to free NAND related resources")
Signed-off-by: Miquel Raynal <miquel.raynal(a)bootlin.com>
Cc: stable(a)vger.kernel.org
Cc: Xiaolei Li <xiaolei.li(a)mediatek.com>
---
drivers/mtd/nand/raw/mtk_nand.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/mtd/nand/raw/mtk_nand.c b/drivers/mtd/nand/raw/mtk_nand.c
index e7ec30e784fd..9dad08bed2bb 100644
--- a/drivers/mtd/nand/raw/mtk_nand.c
+++ b/drivers/mtd/nand/raw/mtk_nand.c
@@ -1419,7 +1419,7 @@ static int mtk_nfc_nand_chip_init(struct device *dev, struct mtk_nfc *nfc,
ret = mtd_device_register(mtd, NULL, 0);
if (ret) {
dev_err(dev, "mtd parse partition error\n");
- nand_release(nand);
+ nand_cleanup(nand);
return ret;
}
--
2.20.1
nand_release() is supposed be called after MTD device registration.
Here, only nand_scan() happened, so use nand_cleanup() instead.
There is no Fixes tag applying here as the use of nand_release()
in this driver predates by far the introduction of nand_cleanup() in
commit d44154f969a4 ("mtd: nand: Provide nand_cleanup() function to free NAND related resources")
which makes this change possible. However, pointing this commit as the
culprit for backporting purposes makes sense.
Fixes: d44154f969a4 ("mtd: nand: Provide nand_cleanup() function to free NAND related resources")
Signed-off-by: Miquel Raynal <miquel.raynal(a)bootlin.com>
Cc: stable(a)vger.kernel.org
---
drivers/mtd/nand/raw/sharpsl.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/mtd/nand/raw/sharpsl.c b/drivers/mtd/nand/raw/sharpsl.c
index b47a9eaff89b..d8c52a016080 100644
--- a/drivers/mtd/nand/raw/sharpsl.c
+++ b/drivers/mtd/nand/raw/sharpsl.c
@@ -183,7 +183,7 @@ static int sharpsl_nand_probe(struct platform_device *pdev)
return 0;
err_add:
- nand_release(this);
+ nand_cleanup(this);
err_scan:
iounmap(sharpsl->io);
--
2.20.1
nand_release() is supposed be called after MTD device registration.
Here, only nand_scan() happened, so use nand_cleanup() instead.
There is no real Fixes tag applying here as the use of nand_release()
in this driver predates the introduction of nand_cleanup() in
commit d44154f969a4 ("mtd: nand: Provide nand_cleanup() function to free NAND related resources")
which makes this change possible. However, pointing this commit as the
culprit for backporting purposes makes sense even if this commit is not
introducing any bug.
Fixes: d44154f969a4 ("mtd: nand: Provide nand_cleanup() function to free NAND related resources")
Signed-off-by: Miquel Raynal <miquel.raynal(a)bootlin.com>
Cc: stable(a)vger.kernel.org
---
drivers/mtd/nand/raw/xway_nand.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/mtd/nand/raw/xway_nand.c b/drivers/mtd/nand/raw/xway_nand.c
index 834f794816a9..018311dc8fe1 100644
--- a/drivers/mtd/nand/raw/xway_nand.c
+++ b/drivers/mtd/nand/raw/xway_nand.c
@@ -210,7 +210,7 @@ static int xway_nand_probe(struct platform_device *pdev)
err = mtd_device_register(mtd, NULL, 0);
if (err)
- nand_release(&data->chip);
+ nand_cleanup(&data->chip);
return err;
}
--
2.20.1
nand_release() is supposed be called after MTD device registration.
Here, only nand_scan() happened, so use nand_cleanup() instead.
There is no real Fixes tag applying here as the use of nand_release()
in this driver predates the introduction of nand_cleanup() in
commit d44154f969a4 ("mtd: nand: Provide nand_cleanup() function to free NAND related resources")
which makes this change possible. Hence, pointing it as the commit to
fix for backporting purposes, even if this commit is not introducing
any bug makes sense.
Fixes: d44154f969a4 ("mtd: nand: Provide nand_cleanup() function to free NAND related resources")
Signed-off-by: Miquel Raynal <miquel.raynal(a)bootlin.com>
Cc: stable(a)vger.kernel.org
Cc: Paul Cercueil <paul(a)crapouillou.net>
Cc: Harvey Hunt <harveyhuntnexus(a)gmail.com>
---
drivers/mtd/nand/raw/ingenic/ingenic_nand_drv.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/mtd/nand/raw/ingenic/ingenic_nand_drv.c b/drivers/mtd/nand/raw/ingenic/ingenic_nand_drv.c
index 935c4902ada7..6e90c2d5cb3a 100644
--- a/drivers/mtd/nand/raw/ingenic/ingenic_nand_drv.c
+++ b/drivers/mtd/nand/raw/ingenic/ingenic_nand_drv.c
@@ -376,7 +376,7 @@ static int ingenic_nand_init_chip(struct platform_device *pdev,
ret = mtd_device_register(mtd, NULL, 0);
if (ret) {
- nand_release(chip);
+ nand_cleanup(chip);
return ret;
}
--
2.20.1
nand_release() is supposed be called after MTD device registration.
Here, only nand_scan() happened, so use nand_cleanup() instead.
There is no real Fixes tag applying here as the use of nand_release()
in this driver predates by far the introduction of nand_cleanup() in
commit d44154f969a4 ("mtd: nand: Provide nand_cleanup() function to free NAND related resources")
which makes this change possible, hence pointing it as the commit to
fix for backporting purposes, even if this commit is not introducing
any bug.
Fixes: d44154f969a4 ("mtd: nand: Provide nand_cleanup() function to free NAND related resources")
Signed-off-by: Miquel Raynal <miquel.raynal(a)bootlin.com>
Cc: stable(a)vger.kernel.org
---
drivers/mtd/nand/raw/plat_nand.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/mtd/nand/raw/plat_nand.c b/drivers/mtd/nand/raw/plat_nand.c
index dc0f3074ddbf..3a495b233443 100644
--- a/drivers/mtd/nand/raw/plat_nand.c
+++ b/drivers/mtd/nand/raw/plat_nand.c
@@ -92,7 +92,7 @@ static int plat_nand_probe(struct platform_device *pdev)
if (!err)
return err;
- nand_release(&data->chip);
+ nand_cleanup(&data->chip);
out:
if (pdata->ctrl.remove)
pdata->ctrl.remove(pdev);
--
2.20.1
nand_cleanup() is supposed to be called on error after a successful
call to nand_scan() to free all NAND resources.
There is no real Fixes tag applying here as the use of nand_release()
in this driver predates by far the introduction of nand_cleanup() in
commit d44154f969a4 ("mtd: nand: Provide nand_cleanup() function to free NAND related resources")
which makes this change possible, hence pointing it as the commit to
fix for backporting purposes, even if this commit is not introducing
any bug.
Fixes: d44154f969a4 ("mtd: nand: Provide nand_cleanup() function to free NAND related resources")
Signed-off-by: Miquel Raynal <miquel.raynal(a)bootlin.com>
Cc: stable(a)vger.kernel.org
---
drivers/mtd/nand/raw/pasemi_nand.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/mtd/nand/raw/pasemi_nand.c b/drivers/mtd/nand/raw/pasemi_nand.c
index 9cfe7395172a..be40b2f32237 100644
--- a/drivers/mtd/nand/raw/pasemi_nand.c
+++ b/drivers/mtd/nand/raw/pasemi_nand.c
@@ -146,7 +146,7 @@ static int pasemi_nand_probe(struct platform_device *ofdev)
if (mtd_device_register(pasemi_nand_mtd, NULL, 0)) {
dev_err(dev, "Unable to register MTD device\n");
err = -ENODEV;
- goto out_lpc;
+ goto out_cleanup_nand;
}
dev_info(dev, "PA Semi NAND flash at %pR, control at I/O %x\n", &res,
@@ -154,6 +154,8 @@ static int pasemi_nand_probe(struct platform_device *ofdev)
return 0;
+out_cleanup:
+ nand_cleanup(chip);
out_lpc:
release_region(lpcctl, 4);
out_ior:
--
2.20.1
nand_release() is supposed be called after MTD device registration.
Here, only nand_scan() happened, so use nand_cleanup() instead.
There is no real Fixes tag applying here as the use of nand_release()
in this driver predates by far the introduction of nand_cleanup() in
commit d44154f969a4 ("mtd: nand: Provide nand_cleanup() function to free NAND related resources")
which makes this change possible. However, pointing this commit as the
culprit for backporting purposes makes sense even if this commit is not
introducing any bug.
Fixes: d44154f969a4 ("mtd: nand: Provide nand_cleanup() function to free NAND related resources")
Signed-off-by: Miquel Raynal <miquel.raynal(a)bootlin.com>
Cc: stable(a)vger.kernel.org
---
drivers/mtd/nand/raw/orion_nand.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/mtd/nand/raw/orion_nand.c b/drivers/mtd/nand/raw/orion_nand.c
index d27b39a7223c..a3dcdf25f5f2 100644
--- a/drivers/mtd/nand/raw/orion_nand.c
+++ b/drivers/mtd/nand/raw/orion_nand.c
@@ -180,7 +180,7 @@ static int __init orion_nand_probe(struct platform_device *pdev)
mtd->name = "orion_nand";
ret = mtd_device_register(mtd, board->parts, board->nr_parts);
if (ret) {
- nand_release(nc);
+ nand_cleanup(nc);
goto no_dev;
}
--
2.20.1
nand_release() is supposed be called after MTD device registration.
Here, only nand_scan() happened, so use nand_cleanup() instead.
There is no real Fixes tag applying here as the use of nand_release()
in this driver predates by far the introduction of nand_cleanup() in
commit d44154f969a4 ("mtd: nand: Provide nand_cleanup() function to free NAND related resources")
which makes this change possible. However, pointing this commit as the
culprit for backporting purposes makes sense even if this commit is not
introducing any bug.
Fixes: d44154f969a4 ("mtd: nand: Provide nand_cleanup() function to free NAND related resources")
Signed-off-by: Miquel Raynal <miquel.raynal(a)bootlin.com>
Cc: stable(a)vger.kernel.org
---
drivers/mtd/nand/raw/socrates_nand.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/mtd/nand/raw/socrates_nand.c b/drivers/mtd/nand/raw/socrates_nand.c
index 20f40c0e812c..7c94fc51a611 100644
--- a/drivers/mtd/nand/raw/socrates_nand.c
+++ b/drivers/mtd/nand/raw/socrates_nand.c
@@ -169,7 +169,7 @@ static int socrates_nand_probe(struct platform_device *ofdev)
if (!res)
return res;
- nand_release(nand_chip);
+ nand_cleanup(nand_chip);
out:
iounmap(host->io_base);
--
2.20.1
From: Marcos Paulo de Souza <mpdesouza(a)suse.com>
[PROBLEM]
Whenever a chown is executed, all capabilities of the file being touched are
lost. When doing incremental send with a file with capabilities, there is a
situation where the capability can be lost in the receiving side. The
sequence of actions bellow shows the problem:
$ mount /dev/sda fs1
$ mount /dev/sdb fs2
$ touch fs1/foo.bar
$ setcap cap_sys_nice+ep fs1/foo.bar
$ btrfs subvol snap -r fs1 fs1/snap_init
$ btrfs send fs1/snap_init | btrfs receive fs2
$ chgrp adm fs1/foo.bar
$ setcap cap_sys_nice+ep fs1/foo.bar
$ btrfs subvol snap -r fs1 fs1/snap_complete
$ btrfs subvol snap -r fs1 fs1/snap_incremental
$ btrfs send fs1/snap_complete | btrfs receive fs2
$ btrfs send -p fs1/snap_init fs1/snap_incremental | btrfs receive fs2
At this point, only a chown was emitted by "btrfs send" since only the group
was changed. This makes the cap_sys_nice capability to be dropped from
fs2/snap_incremental/foo.bar
[FIX]
Only emit capabilities after chown is emitted. The current code
first checks for xattrs that are new/changed, emits them, and later emit
the chown. Now, __process_new_xattr skips capabilities, letting only
finish_inode_if_needed to emit them, if they exist, for the inode being
processed.
This behavior was being worked around in "btrfs receive"
side by caching the capability and only applying it after chown. Now,
xattrs are only emmited _after_ chown, making that hack not needed
anymore.
Link: https://github.com/kdave/btrfs-progs/issues/202
CC: stable(a)vger.kernel.org
Suggested-by: Filipe Manana <fdmanana(a)suse.com>
Reviewed-by: Filipe Manana <fdmanana(a)suse.com>
Signed-off-by: Marcos Paulo de Souza <mpdesouza(a)suse.com>
---
Changes from v3:
* Fixed a comment that didn't start with an uppercase (suggested by David)
* Removed a temporary var and used XATTR_NAME_CAPS directly (suggested by
David)
* Removed the (char *) cast before assigning the data_ptr (suggested by David)
* Use buf_len previously computed instead of calling btrfs_dir_data_len twice
(suggested by David)
Changes from v2:
* Tag Stable correctly
* Forgot to add v2 in the latest patch. Now set to v3 to avoid confusion
Changes from v1:
* Constify name var in send_capabilities function (suggested by Filipe)
* Changed btrfs_alloc_path -> alloc_path_for_send() in send_capabilities
(suggested by Filipe)
* Removed a redundant sentence in the commit message (suggested by Filipe)
* Added the Reviewed-By tag from Filipe
Changes from RFC:
* Explained about chown + drop capabilities problem in the commit message (suggested
by Filipe and David)
* Changed the commit message to show describe the fix (suggested by Filipe)
* Skip the xattr in __process_new_xattr if it's a capability, since it'll be
handled in finish_inode_if_needed now (suggested by Filipe).
* Created function send_capabilities to query if the inode has caps, and if
yes, emit them.
* Call send_capabilities in finish_inode_if_needed _after_ the needs_chown
check. (suggested by Filipe)
fs/btrfs/send.c | 67 +++++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 67 insertions(+)
diff --git a/fs/btrfs/send.c b/fs/btrfs/send.c
index 6b86841315be..58c777e3dc7a 100644
--- a/fs/btrfs/send.c
+++ b/fs/btrfs/send.c
@@ -23,6 +23,7 @@
#include "btrfs_inode.h"
#include "transaction.h"
#include "compression.h"
+#include "xattr.h"
/*
* Maximum number of references an extent can have in order for us to attempt to
@@ -4545,6 +4546,10 @@ static int __process_new_xattr(int num, struct btrfs_key *di_key,
struct fs_path *p;
struct posix_acl_xattr_header dummy_acl;
+ /* Capabilities are emitted by finish_inode_if_needed */
+ if (!strncmp(name, XATTR_NAME_CAPS, name_len))
+ return 0;
+
p = fs_path_alloc();
if (!p)
return -ENOMEM;
@@ -5107,6 +5112,64 @@ static int send_extent_data(struct send_ctx *sctx,
return 0;
}
+/*
+ * Search for a capability xattr related to sctx->cur_ino. If the capability if
+ * found, call send_set_xattr function to emit it.
+ *
+ * Return %0 if there isn't a capability, or when the capability was emitted
+ * successfully, or < %0 if an error occurred.
+ */
+static int send_capabilities(struct send_ctx *sctx)
+{
+ struct fs_path *fspath = NULL;
+ struct btrfs_path *path;
+ struct btrfs_dir_item *di;
+ struct extent_buffer *leaf;
+ unsigned long data_ptr;
+ char *buf = NULL;
+ int buf_len;
+ int ret = 0;
+
+ path = alloc_path_for_send();
+ if (!path)
+ return -ENOMEM;
+
+ di = btrfs_lookup_xattr(NULL, sctx->send_root, path, sctx->cur_ino,
+ XATTR_NAME_CAPS, strlen(XATTR_NAME_CAPS), 0);
+ if (!di) {
+ /* there is no xattr for this inode */
+ goto out;
+ } else if (IS_ERR(di)) {
+ ret = PTR_ERR(di);
+ goto out;
+ }
+
+ leaf = path->nodes[0];
+ buf_len = btrfs_dir_data_len(leaf, di);
+
+ fspath = fs_path_alloc();
+ buf = kmalloc(buf_len, GFP_KERNEL);
+ if (!fspath || !buf) {
+ ret = -ENOMEM;
+ goto out;
+ }
+
+ ret = get_cur_path(sctx, sctx->cur_ino, sctx->cur_inode_gen, fspath);
+ if (ret < 0)
+ goto out;
+
+ data_ptr = (unsigned long)(di + 1) + btrfs_dir_name_len(leaf, di);
+ read_extent_buffer(leaf, buf, data_ptr, buf_len);
+
+ ret = send_set_xattr(sctx, fspath, XATTR_NAME_CAPS,
+ strlen(XATTR_NAME_CAPS), buf, buf_len);
+out:
+ kfree(buf);
+ fs_path_free(fspath);
+ btrfs_free_path(path);
+ return ret;
+}
+
static int clone_range(struct send_ctx *sctx,
struct clone_root *clone_root,
const u64 disk_byte,
@@ -6010,6 +6073,10 @@ static int finish_inode_if_needed(struct send_ctx *sctx, int at_end)
goto out;
}
+ ret = send_capabilities(sctx);
+ if (ret < 0)
+ goto out;
+
/*
* If other directory inodes depended on our current directory
* inode's move/rename, now do their move/rename operations.
--
2.25.1
Thanks Li, cc'ing stable ML so they're aware.
On 5/12/20 6:24 AM, Li Wang wrote:
>
>
> On Tue, May 12, 2020 at 4:48 PM CKI Project <cki-project(a)redhat.com <mailto:cki-project@redhat.com>> wrote:
>
>
> ┌───────────────────────────────────────────────────────────────┐
> │ REVIEW REQUIRED FOR FAILED TEST │
> ├───────────────────────────────────────────────────────────────┤
> │ This failed kernel test has been held for review by kernel │
> │ test maintainers and the CKI team. Please investigate using │
> │ the pipeline link below this box. │
> │ │
> │ If the test failure is related to a non-kernel bug, no action │
> │ is needed. If a kernel bug is found, please reply all with │
> │ your assessment and we will release the report. │
> │ For more details: https://docs.engineering.redhat.com/x/eG5qB │
> └───────────────────────────────────────────────────────────────┘
>
> Pipeline: https://xci32.lab.eng.rdu2.redhat.com/cki-project/cki-pipeline/pipelines/56…
>
> Check out if the issue is autotriaged in the dashboard:
> https://datawarehouse-webservice-ark.cloud.paas.psi.redhat.com/pipeline/563…
>
> Hello,
>
> We ran automated tests on a recent commit from this kernel tree:
>
> Kernel repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
> Commit: c4bbda210077 - Linux 5.6.12
>
> The results of these automated tests are provided below.
>
> Overall result: FAILED (see details below)
> Merge: OK
> Compile: OK
> Tests: FAILED
>
> All kernel binaries, config files, and logs are available for download here:
>
> https://cki-artifacts.s3.us-east-2.amazonaws.com/index.html?prefix=dataware…
>
> One or more kernel tests failed:
>
> aarch64:
> ❌ LTP
>
>
> fanotify09Bug 1832099 - fanotify: fix merging marks masks with FAN_ONDIR
>
> fanotify15 failure is also a kernel bug in fedora.
> which has been fix in mainline: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?…
> $ git describe --contains f367a62a7cad
> v5.7-rc1~72^2~10
>
>
> --
> Regards,
> Li Wang
Here are some fixes that required backporting for 4.9. All of them
are already present in (or queued for) later stable branches.
Ben.
--
Ben Hutchings, Software Developer Codethink Ltd
https://www.codethink.co.uk/ Dale House, 35 Dale Street
Manchester, M1 2HF, United Kingdom
Hello stable-list,
I think this subjected patch [1] missed the below fixes tag.
I guess the subjected patch is only picked for 5.7. And
AFAIU, this patch will be needed for 5.6 as well.
Could you please do the needful.
Fixes: 244adf6426ee31a (ext4: make dioread_nolock the default)
[1]:
https://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4.git/commit/?h=de…
-ritesh
On 3/29/20 7:47 AM, Theodore Y. Ts'o wrote:
> On Sat, Mar 28, 2020 at 01:37:44AM +0530, Ritesh Harjani wrote:
>> Currently on calling echo 3 > drop_caches on host machine, we see
>> FS corruption in the guest. This happens on Power machine where
>> blocksize < pagesize.
>>
>> So as a temporary workaound don't enable dioread_nolock by default
>> for blocksize < pagesize until we identify the root cause.
>>
>> Also emit a warning msg in case if this mount option is manually
>> enabled for blocksize < pagesize.
>>
>> Reported-by: Aneesh Kumar K.V <aneesh.kumar(a)linux.ibm.com>
>> Signed-off-by: Ritesh Harjani <riteshh(a)linux.ibm.com>
>
> Thanks, applied.
>
> - Ted
>
From: Yasunori Goto <y-goto(a)jp.fujitsu.com>
commit a117699c6c4a4b1b4e90ed51e393590986567cb4 upstream
The root cause of panic is the num_pm of nfit_test1 is wrong.
Though 1 is specified for num_pm at nfit_test_init(), it must be 2,
because nfit_test1->spa_set[] array has 2 elements.
Since the array is smaller than expected, the driver breaks other area.
(it is often the link list of devres).
As a result, panic occurs like the following example.
CPU: 4 PID: 2233 Comm: lt-libndctl Tainted: G O 4.12.0-rc1+ #12
RIP: 0010:__list_del_entry_valid+0x6c/0xa0
Call Trace:
release_nodes+0x76/0x260
devres_release_all+0x3c/0x50
device_release_driver_internal+0x159/0x200
device_release_driver+0x12/0x20
bus_remove_device+0xfd/0x170
device_del+0x1e8/0x330
platform_device_del+0x28/0x90
platform_device_unregister+0x12/0x30
nfit_test_exit+0x2a/0x93b [nfit_test]
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Yasunori Goto <y-goto(a)jp.fujitsu.com>
Signed-off-by: Dan Williams <dan.j.williams(a)intel.com>
---
tools/testing/nvdimm/test/nfit.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/testing/nvdimm/test/nfit.c b/tools/testing/nvdimm/test/nfit.c
index 47ab1ab..ffdb7d0 100644
--- a/tools/testing/nvdimm/test/nfit.c
+++ b/tools/testing/nvdimm/test/nfit.c
@@ -2388,7 +2388,7 @@ static __init int nfit_test_init(void)
nfit_test->setup = nfit_test0_setup;
break;
case 1:
- nfit_test->num_pm = 1;
+ nfit_test->num_pm = 2;
nfit_test->dcr_idx = NUM_DCR;
nfit_test->num_dcr = 2;
nfit_test->alloc = nfit_test1_alloc;
--
1.8.3.1
The patch below does not apply to the 5.6-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable(a)vger.kernel.org>.
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
>From 6bd87eec23cbc9ed222bed0f5b5b02bf300e9a8d Mon Sep 17 00:00:00 2001
From: Christoph Hellwig <hch(a)lst.de>
Date: Mon, 4 May 2020 14:47:56 +0200
Subject: [PATCH] bdi: add a ->dev_name field to struct backing_dev_info
Cache a copy of the name for the life time of the backing_dev_info
structure so that we can reference it even after unregistering.
Fixes: 68f23b89067f ("memcg: fix a crash in wb_workfn when a device disappears")
Reported-by: Yufen Yu <yuyufen(a)huawei.com>
Signed-off-by: Christoph Hellwig <hch(a)lst.de>
Reviewed-by: Jan Kara <jack(a)suse.cz>
Reviewed-by: Bart Van Assche <bvanassche(a)acm.org>
Signed-off-by: Jens Axboe <axboe(a)kernel.dk>
diff --git a/include/linux/backing-dev-defs.h b/include/linux/backing-dev-defs.h
index ee577a83cfe6..7367150f962a 100644
--- a/include/linux/backing-dev-defs.h
+++ b/include/linux/backing-dev-defs.h
@@ -219,6 +219,7 @@ struct backing_dev_info {
wait_queue_head_t wb_waitq;
struct device *dev;
+ char dev_name[64];
struct device *owner;
struct timer_list laptop_mode_wb_timer;
diff --git a/mm/backing-dev.c b/mm/backing-dev.c
index c2c44c89ee5d..efc5b83acd2d 100644
--- a/mm/backing-dev.c
+++ b/mm/backing-dev.c
@@ -938,7 +938,8 @@ int bdi_register_va(struct backing_dev_info *bdi, const char *fmt, va_list args)
if (bdi->dev) /* The driver needs to use separate queues per device */
return 0;
- dev = device_create_vargs(bdi_class, NULL, MKDEV(0, 0), bdi, fmt, args);
+ vsnprintf(bdi->dev_name, sizeof(bdi->dev_name), fmt, args);
+ dev = device_create(bdi_class, NULL, MKDEV(0, 0), bdi, bdi->dev_name);
if (IS_ERR(dev))
return PTR_ERR(dev);
@@ -1047,7 +1048,7 @@ const char *bdi_dev_name(struct backing_dev_info *bdi)
{
if (!bdi || !bdi->dev)
return bdi_unknown_name;
- return dev_name(bdi->dev);
+ return bdi->dev_name;
}
EXPORT_SYMBOL_GPL(bdi_dev_name);
The patch below does not apply to the 4.4-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable(a)vger.kernel.org>.
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
>From 027d0c7101f50cf03aeea9eebf484afd4920c8d3 Mon Sep 17 00:00:00 2001
From: Mark Rutland <mark.rutland(a)arm.com>
Date: Tue, 5 May 2020 13:59:30 +0100
Subject: [PATCH] arm64: hugetlb: avoid potential NULL dereference
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
The static analyzer in GCC 10 spotted that in huge_pte_alloc() we may
pass a NULL pmdp into pte_alloc_map() when pmd_alloc() returns NULL:
| CC arch/arm64/mm/pageattr.o
| CC arch/arm64/mm/hugetlbpage.o
| from arch/arm64/mm/hugetlbpage.c:10:
| arch/arm64/mm/hugetlbpage.c: In function ‘huge_pte_alloc’:
| ./arch/arm64/include/asm/pgtable-types.h:28:24: warning: dereference of NULL ‘pmdp’ [CWE-690] [-Wanalyzer-null-dereference]
| ./arch/arm64/include/asm/pgtable.h:436:26: note: in expansion of macro ‘pmd_val’
| arch/arm64/mm/hugetlbpage.c:242:10: note: in expansion of macro ‘pte_alloc_map’
| |arch/arm64/mm/hugetlbpage.c:232:10:
| |./arch/arm64/include/asm/pgtable-types.h:28:24:
| ./arch/arm64/include/asm/pgtable.h:436:26: note: in expansion of macro ‘pmd_val’
| arch/arm64/mm/hugetlbpage.c:242:10: note: in expansion of macro ‘pte_alloc_map’
This can only occur when the kernel cannot allocate a page, and so is
unlikely to happen in practice before other systems start failing.
We can avoid this by bailing out if pmd_alloc() fails, as we do earlier
in the function if pud_alloc() fails.
Fixes: 66b3923a1a0f ("arm64: hugetlb: add support for PTE contiguous bit")
Signed-off-by: Mark Rutland <mark.rutland(a)arm.com>
Reported-by: Kyrill Tkachov <kyrylo.tkachov(a)arm.com>
Cc: <stable(a)vger.kernel.org> # 4.5.x-
Cc: Will Deacon <will(a)kernel.org>
Signed-off-by: Catalin Marinas <catalin.marinas(a)arm.com>
diff --git a/arch/arm64/mm/hugetlbpage.c b/arch/arm64/mm/hugetlbpage.c
index bbeb6a5a6ba6..0be3355e3499 100644
--- a/arch/arm64/mm/hugetlbpage.c
+++ b/arch/arm64/mm/hugetlbpage.c
@@ -230,6 +230,8 @@ pte_t *huge_pte_alloc(struct mm_struct *mm,
ptep = (pte_t *)pudp;
} else if (sz == (CONT_PTE_SIZE)) {
pmdp = pmd_alloc(mm, pudp, addr);
+ if (!pmdp)
+ return NULL;
WARN_ON(addr & (sz - 1));
/*
From: "Steven Rostedt (VMware)" <rostedt(a)goodmis.org>
A bug report was posted that running the preempt irq delay module on a slow
machine, and removing it quickly could lead to the thread created by the
modlue to execute after the module is removed, and this could cause the
kernel to crash. The fix for this was to call kthread_stop() after creating
the thread to make sure it finishes before allowing the module to be
removed.
Now this caused the opposite problem on fast machines. What now happens is
the kthread_stop() can cause the kthread never to execute and the test never
to run. To fix this, add a completion and wait for the kthread to execute,
then wait for it to end.
This issue caused the ftracetest selftests to fail on the preemptirq tests.
Link: https://lore.kernel.org/r/20200510114210.15d9e4af@oasis.local.home
Cc: stable(a)vger.kernel.org
Fixes: d16a8c31077e ("tracing: Wait for preempt irq delay thread to finish")
Reviewed-by: Joel Fernandes (Google) <joel(a)joelfernandes.org>
Signed-off-by: Steven Rostedt (VMware) <rostedt(a)goodmis.org>
---
kernel/trace/preemptirq_delay_test.c | 12 ++++++++++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/kernel/trace/preemptirq_delay_test.c b/kernel/trace/preemptirq_delay_test.c
index c4c86de63cf9..312d1a0ca3b6 100644
--- a/kernel/trace/preemptirq_delay_test.c
+++ b/kernel/trace/preemptirq_delay_test.c
@@ -16,6 +16,7 @@
#include <linux/printk.h>
#include <linux/string.h>
#include <linux/sysfs.h>
+#include <linux/completion.h>
static ulong delay = 100;
static char test_mode[12] = "irq";
@@ -28,6 +29,8 @@ MODULE_PARM_DESC(delay, "Period in microseconds (100 us default)");
MODULE_PARM_DESC(test_mode, "Mode of the test such as preempt, irq, or alternate (default irq)");
MODULE_PARM_DESC(burst_size, "The size of a burst (default 1)");
+static struct completion done;
+
#define MIN(x, y) ((x) < (y) ? (x) : (y))
static void busy_wait(ulong time)
@@ -114,6 +117,8 @@ static int preemptirq_delay_run(void *data)
for (i = 0; i < s; i++)
(testfuncs[i])(i);
+ complete(&done);
+
set_current_state(TASK_INTERRUPTIBLE);
while (!kthread_should_stop()) {
schedule();
@@ -128,15 +133,18 @@ static int preemptirq_delay_run(void *data)
static int preemptirq_run_test(void)
{
struct task_struct *task;
-
char task_name[50];
+ init_completion(&done);
+
snprintf(task_name, sizeof(task_name), "%s_test", test_mode);
task = kthread_run(preemptirq_delay_run, NULL, task_name);
if (IS_ERR(task))
return PTR_ERR(task);
- if (task)
+ if (task) {
+ wait_for_completion(&done);
kthread_stop(task);
+ }
return 0;
}
--
2.26.2
The patch below does not apply to the 4.19-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable(a)vger.kernel.org>.
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
>From 139f7425fdf54f054463e7524b9f54c41af8407f Mon Sep 17 00:00:00 2001
From: Paolo Bonzini <pbonzini(a)redhat.com>
Date: Tue, 5 May 2020 09:40:46 -0400
Subject: [PATCH] kvm: x86: Use KVM CPU capabilities to determine CR4 reserved
bits
Using CPUID data can be useful for the processor compatibility
check, but that's it. Using it to compute guest-reserved bits
can have both false positives (such as LA57 and UMIP which we
are already handling) and false negatives: in particular, with
this patch we don't allow anymore a KVM guest to set CR4.PKE
when CR4.PKE is clear on the host.
Fixes: b9dd21e104bc ("KVM: x86: simplify handling of PKRU")
Reported-by: Jim Mattson <jmattson(a)google.com>
Tested-by: Jim Mattson <jmattson(a)google.com>
Signed-off-by: Paolo Bonzini <pbonzini(a)redhat.com>
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index c5835f9cb9ad..8d296e3d0d56 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -926,19 +926,6 @@ EXPORT_SYMBOL_GPL(kvm_set_xcr);
__reserved_bits; \
})
-static u64 kvm_host_cr4_reserved_bits(struct cpuinfo_x86 *c)
-{
- u64 reserved_bits = __cr4_reserved_bits(cpu_has, c);
-
- if (kvm_cpu_cap_has(X86_FEATURE_LA57))
- reserved_bits &= ~X86_CR4_LA57;
-
- if (kvm_cpu_cap_has(X86_FEATURE_UMIP))
- reserved_bits &= ~X86_CR4_UMIP;
-
- return reserved_bits;
-}
-
static int kvm_valid_cr4(struct kvm_vcpu *vcpu, unsigned long cr4)
{
if (cr4 & cr4_reserved_bits)
@@ -9675,7 +9662,9 @@ int kvm_arch_hardware_setup(void *opaque)
if (!kvm_cpu_cap_has(X86_FEATURE_XSAVES))
supported_xss = 0;
- cr4_reserved_bits = kvm_host_cr4_reserved_bits(&boot_cpu_data);
+#define __kvm_cpu_cap_has(UNUSED_, f) kvm_cpu_cap_has(f)
+ cr4_reserved_bits = __cr4_reserved_bits(__kvm_cpu_cap_has, UNUSED_);
+#undef __kvm_cpu_cap_has
if (kvm_has_tsc_control) {
/*
@@ -9707,7 +9696,8 @@ int kvm_arch_check_processor_compat(void *opaque)
WARN_ON(!irqs_disabled());
- if (kvm_host_cr4_reserved_bits(c) != cr4_reserved_bits)
+ if (__cr4_reserved_bits(cpu_has, c) !=
+ __cr4_reserved_bits(cpu_has, &boot_cpu_data))
return -EIO;
return ops->check_processor_compatibility();
The patch below does not apply to the 4.14-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable(a)vger.kernel.org>.
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
>From 139f7425fdf54f054463e7524b9f54c41af8407f Mon Sep 17 00:00:00 2001
From: Paolo Bonzini <pbonzini(a)redhat.com>
Date: Tue, 5 May 2020 09:40:46 -0400
Subject: [PATCH] kvm: x86: Use KVM CPU capabilities to determine CR4 reserved
bits
Using CPUID data can be useful for the processor compatibility
check, but that's it. Using it to compute guest-reserved bits
can have both false positives (such as LA57 and UMIP which we
are already handling) and false negatives: in particular, with
this patch we don't allow anymore a KVM guest to set CR4.PKE
when CR4.PKE is clear on the host.
Fixes: b9dd21e104bc ("KVM: x86: simplify handling of PKRU")
Reported-by: Jim Mattson <jmattson(a)google.com>
Tested-by: Jim Mattson <jmattson(a)google.com>
Signed-off-by: Paolo Bonzini <pbonzini(a)redhat.com>
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index c5835f9cb9ad..8d296e3d0d56 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -926,19 +926,6 @@ EXPORT_SYMBOL_GPL(kvm_set_xcr);
__reserved_bits; \
})
-static u64 kvm_host_cr4_reserved_bits(struct cpuinfo_x86 *c)
-{
- u64 reserved_bits = __cr4_reserved_bits(cpu_has, c);
-
- if (kvm_cpu_cap_has(X86_FEATURE_LA57))
- reserved_bits &= ~X86_CR4_LA57;
-
- if (kvm_cpu_cap_has(X86_FEATURE_UMIP))
- reserved_bits &= ~X86_CR4_UMIP;
-
- return reserved_bits;
-}
-
static int kvm_valid_cr4(struct kvm_vcpu *vcpu, unsigned long cr4)
{
if (cr4 & cr4_reserved_bits)
@@ -9675,7 +9662,9 @@ int kvm_arch_hardware_setup(void *opaque)
if (!kvm_cpu_cap_has(X86_FEATURE_XSAVES))
supported_xss = 0;
- cr4_reserved_bits = kvm_host_cr4_reserved_bits(&boot_cpu_data);
+#define __kvm_cpu_cap_has(UNUSED_, f) kvm_cpu_cap_has(f)
+ cr4_reserved_bits = __cr4_reserved_bits(__kvm_cpu_cap_has, UNUSED_);
+#undef __kvm_cpu_cap_has
if (kvm_has_tsc_control) {
/*
@@ -9707,7 +9696,8 @@ int kvm_arch_check_processor_compat(void *opaque)
WARN_ON(!irqs_disabled());
- if (kvm_host_cr4_reserved_bits(c) != cr4_reserved_bits)
+ if (__cr4_reserved_bits(cpu_has, c) !=
+ __cr4_reserved_bits(cpu_has, &boot_cpu_data))
return -EIO;
return ops->check_processor_compatibility();
The patch below does not apply to the 5.6-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable(a)vger.kernel.org>.
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
>From 139f7425fdf54f054463e7524b9f54c41af8407f Mon Sep 17 00:00:00 2001
From: Paolo Bonzini <pbonzini(a)redhat.com>
Date: Tue, 5 May 2020 09:40:46 -0400
Subject: [PATCH] kvm: x86: Use KVM CPU capabilities to determine CR4 reserved
bits
Using CPUID data can be useful for the processor compatibility
check, but that's it. Using it to compute guest-reserved bits
can have both false positives (such as LA57 and UMIP which we
are already handling) and false negatives: in particular, with
this patch we don't allow anymore a KVM guest to set CR4.PKE
when CR4.PKE is clear on the host.
Fixes: b9dd21e104bc ("KVM: x86: simplify handling of PKRU")
Reported-by: Jim Mattson <jmattson(a)google.com>
Tested-by: Jim Mattson <jmattson(a)google.com>
Signed-off-by: Paolo Bonzini <pbonzini(a)redhat.com>
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index c5835f9cb9ad..8d296e3d0d56 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -926,19 +926,6 @@ EXPORT_SYMBOL_GPL(kvm_set_xcr);
__reserved_bits; \
})
-static u64 kvm_host_cr4_reserved_bits(struct cpuinfo_x86 *c)
-{
- u64 reserved_bits = __cr4_reserved_bits(cpu_has, c);
-
- if (kvm_cpu_cap_has(X86_FEATURE_LA57))
- reserved_bits &= ~X86_CR4_LA57;
-
- if (kvm_cpu_cap_has(X86_FEATURE_UMIP))
- reserved_bits &= ~X86_CR4_UMIP;
-
- return reserved_bits;
-}
-
static int kvm_valid_cr4(struct kvm_vcpu *vcpu, unsigned long cr4)
{
if (cr4 & cr4_reserved_bits)
@@ -9675,7 +9662,9 @@ int kvm_arch_hardware_setup(void *opaque)
if (!kvm_cpu_cap_has(X86_FEATURE_XSAVES))
supported_xss = 0;
- cr4_reserved_bits = kvm_host_cr4_reserved_bits(&boot_cpu_data);
+#define __kvm_cpu_cap_has(UNUSED_, f) kvm_cpu_cap_has(f)
+ cr4_reserved_bits = __cr4_reserved_bits(__kvm_cpu_cap_has, UNUSED_);
+#undef __kvm_cpu_cap_has
if (kvm_has_tsc_control) {
/*
@@ -9707,7 +9696,8 @@ int kvm_arch_check_processor_compat(void *opaque)
WARN_ON(!irqs_disabled());
- if (kvm_host_cr4_reserved_bits(c) != cr4_reserved_bits)
+ if (__cr4_reserved_bits(cpu_has, c) !=
+ __cr4_reserved_bits(cpu_has, &boot_cpu_data))
return -EIO;
return ops->check_processor_compatibility();
The patch below does not apply to the 5.4-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable(a)vger.kernel.org>.
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
>From 139f7425fdf54f054463e7524b9f54c41af8407f Mon Sep 17 00:00:00 2001
From: Paolo Bonzini <pbonzini(a)redhat.com>
Date: Tue, 5 May 2020 09:40:46 -0400
Subject: [PATCH] kvm: x86: Use KVM CPU capabilities to determine CR4 reserved
bits
Using CPUID data can be useful for the processor compatibility
check, but that's it. Using it to compute guest-reserved bits
can have both false positives (such as LA57 and UMIP which we
are already handling) and false negatives: in particular, with
this patch we don't allow anymore a KVM guest to set CR4.PKE
when CR4.PKE is clear on the host.
Fixes: b9dd21e104bc ("KVM: x86: simplify handling of PKRU")
Reported-by: Jim Mattson <jmattson(a)google.com>
Tested-by: Jim Mattson <jmattson(a)google.com>
Signed-off-by: Paolo Bonzini <pbonzini(a)redhat.com>
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index c5835f9cb9ad..8d296e3d0d56 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -926,19 +926,6 @@ EXPORT_SYMBOL_GPL(kvm_set_xcr);
__reserved_bits; \
})
-static u64 kvm_host_cr4_reserved_bits(struct cpuinfo_x86 *c)
-{
- u64 reserved_bits = __cr4_reserved_bits(cpu_has, c);
-
- if (kvm_cpu_cap_has(X86_FEATURE_LA57))
- reserved_bits &= ~X86_CR4_LA57;
-
- if (kvm_cpu_cap_has(X86_FEATURE_UMIP))
- reserved_bits &= ~X86_CR4_UMIP;
-
- return reserved_bits;
-}
-
static int kvm_valid_cr4(struct kvm_vcpu *vcpu, unsigned long cr4)
{
if (cr4 & cr4_reserved_bits)
@@ -9675,7 +9662,9 @@ int kvm_arch_hardware_setup(void *opaque)
if (!kvm_cpu_cap_has(X86_FEATURE_XSAVES))
supported_xss = 0;
- cr4_reserved_bits = kvm_host_cr4_reserved_bits(&boot_cpu_data);
+#define __kvm_cpu_cap_has(UNUSED_, f) kvm_cpu_cap_has(f)
+ cr4_reserved_bits = __cr4_reserved_bits(__kvm_cpu_cap_has, UNUSED_);
+#undef __kvm_cpu_cap_has
if (kvm_has_tsc_control) {
/*
@@ -9707,7 +9696,8 @@ int kvm_arch_check_processor_compat(void *opaque)
WARN_ON(!irqs_disabled());
- if (kvm_host_cr4_reserved_bits(c) != cr4_reserved_bits)
+ if (__cr4_reserved_bits(cpu_has, c) !=
+ __cr4_reserved_bits(cpu_has, &boot_cpu_data))
return -EIO;
return ops->check_processor_compatibility();
The patch below does not apply to the 5.4-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable(a)vger.kernel.org>.
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
>From 6bd87eec23cbc9ed222bed0f5b5b02bf300e9a8d Mon Sep 17 00:00:00 2001
From: Christoph Hellwig <hch(a)lst.de>
Date: Mon, 4 May 2020 14:47:56 +0200
Subject: [PATCH] bdi: add a ->dev_name field to struct backing_dev_info
Cache a copy of the name for the life time of the backing_dev_info
structure so that we can reference it even after unregistering.
Fixes: 68f23b89067f ("memcg: fix a crash in wb_workfn when a device disappears")
Reported-by: Yufen Yu <yuyufen(a)huawei.com>
Signed-off-by: Christoph Hellwig <hch(a)lst.de>
Reviewed-by: Jan Kara <jack(a)suse.cz>
Reviewed-by: Bart Van Assche <bvanassche(a)acm.org>
Signed-off-by: Jens Axboe <axboe(a)kernel.dk>
diff --git a/include/linux/backing-dev-defs.h b/include/linux/backing-dev-defs.h
index ee577a83cfe6..7367150f962a 100644
--- a/include/linux/backing-dev-defs.h
+++ b/include/linux/backing-dev-defs.h
@@ -219,6 +219,7 @@ struct backing_dev_info {
wait_queue_head_t wb_waitq;
struct device *dev;
+ char dev_name[64];
struct device *owner;
struct timer_list laptop_mode_wb_timer;
diff --git a/mm/backing-dev.c b/mm/backing-dev.c
index c2c44c89ee5d..efc5b83acd2d 100644
--- a/mm/backing-dev.c
+++ b/mm/backing-dev.c
@@ -938,7 +938,8 @@ int bdi_register_va(struct backing_dev_info *bdi, const char *fmt, va_list args)
if (bdi->dev) /* The driver needs to use separate queues per device */
return 0;
- dev = device_create_vargs(bdi_class, NULL, MKDEV(0, 0), bdi, fmt, args);
+ vsnprintf(bdi->dev_name, sizeof(bdi->dev_name), fmt, args);
+ dev = device_create(bdi_class, NULL, MKDEV(0, 0), bdi, bdi->dev_name);
if (IS_ERR(dev))
return PTR_ERR(dev);
@@ -1047,7 +1048,7 @@ const char *bdi_dev_name(struct backing_dev_info *bdi)
{
if (!bdi || !bdi->dev)
return bdi_unknown_name;
- return dev_name(bdi->dev);
+ return bdi->dev_name;
}
EXPORT_SYMBOL_GPL(bdi_dev_name);
A simple fix for a null pointer dereference in vmx_vcpu_run() with an
ugly-but-safe prereq patch.
The even uglier ASM_CALL_CONSTRAINT is gone in v2 as I finally figured
out why vmx_return was undefined: GCC dropped the entire asm blob because
all outputs were deemed unused.
v2:
- Document why there is no exact upstream commit for the fix, with
--verbose. [Greg]
- Tag the asm blob as volatile and drop the ASM_CALL_CONSTRAINT hack.
Sean Christopherson (2):
KVM: VMX: Explicitly reference RCX as the vmx_vcpu pointer in asm
blobs
KVM: VMX: Mark RCX, RDX and RSI as clobbered in vmx_vcpu_run()'s asm
blob
arch/x86/kvm/vmx.c | 91 +++++++++++++++++++++++++---------------------
1 file changed, 50 insertions(+), 41 deletions(-)
--
2.26.0
The patch below does not apply to the 5.6-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable(a)vger.kernel.org>.
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
>From 63ff822358b276137059520cf16e587e8073e80f Mon Sep 17 00:00:00 2001
From: Jens Axboe <axboe(a)kernel.dk>
Date: Thu, 7 May 2020 14:56:15 -0600
Subject: [PATCH] io_uring: don't use 'fd' for openat/openat2/statx
We currently make some guesses as when to open this fd, but in reality
we have no business (or need) to do so at all. In fact, it makes certain
things fail, like O_PATH.
Remove the fd lookup from these opcodes, we're just passing the 'fd' to
generic helpers anyway. With that, we can also remove the special casing
of fd values in io_req_needs_file(), and the 'fd_non_neg' check that
we have. And we can ensure that we only read sqe->fd once.
This fixes O_PATH usage with openat/openat2, and ditto statx path side
oddities.
Cc: stable(a)vger.kernel.org: # v5.6
Reported-by: Max Kellermann <mk(a)cm4all.com>
Signed-off-by: Jens Axboe <axboe(a)kernel.dk>
diff --git a/fs/io_uring.c b/fs/io_uring.c
index dd680eb153cb..979d9f977409 100644
--- a/fs/io_uring.c
+++ b/fs/io_uring.c
@@ -680,8 +680,6 @@ struct io_op_def {
unsigned needs_mm : 1;
/* needs req->file assigned */
unsigned needs_file : 1;
- /* needs req->file assigned IFF fd is >= 0 */
- unsigned fd_non_neg : 1;
/* hash wq insertion if file is a regular file */
unsigned hash_reg_file : 1;
/* unbound wq insertion if file is a non-regular file */
@@ -784,8 +782,6 @@ static const struct io_op_def io_op_defs[] = {
.needs_file = 1,
},
[IORING_OP_OPENAT] = {
- .needs_file = 1,
- .fd_non_neg = 1,
.file_table = 1,
.needs_fs = 1,
},
@@ -799,8 +795,6 @@ static const struct io_op_def io_op_defs[] = {
},
[IORING_OP_STATX] = {
.needs_mm = 1,
- .needs_file = 1,
- .fd_non_neg = 1,
.needs_fs = 1,
.file_table = 1,
},
@@ -837,8 +831,6 @@ static const struct io_op_def io_op_defs[] = {
.buffer_select = 1,
},
[IORING_OP_OPENAT2] = {
- .needs_file = 1,
- .fd_non_neg = 1,
.file_table = 1,
.needs_fs = 1,
},
@@ -5368,15 +5360,6 @@ static void io_wq_submit_work(struct io_wq_work **workptr)
io_steal_work(req, workptr);
}
-static int io_req_needs_file(struct io_kiocb *req, int fd)
-{
- if (!io_op_defs[req->opcode].needs_file)
- return 0;
- if ((fd == -1 || fd == AT_FDCWD) && io_op_defs[req->opcode].fd_non_neg)
- return 0;
- return 1;
-}
-
static inline struct file *io_file_from_index(struct io_ring_ctx *ctx,
int index)
{
@@ -5414,14 +5397,11 @@ static int io_file_get(struct io_submit_state *state, struct io_kiocb *req,
}
static int io_req_set_file(struct io_submit_state *state, struct io_kiocb *req,
- int fd, unsigned int flags)
+ int fd)
{
bool fixed;
- if (!io_req_needs_file(req, fd))
- return 0;
-
- fixed = (flags & IOSQE_FIXED_FILE);
+ fixed = (req->flags & REQ_F_FIXED_FILE) != 0;
if (unlikely(!fixed && req->needs_fixed_file))
return -EBADF;
@@ -5798,7 +5778,7 @@ static int io_init_req(struct io_ring_ctx *ctx, struct io_kiocb *req,
struct io_submit_state *state, bool async)
{
unsigned int sqe_flags;
- int id, fd;
+ int id;
/*
* All io need record the previous position, if LINK vs DARIN,
@@ -5850,8 +5830,10 @@ static int io_init_req(struct io_ring_ctx *ctx, struct io_kiocb *req,
IOSQE_ASYNC | IOSQE_FIXED_FILE |
IOSQE_BUFFER_SELECT | IOSQE_IO_LINK);
- fd = READ_ONCE(sqe->fd);
- return io_req_set_file(state, req, fd, sqe_flags);
+ if (!io_op_defs[req->opcode].needs_file)
+ return 0;
+
+ return io_req_set_file(state, req, READ_ONCE(sqe->fd));
}
static int io_submit_sqes(struct io_ring_ctx *ctx, unsigned int nr,
i915_gem_evict_something() is charged with finding a slot within the GTT
that we may reuse. Since our goal is not to stall, we first look for a
slot that only overlaps idle vma. To this end, on the first pass we move
any active vma to the end of the search list. However, we only stopped
moving active vma after we see the first active vma twice. If during the
search, that first active vma completed, we would not notice and keep on
extending the search list.
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/1746
Signed-off-by: Chris Wilson <chris(a)chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin(a)intel.com>
Cc: <stable(a)vger.kernel.org> # v5.5+
---
drivers/gpu/drm/i915/i915_gem_evict.c | 26 ++++++++++++--------------
1 file changed, 12 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_evict.c b/drivers/gpu/drm/i915/i915_gem_evict.c
index 0ba7b1e881c0..6501939929d5 100644
--- a/drivers/gpu/drm/i915/i915_gem_evict.c
+++ b/drivers/gpu/drm/i915/i915_gem_evict.c
@@ -128,6 +128,13 @@ i915_gem_evict_something(struct i915_address_space *vm,
active = NULL;
INIT_LIST_HEAD(&eviction_list);
list_for_each_entry_safe(vma, next, &vm->bound_list, vm_link) {
+ if (vma == active) { /* now seen this vma twice */
+ if (flags & PIN_NONBLOCK)
+ break;
+
+ active = ERR_PTR(-EAGAIN);
+ }
+
/*
* We keep this list in a rough least-recently scanned order
* of active elements (inactive elements are cheap to reap).
@@ -143,21 +150,12 @@ i915_gem_evict_something(struct i915_address_space *vm,
* To notice when we complete one full cycle, we record the
* first active element seen, before moving it to the tail.
*/
- if (i915_vma_is_active(vma)) {
- if (vma == active) {
- if (flags & PIN_NONBLOCK)
- break;
-
- active = ERR_PTR(-EAGAIN);
- }
-
- if (active != ERR_PTR(-EAGAIN)) {
- if (!active)
- active = vma;
+ if (active != ERR_PTR(-EAGAIN) && i915_vma_is_active(vma)) {
+ if (!active)
+ active = vma;
- list_move_tail(&vma->vm_link, &vm->bound_list);
- continue;
- }
+ list_move_tail(&vma->vm_link, &vm->bound_list);
+ continue;
}
if (mark_free(&scan, vma, flags, &eviction_list))
--
2.20.1
From: Xing Li <lixing(a)loongson.cn>
If a CPU support more than 32bit vmbits (which is true for 64bit CPUs),
VPN2_MASK set to fixed 0xffffe000 will lead to a wrong EntryHi in some
functions such as _kvm_mips_host_tlb_inv().
The cpu_vmbits definition of 32bit CPU in cpu-features.h is 31, so we
still use the old definition.
Cc: stable(a)vger.kernel.org
Reviewed-by: Aleksandar Markovic <aleksandar.qemu.devel(a)gmail.com>
Signed-off-by: Xing Li <lixing(a)loongson.cn>
[Huacai: Improve commit messages]
Signed-off-by: Huacai Chen <chenhc(a)lemote.com>
---
arch/mips/include/asm/kvm_host.h | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/mips/include/asm/kvm_host.h b/arch/mips/include/asm/kvm_host.h
index a01cee9..caa2b936 100644
--- a/arch/mips/include/asm/kvm_host.h
+++ b/arch/mips/include/asm/kvm_host.h
@@ -274,7 +274,11 @@ enum emulation_result {
#define MIPS3_PG_SHIFT 6
#define MIPS3_PG_FRAME 0x3fffffc0
+#if defined(CONFIG_64BIT)
+#define VPN2_MASK GENMASK(cpu_vmbits - 1, 13)
+#else
#define VPN2_MASK 0xffffe000
+#endif
#define KVM_ENTRYHI_ASID cpu_asid_mask(&boot_cpu_data)
#define TLB_IS_GLOBAL(x) ((x).tlb_lo[0] & (x).tlb_lo[1] & ENTRYLO_G)
#define TLB_VPN2(x) ((x).tlb_hi & VPN2_MASK)
--
2.7.0
Hi,
Please consider applying the following patches to the listed stable releases.
The following patches were found to be missing in stable releases by the
Chrome OS missing patch robot. The patches meet the following criteria.
- The patch includes a Fixes: tag
- The patch referenced in the Fixes: tag has been applied to the listed
stable release
- The patch has not been applied to that stable release
All patches have been applied to the listed stable releases and to at least one
Chrome OS branch. Resulting images have been build- and runtime-tested (where
applicable) on real hardware and with virtual hardware on kerneltests.org.
Thanks,
Guenter
---
Upstream commit fd25ea29093e ("Revert "ACPI / video: Add force_native quirk for HP Pavilion dv6"")
upstream: v4.10-rc6
Fixes: 6276e53fa8c0 ("ACPI / video: Add force_native quirk for HP Pavilion dv6")
in linux-4.4.y: 69e236e70ead
in linux-4.9.y: a04465251f94
upstream: v4.10-rc1
Affected branches:
linux-4.4.y
linux-4.9.y
Upstream commit 56f772279a76 ("enic: do not overwrite error code")
upstream: v4.18-rc2
Fixes: e8588e268509 ("enic: enable rq before updating rq descriptors")
in linux-4.4.y: 6af8cf3ca5cb
in linux-4.9.y: 92ff7ff0318f
in linux-4.14.y: 87337cb5663c
upstream: v4.17-rc1
Affected branches:
linux-4.4.y
linux-4.9.y (already applied)
linux-4.14.y (already applied)
Upstream commit afe49de44c27 ("ipv6: fix cleanup ordering for ip6_mr failure")
upstream: v4.19-rc3
Fixes: 15e668070a64 ("ipv6: reorder icmpv6_init() and ip6_mr_init()")
in linux-4.4.y: 7c5deeccc664
in linux-4.9.y: 05a59bc2f3c0
upstream: v4.11-rc3
Affected branches:
linux-4.4.y
linux-4.9.y (already applied)
linux-4.14.y
[commit 15e668070a64 is in v4.14 and thus in v4.14.y but its fix isn't]
Upstream commit bbdc6076d2e5 ("binfmt_elf: move brk out of mmap when doing direct loader exec")
upstream: v5.2-rc1
Fixes: eab09532d400 ("binfmt_elf: use ELF_ET_DYN_BASE only for PIE")
in linux-4.4.y: 7eb968cd04d4
in linux-4.9.y: 63c2f8f8c41b
upstream: v4.13-rc1
Affected branches:
linux-4.4.y
linux-4.9.y
linux-4.14.y (already applied)
linux-4.19.y (already applied)
Upstream commit 6f6060a5c9cc ("x86/apm: Don't access __preempt_count with zeroed fs")
upstream: v4.18-rc6
Fixes: dd84441a7971 ("x86/speculation: Use IBRS if available before calling into firmware")
in linux-4.4.y: 7ec391255421
in linux-4.9.y: a27ede1bedcb
in linux-4.14.y: c3ffdb5a2ed4
upstream: v4.16-rc4
Affected branches:
linux-4.4.y
linux-4.9.y (already applied)
linux-4.14.y (already applied)
Upstream commit 612601d0013f ("Revert "IB/ipoib: Update broadcast object if PKey value was changed in index 0"")
upstream: v4.14-rc3
Fixes: 9a9b8112699d ("IB/ipoib: Update broadcast object if PKey value was changed in index 0")
in linux-4.4.y: 8716c87ec253
in linux-4.9.y: 089f13786bdc
upstream: v4.12-rc1
Affected branches:
linux-4.4.y
linux-4.9.y (already applied)
Upstream commit 778fbf417999 ("HID: wacom: Read HID_DG_CONTACTMAX directly for non-generic devices")
upstream: v5.7-rc5
Fixes: 184eccd40389 ("HID: wacom: generic: read HID_DG_CONTACTMAX from any feature report")
in linux-4.14.y: 4e268e9c404a
in linux-4.19.y: 8993c673d6c4
upstream: v5.3-rc1
Affected branches:
linux-4.14.y
linux-4.19.y
linux-5.4.y
linux-5.6.y
Upstream commit f9094b7603c0 ("geneve: only configure or fill UDP_ZERO_CSUM6_RX/TX info when CONFIG_IPV6")
upstream: v4.15-rc1
Fixes: fd7eafd02121 ("geneve: fix fill_info when link down")
in linux-4.14.y: 81a1c2d3f9eb
upstream: v4.15-rc1
Affected branches:
linux-4.14.y
Upstream commit 57d38f26d81e ("vt: fix unicode console freeing with a common interface")
upstream: v5.7-rc5
Fixes: 9a98e7a80f95 ("vt: don't use kmalloc() for the unicode screen buffer")
in linux-4.19.y: b91c4171c74e
in linux-5.4.y: 64882aa0c531
in linux-5.6.y: ec6e885a4cb0
upstream: v5.7-rc3
Affected branches:
linux-4.19.y
linux-5.4.y
linux-5.6.y
Upstream commit 145cb2f7177d ("sctp: Fix bundling of SHUTDOWN with COOKIE-ACK")
upstream: v5.7-rc3
Fixes: 4ff40b86262b ("sctp: set chunk transport correctly when it's a new asoc")
in linux-4.19.y: cbf23d40cece
upstream: v5.0-rc4
Affected branches:
linux-4.19.y
linux-5.4.y
linux-5.6.y
Upstream commit 2ae11c46d5fd ("tty: xilinx_uartps: Fix missing id assignment to the console")
upstream: v5.7-rc5
Fixes: 18cc7ac8a28e ("Revert "serial: uartps: Register own uart console and driver structures"")
in linux-5.4.y: c4606876164c
in linux-5.6.y: 29772eb399a3
upstream: v5.7-rc3
Affected branches:
linux-5.4.y
linux-5.6.y
A 5-level paging capable machine can have memory above 46-bit in the
physical address space. This memory is only addressable in the 5-level
paging mode: we don't have enough virtual address space to create direct
mapping for such memory in the 4-level paging mode.
Currently, we fail boot completely: NULL pointer dereference in
subsection_map_init().
Skip creating a memblock for such memory instead and notify user that
some memory is not addressable.
Signed-off-by: Kirill A. Shutemov <kirill.shutemov(a)linux.intel.com>
Cc: stable(a)vger.kernel.org # v4.14
---
Tested with a hacked QEMU: https://gist.github.com/kiryl/d45eb54110944ff95e544972d8bdac1d
---
arch/x86/kernel/e820.c | 9 ++++++++-
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/arch/x86/kernel/e820.c b/arch/x86/kernel/e820.c
index c5399e80c59c..022fe1de8940 100644
--- a/arch/x86/kernel/e820.c
+++ b/arch/x86/kernel/e820.c
@@ -1307,7 +1307,14 @@ void __init e820__memblock_setup(void)
if (entry->type != E820_TYPE_RAM && entry->type != E820_TYPE_RESERVED_KERN)
continue;
- memblock_add(entry->addr, entry->size);
+ if (entry->addr >= MAXMEM || end >= MAXMEM)
+ pr_err_once("Some physical memory is not addressable in the paging mode.\n");
+
+ if (entry->addr >= MAXMEM)
+ continue;
+
+ end = min_t(u64, end, MAXMEM - 1);
+ memblock_add(entry->addr, end - entry->addr);
}
/* Throw away partial pages: */
--
2.26.2
GCC 10 appears to have changed -O2 in order to make compilation time
faster when using -flto, seemingly at the expense of performance, in
particular with regards to how the inliner works. Since -O3 these days
shouldn't have the same set of bugs as 10 years ago, this commit
defaults new kernel compiles to -O3 when using gcc >= 10.
Cc: linux-kbuild(a)vger.kernel.org
Cc: x86(a)kernel.org
Cc: stable(a)vger.kernel.org
Cc: hjl.tools(a)gmail.com
Cc: Peter Zijlstra <peterz(a)infradead.org>
Cc: Jakub Jelinek <jakub(a)redhat.com>
Cc: Oleksandr Natalenko <oleksandr(a)redhat.com>
Cc: Arnd Bergmann <arnd(a)arndb.de>
Cc: Andrew Morton <akpm(a)linux-foundation.org>
Cc: David Laight <David.Laight(a)aculab.com>
Cc: Linus Torvalds <torvalds(a)linux-foundation.org>
Cc: Masahiro Yamada <yamada.masahiro(a)socionext.com>
Signed-off-by: Jason A. Donenfeld <Jason(a)zx2c4.com>
---
Changes v1->v2:
- [Oleksandr] Remove O3 dependency on ARC.
init/Kconfig | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/init/Kconfig b/init/Kconfig
index 9e22ee8fbd75..f76ec3ccc883 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -1245,7 +1245,8 @@ config BOOT_CONFIG
choice
prompt "Compiler optimization level"
- default CC_OPTIMIZE_FOR_PERFORMANCE
+ default CC_OPTIMIZE_FOR_PERFORMANCE_O3 if GCC_VERSION >= 100000
+ default CC_OPTIMIZE_FOR_PERFORMANCE if (GCC_VERSION < 100000 || CC_IS_CLANG)
config CC_OPTIMIZE_FOR_PERFORMANCE
bool "Optimize for performance (-O2)"
@@ -1256,7 +1257,6 @@ config CC_OPTIMIZE_FOR_PERFORMANCE
config CC_OPTIMIZE_FOR_PERFORMANCE_O3
bool "Optimize more for performance (-O3)"
- depends on ARC
imply CC_DISABLE_WARN_MAYBE_UNINITIALIZED # avoid false positives
help
Choosing this option will pass "-O3" to your compiler to optimize
--
2.26.2