- 16 Oct, 2008 40 commits
-
-
David Fries authored
w1_control_thread was removed which would wake up every second and process newly registered family codes and complete some final cleanup for a removed master. Those routines were moved to the threads that were previously requesting those operations. A new function w1_reconnect_slaves takes care of reconnecting existing slave devices when a new family code is registered or removed. The removal case was missing and would cause a deadlock waiting for the family code reference count to decrease, which will now happen. A problem with registering a family code was fixed. A slave device would be unattached if it wasn't yet claimed, then attached at the end of the list, two unclaimed slaves would cause an infinite loop. The struct w1_bus_master.search now takes a pointer to the struct w1_master device to avoid searching for it, which would have caused a lock ordering deadlock with the removal of w1_control_thread. Signed-off-by:
David Fries <david@fries.net> Signed-off-by:
Evgeniy Polyakov <johnpol@2ka.mipt.ru> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
Andrew Morton authored
tpm_register_hardware() leaks devname on an error path. Addresses http://bugzilla.kernel.org/show_bug.cgi?id=11425Reported-by:
Daniel Marjamki <danielm77@spray.se> Cc: Debora Velarde <debora@linux.vnet.ibm.com> Cc: Rajiv Andrade <srajiv@linux.vnet.ibm.com> Cc: Marcel Selhorst <tpm@selhorst.net> Signed-off-by:
-
Rajiv Andrade authored
Cc: Eric Paris <eparis@redhat.com> Signed-off-by:
-
Valdis Kletnieks authored
Patch tpm-correct-tpm-timeouts-to-jiffies-conversion reveals a bug in the Broadcom BCM0102 TPM chipset used in the Dell Latitude D820 - although most of the timeouts are returned in usecs as per the spec, one is apparently returned in msecs, which results in a too-small value leading to a timeout when the code treats it as usecs. To prevent a regression, we check for the known too-short value and adjust it to a value that makes things work. Signed-off-by:
Valdis Kletnieks <valdis.kletnieks@vt.edu> Cc: Marcin Obara <marcin_obara@users.sourceforge.net> Cc: Marcel Selhorst <tpm@selhorst.net> Cc: Kylene Jo Hall <kjhall@us.ibm.com> Signed-off-by:
-
Marcin Obara authored
This patch fixes timeouts conversion to jiffies, by replacing msecs_to_jiffies() calls with usecs_to_jiffies(). According to TCG TPM Specification Version 1.2 Revision 103 (pages 166, 167) TPM timeouts and durations are returned in microseconds (usec) not in miliseconds (msec). This fixes a long hang while loading TPM driver, if TPM chip starts in "Idle" state instead of "Ready" state. Without this patch - 'modprobe' may hang for 30 seconds or more. Signed-off-by:
Marcin Obara <marcin_obara@users.sourceforge.net> Cc: Marcel Selhorst <tpm@selhorst.net> Cc: Kylene Jo Hall <kjhall@us.ibm.com> Cc: Jiri Slaby <jirislaby@gmail.com> Signed-off-by:
-
Adrian Bunk authored
Remove CVS keywords that weren't updated for a long time from comments. Signed-off-by:
Adrian Bunk <bunk@kernel.org> Signed-off-by:
-
Nick Piggin authored
Cannot assume writes will fully complete, so this conversion goes the easy way and always brings the page uptodate before the write. [dhowells@redhat.com: style tweaks] Signed-off-by:
Nick Piggin <npiggin@suse.de> Acked-by:
David Howells <dhowells@redhat.com> Signed-off-by:
-
Aristeu Rozanski authored
Make the Thermal messages (temperature got past Tmid) be displayed only once because: 1) it's the BIOS job to configure and handle the memory throttling 2) if the BIOS is broken or is aware about the condition, flooding the system logs won't help anything. 3) According to the specification update for Intel 5000 MCHs, all the revisions of this MCH have problems on the thermal sensors, making not automatic (a.k.a. intelligent thermal throttling) impossible. Signed-off-by:
Aristeu Rozanski <aris@redhat.com> Signed-off-by:
Doug Thompson <dougthompson@xmission.com> Cc: Alan Cox <alan@lxorguk.ukuu.org.uk> Signed-off-by:
-
Aristeu Rozanski authored
Update the i5000_edac messages, making everything pass through the EDAC (so the log controls will work) and being more specific about the errors. Also, it makes the miscellaneous errors optional and disabled by default. As I didn't found anywhere information about M23ERR-M26ERR (FERR_NF_THERMAL) on FERR_NF_FBD, I'm removing them. Signed-off-by:
-
Andrew Kilkenny authored
This adds support for the dual-core MPC8572 processor. We have to support making SPR changes on each core. Also, since we can have multiple memory controllers sharing an interrupt, flag the interrupts with IRQF_SHARED. Signed-off-by:
Andrew Kilkenny <akilkenny@xes-inc.com> Signed-off-by:
Nate Case <ncase@xes-inc.com> Acked-by:
Dave Jiang <djiang@mvista.com> Signed-off-by:
-
Vladislav Bogdanov authored
Fix 443BX/GX MCH suppport in a EDAC. It makes i82443bxgx_edac coexist with intel_agp using the same approach as several other EDAC drivers. Tested on Intel's L443GX with redhat's 2.6.18 with whole EDAC subsystem backported a while ago. [root@host ~]# dmesg|grep -iE '(AGP|EDAC)' Linux agpgart interface v0.101 (c) Dave Jones agpgart: Detected an Intel 440GX Chipset. agpgart: AGP aperture is 64M @ 0xf8000000 EDAC MC: Ver: 2.1.0 Jun 27 2008 EDAC MC0: Giving out device to 'i82443bxgx_edac' 'I82443BXGX': DEV 0000:00:00.0 EDAC PCI0: Giving out device to module 'i82443bxgx_edac' controller 'EDAC PCI controller': DEV '0000:00:00.0' (POLLED) Signed-off-by:
Vladislav Bogdanov <slava@nsys.by> Cc: Doug Thompson <norsk5@yahoo.com> Cc: Dave Airlie <airlied@linux.ie> Signed-off-by:
-
Oleg Nesterov authored
task_child_reaper() has no callers anymore, kill it. Signed-off-by:
Oleg Nesterov <oleg@tv-sign.ru> Acked-by:
Serge Hallyn <serue@us.ibm.com> Acked-by:
Pavel Emelyanov <xemul@openvz.org> Acked-by:
Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com> Signed-off-by:
-
Oleg Nesterov authored
de_thread() checks if the old leader was the ->child_reaper, this is not possible any longer. With the previous patch ->group_leader itself will change ->child_reaper on exit. Henceforth find_new_reaper() is the only function (apart from initialization) which plays with ->child_reaper. Signed-off-by:
-
Alexey Dobriyan authored
name and nlen parameters passed to ->strategy hook are unused, remove them. In general ->strategy hook should know what it's doing, and don't do something tricky for which, say, pointer to original userspace array may be needed (name). Signed-off-by:
Alexey Dobriyan <adobriyan@gmail.com> Acked-by: David S. Miller <davem@davemloft.net> [ networking bits ] Cc: Ralf Baechle <ralf@linux-mips.org> Cc: David Howells <dhowells@redhat.com> Cc: Matt Mackall <mpm@selenic.com> Cc: "Eric W. Biederman" <ebiederm@xmission.com> Signed-off-by:
-
Alexey Dobriyan authored
Move it into sysrq.c, along with the rest of the sysrq implementation. Signed-off-by:
-
Kay Sievers authored
We currently follow blindly what the partition table lies about the disk, and let the kernel create block devices which can not be accessed. Trying to identify the device leads to kernel logs full of: sdb: rw=0, want=73392, limit=28800 attempt to access beyond end of device Here is an example of a broken partition table, where sda2 starts behind the end of the disk, and sdb3 is larger than the entire disk: Disk /dev/sdb: 14 MB, 14745600 bytes 1 heads, 29 sectors/track, 993 cylinders, total 28800 sectors Device Boot Start End Blocks Id System /dev/sdb1 29 7800 3886 83 Linux /dev/sdb2 37801 45601 3900+ 83 Linux /dev/sdb3 15602 73402 28900+ 83 Linux /dev/sdb4 23403 28796 2697 83 Linux The kernel creates these completely invalid devices, which can not be accessed, or may lead to other unpredictable failures: grep . /sys/class/block/sdb*/{start,size} /sys/class/block/sdb/size:28800 /sys/class/block/sdb1/start:29 /sys/class/block/sdb1/size:7772 /sys/class/block/sdb2/start:37801 /sys/class/block/sdb2/size:7801 /sys/class/block/sdb3/start:15602 /sys/class/block/sdb3/size:57801 /sys/class/block/sdb4/start:23403 /sys/class/block/sdb4/size:5394 With this patch, we ignore partitions which start behind the end of the disk, and limit partitions to the end of the disk if they pretend to be larger: grep . /sys/class/block/sdb*/{start,size} /sys/class/block/sdb/size:28800 /sys/class/block/sdb1/start:29 /sys/class/block/sdb1/size:7772 /sys/class/block/sdb3/start:15602 /sys/class/block/sdb3/size:13198 /sys/class/block/sdb4/start:23403 /sys/class/block/sdb4/size:5394 These warnings are printed to the kernel log: sdb: p2 ignored, start 37801 is behind the end of the disk sdb: p3 size 57801 limited to end of disk Signed-off-by:Kay Sievers <kay.sievers@vrfy.org> Cc: Herton Ronaldo Krzesinski <herton@mandriva.com.br> Cc: Jens Axboe <jens.axboe@oracle.com> Signed-off-by:
-
Adrian Bunk authored
I missed this when I did the arm26 removal. Reported-by:
Robert P. J. Day <rpjday@crashcourse.ca> Signed-off-by:
-
Bjorn Helgaas authored
Convert printks to use dev_printk(). Signed-off-by:
Bjorn Helgaas <bjorn.helgaas@hp.com> Cc: David Woodhouse <dwmw2@infradead.org> Signed-off-by:
-
Harvey Harrison authored
The only use is to pass this to le16_to_cpu, declare as such drivers/char/moxa.c:548:11: warning: cast to restricted __le16. Signed-off-by:
Harvey Harrison <harvey.harrison@gmail.com> Cc: Jiri Slaby <jirislaby@gmail.com> Cc: Alan Cox <alan@lxorguk.ukuu.org.uk> Signed-off-by:
-
Andrew Morton authored
The code scriblles over a local pointer whereas it appears to be trying to write to the memory at which that pointer points. Addresses http://bugzilla.kernel.org/show_bug.cgi?id=11397 Nobody we know can test this change. Reported-by:
Zvonimir Rakamaric <zrakamar@cs.ubc.ca> Cc: Jesse Barnes <jbarnes@virtuousgeek.org> Cc: David Woodhouse <dwmw2@infradead.org> Cc: Jiri Slaby <jirislaby@gmail.com> Cc: Alan Cox <alan@lxorguk.ukuu.org.uk> Signed-off-by:
-
Jiri Slaby authored
ds1286_get_time(); is not called from atomic context, sleep for 20 ms is better choice than a (home-made) busy waiting for such a situation. Signed-off-by:
Jiri Slaby <jirislaby@gmail.com> Acked-by:
Ralf Baechle <ralf@linux-mips.org> Signed-off-by:
-
Alexey Dobriyan authored
Don't repeat BINFMT_ELF definition, simply multiply COMPAT and BINFMT_ELF. Signed-off-by:
-
Paul Mundt authored
These auxvec entries are the only ones left unhandled out of the current base implementation. This syncs up binfmt_elf_fdpic with linux/auxvec.h and current binfmt_elf. Signed-off-by:
Paul Mundt <lethal@linux-sh.org> Acked-by:
-
Paul Mundt authored
binfmt_elf_fdpic seems to have grabbed a hard-coded hack from an ancient version of binfmt_elf in order to try and fix up initial stack alignment on multi-threaded x86, which while in addition to being unused, was also pushed down beyond the first set of operations on the stack pointer, negating the entire purpose. These days, we have an architecture independent arch_align_stack(), so we switch to using that instead. Move the initial alignment up before the initial stores while we're at it. Signed-off-by:
-
Paul Mundt authored
Commit 483fad1c ("ELF loader support for auxvec base platform string") introduced AT_BASE_PLATFORM, but only implemented it for binfmt_elf. Given that AT_VECTOR_SIZE_BASE is unconditionally enlarged for us, and it's only optionally added in for the platforms that set ELF_BASE_PLATFORM, wire it up for binfmt_elf_fdpic, too. Signed-off-by:
-
Randy Dunlap authored
Update Erik Mouw's email address & affiliation in DocBook. Signed-off-by:
Randy Dunlap <randy.dunlap@oracle.com> Acked-by:
Erik Mouw <mouw@nl.linux.org> Signed-off-by:
-
Adrian Bunk authored
Remove CVS keywords that weren't updated for a long time from comments. Signed-off-by:
Jan Kara <jack@suse.cz> Signed-off-by:
-
Julien Brunel authored
In case of error, the function open_xa_dir returns an ERR pointer, but never returns a NULL pointer. So a NULL test that comes after an IS_ERR test should be deleted. The semantic match that finds this problem is as follows: (http://www.emn.fr/x-info/coccinelle/) // <smpl> @match_bad_null_test@ expression x, E; statement S1,S2; @@ x = open_xa_dir(...) ... when != x = E ( * if (x == NULL && ...) S1 else S2 | * if (x == NULL || ...) S1 else S2 ) // </smpl> Signed-off-by:
Julien Brunel <brunel@diku.dk> Signed-off-by:
Julia Lawall <julia@diku.dk> Cc: Jeff Mahoney <jeffm@suse.com> Cc: Jan Kara <jack@ucw.cz> Signed-off-by:
-
Adrian Bunk authored
Remove CVS keywords that weren't updated for a long time from comments. Signed-off-by:
-
Eric Sesterhenn authored
Fix a stack corruption caused by a corrupted hfs filesystem. If the catalog name length is corrupted the memcpy overwrites the catalog btree structure. Since the field is limited to HFS_NAMELEN bytes in the structure and the file format, we throw an error if it is too long. Cc: Roman Zippel <zippel@linux-m68k.org> Signed-off-by:
Eric Sesterhenn <snakebyte@gmx.de> Signed-off-by:
-
Eric Sesterhenn authored
While testing more corrupted images with hfsplus, i came across one which triggered the following bug: [15840.675016] BUG: unable to handle kernel paging request at fffffffb [15840.675016] IP: [<c0116a4f>] kmap+0x15/0x56 [15840.675016] *pde = 00008067 *pte = 00000000 [15840.675016] Oops: 0000 [#1] PREEMPT DEBUG_PAGEALLOC [15840.675016] Modules linked in: [15840.675016] [15840.675016] Pid: 11575, comm: ln Not tainted (2.6.27-rc4-00123-gd3ee1b40-dirty #29) [15840.675016] EIP: 0060:[<c0116a4f>] EFLAGS: 00010202 CPU: 0 [15840.675016] EIP is at kmap+0x15/0x56 [15840.675016] EAX: 00000246 EBX: fffffffb ECX: 00000000 EDX: cab919c0 [15840.675016] ESI: 000007dd EDI: cab0bcf4 EBP: cab0bc98 ESP: cab0bc94 [15840.675016] DS: 007b ES: 007b FS: 0000 GS: 0033 SS: 0068 [15840.675016] Process ln (pid: 11575, ti=cab0b000 task=cab919c0 task.ti=cab0b000) [15840.675016] Stack: 00000000 cab0bcdc c0231cfb 00000000 cab0bce0 00000800 ca9290c0 fffffffb [15840.675016] cab145d0 cab919c0 cab15998 22222222 22222222 22222222 00000001 cab15960 [15840.675016] 000007dd cab0bcf4 cab0bd04 c022cb3a cab0bcf4 cab15a6c ca9290c0 00000000 [15840.675016] Call Trace: [15840.675016] [<c0231cfb>] ? hfsplus_block_allocate+0x6f/0x2d3 [15840.675016] [<c022cb3a>] ? hfsplus_file_extend+0xc4/0x1db [15840.675016] [<c022ce41>] ? hfsplus_get_block+0x8c/0x19d [15840.675016] [<c06adde4>] ? sub_preempt_count+0x9d/0xab [15840.675016] [<c019ece6>] ? __block_prepare_write+0x147/0x311 [15840.675016] [<c0161934>] ? __grab_cache_page+0x52/0x73 [15840.675016] [<c019ef4f>] ? block_write_begin+0x79/0xd5 [15840.675016] [<c022cdb5>] ? hfsplus_get_block+0x0/0x19d [15840.675016] [<c019f22a>] ? cont_write_begin+0x27f/0x2af [15840.675016] [<c022cdb5>] ? hfsplus_get_block+0x0/0x19d [15840.675016] [<c0139ebe>] ? tick_program_event+0x28/0x4c [15840.675016] [<c013bd35>] ? trace_hardirqs_off+0xb/0xd [15840.675016] [<c022b723>] ? hfsplus_write_begin+0x2d/0x32 [15840.675016] [<c022cdb5>] ? hfsplus_get_block+0x0/0x19d [15840.675016] [<c0161988>] ? pagecache_write_begin+0x33/0x107 [15840.675016] [<c01879e5>] ? __page_symlink+0x3c/0xae [15840.675016] [<c019ad34>] ? __mark_inode_dirty+0x12f/0x137 [15840.675016] [<c0187a70>] ? page_symlink+0x19/0x1e [15840.675016] [<c022e6eb>] ? hfsplus_symlink+0x41/0xa6 [15840.675016] [<c01886a9>] ? vfs_symlink+0x99/0x101 [15840.675016] [<c018a2f6>] ? sys_symlinkat+0x6b/0xad [15840.675016] [<c018a348>] ? sys_symlink+0x10/0x12 [15840.675016] [<c01038bd>] ? sysenter_do_call+0x12/0x31 [15840.675016] ======================= [15840.675016] Code: 00 00 75 10 83 3d 88 2f ec c0 02 75 07 89 d0 e8 12 56 05 00 5d c3 55 ba 06 00 00 00 89 e5 53 89 c3 b8 3d eb 7e c0 e8 16 74 00 00 <8b> 03 c1 e8 1e 69 c0 d8 02 00 00 05 b8 69 8e c0 2b 80 c4 02 00 [15840.675016] EIP: [<c0116a4f>] kmap+0x15/0x56 SS:ESP 0068:cab0bc94 [15840.675016] ---[ end trace 4fea40dad6b70e5f ]--- This happens because the return value of read_mapping_page() is passed on to kmap unchecked. The bug is triggered after the first read_mapping_page() in hfsplus_block_allocate(), this patch fixes all three usages in this functions but leaves the ones further down in the file unchanged. Signed-off-by:
-
Eric Sesterhenn authored
When an hfsplus image gets corrupted it might happen that the catalog namelength field gets b0rked. If we mount such an image the memcpy() in hfsplus_cat_build_key_uni() writes more than the 255 that fit in the name field. Depending on the size of the overwritten data, we either only get memory corruption or also trigger an oops like this: [ 221.628020] BUG: unable to handle kernel paging request at c82b0000 [ 221.629066] IP: [<c022d4b1>] hfsplus_find_cat+0x10d/0x151 [ 221.629066] *pde = 0ea29163 *pte = 082b0160 [ 221.629066] Oops: 0002 [#1] PREEMPT DEBUG_PAGEALLOC [ 221.629066] Modules linked in: [ 221.629066] [ 221.629066] Pid: 4845, comm: mount Not tainted (2.6.27-rc4-00123-gd3ee1b40-dirty #28) [ 221.629066] EIP: 0060:[<c022d4b1>] EFLAGS: 00010206 CPU: 0 [ 221.629066] EIP is at hfsplus_find_cat+0x10d/0x151 [ 221.629066] EAX: 00000029 EBX: 00016210 ECX: 000042c2 EDX: 00000002 [ 221.629066] ESI: c82d70ca EDI: c82b0000 EBP: c82d1bcc ESP: c82d199c [ 221.629066] DS: 007b ES: 007b FS: 0000 GS: 0033 SS: 0068 [ 221.629066] Process mount (pid: 4845, ti=c82d1000 task=c8224060 task.ti=c82d1000) [ 221.629066] Stack: c080b3c4 c82aa8f8 c82d19c2 00016210 c080b3be c82d1bd4 c82aa8f0 00000300 [ 221.629066] 01000000 750008b1 74006e00 74006900 65006c00 c82d6400 c013bd35 c8224060 [ 221.629066] 00000036 00000046 c82d19f0 00000082 c8224548 c8224060 00000036 c0d653cc [ 221.629066] Call Trace: [ 221.629066] [<c013bd35>] ? trace_hardirqs_off+0xb/0xd [ 221.629066] [<c013bca3>] ? trace_hardirqs_off_caller+0x14/0x9b [ 221.629066] [<c013bd35>] ? trace_hardirqs_off+0xb/0xd [ 221.629066] [<c013bca3>] ? trace_hardirqs_off_caller+0x14/0x9b [ 221.629066] [<c013bd35>] ? trace_hardirqs_off+0xb/0xd [ 221.629066] [<c0107aa3>] ? native_sched_clock+0x82/0x96 [ 221.629066] [<c01302d2>] ? __kernel_text_address+0x1b/0x27 [ 221.629066] [<c010487a>] ? dump_trace+0xca/0xd6 [ 221.629066] [<c0109e32>] ? save_stack_address+0x0/0x2c [ 221.629066] [<c0109eaf>] ? save_stack_trace+0x1c/0x3a [ 221.629066] [<c013b571>] ? save_trace+0x37/0x8d [ 221.629066] [<c013b62e>] ? add_lock_to_list+0x67/0x8d [ 221.629066] [<c013ea1c>] ? validate_chain+0x8a4/0x9f4 [ 221.629066] [<c013553d>] ? down+0xc/0x2f [ 221.629066] [<c013f1f6>] ? __lock_acquire+0x68a/0x6e0 [ 221.629066] [<c013bd35>] ? trace_hardirqs_off+0xb/0xd [ 221.629066] [<c013bca3>] ? trace_hardirqs_off_caller+0x14/0x9b [ 221.629066] [<c013bd35>] ? trace_hardirqs_off+0xb/0xd [ 221.629066] [<c0107aa3>] ? native_sched_clock+0x82/0x96 [ 221.629066] [<c013da5d>] ? mark_held_locks+0x43/0x5a [ 221.629066] [<c013dc3a>] ? trace_hardirqs_on+0xb/0xd [ 221.629066] [<c013dbf4>] ? trace_hardirqs_on_caller+0xf4/0x12f [ 221.629066] [<c06abec8>] ? _spin_unlock_irqrestore+0x42/0x58 [ 221.629066] [<c013555c>] ? down+0x2b/0x2f [ 221.629066] [<c022aa68>] ? hfsplus_iget+0xa0/0x154 [ 221.629066] [<c022b0b9>] ? hfsplus_fill_super+0x280/0x447 [ 221.629066] [<c0107aa3>] ? native_sched_clock+0x82/0x96 [ 221.629066] [<c013bca3>] ? trace_hardirqs_off_caller+0x14/0x9b [ 221.629066] [<c013bca3>] ? trace_hardirqs_off_caller+0x14/0x9b [ 221.629066] [<c013f1f6>] ? __lock_acquire+0x68a/0x6e0 [ 221.629066] [<c041c9e4>] ? string+0x2b/0x74 [ 221.629066] [<c041cd16>] ? vsnprintf+0x2e9/0x512 [ 221.629066] [<c010487a>] ? dump_trace+0xca/0xd6 [ 221.629066] [<c0109eaf>] ? save_stack_trace+0x1c/0x3a [ 221.629066] [<c0109eaf>] ? save_stack_trace+0x1c/0x3a [ 221.629066] [<c013b571>] ? save_trace+0x37/0x8d [ 221.629066] [<c013b62e>] ? add_lock_to_list+0x67/0x8d [ 221.629066] [<c013ea1c>] ? validate_chain+0x8a4/0x9f4 [ 221.629066] [<c01354d3>] ? up+0xc/0x2f [ 221.629066] [<c013f1f6>] ? __lock_acquire+0x68a/0x6e0 [ 221.629066] [<c013bd35>] ? trace_hardirqs_off+0xb/0xd [ 221.629066] [<c013bca3>] ? trace_hardirqs_off_caller+0x14/0x9b [ 221.629066] [<c013bd35>] ? trace_hardirqs_off+0xb/0xd [ 221.629066] [<c0107aa3>] ? native_sched_clock+0x82/0x96 [ 221.629066] [<c041cfb7>] ? snprintf+0x1b/0x1d [ 221.629066] [<c01ba466>] ? disk_name+0x25/0x67 [ 221.629066] [<c0183960>] ? get_sb_bdev+0xcd/0x10b [ 221.629066] [<c016ad92>] ? kstrdup+0x2a/0x4c [ 221.629066] [<c022a7b3>] ? hfsplus_get_sb+0x13/0x15 [ 221.629066] [<c022ae39>] ? hfsplus_fill_super+0x0/0x447 [ 221.629066] [<c0183583>] ? vfs_kern_mount+0x3b/0x76 [ 221.629066] [<c0183602>] ? do_kern_mount+0x32/0xba [ 221.629066] [<c01960d4>] ? do_new_mount+0x46/0x74 [ 221.629066] [<c0196277>] ? do_mount+0x175/0x193 [ 221.629066] [<c013dbf4>] ? trace_hardirqs_on_caller+0xf4/0x12f [ 221.629066] [<c01663b2>] ? __get_free_pages+0x1e/0x24 [ 221.629066] [<c06ac07b>] ? lock_kernel+0x19/0x8c [ 221.629066] [<c01962e6>] ? sys_mount+0x51/0x9b [ 221.629066] [<c01962f9>] ? sys_mount+0x64/0x9b [ 221.629066] [<c01038bd>] ? sysenter_do_call+0x12/0x31 [ 221.629066] ======================= [ 221.629066] Code: 89 c2 c1 e2 08 c1 e8 08 09 c2 8b 85 e8 fd ff ff 66 89 50 06 89 c7 53 83 c7 08 56 57 68 c4 b3 80 c0 e8 8c 5c ef ff 89 d9 c1 e9 02 <f3> a5 89 d9 83 e1 03 74 02 f3 a4 83 c3 06 8b 95 e8 fd ff ff 0f [ 221.629066] EIP: [<c022d4b1>] hfsplus_find_cat+0x10d/0x151 SS:ESP 0068:c82d199c [ 221.629066] ---[ end trace e417a1d67f0d0066 ]--- Since hfsplus_cat_build_key_uni() returns void and only has one callsite, the check is performed at the callsite. Signed-off-by:
Pekka Enberg <penberg@cs.helsinki.fi> Cc: Roman Zippel <zippel@linux-m68k.org> Signed-off-by:
-
Mike Crowe authored
Check whether the file system was to be mounted read only anyway before warning about changing the mount to read only. Signed-off-by:
Mike Crowe <mac@mcrowe.com> Cc: Roman Zippel <zippel@linux-m68k.org> Signed-off-by:
-
Harvey Harrison authored
Does compile-time byteswapping rather than runtime. Noticed by sparse: fs/befs/super.c:29:6: warning: cast to restricted __le32 fs/befs/super.c:29:6: warning: cast from restricted fs32 fs/befs/super.c:31:11: warning: cast to restricted __be32 fs/befs/super.c:31:11: warning: cast from restricted fs32 fs/befs/super.c:31:11: warning: cast to restricted __be32 fs/befs/super.c:31:11: warning: cast from restricted fs32 fs/befs/super.c:31:11: warning: cast to restricted __be32 fs/befs/super.c:31:11: warning: cast from restricted fs32 fs/befs/super.c:31:11: warning: cast to restricted __be32 fs/befs/super.c:31:11: warning: cast from restricted fs32 fs/befs/super.c:31:11: warning: cast to restricted __be32 fs/befs/super.c:31:11: warning: cast from restricted fs32 fs/befs/super.c:31:11: warning: cast to restricted __be32 fs/befs/super.c:31:11: warning: cast from restricted fs32 fs/befs/linuxvfs.c:811:7: warning: cast to restricted __le32 fs/befs/linuxvfs.c:811:7: warning: cast from restricted fs32 fs/befs/linuxvfs.c:812:7: warning: cast to restricted __be32 fs/befs/linuxvfs.c:812:7: warning: cast from restricted fs32 fs/befs/linuxvfs.c:812:7: warning: cast to restricted __be32 fs/befs/linuxvfs.c:812:7: warning: cast from restricted fs32 fs/befs/linuxvfs.c:812:7: warning: cast to restricted __be32 fs/befs/linuxvfs.c:812:7: warning: cast from restricted fs32 fs/befs/linuxvfs.c:812:7: warning: cast to restricted __be32 fs/befs/linuxvfs.c:812:7: warning: cast from restricted fs32 fs/befs/linuxvfs.c:812:7: warning: cast to restricted __be32 fs/befs/linuxvfs.c:812:7: warning: cast from restricted fs32 fs/befs/linuxvfs.c:812:7: warning: cast to restricted __be32 fs/befs/linuxvfs.c:812:7: warning: cast from restricted fs32 Signed-off-by:
-
Eric Sandeen authored
A very large directory with many read failures (either due to storage problems, or due to invalid size & blocks from corruption) will generate a printk storm as the filesystem continues to try to read all the blocks. This flood of messages can tie up the box until it is complete - which may be a very long time, especially for very large corrupted values. This is fixed by only reporting the corruption once each time we try to read the directory. [akpm@linux-foundation.org: coding-style fixes] Signed-off-by:
Eric Sandeen <sandeen@redhat.com> Signed-off-by:
"Theodore Ts'o" <tytso@mit.edu> Cc: Eugene Teo <eugeneteo@kernel.sg> Signed-off-by:
-
Mingming Cao authored
We could run into ENOSPC error on ext2, even when there is free blocks on the filesystem. The problem is triggered in the case the goal block group has 0 free blocks , and the rest block groups are skipped due to the check of "free_blocks < windowsz/2". Current code could fall back to non reservation allocation to prevent early ENOSPC after examing all the block groups with reservation on , but this code was bypassed if the reservation window is turned off already, which is true in this case. This patch fixed two issues: 1) We don't need to turn off block reservation if the goal block group has 0 free blocks left and continue search for the rest of block groups. Current code the intention is to turn off the block reservation if the goal allocation group has a few (some) free blocks left (not enough for make the desired reservation window),to try to allocation in the goal block group, to get better locality. But if the goal blocks have 0 free blocks, it should leave the block reservation on, and continues search for the next block groups,rather than turn off block reservation completely. 2) we don't need to check the window size if the block reservation is off. The problem was originally found and fixed in ext4. Signed-off-by:
Mingming Cao <cmm@us.ibm.com> Cc: Theodore Ts'o <tytso@mit.edu> Signed-off-by:
-
Adrian Bunk authored
Remove CVS keywords that weren't updated for a long time from comments. Signed-off-by:
-
Rene Herman authored
PnP encodes the resource type directly as its struct resource->flags value which is an unsigned long. Make it so... Signed-off-by:
Rene Herman <rene.herman@gmail.com> Cc: "H. Peter Anvin" <hpa@zytor.com> Acked-by:
-
Adrian Bunk authored
There's no point in printing some ancient version number forever. Signed-off-by:
Adam M Belay <abelay@MIT.EDU> Signed-off-by:
-
Oleg Nesterov authored
echo 3 >> /sys/class/graphics/fbcon/rotate_all, then switch to another console. Result: BUG: unable to handle kernel paging request at ffffc20005d00000 IP: [bitfill_aligned+149/265] bitfill_aligned+0x95/0x109 PGD 7e228067 PUD 7e229067 PMD 7bc1f067 PTE 0 Oops: 0002 [1] SMP CPU 1 Modules linked in: [...a lot...] Pid: 10, comm: events/1 Not tainted 2.6.26.5-45.fc9.x86_64 #1 RIP: 0010:[bitfill_aligned+149/265] [bitfill_aligned+149/265] bitfill_aligned+0x95/0x109 RSP: 0018:ffff81007d811bc8 EFLAGS: 00010216 RAX: ffffc20005d00000 RBX: 0000000000000000 RCX: 0000000000000400 RDX: 0000000000000000 RSI: ffffc20005d00000 RDI: ffffffffffffffff RBP: ffff81007d811be0 R08: 0000000000000400 R09: 0000000000000040 R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000010000 R13: ffffffff811632f0 R14: 0000000000000006 R15: ffff81007cb85400 FS: 0000000000000000(0000) GS:ffff81007e004780(0000) knlGS:0000000000000000 CS: 0010 DS: 0018 ES: 0018 CR0: 000000008005003b CR2: ffffc20005d00000 CR3: 0000000000201000 CR4: 00000000000006e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Process events/1 (pid: 10, threadinfo ffff81007d810000, task ffff81007d808000) Stack: ffff81007c9d75a0 0000000000000000 0000000000000000 ffff81007d811c80 ffffffff81163a61 ffff810000000000 ffffffff8115f9c8 0000001000000000 0000000100aaaaaa 000000007cd0d4a0 fffffd8a00000800 0001000000000000 Call Trace: [cfb_fillrect+523/798] cfb_fillrect+0x20b/0x31e [soft_cursor+416/436] ? soft_cursor+0x1a0/0x1b4 [ccw_clear_margins+205/263] ccw_clear_margins+0xcd/0x107 [fbcon_clear_margins+59/61] fbcon_clear_margins+0x3b/0x3d [fbcon_switch+1291/1466] fbcon_switch+0x50b/0x5ba [redraw_screen+261/481] redraw_screen+0x105/0x1e1 [ccw_cursor+0/1869] ? ccw_cursor+0x0/0x74d [complete_change_console+48/190] complete_change_console+0x30/0xbe [change_console+115/120] change_console+0x73/0x78 [console_callback+0/292] ? console_callback+0x0/0x124 [console_callback+97/292] console_callback+0x61/0x124 [schedule_delayed_work+25/30] ? schedule_delayed_work+0x19/0x1e [run_workqueue+139/282] run_workqueue+0x8b/0x11a [worker_thread+221/238] worker_thread+0xdd/0xee [autoremove_wake_function+0/56] ? autoremove_wake_function+0x0/0x38 [worker_thread+0/238] ? worker_thread+0x0/0xee [kthread+73/118] kthread+0x49/0x76 [child_rip+10/18] child_rip+0xa/0x12 [kthread+0/118] ? kthread+0x0/0x76 [child_rip+0/18] ? child_rip+0x0/0x12 Because fbcon_set_all_vcs()->FBCON_SWAP() uses display->rotate == 0 instead of fbcon_ops->rotate, and vc_resize() has no effect because it is called with new_cols/rows == ->vc_cols/rows. Tested on 2.6.26.5-45.fc9.x86_64, but http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git seems to have the same problem. Signed-off-by:
-
