Re: [PATCH 1/6] Generic radix trees

On Sat, May 26, 2018 at 11:16:42AM +0800, Liu Bo wrote: > > +/* > > + * Returns pointer to the specified byte @offset within @radix, allocating > > it if > > + * necessary - newly allocated slots are always zeroed out: > > + */ > > +void *__genradix_ptr_alloc(struct __genradix *radix, size_t

Re: [PATCH 1/6] Generic radix trees

On Sat, May 26, 2018 at 11:16:42AM +0800, Liu Bo wrote: > > +/* > > + * Returns pointer to the specified byte @offset within @radix, allocating > > it if > > + * necessary - newly allocated slots are always zeroed out: > > + */ > > +void *__genradix_ptr_alloc(struct __genradix *radix, size_t

Re: [PATCH] arm64: dts: hikey: Fix eMMC corruption regression

On Fri, May 25, 2018 at 08:10:47PM -0700, John Stultz wrote: > This patch is a partial revert of commit > abd7d0972a19 ("arm64: dts: hikey: Enable HS200 mode on eMMC") > > which has been causing eMMC corruption on my HiKey board. > > Symptoms usually looked like: > > mmc_host mmc0: Bus speed

Re: [PATCH] arm64: dts: hikey: Fix eMMC corruption regression

On Fri, May 25, 2018 at 08:10:47PM -0700, John Stultz wrote: > This patch is a partial revert of commit > abd7d0972a19 ("arm64: dts: hikey: Enable HS200 mode on eMMC") > > which has been causing eMMC corruption on my HiKey board. > > Symptoms usually looked like: > > mmc_host mmc0: Bus speed

Re: linux-next: manual merge of the staging tree with the v4l-dvb tree

Hi Mauro, On Thu, 17 May 2018 07:06:57 -0300 Mauro Carvalho Chehab wrote: > > What do you use in order to check it? Maybe we could have some git > hook running such check, in order to prevent merging patches without > the right SOBs. I run the script below on the

Re: linux-next: manual merge of the staging tree with the v4l-dvb tree

Hi Mauro, On Thu, 17 May 2018 07:06:57 -0300 Mauro Carvalho Chehab wrote: > > What do you use in order to check it? Maybe we could have some git > hook running such check, in order to prevent merging patches without > the right SOBs. I run the script below on the range of new commits each time

Re: [PATCH 0/3] Dts nodes for Keystone2 hw_rng driver

On 5/24/18 6:12 AM, Vitaly Andrianov wrote: This series adds dts nodes for Keystone2 hw_rng driver Vitaly Andrianov (3): ARM: dts: k2hk: add dts node for k2hk hw_rng driver ARM: dts: k2l: add dts node for k2l hw_rng driver ARM: dts: k2e: add dts node for k2e hw_rng driver Looks good.

Re: [PATCH 0/3] Dts nodes for Keystone2 hw_rng driver

On 5/24/18 6:12 AM, Vitaly Andrianov wrote: This series adds dts nodes for Keystone2 hw_rng driver Vitaly Andrianov (3): ARM: dts: k2hk: add dts node for k2hk hw_rng driver ARM: dts: k2l: add dts node for k2l hw_rng driver ARM: dts: k2e: add dts node for k2e hw_rng driver Looks good.

arch/powerpc/kernel/head_32.S:1106: Error: missing operand

Dear Linux folks, Building the configuration created with `make tinyconfig` on the Power 8 system IBM S822LC with Ubuntu 18.04 fails with the error below. ``` $ git describe --dirty v4.17-rc6-296-gbc2dbc5420e8 $ git log --oneline -1 bc2dbc5420e8 (HEAD -> master, origin/master, origin/HEAD)

arch/powerpc/kernel/head_32.S:1106: Error: missing operand

Dear Linux folks, Building the configuration created with `make tinyconfig` on the Power 8 system IBM S822LC with Ubuntu 18.04 fails with the error below. ``` $ git describe --dirty v4.17-rc6-296-gbc2dbc5420e8 $ git log --oneline -1 bc2dbc5420e8 (HEAD -> master, origin/master, origin/HEAD)

Re: linux-next: Signed-off-by missing for commit in the arm-soc tree

Hi Alexandre, On Tue, 15 May 2018 09:15:23 +0200 Alexandre Torgue wrote: > > On 05/14/2018 11:22 PM, Stephen Rothwell wrote: > > > > Commit > > > >949a0c0dec85 ("ARM: dts: stm32: add USB Host (USBH) support to > > stm32mp157c") > > > > is missing a Signed-off-by

Re: linux-next: Signed-off-by missing for commit in the arm-soc tree

Hi Alexandre, On Tue, 15 May 2018 09:15:23 +0200 Alexandre Torgue wrote: > > On 05/14/2018 11:22 PM, Stephen Rothwell wrote: > > > > Commit > > > >949a0c0dec85 ("ARM: dts: stm32: add USB Host (USBH) support to > > stm32mp157c") > > > > is missing a Signed-off-by from its committer. > >

Re: [PATCH] qcom: cmd-db: enforce CONFIG_OF_RESERVED_MEM dependency

On Fri 25 May 09:08 PDT 2018, Arnd Bergmann wrote: > Without CONFIG_OF_RESERVED_MEM, gcc sees that the global cmd_db_header > variable is never initialized, and through code optimization concludes > that a lot of other code cannot possibly work after that: > > drivers/soc/qcom/cmd-db.c: In

Re: [PATCH] qcom: cmd-db: enforce CONFIG_OF_RESERVED_MEM dependency

On Fri 25 May 09:08 PDT 2018, Arnd Bergmann wrote: > Without CONFIG_OF_RESERVED_MEM, gcc sees that the global cmd_db_header > variable is never initialized, and through code optimization concludes > that a lot of other code cannot possibly work after that: > > drivers/soc/qcom/cmd-db.c: In

Re: linux-next: Signed-off-by missing for commits in the block tree

On 5/25/18 9:50 PM, Stephen Rothwell wrote: > Hi Jens, > > Commits > > 287a63ebbe7c ("nvme: mark the result argument to nvme_complete_async_event > volatile") > 750dde4472e4 ("nvme-pci: simplify nvme_cqe_valid") > d1f06f4ae041 ("nvme-pci: move ->cq_vector == -1 check outside of ->q_lock")

Re: linux-next: Signed-off-by missing for commits in the block tree

On 5/25/18 9:50 PM, Stephen Rothwell wrote: > Hi Jens, > > Commits > > 287a63ebbe7c ("nvme: mark the result argument to nvme_complete_async_event > volatile") > 750dde4472e4 ("nvme-pci: simplify nvme_cqe_valid") > d1f06f4ae041 ("nvme-pci: move ->cq_vector == -1 check outside of ->q_lock")

linux-next: Signed-off-by missing for commits in the block tree

Hi Jens, Commits 287a63ebbe7c ("nvme: mark the result argument to nvme_complete_async_event volatile") 750dde4472e4 ("nvme-pci: simplify nvme_cqe_valid") d1f06f4ae041 ("nvme-pci: move ->cq_vector == -1 check outside of ->q_lock") 1ab0cd6966fc ("nvme-pci: split the nvme queue lock into

linux-next: Signed-off-by missing for commits in the block tree

Hi Jens, Commits 287a63ebbe7c ("nvme: mark the result argument to nvme_complete_async_event volatile") 750dde4472e4 ("nvme-pci: simplify nvme_cqe_valid") d1f06f4ae041 ("nvme-pci: move ->cq_vector == -1 check outside of ->q_lock") 1ab0cd6966fc ("nvme-pci: split the nvme queue lock into

Re: [PATCH] mm-kasan-dont-vfree-nonexistent-vm_area-fix

On Sat, 26 May 2018 11:31:35 +0800 kbuild test robot wrote: > Hi Andrey, > > I love your patch! Yet something to improve: > > [auto build test ERROR on mmotm/master] > [cannot apply to v4.17-rc6] > [if your patch is applied to the wrong git tree, please drop us a note to >

Re: [PATCH] mm-kasan-dont-vfree-nonexistent-vm_area-fix

On Sat, 26 May 2018 11:31:35 +0800 kbuild test robot wrote: > Hi Andrey, > > I love your patch! Yet something to improve: > > [auto build test ERROR on mmotm/master] > [cannot apply to v4.17-rc6] > [if your patch is applied to the wrong git tree, please drop us a note to > help improve the

linux-next: Signed-off-by missing for commits in the rdma tree

Hi all, Commits 116aeb887371 ("iw_cxgb4: provide detailed provider-specific CM_ID information") to 0252f73334f9 ("IB/qib: Fix DMA api warning with debug kernel") are missing a Signed-off-by from their committer. I presume they have been rebased? -- Cheers, Stephen Rothwell

linux-next: Signed-off-by missing for commits in the rdma tree

Hi all, Commits 116aeb887371 ("iw_cxgb4: provide detailed provider-specific CM_ID information") to 0252f73334f9 ("IB/qib: Fix DMA api warning with debug kernel") are missing a Signed-off-by from their committer. I presume they have been rebased? -- Cheers, Stephen Rothwell

Re: [PATCH] mm-kasan-dont-vfree-nonexistent-vm_area-fix

Hi Andrey, I love your patch! Yet something to improve: [auto build test ERROR on mmotm/master] [cannot apply to v4.17-rc6] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url:

Re: [PATCH] mm-kasan-dont-vfree-nonexistent-vm_area-fix

Hi Andrey, I love your patch! Yet something to improve: [auto build test ERROR on mmotm/master] [cannot apply to v4.17-rc6] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url:

Re: [PATCH 1/6] Generic radix trees

Hi Kent, (Add all ML to cc this time.) On Wed, May 23, 2018 at 9:18 AM, Kent Overstreet wrote: > Very simple radix tree implementation that supports storing arbitrary > size entries, up to PAGE_SIZE - upcoming patches will convert existing > flex_array users to

Re: [PATCH 1/6] Generic radix trees

Hi Kent, (Add all ML to cc this time.) On Wed, May 23, 2018 at 9:18 AM, Kent Overstreet wrote: > Very simple radix tree implementation that supports storing arbitrary > size entries, up to PAGE_SIZE - upcoming patches will convert existing > flex_array users to genradixes. The new genradix code

[PATCH] arm64: dts: hikey: Fix eMMC corruption regression

This patch is a partial revert of commit abd7d0972a19 ("arm64: dts: hikey: Enable HS200 mode on eMMC") which has been causing eMMC corruption on my HiKey board. Symptoms usually looked like: mmc_host mmc0: Bus speed (slot 0) = 2480Hz (slot req 40Hz, actual 40HZ div = 31) ...

[PATCH] arm64: dts: hikey: Fix eMMC corruption regression

This patch is a partial revert of commit abd7d0972a19 ("arm64: dts: hikey: Enable HS200 mode on eMMC") which has been causing eMMC corruption on my HiKey board. Symptoms usually looked like: mmc_host mmc0: Bus speed (slot 0) = 2480Hz (slot req 40Hz, actual 40HZ div = 31) ...

Re: [PATCH v2] gpu: drm: gma500: Change return type to vm_fault_t

Hi Souptick, Thank you for the patch! Perhaps something to improve: [auto build test WARNING on drm/drm-next] [also build test WARNING on v4.17-rc6] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url:

Re: [PATCH v2] gpu: drm: gma500: Change return type to vm_fault_t

Hi Souptick, Thank you for the patch! Perhaps something to improve: [auto build test WARNING on drm/drm-next] [also build test WARNING on v4.17-rc6] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url:

Re: [PATCH 12/14] documentation: fpga: move fpga-region.txt to driver-api

On 05/16/2018 04:50 PM, Alan Tull wrote: > Move Documentation/fpga/fpga-region.txt to > driver-api/fpga/fpga-region.rst. Including: > - Add it to driver-api/fpga/index.rst > - Formatting changes to build cleanly as ReST documentation > - Some rewrites for better flow as a ReST doc such as

Re: [PATCH 12/14] documentation: fpga: move fpga-region.txt to driver-api

On 05/16/2018 04:50 PM, Alan Tull wrote: > Move Documentation/fpga/fpga-region.txt to > driver-api/fpga/fpga-region.rst. Including: > - Add it to driver-api/fpga/index.rst > - Formatting changes to build cleanly as ReST documentation > - Some rewrites for better flow as a ReST doc such as

Re: [PATCH 10/14] documentation: fpga: move fpga-mgr.txt to driver-api

On 05/16/2018 04:50 PM, Alan Tull wrote: > Move Documentation/fpga/fpga-mgr.txt to driver-api/fpga/fpga-mgr.rst > and: > - Add to driver-api/fpga/index.rst > - Format changes so documentation builds cleanly. > - Minor rewrites that make the doc flow better as ReST documentation. >- Such as

Re: [PATCH 10/14] documentation: fpga: move fpga-mgr.txt to driver-api

On 05/16/2018 04:50 PM, Alan Tull wrote: > Move Documentation/fpga/fpga-mgr.txt to driver-api/fpga/fpga-mgr.rst > and: > - Add to driver-api/fpga/index.rst > - Format changes so documentation builds cleanly. > - Minor rewrites that make the doc flow better as ReST documentation. >- Such as

Re: [PATCH net-next] bpfilter: fix a build err

On 2018/5/26 0:19, Alexei Starovoitov wrote: > On Fri, May 25, 2018 at 06:17:57PM +0800, YueHaibing wrote: >> gcc-7.3.0 report following err: >> >> HOSTCC net/bpfilter/main.o >> In file included from net/bpfilter/main.c:9:0: >> ./include/uapi/linux/bpf.h:12:10: fatal error: linux/bpf_common.h:

Re: [PATCH net-next] bpfilter: fix a build err

On 2018/5/26 0:19, Alexei Starovoitov wrote: > On Fri, May 25, 2018 at 06:17:57PM +0800, YueHaibing wrote: >> gcc-7.3.0 report following err: >> >> HOSTCC net/bpfilter/main.o >> In file included from net/bpfilter/main.c:9:0: >> ./include/uapi/linux/bpf.h:12:10: fatal error: linux/bpf_common.h:

Re: [PATCH 09/14] Documentation: fpga: move fpga overview to driver-api

On 05/16/2018 04:50 PM, Alan Tull wrote: > Start of moving Documentation/fpga/*.txt to driver-api, including: > - Add new directory driver-api/fpga > - Add new file driver-api/fpga/index.rst > - Add driver-api/fpga to driver-api/index.rst > - Move Documentation/fpga/overview.txt to

Re: [PATCH 09/14] Documentation: fpga: move fpga overview to driver-api

On 05/16/2018 04:50 PM, Alan Tull wrote: > Start of moving Documentation/fpga/*.txt to driver-api, including: > - Add new directory driver-api/fpga > - Add new file driver-api/fpga/index.rst > - Add driver-api/fpga to driver-api/index.rst > - Move Documentation/fpga/overview.txt to

Re: [PATCH v4 19/31] Documentation: kconfig: document a new Kconfig macro language

On 05/16/2018 11:16 PM, Masahiro Yamada wrote: > Add a document for the macro language introduced to Kconfig. > > The motivation of this work is to move the compiler option tests to > Kconfig from Makefile. A number of kernel features require the > compiler support. Enabling such features

Re: [PATCH v4 19/31] Documentation: kconfig: document a new Kconfig macro language

On 05/16/2018 11:16 PM, Masahiro Yamada wrote: > Add a document for the macro language introduced to Kconfig. > > The motivation of this work is to move the compiler option tests to > Kconfig from Makefile. A number of kernel features require the > compiler support. Enabling such features

[PATCH v2] ARM: dts: imx51-zii-rdu1: Make sure SD1_WP is low

Make sure that MX51_PAD_GPIO1_1 does not remain configure as ALT0/SD1_WP (it is out of reset). This is needed because of external pull-up resistor attached to that pad that, when left unchanged, will drive SD1_WP high preventing eSDHC1/eMMC from working correctly. To fix that add a pinmux

[PATCH v2] ARM: dts: imx51-zii-rdu1: Make sure SD1_WP is low

Make sure that MX51_PAD_GPIO1_1 does not remain configure as ALT0/SD1_WP (it is out of reset). This is needed because of external pull-up resistor attached to that pad that, when left unchanged, will drive SD1_WP high preventing eSDHC1/eMMC from working correctly. To fix that add a pinmux

[PATCH] rtc: test: remove obsolete .set_mmss

There is no point in testing .set_mmss versus .set_mmss64 as there are both taking the exact same argument (truncated for set_mmss though). Signed-off-by: Alexandre Belloni --- drivers/rtc/rtc-test.c | 19 ++- 1 file changed, 2 insertions(+), 17

[PATCH] rtc: test: remove obsolete .set_mmss

There is no point in testing .set_mmss versus .set_mmss64 as there are both taking the exact same argument (truncated for set_mmss though). Signed-off-by: Alexandre Belloni --- drivers/rtc/rtc-test.c | 19 ++- 1 file changed, 2 insertions(+), 17 deletions(-) diff --git

Re: [PATCH V2 rdma-next 3/4] RDMA/hns: Add reset process for RoCE in hip08

On 2018/5/25 22:55, Jason Gunthorpe wrote: > On Fri, May 25, 2018 at 01:54:31PM +0800, Wei Hu (Xavier) wrote: >> >> On 2018/5/25 5:31, Jason Gunthorpe wrote: static const struct hnae3_client_ops hns_roce_hw_v2_ops = { .init_instance = hns_roce_hw_v2_init_instance,

Re: [PATCH V2 rdma-next 3/4] RDMA/hns: Add reset process for RoCE in hip08

On 2018/5/25 22:55, Jason Gunthorpe wrote: > On Fri, May 25, 2018 at 01:54:31PM +0800, Wei Hu (Xavier) wrote: >> >> On 2018/5/25 5:31, Jason Gunthorpe wrote: static const struct hnae3_client_ops hns_roce_hw_v2_ops = { .init_instance = hns_roce_hw_v2_init_instance,

Re: [RFC PATCH] f2fs: add fsync_mode=nobarrier for non-atomic files

On 2018/5/26 9:04, Jaegeuk Kim wrote: > For non-atomic files, this patch adds an option to give nobarrier which > doesn't issue flush commands to the device. > > Signed-off-by: Jaegeuk Kim Reviewed-by: Chao Yu Thanks,

[PATCH v3] block/loop: Serialize ioctl operations.

syzbot is reporting NULL pointer dereference [1] which is caused by race condition between ioctl(loop_fd, LOOP_CLR_FD, 0) versus ioctl(other_loop_fd, LOOP_SET_FD, loop_fd) due to traversing other loop devices without holding corresponding locks. syzbot is also reporting circular locking

Re: [RFC PATCH] f2fs: add fsync_mode=nobarrier for non-atomic files

On 2018/5/26 9:04, Jaegeuk Kim wrote: > For non-atomic files, this patch adds an option to give nobarrier which > doesn't issue flush commands to the device. > > Signed-off-by: Jaegeuk Kim Reviewed-by: Chao Yu Thanks,

[PATCH v3] block/loop: Serialize ioctl operations.

syzbot is reporting NULL pointer dereference [1] which is caused by race condition between ioctl(loop_fd, LOOP_CLR_FD, 0) versus ioctl(other_loop_fd, LOOP_SET_FD, loop_fd) due to traversing other loop devices without holding corresponding locks. syzbot is also reporting circular locking

[PATCH V2] cros_ec_keyb: Mark cros_ec_keyb driver as wake enabled device.

Mark cros_ec_keyb has wake enabled by default. If we see a MKBP event related to keyboard, call pm_wakeup_event() to make sure wakeup triggers are accounted to keyb during suspend resume path. Signed-off-by: Ravi Chandra Sadineni --- V2: Marked the ckdev as wake

[PATCH V2] cros_ec_keyb: Mark cros_ec_keyb driver as wake enabled device.

Mark cros_ec_keyb has wake enabled by default. If we see a MKBP event related to keyboard, call pm_wakeup_event() to make sure wakeup triggers are accounted to keyb during suspend resume path. Signed-off-by: Ravi Chandra Sadineni --- V2: Marked the ckdev as wake enabled instead of input

[PATCH] thermal: int340x: Prevent error in reading trip hysteresis attribute

Some of the INT340X devices may not have hysteresis defined in the ACPI definition. In that case reading trip hysteresis results in error. This spams logs of user space utilities. In this case instead of returning error, just return hysteresis as 0, which is correct as there is no hysteresis

[PATCH] thermal: int340x: Prevent error in reading trip hysteresis attribute

Some of the INT340X devices may not have hysteresis defined in the ACPI definition. In that case reading trip hysteresis results in error. This spams logs of user space utilities. In this case instead of returning error, just return hysteresis as 0, which is correct as there is no hysteresis

Re: [PATCH v2 5/6] soc: qcom: rpmh powerdomain driver

Hello Rajendra, On 05/25/2018 03:01 AM, Rajendra Nayak wrote: > The RPMh powerdomain driver aggregates the corner votes from various s/powerdomain/power domain/ This applies to all instances in this patch. "Power domain" seems to be the preferred spelling in the kernel. > consumers for the

Re: [PATCH v2 5/6] soc: qcom: rpmh powerdomain driver

Hello Rajendra, On 05/25/2018 03:01 AM, Rajendra Nayak wrote: > The RPMh powerdomain driver aggregates the corner votes from various s/powerdomain/power domain/ This applies to all instances in this patch. "Power domain" seems to be the preferred spelling in the kernel. > consumers for the

[RFC PATCH] f2fs: add fsync_mode=nobarrier for non-atomic files

For non-atomic files, this patch adds an option to give nobarrier which doesn't issue flush commands to the device. Signed-off-by: Jaegeuk Kim --- Documentation/filesystems/f2fs.txt | 16 +--- fs/f2fs/f2fs.h | 1 + fs/f2fs/file.c

[RFC PATCH] f2fs: add fsync_mode=nobarrier for non-atomic files

For non-atomic files, this patch adds an option to give nobarrier which doesn't issue flush commands to the device. Signed-off-by: Jaegeuk Kim --- Documentation/filesystems/f2fs.txt | 16 +--- fs/f2fs/f2fs.h | 1 + fs/f2fs/file.c | 2 +-

[PATCH v2] f2fs: keep migration IO order in LFS mode

For non-migration IO, we will keep order of data/node blocks' submitting as allocation sequence by sorting IOs in per log io_list list, but for migration IO, it could be out-of-order. In LFS mode, we should keep all IOs including migration IO be ordered, so that this patch fixes to add an

[PATCH v2] f2fs: keep migration IO order in LFS mode

For non-migration IO, we will keep order of data/node blocks' submitting as allocation sequence by sorting IOs in per log io_list list, but for migration IO, it could be out-of-order. In LFS mode, we should keep all IOs including migration IO be ordered, so that this patch fixes to add an

[PATCH] PM / hibernate: Fix oops at snapshot_write().

syzbot is reporting NULL pointer dereference at snapshot_write() [1]. This is because data->handle is zero-cleared by ioctl(SNAPSHOT_FREE). Fix this by checking data_of(data->handle) != NULL before using it. [1] https://syzkaller.appspot.com/bug?id=828a3c71bd344a6de8b6a31233d51a72099f27fd

[PATCH] PM / hibernate: Fix oops at snapshot_write().

syzbot is reporting NULL pointer dereference at snapshot_write() [1]. This is because data->handle is zero-cleared by ioctl(SNAPSHOT_FREE). Fix this by checking data_of(data->handle) != NULL before using it. [1] https://syzkaller.appspot.com/bug?id=828a3c71bd344a6de8b6a31233d51a72099f27fd

[PATCH 1/2] n_tty: Fix stall at n_tty_receive_char_special().

syzbot is reporting stalls at n_tty_receive_char_special() [1]. This is because comparison is not working as expected since ldata->read_head can change at any moment. Mitigate this by explicitly masking with buffer size when checking condition for "while" loops. [1]

[PATCH 1/2] n_tty: Fix stall at n_tty_receive_char_special().

syzbot is reporting stalls at n_tty_receive_char_special() [1]. This is because comparison is not working as expected since ldata->read_head can change at any moment. Mitigate this by explicitly masking with buffer size when checking condition for "while" loops. [1]

[PATCH 2/2] n_tty: Access echo_* variables carefully.

syzbot is reporting stalls at __process_echoes() [1]. This is because since ldata->echo_commit < ldata->echo_tail becomes true for some reason, the discard loop is serving as almost infinite loop. This patch tries to avoid falling into ldata->echo_commit < ldata->echo_tail situation by making

[PATCH 2/2] n_tty: Access echo_* variables carefully.

syzbot is reporting stalls at __process_echoes() [1]. This is because since ldata->echo_commit < ldata->echo_tail becomes true for some reason, the discard loop is serving as almost infinite loop. This patch tries to avoid falling into ldata->echo_commit < ldata->echo_tail situation by making

Re: [PATCH v2] f2fs: let fstrim issue discard commands in lower priority

On 2018/5/26 3:49, Jaegeuk Kim wrote: > The fstrim gathers huge number of large discard commands, and tries to issue > without IO awareness, which results in long user-perceive IO latencies on > READ, WRITE, and FLUSH in UFS. We've observed some of commands take several > seconds due to long

Re: [PATCH v2] f2fs: let fstrim issue discard commands in lower priority

On 2018/5/26 3:49, Jaegeuk Kim wrote: > The fstrim gathers huge number of large discard commands, and tries to issue > without IO awareness, which results in long user-perceive IO latencies on > READ, WRITE, and FLUSH in UFS. We've observed some of commands take several > seconds due to long

Re: [PATCH v3] f2fs: Fix deadlock in shutdown ioctl

On 2018/5/18 14:21, Sahitya Tummala wrote: > f2fs_ioc_shutdown() ioctl gets stuck in the below path > when issued with F2FS_GOING_DOWN_FULLSYNC option. > > __switch_to+0x90/0xc4 > percpu_down_write+0x8c/0xc0 > freeze_super+0xec/0x1e4 > freeze_bdev+0xc4/0xcc > f2fs_ioctl+0xc0c/0x1ce0 >

Re: [PATCH v3] f2fs: Fix deadlock in shutdown ioctl

On 2018/5/18 14:21, Sahitya Tummala wrote: > f2fs_ioc_shutdown() ioctl gets stuck in the below path > when issued with F2FS_GOING_DOWN_FULLSYNC option. > > __switch_to+0x90/0xc4 > percpu_down_write+0x8c/0xc0 > freeze_super+0xec/0x1e4 > freeze_bdev+0xc4/0xcc > f2fs_ioctl+0xc0c/0x1ce0 >

Re: [PATCH] xfs, proc: hide unused xfs procfs helpers

On Fri, May 25, 2018 at 06:22:04PM +0200, Christoph Hellwig wrote: > Looks fine to me: > > Reviewed-by: Christoph Hellwig > > Al, can you pick this up? Done

Re: [PATCH] xfs, proc: hide unused xfs procfs helpers

On Fri, May 25, 2018 at 06:22:04PM +0200, Christoph Hellwig wrote: > Looks fine to me: > > Reviewed-by: Christoph Hellwig > > Al, can you pick this up? Done

Re: [PATCH] IB: Revert "remove redundant INFINIBAND kconfig dependencies"

On Fri, May 25, 2018 at 2:32 PM Arnd Bergmann wrote: > Several subsystems depend on INFINIBAND_ADDR_TRANS, which in turn depends > on INFINIBAND. However, when with CONFIG_INIFIBAND=m, this leads to a > link error when another driver using it is built-in. The >

Re: [PATCH] IB: Revert "remove redundant INFINIBAND kconfig dependencies"

On Fri, May 25, 2018 at 2:32 PM Arnd Bergmann wrote: > Several subsystems depend on INFINIBAND_ADDR_TRANS, which in turn depends > on INFINIBAND. However, when with CONFIG_INIFIBAND=m, this leads to a > link error when another driver using it is built-in. The > INFINIBAND_ADDR_TRANS dependency

Re: define struct workqueue_struct in C file

On Thu, May 24, 2018 at 11:10:14PM +0800, Liu, Changcheng wrote: > Hi all, > I have one confusion about workqueue_struct: > 1) Why struct workqueue_struct is defined in C file instead of > header file? To prevent all other code poking in its guts? > I'm trying to print

Re: define struct workqueue_struct in C file

On Thu, May 24, 2018 at 11:10:14PM +0800, Liu, Changcheng wrote: > Hi all, > I have one confusion about workqueue_struct: > 1) Why struct workqueue_struct is defined in C file instead of > header file? To prevent all other code poking in its guts? > I'm trying to print

Re: [PATCH 0/7] psi: pressure stall information for CPU, memory, and IO

Hi Johannes, I tried your previous memdelay patches before this new set was posted and results were promising for predicting when Android system is close to OOM. I'm definitely going to try this one after I backport it to 4.9. On Mon, May 7, 2018 at 2:01 PM, Johannes Weiner

Re: [PATCH 0/7] psi: pressure stall information for CPU, memory, and IO

Hi Johannes, I tried your previous memdelay patches before this new set was posted and results were promising for predicting when Android system is close to OOM. I'm definitely going to try this one after I backport it to 4.9. On Mon, May 7, 2018 at 2:01 PM, Johannes Weiner wrote: > Hi, > > I

Re: [PATCH, net-next] qcom-emag: hide ACPI specific functions

On 5/25/18 4:37 PM, Arnd Bergmann wrote: +#ifdef CONFIG_ACPI static int emac_sgmii_irq_clear(struct emac_adapter *adpt, u8 irq_bits) { struct emac_sgmii *phy = >phy; @@ -288,6 +289,7 @@ static struct sgmii_ops qdf2400_ops = { .link_change = emac_sgmii_common_link_change,

Re: [PATCH, net-next] qcom-emag: hide ACPI specific functions

On 5/25/18 4:37 PM, Arnd Bergmann wrote: +#ifdef CONFIG_ACPI static int emac_sgmii_irq_clear(struct emac_adapter *adpt, u8 irq_bits) { struct emac_sgmii *phy = >phy; @@ -288,6 +289,7 @@ static struct sgmii_ops qdf2400_ops = { .link_change = emac_sgmii_common_link_change,

[BUG] perf/inject: crash in pipe mode

Hi, With the latest tip.git perf, if you run $ perf record -a -o - sleep 2 | perf inject -b -i - | perf buildid-list -i - SEGFAULT in perf inject: free_dup_event (oe=0x55d25b88, oe=0x55d25b88, event=0x3030310931303031) at util/ordered-events.c:86 86 oe->cur_alloc_size -=

[BUG] perf/inject: crash in pipe mode

Hi, With the latest tip.git perf, if you run $ perf record -a -o - sleep 2 | perf inject -b -i - | perf buildid-list -i - SEGFAULT in perf inject: free_dup_event (oe=0x55d25b88, oe=0x55d25b88, event=0x3030310931303031) at util/ordered-events.c:86 86 oe->cur_alloc_size -=

Re: aio poll and a new in-kernel poll API V13

On Wed, May 23, 2018 at 09:19:49PM +0200, Christoph Hellwig wrote: > Hi all, > > this series adds support for the IOCB_CMD_POLL operation to poll for the > readyness of file descriptors using the aio subsystem. The API is based > on patches that existed in RHAS2.1 and RHEL3, which means it

Re: aio poll and a new in-kernel poll API V13

On Wed, May 23, 2018 at 09:19:49PM +0200, Christoph Hellwig wrote: > Hi all, > > this series adds support for the IOCB_CMD_POLL operation to poll for the > readyness of file descriptors using the aio subsystem. The API is based > on patches that existed in RHAS2.1 and RHEL3, which means it

[GIT PULL] Transition vfs to 64-bit timestamps

Hi Thomas, This is a pull request for the series that I sent earlier. The series aims to switch vfs timestamps to use struct timespec64. Currently vfs uses struct timespec, which is not y2038 safe. The flag patch applies cleanly. I've not seen the timestamps update logic change often. The series

[GIT PULL] Transition vfs to 64-bit timestamps

Hi Thomas, This is a pull request for the series that I sent earlier. The series aims to switch vfs timestamps to use struct timespec64. Currently vfs uses struct timespec, which is not y2038 safe. The flag patch applies cleanly. I've not seen the timestamps update logic change often. The series

Re: [PATCH v7 6/8] tracing: Centralize preemptirq tracepoints and unify their usage

On Fri, May 25, 2018 at 08:43:39PM +0900, Namhyung Kim wrote: > Hi Joel, > > On Wed, May 23, 2018 at 06:21:55PM -0700, Joel Fernandes wrote: > > From: "Joel Fernandes (Google)" > > > > This patch detaches the preemptirq tracepoints from the tracers and > > keeps it

Re: [PATCH v7 6/8] tracing: Centralize preemptirq tracepoints and unify their usage

On Fri, May 25, 2018 at 08:43:39PM +0900, Namhyung Kim wrote: > Hi Joel, > > On Wed, May 23, 2018 at 06:21:55PM -0700, Joel Fernandes wrote: > > From: "Joel Fernandes (Google)" > > > > This patch detaches the preemptirq tracepoints from the tracers and > > keeps it separate. > > > >

Re: [PATCH, net-next] net/mlx5e: fix TLS dependency

On Fri, 2018-05-25 at 23:36 +0200, Arnd Bergmann wrote: > With CONFIG_TLS=m and MLX5_CORE_EN=y, we get a link failure: > > drivers/net/ethernet/mellanox/mlx5/core/en_accel/tls_rxtx.o: In > function `mlx5e_tls_handle_ooo': > tls_rxtx.c:(.text+0x24c): undefined reference to `tls_get_record' >

Re: [PATCH, net-next] net/mlx5e: fix TLS dependency

On Fri, 2018-05-25 at 23:36 +0200, Arnd Bergmann wrote: > With CONFIG_TLS=m and MLX5_CORE_EN=y, we get a link failure: > > drivers/net/ethernet/mellanox/mlx5/core/en_accel/tls_rxtx.o: In > function `mlx5e_tls_handle_ooo': > tls_rxtx.c:(.text+0x24c): undefined reference to `tls_get_record' >

Re: mmotm 2018-05-25-14-52 uploaded (drivers/net/ethernet/ti/davinci_mdio.c)

[forgot to add netdev] On 05/25/2018 04:14 PM, Randy Dunlap wrote: > On 05/25/2018 02:52 PM, a...@linux-foundation.org wrote: >> The mm-of-the-moment snapshot 2018-05-25-14-52 has been uploaded to >> >>http://www.ozlabs.org/~akpm/mmotm/ >> >> mmotm-readme.txt says >> >> README for

Re: mmotm 2018-05-25-14-52 uploaded (drivers/net/ethernet/ti/davinci_mdio.c)

[forgot to add netdev] On 05/25/2018 04:14 PM, Randy Dunlap wrote: > On 05/25/2018 02:52 PM, a...@linux-foundation.org wrote: >> The mm-of-the-moment snapshot 2018-05-25-14-52 has been uploaded to >> >>http://www.ozlabs.org/~akpm/mmotm/ >> >> mmotm-readme.txt says >> >> README for

Re: mmotm 2018-05-25-14-52 uploaded (drivers/net/ethernet/ti/davinci_mdio.c)

On 05/25/2018 02:52 PM, a...@linux-foundation.org wrote: > The mm-of-the-moment snapshot 2018-05-25-14-52 has been uploaded to > >http://www.ozlabs.org/~akpm/mmotm/ > > mmotm-readme.txt says > > README for mm-of-the-moment: > > http://www.ozlabs.org/~akpm/mmotm/ > > This is a snapshot of

Re: mmotm 2018-05-25-14-52 uploaded (drivers/net/ethernet/ti/davinci_mdio.c)

On 05/25/2018 02:52 PM, a...@linux-foundation.org wrote: > The mm-of-the-moment snapshot 2018-05-25-14-52 has been uploaded to > >http://www.ozlabs.org/~akpm/mmotm/ > > mmotm-readme.txt says > > README for mm-of-the-moment: > > http://www.ozlabs.org/~akpm/mmotm/ > > This is a snapshot of

[PATCH] perf tools: Fix indexing for decoder packet queue

The tail of a queue is supposed to be pointing to the next available slot in a queue. In this implementation the tail is incremented before it is used and as such points to the last used element, something that has the immense advantage of centralizing tail management at a single location and

[PATCH] perf tools: Fix indexing for decoder packet queue

The tail of a queue is supposed to be pointing to the next available slot in a queue. In this implementation the tail is incremented before it is used and as such points to the last used element, something that has the immense advantage of centralizing tail management at a single location and

RE: [PATCH V4 0/3] Use efi_rts_wq to invoke EFI Runtime Services

> > Changes from V3 to V4: > > -- > > 1. As suggested by Peter, use completions instead of flush_work() as the > > former is cheaper > > 2. Call efi_delete_dummy_variable() from efisubsys_init(). Sorry! Ard, > > wasn't able to find a better alternative to keep this change

RE: [PATCH V4 0/3] Use efi_rts_wq to invoke EFI Runtime Services

> > Changes from V3 to V4: > > -- > > 1. As suggested by Peter, use completions instead of flush_work() as the > > former is cheaper > > 2. Call efi_delete_dummy_variable() from efisubsys_init(). Sorry! Ard, > > wasn't able to find a better alternative to keep this change

[GIT PULL] ARM: at91: DT for 4.18

Arnd, Olof, I'm a bit late for this very small PR, as I had to extend the expiration date for my GPG signature key. Two small DT changes that have no functional impact. The following changes since commit 60cc43fc888428bb2f18f08997432d426a243338: Linux 4.17-rc1 (2018-04-15 18:24:20 -0700)

[GIT PULL] ARM: at91: DT for 4.18

Arnd, Olof, I'm a bit late for this very small PR, as I had to extend the expiration date for my GPG signature key. Two small DT changes that have no functional impact. The following changes since commit 60cc43fc888428bb2f18f08997432d426a243338: Linux 4.17-rc1 (2018-04-15 18:24:20 -0700)

  1   2   3   4   5   6   7   8   9   10   >