<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-toradex.git, branch v2.6.20.12</title>
<subtitle>Linux kernel for Apalis and Colibri modules</subtitle>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/'/>
<entry>
<title>Linux 2.6.20.12</title>
<updated>2007-05-24T21:21:02+00:00</updated>
<author>
<name>Chris Wright</name>
<email>chrisw@sous-sol.org</email>
</author>
<published>2007-05-24T21:21:02+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=fcfbb42bd476ed54b598d917d3b9b63d8835093e'/>
<id>fcfbb42bd476ed54b598d917d3b9b63d8835093e</id>
<content type='text'>
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
</pre>
</div>
</content>
</entry>
<entry>
<title>[PATCH] GEODE-AES: Allow in-place operations [CVE-2007-2451]</title>
<updated>2007-05-24T21:20:43+00:00</updated>
<author>
<name>Jordan Crouse</name>
<email>jordan.crouse@amd.com</email>
</author>
<published>2007-05-24T11:36:35+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=f66e4a9471d067a04d53904890dc1b84208cdda9'/>
<id>f66e4a9471d067a04d53904890dc1b84208cdda9</id>
<content type='text'>
Allow in-place crypto operations.  Also remove the coherent user flag
(we use it automagically now), and by default use the user written
key rather then the HW hidden key - this makes crypto just work without
any special considerations, and thats OK, since its our only usage
model.

Signed-off-by: Jordan Crouse &lt;jordan.crouse@amd.com&gt;
Signed-off-by: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;
Signed-off-by: Chris Wright &lt;chrisw@sous-sol.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Allow in-place crypto operations.  Also remove the coherent user flag
(we use it automagically now), and by default use the user written
key rather then the HW hidden key - this makes crypto just work without
any special considerations, and thats OK, since its our only usage
model.

Signed-off-by: Jordan Crouse &lt;jordan.crouse@amd.com&gt;
Signed-off-by: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;
Signed-off-by: Chris Wright &lt;chrisw@sous-sol.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Linux 2.6.20.11</title>
<updated>2007-05-02T00:34:12+00:00</updated>
<author>
<name>Greg Kroah-Hartman</name>
<email>gregkh@suse.de</email>
</author>
<published>2007-05-02T00:34:12+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=6b99a1744ab187073bca84a9fd3ccbf091865ca6'/>
<id>6b99a1744ab187073bca84a9fd3ccbf091865ca6</id>
<content type='text'>
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
</pre>
</div>
</content>
</entry>
<entry>
<title>Revert "adjust legacy IDE resource setting (v2)"</title>
<updated>2007-05-02T00:06:03+00:00</updated>
<author>
<name>Bartlomiej Zolnierkiewicz</name>
<email>bzolnier@gmail.com</email>
</author>
<published>2007-04-25T20:18:52+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=481576e9872a6366227bce3838f566a3fa338d81'/>
<id>481576e9872a6366227bce3838f566a3fa338d81</id>
<content type='text'>
Revert "adjust legacy IDE resource setting (v2)"

This reverts commit ed8ccee0918ad063a4741c0656fda783e02df627.

It causes hang on boot for some users and we don't yet know why:

http://bugzilla.kernel.org/show_bug.cgi?id=7562

http://lkml.org/lkml/2007/4/20/404
http://lkml.org/lkml/2007/3/25/113

Just reverse it for 2.6.21-final, having broken X server is somehow
better than unbootable system.

Signed-off-by: Bartlomiej Zolnierkiewicz &lt;bzolnier@gmail.com&gt;
Cc: Chuck Ebbert &lt;cebbert@redhat.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Revert "adjust legacy IDE resource setting (v2)"

This reverts commit ed8ccee0918ad063a4741c0656fda783e02df627.

It causes hang on boot for some users and we don't yet know why:

http://bugzilla.kernel.org/show_bug.cgi?id=7562

http://lkml.org/lkml/2007/4/20/404
http://lkml.org/lkml/2007/3/25/113

Just reverse it for 2.6.21-final, having broken X server is somehow
better than unbootable system.

Signed-off-by: Bartlomiej Zolnierkiewicz &lt;bzolnier@gmail.com&gt;
Cc: Chuck Ebbert &lt;cebbert@redhat.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>cfq-iosched: fix alias + front merge bug</title>
<updated>2007-05-02T00:06:03+00:00</updated>
<author>
<name>Jens Axboe</name>
<email>jens.axboe@oracle.com</email>
</author>
<published>2007-04-25T11:42:27+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=3720eda544ece8fa5ade8c87e5f2cf2fb05b0ff5'/>
<id>3720eda544ece8fa5ade8c87e5f2cf2fb05b0ff5</id>
<content type='text'>
There's a really rare and obscure bug in CFQ, that causes a crash in
cfq_dispatch_insert() due to rq == NULL. One example of that is seen
here:

http://lkml.org/lkml/2007/4/15/41

Neil correctly diagnosed the situation for how this can happen, read
that analysis here:

http://lkml.org/lkml/2007/4/25/57

This looks like it requires md to trigger, even though it should
potentially be possible to due with O_DIRECT (at least if you edit the
kernel and doctor some of the unplug calls).

The fix is to move the -&gt;next_rq update to when we add a request to the
rbtree. Then we remove the possibility for a request to exist in the
rbtree code, but not have -&gt;next_rq correctly updated.

Signed-off-by: Jens Axboe &lt;jens.axboe@oracle.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
There's a really rare and obscure bug in CFQ, that causes a crash in
cfq_dispatch_insert() due to rq == NULL. One example of that is seen
here:

http://lkml.org/lkml/2007/4/15/41

Neil correctly diagnosed the situation for how this can happen, read
that analysis here:

http://lkml.org/lkml/2007/4/25/57

This looks like it requires md to trigger, even though it should
potentially be possible to due with O_DIRECT (at least if you edit the
kernel and doctor some of the unplug calls).

The fix is to move the -&gt;next_rq update to when we add a request to the
rbtree. Then we remove the possibility for a request to exist in the
rbtree code, but not have -&gt;next_rq correctly updated.

Signed-off-by: Jens Axboe &lt;jens.axboe@oracle.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>AGPGART: intel_agp: fix G965 GTT size detect</title>
<updated>2007-05-02T00:06:03+00:00</updated>
<author>
<name>Wang Zhenyu</name>
<email>zhenyu.z.wang@intel.com</email>
</author>
<published>2007-04-25T19:07:38+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=ab02a65798ea8b940ea5645655238c778d4e4765'/>
<id>ab02a65798ea8b940ea5645655238c778d4e4765</id>
<content type='text'>
[AGPGART] intel_agp: fix G965 GTT size detect

On G965, I810_PGETBL_CTL is a mmio offset, but we wrongly take it
as pci config space offset in detecting GTT size. This one line patch
fixs this.

Signed-off-by: Wang Zhenyu &lt;zhenyu.z.wang@intel.com&gt;
Signed-off-by: Dave Jones &lt;davej@redhat.com&gt;
Cc: Chuck Ebbert &lt;cebbert@redhat.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[AGPGART] intel_agp: fix G965 GTT size detect

On G965, I810_PGETBL_CTL is a mmio offset, but we wrongly take it
as pci config space offset in detecting GTT size. This one line patch
fixs this.

Signed-off-by: Wang Zhenyu &lt;zhenyu.z.wang@intel.com&gt;
Signed-off-by: Dave Jones &lt;davej@redhat.com&gt;
Cc: Chuck Ebbert &lt;cebbert@redhat.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>ALSA: intel8x0 - Fix speaker output after S2RAM</title>
<updated>2007-05-02T00:06:03+00:00</updated>
<author>
<name>Tommi Kyntola</name>
<email>tommi.kyntola@ray.fi</email>
</author>
<published>2007-04-25T19:05:50+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=27797cc764b52d417f5daf5703d4fa9f98867185'/>
<id>27797cc764b52d417f5daf5703d4fa9f98867185</id>
<content type='text'>
[ALSA] intel8x0 - Fix speaker output after S2RAM

Fixed the mute speaker problem after S2RAM on some laptops:
	http://bugme.osdl.org/show_bug.cgi?id=6181

Signed-off-by: Tommi Kyntola &lt;tommi.kyntola@ray.fi&gt;
Signed-off-by: Takashi Iwai &lt;tiwai@suse.de&gt;
Signed-off-by: Jaroslav Kysela &lt;perex@suse.cz&gt;
Cc: Chuck Ebbert &lt;cebbert@redhat.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;


</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ALSA] intel8x0 - Fix speaker output after S2RAM

Fixed the mute speaker problem after S2RAM on some laptops:
	http://bugme.osdl.org/show_bug.cgi?id=6181

Signed-off-by: Tommi Kyntola &lt;tommi.kyntola@ray.fi&gt;
Signed-off-by: Takashi Iwai &lt;tiwai@suse.de&gt;
Signed-off-by: Jaroslav Kysela &lt;perex@suse.cz&gt;
Cc: Chuck Ebbert &lt;cebbert@redhat.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;


</pre>
</div>
</content>
</entry>
<entry>
<title>hwmon/w83627ehf: Fix the fan5 clock divider write</title>
<updated>2007-05-02T00:06:02+00:00</updated>
<author>
<name>Jean Delvare</name>
<email>khali@linux-fr.org</email>
</author>
<published>2007-04-25T07:51:01+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=87b814c9a7e7316ae4ea64767dbd0ae2fd6c179d'/>
<id>87b814c9a7e7316ae4ea64767dbd0ae2fd6c179d</id>
<content type='text'>
Users have been complaining about the w83627ehf driver flooding their
logs with debug messages like:

w83627ehf 9191-0a10: Increasing fan 4 clock divider from 64 to 128

or:

w83627ehf 9191-0290: Increasing fan 4 clock divider from 4 to 8

The reason is that we failed to actually write the LSB of the encoded
clock divider value for that fan, causing the next read to report the
same old value again and again.

Additionally, the fan number was improperly reported, making the bug
harder to find.

Signed-off-by: Jean Delvare &lt;khali@linux-fr.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Users have been complaining about the w83627ehf driver flooding their
logs with debug messages like:

w83627ehf 9191-0a10: Increasing fan 4 clock divider from 64 to 128

or:

w83627ehf 9191-0290: Increasing fan 4 clock divider from 4 to 8

The reason is that we failed to actually write the LSB of the encoded
clock divider value for that fan, causing the next read to report the
same old value again and again.

Additionally, the fan number was improperly reported, making the bug
harder to find.

Signed-off-by: Jean Delvare &lt;khali@linux-fr.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>reiserfs: fix xattr root locking/refcount bug</title>
<updated>2007-05-02T00:06:02+00:00</updated>
<author>
<name>Jeff Mahoney</name>
<email>jeffm@suse.com</email>
</author>
<published>2007-04-23T21:41:17+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=1b3bac165e24b4e5711b8bcf3ca7e7a990f5a22c'/>
<id>1b3bac165e24b4e5711b8bcf3ca7e7a990f5a22c</id>
<content type='text'>
The listxattr() and getxattr() operations are only protected by a read
lock.  As a result, if either of these operations run in parallel, a race
condition exists where the xattr_root will end up being cached twice, which
results in the leaking of a reference and a BUG() on umount.

This patch refactors get_xa_root(), __get_xa_root(), and create_xa_root(),
into one get_xa_root() function that takes the appropriate locking around
the entire critical section.

Reported, diagnosed and tested by Andrea Righi &lt;a.righi@cineca.it&gt;

Signed-off-by: Jeff Mahoney &lt;jeffm@suse.com&gt;
Cc: Andrea Righi &lt;a.righi@cineca.it&gt;
Cc: "Vladimir V. Saveliev" &lt;vs@namesys.com&gt;
Cc: Edward Shishkin &lt;edward@namesys.com&gt;
Cc: Alex Zarochentsev &lt;zam@namesys.com&gt;
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The listxattr() and getxattr() operations are only protected by a read
lock.  As a result, if either of these operations run in parallel, a race
condition exists where the xattr_root will end up being cached twice, which
results in the leaking of a reference and a BUG() on umount.

This patch refactors get_xa_root(), __get_xa_root(), and create_xa_root(),
into one get_xa_root() function that takes the appropriate locking around
the entire critical section.

Reported, diagnosed and tested by Andrea Righi &lt;a.righi@cineca.it&gt;

Signed-off-by: Jeff Mahoney &lt;jeffm@suse.com&gt;
Cc: Andrea Righi &lt;a.righi@cineca.it&gt;
Cc: "Vladimir V. Saveliev" &lt;vs@namesys.com&gt;
Cc: Edward Shishkin &lt;edward@namesys.com&gt;
Cc: Alex Zarochentsev &lt;zam@namesys.com&gt;
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>Taskstats fix the structure members alignment issue</title>
<updated>2007-05-02T00:06:02+00:00</updated>
<author>
<name>Balbir Singh</name>
<email>balbir@in.ibm.com</email>
</author>
<published>2007-04-23T21:41:05+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=2b2c594d5faa4c85db286ed015df78ee02138eec'/>
<id>2b2c594d5faa4c85db286ed015df78ee02138eec</id>
<content type='text'>
We broke the the alignment of members of taskstats to the 8 byte boundary
with the CSA patches.  In the current kernel, the taskstats structure is
not suitable for use by 32 bit applications in a 64 bit kernel.

On x86_64

Offsets of taskstats' members (64 bit kernel, 64 bit application)

@taskstats'offsetof[@taskstats'indices] = (
        0,      # version
        4,      # ac_exitcode
        8,      # ac_flag
        9,      # ac_nice
        16,     # cpu_count
        24,     # cpu_delay_total
        32,     # blkio_count
        40,     # blkio_delay_total
        48,     # swapin_count
        56,     # swapin_delay_total
        64,     # cpu_run_real_total
        72,     # cpu_run_virtual_total
        80,     # ac_comm
        112,    # ac_sched
        113,    # ac_pad
        116,    # ac_uid
        120,    # ac_gid
        124,    # ac_pid
        128,    # ac_ppid
        132,    # ac_btime
        136,    # ac_etime
        144,    # ac_utime
        152,    # ac_stime
        160,    # ac_minflt
        168,    # ac_majflt
        176,    # coremem
        184,    # virtmem
        192,    # hiwater_rss
        200,    # hiwater_vm
        208,    # read_char
        216,    # write_char
        224,    # read_syscalls
        232,    # write_syscalls
        240,    # read_bytes
        248,    # write_bytes
        256,    # cancelled_write_bytes
    );

Offsets of taskstats' members (64 bit kernel, 32 bit application)

@taskstats'offsetof[@taskstats'indices] = (
        0,      # version
        4,      # ac_exitcode
        8,      # ac_flag
        9,      # ac_nice
        12,     # cpu_count
        20,     # cpu_delay_total
        28,     # blkio_count
        36,     # blkio_delay_total
        44,     # swapin_count
        52,     # swapin_delay_total
        60,     # cpu_run_real_total
        68,     # cpu_run_virtual_total
        76,     # ac_comm
        108,    # ac_sched
        109,    # ac_pad
        112,    # ac_uid
        116,    # ac_gid
        120,    # ac_pid
        124,    # ac_ppid
        128,    # ac_btime
        132,    # ac_etime
        140,    # ac_utime
        148,    # ac_stime
        156,    # ac_minflt
        164,    # ac_majflt
        172,    # coremem
        180,    # virtmem
        188,    # hiwater_rss
        196,    # hiwater_vm
        204,    # read_char
        212,    # write_char
        220,    # read_syscalls
        228,    # write_syscalls
        236,    # read_bytes
        244,    # write_bytes
        252,    # cancelled_write_bytes
    );

This is one way to solve the problem without re-arranging structure members
is to pack the structure.  The patch adds an __attribute__((aligned(8))) to
the taskstats structure members so that 32 bit applications using taskstats
can work with a 64 bit kernel.

Using __attribute__((packed)) would break the 64 bit alignment of members.

The fix was tested on x86_64. After the fix, we got

Offsets of taskstats' members (64 bit kernel, 64 bit application)

@taskstats'offsetof[@taskstats'indices] = (
        0,      # version
        4,      # ac_exitcode
        8,      # ac_flag
        9,      # ac_nice
        16,     # cpu_count
        24,     # cpu_delay_total
        32,     # blkio_count
        40,     # blkio_delay_total
        48,     # swapin_count
        56,     # swapin_delay_total
        64,     # cpu_run_real_total
        72,     # cpu_run_virtual_total
        80,     # ac_comm
        112,    # ac_sched
        113,    # ac_pad
        120,    # ac_uid
        124,    # ac_gid
        128,    # ac_pid
        132,    # ac_ppid
        136,    # ac_btime
        144,    # ac_etime
        152,    # ac_utime
        160,    # ac_stime
        168,    # ac_minflt
        176,    # ac_majflt
        184,    # coremem
        192,    # virtmem
        200,    # hiwater_rss
        208,    # hiwater_vm
        216,    # read_char
        224,    # write_char
        232,    # read_syscalls
        240,    # write_syscalls
        248,    # read_bytes
        256,    # write_bytes
        264,    # cancelled_write_bytes
    );

Offsets of taskstats' members (64 bit kernel, 32 bit application)

@taskstats'offsetof[@taskstats'indices] = (
        0,      # version
        4,      # ac_exitcode
        8,      # ac_flag
        9,      # ac_nice
        16,     # cpu_count
        24,     # cpu_delay_total
        32,     # blkio_count
        40,     # blkio_delay_total
        48,     # swapin_count
        56,     # swapin_delay_total
        64,     # cpu_run_real_total
        72,     # cpu_run_virtual_total
        80,     # ac_comm
        112,    # ac_sched
        113,    # ac_pad
        120,    # ac_uid
        124,    # ac_gid
        128,    # ac_pid
        132,    # ac_ppid
        136,    # ac_btime
        144,    # ac_etime
        152,    # ac_utime
        160,    # ac_stime
        168,    # ac_minflt
        176,    # ac_majflt
        184,    # coremem
        192,    # virtmem
        200,    # hiwater_rss
        208,    # hiwater_vm
        216,    # read_char
        224,    # write_char
        232,    # read_syscalls
        240,    # write_syscalls
        248,    # read_bytes
        256,    # write_bytes
        264,    # cancelled_write_bytes
    );

Signed-off-by: Balbir Singh &lt;balbir@linux.vnet.ibm.com&gt;
Cc: Jay Lan &lt;jlan@engr.sgi.com&gt;
Cc: Shailabh Nagar &lt;nagar@watson.ibm.com&gt;
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
We broke the the alignment of members of taskstats to the 8 byte boundary
with the CSA patches.  In the current kernel, the taskstats structure is
not suitable for use by 32 bit applications in a 64 bit kernel.

On x86_64

Offsets of taskstats' members (64 bit kernel, 64 bit application)

@taskstats'offsetof[@taskstats'indices] = (
        0,      # version
        4,      # ac_exitcode
        8,      # ac_flag
        9,      # ac_nice
        16,     # cpu_count
        24,     # cpu_delay_total
        32,     # blkio_count
        40,     # blkio_delay_total
        48,     # swapin_count
        56,     # swapin_delay_total
        64,     # cpu_run_real_total
        72,     # cpu_run_virtual_total
        80,     # ac_comm
        112,    # ac_sched
        113,    # ac_pad
        116,    # ac_uid
        120,    # ac_gid
        124,    # ac_pid
        128,    # ac_ppid
        132,    # ac_btime
        136,    # ac_etime
        144,    # ac_utime
        152,    # ac_stime
        160,    # ac_minflt
        168,    # ac_majflt
        176,    # coremem
        184,    # virtmem
        192,    # hiwater_rss
        200,    # hiwater_vm
        208,    # read_char
        216,    # write_char
        224,    # read_syscalls
        232,    # write_syscalls
        240,    # read_bytes
        248,    # write_bytes
        256,    # cancelled_write_bytes
    );

Offsets of taskstats' members (64 bit kernel, 32 bit application)

@taskstats'offsetof[@taskstats'indices] = (
        0,      # version
        4,      # ac_exitcode
        8,      # ac_flag
        9,      # ac_nice
        12,     # cpu_count
        20,     # cpu_delay_total
        28,     # blkio_count
        36,     # blkio_delay_total
        44,     # swapin_count
        52,     # swapin_delay_total
        60,     # cpu_run_real_total
        68,     # cpu_run_virtual_total
        76,     # ac_comm
        108,    # ac_sched
        109,    # ac_pad
        112,    # ac_uid
        116,    # ac_gid
        120,    # ac_pid
        124,    # ac_ppid
        128,    # ac_btime
        132,    # ac_etime
        140,    # ac_utime
        148,    # ac_stime
        156,    # ac_minflt
        164,    # ac_majflt
        172,    # coremem
        180,    # virtmem
        188,    # hiwater_rss
        196,    # hiwater_vm
        204,    # read_char
        212,    # write_char
        220,    # read_syscalls
        228,    # write_syscalls
        236,    # read_bytes
        244,    # write_bytes
        252,    # cancelled_write_bytes
    );

This is one way to solve the problem without re-arranging structure members
is to pack the structure.  The patch adds an __attribute__((aligned(8))) to
the taskstats structure members so that 32 bit applications using taskstats
can work with a 64 bit kernel.

Using __attribute__((packed)) would break the 64 bit alignment of members.

The fix was tested on x86_64. After the fix, we got

Offsets of taskstats' members (64 bit kernel, 64 bit application)

@taskstats'offsetof[@taskstats'indices] = (
        0,      # version
        4,      # ac_exitcode
        8,      # ac_flag
        9,      # ac_nice
        16,     # cpu_count
        24,     # cpu_delay_total
        32,     # blkio_count
        40,     # blkio_delay_total
        48,     # swapin_count
        56,     # swapin_delay_total
        64,     # cpu_run_real_total
        72,     # cpu_run_virtual_total
        80,     # ac_comm
        112,    # ac_sched
        113,    # ac_pad
        120,    # ac_uid
        124,    # ac_gid
        128,    # ac_pid
        132,    # ac_ppid
        136,    # ac_btime
        144,    # ac_etime
        152,    # ac_utime
        160,    # ac_stime
        168,    # ac_minflt
        176,    # ac_majflt
        184,    # coremem
        192,    # virtmem
        200,    # hiwater_rss
        208,    # hiwater_vm
        216,    # read_char
        224,    # write_char
        232,    # read_syscalls
        240,    # write_syscalls
        248,    # read_bytes
        256,    # write_bytes
        264,    # cancelled_write_bytes
    );

Offsets of taskstats' members (64 bit kernel, 32 bit application)

@taskstats'offsetof[@taskstats'indices] = (
        0,      # version
        4,      # ac_exitcode
        8,      # ac_flag
        9,      # ac_nice
        16,     # cpu_count
        24,     # cpu_delay_total
        32,     # blkio_count
        40,     # blkio_delay_total
        48,     # swapin_count
        56,     # swapin_delay_total
        64,     # cpu_run_real_total
        72,     # cpu_run_virtual_total
        80,     # ac_comm
        112,    # ac_sched
        113,    # ac_pad
        120,    # ac_uid
        124,    # ac_gid
        128,    # ac_pid
        132,    # ac_ppid
        136,    # ac_btime
        144,    # ac_etime
        152,    # ac_utime
        160,    # ac_stime
        168,    # ac_minflt
        176,    # ac_majflt
        184,    # coremem
        192,    # virtmem
        200,    # hiwater_rss
        208,    # hiwater_vm
        216,    # read_char
        224,    # write_char
        232,    # read_syscalls
        240,    # write_syscalls
        248,    # read_bytes
        256,    # write_bytes
        264,    # cancelled_write_bytes
    );

Signed-off-by: Balbir Singh &lt;balbir@linux.vnet.ibm.com&gt;
Cc: Jay Lan &lt;jlan@engr.sgi.com&gt;
Cc: Shailabh Nagar &lt;nagar@watson.ibm.com&gt;
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</pre>
</div>
</content>
</entry>
</feed>
