Re: [PATCH v9 2/8] KVM: PPC: Move pages between normal and secure memory

2019-10-21 Thread Bharata B Rao 
On Fri, Oct 18, 2019 at 8:31 AM Paul Mackerras  wrote:
>
> On Wed, Sep 25, 2019 at 10:36:43AM +0530, Bharata B Rao wrote:
> > Manage migration of pages betwen normal and secure memory of secure
> > guest by implementing H_SVM_PAGE_IN and H_SVM_PAGE_OUT hcalls.
> >
> > H_SVM_PAGE_IN: Move the content of a normal page to secure page
> > H_SVM_PAGE_OUT: Move the content of a secure page to normal page
> >
> > Private ZONE_DEVICE memory equal to the amount of secure memory
> > available in the platform for running secure guests is created.
> > Whenever a page belonging to the guest becomes secure, a page from
> > this private device memory is used to represent and track that secure
> > page on the HV side. The movement of pages between normal and secure
> > memory is done via migrate_vma_pages() using UV_PAGE_IN and
> > UV_PAGE_OUT ucalls.
>
> As we discussed privately, but mentioning it here so there is a
> record:  I am concerned about this structure
>
> > +struct kvmppc_uvmem_page_pvt {
> > + unsigned long *rmap;
> > + struct kvm *kvm;
> > + unsigned long gpa;
> > +};
>
> which keeps a reference to the rmap.  The reference could become stale
> if the memslot is deleted or moved, and nothing in the patch series
> ensures that the stale references are cleaned up.

I will add code to release the device PFNs when memslot goes away. In
fact the early versions of the patchset had this, but it subsequently
got removed.

>
> If it is possible to do without the long-term rmap reference, and
> instead find the rmap via the memslots (with the srcu lock held) each
> time we need the rmap, that would be safer, I think, provided that we
> can sort out the lock ordering issues.

All paths except fault handler access rmap[] under srcu lock. Even in
case of fault handler, for those faults induced by us (shared page
handling, releasing device pfns), we do hold srcu lock. The difficult
case is when we fault due to HV accessing a device page. In this case
we come to fault hanler with mmap_sem already held and are not in a
position to take kvm srcu lock as that would lead to lock order
reversal. Given that we have pages mapped in still, I assume memslot
can't go away while we access rmap[], so think we should be ok here.

However if that sounds fragile, may be I can go back to my initial
design where we weren't using rmap[] to store device PFNs. That will
increase the memory usage but we give us an easy option to have
per-guest mutex to protect concurrent page-ins/outs/faults.

Regards,
Bharata.
-- 
http://raobharata.wordpress.com/

Re: [PATCH] powerpc/64s/exception: Fix kaup -> kuap typo

2019-10-21 Thread Russell Currey 
On Tue, 2019-10-22 at 17:06 +1100, Andrew Donnellan wrote:
> It's KUAP, not KAUP. Fix typo in INT_COMMON macro.
> 
> Signed-off-by: Andrew Donnellan 

Akced-by: Russell Currey

[PATCH] powerpc/64s/exception: Fix kaup -> kuap typo

2019-10-21 Thread Andrew Donnellan 
It's KUAP, not KAUP. Fix typo in INT_COMMON macro.

Signed-off-by: Andrew Donnellan 
---
 arch/powerpc/kernel/exceptions-64s.S | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/powerpc/kernel/exceptions-64s.S 
b/arch/powerpc/kernel/exceptions-64s.S
index d0018dd17e0a..46508b148e16 100644
--- a/arch/powerpc/kernel/exceptions-64s.S
+++ b/arch/powerpc/kernel/exceptions-64s.S
@@ -514,7 +514,7 @@ END_FTR_SECTION_NESTED(CPU_FTR_HAS_PPR,CPU_FTR_HAS_PPR,948)
  * If stack=0, then the stack is already set in r1, and r1 is saved in r10.
  * PPR save and CPU accounting is not done for the !stack case (XXX why not?)
  */
-.macro INT_COMMON vec, area, stack, kaup, reconcile, dar, dsisr
+.macro INT_COMMON vec, area, stack, kuap, reconcile, dar, dsisr
.if \stack
andi.   r10,r12,MSR_PR  /* See if coming from user  */
mr  r10,r1  /* Save r1  */
@@ -533,7 +533,7 @@ END_FTR_SECTION_NESTED(CPU_FTR_HAS_PPR,CPU_FTR_HAS_PPR,948)
std r10,GPR1(r1)/* save r1 in stackframe*/
 
.if \stack
-   .if \kaup
+   .if \kuap
kuap_save_amr_and_lock r9, r10, cr1, cr0
.endif
beq 101f/* if from kernel mode  */
@@ -541,7 +541,7 @@ END_FTR_SECTION_NESTED(CPU_FTR_HAS_PPR,CPU_FTR_HAS_PPR,948)
SAVE_PPR(\area, r9)
 101:
.else
-   .if \kaup
+   .if \kuap
kuap_save_amr_and_lock r9, r10, cr1
.endif
.endif
-- 
2.20.1

Re: [PATCH v4 3/3] powerpc/prom_init: Use -ffreestanding to avoid a reference to bcmp

2019-10-21 Thread Nathan Chancellor 
On Fri, Oct 18, 2019 at 03:02:10PM -0500, Segher Boessenkool wrote:
> On Fri, Oct 18, 2019 at 12:00:22PM -0700, Nathan Chancellor wrote:
> > Just as an FYI, there was some more discussion around the availablity
> > and use of bcmp in this LLVM bug which spawned
> > commit 5f074f3e192f ("lib/string.c: implement a basic bcmp").
> > 
> > https://bugs.llvm.org/show_bug.cgi?id=41035#c13
> > 
> > I believe this is the proper solution but I am fine with whatever works,
> > I just want our CI to be green without any out of tree patches again...
> 
> I think the proper solution is for the kernel to *do* use -ffreestanding,
> and then somehow tell the kernel that memcpy etc. are the standard
> functions.  A freestanding GCC already requires memcpy, memmove, memset,
> memcmp, and sometimes abort to exist and do the standard thing; why cannot
> programs then also rely on it to be the standard functions.
> 
> What exact functions are the reason the kernel does not use -ffreestanding?
> Is it just memcpy?  Is more wanted?
> 
> 
> Segher

I think Linus summarized it pretty well here:

https://lore.kernel.org/lkml/CAHk-=wi-epJZfBHDbKKDZ64us7WkF=lpufhvybmzsteo8q0...@mail.gmail.com/

Cheers,
Nathan

Re: [PATCH 5/5] ionic: Use debugfs_create_bool() to export bool

2019-10-21 Thread Shannon Nelson 

On 10/21/19 7:51 AM, Geert Uytterhoeven wrote:

Currently bool ionic_cq.done_color is exported using
debugfs_create_u8(), which requires a cast, preventing further compiler
checks.

Fix this by switching to debugfs_create_bool(), and dropping the cast.

Signed-off-by: Geert Uytterhoeven 


Acked-by: Shannon Nelson 


---
  drivers/net/ethernet/pensando/ionic/ionic_debugfs.c | 3 +--
  1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/net/ethernet/pensando/ionic/ionic_debugfs.c 
b/drivers/net/ethernet/pensando/ionic/ionic_debugfs.c
index bc03cecf80cc9eb4..5beba915f69d12dd 100644
--- a/drivers/net/ethernet/pensando/ionic/ionic_debugfs.c
+++ b/drivers/net/ethernet/pensando/ionic/ionic_debugfs.c
@@ -170,8 +170,7 @@ void ionic_debugfs_add_qcq(struct ionic_lif *lif, struct 
ionic_qcq *qcq)
debugfs_create_x64("base_pa", 0400, cq_dentry, &cq->base_pa);
debugfs_create_u32("num_descs", 0400, cq_dentry, &cq->num_descs);
debugfs_create_u32("desc_size", 0400, cq_dentry, &cq->desc_size);
-   debugfs_create_u8("done_color", 0400, cq_dentry,
- (u8 *)&cq->done_color);
+   debugfs_create_bool("done_color", 0400, cq_dentry, &cq->done_color);
  
  	debugfs_create_file("tail", 0400, cq_dentry, cq, &cq_tail_fops);

RE: [PATCH 0/7] towards QE support on ARM

2019-10-21 Thread Qiang Zhao 
On Mon, Oct 22, 2019 at 6:11 AM Leo Li wrote
> -Original Message-
> From: Li Yang 
> Sent: 2019年10月22日 6:11
> To: Rasmus Villemoes 
> Cc: Timur Tabi ; Greg Kroah-Hartman
> ; linux-ker...@vger.kernel.org;
> linux-ser...@vger.kernel.org; Jiri Slaby ;
> linuxppc-dev@lists.ozlabs.org; linux-arm-ker...@lists.infradead.org; Qiang
> Zhao 
> Subject: Re: [PATCH 0/7] towards QE support on ARM
> 
> On Mon, Oct 21, 2019 at 3:46 AM Rasmus Villemoes
>  wrote:
> >
> > On 18/10/2019 23.52, Li Yang wrote:
> > > On Fri, Oct 18, 2019 at 3:54 PM Rasmus Villemoes
> > >  wrote:
> > >>
> > >> On 18/10/2019 22.16, Leo Li wrote:
> > >>>
> > 
> >  There have been several attempts in the past few years to allow
> >  building the QUICC engine drivers for platforms other than PPC.
> >  This is (the beginning of) yet another attempt. I hope I can get
> >  someone to pick up these relatively trivial patches (I _think_
> >  they shouldn't change functionality at all), and then I'll
> >  continue slowly working towards removing the PPC32 dependency for
> CONFIG_QUICC_ENGINE.
> > >>>
> > >>> Hi Rasmus,
> > >>>
> > >>> I don't fully understand the motivation of this work.  As far as I know
> the QUICC ENGINE is only used on PowerPC based SoCs.
> > >>
> > >> Hm, you're not the Leo Li that participated in this thread
> > >>
>  rnel.org%2Flkml%2FAM3PR04MB11857AE8D2B0BE56121B97D391C90%40A
> M3PR04MB1185.eurprd04.prod.outlook.com%2FT%2F%23u&data=02%7
> C01%7Cqiang.zhao%40nxp.com%7C1ba8c50c2db14b22bef608d756739d82%
> 7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C6370729268771788
> 75&sdata=k4zM75OczXwZF%2Br9ec4RxiVR2a%2F8GhSZmK70JYddIck%3
> D&reserved=0>?
> > >
> > > Oops, I totally forgot about this discussion which is just three
> > > years ago.  :)  The QE-HDLC on LS1021a is kind of a special case.
> > >
> > >>
> > >>
> > >>  Can you give an example on how is it used on ARM system?
> > >>
> > >> LS1021A, for example, which is the one I'm aiming for getting fully
> > >> supported in mainline.
> > >>  > >>
> www.nxp.com%2Fproducts%2Fprocessors-and-microcontrollers%2Farm-proc
> > >> essors%2Flayerscape-communication-process%2Fqoriq-layerscape-1021a-
> > >>
> dual-core-communications-processor-with-lcd-controller%3ALS1021A&am
> > >>
> p;data=02%7C01%7Cqiang.zhao%40nxp.com%7C1ba8c50c2db14b22bef608d
> 7567
> > >>
> 39d82%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C6370729268
> 771788
> > >>
> 75&sdata=vqPYSZqEv6vCEIxJshLuA4gngh9J4IsFAQrTwJKMjm4%3D&r
> es
> > >> erved=0>
> > >>
> > >> The forks at
> > >>
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.
> com%2Fqoriq-open-source%2Flinux.git&data=02%7C01%7Cqiang.zhao%
> 40nxp.com%7C1ba8c50c2db14b22bef608d756739d82%7C686ea1d3bc2b4c6
> fa92cd99c5c301635%7C0%7C0%7C637072926877178875&sdata=v4eG
> 4KqGTWQkQHp%2FYg2OHCKITLWaOgH64JYpY%2B1LilA%3D&reserved=0
> have various degrees of support (grep for commits saying stuff like "remove
> PPCisms"
> > >> - some versions can be found on
> > >>  > >>
> lore.kernel.org%2Flkml%2F%3Fq%3Dremove%2Bppcisms&data=02%7C0
> 1%7
> > >>
> Cqiang.zhao%40nxp.com%7C1ba8c50c2db14b22bef608d756739d82%7C686e
> a1d3
> > >>
> bc2b4c6fa92cd99c5c301635%7C0%7C0%7C637072926877178875&sdat
> a=i2WdKNHLV68a1mTOMQ%2FoMr0y5ee8edS07xq61M8%2BvPU%3D&r
> eserved=0>). Our current kernel is based on commits from the now-vanished
> 4.1 branch, and unfortunately at least the 4.14 branch (LSDK-18.06-V4.14)
> trivially doesn't build on ARM, despite the PPC32 dependency having been
> removed from CONFIG_QUICC_ENGINE.
> > >
> > > Can you try the 4.14 branch from a newer LSDK release?  LS1021a
> > > should be supported platform on LSDK.  If it is broken, something is
> wrong.
> >
> > What newer release? LSDK-18.06-V4.14 is the latest -V4.14 tag at
> > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith
> >
> ub.com%2Fqoriq-open-source%2Flinux.git&data=02%7C01%7Cqiang.zha
> o%4
> >
> 0nxp.com%7C1ba8c50c2db14b22bef608d756739d82%7C686ea1d3bc2b4c6f
> a92cd99c
> >
> 5c301635%7C0%7C0%7C637072926877188868&sdata=vdm4qPoTzfIpXL
> mRrv17EW
> > noxG3n91qELMGqvRh9we4%3D&reserved=0, and identical to the
> 
> That tree has been abandoned for a while, we probably should state that in the
> github.  The latest tree can be found at
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsource.
> codeaurora.org%2Fexternal%2Fqoriq%2Fqoriq-components%2Flinux%2F&
> ;data=02%7C01%7Cqiang.zhao%40nxp.com%7C1ba8c50c2db14b22bef608d7
> 56739d82%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C6370729
> 26877188868&sdata=NooBFUWnceTG2OF24pCuP0AYgKfr0Df%2BtrcCY6
> X6Dog%3D&reserved=0
> 
> > linux-4.14 branch. And despite commit 4c33e2d0576b removing the PPC32
> > dependency from QUICC_ENGINE, it clearly hasn't been built on arm,
> > si

[Bug 205283] BUG: KASAN: global-out-of-bounds in _copy_to_iter+0x3d4/0x5a8

2019-10-21 Thread bugzilla-daemon 
https://bugzilla.kernel.org/show_bug.cgi?id=205283

--- Comment #1 from Erhard F. (erhar...@mailbox.org) ---
Created attachment 285607
  --> https://bugzilla.kernel.org/attachment.cgi?id=285607&action=edit
5.4.0-rc4 kernel .config (PowerMac G4 DP)

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.

[Bug 205283] New: BUG: KASAN: global-out-of-bounds in _copy_to_iter+0x3d4/0x5a8

2019-10-21 Thread bugzilla-daemon 
https://bugzilla.kernel.org/show_bug.cgi?id=205283

Bug ID: 205283
   Summary: BUG: KASAN: global-out-of-bounds in
_copy_to_iter+0x3d4/0x5a8
   Product: File System
   Version: 2.5
Kernel Version: 5.4-rc4
  Hardware: PPC-32
OS: Linux
  Tree: Mainline
Status: NEW
  Severity: normal
  Priority: P1
 Component: btrfs
  Assignee: fs_bt...@kernel-bugs.kernel.org
  Reporter: erhar...@mailbox.org
CC: platform_ppc...@kernel-bugs.osdl.org
Regression: No

Created attachment 285605
  --> https://bugzilla.kernel.org/attachment.cgi?id=285605&action=edit
dmesg (kernel 5.4.0-rc4, PowerMac G4 DP)

First of all apologies 'cause I am not quite sure under what kernel subsystem
tracker I should file this bug. It was triggered running btrfs filesystem tests
(misc tests) on a PowerMac G4 DP and seems to touch some memcopy routine:

[...]
[  601.897623]
==
[  601.905117] BUG: KASAN: global-out-of-bounds in _copy_to_iter+0x3d4/0x5a8
[  601.912512] Write of size 4096 at addr f18b8000 by task modprobe/10589

[  601.927287] CPU: 1 PID: 10589 Comm: modprobe Tainted: GW
5.4.0-rc4-PowerMacG4+ #20
[  601.934991] Call Trace:
[  601.942534] [eb9cf848] [c0769184] dump_stack+0xb0/0x10c (unreliable)
[  601.950307] [eb9cf878] [c023aea8]
print_address_description.isra.5+0x3c/0x420
[  601.958167] [eb9cf908] [c023b470] __kasan_report+0x140/0x188
[  601.966030] [eb9cf948] [c023bea8] check_memory_region+0x28/0x184
[  601.973925] [eb9cf958] [c0239f30] memcpy+0x48/0x74
[  601.981792] [eb9cf978] [c044ab9c] _copy_to_iter+0x3d4/0x5a8
[  601.989705] [eb9cfaa8] [c044af18] copy_page_to_iter+0x90/0x550
[  601.997585] [eb9cfb08] [c01bcc60] generic_file_read_iter+0x5c8/0x7bc
[  602.005374] [eb9cfb78] [c0251e5c] __vfs_read+0x1b0/0x1f4
[  602.013027] [eb9cfca8] [c0251f5c] vfs_read+0xbc/0x124
[  602.020671] [eb9cfcd8] [c0252018] kernel_read+0x54/0x70
[  602.028302] [eb9cfd08] [c025c7d8] kernel_read_file+0x240/0x358
[  602.035930] [eb9cfdb8] [c025c9dc] kernel_read_file_from_fd+0x54/0x74
[  602.043581] [eb9cfdf8] [c010c494] sys_finit_module+0xd8/0x140
[  602.051183] [eb9cff38] [c001a274] ret_from_syscall+0x0/0x34
[  602.058641] --- interrupt: c01 at 0x7062c4
   LR = 0x88e7c4


[  602.087858] Memory state around the buggy address:
[  602.095160]  f18b7f00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[  602.102601]  f18b7f80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[  602.109845] >f18b8000: 00 06 fa fa fa fa fa fa 00 00 03 fa fa fa fa fa
[  602.117150]   ^
[  602.124218]  f18b8080: 00 00 04 fa fa fa fa fa 00 03 fa fa fa fa fa fa
[  602.131467]  f18b8100: 00 07 fa fa fa fa fa fa 00 00 03 fa fa fa fa fa
[  602.138638]
==

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.

Re: [PATCH 0/7] towards QE support on ARM

2019-10-21 Thread Li Yang 
On Mon, Oct 21, 2019 at 3:46 AM Rasmus Villemoes
 wrote:
>
> On 18/10/2019 23.52, Li Yang wrote:
> > On Fri, Oct 18, 2019 at 3:54 PM Rasmus Villemoes
> >  wrote:
> >>
> >> On 18/10/2019 22.16, Leo Li wrote:
> >>>
> 
>  There have been several attempts in the past few years to allow building 
>  the
>  QUICC engine drivers for platforms other than PPC. This is (the 
>  beginning of)
>  yet another attempt. I hope I can get someone to pick up these relatively
>  trivial patches (I _think_ they shouldn't change functionality at all), 
>  and then
>  I'll continue slowly working towards removing the PPC32 dependency for
>  CONFIG_QUICC_ENGINE.
> >>>
> >>> Hi Rasmus,
> >>>
> >>> I don't fully understand the motivation of this work.  As far as I know 
> >>> the QUICC ENGINE is only used on PowerPC based SoCs.
> >>
> >> Hm, you're not the Leo Li that participated in this thread
> >> ?
> >
> > Oops, I totally forgot about this discussion which is just three years
> > ago.  :)  The QE-HDLC on LS1021a is kind of a special case.
> >
> >>
> >>
> >>  Can you give an example on how is it used on ARM system?
> >>
> >> LS1021A, for example, which is the one I'm aiming for getting fully
> >> supported in mainline.
> >> 
> >>
> >> The forks at https://github.com/qoriq-open-source/linux.git have various
> >> degrees of support (grep for commits saying stuff like "remove PPCisms"
> >> - some versions can be found on
> >> ). Our current kernel is
> >> based on commits from the now-vanished 4.1 branch, and unfortunately at
> >> least the 4.14 branch (LSDK-18.06-V4.14) trivially doesn't build on ARM,
> >> despite the PPC32 dependency having been removed from CONFIG_QUICC_ENGINE.
> >
> > Can you try the 4.14 branch from a newer LSDK release?  LS1021a should
> > be supported platform on LSDK.  If it is broken, something is wrong.
>
> What newer release? LSDK-18.06-V4.14 is the latest -V4.14 tag at
> https://github.com/qoriq-open-source/linux.git, and identical to the

That tree has been abandoned for a while, we probably should state
that in the github.  The latest tree can be found at
https://source.codeaurora.org/external/qoriq/qoriq-components/linux/

> linux-4.14 branch. And despite commit 4c33e2d0576b removing the PPC32
> dependency from QUICC_ENGINE, it clearly hasn't been built on arm, since
> back around v4.12, mainline's qe.c grew a call to pvr_version_is which
> is ppc-only. So from that I sort of assumed that NXP had dropped trying
> to support the LS1021A even in their own kernels.
>
> In any case, we have zero interest in running an NXP kernel. Maybe I
> should clarify what I meant by "based on commits from" above: We're
> currently running a mainline 4.14 kernel on LS1021A, with a few patches
> inspired from the NXP 4.1 branch applied on top - but also with some
> manual fixes for e.g. the pvr_version_is() issue. Now we want to move
> that to a 4.19-based kernel (so that it aligns with our MPC8309 platform).

We also provide 4.19 based kernel in the codeaurora repo.  I think it
will be helpful to reuse patches there if you want to make your own
tree.

>
> >> This is just some first few steps, and I'm not claiming
> >> that this is sufficient to make the QE drivers build on ARM yet. But I
> >> have a customer with both mpc8309-based and ls1021a-based platforms, and
> >> they want to run the same, as-close-to-mainline-as-possible, kernel on
> >> both. So I will take a piecemeal approach, and try to make sure I don't
> >> break the ppc boards in the process (just building and booting one board
> >> is of course not sufficient, but better than nothing). Once I get to
> >> actually build some of the QE drivers for ARM, I'll of course also test
> >> them.
> >
> > Understood.  Zhao Qiang also maintains some patches similar to your
> > patchset and I think they are tested on ARM.  But the review of these
> > patches from last submission didn't finish.  It looks like your
> > patches are better divided but not really verified on ARM.  Zhao
> > Qiang's patches are tested but maybe need some final touch for
> > cleaning up.  I will let you guys decide what is the best approach to
> > make this upstreamed.
>
> Yes, as I said, I wanted to try a fresh approach since Zhao
> Qiang's patches seemed to be getting nowhere. Splitting the patches into
> smaller pieces is definitely part of that - for example, the completely
> trivial whitespace fix in patch 1 is to make sure the later coccinelle
> generated patch is precisely that (i.e., a later respin can just rerun
> the coccinelle script, with zero manual fixups). I also want to avoid
> mixing

Re: [RFC PATCH] powerpc/32: Switch VDSO to C implementation.

2019-10-21 Thread Thomas Gleixner 
On Mon, 21 Oct 2019, Christophe Leroy wrote:

> This is a tentative to switch powerpc/32 vdso to generic C implementation.
> It will likely not work on 64 bits or even build properly at the moment.
> 
> powerpc is a bit special for VDSO as well as system calls in the
> way that it requires setting CR SO bit which cannot be done in C.
> Therefore, entry/exit and fallback needs to be performed in ASM.
> 
> To allow that, C fallbacks just return -1 and the ASM entry point
> performs the system call when the C function returns -1.
> 
> The performance is rather disappoiting. That's most likely all
> calculation in the C implementation are based on 64 bits math and
> converted to 32 bits at the very end. I guess C implementation should
> use 32 bits math like the assembly VDSO does as of today.

> gettimeofday:vdso: 750 nsec/call
> 
> gettimeofday:vdso: 1533 nsec/call

The only real 64bit math which can matter is the 64bit * 32bit multiply,
i.e.

static __always_inline
u64 vdso_calc_delta(u64 cycles, u64 last, u64 mask, u32 mult)
{
return ((cycles - last) & mask) * mult;
}

Everything else is trivial add/sub/shift, which should be roughly the same
in ASM.

Can you try to replace that with:

static __always_inline
u64 vdso_calc_delta(u64 cycles, u64 last, u64 mask, u32 mult)
{
u64 ret, delta = ((cycles - last) & mask);
u32 dh, dl;

dl = delta;
dh = delta >> 32;

res = mul_u32_u32(al, mul);
if (ah)
res += mul_u32_u32(ah, mul) << 32;

return res;
}

That's pretty much what __do_get_tspec does in ASM.

Thanks,

tglx

[Bug 199561] sungem: RX MAC fifo overflow smac[03910440]

2019-10-21 Thread bugzilla-daemon 
https://bugzilla.kernel.org/show_bug.cgi?id=199561

Erhard F. (erhar...@mailbox.org) changed:

   What|Removed |Added

 CC||linuxppc-dev@lists.ozlabs.o
   ||rg
   Hardware|PPC-64  |PPC-32
 Kernel Version|4.19.19 |5.4-rc4

--- Comment #4 from Erhard F. (erhar...@mailbox.org) ---
On 5.4-rc4 I am getting now:

[   43.822417] sungem_phy: PHY ID: 2060e1, addr: 0
[   43.831184] gem 0002:20:0f.0 enP2p32s15f0: Found BCM5421 PHY
[   47.502223] gem 0002:20:0f.0 enP2p32s15f0: Link is up at 1000 Mbps,
full-duplex
[   47.502697] gem 0002:20:0f.0 enP2p32s15f0: Pause is enabled (rxfifo: 10240
off: 7168 on: 5632)
[   47.503173] IPv6: ADDRCONF(NETDEV_CHANGE): enP2p32s15f0: link becomes ready
[...]
[  423.097905] gem 0002:20:0f.0 enP2p32s15f0: Memory squeeze, deferring packet
[  423.125951] gem 0002:20:0f.0 enP2p32s15f0: Memory squeeze, deferring packet
[  423.148828] gem 0002:20:0f.0 enP2p32s15f0: Memory squeeze, deferring packet
[  423.156830] gem 0002:20:0f.0 enP2p32s15f0: RX MAC fifo overflow
smac[00910440]
[  423.243823] gem 0002:20:0f.0 enP2p32s15f0: Memory squeeze, deferring packet

-- 
You are receiving this mail because:
You are on the CC list for the bug.

Re: [PATCH] lib/vdso: Make clock_getres() POSIX compliant again

2019-10-21 Thread Christophe Leroy 




Le 21/10/2019 à 12:07, Thomas Gleixner a écrit :

A recent commit removed the NULL pointer check from the clock_getres()
implementation causing a test case to fault.

POSIX requires an explicit NULL pointer check for clock_getres() aside of
the validity check of the clock_id argument for obscure reasons.

Add it back for both 32bit and 64bit.

Note, this is only a partial revert of the offending commit which does not
bring back the broken fallback invocation in the the 32bit compat
implementations of clock_getres() and clock_gettime().

Fixes: a9446a906f52 ("lib/vdso/32: Remove inconsistent NULL pointer checks")
Reported-by: Andreas Schwab 
Signed-off-by: Thomas Gleixner 


Tested-by: Christophe Leroy 


Cc: sta...@vger.kernel.org
---
  lib/vdso/gettimeofday.c |9 +
  1 file changed, 5 insertions(+), 4 deletions(-)

--- a/lib/vdso/gettimeofday.c
+++ b/lib/vdso/gettimeofday.c
@@ -214,9 +214,10 @@ int __cvdso_clock_getres_common(clockid_
return -1;
}
  
-	res->tv_sec = 0;

-   res->tv_nsec = ns;
-
+   if (likely(res)) {
+   res->tv_sec = 0;
+   res->tv_nsec = ns;
+   }
return 0;
  }
  
@@ -245,7 +246,7 @@ static __maybe_unused int

ret = clock_getres_fallback(clock, &ts);
  #endif
  
-	if (likely(!ret)) {

+   if (likely(!ret && res)) {
res->tv_sec = ts.tv_sec;
res->tv_nsec = ts.tv_nsec;
}

[PATCH 1/5] crypto: nx - Improve debugfs_create_u{32, 64}() handling for atomics

2019-10-21 Thread Geert Uytterhoeven 
Variables of type atomic{,64}_t can be used fine with
debugfs_create_u{32,64}, when passing a pointer to the embedded counter.
This allows to get rid of the casts, which prevented compiler checks.

Signed-off-by: Geert Uytterhoeven 
---
 drivers/crypto/nx/nx_debugfs.c | 18 +-
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/drivers/crypto/nx/nx_debugfs.c b/drivers/crypto/nx/nx_debugfs.c
index e0d44a5512ab455b..1975bcbee997481e 100644
--- a/drivers/crypto/nx/nx_debugfs.c
+++ b/drivers/crypto/nx/nx_debugfs.c
@@ -38,23 +38,23 @@ void nx_debugfs_init(struct nx_crypto_driver *drv)
drv->dfs_root = root;
 
debugfs_create_u32("aes_ops", S_IRUSR | S_IRGRP | S_IROTH,
-  root, (u32 *)&drv->stats.aes_ops);
+  root, &drv->stats.aes_ops.counter);
debugfs_create_u32("sha256_ops", S_IRUSR | S_IRGRP | S_IROTH,
-  root, (u32 *)&drv->stats.sha256_ops);
+  root, &drv->stats.sha256_ops.counter);
debugfs_create_u32("sha512_ops", S_IRUSR | S_IRGRP | S_IROTH,
-  root, (u32 *)&drv->stats.sha512_ops);
+  root, &drv->stats.sha512_ops.counter);
debugfs_create_u64("aes_bytes", S_IRUSR | S_IRGRP | S_IROTH,
-  root, (u64 *)&drv->stats.aes_bytes);
+  root, &drv->stats.aes_bytes.counter);
debugfs_create_u64("sha256_bytes", S_IRUSR | S_IRGRP | S_IROTH,
-  root, (u64 *)&drv->stats.sha256_bytes);
+  root, &drv->stats.sha256_bytes.counter);
debugfs_create_u64("sha512_bytes", S_IRUSR | S_IRGRP | S_IROTH,
-  root, (u64 *)&drv->stats.sha512_bytes);
+  root, &drv->stats.sha512_bytes.counter);
debugfs_create_u32("errors", S_IRUSR | S_IRGRP | S_IROTH,
-  root, (u32 *)&drv->stats.errors);
+  root, &drv->stats.errors.counter);
debugfs_create_u32("last_error", S_IRUSR | S_IRGRP | S_IROTH,
-  root, (u32 *)&drv->stats.last_error);
+  root, &drv->stats.last_error.counter);
debugfs_create_u32("last_error_pid", S_IRUSR | S_IRGRP | S_IROTH,
-  root, (u32 *)&drv->stats.last_error_pid);
+  root, &drv->stats.last_error_pid.counter);
 }
 
 void
-- 
2.17.1

[PATCH 5/5] ionic: Use debugfs_create_bool() to export bool

2019-10-21 Thread Geert Uytterhoeven 
Currently bool ionic_cq.done_color is exported using
debugfs_create_u8(), which requires a cast, preventing further compiler
checks.

Fix this by switching to debugfs_create_bool(), and dropping the cast.

Signed-off-by: Geert Uytterhoeven 
---
 drivers/net/ethernet/pensando/ionic/ionic_debugfs.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/net/ethernet/pensando/ionic/ionic_debugfs.c 
b/drivers/net/ethernet/pensando/ionic/ionic_debugfs.c
index bc03cecf80cc9eb4..5beba915f69d12dd 100644
--- a/drivers/net/ethernet/pensando/ionic/ionic_debugfs.c
+++ b/drivers/net/ethernet/pensando/ionic/ionic_debugfs.c
@@ -170,8 +170,7 @@ void ionic_debugfs_add_qcq(struct ionic_lif *lif, struct 
ionic_qcq *qcq)
debugfs_create_x64("base_pa", 0400, cq_dentry, &cq->base_pa);
debugfs_create_u32("num_descs", 0400, cq_dentry, &cq->num_descs);
debugfs_create_u32("desc_size", 0400, cq_dentry, &cq->desc_size);
-   debugfs_create_u8("done_color", 0400, cq_dentry,
- (u8 *)&cq->done_color);
+   debugfs_create_bool("done_color", 0400, cq_dentry, &cq->done_color);
 
debugfs_create_file("tail", 0400, cq_dentry, cq, &cq_tail_fops);
 
-- 
2.17.1

[PATCH 2/5] cxgb4/cxgb4vf: Remove superfluous void * cast in debugfs_create_file() call

2019-10-21 Thread Geert Uytterhoeven 
There is no need to cast a typed pointer to a void pointer when calling
a function that accepts the latter.  Remove it, as the cast prevents
further compiler checks.

Signed-off-by: Geert Uytterhoeven 
---
 drivers/net/ethernet/chelsio/cxgb4vf/cxgb4vf_main.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/chelsio/cxgb4vf/cxgb4vf_main.c 
b/drivers/net/ethernet/chelsio/cxgb4vf/cxgb4vf_main.c
index f6fc0875d5b0a285..4a07a73c672b5996 100644
--- a/drivers/net/ethernet/chelsio/cxgb4vf/cxgb4vf_main.c
+++ b/drivers/net/ethernet/chelsio/cxgb4vf/cxgb4vf_main.c
@@ -2480,7 +2480,7 @@ static int setup_debugfs(struct adapter *adapter)
for (i = 0; i < ARRAY_SIZE(debugfs_files); i++)
debugfs_create_file(debugfs_files[i].name,
debugfs_files[i].mode,
-   adapter->debugfs_root, (void *)adapter,
+   adapter->debugfs_root, adapter,
debugfs_files[i].fops);
 
return 0;
-- 
2.17.1

[PATCH 3/5] drm/amdgpu: Remove superfluous void * cast in debugfs_create_file() call

2019-10-21 Thread Geert Uytterhoeven 
There is no need to cast a typed pointer to a void pointer when calling
a function that accepts the latter.  Remove it, as the cast prevents
further compiler checks.

Signed-off-by: Geert Uytterhoeven 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
index 5652cc72ed3a9b3a..b97a38b1e089b3d6 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
@@ -1090,8 +1090,8 @@ int amdgpu_debugfs_init(struct amdgpu_device *adev)
 {
adev->debugfs_preempt =
debugfs_create_file("amdgpu_preempt_ib", 0600,
-   adev->ddev->primary->debugfs_root,
-   (void *)adev, &fops_ib_preempt);
+   adev->ddev->primary->debugfs_root, adev,
+   &fops_ib_preempt);
if (!(adev->debugfs_preempt)) {
DRM_ERROR("unable to create amdgpu_preempt_ib debugsfs file\n");
return -EIO;
-- 
2.17.1

[PATCH 0/5] debugfs: Remove casts in debugfs_create_*() callers

2019-10-21 Thread Geert Uytterhoeven 
Hi all,

Casting parameters in debugfs_create_*() calls prevents the compiler
from performing some checks.

Hence this patch series removes superfluous casts, or reworks code to no
longer need the casts.

All patches can be applied independently, there are no dependencies.
Thanks for your comments!

Geert Uytterhoeven (5):
  crypto: nx - Improve debugfs_create_u{32,64}() handling for atomics
  cxgb4/cxgb4vf: Remove superfluous void * cast in debugfs_create_file()
call
  drm/amdgpu: Remove superfluous void * cast in debugfs_create_file()
call
  power: avs: smartreflex: Remove superfluous cast in
debugfs_create_file() call
  ionic: Use debugfs_create_bool() to export bool

 drivers/crypto/nx/nx_debugfs.c | 18 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c|  4 ++--
 .../ethernet/chelsio/cxgb4vf/cxgb4vf_main.c|  2 +-
 .../ethernet/pensando/ionic/ionic_debugfs.c|  3 +--
 drivers/power/avs/smartreflex.c|  2 +-
 5 files changed, 14 insertions(+), 15 deletions(-)

-- 
2.17.1

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

[PATCH 4/5] power: avs: smartreflex: Remove superfluous cast in debugfs_create_file() call

2019-10-21 Thread Geert Uytterhoeven 
There is no need to cast a typed pointer to a void pointer when calling
a function that accepts the latter.  Remove it, as the cast prevents
further compiler checks.

Signed-off-by: Geert Uytterhoeven 
---
 drivers/power/avs/smartreflex.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/power/avs/smartreflex.c b/drivers/power/avs/smartreflex.c
index 4684e7df833a81e9..5376f3d22f31eade 100644
--- a/drivers/power/avs/smartreflex.c
+++ b/drivers/power/avs/smartreflex.c
@@ -905,7 +905,7 @@ static int omap_sr_probe(struct platform_device *pdev)
sr_info->dbg_dir = debugfs_create_dir(sr_info->name, sr_dbg_dir);
 
debugfs_create_file("autocomp", S_IRUGO | S_IWUSR, sr_info->dbg_dir,
-   (void *)sr_info, &pm_sr_fops);
+   sr_info, &pm_sr_fops);
debugfs_create_x32("errweight", S_IRUGO, sr_info->dbg_dir,
   &sr_info->err_weight);
debugfs_create_x32("errmaxlimit", S_IRUGO, sr_info->dbg_dir,
-- 
2.17.1

[PATCH] powerpc/security: Fix debugfs data leak on 32-bit

2019-10-21 Thread Geert Uytterhoeven 
"powerpc_security_features" is "unsigned long", i.e. 32-bit or 64-bit,
depending on the platform (PPC_FSL_BOOK3E or PPC_BOOK3S_64).  Hence
casting its address to "u64 *", and calling debugfs_create_x64() is
wrong, and leaks 32-bit of nearby data to userspace on 32-bit platforms.

While all currently defined SEC_FTR_* security feature flags fit in
32-bit, they all have "ULL" suffixes to make them 64-bit constants.
Hence fix the leak by changing the type of "powerpc_security_features"
(and the parameter types of its accessors) to "u64".  This also allows
to drop the cast.

Fixes: 398af571128fe75f ("powerpc/security: Show powerpc_security_features in 
debugfs")
Signed-off-by: Geert Uytterhoeven 
---
Compile-tested only.

Alternatively, powerpc_security_features could be changed to u32.
However, that would require using debugfs_create_x32() instead of
debugfs_create_x64(), which would change the debugfs file formatting
from "0x%016llx" to "0x%08llx".
---
 arch/powerpc/include/asm/security_features.h | 8 
 arch/powerpc/kernel/security.c   | 4 ++--
 2 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/arch/powerpc/include/asm/security_features.h 
b/arch/powerpc/include/asm/security_features.h
index 759597bf0fd867bd..a3e8ecd48dc7ffa0 100644
--- a/arch/powerpc/include/asm/security_features.h
+++ b/arch/powerpc/include/asm/security_features.h
@@ -9,7 +9,7 @@
 #define _ASM_POWERPC_SECURITY_FEATURES_H
 
 
-extern unsigned long powerpc_security_features;
+extern u64 powerpc_security_features;
 extern bool rfi_flush;
 
 /* These are bit flags */
@@ -24,17 +24,17 @@ void setup_stf_barrier(void);
 void do_stf_barrier_fixups(enum stf_barrier_type types);
 void setup_count_cache_flush(void);
 
-static inline void security_ftr_set(unsigned long feature)
+static inline void security_ftr_set(u64 feature)
 {
powerpc_security_features |= feature;
 }
 
-static inline void security_ftr_clear(unsigned long feature)
+static inline void security_ftr_clear(u64 feature)
 {
powerpc_security_features &= ~feature;
 }
 
-static inline bool security_ftr_enabled(unsigned long feature)
+static inline bool security_ftr_enabled(u64 feature)
 {
return !!(powerpc_security_features & feature);
 }
diff --git a/arch/powerpc/kernel/security.c b/arch/powerpc/kernel/security.c
index 7cfcb294b11ca7be..2e9a7e20d05c5f79 100644
--- a/arch/powerpc/kernel/security.c
+++ b/arch/powerpc/kernel/security.c
@@ -16,7 +16,7 @@
 #include 
 
 
-unsigned long powerpc_security_features __read_mostly = SEC_FTR_DEFAULT;
+u64 powerpc_security_features __read_mostly = SEC_FTR_DEFAULT;
 
 enum count_cache_flush_type {
COUNT_CACHE_FLUSH_NONE  = 0x1,
@@ -108,7 +108,7 @@ device_initcall(barrier_nospec_debugfs_init);
 static __init int security_feature_debugfs_init(void)
 {
debugfs_create_x64("security_features", 0400, powerpc_debugfs_root,
-  (u64 *)&powerpc_security_features);
+  &powerpc_security_features);
return 0;
 }
 device_initcall(security_feature_debugfs_init);
-- 
2.17.1

[RFC PATCH] powerpc/32: Switch VDSO to C implementation.

2019-10-21 Thread Christophe Leroy 
This is a tentative to switch powerpc/32 vdso to generic C implementation.
It will likely not work on 64 bits or even build properly at the moment.

powerpc is a bit special for VDSO as well as system calls in the
way that it requires setting CR SO bit which cannot be done in C.
Therefore, entry/exit and fallback needs to be performed in ASM.

To allow that, C fallbacks just return -1 and the ASM entry point
performs the system call when the C function returns -1.

The performance is rather disappoiting. That's most likely all
calculation in the C implementation are based on 64 bits math and
converted to 32 bits at the very end. I guess C implementation should
use 32 bits math like the assembly VDSO does as of today.

With current powerpc/32 ASM VDSO:

gettimeofday:vdso: 750 nsec/call
clock-getres-realtime:vdso: 382 nsec/call
clock-gettime-realtime:vdso: 928 nsec/call
clock-getres-monotonic:vdso: 382 nsec/call
clock-gettime-monotonic:vdso: 1033 nsec/call

Once switched to C implementation:

gettimeofday:vdso: 1533 nsec/call
clock-getres-realtime:vdso: 853 nsec/call
clock-gettime-realtime:vdso: 1570 nsec/call
clock-getres-monotonic:vdso: 835 nsec/call
clock-gettime-monotonic:vdso: 1605 nsec/call
Signed-off-by: Christophe Leroy 
---
 arch/powerpc/Kconfig |   2 +
 arch/powerpc/include/asm/vdso/gettimeofday.h |  81 
 arch/powerpc/include/asm/vdso/vsyscall.h |  27 +++
 arch/powerpc/include/asm/vdso_datapage.h |  16 +-
 arch/powerpc/kernel/asm-offsets.c|  26 +--
 arch/powerpc/kernel/time.c   |  90 +
 arch/powerpc/kernel/vdso.c   |  19 +-
 arch/powerpc/kernel/vdso32/Makefile  |  19 +-
 arch/powerpc/kernel/vdso32/gettimeofday.S| 270 ++-
 arch/powerpc/kernel/vdso32/vgettimeofday.c   |  32 
 10 files changed, 233 insertions(+), 349 deletions(-)
 create mode 100644 arch/powerpc/include/asm/vdso/gettimeofday.h
 create mode 100644 arch/powerpc/include/asm/vdso/vsyscall.h
 create mode 100644 arch/powerpc/kernel/vdso32/vgettimeofday.c

diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 3e56c9c2f16e..a363c5186b82 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -168,6 +168,7 @@ config PPC
select GENERIC_STRNCPY_FROM_USER
select GENERIC_STRNLEN_USER
select GENERIC_TIME_VSYSCALL
+   select GENERIC_GETTIMEOFDAY
select HAVE_ARCH_AUDITSYSCALL
select HAVE_ARCH_HUGE_VMAP  if PPC_BOOK3S_64 && 
PPC_RADIX_MMU
select HAVE_ARCH_JUMP_LABEL
@@ -197,6 +198,7 @@ config PPC
select HAVE_FUNCTION_GRAPH_TRACER
select HAVE_FUNCTION_TRACER
select HAVE_GCC_PLUGINS if GCC_VERSION >= 50200   # 
plugin support on gcc <= 5.1 is buggy on PPC
+   select HAVE_GENERIC_VDSO
select HAVE_HW_BREAKPOINT   if PERF_EVENTS && (PPC_BOOK3S 
|| PPC_8xx)
select HAVE_IDE
select HAVE_IOREMAP_PROT
diff --git a/arch/powerpc/include/asm/vdso/gettimeofday.h 
b/arch/powerpc/include/asm/vdso/gettimeofday.h
new file mode 100644
index ..6de875cf4b75
--- /dev/null
+++ b/arch/powerpc/include/asm/vdso/gettimeofday.h
@@ -0,0 +1,81 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Copyright (C) 2018 ARM Limited
+ */
+#ifndef __ASM_VDSO_GETTIMEOFDAY_H
+#define __ASM_VDSO_GETTIMEOFDAY_H
+
+#ifndef __ASSEMBLY__
+
+#include 
+#include 
+#include 
+
+#define __VDSO_USE_SYSCALL ULLONG_MAX
+
+#define VDSO_HAS_CLOCK_GETRES  1
+
+#define VDSO_HAS_TIME  1
+
+#define VDSO_HAS_32BIT_FALLBACK1
+
+static __always_inline
+int gettimeofday_fallback(struct __kernel_old_timeval *_tv,
+ struct timezone *_tz)
+{
+   return -1;
+}
+
+static __always_inline
+long clock_gettime_fallback(clockid_t _clkid, struct __kernel_timespec *_ts)
+{
+   return -1;
+}
+
+static __always_inline
+int clock_getres_fallback(clockid_t _clkid, struct __kernel_timespec *_ts)
+{
+   return -1;
+}
+
+static __always_inline
+int clock_getres32_fallback(clockid_t clock, struct old_timespec32 *res)
+{
+   return -1;
+}
+
+static __always_inline
+int clock_gettime32_fallback(clockid_t clock, struct old_timespec32 *res)
+{
+   return -1;
+}
+
+static __always_inline u64 __arch_get_hw_counter(s32 clock_mode)
+{
+   /*
+* clock_mode == 0 implies that vDSO are enabled otherwise
+* fallback on syscall.
+*/
+   if (clock_mode)
+   return __VDSO_USE_SYSCALL;
+
+   return get_tb();
+}
+
+static __always_inline
+const struct vdso_data *__arch_get_vdso_data(void)
+{
+   void *ptr;
+
+   asm volatile(
+   "   bcl 20, 31, .+4;\n"
+   "   mflr%0;\n"
+   "   addi%0, %0, __kernel_datapage_offset - (.-4);\n"
+   : "=b"(ptr) : : "lr");
+
+   return ptr + *(unsigned long

[PATCH v1] usb: fsl: Remove unused variable

2019-10-21 Thread Yinbo Zhu 
From: Nikhil Badola 

Remove unused variable td_complete

Signed-off-by: Nikhil Badola 
Reviewed-by: Ran Wang 
Reviewed-by: Peter Chen 
---
 drivers/usb/gadget/udc/fsl_udc_core.c | 5 +
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/drivers/usb/gadget/udc/fsl_udc_core.c 
b/drivers/usb/gadget/udc/fsl_udc_core.c
index 9a05863b2876..381fdff12d4e 100644
--- a/drivers/usb/gadget/udc/fsl_udc_core.c
+++ b/drivers/usb/gadget/udc/fsl_udc_core.c
@@ -1595,14 +1595,13 @@ static int process_ep_req(struct fsl_udc *udc, int pipe,
struct fsl_req *curr_req)
 {
struct ep_td_struct *curr_td;
-   int td_complete, actual, remaining_length, j, tmp;
+   int actual, remaining_length, j, tmp;
int status = 0;
int errors = 0;
struct  ep_queue_head *curr_qh = &udc->ep_qh[pipe];
int direction = pipe % 2;
 
curr_td = curr_req->head;
-   td_complete = 0;
actual = curr_req->req.length;
 
for (j = 0; j < curr_req->dtd_count; j++) {
@@ -1647,11 +1646,9 @@ static int process_ep_req(struct fsl_udc *udc, int pipe,
status = -EPROTO;
break;
} else {
-   td_complete++;
break;
}
} else {
-   td_complete++;
VDBG("dTD transmitted successful");
}
 
-- 
2.17.1

[PATCH v1] usb: fsl: Check memory resource before releasing it

2019-10-21 Thread Yinbo Zhu 
From: Nikhil Badola 

Check memory resource existence before releasing it to avoid NULL
pointer dereference

Signed-off-by: Nikhil Badola 
Reviewed-by: Ran Wang 
Reviewed-by: Peter Chen 
---
 drivers/usb/gadget/udc/fsl_udc_core.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/usb/gadget/udc/fsl_udc_core.c 
b/drivers/usb/gadget/udc/fsl_udc_core.c
index 20141c3096f6..9a05863b2876 100644
--- a/drivers/usb/gadget/udc/fsl_udc_core.c
+++ b/drivers/usb/gadget/udc/fsl_udc_core.c
@@ -2576,7 +2576,7 @@ static int fsl_udc_remove(struct platform_device *pdev)
dma_pool_destroy(udc_controller->td_pool);
free_irq(udc_controller->irq, udc_controller);
iounmap(dr_regs);
-   if (pdata->operating_mode == FSL_USB2_DR_DEVICE)
+   if (res && (pdata->operating_mode == FSL_USB2_DR_DEVICE))
release_mem_region(res->start, resource_size(res));
 
/* free udc --wait for the release() finished */
-- 
2.17.1

[PATCH v1] usb: gadget: Correct NULL pointer checking in fsl gadget

2019-10-21 Thread Yinbo Zhu 
From: Nikhil Badola 

Correct NULL pointer checking for endpoint descriptor
before it gets dereferenced

Signed-off-by: Nikhil Badola 
Signed-off-by: Ran Wang 
Reviewed-by: Peter Chen 
---
 drivers/usb/gadget/udc/fsl_udc_core.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/gadget/udc/fsl_udc_core.c 
b/drivers/usb/gadget/udc/fsl_udc_core.c
index 381fdff12d4e..980cb1382851 100644
--- a/drivers/usb/gadget/udc/fsl_udc_core.c
+++ b/drivers/usb/gadget/udc/fsl_udc_core.c
@@ -1052,10 +1052,11 @@ static int fsl_ep_fifo_status(struct usb_ep *_ep)
u32 bitmask;
struct ep_queue_head *qh;
 
-   ep = container_of(_ep, struct fsl_ep, ep);
-   if (!_ep || (!ep->ep.desc && ep_index(ep) != 0))
+   if (!_ep || _ep->desc || !(_ep->desc->bEndpointAddress&0xF))
return -ENODEV;
 
+   ep = container_of(_ep, struct fsl_ep, ep);
+
udc = (struct fsl_udc *)ep->udc;
 
if (!udc->driver || udc->gadget.speed == USB_SPEED_UNKNOWN)
-- 
2.17.1

[PATCH] lib/vdso: Make clock_getres() POSIX compliant again

2019-10-21 Thread Thomas Gleixner 
A recent commit removed the NULL pointer check from the clock_getres()
implementation causing a test case to fault.

POSIX requires an explicit NULL pointer check for clock_getres() aside of
the validity check of the clock_id argument for obscure reasons.

Add it back for both 32bit and 64bit.

Note, this is only a partial revert of the offending commit which does not
bring back the broken fallback invocation in the the 32bit compat
implementations of clock_getres() and clock_gettime().

Fixes: a9446a906f52 ("lib/vdso/32: Remove inconsistent NULL pointer checks")
Reported-by: Andreas Schwab 
Signed-off-by: Thomas Gleixner 
Cc: sta...@vger.kernel.org
---
 lib/vdso/gettimeofday.c |9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

--- a/lib/vdso/gettimeofday.c
+++ b/lib/vdso/gettimeofday.c
@@ -214,9 +214,10 @@ int __cvdso_clock_getres_common(clockid_
return -1;
}
 
-   res->tv_sec = 0;
-   res->tv_nsec = ns;
-
+   if (likely(res)) {
+   res->tv_sec = 0;
+   res->tv_nsec = ns;
+   }
return 0;
 }
 
@@ -245,7 +246,7 @@ static __maybe_unused int
ret = clock_getres_fallback(clock, &ts);
 #endif
 
-   if (likely(!ret)) {
+   if (likely(!ret && res)) {
res->tv_sec = ts.tv_sec;
res->tv_nsec = ts.tv_nsec;
}

RE: passing NULL to clock_getres (VDSO): terminated by unexpected signal 11

2019-10-21 Thread David Laight 
From: Thomas Gleixner
> Sent: 20 October 2019 20:53
> On Sun, 20 Oct 2019, Andreas Schwab wrote:
> > On Okt 20 2019, Thomas Gleixner wrote:
> >
> > > POSIX does not mention anything about the validity of the pointer handed 
> > > to
> > > clock_getres().
> >
> > Sure it does: "If the argument res is not NULL, the resolution of the
> > specified clock shall be stored in the location pointed to by res.  If
> > res is NULL, the clock resolution is not returned.".
> 
> Sigh, that makes a lot of sense - NOT.
> 
> But for the sake of making a non-sensical specification happy we can add a
> NULL pointer check for this. The interesting question is what should be
> returned in this case. The kernel returns EFAULT which is probably not
> POSIX compliant either.

The application won't see errno == EFAULT.
EFAULT gets converted to SIGSEGV (probably) in the return-to-user code path.

David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, 
UK
Registration No: 1397386 (Wales)

Re: [PATCH 0/7] towards QE support on ARM

2019-10-21 Thread Rasmus Villemoes 
On 18/10/2019 23.52, Li Yang wrote:
> On Fri, Oct 18, 2019 at 3:54 PM Rasmus Villemoes
>  wrote:
>>
>> On 18/10/2019 22.16, Leo Li wrote:
>>>

 There have been several attempts in the past few years to allow building 
 the
 QUICC engine drivers for platforms other than PPC. This is (the beginning 
 of)
 yet another attempt. I hope I can get someone to pick up these relatively
 trivial patches (I _think_ they shouldn't change functionality at all), 
 and then
 I'll continue slowly working towards removing the PPC32 dependency for
 CONFIG_QUICC_ENGINE.
>>>
>>> Hi Rasmus,
>>>
>>> I don't fully understand the motivation of this work.  As far as I know the 
>>> QUICC ENGINE is only used on PowerPC based SoCs.
>>
>> Hm, you're not the Leo Li that participated in this thread
>> ?
> 
> Oops, I totally forgot about this discussion which is just three years
> ago.  :)  The QE-HDLC on LS1021a is kind of a special case.
> 
>>
>>
>>  Can you give an example on how is it used on ARM system?
>>
>> LS1021A, for example, which is the one I'm aiming for getting fully
>> supported in mainline.
>> 
>>
>> The forks at https://github.com/qoriq-open-source/linux.git have various
>> degrees of support (grep for commits saying stuff like "remove PPCisms"
>> - some versions can be found on
>> ). Our current kernel is
>> based on commits from the now-vanished 4.1 branch, and unfortunately at
>> least the 4.14 branch (LSDK-18.06-V4.14) trivially doesn't build on ARM,
>> despite the PPC32 dependency having been removed from CONFIG_QUICC_ENGINE.
> 
> Can you try the 4.14 branch from a newer LSDK release?  LS1021a should
> be supported platform on LSDK.  If it is broken, something is wrong.

What newer release? LSDK-18.06-V4.14 is the latest -V4.14 tag at
https://github.com/qoriq-open-source/linux.git, and identical to the
linux-4.14 branch. And despite commit 4c33e2d0576b removing the PPC32
dependency from QUICC_ENGINE, it clearly hasn't been built on arm, since
back around v4.12, mainline's qe.c grew a call to pvr_version_is which
is ppc-only. So from that I sort of assumed that NXP had dropped trying
to support the LS1021A even in their own kernels.

In any case, we have zero interest in running an NXP kernel. Maybe I
should clarify what I meant by "based on commits from" above: We're
currently running a mainline 4.14 kernel on LS1021A, with a few patches
inspired from the NXP 4.1 branch applied on top - but also with some
manual fixes for e.g. the pvr_version_is() issue. Now we want to move
that to a 4.19-based kernel (so that it aligns with our MPC8309 platform).

>> This is just some first few steps, and I'm not claiming
>> that this is sufficient to make the QE drivers build on ARM yet. But I
>> have a customer with both mpc8309-based and ls1021a-based platforms, and
>> they want to run the same, as-close-to-mainline-as-possible, kernel on
>> both. So I will take a piecemeal approach, and try to make sure I don't
>> break the ppc boards in the process (just building and booting one board
>> is of course not sufficient, but better than nothing). Once I get to
>> actually build some of the QE drivers for ARM, I'll of course also test
>> them.
> 
> Understood.  Zhao Qiang also maintains some patches similar to your
> patchset and I think they are tested on ARM.  But the review of these
> patches from last submission didn't finish.  It looks like your
> patches are better divided but not really verified on ARM.  Zhao
> Qiang's patches are tested but maybe need some final touch for
> cleaning up.  I will let you guys decide what is the best approach to
> make this upstreamed.

Yes, as I said, I wanted to try a fresh approach since Zhao
Qiang's patches seemed to be getting nowhere. Splitting the patches into
smaller pieces is definitely part of that - for example, the completely
trivial whitespace fix in patch 1 is to make sure the later coccinelle
generated patch is precisely that (i.e., a later respin can just rerun
the coccinelle script, with zero manual fixups). I also want to avoid
mixing the ppcism cleanups with other things (e.g. replacing some
of_get_property() by of_property_read_u32()). And the "testing on ARM"
part comes once I get to actually building on ARM. But there's not much
point doing all that unless there's some indication that this can be
applied to some tree that actually feeds into Linus', which is why I
started with a few trivial patches and precisely to start this discussion.

Rasmus

Re: [PATCH v7 1/3] PM: wakeup: Add routine to help fetch wakeup source object.

2019-10-21 Thread Rafael J. Wysocki 
On Mon, Oct 21, 2019 at 5:49 AM Ran Wang  wrote:
>
> Some user might want to go through all registered wakeup sources
> and doing things accordingly. For example, SoC PM driver might need to
> do HW programming to prevent powering down specific IP which wakeup
> source depending on. So add this API to help walk through all registered
> wakeup source objects on that list and return them one by one.
>
> Signed-off-by: Ran Wang 
> Tested-by: Leonard Crestez 
> ---
> Change in v7:
> - Remove define of member *dev in wake_irq to fix conflict with commit
> c8377adfa781 ("PM / wakeup: Show wakeup sources stats in sysfs"), user
> will use ws->dev->parent instead.
> - Remove '#include ' because it is not used.
>
> Change in v6:
> - Add wakeup_source_get_star() and wakeup_source_get_stop() to aligned
> with wakeup_sources_stats_seq_start/nex/stop.
>
> Change in v5:
> - Update commit message, add decription of walk through all wakeup
> source objects.
> - Add SCU protection in function wakeup_source_get_next().
> - Rename wakeup_source member 'attached_dev' to 'dev' and move it up
> (before wakeirq).
>
> Change in v4:
> - None.
>
> Change in v3:
> - Adjust indentation of *attached_dev;.
>
> Change in v2:
> - None.
>
>  drivers/base/power/wakeup.c | 37 +
>  include/linux/pm_wakeup.h   |  3 +++
>  2 files changed, 40 insertions(+)
>
> diff --git a/drivers/base/power/wakeup.c b/drivers/base/power/wakeup.c
> index 5817b51..dee1b09 100644
> --- a/drivers/base/power/wakeup.c
> +++ b/drivers/base/power/wakeup.c
> @@ -248,6 +248,43 @@ void wakeup_source_unregister(struct wakeup_source *ws)
>  EXPORT_SYMBOL_GPL(wakeup_source_unregister);
>
>  /**
> + * wakeup_source_get_star - Begin a walk on wakeup source list

The "get" in the name suggests acquiring a reference of some kind
which doesn't happen here.

What about renaming it to wakeup_sources_walk_start()?

> + * @srcuidx: Lock index allocated for this caller.
> + */
> +struct wakeup_source *wakeup_source_get_start(int *srcuidx)

I don't quite like the calling convention here with passing an int
pointer to get the SRCU index back.

What about splitting this into, say, wakeup_sources_read_lock() (that
will return the SRCU index) and wakeup_sources_walk_start() (that will
return the first list entry)?

Then, you could do something like

idx = wakeup_sources_read_lock();

ws = wakeup_sources_walk_start();
while (ws) {

stuff

ws = wakeup_sources_walk_next();
}

wakeup_sources_read_unlock(idx);

Or even define for_each_wakeup_source(ws) as

for (ws = wakeup_sources_walk_start(); ws; ws = wakeup_sources_walk_next())

and use that under a _read_lock()/_read_unlock() pair?

Re: [PATCH 2/2] virtio_ring: Use DMA API if memory is encrypted

2019-10-21 Thread David Gibson 
On Tue, Oct 15, 2019 at 09:35:01AM +0200, Christoph Hellwig wrote:
> On Fri, Oct 11, 2019 at 06:25:19PM -0700, Ram Pai wrote:
> > From: Thiago Jung Bauermann 
> > 
> > Normally, virtio enables DMA API with VIRTIO_F_IOMMU_PLATFORM, which must
> > be set by both device and guest driver. However, as a hack, when DMA API
> > returns physical addresses, guest driver can use the DMA API; even though
> > device does not set VIRTIO_F_IOMMU_PLATFORM and just uses physical
> > addresses.
> 
> Sorry, but this is a complete bullshit hack.  Driver must always use
> the DMA API if they do DMA, and if virtio devices use physical addresses
> that needs to be returned through the platform firmware interfaces for
> the dma setup.  If you don't do that yet (which based on previous
> informations you don't), you need to fix it, and we can then quirk
> old implementations that already are out in the field.
> 
> In other words: we finally need to fix that virtio mess and not pile
> hacks on top of hacks.

Christoph, if I understand correctly, your objection isn't so much to
the proposed change here of itself, except insofar as it entrenches
virtio's existing code allowing it to either use the DMA api or bypass
it and use physical addresses directly.  Is that right, or have I
missed something?

Where do you envisage the decision to bypass the IOMMU being made?
The virtio spec more or less states that virtio devices use hypervisor
magic to access physical addresses directly, rather than using normal
DMA channels.  The F_IOMMU_PLATFORM flag then overrides that, since it
obviously won't work for hardware devices.

The platform code isn't really in a position to know that virtio
devices are (usually) magic.  So were you envisaging the virtio driver
explicitly telling the platform to use bypassing DMA operations?

-- 
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au  | minimalist, thank you.  NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson


signature.asc
Description: PGP signature

Re: [PATCH v2 3/4] Documentation/ABI: mark /sys/kernel/fadump_* sysfs files deprecated

2019-10-21 Thread Hari Bathini 



On 18/10/19 6:35 PM, Sourabh Jain wrote:
> The /sys/kernel/fadump_* sysfs files are replicated under

[...]

> +Note: The following FADump sysfs files are deprecated.
> +
> +Deprecated   Alternative
> +
> ---
> +/sys/kernel/fadump_enabled   /sys/kernel/fadump/fadump_enabled
> +/sys/kernel/fadump_registered/sys/kernel/fadump/fadump_registered
> +/sys/kernel/fadump_release_mem   
> /sys/kernel/fadump/fadump_release_mem

/sys/kernel/fadump/* looks tidy instead of /sys/kernel/fadump/fadump_* 
I mean, /sys/kernel/fadump/fadump_enabled => /sys/kernel/fadump/enabled and 
such..

- Hari