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:	Sun, 9 Sep 2007 19:36:52 +0100
From:	"Adrian McMenamin" <lkmladrian@...il.com>
To:	"Arjan van de Ven" <arjan@...radead.org>
Cc:	"Paul Mundt" <lethal@...ux-sh.org>,
	linuxsh-dev@...ts.sourceforge.net, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/3] Maple bus support for the Sega Dreamcast

On 09/09/07, Arjan van de Ven <arjan@...radead.org> wrote:
> On Sun, 9 Sep 2007 17:46:54 +0100
> "Adrian McMenamin" <lkmladrian@...il.com> wrote:
>
> > This patch adds support for Sega's proprietary Maple bus - which is
> > required to support the Dreamcast's peripherals.
>

>
> First of all, I'm a little concerned about the lack of locking that
> this driver seems to have; what guarantees the integrity of the lists
> used in the driver?
>
Could you explain what you think the issue is? The lists are only
handled by this driver and not anything else.


> Second, you have a lot of use of likely() and unlikely(); so much that I think it's waaaay overkill. The code it's in generally isn't hotpath, and gcc also does a pretty decent job without giving these hints in general.
>
>
>

Fair enough.

> > +
> > +void maple_add_packet(struct mapleq *mq)
> > +{
> > +     list_add((struct list_head *) mq, &maple_waitq);
> > +}
>
> for example this list.. what makes sure that no 2 pieces of code muck with it at the same time?
>
>

Because everything is handled by one kernel thread on a uniprocessor machine.


> > +static irqreturn_t maplebus_dma_interrupt(int irq, void *dev_id)
> > +{
> > +     /* Load everything into the bottom half */
> > +     schedule_work(&maple_dma_process);
> > +     return IRQ_HANDLED;
> > +}
>
> I wonder if you want to at least check if the work was really for you before returning IRQ_HANDLED....
>

It's *always* for me - this is an end of DMA interrupt for the bus.
-
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ