All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jeff Mahoney <jeffm@suse.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: balbir@linux.vnet.ibm.com, Dan Carpenter <error27@gmail.com>,
	Brian Rogers <brian@xyzw.org>,
	linux-kernel@vger.kernel.org,
	Guillaume Chazarain <guichaz@gmail.com>
Subject: Re: [patch] delayacct: fix iotop on x86_64
Date: Tue, 14 Dec 2010 15:21:09 -0500	[thread overview]
Message-ID: <4D07D1B5.1060505@suse.com> (raw)
In-Reply-To: <20101214121641.7c337509.akpm@linux-foundation.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 12/14/2010 03:16 PM, Andrew Morton wrote:
> On Tue, 14 Dec 2010 13:32:39 +0530
> Balbir Singh <balbir@linux.vnet.ibm.com> wrote:
> 
>> * Dan Carpenter <error27@gmail.com> [2010-12-14 10:02:43]:
>>
>>> We changed how the taskstats was exported to user space in:
>>> 85893120699 "delayacct: align to 8 byte boundary on 64-bit systems"
>>> This was important because it fixes a run time warning on IA64.  In
>>> theory it shouldn't have broken anything, if you just assume that user
>>> space programmers don't smoke crack all day long.
>>>
>>> But actually it breaks iotop on x86_64.
>>>
>>> Reported-by: Brian Rogers <brian@xyzw.org>
>>> Signed-off-by: Dan Carpenter <error27@gmail.com>
>>>
>>> diff --git a/kernel/taskstats.c b/kernel/taskstats.c
>>> index c8231fb..a0758de 100644
>>> --- a/kernel/taskstats.c
>>> +++ b/kernel/taskstats.c
>>> @@ -358,7 +358,19 @@ static struct taskstats *mk_reply(struct sk_buff *skb, int type, u32 pid)
>>>  	 * This causes lots of runtime warnings on systems requiring 8 byte
>>>  	 * alignment */
>>>  	u32 pids[2] = { pid, 0 };
>>> -	int pid_size = ALIGN(sizeof(pid), sizeof(long));
>>> +	int pid_size;
>>> +
>>> +	/*
>>> +	 * IA64 can't be aligned on a 4 byte boundary.  But iotop on x86_64
>>> +	 * depends on the current struct layout.  The next version of iotop
>>> +	 * will fix this so maybe we can move everything to the new code in
>>> +	 * a couple years.
>>> +	 */
>>> +#if defined(CONFIG_IA64)
>>> +	pid_size = ALIGN(sizeof(pid), sizeof(long));
>>> +#else
>>> +	pid_size = sizeof(u32);
>>> +#endif
>>
>> I would rather abstract this better
> 
> Well.  Abstracting something tends to make it permanent.  When you have
> an ugly, special-case temporary hack, there is merit to having it
> sitting there in the middle of the code staring you in the face.  It's
> very explicit and we won't forget about it.
> 
>> and I'd be apprehensive about the
>> fix if iotop was at fault to begin with, I would rather fix iotop.
>> IOW, are we fixing what iotop got wrong? Isn't it easier to backport
>> the correct behaviour in iotop. I understand we broke the ABI, but
>> user space can still live.
> 
> Nah, let's not knowingly break a userspace app.
> 
> 
> This is a versioned interface, is it not?  How is that supposed
> to work?  Should we have upped the version number when making this
> change?

Perhaps. Balbir suggested it, but it didn't make it into the final
version. Not that it would have mattered. iotop doesn't look at the
version anyway.

- -Jeff

- -- 
Jeff Mahoney
SUSE Labs
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.16 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/

iEYEARECAAYFAk0H0bUACgkQLPWxlyuTD7LJlwCeKLRuVKXIwZi7XMARDNXmBxkj
QC0An0up3AVv/G8T8JZbb+cpDFagKnj0
=ra4a
-----END PGP SIGNATURE-----

  reply	other threads:[~2010-12-14 20:21 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-12-13 11:37 delayacct: alignment changes break iotop Dan Carpenter
2010-12-13 12:57 ` Balbir Singh
2010-12-13 13:10   ` Dan Carpenter
2010-12-13 15:20   ` Jeff Mahoney
2010-12-13 20:56     ` Brian Rogers
2010-12-13 21:22       ` Dan Carpenter
2010-12-14  7:02         ` [patch] delayacct: fix iotop on x86_64 Dan Carpenter
2010-12-14  8:02           ` Balbir Singh
2010-12-14  8:16             ` Dan Carpenter
2010-12-14 20:16             ` Andrew Morton
2010-12-14 20:21               ` Jeff Mahoney [this message]
2010-12-15  7:10               ` Balbir Singh

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=4D07D1B5.1060505@suse.com \
    --to=jeffm@suse.com \
    --cc=akpm@linux-foundation.org \
    --cc=balbir@linux.vnet.ibm.com \
    --cc=brian@xyzw.org \
    --cc=error27@gmail.com \
    --cc=guichaz@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.