On Mon, 6 Jun 2005, Hugh Dickins wrote:
> @@ -1607,15 +1582,17 @@ static int shmem_statfs(struct super_blo
> buf->f_type = TMPFS_MAGIC;
> buf->f_bsize = PAGE_CACHE_SIZE;
> buf->f_namelen = NAME_MAX;
> - if (sbinfo) {
> - spin_lock(&sbinfo->stat_lock);
> + spin_lock(&sbinfo->stat_lock);
> + if (sbinfo->max_blocks) {
> buf->f_blocks = sbinfo->max_blocks;
> buf->f_bavail = buf->f_bfree = sbinfo->free_blocks;
> + }
> + if (sbinfo->max_inodes) {
> buf->f_files = sbinfo->max_inodes;
> buf->f_ffree = sbinfo->free_inodes;
> - spin_unlock(&sbinfo->stat_lock);
> }
> /* else leave those fields 0 like simple_statfs */
> + spin_unlock(&sbinfo->stat_lock);
> return 0;
> }
This is the only change I'm at all concerned about.
I'm not sure how frequent statfs operations occur in practice (I suspect
infrequently), however simply changing the existing code from "if (sbinfo)"
to "if (sbinfo->max_blocks || sbinfo->max_inodes)" would be an appropriate
remedy if there is a real problem.
That said, I'm not all that concerned about it, as my fuzzy memory
indicates it was the lock/unlock around the statistics updates which
caused the primary lock contention.
Brent
--
Brent Casavant If you had nothing to fear,
[email protected] how then could you be brave?
Silicon Graphics, Inc. -- Queen Dama, Source Wars
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
