From: Eric Sandeen <sandeen@redhat.com>
To: ext4 development <linux-ext4@vger.kernel.org>
Cc: Eric Paris <eparis@redhat.com>
Subject: [PATCH 2/2] delay capable() check in ext4_has_free_blocks(
Date: Fri, 24 Oct 2008 15:27:35 -0500 [thread overview]
Message-ID: <49022FB7.9050608@redhat.com> (raw)
As reported by Eric Paris, the capable() check in ext4_has_free_blocks()
sometimes causes SELinux denials.
We can rearrange the logic so that we only try to use the root-reserved
blocks when necessary, and even then we can move the capable() test
to last, to avoid the check most of the time.
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
--
Index: linux-2.6/fs/ext4/balloc.c
===================================================================
--- linux-2.6.orig/fs/ext4/balloc.c 2008-10-24 14:43:11.103063953 -0500
+++ linux-2.6/fs/ext4/balloc.c 2008-10-24 14:43:18.082063765 -0500
@@ -596,23 +596,19 @@ void ext4_free_blocks(handle_t *handle,
*
* Check if filesystem has free blocks available for allocation.
* Return the number of blocks avaible for allocation for this request
- * On success, return nblocks
+ * On success, return 1, on failure, return 0.
*/
int ext4_has_free_blocks(struct ext4_sb_info *sbi,
s64 nblocks)
{
- s64 free_blocks, dirty_blocks;
- s64 root_blocks = 0;
+ s64 free_blocks, dirty_blocks, root_blocks;
struct percpu_counter *fbc = &sbi->s_freeblocks_counter;
struct percpu_counter *dbc = &sbi->s_dirtyblocks_counter;
free_blocks = percpu_counter_read_positive(fbc);
dirty_blocks = percpu_counter_read_positive(dbc);
+ root_blocks = ext4_r_blocks_count(sbi->s_es);
- if (!capable(CAP_SYS_RESOURCE) &&
- sbi->s_resuid != current->fsuid &&
- (sbi->s_resgid == 0 || !in_group_p(sbi->s_resgid)))
- root_blocks = ext4_r_blocks_count(sbi->s_es);
if (free_blocks - (nblocks + root_blocks + dirty_blocks) <
EXT4_FREEBLOCKS_WATERMARK) {
@@ -625,13 +621,20 @@ int ext4_has_free_blocks(struct ext4_sb_
}
}
/* Check whether we have space after
- * accounting for current dirty blocks
+ * accounting for current dirty blocks & root reserved blocks.
*/
- if (free_blocks < ((root_blocks + nblocks) + dirty_blocks))
- /* we don't have free space */
- return 0;
+ if (free_blocks >= ((root_blocks + nblocks) + dirty_blocks))
+ return 1;
- return 1;
+ /* Hm, nope. Are (enough) root reserved blocks available? */
+ if (sbi->s_resuid == current->fsuid ||
+ ((sbi->s_resgid != 0) && in_group_p(sbi->s_resgid)) ||
+ capable(CAP_SYS_RESOURCE)) {
+ if (free_blocks >= (nblocks + dirty_blocks))
+ return 1;
+ }
+
+ return 0;
}
int ext4_claim_free_blocks(struct ext4_sb_info *sbi,
next reply other threads:[~2008-10-24 20:27 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-10-24 20:27 Eric Sandeen [this message]
2008-10-24 20:41 ` [PATCH 2/2 v2] delay capable() check in ext4_has_free_blocks( Eric Sandeen
2008-10-24 20:48 ` [PATCH 2/2] " Mingming Cao
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=49022FB7.9050608@redhat.com \
--to=sandeen@redhat.com \
--cc=eparis@redhat.com \
--cc=linux-ext4@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.