Re: Repercussions of overflow in get_next_ino()
Hello, Nikolay Borisov: > My question is what are the repercussions of get_next_ino overflowing > and at some point having possibly multiple inodes on my system with the > same i_ino id? And why is it safe to have the inode id's overflow and > wrap around? I am afraid some applications won't work correctly. As far as I know, ls(1) and find(1) don't show the file whose inum is zero. See also Subject: [PATCH v2] vfs: get_next_ino(), never inum=0 Date: 2014-05-28 14:06:32 http://marc.info/?l=linux-fsdevel=140128600801771=2 and their thread. For tmpfs, I have another patch. Just FYI, here attached. J. R. Okajima a.patch.bz2 Description: BZip2 compressed data
Repercussions of overflow in get_next_ino()
Hello, get_next_ino would allocate a number between 0...2^32 - 1 to be used as an inode number. The implementation of this mechanism relies on an unsigned int which is 32 bits. On one server I'm observing that every couple of months grsec complains that the percpu variable last_ino overflows (due to shared_last_ino) being incremented to the limit of a 32 bit value and then then the machine becomes unstable due to grsec starting to kill processes. Now, I understand this isssue stems from the fact how grsec detects the overflow. My question is what are the repercussions of get_next_ino overflowing and at some point having possibly multiple inodes on my system with the same i_ino id? And why is it safe to have the inode id's overflow and wrap around? Would simply changing the inode numbering code work with 64 bit value remedy the situation or would it require a more involved fix? Regards, Nikolay -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Repercussions of overflow in get_next_ino()
Hello, get_next_ino would allocate a number between 0...2^32 - 1 to be used as an inode number. The implementation of this mechanism relies on an unsigned int which is 32 bits. On one server I'm observing that every couple of months grsec complains that the percpu variable last_ino overflows (due to shared_last_ino) being incremented to the limit of a 32 bit value and then then the machine becomes unstable due to grsec starting to kill processes. Now, I understand this isssue stems from the fact how grsec detects the overflow. My question is what are the repercussions of get_next_ino overflowing and at some point having possibly multiple inodes on my system with the same i_ino id? And why is it safe to have the inode id's overflow and wrap around? Would simply changing the inode numbering code work with 64 bit value remedy the situation or would it require a more involved fix? Regards, Nikolay -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Repercussions of overflow in get_next_ino()
Hello, Nikolay Borisov: My question is what are the repercussions of get_next_ino overflowing and at some point having possibly multiple inodes on my system with the same i_ino id? And why is it safe to have the inode id's overflow and wrap around? I am afraid some applications won't work correctly. As far as I know, ls(1) and find(1) don't show the file whose inum is zero. See also Subject: [PATCH v2] vfs: get_next_ino(), never inum=0 Date: 2014-05-28 14:06:32 http://marc.info/?l=linux-fsdevelm=140128600801771w=2 and their thread. For tmpfs, I have another patch. Just FYI, here attached. J. R. Okajima a.patch.bz2 Description: BZip2 compressed data
