The patch below does not apply to the 4.9-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable(a)vger.kernel.org>.
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
>From 100843f176109af94600e500da0428e21030ca7f Mon Sep 17 00:00:00 2001
From: Steffen Maier <maier(a)linux.ibm.com>
Date: Fri, 25 Oct 2019 18:12:53 +0200
Subject: [PATCH] scsi: zfcp: trace channel log even for FCP command responses
While v2.6.26 commit b75db73159cc ("[SCSI] zfcp: Add qtcb dump to hba debug
trace") is right that we don't want to flood the (payload) trace ring
buffer, we don't trace successful FCP command responses by default. So we
can include the channel log for problem determination with failed responses
of any FSF request type.
Fixes: b75db73159cc ("[SCSI] zfcp: Add qtcb dump to hba debug trace")
Fixes: a54ca0f62f95 ("[SCSI] zfcp: Redesign of the debug tracing for HBA records.")
Cc: <stable(a)vger.kernel.org> #2.6.38+
Link: https://lore.kernel.org/r/e37597b5c4ae123aaa85fd86c23a9f71e994e4a9.15720181…
Reviewed-by: Benjamin Block <bblock(a)linux.ibm.com>
Signed-off-by: Steffen Maier <maier(a)linux.ibm.com>
Signed-off-by: Benjamin Block <bblock(a)linux.ibm.com>
Signed-off-by: Martin K. Petersen <martin.petersen(a)oracle.com>
diff --git a/drivers/s390/scsi/zfcp_dbf.c b/drivers/s390/scsi/zfcp_dbf.c
index dccdb41bed8c..1234294700c4 100644
--- a/drivers/s390/scsi/zfcp_dbf.c
+++ b/drivers/s390/scsi/zfcp_dbf.c
@@ -95,11 +95,9 @@ void zfcp_dbf_hba_fsf_res(char *tag, int level, struct zfcp_fsf_req *req)
memcpy(rec->u.res.fsf_status_qual, &q_head->fsf_status_qual,
FSF_STATUS_QUALIFIER_SIZE);
- if (q_head->fsf_command != FSF_QTCB_FCP_CMND) {
- rec->pl_len = q_head->log_length;
- zfcp_dbf_pl_write(dbf, (char *)q_pref + q_head->log_start,
- rec->pl_len, "fsf_res", req->req_id);
- }
+ rec->pl_len = q_head->log_length;
+ zfcp_dbf_pl_write(dbf, (char *)q_pref + q_head->log_start,
+ rec->pl_len, "fsf_res", req->req_id);
debug_event(dbf->hba, level, rec, sizeof(*rec));
spin_unlock_irqrestore(&dbf->hba_lock, flags);
This is a note to let you know that I've just added the patch titled
binder: fix incorrect calculation for num_valid
to my char-misc git tree which can be found at
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc.git
in the char-misc-linus branch.
The patch will show up in the next release of the linux-next tree
(usually sometime within the next 24 hours during the week.)
The patch will hopefully also be merged in Linus's tree for the
next -rc kernel release.
If you have any questions about this process, please let me know.
>From 16981742717b04644a41052570fb502682a315d2 Mon Sep 17 00:00:00 2001
From: Todd Kjos <tkjos(a)android.com>
Date: Fri, 13 Dec 2019 12:25:31 -0800
Subject: binder: fix incorrect calculation for num_valid
For BINDER_TYPE_PTR and BINDER_TYPE_FDA transactions, the
num_valid local was calculated incorrectly causing the
range check in binder_validate_ptr() to miss out-of-bounds
offsets.
Fixes: bde4a19fc04f ("binder: use userspace pointer as base of buffer space")
Signed-off-by: Todd Kjos <tkjos(a)google.com>
Cc: stable <stable(a)vger.kernel.org>
Link: https://lore.kernel.org/r/20191213202531.55010-1-tkjos@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/android/binder.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/android/binder.c b/drivers/android/binder.c
index e9bc9fcc7ea5..b2dad43dbf82 100644
--- a/drivers/android/binder.c
+++ b/drivers/android/binder.c
@@ -3310,7 +3310,7 @@ static void binder_transaction(struct binder_proc *proc,
binder_size_t parent_offset;
struct binder_fd_array_object *fda =
to_binder_fd_array_object(hdr);
- size_t num_valid = (buffer_offset - off_start_offset) *
+ size_t num_valid = (buffer_offset - off_start_offset) /
sizeof(binder_size_t);
struct binder_buffer_object *parent =
binder_validate_ptr(target_proc, t->buffer,
@@ -3384,7 +3384,7 @@ static void binder_transaction(struct binder_proc *proc,
t->buffer->user_data + sg_buf_offset;
sg_buf_offset += ALIGN(bp->length, sizeof(u64));
- num_valid = (buffer_offset - off_start_offset) *
+ num_valid = (buffer_offset - off_start_offset) /
sizeof(binder_size_t);
ret = binder_fixup_parent(t, thread, bp,
off_start_offset,
--
2.24.1
The following changes since commit e42617b825f8073569da76dc4510bfa019b1c35a:
Linux 5.5-rc1 (2019-12-08 14:57:55 -0800)
are available in the Git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost.git tags/for_linus
for you to fetch changes up to 63b9b80e9f5b2c463d98d6e550e0d0e3ace66033:
virtio_balloon: divide/multiply instead of shifts (2019-12-11 08:14:07 -0500)
----------------------------------------------------------------
virtio: fixes, cleanups
Some fixes and cleanup patches.
Signed-off-by: Michael S. Tsirkin <mst(a)redhat.com>
----------------------------------------------------------------
David Hildenbrand (1):
virtio-balloon: fix managed page counts when migrating pages between zones
Michael S. Tsirkin (2):
virtio_balloon: name cleanups
virtio_balloon: divide/multiply instead of shifts
drivers/virtio/virtio_balloon.c | 36 ++++++++++++++++++++++++------------
1 file changed, 24 insertions(+), 12 deletions(-)
From: Sean Paul <seanpaul(a)chromium.org>
On HDCP disable, clear the repeater bit. This ensures if we connect a
non-repeater sink after a repeater, the bit is in the state we expect.
Fixes: ee5e5e7a5e0f ("drm/i915: Add HDCP framework + base implementation")
Cc: Chris Wilson <chris(a)chris-wilson.co.uk>
Cc: Ramalingam C <ramalingam.c(a)intel.com>
Cc: Daniel Vetter <daniel.vetter(a)ffwll.ch>
Cc: Sean Paul <seanpaul(a)chromium.org>
Cc: Jani Nikula <jani.nikula(a)linux.intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen(a)linux.intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi(a)intel.com>
Cc: intel-gfx(a)lists.freedesktop.org
Cc: <stable(a)vger.kernel.org> # v4.17+
Signed-off-by: Sean Paul <seanpaul(a)chromium.org>
Changes in v2:
-Added to the set
---
drivers/gpu/drm/i915/display/intel_hdcp.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c b/drivers/gpu/drm/i915/display/intel_hdcp.c
index eaab9008feef..c4394c8e10eb 100644
--- a/drivers/gpu/drm/i915/display/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/display/intel_hdcp.c
@@ -773,6 +773,7 @@ static int _intel_hdcp_disable(struct intel_connector *connector)
struct intel_digital_port *intel_dig_port = conn_to_dig_port(connector);
enum port port = intel_dig_port->base.port;
enum transcoder cpu_transcoder = hdcp->cpu_transcoder;
+ u32 repeater_ctl;
int ret;
DRM_DEBUG_KMS("[%s:%d] HDCP is being disabled...\n",
@@ -787,6 +788,10 @@ static int _intel_hdcp_disable(struct intel_connector *connector)
return -ETIMEDOUT;
}
+ repeater_ctl = intel_hdcp_get_repeater_ctl(dev_priv, cpu_transcoder,
+ port);
+ I915_WRITE(HDCP_REP_CTL, I915_READ(HDCP_REP_CTL) & ~repeater_ctl);
+
ret = hdcp->shim->toggle_signalling(intel_dig_port, false);
if (ret) {
DRM_ERROR("Failed to disable HDCP signalling\n");
--
Sean Paul, Software Engineer, Google / Chromium OS
Hi,
I'd like to report a very severe performance regression due to
mm/vmalloc: Sync unmappings in __purge_vmap_area_lazy() in stable kernels
in v4.19.88. I believe this was included since v4.19.67. It is also
in all the other LTS kernels, except 3.16.
So today I switched an x86_64 production server from v5.1.21 to
v4.19.88, because we kept hitting runaway kcompactd and kswapd.
Plus there was a significant increase in memory usage compared to
v5.1.5. I'm still bisecting that on another production server.
The service we run is one of the largest forums in Taiwan [1].
It is a terminal-based bulletin board system running over telnet,
SSH or a custom WebSocket bridge. The service itself is the
one-process-per-user type of design from the old days. This
means a lot of forks when there are user spikes or reconnections.
(Reconnections happen because a lot of people use mobile apps that
wrap the service, but they get disconnected as soon as they are
backgrounded.)
With v4.19.88 we saw a lot of contention on pgd_lock in the process
fork path with CONFIG_VMAP_STACK=y:
Samples: 937K of event 'cycles:ppp', Event count (approx.): 499112453614
Children Self Command Shared Object Symbol
+ 31.15% 0.03% mbbsd [kernel.kallsyms]
[k] entry_SYSCALL_64_after_hwframe
+ 31.12% 0.02% mbbsd [kernel.kallsyms]
[k] do_syscall_64
+ 28.12% 0.42% mbbsd [kernel.kallsyms]
[k] do_raw_spin_lock
- 27.70% 27.62% mbbsd [kernel.kallsyms]
[k] queued_spin_lock_slowpath
- 18.73% __libc_fork
- 18.33% entry_SYSCALL_64_after_hwframe
do_syscall_64
- _do_fork
- 18.33% copy_process.part.64
- 11.00% __vmalloc_node_range
- 10.93% sync_global_pgds_l4
do_raw_spin_lock
queued_spin_lock_slowpath
- 7.27% mm_init.isra.59
pgd_alloc
do_raw_spin_lock
queued_spin_lock_slowpath
- 8.68% 0x41fd89415541f689
- __libc_start_main
+ 7.49% main
+ 0.90% main
This hit us pretty hard, with the service dropping below one-third
of its original capacity.
With CONFIG_VMAP_STACK=n, the fork code path skips this, but other
vmalloc users are still affected. One other area is the tty layer.
This also causes problems for us since there can be as many as 15k
users over SSH, some coming and going. So we got a lot of hung sshd
processes as well. Unfortunately I don't have any perf reports or
kernel logs to go with.
Now I understand that there is already a fix in -next:
https://lore.kernel.org/patchwork/patch/1137341/
However the code has changed a lot in mainline and I'm not sure how
to backport this. For now I just reverted the commit by hand by
removing the offending code. Seems to work OK, and based on the commit
logs I guess it's safe to do so, as we're not running X86-32 or PTI.
Regards
ChenYu
[1] https://en.wikipedia.org/wiki/PTT_Bulletin_Board_System