| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <4C62D73E.6090302@genband.com> Date: Wed, 11 Aug 2010 11:00:46 -0600 From: Chris Friesen <chris.friesen@...band.com> To: Rob Donovan <rob@...ivrc.com> CC: linux-kernel@...r.kernel.org Subject: Re: FCNTL Performance problem On 08/11/2010 10:19 AM, Rob Donovan wrote: > Hi, > > Not sure it's about read or write 'priority' so much is it? > > I wouldn't want to particularly favour writes over reads either, or it will > just make the problem happen for reads wouldn't it? No, because readers can always share the lock with other readers if there is no writer waiting. If you have one or more readers already holding the lock, with a writer waiting, you have two choices: 1) let the new reader in under the assumption that they'll be quick and won't extend the current "read" usage by much, or 2) block the new reader until after any waiting writers get a chance to get in. The first is called reader priority, the second is writer priority. > And to do this, and make it favour writes, I presume it would have to be > coded into the kernel to do this, there isn't any 'switch' for me to try? The locks are written by glibc and the kernel. I haven't looked at fcntl locking so I'm not sure where the bulk of the code is. I'd suspect in the kernel. > Could we not have it 'fairly' process locks? So that if a read lock comes > along, and there is a write lock waiting for another read lock to unlock, > then the 2nd read has to wait for the write lock. Not particularly because > the write lock has priority, but because it was requested after the write > lock was. The behaviour you describe is called "writer priority". > To me, it seems like there needs to be something in the fcntl() routines so > that when a lock is called with F_SETLKW, if it gets blocked then it needs > to put its 'request' in some kind of queue, so that if any more reads come > along, they know there is already a lock waiting to get the lock before it, > so they queue up behind it. Again, this would be implementing writer priority. POSIX doesn't guarantee either form, so if you need a writer-priority lock then fcntl() isn't a good choice. In fact in most cases I suspect you'll find that read/write locks are implemented as reader priority since the expectation is that writes are infrequent. Chris -- Chris Friesen Software Developer GENBAND chris.friesen@...band.com www.genband.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists