Re: [PATCH] btrfs: fix disk-io.c/btrfs_read_dev_super with BTRFS_SUPER_MIRROR_MAX to control the loops
On Mon, Sep 10, 2012 at 12:38 AM, Wang Sheng-Hui wrote:
> To check the duplicated super blocks, use BTRFS_SUPER_MIRROR_MAX
> as the loops limit.
>
> Signed-off-by: Wang Sheng-Hui
> ---
> fs/btrfs/disk-io.c |2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/fs/btrfs/disk-io.c b/fs/btrfs/disk-io.c
> index 22e98e0..a431144 100644
> --- a/fs/btrfs/disk-io.c
> +++ b/fs/btrfs/disk-io.c
> @@ -2723,7 +2723,7 @@ struct buffer_head *btrfs_read_dev_super(struct
> block_device *bdev)
> * So, we need to add a special mount option to scan for
> * later supers, using BTRFS_SUPER_MIRROR_MAX instead
> */
> - for (i = 0; i < 1; i++) {
> + for (i = 0; i < BTRFS_SUPER_MIRROR_MAX; i++) {
> bytenr = btrfs_sb_offset(i);
> if (bytenr + 4096 >= i_size_read(bdev->bd_inode))
> break;
> --
> 1.7.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
Please fix the comment as well; if we check all the supers, then
mounting as btrfs _will_ succeed after a different (non-btrfs)
filesystem is created on the partition/device, pretty much
guaranteeing it will be corrupted.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [tip:sched/core] sched: Fix race in task_group()
On Tue, Jul 24, 2012 at 8:21 AM, tip-bot for Peter Zijlstra
wrote:
> Commit-ID: 8323f26ce3425460769605a6aece7a174edaa7d1
> Gitweb: http://git.kernel.org/tip/8323f26ce3425460769605a6aece7a174edaa7d1
> Author: Peter Zijlstra
> AuthorDate: Fri, 22 Jun 2012 13:36:05 +0200
> Committer: Ingo Molnar
> CommitDate: Tue, 24 Jul 2012 13:58:20 +0200
>
> sched: Fix race in task_group()
>
> Stefan reported a crash on a kernel before a3e5d1091c1 ("sched:
> Don't call task_group() too many times in set_task_rq()"), he
> found the reason to be that the multiple task_group()
> invocations in set_task_rq() returned different values.
>
> Looking at all that I found a lack of serialization and plain
> wrong comments.
>
> The below tries to fix it using an extra pointer which is
> updated under the appropriate scheduler locks. Its not pretty,
> but I can't really see another way given how all the cgroup
> stuff works.
>
> Reported-and-tested-by: Stefan Bader
> Signed-off-by: Peter Zijlstra
> Link: http://lkml.kernel.org/r/1340364965.18025.71.camel@twins
> Signed-off-by: Ingo Molnar
I just finished bisecting a crash on boot to this commit; booting with
"noautogroup" brings it back.
3.5.4 is the latest -stable that still boots, and none of the 3.6 rc's
boot at all.
Photo of the bug (3.6.0next is 3.6 + btrfs's for-linus):
https://lh5.googleusercontent.com/-0DY-YYhgvzs/UHdB-BQdzMI/AEg/QhY9rgxnv98/s811/2012-10-11
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [tip:sched/core] sched: Fix race in task_group()
On Thu, Oct 18, 2012 at 7:33 AM, Luis Henriques
wrote:
> On Thu, Oct 18, 2012 at 12:23:38PM +0200, Stefan Bader wrote:
>> On 18.10.2012 10:27, cwillu wrote:
>> > On Tue, Jul 24, 2012 at 8:21 AM, tip-bot for Peter Zijlstra
>> > wrote:
>> >> Commit-ID: 8323f26ce3425460769605a6aece7a174edaa7d1
>> >> Gitweb:
>> >> http://git.kernel.org/tip/8323f26ce3425460769605a6aece7a174edaa7d1
>> >> Author: Peter Zijlstra
>> >> AuthorDate: Fri, 22 Jun 2012 13:36:05 +0200
>> >> Committer: Ingo Molnar
>> >> CommitDate: Tue, 24 Jul 2012 13:58:20 +0200
>> >>
>> >> sched: Fix race in task_group()
>> >>
>> >> Stefan reported a crash on a kernel before a3e5d1091c1 ("sched:
>> >> Don't call task_group() too many times in set_task_rq()"), he
>> >> found the reason to be that the multiple task_group()
>> >> invocations in set_task_rq() returned different values.
>> >>
>> >> Looking at all that I found a lack of serialization and plain
>> >> wrong comments.
>> >>
>> >> The below tries to fix it using an extra pointer which is
>> >> updated under the appropriate scheduler locks. Its not pretty,
>> >> but I can't really see another way given how all the cgroup
>> >> stuff works.
>> >>
>> >> Reported-and-tested-by: Stefan Bader
>> >> Signed-off-by: Peter Zijlstra
>> >> Link: http://lkml.kernel.org/r/1340364965.18025.71.camel@twins
>> >> Signed-off-by: Ingo Molnar
>> >
>> > I just finished bisecting a crash on boot to this commit; booting with
>> > "noautogroup" brings it back.
>> >
>> > 3.5.4 is the latest -stable that still boots, and none of the 3.6 rc's
>> > boot at all.
>> >
>> > Photo of the bug (3.6.0next is 3.6 + btrfs's for-linus):
>> > https://lh5.googleusercontent.com/-0DY-YYhgvzs/UHdB-BQdzMI/AEg/QhY9rgxnv98/s811/2012-10-11
>> >
>>
>> On a very quick glance I wonder whether there might be a case where
>> sched_fork
>> goes into set_task_cpu with a different cpu than the current but has not yet
>> task_group.sched_task_group set to something valid...
>>
>>
>
> I was looking at another bug report [1] which may be related with this
> issue. Basically, it looks like there is a race window where
> resetting sched_autogroup_enabled will cause a crash on
> shutdown/reboot. In the bug report, the user has added:
>
> echo 0 > /proc/sys/kernel/sched_autogroup_enabled
>
> to /etc/rc.local. This will cause a NULL pointer dereference during
> shutdown (and it is reproducible with mainline kernel 3.7.0-rc1).
>
> By using the kernel parameter noautogroup I *wasn't* able to reproduce
> this issue.
Ah, yes, that makes sense. I just checked, and the machine has
"kernel.sched_autogroup_enabled = 0" in /etc/sysctl.conf, which would
have the same effect.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 07/16] btrfs: nuke write_super from comments
> diff --git a/fs/btrfs/volumes.c b/fs/btrfs/volumes.c > index ecaad40..9f2416c 100644 > --- a/fs/btrfs/volumes.c > +++ b/fs/btrfs/volumes.c > @@ -1738,10 +1738,6 @@ int btrfs_init_new_device(struct btrfs_root *root, > char *device_path) > > device->fs_devices = root->fs_info->fs_devices; > > - /* > -* we don't want write_supers to jump in here with our device > -* half setup > -*/ > mutex_lock(&root->fs_info->fs_devices->device_list_mutex); > list_add_rcu(&device->dev_list, &root->fs_info->fs_devices->devices); > list_add(&device->dev_alloc_list, Is the locking still required for approximately the same reason? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
