Calling the START_ISO ioctl with a nonnegative cycle paramater has
never worked. Last night I got around to figuring out why. Most of
this patch is a big comment explaining why we enable an interrupt
source then don't actually do anything when we get one. As the
comment says, we should do more, but we don't have a way to tell
userspace what happened. . .
Signed-off-by: Jay Fenlason <fenlason@redhat.com>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de> (edited comment)
The Unit_Characteristics entry of an SBP-2 unit directory is not
mandatory as far as I can tell. If it is missing, we would probably
fail to log in into the target because firewire-sbp2 would not wait for
status after it sent the login request.
The fix moves the cleanup of tgt->mgt_orb_timeout into a place where it
is executed exactly once before login, rather than 0..n times depending
on the target's config ROM. With targets with one or more
Unit_Characteristics entries, the result is the same as before.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Add the file pattern of drivers/ieee1394/init_ohci1394_dma.c's
documentation to the maintainers database. init_ohci1394_dma.c is not
really part of the IEEE 1394 subsystem, but this maintainers contact
seems to be better than none at all.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Per SBP-2 clause 5.3, a target shall store 8...32 bytes of status
information. Trailing zeros after the first 8 bytes don't need to be
stored, they are implicit. Fix the status write handler to clear all
unwritten status data.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
This register is 1 kBytes large. Adjust topology_map.length to prevent
registration of other response handlers in this region and to make sure
that we respond to requests to the upper half of the register.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
The config ROM buffer received from generate_config_rom is a globally
shared static buffer. Extend the card_mutex protection in fw_add_card
until after the config ROM was copied into the card driver's buffer.
Otherwise, parallelized card driver probes may end up with ROM contents
that were meant for a different card.
firewire-ohci's card->driver->enable hook is safe to be called within
the card_mutex. Furthermore, it is safe to reorder card_list update
versus card enable, which simplifies the code a little.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
fw_card_get, fw_card_put, fw_card_release are currently not exported for
use outside the firewire-core. Move their definitions/ declarations
from the subsystem header file to the core header file.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
The selfIDSize field of Self ID Count is 9 bits wide, and we are only
interested in the high 8 bits. Fix the mask accordingly. The
previously too large mask didn't do damage though because the next few
bits in the register are reserved and therefore zero with presently
existing hardware.
Also, check for the maximum possible self ID count of 252 (according to
OHCI 1.1 clause 11.2 and IEEE 1394a-2000 clause 4.3.4.1, i.e. up to four
self IDs of up to 63 nodes, even though IEEE 1394 up to edition 2008
defines only up to three self IDs per node). More than 252 self IDs
would only happen if the self ID receive DMA unit malfunctioned, which
would likely be caught by other self ID buffer checks. However, check
it early to be sure. More than 253 quadlets would overflow the Topology
Map CSR.
Reported-By: PaX Team
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Do not leak the allocated memory in case the mutex_trylock() failed
to acquire the lock.
Signed-off-by: Michael Buesch <mb@bu3sch.de>
This bug does not happen in practice: All raw1394 clients use
libraw1394, and accesses to a libraw1394 handle need to be serialized
by the client. This is documented in libraw1394's API reference.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Andy Whitcroft reported an oops in aoe triggered by use of an
incorrectly initialised request_queue object:
[ 2645.959090] kobject '<NULL>' (ffff880059ca22c0): tried to add
an uninitialized object, something is seriously wrong.
[ 2645.959104] Pid: 6, comm: events/0 Not tainted 2.6.31-5-generic #24-Ubuntu
[ 2645.959107] Call Trace:
[ 2645.959139] [<ffffffff8126ca2f>] kobject_add+0x5f/0x70
[ 2645.959151] [<ffffffff8125b4ab>] blk_register_queue+0x8b/0xf0
[ 2645.959155] [<ffffffff8126043f>] add_disk+0x8f/0x160
[ 2645.959161] [<ffffffffa01673c4>] aoeblk_gdalloc+0x164/0x1c0 [aoe]
The request queue of an aoe device is not used but can be allocated in
code that does not sleep.
Bruno bisected this regression down to
cd43e26f07
block: Expose stacked device queues in sysfs
"This seems to generate /sys/block/$device/queue and its contents for
everyone who is using queues, not just for those queues that have a
non-NULL queue->request_fn."
Addresses http://bugs.launchpad.net/bugs/410198
Addresses http://bugzilla.kernel.org/show_bug.cgi?id=13942
Note that embedding a queue inside another object has always been
an illegal construct, since the queues are reference counted and
must persist until the last reference is dropped. So aoe was
always buggy in this respect (Jens).
Signed-off-by: Ed Cashin <ecashin@coraid.com>
Cc: Andy Whitcroft <apw@canonical.com>
Cc: "Rafael J. Wysocki" <rjw@sisk.pl>
Cc: Bruno Premont <bonbons@linux-vserver.org>
Cc: Martin K. Petersen <martin.petersen@oracle.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Jens Axboe <jens.axboe@oracle.com>
Reinette Chatre reports a frozen system (with blinking keyboard LEDs)
when switching from graphics mode to the text console, or when
suspending (which does the same thing). With netconsole, the oops
turned out to be
BUG: unable to handle kernel NULL pointer dereference at 0000000000000084
IP: [<ffffffffa03ecaab>] i915_driver_irq_handler+0x26b/0xd20 [i915]
and it's due to the i915_gem.c code doing drm_irq_uninstall() after
having done i915_gem_idle(). And the i915_gem_idle() path will do
i915_gem_idle() ->
i915_gem_cleanup_ringbuffer() ->
i915_gem_cleanup_hws() ->
dev_priv->hw_status_page = NULL;
but if an i915 interrupt comes in after this stage, it may want to
access that hw_status_page, and gets the above NULL pointer dereference.
And since the NULL pointer dereference happens from within an interrupt,
and with the screen still in graphics mode, the common end result is
simply a silently hung machine.
Fix it by simply uninstalling the irq handler before idling rather than
after. Fixes
http://bugzilla.kernel.org/show_bug.cgi?id=13819
Reported-and-tested-by: Reinette Chatre <reinette.chatre@intel.com>
Acked-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/anholt/drm-intel:
agp/intel: support for new chip variant of IGDNG mobile
drm/i915: Unref old_obj on get_fence_reg() error path
drm/i915: increase default latency constant (v2 w/comment)
This adds some rv350+ register for LTE/GTE discard,
and enables the rv515 two sided stencil register.
It also disables the DEPTHXY_OFFSET register which
can be used to workaround the CS checker.
Moves rs690 to proper place in rs600 and uses correct
table on rs600.
Signed-off-by: Dave Airlie <airlied@redhat.com>
- As ima_counts_put() may be called after the inode has been freed,
verify that the inode is not NULL, before dereferencing it.
- Maintain the IMA file counters in may_open() properly, decrementing
any counter increments on subsequent errors.
Reported-by: Ciprian Docan <docan@eden.rutgers.edu>
Reported-by: J.R. Okajima <hooanon05@yahoo.co.jp>
Signed-off-by: Mimi Zohar <zohar@us.ibm.com>
Acked-by: Eric Paris <eparis@redhat.com
Signed-off-by: James Morris <jmorris@namei.org>
Reported by Michael Guntsche <mike@it-loops.com>
--------------------
Commit
38bddf04bc gianfar: gfar_remove needs to call unregister_netdev()
breaks the build of the gianfar driver because "dev" is undefined in
this function. To quickly test rc9 I changed this to priv->ndev but I do
not know if this is the correct one.
--------------------
Signed-off-by: David S. Miller <davem@davemloft.net>