[PATCH] [RESEND 2] scsi: esas2r: use ktime_get_real_seconds()

do_gettimeofday() is deprecated because of the y2038 overflow. Here, we use the result to pass into a 32-bit field in the firmware, which still risks an overflow, but if the firmware is written to expect unsigned values, it can at least last until y2106, and there is not much we can do about it.

[PATCH] [RESEND 2] scsi: esas2r: use ktime_get_real_seconds()

do_gettimeofday() is deprecated because of the y2038 overflow. Here, we use the result to pass into a 32-bit field in the firmware, which still risks an overflow, but if the firmware is written to expect unsigned values, it can at least last until y2106, and there is not much we can do about it.

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

On Thu 19 Apr 22:43 PDT 2018, kgu...@codeaurora.org wrote: > 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: [..] > > > > When is this feature needed? > > > > > > > This feature is needed

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

On Thu 19 Apr 22:43 PDT 2018, kgu...@codeaurora.org wrote: > 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: [..] > > > > When is this feature needed? > > > > > > > This feature is needed

Re: [PATCH 2/2] x86/microcode: Do not exit early from __reload_late()

On Fri, Apr 20, 2018 at 12:37:08PM +0200, Borislav Petkov wrote: > Vitezslav reported a case where the > > "Timeout during microcode update!" > > panic would hit. After a deeper look, it turned out that his .config had > CONFIG_HOTPLUG_CPU disabled which practically made save_mc_for_early() a

Re: [PATCH 2/2] x86/microcode: Do not exit early from __reload_late()

On Fri, Apr 20, 2018 at 12:37:08PM +0200, Borislav Petkov wrote: > Vitezslav reported a case where the > > "Timeout during microcode update!" > > panic would hit. After a deeper look, it turned out that his .config had > CONFIG_HOTPLUG_CPU disabled which practically made save_mc_for_early() a

Re: Potential problem with 31e77c93e432dec7 ("sched/fair: Update blocked load when newly idle")

Hi Heiner and Niklas, Le Saturday 14 Apr 2018 à 13:24:20 (+0200), Vincent Guittot a écrit : > Hi Niklas, > > On 13 April 2018 at 00:39, Niklas Söderlund > wrote: > > Hi Vincent, > > > > Thanks for helping trying to figure this out. > > > > On 2018-04-12 15:30:31

Re: Potential problem with 31e77c93e432dec7 ("sched/fair: Update blocked load when newly idle")

Hi Heiner and Niklas, Le Saturday 14 Apr 2018 à 13:24:20 (+0200), Vincent Guittot a écrit : > Hi Niklas, > > On 13 April 2018 at 00:39, Niklas Söderlund > wrote: > > Hi Vincent, > > > > Thanks for helping trying to figure this out. > > > > On 2018-04-12 15:30:31 +0200, Vincent Guittot wrote: >

Re: [PATCH 1/2] x86/microcode/intel: Save microcode patch unconditionally

On Fri, Apr 20, 2018 at 12:34:28PM +0200, Borislav Petkov wrote: > save_mc_for_early() was a no-op on !CONFIG_HOTPLUG_CPU but the > generic_load_microcode() path saves the microcode patches it has found > into our cache of patches which is used for late loading too. Regardless > of whether we do

Re: [PATCH 1/2] x86/microcode/intel: Save microcode patch unconditionally

On Fri, Apr 20, 2018 at 12:34:28PM +0200, Borislav Petkov wrote: > save_mc_for_early() was a no-op on !CONFIG_HOTPLUG_CPU but the > generic_load_microcode() path saves the microcode patches it has found > into our cache of patches which is used for late loading too. Regardless > of whether we do

[git pull] vfs fixes

Assorted fixes. Some of that is only a matter with fault injection (broken handling of small allocation failure in various mount-related places), but the last one is a root-triggerable stack overflow, and combined with userns it gets really nasty ;-/ The following changes since commit

[git pull] vfs fixes

Assorted fixes. Some of that is only a matter with fault injection (broken handling of small allocation failure in various mount-related places), but the last one is a root-triggerable stack overflow, and combined with userns it gets really nasty ;-/ The following changes since commit

Re: [PATCH ghak80 V1] audit: add syscall information to FEATURE_CHANGE records

On Fri, Apr 20, 2018 at 9:46 AM, Richard Guy Briggs wrote: > On 2018-04-17 18:06, Paul Moore wrote: >> On Wed, Apr 11, 2018 at 8:46 AM, Richard Guy Briggs wrote: >> > Tie syscall information to FEATURE_CHANGE calls since it is a result of >> > user action. >> >

Re: [PATCH ghak80 V1] audit: add syscall information to FEATURE_CHANGE records

On Fri, Apr 20, 2018 at 9:46 AM, Richard Guy Briggs wrote: > On 2018-04-17 18:06, Paul Moore wrote: >> On Wed, Apr 11, 2018 at 8:46 AM, Richard Guy Briggs wrote: >> > Tie syscall information to FEATURE_CHANGE calls since it is a result of >> > user action. >> > >> > See:

[PATCH 4/5] ARM: dts: stih410: Fix complain about IRQ_TYPE_NONE usage

From: Patrice Chotard Since commit 83a86fbb5b56 ("irqchip/gic: Loudly complain about the use of IRQ_TYPE_NONE") kernel is complaining about the IRQ_TYPE_NONE usage which shouldn't be used. Use IRQ_TYPE_LEVEL_HIGH instead. Signed-off-by: Patrice Chotard

[PATCH 4/5] ARM: dts: stih410: Fix complain about IRQ_TYPE_NONE usage

From: Patrice Chotard Since commit 83a86fbb5b56 ("irqchip/gic: Loudly complain about the use of IRQ_TYPE_NONE") kernel is complaining about the IRQ_TYPE_NONE usage which shouldn't be used. Use IRQ_TYPE_LEVEL_HIGH instead. Signed-off-by: Patrice Chotard --- arch/arm/boot/dts/stih410.dtsi |

[PATCH 5/5] ARM: dts: stihxxx-b2120: Fix complain about IRQ_TYPE_NONE usage

From: Patrice Chotard Since commit 83a86fbb5b56 ("irqchip/gic: Loudly complain about the use of IRQ_TYPE_NONE") kernel is complaining about the IRQ_TYPE_NONE usage which shouldn't be used. Use IRQ_TYPE_LEVEL_HIGH instead. Signed-off-by: Patrice Chotard

[PATCH 5/5] ARM: dts: stihxxx-b2120: Fix complain about IRQ_TYPE_NONE usage

From: Patrice Chotard Since commit 83a86fbb5b56 ("irqchip/gic: Loudly complain about the use of IRQ_TYPE_NONE") kernel is complaining about the IRQ_TYPE_NONE usage which shouldn't be used. Use IRQ_TYPE_LEVEL_HIGH instead. Signed-off-by: Patrice Chotard ---

[PATCH 0/5] ARM: dts: STi: Fix complain about IRQ_TYPE_NONE_usage

From: Patrice Chotard Fix the STi following DT files which make usage of IRQ_TYPE_NONE flag: _ stih407-family.dtsi _ stih407-pinctrl.dtsi _ stih407.dtsi _ stih410.dtsi _ stihxxx-b2120.dtsi Patrice Chotard (5): ARM: dts: stih407-family: Fix complain about

[PATCH 1/5] ARM: dts: stih407-family: Fix complain about IRQ_TYPE_NONE usage

From: Patrice Chotard Since commit 83a86fbb5b56 ("irqchip/gic: Loudly complain about the use of IRQ_TYPE_NONE") kernel is complaining about the IRQ_TYPE_NONE usage which shouldn't be used. Use IRQ_TYPE_LEVEL_HIGH instead. Signed-off-by: Patrice Chotard

[PATCH 0/5] ARM: dts: STi: Fix complain about IRQ_TYPE_NONE_usage

From: Patrice Chotard Fix the STi following DT files which make usage of IRQ_TYPE_NONE flag: _ stih407-family.dtsi _ stih407-pinctrl.dtsi _ stih407.dtsi _ stih410.dtsi _ stihxxx-b2120.dtsi Patrice Chotard (5): ARM: dts: stih407-family: Fix complain about IRQ_TYPE_NONE usage ARM: dts:

[PATCH 1/5] ARM: dts: stih407-family: Fix complain about IRQ_TYPE_NONE usage

From: Patrice Chotard Since commit 83a86fbb5b56 ("irqchip/gic: Loudly complain about the use of IRQ_TYPE_NONE") kernel is complaining about the IRQ_TYPE_NONE usage which shouldn't be used. Use IRQ_TYPE_LEVEL_HIGH instead. Signed-off-by: Patrice Chotard ---

[PATCH 2/5] ARM: dts: stih407-pinctrl: Fix complain about IRQ_TYPE_NONE usage

From: Patrice Chotard Since commit 83a86fbb5b56 ("irqchip/gic: Loudly complain about the use of IRQ_TYPE_NONE") kernel is complaining about the IRQ_TYPE_NONE usage which shouldn't be used. Use IRQ_TYPE_LEVEL_HIGH instead. Signed-off-by: Patrice Chotard

[PATCH 2/5] ARM: dts: stih407-pinctrl: Fix complain about IRQ_TYPE_NONE usage

From: Patrice Chotard Since commit 83a86fbb5b56 ("irqchip/gic: Loudly complain about the use of IRQ_TYPE_NONE") kernel is complaining about the IRQ_TYPE_NONE usage which shouldn't be used. Use IRQ_TYPE_LEVEL_HIGH instead. Signed-off-by: Patrice Chotard ---

[PATCH 3/5] ARM: dts: stih407: Fix complain about IRQ_TYPE_NONE usage

From: Patrice Chotard Since commit 83a86fbb5b56 ("irqchip/gic: Loudly complain about the use of IRQ_TYPE_NONE") kernel is complaining about the IRQ_TYPE_NONE usage which shouldn't be used. Use IRQ_TYPE_LEVEL_HIGH instead. Signed-off-by: Patrice Chotard

[PATCH 3/5] ARM: dts: stih407: Fix complain about IRQ_TYPE_NONE usage

From: Patrice Chotard Since commit 83a86fbb5b56 ("irqchip/gic: Loudly complain about the use of IRQ_TYPE_NONE") kernel is complaining about the IRQ_TYPE_NONE usage which shouldn't be used. Use IRQ_TYPE_LEVEL_HIGH instead. Signed-off-by: Patrice Chotard --- arch/arm/boot/dts/stih407.dtsi | 2

[PATCH net-next 4/4] tcp: mmap: move the skb cleanup to tcp_mmap_hook()

Freeing all skbs and sending ACK is time consuming. This is currently done while both current->mm->mmap_sem and socket lock are held, in tcp_mmap() Thanks to mmap_hook infrastructure, we can perform the cleanup after current->mm->mmap_sem has been released, thus allowing other threads to perform

[PATCH net-next 2/4] net: implement sock_mmap_hook()

sock_mmap_hook() is the mmap_hook handler provided for socket_file_ops Following patch will provide tcp_mmap_hook() for TCP protocol. Signed-off-by: Eric Dumazet --- include/linux/net.h | 1 + net/socket.c| 9 + 2 files changed, 10 insertions(+) diff --git

[PATCH net-next 4/4] tcp: mmap: move the skb cleanup to tcp_mmap_hook()

Freeing all skbs and sending ACK is time consuming. This is currently done while both current->mm->mmap_sem and socket lock are held, in tcp_mmap() Thanks to mmap_hook infrastructure, we can perform the cleanup after current->mm->mmap_sem has been released, thus allowing other threads to perform

[PATCH net-next 2/4] net: implement sock_mmap_hook()

sock_mmap_hook() is the mmap_hook handler provided for socket_file_ops Following patch will provide tcp_mmap_hook() for TCP protocol. Signed-off-by: Eric Dumazet --- include/linux/net.h | 1 + net/socket.c| 9 + 2 files changed, 10 insertions(+) diff --git

[PATCH net-next 1/4] mm: provide a mmap_hook infrastructure

When adding tcp mmap() implementation, I forgot that socket lock had to be taken before current->mm->mmap_sem. syzbot eventually caught the bug. This patch provides a new mmap_hook() method in struct file_operations that might be provided by fs to implement a finer control of whats to be done

[PATCH net-next 0/4] mm,tcp: provide mmap_hook to solve lockdep issue

This patch series provide a new mmap_hook to fs willing to grab a mutex before mm->mmap_sem is taken, to ensure lockdep sanity. This hook allows us to shorten tcp_mmap() execution time (while mmap_sem is held), and improve multi-threading scalability. Eric Dumazet (4): mm: provide a mmap_hook

[PATCH net-next 3/4] tcp: provide tcp_mmap_hook()

Many socket operations can copy data between user and kernel space while socket lock is held. This means mm->mmap_sem can be taken after socket lock. When implementing tcp mmap(), I forgot this and syzbot was kind enough to point this to my attention. This patch adds tcp_mmap_hook(), allowing us

[PATCH net-next 1/4] mm: provide a mmap_hook infrastructure

When adding tcp mmap() implementation, I forgot that socket lock had to be taken before current->mm->mmap_sem. syzbot eventually caught the bug. This patch provides a new mmap_hook() method in struct file_operations that might be provided by fs to implement a finer control of whats to be done

[PATCH net-next 0/4] mm,tcp: provide mmap_hook to solve lockdep issue

This patch series provide a new mmap_hook to fs willing to grab a mutex before mm->mmap_sem is taken, to ensure lockdep sanity. This hook allows us to shorten tcp_mmap() execution time (while mmap_sem is held), and improve multi-threading scalability. Eric Dumazet (4): mm: provide a mmap_hook

[PATCH net-next 3/4] tcp: provide tcp_mmap_hook()

Many socket operations can copy data between user and kernel space while socket lock is held. This means mm->mmap_sem can be taken after socket lock. When implementing tcp mmap(), I forgot this and syzbot was kind enough to point this to my attention. This patch adds tcp_mmap_hook(), allowing us

Re: [RFC 0/2] dw_mmc: add multislot support

Hi Ulf, On Fri, 2018-04-20 at 09:35 +0200, Ulf Hansson wrote: > [...] > > > > > 2. Add missing stuff to support multislot mode in DesignWare MMC driver. > > * Add missing slot switch to __dw_mci_start_request() function. > > * Refactor set_ios function: > >a) Calculate common clock which

Re: [RFC 0/2] dw_mmc: add multislot support

Hi Ulf, On Fri, 2018-04-20 at 09:35 +0200, Ulf Hansson wrote: > [...] > > > > > 2. Add missing stuff to support multislot mode in DesignWare MMC driver. > > * Add missing slot switch to __dw_mci_start_request() function. > > * Refactor set_ios function: > >a) Calculate common clock which

[PATCH 4/4] sh: remove board_time_init() callback

The only remaining user of board_time_init() is the of-generic machine, and that just calls the global timer_init() function. Calling that one has no effect on non-DT platforms, so we can simply call it unconditionally in place of board_time_init(). Signed-off-by: Arnd Bergmann

[PATCH 4/4] sh: remove board_time_init() callback

The only remaining user of board_time_init() is the of-generic machine, and that just calls the global timer_init() function. Calling that one has no effect on non-DT platforms, so we can simply call it unconditionally in place of board_time_init(). Signed-off-by: Arnd Bergmann ---

[PATCH 3/4] sh: remove unused rtc_sh_get/set_time infrastructure

All platforms are now converted to RTC drivers, so this has become obsolete. The board_time_init() callback still has one caller, but could otherwise also get killed. This removes one more usage of the deprecated timespec structure, which overflows in y2038. Signed-off-by: Arnd Bergmann

[PATCH 3/4] sh: remove unused rtc_sh_get/set_time infrastructure

All platforms are now converted to RTC drivers, so this has become obsolete. The board_time_init() callback still has one caller, but could otherwise also get killed. This removes one more usage of the deprecated timespec structure, which overflows in y2038. Signed-off-by: Arnd Bergmann ---

[PATCH 2/4] sh: sh03: rtc: push down rtc class ops into driver

The dreamcast RTC support has an extra level of indirection to provide either the old read_persistent_clock/update_persistent_clock interface or the rtc-generic device for hctosys/systohc. By removing the indirection and always using the RTC_CLASS interface, we can avoid the lossy double

[PATCH 2/4] sh: sh03: rtc: push down rtc class ops into driver

The dreamcast RTC support has an extra level of indirection to provide either the old read_persistent_clock/update_persistent_clock interface or the rtc-generic device for hctosys/systohc. By removing the indirection and always using the RTC_CLASS interface, we can avoid the lossy double

Re: [Patch v2] Storvsc: Select channel based on available percentage of ring buffer to write

On Thu, 19 Apr 2018 14:54:24 -0700 Long Li wrote: > From: Long Li > > This is a best effort for estimating on how busy the ring buffer is for > that channel, based on available buffer to write in percentage. It is still > possible that at the

Re: [Patch v2] Storvsc: Select channel based on available percentage of ring buffer to write

On Thu, 19 Apr 2018 14:54:24 -0700 Long Li wrote: > From: Long Li > > This is a best effort for estimating on how busy the ring buffer is for > that channel, based on available buffer to write in percentage. It is still > possible that at the time of actual ring buffer write, the space may not

Re: [PATCH 2/2] rtmutex: Reduce top-waiter blocking on a lock

On Tue, Apr 10, 2018 at 09:27:50AM -0700, Davidlohr Bueso wrote: > By applying well known spin-on-lock-owner techniques, we can avoid the > blocking overhead during the process of when the task is trying to take > the rtmutex. The idea is that as long as the owner is running, there is a > fair

Re: [PATCH 2/2] rtmutex: Reduce top-waiter blocking on a lock

On Tue, Apr 10, 2018 at 09:27:50AM -0700, Davidlohr Bueso wrote: > By applying well known spin-on-lock-owner techniques, we can avoid the > blocking overhead during the process of when the task is trying to take > the rtmutex. The idea is that as long as the owner is running, there is a > fair

[PATCH 1/4] sh: dreamcast: rtc: push down rtc class ops into driver

The dreamcast RTC support has an extra level of indirection to provide either the old read_persistent_clock/update_persistent_clock interface or the rtc-generic device for hctosys/systohc. Both do the same thing here, so we can do away with the abstraction and simply enable the RTC core code to

[PATCH 1/4] sh: dreamcast: rtc: push down rtc class ops into driver

The dreamcast RTC support has an extra level of indirection to provide either the old read_persistent_clock/update_persistent_clock interface or the rtc-generic device for hctosys/systohc. Both do the same thing here, so we can do away with the abstraction and simply enable the RTC core code to

[PATCH for-rc] uapi: Fix SPDX tags for files referring to the 'OpenIB.org' license

Based on discussion with Kate Stewart this license is not a BSD-2-Clause, but is now formally identified as Linux-OpenIB by SPDX. The key difference between the licenses is in the 'warranty' paragraph. if_infiniband.h refers to the 'OpenIB.org' license, but does not include the text, instead it

[PATCH for-rc] uapi: Fix SPDX tags for files referring to the 'OpenIB.org' license

Based on discussion with Kate Stewart this license is not a BSD-2-Clause, but is now formally identified as Linux-OpenIB by SPDX. The key difference between the licenses is in the 'warranty' paragraph. if_infiniband.h refers to the 'OpenIB.org' license, but does not include the text, instead it

[PATCH] ARM: dts: imx53-ppd: Use IRQ_TYPE_* constants

Replace magic numbers with IRQ_TYPE_* constants to improve DT readability. Signed-off-by: Sebastian Reichel --- arch/arm/boot/dts/imx53-ppd.dts | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/arch/arm/boot/dts/imx53-ppd.dts

[PATCH] ARM: dts: imx53-ppd: Use IRQ_TYPE_* constants

Replace magic numbers with IRQ_TYPE_* constants to improve DT readability. Signed-off-by: Sebastian Reichel --- arch/arm/boot/dts/imx53-ppd.dts | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/arch/arm/boot/dts/imx53-ppd.dts b/arch/arm/boot/dts/imx53-ppd.dts index

Re: c9e97a1997 BUG: kernel reboot-without-warning in early-boot stage, last printk: early console in setup code

I have root caused the issue, and will submit a fix shortly. The fix also fixes the per_cpu_ptr_to_phys bug that is sent in a separate thread. The issue arises in this stack: start_kernel() trap_init() setup_cpu_entry_areas() setup_cpu_entry_area(cpu) get_cpu_gdt_paddr(cpu)

Re: c9e97a1997 BUG: kernel reboot-without-warning in early-boot stage, last printk: early console in setup code

I have root caused the issue, and will submit a fix shortly. The fix also fixes the per_cpu_ptr_to_phys bug that is sent in a separate thread. The issue arises in this stack: start_kernel() trap_init() setup_cpu_entry_areas() setup_cpu_entry_area(cpu) get_cpu_gdt_paddr(cpu)

Re: [PATCH v4 0/3] lan78xx: Read configuration from Device Tree

From: Phil Elwell Date: Thu, 19 Apr 2018 17:59:37 +0100 > The Microchip LAN78XX family of devices are Ethernet controllers with > a USB interface. Despite being discoverable devices it can be useful to > be able to configure them from Device Tree, particularly in low-cost >

Re: [PATCH v4 0/3] lan78xx: Read configuration from Device Tree

From: Phil Elwell Date: Thu, 19 Apr 2018 17:59:37 +0100 > The Microchip LAN78XX family of devices are Ethernet controllers with > a USB interface. Despite being discoverable devices it can be useful to > be able to configure them from Device Tree, particularly in low-cost > applications without

[PATCH 3/2] rtmutex: Use waiter debug init,free magic numbers

... we already use these for regular mutexes, rtmutex can also use it, and while at it rename the whole thing since this is specific to waiters. Signed-off-by: Davidlohr Bueso --- include/linux/poison.h | 4 ++-- kernel/locking/mutex-debug.c | 4 ++--

[PATCH 3/2] rtmutex: Use waiter debug init,free magic numbers

... we already use these for regular mutexes, rtmutex can also use it, and while at it rename the whole thing since this is specific to waiters. Signed-off-by: Davidlohr Bueso --- include/linux/poison.h | 4 ++-- kernel/locking/mutex-debug.c | 4 ++-- kernel/locking/rtmutex-debug.c | 4

Re: Clang arm64 build is broken

Hi Andrey, On Fri, Apr 20, 2018 at 04:59:35PM +0200, Andrey Konovalov wrote: > On Fri, Apr 20, 2018 at 10:13 AM, Marc Zyngier wrote: > >> The issue is that > >> clang doesn't know about the "S" asm constraint. I reported this to > >> clang [2], and hopefully this will get

Re: Clang arm64 build is broken

Hi Andrey, On Fri, Apr 20, 2018 at 04:59:35PM +0200, Andrey Konovalov wrote: > On Fri, Apr 20, 2018 at 10:13 AM, Marc Zyngier wrote: > >> The issue is that > >> clang doesn't know about the "S" asm constraint. I reported this to > >> clang [2], and hopefully this will get fixed. In the meantime,

Re: [RFC] trace_events: Fix kernel crash while using empty filter with perf

On Fri, 20 Apr 2018 20:37:58 +0530 Ravi Bangoria wrote: > Kernel is crashing when user tries to record 'ftrace:function' event > with empty filter: > > # perf record -e ftrace:function --filter="" ls > > # dmesg > BUG: unable to handle kernel NULL pointer

Re: [RFC] trace_events: Fix kernel crash while using empty filter with perf

On Fri, 20 Apr 2018 20:37:58 +0530 Ravi Bangoria wrote: > Kernel is crashing when user tries to record 'ftrace:function' event > with empty filter: > > # perf record -e ftrace:function --filter="" ls > > # dmesg > BUG: unable to handle kernel NULL pointer dereference at 0008

Re: [PATCH 04/24] VFS: Add LSM hooks for filesystem context [ver #7]

Paul Moore wrote: > Adding the SELinux mailing list to the CC line; in the future please > include the SELinux mailing list on patches like this. It would also > be very helpful to include "selinux" somewhere in the subject line > when the patch is predominately SELinux

Re: [PATCH 04/24] VFS: Add LSM hooks for filesystem context [ver #7]

Paul Moore wrote: > Adding the SELinux mailing list to the CC line; in the future please > include the SELinux mailing list on patches like this. It would also > be very helpful to include "selinux" somewhere in the subject line > when the patch is predominately SELinux related (much like you

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

On Thu, Apr 19, 2018 at 11:55:55PM -0400, Doug Ledford wrote: > 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. > >

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

On Thu, Apr 19, 2018 at 11:55:55PM -0400, Doug Ledford wrote: > 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. > >

[PATCH v2] clk: add duty cycle support

Add the possibility to apply and query the clock signal duty cycle ratio. This is useful when the duty cycle of the clock signal depends on some other parameters controlled by the clock framework. For example, the duty cycle of a divider may depends on the raw divider setting (ratio = N / div) ,

[PATCH v2] clk: add duty cycle support

Add the possibility to apply and query the clock signal duty cycle ratio. This is useful when the duty cycle of the clock signal depends on some other parameters controlled by the clock framework. For example, the duty cycle of a divider may depends on the raw divider setting (ratio = N / div) ,

Re: [virtio-dev] [pci PATCH v7 2/5] virtio_pci: Add support for unmanaged SR-IOV on virtio_pci devices

On Fri, Apr 20, 2018 at 07:56:14AM -0700, Alexander Duyck wrote: > > I think for virtio it should include the feature bit, yes. > > Adding feature bit is very easy - post a patch to the virtio TC mailing > > list, wait about a week to give people time to respond (two weeks if it > > is around

Re: [virtio-dev] [pci PATCH v7 2/5] virtio_pci: Add support for unmanaged SR-IOV on virtio_pci devices

On Fri, Apr 20, 2018 at 07:56:14AM -0700, Alexander Duyck wrote: > > I think for virtio it should include the feature bit, yes. > > Adding feature bit is very easy - post a patch to the virtio TC mailing > > list, wait about a week to give people time to respond (two weeks if it > > is around

Re: [PATCH v2] sched/rt: Rework for_each_process_thread() iterations in tg_has_rt_tasks()

On 20/04/18 17:30, Kirill Tkhai wrote: > On 20.04.2018 17:11, Juri Lelli wrote: > > On 20/04/18 13:06, Kirill Tkhai wrote: > >> From: Kirill Tkhai > >> > >> tg_rt_schedulable() iterates over all child task groups, > >> while tg_has_rt_tasks() iterates over all linked tasks.

Re: [PATCH v2] sched/rt: Rework for_each_process_thread() iterations in tg_has_rt_tasks()

On 20/04/18 17:30, Kirill Tkhai wrote: > On 20.04.2018 17:11, Juri Lelli wrote: > > On 20/04/18 13:06, Kirill Tkhai wrote: > >> From: Kirill Tkhai > >> > >> tg_rt_schedulable() iterates over all child task groups, > >> while tg_has_rt_tasks() iterates over all linked tasks. > >> In case of

Re: linux-next: Tree for Apr 19 (dell smbios SMM)

On 04/20/18 07:29, mario.limoncie...@dell.com wrote: >> -Original Message- >> From: Randy Dunlap [mailto:rdun...@infradead.org] >> Sent: Thursday, April 19, 2018 1:00 PM >> To: Stephen Rothwell; Linux-Next Mailing List >> Cc: Linux Kernel Mailing List; Platform Driver; Limonciello, Mario

Re: linux-next: Tree for Apr 19 (dell smbios SMM)

On 04/20/18 07:29, mario.limoncie...@dell.com wrote: >> -Original Message- >> From: Randy Dunlap [mailto:rdun...@infradead.org] >> Sent: Thursday, April 19, 2018 1:00 PM >> To: Stephen Rothwell; Linux-Next Mailing List >> Cc: Linux Kernel Mailing List; Platform Driver; Limonciello, Mario

Re: [PATCH] MIPS: sni: Remove the read_persistent_clock()

On Thu, Apr 19, 2018 at 9:21 AM, Baolin Wang wrote: > The dummy read_persistent_clock() uses a timespec, which is not year 2038 > safe on 32bit systems. Thus remove this obsolete interface. > > Signed-off-by: Baolin Wang Looks good to me. I have a

Re: [PATCH] MIPS: sni: Remove the read_persistent_clock()

On Thu, Apr 19, 2018 at 9:21 AM, Baolin Wang wrote: > The dummy read_persistent_clock() uses a timespec, which is not year 2038 > safe on 32bit systems. Thus remove this obsolete interface. > > Signed-off-by: Baolin Wang Looks good to me. I have a larger but incomplete patch for arch/mips

Re: [PATCH v3 net-next] net: introduce a new tracepoint for tcp_rcv_space_adjust

On Fri, Apr 20, 2018 at 11:21 PM, David Miller wrote: > > Why are you sending this same patch twice? > > Thank you. Some mistake. Sorry about that. Pls. use the second patch. Thanks Yafang

Re: [PATCH v3 net-next] net: introduce a new tracepoint for tcp_rcv_space_adjust

On Fri, Apr 20, 2018 at 11:21 PM, David Miller wrote: > > Why are you sending this same patch twice? > > Thank you. Some mistake. Sorry about that. Pls. use the second patch. Thanks Yafang

Re: [PATCH v2] tracing: fix bad use of igrab in trace_uprobe.c

On Fri, 20 Apr 2018 16:34:25 +0200 Miklos Szeredi wrote: > This corner case is simply not interesting (modifying a binary while > it is being debugged with uprobe). Let's just concentrate on making > this crash and leak free. Yes please. I'm waiting for a final patch to run

Re: [PATCH v2] tracing: fix bad use of igrab in trace_uprobe.c

On Fri, 20 Apr 2018 16:34:25 +0200 Miklos Szeredi wrote: > This corner case is simply not interesting (modifying a binary while > it is being debugged with uprobe). Let's just concentrate on making > this crash and leak free. Yes please. I'm waiting for a final patch to run my tests. I have

Re: [PATCH] parisc: time: Convert read_persistent_clock() to read_persistent_clock64()

On Thu, Apr 19, 2018 at 8:51 AM, Baolin Wang wrote: > The read_persistent_clock() uses a timespec, which is not year 2038 safe > on 32bit systems. On parisc architecture, we have implemented generic RTC > drivers that can be used to compensate the system suspend time, but

Re: [PATCH] parisc: time: Convert read_persistent_clock() to read_persistent_clock64()

On Thu, Apr 19, 2018 at 8:51 AM, Baolin Wang wrote: > The read_persistent_clock() uses a timespec, which is not year 2038 safe > on 32bit systems. On parisc architecture, we have implemented generic RTC > drivers that can be used to compensate the system suspend time, but the > RTC time can not

Re: [PATCH] m68k: Remove read_persistent_clock()

On Thu, Apr 19, 2018 at 8:22 AM, Baolin Wang wrote: > The read_persistent_clock() uses a timespec, which is not year 2038 safe > on 32bit systems. Moreover on m68k architecture, we have implemented generic > RTC drivers that can be used to compensate the system suspend

Re: [PATCH] m68k: Remove read_persistent_clock()

On Thu, Apr 19, 2018 at 8:22 AM, Baolin Wang wrote: > The read_persistent_clock() uses a timespec, which is not year 2038 safe > on 32bit systems. Moreover on m68k architecture, we have implemented generic > RTC drivers that can be used to compensate the system suspend time. So > we can remove

Re: [PATCH 4/8] sh_eth: Change platform check to CONFIG_ARCH_RENESAS

On 04/20/2018 04:28 PM, Geert Uytterhoeven wrote: > Since commit 9b5ba0df4ea4f940 ("ARM: shmobile: Introduce ARCH_RENESAS") > is CONFIG_ARCH_RENESAS a more appropriate platform check than the legacy > CONFIG_ARCH_SHMOBILE, hence use the former. > > Renesas SuperH SH-Mobile SoCs are still covered

Re: [PATCH 4/8] sh_eth: Change platform check to CONFIG_ARCH_RENESAS

On 04/20/2018 04:28 PM, Geert Uytterhoeven wrote: > Since commit 9b5ba0df4ea4f940 ("ARM: shmobile: Introduce ARCH_RENESAS") > is CONFIG_ARCH_RENESAS a more appropriate platform check than the legacy > CONFIG_ARCH_SHMOBILE, hence use the former. > > Renesas SuperH SH-Mobile SoCs are still covered

Re: Clang arm64 build is broken

[fixing up Christoffer's address] On 20/04/18 15:59, Andrey Konovalov wrote: > On Fri, Apr 20, 2018 at 10:13 AM, Marc Zyngier wrote: >>> The issue is that >>> clang doesn't know about the "S" asm constraint. I reported this to >>> clang [2], and hopefully this will get

Re: Clang arm64 build is broken

[fixing up Christoffer's address] On 20/04/18 15:59, Andrey Konovalov wrote: > On Fri, Apr 20, 2018 at 10:13 AM, Marc Zyngier wrote: >>> The issue is that >>> clang doesn't know about the "S" asm constraint. I reported this to >>> clang [2], and hopefully this will get fixed. In the meantime,

Re: [Linaro-mm-sig] [PATCH 4/8] dma-buf: add peer2peer flag

On Fri, Apr 20, 2018 at 05:46:25AM -0700, Christoph Hellwig wrote: > On Fri, Apr 20, 2018 at 12:44:01PM +0200, Christian König wrote: > > > > What we need is an sg_alloc_table_from_resources(dev, resources, > > > > num_resources) which does the handling common to all drivers. > > > A structure

Re: [Linaro-mm-sig] [PATCH 4/8] dma-buf: add peer2peer flag

On Fri, Apr 20, 2018 at 05:46:25AM -0700, Christoph Hellwig wrote: > On Fri, Apr 20, 2018 at 12:44:01PM +0200, Christian König wrote: > > > > What we need is an sg_alloc_table_from_resources(dev, resources, > > > > num_resources) which does the handling common to all drivers. > > > A structure

Re: [PATCH v3 net-next] net: introduce a new tracepoint for tcp_rcv_space_adjust

Why are you sending this same patch twice? Thank you.

Re: [PATCH v3 net-next] net: introduce a new tracepoint for tcp_rcv_space_adjust

Why are you sending this same patch twice? Thank you.

[PATCH v3 net-next] net: introduce a new tracepoint for tcp_rcv_space_adjust

tcp_rcv_space_adjust is called every time data is copied to user space, introducing a tcp tracepoint for which could show us when the packet is copied to user. When a tcp packet arrives, tcp_rcv_established() will be called and with the existed tracepoint tcp_probe we could get the time when this

[PATCH v3 net-next] net: introduce a new tracepoint for tcp_rcv_space_adjust

tcp_rcv_space_adjust is called every time data is copied to user space, introducing a tcp tracepoint for which could show us when the packet is copied to user. When a tcp packet arrives, tcp_rcv_established() will be called and with the existed tracepoint tcp_probe we could get the time when this

[PATCH net-next v3] net: introduce a new tracepoint for tcp_rcv_space_adjust

tcp_rcv_space_adjust is called every time data is copied to user space, introducing a tcp tracepoint for which could show us when the packet is copied to user. When a tcp packet arrives, tcp_rcv_established() will be called and with the existed tracepoint tcp_probe we could get the time when this

[PATCH net-next v3] net: introduce a new tracepoint for tcp_rcv_space_adjust

tcp_rcv_space_adjust is called every time data is copied to user space, introducing a tcp tracepoint for which could show us when the packet is copied to user. When a tcp packet arrives, tcp_rcv_established() will be called and with the existed tracepoint tcp_probe we could get the time when this

Re: [PATCH] printk: Ratelimit messages printed by console drivers

On Fri, 20 Apr 2018 16:57:20 +0200 Petr Mladek wrote: > No, call_console_drivers() is done with interrupts disabled: > > console_lock_spinning_enable(); > > stop_critical_timings();/* don't trace print latency */ > >

Re: [PATCH] printk: Ratelimit messages printed by console drivers

On Fri, 20 Apr 2018 16:57:20 +0200 Petr Mladek wrote: > No, call_console_drivers() is done with interrupts disabled: > > console_lock_spinning_enable(); > > stop_critical_timings();/* don't trace print latency */ > >

<    3   4   5   6   7   8   9   10   11   12   >