[PATCH 2/2] drivers core: multi-threading device shutdown

When system is rebooted, halted or kexeced device_shutdown() is called. This function shuts down every single device by calling either: dev->bus->shutdown(dev) dev->driver->shutdown(dev) Even on a machine just with a moderate amount of devices, device_shutdown() may take multiple

[PATCH 1/2] ixgbe: release lock for the duration of ixgbe_suspend_close()

Currently, during device_shutdown() ixgbe holds rtnl_lock for the duration of lengthy ixgbe_close_suspend(). On machines with multiple ixgbe cards this lock prevents scaling if device_shutdown() function is multi-threaded. It is not necessary to hold this lock during ixgbe_close_suspend() as it

[PATCH 2/2] drivers core: multi-threading device shutdown

When system is rebooted, halted or kexeced device_shutdown() is called. This function shuts down every single device by calling either: dev->bus->shutdown(dev) dev->driver->shutdown(dev) Even on a machine just with a moderate amount of devices, device_shutdown() may take multiple

[PATCH 1/2] ixgbe: release lock for the duration of ixgbe_suspend_close()

Currently, during device_shutdown() ixgbe holds rtnl_lock for the duration of lengthy ixgbe_close_suspend(). On machines with multiple ixgbe cards this lock prevents scaling if device_shutdown() function is multi-threaded. It is not necessary to hold this lock during ixgbe_close_suspend() as it

[PATCH 0/2] multi-threading device shutdown

Do a faster shutdown by calling dev->*->shutdown(dev) in parallel. device_shutdown() calls these functions for every single device but only using one thread. Since, nothing else is running on the machine by the device_shutdown() s called, there is no reason not to utilize all the available CPU

[PATCH 0/2] multi-threading device shutdown

Do a faster shutdown by calling dev->*->shutdown(dev) in parallel. device_shutdown() calls these functions for every single device but only using one thread. Since, nothing else is running on the machine by the device_shutdown() s called, there is no reason not to utilize all the available CPU

Re: [PATCH V4 7/8] soc: mediatek: pwrap: add mt6351 for mt6797 SoCs

Hi, Argus On Wed, 2018-05-02 at 17:21 +0800, argus@mediatek.com wrote: > From: Argus Lin > > mt6351 is a new power management IC and it is > used for mt6797 SoCs. We need to add mt6351_regs for > pmic register mapping and pmic_mt6351 for > register accessing by

Re: [PATCH V4 7/8] soc: mediatek: pwrap: add mt6351 for mt6797 SoCs

Hi, Argus On Wed, 2018-05-02 at 17:21 +0800, argus@mediatek.com wrote: > From: Argus Lin > > mt6351 is a new power management IC and it is > used for mt6797 SoCs. We need to add mt6351_regs for > pmic register mapping and pmic_mt6351 for > register accessing by regmap. > suggest line

Re: [Ksummit-discuss] bug-introducing patches

On 05/02/2018 08:10 PM, Theodore Y. Ts'o wrote: On Thu, May 03, 2018 at 11:05:50AM +0900, Mark Brown wrote: On Wed, May 02, 2018 at 07:46:34PM +, Sasha Levin wrote: As you said, the regression should be fixed "asap", not "immediately". It should go through some sort of review and testing

Re: [Ksummit-discuss] bug-introducing patches

On 05/02/2018 08:10 PM, Theodore Y. Ts'o wrote: On Thu, May 03, 2018 at 11:05:50AM +0900, Mark Brown wrote: On Wed, May 02, 2018 at 07:46:34PM +, Sasha Levin wrote: As you said, the regression should be fixed "asap", not "immediately". It should go through some sort of review and testing

Re: [PATCH 0/6] virtio-console: spec compliance fixes

(apologies if you received a dup) On (Tue) 24 Apr 2018 [21:41:29], Michael S. Tsirkin wrote: > On Fri, Apr 20, 2018 at 09:17:59PM +0300, Michael S. Tsirkin wrote: > > Turns out virtio console tries to take a buffer out of an active vq. > > Works by sheer luck, and is explicitly forbidden by spec.

Re: [PATCH 0/6] virtio-console: spec compliance fixes

(apologies if you received a dup) On (Tue) 24 Apr 2018 [21:41:29], Michael S. Tsirkin wrote: > On Fri, Apr 20, 2018 at 09:17:59PM +0300, Michael S. Tsirkin wrote: > > Turns out virtio console tries to take a buffer out of an active vq. > > Works by sheer luck, and is explicitly forbidden by spec.

Re: [PATCH] x86/boot/compressed: Exclude 'top_pgtable' from relocation

On Wed, 2 May 2018, Kirill A. Shutemov wrote: > startup_64() copies kernel (including .data section) to the new place. > It's required for safe in-place decompression. > > This is a problem if the original place is referenced: by mistake I've > put 'top_pgtable' into .data section and the

Re: [PATCH] x86/boot/compressed: Exclude 'top_pgtable' from relocation

On Wed, 2 May 2018, Kirill A. Shutemov wrote: > startup_64() copies kernel (including .data section) to the new place. > It's required for safe in-place decompression. > > This is a problem if the original place is referenced: by mistake I've > put 'top_pgtable' into .data section and the

Re: [PATCH 0/6] virtio-console: spec compliance fixes

On (Tue) 24 Apr 2018 [21:41:29], Michael S. Tsirkin wrote: > On Fri, Apr 20, 2018 at 09:17:59PM +0300, Michael S. Tsirkin wrote: > > Turns out virtio console tries to take a buffer out of an active vq. > > Works by sheer luck, and is explicitly forbidden by spec. And while > > going over it I saw

Re: [PATCH 0/6] virtio-console: spec compliance fixes

On (Tue) 24 Apr 2018 [21:41:29], Michael S. Tsirkin wrote: > On Fri, Apr 20, 2018 at 09:17:59PM +0300, Michael S. Tsirkin wrote: > > Turns out virtio console tries to take a buffer out of an active vq. > > Works by sheer luck, and is explicitly forbidden by spec. And while > > going over it I saw

Re: BUG: Bad page map in process python2 pte:10000000000 pmd:17e8be067

Hi, Dave I have met the same issue now but in 3.10.0-514.16.1.el7.x86_64, the issue also accurred in last November. I read 3.10.0-514.16.1.el7.x86_64, the bit9~13 is the swap type, because the swap has been swapoff on my machine, for the "Bad swap file entry" error, the bit9~13 should be zero,

Re: BUG: Bad page map in process python2 pte:10000000000 pmd:17e8be067

Hi, Dave I have met the same issue now but in 3.10.0-514.16.1.el7.x86_64, the issue also accurred in last November. I read 3.10.0-514.16.1.el7.x86_64, the bit9~13 is the swap type, because the swap has been swapoff on my machine, for the "Bad swap file entry" error, the bit9~13 should be zero,

Re: [PATCH] KVM: arm/arm64: fix unaligned hva start and end in handle_hva_to_gpa

On 5/3/2018 10:02 AM, Jia He Wrote: Hi Marc Thanks for the review On 5/2/2018 10:26 PM, Marc Zyngier Wrote: [+ Suzuki] On 02/05/18 08:08, Jia He wrote: From: Jia He In our armv8a server (QDF2400), I noticed a WARN_ON as follows: [ 800.202850] WARNING: CPU: 33

Re: [PATCH] KVM: arm/arm64: fix unaligned hva start and end in handle_hva_to_gpa

On 5/3/2018 10:02 AM, Jia He Wrote: Hi Marc Thanks for the review On 5/2/2018 10:26 PM, Marc Zyngier Wrote: [+ Suzuki] On 02/05/18 08:08, Jia He wrote: From: Jia He In our armv8a server (QDF2400), I noticed a WARN_ON as follows: [ 800.202850] WARNING: CPU: 33 PID: 255 at

Re: [PATCH v2] libata: blacklist Micron SSD

Sudip, >> I think my preference would be to blacklist M500IT with the MU01 >> firmware (which Micron said was affected) and rely on the "Micron*" >> fallthrough further down for the rest. > > This patch was based on your reply at: > https://www.spinics.net/lists/linux-ide/msg55370.html Yep, but

Re: [PATCH v2] libata: blacklist Micron SSD

Sudip, >> I think my preference would be to blacklist M500IT with the MU01 >> firmware (which Micron said was affected) and rely on the "Micron*" >> fallthrough further down for the rest. > > This patch was based on your reply at: > https://www.spinics.net/lists/linux-ide/msg55370.html Yep, but

Re: [Ksummit-discuss] bug-introducing patches

On Thu, May 03, 2018 at 11:05:50AM +0900, Mark Brown wrote: > On Wed, May 02, 2018 at 07:46:34PM +, Sasha Levin wrote: > > > As you said, the regression should be fixed "asap", not "immediately". > > It should go through some sort of review and testing the maintainers are > > happy with, but

Re: [Ksummit-discuss] bug-introducing patches

On Thu, May 03, 2018 at 11:05:50AM +0900, Mark Brown wrote: > On Wed, May 02, 2018 at 07:46:34PM +, Sasha Levin wrote: > > > As you said, the regression should be fixed "asap", not "immediately". > > It should go through some sort of review and testing the maintainers are > > happy with, but

[PATCH v2] platform/x86: asus-wmi: Add keyboard backlight toggle support

Some Asus laptops like UX550GE has hotkey (Fn+F7) for keyboard backlight toggle. In this UX550GE, the hotkey incremet the level of brightness for each keypress from 1 to 3, and then switch it off when the brightness has been the max. This commit interprets the code 0xc7 generated from hotkey to

[PATCH v2] platform/x86: asus-wmi: Add keyboard backlight toggle support

Some Asus laptops like UX550GE has hotkey (Fn+F7) for keyboard backlight toggle. In this UX550GE, the hotkey incremet the level of brightness for each keypress from 1 to 3, and then switch it off when the brightness has been the max. This commit interprets the code 0xc7 generated from hotkey to

[RFC] virtio: support VIRTIO_F_IO_BARRIER

This patch introduces the support for VIRTIO_F_IO_BARRIER. When this feature is negotiated, driver will use the barriers suitable for hardware devices. Signed-off-by: Tiwei Bie --- drivers/virtio/virtio_ring.c | 5 + include/uapi/linux/virtio_config.h | 8 +++-

[RFC] virtio: support VIRTIO_F_IO_BARRIER

This patch introduces the support for VIRTIO_F_IO_BARRIER. When this feature is negotiated, driver will use the barriers suitable for hardware devices. Signed-off-by: Tiwei Bie --- drivers/virtio/virtio_ring.c | 5 + include/uapi/linux/virtio_config.h | 8 +++- 2 files changed, 12

Re: [PATCH 3/3] vsprintf: Add use-early-random-bytes cmd line option

On Wed, May 02, 2018 at 02:56:45PM -0700, Andrew Morton wrote: > On Wed, 2 May 2018 09:33:40 +1000 "Tobin C. Harding" wrote: > > > Currently if an attempt is made to print a pointer before there is > > enough entropy then '(ptrval)' is printed. This makes debugging > >

Re: [PATCH 3/3] vsprintf: Add use-early-random-bytes cmd line option

On Wed, May 02, 2018 at 02:56:45PM -0700, Andrew Morton wrote: > On Wed, 2 May 2018 09:33:40 +1000 "Tobin C. Harding" wrote: > > > Currently if an attempt is made to print a pointer before there is > > enough entropy then '(ptrval)' is printed. This makes debugging > > early stage

[PATCH 2/2] MIPS: Convert update_persistent_clock() to update_persistent_clock64()

Since struct timespec is not y2038 safe on 32bit machines, this patch converts update_persistent_clock() to update_persistent_clock64() using struct timespec64. This patch also changes rtc_mips_set_time()/rtc_mips_set_mmss() interfaces to use time64_t, which is y2038 safe. Signed-off-by: Baolin

[PATCH 2/2] MIPS: Convert update_persistent_clock() to update_persistent_clock64()

Since struct timespec is not y2038 safe on 32bit machines, this patch converts update_persistent_clock() to update_persistent_clock64() using struct timespec64. This patch also changes rtc_mips_set_time()/rtc_mips_set_mmss() interfaces to use time64_t, which is y2038 safe. Signed-off-by: Baolin

[PATCH 1/2] MIPS: Convert read_persistent_clock() to read_persistent_clock64()

Since struct timespec is not y2038 safe on 32bit machines, this patch converts read_persistent_clock() to read_persistent_clock64() using struct timespec64, as well as converting mktime() to mktime64(). Signed-off-by: Baolin Wang --- arch/mips/dec/time.c

[PATCH 1/2] MIPS: Convert read_persistent_clock() to read_persistent_clock64()

Since struct timespec is not y2038 safe on 32bit machines, this patch converts read_persistent_clock() to read_persistent_clock64() using struct timespec64, as well as converting mktime() to mktime64(). Signed-off-by: Baolin Wang --- arch/mips/dec/time.c |4 ++--

Re: [ANNOUNCE] Kconfiglib menuconfig implementation

On Tue, May 1, 2018 at 8:52 PM, Randy Dunlap wrote: > On 05/01/2018 11:13 AM, Randy Dunlap wrote: >> On 05/01/2018 10:56 AM, Randy Dunlap wrote: >>> On 04/30/2018 05:57 PM, Ulf Magnusson wrote: Hello, Kconfiglib (https://github.com/ulfalizer/Kconfiglib) now

Re: [ANNOUNCE] Kconfiglib menuconfig implementation

On Tue, May 1, 2018 at 8:52 PM, Randy Dunlap wrote: > On 05/01/2018 11:13 AM, Randy Dunlap wrote: >> On 05/01/2018 10:56 AM, Randy Dunlap wrote: >>> On 04/30/2018 05:57 PM, Ulf Magnusson wrote: Hello, Kconfiglib (https://github.com/ulfalizer/Kconfiglib) now has a terminal

Re: [PATCHv4 2/2] iommu/vt-d: Limit number of faults to clear in irq handler

Hi, On 05/03/2018 10:34 AM, Dmitry Safonov wrote: > On Thu, 2018-05-03 at 10:16 +0800, Lu Baolu wrote: >> Hi, >> >> On 05/03/2018 09:59 AM, Dmitry Safonov wrote: >>> On Thu, 2018-05-03 at 09:32 +0800, Lu Baolu wrote: Hi, On 05/03/2018 08:52 AM, Dmitry Safonov wrote: > AFAICS,

Re: [PATCHv4 2/2] iommu/vt-d: Limit number of faults to clear in irq handler

Hi, On 05/03/2018 10:34 AM, Dmitry Safonov wrote: > On Thu, 2018-05-03 at 10:16 +0800, Lu Baolu wrote: >> Hi, >> >> On 05/03/2018 09:59 AM, Dmitry Safonov wrote: >>> On Thu, 2018-05-03 at 09:32 +0800, Lu Baolu wrote: Hi, On 05/03/2018 08:52 AM, Dmitry Safonov wrote: > AFAICS,

Re: [PATCH] platform/x86: asus-wmi: Add keyboard backlight toggle support

On Wed, May 2, 2018 at 10:29 PM, Puma D. wrote: > On 02.05.2018 08:02, Chris Chiu wrote: >> >> Some Asus laptops like UX550GE has hotkey (Fn+F7) for keyboard >> backlight toggle. In this UX550GE, the hotkey incremet the level >> of brightness for each keypress from 1 to 3, and then

Re: [PATCH] platform/x86: asus-wmi: Add keyboard backlight toggle support

On Wed, May 2, 2018 at 10:29 PM, Puma D. wrote: > On 02.05.2018 08:02, Chris Chiu wrote: >> >> Some Asus laptops like UX550GE has hotkey (Fn+F7) for keyboard >> backlight toggle. In this UX550GE, the hotkey incremet the level >> of brightness for each keypress from 1 to 3, and then switch it >>

Re: [PATCH 5/6 resend] statfs: add ST_SLAVE

No explanation, no nothing? NAK. Linus

Re: [PATCH 5/6 resend] statfs: add ST_SLAVE

No explanation, no nothing? NAK. Linus

Re: [PATCHv4 2/2] iommu/vt-d: Limit number of faults to clear in irq handler

On Thu, 2018-05-03 at 10:16 +0800, Lu Baolu wrote: > Hi, > > On 05/03/2018 09:59 AM, Dmitry Safonov wrote: > > On Thu, 2018-05-03 at 09:32 +0800, Lu Baolu wrote: > > > Hi, > > > > > > On 05/03/2018 08:52 AM, Dmitry Safonov wrote: > > > > AFAICS, we're doing fault-clearing in a loop inside irq >

Re: [PATCHv4 2/2] iommu/vt-d: Limit number of faults to clear in irq handler

On Thu, 2018-05-03 at 10:16 +0800, Lu Baolu wrote: > Hi, > > On 05/03/2018 09:59 AM, Dmitry Safonov wrote: > > On Thu, 2018-05-03 at 09:32 +0800, Lu Baolu wrote: > > > Hi, > > > > > > On 05/03/2018 08:52 AM, Dmitry Safonov wrote: > > > > AFAICS, we're doing fault-clearing in a loop inside irq >

Re: [PATCH] memcg, hugetlb: pages allocated for hugetlb's overcommit will be charged to memcg

On 05/01/2018 11:54 PM, TSUKADA Koutaro wrote: > On 2018/05/02 13:41, Mike Kravetz wrote: >> What is the reason for not charging pages at allocation/reserve time? I am >> not an expert in memcg accounting, but I would think the pages should be >> charged at allocation time. Otherwise, a task

Re: [PATCH] memcg, hugetlb: pages allocated for hugetlb's overcommit will be charged to memcg

On 05/01/2018 11:54 PM, TSUKADA Koutaro wrote: > On 2018/05/02 13:41, Mike Kravetz wrote: >> What is the reason for not charging pages at allocation/reserve time? I am >> not an expert in memcg accounting, but I would think the pages should be >> charged at allocation time. Otherwise, a task

Re: [J-core] [PATCH v5 00/22] sh: LANDISK and R2Dplus convert to device tree

On Wed, May 02, 2018 at 09:37:08PM -0400, Rich Felker wrote: > On Fri, Jan 05, 2018 at 04:28:57PM -0500, Rich Felker wrote: > > On Fri, Nov 17, 2017 at 08:54:47PM +0100, John Paul Adrian Glaubitz wrote: > > > On 11/17/2017 08:17 PM, Rich Felker wrote: > > > > There were significant problems that I

[PATCH 3/3] x86/Centaur: Report correct CPU/cache topology

Centaur CPUs enumerate the cache topology in the same way as Intel CPUs, but the function is unused so for. The Centaur init code also missies to initialize x86_info::max_cores, so the CPU topology can't be described correctly. Initialize x86_info::max_cores and invoke init_intel_cacheinfo() to

Re: [J-core] [PATCH v5 00/22] sh: LANDISK and R2Dplus convert to device tree

On Wed, May 02, 2018 at 09:37:08PM -0400, Rich Felker wrote: > On Fri, Jan 05, 2018 at 04:28:57PM -0500, Rich Felker wrote: > > On Fri, Nov 17, 2017 at 08:54:47PM +0100, John Paul Adrian Glaubitz wrote: > > > On 11/17/2017 08:17 PM, Rich Felker wrote: > > > > There were significant problems that I

[PATCH 3/3] x86/Centaur: Report correct CPU/cache topology

Centaur CPUs enumerate the cache topology in the same way as Intel CPUs, but the function is unused so for. The Centaur init code also missies to initialize x86_info::max_cores, so the CPU topology can't be described correctly. Initialize x86_info::max_cores and invoke init_intel_cacheinfo() to

[PATCH 0/3] x86/CPU: Report correct cpu/cache topo for Centaur CPUs and some minor changes

There are three patches: The first patch define detect_num_cpu_cores() in common.c to replace the original intel_num_cpu_cores() which is defined in intel.c; The second patch is used to include the legacy cpu_detect_cache_sizes() into the init_intel_cacheinfo() function; The third patch is

[PATCH 0/3] x86/CPU: Report correct cpu/cache topo for Centaur CPUs and some minor changes

There are three patches: The first patch define detect_num_cpu_cores() in common.c to replace the original intel_num_cpu_cores() which is defined in intel.c; The second patch is used to include the legacy cpu_detect_cache_sizes() into the init_intel_cacheinfo() function; The third patch is

[PATCH 1/3] x86/CPU: Replace intel_num_cpu_cores with detect_num_cpu_cores

intel_num_cpu_cores() is a static defination in intel.c which can't be used by other files. Define another function called detect_num_cpu_cores() in common.c to replace this function. Signed-off-by: David Wang --- arch/x86/include/asm/processor.h | 1 +

[PATCH 1/3] x86/CPU: Replace intel_num_cpu_cores with detect_num_cpu_cores

intel_num_cpu_cores() is a static defination in intel.c which can't be used by other files. Define another function called detect_num_cpu_cores() in common.c to replace this function. Signed-off-by: David Wang --- arch/x86/include/asm/processor.h | 1 + arch/x86/kernel/cpu/common.c | 14

[PATCH 2/3] x86/cpu: Include cpu_detect_cache_sizes in init_intel_cacheinfo

Clean up the silly cpu_detect_cache_sizes() calling by including the cpu_detect_cache_sizes() inside the init_intel_cacheinfo(). Signed-off-by: David Wang --- arch/x86/kernel/cpu/intel.c | 8 +--- arch/x86/kernel/cpu/intel_cacheinfo.c | 6 ++ 2 files

[PATCH 2/3] x86/cpu: Include cpu_detect_cache_sizes in init_intel_cacheinfo

Clean up the silly cpu_detect_cache_sizes() calling by including the cpu_detect_cache_sizes() inside the init_intel_cacheinfo(). Signed-off-by: David Wang --- arch/x86/kernel/cpu/intel.c | 8 +--- arch/x86/kernel/cpu/intel_cacheinfo.c | 6 ++ 2 files changed, 7 insertions(+),

Re: [PATCH v2 4/4] seccomp: Don't special case audited processes when logging

On Wed, May 2, 2018 at 12:57 PM, Kees Cook wrote: > On Wed, May 2, 2018 at 8:53 AM, Tyler Hicks wrote: >> diff --git a/kernel/seccomp.c b/kernel/seccomp.c >> index da78835..9029d9d 100644 >> --- a/kernel/seccomp.c >> +++ b/kernel/seccomp.c >> @@

Re: [PATCH v2 4/4] seccomp: Don't special case audited processes when logging

On Wed, May 2, 2018 at 12:57 PM, Kees Cook wrote: > On Wed, May 2, 2018 at 8:53 AM, Tyler Hicks wrote: >> diff --git a/kernel/seccomp.c b/kernel/seccomp.c >> index da78835..9029d9d 100644 >> --- a/kernel/seccomp.c >> +++ b/kernel/seccomp.c >> @@ -584,18 +584,13 @@ static inline void

Re: [PATCHv4 2/2] iommu/vt-d: Limit number of faults to clear in irq handler

Hi, On 05/03/2018 10:16 AM, Lu Baolu wrote: > Hi, > > On 05/03/2018 09:59 AM, Dmitry Safonov wrote: >> On Thu, 2018-05-03 at 09:32 +0800, Lu Baolu wrote: >>> Hi, >>> >>> On 05/03/2018 08:52 AM, Dmitry Safonov wrote: AFAICS, we're doing fault-clearing in a loop inside irq handler. That

Re: [PATCHv4 2/2] iommu/vt-d: Limit number of faults to clear in irq handler

Hi, On 05/03/2018 10:16 AM, Lu Baolu wrote: > Hi, > > On 05/03/2018 09:59 AM, Dmitry Safonov wrote: >> On Thu, 2018-05-03 at 09:32 +0800, Lu Baolu wrote: >>> Hi, >>> >>> On 05/03/2018 08:52 AM, Dmitry Safonov wrote: AFAICS, we're doing fault-clearing in a loop inside irq handler. That

Re: [PATCH v2 RESEND 2/2] mm: ignore memory.min of abandoned memory cgroups

On Wed, May 02, 2018 at 04:47:10PM +0100, Roman Gushchin wrote: > + * Abandoned cgroups are loosing protection, "losing".

Re: [PATCH v2 RESEND 2/2] mm: ignore memory.min of abandoned memory cgroups

On Wed, May 02, 2018 at 04:47:10PM +0100, Roman Gushchin wrote: > + * Abandoned cgroups are loosing protection, "losing".

Re: [Ksummit-discuss] bug-introducing patches

On Wed, May 02, 2018 at 05:38:32PM -0700, Guenter Roeck wrote: > > Because if that last is the case, then the prescription is very simple > > and not controversial --- bug fixes found post -rc4 should be held to > > the next merge window. > > > > Holding up even fixes for severe bugs for 4-6

Re: [Ksummit-discuss] bug-introducing patches

On Wed, May 02, 2018 at 05:38:32PM -0700, Guenter Roeck wrote: > > Because if that last is the case, then the prescription is very simple > > and not controversial --- bug fixes found post -rc4 should be held to > > the next merge window. > > > > Holding up even fixes for severe bugs for 4-6

Re: [PATCH V4 8/8] arm64: dts: mt6797: add pwrap support for mt6797

On Wed, 2018-05-02 at 17:21 +0800, argus@mediatek.com wrote: > From: Argus Lin > > mt6797 is a highly integrated SoCs, and it uses > mt6351 as Power Management IC. > We need to add pwrap device to communicate with > mt6351 by SPI. > The base address of pwrap is

Re: [PATCH V4 8/8] arm64: dts: mt6797: add pwrap support for mt6797

On Wed, 2018-05-02 at 17:21 +0800, argus@mediatek.com wrote: > From: Argus Lin > > mt6797 is a highly integrated SoCs, and it uses > mt6351 as Power Management IC. > We need to add pwrap device to communicate with > mt6351 by SPI. > The base address of pwrap is 0x1000d000, and IRQ > number

[PATCH] mtd: rawnand: marvell: pass ms delay to wait_op

marvell_nfc_wait_op() expects the delay to be expressed in milliseconds but nand_sdr_timings uses picoseconds. Use PSEC_TO_MSEC when passing tPROG_max to marvell_nfc_wait_op(). Fixes: 02f26ecf8c772 ("mtd: nand: add reworked Marvell NAND controller driver") Cc: sta...@vger.kernel.org

[PATCH] mtd: rawnand: marvell: pass ms delay to wait_op

marvell_nfc_wait_op() expects the delay to be expressed in milliseconds but nand_sdr_timings uses picoseconds. Use PSEC_TO_MSEC when passing tPROG_max to marvell_nfc_wait_op(). Fixes: 02f26ecf8c772 ("mtd: nand: add reworked Marvell NAND controller driver") Cc: sta...@vger.kernel.org

[PATCH] KVM: x86: Expose CLDEMOTE CPU feature to guest VM

The CLDEMOTE instruction hints to hardware that the cache line that contains the linear address should be moved("demoted") from the cache(s) closest to the processor core to a level more distant from the processor core. This may accelerate subsequent accesses to the line by other cores in the same

[PATCH] KVM: x86: Expose CLDEMOTE CPU feature to guest VM

The CLDEMOTE instruction hints to hardware that the cache line that contains the linear address should be moved("demoted") from the cache(s) closest to the processor core to a level more distant from the processor core. This may accelerate subsequent accesses to the line by other cores in the same

Re: [PATCHv4 2/2] iommu/vt-d: Limit number of faults to clear in irq handler

Hi, On 05/03/2018 09:59 AM, Dmitry Safonov wrote: > On Thu, 2018-05-03 at 09:32 +0800, Lu Baolu wrote: >> Hi, >> >> On 05/03/2018 08:52 AM, Dmitry Safonov wrote: >>> AFAICS, we're doing fault-clearing in a loop inside irq handler. >>> That means that while we're clearing if a fault raises, it'll

Re: [PATCHv4 2/2] iommu/vt-d: Limit number of faults to clear in irq handler

Hi, On 05/03/2018 09:59 AM, Dmitry Safonov wrote: > On Thu, 2018-05-03 at 09:32 +0800, Lu Baolu wrote: >> Hi, >> >> On 05/03/2018 08:52 AM, Dmitry Safonov wrote: >>> AFAICS, we're doing fault-clearing in a loop inside irq handler. >>> That means that while we're clearing if a fault raises, it'll

Re: [RFC v3 4/5] virtio_ring: add event idx support in packed ring

On Thu, May 03, 2018 at 04:44:39AM +0300, Michael S. Tsirkin wrote: > On Thu, May 03, 2018 at 09:11:16AM +0800, Tiwei Bie wrote: > > On Wed, May 02, 2018 at 06:42:57PM +0300, Michael S. Tsirkin wrote: > > > On Wed, May 02, 2018 at 11:12:55PM +0800, Tiwei Bie wrote: > > > > On Wed, May 02, 2018 at

Re: [RFC v3 4/5] virtio_ring: add event idx support in packed ring

On Thu, May 03, 2018 at 04:44:39AM +0300, Michael S. Tsirkin wrote: > On Thu, May 03, 2018 at 09:11:16AM +0800, Tiwei Bie wrote: > > On Wed, May 02, 2018 at 06:42:57PM +0300, Michael S. Tsirkin wrote: > > > On Wed, May 02, 2018 at 11:12:55PM +0800, Tiwei Bie wrote: > > > > On Wed, May 02, 2018 at

Re: [Ksummit-discuss] bug-introducing patches

On Wed, May 02, 2018 at 07:46:34PM +, Sasha Levin wrote: > As you said, the regression should be fixed "asap", not "immediately". > It should go through some sort of review and testing the maintainers are > happy with, but unfourtenately it doesn't happen now. Doesn't happen some of the

Re: [Ksummit-discuss] bug-introducing patches

On Wed, May 02, 2018 at 07:46:34PM +, Sasha Levin wrote: > As you said, the regression should be fixed "asap", not "immediately". > It should go through some sort of review and testing the maintainers are > happy with, but unfourtenately it doesn't happen now. Doesn't happen some of the

Re: [PATCH] KVM: arm/arm64: fix unaligned hva start and end in handle_hva_to_gpa

Hi Marc Thanks for the review On 5/2/2018 10:26 PM, Marc Zyngier Wrote: [+ Suzuki] On 02/05/18 08:08, Jia He wrote: From: Jia He In our armv8a server (QDF2400), I noticed a WARN_ON as follows: [ 800.202850] WARNING: CPU: 33 PID: 255 at

Re: [PATCH] KVM: arm/arm64: fix unaligned hva start and end in handle_hva_to_gpa

Hi Marc Thanks for the review On 5/2/2018 10:26 PM, Marc Zyngier Wrote: [+ Suzuki] On 02/05/18 08:08, Jia He wrote: From: Jia He In our armv8a server (QDF2400), I noticed a WARN_ON as follows: [ 800.202850] WARNING: CPU: 33 PID: 255 at arch/arm64/kvm/../../../virt/kvm/arm/mmu.c:1670

Re: [PATCH V4 1/8] dt-bindings: pwrap: mediatek: add MT6351 PMIC support for MT6797

On Wed, 2018-05-02 at 17:21 +0800, argus@mediatek.com wrote: > From: Argus Lin > > We add MT6351 PMIC support for MT6797 SoCs. > > Signed-off-by: Argus Lin > --- > Documentation/devicetree/bindings/soc/mediatek/pwrap.txt | 1 + > 1 file

Re: [PATCH V4 1/8] dt-bindings: pwrap: mediatek: add MT6351 PMIC support for MT6797

On Wed, 2018-05-02 at 17:21 +0800, argus@mediatek.com wrote: > From: Argus Lin > > We add MT6351 PMIC support for MT6797 SoCs. > > Signed-off-by: Argus Lin > --- > Documentation/devicetree/bindings/soc/mediatek/pwrap.txt | 1 + > 1 file changed, 1 insertion(+) > > diff --git

Re: [PATCHv4 2/2] iommu/vt-d: Limit number of faults to clear in irq handler

On Thu, 2018-05-03 at 09:32 +0800, Lu Baolu wrote: > Hi, > > On 05/03/2018 08:52 AM, Dmitry Safonov wrote: > > AFAICS, we're doing fault-clearing in a loop inside irq handler. > > That means that while we're clearing if a fault raises, it'll make > > an irq level triggered (or on edge) on lapic.

Re: [PATCHv4 2/2] iommu/vt-d: Limit number of faults to clear in irq handler

On Thu, 2018-05-03 at 09:32 +0800, Lu Baolu wrote: > Hi, > > On 05/03/2018 08:52 AM, Dmitry Safonov wrote: > > AFAICS, we're doing fault-clearing in a loop inside irq handler. > > That means that while we're clearing if a fault raises, it'll make > > an irq level triggered (or on edge) on lapic.

Re: [PATCH] sctp: fix a potential missing-check bug

On Wed, May 02, 2018 at 08:27:05PM -0500, Wenwen Wang wrote: > On Wed, May 2, 2018 at 8:24 PM, Marcelo Ricardo Leitner > wrote: > > On Wed, May 02, 2018 at 08:15:45PM -0500, Wenwen Wang wrote: > >> In sctp_setsockopt_maxseg(), the integer 'val' is compared against

Re: [PATCH] sctp: fix a potential missing-check bug

On Wed, May 02, 2018 at 08:27:05PM -0500, Wenwen Wang wrote: > On Wed, May 2, 2018 at 8:24 PM, Marcelo Ricardo Leitner > wrote: > > On Wed, May 02, 2018 at 08:15:45PM -0500, Wenwen Wang wrote: > >> In sctp_setsockopt_maxseg(), the integer 'val' is compared against min_len > >> and max_len to

Re: [RFC v3 4/5] virtio_ring: add event idx support in packed ring

On Thu, May 03, 2018 at 09:11:16AM +0800, Tiwei Bie wrote: > On Wed, May 02, 2018 at 06:42:57PM +0300, Michael S. Tsirkin wrote: > > On Wed, May 02, 2018 at 11:12:55PM +0800, Tiwei Bie wrote: > > > On Wed, May 02, 2018 at 04:51:01PM +0300, Michael S. Tsirkin wrote: > > > > On Wed, May 02, 2018 at

Re: [RFC v3 4/5] virtio_ring: add event idx support in packed ring

On Thu, May 03, 2018 at 09:11:16AM +0800, Tiwei Bie wrote: > On Wed, May 02, 2018 at 06:42:57PM +0300, Michael S. Tsirkin wrote: > > On Wed, May 02, 2018 at 11:12:55PM +0800, Tiwei Bie wrote: > > > On Wed, May 02, 2018 at 04:51:01PM +0300, Michael S. Tsirkin wrote: > > > > On Wed, May 02, 2018 at

Re: [PATCH] evm: Don't update hmacs in user ns mounts

On Wed, 2018-05-02 at 16:49 -0500, Eric W. Biederman wrote: > From: Seth Forshee > Date: Fri, 22 Dec 2017 15:32:35 +0100 > > The kernel should not calculate new hmacs for mounts done by > non-root users. Update evm_calc_hmac_or_hash() to refuse to > calculate new

Re: [PATCH] evm: Don't update hmacs in user ns mounts

On Wed, 2018-05-02 at 16:49 -0500, Eric W. Biederman wrote: > From: Seth Forshee > Date: Fri, 22 Dec 2017 15:32:35 +0100 > > The kernel should not calculate new hmacs for mounts done by > non-root users. Update evm_calc_hmac_or_hash() to refuse to > calculate new hmacs for mounts for non-init

Re: [PATCH v2] ASoC: da7219: read fmw property to get mclk for non-dts systems

On Wed, May 02, 2018 at 10:13:55AM +, Adam Thomson wrote: > On 01 May 2018 21:50, Mark Brown wrote: > > There's a lot of things that ACPI *should* do but doesn't - it's a bit > > of a shambles how ACPI standards get defined and what's there is not > > really intended to handle systems like

Re: [PATCH v2] ASoC: da7219: read fmw property to get mclk for non-dts systems

On Wed, May 02, 2018 at 10:13:55AM +, Adam Thomson wrote: > On 01 May 2018 21:50, Mark Brown wrote: > > There's a lot of things that ACPI *should* do but doesn't - it's a bit > > of a shambles how ACPI standards get defined and what's there is not > > really intended to handle systems like

Re: [J-core] [PATCH v5 00/22] sh: LANDISK and R2Dplus convert to device tree

On Fri, Jan 05, 2018 at 04:28:57PM -0500, Rich Felker wrote: > On Fri, Nov 17, 2017 at 08:54:47PM +0100, John Paul Adrian Glaubitz wrote: > > On 11/17/2017 08:17 PM, Rich Felker wrote: > > > There were significant problems that I don't think were ever > > > addressed, including incompatible

Re: [J-core] [PATCH v5 00/22] sh: LANDISK and R2Dplus convert to device tree

On Fri, Jan 05, 2018 at 04:28:57PM -0500, Rich Felker wrote: > On Fri, Nov 17, 2017 at 08:54:47PM +0100, John Paul Adrian Glaubitz wrote: > > On 11/17/2017 08:17 PM, Rich Felker wrote: > > > There were significant problems that I don't think were ever > > > addressed, including incompatible

Applied "ASoC: Intel: bytcr_rt565: fix missing assignment to ret_val" to the asoc tree

The patch ASoC: Intel: bytcr_rt565: fix missing assignment to ret_val has been applied to the asoc tree at https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24

Applied "ASoC: Intel: bytcr_rt565: fix missing assignment to ret_val" to the asoc tree

The patch ASoC: Intel: bytcr_rt565: fix missing assignment to ret_val has been applied to the asoc tree at https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24

Re: [PATCHv4 2/2] iommu/vt-d: Limit number of faults to clear in irq handler

Hi, On 05/03/2018 08:52 AM, Dmitry Safonov wrote: > On Thu, 2018-05-03 at 07:49 +0800, Lu Baolu wrote: >> Hi, >> >> On 05/02/2018 08:38 PM, Dmitry Safonov wrote: >>> Hi Lu, >>> >>> On Wed, 2018-05-02 at 14:34 +0800, Lu Baolu wrote: Hi, On 03/31/2018 08:33 AM, Dmitry Safonov wrote:

Re: [PATCHv4 2/2] iommu/vt-d: Limit number of faults to clear in irq handler

Hi, On 05/03/2018 08:52 AM, Dmitry Safonov wrote: > On Thu, 2018-05-03 at 07:49 +0800, Lu Baolu wrote: >> Hi, >> >> On 05/02/2018 08:38 PM, Dmitry Safonov wrote: >>> Hi Lu, >>> >>> On Wed, 2018-05-02 at 14:34 +0800, Lu Baolu wrote: Hi, On 03/31/2018 08:33 AM, Dmitry Safonov wrote:

Re: [PATCH] sctp: fix a potential missing-check bug

On Wed, May 2, 2018 at 8:24 PM, Marcelo Ricardo Leitner wrote: > On Wed, May 02, 2018 at 08:15:45PM -0500, Wenwen Wang wrote: >> In sctp_setsockopt_maxseg(), the integer 'val' is compared against min_len >> and max_len to check whether it is in the appropriate range. If

Re: [PATCH v6 2/5] KVM: x86: Add IBPB support

Hi Ashok， 2018-02-02 5:59 GMT+08:00 KarimAllah Ahmed : > From: Ashok Raj > > The Indirect Branch Predictor Barrier (IBPB) is an indirect branch > control mechanism. It keeps earlier branches from influencing > later ones. > > Unlike IBRS and STIBP, IBPB

Re: [PATCH] sctp: fix a potential missing-check bug

On Wed, May 2, 2018 at 8:24 PM, Marcelo Ricardo Leitner wrote: > On Wed, May 02, 2018 at 08:15:45PM -0500, Wenwen Wang wrote: >> In sctp_setsockopt_maxseg(), the integer 'val' is compared against min_len >> and max_len to check whether it is in the appropriate range. If it is not, >> an error

Re: [PATCH v6 2/5] KVM: x86: Add IBPB support

Hi Ashok， 2018-02-02 5:59 GMT+08:00 KarimAllah Ahmed : > From: Ashok Raj > > The Indirect Branch Predictor Barrier (IBPB) is an indirect branch > control mechanism. It keeps earlier branches from influencing > later ones. > > Unlike IBRS and STIBP, IBPB does not define a new mode of operation. >

<    1   2   3   4   5   6   7   8   9   10   >