Joel Becker [Thu, 30 Sep 2010 00:33:05 +0000 (17:33 -0700)]
ocfs2: Don't walk off the end of fast symlinks.
commit
1fc8a117865b54590acd773a55fbac9221b018f0 upstream.
ocfs2 fast symlinks are NUL terminated strings stored inline in the
inode data area. However, disk corruption or a local attacker could, in
theory, remove that NUL. Because we're using strlen() (my fault,
introduced in a731d1 when removing vfs_follow_link()), we could walk off
the end of that string.
Signed-off-by: Joel Becker <joel.becker@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Yegor Yefremov [Thu, 30 Sep 2010 12:14:22 +0000 (14:14 +0200)]
i2c-pca: Fix waitforcompletion() return value
commit
6abb930af064fb1cf4177d32e2c7bfb89eee0fe5 upstream.
ret is still -1, if during the polling read_byte() returns at once
with I2C_PCA_CON_SI set. So ret > 0 would lead *_waitforcompletion()
to return 0, in spite of the proper behavior.
The routine was rewritten, so that ret has always a proper value,
before returning.
Signed-off-by: Yegor Yefremov <yegorslists@googlemail.com>
Reviewed-by: Wolfram Sang <w.sang@pengutronix.de>
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Salman Qazi [Tue, 12 Oct 2010 14:25:19 +0000 (07:25 -0700)]
hrtimer: Preserve timer state in remove_hrtimer()
commit
f13d4f979c518119bba5439dd2364d76d31dcd3f upstream.
The race is described as follows:
CPU X CPU Y
remove_hrtimer
// state & QUEUED == 0
timer->state = CALLBACK
unlock timer base
timer->f(n) //very long
hrtimer_start
lock timer base
remove_hrtimer // no effect
hrtimer_enqueue
timer->state = CALLBACK |
QUEUED
unlock timer base
hrtimer_start
lock timer base
remove_hrtimer
mode = INACTIVE
// CALLBACK bit lost!
switch_hrtimer_base
CALLBACK bit not set:
timer->base
changes to a
different CPU.
lock this CPU's timer base
The bug was introduced with commit
ca109491f (hrtimer: removing all ur
callback modes) in 2.6.29
[ tglx: Feed new state via local variable and add a comment. ]
Signed-off-by: Salman Qazi <sqazi@google.com>
Cc: akpm@linux-foundation.org
Cc: Peter Zijlstra <peterz@infradead.org>
LKML-Reference: <
20101012142351.8485.21823.stgit@dungbeetle.mtv.corp.google.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Simon Guinot [Fri, 17 Sep 2010 21:33:51 +0000 (23:33 +0200)]
dmaengine: fix interrupt clearing for mv_xor
commit
cc60f8878eab892c03d06b10f389232b9b66bd83 upstream.
When using simultaneously the two DMA channels on a same engine, some
transfers are never completed. For example, an endless lock can occur
while writing heavily on a RAID5 array (with async-tx offload support
enabled).
Note that this issue can also be reproduced by using the DMA test
client.
On a same engine, the interrupt cause register is shared between two
DMA channels. This patch make sure that the cause bit is only cleared
for the requested channel.
Signed-off-by: Simon Guinot <sguinot@lacie.com>
Tested-by: Luc Saillard <luc@saillard.org>
Acked-by: saeed bishara <saeed.bishara@gmail.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Steven Rostedt [Tue, 12 Oct 2010 16:06:43 +0000 (12:06 -0400)]
ring-buffer: Fix typo of time extends per page
commit
d01343244abdedd18303d0323b518ed9cdcb1988 upstream.
Time stamps for the ring buffer are created by the difference between
two events. Each page of the ring buffer holds a full 64 bit timestamp.
Each event has a 27 bit delta stamp from the last event. The unit of time
is nanoseconds, so 27 bits can hold ~134 milliseconds. If two events
happen more than 134 milliseconds apart, a time extend is inserted
to add more bits for the delta. The time extend has 59 bits, which
is good for ~18 years.
Currently the time extend is committed separately from the event.
If an event is discarded before it is committed, due to filtering,
the time extend still exists. If all events are being filtered, then
after ~134 milliseconds a new time extend will be added to the buffer.
This can only happen till the end of the page. Since each page holds
a full timestamp, there is no reason to add a time extend to the
beginning of a page. Time extends can only fill a page that has actual
data at the beginning, so there is no fear that time extends will fill
more than a page without any data.
When reading an event, a loop is made to skip over time extends
since they are only used to maintain the time stamp and are never
given to the caller. As a paranoid check to prevent the loop running
forever, with the knowledge that time extends may only fill a page,
a check is made that tests the iteration of the loop, and if the
iteration is more than the number of time extends that can fit in a page
a warning is printed and the ring buffer is disabled (all of ftrace
is also disabled with it).
There is another event type that is called a TIMESTAMP which can
hold 64 bits of data in the theoretical case that two events happen
18 years apart. This code has not been implemented, but the name
of this event exists, as well as the structure for it. The
size of a TIMESTAMP is 16 bytes, where as a time extend is only
8 bytes. The macro used to calculate how many time extends can fit on
a page used the TIMESTAMP size instead of the time extend size
cutting the amount in half.
The following test case can easily trigger the warning since we only
need to have half the page filled with time extends to trigger the
warning:
# cd /sys/kernel/debug/tracing/
# echo function > current_tracer
# echo 'common_pid < 0' > events/ftrace/function/filter
# echo > trace
# echo 1 > trace_marker
# sleep 120
# cat trace
Enabling the function tracer and then setting the filter to only trace
functions where the process id is negative (no events), then clearing
the trace buffer to ensure that we have nothing in the buffer,
then write to trace_marker to add an event to the beginning of a page,
sleep for 2 minutes (only 35 seconds is probably needed, but this
guarantees the bug), and then finally reading the trace which will
trigger the bug.
This patch fixes the typo and prevents the false positive of that warning.
Reported-by: Hans J. Koch <hjk@linutronix.de>
Tested-by: Hans J. Koch <hjk@linutronix.de>
Cc: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Tejun Heo [Fri, 15 Oct 2010 10:56:21 +0000 (12:56 +0200)]
ubd: fix incorrect sector handling during request restart
commit
47526903feb52f4c26a6350370bdf74e337fcdb1 upstream.
Commit
f81f2f7c (ubd: drop unnecessary rq->sector manipulation)
dropped request->sector manipulation in preparation for global request
handling cleanup; unfortunately, it incorrectly assumed that the
updated sector wasn't being used.
ubd tries to issue as many requests as possible to io_thread. When
issuing fails due to memory pressure or other reasons, the device is
put on the restart list and issuing stops. On IO completion, devices
on the restart list are scanned and IO issuing is restarted.
ubd issues IOs sg-by-sg and issuing can be stopped in the middle of a
request, so each device on the restart queue needs to remember where
to restart in its current request. ubd needs to keep track of the
issue position itself because,
* blk_rq_pos(req) is now updated by the block layer to keep track of
_completion_ position.
* Multiple io_req's for the current request may be in flight, so it's
difficult to tell where blk_rq_pos(req) currently is.
Add ubd->rq_pos to keep track of the issue position and use it to
correctly restart io_req issue.
Signed-off-by: Tejun Heo <tj@kernel.org>
Reported-by: Richard Weinberger <richard@nod.at>
Tested-by: Richard Weinberger <richard@nod.at>
Tested-by: Chris Frey <cdfrey@foursquare.net>
Signed-off-by: Jens Axboe <jaxboe@fusionio.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Thomas Gleixner [Tue, 28 Sep 2010 18:57:19 +0000 (20:57 +0200)]
x86, irq: Plug memory leak in sparse irq
commit
1cf180c94e9166cda083ff65333883ab3648e852 upstream.
free_irq_cfg() is not freeing the cpumask_vars in irq_cfg. Fixing this
triggers a use after free caused by the fact that copying struct
irq_cfg is done with memcpy, which copies the pointer not the cpumask.
Fix both places.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: Yinghai Lu <yhlu.kernel@gmail.com>
LKML-Reference: <alpine.LFD.2.00.
1009282052570.2416@localhost6.localdomain6>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Thomas Gleixner [Tue, 28 Sep 2010 21:20:23 +0000 (23:20 +0200)]
x86, hpet: Fix bogus error check in hpet_assign_irq()
commit
021989622810b02aab4b24f91e1f5ada2b654579 upstream.
create_irq() returns -1 if the interrupt allocation failed, but the
code checks for irq == 0.
Use create_irq_nr() instead.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: Venkatesh Pallipadi <venki@google.com>
LKML-Reference: <alpine.LFD.2.00.
1009282310360.2416@localhost6.localdomain6>
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Kenneth Waters [Tue, 21 Sep 2010 07:58:23 +0000 (00:58 -0700)]
Input: joydev - fix JSIOCSAXMAP ioctl
commit
d2520a426dc3033c00077e923a553fc6c98c7564 upstream.
Fixed JSIOCSAXMAP ioctl to update absmap, the map from hardware axis to
event axis in addition to abspam. This fixes a regression introduced
by
999b874f.
Signed-off-by: Kenneth Waters <kwwaters@gmail.com>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Dmitri Belimov [Fri, 8 Jan 2010 09:38:28 +0000 (06:38 -0300)]
V4L/DVB (13966): DVB-T regression fix for saa7134 cards
commit
08be64be3d1e5ecd72e7ba3147aea518e527f08e upstream.
Some customers has problem with quality of DVB-T
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/446575
After this patch http://patchwork.kernel.org/patch/23345/
This is patch for fix regression with DVB-T. Tested with many people.
Signed-off-by: Alexey Osipov <lion-simba@pridelands.ru>
Signed-off-by: Beholder Intl. Ltd. Dmitry Belimov <d.belimov@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Mauro Carvalho Chehab [Sat, 11 Sep 2010 14:37:51 +0000 (11:37 -0300)]
V4L/DVB: cx231xx: Avoid an OOPS when card is unknown (card=0)
commit
c10469c637602c2385e2993d8c730cc44fd47d23 upstream.
As reported by: Carlos Americo Domiciano <c_domiciano@yahoo.com.br>:
[ 220.033500] cx231xx v4l2 driver loaded.
[ 220.033571] cx231xx #0: New device Conexant Corporation Polaris AV Capturb @ 480 Mbps (1554:5010) with 6 interfaces
[ 220.033577] cx231xx #0: registering interface 0
[ 220.033591] cx231xx #0: registering interface 1
[ 220.033654] cx231xx #0: registering interface 6
[ 220.033910] cx231xx #0: Identified as Unknown CX231xx video grabber (card=0)
[ 220.033946] BUG: unable to handle kernel NULL pointer dereference at (null)
[ 220.033955] IP: [<
ffffffffa0d3c8bd>] cx231xx_pre_card_setup+0x5d/0xb0 [cx231xx]
Thanks-to: Carlos Americo Domiciano <c_domiciano@yahoo.com.br>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Linus Torvalds [Fri, 15 Oct 2010 18:12:38 +0000 (11:12 -0700)]
v4l1: fix 32-bit compat microcode loading translation
commit
3e645d6b485446c54c6745c5e2cf5c528fe4deec upstream.
The compat code for the VIDIOCSMICROCODE ioctl is totally buggered.
It's only used by the VIDEO_STRADIS driver, and that one is scheduled to
staging and eventually removed unless somebody steps up to maintain it
(at which point it should use request_firmware() rather than some magic
ioctl). So we'll get rid of it eventually.
But in the meantime, the compatibility ioctl code is broken, and this
tries to get it to at least limp along (even if Mauro suggested just
deleting it entirely, which may be the right thing to do - I don't think
the compatibility translation code has ever worked unless you were very
lucky).
Reported-by: Kees Cook <kees.cook@canonical.com>
Cc: Mauro Carvalho Chehab <mchehab@infradead.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Steven Rostedt [Thu, 23 Sep 2010 02:22:25 +0000 (22:22 -0400)]
tracing/x86: Don't use mcount in kvmclock.c
commit
258af47479980d8238a04568b94a4e55aa1cb537 upstream.
The guest can use the paravirt clock in kvmclock.c which is used
by sched_clock(), which in turn is used by the tracing mechanism
for timestamps, which leads to infinite recursion.
Disable mcount/tracing for kvmclock.o.
Cc: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
Cc: Avi Kivity <avi@redhat.com>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Jeremy Fitzhardinge [Thu, 23 Sep 2010 00:07:27 +0000 (17:07 -0700)]
tracing/x86: Don't use mcount in pvclock.c
commit
9ecd4e1689208afe9b059a5ce1333acb2f42c4d2 upstream.
When using a paravirt clock, pvclock.c can be used by sched_clock(),
which in turn is used by the tracing mechanism for timestamps,
which leads to infinite recursion.
Disable mcount/tracing for pvclock.o.
Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
LKML-Reference: <
4C9A9A3F.
4040201@goop.org>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Joerg Roedel [Thu, 23 Sep 2010 13:15:19 +0000 (15:15 +0200)]
x86/amd-iommu: Work around S3 BIOS bug
commit
4c894f47bb49284008073d351c0ddaac8860864e upstream.
This patch adds a workaround for an IOMMU BIOS problem to
the AMD IOMMU driver. The result of the bug is that the
IOMMU does not execute commands anymore when the system
comes out of the S3 state resulting in system failure. The
bug in the BIOS is that is does not restore certain hardware
specific registers correctly. This workaround reads out the
contents of these registers at boot time and restores them
on resume from S3. The workaround is limited to the specific
IOMMU chipset where this problem occurs.
Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Joerg Roedel [Thu, 23 Sep 2010 14:12:48 +0000 (16:12 +0200)]
x86/amd-iommu: Fix rounding-bug in __unmap_single
commit
04e0463e088b41060c08c255eb0d3278a504f094 upstream.
In the __unmap_single function the dma_addr is rounded down
to a page boundary before the dma pages are unmapped. The
address is later also used to flush the TLB entries for that
mapping. But without the offset into the dma page the amount
of pages to flush might be miscalculated in the TLB flushing
path. This patch fixes this bug by using the original
address to flush the TLB.
Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Joerg Roedel [Mon, 20 Sep 2010 12:33:07 +0000 (14:33 +0200)]
x86/amd-iommu: Set iommu configuration flags in enable-loop
commit
e9bf51971157e367aabfc111a8219db010f69cd4 upstream.
This patch moves the setting of the configuration and
feature flags out out the acpi table parsing path and moves
it into the iommu-enable path. This is needed to reliably
fix resume-from-s3.
Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Marek Szyprowski [Thu, 23 Sep 2010 14:22:05 +0000 (16:22 +0200)]
mmc: sdhci-s3c: fix NULL ptr access in sdhci_s3c_remove
commit
9320f7cbbdd5febf013b0e91db29189724057738 upstream.
If not all clocks have been defined in platform data, the driver will
cause a null pointer dereference when it is removed. This patch fixes
this issue.
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Chris Ball <cjb@laptop.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Steve Wise [Sun, 19 Sep 2010 00:38:21 +0000 (19:38 -0500)]
RDMA/cxgb3: Turn off RX coalescing for iWARP connections
commit
bec658ff31453a5726b1c188674d587a5d40c482 upstream.
The HW by default has RX coalescing on. For iWARP connections, this
causes a 100ms delay in connection establishement due to the ingress
MPA Start message being stalled in HW. So explicitly turn RX
coalescing off when setting up iWARP connections.
This was causing very bad performance for NP64 gather operations using
Open MPI, due to the way it sets up connections on larger jobs.
Signed-off-by: Steve Wise <swise@opengridcomputing.com>
Signed-off-by: Roland Dreier <rolandd@cisco.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Jiri Olsa [Tue, 21 Sep 2010 07:26:35 +0000 (03:26 -0400)]
oprofile: Add Support for Intel CPU Family 6 / Model 29
commit
bb7ab785ad05a97a2c9ffb3a06547ed39f3133e8 upstream.
This patch adds CPU type detection for dunnington processor (Family 6
/ Model 29) to be identified as core 2 family cpu type (wikipedia
source).
I tested oprofile on Intel(R) Xeon(R) CPU E7440 reporting itself as
model 29, and it runs without an issue.
Spec:
http://www.intel.com/Assets/en_US/PDF/specupdate/320336.pdf
Signed-off-by: Jiri Olsa <jolsa@redhat.com>
Acked-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Robert Richter <robert.richter@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Sergei Shtylyov [Sat, 11 Sep 2010 18:23:12 +0000 (13:23 -0500)]
usb: musb: gadget: restart request on clearing endpoint halt
commit
a666e3e6098a9f56310e4ec2705f1dad124a34b5 upstream.
Commit
46034dca515bc4ddca0399ae58106d1f5f0d809f (USB: musb_gadget_ep0: stop
abusing musb_gadget_set_halt()) forgot to restart a queued request after
clearing the endpoint halt feature. This results in a couple of USB resets
while enumerating the file-backed storage gadget due to CSW packet not being
sent for the MODE SENSE(10) command.
Signed-off-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Ming Lei [Mon, 20 Sep 2010 07:32:01 +0000 (10:32 +0300)]
usb: musb: gadget: fix kernel panic if using out ep with FIFO_TXRX style
commit
bd2e74d657fc7d514881cc2117e323790b257914 upstream.
For shared fifo hw endpoint(with FIFO_TXRX style), only ep_in
field of musb_hw_ep is intialized in musb_g_init_endpoints, and
ep_out is not initialized, but musb_g_rx and rxstate may access
ep_out field of musb_hw_ep by the method below:
musb_ep = &musb->endpoints[epnum].ep_out
which can cause the kernel panic[1] below, this patch fixes the issue
by getting 'musb_ep' from '&musb->endpoints[epnum].ep_in' for shared fifo
endpoint.
[1], kernel panic
[root@OMAP3EVM /]# musb_interrupt 1583: ** IRQ peripheral usb0008 tx0000 rx4000
musb_stage0_irq 460: <== Power=f0, DevCtl=99, int_usb=0x8
musb_g_rx 772: <== (null), rxcsr 4007
ffffffe8
musb_g_rx 786: iso overrun on
ffffffe8
Unable to handle kernel NULL pointer dereference at virtual address
00000008
pgd =
c0004000
[
00000008] *pgd=
00000000
Internal error: Oops: 17 [#1] PREEMPT
last sysfs file: /sys/devices/platform/musb_hdrc/usb1/usb_device/usbdev1.1/dev
Modules linked in: g_zero
CPU: 0 Tainted: G W (2.6.35-rc6-gkh-wl+ #92)
PC is at musb_g_rx+0xfc/0x2ec
LR is at vprintk+0x3f4/0x458
pc : [<
c02c07a4>] lr : [<
c006ccb0>] psr:
20000193
sp :
c760bd78 ip :
c03c9d70 fp :
c760bdbc
r10:
00000000 r9 :
fa0ab1e0 r8 :
0000000e
r7 :
c7e80158 r6 :
ffffffe8 r5 :
00000001 r4 :
00004003
r3 :
00010003 r2 :
c760bcd8 r1 :
c03cd030 r0 :
0000002e
Flags: nzCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment kernel
Control:
10c5387d Table:
8778c019 DAC:
00000017
Process kmemleak (pid: 421, stack limit = 0xc760a2e8)
Stack: (0xc760bd78 to 0xc760c000)
bd60:
ffffffe8 c04b1b58
bd80:
ffffffe8 c7c01ac0 00000000 c7e80d24 c0084238 00000001 00000001 c7e80158
bda0:
0000000e 00000008 00000099 000000f0 c760be04 c760bdc0 c02bcd68 c02c06b4
bdc0:
00000099 00000008 00004000 c760bdd8 c03cc4f8 00000000 00000002 c7e80158
bde0:
c7d2e300 60000193 c760a000 0000005c 00000000 00000000 c760be24 c760be08
be00:
c02bcecc c02bc1ac c7d2e300 c7d2e300 0000005c c760a000 c760be54 c760be28
be20:
c00ad698 c02bce6c 00000000 c7d2e300 c067c258 0000005c c067c294 00000001
be40:
c760a000 00000000 c760be74 c760be58 c00af984 c00ad5fc 0000005c 00000000
be60:
00000000 00000002 c760be8c c760be78 c0039080 c00af8d0 ffffffff fa200000
be80:
c760beec c760be90 c0039b6c c003900c 00000001 00000000 c7d1e240 00000000
bea0:
00000000 c068bae8 00000000 60000013 00000001 00000000 00000000 c760beec
bec0:
c0064ecc c760bed8 c00ff7d0 c003a0a8 60000013 ffffffff 00000000 c068bae8
bee0:
c760bf24 c760bef0 c00ff7d0 c0064ec4 00000001 00000000 c00ff700 00000000
bf00:
c0087f00 00000000 60000013 c0d76a70 c0e23795 00000001 c760bf4c c760bf28
bf20:
c00ffdd8 c00ff70c c068bb08 c068bae8 60000013 c0100938 c068bb30 00000000
bf40:
c760bf84 c760bf50 c010014c c00ffd84 00000001 00000000 c010000c 00012c00
bf60:
c7c33f04 00012c00 c7c33f04 00000000 c0100938 00000000 c760bf9c c760bf88
bf80:
c01009a8 c0100018 c760bfa8 c7c33f04 c760bff4 c760bfa0 c0088000 c0100944
bfa0:
c760bf98 00000000 00000000 00000001 dead4ead ffffffff ffffffff c08ba2bc
bfc0:
00000000 c049e7fa 00000000 c0087f70 c760bfd0 c760bfd0 c7c33f04 c0087f70
bfe0:
c006f5e8 00000013 00000000 c760bff8 c006f5e8 c0087f7c 7f0004ff df2000ff
Backtrace:
[<
c02c06a8>] (musb_g_rx+0x0/0x2ec) from [<
c02bcd68>] (musb_interrupt+0xbc8/0xcc0)
[<
c02bc1a0>] (musb_interrupt+0x0/0xcc0) from [<
c02bcecc>] (generic_interrupt+0x6c/0x84)
[<
c02bce60>] (generic_interrupt+0x0/0x84) from [<
c00ad698>] (handle_IRQ_event+0xa8/0x1ec)
r7:
c760a000 r6:
0000005c r5:
c7d2e300 r4:
c7d2e300
[<
c00ad5f0>] (handle_IRQ_event+0x0/0x1ec) from [<
c00af984>] (handle_level_irq+0xc0/0x13c)
[<
c00af8c4>] (handle_level_irq+0x0/0x13c) from [<
c0039080>] (asm_do_IRQ+0x80/0xa0)
r7:
00000002 r6:
00000000 r5:
00000000 r4:
0000005c
[<
c0039000>] (asm_do_IRQ+0x0/0xa0) from [<
c0039b6c>] (__irq_svc+0x4c/0xb4)
Exception stack(0xc760be90 to 0xc760bed8)
be80:
00000001 00000000 c7d1e240 00000000
bea0:
00000000 c068bae8 00000000 60000013 00000001 00000000 00000000 c760beec
bec0:
c0064ecc c760bed8 c00ff7d0 c003a0a8 60000013 ffffffff
r5:
fa200000 r4:
ffffffff
[<
c0064eb8>] (sub_preempt_count+0x0/0x100) from [<
c00ff7d0>] (find_and_get_object+0xd0/0x110)
r5:
c068bae8 r4:
00000000
[<
c00ff700>] (find_and_get_object+0x0/0x110) from [<
c00ffdd8>] (scan_block+0x60/0x104)
r8:
00000001 r7:
c0e23795 r6:
c0d76a70 r5:
60000013 r4:
00000000
[<
c00ffd78>] (scan_block+0x0/0x104) from [<
c010014c>] (kmemleak_scan+0x140/0x484)
[<
c010000c>] (kmemleak_scan+0x0/0x484) from [<
c01009a8>] (kmemleak_scan_thread+0x70/0xcc)
r8:
00000000 r7:
c0100938 r6:
00000000 r5:
c7c33f04 r4:
00012c00
[<
c0100938>] (kmemleak_scan_thread+0x0/0xcc) from [<
c0088000>] (kthread+0x90/0x98)
r5:
c7c33f04 r4:
c760bfa8
[<
c0087f70>] (kthread+0x0/0x98) from [<
c006f5e8>] (do_exit+0x0/0x684)
r7:
00000013 r6:
c006f5e8 r5:
c0087f70 r4:
c7c33f04
Code:
e3002312 e58d6000 e2833e16 eb0422d5 (
e5963020)
---[ end trace
f3d5e96f75c297b7 ]---
Signed-off-by: Ming Lei <tom.leiming@gmail.com>
Reviewed-by: Sergei Shtylyov <sshtylyov@mvista.com>
Cc: David Brownell <dbrownell@users.sourceforge.net>
Cc: Anand Gadiyar <gadiyar@ti.com>
Cc: Mike Frysinger <vapier@gentoo.org>
Cc: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Alan Stern [Tue, 21 Sep 2010 19:01:53 +0000 (15:01 -0400)]
USB: fix bug in initialization of interface minor numbers
commit
0026e00523a85b90a92a93ddf6660939ecef3e54 upstream.
Recent changes in the usbhid layer exposed a bug in usbcore. If
CONFIG_USB_DYNAMIC_MINORS is enabled then an interface may be assigned
a minor number of 0. However interfaces that aren't registered as USB
class devices also have their minor number set to 0, during
initialization. As a result usb_find_interface() may return the
wrong interface, leading to a crash.
This patch (as1418) fixes the problem by initializing every
interface's minor number to -1. It also cleans up the
usb_register_dev() function, which besides being somewhat awkwardly
written, does not unwind completely on all its error paths.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Tested-by: Philip J. Turmel <philip@turmel.org>
Tested-by: Gabriel Craciunescu <nix.or.die@googlemail.com>
Tested-by: Alex Riesen <raa.lkml@gmail.com>
Tested-by: Matthias Bayer <jackdachef@gmail.com>
CC: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Clemens Ladisch [Fri, 15 Oct 2010 10:06:18 +0000 (12:06 +0200)]
ALSA: rawmidi: fix oops (use after free) when unloading a driver module
commit
aa73aec6c385e2c797ac25cc7ccf0318031de7c8 upstream.
When a driver module is unloaded and the last still open file is a raw
MIDI device, the card and its devices will be actually freed in the
snd_card_file_remove() call when that file is closed. Afterwards, rmidi
and rmidi->card point into freed memory, so the module pointer is likely
to be garbage.
(This was introduced by commit
9a1b64caac82aa02cb74587ffc798e6f42c6170a.)
Signed-off-by: Clemens Ladisch <clemens@ladisch.de>
Reported-by: Krzysztof Foltman <wdev@foltman.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Dan Rosenberg [Tue, 28 Sep 2010 18:18:20 +0000 (14:18 -0400)]
ALSA: prevent heap corruption in snd_ctl_new()
commit
5591bf07225523600450edd9e6ad258bb877b779 upstream.
The snd_ctl_new() function in sound/core/control.c allocates space for a
snd_kcontrol struct by performing arithmetic operations on a
user-provided size without checking for integer overflow. If a user
provides a large enough size, an overflow will occur, the allocated
chunk will be too small, and a second user-influenced value will be
written repeatedly past the bounds of this chunk. This code is
reachable by unprivileged users who have permission to open
a /dev/snd/controlC* device (on many distros, this is group "audio") via
the SNDRV_CTL_IOCTL_ELEM_ADD and SNDRV_CTL_IOCTL_ELEM_REPLACE ioctls.
Signed-off-by: Dan Rosenberg <drosenberg@vsecurity.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Luke Yelavich [Tue, 21 Sep 2010 07:05:46 +0000 (17:05 +1000)]
ALSA: hda - Add Dell Latitude E6400 model quirk
commit
0f9f1ee9d1412d45a22bfd69dfd4d4324b506e9e upstream.
BugLink: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/643891
Set the Dell Latitude E6400 (1028:0233) SSID to use AD1984_DELL_DESKTOP
Signed-off-by: Luke Yelavich <luke.yelavich@canonical.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Erik J. Staab [Wed, 22 Sep 2010 09:07:41 +0000 (11:07 +0200)]
ALSA: oxygen: fix analog capture on Claro halo cards
commit
0873a5ae747847ee55a63db409dff3476e45bcd9 upstream.
On the HT-Omega Claro halo card, the ADC data must be captured from the
second I2S input. Using the default first input, which isn't connected
to anything, would result in silence.
Signed-off-by: Erik J. Staab <ejs@insightbb.com>
Signed-off-by: Clemens Ladisch <clemens@ladisch.de>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Dan Rosenberg [Sat, 25 Sep 2010 15:07:27 +0000 (11:07 -0400)]
ALSA: sound/pci/rme9652: prevent reading uninitialized stack memory
commit
e68d3b316ab7b02a074edc4f770e6a746390cb7d upstream.
The SNDRV_HDSP_IOCTL_GET_CONFIG_INFO and
SNDRV_HDSP_IOCTL_GET_CONFIG_INFO ioctls in hdspm.c and hdsp.c allow
unprivileged users to read uninitialized kernel stack memory, because
several fields of the hdsp{m}_config_info structs declared on the stack
are not altered or zeroed before being copied back to the user. This
patch takes care of it.
Signed-off-by: Dan Rosenberg <dan.j.rosenberg@gmail.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
H. Peter Anvin [Tue, 28 Sep 2010 22:35:01 +0000 (15:35 -0700)]
x86, cpu: After uncapping CPUID, re-run CPU feature detection
commit
d900329e20f4476db6461752accebcf7935a8055 upstream.
After uncapping the CPUID level, we need to also re-run the CPU
feature detection code.
This resolves kernel bugzilla 16322.
Reported-by: boris64 <bugzilla.kernel.org@boris64.net>
LKML-Reference: <tip-@git.kernel.org>
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Greg Kroah-Hartman [Fri, 1 Oct 2010 20:51:56 +0000 (13:51 -0700)]
Linux 2.6.32.24
James Dingwall [Mon, 27 Sep 2010 08:37:17 +0000 (09:37 +0100)]
Xen: fix typo in previous patch
Correctly name the irq_chip structure to fix an immediate failure when booting
as a xen pv_ops guest with a NULL pointer exception. The missing 'x' was
introduced in commit [
fb412a178502dc498430723b082a932f797e4763] applied to
2.6.3[25]-stable trees. The commit to mainline was
[
aaca49642b92c8a57d3ca5029a5a94019c7af69f] which did not have the problem.
Signed-off-by: James Dingwall <james@dingwall.me.uk>
Reported-by: Pawel Zuzelski <pawelz@pld-linux.org>
Tested-by: Pawel Zuzelski <pawelz@pld-linux.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Greg Kroah-Hartman [Mon, 27 Sep 2010 00:22:13 +0000 (17:22 -0700)]
Linux 2.6.32.23
H. Peter Anvin [Wed, 28 Jul 2010 00:01:49 +0000 (17:01 -0700)]
x86: Add memory modify constraints to xchg() and cmpxchg()
commit
113fc5a6e8c2288619ff7e8187a6f556b7e0d372 upstream.
[ Backport to .32 by Tomáš Janoušek <tomi@nomi.cz> ]
xchg() and cmpxchg() modify their memory operands, not merely read
them. For some versions of gcc the "memory" clobber has apparently
dealt with the situation, but not for all.
Originally-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Cc: Glauber Costa <glommer@redhat.com>
Cc: Avi Kivity <avi@redhat.com>
Cc: Peter Palfrader <peter@palfrader.org>
Cc: Greg KH <gregkh@suse.de>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: Zachary Amsden <zamsden@redhat.com>
Cc: Marcelo Tosatti <mtosatti@redhat.com>
LKML-Reference: <
4C4F7277.
8050306@zytor.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Michael Cree [Wed, 1 Sep 2010 15:25:17 +0000 (11:25 -0400)]
alpha: Fix printk format errors
commit
3e073367a57d41e506f20aebb98e308387ce3090 upstream.
When compiling alpha generic build get errors such as:
arch/alpha/kernel/err_marvel.c: In function ‘marvel_print_err_cyc’:
arch/alpha/kernel/err_marvel.c:119: error: format ‘%ld’ expects type ‘long int’, but argument 6 has type ‘u64’
Replaced a number of %ld format specifiers with %lld since u64
is unsigned long long.
Signed-off-by: Michael Cree <mcree@orcon.net.nz>
Signed-off-by: Matt Turner <mattst88@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Ben Hutchings [Wed, 24 Mar 2010 03:33:48 +0000 (03:33 +0000)]
sis-agp: Remove SIS 760, handled by amd64-agp
commit
d831692a1a8e9ceaaa9bb16bb3fc503b7e372558 upstream.
SIS 760 is listed in the device tables for both amd64-agp and sis-agp.
amd64-agp is apparently preferable since it has workarounds for some
BIOS misconfigurations that sis-agp doesn't handle.
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Ralf Baechle [Tue, 23 Mar 2010 16:56:38 +0000 (17:56 +0100)]
MIPS: Sibyte: Fix M3 TLB exception handler workaround.
commit
3d45285dd1ff4d4a1361b95e2d6508579a4402b5 upstream.
The M3 workaround needs to cmpare the region and VPN2 fields only.
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Bartlomiej Zolnierkiewicz [Sat, 13 Feb 2010 22:43:17 +0000 (17:43 -0500)]
pata_pdc202xx_old: fix UDMA mode for PDC2026x chipsets
commit
750e519da7b3f470fe1b5b55c8d8f52d6d6371e4 upstream.
PDC2026x chipsets need the same treatment as PDC20246 one.
This is completely untested but will hopefully fix UDMA issues
that people have been reporting against pata_pdc202xx_old for
the last couple of years.
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Bartlomiej Zolnierkiewicz [Sat, 13 Feb 2010 13:35:53 +0000 (14:35 +0100)]
pata_pdc202xx_old: fix UDMA mode for Promise UDMA33 cards
commit
a75032e8772d13dab5e3501413d7e14a148281b4 upstream.
On Monday 04 January 2010 02:30:24 pm Russell King wrote:
> Found the problem - getting rid of the read of the alt status register
> after the command has been written fixes the UDMA CRC errors on write:
>
> @@ -676,7 +676,8 @@ void ata_sff_exec_command(struct ata_port *ap, const struct
> ata_taskfile *tf)
> DPRINTK("ata%u: cmd 0x%X\n", ap->print_id, tf->command);
>
> iowrite8(tf->command, ap->ioaddr.command_addr);
> - ata_sff_pause(ap);
> + ndelay(400);
> +// ata_sff_pause(ap);
> }
> EXPORT_SYMBOL_GPL(ata_sff_exec_command);
>
>
> This rather makes sense. The PDC20247 handles the UDMA part of the
> protocol. It has no way to tell the PDC20246 to wait while it suspends
> UDMA, so that a normal register access can take place - the 246 ploughs
> on with the register access without any regard to the state of the 247.
>
> If the drive immediately starts the UDMA protocol after a write to the
> command register (as it probably will for the DMA WRITE command), then
> we'll be accessing the taskfile in the middle of the UDMA setup, which
> can't be good. It's certainly a violation of the ATA specs.
Fix it by adding custom ->sff_exec_command method for UDMA33 chipsets.
Debugged-by: Russell King <rmk@arm.linux.org.uk>
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Ralf Baechle [Tue, 23 Mar 2010 14:54:50 +0000 (15:54 +0100)]
MIPS: uasm: Add OR instruction.
commit
5808184f1b2fe06ef8a54a2b7fb1596d58098acf upstream.
This is needed for the fix of the M3 workaround.
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
[Backported by Aurelien Jarno <aurelien@aurel32.net>]
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Ben Hutchings [Sun, 13 Jun 2010 21:22:59 +0000 (22:22 +0100)]
MIPS: Set io_map_base for several PCI bridges lacking it
commit
8faf2e6c201d95b780cd3b4674b7a55ede6dcbbb upstream.
Several MIPS platforms don't set pci_controller::io_map_base for their
PCI bridges. This results in a panic in pci_iomap(). (The panic is
conditional on CONFIG_PCI_DOMAINS, but that is now enabled for all PCI
MIPS systems.)
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Cc: linux-mips@linux-mips.org
Cc: Martin Michlmayr <tbm@cyrius.com>
Cc: Aurelien Jarno <aurelien@aurel32.net>
Cc: 584784@bugs.debian.org
Patchwork: https://patchwork.linux-mips.org/patch/1377/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
David Daney [Thu, 22 Jul 2010 18:59:27 +0000 (11:59 -0700)]
MIPS: Quit using undefined behavior of ADDU in 64-bit atomic operations.
commit
f2a68272d799bf4092443357142f63b74f7669a1 upstream.
For 64-bit, we must use DADDU and DSUBU.
Signed-off-by: David Daney <ddaney@caviumnetworks.com>
To: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/1483/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Dmitry Torokhov [Mon, 11 Jan 2010 08:05:43 +0000 (00:05 -0800)]
Input: add compat support for sysfs and /proc capabilities output
commit
15e184afa83a45cf8bafdb9dc906b97a8fbc974f upstream.
Input core displays capabilities bitmasks in form of one or more longs printed
in hex form and separated by spaces. Unfortunately it does not work well
for 32-bit applications running on 64-bit kernels since applications expect
that number is "worth" only 32 bits when kernel advances by 64 bits.
Fix that by ensuring that output produced for compat tasks uses 32-bit units.
Reported-and-tested-by: Michael Tokarev <mjt@tls.msk.ru>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Eric Paris [Wed, 28 Jul 2010 14:18:37 +0000 (10:18 -0400)]
inotify: fix inotify oneshot support
commit
ff311008ab8d2f2cfdbbefd407d1b05acc8164b2 upstream.
During the large inotify rewrite to fsnotify I completely dropped support
for IN_ONESHOT. Reimplement that support.
Signed-off-by: Eric Paris <eparis@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
John W. Linville [Tue, 13 Jul 2010 18:06:32 +0000 (14:06 -0400)]
hostap_pci: set dev->base_addr during probe
commit
0f4da2d77e1bf424ac36424081afc22cbfc3ff2b upstream.
"hostap: Protect against initialization interrupt" (which reinstated
"wireless: hostap, fix oops due to early probing interrupt")
reintroduced Bug 16111. This is because hostap_pci wasn't setting
dev->base_addr, which is now checked in prism2_interrupt. As a result,
initialization was failing for PCI-based hostap devices. This corrects
that oversight.
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Herbert Xu [Fri, 21 May 2010 06:07:56 +0000 (23:07 -0700)]
gro: Fix bogus gso_size on the first fraglist entry
commit
622e0ca1cd4d459f5af4f2c65f4dc0dd823cb4c3 upstream.
When GRO produces fraglist entries, and the resulting skb hits
an interface that is incapable of TSO but capable of FRAGLIST,
we end up producing a bogus packet with gso_size non-zero.
This was reported in the field with older versions of KVM that
did not set the TSO bits on tuntap.
This patch fixes that.
Reported-by: Igor Zhang <yugzhang@redhat.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Aurelien Jarno [Mon, 31 May 2010 21:45:48 +0000 (21:45 +0000)]
clocksource: sh_tmu: compute mult and shift before registration
commit
66f49121ffa41a19c59965b31b046d8368fec3c7 upstream.
Since commit
98962465ed9e6ea99c38e0af63fe1dcb5a79dc25 ("nohz: Prevent
clocksource wrapping during idle"), the CPU of an R2D board never goes
to idle. This commit assumes that mult and shift are assigned before
the clocksource is registered. As a consequence the safe maximum sleep
time is negative and the CPU never goes into idle.
This patch fixes the problem by moving mult and shift initialization
from sh_tmu_clocksource_enable() to sh_tmu_register_clocksource().
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
Signed-off-by: Paul Mundt <lethal@linux-sh.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Peter Oberparleiter [Mon, 19 Jul 2010 07:22:35 +0000 (09:22 +0200)]
dasd: use correct label location for diag fba disks
commit
cffab6bc5511cd6f67a60bf16b62de4267b68c4c upstream.
Partition boundary calculation fails for DASD FBA disks under the
following conditions:
- disk is formatted with CMS FORMAT with a blocksize of more than
512 bytes
- all of the disk is reserved to a single CMS file using CMS RESERVE
- the disk is accessed using the DIAG mode of the DASD driver
Under these circumstances, the partition detection code tries to
read the CMS label block containing partition-relevant information
from logical block offset 1, while it is in fact located at physical
block offset 1.
Fix this problem by using the correct CMS label block location
depending on the device type as determined by the DASD SENSE ID
information.
Signed-off-by: Peter Oberparleiter <peter.oberparleiter@de.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
[bwh: Adjust for 2.6.32]
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Jussi Kivilinna [Tue, 9 Mar 2010 12:24:38 +0000 (12:24 +0000)]
asix: fix setting mac address for AX88772
commit
7f29a3baa825725d29db399663790d15c78cddcf upstream.
Setting new MAC address only worked when device was set to promiscuous mode.
Fix MAC address by writing new address to device using undocumented command
AX_CMD_READ_NODE_ID+1. Patch is tested with AX88772 device.
Signed-off-by: Jussi Kivilinna <jussi.kivilinna@mbnet.fi>
Acked-by: David Hollis <dhollis@davehollis.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Ben Hutchings [Thu, 8 Apr 2010 03:55:47 +0000 (20:55 -0700)]
3c503: Fix IRQ probing
commit
b0cf4dfb7cd21556efd9a6a67edcba0840b4d98d upstream.
The driver attempts to select an IRQ for the NIC automatically by
testing which of the supported IRQs are available and then probing
each available IRQ with probe_irq_{on,off}(). There are obvious race
conditions here, besides which:
1. The test for availability is done by passing a NULL handler, which
now always returns -EINVAL, thus the device cannot be opened:
<http://bugs.debian.org/566522>
2. probe_irq_off() will report only the first ISA IRQ handled,
potentially leading to a false negative.
There was another bug that meant it ignored all error codes from
request_irq() except -EBUSY, so it would 'succeed' despite this
(possibly causing conflicts with other ISA devices). This was fixed
by
ab08999d6029bb2c79c16be5405d63d2bedbdfea 'WARNING: some
request_irq() failures ignored in el2_open()', which exposed bug 1.
This patch:
1. Replaces the use of probe_irq_{on,off}() with a real interrupt handler
2. Adds a delay before checking the interrupt-seen flag
3. Disables interrupts on all failure paths
4. Distinguishes error codes from the second request_irq() call,
consistently with the first
Compile-tested only.
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Vlad Yasevich [Wed, 15 Sep 2010 14:00:26 +0000 (10:00 -0400)]
sctp: Do not reset the packet during sctp_packet_config().
commit
4bdab43323b459900578b200a4b8cf9713ac8fab upstream.
sctp_packet_config() is called when getting the packet ready
for appending of chunks. The function should not touch the
current state, since it's possible to ping-pong between two
transports when sending, and that can result packet corruption
followed by skb overlfow crash.
Reported-by: Thomas Dreibholz <dreibh@iem.uni-due.de>
Signed-off-by: Vlad Yasevich <vladislav.yasevich@hp.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Daniel J Blueman [Tue, 17 Aug 2010 22:56:55 +0000 (23:56 +0100)]
Fix unprotected access to task credentials in waitid()
commit
f362b73244fb16ea4ae127ced1467dd8adaa7733 upstream.
Using a program like the following:
#include <stdlib.h>
#include <unistd.h>
#include <sys/types.h>
#include <sys/wait.h>
int main() {
id_t id;
siginfo_t infop;
pid_t res;
id = fork();
if (id == 0) { sleep(1); exit(0); }
kill(id, SIGSTOP);
alarm(1);
waitid(P_PID, id, &infop, WCONTINUED);
return 0;
}
to call waitid() on a stopped process results in access to the child task's
credentials without the RCU read lock being held - which may be replaced in the
meantime - eliciting the following warning:
===================================================
[ INFO: suspicious rcu_dereference_check() usage. ]
---------------------------------------------------
kernel/exit.c:1460 invoked rcu_dereference_check() without protection!
other info that might help us debug this:
rcu_scheduler_active = 1, debug_locks = 1
2 locks held by waitid02/22252:
#0: (tasklist_lock){.?.?..}, at: [<
ffffffff81061ce5>] do_wait+0xc5/0x310
#1: (&(&sighand->siglock)->rlock){-.-...}, at: [<
ffffffff810611da>]
wait_consider_task+0x19a/0xbe0
stack backtrace:
Pid: 22252, comm: waitid02 Not tainted 2.6.35-323cd+ #3
Call Trace:
[<
ffffffff81095da4>] lockdep_rcu_dereference+0xa4/0xc0
[<
ffffffff81061b31>] wait_consider_task+0xaf1/0xbe0
[<
ffffffff81061d15>] do_wait+0xf5/0x310
[<
ffffffff810620b6>] sys_waitid+0x86/0x1f0
[<
ffffffff8105fce0>] ? child_wait_callback+0x0/0x70
[<
ffffffff81003282>] system_call_fastpath+0x16/0x1b
This is fixed by holding the RCU read lock in wait_task_continued() to ensure
that the task's current credentials aren't destroyed between us reading the
cred pointer and us reading the UID from those credentials.
Furthermore, protect wait_task_stopped() in the same way.
We don't need to keep holding the RCU read lock once we've read the UID from
the credentials as holding the RCU read lock doesn't stop the target task from
changing its creds under us - so the credentials may be outdated immediately
after we've read the pointer, lock or no lock.
Signed-off-by: Daniel J Blueman <daniel.blueman@gmail.com>
Signed-off-by: David Howells <dhowells@redhat.com>
Acked-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Acked-by: Oleg Nesterov <oleg@redhat.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Luck, Tony [Tue, 24 Aug 2010 18:44:18 +0000 (11:44 -0700)]
guard page for stacks that grow upwards
commit
8ca3eb08097f6839b2206e2242db4179aee3cfb3 upstream.
pa-risc and ia64 have stacks that grow upwards. Check that
they do not run into other mappings. By making VM_GROWSUP
0x0 on architectures that do not ever use it, we can avoid
some unpleasant #ifdefs in check_stack_guard_page().
Signed-off-by: Tony Luck <tony.luck@intel.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Cc: dann frazier <dannf@debian.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Mel Gorman [Thu, 9 Sep 2010 23:38:16 +0000 (16:38 -0700)]
mm: page allocator: update free page counters after pages are placed on the free list
commit
72853e2991a2702ae93aaf889ac7db743a415dd3 upstream.
When allocating a page, the system uses NR_FREE_PAGES counters to
determine if watermarks would remain intact after the allocation was made.
This check is made without interrupts disabled or the zone lock held and
so is race-prone by nature. Unfortunately, when pages are being freed in
batch, the counters are updated before the pages are added on the list.
During this window, the counters are misleading as the pages do not exist
yet. When under significant pressure on systems with large numbers of
CPUs, it's possible for processes to make progress even though they should
have been stalled. This is particularly problematic if a number of the
processes are using GFP_ATOMIC as the min watermark can be accidentally
breached and in extreme cases, the system can livelock.
This patch updates the counters after the pages have been added to the
list. This makes the allocator more cautious with respect to preserving
the watermarks and mitigates livelock possibilities.
[akpm@linux-foundation.org: avoid modifying incoming args]
Signed-off-by: Mel Gorman <mel@csn.ul.ie>
Reviewed-by: Rik van Riel <riel@redhat.com>
Reviewed-by: Minchan Kim <minchan.kim@gmail.com>
Reviewed-by: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Reviewed-by: Christoph Lameter <cl@linux.com>
Reviewed-by: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
Acked-by: Johannes Weiner <hannes@cmpxchg.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Christoph Lameter [Thu, 9 Sep 2010 23:38:17 +0000 (16:38 -0700)]
mm: page allocator: calculate a better estimate of NR_FREE_PAGES when memory is low and kswapd is awake
commit
aa45484031ddee09b06350ab8528bfe5b2c76d1c upstream.
Ordinarily watermark checks are based on the vmstat NR_FREE_PAGES as it is
cheaper than scanning a number of lists. To avoid synchronization
overhead, counter deltas are maintained on a per-cpu basis and drained
both periodically and when the delta is above a threshold. On large CPU
systems, the difference between the estimated and real value of
NR_FREE_PAGES can be very high. If NR_FREE_PAGES is much higher than
number of real free page in buddy, the VM can allocate pages below min
watermark, at worst reducing the real number of pages to zero. Even if
the OOM killer kills some victim for freeing memory, it may not free
memory if the exit path requires a new page resulting in livelock.
This patch introduces a zone_page_state_snapshot() function (courtesy of
Christoph) that takes a slightly more accurate view of an arbitrary vmstat
counter. It is used to read NR_FREE_PAGES while kswapd is awake to avoid
the watermark being accidentally broken. The estimate is not perfect and
may result in cache line bounces but is expected to be lighter than the
IPI calls necessary to continually drain the per-cpu counters while kswapd
is awake.
Signed-off-by: Christoph Lameter <cl@linux.com>
Signed-off-by: Mel Gorman <mel@csn.ul.ie>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Mel Gorman [Thu, 9 Sep 2010 23:38:18 +0000 (16:38 -0700)]
mm: page allocator: drain per-cpu lists after direct reclaim allocation fails
commit
9ee493ce0a60bf42c0f8fd0b0fe91df5704a1cbf upstream.
When under significant memory pressure, a process enters direct reclaim
and immediately afterwards tries to allocate a page. If it fails and no
further progress is made, it's possible the system will go OOM. However,
on systems with large amounts of memory, it's possible that a significant
number of pages are on per-cpu lists and inaccessible to the calling
process. This leads to a process entering direct reclaim more often than
it should increasing the pressure on the system and compounding the
problem.
This patch notes that if direct reclaim is making progress but allocations
are still failing that the system is already under heavy pressure. In
this case, it drains the per-cpu lists and tries the allocation a second
time before continuing.
Signed-off-by: Mel Gorman <mel@csn.ul.ie>
Reviewed-by: Minchan Kim <minchan.kim@gmail.com>
Reviewed-by: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Reviewed-by: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
Reviewed-by: Christoph Lameter <cl@linux.com>
Cc: Dave Chinner <david@fromorbit.com>
Cc: Wu Fengguang <fengguang.wu@intel.com>
Cc: David Rientjes <rientjes@google.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Divy Le Ray [Wed, 3 Mar 2010 09:49:47 +0000 (09:49 +0000)]
cxgb3: fix hot plug removal crash
commit
a6f018e324ba91d0464cca6895447c2b89e6d578 upstream.
queue restart tasklets need to be stopped after napi handlers are stopped
since the latter can restart them. So stop them after stopping napi.
Signed-off-by: Divy Le Ray <divy@chelsio.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Brandon Philips <bphilips@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Nicolas Ferre [Fri, 20 Aug 2010 14:44:33 +0000 (16:44 +0200)]
AT91: change dma resource index
commit
8d2602e0778299e2d6084f03086b716d6e7a1e1e upstream.
Reported-by: Dan Liang <dan.liang@atmel.com>
Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Michael Chan [Tue, 1 Jun 2010 15:05:36 +0000 (15:05 +0000)]
bnx2: Fix hang during rmmod bnx2.
commit
f048fa9c8686119c3858a463cab6121dced7c0bf upstream.
The regression is caused by:
commit
4327ba435a56ada13eedf3eb332e583c7a0586a9
bnx2: Fix netpoll crash.
If ->open() and ->close() are called multiple times, the same napi structs
will be added to dev->napi_list multiple times, corrupting the dev->napi_list.
This causes free_netdev() to hang during rmmod.
We fix this by calling netif_napi_del() during ->close().
Also, bnx2_init_napi() must not be in the __devinit section since it is
called by ->open().
Signed-off-by: Michael Chan <mchan@broadcom.com>
Signed-off-by: Benjamin Li <benli@broadcom.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Benjamin Li [Tue, 23 Mar 2010 13:13:11 +0000 (13:13 +0000)]
bnx2: Fix netpoll crash.
commit
4327ba435a56ada13eedf3eb332e583c7a0586a9 upstream.
The bnx2 driver calls netif_napi_add() for all the NAPI structs during
->probe() time but not all of them will be used if we're not in MSI-X
mode. This creates a problem for netpoll since it will poll all the
NAPI structs in the dev_list whether or not they are scheduled, resulting
in a crash when we access structure fields not initialized for that vector.
We fix it by moving the netif_napi_add() call to ->open() after the number
of IRQ vectors has been determined.
Signed-off-by: Benjamin Li <benli@broadcom.com>
Signed-off-by: Michael Chan <mchan@broadcom.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Zhang Rui [Mon, 21 Dec 2009 08:13:15 +0000 (16:13 +0800)]
ACPI: disable _OSI(Windows 2009) on Asus K50IJ
commit
81074e90f5c150ca70ab8dfcc77860cbe76f364d upstream.
Fix a win7 compability issue on Asus K50IJ.
Here is the _BCM method of this laptop:
Method (_BCM, 1, NotSerialized)
{
If (LGreaterEqual (OSFG, OSVT))
{
If (LNotEqual (OSFG, OSW7))
{
Store (One, BCMD)
Store (GCBL (Arg0), Local0)
Subtract (0x0F, Local0, LBTN)
^^^SBRG.EC0.STBR ()
...
}
Else
{
DBGR (0x0B, Zero, Zero, Arg0)
Store (Arg0, LBTN)
^^^SBRG.EC0.STBR ()
...
}
}
}
LBTN is used to store the index of the brightness level in the _BCL.
GCBL is a method that convert the percentage value to the index value.
If _OSI(Windows 2009) is not disabled, LBTN is stored a percentage
value which is surely beyond the end of _BCL package.
http://bugzilla.kernel.org/show_bug.cgi?id=14753
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Cc: maximilian attems <max@stro.at>
Cc: Paolo Ornati <ornati@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Dan Rosenberg [Wed, 15 Sep 2010 23:08:24 +0000 (19:08 -0400)]
drivers/video/via/ioctl.c: prevent reading uninitialized stack memory
commit
b4aaa78f4c2f9cde2f335b14f4ca30b01f9651ca upstream.
The VIAFB_GET_INFO device ioctl allows unprivileged users to read 246
bytes of uninitialized stack memory, because the "reserved" member of
the viafb_ioctl_info struct declared on the stack is not altered or
zeroed before being copied back to the user. This patch takes care of
it.
Signed-off-by: Dan Rosenberg <dan.j.rosenberg@gmail.com>
Signed-off-by: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Dan Rosenberg [Mon, 6 Sep 2010 22:24:57 +0000 (18:24 -0400)]
xfs: prevent reading uninitialized stack memory
commit
a122eb2fdfd78b58c6dd992d6f4b1aaef667eef9 upstream.
The XFS_IOC_FSGETXATTR ioctl allows unprivileged users to read 12
bytes of uninitialized stack memory, because the fsxattr struct
declared on the stack in xfs_ioc_fsgetxattr() does not alter (or zero)
the 12-byte fsx_pad member before copying it back to the user. This
patch takes care of it.
Signed-off-by: Dan Rosenberg <dan.j.rosenberg@gmail.com>
Reviewed-by: Eric Sandeen <sandeen@redhat.com>
Signed-off-by: Alex Elder <aelder@sgi.com>
Cc: dann frazier <dannf@debian.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
David Howells [Fri, 10 Sep 2010 08:59:51 +0000 (09:59 +0100)]
KEYS: Fix bug in keyctl_session_to_parent() if parent has no session keyring
commit
3d96406c7da1ed5811ea52a3b0905f4f0e295376 upstream.
Fix a bug in keyctl_session_to_parent() whereby it tries to check the ownership
of the parent process's session keyring whether or not the parent has a session
keyring [CVE-2010-2960].
This results in the following oops:
BUG: unable to handle kernel NULL pointer dereference at
00000000000000a0
IP: [<
ffffffff811ae4dd>] keyctl_session_to_parent+0x251/0x443
...
Call Trace:
[<
ffffffff811ae2f3>] ? keyctl_session_to_parent+0x67/0x443
[<
ffffffff8109d286>] ? __do_fault+0x24b/0x3d0
[<
ffffffff811af98c>] sys_keyctl+0xb4/0xb8
[<
ffffffff81001eab>] system_call_fastpath+0x16/0x1b
if the parent process has no session keyring.
If the system is using pam_keyinit then it mostly protected against this as all
processes derived from a login will have inherited the session keyring created
by pam_keyinit during the log in procedure.
To test this, pam_keyinit calls need to be commented out in /etc/pam.d/.
Reported-by: Tavis Ormandy <taviso@cmpxchg8b.com>
Signed-off-by: David Howells <dhowells@redhat.com>
Acked-by: Tavis Ormandy <taviso@cmpxchg8b.com>
Cc: dann frazier <dannf@debian.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
David Howells [Fri, 10 Sep 2010 08:59:46 +0000 (09:59 +0100)]
KEYS: Fix RCU no-lock warning in keyctl_session_to_parent()
commit
9d1ac65a9698513d00e5608d93fca0c53f536c14 upstream.
There's an protected access to the parent process's credentials in the middle
of keyctl_session_to_parent(). This results in the following RCU warning:
===================================================
[ INFO: suspicious rcu_dereference_check() usage. ]
---------------------------------------------------
security/keys/keyctl.c:1291 invoked rcu_dereference_check() without protection!
other info that might help us debug this:
rcu_scheduler_active = 1, debug_locks = 0
1 lock held by keyctl-session-/2137:
#0: (tasklist_lock){.+.+..}, at: [<
ffffffff811ae2ec>] keyctl_session_to_parent+0x60/0x236
stack backtrace:
Pid: 2137, comm: keyctl-session- Not tainted 2.6.36-rc2-cachefs+ #1
Call Trace:
[<
ffffffff8105606a>] lockdep_rcu_dereference+0xaa/0xb3
[<
ffffffff811ae379>] keyctl_session_to_parent+0xed/0x236
[<
ffffffff811af77e>] sys_keyctl+0xb4/0xb6
[<
ffffffff81001eab>] system_call_fastpath+0x16/0x1b
The code should take the RCU read lock to make sure the parents credentials
don't go away, even though it's holding a spinlock and has IRQ disabled.
Signed-off-by: David Howells <dhowells@redhat.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Cc: dann frazier <dannf@debian.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Petr Tesarik [Wed, 15 Sep 2010 22:35:48 +0000 (15:35 -0700)]
IA64: Optimize ticket spinlocks in fsys_rt_sigprocmask
commit
2d2b6901649a62977452be85df53eda2412def24 upstream.
Tony's fix (
f574c843191728d9407b766a027f779dcd27b272) has a small bug,
it incorrectly uses "r3" as a scratch register in the first of the two
unlock paths ... it is also inefficient. Optimize the fast path again.
Signed-off-by: Petr Tesarik <ptesarik@suse.cz>
Signed-off-by: Tony Luck <tony.luck@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Tony Luck [Thu, 9 Sep 2010 22:16:56 +0000 (15:16 -0700)]
IA64: fix siglock
commit
f574c843191728d9407b766a027f779dcd27b272 upstream.
When ia64 converted to using ticket locks, an inline implementation
of trylock/unlock in fsys.S was missed. This was not noticed because
in most circumstances it simply resulted in using the slow path because
the siglock was apparently not available (under old spinlock rules).
Problems occur when the ticket spinlock has value 0x0 (when first
initialised, or when it wraps around). At this point the fsys.S
code acquires the lock (changing the 0x0 to 0x1. If another process
attempts to get the lock at this point, it will change the value from
0x1 to 0x2 (using new ticket lock rules). Then the fsys.S code will
free the lock using old spinlock rules by writing 0x0 to it. From
here a variety of bad things can happen.
Signed-off-by: Tony Luck <tony.luck@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Dmitry Monakhov [Sat, 5 Jun 2010 15:51:27 +0000 (11:51 -0400)]
ext4: Fix remaining racy updates of EXT4_I(inode)->i_flags
commit
84a8dce2710cc425089a2b92acc354d4fbb5788d upstream.
A few functions were still modifying i_flags in a racy manner.
Signed-off-by: Dmitry Monakhov <dmonakhov@openvz.org>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Ryan Kuester [Mon, 26 Apr 2010 23:11:54 +0000 (18:11 -0500)]
SCSI: mptsas: fix hangs caused by ATA pass-through
commit
2a1b7e575b80ceb19ea50bfa86ce0053ea57181d upstream.
I may have an explanation for the LSI 1068 HBA hangs provoked by ATA
pass-through commands, in particular by smartctl.
First, my version of the symptoms. On an LSI SAS1068E B3 HBA running
01.29.00.00 firmware, with SATA disks, and with smartd running, I'm seeing
occasional task, bus, and host resets, some of which lead to hard faults of
the HBA requiring a reboot. Abusively looping the smartctl command,
# while true; do smartctl -a /dev/sdb > /dev/null; done
dramatically increases the frequency of these failures to nearly one per
minute. A high IO load through the HBA while looping smartctl seems to
improve the chance of a full scsi host reset or a non-recoverable hang.
I reduced what smartctl was doing down to a simple test case which
causes the hang with a single IO when pointed at the sd interface. See
the code at the bottom of this e-mail. It uses an SG_IO ioctl to issue
a single pass-through ATA identify device command. If the buffer
userspace gives for the read data has certain alignments, the task is
issued to the HBA but the HBA fails to respond. If run against the sg
interface, neither the test code nor smartctl causes a hang.
sd and sg handle the SG_IO ioctl slightly differently. Unless you
specifically set a flag to do direct IO, sg passes a buffer of its own,
which is page-aligned, to the block layer and later copies the result
into the userspace buffer regardless of its alignment. sd, on the other
hand, always does direct IO unless the userspace buffer fails an
alignment test at block/blk-map.c line 57, in which case a page-aligned
buffer is created and used for the transfer.
The alignment test currently checks for word-alignment, the default
setup by scsi_lib.c; therefore, userspace buffers of almost any
alignment are given directly to the HBA as DMA targets. The LSI 1068
hardware doesn't seem to like at least a couple of the alignments which
cross a page boundary (see the test code below). Curiously, many
page-boundary-crossing alignments do work just fine.
So, either the hardware has an bug handling certain alignments or the
hardware has a stricter alignment requirement than the driver is
advertising. If stricter alignment is required, then in no case should
misaligned buffers from userspace be allowed through without being
bounced or at least causing an error to be returned.
It seems the mptsas driver could use blk_queue_dma_alignment() to advertise
a stricter alignment requirement. If it does, sd does the right thing and
bounces misaligned buffers (see block/blk-map.c line 57). The following
patch to 2.6.34-rc5 makes my symptoms go away. I'm sure this is the wrong
place for this code, but it gets my idea across.
Acked-by: Kashyap Desai <Kashyap.Desai@lsi.com>
Signed-off-by: James Bottomley <James.Bottomley@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Eric Paris [Wed, 28 Jul 2010 14:18:37 +0000 (10:18 -0400)]
inotify: send IN_UNMOUNT events
commit
611da04f7a31b2208e838be55a42c7a1310ae321 upstream.
Since the .31 or so notify rewrite inotify has not sent events about
inodes which are unmounted. This patch restores those events.
Signed-off-by: Eric Paris <eparis@redhat.com>
Cc: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Jeff Moyer [Fri, 10 Sep 2010 21:16:00 +0000 (14:16 -0700)]
aio: check for multiplication overflow in do_io_submit
commit
75e1c70fc31490ef8a373ea2a4bea2524099b478 upstream.
Tavis Ormandy pointed out that do_io_submit does not do proper bounds
checking on the passed-in iocb array:
if (unlikely(nr < 0))
return -EINVAL;
if (unlikely(!access_ok(VERIFY_READ, iocbpp, (nr*sizeof(iocbpp)))))
return -EFAULT; ^^^^^^^^^^^^^^^^^^
The attached patch checks for overflow, and if it is detected, the
number of iocbs submitted is scaled down to a number that will fit in
the long. This is an ok thing to do, as sys_io_submit is documented as
returning the number of iocbs submitted, so callers should handle a
return value of less than the 'nr' argument passed in.
Reported-by: Tavis Ormandy <taviso@cmpxchg8b.com>
Signed-off-by: Jeff Moyer <jmoyer@redhat.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Tejun Heo [Tue, 21 Sep 2010 05:57:19 +0000 (07:57 +0200)]
percpu: fix pcpu_last_unit_cpu
commit
46b30ea9bc3698bc1d1e6fd726c9601d46fa0a91 upstream.
pcpu_first/last_unit_cpu are used to track which cpu has the first and
last units assigned. This in turn is used to determine the span of a
chunk for man/unmap cache flushes and whether an address belongs to
the first chunk or not in per_cpu_ptr_to_phys().
When the number of possible CPUs isn't power of two, a chunk may
contain unassigned units towards the end of a chunk. The logic to
determine pcpu_last_unit_cpu was incorrect when there was an unused
unit at the end of a chunk. It failed to ignore the unused unit and
assigned the unused marker NR_CPUS to pcpu_last_unit_cpu.
This was discovered through kdump failure which was caused by
malfunctioning per_cpu_ptr_to_phys() on a kvm setup with 50 possible
CPUs by CAI Qian.
Signed-off-by: Tejun Heo <tj@kernel.org>
Reported-by: CAI Qian <caiqian@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Dan Rosenberg [Wed, 22 Sep 2010 20:05:09 +0000 (13:05 -0700)]
drivers/video/sis/sis_main.c: prevent reading uninitialized stack memory
commit
fd02db9de73faebc51240619c7c7f99bee9f65c7 upstream.
The FBIOGET_VBLANK device ioctl allows unprivileged users to read 16 bytes
of uninitialized stack memory, because the "reserved" member of the
fb_vblank struct declared on the stack is not altered or zeroed before
being copied back to the user. This patch takes care of it.
Signed-off-by: Dan Rosenberg <dan.j.rosenberg@gmail.com>
Cc: Thomas Winischhofer <thomas@winischhofer.net>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Andrew Morton [Wed, 22 Sep 2010 20:05:11 +0000 (13:05 -0700)]
drivers/pci/intel-iommu.c: fix build with older gcc's
commit
df08cdc7ef606509debe7677c439be0ca48790e4 upstream.
drivers/pci/intel-iommu.c: In function `__iommu_calculate_agaw':
drivers/pci/intel-iommu.c:437: sorry, unimplemented: inlining failed in call to 'width_to_agaw': function body not available
drivers/pci/intel-iommu.c:445: sorry, unimplemented: called from here
Move the offending function (and its siblings) to top-of-file, remove the
forward declaration.
Addresses https://bugzilla.kernel.org/show_bug.cgi?id=17441
Reported-by: Martin Mokrejs <mmokrejs@ribosome.natur.cuni.cz>
Cc: David Woodhouse <dwmw2@infradead.org>
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Jan Kara [Tue, 21 Sep 2010 09:49:01 +0000 (11:49 +0200)]
char: Mark /dev/zero and /dev/kmem as not capable of writeback
commit
371d217ee1ff8b418b8f73fb2a34990f951ec2d4 upstream.
These devices don't do any writeback but their device inodes still can get
dirty so mark bdi appropriately so that bdi code does the right thing and files
inodes to lists of bdi carrying the device inodes.
Signed-off-by: Jan Kara <jack@suse.cz>
Signed-off-by: Jens Axboe <jaxboe@fusionio.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Patrick Simmons [Wed, 8 Sep 2010 14:34:28 +0000 (10:34 -0400)]
oprofile: Add Support for Intel CPU Family 6 / Model 22 (Intel Celeron 540)
commit
c33f543d320843e1732534c3931da4bbd18e6c14 upstream.
This patch adds CPU type detection for the Intel Celeron 540, which is
part of the Core 2 family according to Wikipedia; the family and ID pair
is absent from the Volume 3B table referenced in the source code
comments. I have tested this patch on an Intel Celeron 540 machine
reporting itself as Family 6 Model 22, and OProfile runs on the machine
without issue.
Spec:
http://download.intel.com/design/mobile/SPECUPDT/317667.pdf
Signed-off-by: Patrick Simmons <linuxrocks123@netscape.net>
Acked-by: Andi Kleen <ak@linux.intel.com>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Robert Richter <robert.richter@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Stanislaw Gruszka [Tue, 14 Sep 2010 14:35:14 +0000 (16:35 +0200)]
sched: Fix user time incorrectly accounted as system time on 32-bit
commit
e75e863dd5c7d96b91ebbd241da5328fc38a78cc upstream.
We have 32-bit variable overflow possibility when multiply in
task_times() and thread_group_times() functions. When the
overflow happens then the scaled utime value becomes erroneously
small and the scaled stime becomes i erroneously big.
Reported here:
https://bugzilla.redhat.com/show_bug.cgi?id=633037
https://bugzilla.kernel.org/show_bug.cgi?id=16559
Reported-by: Michael Chapman <redhat-bugzilla@very.puzzling.org>
Reported-by: Ciriaco Garcia de Celis <sysman@etherpilot.com>
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Hidetoshi Seto <seto.hidetoshi@jp.fujitsu.com>
LKML-Reference: <
20100914143513.GB8415@redhat.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Paul E. McKenney [Wed, 1 Sep 2010 00:00:18 +0000 (17:00 -0700)]
pid: make setpgid() system call use RCU read-side critical section
commit
950eaaca681c44aab87a46225c9e44f902c080aa upstream.
[ 23.584719]
[ 23.584720] ===================================================
[ 23.585059] [ INFO: suspicious rcu_dereference_check() usage. ]
[ 23.585176] ---------------------------------------------------
[ 23.585176] kernel/pid.c:419 invoked rcu_dereference_check() without protection!
[ 23.585176]
[ 23.585176] other info that might help us debug this:
[ 23.585176]
[ 23.585176]
[ 23.585176] rcu_scheduler_active = 1, debug_locks = 1
[ 23.585176] 1 lock held by rc.sysinit/728:
[ 23.585176] #0: (tasklist_lock){.+.+..}, at: [<
ffffffff8104771f>] sys_setpgid+0x5f/0x193
[ 23.585176]
[ 23.585176] stack backtrace:
[ 23.585176] Pid: 728, comm: rc.sysinit Not tainted 2.6.36-rc2 #2
[ 23.585176] Call Trace:
[ 23.585176] [<
ffffffff8105b436>] lockdep_rcu_dereference+0x99/0xa2
[ 23.585176] [<
ffffffff8104c324>] find_task_by_pid_ns+0x50/0x6a
[ 23.585176] [<
ffffffff8104c35b>] find_task_by_vpid+0x1d/0x1f
[ 23.585176] [<
ffffffff81047727>] sys_setpgid+0x67/0x193
[ 23.585176] [<
ffffffff810029eb>] system_call_fastpath+0x16/0x1b
[ 24.959669] type=1400 audit(
1282938522.956:4): avc: denied { module_request } for pid=766 comm="hwclock" kmod="char-major-10-135" scontext=system_u:system_r:hwclock_t:s0 tcontext=system_u:system_r:kernel_t:s0 tclas
It turns out that the setpgid() system call fails to enter an RCU
read-side critical section before doing a PID-to-task_struct translation.
This commit therefore does rcu_read_lock() before the translation, and
also does rcu_read_unlock() after the last use of the returned pointer.
Reported-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Acked-by: David Howells <dhowells@redhat.com>
Cc: Jiri Slaby <jslaby@suse.cz>
Cc: Oleg Nesterov <oleg@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Dan Carpenter [Fri, 10 Sep 2010 01:56:16 +0000 (01:56 +0000)]
net/llc: make opt unsigned in llc_ui_setsockopt()
commit
339db11b219f36cf7da61b390992d95bb6b7ba2e upstream.
The members of struct llc_sock are unsigned so if we pass a negative
value for "opt" it can cause a sign bug. Also it can cause an integer
overflow when we multiply "opt * HZ".
Signed-off-by: Dan Carpenter <error27@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Dan Carpenter [Mon, 6 Sep 2010 12:32:30 +0000 (14:32 +0200)]
Staging: vt6655: fix buffer overflow
commit
dd173abfead903c7df54e977535973f3312cd307 upstream.
"param->u.wpa_associate.wpa_ie_len" comes from the user. We should
check it so that the copy_from_user() doesn't overflow the buffer.
Also further down in the function, we assume that if
"param->u.wpa_associate.wpa_ie_len" is set then "abyWPAIE[0]" is
initialized. To make that work, I changed the test here to say that if
"wpa_ie_len" is set then "wpa_ie" has to be a valid pointer or we return
-EINVAL.
Oddly, we only use the first element of the abyWPAIE[] array. So I
suspect there may be some other issues in this function.
Signed-off-by: Dan Carpenter <error27@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Andy Gospodarek [Fri, 10 Sep 2010 11:43:20 +0000 (11:43 +0000)]
bonding: correctly process non-linear skbs
commit
ab12811c89e88f2e66746790b1fe4469ccb7bdd9 upstream.
It was recently brought to my attention that 802.3ad mode bonds would no
longer form when using some network hardware after a driver update.
After snooping around I realized that the particular hardware was using
page-based skbs and found that skb->data did not contain a valid LACPDU
as it was not stored there. That explained the inability to form an
802.3ad-based bond. For balance-alb mode bonds this was also an issue
as ARPs would not be properly processed.
This patch fixes the issue in my tests and should be applied to 2.6.36
and as far back as anyone cares to add it to stable.
Thanks to Alexander Duyck <alexander.h.duyck@intel.com> and Jesse
Brandeburg <jesse.brandeburg@intel.com> for the suggestions on this one.
Signed-off-by: Andy Gospodarek <andy@greyhouse.net>
CC: Alexander Duyck <alexander.h.duyck@intel.com>
CC: Jesse Brandeburg <jesse.brandeburg@intel.com>
Signed-off-by: Jay Vosburgh <fubar@us.ibm.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Dan Rosenberg [Wed, 15 Sep 2010 11:43:04 +0000 (11:43 +0000)]
drivers/net/eql.c: prevent reading uninitialized stack memory
commit
44467187dc22fdd33a1a06ea0ba86ce20be3fe3c upstream.
Fixed formatting (tabs and line breaks).
The EQL_GETMASTRCFG device ioctl allows unprivileged users to read 16
bytes of uninitialized stack memory, because the "master_name" member of
the master_config_t struct declared on the stack in eql_g_master_cfg()
is not altered or zeroed before being copied back to the user. This
patch takes care of it.
Signed-off-by: Dan Rosenberg <dan.j.rosenberg@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Dan Rosenberg [Wed, 15 Sep 2010 11:43:12 +0000 (11:43 +0000)]
drivers/net/cxgb3/cxgb3_main.c: prevent reading uninitialized stack memory
commit
49c37c0334a9b85d30ab3d6b5d1acb05ef2ef6de upstream.
Fixed formatting (tabs and line breaks).
The CHELSIO_GET_QSET_NUM device ioctl allows unprivileged users to read
4 bytes of uninitialized stack memory, because the "addr" member of the
ch_reg struct declared on the stack in cxgb_extension_ioctl() is not
altered or zeroed before being copied back to the user. This patch
takes care of it.
Signed-off-by: Dan Rosenberg <dan.j.rosenberg@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Dan Rosenberg [Wed, 15 Sep 2010 11:43:28 +0000 (11:43 +0000)]
drivers/net/usb/hso.c: prevent reading uninitialized memory
commit
7011e660938fc44ed86319c18a5954e95a82ab3e upstream.
Fixed formatting (tabs and line breaks).
The TIOCGICOUNT device ioctl allows unprivileged users to read
uninitialized stack memory, because the "reserved" member of the
serial_icounter_struct struct declared on the stack in hso_get_count()
is not altered or zeroed before being copied back to the user. This
patch takes care of it.
Signed-off-by: Dan Rosenberg <dan.j.rosenberg@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
David S. Miller [Mon, 20 Sep 2010 00:50:44 +0000 (17:50 -0700)]
sparc64: Get rid of indirect p1275 PROM call buffer.
[ Upstream commit
25edd6946a1d74e5e77813c2324a0908c68bcf9e ]
This is based upon a report by Meelis Roos showing that it's possible
that we'll try to fetch a property that is 32K in size with some
devices. With the current fixed 3K buffer we use for moving data in
and out of the firmware during PROM calls, that simply won't work.
In fact, it will scramble random kernel data during bootup.
The reasoning behind the temporary buffer is entirely historical. It
used to be the case that we had problems referencing dynamic kernel
memory (including the stack) early in the boot process before we
explicitly told the firwmare to switch us over to the kernel trap
table.
So what we did was always give the firmware buffers that were locked
into the main kernel image.
But we no longer have problems like that, so get rid of all of this
indirect bounce buffering.
Besides fixing Meelis's bug, this also makes the kernel data about 3K
smaller.
It was also discovered during these conversions that the
implementation of prom_retain() was completely wrong, so that was
fixed here as well. Currently that interface is not in use.
Reported-by: Meelis Roos <mroos@linux.ee>
Tested-by: Meelis Roos <mroos@linux.ee>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Timo Teräs [Thu, 10 Jun 2010 00:31:48 +0000 (17:31 -0700)]
r8169: fix mdio_read and update mdio_write according to hw specs
[ Upstream commit
81a95f049962ec20a9aed888e676208b206f0f2e ]
Realtek confirmed that a 20us delay is needed after mdio_read and
mdio_write operations. Reduce the delay in mdio_write, and add it
to mdio_read too. Also add a comment that the 20us is from hw specs.
Signed-off-by: Timo Teräs <timo.teras@iki.fi>
Acked-by: Francois Romieu <romieu@fr.zoreil.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Timo Teräs [Sun, 6 Jun 2010 22:38:47 +0000 (15:38 -0700)]
r8169: fix random mdio_write failures
[ Upstream commit
024a07bacf8287a6ddfa83e9d5b951c5e8b4070e ]
Some configurations need delay between the "write completed" indication
and new write to work reliably.
Realtek driver seems to use longer delay when polling the "write complete"
bit, so it waits long enough between writes with high probability (but
could probably break too). This patch adds a new udelay to make sure we
wait unconditionally some time after the write complete indication.
This caused a regression with XID
18000000 boards when the board specific
phy configuration writing many mdio registers was added in commit
2e955856ff (r8169: phy init for the 8169scd). Some of the configration
mdio writes would almost always fail, and depending on failure might leave
the PHY in non-working state.
Signed-off-by: Timo Teräs <timo.teras@iki.fi>
Acked-off-by: Francois Romieu <romieu@fr.zoreil.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Tetsuo Handa [Sat, 4 Sep 2010 01:34:28 +0000 (01:34 +0000)]
UNIX: Do not loop forever at unix_autobind().
[ Upstream commit
a9117426d0fcc05a194f728159a2d43df43c7add ]
We assumed that unix_autobind() never fails if kzalloc() succeeded.
But unix_autobind() allows only
1048576 names. If /proc/sys/fs/file-max is
larger than
1048576 (e.g. systems with more than 10GB of RAM), a local user can
consume all names using fork()/socket()/bind().
If all names are in use, those who call bind() with addr_len == sizeof(short)
or connect()/sendmsg() with setsockopt(SO_PASSCRED) will continue
while (1)
yield();
loop at unix_autobind() till a name becomes available.
This patch adds a loop counter in order to give up after
1048576 attempts.
Calling yield() for once per 256 attempts may not be sufficient when many names
are already in use, for __unix_find_socket_byname() can take long time under
such circumstance. Therefore, this patch also adds cond_resched() call.
Note that currently a local user can consume 2GB of kernel memory if the user
is allowed to create and autobind
1048576 UNIX domain sockets. We should
consider adding some restriction for autobind operation.
Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Alexey Kuznetsov [Wed, 15 Sep 2010 17:27:52 +0000 (10:27 -0700)]
tcp: Prevent overzealous packetization by SWS logic.
[ Upstream commit
01f83d69844d307be2aa6fea88b0e8fe5cbdb2f4 ]
If peer uses tiny MSS (say, 75 bytes) and similarly tiny advertised
window, the SWS logic will packetize to half the MSS unnecessarily.
This causes problems with some embedded devices.
However for large MSS devices we do want to half-MSS packetize
otherwise we never get enough packets into the pipe for things
like fast retransmit and recovery to work.
Be careful also to handle the case where MSS > window, otherwise
we'll never send until the probe timer.
Reported-by: ツ Leandro Melo de Sales <leandroal@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Eric Dumazet [Mon, 16 Aug 2010 03:25:00 +0000 (03:25 +0000)]
rds: fix a leak of kernel memory
[ Upstream commit
f037590fff3005ce8a1513858d7d44f50053cc8f ]
struct rds_rdma_notify contains a 32 bits hole on 64bit arches,
make sure it is zeroed before copying it to user.
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
CC: Andy Grover <andy.grover@oracle.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Steven J. Magnani [Tue, 30 Mar 2010 20:56:01 +0000 (13:56 -0700)]
net: Fix oops from tcp_collapse() when using splice()
[ Upstream commit
baff42ab1494528907bf4d5870359e31711746ae ]
tcp_read_sock() can have a eat skbs without immediately advancing copied_seq.
This can cause a panic in tcp_collapse() if it is called as a result
of the recv_actor dropping the socket lock.
A userspace program that splices data from a socket to either another
socket or to a file can trigger this bug.
Signed-off-by: Steven J. Magnani <steve@digidescorp.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
David S. Miller [Mon, 20 Sep 2010 04:45:29 +0000 (21:45 -0700)]
bridge: Clear INET control block of SKBs passed into ip_fragment().
[ Upstream commit
4ce6b9e1621c187a32a47a17bf6be93b1dc4a3df ]
In a similar vain to commit
17762060c25590bfddd68cc1131f28ec720f405f
("bridge: Clear IPCB before possible entry into IP stack")
Any time we call into the IP stack we have to make sure the state
there is as expected by the ipv4 code.
With help from Eric Dumazet and Herbert Xu.
Reported-by: Brandan Das <brandan.das@stratus.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Herbert Xu [Mon, 5 Jul 2010 21:29:28 +0000 (21:29 +0000)]
bridge: Clear IPCB before possible entry into IP stack
[ Upstream commit
17762060c25590bfddd68cc1131f28ec720f405f ]
The bridge protocol lives dangerously by having incestuous relations
with the IP stack. In this instance an abomination has been created
where a bogus IPCB area from a bridged packet leads to a crash in
the IP stack because it's interpreted as IP options.
This patch papers over the problem by clearing the IPCB area in that
particular spot. To fix this properly we'd also need to parse any
IP options if present but I'm way too lazy for that.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Eric Dumazet [Mon, 20 Sep 2010 04:38:12 +0000 (21:38 -0700)]
tcp: fix three tcp sysctls tuning
[ Upstream commit
c5ed63d66f24fd4f7089b5a6e087b0ce7202aa8e ]
As discovered by Anton Blanchard, current code to autotune
tcp_death_row.sysctl_max_tw_buckets, sysctl_tcp_max_orphans and
sysctl_max_syn_backlog makes little sense.
The bigger a page is, the less tcp_max_orphans is : 4096 on a 512GB
machine in Anton's case.
(tcp_hashinfo.bhash_size * sizeof(struct inet_bind_hashbucket))
is much bigger if spinlock debugging is on. Its wrong to select bigger
limits in this case (where kernel structures are also bigger)
bhash_size max is 65536, and we get this value even for small machines.
A better ground is to use size of ehash table, this also makes code
shorter and more obvious.
Based on a patch from Anton, and another from David.
Reported-and-tested-by: Anton Blanchard <anton@samba.org>
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
David S. Miller [Wed, 25 Aug 2010 09:27:49 +0000 (02:27 -0700)]
tcp: Combat per-cpu skew in orphan tests.
[ Upstream commit
ad1af0fedba14f82b240a03fe20eb9b2fdbd0357 ]
As reported by Anton Blanchard when we use
percpu_counter_read_positive() to make our orphan socket limit checks,
the check can be off by up to num_cpus_online() * batch (which is 32
by default) which on a 128 cpu machine can be as large as the default
orphan limit itself.
Fix this by doing the full expensive sum check if the optimized check
triggers.
Reported-by: Anton Blanchard <anton@samba.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Acked-by: Eric Dumazet <eric.dumazet@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
KOSAKI Motohiro [Tue, 24 Aug 2010 16:05:48 +0000 (16:05 +0000)]
tcp: select(writefds) don't hang up when a peer close connection
[ Upstream commit
d84ba638e4ba3c40023ff997aa5e8d3ed002af36 ]
This issue come from ruby language community. Below test program
hang up when only run on Linux.
% uname -mrsv
Linux 2.6.26-2-486 #1 Sat Dec 26 08:37:39 UTC 2009 i686
% ruby -rsocket -ve '
BasicSocket.do_not_reverse_lookup = true
serv = TCPServer.open("127.0.0.1", 0)
s1 = TCPSocket.open("127.0.0.1", serv.addr[1])
s2 = serv.accept
s2.close
s1.write("a") rescue p $!
s1.write("a") rescue p $!
Thread.new {
s1.write("a")
}.join'
ruby 1.9.3dev (2010-07-06 trunk 28554) [i686-linux]
#<Errno::EPIPE: Broken pipe>
[Hang Here]
FreeBSD, Solaris, Mac doesn't. because Ruby's write() method call
select() internally. and tcp_poll has a bug.
SUS defined 'ready for writing' of select() as following.
| A descriptor shall be considered ready for writing when a call to an output
| function with O_NONBLOCK clear would not block, whether or not the function
| would transfer data successfully.
That said, EPIPE situation is clearly one of 'ready for writing'.
We don't have read-side issue because tcp_poll() already has read side
shutdown care.
| if (sk->sk_shutdown & RCV_SHUTDOWN)
| mask |= POLLIN | POLLRDNORM | POLLRDHUP;
So, Let's insert same logic in write side.
- reference url
http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-core/31065
http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-core/31068
Signed-off-by: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
David S. Miller [Mon, 20 Sep 2010 00:56:19 +0000 (17:56 -0700)]
irda: Correctly clean up self->ias_obj on irda_bind() failure.
[ Upstream commit
628e300cccaa628d8fb92aa28cb7530a3d5f2257 ]
If irda_open_tsap() fails, the irda_bind() code tries to destroy
the ->ias_obj object by hand, but does so wrongly.
In particular, it fails to a) release the hashbin attached to the
object and b) reset the self->ias_obj pointer to NULL.
Fix both problems by using irias_delete_object() and explicitly
setting self->ias_obj to NULL, just as irda_release() does.
Reported-by: Tavis Ormandy <taviso@cmpxchg8b.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Jarek Poplawski [Sat, 4 Sep 2010 10:34:29 +0000 (10:34 +0000)]
gro: Re-fix different skb headrooms
[ Upstream commit
64289c8e6851bca0e589e064c9a5c9fbd6ae5dd4 ]
The patch: "gro: fix different skb headrooms" in its part:
"2) allocate a minimal skb for head of frag_list" is buggy. The copied
skb has p->data set at the ip header at the moment, and skb_gro_offset
is the length of ip + tcp headers. So, after the change the length of
mac header is skipped. Later skb_set_mac_header() sets it into the
NET_SKB_PAD area (if it's long enough) and ip header is misaligned at
NET_SKB_PAD + NET_IP_ALIGN offset. There is no reason to assume the
original skb was wrongly allocated, so let's copy it as it was.
bugzilla : https://bugzilla.kernel.org/show_bug.cgi?id=16626
fixes commit:
3d3be4333fdf6faa080947b331a6a19bce1a4f57
Reported-by: Plamen Petrov <pvp-lsts@fs.uni-ruse.bg>
Signed-off-by: Jarek Poplawski <jarkao2@gmail.com>
CC: Eric Dumazet <eric.dumazet@gmail.com>
Acked-by: Eric Dumazet <eric.dumazet@gmail.com>
Tested-by: Plamen Petrov <pvp-lsts@fs.uni-ruse.bg>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Eric Dumazet [Wed, 1 Sep 2010 00:50:51 +0000 (00:50 +0000)]
gro: fix different skb headrooms
[ Upstream commit
3d3be4333fdf6faa080947b331a6a19bce1a4f57 ]
Packets entering GRO might have different headrooms, even for a given
flow (because of implementation details in drivers, like copybreak).
We cant force drivers to deliver packets with a fixed headroom.
1) fix skb_segment()
skb_segment() makes the false assumption headrooms of fragments are same
than the head. When CHECKSUM_PARTIAL is used, this can give csum_start
errors, and crash later in skb_copy_and_csum_dev()
2) allocate a minimal skb for head of frag_list
skb_gro_receive() uses netdev_alloc_skb(headroom + skb_gro_offset(p)) to
allocate a fresh skb. This adds NET_SKB_PAD to a padding already
provided by netdevice, depending on various things, like copybreak.
Use alloc_skb() to allocate an exact padding, to reduce cache line
needs:
NET_SKB_PAD + NET_IP_ALIGN
bugzilla : https://bugzilla.kernel.org/show_bug.cgi?id=16626
Many thanks to Plamen Petrov, testing many debugging patches !
With help of Jarek Poplawski.
Reported-by: Plamen Petrov <pvp-lsts@fs.uni-ruse.bg>
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
CC: Jarek Poplawski <jarkao2@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
David S. Miller [Wed, 3 Mar 2010 10:30:37 +0000 (02:30 -0800)]
sparc: Provide io{read,write}{16,32}be().
[ Upstream commit
1bff4dbb79a2bc0ee4881c8ea6a4fbed64ea6309 ]
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Dan Rosenberg [Wed, 15 Sep 2010 21:44:16 +0000 (17:44 -0400)]
USB: serial/mos*: prevent reading uninitialized stack memory
commit
a0846f1868b11cd827bdfeaf4527d8b1b1c0b098 upstream.
The TIOCGICOUNT device ioctl in both mos7720.c and mos7840.c allows
unprivileged users to read uninitialized stack memory, because the
"reserved" member of the serial_icounter_struct struct declared on the
stack is not altered or zeroed before being copied back to the user.
This patch takes care of it.
Signed-off-by: Dan Rosenberg <dan.j.rosenberg@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>