August 2020 - Linux-stable-mirror

[PATCH] drm/amdgpu: fix ordering of psp suspend

by Alex Deucher

The ordering of psp_tmr_terminate() and psp_asd_unload() got reversed when the patches were applied to stable. Fixes: 22ff658396b446 ("drm/amdgpu: asd function needs to be unloaded in suspend phase") Fixes: 2c41c968c6f648 ("drm/amdgpu: add TMR destory function for psp") Signed-off-by: Alex Deucher <alexander.deucher(a)amd.com> Cc: stable(a)vger.kernel.org # 5.7.x Cc: Huang Rui <ray.huang(a)amd.com> --- drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c index 3c6f60c5b1a5..088f43ebdceb 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c @@ -1679,15 +1679,15 @@ static int psp_suspend(void *handle) } } - ret = psp_tmr_terminate(psp); + ret = psp_asd_unload(psp); if (ret) { - DRM_ERROR("Falied to terminate tmr\n"); + DRM_ERROR("Failed to unload asd\n"); return ret; } - ret = psp_asd_unload(psp); + ret = psp_tmr_terminate(psp); if (ret) { - DRM_ERROR("Failed to unload asd\n"); + DRM_ERROR("Falied to terminate tmr\n"); return ret; } -- 2.25.4

4 years, 5 months

2
4
0 0

stable-rc/linux-4.4.y baseline: 107 runs, 6 regressions (v4.4.232-32-g22cd589cd66a)

by kernelci.org bot

stable-rc/linux-4.4.y baseline: 107 runs, 6 regressions (v4.4.232-32-g22cd589cd66a) Regressions Summary ------------------- platform | arch | lab | compiler | defconfig | results -----------------+--------+--------------+----------+---------------------+-------- omap3-beagle-xm | arm | lab-baylibre | gcc-8 | omap2plus_defconfig | 2/5 qemu_i386 | i386 | lab-baylibre | gcc-8 | i386_defconfig | 0/1 qemu_i386-uefi | i386 | lab-baylibre | gcc-8 | i386_defconfig | 0/1 qemu_x86_64 | x86_64 | lab-baylibre | gcc-8 | x86_64_defconfig | 0/1 qemu_x86_64-uefi | x86_64 | lab-baylibre | gcc-8 | x86_64_defconfig | 0/1 Details: https://kernelci.org/test/job/stable-rc/branch/linux-4.4.y/kernel/v4.4.232-… Test: baseline Tree: stable-rc Branch: linux-4.4.y Describe: v4.4.232-32-g22cd589cd66a URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git SHA: 22cd589cd66a3d9cc765d57003fe1deaff256b1f Test Regressions ---------------- platform | arch | lab | compiler | defconfig | results -----------------+--------+--------------+----------+---------------------+-------- omap3-beagle-xm | arm | lab-baylibre | gcc-8 | omap2plus_defconfig | 2/5 Details: https://kernelci.org/test/plan/id/5f2bd3054e39d34dc652c1be Results: 2 PASS, 2 FAIL, 1 SKIP Full config: omap2plus_defconfig Compiler: gcc-8 (arm-linux-gnueabihf-gcc (Debian 8.3.0-2) 8.3.0) Plain log: https://storage.kernelci.org//stable-rc/linux-4.4.y/v4.4.232-32-g22cd589cd6… HTML log: https://storage.kernelci.org//stable-rc/linux-4.4.y/v4.4.232-32-g22cd589cd6… Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/kci-2020.05/armel/basel… * baseline.dmesg.crit: https://kernelci.org/test/case/id/5f2bd3054e39d34dc652c1c1 new failure (last pass: v4.4.232-30-g52247eb98ebe) 1 lines* baseline.dmesg.emerg: https://kernelci.org/test/case/id/5f2bd3054e39d34dc652c1c3 new failure (last pass: v4.4.232-30-g52247eb98ebe) 28 lines platform | arch | lab | compiler | defconfig | results -----------------+--------+--------------+----------+---------------------+-------- qemu_i386 | i386 | lab-baylibre | gcc-8 | i386_defconfig | 0/1 Details: https://kernelci.org/test/plan/id/5f2bf8238a986b218552c1b3 Results: 0 PASS, 1 FAIL, 0 SKIP Full config: i386_defconfig Compiler: gcc-8 (gcc (Debian 8.3.0-6) 8.3.0) Plain log: https://storage.kernelci.org//stable-rc/linux-4.4.y/v4.4.232-32-g22cd589cd6… HTML log: https://storage.kernelci.org//stable-rc/linux-4.4.y/v4.4.232-32-g22cd589cd6… Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/kci-2020.05/x86/baselin… * baseline.login: https://kernelci.org/test/case/id/5f2bf8238a986b218552c1b4 failing since 2 days (last pass: v4.4.232, first fail: v4.4.232-33-g191818eb5a46) platform | arch | lab | compiler | defconfig | results -----------------+--------+--------------+----------+---------------------+-------- qemu_i386-uefi | i386 | lab-baylibre | gcc-8 | i386_defconfig | 0/1 Details: https://kernelci.org/test/plan/id/5f2bf8108a986b218552c1b0 Results: 0 PASS, 1 FAIL, 0 SKIP Full config: i386_defconfig Compiler: gcc-8 (gcc (Debian 8.3.0-6) 8.3.0) Plain log: https://storage.kernelci.org//stable-rc/linux-4.4.y/v4.4.232-32-g22cd589cd6… HTML log: https://storage.kernelci.org//stable-rc/linux-4.4.y/v4.4.232-32-g22cd589cd6… Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/kci-2020.05/x86/baselin… * baseline.login: https://kernelci.org/test/case/id/5f2bf8108a986b218552c1b1 failing since 2 days (last pass: v4.4.232, first fail: v4.4.232-33-g191818eb5a46) platform | arch | lab | compiler | defconfig | results -----------------+--------+--------------+----------+---------------------+-------- qemu_x86_64 | x86_64 | lab-baylibre | gcc-8 | x86_64_defconfig | 0/1 Details: https://kernelci.org/test/plan/id/5f2bf77cf44ce540c552c1a9 Results: 0 PASS, 1 FAIL, 0 SKIP Full config: x86_64_defconfig Compiler: gcc-8 (gcc (Debian 8.3.0-6) 8.3.0) Plain log: https://storage.kernelci.org//stable-rc/linux-4.4.y/v4.4.232-32-g22cd589cd6… HTML log: https://storage.kernelci.org//stable-rc/linux-4.4.y/v4.4.232-32-g22cd589cd6… Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/kci-2020.05/x86/baselin… * baseline.login: https://kernelci.org/test/case/id/5f2bf77cf44ce540c552c1aa failing since 2 days (last pass: v4.4.232, first fail: v4.4.232-33-g191818eb5a46) platform | arch | lab | compiler | defconfig | results -----------------+--------+--------------+----------+---------------------+-------- qemu_x86_64-uefi | x86_64 | lab-baylibre | gcc-8 | x86_64_defconfig | 0/1 Details: https://kernelci.org/test/plan/id/5f2bf6ebca697b064252c1a6 Results: 0 PASS, 1 FAIL, 0 SKIP Full config: x86_64_defconfig Compiler: gcc-8 (gcc (Debian 8.3.0-6) 8.3.0) Plain log: https://storage.kernelci.org//stable-rc/linux-4.4.y/v4.4.232-32-g22cd589cd6… HTML log: https://storage.kernelci.org//stable-rc/linux-4.4.y/v4.4.232-32-g22cd589cd6… Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/kci-2020.05/x86/baselin… * baseline.login: https://kernelci.org/test/case/id/5f2bf6ebca697b064252c1a7 failing since 2 days (last pass: v4.4.232, first fail: v4.4.232-33-g191818eb5a46)

4 years, 5 months

1
0
0 0

[PATCH 1/2] io_uring: set ctx sq/cq entry count earlier

by Jens Axboe

If we hit an earlier error path in io_uring_create(), then we will have accounted memory, but not set ctx->{sq,cq}_entries yet. Then when the ring is torn down in error, we use those values to unaccount the memory. Ensure we set the ctx entries before we're able to hit a potential error path. Cc: stable(a)vger.kernel.org Signed-off-by: Jens Axboe <axboe(a)kernel.dk> --- fs/io_uring.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/fs/io_uring.c b/fs/io_uring.c index 8f96566603f3..0d857f7ca507 100644 --- a/fs/io_uring.c +++ b/fs/io_uring.c @@ -8193,6 +8193,10 @@ static int io_allocate_scq_urings(struct io_ring_ctx *ctx, struct io_rings *rings; size_t size, sq_array_offset; + /* make sure these are sane, as we already accounted them */ + ctx->sq_entries = p->sq_entries; + ctx->cq_entries = p->cq_entries; + size = rings_size(p->sq_entries, p->cq_entries, &sq_array_offset); if (size == SIZE_MAX) return -EOVERFLOW; @@ -8209,8 +8213,6 @@ static int io_allocate_scq_urings(struct io_ring_ctx *ctx, rings->cq_ring_entries = p->cq_entries; ctx->sq_mask = rings->sq_ring_mask; ctx->cq_mask = rings->cq_ring_mask; - ctx->sq_entries = rings->sq_ring_entries; - ctx->cq_entries = rings->cq_ring_entries; size = array_size(sizeof(struct io_uring_sqe), p->sq_entries); if (size == SIZE_MAX) { -- 2.28.0

4 years, 5 months

2
2
0 0

[for-linus][PATCH 2/3] tracing: Use trace_sched_process_free() instead of exit() for pid tracing

by Steven Rostedt

From: "Steven Rostedt (VMware)" <rostedt(a)goodmis.org> On exit, if a process is preempted after the trace_sched_process_exit() tracepoint but before the process is done exiting, then when it gets scheduled in, the function tracers will not filter it properly against the function tracing pid filters. That is because the function tracing pid filters hooks to the sched_process_exit() tracepoint to remove the exiting task's pid from the filter list. Because the filtering happens at the sched_switch tracepoint, when the exiting task schedules back in to finish up the exit, it will no longer be in the function pid filtering tables. This was noticeable in the notrace self tests on a preemptable kernel, as the tests would fail as it exits and preempted after being taken off the notrace filter table and on scheduling back in it would not be in the notrace list, and then the ending of the exit function would trace. The test detected this and would fail. Cc: stable(a)vger.kernel.org Cc: Namhyung Kim <namhyung(a)kernel.org> Fixes: 1e10486ffee0a ("ftrace: Add 'function-fork' trace option") Fixes: c37775d57830a ("tracing: Add infrastructure to allow set_event_pid to follow children" Signed-off-by: Steven Rostedt (VMware) <rostedt(a)goodmis.org> --- kernel/trace/ftrace.c | 4 ++-- kernel/trace/trace_events.c | 4 ++-- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/kernel/trace/ftrace.c b/kernel/trace/ftrace.c index 4e3a5d79c078..76f2dd6fd414 100644 --- a/kernel/trace/ftrace.c +++ b/kernel/trace/ftrace.c @@ -6985,12 +6985,12 @@ void ftrace_pid_follow_fork(struct trace_array *tr, bool enable) if (enable) { register_trace_sched_process_fork(ftrace_pid_follow_sched_process_fork, tr); - register_trace_sched_process_exit(ftrace_pid_follow_sched_process_exit, + register_trace_sched_process_free(ftrace_pid_follow_sched_process_exit, tr); } else { unregister_trace_sched_process_fork(ftrace_pid_follow_sched_process_fork, tr); - unregister_trace_sched_process_exit(ftrace_pid_follow_sched_process_exit, + unregister_trace_sched_process_free(ftrace_pid_follow_sched_process_exit, tr); } } diff --git a/kernel/trace/trace_events.c b/kernel/trace/trace_events.c index f6f55682d3e2..a85effb2373b 100644 --- a/kernel/trace/trace_events.c +++ b/kernel/trace/trace_events.c @@ -538,12 +538,12 @@ void trace_event_follow_fork(struct trace_array *tr, bool enable) if (enable) { register_trace_prio_sched_process_fork(event_filter_pid_sched_process_fork, tr, INT_MIN); - register_trace_prio_sched_process_exit(event_filter_pid_sched_process_exit, + register_trace_prio_sched_process_free(event_filter_pid_sched_process_exit, tr, INT_MAX); } else { unregister_trace_sched_process_fork(event_filter_pid_sched_process_fork, tr); - unregister_trace_sched_process_exit(event_filter_pid_sched_process_exit, + unregister_trace_sched_process_free(event_filter_pid_sched_process_exit, tr); } } -- 2.26.2

4 years, 5 months

1
0
0 0

[for-linus][PATCH 1/3] bootconfig: Fix to find the initargs correctly

by Steven Rostedt

From: Masami Hiramatsu <mhiramat(a)kernel.org> Since the parse_args() stops parsing at '--', bootconfig_params() will never get the '--' as param and initargs_found never be true. In the result, if we pass some init arguments via the bootconfig, those are always appended to the kernel command line with '--' even if the kernel command line already has '--'. To fix this correctly, check the return value of parse_args() and set initargs_found true if the return value is not an error but a valid address. Link: https://lkml.kernel.org/r/159650953285.270383.14822353843556363851.stgit@de… Fixes: f61872bb58a1 ("bootconfig: Use parse_args() to find bootconfig and '--'") Cc: stable(a)vger.kernel.org Reported-by: Arvind Sankar <nivedita(a)alum.mit.edu> Suggested-by: Arvind Sankar <nivedita(a)alum.mit.edu> Signed-off-by: Masami Hiramatsu <mhiramat(a)kernel.org> Signed-off-by: Steven Rostedt (VMware) <rostedt(a)goodmis.org> --- init/main.c | 14 ++++++++------ 1 file changed, 8 insertions(+), 6 deletions(-) diff --git a/init/main.c b/init/main.c index 0ead83e86b5a..883ded3638e5 100644 --- a/init/main.c +++ b/init/main.c @@ -387,8 +387,6 @@ static int __init bootconfig_params(char *param, char *val, { if (strcmp(param, "bootconfig") == 0) { bootconfig_found = true; - } else if (strcmp(param, "--") == 0) { - initargs_found = true; } return 0; } @@ -399,19 +397,23 @@ static void __init setup_boot_config(const char *cmdline) const char *msg; int pos; u32 size, csum; - char *data, *copy; + char *data, *copy, *err; int ret; /* Cut out the bootconfig data even if we have no bootconfig option */ data = get_boot_config_from_initrd(&size, &csum); strlcpy(tmp_cmdline, boot_command_line, COMMAND_LINE_SIZE); - parse_args("bootconfig", tmp_cmdline, NULL, 0, 0, 0, NULL, - bootconfig_params); + err = parse_args("bootconfig", tmp_cmdline, NULL, 0, 0, 0, NULL, + bootconfig_params); - if (!bootconfig_found) + if (IS_ERR(err) || !bootconfig_found) return; + /* parse_args() stops at '--' and returns an address */ + if (err) + initargs_found = true; + if (!data) { pr_err("'bootconfig' found on command line, but no bootconfig found\n"); return; -- 2.26.2

4 years, 5 months

1
0
0 0

Re: [PATCH v6] ext4: fix direct I/O read error for kernel stable rc 4.9

by Greg KH

On Thu, Aug 06, 2020 at 08:04:07PM +0800, 姜迎 wrote: > > > > Hi all, > This patch is used to fix checkpatch error on kernel stable rc 4.9. > I have built pass and tested pass, thanks! Now queued up, thanks! greg k-h

4 years, 5 months

1
0
0 0

[PATCH v6] ext4: fix direct I/O read error for kernel stable rc 4.9

by Jiang Ying

This patch is used to fix ext4 direct I/O read error when the read size is not aligned with block size. Then, I will use a test to explain the error. (1) Make a file that is not aligned with block size: $dd if=/dev/zero of=./test.jar bs=1000 count=3 (2) I wrote a source file named "direct_io_read_file.c" as following: #include <stdio.h> #include <stdlib.h> #include <unistd.h> #include <sys/file.h> #include <sys/types.h> #include <sys/stat.h> #include <string.h> #define BUF_SIZE 1024 int main() { int fd; int ret; unsigned char *buf; ret = posix_memalign((void **)&buf, 512, BUF_SIZE); if (ret) { perror("posix_memalign failed"); exit(1); } fd = open("./test.jar", O_RDONLY | O_DIRECT, 0755); if (fd < 0){ perror("open ./test.jar failed"); exit(1); } do { ret = read(fd, buf, BUF_SIZE); printf("ret=%d\n",ret); if (ret < 0) { perror("write test.jar failed"); } } while (ret > 0); free(buf); close(fd); } (3) Compile the source file: $gcc direct_io_read_file.c -D_GNU_SOURCE (4) Run the test program: $./a.out The result is as following: ret=1024 ret=1024 ret=952 ret=-1 write test.jar failed: Invalid argument. I have tested this program on XFS filesystem, XFS does not have this problem, because XFS use iomap_dio_rw() to do direct I/O read. And the comparing between read offset and file size is done in iomap_dio_rw(), the code is as following: if (pos < size) { retval = filemap_write_and_wait_range(mapping, pos, pos + iov_length(iov, nr_segs) - 1); if (!retval) { retval = mapping->a_ops->direct_IO(READ, iocb, iov, pos, nr_segs); } ... } ...only when "pos < size", direct I/O can be done, or 0 will be return. I have tested the fix patch on Ext4, it is up to the mustard of EINVAL in man2(read) as following: #include <unistd.h> ssize_t read(int fd, void *buf, size_t count); EINVAL fd is attached to an object which is unsuitable for reading; or the file was opened with the O_DIRECT flag, and either the address specified in buf, the value specified in count, or the current file offset is not suitably aligned. So I think this patch can be applied to fix ext4 direct I/O error. However Ext4 introduces direct I/O read using iomap infrastructure on kernel 5.5, the patch is commit <b1b4705d54ab> ("ext4: introduce direct I/O read using iomap infrastructure"), then Ext4 will be the same as XFS, they all use iomap_dio_rw() to do direct I/O read. So this problem does not exist on kernel 5.5 for Ext4. >From above description, we can see this problem exists on all the kernel versions between kernel 3.14 and kernel 5.4. It will cause the Applications to fail to read. For example, when the search service downloads a new full index file, the search engine is loading the previous index file and is processing the search request, it can not use buffer io that may squeeze the previous index file in use from pagecache, so the serch service must use direct I/O read. Please apply this patch on these kernel versions, or please use the method on kernel 5.5 to fix this problem. Fixes: 9fe55eea7e4b ("Fix race when checking i_size on direct i/o read") Reviewed-by: Jan Kara <jack(a)suse.cz> Reviewed-by: Wang Long <wanglong19(a)meituan.com> Signed-off-by: Jiang Ying <jiangying8582(a)126.com> Changes since V5: Fix checkpatch error on kernel stable rc 4.9 based V3. Use "reviewed-by" instead of "Co-developed-by" to fix checkpatch error. Changes since V4: Fix build error on kernel stable rc 4.4 based V3. This patch only for kernel 4.4. Changes since V3: Add the info: this bug could break some application that use the stable kernel releases. Changes since V2: Optimize the description of the commit message and make a variation for the patch, e.g. with: Before: loff_t size; size = i_size_read(inode); After: loff_t size = i_size_read(inode); Changes since V1: Signed-off use real name and add "Fixes:" flag --- fs/ext4/inode.c | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c index d8780e0..ccce89d 100644 --- a/fs/ext4/inode.c +++ b/fs/ext4/inode.c @@ -3575,6 +3575,11 @@ static ssize_t ext4_direct_IO_read(struct kiocb *iocb, struct iov_iter *iter) struct address_space *mapping = iocb->ki_filp->f_mapping; struct inode *inode = mapping->host; ssize_t ret; + loff_t offset = iocb->ki_pos; + loff_t size = i_size_read(inode); + + if (offset >= size) + return 0; /* * Shared inode_lock is enough for us - it protects against concurrent -- 1.8.3.1

4 years, 5 months

1
0
0 0

[PATCH V2] USB: serial: ftdi_sio: add IDs for Xsens Mti USB converter

by Patrick Riphagen

From: Patrick Riphagen <patrick.riphagen(a)xsens.com> The device added has an FTDI chip inside. The device is used to connect Xsens USB Motion Trackers. Cc: stable(a)vger.kernel.org Signed-off-by: Patrick Riphagen <patrick.riphagen(a)xsens.com> --- drivers/usb/serial/ftdi_sio.c | 1 + drivers/usb/serial/ftdi_sio_ids.h | 1 + 2 files changed, 2 insertions(+) diff --git a/drivers/usb/serial/ftdi_sio.c b/drivers/usb/serial/ftdi_sio.c index 9ad44a96dfe3..2c08cad32f1d 100644 --- a/drivers/usb/serial/ftdi_sio.c +++ b/drivers/usb/serial/ftdi_sio.c @@ -713,6 +713,7 @@ static const struct usb_device_id id_table_combined[] = { { USB_DEVICE(XSENS_VID, XSENS_AWINDA_STATION_PID) }, { USB_DEVICE(XSENS_VID, XSENS_CONVERTER_PID) }, { USB_DEVICE(XSENS_VID, XSENS_MTDEVBOARD_PID) }, + { USB_DEVICE(XSENS_VID, XSENS_MTIUSBCONVERTER_PID) }, { USB_DEVICE(XSENS_VID, XSENS_MTW_PID) }, { USB_DEVICE(FTDI_VID, FTDI_OMNI1509) }, { USB_DEVICE(MOBILITY_VID, MOBILITY_USB_SERIAL_PID) }, diff --git a/drivers/usb/serial/ftdi_sio_ids.h b/drivers/usb/serial/ftdi_sio_ids.h index e8373528264c..b5ca17a5967a 100644 --- a/drivers/usb/serial/ftdi_sio_ids.h +++ b/drivers/usb/serial/ftdi_sio_ids.h @@ -160,6 +160,7 @@ #define XSENS_AWINDA_DONGLE_PID 0x0102 #define XSENS_MTW_PID 0x0200 /* Xsens MTw */ #define XSENS_MTDEVBOARD_PID 0x0300 /* Motion Tracker Development Board */ +#define XSENS_MTIUSBCONVERTER_PID 0x0301 /* MTi USB converter */ #define XSENS_CONVERTER_PID 0xD00D /* Xsens USB-serial converter */ /* Xsens devices using FTDI VID */ -- 2.25.1 V2: Added CC to stable, From line to match SoB and version in subject

4 years, 5 months

2
1
0 0

[PATCH] USB: serial: ftdi_sio: add IDs for Xsens Mti USB converter

by Patrick Riphagen

The device added has an FTDI chip inside. The device is used to connect Xsens USB Motion Trackers. Cc: stable(a)vger.kernel.org Signed-off-by: Patrick Riphagen <patrick.riphagen(a)xsens.com> --- drivers/usb/serial/ftdi_sio.c | 1 + drivers/usb/serial/ftdi_sio_ids.h | 1 + 2 files changed, 2 insertions(+) diff --git a/drivers/usb/serial/ftdi_sio.c b/drivers/usb/serial/ftdi_sio.c index 9ad44a96dfe3..2c08cad32f1d 100644 --- a/drivers/usb/serial/ftdi_sio.c +++ b/drivers/usb/serial/ftdi_sio.c @@ -713,6 +713,7 @@ static const struct usb_device_id id_table_combined[] = { { USB_DEVICE(XSENS_VID, XSENS_AWINDA_STATION_PID) }, { USB_DEVICE(XSENS_VID, XSENS_CONVERTER_PID) }, { USB_DEVICE(XSENS_VID, XSENS_MTDEVBOARD_PID) }, + { USB_DEVICE(XSENS_VID, XSENS_MTIUSBCONVERTER_PID) }, { USB_DEVICE(XSENS_VID, XSENS_MTW_PID) }, { USB_DEVICE(FTDI_VID, FTDI_OMNI1509) }, { USB_DEVICE(MOBILITY_VID, MOBILITY_USB_SERIAL_PID) }, diff --git a/drivers/usb/serial/ftdi_sio_ids.h b/drivers/usb/serial/ftdi_sio_ids.h index e8373528264c..b5ca17a5967a 100644 --- a/drivers/usb/serial/ftdi_sio_ids.h +++ b/drivers/usb/serial/ftdi_sio_ids.h @@ -160,6 +160,7 @@ #define XSENS_AWINDA_DONGLE_PID 0x0102 #define XSENS_MTW_PID 0x0200 /* Xsens MTw */ #define XSENS_MTDEVBOARD_PID 0x0300 /* Motion Tracker Development Board */ +#define XSENS_MTIUSBCONVERTER_PID 0x0301 /* MTi USB converter */ #define XSENS_CONVERTER_PID 0xD00D /* Xsens USB-serial converter */ /* Xsens devices using FTDI VID */ -- 2.25.1

4 years, 5 months

2
1
0 0

[PATCH v5] ext4: fix direct I/O read error for kernel stable rc4.4

by Jiang Ying

This patch is used to fix ext4 direct I/O read error when the read size is not aligned with block size. Then, I will use a test to explain the error. (1) Make a file that is not aligned with block size: $dd if=/dev/zero of=./test.jar bs=1000 count=3 (2) I wrote a source file named "direct_io_read_file.c" as following: #include <stdio.h> #include <stdlib.h> #include <unistd.h> #include <sys/file.h> #include <sys/types.h> #include <sys/stat.h> #include <string.h> #define BUF_SIZE 1024 int main() { int fd; int ret; unsigned char *buf; ret = posix_memalign((void **)&buf, 512, BUF_SIZE); if (ret) { perror("posix_memalign failed"); exit(1); } fd = open("./test.jar", O_RDONLY | O_DIRECT, 0755); if (fd < 0){ perror("open ./test.jar failed"); exit(1); } do { ret = read(fd, buf, BUF_SIZE); printf("ret=%d\n",ret); if (ret < 0) { perror("write test.jar failed"); } } while (ret > 0); free(buf); close(fd); } (3) Compile the source file: $gcc direct_io_read_file.c -D_GNU_SOURCE (4) Run the test program: $./a.out The result is as following: ret=1024 ret=1024 ret=952 ret=-1 write test.jar failed: Invalid argument. I have tested this program on XFS filesystem, XFS does not have this problem, because XFS use iomap_dio_rw() to do direct I/O read. And the comparing between read offset and file size is done in iomap_dio_rw(), the code is as following: if (pos < size) { retval = filemap_write_and_wait_range(mapping, pos, pos + iov_length(iov, nr_segs) - 1); if (!retval) { retval = mapping->a_ops->direct_IO(READ, iocb, iov, pos, nr_segs); } ... } ...only when "pos < size", direct I/O can be done, or 0 will be return. I have tested the fix patch on Ext4, it is up to the mustard of EINVAL in man2(read) as following: #include <unistd.h> ssize_t read(int fd, void *buf, size_t count); EINVAL fd is attached to an object which is unsuitable for reading; or the file was opened with the O_DIRECT flag, and either the address specified in buf, the value specified in count, or the current file offset is not suitably aligned. So I think this patch can be applied to fix ext4 direct I/O error. However Ext4 introduces direct I/O read using iomap infrastructure on kernel 5.5, the patch is commit <b1b4705d54ab> ("ext4: introduce direct I/O read using iomap infrastructure"), then Ext4 will be the same as XFS, they all use iomap_dio_rw() to do direct I/O read. So this problem does not exist on kernel 5.5 for Ext4. >From above description, we can see this problem exists on all the kernel versions between kernel 3.14 and kernel 5.4. It will cause the Applications to fail to read. For example, when the search service downloads a new full index file, the search engine is loading the previous index file and is processing the search request, it can not use buffer io that may squeeze the previous index file in use from pagecache, so the serch service must use direct I/O read. Please apply this patch on these kernel versions, or please use the method on kernel 5.5 to fix this problem. Fixes: 9fe55eea7e4b ("Fix race when checking i_size on direct i/o read") Reviewed-by: Jan Kara <jack(a)suse.cz> Reviewed-by: Wang Long <wanglong19(a)meituan.com> Signed-off-by: Jiang Ying <jiangying8582(a)126.com> Changes since V4: Fix build error on kernel stable rc 4.4. This patch only for kernel 4.4. Changes since V3: Add the info: this bug could break some application that use the stable kernel releases. Changes since V2: Optimize the description of the commit message and make a variation for the patch, e.g. with: Before: loff_t size; size = i_size_read(inode); After: loff_t size = i_size_read(inode); Changes since V1: Signed-off use real name and add "Fixes:" flag --- fs/ext4/inode.c | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c index 8e79970..8816016 100644 --- a/fs/ext4/inode.c +++ b/fs/ext4/inode.c @@ -3353,6 +3353,13 @@ static ssize_t ext4_direct_IO(struct kiocb *iocb, struct iov_iter *iter, size_t count = iov_iter_count(iter); ssize_t ret; + if (iov_iter_rw(iter) == READ) { + loff_t size = i_size_read(inode); + + if (offset >= size) + return 0; + } + #ifdef CONFIG_EXT4_FS_ENCRYPTION if (ext4_encrypted_inode(inode) && S_ISREG(inode->i_mode)) return 0; -- 1.8.3.1

4 years, 5 months

2
1
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror August 2020