- 13 Apr, 2009 40 commits
-
-
Bharata B Rao authored
The description about various statistics from memory.stat is not accurate and confusing at times. Correct this along with a few other minor cleanups. Signed-off-by:
Bharata B Rao <bharata@linux.vnet.ibm.com> Acked-by:
Balbir Singh <balbir@linux.vnet.ibm.com> Acked-by:
KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
Yang Hongyang authored
This is the second go through of the old DMA_nBIT_MASK macro,and there're not so many of them left,so I put them into one patch.I hope this is the last round. After this the definition of the old DMA_nBIT_MASK macro could be removed. Signed-off-by:
Yang Hongyang <yanghy@cn.fujitsu.com> Cc: Russell King <rmk@arm.linux.org.uk> Cc: Tony Lindgren <tony@atomide.com> Cc: "David S. Miller" <davem@davemloft.net> Cc: James Bottomley <James.Bottomley@HansenPartnership.com> Cc: Greg KH <greg@kroah.com> Cc: Takashi Iwai <tiwai@suse.de> Signed-off-by:
-
Jan Kara authored
If two writers allocating blocks to file race with each other (e.g. because writepages races with ordinary write or two writepages race with each other), ext2_getblock() can be called on the same inode in parallel. Before we are going to allocate new blocks, we have to recheck the block chain we have obtained so far without holding truncate_mutex. Otherwise we could overwrite the indirect block pointer set by the other writer leading to data loss. The below test program by Ying is able to reproduce the data loss with ext2 on in BRD in a few minutes if the machine is under memory pressure: long kMemSize = 50 << 20; int kPageSize = 4096; int main(int argc, char **argv) { int status; int count = 0; int i; char *fname = "/mnt/test.mmap"; char *mem; unlink(fname); int fd = open(fname, O_CREAT | O_EXCL | O_RDWR, 0600); status = ftruncate(fd, kMemSize); mem = mmap(0, kMemSize, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0); // Fill the memory with 1s. memset(mem, 1, kMemSize); sleep(2); for (i = 0; i < kMemSize; i++) { int byte_good = mem[i] != 0; if (!byte_good && ((i % kPageSize) == 0)) { //printf("%d ", i / kPageSize); count++; } } munmap(mem, kMemSize); close(fd); unlink(fname); if (count > 0) { printf("Running %d bad page\n", count); return 1; } return 0; } Cc: Ying Han <yinghan@google.com> Cc: Nick Piggin <nickpiggin@yahoo.com.au> Signed-off-by:Jan Kara <jack@suse.cz> Cc: Mingming Cao <cmm@us.ibm.com> Cc: <linux-ext4@vger.kernel.org> Signed-off-by:
-
Hugh Dickins authored
SHMEM_MAX_BYTES was derived from the maximum size of its triple-indirect swap vector, forgetting to take the MAX_LFS_FILESIZE limit into account. Never mind 256kB pages, even 8kB pages on 32-bit kernels allowed files to grow slightly bigger than that supposed maximum. Fix this by using the min of both (at build time not run time). And it happens that this calculation is good as far as 8MB pages on 32-bit or 16MB pages on 64-bit: though SHMSWP_MAX_INDEX gets truncated before that, it's truncated to such large numbers that we don't need to care. [akpm@linux-foundation.org: it needs pagemap.h] [akpm@linux-foundation.org: fix sparc64 min() warnings] Signed-off-by:
Hugh Dickins <hugh@veritas.com> Cc: Yuri Tikhonov <yur@emcraft.com> Cc: Paul Mackerras <paulus@samba.org> Cc: Randy Dunlap <randy.dunlap@oracle.com> Signed-off-by:
-
Yuri Tikhonov authored
Fix a division by zero which we have in shmem_truncate_range() and shmem_unuse_inode() when using big PAGE_SIZE values (e.g. 256kB on ppc44x). With 256kB PAGE_SIZE, the ENTRIES_PER_PAGEPAGE constant becomes too large (0x1.0000.0000) on a 32-bit kernel, so this patch just changes its type from 'unsigned long' to 'unsigned long long'. Hugh: reverted its unsigned long longs in shmem_truncate_range() and shmem_getpage(): the pagecache index cannot be more than an unsigned long, so the divisions by zero occurred in unreached code. It's a pity we need any ULL arithmetic here, but I found no pretty way to avoid it. Signed-off-by:
Yuri Tikhonov <yur@emcraft.com> Signed-off-by:
-
Stefan Husemann authored
Support the Intel 854 Chipset in fbdev. We test and use the patch on a Thomson IP1101 IPTV-Box. On the VGA-Port we get a normal signal. Here is the link to the Mambux-Project: http://www.mambux.de Cc: Keith Packard <keithp@keithp.com> Cc: Dave Airlie <airlied@linux.ie> Cc: Krzysztof Helt <krzysztof.h1@poczta.fm> Signed-off-by:
Stefan Husemann <shusemann@googlemail.com> Signed-off-by:
-
Michael Ellerman authored
I'm sure everyone knows this, but I didn't, so I googled it, and found a nice explanation from Linus. Might be worth sticking in Documentation. Signed-off-by:
Michael Ellerman <michael@ellerman.id.au> Signed-off-by:
-
KAMEZAWA Hiroyuki authored
mm/memcontrol.c:318: warning: `mem_cgroup_is_obsolete' defined but not used [akpm@linux-foundation.org: simplify as suggested by Balbir] Signed-off-by:
-
Andi Kleen authored
Impact: cleanup, fix Clean up sys_shutdown() exit path. Factor out common code. Return correct error code instead of always 0 on failure. Signed-off-by:
Andi Kleen <ak@linux.intel.com> Signed-off-by:
-
Geert Uytterhoeven authored
| drivers/misc/eeprom/at25.c:358: warning: assignment from incompatible pointer type Signed-off-by:
Geert Uytterhoeven <geert@linux-m68k.org> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: David Brownell <dbrownell@users.sourceforge.net> Cc: Jean Delvare <khali@linux-fr.org> Signed-off-by:
-
Geert Uytterhoeven authored
| drivers/misc/eeprom/at24.c:508: warning: assignment from incompatible pointer type Signed-off-by:
-
Jan Kara authored
Update information about locking in JBD revoke code. Reported-by: Lin Tan <tammy000@gmail.com>. Signed-off-by:
-
Andy Grover authored
While better than get_user_pages(), the usage of gupf(), especially the return values and the fact that it can potentially only partially pin the range, warranted some documentation. Signed-off-by:
Andy Grover <andy.grover@oracle.com> Cc: Ingo Molnar <mingo@elte.hu> Cc: Nick Piggin <nickpiggin@yahoo.com.au> Signed-off-by:
-
Randy Robertson authored
Change cb6ff208 ("NOMMU: Support XIP on initramfs") seems to have broken booting from initramfs with /sbin/init being a hardlink. It seems like the logic required for XIP on nommu, i.e. ftruncate to reported cpio header file size (body_len) is broken for hardlinks, which have a reported size of 0, and the truncate thus nukes the contents of the file (in my case busybox), making boot impossible and ending with runaway loop modprobe binfmt-0000 - and of course 0000 is not a valid binary format. My fix is to only call ftruncate if size is non-zero which fixes things for me, but I'm not certain whether this will break XIP for those files on nommu systems, although I would guess not. Signed-off-by:
Randy Robertson <rmrobert@vmware.com> Acked-by:
David Howells <dhowells@redhat.com> Acked-by:
Paul Mundt <lethal@linux-sh.org> Acked-by:
H. Peter Anvin <hpa@zytor.com> Signed-off-by:
-
Oleg Nesterov authored
Pointed out by Roland. The bug was recently introduced by me in "forget_original_parent: split out the un-ptrace part", commit 39c626ae. Since that patch we have a window after exit_ptrace() drops tasklist and before forget_original_parent() takes it again. In this window the child can do ptrace(PTRACE_TRACEME) and nobody can untrace this child after that. Change ptrace_traceme() to not attach to the exiting ->real_parent. We don't report the error in this case, we pretend we attach right before ->real_parent calls exit_ptrace() which should untrace us anyway. Signed-off-by:
Oleg Nesterov <oleg@redhat.com> Acked-by:
Roland McGrath <roland@redhat.com> Signed-off-by:
-
Jean Delvare authored
Signed-off-by:
Jean Delvare <khali@linux-fr.org> Acked-by:
Doug Thompson <dougthompson@xmission.com> Signed-off-by:
-
David Howells authored
Do a bit of reformatting on the Unevictable-LRU documentation. Signed-off-by:
Lee Schermerhorn <lee.schermerhorn@hp.com> Cc: Rik van Riel <riel@redhat.com> Cc: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com> Signed-off-by:
-
David Howells authored
Point the UNEVICTABLE_LRU config option at the documentation describing the option. Signed-off-by:
-
Huang Weiyi authored
Remove duplicated #include in drivers/char/sysrq.c. Signed-off-by:
Huang Weiyi <weiyi.huang@gmail.com> Signed-off-by:
-
Joe Perches authored
commit ddb53d48 ("fbdev: remove cyblafb driver") removed drivers/video/cyblafb.c, but not its .h file Signed-off-by:
Joe Perches <joe@perches.com> Cc: Krzysztof Helt <krzysztof.h1@wp.pl> Cc: "Jani Monoses" <jani@ubuntu.com> Signed-off-by:
-
Andrea Righi authored
After the introduction of resource counters hierarchies (28dbc4b6) the prototypes of res_counter_init() and res_counter_charge() have been changed. Keep the documentation consistent with the actual function prototypes. Signed-off-by:
Andrea Righi <righi.andrea@gmail.com> Cc: Paul Menage <menage@google.com> Cc: Pavel Emelyanov <xemul@openvz.org> Cc: Balbir Singh <balbir@linux.vnet.ibm.com> Signed-off-by:
-
David Brownell authored
The "simplify spi_write_then_read()" patch included two regressions from the 2.6.27 behaviors: - The data it wrote out during the (full duplex) read side of the transfer was not zeroed. - It fails completely on half duplex hardware, such as Microwire and most "3-wire" SPI variants. So, revert that patch. A revised version should be submitted at some point, which can get the speedup on standard hardware (full duplex) without breaking on less-capable half-duplex stuff. Signed-off-by:
David Brownell <dbrownell@users.sourceforge.net> Cc: <stable@kernel.org> [2.6.28.x, 2.6.29.x] Signed-off-by:
-
Andi Kleen authored
Impact: (nearly) trivial The patch commit da654b74 Author: Srinivasa Ds <srinivasa@in.ibm.com> Date: Tue Sep 23 15:23:52 2008 +0530 signals: demultiplexing SIGTRAP signal forgot to update the NSIGTRAP define in asm-generic/siginfo.h to the new number of sigtrap subcodes. Nothing in the tree seems to use it, but presumably something in user space might. So update it. Cc: Srinivasa Ds <srinivasa@in.ibm.com> Signed-off-by:
-
Krzysztof Helt authored
Do not allow modes with unsupported pixel depth. Otherwise, one can hang a computer by setting incorrect value with fbset command. Signed-off-by:
Krzysztof Helt <krzysztof.h1@wp.pl> Signed-off-by:
-
Randy Dunlap authored
Fix filemap.c kernel-doc warnings: Warning(mm/filemap.c:575): No description found for parameter 'page' Warning(mm/filemap.c:575): No description found for parameter 'waiter' Signed-off-by:
Randy Dunlap <randy.dunlap@oracle.com> Signed-off-by:
-
Eric Sandeen authored
Include <linux/types.h> in fiemap.h. Sam Ravnborg pointed out that this was missing in this newly-exported header which uses the __u32 and __u64 types. Signed-off-by:
Eric Sandeen <sandeen@redhat.com> Cc: Sam Ravnborg <sam@ravnborg.org> Signed-off-by:
-
Paul Menzel authored
Signed-off-by:
Paul Menzel <paulepanter@users.sourceforge.net> Signed-off-by:
-
Michal Januszewski authored
sisfb incorrectly sets the length of the color fields to 6 bits for PSEUDOCOLOR modes, even though 8 bits are always used per pixel. Fix this by setting the length to 8. Signed-off-by:
Michal Januszewski <spock@gentoo.org> Cc: Thomas Winischhofer <thomas@winischhofer.net> Acked-by:
-
Michal Januszewski authored
sa1100fb incorrectly sets the length of the color fields to 8 bits for PSEUDOCOLOR modes for which only 4 bits are used per pixel. Fix this by setting the length to 4 bits for these modes. Signed-off-by:
-
Michal Januszewski authored
s3fb incorrectly sets the length of the color fields to 6 bits for PSEUDOCOLOR modes, even though 8 or 4 bits are used per pixel. Fix this by setting the length to 8 or 4, respectively. Signed-off-by:
Ondrej Zajicek <santiago@crfreenet.org> Cc: Krzysztof Helt <krzysztof.h1@poczta.fm> Signed-off-by:
-
Geert Uytterhoeven authored
| ipc/mq_sysctl.c:26: warning: 'get_mq' defined but not used Signed-off-by:
Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com> Acked-by:
Serge Hallyn <serue@us.ibm.com> Signed-off-by:
-
Alexey Dobriyan authored
Unused after 20dcae32 aka "[PATCH] aio: remove kioctx from mm_struct". Signed-off-by:
Alexey Dobriyan <adobriyan@gmail.com> Signed-off-by:
-
Dave Anderson authored
When an HFS filesystem is unmounted, it leaks a 2-page bitmap. Also, under extreme memory pressure, it's possible that hfs_releasepage() may use a tree pointer that has not been initialized, and if so, the release request should just be rejected. [akpm@linux-foundation.org: free_pages(0) is legal, remove obvious comment] Signed-off-by:
Dave Anderson <anderson@redhat.com> Tested-by:
Eugene Teo <eugeneteo@kernel.sg> Cc: Roman Zippel <zippel@linux-m68k.org> Signed-off-by:
-
Jonathan Cameron authored
Data sheet at: http://www.sensirion.ch/en/pdf/product_information/Datasheet-humidity-sensor-SHT1x.pdf These sensors communicate over a 2 wire bus running a device specific protocol. The complexity of the driver is mainly due to handling the substantial delays between requesting a reading and the device pulling the data line low to indicate that the data is available. This is handled by an interrupt that is disabled under all other conditions. I wasn't terribly clear on the best way to handle this, so comments on that aspect would be particularly welcome! Interpretation of the temperature depends on knowing the supply voltage. If configured in a board config as a regulator consumer this is obtained from the regulator subsystem. If not it should be provided in the platform data. I've placed this driver in the hwmon subsystem as it is definitely a device that may be used for hardware monitoring and with it's relatively slow response times (up to 120 millisecs to get a reading) a caching strategy certainly seems to make sense! Signed-off-by:
Jonathan Cameron <jic23@cam.ac.uk> Signed-off-by:
-
Matthew Garrett authored
efifb will attempt to ioremap a framebuffer even if its starting address is 0, failing and causing an ugly backtrace in the process. Exit before probing if this is the case. Signed-off-by:
Matthew Garrett <mjg@redhat.com> Acked-by:
Peter Jones <pjones@redhat.com> Cc: Krzysztof Helt <krzysztof.h1@poczta.fm> Signed-off-by:
-
Michal Januszewski authored
uvesafb incorrectly sets the length of the color fields to 6 bits for PSEUDOCOLOR modes, even though 8 bits are always used per pixel. Fix this by setting the length to 8. The switch of the DAC width from the default 6 bits to 8 bits is retained and tracked internally in the driver, but never exposed to userspace. Signed-off-by:
Krzysztof Helt <krzysztof.h1@poczta.fm> Cc: <syrjala@sci.fi> Cc: Geert Uytterhoeven <geert.uytterhoeven@gmail.com> Signed-off-by:
-
Michal Januszewski authored
The documentation about the meaning of the color component bitfield lengths in pseudocolor modes is inconsistent. Fix it, so that it indicates the correct interpretation everywhere, i.e. that 1 << length is the number of palette entries. Signed-off-by:
Geert Uytterhoeven <geert.uytterhoeven@gmail.com> Signed-off-by:
-
Andrea Righi authored
fb_notifier_call_chain() is called with info->lock held, i.e. in do_fb_ioctl() => FBIOPUT_VSCREENINFO => fb_set_var() and the some notifier callbacks, like fbcon_event_notify(), try to re-acquire info->lock again. Remove the lock/unlock_fb_info() in all the framebuffer notifier callbacks' and be sure to always call fb_notifier_call_chain() with info->lock held. Reported-by:
Pavel Roskin <proski@gnu.org> Reported-by:
Eric Miao <eric.y.miao@gmail.com> Signed-off-by:
-
Nikanth Karthikesan authored
init/initramfs.c:520: warning: 'clean_rootfs' defined but not used Signed-off-by:
Nikanth Karthikesan <knikanth@suse.de> Signed-off-by:
-
Huang Weiyi authored
Remove unused #include <version.h> in drivers/hwmon/hp_accel.c. Signed-off-by:
Pavel Machek <pavel@ucw.cz> Signed-off-by:
-
