date:20160913

[Ocfs2-devel] [PATCH] ocfs2: fix double unlock in case retry after free truncate log

2016-09-13 Thread Joseph Qi

If ocfs2_reserve_cluster_bitmap_bits fails with ENOSPC, it will try to
free truncate log and then retry. Since ocfs2_try_to_free_truncate_log
will lock/unlock global bitmap inode, we have to unlock it before
calling this function. But when retry reserve and it fails with no
global bitmap inode lock taken, it will unlock again in error handling
branch and BUG.
This issue also exists if no need retry and then ocfs2_inode_lock fails.
So fix it.

Fixes: 2070ad1aebff ("ocfs2: retry on ENOSPC if sufficient space in
truncate log"
Signed-off-by: Jospeh Qi 
Signed-off-by: Jiufei Xue 
---
 fs/ocfs2/suballoc.c | 13 +++--
 1 file changed, 11 insertions(+), 2 deletions(-)

diff --git a/fs/ocfs2/suballoc.c b/fs/ocfs2/suballoc.c
index ea47120..041453b 100644
--- a/fs/ocfs2/suballoc.c
+++ b/fs/ocfs2/suballoc.c
@@ -1199,14 +1199,23 @@ retry:
inode_unlock((*ac)->ac_inode);

ret = ocfs2_try_to_free_truncate_log(osb, bits_wanted);
-   if (ret == 1)
+   if (ret == 1) {
+   iput((*ac)->ac_inode);
+   (*ac)->ac_inode = NULL;
goto retry;
+   }

if (ret < 0)
mlog_errno(ret);

inode_lock((*ac)->ac_inode);
-   ocfs2_inode_lock((*ac)->ac_inode, NULL, 1);
+   status = ocfs2_inode_lock((*ac)->ac_inode, NULL, 1);
+   if (status < 0) {
+   inode_unlock((*ac)->ac_inode);
+   iput((*ac)->ac_inode);
+   (*ac)->ac_inode = NULL;
+   goto bail;
+   }
}
if (status < 0) {
if (status != -ENOSPC)
-- 
1.8.4.3


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

[Ocfs2-devel] 答复: [PATCH] ocfs2: oldmle should be put while -EEXIST returned, and the new mle should not be get once at that time.

2016-09-13 Thread Guozhonghua

Hi, Joseph

I reviewed the patch of 32e493265b2b.
If the ret is --EEXIST, the oldmle will not be put.

As the fucntion dlm_add_migration_mle called, the return value is -EEXIST.
The oldmle had been gotten once and goto fail.

The fail code, ret is -EEXIST, so there is not anyway for the oldmle to be put.
fail:
if (ret != -EEXIST && oldmle) {
/* master is known, detach if not already detached */
dlm_mle_detach_hb_events(dlm, oldmle);
dlm_put_mle(oldmle);
}

Same thing, the new mle is allocated
It will not initialized with the ret --EEXIST while call dlm_add_migration_mle.
So it is wrong to call dlm_get_mle_inuse(mle) for the new mle before goto fail.

I review these code and find that is not well.
Please have a check, and your comments will be good for me.
Thank You.

-
本邮件及其附件含有杭州华三通信技术有限公司的保密信息，仅限于发送给上面地址中列出
的个人或群组。禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、
或散发）本邮件中的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本
邮件！
This e-mail and its attachments contain confidential information from H3C,
which is
intended only for the person or entity whose address is listed above. Any use
of the
information contained herein in any way (including, but not limited to, total
or partial
disclosure, reproduction, or dissemination) by persons other than the intended
recipient(s) is prohibited. If you receive this e-mail in error, please notify
the sender
by phone or email immediately and delete it!
___
Ocfs2-devel mailing list
Ocfs2-devel@oss.oracle.com
https://oss.oracle.com/mailman/listinfo/ocfs2-devel

Re: [Ocfs2-devel] [PATCH] ocfs2: oldmle should be put while -EEXIST returned, and the new mle should not be get once at that time.

2016-09-13 Thread Joseph Qi

NAK. This has already been fixed by commit 32e493265b2b ("ocfs2/dlm:
do not insert a new mle when another process is already migrating").
Please submit patch based on the latest kernel.

Thanks,
Joseph

On 2016/9/14 10:30, Guozhonghua wrote:
> 
> In the function dlm_migrate_lockres, while calling dlm_add_migration_mle, and 
> the ret is --EEXIST.
> At this time, the oldmle should be put one time for it had been get once in 
> dlm_find_mle.
> And the new mle should not get once for it had not been initialized before 
> goto fail.
> 
> Signed-off-by: Guozhonghua 
> 
> --- ocfs2.orig/dlm/dlmmaster.c  2016-09-13 15:18:13.602684325 +0800
> +++ ocfs2/dlm/dlmmaster.c   2016-09-14 10:15:10.496873879 +0800
> @@ -2573,8 +2573,6 @@ static int dlm_is_lockres_migrateable(st
>  /*
>   * DLM_MIGRATE_LOCKRES
>   */
> -
> -
>  static int dlm_migrate_lockres(struct dlm_ctxt *dlm,
>struct dlm_lock_resource *res, u8 target)
>  {
> @@ -2621,20 +2619,26 @@ static int dlm_migrate_lockres(struct dl
> spin_lock(&dlm->master_lock);
> ret = dlm_add_migration_mle(dlm, res, mle, &oldmle, name,
> namelen, target, dlm->node_num);
> +   if (ret == -EEXIST) {
> +   if(oldmle)
> +   __dlm_put_mle(oldmle);
> +
> +   spin_unlock(&dlm->master_lock);
> +   spin_unlock(&dlm->spinlock);
> +   mlog(0, "another process is already migrating it\n");
> +   goto fail;
> +   }
> +
> /* get an extra reference on the mle.
>  * otherwise the assert_master from the new
>  * master will destroy this.
>  */
> dlm_get_mle_inuse(mle);
> +   mle_added = 1;
> +
> spin_unlock(&dlm->master_lock);
> spin_unlock(&dlm->spinlock);
> 
> -   if (ret == -EEXIST) {
> -   mlog(0, "another process is already migrating it\n");
> -   goto fail;
> -   }
> -   mle_added = 1;
> -
> /*
>  * set the MIGRATING flag and flush asts
>  * if we fail after this we need to re-dirty the lockres
> 
> -
> 本邮件及其附件含有杭州华三通信技术有限公司的保密信息，仅限于发送给上面地址中列出
> 的个人或群组。禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、
> 或散发）本邮件中的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本
> 邮件！
> This e-mail and its attachments contain confidential information from H3C, 
> which is
> intended only for the person or entity whose address is listed above. Any use 
> of the
> information contained herein in any way (including, but not limited to, total 
> or partial
> disclosure, reproduction, or dissemination) by persons other than the intended
> recipient(s) is prohibited. If you receive this e-mail in error, please 
> notify the sender
> by phone or email immediately and delete it!
> ___
> Ocfs2-devel mailing list
> Ocfs2-devel@oss.oracle.com
> https://oss.oracle.com/mailman/listinfo/ocfs2-devel
> 



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

[Ocfs2-devel] [PATCH] ocfs2: oldmle should be put while -EEXIST returned, and the new mle should not be get once at that time.

2016-09-13 Thread Guozhonghua


In the function dlm_migrate_lockres, while calling dlm_add_migration_mle, and 
the ret is --EEXIST.
At this time, the oldmle should be put one time for it had been get once in 
dlm_find_mle.
And the new mle should not get once for it had not been initialized before goto 
fail.

Signed-off-by: Guozhonghua 

--- ocfs2.orig/dlm/dlmmaster.c  2016-09-13 15:18:13.602684325 +0800
+++ ocfs2/dlm/dlmmaster.c   2016-09-14 10:15:10.496873879 +0800
@@ -2573,8 +2573,6 @@ static int dlm_is_lockres_migrateable(st
 /*
  * DLM_MIGRATE_LOCKRES
  */
-
-
 static int dlm_migrate_lockres(struct dlm_ctxt *dlm,
   struct dlm_lock_resource *res, u8 target)
 {
@@ -2621,20 +2619,26 @@ static int dlm_migrate_lockres(struct dl
spin_lock(&dlm->master_lock);
ret = dlm_add_migration_mle(dlm, res, mle, &oldmle, name,
namelen, target, dlm->node_num);
+   if (ret == -EEXIST) {
+   if(oldmle)
+   __dlm_put_mle(oldmle);
+
+   spin_unlock(&dlm->master_lock);
+   spin_unlock(&dlm->spinlock);
+   mlog(0, "another process is already migrating it\n");
+   goto fail;
+   }
+
/* get an extra reference on the mle.
 * otherwise the assert_master from the new
 * master will destroy this.
 */
dlm_get_mle_inuse(mle);
+   mle_added = 1;
+
spin_unlock(&dlm->master_lock);
spin_unlock(&dlm->spinlock);

-   if (ret == -EEXIST) {
-   mlog(0, "another process is already migrating it\n");
-   goto fail;
-   }
-   mle_added = 1;
-
/*
 * set the MIGRATING flag and flush asts
 * if we fail after this we need to re-dirty the lockres

-
本邮件及其附件含有杭州华三通信技术有限公司的保密信息，仅限于发送给上面地址中列出
的个人或群组。禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、
或散发）本邮件中的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本
邮件！
This e-mail and its attachments contain confidential information from H3C, 
which is
intended only for the person or entity whose address is listed above. Any use 
of the
information contained herein in any way (including, but not limited to, total 
or partial
disclosure, reproduction, or dissemination) by persons other than the intended
recipient(s) is prohibited. If you receive this e-mail in error, please notify 
the sender
by phone or email immediately and delete it!
___
Ocfs2-devel mailing list
Ocfs2-devel@oss.oracle.com
https://oss.oracle.com/mailman/listinfo/ocfs2-devel

Re: [Ocfs2-devel] [PATCH] ocfs2: free the mle while the res had one, to avoid mle memory leak.

2016-09-13 Thread Joseph Qi

Hi Andrew,
-EEXIST can only happen in case of "I am the master". So
dlm_migrate_request_handler won't get this return value.
I think commit 32e493265b2b ("ocfs2/dlm: do not insert a new mle when
another process is already migrating") has already considered the
case.
So NAK.

Thanks,
Joseph

On 2016/9/14 5:20, Andrew Morton wrote:
> On Tue, 13 Sep 2016 07:52:30 + Guozhonghua  wrote:
> 
>> In the function dlm_migrate_request_handler, while the ret is --EEXIST, the 
>> mle should be freed, otherwise the memory will be leaked.
>>
>> Signed-off-by: Guozhonghua 
>>
>> --- ocfs2.orig/dlm/dlmmaster.c  2016-09-13 15:18:13.602684325 +0800
>> +++ ocfs2/dlm/dlmmaster.c   2016-09-13 15:27:05.014675736 +0800
>> @@ -3188,6 +3188,9 @@ int dlm_migrate_request_handler(struct o
>> migrate->new_master,
>> migrate->master);
>>
>> +   if (ret < 0)
>> +   kmem_cache_free(dlm_mle_cache, mle);
>> +
>> spin_unlock(&dlm->master_lock);
>>  unlock:
>> spin_unlock(&dlm->spinlock);
> 
> Looks OK to me.
> 
> I wonder if there's another bug here.  If dlm_add_migration_mle()
> failed, is it correct to go ahead and detach `oldmle'?
> 
> 
> ___
> Ocfs2-devel mailing list
> Ocfs2-devel@oss.oracle.com
> https://oss.oracle.com/mailman/listinfo/ocfs2-devel
> 
> 



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

Re: [Ocfs2-devel] [PATCH] ocfs2: free the mle while the res had one, to avoid mle memory leak.

2016-09-13 Thread Andrew Morton

On Tue, 13 Sep 2016 07:52:30 + Guozhonghua  wrote:

> In the function dlm_migrate_request_handler, while the ret is --EEXIST, the 
> mle should be freed, otherwise the memory will be leaked.
> 
> Signed-off-by: Guozhonghua 
> 
> --- ocfs2.orig/dlm/dlmmaster.c  2016-09-13 15:18:13.602684325 +0800
> +++ ocfs2/dlm/dlmmaster.c   2016-09-13 15:27:05.014675736 +0800
> @@ -3188,6 +3188,9 @@ int dlm_migrate_request_handler(struct o
> migrate->new_master,
> migrate->master);
> 
> +   if (ret < 0)
> +   kmem_cache_free(dlm_mle_cache, mle);
> +
> spin_unlock(&dlm->master_lock);
>  unlock:
> spin_unlock(&dlm->spinlock);

Looks OK to me.

I wonder if there's another bug here.  If dlm_add_migration_mle()
failed, is it correct to go ahead and detach `oldmle'?


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

Re: [Ocfs2-devel] [PATCH] ocfs2: free the mle while the res had one, to avoid mle memory leak.

2016-09-13 Thread Eric Ren

Hi,
On 09/13/2016 03:52 PM, Guozhonghua wrote:
> In the function dlm_migrate_request_handler, while the ret is --EEXIST, the 
> mle should be freed, otherwise the memory will be leaked.
Keep your commit comments within 75 or 78 (I don't remember clearly but git 
will warn
if you don't keep its rule) characters per line.
>
> Signed-off-by: Guozhonghua 
>
> --- ocfs2.orig/dlm/dlmmaster.c  2016-09-13 15:18:13.602684325 +0800
Please use `git format-patch` to create patch. FYI:
http://wiki.openhatch.org/How_to_generate_patches_with_git_format-patch

Sorry, I don't familiar with ocfs2/dlm code, so cannot review this patch.

Eric
> +++ ocfs2/dlm/dlmmaster.c   2016-09-13 15:27:05.014675736 +0800
> @@ -3188,6 +3188,9 @@ int dlm_migrate_request_handler(struct o
>  migrate->new_master,
>  migrate->master);
>
> +   if (ret < 0)
> +   kmem_cache_free(dlm_mle_cache, mle);
> +
>  spin_unlock(&dlm->master_lock);
>   unlock:
>  spin_unlock(&dlm->spinlock);
>
>
> -
> 本邮件及其附件含有杭州华三通信技术有限公司的保密信息，仅限于发送给上面地址中列出
> 的个人或群组。禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、
> 或散发）本邮件中的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本
> 邮件！
> This e-mail and its attachments contain confidential information from H3C, 
> which is
> intended only for the person or entity whose address is listed above. Any use 
> of the
> information contained herein in any way (including, but not limited to, total 
> or partial
> disclosure, reproduction, or dissemination) by persons other than the intended
> recipient(s) is prohibited. If you receive this e-mail in error, please 
> notify the sender
> by phone or email immediately and delete it!
> ___
> Ocfs2-devel mailing list
> Ocfs2-devel@oss.oracle.com
> https://oss.oracle.com/mailman/listinfo/ocfs2-devel


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

Re: [Ocfs2-devel] [Ocfs2-users] ocf2 mount point hangs

2016-09-13 Thread Eric Ren

Hi,

On 09/13/2016 03:16 PM, Ishmael Tsoaela wrote:
> Hi All,
>
> I have an ocfs2  mount point of 3 ceph cluster nodes and suddenly I
> cannot read and write to the mount point although the cluster is clean
> and showing no errors.
1. What is your ocfs2 shared disk? I mean it's a shared disk exported by iscsi 
target, or a 
ceph rbd device?
2. Did you check if ocfs2 works well before any read/write? and how?
3. Could you elaborating more details how the ceph nodes use ocfs2?
4. Please provide the output of:
#sudo debugfs.ocfs2 -R stats /dev/sda
>
>
> Are the any other logs I can check?
All log messages should go to /var/log/messages, could you attach the whole log 
file?

Eric
>
> There are some log in kern.log about
>
>
> kern.log
>
> Sep 13 08:10:18 nodeB kernel: [1104431.300882] kernel BUG at
> /build/linux-lts-wily-Vv6Eyd/linux-lts-wily-4.2.0/fs/ocfs2/suballoc.c:2419!
> Sep 13 08:10:18 nodeB kernel: [1104431.345504] invalid opcode:  [#1] SMP
> Sep 13 08:10:18 nodeB kernel: [1104431.370081] Modules linked in:
> vhost_net vhost macvtap macvlan ocfs2 quota_tree rbd libceph ipmi_si
> mpt3sas mpt2sas raid_class scsi_transport_sas mptctl mptbase
> xt_CHECKSUM iptable_mangle ipt_MASQUERADE nf_nat_masquerade_ipv4
> iptable_nat nf_nat_ipv4 nf_nat nf_conntrack_ipv4 nf_defrag_ipv4
> xt_conntrack nf_conntrack ipt_REJECT nf_reject_ipv4 xt_tcpudp
> ebtable_filter ebtables ip6table_filter ip6_tables iptable_filter
> ip_tables x_tables dell_rbu ocfs2_dlmfs ocfs2_stack_o2cb ocfs2_dlm
> ocfs2_nodemanager ocfs2_stackglue configfs bridge stp llc binfmt_misc
> ipmi_devintf kvm_amd dcdbas kvm input_leds joydev amd64_edac_mod
> crct10dif_pclmul edac_core shpchp i2c_piix4 fam15h_power crc32_pclmul
> edac_mce_amd ipmi_ssif k10temp aesni_intel aes_x86_64 lrw gf128mul
> 8250_fintek glue_helper acpi_power_meter mac_hid serio_raw ablk_helper
> cryptd ipmi_msghandler xfs libcrc32c lp parport ixgbe dca hid_generic
> uas usbhid vxlan usb_storage ip6_udp_tunnel hid udp_tunnel ptp psmouse
> bnx2 pps_core megaraid_sas mdio [last unloaded: ipmi_si]
> Sep 13 08:10:18 nodeB kernel: [1104431.898986] CPU: 10 PID: 65016
> Comm: cp Not tainted 4.2.0-27-generic #32~14.04.1-Ubuntu
> Sep 13 08:10:18 nodeB kernel: [1104432.012469] Hardware name: Dell
> Inc. PowerEdge R515/0RMRF7, BIOS 2.0.2 10/22/2012
> Sep 13 08:10:18 nodeB kernel: [1104432.134659] task: 880a61dca940
> ti: 88084a5ac000 task.ti: 88084a5ac000
> Sep 13 08:10:18 nodeB kernel: [1104432.265260] RIP:
> 0010:[]  []
> _ocfs2_free_suballoc_bits+0x4db/0x4e0 [ocfs2]
> Sep 13 08:10:18 nodeB kernel: [1104432.406559] RSP:
> 0018:88084a5af798  EFLAGS: 00010246
> Sep 13 08:10:18 nodeB kernel: [1104432.479958] RAX: 
> RBX: 881acebcb000 RCX: 881fcd372e00
> Sep 13 08:10:18 nodeB kernel: [1104432.630768] RDX: 881fd0d4dc30
> RSI: 88197e351bc8 RDI: 880fd127b2b0
> Sep 13 08:10:18 nodeB kernel: [1104432.789688] RBP: 88084a5af818
> R08: 0002 R09: 7e00
> Sep 13 08:10:18 nodeB kernel: [1104432.950053] R10: 880d39a21020
> R11: 88084a5af550 R12: 00fa
> Sep 13 08:10:18 nodeB kernel: [1104433.113014] R13: 5ab1
> R14:  R15: 880fb2d43000
> Sep 13 08:10:18 nodeB kernel: [1104433.276484] FS:
> 7fcc68373840() GS:881fdde8()
> knlGS:
> Sep 13 08:10:18 nodeB kernel: [1104433.440016] CS:  0010 DS:  ES:
>  CR0: 8005003b
> Sep 13 08:10:18 nodeB kernel: [1104433.521496] CR2: 5647b2ee6d80
> CR3: 000198b93000 CR4: 000406e0
> Sep 13 08:10:18 nodeB kernel: [1104433.681357] Stack:
> Sep 13 08:10:18 nodeB kernel: [1104433.758498]  
> 880fd127b2e8 881fc6655f08 5bab
> Sep 13 08:10:18 nodeB kernel: [1104433.913655]  881fd0c51d80
> 88197e351bc8 880fd127b330 880e9eaa6000
> Sep 13 08:10:18 nodeB kernel: [1104434.068609]  88197e351bc8
> 817ba6d6 0001 1ac592b1
> Sep 13 08:10:18 nodeB kernel: [1104434.223347] Call Trace:
> Sep 13 08:10:18 nodeB kernel: [1104434.298560]  [] ?
> mutex_lock+0x16/0x37
> Sep 13 08:10:18 nodeB kernel: [1104434.374183]  []
> _ocfs2_free_clusters+0xea/0x200 [ocfs2]
> Sep 13 08:10:18 nodeB kernel: [1104434.449628]  [] ?
> ocfs2_put_slot+0xe0/0xe0 [ocfs2]
> Sep 13 08:10:18 nodeB kernel: [1104434.523971]  [] ?
> ocfs2_put_slot+0xe0/0xe0 [ocfs2]
> Sep 13 08:10:18 nodeB kernel: [1104434.595803]  []
> ocfs2_free_clusters+0x15/0x20 [ocfs2]
> Sep 13 08:10:18 nodeB kernel: [1104434.14]  []
> __ocfs2_flush_truncate_log+0x247/0x560 [ocfs2]
> Sep 13 08:10:18 nodeB kernel: [1104434.806017]  [] ?
> ocfs2_num_free_extents+0x56/0x120 [ocfs2]
> Sep 13 08:10:18 nodeB kernel: [1104434.946141]  []
> ocfs2_remove_btree_range+0x4e8/0x760 [ocfs2]
> Sep 13 08:10:18 nodeB kernel: [1104435.086490]  []
> ocfs2_commit_truncate+0x180/0x590 [ocfs2]
> Sep 13 08:10:18 nodeB kernel: [1104435.158189]  [] ?
> ocfs2_allocate_extend_trans+0x130/0x130 [oc

[Ocfs2-devel] [PATCH] ocfs2: free the mle while the res had one, to avoid mle memory leak.

2016-09-13 Thread Guozhonghua

In the function dlm_migrate_request_handler, while the ret is --EEXIST, the mle 
should be freed, otherwise the memory will be leaked.

Signed-off-by: Guozhonghua 

--- ocfs2.orig/dlm/dlmmaster.c  2016-09-13 15:18:13.602684325 +0800
+++ ocfs2/dlm/dlmmaster.c   2016-09-13 15:27:05.014675736 +0800
@@ -3188,6 +3188,9 @@ int dlm_migrate_request_handler(struct o
migrate->new_master,
migrate->master);

+   if (ret < 0)
+   kmem_cache_free(dlm_mle_cache, mle);
+
spin_unlock(&dlm->master_lock);
 unlock:
spin_unlock(&dlm->spinlock);


-
本邮件及其附件含有杭州华三通信技术有限公司的保密信息，仅限于发送给上面地址中列出
的个人或群组。禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、
或散发）本邮件中的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本
邮件！
This e-mail and its attachments contain confidential information from H3C, 
which is
intended only for the person or entity whose address is listed above. Any use 
of the
information contained herein in any way (including, but not limited to, total 
or partial
disclosure, reproduction, or dissemination) by persons other than the intended
recipient(s) is prohibited. If you receive this e-mail in error, please notify 
the sender
by phone or email immediately and delete it!
___
Ocfs2-devel mailing list
Ocfs2-devel@oss.oracle.com
https://oss.oracle.com/mailman/listinfo/ocfs2-devel

[Ocfs2-devel] [PATCH] ocfs2: fix double unlock in case retry after free truncate log

[Ocfs2-devel] 答复: [PATCH] ocfs2: oldmle should be put while -EEXIST returned, and the new mle should not be get once at that time.

Re: [Ocfs2-devel] [PATCH] ocfs2: oldmle should be put while -EEXIST returned, and the new mle should not be get once at that time.

[Ocfs2-devel] [PATCH] ocfs2: oldmle should be put while -EEXIST returned, and the new mle should not be get once at that time.

Re: [Ocfs2-devel] [PATCH] ocfs2: free the mle while the res had one, to avoid mle memory leak.

Re: [Ocfs2-devel] [PATCH] ocfs2: free the mle while the res had one, to avoid mle memory leak.

Re: [Ocfs2-devel] [PATCH] ocfs2: free the mle while the res had one, to avoid mle memory leak.

Re: [Ocfs2-devel] [Ocfs2-users] ocf2 mount point hangs

[Ocfs2-devel] [PATCH] ocfs2: free the mle while the res had one, to avoid mle memory leak.

9 matches

Site Navigation

Mail list logo

Footer information