* [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 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
* 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
* 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: [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] 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
* [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
* [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] 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
* 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
* 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 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 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 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 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 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 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 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 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 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
* [PATCH v2 1/2] powerpc/44x: Don't support 440 when CONFIG_PPC_47x is set
From: Christophe Leroy @ 2020-10-18 17:25 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman
Cc: linuxppc-dev, linux-kernel
As stated in platform/44x/Kconfig, CONFIG_PPC_47x is not
compatible with 440 and 460 variants.
This is confirmed in asm/cache.h as L1_CACHE_SHIFT is different
for 47x, meaning a kernel built for 47x will not run correctly
on a 440.
In cputable, opt out all 440 and 460 variants when CONFIG_PPC_47x
is set. Also add a default match dedicated to 470.
Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
---
arch/powerpc/include/asm/cputable.h | 9 +++++----
arch/powerpc/include/asm/mmu.h | 7 +++----
arch/powerpc/kernel/cputable.c | 29 +++++++++++++++++++++--------
3 files changed, 29 insertions(+), 16 deletions(-)
diff --git a/arch/powerpc/include/asm/cputable.h b/arch/powerpc/include/asm/cputable.h
index d88bcb79f16d..4a0ddf66bd4a 100644
--- a/arch/powerpc/include/asm/cputable.h
+++ b/arch/powerpc/include/asm/cputable.h
@@ -523,11 +523,10 @@ enum {
#ifdef CONFIG_40x
CPU_FTRS_40X |
#endif
-#ifdef CONFIG_44x
- CPU_FTRS_44X | CPU_FTRS_440x6 |
-#endif
#ifdef CONFIG_PPC_47x
CPU_FTRS_47X | CPU_FTR_476_DD2 |
+#elif defined(CONFIG_44x)
+ CPU_FTRS_44X | CPU_FTRS_440x6 |
#endif
#ifdef CONFIG_E200
CPU_FTRS_E200 |
@@ -596,7 +595,9 @@ enum {
#ifdef CONFIG_40x
CPU_FTRS_40X &
#endif
-#ifdef CONFIG_44x
+#ifdef CONFIG_PPC_47x
+ CPU_FTRS_47X &
+#elif defined(CONFIG_44x)
CPU_FTRS_44X & CPU_FTRS_440x6 &
#endif
#ifdef CONFIG_E200
diff --git a/arch/powerpc/include/asm/mmu.h b/arch/powerpc/include/asm/mmu.h
index a1769c0426f2..bf5d3b5291f1 100644
--- a/arch/powerpc/include/asm/mmu.h
+++ b/arch/powerpc/include/asm/mmu.h
@@ -162,15 +162,14 @@ enum {
#ifdef CONFIG_40x
MMU_FTR_TYPE_40x |
#endif
-#ifdef CONFIG_44x
+#ifdef CONFIG_PPC_47x
+ MMU_FTR_TYPE_47x | MMU_FTR_USE_TLBIVAX_BCAST | MMU_FTR_LOCK_BCAST_INVAL |
+#elif defined(CONFIG_44x)
MMU_FTR_TYPE_44x |
#endif
#if defined(CONFIG_E200) || defined(CONFIG_E500)
MMU_FTR_TYPE_FSL_E | MMU_FTR_BIG_PHYS | MMU_FTR_USE_TLBILX |
#endif
-#ifdef CONFIG_PPC_47x
- MMU_FTR_TYPE_47x | MMU_FTR_USE_TLBIVAX_BCAST | MMU_FTR_LOCK_BCAST_INVAL |
-#endif
#ifdef CONFIG_PPC_BOOK3S_32
MMU_FTR_USE_HIGH_BATS |
#endif
diff --git a/arch/powerpc/kernel/cputable.c b/arch/powerpc/kernel/cputable.c
index 492c0b36aff6..cf80e6c8ed5e 100644
--- a/arch/powerpc/kernel/cputable.c
+++ b/arch/powerpc/kernel/cputable.c
@@ -1533,6 +1533,7 @@ static struct cpu_spec __initdata cpu_specs[] = {
#endif /* CONFIG_40x */
#ifdef CONFIG_44x
+#ifndef CONFIG_PPC_47x
{
.pvr_mask = 0xf0000fff,
.pvr_value = 0x40000850,
@@ -1815,7 +1816,19 @@ static struct cpu_spec __initdata cpu_specs[] = {
.machine_check = machine_check_440A,
.platform = "ppc440",
},
-#ifdef CONFIG_PPC_47x
+ { /* default match */
+ .pvr_mask = 0x00000000,
+ .pvr_value = 0x00000000,
+ .cpu_name = "(generic 44x PPC)",
+ .cpu_features = CPU_FTRS_44X,
+ .cpu_user_features = COMMON_USER_BOOKE,
+ .mmu_features = MMU_FTR_TYPE_44x,
+ .icache_bsize = 32,
+ .dcache_bsize = 32,
+ .machine_check = machine_check_4xx,
+ .platform = "ppc440",
+ }
+#else /* CONFIG_PPC_47x */
{ /* 476 DD2 core */
.pvr_mask = 0xffffffff,
.pvr_value = 0x11a52080,
@@ -1872,19 +1885,19 @@ static struct cpu_spec __initdata cpu_specs[] = {
.machine_check = machine_check_47x,
.platform = "ppc470",
},
-#endif /* CONFIG_PPC_47x */
{ /* default match */
.pvr_mask = 0x00000000,
.pvr_value = 0x00000000,
- .cpu_name = "(generic 44x PPC)",
- .cpu_features = CPU_FTRS_44X,
+ .cpu_name = "(generic 47x PPC)",
+ .cpu_features = CPU_FTRS_47X,
.cpu_user_features = COMMON_USER_BOOKE,
- .mmu_features = MMU_FTR_TYPE_44x,
+ .mmu_features = MMU_FTR_TYPE_47x,
.icache_bsize = 32,
- .dcache_bsize = 32,
- .machine_check = machine_check_4xx,
- .platform = "ppc440",
+ .dcache_bsize = 128,
+ .machine_check = machine_check_47x,
+ .platform = "ppc470",
}
+#endif /* CONFIG_PPC_47x */
#endif /* CONFIG_44x */
#ifdef CONFIG_E200
{ /* e200z5 */
--
2.25.0
^ permalink raw reply related
* [PATCH v2 2/2] powerpc/44x: Don't support 47x code and non 47x code at the same time
From: Christophe Leroy @ 2020-10-18 17:25 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <822833ce3dc10634339818f7d1ab616edf63b0c6.1603041883.git.christophe.leroy@csgroup.eu>
440/460 variants and 470 variants are not compatible, no
need to make code supporting both and using MMU features.
Just use CONFIG_PPC_47x to decide what to build.
Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
---
v2: Move outside #ifdef CONFIG_PPC_47x a label "1:" used by 44x
---
arch/powerpc/kernel/entry_32.S | 11 +++--------
arch/powerpc/mm/nohash/tlb_low.S | 29 +++++++----------------------
2 files changed, 10 insertions(+), 30 deletions(-)
diff --git a/arch/powerpc/kernel/entry_32.S b/arch/powerpc/kernel/entry_32.S
index 8cdc8bcde703..a425360deabb 100644
--- a/arch/powerpc/kernel/entry_32.S
+++ b/arch/powerpc/kernel/entry_32.S
@@ -439,15 +439,13 @@ syscall_exit_cont:
andis. r10,r0,DBCR0_IDM@h
bnel- load_dbcr0
#endif
-#ifdef CONFIG_44x
-BEGIN_MMU_FTR_SECTION
+#ifdef CONFIG_PPC_47x
lis r4,icache_44x_need_flush@ha
lwz r5,icache_44x_need_flush@l(r4)
cmplwi cr0,r5,0
bne- 2f
+#endif /* CONFIG_PPC_47x */
1:
-END_MMU_FTR_SECTION_IFCLR(MMU_FTR_TYPE_47x)
-#endif /* CONFIG_44x */
BEGIN_FTR_SECTION
lwarx r7,0,r1
END_FTR_SECTION_IFSET(CPU_FTR_NEED_PAIRED_STWCX)
@@ -948,10 +946,7 @@ restore_kuap:
/* interrupts are hard-disabled at this point */
restore:
-#ifdef CONFIG_44x
-BEGIN_MMU_FTR_SECTION
- b 1f
-END_MMU_FTR_SECTION_IFSET(MMU_FTR_TYPE_47x)
+#if defined(CONFIG_44x) && !defined(CONFIG_PPC_47x)
lis r4,icache_44x_need_flush@ha
lwz r5,icache_44x_need_flush@l(r4)
cmplwi cr0,r5,0
diff --git a/arch/powerpc/mm/nohash/tlb_low.S b/arch/powerpc/mm/nohash/tlb_low.S
index eaeee402f96e..68797e072f55 100644
--- a/arch/powerpc/mm/nohash/tlb_low.S
+++ b/arch/powerpc/mm/nohash/tlb_low.S
@@ -92,36 +92,25 @@ _GLOBAL(__tlbil_va)
tlbsx. r6,0,r3
bne 10f
sync
-BEGIN_MMU_FTR_SECTION
- b 2f
-END_MMU_FTR_SECTION_IFSET(MMU_FTR_TYPE_47x)
+#ifndef CONFIG_PPC_47x
/* On 440 There are only 64 TLB entries, so r3 < 64, which means bit
* 22, is clear. Since 22 is the V bit in the TLB_PAGEID, loading this
* value will invalidate the TLB entry.
*/
tlbwe r6,r6,PPC44x_TLB_PAGEID
- isync
-10: wrtee r10
- blr
-2:
-#ifdef CONFIG_PPC_47x
+#else
oris r7,r6,0x8000 /* specify way explicitly */
clrrwi r4,r3,12 /* get an EPN for the hashing with V = 0 */
ori r4,r4,PPC47x_TLBE_SIZE
tlbwe r4,r7,0 /* write it */
+#endif /* !CONFIG_PPC_47x */
isync
- wrtee r10
+10: wrtee r10
blr
-#else /* CONFIG_PPC_47x */
-1: trap
- EMIT_BUG_ENTRY 1b,__FILE__,__LINE__,0;
-#endif /* !CONFIG_PPC_47x */
_GLOBAL(_tlbil_all)
_GLOBAL(_tlbil_pid)
-BEGIN_MMU_FTR_SECTION
- b 2f
-END_MMU_FTR_SECTION_IFSET(MMU_FTR_TYPE_47x)
+#ifndef CONFIG_PPC_47x
li r3,0
sync
@@ -136,8 +125,7 @@ END_MMU_FTR_SECTION_IFSET(MMU_FTR_TYPE_47x)
isync
blr
-2:
-#ifdef CONFIG_PPC_47x
+#else
/* 476 variant. There's not simple way to do this, hopefully we'll
* try to limit the amount of such full invalidates
*/
@@ -179,11 +167,8 @@ END_MMU_FTR_SECTION_IFSET(MMU_FTR_TYPE_47x)
b 1b /* Then loop */
1: isync /* Sync shadows */
wrtee r11
-#else /* CONFIG_PPC_47x */
-1: trap
- EMIT_BUG_ENTRY 1b,__FILE__,__LINE__,0;
-#endif /* !CONFIG_PPC_47x */
blr
+#endif /* !CONFIG_PPC_47x */
#ifdef CONFIG_PPC_47x
--
2.25.0
^ permalink raw reply related
* [PATCH AUTOSEL 5.9 076/111] scsi: ibmvfc: Fix error return in ibmvfc_probe()
From: Sasha Levin @ 2020-10-18 19:17 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Sasha Levin, Tyrel Datwyler, Martin K . Petersen, linux-scsi,
Jing Xiangfeng, linuxppc-dev
In-Reply-To: <20201018191807.4052726-1-sashal@kernel.org>
From: Jing Xiangfeng <jingxiangfeng@huawei.com>
[ Upstream commit 5e48a084f4e824e1b624d3fd7ddcf53d2ba69e53 ]
Fix to return error code PTR_ERR() from the error handling case instead of
0.
Link: https://lore.kernel.org/r/20200907083949.154251-1-jingxiangfeng@huawei.com
Acked-by: Tyrel Datwyler <tyreld@linux.ibm.com>
Signed-off-by: Jing Xiangfeng <jingxiangfeng@huawei.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/scsi/ibmvscsi/ibmvfc.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/scsi/ibmvscsi/ibmvfc.c b/drivers/scsi/ibmvscsi/ibmvfc.c
index ea7c8930592dc..70daa0605082d 100644
--- a/drivers/scsi/ibmvscsi/ibmvfc.c
+++ b/drivers/scsi/ibmvscsi/ibmvfc.c
@@ -4928,6 +4928,7 @@ static int ibmvfc_probe(struct vio_dev *vdev, const struct vio_device_id *id)
if (IS_ERR(vhost->work_thread)) {
dev_err(dev, "Couldn't create kernel thread: %ld\n",
PTR_ERR(vhost->work_thread));
+ rc = PTR_ERR(vhost->work_thread);
goto free_host_mem;
}
--
2.25.1
^ permalink raw reply related
* [PATCH AUTOSEL 5.8 071/101] scsi: ibmvfc: Fix error return in ibmvfc_probe()
From: Sasha Levin @ 2020-10-18 19:19 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Sasha Levin, Tyrel Datwyler, Martin K . Petersen, linux-scsi,
Jing Xiangfeng, linuxppc-dev
In-Reply-To: <20201018192026.4053674-1-sashal@kernel.org>
From: Jing Xiangfeng <jingxiangfeng@huawei.com>
[ Upstream commit 5e48a084f4e824e1b624d3fd7ddcf53d2ba69e53 ]
Fix to return error code PTR_ERR() from the error handling case instead of
0.
Link: https://lore.kernel.org/r/20200907083949.154251-1-jingxiangfeng@huawei.com
Acked-by: Tyrel Datwyler <tyreld@linux.ibm.com>
Signed-off-by: Jing Xiangfeng <jingxiangfeng@huawei.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/scsi/ibmvscsi/ibmvfc.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/scsi/ibmvscsi/ibmvfc.c b/drivers/scsi/ibmvscsi/ibmvfc.c
index 635f6f9cffc40..ef91f3d01f989 100644
--- a/drivers/scsi/ibmvscsi/ibmvfc.c
+++ b/drivers/scsi/ibmvscsi/ibmvfc.c
@@ -4928,6 +4928,7 @@ static int ibmvfc_probe(struct vio_dev *vdev, const struct vio_device_id *id)
if (IS_ERR(vhost->work_thread)) {
dev_err(dev, "Couldn't create kernel thread: %ld\n",
PTR_ERR(vhost->work_thread));
+ rc = PTR_ERR(vhost->work_thread);
goto free_host_mem;
}
--
2.25.1
^ permalink raw reply related
* [PATCH AUTOSEL 5.4 55/80] scsi: ibmvfc: Fix error return in ibmvfc_probe()
From: Sasha Levin @ 2020-10-18 19:22 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Sasha Levin, Tyrel Datwyler, Martin K . Petersen, linux-scsi,
Jing Xiangfeng, linuxppc-dev
In-Reply-To: <20201018192231.4054535-1-sashal@kernel.org>
From: Jing Xiangfeng <jingxiangfeng@huawei.com>
[ Upstream commit 5e48a084f4e824e1b624d3fd7ddcf53d2ba69e53 ]
Fix to return error code PTR_ERR() from the error handling case instead of
0.
Link: https://lore.kernel.org/r/20200907083949.154251-1-jingxiangfeng@huawei.com
Acked-by: Tyrel Datwyler <tyreld@linux.ibm.com>
Signed-off-by: Jing Xiangfeng <jingxiangfeng@huawei.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/scsi/ibmvscsi/ibmvfc.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/scsi/ibmvscsi/ibmvfc.c b/drivers/scsi/ibmvscsi/ibmvfc.c
index df897df5cafee..8a76284b59b08 100644
--- a/drivers/scsi/ibmvscsi/ibmvfc.c
+++ b/drivers/scsi/ibmvscsi/ibmvfc.c
@@ -4788,6 +4788,7 @@ static int ibmvfc_probe(struct vio_dev *vdev, const struct vio_device_id *id)
if (IS_ERR(vhost->work_thread)) {
dev_err(dev, "Couldn't create kernel thread: %ld\n",
PTR_ERR(vhost->work_thread));
+ rc = PTR_ERR(vhost->work_thread);
goto free_host_mem;
}
--
2.25.1
^ permalink raw reply related
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