- 02 May, 2007 16 commits
-
-
Olaf Kirch authored
This fixes and OOPS due to incorrect socket orpahning in the IRDA stack. [IrDA]: Correctly handling socket error This patch fixes an oops first reported in mid 2006 - see http://lkml.org/lkml/2006/8/29/358 The cause of this bug report is that when an error is signalled on the socket, irda_recvmsg_stream returns without removing a local wait_queue variable from the socket's sk_sleep queue. This causes havoc further down the road. In response to this problem, a patch was made that invoked sock_orphan on the socket when receiving a disconnect indication. This is not a good fix, as this sets sk_sleep to NULL, causing applications sleeping in recvmsg (and other places) to oops. This is against the latest net-2.6 and should be considered for -stable inclusion. Signed-off-by:
Olaf Kirch <olaf.kirch@oracle.com> Signed-off-by:
Samuel Ortiz <samuel@sortiz.org> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Aubrey.Li authored
Netpoll UDP input handler needs to pull up the UDP headers and handle receive checksum offloading properly just like the normal UDP input path does else we get corrupted checksums. [NET]: Fix UDP checksum issue in net poll mode. In net poll mode, the current checksum function doesn't consider the kind of packet which is padded to reach a specific minimum length. I believe that's the problem causing my test case failed. The following patch fixed this issue. Signed-off-by:
Aubrey.Li <aubreylee@gmail.com> Signed-off-by:
-
John Heffner authored
In 2.6.18 a change was made to the tcp_mem[] calculations, but this causes regressions for some folks up to 2.6.20 The following fix to smooth out the calculation from the pending 2.6.21 tree by John Heffner fixes the problem for these folks. [TCP]: Fix tcp_mem[] initialization. Change tcp_mem initialization function. The fraction of total memory is now a continuous function of memory size, and independent of page size. Signed-off-by:
John Heffner <jheffner@psc.edu> Signed-off-by:
-
Tom "spot" Callaway authored
[SPARC64]: Fix inline directive in pci_iommu.c While building a test kernel for the new esp driver (against git-current), I hit this bug. Trivial fix, put the inline declaration in the right place. :) Signed-off-by:
Tom "spot" Callaway <tcallawa@redhat.com> Signed-off-by:
-
David Miller authored
The 32-bit syscall trampoline for sys_ipc() on sparc64 was sign extending various arguments, which is bogus when using compat_sys_ipc() since that function expects zero extended copies of all the arguments. This bug breaks the sparc64 kernel when built with gcc-4.2.x among other things. [SPARC64]: Fix arg passing to compat_sys_ipc(). Do not sign extend args using the sys32_ipc stub, that is buggy and unnecessary. Based upon an excellent report by Mikael Pettersson. Signed-off-by:
-
David Miller authored
[SCSI] QLOGICPTI: Do not unmap DMA unless we actually mapped something. We only map DMA when cmd->request_bufflen is non-zero for non-sg buffers, we thus should make the same check when unmapping. Based upon a report from Pasi Pirhonen. Signed-off-by:
-
David Miller authored
[SPARC64]: Fix SBUS IOMMU allocation code. There are several IOMMU allocator bugs. Instead of trying to fix this overly complicated code, just mirror the PCI IOMMU arena allocator which is very stable and well stress tested. I tried to make the code as identical as possible so we can switch sun4u PCI and SBUS over to a common piece of IOMMU code. All that will be need are two callbacks, one to do a full IOMMU flush and one to do a streaming buffer flush. This patch gets rid of a lot of hangs and mysterious crashes on SBUS sparc64 systems, at least for me. Signed-off-by:
-
Hugh Dickins authored
sys_madvise has down_write of mmap_sem, then madvise_remove calls vmtruncate_range which takes i_mutex and i_alloc_sem: no, we can easily devise deadlocks from that ordering. madvise_remove drop mmap_sem while calling vmtruncate_range: luckily, since madvise_remove doesn't split or merge vmas, it's easy to handle this case with a NULL prev, without restructuring sys_madvise. (Though sad to retake mmap_sem when it's unlikely to be needed, and certainly down_read is sufficient for MADV_REMOVE, unlike the other madvices.) Signed-off-by:
Hugh Dickins <hugh@veritas.com> Signed-off-by:
-
Hugh Dickins authored
shmem_truncate_range has its own truncate_inode_pages_range, to free any pages racily instantiated while it was in progress: a SHMEM_PAGEIN flag is set when this might have happened. But holepunching gets no chance to clear that flag at the start of vmtruncate_range, so it's always set (unless a truncate came just before), so holepunch almost always does this second truncate_inode_pages_range. shmem holepunch has unlikely swap<->file races hereabouts whatever we do (without a fuller rework than is fit for this release): I was going to skip the second truncate in the punch_hole case, but Miklos points out that would make holepunch correctness more vulnerable to swapoff. So keep the second truncate, but follow it by an unmap_mapping_range to eliminate the disconnected pages (freed from pagecache while still mapped in userspace) that it might have left behind. Signed-off-by:
-
Hugh Dickins authored
Miklos Szeredi observes that during truncation of shmem page directories, info->lock is released to improve latency (after lowering i_size and next_index to exclude races); but this is quite wrong for holepunching, which receives no such protection from i_size or next_index, and is left vulnerable to races with shmem_unuse, shmem_getpage and shmem_writepage. Hold info->lock throughout when holepunching? No, any user could prevent rescheduling for far too long. Instead take info->lock just when needed: in shmem_free_swp when removing the swap entries, and whenever removing a directory page from the level above. But so long as we remove before scanning, we can safely skip taking the lock at the lower levels, except at misaligned start and end of the hole. Signed-off-by:
-
Hugh Dickins authored
Miklos Szeredi observes BUG_ON(!entry) in shmem_writepage() triggered in rare circumstances, because shmem_truncate_range() erroneously removes partially truncated directory pages at the end of the range: later reclaim on pages pointing to these removed directories triggers the BUG. Indeed, and it can also cause data loss beyond the hole. Fix this as in the patch proposed by Miklos, but distinguish between "limit" (how far we need to search: ignore truncation's next_index optimization in the holepunch case - if there are races it's more consistent to act on the whole range specified) and "upper_limit" (how far we can free directory pages: generally we must be careful to keep partially punched pages, but can relax at end of file - i_size being held stable by i_mutex). Signed-off-by:
-
Avi Kivity authored
PAGE_MASK is an unsigned long, so using it to mask physical addresses on i386 (which are 64-bit wide) leads to truncation. This can result in page->private of unrelated memory pages being modified, with disasterous results. Fix by not using PAGE_MASK for physical addresses; instead calculate the correct value directly from PAGE_SIZE. Also fix a similar BUG_ON(). Acked-by:
Ingo Molnar <mingo@elte.hu> Signed-off-by:
Avi Kivity <avi@qumranet.com> Signed-off-by:
-
Avi Kivity authored
KVM shadow page tables are always in pae mode, regardless of the guest setting. This means that a guest pde (mapping 4MB of memory) is mapped to two shadow pdes (mapping 2MB each). When the guest writes to a pte or pde, we intercept the write and emulate it. We also remove any shadowed mappings corresponding to the write. Since the mmu did not account for the doubling in the number of pdes, it removed the wrong entry, resulting in a mismatch between shadow page tables and guest page tables, followed shortly by guest memory corruption. This patch fixes the problem by detecting the special case of writing to a non-pae pde and adjusting the address and number of shadow pdes zapped accordingly. Acked-by:
-
Jiri Kosina authored
HID: zeroing of bytes in output fields is bogus This patch removes bogus zeroing of unused bits in output reports, introduced in Simon's patch in commit d4ae650a. According to the specification, any sane device should not care about values of unused bits. What is worse, the zeroing is done in a way which is broken and might clear certain bits in output reports which are actually _used_ - a device that has multiple fields with one value of the size 1 bit each might serve as an example of why this is bogus - the second call of hid_output_report() would clear the first bit of report, which has already been set up previously. This patch will break LEDs on SpaceNavigator, because this device is broken and takes into account the bits which it shouldn't touch. The quirk for this particular device will be provided in a separate patch. Signed-off-by:
Jiri Kosina <jkosina@suse.cz> Signed-off-by:
-
Michael S. Tsirkin authored
In mthca_arbel_fmr_unmap(), the high bits of the key are masked off. This gets rid of the effect of adjust_key(), which makes sure that bits 3 and 23 of the key are equal when the Sinai throughput optimization is enabled, and so it may happen that an FMR will end up with bits 3 and 23 in the key being different. This causes data corruption, because when enabling the throughput optimization, the driver promises the HCA firmware that bits 3 and 23 of all memory keys will always be equal. Fix by re-applying adjust_key() after masking the key. Thanks to Or Gerlitz for reproducing the problem, and Ariel Shahar for help in debug. Signed-off-by:
Michael S. Tsirkin <mst@dev.mellanox.co.il> Signed-off-by:
Roland Dreier <rolandd@cisco.com> Signed-off-by:
-
NeilBrown authored
sk_info_authunix is not being protected properly so the object that it points to can be cache_put twice, leading to corruption. We borrow svsk->sk_defer_lock to provide the protection. We should probably rename that lock to have a more generic name - later. Thanks to Gabriel for reporting this. Cc: Greg Banks <gnb@melbourne.sgi.com> Cc: Gabriel Barazer <gabriel@oxeva.fr> Signed-off-by:
Neil Brown <neilb@suse.de> Signed-off-by:
-
- 27 Apr, 2007 3 commits
-
-
Greg Kroah-Hartman authored
-
YOSHIFUJI Hideaki authored
[IPV6]: Fix thinko in ipv6_rthdr_rcv() changes. Signed-off-by:
YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org> Signed-off-by:
-
Sergey Vlasov authored
[IPV4] nl_fib_lookup: Initialise res.r before fib_res_put(&res) When CONFIG_IP_MULTIPLE_TABLES is enabled, the code in nl_fib_lookup() needs to initialize the res.r field before fib_res_put(&res) - unlike fib_lookup(), a direct call to ->tb_lookup does not set this field. Signed-off-by:
Sergey Vlasov <vsu@altlinux.ru> Signed-off-by:
-
- 26 Apr, 2007 2 commits
-
-
Greg Kroah-Hartman authored
-
YOSHIFUJI Hideaki authored
[IPV6]: Disallow RH0 by default. A security issue is emerging. Disallow Routing Header Type 0 by default as we have been doing for IPv4. Note: We allow RH2 by default because it is harmless. Signed-off-by:
-
- 25 Apr, 2007 2 commits
-
-
Greg Kroah-Hartman authored
-
Alexey Kuznetsov authored
[NETLINK]: Infinite recursion in netlink. Reply to NETLINK_FIB_LOOKUP messages were misrouted back to kernel, which resulted in infinite recursion and stack overflow. The bug is present in all kernel versions since the feature appeared. The patch also makes some minimal cleanup: 1. Return something consistent (-ENOENT) when fib table is missing 2. Do not crash when queue is empty (does not happen, but yet) 3. Put result of lookup Signed-off-by:
Alexey Kuznetsov <kuznet@ms2.inr.ac.ru> Signed-off-by:
-
- 13 Apr, 2007 17 commits
-
-
Greg Kroah-Hartman authored
-
Chuck Ebbert authored
Update libata drive blacklist to the latest from 2.6.21 Removes one duplicate entry from blacklist table, adds several entries for drives with broken NCQ. [diff between 2.6.20 and 2.6.21-rc6, with one entry removed that required new libata features] Signed-off-by:
Chuck Ebbert <cebbert@redhat.com> Signed-off-by:
-
Brian Pomerantz authored
When the dump cannot occur most likely because of a full file system and the page to be written is the zero page, the call to page_cache_release() is missed. Signed-off-by:
Brian Pomerantz <bapper@mvista.com> Cc: Hugh Dickins <hugh@veritas.com> Cc: Nick Piggin <nickpiggin@yahoo.com.au> Cc: David Howells <dhowells@redhat.com> Cc: <stable@kernel.org> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
-
Andrew Morton authored
Revert b46be050. Same reasoning as for ext3. Cc: Kirill Korotaev <dev@openvz.org> Cc: Ingo Molnar <mingo@elte.hu> Cc: Ken Chen <kenneth.w.chen@intel.com> Cc: Andrey Savochkin <saw@sw.ru> Cc: <linux-ext4@vger.kernel.org> Cc: Dmitriy Monakhov <dmonakhov@openvz.org> Signed-off-by:
-
Andrew Morton authored
Revert e92a4d59. Dmitry points out "When we block_prepare_write() failed while ext3_prepare_write() we jump to "failure" label and call ext3_prepare_failure() witch search last mapped bh and invoke commit_write untill it. This is wrong!! because some bh from begining to the last mapped bh may be not uptodate. As a result we commit to disk not uptodate page content witch contains garbage from previous usage." and "Unexpected file size increasing." Call trace the same as it was in first issue but result is different. For example we have file with i_size is zero. we want write two blocks , but fs has only one free block. ->ext3_prepare_write(...from == 0, to == 2048) retry: ->block_prepare_write() == -ENOSPC# we failed but allocated one block here. ->ext3_prepare_failure() ->commit_write( from == 0, to == 1024) # after this i_size becomes 1024 :) if (ret == -ENOSPC && ext3_should_retry_alloc(inode->i_sb, &retries)) goto retry; Finally when all retries will be spended ext3_prepare_failure return -ENOSPC, but i_size was increased and later block trimm procedures can't help here. We don't appear to have the horsepower to fix these issues, so let's put things back the way they were for now. Cc: Kirill Korotaev <dev@openvz.org> Cc: Ingo Molnar <mingo@elte.hu> Cc: Ken Chen <kenneth.w.chen@intel.com> Cc: Andrey Savochkin <saw@sw.ru> Cc: <linux-ext4@vger.kernel.org> Cc: Dmitriy Monakhov <dmonakhov@openvz.org> Signed-off-by:
-
Albert Lee authored
libata: Clear tf before doing request sense (take 3) patch 2/4: Clear tf before doing request sense. This fixes the AOpen 56X/AKH timeout problem. (http://bugzilla.kernel.org/show_bug.cgi?id=8244) Signed-off-by:
Albert Lee <albertcc@tw.ibm.com> Signed-off-by:
Jeff Garzik <jeff@garzik.org> Cc: Chuck Ebbert <cebbert@redhat.com> Signed-off-by:
-
Mark Lord authored
2.6.21 fix lba48 bug in libata fill_result_tf() Current 2.6.21 libata does the following: void ata_tf_read(struct ata_port *ap, struct ata_taskfile *tf) { struct ata_ioports *ioaddr = &ap->ioaddr; tf->command = ata_check_status(ap); ... if (tf->flags & ATA_TFLAG_LBA48) { iowrite8(tf->ctl | ATA_HOB, ioaddr->ctl_addr); tf->hob_feature = ioread8(ioaddr->error_addr); ... } } ... static void fill_result_tf(struct ata_queued_cmd *qc) { struct ata_port *ap = qc->ap; ap->ops->tf_read(ap, &qc->result_tf); qc->result_tf.flags = qc->tf.flags; } Based on this, those last two statements fill_result_tf() appear to me to be in the wrong order, in that the tf->flags are uninitialized at the point where tf_read() is invoked. So for lba48 commands, tf_read() won't be reading back the full lba48 register contents.. Correct? This patch corrects fill_result_tf() so that the flags get copied to result_tf before they are used by tf_read(). Signed-off-by:Mark Lord <mlord@pobox.com> Signed-off-by:
-
Conke Hu authored
ahci.c: walkaround for SB600 SATA internal error issue There is a HW issue in ATI SB600 SATA that PxSERR.E should not be set on some conditions, for example, when there is no media in SATA CD/DVD drive or media is not ready, AHCI controller fails to execute ATAPI commands and reports PORT_IRQ_TF_ERR, but ATI SB600 SATA controller sets PxSERR.E at the same time, which is not necessary. This patch is just to ignore the INTERNAL ERROR in such case. Without this patch, ahci error handler will report many errors as below: ----------- cut from dmesg ----------- ata9: soft resetting port ata9: SATA link up 1.5 Gbps (SStatus 113 SControl 300) ata9.00: configured for UDMA/33 ata9: EH complete ata9.00: exception Emask 0x40 SAct 0x0 SErr 0x800 action 0x2 ata9.00: (irq_stat 0x40000001) ata9.00: cmd a0/00:00:00:00:20/00:00:00:00:00/a0 tag 0 cdb 0x0 data 0 res 51/24:03:00:00:20/00:00:00:00:00/a0 Emask 0x40 (internal error) ata9: soft resetting port ata9: SATA link up 1.5 Gbps (SStatus 113 SControl 300) ata9.00: configured for UDMA/33 ata9: EH complete ata9.00: exception Emask 0x40 SAct 0x0 SErr 0x800 action 0x2 ata9.00: (irq_stat 0x40000001) ata9.00: cmd a0/01:00:00:00:00/00:00:00:00:00/a0 tag 0 cdb 0x43 data 12 in res 51/24:03:00:00:00/00:00:00:00:00/a0 Emask 0x40 (internal error) -------- end cut --------- Signed-off-by:Conke Hu <conke.hu@amd.com> Signed-off-by:
-
Mark Lord authored
libata bugfix: preserve LBA bit for HDIO_DRIVE_TASK Preserve the LBA bit in the DevSel/Head register for HDIO_DRIVE_TASK. Signed-off-by:
-
John W. Linville authored
[PATCH] softmac: avoid assert in ieee80211softmac_wx_get_rate Unconfigured bcm43xx device can hit an assert() during wx_get_rate queries. This is because bcm43xx calls ieee80211softmac_start late (i.e. during open instead of probe). bcm43xx_net_open -> bcm43xx_init_board -> bcm43xx_select_wireless_core -> ieee80211softmac_start Fix is to check that device is running before completing ieee80211softmac_wx_get_rate. Signed-off-by:John W. Linville <linville@tuxdriver.com> Cc: Chuck Ebbert <cebbert@redhat.com> Signed-off-by:
-
Neil Brown authored
From Neil Brown <neilb@suse.de> [PATCH] knfsd: allow nfsd READDIR to return 64bit cookies ->readdir passes lofft_t offsets (used as nfs cookies) to nfs3svc_encode_entry{,_plus}, but when they pass it on to encode_entry it becomes an 'off_t', which isn't good. So filesystems that returned 64bit offsets would lose. Signed-off-by:Linus Torvalds <torvalds@linux-foundation.org> Cc: Chuck Ebbert <cebbert@redhat.com> Signed-off-by:
-
Suleiman Souhlal authored
ide: use correct IDE error recovery IDE error recovery is using IDLE IMMEDIATE if the drive is busy or has DRQ set. This violates the ATA spec (can only send IDLEà IMMEDIATE when drive is not busy) and really hoses up some drives (modern drives will not be able to recover using this error handling). The correct thing to do is issue a SRST followed by a SET FEATURES command. This is what Western Digital recommends for error recovery and what Western Digital says Windows does. à Ità also does not violate the ATA spec as far as I can tell. Bart: * port the patch over the current tree * undo the recalibration code removal * send SET FEATURES command after checking for good drive status * don't check whether the current request is of REQ_TYPE_ATA_{CMD,TASK} type because we need to send SET FEATURES before handling any requests * some pre-ATA4 drives require INITIALIZE DEVICE PARAMETERS command before other commands (except IDENTIFY) so send SET FEATURES only if there are no pending drive->special requests * update comments and patch description * any bugs introduced by this patch are mine and not Suleiman's :-) Signed-off-by:Suleiman Souhlal <suleiman@google.com> Acked-by:
Alan Cox <alan@redhat.com> Cc: Chuck Ebbert <cebbert@redhat.com> Signed-off-by:
Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
-
David Miller authored
[TCP]: slow_start_after_idle should influence cwnd validation too For the cases that slow_start_after_idle are meant to deal with, it is almost a certainty that the congestion window tests will think the connection is application limited and we'll thus decrease the cwnd there too. This defeats the whole point of setting slow_start_after_idle to zero. So test it there too. We do not cancel out the entire tcp_cwnd_validate() function so that if the sysctl is changed we still have the validation state maintained. Signed-off-by:
-
Patrick McHardy authored
[NET_SCHED]: cls_tcindex: fix compatibility breakage Userspace uses an integer for TCA_TCINDEX_SHIFT, the kernel was changed to expect and use a u16 value in 2.6.11, which broke compatibility on big endian machines. Change back to use int. Reported by Ole Reinartz <ole.reinartz@gmx.de> Signed-off-by:
Patrick McHardy <kaber@trash.net> Signed-off-by:
-
Herbert Xu authored
[IPSEC]: Reject packets within replay window but outside the bit mask Up until this point we've accepted replay window settings greater than 32 but our bit mask can only accomodate 32 packets. Thus any packet with a sequence number within the window but outside the bit mask would be accepted. This patch causes those packets to be rejected instead. Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by:
-
John Heffner authored
[TCP]: Do receiver-side SWS avoidance for rcvbuf < MSS. Signed-off-by:
-
David Miller authored
[SCSI]: Fix scsi_send_eh_cmnd scatterlist handling This fixes a regression caused by commit: 2dc611de The sense buffer code in scsi_send_eh_cmnd was changed to use alloc_page() and a scatter list, but the sense data copy was not updated to match so what we actually get in the sense buffer is total grabage starting with the kernel address of the struct page we got. Basically the stack frame of scsi_send_eh_cmd() is what ends up in the sense buffer. Depending upon how pointers look on a given platform, you can end up getting sr_ioctl.c errors when you mount a cdrom. If the CDROM gives a check condition for GPCMD_GET_CONFIGURATION issued by drivers/cdrom/cdrom.c:cdrom_mmc_profile(), sr_ioctl will spit out this error message in sr_do_ioctl() with the way pointers are on sparc64: default: printk(KERN_ERR "%s: CDROM (ioctl) error, command: ", cd->cdi.name); __scsi_print_command(cgc->cmd); scsi_print_sense_hdr("sr", &sshdr); err = -EIO; This is the error Tom Callaway reported in: http://marc.info/?l=linux-sparc&m=117407453208101&w=2 Anyways, fix this by using page_address(sgl.page) which is OK because we know this is low-mem due to GFP_ATOMIC. Signed-off-by:
Christoph Hellwig <hch@lst.de> Signed-off-by:
-
