Linux kernel stable tree https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux-stable.git/atom?h=master 2016-12-15T04:48:11+00:00 2016-12-15T04:48:11+00:00 Christoph Hellwig hch@lst.de 2016-09-11T14:04:46+00:00 urn:sha1:1d0fd57a50aa372dd2e84b16711023cbcd826cb8 Logfs was introduced to the kernel in 2009, and hasn't seen any non drive-by changes since 2012, while having lots of unsolved issues including the complete lack of error handling, with more and more issues popping up without any fixes. The logfs.org domain has been bouncing from a mail, and the maintainer on the non-logfs.org domain hasn't repsonded to past queries either. Signed-off-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> 2012-07-23T03:48:14+00:00 Prasad Joshi prasadjoshi.linux@gmail.com 2012-07-23T03:48:14+00:00 urn:sha1:ddb24bbac3681b87ae0638aacb702d9273e3c025 While writing the partial journal entries we assumed that the page associated with the journal would always in locatable. This incorrect assumption resulted in the following BUG kernel BUG at /home/benixon/WD_SMR/kernels/linux-3.3.7-logfs/fs/logfs/journal.c:569! EIP is at logfs_write_area+0xb6/0x109 [logfs] EAX: 00000000 EBX: 00000000 ECX: ef6efea4 EDX: 00000000 ESI: 001b9000 EDI: f009e000 EBP: c3c13f14 ESP: c3c13ef0 DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068 Process sync (pid: 1799, ti=c3c12000 task=f07825b0 task.ti=c3c12000) Stack: 01001000 c3c13f26 781b9000 00000000 f009e000 f7286000 f1f83400 f8445071 f1f83400 c3c13f30 f8445ae9 c3c13f20 0000100a 000ee000 f009e000 00000001 c3c13f5c f8445d17 c05eb0ee 00000000 f1f83400 ef718000 f009e25c ea9c3d80 Call Trace: [<f8445071>] ? account_shadow+0x16d/0x16d [logfs] [<f8445ae9>] logfs_write_je+0x2a/0x44 [logfs] [<f8445d17>] logfs_write_anchor+0x114/0x228 [logfs] [<c05eb0ee>] ? empty+0x5/0x5 [<f8444522>] logfs_sync_fs+0x1e/0x31 [logfs] [<c051be66>] __sync_filesystem+0x5d/0x6f [<c051be8d>] sync_one_sb+0x15/0x17 [<c04ff8b0>] iterate_supers+0x59/0x9a [<c051be78>] ? __sync_filesystem+0x6f/0x6f [<c051befc>] sys_sync+0x29/0x4f [<c084285f>] sysenter_do_call+0x12/0x28 EIP: [<f8445127>] logfs_write_area+0xb6/0x109 [logfs] SS:ESP 0068:c3c13ef0 ---[ end trace ef6e9ef52601a945 ]--- The fix is to create the pagecache page if it is not locatable. Reported-and-tested-by: Benixon Dhas <Benixon.Dhas@wdc.com> Signed-off-by: Prasad Joshi <prasadjoshi.linux@gmail.com> 2012-01-28T06:11:56+00:00 Joern Engel joern@logfs.org 2011-09-12T15:39:16+00:00 urn:sha1:6c69494f6b442834f26377e02d43fc8e1272221d It prevents write sizes >4k. Signed-off-by: Joern Engel <joern@logfs.org> 2010-12-23T03:43:33+00:00 Prasad Joshi prasadjoshi124@gmail.com 2010-12-22T01:24:19+00:00 urn:sha1:eabb26cacdec33ca6f6fcaee762b57c2205169ca do_logfs_journal_wl_pass() should use GFP_NOFS for memory allocation GC code calls btree_insert32 with GFP_KERNEL while holding a mutex super->s_write_mutex. The same mutex is used in address_space_operations->writepage(), and a call to writepage() could be triggered as a result of memory allocation in btree_insert32, causing a deadlock. Addresses https://bugzilla.kernel.org/show_bug.cgi?id=20342 Signed-off-by: Prasad Joshi <prasadjoshi124@gmail.com> Cc: Joern Engel <joern@logfs.org> Cc: Florian Mickler <florian@mickler.org> Cc: "Rafael J. Wysocki" <rjw@sisk.pl> Cc: Maciej Rutecki <maciej.rutecki@gmail.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> 2010-08-09T20:48:26+00:00 Al Viro viro@zeniv.linux.org.uk 2010-06-07T16:22:31+00:00 urn:sha1:8e22c1a4e429e9facf309c7e7a03ba9cdfd7b106 ordering problems at ->kill_sb() time are solved by doing iput() of these suckers in ->put_super() Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> 2010-05-04T17:37:04+00:00 Joern Engel joern@logfs.org 2010-05-03T18:54:34+00:00 urn:sha1:20503664b008e17976bff1fdbc693c77ebd6f6c9 Refusing to mount beats a kernel crash. Signed-off-by: Joern Engel <joern@logfs.org> 2010-04-21T19:31:12+00:00 Linus Torvalds torvalds@linux-foundation.org 2010-04-21T19:31:12+00:00 urn:sha1:255f41c59558a346d65a2012420a7573e36dc584 * git://git.kernel.org/pub/scm/linux/kernel/git/joern/logfs: [LogFS] Split large truncated into smaller chunks [LogFS] Set s_bdi [LogFS] Prevent mempool_destroy NULL pointer dereference [LogFS] Move assertion [LogFS] Plug 8 byte information leak [LogFS] Prevent memory corruption on large deletes [LogFS] Remove unused method Fix trivial conflict with added header includes in fs/logfs/super.c 2010-04-13T15:57:21+00:00 Joern Engel joern@logfs.org 2010-04-13T15:57:21+00:00 urn:sha1:ead88af5f577fd2b399a0fcdfe52605116fac489 The assertion is valid independently of the condition. Signed-off-by: Joern Engel <joern@logfs.org> 2010-04-13T15:54:27+00:00 Joern Engel joern@logfs.org 2010-04-13T15:54:27+00:00 urn:sha1:d3a03f8031000f8297823b80e36db536fd020884 Within each journal segment, 8 bytes at offset 24 would remain uninitialized. Signed-off-by: Joern Engel <joern@logfs.org> 2010-04-13T15:46:37+00:00 Joern Engel joern@logfs.org 2010-04-13T15:46:37+00:00 urn:sha1:032d8f7268444a0f5d4ee02d9513d682d5b8edfc Removing sufficiently large files would create aliases for a large number of segments. This in turn results in a large number of journal entries and an overflow of s_je_array. Cheap fix is to add a BUG_ON, turning memory corruption into something annoying, but less dangerous. Real fix is to count the number of affected segments and prevent the problem completely. Signed-off-by: Joern Engel <joern@logfs.org>