summaryrefslogtreecommitdiffstats
path: root/drivers/char
AgeCommit message (Collapse)Author
2012-05-17tty: fix warning in synclink driverAndres Salomon
commit dc98d9650891661a20842a8eef9e76536046d897 upstream. During builds I see the following warning - CC [M] drivers/char/pcmcia/synclink_cs.o drivers/char/pcmcia/synclink_cs.c:2194: warning: ‘mgslpc_get_icount’ defined but not used The function is a callback meant to be assigned to get_icount (added during 0587102cf). Fix accordingly. Signed-off-by: Andres Salomon <dilinger@queued.net> Acked-by: Alan Cox <alan@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2012-05-17nozomi: Fix warning from the previous TIOCGCOUNT changesAlan Cox
commit 68e29655cc51761d60d5f27b2738816a5b13e415 upstream. Just remove a now unused variable Signed-off-by: Alan Cox <alan@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2012-05-17tty: icount changeover for other main devicesAlan Cox
commit 0587102cf9f427c185bfdeb2cef41e13ee0264b1 upstream. Again basically cut and paste Convert the main driver set to use the hooks for GICOUNT Signed-off-by: Alan Cox <alan@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2012-05-17tty: Make tiocgicount a handlerAlan Cox
commit d281da7ff6f70efca0553c288bb883e8605b3862 upstream. Dan Rosenberg noted that various drivers return the struct with uncleared fields. Instead of spending forever trying to stomp all the drivers that get it wrong (and every new driver) do the job in one place. This first patch adds the needed operations and hooks them up, including the needed USB midlayer and serial core plumbing. Signed-off-by: Alan Cox <alan@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2012-05-17net: Compute protocol sequence numbers and fragment IDs using MD5.David S. Miller
commit 6e5714eaf77d79ae1c8b47e3e040ff5411b717ec upstream. Computers have become a lot faster since we compromised on the partial MD4 hash which we use currently for performance reasons. MD5 is a much safer choice, and is inline with both RFC1948 and other ISS generators (OpenBSD, Solaris, etc.) Furthermore, only having 24-bits of the sequence number be truly unpredictable is a very serious limitation. So the periodic regeneration and 8-bit counter have been removed. We compute and use a full 32-bit sequence number. For ipv6, DCCP was found to use a 32-bit truncated initial sequence number (it needs 43-bits) and that is fixed here as well. Reported-by: Dan Kaminsky <dan@doxpara.com> Tested-by: Willy Tarreau <w@1wt.eu> Signed-off-by: David S. Miller <davem@davemloft.net> [PG: diffstat vs. 6e5714 differs, since no secure_ipv6_id to delete in 34] Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2012-05-17TTY: ldisc, do not close until there are readersJiri Slaby
commit 92f6fa09bd453ffe3351fa1f1377a1b7cfa911e6 upstream. We restored tty_ldisc_wait_idle in 100eeae2c5c (TTY: restore tty_ldisc_wait_idle). We used it in the ldisc changing path to fix the case where there are tasks in n_tty_read waiting for data and somebody tries to change ldisc. Similar to the case above, there may be also tasks waiting in n_tty_read while hangup is performed. As 65b770468e98 (tty-ldisc: turn ldisc user count into a proper refcount) removed the wait-until-idle from all paths, hangup path won't wait for them to disappear either now. So add it back even to the hangup path. There is a difference, we need uninterruptible sleep as there is obviously HUP signal pending. So tty_ldisc_wait_idle now sleeps without possibility to be interrupted. This is what original tty_ldisc_wait_idle did. After the wait idle reintroduction (100eeae2c5c), we have had interruptible sleeps for the ldisc changing path. But as there is a 5s timeout anyway, we don't allow it to be interrupted from now on. It's not worth the added complexity of deciding what kind of sleep we want. Before 65b770468e98 tty_ldisc_release was called also from tty_ldisc_release. It is called from tty_release, so I don't think we need to restore that one. This is nicely reproducible after constifying the timing when drivers/tty/n_tty.c is patched as follows ("TTY: ntty, add one more sanity check" patch is needed to actually see it explode): %% -1548,6 +1549,7 @@ static int n_tty_open(struct tty_struct *tty) /* These are ugly. Currently a malloc failure here can panic */ if (!tty->read_buf) { + msleep(100); tty->read_buf = kzalloc(N_TTY_BUF_SIZE, GFP_KERNEL); if (!tty->read_buf) return -ENOMEM; %% -1785,6 +1788,7 @@ do_it_again: break; } timeout = schedule_timeout(timeout); + msleep(20); continue; } __set_current_state(TASK_RUNNING); ===== With a process: ===== while (1) { int fd = open(argv[1], O_RDWR); read(fd, buf, sizeof(buf)); close(fd); } ===== and its child: ===== setsid(); while (1) { int fd = open(tty, O_RDWR|O_NOCTTY); ioctl(fd, TIOCSCTTY, 1); vhangup(); close(fd); usleep(100 * (10 + random() % 1000)); } ===== EOF ===== References: https://bugzilla.novell.com/show_bug.cgi?id=693374 References: https://bugzilla.novell.com/show_bug.cgi?id=694509 Signed-off-by: Jiri Slaby <jslaby@suse.cz> Cc: Alan Cox <alan@lxorguk.ukuu.org.uk> Cc: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> [PG: account for char --> tty file rename post 2.6.34] Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2012-05-17i8k: Avoid lahf in 64-bit codeLuca Tettamanti
commit bc1f419c76a2d6450413ce4349f4e4a07be011d5 upstream. i8k uses lahf to read the flag register in 64-bit code; early x86-64 CPUs, however, lack this instruction and we get an invalid opcode exception at runtime. Use pushf to load the flag register into the stack instead. Signed-off-by: Luca Tettamanti <kronos.it@gmail.com> Reported-by: Jeff Rickman <jrickman@myamigos.us> Tested-by: Jeff Rickman <jrickman@myamigos.us> Tested-by: Harry G McGavran Jr <w5pny@arrl.net> Cc: Massimo Dal Zotto <dz@debian.org> Signed-off-by: Jean Delvare <khali@linux-fr.org> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2012-03-14Fix gcc 4.5.1 miscompiling drivers/char/i8k.c (again)Jim Bos
commit 22d3243de86bc92d874abb7c5b185d5c47aba323 upstream. The fix in commit 6b4e81db2552 ("i8k: Tell gcc that *regs gets clobbered") to work around the gcc miscompiling i8k.c to add "+m (*regs)" caused register pressure problems and a build failure. Changing the 'asm' statement to 'asm volatile' instead should prevent that and works around the gcc bug as well, so we can remove the "+m". [ Background on the gcc bug: a memory clobber fails to mark the function the asm resides in as non-pure (aka "__attribute__((const))"), so if the function does nothing else that triggers the non-pure logic, gcc will think that that function has no side effects at all. As a result, callers will be mis-compiled. Adding the "+m" made gcc see that it's not a pure function, and so does "asm volatile". The problem was never really the need to mark "*regs" as changed, since the memory clobber did that part - the problem was just a bug in the gcc "pure" function analysis - Linus ] Signed-off-by: Jim Bos <jim876@xs4all.nl> Acked-by: Jakub Jelinek <jakub@redhat.com> Cc: Andi Kleen <andi@firstfloor.org> Cc: Andreas Schwab <schwab@linux-m68k.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2012-03-14i8k: Tell gcc that *regs gets clobberedJim Bos
commit 6b4e81db2552bad04100e7d5ddeed7e848f53b48 upstream. More recent GCC caused the i8k driver to stop working, on Slackware compiler was upgraded from gcc-4.4.4 to gcc-4.5.1 after which it didn't work anymore, meaning the driver didn't load or gave total nonsensical output. As it turned out the asm(..) statement forgot to mention it modifies the *regs variable. Credits to Andi Kleen and Andreas Schwab for providing the fix. Signed-off-by: Jim Bos <jim876@xs4all.nl> Cc: Andi Kleen <andi@firstfloor.org> Cc: Andreas Schwab <schwab@linux-m68k.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2012-03-14char/tpm: Fix unitialized usage of data bufferPeter Huewe
commit 1309d7afbed112f0e8e90be9af975550caa0076b upstream. This patch fixes information leakage to the userspace by initializing the data buffer to zero. Reported-by: Peter Huewe <huewe.external@infineon.com> Signed-off-by: Peter Huewe <huewe.external@infineon.com> Signed-off-by: Marcel Selhorst <m.selhorst@sirrix.com> [ Also removed the silly "* sizeof(u8)". If that isn't 1, we have way deeper problems than a simple multiplication can fix. - Linus ] Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2011-06-26agp: fix OOM and buffer overflowVasiliy Kulikov
commit b522f02184b413955f3bc952e3776ce41edc6355 upstream. page_count is copied from userspace. agp_allocate_memory() tries to check whether this number is too big, but doesn't take into account the wrap case. Also agp_create_user_memory() doesn't check whether alloc_size is calculated from num_agp_pages variable without overflow. This may lead to allocation of too small buffer with following buffer overflow. Another problem in agp code is not addressed in the patch - kernel memory exhaustion (AGPIOC_RESERVE and AGPIOC_ALLOCATE ioctls). It is not checked whether requested pid is a pid of the caller (no check in agpioc_reserve_wrap()). Each allocation is limited to 16KB, though, there is no per-process limit. This might lead to OOM situation, which is not even solved in case of the caller death by OOM killer - the memory is allocated for another (faked) process. Signed-off-by: Vasiliy Kulikov <segoon@openwall.com> Signed-off-by: Dave Airlie <airlied@redhat.com> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2011-06-26agp: fix arbitrary kernel memory writesVasiliy Kulikov
commit 194b3da873fd334ef183806db751473512af29ce upstream. pg_start is copied from userspace on AGPIOC_BIND and AGPIOC_UNBIND ioctl cmds of agp_ioctl() and passed to agpioc_bind_wrap(). As said in the comment, (pg_start + mem->page_count) may wrap in case of AGPIOC_BIND, and it is not checked at all in case of AGPIOC_UNBIND. As a result, user with sufficient privileges (usually "video" group) may generate either local DoS or privilege escalation. Signed-off-by: Vasiliy Kulikov <segoon@openwall.com> Signed-off-by: Dave Airlie <airlied@redhat.com> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2011-06-26TPM: Long default timeout fixRajiv Andrade
commit c4ff4b829ef9e6353c0b133b7adb564a68054979 upstream. If duration variable value is 0 at this point, it's because chip->vendor.duration wasn't filled by tpm_get_timeouts() yet. This patch sets then the lowest timeout just to give enough time for tpm_get_timeouts() to further succeed. This fix avoids long boot times in case another entity attempts to send commands to the TPM when the TPM isn't accessible. Signed-off-by: Rajiv Andrade <srajiv@linux.vnet.ibm.com> Signed-off-by: James Morris <jmorris@namei.org> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2011-04-17TTY: don't allow reopen when ldisc is changingJiri Slaby
commit e2efafbf139d2bfdfe96f2901f03189fecd172e4 upstream There are many WARNINGs like the following reported nowadays: WARNING: at drivers/tty/tty_io.c:1331 tty_open+0x2a2/0x49a() Hardware name: Latitude E6500 Modules linked in: Pid: 1207, comm: plymouthd Not tainted 2.6.37-rc3-mmotm1123 #3 Call Trace: [<ffffffff8103b189>] warn_slowpath_common+0x80/0x98 [<ffffffff8103b1b6>] warn_slowpath_null+0x15/0x17 [<ffffffff8128a3ab>] tty_open+0x2a2/0x49a [<ffffffff810fd53f>] chrdev_open+0x11d/0x146 ... This means tty_reopen is called without TTY_LDISC set. For further considerations, note tty_lock is held in tty_open. TTY_LDISC is cleared in: 1) __tty_hangup from tty_ldisc_hangup to tty_ldisc_enable. During this section tty_lock is held. However tty_lock is temporarily dropped in the middle of the function by tty_ldisc_hangup. 2) tty_release via tty_ldisc_release till the end of tty existence. If tty->count <= 1, tty_lock is taken, TTY_CLOSING bit set and then tty_ldisc_release called. tty_reopen checks TTY_CLOSING before checking TTY_LDISC. 3) tty_set_ldisc from tty_ldisc_halt to tty_ldisc_enable. We: * take tty_lock, set TTY_LDISC_CHANGING, put tty_lock * call tty_ldisc_halt (clear TTY_LDISC), tty_lock is _not_ held * do some other work * take tty_lock, call tty_ldisc_enable (set TTY_LDISC), put tty_lock I cannot see how 2) can be a problem, as there I see no race. OTOH, 1) and 3) can happen without problems. This patch the case 3) by checking TTY_LDISC_CHANGING along with TTY_CLOSING in tty_reopen. 1) will be fixed in the following patch. Nicely reproducible with two processes: while (1) { fd = open("/dev/ttyS1", O_RDWR); if (fd < 0) { warn("open"); continue; } close(fd); } -------- while (1) { fd = open("/dev/ttyS1", O_RDWR); ld1 = 0; ld2 = 2; while (1) { ioctl(fd, TIOCSETD, &ld1); ioctl(fd, TIOCSETD, &ld2); } close(fd); } Signed-off-by: Jiri Slaby <jslaby@suse.cz> Reported-by: <Valdis.Kletnieks@vt.edu> Cc: Kyle McMartin <kyle@mcmartin.ca> Cc: Alan Cox <alan@lxorguk.ukuu.org.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2011-04-17TTY: ldisc, fix open flag handlingJiri Slaby
commit 7f90cfc505d613f4faf096e0d84ffe99208057d9 upstream. When a concrete ldisc open fails in tty_ldisc_open, we forget to clear TTY_LDISC_OPEN. This causes a false warning on the next ldisc open: WARNING: at drivers/char/tty_ldisc.c:445 tty_ldisc_open+0x26/0x38() Hardware name: System Product Name Modules linked in: ... Pid: 5251, comm: a.out Tainted: G W 2.6.32-5-686 #1 Call Trace: [<c1030321>] ? warn_slowpath_common+0x5e/0x8a [<c1030357>] ? warn_slowpath_null+0xa/0xc [<c119311c>] ? tty_ldisc_open+0x26/0x38 [<c11936c5>] ? tty_set_ldisc+0x218/0x304 ... So clear the bit when failing... Introduced in c65c9bc3efa (tty: rewrite the ldisc locking) back in 2.6.31-rc1. Signed-off-by: Jiri Slaby <jslaby@suse.cz> Cc: Alan Cox <alan@linux.intel.com> Reported-by: Sergey Lapin <slapin@ossfans.org> Tested-by: Sergey Lapin <slapin@ossfans.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2011-04-17tty_ldisc: Fix BUG() on hangupPhilippe Rétornaz
commit 1c95ba1e1de7edffc0c4e275e147f1a9eb1f81ae upstream. A kernel BUG when bluetooth rfcomm connection drop while the associated serial port is open is sometime triggered. It seems that the line discipline can disappear between the tty_ldisc_put and tty_ldisc_get. This patch fall back to the N_TTY line discipline if the previous discipline is not available anymore. Signed-off-by: Philippe Retornaz <philippe.retornaz@epfl.ch> Acked-by: Alan Cox <alan@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2011-04-17TTY: restore tty_ldisc_wait_idleJiri Slaby
commit 100eeae2c5ce23b4db93ff320ee330ef1d740151 upstream. It was removed in 65b770468e98 (tty-ldisc: turn ldisc user count into a proper refcount), but we need to wait for last user to quit the ldisc before we close it in tty_set_ldisc. Otherwise weird things start to happen. There might be processes waiting in tty_read->n_tty_read on tty->read_wait for input to appear and at that moment, a change of ldisc is fatal. n_tty_close is called, it frees read_buf and the waiting process is still in the middle of reading and goes nuts after it is woken. Previously we prevented close to happen when others are in ldisc ops by tty_ldisc_wait_idle in tty_set_ldisc. But the commit above removed that. So revoke the change and test whether there is 1 user (=we), and allow the close then. We can do that without ldisc/tty locks, because nobody else can open the device due to TTY_LDISC_CHANGING bit set, so we in fact wait for everybody to leave. I don't understand why tty_ldisc_lock would be needed either when the counter is an atomic variable, so this is a lockless tty_ldisc_wait_idle. On the other hand, if we fail to wait (timeout or signal), we have to reenable the halted ldiscs, so we take ldisc lock and reuse the setup path at the end of tty_set_ldisc. Signed-off-by: Jiri Slaby <jslaby@suse.cz> Acked-by: Linus Torvalds <torvalds@linux-foundation.org> Tested-by: Sebastian Andrzej Siewior <bigeasy@breakpoint.cc> Signed-off-by: Andi Kleen <ak@linux.intel.com> LKML-Reference: <20101031104136.GA511@Chamillionaire.breakpoint.cc> LKML-Reference: <1287669539-22644-1-git-send-email-jslaby@suse.cz> Cc: Alan Cox <alan@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2011-04-17tty: prevent DOS in the flush_to_ldiscJiri Olsa
commit e045fec48970df84647a47930fcf7a22ff7229c0 upstream. There's a small window inside the flush_to_ldisc function, where the tty is unlocked and calling ldisc's receive_buf function. If in this window new buffer is added to the tty, the processing might never leave the flush_to_ldisc function. This scenario will hog the cpu, causing other tty processing starving, and making it impossible to interface the computer via tty. I was able to exploit this via pty interface by sending only control characters to the master input, causing the flush_to_ldisc to be scheduled, but never actually generate any output. To reproduce, please run multiple instances of following code. - SNIP #define _XOPEN_SOURCE #include <stdlib.h> #include <stdio.h> #include <sys/types.h> #include <sys/stat.h> #include <fcntl.h> int main(int argc, char **argv) { int i, slave, master = getpt(); char buf[8192]; sprintf(buf, "%s", ptsname(master)); grantpt(master); unlockpt(master); slave = open(buf, O_RDWR); if (slave < 0) { perror("open slave failed"); return 1; } for(i = 0; i < sizeof(buf); i++) buf[i] = rand() % 32; while(1) { write(master, buf, sizeof(buf)); } return 0; } - SNIP The attached patch (based on -next tree) fixes this by checking on the tty buffer tail. Once it's reached, the current work is rescheduled and another could run. Signed-off-by: Jiri Olsa <jolsa@redhat.com> Acked-by: Alan Cox <alan@lxorguk.ukuu.org.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2011-04-17drivers/char/vt_ioctl.c: fix VT_OPENQRY error valueGraham Gower
commit 1e0ad2881d50becaeea70ec696a80afeadf944d2 upstream. When all VT's are in use, VT_OPENQRY casts -1 to unsigned char before returning it to userspace as an int. VT255 is not the next available console. Signed-off-by: Graham Gower <graham.gower@gmail.com> Cc: Greg KH <greg@kroah.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2011-04-17hpet: unmap unused I/O spaceJiri Slaby
commit a56d5318716d120e040294bb258901ba89fb9c90 upstream. When the initialization code in hpet finds a memory resource and does not find an IRQ, it does not unmap the memory resource previously mapped. There are buggy BIOSes which report resources exactly like this and what is worse the memory region bases point to normal RAM. This normally would not matter since the space is not touched. But when PAT is turned on, ioremap causes the page to be uncached and sets this bit in page->flags. Then when the page is about to be used by the allocator, it is reported as: BUG: Bad page state in process md5sum pfn:3ed00 page:ffffea0000dbd800 count:0 mapcount:0 mapping:(null) index:0x0 page flags: 0x20000001000000(uncached) Pid: 7956, comm: md5sum Not tainted 2.6.34-12-desktop #1 Call Trace: [<ffffffff810df851>] bad_page+0xb1/0x100 [<ffffffff810dfa45>] prep_new_page+0x1a5/0x1c0 [<ffffffff810dfe01>] get_page_from_freelist+0x3a1/0x640 [<ffffffff810e01af>] __alloc_pages_nodemask+0x10f/0x6b0 ... In this particular case: 1) HPET returns 3ed00000 as memory region base, but it is not in reserved ranges reported by the BIOS (excerpt): BIOS-e820: 0000000000100000 - 00000000af6cf000 (usable) BIOS-e820: 00000000af6cf000 - 00000000afdcf000 (reserved) 2) there is no IRQ resource reported by HPET method. On the other hand, the Intel HPET specs (1.0a) says (3.2.5.1): _CRS ( // Report 1K of memory consumed by this Timer Block memory range consumed // Optional: only used if BIOS allocates Interrupts [1] IRQs consumed ) [1] For case where Timer Block is configured to consume IRQ0/IRQ8 AND Legacy 8254/Legacy RTC hardware still exists, the device objects associated with 8254 & RTC devices should not report IRQ0/IRQ8 as "consumed resources". So in theory we should check whether if it is the case and use those interrupts instead. Anyway the address reported by the BIOS here is bogus, so non-presence of IRQ doesn't mean the "optional" part in point 2). Since I got no reply previously, fix this by simply unmapping the space when IRQ is not found and memory region was mapped previously. It would be probably more safe to walk the resources again and unmap appropriately depending on type. But as we now use only ioremap for both 2 memory resource types, it is not necessarily needed right now. Addresses https://bugzilla.novell.com/show_bug.cgi?id=629908 Reported-by: Olaf Hering <olaf@aepfle.de> Signed-off-by: Jiri Slaby <jslaby@suse.cz> Acked-by: Clemens Ladisch <clemens@ladisch.de> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2011-04-17hpet: fix unwanted interrupt due to stale irq status bitClemens Ladisch
commit 96e9694df446d1154ec2f4fdba8908588b9cba38 upstream. Jaswinder Singh Rajput wrote: > By executing Documentation/timers/hpet_example.c > > for polling, I requested for 3 iterations but it seems iteration work > for only 2 as first expired time is always very small. > > # ./hpet_example poll /dev/hpet 10 3 > -hpet: executing poll > hpet_poll: info.hi_flags 0x0 > hpet_poll: expired time = 0x13 > hpet_poll: revents = 0x1 > hpet_poll: data 0x1 > hpet_poll: expired time = 0x1868c > hpet_poll: revents = 0x1 > hpet_poll: data 0x1 > hpet_poll: expired time = 0x18645 > hpet_poll: revents = 0x1 > hpet_poll: data 0x1 Clearing the HPET interrupt enable bit disables interrupt generation but does not disable the timer, so the interrupt status bit will still be set when the timer elapses. If another interrupt arrives before the timer has been correctly programmed (due to some other device on the same interrupt line, or CONFIG_DEBUG_SHIRQ), this results in an extra unwanted interrupt event because the status bit is likely to be set from comparator matches that happened before the device was opened. Therefore, we have to ensure that the interrupt status bit is and stays cleared until we actually program the timer. Signed-off-by: Clemens Ladisch <clemens@ladisch.de> Reported-by: Jaswinder Singh Rajput <jaswinderlinux@gmail.com> Cc: Ingo Molnar <mingo@elte.hu> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: john stultz <johnstul@us.ibm.com> Cc: Bob Picco <bpicco@redhat.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2011-01-06pcmcia: synclink_cs: fix information leak to userlandVasiliy Kulikov
commit 5b917a1420d3d1a9c8da49fb0090692dc9aaee86 upstream. Structure new_line is copied to userland with some padding fields unitialized. It leads to leaking of stack memory. Signed-off-by: Vasiliy Kulikov <segooon@gmail.com> Signed-off-by: Dominik Brodowski <linux@dominikbrodowski.net> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2011-01-06sis-agp: Remove SIS 760, handled by amd64-agpBen Hutchings
commit d831692a1a8e9ceaaa9bb16bb3fc503b7e372558 upstream. SIS 760 is listed in the device tables for both amd64-agp and sis-agp. amd64-agp is apparently preferable since it has workarounds for some BIOS misconfigurations that sis-agp doesn't handle. Signed-off-by: Ben Hutchings <ben@decadent.org.uk> Signed-off-by: Dave Airlie <airlied@redhat.com> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2011-01-06char: Mark /dev/zero and /dev/kmem as not capable of writebackJan Kara
commit 371d217ee1ff8b418b8f73fb2a34990f951ec2d4 upstream. These devices don't do any writeback but their device inodes still can get dirty so mark bdi appropriately so that bdi code does the right thing and files inodes to lists of bdi carrying the device inodes. Signed-off-by: Jan Kara <jack@suse.cz> Signed-off-by: Jens Axboe <jaxboe@fusionio.com> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2010-08-13Char: nozomi, set tty->driver_data appropriatelyJiri Slaby
commit bf9c1fca9ae9a79ed209e7ab2c10b3862f3f6f72 upstream. Sorry, one more fix, this one depends on the other, so this is rather 2/2. -- tty->driver_data is used all over the code, but never set. This results in oopses like: BUG: unable to handle kernel NULL pointer dereference at 0000000000000130 IP: [<ffffffff814a0040>] mutex_lock+0x10/0x40 ... Pid: 2157, comm: modem-manager Not tainted 2.6.34.1-0.1-desktop #1 2768DR7/2768DR7 RIP: 0010:[<ffffffff814a0040>] [<ffffffff814a0040>] mutex_lock+0x10/0x40 RSP: 0018:ffff88007b16fa50 EFLAGS: 00010286 RAX: 0000000000000000 RBX: 0000000000000130 RCX: 0000000000000003 RDX: 0000000000000003 RSI: 0000000000000286 RDI: 0000000000000130 RBP: 0000000000001000 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000130 R13: 0000000000000001 R14: 0000000000000000 R15: ffff88007b16feb4 ... Call Trace: [<ffffffffa077690d>] ntty_write_room+0x4d/0x90 [nozomi] ... Set tty->driver_data to the computed port in .install to not recompute it in every place where needed. Switch .open to use driver_data too. Signed-off-by: Jiri Slaby <jslaby@suse.cz> Cc: Alan Cox <alan@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-08-13Char: nozomi, fix tty->count countingJiri Slaby
commit ee78bb95b7bea08b7774a02073ea2bb45611a9e1 upstream. Currently ntty_install omits to increment tty count and we get the following warnings: Warning: dev (noz2) tty->count(0) != #fd's(1) in tty_open So to fix that, add one tty->count++ there. Signed-off-by: Jiri Slaby <jslaby@suse.cz> Cc: Alan Cox <alan@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-08-02ipmi: set schedule_timeout_wait() value back to oneMartin Wilck
commit 8d1f66dc9b4f80a1441bc1c33efa98aca99e8813 upstream. Fix a regression introduced by ae74e823cb7d ("ipmi: add parameter to limit CPU usage in kipmid"). Some systems were seeing CPU usage go up dramatically with the recent changes to try to reduce timer usage in the IPMI driver. This was traced down to schedule_timeout_interruptible(1) being changed to schedule_timeout_interruptbile(0). Revert that part of the change. Addresses https://bugzilla.kernel.org/show_bug.cgi?id=16147 Reported-by: Thomas Jarosch <thomas.jarosch@intra2net.com> Signed-off-by: Corey Minyard <cminyard@mvista.com> Tested-by: Thomas Jarosch <thomas.jarosch@intra2net.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-08-02amd64-agp: Probe unknown AGP devices the right wayBen Hutchings
commit 6fd024893911dcb51b4a0aa71971db5ba38f7071 upstream. The current initialisation code probes 'unsupported' AGP devices simply by calling its own probe function. It does not lock these devices or even check whether another driver is already bound to them. We must use the device core to manage this. So if the specific device id table didn't match anything and agp_try_unsupported=1, switch the device id table and call driver_attach() again. Signed-off-by: Ben Hutchings <ben@decadent.org.uk> Signed-off-by: Dave Airlie <airlied@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-08-02tpm_tis: fix subsequent suspend failuresRajiv Andrade
commit 59f6fbe4291fcc078ba26ce4edf8373a7620a13a upstream. Fix subsequent suspends by issuing tpm_continue_selftest during resume. Otherwise, the tpm chip seems to be not fully initialized and will reject the save state command during suspend, thus preventing the whole system to suspend. Addresses https://bugzilla.kernel.org/show_bug.cgi?id=16256 Signed-off-by: Helmut Schaa <helmut.schaa@googlemail.com> Signed-off-by: Rajiv Andrade <srajiv@linux.vnet.ibm.com> Cc: James Morris <jmorris@namei.org> Cc: Debora Velarde <debora@linux.vnet.ibm.com> Cc: David Safford <safford@watson.ibm.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: James Morris <jmorris@namei.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-08-02TPM: ReadPubEK output struct fixRajiv Andrade
commit 02a077c52ef7631275a79862ffd9f3dbe9d38bc2 upstream. This patch adds a missing element of the ReadPubEK command output, that prevents future overflow of this buffer when copying the TPM output result into it. Prevents a kernel panic in case the user tries to read the pubek from sysfs. Signed-off-by: Rajiv Andrade <srajiv@linux.vnet.ibm.com> Signed-off-by: James Morris <jmorris@namei.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-07-05ipmi: handle run_to_completion properly in deliver_recv_msg()Jiri Kosina
commit a747c5abc329611220f16df0bb4cf0ca4a7fdf0c upstream. If run_to_completion flag is set, it means that we are running in a single-threaded mode, and thus no locks are held. This fixes a deadlock when IPMI notifier is being called during panic. Signed-off-by: Jiri Kosina <jkosina@suse.cz> Acked-by: Corey Minyard <minyard@acm.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-05-13tty: Fix unbalanced BKL handling in error pathAlan Cox
Arnd noted: After the "retry_open:" label, we first get the tty_mutex and then the BKL. However a the end of tty_open, we jump back to retry_open with the BKL still held. If we run into this case, the tty_open function will be left with the BKL still held. Signed-off-by: Alan Cox <alan@linux.intel.com> Acked-by: Arnd Bergmann <arnd@arndb.de> Cc: stable <stable@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-04-30tty: Fix regressions in the char driver conversionAlan Cox
This forgot to update a field in the old char drivers. The fact nobody has basically noticed (except one mxser user) rather suggests most of these drivers could go into the bitbucket. Signed-off-by: Alan Cox <alan@linux.intel.com> Cc: Jiri Slaby <jirislaby@gmail.com> Cc: Dan Carpenter <error27@gmail.com> Cc: Andreas Pretzsch <apr@cn-eng.de> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-04-20Merge branch 'urgent' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/brodo/pcmcia-2.6 * 'urgent' of git://git.kernel.org/pub/scm/linux/kernel/git/brodo/pcmcia-2.6: pcmcia: fix error handling in cm4000_cs.c drivers/pcmcia: Add missing local_irq_restore serial_cs: MD55x support (PCMCIA GPRS/EDGE modem) (kernel 2.6.33) pcmcia: avoid late calls to pccard_validate_cis pcmcia: fix ioport size calculation in rsrc_nonstatic pcmcia: re-start on MFC override pcmcia: fix io_probe due to parent (PCI) resources pcmcia: use previously assigned IRQ for all card functions
2010-04-19pcmcia: fix error handling in cm4000_cs.cDan Carpenter
In the original code we used -ENODEV as the number of bytes to copy_to_user() and we didn't release the locks. Signed-off-by: Dan Carpenter <error27@gmail.com> Acked-by: Harald Welte <laforge@gnumonks.org> Signed-off-by: Dominik Brodowski <linux@dominikbrodowski.net>
2010-04-17Merge branch 'for-linus' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/anholt/drm-intel * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/anholt/drm-intel: drm/i915: Ignore LVDS EDID when it is unavailabe or invalid drm/i915: Add no_lvds entry for the Clientron U800 drm/i915: Rename many remaining uses of "output" to encoder or connector. drm/i915: Rename intel_output to intel_encoder. agp/intel: intel_845_driver is an agp driver! drm/i915: introduce to_intel_bo helper drm/i915: Disable FBC on 915GM and 945GM.
2010-04-08hvc_console: Fix race between hvc_close and hvc_removeAnton Blanchard
I don't claim to understand the tty layer, but it seems like hvc_open and hvc_close should be balanced in their kref reference counting. Right now we get a kref every call to hvc_open: if (hp->count++ > 0) { tty_kref_get(tty); <----- here spin_unlock_irqrestore(&hp->lock, flags); hvc_kick(); return 0; } /* else count == 0 */ tty->driver_data = hp; hp->tty = tty_kref_get(tty); <------ or here if hp->count was 0 But hvc_close has: tty_kref_get(tty); if (--hp->count == 0) { ... /* Put the ref obtained in hvc_open() */ tty_kref_put(tty); ... } tty_kref_put(tty); Since the outside kref get/put balance we only do a single kref_put when count reaches 0. The patch below changes things to call tty_kref_put once for every hvc_close call, and with that my machine boots fine. Signed-off-by: Anton Blanchard <anton@samba.org> Acked-by: Amit Shah <amit.shah@redhat.com> Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2010-04-08virtio: disable multiport console support.Michael S. Tsirkin
Move MULTIPORT feature and related config changes out of exported headers, and disable the feature at runtime. At this point, it seems less risky to keep code around until we can enable it than rip it out completely. Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2010-04-08virtio: console makes incorrect assumption about virtio APIRusty Russell
The get_buf() API sets the second arg to the number of bytes *written* by the other side; in this case it should be zero as these are output buffers. lguest gets this right (obviously kvm's console doesn't), resulting in continual buildup of console writes. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> Acked-by: Amit Shah <amit.shah@redhat.com>
2010-04-08virtio: console: Fix early_put_chars usageFrançois Diakhaté
Currently early_put_chars is not used by virtio_console because it can only be used once a port has been found, at which point it's too late because it is no longer needed. This patch should fix it. Acked-by: Christian Borntraeger <borntraeger@de.ibm.com> Signed-off-by: Amit Shah <amit.shah@redhat.com> Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2010-04-07frv: hide uncached_access() when pgprot_noncached is not #definedDavid Howells
Hide uncached_access() when pgprot_noncached is not #defined. This prevents the following warning: CC drivers/char/mem.o drivers/char/mem.c:229: warning: 'uncached_access' defined but not used Repairs d7d4d849b4e3acc405ec222884936800ffb26d48 ("drivers/char/mem.c: cleanups"). Signed-off-by: David Howells <dhowells@redhat.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2010-04-07/dev/mem: allow rewindingEric Dumazet
commit dcefafb6 ("/dev/mem: dont allow seek to last page") inadvertently disabled rewinding on /dev/mem. This broke x86info for example. Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com> Acked-by: Wu Fengguang <fengguang.wu@intel.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2010-04-07vfs: rename block_fsync() to blkdev_fsync()Andrew Morton
Requested by hch, for consistency now it is exported. Cc: Alexander Viro <viro@zeniv.linux.org.uk> Cc: Anton Blanchard <anton@samba.org> Cc: Christoph Hellwig <hch@lst.de> Cc: Jan Kara <jack@suse.cz> Cc: Jeff Moyer <jmoyer@redhat.com> Cc: Jens Axboe <jens.axboe@oracle.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2010-04-07raw: fsync method is now requiredAnton Blanchard
Commit 148f948ba877f4d3cdef036b1ff6d9f68986706a (vfs: Introduce new helpers for syncing after writing to O_SYNC file or IS_SYNC inode) broke the raw driver. We now call through generic_file_aio_write -> generic_write_sync -> vfs_fsync_range. vfs_fsync_range has: if (!fop || !fop->fsync) { ret = -EINVAL; goto out; } But drivers/char/raw.c doesn't set an fsync method. We have two options: fix it or remove the raw driver completely. I'm happy to do either, the fact this has been broken for so long suggests it is rarely used. The patch below adds an fsync method to the raw driver. My knowledge of the block layer is pretty sketchy so this could do with a once over. If we instead decide to remove the raw driver, this patch might still be useful as a backport to 2.6.33 and 2.6.32. Signed-off-by: Anton Blanchard <anton@samba.org> Reviewed-by: Jan Kara <jack@suse.cz> Cc: Christoph Hellwig <hch@lst.de> Cc: Alexander Viro <viro@zeniv.linux.org.uk> Cc: Jens Axboe <jens.axboe@oracle.com> Reviewed-by: Jeff Moyer <jmoyer@redhat.com> Tested-by: Jeff Moyer <jmoyer@redhat.com> Cc: <stable@kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2010-04-07devmem: handle class_create() failureAnton Blanchard
I hit this when we had a bug in IDR for a few days. Basically sysfs would fail to create new inodes since it uses an IDR and therefore class_create would fail. While we are unlikely to see this fail we may as well handle it instead of oopsing. Signed-off-by: Anton Blanchard <anton@samba.org> Reviewed-by: Wu Fengguang <fengguang.wu@intel.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2010-04-07mxser: spin_lock() => spin_lock_irq()Dan Carpenter
This should be spin_lock_irq() to match the spin_unlock_irq(). Originally it was a lock_kernel() but we switched everything to spin_lock_irq() last November. [akpm@linux-foundation.org: fix the MOXA_ASPP_MON case too (per Jiri)] Signed-off-by: Dan Carpenter <error27@gmail.com> Cc: Jiri Slaby <jirislaby@gmail.com> Cc: Alan Cox <alan@lxorguk.ukuu.org.uk> Cc: Greg KH <greg@kroah.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2010-04-07drivers/char/amiserial.c: add missing local_irq_restoreJulia Lawall
rs_init() is failing to restore interrupts on two error paths, and is incorrectly calling tty_unregister_driver() with local interrupts disabled. Fix these things by disabling interrupts later, after the reauest_irq() calls. A simplified version of the semantic patch that finds this problem is as follows: (http://coccinelle.lip6.fr/) // <smpl> @r exists@ expression E1; identifier f; @@ f (...) { <+... * local_irq_save (E1,...); ... when != E1 * return ...; ...+> } // </smpl> [akpm@linux-foundation.org: reimplement the fix] Signed-off-by: Julia Lawall <julia@diku.dk> Cc: Thadeu Lima de Souza Cascardo <cascardo@holoscopio.com> Cc: Greg KH <greg@kroah.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2010-04-05Merge branch 'master' into export-slabhTejun Heo
2010-04-02tty: release_one_tty() forgets to put pidsOleg Nesterov
release_one_tty(tty) can be called when tty still has a reference to pgrp/session. In this case we leak the pid. Signed-off-by: Oleg Nesterov <oleg@redhat.com> Reported-by: Catalin Marinas <catalin.marinas@arm.com> Reported-and-tested-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> Acked-by: Linus Torvalds <torvalds@linux-foundation.org> Acked-by: Eric W. Biederman <ebiederm@xmission.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2010-03-30include cleanup: Update gfp.h and slab.h includes to prepare for breaking ↵Tejun Heo
implicit slab.h inclusion from percpu.h percpu.h is included by sched.h and module.h and thus ends up being included when building most .c files. percpu.h includes slab.h which in turn includes gfp.h making everything defined by the two files universally available and complicating inclusion dependencies. percpu.h -> slab.h dependency is about to be removed. Prepare for this change by updating users of gfp and slab facilities include those headers directly instead of assuming availability. As this conversion needs to touch large number of source files, the following script is used as the basis of conversion. http://userweb.kernel.org/~tj/misc/slabh-sweep.py The script does the followings. * Scan files for gfp and slab usages and update includes such that only the necessary includes are there. ie. if only gfp is used, gfp.h, if slab is used, slab.h. * When the script inserts a new include, it looks at the include blocks and try to put the new include such that its order conforms to its surrounding. It's put in the include block which contains core kernel includes, in the same order that the rest are ordered - alphabetical, Christmas tree, rev-Xmas-tree or at the end if there doesn't seem to be any matching order. * If the script can't find a place to put a new include (mostly because the file doesn't have fitting include block), it prints out an error message indicating which .h file needs to be added to the file. The conversion was done in the following steps. 1. The initial automatic conversion of all .c files updated slightly over 4000 files, deleting around 700 includes and adding ~480 gfp.h and ~3000 slab.h inclusions. The script emitted errors for ~400 files. 2. Each error was manually checked. Some didn't need the inclusion, some needed manual addition while adding it to implementation .h or embedding .c file was more appropriate for others. This step added inclusions to around 150 files. 3. The script was run again and the output was compared to the edits from #2 to make sure no file was left behind. 4. Several build tests were done and a couple of problems were fixed. e.g. lib/decompress_*.c used malloc/free() wrappers around slab APIs requiring slab.h to be added manually. 5. The script was run on all .h files but without automatically editing them as sprinkling gfp.h and slab.h inclusions around .h files could easily lead to inclusion dependency hell. Most gfp.h inclusion directives were ignored as stuff from gfp.h was usually wildly available and often used in preprocessor macros. Each slab.h inclusion directive was examined and added manually as necessary. 6. percpu.h was updated not to include slab.h. 7. Build test were done on the following configurations and failures were fixed. CONFIG_GCOV_KERNEL was turned off for all tests (as my distributed build env didn't work with gcov compiles) and a few more options had to be turned off depending on archs to make things build (like ipr on powerpc/64 which failed due to missing writeq). * x86 and x86_64 UP and SMP allmodconfig and a custom test config. * powerpc and powerpc64 SMP allmodconfig * sparc and sparc64 SMP allmodconfig * ia64 SMP allmodconfig * s390 SMP allmodconfig * alpha SMP allmodconfig * um on x86_64 SMP allmodconfig 8. percpu.h modifications were reverted so that it could be applied as a separate patch and serve as bisection point. Given the fact that I had only a couple of failures from tests on step 6, I'm fairly confident about the coverage of this conversion patch. If there is a breakage, it's likely to be something in one of the arch headers which should be easily discoverable easily on most builds of the specific arch. Signed-off-by: Tejun Heo <tj@kernel.org> Guess-its-ok-by: Christoph Lameter <cl@linux-foundation.org> Cc: Ingo Molnar <mingo@redhat.com> Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>