lkml.org 
[lkml]   [2001]   [Oct]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] devfs v194 available
Alexander Viro writes:
> ... doesn't fix _under_run in try_modload() (see what happens if
> namelen is 255 and parent is devfs root)

What underrun?
How can this be a problem? Before I use pos, I have the following
check:
if (namelen >= STRING_LENGTH) return -ENAMETOOLONG;

so the maximum value that namelen can be is STRING_LENGTH-1. Thus we
have:
pos = STRING_LENGTH - (STRING_LENGTH - 1) - 1;
-> pos = 0;

> ... doesn't fix the deadlock introduced into -pre6 in place of symlink
> races. That
>
> /* Need to follow the link: this is a stack chomper */
> down_read (&symlink_rwsem);
> retval = curr->registered ?
> search_for_entry (parent, curr->u.symlink.linkname,
> curr->u.symlink.length, FALSE, FALSE, NULL,
> TRUE) : NULL;
> up_read (&symlink_rwsem);
>
> is a fairly bad idea. Think what happens if somebody else tries to
> acquire symlink_rwsem for write between two calls of down_read() in
> that recursion.

Where is the problem? After the first call to down_read(), anyone
calling down_write() will block, which is fine. Then the second call
to down_read() should still work, right? Once the recursion unwinds,
the semaphore will be released and whoever is waiting on down_write()
will unblock.

There should be no code paths where there is recursion between
down_read() and down_write() (otherwise we *would* have a deadlock).

Ah, shit. I just checked the rwsem implementation. It seems that once
we do a down_write() (even if that blocks because someone else has a
down_read() already), subsequent down_read() calls will block until
the writer is granted access and then does up_write(). Damn. It would
have been good for this to be documented somewhere. Those are the
kinds of traps that should be mentioned in the header file.

OK: is there a variant of rwsem which is "unfair" (i.e. readers can
starve writers indefinately)?

Regards,

Richard....
Permanent: rgooch@atnf.csiro.au
Current: rgooch@ras.ucalgary.ca
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:05    [W:0.071 / U:0.816 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site