> Strange, I never even knew recently_deleted() existed, even though it was > added to the tree 4 years ago yesterday. It looks like this is only used > with the no-journal code, which I don't really interact with. > > One thing I did notice when looking at it is that there is a Y2038 bug in > recently_deleted(), as it is comparing 32-bit i_dtime directly with 64-bit > get_seconds(). I don't think dtime has widened on the disk layout for ext4 according to https://ext4.wiki.kernel.org/index.php/Ext4_Disk_Layout. So I am not sure how fixing the internal implementation would be useful until we do that. Is there a plan for that? As far as get_seconds() is concerned, get_seconds() returns unsigned long which is 64 bits on a 64 bit arch and 32 bit on a 32 bit arch. Since dtime variable is declared as unsigned long in this function, same holds for the size of this variable. There is no y2038 problem on a 64 bit machine. So moving to the case of a 32 bit machine: get_seconds() can return values until year 2106. And, recentcy at max can only be 35. Analyzing the current line: if (dtime && (dtime < now) && (now < dtime + recentcy)) The above equation should work fine at least until 35 seconds before y2038 deadline. -Deepa
