On 2018年07月18日 15:54, Lu Fengqi wrote:
> On Wed, Jul 18, 2018 at 02:58:06PM +0800, Qu Wenruo wrote:
>>
>>
>> On 2018年07月18日 14:45, Lu Fengqi wrote:
>>> It can be fetched from the transaction handle.
>>>
>>> Signed-off-by: Lu Fengqi <lufq.f...@cn.fujitsu.com>
>>> ---
>>> fs/btrfs/qgroup.c | 13 ++++++-------
>>> fs/btrfs/qgroup.h | 5 ++---
>>> fs/btrfs/tree-log.c | 2 +-
>>> 3 files changed, 9 insertions(+), 11 deletions(-)
>>>
>>> diff --git a/fs/btrfs/qgroup.c b/fs/btrfs/qgroup.c
>>> index c85c1a0e933a..01add73cb2aa 100644
>>> --- a/fs/btrfs/qgroup.c
>>> +++ b/fs/btrfs/qgroup.c
>>> @@ -1579,10 +1579,10 @@ int btrfs_qgroup_trace_extent_post(struct
>>> btrfs_fs_info *fs_info,
>>> return 0;
>>> }
>>>
>>> -int btrfs_qgroup_trace_extent(struct btrfs_trans_handle *trans,
>>> - struct btrfs_fs_info *fs_info, u64 bytenr, u64 num_bytes,
>>> - gfp_t gfp_flag)
>>> +int btrfs_qgroup_trace_extent(struct btrfs_trans_handle *trans, u64 bytenr,
>>> + u64 num_bytes, gfp_t gfp_flag)
>>> {
>>> + struct btrfs_fs_info *fs_info = trans->fs_info;
>>
>> Just lines below, we do extra WARN_ON(trans == NULL).
>> So if we really hit some case with NULL trans, this would cause a NULL
>> pointer dereference.
>>
>> Although I have to admit, I'm a little paranoid about possible NULL
>> trans passed in.
>> So maybe it's a good timing to remove that WARN_ON() too?
>
> Sorry, I didn't notice this WARN_ON(trans == NULL). However, I have
> confirmed that the callers of btrfs_qgroup_trace_{extent, leaf_items,
> subtree} should never pass NULL as trans. In my opinion the WARN_ON() can
> be removed without any bad effect.
>
Then removing that WARN_ON() would be pretty nice.Thanks, Qu
signature.asc
Description: OpenPGP digital signature
