[linux-stable-rc CI] Test report for linux-4.14.y/x86

Kernel repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git Branch: linux-4.14.y Arch: x86 Version: 4.14.226-rc1+ Commit: ac6e3f484ce66973debf20d6f035ba453f804c1a Compiler: gcc version 7.3.0 (GCC) All

Re: fixing 4.14-stable's broken DM cache writethrough support [was: Re: [(resend) PATCH v3: {linux-4.14.y} ] dm cache: submit writethrough writes in parallel to origin and cache]

On Wed, Aug 05, 2020 at 03:34:09PM -0400, Mike Snitzer wrote: > On Wed, Aug 05 2020 at 10:32am -0400, > Greg KH wrote: > > > On Tue, Aug 04, 2020 at 02:20:38PM -0400, Mike Snitzer wrote: > > > On Tue, Aug 04 2020 at 8:47am -0400, > > > Greg KH wrote: > > > > > > > On Tue, Aug 04, 2020 at 07:33

Re: [(resend) PATCH v3: {linux-4.14.y} ] dm cache: submit writethrough writes in parallel to origin and cache

On Tue, Aug 04, 2020 at 02:20:38PM -0400, Mike Snitzer wrote: > On Tue, Aug 04 2020 at 8:47am -0400, > Greg KH wrote: > > > On Tue, Aug 04, 2020 at 07:33:05AM -0500, John Donnelly wrote: > > > From: Mike Snitzer > > > > > > Discontinue issuing writethrough write IO in series to the origin and

fixing 4.14-stable's broken DM cache writethrough support [was: Re: [(resend) PATCH v3: {linux-4.14.y} ] dm cache: submit writethrough writes in parallel to origin and cache]

On Wed, Aug 05 2020 at 10:32am -0400, Greg KH wrote: > On Tue, Aug 04, 2020 at 02:20:38PM -0400, Mike Snitzer wrote: > > On Tue, Aug 04 2020 at 8:47am -0400, > > Greg KH wrote: > > > > > On Tue, Aug 04, 2020 at 07:33:05AM -0500, John Donnelly wrote: > > > > From: Mike Snitzer > > > > > > > >

Re: [PATCH v4: {linux-4.14.y} ] dm cache: submit writethrough writes in parallel to origin and cache

On Tue, Aug 04, 2020 at 07:12:46PM -0500, John Donnelly wrote: > > > > On Aug 4, 2020, at 7:07 PM, john.p.donne...@oracle.com wrote: > > > > From: Mike Snitzer > > > > Discontinue issuing writethrough write IO in series to the origin and > > then cache. > > > > Use bio_clone_fast() to create

Re: [PATCH v4: {linux-4.14.y} ] dm cache: submit writethrough writes in parallel to origin and cache

> On Aug 4, 2020, at 7:07 PM, john.p.donne...@oracle.com wrote: > > From: Mike Snitzer > > Discontinue issuing writethrough write IO in series to the origin and > then cache. > > Use bio_clone_fast() to create a new origin clone bio that will be > mapped to the origin device and then bio_cha

[PATCH v4: {linux-4.14.y} ] dm cache: submit writethrough writes in parallel to origin and cache

From: Mike Snitzer Discontinue issuing writethrough write IO in series to the origin and then cache. Use bio_clone_fast() to create a new origin clone bio that will be mapped to the origin device and then bio_chain() it to the bio that gets remapped to the cache device. The origin clone bio doe

Re: [(resend) PATCH v3: {linux-4.14.y} ] dm cache: submit writethrough writes in parallel to origin and cache

On Tue, Aug 04 2020 at 8:47am -0400, Greg KH wrote: > On Tue, Aug 04, 2020 at 07:33:05AM -0500, John Donnelly wrote: > > From: Mike Snitzer > > > > Discontinue issuing writethrough write IO in series to the origin and > > then cache. > > > > Use bio_clone_fast() to create a new origin clone b

Re: [(resend) PATCH v3: {linux-4.14.y} ] dm cache: submit writethrough writes in parallel to origin and cache

d/dm-cache-target.c | 92 ++-- > 1 file changed, 37 insertions(+), 55 deletions(-) Please fix your email client up, it's totally broken and this does not work at all and is getting frustrating from my side here. Try sending emails to yourself and see i

[(resend) PATCH v3: {linux-4.14.y} ] dm cache: submit writethrough writes in parallel to origin and cache

From: Mike Snitzer Discontinue issuing writethrough write IO in series to the origin and then cache. Use bio_clone_fast() to create a new origin clone bio that will be mapped to the origin device and then bio_chain() it to the bio that gets remapped to the cache device. The origin clone bio doe

Re: [PATCH v3: {linux-4.14.y} ] dm cache: submit writethrough writes in parallel to origin and cache

On Mon, Aug 03, 2020 at 12:27:31PM -0500, John Donnelly wrote: > From: Mike Snitzer > > Discontinue issuing writethrough write IO in series to the origin and > then cache. > > Use bio_clone_fast() to create a new origin clone bio that will be > mapped to the origin device and then bio_chain() it

[PATCH v3: {linux-4.14.y} ] dm cache: submit writethrough writes in parallel to origin and cache

From: Mike Snitzer Discontinue issuing writethrough write IO in series to the origin and then cache. Use bio_clone_fast() to create a new origin clone bio that will be mapped to the origin device and then bio_chain() it to the bio that gets remapped to the cache device. The origin clone bio do

Re: [PATCH v2: [linux-4.14.y] ] dm cache: submit writethrough writes in parallel to origin and cache

On 7/31/20 1:54 AM, Greg KH wrote: On Thu, Jul 30, 2020 at 03:33:42PM -0500, John Donnelly wrote: From: Mike Snitzer Discontinue issuing writethrough write IO in series to the origin and then cache. Use bio_clone_fast() to create a new origin clone bio that will be mapped to the origin dev

Re: [PATCH v2: [linux-4.14.y] ] dm cache: submit writethrough writes in parallel to origin and cache

On Thu, Jul 30, 2020 at 03:33:42PM -0500, John Donnelly wrote: > From: Mike Snitzer > > Discontinue issuing writethrough write IO in series to the origin and > then cache. > > Use bio_clone_fast() to create a new origin clone bio that will be > mapped to the origin device and then bio_chain() it

Re: (resend) [PATCH [linux-4.14.y]] dm cache: submit writethrough writes in parallel to origin and cache

On Thu, Jul 30, 2020 at 09:40:32AM -0500, John Donnelly wrote: > > > > On Jul 30, 2020, at 12:21 AM, Greg KH wrote: > > > > On Wed, Jul 29, 2020 at 06:45:46PM -0500, John Donnelly wrote: > >> > >> > >> On 7/29/20 9:16 AM, Mike Snitzer wrote: > >>> On Wed, Jul 29 2020 at 7:55am -0400, > >>> G

[PATCH v2: [linux-4.14.y] ] dm cache: submit writethrough writes in parallel to origin and cache

From: Mike Snitzer Discontinue issuing writethrough write IO in series to the origin and then cache. Use bio_clone_fast() to create a new origin clone bio that will be mapped to the origin device and then bio_chain() it to the bio that gets remapped to the cache device. The origin clone bio do

Re: (resend) [PATCH [linux-4.14.y]] dm cache: submit writethrough writes in parallel to origin and cache

> On Jul 30, 2020, at 12:21 AM, Greg KH wrote: > > On Wed, Jul 29, 2020 at 06:45:46PM -0500, John Donnelly wrote: >> >> >> On 7/29/20 9:16 AM, Mike Snitzer wrote: >>> On Wed, Jul 29 2020 at 7:55am -0400, >>> Greg KH wrote: >>> On Wed, Jul 29, 2020 at 01:51:19PM +0200, Greg KH wrote:

Re: (resend) [PATCH [linux-4.14.y]] dm cache: submit writethrough writes in parallel to origin and cache

On Wed, Jul 29, 2020 at 06:45:46PM -0500, John Donnelly wrote: > > > On 7/29/20 9:16 AM, Mike Snitzer wrote: > > On Wed, Jul 29 2020 at 7:55am -0400, > > Greg KH wrote: > > > > > On Wed, Jul 29, 2020 at 01:51:19PM +0200, Greg KH wrote: > > > > On Mon, Jul 27, 2020 at 11:00:14AM -0400, Mike Sni

Re: (resend) [PATCH [linux-4.14.y]] dm cache: submit writethrough writes in parallel to origin and cache

On 7/29/20 9:16 AM, Mike Snitzer wrote: On Wed, Jul 29 2020 at 7:55am -0400, Greg KH wrote: On Wed, Jul 29, 2020 at 01:51:19PM +0200, Greg KH wrote: On Mon, Jul 27, 2020 at 11:00:14AM -0400, Mike Snitzer wrote: This mail needs to be saent to sta...@vger.kernel.org (now cc'd). Greg et al

Re: (resend) [PATCH [linux-4.14.y]] dm cache: submit writethrough writes in parallel to origin and cache

On Wed, Jul 29 2020 at 7:55am -0400, Greg KH wrote: > On Wed, Jul 29, 2020 at 01:51:19PM +0200, Greg KH wrote: > > On Mon, Jul 27, 2020 at 11:00:14AM -0400, Mike Snitzer wrote: > > > This mail needs to be saent to sta...@vger.kernel.org (now cc'd). > > > > > > Greg et al: please backport 2df3ba

Re: (resend) [PATCH [linux-4.14.y]] dm cache: submit writethrough writes in parallel to origin and cache

On Wed, Jul 29, 2020 at 01:51:19PM +0200, Greg KH wrote: > On Mon, Jul 27, 2020 at 11:00:14AM -0400, Mike Snitzer wrote: > > This mail needs to be saent to sta...@vger.kernel.org (now cc'd). > > > > Greg et al: please backport 2df3bae9a6543e90042291707b8db0cbfbae9ee9 > > Now backported, thanks.

Re: (resend) [PATCH [linux-4.14.y]] dm cache: submit writethrough writes in parallel to origin and cache

On Mon, Jul 27, 2020 at 11:00:14AM -0400, Mike Snitzer wrote: > This mail needs to be saent to sta...@vger.kernel.org (now cc'd). > > Greg et al: please backport 2df3bae9a6543e90042291707b8db0cbfbae9ee9 Now backported, thanks. greg k-h

Re: (resend) [PATCH [linux-4.14.y]] dm cache: submit writethrough writes in parallel to origin and cache

gt; 2df3bae9a6543e90042291707b8db0cbfbae9ee9 >> >> >> Completes the series > > Should we just revert those two commits instead if they're not needed? > > -- > Thanks, > Sasha As I stated above: > Fixes: 705559706d62038b74c5088114c1799cf2c9dce8 (dm bi

Re: (resend) [PATCH [linux-4.14.y]] dm cache: submit writethrough writes in parallel to origin and cache

On Mon, Jul 27 2020 at 4:17pm -0400, Sasha Levin wrote: > On Mon, Jul 27, 2020 at 02:38:52PM -0500, John Donnelly wrote: > > > > > >>On Jul 27, 2020, at 2:18 PM, Sasha Levin wrote: > >> > >>On Mon, Jul 27, 2020 at 11:00:14AM -0400, Mike Snitzer wrote: > >>>This mail needs to be saent to sta...@

Re: (resend) [PATCH [linux-4.14.y]] dm cache: submit writethrough writes in parallel to origin and cache

On Mon, Jul 27, 2020 at 02:38:52PM -0500, John Donnelly wrote: On Jul 27, 2020, at 2:18 PM, Sasha Levin wrote: On Mon, Jul 27, 2020 at 11:00:14AM -0400, Mike Snitzer wrote: This mail needs to be saent to sta...@vger.kernel.org (now cc'd). Greg et al: please backport 2df3bae9a6543e900422917

re: (resend) [PATCH [linux-4.14.y]] dm cache: submit writethrough writes in parallel to origin and cache

> On Jul 27, 2020, at 2:18 PM, Sasha Levin wrote: > > On Mon, Jul 27, 2020 at 11:00:14AM -0400, Mike Snitzer wrote: >> This mail needs to be saent to sta...@vger.kernel.org (now cc'd). >> >> Greg et al: please backport 2df3bae9a6543e90042291707b8db0cbfbae9ee9 > > Hm, what's the issue that th

Re: (resend) [PATCH [linux-4.14.y]] dm cache: submit writethrough writes in parallel to origin and cache

On Mon, Jul 27, 2020 at 11:00:14AM -0400, Mike Snitzer wrote: This mail needs to be saent to sta...@vger.kernel.org (now cc'd). Greg et al: please backport 2df3bae9a6543e90042291707b8db0cbfbae9ee9 Hm, what's the issue that this patch addresses? It's not clear from the commit message. -- Thank

Re: (resend) [PATCH [linux-4.14.y]] dm cache: submit writethrough writes in parallel to origin and cache

This mail needs to be saent to sta...@vger.kernel.org (now cc'd). Greg et al: please backport 2df3bae9a6543e90042291707b8db0cbfbae9ee9 Thanks, Mike On Mon, Jul 27 2020 at 9:40am -0400, John Donnelly wrote: > From: Mike Snitzer > > Discontinue issuing writethrough write IO in series to the o

(resend) [PATCH [linux-4.14.y]] dm cache: submit writethrough writes in parallel to origin and cache

From: Mike Snitzer Discontinue issuing writethrough write IO in series to the origin and then cache. Use bio_clone_fast() to create a new origin clone bio that will be mapped to the origin device and then bio_chain() it to the bio that gets remapped to the cache device. The origin clone bio doe

[PATCH [linux-4.14.y]] dm cache: submit writethrough writes in parallel to origin and cache

From: Mike Snitzer Discontinue issuing writethrough write IO in series to the origin and then cache. Use bio_clone_fast() to create a new origin clone bio that will be mapped to the origin device and then bio_chain() it to the bio that gets remapped to the cache device. The origin clone bio doe

Re: Follow up on hid2hci: Fix udev rules for linux-4.14+

On Wed, Aug 28, 2019 at 1:59 PM Ville Syrjälä wrote: > > On Wed, Aug 28, 2019 at 08:50:51PM +0300, Ville Syrjälä wrote: > > On Wed, Aug 28, 2019 at 01:34:07PM -0400, Dan Streetman wrote: > > > It looks like this patch got lost at some point: > > > https://lore.kernel.org/patchwork/patch/902126/#11

Re: Follow up on hid2hci: Fix udev rules for linux-4.14+

On Wed, Aug 28, 2019 at 08:50:51PM +0300, Ville Syrjälä wrote: > On Wed, Aug 28, 2019 at 01:34:07PM -0400, Dan Streetman wrote: > > It looks like this patch got lost at some point: > > https://lore.kernel.org/patchwork/patch/902126/#1138115 > > > > but it seems to still be a problem and I'd like t

Re: Follow up on hid2hci: Fix udev rules for linux-4.14+

On Wed, Aug 28, 2019 at 01:34:07PM -0400, Dan Streetman wrote: > It looks like this patch got lost at some point: > https://lore.kernel.org/patchwork/patch/902126/#1138115 > > but it seems to still be a problem and I'd like to pull it into Ubuntu: > https://bugs.launchpad.net/ubuntu/+source/bluez/

Follow up on hid2hci: Fix udev rules for linux-4.14+

It looks like this patch got lost at some point: https://lore.kernel.org/patchwork/patch/902126/#1138115 but it seems to still be a problem and I'd like to pull it into Ubuntu: https://bugs.launchpad.net/ubuntu/+source/bluez/+bug/1759836 Ville, did you ever follow up with a v2 for that patch and/

Re: [PATCH v2 BlueZ] hid2hci: Fix udev rules for linux-4.14+

On Wed, Dec 05, 2018 at 09:40:51PM +0200, Ville Syrjälä wrote: > On Wed, Dec 05, 2018 at 08:20:36PM +0100, Greg Kroah-Hartman wrote: > > On Wed, Dec 05, 2018 at 05:40:32PM +0200, Ville Syrjälä wrote: > > > On Wed, Dec 05, 2018 at 08:06:21AM +0100, Greg Kroah-Hartman wrote: > > > > On Tue, Dec 04, 2

Re: [systemd-devel] [PATCH bluez] hid2hci: Fix udev rules for linux-4.14+

On Mon, May 07, 2018 at 04:06:38PM +0300, Ville Syrjala wrote: > From: Ville Syrjälä > > Since commit 1455cf8dbfd0 ("driver core: emit uevents when > device is bound to a driver") the kernel started emitting > "bound" and "unbound" uevents which confuse the hid2hci > udev rules. > > The symptoms

[PATCH bluez] hid2hci: Fix udev rules for linux-4.14+

From: Ville Syrjälä Since commit 1455cf8dbfd0 ("driver core: emit uevents when device is bound to a driver") the kernel started emitting "bound" and "unbound" uevents which confuse the hid2hci udev rules. The symptoms on an affected machine (Dell E5400 in my case) include bluetooth devices not a

Re: stable/linux-4.14.y boot: 108 boots: 0 failed, 107 passed with 1 conflict (v4.14.11)

On Wed, 3 Jan 2018, Paolo Bonzini wrote: > On 03/01/2018 11:36, Thomas Gleixner wrote: > > On Wed, 3 Jan 2018, Guillaume Tucker wrote: > >> On 03/01/18 09:48, Thomas Gleixner wrote: > Well, it turns out this is not exactly a conflict as there's a > subtle difference between the qemu devic

Re: stable/linux-4.14.y boot: 108 boots: 0 failed, 107 passed with 1 conflict (v4.14.11)

On 03/01/2018 11:36, Thomas Gleixner wrote: > On Wed, 3 Jan 2018, Guillaume Tucker wrote: >> On 03/01/18 09:48, Thomas Gleixner wrote: Well, it turns out this is not exactly a conflict as there's a subtle difference between the qemu devices in lab-mhart and in lab-collabora. The one

Re: stable/linux-4.14.y boot: 108 boots: 0 failed, 107 passed with 1 conflict (v4.14.11)

On Wed, 3 Jan 2018, Guillaume Tucker wrote: > On 03/01/18 09:48, Thomas Gleixner wrote: > > > Well, it turns out this is not exactly a conflict as there's a > > > subtle difference between the qemu devices in lab-mhart and in > > > lab-collabora. The ones in lab-collabora are configured to use > >

Re: Linux 4.14 - BUG: unable to handle kernel paging request at ffffffff3bbbe160 IP: audit_signal_cb+0x75/0xf0

led. >>> >>> Can you confirm the sha of your kernel build? If its has some none upstream >>> patches can you provide the sha your kernel is based on. >>> >>> My testing so far were based on bebc6082da0a9f5d47a1ea2edc099bf671058bd4 >>> >>&g

Re: Linux 4.14 - BUG: unable to handle kernel paging request at ffffffff3bbbe160 IP: audit_signal_cb+0x75/0xf0

On 11/27/2017, 06:59 PM, John Johansen wrote: > On 11/23/2017 05:38 AM, Jiri Slaby wrote: >> On 11/22/2017, 04:59 PM, John Johansen wrote: >>> Can you verify the following patch fixes the problem for you >> >> Reportedly, it helps: >> https://apibugzilla.suse.com/show_bug.cgi?id=1069562#c3 >> > >

Re: Linux 4.14 - BUG: unable to handle kernel paging request at ffffffff3bbbe160 IP: audit_signal_cb+0x75/0xf0

On 11/27/2017 10:59 AM, John Johansen wrote: > On 11/23/2017 05:38 AM, Jiri Slaby wrote: >> On 11/22/2017, 04:59 PM, John Johansen wrote: >>> Can you verify the following patch fixes the problem for you >> >> Reportedly, it helps: >> https://apibugzilla.suse.com/show_bug.cgi?id=1069562#c3 >> > > T

Re: Linux 4.14 - BUG: unable to handle kernel paging request at ffffffff3bbbe160 IP: audit_signal_cb+0x75/0xf0

t; >>> Yeah. I forgot mention that detail :) >>> >> So my first attempts to replicate have failed. >> >> Can you confirm the sha of your kernel build? If its has some none upstream >> patches can you provide the sha your kernel is based on. >> >> M

Re: Linux 4.14 - BUG: unable to handle kernel paging request at ffffffff3bbbe160 IP: audit_signal_cb+0x75/0xf0

On 11/23/2017 05:38 AM, Jiri Slaby wrote: > On 11/22/2017, 04:59 PM, John Johansen wrote: >> Can you verify the following patch fixes the problem for you > > Reportedly, it helps: > https://apibugzilla.suse.com/show_bug.cgi?id=1069562#c3 > Thanks Jiri, Unfortunately I wasn't able to access the b

Re: Linux 4.14 - BUG: unable to handle kernel paging request at ffffffff3bbbe160 IP: audit_signal_cb+0x75/0xf0

On Wed, Nov 22, 2017 at 3:59 PM, John Johansen wrote: > Can you verify the following patch fixes the problem for you I am another user with this problem. Thank you for the patch, I tested it with 4.14.2 (built from Debian packaging) and I no longer see audit_signal_cb oops with my apparmor profi

Re: Linux 4.14 - BUG: unable to handle kernel paging request at ffffffff3bbbe160 IP: audit_signal_cb+0x75/0xf0

On 11/22/2017, 04:59 PM, John Johansen wrote: > Can you verify the following patch fixes the problem for you Reportedly, it helps: https://apibugzilla.suse.com/show_bug.cgi?id=1069562#c3 > From 6ba06322267ea931be5f1f559965120d1e09b030 Mon Sep 17 00:00:00 2001 > From: John Johansen > Date: Wed, 2

Re: Linux 4.14 - BUG: unable to handle kernel paging request at ffffffff3bbbe160 IP: audit_signal_cb+0x75/0xf0

Can you verify the following patch fixes the problem for you --- >From 6ba06322267ea931be5f1f559965120d1e09b030 Mon Sep 17 00:00:00 2001 From: John Johansen Date: Wed, 22 Nov 2017 07:33:38 -0800 Subject: [PATCH] apparmor: fix oops in audit_signal_cb hook The apparmor_audit_data struct ordering

Re: Linux 4.14 - BUG: unable to handle kernel paging request at ffffffff3bbbe160 IP: audit_signal_cb+0x75/0xf0

On 11/21/2017 10:02 AM, Shuah Khan wrote: > On 11/21/2017 10:44 AM, John Johansen wrote: >> On 11/21/2017 08:58 AM, Shuah Khan wrote: >>> Hi John, >>> >>> I am seeing the following on my laptop. Unfortunately this is my primary >>> system and my ability to bisect might be a bit limited. The system

Re: Linux 4.14 - BUG: unable to handle kernel paging request at ffffffff3bbbe160 IP: audit_signal_cb+0x75/0xf0

On 11/21/2017 10:44 AM, John Johansen wrote: > On 11/21/2017 08:58 AM, Shuah Khan wrote: >> Hi John, >> >> I am seeing the following on my laptop. Unfortunately this is my primary >> system and my ability to bisect might be a bit limited. The system is >> running >> >> 4.14.0+ #4 SMP Tue Nov 14 19

Re: Linux 4.14 - BUG: unable to handle kernel paging request at ffffffff3bbbe160 IP: audit_signal_cb+0x75/0xf0

On 11/21/2017 08:58 AM, Shuah Khan wrote: > Hi John, > > I am seeing the following on my laptop. Unfortunately this is my primary > system and my ability to bisect might be a bit limited. The system is > running > > 4.14.0+ #4 SMP Tue Nov 14 19:25:58 MST 2017 x86_64 x86_64 x86_64 GNU/Linux > >

Linux 4.14 - BUG: unable to handle kernel paging request at ffffffff3bbbe160 IP: audit_signal_cb+0x75/0xf0

Hi John, I am seeing the following on my laptop. Unfortunately this is my primary system and my ability to bisect might be a bit limited. The system is running 4.14.0+ #4 SMP Tue Nov 14 19:25:58 MST 2017 x86_64 x86_64 x86_64 GNU/Linux on Ubuntu 17.10 base. Is this a known issue? Please see the

Linux 4.14

utemov (1): x86/mm: Fix ELF_ET_DYN_BASE for 5-level paging Kristian Evensen (1): qmi_wwan: Add missing skb_reset_mac_header-call Li Bin (1): workqueue: Fix NULL pointer dereference Linus Torvalds (3): Revert "scsi: make 'state' device attribute pol

Linux 4.14-rc8

Leo Liu (2): drm/amdgpu: return -ENOENT from uvd 6.0 early init for harvesting drm/amdgpu: allow harvesting check for Polaris VCE Leon Romanovsky (1): RDMA/nldev: Enforce device index check for port callback Linus Torvalds (4): Mark 'ioremap_page_range()' as possibly slee

[GIT PULL] Final KVM fixes for Linux 4.14 (rc8 or final)

Linus, The following changes since commit cc9085b6875323fd0c935ee7176583bb572821ee: Merge branch 'kvm-ppc-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc (2017-10-19 14:42:09 +0200) are available in the git repository at: git://git.kernel.org/pub/scm/virt/kvm/kvm.g

Re: Linux 4.14-rc6: WARNING: CPU: 9 PID: 5377 at arch/x86/events/intel/core.c:2228 intel_pmu_handle_irq+0x4a8/0x4c0

On Mon, Oct 30, 2017 at 11:49:54PM +0100, Fengguang Wu wrote: > On Mon, Oct 30, 2017 at 11:02:58AM +0100, Peter Zijlstra wrote: > > On Mon, Oct 30, 2017 at 07:27:36AM +0100, Fengguang Wu wrote: > > > > > [ 189.480568] perf: interrupt took too long (5132 > 4982), lowering > > > kernel.perf_event_

Re: Linux 4.14-rc6: WARNING: CPU: 9 PID: 5377 at arch/x86/events/intel/core.c:2228 intel_pmu_handle_irq+0x4a8/0x4c0

On Mon, Oct 30, 2017 at 11:02:58AM +0100, Peter Zijlstra wrote: On Mon, Oct 30, 2017 at 07:27:36AM +0100, Fengguang Wu wrote: [ 189.480568] perf: interrupt took too long (5132 > 4982), lowering kernel.perf_event_max_sample_rate to 38000 [ 189.690660] perf: interrupt took too long (6582 > 641

Re: Linux 4.14-rc6: WARNING: CPU: 9 PID: 5377 at arch/x86/events/intel/core.c:2228 intel_pmu_handle_irq+0x4a8/0x4c0

On Mon, Oct 30, 2017 at 07:27:36AM +0100, Fengguang Wu wrote: > [ 189.480568] perf: interrupt took too long (5132 > 4982), lowering > kernel.perf_event_max_sample_rate to 38000 > [ 189.690660] perf: interrupt took too long (6582 > 6415), lowering > kernel.perf_event_max_sample_rate to 3 >

Linux 4.14-rc6: WARNING: CPU: 9 PID: 5377 at arch/x86/events/intel/core.c:2228 intel_pmu_handle_irq+0x4a8/0x4c0

CC perf maintainers. On Sun, Oct 29, 2017 at 11:51:55PM +0100, Fengguang Wu wrote: Hi Linus, Up to now we see the below boot error/warnings when testing v4.14-rc6. They hit the RC release mainly due to various imperfections in 0day's auto bisection. So I manually list them here and CC the like

Re: Linux 4.14-rc6

Hi Linus, Up to now we see the below boot error/warnings when testing v4.14-rc6. They hit the RC release mainly due to various imperfections in 0day's auto bisection. So I manually list them here and CC the likely easy to debug ones to the corresponding maintainers in the followup emails. boot_

Linux 4.14-rc7

sc arrays by id Linus Torvalds (3): Revert "apparmor: add base infastructure for socket mediation" Fix tracing sample code warning. Linux 4.14-rc7 Lionel Landwerlin (1): drm/i915/perf: fix perf enable/disable ioctls with 32bits userspace Long Li (1): CIFS: SMB

Linux 4.14: Reported regressions as of Sunday, 2017-10-29

Hi! Find below my fourth regression report for Linux 4.14. It lists 6 regressions I'm currently aware of; for most of them fixes are in the work. 4 regressions got fixed since last weeks report; 1 turned out to not be a regression. As always: Are you aware of any other regressions? Then p

Re: Linux 4.14-rc6 bisected regression tun devices not working anymore in openvpn

From: Cong Wang Date: Sat, 28 Oct 2017 10:37:27 -0700 > On Sat, Oct 28, 2017 at 7:57 AM, Sander Eikelenboom > wrote: >> The offending commit is: >> 0ad646c81b2182f7fa67ec0c8c825e0ee165696d >> "tun: call dev_get_valid_name() before register_netdevice()" >> >> Reverting this commit fixes t

Re: Linux 4.14-rc6 bisected regression tun devices not working anymore in openvpn

On Sat, Oct 28, 2017 at 7:57 AM, Sander Eikelenboom wrote: > L.S., > > While testing a linux 4.14-rc6 kernel i noticed OpenVPN didn't function > anymore. > My openvpn config uses tun devices and is pretty standard. > The openvpn version is current Debian stable: openvpn

Linux 4.14-rc6 bisected regression tun devices not working anymore in openvpn

L.S., While testing a linux 4.14-rc6 kernel i noticed OpenVPN didn't function anymore. My openvpn config uses tun devices and is pretty standard. The openvpn version is current Debian stable: openvpn 2.4.0-6+deb9u2 >From the openvpn logging: Sat Oct 28 16:03:34 2017 us=175829

Linux 4.14-rc6

tools/power turbostat: stop migrating, unless '-m'" Li Zhijian (1): perf test shell trace+probe_libc_inet_pton.sh: Be compatible with Debian/Ubuntu Linus Torvalds (1): Linux 4.14-rc6 Linus Walleij (1): ARM: dts: fix PCLK name on Gemini and MOXA ART Loic Poulain (1):

Re: linux-4.14-rc3/drivers/net/ieee802154/atusb.c:827: pointless test ?

Hello. [Sorry for the delay, not really at my machine the last few weeks] On 10/06/2017 09:06 PM, David Binderman wrote: > Hello there, > > linux-4.14-rc3/drivers/net/ieee802154/atusb.c:827]: (style) Unsigned variable > 'fw_ver_maj' can't be negative so i

Linux 4.14-rc5

ing nested EPT KVM: MMU: always terminate page walks at level 1 Len Brown (1): x86/apic: Update TSC_DEADLINE quirk with additional SKX stepping Lin Zhang (1): netfilter: SYNPROXY: skip non-tcp packet in {ipv4, ipv6}_synproxy_hook Linus Torvalds (1): Linux 4.14-rc5 Lu

[Kernel.org Helpdesk #46182] [linuxfoundation.org #46182] Re: Linux 4.14-rc2 (bad patch file on kernel.org)

On Sun 2017-09-24 20:43:45, Linus Torvalds wrote: > On Sun, Sep 24, 2017 at 8:41 PM, Linus Torvalds > wrote: > > > > But I just tried it myself, and get the same breakage. In fact, the > > patch it downloads is exactly 50397184 bytes in size. > > Side note: instead of downloading a 50MB patch, yo

Re: Linux 4.14-rc2 (bad patch file on kernel.org)

On Sun 2017-09-24 20:43:45, Linus Torvalds wrote: > On Sun, Sep 24, 2017 at 8:41 PM, Linus Torvalds > wrote: > > > > But I just tried it myself, and get the same breakage. In fact, the > > patch it downloads is exactly 50397184 bytes in size. > > Side note: instead of downloading a 50MB patch, yo

Re: Linux 4.14: Reported regressions as of Sunday, 2017-10-15

On Sun, Oct 15, 2017 at 02:55:24PM +0200, Thorsten Leemhuis wrote: > == Fixed since last report == > > "hangs when building e.g. perf" & "Random insta-reboots on AMD Phenom II" > Status: Fixed by https://git.kernel.org/torvalds/c/67bb8e999e0a That should be: b956575bed91 ("x86/mm: Flush more aggr

Linux 4.14: Reported regressions as of Sunday, 2017-10-15

Hi! Find below my third regression report for Linux 4.14. It lists 9 regressions I'm currently aware of. Two regressions got fixed since last weeks report. As always: Are you aware of any other regressions? Then please let me know by mail (a simple bounce or forward in my direction is e

Re: Linux 4.14: Reported regressions as of Sunday, 2017-10-08

On Sunday, October 8, 2017 2:37:41 PM CEST Thorsten Leemhuis wrote: > Hi! Find below my second regression report for Linux 4.14. It lists 8 > regressions I'm currently aware of. One regression was fixed since last > weeks report. One was in there that shouldn't have been there.

Re: linux-4.14-rc3/arch/powerpc/perf/imc-pmu.c:599: pointless test ?

Hi David, On Monday 09 October 2017 10:31 AM, Michael Ellerman wrote: David Binderman writes: Hello there, linux-4.14-rc3/arch/powerpc/perf/imc-pmu.c:599]: (style) Unsigned variable 'ncpu' can't be negative so it is unnecessary to test it. Source code is if (nc

Re: linux-4.14-rc3/arch/powerpc/perf/imc-pmu.c:599: pointless test ?

David Binderman writes: > Hello there, > > linux-4.14-rc3/arch/powerpc/perf/imc-pmu.c:599]: (style) Unsigned variable > 'ncpu' can't be negative so it is unnecessary to test it. > > Source code is > > if (ncpu >= 0 && ncpu < nr_

Re: Linux 4.14-rc4

On Sun, 2017-10-08 at 21:18 -0700, Linus Torvalds wrote: > Another week, another -rc. Any idea if you want to break up MAINTAINERS?

Linux 4.14-rc4

libiscsi: Fix use-after-free race during iscsi_session_teardown scsi: libiscsi: Remove iscsi_destroy_session Kirill A. Shutemov (1): include/linux/mm.h: fix typo in VM_MPX definition Kirill Tkhai (1): ksm: fix unlocked iteration over vmas in cmp_and_merge_page() Linus Torvalds

Re: Linux 4.14: Reported regressions as of Sunday, 2017-10-08

On Sun, Oct 08, 2017 at 02:37:41PM +0200, Thorsten Leemhuis wrote: > Hi! Find below my second regression report for Linux 4.14. It lists 8 > regressions I'm currently aware of. One regression was fixed since last > weeks report. One was in there that shouldn't have been the

Linux 4.14: Reported regressions as of Sunday, 2017-10-08

Hi! Find below my second regression report for Linux 4.14. It lists 8 regressions I'm currently aware of. One regression was fixed since last weeks report. One was in there that shouldn't have been there. As always: Are you aware of any other regressions? Then please let me know by mail

Linux 4.14-rc3

ort discard Konstantin Khlebnikov (1): quota: add missing lock into __dquot_transfer() Ladi Prosek (1): KVM: nVMX: fix HOST_CR3/HOST_CR4 cache Laurent Dufour (1): x86/mm: Fix fault error path using unsafe vma pointer Leon Romanovsky (1): IB/core: Fix typo in the n

Linux 4.14: Reported regressions as of Sunday, 2017-10-01

Hi! Find below my first regression report for Linux 4.14. It lists 4 regressions I'm currently aware of (two of the reports are my own). I skimmed LKML, bugzilla.kernel.org, but those were all I found that looked worthy. And nobody pointed me to any regressions directly. Sigh. Either we are

[GIT PULL] KVM fixes for Linux 4.14-rc3

Linus, The following changes since commit 5753743fa5108b8f98bd61e40dc63f641b26c768: KVM: VMX: remove WARN_ON_ONCE in kvm_vcpu_trigger_posted_interrupt (2017-09-19 15:09:16 +0200) are available in the git repository at: git://git.kernel.org/pub/scm/virt/kvm/kvm.git tags/for-linus for you t

RE: linux-4.14-rc2/drivers/acpi/acpica/utmath.c: 2 * suspicious expression ?

ubject: linux-4.14-rc2/drivers/acpi/acpica/utmath.c: 2 * suspicious > expression ? > > Hello there, > > [linux-4.14-rc2/drivers/acpi/acpica/utmath.c:137] -> > [linux-4.14-rc2/drivers/acpi/acpica/utmath.c:137]: > (style) Same expression on both sides of '^='

Re: linux-4.14-rc2/drivers/hwmon/pmbus/pmbus_core.c:1086]: (style) Redundant condition

On Mon, Sep 25, 2017 at 01:54:02PM +, David Binderman wrote: > > Hello there, > > linux-4.14-rc2/drivers/hwmon/pmbus/pmbus_core.c:1086]: (style) Redundant > condition: upper. '!upper || (upper && data->has_status_word)' is equivalent > to '!uppe

[Kernel.org Helpdesk #46182] Re: Linux 4.14-rc2 (bad patch file on kernel.org)

On 2017-09-24 22:57:37, rdun...@infradead.org wrote: > On 09/24/17 17:03, Linus Torvalds wrote: > > I'm back to my usual Sunday release schedule, and rc2 is out there in > > all the normal places. > > Downloading & applying 4.14-rc2 [patch] >

[Kernel.org Helpdesk #46182] [linuxfoundation.org #46182] Re: Linux 4.14-rc2 (bad patch file on kernel.org)

On Sun, Sep 24, 2017 at 7:57 PM, Randy Dunlap wrote: > > Downloading & applying 4.14-rc2 [patch] > > > from kernel.org (home page) gives me a file that does not apply cleanly to > v4.13: Hmm. Th

[Kernel.org Helpdesk #46182] [linuxfoundation.org #46182] Re: Linux 4.14-rc2 (bad patch file on kernel.org)

On Sun, Sep 24, 2017 at 8:41 PM, Linus Torvalds wrote: > > But I just tried it myself, and get the same breakage. In fact, the > patch it downloads is exactly 50397184 bytes in size. Side note: instead of downloading a 50MB patch, you could probably use the same amount of bandwidth to download an

Re: Linux 4.14-rc2 (bad patch file on kernel.org)

On Sun, Sep 24, 2017 at 8:41 PM, Linus Torvalds wrote: > > But I just tried it myself, and get the same breakage. In fact, the > patch it downloads is exactly 50397184 bytes in size. Side note: instead of downloading a 50MB patch, you could probably use the same amount of bandwidth to download an

Re: Linux 4.14-rc2 (bad patch file on kernel.org)

On Sun, Sep 24, 2017 at 7:57 PM, Randy Dunlap wrote: > > Downloading & applying 4.14-rc2 [patch] > > > from kernel.org (home page) gives me a file that does not apply cleanly to > v4.13: Hmm. Th

Re: Linux 4.14-rc2 (bad patch file on kernel.org)

On 09/24/17 17:03, Linus Torvalds wrote: > I'm back to my usual Sunday release schedule, and rc2 is out there in > all the normal places. Downloading & applying 4.14-rc2 [patch] from kernel.org (

Linux 4.14-rc2

LEROY Christophe (3): crypto: talitos - fix sha224 crypto: talitos - fix hashing crypto: talitos - Don't provide setkey for non hmac hashing algs. Lee, Shawn C (2): drm/i915/bxt: set min brightness from VBT drm/i915/cnp: set min brightness from VBT Leon Romanovsky (

Re: linux-4.14-rc1/arch/powerpc/perf/hv-24x7.c:541: bad condition ?

[ + Cody in case he's still interested] Michael Ellerman writes: > David Binderman writes: > >> Hello there, >> >> linux-4.14-rc1/arch/powerpc/perf/hv-24x7.c:543]: (warning) Identical >> condition 's1> >> Source code is >> >

Re: linux-4.14-rc1/arch/x86/include/asm/uaccess.h: Missing include of

Hi, changing the include line to solves the problem for me. Thank you for taking the time to look into this. Best regards, Stefan Mätje Am 19.09.2017 um 15:12 schrieb Seraphime Kirkovski: > Hi, > >> ./arch/x86/include/asm/uaccess.h: In function ‘set_fs’: >> ./arch/x86/include/asm/uacc

Re: linux-4.14-rc1/arch/x86/include/asm/uaccess.h: Missing include of

Hi, > ./arch/x86/include/asm/uaccess.h: In function ‘set_fs’: > ./arch/x86/include/asm/uaccess.h:31:9: error: dereferencing pointer to > incomplete type I can reproduce your problem by including , but not with . #include //#include does compile #include int

linux-4.14-rc1/arch/x86/include/asm/uaccess.h: Missing include of

Resend with changed subject: Hi, there is a change in Linus' mainline kernel for 4.14-rc1 (https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/arch/x86/include/asm/uaccess.h?id=6c51e67b64d169419fb13318035bb442f9176612) that changes the set_fs() macro into an inline function.

Re: linux-4.14-rc1/arch/powerpc/perf/hv-24x7.c:541: bad condition ?

David Binderman writes: > Hello there, > > linux-4.14-rc1/arch/powerpc/perf/hv-24x7.c:543]: (warning) Identical > condition 's1 > Source code is > > if (s1 < s2) > return 1; > if (s2 > s1) > return -1; > > Suggest code rewor

Re: linux-4.14-rc1/drivers/clk/clk-stm32h7.c: 2 * possible typo ?

I missed David ... On 09/19/2017 11:22 AM, Gabriel FERNANDEZ wrote: > Hi David, > > I confirm it's typo issue. I 'm ready to send a fix for that. > > Many Thank's > > Gabriel > >> Hello there, >> >> 1. >> >> linux-4.14-rc1/dri

Re: linux-4.14-rc1/drivers/clk/clk-stm32h7.c: 2 * possible typo ?

Hi David, I confirm it's typo issue. I 'm ready to send a fix for that. Many Thank's Gabriel > Hello there, > > 1. > > linux-4.14-rc1/drivers/clk/clk-stm32h7.c:387]: (style) Same expression > on both sides of '&&'. > > Source code is

Re: linux-4.14-rc1/kernel/sysctl.c:2188: possible cut'n'paste error ?

On Mon, Sep 18, 2017 at 1:53 PM, David Binderman wrote: > Hello there, > > linux-4.14-rc1/kernel/sysctl.c:2188] -> > [linux-4.14-rc1/kernel/sysctl.c:2190]: (warning) Identical condition > '*lvalp>UINT_MAX', second condition is always false > > Source code

Linux 4.14-rc1

Yes, I realize this is a day early, and yes, I realize that if I had waited until tomorrow, I would also have hit the 26th anniversary of the Linux-0.01 release, but neither of those undeniable facts made me want to wait with closing the mege window. This has been an "interesting" merge window. It

  1   2   >