Re: [PATCH] x86/efi: Map EFI memmap entries in-order at runtime

On 8 September 2015 at 22:37, Matt Fleming wrote: > On Tue, 08 Sep, at 03:21:17PM, Ard Biesheuvel wrote: >> >> I noticed that the 64-bit version of efi_map_region() preserves the >> relative alignment with respect to a 2 MB boundary for /each/ region. >> Since the

Re: [PATCH] x86: serialize LVTT and TSC_DEADLINE write

Andi, On Tue, 8 Sep 2015, Andi Kleen wrote: > > Hmm, I didn't mean mfence can't serialize the instructions. For a true > > IO, a serialization can't guarantee device finishes the IO, we generally > > read some safe IO registers to wait IO finish. I completely don't know > > if this case fits

[PATCH 1/2][RFC] time: Fix timekeeping_freqadjust()'s incorrect use of abs() instead of abs64()

The internal clocksteering done for fine-grained error correction uses a logarithmic approximation, so any time adjtimex() adjusts the clock steering, timekeeping_freqadjust() quickly approximates the correct clock frequency over a series of ticks. Unfortunately, the logic in

Re: [PATCH v2] drm/i915: Limit the number of loops for reading a split 64bit register

On Tue, 08 Sep 2015, Daniel Vetter wrote: > On Tue, Sep 08, 2015 at 02:17:13PM +0100, Chris Wilson wrote: >> In I915_READ64_2x32 we attempt to read a 64bit register using 2 32bit >> reads. Due to the nature of the registers we try to read in this manner, >> they may increment

Re: [PATCH] x86/efi: Map EFI memmap entries in-order at runtime

On 9 September 2015 at 11:58, Matt Fleming wrote: > On Wed, 09 Sep, at 09:37:21AM, Ard Biesheuvel wrote: >> On 8 September 2015 at 22:37, Matt Fleming wrote: >> > >> > diff --git a/arch/x86/platform/efi/efi.c b/arch/x86/platform/efi/efi.c >> >

Re: [PATCH] x86/efi: Map EFI memmap entries in-order at runtime

On Wed, 09 Sep, at 09:37:21AM, Ard Biesheuvel wrote: > On 8 September 2015 at 22:37, Matt Fleming wrote: > > > > diff --git a/arch/x86/platform/efi/efi.c b/arch/x86/platform/efi/efi.c > > index 691b333e0038..a2af35f6093a 100644 > > --- a/arch/x86/platform/efi/efi.c > >

Re: [PATCH] x86/efi: Map EFI memmap entries in-order at runtime

On Wed, 09 Sep, at 08:33:07AM, joeyli wrote: > > Yes, the machine on my hand has EFI_PROPERTIES_TABLE enabled, and it doesn't > boot without your patch. Awesome. Could you test the following patch instead? --- >From 24d324b781a3b688dcc265995949a9cf4e8af687 Mon Sep 17 00:00:00 2001 From: Matt

[PATCH for 3.14-stable] NVMe: Initialize device reference count earlier

commit fb35e914b3f88cda9ee6f9d776910c35269c4ecf upstream. If an NVMe device becomes ready but fails to create IO queues, the driver creates a character device handle so the device can be managed. The device reference count needs to be initialized before creating the character device.

Re: [Intel-gfx] [PATCH v3 2/3] drm/i915: Fix userptr deadlock with aliased GTT mmappings

Hi, On 08/10/2015 09:51 AM, Chris Wilson wrote: > Michał Winiarski found a really evil way to trigger a struct_mutex > deadlock with userptr. He found that if he allocated a userptr bo and > then GTT mmaped another bo, or even itself, at the same address as the > userptr using MAP_FIXED, he

Re: [PATCH v3] stmmac: fix check for phydev being open

Hi Sergei, On Tue, 2015-09-08 at 22:53 +0300, Sergei Shtylyov wrote: > Hello. > > On 09/08/2015 03:46 PM, Alexey Brodkin wrote: > > > > > Current check of phydev with IS_ERR(phydev) may make not much sense > > > > because of_phy_connect() returns NULL on failure instead of error value. > > > >

[PATCH v4] stmmac: fix check for phydev being open

Current check of phydev with IS_ERR(phydev) may make not much sense because of_phy_connect() returns NULL on failure instead of error value. Still for checking result of phy_connect() IS_ERR() makes perfect sense. So let's use combined check IS_ERR_OR_NULL() that covers both cases. Cc: Sergei

Re: [Intel-gfx] [PATCH v3 2/3] drm/i915: Fix userptr deadlock with aliased GTT mmappings

On Wed, Sep 09, 2015 at 02:56:16PM +0100, Tvrtko Ursulin wrote: > > Hi, > > On 08/10/2015 09:51 AM, Chris Wilson wrote: > > +out: > > drm_free_large(pvec); > > return ret; > > + > > +err: > > + /* No pages here, no need for the mmu-notifier to wake us */ > > +

Re: [PATCH v4] stmmac: fix check for phydev being open

From: Alexey Brodkin Date: Wed, 9 Sep 2015 18:01:08 +0300 > Current check of phydev with IS_ERR(phydev) may make not much sense > because of_phy_connect() returns NULL on failure instead of error value. > > Still for checking result of phy_connect() IS_ERR() makes

[PATCH 1/2] time: Fix timekeeping_freqadjust()'s incorrect use of abs() instead of abs64()

The internal clocksteering done for fine-grained error correction uses a logarithmic approximation, so any time adjtimex() adjusts the clock steering, timekeeping_freqadjust() quickly approximates the correct clock frequency over a series of ticks. Unfortunately, the logic in

Re: [PATCH] inotify: actually check for invalid bits in sys_inotify_add_watch()

On 06/30/2015 10:36 AM, Dave Hansen wrote: > From: Dave Hansen > > The comment here says that it is checking for invalid bits. But, > the mask is *actually* checking to ensure that _any_ valid bit > is set, which is quite different. > > Add the actual check which

[patch 60/95] hfs: fix B-tree corruption after insertion at position 0

From: Hin-Tak Leung Subject: hfs: fix B-tree corruption after insertion at position 0 Fix B-tree corruption when a new record is inserted at position 0 in the node in hfs_brec_insert(). This is an identical change to the corresponding hfs b-tree code to Sergei

[patch 59/95] hfs,hfsplus: cache pages correctly between bnode_create and bnode_free

From: Hin-Tak Leung Subject: hfs,hfsplus: cache pages correctly between bnode_create and bnode_free Pages looked up by __hfs_bnode_create() (called by hfs_bnode_create() and hfs_bnode_find() for finding or creating pages corresponding to an inode) are immediately

Re: [PATCH] inotify: actually check for invalid bits in sys_inotify_add_watch()

On Wed, Sep 9, 2015 at 5:59 PM, Dave Hansen wrote: > On 06/30/2015 10:36 AM, Dave Hansen wrote: >> From: Dave Hansen >> >> The comment here says that it is checking for invalid bits. But, >> the mask is *actually* checking to ensure that _any_ valid

[patch 82/95] lib/decompressors: use real out buf size for gunzip with kernel

From: Yinghai Lu Subject: lib/decompressors: use real out buf size for gunzip with kernel When loading x86 64bit kernel above 4GiB with patched grub2, got kernel gunzip error. | early console in decompress_kernel | decompress_kernel: | input:

Re: [PATCH] inotify: actually check for invalid bits in sys_inotify_add_watch()

Looks fine to me. And usually akpm picks them up these days. On Wed, 2015-09-09 at 14:59 -0700, Dave Hansen wrote: > On 06/30/2015 10:36 AM, Dave Hansen wrote: > > From: Dave Hansen > > > > The comment here says that it is checking for invalid bits. But, > > the

Re: [PATCH] inotify: actually check for invalid bits in sys_inotify_add_watch()

On 09/09/2015 04:16 PM, Eric Paris wrote: > Looks fine to me. And usually akpm picks them up these days. Is that an Acked-by? :) -- To unsubscribe from this list: send the line "unsubscribe stable" in the body of a message to majord...@vger.kernel.org More majordomo info at

[PATCH 2/2] SCSI: Fix NULL pointer dereference in RTPM of block layer

SCSI: Fix NULL pointer dereference in RTPM of block layer The routines in scsi_pm.c assume that if a runtime-PM callback is invoked for a SCSI device, it can only mean that the device's driver has asked the block layer to handle the runtime power management (by calling blk_pm_runtime_init(),

[PATCH 1/2]Revert "SCSI: Fix NULL pointer dereference in runtime PM"

Revert "SCSI: Fix NULL pointer dereference in runtime PM" This reverts commit 49718f0fb8c9 ("SCSI: Fix NULL pointer dereference in runtime PM") The old commit may lead to a issue that blk_{pre|post}_runtime_suspend and blk_{pre|post}_runtime_resume can not be called in pairs. Take sr device as

Re: [PATCH] x86/efi: Map EFI memmap entries in-order at runtime

Hi, On Wed, Sep 09, 2015 at 12:21:23PM +0100, Matt Fleming wrote: > On Wed, 09 Sep, at 08:33:07AM, joeyli wrote: > > > > Yes, the machine on my hand has EFI_PROPERTIES_TABLE enabled, and it doesn't > > boot without your patch. > > Awesome. Could you test the following patch instead? > > ---

[PATCH] parisc: Filter out spurious interrupts in PA-RISC irq handler

This is a backport of upstream commit b1b4e435e4ef7de77f07bf2a42c8380b960c2d44, which sadly can't easily be cherry-picked because of other conflicting patches which have been applied by Linus in the meantime... Can you please apply it to all stable kernels? Thanks, Helge From: Helge Deller

[PATCH] toshiba_acpi: Fix hotkeys registration on some toshiba models

Commit a2b3471b5b13 ("toshiba_acpi: Use the Hotkey Event Type function for keymap choosing") changed the *setup_keyboard function to query for the Hotkey Event Type to help choose the correct keymap, but turns out that here are certain Toshiba models out there not implementing this feature, and

[merged] vmscan-fix-increasing-nr_isolated-incurred-by-putback-unevictable-pages.patch removed from -mm tree

The patch titled Subject: vmscan: fix increasing nr_isolated incurred by putback unevictable pages has been removed from the -mm tree. Its filename was vmscan-fix-increasing-nr_isolated-incurred-by-putback-unevictable-pages.patch This patch was dropped because it was merged into