- 08 May, 2007 40 commits
-
-
Adrian Bunk authored
Signed-off-by:
Adrian Bunk <bunk@stusta.de> Acked-by:
Karsten Keil <kkeil@suse.de> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
Jeff Layton authored
This patch makes it so that simple_fill_super and get_sb_pseudo assign their root inodes to be number 1. It also fixes up a couple of callers of simple_fill_super that were passing in files arrays that had an index at number 1, and adds a warning for any caller that sends in such an array. It would have been nice to have made it so that it wasn't possible to make such a collision, but some callers need to be able to control what inode number their entries get, so I think this is the best that can be done. Signed-off-by:
Jeff Layton <jlayton@redhat.com> Cc: Christoph Hellwig <hch@lst.de> Cc: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by:
-
Jeff Layton authored
The problems are: - on filesystems w/o permanent inode numbers, i_ino values can be larger than 32 bits, which can cause problems for some 32 bit userspace programs on a 64 bit kernel. We can't do anything for filesystems that have actual >32-bit inode numbers, but on filesystems that generate i_ino values on the fly, we should try to have them fit in 32 bits. We could trivially fix this by making the static counters in new_inode and iunique 32 bits, but... - many filesystems call new_inode and assume that the i_ino values they are given are unique. They are not guaranteed to be so, since the static counter can wrap. This problem is exacerbated by the fix for #1. - after allocating a new inode, some filesystems call iunique to try to get a unique i_ino value, but they don't actually add their inodes to the hashtable, and so they're still not guaranteed to be unique if that counter wraps. This patch set takes the simpler approach of simply using iunique and hashing the inodes afterward. Christoph H. previously mentioned that he thought that this approach may slow down lookups for filesystems that currently hash their inodes. The questions are: 1) how much would this slow down lookups for these filesystems? 2) is it enough to justify adding more infrastructure to avoid it? What might be best is to start with this approach and then only move to using IDR or some other scheme if these extra inodes in the hashtable prove to be problematic. I've done some cursory testing with this patch and the overhead of hashing and unhashing the inodes with pipefs is pretty low -- just a few seconds of system time added on to the creation and destruction of 10 million pipes (very similar to the overhead that the IDR approach would add). The hard thing to measure is what effect this has on other filesystems. I'm open to ways to try and gauge this. Again, I've only converted pipefs as an example. If this approach is acceptable then I'll start work on patches to convert other filesystems. With a pretty-much-worst-case microbenchmark provided by Eric Dumazet <dada1@cosmosbay.com>: hashing patch (pipebench): sys 1m15.329s sys 1m16.249s sys 1m17.169s unpatched (pipebench): sys 1m9.836s sys 1m12.541s sys 1m14.153s Which works out to 1.05642174294555027017. So ~5-6% slowdown. This patch: When a 32-bit program that was not compiled with large file offsets does a stat and gets a st_ino value back that won't fit in the 32 bit field, glibc (correctly) generates an EOVERFLOW error. We can't do anything about fs's with larger permanent inode numbers, but when we generate them on the fly, we ought to try and have them fit within a 32 bit field. This patch takes the first step toward this by making the static counters in these two functions be 32 bits. [jlayton@redhat.com: mention that it's only the case for 32bit, non-LFS stat] Signed-off-by:
-
Jan Nikitenko authored
Here is a driver for the Alchemy au1550 PSC (Programmable Serial Controller) in SPI master mode. It supports dma transfers using the Alchemy descriptor based dma controller for 4-8 bits per word SPI transfers. For 9-24 bits per word transfers, pio irq based mode is used to avoid setup of dma channels from scratch on each number of bits per word change. Tested with au1550; this may also work on other MIPS Alchemy cpus, like au1200/au1210/au1250. Used extensively with SD card connected via SPI; this handles 8.1MHz SPI clock transfers using dma without any problem (the highest SPI clock freq possible with au1550 running on 324MHz). The driver supports sharing of SPI bus by multiple devices. All features of Alchemy SPI mode are supported (all SPI modes, msb/lsb first, bits per word in 4-24 range). As the SPI clock of the controller depends on main input clock that shall be configured externally, platform data structure for au1550 SPI controller driver contains mainclk_hz attribute to define the input clock rate. From this value, dividers of the controller for SPI clock are set up for required frequency. Signed-off-by:
Jan Nikitenko <jan.nikitenko@gmail.com> Whitespace and section fixups. Remove partial workaround for platform setup bug in dma_mask setup; it couldn't work with multiple controllers. Signed-off-by:
David Brownell <dbrownell@users.sourceforge.net> Signed-off-by:
-
David Brownell authored
Various documentation updates for the SPI infrastructure, to clarify things that may not have been clear, to cope with lack of editing, and fix omissions. Also, plug SPI into the kernel-api DocBook template, and fix all the resulting glitches in document generation. Signed-off-by:
-
Andrea Paterniani authored
Add a filesystem API for <linux/spi/spi.h> stack. The initial version of this interface is purely synchronous. dbrownell@users.sourceforge.net: Cleaned up, bugfixed; much simplified; added preliminary documentation. Works with mdev given CONFIG_SYSFS_DEPRECATED; and presumably udev. Updated SPI_IOC_MESSAGE ioctl to full spi_message semantics, supporting groups of one or more transfers (each of which may be full duplex if desired). This is marked as EXPERIMENTAL with an explicit disclaimer that the API (notably the ioctls) is subject to change. Signed-off-by:
Andrea Paterniani <a.paterniani@swapp-eng.it> Signed-off-by:
-
David Brownell authored
Simplify the spi_butterfly driver by removing incomplete/unused support for the second SPI bus, implemented by the USI controller. This should make this a clearer example of how to write a parport bitbang driver. Signed-off-by:
-
Josh Boyer authored
Remove some obviously old interrupt disable/enable code that has been commented out. Signed-off-by:
Josh Boyer <jwboyer@gmail.com> Signed-off-by:
-
Matthias Kaehlcke authored
The misc character device driver uses a semaphore as mutex. Use the mutex API instead of the (binary) semaphore. Signed-off-by:
Matthias Kaehlcke <matthias.kaehlcke@gmail.com> Signed-off-by:
-
Matthias Kaehlcke authored
The hdaps driver uses a semaphore as mutex. Use the mutex API instead of the (binary) semaphore. Signed-off-by:
-
Matthias Kaehlcke authored
The TPM driver uses two semaphores as mutexes. Use the mutex API instead of the (binary) semaphores. Signed-off-by:
-
Matthias Kaehlcke authored
The RocketPort driver uses a semaphore as mutex. Use the mutex API instead of the (binary) semaphore. Signed-off-by:
-
Stas Sergeev authored
Other symbols of the hrtimers API are already exported. Signed-off-by:
Stas Sergeev <stsp@aknet.ru> Acked-by:
Thomas Gleixner <tglx@linutronix.de> Cc: Ingo Molnar <mingo@elte.hu> Signed-off-by:
-
Alexey Kuznetsov authored
When elf loader fails to map executable (due to memory shortage or because binary is malformed), it can return 0. Normally, this is invisible because process is killed with SIGKILL and it never returns to user space. But if exec() is called from kernel thread (hotplug, whatever) consequences are more interesting and vary depending on architecture. i386. Nothing especially interesting, execve() just returns with "success" :-) x86_64. Fake zero frame is used on way to caller, RSP/RIP are loaded with zeros, ergo... double fault. ia64. Similar to i386, but r32...r95 are corrupted. Sometimes it oopses due to return to zero PC, sometimes it sees NaT in rXX and oopses due to NaT consumption. Signed-off-by:Alexey Kuznetsov <alexey@openvz.org> Signed-off-by:
Kirill Korotaev <dev@openvz.org> Signed-off-by:
Pavel Emelianov <xemul@openvz.org> Signed-off-by:
-
Sergei Shtylyov authored
Fix misnamed fields of 'struct clock_event_device' in the kernel-doc comment. Convert the acronyms to uppercase, while at it... Signed-off-by:
Sergei Shtylyov <sshtylyov@ru.mvista.com> Acked-by:
-
Randy Dunlap authored
librs docbook typo fixes. Signed-off-by:
Randy Dunlap <randy.dunlap@oracle.com> Signed-off-by:
-
Mike Frysinger authored
Signed-off-by:
Mike Frysinger <vapier@gentoo.org> Acked-by:
Jan Kara <jack@ucw.cz> Cc: David Woodhouse <dwmw2@infradead.org> Signed-off-by:
-
David Woodhouse authored
Add taskstats.h to include/linux/Kbuild, make headers_install would then pickup taskstats.h. This needs to be done as taskstats.h is a user interface header. Signed-off-by:
Balbir Singh <balbir@linux.vnet.ibm.com> Signed-off-by:
David Woodhouse <dwmw2@infradead.org> Cc: Don Zickus <dzickus@redhat.com> Signed-off-by:
-
Paul Fulghum authored
Change synclink_gt driver to use dynamic tty device registration. Signed-off-by:
Paul Fulghum <paulkf@microgate.com> Signed-off-by:
-
Jiri Slaby authored
Add sensable phantom driver Signed-off-by:
Jiri Slaby <jirislaby@gmail.com> Signed-off-by:
-
David Rientjes authored
You currently cannot remove all cpus or mems from cpus_allowed or mems_allowed of a cpuset. We now allow both if there are no attached tasks. Acked-by:
Paul Jackson <pj@sgi.com> Cc: Christoph Lameter <clameter@engr.sgi.com> Signed-off-by:
Paul Menage <menage@google.com> Signed-off-by:
David Rientjes <rientjes@google.com> Signed-off-by:
-
Akinobu Mita authored
Cleanup using simple_read_from_buffer() in procfs. Signed-off-by:
Akinobu Mita <akinobu.mita@gmail.com> Signed-off-by:
-
Simon Horman authored
There is a new list for kexec/kdump discussion. Signed-off-by:
Simon Horman <horms@verge.net.au> Acked-by:
Eric W. Biederman <ebiederm@xmission.com> Signed-off-by:
-
dann frazier authored
I noticed that the moxa input checking security bug described by CVE-2005-0504 appears to remain unfixed upstream. The issue is described here: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-0504 Debian has been shipping the following patch from Andres Salomon. (akpm: it's a privileged operation) Signed-off-by:
dann frazier <dannf@hp.com> Signed-off-by:
Andres Salomon <dilinger@debian.org> Signed-off-by:
-
Andreas Schwab authored
Don't clobber error from sys_ioctl in HDIO_GETGEO compat wrapper. Signed-off-by:
Andreas Schwab <schwab@suse.de> Signed-off-by:
-
Zach Carter authored
Signed-off-by:
Zach Carter <linux@zachcarter.com> Cc: Bart Samwel <bart@samwel.tk> Signed-off-by:
-
Michal Piotrowski authored
Remove duplicate 'U' entry -- fix mis-merge. Signed-off-by:
Michal Piotrowski <michal.k.k.piotrowski@gmail.com> Signed-off-by:
-
Stephen Mollett authored
It appears that a minor thinko occurred in udf_rmdir and the (already-cleared) link count on the directory that is being removed was being decremented instead of the link count on its parent directory. This gives rise to lots of kernel messages similar to: UDF-fs warning (device loop1): udf_rmdir: empty directory has nlink != 2 (8) when removing directory trees. No other ill effects have been observed but I guess it could theoretically result in the link count overflowing on a very long-lived, much modified directory. Signed-off-by:
Stephen Mollett <molletts@yahoo.com> Cc: Dave Hansen <haveblue@us.ibm.com> Cc: Jan Kara <jack@ucw.cz> Cc: <stable@kernel.org> Signed-off-by:
-
OGAWA Hirofumi authored
If you compile and run the below test case in an msdos or vfat directory on an x86-64 system with -m32 you'll get garbage in the kernel_dirent struct followed by a SIGSEGV. The patch fixes this. Reported and initial fix by Bart Oldeman #include <sys/types.h> #include <sys/ioctl.h> #include <dirent.h> #include <stdio.h> #include <unistd.h> #include <fcntl.h> struct kernel_dirent { long d_ino; long d_off; unsigned short d_reclen; char d_name[256]; /* We must not include limits.h! */ }; #define VFAT_IOCTL_READDIR_BOTH _IOR('r', 1, struct kernel_dirent [2]) #define VFAT_IOCTL_READDIR_SHORT _IOR('r', 2, struct kernel_dirent [2]) int main(void) { int fd = open(".", O_RDONLY); struct kernel_dirent de[2]; while (1) { int i = ioctl(fd, VFAT_IOCTL_READDIR_BOTH, (long)de); if (i == -1) break; if (de[0].d_reclen == 0) break; printf("SFN: reclen=%2d off=%d ino=%d, %-12s", de[0].d_reclen, de[0].d_off, de[0].d_ino, de[0].d_name); if (de[1].d_reclen) printf("\tLFN: reclen=%2d off=%d ino=%d, %s", de[1].d_reclen, de[1].d_off, de[1].d_ino, de[1].d_name); printf("\n"); } return 0; } Signed-off-by:Bart Oldeman <bartoldeman@users.sourceforge.net> Signed-off-by:
OGAWA Hirofumi <hirofumi@mail.parknet.co.jp> Cc: <stable@kernel.org> Signed-off-by:
-
Guennadi Liakhovetski authored
dma_declare_coherent_memory() allocates a bitmap 1 bit per page, it calculates the bitmap size based on size of long, but allocates bytes... Thanks to James Bottomley for clarifications and corrections. Signed-off-by:
G. Liakhovetski <g.liakhovetski@gmx.de> Acked-by:
James Bottomley <James.Bottomley@SteelEye.com> Cc: Mikael Starvik <starvik@axis.com> Cc: Andi Kleen <ak@suse.de> Signed-off-by:
-
akpm@linux-foundation.org authored
Cc: Matt Reimer <mreimer@vpop.net> [akpm@linux-foundation.org: kconfig update] Signed-off-by:
Matt Reimer <mreimer@vpop.net> Signed-off-by:
Evgeniy Polyakov <johnpol@2ka.mipt.ru> Signed-off-by:
-
Evgeniy Polyakov authored
Signed-off-by:
-
Evgeniy Polyakov authored
Signed-off-by:
-
Alistair John Strachan authored
Several people have observed that perhaps LOG_BUF_SHIFT should be in a more obvious place than under DEBUG_KERNEL. Under some circumstances (such as the PARISC architecture), DEBUG_KERNEL can increase kernel size, which is an undesirable trade off for something as trivial as increasing the kernel log buffer size. Instead, move LOG_BUF_SHIFT into "General Setup", so that people are more likely to be able to change it such a circumstance that the default buffer size is insufficient. Signed-off-by:
Alistair John Strachan <s0348365@sms.ed.ac.uk> Acked-by:
-
Randy Dunlap authored
Eliminate 19439 (!!) sparse warnings like: include/linux/mm.h:321:22: warning: constant 0xffff810000000000 is so big it is unsigned long Eliminate 56 sparse warnings like: arch/x86_64/kernel/setup.c:248:16: warning: constant 0xffffffff80000000 is so big it is unsigned long Eliminate 5 sparse warnings like: arch/x86_64/kernel/module.c:49:13: warning: constant 0xfffffffffff00000 is so big it is unsigned long Eliminate 23 sparse warnings like: arch/x86_64/mm/init.c:551:37: warning: constant 0xffffc20000000000 is so big it is unsigned long Eliminate 6 sparse warnings like: arch/x86_64/kernel/module.c:49:13: warning: constant 0xffffffff88000000 is so big it is unsigned long Eliminate 23 sparse warnings like: arch/x86_64/mm/init.c:552:6: warning: constant 0xffffe1ffffffffff is so big it is unsigned long Eliminate 3 sparse warnings like: arch/x86_64/kernel/e820.c:186:17: warning: constant 0x3fffffffffff is so big it is long Signed-off-by:
-
Randy Dunlap authored
Make a global linux/const.h header file instead of having multiple, per-arch files, and convert current users of asm/const.h to use linux/const.h. Built on x86_64 and sparc64. [akpm@linux-foundation.org: fix include/asm-x86_64/Kbuild] Signed-off-by:
David S. Miller <davem@davemloft.net> Cc: Andi Kleen <ak@suse.de> Signed-off-by:
-
Parag Warudkar authored
flush_scheduled_work() can sleep, and we're calling it under spinlock. AFAICS, moving flush_scheduled_work before spin_lock() should not cause any problems. Reason being - The only thing that can race against tpm_release is tpm_open (tpm_release is called when last reference to the file is closed and only thing that can happen after that is tpm_open??) and tpm_open acquires driver_lock and more over it bails out with EBUSY if chip->num_opens is greater than 0. I also moved chip->num_pending-- to after deleting timer and setting data pending as it looks more correct for the paranoid although it probably doesn't matter as it is guarded by driver_lock. None the less this change should not cause problems. While I was at it I noticed a missing NULL check in tpm_register_hardware which is fixed with this patch as well. Signed-off-by:
Parag Warudkar <parag.warudkar@gmail.com> Signed-off-by:
-
Jesper Juhl authored
commit 226a6b84 renumbered Chapter 11 in Documentation/CodingStyle to Chapter 12, but it didn't update the reference to that chapter further down in the file. This patch corrects the chapter reference. Signed-off-by:
Jesper Juhl <jesper.juhl@gmail.com> Signed-off-by:
-
Jan Kara authored
Propagate flags such as S_APPEND, S_IMMUTABLE, etc. from i_flags into ext2-specific i_flags. Hence, when someone sets these flags via a different interface than ioctl, they are stored correctly. Signed-off-by:
Jan Kara <jack@suse.cz> Signed-off-by:
-
OGAWA Hirofumi authored
It seems that the recent Windows changed specification, and it's undocumented. Windows doesn't update ->free_clusters correctly. This patch doesn't use ->free_clusters by default. (instead, add "usefree" for forcing to use it) Signed-off-by:
-
