On 2019-07-13, Al Viro wrote:
> On Fri, Jul 12, 2019 at 04:00:26PM +0100, Al Viro wrote:
> > On Fri, Jul 12, 2019 at 02:25:53PM +0100, Al Viro wrote:
> >
> > > if (flags & LOOKUP_BENEATH) {
> > > nd->root = nd->path;
> > > if (!(flags & LOOKUP_RCU))
> > > p
On 2019-07-12, Al Viro wrote:
> On Fri, Jul 12, 2019 at 10:20:17PM +1000, Aleksa Sarai wrote:
> > On 2019-07-12, Al Viro wrote:
> > > On Sun, Jul 07, 2019 at 12:57:28AM +1000, Aleksa Sarai wrote:
> > > > @@ -514,7 +516,14 @@ static void set_nameidata(struct nameidata *p, int
> > > > dfd, struct
On 2019-07-12, Al Viro wrote:
> On Fri, Jul 12, 2019 at 01:55:52PM +0100, Al Viro wrote:
> > On Fri, Jul 12, 2019 at 01:39:24PM +0100, Al Viro wrote:
> > > On Fri, Jul 12, 2019 at 08:57:45PM +1000, Aleksa Sarai wrote:
> > >
> > > > > > @@ -2350,9 +2400,11 @@ static const char *path_init(struct
>
https://bugzilla.kernel.org/show_bug.cgi?id=200055
--- Comment #15 from Erhard F. (erhar...@mailbox.org) ---
Created attachment 283675
--> https://bugzilla.kernel.org/attachment.cgi?id=283675&action=edit
dmesg.txt (G5 11,2 + kernel 4.9.184)
By running some older kernels from the stable series I
https://bugzilla.kernel.org/show_bug.cgi?id=200055
--- Comment #16 from Erhard F. (erhar...@mailbox.org) ---
Created attachment 283677
--> https://bugzilla.kernel.org/attachment.cgi?id=283677&action=edit
dmesg.txt (G5 11,2 + kernel 4.14.132)
--
You are receiving this mail because:
You are watc
https://bugzilla.kernel.org/show_bug.cgi?id=200055
--- Comment #17 from Erhard F. (erhar...@mailbox.org) ---
Created attachment 283679
--> https://bugzilla.kernel.org/attachment.cgi?id=283679&action=edit
4.9.184 kernel .config (G5 11,2)
--
You are receiving this mail because:
You are watching
https://bugzilla.kernel.org/show_bug.cgi?id=200055
Erhard F. (erhar...@mailbox.org) changed:
What|Removed |Added
Attachment #281901|0 |1
is obsolete|
On Sun, Jul 14, 2019 at 05:00:29PM +1000, Aleksa Sarai wrote:
> The basic property being guaranteed by LOOKUP_IN_ROOT is that it will
> not result in resolution of a path component which was not inside the
> root of the dirfd tree at some point during resolution (and that all
> absolute symlink an
Hi Jon,
Thanks for quick response!
在 2019/7/13 上午1:34, Jonathan Corbet 写道:
> On Fri, 12 Jul 2019 10:20:07 +0800
> Alex Shi wrote:
>
>> There are many different archs in Documentation/ dir, it's better to
>> move them together in 'Documentation/arch' which follows from kernel source.
>
> So thi
A while ago Arnd made it possible to give new system calls the same
syscall number on all architectures (except alpha). To not break this
nice new feature let's mark 435 for clone3 as reserved on all
architectures that do not yet implement it.
Even if an architecture does not plan to implement it t
On 14/07/2019 03:31, Benjamin Herrenschmidt wrote:
> On Sat, 2019-07-13 at 18:53 +1000, Alexey Kardashevskiy wrote:
>>
>> On 13/07/2019 09:47, Benjamin Herrenschmidt wrote:
>>> On Fri, 2019-07-12 at 19:37 +1000, Alexey Kardashevskiy wrote:
>>>
>>>
> https://git.kernel.org/pub/scm/linux/kernel/
This patch fixed an issue I was experiencing with virsh start/destroy
of guests with mlx5 and GPU passthrough in a Power 9 server. I
believe it's a similar situation which Alexey described in the post
commit msg.
Tested-by: Daniel Henrique Barboza
On 7/12/19 5:20 AM, Alexey Kardashevskiy wrot
Change all phy-connection-type properties to phy-mode that are better
supported by the fman driver.
Use the more readable fixed-link node for the 2 sgmii links.
Change the RGMII link to rgmii-id as the clock delays are added by the
phy.
Signed-off-by: Valentin Longchamp
---
arch/powerpc/boot/d
On Sun, 2019-07-14 at 21:44 +0200, Cédric Le Goater wrote:
> > Well, best is probably to do just that though, but call it something
> > like ppc_md.orphan_irq() or something like that instead. Another option
> > as you mention is to try to scrub queues, but that's trickier to do due
> > to the lock
On 7/11/19 9:57 AM, Michael Ellerman wrote:
> Claudio Carvalho writes:
>> When the ultravisor firmware is available, it takes control over the
>> LDBAR register. In this case, thread-imc updates and save/restore
>> operations on the LDBAR register are handled by ultravisor.
> Please roll up the
On Fri, 2019-07-12 at 23:09 +1000, Michael Ellerman wrote:
> Suraj Jitindar Singh writes:
> > The virtual real mode addressing (VRMA) mechanism is used when a
> > partition is using HPT (Hash Page Table) translation and performs
> > real mode accesses (MSR[IR|DR] = 0) in non-hypervisor mode. In th
On Sat, 2019-07-13 at 13:47 +1000, Michael Ellerman wrote:
> Suraj Jitindar Singh writes:
> > The performance monitoring unit (PMU) registers are saved on guest
> > exit
> > when the guest has set the pmcregs_in_use flag in its lppaca, if it
> > exists, or unconditionally if it doesn't. If a neste
Suraj Jitindar Singh writes:
> On Fri, 2019-07-12 at 23:09 +1000, Michael Ellerman wrote:
>> Suraj Jitindar Singh writes:
>> > The virtual real mode addressing (VRMA) mechanism is used when a
>> > partition is using HPT (Hash Page Table) translation and performs
>> > real mode accesses (MSR[IR|DR
Suraj Jitindar Singh writes:
> On Sat, 2019-07-13 at 13:47 +1000, Michael Ellerman wrote:
>> Suraj Jitindar Singh writes:
...
>> >
>> > Fixes: 95a6432ce903 "KVM: PPC: Book3S HV: Streamlined guest
>> > entry/exit path on P9 for radix guests"
>>
>> I'm not clear why this and the next commit are m
On 15/07/2019 05:14, Daniel Henrique Barboza wrote:
This patch fixed an issue I was experiencing with virsh start/destroy
of guests with mlx5 and GPU passthrough in a Power 9 server. I
believe it's a similar situation which Alexey described in the post
commit msg.
Tested-by: Daniel Henrique
Claudio Carvalho writes:
> On 7/11/19 9:57 AM, Michael Ellerman wrote:
>> Claudio Carvalho writes:
>>> diff --git a/arch/powerpc/include/asm/ultravisor.h
>>> b/arch/powerpc/include/asm/ultravisor.h
>>> new file mode 100644
>>> index ..e5009b0d84ea
>>> --- /dev/null
>>> +++ b/arch/pow
Claudio Carvalho writes:
> On 7/11/19 9:57 AM, Michael Ellerman wrote:
>> Claudio Carvalho writes:
>>> From: Ram Pai
>>>
>>> Add the ucall() function, which can be used to make ultravisor calls
>>> with varied number of in and out arguments. Ultravisor calls can be made
>>> from the host or gues
On Tue, 2019-07-02 at 10:58:36 UTC, Madhavan Srinivasan wrote:
> From: Athira Rajeev
>
> commit 10d91611f426 ("powerpc/64s: Reimplement book3s idle code in C")
> reimplemented book3S code to pltform/powernv/idle.c. But when doing so
> missed to add the per-thread LDBAR update in the core_woken pa
On Wed, 2019-07-10 at 15:05:17 UTC, Oliver O'Halloran wrote:
> In commit 4a7b06c157a2 ("powerpc/eeh: Handle hugepages in ioremap
> space") support for using hugepages in the vmalloc and ioremap areas was
> enabled for radix. Unfortunately this broke EEH MMIO error checking.
>
> Detection works by
On 7/11/19 10:23 AM, Michael Ellerman wrote:
Hi Maddy,
Madhavan Srinivasan writes:
diff --git a/arch/powerpc/platforms/powernv/opal-imc.c
b/arch/powerpc/platforms/powernv/opal-imc.c
index 186109bdd41b..e04b20625cb9 100644
--- a/arch/powerpc/platforms/powernv/opal-imc.c
+++ b/arch/powerpc/pl
Qian Cai writes:
> At the beginning of setup_64.c, it has,
>
> #ifdef DEBUG
> #define DBG(fmt...) udbg_printf(fmt)
> #else
> #define DBG(fmt...)
> #endif
>
> where DBG() could be compiled away, and generate warnings,
>
> arch/powerpc/kernel/setup_64.c: In function 'initialize_cache_info'
Christophe Leroy writes:
> PPC32 also have flush_dcache_range() so it can also support
> ARCH_HAS_PMEM_API and ARCH_HAS_UACCESS_FLUSHCACHE without changes.
>
> Signed-off-by: Christophe Leroy
> ---
> arch/powerpc/Kconfig | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git
27 matches
Mail list logo