lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<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

Powered by Openwall GNU/*/Linux Powered by OpenVZ