From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755246AbdBGQH1 (ORCPT ); Tue, 7 Feb 2017 11:07:27 -0500 Received: from mail-pg0-f48.google.com ([74.125.83.48]:35062 "EHLO mail-pg0-f48.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755101AbdBGQFV (ORCPT ); Tue, 7 Feb 2017 11:05:21 -0500 Subject: Re: [PATCH v4 2nd 1/4] ramoops: Add __ramoops_init_prz() as generic function To: =?UTF-8?B?5bKp5p2+5L+h5rSLIC8gSVdBTUFUU1XvvIxOT0JVSElSTw==?= , Anton Vorontsov , Colin Cross , Kees Cook , Tony Luck References: <1485827915-9620-1-git-send-email-nobuhiro.iwamatsu.kw@hitachi.com> <1485827915-9620-2-git-send-email-nobuhiro.iwamatsu.kw@hitachi.com> <8035b840-8f84-35c4-60e7-5d1c4c8e9b5f@android.com> Cc: "linux-kernel@vger.kernel.org" , =?UTF-8?B?6Zi/5Y+j6Kqg5Y+4IC8gQUdVQ0hJ77yMU0VJSkk=?= , Shuah Khan From: Mark Salyzyn Message-ID: <5ecf32e0-2ef0-12b8-d259-0f1663f03d57@android.com> Date: Tue, 7 Feb 2017 08:05:19 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=iso-2022-jp; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 02/07/2017 12:51 AM, 岩松信洋 / IWAMATSU,NOBUHIRO wrote: > Hi, > > Thanks for your review. > >> -----Original Message----- >> From: Mark Salyzyn [mailto:salyzyn@android.com] >> Sent: Friday, February 03, 2017 7:13 AM >> To: 岩松信洋 / IWAMATSU,NOBUHIRO; Anton Vorontsov; Colin Cross; Kees Cook; >> Tony Luck >> Cc: linux-kernel@vger.kernel.org; Hiraku Toyooka; 阿口誠司 / AGUCHI, >> SEIJI; Shuah Khan >> Subject: Re: [PATCH v4 2nd 1/4] ramoops: Add __ramoops_init_prz() as generic >> function >> >> On 01/30/2017 05:58 PM, Nobuhiro Iwamatsu wrote: >>> + >>> + if (zap && *paddr + sz - cxt->phys_addr > cxt->size) { >>> + dev_err(dev, "no room for %s mem region (0x%zx@0x%llx) in >> (0x%lx@0x%llx)\n", >>> + name, sz, (unsigned long long)*paddr, >>> + cxt->size, (unsigned long long)cxt->phys_addr); >>> + return -ENOMEM; >>> + } >>> + >> Why not allow this limit check for ramoops_init_prsz call? >> > This code is controlled by flag of zap. > If zap is false, __ramoops_init_prz() is worked same as original ramoops_init_przs(). > > Best regards, > Nobuhiro I agree, preserve functionality as is. Please consider removing the need for zap && in a future patch, as I _believe_ (untested, and no deep dive) that the limit check is relevant for the zap is false path as well and may have been an oversight. -- Mark