Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1502110

Re: [PATCH v2] z3fold: fix the potential encode bug in encod_handle

Show all headers | View raw

On Mon, Oct 17, 2016 at 8:48 AM, zhong jiang <zhongjiang@huawei.com> 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@huawei.com> wrote:
> >> Hi,  Vitaly
> >>
> >> About the following patch,  is it right?
> >>
> >> Thanks
> >> zhongjiang
> >> On 2016/10/13 12:02, zhongjiang wrote:
> >>> From: zhong jiang <zhongjiang@huawei.com>
> >>>
> >>> 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.

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.

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)...

>
>   Thanks
>   zhongjiang
>
>

Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

[PATCH v2] z3fold: fix the potential encode bug in encod_handle zhongjiang <zhongjiang@huawei.com> - 2016-10-13 06:10 +0200
  Re: [PATCH v2] z3fold: fix the potential encode bug in encod_handle zhong jiang <zhongjiang@huawei.com> - 2016-10-17 04:00 +0200
    Re: [PATCH v2] z3fold: fix the potential encode bug in encod_handle Vitaly Wool <vitalywool@gmail.com> - 2016-10-17 14:10 +0200
      Re: [PATCH v2] z3fold: fix the potential encode bug in encod_handle zhong jiang <zhongjiang@huawei.com> - 2016-10-17 15:40 +0200
        Re: [PATCH v2] z3fold: fix the potential encode bug in encod_handle Dan Streetman <ddstreet@ieee.org> - 2016-10-17 17:40 +0200
          Re: [PATCH v2] z3fold: fix the potential encode bug in encod_handle zhong jiang <zhongjiang@huawei.com> - 2016-10-18 04:00 +0200
      Re: [PATCH v2] z3fold: fix the potential encode bug in encod_handle zhong jiang <zhongjiang@huawei.com> - 2016-10-17 16:20 +0200

csiph-web