Groups > linux.kernel > #1738280 > unrolled thread

[PATCH 3.18 00/42] 3.18.72-stable review

Started by	Greg Kroah-Hartman <gregkh@linuxfoundation.org>
First post	2017-09-24 22:30 +0200
Last post	2017-09-26 01:20 +0200
Articles	20 on this page of 41 — 3 participants

Back to article view | Back to linux.kernel

  [PATCH 3.18 00/42] 3.18.72-stable review Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-09-24 22:30 +0200
    [PATCH 3.18 11/42] [PATCH - RESEND] crypto: AF_ALG - remove SGL terminator indicator when  chaining Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-09-24 22:30 +0200
    [PATCH 3.18 25/42] scsi: sg: use standard lists for sg_requests Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-09-24 22:30 +0200
    [PATCH 3.18 03/42] Revert "net: phy: Correctly process PHY_HALTED in phy_stop_machine()" Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-09-24 22:30 +0200
    [PATCH 3.18 42/42] mac80211: flush hw_roc_start work before cancelling the ROC Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-09-24 22:30 +0200
    [PATCH 3.18 05/42] ipv6: fix memory leak with multiple tables during netns destruction Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-09-24 22:30 +0200
    [PATCH 3.18 27/42] scsi: sg: factor out sg_fill_request_table() Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-09-24 22:30 +0200
    [PATCH 3.18 12/42] ext4: fix incorrect quotaoff if the quota feature is enabled Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-09-24 22:30 +0200
    [PATCH 3.18 01/42] ipv6: accept 64k - 1 packet length in ip6_find_1stfragopt() Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-09-24 22:30 +0200
    [PATCH 3.18 21/42] scsi: zfcp: fix payload with full FCP_RSP IU in SCSI trace records Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-09-24 22:30 +0200
    [PATCH 3.18 29/42] scsi: qla2xxx: Fix an integer overflow in sysfs code Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-09-24 22:30 +0200
    [PATCH 3.18 08/42] [PATCH] Revert "usb: musb: fix tx fifo flush handling again" Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-09-24 22:30 +0200
    [PATCH 3.18 16/42] skd: Avoid that module unloading triggers a use-after-free Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-09-24 22:30 +0200
    [PATCH 3.18 30/42] ftrace: Fix selftest goto location on error Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-09-24 22:40 +0200
    [PATCH 3.18 07/42] f2fs: check hot_data for roll-forward recovery Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-09-24 22:40 +0200
    [PATCH 3.18 37/42] bcache: Fix leak of bdev reference Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-09-24 22:40 +0200
    [PATCH 3.18 40/42] bcache: fix for gc and write-back race Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-09-24 22:40 +0200
    [PATCH 3.18 39/42] bcache: Correct return value for sysfs attach errors Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-09-24 22:40 +0200
    [PATCH 3.18 41/42] bcache: fix bch_hprint crash and improve output Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-09-24 22:40 +0200
    [PATCH 3.18 33/42] PCI: shpchp: Enable bridge bus mastering if MSI is enabled Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-09-24 22:40 +0200
    [PATCH 3.18 06/42] ipv6: fix typo in fib6_net_exit() Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-09-24 22:40 +0200
    [PATCH 3.18 31/42] tracing: Apply trace_clock changes to instance max buffer Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-09-24 22:40 +0200
    [PATCH 3.18 38/42] bcache: correct cache_dirty_target in __update_writeback_rate() Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-09-24 22:40 +0200
    [PATCH 3.18 32/42] ARC: Re-enable MMU upon Machine Check exception Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-09-24 22:40 +0200
    [PATCH 3.18 28/42] scsi: sg: fixup infoleak when using SG_GET_REQUEST_TABLE Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-09-24 22:40 +0200
    [PATCH 3.18 34/42] media: v4l2-compat-ioctl32: Fix timespec conversion Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-09-24 22:40 +0200
    [PATCH 3.18 04/42] tcp: initialize rcv_mss to TCP_MIN_MSS instead of 0 Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-09-24 22:40 +0200
    [PATCH 3.18 35/42] media: uvcvideo: Prevent heap overflow when accessing mapped controls Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-09-24 22:40 +0200
    [PATCH 3.18 24/42] scsi: sg: remove save_scat_len Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-09-24 23:40 +0200
    [PATCH 3.18 14/42] block: Relax a check in blk_start_queue() Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-09-24 23:40 +0200
    [PATCH 3.18 18/42] scsi: zfcp: fix queuecommand for scsi_eh commands when DIX enabled Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-09-24 23:40 +0200
    [PATCH 3.18 22/42] scsi: zfcp: trace HBA FSF response by default on dismiss or timedout late response Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-09-24 23:40 +0200
    [PATCH 3.18 26/42] scsi: sg: off by one in sg_ioctl() Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-09-24 23:40 +0200
    [PATCH 3.18 23/42] scsi: zfcp: trace high part of "new" 64 bit SCSI LUN Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-09-24 23:40 +0200
    [PATCH 3.18 02/42] qlge: avoid memcpy buffer overflow Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-09-24 23:40 +0200
    [PATCH 3.18 13/42] powerpc: Fix DAR reporting when alignment handler faults Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-09-24 23:40 +0200
    Re: [PATCH 3.18 00/42] 3.18.72-stable review Guenter Roeck <linux@roeck-us.net> - 2017-09-25 03:10 +0200
      Re: [PATCH 3.18 00/42] 3.18.72-stable review Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-09-25 08:40 +0200
        Re: [PATCH 3.18 00/42] 3.18.72-stable review Guenter Roeck <linux@roeck-us.net> - 2017-09-25 13:10 +0200
          Re: [PATCH 3.18 00/42] 3.18.72-stable review Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-09-25 14:30 +0200
    Re: [PATCH 3.18 00/42] 3.18.72-stable review Shuah Khan <shuahkh@osg.samsung.com> - 2017-09-26 01:20 +0200

Page 2 of 3 — ← Prev page 1 [2] 3 Next page →

#1738327 — [PATCH 3.18 06/42] ipv6: fix typo in fib6_net_exit()

From	Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date	2017-09-24 22:40 +0200
Subject	[PATCH 3.18 06/42] ipv6: fix typo in fib6_net_exit()
Message-ID	<utlR2-4Ti-79@gated-at.bofh.it>
In reply to	#1738280

3.18-stable review patch.  If anyone has any objections, please let me know.

------------------

From: Eric Dumazet <edumazet@google.com>


[ Upstream commit 32a805baf0fb70b6dbedefcd7249ac7f580f9e3b ]

IPv6 FIB should use FIB6_TABLE_HASHSZ, not FIB_TABLE_HASHSZ.

Fixes: ba1cc08d9488 ("ipv6: fix memory leak with multiple tables during netns destruction")
Signed-off-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
 net/ipv6/ip6_fib.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/net/ipv6/ip6_fib.c
+++ b/net/ipv6/ip6_fib.c
@@ -1793,7 +1793,7 @@ static void fib6_net_exit(struct net *ne
 	rt6_ifdown(net, NULL);
 	del_timer_sync(&net->ipv6.ip6_fib_timer);
 
-	for (i = 0; i < FIB_TABLE_HASHSZ; i++) {
+	for (i = 0; i < FIB6_TABLE_HASHSZ; i++) {
 		struct hlist_head *head = &net->ipv6.fib_table_hash[i];
 		struct hlist_node *tmp;
 		struct fib6_table *tb;

[toc] | [prev] | [next] | [standalone]

#1738329 — [PATCH 3.18 31/42] tracing: Apply trace_clock changes to instance max buffer

From	Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date	2017-09-24 22:40 +0200
Subject	[PATCH 3.18 31/42] tracing: Apply trace_clock changes to instance max buffer
Message-ID	<utlR2-4Ti-83@gated-at.bofh.it>
In reply to	#1738280

3.18-stable review patch.  If anyone has any objections, please let me know.

------------------

From: Baohong Liu <baohong.liu@intel.com>

commit 170b3b1050e28d1ba0700e262f0899ffa4fccc52 upstream.

Currently trace_clock timestamps are applied to both regular and max
buffers only for global trace. For instance trace, trace_clock
timestamps are applied only to regular buffer. But, regular and max
buffers can be swapped, for example, following a snapshot. So, for
instance trace, bad timestamps can be seen following a snapshot.
Let's apply trace_clock timestamps to instance max buffer as well.

Link: http://lkml.kernel.org/r/ebdb168d0be042dcdf51f81e696b17fabe3609c1.1504642143.git.tom.zanussi@linux.intel.com

Fixes: 277ba0446 ("tracing: Add interface to allow multiple trace buffers")
Signed-off-by: Baohong Liu <baohong.liu@intel.com>
Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 kernel/trace/trace.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/kernel/trace/trace.c
+++ b/kernel/trace/trace.c
@@ -4966,7 +4966,7 @@ static int tracing_set_clock(struct trac
 	tracing_reset_online_cpus(&tr->trace_buffer);
 
 #ifdef CONFIG_TRACER_MAX_TRACE
-	if (tr->flags & TRACE_ARRAY_FL_GLOBAL && tr->max_buffer.buffer)
+	if (tr->max_buffer.buffer)
 		ring_buffer_set_clock(tr->max_buffer.buffer, trace_clocks[i].func);
 	tracing_reset_online_cpus(&tr->max_buffer);
 #endif

[toc] | [prev] | [next] | [standalone]

#1738330 — [PATCH 3.18 38/42] bcache: correct cache_dirty_target in __update_writeback_rate()

From	Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date	2017-09-24 22:40 +0200
Subject	[PATCH 3.18 38/42] bcache: correct cache_dirty_target in __update_writeback_rate()
Message-ID	<utlR2-4Ti-85@gated-at.bofh.it>
In reply to	#1738280

3.18-stable review patch.  If anyone has any objections, please let me know.

------------------

From: Tang Junhui <tang.junhui@zte.com.cn>

commit a8394090a9129b40f9d90dcb7f4a49d60c727ca6 upstream.

__update_write_rate() uses a Proportion-Differentiation Controller
algorithm to control writeback rate. A dirty target number is used in
this PD controller to control writeback rate. A larger target number
will make the writeback rate smaller, on the versus, a smaller target
number will make the writeback rate larger.

bcache uses the following steps to calculate the target number,
1) cache_sectors = all-buckets-of-cache-set * buckets-size
2) cache_dirty_target = cache_sectors * cached-device-writeback_percent
3) target = cache_dirty_target *
(sectors-of-cached-device/sectors-of-all-cached-devices-of-this-cache-set)

The calculation at step 1) for cache_sectors is incorrect, which does
not consider dirty blocks occupied by flash only volume.

A flash only volume can be took as a bcache device without cached
device. All data sectors allocated for it are persistent on cache device
and marked dirty, they are not touched by bcache writeback and garbage
collection code. So data blocks of flash only volume should be ignore
when calculating cache_sectors of cache set.

Current code does not subtract dirty sectors of flash only volume, which
results a larger target number from the above 3 steps. And in sequence
the cache device's writeback rate is smaller then a correct value,
writeback speed is slower on all cached devices.

This patch fixes the incorrect slower writeback rate by subtracting
dirty sectors of flash only volumes in __update_writeback_rate().

(Commit log composed by Coly Li to pass checkpatch.pl checking)

Signed-off-by: Tang Junhui <tang.junhui@zte.com.cn>
Reviewed-by: Coly Li <colyli@suse.de>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/md/bcache/writeback.c |    3 ++-
 drivers/md/bcache/writeback.h |   19 +++++++++++++++++++
 2 files changed, 21 insertions(+), 1 deletion(-)

--- a/drivers/md/bcache/writeback.c
+++ b/drivers/md/bcache/writeback.c
@@ -21,7 +21,8 @@
 static void __update_writeback_rate(struct cached_dev *dc)
 {
 	struct cache_set *c = dc->disk.c;
-	uint64_t cache_sectors = c->nbuckets * c->sb.bucket_size;
+	uint64_t cache_sectors = c->nbuckets * c->sb.bucket_size -
+				bcache_flash_devs_sectors_dirty(c);
 	uint64_t cache_dirty_target =
 		div_u64(cache_sectors * dc->writeback_percent, 100);
 
--- a/drivers/md/bcache/writeback.h
+++ b/drivers/md/bcache/writeback.h
@@ -14,6 +14,25 @@ static inline uint64_t bcache_dev_sector
 	return ret;
 }
 
+static inline uint64_t  bcache_flash_devs_sectors_dirty(struct cache_set *c)
+{
+	uint64_t i, ret = 0;
+
+	mutex_lock(&bch_register_lock);
+
+	for (i = 0; i < c->nr_uuids; i++) {
+		struct bcache_device *d = c->devices[i];
+
+		if (!d || !UUID_FLASH_ONLY(&c->uuids[i]))
+			continue;
+	   ret += bcache_dev_sectors_dirty(d);
+	}
+
+	mutex_unlock(&bch_register_lock);
+
+	return ret;
+}
+
 static inline unsigned offset_to_stripe(struct bcache_device *d,
 					uint64_t offset)
 {

[toc] | [prev] | [next] | [standalone]

#1738331 — [PATCH 3.18 32/42] ARC: Re-enable MMU upon Machine Check exception

From	Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date	2017-09-24 22:40 +0200
Subject	[PATCH 3.18 32/42] ARC: Re-enable MMU upon Machine Check exception
Message-ID	<utlR2-4Ti-89@gated-at.bofh.it>
In reply to	#1738280

3.18-stable review patch.  If anyone has any objections, please let me know.

------------------

From: Jose Abreu <Jose.Abreu@synopsys.com>

commit 1ee55a8f7f6b7ca4c0c59e0b4b4e3584a085c2d3 upstream.

I recently came upon a scenario where I would get a double fault
machine check exception tiriggered by a kernel module.
However the ensuing crash stacktrace (ksym lookup) was not working
correctly.

Turns out that machine check auto-disables MMU while modules are allocated
in kernel vaddr spapce.

This patch re-enables the MMU before start printing the stacktrace
making stacktracing of modules work upon a fatal exception.

Signed-off-by: Jose Abreu <joabreu@synopsys.com>
Reviewed-by: Alexey Brodkin <abrodkin@synopsys.com>
Signed-off-by: Vineet Gupta <vgupta@synopsys.com>
[vgupta: moved code into low level handler to avoid in 2 places]
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 arch/arc/kernel/entry.S |    6 ++++++
 arch/arc/mm/tlb.c       |    3 ---
 2 files changed, 6 insertions(+), 3 deletions(-)

--- a/arch/arc/kernel/entry.S
+++ b/arch/arc/kernel/entry.S
@@ -315,6 +315,12 @@ ENTRY(EV_MachineCheck)
 	lr  r0, [efa]
 	mov r1, sp
 
+	; hardware auto-disables MMU, re-enable it to allow kernel vaddr
+	; access for say stack unwinding of modules for crash dumps
+	lr	r3, [ARC_REG_PID]
+	or	r3, r3, MMU_ENABLE
+	sr	r3, [ARC_REG_PID]
+
 	lsr  	r3, r2, 8
 	bmsk 	r3, r3, 7
 	brne    r3, ECR_C_MCHK_DUP_TLB, 1f
--- a/arch/arc/mm/tlb.c
+++ b/arch/arc/mm/tlb.c
@@ -689,9 +689,6 @@ void do_tlb_overlap_fault(unsigned long
 
 	local_irq_save(flags);
 
-	/* re-enable the MMU */
-	write_aux_reg(ARC_REG_PID, MMU_ENABLE | read_aux_reg(ARC_REG_PID));
-
 	/* loop thru all sets of TLB */
 	for (set = 0; set < mmu->sets; set++) {

[toc] | [prev] | [next] | [standalone]

#1738336 — [PATCH 3.18 28/42] scsi: sg: fixup infoleak when using SG_GET_REQUEST_TABLE

From	Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date	2017-09-24 22:40 +0200
Subject	[PATCH 3.18 28/42] scsi: sg: fixup infoleak when using SG_GET_REQUEST_TABLE
Message-ID	<utlR3-4Ti-99@gated-at.bofh.it>
In reply to	#1738280

3.18-stable review patch.  If anyone has any objections, please let me know.

------------------

From: Hannes Reinecke <hare@suse.de>

commit 3e0097499839e0fe3af380410eababe5a47c4cf9 upstream.

When calling SG_GET_REQUEST_TABLE ioctl only a half-filled table is
returned; the remaining part will then contain stale kernel memory
information.  This patch zeroes out the entire table to avoid this
issue.

Signed-off-by: Hannes Reinecke <hare@suse.com>
Reviewed-by: Bart Van Assche <bart.vanassche@wdc.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/scsi/sg.c |    5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

--- a/drivers/scsi/sg.c
+++ b/drivers/scsi/sg.c
@@ -865,7 +865,6 @@ sg_fill_request_table(Sg_fd *sfp, sg_req
 	list_for_each_entry(srp, &sfp->rq_list, entry) {
 		if (val > SG_MAX_QUEUE)
 			break;
-		memset(&rinfo[val], 0, SZ_SG_REQ_INFO);
 		rinfo[val].req_state = srp->done + 1;
 		rinfo[val].problem =
 			srp->header.masked_status &
@@ -1082,8 +1081,8 @@ sg_ioctl(struct file *filp, unsigned int
 		else {
 			sg_req_info_t *rinfo;
 
-			rinfo = kmalloc(SZ_SG_REQ_INFO * SG_MAX_QUEUE,
-								GFP_KERNEL);
+			rinfo = kzalloc(SZ_SG_REQ_INFO * SG_MAX_QUEUE,
+					GFP_KERNEL);
 			if (!rinfo)
 				return -ENOMEM;
 			read_lock_irqsave(&sfp->rq_list_lock, iflags);

[toc] | [prev] | [next] | [standalone]

#1738340 — [PATCH 3.18 34/42] media: v4l2-compat-ioctl32: Fix timespec conversion

From	Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date	2017-09-24 22:40 +0200
Subject	[PATCH 3.18 34/42] media: v4l2-compat-ioctl32: Fix timespec conversion
Message-ID	<utlR3-4Ti-101@gated-at.bofh.it>
In reply to	#1738280

3.18-stable review patch.  If anyone has any objections, please let me know.

------------------

From: Daniel Mentz <danielmentz@google.com>

commit 9c7ba1d7634cef490b85bc64c4091ff004821bfd upstream.

Certain syscalls like recvmmsg support 64 bit timespec values for the
X32 ABI. The helper function compat_put_timespec converts a timespec
value to a 32 bit or 64 bit value depending on what ABI is used. The
v4l2 compat layer, however, is not designed to support 64 bit timespec
values and always uses 32 bit values. Hence, compat_put_timespec must
not be used.

Without this patch, user space will be provided with bad timestamp
values from the VIDIOC_DQEVENT ioctl. Also, fields of the struct
v4l2_event32 that come immediately after timestamp get overwritten,
namely the field named id.

Fixes: 81993e81a994 ("compat: Get rid of (get|put)_compat_time(val|spec)")
Cc: H. Peter Anvin <hpa@linux.intel.com>
Cc: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Cc: Tiffany Lin <tiffany.lin@mediatek.com>
Cc: Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com>
Cc: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Daniel Mentz <danielmentz@google.com>
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/media/v4l2-core/v4l2-compat-ioctl32.c |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

--- a/drivers/media/v4l2-core/v4l2-compat-ioctl32.c
+++ b/drivers/media/v4l2-core/v4l2-compat-ioctl32.c
@@ -747,7 +747,8 @@ static int put_v4l2_event32(struct v4l2_
 		copy_to_user(&up->u, &kp->u, sizeof(kp->u)) ||
 		put_user(kp->pending, &up->pending) ||
 		put_user(kp->sequence, &up->sequence) ||
-		compat_put_timespec(&kp->timestamp, &up->timestamp) ||
+		put_user(kp->timestamp.tv_sec, &up->timestamp.tv_sec) ||
+		put_user(kp->timestamp.tv_nsec, &up->timestamp.tv_nsec) ||
 		put_user(kp->id, &up->id) ||
 		copy_to_user(up->reserved, kp->reserved, 8 * sizeof(__u32)))
 			return -EFAULT;

[toc] | [prev] | [next] | [standalone]

#1738348 — [PATCH 3.18 04/42] tcp: initialize rcv_mss to TCP_MIN_MSS instead of 0

From	Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date	2017-09-24 22:40 +0200
Subject	[PATCH 3.18 04/42] tcp: initialize rcv_mss to TCP_MIN_MSS instead of 0
Message-ID	<utlR4-4Ti-123@gated-at.bofh.it>
In reply to	#1738280

3.18-stable review patch.  If anyone has any objections, please let me know.

------------------

From: Wei Wang <weiwan@google.com>


[ Upstream commit 499350a5a6e7512d9ed369ed63a4244b6536f4f8 ]

When tcp_disconnect() is called, inet_csk_delack_init() sets
icsk->icsk_ack.rcv_mss to 0.
This could potentially cause tcp_recvmsg() => tcp_cleanup_rbuf() =>
__tcp_select_window() call path to have division by 0 issue.
So this patch initializes rcv_mss to TCP_MIN_MSS instead of 0.

Reported-by: Andrey Konovalov  <andreyknvl@google.com>
Signed-off-by: Wei Wang <weiwan@google.com>
Signed-off-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: Neal Cardwell <ncardwell@google.com>
Signed-off-by: Yuchung Cheng <ycheng@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
 net/ipv4/tcp.c |    4 ++++
 1 file changed, 4 insertions(+)

--- a/net/ipv4/tcp.c
+++ b/net/ipv4/tcp.c
@@ -2265,6 +2265,10 @@ int tcp_disconnect(struct sock *sk, int
 	tcp_set_ca_state(sk, TCP_CA_Open);
 	tcp_clear_retrans(tp);
 	inet_csk_delack_init(sk);
+	/* Initialize rcv_mss to TCP_MIN_MSS to avoid division by 0
+	 * issue in __tcp_select_window()
+	 */
+	icsk->icsk_ack.rcv_mss = TCP_MIN_MSS;
 	tcp_init_send_head(sk);
 	memset(&tp->rx_opt, 0, sizeof(tp->rx_opt));
 	__sk_dst_reset(sk);

[toc] | [prev] | [next] | [standalone]

#1738358 — [PATCH 3.18 35/42] media: uvcvideo: Prevent heap overflow when accessing mapped controls

From	Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date	2017-09-24 22:40 +0200
Subject	[PATCH 3.18 35/42] media: uvcvideo: Prevent heap overflow when accessing mapped controls
Message-ID	<utlR4-4Ti-135@gated-at.bofh.it>
In reply to	#1738280

3.18-stable review patch.  If anyone has any objections, please let me know.

------------------

From: Guenter Roeck <linux@roeck-us.net>

commit 7e09f7d5c790278ab98e5f2c22307ebe8ad6e8ba upstream.

The size of uvc_control_mapping is user controlled leading to a
potential heap overflow in the uvc driver. This adds a check to verify
the user provided size fits within the bounds of the defined buffer
size.

Originally-from: Richard Simmons <rssimmo@amazon.com>

Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/media/usb/uvc/uvc_ctrl.c |    7 +++++++
 1 file changed, 7 insertions(+)

--- a/drivers/media/usb/uvc/uvc_ctrl.c
+++ b/drivers/media/usb/uvc/uvc_ctrl.c
@@ -2001,6 +2001,13 @@ int uvc_ctrl_add_mapping(struct uvc_vide
 		goto done;
 	}
 
+	/* Validate the user-provided bit-size and offset */
+	if (mapping->size > 32 ||
+	    mapping->offset + mapping->size > ctrl->info.size * 8) {
+		ret = -EINVAL;
+		goto done;
+	}
+
 	list_for_each_entry(map, &ctrl->info.mappings, list) {
 		if (mapping->id == map->id) {
 			uvc_trace(UVC_TRACE_CONTROL, "Can't add mapping '%s', "

[toc] | [prev] | [next] | [standalone]

#1738560 — [PATCH 3.18 24/42] scsi: sg: remove save_scat_len

From	Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date	2017-09-24 23:40 +0200
Subject	[PATCH 3.18 24/42] scsi: sg: remove save_scat_len
Message-ID	<utmN4-5vy-5@gated-at.bofh.it>
In reply to	#1738280

3.18-stable review patch.  If anyone has any objections, please let me know.

------------------

From: Hannes Reinecke <hare@suse.de>

commit 136e57bf43dc4babbfb8783abbf707d483cacbe3 upstream.

Unused.

Signed-off-by: Hannes Reinecke <hare@suse.com>
Reviewed-by: Johannes Thumshirn <jthumshirn@suse.de>
Tested-by: Johannes Thumshirn <jthumshirn@suse.de>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/scsi/sg.c |    2 --
 1 file changed, 2 deletions(-)

--- a/drivers/scsi/sg.c
+++ b/drivers/scsi/sg.c
@@ -157,7 +157,6 @@ typedef struct sg_fd {		/* holds the sta
 	int timeout;		/* defaults to SG_DEFAULT_TIMEOUT      */
 	int timeout_user;	/* defaults to SG_DEFAULT_TIMEOUT_USER */
 	Sg_scatter_hold reserve;	/* buffer held for this file descriptor */
-	unsigned save_scat_len;	/* original length of trunc. scat. element */
 	Sg_request *headrp;	/* head of request slist, NULL->empty */
 	struct fasync_struct *async_qp;	/* used by asynchronous notification */
 	Sg_request req_arr[SG_MAX_QUEUE];	/* used as singly-linked list */
@@ -2105,7 +2104,6 @@ sg_unlink_reserve(Sg_fd * sfp, Sg_reques
 	req_schp->pages = NULL;
 	req_schp->page_order = 0;
 	req_schp->sglist_len = 0;
-	sfp->save_scat_len = 0;
 	srp->res_used = 0;
 	/* Called without mutex lock to avoid deadlock */
 	sfp->res_in_use = 0;

[toc] | [prev] | [next] | [standalone]

#1738561 — [PATCH 3.18 14/42] block: Relax a check in blk_start_queue()

From	Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date	2017-09-24 23:40 +0200
Subject	[PATCH 3.18 14/42] block: Relax a check in blk_start_queue()
Message-ID	<utmN4-5vy-7@gated-at.bofh.it>
In reply to	#1738280

3.18-stable review patch.  If anyone has any objections, please let me know.

------------------

From: Bart Van Assche <bart.vanassche@wdc.com>

commit 4ddd56b003f251091a67c15ae3fe4a5c5c5e390a upstream.

Calling blk_start_queue() from interrupt context with the queue
lock held and without disabling IRQs, as the skd driver does, is
safe. This patch avoids that loading the skd driver triggers the
following warning:

WARNING: CPU: 11 PID: 1348 at block/blk-core.c:283 blk_start_queue+0x84/0xa0
RIP: 0010:blk_start_queue+0x84/0xa0
Call Trace:
 skd_unquiesce_dev+0x12a/0x1d0 [skd]
 skd_complete_internal+0x1e7/0x5a0 [skd]
 skd_complete_other+0xc2/0xd0 [skd]
 skd_isr_completion_posted.isra.30+0x2a5/0x470 [skd]
 skd_isr+0x14f/0x180 [skd]
 irq_forced_thread_fn+0x2a/0x70
 irq_thread+0x144/0x1a0
 kthread+0x125/0x140
 ret_from_fork+0x2a/0x40

Fixes: commit a038e2536472 ("[PATCH] blk_start_queue() must be called with irq disabled - add warning")
Signed-off-by: Bart Van Assche <bart.vanassche@wdc.com>
Cc: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it>
Cc: Andrew Morton <akpm@osdl.org>
Cc: Christoph Hellwig <hch@lst.de>
Cc: Hannes Reinecke <hare@suse.de>
Cc: Johannes Thumshirn <jthumshirn@suse.de>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 block/blk-core.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/block/blk-core.c
+++ b/block/blk-core.c
@@ -194,7 +194,7 @@ EXPORT_SYMBOL(blk_delay_queue);
  **/
 void blk_start_queue(struct request_queue *q)
 {
-	WARN_ON(!irqs_disabled());
+	WARN_ON(!in_interrupt() && !irqs_disabled());
 
 	queue_flag_clear(QUEUE_FLAG_STOPPED, q);
 	__blk_run_queue(q);

[toc] | [prev] | [next] | [standalone]

#1738562 — [PATCH 3.18 18/42] scsi: zfcp: fix queuecommand for scsi_eh commands when DIX enabled

From	Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date	2017-09-24 23:40 +0200
Subject	[PATCH 3.18 18/42] scsi: zfcp: fix queuecommand for scsi_eh commands when DIX enabled
Message-ID	<utmN4-5vy-9@gated-at.bofh.it>
In reply to	#1738280

3.18-stable review patch.  If anyone has any objections, please let me know.

------------------

From: Steffen Maier <maier@linux.vnet.ibm.com>

commit 71b8e45da51a7b64a23378221c0a5868bd79da4f upstream.

Since commit db007fc5e20c ("[SCSI] Command protection operation"),
scsi_eh_prep_cmnd() saves scmd->prot_op and temporarily resets it to
SCSI_PROT_NORMAL.
Other FCP LLDDs such as qla2xxx and lpfc shield their queuecommand()
to only access any of scsi_prot_sg...() if
(scsi_get_prot_op(cmd) != SCSI_PROT_NORMAL).

Do the same thing for zfcp, which introduced DIX support with
commit ef3eb71d8ba4 ("[SCSI] zfcp: Introduce experimental support for
DIF/DIX").

Otherwise, TUR SCSI commands as part of scsi_eh likely fail in zfcp,
because the regular SCSI command with DIX protection data, that scsi_eh
re-uses in scsi_send_eh_cmnd(), of course still has
(scsi_prot_sg_count() != 0) and so zfcp sends down bogus requests to the
FCP channel hardware.

This causes scsi_eh_test_devices() to have (finish_cmds == 0)
[not SCSI device is online or not scsi_eh_tur() failed]
so regular SCSI commands, that caused / were affected by scsi_eh,
are moved to work_q and scsi_eh_test_devices() itself returns false.
In turn, it unnecessarily escalates in our case in scsi_eh_ready_devs()
beyond host reset to finally scsi_eh_offline_sdevs()
which sets affected SCSI devices offline with the following kernel message:

"kernel: sd H:0:T:L: Device offlined - not ready after error recovery"

Signed-off-by: Steffen Maier <maier@linux.vnet.ibm.com>
Fixes: ef3eb71d8ba4 ("[SCSI] zfcp: Introduce experimental support for DIF/DIX")
Reviewed-by: Benjamin Block <bblock@linux.vnet.ibm.com>
Signed-off-by: Benjamin Block <bblock@linux.vnet.ibm.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/s390/scsi/zfcp_fsf.c |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

--- a/drivers/s390/scsi/zfcp_fsf.c
+++ b/drivers/s390/scsi/zfcp_fsf.c
@@ -2247,7 +2247,8 @@ int zfcp_fsf_fcp_cmnd(struct scsi_cmnd *
 	fcp_cmnd = (struct fcp_cmnd *) &req->qtcb->bottom.io.fcp_cmnd;
 	zfcp_fc_scsi_to_fcp(fcp_cmnd, scsi_cmnd, 0);
 
-	if (scsi_prot_sg_count(scsi_cmnd)) {
+	if ((scsi_get_prot_op(scsi_cmnd) != SCSI_PROT_NORMAL) &&
+	    scsi_prot_sg_count(scsi_cmnd)) {
 		zfcp_qdio_set_data_div(qdio, &req->qdio_req,
 				       scsi_prot_sg_count(scsi_cmnd));
 		retval = zfcp_qdio_sbals_from_sg(qdio, &req->qdio_req,

[toc] | [prev] | [next] | [standalone]

#1738567 — [PATCH 3.18 22/42] scsi: zfcp: trace HBA FSF response by default on dismiss or timedout late response

From	Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date	2017-09-24 23:40 +0200
Subject	[PATCH 3.18 22/42] scsi: zfcp: trace HBA FSF response by default on dismiss or timedout late response
Message-ID	<utmN4-5vy-19@gated-at.bofh.it>
In reply to	#1738280

3.18-stable review patch.  If anyone has any objections, please let me know.

------------------

From: Steffen Maier <maier@linux.vnet.ibm.com>

commit fdb7cee3b9e3c561502e58137a837341f10cbf8b upstream.

At the default trace level, we only trace unsuccessful events including
FSF responses.

zfcp_dbf_hba_fsf_response() only used protocol status and FSF status to
decide on an unsuccessful response. However, this is only one of multiple
possible sources determining a failed struct zfcp_fsf_req.

An FSF request can also "fail" if its response runs into an ERP timeout
or if it gets dismissed because a higher level recovery was triggered
[trace tags "erscf_1" or "erscf_2" in zfcp_erp_strategy_check_fsfreq()].
FSF requests with ERP timeout are:
FSF_QTCB_EXCHANGE_CONFIG_DATA, FSF_QTCB_EXCHANGE_PORT_DATA,
FSF_QTCB_OPEN_PORT_WITH_DID or FSF_QTCB_CLOSE_PORT or
FSF_QTCB_CLOSE_PHYSICAL_PORT for target ports,
FSF_QTCB_OPEN_LUN, FSF_QTCB_CLOSE_LUN.
One example is slow queue processing which can cause follow-on errors,
e.g. FSF_PORT_ALREADY_OPEN after FSF_QTCB_OPEN_PORT_WITH_DID timed out.
In order to see the root cause, we need to see late responses even if the
channel presented them successfully with FSF_PROT_GOOD and FSF_GOOD.
Example trace records formatted with zfcpdbf from the s390-tools package:

Timestamp      : ...
Area           : REC
Subarea        : 00
Level          : 1
Exception      : -
CPU ID         : ..
Caller         : ...
Record ID      : 1
Tag            : fcegpf1
LUN            : 0xffffffffffffffff
WWPN           : 0x<WWPN>
D_ID           : 0x00<D_ID>
Adapter status : 0x5400050b
Port status    : 0x41200000
LUN status     : 0x00000000
Ready count    : 0x00000001
Running count  : 0x...
ERP want       : 0x02				ZFCP_ERP_ACTION_REOPEN_PORT
ERP need       : 0x02				ZFCP_ERP_ACTION_REOPEN_PORT
|
Timestamp      : ...				30 seconds later
Area           : REC
Subarea        : 00
Level          : 1
Exception      : -
CPU ID         : ..
Caller         : ...
Record ID      : 2
Tag            : erscf_2
LUN            : 0xffffffffffffffff
WWPN           : 0x<WWPN>
D_ID           : 0x00<D_ID>
Adapter status : 0x5400050b
Port status    : 0x41200000
LUN status     : 0x00000000
Request ID     : 0x<request_ID>
ERP status     : 0x10000000			ZFCP_STATUS_ERP_TIMEDOUT
ERP step       : 0x0800				ZFCP_ERP_STEP_PORT_OPENING
ERP action     : 0x02				ZFCP_ERP_ACTION_REOPEN_PORT
ERP count      : 0x00
|
Timestamp      : ...				later than previous record
Area           : HBA
Subarea        : 00
Level          : 5	> default level		=> 3	<= default level
Exception      : -
CPU ID         : 00
Caller         : ...
Record ID      : 1
Tag            : fs_qtcb			=> fs_rerr
Request ID     : 0x<request_ID>
Request status : 0x00001010			ZFCP_STATUS_FSFREQ_DISMISSED
						| ZFCP_STATUS_FSFREQ_CLEANUP
FSF cmnd       : 0x00000005
FSF sequence no: 0x...
FSF issued     : ...				> 30 seconds ago
FSF stat       : 0x00000000			FSF_GOOD
FSF stat qual  : 00000000 00000000 00000000 00000000
Prot stat      : 0x00000001			FSF_PROT_GOOD
Prot stat qual : 00000000 00000000 00000000 00000000
Port handle    : 0x...
LUN handle     : 0x00000000
QTCB log length: ...
QTCB log info  : ...

In case of problems detecting that new responses are waiting on the input
queue, we sooner or later trigger adapter recovery due to an FSF request
timeout (trace tag "fsrth_1").
FSF requests with FSF request timeout are:
typically FSF_QTCB_ABORT_FCP_CMND; but theoretically also
FSF_QTCB_EXCHANGE_CONFIG_DATA or FSF_QTCB_EXCHANGE_PORT_DATA via sysfs,
FSF_QTCB_OPEN_PORT_WITH_DID or FSF_QTCB_CLOSE_PORT for WKA ports,
FSF_QTCB_FCP_CMND for task management function (LUN / target reset).
One or more pending requests can meanwhile have FSF_PROT_GOOD and FSF_GOOD
because the channel filled in the response via DMA into the request's QTCB.

In a theroretical case, inject code can create an erroneous FSF request
on purpose. If data router is enabled, it uses deferred error reporting.
A READ SCSI command can succeed with FSF_PROT_GOOD, FSF_GOOD, and
SAM_STAT_GOOD. But on writing the read data to host memory via DMA,
it can still fail, e.g. if an intentionally wrong scatter list does not
provide enough space. Rather than getting an unsuccessful response,
we get a QDIO activate check which in turn triggers adapter recovery.
One or more pending requests can meanwhile have FSF_PROT_GOOD and FSF_GOOD
because the channel filled in the response via DMA into the request's QTCB.
Example trace records formatted with zfcpdbf from the s390-tools package:

Timestamp      : ...
Area           : HBA
Subarea        : 00
Level          : 6	> default level		=> 3	<= default level
Exception      : -
CPU ID         : ..
Caller         : ...
Record ID      : 1
Tag            : fs_norm			=> fs_rerr
Request ID     : 0x<request_ID2>
Request status : 0x00001010			ZFCP_STATUS_FSFREQ_DISMISSED
						| ZFCP_STATUS_FSFREQ_CLEANUP
FSF cmnd       : 0x00000001
FSF sequence no: 0x...
FSF issued     : ...
FSF stat       : 0x00000000			FSF_GOOD
FSF stat qual  : 00000000 00000000 00000000 00000000
Prot stat      : 0x00000001			FSF_PROT_GOOD
Prot stat qual : ........ ........ 00000000 00000000
Port handle    : 0x...
LUN handle     : 0x...
|
Timestamp      : ...
Area           : SCSI
Subarea        : 00
Level          : 3
Exception      : -
CPU ID         : ..
Caller         : ...
Record ID      : 1
Tag            : rsl_err
Request ID     : 0x<request_ID2>
SCSI ID        : 0x...
SCSI LUN       : 0x...
SCSI result    : 0x000e0000			DID_TRANSPORT_DISRUPTED
SCSI retries   : 0x00
SCSI allowed   : 0x05
SCSI scribble  : 0x<request_ID2>
SCSI opcode    : 28...				Read(10)
FCP rsp inf cod: 0x00
FCP rsp IU     : 00000000 00000000 00000000 00000000
                                         ^^	SAM_STAT_GOOD
                 00000000 00000000

Only with luck in both above cases, we could see a follow-on trace record
of an unsuccesful event following a successful but late FSF response with
FSF_PROT_GOOD and FSF_GOOD. Typically this was the case for I/O requests
resulting in a SCSI trace record "rsl_err" with DID_TRANSPORT_DISRUPTED
[On ZFCP_STATUS_FSFREQ_DISMISSED, zfcp_fsf_protstatus_eval() sets
ZFCP_STATUS_FSFREQ_ERROR seen by the request handler functions as failure].
However, the reason for this follow-on trace was invisible because the
corresponding HBA trace record was missing at the default trace level
(by default hidden records with tags "fs_norm", "fs_qtcb", or "fs_open").

On adapter recovery, after we had shut down the QDIO queues, we perform
unsuccessful pseudo completions with flag ZFCP_STATUS_FSFREQ_DISMISSED
for each pending FSF request in zfcp_fsf_req_dismiss_all().
In order to find the root cause, we need to see all pseudo responses even
if the channel presented them successfully with FSF_PROT_GOOD and FSF_GOOD.

Therefore, check zfcp_fsf_req.status for ZFCP_STATUS_FSFREQ_DISMISSED
or ZFCP_STATUS_FSFREQ_ERROR and trace with a new tag "fs_rerr".

It does not matter that there are numerous places which set
ZFCP_STATUS_FSFREQ_ERROR after the location where we trace an FSF response
early. These cases are based on protocol status != FSF_PROT_GOOD or
== FSF_PROT_FSF_STATUS_PRESENTED and are thus already traced by default
as trace tag "fs_perr" or "fs_ferr" respectively.

NB: The trace record with tag "fssrh_1" for status read buffers on dismiss
all remains. zfcp_fsf_req_complete() handles this and returns early.
All other FSF request types are handled separately and as described above.

Signed-off-by: Steffen Maier <maier@linux.vnet.ibm.com>
Fixes: 8a36e4532ea1 ("[SCSI] zfcp: enhancement of zfcp debug features")
Fixes: 2e261af84cdb ("[SCSI] zfcp: Only collect FSF/HBA debug data for matching trace levels")
Reviewed-by: Benjamin Block <bblock@linux.vnet.ibm.com>
Signed-off-by: Benjamin Block <bblock@linux.vnet.ibm.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/s390/scsi/zfcp_dbf.h |    6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

--- a/drivers/s390/scsi/zfcp_dbf.h
+++ b/drivers/s390/scsi/zfcp_dbf.h
@@ -291,7 +291,11 @@ void zfcp_dbf_hba_fsf_response(struct zf
 {
 	struct fsf_qtcb *qtcb = req->qtcb;
 
-	if ((qtcb->prefix.prot_status != FSF_PROT_GOOD) &&
+	if (unlikely(req->status & (ZFCP_STATUS_FSFREQ_DISMISSED |
+				    ZFCP_STATUS_FSFREQ_ERROR))) {
+		zfcp_dbf_hba_fsf_resp("fs_rerr", 3, req);
+
+	} else if ((qtcb->prefix.prot_status != FSF_PROT_GOOD) &&
 	    (qtcb->prefix.prot_status != FSF_PROT_FSF_STATUS_PRESENTED)) {
 		zfcp_dbf_hba_fsf_resp("fs_perr", 1, req);

[toc] | [prev] | [next] | [standalone]

#1738568 — [PATCH 3.18 26/42] scsi: sg: off by one in sg_ioctl()

From	Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date	2017-09-24 23:40 +0200
Subject	[PATCH 3.18 26/42] scsi: sg: off by one in sg_ioctl()
Message-ID	<utmN4-5vy-23@gated-at.bofh.it>
In reply to	#1738280

3.18-stable review patch.  If anyone has any objections, please let me know.

------------------

From: Dan Carpenter <dan.carpenter@oracle.com>

commit bd46fc406b30d1db1aff8dabaff8d18bb423fdcf upstream.

If "val" is SG_MAX_QUEUE then we are one element beyond the end of the
"rinfo" array so the > should be >=.

Fixes: 109bade9c625 ("scsi: sg: use standard lists for sg_requests")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Acked-by: Douglas Gilbert <dgilbert@interlog.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/scsi/sg.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/scsi/sg.c
+++ b/drivers/scsi/sg.c
@@ -1056,7 +1056,7 @@ sg_ioctl(struct file *filp, unsigned int
 			read_lock_irqsave(&sfp->rq_list_lock, iflags);
 			val = 0;
 			list_for_each_entry(srp, &sfp->rq_list, entry) {
-				if (val > SG_MAX_QUEUE)
+				if (val >= SG_MAX_QUEUE)
 					break;
 				memset(&rinfo[val], 0, SZ_SG_REQ_INFO);
 				rinfo[val].req_state = srp->done + 1;

[toc] | [prev] | [next] | [standalone]

#1738569 — [PATCH 3.18 23/42] scsi: zfcp: trace high part of "new" 64 bit SCSI LUN

From	Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date	2017-09-24 23:40 +0200
Subject	[PATCH 3.18 23/42] scsi: zfcp: trace high part of "new" 64 bit SCSI LUN
Message-ID	<utmN5-5vy-33@gated-at.bofh.it>
In reply to	#1738280

3.18-stable review patch.  If anyone has any objections, please let me know.

------------------

From: Steffen Maier <maier@linux.vnet.ibm.com>

commit 5d4a3d0a2ff23799b956e5962b886287614e7fad upstream.

Complements debugging aspects of the otherwise functionally complete
v3.17 commit 9cb78c16f5da ("scsi: use 64-bit LUNs").

While I don't have access to a target exporting 3 or 4 level LUNs,
I did test it by explicitly attaching a non-existent fake 4 level LUN
by means of zfcp sysfs attribute "unit_add".
In order to see corresponding trace records of otherwise successful
events, we had to increase the trace level of area SCSI and HBA to 6.

$ echo 6 > /sys/kernel/debug/s390dbf/zfcp_0.0.1880_scsi/level
$ echo 6 > /sys/kernel/debug/s390dbf/zfcp_0.0.1880_hba/level

$ echo 0x4011402240334044 > \
  /sys/bus/ccw/drivers/zfcp/0.0.1880/0x50050763031bd327/unit_add

Example output formatted by an updated zfcpdbf from the s390-tools
package interspersed with kernel messages at scsi_logging_level=4605:

Timestamp      : ...
Area           : REC
Subarea        : 00
Level          : 1
Exception      : -
CPU ID         : ..
Caller         : 0x...
Record ID      : 1
Tag            : scsla_1
LUN            : 0x4011402240334044
WWPN           : 0x50050763031bd327
D_ID           : 0x00......
Adapter status : 0x5400050b
Port status    : 0x54000001
LUN status     : 0x41000000
Ready count    : 0x00000001
Running count  : 0x00000000
ERP want       : 0x01
ERP need       : 0x01

scsi 2:0:0:4630896905707208721: scsi scan: INQUIRY pass 1 length 36
scsi 2:0:0:4630896905707208721: scsi scan: INQUIRY successful with code 0x0

Timestamp      : ...
Area           : HBA
Subarea        : 00
Level          : 6
Exception      : -
CPU ID         : ..
Caller         : 0x...
Record ID      : 1
Tag            : fs_norm
Request ID     : 0x<inquiry2-req-id>
Request status : 0x00000010
FSF cmnd       : 0x00000001
FSF sequence no: 0x...
FSF issued     : ...
FSF stat       : 0x00000000
FSF stat qual  : 00000000 00000000 00000000 00000000
Prot stat      : 0x00000001
Prot stat qual : ........ ........ 00000000 00000000
Port handle    : 0x...
LUN handle     : 0x...
|
Timestamp      : ...
Area           : SCSI
Subarea        : 00
Level          : 6
Exception      : -
CPU ID         : ..
Caller         : 0x...
Record ID      : 1
Tag            : rsl_nor
Request ID     : 0x<inquiry2-req-id>
SCSI ID        : 0x00000000
SCSI LUN       : 0x40224011
SCSI LUN high  : 0x40444033 <=======================
SCSI result    : 0x00000000
SCSI retries   : 0x00
SCSI allowed   : 0x03
SCSI scribble  : 0x<inquiry2-req-id>
SCSI opcode    : 12000000 a4000000 00000000 00000000
FCP rsp inf cod: 0x00
FCP rsp IU     : 00000000 00000000 00000000 00000000
                 00000000 00000000

scsi 2:0:0:4630896905707208721: scsi scan: INQUIRY pass 2 length 164
scsi 2:0:0:4630896905707208721: scsi scan: INQUIRY successful with code 0x0
scsi 2:0:0:4630896905707208721: scsi scan: peripheral device type of 31, \
no device added

Signed-off-by: Steffen Maier <maier@linux.vnet.ibm.com>
Fixes: 9cb78c16f5da ("scsi: use 64-bit LUNs")
Reviewed-by: Benjamin Block <bblock@linux.vnet.ibm.com>
Reviewed-by: Jens Remus <jremus@linux.vnet.ibm.com>
Signed-off-by: Benjamin Block <bblock@linux.vnet.ibm.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/s390/scsi/zfcp_dbf.c |    2 +-
 drivers/s390/scsi/zfcp_dbf.h |    4 +++-
 2 files changed, 4 insertions(+), 2 deletions(-)

--- a/drivers/s390/scsi/zfcp_dbf.c
+++ b/drivers/s390/scsi/zfcp_dbf.c
@@ -418,8 +418,8 @@ void zfcp_dbf_scsi(char *tag, struct scs
 	rec->scsi_retries = sc->retries;
 	rec->scsi_allowed = sc->allowed;
 	rec->scsi_id = sc->device->id;
-	/* struct zfcp_dbf_scsi needs to be updated to handle 64bit LUNs */
 	rec->scsi_lun = (u32)sc->device->lun;
+	rec->scsi_lun_64_hi = (u32)(sc->device->lun >> 32);
 	rec->host_scribble = (unsigned long)sc->host_scribble;
 
 	memcpy(rec->scsi_opcode, sc->cmnd,
--- a/drivers/s390/scsi/zfcp_dbf.h
+++ b/drivers/s390/scsi/zfcp_dbf.h
@@ -196,7 +196,7 @@ enum zfcp_dbf_scsi_id {
  * @id: unique number of recovery record type
  * @tag: identifier string specifying the location of initiation
  * @scsi_id: scsi device id
- * @scsi_lun: scsi device logical unit number
+ * @scsi_lun: scsi device logical unit number, low part of 64 bit, old 32 bit
  * @scsi_result: scsi result
  * @scsi_retries: current retry number of scsi request
  * @scsi_allowed: allowed retries
@@ -206,6 +206,7 @@ enum zfcp_dbf_scsi_id {
  * @host_scribble: LLD specific data attached to SCSI request
  * @pl_len: length of paload stored as zfcp_dbf_pay
  * @fsf_rsp: response for fsf request
+ * @scsi_lun_64_hi: scsi device logical unit number, high part of 64 bit
  */
 struct zfcp_dbf_scsi {
 	u8 id;
@@ -222,6 +223,7 @@ struct zfcp_dbf_scsi {
 	u64 host_scribble;
 	u16 pl_len;
 	struct fcp_resp_with_ext fcp_rsp;
+	u32 scsi_lun_64_hi;
 } __packed;
 
 /**

[toc] | [prev] | [next] | [standalone]

#1738570 — [PATCH 3.18 02/42] qlge: avoid memcpy buffer overflow

From	Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date	2017-09-24 23:40 +0200
Subject	[PATCH 3.18 02/42] qlge: avoid memcpy buffer overflow
Message-ID	<utmN5-5vy-39@gated-at.bofh.it>
In reply to	#1738280

3.18-stable review patch.  If anyone has any objections, please let me know.

------------------

From: Arnd Bergmann <arnd@arndb.de>


[ Upstream commit e58f95831e7468d25eb6e41f234842ecfe6f014f ]

gcc-8.0.0 (snapshot) points out that we copy a variable-length string
into a fixed length field using memcpy() with the destination length,
and that ends up copying whatever follows the string:

    inlined from 'ql_core_dump' at drivers/net/ethernet/qlogic/qlge/qlge_dbg.c:1106:2:
drivers/net/ethernet/qlogic/qlge/qlge_dbg.c:708:2: error: 'memcpy' reading 15 bytes from a region of size 14 [-Werror=stringop-overflow=]
  memcpy(seg_hdr->description, desc, (sizeof(seg_hdr->description)) - 1);

Changing it to use strncpy() will instead zero-pad the destination,
which seems to be the right thing to do here.

The bug is probably harmless, but it seems like a good idea to address
it in stable kernels as well, if only for the purpose of building with
gcc-8 without warnings.

Fixes: a61f80261306 ("qlge: Add ethtool register dump function.")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
 drivers/net/ethernet/qlogic/qlge/qlge_dbg.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/net/ethernet/qlogic/qlge/qlge_dbg.c
+++ b/drivers/net/ethernet/qlogic/qlge/qlge_dbg.c
@@ -724,7 +724,7 @@ static void ql_build_coredump_seg_header
 	seg_hdr->cookie = MPI_COREDUMP_COOKIE;
 	seg_hdr->segNum = seg_number;
 	seg_hdr->segSize = seg_size;
-	memcpy(seg_hdr->description, desc, (sizeof(seg_hdr->description)) - 1);
+	strncpy(seg_hdr->description, desc, (sizeof(seg_hdr->description)) - 1);
 }
 
 /*

[toc] | [prev] | [next] | [standalone]

#1738573 — [PATCH 3.18 13/42] powerpc: Fix DAR reporting when alignment handler faults

From	Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date	2017-09-24 23:40 +0200
Subject	[PATCH 3.18 13/42] powerpc: Fix DAR reporting when alignment handler faults
Message-ID	<utmN5-5vy-31@gated-at.bofh.it>
In reply to	#1738280

3.18-stable review patch.  If anyone has any objections, please let me know.

------------------

From: Michael Ellerman <mpe@ellerman.id.au>

commit f9effe925039cf54489b5c04e0d40073bb3a123d upstream.

Anton noticed that if we fault part way through emulating an unaligned
instruction, we don't update the DAR to reflect that.

The DAR value is eventually reported back to userspace as the address
in the SEGV signal, and if userspace is using that value to demand
fault then it can be confused by us not setting the value correctly.

This patch is ugly as hell, but is intended to be the minimal fix and
back ports easily.

Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Reviewed-by: Paul Mackerras <paulus@ozlabs.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 arch/powerpc/kernel/align.c |  119 +++++++++++++++++++++++++++-----------------
 1 file changed, 74 insertions(+), 45 deletions(-)

--- a/arch/powerpc/kernel/align.c
+++ b/arch/powerpc/kernel/align.c
@@ -236,6 +236,28 @@ static int emulate_dcbz(struct pt_regs *
 
 #define SWIZ_PTR(p)		((unsigned char __user *)((p) ^ swiz))
 
+#define __get_user_or_set_dar(_regs, _dest, _addr)		\
+	({							\
+		int rc = 0;					\
+		typeof(_addr) __addr = (_addr);			\
+		if (__get_user_inatomic(_dest, __addr)) {	\
+			_regs->dar = (unsigned long)__addr;	\
+			rc = -EFAULT;				\
+		}						\
+		rc;						\
+	})
+
+#define __put_user_or_set_dar(_regs, _src, _addr)		\
+	({							\
+		int rc = 0;					\
+		typeof(_addr) __addr = (_addr);			\
+		if (__put_user_inatomic(_src, __addr)) {	\
+			_regs->dar = (unsigned long)__addr;	\
+			rc = -EFAULT;				\
+		}						\
+		rc;						\
+	})
+
 static int emulate_multiple(struct pt_regs *regs, unsigned char __user *addr,
 			    unsigned int reg, unsigned int nb,
 			    unsigned int flags, unsigned int instr,
@@ -264,9 +286,10 @@ static int emulate_multiple(struct pt_re
 		} else {
 			unsigned long pc = regs->nip ^ (swiz & 4);
 
-			if (__get_user_inatomic(instr,
-						(unsigned int __user *)pc))
+			if (__get_user_or_set_dar(regs, instr,
+						  (unsigned int __user *)pc))
 				return -EFAULT;
+
 			if (swiz == 0 && (flags & SW))
 				instr = cpu_to_le32(instr);
 			nb = (instr >> 11) & 0x1f;
@@ -310,31 +333,31 @@ static int emulate_multiple(struct pt_re
 			       ((nb0 + 3) / 4) * sizeof(unsigned long));
 
 		for (i = 0; i < nb; ++i, ++p)
-			if (__get_user_inatomic(REG_BYTE(rptr, i ^ bswiz),
-						SWIZ_PTR(p)))
+			if (__get_user_or_set_dar(regs, REG_BYTE(rptr, i ^ bswiz),
+						  SWIZ_PTR(p)))
 				return -EFAULT;
 		if (nb0 > 0) {
 			rptr = &regs->gpr[0];
 			addr += nb;
 			for (i = 0; i < nb0; ++i, ++p)
-				if (__get_user_inatomic(REG_BYTE(rptr,
-								 i ^ bswiz),
-							SWIZ_PTR(p)))
+				if (__get_user_or_set_dar(regs,
+							  REG_BYTE(rptr, i ^ bswiz),
+							  SWIZ_PTR(p)))
 					return -EFAULT;
 		}
 
 	} else {
 		for (i = 0; i < nb; ++i, ++p)
-			if (__put_user_inatomic(REG_BYTE(rptr, i ^ bswiz),
-						SWIZ_PTR(p)))
+			if (__put_user_or_set_dar(regs, REG_BYTE(rptr, i ^ bswiz),
+						  SWIZ_PTR(p)))
 				return -EFAULT;
 		if (nb0 > 0) {
 			rptr = &regs->gpr[0];
 			addr += nb;
 			for (i = 0; i < nb0; ++i, ++p)
-				if (__put_user_inatomic(REG_BYTE(rptr,
-								 i ^ bswiz),
-							SWIZ_PTR(p)))
+				if (__put_user_or_set_dar(regs,
+							  REG_BYTE(rptr, i ^ bswiz),
+							  SWIZ_PTR(p)))
 					return -EFAULT;
 		}
 	}
@@ -346,29 +369,32 @@ static int emulate_multiple(struct pt_re
  * Only POWER6 has these instructions, and it does true little-endian,
  * so we don't need the address swizzling.
  */
-static int emulate_fp_pair(unsigned char __user *addr, unsigned int reg,
-			   unsigned int flags)
+static int emulate_fp_pair(struct pt_regs *regs, unsigned char __user *addr,
+			   unsigned int reg, unsigned int flags)
 {
 	char *ptr0 = (char *) &current->thread.TS_FPR(reg);
 	char *ptr1 = (char *) &current->thread.TS_FPR(reg+1);
-	int i, ret, sw = 0;
+	int i, sw = 0;
 
 	if (reg & 1)
 		return 0;	/* invalid form: FRS/FRT must be even */
 	if (flags & SW)
 		sw = 7;
-	ret = 0;
+
 	for (i = 0; i < 8; ++i) {
 		if (!(flags & ST)) {
-			ret |= __get_user(ptr0[i^sw], addr + i);
-			ret |= __get_user(ptr1[i^sw], addr + i + 8);
+			if (__get_user_or_set_dar(regs, ptr0[i^sw], addr + i))
+				return -EFAULT;
+			if (__get_user_or_set_dar(regs, ptr1[i^sw], addr + i + 8))
+				return -EFAULT;
 		} else {
-			ret |= __put_user(ptr0[i^sw], addr + i);
-			ret |= __put_user(ptr1[i^sw], addr + i + 8);
+			if (__put_user_or_set_dar(regs, ptr0[i^sw], addr + i))
+				return -EFAULT;
+			if (__put_user_or_set_dar(regs, ptr1[i^sw], addr + i + 8))
+				return -EFAULT;
 		}
 	}
-	if (ret)
-		return -EFAULT;
+
 	return 1;	/* exception handled and fixed up */
 }
 
@@ -378,24 +404,27 @@ static int emulate_lq_stq(struct pt_regs
 {
 	char *ptr0 = (char *)&regs->gpr[reg];
 	char *ptr1 = (char *)&regs->gpr[reg+1];
-	int i, ret, sw = 0;
+	int i, sw = 0;
 
 	if (reg & 1)
 		return 0;	/* invalid form: GPR must be even */
 	if (flags & SW)
 		sw = 7;
-	ret = 0;
+
 	for (i = 0; i < 8; ++i) {
 		if (!(flags & ST)) {
-			ret |= __get_user(ptr0[i^sw], addr + i);
-			ret |= __get_user(ptr1[i^sw], addr + i + 8);
+			if (__get_user_or_set_dar(regs, ptr0[i^sw], addr + i))
+				return -EFAULT;
+			if (__get_user_or_set_dar(regs, ptr1[i^sw], addr + i + 8))
+				return -EFAULT;
 		} else {
-			ret |= __put_user(ptr0[i^sw], addr + i);
-			ret |= __put_user(ptr1[i^sw], addr + i + 8);
+			if (__put_user_or_set_dar(regs, ptr0[i^sw], addr + i))
+				return -EFAULT;
+			if (__put_user_or_set_dar(regs, ptr1[i^sw], addr + i + 8))
+				return -EFAULT;
 		}
 	}
-	if (ret)
-		return -EFAULT;
+
 	return 1;	/* exception handled and fixed up */
 }
 #endif /* CONFIG_PPC64 */
@@ -688,9 +717,14 @@ static int emulate_vsx(unsigned char __u
 	for (j = 0; j < length; j += elsize) {
 		for (i = 0; i < elsize; ++i) {
 			if (flags & ST)
-				ret |= __put_user(ptr[i^sw], addr + i);
+				ret = __put_user_or_set_dar(regs, ptr[i^sw],
+							    addr + i);
 			else
-				ret |= __get_user(ptr[i^sw], addr + i);
+				ret = __get_user_or_set_dar(regs, ptr[i^sw],
+							    addr + i);
+
+			if (ret)
+				return ret;
 		}
 		ptr  += elsize;
 #ifdef __LITTLE_ENDIAN__
@@ -740,7 +774,7 @@ int fix_alignment(struct pt_regs *regs)
 	unsigned int dsisr;
 	unsigned char __user *addr;
 	unsigned long p, swiz;
-	int ret, i;
+	int i;
 	union data {
 		u64 ll;
 		double dd;
@@ -923,7 +957,7 @@ int fix_alignment(struct pt_regs *regs)
 		if (flags & F) {
 			/* Special case for 16-byte FP loads and stores */
 			PPC_WARN_ALIGNMENT(fp_pair, regs);
-			return emulate_fp_pair(addr, reg, flags);
+			return emulate_fp_pair(regs, addr, reg, flags);
 		} else {
 #ifdef CONFIG_PPC64
 			/* Special case for 16-byte loads and stores */
@@ -953,15 +987,12 @@ int fix_alignment(struct pt_regs *regs)
 		}
 
 		data.ll = 0;
-		ret = 0;
 		p = (unsigned long)addr;
 
 		for (i = 0; i < nb; i++)
-			ret |= __get_user_inatomic(data.v[start + i],
-						   SWIZ_PTR(p++));
-
-		if (unlikely(ret))
-			return -EFAULT;
+			if (__get_user_or_set_dar(regs, data.v[start + i],
+						  SWIZ_PTR(p++)))
+				return -EFAULT;
 
 	} else if (flags & F) {
 		data.ll = current->thread.TS_FPR(reg);
@@ -1031,15 +1062,13 @@ int fix_alignment(struct pt_regs *regs)
 			break;
 		}
 
-		ret = 0;
 		p = (unsigned long)addr;
 
 		for (i = 0; i < nb; i++)
-			ret |= __put_user_inatomic(data.v[start + i],
-						   SWIZ_PTR(p++));
+			if (__put_user_or_set_dar(regs, data.v[start + i],
+						  SWIZ_PTR(p++)))
+				return -EFAULT;
 
-		if (unlikely(ret))
-			return -EFAULT;
 	} else if (flags & F)
 		current->thread.TS_FPR(reg) = data.ll;
 	else

[toc] | [prev] | [next] | [standalone]

#1738613

From	Guenter Roeck <linux@roeck-us.net>
Date	2017-09-25 03:10 +0200
Message-ID	<utq4h-7BV-1@gated-at.bofh.it>
In reply to	#1738280

On 09/24/2017 01:27 PM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 3.18.72 release.
> There are 42 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 Tue Sep 26 20:26:30 UTC 2017.
> Anything received after that time might be too late.
> 

Build results:
	total: 136 pass: 134 fail: 2
Failed builds:
	s390:defconfig
	s390:allmodconfig
Qemu test results:
	total: 112 pass: 111 fail: 1
Failed tests:
	s390:defconfig

Build failure:

Building s390:defconfig ... failed
------------
Error log:
drivers/s390/scsi/zfcp_scsi.c: In function 'zfcp_task_mgmt_function':
drivers/s390/scsi/zfcp_scsi.c:249:4: error: too many arguments to function 'zfcp_dbf_scsi_devreset'
drivers/s390/scsi/zfcp_dbf.h:376:6: note: declared here
drivers/s390/scsi/zfcp_scsi.c:260:3: error: too many arguments to function 'zfcp_dbf_scsi_devreset'
drivers/s390/scsi/zfcp_dbf.h:376:6: note: declared here
make[2]: *** [drivers/s390/scsi/zfcp_scsi.o] Error 1

Details are available at http://kerneltests.org/builders.

Guenter

[toc] | [prev] | [next] | [standalone]

#1738769

From	Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date	2017-09-25 08:40 +0200
Message-ID	<utvdE-2CX-17@gated-at.bofh.it>
In reply to	#1738613

On Sun, Sep 24, 2017 at 06:02:56PM -0700, Guenter Roeck wrote:
> On 09/24/2017 01:27 PM, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 3.18.72 release.
> > There are 42 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 Tue Sep 26 20:26:30 UTC 2017.
> > Anything received after that time might be too late.
> > 
> 
> Build results:
> 	total: 136 pass: 134 fail: 2
> Failed builds:
> 	s390:defconfig
> 	s390:allmodconfig
> Qemu test results:
> 	total: 112 pass: 111 fail: 1
> Failed tests:
> 	s390:defconfig
> 
> Build failure:
> 
> Building s390:defconfig ... failed
> ------------
> Error log:
> drivers/s390/scsi/zfcp_scsi.c: In function 'zfcp_task_mgmt_function':
> drivers/s390/scsi/zfcp_scsi.c:249:4: error: too many arguments to function 'zfcp_dbf_scsi_devreset'
> drivers/s390/scsi/zfcp_dbf.h:376:6: note: declared here
> drivers/s390/scsi/zfcp_scsi.c:260:3: error: too many arguments to function 'zfcp_dbf_scsi_devreset'
> drivers/s390/scsi/zfcp_dbf.h:376:6: note: declared here
> make[2]: *** [drivers/s390/scsi/zfcp_scsi.o] Error 1

Ah, thanks for letting me know about this, I have fixed it up now (hopefully.)

greg k-h

[toc] | [prev] | [next] | [standalone]

#1738932

From	Guenter Roeck <linux@roeck-us.net>
Date	2017-09-25 13:10 +0200
Message-ID	<utzqW-5xX-17@gated-at.bofh.it>
In reply to	#1738769

On 09/24/2017 11:29 PM, Greg Kroah-Hartman wrote:
> On Sun, Sep 24, 2017 at 06:02:56PM -0700, Guenter Roeck wrote:
>> On 09/24/2017 01:27 PM, Greg Kroah-Hartman wrote:
>>> This is the start of the stable review cycle for the 3.18.72 release.
>>> There are 42 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 Tue Sep 26 20:26:30 UTC 2017.
>>> Anything received after that time might be too late.
>>>
>>
>> Build results:
>> 	total: 136 pass: 134 fail: 2
>> Failed builds:
>> 	s390:defconfig
>> 	s390:allmodconfig
>> Qemu test results:
>> 	total: 112 pass: 111 fail: 1
>> Failed tests:
>> 	s390:defconfig
>>
>> Build failure:
>>
>> Building s390:defconfig ... failed
>> ------------
>> Error log:
>> drivers/s390/scsi/zfcp_scsi.c: In function 'zfcp_task_mgmt_function':
>> drivers/s390/scsi/zfcp_scsi.c:249:4: error: too many arguments to function 'zfcp_dbf_scsi_devreset'
>> drivers/s390/scsi/zfcp_dbf.h:376:6: note: declared here
>> drivers/s390/scsi/zfcp_scsi.c:260:3: error: too many arguments to function 'zfcp_dbf_scsi_devreset'
>> drivers/s390/scsi/zfcp_dbf.h:376:6: note: declared here
>> make[2]: *** [drivers/s390/scsi/zfcp_scsi.o] Error 1
> 
> Ah, thanks for letting me know about this, I have fixed it up now (hopefully.)
> 

The latest build (v3.18.71-42-ge78c938) passed all my tests.

Guenter

[toc] | [prev] | [next] | [standalone]

#1738989

From	Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date	2017-09-25 14:30 +0200
Message-ID	<utAGl-6ix-11@gated-at.bofh.it>
In reply to	#1738932

On Mon, Sep 25, 2017 at 04:05:41AM -0700, Guenter Roeck wrote:
> On 09/24/2017 11:29 PM, Greg Kroah-Hartman wrote:
> > On Sun, Sep 24, 2017 at 06:02:56PM -0700, Guenter Roeck wrote:
> > > On 09/24/2017 01:27 PM, Greg Kroah-Hartman wrote:
> > > > This is the start of the stable review cycle for the 3.18.72 release.
> > > > There are 42 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 Tue Sep 26 20:26:30 UTC 2017.
> > > > Anything received after that time might be too late.
> > > > 
> > > 
> > > Build results:
> > > 	total: 136 pass: 134 fail: 2
> > > Failed builds:
> > > 	s390:defconfig
> > > 	s390:allmodconfig
> > > Qemu test results:
> > > 	total: 112 pass: 111 fail: 1
> > > Failed tests:
> > > 	s390:defconfig
> > > 
> > > Build failure:
> > > 
> > > Building s390:defconfig ... failed
> > > ------------
> > > Error log:
> > > drivers/s390/scsi/zfcp_scsi.c: In function 'zfcp_task_mgmt_function':
> > > drivers/s390/scsi/zfcp_scsi.c:249:4: error: too many arguments to function 'zfcp_dbf_scsi_devreset'
> > > drivers/s390/scsi/zfcp_dbf.h:376:6: note: declared here
> > > drivers/s390/scsi/zfcp_scsi.c:260:3: error: too many arguments to function 'zfcp_dbf_scsi_devreset'
> > > drivers/s390/scsi/zfcp_dbf.h:376:6: note: declared here
> > > make[2]: *** [drivers/s390/scsi/zfcp_scsi.o] Error 1
> > 
> > Ah, thanks for letting me know about this, I have fixed it up now (hopefully.)
> > 
> 
> The latest build (v3.18.71-42-ge78c938) passed all my tests.

Wonderful, thanks for letting me know.

greg k-h

[toc] | [prev] | [next] | [standalone]

Page 2 of 3 — ← Prev page 1 [2] 3 Next page →

csiph-web

[PATCH 3.18 00/42] 3.18.72-stable review

Contents

#1738327 — [PATCH 3.18 06/42] ipv6: fix typo in fib6_net_exit()

#1738329 — [PATCH 3.18 31/42] tracing: Apply trace_clock changes to instance max buffer

#1738330 — [PATCH 3.18 38/42] bcache: correct cache_dirty_target in __update_writeback_rate()

#1738331 — [PATCH 3.18 32/42] ARC: Re-enable MMU upon Machine Check exception

#1738336 — [PATCH 3.18 28/42] scsi: sg: fixup infoleak when using SG_GET_REQUEST_TABLE

#1738340 — [PATCH 3.18 34/42] media: v4l2-compat-ioctl32: Fix timespec conversion

#1738348 — [PATCH 3.18 04/42] tcp: initialize rcv_mss to TCP_MIN_MSS instead of 0

#1738358 — [PATCH 3.18 35/42] media: uvcvideo: Prevent heap overflow when accessing mapped controls

#1738560 — [PATCH 3.18 24/42] scsi: sg: remove save_scat_len

#1738561 — [PATCH 3.18 14/42] block: Relax a check in blk_start_queue()

#1738562 — [PATCH 3.18 18/42] scsi: zfcp: fix queuecommand for scsi_eh commands when DIX enabled

#1738567 — [PATCH 3.18 22/42] scsi: zfcp: trace HBA FSF response by default on dismiss or timedout late response

#1738568 — [PATCH 3.18 26/42] scsi: sg: off by one in sg_ioctl()

#1738569 — [PATCH 3.18 23/42] scsi: zfcp: trace high part of "new" 64 bit SCSI LUN

#1738570 — [PATCH 3.18 02/42] qlge: avoid memcpy buffer overflow

#1738573 — [PATCH 3.18 13/42] powerpc: Fix DAR reporting when alignment handler faults

#1738613

#1738769

#1738932

#1738989