linux-kernel - Re: [PATCH 2/3] Add GD-Rom support to the SEGA Dreamcast

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]

Message-ID: <48462.85.118.17.158.1197902160.squirrel@newgolddream.dyndns.info>
Date:	Mon, 17 Dec 2007 14:36:00 -0000 (UTC)
From:	"Adrian McMenamin" <adrian@...golddream.dyndns.info>
To:	"Jens Axboe" <jens.axboe@...cle.com>
Cc:	"Adrian McMenamin" <lkmladrian@...il.com>,
	"Paul Mundt" <lethal@...ux-sh.org>, linux-kernel@...r.kernel.org,
	linux-ide@...r.kernel.org, linux-sh@...r.kernel.org
Subject: Re: [PATCH 2/3] Add GD-Rom support to the SEGA Dreamcast

On Mon, December 17, 2007 2:06 pm, Jens Axboe wrote:
> On Sun, Dec 16 2007, Adrian McMenamin wrote:
>
> Few notes:


Thanks for these, very helpful.

>
> - Compare rq_data_dir() with WRITE, don't just assume that any non-zero
>   will be a write.
>
> - You need to offload this request handling to a workqueue of some sort,
>   your current request handling is very broken for two reasons: One is
>   that interrupts are still disabled when you drop your queue lock, so
>   you cannot use sleeping functions like GFP_KERNEL allocations or
>   wait_event(). The other is that it's illegal to sleep from your
>   request_fn context in the first place, since you could be stalling
>   others.



Ah. OK. Funnily enough an earlier version did offload to a workqueue but i
thought that was too convoluted. I didn't realise interrupts were disabled
inside the request_fn context.

>
> - You also seem to be busy waiting for other transactions to finish. Any
>   idea how long those might take? Perhaps put an upper bound on this
>   waiting, and/or do blocking waits?
>
Well, when the register bit clears they are over, seems to be about 200 -
400 microseconds or there abouts (ie that length of time between the
interrupt signalling that the transfer is over and the bit clearing to
allow a new transfer) - so I could time that out at say HZ/2 and be very
safe.


> - I'm assuming this hardware can't do sg transfers?
>

Afraid not.

--
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/