From: Allison Henderson <allison.henderson@oracle.com>
To: Dave Chinner <david@fromorbit.com>
Cc: "Darrick J. Wong" <darrick.wong@oracle.com>, linux-xfs@vger.kernel.org
Subject: Re: [PATCH v3 17/17] Add parent pointer ioctl
Date: Wed, 29 Nov 2017 18:52:15 -0700 [thread overview]
Message-ID: <ec04ac86-f19c-007f-95dd-b16080257ced@oracle.com> (raw)
In-Reply-To: <20171130000251.GL5858@dastard>
On 11/29/2017 05:02 PM, Dave Chinner wrote:
> On Wed, Nov 29, 2017 at 03:48:50PM -0700, Allison Henderson wrote:
>>
>>
>> On 11/29/2017 02:37 PM, Dave Chinner wrote:
>>> On Tue, Nov 28, 2017 at 12:35:37PM -0800, Darrick J. Wong wrote:
>>>> On Fri, Nov 17, 2017 at 11:21:45AM -0700, Allison Henderson wrote:
>>>>> This patch adds a new file ioctl to retrieve the parent
>>>>> pointer of a given inode
>>>>
>>>> (Yes, it's time to start talking about actual use cases...)
>>>>
>>>> At a bare minimum, this is what I pictured for the "return parents of
>>>> the open file" ioctl:
>>>>
>>>> #define XFS_PPTR_MAXNAMELEN 255
>>>>
>>>> struct xfs_pptr {
>>>> u64 pp_ino;
>>>> u32 pp_gen;
>>>> u8 pp_namelen;
>>>> u8 pp_name[XFS_PPTR_MAXNAMELEN];
>>>> };
>>>
>>> That's going to be a different size on 32bit and 64 bit platforms
>>> as the structure size is a multiple of 4 bytes, not 8 bytes.
>>> That will cause problems and need complex comapt ioctl translation.
>>> Better to make pp_namelen a u32 and that will make the structure
>>> 64 bit aligned and sized on all platforms.
>>>
>>> I'd allow more than u8 for the namelen. Yes, while we currently
>>> allow on 255 bytes for a name, it would make more sense to
>>> use a u32 here so that the structure size is a multiple of it's
>>> alignment rather than having a 4 byte hole in the array we don't
>>> fill out....
>>>
>>>>
>>>> /* return parents of the handle, instead of the open fd */
>>>> #define XFS_PPTR_FLAG_HANDLE (1u << 0)
>>>>
>>>> struct xfs_pptr_info {
>>>> struct xfs_fsop_handlereq pi_handle;
>>>> struct xfs_attrlist_cursor pi_cursor;
>>>> u32 pi_flags;
>>>> u32 pi_reserved;
>>>> u32 pi_ptrs_size;
>>>> u32 pi_ptrs_used;
>>>> u64 pi_reserved2[6];
>>>> struct xfs_pptr pi_ptrs[0];
>>>> };
>>>
>>> I thought gcc had started doing weird things with variable size
>>> array declarations like this (i.e. pi_ptrs[0]) because the exact
>>> behaviour is not defined in the C standard. i.e. we need to avoid
>>> adding new declarations that do this...
>>
>> Oh, I think there's a few places in the set where I have
>> declarations like that.
>
> Yup, there are quite a few, but IIRC we can't rely on them working
> as they do right now in future compilers. So I'm pretty sure we need
> to avoid these sorts of constructs if we can. Doing something like
> this:
>
> struct xfs_pptr_info {
> struct xfs_fsop_handlereq pi_handle;
> struct xfs_attrlist_cursor pi_cursor;
> u32 pi_flags;
> u32 pi_reserved;
> u32 pi_ptrs_size;
> u32 pi_ptrs_used;
> u64 pi_reserved2[6];
>
> /*
> * An array of struct xfs_pptr follows the header
> * information. Use XFS_PPINFO_TO_PP() to access the
> * parent pointer array entries.
> */
> };
>
> And providing an accessor function:
>
> #define XFS_PPINFO_TO_PP(info, idx) \
> (&(((struct xfs_pptr *)((char *)(info) + sizeof(*(info))))[(idx)]))
>
> Will solve the problem.
>
>> Should they be some_array[1]; instead?
>
> That has problems, too. See, for example, commit ffeecc521302 ("xfs:
> Fix xfs_attr_leafblock definition"), where gcc completely mangled
> the code because it thought it could optimise away bits of the
> structure and code that "weren't used".
>
>>>> #define XFS_PPTR_INFO_SIZEOF(ptrs) (sizeof(struct xfs_pptr_info) + \
>>>> ((ptrs) * sizeof(struct xfs_pptr)));
>>>> static inline struct xfs_pptr_info *
>>>> xfs_pptr_alloc(
>>>> size_t nr_ptrs)
>>>> {
>>>> struct xfs_pptr_info *ppi;
>>>>
>>>> ppi = malloc(XFS_PPTR_INFO_SIZEOF(nr_ptrs));
>>>> if (!ppi)
>>>> return NULL;
>>>> memset(ppi, 0, XFS_PPTR_INFO_SIZEOF(nr_ptrs));
>>>> ppi->pi_ptrs_size = nr_ptrs;
>>>> return ppi;
>>>> }
>>>>
>>>> With the following example userspace program (that does no checking
>>>> whatsoever):
>>>>
>>>> int main(int argc, char *argv[])
>>>> {
>>>> struct xfs_pptr_info *ppi;
>>>> struct xfs_pptr *pp;
>>>> int fd;
>>>>
>>>> fd = open(argv[1], O_RDONLY);
>>>> ppi = xfs_pptr_alloc(32);
>>>>
>>>> while (ioctl(fd, XFS_IOC_GETPPOINTER, ppi) == 0 && ppi->pi_ptrs_used) {
>>>> for (i = 0; i < ppi->pi_ptrs_used; i++) {
>>>> printf("%llu:%u -> %s\n",
>>>> ppi->pi_ptrs[i].pp_ino,
>>>> ppi->pi_ptrs[i].pp_gen,
>>>> ppi->pi_ptrs[i].pp_name);
>
> And this becomes:
>
> for (i = 0; i < ppi->pi_ptrs_used; i++) {
> pp = XFS_PPINFO_TO_PP(ppi, i);
> printf("%llu:%u -> %s\n", pp->pp_ino, pp->pp_gen,
> pp->pp_name);
> }
>
> Cheers,
>
> Dave.
>
Alrighty then, thank you!
Allison
next prev parent reply other threads:[~2017-11-30 1:52 UTC|newest]
Thread overview: 69+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-11-17 18:21 [PATCH v3 00/17] Parent Pointers v4 Allison Henderson
2017-11-17 18:21 ` [PATCH v3 01/17] Add helper functions xfs_attr_set_args and xfs_attr_remove_args Allison Henderson
2017-11-28 19:54 ` Darrick J. Wong
2017-11-29 1:02 ` Dave Chinner
2017-11-29 18:52 ` Allison Henderson
2017-11-29 22:34 ` Allison Henderson
2017-11-17 18:21 ` [PATCH v3 02/17] Set up infastructure for deferred attribute operations Allison Henderson
2017-11-28 19:45 ` Darrick J. Wong
2017-11-29 1:19 ` Dave Chinner
2017-11-29 18:52 ` Allison Henderson
2017-11-29 18:51 ` Allison Henderson
2017-11-17 18:21 ` [PATCH v3 03/17] Add xfs_attr_set_defered and xfs_attr_remove_defered Allison Henderson
2017-11-28 19:19 ` Darrick J. Wong
2017-11-29 18:50 ` Allison Henderson
2017-11-17 18:21 ` [PATCH v3 04/17] Remove all strlen calls in all xfs_attr_* functions for attr names Allison Henderson
2017-11-28 19:10 ` Darrick J. Wong
2017-11-29 18:50 ` Allison Henderson
2017-11-17 18:21 ` [PATCH v3 05/17] xfs: get directory offset when adding directory name Allison Henderson
2017-11-28 19:07 ` Darrick J. Wong
2017-11-29 18:50 ` Allison Henderson
2017-11-17 18:21 ` [PATCH v3 06/17] xfs: get directory offset when removing " Allison Henderson
2017-11-28 19:05 ` Darrick J. Wong
2017-11-29 18:49 ` Allison Henderson
2017-11-17 18:21 ` [PATCH v3 07/17] xfs: get directory offset when replacing a " Allison Henderson
2017-11-28 19:04 ` Darrick J. Wong
2017-11-29 18:49 ` Allison Henderson
2017-11-17 18:21 ` [PATCH v3 08/17] xfs: add parent pointer support to attribute code Allison Henderson
2017-11-28 19:01 ` Darrick J. Wong
2017-11-29 18:48 ` Allison Henderson
2017-11-17 18:21 ` [PATCH v3 09/17] xfs: define parent pointer xattr format Allison Henderson
2017-11-28 18:59 ` Darrick J. Wong
2017-11-29 18:48 ` Allison Henderson
2017-11-17 18:21 ` [PATCH v3 10/17] xfs: extent transaction reservations for parent attributes Allison Henderson
2017-11-28 18:58 ` Darrick J. Wong
2017-11-29 18:48 ` Allison Henderson
2017-11-17 18:21 ` [PATCH v3 11/17] Add the extra space requirements for parent pointer attributes when calculating the minimum log size during mkfs Allison Henderson
2017-11-28 18:51 ` Darrick J. Wong
2017-11-29 18:47 ` Allison Henderson
2017-11-29 20:18 ` Darrick J. Wong
2017-11-17 18:21 ` [PATCH v3 12/17] xfs: parent pointer attribute creation Allison Henderson
2017-11-28 18:49 ` Darrick J. Wong
2017-11-28 18:54 ` Darrick J. Wong
2017-11-29 18:46 ` Allison Henderson
2017-11-17 18:21 ` [PATCH v3 13/17] xfs: add parent attributes to link Allison Henderson
2017-11-28 18:37 ` Darrick J. Wong
2017-11-29 18:45 ` Allison Henderson
2017-11-17 18:21 ` [PATCH v3 14/17] xfs: remove parent pointers in unlink Allison Henderson
2017-11-28 18:24 ` Darrick J. Wong
2017-11-29 18:44 ` Allison Henderson
2017-11-17 18:21 ` [PATCH v3 15/17] Add parent pointers to rename Allison Henderson
2017-11-28 18:20 ` Darrick J. Wong
2017-11-29 18:43 ` Allison Henderson
2017-11-17 18:21 ` [PATCH v3 16/17] Add the parent pointer support to the superblock version 5 Allison Henderson
2017-11-28 18:08 ` Darrick J. Wong
2017-11-29 18:41 ` Allison Henderson
2017-11-17 18:21 ` [PATCH v3 17/17] Add parent pointer ioctl Allison Henderson
2017-11-22 19:54 ` Allison Henderson
2017-11-22 21:07 ` Dave Chinner
2017-11-22 22:49 ` Allison Henderson
2017-11-22 21:13 ` Darrick J. Wong
2017-11-22 22:49 ` Allison Henderson
2017-11-28 20:35 ` Darrick J. Wong
2017-11-29 18:52 ` Allison Henderson
2017-11-29 21:37 ` Dave Chinner
2017-11-29 22:48 ` Allison Henderson
2017-11-30 0:02 ` Dave Chinner
2017-11-30 1:52 ` Allison Henderson [this message]
2017-11-30 21:11 ` Darrick J. Wong
2017-12-01 2:58 ` Dave Chinner
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=ec04ac86-f19c-007f-95dd-b16080257ced@oracle.com \
--to=allison.henderson@oracle.com \
--cc=darrick.wong@oracle.com \
--cc=david@fromorbit.com \
--cc=linux-xfs@vger.kernel.org \
/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).