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.
next prev parent 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®