[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <8373c730-2e08-4abb-8d21-fd9a76116d2c@redhat.com>
Date: Fri, 3 May 2024 18:13:38 -0400
From: Waiman Long <longman@...hat.com>
To: David Laight <David.Laight@...LAB.COM>,
"'linux-kernel@...r.kernel.org'" <linux-kernel@...r.kernel.org>,
"'peterz@...radead.org'" <peterz@...radead.org>
Cc: "'mingo@...hat.com'" <mingo@...hat.com>,
"'will@...nel.org'" <will@...nel.org>,
"'boqun.feng@...il.com'" <boqun.feng@...il.com>,
'Linus Torvalds' <torvalds@...ux-foundation.org>,
"'virtualization@...ts.linux-foundation.org'"
<virtualization@...ts.linux-foundation.org>,
'Zeng Heng' <zengheng4@...wei.com>
Subject: Re: [PATCH next v2 5/5] locking/osq_lock: Optimise decode_cpu() and
per_cpu_ptr().
On 5/3/24 17:10, David Laight wrote:
> From: Waiman Long
>> Sent: 03 May 2024 17:00
> ...
>> David,
>>
>> Could you respin the series based on the latest upstream code?
> I've just reapplied the patches to 'master' and they all apply
> cleanly and diffing the new patches to the old ones gives no differences.
> So I think they should still apply.
>
> Were you seeing a specific problem?
>
> I don't remember any suggested changed either.
> (Apart from a very local variable I used to keep a patch isolated.)
No, I just want to make sure that your patches will still apply. Anyway,
it will be easier for the maintainer to merge your remaining patches if
you can send out a new version even if they are almost the same as the
old ones.
Thanks,
Longman
Powered by blists - more mailing lists