Received: by 2002:a25:ef43:0:0:0:0:0 with SMTP id w3csp823826ybm; Wed, 27 May 2020 08:52:06 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwk6cf051ppavDFgsk8lijuHX3bsHWqyHWIkve3hUQjYlNnkMUSjkk+79GtkNtckNF0FC7s X-Received: by 2002:a17:906:11c4:: with SMTP id o4mr6966587eja.163.1590594725912; Wed, 27 May 2020 08:52:05 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1590594725; cv=none; d=google.com; s=arc-20160816; b=De7CJXjcaoQweS/OTFYAyW/dglW218nMrqk+iKKzd1wKSdfqKxsuY7jxg+0a26b8G5 LTHxr1a8lbOt6e6wopxigq0JNzercgUYTZIioifpeqEY9BX9pwQSWXV2PhLp9FVVjsRF XCI6MwVlKeHADHkwXAG04rpQlNkcpdLp3uC67fbkRoihqeDapQIQBm3J3DqWuyXHsqUy omRj9fTB4rlJrVdfi+TH+qam5Vu/lZiANebs5S4rpJIL7X55/Kayzj7kiDf96f73rHFk A796jfHpu+otCcYYX0LYkaROc0Gj0wIXd52veGLKK6BVrXzCzGbvThPDwhB9kGoFfohW Wycg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:date:from :dkim-signature; bh=7YJa5saMRdpmvcQWiah99cBIMoG1Tkr+u26njxMEKnA=; b=NHSsE9R0S2HYHYqY8MMZQGcyQ/rI315cs2gO1jodnluN0J7+RxeUSaRdQrEsk1jMSi afoc2RXMgb/kEWG9gC5HqNRD+eUAtk5wm11KlS5lwujIj6rGTDVCXZWPtwNcOBvcla/Z rG0haSTTqjA34FCecS9uFPFlMWxq3jl8r+zfZXQRs83IiXY5VtAkE2l0znCohHiYwVph tQ3vsj3NLW3SDC76NdcySb/gL+yjvZ2aO8Fqa58GQvl9XvITD3nAx122y4k91JpvalEt 0Xzt2IkSQQZpLuzN2uoJS9UiCFeNgQxXrhY/uAtYSKFM5Sm63EId3gtk/g4sI9At2y2L BPSQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b="k/tiHg8a"; 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=NONE dis=NONE) header.from=chromium.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id x8si2088250ejc.340.2020.05.27.08.51.42; Wed, 27 May 2020 08:52:05 -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=@chromium.org header.s=google header.b="k/tiHg8a"; 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=NONE dis=NONE) header.from=chromium.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730138AbgE0Mip (ORCPT + 99 others); Wed, 27 May 2020 08:38:45 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:55360 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728964AbgE0Mio (ORCPT ); Wed, 27 May 2020 08:38:44 -0400 Received: from mail-wm1-x344.google.com (mail-wm1-x344.google.com [IPv6:2a00:1450:4864:20::344]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 531D4C08C5C1 for ; Wed, 27 May 2020 05:38:44 -0700 (PDT) Received: by mail-wm1-x344.google.com with SMTP id f5so2876576wmh.2 for ; Wed, 27 May 2020 05:38:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=from:date:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=7YJa5saMRdpmvcQWiah99cBIMoG1Tkr+u26njxMEKnA=; b=k/tiHg8auqdYOndajzxN9gTWTghLMBY1djKWtYEk3Xs2loSyC6tNGpBNzsi1V1e5Q0 sXy0IbM/e69LS16IJmi8Ef8kB/l2kNim+cB6791xU3ax7Eiy31LOofzXlMGIwi2jktfo 2RxazoKHTEtqEyOaqbjd/lW1f4FMzrKfhxl+I= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:date:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=7YJa5saMRdpmvcQWiah99cBIMoG1Tkr+u26njxMEKnA=; b=fpCJX2b8cywOWxaPvQlIUuj7ZNqdMeLKAviCf60Fr+p6X4Mpq70Y9GmmoIPHABapkh gyHzXIyxrIXQYBAVlAsEYXzpB1axK/y2lxFedKbwJjJN1an+K0hYOHzIERHI6l1kSy7r WDyUUxKBogv78ByI+cyFwWAzcmv6cCTO5Y43CgVakV3Scq6bD90MpkkKR+TMwOrzGOEn sT4UG2KPCsl1ErZ8NyQBPzo7JAwYX8CwlnV6AfuA7NcPoiYCYTt2PfvYwK6f6MIU4E/p BHMH38VFLsYGEen+xnJoEbz3Vu4P7Ovpjxi4Vua7J/vwQfElLLidD9Z4M0K+uUydrCRu 57/g== X-Gm-Message-State: AOAM532vaFZ5VqmI+Q+Y0wzklIipYomCYqa9MtLYRA1SnnAJVsBXYeuq GqXi+hnvNcfQl8dMGNOgCkAJNw== X-Received: by 2002:a05:600c:2c4e:: with SMTP id r14mr4358980wmg.118.1590583122956; Wed, 27 May 2020 05:38:42 -0700 (PDT) Received: from google.com ([81.6.44.51]) by smtp.gmail.com with ESMTPSA id h74sm2831566wrh.76.2020.05.27.05.38.41 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 27 May 2020 05:38:42 -0700 (PDT) From: KP Singh X-Google-Original-From: KP Singh Date: Wed, 27 May 2020 14:38:40 +0200 To: Christoph Hellwig Cc: KP Singh , linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, bpf@vger.kernel.org, linux-security-module@vger.kernel.org, Alexei Starovoitov , Daniel Borkmann , James Morris , Alexander Viro , Martin KaFai Lau , Florent Revest Subject: Re: [PATCH bpf-next 2/4] bpf: Implement bpf_local_storage for inodes Message-ID: <20200527123840.GA12958@google.com> References: <20200526163336.63653-1-kpsingh@chromium.org> <20200526163336.63653-3-kpsingh@chromium.org> <20200527050823.GA31860@infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200527050823.GA31860@infradead.org> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 26-May 22:08, Christoph Hellwig wrote: > On Tue, May 26, 2020 at 06:33:34PM +0200, KP Singh wrote: > > From: KP Singh > > > > Similar to bpf_local_storage for sockets, add local storage for inodes. > > The life-cycle of storage is managed with the life-cycle of the inode. > > i.e. the storage is destroyed along with the owning inode. > > > > Since, the intention is to use this in LSM programs, the destruction is > > done after security_inode_free in __destroy_inode. > > NAK onbloating the inode structure. Please find an out of line way > to store your information. The other alternative is to use lbs_inode (security blobs) and we can do this without adding fields to struct inode. Here is a rough diff (only illustrative, won't apply cleanly) of the changes needed to this patch: https://gist.github.com/sinkap/1d213d17fb82a5e8ffdc3f320ec37d79 Once tracing has gets a whitelist based access to inode storage, I guess it, too, can use bpf_local_storage for inodes if CONFIG_BPF_LSM is enabled. Does this sound reasonable to the BPF folks? - KP