This is a note to let you know that I've just added the patch titled
lockd: double unregister of inetaddr notifiers
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
lockd-double-unregister-of-inetaddr-notifiers.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From dc3033e16c59a2c4e62b31341258a5786cbcee56 Mon Sep 17 00:00:00 2001
From: Vasily Averin <vvs(a)virtuozzo.com>
Date: Fri, 20 Oct 2017 17:33:18 +0300
Subject: lockd: double unregister of inetaddr notifiers
From: Vasily Averin <vvs(a)virtuozzo.com>
commit dc3033e16c59a2c4e62b31341258a5786cbcee56 upstream.
lockd_up() can call lockd_unregister_notifiers twice:
inside lockd_start_svc() when it calls lockd_svc_exit_thread()
and then in error path of lockd_up()
Patch forces lockd_start_svc() to unregister notifiers in all error cases
and removes extra unregister in error path of lockd_up().
Fixes: cb7d224f82e4 "lockd: unregister notifier blocks if the service ..."
Signed-off-by: Vasily Averin <vvs(a)virtuozzo.com>
Reviewed-by: Jeff Layton <jlayton(a)kernel.org>
Signed-off-by: J. Bruce Fields <bfields(a)redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
fs/lockd/svc.c | 20 +++++++++-----------
1 file changed, 9 insertions(+), 11 deletions(-)
--- a/fs/lockd/svc.c
+++ b/fs/lockd/svc.c
@@ -365,6 +365,7 @@ static int lockd_start_svc(struct svc_se
printk(KERN_WARNING
"lockd_up: svc_rqst allocation failed, error=%d\n",
error);
+ lockd_unregister_notifiers();
goto out_rqst;
}
@@ -455,13 +456,16 @@ int lockd_up(struct net *net)
}
error = lockd_up_net(serv, net);
- if (error < 0)
- goto err_net;
+ if (error < 0) {
+ lockd_unregister_notifiers();
+ goto err_put;
+ }
error = lockd_start_svc(serv);
- if (error < 0)
- goto err_start;
-
+ if (error < 0) {
+ lockd_down_net(serv, net);
+ goto err_put;
+ }
nlmsvc_users++;
/*
* Note: svc_serv structures have an initial use count of 1,
@@ -472,12 +476,6 @@ err_put:
err_create:
mutex_unlock(&nlmsvc_mutex);
return error;
-
-err_start:
- lockd_down_net(serv, net);
-err_net:
- lockd_unregister_notifiers();
- goto err_put;
}
EXPORT_SYMBOL_GPL(lockd_up);
Patches currently in stable-queue which might be from vvs(a)virtuozzo.com are
queue-4.9/lockd-double-unregister-of-inetaddr-notifiers.patch
This is a note to let you know that I've just added the patch titled
iscsi-target: Fix non-immediate TMR reference leak
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
iscsi-target-fix-non-immediate-tmr-reference-leak.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 3fc9fb13a4b2576aeab86c62fd64eb29ab68659c Mon Sep 17 00:00:00 2001
From: Nicholas Bellinger <nab(a)linux-iscsi.org>
Date: Fri, 27 Oct 2017 20:52:56 -0700
Subject: iscsi-target: Fix non-immediate TMR reference leak
From: Nicholas Bellinger <nab(a)linux-iscsi.org>
commit 3fc9fb13a4b2576aeab86c62fd64eb29ab68659c upstream.
This patch fixes a se_cmd->cmd_kref reference leak that can
occur when a non immediate TMR is proceeded our of command
sequence number order, and CMDSN_LOWER_THAN_EXP is returned
by iscsit_sequence_cmd().
To address this bug, call target_put_sess_cmd() during this
special case following what iscsit_process_scsi_cmd() does
upon CMDSN_LOWER_THAN_EXP.
Cc: Mike Christie <mchristi(a)redhat.com>
Cc: Hannes Reinecke <hare(a)suse.com>
Signed-off-by: Nicholas Bellinger <nab(a)linux-iscsi.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/target/iscsi/iscsi_target.c | 8 +++++---
1 file changed, 5 insertions(+), 3 deletions(-)
--- a/drivers/target/iscsi/iscsi_target.c
+++ b/drivers/target/iscsi/iscsi_target.c
@@ -2104,12 +2104,14 @@ attach:
if (!(hdr->opcode & ISCSI_OP_IMMEDIATE)) {
int cmdsn_ret = iscsit_sequence_cmd(conn, cmd, buf, hdr->cmdsn);
- if (cmdsn_ret == CMDSN_HIGHER_THAN_EXP)
+ if (cmdsn_ret == CMDSN_HIGHER_THAN_EXP) {
out_of_order_cmdsn = 1;
- else if (cmdsn_ret == CMDSN_LOWER_THAN_EXP)
+ } else if (cmdsn_ret == CMDSN_LOWER_THAN_EXP) {
+ target_put_sess_cmd(&cmd->se_cmd);
return 0;
- else if (cmdsn_ret == CMDSN_ERROR_CANNOT_RECOVER)
+ } else if (cmdsn_ret == CMDSN_ERROR_CANNOT_RECOVER) {
return -1;
+ }
}
iscsit_ack_from_expstatsn(conn, be32_to_cpu(hdr->exp_statsn));
Patches currently in stable-queue which might be from nab(a)linux-iscsi.org are
queue-4.9/target-fix-queue_full-scsi-task-attribute-handling.patch
queue-4.9/iscsi-target-fix-non-immediate-tmr-reference-leak.patch
This is a note to let you know that I've just added the patch titled
isofs: fix timestamps beyond 2027
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
isofs-fix-timestamps-beyond-2027.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 34be4dbf87fc3e474a842305394534216d428f5d Mon Sep 17 00:00:00 2001
From: Arnd Bergmann <arnd(a)arndb.de>
Date: Thu, 19 Oct 2017 16:47:48 +0200
Subject: isofs: fix timestamps beyond 2027
From: Arnd Bergmann <arnd(a)arndb.de>
commit 34be4dbf87fc3e474a842305394534216d428f5d upstream.
isofs uses a 'char' variable to load the number of years since
1900 for an inode timestamp. On architectures that use a signed
char type by default, this results in an invalid date for
anything beyond 2027.
This changes the function argument to a 'u8' array, which
is defined the same way on all architectures, and unambiguously
lets us use years until 2155.
This should be backported to all kernels that might still be
in use by that date.
Signed-off-by: Arnd Bergmann <arnd(a)arndb.de>
Signed-off-by: Jan Kara <jack(a)suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
fs/isofs/isofs.h | 2 +-
fs/isofs/rock.h | 2 +-
fs/isofs/util.c | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
--- a/fs/isofs/isofs.h
+++ b/fs/isofs/isofs.h
@@ -103,7 +103,7 @@ static inline unsigned int isonum_733(ch
/* Ignore bigendian datum due to broken mastering programs */
return get_unaligned_le32(p);
}
-extern int iso_date(char *, int);
+extern int iso_date(u8 *, int);
struct inode; /* To make gcc happy */
--- a/fs/isofs/rock.h
+++ b/fs/isofs/rock.h
@@ -65,7 +65,7 @@ struct RR_PL_s {
};
struct stamp {
- char time[7];
+ __u8 time[7]; /* actually 6 unsigned, 1 signed */
} __attribute__ ((packed));
struct RR_TF_s {
--- a/fs/isofs/util.c
+++ b/fs/isofs/util.c
@@ -15,7 +15,7 @@
* to GMT. Thus we should always be correct.
*/
-int iso_date(char * p, int flag)
+int iso_date(u8 *p, int flag)
{
int year, month, day, hour, minute, second, tz;
int crtime;
Patches currently in stable-queue which might be from arnd(a)arndb.de are
queue-4.9/rtlwifi-fix-uninitialized-rtlhal-last_suspend_sec-time.patch
queue-4.9/isofs-fix-timestamps-beyond-2027.patch
This is a note to let you know that I've just added the patch titled
irqchip/gic-v3: Fix ppi-partitions lookup
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
irqchip-gic-v3-fix-ppi-partitions-lookup.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 00ee9a1ca5080202bc37b44e998c3b2c74d45817 Mon Sep 17 00:00:00 2001
From: Johan Hovold <johan(a)kernel.org>
Date: Sat, 11 Nov 2017 17:51:25 +0100
Subject: irqchip/gic-v3: Fix ppi-partitions lookup
From: Johan Hovold <johan(a)kernel.org>
commit 00ee9a1ca5080202bc37b44e998c3b2c74d45817 upstream.
Fix child-node lookup during initialisation, which ended up searching
the whole device tree depth-first starting at the parent rather than
just matching on its children.
To make things worse, the parent gic node was prematurely freed, while
the ppi-partitions node was leaked.
Fixes: e3825ba1af3a ("irqchip/gic-v3: Add support for partitioned PPIs")
Signed-off-by: Johan Hovold <johan(a)kernel.org>
Signed-off-by: Marc Zyngier <marc.zyngier(a)arm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/irqchip/irq-gic-v3.c | 9 ++++++---
1 file changed, 6 insertions(+), 3 deletions(-)
--- a/drivers/irqchip/irq-gic-v3.c
+++ b/drivers/irqchip/irq-gic-v3.c
@@ -1022,18 +1022,18 @@ static void __init gic_populate_ppi_part
int nr_parts;
struct partition_affinity *parts;
- parts_node = of_find_node_by_name(gic_node, "ppi-partitions");
+ parts_node = of_get_child_by_name(gic_node, "ppi-partitions");
if (!parts_node)
return;
nr_parts = of_get_child_count(parts_node);
if (!nr_parts)
- return;
+ goto out_put_node;
parts = kzalloc(sizeof(*parts) * nr_parts, GFP_KERNEL);
if (WARN_ON(!parts))
- return;
+ goto out_put_node;
for_each_child_of_node(parts_node, child_part) {
struct partition_affinity *part;
@@ -1100,6 +1100,9 @@ static void __init gic_populate_ppi_part
gic_data.ppi_descs[i] = desc;
}
+
+out_put_node:
+ of_node_put(parts_node);
}
static void __init gic_of_setup_kvm_info(struct device_node *node)
Patches currently in stable-queue which might be from johan(a)kernel.org are
queue-4.9/irqchip-gic-v3-fix-ppi-partitions-lookup.patch
This is a note to let you know that I've just added the patch titled
fs/9p: Compare qid.path in v9fs_test_inode
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
fs-9p-compare-qid.path-in-v9fs_test_inode.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 8ee031631546cf2f7859cc69593bd60bbdd70b46 Mon Sep 17 00:00:00 2001
From: Tuomas Tynkkynen <tuomas(a)tuxera.com>
Date: Wed, 6 Sep 2017 17:59:07 +0300
Subject: fs/9p: Compare qid.path in v9fs_test_inode
From: Tuomas Tynkkynen <tuomas(a)tuxera.com>
commit 8ee031631546cf2f7859cc69593bd60bbdd70b46 upstream.
Commit fd2421f54423 ("fs/9p: When doing inode lookup compare qid details
and inode mode bits.") transformed v9fs_qid_iget() to use iget5_locked()
instead of iget_locked(). However, the test() callback is not checking
fid.path at all, which means that a lookup in the inode cache can now
accidentally locate a completely wrong inode from the same inode hash
bucket if the other fields (qid.type and qid.version) match.
Fixes: fd2421f54423 ("fs/9p: When doing inode lookup compare qid details and inode mode bits.")
Reviewed-by: Latchesar Ionkov <lucho(a)ionkov.net>
Signed-off-by: Tuomas Tynkkynen <tuomas(a)tuxera.com>
Signed-off-by: Al Viro <viro(a)zeniv.linux.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
fs/9p/vfs_inode.c | 3 +++
fs/9p/vfs_inode_dotl.c | 3 +++
2 files changed, 6 insertions(+)
--- a/fs/9p/vfs_inode.c
+++ b/fs/9p/vfs_inode.c
@@ -483,6 +483,9 @@ static int v9fs_test_inode(struct inode
if (v9inode->qid.type != st->qid.type)
return 0;
+
+ if (v9inode->qid.path != st->qid.path)
+ return 0;
return 1;
}
--- a/fs/9p/vfs_inode_dotl.c
+++ b/fs/9p/vfs_inode_dotl.c
@@ -87,6 +87,9 @@ static int v9fs_test_inode_dotl(struct i
if (v9inode->qid.type != st->qid.type)
return 0;
+
+ if (v9inode->qid.path != st->qid.path)
+ return 0;
return 1;
}
Patches currently in stable-queue which might be from tuomas(a)tuxera.com are
queue-4.9/fs-9p-compare-qid.path-in-v9fs_test_inode.patch
This is a note to let you know that I've just added the patch titled
ext4: fix interaction between i_size, fallocate, and delalloc after a crash
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
ext4-fix-interaction-between-i_size-fallocate-and-delalloc-after-a-crash.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 51e3ae81ec58e95f10a98ef3dd6d7bce5d8e35a2 Mon Sep 17 00:00:00 2001
From: Theodore Ts'o <tytso(a)mit.edu>
Date: Fri, 6 Oct 2017 23:09:55 -0400
Subject: ext4: fix interaction between i_size, fallocate, and delalloc after a crash
From: Theodore Ts'o <tytso(a)mit.edu>
commit 51e3ae81ec58e95f10a98ef3dd6d7bce5d8e35a2 upstream.
If there are pending writes subject to delayed allocation, then i_size
will show size after the writes have completed, while i_disksize
contains the value of i_size on the disk (since the writes have not
been persisted to disk).
If fallocate(2) is called with the FALLOC_FL_KEEP_SIZE flag, either
with or without the FALLOC_FL_ZERO_RANGE flag set, and the new size
after the fallocate(2) is between i_size and i_disksize, then after a
crash, if a journal commit has resulted in the changes made by the
fallocate() call to be persisted after a crash, but the delayed
allocation write has not resolved itself, i_size would not be updated,
and this would cause the following e2fsck complaint:
Inode 12, end of extent exceeds allowed value
(logical block 33, physical block 33441, len 7)
This can only take place on a sparse file, where the fallocate(2) call
is allocating blocks in a range which is before a pending delayed
allocation write which is extending i_size. Since this situation is
quite rare, and the window in which the crash must take place is
typically < 30 seconds, in practice this condition will rarely happen.
Nevertheless, it can be triggered in testing, and in particular by
xfstests generic/456.
Signed-off-by: Theodore Ts'o <tytso(a)mit.edu>
Reported-by: Amir Goldstein <amir73il(a)gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
fs/ext4/extents.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
--- a/fs/ext4/extents.c
+++ b/fs/ext4/extents.c
@@ -4803,7 +4803,8 @@ static long ext4_zero_range(struct file
}
if (!(mode & FALLOC_FL_KEEP_SIZE) &&
- offset + len > i_size_read(inode)) {
+ (offset + len > i_size_read(inode) ||
+ offset + len > EXT4_I(inode)->i_disksize)) {
new_size = offset + len;
ret = inode_newsize_ok(inode, new_size);
if (ret)
@@ -4974,7 +4975,8 @@ long ext4_fallocate(struct file *file, i
}
if (!(mode & FALLOC_FL_KEEP_SIZE) &&
- offset + len > i_size_read(inode)) {
+ (offset + len > i_size_read(inode) ||
+ offset + len > EXT4_I(inode)->i_disksize)) {
new_size = offset + len;
ret = inode_newsize_ok(inode, new_size);
if (ret)
Patches currently in stable-queue which might be from tytso(a)mit.edu are
queue-4.9/ext4-fix-interaction-between-i_size-fallocate-and-delalloc-after-a-crash.patch
This is a note to let you know that I've just added the patch titled
fix a page leak in vhost_scsi_iov_to_sgl() error recovery
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
fix-a-page-leak-in-vhost_scsi_iov_to_sgl-error-recovery.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 11d49e9d089ccec81be87c2386dfdd010d7f7f6e Mon Sep 17 00:00:00 2001
From: Al Viro <viro(a)zeniv.linux.org.uk>
Date: Sun, 24 Sep 2017 18:36:44 -0400
Subject: fix a page leak in vhost_scsi_iov_to_sgl() error recovery
From: Al Viro <viro(a)zeniv.linux.org.uk>
commit 11d49e9d089ccec81be87c2386dfdd010d7f7f6e upstream.
we are advancing sg as we go, so the pages we need to drop in
case of error are *before* the current sg.
Signed-off-by: Al Viro <viro(a)zeniv.linux.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/vhost/scsi.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
--- a/drivers/vhost/scsi.c
+++ b/drivers/vhost/scsi.c
@@ -693,6 +693,7 @@ vhost_scsi_iov_to_sgl(struct vhost_scsi_
struct scatterlist *sg, int sg_count)
{
size_t off = iter->iov_offset;
+ struct scatterlist *p = sg;
int i, ret;
for (i = 0; i < iter->nr_segs; i++) {
@@ -701,8 +702,8 @@ vhost_scsi_iov_to_sgl(struct vhost_scsi_
ret = vhost_scsi_map_to_sgl(cmd, base, len, sg, write);
if (ret < 0) {
- for (i = 0; i < sg_count; i++) {
- struct page *page = sg_page(&sg[i]);
+ while (p < sg) {
+ struct page *page = sg_page(p++);
if (page)
put_page(page);
}
Patches currently in stable-queue which might be from viro(a)zeniv.linux.org.uk are
queue-4.9/fs-9p-compare-qid.path-in-v9fs_test_inode.patch
queue-4.9/fix-a-page-leak-in-vhost_scsi_iov_to_sgl-error-recovery.patch
queue-4.9/arm64-implement-arch-specific-pte_access_permitted.patch
This is a note to let you know that I've just added the patch titled
dm: fix race between dm_get_from_kobject() and __dm_destroy()
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
dm-fix-race-between-dm_get_from_kobject-and-__dm_destroy.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From b9a41d21dceadf8104812626ef85dc56ee8a60ed Mon Sep 17 00:00:00 2001
From: Hou Tao <houtao1(a)huawei.com>
Date: Wed, 1 Nov 2017 15:42:36 +0800
Subject: dm: fix race between dm_get_from_kobject() and __dm_destroy()
From: Hou Tao <houtao1(a)huawei.com>
commit b9a41d21dceadf8104812626ef85dc56ee8a60ed upstream.
The following BUG_ON was hit when testing repeat creation and removal of
DM devices:
kernel BUG at drivers/md/dm.c:2919!
CPU: 7 PID: 750 Comm: systemd-udevd Not tainted 4.1.44
Call Trace:
[<ffffffff81649e8b>] dm_get_from_kobject+0x34/0x3a
[<ffffffff81650ef1>] dm_attr_show+0x2b/0x5e
[<ffffffff817b46d1>] ? mutex_lock+0x26/0x44
[<ffffffff811df7f5>] sysfs_kf_seq_show+0x83/0xcf
[<ffffffff811de257>] kernfs_seq_show+0x23/0x25
[<ffffffff81199118>] seq_read+0x16f/0x325
[<ffffffff811de994>] kernfs_fop_read+0x3a/0x13f
[<ffffffff8117b625>] __vfs_read+0x26/0x9d
[<ffffffff8130eb59>] ? security_file_permission+0x3c/0x44
[<ffffffff8117bdb8>] ? rw_verify_area+0x83/0xd9
[<ffffffff8117be9d>] vfs_read+0x8f/0xcf
[<ffffffff81193e34>] ? __fdget_pos+0x12/0x41
[<ffffffff8117c686>] SyS_read+0x4b/0x76
[<ffffffff817b606e>] system_call_fastpath+0x12/0x71
The bug can be easily triggered, if an extra delay (e.g. 10ms) is added
between the test of DMF_FREEING & DMF_DELETING and dm_get() in
dm_get_from_kobject().
To fix it, we need to ensure the test of DMF_FREEING & DMF_DELETING and
dm_get() are done in an atomic way, so _minor_lock is used.
The other callers of dm_get() have also been checked to be OK: some
callers invoke dm_get() under _minor_lock, some callers invoke it under
_hash_lock, and dm_start_request() invoke it after increasing
md->open_count.
Signed-off-by: Hou Tao <houtao1(a)huawei.com>
Signed-off-by: Mike Snitzer <snitzer(a)redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/md/dm.c | 12 ++++++++----
1 file changed, 8 insertions(+), 4 deletions(-)
--- a/drivers/md/dm.c
+++ b/drivers/md/dm.c
@@ -2515,11 +2515,15 @@ struct mapped_device *dm_get_from_kobjec
md = container_of(kobj, struct mapped_device, kobj_holder.kobj);
- if (test_bit(DMF_FREEING, &md->flags) ||
- dm_deleting_md(md))
- return NULL;
-
+ spin_lock(&_minor_lock);
+ if (test_bit(DMF_FREEING, &md->flags) || dm_deleting_md(md)) {
+ md = NULL;
+ goto out;
+ }
dm_get(md);
+out:
+ spin_unlock(&_minor_lock);
+
return md;
}
Patches currently in stable-queue which might be from houtao1(a)huawei.com are
queue-4.9/dm-fix-race-between-dm_get_from_kobject-and-__dm_destroy.patch
This is a note to let you know that I've just added the patch titled
eCryptfs: use after free in ecryptfs_release_messaging()
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
ecryptfs-use-after-free-in-ecryptfs_release_messaging.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From db86be3a12d0b6e5c5b51c2ab2a48f06329cb590 Mon Sep 17 00:00:00 2001
From: Dan Carpenter <dan.carpenter(a)oracle.com>
Date: Tue, 22 Aug 2017 23:41:28 +0300
Subject: eCryptfs: use after free in ecryptfs_release_messaging()
From: Dan Carpenter <dan.carpenter(a)oracle.com>
commit db86be3a12d0b6e5c5b51c2ab2a48f06329cb590 upstream.
We're freeing the list iterator so we should be using the _safe()
version of hlist_for_each_entry().
Fixes: 88b4a07e6610 ("[PATCH] eCryptfs: Public key transport mechanism")
Signed-off-by: Dan Carpenter <dan.carpenter(a)oracle.com>
Signed-off-by: Tyler Hicks <tyhicks(a)canonical.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
fs/ecryptfs/messaging.c | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
--- a/fs/ecryptfs/messaging.c
+++ b/fs/ecryptfs/messaging.c
@@ -442,15 +442,16 @@ void ecryptfs_release_messaging(void)
}
if (ecryptfs_daemon_hash) {
struct ecryptfs_daemon *daemon;
+ struct hlist_node *n;
int i;
mutex_lock(&ecryptfs_daemon_hash_mux);
for (i = 0; i < (1 << ecryptfs_hash_bits); i++) {
int rc;
- hlist_for_each_entry(daemon,
- &ecryptfs_daemon_hash[i],
- euid_chain) {
+ hlist_for_each_entry_safe(daemon, n,
+ &ecryptfs_daemon_hash[i],
+ euid_chain) {
rc = ecryptfs_exorcise_daemon(daemon);
if (rc)
printk(KERN_ERR "%s: Error whilst "
Patches currently in stable-queue which might be from dan.carpenter(a)oracle.com are
queue-4.9/ecryptfs-use-after-free-in-ecryptfs_release_messaging.patch
This is a note to let you know that I've just added the patch titled
block: Fix a race between blk_cleanup_queue() and timeout handling
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
block-fix-a-race-between-blk_cleanup_queue-and-timeout-handling.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 4e9b6f20828ac880dbc1fa2fdbafae779473d1af Mon Sep 17 00:00:00 2001
From: Bart Van Assche <bart.vanassche(a)wdc.com>
Date: Thu, 19 Oct 2017 10:00:48 -0700
Subject: block: Fix a race between blk_cleanup_queue() and timeout handling
From: Bart Van Assche <bart.vanassche(a)wdc.com>
commit 4e9b6f20828ac880dbc1fa2fdbafae779473d1af upstream.
Make sure that if the timeout timer fires after a queue has been
marked "dying" that the affected requests are finished.
Reported-by: chenxiang (M) <chenxiang66(a)hisilicon.com>
Fixes: commit 287922eb0b18 ("block: defer timeouts to a workqueue")
Signed-off-by: Bart Van Assche <bart.vanassche(a)wdc.com>
Tested-by: chenxiang (M) <chenxiang66(a)hisilicon.com>
Cc: Christoph Hellwig <hch(a)lst.de>
Cc: Keith Busch <keith.busch(a)intel.com>
Cc: Hannes Reinecke <hare(a)suse.com>
Cc: Ming Lei <ming.lei(a)redhat.com>
Cc: Johannes Thumshirn <jthumshirn(a)suse.de>
Signed-off-by: Jens Axboe <axboe(a)kernel.dk>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
block/blk-core.c | 2 ++
block/blk-timeout.c | 3 ---
2 files changed, 2 insertions(+), 3 deletions(-)
--- a/block/blk-core.c
+++ b/block/blk-core.c
@@ -282,6 +282,7 @@ EXPORT_SYMBOL(blk_stop_queue);
void blk_sync_queue(struct request_queue *q)
{
del_timer_sync(&q->timeout);
+ cancel_work_sync(&q->timeout_work);
if (q->mq_ops) {
struct blk_mq_hw_ctx *hctx;
@@ -720,6 +721,7 @@ struct request_queue *blk_alloc_queue_no
setup_timer(&q->backing_dev_info.laptop_mode_wb_timer,
laptop_mode_timer_fn, (unsigned long) q);
setup_timer(&q->timeout, blk_rq_timed_out_timer, (unsigned long) q);
+ INIT_WORK(&q->timeout_work, NULL);
INIT_LIST_HEAD(&q->queue_head);
INIT_LIST_HEAD(&q->timeout_list);
INIT_LIST_HEAD(&q->icq_list);
--- a/block/blk-timeout.c
+++ b/block/blk-timeout.c
@@ -135,8 +135,6 @@ void blk_timeout_work(struct work_struct
struct request *rq, *tmp;
int next_set = 0;
- if (blk_queue_enter(q, true))
- return;
spin_lock_irqsave(q->queue_lock, flags);
list_for_each_entry_safe(rq, tmp, &q->timeout_list, timeout_list)
@@ -146,7 +144,6 @@ void blk_timeout_work(struct work_struct
mod_timer(&q->timeout, round_jiffies_up(next));
spin_unlock_irqrestore(q->queue_lock, flags);
- blk_queue_exit(q);
}
/**
Patches currently in stable-queue which might be from bart.vanassche(a)wdc.com are
queue-4.9/block-fix-a-race-between-blk_cleanup_queue-and-timeout-handling.patch
This is a note to let you know that I've just added the patch titled
bcache: check ca->alloc_thread initialized before wake up it
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
bcache-check-ca-alloc_thread-initialized-before-wake-up-it.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 91af8300d9c1d7c6b6a2fd754109e08d4798b8d8 Mon Sep 17 00:00:00 2001
From: Coly Li <colyli(a)suse.de>
Date: Fri, 13 Oct 2017 16:35:29 -0700
Subject: bcache: check ca->alloc_thread initialized before wake up it
From: Coly Li <colyli(a)suse.de>
commit 91af8300d9c1d7c6b6a2fd754109e08d4798b8d8 upstream.
In bcache code, sysfs entries are created before all resources get
allocated, e.g. allocation thread of a cache set.
There is posibility for NULL pointer deference if a resource is accessed
but which is not initialized yet. Indeed Jorg Bornschein catches one on
cache set allocation thread and gets a kernel oops.
The reason for this bug is, when bch_bucket_alloc() is called during
cache set registration and attaching, ca->alloc_thread is not properly
allocated and initialized yet, call wake_up_process() on ca->alloc_thread
triggers NULL pointer deference failure. A simple and fast fix is, before
waking up ca->alloc_thread, checking whether it is allocated, and only
wake up ca->alloc_thread when it is not NULL.
Signed-off-by: Coly Li <colyli(a)suse.de>
Reported-by: Jorg Bornschein <jb(a)capsec.org>
Cc: Kent Overstreet <kent.overstreet(a)gmail.com>
Reviewed-by: Michael Lyle <mlyle(a)lyle.org>
Signed-off-by: Jens Axboe <axboe(a)kernel.dk>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/md/bcache/alloc.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/drivers/md/bcache/alloc.c
+++ b/drivers/md/bcache/alloc.c
@@ -404,7 +404,8 @@ long bch_bucket_alloc(struct cache *ca,
finish_wait(&ca->set->bucket_wait, &w);
out:
- wake_up_process(ca->alloc_thread);
+ if (ca->alloc_thread)
+ wake_up_process(ca->alloc_thread);
trace_bcache_alloc(ca, reserve);
Patches currently in stable-queue which might be from colyli(a)suse.de are
queue-4.9/bcache-only-permit-to-recovery-read-error-when-cache-device-is-clean.patch
queue-4.9/bcache-check-ca-alloc_thread-initialized-before-wake-up-it.patch
This is a note to let you know that I've just added the patch titled
autofs: don't fail mount for transient error
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
autofs-don-t-fail-mount-for-transient-error.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From ecc0c469f27765ed1e2b967be0aa17cee1a60b76 Mon Sep 17 00:00:00 2001
From: NeilBrown <neilb(a)suse.com>
Date: Fri, 17 Nov 2017 15:29:13 -0800
Subject: autofs: don't fail mount for transient error
From: NeilBrown <neilb(a)suse.com>
commit ecc0c469f27765ed1e2b967be0aa17cee1a60b76 upstream.
Currently if the autofs kernel module gets an error when writing to the
pipe which links to the daemon, then it marks the whole moutpoint as
catatonic, and it will stop working.
It is possible that the error is transient. This can happen if the
daemon is slow and more than 16 requests queue up. If a subsequent
process tries to queue a request, and is then signalled, the write to
the pipe will return -ERESTARTSYS and autofs will take that as total
failure.
So change the code to assess -ERESTARTSYS and -ENOMEM as transient
failures which only abort the current request, not the whole mountpoint.
It isn't a crash or a data corruption, but having autofs mountpoints
suddenly stop working is rather inconvenient.
Ian said:
: And given the problems with a half dozen (or so) user space applications
: consuming large amounts of CPU under heavy mount and umount activity this
: could happen more easily than we expect.
Link: http://lkml.kernel.org/r/87y3norvgp.fsf@notabene.neil.brown.name
Signed-off-by: NeilBrown <neilb(a)suse.com>
Acked-by: Ian Kent <raven(a)themaw.net>
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds(a)linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
fs/autofs4/waitq.c | 15 ++++++++++++++-
1 file changed, 14 insertions(+), 1 deletion(-)
--- a/fs/autofs4/waitq.c
+++ b/fs/autofs4/waitq.c
@@ -87,7 +87,8 @@ static int autofs4_write(struct autofs_s
spin_unlock_irqrestore(¤t->sighand->siglock, flags);
}
- return (bytes > 0);
+ /* if 'wr' returned 0 (impossible) we assume -EIO (safe) */
+ return bytes == 0 ? 0 : wr < 0 ? wr : -EIO;
}
static void autofs4_notify_daemon(struct autofs_sb_info *sbi,
@@ -101,6 +102,7 @@ static void autofs4_notify_daemon(struct
} pkt;
struct file *pipe = NULL;
size_t pktsz;
+ int ret;
pr_debug("wait id = 0x%08lx, name = %.*s, type=%d\n",
(unsigned long) wq->wait_queue_token,
@@ -175,7 +177,18 @@ static void autofs4_notify_daemon(struct
mutex_unlock(&sbi->wq_mutex);
if (autofs4_write(sbi, pipe, &pkt, pktsz))
+ switch (ret = autofs4_write(sbi, pipe, &pkt, pktsz)) {
+ case 0:
+ break;
+ case -ENOMEM:
+ case -ERESTARTSYS:
+ /* Just fail this one */
+ autofs4_wait_release(sbi, wq->wait_queue_token, ret);
+ break;
+ default:
autofs4_catatonic_mode(sbi);
+ break;
+ }
fput(pipe);
}
Patches currently in stable-queue which might be from neilb(a)suse.com are
queue-4.9/autofs-don-t-fail-mount-for-transient-error.patch
This is a note to let you know that I've just added the patch titled
ALSA: usb-audio: Fix potential zero-division at parsing FU
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
alsa-usb-audio-fix-potential-zero-division-at-parsing-fu.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 8428a8ebde2db1e988e41a58497a28beb7ce1705 Mon Sep 17 00:00:00 2001
From: Takashi Iwai <tiwai(a)suse.de>
Date: Tue, 21 Nov 2017 17:07:43 +0100
Subject: ALSA: usb-audio: Fix potential zero-division at parsing FU
From: Takashi Iwai <tiwai(a)suse.de>
commit 8428a8ebde2db1e988e41a58497a28beb7ce1705 upstream.
parse_audio_feature_unit() contains a code dividing potentially with
zero when a malformed FU descriptor is passed. Although there is
already a sanity check, it checks only the value zero, hence it can
still lead to a zero-division when a value 1 is passed there.
Fix it by correcting the sanity check (and the error message
thereof).
Fixes: 23caaf19b11e ("ALSA: usb-mixer: Add support for Audio Class v2.0")
Signed-off-by: Takashi Iwai <tiwai(a)suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
sound/usb/mixer.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/sound/usb/mixer.c
+++ b/sound/usb/mixer.c
@@ -1470,9 +1470,9 @@ static int parse_audio_feature_unit(stru
return -EINVAL;
}
csize = hdr->bControlSize;
- if (!csize) {
+ if (csize <= 1) {
usb_audio_dbg(state->chip,
- "unit %u: invalid bControlSize == 0\n",
+ "unit %u: invalid bControlSize <= 1\n",
unitid);
return -EINVAL;
}
Patches currently in stable-queue which might be from tiwai(a)suse.de are
queue-4.9/alsa-usb-audio-fix-potential-zero-division-at-parsing-fu.patch
queue-4.9/alsa-timer-remove-kernel-warning-at-compat-ioctl-error-paths.patch
queue-4.9/alsa-hda-add-raven-pci-id.patch
queue-4.9/alsa-usb-audio-add-sanity-checks-in-v2-clock-parsers.patch
queue-4.9/alsa-hda-fix-too-short-hdmi-dp-chmap-reporting.patch
queue-4.9/alsa-hda-realtek-fix-alc700-family-no-sound-issue.patch
queue-4.9/alsa-usb-audio-fix-potential-out-of-bound-access-at-parsing-su.patch
queue-4.9/alsa-pcm-update-tstamp-only-if-audio_tstamp-changed.patch
queue-4.9/alsa-usb-audio-add-sanity-checks-to-fe-parser.patch
This is a note to let you know that I've just added the patch titled
ata: fixes kernel crash while tracing ata_eh_link_autopsy event
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
ata-fixes-kernel-crash-while-tracing-ata_eh_link_autopsy-event.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From f1601113ddc0339a745e702f4fb1ca37d4875e65 Mon Sep 17 00:00:00 2001
From: Rameshwar Prasad Sahu <rsahu(a)apm.com>
Date: Thu, 2 Nov 2017 16:31:07 +0530
Subject: ata: fixes kernel crash while tracing ata_eh_link_autopsy event
From: Rameshwar Prasad Sahu <rsahu(a)apm.com>
commit f1601113ddc0339a745e702f4fb1ca37d4875e65 upstream.
When tracing ata link error event, the kernel crashes when the disk is
removed due to NULL pointer access by trace_ata_eh_link_autopsy API.
This occurs as the dev is NULL when the disk disappeared. This patch
fixes this crash by calling trace_ata_eh_link_autopsy only if "dev"
is not NULL.
v2 changes:
Removed direct passing "link" pointer instead of "dev" in trace API.
Signed-off-by: Rameshwar Prasad Sahu <rsahu(a)apm.com>
Signed-off-by: Tejun Heo <tj(a)kernel.org>
Fixes: 255c03d15a29 ("libata: Add tracepoints")
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/ata/libata-eh.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/ata/libata-eh.c
+++ b/drivers/ata/libata-eh.c
@@ -2329,8 +2329,8 @@ static void ata_eh_link_autopsy(struct a
if (dev->flags & ATA_DFLAG_DUBIOUS_XFER)
eflags |= ATA_EFLAG_DUBIOUS_XFER;
ehc->i.action |= ata_eh_speed_down(dev, eflags, all_err_mask);
+ trace_ata_eh_link_autopsy(dev, ehc->i.action, all_err_mask);
}
- trace_ata_eh_link_autopsy(dev, ehc->i.action, all_err_mask);
DPRINTK("EXIT\n");
}
Patches currently in stable-queue which might be from rsahu(a)apm.com are
queue-4.9/ata-fixes-kernel-crash-while-tracing-ata_eh_link_autopsy-event.patch
This is a note to let you know that I've just added the patch titled
ALSA: usb-audio: Add sanity checks to FE parser
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
alsa-usb-audio-add-sanity-checks-to-fe-parser.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From d937cd6790a2bef2d07b500487646bd794c039bb Mon Sep 17 00:00:00 2001
From: Takashi Iwai <tiwai(a)suse.de>
Date: Tue, 21 Nov 2017 16:55:51 +0100
Subject: ALSA: usb-audio: Add sanity checks to FE parser
From: Takashi Iwai <tiwai(a)suse.de>
commit d937cd6790a2bef2d07b500487646bd794c039bb upstream.
When the usb-audio descriptor contains the malformed feature unit
description with a too short length, the driver may access
out-of-bounds. Add a sanity check of the header size at the beginning
of parse_audio_feature_unit().
Fixes: 23caaf19b11e ("ALSA: usb-mixer: Add support for Audio Class v2.0")
Reported-by: Andrey Konovalov <andreyknvl(a)google.com>
Signed-off-by: Takashi Iwai <tiwai(a)suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
sound/usb/mixer.c | 12 ++++++++++++
1 file changed, 12 insertions(+)
--- a/sound/usb/mixer.c
+++ b/sound/usb/mixer.c
@@ -1463,6 +1463,12 @@ static int parse_audio_feature_unit(stru
__u8 *bmaControls;
if (state->mixer->protocol == UAC_VERSION_1) {
+ if (hdr->bLength < 7) {
+ usb_audio_err(state->chip,
+ "unit %u: invalid UAC_FEATURE_UNIT descriptor\n",
+ unitid);
+ return -EINVAL;
+ }
csize = hdr->bControlSize;
if (!csize) {
usb_audio_dbg(state->chip,
@@ -1480,6 +1486,12 @@ static int parse_audio_feature_unit(stru
}
} else {
struct uac2_feature_unit_descriptor *ftr = _ftr;
+ if (hdr->bLength < 6) {
+ usb_audio_err(state->chip,
+ "unit %u: invalid UAC_FEATURE_UNIT descriptor\n",
+ unitid);
+ return -EINVAL;
+ }
csize = 4;
channels = (hdr->bLength - 6) / 4 - 1;
bmaControls = ftr->bmaControls;
Patches currently in stable-queue which might be from tiwai(a)suse.de are
queue-4.9/alsa-usb-audio-fix-potential-zero-division-at-parsing-fu.patch
queue-4.9/alsa-timer-remove-kernel-warning-at-compat-ioctl-error-paths.patch
queue-4.9/alsa-hda-add-raven-pci-id.patch
queue-4.9/alsa-usb-audio-add-sanity-checks-in-v2-clock-parsers.patch
queue-4.9/alsa-hda-fix-too-short-hdmi-dp-chmap-reporting.patch
queue-4.9/alsa-hda-realtek-fix-alc700-family-no-sound-issue.patch
queue-4.9/alsa-usb-audio-fix-potential-out-of-bound-access-at-parsing-su.patch
queue-4.9/alsa-pcm-update-tstamp-only-if-audio_tstamp-changed.patch
queue-4.9/alsa-usb-audio-add-sanity-checks-to-fe-parser.patch
This is a note to let you know that I've just added the patch titled
ALSA: usb-audio: Fix potential out-of-bound access at parsing SU
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
alsa-usb-audio-fix-potential-out-of-bound-access-at-parsing-su.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From f658f17b5e0e339935dca23e77e0f3cad591926b Mon Sep 17 00:00:00 2001
From: Takashi Iwai <tiwai(a)suse.de>
Date: Tue, 21 Nov 2017 17:00:32 +0100
Subject: ALSA: usb-audio: Fix potential out-of-bound access at parsing SU
From: Takashi Iwai <tiwai(a)suse.de>
commit f658f17b5e0e339935dca23e77e0f3cad591926b upstream.
The usb-audio driver may trigger an out-of-bound access at parsing a
malformed selector unit, as it checks the header length only after
evaluating bNrInPins field, which can be already above the given
length. Fix it by adding the length check beforehand.
Fixes: 99fc86450c43 ("ALSA: usb-mixer: parse descriptors with structs")
Signed-off-by: Takashi Iwai <tiwai(a)suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
sound/usb/mixer.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/sound/usb/mixer.c
+++ b/sound/usb/mixer.c
@@ -2092,7 +2092,8 @@ static int parse_audio_selector_unit(str
const struct usbmix_name_map *map;
char **namelist;
- if (!desc->bNrInPins || desc->bLength < 5 + desc->bNrInPins) {
+ if (desc->bLength < 5 || !desc->bNrInPins ||
+ desc->bLength < 5 + desc->bNrInPins) {
usb_audio_err(state->chip,
"invalid SELECTOR UNIT descriptor %d\n", unitid);
return -EINVAL;
Patches currently in stable-queue which might be from tiwai(a)suse.de are
queue-4.9/alsa-usb-audio-fix-potential-zero-division-at-parsing-fu.patch
queue-4.9/alsa-timer-remove-kernel-warning-at-compat-ioctl-error-paths.patch
queue-4.9/alsa-hda-add-raven-pci-id.patch
queue-4.9/alsa-usb-audio-add-sanity-checks-in-v2-clock-parsers.patch
queue-4.9/alsa-hda-fix-too-short-hdmi-dp-chmap-reporting.patch
queue-4.9/alsa-hda-realtek-fix-alc700-family-no-sound-issue.patch
queue-4.9/alsa-usb-audio-fix-potential-out-of-bound-access-at-parsing-su.patch
queue-4.9/alsa-pcm-update-tstamp-only-if-audio_tstamp-changed.patch
queue-4.9/alsa-usb-audio-add-sanity-checks-to-fe-parser.patch
This is a note to let you know that I've just added the patch titled
ALSA: usb-audio: Add sanity checks in v2 clock parsers
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
alsa-usb-audio-add-sanity-checks-in-v2-clock-parsers.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 0a62d6c966956d77397c32836a5bbfe3af786fc1 Mon Sep 17 00:00:00 2001
From: Takashi Iwai <tiwai(a)suse.de>
Date: Tue, 21 Nov 2017 17:28:06 +0100
Subject: ALSA: usb-audio: Add sanity checks in v2 clock parsers
From: Takashi Iwai <tiwai(a)suse.de>
commit 0a62d6c966956d77397c32836a5bbfe3af786fc1 upstream.
The helper functions to parse and look for the clock source, selector
and multiplier unit may return the descriptor with a too short length
than required, while there is no sanity check in the caller side.
Add some sanity checks in the parsers, at least, to guarantee the
given descriptor size, for avoiding the potential crashes.
Fixes: 79f920fbff56 ("ALSA: usb-audio: parse clock topology of UAC2 devices")
Reported-by: Andrey Konovalov <andreyknvl(a)google.com>
Signed-off-by: Takashi Iwai <tiwai(a)suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
sound/usb/clock.c | 9 ++++++---
1 file changed, 6 insertions(+), 3 deletions(-)
--- a/sound/usb/clock.c
+++ b/sound/usb/clock.c
@@ -43,7 +43,7 @@ static struct uac_clock_source_descripto
while ((cs = snd_usb_find_csint_desc(ctrl_iface->extra,
ctrl_iface->extralen,
cs, UAC2_CLOCK_SOURCE))) {
- if (cs->bClockID == clock_id)
+ if (cs->bLength >= sizeof(*cs) && cs->bClockID == clock_id)
return cs;
}
@@ -59,8 +59,11 @@ static struct uac_clock_selector_descrip
while ((cs = snd_usb_find_csint_desc(ctrl_iface->extra,
ctrl_iface->extralen,
cs, UAC2_CLOCK_SELECTOR))) {
- if (cs->bClockID == clock_id)
+ if (cs->bLength >= sizeof(*cs) && cs->bClockID == clock_id) {
+ if (cs->bLength < 5 + cs->bNrInPins)
+ return NULL;
return cs;
+ }
}
return NULL;
@@ -75,7 +78,7 @@ static struct uac_clock_multiplier_descr
while ((cs = snd_usb_find_csint_desc(ctrl_iface->extra,
ctrl_iface->extralen,
cs, UAC2_CLOCK_MULTIPLIER))) {
- if (cs->bClockID == clock_id)
+ if (cs->bLength >= sizeof(*cs) && cs->bClockID == clock_id)
return cs;
}
Patches currently in stable-queue which might be from tiwai(a)suse.de are
queue-4.9/alsa-usb-audio-fix-potential-zero-division-at-parsing-fu.patch
queue-4.9/alsa-timer-remove-kernel-warning-at-compat-ioctl-error-paths.patch
queue-4.9/alsa-hda-add-raven-pci-id.patch
queue-4.9/alsa-usb-audio-add-sanity-checks-in-v2-clock-parsers.patch
queue-4.9/alsa-hda-fix-too-short-hdmi-dp-chmap-reporting.patch
queue-4.9/alsa-hda-realtek-fix-alc700-family-no-sound-issue.patch
queue-4.9/alsa-usb-audio-fix-potential-out-of-bound-access-at-parsing-su.patch
queue-4.9/alsa-pcm-update-tstamp-only-if-audio_tstamp-changed.patch
queue-4.9/alsa-usb-audio-add-sanity-checks-to-fe-parser.patch
This is a note to let you know that I've just added the patch titled
ALSA: timer: Remove kernel warning at compat ioctl error paths
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
alsa-timer-remove-kernel-warning-at-compat-ioctl-error-paths.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 3d4e8303f2c747c8540a0a0126d0151514f6468b Mon Sep 17 00:00:00 2001
From: Takashi Iwai <tiwai(a)suse.de>
Date: Tue, 21 Nov 2017 16:36:11 +0100
Subject: ALSA: timer: Remove kernel warning at compat ioctl error paths
From: Takashi Iwai <tiwai(a)suse.de>
commit 3d4e8303f2c747c8540a0a0126d0151514f6468b upstream.
Some timer compat ioctls have NULL checks of timer instance with
snd_BUG_ON() that bring up WARN_ON() when the debug option is set.
Actually the condition can be met in the normal situation and it's
confusing and bad to spew kernel warnings with stack trace there.
Let's remove snd_BUG_ON() invocation and replace with the simple
checks. Also, correct the error code to EBADFD to follow the native
ioctl error handling.
Reported-by: syzbot <syzkaller(a)googlegroups.com>
Signed-off-by: Takashi Iwai <tiwai(a)suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
sound/core/timer_compat.c | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
--- a/sound/core/timer_compat.c
+++ b/sound/core/timer_compat.c
@@ -66,11 +66,11 @@ static int snd_timer_user_info_compat(st
struct snd_timer *t;
tu = file->private_data;
- if (snd_BUG_ON(!tu->timeri))
- return -ENXIO;
+ if (!tu->timeri)
+ return -EBADFD;
t = tu->timeri->timer;
- if (snd_BUG_ON(!t))
- return -ENXIO;
+ if (!t)
+ return -EBADFD;
memset(&info, 0, sizeof(info));
info.card = t->card ? t->card->number : -1;
if (t->hw.flags & SNDRV_TIMER_HW_SLAVE)
@@ -99,8 +99,8 @@ static int snd_timer_user_status_compat(
struct snd_timer_status32 status;
tu = file->private_data;
- if (snd_BUG_ON(!tu->timeri))
- return -ENXIO;
+ if (!tu->timeri)
+ return -EBADFD;
memset(&status, 0, sizeof(status));
status.tstamp.tv_sec = tu->tstamp.tv_sec;
status.tstamp.tv_nsec = tu->tstamp.tv_nsec;
Patches currently in stable-queue which might be from tiwai(a)suse.de are
queue-4.9/alsa-usb-audio-fix-potential-zero-division-at-parsing-fu.patch
queue-4.9/alsa-timer-remove-kernel-warning-at-compat-ioctl-error-paths.patch
queue-4.9/alsa-hda-add-raven-pci-id.patch
queue-4.9/alsa-usb-audio-add-sanity-checks-in-v2-clock-parsers.patch
queue-4.9/alsa-hda-fix-too-short-hdmi-dp-chmap-reporting.patch
queue-4.9/alsa-hda-realtek-fix-alc700-family-no-sound-issue.patch
queue-4.9/alsa-usb-audio-fix-potential-out-of-bound-access-at-parsing-su.patch
queue-4.9/alsa-pcm-update-tstamp-only-if-audio_tstamp-changed.patch
queue-4.9/alsa-usb-audio-add-sanity-checks-to-fe-parser.patch
This is a note to let you know that I've just added the patch titled
ALSA: hda/realtek - Fix ALC700 family no sound issue
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
alsa-hda-realtek-fix-alc700-family-no-sound-issue.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 2d7fe6185722b0817bb345f62ab06b76a7b26542 Mon Sep 17 00:00:00 2001
From: Kailang Yang <kailang(a)realtek.com>
Date: Wed, 22 Nov 2017 15:21:32 +0800
Subject: ALSA: hda/realtek - Fix ALC700 family no sound issue
From: Kailang Yang <kailang(a)realtek.com>
commit 2d7fe6185722b0817bb345f62ab06b76a7b26542 upstream.
It maybe the typo for ALC700 support patch.
To fix the bit value on this patch.
Fixes: 6fbae35a3170 ("ALSA: hda/realtek - Add support for new codecs ALC700/ALC701/ALC703")
Signed-off-by: Kailang Yang <kailang(a)realtek.com>
Signed-off-by: Takashi Iwai <tiwai(a)suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
sound/pci/hda/patch_realtek.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/sound/pci/hda/patch_realtek.c
+++ b/sound/pci/hda/patch_realtek.c
@@ -6272,7 +6272,7 @@ static int patch_alc269(struct hda_codec
case 0x10ec0703:
spec->codec_variant = ALC269_TYPE_ALC700;
spec->gen.mixer_nid = 0; /* ALC700 does not have any loopback mixer path */
- alc_update_coef_idx(codec, 0x4a, 0, 1 << 15); /* Combo jack auto trigger control */
+ alc_update_coef_idx(codec, 0x4a, 1 << 15, 0); /* Combo jack auto trigger control */
break;
}
Patches currently in stable-queue which might be from kailang(a)realtek.com are
queue-4.9/alsa-hda-realtek-fix-alc700-family-no-sound-issue.patch
This is a note to let you know that I've just added the patch titled
ALSA: pcm: update tstamp only if audio_tstamp changed
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
alsa-pcm-update-tstamp-only-if-audio_tstamp-changed.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 20e3f985bb875fea4f86b04eba4b6cc29bfd6b71 Mon Sep 17 00:00:00 2001
From: Henrik Eriksson <henrik.eriksson(a)axis.com>
Date: Tue, 21 Nov 2017 09:29:28 +0100
Subject: ALSA: pcm: update tstamp only if audio_tstamp changed
From: Henrik Eriksson <henrik.eriksson(a)axis.com>
commit 20e3f985bb875fea4f86b04eba4b6cc29bfd6b71 upstream.
commit 3179f6200188 ("ALSA: core: add .get_time_info") had a side effect
of changing the behaviour of the PCM runtime tstamp. Prior to this
change tstamp was not updated by snd_pcm_update_hw_ptr0() unless the
hw_ptr had moved, after this change tstamp was always updated.
For an application using alsa-lib, doing snd_pcm_readi() followed by
snd_pcm_status() to estimate the age of the read samples by subtracting
status->avail * [sample rate] from status->tstamp this change degraded
the accuracy of the estimate on devices where the pcm hw does not
provide a granular hw_ptr, e.g., devices using
soc-generic-dmaengine-pcm.c and a dma-engine with residue_granularity
DMA_RESIDUE_GRANULARITY_DESCRIPTOR. The accuracy of the estimate
depended on the latency between the PCM hw completing a period and the
driver called snd_pcm_period_elapsed() to notify ALSA core, typically
determined by interrupt handling latency. After the change the accuracy
of the estimate depended on the latency between the PCM hw completing a
period and the application calling snd_pcm_status(), determined by the
scheduling of the application process. The maximum error of the
estimate is one period length in both cases, but the error average and
variance is smaller when it depends on interrupt latency.
Instead of always updating tstamp, update it only if audio_tstamp
changed.
Fixes: 3179f6200188 ("ALSA: core: add .get_time_info")
Suggested-by: Pierre-Louis Bossart <pierre-louis.bossart(a)linux.intel.com>
Signed-off-by: Henrik Eriksson <henrik.eriksson(a)axis.com>
Signed-off-by: Takashi Iwai <tiwai(a)suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
sound/core/pcm_lib.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
--- a/sound/core/pcm_lib.c
+++ b/sound/core/pcm_lib.c
@@ -264,8 +264,10 @@ static void update_audio_tstamp(struct s
runtime->rate);
*audio_tstamp = ns_to_timespec(audio_nsecs);
}
- runtime->status->audio_tstamp = *audio_tstamp;
- runtime->status->tstamp = *curr_tstamp;
+ if (!timespec_equal(&runtime->status->audio_tstamp, audio_tstamp)) {
+ runtime->status->audio_tstamp = *audio_tstamp;
+ runtime->status->tstamp = *curr_tstamp;
+ }
/*
* re-take a driver timestamp to let apps detect if the reference tstamp
Patches currently in stable-queue which might be from henrik.eriksson(a)axis.com are
queue-4.9/alsa-pcm-update-tstamp-only-if-audio_tstamp-changed.patch
This is a note to let you know that I've just added the patch titled
ALSA: hda: Fix too short HDMI/DP chmap reporting
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
alsa-hda-fix-too-short-hdmi-dp-chmap-reporting.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From c2432466f583cb719b35a41e757da587d9ab1d00 Mon Sep 17 00:00:00 2001
From: Takashi Iwai <tiwai(a)suse.de>
Date: Fri, 17 Nov 2017 12:08:40 +0100
Subject: ALSA: hda: Fix too short HDMI/DP chmap reporting
From: Takashi Iwai <tiwai(a)suse.de>
commit c2432466f583cb719b35a41e757da587d9ab1d00 upstream.
We got a regression report about the HD-audio HDMI chmap, where some
surround channels are reported as UNKNOWN. The git bisection pointed
the culprit at the commit 9b3dc8aa3fb1 ("ALSA: hda - Register chmap
obj as priv data instead of codec"). The story behind scene is like
this:
- While moving the code out of the legacy HDA to the HDA common place,
the patch modifies the code to obtain the chmap array indirectly in
a byte array, and it expands it to kctl value array.
- At the latter operation, the size of the array is wrongly passed by
sizeof() to the pointer.
- It can be 4 on 32bit arch, thus too short for 6+ channels.
(And that's the reason why it didn't hit other persons; it's 8 on
64bit arch, thus it's usually enough.)
The code was further changed meanwhile, but the problem persisted.
Let's fix it by correctly evaluating the array size.
Fixes: 9b3dc8aa3fb1 ("ALSA: hda - Register chmap obj as priv data instead of codec")
Reported-by: VDR User <user.vdr(a)gmail.com>
Signed-off-by: Takashi Iwai <tiwai(a)suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
sound/hda/hdmi_chmap.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/sound/hda/hdmi_chmap.c
+++ b/sound/hda/hdmi_chmap.c
@@ -746,7 +746,7 @@ static int hdmi_chmap_ctl_get(struct snd
memset(pcm_chmap, 0, sizeof(pcm_chmap));
chmap->ops.get_chmap(chmap->hdac, pcm_idx, pcm_chmap);
- for (i = 0; i < sizeof(chmap); i++)
+ for (i = 0; i < ARRAY_SIZE(pcm_chmap); i++)
ucontrol->value.integer.value[i] = pcm_chmap[i];
return 0;
Patches currently in stable-queue which might be from tiwai(a)suse.de are
queue-4.9/alsa-usb-audio-fix-potential-zero-division-at-parsing-fu.patch
queue-4.9/alsa-timer-remove-kernel-warning-at-compat-ioctl-error-paths.patch
queue-4.9/alsa-hda-add-raven-pci-id.patch
queue-4.9/alsa-usb-audio-add-sanity-checks-in-v2-clock-parsers.patch
queue-4.9/alsa-hda-fix-too-short-hdmi-dp-chmap-reporting.patch
queue-4.9/alsa-hda-realtek-fix-alc700-family-no-sound-issue.patch
queue-4.9/alsa-usb-audio-fix-potential-out-of-bound-access-at-parsing-su.patch
queue-4.9/alsa-pcm-update-tstamp-only-if-audio_tstamp-changed.patch
queue-4.9/alsa-usb-audio-add-sanity-checks-to-fe-parser.patch
This is a note to let you know that I've just added the patch titled
ALSA: usb-audio: Fix potential zero-division at parsing FU
to the 3.18-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
alsa-usb-audio-fix-potential-zero-division-at-parsing-fu.patch
and it can be found in the queue-3.18 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 8428a8ebde2db1e988e41a58497a28beb7ce1705 Mon Sep 17 00:00:00 2001
From: Takashi Iwai <tiwai(a)suse.de>
Date: Tue, 21 Nov 2017 17:07:43 +0100
Subject: ALSA: usb-audio: Fix potential zero-division at parsing FU
From: Takashi Iwai <tiwai(a)suse.de>
commit 8428a8ebde2db1e988e41a58497a28beb7ce1705 upstream.
parse_audio_feature_unit() contains a code dividing potentially with
zero when a malformed FU descriptor is passed. Although there is
already a sanity check, it checks only the value zero, hence it can
still lead to a zero-division when a value 1 is passed there.
Fix it by correcting the sanity check (and the error message
thereof).
Fixes: 23caaf19b11e ("ALSA: usb-mixer: Add support for Audio Class v2.0")
Signed-off-by: Takashi Iwai <tiwai(a)suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
sound/usb/mixer.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/sound/usb/mixer.c
+++ b/sound/usb/mixer.c
@@ -1380,9 +1380,9 @@ static int parse_audio_feature_unit(stru
return -EINVAL;
}
csize = hdr->bControlSize;
- if (!csize) {
+ if (csize <= 1) {
usb_audio_dbg(state->chip,
- "unit %u: invalid bControlSize == 0\n",
+ "unit %u: invalid bControlSize <= 1\n",
unitid);
return -EINVAL;
}
Patches currently in stable-queue which might be from tiwai(a)suse.de are
queue-3.18/alsa-usb-audio-fix-potential-zero-division-at-parsing-fu.patch
queue-3.18/alsa-timer-remove-kernel-warning-at-compat-ioctl-error-paths.patch
queue-3.18/alsa-hda-add-raven-pci-id.patch
queue-3.18/alsa-usb-audio-add-sanity-checks-in-v2-clock-parsers.patch
queue-3.18/alsa-usb-audio-fix-potential-out-of-bound-access-at-parsing-su.patch
queue-3.18/alsa-usb-audio-add-sanity-checks-to-fe-parser.patch
This is a note to let you know that I've just added the patch titled
rtlwifi: rtl8192ee: Fix memory leak when loading firmware
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
rtlwifi-rtl8192ee-fix-memory-leak-when-loading-firmware.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 519ce2f933fa14acf69d5c8cabcc18711943d629 Mon Sep 17 00:00:00 2001
From: Larry Finger <Larry.Finger(a)lwfinger.net>
Date: Thu, 14 Sep 2017 13:17:44 -0500
Subject: rtlwifi: rtl8192ee: Fix memory leak when loading firmware
From: Larry Finger <Larry.Finger(a)lwfinger.net>
commit 519ce2f933fa14acf69d5c8cabcc18711943d629 upstream.
In routine rtl92ee_set_fw_rsvdpagepkt(), the driver allocates an skb, but
never calls rtl_cmd_send_packet(), which will free the buffer. All other
rtlwifi drivers perform this operation correctly.
This problem has been in the driver since it was included in the kernel.
Fortunately, each firmware load only leaks 4 buffers, which likely
explains why it has not previously been detected.
Signed-off-by: Larry Finger <Larry.Finger(a)lwfinger.net>
Signed-off-by: Kalle Valo <kvalo(a)codeaurora.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/wireless/realtek/rtlwifi/rtl8192ee/fw.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8192ee/fw.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8192ee/fw.c
@@ -664,7 +664,7 @@ void rtl92ee_set_fw_rsvdpagepkt(struct i
struct rtl_priv *rtlpriv = rtl_priv(hw);
struct rtl_mac *mac = rtl_mac(rtl_priv(hw));
struct sk_buff *skb = NULL;
-
+ bool rtstatus;
u32 totalpacketlen;
u8 u1rsvdpageloc[5] = { 0 };
bool b_dlok = false;
@@ -727,7 +727,9 @@ void rtl92ee_set_fw_rsvdpagepkt(struct i
memcpy((u8 *)skb_put(skb, totalpacketlen),
&reserved_page_packet, totalpacketlen);
- b_dlok = true;
+ rtstatus = rtl_cmd_send_packet(hw, skb);
+ if (rtstatus)
+ b_dlok = true;
if (b_dlok) {
RT_TRACE(rtlpriv, COMP_POWER, DBG_LOUD ,
Patches currently in stable-queue which might be from Larry.Finger(a)lwfinger.net are
queue-4.4/rtlwifi-fix-uninitialized-rtlhal-last_suspend_sec-time.patch
queue-4.4/rtlwifi-rtl8192ee-fix-memory-leak-when-loading-firmware.patch
This is a note to let you know that I've just added the patch titled
target: Fix QUEUE_FULL + SCSI task attribute handling
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
target-fix-queue_full-scsi-task-attribute-handling.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 1c79df1f349fb6050016cea4ef1dfbc3853a5685 Mon Sep 17 00:00:00 2001
From: Nicholas Bellinger <nab(a)linux-iscsi.org>
Date: Fri, 22 Sep 2017 16:48:28 -0700
Subject: target: Fix QUEUE_FULL + SCSI task attribute handling
From: Nicholas Bellinger <nab(a)linux-iscsi.org>
commit 1c79df1f349fb6050016cea4ef1dfbc3853a5685 upstream.
This patch fixes a bug during QUEUE_FULL where transport_complete_qf()
calls transport_complete_task_attr() after it's already been invoked
by target_complete_ok_work() or transport_generic_request_failure()
during initial completion, preceeding QUEUE_FULL.
This will result in se_device->simple_cmds, se_device->dev_cur_ordered_id
and/or se_device->dev_ordered_sync being updated multiple times for
a single se_cmd.
To address this bug, clear SCF_TASK_ATTR_SET after the first call
to transport_complete_task_attr(), and avoid updating SCSI task
attribute related counters for any subsequent calls.
Also, when a se_cmd is deferred due to ordered tags and executed
via target_restart_delayed_cmds(), set CMD_T_SENT before execution
matching what target_execute_cmd() does.
Cc: Michael Cyr <mikecyr(a)linux.vnet.ibm.com>
Cc: Bryant G. Ly <bryantly(a)linux.vnet.ibm.com>
Cc: Mike Christie <mchristi(a)redhat.com>
Cc: Hannes Reinecke <hare(a)suse.com>
Signed-off-by: Nicholas Bellinger <nab(a)linux-iscsi.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/target/target_core_transport.c | 4 ++++
1 file changed, 4 insertions(+)
--- a/drivers/target/target_core_transport.c
+++ b/drivers/target/target_core_transport.c
@@ -1970,6 +1970,8 @@ static void target_restart_delayed_cmds(
list_del(&cmd->se_delayed_node);
spin_unlock(&dev->delayed_cmd_lock);
+ cmd->transport_state |= CMD_T_SENT;
+
__target_execute_cmd(cmd, true);
if (cmd->sam_task_attr == TCM_ORDERED_TAG)
@@ -2007,6 +2009,8 @@ static void transport_complete_task_attr
pr_debug("Incremented dev_cur_ordered_id: %u for ORDERED\n",
dev->dev_cur_ordered_id);
}
+ cmd->se_cmd_flags &= ~SCF_TASK_ATTR_SET;
+
restart:
target_restart_delayed_cmds(dev);
}
Patches currently in stable-queue which might be from nab(a)linux-iscsi.org are
queue-4.4/target-fix-queue_full-scsi-task-attribute-handling.patch
queue-4.4/iscsi-target-fix-non-immediate-tmr-reference-leak.patch
This is a note to let you know that I've just added the patch titled
nilfs2: fix race condition that causes file system corruption
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
nilfs2-fix-race-condition-that-causes-file-system-corruption.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 31ccb1f7ba3cfe29631587d451cf5bb8ab593550 Mon Sep 17 00:00:00 2001
From: Andreas Rohner <andreas.rohner(a)gmx.net>
Date: Fri, 17 Nov 2017 15:29:35 -0800
Subject: nilfs2: fix race condition that causes file system corruption
From: Andreas Rohner <andreas.rohner(a)gmx.net>
commit 31ccb1f7ba3cfe29631587d451cf5bb8ab593550 upstream.
There is a race condition between nilfs_dirty_inode() and
nilfs_set_file_dirty().
When a file is opened, nilfs_dirty_inode() is called to update the
access timestamp in the inode. It calls __nilfs_mark_inode_dirty() in a
separate transaction. __nilfs_mark_inode_dirty() caches the ifile
buffer_head in the i_bh field of the inode info structure and marks it
as dirty.
After some data was written to the file in another transaction, the
function nilfs_set_file_dirty() is called, which adds the inode to the
ns_dirty_files list.
Then the segment construction calls nilfs_segctor_collect_dirty_files(),
which goes through the ns_dirty_files list and checks the i_bh field.
If there is a cached buffer_head in i_bh it is not marked as dirty
again.
Since nilfs_dirty_inode() and nilfs_set_file_dirty() use separate
transactions, it is possible that a segment construction that writes out
the ifile occurs in-between the two. If this happens the inode is not
on the ns_dirty_files list, but its ifile block is still marked as dirty
and written out.
In the next segment construction, the data for the file is written out
and nilfs_bmap_propagate() updates the b-tree. Eventually the bmap root
is written into the i_bh block, which is not dirty, because it was
written out in another segment construction.
As a result the bmap update can be lost, which leads to file system
corruption. Either the virtual block address points to an unallocated
DAT block, or the DAT entry will be reused for something different.
The error can remain undetected for a long time. A typical error
message would be one of the "bad btree" errors or a warning that a DAT
entry could not be found.
This bug can be reproduced reliably by a simple benchmark that creates
and overwrites millions of 4k files.
Link: http://lkml.kernel.org/r/1509367935-3086-2-git-send-email-konishi.ryusuke@l…
Signed-off-by: Andreas Rohner <andreas.rohner(a)gmx.net>
Signed-off-by: Ryusuke Konishi <konishi.ryusuke(a)lab.ntt.co.jp>
Tested-by: Andreas Rohner <andreas.rohner(a)gmx.net>
Tested-by: Ryusuke Konishi <konishi.ryusuke(a)lab.ntt.co.jp>
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds(a)linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
fs/nilfs2/segment.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
--- a/fs/nilfs2/segment.c
+++ b/fs/nilfs2/segment.c
@@ -1945,8 +1945,6 @@ static int nilfs_segctor_collect_dirty_f
"failed to get inode block.\n");
return err;
}
- mark_buffer_dirty(ibh);
- nilfs_mdt_mark_dirty(ifile);
spin_lock(&nilfs->ns_inode_lock);
if (likely(!ii->i_bh))
ii->i_bh = ibh;
@@ -1955,6 +1953,10 @@ static int nilfs_segctor_collect_dirty_f
goto retry;
}
+ // Always redirty the buffer to avoid race condition
+ mark_buffer_dirty(ii->i_bh);
+ nilfs_mdt_mark_dirty(ifile);
+
clear_bit(NILFS_I_QUEUED, &ii->i_state);
set_bit(NILFS_I_BUSY, &ii->i_state);
list_move_tail(&ii->i_dirty, &sci->sc_dirty_files);
Patches currently in stable-queue which might be from andreas.rohner(a)gmx.net are
queue-4.4/nilfs2-fix-race-condition-that-causes-file-system-corruption.patch