linux-toradex.git/include, branch v3.2.30

SUNRPC: Fix a UDP transport regression

2012-09-19T14:05:17+00:00

commit f39c1bfb5a03e2d255451bff05be0d7255298fa4 upstream.

Commit 43cedbf0e8dfb9c5610eb7985d5f21263e313802 (SUNRPC: Ensure that
we grab the XPRT_LOCK before calling xprt_alloc_slot) is causing
hangs in the case of NFS over UDP mounts.

Since neither the UDP or the RDMA transport mechanism use dynamic slot
allocation, we can skip grabbing the socket lock for those transports.
Add a new rpc_xprt_op to allow switching between the TCP and UDP/RDMA
case.

Note that the NFSv4.1 back channel assigns the slot directly
through rpc_run_bc_task, so we can ignore that case.

Reported-by: Dick Streefland 
Signed-off-by: Trond Myklebust 
Signed-off-by: Ben Hutchings

kobject: fix oops with "input0: bad kobj_uevent_env content in show_uevent()"

2012-09-19T14:05:16+00:00

commit 60e233a56609fd963c59e99bd75c663d63fa91b6 upstream.

Fengguang Wu  writes:

> After the __devinit* removal series, I can still get kernel panic in
> show_uevent(). So there are more sources of bug..
>
> Debug patch:
>
> @@ -343,8 +343,11 @@ static ssize_t show_uevent(struct device
>                 goto out;
>
>         /* copy keys to file */
> -       for (i = 0; i < env->envp_idx; i++)
> +       dev_err(dev, "uevent %d env[%d]: %s/.../%s\n", env->buflen, env->envp_idx, top_kobj->name, dev->kobj.name);
> +       for (i = 0; i < env->envp_idx; i++) {
> +               printk(KERN_ERR "uevent %d env[%d]: %s\n", (int)count, i, env->envp[i]);
>                 count += sprintf(&buf[count], "%s\n", env->envp[i]);
> +       }
>
> Oops message, the env[] is again not properly initilized:
>
> [   44.068623] input input0: uevent 61 env[805306368]: input0/.../input0
> [   44.069552] uevent 0 env[0]: (null)

This is a completely different CONFIG_HOTPLUG problem, only
demonstrating another reason why CONFIG_HOTPLUG should go away.  I had a
hard time trying to disable it anyway ;-)

The problem this time is lots of code assuming that a call to
add_uevent_var() will guarantee that env->buflen > 0.  This is not true
if CONFIG_HOTPLUG is unset.  So things like this end up overwriting
env->envp_idx because the array index is -1:

	if (add_uevent_var(env, "MODALIAS="))
		return -ENOMEM;
        len = input_print_modalias(&env->buf[env->buflen - 1],
				   sizeof(env->buf) - env->buflen,
				   dev, 0);

Don't know what the best action is, given that there seem to be a *lot*
of this around the kernel.  This patch "fixes" the problem for me, but I
don't know if it can be considered an appropriate fix.

[ It is the correct fix for now, for 3.7 forcing CONFIG_HOTPLUG to
always be on is the longterm fix, but it's too late for 3.6 and older
kernels to resolve this that way - gregkh ]

Reported-by: Fengguang Wu 
Signed-off-by: Bjørn Mork 
Tested-by: Fengguang Wu 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Ben Hutchings

NFS: Fix the initialisation of the readdir 'cookieverf' array

2012-09-19T14:05:06+00:00

commit c3f52af3e03013db5237e339c817beaae5ec9e3a upstream.

When the NFS_COOKIEVERF helper macro was converted into a static
inline function in commit 99fadcd764 (nfs: convert NFS_*(inode)
helpers to static inline), we broke the initialisation of the
readdir cookies, since that depended on doing a memset with an
argument of 'sizeof(NFS_COOKIEVERF(inode))' which therefore
changed from sizeof(be32 cookieverf[2]) to sizeof(be32 *).

At this point, NFS_COOKIEVERF seems to be more of an obfuscation
than a helper, so the best thing would be to just get rid of it.

Also see: https://bugzilla.kernel.org/show_bug.cgi?id=46881

Reported-by: Andi Kleen 
Reported-by: David Binderman 
Signed-off-by: Trond Myklebust 
Signed-off-by: Ben Hutchings

perf_event: Switch to internal refcount, fix race with close()

2012-09-19T14:05:06+00:00

commit a6fa941d94b411bbd2b6421ffbde6db3c93e65ab upstream.

Don't mess with file refcounts (or keep a reference to file, for
that matter) in perf_event.  Use explicit refcount of its own
instead.  Deal with the race between the final reference to event
going away and new children getting created for it by use of
atomic_long_inc_not_zero() in inherit_event(); just have the
latter free what it had allocated and return NULL, that works
out just fine (children of siblings of something doomed are
created as singletons, same as if the child of leader had been
created and immediately killed).

Signed-off-by: Al Viro 
Signed-off-by: Peter Zijlstra 
Link: http://lkml.kernel.org/r/20120820135925.GG23464@ZenIV.linux.org.uk
Signed-off-by: Ingo Molnar 
Signed-off-by: Ben Hutchings

time: Move ktime_t overflow checking into timespec_valid_strict

2012-09-19T14:05:00+00:00

This is a -stable backport of cee58483cf56e0ba355fdd97ff5e8925329aa936

Andreas Bombe reported that the added ktime_t overflow checking added to
timespec_valid in commit 4e8b14526ca7 ("time: Improve sanity checking of
timekeeping inputs") was causing problems with X.org because it caused
timeouts larger then KTIME_T to be invalid.

Previously, these large timeouts would be clamped to KTIME_MAX and would
never expire, which is valid.

This patch splits the ktime_t overflow checking into a new
timespec_valid_strict function, and converts the timekeeping codes
internal checking to use this more strict function.

Reported-and-tested-by: Andreas Bombe 
Cc: Zhouping Liu 
Cc: Ingo Molnar 
Cc: Prarit Bhargava 
Cc: Thomas Gleixner 
Signed-off-by: John Stultz 
Signed-off-by: Linus Torvalds 
Cc: Linux Kernel 
Signed-off-by: John Stultz

time: Improve sanity checking of timekeeping inputs

2012-09-19T14:04:59+00:00

This is a -stable backport of 4e8b14526ca7fb046a81c94002c1c43b6fdf0e9b

Unexpected behavior could occur if the time is set to a value large
enough to overflow a 64bit ktime_t (which is something larger then the
year 2262).

Also unexpected behavior could occur if large negative offsets are
injected via adjtimex.

So this patch improves the sanity check timekeeping inputs by
improving the timespec_valid() check, and then makes better use of
timespec_valid() to make sure we don't set the time to an invalid
negative value or one that overflows ktime_t.

Note: This does not protect from setting the time close to overflowing
ktime_t and then letting natural accumulation cause the overflow.

Reported-by: CAI Qian 
Reported-by: Sasha Levin 
Signed-off-by: John Stultz 
Cc: Peter Zijlstra 
Cc: Prarit Bhargava 
Cc: Zhouping Liu 
Cc: Ingo Molnar 
Link: http://lkml.kernel.org/r/1344454580-17031-1-git-send-email-john.stultz@linaro.org
Signed-off-by: Thomas Gleixner 
Cc: Linux Kernel 
Signed-off-by: John Stultz

bnx2x: fix 57840_MF pci id

2012-09-19T14:04:58+00:00

[ Upstream commit 5c879d2094946081af934739850c7260e8b25d3c ]

Commit c3def943c7117d42caaed3478731ea7c3c87190e have added support for
new pci ids of the 57840 board, while failing to change the obsolete value
in 'pci_ids.h'.
This patch does so, allowing the probe of such devices.

Signed-off-by: Yuval Mintz 
Signed-off-by: Eilon Greenstein 
Signed-off-by: David S. Miller 
Signed-off-by: Ben Hutchings

af_netlink: force credentials passing [CVE-2012-3520]

2012-09-19T14:04:55+00:00

[ Upstream commit e0e3cea46d31d23dc40df0a49a7a2c04fe8edfea ]

Pablo Neira Ayuso discovered that avahi and
potentially NetworkManager accept spoofed Netlink messages because of a
kernel bug.  The kernel passes all-zero SCM_CREDENTIALS ancillary data
to the receiver if the sender did not provide such data, instead of not
including any such data at all or including the correct data from the
peer (as it is the case with AF_UNIX).

This bug was introduced in commit 16e572626961
(af_unix: dont send SCM_CREDENTIALS by default)

This patch forces passing credentials for netlink, as
before the regression.

Another fix would be to not add SCM_CREDENTIALS in
netlink messages if not provided by the sender, but it
might break some programs.

With help from Florian Weimer & Petr Matousek

This issue is designated as CVE-2012-3520

Signed-off-by: Eric Dumazet 
Cc: Petr Matousek 
Cc: Florian Weimer 
Cc: Pablo Neira Ayuso 
Signed-off-by: David S. Miller 
Signed-off-by: Ben Hutchings

af_packet: don't emit packet on orig fanout group

2012-09-19T14:04:55+00:00

[ Upstream commit c0de08d04215031d68fa13af36f347a6cfa252ca ]

If a packet is emitted on one socket in one group of fanout sockets,
it is transmitted again. It is thus read again on one of the sockets
of the fanout group. This result in a loop for software which
generate packets when receiving one.
This retransmission is not the intended behavior: a fanout group
must behave like a single socket. The packet should not be
transmitted on a socket if it originates from a socket belonging
to the same fanout group.

This patch fixes the issue by changing the transmission check to
take fanout group info account.

Reported-by: Aleksandr Kotov 
Signed-off-by: Eric Leblond 
Signed-off-by: David S. Miller 
Signed-off-by: Ben Hutchings

tcp: Apply device TSO segment limit earlier

2012-09-19T14:04:46+00:00

[ Upstream commit 1485348d2424e1131ea42efc033cbd9366462b01 ]

Cache the device gso_max_segs in sock::sk_gso_max_segs and use it to
limit the size of TSO skbs.  This avoids the need to fall back to
software GSO for local TCP senders.

Signed-off-by: Ben Hutchings 
Signed-off-by: David S. Miller 
Signed-off-by: Ben Hutchings