10 Dec, 2010
40 commits
-
commit 72083646528d4887b920deb71b37e09bc7d227bb upstream.
This avoids some include-file hell, and the function isn't really
important enough to be inlined anyway.Reported-by: Ingo Molnar
Signed-off-by: Linus Torvalds
Signed-off-by: Greg Kroah-Hartman -
commit c66fb347946ebdd5b10908866ecc9fa05ee2cf3d upstream.
And in particular, use it in 'pipe_fcntl()'.
The other pipe functions do not need to use the 'careful' version, since
they are only ever called for things that are already known to be pipes.The normal read/write/ioctl functions are called through the file
operations structures, so if a file isn't a pipe, they'd never get
called. But pipe_fcntl() is special, and called directly from the
generic fcntl code, and needs to use the same careful function that the
splice code is using.Cc: Jens Axboe
Cc: Andrew Morton
Cc: Al Viro
Cc: Dave Jones
Signed-off-by: Linus Torvalds
Signed-off-by: Greg Kroah-Hartman -
commit 71993e62a47dabddf10302807d6aa260455503f4 upstream.
.. and change it to take the 'file' pointer instead of an inode, since
that's what all users want anyway.The renaming is preparatory to exporting it to other users. The old
'pipe_info()' name was too generic and is already used elsewhere, so
before making the function public we need to use a more specific name.Cc: Jens Axboe
Cc: Andrew Morton
Cc: Al Viro
Cc: Dave Jones
Signed-off-by: Linus Torvalds
Signed-off-by: Greg Kroah-Hartman -
commit e8129c642155616d9e2160a75f103e127c8c3708 upstream.
On each machine check all registers are revalidated. The save area for
the clock comparator however only contains the upper most seven bytes
of the former contents, if valid.
Therefore the machine check handler uses a store clock instruction to
get the current time and writes that to the clock comparator register
which in turn will generate an immediate timer interrupt.
However within the lowcore the expected time of the next timer
interrupt is stored. If the interrupt happens before that time the
handler won't be called. In turn the clock comparator won't be
reprogrammed and therefore the interrupt condition stays pending which
causes an interrupt loop until the expected time is reached.On NOHZ machines this can result in unresponsive machines since the
time of the next expected interrupted can be a couple of days in the
future.To fix this just revalidate the clock comparator register with the
expected value.
In addition the special handling for udelay must be changed as well.Signed-off-by: Heiko Carstens
Signed-off-by: Martin Schwidefsky
Signed-off-by: Greg Kroah-Hartman -
commit d5d3ebe3be5c5123f2d444e186717f45284151e2 upstream.
If r8196 received packets with invalid sctp/igmp(not tcp, udp) checksum, r8196 set skb->ip_summed
wit CHECKSUM_UNNECESSARY. This cause that upper protocol don't check checksum field.I am not family with r8196 driver. I try to guess the meaning of RxProtoIP and IPFail.
RxProtoIP stands for received IPv4 packet that upper protocol is not tcp and udp.
!(opts1 & IPFail) is true means that driver correctly to check checksum in IPv4 header.If it's right, I think we should not set ip_summed wit CHECKSUM_UNNECESSARY for my sctp packets
with invalid checksum.If it's not right, please tell me.
Signed-off-by: Shan Wei
Acked-by: Francois Romieu
Signed-off-by: David S. Miller
Signed-off-by: Greg Kroah-Hartman -
commit 53f57357ff0afc37804f4e82ee3123e0c0a2cad6 upstream.
The original patch helps under obscure conditions (no pun) but
some 8168 do not like it. The change needs to be tightened with
a specific 8168 version.This reverts commit 801e147cde02f04b5c2f42764cd43a89fc7400a2
("r8169: Handle rxfifo errors on 8168 chips").Regression at https://bugzilla.kernel.org/show_bug.cgi?id=20882
Signed-off-by: Francois Romieu
Tested-by: Andreas Radke
Cc: Matthew Garrett
Cc: Daniel J Blueman
Signed-off-by: David S. Miller
Signed-off-by: Greg Kroah-Hartman -
commit fccec10b33503a2b1197c8e7a3abd30443bedb08 upstream.
Fix switching device to low-speed mode after resume reported in:
https://bugzilla.redhat.com/show_bug.cgi?id=502974Reported-and-tested-by: Laurentiu Badea
Signed-off-by: Stanislaw Gruszka
Signed-off-by: David S. Miller
Cc: Francois Romieu
Signed-off-by: Greg Kroah-Hartman -
commit adea1ac7effbddbe60a9de6d63462bfe79289e59 upstream.
While porting GRO to r8169, I found this driver has a bug in its rx
path.All skbs given to network stack had their ip_summed set to
CHECKSUM_NONE, while hardware said they had correct TCP/UDP checksums.The reason is driver sets skb->ip_summed on the original skb before the
copy eventually done by copybreak. The fresh skb gets the ip_summed =
CHECKSUM_NONE value, forcing network stack to recompute checksum, and
preventing my GRO patch to work.Fix is to make the ip_summed setting after skb copy.
Note : rx_copybreak current value is 16383, so all frames are copied...
Signed-off-by: Eric Dumazet
Acked-by: Francois Romieu
Signed-off-by: David S. Miller
Signed-off-by: Greg Kroah-Hartman -
commit 0310871d8f71da4ad8643687fbc40f219a0dac4d upstream.
The switch to the new control framework caused a regression where the audio was
no longer unmuted after the carrier scan finished.The original code attempted to set the volume control to its current value in
order to have the set-volume control code to be called that handles the volume
and muting. However, the framework will not call that code unless the new volume
value is different from the old.Instead we now call msp_s_ctrl directly.
It is a bit of a hack: we really need a v4l2_ctrl_refresh_ctrl function for this
(or something along those lines).Thanks to Andy Walls for bisecting this and to Shane Shrybman for reporting it!
Reported-by: Shane Shrybman
Thanks-to: Andy Walls
Signed-off-by: Hans Verkuil
Signed-off-by: Mauro Carvalho Chehab
Signed-off-by: Greg Kroah-Hartman -
commit 4da26e162b69d89c3186a35a052c05e61a555637 upstream.
Add the module parameter ql2xgffidenable to disable/enable the use of the
GFF_ID name server command to prevent non FCP SCSI devices from being added to
the driver's internal fc_port database.Signed-off-by: Chad Dupuis
Signed-off-by: Madhuranath Iyengar
Signed-off-by: James Bottomley
Signed-off-by: Greg Kroah-Hartman -
commit 9236d838c920e90708570d9bbd7bb82d30a38130 upstream.
When operating in a mode that initiates communication and using
HT40 we should fail if we cannot use both primary and secondary
channels to initiate communication. Our current ht40 allowmap
only covers STA mode of operation, for beaconing modes we need
a check on the fly as the mode of operation is dynamic and
there other flags other than disable which we should read
to check if we can initiate communication.Do not allow for initiating communication if our secondary HT40
channel has is either disabled, has a passive scan flag, a
no-ibss flag or is a radar channel. Userspace now has similar
checks but this is also needed in-kernel.Reported-by: Jouni Malinen
Signed-off-by: Luis R. Rodriguez
Signed-off-by: John W. Linville
Signed-off-by: Greg Kroah-Hartman -
commit 218854af84038d828a32f061858b1902ed2beec6 upstream.
In rds_cmsg_rdma_args(), the user-provided args->nr_local value is
restricted to less than UINT_MAX. This seems to need a tighter upper
bound, since the calculation of total iov_size can overflow, resulting
in a small sock_kmalloc() allocation. This would probably just result
in walking off the heap and crashing when calling rds_rdma_pages() with
a high count value. If it somehow doesn't crash here, then memory
corruption could occur soon after.Signed-off-by: Dan Rosenberg
Signed-off-by: David S. Miller
Signed-off-by: Greg Kroah-Hartman -
commit a27e13d370415add3487949c60810e36069a23a6 upstream.
Don't declare variable sized array of iovecs on the stack since this
could cause stack overflow if msg->msgiovlen is large. Instead, coalesce
the user-supplied data into a new buffer and use a single iovec for it.Signed-off-by: Phil Blundell
Signed-off-by: David S. Miller
Signed-off-by: Greg Kroah-Hartman -
commit 16c41745c7b92a243d0874f534c1655196c64b74 upstream.
Add missing check for capable(CAP_NET_ADMIN) in SIOCSIFADDR operation.
Signed-off-by: Phil Blundell
Signed-off-by: David S. Miller
Signed-off-by: Greg Kroah-Hartman -
commit fa0e846494792e722d817b9d3d625a4ef4896c96 upstream.
Later parts of econet_sendmsg() rely on saddr != NULL, so return early
with EINVAL if NULL was passed otherwise an oops may occur.Signed-off-by: Phil Blundell
Signed-off-by: David S. Miller
Signed-off-by: Greg Kroah-Hartman -
commit a1c6c5698d53db4c47a25c3a8d11731a4d7b8370 upstream.
Fix NULL pointer dereference in print_daily_error_info, when
called on unmounted fs (EXT4_SB(sb) returns NULL), by removing error
reporting timer in ext4_put_super.Google-Bug-Id: 3017663
Signed-off-by: Sergey Senozhatsky
Signed-off-by: "Theodore Ts'o"
Cc: Thomas Meyer
Signed-off-by: Greg Kroah-Hartman -
commit c054a076a1bd4731820a9c4d638b13d5c9bf5935 upstream.
On certain VIA chipsets AES-CBC requires the input/output to be
a multiple of 64 bytes. We had a workaround for this but it was
buggy as it sent the whole input for processing when it is meant
to only send the initial number of blocks which makes the rest
a multiple of 64 bytes.As expected this causes memory corruption whenever the workaround
kicks in.Reported-by: Phil Sutter
Signed-off-by: Herbert Xu
Signed-off-by: Greg Kroah-Hartman -
commit 5ef41308f94dcbb3b7afc56cdef1c2ba53fa5d2f upstream.
Now with improved comma support.
On parsing malformed X.25 facilities, decrementing the remaining length
may cause it to underflow. Since the length is an unsigned integer,
this will result in the loop continuing until the kernel crashes.This patch adds checks to ensure decrementing the remaining length does
not cause it to wrap around.Signed-off-by: Dan Rosenberg
Signed-off-by: David S. Miller
Signed-off-by: Greg Kroah-Hartman -
commit 0597d1b99fcfc2c0eada09a698f85ed413d4ba84 upstream.
On 64-bit platforms the ASCII representation of a pointer may be up to 17
bytes long. This patch increases the length of the buffer accordingly.http://marc.info/?l=linux-netdev&m=128872251418192&w=2
Reported-by: Dan Rosenberg
Signed-off-by: Oliver Hartkopp
CC: Linus Torvalds
Signed-off-by: David S. Miller
Signed-off-by: Greg Kroah-Hartman -
commit 57fe93b374a6b8711995c2d466c502af9f3a08bb upstream.
There is a possibility malicious users can get limited information about
uninitialized stack mem array. Even if sk_run_filter() result is bound
to packet length (0 .. 65535), we could imagine this can be used by
hostile user.Initializing mem[] array, like Dan Rosenberg suggested in his patch is
expensive since most filters dont even use this array.Its hard to make the filter validation in sk_chk_filter(), because of
the jumps. This might be done later.In this patch, I use a bitmap (a single long var) so that only filters
using mem[] loads/stores pay the price of added security checks.For other filters, additional cost is a single instruction.
[ Since we access fentry->k a lot now, cache it in a local variable
and mark filter entry pointer as const. -DaveM ]Reported-by: Dan Rosenberg
Signed-off-by: Eric Dumazet
Signed-off-by: David S. Miller
Signed-off-by: Greg Kroah-Hartman -
commit c94d3fb01fb6db1899cdf53ea4eb9d38e08a08fe upstream.
NetBSD lacks getopt_long_only() whereas getopt_long() works just fine.
Signed-off-by: Arnaud Lacombe
Acked-by: Sam Ravnborg
Signed-off-by: Michal Marek
Signed-off-by: Greg Kroah-Hartman -
[This patch applies only to 2.6.36 stable. The problem was introduced
in that release and is already fixed by larger changes to the vlan
code in 2.6.37.]Normally hardware accelerated vlan packets are quickly dropped if
there is no corresponding vlan device configured. The one exception
is promiscuous mode, where we allow all of these packets through so
they can be picked up by tcpdump. However, this behavior causes a
crash if we actually try to receive these packets. This fixes that
crash by ignoring packets with vids not corresponding to a configured
device in the vlan hwaccel routines and then dropping them before they
get to consumers in the network stack.Reported-by: Ben Greear
Tested-by: Nikola Ciprich
Signed-off-by: Jesse Gross
Acked-by: David Miller
Signed-off-by: Greg Kroah-Hartman -
commit a6331d6f9a4298173b413cf99a40cc86a9d92c37 upstream.
Signed-of-by: Andrew Hendry
Signed-off-by: David S. Miller
Signed-off-by: Greg Kroah-Hartman -
commit 0e4905c0199d683497833be60a428c784d7575b8 upstream.
Implement the suggested workaround for OMAP3 regarding to sDMA draining
issue, when the channel is disabled on the fly.
This errata affects the following configuration:
sDMA transfer is source synchronized
Buffering is enabled
SmartStandby is selected.The issue can be easily reproduced by creating overrun situation while
recording audio.
Either introduce load to the CPU:
nice -19 arecord -D hw:0 -M -B 10000 -F 5000 -f dat > /dev/null & \
dd if=/dev/urandom of=/dev/nullor suspending the arecord, and resuming it:
arecord -D hw:0 -M -B 10000 -F 5000 -f dat > /dev/null
CTRL+Z; fg; CTRL+Z; fg; ...In case of overrun audio stops DMA, and restarts it (without reseting
the sDMA channel). When we hit this errata in stop case (sDMA drain did
not complete), at the coming start the sDMA will not going to be
operational (it is still draining).
This leads to DMA stall condition.
On OMAP3 we can recover with sDMA channel reset, it has been observed
that by introducing unrelated sDMA activity might also help (reading
from MMC for example).The same errata exists for OMAP2, where the suggestion is to disable the
buffering to avoid this type of error.
On OMAP3 the suggestion is to set sDMA to NoStandby before disabling
the channel, and wait for the drain to finish, than configure sDMA to
SmartStandby again.Signed-off-by: Peter Ujfalusi
Acked-by: Jarkko Nikula
Acked-by : Santosh Shilimkar
Acked-by : Manjunath Kondaiah G
Signed-off-by: Tony Lindgren
Signed-off-by: Greg Kroah-Hartman -
commit 3e57f1626b5febe5cc99aa6870377deef3ae03cc upstream.
An errata workaround for omap24xx is not setting the buffering disable bit
25 what is the purpose but channel enable bit 7 instead.Background for this fix is the DMA stalling issue with ASoC omap-mcbsp
driver. Peter Ujfalusi has found an issue in
recording that the DMA stall could happen if there were a buffer overrun
detected by ALSA and the DMA was stopped and restarted due that. This
problem is known to occur on both OMAP2420 and OMAP3. It can recover on
OMAP3 after dma free, dma request and reconfiguration cycle. However, on
OMAP2420 it seems that only way to recover is a reset.Problem was not visible before the commit c12abc0. That commit changed that
the McBSP transmitter/receiver is released from reset only when needed. That
is, only enabled McBSP transmitter without transmission was able to prevent
this DMA stall problem in receiving side and underlying problem did not show
up until now. McBSP transmitter itself seems to no be reason since DMA
stall does not recover by enabling the transmission after stall.Debugging showed that there were a DMA write active during DMA stop time and
it never completed even when restarting the DMA. Experimenting showed that
the DMA buffering disable bit could be used to avoid stalling when using
source synchronized transfers. However that could have performance hit and
OMAP3 TRM states that buffering disable is not allowed for destination
synchronized transfers so subsequent patch will implement a method to
complete DMA writes when stopping.This patch is based on assumtion that complete lock-up on OMAP2420 is
different but related problem. I don't have access to OMAP2420 errata but
I believe this old workaround here is put for a reason but unfortunately
a wrong bit was typed and problem showed up only now.Signed-off-by: Jarkko Nikula
Signed-off-by: Peter Ujfalusi
Acked-by: Manjunath Kondaiah G
Signed-off-by: Tony Lindgren
Signed-off-by: Greg Kroah-Hartman -
[Note that the mainline will not have this particular fix but rather
will blacklist entire VAIO line based off DMI board name. For stable
I am being a bit more cautious and blacklist one particular product.]Trying to query/activate active multiplexing mode on this VAIO makes
both keyboard and touchpad inoperable. Futher kernels will blacklist
entire VAIO line, however here we blacklist just one particular model.Reported-by: Jesse Barnes
Signed-off-by: Dmitry Torokhov
Signed-off-by: Greg Kroah-Hartman -
commit 8acfe468b0384e834a303f08ebc4953d72fb690a upstream.
This helps protect us from overflow issues down in the
individual protocol sendmsg/recvmsg handlers. Once
we hit INT_MAX we truncate out the rest of the iovec
by setting the iov_len members to zero.This works because:
1) For SOCK_STREAM and SOCK_SEQPACKET sockets, partial
writes are allowed and the application will just continue
with another write to send the rest of the data.2) For datagram oriented sockets, where there must be a
one-to-one correspondance between write() calls and
packets on the wire, INT_MAX is going to be far larger
than the packet size limit the protocol is going to
check for and signal with -EMSGSIZE.Based upon a patch by Linus Torvalds.
Signed-off-by: David S. Miller
Signed-off-by: Greg Kroah-Hartman -
commit 253eacc070b114c2ec1f81b067d2fed7305467b0 upstream.
Signed-off-by: Linus Torvalds
Signed-off-by: David S. Miller
Signed-off-by: Greg Kroah-Hartman -
commit 25c9170ed64a6551beefe9315882f754e14486f4 upstream.
Since commit a1afb637(switch /proc/irq/*/spurious to seq_file) all
/proc/irq/XX/spurious files show the information of irq 0.Current irq_spurious_proc_open() passes on NULL as the 3rd argument,
which is used as an IRQ number in irq_spurious_proc_show(), to the
single_open(). Because of this, all the /proc/irq/XX/spurious file
shows IRQ 0 information regardless of the IRQ number.To fix the problem, irq_spurious_proc_open() must pass on the
appropreate data (IRQ number) to single_open().Signed-off-by: Kenji Kaneshige
Reviewed-by: Yong Zhang
LKML-Reference:
Signed-off-by: Thomas Gleixner
Signed-off-by: Greg Kroah-Hartman -
commit 398812159e328478ae49b4bd01f0d71efea96c39 upstream.
This fixes the same problem as described in the patch "nohz: fix
printk_needs_cpu() return value on offline cpus" for the arch_needs_cpu()
primitive:arch_needs_cpu() may return 1 if called on offline cpus. When a cpu gets
offlined it schedules the idle process which, before killing its own cpu,
will call tick_nohz_stop_sched_tick().
That function in turn will call arch_needs_cpu() in order to check if the
local tick can be disabled. On offline cpus this function should naturally
return 0 since regardless if the tick gets disabled or not the cpu will be
dead short after. That is besides the fact that __cpu_disable() should already
have made sure that no interrupts on the offlined cpu will be delivered anyway.In this case it prevents tick_nohz_stop_sched_tick() to call
select_nohz_load_balancer(). No idea if that really is a problem. However what
made me debug this is that on 2.6.32 the function get_nohz_load_balancer() is
used within __mod_timer() to select a cpu on which a timer gets enqueued.
If arch_needs_cpu() returns 1 then the nohz_load_balancer cpu doesn't get
updated when a cpu gets offlined. It may contain the cpu number of an offline
cpu. In turn timers get enqueued on an offline cpu and not very surprisingly
they never expire and cause system hangs.This has been observed 2.6.32 kernels. On current kernels __mod_timer() uses
get_nohz_timer_target() which doesn't have that problem. However there might
be other problems because of the too early exit tick_nohz_stop_sched_tick()
in case a cpu goes offline.This specific bug was indrocuded with 3c5d92a0 "nohz: Introduce
arch_needs_cpu".In this case a cpu hotplug notifier is used to fix the issue in order to keep
the normal/fast path small. All we need to do is to clear the condition that
makes arch_needs_cpu() return 1 since it is just a performance improvement
which is supposed to keep the local tick running for a short period if a cpu
goes idle. Nothing special needs to be done except for clearing the condition.Acked-by: Peter Zijlstra
Signed-off-by: Heiko Carstens
Signed-off-by: Martin Schwidefsky
Signed-off-by: Greg Kroah-Hartman -
commit 8b14d7b22c61f17ccb869e0047d9df6dd9f50a9f upstream.
While looking for the duplicates in /sys/class/wmi/, I couldn't find
them. The code that looks for duplicates uses strncmp in a binary GUID,
which may contain zero bytes. The right function is memcmp, which is
also used in another section of wmi code.It was finding 49142400-C6A3-40FA-BADB-8A2652834100 as a duplicate of
39142400-C6A3-40FA-BADB-8A2652834100. Since the first byte is the fourth
printed, they were found as equal by strncmp.Signed-off-by: Thadeu Lima de Souza Cascardo
Signed-off-by: Matthew Garrett
Signed-off-by: Greg Kroah-Hartman -
commit c9e664f1fdf34aa8cede047b206deaa8f1945af0 upstream.
There is a problem that swap pages allocated before the creation of
a hibernation image can be released and used for storing the contents
of different memory pages while the image is being saved. Since the
kernel stored in the image doesn't know of that, it causes memory
corruption to occur after resume from hibernation, especially on
systems with relatively small RAM that need to swap often.This issue can be addressed by keeping the GFP_IOFS bits clear
in gfp_allowed_mask during the entire hibernation, including the
saving of the image, until the system is finally turned off or
the hibernation is aborted. Unfortunately, for this purpose
it's necessary to rework the way in which the hibernate and
suspend code manipulates gfp_allowed_mask.This change is based on an earlier patch from Hugh Dickins.
Signed-off-by: Rafael J. Wysocki
Reported-by: Ondrej Zary
Acked-by: Hugh Dickins
Reviewed-by: KAMEZAWA Hiroyuki
Signed-off-by: Greg Kroah-Hartman -
commit 44266416f786514ec43a0d15ad951c34566b99c9 upstream.
commit 6338a6aa7c082f11d55712251e14178c68bf5869 ("ARM: 6269/1: Add 'code'
parameter for hook_fault_code()") breaks CNS3xxx build:CC arch/arm/mach-cns3xxx/pcie.o
pcie.c: In function 'cns3xxx_pcie_init':
pcie.c:373: warning: passing argument 4 of 'hook_fault_code' makes integer from pointer without a cast
pcie.c:373: error: too few arguments to function 'hook_fault_code'This commit fixes the small issue.
Signed-off-by: Anton Vorontsov
Signed-off-by: Greg Kroah-Hartman -
commit b9f515e3e3861abbaa093359f7c6f31283695228 upstream.
This patch fixes a compilation issue when compiling PCMCIA SA1100
support as a module with PCMCIA_DEBUG enabled. The symbol
soc_pcmcia_debug was not beeing exported.
ARM: pcmcia: Fix for building DEBUG with sa11xx_base.c as a module.This patch fixes a compilation issue when compiling PCMCIA SA1100
support as a module with PCMCIA_DEBUG enabled. The symbol
soc_pcmcia_debug was not beeing exported.Signed-off-by: Marcelo Roberto Jimenez
Signed-off-by: Russell King
Signed-off-by: Greg Kroah-Hartman -
commit dddd3379a619a4cb8247bfd3c94ca9ae3797aa2e upstream.
It was found that sometimes children of tasks with inherited events had
one extra event. Eventually it turned out to be due to the list rotation
no being exclusive with the list iteration in the inheritance code.Cure this by temporarily disabling the rotation while we inherit the events.
Signed-off-by: Thomas Gleixner
Signed-off-by: Peter Zijlstra
LKML-Reference:
Signed-off-by: Ingo Molnar
Signed-off-by: Greg Kroah-Hartman -
commit b6faaae1a15a352d68b3e3cd8b840e56709820bf upstream.
eth_type_trans tries to pull data with the length of the ethernet header
from the skb. We only ensured that enough data for the first ethernet
header and the batman header is available in non-paged memory of the skb
and not for the ethernet after the batman header.eth_type_trans would fail sometimes with drivers which don't ensure that
all there data is perfectly linearised.The failure was noticed through a kernel bug Oops generated by the
skb_pull inside eth_type_trans.Reported-by: Rafal Lesniak
Signed-off-by: Marek Lindner
Signed-off-by: Sven Eckelmann
Signed-off-by: Greg Kroah-Hartman -
commit f36d83a8cb7224f45fdfa1129a616dff56479a09 upstream.
This driver issues a kernel panic over conditions that do not
justify such drastic action. Change these to log entries with
a stack dump.This patch fixes the system crash reported in
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/674285.Signed-off-by: Larry Finger
Reported-and-Tested-by: Robie Basik
Signed-off-by: Greg Kroah-Hartman -
commit 3bad28ec006ad6ab2bca4e5103860b75391e3c9d and
2a767fda5d0d8dcff465724dfad6ee131489b3f2 upstream merged together.They should not be writable by any user
Reported-by: Linus Torvalds
Cc: David Taht
Signed-off-by: Greg Kroah-Hartman -
commit 4d7bc388b44e42a1feafa35e50eef4f24d6ca59d upstream.
They should be writable by root, not readable.
Doh, stupid me with the wrong flags.Reported-by: Jonathan Cameron
Signed-off-by: Greg Kroah-Hartman
