From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-7.2 required=3.0 tests=DKIMWL_WL_MED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FSL_HELO_FAKE,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1, USER_IN_DEF_DKIM_WL autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id CD572C3F2C1 for ; Thu, 27 Feb 2020 21:25:19 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 9AF7D246A1 for ; Thu, 27 Feb 2020 21:25:19 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="PD5AuIH9" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729685AbgB0VZT (ORCPT ); Thu, 27 Feb 2020 16:25:19 -0500 Received: from mail-pj1-f68.google.com ([209.85.216.68]:36506 "EHLO mail-pj1-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726460AbgB0VZS (ORCPT ); Thu, 27 Feb 2020 16:25:18 -0500 Received: by mail-pj1-f68.google.com with SMTP id gv17so337281pjb.1 for ; Thu, 27 Feb 2020 13:25:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=zbiMEvwdKM/tvZAA5Qj434C9S081Ob3tK31bpwxJweM=; b=PD5AuIH9YkPwMY1wk/M2YjcFyJ0ifFKkRpny5ZyGDYGn1QOO/zohITOuyJrm8SULUl 7i+MnHC+yUTXTPi9Ej+G5yNVS3jFkcc7VmG08QcNrBd6venEz216NN4gW5ri9dfRMEY5 T9q3N+SI14tw/2hmTyKa+XjXBZtxMwuu/SYW/t2qpCgLUResl8ne20dFgnF5Clkq+VPd fKd4zMbXTcBkWMq/t3v6ItovAlemxDo+YGgs9x//wHp14jvdIoTrJr8E7cFsndG+SFrU lQ3Su/cUXhsTRXyXiXcqdziWtx03q3ThazV8PbjImCgXZMy3x3k0A2xd3rU2TVHPaLCB 3Adg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=zbiMEvwdKM/tvZAA5Qj434C9S081Ob3tK31bpwxJweM=; b=h2DK8iHl6b9Z2s4vqS+0dbNqbCCWqk9jocsK0Z+k1ZqLlw0SFbIfe+9J2VtJMmorAX ycvdhuUa/qk40tRkuZuZyh2NB2Xew7CNJ5yWK4tTw+3B6i+gTHwNW+ge8qiLWJ6R+Mwd 3eSlmoV6ykgGn897R0XCRhYn191OqQH/Ty/S6Fmz8KYSNr4wfu3jJCqNNSDbgRSn2NPg LzsxXIkQZmvalZO0TjJuCagI2LVee18m4kGjUGJ9v2jrIGsjVeB8EfFEGkJTn+M+TqVI +ZnEyI51nd08jK5Bj78Mhane7nkHo9b5EuW4HajfmqM8eMbs/PBOF1btSNbpbm63A7hB 9XZQ== X-Gm-Message-State: APjAAAVMhx0lcaP4mh4aI3m19qJEnnMQvnf+3yIUPxkBLDp171I33J5s ZY5295QyUqgshhwgS4xwFOkXzA== X-Google-Smtp-Source: APXvYqx9TDG0Lr2SN5dRxW/+L8a98eXpzWzxOnFNh71eBbIDihuNaU52qVET1Y7r5ElfIRGM27CypQ== X-Received: by 2002:a17:902:6907:: with SMTP id j7mr807838plk.88.1582838717243; Thu, 27 Feb 2020 13:25:17 -0800 (PST) Received: from google.com ([2620:15c:201:0:7f8c:9d6e:20b8:e324]) by smtp.gmail.com with ESMTPSA id k9sm8493396pfh.153.2020.02.27.13.25.16 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 27 Feb 2020 13:25:16 -0800 (PST) Date: Thu, 27 Feb 2020 13:25:12 -0800 From: Satya Tangirala To: Eric Biggers Cc: Christoph Hellwig , linux-block@vger.kernel.org, linux-scsi@vger.kernel.org, linux-fscrypt@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-f2fs-devel@lists.sourceforge.net, linux-ext4@vger.kernel.org, Barani Muthukumaran , Kuohong Wang , Kim Boojin Subject: Re: [PATCH v7 1/9] block: Keyslot Manager for Inline Encryption Message-ID: <20200227212512.GA162309@google.com> References: <20200221115050.238976-1-satyat@google.com> <20200221115050.238976-2-satyat@google.com> <20200221170434.GA438@infradead.org> <20200221173118.GA30670@infradead.org> <20200227181411.GB877@sol.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200227181411.GB877@sol.localdomain> User-Agent: Mutt/1.12.2 (2019-09-21) Sender: linux-fscrypt-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-fscrypt@vger.kernel.org On Thu, Feb 27, 2020 at 10:14:11AM -0800, Eric Biggers wrote: > On Fri, Feb 21, 2020 at 09:31:18AM -0800, Christoph Hellwig wrote: > > On Fri, Feb 21, 2020 at 09:04:34AM -0800, Christoph Hellwig wrote: > > > Given that blk_ksm_get_slot_for_key returns a signed keyslot that > > > can return errors, and the only callers stores it in a signed variable > > > I think this function should take a signed slot as well, and the check > > > for a non-negative slot should be moved here from the only caller. > > > > Actually looking over the code again I think it might be better to > > return only the error code (and that might actually be a blk_status_t), > > and then use an argument to return a pointer to the actual struct > > keyslot. That gives us much easier to understand code and better > > type safety. > > That doesn't make sense because the caller only cares about the keyslot number, > not the 'struct keyslot'. The 'struct keyslot' is internal to > keyslot-manager.c, as it only contains keyslot management information. > I think it does make some sense at least to make the keyslot type opaque to most of the system other than the driver itself (the driver will now have to call a function like blk_ksm_slot_idx_for_keyslot to actually get a keyslot number at the end of the day). Also this way, the keyslot manager can verify that the keyslot passed to blk_ksm_put_slot is actually part of that keyslot manager (and that somebody isn't releasing a slot number that was actually acquired from a different keyslot manager). I don't think it's much benefit or loss either way, but I already switched to passing pointers to struct keyslot around instead of ints, so I'll keep it that way unless you strongly feel that using ints in this case is better than struct keyslot *. > Your earlier suggestion of making blk_ksm_put_slot() be a no-op on a negative > keyslot number sounds fine though. > > - Eric From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=0.3 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FSL_HELO_FAKE,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id C295BC3F2C1 for ; Thu, 27 Feb 2020 21:25:29 +0000 (UTC) Received: from lists.sourceforge.net (lists.sourceforge.net [216.105.38.7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 8602B246A1; Thu, 27 Feb 2020 21:25:29 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=lists.sourceforge.net header.i=@lists.sourceforge.net header.b="eSxGwg6M"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=sourceforge.net header.i=@sourceforge.net header.b="cRADfYRb"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=sf.net header.i=@sf.net header.b="faKNKR8+"; dkim=neutral (0-bit key) header.d=google.com header.i=@google.com header.b="PD5AuIH9" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 8602B246A1 Authentication-Results: mail.kernel.org; dmarc=pass (p=none dis=none) header.from=lists.sourceforge.net Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=linux-f2fs-devel-bounces@lists.sourceforge.net DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.sourceforge.net; s=beta; h=Content-Transfer-Encoding:Content-Type:Cc: Reply-To:From:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:Subject:In-Reply-To:MIME-Version:References: Message-ID:To:Date:Sender:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=4G28zG2XRrVEVPSSe6x2qwNUXKlBrq2Meg6u0ad6l5I=; b=eSxGwg6MrIsDq+6EZtVdMwMSG rXc94jazTzqRqMdSp13r5Pk76ZRm1CXj4SpiZhTTRzQHTX3+87zhIwM0+iidSzlp1IvBRqnguzit1 JGyxRBVsbAQ/wB7GhaSKLG2gQfJdrl2n6YJ+J+eeHlU6NLJX15s/TZwarL9ZitABVdTXE=; Received: from [127.0.0.1] (helo=sfs-ml-4.v29.lw.sourceforge.com) by sfs-ml-4.v29.lw.sourceforge.com with esmtp (Exim 4.90_1) (envelope-from ) id 1j7Qeu-0000F2-ON; Thu, 27 Feb 2020 21:25:28 +0000 Received: from [172.30.20.202] (helo=mx.sourceforge.net) by sfs-ml-4.v29.lw.sourceforge.com with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1) (envelope-from ) id 1j7Qet-0000Es-Oj for linux-f2fs-devel@lists.sourceforge.net; Thu, 27 Feb 2020 21:25:27 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sourceforge.net; s=x; h=In-Reply-To:Content-Type:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=zbiMEvwdKM/tvZAA5Qj434C9S081Ob3tK31bpwxJweM=; b=cRADfYRbZ2IGaxP/gSNoMMVrki t80MMWzTI/XoH/2iNXH/GT3YwjEjHLdsFUvYV0ZpOVhqKpyFGyUy0HYDeXQroX1D23IbB6rSoZH3p 9m/swcYH8QDo0L6yc+alsxsYz3CXiEhA6UlzmOqez8SobiXPfEPeCgOUVYLlc8u76MoQ=; DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sf.net; s=x ; h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To :From:Date:Sender:Reply-To:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=zbiMEvwdKM/tvZAA5Qj434C9S081Ob3tK31bpwxJweM=; b=faKNKR8+SDJAkQ8uqJMx8gwrj1 OGT/z3fqYffH1op3tSTz28k0JhMeJ1xroBzdz7iGj6nUAHhEdLLGtOWF3YI/HB7vSEBS8HqOWqxCA ivXREXhn/SDHrY6tgreHpDXQndMNhcHScqViZu/1LLsB2RezRSxMeds2NoFn6X1U42HM=; Received: from mail-pj1-f66.google.com ([209.85.216.66]) by sfi-mx-3.v28.lw.sourceforge.com with esmtps (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.92.2) id 1j7Qep-007zw1-AW for linux-f2fs-devel@lists.sourceforge.net; Thu, 27 Feb 2020 21:25:27 +0000 Received: by mail-pj1-f66.google.com with SMTP id ep11so332874pjb.2 for ; Thu, 27 Feb 2020 13:25:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=zbiMEvwdKM/tvZAA5Qj434C9S081Ob3tK31bpwxJweM=; b=PD5AuIH9YkPwMY1wk/M2YjcFyJ0ifFKkRpny5ZyGDYGn1QOO/zohITOuyJrm8SULUl 7i+MnHC+yUTXTPi9Ej+G5yNVS3jFkcc7VmG08QcNrBd6venEz216NN4gW5ri9dfRMEY5 T9q3N+SI14tw/2hmTyKa+XjXBZtxMwuu/SYW/t2qpCgLUResl8ne20dFgnF5Clkq+VPd fKd4zMbXTcBkWMq/t3v6ItovAlemxDo+YGgs9x//wHp14jvdIoTrJr8E7cFsndG+SFrU lQ3Su/cUXhsTRXyXiXcqdziWtx03q3ThazV8PbjImCgXZMy3x3k0A2xd3rU2TVHPaLCB 3Adg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=zbiMEvwdKM/tvZAA5Qj434C9S081Ob3tK31bpwxJweM=; b=tjwBEMJtiurE+mVkm3aKynPA5d5O2AhYUXR94ZxK6Z1Qa1agWsNnVFSeh39DDpjm5s 4qN7JLFnnKRH7wyPQ6DEIFErKvRD+9F7Rq16+1hg4gTZxKwc2QdVSYm5ge2lc5sdDx1B ixd4/RqEjTNMGKxKBRFvngnN2VHZKcvlkyENU76zv8vxq/Rlcb/DfmkCll9YmD1NytHd kmn2aWPgNDTE6jZce/eVBj+kN6YSmXn3UH8S/iMHPbQqb6VZf2/lHsx0LZpmVeJ9t5WX tpDYiI5z5qz0bGjOFNs/m5PvGYnk1D8PTdJG2aPees+bPdtZKGsgse0Q8oDGtgfbLbol eO0w== X-Gm-Message-State: APjAAAX7eDb6ScMoREcoymanXuMWakNgIIK95SnrfBiFf6a08TIgAxXs ukEIB2SzKoedqBuF3BQdtOrsqg== X-Google-Smtp-Source: APXvYqx9TDG0Lr2SN5dRxW/+L8a98eXpzWzxOnFNh71eBbIDihuNaU52qVET1Y7r5ElfIRGM27CypQ== X-Received: by 2002:a17:902:6907:: with SMTP id j7mr807838plk.88.1582838717243; Thu, 27 Feb 2020 13:25:17 -0800 (PST) Received: from google.com ([2620:15c:201:0:7f8c:9d6e:20b8:e324]) by smtp.gmail.com with ESMTPSA id k9sm8493396pfh.153.2020.02.27.13.25.16 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 27 Feb 2020 13:25:16 -0800 (PST) Date: Thu, 27 Feb 2020 13:25:12 -0800 To: Eric Biggers Message-ID: <20200227212512.GA162309@google.com> References: <20200221115050.238976-1-satyat@google.com> <20200221115050.238976-2-satyat@google.com> <20200221170434.GA438@infradead.org> <20200221173118.GA30670@infradead.org> <20200227181411.GB877@sol.localdomain> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20200227181411.GB877@sol.localdomain> User-Agent: Mutt/1.12.2 (2019-09-21) X-Headers-End: 1j7Qep-007zw1-AW Subject: Re: [f2fs-dev] [PATCH v7 1/9] block: Keyslot Manager for Inline Encryption X-BeenThere: linux-f2fs-devel@lists.sourceforge.net X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Satya Tangirala via Linux-f2fs-devel Reply-To: Satya Tangirala Cc: linux-block@vger.kernel.org, linux-scsi@vger.kernel.org, Kim Boojin , Kuohong Wang , Barani Muthukumaran , linux-f2fs-devel@lists.sourceforge.net, Christoph Hellwig , linux-fscrypt@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-ext4@vger.kernel.org Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: linux-f2fs-devel-bounces@lists.sourceforge.net On Thu, Feb 27, 2020 at 10:14:11AM -0800, Eric Biggers wrote: > On Fri, Feb 21, 2020 at 09:31:18AM -0800, Christoph Hellwig wrote: > > On Fri, Feb 21, 2020 at 09:04:34AM -0800, Christoph Hellwig wrote: > > > Given that blk_ksm_get_slot_for_key returns a signed keyslot that > > > can return errors, and the only callers stores it in a signed variable > > > I think this function should take a signed slot as well, and the check > > > for a non-negative slot should be moved here from the only caller. > > > > Actually looking over the code again I think it might be better to > > return only the error code (and that might actually be a blk_status_t), > > and then use an argument to return a pointer to the actual struct > > keyslot. That gives us much easier to understand code and better > > type safety. > > That doesn't make sense because the caller only cares about the keyslot number, > not the 'struct keyslot'. The 'struct keyslot' is internal to > keyslot-manager.c, as it only contains keyslot management information. > I think it does make some sense at least to make the keyslot type opaque to most of the system other than the driver itself (the driver will now have to call a function like blk_ksm_slot_idx_for_keyslot to actually get a keyslot number at the end of the day). Also this way, the keyslot manager can verify that the keyslot passed to blk_ksm_put_slot is actually part of that keyslot manager (and that somebody isn't releasing a slot number that was actually acquired from a different keyslot manager). I don't think it's much benefit or loss either way, but I already switched to passing pointers to struct keyslot around instead of ints, so I'll keep it that way unless you strongly feel that using ints in this case is better than struct keyslot *. > Your earlier suggestion of making blk_ksm_put_slot() be a no-op on a negative > keyslot number sounds fine though. > > - Eric _______________________________________________ Linux-f2fs-devel mailing list Linux-f2fs-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel