Re: [CRIU] BUG: Dentry ffff9f795a08fe60{i=af565f, n=lo} still in use (1) [unmount of proc proc]
On Thu, Jul 06, 2017 at 08:41:00AM -0500, Eric W. Biederman wrote:
> Andrei Vagin writes:
>
> > I did a few experiments and found that the bug is reproduced for 6-12
> > hours on the our test server. Then I reverted two patches and the server
> > is working normally for more than 24 hours already, so the bug is
> > probably in one of these patches.
> >
> > commit e3d0065ab8535cbeee69a4c46a59f4d7360803ae
> > Author: Andrei Vagin
> > Date: Sun Jul 2 07:41:25 2017 +0200
> >
> > Revert "proc/sysctl: prune stale dentries during unregistering"
> >
> > This reverts commit d6cffbbe9a7e51eb705182965a189457c17ba8a3.
> >
> > commit 2d3c50dac81011c1da4d2f7a63b84bd75287e320
> > Author: Andrei Vagin
> > Date: Sun Jul 2 07:40:08 2017 +0200
> >
> > Revert "proc/sysctl: Don't grab i_lock under sysctl_lock."
> >
> > This reverts commit ace0c791e6c3cf5ef37cad2df69f0d90ccc40ffb.
> >
> >
> > FYI: This bug has been reproduced on 4.11.7
>
> Instead of the revert could you test the patch below?
Our CI server are working with this patch for more than one day without
any problem.
Tested-by: Andrei Vagin
Thanks,
Andrei
>
> This should fix the issue by grabbing a s_active reference
> to the proc super block for every inode we flush.
>
> diff --git a/fs/proc/internal.h b/fs/proc/internal.h
> index c5ae09b6c726..18694598bebf 100644
> --- a/fs/proc/internal.h
> +++ b/fs/proc/internal.h
> @@ -67,7 +67,7 @@ struct proc_inode {
> struct proc_dir_entry *pde;
> struct ctl_table_header *sysctl;
> struct ctl_table *sysctl_entry;
> - struct list_head sysctl_inodes;
> + struct hlist_node sysctl_inodes;
> const struct proc_ns_operations *ns_ops;
> struct inode vfs_inode;
> };
> diff --git a/fs/proc/proc_sysctl.c b/fs/proc/proc_sysctl.c
> index 67985a7233c2..9bf06e2b1284 100644
> --- a/fs/proc/proc_sysctl.c
> +++ b/fs/proc/proc_sysctl.c
> @@ -191,7 +191,7 @@ static void init_header(struct ctl_table_header *head,
> head->set = set;
> head->parent = NULL;
> head->node = node;
> - INIT_LIST_HEAD(&head->inodes);
> + INIT_HLIST_HEAD(&head->inodes);
> if (node) {
> struct ctl_table *entry;
> for (entry = table; entry->procname; entry++, node++)
> @@ -261,25 +261,42 @@ static void unuse_table(struct ctl_table_header *p)
> complete(p->unregistering);
> }
>
> -/* called under sysctl_lock */
> static void proc_sys_prune_dcache(struct ctl_table_header *head)
> {
> - struct inode *inode, *prev = NULL;
> + struct inode *inode;
> struct proc_inode *ei;
> + struct hlist_node *node;
> + struct super_block *sb;
>
> rcu_read_lock();
> - list_for_each_entry_rcu(ei, &head->inodes, sysctl_inodes) {
> - inode = igrab(&ei->vfs_inode);
> - if (inode) {
> - rcu_read_unlock();
> - iput(prev);
> - prev = inode;
> - d_prune_aliases(inode);
> + for (;;) {
> + node = hlist_first_rcu(&head->inodes);
> + if (!node)
> + break;
> + ei = hlist_entry(node, struct proc_inode, sysctl_inodes);
> + spin_lock(&sysctl_lock);
> + hlist_del_init_rcu(&ei->sysctl_inodes);
> + spin_unlock(&sysctl_lock);
> +
> + inode = &ei->vfs_inode;
> + sb = inode->i_sb;
> + if (!atomic_inc_not_zero(&sb->s_active))
> + continue;
> + inode = igrab(inode);
> + rcu_read_unlock();
> + if (unlikely(!inode)) {
> + deactivate_super(sb);
> rcu_read_lock();
> + continue;
> }
> +
> + d_prune_aliases(inode);
> + iput(inode);
> + deactivate_super(sb);
> +
> + rcu_read_lock();
> }
> rcu_read_unlock();
> - iput(prev);
> }
>
> /* called under sysctl_lock, will reacquire if has to wait */
> @@ -461,7 +478,7 @@ static struct inode *proc_sys_make_inode(struct
> super_block *sb,
> }
> ei->sysctl = head;
> ei->sysctl_entry = table;
> - list_add_rcu(&ei->sysctl_inodes, &head->inodes);
> + hlist_add_head_rcu(&ei->sysctl_inodes, &head->inodes);
> head->count++;
> spin_unlock(&sysctl_lock);
>
> @@ -489,7 +506,7 @@ static struct inode *proc_sys_make_inode(struct
> super_block *sb,
> void proc_sys_evict_inode(struct inode *inode, struct ctl_table_header *head)
> {
> spin_lock(&sysctl_lock);
> - list_del_rcu(&PROC_I(inode)->sysctl_inodes);
> + hlist_del_init_rcu(&PROC_I(inode)->sysctl_inodes);
> if (!--head->count)
> kfree_rcu(head, rcu);
> spin_unlock(&sysctl_lock);
> diff --git a/include/linux/sysctl.h b/include/linux/sysctl.h
> index 80d07816def0..1c04a26bfd2f 100644
> --- a/include/linux/sysctl.h
> +++ b/include/linux/sysct
Re: [CRIU] BUG: Dentry ffff9f795a08fe60{i=af565f, n=lo} still in use (1) [unmount of proc proc]
Andrei Vagin writes:
> I did a few experiments and found that the bug is reproduced for 6-12
> hours on the our test server. Then I reverted two patches and the server
> is working normally for more than 24 hours already, so the bug is
> probably in one of these patches.
>
> commit e3d0065ab8535cbeee69a4c46a59f4d7360803ae
> Author: Andrei Vagin
> Date: Sun Jul 2 07:41:25 2017 +0200
>
> Revert "proc/sysctl: prune stale dentries during unregistering"
>
> This reverts commit d6cffbbe9a7e51eb705182965a189457c17ba8a3.
>
> commit 2d3c50dac81011c1da4d2f7a63b84bd75287e320
> Author: Andrei Vagin
> Date: Sun Jul 2 07:40:08 2017 +0200
>
> Revert "proc/sysctl: Don't grab i_lock under sysctl_lock."
>
> This reverts commit ace0c791e6c3cf5ef37cad2df69f0d90ccc40ffb.
>
>
> FYI: This bug has been reproduced on 4.11.7
Instead of the revert could you test the patch below?
This should fix the issue by grabbing a s_active reference
to the proc super block for every inode we flush.
diff --git a/fs/proc/internal.h b/fs/proc/internal.h
index c5ae09b6c726..18694598bebf 100644
--- a/fs/proc/internal.h
+++ b/fs/proc/internal.h
@@ -67,7 +67,7 @@ struct proc_inode {
struct proc_dir_entry *pde;
struct ctl_table_header *sysctl;
struct ctl_table *sysctl_entry;
- struct list_head sysctl_inodes;
+ struct hlist_node sysctl_inodes;
const struct proc_ns_operations *ns_ops;
struct inode vfs_inode;
};
diff --git a/fs/proc/proc_sysctl.c b/fs/proc/proc_sysctl.c
index 67985a7233c2..9bf06e2b1284 100644
--- a/fs/proc/proc_sysctl.c
+++ b/fs/proc/proc_sysctl.c
@@ -191,7 +191,7 @@ static void init_header(struct ctl_table_header *head,
head->set = set;
head->parent = NULL;
head->node = node;
- INIT_LIST_HEAD(&head->inodes);
+ INIT_HLIST_HEAD(&head->inodes);
if (node) {
struct ctl_table *entry;
for (entry = table; entry->procname; entry++, node++)
@@ -261,25 +261,42 @@ static void unuse_table(struct ctl_table_header *p)
complete(p->unregistering);
}
-/* called under sysctl_lock */
static void proc_sys_prune_dcache(struct ctl_table_header *head)
{
- struct inode *inode, *prev = NULL;
+ struct inode *inode;
struct proc_inode *ei;
+ struct hlist_node *node;
+ struct super_block *sb;
rcu_read_lock();
- list_for_each_entry_rcu(ei, &head->inodes, sysctl_inodes) {
- inode = igrab(&ei->vfs_inode);
- if (inode) {
- rcu_read_unlock();
- iput(prev);
- prev = inode;
- d_prune_aliases(inode);
+ for (;;) {
+ node = hlist_first_rcu(&head->inodes);
+ if (!node)
+ break;
+ ei = hlist_entry(node, struct proc_inode, sysctl_inodes);
+ spin_lock(&sysctl_lock);
+ hlist_del_init_rcu(&ei->sysctl_inodes);
+ spin_unlock(&sysctl_lock);
+
+ inode = &ei->vfs_inode;
+ sb = inode->i_sb;
+ if (!atomic_inc_not_zero(&sb->s_active))
+ continue;
+ inode = igrab(inode);
+ rcu_read_unlock();
+ if (unlikely(!inode)) {
+ deactivate_super(sb);
rcu_read_lock();
+ continue;
}
+
+ d_prune_aliases(inode);
+ iput(inode);
+ deactivate_super(sb);
+
+ rcu_read_lock();
}
rcu_read_unlock();
- iput(prev);
}
/* called under sysctl_lock, will reacquire if has to wait */
@@ -461,7 +478,7 @@ static struct inode *proc_sys_make_inode(struct super_block
*sb,
}
ei->sysctl = head;
ei->sysctl_entry = table;
- list_add_rcu(&ei->sysctl_inodes, &head->inodes);
+ hlist_add_head_rcu(&ei->sysctl_inodes, &head->inodes);
head->count++;
spin_unlock(&sysctl_lock);
@@ -489,7 +506,7 @@ static struct inode *proc_sys_make_inode(struct super_block
*sb,
void proc_sys_evict_inode(struct inode *inode, struct ctl_table_header *head)
{
spin_lock(&sysctl_lock);
- list_del_rcu(&PROC_I(inode)->sysctl_inodes);
+ hlist_del_init_rcu(&PROC_I(inode)->sysctl_inodes);
if (!--head->count)
kfree_rcu(head, rcu);
spin_unlock(&sysctl_lock);
diff --git a/include/linux/sysctl.h b/include/linux/sysctl.h
index 80d07816def0..1c04a26bfd2f 100644
--- a/include/linux/sysctl.h
+++ b/include/linux/sysctl.h
@@ -143,7 +143,7 @@ struct ctl_table_header
struct ctl_table_set *set;
struct ctl_dir *parent;
struct ctl_node *node;
- struct list_head inodes; /* head for proc_inode->sysctl_inodes */
+ struct hlist_head inodes; /* head for proc_inode->sysctl_inodes */
};
struct ctl_dir {
Re: [CRIU] BUG: Dentry ffff9f795a08fe60{i=af565f, n=lo} still in use (1) [unmount of proc proc]
b84bd75287e320
Author: Andrei Vagin
Date: Sun Jul 2 07:40:08 2017 +0200
Revert "proc/sysctl: Don't grab i_lock under sysctl_lock."
This reverts commit ace0c791e6c3cf5ef37cad2df69f0d90ccc40ffb.
FYI: This bug has been reproduced on 4.11.7
[192885.875105] BUG: Dentry 895a3dd01240{i=4e7c09a,n=lo} still in use (1)
[unmount of proc proc]
[192885.875313] [ cut here ]
[192885.875328] WARNING: CPU: 1 PID: 13588 at fs/dcache.c:1445
umount_check+0x6e/0x80
[192885.875331] Modules linked in: veth tun macvlan nf_conntrack_netlink
xt_mark udp_diag tcp_diag inet_diag netlink_diag af_packet_diag unix_diag nfsd
auth_rpcgss nfs_acl lockd grace binfmt_misc ip6t_rpfilter ip6t_REJECT
nf_reject_ipv6 xt_conntrack ip_set nfnetlink ebtable_broute bridge stp llc
ebtable_nat ip6table_nat nf_conntrack_ipv6 nf_defrag_ipv6 nf_nat_ipv6
ip6table_security ip6table_mangle ip6table_raw iptable_nat nf_conntrack_ipv4
nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack libcrc32c iptable_security
iptable_mangle iptable_raw ebtable_filter ebtables ip6table_filter ip6_tables
cmac bnep sunrpc edac_mce_amd edac_core kvm_amd btusb kvm btrtl btbcm btintel
bluetooth snd_hda_codec_realtek snd_hda_codec_hdmi snd_hda_codec_generic
snd_hda_intel iwlwifi snd_hda_codec cfg80211 irqbypass crct10dif_pclmul
[192885.875441] snd_hda_core crc32_pclmul snd_pcsp ghash_clmulni_intel
snd_hwdep snd_seq snd_seq_device snd_pcm sp5100_tco k10temp fam15h_power
i2c_piix4 snd_timer snd rfkill ccp soundcore shpchp acpi_cpufreq tpm_tis video
tpm_tis_core tpm amdkfd amd_iommu_v2 radeon crc32c_intel drm_kms_helper
sdhci_pci sdhci ttm mmc_core igb drm ptp pps_core dca i2c_algo_bit
[192885.875512] CPU: 1 PID: 13588 Comm: kworker/1:1 Not tainted
4.11.7-200.fc25.x86_64 #1
[192885.875514] Hardware name: CompuLab sbc-flt1/fitlet, BIOS SBCFLT_0.08.04
06/27/2015
[192885.875528] Workqueue: events proc_cleanup_work
[192885.875533] Call Trace:
[192885.875552] dump_stack+0x63/0x86
[192885.875558] __warn+0xcb/0xf0
[192885.875562] warn_slowpath_null+0x1d/0x20
[192885.875566] umount_check+0x6e/0x80
[192885.875570] d_walk+0xc6/0x270
[192885.875574] ? dentry_free+0x80/0x80
[192885.875578] do_one_tree+0x26/0x40
[192885.875582] shrink_dcache_for_umount+0x2d/0x90
[192885.875588] generic_shutdown_super+0x1f/0xf0
[192885.875592] kill_anon_super+0x12/0x20
[192885.875599] proc_kill_sb+0x40/0x50
[192885.875604] deactivate_locked_super+0x43/0x70
[192885.875609] deactivate_super+0x5a/0x60
[192885.875613] cleanup_mnt+0x3f/0x90
[192885.875617] mntput_no_expire+0x13b/0x190
[192885.875621] kern_unmount+0x3e/0x50
[192885.875626] pid_ns_release_proc+0x15/0x20
[192885.875630] proc_cleanup_work+0x15/0x20
[192885.875636] process_one_work+0x197/0x450
[192885.875641] worker_thread+0x4e/0x4a0
[192885.875648] kthread+0x109/0x140
[192885.875652] ? process_one_work+0x450/0x450
[192885.875657] ? kthread_park+0x90/0x90
[192885.875665] ret_from_fork+0x2c/0x40
[192885.875670] ---[ end trace e1c109611e5d0b41 ]---
[192885.875688] VFS: Busy inodes after unmount of proc. Self-destruct in 5
seconds. Have a nice day...
[192885.875755] BUG: unable to handle kernel NULL pointer dereference at
(null)
[192885.875959] IP: _raw_spin_lock+0xc/0x30
[192885.876033] PGD 0
>
> Thanks!
>
> >
> > I think the following change where it uses igrab has the possibility
> > of increasing the inode count while a pid namespace is being shut down.
> > So it is worth a good hard look and fixes and possibly a revert if we
> > can prove that this is the issue.
> >
> > commit d6cffbbe9a7e51eb705182965a189457c17ba8a3
> > Author: Konstantin Khlebnikov
> > Date: Fri Feb 10 10:35:02 2017 +0300
> >
> > proc/sysctl: prune stale dentries during unregistering
> >
> > Eric
> >
> >
> > > Thanks,
> > > Andrei
> > >
> > >>
> > >> Eric
> > >>
> > >>> [root@zdtm linux]# git describe HEAD~1
> > >>> v4.12-rc7-25-g6474924
> > >>>
> > >>> And there is one more patch from the netfilter tree:
> > >>> commit b216759c0cb5d37d1eec3cd5b67ba38bace94fd8
> > >>> Author: Liping Zhang
> > >>> Date: Sun Jun 4 19:17:34 2017 +0800
> > >>>
> > >>> netfilter: nf_ct_dccp/sctp: fix memory leak after netns cleanup
> > >>>
> > >>> [root@zdtm linux]# uname -a
> > >>> Linux zdtm.openvz.org 4.12.0-rc7+ #9 SMP Thu Jun 29 08:28:18 CEST 2017
> > >>> x86_64 x86_64 x86_64 GNU/Linux
> > >>>
> > >>> A kernel config is attached.
> > >>>
> > >>>
> > >>> [22458.504137] BUG: Dentry 9f795a08fe60{i=af565f,n=lo} still in
> > >>> u
Re: [CRIU] BUG: Dentry ffff9f795a08fe60{i=af565f, n=lo} still in use (1) [unmount of proc proc]
On Thu, Jun 29, 2017 at 08:42:23PM -0500, Eric W. Biederman wrote: > Andrei Vagin writes: > > > On Thu, Jun 29, 2017 at 12:06 PM, Eric W. Biederman > > wrote: > >> Andrei Vagin writes: > >> > >>> Hello, > >>> > >>> We run CRIU tests on linus' tree and today we found this issue. > >>> > >>> CRIU tests are the set of small programs to check checkpoint/restore > >>> of different primitives (files, sockets, signals, pipes, etc). > >>> https://github.com/xemul/criu/tree/master/test > >>> > >>> Each test is executed three times: without namespaces, in a set of all > >>> namespaces except userns, in a set of all namespaces. When a test > >>> passed the preparation tests, it sends a signal to an executer, and > >>> then the executer dumps and restores tests processes, and sends a > >>> signal to the test back to check that everything are restored > >>> correctly. > >> > >> I am not certain what you are saying, and you seem to have Cc'd > >> every list except the netdev and netfilter lists that are needed > >> to deal with this. > >> > >> Are you saing that the change from Liping Zhang is needed? Or are you > >> saying that change introduces the problem below? > > > > Hi Eric, > > > > Here I tried to explain our usecase. I don't know which changes in the > > kernel affect this issue. > > > > Actually I reported about the similar problem a few month ago on the > > linux-next: > > https://lkml.org/lkml/2017/3/10/1586 > > > > So I don't think that the change from Liping Zhang affects this issue > > somehow. I mentioned it just to describe what kernel we used. > > > > And I don't know how to reproduce the issue. You can see from the > > kernel log, that the kernel worked for more than 6 hours in out case. > > During this perioud we run all our tests a few times, so I think there > > is a kind of race. > > > >> > >> I could not find the mentioned commits. Are the in Linus's tree or > >> someone's next tree that feeds into linux-next? > > > > Here is the patch from Liping Zhang > > https://patchwork.ozlabs.org/patch/770887/ > > > > The second mentioned commit is HEAD of the master branch in Linus' tree: > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=6474924e2b5ddb0030c38966adcbe3b49022 > > Apologies I somehow thought that g in the kernel version you mentioned > was part of the commit id and thus I could not find it. Sigh. > > Ok so with Linus's tree and that one extra patch from Liping Zhang you > have kernel problems sometimes. > > The warning and the oops combined are quite suggestive of what is going > on. It does sound like while the pid namespace is being unregistered > something under /proc/sys/net/ipv4/conf//... is being accessed > and keeping the inode busy. > > Which then leads to an oops when the network namespace is being cleaned > up later, as it tries to purge all of the inodes. > > Which raises the question how in the world can the count of the > superblock drop to zero with an inode in use. > > As devinet is where things go strange this does seem completely > independent of what Liping Zhang was looking at. > > This does smell like a bug in the generic code. Hmm. > > Is this consistently reproducible when you run your tests... I'm not sure about that. I'm going to do some experiments to understand how often it is reproduced on our test system, and then will try to revert the patch from Konstantin. Thanks! > > I think the following change where it uses igrab has the possibility > of increasing the inode count while a pid namespace is being shut down. > So it is worth a good hard look and fixes and possibly a revert if we > can prove that this is the issue. > > commit d6cffbbe9a7e51eb705182965a189457c17ba8a3 > Author: Konstantin Khlebnikov > Date: Fri Feb 10 10:35:02 2017 +0300 > > proc/sysctl: prune stale dentries during unregistering > > Eric > > > > Thanks, > > Andrei > > > >> > >> Eric > >> > >>> [root@zdtm linux]# git describe HEAD~1 > >>> v4.12-rc7-25-g6474924 > >>> > >>> And there is one more patch from the netfilter tree: > >>> commit b216759c0cb5d37d1eec3cd5b67ba38bace94fd8 > >>> Author: Liping Zhang > >>> Date: Sun Jun 4 19:17:34 2017 +0800 > >>> > >>> netfilter: nf_
Re: BUG: Dentry ffff9f795a08fe60{i=af565f,n=lo} still in use (1) [unmount of proc proc]
On Thu, Jun 29, 2017 at 12:06 PM, Eric W. Biederman
wrote:
> Andrei Vagin writes:
>
>> Hello,
>>
>> We run CRIU tests on linus' tree and today we found this issue.
>>
>> CRIU tests are the set of small programs to check checkpoint/restore
>> of different primitives (files, sockets, signals, pipes, etc).
>> https://github.com/xemul/criu/tree/master/test
>>
>> Each test is executed three times: without namespaces, in a set of all
>> namespaces except userns, in a set of all namespaces. When a test
>> passed the preparation tests, it sends a signal to an executer, and
>> then the executer dumps and restores tests processes, and sends a
>> signal to the test back to check that everything are restored
>> correctly.
>
> I am not certain what you are saying, and you seem to have Cc'd
> every list except the netdev and netfilter lists that are needed
> to deal with this.
>
> Are you saing that the change from Liping Zhang is needed? Or are you
> saying that change introduces the problem below?
Hi Eric,
Here I tried to explain our usecase. I don't know which changes in the
kernel affect this issue.
Actually I reported about the similar problem a few month ago on the linux-next:
https://lkml.org/lkml/2017/3/10/1586
So I don't think that the change from Liping Zhang affects this issue
somehow. I mentioned it just to describe what kernel we used.
And I don't know how to reproduce the issue. You can see from the
kernel log, that the kernel worked for more than 6 hours in out case.
During this perioud we run all our tests a few times, so I think there
is a kind of race.
>
> I could not find the mentioned commits. Are the in Linus's tree or
> someone's next tree that feeds into linux-next?
Here is the patch from Liping Zhang
https://patchwork.ozlabs.org/patch/770887/
The second mentioned commit is HEAD of the master branch in Linus' tree:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=6474924e2b5ddb0030c38966adcbe3b49022
Thanks,
Andrei
>
> Eric
>
>> [root@zdtm linux]# git describe HEAD~1
>> v4.12-rc7-25-g6474924
>>
>> And there is one more patch from the netfilter tree:
>> commit b216759c0cb5d37d1eec3cd5b67ba38bace94fd8
>> Author: Liping Zhang
>> Date: Sun Jun 4 19:17:34 2017 +0800
>>
>> netfilter: nf_ct_dccp/sctp: fix memory leak after netns cleanup
>>
>> [root@zdtm linux]# uname -a
>> Linux zdtm.openvz.org 4.12.0-rc7+ #9 SMP Thu Jun 29 08:28:18 CEST 2017
>> x86_64 x86_64 x86_64 GNU/Linux
>>
>> A kernel config is attached.
>>
>>
>> [22458.504137] BUG: Dentry 9f795a08fe60{i=af565f,n=lo} still in
>> use (1) [unmount of proc proc]
>> [22458.505117] [ cut here ]
>> [22458.505299] WARNING: CPU: 0 PID: 15036 at fs/dcache.c:1445
>> umount_check+0x66/0x80
>> [22458.505564] Modules linked in: nfsd auth_rpcgss nfs_acl lockd grace
>> sunrpc macvlan tun veth nf_conntrack_netlink xt_mark udp_diag tcp_diag
>> inet_diag netlink_diag af_packet_diag unix_diag binfmt_misc
>> ip6t_rpfilter ip6t_REJECT nf_reject_ipv6 xt_conntrack ip_set nfnetlink
>> ebtable_broute bridge stp llc ebtable_nat ip6table_security
>> ip6table_mangle ip6table_raw ip6table_nat nf_conntrack_ipv6
>> nf_defrag_ipv6 nf_nat_ipv6 iptable_security iptable_mangle iptable_raw
>> iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat
>> nf_conntrack ebtable_filter ebtables ip6table_filter ip6_tables btrfs
>> xor raid6_pq loop ppdev crct10dif_pclmul crc32_pclmul
>> ghash_clmulni_intel lpc_ich sbs virtio_balloon shpchp sbshc parport_pc
>> parport tpm_tis tpm_tis_core tpm xfs libcrc32c crc32c_intel
>> ata_generic serio_raw pata_acpi
>> [22458.507586] virtio_pci virtio virtio_ring e1000
>> [22458.507771] CPU: 0 PID: 15036 Comm: kworker/0:2 Not tainted 4.12.0-rc7+ #9
>> [22458.507830] systemd-journald[561]: Compressed data object 807 ->
>> 605 using LZ4
>> [22458.508184] Hardware name: Parallels Software International Inc.
>> Parallels Virtual Platform/Parallels Virtual Platform, BIOS
>> 6.12.26068.1232434 02/27/2017
>> [22458.508641] Workqueue: events proc_cleanup_work
>> [22458.508848] task: 9f797be8 task.stack: b2b8825f
>> [22458.509033] RIP: 0010:umount_check+0x66/0x80
>> [22458.509172] RSP: 0018:b2b8825f3c68 EFLAGS: 00010286
>> [22458.509363] RAX: 0054 RBX: 9f798492afa0 RCX:
>>
>> [22458.509589] RDX: RSI: 9f79bce0e388 RDI:
>> 9f79bce0e388
>> [22458.509823] RBP: b2b8825f3c70 R08: R09:
>>
&
