All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eric Sandeen <sandeen@sandeen.net>
To: Dave Chinner <david@fromorbit.com>
Cc: xfs@oss.sgi.com
Subject: Re: [PATCH] xfs_quota: correctly initialise the default path
Date: Thu, 15 Nov 2012 22:18:20 -0600	[thread overview]
Message-ID: <50A5BE8C.1050308@sandeen.net> (raw)
In-Reply-To: <1353028488-24436-1-git-send-email-david@fromorbit.com>

On 11/15/12 7:14 PM, Dave Chinner wrote:
> From: Dave Chinner <dchinner@redhat.com>
> 
> When we initial xfs_quota, we place lots of information into the
> fs_table. This includes all the devices/mount points the user has
> specified as a global command line parameter to report on, as well
> as all the paths under project quota control.
> 
> There is a "current path" pointer (fs_path) maintained by the code
> that points somewhere into the fs_table. After the table is
> initialised, fs_path always points to the last entry in the table,
> and hence has to be re-initialised to point at the desired entry
> before it can be used properly.
> 
> In the case of xfs_quota, if the command passed on the command line
> is a non-global command, the command is called multiple times, each
> time after the libxcmd args_command() callback is run. That starts
> with an index of 0, and until the callback returns zero it will keep
> passing whatever the last returned value was into the callback.
> 
> xfs_quota supplies such a callback, and it's purpose is to iterate
> over the fs_table setting fs_path to the next mount point in the
> table. IOWs, non-global quota functions get called once for each
> mount point specified on the command line. However, it also means
> that for global functions, the fs_path pointer is not
> re-initialised and hence if there are project quotas configured the
> fs_path pointer does not point to a mount point andhence commands
> may malfunction..
> 
> The problem that demonstrated this is the report function. It does
> it's own fs_table iteration if the command requires it, and so only
> should be called once to avoid outputting the same information
> multiple times.  That's what the previous patch fixed by making the
> command global, but this now has the effect of making commands that
> need to operate on the device specified on the global command rely
> on the fs_path variable pointing at that device.
> 
> Further, commands executed by the interactive method are always
> treated as global commands, so the report command never worked as a
> global command in the presence of a configured project quota setup.
> 
> Fix the problem by initialising the fs_path pointer correctly.

tl;dr ;)  I'm all for detailed commit messages but you lost me there.
If I were searching for this fix I'd have no idea what behavior this
commit actually . . . fixes. :)

Can you say:

a) what the "previous patch" commit was, and
b) what commandline triggers this problem, and what the result is?

Sorry if I'm dense,
-Eric


> Signed-off-by: Dave Chinner <dchinner@redhat.com>
> ---
>  quota/init.c |    9 +++++++++
>  1 file changed, 9 insertions(+)
> 
> diff --git a/quota/init.c b/quota/init.c
> index 3293b90..0b481f7 100644
> --- a/quota/init.c
> +++ b/quota/init.c
> @@ -140,6 +140,15 @@ init(
>  
>  	init_commands();
>  	add_args_command(init_args_command);
> +
> +	/*
> +	 * Ensure that global commands don't end up with an invalid path pointer
> +	 * by setting the default device at the first specified on the CLI
> +	 */
> +	if (argc != optind)
> +		fs_path = fs_table_lookup(argv[optind], FS_MOUNT_POINT);
> +	else
> +		fs_path = &fs_table[0];
>  }
>  
>  int
> 

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

  reply	other threads:[~2012-11-16  4:16 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-11-16  1:14 [PATCH] xfs_quota: correctly initialise the default path Dave Chinner
2012-11-16  4:18 ` Eric Sandeen [this message]
2012-11-16  6:29   ` Dave Chinner
2012-11-17 21:15 ` Mark Tinguely
2012-11-20  3:41 ` Mark Tinguely

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=50A5BE8C.1050308@sandeen.net \
    --to=sandeen@sandeen.net \
    --cc=david@fromorbit.com \
    --cc=xfs@oss.sgi.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.