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

efi_pstore: Introducing workqueue updating sysfs

2013-03-27T02:41:20+00:00

commit a93bc0c6e07ed9bac44700280e65e2945d864fd4 upstream.

[Problem]
efi_pstore creates sysfs entries, which enable users to access to NVRAM,
in a write callback. If a kernel panic happens in an interrupt context,
it may fail because it could sleep due to dynamic memory allocations during
creating sysfs entries.

[Patch Description]
This patch removes sysfs operations from a write callback by introducing
a workqueue updating sysfs entries which is scheduled after the write
callback is called.

Also, the workqueue is kicked in a just oops case.
A system will go down in other cases such as panic, clean shutdown and emergency
restart. And we don't need to create sysfs entries because there is no chance for
users to access to them.

efi_pstore will be robust against a kernel panic in an interrupt context with this patch.

Signed-off-by: Seiji Aguchi 
Acked-by: Matt Fleming 
Signed-off-by: Tony Luck 
[bwh: Backported to 3.2:
 - Adjust contest
 - Don't check reason in efi_pstore_write(), as it is not given as a
   parameter
 - Move up declaration of __efivars]
Signed-off-by: Ben Hutchings

tcp: fix skb_availroom()

2013-03-27T02:41:06+00:00

[ Upstream commit 16fad69cfe4adbbfa813de516757b87bcae36d93 ]

Chrome OS team reported a crash on a Pixel ChromeBook in TCP stack :

https://code.google.com/p/chromium/issues/detail?id=182056

commit a21d45726acac (tcp: avoid order-1 allocations on wifi and tx
path) did a poor choice adding an 'avail_size' field to skb, while
what we really needed was a 'reserved_tailroom' one.

It would have avoided commit 22b4a4f22da (tcp: fix retransmit of
partially acked frames) and this commit.

Crash occurs because skb_split() is not aware of the 'avail_size'
management (and should not be aware)

Signed-off-by: Eric Dumazet 
Reported-by: Mukesh Agrawal 
Signed-off-by: David S. Miller 
Signed-off-by: Ben Hutchings

perf,x86: fix link failure for non-Intel configs

2013-03-27T02:40:55+00:00

commit 6c4d3bc99b3341067775efd4d9d13cc8e655fd7c upstream.

Commit 1d9d8639c063 ("perf,x86: fix kernel crash with PEBS/BTS after
suspend/resume") introduces a link failure since
perf_restore_debug_store() is only defined for CONFIG_CPU_SUP_INTEL:

	arch/x86/power/built-in.o: In function `restore_processor_state':
	(.text+0x45c): undefined reference to `perf_restore_debug_store'

Fix it by defining the dummy function appropriately.

Signed-off-by: David Rientjes 
Signed-off-by: Linus Torvalds 
Signed-off-by: Ben Hutchings

perf,x86: fix kernel crash with PEBS/BTS after suspend/resume

2013-03-27T02:40:54+00:00

commit 1d9d8639c063caf6efc2447f5f26aa637f844ff6 upstream.

This patch fixes a kernel crash when using precise sampling (PEBS)
after a suspend/resume. Turns out the CPU notifier code is not invoked
on CPU0 (BP). Therefore, the DS_AREA (used by PEBS) is not restored properly
by the kernel and keeps it power-on/resume value of 0 causing any PEBS
measurement to crash when running on CPU0.

The workaround is to add a hook in the actual resume code to restore
the DS Area MSR value. It is invoked for all CPUS. So for all but CPU0,
the DS_AREA will be restored twice but this is harmless.

Reported-by: Linus Torvalds 
Signed-off-by: Stephane Eranian 
Signed-off-by: Linus Torvalds 
Signed-off-by: Ben Hutchings

NLS: improve UTF8 -> UTF16 string conversion routine

2013-03-20T15:03:41+00:00

commit 0720a06a7518c9d0c0125bd5d1f3b6264c55c3dd upstream.

The utf8s_to_utf16s conversion routine needs to be improved.  Unlike
its utf16s_to_utf8s sibling, it doesn't accept arguments specifying
the maximum length of the output buffer or the endianness of its
16-bit output.

This patch (as1501) adds the two missing arguments, and adjusts the
only two places in the kernel where the function is called.  A
follow-on patch will add a third caller that does utilize the new
capabilities.

The two conversion routines are still annoyingly inconsistent in the
way they handle invalid byte combinations.  But that's a subject for a
different patch.

Signed-off-by: Alan Stern 
CC: Clemens Ladisch 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Ben Hutchings

tty/serial: Add support for Altera serial port

2013-03-20T15:03:33+00:00

commit e06c93cacb82dd147266fd1bdb2d0a0bd45ff2c1 upstream.

Add support for Altera 8250/16550 compatible serial port.

Signed-off-by: Ley Foon Tan 
Signed-off-by: Greg Kroah-Hartman 
[bwh: Backported to 3.2: adjust filenames, context]
Signed-off-by: Ben Hutchings

efi: be more paranoid about available space when creating variables

2013-03-20T15:03:28+00:00

commit 68d929862e29a8b52a7f2f2f86a0600423b093cd upstream.

UEFI variables are typically stored in flash. For various reasons, avaiable
space is typically not reclaimed immediately upon the deletion of a
variable - instead, the system will garbage collect during initialisation
after a reboot.

Some systems appear to handle this garbage collection extremely poorly,
failing if more than 50% of the system flash is in use. This can result in
the machine refusing to boot. The safest thing to do for the moment is to
forbid writes if they'd end up using more than half of the storage space.
We can make this more finegrained later if we come up with a method for
identifying the broken machines.

Signed-off-by: Matthew Garrett 
Signed-off-by: Matt Fleming 
[bwh: Backported to 3.2:
 - Drop efivarfs changes and unused check_var_size()
 - Add error codes to include/linux/efi.h, added upstream by
   commit 5d9db883761a ('efi: Add support for a UEFI variable filesystem')
 - Add efi_status_to_err(), added upstream by commit 7253eaba7b17
   ('efivarfs: Return an error if we fail to read a variable')]
Signed-off-by: Ben Hutchings

efi_pstore: Check remaining space with QueryVariableInfo() before writing data

2013-03-20T15:03:27+00:00

commit d80a361d779a9f19498943d1ca84243209cd5647 upstream.

[Issue]

As discussed in a thread below, Running out of space in EFI isn't a well-tested scenario.
And we wouldn't expect all firmware to handle it gracefully.
http://marc.info/?l=linux-kernel&m=134305325801789&w=2

On the other hand, current efi_pstore doesn't check a remaining space of storage at writing time.
Therefore, efi_pstore may not work if it tries to write a large amount of data.

[Patch Description]

To avoid handling the situation above, this patch checks if there is a space enough to log with
QueryVariableInfo() before writing data.

Signed-off-by: Seiji Aguchi 
Acked-by: Mike Waychison 
Signed-off-by: Tony Luck 
Signed-off-by: Ben Hutchings

dm: fix truncated status strings

2013-03-20T15:03:20+00:00

commit fd7c092e711ebab55b2688d3859d95dfd0301f73 upstream.

Avoid returning a truncated table or status string instead of setting
the DM_BUFFER_FULL_FLAG when the last target of a table fills the
buffer.

When processing a table or status request, the function retrieve_status
calls ti->type->status. If ti->type->status returns non-zero,
retrieve_status assumes that the buffer overflowed and sets
DM_BUFFER_FULL_FLAG.

However, targets don't return non-zero values from their status method
on overflow. Most targets returns always zero.

If a buffer overflow happens in a target that is not the last in the
table, it gets noticed during the next iteration of the loop in
retrieve_status; but if a buffer overflow happens in the last target, it
goes unnoticed and erroneously truncated data is returned.

In the current code, the targets behave in the following way:
* dm-crypt returns -ENOMEM if there is not enough space to store the
  key, but it returns 0 on all other overflows.
* dm-thin returns errors from the status method if a disk error happened.
  This is incorrect because retrieve_status doesn't check the error
  code, it assumes that all non-zero values mean buffer overflow.
* all the other targets always return 0.

This patch changes the ti->type->status function to return void (because
most targets don't use the return code). Overflow is detected in
retrieve_status: if the status method fills up the remaining space
completely, it is assumed that buffer overflow happened.

Signed-off-by: Mikulas Patocka 
Signed-off-by: Alasdair G Kergon 
[bwh: Backported to 3.2:
 - Adjust context
 - dm_status_fn doesn't take a status_flags parameter
 - Bump the last component of each current version (verified not to
   match any version used in mainline)
 - Drop changes to dm-verity]
Signed-off-by: Ben Hutchings

exec: use -ELOOP for max recursion depth

2013-03-06T03:24:28+00:00

commit d740269867021faf4ce38a449353d2b986c34a67 upstream.

To avoid an explosion of request_module calls on a chain of abusive
scripts, fail maximum recursion with -ELOOP instead of -ENOEXEC. As soon
as maximum recursion depth is hit, the error will fail all the way back
up the chain, aborting immediately.

This also has the side-effect of stopping the user's shell from attempting
to reexecute the top-level file as a shell script. As seen in the
dash source:

        if (cmd != path_bshell && errno == ENOEXEC) {
                *argv-- = cmd;
                *argv = cmd = path_bshell;
                goto repeat;
        }

The above logic was designed for running scripts automatically that lacked
the "#!" header, not to re-try failed recursion. On a legitimate -ENOEXEC,
things continue to behave as the shell expects.

Additionally, when tracking recursion, the binfmt handlers should not be
involved. The recursion being tracked is the depth of calls through
search_binary_handler(), so that function should be exclusively responsible
for tracking the depth.

Signed-off-by: Kees Cook 
Cc: halfdog 
Cc: P J P 
Cc: Alexander Viro 
Signed-off-by: Andrew Morton 
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings