On 09/13/2007 03:34 PM, J. Bruce Fields wrote:
>> Doesn't that create a leak in some cases?
>>
>>> for_each_lock(inode, before) {
>>> struct file_lock *fl = *before;
>>> if (IS_POSIX(fl))
>>> break;
>>> if
On Thu, Sep 13, 2007 at 03:27:08PM -0400, Chuck Ebbert wrote:
> On 09/11/2007 08:38 AM, Pavel Emelyanov wrote:
> > diff --git a/fs/locks.c b/fs/locks.c
> > index 0db1a14..f59d066 100644
> > --- a/fs/locks.c
> > +++ b/fs/locks.c
> > @@ -732,6 +732,14 @@ static int flock_lock_file(struct file *
> >
On 09/11/2007 08:38 AM, Pavel Emelyanov wrote:
> When the flock_lock_file() is called to change the flock
> from F_RDLCK to F_WRLCK or vice versa the existing flock
> can be removed without appropriate warning.
>
> Look:
> for_each_lock(inode, before) {
> struct file_lock
On 9/13/07, Pavel Emelyanov <[EMAIL PROTECTED]> wrote:
> J. Bruce Fields wrote:
> > On Tue, Sep 11, 2007 at 04:38:13PM +0400, Pavel Emelyanov wrote:
> >> This is a known feature that such "re-locking" is not atomic,
> >> but in the racy case the file should stay locked (although by
> >> some other
J. Bruce Fields wrote:
> On Tue, Sep 11, 2007 at 04:38:13PM +0400, Pavel Emelyanov wrote:
>> This is a known feature that such "re-locking" is not atomic,
>> but in the racy case the file should stay locked (although by
>> some other process), but in this case the file will be unlocked.
>
>
J. Bruce Fields wrote:
On Tue, Sep 11, 2007 at 04:38:13PM +0400, Pavel Emelyanov wrote:
This is a known feature that such re-locking is not atomic,
but in the racy case the file should stay locked (although by
some other process), but in this case the file will be unlocked.
That's a little
On 9/13/07, Pavel Emelyanov [EMAIL PROTECTED] wrote:
J. Bruce Fields wrote:
On Tue, Sep 11, 2007 at 04:38:13PM +0400, Pavel Emelyanov wrote:
This is a known feature that such re-locking is not atomic,
but in the racy case the file should stay locked (although by
some other process), but
On 09/11/2007 08:38 AM, Pavel Emelyanov wrote:
When the flock_lock_file() is called to change the flock
from F_RDLCK to F_WRLCK or vice versa the existing flock
can be removed without appropriate warning.
Look:
for_each_lock(inode, before) {
struct file_lock *fl =
On Thu, Sep 13, 2007 at 03:27:08PM -0400, Chuck Ebbert wrote:
On 09/11/2007 08:38 AM, Pavel Emelyanov wrote:
diff --git a/fs/locks.c b/fs/locks.c
index 0db1a14..f59d066 100644
--- a/fs/locks.c
+++ b/fs/locks.c
@@ -732,6 +732,14 @@ static int flock_lock_file(struct file *
On 09/13/2007 03:34 PM, J. Bruce Fields wrote:
Doesn't that create a leak in some cases?
for_each_lock(inode, before) {
struct file_lock *fl = *before;
if (IS_POSIX(fl))
break;
if (IS_LEASE(fl))
On Tue, Sep 11, 2007 at 04:38:13PM +0400, Pavel Emelyanov wrote:
> This is a known feature that such "re-locking" is not atomic,
> but in the racy case the file should stay locked (although by
> some other process), but in this case the file will be unlocked.
That's a little subtle (I assume
On Tue, Sep 11, 2007 at 04:38:13PM +0400, Pavel Emelyanov wrote:
This is a known feature that such re-locking is not atomic,
but in the racy case the file should stay locked (although by
some other process), but in this case the file will be unlocked.
That's a little subtle (I assume you've
When the flock_lock_file() is called to change the flock
from F_RDLCK to F_WRLCK or vice versa the existing flock
can be removed without appropriate warning.
Look:
for_each_lock(inode, before) {
struct file_lock *fl = *before;
if (IS_POSIX(fl))
When the flock_lock_file() is called to change the flock
from F_RDLCK to F_WRLCK or vice versa the existing flock
can be removed without appropriate warning.
Look:
for_each_lock(inode, before) {
struct file_lock *fl = *before;
if (IS_POSIX(fl))
14 matches
Mail list logo
