[EXTERNAL] Re: [GIT PULL] Please pull powerpc/linux.git powerpc-5.9-1 tag

[Aneesh Kumar K.V]

On 8/8/20 12:44 AM, Al Viro wrote:
> On Fri, Aug 07, 2020 at 10:46:13AM -0700, Linus Torvalds wrote:
>> On Fri, Aug 7, 2020 at 6:14 AM Michael Ellerman <mpe at ellerman.id.au> wrote:
>>>
>>> Just one minor conflict, in a comment in drivers/misc/ocxl/config.c.
>>
>> Well, this morning I merged the ptrace ->regset_get() updates from Al,
>> and that brought in a different conflict.
>>
>> I _think_ I resolved it correctly, but while the new model is fairly
>> readable, the old one sure wasn't, and who knows how messed up my
>> attempt to sort it out was. I don't know the pkey details on powerpc..
>>
>> So I'd appreciate it if both Al and Aneesh Kumar would check that what
>> I did to pkey_get() in arch/powerpc/kernel/ptrace/ptrace-view.c makes
>> sense and works..
> 
> Grabbing...
> 
> Looks sane and yes, 3 membuf_store() instead of membuf_write() + membuf_store()
> would make sense (might even yield better code).  Up to ppc folks...
> 
>> Side note - it might have been cleaner to just make it do
>>
>>          membuf_store(&to, target->thread.amr);
>>          membuf_store(&to, target->thread.iamr);
>>          return membuf_store(&to, default_uamor);

That will also allow to get rid of

	BUILD_BUG_ON(TSO(amr) + sizeof(unsigned long) != TSO(iamr));

I will followup with a cleanup patch.


>>
>> instead of doing that membuf_write() for the first two ones and then
>> the membuf_store() for the uamor field, but I did what I did to keep
>> the logic as close to what it used to be as possible.
>>
>> If I messed up, I apologize.
>>
>> And if you agree that making it three membuf_store() instead of that
>> odd "depend on the exact order of the thread struct and pick two
>> consecutive values", I'll leave that to you as a separate cleanup.
>>
>>                     Linus


-aneesh