Jan Kara <j...@suse.cz> writes: > On Fri 05-10-12 00:34:29, Jiri Kosina wrote: >> Hi, >> >> commit e8a3e4719b7ec19288c56f22623f537cb78885c1 >> Author: Eric W. Biederman <ebied...@xmission.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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/