Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp2770375imu; Tue, 6 Nov 2018 22:20:19 -0800 (PST) X-Google-Smtp-Source: AJdET5d0n20ZXrcLoomW2zIYxEEu/cRcsoGynCsD0eSowad3JeTbEgcVjcqLnsdCx33Sldn8SaZy X-Received: by 2002:a63:ae4d:: with SMTP id e13-v6mr537206pgp.315.1541571619200; Tue, 06 Nov 2018 22:20:19 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1541571619; cv=none; d=google.com; s=arc-20160816; b=IoR21SfAgNXQb7zLXmOxXbCZzAUm3ZCWzvXiLn/LlCy+f5TFPRf5BywleLGrWOAyI3 nhTDRnKKZWHM0B1VxGl/bzw93XrEvYUX6H6Ei8NzSW/B5u9PF2SV8U90V+1QCqKw2KPF LA9WJmdoJJpKn8tgA5uZO6OUL+z2wmZHTSyGS+2spLEoemIjgRM55aR3lGEYtvUEtIku J7v0UYnc5qnL+V5+2bSJ0GHXYI3FW13Eyl8qF4shftenxdiXaidatuT7V/0ewzCkg0K/ iKfDgkv+Z3ls3s7J3ZeH3/jH4x7LFC4vcxqj5T1QmGzaHcoKE+17GpyGgodV9BMSX3O4 UI7w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject; bh=UL9BDnoQkqlszxfuCalsTeeWd7XMczBa0NB76sgxeug=; b=gMrTJ2O9iVz44noYBTObxX63uNHoB7Dz44QYrEugmAxRkWgISq3sk6fjzq49jaDoKd +7lSkExFNzojnCDwx/6ygAvM6pXc81vvFYtoSK2yyucNXvR8aA6ppPthsyQRFFAi/jr9 zYLV9Qbam06hCdsN55gmXtgOlQKjcsbBigBdyMtFKYH2bZ1KFgQZjRz54uJusMD0DXyE KwmuIcRulAj8iuzAP3ognPvAs37n6YcuIBOGqb6fVis4QCd3mLBn6CwpacqL5GOgguiI YBAPGwiOra+ubcsth5vSlwODPvYlRmsIRYS7PGC1I8KTo8GpyyPYWuh4xGV7CcWBq7UL gWrg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 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. [209.132.180.67]) by mx.google.com with ESMTP id 4-v6si51541816pff.140.2018.11.06.22.20.04; Tue, 06 Nov 2018 22:20:19 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 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 S1728299AbeKGPsc (ORCPT + 99 others); Wed, 7 Nov 2018 10:48:32 -0500 Received: from mga18.intel.com ([134.134.136.126]:35422 "EHLO mga18.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726779AbeKGPsc (ORCPT ); Wed, 7 Nov 2018 10:48:32 -0500 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga006.fm.intel.com ([10.253.24.20]) by orsmga106.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 06 Nov 2018 22:19:37 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.54,474,1534834800"; d="scan'208";a="278986354" Received: from kohsamui.iil.intel.com (HELO [10.236.193.12]) ([10.236.193.12]) by fmsmga006.fm.intel.com with ESMTP; 06 Nov 2018 22:19:33 -0800 Subject: Re: [PATCH] lib/genaloc: Fix allocation of aligned buffer from non-aligned chunk To: Andrew Morton Cc: sbates@raithlin.com, logang@deltatee.com, danielmentz@google.com, mathieu.desnoyers@efficios.com, linux-kernel@vger.kernel.org, labbott@redhat.com References: <1541506853-10685-1-git-send-email-alexey.skidanov@intel.com> <20181106141131.76e94f6b1ff2859d96792aca@linux-foundation.org> From: Alexey Skidanov Message-ID: Date: Wed, 7 Nov 2018 08:21:07 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: <20181106141131.76e94f6b1ff2859d96792aca@linux-foundation.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 11/7/18 12:11 AM, Andrew Morton wrote: > On Tue, 6 Nov 2018 14:20:53 +0200 Alexey Skidanov wrote: > >> On success, gen_pool_first_fit_align() returns the bit number such that >> chunk_start_addr + (bit << order) is properly aligned. On failure, >> the bitmap size parameter is returned. >> >> When the chunk_start_addr isn't aligned properly, the >> chunk_start_addr + (bit << order) isn't aligned too. >> >> To fix this, gen_pool_first_fit_align() takes into account >> the chunk_start_addr alignment and returns the bit value such that >> chunk_start_addr + (bit << order) is properly aligned >> (exactly as it done in CMA). > > Why does this need "fixing"? Are there current callers which can > misalign chunk_start_addr? Or is there a requirement that future > callers can misalign chunk_start_addr? > I work on adding aligned allocation support for ION heaps (https://www.spinics.net/lists/linux-driver-devel/msg118754.html). Two of these heaps use genpool internally. If you want to have an ability to allocate buffers aligned on different boundaries (for example, 4K, 1MB, ...), this fix actually removes the requirement for chunk_start_addr to be aligned on the max possible alignment. Thanks, Alexey