Re: Re: [PATCH v3 7/9] KVM: PPC: Ultravisor: Restrict LDBAR access
On Sat, Jun 15, 2019 at 05:43:34PM +1000, Paul Mackerras wrote: > On Thu, Jun 06, 2019 at 02:36:12PM -0300, Claudio Carvalho wrote: > > When the ultravisor firmware is available, it takes control over the > > LDBAR register. In this case, thread-imc updates and save/restore > > operations on the LDBAR register are handled by ultravisor. > > > > Signed-off-by: Claudio Carvalho > > Signed-off-by: Ram Pai > > Acked-by: Paul Mackerras > > Just a note on the signed-off-by: it's a bit weird to have Ram's > signoff when he is neither the author nor the sender of the patch. > The author is assumed to be Claudio; if that is not correct then the > patch should have a From: line at the start telling us who the author > is, and ideally that person should have a signoff line before > Claudio's signoff as the sender of the patch. Ryan originally wrote this patch, which I than modified, before Claudio further modified it to its current form. So I think the author should be Ryan. RP
Re: [PATCH] powerpc/pseries: fix oops in hotplug memory notifier
On 06/13/2019 06:05 PM, Nathan Lynch wrote: > Nathan Lynch writes: > >> Tyrel Datwyler writes: >> >>> Maybe we are ok with this behavior as I haven't dug deep enough into the >>> memory >>> subsystem here to really understand what the memory code is updating, but >>> it is >>> concerning that we are doing it in some cases, but not all. >> >> I hope I've made a good case above that the notifier does not do any >> useful work, and a counterpart for the v2 format isn't needed. Do you >> agree? >> >> If so, I'll send a patch later to remove the notifier altogether. In the >> near term I would still like this minimal fix to go in. > > Tyrel, ack? > Sure, lets start with simple case to fix the crash. -Tyrel
Re: [GIT PULL] Please pull powerpc/linux.git powerpc-5.2-4 tag
The pull request you sent on Sat, 15 Jun 2019 23:34:46 +1000: > https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git > tags/powerpc-5.2-4 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/fa1827d7731ac24f44309ddc2ca806650912bf0e Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
[PATCH] powerpc/4xx/uic: clear pending interrupt after irq type/pol change
When testing out gpio-keys with a button, a spurious interrupt (and therefore a key press or release event) gets triggered as soon as the driver enables the irq line for the first time. This patch clears any potential bogus generated interrupt that was caused by the switching of the associated irq's type and polarity. Signed-off-by: Christian Lamparter --- arch/powerpc/platforms/4xx/uic.c | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/powerpc/platforms/4xx/uic.c b/arch/powerpc/platforms/4xx/uic.c index 31f12ad37a98..36fb66ce54cf 100644 --- a/arch/powerpc/platforms/4xx/uic.c +++ b/arch/powerpc/platforms/4xx/uic.c @@ -154,6 +154,7 @@ static int uic_set_irq_type(struct irq_data *d, unsigned int flow_type) mtdcr(uic->dcrbase + UIC_PR, pr); mtdcr(uic->dcrbase + UIC_TR, tr); + mtdcr(uic->dcrbase + UIC_SR, ~mask); raw_spin_unlock_irqrestore(>lock, flags); -- 2.20.1
Re: [PATCH] powerpc/mm/32s: only use MMU to mark initmem NX if STRICT_KERNEL_RWX
On Jun 15 2019, Christophe Leroy wrote: > Andreas Schwab a écrit : > >> If STRICT_KERNEL_RWX is disabled, never use the MMU to mark initmen >> nonexecutable. > > I dont understand, can you elaborate ? It breaks suspend. > This area is mapped with BATs so using change_page_attr() is pointless. There must be a reason STRICT_KERNEL_RWX is not available with HIBERNATE. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different."
Re: [PATCH 1/3] powerpc/cacheinfo: add cacheinfo_teardown, cacheinfo_rebuild
On Wed, 2019-06-12 at 04:45:04 UTC, Nathan Lynch wrote:
> Allow external callers to force the cacheinfo code to release all its
> references to cache nodes, e.g. before processing device tree updates
> post-migration, and to rebuild the hierarchy afterward.
>
> CPU online/offline must be blocked by callers; enforce this.
>
> Fixes: 410bccf97881 ("powerpc/pseries: Partition migration in the kernel")
> Signed-off-by: Nathan Lynch
> Reviewed-by: Gautham R. Shenoy
Series applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/d4aa219a074a5abaf95a756b9f0d190b
cheers
Re: [PATCH] powerpc/pseries: fix oops in hotplug memory notifier
On Fri, 2019-06-07 at 05:04:07 UTC, Nathan Lynch wrote: > During post-migration device tree updates, we can oops in > pseries_update_drconf_memory if the source device tree has an > ibm,dynamic-memory-v2 property and the destination has a > ibm,dynamic_memory (v1) property. The notifier processes an "update" > for the ibm,dynamic-memory property but it's really an add in this > scenario. So make sure the old property object is there before > dereferencing it. > > Signed-off-by: Nathan Lynch Applied to powerpc next, thanks. https://git.kernel.org/powerpc/c/0aa82c482ab2ece530a6f44897b63b27 cheers
Re: [PATCH] ocxl: do not use C++ style comments in uapi header
On Tue, 2019-06-04 at 11:16:32 UTC, Masahiro Yamada wrote: > Linux kernel tolerates C++ style comments these days. Actually, the > SPDX License tags for .c files start with //. > > On the other hand, uapi headers are written in more strict C, where > the C++ comment style is forbidden. > > Signed-off-by: Masahiro Yamada > Acked-by: Frederic Barrat > Acked-by: Andrew Donnellan Applied to powerpc next, thanks. https://git.kernel.org/powerpc/c/2305ff225c0b1691ec2e93f3d6990e13 cheers
Re: [PATCH v2] powerpc: pseries/hvconsole: fix stack overread via udbg
On Mon, 2019-06-03 at 06:56:57 UTC, Daniel Axtens wrote: > While developing kasan for 64-bit book3s, I hit the following stack > over-read. > > It occurs because the hypercall to put characters onto the terminal > takes 2 longs (128 bits/16 bytes) of characters at a time, and so > hvc_put_chars would unconditionally copy 16 bytes from the argument > buffer, regardless of supplied length. However, udbg_hvc_putc can > call hvc_put_chars with a single-byte buffer, leading to the error. > > [0.001931] > == > [150/819] > [0.001933] BUG: KASAN: stack-out-of-bounds in hvc_put_chars+0xdc/0x110 > [0.001934] Read of size 8 at addr c23e7a90 by task swapper/0 > [0.001934] > [0.001935] CPU: 0 PID: 0 Comm: swapper Not tainted > 5.2.0-rc2-next-20190528-02824-g048a6ab4835b #113 > [0.001935] Call Trace: > [0.001936] [c23e7790] [c1b4a450] dump_stack+0x104/0x154 > (unreliable) > [0.001937] [c23e77f0] [c06d3524] > print_address_description+0xa0/0x30c > [0.001938] [c23e7880] [c06d318c] > __kasan_report+0x20c/0x224 > [0.001939] [c23e7950] [c06d19d8] kasan_report+0x18/0x30 > [0.001940] [c23e7970] [c06d4854] > __asan_report_load8_noabort+0x24/0x40 > [0.001941] [c23e7990] [c01511ac] hvc_put_chars+0xdc/0x110 > [0.001942] [c23e7a10] [c0f81cfc] > hvterm_raw_put_chars+0x9c/0x110 > [0.001943] [c23e7a50] [c0f82634] udbg_hvc_putc+0x154/0x200 > [0.001944] [c23e7b10] [c0049c90] udbg_write+0xf0/0x240 > [0.001945] [c23e7b70] [c02e5d88] > console_unlock+0x868/0xd30 > [0.001946] [c23e7ca0] [c02e6e00] > register_console+0x970/0xe90 > [0.001947] [c23e7d80] [c1ff1928] > register_early_udbg_console+0xf8/0x114 > [0.001948] [c23e7df0] [c1ff1174] setup_arch+0x108/0x790 > [0.001948] [c23e7e90] [c1fe41c8] start_kernel+0x104/0x784 > [0.001949] [c23e7f90] [c000b368] > start_here_common+0x1c/0x534 > [0.001950] > [0.001950] > [0.001951] Memory state around the buggy address: > [0.001952] c23e7980: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 > [0.001952] c23e7a00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > f1 f1 > [0.001953] >c23e7a80: f1 f1 01 f2 f2 f2 00 00 00 00 00 00 00 00 > 00 00 > [0.001953] ^ > [0.001954] c23e7b00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 > [0.001954] c23e7b80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 > [0.001955] > == > > Document that a 16-byte buffer is requred, and provide it in udbg. > > CC: Dmitry Vyukov > Signed-off-by: Daniel Axtens Applied to powerpc next, thanks. https://git.kernel.org/powerpc/c/934bda59f286d0221f1a3ebab7f5156a cheers
[GIT PULL] Please pull powerpc/linux.git powerpc-5.2-4 tag
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Linus, Please pull some more powerpc fixes for 5.2: The following changes since commit cd6c84d8f0cdc911df435bb075ba22ce3c605b07: Linux 5.2-rc2 (2019-05-26 16:49:19 -0700) are available in the git repository at: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git tags/powerpc-5.2-4 for you to fetch changes up to c21f5a9ed85ca3e914ca11f421677ae9ae0d04b0: powerpc/32s: fix booting with CONFIG_PPC_EARLY_DEBUG_BOOTX (2019-06-07 19:00:14 +1000) - -- powerpc fixes for 5.2 #4 One fix for a regression introduced by our 32-bit KASAN support, which broke booting on machines with "bootx" early debugging enabled. A fix for a bug which broke kexec on 32-bit, introduced by changes to the 32-bit STRICT_KERNEL_RWX support in v5.1. Finally two fixes going to stable for our THP split/collapse handling, discovered by Nick. The first fixes random crashes and/or corruption in guests under sufficient load. Thanks to: Nicholas Piggin, Christophe Leroy, Aaro Koskinen, Mathieu Malaterre. - -- Christophe Leroy (2): powerpc: Fix kexec failure on book3s/32 powerpc/32s: fix booting with CONFIG_PPC_EARLY_DEBUG_BOOTX Nicholas Piggin (2): powerpc/64s: Fix THP PMD collapse serialisation powerpc/64s: __find_linux_pte() synchronization vs pmdp_invalidate() arch/powerpc/include/asm/book3s/64/pgtable.h | 30 arch/powerpc/include/asm/btext.h | 4 arch/powerpc/include/asm/kexec.h | 3 +++ arch/powerpc/kernel/machine_kexec_32.c | 4 +++- arch/powerpc/kernel/prom_init.c | 1 + arch/powerpc/kernel/prom_init_check.sh | 2 +- arch/powerpc/mm/book3s64/pgtable.c | 3 +++ arch/powerpc/mm/pgtable.c| 16 +-- 8 files changed, 59 insertions(+), 4 deletions(-) -BEGIN PGP SIGNATURE- iQIcBAEBAgAGBQJdBO4+AAoJEFHr6jzI4aWAsAwQAK+CK0jvw2pgZMk8/RwuPihJ gr6pvRaiUuyyiCpWxpzHslZx0WYSg84EYaog4e3fRss6MZeTd4CxxJqAIIny2XTK 3Z6EI3GQGtA8U/+GY+whaQ5+ILdJotbPNRci+yGwc3HNZwT/4RScbmJz7E84MZv+ 9gyXrKUio0RdtdZmMHtkrCbpg24QYf1+168gUlJ8H5XGy5NVXVhXwxbYcFeN4zIY JI+exlBZwtYBJQMtR0FCvjybKk7kRdQzrrUEFM/ZmzsXQryUR7tLrwqAeLvcDc6x CY9/fn2q7BcFRiOxeZ3AGG89NRTGdOOC1cNJ+Wqn8bIxzP/yFwTEr+lcbdpooCAs MYyR0yoiI8Aty55lH0uTYQDbXWBZigvKDjLJzn3KN91NKnb3Yw37y5fM5e1ZYQez bJmbcJJpQzv0YVxXpxd27QeLQtJe6B8D5y0HkpRzYifma5ItAzc1VGzp66jLRFT+ m4LmzD3TjQ61LWyxxDBjAWCHUKW7+cu++sFw0LOA2Wib5DjLjhQAu9qXN1sR5704 FXji4jULMajLMhqqMxjwTEatS46THyz2rqOtJ5/eRWOHBMBS8rHTbHRtFF20mL7x tHtDmKCfFs2HwHOndtaWduBjiGVVwOo84o2jY0EvfaQ5nscf2XE9acVo6czpJacn NnIsVZZ6RU/y4Q/f55T4 =Viyv -END PGP SIGNATURE-
Re: [PATCH] powerpc/mm/32s: only use MMU to mark initmem NX if STRICT_KERNEL_RWX
Andreas Schwab a écrit :
If STRICT_KERNEL_RWX is disabled, never use the MMU to mark initmen
nonexecutable.
I dont understand, can you elaborate ?
This area is mapped with BATs so using change_page_attr() is pointless.
Christophe
Also move a misplaced paren that makes the condition always true.
Fixes: 63b2bc619565 ("powerpc/mm/32s: Use BATs for STRICT_KERNEL_RWX")
Signed-off-by: Andreas Schwab
---
arch/powerpc/mm/pgtable_32.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/mm/pgtable_32.c b/arch/powerpc/mm/pgtable_32.c
index d53188dee18f..3935dc263d65 100644
--- a/arch/powerpc/mm/pgtable_32.c
+++ b/arch/powerpc/mm/pgtable_32.c
@@ -360,9 +360,11 @@ void mark_initmem_nx(void)
unsigned long numpages = PFN_UP((unsigned long)_einittext) -
PFN_DOWN((unsigned long)_sinittext);
- if (v_block_mapped((unsigned long)_stext) + 1)
+#ifdef CONFIG_STRICT_KERNEL_RWX
+ if (v_block_mapped((unsigned long)_stext + 1))
mmu_mark_initmem_nx();
else
+#endif
change_page_attr(page, numpages, PAGE_KERNEL);
}
--
2.22.0
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1
"And now for something completely different."
Re: [PATCH v5 13/16] powerpc/mm/32s: Use BATs for STRICT_KERNEL_RWX
Andreas Schwab a écrit : This breaks suspend (or resume) on the iBook G4. no_console_suspend doesn't give any clues, the display just stays dark. Can you send your .config Thanks Christophe Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different."
[PATCH] powerpc/mm/32s: only use MMU to mark initmem NX if STRICT_KERNEL_RWX
If STRICT_KERNEL_RWX is disabled, never use the MMU to mark initmen
nonexecutable.
Also move a misplaced paren that makes the condition always true.
Fixes: 63b2bc619565 ("powerpc/mm/32s: Use BATs for STRICT_KERNEL_RWX")
Signed-off-by: Andreas Schwab
---
arch/powerpc/mm/pgtable_32.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/mm/pgtable_32.c b/arch/powerpc/mm/pgtable_32.c
index d53188dee18f..3935dc263d65 100644
--- a/arch/powerpc/mm/pgtable_32.c
+++ b/arch/powerpc/mm/pgtable_32.c
@@ -360,9 +360,11 @@ void mark_initmem_nx(void)
unsigned long numpages = PFN_UP((unsigned long)_einittext) -
PFN_DOWN((unsigned long)_sinittext);
- if (v_block_mapped((unsigned long)_stext) + 1)
+#ifdef CONFIG_STRICT_KERNEL_RWX
+ if (v_block_mapped((unsigned long)_stext + 1))
mmu_mark_initmem_nx();
else
+#endif
change_page_attr(page, numpages, PAGE_KERNEL);
}
--
2.22.0
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1
"And now for something completely different."
Re: [PATCH v5 13/16] powerpc/mm/32s: Use BATs for STRICT_KERNEL_RWX
On Feb 21 2019, Christophe Leroy wrote: > diff --git a/arch/powerpc/mm/pgtable_32.c b/arch/powerpc/mm/pgtable_32.c > index a000768a5cc9..6e56a6240bfa 100644 > --- a/arch/powerpc/mm/pgtable_32.c > +++ b/arch/powerpc/mm/pgtable_32.c > @@ -353,7 +353,10 @@ void mark_initmem_nx(void) > unsigned long numpages = PFN_UP((unsigned long)_einittext) - >PFN_DOWN((unsigned long)_sinittext); > > - change_page_attr(page, numpages, PAGE_KERNEL); > + if (v_block_mapped((unsigned long)_stext) + 1) That is always true. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different."
Re: [PATCH v5 13/16] powerpc/mm/32s: Use BATs for STRICT_KERNEL_RWX
This breaks suspend (or resume) on the iBook G4. no_console_suspend doesn't give any clues, the display just stays dark. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different."
crypto/NX: Set receive window credits to max number of CRBs in RxFIFO
System gets checkstop if RxFIFO overruns with more requests than the
maximum possible number of CRBs in FIFO at the same time. So find max
CRBs from FIFO size and set it to receive window credits.
CC: sta...@vger.kernel.org # v4.14+
Signed-off-by:Haren Myneni
diff --git a/drivers/crypto/nx/nx-842-powernv.c
b/drivers/crypto/nx/nx-842-powernv.c
index 4acbc47..e78ff5c 100644
--- a/drivers/crypto/nx/nx-842-powernv.c
+++ b/drivers/crypto/nx/nx-842-powernv.c
@@ -27,8 +27,6 @@
#define WORKMEM_ALIGN (CRB_ALIGN)
#define CSB_WAIT_MAX (5000) /* ms */
#define VAS_RETRIES(10)
-/* # of requests allowed per RxFIFO at a time. 0 for unlimited */
-#define MAX_CREDITS_PER_RXFIFO (1024)
struct nx842_workmem {
/* Below fields must be properly aligned */
@@ -812,7 +810,11 @@ static int __init vas_cfg_coproc_info(struct device_node
*dn, int chip_id,
rxattr.lnotify_lpid = lpid;
rxattr.lnotify_pid = pid;
rxattr.lnotify_tid = tid;
- rxattr.wcreds_max = MAX_CREDITS_PER_RXFIFO;
+ /*
+* Maximum RX window credits can not be more than #CRBs in
+* RxFIFO. Otherwise, can get checkstop if RxFIFO overruns.
+*/
+ rxattr.wcreds_max = fifo_size / CRB_SIZE;
/*
* Open a VAS receice window which is used to configure RxFIFO
Issue with sg_copy_to_buffer() ? (was Re: [PATCH v3 2/4] crypto: talitos - fix hash on SEC1.)
Le 15/06/2019 à 10:18, Christophe Leroy a écrit :
@@ -2058,7 +2065,18 @@ static int ahash_process_req(struct
ahash_request *areq, unsigned int nbytes)
sg_copy_to_buffer(areq->src, nents,
ctx_buf + req_ctx->nbuf, offset);
req_ctx->nbuf += offset;
- req_ctx->psrc = areq->src;
+ for (sg = areq->src; sg && offset >= sg->length;
+ offset -= sg->length, sg = sg_next(sg))
+ ;
+ if (offset) {
+ sg_init_table(req_ctx->bufsl, 2);
+ sg_set_buf(req_ctx->bufsl, sg_virt(sg) + offset,
+ sg->length - offset);
+ sg_chain(req_ctx->bufsl, 2, sg_next(sg));
+ req_ctx->psrc = req_ctx->bufsl;
Isn't this what scatterwalk_ffwd() does?
Thanks for pointing this, I wasn't aware of that function. Looking at it
it seems to do the same. Unfortunately, some tests fails with 'wrong
result' when using it instead.
Comparing the results of scatterwalk_ffwd() with what I get with my open
codying, I see the following difference:
scatterwalk_ffwd() uses sg_page(sg) + sg->offset + len
while my open codying results in virt_to_page(sg_virt(sg) + len)
When sg->offset + len is greater than PAGE_SIZE, the resulting SG entry
is different allthough valid in both cases. I think this difference
results in sg_copy_to_buffer() failing. I'm still investigating. Any idea ?
After adding some dumps, I confirm the suspicion:
My board uses 16k pages.
SG list when not using scatterwalk_ffwd()
[ 64.120540] sg c6386794 page c7fc1c60 offset 22 len 213
[ 64.120579] sg c6386a48 page c7fc1b80 offset 4 len 2
[ 64.120618] sg c6386a5c page c7fc1b00 offset 3 len 17
[ 64.120658] sg c6386a70 page c7fc1b40 offset 2 len 10
SG list when using scatterwalk_ffwd()
[ 64.120743] sg c6386794 page c7fc1c40 offset 16406 len 213
[ 64.120782] sg c6386a48 page c7fc1b80 offset 4 len 2
[ 64.120821] sg c6386a5c page c7fc1b00 offset 3 len 17
[ 64.120861] sg c6386a70 page c7fc1b40 offset 2 len 10
Content of the SG list:
[ 64.120975] : e8 40 98 f0 48 a0 f8 50 a8 00 58 b0 08 60 b8 10
[ 64.121021] 0010: 68 c0 18 70 c8 20 78 d0 28 80 d8 30 88 e0 38 90
[ 64.121067] 0020: e8 40 98 f0 48 a0 f8 50 a8 00 58 b0 08 60 b8 10
[ 64.121112] 0030: 68 c0 18 70 c8 20 78 d0 28 80 d8 30 88 e0 38 90
[ 64.121157] 0040: e8 40 98 f0 48 a0 f8 50 a8 00 58 b0 08 60 b8 10
[ 64.121202] 0050: 68 c0 18 70 c8 20 78 d0 28 80 d8 30 88 e0 38 90
[ 64.121247] 0060: e8 40 98 f0 48 a0 f8 50 a8 00 58 b0 08 60 a8 10
[ 64.121292] 0070: 68 c0 18 70 c8 20 78 d0 28 80 d8 30 88 e0 38 90
[ 64.121337] 0080: e8 40 98 f0 48 a0 f8 50 28 00 58 b0 08 60 b8 10
[ 64.121382] 0090: 68 c0 18 70 c8 20 78 d0 28 80 d8 30 88 e0 38 90
[ 64.121427] 00a0: e8 40 98 f0 48 a0 f8 50 a8 00 58 b0 08 60 b8 10
[ 64.121472] 00b0: 68 c0 18 70 c8 20 78 d0 28 80 d8 30 88 e0 38 90
[ 64.121517] 00c0: e8 40 98 f0 48 a0 f8 50 a8 00 58 b0 08 60 b8 10
[ 64.121557] 00d0: 68 c0 18 30 c8
[ 64.121598] : 20 78
[ 64.121646] : d0 28 80 f8 30 88 e0 38 90 e8 40 98 f0 48 a0 f8
[ 64.121684] 0010: 50
[ 64.121729] : a8 00 58 b0 08 60 b8 10 68 c0
Content of the buffer after the copy from the list:
[ 64.121790] : e8 40 98 f0 48 a0 f8 50 a8 00 58 b0 08 60 b8 10
[ 64.121836] 0010: 68 c0 18 70 c8 20 78 d0 28 80 d8 30 88 e0 38 90
[ 64.121881] 0020: e8 40 98 f0 48 a0 f8 50 a8 00 58 b0 08 60 b8 10
[ 64.121927] 0030: 68 c0 18 70 c8 20 78 d0 28 80 d8 30 88 e0 38 90
[ 64.121972] 0040: e8 40 98 f0 48 a0 f8 50 a8 00 58 b0 08 60 b8 10
[ 64.122017] 0050: 68 c0 18 70 c8 20 78 d0 28 80 d8 30 88 e0 38 90
[ 64.122062] 0060: e8 40 98 f0 48 a0 f8 50 a8 00 58 b0 08 60 a8 10
[ 64.122107] 0070: 68 c0 18 70 c8 20 78 d0 28 80 d8 30 88 e0 38 90
[ 64.122152] 0080: e8 40 98 f0 48 a0 f8 50 28 00 58 b0 08 60 b8 10
[ 64.122197] 0090: 68 c0 18 70 c8 20 78 d0 28 80 d8 30 88 e0 38 90
[ 64.122243] 00a0: e8 40 98 f0 48 a0 f8 50 a8 00 58 b0 08 60 b8 10
[ 64.122288] 00b0: 68 c0 18 70 c8 20 78 d0 28 80 d8 30 88 e0 38 90
[ 64.122333] 00c0: e8 40 98 f0 48 a0 f8 50 a8 00 58 b0 08 60 b8 10
[ 64.122378] 00d0: 68 c0 18 30 c8 d8 b0 08 60 b8 10 68 c0 18 70 c8
[ 64.122424] 00e0: 20 78 d0 28 80 d8 30 88 e0 38 90 e8 40 98 f0 48
[ 64.122462] 00f0: a0 f8
As you can see, the data following the first block should be
20 78 d0 28 80 f8 30 88 e0 38 90 e8 40 98 f0 48 a0 f8 50 a8 00 58 b0 08
60 b8 10 68 c0
Instead it is
d8 b0 08 60 b8 10 68 c0 18 70 c8 20 78 d0 28 80 d8 30 88 e0 38 90 e8 40
98 f0 48 a0 f8
So I guess there is something wrong with sg_copy_to_buffer()
Christophe
Re: [PATCH v3 2/4] crypto: talitos - fix hash on SEC1.
Le 14/06/2019 à 13:32, Horia Geanta a écrit :
On 6/13/2019 3:48 PM, Christophe Leroy wrote:
@@ -336,15 +336,18 @@ static void flush_channel(struct device *dev, int ch, int
error, int reset_ch)
tail = priv->chan[ch].tail;
while (priv->chan[ch].fifo[tail].desc) {
__be32 hdr;
+ struct talitos_edesc *edesc;
request = >chan[ch].fifo[tail];
+ edesc = container_of(request->desc, struct talitos_edesc, desc);
Not needed for all cases, should be moved to the block that uses it.
Ok.
/* descriptors with their done bits set don't get the error */
rmb();
if (!is_sec1)
hdr = request->desc->hdr;
else if (request->desc->next_desc)
- hdr = (request->desc + 1)->hdr1;
+ hdr = ((struct talitos_desc *)
+ (edesc->buf + edesc->dma_len))->hdr1;
else
hdr = request->desc->hdr1;
[snip]
@@ -2058,7 +2065,18 @@ static int ahash_process_req(struct ahash_request *areq,
unsigned int nbytes)
sg_copy_to_buffer(areq->src, nents,
ctx_buf + req_ctx->nbuf, offset);
req_ctx->nbuf += offset;
- req_ctx->psrc = areq->src;
+ for (sg = areq->src; sg && offset >= sg->length;
+offset -= sg->length, sg = sg_next(sg))
+ ;
+ if (offset) {
+ sg_init_table(req_ctx->bufsl, 2);
+ sg_set_buf(req_ctx->bufsl, sg_virt(sg) + offset,
+ sg->length - offset);
+ sg_chain(req_ctx->bufsl, 2, sg_next(sg));
+ req_ctx->psrc = req_ctx->bufsl;
Isn't this what scatterwalk_ffwd() does?
Thanks for pointing this, I wasn't aware of that function. Looking at it
it seems to do the same. Unfortunately, some tests fails with 'wrong
result' when using it instead.
Comparing the results of scatterwalk_ffwd() with what I get with my open
codying, I see the following difference:
scatterwalk_ffwd() uses sg_page(sg) + sg->offset + len
while my open codying results in virt_to_page(sg_virt(sg) + len)
When sg->offset + len is greater than PAGE_SIZE, the resulting SG entry
is different allthough valid in both cases. I think this difference
results in sg_copy_to_buffer() failing. I'm still investigating. Any idea ?
Christophe
Horia
Re: [PATCH v1 1/6] mm: Section numbers use the type "unsigned long"
Le 14/06/2019 à 21:00, Andrew Morton a écrit :
On Fri, 14 Jun 2019 12:01:09 +0200 David Hildenbrand wrote:
We are using a mixture of "int" and "unsigned long". Let's make this
consistent by using "unsigned long" everywhere. We'll do the same with
memory block ids next.
...
- int i, ret, section_count = 0;
+ unsigned long i;
...
- unsigned int i;
+ unsigned long i;
Maybe I did too much fortran back in the day, but I think the
expectation is that a variable called "i" has type "int".
This?
s/unsigned long i/unsigned long section_nr/
From my point of view you degrade readability by doing that.
section_nr_to_pfn(mem->start_section_nr + section_nr);
Three times the word 'section_nr' in one line, is that worth it ? Gives
me headache.
Codying style says the following, which makes full sense in my opinion:
LOCAL variable names should be short, and to the point. If you have
some random integer loop counter, it should probably be called ``i``.
Calling it ``loop_counter`` is non-productive, if there is no chance of it
being mis-understood.
What about just naming it 'nr' if we want to use something else than 'i' ?
Christophe
--- a/drivers/base/memory.c~mm-section-numbers-use-the-type-unsigned-long-fix
+++ a/drivers/base/memory.c
@@ -131,17 +131,17 @@ static ssize_t phys_index_show(struct de
static ssize_t removable_show(struct device *dev, struct device_attribute
*attr,
char *buf)
{
- unsigned long i, pfn;
+ unsigned long section_nr, pfn;
int ret = 1;
struct memory_block *mem = to_memory_block(dev);
if (mem->state != MEM_ONLINE)
goto out;
- for (i = 0; i < sections_per_block; i++) {
- if (!present_section_nr(mem->start_section_nr + i))
+ for (section_nr = 0; section_nr < sections_per_block; section_nr++) {
+ if (!present_section_nr(mem->start_section_nr + section_nr))
continue;
- pfn = section_nr_to_pfn(mem->start_section_nr + i);
+ pfn = section_nr_to_pfn(mem->start_section_nr + section_nr);
ret &= is_mem_section_removable(pfn, PAGES_PER_SECTION);
}
@@ -695,12 +695,12 @@ static int add_memory_block(unsigned lon
{
int ret, section_count = 0;
struct memory_block *mem;
- unsigned long i;
+ unsigned long section_nr;
- for (i = base_section_nr;
-i < base_section_nr + sections_per_block;
-i++)
- if (present_section_nr(i))
+ for (section_nr = base_section_nr;
+section_nr < base_section_nr + sections_per_block;
+section_nr++)
+ if (present_section_nr(section_nr))
section_count++;
if (section_count == 0)
@@ -823,7 +823,7 @@ static const struct attribute_group *mem
*/
int __init memory_dev_init(void)
{
- unsigned long i;
+ unsigned long section_nr;
int ret;
int err;
unsigned long block_sz;
@@ -840,9 +840,9 @@ int __init memory_dev_init(void)
* during boot and have been initialized
*/
mutex_lock(_sysfs_mutex);
- for (i = 0; i <= __highest_present_section_nr;
- i += sections_per_block) {
- err = add_memory_block(i);
+ for (section_nr = 0; section_nr <= __highest_present_section_nr;
+ section_nr += sections_per_block) {
+ err = add_memory_block(section_nr);
if (!ret)
ret = err;
}
_
Re: [PATCH v3 8/9] KVM: PPC: Ultravisor: Enter a secure guest
On Thu, Jun 06, 2019 at 02:36:13PM -0300, Claudio Carvalho wrote: > From: Sukadev Bhattiprolu > > To enter a secure guest, we have to go through the ultravisor, therefore > we do a ucall when we are entering a secure guest. > > This change is needed for any sort of entry to the secure guest from the > hypervisor, whether it is a return from an hcall, a return from a > hypervisor interrupt, or the first time that a secure guest vCPU is run. > > If we are returning from an hcall, the results are already in the > appropriate registers (R3:12), except for R6,7, which need to be > restored before doing the ucall (UV_RETURN). > > Have fast_guest_return check the kvm_arch.secure_guest field so that a > new CPU enters UV when started (in response to a RTAS start-cpu call). > > Thanks to input from Paul Mackerras, Ram Pai and Mike Anderson. > > Signed-off-by: Sukadev Bhattiprolu > [Pass SRR1 in r11 for UV_RETURN, fix kvmppc_msr_interrupt to preserve > the MSR_S bit] > Signed-off-by: Paul Mackerras > [Fix UV_RETURN token number and arch.secure_guest check] > Signed-off-by: Ram Pai > [Update commit message and ret_to_ultra comment] > Signed-off-by: Claudio Carvalho Acked-by: Paul Mackerras Paul.
Re: [PATCH v3 9/9] KVM: PPC: Ultravisor: Check for MSR_S during hv_reset_msr
On Thu, Jun 06, 2019 at 02:36:14PM -0300, Claudio Carvalho wrote: > From: Michael Anderson > > - Check for MSR_S so that kvmppc_set_msr will include. Prior to this Will include what? "it" maybe? >change return to guest would not have the S bit set. > > - Patch based on comment from Paul Mackerras > > Signed-off-by: Michael Anderson > Signed-off-by: Claudio Carvalho Acked-by: Paul Mackerras but you should reword the commit message fix that first sentence. Paul.
Re: [PATCH v3 7/9] KVM: PPC: Ultravisor: Restrict LDBAR access
On Thu, Jun 06, 2019 at 02:36:12PM -0300, Claudio Carvalho wrote: > When the ultravisor firmware is available, it takes control over the > LDBAR register. In this case, thread-imc updates and save/restore > operations on the LDBAR register are handled by ultravisor. > > Signed-off-by: Claudio Carvalho > Signed-off-by: Ram Pai Acked-by: Paul Mackerras Just a note on the signed-off-by: it's a bit weird to have Ram's signoff when he is neither the author nor the sender of the patch. The author is assumed to be Claudio; if that is not correct then the patch should have a From: line at the start telling us who the author is, and ideally that person should have a signoff line before Claudio's signoff as the sender of the patch. Paul.
Re: [PATCH v3 5/9] KVM: PPC: Ultravisor: Use UV_WRITE_PATE ucall to register a PATE
On Thu, Jun 06, 2019 at 02:36:10PM -0300, Claudio Carvalho wrote: > From: Michael Anderson > > When running under an ultravisor, the ultravisor controls the real > partition table and has it in secure memory where the hypervisor can't > access it, and therefore we (the HV) have to do a ucall whenever we want > to update an entry. > > The HV still keeps a copy of its view of the partition table in normal > memory so that the nest MMU can access it. > > Both partition tables will have PATE entries for HV and normal virtual > machines. As discussed before, all of this should depend only on CONFIG_PPC_POWERNV. Paul.
Re: [PATCH v3 4/9] KVM: PPC: Ultravisor: Add generic ultravisor call handler
On Thu, Jun 06, 2019 at 02:36:09PM -0300, Claudio Carvalho wrote: > From: Ram Pai > > Add the ucall() function, which can be used to make ultravisor calls > with varied number of in and out arguments. Ultravisor calls can be made > from the host or guests. > > This copies the implementation of plpar_hcall(). Again, we will want all of this on every powernv-capable kernel, since they will all need to do UV_WRITE_PATE, even if they have no other support for the ultravisor. Paul.
Re: [PATCH v3 3/9] powerpc: Introduce FW_FEATURE_ULTRAVISOR
On Thu, Jun 06, 2019 at 02:36:08PM -0300, Claudio Carvalho wrote: > This feature tells if the ultravisor firmware is available to handle > ucalls. Everything in this patch that depends on CONFIG_PPC_UV should just depend on CONFIG_PPC_POWERNV instead. The reason is that every host kernel needs to be able to do the ultracall to set partition table entry 0, in case it ends up being run on a machine with an ultravisor. Otherwise we will have the situation where a host kernel may crash early in boot just because the machine it's booted on happens to have an ultravisor running. The crash will be a particularly nasty one because it will happen before we have probed the machine type and initialized the console; therefore it will just look like the machine hangs for no discernable reason. We also need to think about how to provide a way for petitboot to know whether the kernel it is booting knows how to do a ucall to set its partition table entry. One suggestion would be to modify vmlinux.lds.S to add a new PT_NOTE entry in the program header of the binary with (say) a 64-bit doubleword which is a bitmap indicating capabilities of the binary. We would define the first bit as indicating that the kernel knows how to run under an ultravisor. When running under an ultravisor, petitboot could then look for the PT_NOTE and the ultravisor-capable bit in it, and if the PT_NOTE is not there or the bit is zero, put up a dialog warning the user that the kernel will probably crash early in boot, and asking for explicit confirmation that the user wants to proceed. Paul.
