- 13 Aug, 2010 3 commits
-
-
H. Peter Anvin authored
commit a01c7800 upstream. In nvram_write, first of all, correctly handle the case where the file pointer is already beyond the end; we should return EOF in that case. Second, make the logic a bit more explicit so that gcc can statically prove that the copy_from_user() is safe. Once the condition of the beyond-end filepointer is eliminated, the copy is safe but gcc can't prove it, causing build failures for i386 allyesconfig. Third, eliminate the entirely superfluous variable "len", and just use the passed-in variable "count" instead. Signed-off-by:
H. Peter Anvin <hpa@zytor.com> Cc: Arjan van de Ven <arjan@infradead.org> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Wim Van Sebroeck <wim@iguana.be> Cc: Frederic Weisbecker <fweisbec@gmail.com> LKML-Reference: <tip-*@git.kernel.org> Cc: Stephen Hemminger <shemminger@vyatta.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Sam Ravnborg authored
commit e32e78c5 upstream. Thomas Backlund reported that the powerpc build broke with make 3.82. It failed with the following message: arch/powerpc/Makefile:183: *** mixed implicit and normal rules. Stop. The fix is to avoid mixing non-wildcard and wildcard targets. Reported-by:
Thomas Backlund <tmb@mandriva.org> Tested-by:
Sam Ravnborg <sam@ravnborg.org> Signed-off-by:
Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by:
-
Tejun Heo authored
commit 213373cf upstream. SIDPR window registers are shared across ports and as each access is done in two steps, accesses to different ports under EH may race. This primarily is caused by incorrect host locking in EH context and should be fixed by defining locking requirements for each EH operation which can be used during EH and enforcing them but for now work around the problem by adding a dedicated SIDPR lock and grabbing it for each SIDPR access. Signed-off-by:
Tejun Heo <tj@kernel.org> Reported-by:
Mark Knecht <markknecht@gmail.com> Reported-by:
Paul Check <paul@thechecks.ca> Signed-off-by:
Jeff Garzik <jgarzik@redhat.com> Signed-off-by:
-
- 10 Aug, 2010 35 commits
-
-
Greg Kroah-Hartman authored
-
Larry Finger authored
commit 9d1ac34e upstream. In kernel Bugzilla #15825 (2 users), in a wireless mailing list thread (http://lists.infradead.org/pipermail/b43-dev/2010-May/000124.html), and on a netbook owned by John Linville (http://marc.info/?l=linux-wireless&m=127230751408818&w=4), there are reports of ssb failing to detect an SPROM at the normal location. After studying the MMIO trace dump for the Broadcom wl driver, it was determined that the affected boxes had a relocated SPROM. This patch fixes all systems that have reported this problem. Signed-off-by:
Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by:
John W. Linville <linville@tuxdriver.com> Cc: Ben Hutchings <ben@decadent.org.uk> Signed-off-by:
-
Christoph Fritz authored
commit da1fdb02 upstream. Ethernet driver b44 does register ssb by it's pcihost_wrapper and doesn't set ssb_chipcommon. A check on this value introduced with commit d53cdbb9 and ea2db495 triggers: BUG: unable to handle kernel NULL pointer dereference at 00000010 IP: [<c1266c36>] ssb_is_sprom_available+0x16/0x30 Signed-off-by:
Christoph Fritz <chf.fritz@googlemail.com> Signed-off-by:
-
Rafał Miłecki authored
commit ea2db495 upstream. Our offset handling becomes even a little more hackish now. For some reason I do not understand all offsets as inrelative. It assumes base offset is 0x1000 but it will work for now as we make offsets relative anyway by removing base 0x1000. Should be cleaner however. Signed-off-by:
Rafał Miłecki <zajec5@gmail.com> Signed-off-by:
-
John W. Linville authored
commit d53cdbb9 upstream. Attempting to read registers that don't exist on the SSB bus can cause hangs on some boxes. At least some b43 devices are 'in the wild' that don't have SPROMs at all. When the SSB bus support loads, it attempts to read these (non-existant) SPROMs and causes hard hangs on the box -- no console output, etc. This patch adds some intelligence to determine whether or not the SPROM is present before attempting to read it. This avoids those hard hangs on those devices with no SPROM attached to their SSB bus. The SSB-attached devices (e.g. b43, et al.) won't work, but at least the box will survive to test further patches. :-) Signed-off-by:
-
Greg Kroah-Hartman authored
Turns out this isn't the best way to resolve this issue. The individual patches will be applied instead. Cc: Larry Finger <Larry.Finger@lwfinger.net> Cc: Ben Hutchings <ben@decadent.org.uk> Signed-off-by: -
Zhao Yakui authored
commit 6363ee6f upstream. On some laptops there is no HDMI/DP. But the xrandr still reports several disconnected HDMI/display ports. In such case the user will be confused. >DVI1 disconnected (normal left inverted right x axis y axis) >DP1 disconnected (normal left inverted right x axis y axis) >DVI2 disconnected (normal left inverted right x axis y axis) >DP2 disconnected (normal left inverted right x axis y axis) >DP3 disconnected (normal left inverted right x axis y axis) This patch set is to use the child device parsed in VBT to decide whether the HDMI/DP/LVDS/TV should be initialized. Parse the child device from VBT. The device class type is also added for LFP, TV, HDMI, DP output. https://bugs.freedesktop.org/show_bug.cgi?id=22785Signed-off-by:
Zhao Yakui <yakui.zhao@intel.com> Reviewed-by:
Adam Jackson <ajax@redhat.com> Signed-off-by:
Eric Anholt <eric@anholt.net> Acked-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
-
Adam Jackson authored
Combined patches from 2.6.33 for fixing LVDS detection. 7cf4f69d drm/i915: Don't set up the LVDS if it isn't in the BIOS device table. 38b3037e drm/i915: Fix LVDS presence check 6e36595a drm/i915: Declare the new VBT parsing functions as static 11ba1592 drm/i915: Don't check for lid presence when detecting LVDS Acked-by:
-
Jeremy Fitzhardinge authored
commit 8a22b999 upstream. xen_sched_clock only counts unstolen time. In principle this should be useful to the Linux scheduler so that it knows how much time a process actually consumed. But in practice this doesn't work very well as the scheduler expects the sched_clock time to be synchronized between cpus. It also uses sched_clock to measure the time a task spends sleeping, in which case "unstolen time" isn't meaningful. So just use plain xen_clocksource_read to return wallclock nanoseconds for sched_clock. Signed-off-by:
Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> Signed-off-by:
-
Michael Neuling authored
An allmodconfig compile on ppc64 with 2.6.32.17 currently gives this error fs/cifs/dns_resolve.h:27: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'cifs_init_dns_resolver' This adds the correct header file to fix this. Signed-off-by:
Michael Neuling <mikey@neuling.org> Cc: David Howells <dhowells@redhat.com> Signed-off-by:
-
David Howells authored
commit 51c20fcc upstream. Remove the __exit mark from cifs_exit_dns_resolver() as it's called by the module init routine in case of error, and so may have been discarded during linkage. Signed-off-by:
David Howells <dhowells@redhat.com> Acked-by:
Jeff Layton <jlayton@redhat.com> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
Dave Airlie authored
commit 88be12c4 upstream. Otherwise we can get an oops if the user has no get_ref/put_ref requirement. Signed-off-by:
Dave Airlie <airlied@redhat.com> Signed-off-by:
-
Bob Peterson authored
commit 728a756b upstream. This patch fixes a kernel Oops in the GFS2 rename code. The problem was in the way the gfs2 directory code was trying to re-use sentinel directory entries. In the failing case, gfs2's rename function was renaming a file to another name that had the same non-trivial length. The file being renamed happened to be the first directory entry on the leaf block. First, the rename code (gfs2_rename in ops_inode.c) found the original directory entry and decided it could do its job by simply replacing the directory entry with another. Therefore it determined correctly that no block allocations were needed. Next, the rename code deleted the old directory entry prior to replacing it with the new name. Therefore, the soon-to-be replaced directory entry was temporarily made into a directory entry "sentinel" or a place holder at the start of a leaf block. Lastly, it went to re-add the replacement directory entry in that leaf block. However, when gfs2_dirent_find_space was looking for space in the leaf block, it used the wrong value for the sentinel. That threw off its calculations so later it decides it can't really re-use the sentinel and therefore must allocate a new leaf block. But because it previously decided to re-use the directory entry, it didn't waste the time to grab a new block allocation for the inode. Therefore, the inode's i_alloc pointer was still NULL and it crashes trying to reference it. In the case of sentinel directory entries, the entire dirent is reused, not just the "free space" portion of it, and therefore the function gfs2_dirent_find_space should use the value 0 rather than GFS2_DIRENT_SIZE(0) for the actual dirent size. Fixing this calculation enables the reproducer programs to work properly. Signed-off-by:
Bob Peterson <rpeterso@redhat.com> Signed-off-by:
Steven Whitehouse <swhiteho@redhat.com> Signed-off-by:
-
James Bottomley authored
commit a91c1be2 upstream. we also need to clean up and free the cdev. Reported-by:
Jani Nikula <ext-jani.1.nikula@nokia.com> Signed-off-by:
James Bottomley <James.Bottomley@suse.de> Signed-off-by:
-
Dan Rosenberg authored
commit 1817176a upstream. This patch prevents user "foo" from using the SWAPEXT ioctl to swap a write-only file owned by user "bar" into a file owned by "foo" and subsequently reading it. It does so by checking that the file descriptors passed to the ioctl are also opened for reading. Signed-off-by:
Dan Rosenberg <dan.j.rosenberg@gmail.com> Reviewed-by:
Christoph Hellwig <hch@lst.de> Signed-off-by:
-
Johannes Berg authored
commit ccb6c136 upstream. When kernel-internal users use cfg80211_get_bss() to get a reference to a BSS struct, they may end up getting one that would have been removed from the list if there had been any userspace access to the list. This leads to inconsistencies and problems. Fix it by making cfg80211_get_bss() ignore BSSes that cfg80211_bss_expire() would remove. Fixes http://bugzilla.intellinuxwireless.org/show_bug.cgi?id=2180Reported-by:
Jiajia Zheng <jiajia.zheng@intel.com> Tested-by:
Johannes Berg <johannes.berg@intel.com> Signed-off-by:
-
Johannes Berg authored
commit 643f82e3 upstream. Ever since mac80211/drivers are no longer fully in charge of keeping track of the auth status, trying to make them do so will fail. Instead of warning and reporting the deauthentication to userspace, cfg80211 must simply ignore it so that spurious deauthentications, e.g. before starting authentication, aren't seen by userspace as actual deauthentications. Reported-by:
Paul Stewart <pstew@google.com> Signed-off-by:
-
Stanislaw Gruszka authored
commit d28232b4 upstream. Fix possible double priv->mutex lock introduced by commit a69b03e9 "iwlwifi: cancel scan watchdog in iwl_bg_abort_scan" . We can not call cancel_delayed_work_sync(&priv->scan_check) with priv->mutex locked because workqueue function iwl_bg_scan_check() take that lock internally. We do not need to synchronize when canceling priv->scan_check work. We can avoid races (sending double abort command or send no command at all) using STATUS_SCAN_ABORT bit. Moreover current iwl_bg_scan_check() code seems to be broken, as we should not send abort commands when currently aborting. Signed-off-by:
Stanislaw Gruszka <sgruszka@redhat.com> Signed-off-by:
-
Felix Fietkau authored
commit 4cee7861 upstream. When an aggregation session is being cleaned up, while the tx status for some frames is being processed, the TID is flushed and its buffers are sent out. Unfortunately that left the pending un-acked frames unprocessed, thus leaking buffers. Fix this by reordering the code so that those frames are processed first, before the TID is flushed. Signed-off-by:
Felix Fietkau <nbd@openwrt.org> Signed-off-by:
-
Felix Fietkau authored
commit f860d526 upstream. When issuing a reset, the TSF value is lost in the hardware because of the 913x specific cold reset. As with some AR9280 cards, the TSF needs to be preserved in software here. Additionally, there's an issue that frequently prevents a successful TSF write directly after the chip reset. In this case, repeating the TSF write after the initval-writes usually works. This patch detects failed TSF writes and recovers from them, taking into account the delay caused by the initval writes. Signed-off-by:
Björn Smedman <bjorn.smedman@venatech.se> Signed-off-by:
-
Felix Fietkau authored
commit 03b4776c upstream. PDADC values were only generated for values surrounding the target index, however not for the target index itself, leading to a minor error in the generated curve. Signed-off-by:
-
John W. Linville authored
commit 4c85ab11 upstream. https://bugzilla.kernel.org/show_bug.cgi?id=16476Signed-off-by:
Luis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by:
-
Dan Carpenter authored
commit 5c4bfa17 upstream. This is an off by one bug because strlen() doesn't count the NULL terminator. We strcpy() addr into a fixed length array of size UNIX_PATH_MAX later on. The addr variable is the name of the device being mounted. Signed-off-by:
Dan Carpenter <error27@gmail.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
Bruce Allan authored
commit ff847ac2 upstream. The MAC-PHY interconnect on 82577/82578 uses a power management feature (called K1) which must be disabled when in 1Gbps due to a hardware issue on these parts. The #define bit setting used to enable/disable K1 is incorrect and can cause PHY register accesses to stop working altogether until the next device reset. This patch sets the register correctly. This issue is present in kernels since 2.6.32. Signed-off-by:
Bruce Allan <bruce.w.allan@intel.com> Tested-by:
Jeff Pieper <jeffrey.e.pieper@intel.com> Signed-off-by:
Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by:
-
Dean Nelson authored
commit 36f2407f upstream. Should e1000_test_msi() fail to see an msi interrupt, it attempts to fallback to legacy INTx interrupts. But an error in the code may prevent this from happening correctly. Before calling e1000_test_msi_interrupt(), e1000_test_msi() disables SERR by clearing the SERR bit from the just read PCI_COMMAND bits as it writes them back out. Upon return from calling e1000_test_msi_interrupt(), it re-enables SERR by writing out the version of PCI_COMMAND it had previously read. The problem with this is that e1000_test_msi_interrupt() calls pci_disable_msi(), which eventually ends up in pci_intx(). And because pci_intx() was called with enable set to 1, the INTX_DISABLE bit gets cleared from PCI_COMMAND, which is what we want. But when we get back to e1000_test_msi(), the INTX_DISABLE bit gets inadvertently re-set because of the attempt by e1000_test_msi() to re-enable SERR. The solution is to have e1000_test_msi() re-read the PCI_COMMAND bits as part of its attempt to re-enable SERR. During debugging/testing of this issue I found that not all the systems I ran on had the SERR bit set to begin with. And on some of the systems the same could be said for the INTX_DISABLE bit. Needless to say these latter systems didn't have a problem falling back to legacy INTx interrupts with the code as is. Signed-off-by:
Dean Nelson <dnelson@redhat.com> Tested-by:
Emil Tantilov <emil.s.tantilov@intel.com> Signed-off-by:
-
Borislav Petkov authored
commit bc571178 upstream. Exit early when setting scrub rate on unknown/unsupported families. Signed-off-by:
Borislav Petkov <borislav.petkov@amd.com> Acked-by:
Doug Thompson <dougthompson@xmission.com> Signed-off-by:
-
Borislav Petkov authored
commit 9975a5f2 upstream. The correct check is to verify whether in high range we're below 4GB and not to extract the DctSelBaseAddr again. See "2.8.5 Routing DRAM Requests" in the F10h BKDG. Signed-off-by:
-
Kyle McMartin authored
commit d9b68e5e upstream. The firmware handles '\t' internally, so stop trying to emulate it (which, incidentally, had a bug in it.) Fixes a really weird hang at bootup in rcu_bootup_announce, which, as far as I can tell, is the first printk in the core kernel to use a tab as the first character. Signed-off-by:
Kyle McMartin <kyle@parisc-linux.org> Signed-off-by:
-
Baruch Siach authored
commit 14cb0deb upstream. The GPIO registers need protection from concurrent access for operations that are not atomic. Cc: Juergen Beisert <j.beisert@pengutronix.de> Cc: Daniel Mack <daniel@caiaq.de> Reported-by: rpkamiak@rockwellcollins.com Signed-off-by:
Baruch Siach <baruch@tkos.co.il> Signed-off-by:
Sascha Hauer <s.hauer@pengutronix.de> Signed-off-by:
-
Helge Deller authored
commit 4b4fd27c upstream. avoid potential stack overflow by correctly checking count parameter Reported-by:
Ilja <ilja@netric.org> Signed-off-by:
Helge Deller <deller@gmx.de> Acked-by:
Kyle McMartin <kyle@mcmartin.ca> Cc: James E.J. Bottomley <jejb@parisc-linux.org> Signed-off-by:
-
Trond Myklebust authored
commit b608b283 upstream See https://bugzilla.kernel.org/show_bug.cgi?id=16056 If other processes are blocked waiting for kswapd to free up some memory so that they can make progress, then we cannot allow kswapd to block on those processes. Signed-off-by:
Trond Myklebust <Trond.Myklebust@netapp.com> Signed-off-by:
-
Ian Abbott authored
(Note: upstream comedi configuration has been overhauled, so this patch does not apply there.) Several comedi drivers call subdev_8255_init() (declared in "drivers/staging/comedi/drivers/8255.h") to set up one or more DIO subdevices. This should be provided by the 8255.ko module, but unless the CONFIG_COMEDI_8255 or CONFIG_COMEDI_8255_MODULE macro is defined, the 8255.h header uses a dummy inline version of the function instead. This means the comedi devices end up with an "unused" subdevice with 0 channels instead of a "DIO" subdevice with 24 channels! This patch provides a non-interactive COMEDI_8255 option and selects it whenever the COMEDI_PCI_DRIVERS or COMEDI_PCMCIA_DRIVERS options are selected. Signed-off-by:
Ian Abbott <abbotti@mev.co.uk> Signed-off-by:
-
J. Bruce Fields authored
commit d327cf74 upstream. Subject: nfs: fix acl decoding Commit 28f56694 "NFS: use dynamically computed compound_hdr.replen for xdr_inline_pages offset" accidentally changed the amount of space to allow for the acl reply, resulting in an IO error on attempts to get an acl. Reported-by:
Paul Rudin <paul@rudin.co.uk> Cc: Benny Halevy <bhalevy@panasas.com> Signed-off-by:
J. Bruce Fields <bfields@citi.umich.edu> Signed-off-by:
-
Hugh Dickins authored
commit de51257a upstream. Debian's ia64 autobuilders have been seeing kernel freeze or reboot when running the gdb testsuite (Debian bug 588574): dannf bisected to 2.6.32 62eede62 "mm: ZERO_PAGE without PTE_SPECIAL"; and reproduced it with gdb's gcore on a simple target. I'd missed updating the gate_vma handling in __get_user_pages(): that happens to use vm_normal_page() (nowadays failing on the zero page), yet reported success even when it failed to get a page - boom when access_process_vm() tried to copy that to its intermediate buffer. Fix this, resisting cleanups: in particular, leave it for now reporting success when not asked to get any pages - very probably safe to change, but let's not risk it without testing exposure. Why did ia64 crash with 16kB pages, but succeed with 64kB pages? Because setup_gate() pads each 64kB of its gate area with zero pages. Reported-by:
Andreas Barth <aba@not.so.argh.org> Bisected-by:
dann frazier <dannf@debian.org> Signed-off-by:
Hugh Dickins <hughd@google.com> Tested-by:
dann frazier <dannf@dannf.org> Signed-off-by:
-
Peter Zijlstra authored
commit cd8ad40d upstream. When setting the weight for a per-cpu task-group, we have to put in a phantom weight when there is no work on that cpu, otherwise we'll not service that cpu when new work gets placed there until we again update the per-cpu weights. We used to add these phantom weights to the total, so that the idle per-cpu shares don't get inflated, this however causes the non-idle parts to get deflated, causing unexpected weight distibutions. Reverse this, so that the non-idle shares are correct but the idle shares are inflated. Reported-by:
Yasunori Goto <y-goto@jp.fujitsu.com> Tested-by:
Peter Zijlstra <a.p.zijlstra@chello.nl> LKML-Reference: <1257934048.23203.76.camel@twins> Signed-off-by:
Ingo Molnar <mingo@elte.hu> Signed-off-by:
-
- 02 Aug, 2010 2 commits
-
-
Greg Kroah-Hartman authored
-
Daniel Ritz authored
commit 68f194e0 upstream. For some unknown reason, on a MacBookPro5,3 the iSight sometimes report a different video format GUID. This patch add the other (wrong) GUID to the format table, making the iSight work always w/o other problems. What it should report: 32595559-0000-0010-8000-00aa00389b71 What it often reports: 32595559-0000-0010-8000-000000389b71 Signed-off-by:
Daniel Ritz <daniel.ritz@gmx.ch> Signed-off-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by:
Mauro Carvalho Chehab <mchehab@redhat.com> Cc: Leann Ogasawara <leann.ogasawara@canonical.com> Signed-off-by:
-
