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
| ||
|
Message-ID: <20170619090329.GE11837@quack2.suse.cz> Date: Mon, 19 Jun 2017 11:03:29 +0200 From: Jan Kara <jack@...e.cz> To: Tahsin Erdogan <tahsin@...gle.com> Cc: Jan Kara <jack@...e.cz>, Jan Kara <jack@...e.com>, Theodore Ts'o <tytso@....edu>, Andreas Dilger <adilger.kernel@...ger.ca>, Dave Kleikamp <shaggy@...nel.org>, Alexander Viro <viro@...iv.linux.org.uk>, Mark Fasheh <mfasheh@...sity.com>, Joel Becker <jlbec@...lplan.org>, Jens Axboe <axboe@...com>, Deepa Dinamani <deepa.kernel@...il.com>, Mike Christie <mchristi@...hat.com>, Fabian Frederick <fabf@...net.be>, linux-ext4@...r.kernel.org, linux-kernel@...r.kernel.org, jfs-discussion@...ts.sourceforge.net, linux-fsdevel@...r.kernel.org, ocfs2-devel@....oracle.com, reiserfs-devel@...r.kernel.org Subject: Re: [PATCH 28/28] quota: add extra inode count to dquot transfer functions On Fri 16-06-17 18:50:58, Tahsin Erdogan wrote: > On Thu, Jun 15, 2017 at 12:57 AM, Jan Kara <jack@...e.cz> wrote: > > Hum, rather handle this similarly to how we handle delalloc reserved space. > > Add a callback to dq_ops to get "inode usage" of an inode and then use it > > in dquot_transfer(), dquot_free_inode(), dquot_alloc_inode(). > > I tried that approach by adding a "int get_inode_usage(struct inode > *inode, qsize_t *usage)" callback to dquot_operations. Unfortunately, > ext4 code that calculates the number of internal inodes > (ext4_xattr_inode_count()) is subject to failures so the callback has > to be able to report errors. And, that itself is problematic because > we can't afford to have errors in dquot_free_inode(). If you have > thoughts about how to address this please let me know. Well, you can just make dquot_free_inode() return error. Now most callers won't be able to do much with an error from dquot_free_inode() but that's the case also for other things during inode deletion - just handle it as other fatal failures during inode freeing. > Alternatively, I could try to make this patch less intrusive by > keeping the existing dquot_transfer() signature and add a new > dquot_transfer_usage() that accepts inode_usage as a parameter. What > do you think? That would be somewhat better than what you do in this patch but I prefer to handle this like I suggested above. Honza -- Jan Kara <jack@...e.com> SUSE Labs, CR
Powered by blists - more mailing lists