From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi0-x242.google.com (mail-oi0-x242.google.com [IPv6:2607:f8b0:4003:c06::242]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 356D721A6F107 for ; Wed, 10 May 2017 12:08:28 -0700 (PDT) Received: by mail-oi0-x242.google.com with SMTP id m17so760802oik.2 for ; Wed, 10 May 2017 12:08:28 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <20170510180214.16852-17-hch@lst.de> References: <20170510180214.16852-1-hch@lst.de> <20170510180214.16852-17-hch@lst.de> From: Amir Goldstein Date: Wed, 10 May 2017 22:08:25 +0300 Message-ID: Subject: Re: [PATCH 16/16] fs: switch ->s_uuid to uuid_t List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: linux-nvdimm-bounces@lists.01.org Sender: "Linux-nvdimm" To: Christoph Hellwig Cc: linux-xfs , linux-raid@vger.kernel.org, linux-nvdimm@lists.01.org, Mimi Zohar , linux-kernel , David Howells , linux-fsdevel , Andy Shevchenko , Shaohua Li , Steven Whitehouse List-ID: On Wed, May 10, 2017 at 9:02 PM, Christoph Hellwig wrote: > For some file systems we still memcpy into it, but in various places this > already allows us to use the proper uuid helpers. More to come.. > Signed-off-by: Christoph Hellwig > --- Series looks good! My main concern is that filesystems with char uuid[16] are here to stay, or maybe, will be converted slowly. Considering this, perhaps we should have a helper/macro to copy from char[16] to *uuid_t and maybe BUILD_BUG_ON the size comparison? #define bytes_to_uuid(dst, src) ... > diff --git a/fs/xfs/xfs_mount.c b/fs/xfs/xfs_mount.c > index 682b336a7a6a..93a420160964 100644 > --- a/fs/xfs/xfs_mount.c > +++ b/fs/xfs/xfs_mount.c > @@ -75,7 +75,7 @@ xfs_uuid_mount( > > /* Publish UUID in struct super_block */ > BUILD_BUG_ON(sizeof(mp->m_super->s_uuid) != sizeof(uuid_t)); This BUILD_BUG is no longer needed. > - memcpy(&mp->m_super->s_uuid, uuid, sizeof(uuid_t)); > + uuid_copy(&mp->m_super->s_uuid, uuid); > > if (mp->m_flags & XFS_MOUNT_NOUUID) > return 0; [...] > diff --git a/security/integrity/evm/evm_crypto.c b/security/integrity/evm/evm_crypto.c > index d7f282d75cc1..1d32cd20009a 100644 > --- a/security/integrity/evm/evm_crypto.c > +++ b/security/integrity/evm/evm_crypto.c > @@ -164,7 +164,7 @@ static void hmac_add_misc(struct shash_desc *desc, struct inode *inode, > hmac_misc.mode = inode->i_mode; > crypto_shash_update(desc, (const u8 *)&hmac_misc, sizeof(hmac_misc)); > if (evm_hmac_attrs & EVM_ATTR_FSUUID) > - crypto_shash_update(desc, inode->i_sb->s_uuid, > + crypto_shash_update(desc, &inode->i_sb->s_uuid.b[0], I wonder if 'inode->i_sb->s_uuid.b' would have been better here Cheers, Amir. _______________________________________________ Linux-nvdimm mailing list Linux-nvdimm@lists.01.org https://lists.01.org/mailman/listinfo/linux-nvdimm From mboxrd@z Thu Jan 1 00:00:00 1970 From: Amir Goldstein Subject: Re: [PATCH 16/16] fs: switch ->s_uuid to uuid_t Date: Wed, 10 May 2017 22:08:25 +0300 Message-ID: References: <20170510180214.16852-1-hch@lst.de> <20170510180214.16852-17-hch@lst.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20170510180214.16852-17-hch-jcswGhMUV9g@public.gmane.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: linux-nvdimm-bounces-hn68Rpc1hR1g9hUCZPvPmw@public.gmane.org Sender: "Linux-nvdimm" To: Christoph Hellwig Cc: linux-xfs , linux-raid-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-nvdimm-hn68Rpc1hR1g9hUCZPvPmw@public.gmane.org, Mimi Zohar , linux-kernel , David Howells , linux-fsdevel , Andy Shevchenko , Shaohua Li , Steven Whitehouse List-Id: linux-raid.ids On Wed, May 10, 2017 at 9:02 PM, Christoph Hellwig wrote: > For some file systems we still memcpy into it, but in various places this > already allows us to use the proper uuid helpers. More to come.. > Signed-off-by: Christoph Hellwig > --- Series looks good! My main concern is that filesystems with char uuid[16] are here to stay, or maybe, will be converted slowly. Considering this, perhaps we should have a helper/macro to copy from char[16] to *uuid_t and maybe BUILD_BUG_ON the size comparison? #define bytes_to_uuid(dst, src) ... > diff --git a/fs/xfs/xfs_mount.c b/fs/xfs/xfs_mount.c > index 682b336a7a6a..93a420160964 100644 > --- a/fs/xfs/xfs_mount.c > +++ b/fs/xfs/xfs_mount.c > @@ -75,7 +75,7 @@ xfs_uuid_mount( > > /* Publish UUID in struct super_block */ > BUILD_BUG_ON(sizeof(mp->m_super->s_uuid) != sizeof(uuid_t)); This BUILD_BUG is no longer needed. > - memcpy(&mp->m_super->s_uuid, uuid, sizeof(uuid_t)); > + uuid_copy(&mp->m_super->s_uuid, uuid); > > if (mp->m_flags & XFS_MOUNT_NOUUID) > return 0; [...] > diff --git a/security/integrity/evm/evm_crypto.c b/security/integrity/evm/evm_crypto.c > index d7f282d75cc1..1d32cd20009a 100644 > --- a/security/integrity/evm/evm_crypto.c > +++ b/security/integrity/evm/evm_crypto.c > @@ -164,7 +164,7 @@ static void hmac_add_misc(struct shash_desc *desc, struct inode *inode, > hmac_misc.mode = inode->i_mode; > crypto_shash_update(desc, (const u8 *)&hmac_misc, sizeof(hmac_misc)); > if (evm_hmac_attrs & EVM_ATTR_FSUUID) > - crypto_shash_update(desc, inode->i_sb->s_uuid, > + crypto_shash_update(desc, &inode->i_sb->s_uuid.b[0], I wonder if 'inode->i_sb->s_uuid.b' would have been better here Cheers, Amir. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754138AbdEJTI3 (ORCPT ); Wed, 10 May 2017 15:08:29 -0400 Received: from mail-oi0-f65.google.com ([209.85.218.65]:34750 "EHLO mail-oi0-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753224AbdEJTI1 (ORCPT ); Wed, 10 May 2017 15:08:27 -0400 MIME-Version: 1.0 In-Reply-To: <20170510180214.16852-17-hch@lst.de> References: <20170510180214.16852-1-hch@lst.de> <20170510180214.16852-17-hch@lst.de> From: Amir Goldstein Date: Wed, 10 May 2017 22:08:25 +0300 Message-ID: Subject: Re: [PATCH 16/16] fs: switch ->s_uuid to uuid_t To: Christoph Hellwig Cc: Andy Shevchenko , linux-fsdevel , Shaohua Li , Dan Williams , David Howells , Steven Whitehouse , Mimi Zohar , linux-xfs , linux-raid@vger.kernel.org, linux-nvdimm@ml01.01.org, linux-kernel Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, May 10, 2017 at 9:02 PM, Christoph Hellwig wrote: > For some file systems we still memcpy into it, but in various places this > already allows us to use the proper uuid helpers. More to come.. > Signed-off-by: Christoph Hellwig > --- Series looks good! My main concern is that filesystems with char uuid[16] are here to stay, or maybe, will be converted slowly. Considering this, perhaps we should have a helper/macro to copy from char[16] to *uuid_t and maybe BUILD_BUG_ON the size comparison? #define bytes_to_uuid(dst, src) ... > diff --git a/fs/xfs/xfs_mount.c b/fs/xfs/xfs_mount.c > index 682b336a7a6a..93a420160964 100644 > --- a/fs/xfs/xfs_mount.c > +++ b/fs/xfs/xfs_mount.c > @@ -75,7 +75,7 @@ xfs_uuid_mount( > > /* Publish UUID in struct super_block */ > BUILD_BUG_ON(sizeof(mp->m_super->s_uuid) != sizeof(uuid_t)); This BUILD_BUG is no longer needed. > - memcpy(&mp->m_super->s_uuid, uuid, sizeof(uuid_t)); > + uuid_copy(&mp->m_super->s_uuid, uuid); > > if (mp->m_flags & XFS_MOUNT_NOUUID) > return 0; [...] > diff --git a/security/integrity/evm/evm_crypto.c b/security/integrity/evm/evm_crypto.c > index d7f282d75cc1..1d32cd20009a 100644 > --- a/security/integrity/evm/evm_crypto.c > +++ b/security/integrity/evm/evm_crypto.c > @@ -164,7 +164,7 @@ static void hmac_add_misc(struct shash_desc *desc, struct inode *inode, > hmac_misc.mode = inode->i_mode; > crypto_shash_update(desc, (const u8 *)&hmac_misc, sizeof(hmac_misc)); > if (evm_hmac_attrs & EVM_ATTR_FSUUID) > - crypto_shash_update(desc, inode->i_sb->s_uuid, > + crypto_shash_update(desc, &inode->i_sb->s_uuid.b[0], I wonder if 'inode->i_sb->s_uuid.b' would have been better here Cheers, Amir. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: MIME-Version: 1.0 In-Reply-To: <20170510180214.16852-17-hch@lst.de> References: <20170510180214.16852-1-hch@lst.de> <20170510180214.16852-17-hch@lst.de> From: Amir Goldstein Date: Wed, 10 May 2017 22:08:25 +0300 Message-ID: Subject: Re: [PATCH 16/16] fs: switch ->s_uuid to uuid_t To: Christoph Hellwig Cc: Andy Shevchenko , linux-fsdevel , Shaohua Li , Dan Williams , David Howells , Steven Whitehouse , Mimi Zohar , linux-xfs , linux-raid@vger.kernel.org, linux-nvdimm@lists.01.org, linux-kernel Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: On Wed, May 10, 2017 at 9:02 PM, Christoph Hellwig wrote: > For some file systems we still memcpy into it, but in various places this > already allows us to use the proper uuid helpers. More to come.. > Signed-off-by: Christoph Hellwig > --- Series looks good! My main concern is that filesystems with char uuid[16] are here to stay, or maybe, will be converted slowly. Considering this, perhaps we should have a helper/macro to copy from char[16] to *uuid_t and maybe BUILD_BUG_ON the size comparison? #define bytes_to_uuid(dst, src) ... > diff --git a/fs/xfs/xfs_mount.c b/fs/xfs/xfs_mount.c > index 682b336a7a6a..93a420160964 100644 > --- a/fs/xfs/xfs_mount.c > +++ b/fs/xfs/xfs_mount.c > @@ -75,7 +75,7 @@ xfs_uuid_mount( > > /* Publish UUID in struct super_block */ > BUILD_BUG_ON(sizeof(mp->m_super->s_uuid) != sizeof(uuid_t)); This BUILD_BUG is no longer needed. > - memcpy(&mp->m_super->s_uuid, uuid, sizeof(uuid_t)); > + uuid_copy(&mp->m_super->s_uuid, uuid); > > if (mp->m_flags & XFS_MOUNT_NOUUID) > return 0; [...] > diff --git a/security/integrity/evm/evm_crypto.c b/security/integrity/evm/evm_crypto.c > index d7f282d75cc1..1d32cd20009a 100644 > --- a/security/integrity/evm/evm_crypto.c > +++ b/security/integrity/evm/evm_crypto.c > @@ -164,7 +164,7 @@ static void hmac_add_misc(struct shash_desc *desc, struct inode *inode, > hmac_misc.mode = inode->i_mode; > crypto_shash_update(desc, (const u8 *)&hmac_misc, sizeof(hmac_misc)); > if (evm_hmac_attrs & EVM_ATTR_FSUUID) > - crypto_shash_update(desc, inode->i_sb->s_uuid, > + crypto_shash_update(desc, &inode->i_sb->s_uuid.b[0], I wonder if 'inode->i_sb->s_uuid.b' would have been better here Cheers, Amir.