* 'devicetree/merge' of git://git.secretlab.ca/git/linux-2.6:
drivercore: revert addition of of_match to struct device
of: fix race when matching drivers
Commit b826291c, "drivercore/dt: add a match table pointer to struct
device" added an of_match pointer to struct device to cache the
of_match_table entry discovered at driver match time. This was unsafe
because matching is not an atomic operation with probing a driver. If
two or more drivers are attempted to be matched to a driver at the
same time, then the cached matching entry pointer could get
overwritten.
This patch reverts the of_match cache pointer and reworks all users to
call of_match_device() directly instead.
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
* 'for-linus' of git://git.kernel.dk/linux-2.6-block:
block: don't delay blk_run_queue_async
scsi: remove performance regression due to async queue run
blk-throttle: Use task_subsys_state() to determine a task's blkio_cgroup
block: rescan partitions on invalidated devices on -ENOMEDIA too
cdrom: always check_disk_change() on open
block: unexport DISK_EVENT_MEDIA_CHANGE for legacy/fringe drivers
Adding the necessary MODULE_DEVICE_TABLE() information allows the driver
to be automatically loaded by udev.
Signed-off-by: Axel Lin <axel.lin@gmail.com>
Cc: Shreshtha Kumar SAHU <shreshthakumar.sahu@stericsson.com>
Cc: Richard Purdie <rpurdie@rpsys.net>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Fix switch initialization to ensure that all switches have default routing
disabled. This guarantees that no unexpected RapidIO packets arrive to
the default port set by reset and there is no default routing destination
until it is properly configured by software.
This update also unifies handling of unmapped destinations by tsi57x, IDT
Gen1 and IDT Gen2 switches.
Signed-off-by: Alexandre Bounine <alexandre.bounine@idt.com>
Cc: Kumar Gala <galak@kernel.crashing.org>
Cc: Matt Porter <mporter@kernel.crashing.org>
Cc: Li Yang <leoli@freescale.com>
Cc: Thomas Moll <thomas.moll@sysgo.com>
Cc: <stable@kernel.org> [2.6.37+]
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Commit c21e6beb removed our queue request_fn re-enter
protection, and defaulted to always running the queues from
kblockd to be safe. This was a known potential slow down,
but should be safe.
Unfortunately this is causing big performance regressions for
some, so we need to improve this logic. Looking into the details
of the re-enter, the real issue is on requeue of requests.
Requeue of requests upon seeing a BUSY condition from the device
ends up re-running the queue, causing traces like this:
scsi_request_fn()
scsi_dispatch_cmd()
scsi_queue_insert()
__scsi_queue_insert()
scsi_run_queue()
scsi_request_fn()
...
potentially causing the issue we want to avoid. So special
case the requeue re-run of the queue, but improve it to offload
the entire run of local queue and starved queue from a single
workqueue callback. This is a lot better than potentially
kicking off a workqueue run for each device seen.
This also fixes the issue of the local device going into recursion,
since the above mentioned commit never moved that queue run out
of line.
Signed-off-by: Jens Axboe <jaxboe@fusionio.com>
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/cjb/mmc:
Revert "mmc: fix a race between card-detect rescan and clock-gate work instances"
During pci remove/rescan testing found:
pci 0000:c0:03.0: PCI bridge to [bus c4-c9]
pci 0000:c0:03.0: bridge window [io 0x1000-0x0fff]
pci 0000:c0:03.0: bridge window [mem 0xf0000000-0xf00fffff]
pci 0000:c0:03.0: bridge window [mem 0xfc180000000-0xfc197ffffff 64bit pref]
pci 0000:c0:03.0: device not available (can't reserve [io 0x1000-0x0fff])
pci 0000:c0:03.0: Error enabling bridge (-22), continuing
pci 0000:c0:03.0: enabling bus mastering
pci 0000:c0:03.0: setting latency timer to 64
pcieport 0000:c0:03.0: device not available (can't reserve [io 0x1000-0x0fff])
pcieport: probe of 0000:c0:03.0 failed with error -22
This bug was caused by commit c8adf9a3e8 ("PCI: pre-allocate
additional resources to devices only after successful allocation of
essential resources.")
After that commit, pci_hotplug_io_size is changed to additional_io_size
from minium size. So it will not go through resource_size(res) != 0
path, and will not be reset.
The root cause is: pci_bridge_check_ranges will set RESOURCE_IO flag for
pci bridge, and later if children do not need IO resource. those bridge
resources will not need to be allocated. but flags is still there.
that will confuse the the pci_enable_bridges later.
related code:
static void assign_requested_resources_sorted(struct resource_list *head,
struct resource_list_x *fail_head)
{
struct resource *res;
struct resource_list *list;
int idx;
for (list = head->next; list; list = list->next) {
res = list->res;
idx = res - &list->dev->resource[0];
if (resource_size(res) && pci_assign_resource(list->dev, idx)) {
...
reset_resource(res);
}
}
}
At last, We have to clear the flags in pbus_size_mem/io when requested
size == 0 and !add_head. becasue this case it will not go through
adjust_resources_sorted().
Just make size1 = size0 when !add_head. it will make flags get cleared.
At the same time when requested size == 0, add_size != 0, will still
have in head and add_list. because we do not clear the flags for it.
After this, we will get right result:
pci 0000:c0:03.0: PCI bridge to [bus c4-c9]
pci 0000:c0:03.0: bridge window [io disabled]
pci 0000:c0:03.0: bridge window [mem 0xf0000000-0xf00fffff]
pci 0000:c0:03.0: bridge window [mem 0xfc180000000-0xfc197ffffff 64bit pref]
pci 0000:c0:03.0: enabling bus mastering
pci 0000:c0:03.0: setting latency timer to 64
pcieport 0000:c0:03.0: setting latency timer to 64
pcieport 0000:c0:03.0: irq 160 for MSI/MSI-X
pcieport 0000:c0:03.0: Signaling PME through PCIe PME interrupt
pci 0000:c4:00.0: Signaling PME through PCIe PME interrupt
pcie_pme 0000:c0:03.0:pcie01: service driver pcie_pme loaded
aer 0000:c0:03.0:pcie02: service driver aer loaded
pciehp 0000:c0:03.0:pcie04: Hotplug Controller:
v3: more simple fix. also fix one typo in pbus_size_mem
Signed-off-by: Yinghai Lu <yinghai@kernel.org>
Reviewed-by: Ram Pai <linuxram@us.ibm.com>
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
During initialization of vmxnet3, the state of LRO
gets out of sync with netdev->features.
This leads to very poor TCP performance in a IP forwarding
setup and is hitting many VMware users.
Simplified call sequence:
1. vmxnet3_declare_features() initializes "adapter->lro" to true.
2. The kernel automatically disables LRO if IP forwarding is enabled,
so vmxnet3_set_flags() gets called. This also updates netdev->features.
3. Now vmxnet3_setup_driver_shared() is called. "adapter->lro" is still
set to true and LRO gets enabled again, even though
netdev->features shows it's disabled.
Fix it by updating "adapter->lro", too.
The private vmxnet3 adapter flags are scheduled for removal
in net-next, see commit a0d2730c95
"net: vmxnet3: convert to hw_features".
Patch applies to 2.6.37 / 2.6.38 and 2.6.39-rc6.
Please CC: comments.
Signed-off-by: Thomas Jarosch <thomas.jarosch@intra2net.com>
Acked-by: Stephen Hemminger <shemminger@vyatta.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Commit 747df2258b ('sfc: Always map MCDI
shared memory as uncacheable') introduced a separate mapping for the
MCDI shared memory (MC_TREG_SMEM). This means we can no longer easily
include it in the register dump. Since it is not particularly useful
in debugging, substitute a recognisable dummy value.
Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
* 'drm-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6:
drm: Take lock around probes for drm_fb_helper_hotplug_event
drm/i915: Revert i915.semaphore=1 default from 47ae63e0
vga_switcheroo: don't toggle-switch devices
drm/radeon/kms: add some evergreen/ni safe regs
drm/radeon/kms: fix extended lvds info parsing
drm/radeon/kms: fix tiling reg on fusion
We need to hold the dev->mode_config.mutex whilst detecting the output
status. But we also need to drop it for the call into
drm_fb_helper_single_fb_probe(), which indirectly acquires the lock when
attaching the fbcon.
Failure to do so exposes a race with normal output probing. Detected by
adding some warnings that the mutex is held to the backend detect routines:
[ 17.772456] WARNING: at drivers/gpu/drm/i915/intel_crt.c:471 intel_crt_detect+0x3e/0x373 [i915]()
[ 17.772458] Hardware name: Latitude E6400
[ 17.772460] Modules linked in: ....
[ 17.772582] Pid: 11, comm: kworker/0:1 Tainted: G W 2.6.38.4-custom.2 #8
[ 17.772584] Call Trace:
[ 17.772591] [<ffffffff81046af5>] ? warn_slowpath_common+0x78/0x8c
[ 17.772603] [<ffffffffa03f3e5c>] ? intel_crt_detect+0x3e/0x373 [i915]
[ 17.772612] [<ffffffffa0355d49>] ? drm_helper_probe_single_connector_modes+0xbf/0x2af [drm_kms_helper]
[ 17.772619] [<ffffffffa03534d5>] ? drm_fb_helper_probe_connector_modes+0x39/0x4d [drm_kms_helper]
[ 17.772625] [<ffffffffa0354760>] ? drm_fb_helper_hotplug_event+0xa5/0xc3 [drm_kms_helper]
[ 17.772633] [<ffffffffa035577f>] ? output_poll_execute+0x146/0x17c [drm_kms_helper]
[ 17.772638] [<ffffffff81193c01>] ? cfq_init_queue+0x247/0x345
[ 17.772644] [<ffffffffa0355639>] ? output_poll_execute+0x0/0x17c [drm_kms_helper]
[ 17.772648] [<ffffffff8105b540>] ? process_one_work+0x193/0x28e
[ 17.772652] [<ffffffff8105c6bc>] ? worker_thread+0xef/0x172
[ 17.772655] [<ffffffff8105c5cd>] ? worker_thread+0x0/0x172
[ 17.772658] [<ffffffff8105c5cd>] ? worker_thread+0x0/0x172
[ 17.772663] [<ffffffff8105f767>] ? kthread+0x7a/0x82
[ 17.772668] [<ffffffff8100a724>] ? kernel_thread_helper+0x4/0x10
[ 17.772671] [<ffffffff8105f6ed>] ? kthread+0x0/0x82
[ 17.772674] [<ffffffff8100a720>] ? kernel_thread_helper+0x0/0x10
Reported-by: Frederik Himpe <fhimpe@telenet.be>
References: https://bugs.freedesktop.org/show_bug.cgi?id=36394
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Dave Airlie <airlied@redhat.com>
My Q67 / i7-2600 box has rev09 Sandy Bridge graphics. It hangs
instantly when GNOME loads and it hangs so hard the reset button
doesn't work. Setting i915.semaphore=0 fixes it.
Semaphores were disabled in a1656b9090
in 2.6.38 and were re-enabled by
commit 47ae63e0c2
Merge: c59a333467cffb
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date: Mon Mar 7 12:32:44 2011 +0000
Merge branch 'drm-intel-fixes' into drm-intel-next
Apply the trivial conflicting regression fixes, but keep GPU semaphores
enabled.
Conflicts:
drivers/gpu/drm/i915/i915_drv.h
drivers/gpu/drm/i915/i915_gem_execbuffer.c
(It's worth noting that the offending change is i915_drv.c,
which is not a conflict.)
Signed-off-by: Andy Lutomirski <luto@mit.edu>
Acked-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
If the requested device is already active, ignore the request.
This restores the original behaviour of the interface. The change was
probably an unintended side effect of
commit 66b37c6777 vga_switcheroo: split switching into two stages
which did not take into account to duplicate the !active check in the split-off
stage2.
Fix this by factoring that check out of stage1 into the debugfs_write routine.
References: https://bugzilla.kernel.org/show_bug.cgi?id=34252
Reported-by: Igor Murzov <e-mail@date.by>
Tested-by: Igor Murzov <e-mail@date.by>
Signed-off-by: Florian Mickler <florian@mickler.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
This reverts commit 270dac35c2.
The commits causes command timeouts on AC plug/unplug. It isn't yet
clear why. As the commit was for a single rather obscure controller,
revert the change for now.
The problem was reported and bisected by Gu Rui in bug#34692.
https://bugzilla.kernel.org/show_bug.cgi?id=34692
Also, reported by Rafael and Michael in the following thread.
http://thread.gmane.org/gmane.linux.kernel/1138771
Signed-off-by: Tejun Heo <tj@kernel.org>
Reported-by: Gu Rui <chaos.proton@gmail.com>
Reported-by: Rafael J. Wysocki <rjw@sisk.pl>
Reported-by: Michael Leun <lkml20100708@newton.leun.net>
Cc: Jian Peng <jipeng2005@gmail.com>
Cc: Jeff Garzik <jgarzik@pobox.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
This moves the
if (num_registered_fb == FB_MAX)
return -ENXIO;
check _AFTER_ the call to do_remove_conflicting_framebuffers() as this
would (now in a safe way) allow a native driver to replace the
conflicting one even if all slots in registered_fb[] are taken.
This also prevents unregistering a framebuffer that is no longer
registered (vga16f will unregister at module unload time even if the
frame buffer had been unregistered earlier due to being found
conflicting).
Signed-off-by: Bruno Prémont <bonbons@linux-vserver.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
When a register_framebuffer() call results in us removing old
conflicting framebuffers, the new registration_lock doesn't protect that
situation. And we can't just add the same locking to the function,
because these functions call each other: register_framebuffer() calls
remove_conflicting_framebuffers, which in turn calls
unregister_framebuffer for any conflicting entry.
In order to fix it, this just creates wrapper functions around all three
functions and makes the versions that actually do the work be called
"do_xxx()", leaving just the wrapper that gets the lock and calls the
worker function.
So the rule becomes simply that "do_xxxx()" has to be called with the
lock held, and now do_register_framebuffer() can just call
do_remove_conflicting_framebuffers(), and that in turn can call
_do_unregister_framebuffer(), and there is no deadlock, and we can hold
the registration lock over the whole sequence, fixing the races.
It also makes error cases simpler, and fixes one situation where we
would return from unregister_framebuffer() without releasing the lock,
pointed out by Bruno Prémont.
Tested-by: Bruno Prémont <bonbons@linux-vserver.org>
Tested-by: Anca Emanuel <anca.emanuel@gmail.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-2.6:
bridge: fix forwarding of IPv6
bonding,llc: Fix structure sizeof incompatibility for some PDUs
ipv6: restore correct ECN handling on TCP xmit
ne-h8300: Fix regression caused during net_device_ops conversion
hydra: Fix regression caused during net_device_ops conversion
zorro8390: Fix regression caused during net_device_ops conversion
sfc: Always map MCDI shared memory as uncacheable
ehea: Fix memory hotplug oops
libertas: fix cmdpendingq locking
iwlegacy: fix IBSS mode crashes
ath9k: Fix a warning due to a queued work during S3 state
mac80211: don't start the dynamic ps timer if not associated
The rbd driver currently splits bios when they span an object boundary.
However, the blk_end_request expects the completions to roll up the results
in block device order, and the split rbd/ceph ops can complete in any
order. This patch adds a struct rbd_req_coll to track completion of split
requests and ensures that the results are passed back up to the block layer
in order.
This fixes errors where the file system gets completion of a read operation
that spans an object boundary before the data has actually arrived. The
bug is easily reproduced with iozone with a working set larger than
available RAM.
Reported-by: Fyodor Ustinov <ufm@ufm.su>
Signed-off-by: Yehuda Sadeh <yehuda@hq.newdream.net>
Signed-off-by: Sage Weil <sage@newdream.net>
My Q67 / i7-2600 box has rev09 Sandy Bridge graphics. It hangs
instantly when GNOME loads and it hangs so hard the reset button
doesn't work. Setting i915.semaphore=0 fixes it.
Semaphores were disabled in a1656b9090 ("drm/i915: Disable GPU
semaphores by default") in 2.6.38 but were then re-enabled (by mistake?)
by the merge 47ae63e0c2 ("Merge branch 'drm-intel-fixes' into
drm-intel-next").
(It's worth noting that the offending change is i915_drv.c, which was
not marked as a conflict - although a 'git show --cc' on the merge does
show that neither parent had it set to 1)
Signed-off-by: Andy Lutomirski <luto@mit.edu>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
With some combinations of arch/compiler (e.g. arm-linux-gcc) the sizeof
operator on structure returns value greater than expected. In cases when the
structure is used for mapping PDU fields it may lead to unexpected results
(such as holes and alignment problems in skb data). __packed prevents this
undesired behavior.
Signed-off-by: Vitalii Demianets <vitas@nppfactor.kiev.ua>
Signed-off-by: David S. Miller <davem@davemloft.net>
The board support has never been merged for it as noticed
by Russell King <linux@arm.linux.org.uk>. So let's remove the
related dead code.
Cc: linux-fbdev@vger.kernel.org
Cc: alsa-devel@alsa-project.org
Cc: Paul Mundt <lethal@linux-sh.org>
Acked-by: Jarkko Nikula <jhnikula@gmail.com>
Acked-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Acked-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Acked-by: Liam Girdwood <lrg@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
On rev <= 1.1 tables, the offset is absolute,
on newer tables, it's relative.
Fixes:
https://bugzilla.redhat.com/show_bug.cgi?id=700326
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Reviewed-by: Jerome Glisse <jglisse@redhat.com>
Cc: stable@kernel.org
Signed-off-by: Dave Airlie <airlied@redhat.com>
The location of MC_ARB_RAMCFG changed on fusion.
I've diffed all the other regs in evergreend.h and this
is the only other reg that changed.
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
alg_data is already a pointer which must be passed directly.
Reported-by: Dieter Ripp <ripp@systecnet.com>
Signed-off-by: Wolfram Sang <w.sang@pengutronix.de>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Ben Dooks <ben-i2c@fluff.org>
Signed-off-by: Ben Dooks <ben-linux@fluff.org>
Changeset dcd39c9029 ("ne-h8300: convert to
net_device_ops") broke ne-h8300 by adding 8390.o to the link. That
meant that lib8390.c was included twice, once in ne-h8300.c and once in
8390.c, subject to different macros. This patch reverts that by
avoiding the wrappers in 8390.c.
Fix based on commits 217cbfa856 ("mac8390:
fix regression caused during net_device_ops conversion") and
4e0168fa48 ("mac8390: fix build with
NET_POLL_CONTROLLER").
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: stable@kernel.org
Signed-off-by: David S. Miller <davem@davemloft.net>
Changeset 5618f0d119 ("hydra: convert to
net_device_ops") broke hydra by adding 8390.o to the link. That
meant that lib8390.c was included twice, once in hydra.c and once in
8390.c, subject to different macros. This patch reverts that by
avoiding the wrappers in 8390.c.
Fix based on commits 217cbfa856 ("mac8390:
fix regression caused during net_device_ops conversion") and
4e0168fa48 ("mac8390: fix build with
NET_POLL_CONTROLLER").
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: stable@kernel.org
Signed-off-by: David S. Miller <davem@davemloft.net>
Changeset b6114794a1 ("zorro8390: convert to
net_device_ops") broke zorro8390 by adding 8390.o to the link. That
meant that lib8390.c was included twice, once in zorro8390.c and once in
8390.c, subject to different macros. This patch reverts that by
avoiding the wrappers in 8390.c.
Fix based on commits 217cbfa856 ("mac8390:
fix regression caused during net_device_ops conversion") and
4e0168fa48 ("mac8390: fix build with
NET_POLL_CONTROLLER").
Reported-by: Christian T. Steigies <cts@debian.org>
Suggested-by: Finn Thain <fthain@telegraphics.com.au>
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Tested-by: Christian T. Steigies <cts@debian.org>
Cc: stable@kernel.org
Signed-off-by: David S. Miller <davem@davemloft.net>
This reverts commit 49183b2818.
Quoth Franz Melchior:
"This patch introduces a bug on my infamous "Acer Travelmate
5735Z-452G32Mnss": when KMS takes over, the frame buffer contents get
completely garbled up on screen, with colored stripes and unreadable
text (photo on request). Only when X11 is started, the screen gets
restored again. Closing and re-opening the lid partly cures the
mess, too: it makes the font readable, though horizontally stretched."
Acked-by: Keith Packard <keithp@keithp.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* 'fixes' of master.kernel.org:/home/rmk/linux-2.6-arm:
ARM: 6870/1: The mandatory barrier rmb() must be a dsb() in for device accesses
ARM: 6892/1: handle ptrace requests to change PC during interrupted system calls
ARM: 6890/1: memmap: only free allocated memmap entries when using SPARSEMEM
ARM: zImage: the page table memory must be considered before relocation
ARM: zImage: make sure not to relocate on top of the relocation code
ARM: zImage: Fix bad SP address after relocating kernel
ARM: zImage: make sure the stack is 64-bit aligned
ARM: RiscPC: acornfb: fix section mismatches
ARM: RiscPC: etherh: fix section mismatches
read/write/ioctl on a fbcon file descriptor has traditionally used the
fbcon not when it was opened, but as it was at the time of the call.
That makes no sense, but the lack of sense is much more obvious now that
we properly ref-count the usage - it means that the ref-counting doesn't
actually protect operations we do on the frame buffer.
This changes it to look at the fb_info that we got at open time, but in
order to avoid using a frame buffer long after it has been unregistered,
we do verify that it is still current, and return -ENODEV if not.
Acked-by: Tim Gardner <tim.gardner@canonical.com>
Tested-by: Daniel J Blueman <daniel.blueman@gmail.com>
Tested-by: Anca Emanuel <anca.emanuel@gmail.com>
Cc: Bruno Prémont <bonbons@linux-vserver.org>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: Paul Mundt <lethal@linux-sh.org>
Cc: Dave Airlie <airlied@redhat.com>
Cc: Andy Whitcroft <andy.whitcroft@canonical.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
This just adds the refcount and the new registration lock logic. It
does not (for example) actually change the read/write/ioctl routines to
actually use the frame buffer that was opened: those function still end
up alway susing whatever the current frame buffer is at the time of the
call.
Without this, if something holds the frame buffer open over a
framebuffer switch, the close() operation after the switch will access a
fb_info that has been free'd by the unregistering of the old frame
buffer.
(The read/write/ioctl operations will normally not cause problems,
because they will - illogically - pick up the new fbcon instead. But a
switch that happens just as one of those is going on might see problems
too, the window is just much smaller: one individual op rather than the
whole open-close sequence.)
This use-after-free is apparently fairly easily triggered by the Ubuntu
11.04 boot sequence.
Acked-by: Tim Gardner <tim.gardner@canonical.com>
Tested-by: Daniel J Blueman <daniel.blueman@gmail.com>
Tested-by: Anca Emanuel <anca.emanuel@gmail.com>
Cc: Bruno Prémont <bonbons@linux-vserver.org>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: Paul Mundt <lethal@linux-sh.org>
Cc: Dave Airlie <airlied@redhat.com>
Cc: Andy Whitcroft <andy.whitcroft@canonical.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
We enabled write-combining for memory-mapped registers in commit
65f0b417de, but inhibited it for the
MCDI shared memory where this is not supported. However,
write-combining mappings also allow read-reordering, which may also
be a problem.
I found that when an SFC9000-family controller is connected to an
Intel 3000 chipset, and write-combining is enabled, the controller
stops responding to PCIe read requests during driver initialisation
while the driver is polling for completion of an MCDI command. This
results in an NMI and system hang. Adding read memory barriers
between all reads to the shared memory area appears to reduce but not
eliminate the probability of this.
We have not yet established whether this is a bug in our BIU or in the
PCIe bridge. For now, work around by mapping the shared memory area
separately.
Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
