Hi, I encountered an issue with migrating memfds in CRIU (checkpoint restore in userspace - it migrates running processes between machines). Imagine a scenario: 1. Create a memfd. By default it's open with O_RDWR and yet one can exec() to it (unlike with regular files, where one would get ETXTBSY). 2. Reopen that memfd with O_RDWR via /proc/self/fd/<fd>. Now those 2 fds are indistinguishable from userspace. You can't exec() to either of them (since the reopen incremented inode->i_writecount) and their /proc/self/fdinfo/ are exactly the same. Unfortunately they are not the same. If you close the second one, the first one becomes exec()able again. If you close the first one, the other doesn't become exec()able (I think this is due to the second one having FMODE_WRITER unlike the first one). Therefore during migration it does matter which is recreated first and which is reopened but there is no way for CRIU to tell which was first. I see 2 ways to fix it: 1. Actually make the second fd the same as the first. Either totally ignore inode->i_writecount check during exec() for memfds or always allow to exec() if there's only one fd with O_RDWR to that memfd. 2. Allow userspace to distinguish between those fds. Either by modifying fdinfo or adding a new fcntl, which will expose that info. I like neither of those solutions so I'd like to ask which is more likely to get accepted. Thanks, Michal Clapinski
