Re: [PATCH v3] nvmet: fix nvmet_execute_write_zeroes function

On 4/2/2018 8:38 PM, Keith Busch wrote: Thanks, I've applied the patch with a simpler changelog explaining the bug. Thanks Rodrigo and Keith, I've tested with/w.o the patch and it works well (with the fix only). -Max. ___ Linux-nvme mailing

Re: [PATCH v3] nvmet: fix nvmet_execute_write_zeroes function

On 4/2/2018 8:38 PM, Keith Busch wrote: Thanks, I've applied the patch with a simpler changelog explaining the bug. Thanks Rodrigo and Keith, I've tested with/w.o the patch and it works well (with the fix only). -Max. ___ Linux-nvme mailing

Re: Signal handling in a page fault handler

On Tue, Apr 03, 2018 at 07:48:29AM -0700, Matthew Wilcox wrote: > On Tue, Apr 03, 2018 at 03:12:35PM +0200, Thomas Hellstrom wrote: > > I think the TTM page fault handler originally set the standard for this. > > First, IMO any critical section that waits for the GPU (like typically the > > page

Re: Signal handling in a page fault handler

On Tue, Apr 03, 2018 at 07:48:29AM -0700, Matthew Wilcox wrote: > On Tue, Apr 03, 2018 at 03:12:35PM +0200, Thomas Hellstrom wrote: > > I think the TTM page fault handler originally set the standard for this. > > First, IMO any critical section that waits for the GPU (like typically the > > page

Re: [GIT PULL] Kernel lockdown for secure boot

[re-added cc's, I think. Sorry, I think I failed to use the gmane gateway correctly there.] On Tue, Apr 3, 2018 at 12:06 AM, David Howells wrote: > Andy Lutomirski wrote: > >> This is an attempt at a review. I'm replying here because I can't find the >>

Re: [GIT PULL] Kernel lockdown for secure boot

[re-added cc's, I think. Sorry, I think I failed to use the gmane gateway correctly there.] On Tue, Apr 3, 2018 at 12:06 AM, David Howells wrote: > Andy Lutomirski wrote: > >> This is an attempt at a review. I'm replying here because I can't find the >> actual relevant patch emails. > > This

Re: [PATCH 00/15] ARM: pxa: switch to DMA slave maps

On 2 April 2018 at 16:26, Robert Jarzmik wrote: > Hi, > > This serie is aimed at removing the dmaengine slave compat use, and transfer > knowledge of the DMA requestors into architecture code. > > This was discussed/advised by Arnd a couple of years back, it's almost time.

Re: [PATCH 00/15] ARM: pxa: switch to DMA slave maps

On 2 April 2018 at 16:26, Robert Jarzmik wrote: > Hi, > > This serie is aimed at removing the dmaengine slave compat use, and transfer > knowledge of the DMA requestors into architecture code. > > This was discussed/advised by Arnd a couple of years back, it's almost time. > > The serie is

Re: call/normal switch was Re: omap4-droid4: voice call support was

* Tony Lindgren [180402 15:59]: > * Dan Williams [180402 15:51]: > > On Sun, 2018-04-01 at 10:30 -0700, Tony Lindgren wrote: > > > * Tony Lindgren [180401 15:38]: > > > Found it! Here's what I need to do over n_gsm: > > > > > > ngsm 1

Re: call/normal switch was Re: omap4-droid4: voice call support was

* Tony Lindgren [180402 15:59]: > * Dan Williams [180402 15:51]: > > On Sun, 2018-04-01 at 10:30 -0700, Tony Lindgren wrote: > > > * Tony Lindgren [180401 15:38]: > > > Found it! Here's what I need to do over n_gsm: > > > > > > ngsm 1 "AT+CFUN=1" > > > ngsm 1 "AT+CFUN?" > > > ngsm 2

Re: [RFC PATCH v3 1/3] ima: extend clone() with IMA namespace support

On Mon, Apr 02, 2018 at 07:20:54AM -0400, Stefan Berger wrote: Good morning to everyone. > On 03/29/2018 01:44 PM, Dr. Greg Wettstein wrote: > >On Mar 28, 8:44am, Stefan Berger wrote: > >} Subject: Re: [RFC PATCH v3 1/3] ima: extend clone() with IMA namespace > >sup > > > >Good morning, I hope

Re: [RFC PATCH v3 1/3] ima: extend clone() with IMA namespace support

On Mon, Apr 02, 2018 at 07:20:54AM -0400, Stefan Berger wrote: Good morning to everyone. > On 03/29/2018 01:44 PM, Dr. Greg Wettstein wrote: > >On Mar 28, 8:44am, Stefan Berger wrote: > >} Subject: Re: [RFC PATCH v3 1/3] ima: extend clone() with IMA namespace > >sup > > > >Good morning, I hope

[PATCH v1] perf stat: enable 1ms interval for printing event counters values

Currently print count interval for performance counters values is limited by 10ms so reading the values at frequencies higher than 100Hz is restricted by the tool. This change makes perf stat -I possible on frequencies up to 1KHz and, to some extent, makes perf stat -I to be on-par with perf

[PATCH v1] perf stat: enable 1ms interval for printing event counters values

Currently print count interval for performance counters values is limited by 10ms so reading the values at frequencies higher than 100Hz is restricted by the tool. This change makes perf stat -I possible on frequencies up to 1KHz and, to some extent, makes perf stat -I to be on-par with perf

Re: [PATCH v2 1/3] locking: Document the semantics of spin_is_locked()

On Tue, Apr 03, 2018 at 04:43:00PM +0200, Peter Zijlstra wrote: > On Tue, Apr 03, 2018 at 07:17:18AM -0700, Paul E. McKenney wrote: > > Suggestions for a fix? Clearly great care is required when using it > > in things like WARN_ON()... > > Yeah, don't use it there, use lockdep_assert_held().

Re: [PATCH v2 1/3] locking: Document the semantics of spin_is_locked()

On Tue, Apr 03, 2018 at 04:43:00PM +0200, Peter Zijlstra wrote: > On Tue, Apr 03, 2018 at 07:17:18AM -0700, Paul E. McKenney wrote: > > Suggestions for a fix? Clearly great care is required when using it > > in things like WARN_ON()... > > Yeah, don't use it there, use lockdep_assert_held().

Re: [PATCH v2 11/17] kvm: arm64: Configure VTCR per VM

Hi Suzuki, On 27/03/18 14:15, Suzuki K Poulose wrote: > We set VTCR_EL2 very early during the stage2 init and don't > touch it ever. This is fine as we had a fixed IPA size. This > patch changes the behavior to set the VTCR for a given VM, > depending on its stage2 table. The common configuration

Re: [PATCH v2 11/17] kvm: arm64: Configure VTCR per VM

Hi Suzuki, On 27/03/18 14:15, Suzuki K Poulose wrote: > We set VTCR_EL2 very early during the stage2 init and don't > touch it ever. This is fine as we had a fixed IPA size. This > patch changes the behavior to set the VTCR for a given VM, > depending on its stage2 table. The common configuration

general protection fault in ucma_set_ib_path (2)

Hello, syzbot hit the following crash on upstream commit 642e7fd23353e22290e3d51719fcb658dc252342 (Tue Apr 3 04:22:12 2018 +) Merge branch 'syscalls-next' of git://git.kernel.org/pub/scm/linux/kernel/git/brodo/linux syzbot dashboard link:

general protection fault in ucma_set_ib_path (2)

Hello, syzbot hit the following crash on upstream commit 642e7fd23353e22290e3d51719fcb658dc252342 (Tue Apr 3 04:22:12 2018 +) Merge branch 'syscalls-next' of git://git.kernel.org/pub/scm/linux/kernel/git/brodo/linux syzbot dashboard link:

Re: [PATCH] rtc: isl12022: use true and false for boolean values

On 22/03/2018 14:53:28-0500, Gustavo A. R. Silva wrote: > Assign true or false to boolean variables instead of an integer value. > > This issue was detected with the help of Coccinelle. > > Signed-off-by: Gustavo A. R. Silva > --- > drivers/rtc/rtc-isl12022.c | 2 +- >

Re: [PATCH] rtc: isl12022: use true and false for boolean values

On 22/03/2018 14:53:28-0500, Gustavo A. R. Silva wrote: > Assign true or false to boolean variables instead of an integer value. > > This issue was detected with the help of Coccinelle. > > Signed-off-by: Gustavo A. R. Silva > --- > drivers/rtc/rtc-isl12022.c | 2 +- > 1 file changed, 1

Re: [PATCH] rtc: mt7622: fix module autoloading for OF platform drivers

On 26/03/2018 18:05:52+0800, sean.w...@mediatek.com wrote: > From: Sean Wang > > It's required to create a modules.alias via MODULE_DEVICE_TABLE helper > for the OF platform driver. Otherwise, module autoloading cannot work. > > Signed-off-by: Sean Wang

Re: [PATCH] rtc: mt7622: fix module autoloading for OF platform drivers

On 26/03/2018 18:05:52+0800, sean.w...@mediatek.com wrote: > From: Sean Wang > > It's required to create a modules.alias via MODULE_DEVICE_TABLE helper > for the OF platform driver. Otherwise, module autoloading cannot work. > > Signed-off-by: Sean Wang > --- > drivers/rtc/rtc-mt7622.c | 1 +

Re: [RESEND] [PATCH] rtc: snvs: Fix usage of snvs_rtc_enable

On 28/03/2018 20:14:05+0100, Bryan O'Donoghue wrote: > commit 179a502f8c46 ("rtc: snvs: add Freescale rtc-snvs driver") introduces > the SNVS RTC driver with a function snvs_rtc_enable(). > > snvs_rtc_enable() can return an error on the enable path however this > driver does not currently trap

Re: [RESEND] [PATCH] rtc: snvs: Fix usage of snvs_rtc_enable

On 28/03/2018 20:14:05+0100, Bryan O'Donoghue wrote: > commit 179a502f8c46 ("rtc: snvs: add Freescale rtc-snvs driver") introduces > the SNVS RTC driver with a function snvs_rtc_enable(). > > snvs_rtc_enable() can return an error on the enable path however this > driver does not currently trap

Re: [PATCH] memcg, thp: do not invoke oom killer on thp charges

On Wed, Mar 21, 2018 at 09:59:28PM +0100, Michal Hocko wrote: > From: Michal Hocko > > David has noticed that THP memcg charge can trigger the oom killer > since 2516035499b9 ("mm, thp: remove __GFP_NORETRY from khugepaged and > madvised allocations"). We have used an explicit

Re: [PATCH] memcg, thp: do not invoke oom killer on thp charges

On Wed, Mar 21, 2018 at 09:59:28PM +0100, Michal Hocko wrote: > From: Michal Hocko > > David has noticed that THP memcg charge can trigger the oom killer > since 2516035499b9 ("mm, thp: remove __GFP_NORETRY from khugepaged and > madvised allocations"). We have used an explicit __GFP_NORETRY >

Re: [PATCH 4.4 22/97] scsi: virtio_scsi: Always try to read VPD pages

On Fri, 2018-03-23 at 10:54 +0100, Greg Kroah-Hartman wrote: > 4.4-stable review patch.  If anyone has any objections, please let me know. > > -- > > From: David Gibson > > > [ Upstream commit 25d1d50e23275e141e3a3fe06c25a99f4c4bf4e0 ] [...] This

Re: [PATCH 4.4 22/97] scsi: virtio_scsi: Always try to read VPD pages

On Fri, 2018-03-23 at 10:54 +0100, Greg Kroah-Hartman wrote: > 4.4-stable review patch.  If anyone has any objections, please let me know. > > -- > > From: David Gibson > > > [ Upstream commit 25d1d50e23275e141e3a3fe06c25a99f4c4bf4e0 ] [...] This is an incomplete fix as it

Re: [PATCH 0/5] KVM: x86: hyperv: PV TLB flush for Windows guests

Roman Kagan writes: > On Mon, Apr 02, 2018 at 06:10:54PM +0200, Vitaly Kuznetsov wrote: >> >> Feature description: >> >> PV TLB flush helps a lot when running overcommited. KVM gained support for >> it recently but it is only available for Linux guests. Windows guests use

Re: [PATCH 0/5] KVM: x86: hyperv: PV TLB flush for Windows guests

Roman Kagan writes: > On Mon, Apr 02, 2018 at 06:10:54PM +0200, Vitaly Kuznetsov wrote: >> >> Feature description: >> >> PV TLB flush helps a lot when running overcommited. KVM gained support for >> it recently but it is only available for Linux guests. Windows guests use >> emulated Hyper-V

Re: [PATCH] memcg, thp: do not invoke oom killer on thp charges

On Wed, Mar 21, 2018 at 02:22:13PM -0700, David Rientjes wrote: > PAGE_ALLOC_COSTLY_ORDER is a heuristic used by the page allocator because > it cannot free high-order contiguous memory. Memcg just needs to reclaim > a number of pages. Two order-3 charges can cause a memcg oom kill but now >

Re: [PATCH] memcg, thp: do not invoke oom killer on thp charges

On Wed, Mar 21, 2018 at 02:22:13PM -0700, David Rientjes wrote: > PAGE_ALLOC_COSTLY_ORDER is a heuristic used by the page allocator because > it cannot free high-order contiguous memory. Memcg just needs to reclaim > a number of pages. Two order-3 charges can cause a memcg oom kill but now >

Re: [PATCH v3] vsprintf: Prevent crash when dereferencing invalid pointers

On Tue 2018-04-03 16:40:58, Andy Shevchenko wrote: > On Tue, 2018-04-03 at 15:13 +0200, Petr Mladek wrote: > > On Tue 2018-04-03 14:54:18, Andy Shevchenko wrote: > > > On Tue, 2018-04-03 at 13:46 +0200, Petr Mladek wrote: > > > > On Mon 2018-04-02 17:15:23, Andy Shevchenko wrote: > > > We have a

Re: [PATCH v3] vsprintf: Prevent crash when dereferencing invalid pointers

On Tue 2018-04-03 16:40:58, Andy Shevchenko wrote: > On Tue, 2018-04-03 at 15:13 +0200, Petr Mladek wrote: > > On Tue 2018-04-03 14:54:18, Andy Shevchenko wrote: > > > On Tue, 2018-04-03 at 13:46 +0200, Petr Mladek wrote: > > > > On Mon 2018-04-02 17:15:23, Andy Shevchenko wrote: > > > We have a

Re: [PATCH 1/6] drivers/i2c: Update i2c_trace_msg static key to modern api

On Mon, Mar 26, 2018 at 02:09:24PM -0700, Davidlohr Bueso wrote: > No changes in refcount semantics -- key init is false; replace > > static_key_slow_inc|dec with static_branch_inc|dec > static_key_false with static_branch_unlikely > > Added a '_key' suffix to i2c_trace_msg, for

Re: [PATCH 1/6] drivers/i2c: Update i2c_trace_msg static key to modern api

On Mon, Mar 26, 2018 at 02:09:24PM -0700, Davidlohr Bueso wrote: > No changes in refcount semantics -- key init is false; replace > > static_key_slow_inc|dec with static_branch_inc|dec > static_key_false with static_branch_unlikely > > Added a '_key' suffix to i2c_trace_msg, for

Re: Signal handling in a page fault handler

On Tue, Apr 03, 2018 at 03:12:35PM +0200, Thomas Hellstrom wrote: > I think the TTM page fault handler originally set the standard for this. > First, IMO any critical section that waits for the GPU (like typically the > page fault handler does), should be locked at least killable. The need for >

Re: Signal handling in a page fault handler

On Tue, Apr 03, 2018 at 03:12:35PM +0200, Thomas Hellstrom wrote: > I think the TTM page fault handler originally set the standard for this. > First, IMO any critical section that waits for the GPU (like typically the > page fault handler does), should be locked at least killable. The need for >

Re: stable-rc build: 4 warnings 0 failures (stable-rc/v4.15.15)

On Sat, Mar 31, 2018 at 7:49 PM, Olof's autobuilder wrote: > Warnings: > > arm64.allmodconfig: > WARNING: modpost: missing MODULE_LICENSE() in > drivers/phy/qualcomm/phy-qcom-ufs.o This needs a backport of 59fba0869aca ("phy: qcom-ufs: add MODULE_LICENSE tag")

RE: [PATCH] x86/smpboot: Don't do mwait_play_dead() on AMD systems

> -Original Message- > From: Ingo Molnar On Behalf Of Ingo Molnar > Sent: Tuesday, April 3, 2018 10:41 AM > To: Ghannam, Yazen > Cc: x...@kernel.org; linux-kernel@vger.kernel.org; b...@suse.de > Subject: Re: [PATCH] x86/smpboot: Don't do

RE: [PATCH] x86/smpboot: Don't do mwait_play_dead() on AMD systems

> -Original Message- > From: Ingo Molnar On Behalf Of Ingo Molnar > Sent: Tuesday, April 3, 2018 10:41 AM > To: Ghannam, Yazen > Cc: x...@kernel.org; linux-kernel@vger.kernel.org; b...@suse.de > Subject: Re: [PATCH] x86/smpboot: Don't do mwait_play_dead() on AMD > systems > > > *

Re: stable-rc build: 4 warnings 0 failures (stable-rc/v4.15.15)

On Sat, Mar 31, 2018 at 7:49 PM, Olof's autobuilder wrote: > Warnings: > > arm64.allmodconfig: > WARNING: modpost: missing MODULE_LICENSE() in > drivers/phy/qualcomm/phy-qcom-ufs.o This needs a backport of 59fba0869aca ("phy: qcom-ufs: add MODULE_LICENSE tag") Arnd

Re: [GIT PULL] f2fs update for 4.16-rc1

Hi Tejun, On Tue, 3 Apr 2018 07:20:29 -0700 Tejun Heo wrote: > > Hello, Stephen. > > On Tue, Apr 03, 2018 at 12:29:19PM +1000, Stephen Rothwell wrote: > > > I am still applying this to the merge of the btrfs tree every day ... > > > > > > Commit > > > 578c647879f7 ("f2fs:

Re: [GIT PULL] f2fs update for 4.16-rc1

Hi Tejun, On Tue, 3 Apr 2018 07:20:29 -0700 Tejun Heo wrote: > > Hello, Stephen. > > On Tue, Apr 03, 2018 at 12:29:19PM +1000, Stephen Rothwell wrote: > > > I am still applying this to the merge of the btrfs tree every day ... > > > > > > Commit > > > 578c647879f7 ("f2fs: implement cgroup

Re: [PATCH v4 1/3] Add notrace to lib/ucmpdi2.c

On Tue, Apr 03, 2018 at 02:51:06PM +0100, Matt Redfearn wrote: > On 29/03/18 22:59, Palmer Dabbelt wrote: > > Ah, thanks, I think I must have forgotten about this.  I assume these > > three are going through your tree? > > Yeah I think that's the plan - James will need your ack to patch 2 if >

Re: [PATCH v4 1/3] Add notrace to lib/ucmpdi2.c

On Tue, Apr 03, 2018 at 02:51:06PM +0100, Matt Redfearn wrote: > On 29/03/18 22:59, Palmer Dabbelt wrote: > > Ah, thanks, I think I must have forgotten about this.  I assume these > > three are going through your tree? > > Yeah I think that's the plan - James will need your ack to patch 2 if >

Re: [PATCH v2 1/3] locking: Document the semantics of spin_is_locked()

On Tue, Apr 03, 2018 at 07:17:18AM -0700, Paul E. McKenney wrote: > Suggestions for a fix? Clearly great care is required when using it > in things like WARN_ON()... Yeah, don't use it there, use lockdep_assert_held(). As I stated before in this thread, ideally we'd make *_is_locked() go away

Re: [PATCH v2 1/3] locking: Document the semantics of spin_is_locked()

On Tue, Apr 03, 2018 at 07:17:18AM -0700, Paul E. McKenney wrote: > Suggestions for a fix? Clearly great care is required when using it > in things like WARN_ON()... Yeah, don't use it there, use lockdep_assert_held(). As I stated before in this thread, ideally we'd make *_is_locked() go away

Re: [RESEND] rtc: snvs: Fix usage of snvs_rtc_enable

Hi, On 02/04/2018 at 23:51:12 +0100, Bryan O'Donoghue wrote: > On 30/03/18 23:59, Trent Piepho wrote: > > However, I think that even if the driver fails to probe if there is a > > timeout at probe time, it's still possible to hang later if there are > > not limits to the hardware polling loops,

Re: [RESEND] rtc: snvs: Fix usage of snvs_rtc_enable

Hi, On 02/04/2018 at 23:51:12 +0100, Bryan O'Donoghue wrote: > On 30/03/18 23:59, Trent Piepho wrote: > > However, I think that even if the driver fails to probe if there is a > > timeout at probe time, it's still possible to hang later if there are > > not limits to the hardware polling loops,

Re: [PATCH v6 10/21] tracing: probeevent: Return consumed bytes of dynamic area

On Mon, 2 Apr 2018 16:02:07 -0400 Steven Rostedt wrote: > On Sat, 17 Mar 2018 21:44:52 +0900 > Masami Hiramatsu wrote: > > > -static nokprobe_inline void > > -fetch_store_string(unsigned long addr, void *dest) > > +static nokprobe_inline int > >

Re: [PATCH v6 10/21] tracing: probeevent: Return consumed bytes of dynamic area

On Mon, 2 Apr 2018 16:02:07 -0400 Steven Rostedt wrote: > On Sat, 17 Mar 2018 21:44:52 +0900 > Masami Hiramatsu wrote: > > > -static nokprobe_inline void > > -fetch_store_string(unsigned long addr, void *dest) > > +static nokprobe_inline int > > +fetch_store_string(unsigned long addr, void

Re: [PATCH] x86/smpboot: Don't do mwait_play_dead() on AMD systems

* Ghannam, Yazen wrote: > > -Original Message- > > From: Ingo Molnar On Behalf Of Ingo Molnar > > Sent: Tuesday, April 3, 2018 7:04 AM > > To: Ghannam, Yazen > > Cc: x...@kernel.org;

Re: [PATCH] x86/smpboot: Don't do mwait_play_dead() on AMD systems

* Ghannam, Yazen wrote: > > -Original Message- > > From: Ingo Molnar On Behalf Of Ingo Molnar > > Sent: Tuesday, April 3, 2018 7:04 AM > > To: Ghannam, Yazen > > Cc: x...@kernel.org; linux-kernel@vger.kernel.org; b...@suse.de > > Subject: Re: [PATCH] x86/smpboot: Don't do

[PATCH v2] x86/xen/efi: Initialize UEFI secure boot state during dom0 boot

Initialize UEFI secure boot state during dom0 boot. Otherwise the kernel may not even know that it runs on secure boot enabled platform. Signed-off-by: Daniel Kiper --- arch/x86/xen/efi.c| 57 +

[PATCH v2] x86/xen/efi: Initialize UEFI secure boot state during dom0 boot

Initialize UEFI secure boot state during dom0 boot. Otherwise the kernel may not even know that it runs on secure boot enabled platform. Signed-off-by: Daniel Kiper --- arch/x86/xen/efi.c| 57 + drivers/firmware/efi/libstub/secureboot.c |

Re: [PATCH v17 01/10] LIB: Introduce a generic PIO mapping method

On Tue, Apr 03, 2018 at 04:04:10PM +0200, Thierry Reding wrote: > On Thu, Mar 15, 2018 at 02:15:50AM +0800, John Garry wrote: > > From: Zhichang Yuan > > > > In commit 41f8bba7f555 ("of/pci: Add pci_register_io_range() and > > pci_pio_to_address()"), a new I/O space

Re: [PATCH v17 01/10] LIB: Introduce a generic PIO mapping method

On Tue, Apr 03, 2018 at 04:04:10PM +0200, Thierry Reding wrote: > On Thu, Mar 15, 2018 at 02:15:50AM +0800, John Garry wrote: > > From: Zhichang Yuan > > > > In commit 41f8bba7f555 ("of/pci: Add pci_register_io_range() and > > pci_pio_to_address()"), a new I/O space management was supported.

[GIT PULL] workqueue changes for v4.17-rc1

Hello, Linus. rcu_work addition and a couple trivial changes. Thanks. The following changes since commit c698ca5278934c0ae32297a8725ced2e27585d7f: Linux 4.16-rc6 (2018-03-18 17:48:42 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/tj/wq.git

[GIT PULL] workqueue changes for v4.17-rc1

Hello, Linus. rcu_work addition and a couple trivial changes. Thanks. The following changes since commit c698ca5278934c0ae32297a8725ced2e27585d7f: Linux 4.16-rc6 (2018-03-18 17:48:42 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/tj/wq.git

[PATCH] lockdep: Add print_irqtrace_events() to __warn

From: "Steven Rostedt (VMware)" Running a test on a x86_32 kernel I triggered a bug that an interrupt disable/enable isn't being catched by lockdep. At least knowing where the last one was found would be helpful, but the warnings that are produced do not show this

[PATCH] lockdep: Add print_irqtrace_events() to __warn

From: "Steven Rostedt (VMware)" Running a test on a x86_32 kernel I triggered a bug that an interrupt disable/enable isn't being catched by lockdep. At least knowing where the last one was found would be helpful, but the warnings that are produced do not show this information. Even without

[PATCH v4 0/1] can: ucan: add driver for Theobroma Systems UCAN devices

This is v4 of the Theobroma Systems CAN/USB "UCAN" adapter driver upstreaming effort. v3 -> v4 changes: * get rid of a few repeated le16_to_cpu casts by storing the value once * fix canid masking logic * drop __func__ from log messages. Use netdev_* where possible, use UCAN_DRIVER_NAME where

[PATCH v4 1/1] can: ucan: add driver for Theobroma Systems UCAN devices

The UCAN driver supports the microcontroller-based USB/CAN adapters from Theobroma Systems. There are two form-factors that run essentially the same firmware: * Seal: standalone USB stick ( https://www.theobroma-systems.com/seal ) * Mule: integrated on the PCB of various System-on-Modules from

[PATCH v4 0/1] can: ucan: add driver for Theobroma Systems UCAN devices

This is v4 of the Theobroma Systems CAN/USB "UCAN" adapter driver upstreaming effort. v3 -> v4 changes: * get rid of a few repeated le16_to_cpu casts by storing the value once * fix canid masking logic * drop __func__ from log messages. Use netdev_* where possible, use UCAN_DRIVER_NAME where

[PATCH v4 1/1] can: ucan: add driver for Theobroma Systems UCAN devices

The UCAN driver supports the microcontroller-based USB/CAN adapters from Theobroma Systems. There are two form-factors that run essentially the same firmware: * Seal: standalone USB stick ( https://www.theobroma-systems.com/seal ) * Mule: integrated on the PCB of various System-on-Modules from

[GIT PULL] libata changes for v4.17-rc1

Hello, Linus. Nothing too interesting. The biggest change is refcnting fix for ata_host - the bug is recent and can only be triggered on controller hotplug, so very few are hitting it. There also are a number of trivial license / error message changes and some hardware specific changes.

[GIT PULL] libata changes for v4.17-rc1

Hello, Linus. Nothing too interesting. The biggest change is refcnting fix for ata_host - the bug is recent and can only be triggered on controller hotplug, so very few are hitting it. There also are a number of trivial license / error message changes and some hardware specific changes.

[PATCH v4 1/2] media: ov2680: dt: Add bindings for OV2680

Add device tree binding documentation for the OV2680 camera sensor. Reviewed-by: Rob Herring CC: devicet...@vger.kernel.org Signed-off-by: Rui Miguel Silva --- .../devicetree/bindings/media/i2c/ov2680.txt | 40 ++ 1 file changed,

[PATCH v4 1/2] media: ov2680: dt: Add bindings for OV2680

Add device tree binding documentation for the OV2680 camera sensor. Reviewed-by: Rob Herring CC: devicet...@vger.kernel.org Signed-off-by: Rui Miguel Silva --- .../devicetree/bindings/media/i2c/ov2680.txt | 40 ++ 1 file changed, 40 insertions(+) create mode 100644

Re: [PATCH 1/6] x86/intel_rdt/mba_sc: Add documentation for MBA software controller

On Tue, 3 Apr 2018, Thomas Gleixner wrote: > On Thu, 29 Mar 2018, Vikas Shivappa wrote: > You said above: > > > This may lead to confusion in scenarios below: > > Reading the blurb after that creates even more confusion than being > helpful. > > First of all this information should not be under

Re: [PATCH 1/6] x86/intel_rdt/mba_sc: Add documentation for MBA software controller

On Tue, 3 Apr 2018, Thomas Gleixner wrote: > On Thu, 29 Mar 2018, Vikas Shivappa wrote: > You said above: > > > This may lead to confusion in scenarios below: > > Reading the blurb after that creates even more confusion than being > helpful. > > First of all this information should not be under

[PATCH v4 2/2] media: ov2680: Add Omnivision OV2680 sensor driver

This patch adds V4L2 sub-device driver for OV2680 image sensor. The OV2680 is a 1/5" CMOS color sensor from Omnivision. Supports output format: 10-bit Raw RGB. The OV2680 has a single lane MIPI interface. The driver exposes following V4L2 controls: - auto/manual exposure, - exposure, -

[PATCH v4 2/2] media: ov2680: Add Omnivision OV2680 sensor driver

This patch adds V4L2 sub-device driver for OV2680 image sensor. The OV2680 is a 1/5" CMOS color sensor from Omnivision. Supports output format: 10-bit Raw RGB. The OV2680 has a single lane MIPI interface. The driver exposes following V4L2 controls: - auto/manual exposure, - exposure, -

[PATCH v4 0/2] media: Introduce Omnivision OV2680 driver

Add driver and bindings for the OV2680 2 megapixel CMOS 1/5" sensor, which has a single MIPI lane interface and output format of 10-bit Raw RGB. Features supported are described in PATCH 2/2. v3->v4: Sakari Ailus: - remove auto_{exposure|gain}_enable and direct call the set functions - add

[PATCH v4 0/2] media: Introduce Omnivision OV2680 driver

Add driver and bindings for the OV2680 2 megapixel CMOS 1/5" sensor, which has a single MIPI lane interface and output format of 10-bit Raw RGB. Features supported are described in PATCH 2/2. v3->v4: Sakari Ailus: - remove auto_{exposure|gain}_enable and direct call the set functions - add

Re: [PATCH] net: improve ipv4 performances

Hi Anton, everyone, On 04/01/18 15:31, Anton Gary Ceph wrote: > As the Linux networking stack is growing, more and more protocols are > added, increasing the complexity of stack itself. > Modern processors, contrary to common belief, are very bad in branch > prediction, so it's our task to give

Re: [PATCH] net: improve ipv4 performances

Hi Anton, everyone, On 04/01/18 15:31, Anton Gary Ceph wrote: > As the Linux networking stack is growing, more and more protocols are > added, increasing the complexity of stack itself. > Modern processors, contrary to common belief, are very bad in branch > prediction, so it's our task to give

Re: [GIT PULL] siginfo fix for v4.16-rc5

Geert Uytterhoeven writes: > Hi Eric, > > On Mon, Apr 2, 2018 at 10:17 PM, Eric W. Biederman > wrote: >> Eugene Syromiatnikov writes: >> >>> So, the offset of the si_lower field is 20 at the current HEAD and was 18 at >>> commits

Re: [GIT PULL] siginfo fix for v4.16-rc5

Geert Uytterhoeven writes: > Hi Eric, > > On Mon, Apr 2, 2018 at 10:17 PM, Eric W. Biederman > wrote: >> Eugene Syromiatnikov writes: >> >>> So, the offset of the si_lower field is 20 at the current HEAD and was 18 at >>> commits v4.16-rc3~17^2 and v4.16-rc1~159^2~20. I believe this is due to

Re: problem with bio handling on raid5 and pblk

> On 23 Mar 2018, at 13.52, Javier González wrote: > >> On 22 Mar 2018, at 18.00, Matias Bjørling wrote: >> >> On 03/22/2018 03:34 PM, Javier González wrote: >>> Hi, >>> I have been looking into a bug report when using pblk and raid5 on top >>> and I am

Re: problem with bio handling on raid5 and pblk

> On 23 Mar 2018, at 13.52, Javier González wrote: > >> On 22 Mar 2018, at 18.00, Matias Bjørling wrote: >> >> On 03/22/2018 03:34 PM, Javier González wrote: >>> Hi, >>> I have been looking into a bug report when using pblk and raid5 on top >>> and I am having problems understanding if the

Re: [GIT PULL] f2fs update for 4.16-rc1

Hello, Stephen. On Tue, Apr 03, 2018 at 12:29:19PM +1000, Stephen Rothwell wrote: > > I am still applying this to the merge of the btrfs tree every day ... > > > > Commit > > 578c647879f7 ("f2fs: implement cgroup writeback support") > > was merged into Linus' tree on Jan 31. > > > > Here is

Re: [GIT PULL] f2fs update for 4.16-rc1

Hello, Stephen. On Tue, Apr 03, 2018 at 12:29:19PM +1000, Stephen Rothwell wrote: > > I am still applying this to the merge of the btrfs tree every day ... > > > > Commit > > 578c647879f7 ("f2fs: implement cgroup writeback support") > > was merged into Linus' tree on Jan 31. > > > > Here is

Re: [PATCH v1] kernel/trace:check the val against the available mem

On Tue, 3 Apr 2018 15:56:07 +0200 Michal Hocko wrote: > On Tue 03-04-18 09:32:45, Steven Rostedt wrote: > > On Tue, 3 Apr 2018 14:35:14 +0200 > > Michal Hocko wrote: > [...] > > > Being clever is OK if it doesn't add a tricky code. And relying on > > >

Re: [PATCH v1] kernel/trace:check the val against the available mem

On Tue, 3 Apr 2018 15:56:07 +0200 Michal Hocko wrote: > On Tue 03-04-18 09:32:45, Steven Rostedt wrote: > > On Tue, 3 Apr 2018 14:35:14 +0200 > > Michal Hocko wrote: > [...] > > > Being clever is OK if it doesn't add a tricky code. And relying on > > > si_mem_available is definitely tricky

Re: [PATCH 4.4 15/97] genirq: Use irqd_get_trigger_type to compare the trigger type for shared IRQs

On Fri, 2018-03-23 at 10:54 +0100, Greg Kroah-Hartman wrote: > 4.4-stable review patch.  If anyone has any objections, please let me know. > > -- > > From: Hans de Goede > > > [ Upstream commit 382bd4de61827dbaaf5fb4fb7b1f4be4a86505e7 ] > > When

Re: [PATCH 4.4 15/97] genirq: Use irqd_get_trigger_type to compare the trigger type for shared IRQs

On Fri, 2018-03-23 at 10:54 +0100, Greg Kroah-Hartman wrote: > 4.4-stable review patch.  If anyone has any objections, please let me know. > > -- > > From: Hans de Goede > > > [ Upstream commit 382bd4de61827dbaaf5fb4fb7b1f4be4a86505e7 ] > > When requesting a shared irq with

Re: [PATCH v2 1/3] locking: Document the semantics of spin_is_locked()

On Tue, Apr 03, 2018 at 02:52:33PM +0100, David Howells wrote: > Andrea Parri wrote: > > > > It's more complicated than that. This function is dangerous and should be > > > used with extreme care. In the case where CONFIG_SMP=n the value is > > > locked > >

Re: [PATCH v2 1/3] locking: Document the semantics of spin_is_locked()

On Tue, Apr 03, 2018 at 02:52:33PM +0100, David Howells wrote: > Andrea Parri wrote: > > > > It's more complicated than that. This function is dangerous and should be > > > used with extreme care. In the case where CONFIG_SMP=n the value is > > > locked > > > one way or the other and it might

Re: [PATCH v2 1/3] locking: Document the semantics of spin_is_locked()

On Tue, Apr 03, 2018 at 02:52:33PM +0100, David Howells wrote: > Andrea Parri wrote: > > > > It's more complicated than that. This function is dangerous and should be > > > used with extreme care. In the case where CONFIG_SMP=n the value is > > > locked > >

Re: [PATCH v2 1/3] locking: Document the semantics of spin_is_locked()

On Tue, Apr 03, 2018 at 02:52:33PM +0100, David Howells wrote: > Andrea Parri wrote: > > > > It's more complicated than that. This function is dangerous and should be > > > used with extreme care. In the case where CONFIG_SMP=n the value is > > > locked > > > one way or the other and it might

Re: [PATCH v5 03/14] PCI: Add pcie_bandwidth_capable() to compute max supported link bandwidth

On Mon, Apr 02, 2018 at 05:30:54PM -0700, Jacob Keller wrote: > On Mon, Apr 2, 2018 at 7:05 AM, Bjorn Helgaas wrote: > > +/* PCIe speed to Mb/s reduced by encoding overhead */ > > +#define PCIE_SPEED2MBS_ENC(speed) \ > > + ((speed) == PCIE_SPEED_16_0GT ?

Re: [PATCH v5 03/14] PCI: Add pcie_bandwidth_capable() to compute max supported link bandwidth

On Mon, Apr 02, 2018 at 05:30:54PM -0700, Jacob Keller wrote: > On Mon, Apr 2, 2018 at 7:05 AM, Bjorn Helgaas wrote: > > +/* PCIe speed to Mb/s reduced by encoding overhead */ > > +#define PCIE_SPEED2MBS_ENC(speed) \ > > + ((speed) == PCIE_SPEED_16_0GT ? (16000*(128/130)) : \ > > +

Re: [PATCH v17 01/10] LIB: Introduce a generic PIO mapping method

On Thu, Mar 15, 2018 at 02:15:50AM +0800, John Garry wrote: > From: Zhichang Yuan > > In commit 41f8bba7f555 ("of/pci: Add pci_register_io_range() and > pci_pio_to_address()"), a new I/O space management was supported. With > that driver, the I/O ranges configured for

Re: [PATCH v17 01/10] LIB: Introduce a generic PIO mapping method

On Thu, Mar 15, 2018 at 02:15:50AM +0800, John Garry wrote: > From: Zhichang Yuan > > In commit 41f8bba7f555 ("of/pci: Add pci_register_io_range() and > pci_pio_to_address()"), a new I/O space management was supported. With > that driver, the I/O ranges configured for PCI/PCIe hosts on some >

Re: [PATCH v17 04/10] PCI: Apply the new generic I/O management on PCI IO hosts

On 03/04/2018 14:45, Thierry Reding wrote: On Thu, Mar 15, 2018 at 02:15:53AM +0800, John Garry wrote: From: Zhichang Yuan After introducing the new generic I/O space management(Logical PIO), the original PCI MMIO relevant helpers need to be updated based on the

Re: [PATCH v17 04/10] PCI: Apply the new generic I/O management on PCI IO hosts

On 03/04/2018 14:45, Thierry Reding wrote: On Thu, Mar 15, 2018 at 02:15:53AM +0800, John Garry wrote: From: Zhichang Yuan After introducing the new generic I/O space management(Logical PIO), the original PCI MMIO relevant helpers need to be updated based on the new interfaces defined in

<    6   7   8   9   10   11   12   13   14   15   >