Re: [PATCH RFC v3 02/10] sched_getattr: port to copy_struct_to_user

* Xi Ruoyao:

On Wed, 2024-12-11 at 11:23 +0100, Christian Brauner wrote:

quoted

On Tue, Dec 10, 2024 at 07:14:07PM +0100, Florian Weimer wrote:

quoted

* Aleksa Sarai:

quoted

sched_getattr(2) doesn't care about trailing non-zero bytes in the
(ksize > usize) case, so just use copy_struct_to_user() without checking
ignored_trailing.

I think this is what causes glibc's misc/tst-sched_setattr test to fail
on recent kernels.  The previous non-modifying behavior was documented
in the manual page:

       If the caller-provided attr buffer is larger than the kernel's
       sched_attr structure, the additional bytes in the user-space
       structure are not touched.

I can just drop this part of the test if the kernel deems both behaviors
valid.

quoted

I think in general both behaviors are valid but I would consider zeroing
the unknown parts of the provided buffer to be the safer option. And all
newer extensible struct system calls do that.

Florian,

So should we drop the test before Glibc-2.41 release?  I'm seeing the
failure during my machine test.

I was waiting for a verdict from the kernel developers.  I didn't expect
such a change to happen given the alleged UAPI policy.

Thanks,
Florian

On Mon, 2025-01-20 at 06:28 +0100, Florian Weimer wrote:

* Xi Ruoyao:

quoted

On Wed, 2024-12-11 at 11:23 +0100, Christian Brauner wrote:

quoted

On Tue, Dec 10, 2024 at 07:14:07PM +0100, Florian Weimer wrote:

quoted

* Aleksa Sarai:

quoted

sched_getattr(2) doesn't care about trailing non-zero bytes in the
(ksize > usize) case, so just use copy_struct_to_user() without checking
ignored_trailing.

I think this is what causes glibc's misc/tst-sched_setattr test to fail
on recent kernels.  The previous non-modifying behavior was documented
in the manual page:

       If the caller-provided attr buffer is larger than the kernel's
       sched_attr structure, the additional bytes in the user-space
       structure are not touched.

I can just drop this part of the test if the kernel deems both behaviors
valid.

quoted

I think in general both behaviors are valid but I would consider zeroing
the unknown parts of the provided buffer to be the safer option. And all
newer extensible struct system calls do that.

Florian,

So should we drop the test before Glibc-2.41 release?  I'm seeing the
failure during my machine test.

I was waiting for a verdict from the kernel developers.  I didn't expect
such a change to happen given the alleged UAPI policy.

But 6.13 is already released without reverting the behavior change
now...  So is this the "final" verdict?

-- 
Xi Ruoyao [off-list ref]
School of Aerospace Science and Technology, Xidian University