4

Is it guaranteed that a struct file pointer won't be deallocated and reallocated somewhere else in memory during its open to close lifecycle?

I want to uniquely identify file structs that are passed to a device driver (through read/write/open etc) and was wondering if I could just use the pointer to the file struct for identification. The only other alternative I see would be to store a unique identifier in private_data, if it is not guaranteed that the struct file pointer will not change.

Michael
  • 5,994
  • 7
  • 44
  • 56
  • I assume you mean just through the lifecycle (open->close) of a file, and not, as in, will it *never* be deallocated? – Ben Zotto Sep 14 '12 at 01:08
  • Yeah just through the lifecycle. – Michael Sep 14 '12 at 01:09
  • IIUC, the {devicenumber,inodenumber} is the *natural key* for files. In a datamodelling sense, the pointers are functionally dependent on them. The raw pointer value *could* be stable in time, but I would not trust on it. Disclaimer: Dammit, Jim, I am a DBA, not a kernel hacker. – wildplasser Sep 14 '12 at 01:15
  • The file struct indicate an open file in a process, not the actual file in the filesystem which is indicated by devnumber/inodenumber. So you could have multiple file structs pointing to the same device/inode. – Michael Sep 14 '12 at 01:25
  • In that case (I think) you have a hierarchy inversion. The file structure should not exist at the device driver level, it is a different level of abstraction, IMHO. – wildplasser Sep 14 '12 at 02:05
  • Yes it should and does exist at the device driver level, it is a kernel structure. It is passed to all file operations associated with a device. – Michael Sep 14 '12 at 02:16
  • 1
    wildplasser: In the linux kernel, character device callbacks for open and close receive a `struct inode *` and a `struct file *`. You can use the `inode` to know which of the possibly many entries in `/dev` you are dealing with. Each of those can be accessed by multiple independent threads. Each of those independent threads can call `open()` on that inode and they get an independent `struct file *`. Normally, when a kernel developer uses that `struct file *`, they use a field called private_data to store a pointer to custom data that they are using. – Bill Lynch Sep 14 '12 at 02:17

1 Answers1

0

Nothing will happen to the pointer. But you have to make sure that if this pointer is being passed across the kernel-user boundary (or computer-network), you actually check that the pointer you get is one of the valid pointers and perhaps an appropriate one (expected from this particular caller, if you can identify them). Otherwise you will have a huge security hole.

Alexey Frunze
  • 61,140
  • 12
  • 83
  • 180
  • 1
    struct file pointers are all in kernel land, file descriptors are used in user land I believe. How do you know nothing will happen to the pointer? – Michael Sep 17 '12 at 11:11
  • Just because current kernels don't move the structure around doesn't mean that some day they will. – wallyk Mar 07 '14 at 01:37