[PATCH v3 2/2] scsi: ibmvfc: interface updates for future FPIN and MQ support

2020-09-04 Thread Tyrel Datwyler
VIOS partitions with SLI-4 enabled Emulex adapters will be capable of driving IO in parallel through mulitple work queues or channels, and with new hyperviosr firmware that supports multiple interrupt sources an ibmvfc NPIV single initiator can be modified to exploit end to end channelization in a

[PATCH v3 1/2] scsi: ibmvfc: use compiler attribute defines instead of __attribute__()

2020-09-04 Thread Tyrel Datwyler
Update ibmvfc.h structs to use the preferred __packed and __aligned() attribute macros defined in include/linux/compiler_attributes.h in place of __attribute__(). Signed-off-by: Tyrel Datwyler --- drivers/scsi/ibmvscsi/ibmvfc.h | 56 +- 1 file changed, 28

[PATCH 5/5] powerpc/tau: Disable TAU between measurements

2020-09-04 Thread Finn Thain
Enabling CONFIG_TAU_INT causes random crashes: Unrecoverable exception 1700 at c0009414 (msr=1000) Oops: Unrecoverable exception, sig: 6 [#1] BE PAGE_SIZE=4K MMU=Hash SMP NR_CPUS=2 PowerMac Modules linked in: CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.7.0-pmac-00043-gd5f545e1a8593 #5 NIP:

[PATCH 4/5] powerpc/tau: Check processor type before enabling TAU interrupt

2020-09-04 Thread Finn Thain
According to Freescale's documentation, MPC74XX processors have an erratum that prevents the TAU interrupt from working, so don't try to use it when running on those processors. Fixes: 1da177e4c3f41 ("Linux-2.6.12-rc2") Tested-by: Stan Johnson Signed-off-by: Finn Thain ---

[PATCH 2/5] powerpc/tau: Convert from timer to workqueue

2020-09-04 Thread Finn Thain
Since commit 19dbdcb8039cf ("smp: Warn on function calls from softirq context") the Thermal Assist Unit driver causes a warning like the following when CONFIG_SMP is enabled. [ cut here ] WARNING: CPU: 0 PID: 0 at kernel/smp.c:428 smp_call_function_many_cond+0xf4/0x38c

[PATCH 3/5] powerpc/tau: Remove duplicated set_thresholds() call

2020-09-04 Thread Finn Thain
The commentary at the call site seems to disagree with the code. The conditional prevents calling set_thresholds() via the exception handler, which appears to crash. Perhaps that's because it immediately triggers another TAU exception. Anyway, calling set_thresholds() from TAUupdate() is redundant

[PATCH 1/5] powerpc/tau: Use appropriate temperature sample interval

2020-09-04 Thread Finn Thain
According to the MPC750 Users Manual, the SITV value in Thermal Management Register 3 is 13 bits long. The present code calculates the SITV value as 60 * 500 cycles. This would overflow to give 10 us on a 500 MHz CPU rather than the intended 60 us. (But according to the Microprocessor Datasheet,

[PATCH 0/5] powerpc/tau: TAU driver fixes

2020-09-04 Thread Finn Thain
This patch series fixes various bugs in the Thermal Assist Unit driver. It was tested on 266 MHz and 292 MHz PowerBook G3 laptops. Finn Thain (5): powerpc/tau: Use appropriate temperature sample interval powerpc/tau: Convert from timer to workqueue powerpc/tau: Remove duplicated

[Bug 208181] BUG: KASAN: stack-out-of-bounds in strcmp+0x58/0xd8

2020-09-04 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=208181 Erhard F. (erhar...@mailbox.org) changed: What|Removed |Added Status|NEW |RESOLVED

[Bug 205099] KASAN hit at raid6_pq: BUG: Unable to handle kernel data access at 0x00f0fd0d

2020-09-04 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=205099 Erhard F. (erhar...@mailbox.org) changed: What|Removed |Added Attachment #288413|0 |1 is obsolete|

[Bug 205099] KASAN hit at raid6_pq: BUG: Unable to handle kernel data access at 0x00f0fd0d

2020-09-04 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=205099 Erhard F. (erhar...@mailbox.org) changed: What|Removed |Added Attachment #287625|0 |1 is obsolete|

[Bug 208181] BUG: KASAN: stack-out-of-bounds in strcmp+0x58/0xd8

2020-09-04 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=208181 --- Comment #18 from Erhard F. (erhar...@mailbox.org) --- Created attachment 292339 --> https://bugzilla.kernel.org/attachment.cgi?id=292339=edit kernel .config (5.9-rc3, PowerMac G4 DP) -- You are receiving this mail because: You are

[Bug 208181] BUG: KASAN: stack-out-of-bounds in strcmp+0x58/0xd8

2020-09-04 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=208181 --- Comment #17 from Erhard F. (erhar...@mailbox.org) --- Created attachment 292337 --> https://bugzilla.kernel.org/attachment.cgi?id=292337=edit dmesg (5.9-rc3, INLINE KASAN, PowerMac G4 DP) Re-tried with 5.9-rc3 (inline KASAN). The original

RE: remove the last set_fs() in common code, and remove it for x86 and powerpc v3

2020-09-04 Thread David Laight
From: Alexey Dobriyan > Sent: 04 September 2020 18:58 > > On Fri, Sep 04, 2020 at 08:00:24AM +0200, Ingo Molnar wrote: > > * Christoph Hellwig wrote: > > > this series removes the last set_fs() used to force a kernel address > > > space for the uaccess code in the kernel read/write/splice code,

Re: [PATCH 0/1] powerpc/numa: do not skip node 0 in lookup table

2020-09-04 Thread Daniel Henrique Barboza
I discussed this a bit with Aneesh Kumar in IBM internal Slack, a few weeks ago, and he informed me that that this patch does not make sense with the design used by the kernel. The kernel will assume that, for node 0, all associativity domains must also be zeroed. This is why node 0 is skipped

Re: remove the last set_fs() in common code, and remove it for x86 and powerpc v3

2020-09-04 Thread Linus Torvalds
On Fri, Sep 4, 2020 at 10:58 AM Alexey Dobriyan wrote: > > set_fs() is older than some kernel hackers! > > $ cd linux-0.11/ > $ find . -type f -name '*.h' | xargs grep -e set_fs -w -n -A3 Oh, it's older than that. It was there (as set_fs) in 0.10, and may even predate that. But

Re: remove the last set_fs() in common code, and remove it for x86 and powerpc v3

2020-09-04 Thread Alexey Dobriyan
On Fri, Sep 04, 2020 at 08:00:24AM +0200, Ingo Molnar wrote: > * Christoph Hellwig wrote: > > this series removes the last set_fs() used to force a kernel address > > space for the uaccess code in the kernel read/write/splice code, and then > > stops implementing the address space overrides

[PATCH] kbuild: preprocess module linker script

2020-09-04 Thread Masahiro Yamada
There was a request to preprocess the module linker script like we do for the vmlinux one (https://lkml.org/lkml/2020/8/21/512). The difference between vmlinux.lds and module.lds is that the latter is needed for external module builds, thus must be cleaned up by 'make mrproper' instead of 'make

[PATCH 3/3] powerpc/uaccess: Remove __put_user_asm() and __put_user_asm2()

2020-09-04 Thread Christophe Leroy
__put_user_asm() and __put_user_asm2() are not used anymore. Remove them. Signed-off-by: Christophe Leroy --- arch/powerpc/include/asm/uaccess.h | 41 -- 1 file changed, 5 insertions(+), 36 deletions(-) diff --git a/arch/powerpc/include/asm/uaccess.h

[PATCH 2/3] powerpc/uaccess: Switch __patch_instruction() to __put_user_asm_goto()

2020-09-04 Thread Christophe Leroy
__patch_instruction() is the only user of __put_user_asm() outside of asm/uaccess.h Switch to the new __put_user_asm_goto() to enable retirement of __put_user_asm() in a later patch. Signed-off-by: Christophe Leroy --- arch/powerpc/lib/code-patching.c | 17 +++-- 1 file changed, 7

[PATCH 1/3] powerpc/uaccess: Switch __put_user_size_allowed() to __put_user_asm_goto()

2020-09-04 Thread Christophe Leroy
__put_user_asm_goto() provides more flexibility to GCC and avoids using a local variable to tell if the write succeeded or not. GCC can then avoid implementing a cmp in the fast path. See the difference for a small function like the PPC64 version of save_general_regs() in

[PATCH] powerpc/uaccess: Add pre-update addressing to __put_user_asm_goto()

2020-09-04 Thread Christophe Leroy
Enable pre-update addressing mode in __put_user_asm_goto() Signed-off-by: Christophe Leroy --- arch/powerpc/include/asm/uaccess.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/powerpc/include/asm/uaccess.h b/arch/powerpc/include/asm/uaccess.h index

Re: ptrace_syscall_32 is failing

2020-09-04 Thread Thomas Gleixner
Andy, On Wed, Sep 02 2020 at 09:49, Andy Lutomirski wrote: > On Wed, Sep 2, 2020 at 1:29 AM Thomas Gleixner wrote: >> >> But you might tell me where exactly you want to inject the SIGTRAP in >> the syscall exit code flow. > > It would be a bit complicated. Definitely after any signals from the

RE: [PATCH 12/14] x86: remove address space overrides using set_fs()

2020-09-04 Thread David Laight
From: Linus Torvalds > Sent: 04 September 2020 00:26 > > On Thu, Sep 3, 2020 at 2:30 PM David Laight wrote: > > > > A non-canonical (is that the right term) address between the highest > > valid user address and the lowest valid kernel address (7ffe to fffe?) > > will fault anyway. > > Yes. >

Re: [PATCH 12/14] x86: remove address space overrides using set_fs()

2020-09-04 Thread Christoph Hellwig
On Fri, Sep 04, 2020 at 08:38:13AM +0200, Christoph Hellwig wrote: > > Wait a sec... how is that supposed to build with X86_5LEVEL? Do you mean > > > > #define LOAD_TASK_SIZE_MINUS_N(n) \ > > ALTERNATIVE __stringify(mov $((1 << 47) - 4096 - (n)),%rdx), \ > > __stringify(mov

Re: [PATCH v4 00/13] mm/debug_vm_pgtable fixes

2020-09-04 Thread Anshuman Khandual
On 09/02/2020 05:12 PM, Aneesh Kumar K.V wrote: > This patch series includes fixes for debug_vm_pgtable test code so that > they follow page table updates rules correctly. The first two patches > introduce > changes w.r.t ppc64. The patches are included in this series for > completeness. We

Re: [PATCH 12/14] x86: remove address space overrides using set_fs()

2020-09-04 Thread Christoph Hellwig
On Fri, Sep 04, 2020 at 03:55:10AM +0100, Al Viro wrote: > On Thu, Sep 03, 2020 at 04:22:40PM +0200, Christoph Hellwig wrote: > > > diff --git a/arch/x86/lib/getuser.S b/arch/x86/lib/getuser.S > > index c8a85b512796e1..94f7be4971ed04 100644 > > --- a/arch/x86/lib/getuser.S > > +++

Re: [PATCH v4 12/13] mm/debug_vm_pgtable/hugetlb: Disable hugetlb test on ppc64

2020-09-04 Thread Anshuman Khandual
On 09/02/2020 05:12 PM, Aneesh Kumar K.V wrote: > The seems to be missing quite a lot of details w.r.t allocating > the correct pgtable_t page (huge_pte_alloc()), holding the right > lock (huge_pte_lock()) etc. The vma used is also not a hugetlb VMA. > > ppc64 do have runtime checks within

Re: [PATCH v1 02/10] powerpc/kernel/iommu: Align size for IOMMU_PAGE_SIZE on iommu_*_coherent()

2020-09-04 Thread Leonardo Bras
On Thu, 2020-09-03 at 14:41 +1000, Alexey Kardashevskiy wrote: > I am new to this, so I am trying to understand how a memory page mapped > > as DMA, and used for something else could be a problem. > > From the device prospective, there is PCI space and everything from 0 > till 1<<64 is

Re: [PATCH v4 11/13] mm/debug_vm_pgtable/pmd_clear: Don't use pmd/pud_clear on pte entries

2020-09-04 Thread Anshuman Khandual
On 09/02/2020 05:12 PM, Aneesh Kumar K.V wrote: > pmd_clear() should not be used to clear pmd level pte entries. > > Signed-off-by: Aneesh Kumar K.V > --- > mm/debug_vm_pgtable.c | 7 --- > 1 file changed, 4 insertions(+), 3 deletions(-) > > diff --git a/mm/debug_vm_pgtable.c

Re: remove the last set_fs() in common code, and remove it for x86 and powerpc v3

2020-09-04 Thread Ingo Molnar
* Christoph Hellwig wrote: > Hi all, > > this series removes the last set_fs() used to force a kernel address > space for the uaccess code in the kernel read/write/splice code, and then > stops implementing the address space overrides entirely for x86 and > powerpc. Cool! For the x86 bits: