Received: by 2002:a05:6a10:9848:0:0:0:0 with SMTP id x8csp1649572pxf; Fri, 19 Mar 2021 12:03:53 -0700 (PDT) X-Google-Smtp-Source: ABdhPJy4SofrJHmC5idI/agktCDXgsxod0GlQ8MUIQQENbOvz8pf45VIpj1MNd+lL2u+pyfWIDsd X-Received: by 2002:a17:906:f9db:: with SMTP id lj27mr6080133ejb.399.1616180632983; Fri, 19 Mar 2021 12:03:52 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1616180632; cv=none; d=google.com; s=arc-20160816; b=ihQWjuzWzkPuLHuPgQpFjo1DvVq7aMNkNbczDHkF/Oe3MSXiULYB6KBmbjEUrJPw0S v87bBfK8wpwZd1tBF89Eh8J1FpwUA4UWNWPD/Dfono/VOVNrdiKkHdrDnnEWyfamvkoZ ETrTvmvIVKPfUdaqk5tEo3OqgZbIPr8yBquSzlw3TOfkE6eJjy+jmsZzhPpVGcDc9+nB ygV+83yv3jWDhoVY64LyNUhEMUKT9WmZT1MHc+brEPbpfVAon2EdUlU35ac3pGuevZwg +px8rq+SsMgsPhxY3b9/80p0onmnR80qXvWyiVJ78grljGEvlk8muNZ1IKyAZQm8PQPL i/1A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:content-language :in-reply-to:mime-version:user-agent:date:message-id:from:references :cc:to:subject:dkim-signature; bh=8ELWO0rVxFoEW/cBhQY2SU43VC88bV8HiGiltIwNbNU=; b=g7xMvc1wveowrcTuhwBORYuGkLEr8sVXDkusrB1bM9K0ed/PYaPTApP1ok21lRKDxC QQED8Bjl9P1iRoc2JNE7VxlD/OgHWxJOF9sckdxBaXskcSqwYQcb+pwTS5tyNX300BWP 5wKQu4Ww4ySYIS+310tnokBzfrBKrx4QyTXfzTBlfdD6rVnRW7rc9w/2YacfRErutork OmyWXzUe6VxAlc4E5nC4afMxJuV97c5+3P9JE5NhUifVZrMl3tAYLL8rEWPEZI8cxBPC oeS3U2J9FiIfzd7aTXOzzNJrgWSF7dwULk7WoetKWURuZRF4E1TmhQJgumvuttVH3k+8 4vvw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=WSoSWgPZ; 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=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id du6si4705384ejc.393.2021.03.19.12.03.28; Fri, 19 Mar 2021 12:03:52 -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; dkim=pass header.i=@gmail.com header.s=20161025 header.b=WSoSWgPZ; 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=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230461AbhCSS7j (ORCPT + 99 others); Fri, 19 Mar 2021 14:59:39 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57318 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230186AbhCSS7L (ORCPT ); Fri, 19 Mar 2021 14:59:11 -0400 Received: from mail-lf1-x133.google.com (mail-lf1-x133.google.com [IPv6:2a00:1450:4864:20::133]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E7E26C06174A; Fri, 19 Mar 2021 11:59:10 -0700 (PDT) Received: by mail-lf1-x133.google.com with SMTP id m12so11571447lfq.10; Fri, 19 Mar 2021 11:59:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=8ELWO0rVxFoEW/cBhQY2SU43VC88bV8HiGiltIwNbNU=; b=WSoSWgPZfb6wMXT11SchmcKZBcjgH73N/Lbq4btmZ0Shz9AF5WurjtECp2zeUeXV/U khxjCywE5IlWSlzB+Z+W1UGdhapRnGBi10RNB74adftfCDJH9WmB5hWAUi+ViH9igQPa oKgxRfeJcsMknIqpd6kAPSHBYrAfMGkQUggG7x5gb/hLdC51f9F0WDCAIOCzDEwr6c8s qMEHkbpN3mulJZALdlMb1gCgzdBmS8K0XQqrUD+vteA5cato+QOfmd4E4S7ZmLFbAHSw TXGgfa+W8F5mqI/V/mGxgg68Kkf73FtdcLI317F2ZT4JLuGfDVLHGhba0c5CyBvmaw9R dEDw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=8ELWO0rVxFoEW/cBhQY2SU43VC88bV8HiGiltIwNbNU=; b=bNXKEdbxKRFOzJ2lDvCPz/T1ucNqEzf5IDQVpxinb14tHMB93viRbUZ8E4oZVwEEUQ C0Fi/NQ7xyewonXF3h59VY85nnROYkYd/hGdHR5Dkk87u15pDHKM3KHZBuMy0KWxx525 SHCFBp4++h8n3LvsT1UDmmNrd9MZ4XXpJLr9wOA4gnJIBHraawHwO8SAlO28jW/FbjCq i8RxXlGniOoZilUI6HJq9D3HQZ3gy9nOyRcit8/JXye+o0yK348rufu0Kn6IcBF4EBmX GoxZzs5Agk/zZM1/cQd/zACPgdlYxmA9GE0eAvaUrsHfLsSmoYlSWdVu0vSxZcJ6CaEm Fzkw== X-Gm-Message-State: AOAM5324MNeGUD2ZFRifUPgmqJ4O96coEWkcEYDWSYvc3k9Dmg76YFGD uBqYZuuICowt9MkNKKJJt45F41nI6W0= X-Received: by 2002:a19:ee16:: with SMTP id g22mr1571911lfb.513.1616180349313; Fri, 19 Mar 2021 11:59:09 -0700 (PDT) Received: from [192.168.2.145] (109-252-193-52.dynamic.spd-mgts.ru. [109.252.193.52]) by smtp.googlemail.com with ESMTPSA id x4sm876461ljj.91.2021.03.19.11.59.08 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 19 Mar 2021 11:59:09 -0700 (PDT) Subject: Re: [PATCH v4] mm: cma: support sysfs To: Minchan Kim Cc: Greg Kroah-Hartman , Andrew Morton , linux-mm , LKML , joaodias@google.com, willy@infradead.org, david@redhat.com, surenb@google.com, John Hubbard , Nicolas Chauvet , "linux-tegra@vger.kernel.org" References: <33ec18ef-8652-643a-1a53-ff7c3caf4399@gmail.com> <78883205-e6da-5bc4-dcec-b6eb921567b1@gmail.com> <72db59eb-75dc-d1ed-7a83-17052e8f22a8@gmail.com> <82bde114-60c0-3fde-43f4-844522b80673@gmail.com> From: Dmitry Osipenko Message-ID: <6bc141d2-ca07-7f03-c306-683f0f630605@gmail.com> Date: Fri, 19 Mar 2021 21:59:08 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.8.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 19.03.2021 21:18, Minchan Kim пишет: >>> + if (ZERO_OR_NULL_PTR(cma_kobjs)) >>> + goto out; >>> + >>> + do { >>> + cma = &cma_areas[i]; >>> + cma->kobj = &cma_kobjs[i]; >> Does cma really need are pointer to cma_kobj? > Do you mean something like this? > > struct cma { > .. > .. > struct kobject *kobj; > }; > > Then, how could we we make kobject dynamic model? > > We need to get struct cma from kboj like below. > > static ssize_t alloc_pages_success_show(struct kobject *kobj, > struct kobj_attribute *attr, char *buf) > { > struct cma_kobject *cma_kobj = container_of(kobj, > struct cma_kobject, kobj); > struct cma *cma = cma_kobj->cma; > > return sysfs_emit(buf, "%llu\n", > atomic64_read(&cma->nr_pages_succeeded)); > } > > So kobj should be not a pointer in the container struct. > Am I missing your point? Otherwise, it would be great if you suggest > better idea. I meant that cma_kobj->cma is okay, but cma->kobj wasn't really used anywhere since struct cma can't be released. I.e. we could write kobject_put(&cma->kobj->kobj) as kobject_put(&cma_kobjs[i].kobj); But since we won't use the array anymore and maybe will get back to use the cma_stat, then it will be fine to add the pointer.