Bug 2304043 - libatasmart broken by kernel 6.10
Summary: libatasmart broken by kernel 6.10
Keywords:
Status: ASSIGNED
Alias: None
Product: Fedora
Classification: Fedora
Component: libatasmart
Version: 40
Hardware: x86_64
OS: Linux
unspecified
medium
Target Milestone: ---
Assignee: Lennart Poettering
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2024-08-11 20:38 UTC by Ian Pilcher
Modified: 2024-08-19 21:03 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed:
Type: ---
Embargoed:


Attachments (Terms of Use)
strace output from kernel 6.9 (works) (33.10 KB, text/plain)
2024-08-11 20:39 UTC, Ian Pilcher
no flags Details
strace output from kernel 6.10 (doesn't work) (31.39 KB, text/plain)
2024-08-11 20:40 UTC, Ian Pilcher
no flags Details

Description Ian Pilcher 2024-08-11 20:38:55 UTC
After updating to kernel 6.10, libatasmart does not work.  Calls to sk_disk_smart_read_data() that previously worked now fail and set errno to ENOTSUP (operation not supported).

The program here demonstrates the issue.

https://github.com/ipilcher/n5550/tree/master/freecusd/smart

On kernel 6.9, running 'sudo ./helper /dev/sda' will print two integers and exit successfully; on kernel 6.10, it will print an error message an exit unsuccessfully.

Reproducible: Always

Comment 1 Ian Pilcher 2024-08-11 20:39:54 UTC
Created attachment 2043948 [details]
strace output from kernel 6.9 (works)

Comment 2 Ian Pilcher 2024-08-11 20:40:41 UTC
Created attachment 2043949 [details]
strace output from kernel 6.10 (doesn't work)

Comment 3 Ian Pilcher 2024-08-11 21:58:36 UTC
I've managed to trace the failure to the check at line 428 of atasmart.c (in disk_passthrough_16_command()).  On kernel 6.10, sense[0] is 0xf0 (not 0x72), and desc[0] and desc[1] are both 0 (not 0x9 and 0xc respectively).

Comment 4 Ian Pilcher 2024-08-12 14:44:10 UTC
Curiouser and curiouser.  This issue doesn't reproduce on a vanilla kernel 6.10.0.

Comment 5 Ian Pilcher 2024-08-12 15:49:49 UTC
Issue is present in vanilla 6.11-rc3.

Comment 6 Ian Pilcher 2024-08-12 22:31:07 UTC
Kernel bisect shows that this was broken by this commit.

https://github.com/torvalds/linux/commit/28ab9769117ca944cb6eb537af5599aa436287a4

Comment 7 Ian Pilcher 2024-08-13 14:57:15 UTC
(In reply to Ian Pilcher from comment #6)
> Kernel bisect shows that this was broken by this commit.
> 
> https://github.com/torvalds/linux/commit/
> 28ab9769117ca944cb6eb537af5599aa436287a4

It looks like this commit is probably going to be reverted.

https://lore.kernel.org/linux-ide/20240813131900.1285842-2-cassel@kernel.org/T/#u

Comment 8 Jan Rybar 2024-08-19 11:03:27 UTC
Thanks for investigating this. So what now? Wait for kernel update?

Comment 10 Ian Pilcher 2024-08-19 21:03:03 UTC
(In reply to Michael Catanzaro from comment #9)
> Reverted in:
> https://github.com/torvalds/linux/commit/
> fa0db8e568787c665384430eaf2221b299b85367

And that commit is in kernel-6.10.5-200.fc40.x86_64 in updates-testing.


Note You need to log in before you can comment on or make changes to this bug.