Andrew,
Here is a new version to the pud_write() fix [1], and some follow-on
patches to use the '_access_permitted' helpers in fault and
get_user_pages() paths where we are checking if the thread has access to
write. I explicitly omit conversions for places where the kernel is
checking the _PAGE_RW flag for kernel purposes, not for userspace
access.
Beyond fixing the crash, this series also fixes get_user_pages() and
fault paths to honor protection keys in the same manner as
get_user_pages_fast(). Only the crash fix is tagged for -stable as the
protection key check is done just for consistency reasons since
userspace can change protection keys at will.
[1]: https://lists.01.org/pipermail/linux-nvdimm/2017-November/013237.html
---
Dan Williams (4):
mm: fix device-dax pud write-faults triggered by get_user_pages()
mm: replace pud_write with pud_access_permitted in fault + gup paths
mm: replace pmd_write with pmd_access_permitted in fault + gup paths
mm: replace pte_write with pte_access_permitted in fault + gup paths
arch/sparc/mm/gup.c | 4 ++--
arch/x86/include/asm/pgtable.h | 6 ++++++
fs/dax.c | 3 ++-
include/asm-generic/pgtable.h | 9 +++++++++
include/linux/hugetlb.h | 8 --------
mm/gup.c | 2 +-
mm/hmm.c | 8 ++++----
mm/huge_memory.c | 6 +++---
mm/memory.c | 8 ++++----
9 files changed, 31 insertions(+), 23 deletions(-)
2017-10-26 09:13+0200, Paolo Bonzini:
> For many years some users of assigned devices have reported worse
> performance on AMD processors with NPT than on AMD without NPT,
> Intel or bare metal.
>
> The reason turned out to be that SVM is discarding the guest PAT
> setting and uses the default (PA0=PA4=WB, PA1=PA5=WT, PA2=PA6=UC-,
> PA3=UC). The guest might be using a different setting, and
> especially might want write combining but isn't getting it
> (instead getting slow UC or UC- accesses).
>
> Thanks a lot to geoff(a)hostfission.com for noticing the relation
> to the g_pat setting. The patch has been tested also by a bunch
> of people on VFIO users forums.
>
> Fixes: 709ddebf81cb40e3c36c6109a7892e8b93a09464
> Fixes: https://bugzilla.kernel.org/show_bug.cgi?id=196409
> Cc: stable(a)vger.kernel.org
> Signed-off-by: Paolo Bonzini <pbonzini(a)redhat.com>
Applied, thanks.
On Mon, Nov 06, 2017 at 06:06:19AM -0500, Mimi Zohar wrote:
> Hi Greg,
>
> On Sun, 2017-11-05 at 15:18 +0100, gregkh(a)linuxfoundation.org wrote:
> > The patch below does not apply to the 4.9-stable tree.
> > If someone wants it applied there, or to any other stable or longterm
> > tree, then please email the backport, including the original git commit
> > id to <stable(a)vger.kernel.org>.
> >
> > thanks,
> >
> > greg k-h
>
> This commit needs to prereq commit ee618b4619b7 "KEYS: trusted:
> sanitize all key material".
Thanks, that fixes the issue for 4.4 and 4.9, but not for 3.18 :(
thanks,
greg k-h
On Mon, Nov 06, 2017 at 10:19:51PM -0800, Eric Biggers wrote:
> From: Eric Biggers <ebiggers(a)google.com>
>
> On a non-preemptible kernel, if KEYCTL_DH_COMPUTE is called with the
> largest permitted inputs (16384 bits), the kernel spends 10+ seconds
> doing modular exponentiation in mpi_powm() without rescheduling. If all
> threads do it, it locks up the system. Moreover, it can cause
> rcu_sched-stall warnings.
>
> Notwithstanding the insanity of doing this calculation in kernel mode
> rather than in userspace, fix it by calling cond_resched() as each bit
> from the exponent is processed. It's still noninterruptible, but at
> least it's preemptible now.
>
> Cc: stable(a)vger.kernel.org # v4.12+
> Signed-off-by: Eric Biggers <ebiggers(a)google.com>
Patch applied. Thanks.
--
Email: Herbert Xu <herbert(a)gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
On Fri, 10 Nov 2017 12:40:39 +0200, Felipe Balbi wrote:
> John Keeping <john(a)metanate.com> writes:
> > This check has gone through several incompatible variations in commits
> > 53642399aa71 ("usb: gadget: f_fs: Fix wrong check on reserved1 of
> > OS_DESC_EXT_COMPAT"), 354bc45bf329 ("usb: gadget: f_fs: Fix ExtCompat
> > descriptor validation") and 3ba534df815f ("Revert "usb: gadget: f_fs:
> > Fix ExtCompat descriptor validation"") after initially being introduced
> > in commit f0175ab51993 ("usb: gadget: f_fs: OS descriptors support").
> >
> > The various changes make it impossible for a single userspace
> > implementation to work with different kernel versions, so let's just
> > drop the condition to avoid breaking userspace.
> >
> > Fixes: 53642399aa71 ("usb: gadget: f_fs: Fix wrong check on reserved1 of OS_DESC_EXT_COMPAT")
> > Cc: stable(a)vger.kernel.org # v4.7+
> > Signed-off-by: John Keeping <john(a)metanate.com>
> > ---
> > drivers/usb/gadget/function/f_fs.c | 3 +--
> > 1 file changed, 1 insertion(+), 2 deletions(-)
> >
> > diff --git a/drivers/usb/gadget/function/f_fs.c b/drivers/usb/gadget/function/f_fs.c
> > index 652397eda6d6..0d9962834345 100644
> > --- a/drivers/usb/gadget/function/f_fs.c
> > +++ b/drivers/usb/gadget/function/f_fs.c
> > @@ -2282,8 +2282,7 @@ static int __ffs_data_do_os_desc(enum ffs_os_desc_type type,
> > int i;
> >
> > if (len < sizeof(*d) ||
> > - d->bFirstInterfaceNumber >= ffs->interfaces_count ||
> > - !d->Reserved1)
> > + d->bFirstInterfaceNumber >= ffs->interfaces_count)
> > return -EINVAL;
> > for (i = 0; i < ARRAY_SIZE(d->Reserved2); ++i)
> > if (d->Reserved2[i])
>
> Sorry, but no. We want to be compliant with the specification. If there
> are older still-maintained stable trees which are not working, we need
> to backport a fix to them, but we're not allowing uncompliant
> implementations.
Aren't we allowing non-compliant implementations now? The spec says the
value must be 1 but since v4.7 this code has allowed all non-zero
values.
At this point I don't think the kernel can disallow any values of
Reserved1 without breaking someone's userspace.
From: Laurent Pinchart <laurent.pinchart+renesas(a)ideasonboard.com>
Since commit 4a97a3da420b ("drm: Don't update property values for atomic
drivers") atomic drivers must not update property values as properties
are read from the state instead. To catch remaining users, the
drm_object_property_set_value() function now throws a warning when
called by atomic drivers on non-immutable properties, and we hit that
warning when creating connectors.
The easy fix is to just remove the drm_object_property_set_value() as it
is used here to set the initial value of the connector's DPMS property
to OFF. The DPMS property applies on top of the connector's state crtc
pointer (initialized to NULL) that is the main connector on/off control,
and should thus default to ON.
Fixes: 4a97a3da420b ("drm: Don't update property values for atomic drivers")
Cc: stable(a)vger.kernel.org
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas(a)ideasonboard.com>
Signed-off-by: Stefan Agner <stefan(a)agner.ch>
---
drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c | 5 -----
1 file changed, 5 deletions(-)
diff --git a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c
index edd7d8127d19..c54806d08dd7 100644
--- a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c
+++ b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c
@@ -102,7 +102,6 @@ static int fsl_dcu_attach_panel(struct fsl_dcu_drm_device *fsl_dev,
{
struct drm_encoder *encoder = &fsl_dev->encoder;
struct drm_connector *connector = &fsl_dev->connector.base;
- struct drm_mode_config *mode_config = &fsl_dev->drm->mode_config;
int ret;
fsl_dev->connector.encoder = encoder;
@@ -122,10 +121,6 @@ static int fsl_dcu_attach_panel(struct fsl_dcu_drm_device *fsl_dev,
if (ret < 0)
goto err_sysfs;
- drm_object_property_set_value(&connector->base,
- mode_config->dpms_property,
- DRM_MODE_DPMS_OFF);
-
ret = drm_panel_attach(panel, connector);
if (ret) {
dev_err(fsl_dev->dev, "failed to attach panel\n");
--
2.14.2
On Thu, Nov 09, 2017 at 04:17:33PM +0000, Mark Brown wrote:
>On Thu, Nov 09, 2017 at 04:09:12PM +0000, Levin, Alexander (Sasha Levin) wrote:
>> On Thu, Nov 09, 2017 at 11:07:44AM +0000, Mark Brown wrote:
>
>> >This doesn't seem like a good idea - note how the changelog says that
>> >the transmit FIFO is at a different address, I'd expect this means that
>> >people won't be able to use the new compatible without a corresponding
>> >code change.
>
>> Interesting. I keep trying to automate DT patch selection to deal with
>> issues as this, but it seems like there is always something...
>
>> I agree with Mark. I think it would make sense to pick 1bd92af877 as
>> well to deal with this issue.
>
>Yeah, if they both go in together it's fine by me (though it's a little
>more than just a device ID).
It's a quirk too :)
--
Thanks,
Sasha
assert_rpm_wakelock_held is triggered from i915_pmic_bus_access_notifier
even though it gets unregistered on (runtime) suspend, this is caused
by a race happening under the following circumstances:
intel_runtime_pm_put does:
atomic_dec(&dev_priv->pm.wakeref_count);
pm_runtime_mark_last_busy(kdev);
pm_runtime_put_autosuspend(kdev);
And pm_runtime_put_autosuspend calls intel_runtime_suspend from
a workqueue, so there is ample of time between the atomic_dec() and
intel_runtime_suspend() unregistering the notifier. If the notifier
gets called in this windowd assert_rpm_wakelock_held falsely triggers
(at this point we're not runtime-suspended yet).
This commit adds disable_rpm_wakeref_asserts and
enable_rpm_wakeref_asserts calls around the
intel_uncore_forcewake_get(FORCEWAKE_ALL) call in
i915_pmic_bus_access_notifier fixing the false-positive WARN_ON.
Changes in v2:
-Reword comment explaining why disabling the wakeref asserts is
ok and necessary
Cc: stable(a)vger.kernel.org
Reported-by: FKr <bugs-freedesktop(a)ubermail.me>
Reviewed-by: Imre Deak <imre.deak(a)intel.com>
Signed-off-by: Hans de Goede <hdegoede(a)redhat.com>
---
drivers/gpu/drm/i915/intel_uncore.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_uncore.c b/drivers/gpu/drm/i915/intel_uncore.c
index 211acee7c31d..dbc5cc309cbc 100644
--- a/drivers/gpu/drm/i915/intel_uncore.c
+++ b/drivers/gpu/drm/i915/intel_uncore.c
@@ -1364,8 +1364,15 @@ static int i915_pmic_bus_access_notifier(struct notifier_block *nb,
* bus, which will be busy after this notification, leading to:
* "render: timed out waiting for forcewake ack request."
* errors.
+ *
+ * The notifier is unregistered during intel_runtime_suspend(),
+ * so it's ok to access the HW here without holding a RPM
+ * wake reference -> disable wakeref asserts for the time of
+ * the access.
*/
+ disable_rpm_wakeref_asserts(dev_priv);
intel_uncore_forcewake_get(dev_priv, FORCEWAKE_ALL);
+ enable_rpm_wakeref_asserts(dev_priv);
break;
case MBI_PMIC_BUS_ACCESS_END:
intel_uncore_forcewake_put(dev_priv, FORCEWAKE_ALL);
--
2.14.3
Hi Greg,
Please consider following upstream selftest firmware changes
to help run mainline/linux-next firmware test scripts on 4.4.y,
without breaking 0-day testing.
47e0bbb7fa98 ("test: firmware_class: report errors properly on failure")
is the one patch actually needed to make sure mainline/linux-next
selftest firmware test scripts run on 4.4.y.
Following commits are, however, required to make sure the above commit
doesn't break 0-day testing, wherein they run in-kernel selftests.
1b1fe542b6f0 ("selftests: firmware: add empty string and async tests")
880444e214cf ("selftests: firmware: send expected errors to /dev/null")
afb999cdef69 ("tools: firmware: check for distro fallback udev cancel rule")
Regards,
Amit Pundir
Brian Norris (2):
test: firmware_class: report errors properly on failure
selftests: firmware: add empty string and async tests
Luis R. Rodriguez (2):
selftests: firmware: send expected errors to /dev/null
tools: firmware: check for distro fallback udev cancel rule
lib/test_firmware.c | 11 ++++++---
tools/testing/selftests/firmware/fw_filesystem.sh | 10 +++++++-
tools/testing/selftests/firmware/fw_userhelper.sh | 28 +++++++++++++++++++++--
3 files changed, 43 insertions(+), 6 deletions(-)
--
2.7.4