Add the ability to write a file_operations->llseek hook in Rust when
using the miscdevice abstraction.
Signed-off-by: Ryosuke Yasuoka <ryasuoka@redhat.com>
---
rust/kernel/miscdevice.rs | 36 ++++++++++++++++++++++++++++++++++++
1 file changed, 36 insertions(+)
diff --git a/rust/kernel/miscdevice.rs b/rust/kernel/miscdevice.rs
index 6373fe183b27..597e7b66e493 100644
--- a/rust/kernel/miscdevice.rs
+++ b/rust/kernel/miscdevice.rs
@@ -125,6 +125,16 @@ fn release(device: Self::Ptr, _file: &File) {
drop(device);
}
+ /// Handler for llseek.
+ fn llseek(
+ _device: <Self::Ptr as ForeignOwnable>::Borrowed<'_>,
+ _file: &File,
+ _offset: i64,
+ _whence: i32,
+ ) -> Result<isize> {
+ build_error!(VTABLE_DEFAULT_ERROR)
+ }
+
/// Handle for mmap.
///
/// This function is invoked when a user space process invokes the `mmap` system call on
@@ -245,6 +255,27 @@ impl<T: MiscDevice> MiscdeviceVTable<T> {
0
}
+ /// # Safety
+ ///
+ /// `file` must be a valid file that is associated with a `MiscDeviceRegistration<T>`.
+ unsafe extern "C" fn llseek(file: *mut bindings::file, offset: i64, whence: c_int) -> i64 {
+ // SAFETY: The llseek call of a file can access the private data.
+ let private = unsafe { (*file).private_data };
+ // SAFETY: This is a Rust Miscdevice, so we call `into_foreign` in `open` and
+ // `from_foreign` in `release`, and `fops_llseek` is guaranteed to be called between those
+ // two operations.
+ let device = unsafe { <T::Ptr as ForeignOwnable>::borrow(private) };
+ // SAFETY:
+ // * The file is valid for the duration of this call.
+ // * There is no active fdget_pos region on the file on this thread.
+ let file = unsafe { File::from_raw_file(file) };
+
+ match T::llseek(device, file, offset, whence) {
+ Ok(res) => res as i64,
+ Err(err) => i64::from(err.to_errno()),
+ }
+ }
+
/// # Safety
///
/// `file` must be a valid file that is associated with a `MiscDeviceRegistration<T>`.
@@ -340,6 +371,11 @@ impl<T: MiscDevice> MiscdeviceVTable<T> {
const VTABLE: bindings::file_operations = bindings::file_operations {
open: Some(Self::open),
release: Some(Self::release),
+ llseek: if T::HAS_LLSEEK {
+ Some(Self::llseek)
+ } else {
+ None
+ },
mmap: if T::HAS_MMAP { Some(Self::mmap) } else { None },
unlocked_ioctl: if T::HAS_IOCTL {
Some(Self::ioctl)
--
2.50.1On Mon, Aug 18, 2025 at 10:58:38PM +0900, Ryosuke Yasuoka wrote: > Add the ability to write a file_operations->llseek hook in Rust when > using the miscdevice abstraction. > > Signed-off-by: Ryosuke Yasuoka <ryasuoka@redhat.com> > --- > rust/kernel/miscdevice.rs | 36 ++++++++++++++++++++++++++++++++++++ > 1 file changed, 36 insertions(+) What misc device driver needs any real llseek function? The ones I see in the tree are only using generic_llseek or noop_llseek. Do you have a specific misc driver that you want to write in rust that needs this call? thanks, greg k-h
On Mon, Aug 18, 2025 at 04:17:40PM +0200, Greg KH wrote: > On Mon, Aug 18, 2025 at 10:58:38PM +0900, Ryosuke Yasuoka wrote: > > Add the ability to write a file_operations->llseek hook in Rust when > > using the miscdevice abstraction. > > > > Signed-off-by: Ryosuke Yasuoka <ryasuoka@redhat.com> > > --- > > rust/kernel/miscdevice.rs | 36 ++++++++++++++++++++++++++++++++++++ > > 1 file changed, 36 insertions(+) > > What misc device driver needs any real llseek function? The ones I see > in the tree are only using generic_llseek or noop_llseek. > > Do you have a specific misc driver that you want to write in rust that > needs this call? No, I'm not actually writing a practical misc driver. I'm just creating a toy misc driver to use for testing. In my toy driver, I need read, write, lseek, and ioctl to verify the basic functionality of the device driver. I saw the Jones and Alice were already working on read/write functions [1] and I believe they will propose their patch soon. So I propose implementing lseek which anyone does not work on currently. This is the background of my patch. As you mentioned, lseek by itself probably doesn't have much meaning. Should I wait for their read/write implementation to be finalized before proceeding this? [1] https://rust-for-linux.zulipchat.com/#narrow/channel/288089-General/topic/.E2.9C.94.20Miscdevice.20read.2Fwrite.20abstraction.3F/with/497953296 Thank you very much for your comment. Ryosuke > > thanks, > > greg k-h >
On Tue, Aug 19, 2025 at 02:10:27PM +0900, Ryosuke Yasuoka wrote: > On Mon, Aug 18, 2025 at 04:17:40PM +0200, Greg KH wrote: > > On Mon, Aug 18, 2025 at 10:58:38PM +0900, Ryosuke Yasuoka wrote: > > > Add the ability to write a file_operations->llseek hook in Rust when > > > using the miscdevice abstraction. > > > > > > Signed-off-by: Ryosuke Yasuoka <ryasuoka@redhat.com> > > > --- > > > rust/kernel/miscdevice.rs | 36 ++++++++++++++++++++++++++++++++++++ > > > 1 file changed, 36 insertions(+) > > > > What misc device driver needs any real llseek function? The ones I see > > in the tree are only using generic_llseek or noop_llseek. > > > > Do you have a specific misc driver that you want to write in rust that > > needs this call? > > No, I'm not actually writing a practical misc driver. I'm just creating > a toy misc driver to use for testing. > > In my toy driver, I need read, write, lseek, and ioctl to verify the > basic functionality of the device driver. I saw the Jones and Alice were > already working on read/write functions [1] and I believe they will > propose their patch soon. So I propose implementing lseek which > anyone does not work on currently. This is the background of my patch. > > As you mentioned, lseek by itself probably doesn't have much meaning. > Should I wait for their read/write implementation to be finalized before > proceeding this? > > [1] https://rust-for-linux.zulipchat.com/#narrow/channel/288089-General/topic/.E2.9C.94.20Miscdevice.20read.2Fwrite.20abstraction.3F/with/497953296 Yes, that would probably be best, because as-is, this patch can not really do anything :( Also, we really want an in-tree user for the new functionality (not just in the sample driver), if at all possible going forward. thanks, greg k-h
On Tue, Aug 19, 2025 at 08:04:32AM +0200, Greg KH wrote: > On Tue, Aug 19, 2025 at 02:10:27PM +0900, Ryosuke Yasuoka wrote: > > On Mon, Aug 18, 2025 at 04:17:40PM +0200, Greg KH wrote: > > > On Mon, Aug 18, 2025 at 10:58:38PM +0900, Ryosuke Yasuoka wrote: > > > > Add the ability to write a file_operations->llseek hook in Rust when > > > > using the miscdevice abstraction. > > > > > > > > Signed-off-by: Ryosuke Yasuoka <ryasuoka@redhat.com> > > > > --- > > > > rust/kernel/miscdevice.rs | 36 ++++++++++++++++++++++++++++++++++++ > > > > 1 file changed, 36 insertions(+) > > > > > > What misc device driver needs any real llseek function? The ones I see > > > in the tree are only using generic_llseek or noop_llseek. > > > > > > Do you have a specific misc driver that you want to write in rust that > > > needs this call? > > > > No, I'm not actually writing a practical misc driver. I'm just creating > > a toy misc driver to use for testing. > > > > In my toy driver, I need read, write, lseek, and ioctl to verify the > > basic functionality of the device driver. I saw the Jones and Alice were > > already working on read/write functions [1] and I believe they will > > propose their patch soon. So I propose implementing lseek which > > anyone does not work on currently. This is the background of my patch. > > > > As you mentioned, lseek by itself probably doesn't have much meaning. > > Should I wait for their read/write implementation to be finalized before > > proceeding this? > > > > [1] https://rust-for-linux.zulipchat.com/#narrow/channel/288089-General/topic/.E2.9C.94.20Miscdevice.20read.2Fwrite.20abstraction.3F/with/497953296 > > Yes, that would probably be best, because as-is, this patch can not > really do anything :( > > Also, we really want an in-tree user for the new functionality (not just > in the sample driver), if at all possible going forward. Got it. I'll try to include an in-tree user for it next time. Thank you. Ryosuke > thanks, > > greg k-h >
On Tue, Aug 19, 2025 at 4:12 PM Ryosuke Yasuoka <ryasuoka@redhat.com> wrote:
>
> Got it. I'll try to include an in-tree user for it next time.
Thanks! Yeah, please see:
https://rust-for-linux.com/contributing#submitting-new-abstractions-and-modules
for some more context on the "in-tree user" rule and ideas on how to
possibly provide one.
I hope that helps.
Cheers,
Miguel
© 2016 - 2025 Red Hat, Inc.