Bug 742708 - Cannot create file in /tmp and /var/tmp after resume from hibernation (ext4)
Cannot create file in /tmp and /var/tmp after resume from hibernation (ext4)
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
15
x86_64 Linux
unspecified Severity unspecified
: ---
: ---
Assigned To: Eric Sandeen
Fedora Extras Quality Assurance
:
Depends On:
Blocks: kernel_hibernate
  Show dependency treegraph
 
Reported: 2011-10-01 16:38 EDT by Thomas Jollans
Modified: 2012-07-11 13:54 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-07-11 13:54:07 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Thomas Jollans 2011-10-01 16:38:00 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   2.6.40.4-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: 2.6.40.4-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.
  
Actual results:
Cannot create files /tmp and /var/tmp.

Expected results:
Creating files in /tmp and /var/tmp is possible, assuming it was before hibernation.

Additional info:
Comment 1 Eric Sandeen 2011-10-03 11:58:04 EDT
why is vg_zarniwoop-lv_root mounted on /, /tmp, and /var/tmp ... are those bind mounts or something?
Comment 2 Thomas Jollans 2011-10-03 12:47:36 EDT
I haven't a clue. This is the configuration anaconda produced. /tmp and /var/tmp do not appear in /etc/fstab:

#
# /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.
Comment 3 Eric Sandeen 2011-10-03 12:56:02 EDT
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.
Comment 4 Thomas Jollans 2011-10-03 13:59:52 EDT
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
Comment 5 Eric Sandeen 2011-10-03 15:58:37 EDT
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? :)
Comment 6 Thomas Jollans 2011-10-03 16:01:33 EDT
Yes, exactly. With sandbox enabled, the post-hibernation problems are always there, with it disabled, they don't exist.
Comment 7 Eric Sandeen 2011-10-03 16:09:17 EDT
Wild.  Ok, let me ponder that one :)
Comment 8 Eric Sandeen 2012-01-13 17:58:23 EST
I've been unable thus far to repro even w/ sandbox turned on.  Argh!
Comment 9 Josh Boyer 2012-03-28 14:03:25 EDT
[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:

http://koji.fedoraproject.org/koji/taskinfo?taskID=3940545

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.
Comment 10 Josh Boyer 2012-07-11 13:54:07 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.