[PATCH 2/2] X86/kdump: fall back to reserve high crashkernel memory
crashkernel=xM tries to reserve crashkernel memory under 4G, which
is enough for usual cases. But this could fail sometimes, for example
one tries to reserve a big chunk like 2G, it is possible to fail.
So let the crashkernel=xM just fall back to use high memory in case it
fails to find a suitable low range. Do not set the ,high as default
because it allocs extra low memory for DMA buffers and swiotlb, this is
not always necessary for all machines. Typically like crashkernel=128M
usually work with low reservation under 4G, so still keep <4G as default.
Signed-off-by: Dave Young
---
Documentation/admin-guide/kernel-parameters.txt |7 +--
arch/x86/kernel/setup.c | 22 ++
2 files changed, 19 insertions(+), 10 deletions(-)
--- linux-x86.orig/arch/x86/kernel/setup.c
+++ linux-x86/arch/x86/kernel/setup.c
@@ -541,21 +541,27 @@ static void __init reserve_crashkernel(v
}
/* 0 means: find the address automatically */
- if (crash_base <= 0) {
+ if (!crash_base) {
/*
* Set CRASH_ADDR_LOW_MAX upper bound for crash memory,
-* as old kexec-tools loads bzImage below that, unless
-* "crashkernel=size[KMG],high" is specified.
+* as crashkernel=x,high allocs memory over 4G, also allocs
+* 256M extra low memory for DMA buffers and swiotlb.
+* but the extra memory is not required for all machines.
+* So prefer low memory first, and fallback to high memory
+* unless "crashkernel=size[KMG],high" is specified.
*/
- crash_base = memblock_find_in_range(CRASH_ALIGN,
- high ? CRASH_ADDR_HIGH_MAX
-: CRASH_ADDR_LOW_MAX,
- crash_size, CRASH_ALIGN);
+ if (!high)
+ crash_base = memblock_find_in_range(CRASH_ALIGN,
+ CRASH_ADDR_LOW_MAX,
+ crash_size, CRASH_ALIGN);
+ if (!crash_base)
+ crash_base = memblock_find_in_range(CRASH_ALIGN,
+ CRASH_ADDR_HIGH_MAX,
+ crash_size, CRASH_ALIGN);
if (!crash_base) {
pr_info("crashkernel reservation failed - No suitable
area found.\n");
return;
}
-
} else {
unsigned long long start;
--- linux-x86.orig/Documentation/admin-guide/kernel-parameters.txt
+++ linux-x86/Documentation/admin-guide/kernel-parameters.txt
@@ -704,8 +704,11 @@
upon panic. This parameter reserves the physical
memory region [offset, offset + size] for that kernel
image. If '@offset' is omitted, then a suitable offset
- is selected automatically. Check
- Documentation/kdump/kdump.txt for further details.
+ is selected automatically.
+ [KNL, x86_64] select a region under 4G first, and
+ fallback to reserve region above 4G in case without
+ '@offset'.
+ See Documentation/kdump/kdump.txt for further details.
crashkernel=range1:size1[,range2:size2,...][@offset]
[KNL] Same as above, but depends on the memory
[PATCH 1/2] X86/kdump: move crashkernel=X to reserve under 4G by default
The kdump crashkernel low reservation is limited to under 896M even for
X86_64. This obscure and miserable limitation exists for old kexec-tools
compatibility, but the reason is not documented anywhere.
Some more tests/investigations about the background:
a) Previously old kexec-tools can only load purgatory to memory under 2G,
Eric remove that limitation in 2012 in kexec-tools:
Commit b4f9f8599679 ("kexec x86_64: Make purgatory relocatable anywhere
in the 64bit address space.")
b) back in 2013 Yinghai removed all the limitations in new kexec-tools,
bzImage64 can be loaded to anywhere.
Commit 82c3dd2280d2 ("kexec, x86_64: Load bzImage64 above 4G")
c) test results with old kexec-tools with old and latest kernels.
1. old kexec-tools can not build with modern toolchain anymore,
I built it in a RHEL6 vm
2. 2.0.0 kexec-tools does not work with latest kernel even with
memory under 896M and give an error:
"ELF core (kcore) parse failed", it needs below kexec-tools fix
Commit ed15ba1b9977 ("build_mem_phdrs(): check if p_paddr is invalid")
3. even with patched kexec-tools which fixes 2), it still needs some
other fixes to work correctly for kaslr enabled kernels.
So the situation is:
* old kexec-tools is already broken with latest kernels
* we can not keep this limitations forever just for compatibility of very
old kexec-tools.
* If one must use old tools then he/she can choose crashkernel=X@Y
* people have reported bugs crashkernel=384M failed because kaslr makes
the 0-896M space sparse,
* crashkernel can reserve in low or high area, it is natural to understand
low as memory under 4G
Hence drop the 896M limitation, and change crashkernel low reservation to
reserve under 4G by default.
Signed-off-by: Dave Young
---
arch/x86/kernel/setup.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
--- linux-x86.orig/arch/x86/kernel/setup.c
+++ linux-x86/arch/x86/kernel/setup.c
@@ -71,6 +71,7 @@
#include
#include
#include
+#include
#include
#include
@@ -448,18 +449,17 @@ static void __init memblock_x86_reserve_
#ifdef CONFIG_KEXEC_CORE
/* 16M alignment for crash kernel regions */
-#define CRASH_ALIGN(16 << 20)
+#define CRASH_ALIGNSZ_16M
/*
* Keep the crash kernel below this limit. On 32 bits earlier kernels
* would limit the kernel to the low 512 MiB due to mapping restrictions.
- * On 64bit, old kexec-tools need to under 896MiB.
*/
#ifdef CONFIG_X86_32
-# define CRASH_ADDR_LOW_MAX(512 << 20)
-# define CRASH_ADDR_HIGH_MAX (512 << 20)
+# define CRASH_ADDR_LOW_MAXSZ_512M
+# define CRASH_ADDR_HIGH_MAX SZ_512M
#else
-# define CRASH_ADDR_LOW_MAX(896UL << 20)
+# define CRASH_ADDR_LOW_MAXSZ_4G
# define CRASH_ADDR_HIGH_MAX MAXMEM
#endif
Re: [PATCH] cifs: fix page reference leak with readv/writev
updated patch in cifs-2.6.git for-next
On Thu, Apr 18, 2019 at 4:45 PM Pavel Shilovsky wrote:
>
> чт, 18 апр. 2019 г. в 14:12, Jerome Glisse :
> >
> > On Wed, Apr 10, 2019 at 09:47:01PM -0500, Steve French wrote:
> > > How was this discovered? Does it address a reported user problem?
> >
> > I have spotted it while tracking down how page reference are taken
> > for bio and how they are release. In the current code, once the page
> > are GUPed they are never release if there is any failure, on failure
> > cifs_aio_ctx_release() will be call but it will just free the bio_vec
> > not release the page reference.
> >
> > Page reference are only drop if everything is successful.
> >
> > So this patch move the page reference droping to cifs_aio_ctx_release()
> > which is call from all code path including failure AFAICT and thus page
> > reference will be drop if failure does happen.
> >
> > Cheers,
> > Jérôme
> >
> > >
> > > On Wed, Apr 10, 2019 at 2:38 PM wrote:
> > > >
> > > > From: Jérôme Glisse
> > > >
> > > > CIFS can leak pages reference gotten through GUP (get_user_pages*()
> > > > through iov_iter_get_pages()). This happen if cifs_send_async_read()
> > > > or cifs_write_from_iter() calls fail from within __cifs_readv() and
> > > > __cifs_writev() respectively. This patch move page unreference to
> > > > cifs_aio_ctx_release() which will happens on all code paths this is
> > > > all simpler to follow for correctness.
> > > >
> > > > Signed-off-by: Jérôme Glisse
> > > > Cc: Steve French
> > > > Cc: linux-c...@vger.kernel.org
> > > > Cc: samba-techni...@lists.samba.org
> > > > Cc: Alexander Viro
> > > > Cc: linux-fsde...@vger.kernel.org
> > > > Cc: Linus Torvalds
> > > > Cc: Stable
> > > > ---
> > > > fs/cifs/file.c | 15 +--
> > > > fs/cifs/misc.c | 23 ++-
> > > > 2 files changed, 23 insertions(+), 15 deletions(-)
> > > >
> > > > diff --git a/fs/cifs/file.c b/fs/cifs/file.c
> > > > index 89006e044973..a756a4d3f70f 100644
> > > > --- a/fs/cifs/file.c
> > > > +++ b/fs/cifs/file.c
> > > > @@ -2858,7 +2858,6 @@ static void collect_uncached_write_data(struct
> > > > cifs_aio_ctx *ctx)
> > > > struct cifs_tcon *tcon;
> > > > struct cifs_sb_info *cifs_sb;
> > > > struct dentry *dentry = ctx->cfile->dentry;
> > > > - unsigned int i;
> > > > int rc;
> > > >
> > > > tcon = tlink_tcon(ctx->cfile->tlink);
> > > > @@ -2922,10 +2921,6 @@ static void collect_uncached_write_data(struct
> > > > cifs_aio_ctx *ctx)
> > > > kref_put(>refcount,
> > > > cifs_uncached_writedata_release);
> > > > }
> > > >
> > > > - if (!ctx->direct_io)
> > > > - for (i = 0; i < ctx->npages; i++)
> > > > - put_page(ctx->bv[i].bv_page);
> > > > -
> > > > cifs_stats_bytes_written(tcon, ctx->total_len);
> > > > set_bit(CIFS_INO_INVALID_MAPPING,
> > > > _I(dentry->d_inode)->flags);
> > > >
> > > > @@ -3563,7 +3558,6 @@ collect_uncached_read_data(struct cifs_aio_ctx
> > > > *ctx)
> > > > struct iov_iter *to = >iter;
> > > > struct cifs_sb_info *cifs_sb;
> > > > struct cifs_tcon *tcon;
> > > > - unsigned int i;
> > > > int rc;
> > > >
> > > > tcon = tlink_tcon(ctx->cfile->tlink);
> > > > @@ -3647,15 +3641,8 @@ collect_uncached_read_data(struct cifs_aio_ctx
> > > > *ctx)
> > > > kref_put(>refcount,
> > > > cifs_uncached_readdata_release);
> > > > }
> > > >
> > > > - if (!ctx->direct_io) {
> > > > - for (i = 0; i < ctx->npages; i++) {
> > > > - if (ctx->should_dirty)
> > > > - set_page_dirty(ctx->bv[i].bv_page);
> > > > - put_page(ctx->bv[i].bv_page);
> > > > - }
> > > > -
> > > > + if (!ctx->direct_io)
> > > > ctx->total_len = ctx->len - iov_iter_count(to);
> > > > - }
> > > >
> > > > /* mask nodata case */
> > > > if (rc == -ENODATA)
> > > > diff --git a/fs/cifs/misc.c b/fs/cifs/misc.c
> > > > index bee203055b30..9bc0d17a9d77 100644
> > > > --- a/fs/cifs/misc.c
> > > > +++ b/fs/cifs/misc.c
> > > > @@ -768,6 +768,11 @@ cifs_aio_ctx_alloc(void)
> > > > {
> > > > struct cifs_aio_ctx *ctx;
> > > >
> > > > + /*
> > > > +* Must use kzalloc to initialize ctx->bv to NULL and
> > > > ctx->direct_io
> > > > +* to false so that we know when we have to unreference pages
> > > > within
> > > > +* cifs_aio_ctx_release()
> > > > +*/
> > > > ctx = kzalloc(sizeof(struct cifs_aio_ctx), GFP_KERNEL);
> > > > if (!ctx)
> > > > return NULL;
> > > > @@ -786,7 +791,23 @@ cifs_aio_ctx_release(struct kref *refcount)
> > > > struct cifs_aio_ctx, refcount);
> > > >
> > > > cifsFileInfo_put(ctx->cfile);
> > > > - kvfree(ctx->bv);
> > > > +
> > > > +
[PATCH] checkpatch: mute SOB warning in case SOB exists but without From header
checkpatch.pl report below warning but the SOB line is correct:
$ ./scripts/checkpatch.pl patches/test.patch
WARNING: Missing Signed-off-by: line by nominal patch author ''
Actually checkpatch.pl assumes every patch includes "From:" line,
this is true for a git formated patch, some saved mail format patch.
But the warning is boring for people who do not use git formated patch.
Change the script only print warning in case "From:" line exists.
Signed-off-by: Dave Young
---
scripts/checkpatch.pl |6 --
1 file changed, 4 insertions(+), 2 deletions(-)
--- linux-x86.orig/scripts/checkpatch.pl
+++ linux-x86/scripts/checkpatch.pl
@@ -2283,7 +2283,7 @@ sub process {
our $clean = 1;
my $signoff = 0;
my $author = '';
- my $authorsignoff = 0;
+ my $authorsignoff = -1;
my $is_patch = 0;
my $is_binding_patch = -1;
my $in_header_lines = $file ? 0 : 1;
@@ -2609,6 +2609,8 @@ sub process {
$l =~ s/"//g;
if ($l =~ /^\s*signed-off-by:\s*\Q$author\E/i) {
$authorsignoff = 1;
+ } else {
+ $authorsignoff = 0;
}
}
}
@@ -6649,7 +6651,7 @@ sub process {
if ($signoff == 0) {
ERROR("MISSING_SIGN_OFF",
"Missing Signed-off-by: line(s)\n");
- } elsif (!$authorsignoff) {
+ } elsif ($authorsignoff == 0) {
WARN("NO_AUTHOR_SIGN_OFF",
"Missing Signed-off-by: line by nominal patch
author '$author'\n");
}
[PATCH] regulator: mt63xx: Switch to SPDX identifier
Convert MediaTek mt63xx PMIC drivers to SPDX identifier. Signed-off-by: Axel Lin --- drivers/regulator/mt6311-regulator.c | 17 - drivers/regulator/mt6311-regulator.h | 10 +- drivers/regulator/mt6323-regulator.c | 12 drivers/regulator/mt6380-regulator.c | 17 - drivers/regulator/mt6397-regulator.c | 17 - 5 files changed, 17 insertions(+), 56 deletions(-) diff --git a/drivers/regulator/mt6311-regulator.c b/drivers/regulator/mt6311-regulator.c index 01d69f43d2b0..af95449d3590 100644 --- a/drivers/regulator/mt6311-regulator.c +++ b/drivers/regulator/mt6311-regulator.c @@ -1,16 +1,7 @@ -/* - * Copyright (c) 2015 MediaTek Inc. - * Author: Henry Chen - * - * This program is free software; you can redistribute it and/or modify - * it under the terms of the GNU General Public License version 2 as - * published by the Free Software Foundation. - * - * This program is distributed in the hope that it will be useful, - * but WITHOUT ANY WARRANTY; without even the implied warranty of - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the - * GNU General Public License for more details. - */ +// SPDX-License-Identifier: GPL-2.0 +// +// Copyright (c) 2015 MediaTek Inc. +// Author: Henry Chen #include #include diff --git a/drivers/regulator/mt6311-regulator.h b/drivers/regulator/mt6311-regulator.h index 5218db46a798..4904d6751714 100644 --- a/drivers/regulator/mt6311-regulator.h +++ b/drivers/regulator/mt6311-regulator.h @@ -1,15 +1,7 @@ +/* SPDX-License-Identifier: GPL-2.0 */ /* * Copyright (c) 2015 MediaTek Inc. * Author: Henry Chen - * - * This program is free software; you can redistribute it and/or modify - * it under the terms of the GNU General Public License version 2 as - * published by the Free Software Foundation. - * - * This program is distributed in the hope that it will be useful, - * but WITHOUT ANY WARRANTY; without even the implied warranty of - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the - * GNU General Public License for more details. */ #ifndef __MT6311_REGULATOR_H__ diff --git a/drivers/regulator/mt6323-regulator.c b/drivers/regulator/mt6323-regulator.c index 25b002328910..893ea190788a 100644 --- a/drivers/regulator/mt6323-regulator.c +++ b/drivers/regulator/mt6323-regulator.c @@ -1,11 +1,7 @@ -/* - * Copyright (c) 2016 MediaTek Inc. - * Author: Chen Zhong - * - * This program is free software; you can redistribute it and/or modify - * it under the terms of the GNU General Public License version 2 as - * published by the Free Software Foundation. - */ +// SPDX-License-Identifier: GPL-2.0 +// +// Copyright (c) 2016 MediaTek Inc. +// Author: Chen Zhong #include #include diff --git a/drivers/regulator/mt6380-regulator.c b/drivers/regulator/mt6380-regulator.c index 86bc332df3f2..b6aed090b5e0 100644 --- a/drivers/regulator/mt6380-regulator.c +++ b/drivers/regulator/mt6380-regulator.c @@ -1,16 +1,7 @@ -/* - * Copyright (c) 2017 MediaTek Inc. - * Author: Chenglin Xu - * - * This program is free software; you can redistribute it and/or modify - * it under the terms of the GNU General Public License version 2 as - * published by the Free Software Foundation. - * - * This program is distributed in the hope that it will be useful, - * but WITHOUT ANY WARRANTY; without even the implied warranty of - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the - * GNU General Public License for more details. - */ +// SPDX-License-Identifier: GPL-2.0 +// +// Copyright (c) 2017 MediaTek Inc. +// Author: Chenglin Xu #include #include diff --git a/drivers/regulator/mt6397-regulator.c b/drivers/regulator/mt6397-regulator.c index 3e6c8d99ec0f..fd9ed864a0c1 100644 --- a/drivers/regulator/mt6397-regulator.c +++ b/drivers/regulator/mt6397-regulator.c @@ -1,16 +1,7 @@ -/* - * Copyright (c) 2014 MediaTek Inc. - * Author: Flora Fu - * - * This program is free software; you can redistribute it and/or modify - * it under the terms of the GNU General Public License version 2 as - * published by the Free Software Foundation. - * - * This program is distributed in the hope that it will be useful, - * but WITHOUT ANY WARRANTY; without even the implied warranty of - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the - * GNU General Public License for more details. - */ +// SPDX-License-Identifier: GPL-2.0 +// +// Copyright (c) 2014 MediaTek Inc. +// Author: Flora Fu #include #include -- 2.17.1
[PATCH v2 1/8] s390: vfio-ap: maintain a shadow of the CRYCB in use by a guest
This patch introduces a shadow of the CRYCB being used by a guest. This
will enable to more effectively manage dynamic changes to the AP
resources installed on the host that may be assigned to an mdev device
and being used by a guest. For example:
* AP adapter cards can be dynamically added to and removed from the AP
configuration via the SE or an SCLP command.
* AP resources that disappear and reappear due to hardware malfunctions.
* AP queues bound to and unbound from the vfio_ap device driver by a
root user.
Signed-off-by: Tony Krowiak
---
drivers/s390/crypto/vfio_ap_ops.c | 69 ---
drivers/s390/crypto/vfio_ap_private.h | 2 +
2 files changed, 65 insertions(+), 6 deletions(-)
diff --git a/drivers/s390/crypto/vfio_ap_ops.c
b/drivers/s390/crypto/vfio_ap_ops.c
index 900b9cf20ca5..b0453e6c20d0 100644
--- a/drivers/s390/crypto/vfio_ap_ops.c
+++ b/drivers/s390/crypto/vfio_ap_ops.c
@@ -271,6 +271,29 @@ static int vfio_ap_mdev_verify_no_sharing(struct
ap_matrix_mdev *matrix_mdev)
return 0;
}
+/*
+ * vfio_ap_mdev_update_crycb
+ *
+ * @matrix_mdev: the mediated matrix device
+ *
+ * Updates the AP matrix in the guest's CRYCB from it's shadow masks.
+ *
+ * Returns zero if the guest's CRYCB is successfully updated; otherwise,
+ * returns -ENODEV if a guest is not running or does not have a CRYCB.
+ */
+static int vfio_ap_mdev_update_crycb(struct ap_matrix_mdev *matrix_mdev)
+{
+ if (!matrix_mdev->kvm || !matrix_mdev->kvm->arch.crypto.crycbd)
+ return -ENODEV;
+
+ kvm_arch_crypto_set_masks(matrix_mdev->kvm,
+ matrix_mdev->shadow_crycb->apm,
+ matrix_mdev->shadow_crycb->aqm,
+ matrix_mdev->shadow_crycb->adm);
+
+ return 0;
+}
+
/**
* assign_adapter_store
*
@@ -340,6 +363,9 @@ static ssize_t assign_adapter_store(struct device *dev,
if (ret)
goto share_err;
+ if (matrix_mdev->shadow_crycb)
+ set_bit_inv(apid, matrix_mdev->shadow_crycb->apm);
+
ret = count;
goto done;
@@ -391,6 +417,9 @@ static ssize_t unassign_adapter_store(struct device *dev,
mutex_lock(_dev->lock);
clear_bit_inv((unsigned long)apid, matrix_mdev->matrix.apm);
+
+ if (matrix_mdev->shadow_crycb)
+ clear_bit_inv(apid, matrix_mdev->shadow_crycb->apm);
mutex_unlock(_dev->lock);
return count;
@@ -481,6 +510,9 @@ static ssize_t assign_domain_store(struct device *dev,
if (ret)
goto share_err;
+ if (matrix_mdev->shadow_crycb)
+ set_bit_inv(apqi, matrix_mdev->shadow_crycb->aqm);
+
ret = count;
goto done;
@@ -533,6 +565,10 @@ static ssize_t unassign_domain_store(struct device *dev,
mutex_lock(_dev->lock);
clear_bit_inv((unsigned long)apqi, matrix_mdev->matrix.aqm);
+
+ if (matrix_mdev->shadow_crycb)
+ clear_bit_inv(apqi, matrix_mdev->shadow_crycb->aqm);
+
mutex_unlock(_dev->lock);
return count;
@@ -582,6 +618,10 @@ static ssize_t assign_control_domain_store(struct device
*dev,
*/
mutex_lock(_dev->lock);
set_bit_inv(id, matrix_mdev->matrix.adm);
+
+ if (matrix_mdev->shadow_crycb)
+ set_bit_inv(id, matrix_mdev->shadow_crycb->adm);
+
mutex_unlock(_dev->lock);
return count;
@@ -626,6 +666,10 @@ static ssize_t unassign_control_domain_store(struct device
*dev,
mutex_lock(_dev->lock);
clear_bit_inv(domid, matrix_mdev->matrix.adm);
+
+ if (matrix_mdev->shadow_crycb)
+ clear_bit_inv(domid, matrix_mdev->shadow_crycb->adm);
+
mutex_unlock(_dev->lock);
return count;
@@ -779,14 +823,9 @@ static int vfio_ap_mdev_group_notifier(struct
notifier_block *nb,
if (ret)
return NOTIFY_DONE;
- /* If there is no CRYCB pointer, then we can't copy the masks */
- if (!matrix_mdev->kvm->arch.crypto.crycbd)
+ if (vfio_ap_mdev_update_crycb(matrix_mdev))
return NOTIFY_DONE;
- kvm_arch_crypto_set_masks(matrix_mdev->kvm, matrix_mdev->matrix.apm,
- matrix_mdev->matrix.aqm,
- matrix_mdev->matrix.adm);
-
return NOTIFY_OK;
}
@@ -838,12 +877,28 @@ static int vfio_ap_mdev_reset_queues(struct mdev_device
*mdev)
return rc;
}
+static int vfio_ap_mdev_create_shadow_crycb(struct ap_matrix_mdev *matrix_mdev)
+{
+ matrix_mdev->shadow_crycb = kzalloc(sizeof(*matrix_mdev->shadow_crycb),
+ GFP_KERNEL);
+ if (!matrix_mdev->shadow_crycb)
+ return -ENOMEM;
+
+ memcpy(matrix_mdev->shadow_crycb, _mdev->matrix,
+ sizeof(matrix_mdev->matrix));
+
+ return 0;
+}
+
static int vfio_ap_mdev_open(struct mdev_device *mdev)
{
[PATCH v2 4/8] s390: vfio-ap: allow hot plug/unplug of AP resources using mdev device
Let's allow adapters, domains and control domains to be assigned to or unassigned from an AP matrix mdev device while it is in use by a guest. When an adapter, domain or control domain is assigned to or unassigned from an mdev device while a guest is using it, the guest's CRYCB will be updated thus giving access to the resource assigned, or taking access away from the resource unassigned for the guest. Signed-off-by: Tony Krowiak --- drivers/s390/crypto/vfio_ap_ops.c | 49 --- 1 file changed, 15 insertions(+), 34 deletions(-) diff --git a/drivers/s390/crypto/vfio_ap_ops.c b/drivers/s390/crypto/vfio_ap_ops.c index 221491a9ba95..091804317c5e 100644 --- a/drivers/s390/crypto/vfio_ap_ops.c +++ b/drivers/s390/crypto/vfio_ap_ops.c @@ -219,10 +219,6 @@ static ssize_t assign_adapter_store(struct device *dev, struct mdev_device *mdev = mdev_from_dev(dev); struct ap_matrix_mdev *matrix_mdev = mdev_get_drvdata(mdev); - /* If the guest is running, disallow assignment of adapter */ - if (matrix_mdev->kvm) - return -EBUSY; - ret = kstrtoul(buf, 0, ); if (ret) return ret; @@ -237,10 +233,6 @@ static ssize_t assign_adapter_store(struct device *dev, */ mutex_lock(_dev->lock); - ret = vfio_ap_mdev_verify_queues_reserved_for_apid(matrix_mdev, apid); - if (ret) - goto done; - set_bit_inv(apid, matrix_mdev->matrix.apm); ret = ap_apqn_in_matrix_owned_by_def_drv(matrix_mdev->matrix.apm, @@ -258,6 +250,7 @@ static ssize_t assign_adapter_store(struct device *dev, if (matrix_mdev->shadow_crycb) set_bit_inv(apid, matrix_mdev->shadow_crycb->apm); + vfio_ap_mdev_update_crycb(matrix_mdev); ret = count; goto done; @@ -296,10 +289,6 @@ static ssize_t unassign_adapter_store(struct device *dev, struct mdev_device *mdev = mdev_from_dev(dev); struct ap_matrix_mdev *matrix_mdev = mdev_get_drvdata(mdev); - /* If the guest is running, disallow un-assignment of adapter */ - if (matrix_mdev->kvm) - return -EBUSY; - ret = kstrtoul(buf, 0, ); if (ret) return ret; @@ -312,6 +301,8 @@ static ssize_t unassign_adapter_store(struct device *dev, if (matrix_mdev->shadow_crycb) clear_bit_inv(apid, matrix_mdev->shadow_crycb->apm); + + vfio_ap_mdev_update_crycb(matrix_mdev); mutex_unlock(_dev->lock); return count; @@ -360,10 +351,6 @@ static ssize_t assign_domain_store(struct device *dev, struct ap_matrix_mdev *matrix_mdev = mdev_get_drvdata(mdev); unsigned long max_apqi = matrix_mdev->matrix.aqm_max; - /* If the guest is running, disallow assignment of domain */ - if (matrix_mdev->kvm) - return -EBUSY; - ret = kstrtoul(buf, 0, ); if (ret) return ret; @@ -384,15 +371,16 @@ static ssize_t assign_domain_store(struct device *dev, ret = vfio_ap_mdev_verify_no_sharing(matrix_mdev); if (ret) - goto share_err; + goto error; if (matrix_mdev->shadow_crycb) set_bit_inv(apqi, matrix_mdev->shadow_crycb->aqm); + vfio_ap_mdev_update_crycb(matrix_mdev); ret = count; goto done; -share_err: +error: clear_bit_inv(apqi, matrix_mdev->matrix.aqm); done: mutex_unlock(_dev->lock); @@ -428,10 +416,6 @@ static ssize_t unassign_domain_store(struct device *dev, struct mdev_device *mdev = mdev_from_dev(dev); struct ap_matrix_mdev *matrix_mdev = mdev_get_drvdata(mdev); - /* If the guest is running, disallow un-assignment of domain */ - if (matrix_mdev->kvm) - return -EBUSY; - ret = kstrtoul(buf, 0, ); if (ret) return ret; @@ -445,6 +429,7 @@ static ssize_t unassign_domain_store(struct device *dev, if (matrix_mdev->shadow_crycb) clear_bit_inv(apqi, matrix_mdev->shadow_crycb->aqm); + vfio_ap_mdev_update_crycb(matrix_mdev); mutex_unlock(_dev->lock); return count; @@ -476,10 +461,6 @@ static ssize_t assign_control_domain_store(struct device *dev, struct mdev_device *mdev = mdev_from_dev(dev); struct ap_matrix_mdev *matrix_mdev = mdev_get_drvdata(mdev); - /* If the guest is running, disallow assignment of control domain */ - if (matrix_mdev->kvm) - return -EBUSY; - ret = kstrtoul(buf, 0, ); if (ret) return ret; @@ -487,10 +468,12 @@ static ssize_t assign_control_domain_store(struct device *dev, if (id > matrix_mdev->matrix.adm_max) return -ENODEV; - /* Set the bit in the ADM (bitmask) corresponding to the AP control -* domain number (id). The bits in the mask, from most significant to -* least significant,
[PATCH v2 5/8] s390: vfio-ap: wait for queue empty on queue reset
Refactors the AP queue reset function to wait until the queue is empty
after the PQAP(ZAPQ) instruction is executed to zero out the queue as
required by the AP architecture.
Signed-off-by: Tony Krowiak
---
drivers/s390/crypto/vfio_ap_ops.c | 35 ---
1 file changed, 32 insertions(+), 3 deletions(-)
diff --git a/drivers/s390/crypto/vfio_ap_ops.c
b/drivers/s390/crypto/vfio_ap_ops.c
index 091804317c5e..31ce30ee784d 100644
--- a/drivers/s390/crypto/vfio_ap_ops.c
+++ b/drivers/s390/crypto/vfio_ap_ops.c
@@ -744,15 +744,44 @@ static int vfio_ap_mdev_group_notifier(struct
notifier_block *nb,
return NOTIFY_OK;
}
-static int vfio_ap_mdev_reset_queue(unsigned int apid, unsigned int apqi,
- unsigned int retry)
+static void vfio_ap_mdev_wait_for_qempty(unsigned long apid, unsigned long
apqi)
{
struct ap_queue_status status;
+ ap_qid_t qid = AP_MKQID(apid, apqi);
+ int retry = 5;
+
+ do {
+ status = ap_tapq(qid, NULL);
+ switch (status.response_code) {
+ case AP_RESPONSE_NORMAL:
+ if (status.queue_empty)
+ return;
+ msleep(20);
+ break;
+ case AP_RESPONSE_RESET_IN_PROGRESS:
+ case AP_RESPONSE_BUSY:
+ msleep(20);
+ break;
+ default:
+ pr_warn("%s: tapq err %02x: 0x%04x may not be empty\n",
+ __func__, status.response_code, q->apqn);
+ return;
+ }
+ } while (--retry);
+}
+
+int vfio_ap_mdev_reset_queue(unsigned int apid, unsigned int apqi)
+{
+ struct ap_queue_status status;
+ int retry = 5;
do {
status = ap_zapq(AP_MKQID(apid, apqi));
switch (status.response_code) {
case AP_RESPONSE_NORMAL:
+ vfio_ap_mdev_wait_for_qempty(apid, apqi);
+ return 0;
+ case AP_RESPONSE_DECONFIGURED:
return 0;
case AP_RESPONSE_RESET_IN_PROGRESS:
case AP_RESPONSE_BUSY:
@@ -778,7 +807,7 @@ static int vfio_ap_mdev_reset_queues(struct mdev_device
*mdev)
matrix_mdev->matrix.apm_max + 1) {
for_each_set_bit_inv(apqi, matrix_mdev->matrix.aqm,
matrix_mdev->matrix.aqm_max + 1) {
- ret = vfio_ap_mdev_reset_queue(apid, apqi, 1);
+ ret = vfio_ap_mdev_reset_queue(apid, apqi);
/*
* Regardless whether a queue turns out to be busy, or
* is not operational, we need to continue resetting
--
2.7.4
[PATCH v2 7/8] s390: vfio-ap: handle bind and unbind of AP queue device
There is an implied guarantee that when an AP queue device is bound to a
device driver, that driver will have exclusive control over the device.
When an AP queue device is unbound from the vfio_ap driver while the
queue is in use by a guest and subsquently bound to a zcrypt driver, the
guarantee that the zcrypt driver has exclusive control of the queue
device will be violated. Likewise, when an AP queue device is bound to
the vfio_ap device driver and its APQN is assigned to an mdev device in
use by a guest, the expectation is that the guest will have access to
the queue.
The purpose of this patch is to ensure three things:
1. When an AP queue device in use by a guest is unbound, the guest shall
no longer access the queue. Due to the limitations of the
architecture, access to a single queue can not be denied to a guest,
so access to the AP card to which the queue is connected will be
denied to the guest.
2. When an AP queue device with an APQN assigned to an mdev device is
bound to the vfio_ap driver while the mdev device is in use by a guest,
the guest shall be granted access to the queue.
3. When a guest is started, each APQN assigned to the guest's mdev device
must be owned by the vfio_ap driver.
Signed-off-by: Tony Krowiak
---
drivers/s390/crypto/vfio_ap_drv.c | 16 ++-
drivers/s390/crypto/vfio_ap_ops.c | 82 ++-
drivers/s390/crypto/vfio_ap_private.h | 2 +
3 files changed, 97 insertions(+), 3 deletions(-)
diff --git a/drivers/s390/crypto/vfio_ap_drv.c
b/drivers/s390/crypto/vfio_ap_drv.c
index e9824c35c34f..0f5dafddf5b1 100644
--- a/drivers/s390/crypto/vfio_ap_drv.c
+++ b/drivers/s390/crypto/vfio_ap_drv.c
@@ -42,12 +42,26 @@ MODULE_DEVICE_TABLE(vfio_ap, ap_queue_ids);
static int vfio_ap_queue_dev_probe(struct ap_device *apdev)
{
+ struct ap_queue *apq = to_ap_queue(>device);
+ unsigned long apid = AP_QID_CARD(apq->qid);
+ unsigned long apqi = AP_QID_QUEUE(apq->qid);
+
+ mutex_lock(_dev->lock);
+ vfio_ap_mdev_probe_queue(apid, apqi);
+ mutex_unlock(_dev->lock);
+
return 0;
}
static void vfio_ap_queue_dev_remove(struct ap_device *apdev)
{
- /* Nothing to do yet */
+ struct ap_queue *apq = to_ap_queue(>device);
+ unsigned long apid = AP_QID_CARD(apq->qid);
+ unsigned long apqi = AP_QID_QUEUE(apq->qid);
+
+ mutex_lock(_dev->lock);
+ vfio_ap_mdev_remove_queue(apid, apqi);
+ mutex_unlock(_dev->lock);
}
static void vfio_ap_matrix_dev_release(struct device *dev)
diff --git a/drivers/s390/crypto/vfio_ap_ops.c
b/drivers/s390/crypto/vfio_ap_ops.c
index 31ce30ee784d..3f9506516545 100644
--- a/drivers/s390/crypto/vfio_ap_ops.c
+++ b/drivers/s390/crypto/vfio_ap_ops.c
@@ -763,8 +763,8 @@ static void vfio_ap_mdev_wait_for_qempty(unsigned long
apid, unsigned long apqi)
msleep(20);
break;
default:
- pr_warn("%s: tapq err %02x: 0x%04x may not be empty\n",
- __func__, status.response_code, q->apqn);
+ pr_warn("%s: tapq err %02x: %02lx%04lx may not be
empty\n",
+ __func__, status.response_code, apid, apqi);
return;
}
} while (--retry);
@@ -823,6 +823,14 @@ static int vfio_ap_mdev_reset_queues(struct mdev_device
*mdev)
static int vfio_ap_mdev_create_shadow_crycb(struct ap_matrix_mdev *matrix_mdev)
{
+ /*
+* If an AP resource is not owned by the vfio_ap driver - e.g., it was
+* unbound from the driver while still assigned to the mdev device
+*/
+ if (ap_apqn_in_matrix_owned_by_def_drv(matrix_mdev->matrix.apm,
+ matrix_mdev->matrix.aqm))
+ return -EADDRNOTAVAIL;
+
matrix_mdev->shadow_crycb = kzalloc(sizeof(*matrix_mdev->shadow_crycb),
GFP_KERNEL);
if (!matrix_mdev->shadow_crycb)
@@ -847,6 +855,18 @@ static int vfio_ap_mdev_open(struct mdev_device *mdev)
if (!try_module_get(THIS_MODULE))
return -ENODEV;
+ ret = ap_apqn_in_matrix_owned_by_def_drv(matrix_mdev->matrix.apm,
+matrix_mdev->matrix.aqm);
+
+ /*
+* If any APQN is owned by a default driver, it can not be used by the
+* guest. This can happen if a queue is unbound from the vfio_ap
+* driver but not unassigned from the mdev device.
+*/
+ ret = (ret == 1) ? -EADDRNOTAVAIL : ret;
+ if (ret)
+ return ret;
+
matrix_mdev->group_notifier.notifier_call = vfio_ap_mdev_group_notifier;
events = VFIO_GROUP_NOTIFY_SET_KVM;
@@ -938,3 +958,61 @@ void vfio_ap_mdev_unregister(void)
{
mdev_unregister_device(_dev->device);
}
+
+static struct ap_matrix_mdev
[PATCH v2 8/8] s390: vfio-ap: update documentation
Updates to the documentation to reflect changes introduced by this patch series. This patch also clarifies the section on configuring the apmask and aqmask. Signed-off-by: Tony Krowiak --- Documentation/s390/vfio-ap.txt | 188 + 1 file changed, 153 insertions(+), 35 deletions(-) diff --git a/Documentation/s390/vfio-ap.txt b/Documentation/s390/vfio-ap.txt index 65167cfe4485..66e05e56ac45 100644 --- a/Documentation/s390/vfio-ap.txt +++ b/Documentation/s390/vfio-ap.txt @@ -351,6 +351,9 @@ matrix device. * matrix: A read-only file for displaying the APQNs derived from the cross product of the adapter and domain numbers assigned to the mediated matrix device. +* guest_matrix: + A read-only file for displaying the APQNs derived from the cross product + of adapter and domain numbers assigned to the guest matrix (i.e., CRYCB) * assign_control_domain: * unassign_control_domain: Write-only attributes for assigning/unassigning an AP control domain @@ -438,7 +441,33 @@ guest use. Example: === Let's now provide an example to illustrate how KVM guests may be given -access to AP facilities. For this example, we will show how to configure +access to AP facilities. Let's assume that the following AP devices are +configured for the host: + +/sys/bus/ap/devices +... 04.0004 +... 04.0005 +... 04.0006 +... 04.0047 +... 04.00ab +... 04.00ff +... 05.0004 +... 05.0005 +... 05.0006 +... 05.0047 +... 05.00ab +... 05.00ff +... 06.0004 +... 06.0005 +... 06.0006 +... 06.0047 +... 06.00ab +... 06.00ff +... card04 +... card05 +... card06 + +For this example, we will show how to configure three guests such that executing the lszcrypt command on the guests would look like this: @@ -461,7 +490,7 @@ CARD.DOMAIN TYPE MODE 05.0047 CEX5A Accelerator 05.00ff CEX5A Accelerator -Guest2 +Guest3 -- CARD.DOMAIN TYPE MODE -- @@ -538,7 +567,7 @@ These are the steps: The APQN of each AP queue device assigned to the linux host is checked by the AP bus against the set of APQNs derived from the cross product of APIDs and APQIs marked as usable only by the default AP queue device drivers. If a - match is detected, only the default AP queue device drivers will be probed; + match is detected, only the default AP queue device drivers will be probed; otherwise, the vfio_ap device driver will be probed. By default, the two masks are set to reserve all APQNs for use by the default @@ -599,32 +628,75 @@ These are the steps: default drivers pool:adapter 0-15, domain 1 alternate drivers pool: adapter 16-255, domains 0, 2-255 + Note: + + * Clearing a bit from the apmask renders all queues associated with + the corresponding adapter inaccessible to the host. + + * Clearing a bit from the aqmask renders that queue inaccessible on all + adapters reserved for the host. + + * When either mask is changed, the AP bus will reprobe all of the AP devices + to ensure each adapter card and queue is bound to the appropriate device + driver as specified by the apmask and aqmask. If the change results in + unbinding an AP queue with an APQN that is in use by a guest, the adapter + card with the specified APID will be hot unplugged from the guest. If the + change results in binding an AP queue with an APQN that is assigned to an + mdev device which is in use by a guest, the queue will be hot plugged into + the guest. + Securing the APQNs for our example: -- To secure the AP queues 05.0004, 05.0047, 05.00ab, 05.00ff, 06.0004, 06.0047, - 06.00ab, and 06.00ff for use by the vfio_ap device driver, the corresponding - APQNs can either be removed from the default masks: + 06.00ab, and 06.00ff for use by the vfio_ap device driver, either mask can + be edited. + + To reserve all queues for adapters 05 and 06: echo -5,-6 > /sys/bus/ap/apmask + or + echo 0xf9ff \ + > apmask - echo -4,-0x47,-0xab,-0xff > /sys/bus/ap/aqmask + This would result in binding all available queues for adapters 05 and 06 to + the vfio_ap device driver: - Or the masks can be set as follows: + /sys/bus/ap + ... [drivers] + .. [vfio_ap] + . [05.0004] + . [05.0005] + . [05.0006] + . [05.0047] + . [05.00ab] + . [05.00ff] + . [06.0004] + . [06.0005] + . [06.0006] + . [06.0047] + . [06.00ab] + . [06.00ff] - echo 0xf9ff \ - > apmask + To reserve only the queues (thus allowing the adapters to be shared by the + host and guests): + echo -4,-0x47,-0xab,-0xff > /sys/bus/ap/aqmask + or echo
[PATCH v2 0/8] s390: vfio-ap: dynamic configuration support
This patch series extends the crypto adapter pass-through support to provide safeguards against inadvertent sharing of AP resources between guests and/or the host, and to implement more of the s390 AP architecture related to provisioning and dynamic configuration of AP resources. Change log v1->v2: - * Removed patches preventing root user from unbinding AP queues from the vfio_ap device driver * Introduced a shadow CRYCB in the vfio_ap driver to manage dynamic changes to the AP guest configuration due to root user interventions or hardware anomalies. Tony Krowiak (8): s390: vfio-ap: maintain a shadow of the CRYCB in use by a guest s390: vfio-ap: sysfs interface to display guest CRYCB s390: vfio-ap: allow assignment of unavailable AP resources to mdev device s390: vfio-ap: allow hot plug/unplug of AP resources using mdev device s390: vfio-ap: wait for queue empty on queue reset s390: kvm: test CRYCB masks before setting them s390: vfio-ap: handle bind and unbind of AP queue device s390: vfio-ap: update documentation Documentation/s390/vfio-ap.txt| 188 +++--- arch/s390/kvm/kvm-s390.c | 31 +++ drivers/s390/crypto/vfio_ap_drv.c | 16 +- drivers/s390/crypto/vfio_ap_ops.c | 449 -- drivers/s390/crypto/vfio_ap_private.h | 4 + 5 files changed, 467 insertions(+), 221 deletions(-) -- 2.7.4
[PATCH v2 3/8] s390: vfio-ap: allow assignment of unavailable AP resources to mdev device
The AP architecture does not preclude assignment of AP resources that are
not yet in the AP configuration (i.e., not available or not online).
Let's go ahead and implement this facet of the AP architecture for linux
guests.
Access to AP resources is controlled by bit masks in a guest's SIE
state description (i.e., the control block containing the state of a
guest). When an AP instruction is executed on the guest, the firmware
combines the masks from the guest's SIE state description with the masks
from the host by doing a logical bitwise AND of the masks to create what
are defined as effective masks. The effective masks determine which AP
resources can be accessed by the guest.
Effective masking allows the assignment of AP resources to a guest even
if the underlying device is not in the AP configuration. If the device
subsequently becomes configured, the guest will automatically have access
to the associated AP resources (e.g., AP queues).
The current implementation does not allow assignment of AP resources to
an mdev device if the AP queues identified by the assignment are not
bound to the vfio_ap device driver. This patch allows assignment of AP
resources to the mdev device even if the AP queues are not bound to the
vfio_ap device driver, as long as the AP queues are not reserved by the
AP BUS for use by the zcrypt device drivers. If the queues are subsequently
bound to the vfio_ap device driver while a running guest is using the mdev
device, the guest will automatically gain access to the queues. Effective
masking prevents access to queues until such time as they become available.
Signed-off-by: Tony Krowiak
---
drivers/s390/crypto/vfio_ap_ops.c | 160 +-
1 file changed, 18 insertions(+), 142 deletions(-)
diff --git a/drivers/s390/crypto/vfio_ap_ops.c
b/drivers/s390/crypto/vfio_ap_ops.c
index eae4ee24460a..221491a9ba95 100644
--- a/drivers/s390/crypto/vfio_ap_ops.c
+++ b/drivers/s390/crypto/vfio_ap_ops.c
@@ -113,122 +113,6 @@ static struct attribute_group *vfio_ap_mdev_type_groups[]
= {
NULL,
};
-struct vfio_ap_queue_reserved {
- unsigned long *apid;
- unsigned long *apqi;
- bool reserved;
-};
-
-/**
- * vfio_ap_has_queue
- *
- * @dev: an AP queue device
- * @data: a struct vfio_ap_queue_reserved reference
- *
- * Flags whether the AP queue device (@dev) has a queue ID containing the APQN,
- * apid or apqi specified in @data:
- *
- * - If @data contains both an apid and apqi value, then @data will be flagged
- * as reserved if the APID and APQI fields for the AP queue device matches
- *
- * - If @data contains only an apid value, @data will be flagged as
- * reserved if the APID field in the AP queue device matches
- *
- * - If @data contains only an apqi value, @data will be flagged as
- * reserved if the APQI field in the AP queue device matches
- *
- * Returns 0 to indicate the input to function succeeded. Returns -EINVAL if
- * @data does not contain either an apid or apqi.
- */
-static int vfio_ap_has_queue(struct device *dev, void *data)
-{
- struct vfio_ap_queue_reserved *qres = data;
- struct ap_queue *ap_queue = to_ap_queue(dev);
- ap_qid_t qid;
- unsigned long id;
-
- if (qres->apid && qres->apqi) {
- qid = AP_MKQID(*qres->apid, *qres->apqi);
- if (qid == ap_queue->qid)
- qres->reserved = true;
- } else if (qres->apid && !qres->apqi) {
- id = AP_QID_CARD(ap_queue->qid);
- if (id == *qres->apid)
- qres->reserved = true;
- } else if (!qres->apid && qres->apqi) {
- id = AP_QID_QUEUE(ap_queue->qid);
- if (id == *qres->apqi)
- qres->reserved = true;
- } else {
- return -EINVAL;
- }
-
- return 0;
-}
-
-/**
- * vfio_ap_verify_queue_reserved
- *
- * @matrix_dev: a mediated matrix device
- * @apid: an AP adapter ID
- * @apqi: an AP queue index
- *
- * Verifies that the AP queue with @apid/@apqi is reserved by the VFIO AP
device
- * driver according to the following rules:
- *
- * - If both @apid and @apqi are not NULL, then there must be an AP queue
- * device bound to the vfio_ap driver with the APQN identified by @apid and
- * @apqi
- *
- * - If only @apid is not NULL, then there must be an AP queue device bound
- * to the vfio_ap driver with an APQN containing @apid
- *
- * - If only @apqi is not NULL, then there must be an AP queue device bound
- * to the vfio_ap driver with an APQN containing @apqi
- *
- * Returns 0 if the AP queue is reserved; otherwise, returns -EADDRNOTAVAIL.
- */
-static int vfio_ap_verify_queue_reserved(unsigned long *apid,
-unsigned long *apqi)
-{
- int ret;
- struct vfio_ap_queue_reserved qres;
-
- qres.apid = apid;
- qres.apqi = apqi;
- qres.reserved = false;
-
- ret =
[PATCH v2 6/8] s390: kvm: test CRYCB masks before setting them
There is no sense in blocking all vCPUs to set the masks in the guest's
CRYCB if the mask values will not be changed, so let's verify
Let's verify that mask values will be changed before blocking all vCPUs
in order to set the crypto masks in the guest's CRYCB.
Signed-off-by: Tony Krowiak
---
arch/s390/kvm/kvm-s390.c | 31 +++
1 file changed, 31 insertions(+)
diff --git a/arch/s390/kvm/kvm-s390.c b/arch/s390/kvm/kvm-s390.c
index 4638303ba6a8..38835717c815 100644
--- a/arch/s390/kvm/kvm-s390.c
+++ b/arch/s390/kvm/kvm-s390.c
@@ -2217,12 +2217,43 @@ static void kvm_s390_set_crycb_format(struct kvm *kvm)
kvm->arch.crypto.crycbd |= CRYCB_FORMAT1;
}
+static int kvm_arch_crypto_test_masks(struct kvm *kvm, unsigned long *apm,
+ unsigned long *aqm, unsigned long *adm)
+{
+ int ret;
+ struct kvm_s390_crypto_cb *crycb = kvm->arch.crypto.crycb;
+
+ switch (kvm->arch.crypto.crycbd & CRYCB_FORMAT_MASK) {
+ case CRYCB_FORMAT2: /* APCB1 use 256 bits */
+ ret = bitmap_equal(apm, (unsigned long *)crycb->apcb1.apm, 256);
+ ret &= bitmap_equal(aqm,
+ (unsigned long *)crycb->apcb1.aqm, 256);
+ ret &= bitmap_equal(adm,
+ (unsigned long *)crycb->apcb1.adm, 256);
+ break;
+ case CRYCB_FORMAT1:
+ case CRYCB_FORMAT0: /* Fall through both use APCB0 */
+ ret = bitmap_equal(apm, (unsigned long *)crycb->apcb0.apm, 64);
+ ret &= bitmap_equal(aqm, (unsigned long *)crycb->apcb0.aqm, 16);
+ ret &= bitmap_equal(adm, (unsigned long *)crycb->apcb0.adm, 16);
+ break;
+ default:/* Can not happen */
+ ret = 0;
+ break;
+ }
+ return ret;
+}
+
void kvm_arch_crypto_set_masks(struct kvm *kvm, unsigned long *apm,
unsigned long *aqm, unsigned long *adm)
{
struct kvm_s390_crypto_cb *crycb = kvm->arch.crypto.crycb;
mutex_lock(>lock);
+ if (kvm_arch_crypto_test_masks(kvm, apm, aqm, adm)) {
+ mutex_unlock(>lock);
+ return;
+ }
kvm_s390_vcpu_block_all(kvm);
switch (kvm->arch.crypto.crycbd & CRYCB_FORMAT_MASK) {
--
2.7.4
[PATCH v2 2/8] s390: vfio-ap: sysfs interface to display guest CRYCB
Introduces a sysfs interface on the matrix mdev device to display the
contents of the shadow of the guest's CRYCB
Signed-off-by: Tony Krowiak
---
drivers/s390/crypto/vfio_ap_ops.c | 58 +++
1 file changed, 58 insertions(+)
diff --git a/drivers/s390/crypto/vfio_ap_ops.c
b/drivers/s390/crypto/vfio_ap_ops.c
index b0453e6c20d0..eae4ee24460a 100644
--- a/drivers/s390/crypto/vfio_ap_ops.c
+++ b/drivers/s390/crypto/vfio_ap_ops.c
@@ -750,6 +750,63 @@ static ssize_t matrix_show(struct device *dev, struct
device_attribute *attr,
}
static DEVICE_ATTR_RO(matrix);
+static ssize_t guest_matrix_show(struct device *dev,
+struct device_attribute *attr, char *buf)
+{
+ struct mdev_device *mdev = mdev_from_dev(dev);
+ struct ap_matrix_mdev *matrix_mdev = mdev_get_drvdata(mdev);
+ char *bufpos = buf;
+ unsigned long apid;
+ unsigned long apqi;
+ unsigned long apid1;
+ unsigned long apqi1;
+ unsigned long napm_bits = matrix_mdev->shadow_crycb->apm_max + 1;
+ unsigned long naqm_bits = matrix_mdev->shadow_crycb->aqm_max + 1;
+ int nchars = 0;
+ int n;
+
+ if (!matrix_mdev->shadow_crycb)
+ return -ENODEV;
+
+ apid1 = find_first_bit_inv(matrix_mdev->shadow_crycb->apm, napm_bits);
+ apqi1 = find_first_bit_inv(matrix_mdev->shadow_crycb->aqm, naqm_bits);
+
+ mutex_lock(_dev->lock);
+
+ if ((apid1 < napm_bits) && (apqi1 < naqm_bits)) {
+ for_each_set_bit_inv(apid, matrix_mdev->shadow_crycb->apm,
+napm_bits) {
+ for_each_set_bit_inv(apqi,
+matrix_mdev->shadow_crycb->aqm,
+naqm_bits) {
+ n = sprintf(bufpos, "%02lx.%04lx\n", apid,
+ apqi);
+ bufpos += n;
+ nchars += n;
+ }
+ }
+ } else if (apid1 < napm_bits) {
+ for_each_set_bit_inv(apid, matrix_mdev->shadow_crycb->apm,
+napm_bits) {
+ n = sprintf(bufpos, "%02lx.\n", apid);
+ bufpos += n;
+ nchars += n;
+ }
+ } else if (apqi1 < naqm_bits) {
+ for_each_set_bit_inv(apqi, matrix_mdev->shadow_crycb->aqm,
+naqm_bits) {
+ n = sprintf(bufpos, ".%04lx\n", apqi);
+ bufpos += n;
+ nchars += n;
+ }
+ }
+
+ mutex_unlock(_dev->lock);
+
+ return nchars;
+}
+static DEVICE_ATTR_RO(guest_matrix);
+
static struct attribute *vfio_ap_mdev_attrs[] = {
_attr_assign_adapter.attr,
_attr_unassign_adapter.attr,
@@ -759,6 +816,7 @@ static struct attribute *vfio_ap_mdev_attrs[] = {
_attr_unassign_control_domain.attr,
_attr_control_domains.attr,
_attr_matrix.attr,
+ _attr_guest_matrix.attr,
NULL,
};
--
2.7.4
Re: [PATCH] staging: unisys: use help instead of ---help--- in Kconfig
On Sat, Apr 20, 2019 at 11:46:46AM +, MosesChristopher wrote: > From: Moses Christopher > > - Resolve the following warning from the Kconfig, > "WARNING: prefer 'help' over '---help---' for new help texts" > > Signed-off-by: Moses Christopher > --- > drivers/staging/unisys/Kconfig| 2 +- > drivers/staging/unisys/visorhba/Kconfig | 2 +- > drivers/staging/unisys/visorinput/Kconfig | 2 +- > drivers/staging/unisys/visornic/Kconfig | 2 +- > 4 files changed, 4 insertions(+), 4 deletions(-) This, and all of your other ---help--- conversion patches, do not apply at all as some of these have already been done by others in my tree. Please rebase all of your help cleanup staging patches against my staging-next branch and resend any remaining ones that are needed, as I'm going to drop all of these from my queue right now. thanks, greg k-h
Re: [PATCH] Staging: mt7621-mmc: Cleanup in msdc_app_cmd()
On Fri, Apr 19, 2019 at 04:11:30PM -0500, Madhumitha Prabakaran wrote: > Remove unwanted variable and replace the respective return type. > > Issue suggested by Coccinelle. > > Signed-off-by: Madhumitha Prabakaran > --- > drivers/staging/mt7621-mmc/sd.c | 4 +--- > 1 file changed, 1 insertion(+), 3 deletions(-) This file is long deleted. Always make sure you work off of the latest development tree for the subsystem you are wanting to contribute to. Or on linux-next at the least. thanks, greg k-h
Re: [GIT PULL] Please pull 1 NFS client bugfix
The pull request you sent on Sat, 20 Apr 2019 19:28:24 +: > git://git.linux-nfs.org/projects/trondmy/linux-nfs.git tags/nfs-for-5.1-5 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/9e5de623a0cb9374bdcc73c0c098818f0d7ab7e9 Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Re: [GIT PULL] SCSI fixes for 5.1-rc5
The pull request you sent on Sat, 20 Apr 2019 19:55:52 +0100: > git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi.git scsi-fixes has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/a06bc2f241f2e6c0c27b48e4c383d6cddd4f6464 Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Re: [PATCH] RAS/CEC: Add debugfs switch to disable at run time
On Thu, Apr 18, 2019 at 03:02:29PM -0700, Tony Luck wrote:
> Useful when running error injection tests that want to
> see all of the MCi_(STATUS|ADDR|MISC) data via /dev/mcelog.
>
> Signed-off-by: Tony Luck
> ---
> drivers/ras/cec.c | 20 +++-
> 1 file changed, 19 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/ras/cec.c b/drivers/ras/cec.c
> index 2d9ec378a8bc..a2ceedcd8516 100644
> --- a/drivers/ras/cec.c
> +++ b/drivers/ras/cec.c
> @@ -123,6 +123,9 @@ static u64 dfs_pfn;
> /* Amount of errors after which we offline */
> static unsigned int count_threshold = COUNT_MASK;
>
> +/* debugfs switch to enable/disable CEC */
> +static u64 cec_enabled = 1;
> +
> /*
> * The timer "decays" element count each timer_interval which is 24hrs by
> * default.
> @@ -400,6 +403,14 @@ static int count_threshold_set(void *data, u64 val)
> }
> DEFINE_DEBUGFS_ATTRIBUTE(count_threshold_ops, u64_get, count_threshold_set,
> "%lld\n");
>
> +static int enable_set(void *data, u64 val)
> +{
> + ce_arr.disabled = !val;
Btw, regardless of what we end up doing wrt hiding this switch under
RAS_CEC_DEBUG or exposing it, that ce_arr.disabled flag is not
needed anymore and you can remove it along with the flags union in
ce_array with the next version of this. Because one of the cec_enabled
or ce_arr.disabled is now redundant and I think you want to have
cec_enabled. :)
Thx.
--
Regards/Gruss,
Boris.
Good mailing practices for 400: avoid top-posting and trim the reply.
Re: [PATCH v2] Staging: vc04_services: Cleanup in ctrl_set_bitrate()
On Sat, Apr 20, 2019 at 11:56:44AM -0500, Madhumitha Prabakaran wrote:
> Remove unnecessary variable and replace return type.
> In addition to that align the function parameters with parentheses to
> maintain Linux coding style.
>
> Issue suggested by Coccinelle.
>
> Signed-off-by: Madhumitha Prabakaran
>
> ---
> Changes in v2
>
> 1) Fix my own error of removing function call from the variable.
> 2) Align the function parameters with parentheses.
>
> ---
> ---
> .../staging/vc04_services/bcm2835-camera/controls.c| 10 --
> 1 file changed, 4 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/staging/vc04_services/bcm2835-camera/controls.c
> b/drivers/staging/vc04_services/bcm2835-camera/controls.c
> index e39ab5fae724..71eb349c3138 100644
> --- a/drivers/staging/vc04_services/bcm2835-camera/controls.c
> +++ b/drivers/staging/vc04_services/bcm2835-camera/controls.c
> @@ -607,18 +607,16 @@ static int ctrl_set_bitrate(struct bm2835_mmal_dev *dev,
> struct v4l2_ctrl *ctrl,
> const struct bm2835_mmal_v4l2_ctrl *mmal_ctrl)
> {
> - int ret;
> struct vchiq_mmal_port *encoder_out;
>
> dev->capture.encode_bitrate = ctrl->val;
>
> encoder_out = >component[MMAL_COMPONENT_VIDEO_ENCODE]->output[0];
>
> - ret = vchiq_mmal_port_parameter_set(dev->instance, encoder_out,
> - mmal_ctrl->mmal_id,
> - >val, sizeof(ctrl->val));
> - ret = 0;
> - return ret;
> + vchiq_mmal_port_parameter_set(dev->instance, encoder_out,
> + mmal_ctrl->mmal_id, >val,
> + sizeof(ctrl->val));
> + return 0;
> }
Why does this function even return anything at all if it can not fail?
Why not return the value that vchiq_mmal_port_parameter_set() returned?
thanks,
greg k-h
Re: arch/sh/kernel/cpu/sh2/clock-sh7619.o:undefined reference to `followparent_recalc'
On 4/20/19 12:40 AM, kbuild test robot wrote: > Hi Randy, > > It's probably a bug fix that unveils the link errors. > > tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git > master > head: 371dd432ab39f7bc55d6ec77d63b430285627e04 > commit: acaf892ecbf5be7710ae05a61fd43c668f68ad95 sh: fix multiple function > definition build errors > date: 2 weeks ago > config: sh-allmodconfig (attached as .config) > compiler: sh4-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0 > reproduce: > wget > https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O > ~/bin/make.cross > chmod +x ~/bin/make.cross > git checkout acaf892ecbf5be7710ae05a61fd43c668f68ad95 > # save the attached .config to linux build tree > GCC_VERSION=7.2.0 make.cross ARCH=sh Hi, Once again, the question is the validity of the SH2 .config file in this case (that was attached). I don't believe that it is valid because CONFIG_SH_DEVICE_TREE=y, which selects COMMON_CLK, and there is no followparent_recalc() in the COMMON_CLK API. Also, while CONFIG_HAVE_CLK=y, drivers/sh/Makefile prevents that from building clk/core.c, which could provide followparent_recalc(): ifneq ($(CONFIG_COMMON_CLK),y) obj-$(CONFIG_HAVE_CLK) += clk/ endif Hm, maybe that's where the problem is. I'll look into that more. It would be Good if someone from the SuperH area could/would comment. Thanks. > If you fix the issue, kindly add following tag > Reported-by: kbuild test robot > > > All errors (new ones prefixed by >>): > >>> arch/sh/kernel/cpu/sh2/clock-sh7619.o:(.data+0x1c): undefined reference to >>> `followparent_recalc' > > --- > 0-DAY kernel test infrastructureOpen Source Technology Center > https://lists.01.org/pipermail/kbuild-all Intel Corporation > -- ~Randy
[GIT PULL] Please pull 1 NFS client bugfix
Hi Linus, The following changes since commit dc4060a5dc2557e6b5aa813bf5b73677299d62d2: Linux 5.1-rc5 (2019-04-14 15:17:41 -0700) are available in the Git repository at: git://git.linux-nfs.org/projects/trondmy/linux-nfs.git tags/nfs-for-5.1-5 for you to fetch changes up to a7b1a4839ff979b4dd4fb6c1ccd31af11de9ca87: SUNRPC: Ignore queue transmission errors on successful transmission (2019-04-17 16:07:28 -0400) Cheers Trond NFS client bugfixes for Linux 5.1 Highlights include: Bugfixes: - Fix a regression in which an RPC call can be tagged with an error despite the transmission being successful Trond Myklebust (1): SUNRPC: Ignore queue transmission errors on successful transmission net/sunrpc/clnt.c | 7 +-- 1 file changed, 5 insertions(+), 2 deletions(-) -- Trond Myklebust Linux NFS client maintainer, Hammerspace trond.mykleb...@hammerspace.com
Re: [GIT PULL] x86 fixes
The pull request you sent on Sat, 20 Apr 2019 09:38:09 +0200: > git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86-urgent-for-linus has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/1fd91d719eb1ae83ef500eb4148d11db9db39a41 Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Re: [GIT PULL] scheduler fixes
The pull request you sent on Sat, 20 Apr 2019 09:33:41 +0200: > git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git > sched-urgent-for-linus has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/2b4cf5850db6acef2bbef52e3011f9bf93484209 Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Re: [GIT PULL] timer fixes
The pull request you sent on Sat, 20 Apr 2019 09:45:50 +0200: > git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git > timers-urgent-for-linus has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/e899cc3b3d9813f795c039c0f3c689861d6836da Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Re: [GIT PULL] sound fixes for 5.1-rc6
The pull request you sent on Sat, 20 Apr 2019 09:35:33 +0200: > git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git > tags/sound-5.1-rc6 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/4b609f1e26f36c43e2dcdebe81e1d612705920d4 Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Re: [GIT PULL] locking fixes
The pull request you sent on Sat, 20 Apr 2019 09:30:18 +0200: > git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git > locking-urgent-for-linus has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/de3af9a99013fdb0358bb990e9bed0172c65bba9 Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Re: [GIT PULL] i3c: Fixes for 5.1-rc6
The pull request you sent on Sat, 20 Apr 2019 11:23:40 +0200: > git://git.kernel.org/pub/scm/linux/kernel/git/i3c/linux.git > tags/i3c/fixes-for-5.1-rc6 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/34396bdfd2b7b41b9dcd2126eb1a57e43fe13368 Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Re: [GIT PULL] perf fixes
The pull request you sent on Sat, 20 Apr 2019 09:43:53 +0200: > git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git > perf-urgent-for-linus has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/b25c69b9d5e41159b54ad7cb33f7d9ead8523d33 Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Re: [PATCH v2 1/2] ras: fix an off-by-one error in __find_elem()
On Sat, Apr 20, 2019 at 12:04 PM Borislav Petkov wrote: > > On Sat, Apr 20, 2019 at 11:25:43AM -0700, Cong Wang wrote: > > If you want to go that far, you can choose to use lib/bsearch.c too in > > case you want to reinvent the wheel. > > Well, that doesn't give me the @to functionality which points to the > slot where the new element should be inserted, when the search was > unsuccessful. No one stops you from adding it, as you are going far you can always go further. :) > > > What's your point here? > > My point is to fix it properly. Obviously. Of course, no one can stop you from rewriting the whole ras code by doing it properly. > > > You know my fix is targeted for -stable, > > Well, first you sent me this: > > https://lkml.kernel.org/r/20190416012001.5338-1-xiyou.wangc...@gmail.com > > then this: > > https://lkml.kernel.org/r/20190416213351.28999-1-xiyou.wangc...@gmail.com Yes, one is V1 and the other is V2. Is it hard to understand V2 is to replace V1? > > Tony liked this second version more and if you look at the final result of > mine: Sorry, I have no reason to look into a 83-line change. > it has basically *both*: the correct [min:max] range *and* the return of > ithe ndex when found. But the algorithm this time is the correct one. I don't review it, so I don't know. Feel free to believe you are correct here, until someone finds a bug later. > > > I doubt your 83-line change could fit for -stable. > > My 83-line change has debug output only for experimentation. It will, > *of* *course* be removed before committing it upstream. That's why I > called it "a conglomerate patch" and I said "It has some debug output > for easier debugging, that will be removed in the final version, of > course." I guess you didn't read that either. Why should I read a debugging patch? > > And the sanity_check() piece will be a separate patch, of course. > > In the end the diffstat will be 30-40 lines max. > > > Feel free to drop my patch to favor yours. I am really tired. > > Suit yourself. Thanks for the reporting. There is no bug here, your code is perfect. :) Sorry for wasting your time to believe this it is bug, it is not. :-) Thanks.
Re: [PATCH] RAS/CEC: Add debugfs switch to disable at run time
On Sat, Apr 20, 2019 at 11:47 AM Borislav Petkov wrote: > IOW, when you have the CEC enabled, you don't need to log memory errors > with a userspace agent. The CEC collects them and discards them if they > don't repeat. So, you mean breaking mcelog is intentionally, if so, why not break it loudly? That is, for example, preventing mcelog from starting by disabling CONFIG_X86_MCELOG_LEGACY in Kconfig _automatically_ when CONFIG_RAS is enabled? (Like what I showed in my PoC change.) Or, for another example, print a kernel warning and let users know this behavior is intentional? > > If they do repeat, then it offlines the page. > > Without user intervention and interference. > > Now, if you still want to know how many errors and where they happened > and when they happened and yadda yadda, you *disable* the CEC. Well, I believe rasdaemon has the counters too, it is not hard to count the trace events at all. I don't worry about this at all. What I worry is how we treat mcelog when having CONFIG_RAS=y. > > I hope this makes more sense now. Yes, thanks for the information. It is kinda what I expected, as I keep saying, I believe we can improve this situation to avoid users' confusion, rather than just saying CONFIG_RAS=n is the answer. Thanks.
Re: [PATCH v2 1/2] ras: fix an off-by-one error in __find_elem()
On Sat, Apr 20, 2019 at 11:25:43AM -0700, Cong Wang wrote:
> If you want to go that far, you can choose to use lib/bsearch.c too in
> case you want to reinvent the wheel.
Well, that doesn't give me the @to functionality which points to the
slot where the new element should be inserted, when the search was
unsuccessful.
> What's your point here?
My point is to fix it properly. Obviously.
> You know my fix is targeted for -stable,
Well, first you sent me this:
https://lkml.kernel.org/r/20190416012001.5338-1-xiyou.wangc...@gmail.com
then this:
https://lkml.kernel.org/r/20190416213351.28999-1-xiyou.wangc...@gmail.com
Tony liked this second version more and if you look at the final result of mine:
int min = 0, max = ca->n - 1;
...
if (this_pfn < pfn)
min = i + 1;
else if (this_pfn > pfn)
max = i - 1;
else if (this_pfn == pfn) {
if (to)
*to = i;
return i;
}
it has basically *both*: the correct [min:max] range *and* the return of
ithe ndex when found. But the algorithm this time is the correct one.
> I doubt your 83-line change could fit for -stable.
My 83-line change has debug output only for experimentation. It will,
*of* *course* be removed before committing it upstream. That's why I
called it "a conglomerate patch" and I said "It has some debug output
for easier debugging, that will be removed in the final version, of
course." I guess you didn't read that either.
And the sanity_check() piece will be a separate patch, of course.
In the end the diffstat will be 30-40 lines max.
> Feel free to drop my patch to favor yours. I am really tired.
Suit yourself. Thanks for the reporting.
> Good luck with that!
Ditto.
--
Regards/Gruss,
Boris.
Good mailing practices for 400: avoid top-posting and trim the reply.
Re: [PATCH] RAS/CEC: Add debugfs switch to disable at run time
On Sat, Apr 20, 2019 at 11:18:46AM -0700, Cong Wang wrote: > You didn't answer my question here, because I asked you whether > the following change (PoC only) makes sense: I answered it - the answer is to disable CONFIG_RAS_CEC. But let me do a more detailed answer, maybe that'll help. The PoC doesn't make sense. Why? Because if you don't return early from the notifier when the CEC has consumed the error, you don't need the CEC at all. Ergo, you can just as well disable it. Because, let me paste from a couple of mails ago what the CEC is: "CEC is something *completely* different and its purpose is to run in the kernel and prevent users and admins from upsetting unnecessarily with every sporadic correctable error and just because an alpha particle flew through their DIMMs, they all start running in headless chicken mode, trying to RMA perfectly good hardware." IOW, when you have the CEC enabled, you don't need to log memory errors with a userspace agent. The CEC collects them and discards them if they don't repeat. If they do repeat, then it offlines the page. Without user intervention and interference. Now, if you still want to know how many errors and where they happened and when they happened and yadda yadda, you *disable* the CEC. I hope this makes more sense now. > I knew disabling it could cure the problem from the beginning, please > save your own time by not repeating things we both already knew. :) > > Once again, I still don't think it is the right answer, which is also why I > keep finding different solutions. This is where you come in and say "it is not the right answer because..." and give your arguments why. I gave mine a couple of times already. I never said this functionality is cast in stone the way it is but there has to be a *good* *reason* why it needs to be changed. I.e., basic kernel deveopment. People come with ideas and they *justify* those ideas with arguments why they're better. > I know you disagree, but you never explain why you disagree, You're kidding, right? https://lkml.kernel.org/r/20190419002645.ga...@zn.tnic -- Regards/Gruss, Boris. Good mailing practices for 400: avoid top-posting and trim the reply.
Re: [PATCH v2 1/2] ras: fix an off-by-one error in __find_elem()
On Sat, Apr 20, 2019 at 4:34 AM Borislav Petkov wrote: > > On Tue, Apr 16, 2019 at 04:16:08PM -0700, Cong Wang wrote: > > It is actually fairly easy: > > > > 1) Fill the whole page with PFN's: > > for i in `seq 0 511`; do echo $i >> /sys/kernel/debug/ras/cec/pfn; done > > > > 2) Set thresh to 1 in order to trigger the deletion: > > echo 1 > /sys/kernel/debug/ras/cec/count_threshold > > > > 3) Repeatedly add and remove the last element: > > echo 512 >> /sys/kernel/debug/ras/cec/pfn > > (until you get a crash.) > > Thanks, I was able to reproduce with that. Below is a conglomerate patch > which converts __find_elem() to using Donald Knuth's binary search > version. I don't know what I was thinking then and why I didn't use > it from the get-go. The textbook even says that one can easily get it > wrong... If you want to go that far, you can choose to use lib/bsearch.c too in case you want to reinvent the wheel. What's your point here? You know my fix is targeted for -stable, I doubt your 83-line change could fit for -stable. Feel free to drop my patch to favor yours. I am really tired. Good luck with that! Thanks.
Re: [PATCH] RAS/CEC: Add debugfs switch to disable at run time
On Sat, Apr 20, 2019 at 2:13 AM Borislav Petkov wrote:
>
> On Fri, Apr 19, 2019 at 10:43:03PM -0700, Cong Wang wrote:
> > With this change, although not even compiled, mcelog should still
> > receive correctable memory errors like before, even when we have
> > CONFIG_RAS_CEC=y.
> >
> > Does this make any sense to you?
>
> Yes, the answer is in the mail you snipped. Did you read it?
I read it, all of your response is based on your speculation that I
don't have CONFIG_X86_MCELOG_LEGACY=y, which is clearly
a misunderstanding.
You didn't answer my question here, because I asked you whether
the following change (PoC only) makes sense:
@ -567,12 +567,12 @@ static int mce_first_notifier(struct
notifier_block *nb, unsigned long val,
void *data)
{
struct mce *m = (struct mce *)data;
+ bool consumed;
if (!m)
return NOTIFY_DONE;
- if (cec_add_mce(m))
- return NOTIFY_STOP;
+ consumed = cec_add_mce(m);
/* Emit the trace record: */
trace_mce_record(m);
@@ -581,7 +581,7 @@ static int mce_first_notifier(struct
notifier_block *nb, unsigned long val,
mce_notify_irq();
- return NOTIFY_DONE;
+ return consumed ? NOTIFY_STOP : NOTIFY_DONE;
}
>
> Hint: disable CONFIG_RAS_CEC.
I knew disabling it could cure the problem from the beginning, please
save your own time by not repeating things we both already knew. :)
Once again, I still don't think it is the right answer, which is also why I
keep finding different solutions. I know you disagree, but you never explain
why you disagree, you speculated CONFIG_X86_MCELOG_LEGACY,
which is completely a misunderstanding.
I brought up CONFIG_X86_MCELOG_LEGACY simply to show you
how we could break mcelog _LOUDLY_ if we really decide to break it,
currently it just breaks silently. You misinterpret it as if I understand
CONFIG_RAS as a replacement for CONFIG_X86_MCELOG_LEGACY,
which is a very sad misunderstanding.
Thanks.
Re: [PATCH -mm] elf: init pt_regs pointer later
On Fri, Apr 19, 2019 at 01:08:26PM -0700, Andrew Morton wrote:
> On Fri, 19 Apr 2019 23:03:43 +0300 Alexey Dobriyan
> wrote:
>
> > Get "current_pt_regs" pointer right before usage.
> >
> > Space savings on x86_64:
> >
> > add/remove: 0/0 grow/shrink: 0/1 up/down: 0/-180 (-180)
> > Function old new delta
> > load_elf_binary 58065626-180 !!!
>
> -256 bytes with my setup.
>
> > --- a/fs/binfmt_elf.c
> > +++ b/fs/binfmt_elf.c
> > @@ -704,12 +704,12 @@ static int load_elf_binary(struct linux_binprm *bprm)
> > unsigned long start_code, end_code, start_data, end_data;
> > unsigned long reloc_func_desc __maybe_unused = 0;
> > int executable_stack = EXSTACK_DEFAULT;
> > - struct pt_regs *regs = current_pt_regs();
> > struct {
> > struct elfhdr elf_ex;
> > struct elfhdr interp_elf_ex;
> > } *loc;
> > struct arch_elf_state arch_state = INIT_ARCH_ELF_STATE;
> > + struct pt_regs *regs;
> >
> > loc = kmalloc(sizeof(*loc), GFP_KERNEL);
> > if (!loc) {
> > @@ -1159,6 +1159,7 @@ static int load_elf_binary(struct linux_binprm *bprm)
> > MAP_FIXED | MAP_PRIVATE, 0);
> > }
> >
> > + regs = current_pt_regs();
> > #ifdef ELF_PLAT_INIT
> > /*
> > * The ABI may specify that certain registers be set up in special
>
> Why the heck does this make such a difference?
Good question. Looks like compiler doesn't know that "current_pt_regs" is
stable pointer (because it doesn't know ->stack isn't) even though it knows
that "current" is stable pointer. So it saves it in the very beginning and
then tries to carry it through a lot of code.
Here is what happens here:
load_elf_binary()
...
mov rax,QWORD PTR gs:0x14c00
mov r13,QWORD PTR [rax+0x18]r13 = current->stack
callkmem_cache_alloc# first kmalloc
[980 bytes later!]
# let's spill that sucker because we need a register
# for "load_bias" calculations at
#
# if (interpreter) {
# load_bias = ELF_ET_DYN_BASE;
# if (current->flags & PF_RANDOMIZE)
# load_bias += arch_mmap_rnd();
# elf_flags |= elf_fixed;
# }
mov QWORD PTR [rsp+0x68],r13
If this is not _the_ root cause it is still h.
After the patch things become much simpler:
mov rax, QWORD PTR gs:0x14c00 # current
mov rdx, QWORD PTR [rax+0x18] # current->stack
movq[rdx+0x3fb8], 0 # fill pt_regs
...
call finalize_exec
Re: [PATCH 0/3] agp: Misc fix
On Fri, Sep 01, 2017 at 02:13:29PM +0200, Corentin Labbe wrote: > Hello > > The first patch goal is to regroup all miscdevice number in the same place. > The two subsequent patch are build warning fix found when working on the > first. > > Corentin Labbe (3): > agp: move AGPGART_MINOR to include/linux/miscdevice.h > agp: add compat_ioctl.h to frontend.c > agp: remove unused variable num_segments > > drivers/char/agp/frontend.c | 4 ++-- > include/linux/agpgart.h | 2 -- > include/linux/miscdevice.h | 1 + > 3 files changed, 3 insertions(+), 4 deletions(-) > > -- > 2.13.5 > Hello Gentle ping Regards
Re: [PATCH RESEND] misc: mic: Remove linux/miscdevice.h include
On Mon, Sep 18, 2017 at 06:52:52PM +0200, Corentin Labbe wrote:
> linux/miscdevice.h include was added in commit 1da2b3eeef36 ("misc: mic:
> Remove COSM functionality from the MIC host driver")
> along with a struct miscdevice miscdev in struct mic_device.
> but the following commit ef39830c3583 ("misc: mic: Remove MIC X100 host
> virtio functionality")
> remove all miscdevice.
>
> This patch remove linux/miscdevice.h which was forgeted and now unnecessary.
>
> Signed-off-by: Corentin Labbe
Hello
Gentle ping
Regards
Re: [PATCH] agp: Add bridge parameter documentation
On Wed, Dec 20, 2017 at 07:26:50PM +, Corentin Labbe wrote: > This patch add documentation about the bridge parameter in several > function. > > This will fix the following build warning: > drivers/char/agp/generic.c:220: warning: No description found for parameter > 'bridge' > drivers/char/agp/generic.c:364: warning: No description found for parameter > 'bridge' > drivers/char/agp/generic.c:1283: warning: No description found for parameter > 'bridge' > > Signed-off-by: Corentin Labbe Hello gentle ping Regards > --- > drivers/char/agp/generic.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/drivers/char/agp/generic.c b/drivers/char/agp/generic.c > index 27a022f806fa..cf50a180c8d6 100644 > --- a/drivers/char/agp/generic.c > +++ b/drivers/char/agp/generic.c > @@ -207,6 +207,7 @@ EXPORT_SYMBOL(agp_free_memory); > /** > * agp_allocate_memory - allocate a group of pages of a certain type. > * > + * @bridge: an agp_bridge_data struct allocated for the AGP host bridge. > * @page_count:size_t argument of the number of pages > * @type: u32 argument of the type of memory to be allocated. > * > @@ -355,6 +356,7 @@ EXPORT_SYMBOL_GPL(agp_num_entries); > /** > * agp_copy_info - copy bridge state information > * > + * @bridge: an agp_bridge_data struct allocated for the AGP host bridge. > * @info: agp_kern_info pointer. The caller should insure that > this pointer is valid. > * > * This function copies information about the agp bridge device and the > state of > @@ -1277,6 +1279,7 @@ EXPORT_SYMBOL(agp_generic_destroy_page); > /** > * agp_enable - initialise the agp point-to-point connection. > * > + * @bridge: an agp_bridge_data struct allocated for the AGP host bridge. > * @mode:agp mode register value to configure with. > */ > void agp_enable(struct agp_bridge_data *bridge, u32 mode) > -- > 2.13.6 >
Notification of VIRUS mail
A VIRUS-infected mail is sent to you and Virus-infected attached file is DELETED. Date : Sun, 21 Apr 2019 02:18:39 KST +0900 From : spsyst...@spsystems.co.kr From IP : 203.217.210.40 Subject : Re: Greetings . Virus info : W32/FakeDoc.G.gen!Eldorado
Re: [PATCH] ia64: agp: Replace empty define with do while
On Wed, Dec 20, 2017 at 08:16:13PM +0100, Corentin Labbe wrote:
> It's dangerous to use empty code define.
> Furthermore it lead to the following warning:
> drivers/char/agp/generic.c: In function « agp_generic_destroy_page »:
> drivers/char/agp/generic.c:1266:28: attention : suggest braces around empty
> body in an « if » statement [-Wempty-body]
>
> So let's replace emptyness by "do {} while(0)"
>
> Signed-off-by: Corentin Labbe
Hello
Gentle ping
Regards
> ---
> arch/ia64/include/asm/agp.h | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/ia64/include/asm/agp.h b/arch/ia64/include/asm/agp.h
> index 2b451c4496da..0261507dc264 100644
> --- a/arch/ia64/include/asm/agp.h
> +++ b/arch/ia64/include/asm/agp.h
> @@ -14,8 +14,8 @@
> * in coherent mode, which lets us map the AGP memory as normal (write-back)
> memory
> * (unlike x86, where it gets mapped "write-coalescing").
> */
> -#define map_page_into_agp(page) /* nothing */
> -#define unmap_page_from_agp(page)/* nothing */
> +#define map_page_into_agp(page) do { } while (0)
> +#define unmap_page_from_agp(page)do { } while (0)
> #define flush_agp_cache()mb()
>
> /* GATT allocation. Returns/accepts GATT kernel virtual address. */
> --
> 2.13.6
>
Re: [PATCH] staging: rtl8*: use help instead of ---help--- in Kconfig
On 4/20/19 6:37 AM, MosesChristopher wrote: From: Moses Christopher - Resolve the following warning from the Kconfig, "WARNING: prefer 'help' over '---help---' for new help texts" Signed-off-by: Moses Christopher I have never seen this warning, but your Kconfig may be newer than mine. In any case, the changes are harmless. Acked-by: Larry Finger --- drivers/staging/rtl8188eu/Kconfig | 4 ++-- drivers/staging/rtl8192e/Kconfig | 8 drivers/staging/rtl8712/Kconfig | 4 ++-- drivers/staging/rtl8723bs/Kconfig | 2 +- 4 files changed, 9 insertions(+), 9 deletions(-) diff --git a/drivers/staging/rtl8188eu/Kconfig b/drivers/staging/rtl8188eu/Kconfig index ff7832798a77..3f8c655856bf 100644 --- a/drivers/staging/rtl8188eu/Kconfig +++ b/drivers/staging/rtl8188eu/Kconfig @@ -7,7 +7,7 @@ config R8188EU select LIB80211 select LIB80211_CRYPT_WEP select LIB80211_CRYPT_CCMP - ---help--- + help This option adds the Realtek RTL8188EU USB device such as TP-Link TL-WN725N. If built as a module, it will be called r8188eu. @@ -16,7 +16,7 @@ if R8188EU config 88EU_AP_MODE bool "Realtek RTL8188EU AP mode" default y - ---help--- + help This option enables Access Point mode. Unless you know that your system will never be used as an AP, or the target system has limited memory, "Y" should be selected. diff --git a/drivers/staging/rtl8192e/Kconfig b/drivers/staging/rtl8192e/Kconfig index 4602a47cdb4a..aa571c12678f 100644 --- a/drivers/staging/rtl8192e/Kconfig +++ b/drivers/staging/rtl8192e/Kconfig @@ -3,7 +3,7 @@ config RTLLIB depends on WLAN && m default n select LIB80211 - ---help--- + help If you have a wireless card that uses rtllib, say Y. Currently the only card is the rtl8192e. @@ -16,7 +16,7 @@ config RTLLIB_CRYPTO_CCMP depends on RTLLIB select CRYPTO_AES default y - ---help--- + help CCMP crypto driver for rtllib. If you enabled RTLLIB, you want this. @@ -27,7 +27,7 @@ config RTLLIB_CRYPTO_TKIP select CRYPTO_ARC4 select CRYPTO_MICHAEL_MIC default y - ---help--- + help TKIP crypto driver for rtllib. If you enabled RTLLIB, you want this. @@ -37,7 +37,7 @@ config RTLLIB_CRYPTO_WEP select CRYPTO_ARC4 depends on RTLLIB default y - ---help--- + help TKIP crypto driver for rtllib. If you enabled RTLLIB, you want this. diff --git a/drivers/staging/rtl8712/Kconfig b/drivers/staging/rtl8712/Kconfig index f160eee52f09..b377d90742db 100644 --- a/drivers/staging/rtl8712/Kconfig +++ b/drivers/staging/rtl8712/Kconfig @@ -4,14 +4,14 @@ config R8712U select WIRELESS_EXT select WEXT_PRIV select FW_LOADER - ---help--- + help This option adds the Realtek RTL8712 USB device such as the D-Link DWA-130. If built as a module, it will be called r8712u. config R8712_TX_AGGR bool "Realtek RTL8712U Transmit Aggregation code" depends on R8712U && BROKEN - ---help--- + help This option provides transmit aggregation for the Realtek RTL8712 USB device. diff --git a/drivers/staging/rtl8723bs/Kconfig b/drivers/staging/rtl8723bs/Kconfig index deae0427ba6c..41ad6ed24860 100644 --- a/drivers/staging/rtl8723bs/Kconfig +++ b/drivers/staging/rtl8723bs/Kconfig @@ -4,7 +4,7 @@ config RTL8723BS depends on m select WIRELESS_EXT select WEXT_PRIV - ---help--- + help This option enables support for RTL8723BS SDIO drivers, such as the wifi found on the 1st gen Intel Compute Stick, the CHIP and many other Intel Atom and ARM based devices.
[PATCH v2] Staging: vc04_services: Cleanup in ctrl_set_bitrate()
Remove unnecessary variable and replace return type.
In addition to that align the function parameters with parentheses to
maintain Linux coding style.
Issue suggested by Coccinelle.
Signed-off-by: Madhumitha Prabakaran
---
Changes in v2
1) Fix my own error of removing function call from the variable.
2) Align the function parameters with parentheses.
---
---
.../staging/vc04_services/bcm2835-camera/controls.c| 10 --
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git a/drivers/staging/vc04_services/bcm2835-camera/controls.c
b/drivers/staging/vc04_services/bcm2835-camera/controls.c
index e39ab5fae724..71eb349c3138 100644
--- a/drivers/staging/vc04_services/bcm2835-camera/controls.c
+++ b/drivers/staging/vc04_services/bcm2835-camera/controls.c
@@ -607,18 +607,16 @@ static int ctrl_set_bitrate(struct bm2835_mmal_dev *dev,
struct v4l2_ctrl *ctrl,
const struct bm2835_mmal_v4l2_ctrl *mmal_ctrl)
{
- int ret;
struct vchiq_mmal_port *encoder_out;
dev->capture.encode_bitrate = ctrl->val;
encoder_out = >component[MMAL_COMPONENT_VIDEO_ENCODE]->output[0];
- ret = vchiq_mmal_port_parameter_set(dev->instance, encoder_out,
- mmal_ctrl->mmal_id,
- >val, sizeof(ctrl->val));
- ret = 0;
- return ret;
+ vchiq_mmal_port_parameter_set(dev->instance, encoder_out,
+ mmal_ctrl->mmal_id, >val,
+ sizeof(ctrl->val));
+ return 0;
}
static int ctrl_set_bitrate_mode(struct bm2835_mmal_dev *dev,
--
2.17.1
Re: [GIT PULL] locking fixes
On Sat, Apr 20, 2019 at 12:30 AM Ingo Molnar wrote:
>
> A lockdep warning fix and a script execution fix when atomics are
> generated.
Hmm. I've pulled this, but looking at it, I think it's worth noting something...
> diff --git a/scripts/atomic/gen-atomics.sh b/scripts/atomic/gen-atomics.sh
> index 27400b0cd732..000dc6437893 100644
> --- a/scripts/atomic/gen-atomics.sh
> +++ b/scripts/atomic/gen-atomics.sh
> - ${ATOMICDIR}/${script} ${ATOMICTBL} > ${LINUXDIR}/include/${header}
> + /bin/sh ${ATOMICDIR}/${script} ${ATOMICTBL} >
> ${LINUXDIR}/include/${header}
/bin/sh ?
Yes, that's what the hash-bang line says in the scripts themselves,
and thus what we used to do with the whole direct execution thing, so
it's clearly not _wrong_, but every single time when we manually do
the "run with shell" normally, we use $(CONFIG_SHELL)".
So I get the feeling that we should likely do that here too.
Of course, the gen-atomics script is (now) outside the normal build,
so maybe people just go "this is special, doesn't go through the
normal build process anyway, and thus might as well not follow the
common rules".
Linus
Re: [PATCH RESEND] spi: clps711x: remove unused header
On Wed, Sep 19, 2018 at 07:17:54PM +, Corentin Labbe wrote:
> include/linux/platform_data/spi-clps711x.h is unused since commit
> 6acaadc852f1 ("spi: clps711x: Driver refactor")
> Let's remove it.
>
Hello
Gentle ping
Regards
> Signed-off-by: Corentin Labbe
> ---
> include/linux/platform_data/spi-clps711x.h | 21 -
> 1 file changed, 21 deletions(-)
> delete mode 100644 include/linux/platform_data/spi-clps711x.h
>
> diff --git a/include/linux/platform_data/spi-clps711x.h
> b/include/linux/platform_data/spi-clps711x.h
> deleted file mode 100644
> index 301956e63143..
> --- a/include/linux/platform_data/spi-clps711x.h
> +++ /dev/null
> @@ -1,21 +0,0 @@
> -/*
> - * CLPS711X SPI bus driver definitions
> - *
> - * Copyright (C) 2012 Alexander Shiyan
> - *
> - * This program is free software; you can redistribute it and/or modify
> - * it under the terms of the GNU General Public License as published by
> - * the Free Software Foundation; either version 2 of the License, or
> - * (at your option) any later version.
> - */
> -
> -#ifndef LINUX_PLATFORM_DATA_SPI_CLPS711X_H
> -#define LINUX_PLATFORM_DATA_SPI_CLPS711X_H
> -
> -/* Board specific platform_data */
> -struct spi_clps711x_pdata {
> - int *chipselect;/* Array of GPIO-numbers */
> - int num_chipselect; /* Total count of GPIOs */
> -};
> -
> -#endif
> --
> 2.16.4
>
Dear Friend,
Dear Friend, I am Mrs Clara David. am sending you this brief letter to solicit your partnership to transfer $18.5 million US Dollars.I shall send you more information and procedures when I receive positive response from you. please send me a message in my Email box (mrsclarad...@gmail.com) as i wait to hear from you. Best regard Mrs Clara David.
Re: [PATCH] Fix some misuses of %x
On 4/19/19 6:21 AM, Fuqian Huang wrote:
> The pointers should be printed with %p or %px rather than
> cast to long or unsigned long type and printed with %x.
> Change %x to %p to print pointers.
>
> Signed-off-by: Fuqian Huang
Hi,
You will need to send this patch (or patch set/patch series) to the
appropriate subsystem maintainers and their respective mailing lists.
Maintainers don't browse the linux-kernel mailing list to search or
pick up patches.
>From Documentation/process/submitting-patches.rst:
5) Select the recipients for your patch
---
You should always copy the appropriate subsystem maintainer(s) on any patch
to code that they maintain; look through the MAINTAINERS file and the
source code revision history to see who those maintainers are. The
script scripts/get_maintainer.pl can be very useful at this step. If you
cannot find a maintainer for the subsystem you are working on, Andrew
Morton (a...@linux-foundation.org) serves as a maintainer of last resort.
You should also normally choose at least one mailing list to receive a copy
of your patch set. linux-kernel@vger.kernel.org functions as a list of
last resort, but the volume on that list has caused a number of developers
to tune it out. Look in the MAINTAINERS file for a subsystem-specific
list; your patch will probably get more attention there. Please do not
spam unrelated lists, though.
Many kernel-related lists are hosted on vger.kernel.org; you can find a
list of them at http://vger.kernel.org/vger-lists.html. There are
kernel-related lists hosted elsewhere as well, though.
Thanks.
> ---
> drivers/atm/iphase.c | 4 ++--
> drivers/misc/genwqe/card_debugfs.c | 4 ++--
> drivers/net/hippi/rrunner.c| 4 ++--
> kernel/cgroup/debug.c | 8
> net/ax25/af_ax25.c | 4 ++--
> sound/isa/gus/gus_mem.c| 2 +-
> 6 files changed, 13 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/atm/iphase.c b/drivers/atm/iphase.c
> index 82532c299bb5..5278c57dce73 100644
> --- a/drivers/atm/iphase.c
> +++ b/drivers/atm/iphase.c
> @@ -2826,8 +2826,8 @@ static int ia_ioctl(struct atm_dev *dev, unsigned int
> cmd, void __user *arg)
> case 0x6:
> {
> ia_cmds.status = 0;
> - printk("skb = 0x%lx\n", (long)skb_peek(>tx_backlog));
> - printk("rtn_q:
> 0x%lx\n",(long)ia_deque_rtn_q(>tx_return_q));
> + printk("skb = 0x%p\n", skb_peek(>tx_backlog));
> + printk("rtn_q: 0x%p\n",ia_deque_rtn_q(>tx_return_q));
> }
> break;
> case 0x8:
> diff --git a/drivers/misc/genwqe/card_debugfs.c
> b/drivers/misc/genwqe/card_debugfs.c
> index 7c713e01d198..6f7e39f07811 100644
> --- a/drivers/misc/genwqe/card_debugfs.c
> +++ b/drivers/misc/genwqe/card_debugfs.c
> @@ -227,7 +227,7 @@ static int ddcb_info_show(struct seq_file *s, void
> *unused)
> seq_puts(s, "DDCB QUEUE:\n");
> seq_printf(s, " ddcb_max:%d\n"
> " ddcb_daddr: %016llx - %016llx\n"
> -" ddcb_vaddr: %016llx\n"
> +" ddcb_vaddr: %p\n"
> " ddcbs_in_flight: %u\n"
> " ddcbs_max_in_flight: %u\n"
> " ddcbs_completed: %u\n"
> @@ -237,7 +237,7 @@ static int ddcb_info_show(struct seq_file *s, void
> *unused)
> queue->ddcb_max, (long long)queue->ddcb_daddr,
> (long long)queue->ddcb_daddr +
> (queue->ddcb_max * DDCB_LENGTH),
> -(long long)queue->ddcb_vaddr, queue->ddcbs_in_flight,
> +queue->ddcb_vaddr, queue->ddcbs_in_flight,
> queue->ddcbs_max_in_flight, queue->ddcbs_completed,
> queue->return_on_busy, queue->wait_on_busy,
> cd->irqs_processed);
> diff --git a/drivers/net/hippi/rrunner.c b/drivers/net/hippi/rrunner.c
> index 029206e4da3b..0f7025f3a384 100644
> --- a/drivers/net/hippi/rrunner.c
> +++ b/drivers/net/hippi/rrunner.c
> @@ -1298,11 +1298,11 @@ static void rr_dump(struct net_device *dev)
> if (rrpriv->tx_skbuff[cons]){
> len = min_t(int, 0x80, rrpriv->tx_skbuff[cons]->len);
> printk("skbuff for cons %i is valid - dumping data (0x%x bytes
> - skbuff len 0x%x)\n", cons, len, rrpriv->tx_skbuff[cons]->len);
> - printk("mode 0x%x, size 0x%x,\n phys %08Lx, skbuff-addr %08lx,
> truesize 0x%x\n",
> + printk("mode 0x%x, size 0x%x,\n phys %08Lx, skbuff-addr %p,
> truesize 0x%x\n",
> rrpriv->tx_ring[cons].mode,
> rrpriv->tx_ring[cons].size,
> (unsigned long long) rrpriv->tx_ring[cons].addr.addrlo,
> -(unsigned long)rrpriv->tx_skbuff[cons]->data,
> +rrpriv->tx_skbuff[cons]->data,
> (unsigned
Re: [PATCH v20 00/28] Intel SGX1 support
On Sat, Apr 20, 2019 at 07:42:13AM +0200, Thomas Gleixner wrote: Good morning/weekend to everyone. > On Fri, 19 Apr 2019, Jethro Beekman wrote: > > On 2019-04-19 14:34, Thomas Gleixner wrote: > > > And how so? You create writeable AND executable memory. That's a nono and > > > you can argue in circles, that's not going to change with any of your > > > proposed changes. > > On 2019-04-19 14:38, Thomas Gleixner wrote: > > > You are working around LSM nothing else and that's just not going to fly. > > > > Based on your comments, I'm still unsure if we're on the same page with > > regards to what I'm proposing. > > > > Here's a regular non-SGX flow that LSM would likely prevent: > > > > mmap(PROT_READ|PROT_WRITE) > > memcpy() > > mmap(PROT_READ|PROT_EXEC) <-- denied by LSM > > > > Or just something based on regular PT permissions: > > > > mmap(PROT_READ|PROT_EXEC) > > memcpy() <-- SIGSEGV > > > > Now, the equivalent for SGX: > > > > mmap(PROT_READ|PROT_WRITE) > > ioctl(EADD) > > mmap(PROT_READ|PROT_EXEC) <-- denied by LSM > This is completely irrelevant, really. > > The point is that the SGX driver loads and executes arbitrary data > which is handed in from user space via an ioctl w/o any chance of > verifying where that comes from. > > What Andy proposed is to open a file with the SGX payload and hand > in the file descriptor. That way LSM can decide whether this is > allowed or denied based on the file descriptor and whatever the > security model/policy is in a particular setup. > > Right know the SGX driver and its proposed API prevent any form of > LSM auditing and whatever permission checks you had in mind won't > change that at all. I don't even want to remotely get in the middle of this arguement, since we are probably already persona-non-grata for having stimulated a discussion that has slowed upstreaming, but some comments to assist and clarify further progress on the driver. We understand and support the need for the LSM to trap these events, but what does LSM provenance mean if the platform is compromised? That is, technically, the target application for SGX technology. This issue is what drove our concern for having ring-0 based enforcement of who can initialize an enclave. As Andy has pointed out, the mmap semantics of the SGX driver allow the introduction of executable code that bypasses LSM enforcement, but the platform owner, with appropriate enforcements on an FLC platform, has cryptographic verification and trust for the origin and provenance of that executable code. It may be possible to load the executable code into enclave memory but the processor will refuse to access the memory until the EINIT instruction validates that the loaded code is compliant with the enclave metadata and measurement. That is why we were argueing for, simple, ring-0 based verification of the key signature that authorizes the EINIT instruction to complete. >From a more practical perspective, an enclave shared image is a rather complex beast, that contains a lot of metadata. An application has to open the shared image file and parse the metadata in order to properly construct the enclave image from the text in the image file. I believe in practice that will effectively activate LSM recognition of the executable code. That obviously leaves a cunning adversary an opportunity to teleport a simple binary file or network stream onto a platform and load and execute the contents. But that takes us back to the need for ring-0 enforcement of enclave initialization... :-) We wrote a major enhancement to the Linux IMA architecture to implement introspection of behavioral namespaces. The actor/subject events get forwarded up into a modeling engine running inside of a namespace specific SGX enclave instance that issues a system call to instruct an LSM that we wrote, and that pairs with the IMA extension, to 'discipline' the process if it is acting outside its behavioral specification. We will verify with Jarkko's current HEAD, but I believe it is consistently trapping access to the shared image file and hence the text of the enclave. > Thanks, > > tglx Have a good weekend. Dr. Greg As always, Dr. G.W. Wettstein, Ph.D. Enjellic Systems Development, LLC. 4206 N. 19th Ave. Specializing in information infra-structure Fargo, ND 58102development. PH: 701-281-1686 FAX: 701-281-3949 EMAIL: g...@enjellic.com -- "Simplicity is prerequisite for reliability." -- Edsger W. Dijkstra
Re: RFC: on adding new CLONE_* flags [WAS Re: [PATCH 0/4] clone: add CLONE_PIDFD]
On Mon, Apr 15, 2019 at 01:29:23PM -0700, Andy Lutomirski wrote: > Anyway, clone(2) is an enormous mess. Surely the right solution here > is to have a whole new process creation API that takes a big, > extensible struct as an argument, and supports *at least* the full > abilities of posix_spawn() and ideally covers all the use cases for > fork() + do stuff + exec(). It would be nifty if this API also had a > way to say "add no_new_privs and therefore enable extra functionality > that doesn't work without no_new_privs". This functionality would > include things like returning a future extra-privileged pidfd that > gives ptrace-like access. You had been two weeks too late with that, and a bit too obvious with the use of "surely" too close to the beginning... If it was _not_ a belated AFD posting, alt.tasteless is over -> that way...
Re: RFC: on adding new CLONE_* flags [WAS Re: [PATCH 0/4] clone: add CLONE_PIDFD]
On Sat, Apr 20, 2019 at 12:14 AM Kevin Easton wrote: > On Mon, Apr 15, 2019 at 01:29:23PM -0700, Andy Lutomirski wrote: > > On Mon, Apr 15, 2019 at 12:59 PM Aleksa Sarai wrote: > > > > > > On 2019-04-15, Enrico Weigelt, metux IT consult wrote: > > > > > This patchset makes it possible to retrieve pid file descriptors at > > > > > process creation time by introducing the new flag CLONE_PIDFD to the > > > > > clone() system call as previously discussed. > > > > > > > > Sorry, for highjacking this thread, but I'm curious on what things to > > > > consider when introducing new CLONE_* flags. > > > > > > > > The reason I'm asking is: > > > > > > > > I'm working on implementing plan9-like fs namespaces, where unprivileged > > > > processes can change their own namespace at will. For that, certain > > > > traditional unix'ish things have to be disabled, most notably suid. > > > > As forbidding suid can be helpful in other scenarios, too, I thought > > > > about making this its own feature. Doing that switch on clone() seems > > > > a nice place for that, IMHO. > > > > > > Just spit-balling -- is no_new_privs not sufficient for this usecase? > > > Not granting privileges such as setuid during execve(2) is the main > > > point of that flag. > > > > > > > I would personally *love* it if distros started setting no_new_privs > > for basically all processes. And pidfd actually gets us part of the > > way toward a straightforward way to make sudo and su still work in a > > no_new_privs world: su could call into a daemon that would spawn the > > privileged task, and su would get a (read-only!) pidfd back and then > > wait for the fd and exit. I suppose that, done naively, this might > > cause some odd effects with respect to tty handling, but I bet it's > > solveable. I suppose it would be nifty if there were a way for a > > process, by mutual agreement, to reparent itself to an unrelated > > process. > > > > Anyway, clone(2) is an enormous mess. Surely the right solution here > > is to have a whole new process creation API that takes a big, > > extensible struct as an argument, and supports *at least* the full > > abilities of posix_spawn() and ideally covers all the use cases for > > fork() + do stuff + exec(). It would be nifty if this API also had a > > way to say "add no_new_privs and therefore enable extra functionality > > that doesn't work without no_new_privs". This functionality would > > include things like returning a future extra-privileged pidfd that > > gives ptrace-like access. > > > > As basic examples, the improved process creation API should take a > > list of dup2() operations to perform, fds to remove the O_CLOEXEC flag > > from, fds to close (or, maybe even better, a list of fds to *not* > > close), a list of rlimit changes to make, a list of signal changes to > > make, the ability to set sid, pgrp, uid, gid (as in > > setresuid/setresgid), the ability to do capset() operations, etc. The > > posix_spawn() API, for all that it's rather complicated, covers a > > bunch of the basics pretty well. > > The idea of a system call that takes an infinitely-extendable laundry > list of operations to perform in kernel space seems quite inelegant, if > only for the error-reporting reason. > > Instead, I suggest that what you'd want is a way to create a new > embryonic process that has no address space and isn't yet schedulable. > You then just need other-process-directed variants of all the normal > setup functions - so pr_openat(pidfd, dirfd, pathname, flags, mode), > pr_sigaction(pidfd, signum, act, oldact), pr_dup2(pidfd, oldfd, newfd) > etc. Providing process-directed versions of these functions would be useful for a variety of management tasks anyway, > Then when it's all set up you pr_execve() to kick it off. Yes. That's the right general approach.
[PATCH] arm64: dts: allwinner: h6: Enable HDMI output on orangepi 3
Orangepi 3 has HDMI type A connector.
Signed-off-by: Yangtao Li
---
rebase:
sunxi/dt64-for-5.2 arm64: dts: allwinner: a64-amarula-relic: Add OV5640
camera node
---
.../dts/allwinner/sun50i-h6-orangepi-3.dts| 25 +++
1 file changed, 25 insertions(+)
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-3.dts
b/arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-3.dts
index 17d496990108..6ed3a1ee297d 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-3.dts
+++ b/arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-3.dts
@@ -21,6 +21,17 @@
stdout-path = "serial0:115200n8";
};
+ connector {
+ compatible = "hdmi-connector";
+ type = "a";
+
+ port {
+ hdmi_con_in: endpoint {
+ remote-endpoint = <_out_con>;
+ };
+ };
+ };
+
leds {
compatible = "gpio-leds";
@@ -50,6 +61,10 @@
cpu-supply = <_dcdca>;
};
+ {
+ status = "okay";
+};
+
{
status = "okay";
};
@@ -58,6 +73,16 @@
status = "okay";
};
+ {
+ status = "okay";
+};
+
+_out {
+ hdmi_out_con: endpoint {
+ remote-endpoint = <_con_in>;
+ };
+};
+
{
vmmc-supply = <_cldo1>;
cd-gpios = < 5 6 GPIO_ACTIVE_LOW>; /* PF6 */
--
2.17.0
Re: Adding plain accesses and detecting data races in the LKMM
On Fri, 19 Apr 2019 11:06:41 -0700, Paul E. McKenney wrote:
> On Sat, Apr 20, 2019 at 12:06:58AM +0900, Akira Yokosawa wrote:
>> Hi Paul,
>>
[...]
>
>>> + (1) The compiler can reorder the load from a to precede the
>>> + atomic_dec(), (2) Because x86 smp_mb__before_atomic() is only a
>>> + compiler barrier, the CPU can reorder the preceding store to
>>> + obj->dead with the later load from a.
>>> +
>>> + This could be avoided by using READ_ONCE(), which would prevent the
>>> + compiler from reordering due to both atomic_dec() and READ_ONCE()
>>> + being volatile accesses, and is usually preferable for loads from
>>> + shared variables. However, weakly ordered CPUs would still be
>>> + free to reorder the atomic_dec() with the load from a, so a more
>>> + readable option is to also use smp_mb__after_atomic() as follows:
>>
>> The point here is not just "readability", but also the portability of the
>> code, isn't it?
>
> As Andrea noted, in this particular case, the guarantee that the
> store to obj->dead precedes the load from x is portable. Either the
> smp_mb__before_atomic() or the atomic_dec() must provide the ordering.
I think I understood this. What I wanted to say was the code for x86 implied
in the subjunctive sentence:
obj->dead = 1;
smp_mb__before_atomic();
atomic_dec(>ref_count);
r1 = READ_ONCE(x);
, which was not spelled out, is not portable if we expect the ordering of
atomic_dec() with READ_ONCE().
> However, you are right that there is some non-portability. But this
> non-portability involves the order of the atomic_dec() and the store to x.
Yes, you've guessed it right.
>
> So what I did was ...
>
>> Thanks, Akira
>>
>>> +
>>> + WRITE_ONCE(obj->dead, 1);
>>> + smp_mb__before_atomic();
>>> + atomic_dec(>ref_count);
>>> + smp_mb__after_atomic();
>>> + r1 = READ_ONCE(a);
>>> +
>>> + This orders all three accesses against each other, and also makes
>>> + the intent quite clear.
>
> ... change the above paragraph to read as follows:
>
> In addition, the example without the smp_mb__after_atomic() does
> not necessarily order the atomic_dec() with the load from x.
> In contrast, the example with both smp_mb__before_atomic() and
> smp_mb__after_atomic() orders all three accesses against each other,
> and also makes the intent quite clear.
>
> Does that help?
This looks a little bit redundant to me. The original one is clear
enough.
How about editing the leading sentence above:
>>> + shared variables. However, weakly ordered CPUs would still be
>>> + free to reorder the atomic_dec() with the load from a, so a more
>>> + readable option is to also use smp_mb__after_atomic() as follows:
to read as follows?
shared variables. However, weakly ordered CPUs would still be
free to reorder the atomic_dec() with the load from x, so a
portable and more readable option is to also use
smp_mb__after_atomic() as follows:
Obviously, the interesting discussion going on in another thread will
surely affect this patch.
Thanks, Akira
>
> Thanx, Paul
>
>>> See Documentation/atomic_{t,bitops}.txt for more information.
>>>
>>> diff --git a/tools/memory-model/linux-kernel.cat
>>> b/tools/memory-model/linux-kernel.cat
>>> index 8dcb37835b61..b6866f93abb8 100644
>>> --- a/tools/memory-model/linux-kernel.cat
>>> +++ b/tools/memory-model/linux-kernel.cat
>>> @@ -28,8 +28,8 @@ include "lock.cat"
>>> let rmb = [R \ Noreturn] ; fencerel(Rmb) ; [R \ Noreturn]
>>> let wmb = [W] ; fencerel(Wmb) ; [W]
>>> let mb = ([M] ; fencerel(Mb) ; [M]) |
>>> - ([M] ; fencerel(Before-atomic) ; [RMW] ; po? ; [M]) |
>>> - ([M] ; po? ; [RMW] ; fencerel(After-atomic) ; [M]) |
>>> + ([M] ; fencerel(Before-atomic) ; [RMW]) |
>>> + ([RMW] ; fencerel(After-atomic) ; [M]) |
>>> ([M] ; po? ; [LKW] ; fencerel(After-spinlock) ; [M]) |
>>> ([M] ; po ; [UL] ; (co | po) ; [LKW] ;
>>> fencerel(After-unlock-lock) ; [M])
>>>
>>
>
Re: [PATCH 5.0 00/93] 5.0.9-stable review
On Sat, Apr 20, 2019 at 05:58:23PM +0530, Bharath Vedartham wrote: > Built and booted on my x86 machine. > Observed no dmesg regressions. Thanks for testing two of these and letting me know. greg k-h
Re: [PATCH 5.0 00/93] 5.0.9-stable review
On Sat, Apr 20, 2019 at 10:22:32AM +0530, Naresh Kamboju wrote: > On Thu, 18 Apr 2019 at 23:40, Greg Kroah-Hartman > wrote: > > > > This is the start of the stable review cycle for the 5.0.9 release. > > There are 93 patches in this series, all will be posted as a response > > to this one. If anyone has any issues with these being applied, please > > let me know. > > > > Responses should be made by Sat Apr 20 16:03:33 UTC 2019. > > Anything received after that time might be too late. > > > > The whole patch series can be found in one patch at: > > > > https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.0.9-rc1.gz > > or in the git tree and branch at: > > > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > > linux-5.0.y > > and the diffstat can be found below. > > > > thanks, > > > > greg k-h > > > > Results from Linaro’s test farm. > No regressions on arm64, arm, x86_64, and i386. Thanks for testing these and letting me know. greg k-h
Re: [PATCH 5.0 00/93] 5.0.9-stable review
On Fri, Apr 19, 2019 at 11:08:50AM +0100, Jon Hunter wrote: > > On 18/04/2019 18:56, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 5.0.9 release. > > There are 93 patches in this series, all will be posted as a response > > to this one. If anyone has any issues with these being applied, please > > let me know. > > > > Responses should be made by Sat Apr 20 16:03:33 UTC 2019. > > Anything received after that time might be too late. > > > > The whole patch series can be found in one patch at: > > > > https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.0.9-rc1.gz > > or in the git tree and branch at: > > > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > > linux-5.0.y > > and the diffstat can be found below. > > > > thanks, > > > > greg k-h > > All tests are passing for Tegra ... > > Test results for stable-v5.0: > 11 builds: 11 pass, 0 fail > 22 boots: 22 pass, 0 fail > 32 tests: 32 pass, 0 fail > > Linux version: 5.0.9-rc1-g68497c6 > Boards tested: tegra124-jetson-tk1, tegra186-p2771-, > tegra194-p2972-, tegra20-ventana, > tegra210-p2371-2180, tegra30-cardhu-a04 Thanks for testing all of these and letting me know. greg k-h
Linux 5.0.9
I'm announcing the release of the 5.0.9 kernel. All users of the 5.0 kernel series must upgrade. The updated 5.0.y git tree can be found at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-5.0.y and can be browsed at the normal kernel.org git web browser: http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary thanks, greg k-h Makefile|2 arch/arc/configs/hsdk_defconfig |1 arch/arc/kernel/head.S |1 arch/arc/kernel/setup.c |8 + arch/arm/kernel/patch.c |6 arch/mips/bcm47xx/workarounds.c |1 arch/x86/hyperv/hv_init.c |6 arch/x86/kernel/aperture_64.c | 20 +- arch/x86/kernel/cpu/cyrix.c | 14 +- arch/x86/kernel/hpet.c |2 arch/x86/kernel/hw_breakpoint.c |1 arch/x86/kernel/mpparse.c |4 block/blk-iolatency.c |1 drivers/acpi/ec.c | 53 +++ drivers/acpi/utils.c|1 drivers/auxdisplay/hd44780.c|2 drivers/base/power/domain.c | 13 - drivers/block/paride/pcd.c | 20 ++ drivers/block/paride/pf.c | 26 +++ drivers/crypto/axis/artpec6_crypto.c| 28 +++- drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c |2 drivers/gpu/drm/amd/amdkfd/kfd_mqd_manager_cik.c| 52 --- drivers/gpu/drm/exynos/exynos_mixer.c | 110 +--- drivers/gpu/drm/nouveau/include/nvkm/subdev/volt.h |1 drivers/gpu/drm/nouveau/nouveau_debugfs.c |2 drivers/gpu/drm/nouveau/nvkm/engine/device/base.c |2 drivers/gpu/drm/nouveau/nvkm/subdev/volt/Kbuild |1 drivers/gpu/drm/nouveau/nvkm/subdev/volt/gf117.c| 60 drivers/gpu/drm/panel/panel-innolux-p079zca.c | 11 - drivers/gpu/drm/udl/udl_gem.c |2 drivers/hwtracing/coresight/coresight-cpu-debug.c |4 drivers/infiniband/hw/hfi1/qp.c |2 drivers/infiniband/hw/hns/hns_roce_device.h | 21 +++ drivers/infiniband/hw/hns/hns_roce_hw_v2.c | 103 +- drivers/infiniband/hw/hns/hns_roce_hw_v2.h |1 drivers/infiniband/hw/i40iw/i40iw_utils.c | 12 + drivers/infiniband/hw/mlx4/alias_GUID.c |2 drivers/iommu/intel-iommu.c |5 drivers/irqchip/irq-mbigen.c|3 drivers/irqchip/irq-stm32-exti.c| 10 - drivers/misc/lkdtm/core.c |2 drivers/misc/lkdtm/lkdtm.h |2 drivers/misc/lkdtm/perms.c | 36 +++-- drivers/mmc/host/davinci_mmc.c |2 drivers/net/ethernet/hisilicon/hns3/hnae3.h |2 drivers/net/ethernet/hisilicon/hns3/hns3_enet.c | 28 drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c | 20 -- drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_mdio.c |8 - drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_mdio.h |4 drivers/pci/pci.c | 75 ++ drivers/platform/x86/intel_pmc_core.c | 34 drivers/platform/x86/intel_pmc_core.h |5 drivers/scsi/qla2xxx/qla_os.c |2 drivers/scsi/scsi_lib.c |9 + drivers/scsi/scsi_transport_iscsi.c |2 drivers/thermal/broadcom/bcm2835_thermal.c |9 - drivers/thermal/intel/int340x_thermal/int3400_thermal.c | 21 ++- drivers/thermal/intel/intel_powerclamp.c|4 drivers/thermal/samsung/exynos_tmu.c|2 fs/cifs/cifsfs.c|2 fs/cifs/smb2maperror.c |3 fs/cifs/smb2ops.c | 10 + fs/cifs/trace.h |6 fs/ext4/ioctl.c |7 + fs/ext4/resize.c| 17 ++ fs/ext4/super.c | 16 +- fs/f2fs/checkpoint.c|9 - fs/f2fs/data.c | 21 +-- fs/f2fs/dir.c
Re: Linux 5.0.9
diff --git a/Makefile b/Makefile
index f7666051de66..ef192ca04330 100644
--- a/Makefile
+++ b/Makefile
@@ -1,7 +1,7 @@
# SPDX-License-Identifier: GPL-2.0
VERSION = 5
PATCHLEVEL = 0
-SUBLEVEL = 8
+SUBLEVEL = 9
EXTRAVERSION =
NAME = Shy Crocodile
diff --git a/arch/arc/configs/hsdk_defconfig b/arch/arc/configs/hsdk_defconfig
index 87b23b7fb781..aefcf7a4e17a 100644
--- a/arch/arc/configs/hsdk_defconfig
+++ b/arch/arc/configs/hsdk_defconfig
@@ -8,6 +8,7 @@ CONFIG_NAMESPACES=y
# CONFIG_UTS_NS is not set
# CONFIG_PID_NS is not set
CONFIG_BLK_DEV_INITRD=y
+CONFIG_BLK_DEV_RAM=y
CONFIG_EMBEDDED=y
CONFIG_PERF_EVENTS=y
# CONFIG_VM_EVENT_COUNTERS is not set
diff --git a/arch/arc/kernel/head.S b/arch/arc/kernel/head.S
index 30e090625916..a72bbda2f7aa 100644
--- a/arch/arc/kernel/head.S
+++ b/arch/arc/kernel/head.S
@@ -106,6 +106,7 @@ ENTRY(stext)
;r2 = pointer to uboot provided cmdline or external DTB in mem
; These are handled later in handle_uboot_args()
st r0, [@uboot_tag]
+ st r1, [@uboot_magic]
st r2, [@uboot_arg]
; setup "current" tsk and optionally cache it in dedicated r25
diff --git a/arch/arc/kernel/setup.c b/arch/arc/kernel/setup.c
index 7b2340996cf8..7b3a7b3b380c 100644
--- a/arch/arc/kernel/setup.c
+++ b/arch/arc/kernel/setup.c
@@ -36,6 +36,7 @@ unsigned int intr_to_DE_cnt;
/* Part of U-boot ABI: see head.S */
int __initdata uboot_tag;
+int __initdata uboot_magic;
char __initdata *uboot_arg;
const struct machine_desc *machine_desc;
@@ -497,6 +498,8 @@ static inline bool uboot_arg_invalid(unsigned long addr)
#define UBOOT_TAG_NONE 0
#define UBOOT_TAG_CMDLINE 1
#define UBOOT_TAG_DTB 2
+/* We always pass 0 as magic from U-boot */
+#define UBOOT_MAGIC_VALUE 0
void __init handle_uboot_args(void)
{
@@ -511,6 +514,11 @@ void __init handle_uboot_args(void)
goto ignore_uboot_args;
}
+ if (uboot_magic != UBOOT_MAGIC_VALUE) {
+ pr_warn(IGNORE_ARGS "non zero uboot magic\n");
+ goto ignore_uboot_args;
+ }
+
if (uboot_tag != UBOOT_TAG_NONE &&
uboot_arg_invalid((unsigned long)uboot_arg)) {
pr_warn(IGNORE_ARGS "invalid uboot arg: '%px'\n", uboot_arg);
diff --git a/arch/arm/kernel/patch.c b/arch/arm/kernel/patch.c
index a50dc00d79a2..d0a05a3bdb96 100644
--- a/arch/arm/kernel/patch.c
+++ b/arch/arm/kernel/patch.c
@@ -16,7 +16,7 @@ struct patch {
unsigned int insn;
};
-static DEFINE_SPINLOCK(patch_lock);
+static DEFINE_RAW_SPINLOCK(patch_lock);
static void __kprobes *patch_map(void *addr, int fixmap, unsigned long *flags)
__acquires(_lock)
@@ -33,7 +33,7 @@ static void __kprobes *patch_map(void *addr, int fixmap,
unsigned long *flags)
return addr;
if (flags)
- spin_lock_irqsave(_lock, *flags);
+ raw_spin_lock_irqsave(_lock, *flags);
else
__acquire(_lock);
@@ -48,7 +48,7 @@ static void __kprobes patch_unmap(int fixmap, unsigned long
*flags)
clear_fixmap(fixmap);
if (flags)
- spin_unlock_irqrestore(_lock, *flags);
+ raw_spin_unlock_irqrestore(_lock, *flags);
else
__release(_lock);
}
diff --git a/arch/mips/bcm47xx/workarounds.c b/arch/mips/bcm47xx/workarounds.c
index 46eddbec8d9f..0ab95dd431b3 100644
--- a/arch/mips/bcm47xx/workarounds.c
+++ b/arch/mips/bcm47xx/workarounds.c
@@ -24,6 +24,7 @@ void __init bcm47xx_workarounds(void)
case BCM47XX_BOARD_NETGEAR_WNR3500L:
bcm47xx_workarounds_enable_usb_power(12);
break;
+ case BCM47XX_BOARD_NETGEAR_WNDR3400V2:
case BCM47XX_BOARD_NETGEAR_WNDR3400_V3:
bcm47xx_workarounds_enable_usb_power(21);
break;
diff --git a/arch/x86/hyperv/hv_init.c b/arch/x86/hyperv/hv_init.c
index d3f42b6bbdac..8a9cff1f129d 100644
--- a/arch/x86/hyperv/hv_init.c
+++ b/arch/x86/hyperv/hv_init.c
@@ -102,9 +102,13 @@ static int hv_cpu_init(unsigned int cpu)
u64 msr_vp_index;
struct hv_vp_assist_page **hvp = _vp_assist_page[smp_processor_id()];
void **input_arg;
+ struct page *pg;
input_arg = (void **)this_cpu_ptr(hyperv_pcpu_input_arg);
- *input_arg = page_address(alloc_page(GFP_KERNEL));
+ pg = alloc_page(GFP_KERNEL);
+ if (unlikely(!pg))
+ return -ENOMEM;
+ *input_arg = page_address(pg);
hv_get_vp_index(msr_vp_index);
diff --git a/arch/x86/kernel/aperture_64.c b/arch/x86/kernel/aperture_64.c
index 58176b56354e..294ed4392a0e 100644
--- a/arch/x86/kernel/aperture_64.c
+++ b/arch/x86/kernel/aperture_64.c
@@ -14,6 +14,7 @@
#define pr_fmt(fmt) "AGP: " fmt
#include
+#include
#include
#include
#include
@@ -57,7 +58,7 @@ int fallback_aper_force __initdata;
int fix_aperture __initdata = 1;
-#ifdef CONFIG_PROC_VMCORE
+#if
Linux 4.19.36
I'm announcing the release of the 4.19.36 kernel. All users of the 4.19 kernel series must upgrade. The updated 4.19.y git tree can be found at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-4.19.y and can be browsed at the normal kernel.org git web browser: http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary thanks, greg k-h MAINTAINERS|6 Makefile |2 arch/arc/configs/hsdk_defconfig|1 arch/arc/kernel/head.S |1 arch/arc/kernel/setup.c|8 arch/arm/crypto/sha256-armv4.pl|3 arch/arm/crypto/sha256-core.S_shipped |3 arch/arm/crypto/sha512-armv4.pl|3 arch/arm/crypto/sha512-core.S_shipped |3 arch/arm/kernel/patch.c|6 arch/arm/plat-samsung/Kconfig |2 arch/powerpc/kernel/rtasd.c| 17 arch/x86/hyperv/hv_init.c |6 arch/x86/kernel/aperture_64.c | 20 arch/x86/kernel/cpu/cyrix.c| 14 arch/x86/kernel/hpet.c |2 arch/x86/kernel/hw_breakpoint.c|1 arch/x86/kernel/mpparse.c |4 arch/x86/kvm/vmx.c | 173 ++ block/blk-iolatency.c |1 drivers/acpi/ec.c | 65 + drivers/acpi/internal.h|2 drivers/acpi/sbs.c |8 drivers/acpi/sleep.c | 11 drivers/acpi/utils.c |1 drivers/auxdisplay/hd44780.c |2 drivers/base/node.c|7 drivers/base/power/domain.c| 13 drivers/crypto/axis/artpec6_crypto.c | 28 drivers/gpio/gpio-pxa.c|6 drivers/gpu/drm/amd/amdkfd/kfd_mqd_manager_cik.c | 52 drivers/gpu/drm/cirrus/cirrus_drv.h|2 drivers/gpu/drm/cirrus/cirrus_fbdev.c | 48 drivers/gpu/drm/cirrus/cirrus_mode.c |2 drivers/gpu/drm/exynos/exynos_mixer.c | 110 + drivers/gpu/drm/nouveau/include/nvkm/subdev/volt.h |1 drivers/gpu/drm/nouveau/nouveau_debugfs.c |2 drivers/gpu/drm/nouveau/nvkm/engine/device/base.c |2 drivers/gpu/drm/nouveau/nvkm/subdev/volt/Kbuild|1 drivers/gpu/drm/nouveau/nvkm/subdev/volt/gf117.c | 60 drivers/gpu/drm/panel/panel-innolux-p079zca.c | 11 drivers/gpu/drm/ttm/ttm_bo.c |1 drivers/gpu/drm/ttm/ttm_memory.c |9 drivers/gpu/drm/udl/udl_gem.c |2 drivers/hid/hid-ids.h |1 drivers/hid/hid-quirks.c |1 drivers/hid/i2c-hid/Makefile |3 drivers/hid/i2c-hid/i2c-hid-core.c | 1348 + drivers/hid/i2c-hid/i2c-hid-dmi-quirks.c | 376 + drivers/hid/i2c-hid/i2c-hid.c | 1328 drivers/hid/i2c-hid/i2c-hid.h | 20 drivers/hwtracing/coresight/coresight-cpu-debug.c |4 drivers/infiniband/hw/hfi1/qp.c|2 drivers/infiniband/hw/i40iw/i40iw_utils.c | 12 drivers/infiniband/hw/mlx4/alias_GUID.c|2 drivers/iommu/dmar.c |2 drivers/iommu/intel-iommu.c|3 drivers/irqchip/irq-mbigen.c |3 drivers/irqchip/irq-stm32-exti.c |5 drivers/media/usb/au0828/au0828-core.c |1 drivers/misc/lkdtm/core.c |2 drivers/misc/lkdtm/lkdtm.h |2 drivers/misc/lkdtm/perms.c | 36 drivers/mmc/host/davinci_mmc.c |2 drivers/net/ethernet/stmicro/stmmac/ring_mode.c|4 drivers/net/wireless/rsi/rsi_common.h |1 drivers/pci/pci.c | 22 drivers/pinctrl/core.c |4 drivers/platform/x86/Kconfig | 12 drivers/platform/x86/Makefile |1 drivers/platform/x86/intel_atomisp2_pm.c | 119 + drivers/scsi/scsi_lib.c|1 drivers/scsi/scsi_transport_iscsi.c|2 drivers/soc/tegra/pmc.c|8 drivers/thermal/broadcom/bcm2835_thermal.c |9
Re: Linux 4.9.170
diff --git a/Makefile b/Makefile
index 23cc23c47adf..966069dab768 100644
--- a/Makefile
+++ b/Makefile
@@ -1,6 +1,6 @@
VERSION = 4
PATCHLEVEL = 9
-SUBLEVEL = 169
+SUBLEVEL = 170
EXTRAVERSION =
NAME = Roaring Lionus
diff --git a/arch/arc/kernel/head.S b/arch/arc/kernel/head.S
index 1f945d0f40da..208bf2c9e7b0 100644
--- a/arch/arc/kernel/head.S
+++ b/arch/arc/kernel/head.S
@@ -107,6 +107,7 @@ ENTRY(stext)
;r2 = pointer to uboot provided cmdline or external DTB in mem
; These are handled later in handle_uboot_args()
st r0, [@uboot_tag]
+ st r1, [@uboot_magic]
st r2, [@uboot_arg]
#endif
diff --git a/arch/arc/kernel/setup.c b/arch/arc/kernel/setup.c
index 9119bea503a7..9f96120eee6e 100644
--- a/arch/arc/kernel/setup.c
+++ b/arch/arc/kernel/setup.c
@@ -32,6 +32,7 @@ unsigned int intr_to_DE_cnt;
/* Part of U-boot ABI: see head.S */
int __initdata uboot_tag;
+int __initdata uboot_magic;
char __initdata *uboot_arg;
const struct machine_desc *machine_desc;
@@ -400,6 +401,8 @@ static inline bool uboot_arg_invalid(unsigned long addr)
#define UBOOT_TAG_NONE 0
#define UBOOT_TAG_CMDLINE 1
#define UBOOT_TAG_DTB 2
+/* We always pass 0 as magic from U-boot */
+#define UBOOT_MAGIC_VALUE 0
void __init handle_uboot_args(void)
{
@@ -415,6 +418,11 @@ void __init handle_uboot_args(void)
goto ignore_uboot_args;
}
+ if (uboot_magic != UBOOT_MAGIC_VALUE) {
+ pr_warn(IGNORE_ARGS "non zero uboot magic\n");
+ goto ignore_uboot_args;
+ }
+
if (uboot_tag != UBOOT_TAG_NONE &&
uboot_arg_invalid((unsigned long)uboot_arg)) {
pr_warn(IGNORE_ARGS "invalid uboot arg: '%px'\n", uboot_arg);
diff --git a/arch/arm/crypto/sha256-armv4.pl b/arch/arm/crypto/sha256-armv4.pl
index fac0533ea633..f64e8413ab9a 100644
--- a/arch/arm/crypto/sha256-armv4.pl
+++ b/arch/arm/crypto/sha256-armv4.pl
@@ -205,10 +205,11 @@ K256:
.globalsha256_block_data_order
.type sha256_block_data_order,%function
sha256_block_data_order:
+.Lsha256_block_data_order:
#if __ARM_ARCH__<7
sub r3,pc,#8@ sha256_block_data_order
#else
- adr r3,sha256_block_data_order
+ adr r3,.Lsha256_block_data_order
#endif
#if __ARM_MAX_ARCH__>=7 && !defined(__KERNEL__)
ldr r12,.LOPENSSL_armcap
diff --git a/arch/arm/crypto/sha256-core.S_shipped
b/arch/arm/crypto/sha256-core.S_shipped
index 555a1a8eec90..72c248081d27 100644
--- a/arch/arm/crypto/sha256-core.S_shipped
+++ b/arch/arm/crypto/sha256-core.S_shipped
@@ -86,10 +86,11 @@ K256:
.globalsha256_block_data_order
.type sha256_block_data_order,%function
sha256_block_data_order:
+.Lsha256_block_data_order:
#if __ARM_ARCH__<7
sub r3,pc,#8@ sha256_block_data_order
#else
- adr r3,sha256_block_data_order
+ adr r3,.Lsha256_block_data_order
#endif
#if __ARM_MAX_ARCH__>=7 && !defined(__KERNEL__)
ldr r12,.LOPENSSL_armcap
diff --git a/arch/arm/crypto/sha512-armv4.pl b/arch/arm/crypto/sha512-armv4.pl
index a2b11a844357..5fe336420bcf 100644
--- a/arch/arm/crypto/sha512-armv4.pl
+++ b/arch/arm/crypto/sha512-armv4.pl
@@ -267,10 +267,11 @@ WORD64(0x5fcb6fab,0x3ad6faec, 0x6c44198c,0x4a475817)
.globalsha512_block_data_order
.type sha512_block_data_order,%function
sha512_block_data_order:
+.Lsha512_block_data_order:
#if __ARM_ARCH__<7
sub r3,pc,#8@ sha512_block_data_order
#else
- adr r3,sha512_block_data_order
+ adr r3,.Lsha512_block_data_order
#endif
#if __ARM_MAX_ARCH__>=7 && !defined(__KERNEL__)
ldr r12,.LOPENSSL_armcap
diff --git a/arch/arm/crypto/sha512-core.S_shipped
b/arch/arm/crypto/sha512-core.S_shipped
index 3694c4d4ca2b..de9bd7f55242 100644
--- a/arch/arm/crypto/sha512-core.S_shipped
+++ b/arch/arm/crypto/sha512-core.S_shipped
@@ -134,10 +134,11 @@ WORD64(0x5fcb6fab,0x3ad6faec, 0x6c44198c,0x4a475817)
.globalsha512_block_data_order
.type sha512_block_data_order,%function
sha512_block_data_order:
+.Lsha512_block_data_order:
#if __ARM_ARCH__<7
sub r3,pc,#8@ sha512_block_data_order
#else
- adr r3,sha512_block_data_order
+ adr r3,.Lsha512_block_data_order
#endif
#if __ARM_MAX_ARCH__>=7 && !defined(__KERNEL__)
ldr r12,.LOPENSSL_armcap
diff --git a/arch/arm/kernel/patch.c b/arch/arm/kernel/patch.c
index 69bda1a5707e..1f665acaa6a9 100644
--- a/arch/arm/kernel/patch.c
+++ b/arch/arm/kernel/patch.c
@@ -15,7 +15,7 @@ struct patch {
unsigned int insn;
};
-static DEFINE_SPINLOCK(patch_lock);
+static DEFINE_RAW_SPINLOCK(patch_lock);
static void __kprobes *patch_map(void *addr, int fixmap, unsigned long *flags)
__acquires(_lock)
@@ -32,7 +32,7 @@ static void __kprobes *patch_map(void *addr, int fixmap,
unsigned long *flags)
Linux 4.9.170
I'm announcing the release of the 4.9.170 kernel. All users of the 4.9 kernel series must upgrade. The updated 4.9.y git tree can be found at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-4.9.y and can be browsed at the normal kernel.org git web browser: http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary thanks, greg k-h Makefile |2 arch/arc/kernel/head.S|1 arch/arc/kernel/setup.c |8 arch/arm/crypto/sha256-armv4.pl |3 arch/arm/crypto/sha256-core.S_shipped |3 arch/arm/crypto/sha512-armv4.pl |3 arch/arm/crypto/sha512-core.S_shipped |3 arch/arm/kernel/patch.c |6 arch/arm/plat-samsung/Kconfig |2 arch/x86/kernel/cpu/cyrix.c | 14 arch/x86/kernel/hpet.c|2 arch/x86/kernel/hw_breakpoint.c |1 drivers/acpi/sbs.c|8 drivers/char/tpm/tpm_crb.c| 22 drivers/gpio/gpio-pxa.c |6 drivers/hid/i2c-hid/Makefile |3 drivers/hid/i2c-hid/i2c-hid-core.c| 1359 ++ drivers/hid/i2c-hid/i2c-hid-dmi-quirks.c | 376 ++ drivers/hid/i2c-hid/i2c-hid.c | 1339 - drivers/hid/i2c-hid/i2c-hid.h | 20 drivers/infiniband/hw/mlx4/alias_GUID.c |2 drivers/iommu/dmar.c |2 drivers/iommu/intel-iommu.c |3 drivers/irqchip/irq-mbigen.c |3 drivers/misc/lkdtm.h |2 drivers/misc/lkdtm_core.c |2 drivers/misc/lkdtm_perms.c| 18 drivers/mmc/host/davinci_mmc.c|2 drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 10 drivers/net/wireless/rsi/rsi_common.h |1 drivers/soc/tegra/pmc.c |8 drivers/thermal/int340x_thermal/int3400_thermal.c | 21 drivers/tty/serial/xilinx_uartps.c|2 fs/9p/v9fs.c | 21 fs/9p/v9fs.h |1 fs/9p/vfs_dir.c |8 fs/9p/vfs_file.c |6 fs/cifs/inode.c | 67 - fs/cifs/smb2maperror.c|3 fs/ext4/ioctl.c |7 fs/ext4/resize.c | 17 fs/f2fs/super.c | 34 include/linux/atalk.h | 20 include/linux/swap.h |4 kernel/events/core.c |2 kernel/hung_task.c| 30 lib/div64.c |4 net/9p/protocol.c |3 net/appletalk/atalk_proc.c|2 net/appletalk/ddp.c | 37 net/appletalk/sysctl_net_atalk.c |5 sound/drivers/opl3/opl3_voice.h |2 sound/isa/sb/sb8.c|4 sound/pci/echoaudio/echoaudio.c |5 tools/perf/Documentation/perf-config.txt |2 tools/perf/builtin-top.c |5 tools/perf/tests/evsel-tp-sched.c |1 tools/perf/tests/openat-syscall-all-cpus.c|4 tools/perf/util/build-id.c|1 tools/perf/util/config.c |3 tools/perf/util/evsel.c |1 tools/perf/util/hist.c|4 tools/perf/util/parse-events.c|1 tools/power/x86/turbostat/turbostat.c |3 64 files changed, 2112 insertions(+), 1452 deletions(-) Aditya Pakki (1): x86/hpet: Prevent potential NULL pointer dereference Ard Biesheuvel (2): crypto: sha256/arm - fix crash bug in Thumb2 build crypto: sha512/arm - fix crash bug in Thumb2 build Arnaldo Carvalho de Melo (1): perf evsel: Free evsel->counts in perf_evsel__exit() Arnd Bergmann (2): mmc: davinci: remove extraneous __init annotation appletalk: Fix compile regression Bartlomiej Zolnierkiewicz (1): ARM: samsung: Limit SAMSUNG_PM_CHECK config option to non-Exynos platforms Changbin Du (7): perf config: Fix an error in the config template documentation perf config: Fix a memory leak in collect_config() perf build-id:
Linux 4.14.113
I'm announcing the release of the 4.14.113 kernel. All users of the 4.14 kernel series must upgrade. The updated 4.14.y git tree can be found at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-4.14.y and can be browsed at the normal kernel.org git web browser: http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary thanks, greg k-h Makefile |2 arch/arc/configs/hsdk_defconfig|1 arch/arc/kernel/head.S |1 arch/arc/kernel/setup.c|8 arch/arm/crypto/sha256-armv4.pl|3 arch/arm/crypto/sha256-core.S_shipped |3 arch/arm/crypto/sha512-armv4.pl|3 arch/arm/crypto/sha512-core.S_shipped |3 arch/arm/kernel/patch.c|6 arch/arm/plat-samsung/Kconfig |2 arch/powerpc/kernel/rtasd.c| 17 arch/x86/kernel/cpu/cyrix.c| 14 arch/x86/kernel/hpet.c |2 arch/x86/kernel/hw_breakpoint.c|1 arch/x86/kernel/mpparse.c |4 arch/x86/kvm/vmx.c | 173 ++ drivers/acpi/ec.c | 53 drivers/acpi/sbs.c |8 drivers/auxdisplay/hd44780.c |2 drivers/base/node.c|7 drivers/crypto/axis/artpec6_crypto.c | 28 drivers/gpio/gpio-pxa.c|6 drivers/gpu/drm/amd/amdkfd/kfd_mqd_manager_cik.c | 52 drivers/gpu/drm/nouveau/include/nvkm/subdev/volt.h |1 drivers/gpu/drm/nouveau/nouveau_debugfs.c |2 drivers/gpu/drm/nouveau/nvkm/engine/device/base.c |2 drivers/gpu/drm/nouveau/nvkm/subdev/volt/Kbuild|1 drivers/gpu/drm/nouveau/nvkm/subdev/volt/gf117.c | 60 drivers/gpu/drm/panel/panel-innolux-p079zca.c | 11 drivers/hid/i2c-hid/Makefile |3 drivers/hid/i2c-hid/i2c-hid-core.c | 1299 + drivers/hid/i2c-hid/i2c-hid-dmi-quirks.c | 376 ++ drivers/hid/i2c-hid/i2c-hid.c | 1279 drivers/hid/i2c-hid/i2c-hid.h | 20 drivers/hwtracing/coresight/coresight-cpu-debug.c |4 drivers/infiniband/hw/mlx4/alias_GUID.c|2 drivers/iommu/dmar.c |2 drivers/iommu/intel-iommu.c|3 drivers/irqchip/irq-mbigen.c |3 drivers/md/dm-crypt.c | 10 drivers/md/dm-integrity.c |4 drivers/media/usb/au0828/au0828-core.c |1 drivers/misc/lkdtm.h |2 drivers/misc/lkdtm_core.c |2 drivers/misc/lkdtm_perms.c | 36 drivers/mmc/host/davinci_mmc.c |2 drivers/net/ethernet/netronome/nfp/bpf/verifier.c |9 drivers/net/ethernet/stmicro/stmmac/stmmac_main.c |6 drivers/net/wireless/rsi/rsi_common.h |1 drivers/scsi/scsi_transport_iscsi.c|2 drivers/soc/tegra/pmc.c|8 drivers/thermal/broadcom/bcm2835_thermal.c |9 drivers/thermal/int340x_thermal/int3400_thermal.c | 21 drivers/thermal/intel_powerclamp.c |4 drivers/tty/serial/xilinx_uartps.c |2 fs/9p/v9fs.c | 21 fs/9p/v9fs.h |1 fs/9p/vfs_dir.c|8 fs/9p/vfs_file.c |6 fs/cifs/inode.c| 67 - fs/cifs/smb2maperror.c |3 fs/ext4/ioctl.c|7 fs/ext4/resize.c | 17 fs/f2fs/super.c| 34 include/linux/atalk.h | 20 include/linux/bpf_verifier.h | 29 include/linux/compiler.h |5 include/linux/filter.h | 10 include/linux/swap.h |4 include/uapi/linux/netfilter/xt_cgroup.h | 16 kernel/bpf/core.c | 51 kernel/bpf/inode.c | 32 kernel/bpf/map_in_map.c| 17 kernel/bpf/verifier.c | 804 +--- kernel/events/core.c |2
[PATCH v4] arm64: dts: hi3660: Add CoreSight support
This patch adds DT bindings for the CoreSight trace components
on hi3660, which is used by 96boards Hikey960.
Signed-off-by: Wanglai Shi
---
.../arm64/boot/dts/hisilicon/hi3660-coresight.dtsi | 456 +
arch/arm64/boot/dts/hisilicon/hi3660.dtsi | 2 +
2 files changed, 458 insertions(+)
create mode 100644 arch/arm64/boot/dts/hisilicon/hi3660-coresight.dtsi
diff --git a/arch/arm64/boot/dts/hisilicon/hi3660-coresight.dtsi
b/arch/arm64/boot/dts/hisilicon/hi3660-coresight.dtsi
new file mode 100644
index 000..d607f2f
--- /dev/null
+++ b/arch/arm64/boot/dts/hisilicon/hi3660-coresight.dtsi
@@ -0,0 +1,456 @@
+// SPDX-License-Identifier: GPL-2.0
+
+/*
+ * dtsi for Hisilicon Hi3660 Coresight
+ *
+ * Copyright (C) 2016-2018 Hisilicon Ltd.
+ *
+ * Author: Wanglai Shi
+ *
+ */
+/ {
+ soc {
+ /* A53 cluster internals */
+ etm@ecc4 {
+ compatible = "arm,coresight-etm4x", "arm,primecell";
+ reg = <0 0xecc4 0 0x1000>;
+ clocks = <_ctrl HI3660_PCLK>;
+ clock-names = "apb_pclk";
+ cpu = <>;
+
+ out-ports {
+ port {
+ etm0_out: endpoint {
+ remote-endpoint =
+ <_funnel_in0>;
+ };
+ };
+ };
+ };
+
+ etm@ecd4 {
+ compatible = "arm,coresight-etm4x", "arm,primecell";
+ reg = <0 0xecd4 0 0x1000>;
+ clocks = <_ctrl HI3660_PCLK>;
+ clock-names = "apb_pclk";
+ cpu = <>;
+
+ out-ports {
+ port {
+ etm1_out: endpoint {
+ remote-endpoint =
+ <_funnel_in1>;
+ };
+ };
+ };
+ };
+
+ etm@ece4 {
+ compatible = "arm,coresight-etm4x", "arm,primecell";
+ reg = <0 0xece4 0 0x1000>;
+ clocks = <_ctrl HI3660_PCLK>;
+ clock-names = "apb_pclk";
+ cpu = <>;
+
+ out-ports {
+ port {
+ etm2_out: endpoint {
+ remote-endpoint =
+ <_funnel_in2>;
+ };
+ };
+ };
+ };
+
+ etm@ecf4 {
+ compatible = "arm,coresight-etm4x", "arm,primecell";
+ reg = <0 0xecf4 0 0x1000>;
+ clocks = <_ctrl HI3660_PCLK>;
+ clock-names = "apb_pclk";
+ cpu = <>;
+
+ out-ports {
+ port {
+ etm3_out: endpoint {
+ remote-endpoint =
+ <_funnel_in3>;
+ };
+ };
+ };
+ };
+
+ funnel@ec801000 {
+ compatible = "arm,coresight-dynamic-funnel",
"arm,primecell";
+ reg = <0 0xec801000 0 0x1000>;
+ clocks = <_ctrl HI3660_PCLK>;
+ clock-names = "apb_pclk";
+
+ out-ports {
+ port {
+ cluster0_funnel_out: endpoint {
+ remote-endpoint =
+ <_etf_in>;
+ };
+ };
+ };
+
+ in-ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ cluster0_funnel_in0: endpoint {
+ remote-endpoint = <_out>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+ cluster0_funnel_in1: endpoint {
+
[PATCH 2/2] fs: f2fs: insert space before the open parenthesis '('
Modify coding style
ERROR: space required before the open parenthesis '('
Signed-off-by: Youngjun Yoo
---
fs/f2fs/acl.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/f2fs/acl.c b/fs/f2fs/acl.c
index a10b5abc1eb2..217b290ae3a5 100644
--- a/fs/f2fs/acl.c
+++ b/fs/f2fs/acl.c
@@ -285,7 +285,7 @@ static int f2fs_acl_create_masq(struct posix_acl *acl,
umode_t *mode_p)
/* assert(atomic_read(acl->a_refcount) == 1); */
FOREACH_ACL_ENTRY(pa, acl, pe) {
- switch(pa->e_tag) {
+ switch (pa->e_tag) {
case ACL_USER_OBJ:
pa->e_perm &= (mode >> 6) | ~S_IRWXO;
mode &= (pa->e_perm << 6) | ~S_IRWXU;
--
2.17.1
Re: [PATCH v3 1/9] ARM: dts: imx6qdl: Specify IMX6QDL_CLK_IPG as "ipg" clock to SDMA
On Sat, Apr 20, 2019 at 07:14:26AM -0500, Adam Ford wrote:
> On Wed, Apr 10, 2019 at 9:30 PM Shawn Guo wrote:
> >
> > On Thu, Mar 28, 2019 at 11:49:16PM -0700, Andrey Smirnov wrote:
> > > Since 25aaa75df1e6 SDMA driver uses clock rates of "ipg" and "ahb"
> > > clock to determine if it needs to configure the IP block as operating
> > > at 1:1 or 1:2 clock ratio (ACR bit in SDMAARM_CONFIG). Specifying both
> > > clocks as IMX6QDL_CLK_SDMA results in driver incorrectly thinking that
> > > ratio is 1:1 which results in broken SDMA funtionality(this at least
> > > breaks RAVE SP serdev driver on RDU2). Fix the code to specify
> > > IMX6QDL_CLK_IPG as "ipg" clock for SDMA, to avoid detecting incorrect
> > > clock ratio.
> > >
> > > Fixes: 25aaa75df1e6 ("dmaengine: imx-sdma: add clock ratio 1:1 check")
> >
> > Since we have a fix in the dma driver, I dropped the Fixes tag here.
> >
> > Applied all, thanks.
>
> Do you know if the SDMA fixes will be back-ported to 5.0.y branch? To
> get 5.0 working, I need to manually apply the patches.
I'm confused here. The regression was caused by 25aaa75df1e6
("dmaengine: imx-sdma: add clock ratio 1:1 check"), which only lands on
mainline with v5.1-rc1. How would 5.0.y branch need fixing?
Shawn
Re: [RESEND v2] soc: imx: Add generic i.MX8 SoC driver
On Fri, Mar 22, 2019 at 04:49:20PM +, Abel Vesa wrote: > Add generic i.MX8 SoC driver along with the i.MX8MQ SoC specific code. > For now, only i.MX8MQ revision B1 is supported. For any other, i.MX8MQ > revision it will print 'unknown'. > > Signed-off-by: Abel Vesa Applied, thanks.
[PATCH] habanalabs: Cancel pr_fmt() definition dependency on includes order
From: Tomer Tayar pr_fmt() should be defined before including linux/printk.h, either directly or indirectly, in order to avoid redefinition of the macro. Currently the macro definition is in habanalabs.h, which is included in many files, and that makes the addition/reorder of includes to be prone to compilation errors. This patch cancels this dependency by defining the macro only in the few source files that use it. Signed-off-by: Tomer Tayar Signed-off-by: Oded Gabbay --- drivers/misc/habanalabs/device.c | 2 ++ drivers/misc/habanalabs/habanalabs.h | 2 -- drivers/misc/habanalabs/habanalabs_drv.c | 2 ++ 3 files changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/misc/habanalabs/device.c b/drivers/misc/habanalabs/device.c index 25bfb093ff26..a88f7be23c7f 100644 --- a/drivers/misc/habanalabs/device.c +++ b/drivers/misc/habanalabs/device.c @@ -5,6 +5,8 @@ * All Rights Reserved. */ +#define pr_fmt(fmt)"habanalabs: " fmt + #include "habanalabs.h" #include diff --git a/drivers/misc/habanalabs/habanalabs.h b/drivers/misc/habanalabs/habanalabs.h index 2f02bb55f66a..86bd5298efd6 100644 --- a/drivers/misc/habanalabs/habanalabs.h +++ b/drivers/misc/habanalabs/habanalabs.h @@ -11,8 +11,6 @@ #include "include/armcp_if.h" #include "include/qman_if.h" -#define pr_fmt(fmt)"habanalabs: " fmt - #include #include #include diff --git a/drivers/misc/habanalabs/habanalabs_drv.c b/drivers/misc/habanalabs/habanalabs_drv.c index 1667df7ca64c..5f4d155be767 100644 --- a/drivers/misc/habanalabs/habanalabs_drv.c +++ b/drivers/misc/habanalabs/habanalabs_drv.c @@ -6,6 +6,8 @@ * */ +#define pr_fmt(fmt)"habanalabs: " fmt + #include "habanalabs.h" #include -- 2.17.1
Re: [PATCH RFC 1/2] Add polling support to pidfd
On Sat, Apr 20, 2019 at 02:26:15PM +0200, Oleg Nesterov wrote: > On 04/20, Oleg Nesterov wrote: > > > > Note that we need > > thread_group_empty() only for the case when the task is traced, > > Damn, sorry for noise... of course this is not true, I tried to say that > notification won't come otherwise. Nevermind, lets discuss this when we > have a patch. I already got lost in this thread and I have no idea what Agreed. The polling work is not targeted for the 5.2 merge window anyway so there's no need to rush this. > are you all talking about ;) Nothing patch-worthy comes without a solid portion of controversy and confusion at first. ;) Christian
Re: [PATCH 5.0 00/93] 5.0.9-stable review
Built and booted on my x86 machine. Observed no dmesg regressions.
Re: [PATCH 4.9 00/50] 4.9.170-stable review
Built and booted the kernel with defconfig on my x86 machine. Observed no dmesg regressions.
Re: [PATCH RFC 1/2] Add polling support to pidfd
On 04/20, Oleg Nesterov wrote: > > Note that we need > thread_group_empty() only for the case when the task is traced, Damn, sorry for noise... of course this is not true, I tried to say that notification won't come otherwise. Nevermind, lets discuss this when we have a patch. I already got lost in this thread and I have no idea what are you all talking about ;) Oleg.
[PATCH v4 2/3] Input: add a driver for GPIO controllable vibrators
Provide a simple driver for GPIO controllable vibrators.
It will be used by the Fairphone 2.
Signed-off-by: Luca Weiss
---
Changes from v3:
- Apply suggestions from Stephen Boyd
drivers/input/misc/Kconfig | 12 ++
drivers/input/misc/Makefile | 1 +
drivers/input/misc/gpio-vibra.c | 209
3 files changed, 222 insertions(+)
create mode 100644 drivers/input/misc/gpio-vibra.c
diff --git a/drivers/input/misc/Kconfig b/drivers/input/misc/Kconfig
index e15ed1bb8558..6dfe9e2fe5b1 100644
--- a/drivers/input/misc/Kconfig
+++ b/drivers/input/misc/Kconfig
@@ -290,6 +290,18 @@ config INPUT_GPIO_DECODER
To compile this driver as a module, choose M here: the module
will be called gpio_decoder.
+config INPUT_GPIO_VIBRA
+ tristate "GPIO vibrator support"
+ depends on GPIOLIB || COMPILE_TEST
+ select INPUT_FF_MEMLESS
+ help
+ Say Y here to get support for GPIO based vibrator devices.
+
+ If unsure, say N.
+
+ To compile this driver as a module, choose M here: the module will be
+ called gpio-vibra.
+
config INPUT_IXP4XX_BEEPER
tristate "IXP4XX Beeper support"
depends on ARCH_IXP4XX
diff --git a/drivers/input/misc/Makefile b/drivers/input/misc/Makefile
index b936c5b1d4ac..f38ebbdb05e2 100644
--- a/drivers/input/misc/Makefile
+++ b/drivers/input/misc/Makefile
@@ -36,6 +36,7 @@ obj-$(CONFIG_INPUT_DRV2667_HAPTICS) += drv2667.o
obj-$(CONFIG_INPUT_GP2A) += gp2ap002a00f.o
obj-$(CONFIG_INPUT_GPIO_BEEPER)+= gpio-beeper.o
obj-$(CONFIG_INPUT_GPIO_DECODER) += gpio_decoder.o
+obj-$(CONFIG_INPUT_GPIO_VIBRA) += gpio-vibra.o
obj-$(CONFIG_INPUT_HISI_POWERKEY) += hisi_powerkey.o
obj-$(CONFIG_HP_SDC_RTC) += hp_sdc_rtc.o
obj-$(CONFIG_INPUT_IMS_PCU)+= ims-pcu.o
diff --git a/drivers/input/misc/gpio-vibra.c b/drivers/input/misc/gpio-vibra.c
new file mode 100644
index ..b76c81015de9
--- /dev/null
+++ b/drivers/input/misc/gpio-vibra.c
@@ -0,0 +1,209 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * GPIO vibrator driver
+ *
+ * Copyright (C) 2019 Luca Weiss
+ *
+ * Based on PWM vibrator driver:
+ * Copyright (C) 2017 Collabora Ltd.
+ *
+ * Based on previous work from:
+ * Copyright (C) 2012 Dmitry Torokhov
+ *
+ * Based on PWM beeper driver:
+ * Copyright (C) 2010, Lars-Peter Clausen
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+struct gpio_vibrator {
+ struct input_dev *input;
+ struct gpio_desc *gpio;
+ struct regulator *vcc;
+
+ struct work_struct play_work;
+ bool running;
+ bool vcc_on;
+};
+
+static int gpio_vibrator_start(struct gpio_vibrator *vibrator)
+{
+ struct device *pdev = vibrator->input->dev.parent;
+ int err;
+
+ if (!vibrator->vcc_on) {
+ err = regulator_enable(vibrator->vcc);
+ if (err) {
+ dev_err(pdev, "failed to enable regulator: %d\n", err);
+ return err;
+ }
+ vibrator->vcc_on = true;
+ }
+
+ gpiod_set_value_cansleep(vibrator->gpio, 1);
+
+ return 0;
+}
+
+static void gpio_vibrator_stop(struct gpio_vibrator *vibrator)
+{
+ gpiod_set_value_cansleep(vibrator->gpio, 0);
+
+ if (vibrator->vcc_on) {
+ regulator_disable(vibrator->vcc);
+ vibrator->vcc_on = false;
+ }
+}
+
+static void gpio_vibrator_play_work(struct work_struct *work)
+{
+ struct gpio_vibrator *vibrator =
+ container_of(work, struct gpio_vibrator, play_work);
+
+ if (vibrator->running)
+ gpio_vibrator_start(vibrator);
+ else
+ gpio_vibrator_stop(vibrator);
+}
+
+static int gpio_vibrator_play_effect(struct input_dev *dev, void *data,
+struct ff_effect *effect)
+{
+ struct gpio_vibrator *vibrator = input_get_drvdata(dev);
+
+ int level = effect->u.rumble.strong_magnitude;
+
+ if (!level)
+ level = effect->u.rumble.weak_magnitude;
+
+ if (level)
+ vibrator->running = true;
+ else
+ vibrator->running = false;
+
+ schedule_work(>play_work);
+
+ return 0;
+}
+
+static void gpio_vibrator_close(struct input_dev *input)
+{
+ struct gpio_vibrator *vibrator = input_get_drvdata(input);
+
+ cancel_work_sync(>play_work);
+ gpio_vibrator_stop(vibrator);
+ vibrator->running = false;
+}
+
+static int gpio_vibrator_probe(struct platform_device *pdev)
+{
+ struct gpio_vibrator *vibrator;
+ int err;
+
+ vibrator = devm_kzalloc(>dev, sizeof(*vibrator), GFP_KERNEL);
+ if (!vibrator)
+ return -ENOMEM;
+
+ vibrator->input = devm_input_allocate_device(>dev);
+ if (!vibrator->input)
+ return -ENOMEM;
+
+
[PATCH v4 1/3] dt-bindings: input: add GPIO controllable vibrator
Provide a simple driver for GPIO controllable vibrators.
It will be used by the Fairphone 2.
Signed-off-by: Luca Weiss
---
Changes from v3:
- Convert .txt based doc to the new yaml based format
.../bindings/input/gpio-vibrator.yaml | 39 +++
1 file changed, 39 insertions(+)
create mode 100644 Documentation/devicetree/bindings/input/gpio-vibrator.yaml
diff --git a/Documentation/devicetree/bindings/input/gpio-vibrator.yaml
b/Documentation/devicetree/bindings/input/gpio-vibrator.yaml
new file mode 100644
index ..bca1b6ea07a4
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/gpio-vibrator.yaml
@@ -0,0 +1,39 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/bindings/input/gpio-vibrator.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: GPIO vibrator
+
+maintainers:
+ - Luca Weiss
+
+description: |+
+ Registers a GPIO device as vibrator, where the on/off capability is
controlled by a GPIO.
+
+properties:
+ compatible:
+items:
+ - const: gpio-vibrator
+
+ enable-gpios:
+maxItems: 1
+
+ vcc-supply:
+$ref: /schemas/types.yaml#/definitions/phandle
+description: Regulator that provides power
+
+required:
+ - compatible
+ - enable-gpios
+
+examples:
+ - |
+#include
+
+vibrator {
+compatible = "gpio-vibrator";
+enable-gpios = < 86 GPIO_ACTIVE_HIGH>;
+vcc-supply = <_l18>;
+};
--
2.21.0
[PATCH v4 3/3] ARM: dts: msm8974-FP2: Add vibration motor
Signed-off-by: Luca Weiss
---
arch/arm/boot/dts/qcom-msm8974-fairphone-fp2.dts | 6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/boot/dts/qcom-msm8974-fairphone-fp2.dts
b/arch/arm/boot/dts/qcom-msm8974-fairphone-fp2.dts
index 643c57f84818..bf402ae39226 100644
--- a/arch/arm/boot/dts/qcom-msm8974-fairphone-fp2.dts
+++ b/arch/arm/boot/dts/qcom-msm8974-fairphone-fp2.dts
@@ -50,6 +50,12 @@
};
};
+ vibrator {
+ compatible = "gpio-vibrator";
+ enable-gpios = < 86 GPIO_ACTIVE_HIGH>;
+ vcc-supply = <_l18>;
+ };
+
smd {
rpm {
rpm_requests {
--
2.21.0
Re: [PATCH v3 1/9] ARM: dts: imx6qdl: Specify IMX6QDL_CLK_IPG as "ipg" clock to SDMA
On Wed, Apr 10, 2019 at 9:30 PM Shawn Guo wrote:
>
> On Thu, Mar 28, 2019 at 11:49:16PM -0700, Andrey Smirnov wrote:
> > Since 25aaa75df1e6 SDMA driver uses clock rates of "ipg" and "ahb"
> > clock to determine if it needs to configure the IP block as operating
> > at 1:1 or 1:2 clock ratio (ACR bit in SDMAARM_CONFIG). Specifying both
> > clocks as IMX6QDL_CLK_SDMA results in driver incorrectly thinking that
> > ratio is 1:1 which results in broken SDMA funtionality(this at least
> > breaks RAVE SP serdev driver on RDU2). Fix the code to specify
> > IMX6QDL_CLK_IPG as "ipg" clock for SDMA, to avoid detecting incorrect
> > clock ratio.
> >
> > Fixes: 25aaa75df1e6 ("dmaengine: imx-sdma: add clock ratio 1:1 check")
>
> Since we have a fix in the dma driver, I dropped the Fixes tag here.
>
> Applied all, thanks.
Do you know if the SDMA fixes will be back-ported to 5.0.y branch? To
get 5.0 working, I need to manually apply the patches.
thanks
adam
>
> Shawn
>
> > Signed-off-by: Andrey Smirnov
> > Reviewed-by: Lucas Stach
> > Cc: Angus Ainslie (Purism)
> > Cc: Chris Healy
> > Cc: Lucas Stach
> > Cc: Fabio Estevam
> > Cc: Shawn Guo
> > Cc: linux-arm-ker...@lists.infradead.org
> > Cc: linux-kernel@vger.kernel.org
> > ---
> > arch/arm/boot/dts/imx6qdl.dtsi | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/arch/arm/boot/dts/imx6qdl.dtsi b/arch/arm/boot/dts/imx6qdl.dtsi
> > index 9f9aa6e7ed0e..354feba077b2 100644
> > --- a/arch/arm/boot/dts/imx6qdl.dtsi
> > +++ b/arch/arm/boot/dts/imx6qdl.dtsi
> > @@ -949,7 +949,7 @@
> > compatible = "fsl,imx6q-sdma",
> > "fsl,imx35-sdma";
> > reg = <0x020ec000 0x4000>;
> > interrupts = <0 2 IRQ_TYPE_LEVEL_HIGH>;
> > - clocks = < IMX6QDL_CLK_SDMA>,
> > + clocks = < IMX6QDL_CLK_IPG>,
> >< IMX6QDL_CLK_SDMA>;
> > clock-names = "ipg", "ahb";
> > #dma-cells = <3>;
> > --
> > 2.20.1
> >
>
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
[PATCH] staging: vt665*: use help instead of ---help--- in Kconfig
From: Moses Christopher - Resolve the following warning from the Kconfig, "WARNING: prefer 'help' over '---help---' for new help texts" - Use 8space tab instead of 3space in vt6655/Kconfig Signed-off-by: Moses Christopher --- drivers/staging/vt6655/Kconfig | 9 - drivers/staging/vt6656/Kconfig | 4 ++-- 2 files changed, 6 insertions(+), 7 deletions(-) diff --git a/drivers/staging/vt6655/Kconfig b/drivers/staging/vt6655/Kconfig index 77cfc708c516..ed0cfc765677 100644 --- a/drivers/staging/vt6655/Kconfig +++ b/drivers/staging/vt6655/Kconfig @@ -1,6 +1,5 @@ config VT6655 - tristate "VIA Technologies VT6655 support" - depends on PCI && MAC80211 && m - ---help--- - This is a vendor-written driver for VIA VT6655. - + tristate "VIA Technologies VT6655 support" + depends on PCI && MAC80211 && m + help + This is a vendor-written driver for VIA VT6655. diff --git a/drivers/staging/vt6656/Kconfig b/drivers/staging/vt6656/Kconfig index b602ef175d55..16b124ed23bc 100644 --- a/drivers/staging/vt6656/Kconfig +++ b/drivers/staging/vt6656/Kconfig @@ -2,6 +2,6 @@ config VT6656 tristate "VIA Technologies VT6656 support" depends on MAC80211 && USB && WLAN && m select FW_LOADER - ---help--- - This is a vendor-written driver for VIA VT6656. + help + This is a vendor-written driver for VIA VT6656. -- 2.11.0
Re: [PATCH 3/3] RAS/CEC: immediate soft-offline page when count_threshold == 1
On Thu, Apr 18, 2019 at 11:41:15AM +0800, WANG Chao wrote: > count_threshol == 1 isn't working as expected. CEC only does soft > offline the second time the same pfn is hit by a correctable error. So this? --- diff --git a/drivers/ras/cec.c b/drivers/ras/cec.c index b3c377ddf340..750a427e1a73 100644 --- a/drivers/ras/cec.c +++ b/drivers/ras/cec.c @@ -333,6 +333,7 @@ int cec_add_elem(u64 pfn) mutex_lock(_mutex); + /* Array full, free the LRU slot. */ if (ca->n == MAX_ELEMS) WARN_ON(!del_lru_elem_unlocked(ca)); @@ -346,14 +347,9 @@ int cec_add_elem(u64 pfn) (void *)>array[to], (ca->n - to) * sizeof(u64)); - ca->array[to] = (pfn << PAGE_SHIFT) | - (DECAY_MASK << COUNT_BITS) | 1; + ca->array[to] = (pfn << PAGE_SHIFT) | 1; ca->n++; - - ret = 0; - - goto decay; } count = COUNT(ca->array[to]); @@ -386,7 +382,6 @@ int cec_add_elem(u64 pfn) goto unlock; } -decay: ca->decay_count++; if (ca->decay_count >= CLEAN_ELEMS) -- Regards/Gruss, Boris. Good mailing practices for 400: avoid top-posting and trim the reply.
Re: [PATCH RFC 1/2] Add polling support to pidfd
On 04/19, Christian Brauner wrote: > > > Just for the exit notification purposes, the states are: > > if process has exit_state == 0, block. > > if process is zombie/dead but not reaped, then return POLLIN > > if process is reaped, then return POLLIN | POLLHUP > > Oleg was explicitly against EXIT_ZOMBIE/DEAD thing, no? He said so in a > prior mail. Has this been addressed? Yes, please don't use EXIT_XXX codes, nobody should ever use them except the core kernel exit/wait paths. For example, EXIT_DEAD means that the task auto- reaps or its parent had to temporary drop tasklist. Just check ->exit_state != 0 && thread_group_empty(). Note that we need thread_group_empty() only for the case when the task is traced, in this case we have an extra notification for debugger which can confuse pidfd_poll(). And of course, everything will differ if/when we will need to monitor the sub-threads. And btw I don't think it needs tasklist_lock, but lets discuss this when we have a new version based on pidfd. Oleg.
[PATCH] staging: unisys: use help instead of ---help--- in Kconfig
From: Moses Christopher - Resolve the following warning from the Kconfig, "WARNING: prefer 'help' over '---help---' for new help texts" Signed-off-by: Moses Christopher --- drivers/staging/unisys/Kconfig| 2 +- drivers/staging/unisys/visorhba/Kconfig | 2 +- drivers/staging/unisys/visorinput/Kconfig | 2 +- drivers/staging/unisys/visornic/Kconfig | 2 +- 4 files changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/staging/unisys/Kconfig b/drivers/staging/unisys/Kconfig index c27dab3b610f..b9c814df5d36 100644 --- a/drivers/staging/unisys/Kconfig +++ b/drivers/staging/unisys/Kconfig @@ -3,7 +3,7 @@ # menuconfig UNISYSSPAR bool "Unisys SPAR driver support" - ---help--- + help Support for the Unisys SPAR drivers if UNISYSSPAR diff --git a/drivers/staging/unisys/visorhba/Kconfig b/drivers/staging/unisys/visorhba/Kconfig index 241d8038261c..4b67634b236d 100644 --- a/drivers/staging/unisys/visorhba/Kconfig +++ b/drivers/staging/unisys/visorhba/Kconfig @@ -5,7 +5,7 @@ config UNISYS_VISORHBA tristate "Unisys visorhba driver" depends on UNISYSSPAR && UNISYS_VISORBUS && SCSI - ---help--- + help The Unisys visorhba driver provides support for s-Par HBA devices exposed on the s-Par visorbus. When a message is sent to visorbus to create a HBA device, the probe function of diff --git a/drivers/staging/unisys/visorinput/Kconfig b/drivers/staging/unisys/visorinput/Kconfig index a3817e0f7e5c..c0681f932d76 100644 --- a/drivers/staging/unisys/visorinput/Kconfig +++ b/drivers/staging/unisys/visorinput/Kconfig @@ -5,7 +5,7 @@ config UNISYS_VISORINPUT tristate "Unisys visorinput driver" depends on UNISYSSPAR && UNISYS_VISORBUS && INPUT - ---help--- + help The Unisys s-Par visorinput driver provides a virtualized system console (keyboard and mouse) that is accessible through the s-Par firmware's user interface. s-Par provides video using the EFI diff --git a/drivers/staging/unisys/visornic/Kconfig b/drivers/staging/unisys/visornic/Kconfig index 1676dc7072d5..33a9b63bccb5 100644 --- a/drivers/staging/unisys/visornic/Kconfig +++ b/drivers/staging/unisys/visornic/Kconfig @@ -5,7 +5,7 @@ config UNISYS_VISORNIC tristate "Unisys visornic driver" depends on UNISYSSPAR && UNISYS_VISORBUS && NET - ---help--- + help The Unisys Visornic driver provides support for s-Par network devices exposed on the s-Par visorbus. When a message is sent to visorbus to create a network device, the probe function of -- 2.11.0
Re: [PATCH v3 3/3] module: Make __tracepoints_ptrs as read-only
On Wed, Apr 17, 2019 at 05:16:18PM +0200, Jessica Yu wrote: > +++ Steven Rostedt [10/04/19 20:44 -0400]: > > On Wed, 10 Apr 2019 16:29:02 -0400 > > Joel Fernandes wrote: > > > > > The srcu structure pointer array is modified at module load time because > > > the > > > array is fixed up by the module loader at load-time with the final > > > locations > > > of the tracepoints right? Basically relocation fixups. At compile time, I > > > believe it is not know what the values in the ptr array are. I believe > > > same > > > is true for the tracepoint ptrs array. > > > > > > Also it needs to be in a separate __tracepoint_ptrs so that this code > > > works: > > > > > > > > > #ifdef CONFIG_TRACEPOINTS > > > mod->tracepoints_ptrs = section_objs(info, "__tracepoints_ptrs", > > >sizeof(*mod->tracepoints_ptrs), > > >>num_tracepoints); > > > #endif > > > > > > Did I miss some point? Thanks, > > > > But there's a lot of others too. Hmm, does this mean that the RO data > > sections that are in modules are not set to RO? > > > > There's a bunch of separate sections that are RO. Just look in > > include/asm-generic/vmlinux.lds.h under the RO_DATA_SECTION() macro. > > > > A lot of the sections saved in module.c:find_module_sections() are in > > that RO_DATA when compiled as a builtin. Are they not RO when loaded via > > a module? > > Unlike the kernel, the module loader does not rely on a linker script > to determine which sections get what protections. On module load, all > sections in a module are looped through and those sections without the > SHF_WRITE flag will be set to RO. For example, when there is a section > filled with structs declared as const or if the section was explicitly > given only the SHF_ALLOC attribute, those will be read-only. As long > as the sections were given the correct section attributes for > read-only, it'll have read-only protection. I see this is already the > case for __param and __ksymtab*/__kcrctab* sections, but I agree that > a full audit would be useful to be consistent with builtin RO > protections. Thanks a lot for the explanations. Yes we dropped the patches because const worked. This is good to know for future such ventures as well ;-) Best, - Joel > Jessica
[PATCH] staging: rtl8*: use help instead of ---help--- in Kconfig
From: Moses Christopher - Resolve the following warning from the Kconfig, "WARNING: prefer 'help' over '---help---' for new help texts" Signed-off-by: Moses Christopher --- drivers/staging/rtl8188eu/Kconfig | 4 ++-- drivers/staging/rtl8192e/Kconfig | 8 drivers/staging/rtl8712/Kconfig | 4 ++-- drivers/staging/rtl8723bs/Kconfig | 2 +- 4 files changed, 9 insertions(+), 9 deletions(-) diff --git a/drivers/staging/rtl8188eu/Kconfig b/drivers/staging/rtl8188eu/Kconfig index ff7832798a77..3f8c655856bf 100644 --- a/drivers/staging/rtl8188eu/Kconfig +++ b/drivers/staging/rtl8188eu/Kconfig @@ -7,7 +7,7 @@ config R8188EU select LIB80211 select LIB80211_CRYPT_WEP select LIB80211_CRYPT_CCMP - ---help--- + help This option adds the Realtek RTL8188EU USB device such as TP-Link TL-WN725N. If built as a module, it will be called r8188eu. @@ -16,7 +16,7 @@ if R8188EU config 88EU_AP_MODE bool "Realtek RTL8188EU AP mode" default y - ---help--- + help This option enables Access Point mode. Unless you know that your system will never be used as an AP, or the target system has limited memory, "Y" should be selected. diff --git a/drivers/staging/rtl8192e/Kconfig b/drivers/staging/rtl8192e/Kconfig index 4602a47cdb4a..aa571c12678f 100644 --- a/drivers/staging/rtl8192e/Kconfig +++ b/drivers/staging/rtl8192e/Kconfig @@ -3,7 +3,7 @@ config RTLLIB depends on WLAN && m default n select LIB80211 - ---help--- + help If you have a wireless card that uses rtllib, say Y. Currently the only card is the rtl8192e. @@ -16,7 +16,7 @@ config RTLLIB_CRYPTO_CCMP depends on RTLLIB select CRYPTO_AES default y - ---help--- + help CCMP crypto driver for rtllib. If you enabled RTLLIB, you want this. @@ -27,7 +27,7 @@ config RTLLIB_CRYPTO_TKIP select CRYPTO_ARC4 select CRYPTO_MICHAEL_MIC default y - ---help--- + help TKIP crypto driver for rtllib. If you enabled RTLLIB, you want this. @@ -37,7 +37,7 @@ config RTLLIB_CRYPTO_WEP select CRYPTO_ARC4 depends on RTLLIB default y - ---help--- + help TKIP crypto driver for rtllib. If you enabled RTLLIB, you want this. diff --git a/drivers/staging/rtl8712/Kconfig b/drivers/staging/rtl8712/Kconfig index f160eee52f09..b377d90742db 100644 --- a/drivers/staging/rtl8712/Kconfig +++ b/drivers/staging/rtl8712/Kconfig @@ -4,14 +4,14 @@ config R8712U select WIRELESS_EXT select WEXT_PRIV select FW_LOADER - ---help--- + help This option adds the Realtek RTL8712 USB device such as the D-Link DWA-130. If built as a module, it will be called r8712u. config R8712_TX_AGGR bool "Realtek RTL8712U Transmit Aggregation code" depends on R8712U && BROKEN - ---help--- + help This option provides transmit aggregation for the Realtek RTL8712 USB device. diff --git a/drivers/staging/rtl8723bs/Kconfig b/drivers/staging/rtl8723bs/Kconfig index deae0427ba6c..41ad6ed24860 100644 --- a/drivers/staging/rtl8723bs/Kconfig +++ b/drivers/staging/rtl8723bs/Kconfig @@ -4,7 +4,7 @@ config RTL8723BS depends on m select WIRELESS_EXT select WEXT_PRIV - ---help--- + help This option enables support for RTL8723BS SDIO drivers, such as the wifi found on the 1st gen Intel Compute Stick, the CHIP and many other Intel Atom and ARM based devices. -- 2.11.0
[PATCH] regulator: core: Actually put the gpiod after use
I went to great lengths to hand over the management of the GPIO
descriptors to the regulator core, and some stray rebased
oneliner in the old patch must have been assuming the devices
were still doing devres management of it.
We handed the management over to the regulator core, so of
course the regulator core shall issue gpiod_put() when done.
Sorry for the descriptor leak.
Fixes: 541d052d7215 ("regulator: core: Only support passing enable GPIO
descriptors")
Signed-off-by: Linus Walleij
---
drivers/regulator/core.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
index 68473d0cc57e..362f34e73a3f 100644
--- a/drivers/regulator/core.c
+++ b/drivers/regulator/core.c
@@ -2256,6 +2256,7 @@ static void regulator_ena_gpio_free(struct regulator_dev
*rdev)
if (pin->gpiod == rdev->ena_pin->gpiod) {
if (pin->request_count <= 1) {
pin->request_count = 0;
+ gpiod_put(pin->gpiod);
list_del(>list);
kfree(pin);
rdev->ena_pin = NULL;
--
2.20.1
Re: [PATCH v2 1/2] ras: fix an off-by-one error in __find_elem()
On Tue, Apr 16, 2019 at 04:16:08PM -0700, Cong Wang wrote:
> It is actually fairly easy:
>
> 1) Fill the whole page with PFN's:
> for i in `seq 0 511`; do echo $i >> /sys/kernel/debug/ras/cec/pfn; done
>
> 2) Set thresh to 1 in order to trigger the deletion:
> echo 1 > /sys/kernel/debug/ras/cec/count_threshold
>
> 3) Repeatedly add and remove the last element:
> echo 512 >> /sys/kernel/debug/ras/cec/pfn
> (until you get a crash.)
Thanks, I was able to reproduce with that. Below is a conglomerate patch
which converts __find_elem() to using Donald Knuth's binary search
version. I don't know what I was thinking then and why I didn't use
it from the get-go. The textbook even says that one can easily get it
wrong...
Anyway, see below. It has some debug output for easier debugging, that
will be removed in the final version, of course. With it, the injection
pattern above works as expected and I'll continue hammering on it to see
if there are more funky issues.
For easier experimenting, the whole branch is also here:
https://git.kernel.org/pub/scm/linux/kernel/git/bp/bp.git/log/?h=tip-ras-core-cec
Thx.
---
From: Borislav Petkov
Date: Sat, 20 Apr 2019 13:27:51 +0200
Subject: [PATCH] WIP
Signed-off-by: Borislav Petkov
---
drivers/ras/cec.c | 83 +++
1 file changed, 62 insertions(+), 21 deletions(-)
diff --git a/drivers/ras/cec.c b/drivers/ras/cec.c
index 3e9f62b84378..946e52751ae2 100644
--- a/drivers/ras/cec.c
+++ b/drivers/ras/cec.c
@@ -185,31 +185,42 @@ static void cec_work_fn(struct work_struct *work)
*/
static int __find_elem(struct ce_array *ca, u64 pfn, unsigned int *to)
{
+ int min = 0, max = ca->n - 1;
u64 this_pfn;
- int min = 0, max = ca->n;
- while (min < max) {
- int tmp = (max + min) >> 1;
+ pr_info("%s: entry %llu in [%d:%d]?\n", __func__, pfn, min, max);
- this_pfn = PFN(ca->array[tmp]);
+ while (min <= max) {
+ int i = (min + max) >> 1;
+
+ this_pfn = PFN(ca->array[i]);
+
+ pr_info("%s: ... this_pfn: %3llu, [%3d:%3d:%3d]\n",
+ __func__, this_pfn, min, i, max);
if (this_pfn < pfn)
- min = tmp + 1;
+ min = i + 1;
else if (this_pfn > pfn)
- max = tmp;
- else {
- min = tmp;
- break;
+ max = i - 1;
+ else if (this_pfn == pfn) {
+ pr_info("%s: .. FOUND at %d\n", __func__, i);
+
+ if (to)
+ *to = i;
+
+ return i;
}
}
- if (to)
- *to = min;
-
- this_pfn = PFN(ca->array[min]);
+ /*
+* When the loop terminates without finding @pfn, min has the index of
+* the element slot where the new @pfn should be inserted.
+*/
- if (this_pfn == pfn)
- return min;
+ if (to) {
+ *to = min;
+ pr_info("%s: [%d:%d]\n", __func__, min, max);
+ }
return -ENOKEY;
}
@@ -234,6 +245,8 @@ static void del_elem(struct ce_array *ca, int idx)
(ca->n - (idx + 1)) * sizeof(u64));
ca->n--;
+
+ pr_info("%s: idx: %d, ca->n: %d\n", __func__, idx, ca->n);
}
static u64 del_lru_elem_unlocked(struct ce_array *ca)
@@ -274,13 +287,43 @@ static u64 __maybe_unused del_lru_elem(void)
return pfn;
}
+static bool sanity_check(struct ce_array *ca)
+{
+ bool ret = false;
+ u64 prev = 0;
+ int i;
+
+ for (i = 0; i < ca->n; i++) {
+ u64 this = PFN(ca->array[i]);
+
+ if (WARN(prev > this, "prev: 0x%016llx <-> this: 0x%016llx\n",
prev, this))
+ ret = true;
+
+ prev = this;
+ }
+
+ if (!ret)
+ return ret;
+
+ pr_info("Sanity check:\n{ n: %d\n", ca->n);
+ for (i = 0; i < ca->n; i++) {
+ u64 this = PFN(ca->array[i]);
+ pr_info(" %03d: [%016llx|%03llx]\n", i, this,
FULL_COUNT(ca->array[i]));
+ }
+ pr_info("}\n");
+
+ return ret;
+}
int cec_add_elem(u64 pfn)
{
struct ce_array *ca = _arr;
- unsigned int to;
+ unsigned int to = 0;
int count, ret = 0;
+ pr_info("===\n");
+ pr_info("%s: entry, pfn: %lld, ca->n: %d\n", __func__, pfn, ca->n);
+
/*
* We can be called very early on the identify_cpu() path where we are
* not initialized yet. We ignore the error for simplicity.
@@ -296,6 +339,7 @@ int cec_add_elem(u64 pfn)
WARN_ON(!del_lru_elem_unlocked(ca));
ret = find_elem(ca, pfn, );
+ pr_info("%s: find_elem: ret: %d: to: %d\n", __func__, ret, to);
if (ret < 0) {
[PATCH] staging: most: use help instead of ---help--- in Kconfig
From: Moses Christopher - Resolve the following warning from the Kconfig, "WARNING: prefer 'help' over '---help---' for new help texts" Signed-off-by: Moses Christopher --- drivers/staging/most/Kconfig | 2 +- drivers/staging/most/cdev/Kconfig | 2 +- drivers/staging/most/dim2/Kconfig | 2 +- drivers/staging/most/i2c/Kconfig | 2 +- drivers/staging/most/net/Kconfig | 2 +- drivers/staging/most/sound/Kconfig | 2 +- drivers/staging/most/usb/Kconfig | 2 +- drivers/staging/most/video/Kconfig | 2 +- 8 files changed, 8 insertions(+), 8 deletions(-) diff --git a/drivers/staging/most/Kconfig b/drivers/staging/most/Kconfig index 20047abbe560..09d2e1ee3388 100644 --- a/drivers/staging/most/Kconfig +++ b/drivers/staging/most/Kconfig @@ -2,7 +2,7 @@ menuconfig MOST tristate "MOST support" depends on HAS_DMA default n ----help--- +help Say Y here if you want to enable MOST support. This driver needs at least one additional component to enable the desired access from userspace (e.g. character devices) and one that diff --git a/drivers/staging/most/cdev/Kconfig b/drivers/staging/most/cdev/Kconfig index 2b04e26bcbea..2e27e1fce58d 100644 --- a/drivers/staging/most/cdev/Kconfig +++ b/drivers/staging/most/cdev/Kconfig @@ -5,7 +5,7 @@ config MOST_CDEV tristate "Cdev" - ---help--- + help Say Y here if you want to commumicate via character devices. To compile this driver as a module, choose M here: the diff --git a/drivers/staging/most/dim2/Kconfig b/drivers/staging/most/dim2/Kconfig index 5aeef22c3cba..ce9da9180056 100644 --- a/drivers/staging/most/dim2/Kconfig +++ b/drivers/staging/most/dim2/Kconfig @@ -6,7 +6,7 @@ config MOST_DIM2 tristate "DIM2" depends on HAS_IOMEM && OF - ---help--- + help Say Y here if you want to connect via MediaLB to network transceiver. This device driver is platform dependent and needs an additional platform driver to be installed. For more information contact diff --git a/drivers/staging/most/i2c/Kconfig b/drivers/staging/most/i2c/Kconfig index 79d0ff27f56d..f723f99711bd 100644 --- a/drivers/staging/most/i2c/Kconfig +++ b/drivers/staging/most/i2c/Kconfig @@ -5,7 +5,7 @@ config MOST_I2C tristate "I2C" depends on I2C - ---help--- + help Say Y here if you want to connect via I2C to network tranceiver. To compile this driver as a module, choose M here: the diff --git a/drivers/staging/most/net/Kconfig b/drivers/staging/most/net/Kconfig index 795330ba94ef..28040931f7e7 100644 --- a/drivers/staging/most/net/Kconfig +++ b/drivers/staging/most/net/Kconfig @@ -6,7 +6,7 @@ config MOST_NET tristate "Net" depends on NET - ---help--- + help Say Y here if you want to commumicate via a networking device. To compile this driver as a module, choose M here: the diff --git a/drivers/staging/most/sound/Kconfig b/drivers/staging/most/sound/Kconfig index 115262a58a42..5614a999b54e 100644 --- a/drivers/staging/most/sound/Kconfig +++ b/drivers/staging/most/sound/Kconfig @@ -6,7 +6,7 @@ config MOST_SOUND tristate "Sound" depends on SND select SND_PCM - ---help--- + help Say Y here if you want to commumicate via ALSA/sound devices. To compile this driver as a module, choose M here: the diff --git a/drivers/staging/most/usb/Kconfig b/drivers/staging/most/usb/Kconfig index ebbdb573a9a6..539b38fb3d88 100644 --- a/drivers/staging/most/usb/Kconfig +++ b/drivers/staging/most/usb/Kconfig @@ -5,7 +5,7 @@ config MOST_USB tristate "USB" depends on USB && NET - ---help--- + help Say Y here if you want to connect via USB to network tranceiver. This device driver depends on the networking AIM. diff --git a/drivers/staging/most/video/Kconfig b/drivers/staging/most/video/Kconfig index ce6af4f951a6..a458d0c74a0f 100644 --- a/drivers/staging/most/video/Kconfig +++ b/drivers/staging/most/video/Kconfig @@ -5,7 +5,7 @@ config MOST_VIDEO tristate "Video" depends on VIDEO_V4L2 - ---help--- + help Say Y here if you want to commumicate via Video 4 Linux. To compile this driver as a module, choose M here: the -- 2.11.0
Re: [PATCH] signal: trace_signal_deliver when signal_group_exit
On 04/20, Zhenliang Wei wrote:
>
> --- a/kernel/signal.c
> +++ b/kernel/signal.c
> @@ -2441,6 +2441,8 @@ bool get_signal(struct ksignal *ksig)
> if (signal_group_exit(signal)) {
> ksig->info.si_signo = signr = SIGKILL;
> sigdelset(>pending.signal, SIGKILL);
> + trace_signal_deliver(signr, >info,
> + >action[signr - 1]);
Well, in this case ksig->info is not fully initialized for TP_STORE_SIGINFO()
which reads si_errno/si_code...
How about
trace_signal_deliver(SIGKILL, SEND_SIG_NOINFO, SIG_DFL)
?
We know that action[SIGKILL] must be SIG_DFL.
And SEND_SIG_NOINFO matches the fact that SIGKILL doesn't have any info,
collect_signal() sets SI_USER and clears si_errno in this case.
Oleg.
Re: [PATCH 3/6] y2038: linux: Provide __clock_settime64 implementation
Hi Stepan,
> 15.04.2019 в 00:08:38 +0200 Lukasz Majewski написал:
> > +# if defined __NR_clock_settime64
> > + /* Make sure that passed __timespec64 struct pad is 0. */
> > + struct __timespec64 ts = *tp;
> > + ts.tv_pad = 0;
> > + return INLINE_SYSCALL_CALL (clock_settime64, clock_id, );
>
> Isn't kernel supposed to zero out padding on its own?
> At least comment in kernel's get_timespec64 says so:
>
> /* Zero out the padding for 32 bit systems or in compat mode
> */ if (IS_ENABLED(CONFIG_64BIT_TIME) && in_compat_syscall())
> kts.tv_nsec &= 0xUL;
>
For ARM (and x86) 32 bit machines I do use following syscalls (like
clock_settime64):
https://elixir.bootlin.com/linux/v5.1-rc4/source/arch/arm/tools/syscall.tbl#L420
which are providing 64 bit time support on 32 bit systems.
Yes. In those systems the upper part (32 bits) of tv_nsec is cleared up
with mask in the kernel. However, I would prefer not to pass random data
to the kernel, and hence I do clear it up explicitly in glibc.
> The code looks buggy though. It fails to zero out the padding in
> 32-bit kernels.
For the 32 bit systems without Y2038 support enabled in glibc - the
clock_settime would be used, which corresponds to sys_clock_settime32()
in the kernel.
> That part is probably broken since
> 98f76206b3350 ("compat: Cleanup in_compat_syscall() callers").
>
> And, hmm, is CONFIG_64BIT_TIME enabled anywhere?
When I do use clock_settime64 on the glibc side (with _TIME_BITS=64), I
do not need to enable such config in the kernel.
If the kernel supports this call (5.1+), then use it, otherwise
fallback to clock_settime().
For 64 bit systems, I do not change the execution path.
If you are interested, please look on the following repo (which has
some more commits than those posted to the mailing list):
https://github.com/lmajewski/y2038_glibc/commits/Y2038-2.29-glibc-__clock-internal-struct-timespec-v1
And meta layer for testing.
https://github.com/lmajewski/meta-y2038
Best regards,
Lukasz Majewski
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lu...@denx.de
pgpTWLzGj6GDd.pgp
Description: OpenPGP digital signature
Re: RFC: on adding new CLONE_* flags [WAS Re: [PATCH 0/4] clone: add CLONE_PIDFD]
On April 20, 2019 9:14:06 AM GMT+02:00, Kevin Easton wrote: >On Mon, Apr 15, 2019 at 01:29:23PM -0700, Andy Lutomirski wrote: >> On Mon, Apr 15, 2019 at 12:59 PM Aleksa Sarai >wrote: >> > >> > On 2019-04-15, Enrico Weigelt, metux IT consult >wrote: >> > > > This patchset makes it possible to retrieve pid file >descriptors at >> > > > process creation time by introducing the new flag CLONE_PIDFD >to the >> > > > clone() system call as previously discussed. >> > > >> > > Sorry, for highjacking this thread, but I'm curious on what >things to >> > > consider when introducing new CLONE_* flags. >> > > >> > > The reason I'm asking is: >> > > >> > > I'm working on implementing plan9-like fs namespaces, where >unprivileged >> > > processes can change their own namespace at will. For that, >certain >> > > traditional unix'ish things have to be disabled, most notably >suid. >> > > As forbidding suid can be helpful in other scenarios, too, I >thought >> > > about making this its own feature. Doing that switch on clone() >seems >> > > a nice place for that, IMHO. >> > >> > Just spit-balling -- is no_new_privs not sufficient for this >usecase? >> > Not granting privileges such as setuid during execve(2) is the main >> > point of that flag. >> > >> >> I would personally *love* it if distros started setting no_new_privs >> for basically all processes. And pidfd actually gets us part of the >> way toward a straightforward way to make sudo and su still work in a >> no_new_privs world: su could call into a daemon that would spawn the >> privileged task, and su would get a (read-only!) pidfd back and then >> wait for the fd and exit. I suppose that, done naively, this might >> cause some odd effects with respect to tty handling, but I bet it's >> solveable. I suppose it would be nifty if there were a way for a >> process, by mutual agreement, to reparent itself to an unrelated >> process. >> >> Anyway, clone(2) is an enormous mess. Surely the right solution here >> is to have a whole new process creation API that takes a big, >> extensible struct as an argument, and supports *at least* the full >> abilities of posix_spawn() and ideally covers all the use cases for >> fork() + do stuff + exec(). It would be nifty if this API also had a >> way to say "add no_new_privs and therefore enable extra functionality >> that doesn't work without no_new_privs". This functionality would >> include things like returning a future extra-privileged pidfd that >> gives ptrace-like access. >> >> As basic examples, the improved process creation API should take a >> list of dup2() operations to perform, fds to remove the O_CLOEXEC >flag >> from, fds to close (or, maybe even better, a list of fds to *not* >> close), a list of rlimit changes to make, a list of signal changes to >> make, the ability to set sid, pgrp, uid, gid (as in >> setresuid/setresgid), the ability to do capset() operations, etc. >The >> posix_spawn() API, for all that it's rather complicated, covers a >> bunch of the basics pretty well. > >The idea of a system call that takes an infinitely-extendable laundry >list of operations to perform in kernel space seems quite inelegant, if >only for the error-reporting reason. > >Instead, I suggest that what you'd want is a way to create a new >embryonic process that has no address space and isn't yet schedulable. >You then just need other-process-directed variants of all the normal >setup functions - so pr_openat(pidfd, dirfd, pathname, flags, mode), >pr_sigaction(pidfd, signum, act, oldact), pr_dup2(pidfd, oldfd, newfd) >etc. > >Then when it's all set up you pr_execve() to kick it off. > >- Kevin I proposed a version of this a while back when we first started talking about this.
Re: [PATCH v10 4/9] cgroup: cgroup v2 freezer
On 04/19, Roman Gushchin wrote:
>
> > > >
> > > > wake_up_interruptible() ?
> > >
> > > Wait_up_interruptible() is supposed to work with a workqueue,
> > > but here there is nothing like this. Probably, I didn't understand your
> > > idea.
> > > Can you, please, elaborate a bit more?
> >
> > Not sure I understand... We need to wake up the task if it sleeps in
> > do_freezer_trap(), right? do_freezer_trap() uses TASK_INTERRUPTIBLE, so
> > why can't wake_up_interruptible() == __wake_up(TASK_INTERRUPTIBLE) work?
>
> Right, but __wake_up is supposed to wake threads blocked on a waitqueue:
Ugh sorry ;) of course I meant wake_up_state(task, TASK_INTERRUPTIBLE).
> > > > > + if (unlikely(cgroup_task_frozen(current))) {
> > > > > spin_unlock_irq(>siglock);
> > > > > + cgroup_leave_frozen(true);
> > > > > goto relock;
> > > > > }
> > > >
> > > > afaics cgroup_leave_frozen(false) makes more sense here.
> > >
> > > Why? I don't see any reasons why the task should remain in the frozen
> > > state after this point.
> >
> > But cgroup_leave_frozen(false) will equally clear ->frozen if !CGRP_FREEZE ?
> > OTOH, if CGRP_FREEZE is set again, why do we need to clear ->frozen?
>
> Hm, it might work too, but I'm not sure I like it more. IMO, the best option
> is to have a single cgroup_leave_frozen(true) in signal.c, it's just simpler.
> If a user changed the desired state of cgroup twice, there is no need to avoid
> state transitions. Or maybe I don't see it yet.
Then why do we need cgroup_leave_frozen(false) in wait_for_vfork_done() ? How
does it differ from get_signal() ?
If nothing else. Suppose that wait_for_vfork_done() calls leave(false) and this
races with freezer, CGRP_FREEZE is already set but JOBCTL_TRAP_FREEZE is not.
This sets TIF_SIGPENDING to ensure the task won't return to user mode, thus it
calls get_signal().
get_signal() doesn't see JOBCTL_TRAP_FREEZE, it notices ->frozen == T and does
cgroup_leave_frozen(true) which clears ->frozen.
Then the task calls dequeue_signal(), clears TIF_SIGPENDING and returns to user
mode?
Oleg.
[PATCH 3/3] ASoC: simple-card: Read pin switches conf from devicetree
When the routing path between a widget (e.g. "Speaker") and the codec
goes through an external amplifier, having a pin switch for this widget
allows the amplifier to be disabled when the widget is not to be used
(e.g. when using headphones).
Signed-off-by: Paul Cercueil
---
sound/soc/generic/simple-card.c | 4
1 file changed, 4 insertions(+)
diff --git a/sound/soc/generic/simple-card.c b/sound/soc/generic/simple-card.c
index 34de32efc4c4..d34adb1518e7 100644
--- a/sound/soc/generic/simple-card.c
+++ b/sound/soc/generic/simple-card.c
@@ -556,6 +556,10 @@ static int simple_parse_of(struct simple_priv *priv)
if (ret < 0)
return ret;
+ ret = asoc_simple_card_of_parse_pin_switches(card, PREFIX);
+ if (ret < 0)
+ return ret;
+
/* Single/Muti DAI link(s) & New style of DT node */
memset(, 0, sizeof(li));
for (li.cpu = 1; li.cpu >= 0; li.cpu--) {
--
2.21.0.593.g511ec345e18
[PATCH 2/3] ASoC: simple-card-utils: add asoc_simple_card_of_parse_pin_switches()
This function is a helper that permits to create pin switch controls for
a list of widgets whose names are listed in the PREFIX "pin-switches"
devicetree property.
Signed-off-by: Paul Cercueil
---
include/sound/simple_card_utils.h | 2 +
sound/soc/generic/simple-card-utils.c | 57 +++
2 files changed, 59 insertions(+)
diff --git a/include/sound/simple_card_utils.h
b/include/sound/simple_card_utils.h
index 7afe45389972..8a56c1713952 100644
--- a/include/sound/simple_card_utils.h
+++ b/include/sound/simple_card_utils.h
@@ -124,6 +124,8 @@ int asoc_simple_card_of_parse_routing(struct snd_soc_card
*card,
char *prefix);
int asoc_simple_card_of_parse_widgets(struct snd_soc_card *card,
char *prefix);
+int asoc_simple_card_of_parse_pin_switches(struct snd_soc_card *card,
+ char *prefix);
int asoc_simple_card_init_jack(struct snd_soc_card *card,
struct asoc_simple_jack *sjack,
diff --git a/sound/soc/generic/simple-card-utils.c
b/sound/soc/generic/simple-card-utils.c
index 5c1424f03620..431002e3e63f 100644
--- a/sound/soc/generic/simple-card-utils.c
+++ b/sound/soc/generic/simple-card-utils.c
@@ -469,6 +469,63 @@ int asoc_simple_card_of_parse_widgets(struct snd_soc_card
*card,
}
EXPORT_SYMBOL_GPL(asoc_simple_card_of_parse_widgets);
+int asoc_simple_card_of_parse_pin_switches(struct snd_soc_card *card,
+ char *prefix)
+{
+ const unsigned int nb_controls_max = 16;
+ const char **strings, *control_name;
+ struct snd_kcontrol_new *controls;
+ struct device *dev = card->dev;
+ unsigned int i, nb_controls;
+ char prop[128];
+ int ret;
+
+ if (!prefix)
+ prefix = "";
+
+ snprintf(prop, sizeof(prop), "%s%s", prefix, "pin-switches");
+
+ if (!of_property_read_bool(dev->of_node, prop))
+ return 0;
+
+ strings = devm_kcalloc(dev, nb_controls_max,
+ sizeof(*strings), GFP_KERNEL);
+ if (!strings)
+ return -ENOMEM;
+
+ ret = of_property_read_string_array(dev->of_node, prop,
+ strings, nb_controls_max);
+ if (ret < 0)
+ return ret;
+
+ nb_controls = (unsigned int)ret;
+
+ controls = devm_kcalloc(dev, nb_controls,
+ sizeof(*controls), GFP_KERNEL);
+ if (!controls)
+ return -ENOMEM;
+
+ for (i = 0; i < nb_controls; i++) {
+ control_name = devm_kasprintf(dev, GFP_KERNEL,
+ "%s Switch", strings[i]);
+ if (!control_name)
+ return -ENOMEM;
+
+ controls[i].iface = SNDRV_CTL_ELEM_IFACE_MIXER;
+ controls[i].name = control_name;
+ controls[i].info = snd_soc_dapm_info_pin_switch;
+ controls[i].get = snd_soc_dapm_get_pin_switch;
+ controls[i].put = snd_soc_dapm_put_pin_switch;
+ controls[i].private_value = (unsigned long)strings[i];
+ }
+
+ card->controls = controls;
+ card->num_controls = nb_controls;
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(asoc_simple_card_of_parse_pin_switches);
+
int asoc_simple_card_init_jack(struct snd_soc_card *card,
struct asoc_simple_jack *sjack,
int is_hp, char *prefix)
--
2.21.0.593.g511ec345e18
[PATCH 1/3] ASoC: doc: simple-card: Add pin-switches property
The simple-audio-card,pin-switches property can contain the list of widget names for which pin switches must be created. Signed-off-by: Paul Cercueil --- Documentation/devicetree/bindings/sound/simple-card.txt | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/devicetree/bindings/sound/simple-card.txt b/Documentation/devicetree/bindings/sound/simple-card.txt index 4629c8f8a6b6..79954cd6e37b 100644 --- a/Documentation/devicetree/bindings/sound/simple-card.txt +++ b/Documentation/devicetree/bindings/sound/simple-card.txt @@ -24,6 +24,8 @@ Optional properties: a microphone is attached. - simple-audio-card,aux-devs : List of phandles pointing to auxiliary devices, such as amplifiers, to be added to the sound card. +- simple-audio-card,pin-switches : List of strings containing the widget names for + which pin switches must be created. Optional subnodes: -- 2.21.0.593.g511ec345e18
[PATCH] signal: trace_signal_deliver when signal_group_exit
In the following commit, removing SIGKILL from each thread signal mask
and executing "goto fatal" directly will skip the call to
"trace_signal_deliver". At this point, the delivery tracking of the SIGKILL
signal will be inaccurate.
commit cf43a757fd4944 ("signal: Restore the stop PTRACE_EVENT_EXIT")
Therefore, we need to add trace_signal_deliver before "goto fatal"
after executing sigdelset.
Signed-off-by: Zhenliang Wei
---
kernel/signal.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/kernel/signal.c b/kernel/signal.c
index 227ba170298e..439b742e3229 100644
--- a/kernel/signal.c
+++ b/kernel/signal.c
@@ -2441,6 +2441,8 @@ bool get_signal(struct ksignal *ksig)
if (signal_group_exit(signal)) {
ksig->info.si_signo = signr = SIGKILL;
sigdelset(>pending.signal, SIGKILL);
+ trace_signal_deliver(signr, >info,
+ >action[signr - 1]);
recalc_sigpending();
goto fatal;
}
--
2.14.1.windows.1
Re: [PATCH] x86/mpx: fix recursive munmap() corruption
Thomas Gleixner writes:
> On Mon, 1 Apr 2019, Dave Hansen wrote:
>> diff -puN mm/mmap.c~mpx-rss-pass-no-vma mm/mmap.c
>> --- a/mm/mmap.c~mpx-rss-pass-no-vma 2019-04-01 06:56:53.409411123 -0700
>> +++ b/mm/mmap.c 2019-04-01 06:56:53.423411123 -0700
>> @@ -2731,9 +2731,17 @@ int __do_munmap(struct mm_struct *mm, un
>> return -EINVAL;
>>
>> len = PAGE_ALIGN(len);
>> +end = start + len;
>> if (len == 0)
>> return -EINVAL;
>>
>> +/*
>> + * arch_unmap() might do unmaps itself. It must be called
>> + * and finish any rbtree manipulation before this code
>> + * runs and also starts to manipulate the rbtree.
>> + */
>> +arch_unmap(mm, start, end);
>
> ...
>
>> -static inline void arch_unmap(struct mm_struct *mm, struct vm_area_struct
>> *vma,
>> - unsigned long start, unsigned long end)
>> +static inline void arch_unmap(struct mm_struct *mm, unsigned long start,
>> + unsigned long end)
>
> While you fixed up the asm-generic thing, this breaks arch/um and
> arch/unicorn32. For those the fixup is trivial by removing the vma
> argument.
>
> But itt also breaks powerpc and there I'm not sure whether moving
> arch_unmap() to the beginning of __do_munmap() is safe. Micheal???
I don't know for sure but I think it should be fine. That code is just
there to handle CRIU unmapping/remapping the VDSO. So that either needs
to happen while the process is stopped or it needs to handle races
anyway, so I don't see how the placement within the unmap path should
matter.
> Aside of that the powerpc variant looks suspicious:
>
> static inline void arch_unmap(struct mm_struct *mm,
> unsigned long start, unsigned long end)
> {
> if (start <= mm->context.vdso_base && mm->context.vdso_base < end)
> mm->context.vdso_base = 0;
> }
>
> Shouldn't that be:
>
> if (start >= mm->context.vdso_base && mm->context.vdso_base < end)
>
> Hmm?
Yeah looks pretty suspicious. I'll follow-up with Laurent who wrote it.
Thanks for spotting it!
cheers
[tip:ras/core] RAS/CEC: Increment cec_entered under the mutex lock
Commit-ID: 09cbd2197e9291d6a3d3f42873f06ca1f388c1a4 Gitweb: https://git.kernel.org/tip/09cbd2197e9291d6a3d3f42873f06ca1f388c1a4 Author: WANG Chao AuthorDate: Thu, 18 Apr 2019 03:41:14 + Committer: Borislav Petkov CommitDate: Sat, 20 Apr 2019 12:16:52 +0200 RAS/CEC: Increment cec_entered under the mutex lock Modify ->cec_entered in the critical section of the mutex. Signed-off-by: WANG Chao Signed-off-by: Borislav Petkov Cc: Tony Luck Cc: linux-edac Link: https://lkml.kernel.org/r/20190418034115.75954-2-chao.w...@ucloud.cn --- drivers/ras/cec.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/ras/cec.c b/drivers/ras/cec.c index 2d9ec378a8bc..88e4f3ff0cb8 100644 --- a/drivers/ras/cec.c +++ b/drivers/ras/cec.c @@ -286,10 +286,10 @@ int cec_add_elem(u64 pfn) if (!ce_arr.array || ce_arr.disabled) return -ENODEV; - ca->ces_entered++; - mutex_lock(_mutex); + ca->ces_entered++; + if (ca->n == MAX_ELEMS) WARN_ON(!del_lru_elem_unlocked(ca));
[tip:ras/core] RAS/CEC: Increment cec_entered under the mutex lock
Commit-ID: 06e0fe2d8e9178bda874a75083bc13647fbf983f Gitweb: https://git.kernel.org/tip/06e0fe2d8e9178bda874a75083bc13647fbf983f Author: WANG Chao AuthorDate: Thu, 18 Apr 2019 03:41:14 + Committer: Borislav Petkov CommitDate: Sat, 20 Apr 2019 12:13:13 +0200 RAS/CEC: Increment cec_entered under the mutex lock Modify ->cec_entered in the critical section of the mutex. Signed-off-by: WANG Chao Signed-off-by: Borislav Petkov Cc: Tony Luck Cc: linux-edac Link: https://lkml.kernel.org/r/20190418034115.75954-2-chao.w...@ucloud.cn --- drivers/ras/cec.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/ras/cec.c b/drivers/ras/cec.c index 2d9ec378a8bc..88e4f3ff0cb8 100644 --- a/drivers/ras/cec.c +++ b/drivers/ras/cec.c @@ -286,10 +286,10 @@ int cec_add_elem(u64 pfn) if (!ce_arr.array || ce_arr.disabled) return -ENODEV; - ca->ces_entered++; - mutex_lock(_mutex); + ca->ces_entered++; + if (ca->n == MAX_ELEMS) WARN_ON(!del_lru_elem_unlocked(ca));
[PATCH v7 09/14] irqchip: ti-sci-intr: Add support for Interrupt Router driver
Texas Instruments' K3 generation SoCs has an IP Interrupt Router
that does allows for redirection of input interrupts to host
interrupt controller. Interrupt Router inputs are either from a
peripheral or from an Interrupt Aggregator which is another
interrupt controller.
Configuration of the interrupt router registers can only be done by
a system co-processor and the driver needs to send a message to this
co processor over TISCI protocol.
Add support for Interrupt Router driver over TISCI protocol.
Signed-off-by: Lokesh Vutla
---
Changes since v6:
- Arranged header files in alphabetical order
- Dropped few unused members in ti_sci_intr_irq_domain structure
MAINTAINERS | 1 +
drivers/irqchip/Kconfig | 11 ++
drivers/irqchip/Makefile | 1 +
drivers/irqchip/irq-ti-sci-intr.c | 285 ++
4 files changed, 298 insertions(+)
create mode 100644 drivers/irqchip/irq-ti-sci-intr.c
diff --git a/MAINTAINERS b/MAINTAINERS
index b40762656a6d..63851f106b5c 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -15350,6 +15350,7 @@ F:
Documentation/devicetree/bindings/clock/ti,sci-clk.txt
F: drivers/clk/keystone/sci-clk.c
F: drivers/reset/reset-ti-sci.c
F: Documentation/devicetree/bindings/interrupt-controller/ti,sci-intr.txt
+F: drivers/irqchip/irq-ti-sci-intr.c
Texas Instruments ASoC drivers
M: Peter Ujfalusi
diff --git a/drivers/irqchip/Kconfig b/drivers/irqchip/Kconfig
index 5438abb1baba..4f84e7902626 100644
--- a/drivers/irqchip/Kconfig
+++ b/drivers/irqchip/Kconfig
@@ -425,6 +425,17 @@ config LS1X_IRQ
help
Support for the Loongson-1 platform Interrupt Controller.
+config TI_SCI_INTR_IRQCHIP
+ bool
+ depends on TI_SCI_PROTOCOL
+ select IRQ_DOMAIN
+ select IRQ_DOMAIN_HIERARCHY
+ help
+ This enables the irqchip driver support for K3 Interrupt router
+ over TI System Control Interface available on some new TI's SoCs.
+ If you wish to use interrupt router irq resources managed by the
+ TI System Controller, say Y here. Otherwise, say N.
+
endmenu
config SIFIVE_PLIC
diff --git a/drivers/irqchip/Makefile b/drivers/irqchip/Makefile
index 85972ae1bd7f..fa5c865788b5 100644
--- a/drivers/irqchip/Makefile
+++ b/drivers/irqchip/Makefile
@@ -97,3 +97,4 @@ obj-$(CONFIG_SIFIVE_PLIC) += irq-sifive-plic.o
obj-$(CONFIG_IMX_IRQSTEER) += irq-imx-irqsteer.o
obj-$(CONFIG_MADERA_IRQ) += irq-madera.o
obj-$(CONFIG_LS1X_IRQ) += irq-ls1x.o
+obj-$(CONFIG_TI_SCI_INTR_IRQCHIP) += irq-ti-sci-intr.o
diff --git a/drivers/irqchip/irq-ti-sci-intr.c
b/drivers/irqchip/irq-ti-sci-intr.c
new file mode 100644
index ..354b9d53798d
--- /dev/null
+++ b/drivers/irqchip/irq-ti-sci-intr.c
@@ -0,0 +1,285 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Texas Instruments' K3 Interrupt Router irqchip driver
+ *
+ * Copyright (C) 2018-2019 Texas Instruments Incorporated - http://www.ti.com/
+ * Lokesh Vutla
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define TI_SCI_DEV_ID_MASK 0x
+#define TI_SCI_DEV_ID_SHIFT16
+#define TI_SCI_IRQ_ID_MASK 0x
+#define TI_SCI_IRQ_ID_SHIFT0
+#define HWIRQ_TO_DEVID(hwirq) (((hwirq) >> (TI_SCI_DEV_ID_SHIFT)) & \
+(TI_SCI_DEV_ID_MASK))
+#define HWIRQ_TO_IRQID(hwirq) ((hwirq) & (TI_SCI_IRQ_ID_MASK))
+#define TO_HWIRQ(dev, index) dev) & TI_SCI_DEV_ID_MASK) << \
+TI_SCI_DEV_ID_SHIFT) | \
+ ((index) & TI_SCI_IRQ_ID_MASK))
+
+/**
+ * struct ti_sci_intr_irq_domain - Structure representing a TISCI based
+ *Interrupt Router IRQ domain.
+ * @sci: Pointer to TISCI handle
+ * @dst_irq: TISCI resource pointer representing GIC irq controller.
+ * @dst_id:TISCI device ID of the GIC irq controller.
+ * @type: Specifies the trigger type supported by this Interrupt Router
+ */
+struct ti_sci_intr_irq_domain {
+ const struct ti_sci_handle *sci;
+ struct ti_sci_resource *dst_irq;
+ u32 dst_id;
+ u32 type;
+};
+
+static struct irq_chip ti_sci_intr_irq_chip = {
+ .name = "INTR",
+ .irq_eoi= irq_chip_eoi_parent,
+ .irq_mask = irq_chip_mask_parent,
+ .irq_unmask = irq_chip_unmask_parent,
+ .irq_set_type = irq_chip_set_type_parent,
+ .irq_retrigger = irq_chip_retrigger_hierarchy,
+ .irq_set_affinity = irq_chip_set_affinity_parent,
+};
+
+/**
+ * ti_sci_intr_irq_domain_translate() - Retrieve hwirq and type from
+ * IRQ firmware specific handler.
+ * @domain:Pointer to IRQ domain
+ * @fwspec:Pointer to IRQ specific firmware structure
+ * @hwirq: IRQ number
[PATCH v7 13/14] irqchip: ti-sci-inta: Add msi domain support
Add a msi domain that is child to the INTA domain. Clients
uses the INTA msi bus layer to allocate irqs in this
msi domain.
Signed-off-by: Lokesh Vutla
---
Changes since v6:
- Updated to get device id from platform device.
drivers/irqchip/Kconfig | 1 +
drivers/irqchip/irq-ti-sci-inta.c | 40 ++-
2 files changed, 40 insertions(+), 1 deletion(-)
diff --git a/drivers/irqchip/Kconfig b/drivers/irqchip/Kconfig
index 7c84a71bcd88..1fab40487d63 100644
--- a/drivers/irqchip/Kconfig
+++ b/drivers/irqchip/Kconfig
@@ -441,6 +441,7 @@ config TI_SCI_INTA_IRQCHIP
depends on TI_SCI_PROTOCOL
select IRQ_DOMAIN
select IRQ_DOMAIN_HIERARCHY
+ select TI_SCI_INTA_MSI_DOMAIN
help
This enables the irqchip driver support for K3 Interrupt aggregator
over TI System Control Interface available on some new TI's SoCs.
diff --git a/drivers/irqchip/irq-ti-sci-inta.c
b/drivers/irqchip/irq-ti-sci-inta.c
index 71e5b45ab4ce..53a356795ebf 100644
--- a/drivers/irqchip/irq-ti-sci-inta.c
+++ b/drivers/irqchip/irq-ti-sci-inta.c
@@ -18,6 +18,7 @@
#include
#include
#include
+#include
#include
#include
@@ -28,6 +29,9 @@
#define HWIRQ_TO_DEVID(hwirq) (((hwirq) >> (TI_SCI_DEV_ID_SHIFT)) & \
(TI_SCI_DEV_ID_MASK))
#define HWIRQ_TO_IRQID(hwirq) ((hwirq) & (TI_SCI_IRQ_ID_MASK))
+#define TO_HWIRQ(dev, index) dev) & TI_SCI_DEV_ID_MASK) << \
+TI_SCI_DEV_ID_SHIFT) | \
+ ((index) & TI_SCI_IRQ_ID_MASK))
#define MAX_EVENTS_PER_VINT64
#define VINT_ENABLE_SET_OFFSET 0x0
@@ -496,9 +500,34 @@ static const struct irq_domain_ops
ti_sci_inta_irq_domain_ops = {
.alloc = ti_sci_inta_irq_domain_alloc,
};
+static struct irq_chip ti_sci_inta_msi_irq_chip = {
+ .name = "MSI-INTA",
+ .flags = IRQCHIP_SUPPORTS_LEVEL_MSI,
+};
+
+static void ti_sci_inta_msi_set_desc(msi_alloc_info_t *arg,
+struct msi_desc *desc)
+{
+ struct platform_device *pdev = to_platform_device(desc->dev);
+
+ arg->desc = desc;
+ arg->hwirq = TO_HWIRQ(pdev->id, desc->inta.dev_index);
+}
+
+static struct msi_domain_ops ti_sci_inta_msi_ops = {
+ .set_desc = ti_sci_inta_msi_set_desc,
+};
+
+static struct msi_domain_info ti_sci_inta_msi_domain_info = {
+ .flags = (MSI_FLAG_USE_DEF_DOM_OPS | MSI_FLAG_USE_DEF_CHIP_OPS |
+ MSI_FLAG_LEVEL_CAPABLE),
+ .ops= _sci_inta_msi_ops,
+ .chip = _sci_inta_msi_irq_chip,
+};
+
static int ti_sci_inta_irq_domain_probe(struct platform_device *pdev)
{
- struct irq_domain *parent_domain, *domain;
+ struct irq_domain *parent_domain, *domain, *msi_domain;
struct device_node *parent_node, *node;
struct ti_sci_inta_irq_domain *inta;
struct device *dev = >dev;
@@ -563,6 +592,15 @@ static int ti_sci_inta_irq_domain_probe(struct
platform_device *pdev)
return -ENOMEM;
}
+ msi_domain = ti_sci_inta_msi_create_irq_domain(of_node_to_fwnode(node),
+ _sci_inta_msi_domain_info,
+ domain);
+ if (!msi_domain) {
+ irq_domain_remove(domain);
+ dev_err(dev, "Failed to allocate msi domain\n");
+ return -ENOMEM;
+ }
+
INIT_LIST_HEAD(>vint_list);
mutex_init(>vint_mutex);
--
2.21.0
[PATCH v7 12/14] soc: ti: Add MSI domain bus support for Interrupt Aggregator
With the system coprocessor managing the range allocation of the
inputs to Interrupt Aggregator, it is difficult to represent
the device IRQs from DT.
The suggestion is to use MSI in such cases where devices wants
to allocate and group interrupts dynamically.
Create a MSI domain bus layer that allocates and frees MSIs for
a device.
APIs that are implemented:
- ti_sci_inta_msi_create_irq_domain() that creates a MSI domain
- ti_sci_inta_msi_domain_alloc_irqs() that creates MSIs for the
specified device and resource.
- ti_sci_inta_msi_domain_free_irqs() frees the irqs attached to the device.
- ti_sci_inta_msi_get_virq() for getting the virq attached to a specific event.
Signed-off-by: Lokesh Vutla
---
Changes since v6:
- Arranged header files in alphabetical order.
- Dropped dev_id from struct ti_sci_inta_msi_desc
- Renamed index to dev_index in struct ti_sci_inta_msi_desc
- Fixed few cosmetic changes.
MAINTAINERS| 2 +
drivers/soc/ti/Kconfig | 6 +
drivers/soc/ti/Makefile| 1 +
drivers/soc/ti/ti_sci_inta_msi.c | 146 +
include/linux/irqdomain.h | 1 +
include/linux/msi.h| 10 ++
include/linux/soc/ti/ti_sci_inta_msi.h | 23
7 files changed, 189 insertions(+)
create mode 100644 drivers/soc/ti/ti_sci_inta_msi.c
create mode 100644 include/linux/soc/ti/ti_sci_inta_msi.h
diff --git a/MAINTAINERS b/MAINTAINERS
index 055467fb2019..96159e502e6c 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -15353,6 +15353,8 @@ F:
Documentation/devicetree/bindings/interrupt-controller/ti,sci-intr.txt
F: Documentation/devicetree/bindings/interrupt-controller/ti,sci-inta.txt
F: drivers/irqchip/irq-ti-sci-intr.c
F: drivers/irqchip/irq-ti-sci-inta.c
+F: include/linux/soc/ti/ti_sci_inta_msi.h
+F: drivers/soc/ti/ti_sci_inta_msi.c
Texas Instruments ASoC drivers
M: Peter Ujfalusi
diff --git a/drivers/soc/ti/Kconfig b/drivers/soc/ti/Kconfig
index be4570baad96..82f110fe4953 100644
--- a/drivers/soc/ti/Kconfig
+++ b/drivers/soc/ti/Kconfig
@@ -73,4 +73,10 @@ config TI_SCI_PM_DOMAINS
called ti_sci_pm_domains. Note this is needed early in boot before
rootfs may be available.
+config TI_SCI_INTA_MSI_DOMAIN
+ bool
+ select GENERIC_MSI_IRQ_DOMAIN
+ help
+ Driver to enable Interrupt Aggregator specific MSI Domain.
+
endif # SOC_TI
diff --git a/drivers/soc/ti/Makefile b/drivers/soc/ti/Makefile
index a22edc0b258a..b3868d392d4f 100644
--- a/drivers/soc/ti/Makefile
+++ b/drivers/soc/ti/Makefile
@@ -8,3 +8,4 @@ obj-$(CONFIG_KEYSTONE_NAVIGATOR_DMA)+= knav_dma.o
obj-$(CONFIG_AMX3_PM) += pm33xx.o
obj-$(CONFIG_WKUP_M3_IPC) += wkup_m3_ipc.o
obj-$(CONFIG_TI_SCI_PM_DOMAINS)+= ti_sci_pm_domains.o
+obj-$(CONFIG_TI_SCI_INTA_MSI_DOMAIN) += ti_sci_inta_msi.o
diff --git a/drivers/soc/ti/ti_sci_inta_msi.c b/drivers/soc/ti/ti_sci_inta_msi.c
new file mode 100644
index ..0eb9462f609e
--- /dev/null
+++ b/drivers/soc/ti/ti_sci_inta_msi.c
@@ -0,0 +1,146 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Texas Instruments' K3 Interrupt Aggregator MSI bus
+ *
+ * Copyright (C) 2018-2019 Texas Instruments Incorporated - http://www.ti.com/
+ * Lokesh Vutla
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+static void ti_sci_inta_msi_write_msg(struct irq_data *data,
+ struct msi_msg *msg)
+{
+ /* Nothing to do */
+}
+
+static void ti_sci_inta_msi_compose_msi_msg(struct irq_data *data,
+ struct msi_msg *msg)
+{
+ /* Nothing to do */
+}
+
+static void ti_sci_inta_msi_update_chip_ops(struct msi_domain_info *info)
+{
+ struct irq_chip *chip = info->chip;
+
+ if (WARN_ON(!chip))
+ return;
+
+ chip->irq_request_resources = irq_chip_request_resources_parent;
+ chip->irq_release_resources = irq_chip_release_resources_parent;
+ chip->irq_compose_msi_msg = ti_sci_inta_msi_compose_msi_msg;
+ chip->irq_write_msi_msg = ti_sci_inta_msi_write_msg;
+ chip->irq_set_type = irq_chip_set_type_parent;
+ chip->irq_unmask = irq_chip_unmask_parent;
+ chip->irq_mask = irq_chip_mask_parent;
+ chip->irq_ack = irq_chip_ack_parent;
+}
+
+struct irq_domain *ti_sci_inta_msi_create_irq_domain(struct fwnode_handle
*fwnode,
+struct msi_domain_info
*info,
+struct irq_domain *parent)
+{
+ struct irq_domain *domain;
+
+ ti_sci_inta_msi_update_chip_ops(info);
+
+ domain = msi_create_irq_domain(fwnode, info, parent);
+ if (domain)
+ irq_domain_update_bus_token(domain, DOMAIN_BUS_TI_SCI_INTA_MSI);
+
+ return domain;
+}
[PATCH v7 11/14] irqchip: ti-sci-inta: Add support for Interrupt Aggregator driver
Texas Instruments' K3 generation SoCs has an IP Interrupt Aggregator
which is an interrupt controller that does the following:
- Converts events to interrupts that can be understood by
an interrupt router.
- Allows for multiplexing of events to interrupts.
Configuration of the interrupt aggregator registers can only be done by
a system co-processor and the driver needs to send a message to this
co processor over TISCI protocol. This patch adds support for Interrupt
Aggregator irqdomain.
Signed-off-by: Lokesh Vutla
---
Changes since v6:
- Updated commit message.
- Arranged header files in alphabetical order
- Included vint_bit in struct ti_sci_inta_event_desc
- With the above change now the chip_data is event_desc instead of vint_desc
- No loops are used in atomic contexts.
- Fixed locking issue while freeing parent virq
- Fixed few other cosmetic changes.
MAINTAINERS | 1 +
drivers/irqchip/Kconfig | 11 +
drivers/irqchip/Makefile | 1 +
drivers/irqchip/irq-ti-sci-inta.c | 589 ++
4 files changed, 602 insertions(+)
create mode 100644 drivers/irqchip/irq-ti-sci-inta.c
diff --git a/MAINTAINERS b/MAINTAINERS
index 461db0a8233f..055467fb2019 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -15352,6 +15352,7 @@ F: drivers/reset/reset-ti-sci.c
F: Documentation/devicetree/bindings/interrupt-controller/ti,sci-intr.txt
F: Documentation/devicetree/bindings/interrupt-controller/ti,sci-inta.txt
F: drivers/irqchip/irq-ti-sci-intr.c
+F: drivers/irqchip/irq-ti-sci-inta.c
Texas Instruments ASoC drivers
M: Peter Ujfalusi
diff --git a/drivers/irqchip/Kconfig b/drivers/irqchip/Kconfig
index 4f84e7902626..7c84a71bcd88 100644
--- a/drivers/irqchip/Kconfig
+++ b/drivers/irqchip/Kconfig
@@ -436,6 +436,17 @@ config TI_SCI_INTR_IRQCHIP
If you wish to use interrupt router irq resources managed by the
TI System Controller, say Y here. Otherwise, say N.
+config TI_SCI_INTA_IRQCHIP
+ bool
+ depends on TI_SCI_PROTOCOL
+ select IRQ_DOMAIN
+ select IRQ_DOMAIN_HIERARCHY
+ help
+ This enables the irqchip driver support for K3 Interrupt aggregator
+ over TI System Control Interface available on some new TI's SoCs.
+ If you wish to use interrupt aggregator irq resources managed by the
+ TI System Controller, say Y here. Otherwise, say N.
+
endmenu
config SIFIVE_PLIC
diff --git a/drivers/irqchip/Makefile b/drivers/irqchip/Makefile
index fa5c865788b5..8a33013da953 100644
--- a/drivers/irqchip/Makefile
+++ b/drivers/irqchip/Makefile
@@ -98,3 +98,4 @@ obj-$(CONFIG_IMX_IRQSTEER)+= irq-imx-irqsteer.o
obj-$(CONFIG_MADERA_IRQ) += irq-madera.o
obj-$(CONFIG_LS1X_IRQ) += irq-ls1x.o
obj-$(CONFIG_TI_SCI_INTR_IRQCHIP) += irq-ti-sci-intr.o
+obj-$(CONFIG_TI_SCI_INTA_IRQCHIP) += irq-ti-sci-inta.o
diff --git a/drivers/irqchip/irq-ti-sci-inta.c
b/drivers/irqchip/irq-ti-sci-inta.c
new file mode 100644
index ..71e5b45ab4ce
--- /dev/null
+++ b/drivers/irqchip/irq-ti-sci-inta.c
@@ -0,0 +1,589 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Texas Instruments' K3 Interrupt Aggregator irqchip driver
+ *
+ * Copyright (C) 2018-2019 Texas Instruments Incorporated - http://www.ti.com/
+ * Lokesh Vutla
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define TI_SCI_DEV_ID_MASK 0x
+#define TI_SCI_DEV_ID_SHIFT16
+#define TI_SCI_IRQ_ID_MASK 0x
+#define TI_SCI_IRQ_ID_SHIFT0
+#define HWIRQ_TO_DEVID(hwirq) (((hwirq) >> (TI_SCI_DEV_ID_SHIFT)) & \
+(TI_SCI_DEV_ID_MASK))
+#define HWIRQ_TO_IRQID(hwirq) ((hwirq) & (TI_SCI_IRQ_ID_MASK))
+
+#define MAX_EVENTS_PER_VINT64
+#define VINT_ENABLE_SET_OFFSET 0x0
+#define VINT_ENABLE_CLR_OFFSET 0x8
+#define VINT_STATUS_OFFSET 0x18
+
+/**
+ * struct ti_sci_inta_event_desc - Description of an event coming to
+ *Interrupt Aggregator. This serves
+ *as a mapping table for global event,
+ *hwirq and vint bit.
+ * @global_event: Global event number corresponding to this event
+ * @hwirq: Hwirq of the incoming interrupt
+ * @vint_bit: Corresponding vint bit to which this event is attached.
+ */
+struct ti_sci_inta_event_desc {
+ u16 global_event;
+ u32 hwirq;
+ u8 vint_bit;
+};
+
+/**
+ * struct ti_sci_inta_vint_desc - Description of a virtual interrupt coming out
+ * of Interrupt Aggregator.
+ * @domain:Pointer to IRQ domain to which this vint belongs.
+ * @list: List entry for the vint list
+ * @event_map: Bitmap to manage the allocation of events to vint.
+ * @event_mutex: Mutex to protect
[PATCH v7 10/14] dt-bindings: irqchip: Introduce TISCI Interrupt Aggregator bindings
Add the DT binding documentation for Interrupt Aggregator driver.
Signed-off-by: Lokesh Vutla
---
Changes since v6:
- None
.../interrupt-controller/ti,sci-inta.txt | 66 +++
MAINTAINERS | 1 +
2 files changed, 67 insertions(+)
create mode 100644
Documentation/devicetree/bindings/interrupt-controller/ti,sci-inta.txt
diff --git
a/Documentation/devicetree/bindings/interrupt-controller/ti,sci-inta.txt
b/Documentation/devicetree/bindings/interrupt-controller/ti,sci-inta.txt
new file mode 100644
index ..7841cb099e13
--- /dev/null
+++ b/Documentation/devicetree/bindings/interrupt-controller/ti,sci-inta.txt
@@ -0,0 +1,66 @@
+Texas Instruments K3 Interrupt Aggregator
+=
+
+The Interrupt Aggregator (INTA) provides a centralized machine
+which handles the termination of system events to that they can
+be coherently processed by the host(s) in the system. A maximum
+of 64 events can be mapped to a single interrupt.
+
+
+ Interrupt Aggregator
+ +-+
+ | IntmapVINT |
+ | +--+ ++|
+m -->| | vint | bit | | 0 |.|63| vint0 |
+ . | +--+ ++| +--+
+ . | . . | | HOST |
+Globalevents -->| . . |-->| IRQ |
+ . | . . | | CTRL |
+ . | . . | +--+
+n -->| +--+ ++|
+ | | vint | bit | | 0 |.|63| vintx |
+ | +--+ ++|
+ | |
+ +-+
+
+Configuration of these Intmap registers that maps global events to vint is done
+by a system controller (like the Device Memory and Security Controller on K3
+AM654 SoC). Driver should request the system controller to get the range
+of global events and vints assigned to the requesting host. Management
+of these requested resources should be handled by driver and requests
+system controller to map specific global event to vint, bit pair.
+
+Communication between the host processor running an OS and the system
+controller happens through a protocol called TI System Control Interface
+(TISCI protocol). For more details refer:
+Documentation/devicetree/bindings/arm/keystone/ti,sci.txt
+
+TISCI Interrupt Aggregator Node:
+---
+- compatible: Must be "ti,sci-inta".
+- reg: Should contain registers location and length.
+- interrupt-controller:Identifies the node as an interrupt controller
+- msi-controller: Identifies the node as an MSI controller.
+- interrupt-parent:phandle of irq parent.
+- ti,sci: Phandle to TI-SCI compatible System controller node.
+- ti,sci-dev-id: TISCI device ID of the Interrupt Aggregator.
+- ti,sci-rm-range-vint:Array of TISCI subtype ids representing
vints(inta
+ outputs) range within this INTA, assigned to the
+ requesting host context.
+- ti,sci-rm-range-global-event:Array of TISCI subtype ids representing
the
+ global events range reaching this IA and are assigned
+ to the requesting host context.
+
+Example:
+
+main_udmass_inta: interrupt-controller@33d0 {
+ compatible = "ti,sci-inta";
+ reg = <0x0 0x33d0 0x0 0x10>;
+ interrupt-controller;
+ msi-controller;
+ interrupt-parent = <_navss_intr>;
+ ti,sci = <>;
+ ti,sci-dev-id = <179>;
+ ti,sci-rm-range-vint = <0x0>;
+ ti,sci-rm-range-global-event = <0x1>;
+};
diff --git a/MAINTAINERS b/MAINTAINERS
index 63851f106b5c..461db0a8233f 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -15350,6 +15350,7 @@ F:
Documentation/devicetree/bindings/clock/ti,sci-clk.txt
F: drivers/clk/keystone/sci-clk.c
F: drivers/reset/reset-ti-sci.c
F: Documentation/devicetree/bindings/interrupt-controller/ti,sci-intr.txt
+F: Documentation/devicetree/bindings/interrupt-controller/ti,sci-inta.txt
F: drivers/irqchip/irq-ti-sci-intr.c
Texas Instruments ASoC drivers
--
2.21.0
[PATCH v7 14/14] arm64: arch_k3: Enable interrupt controller drivers
Select the TISCI Interrupt Router, Aggregator drivers and all its dependencies for TI's SoCs based on K3 architecture. Suggested-by: Marc Zyngier Signed-off-by: Lokesh Vutla --- Changes since v6: - Moved the selection to ARCH_K3 arch/arm64/Kconfig.platforms | 5 + 1 file changed, 5 insertions(+) diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms index b5ca9c50876d..ab9cac8235b3 100644 --- a/arch/arm64/Kconfig.platforms +++ b/arch/arm64/Kconfig.platforms @@ -82,6 +82,11 @@ config ARCH_EXYNOS config ARCH_K3 bool "Texas Instruments Inc. K3 multicore SoC architecture" select PM_GENERIC_DOMAINS if PM + select MAILBOX + select TI_MESSAGE_MANAGER + select TI_SCI_PROTOCOL + select TI_SCI_INTR_IRQCHIP + select TI_SCI_INTA_IRQCHIP help This enables support for Texas Instruments' K3 multicore SoC architecture. -- 2.21.0
