summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2008-01-14Linux 2.6.22.16v2.6.22.16Greg Kroah-Hartman
2008-01-14Use access mode instead of open flags to determine needed permissions ↵Linus Torvalds
(CVE-2008-0001) patch 974a9f0b47da74e28f68b9c8645c3786aa5ace1a in mainline Way back when (in commit 834f2a4a1554dc5b2598038b3fe8703defcbe467, aka "VFS: Allow the filesystem to return a full file pointer on open intent" to be exact), Trond changed the open logic to keep track of the original flags to a file open, in order to pass down the the intent of a dentry lookup to the low-level filesystem. However, when doing that reorganization, it changed the meaning of namei_flags, and thus inadvertently changed the test of access mode for directories (and RO filesystem) to use the wrong flag. So fix those test back to use access mode ("acc_mode") rather than the open flag ("flag"). Issue noticed by Bill Roman at Datalight. Reported-and-tested-by: Bill Roman <bill.roman@datalight.com> Acked-by: Trond Myklebust <Trond.Myklebust@netapp.com> Acked-by: Al Viro <viro@ZenIV.linux.org.uk> Cc: Christoph Hellwig <hch@lst.de> Cc: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-12-14Linux 2.6.22.15v2.6.22.15Greg Kroah-Hartman
2007-12-14BRIDGE: Properly dereference the br_should_route_hookPavel Emelyanov
[BRIDGE]: Properly dereference the br_should_route_hook [ Upstream commit: 82de382ce8e1c7645984616728dc7aaa057821e4 ] This hook is protected with the RCU, so simple if (br_should_route_hook) br_should_route_hook(...) is not enough on some architectures. Use the rcu_dereference/rcu_assign_pointer in this case. Fixed Stephen's comment concerning using the typeof(). Signed-off-by: Pavel Emelyanov <xemul@openvz.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-12-14libata: kill spurious NCQ completion detectionTejun Heo
patch 459ad68893a84fb0881e57919340b97edbbc3dc7 in mainline. Spurious NCQ completion detection implemented in ahci was incorrect. On AHCI receving and processing FISes and raising interrupts are not interlocked and spurious interrupts are expected. For example, if an interrupt occurs while interrupt handler is running and the running interrupt handler handles the event the new IRQ indicated, after IRQ handler finishes, it will be executed again because IRQ pending bit is set by the new interrupt but there won't be anything to process. Please read the following message for more information. http://article.gmane.org/gmane.linux.ide/26012 This patch... * Removes all spurious IRQ whining from ahci. Spurious NCQ completion detection was completely wrong. Spurious D2H Register FIS taught us that some early drives send spurious D2H Register FIS with I bit set while NCQ commands are in progress but none of recent drives does that and even the ones which show such behavior can do NCQ fine. * Kills all NCQ blacklist entries which were added because of spurious NCQ completions. I tracked down each commit and verified all removed ones are actually added because of spurious completions. WD740ADFD-00NLR1 wasn't deleted but moved upward because the drive not only had spurious NCQ completions but also is slow on sequential data transfers if NCQ is enabled. Maxtor 7V300F0 was added by 0e3dbc01d53940fe10e5a5cfec15ede3e929c918 from Alan Cox. I can only find evidences that the drive only had troubles with spuruious completions by searching the mailing list. This entry needs to be verified and removed if it doesn't have other NCQ related problems. Signed-off-by: Tejun Heo <htejun@gmail.com> Cc: Alan Cox <alan@lxorguk.ukuu.org.uk> Signed-off-by: Jeff Garzik <jeff@garzik.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-12-14NETFILTER: xt_TCPMSS: remove network triggerable WARN_ONPatrick McHardy
[NETFILTER]: xt_TCPMSS: remove network triggerable WARN_ON [ Upstream commit: 9dc0564e862b1b9a4677dec2c736b12169e03e99 ] ipv6_skip_exthdr() returns -1 for invalid packets. don't WARN_ON that. Signed-off-by: Patrick McHardy <kaber@trash.net> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-12-14XFRM: Fix leak of expired xfrm_statesPatrick McHardy
[XFRM]: Fix leak of expired xfrm_states [ Upstream commit: 5dba4797115c8fa05c1a4d12927a6ae0b33ffc41 ] The xfrm_timer calls __xfrm_state_delete, which drops the final reference manually without triggering destruction of the state. Change it to use xfrm_state_put to add the state to the gc list when we're dropping the last reference. The timer function may still continue to use the state safely since the final destruction does a del_timer_sync(). Signed-off-by: Patrick McHardy <kaber@trash.net> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-12-14Revert "Fix SMP poweroff hangs"Greg Kroah-Hartman
This reverts the following changeset in 2.6.22.10 that caused a lot of reported problems. From: Mark Lord <lkml@rtr.ca> commit 4047727e5ae33f9b8d2b7766d1994ea6e5ec2991 from upstream We need to disable all CPUs other than the boot CPU (usually 0) before attempting to power-off modern SMP machines. This fixes the hang-on-poweroff issue on my MythTV SMP box, and also on Thomas Gleixner's new toybox. Signed-off-by: Mark Lord <mlord@pobox.com> Acked-by: Thomas Gleixner <tglx@linutronix.de> Cc: "Rafael J. Wysocki" <rjw@sisk.pl> 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> There still is a remaining shutdown problem in 2.6.22 with old APM based systems, but this fix is not the correct one Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-12-14knfsd: Validate filehandle type in fsid_sourceNeil Brown
patch b8da0d1c27f144bce999c653467106f3f0d5a308 in mainline. fsid_source decided where to get the 'fsid' number to return for a GETATTR based on the type of filehandle. It can be from the device, from the fsid, or from the UUID. It is possible for the filehandle to be inconsistent with the export information, so make sure the export information actually has the info implied by the value returned by fsid_source. Signed-off-by: Neil Brown <neilb@suse.de> Cc: "Luiz Fernando N. Capitulino" <lcapitulino@gmail.com> Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Cc: Oliver Pintr <oliver.pntr@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-12-14BRIDGE: Lost call to br_fdb_fini() in br_init() error pathPavel Emelyanov
[BRIDGE]: Lost call to br_fdb_fini() in br_init() error path [ Upstream commit: 17efdd45755c0eb8d1418a1368ef7c7ebbe98c6e ] In case the br_netfilter_init() (or any subsequent call) fails, the br_fdb_fini() must be called to free the allocated in br_fdb_init() br_fdb_cache kmem cache. Signed-off-by: Pavel Emelyanov <xemul@openvz.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-12-14DECNET: dn_nl_deladdr() almost always returns no errorPavel Emelyanov
[DECNET]: dn_nl_deladdr() almost always returns no error [ Upstream commit: 3ccd86241b277249d5ac08e91eddfade47184520 ] As far as I see from the err variable initialization the dn_nl_deladdr() routine was designed to report errors like "EADDRNOTAVAIL" and probaby "ENODEV". But the code sets this err to 0 after the first nlmsg_parse and goes on, returning this 0 in any case. Signed-off-by: Pavel Emelyanov <xemul@openvz.org> Acked-by: Steven Whitehouse <swhiteho@redhat.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-12-14IPV6: Restore IPv6 when MTU is big enoughEvgeniy Polyakov
[IPV6]: Restore IPv6 when MTU is big enough [ Upstream commit: d31c7b8fa303eb81311f27b80595b8d2cbeef950 ] Avaid provided test application, so bug got fixed. IPv6 addrconf removes ipv6 inner device from netdev each time cmu changes and new value is less than IPV6_MIN_MTU (1280 bytes). When mtu is changed and new value is greater than IPV6_MIN_MTU, it does not add ipv6 addresses and inner device bac. This patch fixes that. Tested with Avaid's application, which works ok now. Signed-off-by: Evgeniy Polyakov <johnpol@2ka.mipt.ru> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-12-14RXRPC: Add missing select on CRYPTODavid Howells
[RXRPC]: Add missing select on CRYPTO [ Upstream commit: d5a784b3719ae364f49ecff12a0248f6e4252720 ] AF_RXRPC uses the crypto services, so should depend on or select CRYPTO. Signed-off-by: David Howells <dhowells@redhat.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-12-14TCP: illinois: Incorrect beta usageStephen Hemminger
[TCP] illinois: Incorrect beta usage [ Upstream commit: a357dde9df33f28611e6a3d4f88265e39bcc8880 ] Lachlan Andrew observed that my TCP-Illinois implementation uses the beta value incorrectly: The parameter beta in the paper specifies the amount to decrease *by*: that is, on loss, W <- W - beta*W but in tcp_illinois_ssthresh() uses beta as the amount to decrease *to*: W <- beta*W This bug makes the Linux TCP-Illinois get less-aggressive on uncongested network, hurting performance. Note: since the base beta value is .5, it has no impact on a congested network. Signed-off-by: Stephen Hemminger <shemminger@linux-foundation.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-12-14TEXTSEARCH: Do not allow zero length patterns in the textsearch infrastructurePablo Neira Ayuso
[TEXTSEARCH]: Do not allow zero length patterns in the textsearch infrastructure [ Upstream commit: e03ba84adb62fbc6049325a5bc00ef6932fa5e39 ] If a zero length pattern is passed then return EINVAL. Avoids infinite loops (bm) or invalid memory accesses (kmp). Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org> Signed-off-by: Patrick McHardy <kaber@trash.net> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-12-14UNIX: EOF on non-blocking SOCK_SEQPACKETFlorian Zumbiehl
[UNIX]: EOF on non-blocking SOCK_SEQPACKET [ Upstream commit: 0a11225887fe6cbccd882404dc36ddc50f47daf9 ] I am not absolutely sure whether this actually is a bug (as in: I've got no clue what the standards say or what other implementations do), but at least I was pretty surprised when I noticed that a recv() on a non-blocking unix domain socket of type SOCK_SEQPACKET (which is connection oriented, after all) where the remote end has closed the connection returned -1 (EAGAIN) rather than 0 to indicate end of file. This is a test case: | #include <sys/types.h> | #include <unistd.h> | #include <sys/socket.h> | #include <sys/un.h> | #include <fcntl.h> | #include <string.h> | #include <stdlib.h> | | int main(){ | int sock; | struct sockaddr_un addr; | char buf[4096]; | int pfds[2]; | | pipe(pfds); | sock=socket(PF_UNIX,SOCK_SEQPACKET,0); | addr.sun_family=AF_UNIX; | strcpy(addr.sun_path,"/tmp/foobar_testsock"); | bind(sock,(struct sockaddr *)&addr,sizeof(addr)); | listen(sock,1); | if(fork()){ | close(sock); | sock=socket(PF_UNIX,SOCK_SEQPACKET,0); | connect(sock,(struct sockaddr *)&addr,sizeof(addr)); | fcntl(sock,F_SETFL,fcntl(sock,F_GETFL)|O_NONBLOCK); | close(pfds[1]); | read(pfds[0],buf,sizeof(buf)); | recv(sock,buf,sizeof(buf),0); // <-- this one | }else accept(sock,NULL,NULL); | exit(0); | } If you try it, make sure /tmp/foobar_testsock doesn't exist. The marked recv() returns -1 (EAGAIN) on 2.6.23.9. Below you find a patch that fixes that. Signed-off-by: Florian Zumbiehl <florz@florz.de> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-12-14ATM: [he] initialize lock and tasklet earlierchas williams
[ATM]: [he] initialize lock and tasklet earlier [ Upstream commit: 8a8037ac9dbe4eb20ce50aa20244faf77444f4a3 ] if you are lucky (unlucky?) enough to have shared interrupts, the interrupt handler can be called before the tasklet and lock are ready for use. Signed-off-by: chas williams <chas@cmf.nrl.navy.mil> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Cc: David Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-12-14CRYPTO api: Fix potential race in crypto_remove_spawnHerbert Xu
[CRYPTO] api: Fix potential race in crypto_remove_spawn [ Upstream commit: 38cb2419f544ad413c7f7aa8c17fd7377610cdd8 ] As it is crypto_remove_spawn may try to unregister an instance which is yet to be registered. This patch fixes this by checking whether the instance has been registered before attempting to remove it. It also removes a bogus cra_destroy check in crypto_register_instance as 1) it's outside the mutex; 2) we have a check in __crypto_register_alg already. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Cc: David Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-12-14IPV4: Remove bogus ifdef mess in arp_processAdrian Bunk
[IPV4]: Remove bogus ifdef mess in arp_process [ Upstream commit: 3660019e5f96fd9a8b7d4214a96523c0bf7b676d ] The #ifdef's in arp_process() were not only a mess, they were also wrong in the CONFIG_NET_ETHERNET=n and (CONFIG_NETDEV_1000=y or CONFIG_NETDEV_10000=y) cases. Since they are not required this patch removes them. Also removed are some #ifdef's around #include's that caused compile errors after this change. Signed-off-by: Adrian Bunk <bunk@kernel.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Cc: David Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-12-14NET: Corrects a bug in ip_rt_acct_read()Eric Dumazet
[NET]: Corrects a bug in ip_rt_acct_read() [ Upstream commit: 483b23ffa3a5f44767038b0a676d757e0668437e ] It seems that stats of cpu 0 are counted twice, since for_each_possible_cpu() is looping on all possible cpus, including 0 Before percpu conversion of ip_rt_acct, we should also remove the assumption that CPU 0 is online (or even possible) Signed-off-by: Eric Dumazet <dada1@cosmosbay.com> Cc: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-12-14PFKEY: Sending an SADB_GET responds with an SADB_GETCharles Hardin
[PFKEY]: Sending an SADB_GET responds with an SADB_GET [ Upstream commit: 435000bebd94aae3a7a50078d142d11683d3b193 ] Kernel needs to respond to an SADB_GET with the same message type to conform to the RFC 2367 Section 3.1.5 Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-12-14TCP: MTUprobe: fix potential sk_send_head corruptionIlpo Järvinen
[TCP] MTUprobe: fix potential sk_send_head corruption [ Upstream commit: 6e42141009ff18297fe19d19296738b742f861db ] When the abstraction functions got added, conversion here was made incorrectly. As a result, the skb may end up pointing to skb which got included to the probe skb and then was freed. For it to trigger, however, skb_transmit must fail sending as well. Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@helsinki.fi> Signed-off-by: David S. Miller <davem@davemloft.net> Cc: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-12-14TCP: Problem bug with sysctl_tcp_congestion_control functionSam Jansen
[TCP]: Problem bug with sysctl_tcp_congestion_control function [ Upstream commit: 5487796f0c9475586277a0a7a91211ce5746fa6a ] sysctl_tcp_congestion_control seems to have a bug that prevents it from actually calling the tcp_set_default_congestion_control function. This is not so apparent because it does not return an error and generally the /proc interface is used to configure the default TCP congestion control algorithm. This is present in 2.6.18 onwards and probably earlier, though I have not inspected 2.6.15--2.6.17. sysctl_tcp_congestion_control calls sysctl_string and expects a successful return code of 0. In such a case it actually sets the congestion control algorithm with tcp_set_default_congestion_control. Otherwise, it returns the value returned by sysctl_string. This was correct in 2.6.14, as sysctl_string returned 0 on success. However, sysctl_string was updated to return 1 on success around about 2.6.15 and sysctl_tcp_congestion_control was not updated. Even though sysctl_tcp_congestion_control returns 1, do_sysctl_strategy converts this return code to '0', so the caller never notices the error. Signed-off-by: David S. Miller <davem@davemloft.net> Cc: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-12-14fb_ddc: fix DDC lines quirkJean Delvare
patch b64d70825abbf706bbe80be1b11b09514b71f45e in mainline. The code in fb_ddc_read() is said to be based on the implementation of the radeon driver: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=fc5891c8a3ba284f13994d7bc1f1bfa8283982de However, comparing the old radeon driver code with the new fb_ddc code reveals some differences. Most notably, the I2C bus lines are held at the end of the function, while the original code was releasing them (as the comment above correctly says.) There are a few other differences, which appear to be responsible for read failures on my system. While tracing low-level I2C code in i2c-algo-bit, I noticed that the initial attempt to read the EDID always failed. It takes one retry for the read to succeed. As we are about to remove this automatic retry property from i2c-algo-bit, reading the EDID would really fail. As a summary, the I2C lines quirk which is supposedly needed to read EDID on some older monitors is currently breaking the (first) read on all other monitors (and might not even work with older ones - did anyone try since October 2006?) After applying the patch below, which makes the code in fb_ddc_read() really similar to what the radeon driver used to have, the first EDID read succeeds again. On top of that, as it appears that this code has been broken for one year now and nobody seems to have complained, I'm curious if it makes sense to keep this quirk in place. It makes the code more complex and slower just for the sake of monitors which I guess nobody uses anymore. Can't we just get rid of it? Signed-off-by: Jean Delvare <khali@linux-fr.org> Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Tested-by: Roger Leigh <rleigh@whinlatter.ukfsn.org> Tested-by: Michael Buesch <mb@bu3sch.de> Cc: "Antonino A. Daplas" <adaplas@pol.net> 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>
2007-12-14forcedeth boot delay fixAyaz Abdulla
patch 9e555930bd873d238f5f7b9d76d3bf31e6e3ce93 in mainline. Fix a long boot delay in the forcedeth driver. During initialization, the timeout for the handshake between mgmt unit and driver can be very long. The patch reduces the timeout by eliminating a extra loop around the timeout logic. Addresses http://bugzilla.kernel.org/show_bug.cgi?id=9308 Signed-off-by: Ayaz Abdulla <aabdulla@nvidia.com> Cc: Alex Howells <astinus@gentoo.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Jeff Garzik <jeff@garzik.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-12-14forcedeth: new mcp79 pci idsAyaz Abdulla
patch 490dde8990c55662596a4be71b5070bd7d382d4a in mainline. This patch adds new device ids and features for mcp79 devices into the forcedeth driver. Signed-off-by: Ayaz Abdulla <aabdulla@nvidia.com> Signed-off-by: Jeff Garzik <jgarzik@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> index 92ce2e3..f9ba0ac 100644
2007-12-14futex: fix for futex_wait signal stack corruptionSteven Rostedt
From Steven Rostedt <srostedt@redhat.com> patch ce6bd420f43b28038a2c6e8fbb86ad24014727b6 in mainline. David Holmes found a bug in the -rt tree with respect to pthread_cond_timedwait. After trying his test program on the latest git from mainline, I found the bug was there too. The bug he was seeing that his test program showed, was that if one were to do a "Ctrl-Z" on a process that was in the pthread_cond_timedwait, and then did a "bg" on that process, it would return with a "-ETIMEDOUT" but early. That is, the timer would go off early. Looking into this, I found the source of the problem. And it is a rather nasty bug at that. Here's the relevant code from kernel/futex.c: (not in order in the file) [...] smlinkage long sys_futex(u32 __user *uaddr, int op, u32 val, struct timespec __user *utime, u32 __user *uaddr2, u32 val3) { struct timespec ts; ktime_t t, *tp = NULL; u32 val2 = 0; int cmd = op & FUTEX_CMD_MASK; if (utime && (cmd == FUTEX_WAIT || cmd == FUTEX_LOCK_PI)) { if (copy_from_user(&ts, utime, sizeof(ts)) != 0) return -EFAULT; if (!timespec_valid(&ts)) return -EINVAL; t = timespec_to_ktime(ts); if (cmd == FUTEX_WAIT) t = ktime_add(ktime_get(), t); tp = &t; } [...] return do_futex(uaddr, op, val, tp, uaddr2, val2, val3); } [...] long do_futex(u32 __user *uaddr, int op, u32 val, ktime_t *timeout, u32 __user *uaddr2, u32 val2, u32 val3) { int ret; int cmd = op & FUTEX_CMD_MASK; struct rw_semaphore *fshared = NULL; if (!(op & FUTEX_PRIVATE_FLAG)) fshared = &current->mm->mmap_sem; switch (cmd) { case FUTEX_WAIT: ret = futex_wait(uaddr, fshared, val, timeout); [...] static int futex_wait(u32 __user *uaddr, struct rw_semaphore *fshared, u32 val, ktime_t *abs_time) { [...] struct restart_block *restart; restart = &current_thread_info()->restart_block; restart->fn = futex_wait_restart; restart->arg0 = (unsigned long)uaddr; restart->arg1 = (unsigned long)val; restart->arg2 = (unsigned long)abs_time; restart->arg3 = 0; if (fshared) restart->arg3 |= ARG3_SHARED; return -ERESTART_RESTARTBLOCK; [...] static long futex_wait_restart(struct restart_block *restart) { u32 __user *uaddr = (u32 __user *)restart->arg0; u32 val = (u32)restart->arg1; ktime_t *abs_time = (ktime_t *)restart->arg2; struct rw_semaphore *fshared = NULL; restart->fn = do_no_restart_syscall; if (restart->arg3 & ARG3_SHARED) fshared = &current->mm->mmap_sem; return (long)futex_wait(uaddr, fshared, val, abs_time); } So when the futex_wait is interrupt by a signal we break out of the hrtimer code and set up or return from signal. This code does not return back to userspace, so we set up a RESTARTBLOCK. The bug here is that we save the "abs_time" which is a pointer to the stack variable "ktime_t t" from sys_futex. This returns and unwinds the stack before we get to call our signal. On return from the signal we go to futex_wait_restart, where we update all the parameters for futex_wait and call it. But here we have a problem where abs_time is no longer valid. I verified this with print statements, and sure enough, what abs_time was set to ends up being garbage when we get to futex_wait_restart. The solution I did to solve this (with input from Linus Torvalds) was to add unions to the restart_block to allow system calls to use the restart with specific parameters. This way the futex code now saves the time in a 64bit value in the restart block instead of storing it on the stack. Note: I'm a bit nervious to add "linux/types.h" and use u32 and u64 in thread_info.h, when there's a #ifdef __KERNEL__ just below that. Not sure what that is there for. If this turns out to be a problem, I've tested this with using "unsigned int" for u32 and "unsigned long long" for u64 and it worked just the same. I'm using u32 and u64 just to be consistent with what the futex code uses. Signed-off-by: Steven Rostedt <srostedt@redhat.com> Signed-off-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Acked-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-12-14hrtimers: avoid overflow for large relative timeouts (CVE-2007-5966)Thomas Gleixner
patch 62f0f61e6673e67151a7c8c0f9a09c7ea43fe2b5 in mainline Relative hrtimers with a large timeout value might end up as negative timer values, when the current time is added in hrtimer_start(). This in turn is causing the clockevents_set_next() function to set an huge timeout and sleep for quite a long time when we have a clock source which is capable of long sleeps like HPET. With PIT this almost goes unnoticed as the maximum delta is ~27ms. The non-hrt/nohz code sorts this out in the next timer interrupt, so we never noticed that problem which has been there since the first day of hrtimers. This bug became more apparent in 2.6.24 which activates HPET on more hardware. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-12-14I4L: fix isdn_ioctl memory overrun vulnerabilityKarsten Keil
patch eafe1aa37e6ec2d56f14732b5240c4dd09f0613a in mainline. Fix possible memory overrun issue in the isdn ioctl code. Found by ADLAB <adlab@venustech.com.cn> Signed-off-by: Karsten Keil <kkeil@suse.de> Cc: ADLAB <adlab@venustech.com.cn> 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>
2007-12-14isdn: avoid copying overly-long stringsKarsten Keil
patch 0f13864e5b24d9cbe18d125d41bfa4b726a82e40 in mainline. Addresses http://bugzilla.kernel.org/show_bug.cgi?id=9416 Signed-off-by: Karsten Keil <kkeil@suse.de> 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>
2007-12-14libcrc32c: keep intermediate crc state in cpu orderHerbert Xu
It's upstream changeset ef19454bd437b2ba14c9cda1de85debd9f383484. [LIB] crc32c: Keep intermediate crc state in cpu order crypto/crc32.c:chksum_final() is computing the digest as *(__le32 *)out = ~cpu_to_le32(mctx->crc); so the low-level crc32c_le routines should just keep the crc in cpu order, otherwise it is getting swabbed one too many times on big-endian machines. Signed-off-by: Benny Halevy <bhalevy@fs1.bhalevy.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-12-14nf_nat: fix memset errorLi Zefan
This patch fixes an incorrect memset in the NAT code, causing misbehaviour when unloading and reloading the NAT module. Applies to stable-2.6.22 and stable-2.6.23. Please apply, thanks. [NETFILTER]: nf_nat: fix memset error Upstream commit e0bf9cf15fc30d300b7fbd821c6bc975531fab44 The size passing to memset is the size of a pointer. Fixes misbehaviour when unloading and reloading the NAT module. Signed-off-by: Li Zefan <lizf@cn.fujitsu.com> Signed-off-by: Patrick McHardy <kaber@trash.net> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-12-14tmpfs: restore missing clear_highpageHugh Dickins
patch e84e2e132c9c66d8498e7710d4ea532d1feaaac5 in mainline tmpfs was misconverted to __GFP_ZERO in 2.6.11. There's an unusual case in which shmem_getpage receives the page from its caller instead of allocating. We must cover this case by clear_highpage before SetPageUptodate, as before. Signed-off-by: Hugh Dickins <hugh@veritas.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-12-14USB: fix up EHCI startup synchronizationDavid Brownell
patch 1cb52658b4f5b10a9e91f8e1c21ca2bcc1b9a3ca in mainline. A recent patch added software synchronization during EHCI startup, so ports aren't switched away from the companion controllers after resets have started. This patch adds a short delay letting hardware finish that port switching before any new resets begin ... so both ends of that hardware race window are closed. Signed-off-by: David Brownell <dbrownell@users.sourceforge.net> Cc: Dave Miller <davem@davemloft.net> Cc: Dely Sy <dely.l.sy@intel.com> Cc: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-12-14USB: make the microtek driver and HAL cooperateOliver Neukum
patch 5cf1973a44bd298e3cfce6f6af8faa8c9d0a6d55 in mainline to make HAL like the microtek driver's devices the parent must be correctly set. Signed-off-by: Oliver Neukum <oneukum@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-12-14wait_task_stopped(): pass correct exit_code to wait_noreap_copyout()Scott James Remnant
patch e6ceb32aa25fc33f21af84cc7a32fe289b3e860c in mainline. In wait_task_stopped() exit_code already contains the right value for the si_status member of siginfo, and this is simply set in the non WNOWAIT case. If you call waitid() with a stopped or traced process, you'll get the signal in siginfo.si_status as expected -- however if you call waitid(WNOWAIT) at the same time, you'll get the signal << 8 | 0x7f Pass it unchanged to wait_noreap_copyout(); we would only need to shift it and add 0x7f if we were returning it in the user status field and that isn't used for any function that permits WNOWAIT. Signed-off-by: Scott James Remnant <scott@ubuntu.com> Signed-off-by: Oleg Nesterov <oleg@tv-sign.ru> Cc: Roland McGrath <roland@redhat.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>
2007-12-14Future of Linux 2.6.22.y seriesChristian Borntraeger
commit 5d0360ee96a5ef953dbea45873c2a8c87e77d59b upstream. We have seen ramdisk based install systems, where some pages of mapped libraries and programs were suddendly zeroed under memory pressure. This should not happen, as the ramdisk avoids freeing its pages by keeping them dirty all the time. It turns out that there is a case, where the VM makes a ramdisk page clean, without telling the ramdisk driver. On memory pressure shrink_zone runs and it starts to run shrink_active_list. There is a check for buffer_heads_over_limit, and if true, pagevec_strip is called. pagevec_strip calls try_to_release_page. If the mapping has no releasepage callback, try_to_free_buffers is called. try_to_free_buffers has now a special logic for some file systems to make a dirty page clean, if all buffers are clean. Thats what happened in our test case. The simplest solution is to provide a noop-releasepage callback for the ramdisk driver. This avoids try_to_free_buffers for ramdisk pages. Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com> Signed-off-by: Jan Kara <jack@suse.cz> Acked-by: Nick Piggin <npiggin@suse.de> Cc: "Eric W. Biederman" <ebiederm@xmission.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>
2007-12-14atl1: disable broken 64-bit DMALuca Tettamanti
atl1: disable broken 64-bit DMA [ Upstream commit: 5f08e46b621a769e52a9545a23ab1d5fb2aec1d4 ] The L1 network chip can DMA to 64-bit addresses, but multiple descriptor rings share a single register for the high 32 bits of their address, so only a single, aligned, 4 GB physical address range can be used at a time. As a result, we need to confine the driver to a 32-bit DMA mask, otherwise we see occasional data corruption errors in systems containing 4 or more gigabytes of RAM. Signed-off-by: Luca Tettamanti <kronos.it@gmail.com> Signed-off-by: Jay Cliburn <jacliburn@bellsouth.net> Acked-by: Chris Snook <csnook@redhat.com> Signed-off-by: Jeff Garzik <jeff@garzik.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-11-21Linux 2.6.22.14v2.6.22.14Greg Kroah-Hartman
2007-11-21i2c/eeprom: Recognize VGN as a valid Sony Vaio name prefixJean Delvare
patch 8b925a3dd8a4d7451092cb9aa11da727ba69e0f0 in mainline. Recent (i.e. 2005 and later) Sony Vaio laptops have names beginning with VGN rather than PCG. Update the eeprom driver so that it recognizes these. Why this matters: the eeprom driver hides private data from the EEPROMs it recognizes as Vaio EEPROMs (passwords, serial number...) so if the driver fails to recognize a Vaio EEPROM as such, the private data is exposed to the world. Signed-off-by: Jean Delvare <khali@linux-fr.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-11-21i2c/eeprom: Hide Sony Vaio serial numbersJean Delvare
patch 0f2cbd38aa377e30df3b7602abed69464d1970aa in mainline. The sysfs interface to DMI data takes care to not make the system serial number and UUID world-readable, presumably due to privacy concerns. For consistency, we should not let the eeprom driver export these same strings to the world on Sony Vaio laptops. Instead, only make them readable by root, as we already do for BIOS passwords. Signed-off-by: Jean Delvare <khali@linux-fr.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-11-21i2c-pasemi: Fix NACK detectionJean Delvare
patch be8a1f7cd4501c3b4b32543577a33aee6d2193ac in mainline. Turns out we don't actually check the status to see if there was a device out there to talk to, just if we had a timeout when doing so. Add the proper check, so we don't falsly think there are devices on the bus that are not there, etc. Signed-off-by: Olof Johansson <olof@lixom.net> Signed-off-by: Jean Delvare <khali@linux-fr.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-11-21ocfs2: fix write() performance regressionMark Fasheh
ocfs2: fix write() performance regression patch 4e9563fd55ff4479f2b118d0757d121dd0cfc39c in mainline. On file systems which don't support sparse files, Ocfs2_map_page_blocks() was reading blocks on appending writes. This caused write performance to suffer dramatically. Fix this by detecting an appending write on a nonsparse fs and skipping the read. Signed-off-by: Mark Fasheh <mark.fasheh@oracle.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-11-21ide: fix serverworks.c UDMA regressionTony Battersby
patch 0c824b51b338c808de650b440ba5f9f4a725f7fc in mainline. The patch described by the following excerpt from ChangeLog-2.6.22 makes it impossible to use UDMA on a Tyan S2707 motherboard (SvrWks CSB5): commit 2d5eaa6dd744a641e75503232a01f52d0768884c Author: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com> Date: Thu May 10 00:01:08 2007 +0200 ide: rework the code for selecting the best DMA transfer mode (v3) ... This one-line patch against 2.6.23 fixes the problem. Signed-off-by: Tony Battersby <tonyb@cybernetics.com> Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-11-21i4l: fix random freezes with AVM B1 driversKarsten Keil
patch 9713d9e650045f7f2afd81d58a068827be306993 in mainline. This fix the same issue which was debbuged for the C4 controller for the B1 versions. The capilib_ function modify or traverse a linked list without locking. This patch extends the existing locking to the calls of these function to prevent access to a list which is in the middle of a modification. Signed-off-by: Karsten Keil <kkeil@suse.de> 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>
2007-11-21i4l: Fix random hard freeze with AVM c4 cardKarsten Keil
patch 1ccfd63367c1a6aaf8b33943f18856dde85f2f0b in mainline. The patch - Includes the call to capilib_data_b3_req in the spinlock. This routine in turn calls the offending mq_enqueue routine that triggered the freeze if not locked. This should also fix other indicators of incosistent capilib_msgidqueue list, that trigger messages like: Oct 5 03:05:57 BERL0 kernel: kcapi: msgid 3019 ncci 0x30301 not on queue that we saw several times a day (usually several in a row). - Fixes all occurrences of c4_dispatch_tx to be called with active spinlock, there were some instances where no lock was active. Mostly these are in very infrequently called routines, so the additional performance penalty is minimal. Signed-off-by: Karsten Keil <kkeil@suse.de> Signed-off-by: Rainer Brestan <rainer.brestan@frequentis.com> Signed-off-by: Ralf Schlatterbeck <rsc@runtux.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>
2007-11-21USB: mutual exclusion for EHCI init and port resetsAlan Stern
patch 32fe01985aa2cb2562f6fc171e526e279abe10db in mainline. This patch (as999) fixes a problem that sometimes shows up when host controller driver modules are loaded in the wrong order. If ehci-hcd happens to initialize an EHCI controller while the companion OHCI or UHCI controller is in the middle of a port reset, the reset can fail and the companion may get very confused. The patch adds an rw-semaphore and uses it to keep EHCI initialization and port resets mutually exclusive. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Acked-by: David Brownell <david-b@pacbell.net> Cc: David Miller <davem@davemloft.net> Cc: Dely L Sy <dely.l.sy@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-11-21USB: usbserial - fix potential deadlock between write() and IRQJiri Kosina
patch acd2a847e7fee7df11817f67dba75a2802793e5d in mainline. USB: usbserial - fix potential deadlock between write() and IRQ usb_serial_generic_write() doesn't disable interrupts when taking port->lock, and could therefore deadlock with usb_serial_generic_read_bulk_callback() being called from interrupt, taking the same lock. Fix it. Signed-off-by: Jiri Kosina <jkosina@suse.cz> Acked-by: Larry Finger <larry.finger@lwfinger.net> Cc: Marcin Slusarz <marcin.slusarz@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-11-21USB: kobil_sct: trivial backport to fix libctFrank Seidel
Backport of a patch by Alan Cox <alan@lxorguk.ukuu.org.uk> in the kernel tree with commit 94d0f7eac77a84da2cee41b8038796891f75f09e Original comments: USB: kobil_sct: Rework driver No hardware but this driver is currently totally broken so we can't make it much worse. Remove all tbe broken invalid termios handling and replace it with a proper set_termios method. Frank's comments: Without this patch the userspace libct (to access the cardreader) segfaults. Signed-off-by: Frank Seidel <fseidel@suse.de> Cc: Alan Cox <alan@lxorguk.ukuu.org.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-11-21hptiop: avoid buffer overflow when returning sense dataHighPoint Linux Team
patch 0fec02c93f60fb44ba3a24a0d3e4a52521d34d3f in mainline. avoid buffer overflow when returning sense data. With current adapter firmware the driver is working but future firmware updates may return sense data larger than 96 bytes, causing overflow on scp->sense_buffer and a kernel crash. This fix should be backported to earlier kernels. Signed-off-by: HighPoint Linux Team <linux@highpoint-tech.com> Signed-off-by: James Bottomley <James.Bottomley@steeleye.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Acked-by: Matthew Wilcox <willy@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
generated by cgit v1.2.3 (git 2.0.4) at 2024-05-28 17:26:38 +0000