On Tue, Nov 18, 2008 at 01:38:31PM -0700, Tim Gardner wrote:
> This patch is being proposed as an SRU to Intrepid, but I'm having a
> hard time reconciling the description with the actual function of
> the patch.
>
> Allocating multiple scatterlist structures has nothing to do with
> alignment, but what it _does_ do is correctly consume the second S/G
> entry if the buffer passed to virt_to_scatterlist() crosses a page
> boundary, correct?

That is correct. The patch compensates for the fact that the key value
may not fit in a single page.

> It seems to me that the bug occurs if the virtual pages consumed by
> the buffer are not physically contiguous.
>
> rtg

> To: kernel-team@lists.canonical.com
> Subject: SRU LP292429 Error when copying directory tree with Nautilus to
> ~/Private using ecryptfs
> From: Jim Lieb <jim.lieb@canonical.com>
> Date: Mon, 17 Nov 2008 18:13:24 -0800
>
> OriginalAuthor: Michael Halcrow <mhalcrow@us.ibm.com>
> Bug: #292429
>
> On Wed, Nov 12, 2008 at 12:36:10PM -0600, Michael Halcrow wrote:
> > Looks like crypt_stat->key is not page-aligned on this older AMD
> > architecture. This is a legitimate bug in eCryptfs and needs to be
> > fixed upstream. I think I will just grab a page via page_alloc() to
> > use as a temporary buffer for the crypto API scatterlist ops.
>
> On second thought, it might make more sense just to allocate a couple
> of scatterlist structs on the stack every time instead. See if this
> patch resolves the problem. It tests fine for me on my Intel
> processor, and I expect it will resolve the problem on the AMD
> architecture.
>
> This patch is not in the upstream yet. We expect it may appear
> in a different form later.
>
> Committer: Jim Lieb <lieb@canonical.com>
> Signed-off-by: Michael Halcrow <mhalcrow@us.ibm.com>
> Signed-off-by: Jim Lieb <jim.lieb@canonical.com>
> ---
> fs/ecryptfs/keystore.c | 31 ++++++++++++++-----------------
> 1 files changed, 14 insertions(+), 17 deletions(-)
>
> The raw diff is attached
>
> Jim

> From 0bd3efbad5b618fc2894e0650854e81fc1cbaf85 Mon Sep 17 00:00:00 2001
> From: Jim Lieb <lieb@jim-laptop.home.sea-troll.net>
> Date: Fri, 14 Nov 2008 14:03:54 -0800
> Subject: [PATCH] UBUNTU: SAUCE: Error when copying directory tree with Nautilus to ~/Private using ecryptfs
>
> OriginalAuthor: Michael Halcrow <mhalcrow@us.ibm.com>
> Bug: #292429
>
> On Wed, Nov 12, 2008 at 12:36:10PM -0600, Michael Halcrow wrote:
> > Looks like crypt_stat->key is not page-aligned on this older AMD
> > architecture. This is a legitimate bug in eCryptfs and needs to be
> > fixed upstream. I think I will just grab a page via page_alloc() to
> > use as a temporary buffer for the crypto API scatterlist ops.
>
> On second thought, it might make more sense just to allocate a couple
> of scatterlist structs on the stack every time instead. See if this
> patch resolves the problem. It tests fine for me on my Intel
> processor, and I expect it will resolve the problem on the AMD
> architecture.
>
> This patch is not in the upstream yet. We expect it may appear
> in a different form later.
>
> Committer: Jim Lieb <lieb@canonical.com>
> Signed-off-by: Michael Halcrow <mhalcrow@us.ibm.com>
> Signed-off-by: Jim Lieb <jim.lieb@canonical.com>
> ---
> fs/ecryptfs/keystore.c | 31 ++++++++++++++-----------------
> 1 files changed, 14 insertions(+), 17 deletions(-)
>
> diff --git a/fs/ecryptfs/keystore.c b/fs/ecryptfs/keystore.c
> index f5b76a3..59b9833 100644
> --- a/fs/ecryptfs/keystore.c
> +++ b/fs/ecryptfs/keystore.c
> @@ -1037,17 +1037,14 @@ static int
> decrypt_passphrase_encrypted_session_key(struct ecryptfs_auth_tok *auth_tok,
> struct ecryptfs_crypt_stat *crypt_stat)
> {
> - struct scatterlist dst_sg;
> - struct scatterlist src_sg;
> + struct scatterlist dst_sg[2];
> + struct scatterlist src_sg[2];
> struct mutex *tfm_mutex;
> struct blkcipher_desc desc = {
> .flags = CRYPTO_TFM_REQ_MAY_SLEEP
> };
> int rc = 0;
>
> - sg_init_table(&dst_sg, 1);
> - sg_init_table(&src_sg, 1);
> -
> if (unlikely(ecryptfs_verbosity > 0)) {
> ecryptfs_printk(
> KERN_DEBUG, "Session key encryption key (size [%d]):
",
> @@ -1066,8 +1063,8 @@ decrypt_passphrase_encrypted_session_key(struct ecryptfs_auth_tok *auth_tok,
> }
> rc = virt_to_scatterlist(auth_tok->session_key.encrypted_key,
> auth_tok->session_key.encrypted_key_size,
> - &src_sg, 1);
> - if (rc != 1) {
> + src_sg, 2);
> + if (rc < 1 || rc > 2) {
> printk(KERN_ERR "Internal error whilst attempting to convert "
> "auth_tok->session_key.encrypted_key to scatterlist; "
> "expected rc = 1; got rc = [%d]. "
> @@ -1079,8 +1076,8 @@ decrypt_passphrase_encrypted_session_key(struct ecryptfs_auth_tok *auth_tok,
> auth_tok->session_key.encrypted_key_size;
> rc = virt_to_scatterlist(auth_tok->session_key.decrypted_key,
> auth_tok->session_key.decrypted_key_size,
> - &dst_sg, 1);
> - if (rc != 1) {
> + dst_sg, 2);
> + if (rc < 1 || rc > 2) {
> printk(KERN_ERR "Internal error whilst attempting to convert "
> "auth_tok->session_key.decrypted_key to scatterlist; "
> "expected rc = 1; got rc = [%d]
", rc);
> @@ -1096,7 +1093,7 @@ decrypt_passphrase_encrypted_session_key(struct ecryptfs_auth_tok *auth_tok,
> rc = -EINVAL;
> goto out;
> }
> - rc = crypto_blkcipher_decrypt(&desc, &dst_sg, &src_sg,
> + rc = crypto_blkcipher_decrypt(&desc, dst_sg, src_sg,
> auth_tok->session_key.encrypted_key_size);
> mutex_unlock(tfm_mutex);
> if (unlikely(rc)) {
> @@ -1541,8 +1538,8 @@ write_tag_3_packet(char *dest, size_t *remaining_bytes,
> size_t i;
> size_t encrypted_session_key_valid = 0;
> char session_key_encryption_key[ECRYPTFS_MAX_KEY_BYTES];
> - struct scatterlist dst_sg;
> - struct scatterlist src_sg;
> + struct scatterlist dst_sg[2];
> + struct scatterlist src_sg[2];
> struct mutex *tfm_mutex = NULL;
> u8 cipher_code;
> size_t packet_size_length;
> @@ -1621,8 +1618,8 @@ write_tag_3_packet(char *dest, size_t *remaining_bytes,
> ecryptfs_dump_hex(session_key_encryption_key, 16);
> }
> rc = virt_to_scatterlist(crypt_stat->key, key_rec->enc_key_size,
> - &src_sg, 1);
> - if (rc != 1) {
> + src_sg, 2);
> + if (rc < 1 || rc > 2) {
> ecryptfs_printk(KERN_ERR, "Error generating scatterlist "
> "for crypt_stat session key; expected rc = 1; "
> "got rc = [%d]. key_rec->enc_key_size = [%d]
",
> @@ -1631,8 +1628,8 @@ write_tag_3_packet(char *dest, size_t *remaining_bytes,
> goto out;
> }
> rc = virt_to_scatterlist(key_rec->enc_key, key_rec->enc_key_size,
> - &dst_sg, 1);
> - if (rc != 1) {
> + dst_sg, 2);
> + if (rc < 1 || rc > 2) {
> ecryptfs_printk(KERN_ERR, "Error generating scatterlist "
> "for crypt_stat encrypted session key; "
> "expected rc = 1; got rc = [%d]. "
> @@ -1653,7 +1650,7 @@ write_tag_3_packet(char *dest, size_t *remaining_bytes,
> rc = 0;
> ecryptfs_printk(KERN_DEBUG, "Encrypting [%d] bytes of the key
",
> crypt_stat->key_size);
> - rc = crypto_blkcipher_encrypt(&desc, &dst_sg, &src_sg,
> + rc = crypto_blkcipher_encrypt(&desc, dst_sg, src_sg,
> (*key_rec).enc_key_size);
> mutex_unlock(tfm_mutex);
> if (rc) {



--
kernel-team mailing list
kernel-team@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/kernel-team

This is a multi-part message in MIME format.Michael Halcrow wrote:
> On Tue, Nov 18, 2008 at 01:38:31PM -0700, Tim Gardner wrote:
>> This patch is being proposed as an SRU to Intrepid, but I'm having a
>> hard time reconciling the description with the actual function of
>> the patch.
>>
>> Allocating multiple scatterlist structures has nothing to do with
>> alignment, but what it _does_ do is correctly consume the second S/G
>> entry if the buffer passed to virt_to_scatterlist() crosses a page
>> boundary, correct?
>
> That is correct. The patch compensates for the fact that the key value
> may not fit in a single page.
>
>> It seems to me that the bug occurs if the virtual pages consumed by
>> the buffer are not physically contiguous.
>>
>> rtg

Do you mind if I re-write the commit log a little bit? See attached.

It looks like a legitimate bug possibility to me, and should be
submitted as a stable update once it lands upstream.

rtg
--
Tim Gardner tim.gardner@canonical.com

On Tue, Nov 18, 2008 at 02:28:00PM -0700, Tim Gardner wrote:
> Michael Halcrow wrote:
> > On Tue, Nov 18, 2008 at 01:38:31PM -0700, Tim Gardner wrote:
> >> This patch is being proposed as an SRU to Intrepid, but I'm having a
> >> hard time reconciling the description with the actual function of
> >> the patch.
> >>
> >> Allocating multiple scatterlist structures has nothing to do with
> >> alignment, but what it _does_ do is correctly consume the second S/G
> >> entry if the buffer passed to virt_to_scatterlist() crosses a page
> >> boundary, correct?
> >
> > That is correct. The patch compensates for the fact that the key value
> > may not fit in a single page.
> >
> >> It seems to me that the bug occurs if the virtual pages consumed by
> >> the buffer are not physically contiguous.
> >>
> >> rtg
>
> Do you mind if I re-write the commit log a little bit? See attached.

That looks fine to me.

> It looks like a legitimate bug possibility to me, and should be
> submitted as a stable update once it lands upstream.

Yes, I have sent this patch to Andrew Morton and am waiting for it to
be merged. This patch should be flagged for inclusion into stable.

> rtg

> >From fc54e8c0062d75a7c44bc4edab59303bc410870d Mon Sep 17 00:00:00 2001
> From: Jim Lieb <lieb@jim-laptop.home.sea-troll.net>
> Date: Fri, 14 Nov 2008 14:03:54 -0800
> Subject: [PATCH] UBUNTU: SAUCE: Encryption keys can span a page boundary
>
> OriginalAuthor: Michael Halcrow <mhalcrow@us.ibm.com>
> Bug: #292429
>
> Key buffers sent to virt_to_scatterlist() may span a page boundary. If the virtual pages are not
> physically contiguous, an error occurs when the second part of the key is lost. Using a 2 element
> scatterlist array allows virt_to_scatterlist() to correclty consume the second array element when the
> key buffer spans a page boundary.
>
> This patch is not in the upstream yet. We expect it may appear
> in a different form later.
>
> Committer: Jim Lieb <lieb@canonical.com>
> Signed-off-by: Michael Halcrow <mhalcrow@us.ibm.com>
> Signed-off-by: Jim Lieb <jim.lieb@canonical.com>
> Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
> ---
> fs/ecryptfs/keystore.c | 31 ++++++++++++++-----------------
> 1 files changed, 14 insertions(+), 17 deletions(-)
>
> diff --git a/fs/ecryptfs/keystore.c b/fs/ecryptfs/keystore.c
> index f5b76a3..59b9833 100644
> --- a/fs/ecryptfs/keystore.c
> +++ b/fs/ecryptfs/keystore.c
> @@ -1037,17 +1037,14 @@ static int
> decrypt_passphrase_encrypted_session_key(struct ecryptfs_auth_tok *auth_tok,
> struct ecryptfs_crypt_stat *crypt_stat)
> {
> - struct scatterlist dst_sg;
> - struct scatterlist src_sg;
> + struct scatterlist dst_sg[2];
> + struct scatterlist src_sg[2];
> struct mutex *tfm_mutex;
> struct blkcipher_desc desc = {
> .flags = CRYPTO_TFM_REQ_MAY_SLEEP
> };
> int rc = 0;
>
> - sg_init_table(&dst_sg, 1);
> - sg_init_table(&src_sg, 1);
> -
> if (unlikely(ecryptfs_verbosity > 0)) {
> ecryptfs_printk(
> KERN_DEBUG, "Session key encryption key (size [%d]):
",
> @@ -1066,8 +1063,8 @@ decrypt_passphrase_encrypted_session_key(struct ecryptfs_auth_tok *auth_tok,
> }
> rc = virt_to_scatterlist(auth_tok->session_key.encrypted_key,
> auth_tok->session_key.encrypted_key_size,
> - &src_sg, 1);
> - if (rc != 1) {
> + src_sg, 2);
> + if (rc < 1 || rc > 2) {
> printk(KERN_ERR "Internal error whilst attempting to convert "
> "auth_tok->session_key.encrypted_key to scatterlist; "
> "expected rc = 1; got rc = [%d]. "
> @@ -1079,8 +1076,8 @@ decrypt_passphrase_encrypted_session_key(struct ecryptfs_auth_tok *auth_tok,
> auth_tok->session_key.encrypted_key_size;
> rc = virt_to_scatterlist(auth_tok->session_key.decrypted_key,
> auth_tok->session_key.decrypted_key_size,
> - &dst_sg, 1);
> - if (rc != 1) {
> + dst_sg, 2);
> + if (rc < 1 || rc > 2) {
> printk(KERN_ERR "Internal error whilst attempting to convert "
> "auth_tok->session_key.decrypted_key to scatterlist; "
> "expected rc = 1; got rc = [%d]
", rc);
> @@ -1096,7 +1093,7 @@ decrypt_passphrase_encrypted_session_key(struct ecryptfs_auth_tok *auth_tok,
> rc = -EINVAL;
> goto out;
> }
> - rc = crypto_blkcipher_decrypt(&desc, &dst_sg, &src_sg,
> + rc = crypto_blkcipher_decrypt(&desc, dst_sg, src_sg,
> auth_tok->session_key.encrypted_key_size);
> mutex_unlock(tfm_mutex);
> if (unlikely(rc)) {
> @@ -1541,8 +1538,8 @@ write_tag_3_packet(char *dest, size_t *remaining_bytes,
> size_t i;
> size_t encrypted_session_key_valid = 0;
> char session_key_encryption_key[ECRYPTFS_MAX_KEY_BYTES];
> - struct scatterlist dst_sg;
> - struct scatterlist src_sg;
> + struct scatterlist dst_sg[2];
> + struct scatterlist src_sg[2];
> struct mutex *tfm_mutex = NULL;
> u8 cipher_code;
> size_t packet_size_length;
> @@ -1621,8 +1618,8 @@ write_tag_3_packet(char *dest, size_t *remaining_bytes,
> ecryptfs_dump_hex(session_key_encryption_key, 16);
> }
> rc = virt_to_scatterlist(crypt_stat->key, key_rec->enc_key_size,
> - &src_sg, 1);
> - if (rc != 1) {
> + src_sg, 2);
> + if (rc < 1 || rc > 2) {
> ecryptfs_printk(KERN_ERR, "Error generating scatterlist "
> "for crypt_stat session key; expected rc = 1; "
> "got rc = [%d]. key_rec->enc_key_size = [%d]
",
> @@ -1631,8 +1628,8 @@ write_tag_3_packet(char *dest, size_t *remaining_bytes,
> goto out;
> }
> rc = virt_to_scatterlist(key_rec->enc_key, key_rec->enc_key_size,
> - &dst_sg, 1);
> - if (rc != 1) {
> + dst_sg, 2);
> + if (rc < 1 || rc > 2) {
> ecryptfs_printk(KERN_ERR, "Error generating scatterlist "
> "for crypt_stat encrypted session key; "
> "expected rc = 1; got rc = [%d]. "
> @@ -1653,7 +1650,7 @@ write_tag_3_packet(char *dest, size_t *remaining_bytes,
> rc = 0;
> ecryptfs_printk(KERN_DEBUG, "Encrypting [%d] bytes of the key
",
> crypt_stat->key_size);
> - rc = crypto_blkcipher_encrypt(&desc, &dst_sg, &src_sg,
> + rc = crypto_blkcipher_encrypt(&desc, dst_sg, src_sg,
> (*key_rec).enc_key_size);
> mutex_unlock(tfm_mutex);
> if (rc) {

--
kernel-team mailing list
kernel-team@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/kernel-team

On Tue, 18 Nov 2008 15:54:01 -0600
Michael Halcrow <mhalcrow@us.ibm.com> wrote:

> > It looks like a legitimate bug possibility to me, and should be
> > submitted as a stable update once it lands upstream.
>
> Yes, I have sent this patch to Andrew Morton and am waiting for it to
> be merged. This patch should be flagged for inclusion into stable.

I have this patch in a holding pattern awaiting a reply to Leon
Woestenberg's comments.


--
kernel-team mailing list
kernel-team@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/kernel-team

Tim Gardner wrote:
> Stefan,
>
> Dunno if you saw this on the list awhile back, but it looks like a

No, that mail must somehow slipped by or drowned somewhere. The patch
description rings a distant bell, though.

> candidate for stable update. It cherry-pickled cleanly from 2.6.25.y to
> Hardy, but I haven't pushed from my repo pending your thoughts on the issue.

This definitely looks like a candidate. ACK from me. It should go in with the
next -proposed round.

>
> rtg
>
>
> ------------------------------------------------------------------------
>
> Subject:
> (fwd) BUG: mmapfile/writev spurious zero bytes still in the wild
> From:
> Bron Gondwana <brong@fastmail.fm>
> Date:
> Sat, 4 Oct 2008 10:30:06 +1000
> To:
> Ubuntu Kernel Team <kernel-team@lists.ubuntu.com>
>
> To:
> Ubuntu Kernel Team <kernel-team@lists.ubuntu.com>
> CC:
> emlists@gmail.com
>
>
> I should have just added you as CC. I've tried reporting this via
> launchpad, but it just keeps timing out on me again
>
> I'm also CCing the user who reported the problem to me. He's running
> 2.6.14-19-xen, but the problem exists in all 64 bit kernels in Ubuntu
> if it exists in one. This causes massive data corruption to Cyrus
> running on kernels between 2.6.23 and 2.6.25.8.
>
> You can read the full backthread here:
>
> http://lkml.org/lkml/2008/6/17/9
>
> Linus posted the patch here:
>
> http://lkml.org/lkml/2008/6/17/234
>
> And the fix was rolled into 2.6.25.8:
>
> commit 864f24395c72b6a6c48d13f409f986dc71a5cf4a
> Author: Linus Torvalds <torvalds@linux-foundation.org>
> Date: Tue Jun 17 17:47:50 2008 -0700
>
> x86-64: Fix "bytes left to copy" return value for copy_from_user()
>
> commit 42a886af728c089df8da1b0017b0e7e6c81b5335 upstream
>
> Most users by far do not care about the exact return value (they only
> really care about whether the copy succeeded in its entirety or not),
> but a few special core routines actually care deeply about exactly how
> many bytes were copied from user space.
>
> And the unrolled versions of the x86-64 user copy routines would
> sometimes report that it had copied more bytes than it actually had.
>
> Very few uses actually have partial copies to begin with, but to make
> this bug even harder to trigger, most x86 CPU's use the "rep string"
> instructions for normal user copies, and that version didn't have this
> issue.
>
> To make it even harder to hit, the one user of this that really cared
> about the return value (and used the uncached version of the copy that
> doesn't use the "rep string" instructions) was the generic write
> routine, which pre-populated its source, once more hiding the problem by
> avoiding the exception case that triggers the bug.
>
> In other words, very special thanks to Bron Gondwana who not only
> triggered this, but created a test-program to show it, and bisected the
> behavior down to commit 08291429cfa6258c4cd95d8833beb40f828b194e ("mm:
> fix pagecache write deadlocks") which changed the access pattern just
> enough that you can now trigger it with 'writev()' with multiple
> iovec's.
>
> That commit itself was not the cause of the bug, it just allowed all the
> stars to align just right that you could trigger the problem.
>
> [ Side note: this is just the minimal fix to make the copy routines
> (with __copy_from_user_inatomic_nocache as the particular version that
> was involved in showing this) have the right return values.
>
> We really should improve on the exceptional case further - to make the
> copy do a byte-accurate copy up to the exact page limit that causes it
> to fail. As it is, the callers have to do extra work to handle the
> limit case gracefully. ]
>
> Reported-by: Bron Gondwana <brong@fastmail.fm>
> Cc: Nick Piggin <npiggin@suse.de>
> Cc: Andrew Morton <akpm@linux-foundation.org>
> Cc: Andi Kleen <andi@firstfloor.org>
> Cc: Al Viro <viro@ZenIV.linux.org.uk>
> Acked-by: Ingo Molnar <mingo@elte.hu>
> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
>
>
> ----- Forwarded message from Bron Gondwana <brong@fastmail.fm> -----
>
> Date: Fri, 3 Oct 2008 21:44:14 +1000
> From: Bron Gondwana <brong@fastmail.fm>
> Subject: BUG: mmapfile/writev spurious zero bytes still in the wild
> Cc: Bron Gondwana <brong@fastmail.fm>,
> Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
> Nick Piggin <npiggin@suse.de>,
> Andrew Morton <akpm@linux-foundation.org>,
> Rob Mueller <robm@fastmail.fm>, Andi Kleen <andi@firstfloor.org>,
> Ingo Molnar <mingo@elte.hu>
> To: Linus Torvalds <torvalds@linux-foundation.org>
> Organization: brong.net
>
> On Tue, Jun 17, 2008 at 02:20:49PM -0700, Linus Torvalds wrote:
>
> [reminder from way back: this bug was caused by writev containing
> mmaped pages that weren't paged in, it's 64 bit only. It
> particularly affects Cyrus Imapd's database formats]
>
>> On Tue, 17 Jun 2008, Linus Torvalds wrote:
>>> Hmm. Something like this *may* salvage it.
>>>
>>> Untested, so far (I'll reboot and test soon enough), but even if it fixes
>>> things, it's not really very good.
>> Ok, so I just rebooted with this, and it does indeed fix the bug.
>>
>> I'd be happier with a more complete fix (ie being byte-accurate and
>> actually doing the partial copy when it hits a fault in the middle), but
>> this seems to be the minimal fix, and at least fixes the totally bogus
>> return values from the x86-64 __copy_user*() functions.
>
> Has this been revisited since? I haven't noticed, but I really only
> skim LKML - have to save some time in the day for my real job[tm] of
> keeping an email service running!
>
>> Not that I checked that I got _all_ cases correct (and maybe there are
>> other versions of __copy_user that I missed entirely), but Bron's
>> test-case at least seems to work properly for me now.
>>
>> Bron? If you have a more complete test-suite (ie the real-world case that
>> made you find this), it would be good to verify the whole thing.
>
> It's been fine for us since, but unfortunately most of the world is
> still running distribution "stable" kernels. I've just been helping a
> user who's getting corrupted flat file databases on Ubuntu's stable 64
> bit xen kernels, and it looks like it's the same issue.
>
> Is there a standard way to tell backporters "you really need to add this
> patch for your users' sanity"?
>
> Bron ( I tried reporting it in Launchpad, but kept getting timeout
> errors, so I figured reposting here might get noticed. Besides,
> I can follow up on the "more complete fix" at the same time! )
>
> ----- End forwarded message -----
>


--

When all other means of communication fail, try words!



--
kernel-team mailing list
kernel-team@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/kernel-team

Stefan Bader wrote:
> Tim Gardner wrote:
>> Stefan,
>>
>> Dunno if you saw this on the list awhile back, but it looks like a
>
> No, that mail must somehow slipped by or drowned somewhere. The patch
> description rings a distant bell, though.
>
>> candidate for stable update. It cherry-pickled cleanly from 2.6.25.y to
>> Hardy, but I haven't pushed from my repo pending your thoughts on the
>> issue.
>
> This definitely looks like a candidate. ACK from me. It should go in
> with the next -proposed round.
>

pushed. It'll show up with the rest of the upstream updates when you
incorporate all of the stable patches.

rtg
--
Tim Gardner tim.gardner@canonical.com

--
kernel-team mailing list
kernel-team@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/kernel-team

Please test.

-------- Original Message --------
Subject: [Bug 294914] Re: Intrepid has no GUI method to configure
network interfaces
Date: Thu, 20 Nov 2008 08:53:48 -0000
From: Martin Pitt <martin.pitt@ubuntu.com>
Reply-To: Bug 294914 <294914@bugs.launchpad.net>
To: coryisatm@ubuntu.com
References: <20081106232925.23982.85446.malonedeb@gandwana.can onical.com>



Accepted into intrepid-proposed, please test and give feedback here.
Please see https://wiki.ubuntu.com/Testing/EnableProposed for
documentation how to enable and use -proposed. Thank you in advance!

** Changed in: ubuntustudio-meta (Ubuntu Intrepid)
Status: Confirmed => Fix Committed

--
Intrepid has no GUI method to configure network interfaces
https://bugs.launchpad.net/bugs/294914
You received this bug notification because you are a member of Ubuntu
Studio-dev, which is subscribed to ubuntustudio-meta in ubuntu.



--
Ubuntu-Studio-users mailing list
Ubuntu-Studio-users@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-studio-users

Making sure this gets seen by Artwork; I think this was supposed to be
a list reply, right? If not, I'll apologize in advance... :-)

Paul

----- Forwarded message from Karlie Robinson <karlie_robinson@webpath.net> -----

Date: Thu, 20 Nov 2008 12:35:56 -0500
From: Karlie Robinson <karlie_robinson@webpath.net>
To: "Paul W. Frields" <stickster@gmail.com>
Subject: Re: Package Front Mock-up

I'm using the GIMP and I've changed it to one of the shades of blue from
the solar image.

Just that I need to flop the logos on this once I get the officially
licensed image from OLPC and get it to the printer this afternoon.

I'm using a 4.25 by 6.25 inch image at 200DPI or 850x1250px so that I have
a 800x1200 final print area when the 1/8 inch bleed is cut off all 4 sides.

If someone can shoot me a logo that looks good sitting on top of the Solar
desktop, I'll take it.

Paul W. Frields wrote:
> On Thu, Nov 20, 2008 at 12:03:15PM -0500, Karlie Robinson wrote:
>
>> Try it now -
>> http://on-disk.com/cms/edit/data/files//package-front-mockup.jpg
>>
>
> Actually, I'd suggest using black for the shadow, and having it blur
> around the edges of the entire logo, as opposed to being diagonally
> offset. That way the black blur will surround the whole thing.
>
> It would probably be a good idea to have the Artwork team involved in
> this so that we can make sure the design follows the general
> principles for everything else for Fedora 10. Having a unified and
> consistent presentation is a very good thing for marketing purposes.
>
> What tool are you using to create this? Is it a free tool that our
> Artwork team can use along with source you provide?
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Fedora-olpc-list mailing list
> Fedora-olpc-list@redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-olpc-list

----- End forwarded message -----

--
Paul W. Frields http://paul.frields.org/
gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717
http://redhat.com/ - - - - http://pfrields.fedorapeople.org/
irc.freenode.net: stickster @ #fedora-docs, #fedora-devel, #fredlug
_______________________________________________
Fedora-art-list mailing list
Fedora-art-list@redhat.com
http://www.redhat.com/mailman/listinfo/fedora-art-list

For your consideration.

-------- Forwarded Message --------
> From: Rick Noelle <Rick.Noelle@definition6.com>
> To: webmaster@fedoraproject.org
> Subject: User signup not working?
> Date: Thu, 20 Nov 2008 12:19:25 -0500
>
> Hi,
>
>
>
> I’m trying to sign up for a fedora login but I did not receive my
> initial email with my password. I tried the “Forgot Password� link as
> well and it reported that a password reminder has been sent but I did
> not receive it. I’ve tested the recipient email address and made sure
> spam filters are disabled, etc. but not having much luck. The login I
> created is “jdictionary� and the email address is
> rick@jdictionary.com.
>
>
>
> Thanks a lot,
>
> Rick Noelle
>
>
>
>
--
Ignacio Vazquez-Abrams <ivazqueznet@gmail.com>
_______________________________________________
Fedora-infrastructure-list mailing list
Fedora-infrastructure-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list

I've sent a reply.

-Mike

On Thu, 20 Nov 2008, Ignacio Vazquez-Abrams wrote:

> For your consideration.
>
> -------- Forwarded Message --------
> > From: Rick Noelle <Rick.Noelle@definition6.com>
> > To: webmaster@fedoraproject.org
> > Subject: User signup not working?
> > Date: Thu, 20 Nov 2008 12:19:25 -0500
> >
> > Hi,
> >
> >
> >
> > I’m trying to sign up for a fedora login but I did not receive my
> > initial email with my password. I tried the “Forgot Password� link as
> > well and it reported that a password reminder has been sent but I did
> > not receive it. I’ve tested the recipient email address and made sure
> > spam filters are disabled, etc. but not having much luck. The login I
> > created is “jdictionary� and the email address is
> > rick@jdictionary.com.
> >
> >
> >
> > Thanks a lot,
> >
> > Rick Noelle
> >
> >
> >
> >
> --
> Ignacio Vazquez-Abrams <ivazqueznet@gmail.com>
>_______________________________________________
Fedora-infrastructure-list mailing list
Fedora-infrastructure-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list