Red Hat Bugzilla – Bug 742708
Cannot create file in /tmp and /var/tmp after resume from hibernation (ext4)
Last modified: 2012-07-11 13:54:07 EDT
Description of problem:
After resuming from hibernation, no files can be created in /tmp and /var/tmp. After attempting to create a file, the following appears in dmesg output:
[ 2233.810115] ------------[ cut here ]------------
[ 2233.810138] WARNING: at fs/inode.c:901 unlock_new_inode+0x2e/0x4a()
[ 2233.810145] Hardware name: 1298A15
[ 2233.810151] Modules linked in: fuse ppdev parport_pc lp parport 8021q garp stp llc sunrpc cpufreq_ondemand acpi_cpufreq mperf bnep ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 ip6table_filter ip6_tables bluetooth nf_conntrack_ipv4 nf_defrag_ipv4 xt_state nf_conntrack snd_hda_codec_hdmi snd_hda_codec_conexant uvcvideo videodev snd_hda_intel snd_hda_codec snd_hwdep snd_seq thinkpad_acpi snd_seq_device snd_pcm arc4 media iwlagn mac80211 i2c_i801 atl1c iTCO_wdt iTCO_vendor_support cfg80211 snd_timer serio_raw joydev v4l2_compat_ioctl32 snd snd_page_alloc rfkill soundcore microcode ipv6 xts gf128mul dm_crypt sdhci_pci sdhci mmc_core wmi i915 drm_kms_helper drm i2c_algo_bit i2c_core video [last unloaded: scsi_wait_scan]
[ 2233.810308] Pid: 3127, comm: touch Tainted: G W 22.214.171.124-5.fc15.x86_64 #1
[ 2233.810316] Call Trace:
[ 2233.810336] [<ffffffff81054c8e>] warn_slowpath_common+0x83/0x9b
[ 2233.810350] [<ffffffff81054cc0>] warn_slowpath_null+0x1a/0x1c
[ 2233.810361] [<ffffffff8113a072>] unlock_new_inode+0x2e/0x4a
[ 2233.810375] [<ffffffff8119a43f>] ext4_new_inode+0xc88/0xd1d
[ 2233.810388] [<ffffffff811a55d5>] ext4_create+0xbc/0x13e
[ 2233.810401] [<ffffffff81131af3>] vfs_create+0x6c/0x8e
[ 2233.810412] [<ffffffff81131d57>] do_last+0x242/0x581
[ 2233.810423] [<ffffffff81132c1b>] path_openat+0xc8/0x31c
[ 2233.810435] [<ffffffff810f9956>] ? handle_mm_fault+0x1c8/0x1db
[ 2233.810447] [<ffffffff81132ea7>] do_filp_open+0x38/0x86
[ 2233.810460] [<ffffffff8113c761>] ? alloc_fd+0x72/0x11d
[ 2233.810471] [<ffffffff81126804>] do_sys_open+0x6e/0x100
[ 2233.810482] [<ffffffff810a0e84>] ? audit_syscall_entry+0x145/0x171
[ 2233.810493] [<ffffffff811268b6>] sys_open+0x20/0x22
[ 2233.810507] [<ffffffff8148e842>] system_call_fastpath+0x16/0x1b
[ 2233.810515] ---[ end trace 512e6d4e269af503 ]---
The file system is ext4. Encrypted, as configured by Fedora 15's anaconda installer. This problem only (and always) occurs after resume from hibernation, and only in /tmp and /var/tmp - the rest of the file system is unaffected. The root file system appears to be mounted separately on /tmp and /var/tmp
% mount | grep lv_root
/dev/mapper/vg_zarniwoop-lv_root on / type ext4 (rw,relatime,seclabel,user_xattr,barrier=1,data=ordered)
/dev/mapper/vg_zarniwoop-lv_root on /tmp type ext4 (rw,relatime,seclabel,user_xattr,barrier=1,data=ordered)
/dev/mapper/vg_zarniwoop-lv_root on /var/tmp type ext4 (rw,relatime,seclabel,user_xattr,barrier=1,data=ordered)
This is also the case before hibernation, and doesn't cause any problems then, but it is the only visible (to me) difference between /tmp,/var/tmp and the rest of the file system.
Version-Release number of selected component (if applicable):
Kernel version: 126.96.36.199-5.fc15.x86_64
Fedora 15, system is fully up to date.
How reproducible: always.
Steps to Reproduce:
1. Confirm that /tmp is writable.
2. Hibernate machine. On boot, enter encryption password. System resumes.
3. Confirm that creating files in /tmp is now impossible.
Cannot create files /tmp and /var/tmp.
Creating files in /tmp and /var/tmp is possible, assuming it was before hibernation.
why is vg_zarniwoop-lv_root mounted on /, /tmp, and /var/tmp ... are those bind mounts or something?
I haven't a clue. This is the configuration anaconda produced. /tmp and /var/tmp do not appear in /etc/fstab:
# Created by anaconda on Thu Sep 22 16:14:31 2011
# Accessible filesystems, by reference, are maintained under '/dev/disk'
# See man pages fstab(5), findfs(8), mount(8) and/or blkid(8) for more info
/dev/mapper/vg_zarniwoop-lv_root / ext4 defaults 1 1
UUID=d181aee8-2b6f-4dfa-99f0-9de33fda7fec /boot ext4 defaults 1 2
/dev/mapper/vg_zarniwoop-lv_home /home ext4 defaults,user_xattr,noatime 1 2
/dev/mapper/vg_zarniwoop-lv_swap swap swap defaults 0 0
tmpfs /dev/shm tmpfs defaults 0 0
devpts /dev/pts devpts gid=5,mode=620 0 0
sysfs /sys sysfs defaults 0 0
proc /proc proc defaults 0 0
In addition to that, while /tmp, /var/tmp, and / appear to be identical, they all have distinct contents, and, before hibernation, the system acts as it should if /var/tmp and /tmp weren't somehow separate mounts.
This may of course not be a bug in the kernel, it could be an unforseen side effect of whatever is creating these illogical mount points, whatever that may be.
Very weird - so /tmp & /var/tmp aren't even listed in fstab, yet somehow /etc/mtab thinks they are mounted from the root fs... What does /proc/mounts say, hopefully it looks saner?
I don't know if this is related to the actual problem or not, but it seems odd.
Okay, after some extensive grepping through /etc, I found the reason for the mysterious /tmp and /var/tmp: /etc/init.d/sandbox. This script does:
mount --make-rshared / || return $?
mount --rbind /tmp /tmp || return $?
mount --rbind /var/tmp /var/tmp || return $?
mount --make-private /tmp || return $?
mount --make-private /var/tmp || return $?
I don't think I need this, so I disabled the service, and everything works - but it looks like this mount configuration messes up ext4 in ways that it shouldn't.
/etc/init.d/sandbox is installed by policycoreutils-2.0.86-7.fc15.x86_64
So just to be clear - did disabling it have any effect on the post-hibernation problem? And if so, was it 100% reproducible before, and 0% reproducible after? :)
Yes, exactly. With sandbox enabled, the post-hibernation problems are always there, with it disabled, they don't exist.
Wild. Ok, let me ponder that one :)
I've been unable thus far to repro even w/ sandbox turned on. Argh!
[Mass hibernate bug update]
Dave Airlied has found an issue causing some corruption in the i915 fbdev after a resume from hibernate. I have included his patch in this scratch build:
This will probably not solve all of the issues being tracked at the moment, but it is worth testing when the build completes. If this seems to clear up the issues you see with hibernate, please report your results in the bug.
Fedora 15 has reached it's end of life as of June 26, 2012. As a result, we will not be fixing any remaining bugs found in Fedora 15.
In the event that you have upgraded to a newer release and the bug you reported is still present, please reopen the bug and set the version field to the newest release you have encountered the issue with. Before doing so, please ensure you are testing the latest kernel update in that release and attach any new and relevant information you may have gathered.
Thank you for taking the time to file a report. We hope newer versions of Fedora suit your needs.