illegal seek when access /dev/net/tun simultaneously

[lparam]

illegal-seek-demo.tar.gz

steps to reproduce

1. cargo build; sudo ./target/debug/demo
2. ping 10.0.5.2 in another terminal
3. press any key in the same terminal of the demo program

key code

        loop {
            select! {
                r = tun_file.read(&mut tun_buf).fuse() => match r {
                    Ok(n) => {
                        println!("read {} bytes {:?} from tun", n, &tun_buf[..n]);
                    }
                    Err(e) => {
                        println!("read error: {}", e);
                    }
                },
                line = lines_from_stdin.next().fuse() => match line {
                    Some(line) => {
                        let line = line?;
                        println!("line: {}", line);
                        let buf: [u8; 32] = [0x45, 0x00, 0x00, 0x20, 0x91, 0xb3, 0x40, 0x00, 0x40, 0x11, 0x8d, 0x17, 0x0a, 0x00, 0x05, 0x01, 0x0a, 0x00, 0x05, 0x03, 0x83, 0x0d, 0x1f, 0x90, 0x00, 0x0c, 0x7c, 0xc9, 0x61, 0x62, 0x63, 0x0a];
                        match tun_file.write(&buf).await {
                            Ok(n) => {
                                println!("write {} bytes to tun", n);
                            },
                            Err(e) => {
                                println!("write error: {}", e); // Illegal seek
                            }
                        }
                    }
                    None => break,
                }
            }
        }

When a keypress is received, the line = lines_from_stdin.next().fuse() case in select! will fire. At the same time, since the r = tun_file.read(&mut tun_buf).fuse() case doesn't fire, the tun_file.read(&mut tun_buf).fuse() future will be dropped, which means this read operation gets cancelled.

When canceling a read operation, inside the implementation of async_std::fs::File we will seek backward in the file by as many bytes as were read, thus "undoing" the read operation. However, the problem here is that /dev/net/tun is a special file that is not seekable, and any attempt at calling seek() on it will result in an error. This is how the "illegal seek" error pops up here.

I'm not sure what's the best way of getting around this problem, to be honest. Perhaps we should not undo canceled read operations. What do you think?

Perhaps an easy solution would be to attempt to do .seek(SeekFrom::Current(0)) when the file is opened, and if that fails, we never do any seeking on the file because the file is not seekable.

[lparam]

Yep, setting a seekable flag is probably an easy way.

[yoshuawuyts]

We could also do this lazily and only check for the flag's existence the first time we try and wind back the read operation. When dealing with lots of small files the overhead of calling seek on file creation could be significant.

I think we could probably implement this by storing a seekable: Option<bool> flag inside our File struct.

[lparam]

How about add a seekable option for OpenOptions? e.g

OpenOptions::new()
            .read(true)
            .write(true)
            .seek(false)
            .open("/dev/net/tun")