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] [thread-next>] [day] [month] [year] [list]
Date:	Wed, 7 Nov 2012 14:55:55 +0800
From:	Zhi Yong Wu <zwu.kernel@...il.com>
To:	dave@...os.cz, zwu.kernel@...il.com, linux-fsdevel@...r.kernel.org,
	linux-ext4@...r.kernel.org, linux-btrfs@...r.kernel.org,
	linux-kernel@...r.kernel.org, linuxram@...ux.vnet.ibm.com,
	viro@...iv.linux.org.uk, david@...morbit.com, tytso@....edu,
	cmm@...ibm.com, wuzhy@...ux.vnet.ibm.com, wenqing.lz@...bao.com
Subject: Re: [RFC v4+ hot_track 02/19] vfs: initialize and free data structures

On Wed, Nov 7, 2012 at 6:24 AM, David Sterba <dave@...os.cz> wrote:
> On Mon, Oct 29, 2012 at 12:30:44PM +0800, zwu.kernel@...il.com wrote:
>> +/* Frees the entire hot_range_tree. */
>> +static void hot_inode_item_free(struct kref *kref)
>> +{
>> +     struct hot_comm_item *comm_item = container_of(kref,
>> +                     struct hot_comm_item, refs);
>> +     struct hot_inode_item *he = container_of(comm_item,
>> +                     struct hot_inode_item, hot_inode);
>> +
>> +     hot_range_tree_free(he);
>> +     radix_tree_delete(he->hot_inode_tree, he->i_ino);
>
> void *radix_tree_delete(struct radix_tree_root *root, unsigned long index)
>
> and he::i_ino is u64, this will not work when
> sizeof(unsigned long) != sizeof(u64) (iirc this is a known limitation of
> radix tree implementation). This will work on 64bit only, not sure if
> this is intentional.
i actually also realized this. Do you have a better way to handle this?
>
>> +     kmem_cache_free(hot_inode_item_cachep, he);
>> +}
>> +
>> +/* Frees the entire hot_inode_tree. */
>> +static void hot_inode_tree_exit(struct hot_info *root)
>> +{
>> +     struct hot_inode_item *hi_nodes[8];
>> +     u64 ino = 0;
>> +     int i, n;
>
> nitpick, put the declarations on separate lines
Will it have any issue? It has passed the check of checkpatch.pl.

>
>> +
>> +     while (1) {
>> +             spin_lock(&root->lock);
>> +             n = radix_tree_gang_lookup(&root->hot_inode_tree,
>> +                                        (void **)hi_nodes, ino,
>> +                                        ARRAY_SIZE(hi_nodes));
>> +             if (!n) {
>> +                     spin_unlock(&root->lock);
>> +                     break;
>> +             }
>> +
>> +             ino = hi_nodes[n - 1]->i_ino + 1;
>> +             for (i = 0; i < n; i++)
>> +                     hot_inode_item_put(hi_nodes[i]);
>> +             spin_unlock(&root->lock);
>> +     }
>> +}
>> +
>>  /*
>>   * Initialize kmem cache for hot_inode_item and hot_range_item.
>>   */
>> @@ -106,3 +197,36 @@ err:
>>       kmem_cache_destroy(hot_inode_item_cachep);
>>  }
>>  EXPORT_SYMBOL_GPL(hot_cache_init);
>> +
>> +/*
>> + * Initialize the data structures for hot data tracking.
>> + */
>> +int hot_track_init(struct super_block *sb)
>> +{
>> +     struct hot_info *root;
>> +     int ret = -ENOMEM;
>> +
>> +     root = kzalloc(sizeof(struct hot_info), GFP_NOFS);
>> +     if (!root) {
>> +             printk(KERN_ERR "%s: Failed to malloc memory for "
>> +                             "hot_info\n", __func__);
>> +             return ret;
>
> minor: you can drop the variable ret and just reurn ENOMEM here
This variable will also be used in the following patches.

>
>> +     }
>> +
>> +     sb->s_hot_root = root;
>> +     hot_inode_tree_init(root);
>> +
>> +     printk(KERN_INFO "VFS: Turning on hot data tracking\n");
>> +
>> +     return 0;
>> +}
>> +EXPORT_SYMBOL_GPL(hot_track_init);
>
> david



-- 
Regards,

Zhi Yong Wu
--
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