user/sven/linux.git/include, branch v3.4.92

xen-netfront: reduce gso_max_size to account for max TCP header

2014-06-07T23:02:15Z

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->len > 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 Acked-by: Ian Campbell Signed-off-by: David S. Miller [bwh: Backported to 3.2: adjust context] Signed-off-by: Ben Hutchings [hq: Backported to 3.4: adjust context] Signed-off-by: Qiang Huang Signed-off-by: Greg Kroah-Hartman

net: Add net_ratelimited_function and net__ratelimited macros

2014-06-07T23:02:15Z

commit 3a3bfb61e64476ff1e4ac3122cb6dec9c79b795c upstream. __ratelimit() can be considered an inverted bool test because it returns true when not ratelimited. Several tests in the kernel tree use this __ratelimit() function incorrectly. No net_ratelimit uses are incorrect currently though. Most uses of net_ratelimit are to log something via printk or pr_. In order to minimize the uses of net_ratelimit, and to start standardizing the code style used for __ratelimit() and net_ratelimit(), add a net_ratelimited_function() macro and net__ratelimited() logging macros similar to pr__ratelimited that use the global net_ratelimit instead of a static per call site "struct ratelimit_state". Signed-off-by: Joe Perches Signed-off-by: David S. Miller Signed-off-by: Ben Hutchings Cc: Qiang Huang Signed-off-by: Greg Kroah-Hartman

drm: Pad drm_mode_get_connector to 64-bit boundary

2014-06-07T23:02:13Z

commit bc5bd37ce48c66e9192ad2e7231e9678880f6f8e upstream. Pavel Roskin reported that DRM_IOCTL_MODE_GETCONNECTOR was overwritting the 4 bytes beyond the end of its structure with a 32-bit userspace running on a 64-bit kernel. This is due to the padding gcc inserts as the drm_mode_get_connector struct includes a u64 and its size is not a natural multiple of u64s. 64-bit kernel: sizeof(drm_mode_get_connector)=80, alignof=8 sizeof(drm_mode_get_encoder)=20, alignof=4 sizeof(drm_mode_modeinfo)=68, alignof=4 32-bit userspace: sizeof(drm_mode_get_connector)=76, alignof=4 sizeof(drm_mode_get_encoder)=20, alignof=4 sizeof(drm_mode_modeinfo)=68, alignof=4 Fortuituously we can insert explicit padding to the tail of our structures without breaking ABI. Reported-by: Pavel Roskin Signed-off-by: Chris Wilson Cc: Dave Airlie Cc: dri-devel@lists.freedesktop.org Signed-off-by: Dave Airlie [bwh: Backported to 3.2: adjust filename] Signed-off-by: Ben Hutchings Cc: Weng Meiling Signed-off-by: Greg Kroah-Hartman

x86, efivars: firmware bug workarounds should be in platform code

2014-06-07T23:02:10Z

commit a6e4d5a03e9e3587e88aba687d8f225f4f04c792 upstream. Let's not burden ia64 with checks in the common efivars code that we're not writing too much data to the variable store. That kind of thing is an x86 firmware bug, plain and simple. efi_query_variable_store() provides platforms with a wrapper in which they can perform checks and workarounds for EFI variable storage bugs. Cc: H. Peter Anvin Cc: Matthew Garrett Signed-off-by: Matt Fleming [xr: Backported to 3.4: adjust context] Signed-off-by: Rui Xiang Signed-off-by: Greg Kroah-Hartman

efi_pstore: Introducing workqueue updating sysfs

2014-06-07T23:02:10Z

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 [xr: Backported to 3.4: - Adjust contest - Remove repeated definition of helper function variable_is_present] Signed-off-by: Rui Xiang Signed-off-by: Greg Kroah-Hartman

efi: be more paranoid about available space when creating variables

2014-06-07T23:02:09Z

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 Cc: Rui Xiang Signed-off-by: Greg Kroah-Hartman

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

2014-06-07T23:02:09Z

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 Cc: Rui Xiang Signed-off-by: Greg Kroah-Hartman

x86 get_unmapped_area: Access mmap_legacy_base through mm_struct member

2014-06-07T23:02:09Z

commit 41aacc1eea645c99edbe8fbcf78a97dc9b862adc upstream. This is the updated version of df54d6fa5427 ("x86 get_unmapped_area(): use proper mmap base for bottom-up direction") that only randomizes the mmap base address once. Signed-off-by: Radu Caragea Reported-and-tested-by: Jeff Shorey Cc: Andrew Morton Cc: Michel Lespinasse Cc: Oleg Nesterov Cc: Rik van Riel Cc: Ingo Molnar Cc: Adrian Sendroiu Cc: Greg KH Cc: Kamal Mostafa Signed-off-by: Linus Torvalds [bwh: Backported to 3.2: adjust context] Signed-off-by: Ben Hutchings Cc: Rui Xiang Signed-off-by: Greg Kroah-Hartman

x86, build, icc: Remove uninitialized_var() from compiler-intel.h

2014-06-07T23:02:08Z

commit 503cf95c061a0551eb684da364509297efbe55d9 upstream. When compiling with icc, ends up included because the icc environment defines __GNUC__. Thus, we neither need nor want to have this macro defined in both compiler-gcc.h and compiler-intel.h, and the fact that they are inconsistent just makes the compiler spew warnings. Reported-by: Sunil K. Pandey Cc: Kevin B. Smith Signed-off-by: H. Peter Anvin Link: http://lkml.kernel.org/n/tip-0mbwou1zt7pafij09b897lg3@git.kernel.org [bwh: Backported to 3.2: adjust context] Signed-off-by: Ben Hutchings Cc: Rui Xiang Signed-off-by: Greg Kroah-Hartman

mac80211: introduce IEEE80211_HW_TEARDOWN_AGGR_ON_BAR_FAIL

2014-06-07T23:02:07Z

commit 5b632fe85ec82e5c43740b52e74c66df50a37db3 upstream. Commit f0425beda4d404a6e751439b562100b902ba9c98 "mac80211: retry sending failed BAR frames later instead of tearing down aggr" caused regression on rt2x00 hardware (connection hangs). This regression was fixed by commit be03d4a45c09ee5100d3aaaedd087f19bc20d01 "rt2x00: Don't let mac80211 send a BAR when an AMPDU subframe fails". But the latter commit caused yet another problem reported in https://bugzilla.kernel.org/show_bug.cgi?id=42828#c22 After long discussion in this thread: http://mid.gmane.org/20121018075615.GA18212@redhat.com and testing various alternative solutions, which failed on one or other setup, we have no other good fix for the issues like just revert both mentioned earlier commits. To do not affect other hardware which benefit from commit f0425beda4d404a6e751439b562100b902ba9c98, instead of reverting it, introduce flag that when used will restore mac80211 behaviour before the commit. Signed-off-by: Stanislaw Gruszka [replaced link with mid.gmane.org that has message-id] Signed-off-by: Johannes Berg [bwh: Backported to 3.2: adjust context] Signed-off-by: Ben Hutchings [hq: Backported to 3.4: adjust context] Signed-off-by: Qiang Huang Signed-off-by: Greg Kroah-Hartman