From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S935153AbcJRByU (ORCPT ); Mon, 17 Oct 2016 21:54:20 -0400 Received: from szxga01-in.huawei.com ([58.251.152.64]:5038 "EHLO szxga01-in.huawei.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932571AbcJRByM (ORCPT ); Mon, 17 Oct 2016 21:54:12 -0400 Message-ID: <580580AE.6070200@huawei.com> Date: Tue, 18 Oct 2016 09:53:50 +0800 From: zhong jiang User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Dan Streetman CC: Vitaly Wool , Dave Chinner , Seth Jennings , Andrew Morton , Michal Hocko , "Vlastimil Babka" , LKML , Linux-MM Subject: Re: [PATCH v2] z3fold: fix the potential encode bug in encod_handle References: <1476331337-17253-1-git-send-email-zhongjiang@huawei.com> <5804305F.4030302@huawei.com> <5804C88F.7040000@huawei.com> In-Reply-To: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.177.29.68] X-CFilter-Loop: Reflected Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2016/10/17 23:30, Dan Streetman wrote: > On Mon, Oct 17, 2016 at 8:48 AM, zhong jiang wrote: >> On 2016/10/17 20:03, Vitaly Wool wrote: >>> Hi Zhong Jiang, >>> >>> On Mon, Oct 17, 2016 at 3:58 AM, zhong jiang wrote: >>>> Hi, Vitaly >>>> >>>> About the following patch, is it right? >>>> >>>> Thanks >>>> zhongjiang >>>> On 2016/10/13 12:02, zhongjiang wrote: >>>>> From: zhong jiang >>>>> >>>>> 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 >> >> > . >