Skip to content

gh-83714: Check for struct statx.stx_atomic_write_unit_max_opt in configure#140185

Merged
vstinner merged 1 commit into
python:mainfrom
jbosboom:statx-atomic-write-unit-max-opt
Oct 16, 2025
Merged

gh-83714: Check for struct statx.stx_atomic_write_unit_max_opt in configure#140185
vstinner merged 1 commit into
python:mainfrom
jbosboom:statx-atomic-write-unit-max-opt

Conversation

@jbosboom
Copy link
Copy Markdown
Contributor

@jbosboom jbosboom commented Oct 16, 2025 •
edited by github-actions Bot
Loading

stx_atomic_write_unit_max_opt was added in Linux 6.16, but is controlled by the STATX_WRITE_ATOMIC mask bit added in Linux 6.11. That's safe at runtime because all kernels clear the reserved space in struct statx and zero is a valid value for stx_atomic_write_unit_max_opt, and it avoids allocating another mask bit, which are a limited resource. But it also means the kernel headers don't provide a way to check whether stx_atomic_write_unit_max_opt exists, so add a configure check.

I ran make regen-configure. I know very little about autoconf, so please check I didn't mess up.

📚 Documentation preview 📚: https://cpython-previews--140185.org.readthedocs.build/

@jbosboom
Check for struct statx.stx_atomic_write_unit_max_opt in configure
37ebb56 
stx_atomic_write_unit_max_opt was added in Linux 6.16, but is controlled
by the STATX_WRITE_ATOMIC mask bit added in Linux 6.11.  That's safe at
runtime because all kernels clear the reserved space in struct statx and
zero is a valid value for stx_atomic_write_unit_max_opt, and it avoids
allocating another mask bit, which are a limited resource.  But it also
means the kernel headers don't provide a way to check whether
stx_atomic_write_unit_max_opt exists, so add a configure check.
@bedevere-app bedevere-app Bot mentioned this pull request Oct 16, 2025
Closed
@jbosboom
Copy link
Copy Markdown
Contributor Author

jbosboom commented Oct 16, 2025

!buildbot AMD64 CentOS9 NoGIL 3.x

@bedevere-bot
Copy link
Copy Markdown

bedevere-bot commented Oct 16, 2025

You don't have write permissions to trigger a build

@jbosboom jbosboom mentioned this pull request Oct 16, 2025
Merged
@jbosboom
Copy link
Copy Markdown
Contributor Author

jbosboom commented Oct 16, 2025

#139178 failed on the AMD64 CentOS9 NoGIL 3.x (tier-1), ARM64 Raspbian Debug 3.x (tier-3) and ARM Raspbian 3.x (tier-3) buildbots. I need someone with the appropriate permissions to run those before merging.

This should be skip-news.

cmaloney
cmaloney reviewed Oct 16, 2025
View reviewed changes
Copy link
Copy Markdown
Contributor

@cmaloney cmaloney left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This seems like a reasonable approach to me; a core dev can trigger the bots to validate (although the queue can take a while to get to the top of).

I think skip news works as this is falls under "If a change is a fix (or other adjustment) to an earlier unreleased change and the original NEWS entry remains valid, then no additional entry is needed."

@encukou

This comment was marked as outdated.

Sign in to view
@bedevere-bot

This comment was marked as outdated.

Sign in to view
@encukou

This comment was marked as outdated.

Sign in to view
1 similar comment
@encukou
Copy link
Copy Markdown
Member

encukou commented Oct 16, 2025

!buildbot AMD64.CentOS9.NoGIL