mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@osdl.org>
To: Jan Kara <jack@suse.cz>
Cc: linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org
Subject: Re: [PATCH] Journalled quota (fwd)
Date: Thu, 12 Feb 2004 18:06:59 -0800	[thread overview]
Message-ID: <20040212180659.7d5bcb07.akpm@osdl.org> (raw)
In-Reply-To: <20040212111128.GA32552@atrey.karlin.mff.cuni.cz>

Jan Kara <jack@suse.cz> wrote:
>
>   Here comes journalled quota patch for 2.6.3-rc2.

Could you please document the locking rules?  For example, functions such
as DQUOT_FREE_SPACE_NODIRTY() (and all similar) should have a little
comment above them describing the caller's locking responsibilities.

Because it looks to me like DQUOT_FREE_SPACE_NODIRTY() is supposed to be
called under i_lock, but will call dquot_free_space(), which does
down_read().


I didn't review your changes to the ext3 transaction space reservation
constants.  Did you get them right?  Mistakes here tend to take a long time
to show up.

In ext3_orphan_cleanup():

  - Local variable `i' is unused if !CONFIG_QUOTA and will generate a
    compiler warning.

  - This

	for (i=0; i < MAXQUOTAS; i++)

    introduces coding style inconsistency.  Please do

	for (i = 0; i < MAXQUOTAS; i++)

  - Please edit in an 80-column xterm.  Changes you have made to this
    filesystem are quite infuriating to those who _do_ use 80-cols and need
    to be cleaned up.

  - This

	for (i=0; i < MAXQUOTAS; i++)
		if (EXT3_SB(sb)->s_qf_names[i]) {
			int ret = ext3_quota_on_mount(sb, i);

    introduces coding style inconsistency.  Please do

	for (i=0; i < MAXQUOTAS; i++) {
		if (EXT3_SB(sb)->s_qf_names[i]) {
			int ret = ext3_quota_on_mount(sb, i);

    (several places)


Please document writes_to_blocks()


The locking in v2_commit_dquot() looks fishy.

The locking in dquot_mark_dquot_dirty() and in mark_info_dirty() also look
fishy.  For example:

	void mark_info_dirty(struct super_block *sb, int type)
	{
		spin_lock(&dq_data_lock);
		set_bit(DQF_INFO_DIRTY_B, &sb_dqopt(sb)->info[type].dqi_flags);
		spin_unlock(&dq_data_lock);
	}

what is the spinlock doing there?


I'm not really in a position to review the deadlockiness of this code
without some sort of documentation of the lock ranking (including where
journal_start() sits in that ranking).  Is that something you could add?

Thanks.

  reply	other threads:[~2004-02-13  2:05 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-02-12 11:11 Jan Kara
2004-02-13  2:06 ` Andrew Morton [this message]
2004-02-13 16:12   ` Jan Kara

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=20040212180659.7d5bcb07.akpm@osdl.org \
    --to=akpm@osdl.org \
    --cc=jack@suse.cz \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@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

all inboxes | Powered by JetHome®