linux-xfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Vincenzo Frascino <vincenzo.frascino@arm.com>
To: Eric Sandeen <sandeen@sandeen.net>,
	darrick.wong@oracle.com, linux-xfs@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] xfs: Fix xfs_dir2_sf_entry_t size check
Date: Thu, 9 Jan 2020 15:35:46 +0000	[thread overview]
Message-ID: <1a540ee4-6597-c79e-1bce-6592cb2f3eae@arm.com> (raw)
In-Reply-To: <c43539f2-aa9b-4afa-985c-c438099732ff@sandeen.net>

[-- Attachment #1: Type: text/plain, Size: 2794 bytes --]

Hi Eric,

On 09/01/2020 15:01, Eric Sandeen wrote:
> On 1/9/20 8:14 AM, Vincenzo Frascino wrote:
>> xfs_check_ondisk_structs() verifies that the sizes of the data types
>> used by xfs are correct via the XFS_CHECK_STRUCT_SIZE() macro.
>>
>> xfs_dir2_sf_entry_t size is set erroneously to 3 which breaks the
>> compilation with the assertion below:
>>
>> In file included from linux/include/linux/string.h:6,
>>                  from linux/include/linux/uuid.h:12,
>>                  from linux/fs/xfs/xfs_linux.h:10,
>>                  from linux/fs/xfs/xfs.h:22,
>>                  from linux/fs/xfs/xfs_super.c:7:
>> In function ‘xfs_check_ondisk_structs’,
>>     inlined from ‘init_xfs_fs’ at linux/fs/xfs/xfs_super.c:2025:2:
>> linux/include/linux/compiler.h:350:38:
>>     error: call to ‘__compiletime_assert_107’ declared with attribute
>>     error: XFS: sizeof(xfs_dir2_sf_entry_t) is wrong, expected 3
>>     _compiletime_assert(condition, msg, __compiletime_assert_, __LINE__)
>>
>> Restore the correct behavior defining the correct size.
> 
> # pahole -C xfs_dir2_sf_entry fs/xfs/xfs.o 
> 
> struct xfs_dir2_sf_entry {
> 	__u8                       namelen;              /*     0     1 */
> 	__u8                       offset[2];            /*     1     2 */
> 	__u8                       name[0];              /*     3     0 */
> 
> 	/* size: 3, cachelines: 1, members: 3 */
> 	/* last cacheline: 3 bytes */
> };
> 
> Can you please the same command on your machine, along with which arm abi is
> in use etc just for clarity?
>

The abi is arm32 eabihf. You can reproduce my scenario using randconfig with
seed 0x72F68201.

In this case I get size 4, hence my patch.

If I enable xfs on the defconfig though size is 3 accordingly to what you have
reported. I will continue the investigation.

Vincenzo

> -Eric
> 
>> Cc: "Darrick J. Wong" <darrick.wong@oracle.com>
>> Signed-off-by: Vincenzo Frascino <vincenzo.frascino@arm.com>
>> ---
>>  fs/xfs/xfs_ondisk.h | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/fs/xfs/xfs_ondisk.h b/fs/xfs/xfs_ondisk.h
>> index b6701b4f59a9..ee487ddc60c7 100644
>> --- a/fs/xfs/xfs_ondisk.h
>> +++ b/fs/xfs/xfs_ondisk.h
>> @@ -104,7 +104,7 @@ xfs_check_ondisk_structs(void)
>>  	XFS_CHECK_STRUCT_SIZE(xfs_dir2_leaf_hdr_t,		16);
>>  	XFS_CHECK_STRUCT_SIZE(xfs_dir2_leaf_t,			16);
>>  	XFS_CHECK_STRUCT_SIZE(xfs_dir2_leaf_tail_t,		4);
>> -	XFS_CHECK_STRUCT_SIZE(xfs_dir2_sf_entry_t,		3);
>> +	XFS_CHECK_STRUCT_SIZE(xfs_dir2_sf_entry_t,		4);
>>  	XFS_CHECK_OFFSET(xfs_dir2_sf_entry_t, namelen,		0);
>>  	XFS_CHECK_OFFSET(xfs_dir2_sf_entry_t, offset,		1);
>>  	XFS_CHECK_OFFSET(xfs_dir2_sf_entry_t, name,		3);
>>

-- 
Regards,
Vincenzo

[-- Attachment #2: pEpkey.asc --]
[-- Type: application/pgp-keys, Size: 14291 bytes --]

  reply	other threads:[~2020-01-09 15:35 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-09 14:14 [PATCH] xfs: Fix xfs_dir2_sf_entry_t size check Vincenzo Frascino
2020-01-09 15:01 ` Eric Sandeen
2020-01-09 15:35   ` Vincenzo Frascino [this message]
2020-01-09 16:50     ` Darrick J. Wong
     [not found]       ` <435bcb71-9126-b1f1-3803-4977754b36ff@arm.com>
2020-01-13 13:55         ` Arnd Bergmann
2020-01-13 13:58           ` Christoph Hellwig
2020-01-13 14:06             ` Arnd Bergmann
2020-01-13 17:01               ` Darrick J. Wong
2020-01-13 17:04                 ` Eric Sandeen
2020-01-13 17:26                 ` Vincenzo Frascino
2020-01-13 14:05           ` Vincenzo Frascino
2020-01-12  0:44 ` kbuild test robot

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1a540ee4-6597-c79e-1bce-6592cb2f3eae@arm.com \
    --to=vincenzo.frascino@arm.com \
    --cc=darrick.wong@oracle.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-xfs@vger.kernel.org \
    --cc=sandeen@sandeen.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).