[Top] [All Lists]

Re: [PATCH 3/3] Add timeout feature

To: "Andrew Morton" <akpm@xxxxxxxxxxxxxxxxxxxx>
Subject: Re: [PATCH 3/3] Add timeout feature
From: "Takashi Sato" <t-sato@xxxxxxxxxxxxx>
Date: Mon, 30 Jun 2008 08:13:07 +0900
Cc: <viro@xxxxxxxxxxxxxxxxxx>, <linux-ext4@xxxxxxxxxxxxxxx>, <xfs@xxxxxxxxxxx>, <dm-devel@xxxxxxxxxx>, <linux-fsdevel@xxxxxxxxxxxxxxx>, <linux-kernel@xxxxxxxxxxxxxxx>, <axboe@xxxxxxxxx>, <mtk.manpages@xxxxxxxxxxxxxx>
In-reply-to: <20080627115727.149dcb2e.akpm@xxxxxxxxxxxxxxxxxxxx>
References: <20080624160056t-sato@xxxxxxxxxxxxxxx><20080624150925.765155f0.akpm@xxxxxxxxxxxxxxxxxxxx><7B349EFCD35842D4ADAEB402D2BDCA4E@xxxxxxxxxxxxxxxx> <20080627115727.149dcb2e.akpm@xxxxxxxxxxxxxxxxxxxx>
Sender: xfs-bounce@xxxxxxxxxxx

>> - struct super_block *sb = freeze_bdev(mp->m_super->s_bdev);
>> + struct super_block *sb = freeze_bdev(mp->m_super->s_bdev, 0);
> Using NULL here is clearer and will, I expect, avoid a sparse warning.

I checked it but I couldn't find a sparse warning in xfs_fsops.c.
Can you tell me how to use NULL?

struct super_block *sb = freeze_bdev(mp->m_super->s_bdev, NULL);


It's much better to use NULL here rather than literal zero because the
reader of this code can then say "ah-hah, we're passing in a pointer". Whereas plain old "0" could be a pointer or a scalar.

The second argument's type of freeze_bdev() is "long", not pointer as below.
struct super_block *freeze_bdev(struct block_device *, long timeout_msec);

So "0" is reasonable, isn't it?

We should always use NULL to represent a null pointer in the kernel. The one acceptable exception is when testing for nullness:

if (ptr1)
if (!ptr2)

Often people will use

if (ptr1 != NULL)
if (ptr2 == NULL)

in this case as well.  (I prefer the shorter version personally, but
either is OK).

<Prev in Thread] Current Thread [Next in Thread>