linux-kernel - Re: splice methods in character device driver

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 for Android: free password hash cracker in your pocket

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

Message-ID: <20090616115741.GW11363@kernel.dk>
Date:	Tue, 16 Jun 2009 13:57:41 +0200
From:	Jens Axboe <jens.axboe@...cle.com>
To:	Leon Woestenberg <leon.woestenberg@...il.com>
Cc:	Steve Rottinger <steve@...tek.com>, linux-kernel@...r.kernel.org
Subject: Re: splice methods in character device driver

On Sat, Jun 13 2009, Leon Woestenberg wrote:
> Hello Jens, Steve,
> 
> On Sat, Jun 13, 2009 at 9:26 AM, Jens Axboe<jens.axboe@...cle.com> wrote:
> > On Sat, Jun 13 2009, Leon Woestenberg wrote:
> >> On Mon, Jun 8, 2009 at 9:05 AM, Jens Axboe<jens.axboe@...cle.com> wrote:
> >> > On Sat, Jun 06 2009, Leon Woestenberg wrote:
> >> >> How can I pass information from the splice_read(), which spawns a hardware
> >> >> DMA to the pages in my case, to the confirm() hook which is called at some
> >> >> (random) time in the future?
> >> >
> >> > There's a ->private for each pipe_buffer, so you can pass along info on
> >> > a per-page granularity.
> >> >
> >> So, this means in my driver's splice_read(), I must set
> >> pipe->bufs[i]->private for each 0 <= i < PIPE_BUFFERS?
> >
> > Yes. There's no way to make it bigger granularity, since you could have
> > a mix of source pages in the pipe.
> >
> 
> My current splice support code is copied at the end of this email.
> 
> I would like to batch up some pages before I start the DMA transfer,
> as starting a device-driven DMA on page granularity (with a
> corresponding interrupt)
> looks like too much overhead to me.
> 
> I allocate a device transfer in splice_write(), which I would like to
> fill-in in my write actor pipe_to_device(). At some point, I have to
> start a transfer.
> 
> (sd-> len == sd->total_len) is not a strong enough condition, and I
> find that SPLICE_F_MORE is never set:
> 
> root@...8315e-rdb:~# /splice-in /7000-bytes.bin  | /splice-out -s8192 /dev/alt
> altpciesgdma_open(0xc74fc368, 0xc7be7000)
> 
> splice_write(len=8192)
> 
> transfer = 0xc7114140
> 
> pipe_to_device(buf->offset=0, sd->len/total_len=4096/8192, sd->data =
> 0xc7114140)
> 
> pipe_to_device() expect no more
> 
> pipe_to_device(buf->offset=0, sd->len/total_len=2904/4096, sd->data =
> 0xc7114140)
> 
> pipe_to_device() expect no more
> 
> splice_write(len=8192)
> 
> transfer = 0xc7114ac0
> 
> altpciesgdma_close(0xc74fc368, 0xc7be7000)
> 
> Is total_len <= PAGE_SIZE a sensible and robust (always occuring)
> condition that indicates the last buffer?

It's probably good enough I think. For best results, you want the caller
to pass you that information (since he knows). splice-in is just a dummy
test app, you could easily modify that to pass in SPLICE_F_MORE.

-- 
Jens Axboe

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