<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-toradex.git/include, branch v3.9.6</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>USB: serial: add generic wait_until_sent implementation</title>
<updated>2013-06-13T17:49:48+00:00</updated>
<author>
<name>Johan Hovold</name>
<email>jhovold@gmail.com</email>
</author>
<published>2013-05-08T15:51:43+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=9e8b683555a45f4cc290c1ec7dc8ab059d8d111b'/>
<id>9e8b683555a45f4cc290c1ec7dc8ab059d8d111b</id>
<content type='text'>
commit dcf0105039660e951dfea348d317043d17988dfc upstream.

Add generic wait_until_sent implementation which polls for empty
hardware buffers using the new port-operation tx_empty.

The generic implementation will be used for all sub-drivers that
implement tx_empty but does not define wait_until_sent.

Signed-off-by: Johan Hovold &lt;jhovold@gmail.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit dcf0105039660e951dfea348d317043d17988dfc upstream.

Add generic wait_until_sent implementation which polls for empty
hardware buffers using the new port-operation tx_empty.

The generic implementation will be used for all sub-drivers that
implement tx_empty but does not define wait_until_sent.

Signed-off-by: Johan Hovold &lt;jhovold@gmail.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>USB: serial: add wait_until_sent operation</title>
<updated>2013-06-13T17:49:48+00:00</updated>
<author>
<name>Johan Hovold</name>
<email>jhovold@gmail.com</email>
</author>
<published>2013-05-05T18:32:27+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=4d316eebd86e7745029e90a40311697a64c0f52c'/>
<id>4d316eebd86e7745029e90a40311697a64c0f52c</id>
<content type='text'>
commit 0693196fe7bbb5e6cafd255dfce91ff6d10bc18f upstream.

Add wait_until_sent operation which can be used to wait for hardware
buffers to drain.

Signed-off-by: Johan Hovold &lt;jhovold@gmail.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 0693196fe7bbb5e6cafd255dfce91ff6d10bc18f upstream.

Add wait_until_sent operation which can be used to wait for hardware
buffers to drain.

Signed-off-by: Johan Hovold &lt;jhovold@gmail.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>xen-netfront: reduce gso_max_size to account for max TCP header</title>
<updated>2013-06-07T19:53:36+00:00</updated>
<author>
<name>Wei Liu</name>
<email>wei.liu2@citrix.com</email>
</author>
<published>2013-04-22T02:20:41+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=539f197a06fd6eb2d1211bac9133e8c903fcc70c'/>
<id>539f197a06fd6eb2d1211bac9133e8c903fcc70c</id>
<content type='text'>
commit 9ecd1a75d977e2e8c48139c7d3efed183f898d94 upstream.

The maximum packet including header that can be handled by netfront / netback
wire format is 65535. Reduce gso_max_size accordingly.

Drop skb and print warning when skb-&gt;len &gt; 65535. This can 1) save the effort
to send malformed packet to netback, 2) help spotting misconfiguration of
netfront in the future.

Signed-off-by: Wei Liu &lt;wei.liu2@citrix.com&gt;
Acked-by: Ian Campbell &lt;ian.campbell@citrix.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 9ecd1a75d977e2e8c48139c7d3efed183f898d94 upstream.

The maximum packet including header that can be handled by netfront / netback
wire format is 65535. Reduce gso_max_size accordingly.

Drop skb and print warning when skb-&gt;len &gt; 65535. This can 1) save the effort
to send malformed packet to netback, 2) help spotting misconfiguration of
netfront in the future.

Signed-off-by: Wei Liu &lt;wei.liu2@citrix.com&gt;
Acked-by: Ian Campbell &lt;ian.campbell@citrix.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>xen-netback: coalesce slots in TX path and fix regressions</title>
<updated>2013-06-07T19:53:36+00:00</updated>
<author>
<name>Wei Liu</name>
<email>wei.liu2@citrix.com</email>
</author>
<published>2013-04-22T02:20:42+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=c34e3784b94f9eef8860bb142ca56fddb3c5951f'/>
<id>c34e3784b94f9eef8860bb142ca56fddb3c5951f</id>
<content type='text'>
commit 2810e5b9a7731ca5fce22bfbe12c96e16ac44b6f upstream.

This patch tries to coalesce tx requests when constructing grant copy
structures. It enables netback to deal with situation when frontend's
MAX_SKB_FRAGS is larger than backend's MAX_SKB_FRAGS.

With the help of coalescing, this patch tries to address two regressions
avoid reopening the security hole in XSA-39.

Regression 1. The reduction of the number of supported ring entries (slots)
per packet (from 18 to 17). This regression has been around for some time but
remains unnoticed until XSA-39 security fix. This is fixed by coalescing
slots.

Regression 2. The XSA-39 security fix turning "too many frags" errors from
just dropping the packet to a fatal error and disabling the VIF. This is fixed
by coalescing slots (handling 18 slots when backend's MAX_SKB_FRAGS is 17)
which rules out false positive (using 18 slots is legit) and dropping packets
using 19 to `max_skb_slots` slots.

To avoid reopening security hole in XSA-39, frontend sending packet using more
than max_skb_slots is considered malicious.

The behavior of netback for packet is thus:

    1-18            slots: valid
   19-max_skb_slots slots: drop and respond with an error
   max_skb_slots+   slots: fatal error

max_skb_slots is configurable by admin, default value is 20.

Also change variable name from "frags" to "slots" in netbk_count_requests.

Please note that RX path still has dependency on MAX_SKB_FRAGS. This will be
fixed with separate patch.

Signed-off-by: Wei Liu &lt;wei.liu2@citrix.com&gt;
Acked-by: Ian Campbell &lt;ian.campbell@citrix.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;


</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 2810e5b9a7731ca5fce22bfbe12c96e16ac44b6f upstream.

This patch tries to coalesce tx requests when constructing grant copy
structures. It enables netback to deal with situation when frontend's
MAX_SKB_FRAGS is larger than backend's MAX_SKB_FRAGS.

With the help of coalescing, this patch tries to address two regressions
avoid reopening the security hole in XSA-39.

Regression 1. The reduction of the number of supported ring entries (slots)
per packet (from 18 to 17). This regression has been around for some time but
remains unnoticed until XSA-39 security fix. This is fixed by coalescing
slots.

Regression 2. The XSA-39 security fix turning "too many frags" errors from
just dropping the packet to a fatal error and disabling the VIF. This is fixed
by coalescing slots (handling 18 slots when backend's MAX_SKB_FRAGS is 17)
which rules out false positive (using 18 slots is legit) and dropping packets
using 19 to `max_skb_slots` slots.

To avoid reopening security hole in XSA-39, frontend sending packet using more
than max_skb_slots is considered malicious.

The behavior of netback for packet is thus:

    1-18            slots: valid
   19-max_skb_slots slots: drop and respond with an error
   max_skb_slots+   slots: fatal error

max_skb_slots is configurable by admin, default value is 20.

Also change variable name from "frags" to "slots" in netbk_count_requests.

Please note that RX path still has dependency on MAX_SKB_FRAGS. This will be
fixed with separate patch.

Signed-off-by: Wei Liu &lt;wei.liu2@citrix.com&gt;
Acked-by: Ian Campbell &lt;ian.campbell@citrix.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;


</pre>
</div>
</content>
</entry>
<entry>
<title>target: Re-instate sess_wait_list for target_wait_for_sess_cmds</title>
<updated>2013-06-07T19:53:35+00:00</updated>
<author>
<name>Nicholas Bellinger</name>
<email>nab@linux-iscsi.org</email>
</author>
<published>2013-05-15T07:52:44+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=befb0ab8d1a9f51fb1682aaec9f0ab0eb23228e8'/>
<id>befb0ab8d1a9f51fb1682aaec9f0ab0eb23228e8</id>
<content type='text'>
commit 9b31a328e344e62e7cc98ae574edcb7b674719bb upstream.

Switch back to pre commit 1c7b13fe652 list splicing logic for active I/O
shutdown with tcm_qla2xxx + ib_srpt fabrics.

The original commit was done under the incorrect assumption that it's safe to
walk se_sess-&gt;sess_cmd_list unprotected in target_wait_for_sess_cmds() after
sess-&gt;sess_tearing_down = 1 has been set by target_sess_cmd_list_set_waiting()
during session shutdown.

So instead of adding sess-&gt;sess_cmd_lock protection around sess-&gt;sess_cmd_list
during target_wait_for_sess_cmds(), switch back to sess-&gt;sess_wait_list to
allow wait_for_completion() + TFO-&gt;release_cmd() to occur without having to
walk -&gt;sess_cmd_list after the list_splice.

Also add a check to exit if target_sess_cmd_list_set_waiting() has already
been called, and add a WARN_ON to check for any fabric bug where new se_cmds
are added to sess-&gt;sess_cmd_list after sess-&gt;sess_tearing_down = 1 has already
been set.

Signed-off-by: Nicholas Bellinger &lt;nab@linux-iscsi.org&gt;
Cc: Joern Engel &lt;joern@logfs.org&gt;
Cc: Roland Dreier &lt;roland@kernel.org&gt;
Signed-off-by: Lingzhu Xiang &lt;lxiang@redhat.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 9b31a328e344e62e7cc98ae574edcb7b674719bb upstream.

Switch back to pre commit 1c7b13fe652 list splicing logic for active I/O
shutdown with tcm_qla2xxx + ib_srpt fabrics.

The original commit was done under the incorrect assumption that it's safe to
walk se_sess-&gt;sess_cmd_list unprotected in target_wait_for_sess_cmds() after
sess-&gt;sess_tearing_down = 1 has been set by target_sess_cmd_list_set_waiting()
during session shutdown.

So instead of adding sess-&gt;sess_cmd_lock protection around sess-&gt;sess_cmd_list
during target_wait_for_sess_cmds(), switch back to sess-&gt;sess_wait_list to
allow wait_for_completion() + TFO-&gt;release_cmd() to occur without having to
walk -&gt;sess_cmd_list after the list_splice.

Also add a check to exit if target_sess_cmd_list_set_waiting() has already
been called, and add a WARN_ON to check for any fabric bug where new se_cmds
are added to sess-&gt;sess_cmd_list after sess-&gt;sess_tearing_down = 1 has already
been set.

Signed-off-by: Nicholas Bellinger &lt;nab@linux-iscsi.org&gt;
Cc: Joern Engel &lt;joern@logfs.org&gt;
Cc: Roland Dreier &lt;roland@kernel.org&gt;
Signed-off-by: Lingzhu Xiang &lt;lxiang@redhat.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>ACPI / PM: Allow device power states to be used for CONFIG_PM unset</title>
<updated>2013-06-07T19:53:23+00:00</updated>
<author>
<name>Rafael J. Wysocki</name>
<email>rafael.j.wysocki@intel.com</email>
</author>
<published>2013-05-16T20:29:28+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=8a031713e071cd0576b77e4cc171fabc6a828a7b'/>
<id>8a031713e071cd0576b77e4cc171fabc6a828a7b</id>
<content type='text'>
commit ec4602a9588a196fa1a9af46bfdd37cbf5792db4 upstream.

Currently, drivers/acpi/device_pm.c depends on CONFIG_PM and all of
the functions defined in there are replaced with static inline stubs
if that option is unset.  However, CONFIG_PM means, roughly, "runtime
PM or suspend/hibernation support" and some of those functions are
useful regardless of that.  For example, they are used by the ACPI
fan driver for controlling fans and acpi_device_set_power() is called
during device removal.  Moreover, device initialization may depend on
setting device power states properly.

For these reasons, make the routines manipulating ACPI device power
states defined in drivers/acpi/device_pm.c available for CONFIG_PM
unset too.

Reported-by: Zhang Rui &lt;rui.zhang@intel.com&gt;
Reported-and-tested-by: Michel Lespinasse &lt;walken@google.com&gt;
Signed-off-by: Rafael J. Wysocki &lt;rafael.j.wysocki@intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit ec4602a9588a196fa1a9af46bfdd37cbf5792db4 upstream.

Currently, drivers/acpi/device_pm.c depends on CONFIG_PM and all of
the functions defined in there are replaced with static inline stubs
if that option is unset.  However, CONFIG_PM means, roughly, "runtime
PM or suspend/hibernation support" and some of those functions are
useful regardless of that.  For example, they are used by the ACPI
fan driver for controlling fans and acpi_device_set_power() is called
during device removal.  Moreover, device initialization may depend on
setting device power states properly.

For these reasons, make the routines manipulating ACPI device power
states defined in drivers/acpi/device_pm.c available for CONFIG_PM
unset too.

Reported-by: Zhang Rui &lt;rui.zhang@intel.com&gt;
Reported-and-tested-by: Michel Lespinasse &lt;walken@google.com&gt;
Signed-off-by: Rafael J. Wysocki &lt;rafael.j.wysocki@intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>cgroup: fix a subtle bug in descendant pre-order walk</title>
<updated>2013-06-07T19:53:07+00:00</updated>
<author>
<name>Tejun Heo</name>
<email>tj@kernel.org</email>
</author>
<published>2013-05-24T01:50:24+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=e92b3f9342bd09ba9707d0500b46c6500de1b1fc'/>
<id>e92b3f9342bd09ba9707d0500b46c6500de1b1fc</id>
<content type='text'>
commit 7805d000db30a3787a4c969bab6ae4d8a5fd8ce6 upstream.

When cgroup_next_descendant_pre() initiates a walk, it checks whether
the subtree root doesn't have any children and if not returns NULL.
Later code assumes that the subtree isn't empty.  This is broken
because the subtree may become empty inbetween, which can lead to the
traversal escaping the subtree by walking to the sibling of the
subtree root.

There's no reason to have the early exit path.  Remove it along with
the later assumption that the subtree isn't empty.  This simplifies
the code a bit and fixes the subtle bug.

While at it, fix the comment of cgroup_for_each_descendant_pre() which
was incorrectly referring to -&gt;css_offline() instead of
-&gt;css_online().

Signed-off-by: Tejun Heo &lt;tj@kernel.org&gt;
Reviewed-by: Michal Hocko &lt;mhocko@suse.cz&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 7805d000db30a3787a4c969bab6ae4d8a5fd8ce6 upstream.

When cgroup_next_descendant_pre() initiates a walk, it checks whether
the subtree root doesn't have any children and if not returns NULL.
Later code assumes that the subtree isn't empty.  This is broken
because the subtree may become empty inbetween, which can lead to the
traversal escaping the subtree by walking to the sibling of the
subtree root.

There's no reason to have the early exit path.  Remove it along with
the later assumption that the subtree isn't empty.  This simplifies
the code a bit and fixes the subtle bug.

While at it, fix the comment of cgroup_for_each_descendant_pre() which
was incorrectly referring to -&gt;css_offline() instead of
-&gt;css_online().

Signed-off-by: Tejun Heo &lt;tj@kernel.org&gt;
Reviewed-by: Michal Hocko &lt;mhocko@suse.cz&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>wait: fix false timeouts when using wait_event_timeout()</title>
<updated>2013-06-07T19:52:40+00:00</updated>
<author>
<name>Imre Deak</name>
<email>imre.deak@intel.com</email>
</author>
<published>2013-05-24T22:55:09+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=f68a533ce8484b368aa0c953871e979dbea374bc'/>
<id>f68a533ce8484b368aa0c953871e979dbea374bc</id>
<content type='text'>
commit 4c663cfc523a88d97a8309b04a089c27dc57fd7e upstream.

Many callers of the wait_event_timeout() and
wait_event_interruptible_timeout() expect that the return value will be
positive if the specified condition becomes true before the timeout
elapses.  However, at the moment this isn't guaranteed.  If the wake-up
handler is delayed enough, the time remaining until timeout will be
calculated as 0 - and passed back as a return value - even if the
condition became true before the timeout has passed.

Fix this by returning at least 1 if the condition becomes true.  This
semantic is in line with what wait_for_condition_timeout() does; see
commit bb10ed09 ("sched: fix wait_for_completion_timeout() spurious
failure under heavy load").

Daniel said "We have 3 instances of this bug in drm/i915.  One case even
where we switch between the interruptible and not interruptible
wait_event_timeout variants, foolishly presuming they have the same
semantics.  I very much like this."

One such bug is reported at
  https://bugs.freedesktop.org/show_bug.cgi?id=64133

Signed-off-by: Imre Deak &lt;imre.deak@intel.com&gt;
Acked-by: Daniel Vetter &lt;daniel.vetter@ffwll.ch&gt;
Acked-by: David Howells &lt;dhowells@redhat.com&gt;
Acked-by: Jens Axboe &lt;axboe@kernel.dk&gt;
Cc: "Paul E.  McKenney" &lt;paulmck@linux.vnet.ibm.com&gt;
Cc: Dave Jones &lt;davej@redhat.com&gt;
Cc: Lukas Czerner &lt;lczerner@redhat.com&gt;
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 4c663cfc523a88d97a8309b04a089c27dc57fd7e upstream.

Many callers of the wait_event_timeout() and
wait_event_interruptible_timeout() expect that the return value will be
positive if the specified condition becomes true before the timeout
elapses.  However, at the moment this isn't guaranteed.  If the wake-up
handler is delayed enough, the time remaining until timeout will be
calculated as 0 - and passed back as a return value - even if the
condition became true before the timeout has passed.

Fix this by returning at least 1 if the condition becomes true.  This
semantic is in line with what wait_for_condition_timeout() does; see
commit bb10ed09 ("sched: fix wait_for_completion_timeout() spurious
failure under heavy load").

Daniel said "We have 3 instances of this bug in drm/i915.  One case even
where we switch between the interruptible and not interruptible
wait_event_timeout variants, foolishly presuming they have the same
semantics.  I very much like this."

One such bug is reported at
  https://bugs.freedesktop.org/show_bug.cgi?id=64133

Signed-off-by: Imre Deak &lt;imre.deak@intel.com&gt;
Acked-by: Daniel Vetter &lt;daniel.vetter@ffwll.ch&gt;
Acked-by: David Howells &lt;dhowells@redhat.com&gt;
Acked-by: Jens Axboe &lt;axboe@kernel.dk&gt;
Cc: "Paul E.  McKenney" &lt;paulmck@linux.vnet.ibm.com&gt;
Cc: Dave Jones &lt;davej@redhat.com&gt;
Cc: Lukas Czerner &lt;lczerner@redhat.com&gt;
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>virtio_console: fix uapi header</title>
<updated>2013-05-24T18:36:03+00:00</updated>
<author>
<name>Michael S. Tsirkin</name>
<email>mst@redhat.com</email>
</author>
<published>2013-05-17T01:14:15+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=1435b05b0477773ec80059a6f83bc99862fb0036'/>
<id>1435b05b0477773ec80059a6f83bc99862fb0036</id>
<content type='text'>
commit 6407d75afd08545f2252bb39806ffd3f10c7faac upstream.

uapi should use __u32 not u32.
Fix a macro in virtio_console.h which uses u32.

Signed-off-by: Michael S. Tsirkin &lt;mst@redhat.com&gt;
Signed-off-by: Rusty Russell &lt;rusty@rustcorp.com.au&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 6407d75afd08545f2252bb39806ffd3f10c7faac upstream.

uapi should use __u32 not u32.
Fix a macro in virtio_console.h which uses u32.

Signed-off-by: Michael S. Tsirkin &lt;mst@redhat.com&gt;
Signed-off-by: Rusty Russell &lt;rusty@rustcorp.com.au&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>audit: Make testing for a valid loginuid explicit.</title>
<updated>2013-05-19T18:38:47+00:00</updated>
<author>
<name>Eric W. Biederman</name>
<email>ebiederm@xmission.com</email>
</author>
<published>2013-04-09T09:22:10+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=60106c06452e7db66d13ce8286d89b9cce13664d'/>
<id>60106c06452e7db66d13ce8286d89b9cce13664d</id>
<content type='text'>
commit 780a7654cee8d61819512385e778e4827db4bfbc upstream.

audit rule additions containing "-F auid!=4294967295" were failing
with EINVAL because of a regression caused by e1760bd.

Apparently some userland audit rule sets want to know if loginuid uid
has been set and are using a test for auid != 4294967295 to determine
that.

In practice that is a horrible way to ask if a value has been set,
because it relies on subtle implementation details and will break
every time the uid implementation in the kernel changes.

So add a clean way to test if the audit loginuid has been set, and
silently convert the old idiom to the cleaner and more comprehensible
new idiom.

RGB notes: In upstream, audit_rule_to_entry has been refactored out.
This is patch is already upstream in functionally the same form in
commit 780a7654cee8d61819512385e778e4827db4bfbc .  The decimal constant
was cast to unsigned to quiet GCC 4.6 32-bit architecture warnings.

Reported-By: Steve Grubb &lt;sgrubb@redhat.com&gt;
Signed-off-by: "Eric W. Biederman" &lt;ebiederm@xmission.com&gt;
Tested-by: Richard Guy Briggs &lt;rgb@redhat.com&gt;
Signed-off-by: Eric Paris &lt;eparis@redhat.com&gt;
Backported-by: Richard Guy Briggs &lt;rgb@redhat.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 780a7654cee8d61819512385e778e4827db4bfbc upstream.

audit rule additions containing "-F auid!=4294967295" were failing
with EINVAL because of a regression caused by e1760bd.

Apparently some userland audit rule sets want to know if loginuid uid
has been set and are using a test for auid != 4294967295 to determine
that.

In practice that is a horrible way to ask if a value has been set,
because it relies on subtle implementation details and will break
every time the uid implementation in the kernel changes.

So add a clean way to test if the audit loginuid has been set, and
silently convert the old idiom to the cleaner and more comprehensible
new idiom.

RGB notes: In upstream, audit_rule_to_entry has been refactored out.
This is patch is already upstream in functionally the same form in
commit 780a7654cee8d61819512385e778e4827db4bfbc .  The decimal constant
was cast to unsigned to quiet GCC 4.6 32-bit architecture warnings.

Reported-By: Steve Grubb &lt;sgrubb@redhat.com&gt;
Signed-off-by: "Eric W. Biederman" &lt;ebiederm@xmission.com&gt;
Tested-by: Richard Guy Briggs &lt;rgb@redhat.com&gt;
Signed-off-by: Eric Paris &lt;eparis@redhat.com&gt;
Backported-by: Richard Guy Briggs &lt;rgb@redhat.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

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