search for: lockname

...++ b/fs/ocfs2/dlm/dlmthread.c @@ -158,15 +158,6 @@ static int dlm_purge_lockres(struct dlm_ctxt *dlm, int master; int ret = 0; - spin_lock(&res->spinlock); - if (!__dlm_lockres_unused(res)) { - mlog(0, "%s:%.*s: tried to purge but not unused\n", - dlm->name, res->lockname.len, res->lockname.name); - __dlm_print_one_lock_resource(res); - spin_unlock(&res->spinlock); - BUG(); - } - if (res->state & DLM_LOCK_RES_MIGRATING) { mlog(0, "%s:%.*s: Delay dropref as this lockres is " "being remastered\n", dlm->name, res-...

Hello, Our static analysis tool finds some possible data races in the OCFS2 file system in Linux 6.4.0-rc6. In most calling contexts, the variables such as res->lockname.name and res->owner are accessed with holding the lock res->spinlock. Here is an example: lockres_seq_start() --> Line 539 in dlmdebug.c spin_lock(&res->spinlock); --> Line 574 in dlmdebug.c (Lock res->spinlock) dump_lockres(res, ...); --> Line 575 in fs/ocfs2/dl...

Hi, On 6/13/23 4:23 PM, Tuo Li wrote: > Hello, > > Our static analysis tool finds some possible data races in the OCFS2 file > system in Linux 6.4.0-rc6. > > In most calling contexts, the variables such as res->lockname.name and > res->owner are accessed with holding the lock res->spinlock. Here is an > example: > > lockres_seq_start() --> Line 539 in dlmdebug.c > spin_lock(&res->spinlock); --> Line 574 in dlmdebug.c (Lock > res->spinlock) > dump_lockres(res, ....

This patch makes the following needlessly global functions static: - stringify_lockname() - dlm_debug_put() Signed-off-by: Adrian Bunk <bunk at kernel.org> --- fs/ocfs2/dlm/dlmdebug.c | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) fec83555cf8467e5c932fa52177b8f567eb84d94 diff --git a/fs/ocfs2/dlm/dlmdebug.c b/fs/ocfs2/dlm/dlmdebug.c index 5f6d858..1b81dcb...

Hello, Our static analysis tool finds some possible data races in the OCFS2 file system in Linux 6.4.0-rc6. In most calling contexts, the variables? such as res->lockname.name and res->owner are accessed with holding the lock res->spinlock. Here is an example: ? lockres_seq_start() --> Line 539 in dlmdebug.c ??? spin_lock(&res->spinlock); --> Line 574 in dlmdebug.c (Lock res->spinlock) ??? dump_lockres(res, ...); --> Line 575 in fs/ocfs...

The changes from the last drop are: 1. Patch 11 removes struct dlm_lock_name. 2. Patch 12 is an unrelated bugfix. Actually is related to a bugfix that we are retracting in mainline currently. The patch may need more testing. While I did hit the condition in my testing, Marcos hasn't. I am sending it because it can be queued for 2.6.30. Give us more time to test. 3. Patch 13 will be useful

These patches convert the mle list to a hash. The same patches apply on ocfs2 1.4 too. Currently, we use the same number of hash pages for mles and lockres'. This will be addressed in a future patch that will make both of them configurable. Sunil

.../fs/ocfs2/dlm/dlmrecovery.c index bcb9260..43e6e32 100644 --- a/fs/ocfs2/dlm/dlmrecovery.c +++ b/fs/ocfs2/dlm/dlmrecovery.c @@ -1118,7 +1118,7 @@ static int dlm_send_mig_lockres_msg(struct dlm_ctxt *dlm, mlog(0, "%s:%.*s: sending mig lockres (%s) to %u\n", dlm->name, res->lockname.len, res->lockname.name, - orig_flags & DLM_MRES_MIGRATION ? "migrate" : "recovery", + orig_flags & DLM_MRES_MIGRATION ? "migration" : "recovery", send_to); /* send it */ -- 1.5.4.3

Please review the list of patches being applied to the ocfs2 1.4 tree. All patches list the mainline commit hash. Thanks Sunil

Hi, The following patches comprise the bulk of Ocfs2 updates for the 2.6.30 merge window. Aside from larger, more involved fixes, we're adding the following features, which I will describe in the order their patches are mailed. Sunil's exported some more state to our debugfs files, and consolidated some other aspects of our debugfs infrastructure. This will further aid us in debugging

...ckres' into a debugfs file ocfs2/dlm: Move struct dlm_master_list_entry to dlmcommon.h ocfs2/dlm: Dumps the mles into a debugfs file ocfs2/dlm: Dumps the purgelist into a debugfs file ocfs2/dlm: Move dlm_print_one_mle() from dlmmaster.c to dlmdebug.c ocfs2/dlm: Fix lockname in lockres print function ocfs2/dlm: Cleanup lockres print Tao Ma (6): ocfs2: Reconnect after idle time out. ocfs2: Add support for cross extent block ocfs2: Enable cross extent block merge. ocfs2: Add a new parameter for ocfs2_reserve_suballoc_bits ocfs2: Add...

Found 15 patches (out of 162) that appeared relevant to ocfs2 1.4. Please review. Sunil

Hello all. I''ve recently installed the 0.2.2 pre-release of mongrel_cluster to try out the new --clean option. However, after installing, when I give a simple "mongrel_rails" command, the cluster::status command is not listed. The error I receive when I do try and run the full "mongrel_rails cluster::status" is... ERROR RUNNING

Hi there, I was doing great with R, ggplot and tikzDevice, when suddenly it stopped working. I can do a plot just fine on the R online graphics device. I can also open a tikzdevice via tikz(). However, the plot (both ggplot and R graphics plot) call leads to the error: "createLockFile(lockname): cannot create lock file" I see that this is related to my OS, namely Ubuntu 10.04. I already checked if I have write access to /var/lock via touch /var/lock/test && rm -f /var/lock/test which gave no errors... Now my actual question: How can I inspect which file R wants to create...

Mainline commit d4f7e650e55af6b235871126f747da88600e8040 attempts to delay the dlm_thread from sending the drop ref message if the lockres is being migrated. The problem is that we make the dlm_thread wait for the migration to complete. This causes a deadlock as dlm_thread also participates in the lockres migration process. A better fix for the original oss bugzilla#1012 is in testing.

...; +out_free: + dlm_free_pagevec(vec, i); + return NULL; +} + /* * ocfs2 node maps are array of long int, which limits to send them freely * across the wire due to endianness issues. To workaround this, we convert @@ -127,7 +155,7 @@ void __dlm_insert_lockres(struct dlm_ctx q = &res->lockname; q->hash = full_name_hash(q->name, q->len); - bucket = &(dlm->lockres_hash[q->hash % DLM_HASH_BUCKETS]); + bucket = dlm_lockres_hash(dlm, q->hash); /* get a reference for our hashtable */ dlm_lockres_get(res); @@ -151,7 +179,7 @@ struct dlm_lock_resource * __dlm_lookup...

...page(GFP_KERNEL); + if (!vec[i]) + goto out_free; + } + return vec; +out_free: + dlm_free_pagevec(vec, i); + return NULL; + +} + /* * * spinlock lock ordering: if multiple locks are needed, obey this ordering: @@ -127,7 +154,7 @@ void __dlm_insert_lockres(struct dlm_ctx q = &res->lockname; q->hash = full_name_hash(q->name, q->len); - bucket = &(dlm->lockres_hash[q->hash % DLM_HASH_BUCKETS]); + bucket = dlm_lockres_hash(dlm, q->hash); /* get a reference for our hashtable */ dlm_lockres_get(res); @@ -151,7 +178,7 @@ struct dlm_lock_resource * __dlm_lookup...

Wether the dlm_lock needs to access lvb or not depends on dlm_lock_resource it belongs to. So a new parameter "struct dlm_lock_resource *res" is added to dlm_new_lock() so that we can know if we need to allocate lvb for the dlm_lock. And we have to make the lockres availale for calling dlm_new_lock(). Signed-off-by: Wengang Wang <wen.gang.wang at oracle.com> ---

...{ - res = list_entry (iter, struct dlm_lock_resource, recovering); + list_for_each_entry_safe(res, next, &dlm->reco.resources, recovering) { /* always prune any $RECOVERY entries for dead nodes, * otherwise hangs can occur during later recovery */ if (dlm_is_recovery_lock(res->lockname.name, @@ -1252,7 +1238,7 @@ int dlm_send_one_lockres(struct dlm_ctxt struct dlm_migratable_lockres *mres, u8 send_to, u8 flags) { - struct list_head *queue, *iter; + struct list_head *queue; int total_locks, i; u64 mig_cookie = 0; struct dlm_lock *lock; @@ -1278,9 +1264,7 @@ int dl...