From: Christophe Saout <christophe@saout.de>
To: Jeff Garzik <jgarzik@pobox.com>
Cc: Christoph Hellwig <hch@infradead.org>,
Joe Thornber <thornber@redhat.com>,
Mike Christie <mikenc@us.ibm.com>, Andrew Morton <akpm@osdl.org>,
linux-kernel@vger.kernel.org
Subject: Re: dm-crypt using kthread
Date: Mon, 16 Feb 2004 03:40:44 +0100 [thread overview]
Message-ID: <1076899244.5601.21.camel@leto.cs.pocnet.net> (raw)
In-Reply-To: <4030268C.6050701@pobox.com>
Am Mo, den 16.02.2004 schrieb Jeff Garzik um 03:10:
> > + /*
> > + * if additional pages cannot be allocated without waiting,
> > + * return a partially allocated bio, the caller will then try
> > + * to allocate additional bios while submitting this partial bio
> > + */
> > + if ((i - bio->bi_idx) == (MIN_BIO_PAGES - 1))
> > + gfp_mask = (gfp_mask | __GFP_NOWARN) & ~__GFP_WAIT;
>
> If the caller said they can wait, why not wait?
How can the caller say this?
This is basically to avoid deadlocks. The kernel might decide to flush
data in order to free memory (or even swap out). dm-crypt needs to
allocate buffers for encryption. If we run out of memory we need to be
able to write something in order to get new memory. Successful writes
will return some pages to the pool and potentially wake up some threads
needing these.
> > +static void dec_pending(struct crypt_io *io, int error)
> > [...]
> > + if (io->bio)
> > + bio_endio(io->bio, io->bio->bi_size, io->error);
>
> when does io->bio==NULL ?
Umm, right. Can't ever happen. Thanks.
> > + set_task_state(current, TASK_INTERRUPTIBLE);
> > + while (!(bio = kcryptd_get_bios())) {
> > + schedule();
> > + if (signal_pending(current))
> > + return 0;
> > + }
> > + set_task_state(current, TASK_RUNNING);
>
> You just keep calling schedule() rapid-fire until you get a bio? That's
> a bit sub-optimal.
That's wrong anyway. I was just making sure I was calling
kcryptd_get_bios after schedule. schedule() will sleep and woken after
someone added a bio to the list.
I've changed it to an if now and call kcryptd_get_bios after schedule.
I'm calling it twice because it is likely that someone started a new
list while the old list is being processed and I don't want to sleep in
this case, just fall through.
The kcryptd_get_bios needs to be after state = TASK_INTERRUPTIBLE to
avoid a race. If someone wakes the process after kcryptd_get_bios but
before schedule it resets the state to TASK_RUNNING so that the schedule
won't sleep.
> > +/*
> > + * Encode key into its hex representation
> > + */
> > +static void crypt_encode_key(char *hex, u8 *key, int size)
> > +{
> > + static char hex_digits[] = "0123456789abcdef";
>
> static const
Or sprintf... I doubt this would result in shorter code but it would be
more consistent.
> > + if (!mode || strcmp(mode, "plain") == 0)
> > + cc->iv_generator = crypt_iv_plain;
> > + else if (strcmp(mode, "ecb") == 0)
> > + cc->iv_generator = NULL;
> > + else {
> > + ti->error = "dm-crypt: Invalid chaining mode";
> > + return -EINVAL;
> > + }
>
> memory leak on error
Ouch. Thanks.
> > +static int crypt_endio(struct bio *bio, unsigned int done, int error)
> > +{
> > + struct crypt_io *io = (struct crypt_io *) bio->bi_private;
> > + struct crypt_config *cc = (struct crypt_config *) io->target->private;
> > +
> > + if (bio_rw(bio) == WRITE) {
> > + /*
> > + * free the processed pages, even if
> > + * it's only a partially completed write
> > + */
> > + crypt_free_buffer_pages(cc, bio, done);
> > + }
> > +
> > + if (bio->bi_size)
> > + return 1;
>
> dumb question, for my own knowledge: what does this 'if' test do?
It checks whether has bio has been completed. The block layer may notify
us if parts of the bio has been finished.
>
> > +static int crypt_map(struct dm_target *ti, struct bio *bio,
> > + union map_info *map_context)
> > [...]
>
> would be nice to move this code into a separate "create and init my
> clone" function, simply to be ease review and make things a bit more
> clear...
create and init would be the whole content of the loop. But if you think
so, I can do that.
> might want to use the standard 'goto' style exception handling here too,
> instead of duplicating the error unwind code.
Yes, the function got larger over time.
> Overall, needs a tiny bit of work, but I like it.
Thanks.
next prev parent reply other threads:[~2004-02-16 2:41 UTC|newest]
Thread overview: 55+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-02-11 15:33 Oopsing cryptoapi (or loop device?) on 2.6.* Michal Kwolek
2004-02-11 18:41 ` Jari Ruusu
2004-02-15 2:35 ` Jan Rychter
2004-02-15 14:51 ` Jari Ruusu
2004-02-15 16:38 ` Jari Ruusu
2004-02-16 0:26 ` James Morris
2004-02-18 14:07 ` Bill Davidsen
2004-02-16 12:22 ` Jan Rychter
2004-02-17 14:09 ` Jari Ruusu
2004-02-17 19:14 ` Jan Rychter
2004-02-18 14:06 ` Jari Ruusu
2004-02-18 21:40 ` Jan Rychter
2004-02-19 13:34 ` Jari Ruusu
2004-02-11 22:54 ` bill davidsen
2004-02-15 17:34 ` Christophe Saout
2004-02-15 18:02 ` Christoph Hellwig
2004-02-15 18:42 ` Christophe Saout
2004-02-15 18:53 ` Christoph Hellwig
2004-02-15 19:36 ` Christophe Saout
2004-02-15 19:46 ` Christoph Hellwig
2004-02-15 20:24 ` kthread vs. dm-daemon (was: Oopsing cryptoapi (or loop device?) on 2.6.*) Christophe Saout
2004-02-15 22:13 ` kthread vs. dm-daemon Mike Christie
2004-02-16 0:04 ` Christophe Saout
2004-02-16 1:04 ` Mike Christie
2004-02-16 1:29 ` Christophe Saout
2004-02-16 3:02 ` kthread vs. dm-daemon (was: Oopsing cryptoapi (or loop device?) on 2.6.*) Rusty Russell
2004-02-16 13:27 ` Christophe Saout
2004-02-16 16:42 ` Christophe Saout
2004-02-16 13:48 ` Joe Thornber
2004-02-16 1:44 ` dm-crypt using kthread " Christophe Saout
2004-02-16 1:53 ` Andrew Morton
2004-02-16 2:07 ` Grzegorz Kulewski
2004-02-16 3:03 ` Christophe Saout
2004-02-16 3:22 ` Grzegorz Kulewski
2004-02-16 4:05 ` dm-crypt using kthread Jeff Garzik
2004-02-16 4:14 ` Grzegorz Kulewski
2004-02-16 10:15 ` Christophe Saout
2004-02-16 9:54 ` dm-crypt using kthread (was: Oopsing cryptoapi (or loop device?) on 2.6.*) Christophe Saout
2004-03-01 22:18 ` Matthias Urlichs
2004-03-01 22:51 ` Christophe Saout
2004-03-01 23:22 ` Matthias Urlichs
2004-02-16 2:58 ` Christophe Saout
2004-02-16 7:28 ` David Wagner
2004-02-16 10:11 ` Christophe Saout
2004-02-18 14:15 ` dm-crypt using kthread Bill Davidsen
2004-02-16 2:07 ` dm-crypt using kthread (was: Oopsing cryptoapi (or loop device?) on 2.6.*) Andrew Morton
2004-02-16 2:17 ` dm-crypt using kthread Jeff Garzik
2004-02-16 2:53 ` dm-crypt using kthread (was: Oopsing cryptoapi (or loop device?) on 2.6.*) Christophe Saout
2004-02-16 2:10 ` dm-crypt using kthread Jeff Garzik
2004-02-16 2:40 ` Christophe Saout [this message]
2004-02-16 2:58 ` Jeff Garzik
2004-02-16 3:10 ` Christophe Saout
2004-02-16 13:04 ` Christophe Saout
2004-02-16 19:09 ` Jeff Garzik
[not found] <1o4ML-V4-5@gated-at.bofh.it>
[not found] ` <1pypu-2eR-25@gated-at.bofh.it>
[not found] ` <1pySs-2Hu-13@gated-at.bofh.it>
[not found] ` <1pzve-3a8-21@gated-at.bofh.it>
[not found] ` <1pzEW-3hA-11@gated-at.bofh.it>
[not found] ` <1pAhG-3RJ-29@gated-at.bofh.it>
[not found] ` <1pArj-3ZE-31@gated-at.bofh.it>
[not found] ` <1pG3C-kZ-9@gated-at.bofh.it>
[not found] ` <1pGdl-qX-11@gated-at.bofh.it>
[not found] ` <1pGn1-E8-23@gated-at.bofh.it>
[not found] ` <1pHj1-1q2-11@gated-at.bofh.it>
2004-02-16 3:58 ` Andi Kleen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1076899244.5601.21.camel@leto.cs.pocnet.net \
--to=christophe@saout.de \
--cc=akpm@osdl.org \
--cc=hch@infradead.org \
--cc=jgarzik@pobox.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mikenc@us.ibm.com \
--cc=thornber@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®