* Re: [PATCH 0/5] use pinned_vm instead of locked_vm to account pinned pages
From: Jason Gunthorpe @ 2019-02-11 22:54 UTC (permalink / raw)
To: Daniel Jordan
Cc: dave, jack, kvm, atull, aik, linux-fpga, linux-kernel, kvm-ppc,
linux-mm, alex.williamson, mdf, akpm, linuxppc-dev, cl, hao.wu
In-Reply-To: <20190211224437.25267-1-daniel.m.jordan@oracle.com>
On Mon, Feb 11, 2019 at 05:44:32PM -0500, Daniel Jordan wrote:
> Hi,
>
> This series converts users that account pinned pages with locked_vm to
> account with pinned_vm instead, pinned_vm being the correct counter to
> use. It's based on a similar patch I posted recently[0].
>
> The patches are based on rdma/for-next to build on Davidlohr Bueso's
> recent conversion of pinned_vm to an atomic64_t[1]. Seems to make some
> sense for these to be routed the same way, despite lack of rdma content?
Oy.. I'd be willing to accumulate a branch with acks to send to Linus
*separately* from RDMA to Linus, but this is very abnormal.
Better to wait a few weeks for -rc1 and send patches through the
subsystem trees.
> All five of these places, and probably some of Davidlohr's conversions,
> probably want to be collapsed into a common helper in the core mm for
> accounting pinned pages. I tried, and there are several details that
> likely need discussion, so this can be done as a follow-on.
I've wondered the same..
Jason
^ permalink raw reply
* Re: [PATCH 1/5] vfio/type1: use pinned_vm instead of locked_vm to account pinned pages
From: Jason Gunthorpe @ 2019-02-11 22:56 UTC (permalink / raw)
To: Daniel Jordan
Cc: dave, jack, kvm, atull, aik, linux-fpga, linux-kernel, kvm-ppc,
linux-mm, alex.williamson, mdf, akpm, linuxppc-dev, cl, hao.wu
In-Reply-To: <20190211224437.25267-2-daniel.m.jordan@oracle.com>
On Mon, Feb 11, 2019 at 05:44:33PM -0500, Daniel Jordan wrote:
> Beginning with bc3e53f682d9 ("mm: distinguish between mlocked and pinned
> pages"), locked and pinned pages are accounted separately. Type1
> accounts pinned pages to locked_vm; use pinned_vm instead.
>
> pinned_vm recently became atomic and so no longer relies on mmap_sem
> held as writer: delete.
>
> Signed-off-by: Daniel Jordan <daniel.m.jordan@oracle.com>
> drivers/vfio/vfio_iommu_type1.c | 31 ++++++++++++-------------------
> 1 file changed, 12 insertions(+), 19 deletions(-)
>
> diff --git a/drivers/vfio/vfio_iommu_type1.c b/drivers/vfio/vfio_iommu_type1.c
> index 73652e21efec..a56cc341813f 100644
> +++ b/drivers/vfio/vfio_iommu_type1.c
> @@ -257,7 +257,8 @@ static int vfio_iova_put_vfio_pfn(struct vfio_dma *dma, struct vfio_pfn *vpfn)
> static int vfio_lock_acct(struct vfio_dma *dma, long npage, bool async)
> {
> struct mm_struct *mm;
> - int ret;
> + s64 pinned_vm;
> + int ret = 0;
>
> if (!npage)
> return 0;
> @@ -266,24 +267,15 @@ static int vfio_lock_acct(struct vfio_dma *dma, long npage, bool async)
> if (!mm)
> return -ESRCH; /* process exited */
>
> - ret = down_write_killable(&mm->mmap_sem);
> - if (!ret) {
> - if (npage > 0) {
> - if (!dma->lock_cap) {
> - unsigned long limit;
> -
> - limit = task_rlimit(dma->task,
> - RLIMIT_MEMLOCK) >> PAGE_SHIFT;
> + pinned_vm = atomic64_add_return(npage, &mm->pinned_vm);
>
> - if (mm->locked_vm + npage > limit)
> - ret = -ENOMEM;
> - }
> + if (npage > 0 && !dma->lock_cap) {
> + unsigned long limit = task_rlimit(dma->task, RLIMIT_MEMLOCK) >>
> +
> - PAGE_SHIFT;
I haven't looked at this super closely, but how does this stuff work?
do_mlock doesn't touch pinned_vm, and this doesn't touch locked_vm...
Shouldn't all this be 'if (locked_vm + pinned_vm < RLIMIT_MEMLOCK)' ?
Otherwise MEMLOCK is really doubled..
Jason
^ permalink raw reply
* Re: [PATCH 1/5] vfio/type1: use pinned_vm instead of locked_vm to account pinned pages
From: Daniel Jordan @ 2019-02-11 23:11 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: dave, jack, kvm, atull, aik, linux-fpga, linux-kernel, kvm-ppc,
Daniel Jordan, linux-mm, alex.williamson, mdf, akpm, linuxppc-dev,
cl, hao.wu
In-Reply-To: <20190211225620.GO24692@ziepe.ca>
On Mon, Feb 11, 2019 at 03:56:20PM -0700, Jason Gunthorpe wrote:
> On Mon, Feb 11, 2019 at 05:44:33PM -0500, Daniel Jordan wrote:
> > @@ -266,24 +267,15 @@ static int vfio_lock_acct(struct vfio_dma *dma, long npage, bool async)
> > if (!mm)
> > return -ESRCH; /* process exited */
> >
> > - ret = down_write_killable(&mm->mmap_sem);
> > - if (!ret) {
> > - if (npage > 0) {
> > - if (!dma->lock_cap) {
> > - unsigned long limit;
> > -
> > - limit = task_rlimit(dma->task,
> > - RLIMIT_MEMLOCK) >> PAGE_SHIFT;
> > + pinned_vm = atomic64_add_return(npage, &mm->pinned_vm);
> >
> > - if (mm->locked_vm + npage > limit)
> > - ret = -ENOMEM;
> > - }
> > + if (npage > 0 && !dma->lock_cap) {
> > + unsigned long limit = task_rlimit(dma->task, RLIMIT_MEMLOCK) >>
> > +
> > - PAGE_SHIFT;
>
> I haven't looked at this super closely, but how does this stuff work?
>
> do_mlock doesn't touch pinned_vm, and this doesn't touch locked_vm...
>
> Shouldn't all this be 'if (locked_vm + pinned_vm < RLIMIT_MEMLOCK)' ?
>
> Otherwise MEMLOCK is really doubled..
So this has been a problem for some time, but it's not as easy as adding them
together, see [1][2] for a start.
The locked_vm/pinned_vm issue definitely needs fixing, but all this series is
trying to do is account to the right counter.
Daniel
[1] http://lkml.kernel.org/r/20130523104154.GA23650@twins.programming.kicks-ass.net
[2] http://lkml.kernel.org/r/20130524140114.GK23650@twins.programming.kicks-ass.net
^ permalink raw reply
* Re: [PATCH 0/5] use pinned_vm instead of locked_vm to account pinned pages
From: Daniel Jordan @ 2019-02-11 23:15 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: dave, jack, kvm, atull, aik, linux-fpga, linux-kernel, kvm-ppc,
Daniel Jordan, linux-mm, alex.williamson, mdf, akpm, linuxppc-dev,
cl, hao.wu
In-Reply-To: <20190211225447.GN24692@ziepe.ca>
On Mon, Feb 11, 2019 at 03:54:47PM -0700, Jason Gunthorpe wrote:
> On Mon, Feb 11, 2019 at 05:44:32PM -0500, Daniel Jordan wrote:
> > Hi,
> >
> > This series converts users that account pinned pages with locked_vm to
> > account with pinned_vm instead, pinned_vm being the correct counter to
> > use. It's based on a similar patch I posted recently[0].
> >
> > The patches are based on rdma/for-next to build on Davidlohr Bueso's
> > recent conversion of pinned_vm to an atomic64_t[1]. Seems to make some
> > sense for these to be routed the same way, despite lack of rdma content?
>
> Oy.. I'd be willing to accumulate a branch with acks to send to Linus
> *separately* from RDMA to Linus, but this is very abnormal.
>
> Better to wait a few weeks for -rc1 and send patches through the
> subsystem trees.
Ok, I can do that. It did seem strange, so I made it a question...
^ permalink raw reply
* Re: [PATCH] powerpc/configs: Enable CONFIG_USB_XHCI_HCD by default
From: David Gibson @ 2019-02-11 23:31 UTC (permalink / raw)
To: Thomas Huth; +Cc: Laurent Vivier, linuxppc-dev, Paul Mackerras
In-Reply-To: <1549885032-15702-1-git-send-email-thuth@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 1244 bytes --]
On Mon, 11 Feb 2019 12:37:12 +0100
Thomas Huth <thuth@redhat.com> wrote:
> Recent versions of QEMU provide a XHCI device by default these
> days instead of an old-fashioned OHCI device:
>
> https://git.qemu.org/?p=qemu.git;a=commitdiff;h=57040d451315320b7d27
>
> So to get the keyboard working in the graphical console there again,
> we should now include XHCI support in the kernel by default, too.
>
> Signed-off-by: Thomas Huth <thuth@redhat.com>
Wow, we didn't before? That's bonkers.
Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
> ---
> arch/powerpc/configs/pseries_defconfig | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/powerpc/configs/pseries_defconfig b/arch/powerpc/configs/pseries_defconfig
> index ea79c51..62e12f6 100644
> --- a/arch/powerpc/configs/pseries_defconfig
> +++ b/arch/powerpc/configs/pseries_defconfig
> @@ -217,6 +217,7 @@ CONFIG_USB_MON=m
> CONFIG_USB_EHCI_HCD=y
> # CONFIG_USB_EHCI_HCD_PPC_OF is not set
> CONFIG_USB_OHCI_HCD=y
> +CONFIG_USB_XHCI_HCD=y
> CONFIG_USB_STORAGE=m
> CONFIG_NEW_LEDS=y
> CONFIG_LEDS_CLASS=m
> --
> 1.8.3.1
>
--
David Gibson <dgibson@redhat.com>
Principal Software Engineer, Virtualization, Red Hat
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [QUESTION] powerpc, libseccomp, and spu
From: Benjamin Herrenschmidt @ 2019-02-12 0:18 UTC (permalink / raw)
To: Tom Hromatka, linuxppc-dev; +Cc: Paul Moore, Dhaval Giani
In-Reply-To: <df04c747-58c1-4757-b0ef-1ccea745defb@oracle.com>
On Mon, 2019-02-11 at 11:54 -0700, Tom Hromatka wrote:
> PowerPC experts,
>
> Paul Moore and I are working on the v2.4 release of libseccomp,
> and as part of this work I need to update the syscall table for
> each architecture.
>
> I have incorporated the new ppc syscall.tbl into libseccomp, but
> I am not familiar with the value of "spu" in the ABI column. For
> example:
>
> 22 32 umount sys_oldumount
> 22 64 umount sys_ni_syscall
> 22 spu umount sys_ni_syscall
>
> In libseccomp, we maintain a 32-bit ppc syscall table and a 64-bit
> ppc syscall table. Do we also need to add a "spu" ppc syscall
> table? Some clarification on the syscalls marked "spu" and "nospu"
> would be greatly appreciated.
On the Cell processor, there is a number of little co-processors (SPUs)
that run alongside the main PowerPC core. Userspace can run code on
them, they operate within the user context via their own MMUs. We
provide a facility for them to issue syscalls (via some kind of RPC to
the main core). The "SPU" indication indicates syscalls that can be
called from the SPUs via that mechanism.
Now, the big question is, anybody still using Cell ? :-)
Cheers,
Ben.
^ permalink raw reply
* Re: [QUESTION] powerpc, libseccomp, and spu
From: Benjamin Herrenschmidt @ 2019-02-12 0:18 UTC (permalink / raw)
To: Tom Hromatka, linuxppc-dev; +Cc: Paul Moore, Dhaval Giani
In-Reply-To: <df04c747-58c1-4757-b0ef-1ccea745defb@oracle.com>
On Mon, 2019-02-11 at 11:54 -0700, Tom Hromatka wrote:
> PowerPC experts,
>
> Paul Moore and I are working on the v2.4 release of libseccomp,
> and as part of this work I need to update the syscall table for
> each architecture.
>
> I have incorporated the new ppc syscall.tbl into libseccomp, but
> I am not familiar with the value of "spu" in the ABI column. For
> example:
>
> 22 32 umount sys_oldumount
> 22 64 umount sys_ni_syscall
> 22 spu umount sys_ni_syscall
>
> In libseccomp, we maintain a 32-bit ppc syscall table and a 64-bit
> ppc syscall table. Do we also need to add a "spu" ppc syscall
> table? Some clarification on the syscalls marked "spu" and "nospu"
> would be greatly appreciated.
On the Cell processor, there is a number of little co-processors (SPUs)
that run alongside the main PowerPC core. Userspace can run code on
them, they operate within the user context via their own MMUs. We
provide a facility for them to issue syscalls (via some kind of RPC to
the main core). The "SPU" indication indicates syscalls that can be
called from the SPUs via that mechanism.
Now, the big question is, anybody still using Cell ? :-)
Cheers,
Ben.
^ permalink raw reply
* Re: [QUESTION] powerpc, libseccomp, and spu
From: Michael Ellerman @ 2019-02-12 0:36 UTC (permalink / raw)
To: Tom Hromatka, linuxppc-dev
Cc: firoz.khan, Arnd Bergmann, Paul Moore, Dhaval Giani, tom.hromatka
In-Reply-To: <df04c747-58c1-4757-b0ef-1ccea745defb@oracle.com>
Hi Tom,
Sorry this has caused you trouble, using "spu" there is a bit of a hack
and I want to remove it.
See: https://patchwork.ozlabs.org/patch/1025830/
Unfortunately that series clashed with some of Arnd's work and I haven't
got around to rebasing it.
Tom Hromatka <tom.hromatka@oracle.com> writes:
> PowerPC experts,
>
> Paul Moore and I are working on the v2.4 release of libseccomp,
> and as part of this work I need to update the syscall table for
> each architecture.
>
> I have incorporated the new ppc syscall.tbl into libseccomp, but
> I am not familiar with the value of "spu" in the ABI column. For
> example:
>
> 22 32 umount sys_oldumount
> 22 64 umount sys_ni_syscall
> 22 spu umount sys_ni_syscall
>
> In libseccomp, we maintain a 32-bit ppc syscall table and a 64-bit
> ppc syscall table. Do we also need to add a "spu" ppc syscall
> table? Some clarification on the syscalls marked "spu" and "nospu"
> would be greatly appreciated.
The name "spu" comes from SPU, which are the small cores in the
Playstation 3. The value in the syscall table says whether that syscall
is available to SPU programs ("spu") or blocked ("nospu"). I don't think
you want to support libseccomp on SPUs, so basically you can just ignore
the spu/nospu distinction.
So I'm pretty sure you can just remove all the "spu" lines, and then
replace "nospu" with "common". As I've done below.
I'll try and get my patch above into a branch and into linux-next
somehow, so that you can at least refer to an upstream commit.
cheers
# SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note
#
# system call numbers and entry vectors for powerpc
#
# The format is:
# <number> <abi> <name> <entry point> <compat entry point>
#
# The <abi> can be common, 64, or 32 for this file.
#
0 common restart_syscall sys_restart_syscall
1 common exit sys_exit
2 common fork ppc_fork
3 common read sys_read
4 common write sys_write
5 common open sys_open compat_sys_open
6 common close sys_close
7 common waitpid sys_waitpid
8 common creat sys_creat
9 common link sys_link
10 common unlink sys_unlink
11 common execve sys_execve compat_sys_execve
12 common chdir sys_chdir
13 common time sys_time compat_sys_time
14 common mknod sys_mknod
15 common chmod sys_chmod
16 common lchown sys_lchown
17 common break sys_ni_syscall
18 32 oldstat sys_stat sys_ni_syscall
18 64 oldstat sys_ni_syscall
19 common lseek sys_lseek compat_sys_lseek
20 common getpid sys_getpid
21 common mount sys_mount compat_sys_mount
22 32 umount sys_oldumount
22 64 umount sys_ni_syscall
23 common setuid sys_setuid
24 common getuid sys_getuid
25 common stime sys_stime compat_sys_stime
26 common ptrace sys_ptrace compat_sys_ptrace
27 common alarm sys_alarm
28 32 oldfstat sys_fstat sys_ni_syscall
28 64 oldfstat sys_ni_syscall
29 common pause sys_pause
30 common utime sys_utime compat_sys_utime
31 common stty sys_ni_syscall
32 common gtty sys_ni_syscall
33 common access sys_access
34 common nice sys_nice
35 common ftime sys_ni_syscall
36 common sync sys_sync
37 common kill sys_kill
38 common rename sys_rename
39 common mkdir sys_mkdir
40 common rmdir sys_rmdir
41 common dup sys_dup
42 common pipe sys_pipe
43 common times sys_times compat_sys_times
44 common prof sys_ni_syscall
45 common brk sys_brk
46 common setgid sys_setgid
47 common getgid sys_getgid
48 common signal sys_signal
49 common geteuid sys_geteuid
50 common getegid sys_getegid
51 common acct sys_acct
52 common umount2 sys_umount
53 common lock sys_ni_syscall
54 common ioctl sys_ioctl compat_sys_ioctl
55 common fcntl sys_fcntl compat_sys_fcntl
56 common mpx sys_ni_syscall
57 common setpgid sys_setpgid
58 common ulimit sys_ni_syscall
59 32 oldolduname sys_olduname
59 64 oldolduname sys_ni_syscall
60 common umask sys_umask
61 common chroot sys_chroot
62 common ustat sys_ustat compat_sys_ustat
63 common dup2 sys_dup2
64 common getppid sys_getppid
65 common getpgrp sys_getpgrp
66 common setsid sys_setsid
67 32 sigaction sys_sigaction compat_sys_sigaction
67 64 sigaction sys_ni_syscall
68 common sgetmask sys_sgetmask
69 common ssetmask sys_ssetmask
70 common setreuid sys_setreuid
71 common setregid sys_setregid
72 32 sigsuspend sys_sigsuspend
72 64 sigsuspend sys_ni_syscall
73 32 sigpending sys_sigpending compat_sys_sigpending
73 64 sigpending sys_ni_syscall
74 common sethostname sys_sethostname
75 common setrlimit sys_setrlimit compat_sys_setrlimit
76 32 getrlimit sys_old_getrlimit compat_sys_old_getrlimit
76 64 getrlimit sys_ni_syscall
77 common getrusage sys_getrusage compat_sys_getrusage
78 common gettimeofday sys_gettimeofday compat_sys_gettimeofday
79 common settimeofday sys_settimeofday compat_sys_settimeofday
80 common getgroups sys_getgroups
81 common setgroups sys_setgroups
82 32 select ppc_select sys_ni_syscall
82 64 select sys_ni_syscall
83 common symlink sys_symlink
84 32 oldlstat sys_lstat sys_ni_syscall
84 64 oldlstat sys_ni_syscall
85 common readlink sys_readlink
86 common uselib sys_uselib
87 common swapon sys_swapon
88 common reboot sys_reboot
89 32 readdir sys_old_readdir compat_sys_old_readdir
89 64 readdir sys_ni_syscall
90 common mmap sys_mmap
91 common munmap sys_munmap
92 common truncate sys_truncate compat_sys_truncate
93 common ftruncate sys_ftruncate compat_sys_ftruncate
94 common fchmod sys_fchmod
95 common fchown sys_fchown
96 common getpriority sys_getpriority
97 common setpriority sys_setpriority
98 common profil sys_ni_syscall
99 common statfs sys_statfs compat_sys_statfs
100 common fstatfs sys_fstatfs compat_sys_fstatfs
101 common ioperm sys_ni_syscall
102 common socketcall sys_socketcall compat_sys_socketcall
103 common syslog sys_syslog
104 common setitimer sys_setitimer compat_sys_setitimer
105 common getitimer sys_getitimer compat_sys_getitimer
106 common stat sys_newstat compat_sys_newstat
107 common lstat sys_newlstat compat_sys_newlstat
108 common fstat sys_newfstat compat_sys_newfstat
109 32 olduname sys_uname
109 64 olduname sys_ni_syscall
110 common iopl sys_ni_syscall
111 common vhangup sys_vhangup
112 common idle sys_ni_syscall
113 common vm86 sys_ni_syscall
114 common wait4 sys_wait4 compat_sys_wait4
115 common swapoff sys_swapoff
116 common sysinfo sys_sysinfo compat_sys_sysinfo
117 common ipc sys_ipc compat_sys_ipc
118 common fsync sys_fsync
119 32 sigreturn sys_sigreturn compat_sys_sigreturn
119 64 sigreturn sys_ni_syscall
120 common clone ppc_clone
121 common setdomainname sys_setdomainname
122 common uname sys_newuname
123 common modify_ldt sys_ni_syscall
124 common adjtimex sys_adjtimex compat_sys_adjtimex
125 common mprotect sys_mprotect
126 32 sigprocmask sys_sigprocmask compat_sys_sigprocmask
126 64 sigprocmask sys_ni_syscall
127 common create_module sys_ni_syscall
128 common init_module sys_init_module
129 common delete_module sys_delete_module
130 common get_kernel_syms sys_ni_syscall
131 common quotactl sys_quotactl
132 common getpgid sys_getpgid
133 common fchdir sys_fchdir
134 common bdflush sys_bdflush
135 common sysfs sys_sysfs
136 32 personality sys_personality ppc64_personality
136 64 personality ppc64_personality
137 common afs_syscall sys_ni_syscall
138 common setfsuid sys_setfsuid
139 common setfsgid sys_setfsgid
140 common _llseek sys_llseek
141 common getdents sys_getdents compat_sys_getdents
142 common _newselect sys_select compat_sys_select
143 common flock sys_flock
144 common msync sys_msync
145 common readv sys_readv compat_sys_readv
146 common writev sys_writev compat_sys_writev
147 common getsid sys_getsid
148 common fdatasync sys_fdatasync
149 common _sysctl sys_sysctl compat_sys_sysctl
150 common mlock sys_mlock
151 common munlock sys_munlock
152 common mlockall sys_mlockall
153 common munlockall sys_munlockall
154 common sched_setparam sys_sched_setparam
155 common sched_getparam sys_sched_getparam
156 common sched_setscheduler sys_sched_setscheduler
157 common sched_getscheduler sys_sched_getscheduler
158 common sched_yield sys_sched_yield
159 common sched_get_priority_max sys_sched_get_priority_max
160 common sched_get_priority_min sys_sched_get_priority_min
161 common sched_rr_get_interval sys_sched_rr_get_interval compat_sys_sched_rr_get_interval
162 common nanosleep sys_nanosleep compat_sys_nanosleep
163 common mremap sys_mremap
164 common setresuid sys_setresuid
165 common getresuid sys_getresuid
166 common query_module sys_ni_syscall
167 common poll sys_poll
168 common nfsservctl sys_ni_syscall
169 common setresgid sys_setresgid
170 common getresgid sys_getresgid
171 common prctl sys_prctl
172 common rt_sigreturn sys_rt_sigreturn compat_sys_rt_sigreturn
173 common rt_sigaction sys_rt_sigaction compat_sys_rt_sigaction
174 common rt_sigprocmask sys_rt_sigprocmask compat_sys_rt_sigprocmask
175 common rt_sigpending sys_rt_sigpending compat_sys_rt_sigpending
176 common rt_sigtimedwait sys_rt_sigtimedwait compat_sys_rt_sigtimedwait
177 common rt_sigqueueinfo sys_rt_sigqueueinfo compat_sys_rt_sigqueueinfo
178 common rt_sigsuspend sys_rt_sigsuspend compat_sys_rt_sigsuspend
179 common pread64 sys_pread64 compat_sys_pread64
180 common pwrite64 sys_pwrite64 compat_sys_pwrite64
181 common chown sys_chown
182 common getcwd sys_getcwd
183 common capget sys_capget
184 common capset sys_capset
185 common sigaltstack sys_sigaltstack compat_sys_sigaltstack
186 32 sendfile sys_sendfile compat_sys_sendfile
186 64 sendfile sys_sendfile64
187 common getpmsg sys_ni_syscall
188 common putpmsg sys_ni_syscall
189 common vfork ppc_vfork
190 common ugetrlimit sys_getrlimit compat_sys_getrlimit
191 common readahead sys_readahead compat_sys_readahead
192 32 mmap2 sys_mmap2 compat_sys_mmap2
193 32 truncate64 sys_truncate64 compat_sys_truncate64
194 32 ftruncate64 sys_ftruncate64 compat_sys_ftruncate64
195 32 stat64 sys_stat64
196 32 lstat64 sys_lstat64
197 32 fstat64 sys_fstat64
198 common pciconfig_read sys_pciconfig_read
199 common pciconfig_write sys_pciconfig_write
200 common pciconfig_iobase sys_pciconfig_iobase
201 common multiplexer sys_ni_syscall
202 common getdents64 sys_getdents64
203 common pivot_root sys_pivot_root
204 32 fcntl64 sys_fcntl64 compat_sys_fcntl64
205 common madvise sys_madvise
206 common mincore sys_mincore
207 common gettid sys_gettid
208 common tkill sys_tkill
209 common setxattr sys_setxattr
210 common lsetxattr sys_lsetxattr
211 common fsetxattr sys_fsetxattr
212 common getxattr sys_getxattr
213 common lgetxattr sys_lgetxattr
214 common fgetxattr sys_fgetxattr
215 common listxattr sys_listxattr
216 common llistxattr sys_llistxattr
217 common flistxattr sys_flistxattr
218 common removexattr sys_removexattr
219 common lremovexattr sys_lremovexattr
220 common fremovexattr sys_fremovexattr
221 common futex sys_futex compat_sys_futex
222 common sched_setaffinity sys_sched_setaffinity compat_sys_sched_setaffinity
223 common sched_getaffinity sys_sched_getaffinity compat_sys_sched_getaffinity
# 224 unused
225 common tuxcall sys_ni_syscall
226 32 sendfile64 sys_sendfile64 compat_sys_sendfile64
227 common io_setup sys_io_setup compat_sys_io_setup
228 common io_destroy sys_io_destroy
229 common io_getevents sys_io_getevents compat_sys_io_getevents
230 common io_submit sys_io_submit compat_sys_io_submit
231 common io_cancel sys_io_cancel
232 common set_tid_address sys_set_tid_address
233 common fadvise64 sys_fadvise64 ppc32_fadvise64
234 common exit_group sys_exit_group
235 common lookup_dcookie sys_lookup_dcookie compat_sys_lookup_dcookie
236 common epoll_create sys_epoll_create
237 common epoll_ctl sys_epoll_ctl
238 common epoll_wait sys_epoll_wait
239 common remap_file_pages sys_remap_file_pages
240 common timer_create sys_timer_create compat_sys_timer_create
241 common timer_settime sys_timer_settime compat_sys_timer_settime
242 common timer_gettime sys_timer_gettime compat_sys_timer_gettime
243 common timer_getoverrun sys_timer_getoverrun
244 common timer_delete sys_timer_delete
245 common clock_settime sys_clock_settime compat_sys_clock_settime
246 common clock_gettime sys_clock_gettime compat_sys_clock_gettime
247 common clock_getres sys_clock_getres compat_sys_clock_getres
248 common clock_nanosleep sys_clock_nanosleep compat_sys_clock_nanosleep
249 32 swapcontext ppc_swapcontext ppc32_swapcontext
249 64 swapcontext ppc64_swapcontext
250 common tgkill sys_tgkill
251 common utimes sys_utimes compat_sys_utimes
252 common statfs64 sys_statfs64 compat_sys_statfs64
253 common fstatfs64 sys_fstatfs64 compat_sys_fstatfs64
254 32 fadvise64_64 ppc_fadvise64_64
255 common rtas sys_rtas
256 32 sys_debug_setcontext sys_debug_setcontext sys_ni_syscall
256 64 sys_debug_setcontext sys_ni_syscall
# 257 reserved for vserver
258 common migrate_pages sys_migrate_pages compat_sys_migrate_pages
259 common mbind sys_mbind compat_sys_mbind
260 common get_mempolicy sys_get_mempolicy compat_sys_get_mempolicy
261 common set_mempolicy sys_set_mempolicy compat_sys_set_mempolicy
262 common mq_open sys_mq_open compat_sys_mq_open
263 common mq_unlink sys_mq_unlink
264 common mq_timedsend sys_mq_timedsend compat_sys_mq_timedsend
265 common mq_timedreceive sys_mq_timedreceive compat_sys_mq_timedreceive
266 common mq_notify sys_mq_notify compat_sys_mq_notify
267 common mq_getsetattr sys_mq_getsetattr compat_sys_mq_getsetattr
268 common kexec_load sys_kexec_load compat_sys_kexec_load
269 common add_key sys_add_key
270 common request_key sys_request_key
271 common keyctl sys_keyctl compat_sys_keyctl
272 common waitid sys_waitid compat_sys_waitid
273 common ioprio_set sys_ioprio_set
274 common ioprio_get sys_ioprio_get
275 common inotify_init sys_inotify_init
276 common inotify_add_watch sys_inotify_add_watch
277 common inotify_rm_watch sys_inotify_rm_watch
278 common spu_run sys_spu_run
279 common spu_create sys_spu_create
280 common pselect6 sys_pselect6 compat_sys_pselect6
281 common ppoll sys_ppoll compat_sys_ppoll
282 common unshare sys_unshare
283 common splice sys_splice
284 common tee sys_tee
285 common vmsplice sys_vmsplice compat_sys_vmsplice
286 common openat sys_openat compat_sys_openat
287 common mkdirat sys_mkdirat
288 common mknodat sys_mknodat
289 common fchownat sys_fchownat
290 common futimesat sys_futimesat compat_sys_futimesat
291 32 fstatat64 sys_fstatat64
291 64 newfstatat sys_newfstatat
292 common unlinkat sys_unlinkat
293 common renameat sys_renameat
294 common linkat sys_linkat
295 common symlinkat sys_symlinkat
296 common readlinkat sys_readlinkat
297 common fchmodat sys_fchmodat
298 common faccessat sys_faccessat
299 common get_robust_list sys_get_robust_list compat_sys_get_robust_list
300 common set_robust_list sys_set_robust_list compat_sys_set_robust_list
301 common move_pages sys_move_pages compat_sys_move_pages
302 common getcpu sys_getcpu
303 common epoll_pwait sys_epoll_pwait compat_sys_epoll_pwait
304 common utimensat sys_utimensat compat_sys_utimensat
305 common signalfd sys_signalfd compat_sys_signalfd
306 common timerfd_create sys_timerfd_create
307 common eventfd sys_eventfd
308 common sync_file_range2 sys_sync_file_range2 compat_sys_sync_file_range2
309 common fallocate sys_fallocate compat_sys_fallocate
310 common subpage_prot sys_subpage_prot
311 common timerfd_settime sys_timerfd_settime compat_sys_timerfd_settime
312 common timerfd_gettime sys_timerfd_gettime compat_sys_timerfd_gettime
313 common signalfd4 sys_signalfd4 compat_sys_signalfd4
314 common eventfd2 sys_eventfd2
315 common epoll_create1 sys_epoll_create1
316 common dup3 sys_dup3
317 common pipe2 sys_pipe2
318 common inotify_init1 sys_inotify_init1
319 common perf_event_open sys_perf_event_open
320 common preadv sys_preadv compat_sys_preadv
321 common pwritev sys_pwritev compat_sys_pwritev
322 common rt_tgsigqueueinfo sys_rt_tgsigqueueinfo compat_sys_rt_tgsigqueueinfo
323 common fanotify_init sys_fanotify_init
324 common fanotify_mark sys_fanotify_mark compat_sys_fanotify_mark
325 common prlimit64 sys_prlimit64
326 common socket sys_socket
327 common bind sys_bind
328 common connect sys_connect
329 common listen sys_listen
330 common accept sys_accept
331 common getsockname sys_getsockname
332 common getpeername sys_getpeername
333 common socketpair sys_socketpair
334 common send sys_send
335 common sendto sys_sendto
336 common recv sys_recv compat_sys_recv
337 common recvfrom sys_recvfrom compat_sys_recvfrom
338 common shutdown sys_shutdown
339 common setsockopt sys_setsockopt compat_sys_setsockopt
340 common getsockopt sys_getsockopt compat_sys_getsockopt
341 common sendmsg sys_sendmsg compat_sys_sendmsg
342 common recvmsg sys_recvmsg compat_sys_recvmsg
343 common recvmmsg sys_recvmmsg compat_sys_recvmmsg
344 common accept4 sys_accept4
345 common name_to_handle_at sys_name_to_handle_at
346 common open_by_handle_at sys_open_by_handle_at compat_sys_open_by_handle_at
347 common clock_adjtime sys_clock_adjtime compat_sys_clock_adjtime
348 common syncfs sys_syncfs
349 common sendmmsg sys_sendmmsg compat_sys_sendmmsg
350 common setns sys_setns
351 common process_vm_readv sys_process_vm_readv compat_sys_process_vm_readv
352 common process_vm_writev sys_process_vm_writev compat_sys_process_vm_writev
353 common finit_module sys_finit_module
354 common kcmp sys_kcmp
355 common sched_setattr sys_sched_setattr
356 common sched_getattr sys_sched_getattr
357 common renameat2 sys_renameat2
358 common seccomp sys_seccomp
359 common getrandom sys_getrandom
360 common memfd_create sys_memfd_create
361 common bpf sys_bpf
362 common execveat sys_execveat compat_sys_execveat
363 32 switch_endian sys_ni_syscall
363 64 switch_endian ppc_switch_endian
364 common userfaultfd sys_userfaultfd
365 common membarrier sys_membarrier
378 common mlock2 sys_mlock2
379 common copy_file_range sys_copy_file_range
380 common preadv2 sys_preadv2 compat_sys_preadv2
381 common pwritev2 sys_pwritev2 compat_sys_pwritev2
382 common kexec_file_load sys_kexec_file_load
383 common statx sys_statx
384 common pkey_alloc sys_pkey_alloc
385 common pkey_free sys_pkey_free
386 common pkey_mprotect sys_pkey_mprotect
387 common rseq sys_rseq
388 common io_pgetevents sys_io_pgetevents compat_sys_io_pgetevents
^ permalink raw reply
* [PATCH] powerpc/powernv: Don't reprogram SLW image on every KVM guest entry/exit
From: Paul Mackerras @ 2019-02-12 0:58 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Michael Ellerman, Gautham R. Shenoy
Commit 24be85a23d1f ("powerpc/powernv: Clear PECE1 in LPCR via stop-api
only on Hotplug", 2017-07-21) added two calls to opal_slw_set_reg()
inside pnv_cpu_offline(), with the aim of changing the LPCR value in
the SLW image to disable wakeups from the decrementer while a CPU is
offline. However, pnv_cpu_offline() gets called each time a secondary
CPU thread is woken up to participate in running a KVM guest, that is,
not just when a CPU is offlined.
Since opal_slw_set_reg() is a very slow operation (with observed
execution times around 20 milliseconds), this means that an offline
secondary CPU can often be busy doing the opal_slw_set_reg() call
when the primary CPU wants to grab all the secondary threads so that
it can run a KVM guest. This leads to messages like "KVM: couldn't
grab CPU n" being printed and guest execution failing.
There is no need to reprogram the SLW image on every KVM guest entry
and exit. So that we do it only when a CPU is really transitioning
between online and offline, this moves the calls to
pnv_program_cpu_hotplug_lpcr() into pnv_smp_cpu_kill_self().
Fixes: 24be85a23d1f ("powerpc/powernv: Clear PECE1 in LPCR via stop-api only on Hotplug")
Cc: stable@vger.kernel.org # v4.14+
Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
---
arch/powerpc/include/asm/powernv.h | 2 ++
arch/powerpc/platforms/powernv/idle.c | 27 ++-------------------------
arch/powerpc/platforms/powernv/smp.c | 25 +++++++++++++++++++++++++
3 files changed, 29 insertions(+), 25 deletions(-)
diff --git a/arch/powerpc/include/asm/powernv.h b/arch/powerpc/include/asm/powernv.h
index 2f3ff7a27881..d85fcfea32ca 100644
--- a/arch/powerpc/include/asm/powernv.h
+++ b/arch/powerpc/include/asm/powernv.h
@@ -23,6 +23,8 @@ extern int pnv_npu2_handle_fault(struct npu_context *context, uintptr_t *ea,
unsigned long *flags, unsigned long *status,
int count);
+void pnv_program_cpu_hotplug_lpcr(unsigned int cpu, u64 lpcr_val);
+
void pnv_tm_init(void);
#else
static inline void powernv_set_nmmu_ptcr(unsigned long ptcr) { }
diff --git a/arch/powerpc/platforms/powernv/idle.c b/arch/powerpc/platforms/powernv/idle.c
index 35f699ebb662..e52f9b06dd9c 100644
--- a/arch/powerpc/platforms/powernv/idle.c
+++ b/arch/powerpc/platforms/powernv/idle.c
@@ -458,7 +458,8 @@ EXPORT_SYMBOL_GPL(pnv_power9_force_smt4_release);
#endif /* CONFIG_KVM_BOOK3S_HV_POSSIBLE */
#ifdef CONFIG_HOTPLUG_CPU
-static void pnv_program_cpu_hotplug_lpcr(unsigned int cpu, u64 lpcr_val)
+
+void pnv_program_cpu_hotplug_lpcr(unsigned int cpu, u64 lpcr_val)
{
u64 pir = get_hard_smp_processor_id(cpu);
@@ -481,20 +482,6 @@ unsigned long pnv_cpu_offline(unsigned int cpu)
{
unsigned long srr1;
u32 idle_states = pnv_get_supported_cpuidle_states();
- u64 lpcr_val;
-
- /*
- * We don't want to take decrementer interrupts while we are
- * offline, so clear LPCR:PECE1. We keep PECE2 (and
- * LPCR_PECE_HVEE on P9) enabled as to let IPIs in.
- *
- * If the CPU gets woken up by a special wakeup, ensure that
- * the SLW engine sets LPCR with decrementer bit cleared, else
- * the CPU will come back to the kernel due to a spurious
- * wakeup.
- */
- lpcr_val = mfspr(SPRN_LPCR) & ~(u64)LPCR_PECE1;
- pnv_program_cpu_hotplug_lpcr(cpu, lpcr_val);
__ppc64_runlatch_off();
@@ -526,16 +513,6 @@ unsigned long pnv_cpu_offline(unsigned int cpu)
__ppc64_runlatch_on();
- /*
- * Re-enable decrementer interrupts in LPCR.
- *
- * Further, we want stop states to be woken up by decrementer
- * for non-hotplug cases. So program the LPCR via stop api as
- * well.
- */
- lpcr_val = mfspr(SPRN_LPCR) | (u64)LPCR_PECE1;
- pnv_program_cpu_hotplug_lpcr(cpu, lpcr_val);
-
return srr1;
}
#endif
diff --git a/arch/powerpc/platforms/powernv/smp.c b/arch/powerpc/platforms/powernv/smp.c
index 0d354e19ef92..db09c7022635 100644
--- a/arch/powerpc/platforms/powernv/smp.c
+++ b/arch/powerpc/platforms/powernv/smp.c
@@ -39,6 +39,7 @@
#include <asm/cpuidle.h>
#include <asm/kexec.h>
#include <asm/reg.h>
+#include <asm/powernv.h>
#include "powernv.h"
@@ -153,6 +154,7 @@ static void pnv_smp_cpu_kill_self(void)
{
unsigned int cpu;
unsigned long srr1, wmask;
+ u64 lpcr_val;
/* Standard hot unplug procedure */
/*
@@ -174,6 +176,19 @@ static void pnv_smp_cpu_kill_self(void)
if (cpu_has_feature(CPU_FTR_ARCH_207S))
wmask = SRR1_WAKEMASK_P8;
+ /*
+ * We don't want to take decrementer interrupts while we are
+ * offline, so clear LPCR:PECE1. We keep PECE2 (and
+ * LPCR_PECE_HVEE on P9) enabled so as to let IPIs in.
+ *
+ * If the CPU gets woken up by a special wakeup, ensure that
+ * the SLW engine sets LPCR with decrementer bit cleared, else
+ * the CPU will come back to the kernel due to a spurious
+ * wakeup.
+ */
+ lpcr_val = mfspr(SPRN_LPCR) & ~(u64)LPCR_PECE1;
+ pnv_program_cpu_hotplug_lpcr(cpu, lpcr_val);
+
while (!generic_check_cpu_restart(cpu)) {
/*
* Clear IPI flag, since we don't handle IPIs while
@@ -246,6 +261,16 @@ static void pnv_smp_cpu_kill_self(void)
}
+ /*
+ * Re-enable decrementer interrupts in LPCR.
+ *
+ * Further, we want stop states to be woken up by decrementer
+ * for non-hotplug cases. So program the LPCR via stop api as
+ * well.
+ */
+ lpcr_val = mfspr(SPRN_LPCR) | (u64)LPCR_PECE1;
+ pnv_program_cpu_hotplug_lpcr(cpu, lpcr_val);
+
DBG("CPU%d coming online...\n", cpu);
}
--
2.11.0
^ permalink raw reply related
* Re: [PATCH v4 3/3] powerpc/32: Add KASAN support
From: Daniel Axtens @ 2019-02-12 1:08 UTC (permalink / raw)
To: Andrey Ryabinin, Andrey Konovalov, christophe leroy
Cc: LKML, Nicholas Piggin, Linux Memory Management List,
Alexander Potapenko, Aneesh Kumar K.V, Paul Mackerras, kasan-dev,
PowerPC, Dmitry Vyukov
In-Reply-To: <805fbf9d-a10f-03e0-aa52-6f6bd16059b9@virtuozzo.com>
Andrey Ryabinin <aryabinin@virtuozzo.com> writes:
> On 2/11/19 3:25 PM, Andrey Konovalov wrote:
>> On Sat, Feb 9, 2019 at 12:55 PM christophe leroy
>> <christophe.leroy@c-s.fr> wrote:
>>>
>>> Hi Andrey,
>>>
>>> Le 08/02/2019 à 18:40, Andrey Konovalov a écrit :
>>>> On Fri, Feb 8, 2019 at 6:17 PM Christophe Leroy <christophe.leroy@c-s.fr> wrote:
>>>>>
>>>>> Hi Daniel,
>>>>>
>>>>> Le 08/02/2019 à 17:18, Daniel Axtens a écrit :
>>>>>> Hi Christophe,
>>>>>>
>>>>>> I've been attempting to port this to 64-bit Book3e nohash (e6500),
>>>>>> although I think I've ended up with an approach more similar to Aneesh's
>>>>>> much earlier (2015) series for book3s.
>>>>>>
>>>>>> Part of this is just due to the changes between 32 and 64 bits - we need
>>>>>> to hack around the discontiguous mappings - but one thing that I'm
>>>>>> particularly puzzled by is what the kasan_early_init is supposed to do.
>>>>>
>>>>> It should be a problem as my patch uses a 'for_each_memblock(memory,
>>>>> reg)' loop.
>>>>>
>>>>>>
>>>>>>> +void __init kasan_early_init(void)
>>>>>>> +{
>>>>>>> + unsigned long addr = KASAN_SHADOW_START;
>>>>>>> + unsigned long end = KASAN_SHADOW_END;
>>>>>>> + unsigned long next;
>>>>>>> + pmd_t *pmd = pmd_offset(pud_offset(pgd_offset_k(addr), addr), addr);
>>>>>>> + int i;
>>>>>>> + phys_addr_t pa = __pa(kasan_early_shadow_page);
>>>>>>> +
>>>>>>> + BUILD_BUG_ON(KASAN_SHADOW_START & ~PGDIR_MASK);
>>>>>>> +
>>>>>>> + if (early_mmu_has_feature(MMU_FTR_HPTE_TABLE))
>>>>>>> + panic("KASAN not supported with Hash MMU\n");
>>>>>>> +
>>>>>>> + for (i = 0; i < PTRS_PER_PTE; i++)
>>>>>>> + __set_pte_at(&init_mm, (unsigned long)kasan_early_shadow_page,
>>>>>>> + kasan_early_shadow_pte + i,
>>>>>>> + pfn_pte(PHYS_PFN(pa), PAGE_KERNEL_RO), 0);
>>>>>>> +
>>>>>>> + do {
>>>>>>> + next = pgd_addr_end(addr, end);
>>>>>>> + pmd_populate_kernel(&init_mm, pmd, kasan_early_shadow_pte);
>>>>>>> + } while (pmd++, addr = next, addr != end);
>>>>>>> +}
>>>>>>
>>>>>> As far as I can tell it's mapping the early shadow page, read-only, over
>>>>>> the KASAN_SHADOW_START->KASAN_SHADOW_END range, and it's using the early
>>>>>> shadow PTE array from the generic code.
>>>>>>
>>>>>> I haven't been able to find an answer to why this is in the docs, so I
>>>>>> was wondering if you or anyone else could explain the early part of
>>>>>> kasan init a bit better.
>>>>>
>>>>> See https://www.kernel.org/doc/html/latest/dev-tools/kasan.html for an
>>>>> explanation of the shadow.
>>>>>
>>>>> When shadow is 0, it means the memory area is entirely accessible.
>>>>>
>>>>> It is necessary to setup a shadow area as soon as possible because all
>>>>> data accesses check the shadow area, from the begining (except for a few
>>>>> files where sanitizing has been disabled in Makefiles).
>>>>>
>>>>> Until the real shadow area is set, all access are granted thanks to the
>>>>> zero shadow area beeing for of zeros.
>>>>
>>>> Not entirely correct. kasan_early_init() indeed maps the whole shadow
>>>> memory range to the same kasan_early_shadow_page. However as kernel
>>>> loads and memory gets allocated this shadow page gets rewritten with
>>>> non-zero values by different KASAN allocator hooks. Since these values
>>>> come from completely different parts of the kernel, but all land on
>>>> the same page, kasan_early_shadow_page's content can be considered
>>>> garbage. When KASAN checks memory accesses for validity it detects
>>>> these garbage shadow values, but doesn't print any reports, as the
>>>> reporting routine bails out on the current->kasan_depth check (which
>>>> has the value of 1 initially). Only after kasan_init() completes, when
>>>> the proper shadow memory is mapped, current->kasan_depth gets set to 0
>>>> and we start reporting bad accesses.
>>>
>>> That's surprising, because in the early phase I map the shadow area
>>> read-only, so I do not expect it to get modified unless RO protection is
>>> failing for some reason.
>>
>> Actually it might be that the allocator hooks don't modify shadow at
>> this point, as the allocator is not yet initialized. However stack
>> should be getting poisoned and unpoisoned from the very start. But the
>> generic statement that early shadow gets dirtied should be correct.
>> Might it be that you don't use stack instrumentation?
>>
>
> Yes, stack instrumentation is not used here, because shadow offset which we pass to
> the -fasan-shadow-offset= cflag is not specified here. So the logic in scrpits/Makefile.kasan
> just fallbacks to CFLAGS_KASAN_MINIMAL, which is outline and without stack instrumentation.
>
> Christophe, you can specify KASAN_SHADOW_OFFSET either in Kconfig (e.g. x86_64) or
> in Makefile (e.g. arm64). And make early mapping writable, because compiler generated code will write
> to shadow memory in function prologue/epilogue.
Hmm. Is this limitation just that compilers have not implemented
out-of-line support for stack instrumentation, or is there a deeper
reason that stack/global instrumentation relies upon inline
instrumentation?
I ask because it's very common on ppc64 to have the virtual address
space split up into discontiguous blocks. I know this means we lose
inline instrumentation, but I didn't realise we'd also lose stack and
global instrumentation...
I wonder if it would be worth, in the distant future, trying to
implement a smarter scheme in compilers where we could insert more
complex inline mapping schemes.
Regards,
Daniel
^ permalink raw reply
* Re: [PATCH] powerpc/configs: Enable CONFIG_USB_XHCI_HCD by default
From: Joel Stanley @ 2019-02-12 1:36 UTC (permalink / raw)
To: Thomas Huth; +Cc: Laurent Vivier, Paul Mackerras, linuxppc-dev, David Gibson
In-Reply-To: <1549885032-15702-1-git-send-email-thuth@redhat.com>
On Mon, 11 Feb 2019 at 22:07, Thomas Huth <thuth@redhat.com> wrote:
>
> Recent versions of QEMU provide a XHCI device by default these
> days instead of an old-fashioned OHCI device:
>
> https://git.qemu.org/?p=qemu.git;a=commitdiff;h=57040d451315320b7d27
"recent" :D
> So to get the keyboard working in the graphical console there again,
> we should now include XHCI support in the kernel by default, too.
>
> Signed-off-by: Thomas Huth <thuth@redhat.com>
Acked-by: Joel Stanley <joel@jms.id.au>
> ---
> arch/powerpc/configs/pseries_defconfig | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/powerpc/configs/pseries_defconfig b/arch/powerpc/configs/pseries_defconfig
> index ea79c51..62e12f6 100644
> --- a/arch/powerpc/configs/pseries_defconfig
> +++ b/arch/powerpc/configs/pseries_defconfig
> @@ -217,6 +217,7 @@ CONFIG_USB_MON=m
> CONFIG_USB_EHCI_HCD=y
> # CONFIG_USB_EHCI_HCD_PPC_OF is not set
> CONFIG_USB_OHCI_HCD=y
> +CONFIG_USB_XHCI_HCD=y
> CONFIG_USB_STORAGE=m
> CONFIG_NEW_LEDS=y
> CONFIG_LEDS_CLASS=m
> --
> 1.8.3.1
>
^ permalink raw reply
* Re: [PATCH kernel] vfio/spapr_tce: Skip unsetting already unset table
From: David Gibson @ 2019-02-11 23:44 UTC (permalink / raw)
To: Alexey Kardashevskiy; +Cc: Alex Williamson, linuxppc-dev, kvm, kvm-ppc
In-Reply-To: <20190211074917.125723-1-aik@ozlabs.ru>
[-- Attachment #1: Type: text/plain, Size: 2180 bytes --]
On Mon, Feb 11, 2019 at 06:49:17PM +1100, Alexey Kardashevskiy wrote:
> VFIO TCE IOMMU v2 owns IOMMU tables so when detach a IOMMU group from
> a container, we need to unset those from a group so we call unset_window()
> so do we unconditionally. We also unset tables when removing a DMA window
> via the VFIO_IOMMU_SPAPR_TCE_REMOVE ioctl.
>
> The window removal checks if the table actually exists (hidden inside
> tce_iommu_find_table()) but the group detaching does not so the user
> may see duplicating messages:
> pci 0009:03 : [PE# fd] Removing DMA window #0
> pci 0009:03 : [PE# fd] Removing DMA window #1
> pci 0009:03 : [PE# fd] Removing DMA window #0
> pci 0009:03 : [PE# fd] Removing DMA window #1
>
> At the moment this is not a problem as the second invocation
> of unset_window() writes zeroes to the HW registers again and exits early
> as there is no table.
>
> Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
> ---
>
> When doing VFIO PCI hot unplug, first we remove the DMA window and
> set container->tables[num] - this is a first couple of messages.
> Then we detach the group and then we see another couple of the same
> messages which confused myself.
> ---
> drivers/vfio/vfio_iommu_spapr_tce.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/vfio/vfio_iommu_spapr_tce.c b/drivers/vfio/vfio_iommu_spapr_tce.c
> index c424913..8dbb270 100644
> --- a/drivers/vfio/vfio_iommu_spapr_tce.c
> +++ b/drivers/vfio/vfio_iommu_spapr_tce.c
> @@ -1235,7 +1235,8 @@ static void tce_iommu_release_ownership_ddw(struct tce_container *container,
> }
>
> for (i = 0; i < IOMMU_TABLE_GROUP_MAX_TABLES; ++i)
> - table_group->ops->unset_window(table_group, i);
> + if (container->tables[i])
> + table_group->ops->unset_window(table_group, i);
>
> table_group->ops->release_ownership(table_group);
> }
--
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
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH kernel] powerpc/powernv/ioda: Store correct amount of memory used for table
From: David Gibson @ 2019-02-12 0:20 UTC (permalink / raw)
To: Alexey Kardashevskiy; +Cc: linuxppc-dev
In-Reply-To: <20190211074801.125646-1-aik@ozlabs.ru>
[-- Attachment #1: Type: text/plain, Size: 2502 bytes --]
On Mon, Feb 11, 2019 at 06:48:01PM +1100, Alexey Kardashevskiy wrote:
> We store 2 multilevel tables in iommu_table - one for the hardware and
> one with the corresponding userspace addresses. Before allocating
> the tables, the iommu_table_group_ops::get_table_size() hook returns
> the combined size of the two and VFIO SPAPR TCE IOMMU driver adjusts
> the locked_vm counter correctly. When the table is actually allocated,
> the amount of allocated memory is stored in iommu_table::it_allocated_size
> and used to adjust the locked_vm counter when we release the memory used
> by the table; .get_table_size() and .create_table() calculate it
> independently but the result is expected to be the same.
Any way we can remove that redundant calculation? That seems like
begging for bugs.
> Unfortunately the allocator does not add the userspace table size to
> ::it_allocated_size so when we destroy the table because of VFIO PCI
> unplug (i.e. VFIO container is gone but the userspace keeps running),
> we decrement locked_vm by just a half of size of memory we are releasing.
> As the result, we leak locked_vm and may not be able to allocate more
> IOMMU tables after few iterations of hotplug/unplug.
>
> This adjusts it_allocated_size if the userspace addresses table was
> requested (total_allocated_uas is initialized by zero).
>
> Fixes: 090bad39b "powerpc/powernv: Add indirect levels to it_userspace"
> Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
> ---
> arch/powerpc/platforms/powernv/pci-ioda-tce.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/powerpc/platforms/powernv/pci-ioda-tce.c b/arch/powerpc/platforms/powernv/pci-ioda-tce.c
> index 697449a..58146e1 100644
> --- a/arch/powerpc/platforms/powernv/pci-ioda-tce.c
> +++ b/arch/powerpc/platforms/powernv/pci-ioda-tce.c
> @@ -313,7 +313,7 @@ long pnv_pci_ioda2_table_alloc_pages(int nid, __u64 bus_offset,
> page_shift);
> tbl->it_level_size = 1ULL << (level_shift - 3);
> tbl->it_indirect_levels = levels - 1;
> - tbl->it_allocated_size = total_allocated;
> + tbl->it_allocated_size = total_allocated + total_allocated_uas;
> tbl->it_userspace = uas;
> tbl->it_nid = nid;
>
--
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
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH 06/12] dma-mapping: improve selection of dma_declare_coherent availability
From: Paul Burton @ 2019-02-12 2:17 UTC (permalink / raw)
To: Christoph Hellwig
Cc: linux-xtensa@linux-xtensa.org, linuxppc-dev@lists.ozlabs.org,
linux-sh@vger.kernel.org, devicetree@vger.kernel.org,
Greg Kroah-Hartman, x86@kernel.org, linux-mips@vger.kernel.org,
linux-kernel@vger.kernel.org, iommu@lists.linux-foundation.org,
linux-riscv@lists.infradead.org,
linux-snps-arc@lists.infradead.org, Lee Jones,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <20190211133554.30055-7-hch@lst.de>
Hi Christoph,
On Mon, Feb 11, 2019 at 02:35:48PM +0100, Christoph Hellwig wrote:
> This API is primarily used through DT entries, but two architectures
> and two drivers call it directly. So instead of selecting the config
> symbol for random architectures pull it in implicitly for the actual
> users. Also rename the Kconfig option to describe the feature better.
>
> Signed-off-by: Christoph Hellwig <hch@lst.de>
Acked-by: Paul Burton <paul.burton@mips.com> # MIPS
Thanks,
Paul
^ permalink raw reply
* [PATCH kernel] KVM: PPC: Release all hardware TCE tables attached to a group
From: Alexey Kardashevskiy @ 2019-02-12 4:37 UTC (permalink / raw)
To: linuxppc-dev
Cc: Alexey Kardashevskiy, Paul E . McKenney, kvm-ppc, David Gibson
The SPAPR TCE KVM device references all hardware IOMMU tables assigned to
some IOMMU group to ensure that in-kernel KVM acceleration of H_PUT_TCE
can work. The tables are references when an IOMMU group gets registered
with the VFIO KVM device by the KVM_DEV_VFIO_GROUP_ADD ioctl;
KVM_DEV_VFIO_GROUP_DEL calls into the dereferencing code
in kvm_spapr_tce_release_iommu_group() which walks through the list of
LIOBNs, finds a matching IOMMU table and calls kref_put() when found.
However that code stops after the very first successful derefencing
leaving other tables referenced till the SPAPR TCE KVM device is destroyed
which normally happens on guest reboot or termination so if we do hotplug
and unplug in a loop, we are leaking IOMMU tables here.
This removes a premature return to let kvm_spapr_tce_release_iommu_group()
find and dereference all attached tables.
Fixes: 121f80ba68f "KVM: PPC: VFIO: Add in-kernel acceleration for VFIO"
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
---
I kinda hoped to blame RCU for misbehaviour but it was me all over again :)
---
arch/powerpc/kvm/book3s_64_vio.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/powerpc/kvm/book3s_64_vio.c b/arch/powerpc/kvm/book3s_64_vio.c
index 532ab797..6630dde 100644
--- a/arch/powerpc/kvm/book3s_64_vio.c
+++ b/arch/powerpc/kvm/book3s_64_vio.c
@@ -133,7 +133,6 @@ extern void kvm_spapr_tce_release_iommu_group(struct kvm *kvm,
continue;
kref_put(&stit->kref, kvm_spapr_tce_liobn_put);
- return;
}
}
}
--
2.17.1
^ permalink raw reply related
* Re: [PATCH 2/5] vfio/spapr_tce: use pinned_vm instead of locked_vm to account pinned pages
From: Alexey Kardashevskiy @ 2019-02-12 6:56 UTC (permalink / raw)
To: Daniel Jordan, jgg
Cc: dave, jack, kvm, atull, linux-fpga, linux-kernel, kvm-ppc,
linux-mm, alex.williamson, mdf, akpm, linuxppc-dev, cl, hao.wu
In-Reply-To: <20190211224437.25267-3-daniel.m.jordan@oracle.com>
On 12/02/2019 09:44, Daniel Jordan wrote:
> Beginning with bc3e53f682d9 ("mm: distinguish between mlocked and pinned
> pages"), locked and pinned pages are accounted separately. The SPAPR
> TCE VFIO IOMMU driver accounts pinned pages to locked_vm; use pinned_vm
> instead.
>
> pinned_vm recently became atomic and so no longer relies on mmap_sem
> held as writer: delete.
>
> Signed-off-by: Daniel Jordan <daniel.m.jordan@oracle.com>
> ---
> Documentation/vfio.txt | 6 +--
> drivers/vfio/vfio_iommu_spapr_tce.c | 64 ++++++++++++++---------------
> 2 files changed, 33 insertions(+), 37 deletions(-)
>
> diff --git a/Documentation/vfio.txt b/Documentation/vfio.txt
> index f1a4d3c3ba0b..fa37d65363f9 100644
> --- a/Documentation/vfio.txt
> +++ b/Documentation/vfio.txt
> @@ -308,7 +308,7 @@ This implementation has some specifics:
> currently there is no way to reduce the number of calls. In order to make
> things faster, the map/unmap handling has been implemented in real mode
> which provides an excellent performance which has limitations such as
> - inability to do locked pages accounting in real time.
> + inability to do pinned pages accounting in real time.
>
> 4) According to sPAPR specification, A Partitionable Endpoint (PE) is an I/O
> subtree that can be treated as a unit for the purposes of partitioning and
> @@ -324,7 +324,7 @@ This implementation has some specifics:
> returns the size and the start of the DMA window on the PCI bus.
>
> VFIO_IOMMU_ENABLE
> - enables the container. The locked pages accounting
> + enables the container. The pinned pages accounting
> is done at this point. This lets user first to know what
> the DMA window is and adjust rlimit before doing any real job.
>
> @@ -454,7 +454,7 @@ This implementation has some specifics:
>
> PPC64 paravirtualized guests generate a lot of map/unmap requests,
> and the handling of those includes pinning/unpinning pages and updating
> - mm::locked_vm counter to make sure we do not exceed the rlimit.
> + mm::pinned_vm counter to make sure we do not exceed the rlimit.
> The v2 IOMMU splits accounting and pinning into separate operations:
>
> - VFIO_IOMMU_SPAPR_REGISTER_MEMORY/VFIO_IOMMU_SPAPR_UNREGISTER_MEMORY ioctls
> diff --git a/drivers/vfio/vfio_iommu_spapr_tce.c b/drivers/vfio/vfio_iommu_spapr_tce.c
> index c424913324e3..f47e020dc5e4 100644
> --- a/drivers/vfio/vfio_iommu_spapr_tce.c
> +++ b/drivers/vfio/vfio_iommu_spapr_tce.c
> @@ -34,9 +34,11 @@
> static void tce_iommu_detach_group(void *iommu_data,
> struct iommu_group *iommu_group);
>
> -static long try_increment_locked_vm(struct mm_struct *mm, long npages)
> +static long try_increment_pinned_vm(struct mm_struct *mm, long npages)
> {
> - long ret = 0, locked, lock_limit;
> + long ret = 0;
> + s64 pinned;
> + unsigned long lock_limit;
>
> if (WARN_ON_ONCE(!mm))
> return -EPERM;
> @@ -44,39 +46,33 @@ static long try_increment_locked_vm(struct mm_struct *mm, long npages)
> if (!npages)
> return 0;
>
> - down_write(&mm->mmap_sem);
> - locked = mm->locked_vm + npages;
> + pinned = atomic64_add_return(npages, &mm->pinned_vm);
> lock_limit = rlimit(RLIMIT_MEMLOCK) >> PAGE_SHIFT;
> - if (locked > lock_limit && !capable(CAP_IPC_LOCK))
> + if (pinned > lock_limit && !capable(CAP_IPC_LOCK)) {
> ret = -ENOMEM;
> - else
> - mm->locked_vm += npages;
> + atomic64_sub(npages, &mm->pinned_vm);
> + }
>
> - pr_debug("[%d] RLIMIT_MEMLOCK +%ld %ld/%ld%s\n", current->pid,
> + pr_debug("[%d] RLIMIT_MEMLOCK +%ld %ld/%lu%s\n", current->pid,
> npages << PAGE_SHIFT,
> - mm->locked_vm << PAGE_SHIFT,
> - rlimit(RLIMIT_MEMLOCK),
> - ret ? " - exceeded" : "");
> -
> - up_write(&mm->mmap_sem);
> + atomic64_read(&mm->pinned_vm) << PAGE_SHIFT,
> + rlimit(RLIMIT_MEMLOCK), ret ? " - exceeded" : "");
>
> return ret;
> }
>
> -static void decrement_locked_vm(struct mm_struct *mm, long npages)
> +static void decrement_pinned_vm(struct mm_struct *mm, long npages)
> {
> if (!mm || !npages)
> return;
>
> - down_write(&mm->mmap_sem);
> - if (WARN_ON_ONCE(npages > mm->locked_vm))
> - npages = mm->locked_vm;
> - mm->locked_vm -= npages;
> - pr_debug("[%d] RLIMIT_MEMLOCK -%ld %ld/%ld\n", current->pid,
> + if (WARN_ON_ONCE(npages > atomic64_read(&mm->pinned_vm)))
> + npages = atomic64_read(&mm->pinned_vm);
> + atomic64_sub(npages, &mm->pinned_vm);
> + pr_debug("[%d] RLIMIT_MEMLOCK -%ld %ld/%lu\n", current->pid,
> npages << PAGE_SHIFT,
> - mm->locked_vm << PAGE_SHIFT,
> + atomic64_read(&mm->pinned_vm) << PAGE_SHIFT,
> rlimit(RLIMIT_MEMLOCK));
> - up_write(&mm->mmap_sem);
So it used to be down_write+up_write and stuff in between.
Now it is 3 independent accesses (actually 4 but the last one is
diagnostic) with no locking around them. Why do not we need a lock
anymore precisely? Thanks,
> }
>
> /*
> @@ -110,7 +106,7 @@ struct tce_container {
> bool enabled;
> bool v2;
> bool def_window_pending;
> - unsigned long locked_pages;
> + unsigned long pinned_pages;
> struct mm_struct *mm;
> struct iommu_table *tables[IOMMU_TABLE_GROUP_MAX_TABLES];
> struct list_head group_list;
> @@ -283,7 +279,7 @@ static int tce_iommu_find_free_table(struct tce_container *container)
> static int tce_iommu_enable(struct tce_container *container)
> {
> int ret = 0;
> - unsigned long locked;
> + unsigned long pinned;
> struct iommu_table_group *table_group;
> struct tce_iommu_group *tcegrp;
>
> @@ -292,15 +288,15 @@ static int tce_iommu_enable(struct tce_container *container)
>
> /*
> * When userspace pages are mapped into the IOMMU, they are effectively
> - * locked memory, so, theoretically, we need to update the accounting
> - * of locked pages on each map and unmap. For powerpc, the map unmap
> + * pinned memory, so, theoretically, we need to update the accounting
> + * of pinned pages on each map and unmap. For powerpc, the map unmap
> * paths can be very hot, though, and the accounting would kill
> * performance, especially since it would be difficult to impossible
> * to handle the accounting in real mode only.
> *
> * To address that, rather than precisely accounting every page, we
> - * instead account for a worst case on locked memory when the iommu is
> - * enabled and disabled. The worst case upper bound on locked memory
> + * instead account for a worst case on pinned memory when the iommu is
> + * enabled and disabled. The worst case upper bound on pinned memory
> * is the size of the whole iommu window, which is usually relatively
> * small (compared to total memory sizes) on POWER hardware.
> *
> @@ -317,7 +313,7 @@ static int tce_iommu_enable(struct tce_container *container)
> *
> * So we do not allow enabling a container without a group attached
> * as there is no way to know how much we should increment
> - * the locked_vm counter.
> + * the pinned_vm counter.
> */
> if (!tce_groups_attached(container))
> return -ENODEV;
> @@ -335,12 +331,12 @@ static int tce_iommu_enable(struct tce_container *container)
> if (ret)
> return ret;
>
> - locked = table_group->tce32_size >> PAGE_SHIFT;
> - ret = try_increment_locked_vm(container->mm, locked);
> + pinned = table_group->tce32_size >> PAGE_SHIFT;
> + ret = try_increment_pinned_vm(container->mm, pinned);
> if (ret)
> return ret;
>
> - container->locked_pages = locked;
> + container->pinned_pages = pinned;
>
> container->enabled = true;
>
> @@ -355,7 +351,7 @@ static void tce_iommu_disable(struct tce_container *container)
> container->enabled = false;
>
> BUG_ON(!container->mm);
> - decrement_locked_vm(container->mm, container->locked_pages);
> + decrement_pinned_vm(container->mm, container->pinned_pages);
> }
>
> static void *tce_iommu_open(unsigned long arg)
> @@ -658,7 +654,7 @@ static long tce_iommu_create_table(struct tce_container *container,
> if (!table_size)
> return -EINVAL;
>
> - ret = try_increment_locked_vm(container->mm, table_size >> PAGE_SHIFT);
> + ret = try_increment_pinned_vm(container->mm, table_size >> PAGE_SHIFT);
> if (ret)
> return ret;
>
> @@ -677,7 +673,7 @@ static void tce_iommu_free_table(struct tce_container *container,
> unsigned long pages = tbl->it_allocated_size >> PAGE_SHIFT;
>
> iommu_tce_table_put(tbl);
> - decrement_locked_vm(container->mm, pages);
> + decrement_pinned_vm(container->mm, pages);
> }
>
> static long tce_iommu_create_window(struct tce_container *container,
>
--
Alexey
^ permalink raw reply
* Re: [GIT PULL] of: overlay: validation checks, subsequent fixes for v20 -- correction: v4.20
From: Greg Kroah-Hartman @ 2019-02-12 7:28 UTC (permalink / raw)
To: Alan Tull
Cc: devicetree@vger.kernel.org, linux-fpga, linuxppc-dev,
Pantelis Antoniou, linux-kernel@vger.kernel.org, Rob Herring,
Paul Mackerras, Moritz Fischer, Frank Rowand
In-Reply-To: <CANk1AXRnX+=v+7g-_rM3TwNmM3aVcOqRknv9BR+hBOeCtT24Fg@mail.gmail.com>
On Mon, Feb 11, 2019 at 02:43:48PM -0600, Alan Tull wrote:
> On Mon, Feb 11, 2019 at 1:13 PM Greg Kroah-Hartman
> <gregkh@linuxfoundation.org> wrote:
> >
> > On Mon, Feb 11, 2019 at 12:41:40PM -0600, Alan Tull wrote:
> > > On Fri, Nov 9, 2018 at 12:58 AM Frank Rowand <frowand.list@gmail.com> wrote:
> > >
> > > What LTSI's are these patches likely to end up in? Just to be clear,
> > > I'm not pushing for any specific answer, I just want to know what to
> > > expect.
> >
> > I have no idea what you are asking here.
> >
> > What patches?
>
> I probably should have asked my question *below* the pertinent context
> of the the 17 patches listed in the pull request, which was:
>
> > of: overlay: add tests to validate kfrees from overlay removal
> > of: overlay: add missing of_node_put() after add new node to changeset
> > of: overlay: add missing of_node_get() in __of_attach_node_sysfs
> > powerpc/pseries: add of_node_put() in dlpar_detach_node()
> > of: overlay: use prop add changeset entry for property in new nodes
> > of: overlay: do not duplicate properties from overlay for new nodes
> > of: overlay: reorder fields in struct fragment
> > of: overlay: validate overlay properties #address-cells and #size-cells
> > of: overlay: make all pr_debug() and pr_err() messages unique
> > of: overlay: test case of two fragments adding same node
> > of: overlay: check prevents multiple fragments add or delete same node
> > of: overlay: check prevents multiple fragments touching same property
> > of: unittest: remove unused of_unittest_apply_overlay() argument
> > of: overlay: set node fields from properties when add new overlay node
> > of: unittest: allow base devicetree to have symbol metadata
> > of: unittest: find overlays[] entry by name instead of index
> > of: unittest: initialize args before calling of_*parse_*()
>
> > What is "LTSI's"?
>
> I have recently seen some of devicetree patches being picked up for
> the 4.20 stable-queue. That seemed to suggest that some, but not all
> of these will end up in the next LTS release.
If the git commit has the "cc: stable@" marking in it, yes, it will be
picked up. Without the actual git ids, it's hard to know what did, and
what did not, get backported :)
> Also I was wondering if any of this is likely to get backported to
> LTSI-4.14.
Note, "LTSI" and "LTS" are two different things. "LTSI" is a project
run by some LF member companies, and "LTS" are the normal long term
kernels that I release on kernel.org. They have vastly different
requirements for inclusion in them.
If you have questions about LTSI, I recommend go asking on their mailing
list.
As for showing up in the 4.14 "LTS" kernel, again, I need git commit ids
to know for sure.
Also, as these are now in Linus's tree, you should be able to look at
the stable releases yourself to see if they are present there, right?
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH kernel] powerpc/powernv/ioda: Store correct amount of memory used for table
From: Alexey Kardashevskiy @ 2019-02-12 7:33 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev
In-Reply-To: <20190212002049.GC1884@umbus.fritz.box>
On 12/02/2019 11:20, David Gibson wrote:
> On Mon, Feb 11, 2019 at 06:48:01PM +1100, Alexey Kardashevskiy wrote:
>> We store 2 multilevel tables in iommu_table - one for the hardware and
>> one with the corresponding userspace addresses. Before allocating
>> the tables, the iommu_table_group_ops::get_table_size() hook returns
>> the combined size of the two and VFIO SPAPR TCE IOMMU driver adjusts
>> the locked_vm counter correctly. When the table is actually allocated,
>> the amount of allocated memory is stored in iommu_table::it_allocated_size
>> and used to adjust the locked_vm counter when we release the memory used
>> by the table; .get_table_size() and .create_table() calculate it
>> independently but the result is expected to be the same.
>
> Any way we can remove that redundant calculation? That seems like
> begging for bugs.
I do not see an easy way. One way could be adding a "dryrun" flag to
pnv_pci_ioda2_table_alloc_pages(), count allocated memory there and call
it from .get_table_size() but for multilevel TCEs it only allocates
first level...
>> Unfortunately the allocator does not add the userspace table size to
>> ::it_allocated_size so when we destroy the table because of VFIO PCI
>> unplug (i.e. VFIO container is gone but the userspace keeps running),
>> we decrement locked_vm by just a half of size of memory we are releasing.
>> As the result, we leak locked_vm and may not be able to allocate more
>> IOMMU tables after few iterations of hotplug/unplug.
>>
>> This adjusts it_allocated_size if the userspace addresses table was
>> requested (total_allocated_uas is initialized by zero).
>>
>> Fixes: 090bad39b "powerpc/powernv: Add indirect levels to it_userspace"
>> Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
>
> Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
>
>> ---
>> arch/powerpc/platforms/powernv/pci-ioda-tce.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/arch/powerpc/platforms/powernv/pci-ioda-tce.c b/arch/powerpc/platforms/powernv/pci-ioda-tce.c
>> index 697449a..58146e1 100644
>> --- a/arch/powerpc/platforms/powernv/pci-ioda-tce.c
>> +++ b/arch/powerpc/platforms/powernv/pci-ioda-tce.c
>> @@ -313,7 +313,7 @@ long pnv_pci_ioda2_table_alloc_pages(int nid, __u64 bus_offset,
>> page_shift);
>> tbl->it_level_size = 1ULL << (level_shift - 3);
>> tbl->it_indirect_levels = levels - 1;
>> - tbl->it_allocated_size = total_allocated;
>> + tbl->it_allocated_size = total_allocated + total_allocated_uas;
>> tbl->it_userspace = uas;
>> tbl->it_nid = nid;
>>
>
--
Alexey
^ permalink raw reply
* Re: [PATCH 02/12] device.h: dma_mem is only needed for HAVE_GENERIC_DMA_COHERENT
From: Greg Kroah-Hartman @ 2019-02-12 7:49 UTC (permalink / raw)
To: Christoph Hellwig
Cc: linux-xtensa, linux-sh, devicetree, linuxppc-dev, x86, linux-mips,
linux-kernel, iommu, linux-riscv, linux-snps-arc, Lee Jones,
linux-arm-kernel
In-Reply-To: <20190211133554.30055-3-hch@lst.de>
On Mon, Feb 11, 2019 at 02:35:44PM +0100, Christoph Hellwig wrote:
> No need to carry an unused field around.
>
> Signed-off-by: Christoph Hellwig <hch@lst.de>
> ---
> include/linux/device.h | 2 ++
> 1 file changed, 2 insertions(+)
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
^ permalink raw reply
* Re: [PATCH 06/12] dma-mapping: improve selection of dma_declare_coherent availability
From: Greg Kroah-Hartman @ 2019-02-12 7:49 UTC (permalink / raw)
To: Christoph Hellwig
Cc: linux-xtensa, linux-sh, devicetree, linuxppc-dev, x86, linux-mips,
linux-kernel, iommu, linux-riscv, linux-snps-arc, Lee Jones,
linux-arm-kernel
In-Reply-To: <20190211133554.30055-7-hch@lst.de>
On Mon, Feb 11, 2019 at 02:35:48PM +0100, Christoph Hellwig wrote:
> This API is primarily used through DT entries, but two architectures
> and two drivers call it directly. So instead of selecting the config
> symbol for random architectures pull it in implicitly for the actual
> users. Also rename the Kconfig option to describe the feature better.
>
> Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
^ permalink raw reply
* Re: [PATCH 09/12] dma-mapping: remove the DMA_MEMORY_EXCLUSIVE flag
From: Greg Kroah-Hartman @ 2019-02-12 7:50 UTC (permalink / raw)
To: Christoph Hellwig
Cc: linux-xtensa, linux-sh, devicetree, linuxppc-dev, x86, linux-mips,
linux-kernel, iommu, linux-riscv, linux-snps-arc, Lee Jones,
linux-arm-kernel
In-Reply-To: <20190211133554.30055-10-hch@lst.de>
On Mon, Feb 11, 2019 at 02:35:51PM +0100, Christoph Hellwig wrote:
> All users of dma_declare_coherent want their allocations to be
> exclusive, so default to exclusive allocations.
>
> Signed-off-by: Christoph Hellwig <hch@lst.de>
> ---
> Documentation/DMA-API.txt | 9 +------
> arch/arm/mach-imx/mach-imx27_visstrim_m10.c | 12 +++------
> arch/arm/mach-imx/mach-mx31moboard.c | 3 +--
> arch/sh/boards/mach-ap325rxa/setup.c | 5 ++--
> arch/sh/boards/mach-ecovec24/setup.c | 6 ++---
> arch/sh/boards/mach-kfr2r09/setup.c | 5 ++--
> arch/sh/boards/mach-migor/setup.c | 5 ++--
> arch/sh/boards/mach-se/7724/setup.c | 6 ++---
> arch/sh/drivers/pci/fixups-dreamcast.c | 3 +--
> .../soc_camera/sh_mobile_ceu_camera.c | 3 +--
> drivers/usb/host/ohci-sm501.c | 3 +--
> drivers/usb/host/ohci-tmio.c | 2 +-
> include/linux/dma-mapping.h | 7 ++----
> kernel/dma/coherent.c | 25 ++++++-------------
> 14 files changed, 29 insertions(+), 65 deletions(-)
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
^ permalink raw reply
* Re: [PATCH 07/12] dma-mapping: move CONFIG_DMA_CMA to kernel/dma/Kconfig
From: Greg Kroah-Hartman @ 2019-02-12 7:50 UTC (permalink / raw)
To: Christoph Hellwig
Cc: linux-xtensa, linux-sh, devicetree, linuxppc-dev, x86, linux-mips,
linux-kernel, iommu, linux-riscv, linux-snps-arc, Lee Jones,
linux-arm-kernel
In-Reply-To: <20190211133554.30055-8-hch@lst.de>
On Mon, Feb 11, 2019 at 02:35:49PM +0100, Christoph Hellwig wrote:
> This is where all the related code already lives.
>
> Signed-off-by: Christoph Hellwig <hch@lst.de>
> ---
> drivers/base/Kconfig | 77 --------------------------------------------
> kernel/dma/Kconfig | 77 ++++++++++++++++++++++++++++++++++++++++++++
> 2 files changed, 77 insertions(+), 77 deletions(-)
Much nicer, thanks!
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
^ permalink raw reply
* Re: [PATCH] mmap.2: describe the 5level paging hack
From: Kirill A. Shutemov @ 2019-02-12 9:41 UTC (permalink / raw)
To: Jann Horn
Cc: linux-arch, linux-man, Catalin Marinas, Dave Hansen,
Peter Zijlstra, Will Deacon, linuxppc-dev, Andy Lutomirski,
linux-mm, Paul Mackerras, mtk.manpages, Andrew Morton, linux-api,
Linus Torvalds, Thomas Gleixner, Kirill A . Shutemov,
linux-arm-kernel
In-Reply-To: <20190211163653.97742-1-jannh@google.com>
On Mon, Feb 11, 2019 at 05:36:53PM +0100, Jann Horn wrote:
> The manpage is missing information about the compatibility hack for
> 5-level paging that went in in 4.14, around commit ee00f4a32a76 ("x86/mm:
> Allow userspace have mappings above 47-bit"). Add some information about
> that.
>
> While I don't think any hardware supporting this is shipping yet (?), I
> think it's useful to try to write a manpage for this API, partly to
> figure out how usable that API actually is, and partly because when this
> hardware does ship, it'd be nice if distro manpages had information about
> how to use it.
>
> Signed-off-by: Jann Horn <jannh@google.com>
Thanks for doing this.
> ---
> This patch goes on top of the patch "[PATCH] mmap.2: fix description of
> treatment of the hint" that I just sent, but I'm not sending them in a
> series because I want the first one to go in, and I think this one might
> be a bit more controversial.
>
> It would be nice if the architecture maintainers and mm folks could have
> a look at this and check that what I wrote is right - I only looked at
> the source for this, I haven't tried it.
>
> man2/mmap.2 | 15 +++++++++++++++
> 1 file changed, 15 insertions(+)
>
> diff --git a/man2/mmap.2 b/man2/mmap.2
> index 8556bbfeb..977782fa8 100644
> --- a/man2/mmap.2
> +++ b/man2/mmap.2
> @@ -67,6 +67,8 @@ is NULL,
> then the kernel chooses the (page-aligned) address
> at which to create the mapping;
> this is the most portable method of creating a new mapping.
> +On Linux, in this case, the kernel may limit the maximum address that can be
> +used for allocations to a legacy limit for compatibility reasons.
> If
> .I addr
> is not NULL,
> @@ -77,6 +79,19 @@ or equal to the value specified by
> and attempt to create the mapping there.
> If another mapping already exists there, the kernel picks a new
> address, independent of the hint.
> +However, if a hint above the architecture's legacy address limit is provided
> +(on x86-64: above 0x7ffffffff000, on arm64: above 0x1000000000000, on ppc64 with
> +book3s: above 0x7fffffffffff or 0x3fffffffffff, depending on page size), the
> +kernel is permitted to allocate mappings beyond the architecture's legacy
> +address limit. The availability of such addresses is hardware-dependent.
> +Therefore, if you want to be able to use the full virtual address space of
> +hardware that supports addresses beyond the legacy range, you need to specify an
> +address above that limit; however, for security reasons, you should avoid
> +specifying a fixed valid address outside the compatibility range,
> +since that would reduce the value of userspace address space layout
> +randomization. Therefore, it is recommended to specify an address
> +.I beyond
> +the end of the userspace address space.
It probably worth recommending (void *) -1 as such address.
> .\" Before Linux 2.6.24, the address was rounded up to the next page
> .\" boundary; since 2.6.24, it is rounded down!
> The address of the new mapping is returned as the result of the call.
> --
> 2.20.1.791.gb4d0f1c61a-goog
>
--
Kirill A. Shutemov
^ permalink raw reply
* [PATCH 0/2] x86, numa: always initialize all possible nodes
From: Michal Hocko @ 2019-02-12 9:53 UTC (permalink / raw)
To: linux-mm
Cc: Tony Luck, linux-ia64, Peter Zijlstra, x86, LKML, Pingfan Liu,
Dave Hansen, Ingo Molnar, linuxppc-dev
Hi,
this has been posted as an RFC previously [1]. There didn't seem to be
any objections so I am reposting this for inclusion. I have added a
debugging patch which prints the zonelist setup for each numa node
for an easier debugging of a broken zonelist setup.
[1] http://lkml.kernel.org/r/20190114082416.30939-1-mhocko@kernel.org
^ permalink raw reply
* [PATCH 1/2] x86, numa: always initialize all possible nodes
From: Michal Hocko @ 2019-02-12 9:53 UTC (permalink / raw)
To: linux-mm
Cc: Tony Luck, linux-ia64, Peter Zijlstra, x86, LKML, Pingfan Liu,
Dave Hansen, Michal Hocko, Ingo Molnar, linuxppc-dev
In-Reply-To: <20190212095343.23315-1-mhocko@kernel.org>
From: Michal Hocko <mhocko@suse.com>
Pingfan Liu has reported the following splat
[ 5.772742] BUG: unable to handle kernel paging request at 0000000000002088
[ 5.773618] PGD 0 P4D 0
[ 5.773618] Oops: 0000 [#1] SMP NOPTI
[ 5.773618] CPU: 2 PID: 1 Comm: swapper/0 Not tainted 4.20.0-rc1+ #3
[ 5.773618] Hardware name: Dell Inc. PowerEdge R7425/02MJ3T, BIOS 1.4.3 06/29/2018
[ 5.773618] RIP: 0010:__alloc_pages_nodemask+0xe2/0x2a0
[ 5.773618] Code: 00 00 44 89 ea 80 ca 80 41 83 f8 01 44 0f 44 ea 89 da c1 ea 08 83 e2 01 88 54 24 20 48 8b 54 24 08 48 85 d2 0f 85 46 01 00 00 <3b> 77 08 0f 82 3d 01 00 00 48 89 f8 44 89 ea 48 89
e1 44 89 e6 89
[ 5.773618] RSP: 0018:ffffaa600005fb20 EFLAGS: 00010246
[ 5.773618] RAX: 0000000000000000 RBX: 00000000006012c0 RCX: 0000000000000000
[ 5.773618] RDX: 0000000000000000 RSI: 0000000000000002 RDI: 0000000000002080
[ 5.773618] RBP: 00000000006012c0 R08: 0000000000000000 R09: 0000000000000002
[ 5.773618] R10: 00000000006080c0 R11: 0000000000000002 R12: 0000000000000000
[ 5.773618] R13: 0000000000000001 R14: 0000000000000000 R15: 0000000000000002
[ 5.773618] FS: 0000000000000000(0000) GS:ffff8c69afe00000(0000) knlGS:0000000000000000
[ 5.773618] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 5.773618] CR2: 0000000000002088 CR3: 000000087e00a000 CR4: 00000000003406e0
[ 5.773618] Call Trace:
[ 5.773618] new_slab+0xa9/0x570
[ 5.773618] ___slab_alloc+0x375/0x540
[ 5.773618] ? pinctrl_bind_pins+0x2b/0x2a0
[ 5.773618] __slab_alloc+0x1c/0x38
[ 5.773618] __kmalloc_node_track_caller+0xc8/0x270
[ 5.773618] ? pinctrl_bind_pins+0x2b/0x2a0
[ 5.773618] devm_kmalloc+0x28/0x60
[ 5.773618] pinctrl_bind_pins+0x2b/0x2a0
[ 5.773618] really_probe+0x73/0x420
[ 5.773618] driver_probe_device+0x115/0x130
[ 5.773618] __driver_attach+0x103/0x110
[ 5.773618] ? driver_probe_device+0x130/0x130
[ 5.773618] bus_for_each_dev+0x67/0xc0
[ 5.773618] ? klist_add_tail+0x3b/0x70
[ 5.773618] bus_add_driver+0x41/0x260
[ 5.773618] ? pcie_port_setup+0x4d/0x4d
[ 5.773618] driver_register+0x5b/0xe0
[ 5.773618] ? pcie_port_setup+0x4d/0x4d
[ 5.773618] do_one_initcall+0x4e/0x1d4
[ 5.773618] ? init_setup+0x25/0x28
[ 5.773618] kernel_init_freeable+0x1c1/0x26e
[ 5.773618] ? loglevel+0x5b/0x5b
[ 5.773618] ? rest_init+0xb0/0xb0
[ 5.773618] kernel_init+0xa/0x110
[ 5.773618] ret_from_fork+0x22/0x40
[ 5.773618] Modules linked in:
[ 5.773618] CR2: 0000000000002088
[ 5.773618] ---[ end trace 1030c9120a03d081 ]---
with his AMD machine with the following topology
NUMA node0 CPU(s): 0,8,16,24
NUMA node1 CPU(s): 2,10,18,26
NUMA node2 CPU(s): 4,12,20,28
NUMA node3 CPU(s): 6,14,22,30
NUMA node4 CPU(s): 1,9,17,25
NUMA node5 CPU(s): 3,11,19,27
NUMA node6 CPU(s): 5,13,21,29
NUMA node7 CPU(s): 7,15,23,31
[ 0.007418] Early memory node ranges
[ 0.007419] node 1: [mem 0x0000000000001000-0x000000000008efff]
[ 0.007420] node 1: [mem 0x0000000000090000-0x000000000009ffff]
[ 0.007422] node 1: [mem 0x0000000000100000-0x000000005c3d6fff]
[ 0.007422] node 1: [mem 0x00000000643df000-0x0000000068ff7fff]
[ 0.007423] node 1: [mem 0x000000006c528000-0x000000006fffffff]
[ 0.007424] node 1: [mem 0x0000000100000000-0x000000047fffffff]
[ 0.007425] node 5: [mem 0x0000000480000000-0x000000087effffff]
and nr_cpus set to 4. The underlying reason is tha the device is bound
to node 2 which doesn't have any memory and init_cpu_to_node only
initializes memory-less nodes for possible cpus which nr_cpus restrics.
This in turn means that proper zonelists are not allocated and the page
allocator blows up.
Fix the issue by reworking how x86 initializes the memory less nodes.
The current implementation is hacked into the workflow and it doesn't
allow any flexibility. There is init_memory_less_node called for each
offline node that has a CPU as already mentioned above. This will make
sure that we will have a new online node without any memory. Much later
on we build a zone list for this node and things seem to work, except
they do not (e.g. due to nr_cpus). Not to mention that it doesn't really
make much sense to consider an empty node as online because we just
consider this node whenever we want to iterate nodes to use and empty
node is obviously not the best candidate. This is all just too fragile.
The new code relies on the arch specific initialization to allocate all
possible NUMA nodes (including memory less) - numa_register_memblks in
this case. Generic code then initializes both zonelists (__build_all_zonelists)
and allocator internals (free_area_init_nodes) for all non-null pgdats
rather than online ones.
For the x86 specific part also do not make new node online in alloc_node_data
because this is too early to know that. numa_register_memblks knows that
a node has some memory so it can make the node online appropriately.
init_memory_less_node hack can be safely removed altogether now.
Reported-by: Pingfan Liu <kernelfans@gmail.com>
Tested-by: Pingfan Liu <kernelfans@gmail.com>
Signed-off-by: Michal Hocko <mhocko@suse.com>
---
arch/x86/mm/numa.c | 27 +++------------------------
mm/page_alloc.c | 15 +++++++++------
2 files changed, 12 insertions(+), 30 deletions(-)
diff --git a/arch/x86/mm/numa.c b/arch/x86/mm/numa.c
index 1308f5408bf7..b3621ee4dfe8 100644
--- a/arch/x86/mm/numa.c
+++ b/arch/x86/mm/numa.c
@@ -216,8 +216,6 @@ static void __init alloc_node_data(int nid)
node_data[nid] = nd;
memset(NODE_DATA(nid), 0, sizeof(pg_data_t));
-
- node_set_online(nid);
}
/**
@@ -570,7 +568,7 @@ static int __init numa_register_memblks(struct numa_meminfo *mi)
return -EINVAL;
/* Finally register nodes. */
- for_each_node_mask(nid, node_possible_map) {
+ for_each_node_mask(nid, numa_nodes_parsed) {
u64 start = PFN_PHYS(max_pfn);
u64 end = 0;
@@ -581,9 +579,6 @@ static int __init numa_register_memblks(struct numa_meminfo *mi)
end = max(mi->blk[i].end, end);
}
- if (start >= end)
- continue;
-
/*
* Don't confuse VM with a node that doesn't have the
* minimum amount of memory:
@@ -592,6 +587,8 @@ static int __init numa_register_memblks(struct numa_meminfo *mi)
continue;
alloc_node_data(nid);
+ if (end)
+ node_set_online(nid);
}
/* Dump memblock with node info and return. */
@@ -721,21 +718,6 @@ void __init x86_numa_init(void)
numa_init(dummy_numa_init);
}
-static void __init init_memory_less_node(int nid)
-{
- unsigned long zones_size[MAX_NR_ZONES] = {0};
- unsigned long zholes_size[MAX_NR_ZONES] = {0};
-
- /* Allocate and initialize node data. Memory-less node is now online.*/
- alloc_node_data(nid);
- free_area_init_node(nid, zones_size, 0, zholes_size);
-
- /*
- * All zonelists will be built later in start_kernel() after per cpu
- * areas are initialized.
- */
-}
-
/*
* Setup early cpu_to_node.
*
@@ -763,9 +745,6 @@ void __init init_cpu_to_node(void)
if (node == NUMA_NO_NODE)
continue;
- if (!node_online(node))
- init_memory_less_node(node);
-
numa_set_node(cpu, node);
}
}
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 2ec9cc407216..2e097f336126 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -5361,10 +5361,11 @@ static void __build_all_zonelists(void *data)
if (self && !node_online(self->node_id)) {
build_zonelists(self);
} else {
- for_each_online_node(nid) {
+ for_each_node(nid) {
pg_data_t *pgdat = NODE_DATA(nid);
- build_zonelists(pgdat);
+ if (pgdat)
+ build_zonelists(pgdat);
}
#ifdef CONFIG_HAVE_MEMORYLESS_NODES
@@ -6644,10 +6645,8 @@ static unsigned long __init find_min_pfn_for_node(int nid)
for_each_mem_pfn_range(i, nid, &start_pfn, NULL, NULL)
min_pfn = min(min_pfn, start_pfn);
- if (min_pfn == ULONG_MAX) {
- pr_warn("Could not find start_pfn for node %d\n", nid);
+ if (min_pfn == ULONG_MAX)
return 0;
- }
return min_pfn;
}
@@ -6991,8 +6990,12 @@ void __init free_area_init_nodes(unsigned long *max_zone_pfn)
mminit_verify_pageflags_layout();
setup_nr_node_ids();
zero_resv_unavail();
- for_each_online_node(nid) {
+ for_each_node(nid) {
pg_data_t *pgdat = NODE_DATA(nid);
+
+ if (!pgdat)
+ continue;
+
free_area_init_node(nid, NULL,
find_min_pfn_for_node(nid), NULL);
--
2.20.1
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox