From: David Sterba <dsterba@suse.cz>
To: dsterba@suse.cz, Nikolay Borisov <nborisov@suse.com>,
linux-btrfs@vger.kernel.org
Cc: lufq.fnst@cn.fujitsu.com
Subject: Re: [PATCH 0/7] fs_info cleanups for volume.c
Date: Tue, 24 Jul 2018 10:28:04 +0200 [thread overview]
Message-ID: <20180724082804.GS26141@twin.jikos.cz> (raw)
In-Reply-To: <20180723132501.GL26141@twin.jikos.cz>
On Mon, Jul 23, 2018 at 03:25:01PM +0200, David Sterba wrote:
> On Fri, Jul 20, 2018 at 07:37:46PM +0300, Nikolay Borisov wrote:
> > Here are a bunch of patches which cleanup extraneous fs_info parameters to
> > function which already take a structure that holds a reference to the fs_info.
> >
> > Except for patches 4 and 5, everything else is correct - due to those functions
> > always taking a transaction. 4 and 5 in turn reference the fs_info from
> > struct btrfs_device. Inspecting the callers I managed to convince myself that
> > those function are always called with well-formed btrfs_device i.e one which
> > has its fs_info member initialised. Reviewers might want to pay extra
> > attention to that but otherwise they are trivial.
>
> 4 and 5 look good to me, a device without a valid fs_info has a short
> timespan and should not appear anywhere besides the helpers that set up
> fs_devices etc. Series added to misc-next, thanks.
btrfs/164 crashed in device rm that could be related to the patches, I
haven't analyzed that but this series looks most suspicious since the
last round of tests that did not see that crash:
[ 6712.084324] general protection fault: 0000 [#1] PREEMPT SMP
[ 6712.090096] CPU: 0 PID: 2694 Comm: btrfs Not tainted4.18.0-rc6-1.ge195904-vanilla+ #279
[ 6712.098398] Hardware name: empty empty/S3993, BIOS PAQEX0-302/24/2008
[ 6712.105072] RIP: 0010:__list_del_entry_valid+0x25/0xc0
[ 6712.129603] RSP: 0018:ffffb01281e2bbd0 EFLAGS: 00010a83
[ 6712.134969] RAX: 6b6b6b6b6b6b6b6b RBX: ffff9972756dafd8 RCX:dead000000000200
[ 6712.142246] RDX: 6b6b6b6b6b6b6b6b RSI: ffffffffc10252cf RDI:ffff9972756db100
[ 6712.149507] RBP: ffff9972756db100 R08: 0000000000000000 R09:0000000000000001
[ 6712.156788] R10: ffffb01281e2bbd8 R11: 0000000000000000 R12:ffff99728a2d7500
[ 6712.164059] R13: ffff9972756c0910 R14: ffff99728a2d7450 R15:6b6b6b6b6b6b6a43
[ 6712.171332] FS: 00007f3100bb58c0(0000) GS:ffff9972a6600000(0000)knlGS:0000000000000000
[ 6712.179615] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 6712.185507] CR2: 00007f336c989000 CR3: 00000001f6868000 CR4:00000000000006f0
[ 6712.192779] Call Trace:
[ 6712.195423] btrfs_update_commit_device_size+0x75/0xf0 [btrfs]
[ 6712.201424] btrfs_commit_transaction+0x57d/0xa90 [btrfs]
[ 6712.206999] btrfs_rm_device+0x627/0x850 [btrfs]
[ 6712.211800] btrfs_ioctl+0x2b03/0x3120 [btrfs]
[ 6712.216404] ? __might_fault+0x3e/0x90
[ 6712.220277] ? lock_acquire+0x9f/0x270
[ 6712.224156] ? __audit_syscall_entry+0xd6/0x170
[ 6712.228835] ? ktime_get_coarse_real_ts64+0x67/0x100
[ 6712.233940] ? do_vfs_ioctl+0xa5/0x6f0
[ 6712.237836] do_vfs_ioctl+0xa5/0x6f0
[ 6712.241554] ? syscall_trace_enter+0x1e8/0x3e0
[ 6712.246130] ksys_ioctl+0x70/0x80
[ 6712.249593] __x64_sys_ioctl+0x16/0x20
[ 6712.253484] do_syscall_64+0x62/0x1c0
[ 6712.257291] entry_SYSCALL_64_after_hwframe+0x49/0xbe
[ 6712.262482] RIP: 0033:0x7f30ffc52417
[ 6712.285413] RSP: 002b:00007ffd636f32c8 EFLAGS: 00000202 ORIG_RAX:0000000000000010
[ 6712.293191] RAX: ffffffffffffffda RBX: 00007ffd636f5460 RCX:00007f30ffc52417
[ 6712.300462] RDX: 00007ffd636f4300 RSI: 000000005000943a RDI:0000000000000003
[ 6712.307742] RBP: 00007ffd636f4300 R08: 0000000000000000 R09:0000000000100000
[ 6712.315005] R10: 000000000fa99fa0 R11: 0000000000000202 R12:0000000000000000
[ 6712.322286] R13: 0000000000000000 R14: 0000000000000003 R15:00007ffd636f5468
[ 6712.391596] ---[ end trace f05bf71894e4ee4d ]---
next prev parent reply other threads:[~2018-07-24 9:33 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-07-20 16:37 [PATCH 0/7] fs_info cleanups for volume.c Nikolay Borisov
2018-07-20 16:37 ` [PATCH 1/7] btrfs: Remove fs_info argument from btrfs_add_dev_item Nikolay Borisov
2018-07-20 16:37 ` [PATCH 2/7] btrfs: Remove fs_info from btrfs_rm_dev_replace_remove_srcdev Nikolay Borisov
2018-07-20 16:37 ` [PATCH 3/7] btrfs: remove fs_info argument from update_dev_stat_item Nikolay Borisov
2018-07-20 16:37 ` [PATCH 4/7] btrfs: Remove fs_info from btrfs_assign_next_active_device Nikolay Borisov
2018-07-20 16:37 ` [PATCH 5/7] btrfs: Remove fs_info from btrfs_destroy_dev_replace_tgtdev Nikolay Borisov
2018-07-20 16:37 ` [PATCH 6/7] btrfs: Remove fs_info form btrfs_free_chunk Nikolay Borisov
2018-07-20 16:37 ` [PATCH 7/7] btrfs: Remove fs_info from btrfs_finish_chunk_alloc Nikolay Borisov
2018-07-21 2:08 ` [PATCH 0/7] fs_info cleanups for volume.c Lu Fengqi
2018-07-23 13:25 ` David Sterba
2018-07-24 8:28 ` David Sterba [this message]
2018-07-24 8:59 ` Lu Fengqi
2018-07-24 10:41 ` David Sterba
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=20180724082804.GS26141@twin.jikos.cz \
--to=dsterba@suse.cz \
--cc=linux-btrfs@vger.kernel.org \
--cc=lufq.fnst@cn.fujitsu.com \
--cc=nborisov@suse.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.