Hi Vyacheslav, On Tue, 14 May 2013 10:50:54 +0400, Vyacheslav Dubeyko wrote: > Hi Ryusuke, > > On Tue, 2013-05-14 at 03:18 +0900, Ryusuke Konishi wrote: > > [snip] >> >> > /** >> > + * nilfs_palloc_count_max_entries - count max number of entries that can be >> > + * described by @desc_blocks >> > + * @inode: inode of metadata file using this allocator >> > + * @desc_blocks: descriptor blocks count >> > + */ >> > +u64 nilfs_palloc_count_max_entries(struct inode *inode, >> > + unsigned int desc_blocks) >> >> The logical upper limit of descriptor block count is 2 ^ 43 (in the >> case of 64-bit architecture), so the desc_blocks argument should have >> unsigned long type. >> > > I think that in real world the int type will be enough for descriptor > blocks count. Moreover, I use atomic_t type for storing knowledge about > current known descriptor blocks count in nilfs_mdt_info structure. If > you insist on using unsigned long type then atomic_t type is not good > choice. I pointed out that it looks to have a potential overflow issue which may lead to security breakage. (the atomic_t type counter sounds another overflow issue). > But do you really think that we have to use the unsigned long > type for descriptor blocks count? Well, 32-bit descriptor blocks count is enough. Ok, let's define the maximum number of descriptor blocks (to 2 ^ 32 - 1) and set upper limit on the number of entries with the value. One thing we should care is the persistent object allocater is also used by DAT metadata file though it doesn't use this count up logic at present. The DAT file contains 128 entries of virtual blocks per disk block, then each descriptor block handles up to 128 * 4096 * 8 * 4096 / 4 = 2 ^ 32 virtual blocks in the case of 4kB block. So, 32-bit wide descriptor number seems enough also for the DAT file. (2 ^ 64 virtual blocks can be maintained in the DAT file). Regards, Ryusuke Konishi > With the best regards, > Vyacheslav Dubeyko. > > > -- > To unsubscribe from this list: send the line "unsubscribe linux-nilfs" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
