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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Tue, 7 Jul 2015 23:32:56 +0900
From:	Sergey Senozhatsky <sergey.senozhatsky@...il.com>
To:	Minchan Kim <minchan@...nel.org>
Cc:	Sergey Senozhatsky <sergey.senozhatsky@...il.com>,
	Andrew Morton <akpm@...ux-foundation.org>, linux-mm@...ck.org,
	linux-kernel@...r.kernel.org,
	Sergey Senozhatsky <sergey.senozhatsky.work@...il.com>
Subject: Re: [PATCH v6 5/7] zsmalloc/zram: introduce zs_pool_stats api

On (07/07/15 22:36), Minchan Kim wrote:
[..]
> >  	struct zram *zram = dev_to_zram(dev);
> > +	struct zs_pool_stats pool_stats = {0};
> 
> Does it work even if first member of the structure is non-scalar?
> Personally I prefer memset for initliazation.
> I believe modern compiler would optimize that quite well.

zs_pool_stats contains only one member now, so I didn't bother.

[..]
> >  struct zs_pool {
> > -	char *name;
> > +	char			*name;
> 
> huge tab?
> 
> >  
> > -	struct size_class **size_class;
> > -	struct kmem_cache *handle_cachep;
> > +	struct size_class	**size_class;
> > +	struct kmem_cache	*handle_cachep;
> 
> tab?
> tab?
> 
> >  
> > -	gfp_t flags;	/* allocation flags used when growing pool */
> > -	atomic_long_t pages_allocated;
> 
> Why changes comment position?

Because otherwise it breaks 80-cols rule.

> > +	/* Allocation flags used when growing pool */
> > +	gfp_t			flags;
> > +	atomic_long_t		pages_allocated;
> >  
> 
> Why blank line?

To make it more readable? Separating logically different
struct members. That's why the original code contains blank
lines between `char *name' and `struct size_class **size_class;
struct kmem_cache *handle_cachep;` and so on.

I see no issue.


> > +	struct zs_pool_stats	stats;
> >  #ifdef CONFIG_ZSMALLOC_STAT
> > -	struct dentry *stat_dentry;
> > +	struct dentry		*stat_dentry;
> 
> Tab.

Well, I see no issue with aligned struct members. Looks less
hairy and less messy than the original one.

clean:

struct zs_pool {
        char                    *name;

        struct size_class       **size_class;
        struct kmem_cache       *handle_cachep;

        /* Allocation flags used when growing pool */
        gfp_t                   flags;
        atomic_long_t           pages_allocated;

        struct zs_pool_stats    stats;

        /* Compact classes */
        struct shrinker         shrinker;
        bool                    shrinker_enabled;
#ifdef CONFIG_ZSMALLOC_STAT
        struct dentry           *stat_dentry;
#endif
};



dirty:

struct zs_pool {
        char *name;

        struct size_class **size_class;
        struct kmem_cache *handle_cachep;

        gfp_t flags;    /* allocation flags used when growing pool */
        atomic_long_t pages_allocated;

#ifdef CONFIG_ZSMALLOC_STAT
        struct dentry *stat_dentry;
#endif
};

	-ss
--
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