[PATCH 4.9 040/102] 9p/rdma: do not disconnect on down_interruptible EAGAIN

2019-07-08 Thread Greg Kroah-Hartman
[ Upstream commit 8b894adb2b7e1d1e64b8954569c761eaf3d51ab5 ]

9p/rdma would sometimes drop the connection and display errors in
recv_done when the user does ^C.
The errors were caused by recv buffers that were posted at the time
of disconnect, and we just do not want to disconnect when
down_interruptible is... interrupted.

Link: 
http://lkml.kernel.org/r/1535625307-18019-1-git-send-email-asmad...@codewreck.org
Signed-off-by: Dominique Martinet 
Signed-off-by: Sasha Levin 
---
 net/9p/trans_rdma.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/net/9p/trans_rdma.c b/net/9p/trans_rdma.c
index 5a2ad4707463..9662c2747be7 100644
--- a/net/9p/trans_rdma.c
+++ b/net/9p/trans_rdma.c
@@ -454,7 +454,7 @@ static int rdma_request(struct p9_client *client, struct 
p9_req_t *req)
 
err = post_recv(client, rpl_context);
if (err) {
-   p9_debug(P9_DEBUG_FCALL, "POST RECV failed\n");
+   p9_debug(P9_DEBUG_ERROR, "POST RECV failed: %d\n", err);
goto recv_error;
}
/* remove posted receive buffer from request structure */
@@ -523,7 +523,7 @@ static int rdma_request(struct p9_client *client, struct 
p9_req_t *req)
  recv_error:
kfree(rpl_context);
spin_lock_irqsave(>req_lock, flags);
-   if (rdma->state < P9_RDMA_CLOSING) {
+   if (err != -EINTR && rdma->state < P9_RDMA_CLOSING) {
rdma->state = P9_RDMA_CLOSING;
spin_unlock_irqrestore(>req_lock, flags);
rdma_disconnect(rdma->cm_id);
-- 
2.20.1





[PATCH 4.9 006/102] Input: uinput - add compat ioctl number translation for UI_*_FF_UPLOAD

2019-07-08 Thread Greg Kroah-Hartman
From: Andrey Smirnov 

commit 7c7da40da1640ce6814dab1e8031b44e19e5a3f6 upstream.

In the case of compat syscall ioctl numbers for UI_BEGIN_FF_UPLOAD and
UI_END_FF_UPLOAD need to be adjusted before being passed on
uinput_ioctl_handler() since code built with -m32 will be passing
slightly different values. Extend the code already covering
UI_SET_PHYS to cover UI_BEGIN_FF_UPLOAD and UI_END_FF_UPLOAD as well.

Reported-by: Pierre-Loup A. Griffais 
Signed-off-by: Andrey Smirnov 
Cc: sta...@vger.kernel.org
Signed-off-by: Dmitry Torokhov 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/input/misc/uinput.c |   22 --
 1 file changed, 20 insertions(+), 2 deletions(-)

--- a/drivers/input/misc/uinput.c
+++ b/drivers/input/misc/uinput.c
@@ -991,13 +991,31 @@ static long uinput_ioctl(struct file *fi
 
 #ifdef CONFIG_COMPAT
 
-#define UI_SET_PHYS_COMPAT _IOW(UINPUT_IOCTL_BASE, 108, compat_uptr_t)
+/*
+ * These IOCTLs change their size and thus their numbers between
+ * 32 and 64 bits.
+ */
+#define UI_SET_PHYS_COMPAT \
+   _IOW(UINPUT_IOCTL_BASE, 108, compat_uptr_t)
+#define UI_BEGIN_FF_UPLOAD_COMPAT  \
+   _IOWR(UINPUT_IOCTL_BASE, 200, struct uinput_ff_upload_compat)
+#define UI_END_FF_UPLOAD_COMPAT\
+   _IOW(UINPUT_IOCTL_BASE, 201, struct uinput_ff_upload_compat)
 
 static long uinput_compat_ioctl(struct file *file,
unsigned int cmd, unsigned long arg)
 {
-   if (cmd == UI_SET_PHYS_COMPAT)
+   switch (cmd) {
+   case UI_SET_PHYS_COMPAT:
cmd = UI_SET_PHYS;
+   break;
+   case UI_BEGIN_FF_UPLOAD_COMPAT:
+   cmd = UI_BEGIN_FF_UPLOAD;
+   break;
+   case UI_END_FF_UPLOAD_COMPAT:
+   cmd = UI_END_FF_UPLOAD;
+   break;
+   }
 
return uinput_ioctl_handler(file, cmd, arg, compat_ptr(arg));
 }




[PATCH 4.9 039/102] perf header: Fix unchecked usage of strncpy()

2019-07-08 Thread Greg Kroah-Hartman
From: Arnaldo Carvalho de Melo 

commit 5192bde7d98c99f2cd80225649e3c2e7493722f7 upstream.

The strncpy() function may leave the destination string buffer
unterminated, better use strlcpy() that we have a __weak fallback
implementation for systems without it.

This fixes this warning on an Alpine Linux Edge system with gcc 8.2:

  util/header.c: In function 'perf_event__synthesize_event_update_name':
  util/header.c:3625:2: error: 'strncpy' output truncated before terminating 
nul copying as many bytes from a string as its length 
[-Werror=stringop-truncation]
strncpy(ev->data, evsel->name, len);
^~~
  util/header.c:3618:15: note: length computed here
size_t len = strlen(evsel->name);
 ^~~

Cc: Adrian Hunter 
Cc: Jiri Olsa 
Cc: Namhyung Kim 
Fixes: a6e5281780d1 ("perf tools: Add event_update event unit type")
Link: https://lkml.kernel.org/n/tip-wycz66iy8dl2z3yifgqf8...@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo 
Signed-off-by: Greg Kroah-Hartman 

---
 tools/perf/util/header.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/tools/perf/util/header.c
+++ b/tools/perf/util/header.c
@@ -3027,7 +3027,7 @@ perf_event__synthesize_event_update_name
if (ev == NULL)
return -ENOMEM;
 
-   strncpy(ev->data, evsel->name, len);
+   strlcpy(ev->data, evsel->name, len + 1);
err = process(tool, (union perf_event*) ev, NULL, NULL);
free(ev);
return err;




[PATCH 4.9 036/102] IB/hfi1: Avoid hardlockup with flushlist_lock

2019-07-08 Thread Greg Kroah-Hartman
commit cf131a81967583ae737df6383a0893b9fee75b4e upstream.

Heavy contention of the sde flushlist_lock can cause hard lockups at
extreme scale when the flushing logic is under stress.

Mitigate by replacing the item at a time copy to the local list with
an O(1) list_splice_init() and using the high priority work queue to
do the flushes.

Ported to linux-4.9.y.

Fixes: 7724105686e7 ("IB/hfi1: add driver files")
Cc: 
Reviewed-by: Dennis Dalessandro 
Signed-off-by: Mike Marciniszyn 
Signed-off-by: Dennis Dalessandro 
Signed-off-by: Doug Ledford 
Signed-off-by: Sasha Levin 
---
 drivers/infiniband/hw/hfi1/sdma.c | 9 +++--
 1 file changed, 3 insertions(+), 6 deletions(-)

diff --git a/drivers/infiniband/hw/hfi1/sdma.c 
b/drivers/infiniband/hw/hfi1/sdma.c
index 9cbe52d21077..76e63c88a87a 100644
--- a/drivers/infiniband/hw/hfi1/sdma.c
+++ b/drivers/infiniband/hw/hfi1/sdma.c
@@ -410,10 +410,7 @@ static void sdma_flush(struct sdma_engine *sde)
sdma_flush_descq(sde);
spin_lock_irqsave(>flushlist_lock, flags);
/* copy flush list */
-   list_for_each_entry_safe(txp, txp_next, >flushlist, list) {
-   list_del_init(>list);
-   list_add_tail(>list, );
-   }
+   list_splice_init(>flushlist, );
spin_unlock_irqrestore(>flushlist_lock, flags);
/* flush from flush list */
list_for_each_entry_safe(txp, txp_next, , list)
@@ -2406,7 +2403,7 @@ int sdma_send_txreq(struct sdma_engine *sde,
wait->tx_count++;
wait->count += tx->num_desc;
}
-   schedule_work(>flush_worker);
+   queue_work_on(sde->cpu, system_highpri_wq, >flush_worker);
ret = -ECOMM;
goto unlock;
 nodesc:
@@ -2504,7 +2501,7 @@ int sdma_send_txlist(struct sdma_engine *sde, struct 
iowait *wait,
}
}
spin_unlock(>flushlist_lock);
-   schedule_work(>flush_worker);
+   queue_work_on(sde->cpu, system_highpri_wq, >flush_worker);
ret = -ECOMM;
goto update_tail;
 nodesc:
-- 
2.20.1





[PATCH 4.9 038/102] perf help: Remove needless use of strncpy()

2019-07-08 Thread Greg Kroah-Hartman
From: Arnaldo Carvalho de Melo 

commit b6313899f4ed2e76b8375cf8069556f5b94fbff0 upstream.

Since we make sure the destination buffer has at least strlen(orig) + 1,
no need to do a strncpy(dest, orig, strlen(orig)), just use strcpy(dest,
orig).

This silences this gcc 8.2 warning on Alpine Linux:

  In function 'add_man_viewer',
  inlined from 'perf_help_config' at builtin-help.c:284:3:
  builtin-help.c:192:2: error: 'strncpy' output truncated before terminating 
nul copying as many bytes from a string as its length 
[-Werror=stringop-truncation]
strncpy((*p)->name, name, len);
^~
  builtin-help.c: In function 'perf_help_config':
  builtin-help.c:187:15: note: length computed here
size_t len = strlen(name);
 ^~~~

Cc: Adrian Hunter 
Cc: Jiri Olsa 
Cc: Namhyung Kim 
Fixes: 078006012401 ("perf_counter tools: add in basic glue from Git")
Link: https://lkml.kernel.org/n/tip-2f69l7drca427ob4km8i7...@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo 
Signed-off-by: Greg Kroah-Hartman 

---
 tools/perf/builtin-help.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/tools/perf/builtin-help.c
+++ b/tools/perf/builtin-help.c
@@ -186,7 +186,7 @@ static void add_man_viewer(const char *n
while (*p)
p = &((*p)->next);
*p = zalloc(sizeof(**p) + len + 1);
-   strncpy((*p)->name, name, len);
+   strcpy((*p)->name, name);
 }
 
 static int supported_man_viewer(const char *name, size_t len)




[PATCH 4.9 027/102] can: flexcan: fix timeout when set small bitrate

2019-07-08 Thread Greg Kroah-Hartman
From: Joakim Zhang 

commit 247e5356a709eb49a0d95ff2a7f07dac05c8252c upstream.

Current we can meet timeout issue when setting a small bitrate like
1 as follows on i.MX6UL EVK board (ipg clock = 66MHZ, per clock =
30MHZ):

| root@imx6ul7d:~# ip link set can0 up type can bitrate 1

A link change request failed with some changes committed already.
Interface can0 may have been left with an inconsistent configuration,
please check.

| RTNETLINK answers: Connection timed out

It is caused by calling of flexcan_chip_unfreeze() timeout.

Originally the code is using usleep_range(10, 20) for unfreeze
operation, but the patch (8badd65 can: flexcan: avoid calling
usleep_range from interrupt context) changed it into udelay(10) which is
only a half delay of before, there're also some other delay changes.

After double to FLEXCAN_TIMEOUT_US to 100 can fix the issue.

Meanwhile, Rasmus Villemoes reported that even with a timeout of 100,
flexcan_probe() fails on the MPC8309, which requires a value of at least
140 to work reliably. 250 works for everyone.

Signed-off-by: Joakim Zhang 
Reviewed-by: Dong Aisheng 
Cc: linux-stable 
Signed-off-by: Marc Kleine-Budde 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/net/can/flexcan.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/net/can/flexcan.c
+++ b/drivers/net/can/flexcan.c
@@ -171,7 +171,7 @@
 #define FLEXCAN_MB_CNT_LENGTH(x)   (((x) & 0xf) << 16)
 #define FLEXCAN_MB_CNT_TIMESTAMP(x)((x) & 0x)
 
-#define FLEXCAN_TIMEOUT_US (50)
+#define FLEXCAN_TIMEOUT_US (250)
 
 /* FLEXCAN hardware feature flags
  *




[PATCH 4.9 037/102] perf ui helpline: Use strlcpy() as a shorter form of strncpy() + explicit set nul

2019-07-08 Thread Greg Kroah-Hartman
From: Arnaldo Carvalho de Melo 

commit 4d0f16d059ddb91424480d88473f7392f24aebdc upstream.

The strncpy() function may leave the destination string buffer
unterminated, better use strlcpy() that we have a __weak fallback
implementation for systems without it.

In this case we are actually setting the null byte at the right place,
but since we pass the buffer size as the limit to strncpy() and not
it minus one, gcc ends up warning us about that, see below. So, lets
just switch to the shorter form provided by strlcpy().

This fixes this warning on an Alpine Linux Edge system with gcc 8.2:

  ui/tui/helpline.c: In function 'tui_helpline__push':
  ui/tui/helpline.c:27:2: error: 'strncpy' specified bound 512 equals 
destination size [-Werror=stringop-truncation]
strncpy(ui_helpline__current, msg, sz)[sz - 1] = '\0';
^~
  cc1: all warnings being treated as errors

Cc: Adrian Hunter 
Cc: Jiri Olsa 
Cc: Namhyung Kim 
Fixes: e6e904687949 ("perf ui: Introduce struct ui_helpline")
Link: https://lkml.kernel.org/n/tip-d1wz0hjjsh19xbalw69qp...@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo 
Signed-off-by: Greg Kroah-Hartman 

---
 tools/perf/ui/tui/helpline.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/tools/perf/ui/tui/helpline.c
+++ b/tools/perf/ui/tui/helpline.c
@@ -23,7 +23,7 @@ static void tui_helpline__push(const cha
SLsmg_set_color(0);
SLsmg_write_nstring((char *)msg, SLtt_Screen_Cols);
SLsmg_refresh();
-   strncpy(ui_helpline__current, msg, sz)[sz - 1] = '\0';
+   strlcpy(ui_helpline__current, msg, sz);
 }
 
 static int tui_helpline__show(const char *format, va_list ap)




[PATCH 4.9 026/102] btrfs: start readahead also in seed devices

2019-07-08 Thread Greg Kroah-Hartman
From: Naohiro Aota 

commit c4e0540d0ad49c8ceab06cceed1de27c4fe29f6e upstream.

Currently, btrfs does not consult seed devices to start readahead. As a
result, if readahead zone is added to the seed devices, btrfs_reada_wait()
indefinitely wait for the reada_ctl to finish.

You can reproduce the hung by modifying btrfs/163 to have larger initial
file size (e.g. xfs_io pwrite 4M instead of current 256K).

Fixes: 7414a03fbf9e ("btrfs: initial readahead code and prototypes")
Cc: sta...@vger.kernel.org # 3.2+: ce7791ffee1e: Btrfs: fix race between 
readahead and device replace/removal
Cc: sta...@vger.kernel.org # 3.2+
Reviewed-by: Filipe Manana 
Signed-off-by: Naohiro Aota 
Signed-off-by: David Sterba 
Signed-off-by: Greg Kroah-Hartman 

---
 fs/btrfs/reada.c |5 +
 1 file changed, 5 insertions(+)

--- a/fs/btrfs/reada.c
+++ b/fs/btrfs/reada.c
@@ -759,6 +759,7 @@ static void __reada_start_machine(struct
u64 total = 0;
int i;
 
+again:
do {
enqueued = 0;
mutex_lock(_devices->device_list_mutex);
@@ -771,6 +772,10 @@ static void __reada_start_machine(struct
mutex_unlock(_devices->device_list_mutex);
total += enqueued;
} while (enqueued && total < 1);
+   if (fs_devices->seed) {
+   fs_devices = fs_devices->seed;
+   goto again;
+   }
 
if (enqueued == 0)
return;




[PATCH 4.9 003/102] scsi: ufs: Avoid runtime suspend possibly being blocked forever

2019-07-08 Thread Greg Kroah-Hartman
From: Stanley Chu 

commit 24e2e7a19f7e4b83d0d5189040d997bce3596473 upstream.

UFS runtime suspend can be triggered after pm_runtime_enable() is invoked
in ufshcd_pltfrm_init(). However if the first runtime suspend is triggered
before binding ufs_hba structure to ufs device structure via
platform_set_drvdata(), then UFS runtime suspend will be no longer
triggered in the future because its dev->power.runtime_error was set in the
first triggering and does not have any chance to be cleared.

To be more clear, dev->power.runtime_error is set if hba is NULL in
ufshcd_runtime_suspend() which returns -EINVAL to rpm_callback() where
dev->power.runtime_error is set as -EINVAL. In this case, any future
rpm_suspend() for UFS device fails because rpm_check_suspend_allowed()
fails due to non-zero
dev->power.runtime_error.

To resolve this issue, make sure the first UFS runtime suspend get valid
"hba" in ufshcd_runtime_suspend(): Enable UFS runtime PM only after hba is
successfully bound to UFS device structure.

Fixes: 62694735ca95 ([SCSI] ufs: Add runtime PM support for UFS host controller 
driver)
Cc: sta...@vger.kernel.org
Signed-off-by: Stanley Chu 
Reviewed-by: Avri Altman 
Signed-off-by: Martin K. Petersen 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/scsi/ufs/ufshcd-pltfrm.c |   11 ---
 1 file changed, 4 insertions(+), 7 deletions(-)

--- a/drivers/scsi/ufs/ufshcd-pltfrm.c
+++ b/drivers/scsi/ufs/ufshcd-pltfrm.c
@@ -342,24 +342,21 @@ int ufshcd_pltfrm_init(struct platform_d
goto dealloc_host;
}
 
-   pm_runtime_set_active(>dev);
-   pm_runtime_enable(>dev);
-
ufshcd_init_lanes_per_dir(hba);
 
err = ufshcd_init(hba, mmio_base, irq);
if (err) {
dev_err(dev, "Initialization failed\n");
-   goto out_disable_rpm;
+   goto dealloc_host;
}
 
platform_set_drvdata(pdev, hba);
 
+   pm_runtime_set_active(>dev);
+   pm_runtime_enable(>dev);
+
return 0;
 
-out_disable_rpm:
-   pm_runtime_disable(>dev);
-   pm_runtime_set_suspended(>dev);
 dealloc_host:
ufshcd_dealloc_host(hba);
 out:




[PATCH 4.9 029/102] powerpc/bpf: use unsigned division instruction for 64-bit operations

2019-07-08 Thread Greg Kroah-Hartman
From: Naveen N. Rao 

commit 758f2046ea040773ae8ea7f72dd3bbd8fa984501 upstream.

BPF_ALU64 div/mod operations are currently using signed division, unlike
BPF_ALU32 operations. Fix the same. DIV64 and MOD64 overflow tests pass
with this fix.

Fixes: 156d0e290e969c ("powerpc/ebpf/jit: Implement JIT compiler for extended 
BPF")
Cc: sta...@vger.kernel.org # v4.8+
Signed-off-by: Naveen N. Rao 
Signed-off-by: Daniel Borkmann 
Signed-off-by: Greg Kroah-Hartman 

---
 arch/powerpc/include/asm/ppc-opcode.h |1 +
 arch/powerpc/net/bpf_jit.h|2 +-
 arch/powerpc/net/bpf_jit_comp64.c |8 
 3 files changed, 6 insertions(+), 5 deletions(-)

--- a/arch/powerpc/include/asm/ppc-opcode.h
+++ b/arch/powerpc/include/asm/ppc-opcode.h
@@ -261,6 +261,7 @@
 #define PPC_INST_MULLI 0x1c00
 #define PPC_INST_DIVWU 0x7c000396
 #define PPC_INST_DIVD  0x7c0003d2
+#define PPC_INST_DIVDU 0x7c000392
 #define PPC_INST_RLWINM0x5400
 #define PPC_INST_RLWIMI0x5000
 #define PPC_INST_RLDICL0x7800
--- a/arch/powerpc/net/bpf_jit.h
+++ b/arch/powerpc/net/bpf_jit.h
@@ -116,7 +116,7 @@
 ___PPC_RA(a) | IMM_L(i))
 #define PPC_DIVWU(d, a, b) EMIT(PPC_INST_DIVWU | ___PPC_RT(d) |  \
 ___PPC_RA(a) | ___PPC_RB(b))
-#define PPC_DIVD(d, a, b)  EMIT(PPC_INST_DIVD | ___PPC_RT(d) |   \
+#define PPC_DIVDU(d, a, b) EMIT(PPC_INST_DIVDU | ___PPC_RT(d) |  \
 ___PPC_RA(a) | ___PPC_RB(b))
 #define PPC_AND(d, a, b)   EMIT(PPC_INST_AND | ___PPC_RA(d) |\
 ___PPC_RS(a) | ___PPC_RB(b))
--- a/arch/powerpc/net/bpf_jit_comp64.c
+++ b/arch/powerpc/net/bpf_jit_comp64.c
@@ -419,12 +419,12 @@ static int bpf_jit_build_body(struct bpf
PPC_LI(b2p[BPF_REG_0], 0);
PPC_JMP(exit_addr);
if (BPF_OP(code) == BPF_MOD) {
-   PPC_DIVD(b2p[TMP_REG_1], dst_reg, src_reg);
+   PPC_DIVDU(b2p[TMP_REG_1], dst_reg, src_reg);
PPC_MULD(b2p[TMP_REG_1], src_reg,
b2p[TMP_REG_1]);
PPC_SUB(dst_reg, dst_reg, b2p[TMP_REG_1]);
} else
-   PPC_DIVD(dst_reg, dst_reg, src_reg);
+   PPC_DIVDU(dst_reg, dst_reg, src_reg);
break;
case BPF_ALU | BPF_MOD | BPF_K: /* (u32) dst %= (u32) imm */
case BPF_ALU | BPF_DIV | BPF_K: /* (u32) dst /= (u32) imm */
@@ -452,7 +452,7 @@ static int bpf_jit_build_body(struct bpf
break;
case BPF_ALU64:
if (BPF_OP(code) == BPF_MOD) {
-   PPC_DIVD(b2p[TMP_REG_2], dst_reg,
+   PPC_DIVDU(b2p[TMP_REG_2], dst_reg,
b2p[TMP_REG_1]);
PPC_MULD(b2p[TMP_REG_1],
b2p[TMP_REG_1],
@@ -460,7 +460,7 @@ static int bpf_jit_build_body(struct bpf
PPC_SUB(dst_reg, dst_reg,
b2p[TMP_REG_1]);
} else
-   PPC_DIVD(dst_reg, dst_reg,
+   PPC_DIVDU(dst_reg, dst_reg,
b2p[TMP_REG_1]);
break;
}




[PATCH 4.9 028/102] can: purge socket error queue on sock destruct

2019-07-08 Thread Greg Kroah-Hartman
From: Willem de Bruijn 

commit fd704bd5ee749d560e86c4f1fd2ef486d8abf7cf upstream.

CAN supports software tx timestamps as of the below commit. Purge
any queued timestamp packets on socket destroy.

Fixes: 51f31cabe3ce ("ip: support for TX timestamps on UDP and RAW sockets")
Reported-by: syzbot+a90604060cb40f5bd...@syzkaller.appspotmail.com
Signed-off-by: Willem de Bruijn 
Cc: linux-stable 
Signed-off-by: Marc Kleine-Budde 
Signed-off-by: Greg Kroah-Hartman 

---
 net/can/af_can.c |1 +
 1 file changed, 1 insertion(+)

--- a/net/can/af_can.c
+++ b/net/can/af_can.c
@@ -113,6 +113,7 @@ EXPORT_SYMBOL(can_ioctl);
 static void can_sock_destruct(struct sock *sk)
 {
skb_queue_purge(>sk_receive_queue);
+   skb_queue_purge(>sk_error_queue);
 }
 
 static const struct can_proto *can_get_proto(int protocol)




[PATCH 4.9 030/102] ARM: imx: cpuidle-imx6sx: Restrict the SW2ISO increase to i.MX6SX

2019-07-08 Thread Greg Kroah-Hartman
From: Fabio Estevam 

commit b25af2ff7c07bd19af74e3f64ff82e2880d13d81 upstream.

Since commit 1e434b703248 ("ARM: imx: update the cpu power up timing
setting on i.mx6sx") some characters loss is noticed on i.MX6ULL UART
as reported by Christoph Niedermaier.

The intention of such commit was to increase the SW2ISO field for i.MX6SX
only, but since cpuidle-imx6sx is also used on i.MX6UL/i.MX6ULL this caused
unintended side effects on other SoCs.

Fix this problem by keeping the original SW2ISO value for i.MX6UL/i.MX6ULL
and only increase SW2ISO in the i.MX6SX case.

Cc: sta...@vger.kernel.org
Fixes: 1e434b703248 ("ARM: imx: update the cpu power up timing setting on 
i.mx6sx")
Reported-by: Christoph Niedermaier 
Signed-off-by: Fabio Estevam 
Tested-by: Sébastien Szymanski 
Tested-by: Christoph Niedermaier 
Signed-off-by: Shawn Guo 
Signed-off-by: Greg Kroah-Hartman 

---
 arch/arm/mach-imx/cpuidle-imx6sx.c |3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

--- a/arch/arm/mach-imx/cpuidle-imx6sx.c
+++ b/arch/arm/mach-imx/cpuidle-imx6sx.c
@@ -15,6 +15,7 @@
 
 #include "common.h"
 #include "cpuidle.h"
+#include "hardware.h"
 
 static int imx6sx_idle_finish(unsigned long val)
 {
@@ -108,7 +109,7 @@ int __init imx6sx_cpuidle_init(void)
 * except for power up sw2iso which need to be
 * larger than LDO ramp up time.
 */
-   imx_gpc_set_arm_power_up_timing(0xf, 1);
+   imx_gpc_set_arm_power_up_timing(cpu_is_imx6sx() ? 0xf : 0x2, 1);
imx_gpc_set_arm_power_down_timing(1, 1);
 
return cpuidle_register(_cpuidle_driver, NULL);




[PATCH 4.9 031/102] Bluetooth: Align minimum encryption key size for LE and BR/EDR connections

2019-07-08 Thread Greg Kroah-Hartman
From: Marcel Holtmann 

commit d5bb334a8e171b262e48f378bd2096c0ea458265 upstream.

The minimum encryption key size for LE connections is 56 bits and to
align LE with BR/EDR, enforce 56 bits of minimum encryption key size for
BR/EDR connections as well.

Signed-off-by: Marcel Holtmann 
Signed-off-by: Johan Hedberg 
Cc: sta...@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman 

---
 include/net/bluetooth/hci_core.h |3 +++
 net/bluetooth/hci_conn.c |8 
 2 files changed, 11 insertions(+)

--- a/include/net/bluetooth/hci_core.h
+++ b/include/net/bluetooth/hci_core.h
@@ -176,6 +176,9 @@ struct adv_info {
 
 #define HCI_MAX_SHORT_NAME_LENGTH  10
 
+/* Min encryption key size to match with SMP */
+#define HCI_MIN_ENC_KEY_SIZE   7
+
 /* Default LE RPA expiry time, 15 minutes */
 #define HCI_DEFAULT_RPA_TIMEOUT(15 * 60)
 
--- a/net/bluetooth/hci_conn.c
+++ b/net/bluetooth/hci_conn.c
@@ -1165,6 +1165,14 @@ int hci_conn_check_link_mode(struct hci_
!test_bit(HCI_CONN_ENCRYPT, >flags))
return 0;
 
+   /* The minimum encryption key size needs to be enforced by the
+* host stack before establishing any L2CAP connections. The
+* specification in theory allows a minimum of 1, but to align
+* BR/EDR and LE transports, a minimum of 7 is chosen.
+*/
+   if (conn->enc_key_size < HCI_MIN_ENC_KEY_SIZE)
+   return 0;
+
return 1;
 }
 




[PATCH 4.9 025/102] nvme: Fix u32 overflow in the number of namespace list calculation

2019-07-08 Thread Greg Kroah-Hartman
[ Upstream commit c8e8c77b3bdbade6e26e8e76595f141ede12b692 ]

The Number of Namespaces (nn) field in the identify controller data structure is
defined as u32 and the maximum allowed value in NVMe specification is
0xFFFEUL. This change fixes the possible overflow of the DIV_ROUND_UP()
operation used in nvme_scan_ns_list() by casting the nn to u64.

Signed-off-by: Jaesoo Lee 
Reviewed-by: Christoph Hellwig 
Signed-off-by: Sagi Grimberg 
Signed-off-by: Sasha Levin 
---
 drivers/nvme/host/core.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/nvme/host/core.c b/drivers/nvme/host/core.c
index 979c6ecc6446..8705bfe7bb73 100644
--- a/drivers/nvme/host/core.c
+++ b/drivers/nvme/host/core.c
@@ -1765,7 +1765,8 @@ static int nvme_scan_ns_list(struct nvme_ctrl *ctrl, 
unsigned nn)
 {
struct nvme_ns *ns;
__le32 *ns_list;
-   unsigned i, j, nsid, prev = 0, num_lists = DIV_ROUND_UP(nn, 1024);
+   unsigned i, j, nsid, prev = 0;
+   unsigned num_lists = DIV_ROUND_UP_ULL((u64)nn, 1024);
int ret = 0;
 
ns_list = kzalloc(0x1000, GFP_KERNEL);
-- 
2.20.1





[PATCH 4.9 024/102] hwmon: (pmbus/core) Treat parameters as paged if on multiple pages

2019-07-08 Thread Greg Kroah-Hartman
[ Upstream commit 4a60570dce658e3f8885bbcf852430b99f65aca5 ]

Some chips have attributes which exist on more than one page but the
attribute is not presently marked as paged. This causes the attributes
to be generated with the same label, which makes it impossible for
userspace to tell them apart.

Marking all such attributes as paged would result in the page suffix
being added regardless of whether they were present on more than one
page or not, which might break existing setups. Therefore, we add a
second check which treats the attribute as paged, even if not marked as
such, if it is present on multiple pages.

Fixes: b4ce237b7f7d ("hwmon: (pmbus) Introduce infrastructure to detect sensors 
and limit registers")
Signed-off-by: Robert Hancock 
Signed-off-by: Guenter Roeck 
Signed-off-by: Sasha Levin 
---
 drivers/hwmon/pmbus/pmbus_core.c | 34 
 1 file changed, 30 insertions(+), 4 deletions(-)

diff --git a/drivers/hwmon/pmbus/pmbus_core.c b/drivers/hwmon/pmbus/pmbus_core.c
index c00bad02761a..0d75bc7b5065 100644
--- a/drivers/hwmon/pmbus/pmbus_core.c
+++ b/drivers/hwmon/pmbus/pmbus_core.c
@@ -1028,14 +1028,15 @@ static int pmbus_add_sensor_attrs_one(struct i2c_client 
*client,
  const struct pmbus_driver_info *info,
  const char *name,
  int index, int page,
- const struct pmbus_sensor_attr *attr)
+ const struct pmbus_sensor_attr *attr,
+ bool paged)
 {
struct pmbus_sensor *base;
int ret;
 
if (attr->label) {
ret = pmbus_add_label(data, name, index, attr->label,
- attr->paged ? page + 1 : 0);
+ paged ? page + 1 : 0);
if (ret)
return ret;
}
@@ -1067,6 +1068,30 @@ static int pmbus_add_sensor_attrs_one(struct i2c_client 
*client,
return 0;
 }
 
+static bool pmbus_sensor_is_paged(const struct pmbus_driver_info *info,
+ const struct pmbus_sensor_attr *attr)
+{
+   int p;
+
+   if (attr->paged)
+   return true;
+
+   /*
+* Some attributes may be present on more than one page despite
+* not being marked with the paged attribute. If that is the case,
+* then treat the sensor as being paged and add the page suffix to the
+* attribute name.
+* We don't just add the paged attribute to all such attributes, in
+* order to maintain the un-suffixed labels in the case where the
+* attribute is only on page 0.
+*/
+   for (p = 1; p < info->pages; p++) {
+   if (info->func[p] & attr->func)
+   return true;
+   }
+   return false;
+}
+
 static int pmbus_add_sensor_attrs(struct i2c_client *client,
  struct pmbus_data *data,
  const char *name,
@@ -1080,14 +1105,15 @@ static int pmbus_add_sensor_attrs(struct i2c_client 
*client,
index = 1;
for (i = 0; i < nattrs; i++) {
int page, pages;
+   bool paged = pmbus_sensor_is_paged(info, attrs);
 
-   pages = attrs->paged ? info->pages : 1;
+   pages = paged ? info->pages : 1;
for (page = 0; page < pages; page++) {
if (!(info->func[page] & attrs->func))
continue;
ret = pmbus_add_sensor_attrs_one(client, data, info,
 name, index, page,
-attrs);
+attrs, paged);
if (ret)
return ret;
index++;
-- 
2.20.1





[PATCH 4.9 015/102] net: dsa: mv88e6xxx: avoid error message on remove from VLAN 0

2019-07-08 Thread Greg Kroah-Hartman
[ Upstream commit 62394708f3e01c9f2be6be74eb6305bae1ed924f ]

When non-bridged, non-vlan'ed mv88e6xxx port is moving down, error
message is logged:

failed to kill vid 0081/0 for device eth_cu_1000_4

This is caused by call from __vlan_vid_del() with vin set to zero, over
call chain this results into _mv88e6xxx_port_vlan_del() called with
vid=0, and mv88e6xxx_vtu_get() called from there returns -EINVAL.

On symmetric path moving port up, call goes through
mv88e6xxx_port_vlan_prepare() that calls mv88e6xxx_port_check_hw_vlan()
that returns -EOPNOTSUPP for zero vid.

This patch changes mv88e6xxx_vtu_get() to also return -EOPNOTSUPP for
zero vid, then this error code is explicitly cleared in
dsa_slave_vlan_rx_kill_vid() and error message is no longer logged.

Signed-off-by: Nikita Yushchenko 
Reviewed-by: Vivien Didelot 
Signed-off-by: David S. Miller 
Signed-off-by: Sasha Levin 
---
 drivers/net/dsa/mv88e6xxx/chip.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/dsa/mv88e6xxx/chip.c b/drivers/net/dsa/mv88e6xxx/chip.c
index dc510069d37b..2edd193c96ab 100644
--- a/drivers/net/dsa/mv88e6xxx/chip.c
+++ b/drivers/net/dsa/mv88e6xxx/chip.c
@@ -1742,7 +1742,7 @@ static int _mv88e6xxx_vtu_get(struct mv88e6xxx_chip 
*chip, u16 vid,
int err;
 
if (!vid)
-   return -EINVAL;
+   return -EOPNOTSUPP;
 
err = _mv88e6xxx_vtu_vid_write(chip, vid - 1);
if (err)
-- 
2.20.1





[PATCH 4.4 34/73] 9p: p9dirent_read: check network-provided name length

2019-07-08 Thread Greg Kroah-Hartman
[ Upstream commit ef5305f1f72eb1cfcda25c382bb0368509c0385b ]

strcpy to dirent->d_name could overflow the buffer, use strscpy to check
the provided string length and error out if the size was too big.

While we are here, make the function return an error when the pdu
parsing failed, instead of returning the pdu offset as if it had been a
success...

Link: 
http://lkml.kernel.org/r/1536339057-21974-4-git-send-email-asmad...@codewreck.org
Addresses-Coverity-ID: 139133 ("Copy into fixed size buffer")
Signed-off-by: Dominique Martinet 
Signed-off-by: Sasha Levin 
---
 net/9p/protocol.c | 12 +---
 1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/net/9p/protocol.c b/net/9p/protocol.c
index 7f1b45c082c9..ed1e39ccaebf 100644
--- a/net/9p/protocol.c
+++ b/net/9p/protocol.c
@@ -622,13 +622,19 @@ int p9dirent_read(struct p9_client *clnt, char *buf, int 
len,
if (ret) {
p9_debug(P9_DEBUG_9P, "<<< p9dirent_read failed: %d\n", ret);
trace_9p_protocol_dump(clnt, _pdu);
-   goto out;
+   return ret;
}
 
-   strcpy(dirent->d_name, nameptr);
+   ret = strscpy(dirent->d_name, nameptr, sizeof(dirent->d_name));
+   if (ret < 0) {
+   p9_debug(P9_DEBUG_ERROR,
+"On the wire dirent name too long: %s\n",
+nameptr);
+   kfree(nameptr);
+   return ret;
+   }
kfree(nameptr);
 
-out:
return fake_pdu.offset;
 }
 EXPORT_SYMBOL(p9dirent_read);
-- 
2.20.1





[PATCH 4.4 73/73] dmaengine: imx-sdma: remove BD_INTR for channel0

2019-07-08 Thread Greg Kroah-Hartman
From: Robin Gong 

commit 3f93a4f297961c12bb17aa16cb3a4d1291823cae upstream.

It is possible for an irq triggered by channel0 to be received later
after clks are disabled once firmware loaded during sdma probe. If
that happens then clearing them by writing to SDMA_H_INTR won't work
and the kernel will hang processing infinite interrupts. Actually,
don't need interrupt triggered on channel0 since it's pollling
SDMA_H_STATSTOP to know channel0 done rather than interrupt in
current code, just clear BD_INTR to disable channel0 interrupt to
avoid the above case.
This issue was brought by commit 1d069bfa3c78 ("dmaengine: imx-sdma:
ack channel 0 IRQ in the interrupt handler") which didn't take care
the above case.

Fixes: 1d069bfa3c78 ("dmaengine: imx-sdma: ack channel 0 IRQ in the interrupt 
handler")
Cc: sta...@vger.kernel.org #5.0+
Signed-off-by: Robin Gong 
Reported-by: Sven Van Asbroeck 
Tested-by: Sven Van Asbroeck 
Reviewed-by: Michael Olbrich 
Signed-off-by: Vinod Koul 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/dma/imx-sdma.c |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

--- a/drivers/dma/imx-sdma.c
+++ b/drivers/dma/imx-sdma.c
@@ -614,7 +614,7 @@ static int sdma_load_script(struct sdma_
spin_lock_irqsave(>channel_0_lock, flags);
 
bd0->mode.command = C0_SETPM;
-   bd0->mode.status = BD_DONE | BD_INTR | BD_WRAP | BD_EXTD;
+   bd0->mode.status = BD_DONE | BD_WRAP | BD_EXTD;
bd0->mode.count = size / 2;
bd0->buffer_addr = buf_phys;
bd0->ext_buffer_addr = address;
@@ -883,7 +883,7 @@ static int sdma_load_context(struct sdma
context->gReg[7] = sdmac->watermark_level;
 
bd0->mode.command = C0_SETDM;
-   bd0->mode.status = BD_DONE | BD_INTR | BD_WRAP | BD_EXTD;
+   bd0->mode.status = BD_DONE | BD_WRAP | BD_EXTD;
bd0->mode.count = sizeof(*context) / 4;
bd0->buffer_addr = sdma->context_phys;
bd0->ext_buffer_addr = 2048 + (sizeof(*context) / 4) * channel;




[PATCH 4.4 35/73] net/9p: include trans_common.h to fix missing prototype warning.

2019-07-08 Thread Greg Kroah-Hartman
[ Upstream commit 52ad259eaac0454c1ac7123e7148cf8d6e6f5301 ]

This silences -Wmissing-prototypes when defining p9_release_pages.

Link: 
http://lkml.kernel.org/r/b1c4df8f21689b10d451c28fe38e860722d20e71.1542089696.git.d...@net.com.org.es
Signed-off-by: Adeodato Simó 
Signed-off-by: Dominique Martinet 
Signed-off-by: Sasha Levin 
---
 net/9p/trans_common.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/net/9p/trans_common.c b/net/9p/trans_common.c
index 38aa6345bdfa..9c0c894b56f8 100644
--- a/net/9p/trans_common.c
+++ b/net/9p/trans_common.c
@@ -14,6 +14,7 @@
 
 #include 
 #include 
+#include "trans_common.h"
 
 /**
  *  p9_release_req_pages - Release pages after the transaction.
-- 
2.20.1





[PATCH 4.9 013/102] IB/{qib, hfi1, rdmavt}: Correct ibv_devinfo max_mr value

2019-07-08 Thread Greg Kroah-Hartman
[ Upstream commit 35164f5259a47ea756fa1deb3e463ac2a4f10dc9 ]

The command 'ibv_devinfo -v' reports 0 for max_mr.

Fix by assigning the query values after the mr lkey_table has been built
rather than early on in the driver.

Fixes: 7b1e2099adc8 ("IB/rdmavt: Move memory registration into rdmavt")
Reviewed-by: Josh Collier 
Signed-off-by: Mike Marciniszyn 
Signed-off-by: Dennis Dalessandro 
Signed-off-by: Jason Gunthorpe 
Signed-off-by: Sasha Levin 
---
 drivers/infiniband/hw/hfi1/verbs.c| 2 --
 drivers/infiniband/hw/qib/qib_verbs.c | 2 --
 drivers/infiniband/sw/rdmavt/mr.c | 2 ++
 3 files changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/infiniband/hw/hfi1/verbs.c 
b/drivers/infiniband/hw/hfi1/verbs.c
index d9c71750e22d..15054a0cbf6d 100644
--- a/drivers/infiniband/hw/hfi1/verbs.c
+++ b/drivers/infiniband/hw/hfi1/verbs.c
@@ -1344,8 +1344,6 @@ static void hfi1_fill_device_attr(struct hfi1_devdata *dd)
rdi->dparms.props.max_cq = hfi1_max_cqs;
rdi->dparms.props.max_ah = hfi1_max_ahs;
rdi->dparms.props.max_cqe = hfi1_max_cqes;
-   rdi->dparms.props.max_mr = rdi->lkey_table.max;
-   rdi->dparms.props.max_fmr = rdi->lkey_table.max;
rdi->dparms.props.max_map_per_fmr = 32767;
rdi->dparms.props.max_pd = hfi1_max_pds;
rdi->dparms.props.max_qp_rd_atom = HFI1_MAX_RDMA_ATOMIC;
diff --git a/drivers/infiniband/hw/qib/qib_verbs.c 
b/drivers/infiniband/hw/qib/qib_verbs.c
index 954f15064514..d6e183775e24 100644
--- a/drivers/infiniband/hw/qib/qib_verbs.c
+++ b/drivers/infiniband/hw/qib/qib_verbs.c
@@ -1568,8 +1568,6 @@ static void qib_fill_device_attr(struct qib_devdata *dd)
rdi->dparms.props.max_cq = ib_qib_max_cqs;
rdi->dparms.props.max_cqe = ib_qib_max_cqes;
rdi->dparms.props.max_ah = ib_qib_max_ahs;
-   rdi->dparms.props.max_mr = rdi->lkey_table.max;
-   rdi->dparms.props.max_fmr = rdi->lkey_table.max;
rdi->dparms.props.max_map_per_fmr = 32767;
rdi->dparms.props.max_qp_rd_atom = QIB_MAX_RDMA_ATOMIC;
rdi->dparms.props.max_qp_init_rd_atom = 255;
diff --git a/drivers/infiniband/sw/rdmavt/mr.c 
b/drivers/infiniband/sw/rdmavt/mr.c
index 49d55a0322f6..dbd4c0d268e9 100644
--- a/drivers/infiniband/sw/rdmavt/mr.c
+++ b/drivers/infiniband/sw/rdmavt/mr.c
@@ -94,6 +94,8 @@ int rvt_driver_mr_init(struct rvt_dev_info *rdi)
for (i = 0; i < rdi->lkey_table.max; i++)
RCU_INIT_POINTER(rdi->lkey_table.table[i], NULL);
 
+   rdi->dparms.props.max_mr = rdi->lkey_table.max;
+   rdi->dparms.props.max_fmr = rdi->lkey_table.max;
return 0;
 }
 
-- 
2.20.1





[PATCH 4.9 010/102] parisc: Fix compiler warnings in float emulation code

2019-07-08 Thread Greg Kroah-Hartman
[ Upstream commit 6b98d9134e14f5ef4bcf64b27eedf484ed19a1ec ]

Avoid such compiler warnings:
arch/parisc/math-emu/cnv_float.h:71:27: warning: ‘<<’ in boolean context, did 
you mean ‘<’ ? [-Wint-in-bool-context]
 ((Dintp1(dint_valueA) << 33 - SGL_EXP_LENGTH) || Dintp2(dint_valueB))
arch/parisc/math-emu/fcnvxf.c:257:6: note: in expansion of macro 
‘Dint_isinexact_to_sgl’
  if (Dint_isinexact_to_sgl(srcp1,srcp2)) {

Signed-off-by: Helge Deller 
Signed-off-by: Sasha Levin 
---
 arch/parisc/math-emu/cnv_float.h | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/parisc/math-emu/cnv_float.h b/arch/parisc/math-emu/cnv_float.h
index 933423fa5144..b0db61188a61 100644
--- a/arch/parisc/math-emu/cnv_float.h
+++ b/arch/parisc/math-emu/cnv_float.h
@@ -60,19 +60,19 @@
 ((exponent < (SGL_P - 1)) ?\
  (Sall(sgl_value) << (SGL_EXP_LENGTH + 1 + exponent)) : FALSE)
 
-#define Int_isinexact_to_sgl(int_value)(int_value << 33 - 
SGL_EXP_LENGTH)
+#define Int_isinexact_to_sgl(int_value)((int_value << 33 - 
SGL_EXP_LENGTH) != 0)
 
 #define Sgl_roundnearest_from_int(int_value,sgl_value) \
 if (int_value & 1<<(SGL_EXP_LENGTH - 2))   /* round bit */ \
-   if ((int_value << 34 - SGL_EXP_LENGTH) || Slow(sgl_value))  \
+   if (((int_value << 34 - SGL_EXP_LENGTH) != 0) || Slow(sgl_value)) \
Sall(sgl_value)++
 
 #define Dint_isinexact_to_sgl(dint_valueA,dint_valueB) \
-((Dintp1(dint_valueA) << 33 - SGL_EXP_LENGTH) || Dintp2(dint_valueB))
+(((Dintp1(dint_valueA) << 33 - SGL_EXP_LENGTH) != 0) || 
Dintp2(dint_valueB))
 
 #define Sgl_roundnearest_from_dint(dint_valueA,dint_valueB,sgl_value)  \
 if (Dintp1(dint_valueA) & 1<<(SGL_EXP_LENGTH - 2)) 
\
-   if ((Dintp1(dint_valueA) << 34 - SGL_EXP_LENGTH) || \
+   if (((Dintp1(dint_valueA) << 34 - SGL_EXP_LENGTH) != 0) ||  \
Dintp2(dint_valueB) || Slow(sgl_value)) Sall(sgl_value)++
 
 #define Dint_isinexact_to_dbl(dint_value)  \
-- 
2.20.1





[PATCH 4.9 014/102] MIPS: uprobes: remove set but not used variable epc

2019-07-08 Thread Greg Kroah-Hartman
[ Upstream commit f532beeeff0c0a3586cc15538bc52d249eb19e7c ]

Fixes gcc '-Wunused-but-set-variable' warning:

arch/mips/kernel/uprobes.c: In function 'arch_uprobe_pre_xol':
arch/mips/kernel/uprobes.c:115:17: warning: variable 'epc' set but not used 
[-Wunused-but-set-variable]

It's never used since introduction in
commit 40e084a506eb ("MIPS: Add uprobes support.")

Signed-off-by: YueHaibing 
Signed-off-by: Paul Burton 
Cc: 
Cc: 
Cc: 
Cc: 
Signed-off-by: Sasha Levin 
---
 arch/mips/kernel/uprobes.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/arch/mips/kernel/uprobes.c b/arch/mips/kernel/uprobes.c
index dbb917403131..ec951dde0999 100644
--- a/arch/mips/kernel/uprobes.c
+++ b/arch/mips/kernel/uprobes.c
@@ -111,9 +111,6 @@ int arch_uprobe_pre_xol(struct arch_uprobe *aup, struct 
pt_regs *regs)
 */
aup->resume_epc = regs->cp0_epc + 4;
if (insn_has_delay_slot((union mips_instruction) aup->insn[0])) {
-   unsigned long epc;
-
-   epc = regs->cp0_epc;
__compute_return_epc_for_insn(regs,
(union mips_instruction) aup->insn[0]);
aup->resume_epc = regs->cp0_epc;
-- 
2.20.1





[PATCH 4.9 011/102] IB/rdmavt: Fix alloc_qpn() WARN_ON()

2019-07-08 Thread Greg Kroah-Hartman
[ Upstream commit 2abae62a26a265129b364d8c1ef3be55e2c01309 ]

The qpn allocation logic has a WARN_ON() that intends to detect the use of
an index that will introduce bits in the lower order bits of the QOS bits
in the QPN.

Unfortunately, it has the following bugs:
- it misfires when wrapping QPN allocation for non-QOS
- it doesn't correctly detect low order QOS bits (despite the comment)

The WARN_ON() should not be applied to non-QOS (qos_shift == 1).

Additionally, it SHOULD test the qpn bits per the table below:

2 data VLs:   [qp7, qp6, qp5, qp4, qp3, qp2, qp1] ^
  [  0,   0,   0,   0,   0,   0, sc0],  qp bit 1 always 0*
3-4 data VLs: [qp7, qp6, qp5, qp4, qp3, qp2, qp1] ^
  [  0,   0,   0,   0,   0, sc1, sc0], qp bits [21] always 0
5-8 data VLs: [qp7, qp6, qp5, qp4, qp3, qp2, qp1] ^
  [  0,   0,   0,   0, sc2, sc1, sc0] qp bits [321] always 0

Fix by qualifying the warning for qos_shift > 1 and producing the correct
mask to insure the above bits are zero without generating a superfluous
warning.

Fixes: 501edc42446e ("IB/rdmavt: Correct warning during QPN allocation")
Reviewed-by: Kaike Wan 
Signed-off-by: Mike Marciniszyn 
Signed-off-by: Dennis Dalessandro 
Signed-off-by: Jason Gunthorpe 
Signed-off-by: Sasha Levin 
---
 drivers/infiniband/sw/rdmavt/qp.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/infiniband/sw/rdmavt/qp.c 
b/drivers/infiniband/sw/rdmavt/qp.c
index 6500c3b5a89c..8b330b53d636 100644
--- a/drivers/infiniband/sw/rdmavt/qp.c
+++ b/drivers/infiniband/sw/rdmavt/qp.c
@@ -370,7 +370,8 @@ static int alloc_qpn(struct rvt_dev_info *rdi, struct 
rvt_qpn_table *qpt,
offset = qpt->incr | ((offset & 1) ^ 1);
}
/* there can be no set bits in low-order QoS bits */
-   WARN_ON(offset & (BIT(rdi->dparms.qos_shift) - 1));
+   WARN_ON(rdi->dparms.qos_shift > 1 &&
+   offset & ((BIT(rdi->dparms.qos_shift - 1) - 1) << 1));
qpn = mk_qpn(qpt, map, offset);
}
 
-- 
2.20.1





[PATCH 4.9 016/102] net: hns: Fix loopback test failed at copper ports

2019-07-08 Thread Greg Kroah-Hartman
[ Upstream commit 2e1f164861e500f4e068a9d909bbd3fcc7841483 ]

When doing a loopback test at copper ports, the serdes loopback
and the phy loopback will fail, because of the adjust link had
not finished, and phy not ready.

Adds sleep between adjust link and test process to fix it.

Signed-off-by: Yonglong Liu 
Signed-off-by: David S. Miller 
Signed-off-by: Sasha Levin 
---
 drivers/net/ethernet/hisilicon/hns/hns_ethtool.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/net/ethernet/hisilicon/hns/hns_ethtool.c 
b/drivers/net/ethernet/hisilicon/hns/hns_ethtool.c
index 4cd163390dcc..f38848c4f69d 100644
--- a/drivers/net/ethernet/hisilicon/hns/hns_ethtool.c
+++ b/drivers/net/ethernet/hisilicon/hns/hns_ethtool.c
@@ -367,6 +367,7 @@ static int __lb_setup(struct net_device *ndev,
 static int __lb_up(struct net_device *ndev,
   enum hnae_loop loop_mode)
 {
+#define NIC_LB_TEST_WAIT_PHY_LINK_TIME 300
struct hns_nic_priv *priv = netdev_priv(ndev);
struct hnae_handle *h = priv->ae_handle;
int speed, duplex;
@@ -393,6 +394,9 @@ static int __lb_up(struct net_device *ndev,
 
h->dev->ops->adjust_link(h, speed, duplex);
 
+   /* wait adjust link done and phy ready */
+   msleep(NIC_LB_TEST_WAIT_PHY_LINK_TIME);
+
return 0;
 }
 
-- 
2.20.1





[PATCH 4.9 012/102] IB/hfi1: Insure freeze_work work_struct is canceled on shutdown

2019-07-08 Thread Greg Kroah-Hartman
[ Upstream commit 6d517353c70bb0818b691ca003afdcb5ee5ea44e ]

By code inspection, the freeze_work is never canceled.

Fix by adding a cancel_work_sync in the shutdown path to insure it is no
longer running.

Fixes: 7724105686e7 ("IB/hfi1: add driver files")
Reviewed-by: Michael J. Ruhl 
Reviewed-by: Dennis Dalessandro 
Signed-off-by: Mike Marciniszyn 
Signed-off-by: Dennis Dalessandro 
Signed-off-by: Jason Gunthorpe 
Signed-off-by: Sasha Levin 
---
 drivers/infiniband/hw/hfi1/chip.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/infiniband/hw/hfi1/chip.c 
b/drivers/infiniband/hw/hfi1/chip.c
index d30b3b908621..85db856047a9 100644
--- a/drivers/infiniband/hw/hfi1/chip.c
+++ b/drivers/infiniband/hw/hfi1/chip.c
@@ -9620,6 +9620,7 @@ void hfi1_quiet_serdes(struct hfi1_pportdata *ppd)
 
/* disable the port */
clear_rcvctrl(dd, RCV_CTRL_RCV_PORT_ENABLE_SMASK);
+   cancel_work_sync(>freeze_work);
 }
 
 static inline int init_cpu_counters(struct hfi1_devdata *dd)
-- 
2.20.1





[PATCH 4.9 023/102] s390/qeth: fix VLAN attribute in bridge_hostnotify udev event

2019-07-08 Thread Greg Kroah-Hartman
[ Upstream commit 335726195e460cb6b3f795b695bfd31f0ea70ef0 ]

Enabling sysfs attribute bridge_hostnotify triggers a series of udev events
for the MAC addresses of all currently connected peers. In case no VLAN is
set for a peer, the device reports the corresponding MAC addresses with
VLAN ID 4096. This currently results in attribute VLAN=4096 for all
non-VLAN interfaces in the initial series of events after host-notify is
enabled.

Instead, no VLAN attribute should be reported in the udev event for
non-VLAN interfaces.

Only the initial events face this issue. For dynamic changes that are
reported later, the device uses a validity flag.

This also changes the code so that it now sets the VLAN attribute for
MAC addresses with VID 0. On Linux, no qeth interface will ever be
registered with VID 0: Linux kernel registers VID 0 on all network
interfaces initially, but qeth will drop .ndo_vlan_rx_add_vid for VID 0.
Peers with other OSs could register MACs with VID 0.

Fixes: 9f48b9db9a22 ("qeth: bridgeport support - address notifications")
Signed-off-by: Alexandra Winter 
Signed-off-by: Julian Wiedmann 
Signed-off-by: David S. Miller 
Signed-off-by: Sasha Levin 
---
 drivers/s390/net/qeth_l2_main.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/s390/net/qeth_l2_main.c b/drivers/s390/net/qeth_l2_main.c
index 58404e69aa4b..6ba4e921d2fd 100644
--- a/drivers/s390/net/qeth_l2_main.c
+++ b/drivers/s390/net/qeth_l2_main.c
@@ -2124,7 +2124,7 @@ static void qeth_bridgeport_an_set_cb(void *priv,
 
l2entry = (struct qdio_brinfo_entry_l2 *)entry;
code = IPA_ADDR_CHANGE_CODE_MACADDR;
-   if (l2entry->addr_lnid.lnid)
+   if (l2entry->addr_lnid.lnid < VLAN_N_VID)
code |= IPA_ADDR_CHANGE_CODE_VLANID;
qeth_bridge_emit_host_event(card, anev_reg_unreg, code,
(struct net_if_token *)>nit,
-- 
2.20.1





[PATCH 4.9 022/102] scsi: ufs: Check that space was properly alloced in copy_query_response

2019-07-08 Thread Greg Kroah-Hartman
[ Upstream commit 1c90836f70f9a8ef7b7ad9e1fdd8961903e6ced6 ]

struct ufs_dev_cmd is the main container that supports device management
commands. In the case of a read descriptor request, we assume that the
proper space was allocated in dev_cmd to hold the returning descriptor.

This is no longer true, as there are flows that doesn't use dev_cmd for
device management requests, and was wrong in the first place.

Fixes: d44a5f98bb49 (ufs: query descriptor API)
Signed-off-by: Avri Altman 
Reviewed-by: Alim Akhtar 
Acked-by: Bean Huo 
Signed-off-by: Martin K. Petersen 
Signed-off-by: Sasha Levin 
---
 drivers/scsi/ufs/ufshcd.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
index 0fe4f8e8c8c9..a9c172692f21 100644
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -941,7 +941,8 @@ int ufshcd_copy_query_response(struct ufs_hba *hba, struct 
ufshcd_lrb *lrbp)
memcpy(_res->upiu_res, >ucd_rsp_ptr->qr, QUERY_OSF_SIZE);
 
/* Get the descriptor */
-   if (lrbp->ucd_rsp_ptr->qr.opcode == UPIU_QUERY_OPCODE_READ_DESC) {
+   if (hba->dev_cmd.query.descriptor &&
+   lrbp->ucd_rsp_ptr->qr.opcode == UPIU_QUERY_OPCODE_READ_DESC) {
u8 *descp = (u8 *)lrbp->ucd_rsp_ptr +
GENERAL_UPIU_REQUEST_SIZE;
u16 resp_len;
-- 
2.20.1





[PATCH 4.9 018/102] net: ethernet: mediatek: Use hw_feature to judge if HWLRO is supported

2019-07-08 Thread Greg Kroah-Hartman
[ Upstream commit 9e4f56f1a7f3287718d0083b5cb85298dc05a5fd ]

Should hw_feature as hardware capability flags to check if hardware LRO
got support.

Signed-off-by: Mark Lee 
Signed-off-by: Sean Wang 
Signed-off-by: David S. Miller 
Signed-off-by: Sasha Levin 
---
 drivers/net/ethernet/mediatek/mtk_eth_soc.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.c 
b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
index 20de37a414fe..03b599109619 100644
--- a/drivers/net/ethernet/mediatek/mtk_eth_soc.c
+++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
@@ -2175,13 +2175,13 @@ static int mtk_get_rxnfc(struct net_device *dev, struct 
ethtool_rxnfc *cmd,
 
switch (cmd->cmd) {
case ETHTOOL_GRXRINGS:
-   if (dev->features & NETIF_F_LRO) {
+   if (dev->hw_features & NETIF_F_LRO) {
cmd->data = MTK_MAX_RX_RING_NUM;
ret = 0;
}
break;
case ETHTOOL_GRXCLSRLCNT:
-   if (dev->features & NETIF_F_LRO) {
+   if (dev->hw_features & NETIF_F_LRO) {
struct mtk_mac *mac = netdev_priv(dev);
 
cmd->rule_cnt = mac->hwlro_ip_cnt;
@@ -2189,11 +2189,11 @@ static int mtk_get_rxnfc(struct net_device *dev, struct 
ethtool_rxnfc *cmd,
}
break;
case ETHTOOL_GRXCLSRULE:
-   if (dev->features & NETIF_F_LRO)
+   if (dev->hw_features & NETIF_F_LRO)
ret = mtk_hwlro_get_fdir_entry(dev, cmd);
break;
case ETHTOOL_GRXCLSRLALL:
-   if (dev->features & NETIF_F_LRO)
+   if (dev->hw_features & NETIF_F_LRO)
ret = mtk_hwlro_get_fdir_all(dev, cmd,
 rule_locs);
break;
@@ -2210,11 +2210,11 @@ static int mtk_set_rxnfc(struct net_device *dev, struct 
ethtool_rxnfc *cmd)
 
switch (cmd->cmd) {
case ETHTOOL_SRXCLSRLINS:
-   if (dev->features & NETIF_F_LRO)
+   if (dev->hw_features & NETIF_F_LRO)
ret = mtk_hwlro_add_ipaddr(dev, cmd);
break;
case ETHTOOL_SRXCLSRLDEL:
-   if (dev->features & NETIF_F_LRO)
+   if (dev->hw_features & NETIF_F_LRO)
ret = mtk_hwlro_del_ipaddr(dev, cmd);
break;
default:
-- 
2.20.1





[PATCH v2] kernfs: fix potential null pointer dereference

2019-07-08 Thread Peng Wang
Get root safely after kn is ensureed to be not null.

Signed-off-by: Peng Wang 
---
 fs/kernfs/dir.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/fs/kernfs/dir.c b/fs/kernfs/dir.c
index a387534c9577..ddf537923a0a 100644
--- a/fs/kernfs/dir.c
+++ b/fs/kernfs/dir.c
@@ -430,7 +430,6 @@ struct kernfs_node *kernfs_get_active(struct kernfs_node 
*kn)
  */
 void kernfs_put_active(struct kernfs_node *kn)
 {
-   struct kernfs_root *root = kernfs_root(kn);
int v;
 
if (unlikely(!kn))
@@ -442,7 +441,7 @@ void kernfs_put_active(struct kernfs_node *kn)
if (likely(v != KN_DEACTIVATED_BIAS))
return;
 
-   wake_up_all(>deactivate_waitq);
+   wake_up_all(_root(kn)->deactivate_waitq);
 }
 
 /**
-- 
2.19.1



[PATCH 4.9 019/102] net: ethernet: mediatek: Use NET_IP_ALIGN to judge if HW RX_2BYTE_OFFSET is enabled

2019-07-08 Thread Greg Kroah-Hartman
[ Upstream commit 880c2d4b2fdfd580ebcd6bb7240a8027a1d34751 ]

Should only enable HW RX_2BYTE_OFFSET function in the case NET_IP_ALIGN
equals to 2.

Signed-off-by: Mark Lee 
Signed-off-by: Sean Wang 
Signed-off-by: David S. Miller 
Signed-off-by: Sasha Levin 
---
 drivers/net/ethernet/mediatek/mtk_eth_soc.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.c 
b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
index 03b599109619..d10c8a8156bc 100644
--- a/drivers/net/ethernet/mediatek/mtk_eth_soc.c
+++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
@@ -1700,6 +1700,7 @@ static void mtk_poll_controller(struct net_device *dev)
 
 static int mtk_start_dma(struct mtk_eth *eth)
 {
+   u32 rx_2b_offset = (NET_IP_ALIGN == 2) ? MTK_RX_2B_OFFSET : 0;
int err;
 
err = mtk_dma_init(eth);
@@ -1714,7 +1715,7 @@ static int mtk_start_dma(struct mtk_eth *eth)
MTK_QDMA_GLO_CFG);
 
mtk_w32(eth,
-   MTK_RX_DMA_EN | MTK_RX_2B_OFFSET |
+   MTK_RX_DMA_EN | rx_2b_offset |
MTK_RX_BT_32DWORDS | MTK_MULTI_EN,
MTK_PDMA_GLO_CFG);
 
-- 
2.20.1





[PATCH 4.4 61/73] MIPS: Workaround GCC __builtin_unreachable reordering bug

2019-07-08 Thread Greg Kroah-Hartman
[ Upstream commit 906d441febc0de974b2a6ef848a8f058f3bfada3 ]

Some versions of GCC for the MIPS architecture suffer from a bug which
can lead to instructions from beyond an unreachable statement being
incorrectly reordered into earlier branch delay slots if the unreachable
statement is the only content of a case in a switch statement. This can
lead to seemingly random behaviour, such as invalid memory accesses from
incorrectly reordered loads or stores, and link failures on microMIPS
builds.

See this potential GCC fix for details:

https://gcc.gnu.org/ml/gcc-patches/2015-09/msg00360.html

Runtime problems resulting from this bug were initially observed using a
maltasmvp_defconfig v4.4 kernel built using GCC 4.9.2 (from a Codescape
SDK 2015.06-05 toolchain), with the result being an address exception
taken after log messages about the L1 caches (during probe of the L2
cache):

Initmem setup node 0 [mem 0x8000-0x9fff]
VPE topology {2,2} total 4
Primary instruction cache 64kB, VIPT, 4-way, linesize 32 bytes.
Primary data cache 64kB, 4-way, PIPT, no aliases, linesize 32 bytes


This is early enough that the kernel exception vectors are not in use,
so any further output depends upon the bootloader. This is reproducible
in QEMU where no further output occurs - ie. the system hangs here.
Given the nature of the bug it may potentially be hit with differing
symptoms. The bug is known to affect GCC versions as recent as 7.3, and
it is unclear whether GCC 8 fixed it or just happens not to encounter
the bug in the testcase found at the link above due to differing
optimizations.

This bug can be worked around by placing a volatile asm statement, which
GCC is prevented from reordering past, prior to the
__builtin_unreachable call.

That was actually done already for other reasons by commit 173a3efd3edb
("bug.h: work around GCC PR82365 in BUG()"), but creates problems for
microMIPS builds due to the lack of a .insn directive. The microMIPS ISA
allows for interlinking with regular MIPS32 code by repurposing bit 0 of
the program counter as an ISA mode bit. To switch modes one changes the
value of this bit in the PC. However typical branch instructions encode
their offsets as multiples of 2-byte instruction halfwords, which means
they cannot change ISA mode - this must be done using either an indirect
branch (a jump-register in MIPS terminology) or a dedicated jalx
instruction. In order to ensure that regular branches don't attempt to
target code in a different ISA which they can't actually switch to, the
linker will check that branch targets are code in the same ISA as the
branch.

Unfortunately our empty asm volatile statements don't qualify as code,
and the link for microMIPS builds fails with errors such as:

arch/mips/mm/dma-default.s:3265: Error: branch to a symbol in another ISA 
mode
arch/mips/mm/dma-default.s:5027: Error: branch to a symbol in another ISA 
mode

Resolve this by adding a .insn directive within the asm statement which
declares that what comes next is code. This may or may not be true,
since we don't really know what comes next, but as this code is in an
unreachable path anyway that doesn't matter since we won't execute it.

We do this in asm/compiler.h & select CONFIG_HAVE_ARCH_COMPILER_H in
order to have this included by linux/compiler_types.h after
linux/compiler-gcc.h. This will result in asm/compiler.h being included
in all C compilations via the -include linux/compiler_types.h argument
in c_flags, which should be harmless.

Signed-off-by: Paul Burton 
Fixes: 173a3efd3edb ("bug.h: work around GCC PR82365 in BUG()")
Patchwork: https://patchwork.linux-mips.org/patch/20270/
Cc: James Hogan 
Cc: Ralf Baechle 
Cc: Arnd Bergmann 
Cc: linux-m...@linux-mips.org
Signed-off-by: Sasha Levin 
---
 arch/mips/Kconfig|  1 +
 arch/mips/include/asm/compiler.h | 35 
 2 files changed, 36 insertions(+)

diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
index 333ea0389adb..687a3eb8d4d9 100644
--- a/arch/mips/Kconfig
+++ b/arch/mips/Kconfig
@@ -13,6 +13,7 @@ config MIPS
select HAVE_OPROFILE
select HAVE_PERF_EVENTS
select PERF_USE_VMALLOC
+   select HAVE_ARCH_COMPILER_H
select HAVE_ARCH_KGDB
select HAVE_ARCH_SECCOMP_FILTER
select HAVE_ARCH_TRACEHOOK
diff --git a/arch/mips/include/asm/compiler.h b/arch/mips/include/asm/compiler.h
index e081a265f422..cc2eb1b06050 100644
--- a/arch/mips/include/asm/compiler.h
+++ b/arch/mips/include/asm/compiler.h
@@ -8,6 +8,41 @@
 #ifndef _ASM_COMPILER_H
 #define _ASM_COMPILER_H
 
+/*
+ * With GCC 4.5 onwards we can use __builtin_unreachable to indicate to the
+ * compiler that a particular code path will never be hit. This allows it to be
+ * optimised out of the generated binary.
+ *
+ * Unfortunately at least GCC 4.6.3 through 7.3.0 inclusive suffer from a bug
+ * that can lead to instructions from beyond an unreachable 

[PATCH 4.4 32/73] 9p: acl: fix uninitialized iattr access

2019-07-08 Thread Greg Kroah-Hartman
[ Upstream commit e02a53d92e197706cad1627bd84705d4aa20a145 ]

iattr is passed to v9fs_vfs_setattr_dotl which does send various
values from iattr over the wire, even if it tells the server to
only look at iattr.ia_valid fields this could leak some stack data.

Link: 
http://lkml.kernel.org/r/1536339057-21974-2-git-send-email-asmad...@codewreck.org
Addresses-Coverity-ID: 1195601 ("Uninitalized scalar variable")
Signed-off-by: Dominique Martinet 
Signed-off-by: Sasha Levin 
---
 fs/9p/acl.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs/9p/acl.c b/fs/9p/acl.c
index c30c6ceac2c4..d02ee4026e32 100644
--- a/fs/9p/acl.c
+++ b/fs/9p/acl.c
@@ -282,7 +282,7 @@ static int v9fs_xattr_set_acl(const struct xattr_handler 
*handler,
switch (handler->flags) {
case ACL_TYPE_ACCESS:
if (acl) {
-   struct iattr iattr;
+   struct iattr iattr = { 0 };
struct posix_acl *old_acl = acl;
 
retval = posix_acl_update_mode(inode, _mode, 
);
-- 
2.20.1





[PATCH 4.4 69/73] tty: rocket: fix incorrect forward declaration of rp_init()

2019-07-08 Thread Greg Kroah-Hartman
[ Upstream commit 423ea3255424b954947d167681b71ded1b8fca53 ]

Make the forward declaration actually match the real function
definition, something that previous versions of gcc had just ignored.

This is another patch to fix new warnings from gcc-9 before I start the
merge window pulls.  I don't want to miss legitimate new warnings just
because my system update brought a new compiler with new warnings.

Signed-off-by: Linus Torvalds 
Signed-off-by: Sasha Levin 
---
 drivers/tty/rocket.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/tty/rocket.c b/drivers/tty/rocket.c
index 2b8f2e0a4224..ec6d20f25e8b 100644
--- a/drivers/tty/rocket.c
+++ b/drivers/tty/rocket.c
@@ -279,7 +279,7 @@ MODULE_PARM_DESC(pc104_3, "set interface types for 
ISA(PC104) board #3 (e.g. pc1
 module_param_array(pc104_4, ulong, NULL, 0);
 MODULE_PARM_DESC(pc104_4, "set interface types for ISA(PC104) board #4 (e.g. 
pc104_4=232,232,485,485,...");
 
-static int rp_init(void);
+static int __init rp_init(void);
 static void rp_cleanup_module(void);
 
 module_init(rp_init);
-- 
2.20.1





[PATCH 4.4 31/73] 9p/rdma: do not disconnect on down_interruptible EAGAIN

2019-07-08 Thread Greg Kroah-Hartman
[ Upstream commit 8b894adb2b7e1d1e64b8954569c761eaf3d51ab5 ]

9p/rdma would sometimes drop the connection and display errors in
recv_done when the user does ^C.
The errors were caused by recv buffers that were posted at the time
of disconnect, and we just do not want to disconnect when
down_interruptible is... interrupted.

Link: 
http://lkml.kernel.org/r/1535625307-18019-1-git-send-email-asmad...@codewreck.org
Signed-off-by: Dominique Martinet 
Signed-off-by: Sasha Levin 
---
 net/9p/trans_rdma.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/net/9p/trans_rdma.c b/net/9p/trans_rdma.c
index f42550dd3560..f3a9254b6df9 100644
--- a/net/9p/trans_rdma.c
+++ b/net/9p/trans_rdma.c
@@ -476,7 +476,7 @@ static int rdma_request(struct p9_client *client, struct 
p9_req_t *req)
 
err = post_recv(client, rpl_context);
if (err) {
-   p9_debug(P9_DEBUG_FCALL, "POST RECV failed\n");
+   p9_debug(P9_DEBUG_ERROR, "POST RECV failed: %d\n", err);
goto recv_error;
}
/* remove posted receive buffer from request structure */
@@ -544,7 +544,7 @@ static int rdma_request(struct p9_client *client, struct 
p9_req_t *req)
  recv_error:
kfree(rpl_context);
spin_lock_irqsave(>req_lock, flags);
-   if (rdma->state < P9_RDMA_CLOSING) {
+   if (err != -EINTR && rdma->state < P9_RDMA_CLOSING) {
rdma->state = P9_RDMA_CLOSING;
spin_unlock_irqrestore(>req_lock, flags);
rdma_disconnect(rdma->cm_id);
-- 
2.20.1





[PATCH 4.4 72/73] KVM: x86: degrade WARN to pr_warn_ratelimited

2019-07-08 Thread Greg Kroah-Hartman
From: Paolo Bonzini 

commit 3f16a5c318392cbb5a0c7a3d19dff8c8ef3c38ee upstream.

This warning can be triggered easily by userspace, so it should certainly not
cause a panic if panic_on_warn is set.

Reported-by: syzbot+c03f30b4f4c46bdf8...@syzkaller.appspotmail.com
Suggested-by: Alexander Potapenko 
Acked-by: Alexander Potapenko 
Signed-off-by: Paolo Bonzini 
Signed-off-by: Greg Kroah-Hartman 

---
 arch/x86/kvm/x86.c |6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -1293,7 +1293,7 @@ static int set_tsc_khz(struct kvm_vcpu *
vcpu->arch.tsc_always_catchup = 1;
return 0;
} else {
-   WARN(1, "user requested TSC rate below hardware 
speed\n");
+   pr_warn_ratelimited("user requested TSC rate below 
hardware speed\n");
return -1;
}
}
@@ -1303,8 +1303,8 @@ static int set_tsc_khz(struct kvm_vcpu *
user_tsc_khz, tsc_khz);
 
if (ratio == 0 || ratio >= kvm_max_tsc_scaling_ratio) {
-   WARN_ONCE(1, "Invalid TSC scaling ratio - virtual-tsc-khz=%u\n",
- user_tsc_khz);
+   pr_warn_ratelimited("Invalid TSC scaling ratio - 
virtual-tsc-khz=%u\n",
+   user_tsc_khz);
return -1;
}
 




[PATCH 4.4 68/73] btrfs: Ensure replaced device doesnt have pending chunk allocation

2019-07-08 Thread Greg Kroah-Hartman
From: Nikolay Borisov 

commit debd1c065d2037919a7da67baf55cc683fee09f0 upstream.

Recent FITRIM work, namely bbbf7243d62d ("btrfs: combine device update
operations during transaction commit") combined the way certain
operations are recoded in a transaction. As a result an ASSERT was added
in dev_replace_finish to ensure the new code works correctly.
Unfortunately I got reports that it's possible to trigger the assert,
meaning that during a device replace it's possible to have an unfinished
chunk allocation on the source device.

This is supposed to be prevented by the fact that a transaction is
committed before finishing the replace oepration and alter acquiring the
chunk mutex. This is not sufficient since by the time the transaction is
committed and the chunk mutex acquired it's possible to allocate a chunk
depending on the workload being executed on the replaced device. This
bug has been present ever since device replace was introduced but there
was never code which checks for it.

The correct way to fix is to ensure that there is no pending device
modification operation when the chunk mutex is acquire and if there is
repeat transaction commit. Unfortunately it's not possible to just
exclude the source device from btrfs_fs_devices::dev_alloc_list since
this causes ENOSPC to be hit in transaction commit.

Fixing that in another way would need to add special cases to handle the
last writes and forbid new ones. The looped transaction fix is more
obvious, and can be easily backported. The runtime of dev-replace is
long so there's no noticeable delay caused by that.

Reported-by: David Sterba 
Fixes: 391cd9df81ac ("Btrfs: fix unprotected alloc list insertion during the 
finishing procedure of replace")
CC: sta...@vger.kernel.org # 4.4+
Signed-off-by: Nikolay Borisov 
Reviewed-by: David Sterba 
Signed-off-by: David Sterba 
Signed-off-by: Greg Kroah-Hartman 

---
 fs/btrfs/dev-replace.c |   29 +++--
 fs/btrfs/volumes.c |2 ++
 fs/btrfs/volumes.h |5 +
 3 files changed, 26 insertions(+), 10 deletions(-)

--- a/fs/btrfs/dev-replace.c
+++ b/fs/btrfs/dev-replace.c
@@ -495,18 +495,27 @@ static int btrfs_dev_replace_finishing(s
}
btrfs_wait_ordered_roots(root->fs_info, -1);
 
-   trans = btrfs_start_transaction(root, 0);
-   if (IS_ERR(trans)) {
-   mutex_unlock(_replace->lock_finishing_cancel_unmount);
-   return PTR_ERR(trans);
+   while (1) {
+   trans = btrfs_start_transaction(root, 0);
+   if (IS_ERR(trans)) {
+   
mutex_unlock(_replace->lock_finishing_cancel_unmount);
+   return PTR_ERR(trans);
+   }
+   ret = btrfs_commit_transaction(trans, root);
+   WARN_ON(ret);
+   mutex_lock(_mutex);
+   /* keep away write_all_supers() during the finishing procedure 
*/
+   mutex_lock(>fs_info->fs_devices->device_list_mutex);
+   mutex_lock(>fs_info->chunk_mutex);
+   if (src_device->has_pending_chunks) {
+   mutex_unlock(>fs_info->chunk_mutex);
+   
mutex_unlock(>fs_info->fs_devices->device_list_mutex);
+   mutex_unlock(_mutex);
+   } else {
+   break;
+   }
}
-   ret = btrfs_commit_transaction(trans, root);
-   WARN_ON(ret);
 
-   mutex_lock(_mutex);
-   /* keep away write_all_supers() during the finishing procedure */
-   mutex_lock(>fs_info->fs_devices->device_list_mutex);
-   mutex_lock(>fs_info->chunk_mutex);
btrfs_dev_replace_lock(dev_replace);
dev_replace->replace_state =
scrub_ret ? BTRFS_IOCTL_DEV_REPLACE_STATE_CANCELED
--- a/fs/btrfs/volumes.c
+++ b/fs/btrfs/volumes.c
@@ -4760,6 +4760,7 @@ static int __btrfs_alloc_chunk(struct bt
for (i = 0; i < map->num_stripes; i++) {
num_bytes = map->stripes[i].dev->bytes_used + stripe_size;
btrfs_device_set_bytes_used(map->stripes[i].dev, num_bytes);
+   map->stripes[i].dev->has_pending_chunks = true;
}
 
spin_lock(_root->fs_info->free_chunk_lock);
@@ -7064,6 +7065,7 @@ void btrfs_update_commit_device_bytes_us
for (i = 0; i < map->num_stripes; i++) {
dev = map->stripes[i].dev;
dev->commit_bytes_used = dev->bytes_used;
+   dev->has_pending_chunks = false;
}
}
unlock_chunks(root);
--- a/fs/btrfs/volumes.h
+++ b/fs/btrfs/volumes.h
@@ -62,6 +62,11 @@ struct btrfs_device {
 
spinlock_t io_lock cacheline_aligned;
int running_pending;
+   /* When true means this device has pending chunk alloc in
+* current transaction. Protected by chunk_mutex.
+*/
+   bool has_pending_chunks;
+
/* regular prio bios */
struct 

[PATCH 4.4 66/73] ALSA: usb-audio: fix sign unintended sign extension on left shifts

2019-07-08 Thread Greg Kroah-Hartman
From: Colin Ian King 

commit 2acf5a3e6e9371e63c9e4ff54d84d08f630467a0 upstream.

There are a couple of left shifts of unsigned 8 bit values that
first get promoted to signed ints and hence get sign extended
on the shift if the top bit of the 8 bit values are set. Fix
this by casting the 8 bit values to unsigned ints to stop the
unintentional sign extension.

Addresses-Coverity: ("Unintended sign extension")
Signed-off-by: Colin Ian King 
Cc: 
Signed-off-by: Takashi Iwai 
Signed-off-by: Greg Kroah-Hartman 

---
 sound/usb/mixer_quirks.c |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

--- a/sound/usb/mixer_quirks.c
+++ b/sound/usb/mixer_quirks.c
@@ -753,7 +753,7 @@ static int snd_ni_control_init_val(struc
return err;
}
 
-   kctl->private_value |= (value << 24);
+   kctl->private_value |= ((unsigned int)value << 24);
return 0;
 }
 
@@ -914,7 +914,7 @@ static int snd_ftu_eff_switch_init(struc
if (err < 0)
return err;
 
-   kctl->private_value |= value[0] << 24;
+   kctl->private_value |= (unsigned int)value[0] << 24;
return 0;
 }
 




[PATCH 4.4 30/73] perf help: Remove needless use of strncpy()

2019-07-08 Thread Greg Kroah-Hartman
From: Arnaldo Carvalho de Melo 

commit b6313899f4ed2e76b8375cf8069556f5b94fbff0 upstream.

Since we make sure the destination buffer has at least strlen(orig) + 1,
no need to do a strncpy(dest, orig, strlen(orig)), just use strcpy(dest,
orig).

This silences this gcc 8.2 warning on Alpine Linux:

  In function 'add_man_viewer',
  inlined from 'perf_help_config' at builtin-help.c:284:3:
  builtin-help.c:192:2: error: 'strncpy' output truncated before terminating 
nul copying as many bytes from a string as its length 
[-Werror=stringop-truncation]
strncpy((*p)->name, name, len);
^~
  builtin-help.c: In function 'perf_help_config':
  builtin-help.c:187:15: note: length computed here
size_t len = strlen(name);
 ^~~~

Cc: Adrian Hunter 
Cc: Jiri Olsa 
Cc: Namhyung Kim 
Fixes: 078006012401 ("perf_counter tools: add in basic glue from Git")
Link: https://lkml.kernel.org/n/tip-2f69l7drca427ob4km8i7...@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo 
Signed-off-by: Greg Kroah-Hartman 

---
 tools/perf/builtin-help.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/tools/perf/builtin-help.c
+++ b/tools/perf/builtin-help.c
@@ -179,7 +179,7 @@ static void add_man_viewer(const char *n
while (*p)
p = &((*p)->next);
*p = zalloc(sizeof(**p) + len + 1);
-   strncpy((*p)->name, name, len);
+   strcpy((*p)->name, name);
 }
 
 static int supported_man_viewer(const char *name, size_t len)




[PATCH 4.4 67/73] lib/mpi: Fix karactx leak in mpi_powm

2019-07-08 Thread Greg Kroah-Hartman
From: Herbert Xu 

commit c8ea9fce2baf7b643384f36f29e4194fa40d33a6 upstream.

Sometimes mpi_powm will leak karactx because a memory allocation
failure causes a bail-out that skips the freeing of karactx.  This
patch moves the freeing of karactx to the end of the function like
everything else so that it can't be skipped.

Reported-by: syzbot+f7baccc38dcc1e094...@syzkaller.appspotmail.com
Fixes: cdec9cb5167a ("crypto: GnuPG based MPI lib - source files...")
Cc: 
Signed-off-by: Herbert Xu 
Reviewed-by: Eric Biggers 
Signed-off-by: Herbert Xu 
Signed-off-by: Greg Kroah-Hartman 

---
 lib/mpi/mpi-pow.c |6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

--- a/lib/mpi/mpi-pow.c
+++ b/lib/mpi/mpi-pow.c
@@ -37,6 +37,7 @@
 int mpi_powm(MPI res, MPI base, MPI exp, MPI mod)
 {
mpi_ptr_t mp_marker = NULL, bp_marker = NULL, ep_marker = NULL;
+   struct karatsuba_ctx karactx = {};
mpi_ptr_t xp_marker = NULL;
mpi_ptr_t tspace = NULL;
mpi_ptr_t rp, ep, mp, bp;
@@ -164,13 +165,11 @@ int mpi_powm(MPI res, MPI base, MPI exp,
int c;
mpi_limb_t e;
mpi_limb_t carry_limb;
-   struct karatsuba_ctx karactx;
 
xp = xp_marker = mpi_alloc_limb_space(2 * (msize + 1));
if (!xp)
goto enomem;
 
-   memset(, 0, sizeof karactx);
negative_result = (ep[0] & 1) && base->sign;
 
i = esize - 1;
@@ -295,8 +294,6 @@ int mpi_powm(MPI res, MPI base, MPI exp,
if (mod_shift_cnt)
mpihelp_rshift(rp, rp, rsize, mod_shift_cnt);
MPN_NORMALIZE(rp, rsize);
-
-   mpihelp_release_karatsuba_ctx();
}
 
if (negative_result && rsize) {
@@ -313,6 +310,7 @@ int mpi_powm(MPI res, MPI base, MPI exp,
 leave:
rc = 0;
 enomem:
+   mpihelp_release_karatsuba_ctx();
if (assign_rp)
mpi_assign_limb_space(res, rp, size);
if (mp_marker)




[PATCH 4.4 70/73] ARC: handle gcc generated __builtin_trap for older compiler

2019-07-08 Thread Greg Kroah-Hartman
From: Vineet Gupta 

commit af1be2e21203867cb958aaceed5366e2e24b88e8 upstream.

ARC gcc prior to GNU 2018.03 release didn't have a target specific
__builtin_trap() implementation, generating default abort() call.

Implement the abort() call - emulating what newer gcc does for the same,
as suggested by Arnd.

Acked-by: Arnd Bergmann 
Signed-off-by: Vineet Gupta 
Signed-off-by: Greg Kroah-Hartman 

---
 arch/arc/kernel/traps.c |8 
 1 file changed, 8 insertions(+)

--- a/arch/arc/kernel/traps.c
+++ b/arch/arc/kernel/traps.c
@@ -155,3 +155,11 @@ void do_insterror_or_kprobe(unsigned lon
 
insterror_is_error(address, regs);
 }
+
+/*
+ * abort() call generated by older gcc for __builtin_trap()
+ */
+void abort(void)
+{
+   __asm__ __volatile__("trap_s  5\n");
+}




[PATCH 4.4 65/73] ALSA: firewire-lib/fireworks: fix miss detection of received MIDI messages

2019-07-08 Thread Greg Kroah-Hartman
From: Takashi Sakamoto 

commit 7fbd1753b64eafe21cf842348a40a691d0dee440 upstream.

In IEC 61883-6, 8 MIDI data streams are multiplexed into single
MIDI conformant data channel. The index of stream is calculated by
modulo 8 of the value of data block counter.

In fireworks, the value of data block counter in CIP header has a quirk
with firmware version v5.0.0, v5.7.3 and v5.8.0. This brings ALSA
IEC 61883-1/6 packet streaming engine to miss detection of MIDI
messages.

This commit fixes the miss detection to modify the value of data block
counter for the modulo calculation.

For maintainers, this bug exists since a commit 18f5ed365d3f ("ALSA:
fireworks/firewire-lib: add support for recent firmware quirk") in Linux
kernel v4.2. There're many changes since the commit.  This fix can be
backported to Linux kernel v4.4 or later. I tagged a base commit to the
backport for your convenience.

Besides, my work for Linux kernel v5.3 brings heavy code refactoring and
some structure members are renamed in 'sound/firewire/amdtp-stream.h'.
The content of this patch brings conflict when merging -rc tree with
this patch and the latest tree. I request maintainers to solve the
conflict to replace 'tx_first_dbc' with 'ctx_data.tx.first_dbc'.

Fixes: df075feefbd3 ("ALSA: firewire-lib: complete AM824 data block processing 
layer")
Cc:  # v4.4+
Signed-off-by: Takashi Sakamoto 
Signed-off-by: Takashi Iwai 
Signed-off-by: Greg Kroah-Hartman 

---
 sound/firewire/amdtp-am824.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/sound/firewire/amdtp-am824.c
+++ b/sound/firewire/amdtp-am824.c
@@ -388,7 +388,7 @@ static void read_midi_messages(struct am
u8 *b;
 
for (f = 0; f < frames; f++) {
-   port = (s->data_block_counter + f) % 8;
+   port = (8 - s->tx_first_dbc + s->data_block_counter + f) % 8;
b = (u8 *)[p->midi_position];
 
len = b[0] - 0x80;




[PATCH 4.4 63/73] crypto: user - prevent operating on larval algorithms

2019-07-08 Thread Greg Kroah-Hartman
From: Eric Biggers 

commit 21d4120ec6f5b5992b01b96ac484701163917b63 upstream.

Michal Suchanek reported [1] that running the pcrypt_aead01 test from
LTP [2] in a loop and holding Ctrl-C causes a NULL dereference of
alg->cra_users.next in crypto_remove_spawns(), via crypto_del_alg().
The test repeatedly uses CRYPTO_MSG_NEWALG and CRYPTO_MSG_DELALG.

The crash occurs when the instance that CRYPTO_MSG_DELALG is trying to
unregister isn't a real registered algorithm, but rather is a "test
larval", which is a special "algorithm" added to the algorithms list
while the real algorithm is still being tested.  Larvals don't have
initialized cra_users, so that causes the crash.  Normally pcrypt_aead01
doesn't trigger this because CRYPTO_MSG_NEWALG waits for the algorithm
to be tested; however, CRYPTO_MSG_NEWALG returns early when interrupted.

Everything else in the "crypto user configuration" API has this same bug
too, i.e. it inappropriately allows operating on larval algorithms
(though it doesn't look like the other cases can cause a crash).

Fix this by making crypto_alg_match() exclude larval algorithms.

[1] https://lkml.kernel.org/r/20190625071624.27039-1-msucha...@suse.de
[2] 
https://github.com/linux-test-project/ltp/blob/20190517/testcases/kernel/crypto/pcrypt_aead01.c

Reported-by: Michal Suchanek 
Fixes: a38f7907b926 ("crypto: Add userspace configuration API")
Cc:  # v3.2+
Cc: Steffen Klassert 
Signed-off-by: Eric Biggers 
Signed-off-by: Herbert Xu 
Signed-off-by: Greg Kroah-Hartman 

---
 crypto/crypto_user.c |3 +++
 1 file changed, 3 insertions(+)

--- a/crypto/crypto_user.c
+++ b/crypto/crypto_user.c
@@ -54,6 +54,9 @@ static struct crypto_alg *crypto_alg_mat
list_for_each_entry(q, _alg_list, cra_list) {
int match = 0;
 
+   if (crypto_is_larval(q))
+   continue;
+
if ((q->cra_flags ^ p->cru_type) & p->cru_mask)
continue;
 




[PATCH 4.4 60/73] bug.h: work around GCC PR82365 in BUG()

2019-07-08 Thread Greg Kroah-Hartman
[ Upstream commit 173a3efd3edb2ef6ef07471397c5f542a360e9c1 ]

Looking at functions with large stack frames across all architectures
led me discovering that BUG() suffers from the same problem as
fortify_panic(), which I've added a workaround for already.

In short, variables that go out of scope by calling a noreturn function
or __builtin_unreachable() keep using stack space in functions
afterwards.

A workaround that was identified is to insert an empty assembler
statement just before calling the function that doesn't return.  I'm
adding a macro "barrier_before_unreachable()" to document this, and
insert calls to that in all instances of BUG() that currently suffer
from this problem.

The files that saw the largest change from this had these frame sizes
before, and much less with my patch:

  fs/ext4/inode.c:82:1: warning: the frame size of 1672 bytes is larger than 
800 bytes [-Wframe-larger-than=]
  fs/ext4/namei.c:434:1: warning: the frame size of 904 bytes is larger than 
800 bytes [-Wframe-larger-than=]
  fs/ext4/super.c:2279:1: warning: the frame size of 1160 bytes is larger than 
800 bytes [-Wframe-larger-than=]
  fs/ext4/xattr.c:146:1: warning: the frame size of 1168 bytes is larger than 
800 bytes [-Wframe-larger-than=]
  fs/f2fs/inode.c:152:1: warning: the frame size of 1424 bytes is larger than 
800 bytes [-Wframe-larger-than=]
  net/netfilter/ipvs/ip_vs_core.c:1195:1: warning: the frame size of 1068 bytes 
is larger than 800 bytes [-Wframe-larger-than=]
  net/netfilter/ipvs/ip_vs_core.c:395:1: warning: the frame size of 1084 bytes 
is larger than 800 bytes [-Wframe-larger-than=]
  net/netfilter/ipvs/ip_vs_ftp.c:298:1: warning: the frame size of 928 bytes is 
larger than 800 bytes [-Wframe-larger-than=]
  net/netfilter/ipvs/ip_vs_ftp.c:418:1: warning: the frame size of 908 bytes is 
larger than 800 bytes [-Wframe-larger-than=]
  net/netfilter/ipvs/ip_vs_lblcr.c:718:1: warning: the frame size of 960 bytes 
is larger than 800 bytes [-Wframe-larger-than=]
  drivers/net/xen-netback/netback.c:1500:1: warning: the frame size of 1088 
bytes is larger than 800 bytes [-Wframe-larger-than=]

In case of ARC and CRIS, it turns out that the BUG() implementation
actually does return (or at least the compiler thinks it does),
resulting in lots of warnings about uninitialized variable use and
leaving noreturn functions, such as:

  block/cfq-iosched.c: In function 'cfq_async_queue_prio':
  block/cfq-iosched.c:3804:1: error: control reaches end of non-void function 
[-Werror=return-type]
  include/linux/dmaengine.h: In function 'dma_maxpq':
  include/linux/dmaengine.h:1123:1: error: control reaches end of non-void 
function [-Werror=return-type]

This makes them call __builtin_trap() instead, which should normally
dump the stack and kill the current process, like some of the other
architectures already do.

I tried adding barrier_before_unreachable() to panic() and
fortify_panic() as well, but that had very little effect, so I'm not
submitting that patch.

Vineet said:

: For ARC, it is double win.
:
: 1. Fixes 3 -Wreturn-type warnings
:
: | ../net/core/ethtool.c:311:1: warning: control reaches end of non-void 
function
: [-Wreturn-type]
: | ../kernel/sched/core.c:3246:1: warning: control reaches end of non-void 
function
: [-Wreturn-type]
: | ../include/linux/sunrpc/svc_xprt.h:180:1: warning: control reaches end of
: non-void function [-Wreturn-type]
:
: 2.  bloat-o-meter reports code size improvements as gcc elides the
:generated code for stack return.

Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82365
Link: http://lkml.kernel.org/r/20171219114112.939391-1-a...@arndb.de
Signed-off-by: Arnd Bergmann 
Acked-by: Vineet Gupta [arch/arc]
Tested-by: Vineet Gupta[arch/arc]
Cc: Mikael Starvik 
Cc: Jesper Nilsson 
Cc: Tony Luck 
Cc: Fenghua Yu 
Cc: Geert Uytterhoeven 
Cc: "David S. Miller" 
Cc: Christopher Li 
Cc: Thomas Gleixner 
Cc: Peter Zijlstra 
Cc: Kees Cook 
Cc: Ingo Molnar 
Cc: Josh Poimboeuf 
Cc: Will Deacon 
Cc: "Steven Rostedt (VMware)" 
Cc: Mark Rutland 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Sasha Levin 
[ removed cris changes - gregkh]
Signed-off-by: Greg Kroah-Hartman 
---
 arch/arc/include/asm/bug.h   |3 ++-
 arch/ia64/include/asm/bug.h  |6 +-
 arch/m68k/include/asm/bug.h  |3 +++
 arch/sparc/include/asm/bug.h |6 +-
 include/asm-generic/bug.h|1 +
 include/linux/compiler-gcc.h |   15 ++-
 include/linux/compiler.h |5 +
 7 files changed, 35 insertions(+), 4 deletions(-)

--- a/arch/arc/include/asm/bug.h
+++ b/arch/arc/include/asm/bug.h
@@ -23,7 +23,8 @@ void die(const char *str, struct pt_regs
 
 #define BUG()  do {
\
pr_warn("BUG: failure at %s:%d/%s()!\n", __FILE__, __LINE__, __func__); 
\
-   dump_stack();   
\
+   barrier_before_unreachable();

[PATCH 4.4 57/73] MIPS: math-emu: do not use bools for arithmetic

2019-07-08 Thread Greg Kroah-Hartman
[ Upstream commit 8535f2ba0a9b971df62a5890699b9dfe2e0d5580 ]

GCC-7 complains about a boolean value being used with an arithmetic
AND:

arch/mips/math-emu/cp1emu.c: In function 'cop1Emulate':
arch/mips/math-emu/cp1emu.c:838:14: warning: '~' on a boolean expression 
[-Wbool-operation]
  fpr = (x) & ~(cop1_64bit(xcp) == 0);\
  ^
arch/mips/math-emu/cp1emu.c:1068:3: note: in expansion of macro 'DITOREG'
   DITOREG(dval, MIPSInst_RT(ir));
   ^~~
arch/mips/math-emu/cp1emu.c:838:14: note: did you mean to use logical not?
  fpr = (x) & ~(cop1_64bit(xcp) == 0);\

Since cop1_64bit() returns and int, just flip the LSB.

Suggested-by: Maciej W. Rozycki 
Signed-off-by: Manuel Lauss 
Reviewed-by: Maciej W. Rozycki 
Cc: linux-m...@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/17058/
Signed-off-by: Ralf Baechle 
Signed-off-by: Sasha Levin 
---
 arch/mips/math-emu/cp1emu.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/mips/math-emu/cp1emu.c b/arch/mips/math-emu/cp1emu.c
index 89d05de8040a..011b9b9574f1 100644
--- a/arch/mips/math-emu/cp1emu.c
+++ b/arch/mips/math-emu/cp1emu.c
@@ -829,12 +829,12 @@ do {  
\
 } while (0)
 
 #define DIFROMREG(di, x)   \
-   ((di) = get_fpr64(>fpr[(x) & ~(cop1_64bit(xcp) == 0)], 0))
+   ((di) = get_fpr64(>fpr[(x) & ~(cop1_64bit(xcp) ^ 1)], 0))
 
 #define DITOREG(di, x) \
 do {   \
unsigned fpr, i;\
-   fpr = (x) & ~(cop1_64bit(xcp) == 0);\
+   fpr = (x) & ~(cop1_64bit(xcp) ^ 1); \
set_fpr64(>fpr[fpr], 0, di);   \
for (i = 1; i < ARRAY_SIZE(ctx->fpr[x].val64); i++) \
set_fpr64(>fpr[fpr], i, 0);\
-- 
2.20.1





[PATCH 4.4 56/73] ARC: fix build warning in elf.h

2019-07-08 Thread Greg Kroah-Hartman
[ Upstream commit 1dec78585328db00e33fb18dc1a6deed0e2095a5 ]

The cast valid since TASK_SIZE * 2 will never actually cause overflow.

|   CC  fs/binfmt_elf.o
| In file included from ../include/linux/elf.h:4:0,
|  from ../include/linux/module.h:15,
|  from ../fs/binfmt_elf.c:12:
| ../fs/binfmt_elf.c: In function load_elf_binar:
| ../arch/arc/include/asm/elf.h:57:29: warning: integer overflow in expression 
[-Woverflow]
|  #define ELF_ET_DYN_BASE  (2 * TASK_SIZE / 3)
|  ^
| ../fs/binfmt_elf.c:921:16: note: in expansion of macro ELF_ET_DYN_BASE
| load_bias = ELF_ET_DYN_BASE - vaddr;

Signed-off-by: Vineet Gupta 
Signed-off-by: Sasha Levin 
---
 arch/arc/include/asm/elf.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arc/include/asm/elf.h b/arch/arc/include/asm/elf.h
index 51a99e25fe33..8ee9113b2f8b 100644
--- a/arch/arc/include/asm/elf.h
+++ b/arch/arc/include/asm/elf.h
@@ -55,7 +55,7 @@ extern int elf_check_arch(const struct elf32_hdr *);
  * the loader.  We need to make sure that it is out of the way of the program
  * that it will "exec", and that there is sufficient room for the brk.
  */
-#define ELF_ET_DYN_BASE(2 * TASK_SIZE / 3)
+#define ELF_ET_DYN_BASE(2UL * TASK_SIZE / 3)
 
 /*
  * When the program starts, a1 contains a pointer to a function to be
-- 
2.20.1





[PATCH 4.4 55/73] ARC: Assume multiplier is always present

2019-07-08 Thread Greg Kroah-Hartman
[ Upstream commit 0eca6fdb3193410fbe66b6f064431cc394513e82 ]

It is unlikely that designs running Linux will not have multiplier.
Further the current support is not complete as tool don't generate a
multilib w/o multiplier.

Signed-off-by: Vineet Gupta 
Signed-off-by: Sasha Levin 
---
 arch/arc/Kconfig| 8 
 arch/arc/Makefile   | 4 
 arch/arc/kernel/setup.c | 2 --
 3 files changed, 14 deletions(-)

diff --git a/arch/arc/Kconfig b/arch/arc/Kconfig
index e983f410135a..a5d8bef65911 100644
--- a/arch/arc/Kconfig
+++ b/arch/arc/Kconfig
@@ -278,14 +278,6 @@ config ARC_DCCM_BASE
default "0xA000"
depends on ARC_HAS_DCCM
 
-config ARC_HAS_HW_MPY
-   bool "Use Hardware Multiplier (Normal or Faster XMAC)"
-   default y
-   help
- Influences how gcc generates code for MPY operations.
- If enabled, MPYxx insns are generated, provided by Standard/XMAC
- Multipler. Otherwise software multipy lib is used
-
 choice
prompt "MMU Version"
default ARC_MMU_V3 if ARC_CPU_770
diff --git a/arch/arc/Makefile b/arch/arc/Makefile
index fffaff9c7b2c..8f8d53f08141 100644
--- a/arch/arc/Makefile
+++ b/arch/arc/Makefile
@@ -72,10 +72,6 @@ ldflags-$(CONFIG_CPU_BIG_ENDIAN) += -EB
 # --build-id w/o "-marclinux". Default arc-elf32-ld is OK
 ldflags-$(upto_gcc44)  += -marclinux
 
-ifndef CONFIG_ARC_HAS_HW_MPY
-   cflags-y+= -mno-mpy
-endif
-
 LIBGCC := $(shell $(CC) $(cflags-y) --print-libgcc-file-name)
 
 # Modules with short calls might break for calls into builtin-kernel
diff --git a/arch/arc/kernel/setup.c b/arch/arc/kernel/setup.c
index 05131805aa33..3013f3f82b95 100644
--- a/arch/arc/kernel/setup.c
+++ b/arch/arc/kernel/setup.c
@@ -232,8 +232,6 @@ static char *arc_cpu_mumbojumbo(int cpu_id, char *buf, int 
len)
 
n += scnprintf(buf + n, len - n, "mpy[opt %d] ", opt);
}
-   n += scnprintf(buf + n, len - n, "%s",
-  IS_USED_CFG(CONFIG_ARC_HAS_HW_MPY));
}
 
n += scnprintf(buf + n, len - n, "%s%s%s%s%s%s%s%s\n",
-- 
2.20.1





[PATCH 4.4 29/73] perf ui helpline: Use strlcpy() as a shorter form of strncpy() + explicit set nul

2019-07-08 Thread Greg Kroah-Hartman
From: Arnaldo Carvalho de Melo 

commit 4d0f16d059ddb91424480d88473f7392f24aebdc upstream.

The strncpy() function may leave the destination string buffer
unterminated, better use strlcpy() that we have a __weak fallback
implementation for systems without it.

In this case we are actually setting the null byte at the right place,
but since we pass the buffer size as the limit to strncpy() and not
it minus one, gcc ends up warning us about that, see below. So, lets
just switch to the shorter form provided by strlcpy().

This fixes this warning on an Alpine Linux Edge system with gcc 8.2:

  ui/tui/helpline.c: In function 'tui_helpline__push':
  ui/tui/helpline.c:27:2: error: 'strncpy' specified bound 512 equals 
destination size [-Werror=stringop-truncation]
strncpy(ui_helpline__current, msg, sz)[sz - 1] = '\0';
^~
  cc1: all warnings being treated as errors

Cc: Adrian Hunter 
Cc: Jiri Olsa 
Cc: Namhyung Kim 
Fixes: e6e904687949 ("perf ui: Introduce struct ui_helpline")
Link: https://lkml.kernel.org/n/tip-d1wz0hjjsh19xbalw69qp...@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo 
Signed-off-by: Greg Kroah-Hartman 

---
 tools/perf/ui/tui/helpline.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/tools/perf/ui/tui/helpline.c
+++ b/tools/perf/ui/tui/helpline.c
@@ -23,7 +23,7 @@ static void tui_helpline__push(const cha
SLsmg_set_color(0);
SLsmg_write_nstring((char *)msg, SLtt_Screen_Cols);
SLsmg_refresh();
-   strncpy(ui_helpline__current, msg, sz)[sz - 1] = '\0';
+   strlcpy(ui_helpline__current, msg, sz);
 }
 
 static int tui_helpline__show(const char *format, va_list ap)




[PATCH 4.4 53/73] usb: gadget: udc: lpc32xx: allocate descriptor with GFP_ATOMIC

2019-07-08 Thread Greg Kroah-Hartman
[ Upstream commit fbc318afadd6e7ae2252d6158cf7d0c5a2132f7d ]

Gadget drivers may queue request in interrupt context. This would lead to
a descriptor allocation in that context. In that case we would hit
BUG_ON(in_interrupt()) in __get_vm_area_node.

Also remove the unnecessary cast.

Acked-by: Sylvain Lemieux 
Tested-by: James Grant 
Signed-off-by: Alexandre Belloni 
Signed-off-by: Felipe Balbi 
Signed-off-by: Sasha Levin 
---
 drivers/usb/gadget/udc/lpc32xx_udc.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/usb/gadget/udc/lpc32xx_udc.c 
b/drivers/usb/gadget/udc/lpc32xx_udc.c
index 00b5006baf15..90d24f62bd81 100644
--- a/drivers/usb/gadget/udc/lpc32xx_udc.c
+++ b/drivers/usb/gadget/udc/lpc32xx_udc.c
@@ -964,8 +964,7 @@ static struct lpc32xx_usbd_dd_gad *udc_dd_alloc(struct 
lpc32xx_udc *udc)
dma_addr_t  dma;
struct lpc32xx_usbd_dd_gad  *dd;
 
-   dd = (struct lpc32xx_usbd_dd_gad *) dma_pool_alloc(
-   udc->dd_cache, (GFP_KERNEL | GFP_DMA), );
+   dd = dma_pool_alloc(udc->dd_cache, GFP_ATOMIC | GFP_DMA, );
if (dd)
dd->this_dma = dma;
 
-- 
2.20.1





[PATCH 4.4 54/73] scsi: hpsa: correct ioaccel2 chaining

2019-07-08 Thread Greg Kroah-Hartman
[ Upstream commit 625d7d3518875c4d303c652a198feaa13d9f52d9 ]

- set ioaccel2_sg_element member 'chain_indicator' to IOACCEL2_LAST_SG for
  the last s/g element.

- set ioaccel2_sg_element member 'chain_indicator' to IOACCEL2_CHAIN when
  chaining.

Reviewed-by: Bader Ali - Saleh 
Reviewed-by: Scott Teel 
Reviewed-by: Matt Perricone 
Signed-off-by: Don Brace 
Signed-off-by: Martin K. Petersen 
Signed-off-by: Sasha Levin 
---
 drivers/scsi/hpsa.c | 7 ++-
 drivers/scsi/hpsa_cmd.h | 1 +
 2 files changed, 7 insertions(+), 1 deletion(-)

diff --git a/drivers/scsi/hpsa.c b/drivers/scsi/hpsa.c
index 910b795fc5eb..e0952882e132 100644
--- a/drivers/scsi/hpsa.c
+++ b/drivers/scsi/hpsa.c
@@ -4562,7 +4562,7 @@ static int hpsa_scsi_ioaccel2_queue_command(struct 
ctlr_info *h,
curr_sg->reserved[0] = 0;
curr_sg->reserved[1] = 0;
curr_sg->reserved[2] = 0;
-   curr_sg->chain_indicator = 0x80;
+   curr_sg->chain_indicator = IOACCEL2_CHAIN;
 
curr_sg = h->ioaccel2_cmd_sg_list[c->cmdindex];
}
@@ -4579,6 +4579,11 @@ static int hpsa_scsi_ioaccel2_queue_command(struct 
ctlr_info *h,
curr_sg++;
}
 
+   /*
+* Set the last s/g element bit
+*/
+   (curr_sg - 1)->chain_indicator = IOACCEL2_LAST_SG;
+
switch (cmd->sc_data_direction) {
case DMA_TO_DEVICE:
cp->direction &= ~IOACCEL2_DIRECTION_MASK;
diff --git a/drivers/scsi/hpsa_cmd.h b/drivers/scsi/hpsa_cmd.h
index 26488e2a7f02..7ffde12d57d4 100644
--- a/drivers/scsi/hpsa_cmd.h
+++ b/drivers/scsi/hpsa_cmd.h
@@ -513,6 +513,7 @@ struct ioaccel2_sg_element {
u8 reserved[3];
u8 chain_indicator;
 #define IOACCEL2_CHAIN 0x80
+#define IOACCEL2_LAST_SG 0x40
 };
 
 /*
-- 
2.20.1





[PATCH 4.4 48/73] um: Compile with modern headers

2019-07-08 Thread Greg Kroah-Hartman
From: Jason A. Donenfeld 

commit 530ba6c7cb3c22435a4d26de47037bb6f86a5329 upstream.

Recent libcs have gotten a bit more strict, so we actually need to
include the right headers and use the right types. This enables UML to
compile again.

Signed-off-by: Jason A. Donenfeld 
Cc: sta...@vger.kernel.org
Signed-off-by: Richard Weinberger 
Signed-off-by: Alessio Balsini 
Signed-off-by: Greg Kroah-Hartman 
---
 arch/um/os-Linux/file.c   |1 +
 arch/um/os-Linux/signal.c |2 ++
 arch/x86/um/stub_segv.c   |1 +
 3 files changed, 4 insertions(+)

--- a/arch/um/os-Linux/file.c
+++ b/arch/um/os-Linux/file.c
@@ -12,6 +12,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
--- a/arch/um/os-Linux/signal.c
+++ b/arch/um/os-Linux/signal.c
@@ -14,7 +14,9 @@
 #include 
 #include 
 #include 
+#include 
 #include 
+#include 
 
 void (*sig_info[NSIG])(int, struct siginfo *, struct uml_pt_regs *) = {
[SIGTRAP]   = relay_signal,
--- a/arch/x86/um/stub_segv.c
+++ b/arch/x86/um/stub_segv.c
@@ -6,6 +6,7 @@
 #include 
 #include 
 #include 
+#include 
 
 void __attribute__ ((__section__ (".__syscall_stub")))
 stub_segv_handler(int sig, siginfo_t *info, void *p)




[PATCH 4.4 46/73] net: check before dereferencing netdev_ops during busy poll

2019-07-08 Thread Greg Kroah-Hartman
From: Josh Elsasser 

init_dummy_netdev() leaves its netdev_ops pointer zeroed. This leads
to a NULL pointer dereference when sk_busy_loop fires against an iwlwifi
wireless adapter and checks napi->dev->netdev_ops->ndo_busy_poll.

Avoid this by ensuring napi->dev->netdev_ops is valid before following
the pointer, avoiding the following panic when busy polling on a dummy
netdev:

  BUG: unable to handle kernel NULL pointer dereference at 00c8
  IP: [] sk_busy_loop+0x92/0x2f0
  Call Trace:
   [] ? uart_write_room+0x74/0xf0
   [] sock_poll+0x99/0xa0
   [] do_sys_poll+0x2e2/0x520
   [] ? get_page_from_freelist+0x3bc/0xa30
   [] ? update_curr+0x62/0x140
   [] ? __slab_free+0xa1/0x2a0
   [] ? __slab_free+0xa1/0x2a0
   [] ? skb_free_head+0x21/0x30
   [] ? poll_initwait+0x50/0x50
   [] ? kmem_cache_free+0x1c6/0x1e0
   [] ? uart_write+0x124/0x1d0
   [] ? remove_wait_queue+0x4d/0x60
   [] ? __wake_up+0x44/0x50
   [] ? tty_write_unlock+0x31/0x40
   [] ? tty_ldisc_deref+0x16/0x20
   [] ? tty_write+0x1e0/0x2f0
   [] ? process_echoes+0x80/0x80
   [] ? __vfs_write+0x2b/0x130
   [] ? vfs_write+0x15a/0x1a0
   [] SyS_poll+0x75/0x100
   [] entry_SYSCALL_64_fastpath+0x24/0xcf

Commit 79e7fff47b7b ("net: remove support for per driver ndo_busy_poll()")
indirectly fixed this upstream in linux-4.11 by removing the offending
pointer usage. No other users of napi->dev touch its netdev_ops.

Fixes: 8b80cda536ea ("net: rename include/net/ll_poll.h to 
include/net/busy_poll.h") # 4.4.y
Signed-off-by: Josh Elsasser 
Signed-off-by: Greg Kroah-Hartman 
---

This is a straightforward backport of the 4.9.y fix[1] for this crash, which 
doesn't
apply to the older LTS releases. Only build-tested on 4.4.y, as I don't have 
access
to wireless hardware and firmware that runs on older LTS kernels.

[1]: 
https://lore.kernel.org/stable/20190701234143.72631-1-jelsas...@appneta.com/T/#u

 include/net/busy_poll.h |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/include/net/busy_poll.h
+++ b/include/net/busy_poll.h
@@ -93,7 +93,7 @@ static inline bool sk_busy_loop(struct s
goto out;
 
ops = napi->dev->netdev_ops;
-   if (!ops->ndo_busy_poll)
+   if (!ops || !ops->ndo_busy_poll)
goto out;
 
do {




[PATCH 4.4 51/73] ASoC: max98090: remove 24-bit format support if RJ is 0

2019-07-08 Thread Greg Kroah-Hartman
[ Upstream commit 5628c8979642a076f91ee86c3bae5ad251639af0 ]

The supported formats are S16_LE and S24_LE now. However, by datasheet
of max98090, S24_LE is only supported when it is in the right justified
mode. We should remove 24-bit format if it is not in that mode to avoid
triggering error.

Signed-off-by: Yu-Hsuan Hsu 
Signed-off-by: Mark Brown 
Signed-off-by: Sasha Levin 
---
 sound/soc/codecs/max98090.c | 16 
 1 file changed, 16 insertions(+)

diff --git a/sound/soc/codecs/max98090.c b/sound/soc/codecs/max98090.c
index 3e65dc74eb33..e7aef841f87d 100644
--- a/sound/soc/codecs/max98090.c
+++ b/sound/soc/codecs/max98090.c
@@ -1924,6 +1924,21 @@ static int max98090_configure_dmic(struct max98090_priv 
*max98090,
return 0;
 }
 
+static int max98090_dai_startup(struct snd_pcm_substream *substream,
+   struct snd_soc_dai *dai)
+{
+   struct snd_soc_component *component = dai->component;
+   struct max98090_priv *max98090 = 
snd_soc_component_get_drvdata(component);
+   unsigned int fmt = max98090->dai_fmt;
+
+   /* Remove 24-bit format support if it is not in right justified mode. */
+   if ((fmt & SND_SOC_DAIFMT_FORMAT_MASK) != SND_SOC_DAIFMT_RIGHT_J) {
+   substream->runtime->hw.formats = SNDRV_PCM_FMTBIT_S16_LE;
+   snd_pcm_hw_constraint_msbits(substream->runtime, 0, 16, 16);
+   }
+   return 0;
+}
+
 static int max98090_dai_hw_params(struct snd_pcm_substream *substream,
   struct snd_pcm_hw_params *params,
   struct snd_soc_dai *dai)
@@ -2331,6 +2346,7 @@ EXPORT_SYMBOL_GPL(max98090_mic_detect);
 #define MAX98090_FORMATS (SNDRV_PCM_FMTBIT_S16_LE | SNDRV_PCM_FMTBIT_S24_LE)
 
 static const struct snd_soc_dai_ops max98090_dai_ops = {
+   .startup = max98090_dai_startup,
.set_sysclk = max98090_dai_set_sysclk,
.set_fmt = max98090_dai_set_fmt,
.set_tdm_slot = max98090_set_tdm_slot,
-- 
2.20.1





[PATCH 4.4 52/73] usb: gadget: fusb300_udc: Fix memory leak of fusb300->ep[i]

2019-07-08 Thread Greg Kroah-Hartman
[ Upstream commit 62fd0e0a24abeebe2c19fce49dd5716d9b62042d ]

There is no deallocation of fusb300->ep[i] elements, allocated at
fusb300_probe.

The patch adds deallocation of fusb300->ep array elements.

Signed-off-by: Young Xiao <92siuy...@gmail.com>
Signed-off-by: Felipe Balbi 
Signed-off-by: Sasha Levin 
---
 drivers/usb/gadget/udc/fusb300_udc.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/usb/gadget/udc/fusb300_udc.c 
b/drivers/usb/gadget/udc/fusb300_udc.c
index 948845c90e47..351012c498c5 100644
--- a/drivers/usb/gadget/udc/fusb300_udc.c
+++ b/drivers/usb/gadget/udc/fusb300_udc.c
@@ -1345,12 +1345,15 @@ static const struct usb_gadget_ops fusb300_gadget_ops = 
{
 static int fusb300_remove(struct platform_device *pdev)
 {
struct fusb300 *fusb300 = platform_get_drvdata(pdev);
+   int i;
 
usb_del_gadget_udc(>gadget);
iounmap(fusb300->reg);
free_irq(platform_get_irq(pdev, 0), fusb300);
 
fusb300_free_request(>ep[0]->ep, fusb300->ep0_req);
+   for (i = 0; i < FUSB300_MAX_NUM_EP; i++)
+   kfree(fusb300->ep[i]);
kfree(fusb300);
 
return 0;
@@ -1494,6 +1497,8 @@ clean_up:
if (fusb300->ep0_req)
fusb300_free_request(>ep[0]->ep,
fusb300->ep0_req);
+   for (i = 0; i < FUSB300_MAX_NUM_EP; i++)
+   kfree(fusb300->ep[i]);
kfree(fusb300);
}
if (reg)
-- 
2.20.1





[PATCH 4.4 28/73] mac80211: drop robust management frames from unknown TA

2019-07-08 Thread Greg Kroah-Hartman
From: Johannes Berg 

commit 588f7d39b3592a36fb7702ae3b8bdd9be4621e2f upstream.

When receiving a robust management frame, drop it if we don't have
rx->sta since then we don't have a security association and thus
couldn't possibly validate the frame.

Cc: sta...@vger.kernel.org
Signed-off-by: Johannes Berg 
Signed-off-by: Greg Kroah-Hartman 

---
 net/mac80211/rx.c |2 ++
 1 file changed, 2 insertions(+)

--- a/net/mac80211/rx.c
+++ b/net/mac80211/rx.c
@@ -3324,6 +3324,8 @@ static bool ieee80211_accept_frame(struc
case NL80211_IFTYPE_STATION:
if (!bssid && !sdata->u.mgd.use_4addr)
return false;
+   if (ieee80211_is_robust_mgmt_frame(skb) && !rx->sta)
+   return false;
if (multicast)
return true;
return ether_addr_equal(sdata->vif.addr, hdr->addr1);




Re: [PATCH] [net-next] net/mlx5e: xsk: dynamically allocate mlx5e_channel_param

2019-07-08 Thread Maxim Mikityanskiy
On 2019-07-08 15:55, Arnd Bergmann wrote:
> The structure is too large to put on the stack, resulting in a
> warning on 32-bit ARM:
> 
> drivers/net/ethernet/mellanox/mlx5/core/en/xsk/setup.c:59:5: error: stack 
> frame size of 1344 bytes in function
>'mlx5e_open_xsk' [-Werror,-Wframe-larger-than=]
> 
> Use kzalloc() instead.
> 
> Fixes: a038e9794541 ("net/mlx5e: Add XSK zero-copy support")
> Signed-off-by: Arnd Bergmann 
> ---
>   .../mellanox/mlx5/core/en/xsk/setup.c | 25 ---
>   1 file changed, 16 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en/xsk/setup.c 
> b/drivers/net/ethernet/mellanox/mlx5/core/en/xsk/setup.c
> index aaffa6f68dc0..db9bbec68dbf 100644
> --- a/drivers/net/ethernet/mellanox/mlx5/core/en/xsk/setup.c
> +++ b/drivers/net/ethernet/mellanox/mlx5/core/en/xsk/setup.c
> @@ -60,24 +60,28 @@ int mlx5e_open_xsk(struct mlx5e_priv *priv, struct 
> mlx5e_params *params,
>  struct mlx5e_xsk_param *xsk, struct xdp_umem *umem,
>  struct mlx5e_channel *c)
>   {
> - struct mlx5e_channel_param cparam = {};
> + struct mlx5e_channel_param *cparam;
>   struct dim_cq_moder icocq_moder = {};
>   int err;
>   
>   if (!mlx5e_validate_xsk_param(params, xsk, priv->mdev))
>   return -EINVAL;
>   
> - mlx5e_build_xsk_cparam(priv, params, xsk, );
> + cparam = kzalloc(sizeof(*cparam), GFP_KERNEL);

Similar code in mlx5e_open_channels (en_main.c) uses kvzalloc. Although 
the struct is currently smaller than a page anyway, and there should be 
no difference in behavior now, I suggest using the same alloc function 
to keep code uniform.

> + if (!cparam)
> + return -ENOMEM;
>   
> - err = mlx5e_open_cq(c, params->rx_cq_moderation, _cq, 
> >xskrq.cq);
> + mlx5e_build_xsk_cparam(priv, params, xsk, cparam);
> +
> + err = mlx5e_open_cq(c, params->rx_cq_moderation, >rx_cq, 
> >xskrq.cq);
>   if (unlikely(err))
> - return err;
> + goto err_kfree_cparam;
>   
> - err = mlx5e_open_rq(c, params, , xsk, umem, >xskrq);
> + err = mlx5e_open_rq(c, params, >rq, xsk, umem, >xskrq);
>   if (unlikely(err))
>   goto err_close_rx_cq;
>   
> - err = mlx5e_open_cq(c, params->tx_cq_moderation, _cq, 
> >xsksq.cq);
> + err = mlx5e_open_cq(c, params->tx_cq_moderation, >tx_cq, 
> >xsksq.cq);
>   if (unlikely(err))
>   goto err_close_rq;
>   
> @@ -87,18 +91,18 @@ int mlx5e_open_xsk(struct mlx5e_priv *priv, struct 
> mlx5e_params *params,
>* is disabled and then reenabled, but the SQ continues receiving CQEs
>* from the old UMEM.
>*/
> - err = mlx5e_open_xdpsq(c, params, _sq, umem, >xsksq, 
> true);
> + err = mlx5e_open_xdpsq(c, params, >xdp_sq, umem, >xsksq, 
> true);
>   if (unlikely(err))
>   goto err_close_tx_cq;
>   
> - err = mlx5e_open_cq(c, icocq_moder, _cq, >xskicosq.cq);
> + err = mlx5e_open_cq(c, icocq_moder, >icosq_cq, >xskicosq.cq);
>   if (unlikely(err))
>   goto err_close_sq;
>   
>   /* Create a dedicated SQ for posting NOPs whenever we need an IRQ to be
>* triggered and NAPI to be called on the correct CPU.
>*/
> - err = mlx5e_open_icosq(c, params, , >xskicosq);
> + err = mlx5e_open_icosq(c, params, >icosq, >xskicosq);
>   if (unlikely(err))
>   goto err_close_icocq;
>   

Here is kfree missing. It's a memory leak in the good path.

Thanks!

> @@ -123,6 +127,9 @@ int mlx5e_open_xsk(struct mlx5e_priv *priv, struct 
> mlx5e_params *params,
>   err_close_rx_cq:
>   mlx5e_close_cq(>xskrq.cq);
>   
> +err_kfree_cparam:
> + kfree(cparam);
> +
>   return err;
>   }
>   
> 



[PATCH 4.4 43/73] team: Always enable vlan tx offload

2019-07-08 Thread Greg Kroah-Hartman
From: YueHaibing 

[ Upstream commit ee4297420d56a0033a8593e80b33fcc93fda8509 ]

We should rather have vlan_tci filled all the way down
to the transmitting netdevice and let it do the hw/sw
vlan implementation.

Suggested-by: Jiri Pirko 
Signed-off-by: YueHaibing 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman 
---
 drivers/net/team/team.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/net/team/team.c
+++ b/drivers/net/team/team.c
@@ -2091,12 +2091,12 @@ static void team_setup(struct net_device
dev->features |= NETIF_F_NETNS_LOCAL;
 
dev->hw_features = TEAM_VLAN_FEATURES |
-  NETIF_F_HW_VLAN_CTAG_TX |
   NETIF_F_HW_VLAN_CTAG_RX |
   NETIF_F_HW_VLAN_CTAG_FILTER;
 
dev->hw_features &= ~(NETIF_F_ALL_CSUM & ~NETIF_F_HW_CSUM);
dev->features |= dev->hw_features;
+   dev->features |= NETIF_F_HW_VLAN_CTAG_TX;
 }
 
 static int team_newlink(struct net *src_net, struct net_device *dev,




[PATCH 4.4 45/73] bonding: Always enable vlan tx offload

2019-07-08 Thread Greg Kroah-Hartman
From: YueHaibing 

[ Upstream commit 30d8177e8ac776d89d387fad547af6a0f599210e ]

We build vlan on top of bonding interface, which vlan offload
is off, bond mode is 802.3ad (LACP) and xmit_hash_policy is
BOND_XMIT_POLICY_ENCAP34.

Because vlan tx offload is off, vlan tci is cleared and skb push
the vlan header in validate_xmit_vlan() while sending from vlan
devices. Then in bond_xmit_hash, __skb_flow_dissect() fails to
get information from protocol headers encapsulated within vlan,
because 'nhoff' is points to IP header, so bond hashing is based
on layer 2 info, which fails to distribute packets across slaves.

This patch always enable bonding's vlan tx offload, pass the vlan
packets to the slave devices with vlan tci, let them to handle
vlan implementation.

Fixes: 278339a42a1b ("bonding: propogate vlan_features to bonding master")
Suggested-by: Jiri Pirko 
Signed-off-by: YueHaibing 
Acked-by: Jiri Pirko 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman 
---
 drivers/net/bonding/bond_main.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/net/bonding/bond_main.c
+++ b/drivers/net/bonding/bond_main.c
@@ -4164,13 +4164,13 @@ void bond_setup(struct net_device *bond_
bond_dev->features |= NETIF_F_NETNS_LOCAL;
 
bond_dev->hw_features = BOND_VLAN_FEATURES |
-   NETIF_F_HW_VLAN_CTAG_TX |
NETIF_F_HW_VLAN_CTAG_RX |
NETIF_F_HW_VLAN_CTAG_FILTER;
 
bond_dev->hw_features &= ~(NETIF_F_ALL_CSUM & ~NETIF_F_HW_CSUM);
bond_dev->hw_features |= NETIF_F_GSO_ENCAP_ALL;
bond_dev->features |= bond_dev->hw_features;
+   bond_dev->features |= NETIF_F_HW_VLAN_CTAG_TX;
 }
 
 /* Destroy a bonding device.




[PATCH 4.4 37/73] ovl: modify ovl_permission() to do checks on two inodes

2019-07-08 Thread Greg Kroah-Hartman
From: Vivek Goyal 

commit c0ca3d70e8d3cf81e2255a217f7ca402f5ed0862 upstream.

Right now ovl_permission() calls __inode_permission(realinode), to do
permission checks on real inode and no checks are done on overlay inode.

Modify it to do checks both on overlay inode as well as underlying inode.
Checks on overlay inode will be done with the creds of calling task while
checks on underlying inode will be done with the creds of mounter.

Signed-off-by: Vivek Goyal 
Signed-off-by: Miklos Szeredi 
[ Srivatsa: 4.4.y backport:
  - Skipped the hunk modifying non-existent function ovl_get_acl()
  - Adjusted the error path
  - Included linux/cred.h to get prototype for revert_creds() ]
Signed-off-by: Srivatsa S. Bhat (VMware) 
Signed-off-by: Greg Kroah-Hartman 

---
 fs/overlayfs/inode.c |   13 +
 1 file changed, 13 insertions(+)

--- a/fs/overlayfs/inode.c
+++ b/fs/overlayfs/inode.c
@@ -9,6 +9,7 @@
 
 #include 
 #include 
+#include 
 #include 
 #include "overlayfs.h"
 
@@ -91,6 +92,7 @@ int ovl_permission(struct inode *inode,
struct ovl_entry *oe;
struct dentry *alias = NULL;
struct inode *realinode;
+   const struct cred *old_cred;
struct dentry *realdentry;
bool is_upper;
int err;
@@ -143,7 +145,18 @@ int ovl_permission(struct inode *inode,
goto out_dput;
}
 
+   /*
+* Check overlay inode with the creds of task and underlying inode
+* with creds of mounter
+*/
+   err = generic_permission(inode, mask);
+   if (err)
+   goto out_dput;
+
+   old_cred = ovl_override_creds(inode->i_sb);
err = __inode_permission(realinode, mask);
+   revert_creds(old_cred);
+
 out_dput:
dput(alias);
return err;




[PATCH 4.4 36/73] KVM: X86: Fix scan ioapic use-before-initialization

2019-07-08 Thread Greg Kroah-Hartman
From: Wanpeng Li 

commit e97f852fd4561e77721bb9a4e0ea9d98305b1e93 upstream.

Reported by syzkaller:

 BUG: unable to handle kernel NULL pointer dereference at 01c8
 PGD 8003ec4da067 P4D 8003ec4da067 PUD 3f7bfa067 PMD 0
 Oops:  [#1] PREEMPT SMP PTI
 CPU: 7 PID: 5059 Comm: debug Tainted: G   OE 4.19.0-rc5 #16
 RIP: 0010:__lock_acquire+0x1a6/0x1990
 Call Trace:
  lock_acquire+0xdb/0x210
  _raw_spin_lock+0x38/0x70
  kvm_ioapic_scan_entry+0x3e/0x110 [kvm]
  vcpu_enter_guest+0x167e/0x1910 [kvm]
  kvm_arch_vcpu_ioctl_run+0x35c/0x610 [kvm]
  kvm_vcpu_ioctl+0x3e9/0x6d0 [kvm]
  do_vfs_ioctl+0xa5/0x690
  ksys_ioctl+0x6d/0x80
  __x64_sys_ioctl+0x1a/0x20
  do_syscall_64+0x83/0x6e0
  entry_SYSCALL_64_after_hwframe+0x49/0xbe

The reason is that the testcase writes hyperv synic HV_X64_MSR_SINT6 msr
and triggers scan ioapic logic to load synic vectors into EOI exit bitmap.
However, irqchip is not initialized by this simple testcase, ioapic/apic
objects should not be accessed.
This can be triggered by the following program:

#define _GNU_SOURCE

#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 

uint64_t r[3] = {0x, 0x, 
0x};

int main(void)
{
syscall(__NR_mmap, 0x2000, 0x100, 3, 0x32, -1, 0);
long res = 0;
memcpy((void*)0x2040, "/dev/kvm", 9);
res = syscall(__NR_openat, 0xff9c, 0x2040, 0, 0);
if (res != -1)
r[0] = res;
res = syscall(__NR_ioctl, r[0], 0xae01, 0);
if (res != -1)
r[1] = res;
res = syscall(__NR_ioctl, r[1], 0xae41, 0);
if (res != -1)
r[2] = res;
memcpy(
(void*)0x2080,

"\x01\x00\x00\x00\x00\x5b\x61\xbb\x96\x00\x00\x40\x00\x00\x00\x00\x01\x00"

"\x08\x00\x00\x00\x00\x00\x0b\x77\xd1\x78\x4d\xd8\x3a\xed\xb1\x5c\x2e\x43"

"\xaa\x43\x39\xd6\xff\xf5\xf0\xa8\x98\xf2\x3e\x37\x29\x89\xde\x88\xc6\x33"

"\xfc\x2a\xdb\xb7\xe1\x4c\xac\x28\x61\x7b\x9c\xa9\xbc\x0d\xa0\x63\xfe\xfe"

"\xe8\x75\xde\xdd\x19\x38\xdc\x34\xf5\xec\x05\xfd\xeb\x5d\xed\x2e\xaf\x22"

"\xfa\xab\xb7\xe4\x42\x67\xd0\xaf\x06\x1c\x6a\x35\x67\x10\x55\xcb",
106);
syscall(__NR_ioctl, r[2], 0x4008ae89, 0x2080);
syscall(__NR_ioctl, r[2], 0xae80, 0);
return 0;
}

This patch fixes it by bailing out scan ioapic if ioapic is not initialized in
kernel.

Reported-by: Wei Wu 
Cc: Paolo Bonzini 
Cc: Radim Krčmář 
Cc: Wei Wu 
Signed-off-by: Wanpeng Li 
Cc: sta...@vger.kernel.org
Signed-off-by: Paolo Bonzini 
[ Srivatsa: Adjusted the context for 4.4.y ]
Signed-off-by: Srivatsa S. Bhat (VMware) 
Signed-off-by: Greg Kroah-Hartman 

---
 arch/x86/kvm/x86.c |3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -6409,7 +6409,8 @@ static void vcpu_scan_ioapic(struct kvm_
kvm_scan_ioapic_routes(vcpu, vcpu->arch.eoi_exit_bitmap);
else {
kvm_x86_ops->sync_pir_to_irr(vcpu);
-   kvm_ioapic_scan_entry(vcpu, vcpu->arch.eoi_exit_bitmap);
+   if (ioapic_in_kernel(vcpu->kvm))
+   kvm_ioapic_scan_entry(vcpu, vcpu->arch.eoi_exit_bitmap);
}
kvm_x86_ops->load_eoi_exitmap(vcpu);
 }




[PATCH 4.4 27/73] cfg80211: fix memory leak of wiphy device name

2019-07-08 Thread Greg Kroah-Hartman
From: Eric Biggers 

commit 4f488fbca2a86cc7714a128952eead92cac279ab upstream.

In wiphy_new_nm(), if an error occurs after dev_set_name() and
device_initialize() have already been called, it's necessary to call
put_device() (via wiphy_free()) to avoid a memory leak.

Reported-by: syzbot+7fddca22578bc67c3...@syzkaller.appspotmail.com
Fixes: 1f87f7d3a3b4 ("cfg80211: add rfkill support")
Cc: sta...@vger.kernel.org
Signed-off-by: Eric Biggers 
Signed-off-by: Johannes Berg 
Signed-off-by: Greg Kroah-Hartman 

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

--- a/net/wireless/core.c
+++ b/net/wireless/core.c
@@ -447,7 +447,7 @@ use_default_name:
   >rfkill_ops, rdev);
 
if (!rdev->rfkill) {
-   kfree(rdev);
+   wiphy_free(>wiphy);
return NULL;
}
 




[PATCH 4.4 09/73] parport: Fix mem leak in parport_register_dev_model

2019-07-08 Thread Greg Kroah-Hartman
[ Upstream commit 1c7ebeabc9e5ee12e42075a597de40fdb9059530 ]

BUG: memory leak
unreferenced object 0x8881df48cda0 (size 16):
  comm "syz-executor.0", pid 5077, jiffies 4295994670 (age 22.280s)
  hex dump (first 16 bytes):
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  
  backtrace:
[] parport_register_dev_model+0x141/0x6e0 [parport]
[<782f6dab>] 0xc15d1196
[] platform_drv_probe+0x7e/0x100
[<628c2a94>] really_probe+0x342/0x4d0
[<6874f5da>] driver_probe_device+0x8c/0x170
[<424de37a>] __device_attach_driver+0xda/0x100
[<2acab09a>] bus_for_each_drv+0xfe/0x170
[<3d9e5f31>] __device_attach+0x190/0x230
[<35d32f80>] bus_probe_device+0x123/0x140
[] device_add+0x7cc/0xce0
[<3f7560bf>] platform_device_add+0x230/0x3c0
[<2a0be07d>] 0xc15d0949
[<7361d8d2>] port_check+0x3b/0x50 [parport]
[<4d67200f>] bus_for_each_dev+0x115/0x180
[<3ccfd11c>] __parport_register_driver+0x1f0/0x210 [parport]
[<987f06fc>] 0xc15d803e

After commit 4e5a74f1db8d ("parport: Revert "parport: fix
memory leak""), free_pardevice do not free par_dev->state,
we should free it in error path of parport_register_dev_model
before return.

Reported-by: Hulk Robot 
Fixes: 4e5a74f1db8d ("parport: Revert "parport: fix memory leak"")
Signed-off-by: YueHaibing 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin 
---
 drivers/parport/share.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/parport/share.c b/drivers/parport/share.c
index 754f21fd9768..f26af0214ab3 100644
--- a/drivers/parport/share.c
+++ b/drivers/parport/share.c
@@ -892,6 +892,7 @@ parport_register_dev_model(struct parport *port, const char 
*name,
par_dev->devmodel = true;
ret = device_register(_dev->dev);
if (ret) {
+   kfree(par_dev->state);
put_device(_dev->dev);
goto err_put_port;
}
@@ -909,6 +910,7 @@ parport_register_dev_model(struct parport *port, const char 
*name,
spin_unlock(>physport->pardevice_lock);
pr_debug("%s: cannot grant exclusive access for device 
%s\n",
 port->name, name);
+   kfree(par_dev->state);
device_unregister(_dev->dev);
goto err_put_port;
}
-- 
2.20.1





[PATCH] lib/lz4: remove the exporting of LZ4HC_setExternalDict

2019-07-08 Thread Denis Efremov
The function LZ4HC_setExternalDict is declared static and marked
EXPORT_SYMBOL, which is at best an odd combination. Because the function
is not used outside of the lib/lz4/lz4hc_compress.c file it is defined in,
this commit removes the EXPORT_SYMBOL() marking.

Signed-off-by: Denis Efremov 
---
 lib/lz4/lz4hc_compress.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/lib/lz4/lz4hc_compress.c b/lib/lz4/lz4hc_compress.c
index 176f03b83e56..1b61d874e337 100644
--- a/lib/lz4/lz4hc_compress.c
+++ b/lib/lz4/lz4hc_compress.c
@@ -663,7 +663,6 @@ static void LZ4HC_setExternalDict(
/* match referencing will resume from there */
ctxPtr->nextToUpdate = ctxPtr->dictLimit;
 }
-EXPORT_SYMBOL(LZ4HC_setExternalDict);
 
 static int LZ4_compressHC_continue_generic(
LZ4_streamHC_t *LZ4_streamHCPtr,
-- 
2.21.0



[PATCH 4.4 07/73] Input: uinput - add compat ioctl number translation for UI_*_FF_UPLOAD

2019-07-08 Thread Greg Kroah-Hartman
From: Andrey Smirnov 

commit 7c7da40da1640ce6814dab1e8031b44e19e5a3f6 upstream.

In the case of compat syscall ioctl numbers for UI_BEGIN_FF_UPLOAD and
UI_END_FF_UPLOAD need to be adjusted before being passed on
uinput_ioctl_handler() since code built with -m32 will be passing
slightly different values. Extend the code already covering
UI_SET_PHYS to cover UI_BEGIN_FF_UPLOAD and UI_END_FF_UPLOAD as well.

Reported-by: Pierre-Loup A. Griffais 
Signed-off-by: Andrey Smirnov 
Cc: sta...@vger.kernel.org
Signed-off-by: Dmitry Torokhov 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/input/misc/uinput.c |   22 --
 1 file changed, 20 insertions(+), 2 deletions(-)

--- a/drivers/input/misc/uinput.c
+++ b/drivers/input/misc/uinput.c
@@ -894,13 +894,31 @@ static long uinput_ioctl(struct file *fi
 
 #ifdef CONFIG_COMPAT
 
-#define UI_SET_PHYS_COMPAT _IOW(UINPUT_IOCTL_BASE, 108, compat_uptr_t)
+/*
+ * These IOCTLs change their size and thus their numbers between
+ * 32 and 64 bits.
+ */
+#define UI_SET_PHYS_COMPAT \
+   _IOW(UINPUT_IOCTL_BASE, 108, compat_uptr_t)
+#define UI_BEGIN_FF_UPLOAD_COMPAT  \
+   _IOWR(UINPUT_IOCTL_BASE, 200, struct uinput_ff_upload_compat)
+#define UI_END_FF_UPLOAD_COMPAT\
+   _IOW(UINPUT_IOCTL_BASE, 201, struct uinput_ff_upload_compat)
 
 static long uinput_compat_ioctl(struct file *file,
unsigned int cmd, unsigned long arg)
 {
-   if (cmd == UI_SET_PHYS_COMPAT)
+   switch (cmd) {
+   case UI_SET_PHYS_COMPAT:
cmd = UI_SET_PHYS;
+   break;
+   case UI_BEGIN_FF_UPLOAD_COMPAT:
+   cmd = UI_BEGIN_FF_UPLOAD;
+   break;
+   case UI_END_FF_UPLOAD_COMPAT:
+   cmd = UI_END_FF_UPLOAD;
+   break;
+   }
 
return uinput_ioctl_handler(file, cmd, arg, compat_ptr(arg));
 }




[PATCH 4.4 00/73] 4.4.185-stable review

2019-07-08 Thread Greg Kroah-Hartman
This is the start of the stable review cycle for the 4.4.185 release.
There are 73 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 Wed 10 Jul 2019 03:03:52 PM UTC.
Anything received after that time might be too late.

The whole patch series can be found in one patch at:

https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.4.185-rc1.gz
or in the git tree and branch at:

git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
linux-4.4.y
and the diffstat can be found below.

thanks,

greg k-h

-
Pseudo-Shortlog of commits:

Greg Kroah-Hartman 
Linux 4.4.185-rc1

Robin Gong 
dmaengine: imx-sdma: remove BD_INTR for channel0

Paolo Bonzini 
KVM: x86: degrade WARN to pr_warn_ratelimited

Kees Cook 
arm64, vdso: Define vdso_{start,end} as array

Vineet Gupta 
ARC: handle gcc generated __builtin_trap for older compiler

Linus Torvalds 
tty: rocket: fix incorrect forward declaration of 'rp_init()'

Nikolay Borisov 
btrfs: Ensure replaced device doesn't have pending chunk allocation

Herbert Xu 
lib/mpi: Fix karactx leak in mpi_powm

Colin Ian King 
ALSA: usb-audio: fix sign unintended sign extension on left shifts

Takashi Sakamoto 
ALSA: firewire-lib/fireworks: fix miss detection of received MIDI messages

Colin Ian King 
ALSA: seq: fix incorrect order of dest_client/dest_ports arguments

Eric Biggers 
crypto: user - prevent operating on larval algorithms

Jann Horn 
ptrace: Fix ->ptracer_cred handling for PTRACE_TRACEME

Paul Burton 
MIPS: Workaround GCC __builtin_unreachable reordering bug

Arnd Bergmann 
bug.h: work around GCC PR82365 in BUG()

Thierry Reding 
swiotlb: Make linux/swiotlb.h standalone includible

Arnd Bergmann 
mfd: omap-usb-tll: Fix register offsets

Manuel Lauss 
MIPS: math-emu: do not use bools for arithmetic

Vineet Gupta 
ARC: fix build warning in elf.h

Vineet Gupta 
ARC: Assume multiplier is always present

Don Brace 
scsi: hpsa: correct ioaccel2 chaining

Alexandre Belloni 
usb: gadget: udc: lpc32xx: allocate descriptor with GFP_ATOMIC

Young Xiao <92siuy...@gmail.com>
usb: gadget: fusb300_udc: Fix memory leak of fusb300->ep[i]

Yu-Hsuan Hsu 
ASoC: max98090: remove 24-bit format support if RJ is 0

YueHaibing 
spi: bitbang: Fix NULL pointer dereference in spi_unregister_master

Matt Flax 
ASoC : cs4265 : readable register too low

Jason A. Donenfeld 
um: Compile with modern headers

Matias Karhumaa 
Bluetooth: Fix faulty expression for minimum encryption key size check

Josh Elsasser 
net: check before dereferencing netdev_ops during busy poll

YueHaibing 
bonding: Always enable vlan tx offload

Stephen Suryaputra 
ipv4: Use return value of inet_iif() for __raw_v4_lookup in the while loop

YueHaibing 
team: Always enable vlan tx offload

Xin Long 
tipc: check msg->req data len in tipc_nl_compat_bearer_disable

Xin Long 
tipc: change to use register_pernet_device

Xin Long 
sctp: change to hold sk after auth shkey is created successfully

Geert Uytterhoeven 
cpu/speculation: Warn on unsupported mitigations= parameter

Alejandro Jimenez 
x86/speculation: Allow guests to use SSBD even if host does not

Vivek Goyal 
ovl: modify ovl_permission() to do checks on two inodes

Wanpeng Li 
KVM: X86: Fix scan ioapic use-before-initialization

Adeodato Simó 
net/9p: include trans_common.h to fix missing prototype warning.

Dominique Martinet 
9p: p9dirent_read: check network-provided name length

Dominique Martinet 
9p/rdma: remove useless check in cm_event_handler

Dominique Martinet 
9p: acl: fix uninitialized iattr access

Dominique Martinet 
9p/rdma: do not disconnect on down_interruptible EAGAIN

Arnaldo Carvalho de Melo 
perf help: Remove needless use of strncpy()

Arnaldo Carvalho de Melo 
perf ui helpline: Use strlcpy() as a shorter form of strncpy() + explicit 
set nul

Johannes Berg 
mac80211: drop robust management frames from unknown TA

Eric Biggers 
cfg80211: fix memory leak of wiphy device name

Steve French 
SMB3: retry on STATUS_INSUFFICIENT_RESOURCES instead of failing write

Marcel Holtmann 
Bluetooth: Fix regression with minimum encryption key size alignment

Marcel Holtmann 
Bluetooth: Align minimum encryption key size for LE and BR/EDR connections

Fabio Estevam 
ARM: imx: cpuidle-imx6sx: Restrict the SW2ISO increase to i.MX6SX

Willem de Bruijn 
can: purge socket error queue on sock destruct

Joakim Zhang 
can: flexcan: fix timeout when set small bitrate

Naohiro Aota 
btrfs: start readahead also in seed devices

Filipe Manana 
Btrfs: fix race between readahead and device replace/removal

Robert Hancock 
hwmon: (pmbus/core) Treat parameters as paged if on multiple pages


[PATCH 4.4 04/73] tracing: Silence GCC 9 array bounds warning

2019-07-08 Thread Greg Kroah-Hartman
From: Miguel Ojeda 

commit 0c97bf863efce63d6ab7971dad811601e6171d2f upstream.

Starting with GCC 9, -Warray-bounds detects cases when memset is called
starting on a member of a struct but the size to be cleared ends up
writing over further members.

Such a call happens in the trace code to clear, at once, all members
after and including `seq` on struct trace_iterator:

In function 'memset',
inlined from 'ftrace_dump' at kernel/trace/trace.c:8914:3:
./include/linux/string.h:344:9: warning: '__builtin_memset' offset
[8505, 8560] from the object at 'iter' is out of the bounds of
referenced subobject 'seq' with type 'struct trace_seq' at offset
4368 [-Warray-bounds]
  344 |  return __builtin_memset(p, c, size);
  | ^~~~

In order to avoid GCC complaining about it, we compute the address
ourselves by adding the offsetof distance instead of referring
directly to the member.

Since there are two places doing this clear (trace.c and trace_kdb.c),
take the chance to move the workaround into a single place in
the internal header.

Link: http://lkml.kernel.org/r/20190523124535.ga12...@gmail.com

Signed-off-by: Miguel Ojeda 
[ Removed unnecessary parenthesis around "iter" ]
Signed-off-by: Steven Rostedt (VMware) 
Signed-off-by: Greg Kroah-Hartman 

---
 kernel/trace/trace.c |6 +-
 kernel/trace/trace.h |   18 ++
 kernel/trace/trace_kdb.c |6 +-
 3 files changed, 20 insertions(+), 10 deletions(-)

--- a/kernel/trace/trace.c
+++ b/kernel/trace/trace.c
@@ -7189,12 +7189,8 @@ void ftrace_dump(enum ftrace_dump_mode o
 
cnt++;
 
-   /* reset all but tr, trace, and overruns */
-   memset(, 0,
-  sizeof(struct trace_iterator) -
-  offsetof(struct trace_iterator, seq));
+   trace_iterator_reset();
iter.iter_flags |= TRACE_FILE_LAT_FMT;
-   iter.pos = -1;
 
if (trace_find_next_entry_inc() != NULL) {
int ret;
--- a/kernel/trace/trace.h
+++ b/kernel/trace/trace.h
@@ -1381,4 +1381,22 @@ static inline void trace_event_enum_upda
 
 extern struct trace_iterator *tracepoint_print_iter;
 
+/*
+ * Reset the state of the trace_iterator so that it can read consumed data.
+ * Normally, the trace_iterator is used for reading the data when it is not
+ * consumed, and must retain state.
+ */
+static __always_inline void trace_iterator_reset(struct trace_iterator *iter)
+{
+   const size_t offset = offsetof(struct trace_iterator, seq);
+
+   /*
+* Keep gcc from complaining about overwriting more than just one
+* member in the structure.
+*/
+   memset((char *)iter + offset, 0, sizeof(struct trace_iterator) - 
offset);
+
+   iter->pos = -1;
+}
+
 #endif /* _LINUX_KERNEL_TRACE_H */
--- a/kernel/trace/trace_kdb.c
+++ b/kernel/trace/trace_kdb.c
@@ -40,12 +40,8 @@ static void ftrace_dump_buf(int skip_lin
 
kdb_printf("Dumping ftrace buffer:\n");
 
-   /* reset all but tr, trace, and overruns */
-   memset(, 0,
-  sizeof(struct trace_iterator) -
-  offsetof(struct trace_iterator, seq));
+   trace_iterator_reset();
iter.iter_flags |= TRACE_FILE_LAT_FMT;
-   iter.pos = -1;
 
if (cpu_file == RING_BUFFER_ALL_CPUS) {
for_each_tracing_cpu(cpu) {




[PATCH 4.4 03/73] scsi: vmw_pscsi: Fix use-after-free in pvscsi_queue_lck()

2019-07-08 Thread Greg Kroah-Hartman
From: Jan Kara 

commit 240b4cc8fd5db138b675297d4226ec46594d9b3b upstream.

Once we unlock adapter->hw_lock in pvscsi_queue_lck() nothing prevents just
queued scsi_cmnd from completing and freeing the request. Thus cmd->cmnd[0]
dereference can dereference already freed request leading to kernel crashes
or other issues (which one of our customers observed). Store cmd->cmnd[0]
in a local variable before unlocking adapter->hw_lock to fix the issue.

CC: 
Signed-off-by: Jan Kara 
Reviewed-by: Ewan D. Milne 
Signed-off-by: Martin K. Petersen 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/scsi/vmw_pvscsi.c |6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

--- a/drivers/scsi/vmw_pvscsi.c
+++ b/drivers/scsi/vmw_pvscsi.c
@@ -733,6 +733,7 @@ static int pvscsi_queue_lck(struct scsi_
struct pvscsi_adapter *adapter = shost_priv(host);
struct pvscsi_ctx *ctx;
unsigned long flags;
+   unsigned char op;
 
spin_lock_irqsave(>hw_lock, flags);
 
@@ -745,13 +746,14 @@ static int pvscsi_queue_lck(struct scsi_
}
 
cmd->scsi_done = done;
+   op = cmd->cmnd[0];
 
dev_dbg(>device->sdev_gendev,
-   "queued cmd %p, ctx %p, op=%x\n", cmd, ctx, cmd->cmnd[0]);
+   "queued cmd %p, ctx %p, op=%x\n", cmd, ctx, op);
 
spin_unlock_irqrestore(>hw_lock, flags);
 
-   pvscsi_kick_io(adapter, cmd->cmnd[0]);
+   pvscsi_kick_io(adapter, op);
 
return 0;
 }




[PATCH 4.4 25/73] Bluetooth: Fix regression with minimum encryption key size alignment

2019-07-08 Thread Greg Kroah-Hartman
From: Marcel Holtmann 

commit 693cd8ce3f882524a5d06f7800dd8492411877b3 upstream.

When trying to align the minimum encryption key size requirement for
Bluetooth connections, it turns out doing this in a central location in
the HCI connection handling code is not possible.

Original Bluetooth version up to 2.0 used a security model where the
L2CAP service would enforce authentication and encryption.  Starting
with Bluetooth 2.1 and Secure Simple Pairing that model has changed into
that the connection initiator is responsible for providing an encrypted
ACL link before any L2CAP communication can happen.

Now connecting Bluetooth 2.1 or later devices with Bluetooth 2.0 and
before devices are causing a regression.  The encryption key size check
needs to be moved out of the HCI connection handling into the L2CAP
channel setup.

To achieve this, the current check inside hci_conn_security() has been
moved into l2cap_check_enc_key_size() helper function and then called
from four decisions point inside L2CAP to cover all combinations of
Secure Simple Pairing enabled devices and device using legacy pairing
and legacy service security model.

Fixes: d5bb334a8e17 ("Bluetooth: Align minimum encryption key size for LE and 
BR/EDR connections")
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=203643
Signed-off-by: Marcel Holtmann 
Cc: sta...@vger.kernel.org
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman 

---
 net/bluetooth/hci_conn.c   |   18 +-
 net/bluetooth/l2cap_core.c |   33 -
 2 files changed, 37 insertions(+), 14 deletions(-)

--- a/net/bluetooth/hci_conn.c
+++ b/net/bluetooth/hci_conn.c
@@ -1177,14 +1177,6 @@ int hci_conn_check_link_mode(struct hci_
!test_bit(HCI_CONN_ENCRYPT, >flags))
return 0;
 
-   /* The minimum encryption key size needs to be enforced by the
-* host stack before establishing any L2CAP connections. The
-* specification in theory allows a minimum of 1, but to align
-* BR/EDR and LE transports, a minimum of 7 is chosen.
-*/
-   if (conn->enc_key_size < HCI_MIN_ENC_KEY_SIZE)
-   return 0;
-
return 1;
 }
 
@@ -1301,8 +1293,16 @@ auth:
return 0;
 
 encrypt:
-   if (test_bit(HCI_CONN_ENCRYPT, >flags))
+   if (test_bit(HCI_CONN_ENCRYPT, >flags)) {
+   /* Ensure that the encryption key size has been read,
+* otherwise stall the upper layer responses.
+*/
+   if (!conn->enc_key_size)
+   return 0;
+
+   /* Nothing else needed, all requirements are met */
return 1;
+   }
 
hci_conn_encrypt(conn);
return 0;
--- a/net/bluetooth/l2cap_core.c
+++ b/net/bluetooth/l2cap_core.c
@@ -1329,6 +1329,21 @@ static void l2cap_request_info(struct l2
   sizeof(req), );
 }
 
+static bool l2cap_check_enc_key_size(struct hci_conn *hcon)
+{
+   /* The minimum encryption key size needs to be enforced by the
+* host stack before establishing any L2CAP connections. The
+* specification in theory allows a minimum of 1, but to align
+* BR/EDR and LE transports, a minimum of 7 is chosen.
+*
+* This check might also be called for unencrypted connections
+* that have no key size requirements. Ensure that the link is
+* actually encrypted before enforcing a key size.
+*/
+   return (!test_bit(HCI_CONN_ENCRYPT, >flags) ||
+   hcon->enc_key_size > HCI_MIN_ENC_KEY_SIZE);
+}
+
 static void l2cap_do_start(struct l2cap_chan *chan)
 {
struct l2cap_conn *conn = chan->conn;
@@ -1346,9 +1361,14 @@ static void l2cap_do_start(struct l2cap_
if (!(conn->info_state & L2CAP_INFO_FEAT_MASK_REQ_DONE))
return;
 
-   if (l2cap_chan_check_security(chan, true) &&
-   __l2cap_no_conn_pending(chan))
+   if (!l2cap_chan_check_security(chan, true) ||
+   !__l2cap_no_conn_pending(chan))
+   return;
+
+   if (l2cap_check_enc_key_size(conn->hcon))
l2cap_start_connection(chan);
+   else
+   __set_chan_timer(chan, L2CAP_DISC_TIMEOUT);
 }
 
 static inline int l2cap_mode_supported(__u8 mode, __u32 feat_mask)
@@ -1427,7 +1447,10 @@ static void l2cap_conn_start(struct l2ca
continue;
}
 
-   l2cap_start_connection(chan);
+   if (l2cap_check_enc_key_size(conn->hcon))
+   l2cap_start_connection(chan);
+   else
+   l2cap_chan_close(chan, ECONNREFUSED);
 
} else if (chan->state == BT_CONNECT2) {
struct l2cap_conn_rsp rsp;
@@ -7432,7 +7455,7 @@ static void l2cap_security_cfm(struct hc
}
 
if (chan->state == BT_CONNECT) {
-   

[PATCH 4.4 24/73] Bluetooth: Align minimum encryption key size for LE and BR/EDR connections

2019-07-08 Thread Greg Kroah-Hartman
From: Marcel Holtmann 

commit d5bb334a8e171b262e48f378bd2096c0ea458265 upstream.

The minimum encryption key size for LE connections is 56 bits and to
align LE with BR/EDR, enforce 56 bits of minimum encryption key size for
BR/EDR connections as well.

Signed-off-by: Marcel Holtmann 
Signed-off-by: Johan Hedberg 
Cc: sta...@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman 

---
 include/net/bluetooth/hci_core.h |3 +++
 net/bluetooth/hci_conn.c |8 
 2 files changed, 11 insertions(+)

--- a/include/net/bluetooth/hci_core.h
+++ b/include/net/bluetooth/hci_core.h
@@ -174,6 +174,9 @@ struct adv_info {
 
 #define HCI_MAX_SHORT_NAME_LENGTH  10
 
+/* Min encryption key size to match with SMP */
+#define HCI_MIN_ENC_KEY_SIZE   7
+
 /* Default LE RPA expiry time, 15 minutes */
 #define HCI_DEFAULT_RPA_TIMEOUT(15 * 60)
 
--- a/net/bluetooth/hci_conn.c
+++ b/net/bluetooth/hci_conn.c
@@ -1177,6 +1177,14 @@ int hci_conn_check_link_mode(struct hci_
!test_bit(HCI_CONN_ENCRYPT, >flags))
return 0;
 
+   /* The minimum encryption key size needs to be enforced by the
+* host stack before establishing any L2CAP connections. The
+* specification in theory allows a minimum of 1, but to align
+* BR/EDR and LE transports, a minimum of 7 is chosen.
+*/
+   if (conn->enc_key_size < HCI_MIN_ENC_KEY_SIZE)
+   return 0;
+
return 1;
 }
 




[PATCH 4.4 22/73] can: purge socket error queue on sock destruct

2019-07-08 Thread Greg Kroah-Hartman
From: Willem de Bruijn 

commit fd704bd5ee749d560e86c4f1fd2ef486d8abf7cf upstream.

CAN supports software tx timestamps as of the below commit. Purge
any queued timestamp packets on socket destroy.

Fixes: 51f31cabe3ce ("ip: support for TX timestamps on UDP and RAW sockets")
Reported-by: syzbot+a90604060cb40f5bd...@syzkaller.appspotmail.com
Signed-off-by: Willem de Bruijn 
Cc: linux-stable 
Signed-off-by: Marc Kleine-Budde 
Signed-off-by: Greg Kroah-Hartman 

---
 net/can/af_can.c |1 +
 1 file changed, 1 insertion(+)

--- a/net/can/af_can.c
+++ b/net/can/af_can.c
@@ -113,6 +113,7 @@ EXPORT_SYMBOL(can_ioctl);
 static void can_sock_destruct(struct sock *sk)
 {
skb_queue_purge(>sk_receive_queue);
+   skb_queue_purge(>sk_error_queue);
 }
 
 static const struct can_proto *can_get_proto(int protocol)




[PATCH 4.4 02/73] mm/page_idle.c: fix oops because end_pfn is larger than max_pfn

2019-07-08 Thread Greg Kroah-Hartman
From: Colin Ian King 

commit 7298e3b0a149c91323b3205d325e942c3b3b9ef6 upstream.

Currently the calcuation of end_pfn can round up the pfn number to more
than the actual maximum number of pfns, causing an Oops.  Fix this by
ensuring end_pfn is never more than max_pfn.

This can be easily triggered when on systems where the end_pfn gets
rounded up to more than max_pfn using the idle-page stress-ng stress test:

sudo stress-ng --idle-page 0

  BUG: unable to handle kernel paging request at 20d8
  #PF error: [normal kernel read fault]
  PGD 0 P4D 0
  Oops:  [#1] SMP PTI
  CPU: 1 PID: 11039 Comm: stress-ng-idle- Not tainted 5.0.0-5-generic #6-Ubuntu
  Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1ubuntu1 
04/01/2014
  RIP: 0010:page_idle_get_page+0xc8/0x1a0
  Code: 0f b1 0a 75 7d 48 8b 03 48 89 c2 48 c1 e8 33 83 e0 07 48 c1 ea 36 48 8d 
0c 40 4c 8d 24 88 49 c1 e4 07 4c 03 24 d5 00 89 c3 be <49> 8b 44 24 58 48 8d b8 
80 a1 02 00 e8 07 d5 77 00 48 8b 53 08 48
  RSP: 0018:afd7c672fde8 EFLAGS: 00010202
  RAX: 0005 RBX: e36341fff700 RCX: 000f
  RDX: 0284 RSI: 0275 RDI: 01fff700
  RBP: afd7c672fe00 R08: a0bc34056410 R09: 0276
  R10: a0bc754e9b40 R11: a0bc330f6400 R12: 2080
  R13: e36341fff700 R14: 0008 R15: a0bc330f6400
  FS: 7f0ec1ea5740() GS:a0bc7db0() knlGS:
  CS: 0010 DS:  ES:  CR0: 80050033
  CR2: 20d8 CR3: 77d68000 CR4: 06e0
  Call Trace:
page_idle_bitmap_write+0x8c/0x140
sysfs_kf_bin_write+0x5c/0x70
kernfs_fop_write+0x12e/0x1b0
__vfs_write+0x1b/0x40
vfs_write+0xab/0x1b0
ksys_write+0x55/0xc0
__x64_sys_write+0x1a/0x20
do_syscall_64+0x5a/0x110
entry_SYSCALL_64_after_hwframe+0x44/0xa9

Link: http://lkml.kernel.org/r/20190618124352.28307-1-colin.k...@canonical.com
Fixes: 33c3fc71c8cf ("mm: introduce idle page tracking")
Signed-off-by: Colin Ian King 
Reviewed-by: Andrew Morton 
Acked-by: Vladimir Davydov 
Cc: Michal Hocko 
Cc: Mike Rapoport 
Cc: Mel Gorman 
Cc: Stephen Rothwell 
Cc: Andrey Ryabinin 
Cc: 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman 

---
 mm/page_idle.c |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

--- a/mm/page_idle.c
+++ b/mm/page_idle.c
@@ -130,7 +130,7 @@ static ssize_t page_idle_bitmap_read(str
 
end_pfn = pfn + count * BITS_PER_BYTE;
if (end_pfn > max_pfn)
-   end_pfn = ALIGN(max_pfn, BITMAP_CHUNK_BITS);
+   end_pfn = max_pfn;
 
for (; pfn < end_pfn; pfn++) {
bit = pfn % BITMAP_CHUNK_BITS;
@@ -175,7 +175,7 @@ static ssize_t page_idle_bitmap_write(st
 
end_pfn = pfn + count * BITS_PER_BYTE;
if (end_pfn > max_pfn)
-   end_pfn = ALIGN(max_pfn, BITMAP_CHUNK_BITS);
+   end_pfn = max_pfn;
 
for (; pfn < end_pfn; pfn++) {
bit = pfn % BITMAP_CHUNK_BITS;




[PATCH 4.4 19/73] Btrfs: fix race between readahead and device replace/removal

2019-07-08 Thread Greg Kroah-Hartman
From: Filipe Manana 

commit ce7791ffee1e1ee9f97193b817c7dd1fa6746aad upstream.

The list of devices is protected by the device_list_mutex and the device
replace code, in its finishing phase correctly takes that mutex before
removing the source device from that list. However the readahead code was
iterating that list without acquiring the respective mutex leading to
crashes later on due to invalid memory accesses:

[125671.831036] general protection fault:  [#1] PREEMPT SMP
[125671.832129] Modules linked in: btrfs dm_flakey dm_mod crc32c_generic xor 
raid6_pq acpi_cpufreq tpm_tis tpm ppdev evdev parport_pc psmouse sg parport
processor ser
[125671.834973] CPU: 10 PID: 19603 Comm: kworker/u32:19 Tainted: GW 
  4.6.0-rc7-btrfs-next-29+ #1
[125671.834973] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS by 
qemu-project.org 04/01/2014
[125671.834973] Workqueue: btrfs-readahead btrfs_readahead_helper [btrfs]
[125671.834973] task: 8801ac520540 ti: 8801ac918000 task.ti: 
8801ac918000
[125671.834973] RIP: 0010:[]  [] 
__radix_tree_lookup+0x6a/0x105
[125671.834973] RSP: 0018:8801ac91bc28  EFLAGS: 00010206
[125671.834973] RAX:  RBX: 6b6b6b6b6b6b6b6a RCX: 

[125671.834973] RDX:  RSI: 000c1bff RDI: 
88002ebd62a8
[125671.834973] RBP: 8801ac91bc70 R08: 0001 R09: 

[125671.834973] R10: 8801ac91bc70 R11:  R12: 
88002ebd62a8
[125671.834973] R13:  R14:  R15: 
000c1bff
[125671.834973] FS:  () GS:88023fd4() 
knlGS:
[125671.834973] CS:  0010 DS:  ES:  CR0: 80050033
[125671.834973] CR2: 0073cae4 CR3: b7723000 CR4: 
06e0
[125671.834973] Stack:
[125671.834973]   8801422d5600 8802286bbc00 

[125671.834973]  0001 8802286bbc00 000c1bff 

[125671.834973]  88002e639eb8 8801ac91bc80 81270541 
8801ac91bcb0
[125671.834973] Call Trace:
[125671.834973]  [] radix_tree_lookup+0xd/0xf
[125671.834973]  [] reada_peer_zones_set_lock+0x3e/0x60 
[btrfs]
[125671.834973]  [] reada_pick_zone+0x29/0x103 [btrfs]
[125671.834973]  [] reada_start_machine_worker+0x129/0x2d3 
[btrfs]
[125671.834973]  [] btrfs_scrubparity_helper+0x185/0x3aa 
[btrfs]
[125671.834973]  [] btrfs_readahead_helper+0xe/0x10 [btrfs]
[125671.834973]  [] process_one_work+0x271/0x4e9
[125671.834973]  [] worker_thread+0x1eb/0x2c9
[125671.834973]  [] ? rescuer_thread+0x2b3/0x2b3
[125671.834973]  [] kthread+0xd4/0xdc
[125671.834973]  [] ret_from_fork+0x22/0x40
[125671.834973]  [] ? kthread_stop+0x286/0x286

So fix this by taking the device_list_mutex in the readahead code. We
can't use here the lighter approach of using a rcu_read_lock() and
rcu_read_unlock() pair together with a list_for_each_entry_rcu() call
because we end up doing calls to sleeping functions (kzalloc()) in the
respective code path.

Signed-off-by: Filipe Manana 
Reviewed-by: Josef Bacik 
Signed-off-by: Greg Kroah-Hartman 

---
 fs/btrfs/reada.c |2 ++
 1 file changed, 2 insertions(+)

--- a/fs/btrfs/reada.c
+++ b/fs/btrfs/reada.c
@@ -764,12 +764,14 @@ static void __reada_start_machine(struct
 
do {
enqueued = 0;
+   mutex_lock(_devices->device_list_mutex);
list_for_each_entry(device, _devices->devices, dev_list) {
if (atomic_read(>reada_in_flight) <
MAX_IN_FLIGHT)
enqueued += reada_start_machine_dev(fs_info,
device);
}
+   mutex_unlock(_devices->device_list_mutex);
total += enqueued;
} while (enqueued && total < 1);
 




[PATCH 4.4 21/73] can: flexcan: fix timeout when set small bitrate

2019-07-08 Thread Greg Kroah-Hartman
From: Joakim Zhang 

commit 247e5356a709eb49a0d95ff2a7f07dac05c8252c upstream.

Current we can meet timeout issue when setting a small bitrate like
1 as follows on i.MX6UL EVK board (ipg clock = 66MHZ, per clock =
30MHZ):

| root@imx6ul7d:~# ip link set can0 up type can bitrate 1

A link change request failed with some changes committed already.
Interface can0 may have been left with an inconsistent configuration,
please check.

| RTNETLINK answers: Connection timed out

It is caused by calling of flexcan_chip_unfreeze() timeout.

Originally the code is using usleep_range(10, 20) for unfreeze
operation, but the patch (8badd65 can: flexcan: avoid calling
usleep_range from interrupt context) changed it into udelay(10) which is
only a half delay of before, there're also some other delay changes.

After double to FLEXCAN_TIMEOUT_US to 100 can fix the issue.

Meanwhile, Rasmus Villemoes reported that even with a timeout of 100,
flexcan_probe() fails on the MPC8309, which requires a value of at least
140 to work reliably. 250 works for everyone.

Signed-off-by: Joakim Zhang 
Reviewed-by: Dong Aisheng 
Cc: linux-stable 
Signed-off-by: Marc Kleine-Budde 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/net/can/flexcan.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/net/can/flexcan.c
+++ b/drivers/net/can/flexcan.c
@@ -171,7 +171,7 @@
 #define FLEXCAN_MB_CNT_LENGTH(x)   (((x) & 0xf) << 16)
 #define FLEXCAN_MB_CNT_TIMESTAMP(x)((x) & 0x)
 
-#define FLEXCAN_TIMEOUT_US (50)
+#define FLEXCAN_TIMEOUT_US (250)
 
 /* FLEXCAN hardware feature flags
  *




[PATCH 4.4 20/73] btrfs: start readahead also in seed devices

2019-07-08 Thread Greg Kroah-Hartman
From: Naohiro Aota 

commit c4e0540d0ad49c8ceab06cceed1de27c4fe29f6e upstream.

Currently, btrfs does not consult seed devices to start readahead. As a
result, if readahead zone is added to the seed devices, btrfs_reada_wait()
indefinitely wait for the reada_ctl to finish.

You can reproduce the hung by modifying btrfs/163 to have larger initial
file size (e.g. xfs_io pwrite 4M instead of current 256K).

Fixes: 7414a03fbf9e ("btrfs: initial readahead code and prototypes")
Cc: sta...@vger.kernel.org # 3.2+: ce7791ffee1e: Btrfs: fix race between 
readahead and device replace/removal
Cc: sta...@vger.kernel.org # 3.2+
Reviewed-by: Filipe Manana 
Signed-off-by: Naohiro Aota 
Signed-off-by: David Sterba 
Signed-off-by: Greg Kroah-Hartman 

---
 fs/btrfs/reada.c |5 +
 1 file changed, 5 insertions(+)

--- a/fs/btrfs/reada.c
+++ b/fs/btrfs/reada.c
@@ -762,6 +762,7 @@ static void __reada_start_machine(struct
u64 total = 0;
int i;
 
+again:
do {
enqueued = 0;
mutex_lock(_devices->device_list_mutex);
@@ -774,6 +775,10 @@ static void __reada_start_machine(struct
mutex_unlock(_devices->device_list_mutex);
total += enqueued;
} while (enqueued && total < 1);
+   if (fs_devices->seed) {
+   fs_devices = fs_devices->seed;
+   goto again;
+   }
 
if (enqueued == 0)
return;




[PATCH 4.4 18/73] hwmon: (pmbus/core) Treat parameters as paged if on multiple pages

2019-07-08 Thread Greg Kroah-Hartman
[ Upstream commit 4a60570dce658e3f8885bbcf852430b99f65aca5 ]

Some chips have attributes which exist on more than one page but the
attribute is not presently marked as paged. This causes the attributes
to be generated with the same label, which makes it impossible for
userspace to tell them apart.

Marking all such attributes as paged would result in the page suffix
being added regardless of whether they were present on more than one
page or not, which might break existing setups. Therefore, we add a
second check which treats the attribute as paged, even if not marked as
such, if it is present on multiple pages.

Fixes: b4ce237b7f7d ("hwmon: (pmbus) Introduce infrastructure to detect sensors 
and limit registers")
Signed-off-by: Robert Hancock 
Signed-off-by: Guenter Roeck 
Signed-off-by: Sasha Levin 
---
 drivers/hwmon/pmbus/pmbus_core.c | 34 
 1 file changed, 30 insertions(+), 4 deletions(-)

diff --git a/drivers/hwmon/pmbus/pmbus_core.c b/drivers/hwmon/pmbus/pmbus_core.c
index c00bad02761a..0d75bc7b5065 100644
--- a/drivers/hwmon/pmbus/pmbus_core.c
+++ b/drivers/hwmon/pmbus/pmbus_core.c
@@ -1028,14 +1028,15 @@ static int pmbus_add_sensor_attrs_one(struct i2c_client 
*client,
  const struct pmbus_driver_info *info,
  const char *name,
  int index, int page,
- const struct pmbus_sensor_attr *attr)
+ const struct pmbus_sensor_attr *attr,
+ bool paged)
 {
struct pmbus_sensor *base;
int ret;
 
if (attr->label) {
ret = pmbus_add_label(data, name, index, attr->label,
- attr->paged ? page + 1 : 0);
+ paged ? page + 1 : 0);
if (ret)
return ret;
}
@@ -1067,6 +1068,30 @@ static int pmbus_add_sensor_attrs_one(struct i2c_client 
*client,
return 0;
 }
 
+static bool pmbus_sensor_is_paged(const struct pmbus_driver_info *info,
+ const struct pmbus_sensor_attr *attr)
+{
+   int p;
+
+   if (attr->paged)
+   return true;
+
+   /*
+* Some attributes may be present on more than one page despite
+* not being marked with the paged attribute. If that is the case,
+* then treat the sensor as being paged and add the page suffix to the
+* attribute name.
+* We don't just add the paged attribute to all such attributes, in
+* order to maintain the un-suffixed labels in the case where the
+* attribute is only on page 0.
+*/
+   for (p = 1; p < info->pages; p++) {
+   if (info->func[p] & attr->func)
+   return true;
+   }
+   return false;
+}
+
 static int pmbus_add_sensor_attrs(struct i2c_client *client,
  struct pmbus_data *data,
  const char *name,
@@ -1080,14 +1105,15 @@ static int pmbus_add_sensor_attrs(struct i2c_client 
*client,
index = 1;
for (i = 0; i < nattrs; i++) {
int page, pages;
+   bool paged = pmbus_sensor_is_paged(info, attrs);
 
-   pages = attrs->paged ? info->pages : 1;
+   pages = paged ? info->pages : 1;
for (page = 0; page < pages; page++) {
if (!(info->func[page] & attrs->func))
continue;
ret = pmbus_add_sensor_attrs_one(client, data, info,
 name, index, page,
-attrs);
+attrs, paged);
if (ret)
return ret;
index++;
-- 
2.20.1





[PATCH 4.4 17/73] s390/qeth: fix VLAN attribute in bridge_hostnotify udev event

2019-07-08 Thread Greg Kroah-Hartman
[ Upstream commit 335726195e460cb6b3f795b695bfd31f0ea70ef0 ]

Enabling sysfs attribute bridge_hostnotify triggers a series of udev events
for the MAC addresses of all currently connected peers. In case no VLAN is
set for a peer, the device reports the corresponding MAC addresses with
VLAN ID 4096. This currently results in attribute VLAN=4096 for all
non-VLAN interfaces in the initial series of events after host-notify is
enabled.

Instead, no VLAN attribute should be reported in the udev event for
non-VLAN interfaces.

Only the initial events face this issue. For dynamic changes that are
reported later, the device uses a validity flag.

This also changes the code so that it now sets the VLAN attribute for
MAC addresses with VID 0. On Linux, no qeth interface will ever be
registered with VID 0: Linux kernel registers VID 0 on all network
interfaces initially, but qeth will drop .ndo_vlan_rx_add_vid for VID 0.
Peers with other OSs could register MACs with VID 0.

Fixes: 9f48b9db9a22 ("qeth: bridgeport support - address notifications")
Signed-off-by: Alexandra Winter 
Signed-off-by: Julian Wiedmann 
Signed-off-by: David S. Miller 
Signed-off-by: Sasha Levin 
---
 drivers/s390/net/qeth_l2_main.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/s390/net/qeth_l2_main.c b/drivers/s390/net/qeth_l2_main.c
index 34d3b7aff513..22045e7d78ac 100644
--- a/drivers/s390/net/qeth_l2_main.c
+++ b/drivers/s390/net/qeth_l2_main.c
@@ -2112,7 +2112,7 @@ static void qeth_bridgeport_an_set_cb(void *priv,
 
l2entry = (struct qdio_brinfo_entry_l2 *)entry;
code = IPA_ADDR_CHANGE_CODE_MACADDR;
-   if (l2entry->addr_lnid.lnid)
+   if (l2entry->addr_lnid.lnid < VLAN_N_VID)
code |= IPA_ADDR_CHANGE_CODE_VLANID;
qeth_bridge_emit_host_event(card, anev_reg_unreg, code,
(struct net_if_token *)>nit,
-- 
2.20.1





[PATCH 4.4 16/73] scsi: ufs: Check that space was properly alloced in copy_query_response

2019-07-08 Thread Greg Kroah-Hartman
[ Upstream commit 1c90836f70f9a8ef7b7ad9e1fdd8961903e6ced6 ]

struct ufs_dev_cmd is the main container that supports device management
commands. In the case of a read descriptor request, we assume that the
proper space was allocated in dev_cmd to hold the returning descriptor.

This is no longer true, as there are flows that doesn't use dev_cmd for
device management requests, and was wrong in the first place.

Fixes: d44a5f98bb49 (ufs: query descriptor API)
Signed-off-by: Avri Altman 
Reviewed-by: Alim Akhtar 
Acked-by: Bean Huo 
Signed-off-by: Martin K. Petersen 
Signed-off-by: Sasha Levin 
---
 drivers/scsi/ufs/ufshcd.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
index 7322a17660d1..b140e81c4f7d 100644
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -853,7 +853,8 @@ int ufshcd_copy_query_response(struct ufs_hba *hba, struct 
ufshcd_lrb *lrbp)
memcpy(_res->upiu_res, >ucd_rsp_ptr->qr, QUERY_OSF_SIZE);
 
/* Get the descriptor */
-   if (lrbp->ucd_rsp_ptr->qr.opcode == UPIU_QUERY_OPCODE_READ_DESC) {
+   if (hba->dev_cmd.query.descriptor &&
+   lrbp->ucd_rsp_ptr->qr.opcode == UPIU_QUERY_OPCODE_READ_DESC) {
u8 *descp = (u8 *)lrbp->ucd_rsp_ptr +
GENERAL_UPIU_REQUEST_SIZE;
u16 resp_len;
-- 
2.20.1





[PATCH 4.4 15/73] scripts/checkstack.pl: Fix arm64 wrong or unknown architecture

2019-07-08 Thread Greg Kroah-Hartman
[ Upstream commit 4f45d62a52297b10ded963412a158685647ecdec ]

The following error occurs for the `make ARCH=arm64 checkstack` case:

aarch64-linux-gnu-objdump -d vmlinux $(find . -name '*.ko') | \
perl ./scripts/checkstack.pl arm64
wrong or unknown architecture "arm64"

As suggested by Masahiro Yamada, fix the above error using regular
expressions in the same way it was fixed for the `ARCH=x86` case via
commit fda9f9903be6 ("scripts/checkstack.pl: automatically handle
32-bit and 64-bit mode for ARCH=x86").

Suggested-by: Masahiro Yamada 
Signed-off-by: George G. Davis 
Signed-off-by: Masahiro Yamada 
Signed-off-by: Sasha Levin 
---
 scripts/checkstack.pl | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/scripts/checkstack.pl b/scripts/checkstack.pl
index 12a6940741fe..b8f616545277 100755
--- a/scripts/checkstack.pl
+++ b/scripts/checkstack.pl
@@ -45,7 +45,7 @@ my (@stack, $re, $dre, $x, $xs, $funcre);
$x  = "[0-9a-f]";   # hex character
$xs = "[0-9a-f ]";  # hex character or space
$funcre = qr/^$x* <(.*)>:$/;
-   if ($arch eq 'aarch64') {
+   if ($arch =~ '^(aarch|arm)64$') {
#ffc0006325cc:   a9bb7bfdstp x29, x30, [sp, 
#-80]!
$re = qr/^.*stp.*sp, \#-([0-9]{1,8})\]\!/o;
} elsif ($arch eq 'arm') {
-- 
2.20.1





[PATCH 4.4 12/73] MIPS: uprobes: remove set but not used variable epc

2019-07-08 Thread Greg Kroah-Hartman
[ Upstream commit f532beeeff0c0a3586cc15538bc52d249eb19e7c ]

Fixes gcc '-Wunused-but-set-variable' warning:

arch/mips/kernel/uprobes.c: In function 'arch_uprobe_pre_xol':
arch/mips/kernel/uprobes.c:115:17: warning: variable 'epc' set but not used 
[-Wunused-but-set-variable]

It's never used since introduction in
commit 40e084a506eb ("MIPS: Add uprobes support.")

Signed-off-by: YueHaibing 
Signed-off-by: Paul Burton 
Cc: 
Cc: 
Cc: 
Cc: 
Signed-off-by: Sasha Levin 
---
 arch/mips/kernel/uprobes.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/arch/mips/kernel/uprobes.c b/arch/mips/kernel/uprobes.c
index 4e7b89f2e244..1363d705cc8c 100644
--- a/arch/mips/kernel/uprobes.c
+++ b/arch/mips/kernel/uprobes.c
@@ -164,9 +164,6 @@ int arch_uprobe_pre_xol(struct arch_uprobe *aup, struct 
pt_regs *regs)
 */
aup->resume_epc = regs->cp0_epc + 4;
if (insn_has_delay_slot((union mips_instruction) aup->insn[0])) {
-   unsigned long epc;
-
-   epc = regs->cp0_epc;
__compute_return_epc_for_insn(regs,
(union mips_instruction) aup->insn[0]);
aup->resume_epc = regs->cp0_epc;
-- 
2.20.1





[PATCH 4.4 01/73] fs/binfmt_flat.c: make load_flat_shared_library() work

2019-07-08 Thread Greg Kroah-Hartman
From: Jann Horn 

commit 867bfa4a5fcee66f2b25639acae718e8b28b25a5 upstream.

load_flat_shared_library() is broken: It only calls load_flat_file() if
prepare_binprm() returns zero, but prepare_binprm() returns the number of
bytes read - so this only happens if the file is empty.

Instead, call into load_flat_file() if the number of bytes read is
non-negative. (Even if the number of bytes is zero - in that case,
load_flat_file() will see nullbytes and return a nice -ENOEXEC.)

In addition, remove the code related to bprm creds and stop using
prepare_binprm() - this code is loading a library, not a main executable,
and it only actually uses the members "buf", "file" and "filename" of the
linux_binprm struct. Instead, call kernel_read() directly.

Link: http://lkml.kernel.org/r/20190524201817.16509-1-ja...@google.com
Fixes: 287980e49ffc ("remove lots of IS_ERR_VALUE abuses")
Signed-off-by: Jann Horn 
Cc: Alexander Viro 
Cc: Kees Cook 
Cc: Nicolas Pitre 
Cc: Arnd Bergmann 
Cc: Geert Uytterhoeven 
Cc: Russell King 
Cc: Greg Ungerer 
Cc: 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman 

---
 fs/binfmt_flat.c |   24 +++-
 1 file changed, 7 insertions(+), 17 deletions(-)

--- a/fs/binfmt_flat.c
+++ b/fs/binfmt_flat.c
@@ -808,9 +808,14 @@ err:
 
 static int load_flat_shared_library(int id, struct lib_info *libs)
 {
+   /*
+* This is a fake bprm struct; only the members "buf", "file" and
+* "filename" are actually used.
+*/
struct linux_binprm bprm;
int res;
char buf[16];
+   loff_t pos = 0;
 
memset(, 0, sizeof(bprm));
 
@@ -824,25 +829,10 @@ static int load_flat_shared_library(int
if (IS_ERR(bprm.file))
return res;
 
-   bprm.cred = prepare_exec_creds();
-   res = -ENOMEM;
-   if (!bprm.cred)
-   goto out;
-
-   /* We don't really care about recalculating credentials at this point
-* as we're past the point of no return and are dealing with shared
-* libraries.
-*/
-   bprm.cred_prepared = 1;
-
-   res = prepare_binprm();
-
-   if (!IS_ERR_VALUE(res))
+   res = kernel_read(bprm.file, pos, bprm.buf, BINPRM_BUF_SIZE);
+   if (res >= 0)
res = load_flat_file(, libs, id, NULL);
 
-   abort_creds(bprm.cred);
-
-out:
allow_write_access(bprm.file);
fput(bprm.file);
 




[PATCH 4.4 11/73] IB/hfi1: Insure freeze_work work_struct is canceled on shutdown

2019-07-08 Thread Greg Kroah-Hartman
[ Upstream commit 6d517353c70bb0818b691ca003afdcb5ee5ea44e ]

By code inspection, the freeze_work is never canceled.

Fix by adding a cancel_work_sync in the shutdown path to insure it is no
longer running.

Fixes: 7724105686e7 ("IB/hfi1: add driver files")
Reviewed-by: Michael J. Ruhl 
Reviewed-by: Dennis Dalessandro 
Signed-off-by: Mike Marciniszyn 
Signed-off-by: Dennis Dalessandro 
Signed-off-by: Jason Gunthorpe 
Signed-off-by: Sasha Levin 
---
 drivers/staging/rdma/hfi1/chip.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/staging/rdma/hfi1/chip.c b/drivers/staging/rdma/hfi1/chip.c
index e48981994b10..e1531feb6c5d 100644
--- a/drivers/staging/rdma/hfi1/chip.c
+++ b/drivers/staging/rdma/hfi1/chip.c
@@ -5906,6 +5906,7 @@ void hfi1_quiet_serdes(struct hfi1_pportdata *ppd)
 
/* disable the port */
clear_rcvctrl(dd, RCV_CTRL_RCV_PORT_ENABLE_SMASK);
+   cancel_work_sync(>freeze_work);
 }
 
 static inline int init_cpu_counters(struct hfi1_devdata *dd)
-- 
2.20.1





[PATCH 4.4 10/73] parisc: Fix compiler warnings in float emulation code

2019-07-08 Thread Greg Kroah-Hartman
[ Upstream commit 6b98d9134e14f5ef4bcf64b27eedf484ed19a1ec ]

Avoid such compiler warnings:
arch/parisc/math-emu/cnv_float.h:71:27: warning: ‘<<’ in boolean context, did 
you mean ‘<’ ? [-Wint-in-bool-context]
 ((Dintp1(dint_valueA) << 33 - SGL_EXP_LENGTH) || Dintp2(dint_valueB))
arch/parisc/math-emu/fcnvxf.c:257:6: note: in expansion of macro 
‘Dint_isinexact_to_sgl’
  if (Dint_isinexact_to_sgl(srcp1,srcp2)) {

Signed-off-by: Helge Deller 
Signed-off-by: Sasha Levin 
---
 arch/parisc/math-emu/cnv_float.h | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/parisc/math-emu/cnv_float.h b/arch/parisc/math-emu/cnv_float.h
index 933423fa5144..b0db61188a61 100644
--- a/arch/parisc/math-emu/cnv_float.h
+++ b/arch/parisc/math-emu/cnv_float.h
@@ -60,19 +60,19 @@
 ((exponent < (SGL_P - 1)) ?\
  (Sall(sgl_value) << (SGL_EXP_LENGTH + 1 + exponent)) : FALSE)
 
-#define Int_isinexact_to_sgl(int_value)(int_value << 33 - 
SGL_EXP_LENGTH)
+#define Int_isinexact_to_sgl(int_value)((int_value << 33 - 
SGL_EXP_LENGTH) != 0)
 
 #define Sgl_roundnearest_from_int(int_value,sgl_value) \
 if (int_value & 1<<(SGL_EXP_LENGTH - 2))   /* round bit */ \
-   if ((int_value << 34 - SGL_EXP_LENGTH) || Slow(sgl_value))  \
+   if (((int_value << 34 - SGL_EXP_LENGTH) != 0) || Slow(sgl_value)) \
Sall(sgl_value)++
 
 #define Dint_isinexact_to_sgl(dint_valueA,dint_valueB) \
-((Dintp1(dint_valueA) << 33 - SGL_EXP_LENGTH) || Dintp2(dint_valueB))
+(((Dintp1(dint_valueA) << 33 - SGL_EXP_LENGTH) != 0) || 
Dintp2(dint_valueB))
 
 #define Sgl_roundnearest_from_dint(dint_valueA,dint_valueB,sgl_value)  \
 if (Dintp1(dint_valueA) & 1<<(SGL_EXP_LENGTH - 2)) 
\
-   if ((Dintp1(dint_valueA) << 34 - SGL_EXP_LENGTH) || \
+   if (((Dintp1(dint_valueA) << 34 - SGL_EXP_LENGTH) != 0) ||  \
Dintp2(dint_valueB) || Slow(sgl_value)) Sall(sgl_value)++
 
 #define Dint_isinexact_to_dbl(dint_value)  \
-- 
2.20.1





Re: [PATCH] tpm: fixes uninitialized allocated banks for IBM vtpm driver

2019-07-08 Thread Jarkko Sakkinen
On Sat, 2019-07-06 at 20:25 -0400, Nayna wrote:
> Thanks Jarkko. I just now posted the v2 version that includes your and
> Stefan's feedbacks.

Looks almost legit :-)

/Jarkko



Re: [PATCH v2] tpm: tpm_ibm_vtpm: Fix unallocated banks

2019-07-08 Thread Jarkko Sakkinen
On Sat, 2019-07-06 at 20:18 -0400, Nayna Jain wrote:
> +/*
> + * tpm_get_pcr_allocation() - initialize the chip allocated banks for PCRs
> + * @chip: TPM chip to use.
> + */
> +static int tpm_get_pcr_allocation(struct tpm_chip *chip)
> +{
> + int rc;
> +
> + if (chip->flags & TPM_CHIP_FLAG_TPM2)
> + rc = tpm2_get_pcr_allocation(chip);
> + else
> + rc = tpm1_get_pcr_allocation(chip);
> +
> + return rc;
> +}

It is just a trivial static function, which means that kdoc comment is
not required and neither it is useful. Please remove that. I would
rewrite the function like:

static int tpm_get_pcr_allocation(struct tpm_chip *chip)
{
int rc;

rc = (chip->flags & TPM_CHIP_FLAG_TPM2) ?
 tpm2_get_pcr_allocation(chip) :
 tpm1_get_pcr_allocation(chip);

return rc > 0 ? -ENODEV : rc;
}

This addresses the issue that Stefan also pointed out. You have to
deal with the TPM error codes.

/Jarkko



Re: [PATCH v7 10/12] KVM/x86/lbr: lazy save the guest lbr stack

2019-07-08 Thread Andi Kleen
> I don't understand a word of that.
> 
> Who cares if the LBR MSRs are touched; the guest expects up-to-date
> values when it does reads them.

This is for only when the LBRs are disabled in the guest.

It doesn't make sense to constantly save/restore disabled LBRs, which
would be a large overhead for guests that don't use LBRs. 

When the LBRs are enabled they always need to be saved/restored as you
say.

-Andi


Re: [PATCH net-next 1/2] bpf: skip sockopt hooks without CONFIG_NET

2019-07-08 Thread Yonghong Song


On 7/8/19 5:57 AM, Arnd Bergmann wrote:
> When CONFIG_NET is disabled, we get a link error:
> 
> kernel/bpf/cgroup.o: In function `__cgroup_bpf_run_filter_setsockopt':
> cgroup.c:(.text+0x3010): undefined reference to `lock_sock_nested'
> cgroup.c:(.text+0x3258): undefined reference to `release_sock'
> kernel/bpf/cgroup.o: In function `__cgroup_bpf_run_filter_getsockopt':
> cgroup.c:(.text+0x3568): undefined reference to `lock_sock_nested'
> cgroup.c:(.text+0x3870): undefined reference to `release_sock'
> kernel/bpf/cgroup.o: In function `cg_sockopt_func_proto':
> cgroup.c:(.text+0x41d8): undefined reference to `bpf_sk_storage_delete_proto'
> 
> None of this code is useful in this configuration anyway, so we can
> simply hide it in an appropriate #ifdef.
> 
> Fixes: 0d01da6afc54 ("bpf: implement getsockopt and setsockopt hooks")
> Signed-off-by: Arnd Bergmann 

FYI.

There is already a patch to fix the same issue,
https://lore.kernel.org/bpf/e9e489fe-feec-a211-82aa-5df0c6a30...@huawei.com/T/#t

which has been acked and not merged yet.

> ---
>   include/linux/bpf_types.h | 2 ++
>   kernel/bpf/cgroup.c   | 6 ++
>   2 files changed, 8 insertions(+)
> 
> diff --git a/include/linux/bpf_types.h b/include/linux/bpf_types.h
> index eec5aeeeaf92..3c7222b2db96 100644
> --- a/include/linux/bpf_types.h
> +++ b/include/linux/bpf_types.h
> @@ -30,8 +30,10 @@ BPF_PROG_TYPE(BPF_PROG_TYPE_RAW_TRACEPOINT_WRITABLE, 
> raw_tracepoint_writable)
>   #ifdef CONFIG_CGROUP_BPF
>   BPF_PROG_TYPE(BPF_PROG_TYPE_CGROUP_DEVICE, cg_dev)
>   BPF_PROG_TYPE(BPF_PROG_TYPE_CGROUP_SYSCTL, cg_sysctl)
> +#ifdef CONFIG_NET
>   BPF_PROG_TYPE(BPF_PROG_TYPE_CGROUP_SOCKOPT, cg_sockopt)
>   #endif
> +#endif
>   #ifdef CONFIG_BPF_LIRC_MODE2
>   BPF_PROG_TYPE(BPF_PROG_TYPE_LIRC_MODE2, lirc_mode2)
>   #endif
> diff --git a/kernel/bpf/cgroup.c b/kernel/bpf/cgroup.c
> index 76fa0076f20d..7be44460bd93 100644
> --- a/kernel/bpf/cgroup.c
> +++ b/kernel/bpf/cgroup.c
> @@ -590,6 +590,7 @@ int cgroup_bpf_prog_query(const union bpf_attr *attr,
>   return ret;
>   }
>   
> +#ifdef CONFIG_NET
>   /**
>* __cgroup_bpf_run_filter_skb() - Run a program for packet filtering
>* @sk: The socket sending or receiving traffic
> @@ -750,6 +751,7 @@ int __cgroup_bpf_run_filter_sock_ops(struct sock *sk,
>   return ret == 1 ? 0 : -EPERM;
>   }
>   EXPORT_SYMBOL(__cgroup_bpf_run_filter_sock_ops);
> +#endif
>   
>   int __cgroup_bpf_check_dev_permission(short dev_type, u32 major, u32 minor,
> short access, enum bpf_attach_type type)
> @@ -939,6 +941,7 @@ int __cgroup_bpf_run_filter_sysctl(struct 
> ctl_table_header *head,
>   }
>   EXPORT_SYMBOL(__cgroup_bpf_run_filter_sysctl);
>   
> +#ifdef CONFIG_NET
>   static bool __cgroup_bpf_prog_array_is_empty(struct cgroup *cgrp,
>enum bpf_attach_type attach_type)
>   {
> @@ -1120,6 +1123,7 @@ int __cgroup_bpf_run_filter_getsockopt(struct sock *sk, 
> int level,
>   return ret;
>   }
>   EXPORT_SYMBOL(__cgroup_bpf_run_filter_getsockopt);
> +#endif
>   
>   static ssize_t sysctl_cpy_dir(const struct ctl_dir *dir, char **bufp,
> size_t *lenp)
> @@ -1382,6 +1386,7 @@ const struct bpf_verifier_ops cg_sysctl_verifier_ops = {
>   const struct bpf_prog_ops cg_sysctl_prog_ops = {
>   };
>   
> +#ifdef CONFIG_NET
>   static const struct bpf_func_proto *
>   cg_sockopt_func_proto(enum bpf_func_id func_id, const struct bpf_prog *prog)
>   {
> @@ -1531,3 +1536,4 @@ const struct bpf_verifier_ops cg_sockopt_verifier_ops = 
> {
>   
>   const struct bpf_prog_ops cg_sockopt_prog_ops = {
>   };
> +#endif
> 


Re: [PATCH bpf-next 1/2] bpf, libbpf: add a new API bpf_object__reuse_maps()

2019-07-08 Thread Anton Protopopov
пт, 5 июл. 2019 г. в 17:44, Daniel Borkmann :
>
> On 07/05/2019 10:44 PM, Anton Protopopov wrote:
> > Add a new API bpf_object__reuse_maps() which can be used to replace all 
> > maps in
> > an object by maps pinned to a directory provided in the path argument.  
> > Namely,
> > each map M in the object will be replaced by a map pinned to path/M.name.
> >
> > Signed-off-by: Anton Protopopov 
> > ---
> >  tools/lib/bpf/libbpf.c   | 34 ++
> >  tools/lib/bpf/libbpf.h   |  2 ++
> >  tools/lib/bpf/libbpf.map |  1 +
> >  3 files changed, 37 insertions(+)
> >
> > diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c
> > index 4907997289e9..84c9e8f7bfd3 100644
> > --- a/tools/lib/bpf/libbpf.c
> > +++ b/tools/lib/bpf/libbpf.c
> > @@ -3144,6 +3144,40 @@ int bpf_object__unpin_maps(struct bpf_object *obj, 
> > const char *path)
> >   return 0;
> >  }
> >
> > +int bpf_object__reuse_maps(struct bpf_object *obj, const char *path)
> > +{
> > + struct bpf_map *map;
> > +
> > + if (!obj)
> > + return -ENOENT;
> > +
> > + if (!path)
> > + return -EINVAL;
> > +
> > + bpf_object__for_each_map(map, obj) {
> > + int len, err;
> > + int pinned_map_fd;
> > + char buf[PATH_MAX];
>
> We'd need to skip the case of bpf_map__is_internal(map) since they are always
> recreated for the given object.
>
> > + len = snprintf(buf, PATH_MAX, "%s/%s", path, 
> > bpf_map__name(map));
> > + if (len < 0) {
> > + return -EINVAL;
> > + } else if (len >= PATH_MAX) {
> > + return -ENAMETOOLONG;
> > + }
> > +
> > + pinned_map_fd = bpf_obj_get(buf);
> > + if (pinned_map_fd < 0)
> > + return pinned_map_fd;
>
> Should we rather have a new map definition attribute that tells to reuse
> the map if it's pinned in bpf fs, and if not, we create it and later on
> pin it? This is what iproute2 is doing and which we're making use of heavily.

What do you think about adding a new generic field, say load_flags,
to the bpf_map_def structure and a particular flag, say LOAD_F_STICKY
for this purpose? And it will be cleared for internal maps, so we will skip
them as well.

> In bpf_object__reuse_maps() bailing out if bpf_obj_get() fails is perhaps
> too limiting for a generic API as new version of an object file may contain
> new maps which are not yet present in bpf fs at that point.

How permissive should it be? Is it ok to just print a warning on any
bpf_obj_get()
failure? Or does it make sense to skip some specific error (ENOENT) and reject
on other errors?

>
> > + err = bpf_map__reuse_fd(map, pinned_map_fd);
> > + if (err)
> > + return err;
> > + }
> > +
> > + return 0;
> > +}
> > +
> >  int bpf_object__pin_programs(struct bpf_object *obj, const char *path)
> >  {
> >   struct bpf_program *prog;
> > diff --git a/tools/lib/bpf/libbpf.h b/tools/lib/bpf/libbpf.h
> > index d639f47e3110..7fe465a1be76 100644
> > --- a/tools/lib/bpf/libbpf.h
> > +++ b/tools/lib/bpf/libbpf.h
> > @@ -82,6 +82,8 @@ int bpf_object__variable_offset(const struct bpf_object 
> > *obj, const char *name,
> >  LIBBPF_API int bpf_object__pin_maps(struct bpf_object *obj, const char 
> > *path);
> >  LIBBPF_API int bpf_object__unpin_maps(struct bpf_object *obj,
> > const char *path);
> > +LIBBPF_API int bpf_object__reuse_maps(struct bpf_object *obj,
> > +   const char *path);
> >  LIBBPF_API int bpf_object__pin_programs(struct bpf_object *obj,
> >   const char *path);
> >  LIBBPF_API int bpf_object__unpin_programs(struct bpf_object *obj,
> > diff --git a/tools/lib/bpf/libbpf.map b/tools/lib/bpf/libbpf.map
> > index 2c6d835620d2..66a30be6696c 100644
> > --- a/tools/lib/bpf/libbpf.map
> > +++ b/tools/lib/bpf/libbpf.map
> > @@ -172,5 +172,6 @@ LIBBPF_0.0.4 {
> >   btf_dump__new;
> >   btf__parse_elf;
> >   bpf_object__load_xattr;
> > + bpf_object__reuse_maps;
> >   libbpf_num_possible_cpus;
> >  } LIBBPF_0.0.3;
> >
>


Re: linux-next: build failure after merge of the usb and usb-gadget trees

2019-07-08 Thread Sekhar Nori
On 04/07/19 1:55 PM, Felipe Balbi wrote:
> 
> Hi,
> 
> Pawel Laszczak  writes:
> 
>>>
>>> Hi,
>>>
>>> On Thu, Jul 4, 2019 at 9:59 AM Greg KH  wrote:

 On Thu, Jul 04, 2019 at 04:34:58PM +1000, Stephen Rothwell wrote:
> Hi all,
>
> After merging the usb tree, today's linux-next build (arm
> multi_v7_defconfig) failed like this:
>
> arm-linux-gnueabi-ld: drivers/usb/dwc3/trace.o: in function 
> `trace_raw_output_dwc3_log_ctrl':
> trace.c:(.text+0x119c): undefined reference to `usb_decode_ctrl'
>
> Caused by commit
>
>   3db1b636c07e ("usb:gadget Separated decoding functions from dwc3 
> driver.")
>
> I have used the usb tree from next-20190703 for today.
>
> This also occurs in the usb-gadget tree so I have used the version of
> that from next-20190703 as well.

 Odd, I thought I pulled the usb-gadget tree into mine.  Felipe, can you
 take a look at this to see if I messed something up?
>>>
>>> This looks like it was caused by Pawel's patches.
>>>
>>> I'll try to reproduce here and see what's causing it.
>>
>> Problem is in my Patch. I reproduced it, but I don't understand why compiler 
>> complains about usb_decode_ctrl. It's compiled into libcomposite.ko and
>> declaration is in drivers/usb/gadget.h. 
> 
> That's because in multi_v7_defconfig dwc3 is built-in while libcomposite
> is a module:
> 
> CONFIG_USB_DWC3=y
> CONFIG_USB_LIBCOMPOSITE=m
> 
> 
> I remember that when you were doing this work, I asked you to move
> functions to usb/common. Why did you deviate from that suggestion? It's
> clear that decoding a ctrl request can be used by peripheral and host
> and we wouldn't have to deal with this problem if you had just followed
> the suggestion.
> 
> Now we have to come up with a way to fix this that doesn't involve
> reverting my part2 tag in its entirety because there are other important
> things there.
> 
> This is what I get for trusting people to do their part. I couldn't even
> compile test this since I don't have ARM compilers anymore (actually,
> just installed to test). Your customer, however, uses ARM cores so I
> would expect you to have at least compile tested this on ARM. How come
> this wasn't verified by anybody at TI?
> 
> TI used to have automated testing for many of the important defconfigs,
> is that completely gone? Are you guys relying entirely on linux-next?

I just checked back to see what happened here. In our product kernel
(which does undergo build test with multiple defconfigs), we are using
v6 of these patches which did not have this issue.

I think 0-day kbuild tester could have caught the issue as well. Within
boundaries of existing infrastructure, that probably was the best bet
here. Not sure why that did not happen (probably just build scheduling).

Thanks,
Sekhar


Re: [PATCH v7 12/12] KVM/VMX/vPMU: support to report GLOBAL_STATUS_LBRS_FROZEN

2019-07-08 Thread Peter Zijlstra
On Mon, Jul 08, 2019 at 09:23:19AM +0800, Wei Wang wrote:
> This patch enables the LBR related features in Arch v4 in advance,
> though the current vPMU only has v2 support. Other arch v4 related
> support will be enabled later in another series.
> 
> Arch v4 supports streamlined Freeze_LBR_on_PMI. According to the SDM,
> the LBR_FRZ bit is set to global status when debugctl.freeze_lbr_on_pmi
> has been set and a PMI is generated. The CTR_FRZ bit is set when
> debugctl.freeze_perfmon_on_pmi is set and a PMI is generated.

(that's still a misnomer; it is: freeze_perfmon_on_overflow)

Why?

Who uses that v4 crud? It's broken. It looses events between overflow
and PMI.


Re: Re: Re: linux-next: build failure after merge of the rdma tree

2019-07-08 Thread Bernard Metzler
-"Jason Gunthorpe"  wrote: -

>To: "Bernard Metzler" 
>From: "Jason Gunthorpe" 
>Date: 07/08/2019 04:56PM
>Cc: "Stephen Rothwell" , "Doug Ledford"
>, "Linux Next Mailing List"
>, "Linux Kernel Mailing List"
>, "linux-r...@vger.kernel.org"
>
>Subject: [EXTERNAL] Re: Re: linux-next: build failure after merge of
>the rdma tree
>
>On Mon, Jul 08, 2019 at 02:28:13PM +, Bernard Metzler wrote:
>
>> Thanks for  bringing this up. Indeed, that explicit
>> initialization seem to be inappropriate. Can you please
>> fix that as you suggest?
>
>I'm applying this to fix the PER_CPU stuff in siw:
>
>From 4c7d6dcd364843e408a60952ba914bb72bafc6cc Mon Sep 17 00:00:00
>2001
>From: Jason Gunthorpe 
>Date: Mon, 8 Jul 2019 11:36:32 -0300
>Subject: [PATCH] RDMA/siw: Fix DEFINE_PER_CPU compilation when
> ARCH_NEEDS_WEAK_PER_CPU
>
>The initializer for the variable cannot be inside the macro (and zero
>initialization isn't needed anyhow).
>
>include/linux/percpu-defs.h:92:33: warning: '__pcpu_unique_use_cnt'
>initialized and declared 'extern'
>  extern __PCPU_DUMMY_ATTRS char __pcpu_unique_##name;  \
> ^~
>include/linux/percpu-defs.h:115:2: note: in expansion of macro
>'DEFINE_PER_CPU_SECTION'
>  DEFINE_PER_CPU_SECTION(type, name, "")
>  ^~
>drivers/infiniband/sw/siw/siw_main.c:129:8: note: in expansion of
>macro 'DEFINE_PER_CPU'
> static DEFINE_PER_CPU(atomic_t, use_cnt = ATOMIC_INIT(0));
>^~
>
>Also the rules for PER_CPU require the variable names to be globally
>unique, so prefix them with siw_
>
>Fixes: b9be6f18cf9e ("rdma/siw: transmit path")
>Fixes: bdcf26bf9b3a ("rdma/siw: network and RDMA core interface")
>Reported-by: Stephen Rothwell 
>Signed-off-by: Jason Gunthorpe 
>---
> drivers/infiniband/sw/siw/siw_main.c  |  8 
> drivers/infiniband/sw/siw/siw_qp_tx.c | 10 +-
> 2 files changed, 9 insertions(+), 9 deletions(-)
>
>diff --git a/drivers/infiniband/sw/siw/siw_main.c
>b/drivers/infiniband/sw/siw/siw_main.c
>index 3f5f3d27ebe5a1..fd2552a9091dee 100644
>--- a/drivers/infiniband/sw/siw/siw_main.c
>+++ b/drivers/infiniband/sw/siw/siw_main.c
>@@ -126,7 +126,7 @@ static int siw_dev_qualified(struct net_device
>*netdev)
>   return 0;
> }
> 
>-static DEFINE_PER_CPU(atomic_t, use_cnt = ATOMIC_INIT(0));
>+static DEFINE_PER_CPU(atomic_t, siw_use_cnt);
> 
> static struct {
>   struct cpumask **tx_valid_cpus;
>@@ -215,7 +215,7 @@ int siw_get_tx_cpu(struct siw_device *sdev)
>   if (!siw_tx_thread[cpu])
>   continue;
> 
>-  usage = atomic_read(_cpu(use_cnt, cpu));
>+  usage = atomic_read(_cpu(siw_use_cnt, cpu));
>   if (usage <= min_use) {
>   tx_cpu = cpu;
>   min_use = usage;
>@@ -226,7 +226,7 @@ int siw_get_tx_cpu(struct siw_device *sdev)
> 
> out:
>   if (tx_cpu >= 0)
>-  atomic_inc(_cpu(use_cnt, tx_cpu));
>+  atomic_inc(_cpu(siw_use_cnt, tx_cpu));
>   else
>   pr_warn("siw: no tx cpu found\n");
> 
>@@ -235,7 +235,7 @@ int siw_get_tx_cpu(struct siw_device *sdev)
> 
> void siw_put_tx_cpu(int cpu)
> {
>-  atomic_dec(_cpu(use_cnt, cpu));
>+  atomic_dec(_cpu(siw_use_cnt, cpu));
> }
> 
> static struct ib_qp *siw_get_base_qp(struct ib_device *base_dev, int
>id)
>diff --git a/drivers/infiniband/sw/siw/siw_qp_tx.c
>b/drivers/infiniband/sw/siw/siw_qp_tx.c
>index 5e926fac51db30..1c9fa8fa96e513 100644
>--- a/drivers/infiniband/sw/siw/siw_qp_tx.c
>+++ b/drivers/infiniband/sw/siw/siw_qp_tx.c
>@@ -1183,12 +1183,12 @@ struct tx_task_t {
>   wait_queue_head_t waiting;
> };
> 
>-static DEFINE_PER_CPU(struct tx_task_t, tx_task_g);
>+static DEFINE_PER_CPU(struct tx_task_t, siw_tx_task_g);
> 
> void siw_stop_tx_thread(int nr_cpu)
> {
>   kthread_stop(siw_tx_thread[nr_cpu]);
>-  wake_up(_cpu(tx_task_g, nr_cpu).waiting);
>+  wake_up(_cpu(siw_tx_task_g, nr_cpu).waiting);
> }
> 
> int siw_run_sq(void *data)
>@@ -1196,7 +1196,7 @@ int siw_run_sq(void *data)
>   const int nr_cpu = (unsigned int)(long)data;
>   struct llist_node *active;
>   struct siw_qp *qp;
>-  struct tx_task_t *tx_task = _cpu(tx_task_g, nr_cpu);
>+  struct tx_task_t *tx_task = _cpu(siw_tx_task_g, nr_cpu);
> 
>   init_llist_head(_task->active);
>   init_waitqueue_head(_task->waiting);
>@@ -1261,9 +1261,9 @@ int siw_sq_start(struct siw_qp *qp)
>   }
>   siw_qp_get(qp);
> 
>-  llist_add(>tx_list, _cpu(tx_task_g, qp->tx_cpu).active);
>+  llist_add(>tx_list, _cpu(siw_tx_task_g,
>qp->tx_cpu).active);
> 
>-  wake_up(_cpu(tx_task_g, qp->tx_cpu).waiting);
>+  wake_up(_cpu(siw_tx_task_g, qp->tx_cpu).waiting);
> 
>   return 0;
> }
>-- 
>2.21.0
>
>

Many thanks Jason!

Very much appreciated!

Bernard.



Re: [RFC PATCH 1/6] sched/dl: Improve deadline admission control for asymmetric CPU capacities

2019-07-08 Thread Quentin Perret
On Monday 08 Jul 2019 at 13:22:35 (+0200), Dietmar Eggemann wrote:
> On 5/7/19 4:43 PM, luca abeni wrote:
> > On Tue, 7 May 2019 15:31:27 +0100
> > Quentin Perret  wrote:
> > 
> >> On Tuesday 07 May 2019 at 16:25:23 (+0200), luca abeni wrote:
> >>> On Tue, 7 May 2019 14:48:52 +0100
> >>> Quentin Perret  wrote:
> >>>   
>  Hi Luca,
> 
>  On Monday 06 May 2019 at 06:48:31 (+0200), Luca Abeni wrote:  
> 
> [...]
> 
> >> Right and things moved recently in this area, see bb1fbdd3c3fd
> >> ("sched/topology, drivers/base/arch_topology: Rebuild the sched_domain
> >> hierarchy when capacities change")
> > 
> > Ah, thanks! I missed this change when rebasing the patchset.
> > I guess this part of the patch has to be updated (and probably became
> > useless?), then.
> 
> [...]
> 
> >>> This achieved the effect of correctly setting up the "rd_capacity"
> >>> field, but I do not know if there is a better/simpler way to achieve
> >>> the same result :)  
> >>
> >> OK, that's really an implementation detail, so no need to worry too
> >> much about it at the RFC stage I suppose :-)
> 
> What about we integrate the code to calculate the rd capacity into
> build_sched_domains() (next to the code to establish the rd
> max_cpu_capacity)?

Right, that's also what Vincent suggested IIRC. I think that'd work :)

Thanks,
Quentin


[GIT PULL] clone3 for v5.3

2019-07-08 Thread Christian Brauner
Hi Linus,

This is the PR for the clone3 system call.

The following changes since commit a188339ca5a396acc588e5851ed7e19f66b0ebd9:

  Linux 5.2-rc1 (2019-05-19 15:47:09 -0700)

are available in the Git repository at:

  g...@gitolite.kernel.org:pub/scm/linux/kernel/git/brauner/linux 
tags/clone3-v5.3

for you to fetch changes up to d68dbb0c9ac8b1ff52eb09aa58ce6358400fa939:

  arch: handle arches who do not yet define clone3 (2019-06-21 01:54:53 +0200)

/* Summary */
This adds the clone3 syscall which is an extensible successor to clone
after we snagged the last flag with CLONE_PIDFD during the 5.2 merge window
for clone(). It cleanly supports all of the flags from clone() and thus all
legacy workloads.

There are few user visible differences between clone3 and clone. First,
CLONE_DETACHED will cause EINVAL with clone3 so we can reuse this flag.
Second, the CSIGNAL flag is deprecated and will cause EINVAL to be
reported. It is superseeded by a dedicated "exit_signal" argument in struct
clone_args thus freeing up even more flags. And third, clone3 gives
CLONE_PIDFD a dedicated return argument in struct clone_args instead of
abusing CLONE_PARENT_SETTID's parent_tidptr argument.

The clone3 uapi is designed to be easy to handle on 32- and 64 bit:

/* uapi */
struct clone_args {
__aligned_u64 flags;
__aligned_u64 pidfd;
__aligned_u64 child_tid;
__aligned_u64 parent_tid;
__aligned_u64 exit_signal;
__aligned_u64 stack;
__aligned_u64 stack_size;
__aligned_u64 tls;
};

and a separate kernel struct is used that uses proper kernel typing:

/* kernel internal */
struct kernel_clone_args {
u64 flags;
int __user *pidfd;
int __user *child_tid;
int __user *parent_tid;
int exit_signal;
unsigned long stack;
unsigned long stack_size;
unsigned long tls;
};

The system call comes with a size argument which enables the kernel to
detect what version of clone_args userspace is passing in. clone3 validates
that any additional bytes a given kernel does not know about are set to
zero and that the size never exceeds a page.

A nice feature is that this patchset allowed us to cleanup and simplify
various core kernel codepaths in kernel/fork.c by making the internal
_do_fork() function take struct kernel_clone_args even for legacy clone().

This patch also unblocks the time namespace patchset which wants to
introduce a new CLONE_TIMENS flag.

Note, that clone3 has only been wired up for x86{_32,64}, arm{64}, and
xtensa. These were the architectures that did not require special
massaging. Other architectures treat fork-like system calls individually
and after some back and forth neither Arnd nor I felt confident that we
dared to add clone3 unconditionally to all architectures. We agreed to
leave this up to individual architecture maintainers. This is why there's
an additional patch that introduces __ARCH_WANT_SYS_CLONE3 which any
architecture can set once it has implemented support for clone3. The patch
also adds a cond_syscall(clone3) for architectures such as nios2 or h8300
that generate their syscall table by simply including asm-generic/unistd.h.
The hope is to get rid of __ARCH_WANT_SYS_CLONE3 and cond_syscall() rather
soon.

I sent this patchset separately from the pidfd patches for polling support
and pidfd_open() mostly because they were not necessarily related but also
so you can easily decide what you want to pull.

/* Testing */
The patch is based on v5.2-rc1 and have been sitting in linux-next since
then.

/* Conflicts with v5.2 */
A test-merge of my tree into pristine v5.2 revealed a conflict in
kernel/fork.c. It's not a very difficult conflict to resolve but it's also
not trivial. The fix that was carried in linux-next and that I carry
locally can be seen in [1]. I can also provide a fixed/rebased tree if
needed.

/* Conflicts with other trees */
I am not aware of any conflicts with other trees based on linux-next.

/* Syscall number 435 */
clone3() uses syscall number 435 and is coordinated with pidfd_open() which
uses syscall number 434. I'm not aware of any other syscall targeted for
5.3 that has chosen the same number.

/* New signing subkey */
So that there are no suprises, please note that I signed-off the tag with a
new signing key: 0x91C61BC06578DCA2
It's an ed25519 signing subkey that I moved to a Nitrokey and that's
available from the new, safer keys.openpgp.org keyserver.
Given the SKS churn I figured it might be a good idea to use a new,
dedicated kernel-only subkey instead of my general signing subkey.

Thanks!
Christian

[1]:

diff --cc kernel/fork.c
index fe83343da24b,98abea995629..
--- a/kernel/fork.c
+++ b/kernel/fork.c
@@@ -1753,7 -1768,7 +1748,8 @@@ static __latent_entropy struct task_str
int pidfd = -1, retval;
struct task_struct *p;
struct 

Re: [PATCH v2] PCI: hv: fix pci-hyperv build when SYSFS not enabled

2019-07-08 Thread Stephen Hemminger
On Sun, 7 Jul 2019 10:46:22 -0700
Randy Dunlap  wrote:

> On 7/3/19 11:06 AM, Haiyang Zhang wrote:
> > 
> >   
> >> -Original Message-
> >> From: Randy Dunlap 
> >> Sent: Wednesday, July 3, 2019 12:59 PM
> >> To: LKML ; linux-pci  >> p...@vger.kernel.org>  
> >> Cc: Matthew Wilcox ; Jake Oshins
> >> ; KY Srinivasan ; Haiyang
> >> Zhang ; Stephen Hemminger
> >> ; Sasha Levin ; Bjorn
> >> Helgaas ; linux-hyp...@vger.kernel.org; Dexuan
> >> Cui ; Yuehaibing 
> >> Subject: [PATCH v2] PCI: hv: fix pci-hyperv build when SYSFS not enabled
> >>
> >> From: Randy Dunlap 
> >>
> >> Fix build of drivers/pci/controller/pci-hyperv.o when
> >> CONFIG_SYSFS is not set/enabled by adding stubs for
> >> pci_create_slot() and pci_destroy_slot().
> >>
> >> Fixes these build errors:
> >>
> >> ERROR: "pci_destroy_slot" [drivers/pci/controller/pci-hyperv.ko] undefined!
> >> ERROR: "pci_create_slot" [drivers/pci/controller/pci-hyperv.ko] undefined!
> >>
> >> Fixes: a15f2c08c708 ("PCI: hv: support reporting serial number as slot
> >> information")
> >>
> >> Signed-off-by: Randy Dunlap 
> >> Cc: Matthew Wilcox 
> >> Cc: Jake Oshins 
> >> Cc: "K. Y. Srinivasan" 
> >> Cc: Haiyang Zhang 
> >> Cc: Stephen Hemminger 
> >> Cc: Sasha Levin 
> >> Cc: Bjorn Helgaas 
> >> Cc: linux-...@vger.kernel.org
> >> Cc: linux-hyp...@vger.kernel.org
> >> Cc: Dexuan Cui 
> >> Cc: Yuehaibing 
> >> ---
> >> v2:
> >> - provide non-CONFIG_SYSFS stubs for pci_create_slot() and
> >>   pci_destroy_slot() [suggested by Matthew Wilcox ]
> >> - use the correct Fixes: tag [Dexuan Cui ]
> >>
> >>  include/linux/pci.h |   12 ++--
> >>  1 file changed, 10 insertions(+), 2 deletions(-)
> >>
> >> --- lnx-52-rc7.orig/include/linux/pci.h
> >> +++ lnx-52-rc7/include/linux/pci.h
> >> @@ -25,6 +25,7 @@
> >>  #include 
> >>  #include 
> >>  #include 
> >> +#include 
> >>  #include 
> >>  #include 
> >>  #include 
> >> @@ -947,14 +948,21 @@ int pci_scan_root_bus_bridge(struct pci_
> >>  struct pci_bus *pci_add_new_bus(struct pci_bus *parent, struct pci_dev
> >> *dev,
> >>int busnr);
> >>  void pcie_update_link_speed(struct pci_bus *bus, u16 link_status);
> >> +#ifdef CONFIG_SYSFS
> >> +void pci_dev_assign_slot(struct pci_dev *dev);
> >>  struct pci_slot *pci_create_slot(struct pci_bus *parent, int slot_nr,
> >> const char *name,
> >> struct hotplug_slot *hotplug);
> >>  void pci_destroy_slot(struct pci_slot *slot);
> >> -#ifdef CONFIG_SYSFS
> >> -void pci_dev_assign_slot(struct pci_dev *dev);
> >>  #else
> >>  static inline void pci_dev_assign_slot(struct pci_dev *dev) { }
> >> +static inline struct pci_slot *pci_create_slot(struct pci_bus *parent,
> >> + int slot_nr,
> >> + const char *name,
> >> + struct hotplug_slot *hotplug) {
> >> +  return ERR_PTR(-EINVAL);
> >> +}
> >> +static inline void pci_destroy_slot(struct pci_slot *slot) { }
> >>  #endif
> >>  int pci_scan_slot(struct pci_bus *bus, int devfn);
> >>  struct pci_dev *pci_scan_single_device(struct pci_bus *bus, int devfn);
> >>  
> > 
> > The serial number in slot info is used to match VF NIC with Synthetic NIC.
> > Without selecting SYSFS, the SRIOV feature will fail on VM on Hyper-V and
> > Azure. The first version of this patch should be used.
> > 
> > @Stephen Hemminger how do you think?

Haiyang is right, accelerated networking won't work if slot is not recorded.

So the original patch (to depend on SYSFS) or using "select SYSFS" is
are necessary.

The whole thing is a bit of "angels dancing on the head of a pin" because
there is no good reason to build kernel without SYSFS in real world.
It would just be looking for trouble. As far as I can tell it is all
about getting "make randconfig" to work in more cases.

 


kasan: paging percpu + kasan causes a double fault

2019-07-08 Thread Dennis Zhou
Hi Andrey, Alexander, and Dmitry,

It was reported to me that when percpu is ran with param
percpu_alloc=page or the embed allocation scheme fails and falls back to
page that a double fault occurs.

I don't know much about how kasan works, but a difference between the
two is that we manually reserve vm area via vm_area_register_early().
I guessed it had something to do with the stack canary or the irq_stack,
and manually mapped the shadow vm area with kasan_add_zero_shadow(), but
that didn't seem to do the trick.

RIP resolves to the fixed_percpu_data declaration.

Double fault below:
[0.00] PANIC: double fault, error_code: 0x0
[0.00] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 
5.2.0-rc7-7-ge0afe6d4d12c-dirty #299
[0.00] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
1.11.0-2.el7 04/01/2014
[0.00] RIP: 0010:no_context+0x38/0x4b0
[0.00] Code: df 41 57 41 56 4c 8d bf 88 00 00 00 41 55 49 89 d5 41 54 
49 89 f4 55 48 89 fd 4c8
[0.00] RSP: :c828 EFLAGS: 00010096
[0.00] RAX: dc00 RBX: c850 RCX: 000b
[0.00] RDX: f5200030 RSI: 0003 RDI: c9000130
[0.00] RBP: c9a8 R08: 0001 R09: 
[0.00] R10:  R11:  R12: 0003
[0.00] R13: f5200030 R14:  R15: c9000130
[0.00] FS:  () GS:c900() 
knlGS:
[0.00] CS:  0010 DS:  ES:  CR0: 80050033
[0.00] CR2: c818 CR3: 02e0d001 CR4: 000606b0
[0.00] DR0:  DR1:  DR2: 
[0.00] DR3:  DR6: fffe0ff0 DR7: 0400
[0.00] Call Trace:
[0.00] Kernel panic - not syncing: Machine halted.
[0.00] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 
5.2.0-rc7-7-ge0afe6d4d12c-dirty #299
[0.00] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
1.11.0-2.el7 04/01/2014
[0.00] Call Trace:
[0.00]  <#DF>
[0.00]  dump_stack+0x5b/0x90
[0.00]  panic+0x17e/0x36e
[0.00]  ? __warn_printk+0xdb/0xdb
[0.00]  ? spurious_kernel_fault_check+0x1a/0x60
[0.00]  df_debug+0x2e/0x39
[0.00]  do_double_fault+0x89/0xb0
[0.00]  double_fault+0x1e/0x30
[0.00] RIP: 0010:no_context+0x38/0x4b0
[0.00] Code: df 41 57 41 56 4c 8d bf 88 00 00 00 41 55 49 89 d5 41 54 
49 89 f4 55 48 89 fd 4c8
[0.00] RSP: :c828 EFLAGS: 00010096
[0.00] RAX: dc00 RBX: c850 RCX: 000b
[0.00] RDX: f5200030 RSI: 0003 RDI: c9000130
[0.00] RBP: c9a8 R08: 0001 R09: 
[0.00] R10:  R11:  R12: 0003
[ 0.00] R13: f5200030 R14:  R15: c9000130

Thanks,
Dennis


Re: [PATCH] scsi: Remove unreachable code

2019-07-08 Thread Bart Van Assche

On 7/4/19 2:55 AM, Ding Xiang wrote:

The return code after switch default is unreachable,
so remove it.

Signed-off-by: Ding Xiang 
---
  drivers/scsi/scsi_error.c | 1 -
  1 file changed, 1 deletion(-)

diff --git a/drivers/scsi/scsi_error.c b/drivers/scsi/scsi_error.c
index bfa569f..12180f0 100644
--- a/drivers/scsi/scsi_error.c
+++ b/drivers/scsi/scsi_error.c
@@ -1909,7 +1909,6 @@ int scsi_decide_disposition(struct scsi_cmnd *scmd)
default:
return FAILED;
}
-   return FAILED;


I'd rather remove the "default: return FAILED;" code than make the above 
change. If status_byte() ever would be changed into an inline function 
that returns an enum then my alternative will allow the compiler to 
verify whether all enum labels have been handled. No such check will be 
performed if the above patch would be applied.


Bart.


Re: Investment offer to you,

2019-07-08 Thread Ayesha Al-Qaddafi
Greetings Dear Friend,

 It’s my pleasure to contact you through this media as i am in need of
your urgent assistance. My names are Mrs. Ayesha Al-Qaddafi a single
Mother and a Widow with three Children. I am the only biological
Daughter of late Libyan President (Late Colonel Muammar Al Qaddafi). I
have an investment funds worth Twenty Eight Million Four Hundred
Thousand United State Dollar($28.400.000.00) and i need an
investmentManager/Partner and because of the asylum status i will
authorize you the ownership of the funds, however, I am interested in
for the investment project assistance in your country, may be from
there, we can build a business relationship in the near future. I am
willing to negotiate investment/business profit sharing ratio with you
base on the future investment earning profits. If you arewilling to
handle this project kindly reply urgent to  enable me provide you more
information about the investment funds. Your Urgent Reply Will Be
Appreciated. Regards Ayesha Al-Qaddafi.


kprobes sanity test fails on next-20190708

2019-07-08 Thread Anders Roxell
Hi,

argh... resending, with plaintext... Sorry =/

I tried to build a next-201908 defconfig + CONFIG_KPROBES=y and
CONFIG_KPROBES_SANITY_TEST=y

I get the following Call trace, any ideas?
I've tried tags back to next-20190525 and they also failes... I haven't
found a commit that works yet.

[0.098694] Kprobe smoke test: started
[0.102001] audit: type=2000 audit(0.088:1): state=initialized
audit_enabled=0 res=1
[0.104753] Internal error: aarch64 BRK: f204 [#1] PREEMPT SMP
[0.106845] Modules linked in:
[0.107897] CPU: 0 PID: 1 Comm: swapper/0 Not tainted
5.2.0-next-20190708 #1
[0.110403] Hardware name: linux,dummy-virt (DT)
[0.112104] pstate: 6005 (nZCv daif -PAN -UAO)
[0.113852] pc : kprobe_target+0x0/0x18
[0.115268] lr : init_test_probes+0x1ac/0x3a0
[0.116890] sp : 1000bd40
[0.118122] x29: 1000bd40 x28:  
[0.120049] x27:  x26: 11190518 
[0.122029] x25: 1117e7d8 x24: 11261078 
[0.123977] x23:  x22: 1169bb70 
[0.125930] x21: 1186c000 x20: 116796c8 
[0.127886] x19: 1186cf10 x18: 0010 
[0.129836] x17:  x16: 80007b078000 
[0.131829] x15:  x14: 116796c8 
[0.133759] x13:  x12:  
[0.135736] x11:  x10: 0990 
[0.137693] x9 : 1000ba10 x8 : 80007b0789f0 
[0.139659] x7 : 80007dbe1dc0 x6 : 80007dbe1d40 
[0.141615] x5 : 0237 x4 : 21f2 
[0.143599] x3 : 1169bfb8 x2 :  
[0.145582] x1 : 10184e40 x0 : 40a0d76d 
[0.147556] Call trace:
[0.148459]  kprobe_target+0x0/0x18
[0.149754]  init_kprobes+0x120/0x134
[0.151103]  do_one_initcall+0x74/0x1b0
[0.152511]  kernel_init_freeable+0x194/0x22c
[0.154133]  kernel_init+0x10/0x100
[0.155411]  ret_from_fork+0x10/0x1c
[0.156717] Code: a8c97bfd d65f03c0 d421 97fd5cdd (d4200080) 
[0.158949] ---[ end trace 823556350f0e2d55 ]---
[0.160681] Kernel panic - not syncing: Attempted to kill init!
exitcode=0x000b
[0.163247] ---[ end Kernel panic - not syncing: Attempted to kill
init! exitcode=0x000b ]---


Cheers,
Anders


[PATCH net,v2] nfc: fix potential illegal memory access

2019-07-08 Thread Yang Wei
The frags_q is not properly initialized, it may result in illegal memory 
access when conn_info is NULL.
The "goto free_exit" should be replaced by "goto exit".

Signed-off-by: Yang Wei 
---
 net/nfc/nci/data.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/nfc/nci/data.c b/net/nfc/nci/data.c
index 0a0c265..ce3382b 100644
--- a/net/nfc/nci/data.c
+++ b/net/nfc/nci/data.c
@@ -107,7 +107,7 @@ static int nci_queue_tx_data_frags(struct nci_dev *ndev,
conn_info = nci_get_conn_info_by_conn_id(ndev, conn_id);
if (!conn_info) {
rc = -EPROTO;
-   goto free_exit;
+   goto exit;
}
 
__skb_queue_head_init(_q);
-- 
2.7.4




[PATCH v2] tpm: Remove a deprecated comments about implicit sysfs locking

2019-07-08 Thread Jarkko Sakkinen
Remove all comments about implicit locking tpm-sysfs.c as the file was
updated in Linux v5.1 to use explicit locking.

Signed-off-by: Jarkko Sakkinen 
---
v2: Forgot tpm-sysfs.c changes to my staging area :-/
 drivers/char/tpm/tpm-chip.c  | 7 ++-
 drivers/char/tpm/tpm-sysfs.c | 7 ---
 2 files changed, 2 insertions(+), 12 deletions(-)

diff --git a/drivers/char/tpm/tpm-chip.c b/drivers/char/tpm/tpm-chip.c
index bf868260f435..9311f88afbb4 100644
--- a/drivers/char/tpm/tpm-chip.c
+++ b/drivers/char/tpm/tpm-chip.c
@@ -287,12 +287,9 @@ static void tpm_devs_release(struct device *dev)
  * @dev: device to which the chip is associated.
  *
  * Issues a TPM2_Shutdown command prior to loss of power, as required by the
- * TPM 2.0 spec.
- * Then, calls bus- and device- specific shutdown code.
+ * TPM 2.0 spec. Then, calls bus- and device- specific shutdown code.
  *
- * XXX: This codepath relies on the fact that sysfs is not enabled for
- * TPM2: sysfs uses an implicit lock on chip->ops, so this could race if TPM2
- * has sysfs support enabled before TPM sysfs's implicit locking is fixed.
+ * Return: always 0 (i.e. success)
  */
 static int tpm_class_shutdown(struct device *dev)
 {
diff --git a/drivers/char/tpm/tpm-sysfs.c b/drivers/char/tpm/tpm-sysfs.c
index d9caedda075b..edfa89160010 100644
--- a/drivers/char/tpm/tpm-sysfs.c
+++ b/drivers/char/tpm/tpm-sysfs.c
@@ -329,16 +329,9 @@ static const struct attribute_group tpm_dev_group = {
 
 void tpm_sysfs_add_device(struct tpm_chip *chip)
 {
-   /* XXX: If you wish to remove this restriction, you must first update
-* tpm_sysfs to explicitly lock chip->ops.
-*/
if (chip->flags & TPM_CHIP_FLAG_TPM2)
return;
 
-   /* The sysfs routines rely on an implicit tpm_try_get_ops, device_del
-* is called before ops is null'd and the sysfs core synchronizes this
-* removal so that no callbacks are running or can run again
-*/
WARN_ON(chip->groups_cnt != 0);
chip->groups[chip->groups_cnt++] = _dev_group;
 }
-- 
2.20.1



Re: Re: linux-next: build failure after merge of the rdma tree

2019-07-08 Thread Jason Gunthorpe
On Mon, Jul 08, 2019 at 02:28:13PM +, Bernard Metzler wrote:

> Thanks for  bringing this up. Indeed, that explicit
> initialization seem to be inappropriate. Can you please
> fix that as you suggest?

I'm applying this to fix the PER_CPU stuff in siw:

>From 4c7d6dcd364843e408a60952ba914bb72bafc6cc Mon Sep 17 00:00:00 2001
From: Jason Gunthorpe 
Date: Mon, 8 Jul 2019 11:36:32 -0300
Subject: [PATCH] RDMA/siw: Fix DEFINE_PER_CPU compilation when
 ARCH_NEEDS_WEAK_PER_CPU

The initializer for the variable cannot be inside the macro (and zero
initialization isn't needed anyhow).

include/linux/percpu-defs.h:92:33: warning: '__pcpu_unique_use_cnt' initialized 
and declared 'extern'
  extern __PCPU_DUMMY_ATTRS char __pcpu_unique_##name;  \
 ^~
include/linux/percpu-defs.h:115:2: note: in expansion of macro 
'DEFINE_PER_CPU_SECTION'
  DEFINE_PER_CPU_SECTION(type, name, "")
  ^~
drivers/infiniband/sw/siw/siw_main.c:129:8: note: in expansion of macro 
'DEFINE_PER_CPU'
 static DEFINE_PER_CPU(atomic_t, use_cnt = ATOMIC_INIT(0));
^~

Also the rules for PER_CPU require the variable names to be globally
unique, so prefix them with siw_

Fixes: b9be6f18cf9e ("rdma/siw: transmit path")
Fixes: bdcf26bf9b3a ("rdma/siw: network and RDMA core interface")
Reported-by: Stephen Rothwell 
Signed-off-by: Jason Gunthorpe 
---
 drivers/infiniband/sw/siw/siw_main.c  |  8 
 drivers/infiniband/sw/siw/siw_qp_tx.c | 10 +-
 2 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/drivers/infiniband/sw/siw/siw_main.c 
b/drivers/infiniband/sw/siw/siw_main.c
index 3f5f3d27ebe5a1..fd2552a9091dee 100644
--- a/drivers/infiniband/sw/siw/siw_main.c
+++ b/drivers/infiniband/sw/siw/siw_main.c
@@ -126,7 +126,7 @@ static int siw_dev_qualified(struct net_device *netdev)
return 0;
 }
 
-static DEFINE_PER_CPU(atomic_t, use_cnt = ATOMIC_INIT(0));
+static DEFINE_PER_CPU(atomic_t, siw_use_cnt);
 
 static struct {
struct cpumask **tx_valid_cpus;
@@ -215,7 +215,7 @@ int siw_get_tx_cpu(struct siw_device *sdev)
if (!siw_tx_thread[cpu])
continue;
 
-   usage = atomic_read(_cpu(use_cnt, cpu));
+   usage = atomic_read(_cpu(siw_use_cnt, cpu));
if (usage <= min_use) {
tx_cpu = cpu;
min_use = usage;
@@ -226,7 +226,7 @@ int siw_get_tx_cpu(struct siw_device *sdev)
 
 out:
if (tx_cpu >= 0)
-   atomic_inc(_cpu(use_cnt, tx_cpu));
+   atomic_inc(_cpu(siw_use_cnt, tx_cpu));
else
pr_warn("siw: no tx cpu found\n");
 
@@ -235,7 +235,7 @@ int siw_get_tx_cpu(struct siw_device *sdev)
 
 void siw_put_tx_cpu(int cpu)
 {
-   atomic_dec(_cpu(use_cnt, cpu));
+   atomic_dec(_cpu(siw_use_cnt, cpu));
 }
 
 static struct ib_qp *siw_get_base_qp(struct ib_device *base_dev, int id)
diff --git a/drivers/infiniband/sw/siw/siw_qp_tx.c 
b/drivers/infiniband/sw/siw/siw_qp_tx.c
index 5e926fac51db30..1c9fa8fa96e513 100644
--- a/drivers/infiniband/sw/siw/siw_qp_tx.c
+++ b/drivers/infiniband/sw/siw/siw_qp_tx.c
@@ -1183,12 +1183,12 @@ struct tx_task_t {
wait_queue_head_t waiting;
 };
 
-static DEFINE_PER_CPU(struct tx_task_t, tx_task_g);
+static DEFINE_PER_CPU(struct tx_task_t, siw_tx_task_g);
 
 void siw_stop_tx_thread(int nr_cpu)
 {
kthread_stop(siw_tx_thread[nr_cpu]);
-   wake_up(_cpu(tx_task_g, nr_cpu).waiting);
+   wake_up(_cpu(siw_tx_task_g, nr_cpu).waiting);
 }
 
 int siw_run_sq(void *data)
@@ -1196,7 +1196,7 @@ int siw_run_sq(void *data)
const int nr_cpu = (unsigned int)(long)data;
struct llist_node *active;
struct siw_qp *qp;
-   struct tx_task_t *tx_task = _cpu(tx_task_g, nr_cpu);
+   struct tx_task_t *tx_task = _cpu(siw_tx_task_g, nr_cpu);
 
init_llist_head(_task->active);
init_waitqueue_head(_task->waiting);
@@ -1261,9 +1261,9 @@ int siw_sq_start(struct siw_qp *qp)
}
siw_qp_get(qp);
 
-   llist_add(>tx_list, _cpu(tx_task_g, qp->tx_cpu).active);
+   llist_add(>tx_list, _cpu(siw_tx_task_g, qp->tx_cpu).active);
 
-   wake_up(_cpu(tx_task_g, qp->tx_cpu).waiting);
+   wake_up(_cpu(siw_tx_task_g, qp->tx_cpu).waiting);
 
return 0;
 }
-- 
2.21.0



[PATCH] tpm: Remove a deprecated comments about implicit sysfs locking

2019-07-08 Thread Jarkko Sakkinen
Remove all comments about implicit locking tpm-sysfs.c as the file was
updated in Linux v5.1 to use explicit locking.

Signed-off-by: Jarkko Sakkinen 
---
 drivers/char/tpm/tpm-chip.c | 7 ++-
 1 file changed, 2 insertions(+), 5 deletions(-)

diff --git a/drivers/char/tpm/tpm-chip.c b/drivers/char/tpm/tpm-chip.c
index bf868260f435..9311f88afbb4 100644
--- a/drivers/char/tpm/tpm-chip.c
+++ b/drivers/char/tpm/tpm-chip.c
@@ -287,12 +287,9 @@ static void tpm_devs_release(struct device *dev)
  * @dev: device to which the chip is associated.
  *
  * Issues a TPM2_Shutdown command prior to loss of power, as required by the
- * TPM 2.0 spec.
- * Then, calls bus- and device- specific shutdown code.
+ * TPM 2.0 spec. Then, calls bus- and device- specific shutdown code.
  *
- * XXX: This codepath relies on the fact that sysfs is not enabled for
- * TPM2: sysfs uses an implicit lock on chip->ops, so this could race if TPM2
- * has sysfs support enabled before TPM sysfs's implicit locking is fixed.
+ * Return: always 0 (i.e. success)
  */
 static int tpm_class_shutdown(struct device *dev)
 {
-- 
2.20.1



<    5   6   7   8   9   10   11   12   13   14   >