public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Pavel Machek <pavel@ucw.cz>
To: "Rafael J. Wysocki" <rjw@sisk.pl>
Cc: Andreas Steinmetz <ast@domdv.de>,
	Linux Kernel Mailinglist <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH encrypted swsusp 1/3] core functionality
Date: Mon, 11 Apr 2005 23:08:19 +0200	[thread overview]
Message-ID: <20050411210819.GF23530@elf.ucw.cz> (raw)
In-Reply-To: <200504112257.39708.rjw@sisk.pl>

Hi!

> I had no time to review your patch earlier, sorry.  I'm inlining it so that I can
> comment it:

> > @@ -72,6 +75,16 @@
> >  
> >  #include "power.h"
> >  
> > +#ifdef CONFIG_SWSUSP_ENCRYPT
> > +#include <linux/random.h>
> > +#include <linux/crypto.h>
> > +#include <asm/scatterlist.h>
> > +#endif
> > +
> > +#define CIPHER "aes"
> > +#define MAXKEY 32
> > +#define MAXIV  32
> 
> Why not to put these definitions under #ifdef?
> 
> > +
> >  /* References to section boundaries */
> >  extern const void __nosave_begin, __nosave_end;
> >  
> > @@ -104,7 +117,9 @@
> >  #define SWSUSP_SIG	"S1SUSPEND"
> >  
> >  static struct swsusp_header {
> > -	char reserved[PAGE_SIZE - 20 - sizeof(swp_entry_t)];
> 
> I would add #ifdef here as well.

I think avoiding both ifdefs is actually right thing to do. Keep the
ifdef noise down.

> > +	char reserved[PAGE_SIZE - 20 - MAXKEY - MAXIV - sizeof(swp_entry_t)];
> > +	u8 key[MAXKEY];
> > +	u8 iv[MAXIV];
> >  	swp_entry_t swsusp_info;
> >  	char	orig_sig[10];
> >  	char	sig[10];
> > @@ -112,6 +127,11 @@
> >  
> >  static struct swsusp_info swsusp_info;
> >  
> > +#ifdef CONFIG_SWSUSP_ENCRYPT
> > +static u8 key[MAXKEY];
> > +static u8 iv[MAXIV];
> > +#endif
> > +
> >  /*
> >   * XXX: We try to keep some more pages free so that I/O operations succeed
> >   * without paging. Might this be more?
> > @@ -130,6 +150,52 @@
> >  static unsigned short swapfile_used[MAX_SWAPFILES];
> >  static unsigned short root_swap;
> >  
> > +#ifdef CONFIG_SWSUSP_ENCRYPT
> > +static struct crypto_tfm *crypto_init(int mode)
> 
> I think it's better if this function returns an int error code and the
> messages are printed where it's called from.  This way, the essential
> part of the code would be easier to grasp (Pavel?).

Agreed. Actually I do not care where messages are printed, but
returning different code for different errors seems right.

							Pavel
-- 
Boycott Kodak -- for their patent abuse against Java.

  reply	other threads:[~2005-04-11 21:09 UTC|newest]

Thread overview: 51+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-04-10 23:19 [PATCH encrypted swsusp 1/3] core functionality Andreas Steinmetz
2005-04-11 10:25 ` Pavel Machek
2005-04-11 10:36   ` folkert
2005-04-11 11:01     ` Pavel Machek
2005-04-11 11:38       ` folkert
2005-04-11 16:28       ` Andreas Steinmetz
2005-04-11 16:36         ` Pavel Machek
2005-04-11 13:08     ` Andreas Steinmetz
2005-04-11 11:08 ` Pavel Machek
2005-04-11 13:11   ` Andreas Steinmetz
2005-04-11 16:11   ` Andreas Steinmetz
2005-04-11 20:57     ` Rafael J. Wysocki
2005-04-11 21:08       ` Pavel Machek [this message]
2005-04-11 21:35         ` Rafael J. Wysocki
2005-04-12 10:07           ` Andreas Steinmetz
2005-04-12 10:52       ` Andreas Steinmetz
2005-04-12 13:17       ` Andreas Steinmetz
2005-04-13 11:59         ` Herbert Xu
2005-04-13 12:59           ` Andreas Steinmetz
2005-04-13 21:27             ` Herbert Xu
2005-04-13 22:29               ` Andreas Steinmetz
2005-04-13 23:10                 ` Herbert Xu
2005-04-13 23:24                   ` Pavel Machek
2005-04-13 23:39                     ` Herbert Xu
2005-04-13 23:46                       ` Pavel Machek
2005-04-14  0:35                         ` Matt Mackall
2005-04-14  6:51                           ` Pavel Machek
2005-04-14  8:08                             ` Herbert Xu
2005-04-14  9:04                               ` Rafael J. Wysocki
2005-04-14 17:11                                 ` Matt Mackall
2005-04-14 19:27                                   ` Stefan Seyfried
2005-04-14 19:53                                     ` Matt Mackall
2005-04-14 20:18                                       ` Pavel Machek
2005-04-14 22:27                                         ` Matt Mackall
2005-04-14 22:11                                       ` Andy Isaacson
2005-04-14 22:48                                         ` Matt Mackall
2005-04-15  9:44                                           ` Andreas Steinmetz
2005-04-15  9:44                                       ` Andreas Steinmetz
2005-04-15 17:00                                         ` Matt Mackall
2005-04-14 20:13                                   ` Pavel Machek
2005-04-14  9:05                               ` Pavel Machek
2005-04-15  9:44                             ` Andreas Steinmetz
2005-04-15  9:47                               ` Pavel Machek
2005-04-14  1:13                       ` Bernd Eckenfels
2005-04-14  8:27                         ` Pavel Machek
2005-04-14  8:31                       ` encrypted swap (was Re: [PATCH encrypted swsusp 1/3] core functionality) Andy Isaacson
2005-04-14  8:38                         ` Herbert Xu
2005-04-14  8:49                           ` Arjan van de Ven
2005-04-14  1:11                   ` [PATCH encrypted swsusp 1/3] core functionality Bernd Eckenfels
2005-04-13 13:22         ` Pavel Machek
2005-04-13 14:45           ` Andreas Steinmetz

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=20050411210819.GF23530@elf.ucw.cz \
    --to=pavel@ucw.cz \
    --cc=ast@domdv.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rjw@sisk.pl \
    /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