Re: PRJQUOTA case not handled in need_print_warning()

[Eric W. Biederman]

Jan Kara <jack@xxxxxxx> writes:

> On Fri 05-10-12 00:34:29, Jiri Kosina wrote:
>> Hi,
>> 
>> commit e8a3e4719b7ec19288c56f22623f537cb78885c1
>> Author: Eric W. Biederman <ebiederm@xxxxxxxxxxxx>
>> 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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/