2021-09-07 16:13:02 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-08-19 10:25:00 +02:00
|
|
|
|
2021-09-07 16:13:02 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-09-23 10:37:51 +08:00
|
|
|
|
2023-08-01 19:22:00 +02:00
|
|
|
|
2021-12-02 12:34:00 -08:00
|
|
|
|
block: implement async io_uring discard cmd
io_uring allows implementing custom file specific asynchronous
operations via the fops->uring_cmd callback, a.k.a. IORING_OP_URING_CMD
requests or just io_uring commands. Use it to add support for async
discards.
Normally, it first tries to queue up bios in a non-blocking context,
and if that fails, we'd retry from a blocking context by returning
-EAGAIN to the core io_uring. We always get the result from bios
asynchronously by setting a custom bi_end_io callback, at which point
we drag the request into the task context to either reissue or complete
it and post a completion to the user.
Unlike ioctl(BLKDISCARD) with stronger guarantees against races, we only
do a best effort attempt to invalidate page cache, and it can race with
any writes and reads and leave page cache stale. It's the same kind of
races we allow to direct writes.
Also, apart from cases where discarding is not allowed at all, e.g.
discards are not supported or the file/device is read only, the user
should assume that the sector range on disk is not valid anymore, even
when an error was returned to the user.
Suggested-by: Conrad Meyer <conradmeyer@meta.com>
Signed-off-by: Pavel Begunkov <asml.silence@gmail.com>
Link: https://lore.kernel.org/r/2b5210443e4fa0257934f73dfafcc18a77cd0e09.1726072086.git.asml.silence@gmail.com
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2024-09-11 17:34:41 +01:00
|
|
|
|
2021-09-07 16:13:02 +02:00
|
|
|
|
|
|
|
|
|
2021-10-13 09:57:11 +01:00
|
|
|
|
2021-09-07 16:13:02 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-07-14 11:06:32 -07:00
|
|
|
|
2021-09-07 16:13:02 +02:00
|
|
|
|
2022-07-14 11:06:32 -07:00
|
|
|
|
2021-09-07 16:13:02 +02:00
|
|
|
|
|
|
|
|
|
2022-05-22 09:39:27 -04:00
|
|
|
|
2022-07-14 11:06:32 -07:00
|
|
|
|
|
|
|
|
|
2021-09-07 16:13:02 +02:00
|
|
|
|
|
|
|
|
|
2024-10-19 12:51:06 +00:00
|
|
|
|
2024-10-19 12:51:07 +00:00
|
|
|
|
2022-06-10 12:58:24 -07:00
|
|
|
|
2025-08-27 07:12:54 -07:00
|
|
|
|
|
|
|
|
|
2022-06-10 12:58:24 -07:00
|
|
|
|
|
|
|
|
|
2025-10-07 11:06:28 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-09-07 16:13:02 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-04-15 12:20:20 +00:00
|
|
|
|
|
|
|
|
|
2021-09-07 16:13:02 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-01-24 10:11:06 +01:00
|
|
|
|
|
|
|
|
|
2022-05-22 14:59:25 -04:00
|
|
|
|
2022-01-24 10:11:06 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-10-20 20:00:50 +01:00
|
|
|
|
2024-02-02 12:39:25 -08:00
|
|
|
|
2025-05-06 17:47:26 +05:30
|
|
|
|
2021-09-07 16:13:02 +02:00
|
|
|
|
2024-06-20 12:53:56 +00:00
|
|
|
|
|
|
|
|
|
2021-09-07 16:13:02 +02:00
|
|
|
|
2025-10-07 11:06:28 +02:00
|
|
|
|
2021-09-07 16:13:02 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-01-24 10:11:06 +01:00
|
|
|
|
2021-09-07 16:13:02 +02:00
|
|
|
|
2022-01-24 10:11:06 +01:00
|
|
|
|
2021-09-07 16:13:02 +02:00
|
|
|
|
|
|
|
|
|
2022-04-20 22:31:10 +08:00
|
|
|
|
|
|
|
|
|
2021-09-07 16:13:02 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-10-14 11:17:43 -06:00
|
|
|
|
2021-10-27 13:21:09 +01:00
|
|
|
|
|
|
|
|
|
2021-10-14 11:17:43 -06:00
|
|
|
|
|
|
|
|
|
2021-09-07 16:13:02 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-10-14 11:17:43 -06:00
|
|
|
|
2021-10-15 16:55:05 -06:00
|
|
|
|
2021-09-07 16:13:02 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-10-14 11:17:43 -06:00
|
|
|
|
2024-11-28 16:52:40 +05:30
|
|
|
|
2021-09-07 16:13:02 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-08-19 10:25:01 +02:00
|
|
|
|
2024-11-28 16:52:40 +05:30
|
|
|
|
|
|
|
|
|
2021-10-27 13:21:09 +01:00
|
|
|
|
2024-11-28 16:52:40 +05:30
|
|
|
|
2021-09-07 16:13:02 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-10-12 13:12:24 +02:00
|
|
|
|
|
|
|
|
|
2021-09-07 16:13:02 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-10-21 09:22:35 -06:00
|
|
|
|
2021-10-27 13:21:09 +01:00
|
|
|
|
2021-09-07 16:13:02 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-04-15 12:20:20 +00:00
|
|
|
|
2021-09-07 16:13:02 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-07-14 11:06:32 -07:00
|
|
|
|
2021-09-07 16:13:02 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-03-24 16:35:24 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-09-07 16:13:02 +02:00
|
|
|
|
2021-10-27 13:21:09 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-10-14 11:17:43 -06:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-09-07 16:13:02 +02:00
|
|
|
|
|
|
|
|
|
2021-10-14 11:17:43 -06:00
|
|
|
|
2021-09-07 16:13:02 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-05-22 14:59:25 -04:00
|
|
|
|
2021-10-14 11:17:43 -06:00
|
|
|
|
2021-09-07 16:13:02 +02:00
|
|
|
|
2021-10-27 13:21:08 +01:00
|
|
|
|
2021-09-07 16:13:02 +02:00
|
|
|
|
|
|
|
|
|
2021-10-20 20:00:50 +01:00
|
|
|
|
2024-02-02 12:39:25 -08:00
|
|
|
|
2025-05-06 17:47:26 +05:30
|
|
|
|
2021-09-07 16:13:02 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-10-07 11:06:28 +02:00
|
|
|
|
2021-09-07 16:13:02 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-01-16 08:55:53 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-11-28 16:52:40 +05:30
|
|
|
|
|
|
|
|
|
2023-01-16 08:55:53 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-08-19 10:25:01 +02:00
|
|
|
|
2024-11-28 16:52:40 +05:30
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-09-07 16:13:02 +02:00
|
|
|
|
|
|
|
|
|
2021-10-14 11:17:43 -06:00
|
|
|
|
2021-09-07 16:13:02 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-10-12 13:12:24 +02:00
|
|
|
|
2021-09-07 16:13:02 +02:00
|
|
|
|
|
|
|
|
|
2021-10-27 13:21:09 +01:00
|
|
|
|
2021-09-07 16:13:02 +02:00
|
|
|
|
2022-01-24 10:11:05 +01:00
|
|
|
|
2021-09-07 16:13:02 +02:00
|
|
|
|
|
|
|
|
|
2021-10-27 13:21:08 +01:00
|
|
|
|
2021-09-07 16:13:02 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-10-27 13:21:08 +01:00
|
|
|
|
2021-09-07 16:13:02 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-11-28 16:52:40 +05:30
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-09-07 16:13:02 +02:00
|
|
|
|
|
|
|
|
|
2021-10-23 17:21:32 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-02-11 10:01:36 +01:00
|
|
|
|
|
|
|
|
|
2021-10-23 17:21:32 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-08-19 10:25:01 +02:00
|
|
|
|
2024-11-28 16:52:40 +05:30
|
|
|
|
|
|
|
|
|
2021-11-01 10:17:11 -07:00
|
|
|
|
2021-10-23 17:21:32 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-04-15 12:20:20 +00:00
|
|
|
|
2021-10-23 17:21:32 +01:00
|
|
|
|
|
|
|
|
|
2022-01-24 10:11:04 +01:00
|
|
|
|
2022-07-14 11:06:32 -07:00
|
|
|
|
2021-10-23 17:21:32 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-03-24 16:35:24 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-10-23 17:21:32 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-02-02 12:39:25 -08:00
|
|
|
|
2025-05-06 17:47:26 +05:30
|
|
|
|
2021-10-23 17:21:32 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-10-27 13:21:07 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-10-07 11:06:28 +02:00
|
|
|
|
2024-11-28 16:52:40 +05:30
|
|
|
|
|
|
|
|
|
2021-10-23 17:21:32 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-01-24 10:11:04 +01:00
|
|
|
|
2022-05-22 14:59:25 -04:00
|
|
|
|
2021-10-23 17:21:32 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-11-28 16:52:40 +05:30
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-06-20 12:53:56 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-08-08 11:06:17 -06:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-10-23 17:21:32 +01:00
|
|
|
|
2023-08-08 11:06:17 -06:00
|
|
|
|
2021-10-23 17:21:32 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-11-28 16:52:40 +05:30
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-10-23 17:21:32 +01:00
|
|
|
|
|
|
|
|
|
2021-09-07 16:13:02 +02:00
|
|
|
|
|
|
|
|
|
2024-04-15 12:20:20 +00:00
|
|
|
|
2021-09-07 16:13:02 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-10-19 12:51:07 +00:00
|
|
|
|
2024-04-15 12:20:20 +00:00
|
|
|
|
|
|
|
|
|
2025-05-06 17:47:26 +05:30
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-09-07 16:13:02 +02:00
|
|
|
|
2025-08-19 10:25:01 +02:00
|
|
|
|
|
|
|
|
|
2021-10-23 17:21:32 +01:00
|
|
|
|
2024-04-15 12:20:20 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-10-19 12:51:07 +00:00
|
|
|
|
2024-06-20 12:53:56 +00:00
|
|
|
|
2021-10-23 17:21:32 +01:00
|
|
|
|
2024-04-15 12:20:20 +00:00
|
|
|
|
2021-09-07 16:13:02 +02:00
|
|
|
|
|
|
|
|
|
2023-08-01 19:22:00 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-05-03 10:10:42 +02:00
|
|
|
|
2023-08-01 19:22:00 +02:00
|
|
|
|
2024-06-25 19:55:17 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-08-01 19:22:00 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-08-01 19:22:01 +02:00
|
|
|
|
2023-08-01 19:22:00 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-08-01 19:22:01 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-12-15 20:02:44 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-09-07 16:13:02 +02:00
|
|
|
|
2025-04-24 10:27:52 +02:00
|
|
|
|
2023-12-15 20:02:44 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-04-24 10:27:52 +02:00
|
|
|
|
|
|
|
|
|
2023-12-15 20:02:44 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-09-07 16:13:02 +02:00
|
|
|
|
|
|
|
|
|
2022-04-29 10:40:40 -04:00
|
|
|
|
2021-09-07 16:13:02 +02:00
|
|
|
|
2022-04-29 10:40:40 -04:00
|
|
|
|
2021-09-07 16:13:02 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-07-16 09:36:06 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-09-07 16:13:02 +02:00
|
|
|
|
2024-07-15 14:24:01 -04:00
|
|
|
|
2021-09-07 16:13:02 +02:00
|
|
|
|
|
|
|
|
|
2025-07-16 09:36:06 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-09-07 16:13:02 +02:00
|
|
|
|
|
|
|
|
|
2025-06-24 14:21:27 +01:00
|
|
|
|
2021-09-07 16:13:02 +02:00
|
|
|
|
2024-07-10 13:43:36 -04:00
|
|
|
|
|
|
|
|
|
2021-09-07 16:13:02 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-02-09 20:22:12 +00:00
|
|
|
|
2022-02-09 20:21:34 +00:00
|
|
|
|
2022-04-29 10:40:40 -04:00
|
|
|
|
2021-09-07 16:13:02 +02:00
|
|
|
|
2023-12-15 20:02:44 +00:00
|
|
|
|
2021-09-07 16:13:02 +02:00
|
|
|
|
|
|
|
|
|
2022-06-06 10:20:31 -04:00
|
|
|
|
2021-09-07 16:13:02 +02:00
|
|
|
|
|
|
|
|
|
2023-08-01 19:22:01 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-07-10 15:33:28 +02:00
|
|
|
|
|
|
|
|
|
2023-08-01 19:22:01 +02:00
|
|
|
|
2025-07-10 15:33:28 +02:00
|
|
|
|
2023-08-01 19:22:01 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-07-10 15:33:28 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-08-01 19:22:01 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-07-10 15:33:28 +02:00
|
|
|
|
2025-07-10 15:33:29 +02:00
|
|
|
|
2023-08-01 19:22:01 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-07-10 15:33:26 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-08-01 19:22:01 +02:00
|
|
|
|
2025-07-10 15:33:26 +02:00
|
|
|
|
2023-08-01 19:22:01 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-11-17 16:14:47 +00:00
|
|
|
|
2023-08-01 19:22:01 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-09-07 16:13:02 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-06-08 13:02:56 +02:00
|
|
|
|
2021-09-07 16:13:02 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-09-27 11:34:08 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-06-08 13:02:55 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-09-27 11:34:08 +02:00
|
|
|
|
2024-01-23 14:26:49 +01:00
|
|
|
|
|
|
|
|
|
2023-09-27 11:34:08 +02:00
|
|
|
|
2024-01-23 14:26:49 +01:00
|
|
|
|
|
|
|
|
|
2023-09-27 11:34:08 +02:00
|
|
|
|
2023-06-08 13:02:55 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-09-07 16:13:02 +02:00
|
|
|
|
|
|
|
|
|
2024-01-23 14:26:46 +01:00
|
|
|
|
2023-09-27 11:34:08 +02:00
|
|
|
|
2024-01-23 14:26:46 +01:00
|
|
|
|
2021-09-07 16:13:02 +02:00
|
|
|
|
2023-09-27 11:34:08 +02:00
|
|
|
|
2024-01-23 14:26:49 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-01-23 14:26:46 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-04-23 07:37:41 +02:00
|
|
|
|
2024-01-23 14:26:46 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-10-19 12:51:07 +00:00
|
|
|
|
2024-06-20 12:53:56 +00:00
|
|
|
|
2025-08-19 10:25:00 +02:00
|
|
|
|
|
|
|
|
|
2024-06-20 12:53:56 +00:00
|
|
|
|
2024-01-23 14:26:49 +01:00
|
|
|
|
2024-01-23 14:26:46 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-09-07 16:13:02 +02:00
|
|
|
|
|
|
|
|
|
2023-06-08 13:02:38 +02:00
|
|
|
|
2021-09-07 16:13:02 +02:00
|
|
|
|
2024-01-23 14:26:49 +01:00
|
|
|
|
2021-09-07 16:13:02 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-08-01 19:21:58 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-08-01 19:22:00 +02:00
|
|
|
|
|
|
|
|
|
2025-07-10 15:33:35 +02:00
|
|
|
|
|
|
|
|
|
2023-08-01 19:22:00 +02:00
|
|
|
|
|
|
|
|
|
2021-09-07 16:13:02 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-08-01 19:21:58 +02:00
|
|
|
|
2024-04-11 15:53:40 +01:00
|
|
|
|
|
|
|
|
|
2024-11-27 09:23:18 +00:00
|
|
|
|
2021-11-04 15:13:17 -06:00
|
|
|
|
2021-09-07 16:13:02 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-10-13 09:57:11 +01:00
|
|
|
|
2021-09-07 16:13:02 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-11-27 09:23:18 +00:00
|
|
|
|
2024-10-19 12:51:07 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-09-07 16:13:02 +02:00
|
|
|
|
|
|
|
|
|
2024-11-27 09:23:18 +00:00
|
|
|
|
|
|
|
|
|
2021-09-07 16:13:02 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-08-01 19:21:58 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-08-01 19:22:00 +02:00
|
|
|
|
2023-08-01 19:21:58 +02:00
|
|
|
|
block: fix race between set_blocksize and read paths
With the new large sector size support, it's now the case that
set_blocksize can change i_blksize and the folio order in a manner that
conflicts with a concurrent reader and causes a kernel crash.
Specifically, let's say that udev-worker calls libblkid to detect the
labels on a block device. The read call can create an order-0 folio to
read the first 4096 bytes from the disk. But then udev is preempted.
Next, someone tries to mount an 8k-sectorsize filesystem from the same
block device. The filesystem calls set_blksize, which sets i_blksize to
8192 and the minimum folio order to 1.
Now udev resumes, still holding the order-0 folio it allocated. It then
tries to schedule a read bio and do_mpage_readahead tries to create
bufferheads for the folio. Unfortunately, blocks_per_folio == 0 because
the page size is 4096 but the blocksize is 8192 so no bufferheads are
attached and the bh walk never sets bdev. We then submit the bio with a
NULL block device and crash.
Therefore, truncate the page cache after flushing but before updating
i_blksize. However, that's not enough -- we also need to lock out file
IO and page faults during the update. Take both the i_rwsem and the
invalidate_lock in exclusive mode for invalidations, and in shared mode
for read/write operations.
I don't know if this is the correct fix, but xfs/259 found it.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Luis Chamberlain <mcgrof@kernel.org>
Tested-by: Shin'ichiro Kawasaki <shinichiro.kawasaki@wdc.com>
Link: https://lore.kernel.org/r/174543795699.4139148.2086129139322431423.stgit@frogsfrogsfrogs
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2025-04-23 12:53:42 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-08-01 19:22:00 +02:00
|
|
|
|
block: fix race between set_blocksize and read paths
With the new large sector size support, it's now the case that
set_blocksize can change i_blksize and the folio order in a manner that
conflicts with a concurrent reader and causes a kernel crash.
Specifically, let's say that udev-worker calls libblkid to detect the
labels on a block device. The read call can create an order-0 folio to
read the first 4096 bytes from the disk. But then udev is preempted.
Next, someone tries to mount an 8k-sectorsize filesystem from the same
block device. The filesystem calls set_blksize, which sets i_blksize to
8192 and the minimum folio order to 1.
Now udev resumes, still holding the order-0 folio it allocated. It then
tries to schedule a read bio and do_mpage_readahead tries to create
bufferheads for the folio. Unfortunately, blocks_per_folio == 0 because
the page size is 4096 but the blocksize is 8192 so no bufferheads are
attached and the bh walk never sets bdev. We then submit the bio with a
NULL block device and crash.
Therefore, truncate the page cache after flushing but before updating
i_blksize. However, that's not enough -- we also need to lock out file
IO and page faults during the update. Take both the i_rwsem and the
invalidate_lock in exclusive mode for invalidations, and in shared mode
for read/write operations.
I don't know if this is the correct fix, but xfs/259 found it.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Luis Chamberlain <mcgrof@kernel.org>
Tested-by: Shin'ichiro Kawasaki <shinichiro.kawasaki@wdc.com>
Link: https://lore.kernel.org/r/174543795699.4139148.2086129139322431423.stgit@frogsfrogsfrogs
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2025-04-23 12:53:42 -07:00
|
|
|
|
2023-08-01 19:21:58 +02:00
|
|
|
|
|
|
|
|
|
2021-09-07 16:13:02 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
block: fix race between set_blocksize and read paths
With the new large sector size support, it's now the case that
set_blocksize can change i_blksize and the folio order in a manner that
conflicts with a concurrent reader and causes a kernel crash.
Specifically, let's say that udev-worker calls libblkid to detect the
labels on a block device. The read call can create an order-0 folio to
read the first 4096 bytes from the disk. But then udev is preempted.
Next, someone tries to mount an 8k-sectorsize filesystem from the same
block device. The filesystem calls set_blksize, which sets i_blksize to
8192 and the minimum folio order to 1.
Now udev resumes, still holding the order-0 folio it allocated. It then
tries to schedule a read bio and do_mpage_readahead tries to create
bufferheads for the folio. Unfortunately, blocks_per_folio == 0 because
the page size is 4096 but the blocksize is 8192 so no bufferheads are
attached and the bh walk never sets bdev. We then submit the bio with a
NULL block device and crash.
Therefore, truncate the page cache after flushing but before updating
i_blksize. However, that's not enough -- we also need to lock out file
IO and page faults during the update. Take both the i_rwsem and the
invalidate_lock in exclusive mode for invalidations, and in shared mode
for read/write operations.
I don't know if this is the correct fix, but xfs/259 found it.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Luis Chamberlain <mcgrof@kernel.org>
Tested-by: Shin'ichiro Kawasaki <shinichiro.kawasaki@wdc.com>
Link: https://lore.kernel.org/r/174543795699.4139148.2086129139322431423.stgit@frogsfrogsfrogs
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2025-04-23 12:53:42 -07:00
|
|
|
|
2023-06-08 13:02:56 +02:00
|
|
|
|
2021-11-04 15:13:17 -06:00
|
|
|
|
2021-09-07 16:13:02 +02:00
|
|
|
|
|
|
|
|
|
2021-10-28 08:57:09 -06:00
|
|
|
|
2022-02-01 11:04:20 +01:00
|
|
|
|
2021-09-07 16:13:02 +02:00
|
|
|
|
2022-02-01 11:04:20 +01:00
|
|
|
|
2021-10-20 20:00:48 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-02-01 11:04:20 +01:00
|
|
|
|
|
|
|
|
|
2021-09-07 16:13:02 +02:00
|
|
|
|
|
|
|
|
|
2022-02-01 11:04:20 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-10-28 08:57:09 -06:00
|
|
|
|
2023-06-01 16:58:56 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-10-28 08:57:09 -06:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-01-23 06:18:41 -07:00
|
|
|
|
2021-10-28 08:57:09 -06:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-01-23 06:18:41 -07:00
|
|
|
|
|
|
|
|
|
2021-10-28 08:57:09 -06:00
|
|
|
|
2022-02-01 11:04:20 +01:00
|
|
|
|
2021-10-28 08:57:09 -06:00
|
|
|
|
|
|
|
|
|
block: fix race between set_blocksize and read paths
With the new large sector size support, it's now the case that
set_blocksize can change i_blksize and the folio order in a manner that
conflicts with a concurrent reader and causes a kernel crash.
Specifically, let's say that udev-worker calls libblkid to detect the
labels on a block device. The read call can create an order-0 folio to
read the first 4096 bytes from the disk. But then udev is preempted.
Next, someone tries to mount an 8k-sectorsize filesystem from the same
block device. The filesystem calls set_blksize, which sets i_blksize to
8192 and the minimum folio order to 1.
Now udev resumes, still holding the order-0 folio it allocated. It then
tries to schedule a read bio and do_mpage_readahead tries to create
bufferheads for the folio. Unfortunately, blocks_per_folio == 0 because
the page size is 4096 but the blocksize is 8192 so no bufferheads are
attached and the bh walk never sets bdev. We then submit the bio with a
NULL block device and crash.
Therefore, truncate the page cache after flushing but before updating
i_blksize. However, that's not enough -- we also need to lock out file
IO and page faults during the update. Take both the i_rwsem and the
invalidate_lock in exclusive mode for invalidations, and in shared mode
for read/write operations.
I don't know if this is the correct fix, but xfs/259 found it.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Luis Chamberlain <mcgrof@kernel.org>
Tested-by: Shin'ichiro Kawasaki <shinichiro.kawasaki@wdc.com>
Link: https://lore.kernel.org/r/174543795699.4139148.2086129139322431423.stgit@frogsfrogsfrogs
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2025-04-23 12:53:42 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-10-28 08:57:09 -06:00
|
|
|
|
block: fix race between set_blocksize and read paths
With the new large sector size support, it's now the case that
set_blocksize can change i_blksize and the folio order in a manner that
conflicts with a concurrent reader and causes a kernel crash.
Specifically, let's say that udev-worker calls libblkid to detect the
labels on a block device. The read call can create an order-0 folio to
read the first 4096 bytes from the disk. But then udev is preempted.
Next, someone tries to mount an 8k-sectorsize filesystem from the same
block device. The filesystem calls set_blksize, which sets i_blksize to
8192 and the minimum folio order to 1.
Now udev resumes, still holding the order-0 folio it allocated. It then
tries to schedule a read bio and do_mpage_readahead tries to create
bufferheads for the folio. Unfortunately, blocks_per_folio == 0 because
the page size is 4096 but the blocksize is 8192 so no bufferheads are
attached and the bh walk never sets bdev. We then submit the bio with a
NULL block device and crash.
Therefore, truncate the page cache after flushing but before updating
i_blksize. However, that's not enough -- we also need to lock out file
IO and page faults during the update. Take both the i_rwsem and the
invalidate_lock in exclusive mode for invalidations, and in shared mode
for read/write operations.
I don't know if this is the correct fix, but xfs/259 found it.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Luis Chamberlain <mcgrof@kernel.org>
Tested-by: Shin'ichiro Kawasaki <shinichiro.kawasaki@wdc.com>
Link: https://lore.kernel.org/r/174543795699.4139148.2086129139322431423.stgit@frogsfrogsfrogs
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2025-04-23 12:53:42 -07:00
|
|
|
|
2021-10-20 20:00:48 +01:00
|
|
|
|
2022-02-01 11:04:20 +01:00
|
|
|
|
2021-10-20 20:00:48 +01:00
|
|
|
|
|
|
|
|
|
2021-09-07 16:13:02 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-06-19 19:18:05 +08:00
|
|
|
|
2021-09-07 16:13:02 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-09-23 10:37:51 +08:00
|
|
|
|
|
|
|
|
|
2021-09-07 16:13:02 +02:00
|
|
|
|
|
|
|
|
|
2025-06-19 19:18:04 +08:00
|
|
|
|
2021-09-07 16:13:02 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-06-19 19:18:05 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-09-07 16:13:02 +02:00
|
|
|
|
|
|
|
|
|
2021-10-18 12:11:24 +02:00
|
|
|
|
2021-09-07 16:13:02 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
block: fix race between set_blocksize and read paths
With the new large sector size support, it's now the case that
set_blocksize can change i_blksize and the folio order in a manner that
conflicts with a concurrent reader and causes a kernel crash.
Specifically, let's say that udev-worker calls libblkid to detect the
labels on a block device. The read call can create an order-0 folio to
read the first 4096 bytes from the disk. But then udev is preempted.
Next, someone tries to mount an 8k-sectorsize filesystem from the same
block device. The filesystem calls set_blksize, which sets i_blksize to
8192 and the minimum folio order to 1.
Now udev resumes, still holding the order-0 folio it allocated. It then
tries to schedule a read bio and do_mpage_readahead tries to create
bufferheads for the folio. Unfortunately, blocks_per_folio == 0 because
the page size is 4096 but the blocksize is 8192 so no bufferheads are
attached and the bh walk never sets bdev. We then submit the bio with a
NULL block device and crash.
Therefore, truncate the page cache after flushing but before updating
i_blksize. However, that's not enough -- we also need to lock out file
IO and page faults during the update. Take both the i_rwsem and the
invalidate_lock in exclusive mode for invalidations, and in shared mode
for read/write operations.
I don't know if this is the correct fix, but xfs/259 found it.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Luis Chamberlain <mcgrof@kernel.org>
Tested-by: Shin'ichiro Kawasaki <shinichiro.kawasaki@wdc.com>
Link: https://lore.kernel.org/r/174543795699.4139148.2086129139322431423.stgit@frogsfrogsfrogs
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2025-04-23 12:53:42 -07:00
|
|
|
|
2021-09-23 10:37:51 +08:00
|
|
|
|
|
|
|
|
|
2021-09-07 16:13:02 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-06-19 19:18:04 +08:00
|
|
|
|
2021-09-07 16:13:02 +02:00
|
|
|
|
|
|
|
|
|
2025-06-19 19:18:04 +08:00
|
|
|
|
2021-09-07 16:13:02 +02:00
|
|
|
|
2025-06-19 19:18:05 +08:00
|
|
|
|
|
|
|
|
|
2021-09-07 16:13:02 +02:00
|
|
|
|
|
|
|
|
|
2021-09-23 10:37:51 +08:00
|
|
|
|
2025-06-19 19:18:04 +08:00
|
|
|
|
2021-09-07 16:13:02 +02:00
|
|
|
|
|
|
|
|
|
2025-06-19 19:18:04 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-09-23 10:37:51 +08:00
|
|
|
|
|
|
|
|
|
block: fix race between set_blocksize and read paths
With the new large sector size support, it's now the case that
set_blocksize can change i_blksize and the folio order in a manner that
conflicts with a concurrent reader and causes a kernel crash.
Specifically, let's say that udev-worker calls libblkid to detect the
labels on a block device. The read call can create an order-0 folio to
read the first 4096 bytes from the disk. But then udev is preempted.
Next, someone tries to mount an 8k-sectorsize filesystem from the same
block device. The filesystem calls set_blksize, which sets i_blksize to
8192 and the minimum folio order to 1.
Now udev resumes, still holding the order-0 folio it allocated. It then
tries to schedule a read bio and do_mpage_readahead tries to create
bufferheads for the folio. Unfortunately, blocks_per_folio == 0 because
the page size is 4096 but the blocksize is 8192 so no bufferheads are
attached and the bh walk never sets bdev. We then submit the bio with a
NULL block device and crash.
Therefore, truncate the page cache after flushing but before updating
i_blksize. However, that's not enough -- we also need to lock out file
IO and page faults during the update. Take both the i_rwsem and the
invalidate_lock in exclusive mode for invalidations, and in shared mode
for read/write operations.
I don't know if this is the correct fix, but xfs/259 found it.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Luis Chamberlain <mcgrof@kernel.org>
Tested-by: Shin'ichiro Kawasaki <shinichiro.kawasaki@wdc.com>
Link: https://lore.kernel.org/r/174543795699.4139148.2086129139322431423.stgit@frogsfrogsfrogs
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2025-04-23 12:53:42 -07:00
|
|
|
|
2021-09-23 10:37:51 +08:00
|
|
|
|
2021-09-07 16:13:02 +02:00
|
|
|
|
|
|
|
|
|
fs: convert most other generic_file_*mmap() users to .mmap_prepare()
Update nearly all generic_file_mmap() and generic_file_readonly_mmap()
callers to use generic_file_mmap_prepare() and
generic_file_readonly_mmap_prepare() respectively.
We update blkdev, 9p, afs, erofs, ext2, nfs, ntfs3, smb, ubifs and vboxsf
file systems this way.
Remaining users we cannot yet update are ecryptfs, fuse and cramfs. The
former two are nested file systems that must support any underlying file
ssytem, and cramfs inserts a mixed mapping which currently requires a VMA.
Once all file systems have been converted to mmap_prepare(), we can then
update nested file systems.
Signed-off-by: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
Link: https://lore.kernel.org/08db85970d89b17a995d2cffae96fb4cc462377f.1750099179.git.lorenzo.stoakes@oracle.com
Signed-off-by: Christian Brauner <brauner@kernel.org>
2025-06-16 20:33:28 +01:00
|
|
|
|
2023-05-10 09:42:23 +02:00
|
|
|
|
fs: convert most other generic_file_*mmap() users to .mmap_prepare()
Update nearly all generic_file_mmap() and generic_file_readonly_mmap()
callers to use generic_file_mmap_prepare() and
generic_file_readonly_mmap_prepare() respectively.
We update blkdev, 9p, afs, erofs, ext2, nfs, ntfs3, smb, ubifs and vboxsf
file systems this way.
Remaining users we cannot yet update are ecryptfs, fuse and cramfs. The
former two are nested file systems that must support any underlying file
ssytem, and cramfs inserts a mixed mapping which currently requires a VMA.
Once all file systems have been converted to mmap_prepare(), we can then
update nested file systems.
Signed-off-by: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
Link: https://lore.kernel.org/08db85970d89b17a995d2cffae96fb4cc462377f.1750099179.git.lorenzo.stoakes@oracle.com
Signed-off-by: Christian Brauner <brauner@kernel.org>
2025-06-16 20:33:28 +01:00
|
|
|
|
2023-05-10 09:42:23 +02:00
|
|
|
|
fs: convert most other generic_file_*mmap() users to .mmap_prepare()
Update nearly all generic_file_mmap() and generic_file_readonly_mmap()
callers to use generic_file_mmap_prepare() and
generic_file_readonly_mmap_prepare() respectively.
We update blkdev, 9p, afs, erofs, ext2, nfs, ntfs3, smb, ubifs and vboxsf
file systems this way.
Remaining users we cannot yet update are ecryptfs, fuse and cramfs. The
former two are nested file systems that must support any underlying file
ssytem, and cramfs inserts a mixed mapping which currently requires a VMA.
Once all file systems have been converted to mmap_prepare(), we can then
update nested file systems.
Signed-off-by: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
Link: https://lore.kernel.org/08db85970d89b17a995d2cffae96fb4cc462377f.1750099179.git.lorenzo.stoakes@oracle.com
Signed-off-by: Christian Brauner <brauner@kernel.org>
2025-06-16 20:33:28 +01:00
|
|
|
|
|
|
|
|
|
2023-05-10 09:42:23 +02:00
|
|
|
|
fs: convert most other generic_file_*mmap() users to .mmap_prepare()
Update nearly all generic_file_mmap() and generic_file_readonly_mmap()
callers to use generic_file_mmap_prepare() and
generic_file_readonly_mmap_prepare() respectively.
We update blkdev, 9p, afs, erofs, ext2, nfs, ntfs3, smb, ubifs and vboxsf
file systems this way.
Remaining users we cannot yet update are ecryptfs, fuse and cramfs. The
former two are nested file systems that must support any underlying file
ssytem, and cramfs inserts a mixed mapping which currently requires a VMA.
Once all file systems have been converted to mmap_prepare(), we can then
update nested file systems.
Signed-off-by: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
Link: https://lore.kernel.org/08db85970d89b17a995d2cffae96fb4cc462377f.1750099179.git.lorenzo.stoakes@oracle.com
Signed-off-by: Christian Brauner <brauner@kernel.org>
2025-06-16 20:33:28 +01:00
|
|
|
|
2023-05-10 09:42:23 +02:00
|
|
|
|
|
|
|
|
|
2021-09-07 16:13:02 +02:00
|
|
|
|
|
|
|
|
|
2023-06-08 13:02:38 +02:00
|
|
|
|
2021-09-07 16:13:02 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-10-12 13:12:24 +02:00
|
|
|
|
fs: convert most other generic_file_*mmap() users to .mmap_prepare()
Update nearly all generic_file_mmap() and generic_file_readonly_mmap()
callers to use generic_file_mmap_prepare() and
generic_file_readonly_mmap_prepare() respectively.
We update blkdev, 9p, afs, erofs, ext2, nfs, ntfs3, smb, ubifs and vboxsf
file systems this way.
Remaining users we cannot yet update are ecryptfs, fuse and cramfs. The
former two are nested file systems that must support any underlying file
ssytem, and cramfs inserts a mixed mapping which currently requires a VMA.
Once all file systems have been converted to mmap_prepare(), we can then
update nested file systems.
Signed-off-by: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
Link: https://lore.kernel.org/08db85970d89b17a995d2cffae96fb4cc462377f.1750099179.git.lorenzo.stoakes@oracle.com
Signed-off-by: Christian Brauner <brauner@kernel.org>
2025-06-16 20:33:28 +01:00
|
|
|
|
2021-09-07 16:13:02 +02:00
|
|
|
|
2021-10-12 12:44:50 +02:00
|
|
|
|
2021-09-07 16:13:02 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-05-22 14:50:15 +01:00
|
|
|
|
2021-09-07 16:13:02 +02:00
|
|
|
|
|
|
|
|
|
block: implement async io_uring discard cmd
io_uring allows implementing custom file specific asynchronous
operations via the fops->uring_cmd callback, a.k.a. IORING_OP_URING_CMD
requests or just io_uring commands. Use it to add support for async
discards.
Normally, it first tries to queue up bios in a non-blocking context,
and if that fails, we'd retry from a blocking context by returning
-EAGAIN to the core io_uring. We always get the result from bios
asynchronously by setting a custom bi_end_io callback, at which point
we drag the request into the task context to either reissue or complete
it and post a completion to the user.
Unlike ioctl(BLKDISCARD) with stronger guarantees against races, we only
do a best effort attempt to invalidate page cache, and it can race with
any writes and reads and leave page cache stale. It's the same kind of
races we allow to direct writes.
Also, apart from cases where discarding is not allowed at all, e.g.
discards are not supported or the file/device is read only, the user
should assume that the sector range on disk is not valid anymore, even
when an error was returned to the user.
Suggested-by: Conrad Meyer <conradmeyer@meta.com>
Signed-off-by: Pavel Begunkov <asml.silence@gmail.com>
Link: https://lore.kernel.org/r/2b5210443e4fa0257934f73dfafcc18a77cd0e09.1726072086.git.asml.silence@gmail.com
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2024-09-11 17:34:41 +01:00
|
|
|
|
2024-03-28 13:27:24 +01:00
|
|
|
|
2021-09-07 16:13:02 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|