13 Mar, 2009
14 commits
-
There was a report of a data corruption
http://lkml.org/lkml/2008/11/14/121. There is a script included to
reproduce the problem.During testing, I encountered a number of strange things with ext3, so I
tried ext2 to attempt to reduce complexity of the problem. I found that
fsstress would quickly hang in wait_on_inode, waiting for I_LOCK to be
cleared, even though instrumentation showed that unlock_new_inode had
already been called for that inode. This points to memory scribble, or
synchronisation problme.i_state of I_NEW inodes is not protected by inode_lock because other
processes are not supposed to touch them until I_LOCK (and I_NEW) is
cleared. Adding WARN_ON(inode->i_state & I_NEW) to sites where we modify
i_state revealed that generic_sync_sb_inodes is picking up new inodes from
the inode lists and passing them to __writeback_single_inode without
waiting for I_NEW. Subsequently modifying i_state causes corruption. In
my case it would look like this:CPU0 CPU1
unlock_new_inode() __sync_single_inode()
reg i_state
reg -> reg & ~(I_LOCK|I_NEW) reg i_state
reg -> inode->i_state reg -> reg | I_SYNC
reg -> inode->i_stateNon-atomic RMW on CPU1 overwrites CPU0 store and sets I_LOCK|I_NEW again.
Fix for this is rather than wait for I_NEW inodes, just skip over them:
inodes concurrently being created are not subject to data integrity
operations, and should not significantly contribute to dirty memory
either.After this change, I'm unable to reproduce any of the added warnings or
hangs after ~1hour of running. Previously, the new warnings would start
immediately and hang would happen in under 5 minutes.I'm also testing on ext3 now, and so far no problems there either. I
don't know whether this fixes the problem reported above, but it fixes a
real problem for me.Cc: "Jorge Boncompte [DTI2]"
Reported-by: Adrian Hunter
Cc: Jan Kara
Cc:
Signed-off-by: Nick Piggin
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
Even when page reclaim is under mem_cgroup, # of scan page is determined by
status of global LRU. Fix that.Signed-off-by: KOSAKI Motohiro
Signed-off-by: KAMEZAWA Hiroyuki
Cc: Daisuke Nishimura
Cc: Balbir Singh
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
No software visible difference from revision A.
Signed-off-by: Mark Brown
Cc: Samuel Ortiz
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
Currently we disable the Acer WMI backlight device if there is no ACPI
backlight device. As a result, we end up with no backlight device at all.
We should instead disable it if there is an ACPI device, as the other
laptop drivers do. This regression was introduced in febf2d9 ("Acer-WMI:
fingers off backlight if video.ko is serving this functionality").Each laptop driver with backlight support got a similar change around
febf2d9. The changes to the other drivers look correct; see e.g.
a598c82f for a similar but correct change. The regression is also in
2.6.28.Signed-off-by: Michael Spang
Acked-by: Thomas Renninger
Cc: Zhang Rui
Cc: Andi Kleen
Cc: Carlos Corbacho
Cc: Len Brown
Cc: "Rafael J. Wysocki"
Cc: [2.6.28.x]
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
The s3cmci driver is calling s3c2410_dma_config with incorrect data for
the DCON register. The S3C2410_DCON_HWTRIG is implicit in the channel
configuration and the device selection of S3C2410_DCON_CH0_SDI is
incorrect as the DMA system may not select channel 0.Signed-off-by: Ben Dooks
Acked-by: Pierre Ossman
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
Unfortunately, Linux Foundation funding for my work on
man-pages/testing/doc under the auspices of the LF documentation
fellowship unfortunately ran out a short while ago (after earlier attempts
to seek funding, only Google stepped forward with a bit of further funding
for the position), so the patch below acknowledges something closer to
reality.Unfortunately, there will (probably very) soon be a further downgrade from
"Maintained" to "Odd Fixes" or "Orphan", unless some funding miracle
occurs. So, if anyone is looking to become man-pages maintainer, there
may soon be an opening (okay, don't trample me in the rush ;-).)Signed-off-by: Michael Kerrisk
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
The 'battery remaining capacity' calculation in
drivers/power/ds2760_battery.c lacks a parameter check to a division
operation which causes the kernel to oops on my board.[ 21.233750] Division by zero in kernel.
[ 21.237646] [] (__div0+0x0/0x20) from [] (Ldiv0+0x8/0x10)
[ 21.244816] [] (ds2760_battery_read_status+0x0/0x2a4) from [] (ds2760_battery_get_property+0x30/0xdc)
[ 21.255803] r8:c03a22c0 r7:c7886100 r6:00000009 r5:c782fe7c r4:c7886084
[ 21.262518] [] (ds2760_battery_get_property+0x0/0xdc) from [] (power_supply_show_property+0x48/0x114)
[ 21.273480] r6:c7996000 r5:00000009 r4:00000000
[ 21.278111] [] (power_supply_show_property+0x0/0x114) from [] (power_supply_uevent+0x188/0x280)
[ 21.288537] r8:00000001 r7:c7886100 r6:c7996000 r5:000000b4 r4:00000000
[ 21.295222] [] (power_supply_uevent+0x0/0x280) from [] (dev_uevent+0xd4/0x10c)
[ 21.304199] [] (dev_uevent+0x0/0x10c) from [] (kobject_uevent_env+0x180/0x390)
[ 21.313170] r5:00000000 r4:c78860ac
[ 21.316725] [] (kobject_uevent_env+0x0/0x390) from [] (kobject_uevent+0x14/0x18)
[ 21.325850] [] (kobject_uevent+0x0/0x18) from [] (power_supply_changed_work+0x5c/0x70)
[ 21.335506] [] (power_supply_changed_work+0x0/0x70) from [] (run_workqueue+0xbc/0x144)
[ 21.345167] r4:c7812040
[ 21.347716] [] (run_workqueue+0x0/0x144) from [] (worker_thread+0xa8/0xbc)
[ 21.356296] r7:c7812040 r6:c7820b00 r5:c782ffa4 r4:c7812048
[ 21.361957] [] (worker_thread+0x0/0xbc) from [] (kthread+0x5c/0x94)
[ 21.369971] r7:00000000 r6:c004d8a4 r5:c7812040 r4:c782e000
[ 21.375612] [] (kthread+0x0/0x94) from [] (do_exit+0x0/0x688)Signed-off-by: Daniel Mack
Cc: Szabolcs Gyurko
Acked-by: Matt Reimer
Acked-by: Anton Vorontsov
Cc: David Woodhouse
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
In sget(), destroy_super(s) is called with s->s_umount held, which makes
lockdep unhappy.Signed-off-by: Li Zefan
Cc: Al Viro
Acked-by: Peter Zijlstra
Cc: Paul Menage
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
If the second fasync_helper() fails, pipe_rdwr_fasync() returns the error
but leaves the file on ->fasync_readers.This was always wrong, but since 233e70f4228e78eb2f80dc6650f65d3ae3dbf17c
"saner FASYNC handling on file close" we have the new problem. Because in
this case setfl() doesn't set FASYNC bit, __fput() will not do
->fasync(0), and we leak fasync_struct with ->fa_file pointing to the
freed file.Signed-off-by: Oleg Nesterov
Cc: Al Viro
Cc: Andi Kleen
Cc: Jonathan Corbet
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
W1 master implementations are expected to return 0 or 1 from their
read_bit() function. However, not all platforms do return these values
from gpio_get_value() - namely PXAs won't. Hence the w1 gpio-master needs
to break the result down to 0 or 1 itself.Signed-off-by: Daniel Mack
Cc: Ville Syrjala
Cc: Evgeniy Polyakov
Cc: David Brownell
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
Fix the following warning on x86_64:
LD vmlinux.o
MODPOST vmlinux.o
WARNING: vmlinux: 'memcpy' exported twice. Previous export was in vmlinuxFor x86_64, this symbol is already exported from arch/um/sys-x86_64/ksyms.c.
Reported-by: Boaz Harrosh
Signed-off-by: WANG Cong
Tested-by: Boaz Harrosh
Cc: Jeff Dike
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
It is currently impossible to run a user-mode linux machine inside another
user-mode linux (UML on UML). It breaks after a few instructions. When
it tries to check whether SYSEMU is installed (the inner) UML receives an
inconsistent result (from the outer UML).This is the output of a broken attempt:
$ ./linux mem=256m ubd0=cow
Locating the bottom of the address space ... 0x0
Locating the top of the address space ... 0xc0000000
Core dump limits :
soft - 0
hard - NONE
Checking that ptrace can change system call numbers...OK
Checking ptrace new tags for syscall emulation...unsupported
Checking syscall emulation patch for ptrace...check_sysemu : expected SIGTRAP, got status = 256
$The problem is the following:
PTRACE_SYSCALL/SINGLESTEP is currently managed inside arch_ptrace for ARCH=um.
PTRACE_SYSEMU/SUSEMU_SINGLESTEP is not captured in arch_ptrace's switch,
therefore it is erroneously passed back to ptrace_request (in
kernel/ptrace).This simple patch simply forces ptrace to return an error on
PTRACE_SYSEMU/SUSEMU_SINGLESTEP as it is unsupported on ARCH=um, and fixes
the problem.[akpm@linux-foundation.org: coding-style fixes]
Signed-off-by: Renzo Davoli
Reviewed-by: WANG Cong
Cc: Jeff Dike
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
* git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc-2.6:
sunhme: Fix qfe parent detection.
sparc64: Fix lost interrupts on sun4u.
sparc64: wait_event_interruptible_timeout may return -ERESTARTSYS
jsflash: stop defining MAJOR_NR -
* 'upstream' of git://ftp.linux-mips.org/pub/scm/upstream-linus:
MIPS: IP27: Enable RAID5 module
MIPS: TXx9: update defconfigs
MIPS: NEC VR5500 processor support fixup
MIPS: Fix build of non-CONFIG_SYSVIPC version of sys_32_ipc
12 Mar, 2009
13 commits
-
* 'for-linus' of git://oss.sgi.com/xfs/xfs:
xfs: only issues a cache flush on unmount if barriers are enabled
xfs: prevent lockdep false positive in xfs_iget_cache_miss
xfs: prevent kernel crash due to corrupted inode log format -
Signed-off-by: Ralf Baechle
-
Enable following features:
* MTD (PHYSMAP)
* LED (LEDS_GPIO)
* RBTX4939
* 7SEGLED
* IDE (IDE_TX4938, IDE_TX4939)
* SMC91X
* RTC_DRV_TX4939Signed-off-by: Atsushi Nemoto
Signed-off-by: Ralf Baechle -
Current VR5500 processor support lacks of some functions which are
expected to be configured/synthesized on arch initialization.Here're some VR5500A spec notes:
* All execution hazards are handled in hardware.
* Once VR5500A stops the operation of the pipeline by WAIT instruction,
it could return from the standby mode only when either a reset, NMI
request, or all enabled interrupts is/are detected. In other words,
if interrupts are disabled by Status.IE=0, it keeps in standby mode
even when interrupts are internally asserted.Notes on WAIT: The operation of the processor is undefined if WAIT
insn is in the branch delay slot. The operation is also undefined
if WAIT insn is executed when Status.EXL and Status.ERL are set to 1.* VR5500A core only implements the Load prefetch.
With these changes, it boots fine.
Signed-off-by: Shinya Kuribayashi
Signed-off-by: Ralf Baechle -
Signed-off-by: Xiaotian Feng
Signed-off-by: Ralf Baechle -
* 'drm-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6:
drm: fix EDID parser problem with positive/negative hsync/vsync -
* 'merge' of git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc:
radeonfb/aty128fb: Disable broken early resume hook for PowerBooks
hvc_console: Remove tty->low_latency on pseries backends
powerpc: fix linkstation and storcenter compilation breakage
powerpc/4xx: Enable SERIAL_OF support by default for Virtex platforms -
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/anholt/drm-intel:
drm/i915: fix 945 fence register writes for fence 8 and above.
drm/i915: Protect active fences on i915
drm/i915: Check to see if we've pinned all available fences
drm/i915: Check fence status on every pin.
drm/i915: First recheck for an empty fence register.
drm/i915: Fix bad \n in MTRR failure notice.
drm/i915: Don't restore palettes through VGA registers.
i915: add newline to i915_gem_object_pin failure msg
drm: Return EINVAL on duplicate objects in execbuffer object list -
…git/tip/linux-2.6-tip
* 'x86-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip:
x86: work around Fedora-11 x86-32 kernel failures on Intel Atom CPUs -
On swapon() path, it has already i_mutex. So, this uses i_alloc_sem
instead of it.Signed-off-by: OGAWA Hirofumi
Reported-by: Laurent GUERBY
Signed-off-by: Linus Torvalds -
The last 8 fence registers sit at a different offset, so when we went to set
fence number 8 in the lower offset, we instead set PGETBL_CTL, and the GPU
got all sorts of angry at us.fd.o bug #20567. Easily reproducible by running glxgears and killing it about
6 times.Signed-off-by: Eric Anholt
-
The i915 also uses the fence registers for GPU access to tiled buffers so
we cannot reallocate one whilst it is on the active list. By performing a
LRU scan of the fenced buffers we also avoid waiting the possibility of
waiting on a pinned, or otherwise unusable, buffer.Signed-off-by: Chris Wilson
Signed-off-by: Eric Anholt -
Impact: work around boot crash
Work around Intel Atom erratum AAH41 (probabilistically) - it's triggering
in the field.Reported-by: Linus Torvalds
Tested-by: Kyle McMartin
Signed-off-by: Ingo Molnar
11 Mar, 2009
13 commits
-
Fix kpf_copy_bit(src,dst) to be kpf_copy_bit(dst,src) to match the
actual call patterns, e.g. kpf_copy_bit(kflags, KPF_LOCKED, PG_locked).This misplacement of src/dst only affected reporting of PG_writeback,
PG_reclaim and PG_buddy. For others kflags==uflags so not affected.Signed-off-by: Wu Fengguang
Reviewed-by: KOSAKI Motohiro
Cc: stable@kernel.org
Signed-off-by: Linus Torvalds -
We need to check and report if there are no available fences - or else we
spin endlessly waiting for a buffer to magically unpin itself.Signed-off-by: Chris Wilson
Signed-off-by: Eric Anholt -
As we may steal the fence register of an unpinned buffer for another,
every time we repin the buffer we need to recheck whether it needs to be
allocated a fence.Signed-off-by: Chris Wilson
Signed-off-by: Eric Anholt -
If we wait upon a request and successfully unbind a buffer occupying a
fence register, then that slot will be freed and cause a NULL derefrence
upon rescanning.Signed-off-by: Chris Wilson
Signed-off-by: Eric Anholt -
Comparing the layouts of struct detail_pixel_timing with
x.org's struct detailed_timings and how those are handled,
it appears that the hsync_positive and vsync_positive
fields are backwards.This patch fixes https://bugs.freedesktop.org/show_bug.cgi?id=20019
for me. It was tested on 2 monitors, LG FLATRON L225WS 22" and
a YAKUMO 17" for which more details are unknown.Signed-off-by: Pantelis Koukousoulas
Signed-off-by: Dave Airlie -
radeonfb and aty128fb have a special hook called by the PowerMac platform
code very very early on resume from sleep to bring the screen back. This
is useful for debugging wakup problems, but unfortunately, this also became
a source of problems of its own.The hook is called extremely early, with interrupts still off, and the code
path involved with that code nowadays rely on things like taking mutexes,
GFP_KERNEL allocations, etc...In addition, the driver now relies on the PCI core to restore the standard
config space before calling resume which doesn't happen with this early
code path.I'm keeping the code in but commented out along with a fixup call to
pci_restore_state(). The reason is that I still want to make it easy to
re-enable temporarily to track wake up problems, and it's possible that
I can revive it at some stage if we make sleeping things save to call
in early resume using a system state.In the meantime, this should fix several reported regressions.
Signed-off-by: Benjamin Herrenschmidt
-
The hvcs and hvsi backends both set tty->low_latency to one, along
with more or less scary comments regarding bugs or races that would
happen if not doing so.However, they also both call tty_flip_buffer_push() in conexts where
it's illegal to do so since some recent tty changes (or at least it
may have been illegal always but it nows blows) when low_latency is
set (ie, hard interrupt or with spinlock held and irqs disabled).This removes the setting for now to get them back to working condition,
we'll have to address the races described in the comments separately
if they are still an issue (some of this might have been fixed already).Signed-off-by: Benjamin Herrenschmidt
-
Prevent the kernel from being crashed by a divide-by-zero operation when
supplied an incorrectly filled 'struct fb_var_screeninfo' from userland.Previously i810_main.c:1005 (i810_check_params) was using the global
'yres' symbol previously defined at i810_main.c:145 as a module parameter
value holder (i810_main.c:2174). If i810fb is compiled-in or if this
param doesn't get a default value, this direct usage leads to a
divide-by-zero at i810_main.c:1005 (i810_check_params). The patch simply
replace the 'yres' global, perhaps undefined symbol usage by a given
parameter structure lookup.This problem occurs with directfb, mplayer -vo fbdev, SDL library.
It was also reported ( but non solved ) at:http://mail.directfb.org/pipermail/directfb-dev/2008-March/004050.html
Signed-off-by: Samuel CUELLA
Cc: Jiri Kosina
Cc: Krzysztof Helt
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
There isn't any mcfqspi.h in the tree, and without it everything inside the
#ifdef CONFIG_SPI is uncompilable.Signed-off-by: Steven King
Acked-by: Greg Ungerer
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
Signed-off-by: Steven King
Acked-by: Greg Ungerer
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
Update the RCU documentation to call out the need for callers of
primitives like call_rcu() and synchronize_rcu() to prevent subsequent RCU
readers from hazard.Signed-off-by: Paul E. McKenney
Cc: Ingo Molnar
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
We were returning early in the sysfs directory cleanup function if the
user belonged to a non init usernamespace. Due to this a lot of the
cleanup was not done and we were left with a leak. Fix the leak.Reported-by: Serge Hallyn
Signed-off-by: Dhaval Giani
Acked-by: Serge Hallyn
Tested-by: Serge Hallyn
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
