04 Aug, 2011
40 commits
-
commit 21c5977a836e399fc710ff2c5367845ed5c2527f upstream.
Fix several security issues in Alpha-specific syscalls. Untested, but
mostly trivial.1. Signedness issue in osf_getdomainname allows copying out-of-bounds
kernel memory to userland.2. Signedness issue in osf_sysinfo allows copying large amounts of
kernel memory to userland.3. Typo (?) in osf_getsysinfo bounds minimum instead of maximum copy
size, allowing copying large amounts of kernel memory to userland.4. Usage of user pointer in osf_wait4 while under KERNEL_DS allows
privilege escalation via writing return value of sys_wait4 to kernel
memory.Signed-off-by: Dan Rosenberg
Cc: Richard Henderson
Cc: Ivan Kokshaysky
Cc: Matt Turner
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
Signed-off-by: Greg Kroah-Hartman -
commit 1d1221f375c94ef961ba8574ac4f85c8870ddd51 upstream.
/proc/PID/io may be used for gathering private information. E.g. for
openssh and vsftpd daemons wchars/rchars may be used to learn the
precise password length. Restrict it to processes being able to ptrace
the target process.ptrace_may_access() is needed to prevent keeping open file descriptor of
"io" file, executing setuid binary and gathering io information of the
setuid'ed process.Signed-off-by: Vasiliy Kulikov
Signed-off-by: Linus Torvalds
Signed-off-by: Greg Kroah-Hartman -
commit c027a474a68065391c8773f6e83ed5412657e369 upstream.
exit_mm() sets ->mm == NULL then it does mmput()->exit_mmap() which
frees the memory.However select_bad_process() checks ->mm != NULL before TIF_MEMDIE,
so it continues to kill other tasks even if we have the oom-killed
task freeing its memory.Change select_bad_process() to check ->mm after TIF_MEMDIE, but skip
the tasks which have already passed exit_notify() to ensure a zombie
with TIF_MEMDIE set can't block oom-killer. Alternatively we could
probably clear TIF_MEMDIE after exit_mmap().Signed-off-by: Oleg Nesterov
Reviewed-by: KOSAKI Motohiro
Signed-off-by: Linus Torvalds
Signed-off-by: Greg Kroah-Hartman -
commit b307d4655a71749ac3f91c6dbe33d28cc026ceeb upstream.
The compiler, at least for ix86 and m68k, validly warns that the
comparison:next
Reported-by: Jan Beulich
Signed-off-by: Jan Beulich
Signed-off-by: David Howells
Cc: Suresh Jayaraman
Cc: Geert Uytterhoeven
Signed-off-by: Linus Torvalds
Signed-off-by: Greg Kroah-Hartman -
commit 17dd759c67f21e34f2156abcf415e1f60605a188 upstream.
Currently skb_gro_header_slow unconditionally resets frag0 and
frag0_len. However, when we can't pull on the skb this leaves
the GRO fields in an inconsistent state.This patch fixes this by only resetting those fields after the
pskb_may_pull test.Signed-off-by: Herbert Xu
Signed-off-by: David S. Miller
Signed-off-by: Greg Kroah-Hartman -
commit 0c03150e7ea8f7fcd03cfef29385e0010b22ee92 upstream.
A bridge topology with three systems:
+------+ +------+
| A(2) |--| B(1) |
+------+ +------+
\ /
+------+
| C(3) |
+------+What is supposed to happen:
* bridge with the lowest ID is elected root (for example: B)
* C detects that A->C is higher cost path and puts in blocking stateWhat happens. Bridge with lowest id (B) is elected correctly as
root and things start out fine initially. But then config BPDU
doesn't get transmitted from A -> C. Because of that
the link from A-C is transistioned to the forwarding state.The root cause of this is that the configuration messages
is generated with bogus message age, and dropped before
sending.In the standardmessage_age is supposed to be:
the time since the generation of the Configuration BPDU by
the Root that instigated the generation of this Configuration BPDU.Reimplement this by recording the timestamp (age + jiffies) when
recording config information. The old code incorrectly used the time
elapsed on the ageing timer which was incorrect.See also:
https://bugzilla.vyatta.com/show_bug.cgi?id=7164Signed-off-by: Stephen Hemminger
Signed-off-by: David S. Miller
Signed-off-by: Greg Kroah-Hartman -
This patch is intended for 2.6.39-stable kernels only and is needed to
fix a regression introduced in 2.6.39. Prior to 2.6.39, when signing was
enabled on a socket the client only sent single-page writes. This
changed with commit ca83ce3, which made signed and unsigned connections
use the same codepaths for write calls.This caused a regression when working with windows servers. Windows
machines will reject writes larger than the MaxBufferSize when signing
is active, but do not clear the CAP_LARGE_WRITE_X flag in the protocol
negotiation. The upshot is that when signing is active, windows servers
often reject large writes from the client in 2.6.39.Because 3.0 adds support for larger wsize values, simply cherry picking
the upstream patches that fix the wsize negotiation isn't sufficient to
fix this issue. We also need to alter the maximum and default values to
something suitable for 2.6.39.This patch also accounts for the change in field name from sec_mode to
secMode that went into 3.0.Signed-off-by: Jeff Layton
Signed-off-by: Greg Kroah-Hartman -
commit 1190f6a067bf27b2ee7e06ec0776a17fe0f6c4d8 upstream.
Hopefully last version. Base signing check on CAP_UNIX instead of
tcon->unix_ext, also clean up the comments a bit more.According to Hongwei Sun's blog posting here:
http://blogs.msdn.com/b/openspecification/archive/2009/04/10/smb-maximum-transmit-buffer-size-and-performance-tuning.aspx
CAP_LARGE_WRITEX is ignored when signing is active. Also, the maximum
size for a write without CAP_LARGE_WRITEX should be the maxBuf that
the server sent in the NEGOTIATE request.Fix the wsize negotiation to take this into account. While we're at it,
alter the other wsize definitions to use sizeof(WRITE_REQ) to allow for
slightly larger amounts of data to potentially be written per request.Signed-off-by: Jeff Layton
Signed-off-by: Steve French
Signed-off-by: Greg Kroah-Hartman -
Backport of commit 59430262401bec02d415179c43dbe5b8819c09ce
done by Hugh DickinsDon't update *inode in __follow_mount_rcu() until we'd verified that
there is mountpoint there. Kudos to Hugh Dickins for catching that
one in the first place and eventually figuring out the solution (and
catching a braino in the earlier version of patch).Signed-off-by: Linus Torvalds
Cc: Hugh Dickins
Signed-off-by: Al Viro -
This reverts commit 673de951a6cbaa7a9c4518e03e78b88809828497 which was
commit 5a0deeed5741117ee8625d6305d0034e219f102c upstream.Based on comments from users, this broke things.
Acked-by: Olivier Grenie
Cc: Florian Mickler
Cc: Patrick Boettcher
Cc: Mauro Carvalho Chehab
Signed-off-by: Greg Kroah-Hartman -
commit 215ddd6664ced067afca7eebd2d1eb83f064ff5a upstream
During allocator-intensive workloads, kswapd will be woken frequently
causing free memory to oscillate between the high and min watermark. This
is expected behaviour. Unfortunately, if the highest zone is small, a
problem occurs.When balance_pgdat() returns, it may be at a lower classzone_idx than it
started because the highest zone was unreclaimable. Before checking if it
should go to sleep though, it checks pgdat->classzone_idx which when there
is no other activity will be MAX_NR_ZONES-1. It interprets this as it has
been woken up while reclaiming, skips scheduling and reclaims again. As
there is no useful reclaim work to do, it enters into a loop of shrinking
slab consuming loads of CPU until the highest zone becomes reclaimable for
a long period of time.There are two problems here. 1) If the returned classzone or order is
lower, it'll continue reclaiming without scheduling. 2) if the highest
zone was marked unreclaimable but balance_pgdat() returns immediately at
DEF_PRIORITY, the new lower classzone is not communicated back to kswapd()
for sleeping.This patch does two things that are related. If the end_zone is
unreclaimable, this information is communicated back. Second, if the
classzone or order was reduced due to failing to reclaim, new information
is not read from pgdat and instead an attempt is made to go to sleep. Due
to this, it is also necessary that pgdat->classzone_idx be initialised
each time to pgdat->nr_zones - 1 to avoid re-reads being interpreted as
wakeups.Signed-off-by: Mel Gorman
Reported-by: Pádraig Brady
Tested-by: Pádraig Brady
Tested-by: Andrew Lutomirski
Acked-by: Rik van Riel
Cc: Minchan Kim
Cc: KOSAKI Motohiro
Cc: Johannes Weiner
Signed-off-by: Andrew Morton
Signed-off-by: Greg Kroah-Hartman -
commit d7868dae893c83c50c7824bc2bc75f93d114669f upstream
During allocator-intensive workloads, kswapd will be woken frequently
causing free memory to oscillate between the high and min watermark. This
is expected behaviour.When kswapd applies pressure to zones during node balancing, it checks if
the zone is above a high+balance_gap threshold. If it is, it does not
apply pressure but it unconditionally shrinks slab on a global basis which
is excessive. In the event kswapd is being kept awake due to a high small
unreclaimable zone, it skips zone shrinking but still calls shrink_slab().Once pressure has been applied, the check for zone being unreclaimable is
being made before the check is made if all_unreclaimable should be set.
This miss of unreclaimable can cause has_under_min_watermark_zone to be
set due to an unreclaimable zone preventing kswapd backing off on
congestion_wait().Signed-off-by: Mel Gorman
Reported-by: Pádraig Brady
Tested-by: Pádraig Brady
Tested-by: Andrew Lutomirski
Acked-by: Rik van Riel
Reviewed-by: Minchan Kim
Reviewed-by: KOSAKI Motohiro
Cc: Johannes Weiner
Signed-off-by: Andrew Morton
Signed-off-by: Greg Kroah-Hartman -
commit f7910cbd9fa319ee4501074f1f3b5ce23c4b1518 upstream.
Now that we can handle larger wsizes in writepages, fix up the
negotiation of the wsize to allow for that. find_get_pages only seems to
give out a max of 256 pages at a time, so that gives us a reasonable
default of 1M for the wsize.If the server however does not support large writes via POSIX
extensions, then we cap the wsize to (128k - PAGE_CACHE_SIZE). That
gives us a size that goes up to the max frame size specified in RFC1001.Finally, if CAP_LARGE_WRITE_AND_X isn't set, then further cap it to the
largest size allowed by the protocol (USHRT_MAX).Signed-off-by: Jeff Layton
Reviewed-and-Tested-by: Pavel Shilovsky
Signed-off-by: Steve French
Signed-off-by: Greg Kroah-Hartman -
A user on #xfs reported that a log replay was oopsing in
__rb_rotate_left() with a null pointer deref, and provided
an xfs_metadump image for reproduction and testing.I traced this down to the fact that in xfs_alloc_busy_insert(),
we erased a node with rb_erase() when the new node overlapped,
but left the erased node specified as the parent node for the
new insertion.So when we try to insert a new node with an erased node as
its parent, obviously things go very wrong.Upstream,
97d3ac75e5e0ebf7ca38ae74cebd201c09b97ab2 xfs: exact busy extent tracking
actually fixed this, but as part of a much larger change. Here's
the relevant code from that commit:* We also need to restart the busy extent search from the
* tree root, because erasing the node can rearrange the
* tree topology.
*/
rb_erase(&busyp->rb_node, &pag->pagb_tree);
busyp->length = 0;
return false;We can do essentially the same thing to older codebases by restarting
the tree search after the erase.This should apply to .35.y through .39.y, and was tested on .39
with the oopsing replay reproducer.Signed-off-by: Eric Sandeen
Reviewed-by: Dave Chinner
Reviewed-by: Alex Elder
Signed-off-by: Greg Kroah-Hartman -
commit: f9e35b3b41f47c4e17d8132edbcab305a6aaa4b0 upstream
Asynchronous compaction is used when promoting to huge pages. This is all
very nice but if there are a number of processes in compacting memory, a
large number of pages can be isolated. An "asynchronous" process can
stall for long periods of time as a result with a user reporting that
firefox can stall for 10s of seconds. This patch aborts asynchronous
compaction if too many pages are isolated as it's better to fail a
hugepage promotion than stall a process.[minchan.kim@gmail.com: return COMPACT_PARTIAL for abort]
Reported-and-tested-by: Ury Stankevich
Signed-off-by: Mel Gorman
Reviewed-by: Minchan Kim
Reviewed-by: Michal Hocko
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
Signed-off-by: Greg Kroah-Hartman -
commit: d179e84ba5da1d0024087d1759a2938817a00f3f upstream
It is unsafe to run page_count during the physical pfn scan because
compound_head could trip on a dangling pointer when reading
page->first_page if the compound page is being freed by another CPU.[mgorman@suse.de: split out patch]
Signed-off-by: Andrea Arcangeli
Signed-off-by: Mel Gorman
Reviewed-by: Michal Hocko
Reviewed-by: Minchan Kim
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
Signed-off-by: Greg Kroah-Hartman -
commit: 7454f4ba40b419eb999a3c61a99da662bf1a2bb8 upstream
Compaction works with two scanners, a migration and a free scanner. When
the scanners crossover, migration within the zone is complete. The
location of the scanner is recorded on each cycle to avoid excesive
scanning.When a zone is small and mostly reserved, it's very easy for the migration
scanner to be close to the end of the zone. Then the following situation
can occurso migration scanner isolates some pages near the end of the zone
o free scanner starts at the end of the zone but finds that the
migration scanner is already there
o free scanner gets reinitialised for the next cycle as
cc->migrate_pfn + pageblock_nr_pages
moving the free scanner into the next zone
o migration scanner moves into the next zoneWhen this happens, NR_ISOLATED accounting goes haywire because some of the
accounting happens against the wrong zone. One zones counter remains
positive while the other goes negative even though the overall global
count is accurate. This was reported on X86-32 with !SMP because !SMP
allows the negative counters to be visible. The fact that it is the bug
should theoritically be possible there.Signed-off-by: Mel Gorman
Reviewed-by: Minchan Kim
Reviewed-by: Michal Hocko
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
Signed-off-by: Greg Kroah-Hartman -
commit 0b26859027ce0005ef89520af20351360e51ad76 upstream.
If quota is not enabled when ext4_quota_off() is called, we must not
dereference quota file inode since it is NULL. Check properly for
this.This fixes a bug in commit 21f976975cbe (ext4: remove unnecessary
[cm]time update of quota file), which was merged for 2.6.39-rc3.Reported-by: Amir Goldstein
Signed-off-by: Amir Goldstein
Signed-off-by: Jan Kara
Signed-off-by: "Theodore Ts'o"
Cc: Chris Dunlop
Signed-off-by: Greg Kroah-Hartman -
commit 8c56cacc724c7650b893d43068fa66044aa29a61 upstream.
To work around controllers which can't properly plug events while
reset, ata_eh_reset() clears error states and ATA_PFLAG_EH_PENDING
after reset but before RESET is marked done. As reset is the final
recovery action and full verification of devices including onlineness
and classfication match is done afterwards, this shouldn't lead to
lost devices or missed hotplug events.Unfortunately, it forgot to thaw the port when clearing EH_PENDING, so
if the condition happens after resetting an empty port, the port could
be left frozen and EH will end without thawing it, making the port
unresponsive to further hotplug events.Thaw if the port is frozen after clearing EH_PENDING. This problem is
reported by Bruce Stenning in the following thread.http://thread.gmane.org/gmane.linux.kernel/1123265
stable: I think we should weather this patch a bit longer in -rcX
before sending it to -stable. Please wait at least a month
after this patch makes upstream. Thanks.-v2: Fixed spelling in the comment per Dave Howorth.
Signed-off-by: Tejun Heo
Reported-by: Bruce Stenning
Cc: Dave Howorth
Signed-off-by: Jeff Garzik
Signed-off-by: Greg Kroah-Hartman -
commit 4746efded84d7c5a9c8d64d4c6e814ff0cf9fb42 upstream.
I'm running a workload which triggers a lot of swap in a machine with 4
nodes. After I kill the workload, I found a kswapd livelock. Sometimes
kswapd3 or kswapd2 are keeping running and I can't access filesystem,
but most memory is free.This looks like a regression since commit 08951e545918c159 ("mm: vmscan:
correct check for kswapd sleeping in sleeping_prematurely").Node 2 and 3 have only ZONE_NORMAL, but balance_pgdat() will return 0
for classzone_idx. The reason is end_zone in balance_pgdat() is 0 by
default, if all zones have watermark ok, end_zone will keep 0.Later sleeping_prematurely() always returns true. Because this is an
order 3 wakeup, and if classzone_idx is 0, both balanced_pages and
present_pages in pgdat_balanced() are 0. We add a special case here.
If a zone has no page, we think it's balanced. This fixes the livelock.Signed-off-by: Shaohua Li
Acked-by: Mel Gorman
Cc: Minchan Kim
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
Signed-off-by: Greg Kroah-Hartman -
commit 9daedd833a38edd90cf7baa1b1fcf61c3a0721e3 upstream.
Video input mux settings for tvp7002 and imager inputs were swapped.
Comment was correct.Tested on EVM with tvp7002 input.
Signed-off-by: Jon Povey
Acked-by: Manjunath Hadli
Signed-off-by: Sekhar Nori
Signed-off-by: Greg Kroah-Hartman -
commit b7798d28ec15d20fd34b70fa57eb13f0cf6d1ecd upstream.
Rebooting on the Dell E5420 often hangs with the keyboard or ACPI
methods, but is reliable via the PCI method.[ hpa: this was deferred because we believed for a long time that the
recent reshuffling of the boot priorities in commit
660e34cebf0a11d54f2d5dd8838607452355f321 fixed this platform.
Unfortunately that turned out to be incorrect. ]Signed-off-by: Daniel J Blueman
Link: http://lkml.kernel.org/r/1305248699-2347-1-git-send-email-daniel.blueman@gmail.com
Signed-off-by: H. Peter Anvin
Signed-off-by: Greg Kroah-Hartman -
commit 803862a6f7de4939e0a557214e5e4b37e36f87ff upstream.
The function esdhc_readl_le intends to clear bit SDHCI_CARD_PRESENT,
when the card detect gpio tells there is no card. But it does not
clear the bit actually. The patch gives a fix on that.Signed-off-by: Shawn Guo
Acked-by: Wolfram Sang
Signed-off-by: Chris Ball
Signed-off-by: Greg Kroah-Hartman -
commit 15bed0f2fa8e1d7db201692532c210a7823d2d21 upstream.
Ricoh 1180:e823 does not recognize certain types of SD/MMC cards,
as reported at http://launchpad.net/bugs/773524. Lowering the SD
base clock frequency from 200Mhz to 50Mhz fixes this issue. This
solution was suggest by Koji Matsumuro, Ricoh Company, Ltd.This change has no negative performance effect on standard SD
cards, though it's quite possible that there will be one on
UHS-1 cards.Signed-off-by: Manoj Iyer
Tested-by: Daniel Manrique
Cc: Koji Matsumuro
Acked-by: Jesse Barnes
Signed-off-by: Chris Ball
Signed-off-by: Greg Kroah-Hartman -
commit d3f684f2820a7f42acef68bea6622d9032127fb2 upstream.
spi_sync call uses its spi_message parameter to keep completion information,
using a drvdata structure is not thread-safe. Use a mutex to prevent
multiple access to shared driver data.Signed-off-by: Pavel Herrmann
Acked-by: Russell King
Acked-by: Pavel Machek
Acked-by: Marek Vasut
Acked-by: Cyril Hrubis
Tested-by: Stanislav Brabec
Signed-off-by: Jean Delvare
Signed-off-by: Greg Kroah-Hartman -
commit 0b8e77f12cb6bfe2e5a67f2cdc8c7af23abc4ccf upstream.
The object returned by atk_gitm is dynamically allocated and must be
freed.Signed-off-by: Luca Tettamanti
Signed-off-by: Jean Delvare
Signed-off-by: Greg Kroah-Hartman -
commit fa8b69758e65b406c8010936b541cd00deef804d upstream.
A copy-and-paste error caused it87_attributes_vid to be referenced
where it87_attributes_label should be. Thankfully the group is only
used for attribute removal, not attribute creation, so the effects of
this bug are limited, but let's fix it still.Signed-off-by: Jean Delvare
Acked-by: Guenter Roeck
Signed-off-by: Greg Kroah-Hartman -
commit b35e160a111aa9ae3fad6294e038be20d0da721b upstream.
Signed-off-by: Mark Brown
Signed-off-by: Greg Kroah-Hartman -
commit b793eb60a01d5b5e4aaeb2fbc2b036dec0d9f84d upstream.
The WM8994 and WM8958 series of devices have two MICBIAS supplies rather
than one, the current widget actually manages the microphone detection
control register bit (which is managed separately by the relevant API).Fix this, hooking the relevant supplies up to the MICBIAS1 and MICBIAS2
widgets.Signed-off-by: Mark Brown
Signed-off-by: Greg Kroah-Hartman -
commit dc6b845044ccb7e9e6f3b7e71bd179b3cf0223b6 upstream.
While compiling it with Fedora 15, I noticed this issue:
inlined from ‘si4713_write_econtrol_string’ at drivers/media/radio/si4713-i2c.c:1065:24:
arch/x86/include/asm/uaccess_32.h:211:26: error: call to ‘copy_from_user_overflow’ declared with attribute error: copy_from_user() buffer size is not provably correctSigned-off-by: Mauro Carvalho Chehab
Acked-by: Sakari Ailus
Acked-by: Eduardo Valentin
Reviewed-by: Eugene Teo
Signed-off-by: Linus Torvalds
Signed-off-by: Greg Kroah-Hartman -
commit d7515b8866b60c9526d2d7af37ebcd16c3c5ed97 upstream.
This reverts commit e38030f3ff02684eb9e25e983a03ad318a10a2ea.
MSI flat-out doesn't work right on cx2388x devices yet. There are now
multiple reports of cards that hard-lock systems when MSI is enabled,
including my own HVR-1250 when trying to use its built-in IR receiver.
Disable MSI and it works just fine. Similar for another user's HVR-1270.
Issues have also been reported with the HVR-1850 when MSI is enabled,
and the 1850 behavior sounds similar to an as-yet-undiagnosed issue I've
seen with an 1800.CC: Steven Toth
CC: Kusanagi Kouichi
Signed-off-by: Jarod Wilson
Acked-by: Andy Walls
Signed-off-by: Mauro Carvalho Chehab
Signed-off-by: Greg Kroah-Hartman -
commit 6905d9e4dda6112f007e9090bca80507da158e63 upstream.
The GFS2 fallocate code chooses a target size to for allocating chunks of
space. Whenever it can't find any resource groups with enough space free, it
halves its target. Since this target is in bytes, eventually it will no longer
be a multiple of blksize. As long as there is more space available in the
resource group than the target, this isn't a problem, since gfs2 will use the
actual space available, which is always a multiple of blksize. However,
when gfs couldn't fallocate a bigger chunk than the target, it was using the
non-blksize aligned number. This caused a BUG in later code that required
blksize aligned offsets. GFS2 now ensures that bytes is always a multiple of
blksizeSigned-off-by: Benjamin Marzinski
Signed-off-by: Steven Whitehouse
Signed-off-by: Greg Kroah-Hartman -
commit 498c555f56a02ec1059bc150cde84411ba0ac010 upstream.
We need to take a reference to this object, pinning doesn't take a reference
so if userspace deletes the object it can disappear even if pinned.v2: fix error paths to unreference properly also.
should fix:
https://bugzilla.kernel.org/show_bug.cgi?id=32402
and
https://bugzilla.redhat.com/show_bug.cgi?id=680651Acked-By: Alex Deucher
Signed-off-by: Dave Airlie
Signed-off-by: Greg Kroah-Hartman -
commit b7eff394670366a42935bfbaef67a6f7185627d7 upstream.
evergreen+ asics have 2-6 crtcs. Don't access crtc registers
for crtc regs that don't exist as they have very high latency
and may cause problems on some asics. The previous code missed
a few cases and was not fine grained enough (missed the 4 crtc
case for example).Fixes:
https://bugs.freedesktop.org/show_bug.cgi?id=38800v2: fix typo noticed by Chris Bandy
Signed-off-by: Alex Deucher
Reviewed-by: Michel Dänzer
Tested-by: Simon Farnsworth
Signed-off-by: Dave Airlie
Signed-off-by: Greg Kroah-Hartman -
commit 37000b305bff81bb1ee2f7f37b1319b670a08f76 upstream.
Signed-off-by: Pavel Roskin
Signed-off-by: John W. Linville
Signed-off-by: Greg Kroah-Hartman -
commit 95acbd432b4c6498c5b4b2f92e0e05e3c032d4f8 upstream.
Signed-off-by: Pavel Roskin
Signed-off-by: John W. Linville
Signed-off-by: Greg Kroah-Hartman -
commit 4f6760b01bda625e9555e16d8e9ba8126a9c9498 upstream.
While sending aggregated frames in AES, the AR5416 chips
required additional padding b/w subframes. This workaround
is not needed for edma (AR9003 family) chips. With this patch
~4Mbps thoughput improvement was observed in clear environment.Signed-off-by: Rajkumar Manoharan
Signed-off-by: John W. Linville
Signed-off-by: Greg Kroah-Hartman -
commit e3c1620434ac77b618ce74c024ace3559602ac99 upstream.
Signed-off-by: Alex Deucher
Signed-off-by: Dave Airlie
Signed-off-by: Greg Kroah-Hartman -
commit ec0dd267bf7d08cb30e321e45a75fd40edd7e528 upstream.
Because struct rpcbind_args *map was declared static, if two
threads entered this method at the same time, the values
assigned to map could be sent two two differen tasks.
This could cause all sorts of problems, include use-after-free
and double-free of memory.Fix this by removing the static declaration so that the map
pointer is on the stack.Signed-off-by: Ben Greear
Signed-off-by: Trond Myklebust
Signed-off-by: Greg Kroah-Hartman
