I am trying to send a ioctl command on a symlink opened handle but I am getting errno = 9 (Bad file descriptor) and the call is no reaching my file system f_op->unlocked_ioctl.
Do the kernel restrict ioctl calls to symlink file ids? If so is there a workaround?

would be nice to show what did you really try and explain what did you try to achieve at all.

Sure. I am trying to get the access / modify time set to work with nfs ganesha. As of today nfs ganesha do not set the a/m time on a symlink (the call do not fails but it is not doing anything). nfs ganesha uses the name_to_handle_at/open_by_handle_at to get a handle for the file and when client send the setattr is passing this handle. In this call ganesha has the file id for the file, it doesn't have the name and it can't run utimensat - the only posix call to set the a/m time on a symlink. I thought that I can use a special ioctl to pass the a/m time using the file id of the symlink (as the backing of the exported nfs ganesha is a proprietary filesystem that I have the source code). The call works on a regular file but not on a symlink. It has to be some code in the OS that retuned errno = 9 when ioctl is called on a symlink file id. Is it possible to go around this?
The other alternative is to keep name and parent dir with the symlink in nfs ganesha but this is not working, in case the lru cache remove the entry and client retry with the file handle, server has no way to reconstruct name & parent dir from the handle.

symlink itself is not a real file, it is just a directory entry pointing to somewhere. On ext4 the a/m times are stored together with the inode of the file, but in this case there is no inode at all.

You don't say what ioctl you're using, but one way to update times on a symlink is with the utimensat call with AT_SYMLINK_NOFOLLOW flag.

I can't use utimensat as this required dirfid and name and nfs ganesha do not keep them around, they just have the handle -> fid.
The symlink can be opened and it give back a user file id (if open with no follow), how is that generated? Some of posix commands like
fchownat(my_fd, "", user, group, AT_SYMLINK_NOFOLLOW | AT_EMPTY_PATH) works with my_fd == file id of the symlink.

I think I see what's going on. In the ioctl command the kernel will try to get to the inode using the fid by querying the fdtable with:
__fdget - this uses __fget_light(fd, FMODE_PATH)
and in the search fd's with FMODE_PATH are not returned so the ioctl will not return the file object as symlink has to be open with O_PATH
The fchownat is using: __fget_light(fd, 0) and it will return any fd (so it also return a symlink with FMODE_PATH set).
The option would be top have an ioctl on our driver management port that would pass the symlink file id and have the code run the __fget_light(fd, 0) to get the file object.