On Wed, Jun 20, 2018 at 04:35:16PM -0300, Breno Leitao wrote:
> Wire up io_pgetevents system call on powerpc.
>
> io_pgetevents is a new syscall to read asynchronous I/O events from the
> completion queue.
>
> Tested with libaio branch aio-poll[1] and the io_pgetevents test (#22) passed
> on both
Ram Pai writes:
> On Tue, Jun 19, 2018 at 10:39:52PM +1000, Michael Ellerman wrote:
>> Ram Pai writes:
>>
>> > In a multithreaded application, a key allocated by one thread must
>> > be activate and usable on all threads.
>> >
>> > Currently this is not the case, because the UAMOR bits for all k
Ram Pai writes:
> On Tue, Jun 19, 2018 at 10:39:56PM +1000, Michael Ellerman wrote:
>> Ram Pai writes:
>>
>> > When a thread forks the contents of AMR, IAMR, UAMOR registers in the
>> > newly forked thread are not inherited.
>> >
>> > Save the registers before forking, for content of those
>> >
Hi Robin/Greg k-h,
Will this patch-set be taken for the next kernel release (and via which tree)?
Thanks,
Nipun
> -Original Message-
> From: Nipun Gupta
> Sent: Sunday, May 20, 2018 7:20 PM
> To: robin.mur...@arm.com; will.dea...@arm.com; robh...@kernel.org;
> r...@kernel.org; mark.rutl.
On 06/19/2018 09:22 AM, Joakim Tjernlund wrote:
-Original Message-
From: Linuxppc-dev
[mailto:linuxppc-dev-bounces+qiang.zhao=nxp@lists.ozlabs.org] On Behalf Of
Joakim Tjernlund
Sent: 2018年6月20日 0:22
To: York Sun ; linuxppc-dev
Subject: [PATCH] QE GPIO: Add qe_gpio_set_multiple
This
Hi Michael,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on powerpc/next]
[also build test ERROR on v4.18-rc1 next-20180620]
[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
On Sun, Jun 17, 2018 at 09:14:28PM +1000, Alexey Kardashevskiy wrote:
> At the moment we allocate the entire TCE table, twice (hardware part and
> userspace translation cache). This normally works as we normally have
> contigous memory and the guest will map entire RAM for 64bit DMA.
>
> However i
On Tue, Jun 19, 2018 at 10:34:22PM -0700, Ram Pai wrote:
> Key 2 is preallocated and reserved for execute-only key. In rare
> cases if key-2 is unavailable, mprotect(PROT_EXEC) will behave
> incorrectly. NOTE: mprotect(PROT_EXEC) uses execute-only key.
>
> Ensure key 2 is available for preallocati
Geert Uytterhoeven writes:
> On Tue, Jun 19, 2018 at 8:35 AM Michael Ellerman wrote:
>> Geert Uytterhoeven writes:
>> > On Mon, Jun 18, 2018 at 11:18 AM Geert Uytterhoeven
>> > wrote:
>> >> Below is the list of build error/warning regressions/improvements in
>> >> v4.18-rc1[1] compared to v4.17
[Sorry. File error. Previous copy was older version of file.]
hotplug/pmt: Call rebuild_sched_domains after applying changes
to update CPU associativity i.e. 'readd' CPUs. This is to
ensure that the deferred calls to arch_update_cpu_topology are
now reflected in the system data structures.
Sig
On Thu, 2018-06-21 at 10:28 +1000, Michael Ellerman wrote:
>
> That's true, though I think yours is the first report we've had of
> problems.
>
> The old behaviour relied on device tree ordering in nearly all cases, so
> you basically get whatever order your firmware happened to flatten the
> dev
migration/memory: This patch adds recognition for changes to the
associativity of memory blocks described by 'ibm,dynamic-memory-v2'
in order to update local and general kernel data structures to
reflect those changes. This patch builds upon previous enhancements
that scan the device-tree properti
migration/memory: This patch adds code that recognizes changes to
the associativity of memory blocks described by the device-tree
properties in order to drive equivalent 'hotplug' operations to
update local and general kernel data structures to reflect those
changes. These differences may include:
powerpc/drmem: Export many of the functions of DRMEM to parse
"ibm,dynamic-memory" and "ibm,dynamic-memory-v2" during hotplug
operations and for Post Migration events.
Also modify the DRMEM initialization code to allow it to,
* Be called after system initialization
* Provide a separate user copy
The migration of LPARs across Power systems affects many attributes
including that of the associativity of memory blocks. The patches
in this set execute when a system is coming up fresh upon a migration
target. They are intended to,
* Recognize changes to the associativity of memory recorded in
hotplug/pmt: Call rebuild_sched_domains after applying changes
to update CPU associativity i.e. 'readd' CPUs. This is to
ensure that the deferred calls to arch_update_cpu_topology are
now reflected in the system data structures.
Signed-off-by: Michael Bringmann
---
arch/powerpc/platforms/pserie
hotplug/rtas: Disable rtas_event_scan during device-tree property
updates after migration to reduce conflicts with changes propagated
to other parts of the kernel configuration, such as CPUs or memory.
Signed-off-by: Michael Bringmann
---
arch/powerpc/platforms/pseries/hotplug-cpu.c |4
powerpc/rtas: Provide mechanism by which the rtas_event_scan can
be disabled/re-enabled by other portions of the powerpc code.
Among other things, this simplifies the usage of locking mechanisms
for shared kernel resources.
Signed-off-by: Michael Bringmann
---
arch/powerpc/include/asm/rtas.h |
pmt/numa: Disable arch_update_cpu_topology during post migration
CPU readd updates when evaluating device-tree changes after LPM
to avoid thread deadlocks trying to update node assignments.
System timing between all of the threads and timers restarted in
a migrated system overlapped frequently allo
numa: Provide mechanism to disable/enable operation of
arch_update_cpu_topology/numa_update_cpu_topology. This is
a simple tool to eliminate some avenues for thread deadlock
observed during system execution.
Signed-off-by: Michael Bringmann
---
arch/powerpc/include/asm/topology.h | 10 +++
mobility/numa: Ensure that numa_update_cpu_topology() can not be
entered multiple times concurrently. It may be accessed through
many different paths / concurrent work functions, and the lock
ordering may be difficult to ensure otherwise.
Signed-off-by: Michael Bringmann
---
arch/powerpc/mm/num
powerpc/dlpar: Provide hotplug CPU 'readd by index' operation to
support LPAR Post Migration state updates. When such changes are
invoked by the PowerPC 'mobility' code, they will be queued up so
that modifications to CPU properties will take place after the new
property value is written to the de
migration/dlpar: This patch adds function dlpar_queue_action()
which will queued up information about a CPU/Memory 'readd'
operation according to resource type, action code, and DRC index.
At a subsequent point, the list of operations can be run/played
in series. Examples of such oprations include
powerpc/cpu: Modify dlpar_cpu_add and dlpar_cpu_remove to allow the
skipping of DRC index acquire or release operations during the CPU
add or remove operations. This is intended to support subsequent
changes to provide a 'CPU readd' operation.
Signed-off-by: Michael Bringmann
---
Changes in patc
On Tue, Jun 19, 2018 at 05:25:09PM -0700, Randy Dunlap wrote:
> On 06/19/2018 05:15 PM, Ricardo Neri wrote:
> > On Sat, Jun 16, 2018 at 03:24:49PM +0200, Thomas Gleixner wrote:
> >> On Fri, 15 Jun 2018, Ricardo Neri wrote:
> >>> On Fri, Jun 15, 2018 at 11:19:09AM +0200, Thomas Gleixner wrote:
> >>>
The migration of LPARs across Power systems affects many attributes
including that of the associativity of CPUs. The patches in this
set execute when a system is coming up fresh upon a migration target.
They are intended to,
* Recognize changes to the associativity of CPUs recorded in internal
Ram Pai writes:
> On Tue, Jun 19, 2018 at 10:40:13PM +1000, Michael Ellerman wrote:
>> Ram Pai writes:
>>
>> > execute-only key is allocated dynamically. This is a problem. When a
>> > thread implicitly creates a execute-only key, and resets UAMOR for that
>> > key, the UAMOR value does not per
Hi Daniel,
Sorry we broke things for you.
Daniel Walker writes:
> On 06/19/2018 09:26 AM, Guilherme G. Piccoli wrote:
>>> [...]
>>> What your doing is changing the phb_id to some transformation of "reg" for
>>> all platforms except which have "ibm,opal-phbid". This is what we observe.
>>> This i
Hi Masahiro,
On Thu, Jun 21, 2018 at 08:21:01AM +0900, Masahiro Yamada wrote:
> V2 is good except one nit.
> (I left a comment in it)
Thanks, and yes I agree with your comment that the GCC<4.6 __diag()
definition can be removed.
> I can fix it up locally if it is tedious to re-spin, though.
If
2018-06-20 4:02 GMT+09:00 Paul Burton :
> Hi Masahiro,
>
> On Wed, Jun 20, 2018 at 02:34:35AM +0900, Masahiro Yamada wrote:
>> 2018-06-16 9:53 GMT+09:00 Paul Burton :
>> > diff --git a/include/linux/compiler-gcc.h b/include/linux/compiler-gcc.h
>> > index f1a7492a5cc8..aba64a2912d8 100644
>> > ---
Hi.
2018-06-20 5:14 GMT+09:00 Paul Burton :
> From: Arnd Bergmann
>
> I have occasionally run into a situation where it would make sense to
> control a compiler warning from a source file rather than doing so from
> a Makefile using the $(cc-disable-warning, ...) or $(cc-option, ...)
> helpers.
There is a buffer overflow in dscr_inherit_test.c test. In main(), strncpy()'s
third argument is the lengh of the source, not the size of the destination
buffer, which makes strncpy() behaves like strcpy(), causing a buffer overflow
if argv[0] is bigger than LEN_MAX (100).
This patch simply limit
Wire up io_pgetevents system call on powerpc.
io_pgetevents is a new syscall to read asynchronous I/O events from the
completion queue.
Tested with libaio branch aio-poll[1] and the io_pgetevents test (#22) passed
on both ppc64 LE and BE modes.
[1] https://pagure.io/libaio/branch/aio-poll
CC: C
In commit 4aea909eeba3 ("powerpc: Add missing prototypes in setup_32.c")
prototypes for
- ppc_setup_l2cr
- ppc_setup_l3cr
- ppc_init
were added but at the same time in commit d15a261d876d ("powerpc/32: Make
some functions static") those same functions were made static. Fix
conflicting changes by
On 06/13/2018 05:45 PM, Ram Pai wrote:
> Ensure pkey-0 is allocated on start. Ensure pkey-0 can be attached
> dynamically in various modes, without failures. Ensure pkey-0 can be
> freed and allocated.
I like this. Looks very useful.
Acked-by: Dave Hansen
On 06/13/2018 05:45 PM, Ram Pai wrote:
> Generally the signal handler restores the state of the pkey register
> before returning. However there are times when the read/write operation
> can legitamely fail without invoking the signal handler. Eg: A
> sys_read() operaton to a write-protected page s
On 06/13/2018 05:45 PM, Ram Pai wrote:
> +void test_read_of_access_disabled_region_with_page_already_mapped(int *ptr,
> + u16 pkey)
> +{
> + int ptr_contents;
> +
> + dprintf1("disabling access to PKEY[%02d], doing read @ %p\n",
> + pkey, ptr);
> +
On 06/13/2018 05:45 PM, Ram Pai wrote:
> /*
> - * There are 16 pkeys supported in hardware. Three are
> - * allocated by the time we get here:
> - * 1. The default key (0)
> - * 2. One possibly consumed by an execute-only mapping.
> - * 3. One allocated by the
> - if (cpu_has_pku()) {
> - dprintf1("SKIP: %s: no CPU support\n", __func__);
> + if (is_pkey_supported()) {
> + dprintf1("SKIP: %s: no CPU/kernel support\n", __func__);
> return;
> }
I actually kinda wanted a specific message for when the *CPU*
On 06/19/2018 02:40 PM, Michael Ellerman wrote:
I tested the whole series with the new selftests, with the printamr.c
program I posted earlier, and the glibc test for pkey_alloc &c. The
latter required some test fixes, but now passes as well. As far as I
can tell, everything looks good now.
Te
On 06/13/2018 05:45 PM, Ram Pai wrote:
> --- a/tools/testing/selftests/vm/protection_keys.c
> +++ b/tools/testing/selftests/vm/protection_keys.c
> @@ -577,7 +577,8 @@ int sys_pkey_free(unsigned long pkey)
> int ret = syscall(SYS_pkey_free, pkey);
>
> if (!ret)
> - shadow_p
> +static inline u32 *siginfo_get_pkey_ptr(siginfo_t *si)
> +{
> +#ifdef si_pkey
> + return &si->si_pkey;
> +#else
> + return (u32 *)(((u8 *)si) + si_pkey_offset);
> +#endif
> }
FWIW, this isn't ppc-specific.
> diff --git a/tools/testing/selftests/vm/protection_keys.c
> b/tools/testing
On 06/13/2018 05:45 PM, Ram Pai wrote:
> cleanup the code to satisfy coding styles.
A lot of this makes the code look worse and more unreadable than before.
I think someone just ran it through lindent or something.
I also took a few CodingStyle liberties in here because it's _not_ main
kernel co
On 06/13/2018 05:45 PM, Ram Pai wrote:
> +++ b/tools/testing/selftests/vm/protection_keys.c
> @@ -916,10 +916,10 @@ void expected_pkey_fault(int pkey)
> pkey_assert(last_si_pkey == pkey);
>
> /*
> - * The signal handler shold have cleared out PKEY register to let the
> +
On 06/13/2018 05:45 PM, Ram Pai wrote:
> When a key is freed, the key is no more effective.
> Clear the bits corresponding to the pkey in the shadow
> register. Otherwise it will carry some spurious bits
> which can trigger false-positive asserts.
...--- a/tools/testing/selftests/vm/protecti
On 06/13/2018 05:44 PM, Ram Pai wrote:
> If the flag is 0, no bits will be set. Hence we cant expect
> the resulting bitmap to have a higher value than what it
> was earlier
...
> if (flags)
> - pkey_assert(read_pkey_reg() > orig_pkey_reg);
> + pkey_assert(read_pkey_re
Le 19/06/2018 à 22:14, Paul Burton a écrit :
With SYSCALL_DEFINEx() disabling -Wattribute-alias generically, there's
no need to duplicate that for PowerPC syscalls.
This reverts commit 415520373975 ("powerpc: fix build failure by
disabling attribute-alias warning in pci_32") and commit 2479bf
Kernel pagetable pages for PTE fragments never go through the standard init
sequence which can cause inaccuracies in utilization statistics reported at
places like /proc and /sysfs interfaces etc. Also the allocated page misses
out on pagetable lock and page flag init as well. Fix it by making sure
Hi there,
For some reason I am seeing some new warning (W=0) on some old code.
Anyone else seeing them ?
HOSTCC arch/powerpc/boot/addnote
arch/powerpc/boot/addnote.c: In function ‘main’:
arch/powerpc/boot/addnote.c:75:47: warning: right shift count >= width
of type [-Wshift-count-overflow]
#d
On Wed, 20 Jun 2018, Benjamin Herrenschmidt wrote:
> > I love the alleged line removal, but there's nothing in that 'merge'
> > branch. It points to an ancient powerpc commit from 2016.
> >
> > And please, signed tags. I know you do them, because you used to send me
> > them.
>
> I didn't send
On Tue, Jun 19, 2018 at 04:29:35PM +, York Sun wrote:
> Joakim,
>
> I am not the maintainer for this driver. Adding Mark Brown.
>
> York
>
> On 06/19/2018 09:23 AM, Joakim Tjernlund wrote:
> > espi does not look for a OF cell-index property which
> > makes the bus numbering dynamic only. Thi
On 06/20/2018 02:52 PM, Anshuman Khandual wrote:
Kernel pagetable pages for PTE fragments never go through the standard init
sequence which can cause inaccuracies in utilization statistics reported at
places like /proc and /sysfs interfaces etc. Also the allocated page misses
out on pagetable loc
Kernel pagetable pages for PTE fragments never go through the standard init
sequence which can cause inaccuracies in utilization statistics reported at
places like /proc and /sysfs interfaces etc. Also the allocated page misses
out on pagetable lock and page flag init as well. Fix it by making sure
tree: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git merge
head: 6f4c6f50edb82c36e84df8528760998b1ed6b6cb
commit: 076674a524241b30bbff9e8d45e5dbdcea39cada [116/158] Automatic merge of
branches 'master', 'next' and 'fixes' into merge
config: ia64-allmodconfig (attached as .co
When attaching a hardware table to LIOBN in KVM, we match table parameters
such as page size, table offset and table size. However the tables are
created via very different paths - VFIO and KVM - and the VFIO path goes
through the platform code which has minimum TCE page size requirement
(which is
On Tue, 19 Jun 2018, Ricardo Neri wrote:
> On Sat, Jun 16, 2018 at 03:24:49PM +0200, Thomas Gleixner wrote:
> > The status register is useless in case of MSI. MSI is edge triggered
> >
> > The only register which gives you proper information is the counter
> > register itself. That adds an ma
On Tue, Jun 19, 2018 at 4:04 PM Arnd Bergmann wrote:
>
> As Mathieu pointed out, my conversion to time64_t was incorrect and resulted
> in negative times to be read from the RTC. The problem is that during the
> conversion from a byte array to a time64_t, the 'unsigned char' variable
> holding the
57 matches
Mail list logo
