* Re: [PATCH] 2.4.9-ac10 but not only, locks_alloc_lock()
@ 2001-09-09 9:25 Manfred Spraul
2001-09-09 10:33 ` Francis Galiegue
0 siblings, 1 reply; 3+ messages in thread
From: Manfred Spraul @ 2001-09-09 9:25 UTC (permalink / raw)
To: Francis Galiegue; +Cc: linux-kernel
> Not sure about one thing, though: what error code to return for
> locks_mandatory_area() on failure. It's invoked from some of the
> {do,sys}_*{read,write}*() routines and nowhere else AFAICT. I set it
to
> -ENOMEM, maybe this is not the right thing to do.
I'd put the file_lock structure on the stack. It's ~ 90 bytes long, not
too large.
Returning -ENOMEM is imho not acceptable: -ENOMEM is not listed in
SusV2, and locks_alloc_lock() internally checks for rlimits (setting
RLIM_NLIMITS to 0 and execing another app might have dangerous
sideeffects).
--
Manfred
^ permalink raw reply [flat|nested] 3+ messages in thread* Re: [PATCH] 2.4.9-ac10 but not only, locks_alloc_lock()
2001-09-09 9:25 [PATCH] 2.4.9-ac10 but not only, locks_alloc_lock() Manfred Spraul
@ 2001-09-09 10:33 ` Francis Galiegue
0 siblings, 0 replies; 3+ messages in thread
From: Francis Galiegue @ 2001-09-09 10:33 UTC (permalink / raw)
To: Manfred Spraul; +Cc: linux-kernel, alan, damien.clermonte
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1033 bytes --]
On Sun, 9 Sep 2001, Manfred Spraul wrote:
>
> > Not sure about one thing, though: what error code to return for
> > locks_mandatory_area() on failure. It's invoked from some of the
> > {do,sys}_*{read,write}*() routines and nowhere else AFAICT. I set it
> > to -ENOMEM, maybe this is not the right thing to do.
>
> I'd put the file_lock structure on the stack. It's ~ 90 bytes long, not
> too large.
> Returning -ENOMEM is imho not acceptable: -ENOMEM is not listed in
> SusV2, and locks_alloc_lock() internally checks for rlimits (setting
> RLIM_NLIMITS to 0 and execing another app might have dangerous
> sideeffects).
>
Not sure about what you mean wrt RLIM_NLIMITS, anyway a new patch is
attached with follows your suggestion. Does it look correct?
--
Francis Galiegue, fg@mandrakesoft.com - Normand et fier de l'être
"Programming is a race between programmers, who try and make more and more
idiot-proof software, and universe, which produces more and more remarkable
idiots. Until now, universe leads the race" -- R. Cook
[-- Attachment #2: Type: TEXT/PLAIN, Size: 2124 bytes --]
diff -urN linux-old/fs/locks.c linux/fs/locks.c
--- linux-old/fs/locks.c Sun Sep 9 09:00:06 2001
+++ linux/fs/locks.c Sun Sep 9 12:12:02 2001
@@ -695,16 +695,18 @@
size_t count)
{
struct file_lock *fl;
- struct file_lock *new_fl = locks_alloc_lock(0);
+ struct file_lock new_fl;
int error;
- new_fl->fl_owner = current->files;
- new_fl->fl_pid = current->pid;
- new_fl->fl_file = filp;
- new_fl->fl_flags = FL_POSIX | FL_ACCESS;
- new_fl->fl_type = (read_write == FLOCK_VERIFY_WRITE) ? F_WRLCK : F_RDLCK;
- new_fl->fl_start = offset;
- new_fl->fl_end = offset + count - 1;
+ memset(&new_fl, 0, sizeof(new_fl));
+
+ new_fl.fl_owner = current->files;
+ new_fl.fl_pid = current->pid;
+ new_fl.fl_file = filp;
+ new_fl.fl_flags = FL_POSIX | FL_ACCESS;
+ new_fl.fl_type = (read_write == FLOCK_VERIFY_WRITE) ? F_WRLCK : F_RDLCK;
+ new_fl.fl_start = offset;
+ new_fl.fl_end = offset + count - 1;
error = 0;
lock_kernel();
@@ -716,17 +718,17 @@
for (fl = inode->i_flock; fl != NULL; fl = fl->fl_next) {
if (!(fl->fl_flags & FL_POSIX))
continue;
- if (fl->fl_start > new_fl->fl_end)
+ if (fl->fl_start > new_fl.fl_end)
break;
- if (posix_locks_conflict(new_fl, fl)) {
+ if (posix_locks_conflict(&new_fl, fl)) {
error = -EAGAIN;
if (filp && (filp->f_flags & O_NONBLOCK))
break;
error = -EDEADLK;
- if (posix_locks_deadlock(new_fl, fl))
+ if (posix_locks_deadlock(&new_fl, fl))
break;
- error = locks_block_on(fl, new_fl);
+ error = locks_block_on(fl, &new_fl);
if (error != 0)
break;
@@ -739,7 +741,6 @@
goto repeat;
}
}
- locks_free_lock(new_fl);
unlock_kernel();
return error;
}
@@ -1411,6 +1412,9 @@
struct inode *inode;
int error;
+ if (file_lock == NULL)
+ return -ENOLCK;
+
/*
* This might block, so we do it before checking the inode.
*/
@@ -1563,6 +1567,9 @@
struct flock64 flock;
struct inode *inode;
int error;
+
+ if (file_lock == NULL)
+ return -ENOLCK;
/*
* This might block, so we do it before checking the inode.
^ permalink raw reply [flat|nested] 3+ messages in thread
* [PATCH] 2.4.9-ac10 but not only, locks_alloc_lock()
@ 2001-09-09 8:19 Francis Galiegue
0 siblings, 0 replies; 3+ messages in thread
From: Francis Galiegue @ 2001-09-09 8:19 UTC (permalink / raw)
To: linux-kernel; +Cc: alan, damien.clermonte
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1620 bytes --]
Also affects: 2.4.7, 2.4.9-ac{4,6,9}, probably others.
Problem: in locks_mandatory_area(), fcntl_setlk(), fcntl_setlk64(), no
check whether locks_alloc_lock() succeeds. Attached patch fixes that.
Not sure about one thing, though: what error code to return for
locks_mandatory_area() on failure. It's invoked from some of the
{do,sys}_*{read,write}*() routines and nowhere else AFAICT. I set it to
-ENOMEM, maybe this is not the right thing to do.
Patch follows and is attached. Made over 2.4.9-ac10, applies cleanly
over -ac's mentioned above and with offests (1 to 3 lines) on 2.4.7 and
2.4.9.
diff -urN linux-old/fs/locks.c linux/fs/locks.c
--- linux-old/fs/locks.c Sun Sep 9 09:00:06 2001
+++ linux/fs/locks.c Sun Sep 9 09:21:07 2001
@@ -698,6 +698,9 @@
struct file_lock *new_fl = locks_alloc_lock(0);
int error;
+ if (new_fl == NULL)
+ return -ENOMEM;
+
new_fl->fl_owner = current->files;
new_fl->fl_pid = current->pid;
new_fl->fl_file = filp;
@@ -1411,6 +1414,9 @@
struct inode *inode;
int error;
+ if (file_lock == NULL)
+ return -ENOLCK;
+
/*
* This might block, so we do it before checking the inode.
*/
@@ -1563,6 +1569,9 @@
struct flock64 flock;
struct inode *inode;
int error;
+
+ if (file_lock == NULL)
+ return -ENOLCK;
/*
* This might block, so we do it before checking the inode.
--
Francis Galiegue, fg@mandrakesoft.com - Normand et fier de l'être
"Programming is a race between programmers, who try and make more and more
idiot-proof software, and universe, which produces more and more remarkable
idiots. Until now, universe leads the race" -- R. Cook
[-- Attachment #2: Type: TEXT/PLAIN, Size: 777 bytes --]
diff -urN linux-old/fs/locks.c linux/fs/locks.c
--- linux-old/fs/locks.c Sun Sep 9 09:00:06 2001
+++ linux/fs/locks.c Sun Sep 9 09:21:07 2001
@@ -698,6 +698,9 @@
struct file_lock *new_fl = locks_alloc_lock(0);
int error;
+ if (new_fl == NULL)
+ return -ENOMEM;
+
new_fl->fl_owner = current->files;
new_fl->fl_pid = current->pid;
new_fl->fl_file = filp;
@@ -1411,6 +1414,9 @@
struct inode *inode;
int error;
+ if (file_lock == NULL)
+ return -ENOLCK;
+
/*
* This might block, so we do it before checking the inode.
*/
@@ -1563,6 +1569,9 @@
struct flock64 flock;
struct inode *inode;
int error;
+
+ if (file_lock == NULL)
+ return -ENOLCK;
/*
* This might block, so we do it before checking the inode.
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2001-09-09 10:33 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2001-09-09 9:25 [PATCH] 2.4.9-ac10 but not only, locks_alloc_lock() Manfred Spraul
2001-09-09 10:33 ` Francis Galiegue
-- strict thread matches above, loose matches on Subject: below --
2001-09-09 8:19 Francis Galiegue
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox