linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH] fs/affs: release memory if affs_init_bitmap fails
@ 2019-09-17  4:13 Navid Emamdoost
  2019-09-17  9:52 ` David Sterba
  0 siblings, 1 reply; 3+ messages in thread
From: Navid Emamdoost @ 2019-09-17  4:13 UTC (permalink / raw)
  Cc: emamd001, smccaman, kjlu, Navid Emamdoost, David Sterba,
	linux-fsdevel, linux-kernel

In affs_init_bitmap, on error handling path we may release the allocated
memory.

Signed-off-by: Navid Emamdoost <navid.emamdoost@gmail.com>
---
 fs/affs/bitmap.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/fs/affs/bitmap.c b/fs/affs/bitmap.c
index 5ba9ef2742f6..745ed2cc4b51 100644
--- a/fs/affs/bitmap.c
+++ b/fs/affs/bitmap.c
@@ -347,6 +347,7 @@ int affs_init_bitmap(struct super_block *sb, int *flags)
 out:
 	affs_brelse(bh);
 	affs_brelse(bmap_bh);
+	kfree(sbi->s_bitmap);
 	return res;
 }
 
-- 
2.17.1


^ permalink raw reply related	[flat|nested] 3+ messages in thread

* Re: [PATCH] fs/affs: release memory if affs_init_bitmap fails
  2019-09-17  4:13 [PATCH] fs/affs: release memory if affs_init_bitmap fails Navid Emamdoost
@ 2019-09-17  9:52 ` David Sterba
  2019-09-25 22:29   ` Al Viro
  0 siblings, 1 reply; 3+ messages in thread
From: David Sterba @ 2019-09-17  9:52 UTC (permalink / raw)
  To: Navid Emamdoost
  Cc: David Sterba, emamd001, kjlu, smccaman, linux-fsdevel, linux-kernel

On Mon, Sep 16, 2019 at 11:13:42PM -0500, Navid Emamdoost wrote:
> In affs_init_bitmap, on error handling path we may release the allocated
> memory.

Yes the memory should be released but not all paths that lead to the
label 'out' are actually errors:

288                 if (affs_checksum_block(sb, bh)) {
289                         pr_warn("Bitmap %u invalid - mounting %s read only.\n",
290                                 bm->bm_key, sb->s_id);
291                         *flags |= SB_RDONLY;
292                         goto out;
293                 }

ie. the return value 'res' is still 0, and the filesystem is mounted
read-only.

> Signed-off-by: Navid Emamdoost <navid.emamdoost@gmail.com>
> ---
>  fs/affs/bitmap.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/fs/affs/bitmap.c b/fs/affs/bitmap.c
> index 5ba9ef2742f6..745ed2cc4b51 100644
> --- a/fs/affs/bitmap.c
> +++ b/fs/affs/bitmap.c
> @@ -347,6 +347,7 @@ int affs_init_bitmap(struct super_block *sb, int *flags)
>  out:
>  	affs_brelse(bh);
>  	affs_brelse(bmap_bh);
> +	kfree(sbi->s_bitmap);

The sbi->s_bitmap would be freed but at umount time it will
be freed again.

>  	return res;
>  }
>  
> -- 
> 2.17.1
> 
> 

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [PATCH] fs/affs: release memory if affs_init_bitmap fails
  2019-09-17  9:52 ` David Sterba
@ 2019-09-25 22:29   ` Al Viro
  0 siblings, 0 replies; 3+ messages in thread
From: Al Viro @ 2019-09-25 22:29 UTC (permalink / raw)
  To: dsterba, Navid Emamdoost, David Sterba, emamd001, kjlu, smccaman,
	linux-fsdevel, linux-kernel

On Tue, Sep 17, 2019 at 11:52:41AM +0200, David Sterba wrote:
> On Mon, Sep 16, 2019 at 11:13:42PM -0500, Navid Emamdoost wrote:
> > In affs_init_bitmap, on error handling path we may release the allocated
> > memory.
> 
> Yes the memory should be released but not all paths that lead to the
> label 'out' are actually errors:

... and none of them should be freeing anything here, errors or no
errors.

> The sbi->s_bitmap would be freed but at umount time it will
> be freed again.

It actually would be freed by superblock destructor, be it on umount
or on failed fill_super.

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2019-09-25 22:29 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-09-17  4:13 [PATCH] fs/affs: release memory if affs_init_bitmap fails Navid Emamdoost
2019-09-17  9:52 ` David Sterba
2019-09-25 22:29   ` Al Viro

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).