From: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: "Andreas Bießmann" <andreas.devel@googlemail.com>,
"Jason A. Donenfeld" <Jason@zx2c4.com>,
linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org,
"Jens Axboe" <axboe@kernel.dk>, "Christoph Hellwig" <hch@lst.de>,
"Anton Altaparmakov" <aia21@cantab.net>,
"George Spelvin" <linux@horizon.com>
Subject: Re: [PATCH] fs-writeback: fix NULL pointer dereference in __mark_inode_dirty
Date: Fri, 18 Mar 2011 00:19:26 +0200 [thread overview]
Message-ID: <20110317221925.GA4841@swordfish> (raw)
In-Reply-To: <20110317140401.4f06793e.akpm@linux-foundation.org>
[-- Attachment #1: Type: text/plain, Size: 3679 bytes --]
Hello,
On (03/17/11 14:04), Andrew Morton wrote:
>[..]
> afaik this regression didn't get fixed. Jens put out a patch for
> George to test but there hasn't been any feedback on that yet. Could
> you guys please give it a spin?
>
Sorry for rather long reply. Seem to work fine for me.
Tested-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Thanks,
Sergey
> From: Jens Axboe <axboe@kernel.dk>
>
> When we move the potential dirty list entries to the
> default_backing_dev_info, reassign the sb->s_bdi as well.
> default_backing_dev_info will always be around. I hope this can fix it up
> for 2.6.38 and we can add the proper ref counting for .39.
>
> Cc: Anton Altaparmakov <aia21@cam.ac.uk>
> Cc: George Spelvin <linux@horizon.com>
> Cc: Christoph Hellwig <hch@lst.de>
> Cc: Andreas Biemann <biessmann@corscience.de>
> Cc: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
> Tested-by: Torsten Hilbrich <torsten.hilbrich@secunet.com>
> Cc: <stable@kernel.org> [2.6.38.x]
> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
> ---
>
> fs/super.c | 2 ++
> fs/sync.c | 4 ++--
> mm/backing-dev.c | 2 +-
> 3 files changed, 5 insertions(+), 3 deletions(-)
>
> diff -puN fs/super.c~vfs-fix-null-pointer-oops-in-sync_inodes_sb fs/super.c
> --- a/fs/super.c~vfs-fix-null-pointer-oops-in-sync_inodes_sb
> +++ a/fs/super.c
> @@ -72,6 +72,7 @@ static struct super_block *alloc_super(s
> #else
> INIT_LIST_HEAD(&s->s_files);
> #endif
> + s->s_bdi = &default_backing_dev_info;
> INIT_LIST_HEAD(&s->s_instances);
> INIT_HLIST_BL_HEAD(&s->s_anon);
> INIT_LIST_HEAD(&s->s_inodes);
> @@ -1006,6 +1007,7 @@ vfs_kern_mount(struct file_system_type *
> }
> BUG_ON(!mnt->mnt_sb);
> WARN_ON(!mnt->mnt_sb->s_bdi);
> + WARN_ON(mnt->mnt_sb->s_bdi == &default_backing_dev_info);
> mnt->mnt_sb->s_flags |= MS_BORN;
>
> error = security_sb_kern_mount(mnt->mnt_sb, flags, secdata);
> diff -puN fs/sync.c~vfs-fix-null-pointer-oops-in-sync_inodes_sb fs/sync.c
> --- a/fs/sync.c~vfs-fix-null-pointer-oops-in-sync_inodes_sb
> +++ a/fs/sync.c
> @@ -33,7 +33,7 @@ static int __sync_filesystem(struct supe
> * This should be safe, as we require bdi backing to actually
> * write out data in the first place
> */
> - if (!sb->s_bdi || sb->s_bdi == &noop_backing_dev_info)
> + if (sb->s_bdi == &noop_backing_dev_info)
> return 0;
>
> if (sb->s_qcop && sb->s_qcop->quota_sync)
> @@ -79,7 +79,7 @@ EXPORT_SYMBOL_GPL(sync_filesystem);
>
> static void sync_one_sb(struct super_block *sb, void *arg)
> {
> - if (!(sb->s_flags & MS_RDONLY) && sb->s_bdi)
> + if (!(sb->s_flags & MS_RDONLY))
> __sync_filesystem(sb, *(int *)arg);
> }
> /*
> diff -puN mm/backing-dev.c~vfs-fix-null-pointer-oops-in-sync_inodes_sb mm/backing-dev.c
> --- a/mm/backing-dev.c~vfs-fix-null-pointer-oops-in-sync_inodes_sb
> +++ a/mm/backing-dev.c
> @@ -598,7 +598,7 @@ static void bdi_prune_sb(struct backing_
> spin_lock(&sb_lock);
> list_for_each_entry(sb, &super_blocks, s_list) {
> if (sb->s_bdi == bdi)
> - sb->s_bdi = NULL;
> + sb->s_bdi = &default_backing_dev_info;
> }
> spin_unlock(&sb_lock);
> }
> _
>
>
> btw, Christoph: would this not have been be a less hacky hack?
>
> --- a/fs/fs-writeback.c~a
> +++ a/fs/fs-writeback.c
> @@ -73,7 +73,7 @@ static inline struct backing_dev_info *i
> {
> struct super_block *sb = inode->i_sb;
>
> - if (strcmp(sb->s_type->name, "bdev") == 0)
> + if (sb == blockdev_superblock)
> return inode->i_mapping->backing_dev_info;
>
> return sb->s_bdi;
> _
>
[-- Attachment #2: Type: application/pgp-signature, Size: 316 bytes --]
next prev parent reply other threads:[~2011-03-17 22:17 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-02-28 15:25 [PATCH] fs-writeback: fix NULL pointer dereference in __mark_inode_dirty Andreas Bießmann
2011-02-28 15:43 ` Sergey Senozhatsky
2011-02-28 15:59 ` Andreas Bießmann
2011-02-28 16:29 ` Sergey Senozhatsky
[not found] ` <AANLkTimARkrtmBBgtXmNA=MOD94FWQ8x-qcmLJ8mdQ6o@mail.gmail.com>
2011-03-02 8:35 ` Andreas Bießmann
2011-03-02 8:35 ` Andreas Bießmann
2011-03-03 13:58 ` Andreas Bießmann
2011-03-03 13:58 ` Andreas Bießmann
2011-03-17 21:04 ` Andrew Morton
2011-03-17 21:06 ` George Spelvin
2011-03-17 22:19 ` Sergey Senozhatsky [this message]
[not found] <fa.8ND6HoGS9dKYUuniFCAoNq+1TFY@ifi.uio.no>
2011-03-10 10:39 ` [PATCH] fs-writeback: fix NULL pointer dereference in, __mark_inode_dirty Torsten Hilbrich
2011-03-15 10:17 ` Torsten Hilbrich
2011-03-15 12:11 ` Anton Altaparmakov
2011-03-15 12:35 ` Jens Axboe
2011-03-15 12:40 ` Torsten Hilbrich
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20110317221925.GA4841@swordfish \
--to=sergey.senozhatsky@gmail.com \
--cc=Jason@zx2c4.com \
--cc=aia21@cantab.net \
--cc=akpm@linux-foundation.org \
--cc=andreas.devel@googlemail.com \
--cc=axboe@kernel.dk \
--cc=hch@lst.de \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@horizon.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.