linux-kernel - Re: [PATCH] Replace completions with semaphores

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Sat, 12 Apr 2008 13:04:24 -0600
From:	Matthew Wilcox <matthew@....cx>
To:	Peter Zijlstra <peterz@...radead.org>
Cc:	Ingo Oeser <ioe-lkml@...eria.de>,
	Daniel Walker <dwalker@...sta.com>,
	linux-kernel@...r.kernel.org, Ingo Molnar <mingo@...e.hu>,
	Linus Torvalds <torvalds@...l.org>
Subject: Re: [PATCH] Replace completions with semaphores

On Sat, Apr 12, 2008 at 08:05:49PM +0200, Peter Zijlstra wrote:
> On Sat, 2008-04-12 at 11:26 -0600, Matthew Wilcox wrote:
> >  We can continue the
> > discussion about eliminating one or the other API, but my opinion is that
> > eliminating either is a mistake.  The choice of API indicates how the
> > author thinks about the code, which is crucial for those reading the code.
> 
> Which is exactly the point, semaphores are rarely the right tool for the
> job (I'm currently only aware of XFS that actually uses them as actual
> semaphores, and the driver model that uses it to get around lockdep -
> still need to come up with a good solution for that).

I guess you haven't grepped the tree recently then.  We have 11 places
which call sema_init with a number other than 0 or 1 as the second
argument:

./fs/xfs/linux-2.6/sema.h:#define initnsema(sp, val, name)      sema_init(sp, val)
./drivers/net/mlx4/cmd.c:       sema_init(&priv->cmd.event_sem, priv->cmd.max_cmds);
./drivers/char/viotape.c:       sema_init(&reqSem, VIOTAPE_MAXREQ);
./drivers/infiniband/hw/mthca/mthca_cmd.c:      sema_init(&dev->cmd.event_sem, dev->cmd.max_cmds);
./drivers/acpi/osl.c:   sema_init(sem, initial_units);
./drivers/scsi/megaraid/megaraid_sas.c: sema_init(&instance->ioctl_sem, MEGASAS_INT_CMDS);
./drivers/scsi/megaraid/megaraid_mm.c:  sema_init(&adapter->kioc_semaphore, lld_adp->max_kioc);
./drivers/video/omap/hwa742.c:  sema_init(&hwa742.req_sema, i - IRQ_REQ_POOL_SIZE);
./drivers/video/omap/blizzard.c:        sema_init(&blizzard.req_sema, i - IRQ_REQ_POOL_SIZE);
./drivers/usb/misc/usblcd.c:    sema_init(&dev->limit_sem, USB_LCD_CONCURRENT_WRITES);
./drivers/usb/usb-skeleton.c:   sema_init(&dev->limit_sem, WRITES_IN_FLIGHT);

It's nice to know that nobody is using __DECLARE_SEMAPHORE_GENERIC or
__SEMAPHORE_INITIALIZER at this time.  I'll delete those from my semaphore
tree soon.

-- 
Intel are signing my paycheques ... these opinions are still mine
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours.  We can't possibly take such
a retrograde step."
--
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/