Re: [v2 1/1] i2c: dev: prevent ZERO_SIZE_PTR deref in i2cdev_ioctl_rdwr()

Hello, On Thu, Apr 19, 2018 at 08:01:46PM +0300, Alexander Popov wrote: > On 19.04.2018 16:49, Uwe Kleine-König wrote: > >> @@ -280,6 +280,7 @@ static noinline int i2cdev_ioctl_rdwr(struct > >> i2c_client *client, > >> */ > >>if (msgs[i].flags & I2C_M_RECV_LEN) { > >>

Re: [v2 1/1] i2c: dev: prevent ZERO_SIZE_PTR deref in i2cdev_ioctl_rdwr()

Hello, On Thu, Apr 19, 2018 at 08:01:46PM +0300, Alexander Popov wrote: > On 19.04.2018 16:49, Uwe Kleine-König wrote: > >> @@ -280,6 +280,7 @@ static noinline int i2cdev_ioctl_rdwr(struct > >> i2c_client *client, > >> */ > >>if (msgs[i].flags & I2C_M_RECV_LEN) { > >>

Re: [RESEND PATCH 1/1] drm/i915/glk: Add MODULE_FIRMWARE for Geminilake

On 18 April 2018 at 00:14, Joonas Lahtinen wrote: > Quoting Jani Nikula (2018-04-17 12:02:52) >> On Mon, 16 Apr 2018, "Srivatsa, Anusha" wrote: >> >>-Original Message- >> >>From: Jani Nikula [mailto:jani.nik...@linux.intel.com]

[PATCH] perf: update to new syscall stub naming convention

For v4.17-rc1, the naming of syscall stubs changed. Update the perf scripts/utils/tests which need to be aware of the syscall stub naming accordingly. Signed-off-by: Dominik Brodowski diff --git a/tools/perf/arch/powerpc/util/sym-handling.c

[PATCH] Documentation: updates for new syscall stub naming convention

For v4.17-rc1, the naming of syscall stubs changed. Update stack traces and similar instances in the documentation to avoid sources for confusion. Signed-off-by: Dominik Brodowski diff --git a/Documentation/admin-guide/bug-hunting.rst

[PATCH] Documentation: updates for new syscall stub naming convention

For v4.17-rc1, the naming of syscall stubs changed. Update stack traces and similar instances in the documentation to avoid sources for confusion. Signed-off-by: Dominik Brodowski diff --git a/Documentation/admin-guide/bug-hunting.rst b/Documentation/admin-guide/bug-hunting.rst index

[PATCH] perf: update to new syscall stub naming convention

For v4.17-rc1, the naming of syscall stubs changed. Update the perf scripts/utils/tests which need to be aware of the syscall stub naming accordingly. Signed-off-by: Dominik Brodowski diff --git a/tools/perf/arch/powerpc/util/sym-handling.c b/tools/perf/arch/powerpc/util/sym-handling.c index

Re: [RESEND PATCH 1/1] drm/i915/glk: Add MODULE_FIRMWARE for Geminilake

On 18 April 2018 at 00:14, Joonas Lahtinen wrote: > Quoting Jani Nikula (2018-04-17 12:02:52) >> On Mon, 16 Apr 2018, "Srivatsa, Anusha" wrote: >> >>-Original Message- >> >>From: Jani Nikula [mailto:jani.nik...@linux.intel.com] >> >>Sent: Wednesday, April 11, 2018 5:27 AM >> >>To: Ian W

Re: [RFC/RFT patch 0/7] timekeeping: Unify clock MONOTONIC and clock BOOTTIME

On (04/20/18 06:37), David Herrmann wrote: > > I get lots of timer-errors on Arch-Linux booting current master, after > a suspend/resume cycle. Just a selection of errors I see on resume: Hello David, Any chance you can revert the patches in question and test? I'm running ARCH

Re: [RFC/RFT patch 0/7] timekeeping: Unify clock MONOTONIC and clock BOOTTIME

On (04/20/18 06:37), David Herrmann wrote: > > I get lots of timer-errors on Arch-Linux booting current master, after > a suspend/resume cycle. Just a selection of errors I see on resume: Hello David, Any chance you can revert the patches in question and test? I'm running ARCH

Re: [PATCH V1 4/4] qcom: spmi-wled: Add auto-calibration logic support

On 2018-04-19 21:28, Bjorn Andersson wrote: On Thu 19 Apr 03:45 PDT 2018, kgu...@codeaurora.org wrote: On 2017-12-05 11:10, Bjorn Andersson wrote: > On Thu 16 Nov 04:18 PST 2017, Kiran Gunda wrote: > > > The auto-calibration algorithm checks if the current WLED sink > > configuration is

Re: [PATCH V1 4/4] qcom: spmi-wled: Add auto-calibration logic support

On 2018-04-19 21:28, Bjorn Andersson wrote: On Thu 19 Apr 03:45 PDT 2018, kgu...@codeaurora.org wrote: On 2017-12-05 11:10, Bjorn Andersson wrote: > On Thu 16 Nov 04:18 PST 2017, Kiran Gunda wrote: > > > The auto-calibration algorithm checks if the current WLED sink > > configuration is

Re: [PATCH] nvme: fc: provide a descriptive error

On 04/19/2018 07:43 PM, Johannes Thumshirn wrote: > Provide a descriptive error in case an lport to rport association > isn't found when creating the FC-NVME controller. > > Currently it's very hard to debug the reason for a failed connect > attempt without a look at the source. > >

Re: [PATCH] nvme: fc: provide a descriptive error

On 04/19/2018 07:43 PM, Johannes Thumshirn wrote: > Provide a descriptive error in case an lport to rport association > isn't found when creating the FC-NVME controller. > > Currently it's very hard to debug the reason for a failed connect > attempt without a look at the source. > >

Re: [PATCH] mm:memcg: add __GFP_NOWARN in __memcg_schedule_kmem_cache_create

On Thu, Apr 19, 2018 at 08:40:05AM +0200, Michal Hocko wrote: > On Wed 18-04-18 11:58:00, David Rientjes wrote: > > On Wed, 18 Apr 2018, Michal Hocko wrote: > > > > > > Okay, no problem. However, I don't feel we need ratelimit at this > > > > moment. > > > > We can do when we got real report.

Re: [PATCH] mm:memcg: add __GFP_NOWARN in __memcg_schedule_kmem_cache_create

On Thu, Apr 19, 2018 at 08:40:05AM +0200, Michal Hocko wrote: > On Wed 18-04-18 11:58:00, David Rientjes wrote: > > On Wed, 18 Apr 2018, Michal Hocko wrote: > > > > > > Okay, no problem. However, I don't feel we need ratelimit at this > > > > moment. > > > > We can do when we got real report.

Re: [PATCH v2 4/4] tpm: Move eventlog declarations to its own header

On Thu, Apr 12, 2018 at 12:13:50PM +0200, Thiebaud Weksteen wrote: > Reduce the size of tpm.h by moving eventlog declarations to a separate > header. > > Signed-off-by: Thiebaud Weksteen > Suggested-by: Jarkko Sakkinen Reviewed-by: Jarkko

Re: [PATCH v2 4/4] tpm: Move eventlog declarations to its own header

On Thu, Apr 12, 2018 at 12:13:50PM +0200, Thiebaud Weksteen wrote: > Reduce the size of tpm.h by moving eventlog declarations to a separate > header. > > Signed-off-by: Thiebaud Weksteen > Suggested-by: Jarkko Sakkinen Reviewed-by: Jarkko Sakkinen Tested-by: Jarkko Sakkinen /Jarkko

Re: [PATCH v2 3/4] tpm: Move shared eventlog functions to common.c

On Thu, Apr 12, 2018 at 12:13:49PM +0200, Thiebaud Weksteen wrote: > Functions and structures specific to TPM1 are renamed from tpm* to tpm1*. > > Signed-off-by: Thiebaud Weksteen > Suggested-by: Jarkko Sakkinen Reviewed-by: Jarkko Sakkinen

Re: [PATCH v2 3/4] tpm: Move shared eventlog functions to common.c

On Thu, Apr 12, 2018 at 12:13:49PM +0200, Thiebaud Weksteen wrote: > Functions and structures specific to TPM1 are renamed from tpm* to tpm1*. > > Signed-off-by: Thiebaud Weksteen > Suggested-by: Jarkko Sakkinen Reviewed-by: Jarkko Sakkinen Tested-by: Jarkko Sakkinen /Jarkko

[PATCH] iommu/vt-d: fix shift-out-of-bounds in bug checking

From: Changbin Du It allows to flush more than 4GB of device TLBs. So the mask should be 64bit wide. UBSAN captured this fault as below. [3.760024] [3.768440] UBSAN: Undefined

Re: [PATCH v2 2/4] tpm: Move eventlog files to a subdirectory

On Thu, Apr 12, 2018 at 12:13:48PM +0200, Thiebaud Weksteen wrote: > Signed-off-by: Thiebaud Weksteen > Suggested-by: Jarkko Sakkinen Reviewed-by: Jarkko Sakkinen Tested-by: Jarkko Sakkinen

[PATCH] iommu/vt-d: fix shift-out-of-bounds in bug checking

From: Changbin Du It allows to flush more than 4GB of device TLBs. So the mask should be 64bit wide. UBSAN captured this fault as below. [3.760024] [3.768440] UBSAN: Undefined behaviour in

Re: [PATCH v2 2/4] tpm: Move eventlog files to a subdirectory

On Thu, Apr 12, 2018 at 12:13:48PM +0200, Thiebaud Weksteen wrote: > Signed-off-by: Thiebaud Weksteen > Suggested-by: Jarkko Sakkinen Reviewed-by: Jarkko Sakkinen Tested-by: Jarkko Sakkinen /Jarkko

Re: [PATCH v2 1/4] tpm: Add explicit endianness cast

On Thu, Apr 12, 2018 at 12:13:47PM +0200, Thiebaud Weksteen wrote: > Signed-off-by: Thiebaud Weksteen Reviewed-by: Jarkko Sakkinen Tested-by: Jarkko Sakkinen /Jarkko

Re: [PATCH v2 1/4] tpm: Add explicit endianness cast

On Thu, Apr 12, 2018 at 12:13:47PM +0200, Thiebaud Weksteen wrote: > Signed-off-by: Thiebaud Weksteen Reviewed-by: Jarkko Sakkinen Tested-by: Jarkko Sakkinen /Jarkko

[PATCH] arm64: avoid potential infinity loop in dump_backtrace

When we dump the backtrace of some tasks there is a potential infinity loop if the content of the stack changed, no matter the change is because the task is running or other unexpected cases. This patch add stronger check on frame pointer and set the max number of stack spanning to avoid infinity

[PATCH] arm64: avoid potential infinity loop in dump_backtrace

When we dump the backtrace of some tasks there is a potential infinity loop if the content of the stack changed, no matter the change is because the task is running or other unexpected cases. This patch add stronger check on frame pointer and set the max number of stack spanning to avoid infinity

Re: [PATCH 2/7] i2c: i2c-mux-gpio: move header to platform_data

> "WS" == Wolfram Sang writes: WS> This header only contains platform_data. Move it to the proper directory. WS> Signed-off-by: Wolfram Sang Thanks, Acked-by: Peter Korsgaard -- Bye, Peter Korsgaard This message is

Re: [PATCH 2/7] i2c: i2c-mux-gpio: move header to platform_data

> "WS" == Wolfram Sang writes: WS> This header only contains platform_data. Move it to the proper directory. WS> Signed-off-by: Wolfram Sang Thanks, Acked-by: Peter Korsgaard -- Bye, Peter Korsgaard This message is subject to the following terms and conditions: MAIL

[PATCH v6 0/2] PCI: mediatek: Fixups for the IRQ handle routine and MT7622's class code

From: Honghui Zhang Two fixups for mediatek's host bridge: The first patch fixup class type and vendor ID for MT7622. The second patch fixup the IRQ handle routine by using irq_chip solution to avoid IRQ reentry which may exist for both MT2712 and MT7622. Change

[PATCH v6 0/2] PCI: mediatek: Fixups for the IRQ handle routine and MT7622's class code

From: Honghui Zhang Two fixups for mediatek's host bridge: The first patch fixup class type and vendor ID for MT7622. The second patch fixup the IRQ handle routine by using irq_chip solution to avoid IRQ reentry which may exist for both MT2712 and MT7622. Change since v5: - Make the comments

[PATCH 2/2] PCI: mediatek: Using chained IRQ to setup IRQ handle

From: Honghui Zhang Using irq_chip solution to setup IRQs for the consistent with IRQ framework. Signed-off-by: Honghui Zhang --- drivers/pci/host/pcie-mediatek.c | 192 +-- 1 file changed, 105

[PATCH 2/2] PCI: mediatek: Using chained IRQ to setup IRQ handle

From: Honghui Zhang Using irq_chip solution to setup IRQs for the consistent with IRQ framework. Signed-off-by: Honghui Zhang --- drivers/pci/host/pcie-mediatek.c | 192 +-- 1 file changed, 105 insertions(+), 87 deletions(-) diff --git

[PATCH v6 1/2] PCI: mediatek: Set up vendor ID and class type for MT7622

From: Honghui Zhang MT7622's hardware default value of vendor ID and class type is not correct, fix that by setup the correct values before linkup with Endpoint. Signed-off-by: Honghui Zhang --- drivers/pci/host/pcie-mediatek.c | 30

[PATCH v6 1/2] PCI: mediatek: Set up vendor ID and class type for MT7622

From: Honghui Zhang MT7622's hardware default value of vendor ID and class type is not correct, fix that by setup the correct values before linkup with Endpoint. Signed-off-by: Honghui Zhang --- drivers/pci/host/pcie-mediatek.c | 30 +++--- include/linux/pci_ids.h

Re: DOS by unprivileged user

On Thu, 2018-04-19 at 21:13 +0200, Ferry Toth wrote: > It appears any ordinary user can easily create a DOS on linux. > > One sure way to reproduce this is to open gitk on the linux kernel repo > (SIC) on a machine with 8GB RAM 16 GB swap on a HDD with btrfs and quad core > + hyperthreading.

Re: DOS by unprivileged user

On Thu, 2018-04-19 at 21:13 +0200, Ferry Toth wrote: > It appears any ordinary user can easily create a DOS on linux. > > One sure way to reproduce this is to open gitk on the linux kernel repo > (SIC) on a machine with 8GB RAM 16 GB swap on a HDD with btrfs and quad core > + hyperthreading.

Re: [PATCH] tpm: moves the delay_msec increment after sleep in tpm_transmit()

On Tue, Apr 10, 2018 at 03:31:09PM +0300, Jarkko Sakkinen wrote: > On Mon, 2018-04-09 at 10:29 -0400, Mimi Zohar wrote: > > If this change is acceptable, do you want to make the change or should Nayna > > repost the patch? > > No need. I'll move on to testing. Tested-by: Jarkko Sakkinen

Re: [PATCH] tpm: moves the delay_msec increment after sleep in tpm_transmit()

On Tue, Apr 10, 2018 at 03:31:09PM +0300, Jarkko Sakkinen wrote: > On Mon, 2018-04-09 at 10:29 -0400, Mimi Zohar wrote: > > If this change is acceptable, do you want to make the change or should Nayna > > repost the patch? > > No need. I'll move on to testing. Tested-by: Jarkko Sakkinen

Re: [PATCH 2/2] cpufreq: brcmstb-avs-cpufreq: prefer SCMI cpufreq if supported

On 19-04-18, 11:37, Sudeep Holla wrote: > > > On 19/04/18 05:16, Viresh Kumar wrote: > > On 18-04-18, 08:56, Markus Mayer wrote: > >> From: Jim Quinlan > >> > >> If the SCMI cpufreq driver is supported, we bail, so that the new > >> approach can be used. > >> > >>

Re: [PATCH 2/2] cpufreq: brcmstb-avs-cpufreq: prefer SCMI cpufreq if supported

On 19-04-18, 11:37, Sudeep Holla wrote: > > > On 19/04/18 05:16, Viresh Kumar wrote: > > On 18-04-18, 08:56, Markus Mayer wrote: > >> From: Jim Quinlan > >> > >> If the SCMI cpufreq driver is supported, we bail, so that the new > >> approach can be used. > >> > >> Signed-off-by: Jim Quinlan >

Re: [RFC/RFT patch 0/7] timekeeping: Unify clock MONOTONIC and clock BOOTTIME

Hey On Tue, Mar 13, 2018 at 7:11 PM, John Stultz wrote: > On Mon, Mar 12, 2018 at 11:36 PM, Ingo Molnar wrote: >> Ok, I have edited all the changelogs accordingly (and also flipped around the >> 'clock MONOTONIC' language to the more readable 'the

Re: [RFC/RFT patch 0/7] timekeeping: Unify clock MONOTONIC and clock BOOTTIME

Hey On Tue, Mar 13, 2018 at 7:11 PM, John Stultz wrote: > On Mon, Mar 12, 2018 at 11:36 PM, Ingo Molnar wrote: >> Ok, I have edited all the changelogs accordingly (and also flipped around the >> 'clock MONOTONIC' language to the more readable 'the MONOTONIC clock' >> variant), >> the resulting

Re: [greybus-dev] [PATCH 47/61] staging: greybus: simplify getting .drvdata

On 19-04-18, 16:06, Wolfram Sang wrote: > We should get drvdata from struct device directly. Going via > platform_device is an unneeded step back and forth. > > Signed-off-by: Wolfram Sang > --- > > Build tested only. buildbot is happy. Please apply

Re: [greybus-dev] [PATCH 47/61] staging: greybus: simplify getting .drvdata

On 19-04-18, 16:06, Wolfram Sang wrote: > We should get drvdata from struct device directly. Going via > platform_device is an unneeded step back and forth. > > Signed-off-by: Wolfram Sang > --- > > Build tested only. buildbot is happy. Please apply individually. > >

Re: [PATCH 08/61] dmaengine: dw: simplify getting .drvdata

On 19-04-18, 16:05, Wolfram Sang wrote: > We should get drvdata from struct device directly. Going via > platform_device is an unneeded step back and forth. > > Signed-off-by: Wolfram Sang > --- > > Build tested only. buildbot is happy. Please apply

Re: [PATCH 08/61] dmaengine: dw: simplify getting .drvdata

On 19-04-18, 16:05, Wolfram Sang wrote: > We should get drvdata from struct device directly. Going via > platform_device is an unneeded step back and forth. > > Signed-off-by: Wolfram Sang > --- > > Build tested only. buildbot is happy. Please apply individually. > > drivers/dma/dw/platform.c

Re: [PATCH] f2fs: sepearte hot/cold in free nid

On 2018/4/20 11:37, Jaegeuk Kim wrote: > On 04/20, Chao Yu wrote: >> As most indirect node, dindirect node, and xattr node won't be updated >> after they are created, but inode node and other direct node will change >> more frequently, so store their nat entries mixedly in whole nat table >> will

Re: [PATCH] f2fs: sepearte hot/cold in free nid

On 2018/4/20 11:37, Jaegeuk Kim wrote: > On 04/20, Chao Yu wrote: >> As most indirect node, dindirect node, and xattr node won't be updated >> after they are created, but inode node and other direct node will change >> more frequently, so store their nat entries mixedly in whole nat table >> will

Re: [PATCH] IB/core: Make ib_mad_client_id atomic

On Wed, 2018-04-18 at 16:24 +0200, Håkon Bugge wrote: > Two kernel threads may get the same value for agent.hi_tid, if the > agents are registered for different ports. As of now, this works, as > the agent list is per port. > > It is however confusing and not future robust. Hence, making it >

Re: [PATCH] IB/core: Make ib_mad_client_id atomic

On Wed, 2018-04-18 at 16:24 +0200, Håkon Bugge wrote: > Two kernel threads may get the same value for agent.hi_tid, if the > agents are registered for different ports. As of now, this works, as > the agent list is per port. > > It is however confusing and not future robust. Hence, making it >

Re: [PATCH 5/5] f2fs: fix to avoid race during access gc_thread pointer

On 04/20, Chao Yu wrote: > On 2018/4/20 11:19, Jaegeuk Kim wrote: > > On 04/18, Chao Yu wrote: > >> Thread A Thread BThread C > >> - f2fs_remount > >> - stop_gc_thread > >>- f2fs_sbi_store > >>

Re: [PATCH 5/5] f2fs: fix to avoid race during access gc_thread pointer

On 04/20, Chao Yu wrote: > On 2018/4/20 11:19, Jaegeuk Kim wrote: > > On 04/18, Chao Yu wrote: > >> Thread A Thread BThread C > >> - f2fs_remount > >> - stop_gc_thread > >>- f2fs_sbi_store > >>

Re: [RFC] vhost: introduce mdev based hardware vhost backend

On 2018年04月20日 02:40, Michael S. Tsirkin wrote: On Tue, Apr 10, 2018 at 03:25:45PM +0800, Jason Wang wrote: One problem is that, different virtio ring compatible devices may have different device interfaces. That is to say, we will need different drivers in QEMU. It could be troublesome. And

Re: [RFC] vhost: introduce mdev based hardware vhost backend

On 2018年04月20日 02:40, Michael S. Tsirkin wrote: On Tue, Apr 10, 2018 at 03:25:45PM +0800, Jason Wang wrote: One problem is that, different virtio ring compatible devices may have different device interfaces. That is to say, we will need different drivers in QEMU. It could be troublesome. And

RE: [RFC] vhost: introduce mdev based hardware vhost backend

> -Original Message- > From: Bie, Tiwei > Sent: Friday, April 20, 2018 11:28 AM > To: Michael S. Tsirkin > Cc: Jason Wang ; alex.william...@redhat.com; > ddut...@redhat.com; Duyck, Alexander H ; >

Re: [RFC] vhost: introduce mdev based hardware vhost backend

On Fri, Apr 20, 2018 at 11:28:07AM +0800, Tiwei Bie wrote: > On Thu, Apr 19, 2018 at 09:40:23PM +0300, Michael S. Tsirkin wrote: > > On Tue, Apr 10, 2018 at 03:25:45PM +0800, Jason Wang wrote: > > > > > > One problem is that, different virtio ring compatible devices > > > > > > may have different

RE: [RFC] vhost: introduce mdev based hardware vhost backend

> -Original Message- > From: Bie, Tiwei > Sent: Friday, April 20, 2018 11:28 AM > To: Michael S. Tsirkin > Cc: Jason Wang ; alex.william...@redhat.com; > ddut...@redhat.com; Duyck, Alexander H ; > virtio-...@lists.oasis-open.org; linux-kernel@vger.kernel.org; > k...@vger.kernel.org;

Re: [RFC] vhost: introduce mdev based hardware vhost backend

On Fri, Apr 20, 2018 at 11:28:07AM +0800, Tiwei Bie wrote: > On Thu, Apr 19, 2018 at 09:40:23PM +0300, Michael S. Tsirkin wrote: > > On Tue, Apr 10, 2018 at 03:25:45PM +0800, Jason Wang wrote: > > > > > > One problem is that, different virtio ring compatible devices > > > > > > may have different

Re: [PATCH v1 5/7] soc: mediatek: add a fixed wait for SRAM stable

On Thu, 2018-04-19 at 12:33 +0200, Matthias Brugger wrote: > > On 04/03/2018 09:15 AM, sean.w...@mediatek.com wrote: > > From: Sean Wang > > > > MT7622_POWER_DOMAIN_WB doesn't send an ACK when its managed SRAM becomes > > stable, which is not like the behavior the other

Re: [PATCH v1 5/7] soc: mediatek: add a fixed wait for SRAM stable

On Thu, 2018-04-19 at 12:33 +0200, Matthias Brugger wrote: > > On 04/03/2018 09:15 AM, sean.w...@mediatek.com wrote: > > From: Sean Wang > > > > MT7622_POWER_DOMAIN_WB doesn't send an ACK when its managed SRAM becomes > > stable, which is not like the behavior the other power domains should > >

Re: [PATCH v1 4/7] soc: mediatek: reuse regmap_read_poll_timeout helpers

On Thu, 2018-04-19 at 12:23 +0200, Matthias Brugger wrote: > > On 04/03/2018 09:15 AM, sean.w...@mediatek.com wrote: > > From: Sean Wang > > > > Reuse the common helpers regmap_read_poll_timeout provided by Linux core > > instead of an open-coded handling. > > > >

Re: [PATCH v1 4/7] soc: mediatek: reuse regmap_read_poll_timeout helpers

On Thu, 2018-04-19 at 12:23 +0200, Matthias Brugger wrote: > > On 04/03/2018 09:15 AM, sean.w...@mediatek.com wrote: > > From: Sean Wang > > > > Reuse the common helpers regmap_read_poll_timeout provided by Linux core > > instead of an open-coded handling. > > > > Signed-off-by: Sean Wang > >

Re: [PATCH] f2fs: sepearte hot/cold in free nid

On 04/20, Chao Yu wrote: > As most indirect node, dindirect node, and xattr node won't be updated > after they are created, but inode node and other direct node will change > more frequently, so store their nat entries mixedly in whole nat table > will suffer: > - fragment nat table soon due to

Re: [PATCH] f2fs: sepearte hot/cold in free nid

On 04/20, Chao Yu wrote: > As most indirect node, dindirect node, and xattr node won't be updated > after they are created, but inode node and other direct node will change > more frequently, so store their nat entries mixedly in whole nat table > will suffer: > - fragment nat table soon due to

Re: general protection fault in kernfs_kill_sb

On Thu, Apr 19, 2018 at 07:44:40PM -0700, Eric Biggers wrote: > On Mon, Apr 02, 2018 at 03:34:15PM +0100, Al Viro wrote: > > On Mon, Apr 02, 2018 at 07:40:22PM +0900, Tetsuo Handa wrote: > > > > > That commit assumes that calling kill_sb() from deactivate_locked_super(s) > > > without

Re: general protection fault in kernfs_kill_sb

On Thu, Apr 19, 2018 at 07:44:40PM -0700, Eric Biggers wrote: > On Mon, Apr 02, 2018 at 03:34:15PM +0100, Al Viro wrote: > > On Mon, Apr 02, 2018 at 07:40:22PM +0900, Tetsuo Handa wrote: > > > > > That commit assumes that calling kill_sb() from deactivate_locked_super(s) > > > without

[PATCH] ACPI / scan: Fix regression related to X-Gene UARTs

Commit e361d1f85855 ("ACPI / scan: Fix enumeration for special UART devices") caused a regression with some X-Gene based platforms (Mustang and M400) with invalid DSDT. The DSDT makes it appear that the UART device is also a slave device attached to itself. With the above commit the UART won't be

[PATCH] ACPI / scan: Fix regression related to X-Gene UARTs

Commit e361d1f85855 ("ACPI / scan: Fix enumeration for special UART devices") caused a regression with some X-Gene based platforms (Mustang and M400) with invalid DSDT. The DSDT makes it appear that the UART device is also a slave device attached to itself. With the above commit the UART won't be

Re: [PATCH 3/5] f2fs: avoid stucking GC due to atomic write

On 04/20, Chao Yu wrote: > On 2018/4/20 11:12, Jaegeuk Kim wrote: > > On 04/18, Chao Yu wrote: > >> f2fs doesn't allow abuse on atomic write class interface, so except > >> limiting in-mem pages' total memory usage capacity, we need to limit > >> atomic-write usage as well when filesystem is

Re: [PATCH 3/5] f2fs: avoid stucking GC due to atomic write

On 04/20, Chao Yu wrote: > On 2018/4/20 11:12, Jaegeuk Kim wrote: > > On 04/18, Chao Yu wrote: > >> f2fs doesn't allow abuse on atomic write class interface, so except > >> limiting in-mem pages' total memory usage capacity, we need to limit > >> atomic-write usage as well when filesystem is

Re: [PATCH 5/5] f2fs: fix to avoid race during access gc_thread pointer

On 2018/4/20 11:19, Jaegeuk Kim wrote: > On 04/18, Chao Yu wrote: >> Thread A Thread BThread C >> - f2fs_remount >> - stop_gc_thread >> - f2fs_sbi_store >> - issue_discard_thread

Re: [PATCH 5/5] f2fs: fix to avoid race during access gc_thread pointer

On 2018/4/20 11:19, Jaegeuk Kim wrote: > On 04/18, Chao Yu wrote: >> Thread A Thread BThread C >> - f2fs_remount >> - stop_gc_thread >> - f2fs_sbi_store >> - issue_discard_thread

Re: [RFC] vhost: introduce mdev based hardware vhost backend

On Thu, Apr 19, 2018 at 09:40:23PM +0300, Michael S. Tsirkin wrote: > On Tue, Apr 10, 2018 at 03:25:45PM +0800, Jason Wang wrote: > > > > > One problem is that, different virtio ring compatible devices > > > > > may have different device interfaces. That is to say, we will > > > > > need different

Re: [RFC] vhost: introduce mdev based hardware vhost backend

On Thu, Apr 19, 2018 at 09:40:23PM +0300, Michael S. Tsirkin wrote: > On Tue, Apr 10, 2018 at 03:25:45PM +0800, Jason Wang wrote: > > > > > One problem is that, different virtio ring compatible devices > > > > > may have different device interfaces. That is to say, we will > > > > > need different

Re: [PATCH 4/5] f2fs: show GC failure info in debugfs

On 2018/4/20 11:15, Jaegeuk Kim wrote: > On 04/18, Chao Yu wrote: >> This patch adds to show GC failure information in debugfs, now it just >> shows count of failure caused by atomic write. >> >> Signed-off-by: Chao Yu >> --- >> fs/f2fs/debug.c | 5 + >> fs/f2fs/f2fs.h

Re: [PATCH 4/5] f2fs: show GC failure info in debugfs

On 2018/4/20 11:15, Jaegeuk Kim wrote: > On 04/18, Chao Yu wrote: >> This patch adds to show GC failure information in debugfs, now it just >> shows count of failure caused by atomic write. >> >> Signed-off-by: Chao Yu >> --- >> fs/f2fs/debug.c | 5 + >> fs/f2fs/f2fs.h | 1 + >>

Re: [PATCH 3/5] f2fs: avoid stucking GC due to atomic write

On 2018/4/20 11:12, Jaegeuk Kim wrote: > On 04/18, Chao Yu wrote: >> f2fs doesn't allow abuse on atomic write class interface, so except >> limiting in-mem pages' total memory usage capacity, we need to limit >> atomic-write usage as well when filesystem is seriously fragmented, >> otherwise we

Re: [PATCH 3/5] f2fs: avoid stucking GC due to atomic write

On 2018/4/20 11:12, Jaegeuk Kim wrote: > On 04/18, Chao Yu wrote: >> f2fs doesn't allow abuse on atomic write class interface, so except >> limiting in-mem pages' total memory usage capacity, we need to limit >> atomic-write usage as well when filesystem is seriously fragmented, >> otherwise we

Re: [PATCH 5/5] f2fs: fix to avoid race during access gc_thread pointer

On 04/18, Chao Yu wrote: > Thread A Thread BThread C > - f2fs_remount > - stop_gc_thread > - f2fs_sbi_store > - issue_discard_thread >sbi->gc_thread = NULL; >

Re: [PATCH 5/5] f2fs: fix to avoid race during access gc_thread pointer

On 04/18, Chao Yu wrote: > Thread A Thread BThread C > - f2fs_remount > - stop_gc_thread > - f2fs_sbi_store > - issue_discard_thread >sbi->gc_thread = NULL; >

Re: [PATCH 4/5] f2fs: show GC failure info in debugfs

On 04/18, Chao Yu wrote: > This patch adds to show GC failure information in debugfs, now it just > shows count of failure caused by atomic write. > > Signed-off-by: Chao Yu > --- > fs/f2fs/debug.c | 5 + > fs/f2fs/f2fs.h | 1 + > fs/f2fs/gc.c| 13 +++-- >

Re: [f2fs-dev] [PATCH] f2fs: sepearte hot/cold in free nid

On 2018/4/20 10:30, heyunlei wrote: > > >> -Original Message- >> From: Chao Yu [mailto:yuch...@huawei.com] >> Sent: Friday, April 20, 2018 9:53 AM >> To: jaeg...@kernel.org >> Cc: linux-kernel@vger.kernel.org; linux-f2fs-de...@lists.sourceforge.net >> Subject: [f2fs-dev] [PATCH] f2fs:

Re: [PATCH 4/5] f2fs: show GC failure info in debugfs

On 04/18, Chao Yu wrote: > This patch adds to show GC failure information in debugfs, now it just > shows count of failure caused by atomic write. > > Signed-off-by: Chao Yu > --- > fs/f2fs/debug.c | 5 + > fs/f2fs/f2fs.h | 1 + > fs/f2fs/gc.c| 13 +++-- > fs/f2fs/gc.h|

Re: [f2fs-dev] [PATCH] f2fs: sepearte hot/cold in free nid

On 2018/4/20 10:30, heyunlei wrote: > > >> -Original Message- >> From: Chao Yu [mailto:yuch...@huawei.com] >> Sent: Friday, April 20, 2018 9:53 AM >> To: jaeg...@kernel.org >> Cc: linux-kernel@vger.kernel.org; linux-f2fs-de...@lists.sourceforge.net >> Subject: [f2fs-dev] [PATCH] f2fs:

Re: [PATCH 3/5] f2fs: avoid stucking GC due to atomic write

On 04/18, Chao Yu wrote: > f2fs doesn't allow abuse on atomic write class interface, so except > limiting in-mem pages' total memory usage capacity, we need to limit > atomic-write usage as well when filesystem is seriously fragmented, > otherwise we may run into infinite loop during foreground GC

Re: [PATCH 3/5] f2fs: avoid stucking GC due to atomic write

On 04/18, Chao Yu wrote: > f2fs doesn't allow abuse on atomic write class interface, so except > limiting in-mem pages' total memory usage capacity, we need to limit > atomic-write usage as well when filesystem is seriously fragmented, > otherwise we may run into infinite loop during foreground GC

Re: [PATCH] virtio_ring: switch to dma_XX barriers for rpmsg

On 2018年04月20日 01:35, Michael S. Tsirkin wrote: virtio is using barriers to order memory accesses, thus dma_wmb/rmb is a good match. Build-tested on x86: Before [mst@tuck linux]$ size drivers/virtio/virtio_ring.o textdata bss dec hex filename 11392 820 0

Re: [PATCH] virtio_ring: switch to dma_XX barriers for rpmsg

On 2018年04月20日 01:35, Michael S. Tsirkin wrote: virtio is using barriers to order memory accesses, thus dma_wmb/rmb is a good match. Build-tested on x86: Before [mst@tuck linux]$ size drivers/virtio/virtio_ring.o textdata bss dec hex filename 11392 820 0

Re: [PATCH v8 15/18] mm, fs, dax: handle layout changes to pinned dax mappings

On Thu, Apr 19, 2018 at 3:44 AM, Jan Kara wrote: > On Fri 13-04-18 15:03:51, Dan Williams wrote: >> On Mon, Apr 9, 2018 at 9:51 AM, Dan Williams >> wrote: >> > On Mon, Apr 9, 2018 at 9:49 AM, Jan Kara wrote: >> >> On Sat 07-04-18 12:38:24,

Re: [PATCH v8 15/18] mm, fs, dax: handle layout changes to pinned dax mappings

On Thu, Apr 19, 2018 at 3:44 AM, Jan Kara wrote: > On Fri 13-04-18 15:03:51, Dan Williams wrote: >> On Mon, Apr 9, 2018 at 9:51 AM, Dan Williams >> wrote: >> > On Mon, Apr 9, 2018 at 9:49 AM, Jan Kara wrote: >> >> On Sat 07-04-18 12:38:24, Dan Williams wrote: >> > [..] >> >>> I wonder if this

Re: general protection fault in kernfs_kill_sb

On Mon, Apr 02, 2018 at 03:34:15PM +0100, Al Viro wrote: > On Mon, Apr 02, 2018 at 07:40:22PM +0900, Tetsuo Handa wrote: > > > That commit assumes that calling kill_sb() from deactivate_locked_super(s) > > without corresponding fill_super() is safe. We have so far crashed with > > rpc_mount() and

Re: general protection fault in kernfs_kill_sb

On Mon, Apr 02, 2018 at 03:34:15PM +0100, Al Viro wrote: > On Mon, Apr 02, 2018 at 07:40:22PM +0900, Tetsuo Handa wrote: > > > That commit assumes that calling kill_sb() from deactivate_locked_super(s) > > without corresponding fill_super() is safe. We have so far crashed with > > rpc_mount() and

Re: [v2] prctl: Deprecate non PR_SET_MM_MAP operations

On (04/05/18 21:26), Cyrill Gorcunov wrote: [..] > - > #ifdef CONFIG_CHECKPOINT_RESTORE > if (opt == PR_SET_MM_MAP || opt == PR_SET_MM_MAP_SIZE) > return prctl_set_mm_map(opt, (const void __user *)addr, arg4); > #endif > > - if (!capable(CAP_SYS_RESOURCE)) > -

Re: [v2] prctl: Deprecate non PR_SET_MM_MAP operations

On (04/05/18 21:26), Cyrill Gorcunov wrote: [..] > - > #ifdef CONFIG_CHECKPOINT_RESTORE > if (opt == PR_SET_MM_MAP || opt == PR_SET_MM_MAP_SIZE) > return prctl_set_mm_map(opt, (const void __user *)addr, arg4); > #endif > > - if (!capable(CAP_SYS_RESOURCE)) > -

Re: [PATCH v5 4/4] zram: introduce zram memory tracking

On Fri, Apr 20, 2018 at 11:18:34AM +0900, Sergey Senozhatsky wrote: > On (04/20/18 11:09), Minchan Kim wrote: > [..] > > > hm, OK, can we get this info into the changelog? > > > > No problem. I will add as follows, > > > > "I used the feature a few years ago to find memory hoggers in userspace

Re: [PATCH v5 4/4] zram: introduce zram memory tracking

On Fri, Apr 20, 2018 at 11:18:34AM +0900, Sergey Senozhatsky wrote: > On (04/20/18 11:09), Minchan Kim wrote: > [..] > > > hm, OK, can we get this info into the changelog? > > > > No problem. I will add as follows, > > > > "I used the feature a few years ago to find memory hoggers in userspace

RE: [f2fs-dev] [PATCH] f2fs: sepearte hot/cold in free nid

>-Original Message- >From: Chao Yu [mailto:yuch...@huawei.com] >Sent: Friday, April 20, 2018 9:53 AM >To: jaeg...@kernel.org >Cc: linux-kernel@vger.kernel.org; linux-f2fs-de...@lists.sourceforge.net >Subject: [f2fs-dev] [PATCH] f2fs: sepearte hot/cold in free nid > >As most indirect

RE: [f2fs-dev] [PATCH] f2fs: sepearte hot/cold in free nid

>-Original Message- >From: Chao Yu [mailto:yuch...@huawei.com] >Sent: Friday, April 20, 2018 9:53 AM >To: jaeg...@kernel.org >Cc: linux-kernel@vger.kernel.org; linux-f2fs-de...@lists.sourceforge.net >Subject: [f2fs-dev] [PATCH] f2fs: sepearte hot/cold in free nid > >As most indirect

  1   2   3   4   5   6   7   8   9   10   >