Which error value should I use?

Question

I am currently building a module for the Linux Kernel. My working revision is 3.8-rc3+. My work lead me to implement some ioctl() commands. As you know, my commands should return an appropriate error code to describe what went wrong during the execution. This seems quite simple, but I have a use case for which I can't figure out which error code I should return.

Basically, I want the user to be able to set cryptographic keys for a given device. My module stores the keys in a R-B tree, indexed by the devices unique identifier (a basic int). If the "target" device has already an entry in the tree, then this entry should be updated, otherwise, the module simply adds a newly allocated entry to the tree for that device, with the requested cryptographic key. That said, multiple things can occur while trying to set the key :

• Something inside the module might be using the cryptographic key the user wants to update : the module returns EBUSY error.
• There was no entry and allocation failed : ENOMEM error.
• The module is releasing its resources. The existing key entry might be marked for deletion (the entry has a dying flag to signal this) : internally I currently use EPERM error code, since the caller has not the "permission" to alter the entry while it's being destroyed.

As I said, for the latter case, I use EPERM error code, but I have the feeling it's wrong and I don't know which error code I should use for that purpose. Any advice is welcome !

I also specified linux tag as the ioctl() could be used within user-space applications.

EDIT : After having read through comments and answers, I think I will make it this way :

• When the module is releasing its resources, ESHUTDOWN will be returned.
• When only the target key is being destroyed, while the rest of the tree is still sane, EACCES will be used.

Answer 1

How about ESHUTDOWN? (Cannot send after transport endpoint shutdown)

Another option is ENXIO (No such device or address). It's not 100% accurate since the device is still there but it conveys the meaning of the error (it's no longer usable).

A simple choice would be ENOTSUP (Operation not supported) but that sounds more like "method not implemented"

EPERM sounds better but it's usually used with "you don't have permission/rights to do this" instead of "you can't do this right now".

ESTALE (Stale file handle) would be nice but it's NFS related.