[OpenAFS] Re: RHEL 7.5 beta / 3.10.0-830.el7.x86_66 kernel lock up

[Stephan Wiesand]

> On 2. Feb 2018, at 09:55, Stephan Wiesand <stephan.wiesand@desy.de> =
wrote:
>=20
>=20
>> On 2. Feb 2018, at 02:14, Benjamin Kaduk <kaduk@mit.edu> wrote:
>>=20
>> On Thu, Feb 01, 2018 at 05:11:24PM +0100, Stephan Wiesand wrote:
>>> Comparing the 1.6.22.2 module builds from the SL packaging, where =
the kABI hashes of the used symbols are stored as a requirement, is =
seems none of those hashes changed between -693 and -830.
>>>=20
>>> There are two differences in the configure results:
>>>=20
>>> -ac_cv_linux_header_sched_signal_h=3Dno
>>> +ac_cv_linux_header_sched_signal_h=3Dyes
>>>=20
>>> -ac_cv_linux_struct_file_operations_has_iterate=3Dno
>>> +ac_cv_linux_struct_file_operations_has_iterate=3Dyes
>>=20
>> That's very helpful to know.
>>=20
>> Does the new tree actually have a sched/signal.h header?
>=20
> Yes it does. The only content is a guarded include of <linux/sched.h>
>=20
>> Does the new struct file_operations have an 'iterate' member
>> function?
>=20
> Yes it does, wrapped in a RH_KABI_ITERATE macro.

er, nonsense, that's RH_KABI_EXTEND, sorry

>=20
>> (The idea being to tell whether they changed something in new and
>> interesting ways or our configure test(s) are broken.)
>=20
> It's the former :-(