diff for duplicates of <1CFAE5F0-5E46-4B1D-A9EC-2D6286753A35@linuxhacker.ru>
diff --git a/a/1.txt b/N1/1.txt
index 54be0cf..a202852 100644
--- a/a/1.txt
+++ b/N1/1.txt
@@ -3,7 +3,7 @@ On Jul 3, 2016, at 11:08 PM, Al Viro wrote:
> On Sun, Jul 03, 2016 at 08:37:22PM -0400, Oleg Drokin wrote:
>
->> Hm… This dates to sometime in 2006 and my memory is a bit hazy here.
+>> Hm� This dates to sometime in 2006 and my memory is a bit hazy here.
>>
>> I think when we called into the open, it went into fifo open and stuck there
>> waiting for the other opener. Something like that. And we cannot really be stuck here
@@ -54,14 +54,14 @@ I'll create a patch to cover this anyway. Thanks for reminding me about this.
> d_instantiate(*de, inode);
> }
-Hm… Do you mean that when we do come hashed here, with a negative dentry
+Hm� Do you mean that when we do come hashed here, with a negative dentry
and positive disposition and hit the assertion about inode not being NULL
(still staying negative, basically)?
This one we cannot hit because negative dentries are protected by a Lustre
dlm lock held by the parent directory. Any create in that parent directory
would invalidate the lock and once that happens, all negative dentries would
be killed.
-Hmm… This probably means this is a dead code?
+Hmm� This probably means this is a dead code?
Ah, I guess it's not.
If we do a lookup and find this negative dentry (from 2+ threads) and THEN it gets invalidated and our two threads both race to instantiate it...
It does look like something that is quite hard to hit, but still looks like a race
diff --git a/a/content_digest b/N1/content_digest
index 662b1f3..27a3558 100644
--- a/a/content_digest
+++ b/N1/content_digest
@@ -47,7 +47,7 @@
"\n",
"> On Sun, Jul 03, 2016 at 08:37:22PM -0400, Oleg Drokin wrote:\n",
"> \n",
- ">> Hm\342\200\246 This dates to sometime in 2006 and my memory is a bit hazy here.\n",
+ ">> Hm\303\257\302\277\302\275 This dates to sometime in 2006 and my memory is a bit hazy here.\n",
">> \n",
">> I think when we called into the open, it went into fifo open and stuck there\n",
">> waiting for the other opener. Something like that. And we cannot really be stuck here\n",
@@ -98,14 +98,14 @@
"> d_instantiate(*de, inode);\n",
"> }\n",
"\n",
- "Hm\342\200\246 Do you mean that when we do come hashed here, with a negative dentry\n",
+ "Hm\303\257\302\277\302\275 Do you mean that when we do come hashed here, with a negative dentry\n",
"and positive disposition and hit the assertion about inode not being NULL\n",
"(still staying negative, basically)?\n",
"This one we cannot hit because negative dentries are protected by a Lustre\n",
"dlm lock held by the parent directory. Any create in that parent directory\n",
"would invalidate the lock and once that happens, all negative dentries would\n",
"be killed.\n",
- "Hmm\342\200\246 This probably means this is a dead code?\n",
+ "Hmm\303\257\302\277\302\275 This probably means this is a dead code?\n",
"Ah, I guess it's not.\n",
"If we do a lookup and find this negative dentry (from 2+ threads) and THEN it gets invalidated and our two threads both race to instantiate it...\n",
"It does look like something that is quite hard to hit, but still looks like a race\n",
@@ -173,4 +173,4 @@
">"
]
-940d6f05170244b90217009ce7b80c79f9d589dcb2d777afaeb2e2ee6c6830f8
+37a1fe9e36f287aa13b10985381e0138fa19d64b7d0e588a1cb7893c417e37b6
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.