Re: [PATCH 1/2] vfs: new super block feature flags attribute

[Mimi Zohar]

On Thu, 2012-11-22 at 14:49 +0200, Dmitry Kasatkin wrote:
> This patch introduces new super block attribute flag s_feature_flags
> and SF_IMA_DISABLED flag. This flag will be used by Integrity Measurement
> Architecture (IMA). Name suggested by Bruce Fields.

The patch looks good.  The patch description should reflect the
discussion with Al https://lkml.org/lkml/2012/9/19/9, explanining 'why'
a new flag is needed.

> Certain file system types and partitions will never be measured or
> appraised by IMA depending on the policy. For example, pseudo file
> systems are never measured and appraised. In current implementation
> policy will be checked again and again. It happens thousands times
> per second. That is absolute waste of CPU and may be battery resources.
> 
> IMA will set the SF_IMA_DISABLED flag when file system will not be measured
> and appraised and test this flag during subsequent calls to skip policy search.

This explanation belongs in the subsequent patch, which makes use of the
flag.

> Signed-off-by: Dmitry Kasatkin <dmitry.kasatkin@xxxxxxxxx>


> ---
>  include/linux/fs.h |    4 ++++
>  1 file changed, 4 insertions(+)
> 
> diff --git a/include/linux/fs.h b/include/linux/fs.h
> index b33cfc9..0bef2b2 100644
> --- a/include/linux/fs.h
> +++ b/include/linux/fs.h
> @@ -1321,6 +1321,8 @@ struct super_block {
> 
>  	/* Being remounted read-only */
>  	int s_readonly_remount;
> +
> +	unsigned long s_feature_flags;
>  };
> 
>  /* superblock cache pruning functions */
> @@ -1746,6 +1748,8 @@ struct super_operations {
> 
>  #define I_DIRTY (I_DIRTY_SYNC | I_DIRTY_DATASYNC | I_DIRTY_PAGES)
> 

Comment needed here before the start of the feature flag definitions.

> +#define SF_IMA_DISABLED		0x0001
> +
>  extern void __mark_inode_dirty(struct inode *, int);
>  static inline void mark_inode_dirty(struct inode *inode)
>  {

thanks,

Mimi

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/