[Ocfs2-devel] [PATCH] [ocfs2]: pass new parameter to ocfs2_init_xattr_bucket

2014-03-28 Thread Wengang Wang
This patch fixes the following crash:

[71379.310340] kernel BUG at fs/ocfs2/uptodate.c:530!
[71379.310340] invalid opcode:  [#1] SMP
[71379.310340] Modules linked in: ocfs2(F) ocfs2_dlmfs ocfs2_stack_o2cb 
ocfs2_dlm ocfs2_nodemanager ocfs2_stackglue configfs bridge xen_pciback 
xen_netback xen_blkback xen_gntalloc xen_gntdev xen_evtchn xenfs xen_privcmd 
sunrpc 8021q garp stp llc bonding be2iscsi iscsi_boot_sysfs bnx2i cnic uio 
cxgb4i cxgb4 cxgb3i libcxgbi cxgb3 mdio ib_iser rdma_cm ib_cm iw_cm ib_sa 
ib_mad ib_core ib_addr ipv6 iscsi_tcp libiscsi_tcp libiscsi 
scsi_transport_iscsi iTCO_wdt iTCO_vendor_support dcdbas coretemp freq_table 
mperf microcode pcspkr serio_raw bnx2 lpc_ich mfd_core i5k_amb i5000_edac 
edac_core e1000e sg shpchp ext4(F) jbd2(F) mbcache(F) dm_round_robin(F) 
sr_mod(F) cdrom(F) usb_storage(F) sd_mod(F) crc_t10dif(F) pata_acpi(F) 
ata_generic(F) ata_piix(F) mptsas(F) mptscsih(F) mptbase(F) 
scsi_transport_sas(F) radeon(F)
[71379.310340]  ttm(F) drm_kms_helper(F) drm(F) hwmon(F) i2c_algo_bit(F) 
i2c_core(F) dm_multipath(F) dm_mirror(F) dm_region_hash(F) dm_log(F) dm_mod(F)
[71379.310340] CPU 5
[71379.310340] Pid: 21303, comm: xattr-test Tainted: GF   W
3.8.13-30.el6uek.x86_64 #2 Dell Inc. PowerEdge 1950/0M788G
[71379.310340] RIP: e030:[a074b451]  [a074b451] 
ocfs2_set_new_buffer_uptodate+0x51/0x60 [ocfs2]
[71379.310340] RSP: e02b:880017acb7a8  EFLAGS: 00010202
[71379.310340] RAX: 0001 RBX: 880038f30478 RCX: 8800072f0748
[71379.310340] RDX: 00146326 RSI: 8800072f0748 RDI: 880038f3041c
[71379.310340] RBP: 880017acb7b8 R08: 0004 R09: ea41d69c
[71379.310340] R10: 330a R11:  R12: 8800072f0748
[71379.310340] R13: 00146326 R14:  R15: 88001892ea40
[71379.310340] FS:  7f1922ffc700() GS:88003994() 
knlGS:
[71379.310340] CS:  e033 DS:  ES:  CR0: 8005003b
[71379.310340] CR2: ff600400 CR3: 026c3000 CR4: 2660
[71379.310340] DR0:  DR1:  DR2: 
[71379.310340] DR3:  DR6: 0ff0 DR7: 0400
[71379.310340] Process xattr-test (pid: 21303, threadinfo 880017aca000, 
task 880016a2c480)
[71379.310340] Stack:
[71379.310340]  88001892ea40 88001892ea40 880017acb7f8 
a075950a
[71379.310340]  880038f304c0 880038f304c0  
00146326
[71379.310340]  880017ffc240  880017acb858 
a075965b
[71379.310340] Call Trace:
[71379.310340]  [a075950a] ocfs2_init_xattr_bucket+0x8a/0x120 [ocfs2]
[71379.310340]  [a075965b] ocfs2_cp_xattr_bucket+0xbb/0x1b0 [ocfs2]
[71379.310340]  [a075a73a] ocfs2_extend_xattr_bucket+0x20a/0x2f0 
[ocfs2]
[71379.310340]  [a075f87e] ocfs2_add_new_xattr_bucket+0x23e/0x4b0 
[ocfs2]
[71379.310340]  [a075dc3f] ? ocfs2_xattr_set_entry_bucket+0x1af/0x2d0 
[ocfs2]
[71379.310340]  [a024e934] ? jbd2_journal_dirty_metadata+0xf4/0x250 
[jbd2]
[71379.310340]  [a075fc2c] 
ocfs2_xattr_set_entry_index_block+0x13c/0x3d0 [ocfs2]
[71379.310340]  [a0752f72] ? ocfs2_xa_block_journal_dirty+0x12/0x20 
[ocfs2]
[71379.310340]  [a075ffb9] ocfs2_xattr_block_set+0xf9/0x220 [ocfs2]
[71379.310340]  [a075d981] ? ocfs2_xattr_ibody_set+0x1f1/0x300 [ocfs2]
[71379.310340]  [a07627e8] __ocfs2_xattr_set_handle+0x118/0x710 
[ocfs2]
[71379.310340]  [a024fb33] ? jbd2_journal_start+0x13/0x20 [jbd2]
[71379.310340]  [a0763471] ocfs2_xattr_set+0x691/0x880 [ocfs2]
[71379.310340]  [a07636a6] ocfs2_xattr_user_set+0x46/0x50 [ocfs2]
[71379.310340]  [811b4616] generic_setxattr+0x96/0xa0
[71379.310340]  [811b5b4b] __vfs_setxattr_noperm+0x7b/0x170
[71379.310340]  [811b5cfc] vfs_setxattr+0xbc/0xc0
[71379.310340]  [811b5dde] setxattr+0xde/0x230
[71379.310340]  [811b5ff6] sys_fsetxattr+0xc6/0xf0
[71379.310340]  [8159d599] system_call_fastpath+0x16/0x1b
[71379.310340] Code: 41 80 0c 24 01 48 89 df e8 7d f0 ff ff 4c 89 e6 48 89 df 
e8 a2 fe ff ff 48 89 df e8 3a f0 ff ff 48 8b 1c 24 4c 8b 64 24 08 c9 c3 0f 0b 
eb fe 90 90 90 90 90 90 90 90 90 90 90 55 48 89 e5 66 66
[71379.310340] RIP  [a074b451] 
ocfs2_set_new_buffer_uptodate+0x51/0x60 [ocfs2]
[71379.310340]  RSP 880017acb7a8

It hit the BUG_ON() in ocfs2_set_new_buffer_uptodate().

527 void ocfs2_set_new_buffer_uptodate(struct ocfs2_caching_info *ci,
528struct buffer_head *bh)
529 {
530 /* This should definitely *not* exist in our cache */
531 if (ocfs2_buffer_cached(ci, bh))
532 printk(KERN_ERR bh-b_blocknr: %lu @ %p\n, bh-b_blocknr, 
bh);
533 BUG_ON(ocfs2_buffer_cached(ci, bh));
534
535 set_buffer_uptodate(bh);
536
537 

Re: [Ocfs2-devel] [PATCH] ocfs2: Fix panic on kfree(xattr-name)

2014-03-28 Thread Tetsuo Handa
Thank you for testing.

Mark and Joel, would you pick up this patch via your tree?

Tariq Saeed wrote:
 The patch works. What is the plan for submitting to mainline?
 Thanks,
 -Tariq
 
 On 03/19/2014 05:55 AM, Tetsuo Handa wrote:
  Tariq Saeed wrote:
  This commit did not take into account the callers of this function who
  assume they need to kfree() the name. It causes panic in ocfs2 on create
  file. I am puzzled how did this commit got into the tree without changing
  the callsites to NOT call kfree anymore. Am I missing something?
 
  You are right. It is my mistake. I didn't realize that ocfs2 is calling 
  kfree()
  on the name field. Would you please test below patch?
 
  Regards.
  --
 From 3940749700148f58265407987f813b773515661a Mon Sep 17 00:00:00 2001
  From: Tetsuo Handa penguin-ker...@i-love.sakura.ne.jp
  Date: Wed, 19 Mar 2014 21:49:21 +0900
  Subject: [PATCH] ocfs2: Fix panic on kfree(xattr-name)
 
  Commit 9548906b 'xattr: Constify -name member of struct xattr.' missed 
  that
  ocfs2 is calling kfree(xattr-name). As a result, kernel panic occurs upon
  calling kfree(xattr-name) because xattr-name refers static constant names.
  This patch removes kfree(xattr-name) from ocfs2_mknod() and 
  ocfs2_symlink().
 
  Reported-by: Tariq Saeed tariq.x.sa...@oracle.com
  Signed-off-by: Tetsuo Handa penguin-ker...@i-love.sakura.ne.jp
  Cc: sta...@vger.kernel.org [3.12+]
  ---
fs/ocfs2/namei.c |2 --
1 files changed, 0 insertions(+), 2 deletions(-)
 
  diff --git a/fs/ocfs2/namei.c b/fs/ocfs2/namei.c
  index 3683643..feed025 100644
  --- a/fs/ocfs2/namei.c
  +++ b/fs/ocfs2/namei.c
  @@ -450,7 +450,6 @@ leave:
 
  brelse(new_fe_bh);
  brelse(parent_fe_bh);
  -   kfree(si.name);
  kfree(si.value);
 
  ocfs2_free_dir_lookup_result(lookup);
  @@ -1855,7 +1854,6 @@ bail:
 
  brelse(new_fe_bh);
  brelse(parent_fe_bh);
  -   kfree(si.name);
  kfree(si.value);
  ocfs2_free_dir_lookup_result(lookup);
  if (inode_ac)
 
 

___
Ocfs2-devel mailing list
Ocfs2-devel@oss.oracle.com
https://oss.oracle.com/mailman/listinfo/ocfs2-devel


[Ocfs2-devel] [PATCH 2/2] ocfs2: add necessary check in case sb_getblk fails

2014-03-28 Thread Rui Xiang
Sb_getblk may retrun an err, so add a check for bh.

Signed-off-by: Rui Xiang rui.xi...@huawei.com
---
 fs/ocfs2/refcounttree.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/fs/ocfs2/refcounttree.c b/fs/ocfs2/refcounttree.c
index 50c1796..22f3f19 100644
--- a/fs/ocfs2/refcounttree.c
+++ b/fs/ocfs2/refcounttree.c
@@ -612,6 +612,11 @@ static int ocfs2_create_refcount_tree(struct inode *inode,
}
 
new_bh = sb_getblk(inode-i_sb, first_blkno);
+   if (!new_bh) {
+   ret = -ENOMEM;
+   mlog_errno(ret);
+   goto out_commit;
+   }
ocfs2_set_new_buffer_uptodate(new_tree-rf_ci, new_bh);
 
ret = ocfs2_journal_access_rb(handle, new_tree-rf_ci, new_bh,
-- 
1.8.2.2



___
Ocfs2-devel mailing list
Ocfs2-devel@oss.oracle.com
https://oss.oracle.com/mailman/listinfo/ocfs2-devel


[Ocfs2-devel] [PATCH] ocfs2: check if cluster name exists before deref

2014-03-28 Thread Sasha Levin
Commit c74a3bdd9b ocfs2: add clustername to cluster connection
is trying to strlcpy a string which was explicitly passed as NULL
in the very same patch, triggering a NULL ptr deref.

[  640.225193] BUG: unable to handle kernel NULL pointer dereference at 
  (null)
[  640.230224] IP: strlcpy (lib/string.c:388 lib/string.c:151)
[  640.230224] PGD 82a93a067 PUD 82a93b067 PMD 0 
[  640.230224] Oops:  [#1] PREEMPT SMP DEBUG_PAGEALLOC
[  640.230224] Dumping ftrace buffer:
[  640.230224](ftrace buffer empty)
[  640.230224] Modules linked in:
[  640.230224] CPU: 19 PID: 19426 Comm: trinity-c19 Tainted: GW 
3.14.0-rc7-next-20140325-sasha-00014-g9476368-dirty #274
[  640.230224] task: 88082bc53000 ti: 88082b674000 task.ti: 
88082b674000
[  640.230224] RIP:  strlcpy (lib/string.c:388 lib/string.c:151)
[  640.230224] RSP: 0018:88082b675d88  EFLAGS: 00010296
[  640.230224] RAX: 0007 RBX: 8853b260 RCX: 6f6d7366
[  640.230224] RDX: 0011 RSI:  RDI: 
88052bcd3518  
[  640.230224] RBP: 88082b675da8 R08: 746e756f R09: 
  
[  640.230224] R10: 88052bcd34d0 R11:  R12: 
88052bcd3518  
[  640.230224] R13: 88052c003fb8 R14: 88052bcd34d0 R15: ffea
[  640.230224] FS:  7f04ae7a6700() GS:88052cc0() 
knlGS:
[  640.230224] CS:  0010 DS:  ES:  CR0: 8005003b
[  640.230224] CR2:  CR3: 00082115b000 CR4: 06a0
[  640.230224] DR0: 00698000 DR1: 00698000 DR2: 
[  640.230224] DR3:  DR6: 0ff0 DR7: 0602
[  640.230224] Stack:
[  640.230224]  86b3c260 8853b260 86b3c260 
88052c003fb8
[  640.230224]  88082b675df8 818a3a5d  
0007
[  640.230224]  0282 88052c003f48 88003e6b01a0 
88052c0f81a0
[  640.230224] Call Trace:
[  640.230224]  ocfs2_cluster_connect (fs/ocfs2/stackglue.c:350)
[  640.230224]  ocfs2_cluster_connect_agnostic (fs/ocfs2/stackglue.c:396)
[  640.230224]  ? ocfs2_control_open (fs/ocfs2/dlmfs/userdlm.c:660)
[  640.230224]  user_dlm_register (fs/ocfs2/dlmfs/userdlm.c:679)
[  640.230224]  ? dlmfs_get_inode (fs/ocfs2/dlmfs/dlmfs.c:468)
[  640.230224]  dlmfs_mkdir (fs/ocfs2/dlmfs/dlmfs.c:503)
[  640.230224]  ? security_inode_permission (security/security.c:555)
[  640.230224]  ? __inode_permission (fs/namei.c:414)
[  640.230224]  vfs_mkdir (fs/namei.c:3467)
[  640.230224]  SyS_mkdirat (fs/namei.c:3488 fs/namei.c:3472)
[  640.230224]  tracesys (arch/x86/kernel/entry_64.S:749)  
[  640.230224] Code: 41 c6 44 1d 00 00 48 83 c4 08 5b 4c 89 e0 41 5c 41 5d 5d 
c3 0f 1f 80 00 00 00 00 55 48 89 e5 41 55 41 54 49 89 fc 53 48 83 ec 08 80 3e 
00 74 1c 48 89 f0 0f 1f 84 00 00 00 00 00 48 83 c0 01 80 
[  640.230224] RIP  strlcpy (lib/string.c:388 lib/string.c:151)
[  640.230224]  RSP 88082b675d88
[  640.230224] CR2: 

Signed-off-by: Sasha Levin sasha.le...@oracle.com
---

As a side note, how the hell was this new code path tested?
It's obviously broken and there's no way it even passes
a very basic test.

 fs/ocfs2/stackglue.c |4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/fs/ocfs2/stackglue.c b/fs/ocfs2/stackglue.c
index 5e4d314..83f1a66 100644
--- a/fs/ocfs2/stackglue.c
+++ b/fs/ocfs2/stackglue.c
@@ -346,7 +346,9 @@ int ocfs2_cluster_connect(const char *stack_name,
 
strlcpy(new_conn-cc_name, group, GROUP_NAME_MAX + 1);
new_conn-cc_namelen = grouplen;
-   strlcpy(new_conn-cc_cluster_name, cluster_name, CLUSTER_NAME_MAX + 1);
+   if (cluster_name_len)
+   strlcpy(new_conn-cc_cluster_name, cluster_name,
+   CLUSTER_NAME_MAX + 1);
new_conn-cc_cluster_name_len = cluster_name_len;
new_conn-cc_recovery_handler = recovery_handler;
new_conn-cc_recovery_data = recovery_data;
-- 
1.7.10.4


___
Ocfs2-devel mailing list
Ocfs2-devel@oss.oracle.com
https://oss.oracle.com/mailman/listinfo/ocfs2-devel


[Ocfs2-devel] [PATCH 00/24] treewide: Convert use of typedef ctl_table to struct ctl_table

2014-03-28 Thread Joe Perches
Joe Perches (24):
  arm: Convert use of typedef ctl_table to struct ctl_table
  ia64: Convert use of typedef ctl_table to struct ctl_table
  s390: Convert use of typedef ctl_table to struct ctl_table
  tile: Convert use of typedef ctl_table to struct ctl_table
  cdrom: Convert use of typedef ctl_table to struct ctl_table
  random: Convert use of typedef ctl_table to struct ctl_table
  infiniband: Convert use of typedef ctl_table to struct ctl_table
  md: Convert use of typedef ctl_table to struct ctl_table
  parport: Convert use of typedef ctl_table to struct ctl_table
  scsi: Convert use of typedef ctl_table to struct ctl_table
  coda: Convert use of typedef ctl_table to struct ctl_table
  fscache: Convert use of typedef ctl_table to struct ctl_table
  lockd: Convert use of typedef ctl_table to struct ctl_table
  nfs: Convert use of typedef ctl_table to struct ctl_table
  inotify: Convert use of typedef ctl_table to struct ctl_table
  ntfs: Convert use of typedef ctl_table to struct ctl_table
  ocfs2: Convert use of typedef ctl_table to struct ctl_table
  proc: Convert use of typedef ctl_table to struct ctl_table
  fs: Convert use of typedef ctl_table to struct ctl_table
  key: Convert use of typedef ctl_table to struct ctl_table
  ipc: Convert use of typedef ctl_table to struct ctl_table
  kernel: Convert use of typedef ctl_table to struct ctl_table
  mm: Convert use of typedef ctl_table to struct ctl_table
  security:keys: Convert use of typedef ctl_table to struct ctl_table

 arch/arm/kernel/isa.c  |  6 ++---
 arch/ia64/kernel/crash.c   |  4 +--
 arch/ia64/kernel/perfmon.c |  6 ++---
 arch/s390/appldata/appldata_base.c | 10 
 arch/s390/kernel/debug.c   |  2 +-
 arch/s390/mm/cmm.c |  8 +++---
 arch/tile/kernel/proc.c|  4 +--
 drivers/cdrom/cdrom.c  | 10 
 drivers/char/random.c  |  4 +--
 drivers/infiniband/core/ucma.c |  2 +-
 drivers/md/md.c|  6 ++---
 drivers/parport/procfs.c   | 52 ++
 drivers/scsi/scsi_sysctl.c |  6 ++---
 fs/coda/sysctl.c   |  4 +--
 fs/dcache.c|  2 +-
 fs/drop_caches.c   |  2 +-
 fs/eventpoll.c |  2 +-
 fs/file_table.c|  4 +--
 fs/fscache/main.c  |  4 +--
 fs/inode.c |  2 +-
 fs/lockd/svc.c |  6 ++---
 fs/nfs/nfs4sysctl.c|  6 ++---
 fs/nfs/sysctl.c|  6 ++---
 fs/notify/inotify/inotify_user.c   |  2 +-
 fs/ntfs/sysctl.c   |  4 +--
 fs/ocfs2/stackglue.c   |  8 +++---
 fs/proc/proc_sysctl.c  |  2 +-
 include/linux/key.h|  2 +-
 ipc/ipc_sysctl.c   | 14 +-
 ipc/mq_sysctl.c| 10 
 kernel/sysctl.c|  2 +-
 kernel/utsname_sysctl.c|  6 ++---
 mm/page-writeback.c|  2 +-
 mm/page_alloc.c| 12 -
 security/keys/sysctl.c |  2 +-
 35 files changed, 111 insertions(+), 113 deletions(-)

-- 
1.8.1.2.459.gbcd45b4.dirty


___
Ocfs2-devel mailing list
Ocfs2-devel@oss.oracle.com
https://oss.oracle.com/mailman/listinfo/ocfs2-devel


[Ocfs2-devel] [PATCH 1/2] ocfs2: return ENOMEM while sb_getblk failing

2014-03-28 Thread Rui Xiang
The only reason for sb_getblk() failing is if it can't allocate
the buffer_head. So return ENOMEM instead when it fails.

Signed-off-by: Rui Xiang rui.xi...@huawei.com
---
 fs/ocfs2/alloc.c| 2 +-
 fs/ocfs2/aops.c | 1 +
 fs/ocfs2/dir.c  | 8 
 fs/ocfs2/namei.c| 2 +-
 fs/ocfs2/refcounttree.c | 6 +++---
 fs/ocfs2/suballoc.c | 4 ++--
 fs/ocfs2/super.c| 4 ++--
 fs/ocfs2/xattr.c| 2 +-
 8 files changed, 15 insertions(+), 14 deletions(-)

diff --git a/fs/ocfs2/alloc.c b/fs/ocfs2/alloc.c
index 17e6bdd..dc7411f 100644
--- a/fs/ocfs2/alloc.c
+++ b/fs/ocfs2/alloc.c
@@ -1025,7 +1025,7 @@ static int ocfs2_create_new_meta_bhs(handle_t *handle,
for(i = count;  i  (num_got + count); i++) {
bhs[i] = sb_getblk(osb-sb, first_blkno);
if (bhs[i] == NULL) {
-   status = -EIO;
+   status = -ENOMEM;
mlog_errno(status);
goto bail;
}
diff --git a/fs/ocfs2/aops.c b/fs/ocfs2/aops.c
index 2abf97b..ffcddfd 100644
--- a/fs/ocfs2/aops.c
+++ b/fs/ocfs2/aops.c
@@ -80,6 +80,7 @@ static int ocfs2_symlink_get_block(struct inode *inode, 
sector_t iblock,
 
if ((u64)iblock = ocfs2_clusters_to_blocks(inode-i_sb,

le32_to_cpu(fe-i_clusters))) {
+   err = -ENOMEM;
mlog(ML_ERROR, block offset is outside the allocated size: 
 %llu\n, (unsigned long long)iblock);
goto bail;
diff --git a/fs/ocfs2/dir.c b/fs/ocfs2/dir.c
index 30544ce..5354743 100644
--- a/fs/ocfs2/dir.c
+++ b/fs/ocfs2/dir.c
@@ -2349,7 +2349,7 @@ static int ocfs2_dx_dir_attach_index(struct ocfs2_super 
*osb,
 
dx_root_bh = sb_getblk(osb-sb, dr_blkno);
if (dx_root_bh == NULL) {
-   ret = -EIO;
+   ret = -ENOMEM;
goto out;
}
ocfs2_set_new_buffer_uptodate(INODE_CACHE(dir), dx_root_bh);
@@ -2422,7 +2422,7 @@ static int ocfs2_dx_dir_format_cluster(struct ocfs2_super 
*osb,
for (i = 0; i  num_dx_leaves; i++) {
bh = sb_getblk(osb-sb, start_blk + i);
if (bh == NULL) {
-   ret = -EIO;
+   ret = -ENOMEM;
goto out;
}
dx_leaves[i] = bh;
@@ -2929,7 +2929,7 @@ static int ocfs2_expand_inline_dir(struct inode *dir, 
struct buffer_head *di_bh,
blkno = ocfs2_clusters_to_blocks(dir-i_sb, bit_off);
dirdata_bh = sb_getblk(sb, blkno);
if (!dirdata_bh) {
-   ret = -EIO;
+   ret = -ENOMEM;
mlog_errno(ret);
goto out_commit;
}
@@ -3159,7 +3159,7 @@ static int ocfs2_do_extend_dir(struct super_block *sb,
 
*new_bh = sb_getblk(sb, p_blkno);
if (!*new_bh) {
-   status = -EIO;
+   status = -ENOMEM;
mlog_errno(status);
goto bail;
}
diff --git a/fs/ocfs2/namei.c b/fs/ocfs2/namei.c
index be3f867..4f791f6 100644
--- a/fs/ocfs2/namei.c
+++ b/fs/ocfs2/namei.c
@@ -489,7 +489,7 @@ static int __ocfs2_mknod_locked(struct inode *dir,
 
*new_fe_bh = sb_getblk(osb-sb, fe_blkno);
if (!*new_fe_bh) {
-   status = -EIO;
+   status = -ENOMEM;
mlog_errno(status);
goto leave;
}
diff --git a/fs/ocfs2/refcounttree.c b/fs/ocfs2/refcounttree.c
index a70d604..50c1796 100644
--- a/fs/ocfs2/refcounttree.c
+++ b/fs/ocfs2/refcounttree.c
@@ -1310,7 +1310,7 @@ static int ocfs2_expand_inline_ref_root(handle_t *handle,
 
new_bh = sb_getblk(sb, blkno);
if (new_bh == NULL) {
-   ret = -EIO;
+   ret = -ENOMEM;
mlog_errno(ret);
goto out;
}
@@ -1561,7 +1561,7 @@ static int ocfs2_new_leaf_refcount_block(handle_t *handle,
 
new_bh = sb_getblk(sb, blkno);
if (new_bh == NULL) {
-   ret = -EIO;
+   ret = -ENOMEM;
mlog_errno(ret);
goto out;
}
@@ -3031,7 +3031,7 @@ int ocfs2_duplicate_clusters_by_jbd(handle_t *handle,
for (i = 0; i  blocks; i++, old_block++, new_block++) {
new_bh = sb_getblk(osb-sb, new_block);
if (new_bh == NULL) {
-   ret = -EIO;
+   ret = -ENOMEM;
mlog_errno(ret);
break;
}
diff --git a/fs/ocfs2/suballoc.c b/fs/ocfs2/suballoc.c
index 5397c07..2c91452 100644
--- a/fs/ocfs2/suballoc.c
+++ b/fs/ocfs2/suballoc.c
@@ -481,7 +481,7 @@ ocfs2_block_group_alloc_contig(struct ocfs2_super *osb, 
handle_t *handle,
 
bg_bh = sb_getblk(osb-sb, bg_blkno);
if (!bg_bh) {
-   status = -EIO;
+  

[Ocfs2-devel] [PATCH 09/17] fs/hearbeat: Replace hardcoding of -20 with MIN_NICE.

2014-03-28 Thread Dongsheng Yang
Signed-off-by: Dongsheng Yang yangds.f...@cn.fujitsu.com
cc: ocfs2-devel@oss.oracle.com
cc: Dong Fang yp.fangd...@gmail.com
---
 fs/ocfs2/cluster/heartbeat.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs/ocfs2/cluster/heartbeat.c b/fs/ocfs2/cluster/heartbeat.c
index bf482df..7303929 100644
--- a/fs/ocfs2/cluster/heartbeat.c
+++ b/fs/ocfs2/cluster/heartbeat.c
@@ -1107,7 +1107,7 @@ static int o2hb_thread(void *data)
 
mlog(ML_HEARTBEAT|ML_KTHREAD, hb thread running\n);
 
-   set_user_nice(current, -20);
+   set_user_nice(current, MIN_NICE);
 
/* Pin node */
o2nm_depend_this_node();
-- 
1.8.2.1


___
Ocfs2-devel mailing list
Ocfs2-devel@oss.oracle.com
https://oss.oracle.com/mailman/listinfo/ocfs2-devel


Re: [Ocfs2-devel] [PATCH 0/6] nocontrold: Eliminating ocfs2_controld

2014-03-28 Thread Lars Marowsky-Bree
On 2013-09-05T22:26:56, Goldwyn Rodrigues rgold...@suse.de wrote:

Hi Goldwyn,

thanks! This looks really good.

 This is an effort of removing ocfs2_controld.pcmk and getting ocfs2 DLM
 handling up to the times with respect to DLM (=4.0.1) and corosync
 (2.3.x). AFAIK, cman also is being phased out for a unified corosync
 cluster stack.

That's clearly necessary, also to bring OCFS2 more uptodate with the
latest happenings in the GFS2 world; it'll allow both file systems to
share exactly the same cluster stack.

 https://github.com/goldwynr/ocfs2-tools branch: nocontrold
 Currently, not many checks are present in the userspace code,
 but that would change soon.

There's one question I have; how will this handle

- the old user-space code starting on a new kernel,
- or the new user-space code being run on an old kernel?

Is there anything we can do to at least provide a meaningful error
message in the first case? The second should be easier to handle.


Regards,
Lars

-- 
Architect Storage/HA
SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 
21284 (AG Nürnberg)
Experience is the name everyone gives to their mistakes. -- Oscar Wilde


___
Ocfs2-devel mailing list
Ocfs2-devel@oss.oracle.com
https://oss.oracle.com/mailman/listinfo/ocfs2-devel


[Ocfs2-devel] [PATCH 14/21] fs: Mark functions as static in ocfs2/journal.c

2014-03-28 Thread Rashika Kheria
Mark functions as static in ocfs2/journal.c because they are not used
outside this file.

This eliminates the following warning in ocfs2/journal.c:
fs/ocfs2/journal.c:106:6: warning: no previous prototype for 
‘ocfs2_replay_map_set_state’ [-Wmissing-prototypes]
fs/ocfs2/journal.c:151:6: warning: no previous prototype for 
‘ocfs2_queue_replay_slots’ [-Wmissing-prototypes]
fs/ocfs2/journal.c:169:6: warning: no previous prototype for 
‘ocfs2_free_replay_slots’ [-Wmissing-prototypes]
fs/ocfs2/journal.c:1872:6: warning: no previous prototype for 
‘ocfs2_queue_orphan_scan’ [-Wmissing-prototypes]
fs/ocfs2/journal.c:1921:6: warning: no previous prototype 
for‘ocfs2_orphan_scan_work’ [-Wmissing-prototypes]

Signed-off-by: Rashika Kheria rashika.khe...@gmail.com
Reviewed-by: Josh Triplett j...@joshtriplett.org
---
 fs/ocfs2/journal.c |   10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/fs/ocfs2/journal.c b/fs/ocfs2/journal.c
index 44fc3e5..3aa941a 100644
--- a/fs/ocfs2/journal.c
+++ b/fs/ocfs2/journal.c
@@ -103,7 +103,7 @@ struct ocfs2_replay_map {
unsigned char rm_replay_slots[0];
 };
 
-void ocfs2_replay_map_set_state(struct ocfs2_super *osb, int state)
+static void ocfs2_replay_map_set_state(struct ocfs2_super *osb, int state)
 {
if (!osb-replay_map)
return;
@@ -148,7 +148,7 @@ int ocfs2_compute_replay_slots(struct ocfs2_super *osb)
return 0;
 }
 
-void ocfs2_queue_replay_slots(struct ocfs2_super *osb)
+static void ocfs2_queue_replay_slots(struct ocfs2_super *osb)
 {
struct ocfs2_replay_map *replay_map = osb-replay_map;
int i;
@@ -166,7 +166,7 @@ void ocfs2_queue_replay_slots(struct ocfs2_super *osb)
replay_map-rm_state = REPLAY_DONE;
 }
 
-void ocfs2_free_replay_slots(struct ocfs2_super *osb)
+static void ocfs2_free_replay_slots(struct ocfs2_super *osb)
 {
struct ocfs2_replay_map *replay_map = osb-replay_map;
 
@@ -1869,7 +1869,7 @@ static inline unsigned long 
ocfs2_orphan_scan_timeout(void)
  * hasn't happened.  The node queues a scan and increments the
  * sequence number in the LVB.
  */
-void ocfs2_queue_orphan_scan(struct ocfs2_super *osb)
+static void ocfs2_queue_orphan_scan(struct ocfs2_super *osb)
 {
struct ocfs2_orphan_scan *os;
int status, i;
@@ -1918,7 +1918,7 @@ out:
 }
 
 /* Worker task that gets fired every ORPHAN_SCAN_SCHEDULE_TIMEOUT millsec */
-void ocfs2_orphan_scan_work(struct work_struct *work)
+static void ocfs2_orphan_scan_work(struct work_struct *work)
 {
struct ocfs2_orphan_scan *os;
struct ocfs2_super *osb;
-- 
1.7.9.5


___
Ocfs2-devel mailing list
Ocfs2-devel@oss.oracle.com
https://oss.oracle.com/mailman/listinfo/ocfs2-devel

[Ocfs2-devel] [PATCH 15/21] fs: Mark function as static in ocfs2/xattr.c

2014-03-28 Thread Rashika Kheria
Mark functions as static in ocfs2/xattr.c because it is not used outside
this file.

This eliminates the following warning in ocfs2/xattr.c:
fs/ocfs2/xattr.c:7256:5: warning: no previous prototype for ‘ocfs2_initxattrs’ 
[-Wmissing-prototypes]

Signed-off-by: Rashika Kheria rashika.khe...@gmail.com
Reviewed-by: Josh Triplett j...@joshtriplett.org
---
 fs/ocfs2/xattr.c |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/fs/ocfs2/xattr.c b/fs/ocfs2/xattr.c
index 185fa3b7..7041df5 100644
--- a/fs/ocfs2/xattr.c
+++ b/fs/ocfs2/xattr.c
@@ -7256,8 +7256,8 @@ static int ocfs2_xattr_security_set(struct dentry 
*dentry, const char *name,
   name, value, size, flags);
 }
 
-int ocfs2_initxattrs(struct inode *inode, const struct xattr *xattr_array,
-void *fs_info)
+static int ocfs2_initxattrs(struct inode *inode, const struct xattr 
*xattr_array,
+   void *fs_info)
 {
const struct xattr *xattr;
int err = 0;
-- 
1.7.9.5


___
Ocfs2-devel mailing list
Ocfs2-devel@oss.oracle.com
https://oss.oracle.com/mailman/listinfo/ocfs2-devel

[Ocfs2-devel] [PATCH 13/21] fs: Mark functions as static in ocfs2/ioctl.c

2014-03-28 Thread Rashika Kheria
Mark functions as static in ocfs/ioctl.c because they are not used
outside this file.

This eliminates the following warning in ocfs/ioctl.c:
fs/ocfs2/ioctl.c:145:5: warning: no previous prototype for 
‘ocfs2_info_handle_blocksize’ [-Wmissing-prototypes]
fs/ocfs2/ioctl.c:169:5: warning: no previous prototype for 
‘ocfs2_info_handle_clustersize’ [-Wmissing-prototypes]
fs/ocfs2/ioctl.c:194:5: warning: no previous prototype for 
‘ocfs2_info_handle_maxslots’ [-Wmissing-prototypes]
fs/ocfs2/ioctl.c:219:5: warning: no previous prototype for 
‘ocfs2_info_handle_label’ [-Wmissing-prototypes]
fs/ocfs2/ioctl.c:244:5: warning: no previous prototype for 
‘ocfs2_info_handle_uuid’ [-Wmissing-prototypes]
fs/ocfs2/ioctl.c:269:5: warning: no previous prototype for 
‘ocfs2_info_handle_fs_features’ [-Wmissing-prototypes]
fs/ocfs2/ioctl.c:296:5: warning: no previous prototype for 
‘ocfs2_info_handle_journal_size’ [-Wmissing-prototypes]
fs/ocfs2/ioctl.c:321:5: warning: no previous prototype for 
‘ocfs2_info_scan_inode_alloc’ [-Wmissing-prototypes]
fs/ocfs2/ioctl.c:368:5: warning: no previous prototype for 
‘ocfs2_info_handle_freeinode’ [-Wmissing-prototypes]
fs/ocfs2/ioctl.c:463:6: warning: no previous prototype for 
‘ocfs2_info_update_ffg’ [-Wmissing-prototypes]
fs/ocfs2/ioctl.c:470:5: warning: no previous prototype for 
‘ocfs2_info_freefrag_scan_chain’ [-Wmissing-prototypes]
fs/ocfs2/ioctl.c:573:5: warning: no previous prototype for 
‘ocfs2_info_freefrag_scan_bitmap’ [-Wmissing-prototypes]
fs/ocfs2/ioctl.c:653:5: warning: no previous prototype for 
‘ocfs2_info_handle_freefrag’ [-Wmissing-prototypes]
fs/ocfs2/ioctl.c:724:5: warning: no previous prototype for 
‘ocfs2_info_handle_unknown’ [-Wmissing-prototypes]
fs/ocfs2/ioctl.c:753:5: warning: no previous prototype for 
‘ocfs2_info_handle_request’ [-Wmissing-prototypes]
fs/ocfs2/ioctl.c:812:5: warning: no previous prototype for 
‘ocfs2_get_request_ptr’ [-Wmissing-prototypes]
fs/ocfs2/ioctl.c:850:5: warning: no previous prototype for ‘ocfs2_info_handle’ 
[-Wmissing-prototypes]

Signed-off-by: Rashika Kheria rashika.khe...@gmail.com
Reviewed-by: Josh Triplett j...@joshtriplett.org
---
 fs/ocfs2/ioctl.c |   80 +++---
 1 file changed, 40 insertions(+), 40 deletions(-)

diff --git a/fs/ocfs2/ioctl.c b/fs/ocfs2/ioctl.c
index 8ca3c29..055b20c 100644
--- a/fs/ocfs2/ioctl.c
+++ b/fs/ocfs2/ioctl.c
@@ -143,8 +143,8 @@ bail:
return status;
 }
 
-int ocfs2_info_handle_blocksize(struct inode *inode,
-   struct ocfs2_info_request __user *req)
+static int ocfs2_info_handle_blocksize(struct inode *inode,
+  struct ocfs2_info_request __user *req)
 {
int status = -EFAULT;
struct ocfs2_info_blocksize oib;
@@ -167,8 +167,8 @@ bail:
return status;
 }
 
-int ocfs2_info_handle_clustersize(struct inode *inode,
- struct ocfs2_info_request __user *req)
+static int ocfs2_info_handle_clustersize(struct inode *inode,
+struct ocfs2_info_request __user *req)
 {
int status = -EFAULT;
struct ocfs2_info_clustersize oic;
@@ -192,8 +192,8 @@ bail:
return status;
 }
 
-int ocfs2_info_handle_maxslots(struct inode *inode,
-  struct ocfs2_info_request __user *req)
+static int ocfs2_info_handle_maxslots(struct inode *inode,
+ struct ocfs2_info_request __user *req)
 {
int status = -EFAULT;
struct ocfs2_info_maxslots oim;
@@ -217,8 +217,8 @@ bail:
return status;
 }
 
-int ocfs2_info_handle_label(struct inode *inode,
-   struct ocfs2_info_request __user *req)
+static int ocfs2_info_handle_label(struct inode *inode,
+  struct ocfs2_info_request __user *req)
 {
int status = -EFAULT;
struct ocfs2_info_label oil;
@@ -242,8 +242,8 @@ bail:
return status;
 }
 
-int ocfs2_info_handle_uuid(struct inode *inode,
-  struct ocfs2_info_request __user *req)
+static int ocfs2_info_handle_uuid(struct inode *inode,
+ struct ocfs2_info_request __user *req)
 {
int status = -EFAULT;
struct ocfs2_info_uuid oiu;
@@ -267,8 +267,8 @@ bail:
return status;
 }
 
-int ocfs2_info_handle_fs_features(struct inode *inode,
- struct ocfs2_info_request __user *req)
+static int ocfs2_info_handle_fs_features(struct inode *inode,
+struct ocfs2_info_request __user *req)
 {
int status = -EFAULT;
struct ocfs2_info_fs_features oif;
@@ -294,8 +294,8 @@ bail:
return status;
 }
 
-int ocfs2_info_handle_journal_size(struct inode *inode,
-  struct ocfs2_info_request __user *req)
+static int ocfs2_info_handle_journal_size(struct inode *inode,
+ 

[Ocfs2-devel] [PATCH 3.5 64/96] jbd2: don't BUG but return ENOSPC if a handle runs out of space

2014-03-28 Thread Luis Henriques
3.5.7.29 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: Theodore Ts'o ty...@mit.edu

commit f6c07cad081ba222d63623d913aafba5586c1d2c upstream.

If a handle runs out of space, we currently stop the kernel with a BUG
in jbd2_journal_dirty_metadata().  This makes it hard to figure out
what might be going on.  So return an error of ENOSPC, so we can let
the file system layer figure out what is going on, to make it more
likely we can get useful debugging information).  This should make it
easier to debug problems such as the one which was reported by:

https://bugzilla.kernel.org/show_bug.cgi?id=44731

The only two callers of this function are ext4_handle_dirty_metadata()
and ocfs2_journal_dirty().  The ocfs2 function will trigger a
BUG_ON(), which means there will be no change in behavior.  The ext4
function will call ext4_error_inode() which will print the useful
debugging information and then handle the situation using ext4's error
handling mechanisms (i.e., which might mean halting the kernel or
remounting the file system read-only).

Also, since both file systems already call WARN_ON(), drop the WARN_ON
from jbd2_journal_dirty_metadata() to avoid two stack traces from
being displayed.

Signed-off-by: Theodore Ts'o ty...@mit.edu
Cc: ocfs2-devel@oss.oracle.com
Acked-by: Joel Becker jl...@evilplan.org
Signed-off-by: Luis Henriques luis.henriq...@canonical.com
---
 fs/jbd2/transaction.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/fs/jbd2/transaction.c b/fs/jbd2/transaction.c
index 81203d1..edfb1ec 100644
--- a/fs/jbd2/transaction.c
+++ b/fs/jbd2/transaction.c
@@ -1126,7 +1126,10 @@ int jbd2_journal_dirty_metadata(handle_t *handle, struct 
buffer_head *bh)
 * once a transaction -bzzz
 */
jh-b_modified = 1;
-   J_ASSERT_JH(jh, handle-h_buffer_credits  0);
+   if (handle-h_buffer_credits = 0) {
+   ret = -ENOSPC;
+   goto out_unlock_bh;
+   }
handle-h_buffer_credits--;
}
 
@@ -1209,7 +1212,6 @@ out_unlock_bh:
jbd2_journal_put_journal_head(jh);
 out:
JBUFFER_TRACE(jh, exit);
-   WARN_ON(ret);   /* All errors are bugs, so dump the stack */
return ret;
 }
 
-- 
1.8.3.2


___
Ocfs2-devel mailing list
Ocfs2-devel@oss.oracle.com
https://oss.oracle.com/mailman/listinfo/ocfs2-devel


Re: [Ocfs2-devel] [Cluster-devel] [PATCH] fs: push sync_filesystem() down to the file system's remount_fs()

2014-03-28 Thread Jan Kara
On Thu 13-03-14 19:15:06, Ted Tso wrote:
 On Thu, Mar 13, 2014 at 04:28:23PM +, Steven Whitehouse wrote:
  
  I guess the same is true for other file systems which are mounted ro
  too. So maybe a check for MS_RDONLY before doing the sync in those
  cases?
 
 My original patch moved the sync_filesystem into the check for
 MS_RDONLY in the core VFS code.  The objection was raised that there
 might be some file system out there that might depend on this
 behaviour.  I can't imagine why, but I suppose it's at least
 theoretically possible.
  Well, syncfs() in RO-RW transition clearly isn't needed. In RW-RO
transition basically everybody needs it. What is disputable is the case of
RW-RW remounts and I could imagine someone relying on syncfs() there
although 99% of filesystems don't need it. So I agree in principle with
moving the responsibility for syncfs() to -remount so that each filesystem
can decide.

 So the idea is that this particular patch is *guaranteed* not to make
 any difference.  That way there can be no question about the patch'es
 correctness.
 
 I'm going to follow up with a patch for ext4 that does exactly that,
 but the idea is to allow each file system maintainer to do that for
 their own file system.
 
 I could do that as well for file systems that are obviously
 read-only, but then I'll find out that there's some wierd case where
 the file system can be used in a read-write fashion.  (Example: UDF is
 normally used for DVD's, but at least in theory it can be used
 read/write --- I'm told that Windows supports read-write UDF file
 systems on USB sticks, and at least in theory it could be used as a
 inter-OS exchange format in situations where VFAT and exFAT might not
 be appropriate for various reasons.)
  Yes, some people do use UDF for USB sticks - Linux supports it in
read-write mode as well (although with somewhat limited set of features).
But the filesystem's I've named are those which clearly either bail with
error if RW mount is attempted or silently change it to RO mount. In these
cases, I'd just patch away the unnecessary sync_fs().

Honza
-- 
Jan Kara j...@suse.cz
SUSE Labs, CR

___
Ocfs2-devel mailing list
Ocfs2-devel@oss.oracle.com
https://oss.oracle.com/mailman/listinfo/ocfs2-devel


[Ocfs2-devel] [PATCH 0/4 v3] fiemap: introduce EXTENT_DATA_COMPRESSED flag

2014-03-28 Thread David Sterba
The original FIEMAP patch did not define this bit, btrfs will make use of
it.  The defined constant maintains the same value as originally proposed.

Currently, the 'filefrag' utility has no way to recognize and denote a
compressed extent. As implemented in btrfs right now, the compression step
splits a big extent into smaller chunks and this is reported as a heavily
fragmented file. Adding the flag to filefrag will at least give some
explanation why, this has been confusing users for some time already.

V3:
Based on feedback from Andreas, implement #1 from V2, current users of
fiemap_fill_next_extent (fs/, ext4, gfs2, ocfs2, nilfs2, xfs) updated
accordingly, no functional change.

V2:
Based on feedback from Andreas, the fiemap_extent is now able to hold the
physical extent length, to be filled by the filesystem callback.

The filesystems do not have access to the structure that is passed back to
userspace and are supposed to call fiemap_fill_next_extent, there's no direct
way to fill fe_phys_length. There are two ways to pass it:

1) extend fiemap_fill_next_extent to take phys_length and update all
   users (ext4, gfs2, ocfs2, nilfs2, xfs)

2) add new function that takes arguments for all the fiemap_extent items,
   newly added phys_length compared to fiemap_fill_next_extent

David Sterba (4):
  fiemap: fix comment at EXTENT_DATA_ENCRYPTED
  fiemap: add EXTENT_DATA_COMPRESSED flag
  btrfs: set FIEMAP_EXTENT_DATA_COMPRESSED for compressed extents
  Documentation/fiemap: Document the DATA_COMPRESSED flag

 Documentation/filesystems/fiemap.txt |   17 +
 fs/btrfs/extent_io.c |9 +++--
 fs/ext4/extents.c|3 ++-
 fs/ext4/inline.c |2 +-
 fs/gfs2/inode.c  |2 +-
 fs/ioctl.c   |   18 --
 fs/nilfs2/inode.c|8 +---
 fs/ocfs2/extent_map.c|4 ++--
 fs/xfs/xfs_iops.c|2 +-
 include/linux/fs.h   |2 +-
 include/uapi/linux/fiemap.h  |8 ++--
 11 files changed, 51 insertions(+), 24 deletions(-)

-- 
1.7.9


___
Ocfs2-devel mailing list
Ocfs2-devel@oss.oracle.com
https://oss.oracle.com/mailman/listinfo/ocfs2-devel


[Ocfs2-devel] [PATCH 16/21] fs: Mark function as static in ocfs2/cluster/heartbeat.c

2014-03-28 Thread Rashika Kheria
Mark function as static in ocfs2/cluster/heartbeat.c because it is
not used outside this file.

This eliminates the following warning in ocfs2/cluster/heartbeat.c:
fs/ocfs2/cluster/heartbeat.c:2470:6: warning: no previous prototype for 
‘o2hb_region_dec_user’ [-Wmissing-prototypes]

Signed-off-by: Rashika Kheria rashika.khe...@gmail.com
Reviewed-by: Josh Triplett j...@joshtriplett.org
---
 fs/ocfs2/cluster/heartbeat.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs/ocfs2/cluster/heartbeat.c b/fs/ocfs2/cluster/heartbeat.c
index bf482df..ca10dec 100644
--- a/fs/ocfs2/cluster/heartbeat.c
+++ b/fs/ocfs2/cluster/heartbeat.c
@@ -2467,7 +2467,7 @@ unlock:
return ret;
 }
 
-void o2hb_region_dec_user(const char *region_uuid)
+static void o2hb_region_dec_user(const char *region_uuid)
 {
spin_lock(o2hb_live_lock);
 
-- 
1.7.9.5


___
Ocfs2-devel mailing list
Ocfs2-devel@oss.oracle.com
https://oss.oracle.com/mailman/listinfo/ocfs2-devel

Re: [Ocfs2-devel] [PATCH 2/4 v3] fiemap: add EXTENT_DATA_COMPRESSED flag

2014-03-28 Thread Dave Chinner
On Thu, Dec 12, 2013 at 05:02:57PM -0700, Andreas Dilger wrote:
 On Dec 12, 2013, at 4:24 PM, Dave Chinner da...@fromorbit.com wrote:
  On Thu, Dec 12, 2013 at 04:25:59PM +0100, David Sterba wrote:
  This flag was not accepted when fiemap was proposed [2] due to lack of
  in-kernel users. Btrfs has compression for a long time and we'd like to
  see that an extent is compressed in the output of 'filefrag' utility
  once it's taught about it.
  
  For that purpose, a reserved field from fiemap_extent is used to let the
  filesystem store along the physcial extent length when the flag is set.
  This keeps compatibility with applications that use FIEMAP.
  
  I'd prefer to just see the new physical length field always filled
  out, regardless of whether it is a compressed extent or not. In
  terms of backwards compatibility to userspace, it makes no
  difference because the value of reserved/unused fields is undefined
  by the API. Yes, the implementation zeros them, but there's nothing
  in the documentation that says reserved fields must be zero.
  Hence I think we should just set it for every extent.
 
 I'd actually thought the same thing while reading the patch, but I figured
 people would object because it implies that old kernels will return a
 physical length of 0 bytes (which might be valid) and badly-written tools
 will not work correctly on older kernels. 

Well, that's a problem regardless of whether new kernels return a
physical length by default or not. I think I'd prefer a flag that
says specifically whether the fe_phys_len field is valid or not. Old
kernels will never set the flag, new kernels can always set the
flag...

 That said, applications _should_
 be checking the FIEMAP_EXTENT_DATA_COMPRESSED flag, and I suspect in the
 future fewer developers will be confused if fe_phys_length == fe_length
 going forward.

I think an explicit flag is better than relying on a flag that
defines the encoding to imply the physical length field is valid.

 If the initial tools get it right (in particular filefrag),

I'd think xfs_io is the first target - because we'll need xfstests
coverage of this before there's a filefrag release that supports
it...

 then hopefully others will get it correct also.

Agreed.

  From the point of view of the kernel API (fiemap_fill_next_extent),
  passing the physical extent size in the len parameter for normal
  extents, then passing 0 for the physical length makes absolutely
  no sense.
  
  IOWs, what you have created is a distinction between the extent's
  logical length and it's physical length. For uncompressed
  extents, they are both equal and they should both be passed to
  fiemap_fill_next_extent as the same value. Extents where they are
  different (i.e.  encoded extents) is when they can be different.
  Perhaps fiemap_fill_next_extent() should check and warn about
  mismatches when they differ and the relevant flags are not set...
 
 Seems reasonable to have a WARN_ONCE() in that case.  That would catch bugs
 in the filesystem, code as well:
 
   WARN_ONCE(phys_len != lgcl_len 
 !(flags  FIEMAP_EXTENT_DATA_COMPRESSED),
 physical len %llu != logical length %llu without 
 DATA_COMPRESSED\n,
 phys_len, logical_len, phys_len, logical_len);

Yup, pretty much what I was thinking.

  --- a/include/uapi/linux/fiemap.h
  +++ b/include/uapi/linux/fiemap.h
  @@ -19,7 +19,9 @@ struct fiemap_extent {
 __u64 fe_physical; /* physical offset in bytes for the start
 * of the extent from the beginning of the disk */
 __u64 fe_length;   /* length in bytes for this extent */
  -  __u64 fe_reserved64[2];
  +  __u64 fe_phys_length; /* physical length in bytes, undefined if
  + * DATA_COMPRESSED not set */
  +  __u64 fe_reserved64;
 __u32 fe_flags;/* FIEMAP_EXTENT_* flags for this extent */
 __u32 fe_reserved[3];
  };
  
  The comment for fe_length needs to change, too, because it needs to
  indicate that it is the logical extent length and that it may be
  different to the fe_phys_length depending on the flags that are set
  on the extent.
 
 Would it make sense to rename fe_length to fe_logi_length (or something,
 I'm open to suggestions), and have a compat macro:
 
 #define fe_length fe_logi_length
 
 around for older applications?  That way, new developers would start to
 use the new name, old applications would still compile for both newer and
 older interfaces, and it doesn't affect the ABI at all.

Sounds like a good idea.

  And, FWIW, I wouldn't mention specific flags in the comment here,
  but do it at the definition of the flags that indicate there is
  a difference between physical and logical extent lengths
 
 Actually, I was thinking just the opposite for this field.  It seems useful
 that the requirement for DATA_COMPRESSED being set is beside fe_phys_length
 so that anyone using this field sees the correlation clearly.  I don't expect
 everyone 

Re: [Ocfs2-devel] [PATCH] fs: push sync_filesystem() down to the file system's remount_fs()

2014-03-28 Thread Steve French
On Thu, Mar 13, 2014 at 9:20 AM, Theodore Ts'o ty...@mit.edu wrote:
 Previously, the no-op mount -o mount /dev/xxx operation when the
 file system is already mounted read-write causes an implied,
 unconditional syncfs().  This seems pretty stupid, and it's certainly
 documented or guaraunteed to do this, nor is it particularly useful,
 except in the case where the file system was mounted rw and is getting
 remounted read-only.

Is there a case where a file system, not mounted read-only,
would want to skip the syncfs on remount?  I don't know
of any particular reason to do a syncfs on remount unless
caching behavior is changing (or moving to read-only mount),
but if as you say it is documented and guaranteed...


 However, it's possible that there might be some file systems that are
 actually depending on this behavior.  In most file systems, it's
 probably fine to only call sync_filesystem() when transitioning from
 read-write to read-only, and there are some file systems where this is
 not needed at all (for example, for a pseudo-filesystem or something
 like romfs).

 Signed-off-by: Theodore Ts'o ty...@mit.edu
 Cc: linux-fsde...@vger.kernel.org
 Cc: Christoph Hellwig h...@infradead.org
 Cc: Artem Bityutskiy dedeki...@gmail.com
 Cc: Adrian Hunter adrian.hun...@intel.com
 Cc: Evgeniy Dushistov dushis...@mail.ru
 Cc: Jan Kara j...@suse.cz
 Cc: OGAWA Hirofumi hirof...@mail.parknet.co.jp
 Cc: Anders Larsen a...@alarsen.net
 Cc: Phillip Lougher phil...@squashfs.org.uk
 Cc: Kees Cook keesc...@chromium.org
 Cc: Mikulas Patocka miku...@artax.karlin.mff.cuni.cz
 Cc: Petr Vandrovec p...@vandrovec.name
 Cc: x...@oss.sgi.com
 Cc: linux-bt...@vger.kernel.org
 Cc: linux-c...@vger.kernel.org
 Cc: samba-techni...@lists.samba.org
 Cc: codal...@coda.cs.cmu.edu
 Cc: linux-e...@vger.kernel.org
 Cc: linux-f2fs-de...@lists.sourceforge.net
 Cc: fuse-de...@lists.sourceforge.net
 Cc: cluster-de...@redhat.com
 Cc: linux-...@lists.infradead.org
 Cc: jfs-discuss...@lists.sourceforge.net
 Cc: linux-...@vger.kernel.org
 Cc: linux-ni...@vger.kernel.org
 Cc: linux-ntfs-...@lists.sourceforge.net
 Cc: ocfs2-devel@oss.oracle.com
 Cc: reiserfs-de...@vger.kernel.org
 ---
  fs/adfs/super.c  | 1 +
  fs/affs/super.c  | 1 +
  fs/befs/linuxvfs.c   | 1 +
  fs/btrfs/super.c | 1 +
  fs/cifs/cifsfs.c | 1 +
  fs/coda/inode.c  | 1 +
  fs/cramfs/inode.c| 1 +
  fs/debugfs/inode.c   | 1 +
  fs/devpts/inode.c| 1 +
  fs/efs/super.c   | 1 +
  fs/ext2/super.c  | 1 +
  fs/ext3/super.c  | 2 ++
  fs/ext4/super.c  | 2 ++
  fs/f2fs/super.c  | 2 ++
  fs/fat/inode.c   | 2 ++
  fs/freevxfs/vxfs_super.c | 1 +
  fs/fuse/inode.c  | 1 +
  fs/gfs2/super.c  | 2 ++
  fs/hfs/super.c   | 1 +
  fs/hfsplus/super.c   | 1 +
  fs/hpfs/super.c  | 2 ++
  fs/isofs/inode.c | 1 +
  fs/jffs2/super.c | 1 +
  fs/jfs/super.c   | 1 +
  fs/minix/inode.c | 1 +
  fs/ncpfs/inode.c | 1 +
  fs/nfs/super.c   | 2 ++
  fs/nilfs2/super.c| 1 +
  fs/ntfs/super.c  | 2 ++
  fs/ocfs2/super.c | 2 ++
  fs/openpromfs/inode.c| 1 +
  fs/proc/root.c   | 2 ++
  fs/pstore/inode.c| 1 +
  fs/qnx4/inode.c  | 1 +
  fs/qnx6/inode.c  | 1 +
  fs/reiserfs/super.c  | 1 +
  fs/romfs/super.c | 1 +
  fs/squashfs/super.c  | 1 +
  fs/super.c   | 2 --
  fs/sysv/inode.c  | 1 +
  fs/ubifs/super.c | 1 +
  fs/udf/super.c   | 1 +
  fs/ufs/super.c   | 1 +
  fs/xfs/xfs_super.c   | 1 +
  44 files changed, 53 insertions(+), 2 deletions(-)

 diff --git a/fs/adfs/super.c b/fs/adfs/super.c
 index 7b3003c..952aeb0 100644
 --- a/fs/adfs/super.c
 +++ b/fs/adfs/super.c
 @@ -212,6 +212,7 @@ static int parse_options(struct super_block *sb, char 
 *options)

  static int adfs_remount(struct super_block *sb, int *flags, char *data)
  {
 +   sync_filesystem(sb);
 *flags |= MS_NODIRATIME;
 return parse_options(sb, data);
  }
 diff --git a/fs/affs/super.c b/fs/affs/super.c
 index d098731..3074530 100644
 --- a/fs/affs/super.c
 +++ b/fs/affs/super.c
 @@ -530,6 +530,7 @@ affs_remount(struct super_block *sb, int *flags, char 
 *data)

 pr_debug(AFFS: remount(flags=0x%x,opts=\%s\)\n,*flags,data);

 +   sync_filesystem(sb);
 *flags |= MS_NODIRATIME;

 memcpy(volume, sbi-s_volume, 32);
 diff --git a/fs/befs/linuxvfs.c b/fs/befs/linuxvfs.c
 index 845d2d6..56d70c8 100644
 --- a/fs/befs/linuxvfs.c
 +++ b/fs/befs/linuxvfs.c
 @@ -913,6 +913,7 @@ befs_fill_super(struct super_block *sb, void *data, int 
 silent)
  static int
  befs_remount(struct super_block *sb, int *flags, char *data)
  {
 +   sync_filesystem(sb);
 if (!(*flags  MS_RDONLY))
 return -EINVAL;
 return 0;
 diff --git a/fs/btrfs/super.c b/fs/btrfs/super.c
 index 97cc241..00cd0c5 100644
 --- 

Re: [Ocfs2-devel] [PATCH 00/24] treewide: Convert use of typedef ctl_table to struct ctl_table

2014-03-28 Thread David Daney
On 10/22/2013 03:29 PM, Joe Perches wrote:
 Joe Perches (24):
arm: Convert use of typedef ctl_table to struct ctl_table
ia64: Convert use of typedef ctl_table to struct ctl_table
s390: Convert use of typedef ctl_table to struct ctl_table
tile: Convert use of typedef ctl_table to struct ctl_table
cdrom: Convert use of typedef ctl_table to struct ctl_table
random: Convert use of typedef ctl_table to struct ctl_table
infiniband: Convert use of typedef ctl_table to struct ctl_table
md: Convert use of typedef ctl_table to struct ctl_table
parport: Convert use of typedef ctl_table to struct ctl_table
scsi: Convert use of typedef ctl_table to struct ctl_table
coda: Convert use of typedef ctl_table to struct ctl_table
fscache: Convert use of typedef ctl_table to struct ctl_table
lockd: Convert use of typedef ctl_table to struct ctl_table
nfs: Convert use of typedef ctl_table to struct ctl_table
inotify: Convert use of typedef ctl_table to struct ctl_table
ntfs: Convert use of typedef ctl_table to struct ctl_table
ocfs2: Convert use of typedef ctl_table to struct ctl_table
proc: Convert use of typedef ctl_table to struct ctl_table
fs: Convert use of typedef ctl_table to struct ctl_table
key: Convert use of typedef ctl_table to struct ctl_table
ipc: Convert use of typedef ctl_table to struct ctl_table
kernel: Convert use of typedef ctl_table to struct ctl_table
mm: Convert use of typedef ctl_table to struct ctl_table
security:keys: Convert use of typedef ctl_table to struct ctl_table

After all this work, why not go ahead and remove the typedef?  That way 
people won't add more users of this abomination.

David Daney




   arch/arm/kernel/isa.c  |  6 ++---
   arch/ia64/kernel/crash.c   |  4 +--
   arch/ia64/kernel/perfmon.c |  6 ++---
   arch/s390/appldata/appldata_base.c | 10 
   arch/s390/kernel/debug.c   |  2 +-
   arch/s390/mm/cmm.c |  8 +++---
   arch/tile/kernel/proc.c|  4 +--
   drivers/cdrom/cdrom.c  | 10 
   drivers/char/random.c  |  4 +--
   drivers/infiniband/core/ucma.c |  2 +-
   drivers/md/md.c|  6 ++---
   drivers/parport/procfs.c   | 52 
 ++
   drivers/scsi/scsi_sysctl.c |  6 ++---
   fs/coda/sysctl.c   |  4 +--
   fs/dcache.c|  2 +-
   fs/drop_caches.c   |  2 +-
   fs/eventpoll.c |  2 +-
   fs/file_table.c|  4 +--
   fs/fscache/main.c  |  4 +--
   fs/inode.c |  2 +-
   fs/lockd/svc.c |  6 ++---
   fs/nfs/nfs4sysctl.c|  6 ++---
   fs/nfs/sysctl.c|  6 ++---
   fs/notify/inotify/inotify_user.c   |  2 +-
   fs/ntfs/sysctl.c   |  4 +--
   fs/ocfs2/stackglue.c   |  8 +++---
   fs/proc/proc_sysctl.c  |  2 +-
   include/linux/key.h|  2 +-
   ipc/ipc_sysctl.c   | 14 +-
   ipc/mq_sysctl.c| 10 
   kernel/sysctl.c|  2 +-
   kernel/utsname_sysctl.c|  6 ++---
   mm/page-writeback.c|  2 +-
   mm/page_alloc.c| 12 -
   security/keys/sysctl.c |  2 +-
   35 files changed, 111 insertions(+), 113 deletions(-)



___
Ocfs2-devel mailing list
Ocfs2-devel@oss.oracle.com
https://oss.oracle.com/mailman/listinfo/ocfs2-devel


[Ocfs2-devel] [PATCH 08/15] fs/hearbeat: Replace hardcoding of -20 with MIN_NICE.

2014-03-28 Thread Dongsheng Yang
Signed-off-by: Dongsheng Yang yangds.f...@cn.fujitsu.com
cc: ocfs2-devel@oss.oracle.com
cc: Dong Fang yp.fangd...@gmail.com
---
 fs/ocfs2/cluster/heartbeat.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs/ocfs2/cluster/heartbeat.c b/fs/ocfs2/cluster/heartbeat.c
index bf482df..7303929 100644
--- a/fs/ocfs2/cluster/heartbeat.c
+++ b/fs/ocfs2/cluster/heartbeat.c
@@ -1107,7 +1107,7 @@ static int o2hb_thread(void *data)
 
mlog(ML_HEARTBEAT|ML_KTHREAD, hb thread running\n);
 
-   set_user_nice(current, -20);
+   set_user_nice(current, MIN_NICE);
 
/* Pin node */
o2nm_depend_this_node();
-- 
1.8.2.1


___
Ocfs2-devel mailing list
Ocfs2-devel@oss.oracle.com
https://oss.oracle.com/mailman/listinfo/ocfs2-devel


Re: [Ocfs2-devel] [PATCH] fs: push sync_filesystem() down to the file system's remount_fs()

2014-03-28 Thread Theodore Ts'o
On Thu, Mar 13, 2014 at 07:33:02PM -0500, Steve French wrote:
 On Thu, Mar 13, 2014 at 9:20 AM, Theodore Ts'o ty...@mit.edu wrote:
  Previously, the no-op mount -o mount /dev/xxx operation when the
  file system is already mounted read-write causes an implied,
  unconditional syncfs().  This seems pretty stupid, and it's certainly
  documented or guaraunteed to do this, nor is it particularly useful,
  except in the case where the file system was mounted rw and is getting
  remounted read-only.
 
 Is there a case where a file system, not mounted read-only,
 would want to skip the syncfs on remount?  I don't know
 of any particular reason to do a syncfs on remount unless
 caching behavior is changing (or moving to read-only mount),
 but if as you say it is documented and guaranteed...

If the file system is mounted read-write, and it is transitioning to
read-only, i.e. mount -o remount,ro / then you do want to write out
all dirty data before you transition it to be read-only (otherwise you
would lose data).

It is my belief that this is the _only_ data integrity issue which is
implied by remount (and this is more about not losing work done by
previous system calls).

The background reason for this commit is that a user complained on the
ext4 list that he is using containers in a virtualization environment,
and due to the init scripts which the user doesn't want to change, it
is causing gazillions of no-op remounts, and this is causing ext4 (and
xfs) to do send CACHE FLUSH commands because it is required by the
syncfs(2) system call, which also calls sync_filesystem.  These CACHE
FLUSH commands are unneeded for anything, especially for these no-op
remounts, and so I want them to go away for remounts, but they should
still be there in response to syncfs(2) requests.

Cheers,

- Ted

___
Ocfs2-devel mailing list
Ocfs2-devel@oss.oracle.com
https://oss.oracle.com/mailman/listinfo/ocfs2-devel


Re: [Ocfs2-devel] [XFS on bad superblock] BUG: unable to handle kernel NULL pointer dereference at 00000003

2014-03-28 Thread Dave Chinner
On Thu, Oct 10, 2013 at 04:23:50PM +0800, Fengguang Wu wrote:
 Dave,
 
  This is an easily reproducible bug. And I further confirmed it in
  two ways:
 
  1) turn off XFS, build 39 commits and boot them 2000+ times
 
  = no single mount error
 
 That doesn't tell you it is an XFS error. Absence of symptoms !=
 absence of bug.
 
 True.
 
  2) turn off all other filesystems, build 2 kernels on v3.12-rc3
 v3.12-rc4 and boot them
  
  = half boots have oops
 
 Again, it doesn't tell you that it is an XFS bug. XFS is well known
 for exposing bugs in less used block devices, and you are definitely
 using devices that are unusual and not commonly tested by filesystem
 developers (e.g. zram, nbd, etc).
 
 
 Yeah, it's possible that your commit exposed a bug in the less used
 nbd/zram devices.

So please reproduce it on a brd/scsi/sata/virtio block device before
going any further. Preferably with a bash script I can point at a
single block device, not a binary initrd blob that I have to
deconstruct to try to work out what your test is doing.

because this:

 [7.707009] end_request: I/O error, dev fd0, sector 0
 [   10.475988] block nbd4: Attempted send on closed socket
 [   10.478272] end_request: I/O error, dev nbd4, sector 0
 [   10.492950] block nbd15: Attempted send on closed socket
 [   10.498283] end_request: I/O error, dev nbd15, sector 0

says that nbd is going through I/O error land, and that's the most
likely cause of problems being seen by higher level IO completion
operations

 [   10.504236] BUG: unable to handle kernel NULL pointer dereference at 
 0004
 [   10.507558] IP: [c1034419] pool_mayday_timeout+0x5f/0x9c

And that's deep inside the workqueue infrastructure, indicating that
rescues are being used (allocation deadlock?) which is also less
tested error handling code path

 [   10.507558] *pdpt = 0ce6a001 *pde = 
 [   10.507558] Oops:  [#1]
 [   10.507558] CPU: 0 PID: 516 Comm: mount Not tainted 3.12.0-rc4 #2
 [   10.507558] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
 [   10.507558] task: ccda7440 ti: cf40a000 task.ti: cce2e000
 [   10.507558] EIP: 0060:[c1034419] EFLAGS: 00010046 CPU: 0
 [   10.507558] EIP is at pool_mayday_timeout+0x5f/0x9c
 [   10.507558] EAX:  EBX: c1931d50 ECX:  EDX: 
 [   10.507558] ESI: c10343ba EDI: cd5a3258 EBP: cf40bf94 ESP: cf40bf80
 [   10.507558]  DS: 007b ES: 007b FS:  GS: 0033 SS: 0068
 [   10.507558] CR0: 8005003b CR2: 0004 CR3: 0cdbd000 CR4: 06b0
 [   10.507558] Stack:
 [   10.507558]  c1931d60 cf40bf90 0100 c10343ba cf40bfc0 cf40bfa4 
 c102cd96 c1a52700
 [   10.507558]  cf40bfc0 cf40bfd4 c102cf7e c1931d50 c1a53110 c1a52f10 
 cf40bfc0 c10343ba
 [   10.507558]  cf40bfc0 cf40bfc0 0001 c1a52588 0100 cf40bff8 
 c1028f61 0001
 [   10.507558] Call Trace:
 [   10.507558]  [c10343ba] ? need_to_create_worker+0x32/0x32
 [   10.507558]  [c102cd96] call_timer_fn.isra.39+0x16/0x60
 [   10.507558]  [c102cf7e] run_timer_softirq+0x144/0x15e
 [   10.507558]  [c10343ba] ? need_to_create_worker+0x32/0x32
 [   10.507558]  [c1028f61] __do_softirq+0x87/0x12b
 [   10.507558]  [c1028eda] ? local_bh_enable_ip+0xa/0xa
 [   10.507558]  IRQ
 [   10.507558]  [c10290c4] ? irq_exit+0x3a/0x48
 [   10.507558]  [c1018818] ? smp_apic_timer_interrupt+0x23/0x2c
 [   10.507558]  [c164f38d] ? apic_timer_interrupt+0x2d/0x34
 [   10.507558]  [c126f5e2] ? arch_local_irq_restore+0x5/0xb
 [   10.507558]  [c126f694] ? spin_unlock_irqrestore.isra.4+0x8/0x14
 [   10.507558]  [c126f705] ? nbd_end_request+0x65/0x6d
 [   10.507558]  [c126f784] ? do_nbd_request+0x77/0xc1
 [   10.507558]  [c11abe4f] ? __blk_run_queue_uncond+0x1e/0x27
 [   10.507558]  [c11abe6b] ? __blk_run_queue+0x13/0x15
 [   10.507558]  [c11abfe8] ? queue_unplugged.isra.56+0x13/0x1f
 [   10.507558]  [c11ad70b] ? blk_flush_plug_list+0x140/0x14f
 [   10.507558]  [c11ad95f] ? blk_finish_plug+0xd/0x27
 [   10.507558]  [c11051b6] ? _xfs_buf_ioapply+0x236/0x24e

and it has happened deep inside the nbd IO path in the context of
the xfs_buf allocation that has seen corruptions in previous dumps.

So before I look any further at this, you need to rule out nbd as
the cause of the problems because the XFS code paths on scsi, sata,
brd and virtio block device don't cause any problems

Cheers,

Dave.
-- 
Dave Chinner
da...@fromorbit.com

___
Ocfs2-devel mailing list
Ocfs2-devel@oss.oracle.com
https://oss.oracle.com/mailman/listinfo/ocfs2-devel


[Ocfs2-devel] [PATCH 3.4 37/43] jbd2: dont BUG but return ENOSPC if a handle runs out of space

2014-03-28 Thread Greg Kroah-Hartman
3.4-stable review patch.  If anyone has any objections, please let me know.

--

From: Theodore Ts'o ty...@mit.edu

commit f6c07cad081ba222d63623d913aafba5586c1d2c upstream.

If a handle runs out of space, we currently stop the kernel with a BUG
in jbd2_journal_dirty_metadata().  This makes it hard to figure out
what might be going on.  So return an error of ENOSPC, so we can let
the file system layer figure out what is going on, to make it more
likely we can get useful debugging information).  This should make it
easier to debug problems such as the one which was reported by:

https://bugzilla.kernel.org/show_bug.cgi?id=44731

The only two callers of this function are ext4_handle_dirty_metadata()
and ocfs2_journal_dirty().  The ocfs2 function will trigger a
BUG_ON(), which means there will be no change in behavior.  The ext4
function will call ext4_error_inode() which will print the useful
debugging information and then handle the situation using ext4's error
handling mechanisms (i.e., which might mean halting the kernel or
remounting the file system read-only).

Also, since both file systems already call WARN_ON(), drop the WARN_ON
from jbd2_journal_dirty_metadata() to avoid two stack traces from
being displayed.

Signed-off-by: Theodore Ts'o ty...@mit.edu
Cc: ocfs2-devel@oss.oracle.com
Acked-by: Joel Becker jl...@evilplan.org
Signed-off-by: Greg Kroah-Hartman gre...@linuxfoundation.org

---
 fs/jbd2/transaction.c |6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

--- a/fs/jbd2/transaction.c
+++ b/fs/jbd2/transaction.c
@@ -1126,7 +1126,10 @@ int jbd2_journal_dirty_metadata(handle_t
 * once a transaction -bzzz
 */
jh-b_modified = 1;
-   J_ASSERT_JH(jh, handle-h_buffer_credits  0);
+   if (handle-h_buffer_credits = 0) {
+   ret = -ENOSPC;
+   goto out_unlock_bh;
+   }
handle-h_buffer_credits--;
}
 
@@ -1209,7 +1212,6 @@ out_unlock_bh:
jbd2_journal_put_journal_head(jh);
 out:
JBUFFER_TRACE(jh, exit);
-   WARN_ON(ret);   /* All errors are bugs, so dump the stack */
return ret;
 }
 



___
Ocfs2-devel mailing list
Ocfs2-devel@oss.oracle.com
https://oss.oracle.com/mailman/listinfo/ocfs2-devel


Re: [Ocfs2-devel] [PATCH] Remove versioning information

2014-03-28 Thread Lars Marowsky-Bree
On 2013-11-26T17:37:27, Goldwyn Rodrigues rgold...@suse.de wrote:

 The versioning information is confusing for end-users. The numbers
 are stuck at 1.5.0 while the tools version have moved to 1.8.2.
 
 I suggest removing the versioning system in the ocfs2 module and let
 the kernel version be the guide to debug issues. However, if
 you think versioning is still required, please state the reason and
 modify the version string in the *ver.h files.
 
 Signed-off-by: Goldwyn Rodrigues rgold...@suse.com

Reviewed-by: Lars Marowsky-Bree l...@suse.com

I agree, this is confusing for our users/customers and not quite
appropriate for an in-kernel maintained module.


Regards,
Lars

-- 
Architect Storage/HA
SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 
21284 (AG Nürnberg)
Experience is the name everyone gives to their mistakes. -- Oscar Wilde


___
Ocfs2-devel mailing list
Ocfs2-devel@oss.oracle.com
https://oss.oracle.com/mailman/listinfo/ocfs2-devel


[Ocfs2-devel] [PATCH 3.12 132/144] jbd2: dont BUG but return ENOSPC if a handle runs out of space

2014-03-28 Thread Greg Kroah-Hartman
3.12-stable review patch.  If anyone has any objections, please let me know.

--

From: Theodore Ts'o ty...@mit.edu

commit f6c07cad081ba222d63623d913aafba5586c1d2c upstream.

If a handle runs out of space, we currently stop the kernel with a BUG
in jbd2_journal_dirty_metadata().  This makes it hard to figure out
what might be going on.  So return an error of ENOSPC, so we can let
the file system layer figure out what is going on, to make it more
likely we can get useful debugging information).  This should make it
easier to debug problems such as the one which was reported by:

https://bugzilla.kernel.org/show_bug.cgi?id=44731

The only two callers of this function are ext4_handle_dirty_metadata()
and ocfs2_journal_dirty().  The ocfs2 function will trigger a
BUG_ON(), which means there will be no change in behavior.  The ext4
function will call ext4_error_inode() which will print the useful
debugging information and then handle the situation using ext4's error
handling mechanisms (i.e., which might mean halting the kernel or
remounting the file system read-only).

Also, since both file systems already call WARN_ON(), drop the WARN_ON
from jbd2_journal_dirty_metadata() to avoid two stack traces from
being displayed.

Signed-off-by: Theodore Ts'o ty...@mit.edu
Cc: ocfs2-devel@oss.oracle.com
Acked-by: Joel Becker jl...@evilplan.org
Signed-off-by: Greg Kroah-Hartman gre...@linuxfoundation.org

---
 fs/jbd2/transaction.c |6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

--- a/fs/jbd2/transaction.c
+++ b/fs/jbd2/transaction.c
@@ -1290,7 +1290,10 @@ int jbd2_journal_dirty_metadata(handle_t
 * once a transaction -bzzz
 */
jh-b_modified = 1;
-   J_ASSERT_JH(jh, handle-h_buffer_credits  0);
+   if (handle-h_buffer_credits = 0) {
+   ret = -ENOSPC;
+   goto out_unlock_bh;
+   }
handle-h_buffer_credits--;
}
 
@@ -1373,7 +1376,6 @@ out_unlock_bh:
jbd2_journal_put_journal_head(jh);
 out:
JBUFFER_TRACE(jh, exit);
-   WARN_ON(ret);   /* All errors are bugs, so dump the stack */
return ret;
 }
 



___
Ocfs2-devel mailing list
Ocfs2-devel@oss.oracle.com
https://oss.oracle.com/mailman/listinfo/ocfs2-devel


[Ocfs2-devel] [PATCH 2/4 v3] fiemap: add EXTENT_DATA_COMPRESSED flag

2014-03-28 Thread David Sterba
This flag was not accepted when fiemap was proposed [2] due to lack of
in-kernel users. Btrfs has compression for a long time and we'd like to
see that an extent is compressed in the output of 'filefrag' utility
once it's taught about it.

For that purpose, a reserved field from fiemap_extent is used to let the
filesystem store along the physcial extent length when the flag is set.
This keeps compatibility with applications that use FIEMAP.

Extend arguments of fiemap_fill_next_extent and update all users.

[1] http://article.gmane.org/gmane.comp.file-systems.ext4/8871
[2] http://thread.gmane.org/gmane.comp.file-systems.ext4/8870
[3] http://thread.gmane.org/gmane.linux.file-systems/77632 (v1)
[4] http://www.spinics.net/lists/linux-fsdevel/msg69078.html (v2)

Cc: Al Viro v...@zeniv.linux.org.uk
CC: Andreas Dilger adil...@dilger.ca
CC: Christoph Hellwig h...@infradead.org
CC: Mark Fasheh mfas...@suse.com
Signed-off-by: David Sterba dste...@suse.cz
---
 fs/btrfs/extent_io.c|2 +-
 fs/ext4/extents.c   |3 ++-
 fs/ext4/inline.c|2 +-
 fs/gfs2/inode.c |2 +-
 fs/ioctl.c  |   18 --
 fs/nilfs2/inode.c   |8 +---
 fs/ocfs2/extent_map.c   |4 ++--
 fs/xfs/xfs_iops.c   |2 +-
 include/linux/fs.h  |2 +-
 include/uapi/linux/fiemap.h |6 +-
 10 files changed, 31 insertions(+), 18 deletions(-)

diff --git a/fs/btrfs/extent_io.c b/fs/btrfs/extent_io.c
index ff43802..5ea0ef5 100644
--- a/fs/btrfs/extent_io.c
+++ b/fs/btrfs/extent_io.c
@@ -4244,7 +4244,7 @@ int extent_fiemap(struct inode *inode, struct 
fiemap_extent_info *fieinfo,
end = 1;
}
ret = fiemap_fill_next_extent(fieinfo, em_start, disko,
- em_len, flags);
+ em_len, 0, flags);
if (ret)
goto out_free;
}
diff --git a/fs/ext4/extents.c b/fs/ext4/extents.c
index 35f65cf..00ffd18 100644
--- a/fs/ext4/extents.c
+++ b/fs/ext4/extents.c
@@ -2224,6 +2224,7 @@ static int ext4_fill_fiemap_extents(struct inode *inode,
(__u64)es.es_lblk  blksize_bits,
(__u64)es.es_pblk  blksize_bits,
(__u64)es.es_len  blksize_bits,
+   0,
flags);
if (err  0)
break;
@@ -4798,7 +4799,7 @@ static int ext4_xattr_fiemap(struct inode *inode,
 
if (physical)
error = fiemap_fill_next_extent(fieinfo, 0, physical,
-   length, flags);
+   length, 0, flags);
return (error  0 ? error : 0);
 }
 
diff --git a/fs/ext4/inline.c b/fs/ext4/inline.c
index bae9875..c5da773 100644
--- a/fs/ext4/inline.c
+++ b/fs/ext4/inline.c
@@ -1816,7 +1816,7 @@ int ext4_inline_data_fiemap(struct inode *inode,
 
if (physical)
error = fiemap_fill_next_extent(fieinfo, 0, physical,
-   length, flags);
+   length, 0, flags);
brelse(iloc.bh);
 out:
up_read(EXT4_I(inode)-xattr_sem);
diff --git a/fs/gfs2/inode.c b/fs/gfs2/inode.c
index 7119504..86e9e9b 100644
--- a/fs/gfs2/inode.c
+++ b/fs/gfs2/inode.c
@@ -1817,7 +1817,7 @@ static int gfs2_fiemap(struct inode *inode, struct 
fiemap_extent_info *fieinfo,
len = size - start;
if (start  size)
ret = fiemap_fill_next_extent(fieinfo, start, phys,
- len, flags);
+ len, 0, flags);
if (ret == 1)
ret = 0;
} else {
diff --git a/fs/ioctl.c b/fs/ioctl.c
index 8ac3fad..e7902c4 100644
--- a/fs/ioctl.c
+++ b/fs/ioctl.c
@@ -70,6 +70,7 @@ static int ioctl_fibmap(struct file *filp, int __user *p)
  * @logical:   Extent logical start offset, in bytes
  * @phys:  Extent physical start offset, in bytes
  * @len:   Extent length, in bytes
+ * @phys_len:   Physical extent length in bytes
  * @flags: FIEMAP_EXTENT flags that describe this extent
  *
  * Called from file system -fiemap callback. Will populate extent
@@ -80,10 +81,11 @@ static int ioctl_fibmap(struct file *filp, int __user *p)
  * extent that will fit in user array.
  */
 #define SET_UNKNOWN_FLAGS  (FIEMAP_EXTENT_DELALLOC)
-#define SET_NO_UNMOUNTED_IO_FLAGS  (FIEMAP_EXTENT_DATA_ENCRYPTED)
+#define SET_NO_UNMOUNTED_IO_FLAGS  (FIEMAP_EXTENT_DATA_ENCRYPTED | \
+FIEMAP_EXTENT_DATA_COMPRESSED)
 #define SET_NOT_ALIGNED_FLAGS  
(FIEMAP_EXTENT_DATA_TAIL|FIEMAP_EXTENT_DATA_INLINE)
 int 

[Ocfs2-devel] [PATCH 3.10 085/129] jbd2: dont BUG but return ENOSPC if a handle runs out of space

2014-03-28 Thread Greg Kroah-Hartman
3.10-stable review patch.  If anyone has any objections, please let me know.

--

From: Theodore Ts'o ty...@mit.edu

commit f6c07cad081ba222d63623d913aafba5586c1d2c upstream.

If a handle runs out of space, we currently stop the kernel with a BUG
in jbd2_journal_dirty_metadata().  This makes it hard to figure out
what might be going on.  So return an error of ENOSPC, so we can let
the file system layer figure out what is going on, to make it more
likely we can get useful debugging information).  This should make it
easier to debug problems such as the one which was reported by:

https://bugzilla.kernel.org/show_bug.cgi?id=44731

The only two callers of this function are ext4_handle_dirty_metadata()
and ocfs2_journal_dirty().  The ocfs2 function will trigger a
BUG_ON(), which means there will be no change in behavior.  The ext4
function will call ext4_error_inode() which will print the useful
debugging information and then handle the situation using ext4's error
handling mechanisms (i.e., which might mean halting the kernel or
remounting the file system read-only).

Also, since both file systems already call WARN_ON(), drop the WARN_ON
from jbd2_journal_dirty_metadata() to avoid two stack traces from
being displayed.

Signed-off-by: Theodore Ts'o ty...@mit.edu
Cc: ocfs2-devel@oss.oracle.com
Acked-by: Joel Becker jl...@evilplan.org
Signed-off-by: Greg Kroah-Hartman gre...@linuxfoundation.org

---
 fs/jbd2/transaction.c |6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

--- a/fs/jbd2/transaction.c
+++ b/fs/jbd2/transaction.c
@@ -1151,7 +1151,10 @@ int jbd2_journal_dirty_metadata(handle_t
 * once a transaction -bzzz
 */
jh-b_modified = 1;
-   J_ASSERT_JH(jh, handle-h_buffer_credits  0);
+   if (handle-h_buffer_credits = 0) {
+   ret = -ENOSPC;
+   goto out_unlock_bh;
+   }
handle-h_buffer_credits--;
}
 
@@ -1234,7 +1237,6 @@ out_unlock_bh:
jbd2_journal_put_journal_head(jh);
 out:
JBUFFER_TRACE(jh, exit);
-   WARN_ON(ret);   /* All errors are bugs, so dump the stack */
return ret;
 }
 



___
Ocfs2-devel mailing list
Ocfs2-devel@oss.oracle.com
https://oss.oracle.com/mailman/listinfo/ocfs2-devel


[Ocfs2-devel] [3.11.y.z extended stable] Patch jbd2: don't BUG but return ENOSPC if a handle runs out of space has been added to staging queue

2014-03-28 Thread Luis Henriques
This is a note to let you know that I have just added a patch titled

jbd2: don't BUG but return ENOSPC if a handle runs out of space

to the linux-3.11.y-queue branch of the 3.11.y.z extended stable tree 
which can be found at:

 
http://kernel.ubuntu.com/git?p=ubuntu/linux.git;a=shortlog;h=refs/heads/linux-3.11.y-queue

If you, or anyone else, feels it should not be added to this tree, please 
reply to this email.

For more information about the 3.11.y.z tree, see
https://wiki.ubuntu.com/Kernel/Dev/ExtendedStable

Thanks.
-Luis

--

From 2fca912f31797cfcfb17de2c37c66f63da847945 Mon Sep 17 00:00:00 2001
From: Theodore Ts'o ty...@mit.edu
Date: Sun, 8 Dec 2013 21:12:59 -0500
Subject: jbd2: don't BUG but return ENOSPC if a handle runs out of space

commit f6c07cad081ba222d63623d913aafba5586c1d2c upstream.

If a handle runs out of space, we currently stop the kernel with a BUG
in jbd2_journal_dirty_metadata().  This makes it hard to figure out
what might be going on.  So return an error of ENOSPC, so we can let
the file system layer figure out what is going on, to make it more
likely we can get useful debugging information).  This should make it
easier to debug problems such as the one which was reported by:

https://bugzilla.kernel.org/show_bug.cgi?id=44731

The only two callers of this function are ext4_handle_dirty_metadata()
and ocfs2_journal_dirty().  The ocfs2 function will trigger a
BUG_ON(), which means there will be no change in behavior.  The ext4
function will call ext4_error_inode() which will print the useful
debugging information and then handle the situation using ext4's error
handling mechanisms (i.e., which might mean halting the kernel or
remounting the file system read-only).

Also, since both file systems already call WARN_ON(), drop the WARN_ON
from jbd2_journal_dirty_metadata() to avoid two stack traces from
being displayed.

Signed-off-by: Theodore Ts'o ty...@mit.edu
Cc: ocfs2-devel@oss.oracle.com
Acked-by: Joel Becker jl...@evilplan.org
Signed-off-by: Luis Henriques luis.henriq...@canonical.com
---
 fs/jbd2/transaction.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/fs/jbd2/transaction.c b/fs/jbd2/transaction.c
index 7aa9a32..b0b74e5 100644
--- a/fs/jbd2/transaction.c
+++ b/fs/jbd2/transaction.c
@@ -1290,7 +1290,10 @@ int jbd2_journal_dirty_metadata(handle_t *handle, struct 
buffer_head *bh)
 * once a transaction -bzzz
 */
jh-b_modified = 1;
-   J_ASSERT_JH(jh, handle-h_buffer_credits  0);
+   if (handle-h_buffer_credits = 0) {
+   ret = -ENOSPC;
+   goto out_unlock_bh;
+   }
handle-h_buffer_credits--;
}

@@ -1373,7 +1376,6 @@ out_unlock_bh:
jbd2_journal_put_journal_head(jh);
 out:
JBUFFER_TRACE(jh, exit);
-   WARN_ON(ret);   /* All errors are bugs, so dump the stack */
return ret;
 }

--
1.8.3.2


___
Ocfs2-devel mailing list
Ocfs2-devel@oss.oracle.com
https://oss.oracle.com/mailman/listinfo/ocfs2-devel


Re: [Ocfs2-devel] [XFS on bad superblock] BUG: unable to handle kernel NULL pointer dereference at 00000003

2014-03-28 Thread Dave Chinner
On Thu, Oct 10, 2013 at 11:38:34AM +0800, Fengguang Wu wrote:
 On Thu, Oct 10, 2013 at 11:33:00AM +0800, Fengguang Wu wrote:
  On Thu, Oct 10, 2013 at 11:26:37AM +0800, Fengguang Wu wrote:
   Dave,
   
I note that you have CONFIG_SLUB=y, which means that the cache slabs
are shared with objects of other types. That means that the memory
corruption problem is likely to be caused by one of the other
filesystems that is probing the block device(s), not XFS.
   
   Good to know that, it would easy to test then: just turn off every
   other filesystems. I'll try it right away.
  
  Seems that we don't even need to do that. A dig through the oops
  database and I find stack dumps from other FS.
  
  This happens in the kernel with same kconfig and commit 3.12-rc1.
 
 Here is a summary of all FS with oops:
 
 411 ocfs2_fill_super
 189 xfs_fs_fill_super
  86 jfs_fill_super
  50 isofs_fill_super
  33 fat_fill_super
  18 vfat_fill_super
  15 msdos_fill_super
  11 ext2_fill_super
  10 ext3_fill_super
   3 reiserfs_fill_super

The order of probing on the original dmesg output you reported is:

ext3
ext2
fatfs
reiserfs
gfs2
isofs
ocfs2

which means that no XFS filesystem was mounted in the original bug
report, and hence that further indicates that XFS is not responsible
for the problem and that perhaps the original bisect was not
reliable...

Cheers,

Dave.
-- 
Dave Chinner
da...@fromorbit.com

___
Ocfs2-devel mailing list
Ocfs2-devel@oss.oracle.com
https://oss.oracle.com/mailman/listinfo/ocfs2-devel


[Ocfs2-devel] [3.5.y.z extended stable] Patch jbd2: don't BUG but return ENOSPC if a handle runs out of space has been added to staging queue

2014-03-28 Thread Luis Henriques
This is a note to let you know that I have just added a patch titled

jbd2: don't BUG but return ENOSPC if a handle runs out of space

to the linux-3.5.y-queue branch of the 3.5.y.z extended stable tree 
which can be found at:

 
http://kernel.ubuntu.com/git?p=ubuntu/linux.git;a=shortlog;h=refs/heads/linux-3.5.y-queue

If you, or anyone else, feels it should not be added to this tree, please 
reply to this email.

For more information about the 3.5.y.z tree, see
https://wiki.ubuntu.com/Kernel/Dev/ExtendedStable

Thanks.
-Luis

--

From bc53fe8f253aede4b44e5c0b7e1761461e6c7565 Mon Sep 17 00:00:00 2001
From: Theodore Ts'o ty...@mit.edu
Date: Sun, 8 Dec 2013 21:12:59 -0500
Subject: jbd2: don't BUG but return ENOSPC if a handle runs out of space

commit f6c07cad081ba222d63623d913aafba5586c1d2c upstream.

If a handle runs out of space, we currently stop the kernel with a BUG
in jbd2_journal_dirty_metadata().  This makes it hard to figure out
what might be going on.  So return an error of ENOSPC, so we can let
the file system layer figure out what is going on, to make it more
likely we can get useful debugging information).  This should make it
easier to debug problems such as the one which was reported by:

https://bugzilla.kernel.org/show_bug.cgi?id=44731

The only two callers of this function are ext4_handle_dirty_metadata()
and ocfs2_journal_dirty().  The ocfs2 function will trigger a
BUG_ON(), which means there will be no change in behavior.  The ext4
function will call ext4_error_inode() which will print the useful
debugging information and then handle the situation using ext4's error
handling mechanisms (i.e., which might mean halting the kernel or
remounting the file system read-only).

Also, since both file systems already call WARN_ON(), drop the WARN_ON
from jbd2_journal_dirty_metadata() to avoid two stack traces from
being displayed.

Signed-off-by: Theodore Ts'o ty...@mit.edu
Cc: ocfs2-devel@oss.oracle.com
Acked-by: Joel Becker jl...@evilplan.org
Signed-off-by: Luis Henriques luis.henriq...@canonical.com
---
 fs/jbd2/transaction.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/fs/jbd2/transaction.c b/fs/jbd2/transaction.c
index 81203d1..edfb1ec 100644
--- a/fs/jbd2/transaction.c
+++ b/fs/jbd2/transaction.c
@@ -1126,7 +1126,10 @@ int jbd2_journal_dirty_metadata(handle_t *handle, struct 
buffer_head *bh)
 * once a transaction -bzzz
 */
jh-b_modified = 1;
-   J_ASSERT_JH(jh, handle-h_buffer_credits  0);
+   if (handle-h_buffer_credits = 0) {
+   ret = -ENOSPC;
+   goto out_unlock_bh;
+   }
handle-h_buffer_credits--;
}

@@ -1209,7 +1212,6 @@ out_unlock_bh:
jbd2_journal_put_journal_head(jh);
 out:
JBUFFER_TRACE(jh, exit);
-   WARN_ON(ret);   /* All errors are bugs, so dump the stack */
return ret;
 }

--
1.8.3.2


___
Ocfs2-devel mailing list
Ocfs2-devel@oss.oracle.com
https://oss.oracle.com/mailman/listinfo/ocfs2-devel


Re: [Ocfs2-devel] [PATCH 3/7] Differentiate between no_controld and with_controld

2014-03-28 Thread Lars Marowsky-Bree
On 2013-09-27T12:07:53, Goldwyn Rodrigues rgold...@suse.de wrote:

 This is done primarily for backward compatibility. I hope we do
 away with this sooner than later ;)

I'd actually be quite happy if we could do away with this directly.

Users that want to remain on an older user-space code base can always
revert this or stick to a stable long-term kernel. That may be an
unpopular opinion ;-)

The relevant GFS2 commit seems to be
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/fs/gfs2?id=e0c2a9aa1e68455dc3439e95d85cabcaff073666


Regards,
Lars

-- 
Architect Storage/HA
SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 
21284 (AG Nürnberg)
Experience is the name everyone gives to their mistakes. -- Oscar Wilde


___
Ocfs2-devel mailing list
Ocfs2-devel@oss.oracle.com
https://oss.oracle.com/mailman/listinfo/ocfs2-devel


Re: [Ocfs2-devel] [PATCH] ocfs2: check if cluster name exists before deref

2014-03-28 Thread Sasha Levin
On 03/26/2014 06:00 PM, Mark Fasheh wrote:
 On Tue, Mar 25, 2014 at 01:21:58PM -0400, Sasha Levin wrote:
 As a side note, how the hell was this new code path tested?
 It's obviously broken and there's no way it even passes
 a very basic test.

 I'm not trying to 'defend' Goldwyn, or anything, but mistakes get made -
 it's a fact of life. We have a review process to hopefully catch these sorts
 of things, you are welcome to take part in it. In fact, if you were
 willing to test and report these sorts of things to the Ocfs2-devel list
 before they go upstream that would probably help prevent this sort of thing
 from happening in the future.

Hi Mark,

I'm fuzz testing the kernel and not really testing or reviewing any subsystem
in particular.

My frustration about not testing it was because it's so simple to reproduce this
issue:

  # mount -t ocfs2_dlmfs ocfs2_dlmfs dlm
  # mkdir dlm/anything
  [ boom ]

This is a very basic test that should have been run more than once before this
patch made it into Linus's tree. Whether as part of some ocfs2 test suite or
maybe xfstest.

My beef is not with Goldwyn not testing that path, it's more with whatever
process (or lack thereof) ocfs2 has to test and verify patches before
they make it upstream. Even if Goldwyn missed it, it should have been
caught at a different place on it's way.


Thanks,
Sasha

___
Ocfs2-devel mailing list
Ocfs2-devel@oss.oracle.com
https://oss.oracle.com/mailman/listinfo/ocfs2-devel


[Ocfs2-devel] [PATCH 08/16] fs/hearbeat: Replace hardcoding of -20 with MIN_NICE.

2014-03-28 Thread Dongsheng Yang
Signed-off-by: Dongsheng Yang yangds.f...@cn.fujitsu.com
cc: ocfs2-devel@oss.oracle.com
cc: Dong Fang yp.fangd...@gmail.com
---
 fs/ocfs2/cluster/heartbeat.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs/ocfs2/cluster/heartbeat.c b/fs/ocfs2/cluster/heartbeat.c
index bf482df..7303929 100644
--- a/fs/ocfs2/cluster/heartbeat.c
+++ b/fs/ocfs2/cluster/heartbeat.c
@@ -1107,7 +1107,7 @@ static int o2hb_thread(void *data)
 
mlog(ML_HEARTBEAT|ML_KTHREAD, hb thread running\n);
 
-   set_user_nice(current, -20);
+   set_user_nice(current, MIN_NICE);
 
/* Pin node */
o2nm_depend_this_node();
-- 
1.8.2.1


___
Ocfs2-devel mailing list
Ocfs2-devel@oss.oracle.com
https://oss.oracle.com/mailman/listinfo/ocfs2-devel


[Ocfs2-devel] [PATCH 2/2] ocfs2: add necessary check in case sb_getblk fails

2014-03-28 Thread Rui Xiang
Sb_getblk may retrun an err, so add a check for bh.

Signed-off-by: Rui Xiang rui.xi...@huawei.com
---
 fs/ocfs2/refcounttree.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/fs/ocfs2/refcounttree.c b/fs/ocfs2/refcounttree.c
index 50c1796..22f3f19 100644
--- a/fs/ocfs2/refcounttree.c
+++ b/fs/ocfs2/refcounttree.c
@@ -612,6 +612,11 @@ static int ocfs2_create_refcount_tree(struct inode *inode,
}
 
new_bh = sb_getblk(inode-i_sb, first_blkno);
+   if (!new_bh) {
+   ret = -ENOMEM;
+   mlog_errno(ret);
+   goto out_commit;
+   }
ocfs2_set_new_buffer_uptodate(new_tree-rf_ci, new_bh);
 
ret = ocfs2_journal_access_rb(handle, new_tree-rf_ci, new_bh,
-- 
1.8.2.2



___
Ocfs2-devel mailing list
Ocfs2-devel@oss.oracle.com
https://oss.oracle.com/mailman/listinfo/ocfs2-devel


Re: [Ocfs2-devel] [XFS on bad superblock] BUG: unable to handle kernel NULL pointer dereference at 00000003

2014-03-28 Thread Dave Chinner
On Thu, Oct 10, 2013 at 02:03:34PM +0800, Fengguang Wu wrote:
 On Thu, Oct 10, 2013 at 03:28:20PM +1100, Dave Chinner wrote:
  On Thu, Oct 10, 2013 at 11:38:34AM +0800, Fengguang Wu wrote:
   On Thu, Oct 10, 2013 at 11:33:00AM +0800, Fengguang Wu wrote:
On Thu, Oct 10, 2013 at 11:26:37AM +0800, Fengguang Wu wrote:
 Dave,
 
  I note that you have CONFIG_SLUB=y, which means that the cache slabs
  are shared with objects of other types. That means that the memory
  corruption problem is likely to be caused by one of the other
  filesystems that is probing the block device(s), not XFS.
 
 Good to know that, it would easy to test then: just turn off every
 other filesystems. I'll try it right away.

Seems that we don't even need to do that. A dig through the oops
database and I find stack dumps from other FS.

This happens in the kernel with same kconfig and commit 3.12-rc1.
   
   Here is a summary of all FS with oops:
   
   411 ocfs2_fill_super
   189 xfs_fs_fill_super
86 jfs_fill_super
50 isofs_fill_super
33 fat_fill_super
18 vfat_fill_super
15 msdos_fill_super
11 ext2_fill_super
10 ext3_fill_super
 3 reiserfs_fill_super
  
  The order of probing on the original dmesg output you reported is:
  
  ext3
  ext2
  fatfs
  reiserfs
  gfs2
  isofs
  ocfs2
 
 There are effectively no particular order, because there are many
 superblocks for these filesystems to scan.
 
 for superblocks:
 for filesystems:
 scan super block

Sure, but if XFs is at the end of the list of filesystems to try to
mount, then you'll get allt he other filesystems attempted first,
lik eis being seen. And the absence of a single message in dmesg
from XFS is kind of suspicious, because XFs is by far the noisest of
all filesystems when it comes to warning about bad superblocks

 
 In the end, any filesystem may impact the other (and perhaps a later
 run of itself).

No filesystem should impact on any other filesystem.

However, we have seen in the past that when filesystems share slab
caches that a bug in one filesystem can cause problems in another.
For example, years ago there was a bug in Reiserfs causing bufferhead
corruption that only affected other XFS filesystems on the same
machine.

  which means that no XFS filesystem was mounted in the original bug
  report, and hence that further indicates that XFS is not responsible
  for the problem and that perhaps the original bisect was not
  reliable...
 
 This is an easily reproducible bug. And I further confirmed it in
 two ways:
 
 1) turn off XFS, build 39 commits and boot them 2000+ times
 
 = no single mount error

That doesn't tell you it is an XFS error. Absence of symptoms !=
absence of bug.

 2) turn off all other filesystems, build 2 kernels on v3.12-rc3
v3.12-rc4 and boot them
 
 = half boots have oops

Again, it doesn't tell you that it is an XFS bug. XFS is well known
for exposing bugs in less used block devices, and you are definitely
using devices that are unusual and not commonly tested by filesystem
developers (e.g. zram, nbd, etc).

You need to refine the test down from throw shit at the wall, look
at what sticks to a simple, reproducable test case. I can't
reproduce your systems or testing, so you need to provide a test
case I can use. Otherwise we're just wasting time

 So it may well be that XFS is impacted by an early run of itself.

You haven't provided any evidence that XFS is even finding bad
superblocks. As I said before, XFS is extremely loud when you
attempt to mount a corrupt image. I test this regularly on real
block devices, and I've never, ever had it fall over.

e.g:

$ sudo umount /dev/vda
$ sudo dd if=/dev/zero of=/dev/vda bs=512 count=128
128+0 records in
128+0 records out
65536 bytes (66 kB) copied, 0.0205057 s, 3.2 MB/s
$ sync
$ sudo !!
sudo mount /dev/vda /mnt/test
mount: block device /dev/vda is write-protected, mounting read-only
mount: you must specify the filesystem type
$ dmesg

[121196.435480] REISERFS warning (device vda): sh-2021 reiserfs_fill_super: can 
not find reiserfs on vda
[121196.440097] EXT3-fs (vda): error: can't find ext3 filesystem on dev vda.
[121196.443278] EXT2-fs (vda): error: can't find an ext2 filesystem on dev vda.
[121196.445941] EXT4-fs (vda): VFS: Can't find ext4 filesystem
[121196.449151] cramfs: wrong magic
[121196.450436] SQUASHFS error: Can't find a SQUASHFS superblock on vda
[121196.452453] VFS: Can't find a Minix filesystem V1 | V2 | V3 on device vda.
[121196.454745] FAT-fs (vda): bogus number of reserved sectors
[121196.456275] FAT-fs (vda): Can't find a valid FAT filesystem
[121196.458394] FAT-fs (vda): bogus number of reserved sectors
[121196.459885] FAT-fs (vda): Can't find a valid FAT filesystem
[121196.461918] BFS-fs: bfs_fill_super(): No BFS filesystem on vda 
(magic=)

[Ocfs2-devel] [PATCH 3.11 111/208] jbd2: don't BUG but return ENOSPC if a handle runs out of space

2014-03-28 Thread Luis Henriques
3.11.10.3 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: Theodore Ts'o ty...@mit.edu

commit f6c07cad081ba222d63623d913aafba5586c1d2c upstream.

If a handle runs out of space, we currently stop the kernel with a BUG
in jbd2_journal_dirty_metadata().  This makes it hard to figure out
what might be going on.  So return an error of ENOSPC, so we can let
the file system layer figure out what is going on, to make it more
likely we can get useful debugging information).  This should make it
easier to debug problems such as the one which was reported by:

https://bugzilla.kernel.org/show_bug.cgi?id=44731

The only two callers of this function are ext4_handle_dirty_metadata()
and ocfs2_journal_dirty().  The ocfs2 function will trigger a
BUG_ON(), which means there will be no change in behavior.  The ext4
function will call ext4_error_inode() which will print the useful
debugging information and then handle the situation using ext4's error
handling mechanisms (i.e., which might mean halting the kernel or
remounting the file system read-only).

Also, since both file systems already call WARN_ON(), drop the WARN_ON
from jbd2_journal_dirty_metadata() to avoid two stack traces from
being displayed.

Signed-off-by: Theodore Ts'o ty...@mit.edu
Cc: ocfs2-devel@oss.oracle.com
Acked-by: Joel Becker jl...@evilplan.org
Signed-off-by: Luis Henriques luis.henriq...@canonical.com
---
 fs/jbd2/transaction.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/fs/jbd2/transaction.c b/fs/jbd2/transaction.c
index 7aa9a32..b0b74e5 100644
--- a/fs/jbd2/transaction.c
+++ b/fs/jbd2/transaction.c
@@ -1290,7 +1290,10 @@ int jbd2_journal_dirty_metadata(handle_t *handle, struct 
buffer_head *bh)
 * once a transaction -bzzz
 */
jh-b_modified = 1;
-   J_ASSERT_JH(jh, handle-h_buffer_credits  0);
+   if (handle-h_buffer_credits = 0) {
+   ret = -ENOSPC;
+   goto out_unlock_bh;
+   }
handle-h_buffer_credits--;
}
 
@@ -1373,7 +1376,6 @@ out_unlock_bh:
jbd2_journal_put_journal_head(jh);
 out:
JBUFFER_TRACE(jh, exit);
-   WARN_ON(ret);   /* All errors are bugs, so dump the stack */
return ret;
 }
 
-- 
1.8.3.2


___
Ocfs2-devel mailing list
Ocfs2-devel@oss.oracle.com
https://oss.oracle.com/mailman/listinfo/ocfs2-devel


Re: [Ocfs2-devel] [PATCH] fs: push sync_filesystem() down to the file system's remount_fs()

2014-03-28 Thread Jan Kara
On Thu 13-03-14 10:20:56, Ted Tso wrote:
 Previously, the no-op mount -o mount /dev/xxx operation when the
  ^^remount

 file system is already mounted read-write causes an implied,
 unconditional syncfs().  This seems pretty stupid, and it's certainly
 documented or guaraunteed to do this, nor is it particularly useful,
 except in the case where the file system was mounted rw and is getting
 remounted read-only.
 
 However, it's possible that there might be some file systems that are
 actually depending on this behavior.  In most file systems, it's
 probably fine to only call sync_filesystem() when transitioning from
 read-write to read-only, and there are some file systems where this is
 not needed at all (for example, for a pseudo-filesystem or something
 like romfs).
  Hum, I'd avoid this excercise at least for filesystem where
sync_filesystem() is obviously useless - proc, debugfs, pstore, devpts,
also always read-only filesystems such as isofs, qnx4, qnx6, befs, cramfs,
efs, freevxfs, romfs, squashfs. I think you can find a couple more which
clearly don't care about sync_filesystem() if you look a bit closer.

Honza
 
 Signed-off-by: Theodore Ts'o ty...@mit.edu
 Cc: linux-fsde...@vger.kernel.org
 Cc: Christoph Hellwig h...@infradead.org
 Cc: Artem Bityutskiy dedeki...@gmail.com
 Cc: Adrian Hunter adrian.hun...@intel.com
 Cc: Evgeniy Dushistov dushis...@mail.ru
 Cc: Jan Kara j...@suse.cz
 Cc: OGAWA Hirofumi hirof...@mail.parknet.co.jp
 Cc: Anders Larsen a...@alarsen.net
 Cc: Phillip Lougher phil...@squashfs.org.uk
 Cc: Kees Cook keesc...@chromium.org
 Cc: Mikulas Patocka miku...@artax.karlin.mff.cuni.cz
 Cc: Petr Vandrovec p...@vandrovec.name
 Cc: x...@oss.sgi.com
 Cc: linux-bt...@vger.kernel.org
 Cc: linux-c...@vger.kernel.org
 Cc: samba-techni...@lists.samba.org
 Cc: codal...@coda.cs.cmu.edu
 Cc: linux-e...@vger.kernel.org
 Cc: linux-f2fs-de...@lists.sourceforge.net
 Cc: fuse-de...@lists.sourceforge.net
 Cc: cluster-de...@redhat.com
 Cc: linux-...@lists.infradead.org
 Cc: jfs-discuss...@lists.sourceforge.net
 Cc: linux-...@vger.kernel.org
 Cc: linux-ni...@vger.kernel.org
 Cc: linux-ntfs-...@lists.sourceforge.net
 Cc: ocfs2-devel@oss.oracle.com
 Cc: reiserfs-de...@vger.kernel.org
 ---
  fs/adfs/super.c  | 1 +
  fs/affs/super.c  | 1 +
  fs/befs/linuxvfs.c   | 1 +
  fs/btrfs/super.c | 1 +
  fs/cifs/cifsfs.c | 1 +
  fs/coda/inode.c  | 1 +
  fs/cramfs/inode.c| 1 +
  fs/debugfs/inode.c   | 1 +
  fs/devpts/inode.c| 1 +
  fs/efs/super.c   | 1 +
  fs/ext2/super.c  | 1 +
  fs/ext3/super.c  | 2 ++
  fs/ext4/super.c  | 2 ++
  fs/f2fs/super.c  | 2 ++
  fs/fat/inode.c   | 2 ++
  fs/freevxfs/vxfs_super.c | 1 +
  fs/fuse/inode.c  | 1 +
  fs/gfs2/super.c  | 2 ++
  fs/hfs/super.c   | 1 +
  fs/hfsplus/super.c   | 1 +
  fs/hpfs/super.c  | 2 ++
  fs/isofs/inode.c | 1 +
  fs/jffs2/super.c | 1 +
  fs/jfs/super.c   | 1 +
  fs/minix/inode.c | 1 +
  fs/ncpfs/inode.c | 1 +
  fs/nfs/super.c   | 2 ++
  fs/nilfs2/super.c| 1 +
  fs/ntfs/super.c  | 2 ++
  fs/ocfs2/super.c | 2 ++
  fs/openpromfs/inode.c| 1 +
  fs/proc/root.c   | 2 ++
  fs/pstore/inode.c| 1 +
  fs/qnx4/inode.c  | 1 +
  fs/qnx6/inode.c  | 1 +
  fs/reiserfs/super.c  | 1 +
  fs/romfs/super.c | 1 +
  fs/squashfs/super.c  | 1 +
  fs/super.c   | 2 --
  fs/sysv/inode.c  | 1 +
  fs/ubifs/super.c | 1 +
  fs/udf/super.c   | 1 +
  fs/ufs/super.c   | 1 +
  fs/xfs/xfs_super.c   | 1 +
  44 files changed, 53 insertions(+), 2 deletions(-)
 
 diff --git a/fs/adfs/super.c b/fs/adfs/super.c
 index 7b3003c..952aeb0 100644
 --- a/fs/adfs/super.c
 +++ b/fs/adfs/super.c
 @@ -212,6 +212,7 @@ static int parse_options(struct super_block *sb, char 
 *options)
  
  static int adfs_remount(struct super_block *sb, int *flags, char *data)
  {
 + sync_filesystem(sb);
   *flags |= MS_NODIRATIME;
   return parse_options(sb, data);
  }
 diff --git a/fs/affs/super.c b/fs/affs/super.c
 index d098731..3074530 100644
 --- a/fs/affs/super.c
 +++ b/fs/affs/super.c
 @@ -530,6 +530,7 @@ affs_remount(struct super_block *sb, int *flags, char 
 *data)
  
   pr_debug(AFFS: remount(flags=0x%x,opts=\%s\)\n,*flags,data);
  
 + sync_filesystem(sb);
   *flags |= MS_NODIRATIME;
  
   memcpy(volume, sbi-s_volume, 32);
 diff --git a/fs/befs/linuxvfs.c b/fs/befs/linuxvfs.c
 index 845d2d6..56d70c8 100644
 --- a/fs/befs/linuxvfs.c
 +++ b/fs/befs/linuxvfs.c
 @@ -913,6 +913,7 @@ befs_fill_super(struct super_block *sb, void *data, int 
 silent)
  static int
  befs_remount(struct super_block *sb, int *flags, char *data)
  {
 + sync_filesystem(sb);
   if (!(*flags  MS_RDONLY))
   

[Ocfs2-devel] [PATCH -next] ocfs2: fix sparse non static symbol warning

2014-03-28 Thread Wei Yongjun
From: Wei Yongjun yongjun_...@trendmicro.com.cn

Fixes the following sparse warning:

fs/ocfs2/stack_user.c:930:32: warning:
 symbol 'ocfs2_ls_ops' was not declared. Should it be static?

Signed-off-by: Wei Yongjun yongjun_...@trendmicro.com.cn
---
 fs/ocfs2/stack_user.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs/ocfs2/stack_user.c b/fs/ocfs2/stack_user.c
index eca3f93..9b18f4e 100644
--- a/fs/ocfs2/stack_user.c
+++ b/fs/ocfs2/stack_user.c
@@ -927,7 +927,7 @@ static void user_recover_done(void *arg, struct dlm_slot 
*slots,
wake_up(lc-oc_wait);
 }
 
-const struct dlm_lockspace_ops ocfs2_ls_ops = {
+static const struct dlm_lockspace_ops ocfs2_ls_ops = {
.recover_prep = user_recover_prep,
.recover_slot = user_recover_slot,
.recover_done = user_recover_done,


___
Ocfs2-devel mailing list
Ocfs2-devel@oss.oracle.com
https://oss.oracle.com/mailman/listinfo/ocfs2-devel


Re: [Ocfs2-devel] [PATCH 00/24] treewide: Convert use of typedef ctl_table to struct ctl_table

2014-03-28 Thread Joe Perches
On Tue, 2013-10-22 at 16:53 -0700, David Daney wrote:
 After all this work, why not go ahead and remove the typedef?  That way 
 people won't add more users of this abomination.

Hi David.

The typedef can't be removed until all the uses are gone.

I've sent this before as a single large patch as well as
individual patches.

treewide:   https://lkml.org/lkml/2013/7/22/600
RemoveTypedef:  https://lkml.org/lkml/2013/7/22/603


___
Ocfs2-devel mailing list
Ocfs2-devel@oss.oracle.com
https://oss.oracle.com/mailman/listinfo/ocfs2-devel


[Ocfs2-devel] [PATCH 1/2] ocfs2: return ENOMEM while sb_getblk failing

2014-03-28 Thread Rui Xiang
The only reason for sb_getblk() failing is if it can't allocate
the buffer_head. So return ENOMEM instead when it fails.

Signed-off-by: Rui Xiang rui.xi...@huawei.com
---
 fs/ocfs2/alloc.c| 2 +-
 fs/ocfs2/aops.c | 1 +
 fs/ocfs2/dir.c  | 8 
 fs/ocfs2/namei.c| 2 +-
 fs/ocfs2/refcounttree.c | 6 +++---
 fs/ocfs2/suballoc.c | 4 ++--
 fs/ocfs2/super.c| 4 ++--
 fs/ocfs2/xattr.c| 2 +-
 8 files changed, 15 insertions(+), 14 deletions(-)

diff --git a/fs/ocfs2/alloc.c b/fs/ocfs2/alloc.c
index 17e6bdd..dc7411f 100644
--- a/fs/ocfs2/alloc.c
+++ b/fs/ocfs2/alloc.c
@@ -1025,7 +1025,7 @@ static int ocfs2_create_new_meta_bhs(handle_t *handle,
for(i = count;  i  (num_got + count); i++) {
bhs[i] = sb_getblk(osb-sb, first_blkno);
if (bhs[i] == NULL) {
-   status = -EIO;
+   status = -ENOMEM;
mlog_errno(status);
goto bail;
}
diff --git a/fs/ocfs2/aops.c b/fs/ocfs2/aops.c
index 2abf97b..ffcddfd 100644
--- a/fs/ocfs2/aops.c
+++ b/fs/ocfs2/aops.c
@@ -80,6 +80,7 @@ static int ocfs2_symlink_get_block(struct inode *inode, 
sector_t iblock,
 
if ((u64)iblock = ocfs2_clusters_to_blocks(inode-i_sb,

le32_to_cpu(fe-i_clusters))) {
+   err = -ENOMEM;
mlog(ML_ERROR, block offset is outside the allocated size: 
 %llu\n, (unsigned long long)iblock);
goto bail;
diff --git a/fs/ocfs2/dir.c b/fs/ocfs2/dir.c
index 30544ce..5354743 100644
--- a/fs/ocfs2/dir.c
+++ b/fs/ocfs2/dir.c
@@ -2349,7 +2349,7 @@ static int ocfs2_dx_dir_attach_index(struct ocfs2_super 
*osb,
 
dx_root_bh = sb_getblk(osb-sb, dr_blkno);
if (dx_root_bh == NULL) {
-   ret = -EIO;
+   ret = -ENOMEM;
goto out;
}
ocfs2_set_new_buffer_uptodate(INODE_CACHE(dir), dx_root_bh);
@@ -2422,7 +2422,7 @@ static int ocfs2_dx_dir_format_cluster(struct ocfs2_super 
*osb,
for (i = 0; i  num_dx_leaves; i++) {
bh = sb_getblk(osb-sb, start_blk + i);
if (bh == NULL) {
-   ret = -EIO;
+   ret = -ENOMEM;
goto out;
}
dx_leaves[i] = bh;
@@ -2929,7 +2929,7 @@ static int ocfs2_expand_inline_dir(struct inode *dir, 
struct buffer_head *di_bh,
blkno = ocfs2_clusters_to_blocks(dir-i_sb, bit_off);
dirdata_bh = sb_getblk(sb, blkno);
if (!dirdata_bh) {
-   ret = -EIO;
+   ret = -ENOMEM;
mlog_errno(ret);
goto out_commit;
}
@@ -3159,7 +3159,7 @@ static int ocfs2_do_extend_dir(struct super_block *sb,
 
*new_bh = sb_getblk(sb, p_blkno);
if (!*new_bh) {
-   status = -EIO;
+   status = -ENOMEM;
mlog_errno(status);
goto bail;
}
diff --git a/fs/ocfs2/namei.c b/fs/ocfs2/namei.c
index be3f867..4f791f6 100644
--- a/fs/ocfs2/namei.c
+++ b/fs/ocfs2/namei.c
@@ -489,7 +489,7 @@ static int __ocfs2_mknod_locked(struct inode *dir,
 
*new_fe_bh = sb_getblk(osb-sb, fe_blkno);
if (!*new_fe_bh) {
-   status = -EIO;
+   status = -ENOMEM;
mlog_errno(status);
goto leave;
}
diff --git a/fs/ocfs2/refcounttree.c b/fs/ocfs2/refcounttree.c
index a70d604..50c1796 100644
--- a/fs/ocfs2/refcounttree.c
+++ b/fs/ocfs2/refcounttree.c
@@ -1310,7 +1310,7 @@ static int ocfs2_expand_inline_ref_root(handle_t *handle,
 
new_bh = sb_getblk(sb, blkno);
if (new_bh == NULL) {
-   ret = -EIO;
+   ret = -ENOMEM;
mlog_errno(ret);
goto out;
}
@@ -1561,7 +1561,7 @@ static int ocfs2_new_leaf_refcount_block(handle_t *handle,
 
new_bh = sb_getblk(sb, blkno);
if (new_bh == NULL) {
-   ret = -EIO;
+   ret = -ENOMEM;
mlog_errno(ret);
goto out;
}
@@ -3031,7 +3031,7 @@ int ocfs2_duplicate_clusters_by_jbd(handle_t *handle,
for (i = 0; i  blocks; i++, old_block++, new_block++) {
new_bh = sb_getblk(osb-sb, new_block);
if (new_bh == NULL) {
-   ret = -EIO;
+   ret = -ENOMEM;
mlog_errno(ret);
break;
}
diff --git a/fs/ocfs2/suballoc.c b/fs/ocfs2/suballoc.c
index 5397c07..2c91452 100644
--- a/fs/ocfs2/suballoc.c
+++ b/fs/ocfs2/suballoc.c
@@ -481,7 +481,7 @@ ocfs2_block_group_alloc_contig(struct ocfs2_super *osb, 
handle_t *handle,
 
bg_bh = sb_getblk(osb-sb, bg_blkno);
if (!bg_bh) {
-   status = -EIO;
+  

[Ocfs2-devel] [PATCH] fs: push sync_filesystem() down to the file system's remount_fs()

2014-03-28 Thread Theodore Ts'o
Previously, the no-op mount -o mount /dev/xxx operation when the
file system is already mounted read-write causes an implied,
unconditional syncfs().  This seems pretty stupid, and it's certainly
documented or guaraunteed to do this, nor is it particularly useful,
except in the case where the file system was mounted rw and is getting
remounted read-only.

However, it's possible that there might be some file systems that are
actually depending on this behavior.  In most file systems, it's
probably fine to only call sync_filesystem() when transitioning from
read-write to read-only, and there are some file systems where this is
not needed at all (for example, for a pseudo-filesystem or something
like romfs).

Signed-off-by: Theodore Ts'o ty...@mit.edu
Cc: linux-fsde...@vger.kernel.org
Cc: Christoph Hellwig h...@infradead.org
Cc: Artem Bityutskiy dedeki...@gmail.com
Cc: Adrian Hunter adrian.hun...@intel.com
Cc: Evgeniy Dushistov dushis...@mail.ru
Cc: Jan Kara j...@suse.cz
Cc: OGAWA Hirofumi hirof...@mail.parknet.co.jp
Cc: Anders Larsen a...@alarsen.net
Cc: Phillip Lougher phil...@squashfs.org.uk
Cc: Kees Cook keesc...@chromium.org
Cc: Mikulas Patocka miku...@artax.karlin.mff.cuni.cz
Cc: Petr Vandrovec p...@vandrovec.name
Cc: x...@oss.sgi.com
Cc: linux-bt...@vger.kernel.org
Cc: linux-c...@vger.kernel.org
Cc: samba-techni...@lists.samba.org
Cc: codal...@coda.cs.cmu.edu
Cc: linux-e...@vger.kernel.org
Cc: linux-f2fs-de...@lists.sourceforge.net
Cc: fuse-de...@lists.sourceforge.net
Cc: cluster-de...@redhat.com
Cc: linux-...@lists.infradead.org
Cc: jfs-discuss...@lists.sourceforge.net
Cc: linux-...@vger.kernel.org
Cc: linux-ni...@vger.kernel.org
Cc: linux-ntfs-...@lists.sourceforge.net
Cc: ocfs2-devel@oss.oracle.com
Cc: reiserfs-de...@vger.kernel.org
---
 fs/adfs/super.c  | 1 +
 fs/affs/super.c  | 1 +
 fs/befs/linuxvfs.c   | 1 +
 fs/btrfs/super.c | 1 +
 fs/cifs/cifsfs.c | 1 +
 fs/coda/inode.c  | 1 +
 fs/cramfs/inode.c| 1 +
 fs/debugfs/inode.c   | 1 +
 fs/devpts/inode.c| 1 +
 fs/efs/super.c   | 1 +
 fs/ext2/super.c  | 1 +
 fs/ext3/super.c  | 2 ++
 fs/ext4/super.c  | 2 ++
 fs/f2fs/super.c  | 2 ++
 fs/fat/inode.c   | 2 ++
 fs/freevxfs/vxfs_super.c | 1 +
 fs/fuse/inode.c  | 1 +
 fs/gfs2/super.c  | 2 ++
 fs/hfs/super.c   | 1 +
 fs/hfsplus/super.c   | 1 +
 fs/hpfs/super.c  | 2 ++
 fs/isofs/inode.c | 1 +
 fs/jffs2/super.c | 1 +
 fs/jfs/super.c   | 1 +
 fs/minix/inode.c | 1 +
 fs/ncpfs/inode.c | 1 +
 fs/nfs/super.c   | 2 ++
 fs/nilfs2/super.c| 1 +
 fs/ntfs/super.c  | 2 ++
 fs/ocfs2/super.c | 2 ++
 fs/openpromfs/inode.c| 1 +
 fs/proc/root.c   | 2 ++
 fs/pstore/inode.c| 1 +
 fs/qnx4/inode.c  | 1 +
 fs/qnx6/inode.c  | 1 +
 fs/reiserfs/super.c  | 1 +
 fs/romfs/super.c | 1 +
 fs/squashfs/super.c  | 1 +
 fs/super.c   | 2 --
 fs/sysv/inode.c  | 1 +
 fs/ubifs/super.c | 1 +
 fs/udf/super.c   | 1 +
 fs/ufs/super.c   | 1 +
 fs/xfs/xfs_super.c   | 1 +
 44 files changed, 53 insertions(+), 2 deletions(-)

diff --git a/fs/adfs/super.c b/fs/adfs/super.c
index 7b3003c..952aeb0 100644
--- a/fs/adfs/super.c
+++ b/fs/adfs/super.c
@@ -212,6 +212,7 @@ static int parse_options(struct super_block *sb, char 
*options)
 
 static int adfs_remount(struct super_block *sb, int *flags, char *data)
 {
+   sync_filesystem(sb);
*flags |= MS_NODIRATIME;
return parse_options(sb, data);
 }
diff --git a/fs/affs/super.c b/fs/affs/super.c
index d098731..3074530 100644
--- a/fs/affs/super.c
+++ b/fs/affs/super.c
@@ -530,6 +530,7 @@ affs_remount(struct super_block *sb, int *flags, char *data)
 
pr_debug(AFFS: remount(flags=0x%x,opts=\%s\)\n,*flags,data);
 
+   sync_filesystem(sb);
*flags |= MS_NODIRATIME;
 
memcpy(volume, sbi-s_volume, 32);
diff --git a/fs/befs/linuxvfs.c b/fs/befs/linuxvfs.c
index 845d2d6..56d70c8 100644
--- a/fs/befs/linuxvfs.c
+++ b/fs/befs/linuxvfs.c
@@ -913,6 +913,7 @@ befs_fill_super(struct super_block *sb, void *data, int 
silent)
 static int
 befs_remount(struct super_block *sb, int *flags, char *data)
 {
+   sync_filesystem(sb);
if (!(*flags  MS_RDONLY))
return -EINVAL;
return 0;
diff --git a/fs/btrfs/super.c b/fs/btrfs/super.c
index 97cc241..00cd0c5 100644
--- a/fs/btrfs/super.c
+++ b/fs/btrfs/super.c
@@ -1381,6 +1381,7 @@ static int btrfs_remount(struct super_block *sb, int 
*flags, char *data)
unsigned int old_metadata_ratio = fs_info-metadata_ratio;
int ret;
 
+   sync_filesystem(sb);
btrfs_remount_prepare(fs_info);
 
ret = btrfs_parse_options(root, data);
diff --git a/fs/cifs/cifsfs.c b/fs/cifs/cifsfs.c
index 849f613..4942c94 100644
--- a/fs/cifs/cifsfs.c
+++ b/fs/cifs/cifsfs.c
@@ -541,6 +541,7 @@ 

[Ocfs2-devel] [PATCH] ocfs2: Do not write error flag to user structure we cannot copy from/to

2014-03-28 Thread Ben Hutchings
If we failed to copy from the structure, writing back the flags leaks
31 bits of kernel memory (the rest of the ir_flags field).

In any case, if we cannot copy from/to the structure, why should we
expect putting just the flags to work?

Also make sure ocfs2_info_handle_freeinode() returns the right error
code if the copy_to_user() fails.

Compile-tested only.

Signed-off-by: Ben Hutchings b...@decadent.org.uk
Cc: sta...@vger.kernel.org
Fixes: ddee5cdb70e6 ('Ocfs2: Add new OCFS2_IOC_INFO ioctl for ocfs2 v8.')
---
 fs/ocfs2/ioctl.c | 129 +++
 1 file changed, 43 insertions(+), 86 deletions(-)

diff --git a/fs/ocfs2/ioctl.c b/fs/ocfs2/ioctl.c
index fa32ce9..71e2492 100644
--- a/fs/ocfs2/ioctl.c
+++ b/fs/ocfs2/ioctl.c
@@ -34,9 +34,8 @@
copy_to_user((typeof(a) __user *)b, (a), sizeof(a))
 
 /*
- * This call is void because we are already reporting an error that may
- * be -EFAULT.  The error will be returned from the ioctl(2) call.  It's
- * just a best-effort to tell userspace that this request caused the error.
+ * This is just a best-effort to tell userspace that this request
+ * caused the error.
  */
 static inline void o2info_set_request_error(struct ocfs2_info_request *kreq,
struct ocfs2_info_request __user *req)
@@ -145,136 +144,105 @@ bail:
 int ocfs2_info_handle_blocksize(struct inode *inode,
struct ocfs2_info_request __user *req)
 {
-   int status = -EFAULT;
struct ocfs2_info_blocksize oib;
 
if (o2info_from_user(oib, req))
-   goto bail;
+   return -EFAULT;
 
oib.ib_blocksize = inode-i_sb-s_blocksize;
 
o2info_set_request_filled(oib.ib_req);
 
if (o2info_to_user(oib, req))
-   goto bail;
-
-   status = 0;
-bail:
-   if (status)
-   o2info_set_request_error(oib.ib_req, req);
+   return -EFAULT;
 
-   return status;
+   return 0;
 }
 
 int ocfs2_info_handle_clustersize(struct inode *inode,
  struct ocfs2_info_request __user *req)
 {
-   int status = -EFAULT;
struct ocfs2_info_clustersize oic;
struct ocfs2_super *osb = OCFS2_SB(inode-i_sb);
 
if (o2info_from_user(oic, req))
-   goto bail;
+   return -EFAULT;
 
oic.ic_clustersize = osb-s_clustersize;
 
o2info_set_request_filled(oic.ic_req);
 
if (o2info_to_user(oic, req))
-   goto bail;
-
-   status = 0;
-bail:
-   if (status)
-   o2info_set_request_error(oic.ic_req, req);
+   return -EFAULT;
 
-   return status;
+   return 0;
 }
 
 int ocfs2_info_handle_maxslots(struct inode *inode,
   struct ocfs2_info_request __user *req)
 {
-   int status = -EFAULT;
struct ocfs2_info_maxslots oim;
struct ocfs2_super *osb = OCFS2_SB(inode-i_sb);
 
if (o2info_from_user(oim, req))
-   goto bail;
+   return -EFAULT;
 
oim.im_max_slots = osb-max_slots;
 
o2info_set_request_filled(oim.im_req);
 
if (o2info_to_user(oim, req))
-   goto bail;
+   return -EFAULT;
 
-   status = 0;
-bail:
-   if (status)
-   o2info_set_request_error(oim.im_req, req);
-
-   return status;
+   return 0;
 }
 
 int ocfs2_info_handle_label(struct inode *inode,
struct ocfs2_info_request __user *req)
 {
-   int status = -EFAULT;
struct ocfs2_info_label oil;
struct ocfs2_super *osb = OCFS2_SB(inode-i_sb);
 
if (o2info_from_user(oil, req))
-   goto bail;
+   return -EFAULT;
 
memcpy(oil.il_label, osb-vol_label, OCFS2_MAX_VOL_LABEL_LEN);
 
o2info_set_request_filled(oil.il_req);
 
if (o2info_to_user(oil, req))
-   goto bail;
+   return -EFAULT;
 
-   status = 0;
-bail:
-   if (status)
-   o2info_set_request_error(oil.il_req, req);
-
-   return status;
+   return 0;
 }
 
 int ocfs2_info_handle_uuid(struct inode *inode,
   struct ocfs2_info_request __user *req)
 {
-   int status = -EFAULT;
struct ocfs2_info_uuid oiu;
struct ocfs2_super *osb = OCFS2_SB(inode-i_sb);
 
if (o2info_from_user(oiu, req))
-   goto bail;
+   return -EFAULT;
 
memcpy(oiu.iu_uuid_str, osb-uuid_str, OCFS2_TEXT_UUID_LEN + 1);
 
o2info_set_request_filled(oiu.iu_req);
 
if (o2info_to_user(oiu, req))
-   goto bail;
-
-   status = 0;
-bail:
-   if (status)
-   o2info_set_request_error(oiu.iu_req, req);
+   return -EFAULT;
 
-   return status;
+   return 0;
 }
 
 int ocfs2_info_handle_fs_features(struct inode *inode,
  struct 

Re: [Ocfs2-devel] [XFS on bad superblock] BUG: unable to handle kernel NULL pointer dereference at 00000003

2014-03-28 Thread Fengguang Wu
Dave,

 This is an easily reproducible bug. And I further confirmed it in
 two ways:

 1) turn off XFS, build 39 commits and boot them 2000+ times

 = no single mount error

That doesn't tell you it is an XFS error. Absence of symptoms !=
absence of bug.

True.

 2) turn off all other filesystems, build 2 kernels on v3.12-rc3
v3.12-rc4 and boot them
 
 = half boots have oops

Again, it doesn't tell you that it is an XFS bug. XFS is well known
for exposing bugs in less used block devices, and you are definitely
using devices that are unusual and not commonly tested by filesystem
developers (e.g. zram, nbd, etc).


Yeah, it's possible that your commit exposed a bug in the less used
nbd/zram devices.

 You need to refine the test down from throw shit at the wall, look
 at what sticks to a simple, reproducable test case. I can't
 reproduce your systems or testing, so you need to provide a test
 case I can use. Otherwise we're just wasting time

You may try the attached script. The initrd used in the script will be
sent to you in a private email. Here is an example run on my side:

wfg@bee /kernel/i386-randconfig-c4-0920-XFS/v3.12-rc4% kvm-0day.sh 
vmlinuz-3.12.0-rc4

[0.00] Initializing cgroup subsys cpuset
[0.00] Initializing cgroup subsys cpu
[0.00] Linux version 3.12.0-rc4 (kbuild@cairo) (gcc version 4.8.1 
(Debian 4.8.1-8) ) #2 Thu Oct 10 12:55:12 CST 2013
[0.00] e820: BIOS-provided physical RAM map:
[0.00] BIOS-e820: [mem 0x-0x0009fbff] usable
[0.00] BIOS-e820: [mem 0x0009fc00-0x0009] reserved
[0.00] BIOS-e820: [mem 0x000f-0x000f] reserved
[0.00] BIOS-e820: [mem 0x0010-0x0fffdfff] usable
[0.00] BIOS-e820: [mem 0x0fffe000-0x0fff] reserved
[0.00] BIOS-e820: [mem 0xfeffc000-0xfeff] reserved
[0.00] BIOS-e820: [mem 0xfffc-0x] reserved
[0.00] debug: ignoring loglevel setting.
[0.00] NX (Execute Disable) protection: active
[0.00] SMBIOS 2.4 present.
[0.00] DMI: Bochs Bochs, BIOS Bochs 01/01/2011
[0.00] Hypervisor detected: KVM
[0.00] e820: update [mem 0x-0x0fff] usable == reserved
[0.00] e820: remove [mem 0x000a-0x000f] usable
[0.00] e820: last_pfn = 0xfffe max_arch_pfn = 0x100
[0.00] MTRR default type: write-back
[0.00] MTRR fixed ranges enabled:
[0.00]   0-9 write-back
[0.00]   A-B uncachable
[0.00]   C-F write-protect
[0.00] MTRR variable ranges enabled:
[0.00]   0 base 008000 mask FF8000 uncachable
[0.00]   1 disabled
[0.00]   2 disabled
[0.00]   3 disabled
[0.00]   4 disabled
[0.00]   5 disabled
[0.00]   6 disabled
[0.00]   7 disabled
[0.00] x86 PAT enabled: cpu 0, old 0x70406, new 0x7010600070106
[0.00] Scan for SMP in [mem 0x-0x03ff]
[0.00] Scan for SMP in [mem 0x0009fc00-0x0009]
[0.00] Scan for SMP in [mem 0x000f-0x000f]
[0.00] found SMP MP-table at [mem 0x000f1840-0x000f184f] mapped at 
[c00f1840]
[0.00]   mpc: f1850-f193c
[0.00] initial memory mapped: [mem 0x-0x01ff]
[0.00] Base memory trampoline at [c009b000] 9b000 size 16384
[0.00] init_memory_mapping: [mem 0x-0x000f]
[0.00]  [mem 0x-0x000f] page 4k
[0.00] init_memory_mapping: [mem 0x0fa0-0x0fbf]
[0.00]  [mem 0x0fa0-0x0fbf] page 2M
[0.00] init_memory_mapping: [mem 0x0c00-0x0f9f]
[0.00]  [mem 0x0c00-0x0f9f] page 2M
[0.00] init_memory_mapping: [mem 0x0010-0x0bff]
[0.00]  [mem 0x0010-0x001f] page 4k
[0.00]  [mem 0x0020-0x0bff] page 2M
[0.00] init_memory_mapping: [mem 0x0fc0-0x0fffdfff]
[0.00]  [mem 0x0fc0-0x0fdf] page 2M
[0.00]  [mem 0x0fe0-0x0fffdfff] page 4k
[0.00] BRK [0x01ab4000, 0x01ab4fff] PGTABLE
[0.00] RAMDISK: [mem 0x0fce4000-0x0ffe]
[0.00] ACPI: RSDP 000f16b0 00014 (v00 BOCHS )
[0.00] ACPI: RSDT 0fffe3f0 00034 (v01 BOCHS  BXPCRSDT 0001 BXPC 
0001)
[0.00] ACPI: FACP 0f80 00074 (v01 BOCHS  BXPCFACP 0001 BXPC 
0001)
[0.00] ACPI: DSDT 0fffe430 01137 (v01   BXPC   BXDSDT 0001 INTL 
20100528)
[0.00] ACPI: FACS 0f40 00040
[0.00] ACPI: SSDT 06a0 00899 (v01 BOCHS  BXPCSSDT 0001 BXPC 
0001)
[0.00] ACPI: APIC 05b0 00080 (v01 BOCHS  BXPCAPIC 0001 BXPC 
0001)
[0.00] ACPI: HPET 0570 00038 (v01 BOCHS  BXPCHPET 0001 BXPC 
0001)
[0.00] ACPI: Local APIC address 0xfee0
[0.00] mapped APIC to b000 (fee0)
[

Re: [Ocfs2-devel] [XFS on bad superblock] BUG: unable to handle kernel NULL pointer dereference at 00000003

2014-03-28 Thread Fengguang Wu
On Thu, Oct 10, 2013 at 11:26:37AM +0800, Fengguang Wu wrote:
 Dave,
 
  I note that you have CONFIG_SLUB=y, which means that the cache slabs
  are shared with objects of other types. That means that the memory
  corruption problem is likely to be caused by one of the other
  filesystems that is probing the block device(s), not XFS.
 
 Good to know that, it would easy to test then: just turn off every
 other filesystems. I'll try it right away.

Seems that we don't even need to do that. A dig through the oops
database and I find stack dumps from other FS.

This happens in the kernel with same kconfig and commit 3.12-rc1.

[   51.205369] block nbd1: Attempted send on closed socket
[   51.214126] BUG: unable to handle kernel NULL pointer dereference at 0004
[   51.215640] IP: [c10343fb] pool_mayday_timeout+0x5f/0x9c
[   51.216262] *pdpt = 0ca90001 *pde =  
[   51.216262] Oops:  [#1] 
[   51.216262] CPU: 0 PID: 644 Comm: mount Not tainted 3.12.0-rc1 #2
[   51.216262] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
[   51.216262] task: ccffd7a0 ti: cca54000 task.ti: cca54000
[   51.216262] EIP: 0060:[c10343fb] EFLAGS: 0046 CPU: 0
[   51.216262] EIP is at pool_mayday_timeout+0x5f/0x9c
[   51.216262] EAX:  EBX: c1a81d50 ECX:  EDX: 
[   51.216262] ESI: cd0d303c EDI: cfff7054 EBP: cca55d2c ESP: cca55d18
[   51.216262]  DS: 007b ES: 007b FS:  GS: 0033 SS: 0068
[   51.216262] CR0: 8005003b CR2: 0004 CR3: 0ca0b000 CR4: 06b0
[   51.216262] DR0:  DR1:  DR2:  DR3: 
[   51.216262] DR6:  DR7: 
[   51.216262] Stack:
[   51.216262]  c1a81d60 cd0d303c 0100 c103439c cca55d58 cca55d3c c102cd96 
c1ba4700
[   51.216262]  cca55d58 cca55d6c c102cf7e c1a81d50 c1ba5110 c1ba4f10 cca55d58 
c103439c
[   51.216262]  cca55d58 cca55d58 0001 c1ba4588 0100 cca55d90 c1028f61 
0001
[   51.216262] Call Trace:
[   51.216262]  [c103439c] ? need_to_create_worker+0x32/0x32
[   51.216262]  [c102cd96] call_timer_fn.isra.39+0x16/0x60
[   51.216262]  [c102cf7e] run_timer_softirq+0x144/0x15e
[   51.216262]  [c103439c] ? need_to_create_worker+0x32/0x32
[   51.216262]  [c1028f61] __do_softirq+0x87/0x12b
[   51.216262]  [c10290c4] irq_exit+0x3a/0x48
[   51.216262]  [c1002918] do_IRQ+0x64/0x77
[   51.216262]  [c175fbac] common_interrupt+0x2c/0x31
[   51.216262]  [c12188ee] ? ocfs2_get_sector+0x14/0x1cd
[   51.216262]  [c1218b72] ocfs2_sb_probe+0xcb/0x7ca
[   51.216262]  [c107bb1c] ? bdi_lock_two+0x8/0x14
[   51.216262]  [c12cfc11] ? string.isra.4+0x26/0x89
[   51.216262]  [c121a7ba] ocfs2_fill_super+0x39/0xe84
[   51.216262]  [c12d1000] ? pointer.isra.15+0x23f/0x25b
[   51.216262]  [c12c3660] ? disk_name+0x20/0x65
[   51.216262]  [c109d8f6] mount_bdev+0x105/0x14d
[   51.216262]  [c1092aaa] ? slab_pre_alloc_hook.isra.66+0x1e/0x25
[   51.216262]  [c1095353] ? __kmalloc_track_caller+0xb8/0xe4
[   51.216262]  [c10ae5da] ? alloc_vfsmnt+0xdc/0xff
[   51.216262]  [c1217173] ocfs2_mount+0x10/0x12
[   51.216262]  [c121a781] ? ocfs2_handle_error+0xa2/0xa2
[   51.216262]  [c109dad1] mount_fs+0x55/0x123
[   51.216262]  [c10aef24] vfs_kern_mount+0x44/0xac
[   51.216262]  [c10b030a] do_mount+0x647/0x768
[   51.216262]  [c107b043] ? strndup_user+0x2c/0x3d
[   51.216262]  [c10b049c] SyS_mount+0x71/0xa0
[   51.216262]  [c175f074] syscall_call+0x7/0xb
[   51.216262] Code: 43 44 e8 7a 8c ff ff 58 5a 5b 5e 5f 5d c3 8b 43 10 8d 78 
fc 8d 43 10 89 45 ec 8d 47 04 3b 45 ec 74 ca 89 f8 e8 44 f0 ff ff 89 c1 8b 50 
04 83 7a 44 00 74 2c 8b 40 68 8d 71 68 39 f0 75 22 8b 72
[   51.216262] EIP: [c10343fb] pool_mayday_timeout+0x5f/0x9c SS:ESP 
0068:cca55d18
[   51.216262] CR2: 0004
[   51.216262] ---[ end trace 267272283b2d7610 ]---
[   51.216262] Kernel panic - not syncing: Fatal exception in interrupt

[3.244964] block nbd1: Attempted send on closed socket
[3.246243] block nbd1: Attempted send on closed socket
[3.247508] (mount,661,0):ocfs2_get_sector:1861 ERROR: status = -5
[3.248906] (mount,661,0):ocfs2_sb_probe:770 ERROR: status = -5
[3.250269] (mount,661,0):ocfs2_fill_super:1038 ERROR: superblock probe 
failed!
[3.252100] (mount,661,0):ocfs2_fill_super:1229 ERROR: status = -5
[3.253569] BUG: unable to handle kernel NULL pointer dereference at 0004
[3.255322] IP: [c1034850] process_one_work+0x1a/0x1cc
[3.256681] *pdpt = 0c950001 *pde =  
[3.256833] Oops:  [#1] 
[3.256833] CPU: 0 PID: 5 Comm: kworker/0:0H Not tainted 3.12.0-rc1 #2
[3.256833] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
[3.256833] task: cec44d80 ti: cec54000 task.ti: cec54000
[3.256833] EIP: 0060:[c1034850] EFLAGS: 00010046 CPU: 0
[3.256833] EIP is at process_one_work+0x1a/0x1cc
[3.256833] EAX:  EBX: cec1b900 ECX: ccdf0700 EDX: ccdf0700
[3.256833] ESI: ccdf0754 EDI: c1a81d50 EBP: cec55f44 ESP: cec55f2c
[3.256833]  DS: 007b ES: 007b FS:  GS:  SS: 

Re: [Ocfs2-devel] [XFS on bad superblock] BUG: unable to handle kernel NULL pointer dereference at 00000003

2014-03-28 Thread Fengguang Wu
On Thu, Oct 10, 2013 at 03:28:20PM +1100, Dave Chinner wrote:
 On Thu, Oct 10, 2013 at 11:38:34AM +0800, Fengguang Wu wrote:
  On Thu, Oct 10, 2013 at 11:33:00AM +0800, Fengguang Wu wrote:
   On Thu, Oct 10, 2013 at 11:26:37AM +0800, Fengguang Wu wrote:
Dave,

 I note that you have CONFIG_SLUB=y, which means that the cache slabs
 are shared with objects of other types. That means that the memory
 corruption problem is likely to be caused by one of the other
 filesystems that is probing the block device(s), not XFS.

Good to know that, it would easy to test then: just turn off every
other filesystems. I'll try it right away.
   
   Seems that we don't even need to do that. A dig through the oops
   database and I find stack dumps from other FS.
   
   This happens in the kernel with same kconfig and commit 3.12-rc1.
  
  Here is a summary of all FS with oops:
  
  411 ocfs2_fill_super
  189 xfs_fs_fill_super
   86 jfs_fill_super
   50 isofs_fill_super
   33 fat_fill_super
   18 vfat_fill_super
   15 msdos_fill_super
   11 ext2_fill_super
   10 ext3_fill_super
3 reiserfs_fill_super
 
 The order of probing on the original dmesg output you reported is:
 
   ext3
   ext2
   fatfs
   reiserfs
   gfs2
   isofs
   ocfs2

There are effectively no particular order, because there are many
superblocks for these filesystems to scan.

for superblocks:
for filesystems:
scan super block

In the end, any filesystem may impact the other (and perhaps a later
run of itself).

 which means that no XFS filesystem was mounted in the original bug
 report, and hence that further indicates that XFS is not responsible
 for the problem and that perhaps the original bisect was not
 reliable...

This is an easily reproducible bug. And I further confirmed it in
two ways:

1) turn off XFS, build 39 commits and boot them 2000+ times

= no single mount error

2) turn off all other filesystems, build 2 kernels on v3.12-rc3
   v3.12-rc4 and boot them

= half boots have oops

So it may well be that XFS is impacted by an early run of itself.

Thanks,
Fengguang

___
Ocfs2-devel mailing list
Ocfs2-devel@oss.oracle.com
https://oss.oracle.com/mailman/listinfo/ocfs2-devel


Re: [Ocfs2-devel] [XFS on bad superblock] BUG: unable to handle kernel NULL pointer dereference at 00000003

2014-03-28 Thread Fengguang Wu
On Thu, Oct 10, 2013 at 11:33:00AM +0800, Fengguang Wu wrote:
 On Thu, Oct 10, 2013 at 11:26:37AM +0800, Fengguang Wu wrote:
  Dave,
  
   I note that you have CONFIG_SLUB=y, which means that the cache slabs
   are shared with objects of other types. That means that the memory
   corruption problem is likely to be caused by one of the other
   filesystems that is probing the block device(s), not XFS.
  
  Good to know that, it would easy to test then: just turn off every
  other filesystems. I'll try it right away.
 
 Seems that we don't even need to do that. A dig through the oops
 database and I find stack dumps from other FS.
 
 This happens in the kernel with same kconfig and commit 3.12-rc1.

Here is a summary of all FS with oops:

411 ocfs2_fill_super
189 xfs_fs_fill_super
 86 jfs_fill_super
 50 isofs_fill_super
 33 fat_fill_super
 18 vfat_fill_super
 15 msdos_fill_super
 11 ext2_fill_super
 10 ext3_fill_super
  3 reiserfs_fill_super

Thanks,
Fengguang

___
Ocfs2-devel mailing list
Ocfs2-devel@oss.oracle.com
https://oss.oracle.com/mailman/listinfo/ocfs2-devel


[Ocfs2-devel] ocfs2: Fix panic on kfree(xattr-name)

2014-03-28 Thread Srinivas Eeda
Hi Andrew,

can you please pull the following patch from Tetsuo Handa. It fixes a
regression in ocfs2/mainline and linux-next

Thanks,
--Srini


___
Ocfs2-devel mailing list
Ocfs2-devel@oss.oracle.com
https://oss.oracle.com/mailman/listinfo/ocfs2-devel


[Ocfs2-devel] [PATCH 1/1] ocfs2: Fix panic on kfree(xattr-name)

2014-03-28 Thread Srinivas Eeda
From: Tetsuo Handa penguin-ker...@i-love.sakura.ne.jp

Commit 9548906b 'xattr: Constify -name member of struct xattr.' missed that
ocfs2 is calling kfree(xattr-name). As a result, kernel panic occurs upon
calling kfree(xattr-name) because xattr-name refers static constant names.
This patch removes kfree(xattr-name) from ocfs2_mknod() and ocfs2_symlink().

Reported-by: Tariq Saeed tariq.x.sa...@oracle.com
Signed-off-by: Tetsuo Handa penguin-ker...@i-love.sakura.ne.jp
Reviewed-by: Srinivas Eeda srinivas.e...@oracle.com
---
 fs/ocfs2/namei.c |2 --
 1 file changed, 2 deletions(-)

diff --git a/fs/ocfs2/namei.c b/fs/ocfs2/namei.c
index 3683643..feed025f 100644
--- a/fs/ocfs2/namei.c
+++ b/fs/ocfs2/namei.c
@@ -450,7 +450,6 @@ leave:
 
brelse(new_fe_bh);
brelse(parent_fe_bh);
-   kfree(si.name);
kfree(si.value);
 
ocfs2_free_dir_lookup_result(lookup);
@@ -1855,7 +1854,6 @@ bail:
 
brelse(new_fe_bh);
brelse(parent_fe_bh);
-   kfree(si.name);
kfree(si.value);
ocfs2_free_dir_lookup_result(lookup);
if (inode_ac)
-- 
1.7.9.5


___
Ocfs2-devel mailing list
Ocfs2-devel@oss.oracle.com
https://oss.oracle.com/mailman/listinfo/ocfs2-devel