On 2016/10/17 23:30, Dan Streetman wrote: > On Mon, Oct 17, 2016 at 8:48 AM, zhong jiang <zhongjiang@xxxxxxxxxx> wrote: >> On 2016/10/17 20:03, Vitaly Wool wrote: >>> Hi Zhong Jiang, >>> >>> On Mon, Oct 17, 2016 at 3:58 AM, zhong jiang <zhongjiang@xxxxxxxxxx> wrote: >>>> Hi, Vitaly >>>> >>>> About the following patch, is it right? >>>> >>>> Thanks >>>> zhongjiang >>>> On 2016/10/13 12:02, zhongjiang wrote: >>>>> From: zhong jiang <zhongjiang@xxxxxxxxxx> >>>>> >>>>> At present, zhdr->first_num plus bud can exceed the BUDDY_MASK >>>>> in encode_handle, it will lead to the the caller handle_to_buddy >>>>> return the error value. >>>>> >>>>> The patch fix the issue by changing the BUDDY_MASK to PAGE_MASK, >>>>> it will be consistent with handle_to_z3fold_header. At the same time, >>>>> change the BUDDY_MASK to PAGE_MASK in handle_to_buddy is better. >>> are you seeing problems with the existing code? first_num should wrap around >>> BUDDY_MASK and this should be ok because it is way bigger than the number >>> of buddies. >>> >>> ~vitaly >>> >>> . >>> >> first_num plus buddies can exceed the BUDDY_MASK. is it right? > yes. > >> (first_num + buddies) & BUDDY_MASK may be a smaller value than first_num. > yes, but that doesn't matter; the value stored in the handle is never > accessed directly. > >> but (handle - zhdr->first_num) & BUDDY_MASK will return incorrect value >> in handle_to_buddy. > the subtraction and masking will result in the correct buddy number, > even if (handle & BUDDY_MASK) < zhdr->first_num. yes, I see. it is hard to read. > However, I agree it's nonobvious, and tying the first_num size to > NCHUNKS_ORDER is confusing - the number of chunks is completely > unrelated to the number of buddies. yes. indeed. > Possibly a better way to handle first_num is to limit it to the order > of enum buddy to the actual range of possible buddy indexes, which is > 0x3, i.e.: > > #define BUDDY_MASK (0x3) > > and > > unsigned short first_num:2; > > with that and a small bit of explanation in the encode_handle or > handle_to_buddy comments, it should be clear how the first_num and > buddy numbering work, including that overflow/underflow are ok (due to > the masking)... yes, It is better and clearer. Thanks for your relpy and advice. I will resend the patch. >> Thanks >> zhongjiang >> >> > . > -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>