Re: [PATCH v2] crypto: doc - clarify hash callbacks state machine
On Tue, Mar 20, 2018 at 09:56:12AM +0200, Horia Geantă wrote: > Add a note that it is perfectly legal to "abandon" a request object: > - call .init() and then (as many times) .update() > - _not_ call any of .final(), .finup() or .export() at any point in > future > > Link: https://lkml.kernel.org/r/20180222114741.ga27...@gondor.apana.org.au > Signed-off-by: Horia Geantă <horia.gea...@nxp.com> Patch applied. Thanks. -- Email: Herbert Xu <herb...@gondor.apana.org.au> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] crypto: doc - clarify hash callbacks state machine
On Mon, Mar 19, 2018 at 11:04:24AM +, Horia Geantă wrote: > > The only solution to avoid leaks in this case is to repeatedly DMA map & unmap > the buffer. > IOW, if one wants to load/save HW state in a buffer after an .update() and to > instruct the crypto engine to do this operation, the following steps are > involved: > -gpp: DMA map the buffer, get its IOVA > -gpp: program the crypto engine with IOVA, wait for crypto engine's signal > -crypto engine: load HW state from buffer, perform the partial hash, save HW > state in buffer, signal gpp > -gpp: DMA unmap the buffer What buffer are you talking about here? Is it the hash state? If it's the hash state and assuming DMA mapping was slow enough on your platform, you could solve it by maintaining a fixed set of hash states that are rotated through the actual hash requests. Let's say you allocate n such hash states which are always mapped, then if there are less than n hash requests outstanding, you could directly use the mapped hash states in the requests. If there are more than n, then you simply copy in/copy out for each hash operation. The number n limits how many operations can be pending to be processed by the hardware. Cheers, -- Email: Herbert Xu <herb...@gondor.apana.org.au> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] crypto: doc - clarify hash callbacks state machine
On Mon, Mar 19, 2018 at 06:39:50AM +, Horia Geantă wrote: > > The fact that there can be multiple requests in parallel (for a given tfm) is > a > different topic. > Each request object has its state in its own state machine, independent from > the > other request objects. > I assume this is clear enough. My point is that all of the state associated with a request needs to be stored in the request object. If you're start storing things in the driver/hardware, then things will get ugly one way or another. Cheers, -- Email: Herbert Xu <herb...@gondor.apana.org.au> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] crypto: doc - clarify hash callbacks state machine
On Mon, Mar 05, 2018 at 12:39:45PM +0200, Horia Geantă wrote: > Even though it doesn't make too much sense, it is perfectly legal to: > - call .init() and then (as many times) .update() > - subseqently _not_ call any of .final(), .finup() or .export() Actually it makes perfect sense, because there can be an arbitrary number of requests for a given tfm. There is no requirement that you must finalise the first request before submitting new ones. IOW there can be an arbitrary number of outstanding requests even without the user intentionally abandoning any hash request. So please modify your commit description. Thanks, -- Email: Herbert Xu <herb...@gondor.apana.org.au> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/6] crypto: engine - Permit to enqueue all async requests
On Fri, Jan 26, 2018 at 08:15:28PM +0100, Corentin Labbe wrote: > Hello > > The current crypto_engine support only ahash and ablkcipher request. > My first patch which try to add skcipher was Nacked, it will add too many > functions > and adding other algs(aead, asymetric_key) will make the situation worst. > > This patchset remove all algs specific stuff and now only process generic > crypto_async_request. > > The requests handler function pointer are now moved out of struct engine and > are now stored directly in a crypto_engine_reqctx. > > The original proposal of Herbert [1] cannot be done completly since the > crypto_engine > could only dequeue crypto_async_request and it is impossible to access any > request_ctx > without knowing the underlying request type. > > So I do something near that was requested: adding crypto_engine_reqctx in TFM > context. > Note that the current implementation expect that crypto_engine_reqctx > is the first member of the context. > > The first patch is a try to document the crypto engine API. > The second patch convert the crypto engine with the new way, > while the following patchs convert the 4 existing users of crypto_engine. > Note that this split break bisection, so probably the final commit will be > all merged. > > Appart from virtio, all 4 latest patch were compile tested only. > But the crypto engine is tested with my new sun8i-ce driver. > > Regards > > [1] https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1474434.html > > Changes since V1: > - renamed crypto_engine_reqctx to crypto_engine_ctx > - indentation fix in function parameter > - do not export crypto_transfer_request > - Add aead support > - crypto_finalize_request is now static > > Changes since RFC: > - Added a documentation patch > - Added patch for stm32-cryp > - Changed parameter of all crypto_engine_op functions from > crypto_async_request to void* > - Reintroduced crypto_transfer_xxx_request_to_engine functions > > Corentin Labbe (6): > Documentation: crypto: document crypto engine API > crypto: engine - Permit to enqueue all async requests > crypto: omap: convert to new crypto engine API > crypto: virtio: convert to new crypto engine API > crypto: stm32-hash: convert to the new crypto engine API > crypto: stm32-cryp: convert to the new crypto engine API All applied. Thanks. -- Email: Herbert Xu <herb...@gondor.apana.org.au> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/6] crypto: engine - Permit to enqueue all async requests
On Wed, Jan 03, 2018 at 09:11:05PM +0100, Corentin Labbe wrote:
> The crypto engine could actually only enqueue hash and ablkcipher request.
> This patch permit it to enqueue any type of crypto_async_request.
>
> Signed-off-by: Corentin Labbe <clabbe.montj...@gmail.com>
> ---
> crypto/crypto_engine.c | 230
>
> include/crypto/engine.h | 59 +++--
> 2 files changed, 148 insertions(+), 141 deletions(-)
>
> diff --git a/crypto/crypto_engine.c b/crypto/crypto_engine.c
> index 61e7c4e02fd2..036270b61648 100644
> --- a/crypto/crypto_engine.c
> +++ b/crypto/crypto_engine.c
> @@ -15,7 +15,6 @@
> #include
> #include
> #include
> -#include
> #include
> #include "internal.h"
>
> @@ -34,11 +33,10 @@ static void crypto_pump_requests(struct crypto_engine
> *engine,
>bool in_kthread)
> {
> struct crypto_async_request *async_req, *backlog;
> - struct ahash_request *hreq;
> - struct ablkcipher_request *breq;
> unsigned long flags;
> bool was_busy = false;
> - int ret, rtype;
> + int ret;
> + struct crypto_engine_reqctx *enginectx;
This all looks very good. Just one minor nit, since you're storing
this in the tfm ctx as opposed to the request ctx (which is indeed
an improvement), you should remove the "req" from its name.
Thanks!
--
Email: Herbert Xu <herb...@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v10 00/20] simplify crypto wait for async op
On Wed, Oct 18, 2017 at 08:00:32AM +0100, Gilad Ben-Yossef wrote: > Many users of kernel async. crypto services have a pattern of > starting an async. crypto op and than using a completion > to wait for it to end. > > This patch set simplifies this common use case in two ways: > > First, by separating the return codes of the case where a > request is queued to a backlog due to the provider being > busy (-EBUSY) from the case the request has failed due > to the provider being busy and backlogging is not enabled > (-ENOSPC). > > Next, this change is than built on to create a generic API > to wait for a async. crypto operation to complete. > > The end result is a smaller code base and an API that is > easier to use and more difficult to get wrong. > > The patch set was boot tested on x86_64 and arm64 which > at the very least tests the crypto users via testmgr and > tcrypt but I do note that I do not have access to some > of the HW whose drivers are modified nor do I claim I was > able to test all of the corner cases. > > The patch set is based upon linux-next release tagged > next-20171017. All applied. Thanks. -- Email: Herbert Xu <herb...@gondor.apana.org.au> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v9 00/20] simplify crypto wait for async op
On Tue, Oct 17, 2017 at 02:55:21PM +0300, Gilad Ben-Yossef wrote: > > Would you mind if we used ENOSPC instead of E2BIG? > > "No space left on device" seems more appropriate than > "Argument list too long". It's fine by me. Thanks, -- Email: Herbert Xu <herb...@gondor.apana.org.au> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v9 00/20] simplify crypto wait for async op
On Sun, Oct 15, 2017 at 10:19:45AM +0100, Gilad Ben-Yossef wrote: > > Changes from v8: > - Remove the translation of EAGAIN return code to the > previous return code of EBUSY for the user space > interface of algif as no one seems to rely on it as > requested by Herbert Xu. Sorry, but I forgot to mention that EAGAIN is not a good value to use because it's used by the network system calls for other meanings (interrupted by a signal). So if we stop doing the translation then we also need to pick a different value, perhaps E2BIG or something similar that have no current use within the crypto API or network API. Thanks, -- Email: Herbert Xu <herb...@gondor.apana.org.au> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v8 01/20] crypto: change transient busy return code to -EAGAIN
On Sat, Oct 07, 2017 at 10:51:42AM +0300, Gilad Ben-Yossef wrote:
> On Sat, Oct 7, 2017 at 6:05 AM, Herbert Xu <herb...@gondor.apana.org.au>
> wrote:
> > On Tue, Sep 05, 2017 at 03:38:40PM +0300, Gilad Ben-Yossef wrote:
> >>
> >> diff --git a/crypto/algif_hash.c b/crypto/algif_hash.c
> >> index 5e92bd2..3b3c154 100644
> >> --- a/crypto/algif_hash.c
> >> +++ b/crypto/algif_hash.c
> >> @@ -39,6 +39,20 @@ struct algif_hash_tfm {
> >> bool has_key;
> >> };
> >>
> >> +/* Previous versions of crypto_* ops used to return -EBUSY
> >> + * rather than -EAGAIN to indicate being tied up. The in
> >> + * kernel API changed but we don't want to break the user
> >> + * space API. As only the hash user interface exposed this
> >> + * error ever to the user, do the translation here.
> >> + */
> >> +static inline int crypto_user_err(int err)
> >> +{
> >> + if (err == -EAGAIN)
> >> + return -EBUSY;
> >> +
> >> + return err;
> >
> > I don't see the need to carry along this baggage. Does anyone
> > in user-space actually rely on EBUSY?
>
>
> I am not aware of anyone who does. I was just trying to avoid
> changing the user ABI.
>
> Shall I roll a new revision without this patch?
Yes please. I'd rather not carry this around for eternity unless
it was actually required.
Thanks,
--
Email: Herbert Xu <herb...@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v8 01/20] crypto: change transient busy return code to -EAGAIN
On Tue, Sep 05, 2017 at 03:38:40PM +0300, Gilad Ben-Yossef wrote:
>
> diff --git a/crypto/algif_hash.c b/crypto/algif_hash.c
> index 5e92bd2..3b3c154 100644
> --- a/crypto/algif_hash.c
> +++ b/crypto/algif_hash.c
> @@ -39,6 +39,20 @@ struct algif_hash_tfm {
> bool has_key;
> };
>
> +/* Previous versions of crypto_* ops used to return -EBUSY
> + * rather than -EAGAIN to indicate being tied up. The in
> + * kernel API changed but we don't want to break the user
> + * space API. As only the hash user interface exposed this
> + * error ever to the user, do the translation here.
> + */
> +static inline int crypto_user_err(int err)
> +{
> + if (err == -EAGAIN)
> + return -EBUSY;
> +
> + return err;
I don't see the need to carry along this baggage. Does anyone
in user-space actually rely on EBUSY?
Cheers,
--
Email: Herbert Xu <herb...@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Documentation: hw_random: Fix issue related to feeding entropy pool
PrasannaKumar Muralidharan <prasannatsmku...@gmail.com> wrote: > There is no need to use rng-tools for feeding random data into kernel > entropy pool as hw_random core handles it. Documentation suggested that > rng-tools is required which is incorrect. So remove it. > > Signed-off-by: PrasannaKumar Muralidharan <prasannatsmku...@gmail.com> Hmm, the tool still exists and can still be used to feed /dev/random. Feeding /dev/random directly from the kernel is just one way of using hwrng. So rather than removing it perhaps you can modify it to state that the kernel can now feed /dev/random as an option. Cheers, -- Email: Herbert Xu <herb...@gondor.apana.org.au> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 01/28] crypto: change backlog return code to -EIOCBQUEUED
On Sun, Jul 02, 2017 at 05:41:43PM +0300, Gilad Ben-Yossef wrote: > The crypto API was using the -EBUSY return value to indicate > both a hard failure to submit a crypto operation into a > transformation provider when the latter was busy and the backlog > mechanism was not enabled as well as a notification that the operation > was queued into the backlog when the backlog mechanism was enabled. > > Having the same return code indicate two very different conditions > depending on a flag is both error prone and requires extra runtime > check like the following to discern between the cases: > > if (err == -EINPROGRESS || > (err == -EBUSY && (ahash_request_flags(req) & > CRYPTO_TFM_REQ_MAY_BACKLOG))) > > This patch changes the return code used to indicate a crypto op > was queued in the backlog to -EIOCBQUEUED, thus resolving both > issues. > > Signed-off-by: Gilad Ben-Yossef <gi...@benyossef.com> So you're changing the success case from EBUSY to EIOCBQUEUED. This results in a lot of churn as you have to change every single driver and caller. How about changing the error case to use something other than EBUSY instead? Thanks, -- Email: Herbert Xu <herb...@gondor.apana.org.au> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 01/11] crypto: introduce crypto wait for async op
On Sat, Jun 10, 2017 at 11:05:39AM +0300, Gilad Ben-Yossef wrote: > > I guess there is a question if it really is important to know that > your request ended up > on the backlog, rather than being handled.I can imagine it can be used > as back pressure > indication but I wonder if someone is using that. Oh yes we do want it to return EBUSY if we put it on the backlog because in that case we want the user to stop sending us new requests. It's the other case where we dropped the request and returned EBUSY where I think we could return something other than EBUSY and get rid of the ambiguity. Thanks, -- Email: Herbert Xu <herb...@gondor.apana.org.au> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 01/11] crypto: introduce crypto wait for async op
On Mon, May 29, 2017 at 11:22:48AM +0300, Gilad Ben-Yossef wrote:
>
> +static inline int crypto_wait_req(int err, struct crypto_wait *wait)
> +{
> + switch (err) {
> + case -EINPROGRESS:
> + case -EBUSY:
> + wait_for_completion(>completion);
> + reinit_completion(>completion);
> + err = wait->err;
> + break;
> + };
> +
> + return err;
> +}
This assumes that the request is used with backlog. For non-backlog
requests this would result in a memory leak as EBUSY in that case is
a fatal error.
So this API can't be used without backlog.
We could introduce a flag to indicate whether we want backlog or not,
or maybe we should change our API so that in the non-backlog case we
return something other than EBUSY.
Opinions?
Thanks,
--
Email: Herbert Xu <herb...@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/4] crypto: async crypto op fixes
On Thu, May 18, 2017 at 04:29:22PM +0300, Gilad Ben-Yossef wrote: > This patch set fixes various usage and documentation errors > in waiting for async crypto op to complete which can result > in data corruption. > > Note: these were discovered in the process of working on a > patch set that replaces these call sites and more with a > generic implementation that will prevent these problems > going forward. These are just the fix ups for current code. > > Signed-off-by: Gilad Ben-Yossef <gi...@benyossef.com> > CC: sta...@vger.kernel.org > CC: Eric Biggers <ebigge...@gmail.com> Patches 1-3 applied. Please fix patch 4 and resubmit. Thanks. -- Email: Herbert Xu <herb...@gondor.apana.org.au> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] crypto: fix typo in doc
On Tue, Feb 14, 2017 at 08:21:45AM +0200, Gilad Ben-Yossef wrote: > Fix a single letter typo in api-skcipher.rst. > > Signed-off-by: Gilad Ben-Yossef <gi...@benyossef.com> Patch applied. Thanks. -- Email: Herbert Xu <herb...@gondor.apana.org.au> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/8] Conversion crypto API documentation to Sphinx
On Sun, Oct 23, 2016 at 06:46:12PM +0200, Stephan Mueller wrote: > Am Sonntag, 23. Oktober 2016, 10:32:38 CEST schrieb Jonathan Corbet: > > Hi Jonathan, > > > On Fri, 21 Oct 2016 04:53:45 +0200 > > > > Stephan Mueller <smuel...@chronox.de> wrote: > > > the attached patch set converts the existing crypto API documentation > > > from DocBook to Sphinx. > > > > This looks generally good to me - thanks for doing it! > > > > Is there any chance of running the Documentation/ parts through the docs > > tree? Documentation/index.rst has become a bit of a conflict point > > otherwise... > > Unless Herbert objects, I would not see any reason why we should not push it > through the docs tree. No objections from me. > Yet we should wait for Herbert's ack as I have added also new information in > the patch set (the KPP API documentation and the change in the AEAD > documentation). Looks good to me. Thanks, -- Email: Herbert Xu <herb...@gondor.apana.org.au> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RESEND] crypto: doc - fix documentation for bulk registration functions
Eric Biggers <ebigg...@google.com> wrote: > Update the documentation for crypto_register_algs() and > crypto_unregister_algs() to match the actual behavior. > > Signed-off-by: Eric Biggers <ebigg...@google.com> Your previous submission has already been applied. Cheers, -- Email: Herbert Xu <herb...@gondor.apana.org.au> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3] crypto: Add a flag allowing the self-tests to be disabled at runtime.
On Tue, May 03, 2016 at 10:00:17AM +0100, Richard W.M. Jones wrote: > Running self-tests for a short-lived KVM VM takes 28ms on my laptop. > This commit adds a flag 'cryptomgr.notests' which allows them to be > disabled. > > However if fips=1 as well, we ignore this flag as FIPS mode mandates > that the self-tests are run. > > Signed-off-by: Richard W.M. Jones <rjo...@redhat.com> Applied. -- Email: Herbert Xu <herb...@gondor.apana.org.au> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] crypto: document correct return value for request allocation
On Sat, Apr 02, 2016 at 10:54:56AM -0500, Eric Biggers wrote: > Signed-off-by: Eric Biggers <ebigge...@gmail.com> Applied. -- Email: Herbert Xu <herb...@gondor.apana.org.au> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
