29 Apr, 2011
1 commit
-
cdrom_open() called check_disk_change() after the rest of open path
succeeded which leads to the following bizarre behavior.* After media change, if the device opened without O_NONBLOCK,
open_for_data() naturally fails with -ENOMEDIA and
check_disk_change() is never called. The media is known to be gone
and the open failure makes it obvious to the userland but device
invalidation never happens.* But if the device is opened with O_NONBLOCK, all the checks are
bypassed and cdrom_open() doesn't notice that the media is not there
and check_disk_change() is called and invalidation happens.There's nothing to be gained by avoiding calling check_disk_change()
on open failure. Common cases end up calling check_disk_change()
anyway. All we get is inconsistent behavior.Fix it by moving check_disk_change() invocation to the top of
cdrom_open() so that it always gets called regardless of how the rest
of open proceeds.Stable: 2.6.38
Signed-off-by: Tejun Heo
Reported-by: Amit Shah
Tested-by: Amit Shah
Cc: stable@kernel.org
Signed-off-by: Jens Axboe
22 Apr, 2011
8 commits
-
In-kernel disk event polling doesn't matter for legacy/fringe drivers
and may lead to infinite event loop if ->check_events() implementation
generates events on level condition instead of edge.Now that block layer supports suppressing exporting unlisted events,
simply leaving disk->events cleared allows these drivers to keep the
internal revalidation behavior intact while avoiding weird
interactions with userland event handler.Signed-off-by: Tejun Heo
Cc: Kay Sievers
Signed-off-by: Jens Axboe -
* 'for-linus' of git://git.kernel.dk/linux-2.6-block:
ide: unexport DISK_EVENT_MEDIA_CHANGE for ide-gd and ide-cd
block: don't propagate unlisted DISK_EVENTs to userland
elevator: check for ELEVATOR_INSERT_SORT_MERGE in !elvpriv case too -
check_events() implementations in both ide-gd and ide-cd are
inadequate for in-kernel event polling. Both generate media change
events continuously when certain conditions are met causing infinite
event loop between the driver and userland event handler.As disk event now supports suppression of unlisted events, simply
de-listing DISK_EVENT_MEDIA_CHANGE from disk->events resolves the
problem. Internal handling around media revalidation will behave the
same while userland will fall back to userland event polling after
detecting the device doesn't support disk events.Signed-off-by: Tejun Heo
Reported-by: Jens Axboe
Acked-by: "David S. Miller"
Signed-off-by: Jens Axboe -
Change from unsigned long long to sector_t.
This matches its source field.ERROR: "__udivdi3" [drivers/md/raid456.ko] undefined!
Signed-off-by: Randy Dunlap
Signed-off-by: Linus Torvalds -
* git://git.kernel.org/pub/scm/linux/kernel/git/rusty/linux-2.6-for-linus:
virtio: console: Enable call to hvc_remove() on console port remove
virtio_pci: Prevent double-free of pci regions after device hot-unplug
virtio: Decrement avail idx on buffer detach -
* 'drm-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6:
agp: fix arbitrary kernel memory writes
agp: fix OOM and buffer overflow
drm/radeon/kms: fix IH writeback on r6xx+ on big endian machines -
* 'drm-intel-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/keithp/linux-2.6:
drm/i915: Initialise g4x watermarks for disabled pipes
drm/i915: Sanitize the output registers after resume
drm/i915/tv: Fix modeset flickering introduced in 7f58aabc3
drm/i915/tv: Only poll for TV connections
drm/i915/tv: Remember the detected TV type -
* git://git.infradead.org/iommu-2.6:
intel_iommu: disable all VT-d PMRs when TXT launched
intel-iommu: Fix get_domain_for_dev() error path
intel-iommu: Unlink domain from iommu
intel-iommu: Fix use after release during device attach
21 Apr, 2011
9 commits
-
This call was disabled as hot-unplugging one virtconsole port led to
another virtconsole port freezing.Upon testing it again, this now works, so enable it.
In addition, a bug was found in qemu wherein removing a port of one type
caused the guest output from another port to stop working. I doubt it
was just this bug that caused it (since disabling the hvc_remove() call
did allow other ports to continue working), but since it's all solved
now, we're fine with hot-unplugging of virtconsole ports.Signed-off-by: Amit Shah
Signed-off-by: Rusty Russell -
In the case where a virtio-console port is in use (opened by a program)
and a virtio-console device is removed, the port is kept around but all
the virtio-related state is assumed to be gone.When the port is finally released (close() called), we call
device_destroy() on the port's device. This results in the parent
device's structures to be freed as well. This includes the PCI regions
for the virtio-console PCI device.Once this is done, however, virtio_pci_release_dev() kicks in, as the
last ref to the virtio device is now gone, and attempts to dopci_iounmap(pci_dev, vp_dev->ioaddr);
pci_release_regions(pci_dev);
pci_disable_device(pci_dev);which results in a double-free warning.
Move the code that releases regions, etc., to the virtio_pci_remove()
function, and all that's now left in release_dev is the final freeing of
the vp_dev.Signed-off-by: Amit Shah
Signed-off-by: Rusty Russell -
When detaching a buffer from a vq, the avail.idx value should be
decremented as well.This was noticed by hot-unplugging a virtio console port and then
plugging in a new one on the same number (re-using the vqs which were
just 'disowned'). qemu reported'Guest moved used index from 0 to 256'
when any IO was attempted on the new port.
CC: stable@kernel.org
Reported-by: juzhang
Signed-off-by: Amit Shah
Signed-off-by: Rusty Russell -
Intel VT-d Protected Memory Regions (PMRs) are supposed to be disabled,
on each VT-d engine, after DMA remapping is enabled on the engines.
This is because the behavior of having both enabled is not deterministic
and because, if TXT has been used to launch the kernel, the PMRs may be
programmed to cover memory regions that will be used for DMA.Under some circumstances (certain quirks detected, lack of multiple
devices, etc.), the current code does not set up DMA remapping on some
VT-d engines. In such cases it also skips disabling the PMRs. This
causes failures when the kernel is launched with TXT (most often this
occurs on the graphics engine and results in colored vertical bars on
the display).This patch detects when the kernel has been launched with TXT and then
disables the PMRs on all VT-d engines. In some cases where the reason
that remapping is not being enabled is due to possible ACPI DMAR table
errors, the VT-d engine addresses may not be correct and thus not able
to be safely programmed even to disable PMRs. Because part of the TXT
launch process is the verification of these addresses, it will always be
safe to disable PMRs if the TXT launch has succeeded and hence only
doing this in such cases.Signed-off-by: Joseph Cihula
Signed-off-by: David Woodhouse -
pg_start is copied from userspace on AGPIOC_BIND and AGPIOC_UNBIND ioctl
cmds of agp_ioctl() and passed to agpioc_bind_wrap(). As said in the
comment, (pg_start + mem->page_count) may wrap in case of AGPIOC_BIND,
and it is not checked at all in case of AGPIOC_UNBIND. As a result, user
with sufficient privileges (usually "video" group) may generate either
local DoS or privilege escalation.Signed-off-by: Vasiliy Kulikov
Signed-off-by: Dave Airlie -
page_count is copied from userspace. agp_allocate_memory() tries to
check whether this number is too big, but doesn't take into account the
wrap case. Also agp_create_user_memory() doesn't check whether
alloc_size is calculated from num_agp_pages variable without overflow.
This may lead to allocation of too small buffer with following buffer
overflow.Another problem in agp code is not addressed in the patch - kernel memory
exhaustion (AGPIOC_RESERVE and AGPIOC_ALLOCATE ioctls). It is not checked
whether requested pid is a pid of the caller (no check in agpioc_reserve_wrap()).
Each allocation is limited to 16KB, though, there is no per-process limit.
This might lead to OOM situation, which is not even solved in case of the
caller death by OOM killer - the memory is allocated for another (faked) process.Signed-off-by: Vasiliy Kulikov
Signed-off-by: Dave Airlie -
* 'hwmon-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/groeck/staging:
hwmon: (max34440) Add driver documentation
hwmon: (max16064) Add driver documentation
hwmon: (max8688) Add driver documentation
hwmon: (pmbus) Documentation updates
hwmon: (smm665) Fix spelling error in driver documentation
hwmon: (pmbus) Removed unused variable from struct pmbus_data
hwmon: Add submitting-patches checklist to documentation -
* 'for-linus' of git://neil.brown.name/md:
md: Update documentation for sync_min and sync_max entries
md: Cleanup after raid45->raid0 takeover
md: Fix dev_sectors on takeover from raid0 to raid4/5
md/raid5: remove setting of ->queue_lock -
* 'for-linus' of git://git.kernel.dk/linux-2.6-block:
block: Remove the extra check in queue_requests_store
block, blk-sysfs: Fix an err return path in blk_register_queue()
block: remove stale kerneldoc member from __blk_run_queue()
block: get rid of QUEUE_FLAG_REENTER
cfq-iosched: read_lock() does not always imply rcu_read_lock()
block: kill blk_flush_plug_list() export
20 Apr, 2011
16 commits
-
Problem:
After raid4->raid0 takeover operation, another takeover operation
(e.g raid0->raid10) results "kernel oops".
Root cause:
Variables 'degraded' in mddev structure is not cleared
on raid45->raid0 takeover.This patch reset this variable.
Signed-off-by: Krzysztof Wojcik
Signed-off-by: NeilBrown -
A raid0 array doesn't set 'dev_sectors' as each device might
contribute a different number of sectors.
So when converting to a RAID4 or RAID5 we need to set dev_sectors
as they need the number.
We have already verified that in fact all devices do contribute
the same number of sectors, so use that number.Signed-off-by: NeilBrown
-
We previously needed to set ->queue_lock to match the raid5
device_lock so we could safely use queue_flag_* operations (e.g. for
plugging). which test the ->queue_lock is in fact locked.However that need has completely gone away and is unlikely to come
back to remove this now-pointless setting.Signed-off-by: NeilBrown
-
* 'drm-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6:
drm/radeon/kms: pll tweaks for r7xx
drm/nouveau: fix allocation of notifier object
drm/nouveau: fix notifier memory corruption bug
drm/nouveau: fix pinning of notifier block
drm/nouveau: populate ttm_alloced with false, when it's not
drm/nouveau: fix nv30 pcie boards
drm/nouveau: split ramin_lock into two locks, one hardirq safe
drm/radeon/kms: adjust evergreen display watermark setup
drm/radeon/kms: add connectors even if i2c fails
drm/radeon/kms: fix bad shift in atom iio table parser -
agd5f: fix commit message.
Signed-off-by: Cedric Cano
Reviewed-by: Michel Dänzer
Signed-off-by: Alex Deucher
Signed-off-by: Dave Airlie -
Prefer min m to max p only on pre-r7xx asics.
Fixes:
https://bugs.freedesktop.org/show_bug.cgi?id=36197Signed-off-by: Alex Deucher
Cc: stable@kernel.org
Signed-off-by: Dave Airlie -
Commit 73412c3854c877e5f37ad944ee8977addde4d35a ("drm/nouveau: allocate
kernel's notifier object at end of block") intended to align end of
notifier block to page boundary, but start of block was miscalculated
to be off by -16 bytes. Fix it.Signed-off-by: Marcin Slusarz
Cc: Ben Skeggs
Signed-off-by: Ben Skeggs -
nouveau_bo_wr32 expects offset to be in words, but we pass value in bytes,
so after commit 73412c3854c877e5f37ad944ee8977addde4d35a ("drm/nouveau: allocate
kernel's notifier object at end of block") we started to overwrite some memory
after notifier buffer object (previously m2mf_ntfy was always 0, so it didn't
matter it was a value in bytes).Reported-by: Dominik Brodowski
Reported-by: Nigel Cunningham
Signed-off-by: Marcin Slusarz
Cc: Ben Skeggs
Cc: Pekka Paalanen
Cc: stable@kernel.org [2.6.38]
Signed-off-by: Ben Skeggs -
Problem introduced with commit 6ba9a68317781537d6184d3fdb2d0f20c97da3a4
Reported-by: Bob Gleitsmann
Signed-off-by: Ben Skeggs -
Caught with kmemcheck on unrelated business.
Signed-off-by: Ben Skeggs
-
Wasn't aware they even existed, apparently they do! They're actually
AGP chips with a bridge as far as I can tell, which puts them in the
same boat as nv40/nv45.Signed-off-by: Ben Skeggs
-
Fixes a possible lock ordering reversal between context_switch_lock
and ramin_lock.Signed-off-by: Ben Skeggs
Reviewed-by: Francisco Jerez -
* git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-2.6: (51 commits)
netfilter: ipset: Fix the order of listing of sets
ip6_pol_route panic: Do not allow VLAN on loopback
bnx2x: Fix port identification problem
r8169: add Realtek as maintainer.
ip: ip_options_compile() resilient to NULL skb route
bna: fix memory leak during RX path cleanup
bna: fix for clean fw re-initialization
usbnet: Fix up 'FLAG_POINTTOPOINT' and 'FLAG_MULTI_PACKET' overlaps.
iwlegacy: fix tx_power initialization
Revert "tcp: disallow bind() to reuse addr/port"
qlcnic: limit skb frags for non tso packet
net: can: mscan: fix build breakage in mpc5xxx_can
netfilter: ipset: set match and SET target fixes
netfilter: ipset: bitmap:ip,mac type requires "src" for MAC
sctp: fix oops while removed transport still using as retran path
sctp: fix oops when updating retransmit path with DEBUG on
net: Disable NETIF_F_TSO_ECN when TSO is disabled
net: Disable all TSO features when SG is disabled
sfc: Use rmb() to ensure reads occur in order
ieee802154: Remove hacked CFLAGS in net/ieee802154/Makefile
... -
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jbarnes/pci-2.6:
PCI: pci-label: Fix build failure when CONFIG_NLS is set to 'm' by allmodconfig -
…l/git/tip/linux-2.6-tip
* 'timer-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip:
RTC: rtc-omap: Fix a leak of the IRQ during init failure
posix clocks: Replace mutex with reader/writer semaphore -
This reverts commit 35d9f510b67b10338161aba6229d4f55b4000f5b.
Quoth Jiri Slaby:
"It fixes mmap when IOMMU is used on x86 only, but breaks architectures
like ARM or PPC where virt_to_phys(dma_alloc_coherent) doesn't work.
We need there dma_mmap_coherent or similar (the trickery what
snd_pcm_default_mmap does but in some saner way). But this cannot be
done at this phase."Requested-by: Jiri Slaby
Cc: Russell King - ARM Linux
Cc: Janusz Krzysztofik
Acked-by: Mauro Carvalho Chehab
Signed-off-by: Linus Torvalds
19 Apr, 2011
5 commits
-
struct pmbus_data included an unused variable named status_bits.
Remove it.Signed-off-by: Guenter Roeck
Reviewed-by: Tom Grennan -
We are currently using this flag to check whether it's safe
to call into ->request_fn(). If it is set, we punt to kblockd.
But we get a lot of false positives and excessive punts to
kblockd, which hurts performance.The only real abuser of this infrastructure is SCSI. So export
the async queue run and convert SCSI over to use that. There's
room for improvement in that SCSI need not always use the async
call, but this fixes our performance issue and they can fix that
up in due time.Signed-off-by: Jens Axboe
-
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input:
Input: xen-kbdfront - fix mouse getting stuck after save/restore
Input: estimate number of events per packet
Input: evdev - indicate buffer overrun with SYN_DROPPED
Input: document event types and codes and their intended use
Input: add KEY_IMAGES specifically for AL Image Browser
Input: twl4030_keypad - fix potential NULL dereference in twl4030_kp_probe()
Input: h3600_ts - fix error handling at connect
Input: twl4030_keypad - avoid potential NULL-pointer dereference -
Mouse gets "stuck" after restore of PV guest but buttons are in working
condition.If driver has been configured for ABS coordinates at start it will get
XENKBD_TYPE_POS events and then suddenly after restore it'll start getting
XENKBD_TYPE_MOTION events, that will be dropped later and they won't get
into user-space.Regression was introduced by hunk 5 and 6 of
5ea5254aa0ad269cfbd2875c973ef25ab5b5e9db
("Input: xen-kbdfront - advertise either absolute or relative
coordinates").Driver on restore should ask xen for request-abs-pointer again if it is
available. So restore parts that did it before 5ea5254.Acked-by: Olaf Hering
Signed-off-by: Igor Mammedov
[v1: Expanded the commit description]
Signed-off-by: Konrad Rzeszutek Wilk
Signed-off-by: Dmitry Torokhov -
Calculate a default based on the number of ABS axes, REL axes,
and MT slots for the device during input device registration.Signed-off-by: Jeff Brown
Reviewed-by: Henrik Rydberg
Signed-off-by: Dmitry Torokhov
18 Apr, 2011
1 commit
-
Instead of overloading __blk_run_queue to force an offload to kblockd
add a new blk_run_queue_async helper to do it explicitly. I've kept
the blk_queue_stopped check for now, but I suspect it's not needed
as the check we do when the workqueue items runs should be enough.Signed-off-by: Christoph Hellwig
Signed-off-by: Jens Axboe
