[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <87txu32tej.fsf@xmission.com>
Date: Tue, 09 Oct 2012 15:05:24 -0700
From: ebiederm@...ssion.com (Eric W. Biederman)
To: Jan Kara <jack@...e.cz>
Cc: Jiri Kosina <jkosina@...e.cz>, linux-kernel@...r.kernel.org,
Dave Chinner <david@...morbit.com>
Subject: Re: PRJQUOTA case not handled in need_print_warning()
Jan Kara <jack@...e.cz> writes:
> On Fri 05-10-12 00:34:29, Jiri Kosina wrote:
>> Hi,
>>
>> commit e8a3e4719b7ec19288c56f22623f537cb78885c1
>> Author: Eric W. Biederman <ebiederm@...ssion.com>
>> Date: Sun Sep 16 01:11:45 2012 -0700
>>
>> userns: Implement struct kqid
>>
>> causes this warning:
>>
>> fs/quota/dquot.c: In function ‘need_print_warning’:
>> fs/quota/dquot.c:1158: warning: enumeration value ‘PRJQUOTA’ not handled in switch
>>
>> and it seems to be a valid one -- the switch in need_print_warning()
>> contains neither 'default' nor PRJQUOTA case handler.
> Hum, since Eric didn't seem to care, I've fixed this up myself with the
> attached patch. Actually, PRJQUOTA should never get to that function so it
> shouldn't cause any problems in practice. Thanks for the report.
Sorry about that. I knew there was no functional regression as the
functional part of the code had not changed. I was waiting for a my
head to have a clear moment where I could look through and see if
PRJQUOTA could ever make it there.
Having just made the time to look at it and see that this all goes
to dquot_alloc_space and is not related to the more general
quota_send_warning path I agree that in practice we will never get there
with a PRJQUOTA as xfs is the only filesystem that supports project
quotas and xfs does not call dquot_alloc_space.
If another filesytem were to support project quotas and used the dquot
infrastructure it is theoretically possible to reach need_warning
with a project quota. But even in that theoretical case since project
quotas identifiers do not attach themselves to tasks it looks like
ignoring them is the right thing to do.
Eric
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists