* Re: [PATCH] kdb: use correct pointer when 'btc' calls 'btt'
From: Tobin C. Harding @ 2018-09-16 22:18 UTC (permalink / raw)
To: Daniel Thompson
Cc: Christophe Leroy, Jason Wessel, Michael Ellerman, linux-kernel,
linuxppc-dev, kgdb-bugreport, stable
In-Reply-To: <20180916190610.vzqxwps7zqy2zc6o@holly.lan>
On Sun, Sep 16, 2018 at 12:06:10PM -0700, Daniel Thompson wrote:
> On Fri, Sep 14, 2018 at 12:35:44PM +0000, Christophe Leroy wrote:
> > On a powerpc 8xx, 'btc' fails as follows:
> >
> > Entering kdb (current=0x(ptrval), pid 282) due to Keyboard Entry
> > kdb> btc
> > btc: cpu status: Currently on cpu 0
> > Available cpus: 0
> > kdb_getarea: Bad address 0x0
> >
> > when booting the kernel with 'debug_boot_weak_hash', it fails as well
> >
> > Entering kdb (current=0xba99ad80, pid 284) due to Keyboard Entry
> > kdb> btc
> > btc: cpu status: Currently on cpu 0
> > Available cpus: 0
> > kdb_getarea: Bad address 0xba99ad80
> >
> > On other platforms, Oopses have been observed too, see
> > https://github.com/linuxppc/linux/issues/139
> >
> > This is due to btc calling 'btt' with %p pointer as an argument.
> >
> > This patch replaces %p by %px to get the real pointer value as
> > expected by 'btt'
> >
> > Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
> > Cc: <stable@vger.kernel.org> # 4.15+
>
> Would a Fixes: be better here?
> Fixes: ad67b74d2469d9b82 ("printk: hash addresses printed with %p")
>
> No blame attached to Tobin, but the fixes makes it super clear what
:)
> changed and why this breaks kdb (which was not explicitly called out
> the patch description).
>
>
> Daniel.
^ permalink raw reply
* Re: [PATCH 03/12] powerpc/64s/hash: move POWER5 < DD2.1 slbie workaround where it is needed
From: kbuild test robot @ 2018-09-16 22:06 UTC (permalink / raw)
To: Nicholas Piggin
Cc: kbuild-all, linuxppc-dev, Aneesh Kumar K . V, Nicholas Piggin
In-Reply-To: <20180914153056.3644-4-npiggin@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 7968 bytes --]
Hi Nicholas,
I love your patch! Yet something to improve:
[auto build test ERROR on powerpc/next]
[also build test ERROR on v4.19-rc3 next-20180913]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Nicholas-Piggin/SLB-miss-conversion-to-C-and-SLB-optimisations/20180917-015458
base: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git next
config: powerpc-defconfig (attached as .config)
compiler: powerpc64-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
GCC_VERSION=7.2.0 make.cross ARCH=powerpc
Note: it may well be a FALSE warning. FWIW you are at least aware of it now.
http://gcc.gnu.org/wiki/Better_Uninitialized_Warnings
Note: the linux-review/Nicholas-Piggin/SLB-miss-conversion-to-C-and-SLB-optimisations/20180917-015458 HEAD b26bd44c74488169a0fd19eef43ea3db189a207d builds fine.
It only hurts bisectibility.
All errors (new ones prefixed by >>):
arch/powerpc/mm/slb.c: In function 'switch_slb':
>> arch/powerpc/mm/slb.c:258:4: error: 'slbie_data' may be used uninitialized in this function [-Werror=maybe-uninitialized]
asm volatile("slbie %0" : : "r" (slbie_data));
^~~
cc1: all warnings being treated as errors
vim +/slbie_data +258 arch/powerpc/mm/slb.c
465ccab9 arch/powerpc/mm/slb.c will schmidt 2007-10-31 224
^1da177e arch/ppc64/mm/slb.c Linus Torvalds 2005-04-16 225 /* Flush all user entries from the segment table of the current processor. */
^1da177e arch/ppc64/mm/slb.c Linus Torvalds 2005-04-16 226 void switch_slb(struct task_struct *tsk, struct mm_struct *mm)
^1da177e arch/ppc64/mm/slb.c Linus Torvalds 2005-04-16 227 {
9c1e1052 arch/powerpc/mm/slb.c Paul Mackerras 2009-08-17 228 unsigned long offset;
^1da177e arch/ppc64/mm/slb.c Linus Torvalds 2005-04-16 229 unsigned long pc = KSTK_EIP(tsk);
^1da177e arch/ppc64/mm/slb.c Linus Torvalds 2005-04-16 230 unsigned long stack = KSTK_ESP(tsk);
de4376c2 arch/powerpc/mm/slb.c Anton Blanchard 2009-07-13 231 unsigned long exec_base;
^1da177e arch/ppc64/mm/slb.c Linus Torvalds 2005-04-16 232
9c1e1052 arch/powerpc/mm/slb.c Paul Mackerras 2009-08-17 233 /*
9c1e1052 arch/powerpc/mm/slb.c Paul Mackerras 2009-08-17 234 * We need interrupts hard-disabled here, not just soft-disabled,
9c1e1052 arch/powerpc/mm/slb.c Paul Mackerras 2009-08-17 235 * so that a PMU interrupt can't occur, which might try to access
9c1e1052 arch/powerpc/mm/slb.c Paul Mackerras 2009-08-17 236 * user memory (to get a stack trace) and possible cause an SLB miss
9c1e1052 arch/powerpc/mm/slb.c Paul Mackerras 2009-08-17 237 * which would update the slb_cache/slb_cache_ptr fields in the PACA.
9c1e1052 arch/powerpc/mm/slb.c Paul Mackerras 2009-08-17 238 */
9c1e1052 arch/powerpc/mm/slb.c Paul Mackerras 2009-08-17 239 hard_irq_disable();
9c1e1052 arch/powerpc/mm/slb.c Paul Mackerras 2009-08-17 240 offset = get_paca()->slb_cache_ptr;
44ae3ab3 arch/powerpc/mm/slb.c Matt Evans 2011-04-06 241 if (!mmu_has_feature(MMU_FTR_NO_SLBIE_B) &&
f66bce5e arch/powerpc/mm/slb.c Olof Johansson 2007-10-16 242 offset <= SLB_CACHE_ENTRIES) {
6697d605 arch/powerpc/mm/slb.c Nicholas Piggin 2018-09-15 243 unsigned long slbie_data;
^1da177e arch/ppc64/mm/slb.c Linus Torvalds 2005-04-16 244 int i;
6697d605 arch/powerpc/mm/slb.c Nicholas Piggin 2018-09-15 245
^1da177e arch/ppc64/mm/slb.c Linus Torvalds 2005-04-16 246 asm volatile("isync" : : : "memory");
^1da177e arch/ppc64/mm/slb.c Linus Torvalds 2005-04-16 247 for (i = 0; i < offset; i++) {
1189be65 arch/powerpc/mm/slb.c Paul Mackerras 2007-10-11 248 slbie_data = (unsigned long)get_paca()->slb_cache[i]
1189be65 arch/powerpc/mm/slb.c Paul Mackerras 2007-10-11 249 << SID_SHIFT; /* EA */
1189be65 arch/powerpc/mm/slb.c Paul Mackerras 2007-10-11 250 slbie_data |= user_segment_size(slbie_data)
1189be65 arch/powerpc/mm/slb.c Paul Mackerras 2007-10-11 251 << SLBIE_SSIZE_SHIFT;
1189be65 arch/powerpc/mm/slb.c Paul Mackerras 2007-10-11 252 slbie_data |= SLBIE_C; /* C set for user addresses */
1189be65 arch/powerpc/mm/slb.c Paul Mackerras 2007-10-11 253 asm volatile("slbie %0" : : "r" (slbie_data));
^1da177e arch/ppc64/mm/slb.c Linus Torvalds 2005-04-16 254 }
^1da177e arch/ppc64/mm/slb.c Linus Torvalds 2005-04-16 255
^1da177e arch/ppc64/mm/slb.c Linus Torvalds 2005-04-16 256 /* Workaround POWER5 < DD2.1 issue */
6697d605 arch/powerpc/mm/slb.c Nicholas Piggin 2018-09-15 257 if (!cpu_has_feature(CPU_FTR_ARCH_207S) && offset == 1)
1189be65 arch/powerpc/mm/slb.c Paul Mackerras 2007-10-11 @258 asm volatile("slbie %0" : : "r" (slbie_data));
6697d605 arch/powerpc/mm/slb.c Nicholas Piggin 2018-09-15 259
6697d605 arch/powerpc/mm/slb.c Nicholas Piggin 2018-09-15 260 asm volatile("isync" : : : "memory");
6697d605 arch/powerpc/mm/slb.c Nicholas Piggin 2018-09-15 261 } else {
6697d605 arch/powerpc/mm/slb.c Nicholas Piggin 2018-09-15 262 __slb_flush_and_rebolt();
c15c9670 arch/powerpc/mm/slb.c Nicholas Piggin 2018-09-15 263 }
^1da177e arch/ppc64/mm/slb.c Linus Torvalds 2005-04-16 264
^1da177e arch/ppc64/mm/slb.c Linus Torvalds 2005-04-16 265 get_paca()->slb_cache_ptr = 0;
52b1e665 arch/powerpc/mm/slb.c Aneesh Kumar K.V 2017-03-22 266 copy_mm_to_paca(mm);
^1da177e arch/ppc64/mm/slb.c Linus Torvalds 2005-04-16 267
^1da177e arch/ppc64/mm/slb.c Linus Torvalds 2005-04-16 268 /*
^1da177e arch/ppc64/mm/slb.c Linus Torvalds 2005-04-16 269 * preload some userspace segments into the SLB.
de4376c2 arch/powerpc/mm/slb.c Anton Blanchard 2009-07-13 270 * Almost all 32 and 64bit PowerPC executables are linked at
de4376c2 arch/powerpc/mm/slb.c Anton Blanchard 2009-07-13 271 * 0x10000000 so it makes sense to preload this segment.
^1da177e arch/ppc64/mm/slb.c Linus Torvalds 2005-04-16 272 */
de4376c2 arch/powerpc/mm/slb.c Anton Blanchard 2009-07-13 273 exec_base = 0x10000000;
^1da177e arch/ppc64/mm/slb.c Linus Torvalds 2005-04-16 274
5eb9bac0 arch/powerpc/mm/slb.c Anton Blanchard 2009-07-13 275 if (is_kernel_addr(pc) || is_kernel_addr(stack) ||
de4376c2 arch/powerpc/mm/slb.c Anton Blanchard 2009-07-13 276 is_kernel_addr(exec_base))
^1da177e arch/ppc64/mm/slb.c Linus Torvalds 2005-04-16 277 return;
^1da177e arch/ppc64/mm/slb.c Linus Torvalds 2005-04-16 278
5eb9bac0 arch/powerpc/mm/slb.c Anton Blanchard 2009-07-13 279 slb_allocate(pc);
^1da177e arch/ppc64/mm/slb.c Linus Torvalds 2005-04-16 280
5eb9bac0 arch/powerpc/mm/slb.c Anton Blanchard 2009-07-13 281 if (!esids_match(pc, stack))
^1da177e arch/ppc64/mm/slb.c Linus Torvalds 2005-04-16 282 slb_allocate(stack);
^1da177e arch/ppc64/mm/slb.c Linus Torvalds 2005-04-16 283
de4376c2 arch/powerpc/mm/slb.c Anton Blanchard 2009-07-13 284 if (!esids_match(pc, exec_base) &&
de4376c2 arch/powerpc/mm/slb.c Anton Blanchard 2009-07-13 285 !esids_match(stack, exec_base))
de4376c2 arch/powerpc/mm/slb.c Anton Blanchard 2009-07-13 286 slb_allocate(exec_base);
^1da177e arch/ppc64/mm/slb.c Linus Torvalds 2005-04-16 287 }
^1da177e arch/ppc64/mm/slb.c Linus Torvalds 2005-04-16 288
:::::: The code at line 258 was first introduced by commit
:::::: 1189be6508d45183013ddb82b18f4934193de274 [POWERPC] Use 1TB segments
:::::: TO: Paul Mackerras <paulus@samba.org>
:::::: CC: Paul Mackerras <paulus@samba.org>
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 23944 bytes --]
^ permalink raw reply
* Re: [PATCH 1/3] powerpc: remove old GCC version checks
From: Joel Stanley @ 2018-09-17 2:31 UTC (permalink / raw)
To: Nicholas Piggin; +Cc: linuxppc-dev
In-Reply-To: <20180914050854.6214-2-npiggin@gmail.com>
On Fri, 14 Sep 2018 at 14:39, Nicholas Piggin <npiggin@gmail.com> wrote:
>
> GCC 4.6 is the minimum supported now.
>
> Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Reviewed-by: Joel Stanley <joel@jms.id.au>
^ permalink raw reply
* Re: [PATCH 2/3] powerpc: consolidate -mno-sched-epilog into FTRACE flags
From: Joel Stanley @ 2018-09-17 2:32 UTC (permalink / raw)
To: Nicholas Piggin; +Cc: linuxppc-dev
In-Reply-To: <20180914050854.6214-3-npiggin@gmail.com>
On Fri, 14 Sep 2018 at 14:39, Nicholas Piggin <npiggin@gmail.com> wrote:
>
> Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Reviewed-by: Joel Stanley <joel@jms.id.au>
^ permalink raw reply
* Re: [PATCH 3/3] powerpc: avoid -mno-sched-epilog on GCC 4.9 and newer
From: Joel Stanley @ 2018-09-17 2:36 UTC (permalink / raw)
To: Nicholas Piggin; +Cc: linuxppc-dev
In-Reply-To: <20180914050854.6214-4-npiggin@gmail.com>
On Fri, 14 Sep 2018 at 14:39, Nicholas Piggin <npiggin@gmail.com> wrote:
>
> Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Reviewed-by: Joel Stanley <joel@jms.id.au>
I gave this a spin with clang trunk on the powernv kernel and it did
the trick. Thanks!
mpe, this series supersedes [v2,5/5] powerpc: Remove -mno-sched-epilog
(https://patchwork.ozlabs.org/patch/969615/).
Cheers,
Joel
^ permalink raw reply
* Re: [PATCH 1/2] powerpc/prom: Remove VLA in prom_check_platform_support()
From: Joel Stanley @ 2018-09-17 2:37 UTC (permalink / raw)
To: Suraj Jitindar Singh
Cc: linuxppc-dev, Michael Ellerman, Michael Neuling, Kees Cook
In-Reply-To: <20180905020951.10372-2-sjitindarsingh@gmail.com>
On Wed, 5 Sep 2018 at 11:40, Suraj Jitindar Singh
<sjitindarsingh@gmail.com> wrote:
>
> In prom_check_platform_support() we retrieve and parse the
> "ibm,arch-vec-5-platform-support" property of the chosen node.
> Currently we use a variable length array however to avoid this use an
> array of constant length 8.
>
> This property is used to indicate the supported options of vector 5
> bytes 23-26 of the ibm,architecture.vec node. Each of these options
> is a pair of bytes, thus for 4 options we have a max length of 8 bytes.
>
> Signed-off-by: Suraj Jitindar Singh <sjitindarsingh@gmail.com>
Reviewed-by: Joel Stanley <joel@jms.id.au>
^ permalink raw reply
* Re: [PATCH 2/2] powerpc/pseries: Remove VLA from lparcfg_write()
From: Joel Stanley @ 2018-09-17 2:37 UTC (permalink / raw)
To: Suraj Jitindar Singh
Cc: linuxppc-dev, Michael Ellerman, Michael Neuling, Kees Cook
In-Reply-To: <20180905020951.10372-3-sjitindarsingh@gmail.com>
On Wed, 5 Sep 2018 at 11:40, Suraj Jitindar Singh
<sjitindarsingh@gmail.com> wrote:
>
> In lparcfg_write we hard code kbuf_sz and then use this as the variable
> length of kbuf creating a variable length array. Since we're hard coding
> the length anyway just define the array using this as the length and
> remove the need for kbuf_sz, thus removing the variable length array.
>
> Signed-off-by: Suraj Jitindar Singh <sjitindarsingh@gmail.com>
Reviewed-by: Joel Stanley <joel@jms.id.au>
^ permalink raw reply
* Re: [RFC PATCH 00/11] New TM Model
From: Michael Neuling @ 2018-09-17 5:25 UTC (permalink / raw)
To: Breno Leitao, linuxppc-dev; +Cc: paulus, gromero, mpe, ldufour, Cyril Bur
In-Reply-To: <1536781219-13938-1-git-send-email-leitao@debian.org>
On Wed, 2018-09-12 at 16:40 -0300, Breno Leitao wrote:
> This patchset for the hardware transactional memory (TM) subsystem aims t=
o
> avoid spending a lot of time on TM suspended mode in kernel space. It
> basically
> changes where the reclaim/recheckpoint will be executed.
>=20
> Once a CPU enters in transactional state it uses a footprint area to trac=
k
> down the load/stores performed in transaction so it can be verified later
> to decide if a conflict happened due to some change done in that state. I=
f
> a transaction is active in userspace and there is an exception that takes
> the CPU to the kernel space the CPU moves the transaction to suspended
> state but does not discard the footprint area.
In this description, you should differente between memory and register
(GPR/VSX/SPR) footprints.
In suspend, the CPU can disregard the memory footprint at any point, but it=
has
to keep the register footprint. =20
In the above paragraph you are talking about register footprint but not mem=
ory
footprint.=20
>=20
> POWER9 has a known problem[1][2] and does not have enough room in
> footprint area for several transactions to be suspended at the same time
> on concurrent CPUs leading to CPU stalls.
>=20
> This patchset aims to reclaim the checkpointed footprint as soon as the
> kernel is invoked, in the beginning of the exception handlers, thus freei=
ng
> room to other CPUs enter in suspended mode, avoiding too many CPUs in
> suspended
> state that can cause the CPUs to stall. The same mechanism is done on ker=
nel
> exit, doing a recheckpoint as late as possible (which will reload the
> checkpointed state into CPU's room) at the exception return.
OK, but we are still potentially in suspend in userspace, so that doesn't h=
elp
us on the lockup issue.
We need fake suspend in userspace to prevent lockups.
> The way to achieve this goal is creating a macro (TM_KERNEL_ENTRY) which
> will check if userspace was in an active transaction just after getting
> into kernel and reclaiming if that's the case. Thus all exception handler=
s
> will call this macro as soon as possible.
>=20
> All exceptions should reclaim (if necessary) at this stage and only
> recheckpoint if the task is tagged as TIF_RESTORE_TM (i.e. was in
> transactional state before being interrupted), which will be done at
> ret_from_except_lite().
>=20
> Ideally all reclaims will happen at the exception entrance, however durin=
g
> the recheckpoint process another exception can hit the CPU which might
> cause the current thread to be rescheduled, thus there is another reclaim
> point to be considered at __switch_to().
Can we do the recheckpoint() later so that it's when we have interrupts off=
and
can't be rescheduled?
> Hence, by allowing the CPU to be in suspended state for only a brief peri=
od
> it's possible to cope with the TM hardware limitations like the current
> problem on the new POWER9.
As mentioned, since we're still running userspace with real suspend, we sti=
ll
have an issue.
> This patchset was tested in different scenarios using different test
> suites, as the kernel selftests and htm-torture[3], in the following
> configuration:
>=20
> * POWER8/pseries LE and BE
> * POWER8/powernv LE
> * POWER9/powernv LE hosting KVM guests running TM tests
>=20
> This patchset is based on initial work done by Cyril Bur:
> https://patchwork.ozlabs.org/cover/875341/
Adding Cyril to CC.
Mikey
^ permalink raw reply
* Re: [RFC PATCH 05/11] powerpc/tm: Function that updates the failure code
From: Michael Neuling @ 2018-09-17 5:29 UTC (permalink / raw)
To: Breno Leitao, linuxppc-dev; +Cc: paulus, gromero, mpe, ldufour
In-Reply-To: <1536781219-13938-6-git-send-email-leitao@debian.org>
This series is not bisectable because this patch fails with:
arch/powerpc/kernel/process.c:993:13: error: =E2=80=98tm_fix_failure_cause=
=E2=80=99 defined but not used [-Werror=3Dunused-function]
static void tm_fix_failure_cause(struct task_struct *task, uint8_t cause)
^
cc1: all warnings being treated as errors
scripts/Makefile.build:305: recipe for target 'arch/powerpc/kernel/process.=
o' failed
Mikey
On Wed, 2018-09-12 at 16:40 -0300, Breno Leitao wrote:
> Now the transaction reclaims happens very earlier in the trap handler, an=
d
> it is impossible to know precisely, at that early time, what should be se=
t
> as the failure cause for some specific cases, as, if the task will be
> rescheduled, thus, the transaction abort case should be updated from
> TM_CAUSE_MISC to TM_CAUSE_RESCHED, for example.
>=20
> This patch creates a function that will update TEXASR special purpose
> register in the task thread and set the failure code which will be
> moved to the live register afterward.
>=20
> Signed-off-by: Breno Leitao <leitao@debian.org>
> ---
> arch/powerpc/kernel/process.c | 9 +++++++++
> 1 file changed, 9 insertions(+)
>=20
> diff --git a/arch/powerpc/kernel/process.c b/arch/powerpc/kernel/process.=
c
> index 54fddf03b97a..fe063c0142e3 100644
> --- a/arch/powerpc/kernel/process.c
> +++ b/arch/powerpc/kernel/process.c
> @@ -85,6 +85,7 @@ extern unsigned long _get_SP(void);
> * other paths that we should never reach with suspend disabled.
> */
> bool tm_suspend_disabled __ro_after_init =3D false;
> +static void tm_fix_failure_cause(struct task_struct *task, uint8_t cause=
);
> =20
> static void check_if_tm_restore_required(struct task_struct *tsk)
> {
> @@ -988,6 +989,14 @@ void tm_recheckpoint(struct thread_struct *thread)
> local_irq_restore(flags);
> }
> =20
> +/* Change thread->tm.texasr failure code */
> +static void tm_fix_failure_cause(struct task_struct *task, uint8_t cause=
)
> +{
> + /* Clear the cause first */
> + task->thread.tm_texasr &=3D ~TEXASR_FC;
> + task->thread.tm_texasr |=3D (unsigned long) cause << 56;
> +}
> +
> static inline void tm_recheckpoint_new_task(struct task_struct *new)
> {
> if (!cpu_has_feature(CPU_FTR_TM))
^ permalink raw reply
* Re: [PATCH 03/12] powerpc/64s/hash: move POWER5 < DD2.1 slbie workaround where it is needed
From: Aneesh Kumar K.V @ 2018-09-17 6:00 UTC (permalink / raw)
To: Nicholas Piggin, linuxppc-dev; +Cc: Nicholas Piggin
In-Reply-To: <20180914153056.3644-4-npiggin@gmail.com>
Nicholas Piggin <npiggin@gmail.com> writes:
> The POWER5 < DD2.1 issue is that slbie needs to be issued more than
> once. It came in with this change:
>
> ChangeSet@1.1608, 2004-04-29 07:12:31-07:00, david@gibson.dropbear.id.au
> [PATCH] POWER5 erratum workaround
>
> Early POWER5 revisions (<DD2.1) have a problem requiring slbie
> instructions to be repeated under some circumstances. The patch below
> adds a workaround (patch made by Anton Blanchard).
Thanks for extracting this. Can we add this to the code? Also I am not
sure what is repeated here? Is it that we just need one slb extra(hence
only applicable to offset == 1) or is it that we need to make sure there
is always one slb extra? The code does the former. Do you a have link for
that email patch?
>
> The extra slbie in switch_slb is done even for the case where slbia is
> called (slb_flush_and_rebolt). I don't believe that is required
> because there are other slb_flush_and_rebolt callers which do not
> issue the workaround slbie, which would be broken if it was required.
>
> It also seems to be fine inside the isync with the first slbie, as it
> is in the kernel stack switch code.
>
> So move this workaround to where it is required. This is not much of
> an optimisation because this is the fast path, but it makes the code
> more understandable and neater.
>
> Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
> ---
> arch/powerpc/mm/slb.c | 14 +++++++-------
> 1 file changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/arch/powerpc/mm/slb.c b/arch/powerpc/mm/slb.c
> index 1c7128c63a4b..d952ece3abf7 100644
> --- a/arch/powerpc/mm/slb.c
> +++ b/arch/powerpc/mm/slb.c
> @@ -226,7 +226,6 @@ static inline int esids_match(unsigned long addr1, unsigned long addr2)
> void switch_slb(struct task_struct *tsk, struct mm_struct *mm)
> {
> unsigned long offset;
> - unsigned long slbie_data = 0;
> unsigned long pc = KSTK_EIP(tsk);
> unsigned long stack = KSTK_ESP(tsk);
> unsigned long exec_base;
> @@ -241,7 +240,9 @@ void switch_slb(struct task_struct *tsk, struct mm_struct *mm)
> offset = get_paca()->slb_cache_ptr;
> if (!mmu_has_feature(MMU_FTR_NO_SLBIE_B) &&
> offset <= SLB_CACHE_ENTRIES) {
> + unsigned long slbie_data;
> int i;
> +
> asm volatile("isync" : : : "memory");
> for (i = 0; i < offset; i++) {
> slbie_data = (unsigned long)get_paca()->slb_cache[i]
> @@ -251,15 +252,14 @@ void switch_slb(struct task_struct *tsk, struct mm_struct *mm)
> slbie_data |= SLBIE_C; /* C set for user addresses */
> asm volatile("slbie %0" : : "r" (slbie_data));
> }
> - asm volatile("isync" : : : "memory");
> - } else {
> - __slb_flush_and_rebolt();
> - }
>
> - if (!cpu_has_feature(CPU_FTR_ARCH_207S)) {
> /* Workaround POWER5 < DD2.1 issue */
> - if (offset == 1 || offset > SLB_CACHE_ENTRIES)
> + if (!cpu_has_feature(CPU_FTR_ARCH_207S) && offset == 1)
> asm volatile("slbie %0" : : "r" (slbie_data));
> +
> + asm volatile("isync" : : : "memory");
> + } else {
> + __slb_flush_and_rebolt();
> }
>
> get_paca()->slb_cache_ptr = 0;
> --
> 2.18.0
^ permalink raw reply
* Re: [PATCH 05/12] powerpc/64s/hash: Use POWER6 SLBIA IH=1 variant in switch_slb
From: Aneesh Kumar K.V @ 2018-09-17 6:08 UTC (permalink / raw)
To: Nicholas Piggin, linuxppc-dev; +Cc: Nicholas Piggin
In-Reply-To: <20180914153056.3644-6-npiggin@gmail.com>
Nicholas Piggin <npiggin@gmail.com> writes:
> The SLBIA IH=1 hint will remove all non-zero SLBEs, but only
> invalidate ERAT entries associated with a class value of 1, for
> processors that support the hint (e.g., POWER6 and newer), which
> Linux assigns to user addresses.
>
> This prevents kernel ERAT entries from being invalidated when
> context switchig (if the thread faulted in more than 8 user SLBEs).
how about renaming stuff to indicate kernel ERAT entries are kept?
something like slb_flush_and_rebolt_user()?
>
> Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
> ---
> arch/powerpc/mm/slb.c | 38 +++++++++++++++++++++++---------------
> 1 file changed, 23 insertions(+), 15 deletions(-)
>
> diff --git a/arch/powerpc/mm/slb.c b/arch/powerpc/mm/slb.c
> index a5e58f11d676..03fa1c663ccf 100644
> --- a/arch/powerpc/mm/slb.c
> +++ b/arch/powerpc/mm/slb.c
> @@ -128,13 +128,21 @@ void slb_flush_all_realmode(void)
> asm volatile("slbmte %0,%0; slbia" : : "r" (0));
> }
>
> -static void __slb_flush_and_rebolt(void)
> +void slb_flush_and_rebolt(void)
> {
> /* If you change this make sure you change SLB_NUM_BOLTED
> * and PR KVM appropriately too. */
> unsigned long linear_llp, lflags;
> unsigned long ksp_esid_data, ksp_vsid_data;
>
> + WARN_ON(!irqs_disabled());
> +
> + /*
> + * We can't take a PMU exception in the following code, so hard
> + * disable interrupts.
> + */
> + hard_irq_disable();
> +
> linear_llp = mmu_psize_defs[mmu_linear_psize].sllp;
> lflags = SLB_VSID_KERNEL | linear_llp;
>
> @@ -160,20 +168,7 @@ static void __slb_flush_and_rebolt(void)
> :: "r"(ksp_vsid_data),
> "r"(ksp_esid_data)
> : "memory");
> -}
>
> -void slb_flush_and_rebolt(void)
> -{
> -
> - WARN_ON(!irqs_disabled());
> -
> - /*
> - * We can't take a PMU exception in the following code, so hard
> - * disable interrupts.
> - */
> - hard_irq_disable();
> -
> - __slb_flush_and_rebolt();
> get_paca()->slb_cache_ptr = 0;
> }
>
> @@ -248,7 +243,20 @@ void switch_slb(struct task_struct *tsk, struct mm_struct *mm)
>
> asm volatile("isync" : : : "memory");
> } else {
> - __slb_flush_and_rebolt();
> + struct slb_shadow *p = get_slb_shadow();
> + unsigned long ksp_esid_data =
> + be64_to_cpu(p->save_area[KSTACK_INDEX].esid);
> + unsigned long ksp_vsid_data =
> + be64_to_cpu(p->save_area[KSTACK_INDEX].vsid);
> +
> + asm volatile("isync\n"
> + PPC_SLBIA(1) "\n"
> + "slbmte %0,%1\n"
> + "isync"
> + :: "r"(ksp_vsid_data),
> + "r"(ksp_esid_data));
> +
> + asm volatile("isync" : : : "memory");
> }
>
> get_paca()->slb_cache_ptr = 0;
> --
> 2.18.0
^ permalink raw reply
* [PATCH v3 1/3] watchdog: mpc8xxx: use dev_xxxx() instead of pr_xxxx()
From: Christophe Leroy @ 2018-09-17 6:22 UTC (permalink / raw)
To: Wim Van Sebroeck, Guenter Roeck, Radu Rendec, Rob Herring,
Mark Rutland
Cc: linux-kernel, linuxppc-dev, linux-watchdog, devicetree
mpc8xxx watchdog driver is a platform device drivers, it is
therefore possible to use dev_xxx() messaging rather than pr_xxx()
Reviewed-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
---
drivers/watchdog/mpc8xxx_wdt.c | 24 ++++++++++++------------
1 file changed, 12 insertions(+), 12 deletions(-)
diff --git a/drivers/watchdog/mpc8xxx_wdt.c b/drivers/watchdog/mpc8xxx_wdt.c
index aca2d6323f8a..1dcf5f10cdd9 100644
--- a/drivers/watchdog/mpc8xxx_wdt.c
+++ b/drivers/watchdog/mpc8xxx_wdt.c
@@ -17,8 +17,6 @@
* option) any later version.
*/
-#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
-
#include <linux/fs.h>
#include <linux/init.h>
#include <linux/kernel.h>
@@ -137,26 +135,27 @@ static int mpc8xxx_wdt_probe(struct platform_device *ofdev)
struct mpc8xxx_wdt_ddata *ddata;
u32 freq = fsl_get_sys_freq();
bool enabled;
+ struct device *dev = &ofdev->dev;
- wdt_type = of_device_get_match_data(&ofdev->dev);
+ wdt_type = of_device_get_match_data(dev);
if (!wdt_type)
return -EINVAL;
if (!freq || freq == -1)
return -EINVAL;
- ddata = devm_kzalloc(&ofdev->dev, sizeof(*ddata), GFP_KERNEL);
+ ddata = devm_kzalloc(dev, sizeof(*ddata), GFP_KERNEL);
if (!ddata)
return -ENOMEM;
res = platform_get_resource(ofdev, IORESOURCE_MEM, 0);
- ddata->base = devm_ioremap_resource(&ofdev->dev, res);
+ ddata->base = devm_ioremap_resource(dev, res);
if (IS_ERR(ddata->base))
return PTR_ERR(ddata->base);
enabled = in_be32(&ddata->base->swcrr) & SWCRR_SWEN;
if (!enabled && wdt_type->hw_enabled) {
- pr_info("could not be enabled in software\n");
+ dev_info(dev, "could not be enabled in software\n");
return -ENODEV;
}
@@ -166,7 +165,7 @@ static int mpc8xxx_wdt_probe(struct platform_device *ofdev)
ddata->wdd.ops = &mpc8xxx_wdt_ops,
ddata->wdd.timeout = WATCHDOG_TIMEOUT;
- watchdog_init_timeout(&ddata->wdd, timeout, &ofdev->dev);
+ watchdog_init_timeout(&ddata->wdd, timeout, dev);
watchdog_set_nowayout(&ddata->wdd, nowayout);
@@ -189,12 +188,13 @@ static int mpc8xxx_wdt_probe(struct platform_device *ofdev)
ret = watchdog_register_device(&ddata->wdd);
if (ret) {
- pr_err("cannot register watchdog device (err=%d)\n", ret);
+ dev_err(dev, "cannot register watchdog device (err=%d)\n", ret);
return ret;
}
- pr_info("WDT driver for MPC8xxx initialized. mode:%s timeout=%d sec\n",
- reset ? "reset" : "interrupt", ddata->wdd.timeout);
+ dev_info(dev,
+ "WDT driver for MPC8xxx initialized. mode:%s timeout=%d sec\n",
+ reset ? "reset" : "interrupt", ddata->wdd.timeout);
platform_set_drvdata(ofdev, ddata);
return 0;
@@ -204,8 +204,8 @@ static int mpc8xxx_wdt_remove(struct platform_device *ofdev)
{
struct mpc8xxx_wdt_ddata *ddata = platform_get_drvdata(ofdev);
- pr_crit("Watchdog removed, expect the %s soon!\n",
- reset ? "reset" : "machine check exception");
+ dev_crit(&ofdev->dev, "Watchdog removed, expect the %s soon!\n",
+ reset ? "reset" : "machine check exception");
watchdog_unregister_device(&ddata->wdd);
return 0;
--
2.13.3
^ permalink raw reply related
* [PATCH v3 2/3] watchdog: mpc8xxx: provide boot status
From: Christophe Leroy @ 2018-09-17 6:22 UTC (permalink / raw)
To: Wim Van Sebroeck, Guenter Roeck, Radu Rendec, Rob Herring,
Mark Rutland
Cc: linux-kernel, linuxppc-dev, linux-watchdog, devicetree
In-Reply-To: <c09f541d459c29aca40d54fff152d5645e24b50d.1537163776.git.christophe.leroy@c-s.fr>
mpc8xxx watchdog driver supports the following platforms:
- mpc8xx
- mpc83xx
- mpc86xx
Those three platforms have a 32 bits register which provides the
reason of the last boot, including whether it was caused by the
watchdog.
mpc8xx: Register RSR, bit SWRS (bit 3)
mpc83xx: Register RSR, bit SWRS (bit 28)
mpc86xx: Register RSTRSCR, bit WDT_RR (bit 11)
This patch maps the register as defined in the device tree and updates
wdt.bootstatus based on the value of the watchdog related bit. Then
the information can be retrieved via the WDIOC_GETBOOTSTATUS ioctl.
Hereunder is an example of devicetree for mpc8xx,
the Reset Status Register being at offset 0x288:
WDT: watchdog@0 {
compatible = "fsl,mpc823-wdt";
reg = <0x0 0x10 0x288 0x4>;
};
On the mpc83xx, RSR is at offset 0x910
On the mpc86xx, RSTRSCR is at offset 0xe0094
Suggested-by: Radu Rendec <radu.rendec@gmail.com>
Tested-by: Christophe Leroy <christophe.leroy@c-s.fr> # On mpc885
Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
---
drivers/watchdog/mpc8xxx_wdt.c | 22 ++++++++++++++++++++++
1 file changed, 22 insertions(+)
diff --git a/drivers/watchdog/mpc8xxx_wdt.c b/drivers/watchdog/mpc8xxx_wdt.c
index 1dcf5f10cdd9..069072e6747d 100644
--- a/drivers/watchdog/mpc8xxx_wdt.c
+++ b/drivers/watchdog/mpc8xxx_wdt.c
@@ -47,6 +47,7 @@ struct mpc8xxx_wdt {
struct mpc8xxx_wdt_type {
int prescaler;
bool hw_enabled;
+ u32 rsr_mask;
};
struct mpc8xxx_wdt_ddata {
@@ -159,6 +160,24 @@ static int mpc8xxx_wdt_probe(struct platform_device *ofdev)
return -ENODEV;
}
+ res = platform_get_resource(ofdev, IORESOURCE_MEM, 1);
+ if (res) {
+ bool status;
+ u32 __iomem *rsr = ioremap(res->start, resource_size(res));
+
+ if (!rsr)
+ return -ENOMEM;
+
+ status = in_be32(rsr) & wdt_type->rsr_mask;
+ ddata->wdd.bootstatus = status ? WDIOF_CARDRESET : 0;
+ /* clear reset status bits related to watchdog timer */
+ out_be32(rsr, wdt_type->rsr_mask);
+ iounmap(rsr);
+
+ dev_info(dev, "Last boot was %scaused by watchdog\n",
+ status ? "" : "not ");
+ }
+
spin_lock_init(&ddata->lock);
ddata->wdd.info = &mpc8xxx_wdt_info,
@@ -216,6 +235,7 @@ static const struct of_device_id mpc8xxx_wdt_match[] = {
.compatible = "mpc83xx_wdt",
.data = &(struct mpc8xxx_wdt_type) {
.prescaler = 0x10000,
+ .rsr_mask = BIT(3), /* RSR Bit SWRS */
},
},
{
@@ -223,6 +243,7 @@ static const struct of_device_id mpc8xxx_wdt_match[] = {
.data = &(struct mpc8xxx_wdt_type) {
.prescaler = 0x10000,
.hw_enabled = true,
+ .rsr_mask = BIT(20), /* RSTRSCR Bit WDT_RR */
},
},
{
@@ -230,6 +251,7 @@ static const struct of_device_id mpc8xxx_wdt_match[] = {
.data = &(struct mpc8xxx_wdt_type) {
.prescaler = 0x800,
.hw_enabled = true,
+ .rsr_mask = BIT(28), /* RSR Bit SWRS */
},
},
{},
--
2.13.3
^ permalink raw reply related
* [PATCH v3 3/3] dt-bindings: watchdog: add mpc8xxx-wdt support
From: Christophe Leroy @ 2018-09-17 6:22 UTC (permalink / raw)
To: Wim Van Sebroeck, Guenter Roeck, Radu Rendec, Rob Herring,
Mark Rutland
Cc: linux-kernel, linuxppc-dev, linux-watchdog, devicetree
In-Reply-To: <c09f541d459c29aca40d54fff152d5645e24b50d.1537163776.git.christophe.leroy@c-s.fr>
Add description of DT bindings for mpc8xxx-wdt driver which
handles the CPU watchdog timer on the mpc83xx, mpc86xx and mpc8xx.
Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
---
.../devicetree/bindings/watchdog/mpc8xxx-wdt.txt | 25 ++++++++++++++++++++++
1 file changed, 25 insertions(+)
create mode 100644 Documentation/devicetree/bindings/watchdog/mpc8xxx-wdt.txt
diff --git a/Documentation/devicetree/bindings/watchdog/mpc8xxx-wdt.txt b/Documentation/devicetree/bindings/watchdog/mpc8xxx-wdt.txt
new file mode 100644
index 000000000000..e176face472a
--- /dev/null
+++ b/Documentation/devicetree/bindings/watchdog/mpc8xxx-wdt.txt
@@ -0,0 +1,25 @@
+* Freescale mpc8xxx watchdog driver (For 83xx, 86xx and 8xx)
+
+Required properties:
+- compatible: Shall contain one of the following:
+ "mpc83xx_wdt" for an mpc83xx
+ "fsl,mpc8610-wdt" for an mpc86xx
+ "fsl,mpc823-wdt" for an mpc8xx
+- reg: base physical address and length of the area hosting the
+ watchdog registers.
+ On the 83xx, "Watchdog Timer Registers" area: <0x200 0x100>
+ On the 86xx, "Watchdog Timer Registers" area: <0xe4000 0x100>
+ On the 8xx, "General System Interface Unit" area: <0x0 0x10>
+
+Optional properties:
+- reg: additional physical address and length (4) of location of the
+ Reset Status Register (called RSTRSCR on the mpc86xx)
+ On the 83xx, it is located at offset 0x910
+ On the 86xx, it is located at offset 0xe0094
+ On the 8xx, it is located at offset 0x288
+
+Example:
+ WDT: watchdog@0 {
+ compatible = "fsl,mpc823-wdt";
+ reg = <0x0 0x10 0x288 0x4>;
+ };
--
2.13.3
^ permalink raw reply related
* Re: [PATCH 01/12] powerpc/64s/hash: Fix stab_rr off by one initialization
From: Joel Stanley @ 2018-09-17 6:51 UTC (permalink / raw)
To: Nicholas Piggin; +Cc: linuxppc-dev, aneesh.kumar
In-Reply-To: <20180914153056.3644-2-npiggin@gmail.com>
On Sat, 15 Sep 2018 at 01:03, Nicholas Piggin <npiggin@gmail.com> wrote:
>
> This causes SLB alloation to start 1 beyond the start of the SLB.
> There is no real problem because after it wraps it stats behaving
starts?
> properly, it's just surprisig to see when looking at SLB traces.
surprising
>
> Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
> ---
> arch/powerpc/mm/slb.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/powerpc/mm/slb.c b/arch/powerpc/mm/slb.c
> index 9f574e59d178..2f162c6e52d4 100644
> --- a/arch/powerpc/mm/slb.c
> +++ b/arch/powerpc/mm/slb.c
> @@ -355,7 +355,7 @@ void slb_initialize(void)
> #endif
> }
>
> - get_paca()->stab_rr = SLB_NUM_BOLTED;
> + get_paca()->stab_rr = SLB_NUM_BOLTED - 1;
>
> lflags = SLB_VSID_KERNEL | linear_llp;
> vflags = SLB_VSID_KERNEL | vmalloc_llp;
> --
> 2.18.0
>
^ permalink raw reply
* Re: [PATCH kernel RFC 0/3] powerpc/pseries/iommu: GPU coherent memory pass through
From: Alexey Kardashevskiy @ 2018-09-17 7:05 UTC (permalink / raw)
To: linuxppc-dev
Cc: David Gibson, kvm-ppc, Benjamin Herrenschmidt, Michael Ellerman,
Paul Mackerras, Russell Currey
In-Reply-To: <a28c139e-deb6-cdb3-1eb5-b8d6e7378ce1@ozlabs.ru>
Ping?
The problem is still there...
On 24/08/2018 13:04, Alexey Kardashevskiy wrote:
>
>
> On 09/08/2018 14:41, Alexey Kardashevskiy wrote:
>>
>>
>> On 25/07/2018 19:50, Alexey Kardashevskiy wrote:
>>> I am trying to pass through a 3D controller:
>>> [0302]: NVIDIA Corporation GV100GL [Tesla V100 SXM2] [10de:1db1] (rev a1)
>>>
>>> which has a quite unique feature as coherent memory directly accessible
>>> from a POWER9 CPU via an NVLink2 transport.
>>>
>>> So in addition to passing a PCI device + accompanying NPU devices,
>>> we will also be passing the host physical address range as it is done
>>> on the bare metal system.
>>>
>>> The memory on the host is presented as:
>>>
>>> ===
>>> [aik@yc02goos ~]$ lsprop /proc/device-tree/memory@42000000000
>>> ibm,chip-id 000000fe (254)
>>> device_type "memory"
>>> compatible "ibm,coherent-device-memory"
>>> reg 00000420 00000000 00000020 00000000
>>> linux,usable-memory
>>> 00000420 00000000 00000000 00000000
>>> phandle 00000726 (1830)
>>> name "memory"
>>> ibm,associativity
>>> 00000004 000000fe 000000fe 000000fe 000000fe
>>> ===
>>>
>>> and the host does not touch it as the second 64bit value of
>>> "linux,usable-memory" - the size - is null. Later on the NVIDIA driver
>>> trains the NVLink2 and probes this memory and this is how it becomes
>>> onlined.
>>>
>>> In the virtual environment I am planning on doing the same thing,
>>> however there is a difference in 64bit DMA handling. The powernv
>>> platform uses a PHB3 bypass mode and that just works but
>>> the pseries platform uses DDW RTAS API to achieve the same
>>> result and the problem with this is that we need a huge DMA
>>> window to start from zero (because this GPU supports less than
>>> 50bits for DMA address space) and cover not just present memory
>>> but also this new coherent memory.
>>>
>>>
>>> This is based on sha1
>>> d72e90f3 Linus Torvalds "Linux 4.18-rc6".
>>>
>>> Please comment. Thanks.
>>
>>
>> Ping?
>
>
> Ping?
>
>>
>>
>>>
>>>
>>>
>>> Alexey Kardashevskiy (3):
>>> powerpc/pseries/iommu: Allow dynamic window to start from zero
>>> powerpc/pseries/iommu: Force default DMA window removal
>>> powerpc/pseries/iommu: Use memory@ nodes in max RAM address
>>> calculation
>>>
>>> arch/powerpc/platforms/pseries/iommu.c | 77 ++++++++++++++++++++++++++++++----
>>> 1 file changed, 70 insertions(+), 7 deletions(-)
>>>
>>
>
--
Alexey
^ permalink raw reply
* Re: [PATCH RFCv2 3/6] mm/memory_hotplug: fix online/offline_pages called w.o. mem_hotplug_lock
From: David Hildenbrand @ 2018-09-17 7:32 UTC (permalink / raw)
To: Rashmica, linux-mm
Cc: linux-kernel, linux-doc, linuxppc-dev, linux-acpi, xen-devel,
devel, Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman,
Rafael J. Wysocki, Len Brown, Greg Kroah-Hartman,
K. Y. Srinivasan, Haiyang Zhang, Stephen Hemminger,
Martin Schwidefsky, Heiko Carstens, Boris Ostrovsky,
Juergen Gross, Michael Neuling, Balbir Singh, Kate Stewart,
Thomas Gleixner, Philippe Ombredanne, Andrew Morton, Michal Hocko,
Pavel Tatashin, Vlastimil Babka, Dan Williams, Oscar Salvador,
YASUAKI ISHIMATSU, Mathieu Malaterre
In-Reply-To: <70372ef5-e332-6c07-f08c-50f8808bde6d@gmail.com>
Am 03.09.18 um 02:36 schrieb Rashmica:
> Hi David,
>
>
> On 21/08/18 20:44, David Hildenbrand wrote:
>
>> There seem to be some problems as result of 30467e0b3be ("mm, hotplug:
>> fix concurrent memory hot-add deadlock"), which tried to fix a possible
>> lock inversion reported and discussed in [1] due to the two locks
>> a) device_lock()
>> b) mem_hotplug_lock
>>
>> While add_memory() first takes b), followed by a) during
>> bus_probe_device(), onlining of memory from user space first took b),
>> followed by a), exposing a possible deadlock.
>
> Do you mean "onlining of memory from user space first took a),
> followed by b)"?
Very right, thanks.
>
>> In [1], and it was decided to not make use of device_hotplug_lock, but
>> rather to enforce a locking order.
>>
>> The problems I spotted related to this:
>>
>> 1. Memory block device attributes: While .state first calls
>> mem_hotplug_begin() and the calls device_online() - which takes
>> device_lock() - .online does no longer call mem_hotplug_begin(), so
>> effectively calls online_pages() without mem_hotplug_lock.
>>
>> 2. device_online() should be called under device_hotplug_lock, however
>> onlining memory during add_memory() does not take care of that.
>>
>> In addition, I think there is also something wrong about the locking in
>>
>> 3. arch/powerpc/platforms/powernv/memtrace.c calls offline_pages()
>> without locks. This was introduced after 30467e0b3be. And skimming over
>> the code, I assume it could need some more care in regards to locking
>> (e.g. device_online() called without device_hotplug_lock - but I'll
>> not touch that for now).
>
> Can you mention that you fixed this in later patches?
Sure!
>
>
> The series looks good to me. Feel free to add my reviewed-by:
>
> Reviewed-by: Rashmica Gupta <rashmica.g@gmail.com>
>
Thanks, r-b only for this patch or all of the series?
--
Thanks,
David / dhildenb
^ permalink raw reply
* Re: [PATCH 01/12] powerpc/64s/hash: Fix stab_rr off by one initialization
From: Nicholas Piggin @ 2018-09-17 7:35 UTC (permalink / raw)
To: Joel Stanley; +Cc: linuxppc-dev, aneesh.kumar
In-Reply-To: <CACPK8XcEQdSbUN=bRECfWeV6ZR2Pm9LM5wB83GSmAr63NH1hpg@mail.gmail.com>
On Mon, 17 Sep 2018 16:21:51 +0930
Joel Stanley <joel@jms.id.au> wrote:
> On Sat, 15 Sep 2018 at 01:03, Nicholas Piggin <npiggin@gmail.com> wrote:
> >
> > This causes SLB alloation to start 1 beyond the start of the SLB.
allocation
> > There is no real problem because after it wraps it stats behaving
>
> starts?
>
> > properly, it's just surprisig to see when looking at SLB traces.
>
> surprising
My keyboard is dying :(
^ permalink raw reply
* [PATCH] powerpc: Disable -Wbuiltin-requires-header when setjmp is used
From: Joel Stanley @ 2018-09-17 7:46 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Nick Desaulniers
The powerpc kernel uses setjmp which causes a warning when building with
clang:
CC arch/powerpc/xmon/xmon.o
In file included from arch/powerpc/xmon/xmon.c:51:
./arch/powerpc/include/asm/setjmp.h:15:13: error: declaration of
built-in function 'setjmp' requires inclusion of the header <setjmp.h>
[-Werror,-Wbuiltin-requires-header]
extern long setjmp(long *);
^
./arch/powerpc/include/asm/setjmp.h:16:13: error: declaration of
built-in function 'longjmp' requires inclusion of the header <setjmp.h>
[-Werror,-Wbuiltin-requires-header]
extern void longjmp(long *, long);
^
This *is* the header and we're not using the built-in setjump but
rather the one in arch/powerpc/kernel/misc.S. As the compiler warning
does not make sense, it for the files where setjmp is used.
Signed-off-by: Joel Stanley <joel@jms.id.au>
---
We could instead disable this for all of the kernel as I don't think the
warning is going to ever provide useful information for the kernel.
arch/powerpc/kernel/Makefile | 3 +++
arch/powerpc/xmon/Makefile | 3 +++
2 files changed, 6 insertions(+)
diff --git a/arch/powerpc/kernel/Makefile b/arch/powerpc/kernel/Makefile
index 1e64cfe22a83..9845a94f5f68 100644
--- a/arch/powerpc/kernel/Makefile
+++ b/arch/powerpc/kernel/Makefile
@@ -7,6 +7,9 @@ CFLAGS_ptrace.o += -DUTS_MACHINE='"$(UTS_MACHINE)"'
subdir-ccflags-$(CONFIG_PPC_WERROR) := -Werror
+# Disable clang warning for using setjmp without setjmp.h header
+CFLAGS_crash.o += $(call cc-disable-warning, builtin-requires-header)
+
ifdef CONFIG_PPC64
CFLAGS_prom_init.o += $(NO_MINIMAL_TOC)
endif
diff --git a/arch/powerpc/xmon/Makefile b/arch/powerpc/xmon/Makefile
index 93cc1f1b8b61..a38db48f9f6d 100644
--- a/arch/powerpc/xmon/Makefile
+++ b/arch/powerpc/xmon/Makefile
@@ -14,6 +14,9 @@ ccflags-$(CONFIG_PPC64) := $(NO_MINIMAL_TOC)
obj-y += xmon.o nonstdio.o spr_access.o
+# Disable clang warning for using setjmp without setjmp.h header
+subdir-ccflags-y := $(call cc-disable-warning, builtin-requires-header)
+
ifdef CONFIG_XMON_DISASSEMBLY
obj-y += ppc-dis.o ppc-opc.o
obj-$(CONFIG_SPU_BASE) += spu-dis.o spu-opc.o
--
2.17.1
^ permalink raw reply related
* Re: [PATCH v2 11/24] powerpc/mm: don't use _PAGE_EXEC for calling hash_preload()
From: Aneesh Kumar K.V @ 2018-09-17 7:59 UTC (permalink / raw)
To: Christophe Leroy, Bartlomiej Zolnierkiewicz,
Benjamin Herrenschmidt, Dominik Brodowski, Geoff Levand,
Jens Axboe, Kumar Gala, Li Yang, Michael Ellerman,
Nicholas Piggin, Paul Mackerras, Scott Wood, aneesh.kumar
Cc: linux-arm-kernel, linux-block, linux-fbdev, linux-kernel,
linuxppc-dev, dri-devel
In-Reply-To: <4792a83ab79c6709d010ed4fec3b40242f46df33.1536692743.git.christophe.leroy@c-s.fr>
Christophe Leroy <christophe.leroy@c-s.fr> writes:
> The 'access' parameter of hash_preload() is either 0 or _PAGE_EXEC.
> Among the two versions of hash_preload(), only the PPC64 one is
> doing something with this 'access' parameter.
>
> In order to remove the use of _PAGE_EXEC outside platform code,
> 'access' parameter is replaced by 'is_exec' which will be either
> true of false, and the PPC64 version of hash_preload() creates
> the access flag based on 'is_exec'.
>
Reviewed-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
> Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
> ---
> arch/powerpc/mm/hash_utils_64.c | 3 ++-
> arch/powerpc/mm/mem.c | 9 +++++----
> arch/powerpc/mm/mmu_decl.h | 2 +-
> arch/powerpc/mm/pgtable_32.c | 2 +-
> arch/powerpc/mm/ppc_mmu_32.c | 2 +-
> 5 files changed, 10 insertions(+), 8 deletions(-)
>
> diff --git a/arch/powerpc/mm/hash_utils_64.c b/arch/powerpc/mm/hash_utils_64.c
> index f23a89d8e4ce..b8ce0e8cc608 100644
> --- a/arch/powerpc/mm/hash_utils_64.c
> +++ b/arch/powerpc/mm/hash_utils_64.c
> @@ -1482,7 +1482,7 @@ static bool should_hash_preload(struct mm_struct *mm, unsigned long ea)
> #endif
>
> void hash_preload(struct mm_struct *mm, unsigned long ea,
> - unsigned long access, unsigned long trap)
> + bool is_exec, unsigned long trap)
> {
> int hugepage_shift;
> unsigned long vsid;
> @@ -1490,6 +1490,7 @@ void hash_preload(struct mm_struct *mm, unsigned long ea,
> pte_t *ptep;
> unsigned long flags;
> int rc, ssize, update_flags = 0;
> + unsigned long access = _PAGE_PRESENT | _PAGE_READ | (is_exec ? _PAGE_EXEC : 0);
>
> BUG_ON(REGION_ID(ea) != USER_REGION_ID);
>
> diff --git a/arch/powerpc/mm/mem.c b/arch/powerpc/mm/mem.c
> index 31bd9b53c358..0ba0cdb3f759 100644
> --- a/arch/powerpc/mm/mem.c
> +++ b/arch/powerpc/mm/mem.c
> @@ -507,7 +507,8 @@ void update_mmu_cache(struct vm_area_struct *vma, unsigned long address,
> * We don't need to worry about _PAGE_PRESENT here because we are
> * called with either mm->page_table_lock held or ptl lock held
> */
> - unsigned long access, trap;
> + unsigned long trap;
> + bool is_exec;
>
> if (radix_enabled()) {
> prefetch((void *)address);
> @@ -529,16 +530,16 @@ void update_mmu_cache(struct vm_area_struct *vma, unsigned long address,
> trap = current->thread.regs ? TRAP(current->thread.regs) : 0UL;
> switch (trap) {
> case 0x300:
> - access = 0UL;
> + is_exec = false;
> break;
> case 0x400:
> - access = _PAGE_EXEC;
> + is_exec = true;
> break;
> default:
> return;
> }
>
> - hash_preload(vma->vm_mm, address, access, trap);
> + hash_preload(vma->vm_mm, address, is_exec, trap);
> #endif /* CONFIG_PPC_STD_MMU */
> #if (defined(CONFIG_PPC_BOOK3E_64) || defined(CONFIG_PPC_FSL_BOOK3E)) \
> && defined(CONFIG_HUGETLB_PAGE)
> diff --git a/arch/powerpc/mm/mmu_decl.h b/arch/powerpc/mm/mmu_decl.h
> index e5d779eed181..dd7f9b951d25 100644
> --- a/arch/powerpc/mm/mmu_decl.h
> +++ b/arch/powerpc/mm/mmu_decl.h
> @@ -82,7 +82,7 @@ static inline void _tlbivax_bcast(unsigned long address, unsigned int pid,
> #else /* CONFIG_PPC_MMU_NOHASH */
>
> extern void hash_preload(struct mm_struct *mm, unsigned long ea,
> - unsigned long access, unsigned long trap);
> + bool is_exec, unsigned long trap);
>
>
> extern void _tlbie(unsigned long address);
> diff --git a/arch/powerpc/mm/pgtable_32.c b/arch/powerpc/mm/pgtable_32.c
> index 0bbc7b7d8a05..01f348938328 100644
> --- a/arch/powerpc/mm/pgtable_32.c
> +++ b/arch/powerpc/mm/pgtable_32.c
> @@ -261,7 +261,7 @@ static void __init __mapin_ram_chunk(unsigned long offset, unsigned long top)
> map_kernel_page(v, p, ktext ? PAGE_KERNEL_TEXT : PAGE_KERNEL);
> #ifdef CONFIG_PPC_STD_MMU_32
> if (ktext)
> - hash_preload(&init_mm, v, 0, 0x300);
> + hash_preload(&init_mm, v, false, 0x300);
> #endif
> v += PAGE_SIZE;
> p += PAGE_SIZE;
> diff --git a/arch/powerpc/mm/ppc_mmu_32.c b/arch/powerpc/mm/ppc_mmu_32.c
> index bea6c544e38f..38a793bfca37 100644
> --- a/arch/powerpc/mm/ppc_mmu_32.c
> +++ b/arch/powerpc/mm/ppc_mmu_32.c
> @@ -163,7 +163,7 @@ void __init setbat(int index, unsigned long virt, phys_addr_t phys,
> * Preload a translation in the hash table
> */
> void hash_preload(struct mm_struct *mm, unsigned long ea,
> - unsigned long access, unsigned long trap)
> + bool is_exec, unsigned long trap)
> {
> pmd_t *pmd;
>
> --
> 2.13.3
^ permalink raw reply
* Re: [PATCH 03/12] powerpc/64s/hash: move POWER5 < DD2.1 slbie workaround where it is needed
From: Nicholas Piggin @ 2018-09-17 8:39 UTC (permalink / raw)
To: Aneesh Kumar K.V; +Cc: linuxppc-dev
In-Reply-To: <877ejkiryn.fsf@linux.ibm.com>
On Mon, 17 Sep 2018 11:30:16 +0530
"Aneesh Kumar K.V" <aneesh.kumar@linux.ibm.com> wrote:
> Nicholas Piggin <npiggin@gmail.com> writes:
>
> > The POWER5 < DD2.1 issue is that slbie needs to be issued more than
> > once. It came in with this change:
> >
> > ChangeSet@1.1608, 2004-04-29 07:12:31-07:00, david@gibson.dropbear.id.au
> > [PATCH] POWER5 erratum workaround
> >
> > Early POWER5 revisions (<DD2.1) have a problem requiring slbie
> > instructions to be repeated under some circumstances. The patch below
> > adds a workaround (patch made by Anton Blanchard).
>
> Thanks for extracting this. Can we add this to the code?
The comment? Sure.
> Also I am not
> sure what is repeated here? Is it that we just need one slb extra(hence
> only applicable to offset == 1) or is it that we need to make sure there
> is always one slb extra? The code does the former.
Yeah it has always done the former, so my assumption is that you just
need more than one slbie. I don't think we need to bother revisiting
that assumption unless someone can pull up something definitive.
What I did change is that slbia no longer has the additional slbie, but
I think there are strong reasons not to need that.
> Do you a have link for
> that email patch?
I tried looking through the archives around that date but could not
find it. That came from a bitkeeper log.
Thanks,
Nick
^ permalink raw reply
* Re: [PATCH 05/12] powerpc/64s/hash: Use POWER6 SLBIA IH=1 variant in switch_slb
From: Nicholas Piggin @ 2018-09-17 8:42 UTC (permalink / raw)
To: Aneesh Kumar K.V; +Cc: linuxppc-dev
In-Reply-To: <874leoirks.fsf@linux.ibm.com>
On Mon, 17 Sep 2018 11:38:35 +0530
"Aneesh Kumar K.V" <aneesh.kumar@linux.ibm.com> wrote:
> Nicholas Piggin <npiggin@gmail.com> writes:
>
> > The SLBIA IH=1 hint will remove all non-zero SLBEs, but only
> > invalidate ERAT entries associated with a class value of 1, for
> > processors that support the hint (e.g., POWER6 and newer), which
> > Linux assigns to user addresses.
> >
> > This prevents kernel ERAT entries from being invalidated when
> > context switchig (if the thread faulted in more than 8 user SLBEs).
>
>
> how about renaming stuff to indicate kernel ERAT entries are kept?
> something like slb_flush_and_rebolt_user()?
User mappings aren't bolted though. I consider rebolt to mean update
the bolted kernel mappings when something has changed (like vmalloc
segment update). That doesn't need to be done here, so I think this
is okay. I can add a comment though.
Thanks,
Nick
>
> >
> > Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
> > ---
> > arch/powerpc/mm/slb.c | 38 +++++++++++++++++++++++---------------
> > 1 file changed, 23 insertions(+), 15 deletions(-)
> >
> > diff --git a/arch/powerpc/mm/slb.c b/arch/powerpc/mm/slb.c
> > index a5e58f11d676..03fa1c663ccf 100644
> > --- a/arch/powerpc/mm/slb.c
> > +++ b/arch/powerpc/mm/slb.c
> > @@ -128,13 +128,21 @@ void slb_flush_all_realmode(void)
> > asm volatile("slbmte %0,%0; slbia" : : "r" (0));
> > }
> >
> > -static void __slb_flush_and_rebolt(void)
> > +void slb_flush_and_rebolt(void)
> > {
> > /* If you change this make sure you change SLB_NUM_BOLTED
> > * and PR KVM appropriately too. */
> > unsigned long linear_llp, lflags;
> > unsigned long ksp_esid_data, ksp_vsid_data;
> >
> > + WARN_ON(!irqs_disabled());
> > +
> > + /*
> > + * We can't take a PMU exception in the following code, so hard
> > + * disable interrupts.
> > + */
> > + hard_irq_disable();
> > +
> > linear_llp = mmu_psize_defs[mmu_linear_psize].sllp;
> > lflags = SLB_VSID_KERNEL | linear_llp;
> >
> > @@ -160,20 +168,7 @@ static void __slb_flush_and_rebolt(void)
> > :: "r"(ksp_vsid_data),
> > "r"(ksp_esid_data)
> > : "memory");
> > -}
> >
> > -void slb_flush_and_rebolt(void)
> > -{
> > -
> > - WARN_ON(!irqs_disabled());
> > -
> > - /*
> > - * We can't take a PMU exception in the following code, so hard
> > - * disable interrupts.
> > - */
> > - hard_irq_disable();
> > -
> > - __slb_flush_and_rebolt();
> > get_paca()->slb_cache_ptr = 0;
> > }
> >
> > @@ -248,7 +243,20 @@ void switch_slb(struct task_struct *tsk, struct mm_struct *mm)
> >
> > asm volatile("isync" : : : "memory");
> > } else {
> > - __slb_flush_and_rebolt();
> > + struct slb_shadow *p = get_slb_shadow();
> > + unsigned long ksp_esid_data =
> > + be64_to_cpu(p->save_area[KSTACK_INDEX].esid);
> > + unsigned long ksp_vsid_data =
> > + be64_to_cpu(p->save_area[KSTACK_INDEX].vsid);
> > +
> > + asm volatile("isync\n"
> > + PPC_SLBIA(1) "\n"
> > + "slbmte %0,%1\n"
> > + "isync"
> > + :: "r"(ksp_vsid_data),
> > + "r"(ksp_esid_data));
> > +
> > + asm volatile("isync" : : : "memory");
> > }
> >
> > get_paca()->slb_cache_ptr = 0;
> > --
> > 2.18.0
>
^ permalink raw reply
* Re: How to handle PTE tables with non contiguous entries ?
From: Aneesh Kumar K.V @ 2018-09-17 9:03 UTC (permalink / raw)
To: Christophe Leroy, akpm, linux-mm, aneesh.kumar, Nicholas Piggin,
Michael Ellerman, linuxppc-dev
Cc: LKML
In-Reply-To: <ddc3bb56-4da0-c093-256f-185d4a612b5c@c-s.fr>
Christophe Leroy <christophe.leroy@c-s.fr> writes:
> Hi,
>
> I'm having a hard time figuring out the best way to handle the following
> situation:
>
> On the powerpc8xx, handling 16k size pages requires to have page tables
> with 4 identical entries.
I assume that hugetlb page size? If so isn't that similar to FSL hugetlb
page table layout?
>
> Initially I was thinking about handling this by simply modifying
> pte_index() which changing pte_t type in order to have one entry every
> 16 bytes, then replicate the PTE value at *ptep, *ptep+1,*ptep+2 and
> *ptep+3 both in set_pte_at() and pte_update().
>
> However, this doesn't work because many many places in the mm core part
> of the kernel use loops on ptep with single ptep++ increment.
>
> Therefore did it with the following hack:
>
> /* PTE level */
> +#if defined(CONFIG_PPC_8xx) && defined(CONFIG_PPC_16K_PAGES)
> +typedef struct { pte_basic_t pte, pte1, pte2, pte3; } pte_t;
> +#else
> typedef struct { pte_basic_t pte; } pte_t;
> +#endif
>
> @@ -181,7 +192,13 @@ static inline unsigned long pte_update(pte_t *p,
> : "cc" );
> #else /* PTE_ATOMIC_UPDATES */
> unsigned long old = pte_val(*p);
> - *p = __pte((old & ~clr) | set);
> + unsigned long new = (old & ~clr) | set;
> +
> +#if defined(CONFIG_PPC_8xx) && defined(CONFIG_PPC_16K_PAGES)
> + p->pte = p->pte1 = p->pte2 = p->pte3 = new;
> +#else
> + *p = __pte(new);
> +#endif
> #endif /* !PTE_ATOMIC_UPDATES */
>
> #ifdef CONFIG_44x
>
>
> @@ -161,7 +161,11 @@ static inline void __set_pte_at(struct mm_struct
> *mm, unsigned long addr,
> /* Anything else just stores the PTE normally. That covers all
> 64-bit
> * cases, and 32-bit non-hash with 32-bit PTEs.
> */
> +#if defined(CONFIG_PPC_8xx) && defined(CONFIG_PPC_16K_PAGES)
> + ptep->pte = ptep->pte1 = ptep->pte2 = ptep->pte3 = pte_val(pte);
> +#else
> *ptep = pte;
> +#endif
>
>
>
> But I'm not too happy with it as it means pte_t is not a single type
> anymore so passing it from one function to the other is quite heavy.
>
>
> Would someone have an idea of an elegent way to handle that ?
>
> Thanks
> Christophe
Why would pte_update bother about updating all the 4 entries?. Can you
help me understand the issue?
-aneesh
^ permalink raw reply
* Re: How to handle PTE tables with non contiguous entries ?
From: Christophe LEROY @ 2018-09-17 9:47 UTC (permalink / raw)
To: Aneesh Kumar K.V, akpm, linux-mm, aneesh.kumar, Nicholas Piggin,
Michael Ellerman, linuxppc-dev
Cc: LKML
In-Reply-To: <87tvmoh4w9.fsf@linux.ibm.com>
Le 17/09/2018 à 11:03, Aneesh Kumar K.V a écrit :
> Christophe Leroy <christophe.leroy@c-s.fr> writes:
>
>> Hi,
>>
>> I'm having a hard time figuring out the best way to handle the following
>> situation:
>>
>> On the powerpc8xx, handling 16k size pages requires to have page tables
>> with 4 identical entries.
>
> I assume that hugetlb page size? If so isn't that similar to FSL hugetlb
> page table layout?
No, it is not for 16k hugepage size with a standard page size of 4k.
Here I'm trying to handle the case of CONFIG_PPC_16K_PAGES.
As of today, it is implemented by using the standard Linux page layout,
ie one PTE entry for each 16k page. This forbids the use the 8xx HW
assistance.
>
>>
>> Initially I was thinking about handling this by simply modifying
>> pte_index() which changing pte_t type in order to have one entry every
>> 16 bytes, then replicate the PTE value at *ptep, *ptep+1,*ptep+2 and
>> *ptep+3 both in set_pte_at() and pte_update().
>>
>> However, this doesn't work because many many places in the mm core part
>> of the kernel use loops on ptep with single ptep++ increment.
>>
>> Therefore did it with the following hack:
>>
>> /* PTE level */
>> +#if defined(CONFIG_PPC_8xx) && defined(CONFIG_PPC_16K_PAGES)
>> +typedef struct { pte_basic_t pte, pte1, pte2, pte3; } pte_t;
>> +#else
>> typedef struct { pte_basic_t pte; } pte_t;
>> +#endif
>>
>> @@ -181,7 +192,13 @@ static inline unsigned long pte_update(pte_t *p,
>> : "cc" );
>> #else /* PTE_ATOMIC_UPDATES */
>> unsigned long old = pte_val(*p);
>> - *p = __pte((old & ~clr) | set);
>> + unsigned long new = (old & ~clr) | set;
>> +
>> +#if defined(CONFIG_PPC_8xx) && defined(CONFIG_PPC_16K_PAGES)
>> + p->pte = p->pte1 = p->pte2 = p->pte3 = new;
>> +#else
>> + *p = __pte(new);
>> +#endif
>> #endif /* !PTE_ATOMIC_UPDATES */
>>
>> #ifdef CONFIG_44x
>>
>>
>> @@ -161,7 +161,11 @@ static inline void __set_pte_at(struct mm_struct
>> *mm, unsigned long addr,
>> /* Anything else just stores the PTE normally. That covers all
>> 64-bit
>> * cases, and 32-bit non-hash with 32-bit PTEs.
>> */
>> +#if defined(CONFIG_PPC_8xx) && defined(CONFIG_PPC_16K_PAGES)
>> + ptep->pte = ptep->pte1 = ptep->pte2 = ptep->pte3 = pte_val(pte);
>> +#else
>> *ptep = pte;
>> +#endif
>>
>>
>>
>> But I'm not too happy with it as it means pte_t is not a single type
>> anymore so passing it from one function to the other is quite heavy.
>>
>>
>> Would someone have an idea of an elegent way to handle that ?
>>
>> Thanks
>> Christophe
>
> Why would pte_update bother about updating all the 4 entries?. Can you
> help me understand the issue?
Because the 8xx HW assistance expects 4 identical entries for each 16k
page, so everytime a PTE is updated the 4 entries have to be updated.
Christophe
^ permalink raw reply
* Re: [PATCH v2 05/17] compat_ioctl: move more drivers to generic_compat_ioctl_ptrarg
From: Jonathan Cameron @ 2018-09-17 9:33 UTC (permalink / raw)
To: Arnd Bergmann
Cc: viro, linux-fsdevel, Greg Kroah-Hartman, David S. Miller, devel,
linux-kernel, qat-linux, linux-crypto, linux-media, dri-devel,
linaro-mm-sig, amd-gfx, linux-input, linux-iio, linux-rdma,
linux-nvdimm, linux-nvme, linux-pci, platform-driver-x86,
linux-remoteproc, sparclinux, linux-scsi, linux-usb, linux-fbdev,
linuxppc-dev, linux-btrfs, ceph-devel, linux-wireless, netdev
In-Reply-To: <20180912151134.436719-1-arnd@arndb.de>
On Wed, 12 Sep 2018 17:08:52 +0200
Arnd Bergmann <arnd@arndb.de> wrote:
> The .ioctl and .compat_ioctl file operations have the same prototype so
> they can both point to the same function, which works great almost all
> the time when all the commands are compatible.
>
> One exception is the s390 architecture, where a compat pointer is only
> 31 bit wide, and converting it into a 64-bit pointer requires calling
> compat_ptr(). Most drivers here will ever run in s390, but since we now
> have a generic helper for it, it's easy enough to use it consistently.
>
> I double-checked all these drivers to ensure that all ioctl arguments
> are used as pointers or are ignored, but are not interpreted as integer
> values.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
For IIO part.
Acked-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Thanks,
> diff --git a/drivers/iio/industrialio-core.c b/drivers/iio/industrialio-core.c
> index a062cfddc5af..22844b94b0e9 100644
> --- a/drivers/iio/industrialio-core.c
> +++ b/drivers/iio/industrialio-core.c
> @@ -1630,7 +1630,7 @@ static const struct file_operations iio_buffer_fileops = {
> .owner = THIS_MODULE,
> .llseek = noop_llseek,
> .unlocked_ioctl = iio_ioctl,
> - .compat_ioctl = iio_ioctl,
> + .compat_ioctl = generic_compat_ioctl_ptrarg,
> };
>
^ permalink raw reply
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