* Re: [PATCH v5] soc: ti: smartreflex: Use platform_get_irq_optional() to get the interrupt
From: Lad, Prabhakar @ 2022-01-05 17:55 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Lad Prabhakar, Nishanth Menon, Santosh Shilimkar, Rob Herring,
Linux Kernel Mailing List, linux-arm Mailing List, Linux PM
In-Reply-To: <CAHp75Ve+0VmfU7GhC=AjZ3J1J6KtGko2YAenA9mXCSCVrcuX5w@mail.gmail.com>
Hi Andy,
Thank you for the review.
On Wed, Jan 5, 2022 at 9:47 AM Andy Shevchenko
<andy.shevchenko@gmail.com> wrote:
>
> On Tue, Jan 4, 2022 at 6:45 PM Lad Prabhakar
> <prabhakar.mahadev-lad.rj@bp.renesas.com> wrote:
> >
> > platform_get_resource(pdev, IORESOURCE_IRQ, ..) relies on static
> > allocation of IRQ resources in DT core code, this causes an issue
> > when using hierarchical interrupt domains using "interrupts" property
> > in the node as this bypasses the hierarchical setup and messes up the
> > irq chaining.
> >
> > In preparation for removal of static setup of IRQ resource from DT core
> > code use platform_get_irq_optional().
> >
> > While at it return 0 instead of returning ret in the probe success path.
>
> ...
>
> > + ret = platform_get_irq_optional(pdev, 0);
> > + if (ret < 0 && ret != -ENXIO)
> > + return dev_err_probe(&pdev->dev, ret, "%s: failed to get IRQ resource\n", __func__);
>
> Sorry, I haven't noticed that you are using __func__ in the message.
> Please don't. It shows either that the message is not unique (so make
> the message unique enough in this driver) or the redundancy of the
> __func__ (it doesn't add any value, but noise).
>
Thanks for the pointer, I was just keeping the messages in-sync with the driver.
Cheers,
Prabhakar
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* stable/linux-4.4.y baseline: 140 runs, 1 regressions (v4.4.298)
From: kernelci.org bot @ 2022-01-05 17:56 UTC (permalink / raw)
To: stable, kernel-build-reports, kernelci-results
stable/linux-4.4.y baseline: 140 runs, 1 regressions (v4.4.298)
Regressions Summary
-------------------
platform | arch | lab | compiler | defconfig | regressions
---------+------+---------------+----------+---------------------+------------
panda | arm | lab-collabora | gcc-10 | omap2plus_defconfig | 1
Details: https://kernelci.org/test/job/stable/branch/linux-4.4.y/kernel/v4.4.298/plan/baseline/
Test: baseline
Tree: stable
Branch: linux-4.4.y
Describe: v4.4.298
URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
SHA: 0dc4b955f01eae10c6923c86234ef9768137797f
Test Regressions
----------------
platform | arch | lab | compiler | defconfig | regressions
---------+------+---------------+----------+---------------------+------------
panda | arm | lab-collabora | gcc-10 | omap2plus_defconfig | 1
Details: https://kernelci.org/test/plan/id/61d5a85c4550e2dc6aef674e
Results: 4 PASS, 1 FAIL, 1 SKIP
Full config: omap2plus_defconfig
Compiler: gcc-10 (arm-linux-gnueabihf-gcc (Debian 10.2.1-6) 10.2.1 20210110)
Plain log: https://storage.kernelci.org//stable/linux-4.4.y/v4.4.298/arm/omap2plus_defconfig/gcc-10/lab-collabora/baseline-panda.txt
HTML log: https://storage.kernelci.org//stable/linux-4.4.y/v4.4.298/arm/omap2plus_defconfig/gcc-10/lab-collabora/baseline-panda.html
Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/buildroot-baseline/20211210.0/armel/rootfs.cpio.gz
* baseline.dmesg.emerg: https://kernelci.org/test/case/id/61d5a85c4550e2dc6aef6751
failing since 39 days (last pass: v4.4.292, first fail: v4.4.293)
2 lines
2022-01-05T14:16:38.883980 kern :emerg : BUG: spinlock bad magic on CPU#0, udevd/112
2022-01-05T14:16:38.892866 kern :emerg : lock: emif_lock+0x0/0xfffff25c [emif], .magic: 00000000, .owner: <none>/-1, .owner_cpu: 0
^ permalink raw reply
* Re: [PATCH v1 11/13] KVM: x86/mmu: Split huge pages during CLEAR_DIRTY_LOG
From: David Matlack @ 2022-01-05 17:55 UTC (permalink / raw)
To: Peter Xu
Cc: Paolo Bonzini, kvm list, Ben Gardon, Joerg Roedel, Jim Mattson,
Wanpeng Li, Vitaly Kuznetsov, Sean Christopherson,
Janis Schoetterl-Glausch, Junaid Shahid, Oliver Upton,
Harish Barathvajasankar, Peter Shier, Nikunj A . Dadhania
In-Reply-To: <YdVejo2TODD3Z+QC@xz-m1.local>
On Wed, Jan 5, 2022 at 1:02 AM Peter Xu <peterx@redhat.com> wrote:
>
> On Mon, Dec 13, 2021 at 10:59:16PM +0000, David Matlack wrote:
> > diff --git a/arch/x86/kvm/mmu/mmu.c b/arch/x86/kvm/mmu/mmu.c
> > index c9e5fe290714..55640d73df5a 100644
> > --- a/arch/x86/kvm/mmu/mmu.c
> > +++ b/arch/x86/kvm/mmu/mmu.c
> > @@ -1362,6 +1362,20 @@ void kvm_arch_mmu_enable_log_dirty_pt_masked(struct kvm *kvm,
> > gfn_t start = slot->base_gfn + gfn_offset + __ffs(mask);
> > gfn_t end = slot->base_gfn + gfn_offset + __fls(mask);
> >
> > + /*
> > + * Try to proactively split any huge pages down to 4KB so that
> > + * vCPUs don't have to take write-protection faults.
> > + *
> > + * Drop the MMU lock since huge page splitting uses its own
> > + * locking scheme and does not require the write lock in all
> > + * cases.
> > + */
> > + if (READ_ONCE(eagerly_split_huge_pages_for_dirty_logging)) {
> > + write_unlock(&kvm->mmu_lock);
> > + kvm_mmu_try_split_huge_pages(kvm, slot, start, end, PG_LEVEL_4K);
> > + write_lock(&kvm->mmu_lock);
> > + }
> > +
> > kvm_mmu_slot_gfn_write_protect(kvm, slot, start, PG_LEVEL_2M);
>
> Would it be easier to just allow passing in shared=true/false for the new
> kvm_mmu_try_split_huge_pages(), then previous patch will not be needed? Or is
> it intended to do it for performance reasons?
>
> IOW, I think this patch does two things: (1) support clear-log on eager split,
> and (2) allow lock degrade during eager split.
>
> It's just that imho (2) may still need some justification on necessity since
> this function only operates on a very small range of guest mem (at most
> 4K*64KB=256KB range), so it's not clear to me whether the extra lock operations
> are needed at all; after all it'll make the code slightly harder to follow.
> Not to mention the previous patch is preparing for this, and both patches will
> add lock operations.
>
> I think dirty_log_perf_test didn't cover lock contention case, because clear
> log was run after vcpu threads stopped, so lock access should be mostly hitting
> the cachelines there, afaict. While in real life, clear log is run with vcpus
> running. Not sure whether that'll be a problem, so raising this question up.
Good point. Dropping the write lock to acquire the read lock is
probably not necessary since we're splitting a small region of memory
here. Plus the splitting code detects contention and will drop the
lock if necessary. And the value of dropping the lock is dubious since
it adds a lot more lock operations.
I'll try your suggestion in v3.
>
> Thanks,
>
> --
> Peter Xu
>
^ permalink raw reply
* Re: [PATCH v5] soc: ti: smartreflex: Use platform_get_irq_optional() to get the interrupt
From: Lad, Prabhakar @ 2022-01-05 17:55 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Lad Prabhakar, Nishanth Menon, Santosh Shilimkar, Rob Herring,
Linux Kernel Mailing List, linux-arm Mailing List, Linux PM
In-Reply-To: <CAHp75Ve+0VmfU7GhC=AjZ3J1J6KtGko2YAenA9mXCSCVrcuX5w@mail.gmail.com>
Hi Andy,
Thank you for the review.
On Wed, Jan 5, 2022 at 9:47 AM Andy Shevchenko
<andy.shevchenko@gmail.com> wrote:
>
> On Tue, Jan 4, 2022 at 6:45 PM Lad Prabhakar
> <prabhakar.mahadev-lad.rj@bp.renesas.com> wrote:
> >
> > platform_get_resource(pdev, IORESOURCE_IRQ, ..) relies on static
> > allocation of IRQ resources in DT core code, this causes an issue
> > when using hierarchical interrupt domains using "interrupts" property
> > in the node as this bypasses the hierarchical setup and messes up the
> > irq chaining.
> >
> > In preparation for removal of static setup of IRQ resource from DT core
> > code use platform_get_irq_optional().
> >
> > While at it return 0 instead of returning ret in the probe success path.
>
> ...
>
> > + ret = platform_get_irq_optional(pdev, 0);
> > + if (ret < 0 && ret != -ENXIO)
> > + return dev_err_probe(&pdev->dev, ret, "%s: failed to get IRQ resource\n", __func__);
>
> Sorry, I haven't noticed that you are using __func__ in the message.
> Please don't. It shows either that the message is not unique (so make
> the message unique enough in this driver) or the redundancy of the
> __func__ (it doesn't add any value, but noise).
>
Thanks for the pointer, I was just keeping the messages in-sync with the driver.
Cheers,
Prabhakar
^ permalink raw reply
* Re: [RFC][V9][PATCH 0/6] btrfs: allocation_hint mode
From: Boris Burkov @ 2022-01-05 17:55 UTC (permalink / raw)
To: kreijack
Cc: linux-btrfs, Zygo Blaxell, Josef Bacik, David Sterba,
Sinnamohideen Shafeeq, Paul Jones
In-Reply-To: <7377b63d-23a7-5efd-4ae2-cffe70463d0b@libero.it>
On Wed, Jan 05, 2022 at 10:16:08AM +0100, Goffredo Baroncelli wrote:
> Hi Boris,
>
>
>
> On 1/5/22 03:44, Boris Burkov wrote:
> [...]
> >
> > This is cool, thanks for building it!
> >
> > I'm playing with setting this up for a test I'm working on where I want
> > to send data to a dm-zero device. To that end, I applied this patchset
> > on top of misc-next and ran:
> >
> > $ mkfs.btrfs -f /dev/vg0/lv0 -dsingle -msingle
> > $ mount /dev/vg0/lv0 /mnt/lol
>
> You should mount the filesystem with
>
> $ mount -o allocation_hint=1 /dev/vg0/lv0 /mnt/lol
>
With this option, I got the expected usage output:
Data,single: Size:1.00GiB, Used:512.00KiB (0.05%)
/dev/mapper/zero-data 1.00GiB
Metadata,single: Size:1.00GiB, Used:112.00KiB (0.01%)
/dev/mapper/vg0-lv0 1.00GiB
Sorry I missed that, and thanks for the quick reply.
>
> In the previous iteration I missed the patch #6, which activates this option. You can drop patch #6 and avoid to pass this option.
>
> Please give me a feedback if this resolve.
>
> BR
> G.Baroncelli
>
> > $ btrfs device add /dev/mapper/zero-data /mnt/lol
> > $ btrfs fi usage /mnt/lol
> > Overall:
> > Device size: 50.01TiB
> > Device allocated: 20.00MiB
> > Device unallocated: 50.01TiB
> > Device missing: 0.00B
> > Used: 128.00KiB
> > Free (estimated): 50.01TiB (min: 50.01TiB)
> > Free (statfs, df): 50.01TiB
> > Data ratio: 1.00
> > Metadata ratio: 1.00
> > Global reserve: 3.25MiB (used: 0.00B)
> > Multiple profiles: no
> >
> > Data,single: Size:8.00MiB, Used:0.00B (0.00%)
> > /dev/mapper/vg0-lv0 8.00MiB
> >
> > Metadata,single: Size:8.00MiB, Used:112.00KiB (1.37%)
> > /dev/mapper/vg0-lv0 8.00MiB
> >
> > System,single: Size:4.00MiB, Used:16.00KiB (0.39%)
> > /dev/mapper/vg0-lv0 4.00MiB
> >
> > Unallocated:
> > /dev/mapper/vg0-lv0 9.98GiB
> > /dev/mapper/zero-data 50.00TiB
> >
> > $ ./btrfs property set -t device /dev/mapper/zero-data allocation_hint DATA_ONLY
> > $ ./btrfs property set -t device /dev/vg0/lv0 allocation_hint METADATA_ONLY
> >
> > $ btrfs balance start --full-balance /mnt/lol
> > Done, had to relocate 3 out of 3 chunks
> >
> > $ btrfs fi usage /mnt/lol
> > Overall:
> > Device size: 50.01TiB
> > Device allocated: 2.03GiB
> > Device unallocated: 50.01TiB
> > Device missing: 0.00B
> > Used: 640.00KiB
> > Free (estimated): 50.01TiB (min: 50.01TiB)
> > Free (statfs, df): 50.01TiB
> > Data ratio: 1.00
> > Metadata ratio: 1.00
> > Global reserve: 3.25MiB (used: 0.00B)
> > Multiple profiles: no
> >
> > Data,single: Size:1.00GiB, Used:512.00KiB (0.05%)
> > /dev/mapper/zero-data 1.00GiB
> >
> > Metadata,single: Size:1.00GiB, Used:112.00KiB (0.01%)
> > /dev/mapper/zero-data 1.00GiB
> >
> > System,single: Size:32.00MiB, Used:16.00KiB (0.05%)
> > /dev/mapper/zero-data 32.00MiB
> >
> > Unallocated:
> > /dev/mapper/vg0-lv0 10.00GiB
> > /dev/mapper/zero-data 50.00TiB
> >
> >
> > I expected that I would have data on /dev/mapper/zero-data and metadata
> > on /dev/mapper/vg0-lv0, but it seems both of them were written to the zero
> > device. Attempting to actually use the file system eventually fails, since
> > the metadata is black-holed :)
> >
> > Did I make some mistake in how I used it, or is this a bug?
> >
> > Thanks,
> > Boris
> >
> > > BR
> > > G.Baroncelli
> > >
> > > Revision:
> > > V9:
> > > - rename dev_item->type to dev_item->flags
> > > - rename /sys/fs/btrfs/$UUID/devinfo/type -> allocation_hint
> > >
> > > V8:
> > > - drop the ioctl API, instead use a sysfs one
> > >
> > > V7:
> > > - make more room in the struct btrfs_ioctl_dev_properties up to 1K
> > > - leave in btrfs_tree.h only the costants
> > > - removed the mount option (sic)
> > > - correct an 'use before check' in the while loop (signaled
> > > by Zygo)
> > > - add a 2nd sort to be sure that the device_info array is in the
> > > expected order
> > >
> > > V6:
> > > - add further values to the hints: add the possibility to
> > > exclude a disk for a chunk type
> > >
> > >
> > > Goffredo Baroncelli (6):
> > > btrfs: add flags to give an hint to the chunk allocator
> > > btrfs: export the device allocation_hint property in sysfs
> > > btrfs: change the device allocation_hint property via sysfs
> > > btrfs: add allocation_hint mode
> > > btrfs: rename dev_item->type to dev_item->flags
> > > btrfs: add allocation_hint option.
> > >
> > > fs/btrfs/ctree.h | 18 +++++-
> > > fs/btrfs/disk-io.c | 4 +-
> > > fs/btrfs/super.c | 17 ++++++
> > > fs/btrfs/sysfs.c | 73 ++++++++++++++++++++++
> > > fs/btrfs/volumes.c | 105 ++++++++++++++++++++++++++++++--
> > > fs/btrfs/volumes.h | 7 ++-
> > > include/uapi/linux/btrfs_tree.h | 20 +++++-
> > > 7 files changed, 232 insertions(+), 12 deletions(-)
> > >
> > > --
> > > 2.34.1
> > >
>
>
> --
> gpg @keyserver.linux.it: Goffredo Baroncelli <kreijackATinwind.it>
> Key fingerprint BBF5 1610 0B64 DAC6 5F7D 17B2 0EDA 9B37 8B82 E0B5
^ permalink raw reply
* Re: [PATCH for-next v2] RDMA/rxe: remove redundant err variable
From: Jason Gunthorpe @ 2022-01-05 17:54 UTC (permalink / raw)
To: cgel.zte
Cc: devesh.s.sharma, chi.minghao, dledford, linux-kernel, linux-rdma,
zealci, zyjzyj2000
In-Reply-To: <20211215075258.442930-1-chi.minghao@zte.com.cn>
On Wed, Dec 15, 2021 at 07:52:58AM +0000, cgel.zte@gmail.com wrote:
> From: Minghao Chi <chi.minghao@zte.com.cn>
>
> Return value directly instead of taking this
> in another redundant variable.
>
> Reported-by: Zeal Robot <zealci@zte.com.cn>
> Signed-off-by: Minghao Chi <chi.minghao@zte.com.cn>
> ---
> drivers/infiniband/sw/rxe/rxe_net.c | 8 ++------
> 1 file changed, 2 insertions(+), 6 deletions(-)
Applied to for-next, thanks
Jason
^ permalink raw reply
* [PATCH v7 3/3] integrity: support including firmware ".platform" keys at build time
From: Nayna Jain @ 2022-01-05 17:54 UTC (permalink / raw)
To: linux-integrity, keyrings
Cc: dhowells, zohar, jarkko, linux-security-module, linux-kernel,
dimitri.ledkov, seth, Nayna Jain
In-Reply-To: <20220105175410.554444-1-nayna@linux.ibm.com>
Allow firmware keys to be embedded in the Linux kernel and loaded onto
the ".platform" keyring on boot.
The firmware keys can be specified in a file as a list of PEM encoded
certificates using new config INTEGRITY_PLATFORM_KEYS. The certificates
are embedded in the image by converting the PEM-formatted certificates
into DER(binary) and generating
security/integrity/platform_certs/platform_certificate_list file at
build time. On boot, the embedded certs from the image are loaded onto
the ".platform" keyring at late_initcall(), ensuring the platform keyring
exists before loading the keys.
Reviewed-by: Mimi Zohar <zohar@linux.ibm.com>
Signed-off-by: Nayna Jain <nayna@linux.ibm.com>
---
security/integrity/Kconfig | 10 +++++++
security/integrity/Makefile | 17 +++++++++++-
.../integrity/platform_certs/platform_cert.S | 23 ++++++++++++++++
.../platform_certs/platform_keyring.c | 26 +++++++++++++++++++
4 files changed, 75 insertions(+), 1 deletion(-)
create mode 100644 security/integrity/platform_certs/platform_cert.S
diff --git a/security/integrity/Kconfig b/security/integrity/Kconfig
index 71f0177e8716..9fccf1368b8a 100644
--- a/security/integrity/Kconfig
+++ b/security/integrity/Kconfig
@@ -62,6 +62,16 @@ config INTEGRITY_PLATFORM_KEYRING
provided by the platform for verifying the kexec'ed kerned image
and, possibly, the initramfs signature.
+config INTEGRITY_PLATFORM_KEYS
+ string "Builtin X.509 keys for .platform keyring"
+ depends on KEYS
+ depends on ASYMMETRIC_KEY_TYPE
+ depends on INTEGRITY_PLATFORM_KEYRING
+ help
+ If set, this option should be the filename of a PEM-formatted file
+ containing X.509 certificates to be loaded onto the ".platform"
+ keyring.
+
config LOAD_UEFI_KEYS
depends on INTEGRITY_PLATFORM_KEYRING
depends on EFI
diff --git a/security/integrity/Makefile b/security/integrity/Makefile
index 7ee39d66cf16..46629f5ef4f6 100644
--- a/security/integrity/Makefile
+++ b/security/integrity/Makefile
@@ -3,13 +3,18 @@
# Makefile for caching inode integrity data (iint)
#
+quiet_cmd_extract_certs = EXTRACT_CERTS $(patsubst "%",%,$(2))
+ cmd_extract_certs = scripts/extract-cert $(2) $@
+$(eval $(call config_filename,INTEGRITY_PLATFORM_KEYS))
+
obj-$(CONFIG_INTEGRITY) += integrity.o
integrity-y := iint.o
integrity-$(CONFIG_INTEGRITY_AUDIT) += integrity_audit.o
integrity-$(CONFIG_INTEGRITY_SIGNATURE) += digsig.o
integrity-$(CONFIG_INTEGRITY_ASYMMETRIC_KEYS) += digsig_asymmetric.o
-integrity-$(CONFIG_INTEGRITY_PLATFORM_KEYRING) += platform_certs/platform_keyring.o
+integrity-$(CONFIG_INTEGRITY_PLATFORM_KEYRING) += platform_certs/platform_keyring.o \
+ platform_certs/platform_cert.o
integrity-$(CONFIG_LOAD_UEFI_KEYS) += platform_certs/efi_parser.o \
platform_certs/load_uefi.o \
platform_certs/keyring_handler.o
@@ -19,3 +24,13 @@ integrity-$(CONFIG_LOAD_PPC_KEYS) += platform_certs/efi_parser.o \
platform_certs/keyring_handler.o
obj-$(CONFIG_IMA) += ima/
obj-$(CONFIG_EVM) += evm/
+
+
+$(obj)/platform_certs/platform_cert.o: $(obj)/platform_certs/platform_certificate_list
+
+targets += platform_certificate_list
+
+$(obj)/platform_certs/platform_certificate_list: scripts/extract-cert $(INTEGRITY_PLATFORM_KEYS_FILENAME) FORCE
+ $(call if_changed,extract_certs,$(CONFIG_INTEGRITY_PLATFORM_KEYS))
+
+clean-files := platform_certs/platform_certificate_list
diff --git a/security/integrity/platform_certs/platform_cert.S b/security/integrity/platform_certs/platform_cert.S
new file mode 100644
index 000000000000..20bccce5dc5a
--- /dev/null
+++ b/security/integrity/platform_certs/platform_cert.S
@@ -0,0 +1,23 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#include <linux/export.h>
+#include <linux/init.h>
+
+ __INITRODATA
+
+ .align 8
+#ifdef CONFIG_INTEGRITY_PLATFORM_KEYRING
+ .globl platform_certificate_list
+platform_certificate_list:
+__cert_list_start:
+ .incbin "security/integrity/platform_certs/platform_certificate_list"
+__cert_list_end:
+#endif
+
+ .align 8
+ .globl platform_certificate_list_size
+platform_certificate_list_size:
+#ifdef CONFIG_64BIT
+ .quad __cert_list_end - __cert_list_start
+#else
+ .long __cert_list_end - __cert_list_start
+#endif
diff --git a/security/integrity/platform_certs/platform_keyring.c b/security/integrity/platform_certs/platform_keyring.c
index bcafd7387729..b45de142c5f5 100644
--- a/security/integrity/platform_certs/platform_keyring.c
+++ b/security/integrity/platform_certs/platform_keyring.c
@@ -12,8 +12,12 @@
#include <linux/cred.h>
#include <linux/err.h>
#include <linux/slab.h>
+#include <keys/system_keyring.h>
#include "../integrity.h"
+extern __initconst const u8 platform_certificate_list[];
+extern __initconst const unsigned long platform_certificate_list_size;
+
/**
* add_to_platform_keyring - Add to platform keyring without validation.
* @source: Source of key
@@ -37,6 +41,28 @@ void __init add_to_platform_keyring(const char *source, const void *data,
pr_info("Error adding keys to platform keyring %s\n", source);
}
+static __init int load_platform_certificate_list(void)
+{
+ const u8 *p;
+ unsigned long size;
+ int rc;
+ struct key *keyring;
+
+ p = platform_certificate_list;
+ size = platform_certificate_list_size;
+
+ keyring = integrity_keyring_from_id(INTEGRITY_KEYRING_PLATFORM);
+ if (IS_ERR(keyring))
+ return PTR_ERR(keyring);
+
+ rc = load_certificate_list(p, size, keyring);
+ if (rc)
+ pr_info("Error adding keys to platform keyring %d\n", rc);
+
+ return rc;
+}
+late_initcall(load_platform_certificate_list);
+
/*
* Create the trusted keyrings.
*/
--
2.27.0
^ permalink raw reply related
* [PATCH v7 2/3] integrity: make integrity_keyring_from_id() non-static
From: Nayna Jain @ 2022-01-05 17:54 UTC (permalink / raw)
To: linux-integrity, keyrings
Cc: dhowells, zohar, jarkko, linux-security-module, linux-kernel,
dimitri.ledkov, seth, Nayna Jain
In-Reply-To: <20220105175410.554444-1-nayna@linux.ibm.com>
Make integrity_keyring_from_id() non-static so that it is accessible
by other files in security/integrity.
Reviewed-by: Mimi Zohar <zohar@linux.ibm.com>
Signed-off-by: Nayna Jain <nayna@linux.ibm.com>
---
security/integrity/digsig.c | 2 +-
security/integrity/integrity.h | 6 ++++++
2 files changed, 7 insertions(+), 1 deletion(-)
diff --git a/security/integrity/digsig.c b/security/integrity/digsig.c
index 3b06a01bd0fd..0ea40ed8dfcb 100644
--- a/security/integrity/digsig.c
+++ b/security/integrity/digsig.c
@@ -38,7 +38,7 @@ static const char * const keyring_name[INTEGRITY_KEYRING_MAX] = {
#define restrict_link_to_ima restrict_link_by_builtin_trusted
#endif
-static struct key *integrity_keyring_from_id(const unsigned int id)
+struct key *integrity_keyring_from_id(const unsigned int id)
{
if (id >= INTEGRITY_KEYRING_MAX)
return ERR_PTR(-EINVAL);
diff --git a/security/integrity/integrity.h b/security/integrity/integrity.h
index 547425c20e11..feb84e1b1105 100644
--- a/security/integrity/integrity.h
+++ b/security/integrity/integrity.h
@@ -167,6 +167,7 @@ int __init integrity_init_keyring(const unsigned int id);
int __init integrity_load_x509(const unsigned int id, const char *path);
int __init integrity_load_cert(const unsigned int id, const char *source,
const void *data, size_t len, key_perm_t perm);
+struct key *integrity_keyring_from_id(const unsigned int id);
#else
static inline int integrity_digsig_verify(const unsigned int id,
@@ -194,6 +195,11 @@ static inline int __init integrity_load_cert(const unsigned int id,
{
return 0;
}
+
+static inline struct key *integrity_keyring_from_id(const unsigned int id)
+{
+ return ERR_PTR(-EOPNOTSUPP);
+}
#endif /* CONFIG_INTEGRITY_SIGNATURE */
#ifdef CONFIG_INTEGRITY_ASYMMETRIC_KEYS
--
2.27.0
^ permalink raw reply related
* [PATCH v7 1/3] certs: export load_certificate_list() to be used outside certs/
From: Nayna Jain @ 2022-01-05 17:54 UTC (permalink / raw)
To: linux-integrity, keyrings
Cc: dhowells, zohar, jarkko, linux-security-module, linux-kernel,
dimitri.ledkov, seth, Nayna Jain, kernel test robot
In-Reply-To: <20220105175410.554444-1-nayna@linux.ibm.com>
load_certificate_list() parses certificates embedded in the kernel
image to load them onto the keyring.
Commit "2565ca7f5ec1 (certs: Move load_system_certificate_list to a common
function)" made load_certificate_list() a common function in the certs/
directory. Now, export load_certificate_list() outside certs/ to be used
by load_platform_certificate_list() which is added later in the patchset.
Reported-by: kernel test robot <lkp@intel.com> (auto build test ERROR)
Reviewed-by: Mimi Zohar <zohar@linux.ibm.com>
Signed-off-by: Nayna Jain <nayna@linux.ibm.com>
---
certs/Makefile | 5 +++--
certs/blacklist.c | 1 -
certs/common.c | 2 +-
certs/common.h | 9 ---------
certs/system_keyring.c | 1 -
include/keys/system_keyring.h | 6 ++++++
6 files changed, 10 insertions(+), 14 deletions(-)
delete mode 100644 certs/common.h
diff --git a/certs/Makefile b/certs/Makefile
index 279433783b10..6f26c93ff56b 100644
--- a/certs/Makefile
+++ b/certs/Makefile
@@ -3,8 +3,9 @@
# Makefile for the linux kernel signature checking certificates.
#
-obj-$(CONFIG_SYSTEM_TRUSTED_KEYRING) += system_keyring.o system_certificates.o common.o
-obj-$(CONFIG_SYSTEM_BLACKLIST_KEYRING) += blacklist.o common.o
+obj-$(CONFIG_KEYS) += common.o
+obj-$(CONFIG_SYSTEM_TRUSTED_KEYRING) += system_keyring.o system_certificates.o
+obj-$(CONFIG_SYSTEM_BLACKLIST_KEYRING) += blacklist.o
obj-$(CONFIG_SYSTEM_REVOCATION_LIST) += revocation_certificates.o
ifneq ($(CONFIG_SYSTEM_BLACKLIST_HASH_LIST),"")
obj-$(CONFIG_SYSTEM_BLACKLIST_KEYRING) += blacklist_hashes.o
diff --git a/certs/blacklist.c b/certs/blacklist.c
index c9a435b15af4..b95e9b19c42f 100644
--- a/certs/blacklist.c
+++ b/certs/blacklist.c
@@ -17,7 +17,6 @@
#include <linux/uidgid.h>
#include <keys/system_keyring.h>
#include "blacklist.h"
-#include "common.h"
static struct key *blacklist_keyring;
diff --git a/certs/common.c b/certs/common.c
index 16a220887a53..41f763415a00 100644
--- a/certs/common.c
+++ b/certs/common.c
@@ -2,7 +2,7 @@
#include <linux/kernel.h>
#include <linux/key.h>
-#include "common.h"
+#include <keys/system_keyring.h>
int load_certificate_list(const u8 cert_list[],
const unsigned long list_size,
diff --git a/certs/common.h b/certs/common.h
deleted file mode 100644
index abdb5795936b..000000000000
--- a/certs/common.h
+++ /dev/null
@@ -1,9 +0,0 @@
-/* SPDX-License-Identifier: GPL-2.0-or-later */
-
-#ifndef _CERT_COMMON_H
-#define _CERT_COMMON_H
-
-int load_certificate_list(const u8 cert_list[], const unsigned long list_size,
- const struct key *keyring);
-
-#endif
diff --git a/certs/system_keyring.c b/certs/system_keyring.c
index 692365dee2bd..d130d5a96e09 100644
--- a/certs/system_keyring.c
+++ b/certs/system_keyring.c
@@ -16,7 +16,6 @@
#include <keys/asymmetric-type.h>
#include <keys/system_keyring.h>
#include <crypto/pkcs7.h>
-#include "common.h"
static struct key *builtin_trusted_keys;
#ifdef CONFIG_SECONDARY_TRUSTED_KEYRING
diff --git a/include/keys/system_keyring.h b/include/keys/system_keyring.h
index 6acd3cf13a18..d3f914d9a632 100644
--- a/include/keys/system_keyring.h
+++ b/include/keys/system_keyring.h
@@ -10,6 +10,12 @@
#include <linux/key.h>
+#ifdef CONFIG_KEYS
+int load_certificate_list(const u8 cert_list[],
+ const unsigned long list_size,
+ const struct key *keyring);
+#endif
+
#ifdef CONFIG_SYSTEM_TRUSTED_KEYRING
extern int restrict_link_by_builtin_trusted(struct key *keyring,
--
2.27.0
^ permalink raw reply related
* [PATCH v7 0/3] integrity: support including firmware ".platform" keys at build time
From: Nayna Jain @ 2022-01-05 17:54 UTC (permalink / raw)
To: linux-integrity, keyrings
Cc: dhowells, zohar, jarkko, linux-security-module, linux-kernel,
dimitri.ledkov, seth, Nayna Jain
Some firmware support secure boot by embedding static keys to verify the
Linux kernel during boot. However, these firmware do not expose an
interface for the kernel to load firmware keys onto the ".platform"
keyring, preventing the kernel from verifying the kexec kernel image
signature.
This patchset exports load_certificate_list() and defines a new function
load_builtin_platform_cert() to load compiled in certificates onto the
".platform" keyring.
Note: It seems last time my patches didn't go through mailing list. My
apologies to those who are receiving it twice.
Changelog:
v7:
* Incldues Jarkko's feedback on patch description for Patch 1 and 3.
v6:
* Includes Jarkko's feedback:
* Split Patch 2 into two.
* Update Patch description.
v5:
* Renamed load_builtin_platform_cert() to load_platform_certificate_list()
and config INTEGRITY_PLATFORM_BUILTIN_KEYS to INTEGRITY_PLATFORM_KEYS, as
suggested by Mimi Zohar.
v4:
* Split into two patches as per Mimi Zohar and Dimitri John Ledkov
recommendation.
v3:
* Included Jarkko's feedback
** updated patch description to include approach.
** removed extern for function declaration in the .h file.
* Included load_certificate_list() within #ifdef CONFIG_KEYS condition.
v2:
* Fixed the error reported by kernel test robot
* Updated patch description based on Jarkko's feedback.
Nayna Jain (3):
certs: export load_certificate_list() to be used outside certs/
integrity: make integrity_keyring_from_id() non-static
integrity: support including firmware ".platform" keys at build time
certs/Makefile | 5 ++--
certs/blacklist.c | 1 -
certs/common.c | 2 +-
certs/common.h | 9 -------
certs/system_keyring.c | 1 -
include/keys/system_keyring.h | 6 +++++
security/integrity/Kconfig | 10 +++++++
security/integrity/Makefile | 17 +++++++++++-
security/integrity/digsig.c | 2 +-
security/integrity/integrity.h | 6 +++++
.../integrity/platform_certs/platform_cert.S | 23 ++++++++++++++++
.../platform_certs/platform_keyring.c | 26 +++++++++++++++++++
12 files changed, 92 insertions(+), 16 deletions(-)
delete mode 100644 certs/common.h
create mode 100644 security/integrity/platform_certs/platform_cert.S
--
2.27.0
^ permalink raw reply
* Re: [PATCH for-next v5] RDMA/ocrdma: remove unneeded variable
From: Jason Gunthorpe @ 2022-01-05 17:54 UTC (permalink / raw)
To: cgel.zte
Cc: chi.minghao, dennis.dalessandro, devesh.s.sharma, dledford, leon,
linux-kernel, linux-rdma, mbloch, selvin.xavier, trix, zealci
In-Reply-To: <20211215055421.441375-1-chi.minghao@zte.com.cn>
On Wed, Dec 15, 2021 at 05:54:21AM +0000, cgel.zte@gmail.com wrote:
> From: Minghao Chi <chi.minghao@zte.com.cn>
>
> Return status directly from function called.
>
> Reported-by: Zeal Robot <zealci@zte.com.cn>
> Signed-off-by: Minghao Chi <chi.minghao@zte.com.cn>
> ---
> drivers/infiniband/hw/ocrdma/ocrdma_verbs.c | 8 ++------
> 1 file changed, 2 insertions(+), 6 deletions(-)
Applied to for-next, thanks
Jason
^ permalink raw reply
* Re: [PATCH] PCI: iproc: Set all 24 bits of PCI class code
From: Ray Jui @ 2022-01-05 17:51 UTC (permalink / raw)
To: Pali Rohár, Roman Bacik, Lorenzo Pieralisi, Rob Herring,
Krzysztof Wilczyński, Bjorn Helgaas
Cc: bcm-kernel-feedback-list, linux-pci, linux-arm-kernel,
linux-kernel
In-Reply-To: <20220105093552.27542-1-pali@kernel.org>
[-- Attachment #1.1: Type: text/plain, Size: 2389 bytes --]
Hi Pali,
On 1/5/2022 1:35 AM, Pali Rohár wrote:
> Register 0x43c in its low 24 bits contains PCI class code.
>
> Update code to set all 24 bits of PCI class code and not only upper 16 bits
> of PCI class code.
>
> Use a new macro PCI_CLASS_BRIDGE_PCI_NORMAL which represents whole 24 bits
> of normal PCI bridge class.
>
> Signed-off-by: Pali Rohár <pali@kernel.org>
>
> ---
> Roman helped me with this change and confirmed that class code is stored
> really in bits [23:0] of custom register 0x43c (normally class code is
> stored in bits [31:8] of pci register 0x08).
>
> This patch depends on patch which adds PCI_CLASS_BRIDGE_PCI_NORMAL macro:
> https://lore.kernel.org/linux-pci/20211220145140.31898-1-pali@kernel.org/
> ---
> drivers/pci/controller/pcie-iproc.c | 9 ++++-----
> 1 file changed, 4 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/pci/controller/pcie-iproc.c b/drivers/pci/controller/pcie-iproc.c
> index 3df4ab209253..2519201b0e51 100644
> --- a/drivers/pci/controller/pcie-iproc.c
> +++ b/drivers/pci/controller/pcie-iproc.c
> @@ -789,14 +789,13 @@ static int iproc_pcie_check_link(struct iproc_pcie *pcie)
> return -EFAULT;
> }
>
> - /* force class to PCI_CLASS_BRIDGE_PCI (0x0604) */
> + /* force class to PCI_CLASS_BRIDGE_PCI_NORMAL (0x060400) */
> #define PCI_BRIDGE_CTRL_REG_OFFSET 0x43c
> -#define PCI_CLASS_BRIDGE_MASK 0xffff00
> -#define PCI_CLASS_BRIDGE_SHIFT 8
> +#define PCI_BRIDGE_CTRL_REG_CLASS_MASK 0xffffff
> iproc_pci_raw_config_read32(pcie, 0, PCI_BRIDGE_CTRL_REG_OFFSET,
> 4, &class);
> - class &= ~PCI_CLASS_BRIDGE_MASK;
> - class |= (PCI_CLASS_BRIDGE_PCI << PCI_CLASS_BRIDGE_SHIFT);
> + class &= ~PCI_BRIDGE_CTRL_REG_CLASS_MASK;
> + class |= PCI_CLASS_BRIDGE_PCI_NORMAL;
> iproc_pci_raw_config_write32(pcie, 0, PCI_BRIDGE_CTRL_REG_OFFSET,
> 4, class);
>
I have two comments:
1. You do not seem to generate the email list using the
get_maintainer.pl script, so the two maintainers for Broadcom ARM
architecture (Ray Jui and Scott Branden) are left out.
2. I suppose 'PCI_CLASS_BRIDGE_PCI_NORMAL' is defined in some common PCI
header in a separate patch as described in the commit message. Then how
come these patches are not constructed with a patch series?
Other than, the change itself is exactly what I sent to Roman and looks
good to me. Thanks.
Acked-by: Ray Jui <ray.jui@broadcom.com>
[-- Attachment #1.2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4194 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] sh: sq: use default_groups in kobj_type
From: Greg Kroah-Hartman @ 2022-01-05 17:52 UTC (permalink / raw)
To: Rob Landley; +Cc: linux-kernel, Yoshinori Sato, Rich Felker, linux-sh
In-Reply-To: <4622e641-1423-e72a-4f6d-5f2cc747a148@landley.net>
On Wed, Jan 05, 2022 at 11:46:28AM -0600, Rob Landley wrote:
> On 1/4/22 10:22 AM, Greg Kroah-Hartman wrote:
> > There are currently 2 ways to create a set of sysfs files for a
> > kobj_type, through the default_attrs field, and the default_groups
> > field. Move the sh sq sysfs code to use default_groups field which has
> > been the preferred way since aa30f47cf666 ("kobject: Add support for
> > default attribute groups to kobj_type") so that we can soon get rid of
> > the obsolete default_attrs field.
>
> Let's see, sh4-specific, depends on CONFIG_SH_STORE_QUEUES... it built but I'm
> not finding an "sq" entry under /proc. (Or anything with "mapping" in it...)
>
> Oh well, probably right? Didn't break anything for me:
>
> Tested-by: Rob Landley <rob@landley.net>
Thanks! Seems to pass 0-day testing as well :)
Should I take this in my tree?
greg k-h
^ permalink raw reply
* [PATCH] mm, oom: OOM sysrq should always kill a process
From: Jann Horn @ 2022-01-05 17:51 UTC (permalink / raw)
To: Andrew Morton, linux-mm; +Cc: linux-kernel, Martin Schwidefsky, Jann Horn
The OOM kill sysrq (alt+sysrq+F) should allow the user to kill the
process with the highest OOM badness with a single execution.
However, at the moment, the OOM kill can bail out if an OOM notifier
(e.g. the i915 one) says that it reclaimed a tiny amount of memory
from somewhere. That's probably not what the user wants.
As documented in struct oom_control, order == -1 means the oom kill is
required by sysrq. So check for that, and if it's true, don't bail out
no matter what the OOM notifiers say.
Signed-off-by: Jann Horn <jannh@google.com>
---
mm/oom_kill.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/mm/oom_kill.c b/mm/oom_kill.c
index 1ddabefcfb5a..dc645cbc6e0d 100644
--- a/mm/oom_kill.c
+++ b/mm/oom_kill.c
@@ -1051,13 +1051,14 @@ EXPORT_SYMBOL_GPL(unregister_oom_notifier);
bool out_of_memory(struct oom_control *oc)
{
unsigned long freed = 0;
+ bool sysrq_forced = oc->order == -1;
if (oom_killer_disabled)
return false;
if (!is_memcg_oom(oc)) {
blocking_notifier_call_chain(&oom_notify_list, 0, &freed);
- if (freed > 0)
+ if (freed > 0 && !sysrq_forced)
/* Got some memory back in the last second. */
return true;
}
base-commit: c9e6606c7fe92b50a02ce51dda82586ebdf99b48
--
2.34.1.448.ga2b2bfdf31-goog
^ permalink raw reply related
* Re: [PATCH] PCI: iproc: Set all 24 bits of PCI class code
From: Ray Jui @ 2022-01-05 17:51 UTC (permalink / raw)
To: Pali Rohár, Roman Bacik, Lorenzo Pieralisi, Rob Herring,
Krzysztof Wilczyński, Bjorn Helgaas
Cc: bcm-kernel-feedback-list, linux-pci, linux-arm-kernel,
linux-kernel
In-Reply-To: <20220105093552.27542-1-pali@kernel.org>
[-- Attachment #1: Type: text/plain, Size: 2389 bytes --]
Hi Pali,
On 1/5/2022 1:35 AM, Pali Rohár wrote:
> Register 0x43c in its low 24 bits contains PCI class code.
>
> Update code to set all 24 bits of PCI class code and not only upper 16 bits
> of PCI class code.
>
> Use a new macro PCI_CLASS_BRIDGE_PCI_NORMAL which represents whole 24 bits
> of normal PCI bridge class.
>
> Signed-off-by: Pali Rohár <pali@kernel.org>
>
> ---
> Roman helped me with this change and confirmed that class code is stored
> really in bits [23:0] of custom register 0x43c (normally class code is
> stored in bits [31:8] of pci register 0x08).
>
> This patch depends on patch which adds PCI_CLASS_BRIDGE_PCI_NORMAL macro:
> https://lore.kernel.org/linux-pci/20211220145140.31898-1-pali@kernel.org/
> ---
> drivers/pci/controller/pcie-iproc.c | 9 ++++-----
> 1 file changed, 4 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/pci/controller/pcie-iproc.c b/drivers/pci/controller/pcie-iproc.c
> index 3df4ab209253..2519201b0e51 100644
> --- a/drivers/pci/controller/pcie-iproc.c
> +++ b/drivers/pci/controller/pcie-iproc.c
> @@ -789,14 +789,13 @@ static int iproc_pcie_check_link(struct iproc_pcie *pcie)
> return -EFAULT;
> }
>
> - /* force class to PCI_CLASS_BRIDGE_PCI (0x0604) */
> + /* force class to PCI_CLASS_BRIDGE_PCI_NORMAL (0x060400) */
> #define PCI_BRIDGE_CTRL_REG_OFFSET 0x43c
> -#define PCI_CLASS_BRIDGE_MASK 0xffff00
> -#define PCI_CLASS_BRIDGE_SHIFT 8
> +#define PCI_BRIDGE_CTRL_REG_CLASS_MASK 0xffffff
> iproc_pci_raw_config_read32(pcie, 0, PCI_BRIDGE_CTRL_REG_OFFSET,
> 4, &class);
> - class &= ~PCI_CLASS_BRIDGE_MASK;
> - class |= (PCI_CLASS_BRIDGE_PCI << PCI_CLASS_BRIDGE_SHIFT);
> + class &= ~PCI_BRIDGE_CTRL_REG_CLASS_MASK;
> + class |= PCI_CLASS_BRIDGE_PCI_NORMAL;
> iproc_pci_raw_config_write32(pcie, 0, PCI_BRIDGE_CTRL_REG_OFFSET,
> 4, class);
>
I have two comments:
1. You do not seem to generate the email list using the
get_maintainer.pl script, so the two maintainers for Broadcom ARM
architecture (Ray Jui and Scott Branden) are left out.
2. I suppose 'PCI_CLASS_BRIDGE_PCI_NORMAL' is defined in some common PCI
header in a separate patch as described in the commit message. Then how
come these patches are not constructed with a patch series?
Other than, the change itself is exactly what I sent to Roman and looks
good to me. Thanks.
Acked-by: Ray Jui <ray.jui@broadcom.com>
[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4194 bytes --]
^ permalink raw reply
* Re: Howto implement bootchooser <-> rauc interaction
From: Ahmad Fatoum @ 2022-01-05 17:50 UTC (permalink / raw)
To: Konstantin Kletschke; +Cc: barebox
In-Reply-To: <YcMwk6mncQ8fSwTJ@Hephaistos>
Hello Konstantin,
On 22.12.21 15:05, Konstantin Kletschke wrote:
> I switched from doing the state in the onboard EEPROM (as said, it
> is write protected in production use) to save the state in a dead space
> in the onboard eMMC chip between MBR and first partition:
>
> / {
> aliases {
> state = &state_eeprom;
> };
>
> state_eeprom: state_eeprom {
> #address-cells = <1>;
> #size-cells = <1>;
> compatible = "barebox,state";
> magic = <0xcafebabe>;
> backend-type = "raw";
> backend = <&backend_state_mmc2>;
> backend-storage-type = "direct";
> backend-stridesize = <54>;
> last_chosen {
Here last_chosen is toplevel.
> Compiled in (relevant) variables:
>
> * boot.default: bootchooser insidem2m_1 insidem2m_2
> boot.watchdog_timeout: 0
> bootchooser.default_attempts: 3
> bootchooser.default_priority: 1
> bootchooser.disable_on_zero_attempts: 0
> bootchooser.reset_attempts: (list: "power-on", "all-zero")
> bootchooser.reset_priorities:
> bootchooser.retry: 0
> * bootchooser.state_prefix: state
Here you say they are inside state.*
> The userspace is no amused, however:
>
> rauc status output:
>
> (rauc:583): rauc-WARNING **: 18:51:57.389: Failed getting primary slot: Failed getting primary slot: No content to read
Yes RAUC has:
#define BOOTSTATE_PREFIX "bootstate"
So that's what you need to use.
> barebox-state:
>
> last_chosen=2
> system0.remaining_attempts=0
> system0.priority=21
> system0.ok=0
> system1.remaining_attempts=2
> system1.priority=20
> system1.ok=0
But state works correctly regardless, you can place
all sort of stuff there.
> ################ PLAN B ##################
>
> I had a previous state device tree setup, which made userspace happy,
> but not barebox. I had a parent bootstate section containing system0 and
> system1:
>
> / {
> aliases {
> state = &state_eeprom;
> };
>
> state_eeprom: state_eeprom {
> #address-cells = <1>;
> #size-cells = <1>;
> compatible = "barebox,state";
> magic = <0xcafebabe>;
> backend-type = "raw";
> backend = <&backend_state_mmc2>;
> backend-storage-type = "direct";
> backend-stridesize = <54>;
> bootstate {
Here you have a correctly named container.
> With this device tree barebox bootschooser is unhappy:
Did you set bootchooser.boot_prefix?
> But userspace is fine:
As expected.
> I assume this has to do with bootchooser.state_prefix. If I change from
> state to bootstate (yes, brute force) I get:
>
> global excerpt:
>
> * bootchooser.state_prefix: bootstate
>
> devinfo state looks the same as previous.
>
> boot:
>
> barebox@TI AM335x BeagleBone black:/ boot
> ERROR: bootchooser: Cannot get state 'bootstate'
> Nothing bootable found on 'bootchooser'
> Booting entry 'insidem2m_1'
> ext4 ext40: EXT2 rev 1, inode_size 256, descriptor size 64
> mounted /dev/mmc1.1 on /mnt/mmc1.1
> [...]
>
>
>
> When I set:
>
> * bootchooser.state_prefix: state.bootstate
>
> I get best of both worlds!
Exactly. :-)
> Wall of text, two questions:
>
> Is this resulting setup (DT with bootstate parent, state_prefix:
> state.bootstate) sane?
Ye, the final setup looks good now.
> Can the variant without the boostate variant work too? If it was the
> other way around, userspace working w/o the bootstate variant but bnot
> _with_ I would say additional configuration required or something, but
> this way... I would like to understand this fully.
RAUC hardcodes bootstate, so that's what you need to use, unless you patch
RAUC.
Cheers,
Ahmad
>
>
> Kind Regards
> Konstantin
>
>
--
Pengutronix e.K. | |
Steuerwalder Str. 21 | http://www.pengutronix.de/ |
31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
^ permalink raw reply
* Re: [PATCH] drm/bridge: nwl-dsi: Fix PM disable depth imbalance in nwl_dsi_probe
From: Robert Foss @ 2022-01-05 17:51 UTC (permalink / raw)
To: Miaoqian Lin
Cc: Andrzej Hajda, Neil Armstrong, Laurent Pinchart, Jonas Karlman,
Jernej Skrabec, David Airlie, Daniel Vetter, Fabio Estevam,
Guido Günther, Robert Chiras, Sam Ravnborg, dri-devel,
linux-kernel
In-Reply-To: <20220105104826.1418-1-linmq006@gmail.com>
Hey Miaoqian,
Thanks for submitting this patch!
On Wed, 5 Jan 2022 at 11:48, Miaoqian Lin <linmq006@gmail.com> wrote:
>
> The pm_runtime_enable will increase power disable depth.
> Thus a pairing decrement is needed on the error handling
> path to keep it balanced according to context.
>
> Fixes: 44cfc62 ("drm/bridge: Add NWL MIPI DSI host controller support")
In the future, please use 12 chars of the hash. I'll fix it this time,
but please use 12 characters going forward.
> Signed-off-by: Miaoqian Lin <linmq006@gmail.com>
> ---
> drivers/gpu/drm/bridge/nwl-dsi.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/gpu/drm/bridge/nwl-dsi.c b/drivers/gpu/drm/bridge/nwl-dsi.c
> index a7389a0facfb..fc3ad9fab867 100644
> --- a/drivers/gpu/drm/bridge/nwl-dsi.c
> +++ b/drivers/gpu/drm/bridge/nwl-dsi.c
> @@ -1206,6 +1206,7 @@ static int nwl_dsi_probe(struct platform_device *pdev)
>
> ret = nwl_dsi_select_input(dsi);
> if (ret < 0) {
> + pm_runtime_disable(dev);
> mipi_dsi_host_unregister(&dsi->dsi_host);
> return ret;
> }
> --
> 2.17.1
>
Fixed commit hash length, added my r-b and applied to drm-misc-next.
Reviewed-by: Robert Foss <robert.foss@linaro.org>
^ permalink raw reply
* Re: [PATCH] drm/bridge: nwl-dsi: Fix PM disable depth imbalance in nwl_dsi_probe
From: Robert Foss @ 2022-01-05 17:51 UTC (permalink / raw)
To: Miaoqian Lin
Cc: dri-devel, Jonas Karlman, David Airlie, Sam Ravnborg,
Guido Günther, Neil Armstrong, linux-kernel, Jernej Skrabec,
Andrzej Hajda, Laurent Pinchart, Robert Chiras
In-Reply-To: <20220105104826.1418-1-linmq006@gmail.com>
Hey Miaoqian,
Thanks for submitting this patch!
On Wed, 5 Jan 2022 at 11:48, Miaoqian Lin <linmq006@gmail.com> wrote:
>
> The pm_runtime_enable will increase power disable depth.
> Thus a pairing decrement is needed on the error handling
> path to keep it balanced according to context.
>
> Fixes: 44cfc62 ("drm/bridge: Add NWL MIPI DSI host controller support")
In the future, please use 12 chars of the hash. I'll fix it this time,
but please use 12 characters going forward.
> Signed-off-by: Miaoqian Lin <linmq006@gmail.com>
> ---
> drivers/gpu/drm/bridge/nwl-dsi.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/gpu/drm/bridge/nwl-dsi.c b/drivers/gpu/drm/bridge/nwl-dsi.c
> index a7389a0facfb..fc3ad9fab867 100644
> --- a/drivers/gpu/drm/bridge/nwl-dsi.c
> +++ b/drivers/gpu/drm/bridge/nwl-dsi.c
> @@ -1206,6 +1206,7 @@ static int nwl_dsi_probe(struct platform_device *pdev)
>
> ret = nwl_dsi_select_input(dsi);
> if (ret < 0) {
> + pm_runtime_disable(dev);
> mipi_dsi_host_unregister(&dsi->dsi_host);
> return ret;
> }
> --
> 2.17.1
>
Fixed commit hash length, added my r-b and applied to drm-misc-next.
Reviewed-by: Robert Foss <robert.foss@linaro.org>
^ permalink raw reply
* Re: [PATCH v2] ACPI: PCC: Implement OperationRegion handler for the PCC Type 3 subtype
From: kernel test robot @ 2022-01-05 17:50 UTC (permalink / raw)
To: Sudeep Holla, Linux Kernel Mailing List, ACPI Devel Maling List,
Rafael J . Wysocki
Cc: kbuild-all, Sudeep Holla
In-Reply-To: <20220103155838.616580-1-sudeep.holla@arm.com>
Hi Sudeep,
I love your patch! Perhaps something to improve:
[auto build test WARNING on rafael-pm/linux-next]
[also build test WARNING on next-20220105]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url: https://github.com/0day-ci/linux/commits/Sudeep-Holla/ACPI-PCC-Implement-OperationRegion-handler-for-the-PCC-Type-3-subtype/20220104-000003
base: https://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git linux-next
config: x86_64-rhel-8.3-kselftests (https://download.01.org/0day-ci/archive/20220106/202201060154.xBYcdXiV-lkp@intel.com/config)
compiler: gcc-9 (Debian 9.3.0-22) 9.3.0
reproduce:
# apt-get install sparse
# sparse version: v0.6.4-dirty
# https://github.com/0day-ci/linux/commit/1dbcdc47eadc8c55659410fc03d067f3438a386a
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review Sudeep-Holla/ACPI-PCC-Implement-OperationRegion-handler-for-the-PCC-Type-3-subtype/20220104-000003
git checkout 1dbcdc47eadc8c55659410fc03d067f3438a386a
# save the config file to linux build tree
mkdir build_dir
make W=1 C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' O=build_dir ARCH=x86_64 SHELL=/bin/bash
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp@intel.com>
sparse warnings: (new ones prefixed by >>)
>> drivers/acpi/acpi_pcc.c:34:22: sparse: sparse: symbol 'pcc_ctx' was not declared. Should it be static?
Please review and possibly fold the followup patch.
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
^ permalink raw reply
* Re: [PATCH][TRIVIAL] btrfs-progs: Allow autodetect_object_types() to handle the link.
From: Boris Burkov @ 2022-01-05 17:50 UTC (permalink / raw)
To: Goffredo Baroncelli; +Cc: linux-btrfs, Goffredo Baroncelli
In-Reply-To: <f4345fcac83ba226efdadcd4610861e434f8a73e.1641389199.git.kreijack@inwind.it>
On Wed, Jan 05, 2022 at 02:32:58PM +0100, Goffredo Baroncelli wrote:
> From: Goffredo Baroncelli <kreijack@inwind.it>
>
>
> Hi All,
>
> Boris Burkov reported a problem when "btrfs prop get" is invoked on a link of a block
> device. This happens when btrfs is invoked on a LVM device (which typically is
> a link with an user friendly name to the real block device). In this case btrfs
> reports 'ERROR: object is not a btrfs object'.
>
> ------------------
> Steps to reproduce:
>
> $ sudo losetup -f disk-1.img
> $ sudo losetup -f disk-2.img
> $ sudo losetup -O NAME,BACK-FILE
> NAME BACK-FILE
> /dev/loop1 /home/ghigo/test-allocation-hint/disk-2.img
> /dev/loop0 /home/ghigo/test-allocation-hint/disk-1.img
>
> $ cd /dev/
> $ mv loop1 loop1-tmp
> $ ln -sf loop1-tmp loop1
> $ ls -l /dev/loop[01]*
> brw-rw---- 1 root disk 7, 0 Jan 5 13:42 /dev/loop0
> lrwxrwxrwx 1 root root 9 Jan 5 13:41 /dev/loop1 -> loop1-tmp
> brw-rw---- 1 root disk 7, 1 Jan 5 13:42 /dev/loop1-tmp
>
> $ sudo mkfs.btrfs /dev/loop[0-1]
> [....]
> $ sudo mount /dev/loop1 mnt/
>
> $ # this is the error
> $ sudo btrfs prop get /dev/loop1
> ERROR: object is not a btrfs object: /dev/loop1
>
> $ # this is what should happen
> $ sudo btrfs prop get /dev/loop0
> label=
>
> ------------------
>
> The cause is in the function autodetect_object_types() that detects the type of
> btrfs object passed. If the object is an "inode" type (e.g. file, link...) it
> returns the type of object. If the object is a block device (it doesn't matter
> if it is in a btrfs filesystem), it returns it as block device.
> However it doesn't handle well the case where the object passed is a link
> to a block device (which could be a valid btrfs object). For example
> LVM/DM creates link to block devices.
>
> This patch adds a further call to stat() (instead of reusing the previous lstat()
> returned value) when btrfs-progs checks if the object is a block device.
Thank you very much for investigating and fixing this. I tested this
patch an it works as advertised.
>
> Reported-by: Boris Burkov <boris@bur.io>
> Signed-off-by: Goffredo Baroncelli <kreijack@inwind.it>
> ---
> cmds/property.c | 8 ++++++++
> 1 file changed, 8 insertions(+)
>
> diff --git a/cmds/property.c b/cmds/property.c
> index 59ef997c..97dc5ae1 100644
> --- a/cmds/property.c
> +++ b/cmds/property.c
> @@ -391,6 +391,14 @@ static int autodetect_object_types(const char *object, int *types_out)
> types |= prop_object_root;
> }
>
> + /*
> + * Do a new stat to follow a possible link
> + */
I took a look at the original lstat and it doesn't seem super strongly
motivated. It is used to detect a subvolume object (ino==256) so I don't
see why we would hate to have property get/set work on a symlink to a
subvol.
I tested a patch that just changes lstat to stat instead of adding the
second stat, and it handled the subvol case nicely too.
e.g.
ln -s /mnt/real /mnt/lnk
./btrfs property get /mnt/real ro
ro=false
./btrfs property get /mnt/lnk ro
ro=false
> + ret = stat(object, &st);
> + if (ret < 0) {
> + ret = -errno;
> + goto out;
> + }
> if (S_ISBLK(st.st_mode))
> types |= prop_object_dev;
>
> --
> 2.34.1
>
^ permalink raw reply
* Re: [PATCH v2] ACPI: PCC: Implement OperationRegion handler for the PCC Type 3 subtype
From: kernel test robot @ 2022-01-05 17:50 UTC (permalink / raw)
To: kbuild-all
In-Reply-To: <20220103155838.616580-1-sudeep.holla@arm.com>
[-- Attachment #1: Type: text/plain, Size: 1838 bytes --]
Hi Sudeep,
I love your patch! Perhaps something to improve:
[auto build test WARNING on rafael-pm/linux-next]
[also build test WARNING on next-20220105]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url: https://github.com/0day-ci/linux/commits/Sudeep-Holla/ACPI-PCC-Implement-OperationRegion-handler-for-the-PCC-Type-3-subtype/20220104-000003
base: https://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git linux-next
config: x86_64-rhel-8.3-kselftests (https://download.01.org/0day-ci/archive/20220106/202201060154.xBYcdXiV-lkp(a)intel.com/config)
compiler: gcc-9 (Debian 9.3.0-22) 9.3.0
reproduce:
# apt-get install sparse
# sparse version: v0.6.4-dirty
# https://github.com/0day-ci/linux/commit/1dbcdc47eadc8c55659410fc03d067f3438a386a
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review Sudeep-Holla/ACPI-PCC-Implement-OperationRegion-handler-for-the-PCC-Type-3-subtype/20220104-000003
git checkout 1dbcdc47eadc8c55659410fc03d067f3438a386a
# save the config file to linux build tree
mkdir build_dir
make W=1 C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' O=build_dir ARCH=x86_64 SHELL=/bin/bash
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp@intel.com>
sparse warnings: (new ones prefixed by >>)
>> drivers/acpi/acpi_pcc.c:34:22: sparse: sparse: symbol 'pcc_ctx' was not declared. Should it be static?
Please review and possibly fold the followup patch.
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all(a)lists.01.org
^ permalink raw reply
* Re: [PATCH] phy: ti: Add missing pm_runtime_disable() in probe function
From: kernel test robot @ 2022-01-05 17:50 UTC (permalink / raw)
To: kbuild
[-- Attachment #1: Type: text/plain, Size: 10059 bytes --]
CC: kbuild-all(a)lists.01.org
In-Reply-To: <20220105090225.20507-1-linmq006@gmail.com>
References: <20220105090225.20507-1-linmq006@gmail.com>
TO: Miaoqian Lin <linmq006@gmail.com>
CC: linmq006(a)gmail.com
CC: Kishon Vijay Abraham I <kishon@ti.com>
CC: Vinod Koul <vkoul@kernel.org>
CC: Randy Dunlap <rdunlap@infradead.org>
CC: Roger Quadros <rogerq@ti.com>
CC: linux-phy(a)lists.infradead.org
CC: linux-kernel(a)vger.kernel.org
Hi Miaoqian,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on linus/master]
[also build test WARNING on v5.16-rc8 next-20220105]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url: https://github.com/0day-ci/linux/commits/Miaoqian-Lin/phy-ti-Add-missing-pm_runtime_disable-in-probe-function/20220105-170334
base: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git c9e6606c7fe92b50a02ce51dda82586ebdf99b48
:::::: branch date: 9 hours ago
:::::: commit date: 9 hours ago
config: microblaze-randconfig-s031-20220105 (https://download.01.org/0day-ci/archive/20220106/202201060123.PR3DWie4-lkp(a)intel.com/config)
compiler: microblaze-linux-gcc (GCC) 11.2.0
reproduce:
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# apt-get install sparse
# sparse version: v0.6.4-dirty
# https://github.com/0day-ci/linux/commit/dc404b65a54364bb2937baba85bb37960c514167
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review Miaoqian-Lin/phy-ti-Add-missing-pm_runtime_disable-in-probe-function/20220105-170334
git checkout dc404b65a54364bb2937baba85bb37960c514167
# save the config file to linux build tree
mkdir build_dir
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-11.2.0 make.cross C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' O=build_dir ARCH=microblaze SHELL=/bin/bash drivers/phy/ti/
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp@intel.com>
sparse warnings: (new ones prefixed by >>)
>> drivers/phy/ti/phy-am654-serdes.c:841:1: sparse: sparse: unused label 'err_pm_disable'
vim +/err_pm_disable +841 drivers/phy/ti/phy-am654-serdes.c
71e2f5c5c2249d Kishon Vijay Abraham I 2019-04-17 751
71e2f5c5c2249d Kishon Vijay Abraham I 2019-04-17 752 static int serdes_am654_probe(struct platform_device *pdev)
71e2f5c5c2249d Kishon Vijay Abraham I 2019-04-17 753 {
71e2f5c5c2249d Kishon Vijay Abraham I 2019-04-17 754 struct phy_provider *phy_provider;
71e2f5c5c2249d Kishon Vijay Abraham I 2019-04-17 755 struct device *dev = &pdev->dev;
71e2f5c5c2249d Kishon Vijay Abraham I 2019-04-17 756 struct device_node *node = dev->of_node;
71e2f5c5c2249d Kishon Vijay Abraham I 2019-04-17 757 struct clk_onecell_data *clk_data;
71e2f5c5c2249d Kishon Vijay Abraham I 2019-04-17 758 struct serdes_am654 *am654_phy;
71e2f5c5c2249d Kishon Vijay Abraham I 2019-04-17 759 struct mux_control *control;
71e2f5c5c2249d Kishon Vijay Abraham I 2019-04-17 760 const char *clock_name;
71e2f5c5c2249d Kishon Vijay Abraham I 2019-04-17 761 struct regmap *regmap;
71e2f5c5c2249d Kishon Vijay Abraham I 2019-04-17 762 void __iomem *base;
71e2f5c5c2249d Kishon Vijay Abraham I 2019-04-17 763 struct phy *phy;
71e2f5c5c2249d Kishon Vijay Abraham I 2019-04-17 764 int ret;
71e2f5c5c2249d Kishon Vijay Abraham I 2019-04-17 765 int i;
71e2f5c5c2249d Kishon Vijay Abraham I 2019-04-17 766
71e2f5c5c2249d Kishon Vijay Abraham I 2019-04-17 767 am654_phy = devm_kzalloc(dev, sizeof(*am654_phy), GFP_KERNEL);
71e2f5c5c2249d Kishon Vijay Abraham I 2019-04-17 768 if (!am654_phy)
71e2f5c5c2249d Kishon Vijay Abraham I 2019-04-17 769 return -ENOMEM;
71e2f5c5c2249d Kishon Vijay Abraham I 2019-04-17 770
71e2f5c5c2249d Kishon Vijay Abraham I 2019-04-17 771 base = devm_platform_ioremap_resource(pdev, 0);
71e2f5c5c2249d Kishon Vijay Abraham I 2019-04-17 772 if (IS_ERR(base))
71e2f5c5c2249d Kishon Vijay Abraham I 2019-04-17 773 return PTR_ERR(base);
71e2f5c5c2249d Kishon Vijay Abraham I 2019-04-17 774
71e2f5c5c2249d Kishon Vijay Abraham I 2019-04-17 775 regmap = devm_regmap_init_mmio(dev, base, &serdes_am654_regmap_config);
71e2f5c5c2249d Kishon Vijay Abraham I 2019-04-17 776 if (IS_ERR(regmap)) {
71e2f5c5c2249d Kishon Vijay Abraham I 2019-04-17 777 dev_err(dev, "Failed to initialize regmap\n");
71e2f5c5c2249d Kishon Vijay Abraham I 2019-04-17 778 return PTR_ERR(regmap);
71e2f5c5c2249d Kishon Vijay Abraham I 2019-04-17 779 }
71e2f5c5c2249d Kishon Vijay Abraham I 2019-04-17 780
71e2f5c5c2249d Kishon Vijay Abraham I 2019-04-17 781 control = devm_mux_control_get(dev, NULL);
71e2f5c5c2249d Kishon Vijay Abraham I 2019-04-17 782 if (IS_ERR(control))
71e2f5c5c2249d Kishon Vijay Abraham I 2019-04-17 783 return PTR_ERR(control);
71e2f5c5c2249d Kishon Vijay Abraham I 2019-04-17 784
71e2f5c5c2249d Kishon Vijay Abraham I 2019-04-17 785 am654_phy->dev = dev;
71e2f5c5c2249d Kishon Vijay Abraham I 2019-04-17 786 am654_phy->of_node = node;
71e2f5c5c2249d Kishon Vijay Abraham I 2019-04-17 787 am654_phy->regmap = regmap;
71e2f5c5c2249d Kishon Vijay Abraham I 2019-04-17 788 am654_phy->control = control;
71e2f5c5c2249d Kishon Vijay Abraham I 2019-04-17 789 am654_phy->type = PHY_NONE;
71e2f5c5c2249d Kishon Vijay Abraham I 2019-04-17 790
71e2f5c5c2249d Kishon Vijay Abraham I 2019-04-17 791 ret = serdes_am654_regfield_init(am654_phy);
71e2f5c5c2249d Kishon Vijay Abraham I 2019-04-17 792 if (ret) {
71e2f5c5c2249d Kishon Vijay Abraham I 2019-04-17 793 dev_err(dev, "Failed to initialize regfields\n");
71e2f5c5c2249d Kishon Vijay Abraham I 2019-04-17 794 return ret;
71e2f5c5c2249d Kishon Vijay Abraham I 2019-04-17 795 }
71e2f5c5c2249d Kishon Vijay Abraham I 2019-04-17 796
71e2f5c5c2249d Kishon Vijay Abraham I 2019-04-17 797 platform_set_drvdata(pdev, am654_phy);
71e2f5c5c2249d Kishon Vijay Abraham I 2019-04-17 798
71e2f5c5c2249d Kishon Vijay Abraham I 2019-04-17 799 for (i = 0; i < SERDES_NUM_CLOCKS; i++) {
71e2f5c5c2249d Kishon Vijay Abraham I 2019-04-17 800 ret = of_property_read_string_index(node, "clock-output-names",
71e2f5c5c2249d Kishon Vijay Abraham I 2019-04-17 801 i, &clock_name);
71e2f5c5c2249d Kishon Vijay Abraham I 2019-04-17 802 if (ret) {
71e2f5c5c2249d Kishon Vijay Abraham I 2019-04-17 803 dev_err(dev, "Failed to get clock name\n");
71e2f5c5c2249d Kishon Vijay Abraham I 2019-04-17 804 return ret;
71e2f5c5c2249d Kishon Vijay Abraham I 2019-04-17 805 }
71e2f5c5c2249d Kishon Vijay Abraham I 2019-04-17 806
71e2f5c5c2249d Kishon Vijay Abraham I 2019-04-17 807 ret = serdes_am654_clk_register(am654_phy, clock_name, i);
71e2f5c5c2249d Kishon Vijay Abraham I 2019-04-17 808 if (ret) {
71e2f5c5c2249d Kishon Vijay Abraham I 2019-04-17 809 dev_err(dev, "Failed to initialize clock %s\n",
71e2f5c5c2249d Kishon Vijay Abraham I 2019-04-17 810 clock_name);
71e2f5c5c2249d Kishon Vijay Abraham I 2019-04-17 811 return ret;
71e2f5c5c2249d Kishon Vijay Abraham I 2019-04-17 812 }
71e2f5c5c2249d Kishon Vijay Abraham I 2019-04-17 813 }
71e2f5c5c2249d Kishon Vijay Abraham I 2019-04-17 814
71e2f5c5c2249d Kishon Vijay Abraham I 2019-04-17 815 clk_data = &am654_phy->clk_data;
71e2f5c5c2249d Kishon Vijay Abraham I 2019-04-17 816 clk_data->clks = am654_phy->clks;
71e2f5c5c2249d Kishon Vijay Abraham I 2019-04-17 817 clk_data->clk_num = SERDES_NUM_CLOCKS;
71e2f5c5c2249d Kishon Vijay Abraham I 2019-04-17 818 ret = of_clk_add_provider(node, of_clk_src_onecell_get, clk_data);
71e2f5c5c2249d Kishon Vijay Abraham I 2019-04-17 819 if (ret)
71e2f5c5c2249d Kishon Vijay Abraham I 2019-04-17 820 return ret;
71e2f5c5c2249d Kishon Vijay Abraham I 2019-04-17 821
71e2f5c5c2249d Kishon Vijay Abraham I 2019-04-17 822 pm_runtime_enable(dev);
71e2f5c5c2249d Kishon Vijay Abraham I 2019-04-17 823
71e2f5c5c2249d Kishon Vijay Abraham I 2019-04-17 824 phy = devm_phy_create(dev, NULL, &ops);
850280156f6421 Dan Carpenter 2020-09-05 825 if (IS_ERR(phy)) {
850280156f6421 Dan Carpenter 2020-09-05 826 ret = PTR_ERR(phy);
850280156f6421 Dan Carpenter 2020-09-05 827 goto clk_err;
850280156f6421 Dan Carpenter 2020-09-05 828 }
71e2f5c5c2249d Kishon Vijay Abraham I 2019-04-17 829
71e2f5c5c2249d Kishon Vijay Abraham I 2019-04-17 830 phy_set_drvdata(phy, am654_phy);
71e2f5c5c2249d Kishon Vijay Abraham I 2019-04-17 831 phy_provider = devm_of_phy_provider_register(dev, serdes_am654_xlate);
71e2f5c5c2249d Kishon Vijay Abraham I 2019-04-17 832 if (IS_ERR(phy_provider)) {
71e2f5c5c2249d Kishon Vijay Abraham I 2019-04-17 833 ret = PTR_ERR(phy_provider);
71e2f5c5c2249d Kishon Vijay Abraham I 2019-04-17 834 goto clk_err;
71e2f5c5c2249d Kishon Vijay Abraham I 2019-04-17 835 }
71e2f5c5c2249d Kishon Vijay Abraham I 2019-04-17 836
71e2f5c5c2249d Kishon Vijay Abraham I 2019-04-17 837 return 0;
71e2f5c5c2249d Kishon Vijay Abraham I 2019-04-17 838
71e2f5c5c2249d Kishon Vijay Abraham I 2019-04-17 839 clk_err:
71e2f5c5c2249d Kishon Vijay Abraham I 2019-04-17 840 of_clk_del_provider(node);
dc404b65a54364 Miaoqian Lin 2022-01-05 @841 err_pm_disable:
dc404b65a54364 Miaoqian Lin 2022-01-05 842 pm_runtime_disable(dev);
71e2f5c5c2249d Kishon Vijay Abraham I 2019-04-17 843 return ret;
71e2f5c5c2249d Kishon Vijay Abraham I 2019-04-17 844 }
71e2f5c5c2249d Kishon Vijay Abraham I 2019-04-17 845
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all(a)lists.01.org
^ permalink raw reply
* Re: [PATCH v9 05/10] fsdax: fix function description
From: Darrick J. Wong @ 2022-01-05 17:50 UTC (permalink / raw)
To: Shiyang Ruan
Cc: linux-kernel, linux-xfs, nvdimm, linux-mm, linux-fsdevel,
dan.j.williams, david, hch, jane.chu
In-Reply-To: <20211226143439.3985960-6-ruansy.fnst@fujitsu.com>
On Sun, Dec 26, 2021 at 10:34:34PM +0800, Shiyang Ruan wrote:
> The function name has been changed, so the description should be updated
> too.
>
> Signed-off-by: Shiyang Ruan <ruansy.fnst@fujitsu.com>
Reviewed-by: Darrick J. Wong <djwong@kernel.org>
--D
> ---
> fs/dax.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/fs/dax.c b/fs/dax.c
> index 1f46810d4b68..2ee2d5a525ee 100644
> --- a/fs/dax.c
> +++ b/fs/dax.c
> @@ -390,7 +390,7 @@ static struct page *dax_busy_page(void *entry)
> }
>
> /*
> - * dax_lock_mapping_entry - Lock the DAX entry corresponding to a page
> + * dax_lock_page - Lock the DAX entry corresponding to a page
> * @page: The page whose entry we want to lock
> *
> * Context: Process context.
> --
> 2.34.1
>
>
>
^ permalink raw reply
* [PATCH v2] crypto: octeontx2 - Avoid stack variable overflow
From: Kees Cook @ 2022-01-05 17:49 UTC (permalink / raw)
To: Herbert Xu
Cc: Kees Cook, Boris Brezillon, Arnaud Ebalard, Srujana Challa,
David S. Miller, Suheil Chandran, Shijith Thotton,
Lukasz Bartosik, linux-crypto, Dan Carpenter, Jiapeng Chong,
linux-kernel, linux-hardening
Building with -Warray-bounds showed a stack variable array index
overflow. Increase the expected size of the array to avoid the warning:
In file included from ./include/linux/printk.h:555,
from ./include/asm-generic/bug.h:22,
from ./arch/x86/include/asm/bug.h:84,
from ./include/linux/bug.h:5,
from ./include/linux/mmdebug.h:5,
from ./include/linux/gfp.h:5,
from ./include/linux/firmware.h:7,
from drivers/crypto/marvell/octeontx2/otx2_cptpf_ucode.c:5:
drivers/crypto/marvell/octeontx2/otx2_cptpf_ucode.c: In function 'otx2_cpt_print_uc_dbg_info':
./include/linux/dynamic_debug.h:162:33: warning: array subscript 4 is above array bounds of 'u32[4]' {aka 'unsigned int[4]'} [-Warray-bounds]
162 | _dynamic_func_call(fmt, __dynamic_pr_debug, \
| ^
./include/linux/dynamic_debug.h:134:17: note: in definition of macro '__dynamic_func_call'
134 | func(&id, ##__VA_ARGS__); \
| ^~~~
./include/linux/dynamic_debug.h:162:9: note: in expansion of macro '_dynamic_func_call'
162 | _dynamic_func_call(fmt, __dynamic_pr_debug, \
| ^~~~~~~~~~~~~~~~~~
./include/linux/printk.h:570:9: note: in expansion of macro 'dynamic_pr_debug'
570 | dynamic_pr_debug(fmt, ##__VA_ARGS__)
| ^~~~~~~~~~~~~~~~
drivers/crypto/marvell/octeontx2/otx2_cptpf_ucode.c:1807:41: note: in expansion of macro 'pr_debug'
1807 | pr_debug("Mask: %8.8x %8.8x %8.8x %8.8x %8.8x",
| ^~~~~~~~
drivers/crypto/marvell/octeontx2/otx2_cptpf_ucode.c:1765:13: note: while referencing 'mask'
1765 | u32 mask[4];
| ^~~~
This is justified because the mask size (eng_grps->engs_num) can be at
most 144 (OTX2_CPT_MAX_ENGINES bits), which is larger than available
storage. 4 * 32 == 128, so this must be 5: 5 * 32bit = 150.
Additionally clear the mask before conversion so trailing bits are zero.
Cc: Herbert Xu <herbert@gondor.apana.org.au>
Cc: Boris Brezillon <bbrezillon@kernel.org>
Cc: Arnaud Ebalard <arno@natisbad.org>
Cc: Srujana Challa <schalla@marvell.com>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Suheil Chandran <schandran@marvell.com>
Cc: Shijith Thotton <sthotton@marvell.com>
Cc: Lukasz Bartosik <lbartosik@marvell.com>
Cc: linux-crypto@vger.kernel.org
Fixes: d9d7749773e8 ("crypto: octeontx2 - add apis for custom engine groups")
Signed-off-by: Kees Cook <keescook@chromium.org>
---
v1: https://lore.kernel.org/lkml/20211215225558.1995027-1-keescook@chromium.org/
v2:
- expliticly zero "mask"
- explain math in commit log
- move definition into local context
---
drivers/crypto/marvell/octeontx2/otx2_cptpf_ucode.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/crypto/marvell/octeontx2/otx2_cptpf_ucode.c b/drivers/crypto/marvell/octeontx2/otx2_cptpf_ucode.c
index 4c8ebdf671ca..1b4d425bbf0e 100644
--- a/drivers/crypto/marvell/octeontx2/otx2_cptpf_ucode.c
+++ b/drivers/crypto/marvell/octeontx2/otx2_cptpf_ucode.c
@@ -1753,7 +1753,6 @@ void otx2_cpt_print_uc_dbg_info(struct otx2_cptpf_dev *cptpf)
char engs_info[2 * OTX2_CPT_NAME_LENGTH];
struct otx2_cpt_eng_grp_info *grp;
struct otx2_cpt_engs_rsvd *engs;
- u32 mask[4];
int i, j;
pr_debug("Engine groups global info");
@@ -1785,6 +1784,8 @@ void otx2_cpt_print_uc_dbg_info(struct otx2_cptpf_dev *cptpf)
for (j = 0; j < OTX2_CPT_MAX_ETYPES_PER_GRP; j++) {
engs = &grp->engs[j];
if (engs->type) {
+ u32 mask[5] = { };
+
get_engs_info(grp, engs_info,
2 * OTX2_CPT_NAME_LENGTH, j);
pr_debug("Slot%d: %s", j, engs_info);
--
2.30.2
^ permalink raw reply related
* Re: [PATCH v1 09/13] KVM: x86/mmu: Split huge pages when dirty logging is enabled
From: David Matlack @ 2022-01-05 17:49 UTC (permalink / raw)
To: Peter Xu
Cc: Paolo Bonzini, kvm list, Ben Gardon, Joerg Roedel, Jim Mattson,
Wanpeng Li, Vitaly Kuznetsov, Sean Christopherson,
Janis Schoetterl-Glausch, Junaid Shahid, Oliver Upton,
Harish Barathvajasankar, Peter Shier, Nikunj A . Dadhania
In-Reply-To: <YdVOycjyfi4Wr9ke@xz-m1.local>
On Tue, Jan 4, 2022 at 11:55 PM Peter Xu <peterx@redhat.com> wrote:
>
> On Mon, Dec 13, 2021 at 10:59:14PM +0000, David Matlack wrote:
> > When dirty logging is enabled without initially-all-set, attempt to
> > split all huge pages in the memslot down to 4KB pages so that vCPUs
> > do not have to take expensive write-protection faults to split huge
> > pages.
> >
> > Huge page splitting is best-effort only. This commit only adds the
> > support for the TDP MMU, and even there splitting may fail due to out
> > of memory conditions. Failures to split a huge page is fine from a
> > correctness standpoint because we still always follow it up by write-
> > protecting any remaining huge pages.
> >
> > Signed-off-by: David Matlack <dmatlack@google.com>
>
> Thanks for adding the knob.
>
> Reviewed-by: Peter Xu <peterx@redhat.com>
>
> One trivial nitpick below:
>
> > +u64 make_huge_page_split_spte(u64 huge_spte, int huge_level, int index, unsigned int access)
> > +{
> > + u64 child_spte;
> > + int child_level;
> > +
> > + if (WARN_ON(is_mmio_spte(huge_spte)))
> > + return 0;
> > +
> > + if (WARN_ON(!is_shadow_present_pte(huge_spte)))
> > + return 0;
> > +
> > + if (WARN_ON(!is_large_pte(huge_spte)))
> > + return 0;
> > +
> > + child_spte = huge_spte;
> > + child_level = huge_level - 1;
> > +
> > + /*
> > + * The child_spte already has the base address of the huge page being
> > + * split. So we just have to OR in the offset to the page at the next
> > + * lower level for the given index.
> > + */
> > + child_spte |= (index * KVM_PAGES_PER_HPAGE(child_level)) << PAGE_SHIFT;
> > +
> > + if (child_level == PG_LEVEL_4K) {
> > + child_spte &= ~PT_PAGE_SIZE_MASK;
> > +
> > + /* Allow execution for 4K pages if it was disabled for NX HugePages. */
> > + if (is_nx_huge_page_enabled() && access & ACC_EXEC_MASK)
>
> IMHO clearer to use brackets ("A && (B & C)").
Agreed.
>
> I don't even see anywhere that the tdp mmu disables the EXEC bit for 4K.. if
> that's true then perhaps we can even drop "access" and this check? But I could
> have missed something.
TDP MMU always passes ACC_ALL so the access check could be omitted
from this patch. But it will be needed to support eager splitting for
the shadow MMU, which does not always allow execution.
>
> > + child_spte = mark_spte_executable(child_spte);
> > + }
> > +
> > + return child_spte;
> > +}
>
> --
> Peter Xu
>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.