Received: by 2002:a05:6a10:206:0:0:0:0 with SMTP id 6csp256910pxj; Thu, 3 Jun 2021 06:04:21 -0700 (PDT) X-Google-Smtp-Source: ABdhPJytKcb2KozoN7Rj1KpZB+PXnvfmcgV4DFUjcJVm0rg2CPVqXuFgccSsL1G0UIqylr4EYo83 X-Received: by 2002:a05:6402:524d:: with SMTP id t13mr43968309edd.209.1622725460990; Thu, 03 Jun 2021 06:04:20 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1622725460; cv=none; d=google.com; s=arc-20160816; b=ZrLKVbZ/RoTqKy0omtsD2/I4UW8as1+c9WiUxZWfGX+PchWFf1hgLlkXmaxgLHDhc+ E8J611f+bdfMD9pW5s66owqoF48YfOYyrxAA3gRKdUHIk1hDZUum8taoQVW+d+Gzr0bc QHcooGScbo07haY5iB3yZGbwweLey89Gpgvy1Vic3L5TTRpyZsr4fK5UzsyOjCsgoF93 5CYckAjORRiEb3zhdH74C9OBaC2cjPYxb84L8/I7bcPM00nkXgpblM2C8+odqwQWWHpv aUf+vOQjmLnSdB3BBLDHaObzibDqSuLfpMXbzYQ1geGUCuCc/nsSKuj+Trm1IciOq/Yj pALA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:organization:in-reply-to :content-transfer-encoding:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:ironport-sdr :ironport-sdr; bh=6X76HN6cuLQtDGD0RKhhhjZXc4RYdycWZep2hoAcCuQ=; b=HW4V5VoKFYoEwF4ES0WtKIQrRlvRPiVFz0Z4TseqCeeyXXdl462wK0m4aFf3EF7MT6 NRPQJT6pL5hFLCMdqAE66RueLg9kf9QpaLArhlALFFUPSxyFekZsu+nyXR9tAzoOIMxk c0BEND2ljOGGhXxOqYjj08NFeSUjav7aVFxu+lf1MImBg//rAKfiUfCmjD87ECk7ogkN CKQsDKJZO60/T669iv+E2RX+jpHzVqWdP+NJfa6L9emHX3hQABL3F0MMh4wiPxVksA1Q Gm7zcgCcSznMWsBi2xVdLb5k0rVvhpwxzFPZ9Kon37YMpKZVf/REPf40elPbQkojOw+m YsbA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id a15si2411327edr.48.2021.06.03.06.03.58; Thu, 03 Jun 2021 06:04:20 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230320AbhFCNCX (ORCPT + 99 others); Thu, 3 Jun 2021 09:02:23 -0400 Received: from mga06.intel.com ([134.134.136.31]:56639 "EHLO mga06.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229916AbhFCNCW (ORCPT ); Thu, 3 Jun 2021 09:02:22 -0400 IronPort-SDR: JrmE5VTCkgQVTB4ZXRI6J7ErXwcxZSyDNL35QJ+BYmdtOYyMr1OEjd6dLi5Bfmu7L5i+i7hHbw Y7CPTzIscs0w== X-IronPort-AV: E=McAfee;i="6200,9189,10004"; a="265207505" X-IronPort-AV: E=Sophos;i="5.83,245,1616482800"; d="scan'208";a="265207505" Received: from fmsmga004.fm.intel.com ([10.253.24.48]) by orsmga104.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 03 Jun 2021 06:00:37 -0700 IronPort-SDR: jqTIsbYOI2IHqHLU8ljWa7EWe1NPu4TIHX/CH/Fp51RU1MqxfrU8D6Mla2beTWHQSeOWMYSOYQ AgLxW8nCUw0g== X-IronPort-AV: E=Sophos;i="5.83,245,1616482800"; d="scan'208";a="467951388" Received: from smile.fi.intel.com (HELO smile) ([10.237.68.40]) by fmsmga004-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 03 Jun 2021 06:00:33 -0700 Received: from andy by smile with local (Exim 4.94) (envelope-from ) id 1lomxZ-00Gwlf-Iy; Thu, 03 Jun 2021 16:00:29 +0300 Date: Thu, 3 Jun 2021 16:00:29 +0300 From: Andy Shevchenko To: Jonathan Cameron Cc: "tiantao (H)" , Tian Tao , gregkh@linuxfoundation.org, rafael@kernel.org, akpm@linux-foundation.org, linux-kernel@vger.kernel.org, song.bao.hua@hisilicon.com, Randy Dunlap , Stefano Brivio , Alexander Gordeev , "Ma, Jianpeng" , Yury Norov , Valentin Schneider , Peter Zijlstra , Daniel Bristot de Oliveira Subject: Re: [PATCH v3 1/3] lib: bitmap: introduce bitmap_print_to_buf Message-ID: References: <1622712162-7028-1-git-send-email-tiantao6@hisilicon.com> <1622712162-7028-2-git-send-email-tiantao6@hisilicon.com> <95f5e01d-79c1-28f3-f27b-bee4398308de@huawei.com> <20210603133919.00004603@Huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20210603133919.00004603@Huawei.com> Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Jun 03, 2021 at 01:39:19PM +0100, Jonathan Cameron wrote: > On Thu, 3 Jun 2021 14:11:16 +0300 > Andy Shevchenko wrote: > > > On Thu, Jun 03, 2021 at 06:33:25PM +0800, tiantao (H) wrote: > > > 在 2021/6/3 17:50, Andy Shevchenko 写道: > > > > On Thu, Jun 03, 2021 at 05:22:40PM +0800, Tian Tao wrote: > > > > > New API bitmap_print_to_buf() with bin_attribute to avoid maskp > > > > > exceeding PAGE_SIZE. bitmap_print_to_pagebuf() is a special case > > > > > of bitmap_print_to_buf(), so in bitmap_print_to_pagebuf() call > > > > > bitmap_print_to_buf(). > > > > ... > > > > > > > + * @count: the maximum number of bytes to print > > > > > > > + size = memory_read_from_buffer(buf, count, &off, data, strlen(data) + 1); > > > > Are you sure you have put parameters in the correct order? > > > > > > yes, I already test it. > > > > > > ssize_t memory_read_from_buffer(void *to, size_t count, loff_t *ppos, > > >                                 const void *from, size_t available) > > > > Have you read the meaning of count and available? > > Please, double check that they are filled with correct values. > > Ok, I don't get this one either so can you give us more of a hint? There is no hint, as you noticed the documentation of the function is a bit confusing. > /** > * memory_read_from_buffer - copy data from the buffer > * @to: the kernel space buffer to read to > * @count: the maximum number of bytes to read > * @ppos: the current position in the buffer > * @from: the buffer to read from > * @available: the size of the buffer > * > * The memory_read_from_buffer() function reads up to @count bytes from the > * buffer @from at offset @ppos into the kernel space address starting at @to. > * > * On success, the number of bytes read is returned and the offset @ppos is > * advanced by this number, or negative value is returned on error. > **/ > > These docs do end up rather confusing by using the term buffer for multiple things > but taking what is passed in. > > Count is the maximum in the sense of how many bytes we are requesting are read > which indeed should be count here as that reflects what userspace asked for. > > Avail is the size of the buffer we are reading from. Now that's slightly > ambiguous in the docs in the sense of 'buffer' could mean the to buffer or > the from buffer. However, I'd assume count is definitely <= size of the space > after address to in the to buffer, so I would assume that means available > is the size of the from buffer. Here that is strlen() + 1, so looks fine. > > This interpretation also lines up with the implementation. > > So what are we missing? Thanks for double checking and explaining. > > > > I guess you have to provide the test case(s). Just test cases is what we are missing. Then we can play around with different input to see if it's all correct. -- With Best Regards, Andy Shevchenko