Received-SPF: softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) client-ip=23.128.96.19;
Message-ID: <29829c01-f31e-2c4f-06e9-fc15c0261f93@canonical.com>
Date:   Fri, 6 May 2022 15:15:09 -0400
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101
 Thunderbird/91.8.1
Subject: Re: Issue With real-time patches on 5.15.y
Content-Language: en-US
To:     Dave Hansen <dave.hansen@intel.com>, tglx@linutronix.de
Cc:     linux-kernel@vger.kernel.org, dave.hansen@linux.intel.com,
        linux-rt-users@vger.kernel.org
References: <bdb23fe5-51ae-8873-a3d7-85f377877c79@canonical.com>
 <32803e0b-8ff6-ae8d-f9cb-ce2d3fd37229@intel.com>
From:   Joseph Salisbury <joseph.salisbury@canonical.com>
In-Reply-To: <32803e0b-8ff6-ae8d-f9cb-ce2d3fd37229@intel.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Precedence: bulk


On 5/5/22 19:35, Dave Hansen wrote:
> On 5/5/22 16:18, Joseph Salisbury wrote:
>> The real-time kernel build failure can be resolved by reverting commit
>> b50854eca0e0.  The failure seems to be due to the removal of an include
>> of xstate.h from pkru.h and caused spinlock_t to not be defined.  The
>> commit would only be reverted for the real-time kernel and not any other
>> kernels.  I wanted to see if reverting the commit is the proper
>> approach, or if cherry-picking additional commits might be a better
>> solution in preparation for additional changes that might be coming in
>> the future?
>>
>> Any suggestions would be greatly appreciated.
> I thought you distro folks were the franenkernel experts. :)
>
> But, seriously...  This isn't rocket science.  Just look at the pkru.h
> in your tree and figure out what includes it needs.  If it needs FPU
> gunk, include the FPU header.  If you get a compile error for spinlock_t
> ...  well ...  find the code using spinlock_t and make sure it includes
> spinlock.h.
>
Thanks for the advice, Dave.

Your suggestion will probably be the easiest approach.  I was just 
trying to limit the amount of frankenkernel changes, since there are 
already so many  :-)  It's always best to stay as close to mainline as 
possible.