* Re: [PATCH v5 21/23] powerpc/book3s64/hash/kuep: Enable KUEP on hash
From: Sandipan Das @ 2020-10-18 4:03 UTC (permalink / raw)
To: Aneesh Kumar K.V, linuxppc-dev, mpe
In-Reply-To: <20200827040931.297759-22-aneesh.kumar@linux.ibm.com>
On 27/08/20 9:39 am, Aneesh Kumar K.V wrote:
> Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
> ---
> arch/powerpc/mm/book3s64/pkeys.c | 7 ++++++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
>
Reviewed-by: Sandipan Das <sandipan@linux.ibm.com>
^ permalink raw reply
* Re: [PATCH v5 20/23] powerpc/book3s64/hash/kuap: Enable kuap on hash
From: Sandipan Das @ 2020-10-18 4:02 UTC (permalink / raw)
To: Aneesh Kumar K.V, linuxppc-dev, mpe
In-Reply-To: <20200827040931.297759-21-aneesh.kumar@linux.ibm.com>
On 27/08/20 9:39 am, Aneesh Kumar K.V wrote:
> Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
> ---
> arch/powerpc/mm/book3s64/pkeys.c | 7 ++++++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
>
Reviewed-by: Sandipan Das <sandipan@linux.ibm.com>
^ permalink raw reply
* Re: [PATCH v5 19/23] powerpc/book3s64/kuep: Use Key 3 to implement KUEP with hash translation.
From: Sandipan Das @ 2020-10-18 4:01 UTC (permalink / raw)
To: Aneesh Kumar K.V; +Cc: linuxppc-dev
In-Reply-To: <20200827040931.297759-20-aneesh.kumar@linux.ibm.com>
On 27/08/20 9:39 am, Aneesh Kumar K.V wrote:
> Radix use IAMR Key 0 and hash translation use IAMR key 3.
>
> Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
> ---
> arch/powerpc/include/asm/book3s/64/kup.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
Reviewed-by: Sandipan Das <sandipan@linux.ibm.com>
^ permalink raw reply
* Re: [PATCH v5 18/23] powerpc/book3s64/kuap: Use Key 3 to implement KUAP with hash translation.
From: Sandipan Das @ 2020-10-18 4:00 UTC (permalink / raw)
To: Aneesh Kumar K.V; +Cc: linuxppc-dev
In-Reply-To: <20200827040931.297759-19-aneesh.kumar@linux.ibm.com>
On 27/08/20 9:39 am, Aneesh Kumar K.V wrote:
> Radix use AMR Key 0 and hash translation use AMR key 3.
>
> Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
> ---
> arch/powerpc/include/asm/book3s/64/kup.h | 9 ++++-----
> 1 file changed, 4 insertions(+), 5 deletions(-)
>
Reviewed-by: Sandipan Das <sandipan@linux.ibm.com>
^ permalink raw reply
* Re: [PATCH v5 16/23] powerpc/book3s64/kuap: Restrict access to userspace based on userspace AMR
From: Sandipan Das @ 2020-10-18 4:00 UTC (permalink / raw)
To: Aneesh Kumar K.V; +Cc: linuxppc-dev
In-Reply-To: <20200827040931.297759-17-aneesh.kumar@linux.ibm.com>
On 27/08/20 9:39 am, Aneesh Kumar K.V wrote:
> If an application has configured address protection such that read/write is
> denied using pkey even the kernel should receive a FAULT on accessing the same.
>
> This patch use user AMR value stored in pt_regs.kuap to achieve the same.
>
> Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
> ---
> arch/powerpc/include/asm/book3s/64/kup.h | 12 +++++++++---
> 1 file changed, 9 insertions(+), 3 deletions(-)
>
Reviewed-by: Sandipan Das <sandipan@linux.ibm.com>
^ permalink raw reply
* Re: [PATCH v5 15/23] powerpc/book3s64/pkeys: Don't update SPRN_AMR when in kernel mode.
From: Sandipan Das @ 2020-10-18 3:52 UTC (permalink / raw)
To: Aneesh Kumar K.V; +Cc: linuxppc-dev
In-Reply-To: <20200827040931.297759-16-aneesh.kumar@linux.ibm.com>
On 27/08/20 9:39 am, Aneesh Kumar K.V wrote:
> Now that kernel correctly store/restore userspace AMR/IAMR values, avoid
> manipulating AMR and IAMR from the kernel on behalf of userspace.
>
> Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
> ---
> arch/powerpc/include/asm/book3s/64/kup.h | 18 ++++++++
> arch/powerpc/include/asm/processor.h | 4 --
> arch/powerpc/kernel/process.c | 4 --
> arch/powerpc/kernel/traps.c | 6 ---
> arch/powerpc/mm/book3s64/pkeys.c | 57 +++++-------------------
> 5 files changed, 28 insertions(+), 61 deletions(-)
>
Reviewed-by: Sandipan Das <sandipan@linux.ibm.com>
^ permalink raw reply
* Re: [PATCH v5 12/23] powerpc/book3s64/pkeys: Inherit correctly on fork.
From: Sandipan Das @ 2020-10-18 3:50 UTC (permalink / raw)
To: Aneesh Kumar K.V; +Cc: linuxppc-dev
In-Reply-To: <20200827040931.297759-13-aneesh.kumar@linux.ibm.com>
On 27/08/20 9:39 am, Aneesh Kumar K.V wrote:
> Child thread.kuap value is inherited from the parent in copy_thread_tls. We still
> need to make sure when the child returns from a fork in the kernel we start with the kernel
> default AMR value.
>
> Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
> ---
> arch/powerpc/kernel/process.c | 9 +++++++++
> 1 file changed, 9 insertions(+)
>
Reviewed-by: Sandipan Das <sandipan@linux.ibm.com>
^ permalink raw reply
* Re: [PATCH v5 13/23] powerpc/book3s64/pkeys: Reset userspace AMR correctly on exec
From: Sandipan Das @ 2020-10-18 3:50 UTC (permalink / raw)
To: Aneesh Kumar K.V; +Cc: linuxppc-dev
In-Reply-To: <20200827040931.297759-14-aneesh.kumar@linux.ibm.com>
On 27/08/20 9:39 am, Aneesh Kumar K.V wrote:
> On fork, we inherit from the parent and on exec, we should switch to default_amr values.
>
> Also, avoid changing the AMR register value within the kernel. The kernel now runs with
> different AMR values.
>
> Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
> ---
> arch/powerpc/include/asm/book3s/64/pkeys.h | 2 ++
> arch/powerpc/kernel/process.c | 6 +++++-
> arch/powerpc/mm/book3s64/pkeys.c | 16 ++--------------
> 3 files changed, 9 insertions(+), 15 deletions(-)
>
Reviewed-by: Sandipan Das <sandipan@linux.ibm.com>
^ permalink raw reply
* Re: [PATCH v5 11/23] powerpc/book3s64/pkeys: Store/restore userspace AMR/IAMR correctly on entry and exit from kernel
From: Sandipan Das @ 2020-10-18 3:49 UTC (permalink / raw)
To: Aneesh Kumar K.V; +Cc: linuxppc-dev
In-Reply-To: <20200827040931.297759-12-aneesh.kumar@linux.ibm.com>
On 27/08/20 9:39 am, Aneesh Kumar K.V wrote:
> This prepare kernel to operate with a different value than userspace AMR/IAMR.
> For this, AMR/IAMR need to be saved and restored on entry and return from the
> kernel.
>
> With KUAP we modify kernel AMR when accessing user address from the kernel
> via copy_to/from_user interfaces. We don't need to modify IAMR value in
> similar fashion.
>
> If MMU_FTR_PKEY is enabled we need to save AMR/IAMR in pt_regs on entering
> kernel from userspace. If not we can assume that AMR/IAMR is not modified
> from userspace.
>
> We need to save AMR if we have MMU_FTR_KUAP feature enabled and we are
> interrupted within kernel. This is required so that if we get interrupted
> within copy_to/from_user we continue with the right AMR value.
>
> If we hae MMU_FTR_KUEP enabled we need to restore IAMR on return to userspace
> beause kernel will be running with a different IAMR value.
>
> Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
> ---
> arch/powerpc/include/asm/book3s/64/kup.h | 177 ++++++++++++++++++++---
> arch/powerpc/include/asm/ptrace.h | 4 +-
> arch/powerpc/kernel/asm-offsets.c | 2 +
> arch/powerpc/kernel/entry_64.S | 6 +-
> arch/powerpc/kernel/exceptions-64s.S | 4 +-
> arch/powerpc/kernel/syscall_64.c | 30 +++-
> 6 files changed, 192 insertions(+), 31 deletions(-)
>
Reviewed-by: Sandipan Das <sandipan@linux.ibm.com>
^ permalink raw reply
* Re: [PATCH v5 09/23] powerpc/book3s64/kuap: Use Key 3 for kernel mapping with hash translation
From: Sandipan Das @ 2020-10-18 3:46 UTC (permalink / raw)
To: Aneesh Kumar K.V; +Cc: linuxppc-dev
In-Reply-To: <20200827040931.297759-10-aneesh.kumar@linux.ibm.com>
On 27/08/20 9:39 am, Aneesh Kumar K.V wrote:
> This patch updates kernel hash page table entries to use storage key 3
> for its mapping. This implies all kernel access will now use key 3 to
> control READ/WRITE. The patch also prevents the allocation of key 3 from
> userspace and UAMOR value is updated such that userspace cannot modify key 3.
>
> Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
> ---
> .../powerpc/include/asm/book3s/64/hash-pkey.h | 24 ++++++++++++++-----
> arch/powerpc/include/asm/book3s/64/hash.h | 2 +-
> arch/powerpc/include/asm/book3s/64/mmu-hash.h | 1 +
> arch/powerpc/include/asm/mmu_context.h | 2 +-
> arch/powerpc/mm/book3s64/hash_4k.c | 2 +-
> arch/powerpc/mm/book3s64/hash_64k.c | 4 ++--
> arch/powerpc/mm/book3s64/hash_hugepage.c | 2 +-
> arch/powerpc/mm/book3s64/hash_hugetlbpage.c | 2 +-
> arch/powerpc/mm/book3s64/hash_pgtable.c | 2 +-
> arch/powerpc/mm/book3s64/hash_utils.c | 10 ++++----
> arch/powerpc/mm/book3s64/pkeys.c | 4 ++++
> 11 files changed, 37 insertions(+), 18 deletions(-)
>
Reviewed-by: Sandipan Das <sandipan@linux.ibm.com>
^ permalink raw reply
* Re: [PATCH] powerpc/powernv/elog: Reduce elog message severity
From: Vasant Hegde @ 2020-10-17 17:12 UTC (permalink / raw)
To: Michael Ellerman, linuxppc-dev; +Cc: Mahesh Salgaonkar
In-Reply-To: <87d01s0z37.fsf@mpe.ellerman.id.au>
On 10/9/20 10:34 AM, Michael Ellerman wrote:
> Vasant Hegde <hegdevasant@linux.vnet.ibm.com> writes:
>> OPAL interrupts kernel whenever it has new error log. Kernel calls
>> interrupt handler (elog_event()) to retrieve event. elog_event makes
>> OPAL API call (opal_get_elog_size()) to retrieve elog info.
>>
>> In some case before kernel makes opal_get_elog_size() call, it gets interrupt
>> again. So second time when elog_event() calls opal_get_elog_size API OPAL
>> returns error.
>
> Can you give more detail there? Do you have a stack trace?
I observe below log in dmesg
[ 615.708709] ELOG: OPAL log info read failed
That means elog_event called twice for same error log event.
I don't have stack trace.
>
> We use IRQF_ONESHOT for elog_event(), which (I thought) meant it
> shouldn't be called again until it has completed.
Yes. I thought so.. But once in a while we get above message (mostly when we
have multiple event bits are set).
-Vasant
>
> So I'm unclear how you're seeing the behaviour you describe.
>
> cheers
>
>> Its safe to ignore this error. Hence reduce the severity
>> of log message.
>>
>> CC: Mahesh Salgaonkar <mahesh@linux.ibm.com>
>> Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
>> ---
>> arch/powerpc/platforms/powernv/opal-elog.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/arch/powerpc/platforms/powernv/opal-elog.c b/arch/powerpc/platforms/powernv/opal-elog.c
>> index 62ef7ad995da..67f435bb1ec4 100644
>> --- a/arch/powerpc/platforms/powernv/opal-elog.c
>> +++ b/arch/powerpc/platforms/powernv/opal-elog.c
>> @@ -247,7 +247,7 @@ static irqreturn_t elog_event(int irq, void *data)
>>
>> rc = opal_get_elog_size(&id, &size, &type);
>> if (rc != OPAL_SUCCESS) {
>> - pr_err("ELOG: OPAL log info read failed\n");
>> + pr_debug("ELOG: OPAL log info read failed\n");
>> return IRQ_HANDLED;
>> }
>>
>> --
>> 2.26.2
^ permalink raw reply
* [PATCH] powerpc/powernv/dump: Handle multiple writes to ack attribute
From: Vasant Hegde @ 2020-10-17 16:42 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Vasant Hegde, Mahesh Salgaonkar, Aneesh Kumar K . V
Even though we use self removing sysfs helper, we still need
to make sure we do the final kobject delete conditionally.
sysfs_remove_file_self() will handle parallel calls to remove
the sysfs attribute file and returns true only in the caller
that removed the attribute file. The other parallel callers
are returned false. Do the final kobject delete checking
the return value of sysfs_remove_file_self().
Cc: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
Cc: Mahesh Salgaonkar <mahesh@linux.ibm.com>
Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
---
arch/powerpc/platforms/powernv/opal-dump.c | 11 ++++++++---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/platforms/powernv/opal-dump.c b/arch/powerpc/platforms/powernv/opal-dump.c
index 0e6693bacb7e..00c5a59d82d9 100644
--- a/arch/powerpc/platforms/powernv/opal-dump.c
+++ b/arch/powerpc/platforms/powernv/opal-dump.c
@@ -88,9 +88,14 @@ static ssize_t dump_ack_store(struct dump_obj *dump_obj,
const char *buf,
size_t count)
{
- dump_send_ack(dump_obj->id);
- sysfs_remove_file_self(&dump_obj->kobj, &attr->attr);
- kobject_put(&dump_obj->kobj);
+ /*
+ * Try to self remove this attribute. If we are successful,
+ * delete the kobject itself.
+ */
+ if (sysfs_remove_file_self(&dump_obj->kobj, &attr->attr)) {
+ dump_send_ack(dump_obj->id);
+ kobject_put(&dump_obj->kobj);
+ }
return count;
}
--
2.26.2
^ permalink raw reply related
* [PATCH v2] powerpc/powernv/dump: Fix race while processing OPAL dump
From: Vasant Hegde @ 2020-10-17 16:42 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Vasant Hegde, Mahesh Salgaonkar
Every dump reported by OPAL is exported to userspace through a sysfs
interface and notified using kobject_uevent(). The userspace daemon
(opal_errd) then reads the dump and acknowledges that the dump is
saved safely to disk. Once acknowledged the kernel removes the
respective sysfs file entry causing respective resources to be
released including kobject.
However it's possible the userspace daemon may already be scanning
dump entries when a new sysfs dump entry is created by the kernel.
User daemon may read this new entry and ack it even before kernel can
notify userspace about it through kobject_uevent() call. If that
happens then we have a potential race between
dump_ack_store->kobject_put() and kobject_uevent which can lead to
use-after-free of a kernfs object resulting in a kernel crash.
This patch fixes this race by protecting the sysfs file
creation/notification by holding a reference count on kobject until we
safely send kobject_uevent().
The function create_dump_obj() returns the dump object which if used
by caller function will end up in use-after-free problem again.
However, the return value of create_dump_obj() function isn't being
used today and there is no need as well. Hence change it to return
void to make this fix complete.
Fixes: c7e64b9c ("powerpc/powernv Platform dump interface")
CC: Mahesh Salgaonkar <mahesh@linux.ibm.com>
Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
---
arch/powerpc/platforms/powernv/opal-dump.c | 41 +++++++++++++++-------
1 file changed, 29 insertions(+), 12 deletions(-)
diff --git a/arch/powerpc/platforms/powernv/opal-dump.c b/arch/powerpc/platforms/powernv/opal-dump.c
index 543c816fa99e..0e6693bacb7e 100644
--- a/arch/powerpc/platforms/powernv/opal-dump.c
+++ b/arch/powerpc/platforms/powernv/opal-dump.c
@@ -318,15 +318,14 @@ static ssize_t dump_attr_read(struct file *filep, struct kobject *kobj,
return count;
}
-static struct dump_obj *create_dump_obj(uint32_t id, size_t size,
- uint32_t type)
+static void create_dump_obj(uint32_t id, size_t size, uint32_t type)
{
struct dump_obj *dump;
int rc;
dump = kzalloc(sizeof(*dump), GFP_KERNEL);
if (!dump)
- return NULL;
+ return;
dump->kobj.kset = dump_kset;
@@ -346,21 +345,39 @@ static struct dump_obj *create_dump_obj(uint32_t id, size_t size,
rc = kobject_add(&dump->kobj, NULL, "0x%x-0x%x", type, id);
if (rc) {
kobject_put(&dump->kobj);
- return NULL;
+ return;
}
+ /*
+ * As soon as the sysfs file for this dump is created/activated there is
+ * a chance the opal_errd daemon (or any userspace) might read and
+ * acknowledge the dump before kobject_uevent() is called. If that
+ * happens then there is a potential race between
+ * dump_ack_store->kobject_put() and kobject_uevent() which leads to a
+ * use-after-free of a kernfs object resulting in a kernel crash.
+ *
+ * To avoid that, we need to take a reference on behalf of the bin file,
+ * so that our reference remains valid while we call kobject_uevent().
+ * We then drop our reference before exiting the function, leaving the
+ * bin file to drop the last reference (if it hasn't already).
+ */
+
+ /* Take a reference for the bin file */
+ kobject_get(&dump->kobj);
rc = sysfs_create_bin_file(&dump->kobj, &dump->dump_attr);
- if (rc) {
+ if (rc == 0) {
+ kobject_uevent(&dump->kobj, KOBJ_ADD);
+
+ pr_info("%s: New platform dump. ID = 0x%x Size %u\n",
+ __func__, dump->id, dump->size);
+ } else {
+ /* Drop reference count taken for bin file */
kobject_put(&dump->kobj);
- return NULL;
}
- pr_info("%s: New platform dump. ID = 0x%x Size %u\n",
- __func__, dump->id, dump->size);
-
- kobject_uevent(&dump->kobj, KOBJ_ADD);
-
- return dump;
+ /* Drop our reference */
+ kobject_put(&dump->kobj);
+ return;
}
static irqreturn_t process_dump(int irq, void *data)
--
2.26.2
^ permalink raw reply related
* [PATCH] asm-generic: Force inlining of get_order() to work around gcc10 poor decision
From: Christophe Leroy @ 2020-10-17 15:55 UTC (permalink / raw)
To: Arnd Bergmann, Masahiro Yamada, Andrew Morton
Cc: linux-arch, linuxppc-dev, linux-kernel
When building mpc885_ads_defconfig with gcc 10.1,
the function get_order() appears 50 times in vmlinux:
[linux]# ppc-linux-objdump -x vmlinux | grep get_order | wc -l
50
[linux]# size vmlinux
text data bss dec hex filename
3842620 675624 135160 4653404 47015c vmlinux
In the old days, marking a function 'static inline' was forcing
GCC to inline, but since commit ac7c3e4ff401 ("compiler: enable
CONFIG_OPTIMIZE_INLINING forcibly") GCC may decide to not inline
a function.
It looks like GCC 10 is taking poor decisions on this.
get_order() compiles into the following tiny function,
occupying 20 bytes of text.
0000007c <get_order>:
7c: 38 63 ff ff addi r3,r3,-1
80: 54 63 a3 3e rlwinm r3,r3,20,12,31
84: 7c 63 00 34 cntlzw r3,r3
88: 20 63 00 20 subfic r3,r3,32
8c: 4e 80 00 20 blr
By forcing get_order() to be __always_inline, the size of text is
reduced by 1940 bytes, that is almost twice the space occupied by
50 times get_order()
[linux-powerpc]# size vmlinux
text data bss dec hex filename
3840680 675588 135176 4651444 46f9b4 vmlinux
Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
---
include/asm-generic/getorder.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/asm-generic/getorder.h b/include/asm-generic/getorder.h
index e9f20b813a69..f2979e3a96b6 100644
--- a/include/asm-generic/getorder.h
+++ b/include/asm-generic/getorder.h
@@ -26,7 +26,7 @@
*
* The result is undefined if the size is 0.
*/
-static inline __attribute_const__ int get_order(unsigned long size)
+static __always_inline __attribute_const__ int get_order(unsigned long size)
{
if (__builtin_constant_p(size)) {
if (!size)
--
2.25.0
^ permalink raw reply related
* Re: [PATCH] powerpc/powernv/dump: Fix race while processing OPAL dump
From: Vasant Hegde @ 2020-10-17 12:26 UTC (permalink / raw)
To: Michael Ellerman, linuxppc-dev; +Cc: Mahesh Salgaonkar
In-Reply-To: <87a6ww0yzr.fsf@mpe.ellerman.id.au>
On 10/9/20 10:36 AM, Michael Ellerman wrote:
> Vasant Hegde <hegdevasant@linux.vnet.ibm.com> writes:
>> diff --git a/arch/powerpc/platforms/powernv/opal-dump.c b/arch/powerpc/platforms/powernv/opal-dump.c
>> index 543c816fa99e..7e6eeedec32b 100644
>> --- a/arch/powerpc/platforms/powernv/opal-dump.c
>> +++ b/arch/powerpc/platforms/powernv/opal-dump.c
>> @@ -346,21 +345,39 @@ static struct dump_obj *create_dump_obj(uint32_t id, size_t size,
>> rc = kobject_add(&dump->kobj, NULL, "0x%x-0x%x", type, id);
>> if (rc) {
>> kobject_put(&dump->kobj);
>> - return NULL;
>> + return;
>> }
>>
>> + /*
>> + * As soon as the sysfs file for this dump is created/activated there is
>> + * a chance the opal_errd daemon (or any userspace) might read and
>> + * acknowledge the dump before kobject_uevent() is called. If that
>> + * happens then there is a potential race between
>> + * dump_ack_store->kobject_put() and kobject_uevent() which leads to a
>> + * use-after-free of a kernfs object resulting in a kernel crash.
>> + *
>> + * To avoid that, we need to take a reference on behalf of the bin file,
>> + * so that our reference remains valid while we call kobject_uevent().
>> + * We then drop our reference before exiting the function, leaving the
>> + * bin file to drop the last reference (if it hasn't already).
>> + */
>> +
>> + /* Take a reference for the bin file */
>> + kobject_get(&dump->kobj);
>> rc = sysfs_create_bin_file(&dump->kobj, &dump->dump_attr);
>> if (rc) {
>> kobject_put(&dump->kobj);
>> - return NULL;
>> + /* Drop reference count taken for bin file */
>> + kobject_put(&dump->kobj);
>> + return;
>> }
>>
>> pr_info("%s: New platform dump. ID = 0x%x Size %u\n",
>> __func__, dump->id, dump->size);
>>
>> kobject_uevent(&dump->kobj, KOBJ_ADD);
>> -
>> - return dump;
>> + /* Drop reference count taken for bin file */
>> + kobject_put(&dump->kobj);
>> }
>
> I think this would be better if it was reworked along the lines of:
>
> aea948bb80b4 ("powerpc/powernv/elog: Fix race while processing OPAL error log event.")
Sure. Will fix it in v2.
-Vasant
^ permalink raw reply
* Re: [GIT PULL] Please pull powerpc/linux.git powerpc-5.10-1 tag
From: Michael Ellerman @ 2020-10-17 10:12 UTC (permalink / raw)
To: Linus Torvalds
Cc: ego, Stephen Kitt, Srikar Dronamraju, Ravi Bangoria,
Peter Zijlstra, jniethe5, mahesh, liushixin2,
Oliver O'Halloran, fthain, hofrat, Christoph Hellwig,
leobras.c, Aneesh Kumar K.V, wangwensheng4, Joel Stanley,
yangyingliang, Naveen N. Rao, mrochs, zhengbin, nathanl, biwen.li,
ajd, Stephen Rothwell, kjain, Nick Piggin, Qian Cai, clg,
Vaibhav Jain, Daniel Axtens, atrajeev, gromero, cheloha, yanaijie,
Linux Kernel Mailing List, Li Yang, Wolfram Sang, miaoqinglang,
fbarrat, Colin King, linuxppc-dev, David Miller, bauerman
In-Reply-To: <CAHk-=wjTwLKR1YhVHv5UzvCag5jxBeKVxLLxN9-CoxQYhi_=Kw@mail.gmail.com>
Linus Torvalds <torvalds@linux-foundation.org> writes:
> On Thu, Oct 15, 2020 at 8:24 PM Michael Ellerman <mpe@ellerman.id.au> wrote:
>>
>> Just two minor conflicts I'm aware of. The only slight subtlety is the conflict
>> in kasan_init() where "int ret" needs to move out of the for_each_mem_range()
>> and up to the function scope.
>
> Well, there was also a conflict for the dependencies of OCXL.
Yep, it was so trivial I didn't think it was worth calling out.
> I resolved that by ruthlessly simplifying the dependency:
>
> - depends on PPC_POWERNV && PCI && EEH && HOTPLUG_PCI_POWERNV
> - depends on PPC_POWERNV && PCI && EEH && PPC_XIVE_NATIVE
> ++ depends on HOTPLUG_PCI_POWERNV
>
> because all the other dependencies seem to be pointless.
>
> HOTPLUG_PCI_POWERNV already has a
>
> depends on PPC_POWERNV && EEH
>
> so there's no point in repeating those.
And PPC_POWERNV selects FORCE_PCI, which takes care of the dependency on
PCI.
> And PPC_XIVE_NATIVE is selected by PPC_POWERNV, so if PPC_POWERNV, we
> know PPC_XIVE_NATIVE is set.
>
> Maybe I missed something strange, so I'm just letting you know so you
> can blame me if I broke something.
No, that looks good to me. Thanks.
cheers
^ permalink raw reply
* Re: [PATCH 2/2] ASoC: fsl_spdif: Add support for i.MX8QM platform
From: Nicolin Chen @ 2020-10-17 1:23 UTC (permalink / raw)
To: Shengjiu Wang
Cc: devicetree, alsa-devel, timur, Xiubo.Lee, lgirdwood, linuxppc-dev,
tiwai, robh+dt, perex, broonie, festevam, linux-kernel
In-Reply-To: <1602739728-4433-2-git-send-email-shengjiu.wang@nxp.com>
On Thu, Oct 15, 2020 at 01:28:48PM +0800, Shengjiu Wang wrote:
> On i.MX8QM, there are separate interrupts for TX and RX.
>
> As the EDMA can't be configured to swing back to first FIFO
> after writing the second FIFO, so we need to force the burst
> size to be 2 on i.MX8QM. And EDMA don't support to shift
> the data from S24_LE to S16_LE, so the supported TX format
> is also different on i.MX8QM.
>
> Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com>
One small nit, yet I am okay if you don't resend. So:
Acked-by: Nicolin Chen <nicoleotsuka@gmail.com>
> /* Check if clk is a root clock that does not share clock source with others */
> @@ -1283,6 +1313,8 @@ static int fsl_spdif_probe(struct platform_device *pdev)
> /* Initialize this copy of the CPU DAI driver structure */
> memcpy(&spdif_priv->cpu_dai_drv, &fsl_spdif_dai, sizeof(fsl_spdif_dai));
> spdif_priv->cpu_dai_drv.name = dev_name(&pdev->dev);
> + spdif_priv->cpu_dai_drv.playback.formats =
> + spdif_priv->soc->tx_formats;
Kernel no longer has strict 80-character limit now, and it seems
to fits 80 characters?
^ permalink raw reply
* Re: [PATCH v4 1/2] ASoC: fsl_xcvr: Add XCVR ASoC CPU DAI driver
From: Nicolin Chen @ 2020-10-17 1:17 UTC (permalink / raw)
To: Viorel Suman (OSS)
Cc: devicetree, alsa-devel, Matthias Schiffer, Viorel Suman,
Timur Tabi, Xiubo Li, Shengjiu Wang, linuxppc-dev, Takashi Iwai,
Rob Herring, Liam Girdwood, Mark Brown, Philipp Zabel,
Cosmin-Gabriel Samoila, Jaroslav Kysela, Fabio Estevam,
linux-kernel
In-Reply-To: <20201013121733.83684-2-viorel.suman@oss.nxp.com>
On Tue, Oct 13, 2020 at 03:17:32PM +0300, Viorel Suman (OSS) wrote:
> From: Viorel Suman <viorel.suman@nxp.com>
>
> XCVR (Audio Transceiver) is a on-chip functional module found
> on i.MX8MP. It support HDMI2.1 eARC, HDMI1.4 ARC and SPDIF.
>
> Signed-off-by: Viorel Suman <viorel.suman@nxp.com>
Acked-by: Nicolin Chen <nicoleotsuka@gmail.com>
^ permalink raw reply
* [PATCH 0/2] Fixes for clang/lld
From: Bill Wendling @ 2020-10-17 0:47 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Paul Mackerras, Bill Wendling
These patches fix some compilation / linking issues with clang & lld.
Bill Wendling (2):
powerpc/wrapper: Add "-z notext" flag to disable diagnostic
powerpc/boot: Use clang when CC is clang
arch/powerpc/boot/Makefile | 4 ++++
arch/powerpc/boot/wrapper | 6 ++++--
2 files changed, 8 insertions(+), 2 deletions(-)
--
2.29.0.rc1.297.gfa9743e501-goog
^ permalink raw reply
* [PATCH 1/2] powerpc/wrapper: Add "-z notext" flag to disable diagnostic
From: Bill Wendling @ 2020-10-17 0:47 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Fangrui Song, Alan Modra, Paul Mackerras, Bill Wendling
In-Reply-To: <20201017004752.415054-1-morbo@google.com>
The "-z notext" flag disables reporting an error if DT_TEXTREL is set.
ld.lld: error: can't create dynamic relocation R_PPC64_ADDR64 against
symbol: _start in readonly segment; recompile object files with
-fPIC or pass '-Wl,-z,notext' to allow text relocations in the
output
>>> defined in
>>> referenced by crt0.o:(.text+0x8) in archive arch/powerpc/boot/wrapper.a
The BFD linker disables this by default (though it's configurable in
current versions). LLD enables this by default. So we add the flag to
keep LLD from emitting the error.
Cc: Fangrui Song <maskray@google.com>
Cc: Alan Modra <amodra@gmail.com>
Signed-off-by: Bill Wendling <morbo@google.com>
---
arch/powerpc/boot/wrapper | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/boot/wrapper b/arch/powerpc/boot/wrapper
index cd58a62e810d..e576d3e4b23f 100755
--- a/arch/powerpc/boot/wrapper
+++ b/arch/powerpc/boot/wrapper
@@ -46,6 +46,7 @@ compression=.gz
uboot_comp=gzip
pie=
format=
+notext=
# cross-compilation prefix
CROSS=
@@ -353,6 +354,7 @@ epapr)
platformo="$object/pseries-head.o $object/epapr.o $object/epapr-wrapper.o"
link_address='0x20000000'
pie=-pie
+ notext='-z notext'
;;
mvme5100)
platformo="$object/fixed-head.o $object/mvme5100.o"
@@ -493,8 +495,8 @@ if [ "$platform" != "miboot" ]; then
text_start="-Ttext $link_address"
fi
#link everything
- ${CROSS}ld -m $format -T $lds $text_start $pie $nodl -o "$ofile" $map \
- $platformo $tmp $object/wrapper.a
+ ${CROSS}ld -m $format -T $lds $text_start $pie $notext $nodl -o "$ofile" \
+ $map $platformo $tmp $object/wrapper.a
rm $tmp
fi
--
2.29.0.rc1.297.gfa9743e501-goog
^ permalink raw reply related
* [PATCH 2/2] powerpc/boot: Use clang when CC is clang
From: Bill Wendling @ 2020-10-17 0:47 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Fangrui Song, Alan Modra, Paul Mackerras, Bill Wendling
In-Reply-To: <20201017004752.415054-1-morbo@google.com>
The gcc compiler may not be available if CC is clang.
Cc: Fangrui Song <maskray@google.com>
Cc: Alan Modra <amodra@gmail.com>
Signed-off-by: Bill Wendling <morbo@google.com>
---
arch/powerpc/boot/Makefile | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile
index b88fd27a45f0..218f1c9adb5b 100644
--- a/arch/powerpc/boot/Makefile
+++ b/arch/powerpc/boot/Makefile
@@ -21,7 +21,11 @@
all: $(obj)/zImage
ifdef CROSS32_COMPILE
+ifdef CONFIG_CC_IS_CLANG
+ BOOTCC := $(CROSS32_COMPILE)clang
+else
BOOTCC := $(CROSS32_COMPILE)gcc
+endif
BOOTAR := $(CROSS32_COMPILE)ar
else
BOOTCC := $(CC)
--
2.29.0.rc1.297.gfa9743e501-goog
^ permalink raw reply related
* [PATCH] powerpc/boot: move the .got section to after the .dynamic section
From: Bill Wendling @ 2020-10-17 0:01 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Fangrui Song, Alan Modra, Paul Mackerras, Bill Wendling
Both .dynamic and .got are RELRO sections and should be placed together,
and LLD emits an error:
ld.lld: error: section: .got is not contiguous with other relro sections
Place them together to avoid this.
Cc: Fangrui Song <maskray@google.com>
Cc: Alan Modra <amodra@gmail.com>
Signed-off-by: Bill Wendling <morbo@google.com>
---
arch/powerpc/boot/zImage.lds.S | 21 +++++++++++----------
1 file changed, 11 insertions(+), 10 deletions(-)
diff --git a/arch/powerpc/boot/zImage.lds.S b/arch/powerpc/boot/zImage.lds.S
index a21f3a76e06f..d6f072865627 100644
--- a/arch/powerpc/boot/zImage.lds.S
+++ b/arch/powerpc/boot/zImage.lds.S
@@ -34,6 +34,17 @@ SECTIONS
__dynamic_start = .;
*(.dynamic)
}
+
+#ifdef CONFIG_PPC64_BOOT_WRAPPER
+ . = ALIGN(256);
+ .got :
+ {
+ __toc_start = .;
+ *(.got)
+ *(.toc)
+ }
+#endif
+
.hash : { *(.hash) }
.interp : { *(.interp) }
.rela.dyn :
@@ -76,16 +87,6 @@ SECTIONS
_esm_blob_end = .;
}
-#ifdef CONFIG_PPC64_BOOT_WRAPPER
- . = ALIGN(256);
- .got :
- {
- __toc_start = .;
- *(.got)
- *(.toc)
- }
-#endif
-
. = ALIGN(4096);
.bss :
{
--
2.29.0.rc1.297.gfa9743e501-goog
^ permalink raw reply related
* [powerpc:fixes-test] BUILD SUCCESS 8d0e2101274358d9b6b1f27232b40253ca48bab5
From: kernel test robot @ 2020-10-16 23:39 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git fixes-test
branch HEAD: 8d0e2101274358d9b6b1f27232b40253ca48bab5 powerpc/mce: Avoid nmi_enter/exit in real mode on pseries hash
elapsed time: 750m
configs tested: 119
configs skipped: 3
The following configs have been built successfully.
More configs may be tested in the coming days.
gcc tested configs:
arm defconfig
arm64 allyesconfig
arm64 defconfig
arm allyesconfig
arm allmodconfig
arc axs101_defconfig
sparc allyesconfig
powerpc klondike_defconfig
powerpc mpc832x_mds_defconfig
sh secureedge5410_defconfig
arm neponset_defconfig
sh urquell_defconfig
sh kfr2r09_defconfig
m68k mac_defconfig
parisc allyesconfig
sh ecovec24_defconfig
mips sb1250_swarm_defconfig
m68k atari_defconfig
arm s5pv210_defconfig
arm palmz72_defconfig
mips gpr_defconfig
arm spear13xx_defconfig
ia64 generic_defconfig
arm xcep_defconfig
arm tango4_defconfig
powerpc mpc85xx_cds_defconfig
xtensa virt_defconfig
powerpc g5_defconfig
csky alldefconfig
xtensa nommu_kc705_defconfig
arm aspeed_g4_defconfig
sh se7206_defconfig
arm prima2_defconfig
mips qi_lb60_defconfig
powerpc mpc837x_mds_defconfig
mips vocore2_defconfig
sh microdev_defconfig
c6x dsk6455_defconfig
powerpc wii_defconfig
mips loongson3_defconfig
powerpc mpc834x_mds_defconfig
powerpc icon_defconfig
sh ap325rxa_defconfig
mips maltaup_xpa_defconfig
microblaze defconfig
sh rts7751r2dplus_defconfig
sh edosk7705_defconfig
arm cm_x300_defconfig
arm netwinder_defconfig
arm milbeaut_m10v_defconfig
arm hisi_defconfig
ia64 alldefconfig
ia64 allmodconfig
ia64 defconfig
ia64 allyesconfig
m68k allmodconfig
m68k defconfig
m68k allyesconfig
nios2 defconfig
arc allyesconfig
nds32 allnoconfig
c6x allyesconfig
nds32 defconfig
nios2 allyesconfig
csky defconfig
alpha defconfig
alpha allyesconfig
xtensa allyesconfig
h8300 allyesconfig
arc defconfig
sh allmodconfig
parisc defconfig
s390 allyesconfig
s390 defconfig
i386 allyesconfig
sparc defconfig
i386 defconfig
mips allyesconfig
mips allmodconfig
powerpc allyesconfig
powerpc allmodconfig
powerpc allnoconfig
i386 randconfig-a005-20201016
i386 randconfig-a006-20201016
i386 randconfig-a001-20201016
i386 randconfig-a003-20201016
i386 randconfig-a004-20201016
i386 randconfig-a002-20201016
x86_64 randconfig-a016-20201016
x86_64 randconfig-a012-20201016
x86_64 randconfig-a015-20201016
x86_64 randconfig-a013-20201016
x86_64 randconfig-a014-20201016
x86_64 randconfig-a011-20201016
i386 randconfig-a016-20201016
i386 randconfig-a015-20201016
i386 randconfig-a013-20201016
i386 randconfig-a011-20201016
i386 randconfig-a012-20201016
i386 randconfig-a014-20201016
riscv nommu_k210_defconfig
riscv allyesconfig
riscv nommu_virt_defconfig
riscv allnoconfig
riscv defconfig
riscv rv32_defconfig
riscv allmodconfig
x86_64 rhel
x86_64 allyesconfig
x86_64 rhel-7.6-kselftests
x86_64 defconfig
x86_64 rhel-8.3
x86_64 kexec
clang tested configs:
x86_64 randconfig-a004-20201016
x86_64 randconfig-a002-20201016
x86_64 randconfig-a006-20201016
x86_64 randconfig-a001-20201016
x86_64 randconfig-a005-20201016
x86_64 randconfig-a003-20201016
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
^ permalink raw reply
* Re: [PATCH 15/20] dt-bindings: usb: meson-g12a-usb: Validate DWC2/DWC3 sub-nodes
From: Martin Blumenstingl @ 2020-10-16 20:47 UTC (permalink / raw)
To: Serge Semin
Cc: Neil Armstrong, Bjorn Andersson, Pavel Parkhomenko, Jerome Brunet,
Kevin Hilman, Andy Gross, linux-snps-arc, devicetree,
Mathias Nyman, Lad Prabhakar, Alexey Malahov, Rob Herring,
linux-amlogic, linux-arm-kernel, Roger Quadros, Felipe Balbi,
Greg Kroah-Hartman, Yoshihiro Shimoda, linux-usb, linux-mips,
Serge Semin, linux-kernel, Manu Gautam, linuxppc-dev
In-Reply-To: <20201014101402.18271-16-Sergey.Semin@baikalelectronics.ru>
On Wed, Oct 14, 2020 at 12:14 PM Serge Semin
<Sergey.Semin@baikalelectronics.ru> wrote:
>
> Amlogic G12A USB DT sub-nodes are supposed to be compatible with the
> generic DWC USB2 and USB3 devices. Since now we've got DT schemas for
> both of the later IP cores let's make sure that the Amlogic G12A USB
> DT nodes are fully evaluated including the DWC sub-nodes.
>
> Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
> Reviewed-by: Neil Armstrong <narmstrong@baylibre.com>
Reviewed-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
^ permalink raw reply
* Re: [PATCH 14/20] dt-bindings: usb: meson-g12a-usb: Fix FL-adj property value
From: Martin Blumenstingl @ 2020-10-16 20:46 UTC (permalink / raw)
To: Serge Semin
Cc: Neil Armstrong, Bjorn Andersson, Pavel Parkhomenko, Jerome Brunet,
Kevin Hilman, Andy Gross, linux-snps-arc, devicetree,
Mathias Nyman, Lad Prabhakar, Alexey Malahov, Rob Herring,
linux-amlogic, linux-arm-kernel, Roger Quadros, Felipe Balbi,
Greg Kroah-Hartman, Yoshihiro Shimoda, linux-usb, linux-mips,
Serge Semin, linux-kernel, Manu Gautam, linuxppc-dev
In-Reply-To: <20201014101402.18271-15-Sergey.Semin@baikalelectronics.ru>
On Wed, Oct 14, 2020 at 12:14 PM Serge Semin
<Sergey.Semin@baikalelectronics.ru> wrote:
>
> An empty snps,quirk-frame-length-adjustment won't cause any change
> performed by the driver. Moreover the DT schema validation will fail,
> since it expects the property being assigned with some value. So set
> fix the example by setting a valid FL-adj value in accordance with
> Neil Armstrong comment.
>
> Link: https://lore.kernel.org/linux-usb/20201010224121.12672-16-Sergey.Semin@baikalelectronics.ru/
> Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
> Acked-by: Neil Armstrong <narmstrong@baylibre.com>
Reviewed-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox