Re: stress-ng --hrtimers hangs system
Hi Vladimir, On Tue Jun 09 2020, Vladimir Oltean wrote: > Just out of curiosity, what and how many CPU cores does your ARM64 box > have, and what frequency are you running them at? > Mine is a dual-core A72 machine running at 1500 MHz. That particular machine has a dual core Cortex A53 running at 1GHz. Thanks, Kurt signature.asc Description: PGP signature
KASAN: use-after-free Read in tipc_named_reinit
Hello, syzbot found the following crash on: HEAD commit:cb8e59cc Merge git://git.kernel.org/pub/scm/linux/kernel/g.. git tree: net-next console output: https://syzkaller.appspot.com/x/log.txt?x=12eccfd210 kernel config: https://syzkaller.appspot.com/x/.config?x=a16ddbc78955e3a9 dashboard link: https://syzkaller.appspot.com/bug?extid=e9cc557752ab126c1b99 compiler: gcc (GCC) 9.0.0 20181231 (experimental) Unfortunately, I don't have any reproducer for this crash yet. IMPORTANT: if you fix the bug, please add the following tag to the commit: Reported-by: syzbot+e9cc557752ab126c1...@syzkaller.appspotmail.com == BUG: KASAN: use-after-free in __read_once_size include/linux/compiler.h:252 [inline] BUG: KASAN: use-after-free in tipc_named_reinit+0x913/0x946 net/tipc/name_distr.c:344 Read of size 8 at addr 8880580d2000 by task kworker/1:1/27 CPU: 1 PID: 27 Comm: kworker/1:1 Not tainted 5.7.0-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Workqueue: events tipc_net_finalize_work Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x188/0x20d lib/dump_stack.c:118 print_address_description.constprop.0.cold+0xd3/0x413 mm/kasan/report.c:383 __kasan_report mm/kasan/report.c:513 [inline] kasan_report.cold+0x1f/0x37 mm/kasan/report.c:530 __read_once_size include/linux/compiler.h:252 [inline] tipc_named_reinit+0x913/0x946 net/tipc/name_distr.c:344 tipc_net_finalize net/tipc/net.c:138 [inline] tipc_net_finalize+0x1cf/0x310 net/tipc/net.c:131 tipc_net_finalize_work+0x55/0x80 net/tipc/net.c:150 process_one_work+0x965/0x16a0 kernel/workqueue.c:2268 worker_thread+0x96/0xe20 kernel/workqueue.c:2414 kthread+0x388/0x470 kernel/kthread.c:268 ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:351 Allocated by task 22186: save_stack+0x1b/0x40 mm/kasan/common.c:48 set_track mm/kasan/common.c:56 [inline] __kasan_kmalloc mm/kasan/common.c:494 [inline] __kasan_kmalloc.constprop.0+0xbf/0xd0 mm/kasan/common.c:467 kmem_cache_alloc_trace+0x153/0x7d0 mm/slab.c:3551 kmalloc include/linux/slab.h:555 [inline] kzalloc include/linux/slab.h:669 [inline] tipc_nametbl_init+0x1b5/0x490 net/tipc/name_table.c:852 tipc_init_net+0x381/0x5c0 net/tipc/core.c:79 ops_init+0xaf/0x420 net/core/net_namespace.c:151 setup_net+0x2de/0x860 net/core/net_namespace.c:341 copy_net_ns+0x293/0x590 net/core/net_namespace.c:482 create_new_namespaces+0x3fb/0xb30 kernel/nsproxy.c:110 unshare_nsproxy_namespaces+0xbd/0x1f0 kernel/nsproxy.c:231 ksys_unshare+0x43d/0x8e0 kernel/fork.c:2984 __do_sys_unshare kernel/fork.c:3052 [inline] __se_sys_unshare kernel/fork.c:3050 [inline] __x64_sys_unshare+0x2d/0x40 kernel/fork.c:3050 do_syscall_64+0xf6/0x7d0 arch/x86/entry/common.c:295 entry_SYSCALL_64_after_hwframe+0x49/0xb3 Freed by task 191: save_stack+0x1b/0x40 mm/kasan/common.c:48 set_track mm/kasan/common.c:56 [inline] kasan_set_free_info mm/kasan/common.c:316 [inline] __kasan_slab_free+0xf7/0x140 mm/kasan/common.c:455 __cache_free mm/slab.c:3426 [inline] kfree+0x109/0x2b0 mm/slab.c:3757 tipc_exit_net+0x2c/0x270 net/tipc/core.c:113 ops_exit_list.isra.0+0xa8/0x150 net/core/net_namespace.c:186 cleanup_net+0x511/0xa50 net/core/net_namespace.c:603 process_one_work+0x965/0x16a0 kernel/workqueue.c:2268 worker_thread+0x96/0xe20 kernel/workqueue.c:2414 kthread+0x388/0x470 kernel/kthread.c:268 ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:351 The buggy address belongs to the object at 8880580d which belongs to the cache kmalloc-16k of size 16384 The buggy address is located 8192 bytes inside of 16384-byte region [8880580d, 8880580d4000) The buggy address belongs to the page: page:ea0001603400 refcount:1 mapcount:0 mapping: index:0x0 head:ea0001603400 order:3 compound_mapcount:0 compound_pincount:0 flags: 0xfffe010200(slab|head) raw: 00fffe010200 ea0001509008 8880aa001c50 8880aa002380 raw: 8880580d 00010001 page dumped because: kasan: bad access detected Memory state around the buggy address: 8880580d1f00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb 8880580d1f80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb >8880580d2000: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ^ 8880580d2080: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb 8880580d2100: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb == --- This bug is generated by a bot. It may contain errors. See https://goo.gl/tpsmEJ for more information about syzbot. syzbot engineers can be reached at syzkal...@googlegroups.com. syzbot will keep track of this bug report. See: https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
Re: [PATCH v3] docs: deprecated.rst: Add zero-length and one-element arrays
On Mon, Jun 08, 2020 at 04:37:11PM -0500, Gustavo A. R. Silva wrote: > Add zero-length and one-element arrays to the list. > > While I continue replacing zero-length and one-element arrays with > flexible-array members, I need a reference to point people to, so > they don't introduce more instances of such arrays. And while here, > add a note to the "open-coded arithmetic in allocator arguments" > section, on the use of struct_size() and the arrays-to-deprecate > mentioned here. > > Co-developed-by: Kees Cook > Signed-off-by: Kees Cook > Signed-off-by: Gustavo A. R. Silva We hammered this out offlist, hence my SoB, but just in case it's useful: Acked-by: Kees Cook -- Kees Cook
Re: [PATCH] mm/page_alloc: silence a KASAN false positive
On Wed, Jun 10, 2020 at 7:22 AM Qian Cai wrote:
>
> kernel_init_free_pages() will use memset() on s390 to clear all pages
> from kmalloc_order() which will override KASAN redzones because a
> redzone was setup from the end of the allocation size to the end of the
> last page. Silence it by not reporting it there. An example of the
> report is,
Interesting. The reason why we did not hit it on x86_64 is because
clear_page is implemented in asm (arch/x86/lib/clear_page_64.S) and
thus is not instrumented. Arm64 probably does the same. However, on
s390 clear_page is defined to memset.
clear_[high]page are pretty extensively used in the kernel.
We can either do this, or make clear_page non instrumented on s390 as
well to match the existing implicit assumption. The benefit of the
current approach is that we can find some real use-after-free's and
maybe out-of-bounds on clear_page. The downside is that we may need
more of these annotations. Thoughts?
> BUG: KASAN: slab-out-of-bounds in __free_pages_ok
> Write of size 4096 at addr 00014beaa000
> Call Trace:
> show_stack+0x152/0x210
> dump_stack+0x1f8/0x248
> print_address_description.isra.13+0x5e/0x4d0
> kasan_report+0x130/0x178
> check_memory_region+0x190/0x218
> memset+0x34/0x60
> __free_pages_ok+0x894/0x12f0
> kfree+0x4f2/0x5e0
> unpack_to_rootfs+0x60e/0x650
> populate_rootfs+0x56/0x358
> do_one_initcall+0x1f4/0xa20
> kernel_init_freeable+0x758/0x7e8
> kernel_init+0x1c/0x170
> ret_from_fork+0x24/0x28
> Memory state around the buggy address:
> 00014bea9f00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 00014bea9f80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> >00014beaa000: 03 fe fe fe fe fe fe fe fe fe fe fe fe fe fe fe
> ^
> 00014beaa080: fe fe fe fe fe fe fe fe fe fe fe fe fe fe fe fe
> 00014beaa100: fe fe fe fe fe fe fe fe fe fe fe fe fe fe
>
> Fixes: 6471384af2a6 ("mm: security: introduce init_on_alloc=1 and
> init_on_free=1 boot options")
> Signed-off-by: Qian Cai
> ---
> mm/page_alloc.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> index 727751219003..9954973f89a3 100644
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -1164,8 +1164,11 @@ static void kernel_init_free_pages(struct page *page,
> int numpages)
> {
> int i;
>
> + /* s390's use of memset() could override KASAN redzones. */
> + kasan_disable_current();
> for (i = 0; i < numpages; i++)
> clear_highpage(page + i);
> + kasan_enable_current();
> }
>
> static __always_inline bool free_pages_prepare(struct page *page,
> --
> 2.21.0 (Apple Git-122.2)
>
Re: [PATCH v3 4/7] selftests/ftrace: Convert required interface checks into requires list
Hi Shuah,
On Tue, 9 Jun 2020 14:41:27 -0600
Shuah Khan wrote:
> On 6/2/20 8:40 PM, Masami Hiramatsu wrote:
> > Convert the required tracefs interface checking code with
> > requires: list.
> >
> > Signed-off-by: Masami Hiramatsu
> > Reviewed-by: Tom Zanussi
> > ---
> >Changes in v2: Fix trigger-onchange-action-hist.tc requires list.
>
> Masami,
>
> This patch doesn't apply to linux-kselftest next
>
> Patches 1-3 applied fine and this one failed. For now I will
> hold off on applying this series.
Yes, there is another patch posted by Tom with his ftrace enhancement
in tracing-next. Thus I commented on 0/7 as below.
Since this series depends on following 2 commits,
commit 619ee76f5c9f ("selftests/ftrace: Return unsupported if no
error_log file") on Shuah's Kselftest tree
commit bea24f766efc ("selftests/ftrace: Distinguish between hist
and synthetic event checks") on Steven's Tracing tree
This can be applied on the tree which merged both of them.
I'm not sure how do I handle it. It is OK just modifying this
for linux-kselftest, but in that case we will need another
patch after merged both.
IMHO, since the kselftest must run correctly on older kernel,
(and ftracetest does) Tom's kselftest patch should be merged
into linux-kselftest instead of tracing tree.
Steve, what would you think?
Thank you,
--
Masami Hiramatsu
[PATCH] symlink.7: document magic-links more completely
Hi Michael, Sorry for the delay and here is the patch I promised in this thread. --8<-8<-- Traditionally, magic-links have not been a well-understood topic in Linux. This helps clarify some of the terminology used in openat2.2. Signed-off-by: Aleksa Sarai --- man7/symlink.7 | 31 ++- 1 file changed, 22 insertions(+), 9 deletions(-) diff --git a/man7/symlink.7 b/man7/symlink.7 index 07b1db3a3764..ed99bc4236f1 100644 --- a/man7/symlink.7 +++ b/man7/symlink.7 @@ -84,6 +84,21 @@ as they are implemented on Linux and other systems, are outlined here. It is important that site-local applications also conform to these rules, so that the user interface can be as consistent as possible. +.SS Magic-links +There is a special class of symlink-like objects known as "magic-links" which +can be found in certain pseudo-filesystems such as +.BR proc (5) +(examples include +.IR /proc/[pid]/exe " and " /proc/[pid]/fd/* .) +Unlike normal symlinks, magic-links are not resolved through +pathname-expansion, but instead act as direct references to the kernel's own +representation of a file handle. As such, these magic-links allow users to +access files which cannot be referenced with normal paths (such as unlinked +files still referenced by a running program.) +.PP +Because they can bypass ordinary +.BR mount_namespaces (7)-based +restrictions, magic-links have been used as attack vectors in various exploits. .SS Symbolic link ownership, permissions, and timestamps The owner and group of an existing symbolic link can be changed using @@ -99,16 +114,14 @@ of a symbolic link can be changed using or .BR lutimes (3). .PP -On Linux, the permissions of a symbolic link are not used -in any operations; the permissions are always -0777 (read, write, and execute for all user categories), .\" Linux does not currently implement an lchmod(2). -and can't be changed. -(Note that there are some "magic" symbolic links in the -.I /proc -directory tree\(emfor example, the -.IR /proc/[pid]/fd/* -files\(emthat have different permissions.) +On Linux, the permissions of an ordinary symbolic link are not used in any +operations; the permissions are always 0777 (read, write, and execute for all +user categories), and can't be changed. +.PP +However, magic-links do not follow this rule. They can have a non-0777 mode, +though this mode is not currently used in any permission checks. + .\" .\" The .\" 4.4BSD -- 2.26.2
Re: [PATCH] Fix null pointer dereference in vector_user_bpf
On Tue, Jun 09, 2020 at 11:43:00PM -0400, Gaurav Singh wrote: > Signed-off-by: Gaurav Singh > > The bpf_prog is being checked for !NULL after uml_kmalloc but > later its used directly for example: > bpf_prog->filter = bpf and is also later returned upon success. > Fix this, do a NULL check and return right away. > > --- > arch/um/drivers/vector_user.c | 8 +--- > 1 file changed, 5 insertions(+), 3 deletions(-) No signed-off-by?
[PATCH RESEND V2] vdpa: introduce virtio pci driver
This patch introduce a vDPA driver for virtio-pci device. It bridges
the virtio-pci control command to the vDPA bus. This will be used for
developing new features for both software vDPA framework and hardware
vDPA feature.
Compared to vdpa_sim, it has several advantages:
- it's a real device driver which allow us to play with real hardware
features
- type independent instead of networking specific
Note that since virtio specification does not support get/restore
virtqueue state. So we can not use this driver for VM. This can be
addressed by extending the virtio specification.
Consider the driver is mainly for testing and development for vDPA
features, it can only be bound via dynamic ids to make sure it's not
conflict with the drivers like virtio-pci or IFCVF.
Signed-off-by: Jason Wang
---
Changes since V1:
- use NULL id_table to allow dynamic ids only
- squash the doorbell reporting
---
drivers/vdpa/Kconfig | 8 +
drivers/vdpa/Makefile | 1 +
drivers/vdpa/vp_vdpa/Makefile | 2 +
drivers/vdpa/vp_vdpa/vp_vdpa.c | 601 +
4 files changed, 612 insertions(+)
create mode 100644 drivers/vdpa/vp_vdpa/Makefile
create mode 100644 drivers/vdpa/vp_vdpa/vp_vdpa.c
diff --git a/drivers/vdpa/Kconfig b/drivers/vdpa/Kconfig
index e8140065c8a5..5cef3a4872e3 100644
--- a/drivers/vdpa/Kconfig
+++ b/drivers/vdpa/Kconfig
@@ -28,4 +28,12 @@ config IFCVF
To compile this driver as a module, choose M here: the module will
be called ifcvf.
+config VP_VDPA
+ tristate "Virtio PCI bridge vDPA driver"
+ depends on PCI_MSI
+ help
+ This kernel module that bridges virtio PCI device to vDPA
+ bus. It allows us to test and develop vDPA subsystem inside
+ an VM with the emulated virtio-pci device
+
endif # VDPA
diff --git a/drivers/vdpa/Makefile b/drivers/vdpa/Makefile
index 8bbb686ca7a2..37d00f49b3bf 100644
--- a/drivers/vdpa/Makefile
+++ b/drivers/vdpa/Makefile
@@ -2,3 +2,4 @@
obj-$(CONFIG_VDPA) += vdpa.o
obj-$(CONFIG_VDPA_SIM) += vdpa_sim/
obj-$(CONFIG_IFCVF)+= ifcvf/
+obj-$(CONFIG_VP_VDPA)+= vp_vdpa/
diff --git a/drivers/vdpa/vp_vdpa/Makefile b/drivers/vdpa/vp_vdpa/Makefile
new file mode 100644
index ..231088d3af7d
--- /dev/null
+++ b/drivers/vdpa/vp_vdpa/Makefile
@@ -0,0 +1,2 @@
+# SPDX-License-Identifier: GPL-2.0
+obj-$(CONFIG_VP_VDPA) += vp_vdpa.o
diff --git a/drivers/vdpa/vp_vdpa/vp_vdpa.c b/drivers/vdpa/vp_vdpa/vp_vdpa.c
new file mode 100644
index ..2070298ab9fc
--- /dev/null
+++ b/drivers/vdpa/vp_vdpa/vp_vdpa.c
@@ -0,0 +1,601 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * vDPA bridge driver for modern virtio-pci device
+ *
+ * Copyright (c) 2020, Red Hat Inc. All rights reserved.
+ * Author: Jason Wang
+ *
+ * Based on virtio_pci_modern.c.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+/* TBD: read from config space */
+#define VP_VDPA_MAX_QUEUE 2
+#define VP_VDPA_DRIVER_NAME "vp_vdpa"
+
+#define VP_VDPA_FEATURES \
+ ((1ULL << VIRTIO_F_ANY_LAYOUT) | \
+(1ULL << VIRTIO_F_VERSION_1) | \
+(1ULL << VIRTIO_F_ORDER_PLATFORM) | \
+(1ULL << VIRTIO_F_IOMMU_PLATFORM))
+
+struct vp_vring {
+ void __iomem *notify;
+ char msix_name[256];
+ resource_size_t notify_pa;
+ struct vdpa_callback cb;
+ int irq;
+};
+
+struct vp_vdpa {
+ struct vdpa_device vdpa;
+ struct pci_dev *pdev;
+
+ struct virtio_device_id id;
+
+ struct vp_vring vring[VP_VDPA_MAX_QUEUE];
+
+ /* The IO mapping for the PCI config space */
+ void __iomem * const *base;
+ struct virtio_pci_common_cfg __iomem *common;
+ void __iomem *device;
+ /* Base of vq notifications */
+ void __iomem *notify;
+
+ /* Multiplier for queue_notify_off. */
+ u32 notify_off_multiplier;
+
+ int modern_bars;
+ int vectors;
+};
+
+static struct vp_vdpa *vdpa_to_vp(struct vdpa_device *vdpa)
+{
+ return container_of(vdpa, struct vp_vdpa, vdpa);
+}
+
+/*
+ * Type-safe wrappers for io accesses.
+ * Use these to enforce at compile time the following spec requirement:
+ *
+ * The driver MUST access each field using the “natural” access
+ * method, i.e. 32-bit accesses for 32-bit fields, 16-bit accesses
+ * for 16-bit fields and 8-bit accesses for 8-bit fields.
+ */
+static inline u8 vp_ioread8(u8 __iomem *addr)
+{
+ return ioread8(addr);
+}
+static inline u16 vp_ioread16(__le16 __iomem *addr)
+{
+ return ioread16(addr);
+}
+
+static inline u32 vp_ioread32(__le32 __iomem *addr)
+{
+ return ioread32(addr);
+}
+
+static inline void vp_iowrite8(u8 value, u8 __iomem *addr)
+{
+ iowrite8(value, addr);
+}
+
+static inline void vp_iowrite16(u16 value, __le16 __iomem *addr)
+{
+ iowrite16(value, addr);
+}
+
+static inline void vp_iowrite32(u32 value, __le32 __iomem *addr)
Re: [PATCH v4 09/17] media: mtk-vcodec: Get rid of mtk_smi_larb_get/put
+ Tiffany & Maoguang.
On Sat, 2020-05-30 at 16:10 +0800, Yong Wu wrote:
> MediaTek IOMMU has already added the device_link between the consumer
> and smi-larb device. If the vcodec device call the pm_runtime_get_sync,
> the smi-larb's pm_runtime_get_sync also be called automatically.
>
> CC: Tiffany Lin
> Signed-off-by: Yong Wu
> Reviewed-by: Evan Green
> ---
> .../media/platform/mtk-vcodec/mtk_vcodec_dec_pm.c | 19 ---
> drivers/media/platform/mtk-vcodec/mtk_vcodec_drv.h | 3 ---
> drivers/media/platform/mtk-vcodec/mtk_vcodec_enc.c | 1 -
> .../media/platform/mtk-vcodec/mtk_vcodec_enc_pm.c | 27
> --
> 4 files changed, 50 deletions(-)
>
> diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_pm.c
> b/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_pm.c
> index 36dfe3f..1d7d14d 100644
> --- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_pm.c
> +++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_pm.c
> @@ -8,14 +8,12 @@
> #include
> #include
> #include
> -#include
>
> #include "mtk_vcodec_dec_pm.h"
> #include "mtk_vcodec_util.h"
>
> int mtk_vcodec_init_dec_pm(struct mtk_vcodec_dev *mtkdev)
> {
> - struct device_node *node;
> struct platform_device *pdev;
> struct mtk_vcodec_pm *pm;
> struct mtk_vcodec_clk *dec_clk;
> @@ -26,18 +24,7 @@ int mtk_vcodec_init_dec_pm(struct mtk_vcodec_dev *mtkdev)
> pm = >pm;
> pm->mtkdev = mtkdev;
> dec_clk = >vdec_clk;
> - node = of_parse_phandle(pdev->dev.of_node, "mediatek,larb", 0);
> - if (!node) {
> - mtk_v4l2_err("of_parse_phandle mediatek,larb fail!");
> - return -1;
> - }
>
> - pdev = of_find_device_by_node(node);
> - of_node_put(node);
> - if (WARN_ON(!pdev)) {
> - return -1;
> - }
> - pm->larbvdec = >dev;
> pdev = mtkdev->plat_dev;
> pm->dev = >dev;
>
> @@ -113,11 +100,6 @@ void mtk_vcodec_dec_clock_on(struct mtk_vcodec_pm *pm)
> }
> }
>
> - ret = mtk_smi_larb_get(pm->larbvdec);
> - if (ret) {
> - mtk_v4l2_err("mtk_smi_larb_get larbvdec fail %d", ret);
> - goto error;
> - }
> return;
>
> error:
> @@ -130,7 +112,6 @@ void mtk_vcodec_dec_clock_off(struct mtk_vcodec_pm *pm)
> struct mtk_vcodec_clk *dec_clk = >vdec_clk;
> int i = 0;
>
> - mtk_smi_larb_put(pm->larbvdec);
> for (i = dec_clk->clk_num - 1; i >= 0; i--)
> clk_disable_unprepare(dec_clk->clk_info[i].vcodec_clk);
> }
> diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_drv.h
> b/drivers/media/platform/mtk-vcodec/mtk_vcodec_drv.h
> index 52d1ce1..7d3966a 100644
> --- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_drv.h
> +++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_drv.h
> @@ -190,10 +190,7 @@ struct mtk_vcodec_clk {
> */
> struct mtk_vcodec_pm {
> struct mtk_vcodec_clk vdec_clk;
> - struct device *larbvdec;
> -
> struct mtk_vcodec_clk venc_clk;
> - struct device *larbvenc;
> struct device *dev;
> struct mtk_vcodec_dev *mtkdev;
> };
> diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_enc.c
> b/drivers/media/platform/mtk-vcodec/mtk_vcodec_enc.c
> index 5301dca..18025f7 100644
> --- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_enc.c
> +++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_enc.c
> @@ -8,7 +8,6 @@
> #include
> #include
> #include
> -#include
> #include
>
> #include "mtk_vcodec_drv.h"
> diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_enc_pm.c
> b/drivers/media/platform/mtk-vcodec/mtk_vcodec_enc_pm.c
> index 01c6a55..047919e 100644
> --- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_enc_pm.c
> +++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_enc_pm.c
> @@ -8,44 +8,25 @@
> #include
> #include
> #include
> -#include
>
> #include "mtk_vcodec_enc_pm.h"
> #include "mtk_vcodec_util.h"
>
> int mtk_vcodec_init_enc_pm(struct mtk_vcodec_dev *mtkdev)
> {
> - struct device_node *node;
> struct platform_device *pdev;
> struct mtk_vcodec_pm *pm;
> struct mtk_vcodec_clk *enc_clk;
> struct mtk_vcodec_clk_info *clk_info;
> int ret = 0, i = 0;
> - struct device *dev;
>
> pdev = mtkdev->plat_dev;
> pm = >pm;
> memset(pm, 0, sizeof(struct mtk_vcodec_pm));
> pm->mtkdev = mtkdev;
> pm->dev = >dev;
> - dev = >dev;
> enc_clk = >venc_clk;
>
> - node = of_parse_phandle(dev->of_node, "mediatek,larb", 0);
> - if (!node) {
> - mtk_v4l2_err("no mediatek,larb found");
> - return -ENODEV;
> - }
> - pdev = of_find_device_by_node(node);
> - of_node_put(node);
> - if (!pdev) {
> - mtk_v4l2_err("no mediatek,larb device found");
> - return -ENODEV;
> - }
> - pm->larbvenc = >dev;
> - pdev = mtkdev->plat_dev;
> - pm->dev = >dev;
> -
> enc_clk->clk_num =
Re: [PATCH v4 08/17] media: mtk-vcodec: separate mtk-vcodec-enc node.
+ Tiffany & Maoguang.
On Sat, 2020-05-30 at 16:10 +0800, Yong Wu wrote:
> From: Maoguang Meng
>
> MTK H264 Encoder(VENC_SYS) and VP8 Encoder(VENC_LT_SYS) are two
> independent hardware instance. They have their owner interrupt,
> register mapping, and special clocks.
>
> This patch seperates the two instance. This is a preparing patch for
> adding device_link between the larbs and venc-device. It's mainly for
> fixing the problem:
> https://lkml.org/lkml/2019/9/3/316
>
> User Call "VIDIOC_QUERYCAP":
> H264 Encoder return driver name "mtk-vcodec-enc";
> VP8 Encoder return driver name "mtk-venc-vp8.
>
> Signed-off-by: Maoguang Meng
> Signed-off-by: Hsin-Yi Wang
> Signed-off-by: Irui Wang
> ---
> drivers/media/platform/mtk-vcodec/mtk_vcodec_drv.h | 10 +-
> drivers/media/platform/mtk-vcodec/mtk_vcodec_enc.c | 23 +++-
> .../media/platform/mtk-vcodec/mtk_vcodec_enc_drv.c | 127
> +
> .../media/platform/mtk-vcodec/mtk_vcodec_enc_pm.c | 31 +
> .../media/platform/mtk-vcodec/mtk_vcodec_enc_pm.h | 1 -
> .../media/platform/mtk-vcodec/venc/venc_vp8_if.c | 4 +-
> 6 files changed, 80 insertions(+), 116 deletions(-)
>
> diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_drv.h
> b/drivers/media/platform/mtk-vcodec/mtk_vcodec_drv.h
> index a2716117..52d1ce1 100644
> --- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_drv.h
> +++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_drv.h
> @@ -19,6 +19,7 @@
> #define MTK_VCODEC_DRV_NAME "mtk_vcodec_drv"
> #define MTK_VCODEC_DEC_NAME "mtk-vcodec-dec"
> #define MTK_VCODEC_ENC_NAME "mtk-vcodec-enc"
> +#define MTK_VENC_VP8_NAME"mtk-venc-vp8"
> #define MTK_PLATFORM_STR "platform:mt8173"
>
> #define MTK_VCODEC_MAX_PLANES3
> @@ -193,7 +194,6 @@ struct mtk_vcodec_pm {
>
> struct mtk_vcodec_clk venc_clk;
> struct device *larbvenc;
> - struct device *larbvenclt;
> struct device *dev;
> struct mtk_vcodec_dev *mtkdev;
> };
> @@ -311,25 +311,27 @@ enum mtk_chip {
> * @chip: chip this encoder is compatible with
> *
> * @uses_ext: whether the encoder uses the extended firmware messaging format
> - * @has_lt_irq: whether the encoder uses the LT irq
> + * @name: whether the encoder core is vp8
> * @min_birate: minimum supported encoding bitrate
> * @max_bitrate: maximum supported encoding bitrate
> * @capture_formats: array of supported capture formats
> * @num_capture_formats: number of entries in capture_formats
> * @output_formats: array of supported output formats
> * @num_output_formats: number of entries in output_formats
> + * @core_id: stand for h264 or vp8 encode index
> */
> struct mtk_vcodec_enc_pdata {
> enum mtk_chip chip;
>
> bool uses_ext;
> - bool has_lt_irq;
> + const char *name;
> unsigned long min_bitrate;
> unsigned long max_bitrate;
> const struct mtk_video_fmt *capture_formats;
> size_t num_capture_formats;
> const struct mtk_video_fmt *output_formats;
> size_t num_output_formats;
> + int core_id;
> };
>
> /**
> @@ -359,7 +361,6 @@ struct mtk_vcodec_enc_pdata {
> *
> * @dec_irq: decoder irq resource
> * @enc_irq: h264 encoder irq resource
> - * @enc_lt_irq: vp8 encoder irq resource
> *
> * @dec_mutex: decoder hardware lock
> * @enc_mutex: encoder hardware lock.
> @@ -395,7 +396,6 @@ struct mtk_vcodec_dev {
>
> int dec_irq;
> int enc_irq;
> - int enc_lt_irq;
>
> struct mutex dec_mutex;
> struct mutex enc_mutex;
> diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_enc.c
> b/drivers/media/platform/mtk-vcodec/mtk_vcodec_enc.c
> index f0af78f..5301dca 100644
> --- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_enc.c
> +++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_enc.c
> @@ -9,6 +9,7 @@
> #include
> #include
> #include
> +#include
>
> #include "mtk_vcodec_drv.h"
> #include "mtk_vcodec_enc.h"
> @@ -174,7 +175,10 @@ static int vidioc_enum_fmt_vid_out(struct file *file,
> void *priv,
> static int vidioc_venc_querycap(struct file *file, void *priv,
> struct v4l2_capability *cap)
> {
> - strscpy(cap->driver, MTK_VCODEC_ENC_NAME, sizeof(cap->driver));
> + const struct mtk_vcodec_enc_pdata *pdata =
> + fh_to_ctx(priv)->dev->venc_pdata;
> +
> + strscpy(cap->driver, pdata->name, sizeof(cap->driver));
> strscpy(cap->bus_info, MTK_PLATFORM_STR, sizeof(cap->bus_info));
> strscpy(cap->card, MTK_PLATFORM_STR, sizeof(cap->card));
>
> @@ -788,7 +792,7 @@ static int vb2ops_venc_start_streaming(struct vb2_queue
> *q, unsigned int count)
> */
> if ((ctx->state == MTK_STATE_ABORT) || (ctx->state == MTK_STATE_FREE)) {
> ret = -EIO;
> - goto err_set_param;
> + goto err_start_stream;
> }
>
> /* Do the initialization when both start_streaming have been called */
> @@ -800,6 +804,12 @@ static
Re: [PATCH V2] vdpa: introduce virtio pci driver
On 2020/6/10 下午12:47, Michael S. Tsirkin wrote: On Wed, Jun 10, 2020 at 11:59:20AM +0800, Jason Wang wrote: This patch introduce a vDPA driver for virtio-pci device. It bridges the virtio-pci control command to the vDPA bus. This will be used for developing new features for both software vDPA framework and hardware vDPA feature. The mail headers are mailformed here: Content-Type: text/plain; charset=a so git am can't parse it: error: cannot convert from a to UTF-8 fatal: could not parse patch My bad, let me repost. Thanks
Re: ipr crashes due to NULL dma_need_drain since cc97923a5bcc ("block: move dma drain handling to scsi")
Christoph Hellwig writes:
> Can you try this patch?
>
> ---
> From 1c9913360a0494375c5655b133899cb4323bceb4 Mon Sep 17 00:00:00 2001
> From: Christoph Hellwig
> Date: Tue, 9 Jun 2020 14:07:31 +0200
> Subject: scsi: wire up ata_scsi_dma_need_drain for SAS HBA drivers
>
> We need ata_scsi_dma_need_drain for all drivers wired up to drive ATAPI
> devices through libata. That also includes the SAS HBA drivers in
> addition to native libata HBA drivers.
>
> Fixes: cc97923a5bcc ("block: move dma drain handling to scsi")
> Reported-by: Michael Ellerman
> Signed-off-by: Christoph Hellwig
Yep that works for me here with ipr.
Tested-by: Michael Ellerman
cheers
Re: [PATCH v7 2/4] lib/test_bitmap.c: Add for_each_set_clump test cases
On 6/7/20 7:15 AM, Syed Nayyar Waris wrote:
On Fri, Jun 5, 2020 at 5:54 PM Andy Shevchenko
wrote:
On Fri, Jun 05, 2020 at 02:12:54AM +0530, Syed Nayyar Waris wrote:
On Sun, May 31, 2020 at 12:50 AM kbuild test robot wrote:
WARNING: modpost: lib/test_bitmap.o(.data+0xe80): Section mismatch in reference
from the variable clump_test_data to the variable .init.rodata:clump_exp1
The variable clump_test_data references
the variable __initconst clump_exp1
If the reference is valid then annotate the
variable with or __refdata (see linux/init.h) or name the variable:
--
WARNING: modpost: lib/test_bitmap.o(.data+0xec8): Section mismatch in reference
from the variable clump_test_data to the variable .init.rodata:clump_exp2
The variable clump_test_data references
the variable __initconst clump_exp2
If the reference is valid then annotate the
variable with or __refdata (see linux/init.h) or name the variable:
--
WARNING: modpost: lib/test_bitmap.o(.data+0xf10): Section mismatch in reference
from the variable clump_test_data to the variable .init.rodata:clump_exp3
The variable clump_test_data references
the variable __initconst clump_exp3
If the reference is valid then annotate the
variable with or __refdata (see linux/init.h) or name the variable:
--
WARNING: modpost: lib/test_bitmap.o(.data+0xf58): Section mismatch in reference
from the variable clump_test_data to the variable .init.rodata:clump_exp4
The variable clump_test_data references
the variable __initconst clump_exp4
If the reference is valid then annotate the
variable with or __refdata (see linux/init.h) or name the variable:
I am unable to reproduce the compilation warning.
You have to enable section mismatch checker.
I ran the command:
make W=1 C=1 ARCH=x86_64 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' lib/
But the compilation warning didn't show up. Can anyone please point to me
what I am doing wrong here? How shall I reproduce the warning? Thanks !
You put some data into init section of the object, while you are trying to
access it from non-init one. It's easy-to-fix issue.
--
With Best Regards,
Andy Shevchenko
Thanks! I have made code changes for the above warning. Actually I am
still unable to reproduce the compilation warning. But I believe the
following code fix will fix the compilation warning:
In file lib/test_bitmap.c
@@ -692,7 +692,7 @@ struct clump_test_data_params {
unsigned long const *exp;
};
-struct clump_test_data_params clump_test_data[] =
+static struct clump_test_data_params clump_test_data[] __initdata =
{ {{0}, 2, 0, 64, 8, clump_exp1},
{{0}, 8, 2, 240, 24, clump_exp2},
{{0}, 8, 10, 240, 30, clump_exp3},
Let me know if I should submit a new patchset (v8) for
'for_each_set_clump' including above code fix.
Just to share how I attempted to reproduce the warning (but unsuccessful):
Step 1: Use the config file in attachment. Download, extract, rename
file to .config at the root of the tree.
Step 2: '$ make lib/'
No warning reproduced after above step 2.
Step 3: '$ make W=1 C=1 ARCH=x86_64 CF='-fdiagnostic-prefix
-D__CHECK_ENDIAN__' lib/'
After step 3 I got error in build:
scripts/kconfig/conf --syncconfig Kconfig
CHECK scripts/mod/empty.c
No such file: asan-globals=1
scripts/Makefile.build:266: recipe for target 'scripts/mod/empty.o' failed
make[1]: *** [scripts/mod/empty.o] Error 1
Makefile:1147: recipe for target 'prepare0' failed
make: *** [prepare0] Error 2
The command in above step 3 was mentioned in the bot mail.
Regards
Syed Nayyar Waris
Hi Syed Nayyar Waris,
We can reproduce the warning with the steps in original report,
you may need to build the whole kernel instead of the 'lib'.
Best Regards,
Rong Chen
[PATCH v1 0/2] scsi: ufs: Fix and cleanup device quirk
Hi, this series provides some device quirk fixes and cleanups. Stanley Chu (2): scsi: ufs: Add DELAY_BEFORE_LPM quirk for Micron devices scsi: ufs: Cleanup device vendor and quirk definition drivers/scsi/ufs/ufs_quirks.h | 3 ++- drivers/scsi/ufs/ufshcd.c | 6 +++--- 2 files changed, 5 insertions(+), 4 deletions(-) -- 2.18.0
[PATCH v1 1/2] scsi: ufs: Add DELAY_BEFORE_LPM quirk for Micron devices
It is confirmed that Micron device needs DELAY_BEFORE_LPM
quirk to have a delay before VCC is powered off. So add Micron
vendor ID and this quirk for Micron devices.
Signed-off-by: Stanley Chu
---
drivers/scsi/ufs/ufs_quirks.h | 1 +
drivers/scsi/ufs/ufshcd.c | 2 ++
2 files changed, 3 insertions(+)
diff --git a/drivers/scsi/ufs/ufs_quirks.h b/drivers/scsi/ufs/ufs_quirks.h
index e3175a63c676..e80d5f26a442 100644
--- a/drivers/scsi/ufs/ufs_quirks.h
+++ b/drivers/scsi/ufs/ufs_quirks.h
@@ -12,6 +12,7 @@
#define UFS_ANY_VENDOR 0x
#define UFS_ANY_MODEL "ANY_MODEL"
+#define UFS_VENDOR_MICRON 0x12C
#define UFS_VENDOR_TOSHIBA 0x198
#define UFS_VENDOR_SAMSUNG 0x1CE
#define UFS_VENDOR_SKHYNIX 0x1AD
diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
index 04b79ca66fdf..dea4fddf9332 100644
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -216,6 +216,8 @@ ufs_get_desired_pm_lvl_for_dev_link_state(enum
ufs_dev_pwr_mode dev_state,
static struct ufs_dev_fix ufs_fixups[] = {
/* UFS cards deviations table */
+ UFS_FIX(UFS_VENDOR_MICRON, UFS_ANY_MODEL,
+ UFS_DEVICE_QUIRK_DELAY_BEFORE_LPM),
UFS_FIX(UFS_VENDOR_SAMSUNG, UFS_ANY_MODEL,
UFS_DEVICE_QUIRK_DELAY_BEFORE_LPM),
UFS_FIX(UFS_VENDOR_SAMSUNG, UFS_ANY_MODEL,
--
2.18.0
[PATCH v1 2/2] scsi: ufs: Cleanup device vendor and quirk definition
Cleanup below items,
- Arrange vendor name in alphabetical order
- Squash device quirks as compact as possible in device quirk table
to enhance performance of the lookup.
Signed-off-by: Stanley Chu
---
drivers/scsi/ufs/ufs_quirks.h | 2 +-
drivers/scsi/ufs/ufshcd.c | 6 ++
2 files changed, 3 insertions(+), 5 deletions(-)
diff --git a/drivers/scsi/ufs/ufs_quirks.h b/drivers/scsi/ufs/ufs_quirks.h
index e80d5f26a442..2a0041493e30 100644
--- a/drivers/scsi/ufs/ufs_quirks.h
+++ b/drivers/scsi/ufs/ufs_quirks.h
@@ -13,9 +13,9 @@
#define UFS_ANY_MODEL "ANY_MODEL"
#define UFS_VENDOR_MICRON 0x12C
-#define UFS_VENDOR_TOSHIBA 0x198
#define UFS_VENDOR_SAMSUNG 0x1CE
#define UFS_VENDOR_SKHYNIX 0x1AD
+#define UFS_VENDOR_TOSHIBA 0x198
#define UFS_VENDOR_WDC 0x145
/**
diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
index dea4fddf9332..7c93cb446f51 100644
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -219,10 +219,8 @@ static struct ufs_dev_fix ufs_fixups[] = {
UFS_FIX(UFS_VENDOR_MICRON, UFS_ANY_MODEL,
UFS_DEVICE_QUIRK_DELAY_BEFORE_LPM),
UFS_FIX(UFS_VENDOR_SAMSUNG, UFS_ANY_MODEL,
- UFS_DEVICE_QUIRK_DELAY_BEFORE_LPM),
- UFS_FIX(UFS_VENDOR_SAMSUNG, UFS_ANY_MODEL,
- UFS_DEVICE_QUIRK_RECOVERY_FROM_DL_NAC_ERRORS),
- UFS_FIX(UFS_VENDOR_SAMSUNG, UFS_ANY_MODEL,
+ UFS_DEVICE_QUIRK_DELAY_BEFORE_LPM |
+ UFS_DEVICE_QUIRK_RECOVERY_FROM_DL_NAC_ERRORS |
UFS_DEVICE_QUIRK_HOST_PA_TACTIVATE),
UFS_FIX(UFS_VENDOR_TOSHIBA, UFS_ANY_MODEL,
UFS_DEVICE_QUIRK_DELAY_BEFORE_LPM),
--
2.18.0
Re: [PATCH] scsi: powertec: Fix different dev_id between 'request_irq()' and 'free_irq()'
Le 10/06/2020 à 04:41, Martin K. Petersen a écrit : On Sat, 30 May 2020 09:29:33 +0200, Christophe JAILLET wrote: The dev_id used in 'request_irq()' and 'free_irq()' should match. So use 'host' in both cases. Applied to 5.8/scsi-queue, thanks! [1/1] scsi: powertec: Fix different dev_id between request_irq() and free_irq() https://git.kernel.org/mkp/scsi/c/af7b415a1ebf Please revert, the patch is bogus, as spotted by Russell King - ARM Linux admin . See [1]. I'll try to send the correct fix by this week-end. CJ [1]: https://marc.info/?l=linux-scsi=159083184215730=4
Re: [PATCH] scsi: eesox: Fix different dev_id between 'request_irq()' and 'free_irq()'
Le 10/06/2020 à 04:41, Martin K. Petersen a écrit : On Sat, 30 May 2020 09:34:18 +0200, Christophe JAILLET wrote: The dev_id used in 'request_irq()' and 'free_irq()' should match. So use 'host' in both cases. Applied to 5.8/scsi-queue, thanks! [1/1] scsi: eesox: Fix different dev_id between request_irq() and free_irq() https://git.kernel.org/mkp/scsi/c/3bab76807d95 Please revert, the patch is bogus, as spotted by Russell King - ARM Linux admin . See [1]. I'll try to send the correct fix by this week-end. CJ [1]: https://marc.info/?l=linux-scsi=159083184215730=4
Re: Re: [PATCH v2] scripts/spelling: Recommend blocklist/allowlist instead of blacklist/whitelist
On Tue, 09 Jun 2020 18:35:46 -0700 Joe Perches wrote: > On Tue, 2020-06-09 at 14:25 +0200, SeongJae Park wrote: > > From: SeongJae Park > > > > This commit recommends the patches to replace 'blacklist' and > > 'whitelist' with the 'blocklist' and 'allowlist', because the new > > suggestions are incontrovertible, doesn't make people hurt, and more > > self-explanatory. > > nack. Spelling is for typos not for politics. Agreed, I'm abusing the spell checking. I personally believe the terms will eventually removed from the dictionary and become typos, though. I will update checkpatch to support deprecated terms checking, and set the 'blacklist' and 'whitelist' as the deprecated terms in the next spin. Thanks, SeongJae Park > > > Signed-off-by: SeongJae Park > > --- > > scripts/spelling.txt | 2 ++ > > 1 file changed, 2 insertions(+) > > > > diff --git a/scripts/spelling.txt b/scripts/spelling.txt > > index d9cd24cf0d40..ea785568d8b8 100644 > > --- a/scripts/spelling.txt > > +++ b/scripts/spelling.txt > > @@ -230,6 +230,7 @@ beter||better > > betweeen||between > > bianries||binaries > > bitmast||bitmask > > +blacklist||blocklist > > boardcast||broadcast > > borad||board > > boundry||boundary > > @@ -1495,6 +1496,7 @@ whcih||which > > whenver||whenever > > wheter||whether > > whe||when > > +whitelist||allowlist > > wierd||weird > > wiil||will > > wirte||write
Re: [RFC PATCH v4 07/10] vfio/pci: introduce a new irq type VFIO_IRQ_TYPE_REMAP_BAR_REGION
On Fri, Jun 05, 2020 at 10:13:01AM -0600, Alex Williamson wrote: > On Thu, 4 Jun 2020 22:02:31 -0400 > Yan Zhao wrote: > > > On Wed, Jun 03, 2020 at 10:10:58PM -0600, Alex Williamson wrote: > > > On Wed, 3 Jun 2020 22:42:28 -0400 > > > Yan Zhao wrote: > > > > > > > On Wed, Jun 03, 2020 at 05:04:52PM -0600, Alex Williamson wrote: > > > > > On Tue, 2 Jun 2020 21:40:58 -0400 > > > > > Yan Zhao wrote: > > > > > > > > > > > On Tue, Jun 02, 2020 at 01:34:35PM -0600, Alex Williamson wrote: > > > > > > > I'm not at all happy with this. Why do we need to hide the > > > > > > > migration > > > > > > > sparse mmap from the user until migration time? What if instead > > > > > > > we > > > > > > > introduced a new VFIO_REGION_INFO_CAP_SPARSE_MMAP_SAVING > > > > > > > capability > > > > > > > where the existing capability is the normal runtime sparse setup > > > > > > > and > > > > > > > the user is required to use this new one prior to enabled > > > > > > > device_state > > > > > > > with _SAVING. The vendor driver could then simply track mmap > > > > > > > vmas to > > > > > > > the region and refuse to change device_state if there are > > > > > > > outstanding > > > > > > > mmaps conflicting with the _SAVING sparse mmap layout. No new > > > > > > > IRQs > > > > > > > required, no new irqfds, an incremental change to the protocol, > > > > > > > backwards compatible to the extent that a vendor driver requiring > > > > > > > this > > > > > > > will automatically fail migration. > > > > > > > > > > > > > right. looks we need to use this approach to solve the problem. > > > > > > thanks for your guide. > > > > > > so I'll abandon the current remap irq way for dirty tracking during > > > > > > live > > > > > > migration. > > > > > > but anyway, it demos how to customize irq_types in vendor drivers. > > > > > > then, what do you think about patches 1-5? > > > > > > > > > > In broad strokes, I don't think we've found the right solution yet. I > > > > > really question whether it's supportable to parcel out vfio-pci like > > > > > this and I don't know how I'd support unraveling whether we have a bug > > > > > in vfio-pci, the vendor driver, or how the vendor driver is making use > > > > > of vfio-pci. > > > > > > > > > > Let me also ask, why does any of this need to be in the kernel? We > > > > > spend 5 patches slicing up vfio-pci so that we can register a vendor > > > > > driver and have that vendor driver call into vfio-pci as it sees fit. > > > > > We have two patches creating device specific interrupts and a BAR > > > > > remapping scheme that we've decided we don't need. That brings us to > > > > > the actual i40e vendor driver, where the first patch is simply making > > > > > the vendor driver work like vfio-pci already does, the second patch is > > > > > handling the migration region, and the third patch is implementing the > > > > > BAR remapping IRQ that we decided we don't need. It's difficult to > > > > > actually find the small bit of code that's required to support > > > > > migration outside of just dealing with the protocol we've defined to > > > > > expose this from the kernel. So why are we trying to do this in the > > > > > kernel? We have quirk support in QEMU, we can easily flip > > > > > MemoryRegions on and off, etc. What access to the device outside of > > > > > what vfio-pci provides to the user, and therefore QEMU, is necessary > > > > > to > > > > > implement this migration support for i40e VFs? Is this just an > > > > > exercise in making use of the migration interface? Thanks, > > > > > > > > > hi Alex > > > > > > > > There was a description of intention of this series in RFC v1 > > > > (https://www.spinics.net/lists/kernel/msg3337337.html). > > > > sorry, I didn't include it in starting from RFC v2. > > > > > > > > " > > > > The reason why we don't choose the way of writing mdev parent driver is > > > > that > > > > > > I didn't mention an mdev approach, I'm asking what are we accomplishing > > > by doing this in the kernel at all versus exposing the device as normal > > > through vfio-pci and providing the migration support in QEMU. Are you > > > actually leveraging having some sort of access to the PF in supporting > > > migration of the VF? Is vfio-pci masking the device in a way that > > > prevents migrating the state from QEMU? > > > > > yes, communication to PF is required. VF state is managed by PF and is > > queried from PF when VF is stopped. > > > > migration support in QEMU seems only suitable to devices with dirty > > pages and device state available by reading/writing device MMIOs, which > > is not the case for most devices. > > Post code for such a device. > hi Alex, There's an example in i40e vf. virtual channel related resources are in guest memory. dirty page tracking requires the info stored in those guest memory. there're two ways to get the resources addresses: (1) always trap VF registers related. as in
Re: [PATCH v3 1/4] fs, net: Standardize on file_receive helper to move fds across processes
On Tue, Jun 09, 2020 at 11:27:30PM +0200, Christian Brauner wrote:
> On June 9, 2020 10:55:42 PM GMT+02:00, Kees Cook
> wrote:
> >LOL. And while we were debating this, hch just went and cleaned stuff up:
> >
> >2618d530dd8b ("net/scm: cleanup scm_detach_fds")
> >
> >So, um, yeah, now my proposal is actually even closer to what we already
> >have there. We just add the replace_fd() logic to __scm_install_fd() and
> >we're done with it.
>
> Cool, you have a link? :)
How about this:
https://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git/commit/?h=devel/seccomp/addfd/v3.1=bb94586b9e7cc88e915536c2e9fb991a97b62416
--
Kees Cook
Re: [PATCH v2] HID: usbhid: do not sleep when opening device
On Tue, Jun 9, 2020 at 9:38 PM Dmitry Torokhov
wrote:
>
> usbhid tries to give the device 50 milliseconds to drain its queues when
> opening the device, but dies it naively by simply sleeping in open handler,
> which slows down device probing (and thus may affect overall boot time).
>
> However we do not need to sleep as we can instead mark a point of time in
> the future when we should start processing the events.
>
> Reported-by: Nicolas Boichat
> Signed-off-by: Dmitry Torokhov
Reviewed-by: Guenter Roeck
> ---
>
> v2: switched from using jiffies to ktime_t to make sure we won't have
> issues with jiffies overflowing.
>
> drivers/hid/usbhid/hid-core.c | 53 +++
> drivers/hid/usbhid/usbhid.h | 2 ++
> 2 files changed, 31 insertions(+), 24 deletions(-)
>
> diff --git a/drivers/hid/usbhid/hid-core.c b/drivers/hid/usbhid/hid-core.c
> index c7bc9db5b192..72c92aab2b18 100644
> --- a/drivers/hid/usbhid/hid-core.c
> +++ b/drivers/hid/usbhid/hid-core.c
> @@ -26,6 +26,7 @@
> #include
> #include
> #include
> +#include
>
> #include
>
> @@ -95,6 +96,18 @@ static int hid_start_in(struct hid_device *hid)
> set_bit(HID_NO_BANDWIDTH, >iofl);
> } else {
> clear_bit(HID_NO_BANDWIDTH, >iofl);
> +
> + if (test_bit(HID_RESUME_RUNNING, >iofl)) {
> + /*
> +* In case events are generated while nobody
> was
> +* listening, some are released when the
> device
> +* is re-opened. Wait 50 msec for the queue to
> +* empty before allowing events to go through
> +* hid.
> +*/
> + usbhid->input_start_time =
> + ktime_add_ms(ktime_get_coarse(), 50);
> + }
> }
> }
> spin_unlock_irqrestore(>lock, flags);
> @@ -280,20 +293,23 @@ static void hid_irq_in(struct urb *urb)
> if (!test_bit(HID_OPENED, >iofl))
> break;
> usbhid_mark_busy(usbhid);
> - if (!test_bit(HID_RESUME_RUNNING, >iofl)) {
> - hid_input_report(urb->context, HID_INPUT_REPORT,
> -urb->transfer_buffer,
> -urb->actual_length, 1);
> - /*
> -* autosuspend refused while keys are pressed
> -* because most keyboards don't wake up when
> -* a key is released
> -*/
> - if (hid_check_keys_pressed(hid))
> - set_bit(HID_KEYS_PRESSED, >iofl);
> - else
> - clear_bit(HID_KEYS_PRESSED, >iofl);
> + if (test_bit(HID_RESUME_RUNNING, >iofl)) {
> + if (ktime_before(ktime_get_coarse(),
> +usbhid->input_start_time))
> + break;
> + clear_bit(HID_RESUME_RUNNING, >iofl);
> }
> + hid_input_report(urb->context, HID_INPUT_REPORT,
> +urb->transfer_buffer, urb->actual_length, 1);
> + /*
> +* autosuspend refused while keys are pressed
> +* because most keyboards don't wake up when
> +* a key is released
> +*/
> + if (hid_check_keys_pressed(hid))
> + set_bit(HID_KEYS_PRESSED, >iofl);
> + else
> + clear_bit(HID_KEYS_PRESSED, >iofl);
> break;
> case -EPIPE:/* stall */
> usbhid_mark_busy(usbhid);
> @@ -714,17 +730,6 @@ static int usbhid_open(struct hid_device *hid)
> }
>
> usb_autopm_put_interface(usbhid->intf);
> -
> - /*
> -* In case events are generated while nobody was listening,
> -* some are released when the device is re-opened.
> -* Wait 50 msec for the queue to empty before allowing events
> -* to go through hid.
> -*/
> - if (res == 0)
> - msleep(50);
> -
> - clear_bit(HID_RESUME_RUNNING, >iofl);
> return res;
> }
>
> diff --git a/drivers/hid/usbhid/usbhid.h b/drivers/hid/usbhid/usbhid.h
> index 8620408bd7af..0f0bcf7037f8 100644
> --- a/drivers/hid/usbhid/usbhid.h
> +++ b/drivers/hid/usbhid/usbhid.h
> @@ -13,6 +13,7 @@
>
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -82,6 +83,7 @@ struct usbhid_device {
>
> spinlock_t lock;/*
> fifo spinlock */
> unsigned
Re: next-0519 on thinkpad x60: sound related? window manager crash
On Tue, 9 Jun 2020, Christoph Hellwig wrote:
> > Working theory is that CONFIG_DMA_NONCOHERENT_MMAP getting set is causing
> > the error_code in the page fault path. Debugging with Alex off-thread we
> > found that dma_{alloc,free}_from_pool() are not getting called from the
> > new code in dma_direct_{alloc,free}_pages() and he has not enabled
> > mem_encrypt.
>
> While DMA_COHERENT_POOL absolutely should not select DMA_NONCOHERENT_MMAP
> (and you should send your patch either way), I don't think it is going
> to make a difference here, as DMA_NONCOHERENT_MMAP just means we
> allows mmaps even for non-coherent devices, and we do not support
> non-coherent devices on x86.
>
We haven't heard yet whether the disabling of DMA_NONCOHERENT_MMAP fixes
Aaron's BUG(), and the patch included some other debugging hints that will
be printed out in case it didn't, but I'll share what we figured out:
In 5.7, his config didn't have DMA_DIRECT_REMAP or DMA_REMAP (it did have
GENERIC_ALLOCATOR already). AMD_MEM_ENCRYPT is set.
In Linus HEAD, AMD_MEM_ENCRYPT now selects DMA_COHERENT_POOL so it sets
the two aforementioned options.
We also figured out that dma_should_alloc_from_pool() is always false up
until the BUG(). So what else changed? Only the selection of DMA_REMAP
and DMA_NONCOHERENT_MMAP.
The comment in the Kconfig about setting "an uncached bit in the
pagetables" led me to believe it may be related to the splat he's seeing
(reserved bit violation). So I suggested dropping DMA_NONCOHERENT_MMAP
from his Kconfig for testing purposes.
If this option should not implicitly be set for DMA_COHERENT_POOL, then I
assume we need yet another Kconfig option since DMA_REMAP selected it
before and DMA_COHERENT_POOL selects DMA_REMAP :)
So do we want a DMA_REMAP_BUT_NO_DMA_NONCOHERENT_MMAP? Decouple DMA_REMAP
from DMA_NONCOHERENT_MMAP and select the latter wherever the former was
set (but not DMA_COHERENT_POOL)? Something else?
Re: [PATCH] docs/zh_CN: update sysfs.txt about show() usage
Reviewed-by: Alex Shi Thanks Alex 在 2020/6/10 上午10:53, Chen Zhou 写道: > Update the show() usage according to the English version. > > Signed-off-by: Chen Zhou > --- > Documentation/translations/zh_CN/filesystems/sysfs.txt | 6 -- > 1 file changed, 4 insertions(+), 2 deletions(-) > > diff --git a/Documentation/translations/zh_CN/filesystems/sysfs.txt > b/Documentation/translations/zh_CN/filesystems/sysfs.txt > index fcf620049d11..9481e3ed2a06 100644 > --- a/Documentation/translations/zh_CN/filesystems/sysfs.txt > +++ b/Documentation/translations/zh_CN/filesystems/sysfs.txt > @@ -213,10 +213,12 @@ Sysfs 将会为每次读写操作调用一次这个方法。这使得这些方 > > - 缓冲区应总是 PAGE_SIZE 大小。对于i386，这个值为4096。 > > -- show() 方法应该返回写入缓冲区的字节数，也就是 snprintf()的 > +- show() 方法应该返回写入缓冲区的字节数，也就是 scnprintf()的 >返回值。 > > -- show() 应始终使用 snprintf()。 > +- show() 方法在将格式化返回值返回用户空间的时候，禁止使用snprintf()。 > + 如果可以保证不会发生缓冲区溢出，可以使用sprintf()，否则必须使用 > + scnprintf()。 > > - store() 应返回缓冲区的已用字节数。如果整个缓存都已填满，只需返回 >count 参数。 >
Re: [patch 113/131] mm: balance LRU lists based on relative thrashing
2020년 6월 9일 (화) 오후 11:46, Johannes Weiner 님이 작성: > > On Tue, Jun 09, 2020 at 05:15:33PM +0800, Alex Shi wrote: > > > > > > 在 2020/6/4 上午7:03, Andrew Morton 写道: > > > > > > + /* XXX: Move to lru_cache_add() when it supports new vs putback */ > > > > Hi Hannes, > > > > Sorry for a bit lost, would you like to explain a bit more of your idea > > here? > > > > > + spin_lock_irq(_pgdat(page)->lru_lock); > > > + lru_note_cost(page); > > > + spin_unlock_irq(_pgdat(page)->lru_lock); > > > + > > > > > > What could we see here w/o the lru_lock? > > It'll just be part of the existing LRU locking in > pagevec_lru_move_fn(), when the new pages are added to the LRU in > batch. See this older patch for example: > > https://lore.kernel.org/linux-mm/20160606194836.3624-6-han...@cmpxchg.org/ > > I didn't include it in this series to reduce conflict with Joonsoo's > WIP series that also operates in this area and does something similar: Thanks! > https://lkml.org/lkml/2020/4/3/63 I haven't completed the rebase of my series but I guess that referenced patch "https://lkml.org/lkml/2020/4/3/63; would be removed in the next version. Before the I/O cost model, a new anonymous page contributes to the LRU reclaim balance. But, now, a new anonymous page doesn't contributes to the I/O cost so this adjusting patch would not be needed anymore. If anyone wants to change this part, "/* XXX: Move to lru_cache_add() when it supports new vs putback */", feel free to do it. Thanks.
[PATCH] mm/page_alloc: silence a KASAN false positive
kernel_init_free_pages() will use memset() on s390 to clear all pages
from kmalloc_order() which will override KASAN redzones because a
redzone was setup from the end of the allocation size to the end of the
last page. Silence it by not reporting it there. An example of the
report is,
BUG: KASAN: slab-out-of-bounds in __free_pages_ok
Write of size 4096 at addr 00014beaa000
Call Trace:
show_stack+0x152/0x210
dump_stack+0x1f8/0x248
print_address_description.isra.13+0x5e/0x4d0
kasan_report+0x130/0x178
check_memory_region+0x190/0x218
memset+0x34/0x60
__free_pages_ok+0x894/0x12f0
kfree+0x4f2/0x5e0
unpack_to_rootfs+0x60e/0x650
populate_rootfs+0x56/0x358
do_one_initcall+0x1f4/0xa20
kernel_init_freeable+0x758/0x7e8
kernel_init+0x1c/0x170
ret_from_fork+0x24/0x28
Memory state around the buggy address:
00014bea9f00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00014bea9f80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>00014beaa000: 03 fe fe fe fe fe fe fe fe fe fe fe fe fe fe fe
^
00014beaa080: fe fe fe fe fe fe fe fe fe fe fe fe fe fe fe fe
00014beaa100: fe fe fe fe fe fe fe fe fe fe fe fe fe fe
Fixes: 6471384af2a6 ("mm: security: introduce init_on_alloc=1 and
init_on_free=1 boot options")
Signed-off-by: Qian Cai
---
mm/page_alloc.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 727751219003..9954973f89a3 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -1164,8 +1164,11 @@ static void kernel_init_free_pages(struct page *page,
int numpages)
{
int i;
+ /* s390's use of memset() could override KASAN redzones. */
+ kasan_disable_current();
for (i = 0; i < numpages; i++)
clear_highpage(page + i);
+ kasan_enable_current();
}
static __always_inline bool free_pages_prepare(struct page *page,
--
2.21.0 (Apple Git-122.2)
[PATCH 1/2] perf expr: Add d_ratio operation
This simplifies computing ratios in json expressions.
Signed-off-by: Ian Rogers
---
tools/perf/util/expr.l | 1 +
tools/perf/util/expr.y | 14 --
2 files changed, 13 insertions(+), 2 deletions(-)
diff --git a/tools/perf/util/expr.l b/tools/perf/util/expr.l
index f397bf8b1a48..298d86660a96 100644
--- a/tools/perf/util/expr.l
+++ b/tools/perf/util/expr.l
@@ -100,6 +100,7 @@ symbol ({spec}|{sym})+
}
}
+d_ratio{ return D_RATIO; }
max{ return MAX; }
min{ return MIN; }
if { return IF; }
diff --git a/tools/perf/util/expr.y b/tools/perf/util/expr.y
index bf3e898e3055..fe145344bb39 100644
--- a/tools/perf/util/expr.y
+++ b/tools/perf/util/expr.y
@@ -10,6 +10,14 @@
#include "smt.h"
#include
+static double d_ratio(double val0, double val1)
+{
+ if (val1 == 0) {
+ return 0;
+ }
+ return val0 / val1;
+}
+
%}
%define api.pure full
@@ -28,7 +36,7 @@
%token NUMBER
%token ID
%destructor { free ($$); }
-%token MIN MAX IF ELSE SMT_ON
+%token MIN MAX IF ELSE SMT_ON D_RATIO
%left MIN MAX IF
%left '|'
%left '^'
@@ -64,7 +72,8 @@ other: ID
}
|
MIN | MAX | IF | ELSE | SMT_ON | NUMBER | '|' | '^' | '&' | '-' | '+' | '*' |
'/' | '%' | '(' | ')' | ','
-
+|
+D_RATIO
all_expr: if_expr { *final_val = $1; }
;
@@ -105,6 +114,7 @@ expr: NUMBER
| MIN '(' expr ',' expr ')' { $$ = $3 < $5 ? $3 : $5; }
| MAX '(' expr ',' expr ')' { $$ = $3 > $5 ? $3 : $5; }
| SMT_ON { $$ = smt_on() > 0; }
+ | D_RATIO '(' expr ',' expr ')' { $$ = d_ratio($3,$5); }
;
%%
--
2.27.0.278.ge193c7cf3a9-goog
[PATCH 2/2] perf expr: Add < and > operators
These are broadly useful and necessary for Intel's top-down analysis.
Signed-off-by: Ian Rogers
---
tools/perf/util/expr.l | 2 ++
tools/perf/util/expr.y | 5 -
2 files changed, 6 insertions(+), 1 deletion(-)
diff --git a/tools/perf/util/expr.l b/tools/perf/util/expr.l
index 298d86660a96..13e5e3c75f56 100644
--- a/tools/perf/util/expr.l
+++ b/tools/perf/util/expr.l
@@ -111,6 +111,8 @@ else{ return ELSE; }
"|"{ return '|'; }
"^"{ return '^'; }
"&"{ return '&'; }
+"<"{ return '<'; }
+">"{ return '>'; }
"-"{ return '-'; }
"+"{ return '+'; }
"*"{ return '*'; }
diff --git a/tools/perf/util/expr.y b/tools/perf/util/expr.y
index fe145344bb39..5fcb98800f9c 100644
--- a/tools/perf/util/expr.y
+++ b/tools/perf/util/expr.y
@@ -41,6 +41,7 @@ static double d_ratio(double val0, double val1)
%left '|'
%left '^'
%left '&'
+%left '<' '>'
%left '-' '+'
%left '*' '/' '%'
%left NEG NOT
@@ -73,7 +74,7 @@ other: ID
|
MIN | MAX | IF | ELSE | SMT_ON | NUMBER | '|' | '^' | '&' | '-' | '+' | '*' |
'/' | '%' | '(' | ')' | ','
|
-D_RATIO
+'<' | '>' | D_RATIO
all_expr: if_expr { *final_val = $1; }
;
@@ -94,6 +95,8 @@ expr: NUMBER
| expr '|' expr { $$ = (long)$1 | (long)$3; }
| expr '&' expr { $$ = (long)$1 & (long)$3; }
| expr '^' expr { $$ = (long)$1 ^ (long)$3; }
+ | expr '<' expr { $$ = $1 < $3; }
+ | expr '>' expr { $$ = $1 > $3; }
| expr '+' expr { $$ = $1 + $3; }
| expr '-' expr { $$ = $1 - $3; }
| expr '*' expr { $$ = $1 * $3; }
--
2.27.0.278.ge193c7cf3a9-goog
Re: [PATCH v2 07/12] mm/hugetlb: do not modify user provided gfp_mask
2020년 6월 9일 (화) 오후 10:54, Michal Hocko 님이 작성: > > On Wed 27-05-20 15:44:58, Joonsoo Kim wrote: > > From: Joonsoo Kim > > > > It's not good practice to modify user input. Instead of using it to > > build correct gfp_mask for APIs, this patch introduces another gfp_mask > > field, __gfp_mask, for internal usage. > > Ugh, this is really ugly. It is just hugetlb to add __GFP_THISNODE as a > special case. This is an ugly hack but I do not think we want to work > around it by yet another hack. Moreover it seems that the __GFP_THISNODE > might be not needed anymore as pointed out in a reply to earlier patch. If you mean __GFP_THISNODE handling is ugly, as you pointed out, __GFP_THISNODE handling would be removed in the next version. If you mean introducing __gfp_mask is ugly, I will try to use a local variable to keep modified gfp_mask rather than introducing a field in alloc_control. Thanks.
Dear: Sir/Madam,
Date: 10th June 2020. Time: 09:45am (Washington DC Time GMT) Dear: Sir/Madam, This official memorandum is to know if you receive our previous mail. Officially Sealed. Mr. David Lance Bowdich. bakhti...@azn.ir | metallo.com Disclaimer: This message (including any attachments) is intended for the addressee only and may contain confidential or privileged information. If you have received this message by mistake, you must not copy this message or any attachments neither disclose the contents to any other person. Please notify the sender, destroy any copies and permanently delete this message and any attachments from your computer system. Email transmission cannot be guaranteed to be secure or error free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. No responsibility is accepted for any loss or damage arising in any way from its use. The addressee of this message has to check whether the sender has authority to conclude or enter into binding contracts, engagements, understandings, etc. on behalf of the company.
回复: 回复: [PATCH v2] usb: gadget: function: printer: fix use-after-free in __lock_acquire
cdev object reference count and "struct printer_dev" object reference count(kref), This two reference counts do not conflict. in file usb-skeleton.c also used a similar method， "struct usb_skel" contains kref members. thanks, Zqiang 发件人: Greg KH 发送时间: 2020年6月9日 17:48 收件人: Zhang, Qiang 抄送: ba...@kernel.org; linux-...@vger.kernel.org; linux-kernel@vger.kernel.org 主题: Re: 回复: [PATCH v2] usb: gadget: function: printer: fix use-after-free in __lock_acquire A: http://en.wikipedia.org/wiki/Top_post Q: Were do I find info about this thing called top-posting? A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? A: No. Q: Should I include quotations after my reply? http://daringfireball.net/2007/07/on_top On Tue, Jun 09, 2020 at 09:35:11AM +, Zhang, Qiang wrote: > Thank you for your suggestion > two referenced counted objects in the same exact structure. another > referenced is > "dev->printer_cdev_open"? Maybe, I don't know, but a cdev does have a reference count already, right? Why do you need printer_cdev_open as well? thanks, greg k-h
[PATCH 0/2] Use __scm_install_fd() more widely
Hi, This extends the recent work hch did for scm_detach_fds(), and updates the compat path as well, fixing bugs in the process. Additionally, an effectively incomplete and open-coded __scm_install_fd() is fixed in pidfd_getfd(). Thanks! -Kees Kees Cook (2): net/scm: Regularize compat handling of scm_detach_fds() pidfd: Replace open-coded partial __scm_install_fd() include/net/scm.h | 1 + kernel/pid.c | 12 ++- net/compat.c | 55 +-- net/core/scm.c| 43 +++- 4 files changed, 56 insertions(+), 55 deletions(-) -- 2.25.1
[PATCH 2/2] pidfd: Replace open-coded partial __scm_install_fd()
The sock counting (sock_update_netprioidx() and sock_update_classid())
was missing from this implementation of fd installation, compared to
SCM_RIGHTS. Use the new scm helper to get the work done, after adjusting
it to return the installed fd and accept a NULL user pointer.
Fixes: 8649c322f75c ("pid: Implement pidfd_getfd syscall")
Signed-off-by: Kees Cook
---
AFAICT, the following patches are needed for back-porting this to stable:
0462b6bdb644 ("net: add a CMSG_USER_DATA macro")
2618d530dd8b ("net/scm: cleanup scm_detach_fds")
1f466e1f15cf ("net: cleanly handle kernel vs user buffers for ->msg_control")
6e8a4f9dda38 ("net: ignore sock_from_file errors in __scm_install_fd")
---
kernel/pid.c | 12 ++--
net/compat.c | 2 +-
net/core/scm.c | 27 ---
3 files changed, 23 insertions(+), 18 deletions(-)
diff --git a/kernel/pid.c b/kernel/pid.c
index f1496b757162..a7ce4ba898d3 100644
--- a/kernel/pid.c
+++ b/kernel/pid.c
@@ -42,6 +42,7 @@
#include
#include
#include
+#include
struct pid init_struct_pid = {
.count = REFCOUNT_INIT(1),
@@ -635,18 +636,9 @@ static int pidfd_getfd(struct pid *pid, int fd)
if (IS_ERR(file))
return PTR_ERR(file);
- ret = security_file_receive(file);
- if (ret) {
- fput(file);
- return ret;
- }
-
- ret = get_unused_fd_flags(O_CLOEXEC);
+ ret = __scm_install_fd(file, NULL, O_CLOEXEC);
if (ret < 0)
fput(file);
- else
- fd_install(ret, file);
-
return ret;
}
diff --git a/net/compat.c b/net/compat.c
index 117f1869bf3b..f857b6d7 100644
--- a/net/compat.c
+++ b/net/compat.c
@@ -299,7 +299,7 @@ void scm_detach_fds_compat(struct msghdr *msg, struct
scm_cookie *scm)
for (i = 0; i < fdmax; i++) {
err = __scm_install_fd(scm->fp->fp[i], cmsg_data + i, o_flags);
- if (err)
+ if (err < 0)
break;
}
diff --git a/net/core/scm.c b/net/core/scm.c
index 86d96152646f..e80648fb4da7 100644
--- a/net/core/scm.c
+++ b/net/core/scm.c
@@ -280,6 +280,14 @@ void put_cmsg_scm_timestamping(struct msghdr *msg, struct
scm_timestamping_inter
}
EXPORT_SYMBOL(put_cmsg_scm_timestamping);
+/**
+ * __scm_install_fd() - Install received file into file descriptor table
+ *
+ * Installs a received file into the file descriptor table, with appropriate
+ * checks and count updates.
+ *
+ * Returns fd installed or -ve on error.
+ */
int __scm_install_fd(struct file *file, int __user *ufd, int o_flags)
{
struct socket *sock;
@@ -294,20 +302,25 @@ int __scm_install_fd(struct file *file, int __user *ufd,
int o_flags)
if (new_fd < 0)
return new_fd;
- error = put_user(new_fd, ufd);
- if (error) {
- put_unused_fd(new_fd);
- return error;
+ if (ufd) {
+ error = put_user(new_fd, ufd);
+ if (error) {
+ put_unused_fd(new_fd);
+ return error;
+ }
}
- /* Bump the usage count and install the file. */
+ /* Bump the usage count and install the file. The resulting value of
+* "error" is ignored here since we only need to take action when
+* the file is a socket and testing "sock" for NULL is sufficient.
+*/
sock = sock_from_file(file, );
if (sock) {
sock_update_netprioidx(>sk->sk_cgrp_data);
sock_update_classid(>sk->sk_cgrp_data);
}
fd_install(new_fd, get_file(file));
- return 0;
+ return new_fd;
}
static int scm_max_fds(struct msghdr *msg)
@@ -337,7 +350,7 @@ void scm_detach_fds(struct msghdr *msg, struct scm_cookie
*scm)
for (i = 0; i < fdmax; i++) {
err = __scm_install_fd(scm->fp->fp[i], cmsg_data + i, o_flags);
- if (err)
+ if (err < 0)
break;
}
--
2.25.1
[PATCH 1/2] net/scm: Regularize compat handling of scm_detach_fds()
Duplicate the cleanups from commit 2618d530dd8b ("net/scm: cleanup
scm_detach_fds") into the compat code.
Also moves the check added in commit 1f466e1f15cf ("net: cleanly handle
kernel vs user buffers for ->msg_control") to before the compat call, even
though it should be impossible for an in-kernel call to also be compat.
Regularized any remaining differences, including a whitespace issue, a
checkpatch warning, and adding the check from commit 6900317f5eff ("net,
scm: fix PaX detected msg_controllen overflow in scm_detach_fds") which
fixed an overflow unique to 64-bit. To avoid confusion when comparing
the compat handler to the native handler, just include the same check
in the compat handler.
Fixes: 48a87cc26c13 ("net: netprio: fd passed in SCM_RIGHTS datagram not set
correctly")
Fixes: d84295067fc7 ("net: net_cls: fd passed in SCM_RIGHTS datagram not set
correctly")
Signed-off-by: Kees Cook
---
AFAICT, the following patches are needed for back-porting this to stable:
0462b6bdb644 ("net: add a CMSG_USER_DATA macro")
2618d530dd8b ("net/scm: cleanup scm_detach_fds")
1f466e1f15cf ("net: cleanly handle kernel vs user buffers for ->msg_control")
6e8a4f9dda38 ("net: ignore sock_from_file errors in __scm_install_fd")
---
include/net/scm.h | 1 +
net/compat.c | 55 +--
net/core/scm.c| 16 +++---
3 files changed, 34 insertions(+), 38 deletions(-)
diff --git a/include/net/scm.h b/include/net/scm.h
index 1ce365f4c256..4dcc766f15b3 100644
--- a/include/net/scm.h
+++ b/include/net/scm.h
@@ -37,6 +37,7 @@ struct scm_cookie {
#endif
};
+int __scm_install_fd(struct file *file, int __user *ufd, int o_flags);
void scm_detach_fds(struct msghdr *msg, struct scm_cookie *scm);
void scm_detach_fds_compat(struct msghdr *msg, struct scm_cookie *scm);
int __scm_send(struct socket *sock, struct msghdr *msg, struct scm_cookie
*scm);
diff --git a/net/compat.c b/net/compat.c
index 5e3041a2c37d..117f1869bf3b 100644
--- a/net/compat.c
+++ b/net/compat.c
@@ -281,39 +281,31 @@ int put_cmsg_compat(struct msghdr *kmsg, int level, int
type, int len, void *dat
return 0;
}
-void scm_detach_fds_compat(struct msghdr *kmsg, struct scm_cookie *scm)
+static int scm_max_fds_compat(struct msghdr *msg)
{
- struct compat_cmsghdr __user *cm = (struct compat_cmsghdr __user *)
kmsg->msg_control;
- int fdmax = (kmsg->msg_controllen - sizeof(struct compat_cmsghdr)) /
sizeof(int);
- int fdnum = scm->fp->count;
- struct file **fp = scm->fp->fp;
- int __user *cmfptr;
- int err = 0, i;
+ if (msg->msg_controllen <= sizeof(struct compat_cmsghdr))
+ return 0;
+ return (msg->msg_controllen - sizeof(struct compat_cmsghdr)) /
sizeof(int);
+}
- if (fdnum < fdmax)
- fdmax = fdnum;
+void scm_detach_fds_compat(struct msghdr *msg, struct scm_cookie *scm)
+{
+ struct compat_cmsghdr __user *cm =
+ (struct compat_cmsghdr __user *)msg->msg_control;
+ int o_flags = (msg->msg_flags & MSG_CMSG_CLOEXEC) ? O_CLOEXEC : 0;
+ int fdmax = min_t(int, scm_max_fds_compat(msg), scm->fp->count);
+ int __user *cmsg_data = CMSG_USER_DATA(cm);
+ int err = 0, i;
- for (i = 0, cmfptr = (int __user *) CMSG_COMPAT_DATA(cm); i < fdmax;
i++, cmfptr++) {
- int new_fd;
- err = security_file_receive(fp[i]);
+ for (i = 0; i < fdmax; i++) {
+ err = __scm_install_fd(scm->fp->fp[i], cmsg_data + i, o_flags);
if (err)
break;
- err = get_unused_fd_flags(MSG_CMSG_CLOEXEC & kmsg->msg_flags
- ? O_CLOEXEC : 0);
- if (err < 0)
- break;
- new_fd = err;
- err = put_user(new_fd, cmfptr);
- if (err) {
- put_unused_fd(new_fd);
- break;
- }
- /* Bump the usage count and install the file. */
- fd_install(new_fd, get_file(fp[i]));
}
if (i > 0) {
int cmlen = CMSG_COMPAT_LEN(i * sizeof(int));
+
err = put_user(SOL_SOCKET, >cmsg_level);
if (!err)
err = put_user(SCM_RIGHTS, >cmsg_type);
@@ -321,16 +313,19 @@ void scm_detach_fds_compat(struct msghdr *kmsg, struct
scm_cookie *scm)
err = put_user(cmlen, >cmsg_len);
if (!err) {
cmlen = CMSG_COMPAT_SPACE(i * sizeof(int));
- kmsg->msg_control += cmlen;
- kmsg->msg_controllen -= cmlen;
+ if (msg->msg_controllen < cmlen)
+ cmlen = msg->msg_controllen;
+ msg->msg_control += cmlen;
+ msg->msg_controllen -= cmlen;
}
}
- if (i < fdnum)
-
Re: [PATCH v2 0/2] fw_devlink: Improve cycle detection in DT
On Tue, Jun 9, 2020 at 6:19 PM Saravana Kannan wrote: > > Patch 2/2 explain the series. Just using a cover letter to thread the > series and add CC's. > > -Saravana > > v1 -> v2: > Patch 2/2: > - Added more comments > - Fixed missing put_device() > - Fixed stupid fall through in the error case > > Saravana Kannan (2): > driver core: Add device_is_dependent() to linux/device.h > of: property: Improve cycle detection when one of the devices is never > added > > drivers/base/core.c| 2 +- > drivers/of/property.c | 62 ++ > include/linux/device.h | 1 + > 3 files changed, 58 insertions(+), 7 deletions(-) With both patches, booting with fw_devlink=on (instead of deferred_probe_timeout=30) this allows all modules to properly load on the db845c, and without these patches, we fail to get display. Tested-by: John Stultz thanks -john
[git pull] Input updates for v5.8-rc0
Hi Linus, Please pull from: git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git for-linus to receive updates for the input subsystem. You will get: - a new driver for Azoteq IQS269A capacitive touch controller - a new driver for Cypress CY8CTMA140 touchscreen - updates to Elan and ft5x06 touchscreen drivers - assorted driver fixes - msm-vibrator has been removed as we have more generic solution. Thanks! Changelog: - Ahmad Fatoum (1): Input: edt-ft5x06 - prefer asynchronous probe Anson Huang (1): Input: imx_sc_key - use devm_add_action_or_reset() to handle all cleanups Arnd Bergmann (1): Input: adi - work around module name confict Brian Masney (2): dt-bindings: Input: remove msm-vibrator Input: remove msm-vibrator driver Christophe JAILLET (2): Input: tca6416-keypad - fix a typo in MODULE_DESCRIPTION Input: spear-keyboard - fix a typo in a module name in Kconfig David Heidelberg (1): dt-bindings: input: touchscreen: elants_i2c: convert to YAML Jeff LaBundy (3): dt-bindings: input: Add bindings for Azoteq IQS269A Input: add support for Azoteq IQS269A Input: iqs269a - add missing I2C dependency Jiada Wang (1): Input: introduce input_mt_report_slot_inactive() Johnny Chuang (1): Input: elants_i2c - provide an attribute to show calibration count Kenny Levinsen (1): Input: evdev - use keyed wakeups Linus Walleij (3): Input: delete unused GP2AP002A00F driver dt-bindings: touchscreen: Add CY8CTMA140 bindings Input: add driver for the Cypress CY8CTMA140 touchscreen Marco Felsch (3): Input: edt-ft5x06 - fix get_default register write access Input: edt-ft5x06 - move parameter restore into helper Input: edt-ft5x06 - improve power management operations Michał Mirosław (3): Input: elants - remove unused axes Input: elants - override touchscreen info with DT properties Input: elants - refactor elants_i2c_execute_command() Rajat Jain (3): Input: i8042 - attach fwnode to serio i8042 kbd device Input: atkbd - expose function row physical map to userspace Input: atkbd - receive and use physcode->keycode mapping from FW Stephan Gerhold (2): dt-bindings: mms114: document melfas,mms345l binding Input: mms114 - add extra compatible for mms345l Diffstat: .../devicetree/bindings/input/elants_i2c.txt | 34 - .../devicetree/bindings/input/iqs269a.yaml | 581 +++ .../devicetree/bindings/input/msm-vibrator.txt | 36 - .../input/touchscreen/cypress,cy8ctma140.yaml | 72 + .../input/touchscreen/elan,elants_i2c.yaml | 69 + .../bindings/input/touchscreen/mms114.txt |3 +- MAINTAINERS|6 + drivers/hid/hid-alps.c |3 +- drivers/hid/hid-multitouch.c |6 +- drivers/input/evdev.c |7 +- drivers/input/joystick/Kconfig |1 + drivers/input/keyboard/Kconfig |2 +- drivers/input/keyboard/atkbd.c | 97 +- drivers/input/keyboard/imx_sc_key.c| 33 +- drivers/input/keyboard/tca6416-keypad.c|2 +- drivers/input/misc/Kconfig | 32 +- drivers/input/misc/Makefile|3 +- drivers/input/misc/gp2ap002a00f.c | 281 --- drivers/input/misc/iqs269a.c | 1833 drivers/input/misc/msm-vibrator.c | 281 --- drivers/input/misc/xen-kbdfront.c |2 +- drivers/input/mouse/elan_i2c_core.c|2 +- drivers/input/serio/i8042-x86ia64io.h |1 + drivers/input/serio/i8042.c|3 + drivers/input/touchscreen/Kconfig | 12 + drivers/input/touchscreen/Makefile |1 + drivers/input/touchscreen/atmel_mxt_ts.c |7 +- drivers/input/touchscreen/cy8ctma140.c | 353 drivers/input/touchscreen/cyttsp4_core.c |5 +- drivers/input/touchscreen/cyttsp_core.c|2 +- drivers/input/touchscreen/edt-ft5x06.c | 198 ++- drivers/input/touchscreen/elants_i2c.c | 247 +-- drivers/input/touchscreen/melfas_mip4.c|4 +- drivers/input/touchscreen/mms114.c | 19 +- drivers/input/touchscreen/raspberrypi-ts.c |2 +- drivers/input/touchscreen/stmfts.c |2 +- include/linux/input/gp2ap002a00f.h | 23 - include/linux/input/mt.h |5 + 38 files changed, 3397 insertions(+), 873 deletions(-) delete mode 100644 Documentation/devicetree/bindings/input/elants_i2c.txt create mode 100644 Documentation/devicetree/bindings/input/iqs269a.yaml delete mode 100644
Re: [PATCH V2] vdpa: introduce virtio pci driver
On Wed, Jun 10, 2020 at 11:59:20AM +0800, Jason Wang wrote: > This patch introduce a vDPA driver for virtio-pci device. It bridges > the virtio-pci control command to the vDPA bus. This will be used for > developing new features for both software vDPA framework and hardware > vDPA feature. The mail headers are mailformed here: Content-Type: text/plain; charset=a so git am can't parse it: error: cannot convert from a to UTF-8 fatal: could not parse patch -- MST
[GIT PULL] virtio: features, fixes
There's a single commit here that I tweaked since linux-next - the change is in printk format string which I consider trivial enough not force wait for more testing. A couple of hashes are different from what's in linux-next though. I also upgraded the machine I used to sign the tag (didn't change the key) - hope the signature is still ok. If not pls let me know! The following changes since commit 3d77e6a8804abcc0504c904bd6e5cdf3a5cf8162: Linux 5.7 (2020-05-31 16:49:15 -0700) are available in the Git repository at: https://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost.git tags/for_linus for you to fetch changes up to 044e4b09223039e571e6ec540e25552054208765: vhost/test: fix up after API change (2020-06-09 06:42:06 -0400) virtio: features, fixes virtio-mem doorbell mapping for vdpa config interrupt support in ifc fixes all over the place Signed-off-by: Michael S. Tsirkin Alexander Duyck (1): virtio-balloon: Disable free page reporting if page poison reporting is not enabled David Hildenbrand (17): MAINTAINERS: Add myself as virtio-balloon co-maintainer virtio-mem: Paravirtualized memory hotplug MAINTAINERS: Add myself as virtio-mem maintainer virtio-mem: Allow to specify an ACPI PXM as nid virtio-mem: Paravirtualized memory hotunplug part 1 virtio-mem: Paravirtualized memory hotunplug part 2 mm: Allow to offline unmovable PageOffline() pages via MEM_GOING_OFFLINE virtio-mem: Allow to offline partially unplugged memory blocks mm/memory_hotplug: Introduce offline_and_remove_memory() virtio-mem: Offline and remove completely unplugged memory blocks virtio-mem: Better retry handling virtio-mem: Add parent resource for all added "System RAM" virtio-mem: Drop manual check for already present memory virtio-mem: Unplug subblocks right-to-left virtio-mem: Use -ETXTBSY as error code if the device is busy virtio-mem: Try to unplug the complete online memory block first virtio-mem: Don't rely on implicit compiler padding for requests Guennadi Liakhovetski (1): vhost: (cosmetic) remove a superfluous variable initialisation Jason Wang (4): vhost: allow device that does not depend on vhost worker vhost: use mmgrab() instead of mmget() for non worker device vdpa: introduce get_vq_notification method vhost_vdpa: support doorbell mapping via mmap Longpeng(Mike) (3): crypto: virtio: Fix src/dst scatterlist calculation in __virtio_crypto_skcipher_do_req() crypto: virtio: Fix use-after-free in virtio_crypto_skcipher_finalize_req() crypto: virtio: Fix dest length calculation in __virtio_crypto_skcipher_do_req() Markus Elfring (1): virtio-mmio: Delete an error message in vm_find_vqs() Matej Genci (1): virtio: add VIRTIO_RING_NO_LEGACY Michael S. Tsirkin (6): virtio: force spec specified alignment on types vhost: revert "vhost: disable for OABI" vhost_vdpa: disable doorbell mapping for !MMU virtio-mem: drop unnecessary initialization virtio_mem: convert device block size into 64bit vhost/test: fix up after API change Samuel Zou (1): vdpasim: Fix some coccinelle warnings Zhu Lingshan (5): ifcvf: move IRQ request/free to status change handlers ifcvf: ignore continuous setting same status value vhost_vdpa: Support config interrupt in vdpa vhost: replace -1 with VHOST_FILE_UNBIND in ioctls ifcvf: implement config interrupt in IFCVF MAINTAINERS| 18 +- drivers/acpi/numa/srat.c |1 + drivers/crypto/virtio/virtio_crypto_algs.c | 21 +- drivers/misc/mic/Kconfig |2 +- drivers/net/caif/Kconfig |2 +- drivers/vdpa/Kconfig |2 +- drivers/vdpa/ifcvf/ifcvf_base.c|3 + drivers/vdpa/ifcvf/ifcvf_base.h|4 + drivers/vdpa/ifcvf/ifcvf_main.c| 146 ++- drivers/vdpa/vdpa_sim/vdpa_sim.c |7 +- drivers/vhost/Kconfig | 17 +- drivers/vhost/net.c|2 +- drivers/vhost/scsi.c |2 +- drivers/vhost/test.c |2 +- drivers/vhost/vdpa.c | 112 +- drivers/vhost/vhost.c | 100 +- drivers/vhost/vhost.h |8 +- drivers/vhost/vringh.c |6 +- drivers/vhost/vsock.c |2 +- drivers/virtio/Kconfig | 17 + drivers/virtio/Makefile|1 + drivers/virtio/virtio_balloon.c|9 +- drivers/virtio/virtio_mem.c| 1965 drivers/virtio/virtio_mmio.c |4 +-
Re: [PATCH] usb/gadget/function: introduce Built-in CDROM support
On 20-06-10 10:32:29, Macpaul Lin wrote:
> Introduce Built-In CDROM (BICR) support.
> This feature depends on USB_CONFIGFS_MASS_STORAGE option.
>
> 1. Some settings and new function is introduced for BICR.
> 2. Some work around for adapting Android settings is intorduced as well.
%s/intorduced/introduced
> --- a/drivers/usb/gadget/function/f_mass_storage.c
> +++ b/drivers/usb/gadget/function/f_mass_storage.c
> @@ -315,6 +315,9 @@ struct fsg_common {
> void*private_data;
>
> char inquiry_string[INQUIRY_STRING_LEN];
> +
> + /* For build-in CDROM */
> + u8 bicr;
> };
>
> struct fsg_dev {
> @@ -369,6 +372,10 @@ static void set_bulk_out_req_length(struct fsg_common
> *common,
> if (rem > 0)
> length += common->bulk_out_maxpacket - rem;
> bh->outreq->length = length;
> +
> + /* some USB 2.0 hardware requires this setting */
> + if (IS_ENABLED(USB_CONFIGFS_BICR))
> + bh->outreq->short_not_ok = 1;
> }
Why not use fsg_common.bicr instead of MACRO?
Peter
>
>
> @@ -527,7 +534,16 @@ static int fsg_setup(struct usb_function *f,
> w_length != 1)
> return -EDOM;
> VDBG(fsg, "get max LUN\n");
> - *(u8 *)req->buf = _fsg_common_get_max_lun(fsg->common);
> + if (IS_ENABLED(USB_CONFIGFS_BICR) && fsg->common->bicr) {
> + /*
> + * When Built-In CDROM is enabled,
> + * we share only one LUN.
> + */
> + *(u8 *)req->buf = 0;
> + } else {
> + *(u8 *)req->buf = _fsg_common_get_max_lun(fsg->common);
> + }
> + INFO(fsg, "get max LUN = %d\n", *(u8 *)req->buf);
>
> /* Respond with data/status */
> req->length = min((u16)1, w_length);
> @@ -1329,7 +1345,7 @@ static int do_start_stop(struct fsg_common *common)
> }
>
> /* Are we allowed to unload the media? */
> - if (curlun->prevent_medium_removal) {
> + if (!curlun->nofua && curlun->prevent_medium_removal) {
> LDBG(curlun, "unload attempt prevented\n");
> curlun->sense_data = SS_MEDIUM_REMOVAL_PREVENTED;
> return -EINVAL;
> @@ -2692,6 +2708,7 @@ int fsg_common_set_cdev(struct fsg_common *common,
> common->ep0 = cdev->gadget->ep0;
> common->ep0req = cdev->req;
> common->cdev = cdev;
> + common->bicr = 0;
>
> us = usb_gstrings_attach(cdev, fsg_strings_array,
>ARRAY_SIZE(fsg_strings));
> @@ -2895,6 +2912,33 @@ static void fsg_common_release(struct fsg_common
> *common)
> kfree(common);
> }
>
> +#ifdef USB_CONFIGFS_BICR
> +ssize_t fsg_bicr_show(struct fsg_common *common, char *buf)
> +{
> + return sprintf(buf, "%d\n", common->bicr);
> +}
> +
> +ssize_t fsg_bicr_store(struct fsg_common *common, const char *buf, size_t
> size)
> +{
> + int ret;
> +
> + ret = kstrtou8(buf, 10, >bicr);
> + if (ret)
> + return -EINVAL;
> +
> + /* Set Lun[0] is a CDROM when enable bicr.*/
> + if (!strcmp(buf, "1"))
> + common->luns[0]->cdrom = 1;
> + else {
> + common->luns[0]->cdrom = 0;
> + common->luns[0]->blkbits = 0;
> + common->luns[0]->blksize = 0;
> + common->luns[0]->num_sectors = 0;
> + }
> +
> + return size;
> +}
> +#endif
>
> /*-*/
>
> @@ -3463,6 +3507,7 @@ void fsg_config_from_params(struct fsg_config *cfg,
> lun->ro = !!params->ro[i];
> lun->cdrom = !!params->cdrom[i];
> lun->removable = !!params->removable[i];
> + lun->nofua = !!params->nofua[i];
> lun->filename =
> params->file_count > i && params->file[i][0]
> ? params->file[i]
> diff --git a/drivers/usb/gadget/function/f_mass_storage.h
> b/drivers/usb/gadget/function/f_mass_storage.h
> index 3b8c4ce2a40a..7097e2ea5cc9 100644
> --- a/drivers/usb/gadget/function/f_mass_storage.h
> +++ b/drivers/usb/gadget/function/f_mass_storage.h
> @@ -140,5 +140,8 @@ void fsg_common_set_inquiry_string(struct fsg_common
> *common, const char *vn,
> void fsg_config_from_params(struct fsg_config *cfg,
> const struct fsg_module_parameters *params,
> unsigned int fsg_num_buffers);
> -
> +#ifdef CONFIG_USB_CONFIGFS_BICR
> +ssize_t fsg_bicr_show(struct fsg_common *common, char *buf);
> +ssize_t fsg_bicr_store(struct fsg_common *common, const char *buf, size_t
> size);
> +#endif
> #endif /* USB_F_MASS_STORAGE_H */
> diff --git a/drivers/usb/gadget/function/storage_common.c
> b/drivers/usb/gadget/function/storage_common.c
> index f7e6c42558eb..8fe96eeddf35 100644
> ---
[PATCH v2] HID: usbhid: do not sleep when opening device
usbhid tries to give the device 50 milliseconds to drain its queues when
opening the device, but dies it naively by simply sleeping in open handler,
which slows down device probing (and thus may affect overall boot time).
However we do not need to sleep as we can instead mark a point of time in
the future when we should start processing the events.
Reported-by: Nicolas Boichat
Signed-off-by: Dmitry Torokhov
---
v2: switched from using jiffies to ktime_t to make sure we won't have
issues with jiffies overflowing.
drivers/hid/usbhid/hid-core.c | 53 +++
drivers/hid/usbhid/usbhid.h | 2 ++
2 files changed, 31 insertions(+), 24 deletions(-)
diff --git a/drivers/hid/usbhid/hid-core.c b/drivers/hid/usbhid/hid-core.c
index c7bc9db5b192..72c92aab2b18 100644
--- a/drivers/hid/usbhid/hid-core.c
+++ b/drivers/hid/usbhid/hid-core.c
@@ -26,6 +26,7 @@
#include
#include
#include
+#include
#include
@@ -95,6 +96,18 @@ static int hid_start_in(struct hid_device *hid)
set_bit(HID_NO_BANDWIDTH, >iofl);
} else {
clear_bit(HID_NO_BANDWIDTH, >iofl);
+
+ if (test_bit(HID_RESUME_RUNNING, >iofl)) {
+ /*
+* In case events are generated while nobody was
+* listening, some are released when the device
+* is re-opened. Wait 50 msec for the queue to
+* empty before allowing events to go through
+* hid.
+*/
+ usbhid->input_start_time =
+ ktime_add_ms(ktime_get_coarse(), 50);
+ }
}
}
spin_unlock_irqrestore(>lock, flags);
@@ -280,20 +293,23 @@ static void hid_irq_in(struct urb *urb)
if (!test_bit(HID_OPENED, >iofl))
break;
usbhid_mark_busy(usbhid);
- if (!test_bit(HID_RESUME_RUNNING, >iofl)) {
- hid_input_report(urb->context, HID_INPUT_REPORT,
-urb->transfer_buffer,
-urb->actual_length, 1);
- /*
-* autosuspend refused while keys are pressed
-* because most keyboards don't wake up when
-* a key is released
-*/
- if (hid_check_keys_pressed(hid))
- set_bit(HID_KEYS_PRESSED, >iofl);
- else
- clear_bit(HID_KEYS_PRESSED, >iofl);
+ if (test_bit(HID_RESUME_RUNNING, >iofl)) {
+ if (ktime_before(ktime_get_coarse(),
+usbhid->input_start_time))
+ break;
+ clear_bit(HID_RESUME_RUNNING, >iofl);
}
+ hid_input_report(urb->context, HID_INPUT_REPORT,
+urb->transfer_buffer, urb->actual_length, 1);
+ /*
+* autosuspend refused while keys are pressed
+* because most keyboards don't wake up when
+* a key is released
+*/
+ if (hid_check_keys_pressed(hid))
+ set_bit(HID_KEYS_PRESSED, >iofl);
+ else
+ clear_bit(HID_KEYS_PRESSED, >iofl);
break;
case -EPIPE:/* stall */
usbhid_mark_busy(usbhid);
@@ -714,17 +730,6 @@ static int usbhid_open(struct hid_device *hid)
}
usb_autopm_put_interface(usbhid->intf);
-
- /*
-* In case events are generated while nobody was listening,
-* some are released when the device is re-opened.
-* Wait 50 msec for the queue to empty before allowing events
-* to go through hid.
-*/
- if (res == 0)
- msleep(50);
-
- clear_bit(HID_RESUME_RUNNING, >iofl);
return res;
}
diff --git a/drivers/hid/usbhid/usbhid.h b/drivers/hid/usbhid/usbhid.h
index 8620408bd7af..0f0bcf7037f8 100644
--- a/drivers/hid/usbhid/usbhid.h
+++ b/drivers/hid/usbhid/usbhid.h
@@ -13,6 +13,7 @@
#include
#include
+#include
#include
#include
#include
@@ -82,6 +83,7 @@ struct usbhid_device {
spinlock_t lock;/* fifo
spinlock */
unsigned long iofl; /* I/O
flags (CTRL_RUNNING, OUT_RUNNING) */
+ ktime_t input_start_time; /* When
to start handling input */
struct timer_list io_retry; /*
Retry timer */
unsigned long
Re: [RFC][PATCH v4 27/32] objtool: mcount: Generic location and relocation table types
On 6/9/20 11:42 PM, Matt Helsley wrote:
[...]
>> Hi Matt,
>>
>> I was trying out the patch series on ppc64le and found that __mcount_loc
>> and .rela__mcount_loc section pairs do not get generated.
>>
>> # readelf -S fs/proc/cmdline.o|grep mcount
>> #
>>
>> Debugged the cause to get_mcountsym()'s return type. It returns reloc
>> type from GELF_R_INFO() and expects Elf64_Xword a.k.a unsigned long
>> to be the return type but get_mcountsym() returns unsigned int on 64-bit.
>>
>> On power the _mcount is of relocation type R_PPC64_REL24 (info 0x17000a),
>> using unsigned int truncates the value to 0xa and fails the above check.
>> Using below fix, that converts mcount_sym_info to use unsigned long,
>> generates
>> the __mcount_loc section pairs.
>>
>> --- a/tools/objtool/mcount.c
>> +++ b/tools/objtool/mcount.c
>> @@ -163,7 +163,7 @@ static int is_mcounted_section_name(char const *const
>> txtname)
>> strcmp(".cpuidle.text", txtname) == 0;
>> }
>>
>> -static unsigned int get_mcount_sym_info(struct reloc *reloc)
>> +static unsigned long get_mcount_sym_info(struct reloc *reloc)
>> {
>> struct symbol *sym = reloc->sym;
>> char const *symname = sym->name;
>> @@ -274,7 +274,7 @@ static int nop_mcount(struct section * const rels,
>> {
>> struct reloc *reloc;
>> struct section *txts = find_section_by_index(lf, rels->sh.sh_info);
>> - unsigned int mcount_sym_info = 0;
>> + unsigned long mcount_sym_info = 0;
>> int once = 0;
>>
>> list_for_each_entry(reloc, >reloc_list, list) {
>> @@ -363,7 +363,7 @@ static void sift_rel_mcount(GElf_Addr **mlocpp,
>> {
>> GElf_Rel *mrelp = *mrelpp;
>> GElf_Rela *mrelap = *mrelpp;
>> - unsigned int mcount_sym_info = 0;
>> + unsigned long mcount_sym_info = 0;
>> struct reloc *reloc;
>>
>> list_for_each_entry(reloc, >reloc_list, list) {
>>
>> # readelf -S fs/proc/cmdline.o|grep mcount
>> [31] __mcount_loc PROGBITS 00022f10
>> [32] .rela__mcount_loc RELA 00022f20
>
> Fixed for next posting.
>
> I've essentially added this as another patch before it moves into
> recordmcount.c, gets renamed to get_mcount_sym_info(), etc. I did it
> this way because it only becomes necessary to change the type before
> moving the function (and eventually its callers) out of the wrapper.
>
> I feel I should credit you as author or at least co-author of the added
> patch since it's basically a "backported" version of the changes you
> suggested. I reviewed the process in submitting-patches.rst and propose
> the commit message:
>
> objtool: mcount: Extend mcountsym size
>
> Before we can move this function out of the wrapper and into
> wordsize-independent code we need to explicitly size the
> type returned from get_mcountsym() to preserve the symbol info.
>
> Reported-by: Kamalesh Babulal
> Signed-off-by: Kamalesh Babulal
> Signed-off-by: Matt Helsley
>
> Is that OK with you or do you have another preference?
Thanks, it works for me.
--
Kamalesh
Re: [PATCH 2/2] regulator: Add driver for cros-ec-regulator
Thanks for the review, some inline reply:
On Tue, Jun 9, 2020 at 7:19 PM Mark Brown wrote:
>
> On Tue, Jun 09, 2020 at 03:59:55PM +0800, Pi-Hsun Shih wrote:
>
> > +static int cros_ec_regulator_set_state(struct regulator_dev *dev, bool
> > enable)
> > +{
> > + struct cros_ec_regulator_data *data = rdev_get_drvdata(dev);
> > + struct ec_params_regulator_enable cmd = {
> > + .index = data->index,
> > + .enable = enable ? 1 : 0,
>
> The ternery operator is totally redundant here.
Ack, would fix in v2.
>
> > +static int cros_ec_regulator_enable(struct regulator_dev *dev)
> > +{
> > + return cros_ec_regulator_set_state(dev, true);
> > +}
>
> > +static int cros_ec_regulator_disable(struct regulator_dev *dev)
> > +{
> > + return cros_ec_regulator_set_state(dev, false);
> > +}
>
> I'm not sure that the shared function is really worthwhile though,
> there's not really enough in it and certainly not anything complicated.
Ack, would fix in v2.
>
> > +static int cros_ec_regulator_set_voltage(struct regulator_dev *dev, int
> > min_uV,
> > + int max_uV, unsigned int *selector)
> > +{
> > + struct cros_ec_regulator_data *data = rdev_get_drvdata(dev);
> > + int min_mV = DIV_ROUND_UP(min_uV, 1000);
> > + int max_mV = max_uV / 1000;
> > + struct ec_params_regulator_set_voltage cmd = {
> > + .index = data->index,
> > + .min_mv = min_mV,
> > + .max_mv = max_mV,
> > + };
> > +
> > + if (min_mV > max_mV)
> > + return -EINVAL;
>
> The core will do this for you.
Since I'm doing DIV_ROUND_UP for the min_mV, so this may happen if the
min_uV~max_uV range given by the core doesn't contain any value that
can be represented exactly in mV.
>
> > + ret = of_property_read_u32(np, "google,remote-regulator",
> > +>index);
> > + if (ret < 0)
> > + return ret;
>
> This remote-regulator property is a bit weird, it feels like it should
> be a reg property on a bus.
Ok I'll change this to reg property in v2.
>
> > +#if defined(CONFIG_OF)
> > +static const struct of_device_id regulator_cros_ec_of_match[] = {
> > + { .compatible = "regulator-cros-ec", },
> > + {},
> > +};
> > +MODULE_DEVICE_TABLE(of, regulator_cros_ec_of_match);
> > +#endif
>
> Your compatible is google,regulator-cros-ec.
Ack, would fix in v2.
[PATCH] x86/microcode: Do not select FW_LOADER
The x86 microcode support works just fine without FW_LOADER. In
fact these days most people load them early in boot so FW_LOADER
never gets into the picture anyway.
People who need the FW_LOADER capability can still enable it.
Signed-off-by: Herbert Xu
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 1d6104ea8af0..8aac7a65bfbb 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -1296,7 +1296,6 @@ config MICROCODE
bool "CPU microcode loading support"
default y
depends on CPU_SUP_AMD || CPU_SUP_INTEL
- select FW_LOADER
---help---
If you say Y here, you will be able to update the microcode on
Intel and AMD processors. The Intel support is for the IA32 family,
@@ -1318,7 +1317,6 @@ config MICROCODE_INTEL
bool "Intel microcode loading support"
depends on MICROCODE
default MICROCODE
- select FW_LOADER
---help---
This options enables microcode patch loading support for Intel
processors.
@@ -1330,7 +1328,6 @@ config MICROCODE_INTEL
config MICROCODE_AMD
bool "AMD microcode loading support"
depends on MICROCODE
- select FW_LOADER
---help---
If you select this option, microcode patch loading support for AMD
processors will be enabled.
diff --git a/arch/x86/kernel/cpu/microcode/core.c
b/arch/x86/kernel/cpu/microcode/core.c
index 7019d4b2df0c..5524ea15b3df 100644
--- a/arch/x86/kernel/cpu/microcode/core.c
+++ b/arch/x86/kernel/cpu/microcode/core.c
@@ -145,7 +145,6 @@ extern struct builtin_fw __end_builtin_fw[];
bool get_builtin_firmware(struct cpio_data *cd, const char *name)
{
-#ifdef CONFIG_FW_LOADER
struct builtin_fw *b_fw;
for (b_fw = __start_builtin_fw; b_fw != __end_builtin_fw; b_fw++) {
@@ -155,7 +154,6 @@ bool get_builtin_firmware(struct cpio_data *cd, const char
*name)
return true;
}
}
-#endif
return false;
}
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [RFC PATCH 3/5] scsi: ufs: Introduce HPB module
On 2020-06-04 18:38, Daejun Park wrote:
> + if (total_srgn_cnt != 0) {
> + dev_err(hba->dev, "ufshpb(%d) error total_subregion_count %d",
> + hpb->lun, total_srgn_cnt);
> + goto release_srgn_table;
> + }
> +
> + return 0;
> +release_srgn_table:
> + for (i = 0; i < rgn_idx; i++) {
> + rgn = rgn_table + i;
> + if (rgn->srgn_tbl)
> + kvfree(rgn->srgn_tbl);
> + }
Please insert a blank line above goto labels as is done in most of the
kernel code.
> +static struct device_attribute ufshpb_sysfs_entries[] = {
> + __ATTR(hit_count, 0444, ufshpb_sysfs_show_hit_cnt, NULL),
> + __ATTR(miss_count, 0444, ufshpb_sysfs_show_miss_cnt, NULL),
> + __ATTR(rb_noti_count, 0444, ufshpb_sysfs_show_rb_noti_cnt, NULL),
> + __ATTR(rb_active_count, 0444, ufshpb_sysfs_show_rb_active_cnt, NULL),
> + __ATTR(rb_inactive_count, 0444, ufshpb_sysfs_show_rb_inactive_cnt,
> +NULL),
> + __ATTR(map_req_count, 0444, ufshpb_sysfs_show_map_req_cnt, NULL),
> + __ATTR_NULL
> +};
Please use __ATTR_RO() where appropriate.
> +static int ufshpb_create_sysfs(struct ufs_hba *hba, struct ufshpb_lu *hpb)
> +{
> + struct device_attribute *attr;
> + int ret;
> +
> + device_initialize(>hpb_lu_dev);
> +
> + ufshpb_stat_init(hpb);
> +
> + hpb->hpb_lu_dev.parent = get_device(>ufsf.hpb_dev);
> + hpb->hpb_lu_dev.release = ufshpb_dev_release;
> + dev_set_name(>hpb_lu_dev, "ufshpb_lu%d", hpb->lun);
> +
> + ret = device_add(>hpb_lu_dev);
> + if (ret) {
> + dev_err(hba->dev, "ufshpb(%d) device_add failed",
> + hpb->lun);
> + return -ENODEV;
> + }
> +
> + for (attr = ufshpb_sysfs_entries; attr->attr.name != NULL; attr++) {
> + if (device_create_file(>hpb_lu_dev, attr))
> + dev_err(hba->dev, "ufshpb(%d) %s create file error\n",
> + hpb->lun, attr->attr.name);
> + }
> +
> + return 0;
> +}
This is the wrong way to create sysfs attributes. Please set the
'groups' member of struct device instead of using a loop to create sysfs
attributes. The former approach is compatible with udev but the latter
approach is not.
> +static void ufshpb_probe_async(void *data, async_cookie_t cookie)
> +{
> + struct ufshpb_dev_info hpb_dev_info = { 0 };
> + struct ufs_hba *hba = data;
> + char *desc_buf;
> + int ret;
> +
> + desc_buf = kzalloc(QUERY_DESC_MAX_SIZE, GFP_KERNEL);
> + if (!desc_buf)
> + goto release_desc_buf;
> +
> + ret = ufshpb_get_dev_info(hba, _dev_info, desc_buf);
> + if (ret)
> + goto release_desc_buf;
> +
> + /*
> + * Because HPB driver uses scsi_device data structure,
> + * we should wait at this point until finishing initialization of all
> + * scsi devices. Even if timeout occurs, HPB driver will search
> + * the scsi_device list on struct scsi_host (shost->__host list_head)
> + * and can find out HPB logical units in all scsi_devices
> + */
> + wait_event_timeout(hba->ufsf.sdev_wait,
> +(atomic_read(>ufsf.slave_conf_cnt)
> + == hpb_dev_info.num_lu),
> +SDEV_WAIT_TIMEOUT);
> +
> + dev_dbg(hba->dev, "ufshpb: slave count %d, lu count %d\n",
> + atomic_read(>ufsf.slave_conf_cnt), hpb_dev_info.num_lu);
> +
> + ufshpb_scan_hpb_lu(hba, _dev_info, desc_buf);
> +release_desc_buf:
> + kfree(desc_buf);
> +}
What happens if two LUNs are added before the above code is woken up?
Will that perhaps cause the wait_event_timeout() call to wait forever?
> +static int ufshpb_probe(struct device *dev)
> +{
> + struct ufs_hba *hba;
> + struct ufsf_feature_info *ufsf;
> +
> + if (dev->type != _dev_type)
> + return -ENODEV;
> +
> + ufsf = container_of(dev, struct ufsf_feature_info, hpb_dev);
> + hba = container_of(ufsf, struct ufs_hba, ufsf);
> +
> + async_schedule(ufshpb_probe_async, hba);
> + return 0;
> +}
So this is an asynchronous probe that is not visible to the device
driver core? Could the PROBE_PREFER_ASYNCHRONOUS flag have been used
instead to make device probing asynchronous?
> +static int ufshpb_remove(struct device *dev)
> +{
> + struct ufshpb_lu *hpb, *n_hpb;
> + struct ufsf_feature_info *ufsf;
> + struct scsi_device *sdev;
> +
> + ufsf = container_of(dev, struct ufsf_feature_info, hpb_dev);
> +
> + dev_set_drvdata(>hpb_dev, NULL);
> +
> + list_for_each_entry_safe(hpb, n_hpb, _drv.lh_hpb_lu,
> + list_hpb_lu) {
> + ufshpb_set_state(hpb, HPB_FAILED);
> +
> + sdev = hpb->sdev_ufs_lu;
> + sdev->hostdata = NULL;
> +
> + device_del(>hpb_lu_dev);
> +
> + dev_info(>hpb_lu_dev, "hpb_lu_dev refcnt %d\n",
> +
Re: two more fixes for sysctl
On Tue, Jun 09, 2020 at 07:08:17PM +0200, Christoph Hellwig wrote: > Hi Al, > > two more fixes for the kernel pointers in the sysctl handlers. Applied and pushed. Let me beat it up a bit, if it survives - to Linus it goes...
Re: [kbuild-all] Re: gcc-5: error: -gz is not supported in this configuration
On Tue, Jun 09, 2020 at 11:23:31PM -0400, Arvind Sankar wrote: > On Tue, Jun 09, 2020 at 11:12:25PM -0400, Arvind Sankar wrote: > > The output of gcc-5 -dumpspecs may also be useful. > > > > The exact Kconfig check should have been > > gcc-5 -Werror -gz=zlib -S -x c /dev/null -o /dev/null > > > > I can't see how that would succeed if the a.c test didn't but maybe just > > in case? > > Oh wait, -S instead of -c. Which means it runs neither the assembler nor > the linker, so gcc won't error out. But if that gcc was originally > _configured_ with a version of binutils that doesn't support -gz=zlib, > it will give an error on -c regardless of whether the runtime binutils > would actually support it or not. I think the below might be better than passing the option via -Wa, since gcc will translate -gz=zlib into the right assembler option anyway, and it will also generate an error if the compiler driver was misconfigured and won't support the option even if the rest of the toolchain does, fixing the config dependency. Unless this doesn't work with Clang? Alternatively (or even in addition), we should redefine cc-option to use -c, it uses -S in the Kconfig version, apparently for speed, but -c in the Kbuild version. diff --git a/Makefile b/Makefile index 839f9fee22cb..cb29e56f227a 100644 --- a/Makefile +++ b/Makefile @@ -842,7 +842,7 @@ endif ifdef CONFIG_DEBUG_INFO_COMPRESSED DEBUG_CFLAGS += -gz=zlib -KBUILD_AFLAGS += -Wa,--compress-debug-sections=zlib +KBUILD_AFLAGS += -gz=zlib KBUILD_LDFLAGS += --compress-debug-sections=zlib endif diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug index cb98741601bd..94ce36be470c 100644 --- a/lib/Kconfig.debug +++ b/lib/Kconfig.debug @@ -229,7 +229,7 @@ config DEBUG_INFO_COMPRESSED bool "Compressed debugging information" depends on DEBUG_INFO depends on $(cc-option,-gz=zlib) - depends on $(as-option,-Wa$(comma)--compress-debug-sections=zlib) + depends on $(as-option,-gz=zlib) depends on $(ld-option,--compress-debug-sections=zlib) help Compress the debug information using zlib. Requires GCC 5.0+ or Clang
Re: [PATCH] powerpc/pseries/svm: Fixup align argument in alloc_shared_lppaca() function
Satheesh Rajendran writes: > Argument "align" in alloc_shared_lppaca() function was unused inside the > function. Let's fix it and update code comment. > > Cc: linux-kernel@vger.kernel.org > Cc: Thiago Jung Bauermann > Cc: Ram Pai > Cc: Sukadev Bhattiprolu > Cc: Laurent Dufour > Signed-off-by: Satheesh Rajendran > --- > arch/powerpc/kernel/paca.c | 11 +-- > 1 file changed, 9 insertions(+), 2 deletions(-) Nice. I agree it's a good code cleanup. Reviewed-by: Thiago Jung Bauermann -- Thiago Jung Bauermann IBM Linux Technology Center
[RFC PATCH] PCI: Remove End-End TLP as PASID dependency
Some platform devices appear as PCI and have PCI cfg space, but are actually on the AMBA bus. They can support PASID via smmu stall feature, but does not support tlp since they are not real pci devices. So remove tlp as a PASID dependency. Signed-off-by: Zhangfei Gao --- drivers/pci/ats.c | 3 --- 1 file changed, 3 deletions(-) diff --git a/drivers/pci/ats.c b/drivers/pci/ats.c index 390e92f..8e31278 100644 --- a/drivers/pci/ats.c +++ b/drivers/pci/ats.c @@ -344,9 +344,6 @@ int pci_enable_pasid(struct pci_dev *pdev, int features) if (WARN_ON(pdev->pasid_enabled)) return -EBUSY; - if (!pdev->eetlp_prefix_path) - return -EINVAL; - if (!pasid) return -EINVAL; -- 2.7.4
Re: [RFC PATCH 2/5] scsi: ufs: Add UFS-feature layer
On 2020-06-04 18:30, Daejun Park wrote:
> +inline void ufsf_slave_configure(struct ufs_hba *hba,
> + struct scsi_device *sdev)
> +{
> + /* skip well-known LU */
> + if (sdev->lun >= UFS_UPIU_MAX_UNIT_NUM_ID)
> + return;
> +
> + if (!(hba->dev_info.b_ufs_feature_sup & UFS_FEATURE_SUPPORT_HPB_BIT))
> + return;
> +
> + atomic_inc(>ufsf.slave_conf_cnt);
> + smp_mb__after_atomic(); /* for slave_conf_cnt */
> +
> + /* waiting sdev init.*/
> + if (waitqueue_active(>ufsf.sdev_wait))
> + wake_up(>ufsf.sdev_wait);
> +}
Guarding a wake_up() call with a waitqueue_active() check is an
anti-pattern. Please don't do that and call wake_up() directly.
Additionally, wake_up() includes a barrier if it wakes up a kernel
thread so the smp_mb__after_atomic() can be left out if the
waitqueue_active() call is removed.
> +/**
> + * struct ufsf_operation - UFS feature specific callbacks
> + * @prep_fn: called after construct upiu structure
> + * @reset: called after proving hba
^^^
Is this a typo? Should "proving" perhaps be changed into "probing"?
> +struct ufshpb_driver {
> + struct device_driver drv;
> + struct list_head lh_hpb_lu;
> +
> + struct ufsf_operation ufshpb_ops;
> +
> + /* memory management */
> + struct kmem_cache *ufshpb_mctx_cache;
> + mempool_t *ufshpb_mctx_pool;
> + mempool_t *ufshpb_page_pool;
> +
> + struct workqueue_struct *ufshpb_wq;
> +};
Why is a dedicated workqueue needed? Why are the standard workqueues not
good enough?
> @@ -2525,6 +2525,8 @@ static int ufshcd_queuecommand(struct Scsi_Host *host,
> struct scsi_cmnd *cmd)
>
> ufshcd_comp_scsi_upiu(hba, lrbp);
>
> + ufsf_ops_prep_fn(hba, lrbp);
> +
> err = ufshcd_map_sg(hba, lrbp);
> if (err) {
> lrbp->cmd = NULL;
What happens if a SCSI command is retried and hence ufsf_ops_prep_fn()
is called multiple times for the same SCSI command?
Thanks,
Bart.
Re: [PATCH] powerpc/pseries/svm: Remove unwanted check for shared_lppaca_size
Satheesh Rajendran writes:
> Early secure guest boot hits the below crash while booting with
> vcpus numbers aligned with page boundary for PAGE size of 64k
> and LPPACA size of 1k i.e 64, 128 etc, due to the BUG_ON assert
> for shared_lppaca_total_size equal to shared_lppaca_size,
>
> [0.00] Partition configured for 64 cpus.
> [0.00] CPU maps initialized for 1 thread per core
> [0.00] [ cut here ]
> [0.00] kernel BUG at arch/powerpc/kernel/paca.c:89!
> [0.00] Oops: Exception in kernel mode, sig: 5 [#1]
> [0.00] LE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=2048 NUMA pSeries
>
> which is not necessary, let's remove it.
>
> Cc: linux-kernel@vger.kernel.org
> Cc: Thiago Jung Bauermann
> Cc: Ram Pai
> Cc: Sukadev Bhattiprolu
> Cc: Laurent Dufour
> Signed-off-by: Satheesh Rajendran
> ---
> arch/powerpc/kernel/paca.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Thanks for fixing this bug! I would only add:
Fixes: bd104e6db6f0 ("powerpc/pseries/svm: Use shared memory for LPPACA
structures")
In any case:
Reviewed-by: Thiago Jung Bauermann
--
Thiago Jung Bauermann
IBM Linux Technology Center
[PATCH] pinctrl: meson: fix drive strength register and bit calculation
From: Hyeonki Hong
If a GPIO bank has greater than 16 pins, PAD_DS_REG is split into two
registers. However, when register and bit were calculated, the first
register defined in the bank was used, and the bit was calculated based
on the first pin. This causes problems in setting the driving strength.
Solved the problem by changing the bit using a mask and selecting the
next register when the bit exceeds 15.
Signed-off-by: Hyeonki Hong
---
drivers/pinctrl/meson/pinctrl-meson.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/pinctrl/meson/pinctrl-meson.c
b/drivers/pinctrl/meson/pinctrl-meson.c
index bbc919bef2bf..ef66239b7df5 100644
--- a/drivers/pinctrl/meson/pinctrl-meson.c
+++ b/drivers/pinctrl/meson/pinctrl-meson.c
@@ -98,6 +98,13 @@ static void meson_calc_reg_and_bit(struct meson_bank *bank,
unsigned int pin,
*reg = desc->reg * 4;
*bit = desc->bit + pin - bank->first;
+
+ if (reg_type == REG_DS) {
+ if (*bit > 15) {
+ *bit &= 0xf;
+ *reg += 4;
+ }
+ }
}
static int meson_get_groups_count(struct pinctrl_dev *pcdev)
--
2.17.1
RE: [PATCH] PCI: ERR: Don't override the status returned by error_detect()
Hi Kuppuswamy,
Thanks a lot for your comments and sorry for my late response!
> -Original Message-
> From: Kuppuswamy, Sathyanarayanan
>
> Sent: 2020年5月29日 12:25
> To: Z.q. Hou ; linux-...@vger.kernel.org;
> linux-kernel@vger.kernel.org; rus...@russell.cc; sbobr...@linux.ibm.com;
> ooh...@gmail.com; bhelg...@google.com
> Subject: Re: [PATCH] PCI: ERR: Don't override the status returned by
> error_detect()
>
>
>
> On 5/28/20 9:04 PM, Z.q. Hou wrote:
> > Hi Kuppuswamy,
> >
> >> -Original Message-
> >> From: Kuppuswamy, Sathyanarayanan
> >>
> >> Sent: 2020年5月29日 5:19
> >> To: Z.q. Hou ; linux-...@vger.kernel.org;
> >> linux-kernel@vger.kernel.org; rus...@russell.cc;
> >> sbobr...@linux.ibm.com; ooh...@gmail.com; bhelg...@google.com
> >> Subject: Re: [PATCH] PCI: ERR: Don't override the status returned by
> >> error_detect()
> >>
> >> Hi,
> >>
> >> On 5/27/20 1:31 AM, Zhiqiang Hou wrote:
> >>> From: Hou Zhiqiang
> >>>
> >>> The commit 6d2c89441571 ("PCI/ERR: Update error status after
> >>> reset_link()") overrode the 'status' returned by the error_detect()
> >>> call back function, which is depended on by the next step. This
> >>> overriding makes the Endpoint driver's required info (kept in the
> >>> var
> >>> status) lost, so it results in the fatal errors' recovery failed and
> >>> then kernel
> >> panic.
> >> Can you explain why updating status affects the recovery ?
> >
> > Take the e1000e as an example:
> > Once a fatal error is reported by e1000e, the e1000e's error_detect()
> > will be called and it will return PCI_ERS_RESULT_NEED_RESET to request
> > a slot reset, the return value is stored in the '' of the
> > calling pci_walk_bus(bus,report_frozen_detected, ).
> > If you update the 'status' with the reset_link()'s return value
> > (PCI_ERS_RESULT_RECOVERED if the reset link succeed), then the
> > 'status' has the value PCI_ERS_RESULT_RECOVERED and e1000e's request
> > PCI_ERS_RESULT_NEED_RESET lost, then e1000e's callback function
> > .slot_reset() will be skipped and directly call the .resume().
> I believe you are working with non hotplug capable device. If yes, then this
> issue will be addressed by the following patch.
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flkml.org
> %2Flkml%2F2020%2F5%2F6%2F1545data=02%7C01%7Czhiqiang.hou%4
> 0nxp.com%7C4f0ad836e4384f40400f08d80388383c%7C686ea1d3bc2b4c6fa92
> cd99c5c301635%7C0%7C1%7C637263230875781678sdata=ap0PUMzse
> xIuCnOpBCFPW%2BrUEwMWgAYzT7yxGP8pjio%3Dreserved=0
I'll try this patch, seems it also override the 'status' in the
pci_channel_io_frozen
Case but it make sense for me.
Thanks,
Zhiqiang
> >
> > So this is how the update of 'status' break the handshake between RC's
> > AER driver and the Endpoint's protocol driver error_handlers, then result in
> the recovery failure.
> >
> >>>
> >>> In the e1000e case, the error logs:
> >>> pcieport 0002:00:00.0: AER: Uncorrected (Fatal) error received:
> >>> 0002:01:00.0 e1000e 0002:01:00.0: AER: PCIe Bus Error:
> >>> severity=Uncorrected (Fatal), type=Inaccessible, (Unregistered Agent
> >>> ID) pcieport 0002:00:00.0: AER: Root Port link has been reset
> >> As per above commit log, it looks like link is reset correctly.
> >
> > Yes, see my comments above.
> >
> > Thanks,
> > Zhiqiang
> >
> >>> SError Interrupt on CPU0, code 0xbf02 -- SError
> >>> CPU: 0 PID: 111 Comm: irq/76-aerdrv Not tainted
> >>> 5.7.0-rc7-next-20200526 #8 Hardware name: LS1046A RDB Board (DT)
> >>> pstate: 8005 (Nzcv daif -PAN -UAO BTYPE=--) pc :
> >>> __pci_enable_msix_range+0x4c8/0x5b8
> >>> lr : __pci_enable_msix_range+0x480/0x5b8
> >>> sp : 80001116bb30
> >>> x29: 80001116bb30 x28: 0003
> >>> x27: 0003 x26:
> >>> x25: 00097243e0a8 x24: 0001
> >>> x23: 00097243e2d8 x22:
> >>> x21: 0003 x20: 00095bd46080
> >>> x19: 00097243e000 x18:
> >>> x17: x16:
> >>> x15: b958fa0e9948 x14: 00095bd46303
> >>> x13: 00095bd46302 x12: 0038
> >>> x11: 0040 x10: b958fa101e68
> >>> x9 : b958fa101e60 x8 : 0908
> >>> x7 : 0908 x6 : 80001160
> >>> x5 : 00095bd46800 x4 : 00096e7f6080
> >>> x3 : x2 :
> >>> x1 : x0 : Kernel panic - not
> >>> syncing: Asynchronous SError Interrupt
> >>> CPU: 0 PID: 111 Comm: irq/76-aerdrv Not tainted
> >>> 5.7.0-rc7-next-20200526 #8
> >>>
> >>> I think it's the expected result that "if the initial value of error
> >>> status is PCI_ERS_RESULT_DISCONNECT or
> >> PCI_ERS_RESULT_NO_AER_DRIVER
> >>> then even after successful recovery (using reset_link())
> >>> pcie_do_recovery() will report the recovery result as failure" which
> >>> is described in commit 6d2c89441571 ("PCI/ERR: Update error status
> >>> after
> >> reset_link()").
> >>>
> >>> Refer to the
Re: [RFC] drivers/hwmon: Corsair Commander Pro driver
On Wed, Jun 10, 2020 at 12:26:40AM +0200, Marius Zachmann wrote: > This is a driver for the Corsair Commander Pro. > Since this is my first addition to the kernel I would be happy, if you would > take a look at it. > I am using this driver on my computer at home and I had a few people test it. > > The device: > > The Corsair Commander Pro is a USB device, which is usually connected on the > internal USB headers on the mainboard. > It has 6 fan connectors, 4 thermal sensor connectors and 2 RGB connectors. > It also reads the voltages on the SATA connector, which it needs for power. > > The driver: > > I hope hwmon is the right place. > The driver is a HID driver, but it uses usb_bulk_msg for communication. > The device registers as a HID device and there are userspace tools, which use > hidraw to access it. I think, it would be good to maintain compatibility with > these tools, but the driver can easily be rewritten to be a pure USB driver. > For now it can read temp sensors, fan speeds, voltage values and set pwm > values. > It also reads the connection status on the fan headers. > > There are a few more things, which I would like to add in the near future: > * Fan curves (not yet sure about the nicest way to provide sysfs access) > * Force 3pin or 4pin mode. (Sometimes the device doesn't detect the fans > correctly) > * Setting fixed RPM > > I do not work for Corsair and I intend to keep the driver maintainted as long > as I use the device privately. > The above should be limited to the driver description. Discussion should be below the '---'. Either case, make sure to split your lines. > Signed-off-by: Marius Zachmann > --- > Documentation/hwmon/corsair-cpro.rst | 42 +++ Needs to be added to Documentation/hwmon/index.rst. > MAINTAINERS | 6 + > drivers/hwmon/Kconfig| 10 + > drivers/hwmon/Makefile | 1 + > drivers/hwmon/corsair-cpro.c | 481 +++ > 5 files changed, 540 insertions(+) > create mode 100644 Documentation/hwmon/corsair-cpro.rst > create mode 100644 drivers/hwmon/corsair-cpro.c > > diff --git a/Documentation/hwmon/corsair-cpro.rst > b/Documentation/hwmon/corsair-cpro.rst > new file mode 100644 > index ..d4ea1b6b9336 > --- /dev/null > +++ b/Documentation/hwmon/corsair-cpro.rst > @@ -0,0 +1,42 @@ > +Kernel driver corsair-cpro > +== > + > +Supported devices: > + > + * Corsair Commander Pro > + * Corsair Commander Pro (1000D) > + > +Author: Marius Zachmann > + > +Description > +--- > + > +This driver implements the sysfs interface for the Corsair Commander Pro. > +The Corsair Commander Pro is a USB device with 6 fan connectors, > +4 temperature sensor connectors and 2 Corsair LED connectors. > +It can read the voltage levels on the SATA power connector. > + > +Usage Notes > +--- > + > +Since it is a USB device, hotswapping is possible. The device is > autodetected. > + > +Sysfs entries > +- > + > +in0_inputVoltage on SATA 12v > +in1_inputVoltage on SATA 5v > +in2_inputVoltage on SATA 3.3v > + > +temp[0-3]_input Connected temperature sensors > + Index starts with 1 for everything except inX. > +fan[0-5]_input Connected fan rpm. > +fan[0-5]_label Shows connection status of the fan as detected > by the > + device. > + "fanX nc" no connection > + "fanX 3pin" 3-pin fan detected > + "fanX 4pin" 4-pin fan detected > +fan[0-5]_enable the driver only reports fan speeds when 1 > +pwm[0-5] Sets the fan speed. Values from 0-255. > + When reading, it reports the last value, which > + was set by the driver. > diff --git a/MAINTAINERS b/MAINTAINERS > index f08f290df174..169530c7eede 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -4386,6 +4386,12 @@ S: Maintained > F: Documentation/hwmon/coretemp.rst > F: drivers/hwmon/coretemp.c > > +CORSAIR-CPRO HARDWARE MONITOR DRIVER > +M: Marius Zachmann > +L: linux-hw...@vger.kernel.org > +S: Maintained > +F: drivers/hwmon/corsair-cpro.c > + > COSA/SRP SYNC SERIAL DRIVER > M: Jan "Yenya" Kasprzak > S: Maintained > diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig > index 288ae9f63588..9f5a808768ca 100644 > --- a/drivers/hwmon/Kconfig > +++ b/drivers/hwmon/Kconfig > @@ -439,6 +439,16 @@ config SENSORS_BT1_PVT_ALARMS > the data conversion will be periodically performed and the data will > be > saved in the internal driver cache. > > +config SENSORS_CORSAIR_CPRO > + tristate "Corsair Commander Pro controller" > + depends on USB_HID > + help > + If you say yes here you get support for the Corsair Commander Pro > + controller. > + > + This driver can also be built as a module. If so,
Re: linux-next: build failure after merge of the akpm-current tree
On Wed, 10 Jun 2020 13:44:25 +1000 Stephen Rothwell
wrote:
> Hi all,
>
> On Tue, 9 Jun 2020 22:42:52 +1000 Stephen Rothwell
> wrote:
> >
> > After merging the akpm-current tree, today's linux-next build (sparc
> > defconfig) failed like this:
> >
> > In file included from include/linux/mm.h:32:0,
> > from include/linux/memblock.h:13,
> > from arch/sparc/mm/srmmu.c:14:
> > include/linux/pgtable.h:74:27: error: redefinition of 'pte_offset_kernel'
> > #define pte_offset_kernel pte_offset_kernel
> >^
> > arch/sparc/mm/srmmu.c:144:8: note: in expansion of macro 'pte_offset_kernel'
> > pte_t *pte_offset_kernel(pmd_t *dir, unsigned long address)
> > ^
> > include/linux/pgtable.h:70:22: note: previous definition of
> > 'pte_offset_kernel' was here
> > static inline pte_t *pte_offset_kernel(pmd_t *pmd, unsigned long address)
> > ^
> >
> > Caused by commit
> >
> > 292aa65ed13a ("mm: consolidate pte_index() and pte_offset_*()
> > definitions")
>
> This breakage is now in Linus' tree :-(
I've sent this in as well:
From: Andrew Morton
Subject: arch/sparc/mm/srmmu.c: fix build
"mm: consolidate pte_index() and pte_offset_*() definitions" was supposed
to remove arch/sparc/mm/srmmu.c:pte_offset_kernel().
Fixes: 974b9b2c68f3d35 ("mm: consolidate pte_index() and pte_offset_*()
definitions")
Reported-by: kernel test robot
Cc: Mike Rapoport
Cc: Johannes Weiner
Signed-off-by: Andrew Morton
---
arch/sparc/mm/srmmu.c | 10 --
1 file changed, 10 deletions(-)
--- a/arch/sparc/mm/srmmu.c~arch-sparc-mm-srmmuc-fix-build
+++ a/arch/sparc/mm/srmmu.c
@@ -140,16 +140,6 @@ void pmd_set(pmd_t *pmdp, pte_t *ptep)
set_pte((pte_t *)_val(*pmdp), __pte(SRMMU_ET_PTD | ptp));
}
-/* Find an entry in the third-level page table.. */
-pte_t *pte_offset_kernel(pmd_t *dir, unsigned long address)
-{
- void *pte;
-
- pte = __nocache_va((pmd_val(*dir) & SRMMU_PTD_PMASK) << 4);
- return (pte_t *) pte +
- ((address >> PAGE_SHIFT) & (PTRS_PER_PTE - 1));
-}
-
/*
* size: bytes to allocate in the nocache area.
* align: bytes, number to align at.
_
RE: [RFC PATCH 4/5] scsi: ufs: L2P map management for HPB read
> The spec does not define what the host should do in this case, > e.g. when the device informs it that the entire db is no longer valid. > What are you planning to do? In Jedec spec, there is no decription about what the driver should do. So, I will just inform to user about the "HPB reset" happening with kernel message. Thanks, Daejun
[PATCH V2] vdpa: introduce virtio pci driver
This patch introduce a vDPA driver for virtio-pci device. It bridges
the virtio-pci control command to the vDPA bus. This will be used for
developing new features for both software vDPA framework and hardware
vDPA feature.
Compared to vdpa_sim, it has several advantages:
- it's a real device driver which allow us to play with real hardware
features
- type independent instead of networking specific
Note that since virtio specification does not support get/restore
virtqueue state. So we can not use this driver for VM. This can be
addressed by extending the virtio specification.
Consider the driver is mainly for testing and development for vDPA
features, it can only be bound via dynamic ids to make sure it's not
conflict with the drivers like virtio-pci or IFCVF.
Signed-off-by: Jason Wang
---
Changes since V1:
- use NULL id_table to allow dynamic ids only
- squash the doorbell reporting
---
drivers/vdpa/Kconfig | 8 +
drivers/vdpa/Makefile | 1 +
drivers/vdpa/vp_vdpa/Makefile | 2 +
drivers/vdpa/vp_vdpa/vp_vdpa.c | 601 +
4 files changed, 612 insertions(+)
create mode 100644 drivers/vdpa/vp_vdpa/Makefile
create mode 100644 drivers/vdpa/vp_vdpa/vp_vdpa.c
diff --git a/drivers/vdpa/Kconfig b/drivers/vdpa/Kconfig
index e8140065c8a5..5cef3a4872e3 100644
--- a/drivers/vdpa/Kconfig
+++ b/drivers/vdpa/Kconfig
@@ -28,4 +28,12 @@ config IFCVF
To compile this driver as a module, choose M here: the module will
be called ifcvf.
+config VP_VDPA
+ tristate "Virtio PCI bridge vDPA driver"
+ depends on PCI_MSI
+ help
+ This kernel module that bridges virtio PCI device to vDPA
+ bus. It allows us to test and develop vDPA subsystem inside
+ an VM with the emulated virtio-pci device
+
endif # VDPA
diff --git a/drivers/vdpa/Makefile b/drivers/vdpa/Makefile
index 8bbb686ca7a2..37d00f49b3bf 100644
--- a/drivers/vdpa/Makefile
+++ b/drivers/vdpa/Makefile
@@ -2,3 +2,4 @@
obj-$(CONFIG_VDPA) += vdpa.o
obj-$(CONFIG_VDPA_SIM) += vdpa_sim/
obj-$(CONFIG_IFCVF)+= ifcvf/
+obj-$(CONFIG_VP_VDPA)+= vp_vdpa/
diff --git a/drivers/vdpa/vp_vdpa/Makefile b/drivers/vdpa/vp_vdpa/Makefile
new file mode 100644
index ..231088d3af7d
--- /dev/null
+++ b/drivers/vdpa/vp_vdpa/Makefile
@@ -0,0 +1,2 @@
+# SPDX-License-Identifier: GPL-2.0
+obj-$(CONFIG_VP_VDPA) += vp_vdpa.o
diff --git a/drivers/vdpa/vp_vdpa/vp_vdpa.c b/drivers/vdpa/vp_vdpa/vp_vdpa.c
new file mode 100644
index ..2070298ab9fc
--- /dev/null
+++ b/drivers/vdpa/vp_vdpa/vp_vdpa.c
@@ -0,0 +1,601 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * vDPA bridge driver for modern virtio-pci device
+ *
+ * Copyright (c) 2020, Red Hat Inc. All rights reserved.
+ * Author: Jason Wang
+ *
+ * Based on virtio_pci_modern.c.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+/* TBD: read from config space */
+#define VP_VDPA_MAX_QUEUE 2
+#define VP_VDPA_DRIVER_NAME "vp_vdpa"
+
+#define VP_VDPA_FEATURES \
+ ((1ULL << VIRTIO_F_ANY_LAYOUT) | \
+(1ULL << VIRTIO_F_VERSION_1) | \
+(1ULL << VIRTIO_F_ORDER_PLATFORM) | \
+(1ULL << VIRTIO_F_IOMMU_PLATFORM))
+
+struct vp_vring {
+ void __iomem *notify;
+ char msix_name[256];
+ resource_size_t notify_pa;
+ struct vdpa_callback cb;
+ int irq;
+};
+
+struct vp_vdpa {
+ struct vdpa_device vdpa;
+ struct pci_dev *pdev;
+
+ struct virtio_device_id id;
+
+ struct vp_vring vring[VP_VDPA_MAX_QUEUE];
+
+ /* The IO mapping for the PCI config space */
+ void __iomem * const *base;
+ struct virtio_pci_common_cfg __iomem *common;
+ void __iomem *device;
+ /* Base of vq notifications */
+ void __iomem *notify;
+
+ /* Multiplier for queue_notify_off. */
+ u32 notify_off_multiplier;
+
+ int modern_bars;
+ int vectors;
+};
+
+static struct vp_vdpa *vdpa_to_vp(struct vdpa_device *vdpa)
+{
+ return container_of(vdpa, struct vp_vdpa, vdpa);
+}
+
+/*
+ * Type-safe wrappers for io accesses.
+ * Use these to enforce at compile time the following spec requirement:
+ *
+ * The driver MUST access each field using the ???natural??? access
+ * method, i.e. 32-bit accesses for 32-bit fields, 16-bit accesses
+ * for 16-bit fields and 8-bit accesses for 8-bit fields.
+ */
+static inline u8 vp_ioread8(u8 __iomem *addr)
+{
+ return ioread8(addr);
+}
+static inline u16 vp_ioread16(__le16 __iomem *addr)
+{
+ return ioread16(addr);
+}
+
+static inline u32 vp_ioread32(__le32 __iomem *addr)
+{
+ return ioread32(addr);
+}
+
+static inline void vp_iowrite8(u8 value, u8 __iomem *addr)
+{
+ iowrite8(value, addr);
+}
+
+static inline void vp_iowrite16(u16 value, __le16 __iomem *addr)
+{
+ iowrite16(value, addr);
+}
+
+static inline void vp_iowrite32(u32 value, __le32 __iomem
Re: [f2fs-dev] [PATCH] f2fs: add F2FS_IOC_SEC_TRIM_FILE ioctl
> > > > To prevent the file data from garbage collecting, the user needs to > > use pinfile ioctl and fallocate system call after creating the file. > > The sequence is like below. > > 1. create an empty file > > 2. pinfile > > 3. fallocate() > > Is that persistent? So the file will never be moved afterwards? > > Is there a place where this is (or should be) documented? Yes, this is persistent. F2FS_IOC_SET_PIN_FILE ioctl is to prevent file data from moving and being garbage collected, and further update to the file will be handled in in-place update manner. I don't see any document on this, but you can find the below in Documentation/filesystems/f2fs.rst However, once F2FS receives ioctl(fd, F2FS_IOC_SET_PIN_FILE) in prior to fallocate(fd, DEFAULT_MODE), it allocates on-disk blocks addresses having zero or random data, which is useful to the below scenario where: 1. create(fd) 2. ioctl(fd, F2FS_IOC_SET_PIN_FILE) 3. fallocate(fd, 0, 0, size) 4. address = fibmap(fd, offset) 5. open(blkdev) 6. write(blkdev, address) > Right, the freezing check is actually still necessary. But getting write > access > to the mount is not necessary. I think you should use file_start_write() and > file_end_write(), like vfs_write() does. Yes, agreed. 2020년 6월 10일 (수) 오후 12:15, Eric Biggers 님이 작성: > > On Wed, Jun 10, 2020 at 11:05:46AM +0900, Daeho Jeong wrote: > > > > Added a new ioctl to send discard commands or/and zero out > > > > to whole data area of a regular file for security reason. > > > > > > With this ioctl available, what is the exact procedure to write and then > > > later > > > securely erase a file on f2fs? In particular, how can the user prevent > > > f2fs > > > from making multiple copies of file data blocks as part of garbage > > > collection? > > > > > > > To prevent the file data from garbage collecting, the user needs to > > use pinfile ioctl and fallocate system call after creating the file. > > The sequence is like below. > > 1. create an empty file > > 2. pinfile > > 3. fallocate() > > Is that persistent? So the file will never be moved afterwards? > > Is there a place where this is (or should be) documented? > > > > > + > > > > + if (f2fs_readonly(sbi->sb)) > > > > + return -EROFS; > > > > > > Isn't this redundant with mnt_want_write_file()? > > > > > > Also, shouldn't write access to the file be required, i.e. > > > (filp->f_mode & FMODE_WRITE)? Then the f2fs_readonly() and > > > mnt_want_write_file() checks would be unnecessary. > > > > > > > Using FMODE_WRITE is more proper for this case, since we're going to > > modify the data. But I think mnt_want_write_file() is still required > > to prevent the filesystem from freezing or something else. > > Right, the freezing check is actually still necessary. But getting write > access > to the mount is not necessary. I think you should use file_start_write() and > file_end_write(), like vfs_write() does. > > > > > > > > + > > > > + if (get_user(flags, (u32 __user *)arg)) > > > > + return -EFAULT; > > > > + if (!(flags & F2FS_TRIM_FILE_MASK)) > > > > + return -EINVAL; > > > > > > Need to reject unknown flags: > > > > > > if (flags & ~F2FS_TRIM_FILE_MASK) > > > return -EINVAL; > > > > I needed a different thing here. This was to check neither discard nor > > zeroing out are not here. But we still need to check unknown flags, > > too. > > The below might be better. > > if (!flags || flags & ~F2FS_TRIM_FILE_MASK) > >return -EINVAL; > > Sure, but please put parentheses around the second clause: > > if (flags == 0 || (flags & ~F2FS_TRIM_FILE_MASK)) > return -EINVAL; > > - Eric
Re: [LKP] [xfs] a5949d3fae: aim7.jobs-per-min -33.6% regression
Hi Darrick,
Do you have time to take a look at this? Thanks.
On 6/6/2020 11:48 PM, kernel test robot wrote:
Greeting,
FYI, we noticed a -33.6% regression of aim7.jobs-per-min due to commit:
commit: a5949d3faedf492fa7863b914da408047ab46eb0 ("xfs: force writes to delalloc
regions to unwritten")
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git master
in testcase: aim7
on test machine: 48 threads Intel(R) Xeon(R) CPU E5-2697 v2 @ 2.70GHz with 64G
memory
with following parameters:
disk: 1BRD_48G
fs: xfs
test: sync_disk_rw
load: 600
cpufreq_governor: performance
ucode: 0x42e
test-description: AIM7 is a traditional UNIX system level benchmark suite which
is used to test and measure the performance of multiuser system.
test-url: https://sourceforge.net/projects/aimbench/files/aim-suite7/
If you fix the issue, kindly add following tag
Reported-by: kernel test robot
Details are as below:
-->
To reproduce:
git clone https://github.com/intel/lkp-tests.git
cd lkp-tests
bin/lkp install job.yaml # job file is attached in this email
bin/lkp run job.yaml
=
compiler/cpufreq_governor/disk/fs/kconfig/load/rootfs/tbox_group/test/testcase/ucode:
gcc-9/performance/1BRD_48G/xfs/x86_64-rhel-7.6/600/debian-x86_64-20191114.cgz/lkp-ivb-2ep1/sync_disk_rw/aim7/0x42e
commit:
590b16516e ("xfs: refactor xfs_iomap_prealloc_size")
a5949d3fae ("xfs: force writes to delalloc regions to unwritten")
590b16516ef38e2e a5949d3faedf492fa7863b914da
---
fail:runs %reproductionfail:runs
| | |
:4 50% 2:4
dmesg.WARNING:at#for_ip_swapgs_restore_regs_and_return_to_usermode/0x
%stddev %change %stddev
\ |\
35272 -33.6% 23430aim7.jobs-per-min
102.13 +50.5% 153.75aim7.time.elapsed_time
102.13 +50.5% 153.75aim7.time.elapsed_time.max
1388038 +40.2%1945838
aim7.time.involuntary_context_switches
43420 ± 2% +13.4% 49255 ± 2% aim7.time.minor_page_faults
3123 +44.2% 4504 ± 2% aim7.time.system_time
59.31+6.5% 63.18aim7.time.user_time
48595108 +58.6% 77064959
aim7.time.voluntary_context_switches
1.44 -28.8% 1.02iostat.cpu.user
0.07 ± 6% +0.40.44 ± 7% mpstat.cpu.all.iowait%
1.44-0.41.02mpstat.cpu.all.usr%
8632 ± 50% +75.6% 15156 ± 34% numa-meminfo.node0.KernelStack
6583 ±136%+106.0% 13562 ± 82% numa-meminfo.node0.PageTables
63325 ± 11% +14.3% 72352 ± 12% numa-meminfo.node0.SUnreclaim
8647 ± 50% +75.3% 15156 ± 34% numa-vmstat.node0.nr_kernel_stack
1656 ±136%+104.6% 3389 ± 82%
numa-vmstat.node0.nr_page_table_pages
15831 ± 11% +14.3% 18087 ± 12%
numa-vmstat.node0.nr_slab_unreclaimable
93640 ± 3% +41.2% 132211 ± 2% meminfo.AnonHugePages
21641 +39.9% 30271 ± 4% meminfo.KernelStack
129269 +12.3% 145114meminfo.SUnreclaim
28000 -31.2% 19275meminfo.max_used_kB
1269307 -26.9% 927657vmstat.io.bo
149.75 ± 3% -17.4% 123.75 ± 4% vmstat.procs.r
718992 +13.3% 814567vmstat.system.cs
231397-9.3% 209881 ± 2% vmstat.system.in
6.774e+08 +70.0% 1.152e+09cpuidle.C1.time
18203372 +60.4% 29198744cpuidle.C1.usage
2.569e+08 ± 18% +81.8% 4.672e+08 ± 5% cpuidle.C1E.time
2691402 ± 13% +98.7%5346901 ± 3% cpuidle.C1E.usage
990350 +95.0%1931226 ± 2% cpuidle.POLL.time
520061 +97.7%1028004 ± 2% cpuidle.POLL.usage
77231+1.8% 78602proc-vmstat.nr_active_anon
19868+3.8% 20615proc-vmstat.nr_dirty
381302+1.0% 384969proc-vmstat.nr_file_pages
4388-2.7% 4270proc-vmstat.nr_inactive_anon
69865+4.7% 73155proc-vmstat.nr_inactive_file
21615 +40.0% 30251 ± 4% proc-vmstat.nr_kernel_stack
7363-3.2% 7127proc-vmstat.nr_mapped
12595 ± 3% +5.2% 13255 ± 4% proc-vmstat.nr_shmem
19619+3.2% 20247proc-vmstat.nr_slab_reclaimable
32316 +12.3% 36280
RE: RE: [RFC PATCH 4/5] scsi: ufs: L2P map management for HPB read
> This is not a concern, just a question. > If a map request started while runtime/system suspend, can you share its flow? When suspended, the worker is cancled. And it can just process pending active/inactive list after resume. Thanks, Daejun
Re: [PATCH v2 08/12] mm/migrate: change the interface of the migration target alloc/free functions
2020년 6월 9일 (화) 오후 11:04, Michal Hocko 님이 작성: > > On Wed 27-05-20 15:44:59, Joonsoo Kim wrote: > > From: Joonsoo Kim > > > > To prepare unifying duplicated functions in following patches, this patch > > changes the interface of the migration target alloc/free functions. > > Functions now use struct alloc_control as an argument. > > It also pulls private argument into alloc_control and keeps it that way. > Wouldn't it be better to use explicit types and names in a union? Each > allocation callback has to understant the meaning anyway. I would > consider the resulting code cleaner that way. What do you think? Your suggestion sounds reasonable. Thanks. My plan is that, as Vlastimil suggested, I will keep the private argument in migration callback and use the appropriate private argument by the allocation caller. There will be no private field on alloc_control. Thanks.
Re: linux-next: build failure after merge of the akpm-current tree
Hi all,
On Tue, 9 Jun 2020 22:42:52 +1000 Stephen Rothwell
wrote:
>
> After merging the akpm-current tree, today's linux-next build (sparc
> defconfig) failed like this:
>
> In file included from include/linux/mm.h:32:0,
> from include/linux/memblock.h:13,
> from arch/sparc/mm/srmmu.c:14:
> include/linux/pgtable.h:74:27: error: redefinition of 'pte_offset_kernel'
> #define pte_offset_kernel pte_offset_kernel
>^
> arch/sparc/mm/srmmu.c:144:8: note: in expansion of macro 'pte_offset_kernel'
> pte_t *pte_offset_kernel(pmd_t *dir, unsigned long address)
> ^
> include/linux/pgtable.h:70:22: note: previous definition of
> 'pte_offset_kernel' was here
> static inline pte_t *pte_offset_kernel(pmd_t *pmd, unsigned long address)
> ^
>
> Caused by commit
>
> 292aa65ed13a ("mm: consolidate pte_index() and pte_offset_*() definitions")
This breakage is now in Linus' tree :-(
--
Cheers,
Stephen Rothwell
pgp0vemaS42R5.pgp
Description: OpenPGP digital signature
[PATCH] Fix null pointer dereference in vector_user_bpf
Signed-off-by: Gaurav Singh
The bpf_prog is being checked for !NULL after uml_kmalloc but
later its used directly for example:
bpf_prog->filter = bpf and is also later returned upon success.
Fix this, do a NULL check and return right away.
---
arch/um/drivers/vector_user.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/arch/um/drivers/vector_user.c b/arch/um/drivers/vector_user.c
index aa28e9eecb7b..71d043ae306f 100644
--- a/arch/um/drivers/vector_user.c
+++ b/arch/um/drivers/vector_user.c
@@ -730,10 +730,12 @@ void *uml_vector_user_bpf(char *filename)
return false;
}
bpf_prog = uml_kmalloc(sizeof(struct sock_fprog), UM_GFP_KERNEL);
- if (bpf_prog != NULL) {
- bpf_prog->len = statbuf.st_size / sizeof(struct sock_filter);
- bpf_prog->filter = NULL;
+ if (bpf_prog == NULL) {
+ printk(KERN_ERR "Failed to allocate bpf prog buffer");
+ return NULL;
}
+ bpf_prog->len = statbuf.st_size / sizeof(struct sock_filter);
+ bpf_prog->filter = NULL;
ffd = os_open_file(filename, of_read(OPENFLAGS()), 0);
if (ffd < 0) {
printk(KERN_ERR "Error %d opening bpf file", -errno);
--
2.17.1
Re: [PATCH] Do not assign in if condition wg_noise_handshake_consume_initiation()
On Tue, Jun 9, 2020 at 9:21 AM Frank Werner-Krippendorf wrote: > > Fixes an error condition reported by checkpatch.pl which caused by > assigning a variable in an if condition in > wg_noise_handshake_consume_initiation(). > > Signed-off-by: Frank Werner-Krippendorf Thanks. Queued up in the wireguard-linux.git tree. Jason
Re: [EXT] [PATCH v2 1/5] scsi: ufs: Allow UFS 3.0 as a valid version
Hi Jose On Thu, Apr 30, 2020 at 1:44 PM Jose Abreu wrote: > > From: Bean Huo (beanhuo) > Date: Apr/29/2020, 13:59:08 (UTC+00:00) > > > Probably. I think we can leave them or change the dev_err to a dev_warn. > > > This way we have logs in case someone is using a non-supported version. > > > > > > What do you think ? > > > > > Hi, Jose > > Seems after your patch, all of current released UFS control versions will > > be supported except the > > version suffix is non-zero. Right? > > I think we cover all versions with this patch. > Are you still on this? > --- > Thanks, > Jose Miguel Abreu -- Regards, Alim
Re: [PATCH] scsi: ufs: Bump supported UFS HCI version to 3.0
HI Manivannan
On Thu, Jun 4, 2020 at 12:08 PM Manivannan Sadhasivam
wrote:
>
> UFS HCI 3.0 versions are being used in Qcom SM8250 based boards. Hence,
> adding it to the list of supported versions.
>
> I don't have the exact information of the additional registers supported
> in version 3.0. Hence the change just adds 0x300 to the list of supported
> versions to remove the below warning:
>
> "ufshcd-qcom 1d84000.ufshc: invalid UFS version 0x300"
>
> Signed-off-by: Manivannan Sadhasivam
> ---
> drivers/scsi/ufs/ufshci.h | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/scsi/ufs/ufshci.h b/drivers/scsi/ufs/ufshci.h
> index c2961d37cc1c..f2ee81669b00 100644
> --- a/drivers/scsi/ufs/ufshci.h
> +++ b/drivers/scsi/ufs/ufshci.h
> @@ -104,6 +104,7 @@ enum {
> UFSHCI_VERSION_11 = 0x00010100, /* 1.1 */
> UFSHCI_VERSION_20 = 0x0200, /* 2.0 */
> UFSHCI_VERSION_21 = 0x0210, /* 2.1 */
> + UFSHCI_VERSION_30 = 0x0300, /* 3.0 */
See the current discussion on this https://lkml.org/lkml/2020/4/27/192
> };
>
> /*
> --
> 2.17.1
>
--
Regards,
Alim
Re: [PATCH v2 06/12] mm/hugetlb: make hugetlb migration target allocation APIs CMA aware
2020년 6월 9일 (화) 오후 10:53, Michal Hocko 님이 작성: > > On Wed 27-05-20 15:44:57, Joonsoo Kim wrote: > > From: Joonsoo Kim > > > > There is a user who do not want to use CMA memory for migration. Until > > now, it is implemented by caller side but it's not optimal since there > > is limited information on caller. This patch implements it on callee side > > to get better result. > > I do not follow this changelog and honestly do not see an improvement. > skip_cma in the alloc_control sound like a hack to me. I can now see new_non_cma_page() want to allocate the new page that is not on the CMA area. new_non_cma_page() implements it by not specifying __GFP_MOVALBE mask or removing this mask. hugetlb page allocation has two steps. First is dequeing from the pool. And, if there is no available page on the pool, allocating from the page allocator. new_non_cma_page() can control allocating from the page allocator in hugetlb via the gfp flags. However, dequeing cannot be controlled by this way so it skips dequeing completely. This is why new_non_cma_page() uses alloc_migrate_huge_page() instead of alloc_huge_page_nodemask(). My patch makes hugetlb code CMA aware so that new_non_cma_page() can get the benefit of the hugetlb pool. > why your earlier patch has started to or the given gfp_mask. If anything > this should be folded here. But even then I do not like a partial > gfp_mask (__GFP_NOWARN on its own really has GFP_NOWAIT like semantic). Will not use partial gfp_mask. Thanks.
Re: [LKP] [ima] 8eb613c0b8: stress-ng.icache.ops_per_sec -84.2% regression
Hi Mimi,
Do you have time to take a look at this? we noticed a 3.7%
regression of boot-time.dhcp and a 84.2% regression of
stress-ng.icache.ops_per_sec. Thanks.
On 6/3/2020 5:11 PM, kernel test robot wrote:
Greeting,
FYI, we noticed a 3.7% regression of boot-time.dhcp due to commit:
commit: 8eb613c0b8f19627ba1846dcf78bb2c85edbe8dd ("ima: verify mprotect change is
consistent with mmap policy")
https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git master
in testcase: stress-ng
on test machine: 96 threads Intel(R) Xeon(R) Gold 6252 CPU @ 2.10GHz with 192G
memory
with following parameters:
nr_threads: 100%
disk: 1HDD
testtime: 30s
class: cpu-cache
cpufreq_governor: performance
ucode: 0x52c
If you fix the issue, kindly add following tag
Reported-by: kernel test robot
Details are as below:
-->
To reproduce:
git clone https://github.com/intel/lkp-tests.git
cd lkp-tests
bin/lkp install job.yaml # job file is attached in this email
bin/lkp run job.yaml
=
class/compiler/cpufreq_governor/disk/kconfig/nr_threads/rootfs/tbox_group/testcase/testtime/ucode:
cpu-cache/gcc-9/performance/1HDD/x86_64-rhel-7.6/100%/debian-x86_64-20191114.cgz/lkp-csl-2sp5/stress-ng/30s/0x52c
commit:
0c4395fb2a ("evm: Fix possible memory leak in evm_calc_hmac_or_hash()")
8eb613c0b8 ("ima: verify mprotect change is consistent with mmap policy")
0c4395fb2aa77341 8eb613c0b8f19627ba1846dcf78
---
fail:runs %reproductionfail:runs
| | |
:4 25% 1:4
dmesg.WARNING:at#for_ip_interrupt_entry/0x
0:43% 0:4
perf-profile.children.cycles-pp.error_entry
%stddev %change %stddev
\ |\
1245570 -84.2% 197151stress-ng.icache.ops
41517 -84.2% 6570stress-ng.icache.ops_per_sec
1.306e+09 -82.1% 2.338e+08stress-ng.time.minor_page_faults
2985 +13.5% 3387stress-ng.time.system_time
4.28 +13.1% 4.85iostat.cpu.system
4.18+0.64.73mpstat.cpu.all.sys%
10121+9.6% 11096 ± 3% softirqs.CPU67.SCHED
203299-4.2% 194854 ± 5% vmstat.system.in
26.91+2.8% 27.67 ± 3% boot-time.boot
16.34+3.7% 16.94 ± 2% boot-time.dhcp
2183 ± 3% +3.7% 2263boot-time.idle
1042938 ± 80% +8208.2% 86649242 ±156% cpuidle.C1.time
48428 ±114% +1842.4% 940677 ±151% cpuidle.C1.usage
15748 ± 28%+301.0% 63144 ± 79% cpuidle.POLL.usage
61300 ± 4% +82.8% 112033 ± 11% numa-vmstat.node1.nr_active_anon
47060 ± 3%+106.8% 97323 ± 12% numa-vmstat.node1.nr_anon_pages
42.67 ± 2%+217.0% 135.25 ± 14%
numa-vmstat.node1.nr_anon_transparent_hugepages
61301 ± 4% +82.8% 112032 ± 11%
numa-vmstat.node1.nr_zone_active_anon
3816 ± 2% +3.0% 3931proc-vmstat.nr_page_table_pages
35216541+2.9% 36244047proc-vmstat.pgalloc_normal
1.308e+09 -82.0% 2.356e+08proc-vmstat.pgfault
35173363+2.8% 36173843proc-vmstat.pgfree
248171 ± 5% +82.5% 452893 ± 11% numa-meminfo.node1.Active
244812 ± 4% +83.5% 449116 ± 11% numa-meminfo.node1.Active(anon)
88290 ± 3%+214.4% 277591 ± 15% numa-meminfo.node1.AnonHugePages
187940 ± 3%+107.8% 390486 ± 12% numa-meminfo.node1.AnonPages
1366813 ± 3% +12.0%1530428 ± 6% numa-meminfo.node1.MemUsed
571.00 ± 8% +10.4% 630.50 ± 8% slabinfo.UDP.active_objs
571.00 ± 8% +10.4% 630.50 ± 8% slabinfo.UDP.num_objs
300.00 ± 5% +20.0% 360.00 ± 10% slabinfo.kmem_cache.active_objs
300.00 ± 5% +20.0% 360.00 ± 10% slabinfo.kmem_cache.num_objs
606.33 ± 4% +17.6% 713.00 ± 8%
slabinfo.kmem_cache_node.active_objs
661.33 ± 4% +16.1% 768.00 ± 8% slabinfo.kmem_cache_node.num_objs
114561 ± 23% -34.3% 75239 ± 7% sched_debug.cfs_rq:/.load.max
14869 ± 22% -36.6% 9424 ± 8% sched_debug.cfs_rq:/.load.stddev
4040842 ± 5% +18.0%4767515 ± 13% sched_debug.cpu.avg_idle.max
2019061 ± 8% +25.5%2534134 ± 14%
sched_debug.cpu.max_idle_balance_cost.max
378044 ± 3% +22.5% 463135 ± 8%
sched_debug.cpu.max_idle_balance_cost.stddev
41605 +12.6% 46852 ± 2%
[PATCH] trace: fix typo in allocate_ftrace_ops()'s comment
No functional change, just correct the word. Signed-off-by: Wei Yang --- kernel/trace/trace_functions.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/kernel/trace/trace_functions.c b/kernel/trace/trace_functions.c index 8a4c8d5c2c98..dd4dff71d89a 100644 --- a/kernel/trace/trace_functions.c +++ b/kernel/trace/trace_functions.c @@ -42,7 +42,7 @@ static int allocate_ftrace_ops(struct trace_array *tr) if (!ops) return -ENOMEM; - /* Currently only the non stack verision is supported */ + /* Currently only the non stack version is supported */ ops->func = function_trace_call; ops->flags = FTRACE_OPS_FL_RECURSION_SAFE | FTRACE_OPS_FL_PID; -- 2.20.1 (Apple Git-117)
[rcu:dev.2020.06.08a] BUILD SUCCESS 4c9801b68a39e6b46a6abc19f0dee39474d45984
f's module parameters 0 0 0 42050180cc8c refperf: Work around 64-bit division 0 0 0 58a5f4ce2baa refperf: Change readdelay module parameter to nanoseconds 0 0 0 5046313604ec refperf: Add test for RCU Tasks Trace readers. 0 0 0 90122438ed67 rcu/rcutorture: Replace 0 with false 0 0 0 ede7edf3ce6b rcu: Replace 1 with true 0 0 0 b004faf0336a kcsan: Prefer '__no_kcsan inline' in test 0 0 0 9436b943c1ff EXP kernel/smp: Provide CSD lock timeout diagnostics 0 0 0 e0d7beb95212 refperf: Add test for RCU Tasks readers 0 0 0 8487daf0e4cd tools/memory-model/README: Expand dependency of klitmus7 0 0 0 2630bf802331 rcu: Stop shrinker loop 0 0 0 f6f1566ffb39 torture: Create qemu-cmd in --buildonly runs 0 0 0 c0b8a3f7994a rcu-tasks: Fix code-style issues 0 0 0 4c9801b68a39 squash! EXP kernel/smp: Provide CSD lock timeout diagnostics -188 -189+136 b1fcf9b83c41..4c9801b68a39 (ALL COMMITS) elapsed time: 562m configs tested: 99 configs skipped: 2 The following configs have been built successfully. More configs may be tested in the coming days. arm64allyesconfig arm64 defconfig arm64allmodconfig arm64 allnoconfig arm defconfig arm allyesconfig arm allmodconfig arm allnoconfig arm efm32_defconfig armvexpress_defconfig xtensa iss_defconfig mips decstation_64_defconfig sh cayman_defconfig arm shannon_defconfig umallnoconfig arm socfpga_defconfig sh sh7724_generic_defconfig i386 allyesconfig i386defconfig i386 debian-10.3 i386 allnoconfig ia64 allmodconfig ia64defconfig ia64 allnoconfig ia64 allyesconfig m68k allmodconfig m68k allnoconfig m68k sun3_defconfig m68kdefconfig m68k allyesconfig nios2 defconfig nios2allyesconfig openriscdefconfig c6x allyesconfig c6x allnoconfig openrisc allyesconfig nds32 defconfig nds32 allnoconfig csky allyesconfig cskydefconfig alpha defconfig alphaallyesconfig xtensa allyesconfig h8300allyesconfig h8300allmodconfig xtensa defconfig arc defconfig arc allyesconfig sh allmodconfig shallnoconfig microblazeallnoconfig mips allyesconfig mips allnoconfig mips allmodconfig pariscallnoconfig parisc defconfig parisc allyesconfig parisc allmodconfig powerpc defconfig powerpc allyesconfig powerpc rhel-kconfig powerpc allmodconfig powerpc allnoconfig i386 randconfig-a001-20200
Re: [kbuild-all] Re: gcc-5: error: -gz is not supported in this configuration
On Tue, Jun 09, 2020 at 11:12:25PM -0400, Arvind Sankar wrote: > On Wed, Jun 10, 2020 at 09:49:01AM +0800, Rong Chen wrote: > > > > > > On 6/10/20 8:58 AM, Fangrui Song wrote: > > > On 2020-06-10, Rong Chen wrote: > > >> > > >> > > >> On 6/10/20 1:49 AM, Fangrui Song wrote: > > >>> On 2020-06-09, Nick Desaulniers wrote: > > >>>> On Tue, Jun 9, 2020 at 6:12 AM kernel test robot > > >>>> wrote: > > >>>>> > > >>>>> tree: > > >>>>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git > > >>>>> master > > >>>>> head: abfbb29297c27e3f101f348dc9e467b0fe70f919 > > >>>>> commit: 10e68b02c861ccf2b3adb59d3f0c10dc6b5e3ace Makefile: support > > >>>>> compressed debug info > > >>>>> date: 12 days ago > > >>>>> config: x86_64-randconfig-r032-20200609 (attached as .config) > > >>>>> compiler: gcc-5 (Ubuntu 5.5.0-12ubuntu1) 5.5.0 20171010 > > >>>>> reproduce (this is a W=1 build): > > >>>>> git checkout 10e68b02c861ccf2b3adb59d3f0c10dc6b5e3ace > > >>>>> # save the attached .config to linux build tree > > >>>>> make W=1 ARCH=x86_64 > > >>>>> > > >>>>> If you fix the issue, kindly add following tag as appropriate > > >>>>> Reported-by: kernel test robot > > >>>>> > > >>>>> All errors (new ones prefixed by >>, old ones prefixed by <<): > > >>>>> > > >>>>>>> gcc-5: error: -gz is not supported in this configuration > > >>>> > > >>>> Hmm...I wonder if the feature detection is incomplete? I suspect it's > > >>>> possible to not depend on zlib. > > >>>> > > >>>>> make[2]: *** [scripts/Makefile.build:277: scripts/mod/empty.o] > > >>>>> Error 1 > > >>>>> make[2]: Target '__build' not remade because of errors. > > >>>>> make[1]: *** [Makefile:1169: prepare0] Error 2 > > >>>>> make[1]: Target 'prepare' not remade because of errors. > > >>>>> make: *** [Makefile:185: __sub-make] Error 2 > > >>> > > >>> The output of gcc-5 -v --version on that machine may help. The > > >>> convoluted gcc_cv_ld_compress_de logic in gcc/configure.ac may be > > >>> related, but I can't find any mistake that our > > >>> CONFIG_DEBUG_INFO_COMPRESSED conditions may make. > > >> > > The output of gcc-5 -dumpspecs may also be useful. > > The exact Kconfig check should have been > gcc-5 -Werror -gz=zlib -S -x c /dev/null -o /dev/null > > I can't see how that would succeed if the a.c test didn't but maybe just > in case? Oh wait, -S instead of -c. Which means it runs neither the assembler nor the linker, so gcc won't error out. But if that gcc was originally _configured_ with a version of binutils that doesn't support -gz=zlib, it will give an error on -c regardless of whether the runtime binutils would actually support it or not.
Your response is needed.
Hello friend, I hope this email meets you in good health. I am an investment counselor, leading a law firm. And I have a business proposal which I would like to discuss with you. If you are interested, please communicate with me immediately. Upon your response, I shall then supply you with more details. I anticipate your reply. Best regards, Anthony Nugan. -- This email has been checked for viruses by AVG. https://www.avg.com
Re: [PATCH v11 00/16] per memcg lru lock
On Mon, 8 Jun 2020, Alex Shi wrote: > 在 2020/6/8 下午12:15, Hugh Dickins 写道: > >> 24 files changed, 487 insertions(+), 312 deletions(-) > > Hi Alex, > > > > I didn't get to try v10 at all, waited until Johannes's preparatory > > memcg swap cleanup was in mmotm; but I have spent a while thrashing > > this v11, and can happily report that it is much better than v9 etc: > > I believe this memcg lru_lock work will soon be ready for v5.9. > > > > I've not yet found any flaw at the swapping end, but fixes are needed > > for isolate_migratepages_block() and mem_cgroup_move_account(): I've > > got a series of 4 fix patches to send you (I guess two to fold into > > existing patches of yours, and two to keep as separate from me). > > > > I haven't yet written the patch descriptions, will return to that > > tomorrow. I expect you will be preparing a v12 rebased on v5.8-rc1 > > or v5.8-rc2, and will be able to include these fixes in that. > > I am very glad to get your help on this feature! > > and looking forward for your fixes tomorrow. :) > > Thanks a lot! > Alex Sorry, Alex, the news is not so good today. You'll have noticed I sent nothing yesterday. That's because I got stuck on my second patch: could not quite convince myself that it was safe. I keep hinting at these patches, and I can't complete their writeups until I'm convinced; but to give you a better idea of what they do: 1. Fixes isolate_fail and isolate_abort in isolate_migratepages_block(). 2. Fixes unsafe use of trylock_page() in __isolate_lru_page_prepare(). 3. Reverts 07/16 inversion of lock ordering in split_huge_page_to_list(). 4. Adds lruvec lock protection in mem_cgroup_move_account(). In the second, I was using rcu_read_lock() instead of trylock_page() (like in my own patchset), but could not quite be sure of the case when PageSwapCache gets set at the wrong moment. Gave up for the night, and in the morning abandoned that, instead just shifting the call to __isolate_lru_page_prepare() after the get_page_unless_zero(), where that trylock_page() becomes safe (no danger of stomping on page flags while page is being freed or newly allocated to another owner). I thought that a very safe change, but best to do some test runs with it in before finalizing. And was then unpleasantly surprised to hit a VM_BUG_ON_PAGE(lruvec_memcg(lruvec) != page->mem_cgroup) from lock_page_lruvec_irqsave < relock_page_lruvec < pagevec_lru_move_fn < pagevec_move_tail < lru_add_drain_cpu after 6 hours on one machine. Then similar but < rotate_reclaimable_page after 8 hours on another. Only seen once before: that's what drove me to add patch 4 (with 3 to revert the locking before it): somehow, when adding the lruvec locking there, I just took it for granted that your patchset would have the appropriate locking (or TestClearPageLRU magic) at the other end. But apparently not. And I'm beginning to think that TestClearPageLRU was just to distract the audience from the lack of proper locking. I have certainly not concluded that yet, but I'm having to think about an area of the code which I'd imagined you had under control (and I'm puzzled why my testing has found it so very hard to hit). If we're lucky, I'll find that pagevec_move_tail is a special case, and nothing much else needs changing; but I doubt that will be so. There's one other unexplained and unfixed bug I've seen several times while exercising mem_cgroup_move_account(): refcount_warn_saturate() from where __mem_cgroup_clear_mc() calls mem_cgroup_id_get_many(). I'll be glad if that goes away when the lruvec locking is fixed, but don't understand the connection. And it's quite possible that this refcounting bug has nothing to do with your changes: I have not succeeded in reproducing it on 5.7 nor on 5.7-rc7-mm1, but I didn't really try long enough to be sure. (I should also warn, that I'm surprised by the amount of change 11/16 makes to mm/mlock.c: I've not been exercising mlock at all.) Taking a break for the evening, Hugh
Re: [PATCH RFC v6 02/11] vhost: use batched get_vq_desc version
On 2020/6/8 下午8:52, Michael S. Tsirkin wrote:
As testing shows no performance change, switch to that now.
Signed-off-by: Michael S. Tsirkin
Signed-off-by: Eugenio Pérez
Link: https://lore.kernel.org/r/20200401183118.8334-3-epere...@redhat.com
Signed-off-by: Michael S. Tsirkin
---
drivers/vhost/test.c | 2 +-
drivers/vhost/vhost.c | 318 --
drivers/vhost/vhost.h | 7 +-
3 files changed, 65 insertions(+), 262 deletions(-)
diff --git a/drivers/vhost/test.c b/drivers/vhost/test.c
index 0466921f4772..7d69778aaa26 100644
--- a/drivers/vhost/test.c
+++ b/drivers/vhost/test.c
@@ -119,7 +119,7 @@ static int vhost_test_open(struct inode *inode, struct file
*f)
dev = >dev;
vqs[VHOST_TEST_VQ] = >vqs[VHOST_TEST_VQ];
n->vqs[VHOST_TEST_VQ].handle_kick = handle_vq_kick;
- vhost_dev_init(dev, vqs, VHOST_TEST_VQ_MAX, UIO_MAXIOV,
+ vhost_dev_init(dev, vqs, VHOST_TEST_VQ_MAX, UIO_MAXIOV + 64,
VHOST_TEST_PKT_WEIGHT, VHOST_TEST_WEIGHT, true, NULL);
f->private_data = n;
diff --git a/drivers/vhost/vhost.c b/drivers/vhost/vhost.c
index 180b7b58c76b..41d6b132c234 100644
--- a/drivers/vhost/vhost.c
+++ b/drivers/vhost/vhost.c
@@ -304,6 +304,7 @@ static void vhost_vq_reset(struct vhost_dev *dev,
{
vq->num = 1;
vq->ndescs = 0;
+ vq->first_desc = 0;
vq->desc = NULL;
vq->avail = NULL;
vq->used = NULL;
@@ -372,6 +373,11 @@ static int vhost_worker(void *data)
return 0;
}
+static int vhost_vq_num_batch_descs(struct vhost_virtqueue *vq)
+{
+ return vq->max_descs - UIO_MAXIOV;
+}
+
static void vhost_vq_free_iovecs(struct vhost_virtqueue *vq)
{
kfree(vq->descs);
@@ -394,6 +400,9 @@ static long vhost_dev_alloc_iovecs(struct vhost_dev *dev)
for (i = 0; i < dev->nvqs; ++i) {
vq = dev->vqs[i];
vq->max_descs = dev->iov_limit;
+ if (vhost_vq_num_batch_descs(vq) < 0) {
+ return -EINVAL;
+ }
vq->descs = kmalloc_array(vq->max_descs,
sizeof(*vq->descs),
GFP_KERNEL);
@@ -1610,6 +1619,7 @@ long vhost_vring_ioctl(struct vhost_dev *d, unsigned int
ioctl, void __user *arg
vq->last_avail_idx = s.num;
/* Forget the cached index value. */
vq->avail_idx = vq->last_avail_idx;
+ vq->ndescs = vq->first_desc = 0;
break;
case VHOST_GET_VRING_BASE:
s.index = idx;
@@ -2078,253 +2088,6 @@ static unsigned next_desc(struct vhost_virtqueue *vq,
struct vring_desc *desc)
return next;
}
-static int get_indirect(struct vhost_virtqueue *vq,
- struct iovec iov[], unsigned int iov_size,
- unsigned int *out_num, unsigned int *in_num,
- struct vhost_log *log, unsigned int *log_num,
- struct vring_desc *indirect)
-{
- struct vring_desc desc;
- unsigned int i = 0, count, found = 0;
- u32 len = vhost32_to_cpu(vq, indirect->len);
- struct iov_iter from;
- int ret, access;
-
- /* Sanity check */
- if (unlikely(len % sizeof desc)) {
- vq_err(vq, "Invalid length in indirect descriptor: "
- "len 0x%llx not multiple of 0x%zx\n",
- (unsigned long long)len,
- sizeof desc);
- return -EINVAL;
- }
-
- ret = translate_desc(vq, vhost64_to_cpu(vq, indirect->addr), len,
vq->indirect,
-UIO_MAXIOV, VHOST_ACCESS_RO);
- if (unlikely(ret < 0)) {
- if (ret != -EAGAIN)
- vq_err(vq, "Translation failure %d in indirect.\n",
ret);
- return ret;
- }
- iov_iter_init(, READ, vq->indirect, ret, len);
-
- /* We will use the result as an address to read from, so most
-* architectures only need a compiler barrier here. */
- read_barrier_depends();
-
- count = len / sizeof desc;
- /* Buffers are chained via a 16 bit next field, so
-* we can have at most 2^16 of these. */
- if (unlikely(count > USHRT_MAX + 1)) {
- vq_err(vq, "Indirect buffer length too big: %d\n",
- indirect->len);
- return -E2BIG;
- }
-
- do {
- unsigned iov_count = *in_num + *out_num;
- if (unlikely(++found > count)) {
- vq_err(vq, "Loop detected: last one at %u "
- "indirect size %u\n",
- i, count);
- return -EINVAL;
- }
- if (unlikely(!copy_from_iter_full(, sizeof(desc), )))
{
- vq_err(vq, "Failed indirect descriptor: idx %d, %zx\n",
Re: [f2fs-dev] [PATCH] f2fs: add F2FS_IOC_SEC_TRIM_FILE ioctl
On Wed, Jun 10, 2020 at 11:05:46AM +0900, Daeho Jeong wrote: > > > Added a new ioctl to send discard commands or/and zero out > > > to whole data area of a regular file for security reason. > > > > With this ioctl available, what is the exact procedure to write and then > > later > > securely erase a file on f2fs? In particular, how can the user prevent f2fs > > from making multiple copies of file data blocks as part of garbage > > collection? > > > > To prevent the file data from garbage collecting, the user needs to > use pinfile ioctl and fallocate system call after creating the file. > The sequence is like below. > 1. create an empty file > 2. pinfile > 3. fallocate() Is that persistent? So the file will never be moved afterwards? Is there a place where this is (or should be) documented? > > > + > > > + if (f2fs_readonly(sbi->sb)) > > > + return -EROFS; > > > > Isn't this redundant with mnt_want_write_file()? > > > > Also, shouldn't write access to the file be required, i.e. > > (filp->f_mode & FMODE_WRITE)? Then the f2fs_readonly() and > > mnt_want_write_file() checks would be unnecessary. > > > > Using FMODE_WRITE is more proper for this case, since we're going to > modify the data. But I think mnt_want_write_file() is still required > to prevent the filesystem from freezing or something else. Right, the freezing check is actually still necessary. But getting write access to the mount is not necessary. I think you should use file_start_write() and file_end_write(), like vfs_write() does. > > > > > + > > > + if (get_user(flags, (u32 __user *)arg)) > > > + return -EFAULT; > > > + if (!(flags & F2FS_TRIM_FILE_MASK)) > > > + return -EINVAL; > > > > Need to reject unknown flags: > > > > if (flags & ~F2FS_TRIM_FILE_MASK) > > return -EINVAL; > > I needed a different thing here. This was to check neither discard nor > zeroing out are not here. But we still need to check unknown flags, > too. > The below might be better. > if (!flags || flags & ~F2FS_TRIM_FILE_MASK) >return -EINVAL; Sure, but please put parentheses around the second clause: if (flags == 0 || (flags & ~F2FS_TRIM_FILE_MASK)) return -EINVAL; - Eric
Re: [PATCH v2 05/12] mm/hugetlb: unify hugetlb migration callback function
2020년 6월 9일 (화) 오후 10:43, Michal Hocko 님이 작성:
>
> On Wed 27-05-20 15:44:56, Joonsoo Kim wrote:
> [...]
> > -/* page migration callback function */
> > struct page *alloc_huge_page_nodemask(struct hstate *h,
> > struct alloc_control *ac)
> > {
> > ac->gfp_mask |= htlb_alloc_mask(h);
> > + if (ac->nid == NUMA_NO_NODE)
> > + ac->gfp_mask &= ~__GFP_THISNODE;
>
> Is this really needed? alloc_huge_page_node is currently only called
> from numa migration code and the target node should be always defined.
Thanks! When I read the code, I was not sure that the target node is always
defined so I left this code. However, if it's true, this code isn't
needed at all.
I will consider your suggestion in the next version.
Thanks.
Re: [kbuild-all] Re: gcc-5: error: -gz is not supported in this configuration
On Wed, Jun 10, 2020 at 09:49:01AM +0800, Rong Chen wrote: > > > On 6/10/20 8:58 AM, Fangrui Song wrote: > > On 2020-06-10, Rong Chen wrote: > >> > >> > >> On 6/10/20 1:49 AM, Fangrui Song wrote: > >>> On 2020-06-09, Nick Desaulniers wrote: > >>>> On Tue, Jun 9, 2020 at 6:12 AM kernel test robot > >>>> wrote: > >>>>> > >>>>> tree: > >>>>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git > >>>>> master > >>>>> head: abfbb29297c27e3f101f348dc9e467b0fe70f919 > >>>>> commit: 10e68b02c861ccf2b3adb59d3f0c10dc6b5e3ace Makefile: support > >>>>> compressed debug info > >>>>> date: 12 days ago > >>>>> config: x86_64-randconfig-r032-20200609 (attached as .config) > >>>>> compiler: gcc-5 (Ubuntu 5.5.0-12ubuntu1) 5.5.0 20171010 > >>>>> reproduce (this is a W=1 build): > >>>>> git checkout 10e68b02c861ccf2b3adb59d3f0c10dc6b5e3ace > >>>>> # save the attached .config to linux build tree > >>>>> make W=1 ARCH=x86_64 > >>>>> > >>>>> If you fix the issue, kindly add following tag as appropriate > >>>>> Reported-by: kernel test robot > >>>>> > >>>>> All errors (new ones prefixed by >>, old ones prefixed by <<): > >>>>> > >>>>>>> gcc-5: error: -gz is not supported in this configuration > >>>> > >>>> Hmm...I wonder if the feature detection is incomplete? I suspect it's > >>>> possible to not depend on zlib. > >>>> > >>>>> make[2]: *** [scripts/Makefile.build:277: scripts/mod/empty.o] > >>>>> Error 1 > >>>>> make[2]: Target '__build' not remade because of errors. > >>>>> make[1]: *** [Makefile:1169: prepare0] Error 2 > >>>>> make[1]: Target 'prepare' not remade because of errors. > >>>>> make: *** [Makefile:185: __sub-make] Error 2 > >>> > >>> The output of gcc-5 -v --version on that machine may help. The > >>> convoluted gcc_cv_ld_compress_de logic in gcc/configure.ac may be > >>> related, but I can't find any mistake that our > >>> CONFIG_DEBUG_INFO_COMPRESSED conditions may make. > >> The output of gcc-5 -dumpspecs may also be useful. The exact Kconfig check should have been gcc-5 -Werror -gz=zlib -S -x c /dev/null -o /dev/null I can't see how that would succeed if the a.c test didn't but maybe just in case?
Re: [PATCH v3 0/7] Venus dynamic debug
On Tue, Jun 9, 2020 at 4:23 PM Joe Perches wrote: > > On Tue, 2020-06-09 at 15:21 -0600, jim.cro...@gmail.com wrote: > > > > As Joe noted, there is a lot of ad-hockery to possibly clean up, > > but I dont grok how these levels should be distinguished from > > KERN_(WARN|INFO|DEBUG) constants. > > These are not KERN_ at all, all are emitted at KERN_DEBUG yes indeed. but they are chosen by programmer, fixed by compiler. not dynamic. also noted the conceptual adjacency (ambiguity), and referenced KERN_ If we need this extra query-term, lets call it mbits / mflags / module_flags / module_bits it needs to be module specific, so also requiring "module foo" search term in the query. ( "modflags" is no good, cuz "mod" also means "modified" - just mflags is better ) Already, we have function, file, module, all of which convey semantic structure of the code, and they also match wildcards, so " function foo_*_* " is an effective grouping. Id think this would cover most cases. Finally, all "module venus +p " callsites could be explicitly specified individually in universe=`grep venus control | wc -l` lines, likely a small set. Using the semantic structure exposed by `grep venus control`, it would likely be far less.
Re: [PATCH v2 04/12] mm/hugetlb: use provided ac->gfp_mask for allocation
2020년 6월 9일 (화) 오후 10:26, Michal Hocko 님이 작성: > > On Wed 27-05-20 15:44:55, Joonsoo Kim wrote: > > From: Joonsoo Kim > > > > gfp_mask handling on alloc_huge_page_(node|nodemask) is > > slightly changed, from ASSIGN to OR. It's safe since caller of these > > functions doesn't pass extra gfp_mask except htlb_alloc_mask(). > > > > This is a preparation step for following patches. > > This patch on its own doesn't make much sense to me. Should it be folded > in the patch which uses that? Splitting this patch is requested by Roman. :) Anyway, the next version would not have this patch since many thing will be changed. Thanks.
Re: [PATCH v2 03/12] mm/hugetlb: introduce alloc_control structure to simplify migration target allocation APIs
2020년 6월 9일 (화) 오후 10:24, Michal Hocko 님이 작성:
>
> On Wed 27-05-20 15:44:54, Joonsoo Kim wrote:
> > From: Joonsoo Kim
> >
> > Currently, page allocation functions for migration requires some arguments.
> > More worse, in the following patch, more argument will be needed to unify
> > the similar functions. To simplify them, in this patch, unified data
> > structure that controls allocation behaviour is introduced.
> >
> > For clean-up, function declarations are re-ordered.
>
> This is really hard to review without having a clear picture of the
> resulting code so bear with me. I can see some reasons why allocation
> callbacks might benefit from a agragated argument but you seem to touch
> the internal hugetlb dequeue_huge_page_vma which shouldn't really need
> that. I wouldn't mind much but I remember the hugetlb allocation
> functions layering is quite complex for hugetlb specific reasons (see
> 0c397daea1d4 ("mm, hugetlb: further simplify hugetlb allocation API")
> for more background).
>
> Is there any reason why the agregated argument cannot be limited only to
> migration callbacks. That would be alloc_huge_page_node,
> alloc_huge_page_nodemask
> and alloc_huge_page_vma.
I did it since it's simple for me, but, yes, it's not good to touch
the internal functions.
Anyway, Vlastimil already suggested not to introduce alloc_control for
any hugetlb
functions. I will try it on the next version so the next version would not have
alloc_control in any hugetlb functions.
Thanks.
[PATCH] xdp_rxq_info_user: Add null check after malloc
Signed-off-by: Gaurav Singh
The memset call is made right after malloc call which
can return a NULL pointer upon failure causing a
segmentation fault. Fix this by adding a null check
right after malloc() and then do memset().
---
samples/bpf/xdp_rxq_info_user.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/samples/bpf/xdp_rxq_info_user.c b/samples/bpf/xdp_rxq_info_user.c
index 4fe47502ebed..2d03c84a4cca 100644
--- a/samples/bpf/xdp_rxq_info_user.c
+++ b/samples/bpf/xdp_rxq_info_user.c
@@ -202,11 +202,11 @@ static struct datarec *alloc_record_per_cpu(void)
size = sizeof(struct datarec) * nr_cpus;
array = malloc(size);
- memset(array, 0, size);
if (!array) {
fprintf(stderr, "Mem alloc error (nr_cpus:%u)\n", nr_cpus);
exit(EXIT_FAIL_MEM);
}
+ memset(array, 0, size);
return array;
}
@@ -218,11 +218,11 @@ static struct record *alloc_record_per_rxq(void)
size = sizeof(struct record) * nr_rxqs;
array = malloc(size);
- memset(array, 0, size);
if (!array) {
fprintf(stderr, "Mem alloc error (nr_rxqs:%u)\n", nr_rxqs);
exit(EXIT_FAIL_MEM);
}
+ memset(array, 0, size);
return array;
}
@@ -233,11 +233,11 @@ static struct stats_record *alloc_stats_record(void)
int i;
rec = malloc(sizeof(*rec));
- memset(rec, 0, sizeof(*rec));
if (!rec) {
fprintf(stderr, "Mem alloc error\n");
exit(EXIT_FAIL_MEM);
}
+ memset(rec, 0, sizeof(*rec));
rec->rxq = alloc_record_per_rxq();
for (i = 0; i < nr_rxqs; i++)
rec->rxq[i].cpu = alloc_record_per_cpu();
--
2.17.1
Re: [PATCH] uprobes: ensure that uprobe->offset and ->ref_ctr_offset are properly aligned
Hi Oleg, On Tue, May 5, 2020 at 12:47 AM Oleg Nesterov wrote: > > uprobe_write_opcode() must not cross page boundary; prepare_uprobe() > relies on arch_uprobe_analyze_insn() which should validate "vaddr" but > some architectures (csky, s390, and sparc) don't do this. > > We can remove the BUG_ON() check in prepare_uprobe() and validate the > offset early in __uprobe_register(). The new IS_ALIGNED() check matches > the alignment check in arch_prepare_kprobe() on supported architectures, > so I think that all insns must be aligned to UPROBE_SWBP_INSN_SIZE. > > Another problem is __update_ref_ctr() which was wrong from the very > beginning, it can read/write outside of kmap'ed page unless "vaddr" is > aligned to sizeof(short), __uprobe_register() should check this too. > > Cc: sta...@vger.kernel.org > Reported-by: Linus Torvalds > Suggested-by: Linus Torvalds > Signed-off-by: Oleg Nesterov > --- > kernel/events/uprobes.c | 16 > 1 file changed, 12 insertions(+), 4 deletions(-) > > diff --git a/kernel/events/uprobes.c b/kernel/events/uprobes.c > index ece7e13f6e4a..cc2095607c74 100644 > --- a/kernel/events/uprobes.c > +++ b/kernel/events/uprobes.c > @@ -867,10 +867,6 @@ static int prepare_uprobe(struct uprobe *uprobe, struct > file *file, > if (ret) > goto out; > > - /* uprobe_write_opcode() assumes we don't cross page boundary */ > - BUG_ON((uprobe->offset & ~PAGE_MASK) + > - UPROBE_SWBP_INSN_SIZE > PAGE_SIZE); > - > smp_wmb(); /* pairs with the smp_rmb() in handle_swbp() */ > set_bit(UPROBE_COPY_INSN, >flags); > > @@ -1166,6 +1162,15 @@ static int __uprobe_register(struct inode *inode, > loff_t offset, > if (offset > i_size_read(inode)) > return -EINVAL; > > + /* > +* This ensures that copy_from_page(), copy_to_page() and > +* __update_ref_ctr() can't cross page boundary. > +*/ > + if (!IS_ALIGNED(offset, UPROBE_SWBP_INSN_SIZE)) > + return -EINVAL; > + if (!IS_ALIGNED(ref_ctr_offset, sizeof(short))) > + return -EINVAL; > + > retry: > uprobe = alloc_uprobe(inode, offset, ref_ctr_offset); > if (!uprobe) > @@ -2014,6 +2019,9 @@ static int is_trap_at_addr(struct mm_struct *mm, > unsigned long vaddr) > uprobe_opcode_t opcode; > int result; > > + if (WARN_ON_ONCE(!IS_ALIGNED(vaddr, UPROBE_SWBP_INSN_SIZE))) > + return -EINVAL; > + > pagefault_disable(); > result = __get_user(opcode, (uprobe_opcode_t __user *)vaddr); > pagefault_enable(); > -- > 2.25.1.362.g51ebf55 > > Looks good to me, thx. Reviewed-by: Guo Ren -- Best Regards Guo Ren ML: https://lore.kernel.org/linux-csky/
Re: [PATCH] uprobes: ensure that uprobe->offset and ->ref_ctr_offset are properly aligned
On Tue, May 5, 2020 at 2:41 AM Christian Borntraeger wrote: > > > > On 04.05.20 18:47, Oleg Nesterov wrote: > > uprobe_write_opcode() must not cross page boundary; prepare_uprobe() > > relies on arch_uprobe_analyze_insn() which should validate "vaddr" but > > some architectures (csky, s390, and sparc) don't do this. > > I think the idea was that the uprobe instruction is 2 bytes and instructions > are always aligned to 2 bytes on s390. (we can have 2,4 or 6 bytes). Agree, csky has two length-types of instructions (2,4 bytes). > > > > > We can remove the BUG_ON() check in prepare_uprobe() and validate the > > offset early in __uprobe_register(). The new IS_ALIGNED() check matches > > the alignment check in arch_prepare_kprobe() on supported architectures, > > so I think that all insns must be aligned to UPROBE_SWBP_INSN_SIZE. > > Not sure if it would have been possible to try to create a uprobe on an > odd address. If yes, then the new IS_ALIGNED check certainly makes this > better for s390, so the patch looks sane. Adding Vasily and Sven to double > check. Also good to csky. -- Best Regards Guo Ren ML: https://lore.kernel.org/linux-csky/
[PATCH] docs/zh_CN: update sysfs.txt about show() usage
Update the show() usage according to the English version. Signed-off-by: Chen Zhou --- Documentation/translations/zh_CN/filesystems/sysfs.txt | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/Documentation/translations/zh_CN/filesystems/sysfs.txt b/Documentation/translations/zh_CN/filesystems/sysfs.txt index fcf620049d11..9481e3ed2a06 100644 --- a/Documentation/translations/zh_CN/filesystems/sysfs.txt +++ b/Documentation/translations/zh_CN/filesystems/sysfs.txt @@ -213,10 +213,12 @@ Sysfs 将会为每次读写操作调用一次这个方法。这使得这些方 - 缓冲区应总是 PAGE_SIZE 大小。对于i386，这个值为4096。 -- show() 方法应该返回写入缓冲区的字节数，也就是 snprintf()的 +- show() 方法应该返回写入缓冲区的字节数，也就是 scnprintf()的 返回值。 -- show() 应始终使用 snprintf()。 +- show() 方法在将格式化返回值返回用户空间的时候，禁止使用snprintf()。 + 如果可以保证不会发生缓冲区溢出，可以使用sprintf()，否则必须使用 + scnprintf()。 - store() 应返回缓冲区的已用字节数。如果整个缓存都已填满，只需返回 count 参数。 -- 2.20.1
[PATCH] USB: ohci-sm501: Add missed iounmap() in remove
This driver misses calling iounmap() in remove to undo the ioremap()
called in probe.
Add the missed call to fix it.
Fixes: f54aab6ebcec ("usb: ohci-sm501 driver")
Signed-off-by: Chuhong Yuan
---
drivers/usb/host/ohci-sm501.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/usb/host/ohci-sm501.c b/drivers/usb/host/ohci-sm501.c
index cff965240327..b91d50da6127 100644
--- a/drivers/usb/host/ohci-sm501.c
+++ b/drivers/usb/host/ohci-sm501.c
@@ -191,6 +191,7 @@ static int ohci_hcd_sm501_drv_remove(struct platform_device
*pdev)
struct resource *mem;
usb_remove_hcd(hcd);
+ iounmap(hcd->regs);
release_mem_region(hcd->rsrc_start, hcd->rsrc_len);
usb_put_hcd(hcd);
mem = platform_get_resource(pdev, IORESOURCE_MEM, 1);
--
2.26.2
Re: [PATCH] scsi: eesox: Fix different dev_id between 'request_irq()' and 'free_irq()'
On Sat, 30 May 2020 09:34:18 +0200, Christophe JAILLET wrote: > The dev_id used in 'request_irq()' and 'free_irq()' should match. > So use 'host' in both cases. Applied to 5.8/scsi-queue, thanks! [1/1] scsi: eesox: Fix different dev_id between request_irq() and free_irq() https://git.kernel.org/mkp/scsi/c/3bab76807d95 -- Martin K. Petersen Oracle Linux Engineering
Re: [PATCH] scsi: acornscsi: Fix an error handling path in 'acornscsi_probe()'
On Sat, 30 May 2020 10:16:22 +0200, Christophe JAILLET wrote: > 'ret' is known to be 0 at this point. > So, explicitly return -ENOMEM if one of the 'ecardm_iomap()' calls fail. Applied to 5.8/scsi-queue, thanks! [1/1] scsi: acornscsi: Fix an error handling path in acornscsi_probe() https://git.kernel.org/mkp/scsi/c/7960c0b29626 -- Martin K. Petersen Oracle Linux Engineering
Re: [PATCH] scsi: powertec: Fix different dev_id between 'request_irq()' and 'free_irq()'
On Sat, 30 May 2020 09:29:33 +0200, Christophe JAILLET wrote: > The dev_id used in 'request_irq()' and 'free_irq()' should match. > So use 'host' in both cases. Applied to 5.8/scsi-queue, thanks! [1/1] scsi: powertec: Fix different dev_id between request_irq() and free_irq() https://git.kernel.org/mkp/scsi/c/af7b415a1ebf -- Martin K. Petersen Oracle Linux Engineering
[PATCH] PCI: Loongson: Use DECLARE_PCI_FIXUP_EARLY for bridge_class_quirk()
Use DECLARE_PCI_FIXUP_EARLY instead of DECLARE_PCI_FIXUP_HEADER
for bridge_class_quirk() in pci-loongson.c, otherwise the fixup
has no effect.
Fixes: 1f58cca5cf2b ("PCI: Add Loongson PCI Controller support")
Signed-off-by: Tiezhu Yang
---
This patch is based on mips-next tree.
drivers/pci/controller/pci-loongson.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/pci/controller/pci-loongson.c
b/drivers/pci/controller/pci-loongson.c
index 459009c..58b862a 100644
--- a/drivers/pci/controller/pci-loongson.c
+++ b/drivers/pci/controller/pci-loongson.c
@@ -37,11 +37,11 @@ static void bridge_class_quirk(struct pci_dev *dev)
{
dev->class = PCI_CLASS_BRIDGE_PCI << 8;
}
-DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_LOONGSON,
+DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_LOONGSON,
DEV_PCIE_PORT_0, bridge_class_quirk);
-DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_LOONGSON,
+DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_LOONGSON,
DEV_PCIE_PORT_1, bridge_class_quirk);
-DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_LOONGSON,
+DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_LOONGSON,
DEV_PCIE_PORT_2, bridge_class_quirk);
static void system_bus_quirk(struct pci_dev *pdev)
--
2.1.0
Re: [PATCH 1/3] usb: typec: Add QCOM PMIC typec detection driver
Hi Wesley,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on usb/usb-testing]
[also build test ERROR on robh/for-next v5.7 next-20200609]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use '--base' option to specify the
base tree in git format-patch, please see https://stackoverflow.com/a/37406982]
url:
https://github.com/0day-ci/linux/commits/Wesley-Cheng/Introduce-PMIC-based-USB-type-C-detection/20200610-050045
base: https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git
usb-testing
config: arm-allyesconfig (attached as .config)
compiler: arm-linux-gnueabi-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross ARCH=arm
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All error/warnings (new ones prefixed by >>, old ones prefixed by <<):
>> drivers/usb/typec/qcom-pmic-typec.c:86:6: warning: no previous prototype for
>> 'qcom_pmic_typec_bh_work' [-Wmissing-prototypes]
86 | void qcom_pmic_typec_bh_work(struct work_struct *w)
| ^~~
>> drivers/usb/typec/qcom-pmic-typec.c:116:13: warning: no previous prototype
>> for 'qcom_pmic_typec_interrupt' [-Wmissing-prototypes]
116 | irqreturn_t qcom_pmic_typec_interrupt(int irq, void *_qcom_usb)
| ^
In file included from drivers/usb/typec/qcom-pmic-typec.c:7:
drivers/usb/typec/qcom-pmic-typec.c: In function
'qcom_pmic_typec_typec_hw_init':
>> include/linux/build_bug.h:16:51: error: negative width in bit-field
>> ''
16 | #define BUILD_BUG_ON_ZERO(e) ((int)(sizeof(struct { int:(-!!(e)); })))
| ^
include/linux/regmap.h:84:36: note: in definition of macro 'regmap_update_bits'
84 | regmap_update_bits_base(map, reg, mask, val, NULL, false, false)
|^~~~
include/linux/bits.h:25:3: note: in expansion of macro 'BUILD_BUG_ON_ZERO'
25 | (BUILD_BUG_ON_ZERO(__builtin_choose_expr( | ^
include/linux/bits.h:39:3: note: in expansion of macro 'GENMASK_INPUT_CHECK'
39 | (GENMASK_INPUT_CHECK(h, l) + __GENMASK(h, l))
| ^~~
>> drivers/usb/typec/qcom-pmic-typec.c:48:34: note: in expansion of macro
>> 'GENMASK'
48 | #define TYPEC_INTR_EN_CFG_1_MASK GENMASK(0, 7)
| ^~~
>> drivers/usb/typec/qcom-pmic-typec.c:132:7: note: in expansion of macro
>> 'TYPEC_INTR_EN_CFG_1_MASK'
132 | TYPEC_INTR_EN_CFG_1_MASK, 0);
| ^~~~
vim +/qcom_pmic_typec_bh_work +86 drivers/usb/typec/qcom-pmic-typec.c
31
32 #define TYPEC_BASE 0x1500
33 #define TYPEC_MISC_STATUS (TYPEC_BASE + 0xb)
34 #define CC_ATTACHED BIT(0)
35 #define CC_ORIENTATION BIT(1)
36 #define SNK_SRC_MODEBIT(6)
37 #define TYPEC_MODE_CFG (TYPEC_BASE + 0x44)
38 #define TYPEC_DISABLE_CMD BIT(0)
39 #define EN_SNK_ONLY BIT(1)
40 #define EN_SRC_ONLY BIT(2)
41 #define EN_TRY_SNK BIT(4)
42 #define TYPEC_VCONN_CONTROL (TYPEC_BASE + 0x46)
43 #define VCONN_EN_SRCBIT(0)
44 #define VCONN_EN_VALBIT(1)
45 #define TYPEC_EXIT_STATE_CFG(TYPEC_BASE + 0x50)
46 #define SEL_SRC_UPPER_REF BIT(2)
47 #define TYPEC_INTR_EN_CFG_1 (TYPEC_BASE + 0x5e)
> 48 #define TYPEC_INTR_EN_CFG_1_MASKGENMASK(0, 7)
49
50 struct qcom_pmic_typec {
51 struct device *dev;
52 struct fwnode_handle*fwnode;
53 struct regmap *regmap;
54 struct work_struct bh_work;
55
56 struct typec_capability *cap;
57 struct typec_port *port;
58 struct usb_role_switch *role_sw;
59
60 struct regulator_desc usb_vbus_rdesc;
61 struct regulator_dev *usb_vbus_reg;
62 };
63
64 static int qcom_pmic_typec_vbus_enable(struct qcom_pmic_typec *qcom_usb)
65 {
66 int rc;
67
68 rc = regmap_update_bits(qcom_usb->regmap, CMD_OTG, OTG_EN,
OTG_EN);
69 if (rc)
70 dev_err(qcom_usb->dev, "failed to update OTG_CTL\n");
71
72 return rc;
73 }
74
75 static int qcom_pmic_typec_vbus_disable(struc
Re: [PATCH v4 0/4] Fix some issues about kmod
On Mon, May 11, 2020 at 12:28 PM Luis Chamberlain wrote: > > On Mon, May 11, 2020 at 08:59:37PM +0800, Tiezhu Yang wrote: > > Hi, > > > > Could you please apply the following three patches? > > > > [v4,1/4] selftests: kmod: Use variable NAME in kmod_test_0001() > > https://lore.kernel.org/patchwork/patch/1227980/ > > > > [v4,2/4] kmod: Remove redundant "be an" in the comment > > https://lore.kernel.org/patchwork/patch/1227982/ > > > > [v4,4/4] test_kmod: Avoid potential double free in trigger_config_run_type() > > https://lore.kernel.org/patchwork/patch/1227978/ > > Andrew, > > These 3 patches should be fine. > > I am re-working a replacement proper fix for patch #3, that requires a > change to the umh. I'll try to iron this out today. I'll pick these up, and run tests now that I have a finalized solution in place for the patch replacement I mentioned which was needed. Sorry this took so long, but I am glad I took my time. I'll post soon after I test the new fix. Luis
[PATCH] usb/gadget/function: introduce Built-in CDROM support
Introduce Built-In CDROM (BICR) support.
This feature depends on USB_CONFIGFS_MASS_STORAGE option.
1. Some settings and new function is introduced for BICR.
2. Some work around for adapting Android settings is intorduced as well.
Signed-off-by: Justin Hsieh
Signed-off-by: Hakieyin Hsieh
Signed-off-by: Macpaul Lin
---
drivers/usb/gadget/Kconfig | 16 +++
drivers/usb/gadget/function/f_mass_storage.c | 49 +++-
drivers/usb/gadget/function/f_mass_storage.h | 5 +-
drivers/usb/gadget/function/storage_common.c | 23 +
4 files changed, 90 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/gadget/Kconfig b/drivers/usb/gadget/Kconfig
index 4dc4d48fe6a6..686ba01bedb5 100644
--- a/drivers/usb/gadget/Kconfig
+++ b/drivers/usb/gadget/Kconfig
@@ -188,6 +188,9 @@ config USB_F_RNDIS
config USB_F_MASS_STORAGE
tristate
+config USB_F_BICR
+ tristate
+
config USB_F_FS
tristate
@@ -357,6 +360,19 @@ config USB_CONFIGFS_MASS_STORAGE
device (in much the same way as the "loop" device driver),
specified as a module parameter or sysfs option.
+config USB_CONFIGFS_BICR
+ bool "Built-In CDROM emulation"
+ depends on USB_CONFIGFS
+ depends on BLOCK
+ depends on USB_CONFIGFS_MASS_STORAGE
+ select USB_F_BICR
+ help
+ The Build-In CDROM Gadget acts as a CDROM emulation disk drive.
+ It is based on kernel option "USB_CONFIGFS_MASS_STORAGE".
+ As its storage repository it can use a regular file or a block
+ device (in much the same way as the "loop" device driver),
+ specified as a module parameter or sysfs option.
+
config USB_CONFIGFS_F_LB_SS
bool "Loopback and sourcesink function (for testing)"
depends on USB_CONFIGFS
diff --git a/drivers/usb/gadget/function/f_mass_storage.c
b/drivers/usb/gadget/function/f_mass_storage.c
index 33c2264a0e35..9de1cd465635 100644
--- a/drivers/usb/gadget/function/f_mass_storage.c
+++ b/drivers/usb/gadget/function/f_mass_storage.c
@@ -315,6 +315,9 @@ struct fsg_common {
void*private_data;
char inquiry_string[INQUIRY_STRING_LEN];
+
+ /* For build-in CDROM */
+ u8 bicr;
};
struct fsg_dev {
@@ -369,6 +372,10 @@ static void set_bulk_out_req_length(struct fsg_common
*common,
if (rem > 0)
length += common->bulk_out_maxpacket - rem;
bh->outreq->length = length;
+
+ /* some USB 2.0 hardware requires this setting */
+ if (IS_ENABLED(USB_CONFIGFS_BICR))
+ bh->outreq->short_not_ok = 1;
}
@@ -527,7 +534,16 @@ static int fsg_setup(struct usb_function *f,
w_length != 1)
return -EDOM;
VDBG(fsg, "get max LUN\n");
- *(u8 *)req->buf = _fsg_common_get_max_lun(fsg->common);
+ if (IS_ENABLED(USB_CONFIGFS_BICR) && fsg->common->bicr) {
+ /*
+* When Built-In CDROM is enabled,
+* we share only one LUN.
+*/
+ *(u8 *)req->buf = 0;
+ } else {
+ *(u8 *)req->buf = _fsg_common_get_max_lun(fsg->common);
+ }
+ INFO(fsg, "get max LUN = %d\n", *(u8 *)req->buf);
/* Respond with data/status */
req->length = min((u16)1, w_length);
@@ -1329,7 +1345,7 @@ static int do_start_stop(struct fsg_common *common)
}
/* Are we allowed to unload the media? */
- if (curlun->prevent_medium_removal) {
+ if (!curlun->nofua && curlun->prevent_medium_removal) {
LDBG(curlun, "unload attempt prevented\n");
curlun->sense_data = SS_MEDIUM_REMOVAL_PREVENTED;
return -EINVAL;
@@ -2692,6 +2708,7 @@ int fsg_common_set_cdev(struct fsg_common *common,
common->ep0 = cdev->gadget->ep0;
common->ep0req = cdev->req;
common->cdev = cdev;
+ common->bicr = 0;
us = usb_gstrings_attach(cdev, fsg_strings_array,
ARRAY_SIZE(fsg_strings));
@@ -2895,6 +2912,33 @@ static void fsg_common_release(struct fsg_common *common)
kfree(common);
}
+#ifdef USB_CONFIGFS_BICR
+ssize_t fsg_bicr_show(struct fsg_common *common, char *buf)
+{
+ return sprintf(buf, "%d\n", common->bicr);
+}
+
+ssize_t fsg_bicr_store(struct fsg_common *common, const char *buf, size_t size)
+{
+ int ret;
+
+ ret = kstrtou8(buf, 10, >bicr);
+ if (ret)
+ return -EINVAL;
+
+ /* Set Lun[0] is a CDROM when enable bicr.*/
+ if (!strcmp(buf, "1"))
+ common->luns[0]->cdrom = 1;
+ else {
+ common->luns[0]->cdrom = 0;
+ common->luns[0]->blkbits = 0;
+ common->luns[0]->blksize = 0;
+ common->luns[0]->num_sectors = 0;
+
Re: [PATCH 2/2] clk: bcm63xx-gate: add BCM6318 support
On 6/9/2020 4:30 AM, Álvaro Fernández Rojas wrote:
> +static const struct clk_bcm63xx_table_entry bcm6318_clocks[] = {
> + { .name = "adsl_asb", .bit = 0, },
> + { .name = "usb_asb", .bit = 1, },
> + { .name = "mips_asb", .bit = 2, },
> + { .name = "pcie_asb", .bit = 3, },
> + { .name = "phymips_asb", .bit = 4, },
> + { .name = "robosw_asb", .bit = 5, },
> + { .name = "sar_asb", .bit = 6, },
> + { .name = "sdr_asb", .bit = 7, },
> + { .name = "swreg_asb", .bit = 8, },
> + { .name = "periph_asb", .bit = 9, },
> + { .name = "cpubus160", .bit = 10, },
> + { .name = "adsl", .bit = 11, },
> + { .name = "sar124", .bit = 12, },
Nit: this should be sar125
> + { .name = "mips", .bit = 13, .flags = CLK_IS_CRITICAL, },
> + { .name = "pcie", .bit = 14, },
> + { .name = "robosw250", .bit = 16, },
> + { .name = "robosw025", .bit = 17, },
> + { .name = "sdr", .bit = 19, .flags = CLK_IS_CRITICAL, },
> + { .name = "usb", .bit = 20, },
This should probably be "usbd" to indicate this is the USB device clock
(not host)
With that fixed:
Reviewed-by: Florian Fainelli
--
Florian
Re: [PATCH 1/3] usb: typec: Add QCOM PMIC typec detection driver
Hi,
Wesley Cheng 于2020年6月10日周三 上午5:00写道：
>
> The QCOM SPMI typec driver handles the role and orientation detection, and
> notifies client drivers using the USB role switch framework. It registers
> as a typec port, so orientation can be communicated using the typec switch
> APIs. The driver also registers the VBUS output regulator, so client
> drivers can enable the VBUS source when acting as a source/host.
>
> Signed-off-by: Wesley Cheng
> ---
> drivers/usb/typec/Kconfig | 11 ++
> drivers/usb/typec/Makefile | 1 +
> drivers/usb/typec/qcom-pmic-typec.c | 278
>
> 3 files changed, 290 insertions(+)
> create mode 100644 drivers/usb/typec/qcom-pmic-typec.c
>
> diff --git a/drivers/usb/typec/Kconfig b/drivers/usb/typec/Kconfig
> index 559dd06..8de2520 100644
> --- a/drivers/usb/typec/Kconfig
> +++ b/drivers/usb/typec/Kconfig
> @@ -73,6 +73,17 @@ config TYPEC_TPS6598X
> If you choose to build this driver as a dynamically linked module,
> the
> module will be called tps6598x.ko.
>
> +config TYPEC_QCOM_PMIC
> + tristate "Qualcomm PMIC USB typec driver"
> + depends on ARCH_QCOM
> + help
> + Driver for supporting role switch over the Qualcomm PMIC. This will
> + handle the type C role and orientation detection reported by the
> QCOM
> + PMIC if the PMIC has the capability to handle type C detection.
> +
> + It will also enable the VBUS output to connected devices when a
> + DFP connection is made.
> +
> source "drivers/usb/typec/mux/Kconfig"
>
> source "drivers/usb/typec/altmodes/Kconfig"
> diff --git a/drivers/usb/typec/Makefile b/drivers/usb/typec/Makefile
> index 7753a5c3..cceffd9 100644
> --- a/drivers/usb/typec/Makefile
> +++ b/drivers/usb/typec/Makefile
> @@ -6,4 +6,5 @@ obj-$(CONFIG_TYPEC_TCPM)+= tcpm/
> obj-$(CONFIG_TYPEC_UCSI) += ucsi/
> obj-$(CONFIG_TYPEC_HD3SS3220) += hd3ss3220.o
> obj-$(CONFIG_TYPEC_TPS6598X) += tps6598x.o
> +obj-$(CONFIG_TYPEC_QCOM_PMIC) += qcom-pmic-typec.o
> obj-$(CONFIG_TYPEC)+= mux/
> diff --git a/drivers/usb/typec/qcom-pmic-typec.c
> b/drivers/usb/typec/qcom-pmic-typec.c
> new file mode 100644
> index 000..ce6319c
> --- /dev/null
> +++ b/drivers/usb/typec/qcom-pmic-typec.c
> @@ -0,0 +1,278 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (c) 2020, The Linux Foundation. All rights reserved.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#define DCDC_BASE 0x1100
> +#define CMD_OTG(DCDC_BASE + 0x40)
> +#define OTG_EN BIT(0)
> +#define OTG_CFG(DCDC_BASE + 0x53)
> +#define OTG_EN_SRC_CFG BIT(1)
> +
> +#define USB_BASE 0x1300
> +#define TYPE_C_CFG_REG (USB_BASE + 0x58)
> +#define BC12_START_ON_CC BIT(7)
> +
> +#define TYPEC_BASE 0x1500
> +#define TYPEC_MISC_STATUS (TYPEC_BASE + 0xb)
> +#define CC_ATTACHEDBIT(0)
> +#define CC_ORIENTATION BIT(1)
> +#define SNK_SRC_MODE BIT(6)
> +#define TYPEC_MODE_CFG (TYPEC_BASE + 0x44)
> +#define TYPEC_DISABLE_CMD BIT(0)
> +#define EN_SNK_ONLYBIT(1)
> +#define EN_SRC_ONLYBIT(2)
> +#define EN_TRY_SNK BIT(4)
> +#define TYPEC_VCONN_CONTROL(TYPEC_BASE + 0x46)
> +#define VCONN_EN_SRC BIT(0)
> +#define VCONN_EN_VAL BIT(1)
> +#define TYPEC_EXIT_STATE_CFG (TYPEC_BASE + 0x50)
> +#define SEL_SRC_UPPER_REF BIT(2)
> +#define TYPEC_INTR_EN_CFG_1(TYPEC_BASE + 0x5e)
> +#define TYPEC_INTR_EN_CFG_1_MASK GENMASK(0, 7)
> +
> +struct qcom_pmic_typec {
> + struct device *dev;
> + struct fwnode_handle*fwnode;
> + struct regmap *regmap;
> + struct work_struct bh_work;
> +
> + struct typec_capability *cap;
> + struct typec_port *port;
> + struct usb_role_switch *role_sw;
> +
> + struct regulator_desc usb_vbus_rdesc;
> + struct regulator_dev *usb_vbus_reg;
> +};
> +
> +static int qcom_pmic_typec_vbus_enable(struct qcom_pmic_typec *qcom_usb)
> +{
> + int rc;
> +
> + rc = regmap_update_bits(qcom_usb->regmap, CMD_OTG, OTG_EN, OTG_EN);
> + if (rc)
> + dev_err(qcom_usb->dev, "failed to update OTG_CTL\n");
> +
> + return rc;
> +}
> +
> +static int qcom_pmic_typec_vbus_disable(struct qcom_pmic_typec *qcom_usb)
> +{
> + int rc;
> +
> + rc = regmap_update_bits(qcom_usb->regmap, CMD_OTG, OTG_EN, 0);
> + if (rc)
> +
Re: [PATCH 4/4] mips: bmips: dts: add BCM6362 power domain support
On 6/9/2020 3:52 AM, Álvaro Fernández Rojas wrote: > BCM6362 SoCs have a power domain controller to enable/disable certain > components in order to save power. > > Signed-off-by: Álvaro Fernández Rojas Acked-by: Florian Fainelli -- Florian
RE: [PATCH v9 0/5] Add MMC software queue support
> -Original Message- > From: Baolin Wang [mailto:baolin.wa...@gmail.com] > Sent: 2020年6月8日 19:54 > To: BOUGH CHEN > Cc: Ulf Hansson ; Adrian Hunter > ; Asutosh Das ; Orson > Zhai ; Chunyan Zhang ; Arnd > Bergmann ; Linus Walleij ; Baolin > Wang ; linux-...@vger.kernel.org; Linux Kernel > Mailing List ; dl-linux-imx > Subject: Re: [PATCH v9 0/5] Add MMC software queue support > > Hi Haibo. > > On Mon, Jun 8, 2020 at 2:35 PM BOUGH CHEN wrote: > > > > > -Original Message- > > > From: linux-mmc-ow...@vger.kernel.org > > > [mailto:linux-mmc-ow...@vger.kernel.org] On Behalf Of Baolin Wang > > > Sent: 2020年2月19日 9:35 > > > To: Ulf Hansson > > > Cc: Adrian Hunter ; Asutosh Das > > > ; Orson Zhai ; > Chunyan > > > Zhang ; Arnd Bergmann ; Linus > > > Walleij ; Baolin Wang > > > ; linux-...@vger.kernel.org; Linux Kernel > > > Mailing List > > > Subject: Re: [PATCH v9 0/5] Add MMC software queue support > > > > > > On Wed, Feb 19, 2020 at 7:38 AM Ulf Hansson > > > wrote: > > > > > > > > On Wed, 12 Feb 2020 at 05:14, Baolin Wang > > > wrote: > > > > > > > > > > Hi All, > > > > > > > > > > Now the MMC read/write stack will always wait for previous > > > > > request is completed by mmc_blk_rw_wait(), before sending a new > > > > > request to hardware, or queue a work to complete request, that > > > > > will bring context switching overhead, especially for high I/O > > > > > per second rates, to affect the IO performance. > > > > > > > > > > Thus this patch set will introduce the MMC software command > > > > > queue support based on command queue engine's interfaces, and > > > > > set the queue depth as 64 to allow more requests can be be > > > > > prepared, merged and inserted into IO scheduler, but we only > > > > > allow 2 requests in flight, that is enough to let the irq > > > > > handler always trigger the next request without a context switch, as > well as avoiding a long latency. > > > > > > > > > > Moreover we can expand the MMC software queue interface to > > > > > support MMC packed request or packed command instead of adding > > > > > new interfaces, according to previosus discussion. > > > > > > > > > > Below are some comparison data with fio tool. The fio command I > > > > > used is like below with changing the '--rw' parameter and > > > > > enabling the direct IO flag to measure the actual hardware > > > > > transfer speed in 4K block > > > size. > > > > > > > > > > ./fio --filename=/dev/mmcblk0p30 --direct=1 --iodepth=20 > > > > > --rw=read --bs=4K --size=1G --group_reporting --numjobs=20 > > > > > --name=test_read > > > > > > > > > > My eMMC card working at HS400 Enhanced strobe mode: > > > > > [2.229856] mmc0: new HS400 Enhanced strobe MMC card at > address > > > 0001 > > > > > [2.237566] mmcblk0: mmc0:0001 HBG4a2 29.1 GiB > > > > > [2.242621] mmcblk0boot0: mmc0:0001 HBG4a2 partition 1 4.00 > MiB > > > > > [2.249110] mmcblk0boot1: mmc0:0001 HBG4a2 partition 2 4.00 > MiB > > > > > [2.255307] mmcblk0rpmb: mmc0:0001 HBG4a2 partition 3 4.00 > MiB, > > > chardev (248:0) > > > > > > > > > > 1. Without MMC software queue > > > > > I tested 5 times for each case and output a average speed. > > > > > > > > > > 1) Sequential read: > > > > > Speed: 59.4MiB/s, 63.4MiB/s, 57.5MiB/s, 57.2MiB/s, 60.8MiB/s > > > > > Average > > > > > speed: 59.66MiB/s > > > > > > > > > > 2) Random read: > > > > > Speed: 26.9MiB/s, 26.9MiB/s, 27.1MiB/s, 27.1MiB/s, 27.2MiB/s > > > > > Average > > > > > speed: 27.04MiB/s > > > > > > > > > > 3) Sequential write: > > > > > Speed: 71.6MiB/s, 72.5MiB/s, 72.2MiB/s, 64.6MiB/s, 67.5MiB/s > > > > > Average > > > > > speed: 69.68MiB/s > > > > > > > > > > 4) Random write: > > > > > Speed: 36.3MiB/s, 35.4MiB/s, 38.6MiB/s, 34MiB/s, 35.5MiB/s > > > > > Average > > > > > speed: 35.96MiB/s > > > > > > > > > > 2. With MMC software queue > > > > > I tested 5 times for each case and output a average speed. > > > > > > > > > > 1) Sequential read: > > > > > Speed: 59.2MiB/s, 60.4MiB/s, 63.6MiB/s, 60.3MiB/s, 59.9MiB/s > > > > > Average > > > > > speed: 60.68MiB/s > > > > > > > > > > 2) Random read: > > > > > Speed: 31.3MiB/s, 31.4MiB/s, 31.5MiB/s, 31.3MiB/s, 31.3MiB/s > > > > > Average > > > > > speed: 31.36MiB/s > > > > > > > > > > 3) Sequential write: > > > > > Speed: 71MiB/s, 71.8MiB/s, 72.3MiB/s, 72.2MiB/s, 71MiB/s Average > > > > > speed: 71.66MiB/s > > > > > > > > > > 4) Random write: > > > > > Speed: 68.9MiB/s, 68.7MiB/s, 68.8MiB/s, 68.6MiB/s, 68.8MiB/s > > > > > Average > > > > > speed: 68.76MiB/s > > > > > > > > > > Form above data, we can see the MMC software queue can help to > > > > > improve some performance obviously for random read and write, > > > > > though no obvious improvement for sequential read and write. > > > > > > > > > > Any comments are welcome. Thanks a lot. > > > > > > > > > Hi Baolin, > > > > I refer to your code, and add the software queue support on i.MX based on > the Linux next-20200602, but unfortunately, I see an obvious
Re: [PATCH] scsi: ufs: Bump supported UFS HCI version to 3.0
Avri: Please review!
> UFS HCI 3.0 versions are being used in Qcom SM8250 based boards. Hence,
> adding it to the list of supported versions.
>
> I don't have the exact information of the additional registers supported
> in version 3.0. Hence the change just adds 0x300 to the list of supported
> versions to remove the below warning:
>
> "ufshcd-qcom 1d84000.ufshc: invalid UFS version 0x300"
>
> Signed-off-by: Manivannan Sadhasivam
> ---
> drivers/scsi/ufs/ufshci.h | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/scsi/ufs/ufshci.h b/drivers/scsi/ufs/ufshci.h
> index c2961d37cc1c..f2ee81669b00 100644
> --- a/drivers/scsi/ufs/ufshci.h
> +++ b/drivers/scsi/ufs/ufshci.h
> @@ -104,6 +104,7 @@ enum {
> UFSHCI_VERSION_11 = 0x00010100, /* 1.1 */
> UFSHCI_VERSION_20 = 0x0200, /* 2.0 */
> UFSHCI_VERSION_21 = 0x0210, /* 2.1 */
> + UFSHCI_VERSION_30 = 0x0300, /* 3.0 */
> };
>
> /*
--
Martin K. Petersen Oracle Linux Engineering
Re: [PATCH 2/2] arm-nommu: Add use_reserved_mem() to check if device support reserved memory
Hi Vladimir, I tested your changes, it's working fine on stm32f429-disco(armv7m, without cache) board. you can submit a separate patch for dma-direct support on non-mmu platform, i will drop mine. thanks. best regards. Dillon, On Wed, Jun 10, 2020 at 1:34 AM Christoph Hellwig wrote: > > On Tue, Jun 09, 2020 at 05:25:04PM +0100, Vladimir Murzin wrote: > > Even though commit mentions ARM, I do not see how mmap would continue > > to work for NOMMU with dma-direct. ARM NOMMU needs it's own DMA operations > > only in cases where caches are implemented or active, in other cases it > > fully relies on dma-direct. > > > It looks to me that we either should provide NOMMU variant for mmap in > > dma/direct or (carefully) fix dma/mapping. > > I think dma-direct is the right place, the common helpers in > dma/mapping.c are basically the red headed stepchilds for misc > IOMMU drivers not covered by dma-iommu only. Yes, thanks Christoph's input.
Re: [PATCH 1/2] dt-bindings: clock: bcm63xx: add 6318 gated clock bindings
On 6/9/2020 4:30 AM, Álvaro Fernández Rojas wrote: > Add BCM6318 to the binding documentation for the gated clock controllers found > on BCM63xx SoCs. > > Signed-off-by: Álvaro Fernández Rojas Reviewed-by: Florian Fainelli -- Florian
Re: [PATCH] clk: bcm63xx-gate: fix last clock availability
On 6/9/2020 4:08 AM, Álvaro Fernández Rojas wrote:
> In order to make the last clock available, maxbit has to be set to the
> highest bit value plus 1.
>
> Fixes: 1c099779c1e2 ("clk: add BCM63XX gated clock controller driver")
> Signed-off-by: Álvaro Fernández Rojas
Reviewed-by: Florian Fainelli
--
Florian
Re: [PATCH 4/4] mips: bmips: dts: add BCM6362 power domain support
On 6/9/2020 3:52 AM, Álvaro Fernández Rojas wrote: > BCM6362 SoCs have a power domain controller to enable/disable certain > components in order to save power. > > Signed-off-by: Álvaro Fernández Rojas Acked-by: Florian Fainelli -- Florian
