summaryrefslogtreecommitdiffstats
path: root/fs/omfs/dir.c
diff options
context:
space:
mode:
authorRafael J. Wysocki <rafael.j.wysocki@intel.com>2013-11-14 23:26:58 +0100
committerRafael J. Wysocki <rafael.j.wysocki@intel.com>2013-11-14 23:26:58 +0100
commit6a0c7cd33075f6b7f1d80145bb19812beb3fc5c9 (patch)
tree1c77c05c8d41003216262585a82155fcb448fa41 /fs/omfs/dir.c
parent5e01dc7b26d9f24f39abace5da98ccbd6a5ceb52 (diff)
downloadop-kernel-dev-6a0c7cd33075f6b7f1d80145bb19812beb3fc5c9.zip
op-kernel-dev-6a0c7cd33075f6b7f1d80145bb19812beb3fc5c9.tar.gz
PM / Hibernate: Do not crash kernel in free_basic_memory_bitmaps()
I have received a report about the BUG_ON() in free_basic_memory_bitmaps() triggering mysteriously during an aborted s2disk hibernation attempt. The only way I can explain that is that /dev/snapshot was first opened for writing (resume mode), then closed and then opened again for reading and closed again without freezing tasks. In that case the first invocation of snapshot_open() would set the free_bitmaps flag in snapshot_state, which is a static variable. That flag wouldn't be cleared later and the second invocation of snapshot_open() would just leave it like that, so the subsequent snapshot_release() would see data->frozen set and free_basic_memory_bitmaps() would be called unnecessarily. To prevent that from happening clear data->free_bitmaps in snapshot_open() when the file is being opened for reading (hibernate mode). In addition to that, replace the BUG_ON() in free_basic_memory_bitmaps() with a WARN_ON() as the kernel can continue just fine if the condition checked by that macro occurs. Fixes: aab172891542 (PM / hibernate: Fix user space driven resume regression) Reported-by: Oliver Lorenz <olli@olorenz.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Cc: 3.12+ <stable@vger.kernel.org> # 3.12+
Diffstat (limited to 'fs/omfs/dir.c')
0 files changed, 0 insertions, 0 deletions
OpenPOWER on IntegriCloud