| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
In some virtualized environments (e.g. XEN), there is irrelevant ISA bridge in
the system. To work reliably, we should scan trhough all the ISA bridge
devices and check for the first match, instead of only checking the first one.
Signed-off-by: Rui Guo <[email protected]>
[danvet: Fixup conflict with the num_pch_pll removal. And add
subsystem header to the commit message headline.]
Signed-off-by: Daniel Vetter <[email protected]>
|
|
Because it's the function that destroys the connector, not the
encoder. And we already have intel_dp_encoder_destroy.
This has annoyed me for a long time.
Signed-off-by: Paulo Zanoni <[email protected]>
Reviewed-by: Zoltan Nyul <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
|
|
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc
Pull another powerpc fix from Benjamin Herrenschmidt:
"I mentioned that while we had fixed the kernel crashes, EEH error
recovery didn't always recover... It appears that I had a fix for
that already in powerpc-next (with a stable CC).
I cherry-picked it today and did a few tests and it seems that things
now work quite well. The patch is also pretty simple, so I see no
reason to wait before merging it."
* 'merge' of git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc:
powerpc/eeh: Fix fetching bus for single-dev-PE
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi
Pull SCSI fixes from James Bottomley:
"This is a set of seven bug fixes. Several fcoe fixes for locking
problems, initiator issues and a VLAN API change, all of which could
eventually lead to data corruption, one fix for a qla2xxx locking
problem which could lead to multiple completions of the same request
(and subsequent data corruption) and a use after free in the ipr
driver. Plus one minor MAINTAINERS file update"
(only six bugfixes in this pull, since I had already pulled the fcoe API
fix directly from Robert Love)
* tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi:
[SCSI] ipr: Avoid target_destroy accessing memory after it was freed
[SCSI] qla2xxx: Fix for locking issue between driver ISR and mailbox routines
MAINTAINERS: Fix fcoe mailing list
libfc: extend ex_lock to protect all of fc_seq_send
libfc: Correct check for initiator role
libfcoe: Fix Conflicting FCFs issue in the fabric
|
|
While running Linux as guest on top of phyp, we possiblly have
PE that includes single PCI device. However, we didn't return
its PCI bus correctly and it leads to failure on recovery from
EEH errors for single-dev-PE. The patch fixes the issue.
Cc: <[email protected]> # v3.7+
Cc: Steve Best <[email protected]>
Signed-off-by: Gavin Shan <[email protected]>
Signed-off-by: Benjamin Herrenschmidt <[email protected]>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc
Pull powerpc fixes from Ben Herrenschmidt:
"We discovered some breakage in our "EEH" (PCI Error Handling) code
while doing error injection, due to a couple of regressions. One of
them is due to a patch (37f02195bee9 "powerpc/pci: fix PCI-e devices
rescan issue on powerpc platform") that, in hindsight, I shouldn't
have merged considering that it caused more problems than it solved.
Please pull those two fixes. One for a simple EEH address cache
initialization issue. The other one is a patch from Guenter that I
had originally planned to put in 3.11 but which happens to also fix
that other regression (a kernel oops during EEH error handling and
possibly hotplug).
With those two, the couple of test machines I've hammered with error
injection are remaining up now. EEH appears to still fail to recover
on some devices, so there is another problem that Gavin is looking
into but at least it's no longer crashing the kernel."
* 'merge' of git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc:
powerpc/pci: Improve device hotplug initialization
powerpc/eeh: Add eeh_dev to the cache during boot
|
|
Due to recent changes and expecations of proper cpu bindings, there are
now cases for many of the in-tree devicetrees where a WARN() will hit
on boot due to badly formatted /cpus nodes.
Downgrade this to a pr_warn() to be less alarmist, since it's not a
new problem.
Tested on Arndale, Cubox, Seaboard and Panda ES. Panda hits the WARN
without this, the others do not.
Acked-by: Russell King <[email protected]>
Signed-off-by: Olof Johansson <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
|
|
Commit 37f02195b (powerpc/pci: fix PCI-e devices rescan issue on powerpc
platform) fixes a problem with interrupt and DMA initialization on hot
plugged devices. With this commit, interrupt and DMA initialization for
hot plugged devices is handled in the pci device enable function.
This approach has a couple of drawbacks. First, it creates two code paths
for device initialization, one for hot plugged devices and another for devices
known during the initial PCI scan. Second, the initialization code for hot
plugged devices is only called when the device is enabled, ie typically
in the probe function. Also, the platform specific setup code is called each
time pci_enable_device() is called, not only once during device discovery,
meaning it is actually called multiple times, once for devices discovered
during the initial scan and again each time a driver is re-loaded.
The visible result is that interrupt pins are only assigned to hot plugged
devices when the device driver is loaded. Effectively this changes the PCI
probe API, since pci_dev->irq and the device's dma configuration will now
only be valid after pci_enable() was called at least once. A more subtle
change is that platform specific PCI device setup is moved from device
discovery into the driver's probe function, more specifically into the
pci_enable_device() call.
To fix the inconsistencies, add new function pcibios_add_device.
Call pcibios_setup_device from pcibios_setup_bus_devices if device setup
is not complete, and from pcibios_add_device if bus setup is complete.
With this change, device setup code is moved back into device initialization,
and called exactly once for both static and hot plugged devices.
[ This also fixes a regression introduced by the above patch which
causes dev->irq to be overwritten under some cirumstances after
MSIs have been enabled for the device which leads to crashes due
to the MSI core "hijacking" dev->irq to store the base MSI number
and not the LSI. --BenH
]
Cc: Yuanquan Chen <[email protected]>
Cc: Benjamin Herrenschmidt <[email protected]>
Cc: Hiroo Matsumoto <[email protected]>
Signed-off-by: Guenter Roeck <[email protected]>
Signed-off-by: Benjamin Herrenschmidt <[email protected]>
|
|
Pull crypto fix from Herbert Xu:
"This fixes a crash in the crypto layer exposed by an SCTP test tool"
* git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6:
crypto: algboss - Hold ref count on larval
|
|
Pull drm/qxl fix from Dave Airlie:
"Bad me forgot an access check, possible security issue, but since this
is the first kernel with it, should be fine to just put it in now"
* 'drm-fixes' of git://people.freedesktop.org/~airlied/linux:
drm/qxl: add missing access check for execbuffer ioctl
|
|
This __put_user() could be used by unprivileged processes to write into
kernel memory. The issue here is that even if copy_siginfo_to_user()
fails, the error code is not checked before __put_user() is executed.
Luckily, ptrace_peek_siginfo() has been added within the 3.10-rc cycle,
so it has not hit a stable release yet.
Signed-off-by: Mathieu Desnoyers <[email protected]>
Acked-by: Oleg Nesterov <[email protected]>
Cc: Andrey Vagin <[email protected]>
Cc: Roland McGrath <[email protected]>
Cc: Paul McKenney <[email protected]>
Cc: David Howells <[email protected]>
Cc: Dave Jones <[email protected]>
Cc: Pavel Emelyanov <[email protected]>
Cc: Pedro Alves <[email protected]>
Cc: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/sage/ceph-client
Pull Ceph fix from Sage Weil:
"This is a recently spotted regression in the snapshot behavior...
It turns out several tests weren't being run in the nightlies so this
took a while to spot"
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/sage/ceph-client:
rbd: send snapshot context with writes
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs
Pull ubifs fixes from Al Viro:
"A couple of ubifs readdir/lseek race fixes. Stable fodder, really
nasty..."
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs:
UBIFS: fix a horrid bug
UBIFS: prepare to fix a horrid bug
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-mn10300
Pull two MN10300 fixes from David Howells:
"The first fixes a problem with passing arrays rather than pointers to
get_user() where __typeof__ then wants to declare and initialise an
array variable which gcc doesn't like.
The second fixes a problem whereby putting mem=xxx into the kernel
command line causes init=xxx to get an incorrect value."
* tag 'for-linus-20130628' of git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-mn10300:
mn10300: Use early_param() to parse "mem=" parameter
mn10300: Allow to pass array name to get_user()
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
Pull timer fix from Thomas Gleixner:
"Correct an ordering issue in the tick broadcast code. I really wish
we'd get compensation for pain and suffering for each line of code we
write to work around dysfunctional timer hardware."
* 'timers-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
tick: Fix tick_broadcast_pending_mask not cleared
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
Pull perf fix from Ingo Molnar:
"One more fix for a recently discovered bug"
* 'perf-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
perf: Disable monitoring on setuid processes for regular users
|
|
Al Viro pointed me to the fact that '->readdir()' and '->llseek()' have no
mutual exclusion, which means the 'ubifs_dir_llseek()' can be run while we are
in the middle of 'ubifs_readdir()'.
This means that 'file->private_data' can be freed while 'ubifs_readdir()' uses
it, and this is a very bad bug: not only 'ubifs_readdir()' can return garbage,
but this may corrupt memory and lead to all kinds of problems like crashes an
security holes.
This patch fixes the problem by using the 'file->f_version' field, which
'->llseek()' always unconditionally sets to zero. We set it to 1 in
'ubifs_readdir()' and whenever we detect that it became 0, we know there was a
seek and it is time to clear the state saved in 'file->private_data'.
I tested this patch by writing a user-space program which runds readdir and
seek in parallell. I could easily crash the kernel without these patches, but
could not crash it with these patches.
Cc: [email protected]
Reported-by: Al Viro <[email protected]>
Tested-by: Artem Bityutskiy <[email protected]>
Signed-off-by: Artem Bityutskiy <[email protected]>
Signed-off-by: Al Viro <[email protected]>
|
|
Al Viro pointed me to the fact that '->readdir()' and '->llseek()' have no
mutual exclusion, which means the 'ubifs_dir_llseek()' can be run while we are
in the middle of 'ubifs_readdir()'.
First of all, this means that 'file->private_data' can be freed while
'ubifs_readdir()' uses it. But this particular patch does not fix the problem.
This patch is only a preparation, and the fix will follow next.
In this patch we make 'ubifs_readdir()' stop using 'file->f_pos' directly,
because 'file->f_pos' can be changed by '->llseek()' at any point. This may
lead 'ubifs_readdir()' to returning inconsistent data: directory entry names
may correspond to incorrect file positions.
So here we introduce a local variable 'pos', read 'file->f_pose' once at very
the beginning, and then stick to 'pos'. The result of this is that when
'ubifs_dir_llseek()' changes 'file->f_pos' while we are in the middle of
'ubifs_readdir()', the latter "wins".
Cc: [email protected]
Reported-by: Al Viro <[email protected]>
Tested-by: Artem Bityutskiy <[email protected]>
Signed-off-by: Artem Bityutskiy <[email protected]>
Signed-off-by: Al Viro <[email protected]>
|
|
This fixes the problem that "init=" options may not be passed to kernel
correctly.
parse_mem_cmdline() of mn10300 arch gets rid of "mem=" string from
redboot_command_line. Then init_setup() parses the "init=" options from
static_command_line, which is a copy of redboot_command_line, and keeps
the pointer to the init options in execute_command variable.
Since the commit 026cee0 upstream (params: <level>_initcall-like kernel
parameters), static_command_line becomes overwritten by saved_command_line at
do_initcall_level(). Notice that saved_command_line is a command line
which includes "mem=" string.
As a result, execute_command may point to weird string by the length of
"mem=" parameter.
I noticed this problem when using the command line like this:
mem=128M console=ttyS0,115200 init=/bin/sh
Here is the processing flow of command line parameters.
start_kernel()
setup_arch(&command_line)
parse_mem_cmdline(cmdline_p)
* strcpy(boot_command_line, redboot_command_line);
* Remove "mem=xxx" from redboot_command_line.
* *cmdline_p = redboot_command_line;
setup_command_line(command_line) <-- command_line is redboot_command_line
* strcpy(saved_command_line, boot_command_line)
* strcpy(static_command_line, command_line)
parse_early_param()
strlcpy(tmp_cmdline, boot_command_line, COMMAND_LINE_SIZE);
parse_early_options(tmp_cmdline);
parse_args("early options", cmdline, NULL, 0, 0, 0, do_early_param);
parse_args("Booting ..", static_command_line, ...);
init_setup() <-- save the pointer in execute_command
rest_init()
kernel_thread(kernel_init, NULL, CLONE_FS | CLONE_SIGHAND);
At this point, execute_command points to "/bin/sh" string.
kernel_init()
kernel_init_freeable()
do_basic_setup()
do_initcalls()
do_initcall_level()
(*) strcpy(static_command_line, saved_command_line);
Here, execute_command gets to point to "200" string !!
Signed-off-by: David Howells <[email protected]>
|
|
This fixes the following compile error:
CC block/scsi_ioctl.o
block/scsi_ioctl.c: In function 'sg_scsi_ioctl':
block/scsi_ioctl.c:449: error: invalid initializer
Signed-off-by: David Howells <[email protected]>
|
|
We've been ignoring this return value, so print a nice backtrace in
case it's not what we expected.
Signed-off-by: Paulo Zanoni <[email protected]>
Reviewed-by: Zoltan Nyul <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
|
|
Because calling intel_dp_encoder_destroy inside
intel_edp_init_connector is just wrong. This is the initialization
path, so we should properly unwind all the initialization through the
whole caller stack.
On the intel_dp_encoder_destroy function we do the following:
1 - Call i2c_del_adapter
2 - Call drm_encoder_cleanup
3 - If edp:
3.1 - Cancel panel_vdd_work
3.2 - Call ironlake_panel_vdd_of_sync
4 - Free the encoder
And here is how we unwind each specific step:
1 - We have intel_dp_init_connector -> intel_dp_i2c_init ->
i2c_dp_aux_add_bus -> i2c_add_adapter, so we call
i2c_del_dapter at intel_dp_init_connector
2 - Call it in the same function that called drm_encoder_init
3 - Call it in the same function that called INIT_DELAYED_WORK
4 - Free it in the same function that allocated it
Signed-off-by: Paulo Zanoni <[email protected]>
Reviewed-by: Zoltan Nyul <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
|
|
Because calling intel_dp_destroy inside intel_edp_init_connector is
just wrong. This is the initialization path, so we should properly
unwind all the initialization through the whole caller stack.
On the intel_dp_destroy function we do the following:
1 - Free edid if it exists
2 - Call intel_panel_fini in case it's eDP
3 - Call drm_sysfs_connector_remove
4 - Call drm_connector_cleanup
5 - Free the connector
And here is how we unwind each specific step:
1 - No need as we still didn't assign anything
2 - No need as we still didn't call intel_panel_init
3 - Call it in the same function that called drm_sysfs_connector_add
4 - Call it in the same function that called drm_connector_init
5 - Free it in the same function that allocated it
Signed-off-by: Paulo Zanoni <[email protected]>
Reviewed-by: Zoltan Nyul <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
|
|
In case we detect a "ghost eDP", intel_edp_init_connector frees both
the connector and encoder and then returns. On Haswell, intel_ddi_init
then tries to use the freed encoder on the HDMI initialization path
since the following commit:
commit 21a8e6a4853b2ed39fa4c5188a710f2cf1b92026
Author: Daniel Vetter <[email protected]>
Date: Wed Apr 10 23:28:35 2013 +0200
drm/i915: don't setup hdmi for port D edp in ddi_init
So now on intel_ddi_init we check for the "ghost eDP" case and return
without trying to initialize HDMI. This way we won't try to read the
freed "intel_encoder" struct in the next "if" statement.
Signed-off-by: Paulo Zanoni <[email protected]>
Reviewed-by: Zoltan Nyul <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
|
|
Because intel_dp_init_connector is too big for my poor little brain.
No functional changes.
Signed-off-by: Paulo Zanoni <[email protected]>
Reviewed-by: Zoltan Nyul <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
|
|
By the time we call intel_dp_destroy (which destroys the connector)
the encoder may have been destroyed already, so if we use it we may be
reading some free memory. That happens in drm_mode_config_cleanup()
and also inside intel_dp_init_connector() when we detect a ghost eDP.
I also hope this may solve some random memory bugs.
Reported by kmemcheck.
Signed-off-by: Paulo Zanoni <[email protected]>
Reviewed-by: Zoltan Nyul <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
|
|
This reverts commit 160954b7bca43da7cd3cfbce310e6df919a8216e.
This was rearming the workqueue with a 0 timeout, causing
a WARN_ON, and possible loop.
Daniel writes:
"I've looked a bit into this and I think we need to have a separate
work struct for recovering these lost hotplug events since the
continuous self-rearming case is a real risk (e.g. if a connector
flip-flops all the time). At least I don't see a sane way to block out
re-arming with the current code in a simple way. So reverting the
offender seems like the right thing and I'll go back to the drawing
board for 3.12."
Signed-off-by: Dave Airlie <[email protected]>
|
|
Signed-off-by: Laurent Pinchart <[email protected]>
Reviewed-by: Alex Deucher <[email protected]>
Signed-off-by: Dave Airlie <[email protected]>
|
|
The i915 driver has been fixed not to modify the mode argument of the
encoder mode_fixup operation. Remove the related comment from the
documentation.
Signed-off-by: Laurent Pinchart <[email protected]>
Reviewed-by: Alex Deucher <[email protected]>
Signed-off-by: Dave Airlie <[email protected]>
|
|
Define the rules for using irqs from drm drivers.
Signed-off-by: Laurent Pinchart <[email protected]>
Reviewed-by: Daniel Vetter <[email protected]>
Signed-off-by: Dave Airlie <[email protected]>
|
|
The dma_buf_fd() can return error when it fails to prepare fd,
so the dma_buf needs to be put.
Signed-off-by: YoungJun Cho <[email protected]>
Signed-off-by: Seung-Woo Kim <[email protected]>
Signed-off-by: Kyungmin Park <[email protected]>
Signed-off-by: Dave Airlie <[email protected]>
|
|
Signed-off-by: Seung-Woo Kim <[email protected]>
Signed-off-by: YoungJun Cho <[email protected]>
Signed-off-by: Kyungmin Park <[email protected]>
Signed-off-by: Dave Airlie <[email protected]>
|
|
Reported-by: Mathieu Desnoyers <[email protected]>
Signed-off-by: Dave Airlie <[email protected]>
|
|
When drm_prime_add_buf_handle() returns failure for an exported
dma_buf, the dma_buf was already allocated and its refcount was
increased, so it needs to be put.
Signed-off-by: YoungJun Cho <[email protected]>
Signed-off-by: Seung-Woo Kim <[email protected]>
Signed-off-by: Kyungmin Park <[email protected]>
Signed-off-by: Dave Airlie <[email protected]>
|
|
The drm prime also can support it like GEM CMA supports to cache
mapping. It doesn't allow multiple mappings for one attachment.
[airlied: rebased on top of other prime changes]
Signed-off-by: Joonyoung Shim <[email protected]>
Signed-off-by: Dave Airlie <[email protected]>
|
|
Instead of NULL, error value is casted with ERR_PTR() for
drm_prime_pages_to_sg() and IS_ERR_OR_NULL() macro is replaced
with IS_ERR() macro for drm_gem_map_dma_buf().
Signed-off-by: YoungJun Cho <[email protected]>
Signed-off-by: Seung-Woo Kim <[email protected]>
Signed-off-by: Kyungmin Park <[email protected]>
Signed-off-by: Dave Airlie <[email protected]>
|
|
The dma_map_sg(), in map_dma_buf callback operation of prime helper,
can return 0 when it fails to map, so it needs to release related
resources.
Signed-off-by: YoungJun Cho <[email protected]>
Signed-off-by: Seung-Woo Kim <[email protected]>
Signed-off-by: Kyungmin Park <[email protected]>
Signed-off-by: Dave Airlie <[email protected]>
|
|
If idr_alloc() is failed, obj->name can be error value. Also
it cleans up duplicated flink processing code.
This regression has been introduced in
commit 2e928815c1886fe628ed54623aa98d0889cf5509
Author: Tejun Heo <[email protected]>
Date: Wed Feb 27 17:04:08 2013 -0800
drm: convert to idr_alloc()
Signed-off-by: YoungJun Cho <[email protected]>
Signed-off-by: Seung-Woo Kim <[email protected]>
Signed-off-by: Kyungmin Park <[email protected]>
Cc: [email protected]
Reviewed-by: Chris Wilson <[email protected]>
Signed-off-by: Dave Airlie <[email protected]>
|
|
The drm_gem_mmap_obj() has to be protected with dev->struct_mutex,
but some caller functions do not. So it adds mutex lock to missing
callers and adds assertion to check whether drm_gem_mmap_obj() is
called with mutex lock or not.
Signed-off-by: YoungJun Cho <[email protected]>
Signed-off-by: Seung-Woo Kim <[email protected]>
Signed-off-by: Kyungmin Park <[email protected]>
Reviewed-by: Maarten Lankhorst <[email protected]>
Reviewed-by: Laurent Pinchart <[email protected]>
Reviewed-by: Rob Clark <[email protected]>
Reviewed-by: Maarten Lankhorst <[email protected]>
Signed-off-by: Dave Airlie <[email protected]>
|
|
This ends up causing circularity and really let people shoot themselves
in the foot.
Acked-by: Rob Clark <[email protected]>
Signed-off-by: Dave Airlie <[email protected]>
|
|
Signed-off-by: Maarten Lankhorst <[email protected]>
Signed-off-by: Dave Airlie <[email protected]>
|
|
Use lockdep_assert_held instead.
Signed-off-by: Maarten Lankhorst <[email protected]>
Signed-off-by: Dave Airlie <[email protected]>
|
|
Try to use lockdep_assert_held or other alternatives where possible.
Signed-off-by: Maarten Lankhorst <[email protected]>
Reviewed-by: Jerome Glisse <[email protected]>
Signed-off-by: Dave Airlie <[email protected]>
|
|
Use lockdep_assert_held instead.
Signed-off-by: Maarten Lankhorst <[email protected]>
Signed-off-by: Dave Airlie <[email protected]>
|
|
Makes lockdep a lot more useful.
Signed-off-by: Maarten Lankhorst <[email protected]>
Signed-off-by: Dave Airlie <[email protected]>
|
|
Signed-off-by: Maarten Lankhorst <[email protected]>
Reviewed-by: Jerome Glisse <[email protected]>
Signed-off-by: Dave Airlie <[email protected]>
|
|
Signed-off-by: Maarten Lankhorst <[email protected]>
Signed-off-by: Dave Airlie <[email protected]>
|
|
Signed-off-by: Maarten Lankhorst <[email protected]>
Signed-off-by: Dave Airlie <[email protected]>
|
|
Signed-off-by: Maarten Lankhorst <[email protected]>
Signed-off-by: Dave Airlie <[email protected]>
|