- 12 Nov, 2010 23 commits
-
-
Samu Onkalo authored
Create sub directory Documentation/leds and add short documentation for LP5521 and LP5523 drivers. Signed-off-by:
Samu Onkalo <samu.p.onkalo@nokia.com> Cc: Richard Purdie <rpurdie@rpsys.net> Cc: Jean Delvare <khali@linux-fr.org> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
Samu Onkalo authored
Provide configuration and compilation support for LP5521 and LP5523 Signed-off-by:
-
Samu Onkalo authored
LP5523 chip is nine channel led driver with programmable engines. Driver provides support for that chip for direct access via led class or via programmable engines. Signed-off-by:
-
Samu Onkalo authored
This patchset provides support for LP5521 and LP5523 LED driver chips from National Semicondutor. Both drivers supports programmable engines and naturally LED class features. Documentation is provided as a part of the patchset. I created "leds" subdirectory under Documentation. Perhaps the rest of the leds* documentation should be moved there. Datasheets are freely available at National Semiconductor www pages. This patch: LP5521 chip is three channel led driver with programmable engines. Driver provides support for that chip for direct access via led class or via programmable engines. Signed-off-by:
-
Johannes Berg authored
Currently, blinking LEDs can be awkward because it is not guaranteed that all LEDs implement blinking. The trigger that wants it to blink then needs to implement its own timer solution. Rather than require that, add led_blink_set() API that triggers can use. This function will attempt to use hw blinking, but if that fails implements a timer for it. To stop blinking again, brightness_set() also needs to be wrapped into API that will stop the software blink. As a result of this, the timer trigger becomes a very trivial one, and hopefully we can finally see triggers using blinking as well because it's always easy to use. Signed-off-by:
Johannes Berg <johannes.berg@intel.com> Acked-by:
Richard Purdie <rpurdie@linux.intel.com> Signed-off-by:
-
Dave Jones authored
WARN_ONCE is a bit strong for a deprecation warning, given that it spews a huge backtrace. Signed-off-by:
Dave Jones <davej@redhat.com> Signed-off-by:
-
Nick Piggin authored
Salman Qazi describes the following radix-tree bug: In the following case, we get can get a deadlock: 0. The radix tree contains two items, one has the index 0. 1. The reader (in this case find_get_pages) takes the rcu_read_lock. 2. The reader acquires slot(s) for item(s) including the index 0 item. 3. The non-zero index item is deleted, and as a consequence the other item is moved to the root of the tree. The place where it used to be is queued for deletion after the readers finish. 3b. The zero item is deleted, removing it from the direct slot, it remains in the rcu-delayed indirect node. 4. The reader looks at the index 0 slot, and finds that the page has 0 ref count 5. The reader looks at it again, hoping that the item will either be freed or the ref count will increase. This never happens, as the slot it is looking at will never be updated. Also, this slot can never be reclaimed because the reader is holding rcu_read_lock and is in an infinite loop. The fix is to re-use the same "indirect" pointer case that requires a slot lookup retry into a general "retry the lookup" bit. Signed-off-by:Nick Piggin <npiggin@kernel.dk> Reported-by:
Salman Qazi <sqazi@google.com> Cc: <stable@kernel.org> Signed-off-by:
-
Dan Rosenberg authored
The kernel syslog contains debugging information that is often useful during exploitation of other vulnerabilities, such as kernel heap addresses. Rather than futilely attempt to sanitize hundreds (or thousands) of printk statements and simultaneously cripple useful debugging functionality, it is far simpler to create an option that prevents unprivileged users from reading the syslog. This patch, loosely based on grsecurity's GRKERNSEC_DMESG, creates the dmesg_restrict sysctl. When set to "0", the default, no restrictions are enforced. When set to "1", only users with CAP_SYS_ADMIN can read the kernel syslog via dmesg(8) or other mechanisms. [akpm@linux-foundation.org: explain the config option in kernel.txt] Signed-off-by:
Dan Rosenberg <drosenberg@vsecurity.com> Acked-by:
Ingo Molnar <mingo@elte.hu> Acked-by:
Eugene Teo <eugeneteo@kernel.org> Acked-by:
Kees Cook <kees.cook@canonical.com> Signed-off-by:
-
David Rientjes authored
/proc/pid/oom_adj was deprecated in August 2010 with the introduction of the new oom killer heuristic. This patch copies the Documentation/feature-removal-schedule.txt entry for this tunable to the Documentation/ABI/obsolete directory so nobody misses it. Signed-off-by:
David Rientjes <rientjes@google.com> Reported-by:
Alan Cox <alan@lxorguk.ukuu.org.uk> Signed-off-by:
-
Shaohua Li authored
nr_dirty and nr_congested are increased only when the page is dirty. So if all pages are clean, both them will be zero. In this case, we should not mark the zone congested. Signed-off-by:
Shaohua Li <shaohua.li@intel.com> Reviewed-by:
Johannes Weiner <hannes@cmpxchg.org> Reviewed-by:
Minchan Kim <minchan.kim@gmail.com> Acked-by:
Mel Gorman <mel@csn.ul.ie> Signed-off-by:
-
Ken Chen authored
Per task latencytop accumulator prematurely terminates due to erroneous placement of latency_record_count. It should be incremented whenever a new record is allocated instead of increment on every latencytop event. Also fix search iterator to only search known record events instead of blindly searching all pre-allocated space. Signed-off-by:
Ken Chen <kenchen@google.com> Reviewed-by:
Arjan van de Ven <arjan@infradead.org> Cc: <stable@kernel.org> Signed-off-by:
-
Dave Hansen authored
70 hours into some stress tests of a 2.6.32-based enterprise kernel, we ran into a NULL dereference in here: int block_is_partially_uptodate(struct page *page, read_descriptor_t *desc, unsigned long from) { ----> struct inode *inode = page->mapping->host; It looks like page->mapping was the culprit. (xmon trace is below). After closer examination, I realized that do_generic_file_read() does a find_get_page(), and eventually locks the page before calling block_is_partially_uptodate(). However, it doesn't revalidate the page->mapping after the page is locked. So, there's a small window between the find_get_page() and ->is_partially_uptodate() where the page could get truncated and page->mapping cleared. We _have_ a reference, so it can't get reclaimed, but it certainly can be truncated. I think the correct thing is to check page->mapping after the trylock_page(), and jump out if it got truncated. This patch has been running in the test environment for a month or so now, and we have not seen this bug pop up again. xmon info: 1f:mon> e cpu 0x1f: Vector: 300 (Data Access) at [c0000002ae36f770] pc: c0000000001e7a6c: .block_is_partially_uptodate+0xc/0x100 lr: c000000000142944: .generic_file_aio_read+0x1e4/0x770 sp: c0000002ae36f9f0 msr: 8000000000009032 dar: 0 dsisr: 40000000 current = 0xc000000378f99e30 paca = 0xc000000000f66300 pid = 21946, comm = bash 1f:mon> r R00 = 0025c0500000006d R16 = 0000000000000000 R01 = c0000002ae36f9f0 R17 = c000000362cd3af0 R02 = c000000000e8cd80 R18 = ffffffffffffffff R03 = c0000000031d0f88 R19 = 0000000000000001 R04 = c0000002ae36fa68 R20 = c0000003bb97b8a0 R05 = 0000000000000000 R21 = c0000002ae36fa68 R06 = 0000000000000000 R22 = 0000000000000000 R07 = 0000000000000001 R23 = c0000002ae36fbb0 R08 = 0000000000000002 R24 = 0000000000000000 R09 = 0000000000000000 R25 = c000000362cd3a80 R10 = 0000000000000000 R26 = 0000000000000002 R11 = c0000000001e7b60 R27 = 0000000000000000 R12 = 0000000042000484 R28 = 0000000000000001 R13 = c000000000f66300 R29 = c0000003bb97b9b8 R14 = 0000000000000001 R30 = c000000000e28a08 R15 = 000000000000ffff R31 = c0000000031d0f88 pc = c0000000001e7a6c .block_is_partially_uptodate+0xc/0x100 lr = c000000000142944 .generic_file_aio_read+0x1e4/0x770 msr = 8000000000009032 cr = 22000488 ctr = c0000000001e7a60 xer = 0000000020000000 trap = 300 dar = 0000000000000000 dsisr = 40000000 1f:mon> t [link register ] c000000000142944 .generic_file_aio_read+0x1e4/0x770 [c0000002ae36f9f0] c000000000142a14 .generic_file_aio_read+0x2b4/0x770 (unreliable) [c0000002ae36fb40] c0000000001b03e4 .do_sync_read+0xd4/0x160 [c0000002ae36fce0] c0000000001b153c .vfs_read+0xec/0x1f0 [c0000002ae36fd80] c0000000001b1768 .SyS_read+0x58/0xb0 [c0000002ae36fe30] c00000000000852c syscall_exit+0x0/0x40 --- Exception: c00 (System Call) at 00000080a840bc54 SP (fffca15df30) is in userspace 1f:mon> di c0000000001e7a6c c0000000001e7a6c e9290000 ld r9,0(r9) c0000000001e7a70 418200c0 beq c0000000001e7b30 # .block_is_partially_uptodate+0xd0/0x100 c0000000001e7a74 e9440008 ld r10,8(r4) c0000000001e7a78 78a80020 clrldi r8,r5,32 c0000000001e7a7c 3c000001 lis r0,1 c0000000001e7a80 812900a8 lwz r9,168(r9) c0000000001e7a84 39600001 li r11,1 c0000000001e7a88 7c080050 subf r0,r8,r0 c0000000001e7a8c 7f805040 cmplw cr7,r0,r10 c0000000001e7a90 7d6b4830 slw r11,r11,r9 c0000000001e7a94 796b0020 clrldi r11,r11,32 c0000000001e7a98 419d00a8 bgt cr7,c0000000001e7b40 # .block_is_partially_uptodate+0xe0/0x100 c0000000001e7a9c 7fa55840 cmpld cr7,r5,r11 c0000000001e7aa0 7d004214 add r8,r0,r8 c0000000001e7aa4 79080020 clrldi r8,r8,32 c0000000001e7aa8 419c0078 blt cr7,c0000000001e7b20 # .block_is_partially_uptodate+0xc0/0x100 Signed-off-by:Dave Hansen <dave@linux.vnet.ibm.com> Reviewed-by:
Rik van Riel <riel@redhat.com> Cc: <arunabal@in.ibm.com> Cc: <sbest@us.ibm.com> Cc: Christoph Hellwig <hch@lst.de> Cc: Al Viro <viro@zeniv.linux.org.uk> Cc: Minchan Kim <minchan.kim@gmail.com> Cc: <stable@kernel.org> Signed-off-by:
-
Alexey Khoroshilov authored
clean_sort_range() should return a number of nonempty elements of range array, but if the array is full clean_sort_range() returns 0. The problem is that the number of nonempty elements is evaluated by finding the first empty element of the array. If there is no such element it returns an initial value of local variable nr_range that is zero. The fix is trivial: it changes initial value of nr_range to size of the array. The bug can lead to loss of information regarding all ranges, since typically returned value of clean_sort_range() is considered as an actual number of ranges in the array after a series of add/subtract operations. Found by Analytical Verification project of Linux Verification Center (linuxtesting.org), thanks to Alexander Kolosov. Signed-off-by:
Alexey Khoroshilov <khoroshilov@ispras.ru> Cc: Yinghai Lu <yinghai@kernel.org> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by:
-
Dan Carpenter authored
There was a signedness bug so "ret" was never less than zero and that breaks the error handling. Also in the original code it would overwrite ret and the result is still negative but it's bogus number instead of the correct error code. Signed-off-by:
Dan Carpenter <error27@gmail.com> Cc: Samu Onkalo <samu.p.onkalo@nokia.com> Cc: Jonathan Cameron <jic23@cam.ac.uk> Signed-off-by:
-
Dan Carpenter authored
The original code had a null dereference if alloc_percpu() failed. This was introduced in commit 711d3d2c ("memcg: cpu hotplug aware percpu count updates") Signed-off-by:
Balbir Singh <balbir@linux.vnet.ibm.com> Acked-by:
KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> Acked-by:
Daisuke Nishimura <nishimura@mxp.nes.nec.co.jp> Signed-off-by:
-
Vasiliy Kulikov authored
i2c_smbus_read_byte_data() may return negative error code. This is not seen to als_sensing_range_store() as the result is stored in unsigned int. Made it signed. Signed-off-by:
Vasiliy Kulikov <segooon@gmail.com> Cc: Hong Liu <hong.liu@intel.com> Cc: Alan Cox <alan@linux.intel.com> Cc: Anantha Narayanan <anantha.narayanan@intel.com> Signed-off-by:
-
Dan Carpenter authored
"ret_val" is supposed to be signed here or the error handling breaks. Also we should check the return value from i2c_smbus_read_byte_data(). Signed-off-by:
Alan Cox <alan@linux.intel.com> Signed-off-by:
-
Catalin Marinas authored
Commit 3e4d3af5 ("mm: stack based kmap_atomic()") introduced the kmap_atomic_idx_push() function which warns on in_irq() with CONFIG_DEBUG_HIGHMEM enabled. This patch includes linux/hardirq.h for the in_irq definition. Signed-off-by:
Catalin Marinas <catalin.marinas@arm.com> Acked-by:
Peter Zijlstra <a.p.zijlstra@chello.nl> Signed-off-by:
-
Eric Dumazet authored
Followup of perf tools session in Netfilter WorkShop 2010 In the network stack we make high usage of atomic_inc_not_zero() in contexts we know the probable value of atomic before increment (2 for udp sockets for example) Using a special version of atomic_inc_not_zero() giving this hint can help processor to use less bus transactions. On x86 (MESI protocol) for example, this avoids entering Shared state, because "lock cmpxchg" issues an RFO (Read For Ownership) akpm: Adds a new include/linux/atomic.h. This means that new code should henceforth include linux/atomic.h and not asm/atomic.h. The presence of include/linux/atomic.h will in fact cause checkpatch.pl to warn about use of asm/atomic.h. The new include/linux/atomic.h becomes the place where arch-neutral atomic_t code should be placed. [akpm@linux-foundation.org: coding-style fixes] Signed-off-by:
Eric Dumazet <eric.dumazet@gmail.com> Cc: Christoph Lameter <cl@linux-foundation.org> Cc: Ingo Molnar <mingo@elte.hu> Cc: Andi Kleen <andi@firstfloor.org> Cc: Arnaldo Carvalho de Melo <acme@infradead.org> Cc: David Miller <davem@davemloft.net> Cc: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> Cc: Nick Piggin <npiggin@kernel.dk> Reviewed-by:
"Paul E. McKenney" <paulmck@linux.vnet.ibm.com> Signed-off-by:
-
Jean Delvare authored
Fix the following warning: usr/include/linux/resource.h:49: found __[us]{8,16,32,64} type without #include <linux/types.h> Signed-off-by:Jean Delvare <khali@linux-fr.org> Signed-off-by:
-
Dan Carpenter authored
The size calculation is done incorrectly here because it should include both the start and end (end - start + 1). It's easiest to just use resource_size() which does the right thing. I was worried there was something non-standard going on because the printk() subtracts "end - 1", but the rest of the file uses the normal resource size calculations. This function is only called from fsl_rio_setup() in arch/powerpc/sysdev/fsl_rio.c and the calculation there is also: port->iores.start = law_start; port->iores.end = law_start + law_size - 1; So I think this is the correct fix. Signed-off-by:
Li Yang <leoli@freescale.com> Signed-off-by:
-
Geert Uytterhoeven authored
Fix these warnings: drivers/macintosh/adb-iop.c: In function `adb_iop_complete': drivers/macintosh/adb-iop.c:85: warning: comparison of distinct pointer types lacks a cast drivers/macintosh/adb-iop.c:92: warning: comparison of distinct pointer types lacks a cast drivers/macintosh/adb-iop.c: In function ¡adb_iop_listen¢: drivers/macintosh/adb-iop.c:111: warning: comparison of distinct pointer types lacks a cast drivers/macintosh/adb-iop.c:151: warning: comparison of distinct pointer types lacks a cast Signed-off-by:
Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by:
-
Richard Weinberger authored
Both commits 0a3d763f ("ptrace: cleanup arch_ptrace() on um") and 9b05a69e ("ptrace: change signature of arch_ptrace()") broke the um build. This patch fixes the issues. 0a3d763f introduced the undeclared variable "datavp". The patch seems completely untested. :-( 9b05a69e changed arch_ptrace()'s signature but did not update um/include/asm/ptrace-generic.h. Signed-off-by:
Richard Weinberger <richard@nod.at> Cc: Namhyung Kim <namhyung@gmail.com> Cc: Jeff Dike <jdike@addtoit.com> Tested-by:
Will Newton <will.newton@gmail.com> Signed-off-by:
-
- 09 Nov, 2010 5 commits
-
-
git://git.kernel.org/pub/scm/linux/kernel/git/sfrench/cifs-2.6Linus Torvalds authored
* git://git.kernel.org/pub/scm/linux/kernel/git/sfrench/cifs-2.6: cifs: fix a memleak in cifs_setattr_nounix() cifs: make cifs_ioctl handle NULL filp->private_data correctly
-
Pekka Enberg authored
As pointed out by Linus, commit dab5855b ("perf_counter: Add mmap event hooks to mprotect()") is fundamentally wrong as mprotect_fixup() can free 'vma' due to merging. Fix the problem by moving perf_event_mmap() hook to mprotect_fixup(). Note: there's another successful return path from mprotect_fixup() if old flags equal to new flags. We don't, however, need to call perf_event_mmap() there because 'perf' already knows the VMA is executable. Reported-by:
Pekka Enberg <penberg@kernel.org> Signed-off-by:
-
Suresh Jayaraman authored
Andrew Hendry reported a kmemleak warning in 2.6.37-rc1 while editing a text file with gedit over cifs. unreferenced object 0xffff88022ee08b40 (size 32): comm "gedit", pid 2524, jiffies 4300160388 (age 2633.655s) hex dump (first 32 bytes): 5c 2e 67 6f 75 74 70 75 74 73 74 72 65 61 6d 2d \.goutputstream- 35 42 41 53 4c 56 00 de 09 00 00 00 2c 26 78 ee 5BASLV......,&x. backtrace: [<ffffffff81504a4d>] kmemleak_alloc+0x2d/0x60 [<ffffffff81136e13>] __kmalloc+0xe3/0x1d0 [<ffffffffa0313db0>] build_path_from_dentry+0xf0/0x230 [cifs] [<ffffffffa031ae1e>] cifs_setattr+0x9e/0x770 [cifs] [<ffffffff8115fe90>] notify_change+0x170/0x2e0 [<ffffffff81145ceb>] sys_fchmod+0x10b/0x140 [<ffffffff8100c172>] system_call_fastpath+0x16/0x1b [<ffffffffffffffff>] 0xffffffffffffffff The commit 1025774c that removed inode_setattr() seems to have introduced this memleak by returning early without freeing 'full_path'. Reported-by:Andrew Hendry <andrew.hendry@gmail.com> Cc: Christoph Hellwig <hch@lst.de> Reviewed-by:
Jeff Layton <jlayton@redhat.com> Signed-off-by:
Suresh Jayaraman <sjayaraman@suse.de> Signed-off-by:
Steve French <sfrench@us.ibm.com>
-
Linus Torvalds authored
Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/security-testing-2.6 * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/security-testing-2.6: kernel: Constify temporary variable in roundup()
-
Tetsuo Handa authored
Fix build error with GCC 3.x caused by commit b28efd54 "kernel: roundup should only reference arguments once" by constifying temporary variable used in that macro. Signed-off-by:
Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> Suggested-by:
Eric Paris <eparis@redhat.com> Signed-off-by:
James Morris <jmorris@namei.org>
-
- 08 Nov, 2010 12 commits
-
-
Meelis Roos authored
Fix openpromfs compilation by adding a missing semicolon in fs/openpromfs/inode.c openprom_mount(). Signed-off-by:
Meelis Roos <mroos@linux.ee> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4Linus Torvalds authored
* 'for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4: ext4: Add new ext4 inode tracepoints ext4: Don't call sb_issue_discard() in ext4_free_blocks() ext4: do not try to grab the s_umount semaphore in ext4_quota_off ext4: fix potential race when freeing ext4_io_page structures ext4: handle writeback of inodes which are being freed ext4: initialize the percpu counters before replaying the journal ext4: "ret" may be used uninitialized in ext4_lazyinit_thread() ext4: fix lazyinit hang after removing request
-
Jeff Layton authored
Commit 13cfb733 made cifs_ioctl use the tlink attached to the cifsFileInfo for a filp. This ignores the case of an open directory however, which in CIFS can have a NULL private_data until a readdir is done on it. This patch re-adds the NULL pointer checks that were removed in commit 50ae28f0 and moves the setting of tcon and "caps" variables lower. Long term, a better fix would be to establish a f_op->open routine for directories that populates that field at open time, but that requires some other changes to how readdir calls are handled. Reported-by:
Kjell Rune Skaaraas <kjella79@yahoo.no> Reviewed-and-Tested-by:
-
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty-2.6Linus Torvalds authored
* git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty-2.6: TTY: move .gitignore from drivers/char/ to drivers/tty/vt/ TTY: create drivers/tty/vt and move the vt code there TTY: create drivers/tty and move the tty core files there
-
Linus Torvalds authored
Merge branch 'staging-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging-next-2.6 * 'staging-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging-next-2.6: Staging: ath6kl: remove empty files that mess with 'distclean' staging: ath6kl: Fixing the driver to use modified mmc_host structure Staging: solo6x10: fix build problem
-
Linus Torvalds authored
Merge branch 'rmobile-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/lethal/sh-2.6 * 'rmobile-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/lethal/sh-2.6: mmc: sh_mmcif: Convert extern inline to static inline. ARM: mach-shmobile: Allow GPIO chips to register IRQ mappings. ARM: mach-shmobile: fix sh7372 after a recent clock framework rework ARM: mach-shmobile: include drivers/sh/Kconfig ARM: mach-shmobile: ap4evb: Add HDMI sound support ARM: mach-shmobile: clock-sh7372: Add FSIDIV clock support ARM: shmobile: remove sh_timer_config clk member
-
git://git.kernel.org/pub/scm/linux/kernel/git/lethal/sh-2.6Linus Torvalds authored
* 'sh-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/lethal/sh-2.6: sh: clkfwk: Fix up checkpatch warnings. sh: make some needlessly global sh7724 clocks static sh: add clk_round_parent() to optimize parent clock rate sh: Simplify phys_addr_mask()/PTE_PHYS_MASK for 29/32-bit. sh: nommu: Support building without an uncached mapping. sh: nommu: use 32-bit phys mode. sh: mach-se: Fix up SE7206 no ioport build. sh: intc: Update for single IRQ reservation helper. sh: clkfwk: Fix up rate rounding error handling. sh: mach-se: Rip out superfluous 7751 PIO routines. sh: mach-se: Rip out superfluous 770x PIO routines. sh: mach-edosk7705: Kill off machtype, consolidate board def. sh: mach-edosk7705: update for this century, kill off PIO trapping. sh: mach-se: Rip out superfluous 7206 PIO routines. sh: mach-systemh: Kill off dead board. sh: mach-snapgear: Kill off machtype, consolidate board def. sh: mach-snapgear: Rip out superfluous PIO routines. sh: mach-microdev: SuperIO-relative ioport mapping.
-
Theodore Ts'o authored
Add ext4_evict_inode, ext4_drop_inode, ext4_mark_inode_dirty, and ext4_begin_ordered_truncate() Signed-off-by:"Theodore Ts'o" <tytso@mit.edu>
-
Theodore Ts'o authored
Commit 5c521830 (ext4: Support discard requests when running in no-journal mode) attempts to add sb_issue_discard() for data blocks (in data=writeback mode) and in no-journal mode. Unfortunately, this no longer works, because in commit dd3932ed (block: remove BLKDEV_IFL_WAIT), sb_issue_discard() only presents a synchronous interface, and there are times when we call ext4_free_blocks() when we are are holding a spinlock, or are otherwise in an atomic context. For now, I've removed the call to sb_issue_discard() to prevent a deadlock or (if spinlock debugging is enabled) failures like this: BUG: scheduling while atomic: rc.sysinit/1376/0x00000002 Pid: 1376, comm: rc.sysinit Not tainted 2.6.36-ARCH #1 Call Trace: [<ffffffff810397ce>] __schedule_bug+0x5e/0x70 [<ffffffff81403110>] schedule+0x950/0xa70 [<ffffffff81060bad>] ? insert_work+0x7d/0x90 [<ffffffff81060fbd>] ? queue_work_on+0x1d/0x30 [<ffffffff81061127>] ? queue_work+0x37/0x60 [<ffffffff8140377d>] schedule_timeout+0x21d/0x360 [<ffffffff812031c3>] ? generic_make_request+0x2c3/0x540 [<ffffffff81402680>] wait_for_common+0xc0/0x150 [<ffffffff81041490>] ? default_wake_function+0x0/0x10 [<ffffffff812034bc>] ? submit_bio+0x7c/0x100 [<ffffffff810680a0>] ? wake_bit_function+0x0/0x40 [<ffffffff814027b8>] wait_for_completion+0x18/0x20 [<ffffffff8120a969>] blkdev_issue_discard+0x1b9/0x210 [<ffffffff811ba03e>] ext4_free_blocks+0x68e/0xb60 [<ffffffff811b1650>] ? __ext4_handle_dirty_metadata+0x110/0x120 [<ffffffff811b098c>] ext4_ext_truncate+0x8cc/0xa70 [<ffffffff810d713e>] ? pagevec_lookup+0x1e/0x30 [<ffffffff81191618>] ext4_truncate+0x178/0x5d0 [<ffffffff810eacbb>] ? unmap_mapping_range+0xab/0x280 [<ffffffff810d8976>] vmtruncate+0x56/0x70 [<ffffffff811925cb>] ext4_setattr+0x14b/0x460 [<ffffffff811319e4>] notify_change+0x194/0x380 [<ffffffff81117f80>] do_truncate+0x60/0x90 [<ffffffff811e08fa>] ? security_inode_permission+0x1a/0x20 [<ffffffff811eaec1>] ? tomoyo_path_truncate+0x11/0x20 [<ffffffff81127539>] do_last+0x5d9/0x770 [<ffffffff811278bd>] do_filp_open+0x1ed/0x680 [<ffffffff8140644f>] ? page_fault+0x1f/0x30 [<ffffffff81132bfc>] ? alloc_fd+0xec/0x140 [<ffffffff81118db1>] do_sys_open+0x61/0x120 [<ffffffff81118e8b>] sys_open+0x1b/0x20 [<ffffffff81002e6b>] system_call_fastpath+0x16/0x1b https://bugzilla.kernel.org/show_bug.cgi?id=22302Reported-by:
Mathias Burén <mathias.buren@gmail.com> Signed-off-by:
-
Dmitry Monakhov authored
It's not needed to sync the filesystem, and it fixes a lock_dep complaint. Signed-off-by:
Dmitry Monakhov <dmonakhov@gmail.com> Signed-off-by:
Jan Kara <jack@suse.cz>
-
Theodore Ts'o authored
Use an atomic_t and make sure we don't free the structure while we might still be submitting I/O for that page. Signed-off-by: -
Theodore Ts'o authored
The following BUG can occur when an inode which is getting freed when it still has dirty pages outstanding, and it gets deleted (in this because it was the target of a rename). In ordered mode, we need to make sure the data pages are written just in case we crash before the rename (or unlink) is committed. If the inode is being freed then when we try to igrab the inode, we end up tripping the BUG_ON at fs/ext4/page-io.c:146. To solve this problem, we need to keep track of the number of io callbacks which are pending, and avoid destroying the inode until they have all been completed. That way we don't have to bump the inode count to keep the inode from being destroyed; an approach which doesn't work because the count could have already been dropped down to zero before the inode writeback has started (at which point we're not allowed to bump the count back up to 1, since it's already started getting freed). Thanks to Dave Chinner for suggesting this approach, which is also used by XFS. kernel BUG at /scratch_space/linux-2.6/fs/ext4/page-io.c:146! Call Trace: [<ffffffff811075b1>] ext4_bio_write_page+0x172/0x307 [<ffffffff811033a7>] mpage_da_submit_io+0x2f9/0x37b [<ffffffff811068d7>] mpage_da_map_and_submit+0x2cc/0x2e2 [<ffffffff811069b3>] mpage_add_bh_to_extent+0xc6/0xd5 [<ffffffff81106c66>] write_cache_pages_da+0x2a4/0x3ac [<ffffffff81107044>] ext4_da_writepages+0x2d6/0x44d [<ffffffff81087910>] do_writepages+0x1c/0x25 [<ffffffff810810a4>] __filemap_fdatawrite_range+0x4b/0x4d [<ffffffff810815f5>] filemap_fdatawrite_range+0xe/0x10 [<ffffffff81122a2e>] jbd2_journal_begin_ordered_truncate+0x7b/0xa2 [<ffffffff8110615d>] ext4_evict_inode+0x57/0x24c [<ffffffff810c14a3>] evict+0x22/0x92 [<ffffffff810c1a3d>] iput+0x212/0x249 [<ffffffff810bdf16>] dentry_iput+0xa1/0xb9 [<ffffffff810bdf6b>] d_kill+0x3d/0x5d [<ffffffff810be613>] dput+0x13a/0x147 [<ffffffff810b990d>] sys_renameat+0x1b5/0x258 [<ffffffff81145f71>] ? _atomic_dec_and_lock+0x2d/0x4c [<ffffffff810b2950>] ? cp_new_stat+0xde/0xea [<ffffffff810b29c1>] ? sys_newlstat+0x2d/0x38 [<ffffffff810b99c6>] sys_rename+0x16/0x18 [<ffffffff81002a2b>] system_call_fastpath+0x16/0x1b Reported-by:
Nick Bowler <nbowler@elliptictech.com> Signed-off-by:
-
