Vitaliy, As I told you directly last week, proposing changes in anticipation of future work requires some sort of plan about that future work. Without some sort of model for locking the access paths, it's impossible to judge whether the proposed change is useful or pointless.
On Fri, 8 May 2015, Vitaliy Makkoveev wrote: > sysctl_file() has 2 cases: KERN_FILE_BY_PID and KERN_FILE_BYUID. In > these cases sysctl_file() can access file descriptor table from other > processes. File descriptor table of caller process can be accessed by > other threads too. The file instances from file descriptor table will be > accessed too. So file descriptor table and the file instances within > should be protected in these cases. The patch below adds protection to > file instances only. Really, each foreign process should be locked here, > not only file descriptor table, but not in this patch. Races between > sysctl_file() and process destruction denied by kernel lock. You need to be a lot more specific about the sequence of events that you're concerned with. Protections against what? So while it's not clear what problem this diff is supposed to solve, it does make the *real* problem with this sysctl, lock of locking of the process, much more likely to be hit, thus making things worse instead of better. You need a lot more than handwaving to justify that. Philip Guenther
