Skip to content

R
raspberrypi-kernel

openeuler / raspberrypi-kernel

通知 13
Star 1
Fork 0
R
raspberrypi-kernel
切换分支/标签
  1. 08 5月, 2014 1 次提交
  3. 07 5月, 2014 4 次提交
    • N
      PM / OPP: Move cpufreq specific OPP functions out of generic OPP library · a0dd7b79
      由 Nishanth Menon 提交于 
      CPUFreq specific helper functions for OPP (Operating Performance Points)
now use generic OPP functions that allow CPUFreq to be be moved back
into CPUFreq framework. This allows for independent modifications
or future enhancements as needed isolated to just CPUFreq framework
alone.

Here, we just move relevant code and documentation to make this part of
CPUFreq infrastructure.

Cc: Kevin Hilman <khilman@deeprootsystems.com>
Signed-off-by: NNishanth Menon <nm@ti.com>
Acked-by: NViresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      a0dd7b79
    • N
      PM / OPP: Remove cpufreq wrapper dependency on internal data organization · 0f5c890e
      由 Nishanth Menon 提交于 
      CPUFREQ custom functions for OPP (Operating Performance Points)
currently exist inside the OPP library. These custom functions currently
depend on internal data structures to pick up OPP information to create
the cpufreq table.  For example, the cpufreq table is created precisely
in the same order of how OPP entries are stored inside the list implementation.

This kind of tight interdependency is purely artificial since the same
functionality can be achieved using the generic OPP functions
meant to do the same. This interdependency also limits the independent
modification of cpufreq and OPP library.

So use the generic dev_pm_opp_find_freq_ceil function that achieves the
table organization as we currently use.

As a result of this, we dont need to use the internal device_opp
structure anymore, and we hence we can switch over to rcu lock instead
of the mutex holding the internal list lock.

This breaking of dependency on internal data structure imposes no change
to usage of these.

NOTE: This change is a precursor to moving this cpufreq specific logic
out of the generic library into cpufreq.

Cc: Kevin Hilman <khilman@deeprootsystems.com>
Signed-off-by: NNishanth Menon <nm@ti.com>
Acked-by: NViresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      0f5c890e
    • S
      cpufreq: Catch double invocations of cpufreq_freq_transition_begin/end · ca654dc3
      由 Srivatsa S. Bhat 提交于 
      Some cpufreq drivers were redundantly invoking the _begin() and _end()
APIs around frequency transitions, and this double invocation (one from
the cpufreq core and the other from the cpufreq driver) used to result
in a self-deadlock, leading to system hangs during boot. (The _begin()
API makes contending callers wait until the previous invocation is
complete. Hence, the cpufreq driver would end up waiting on itself!).

Now all such drivers have been fixed, but debugging this issue was not
very straight-forward (even lockdep didn't catch this). So let us add a
debug infrastructure to the cpufreq core to catch such issues more easily
in the future.

We add a new field called 'transition_task' to the policy structure, to keep
track of the task which is performing the frequency transition. Using this
field, we make note of this task during _begin() and print a warning if we
find a case where the same task is calling _begin() again, before completing
the previous frequency transition using the corresponding _end().

We have left out ASYNC_NOTIFICATION drivers from this debug infrastructure
for 2 reasons:

1. At the moment, we have no way to avoid a particular scenario where this
   debug infrastructure can emit false-positive warnings for such drivers.
   The scenario is depicted below:

         Task A						Task B

    /* 1st freq transition */
    Invoke _begin() {
            ...
            ...
    }

    Change the frequency

    /* 2nd freq transition */
    Invoke _begin() {
	    ...	//waiting for B to
            ... //finish _end() for
	    ... //the 1st transition
	    ...	      |				Got interrupt for successful
	    ...	      |				change of frequency (1st one).
	    ...       |
	    ...	      |				/* 1st freq transition */
	    ...	      |				Invoke _end() {
	    ...	      |					...
	    ...	      V				}
	    ...
	    ...
    }

   This scenario is actually deadlock-free because, once Task A changes the
   frequency, it is Task B's responsibility to invoke the corresponding
   _end() for the 1st frequency transition. Hence it is perfectly legal for
   Task A to go ahead and attempt another frequency transition in the meantime.
   (Of course it won't be able to proceed until Task B finishes the 1st _end(),
   but this doesn't cause a deadlock or a hang).

   The debug infrastructure cannot handle this scenario and will treat it as
   a deadlock and print a warning. To avoid this, we exclude such drivers
   from the purview of this code.

2. Luckily, we don't _need_ this infrastructure for ASYNC_NOTIFICATION drivers
   at all! The cpufreq core does not automatically invoke the _begin() and
   _end() APIs during frequency transitions in such drivers. Thus, the driver
   alone is responsible for invoking _begin()/_end() and hence there shouldn't
   be any conflicts which lead to double invocations. So, we can skip these
   drivers, since the probability that such drivers will hit this problem is
   extremely low, as outlined above.
Signed-off-by: NSrivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
Acked-by: NViresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      ca654dc3
    • S
      intel_pstate: Remove sample parameter in intel_pstate_calc_busy · 6b17ddb2
      由 Stratos Karafotis 提交于 
      Since commit d37e2b76 ("intel_pstate: remove unneeded sample buffers")
we use only one sample. So, there is no need to pass the sample
pointer to intel_pstate_calc_busy. Instead, get the pointer from
cpudata. Also, remove the unused SAMPLE_COUNT macro.

While at it, reformat the first line in this function.
Signed-off-by: NStratos Karafotis <stratosk@semaphore.gr>
Acked-by: NViresh Kumar <viresh.kumar@linaro.org>
Acked-by: NDirk Brandewie <dirk.j.brandewie@intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      6b17ddb2
  5. 04 5月, 2014 1 次提交
  7. 02 5月, 2014 1 次提交
  9. 01 5月, 2014 6 次提交
  11. 30 4月, 2014 11 次提交
  13. 29 4月, 2014 16 次提交
    • M
      dm thin: use INIT_WORK_ONSTACK in noflush_work to avoid ODEBUG warning · fbcde3d8
      由 Mike Snitzer 提交于 
      Use INIT_WORK_ONSTACK to silence "ODEBUG: object is on stack, but not
annotated".
Reported-by: NZdeněk Kabeláč <zkabelac@redhat.com>
Signed-off-by: NMike Snitzer <snitzer@redhat.com>
Acked-by: NJoe Thornber <ejt@redhat.com>
      fbcde3d8
    • G
      drivercore: deferral race condition fix · 58b116bc
      由 Grant Likely 提交于 
      When the kernel is built with CONFIG_PREEMPT it is possible to reach a state
when all modules loaded but some driver still stuck in the deferred list
and there is a need for external event to kick the deferred queue to probe
these drivers.

The issue has been observed on embedded systems with CONFIG_PREEMPT enabled,
audio support built as modules and using nfsroot for root filesystem.

The following log fragment shows such sequence when all audio modules
were loaded but the sound card is not present since the machine driver has
failed to probe due to missing dependency during it's probe.
The board is am335x-evmsk (McASP<->tlv320aic3106 codec) with davinci-evm
machine driver:

...
[   12.615118] davinci-mcasp 4803c000.mcasp: davinci_mcasp_probe: ENTER
[   12.719969] davinci_evm sound.3: davinci_evm_probe: ENTER
[   12.725753] davinci_evm sound.3: davinci_evm_probe: snd_soc_register_card
[   12.753846] davinci-mcasp 4803c000.mcasp: davinci_mcasp_probe: snd_soc_register_component
[   12.922051] davinci-mcasp 4803c000.mcasp: davinci_mcasp_probe: snd_soc_register_component DONE
[   12.950839] davinci_evm sound.3: ASoC: platform (null) not registered
[   12.957898] davinci_evm sound.3: davinci_evm_probe: snd_soc_register_card DONE (-517)
[   13.099026] davinci-mcasp 4803c000.mcasp: Kicking the deferred list
[   13.177838] davinci-mcasp 4803c000.mcasp: really_probe: probe_count = 2
[   13.194130] davinci_evm sound.3: snd_soc_register_card failed (-517)
[   13.346755] davinci_mcasp_driver_init: LEAVE
[   13.377446] platform sound.3: Driver davinci_evm requests probe deferral
[   13.592527] platform sound.3: really_probe: probe_count = 0

In the log the machine driver enters it's probe at 12.719969 (this point it
has been removed from the deferred lists). McASP driver already executing
it's probing (since 12.615118).
The machine driver tries to construct the sound card (12.950839) but did
not found one of the components so it fails. After this McASP driver
registers all the ASoC components (the machine driver still in it's probe
function after it failed to construct the card) and the deferred work is
prepared at 13.099026 (note that this time the machine driver is not in the
lists so it is not going to be handled when the work is executing).
Lastly the machine driver exit from it's probe and the core places it to
the deferred list but there will be no other driver going to load and the
deferred queue is not going to be kicked again - till we have external event
like connecting USB stick, etc.

The proposed solution is to try the deferred queue once more when the last
driver is asking for deferring and we had drivers loaded while this last
driver was probing.

This way we can avoid drivers stuck in the deferred queue.
Signed-off-by: NGrant Likely <grant.likely@linaro.org>
Reviewed-by: NPeter Ujfalusi <peter.ujfalusi@ti.com>
Tested-by: NPeter Ujfalusi <peter.ujfalusi@ti.com>
Acked-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Mark Brown <broonie@kernel.org>
Cc: Stable <stable@vger.kernel.org> # v3.4+
      58b116bc
    • A
      clocksource: nspire: Fix compiler warning · 9afa27ce
      由 Alexander Shiyan 提交于 
      CC      drivers/clocksource/zevio-timer.o
drivers/clocksource/zevio-timer.c:215:1: warning: comparison of distinct pointer types lacks a cast [enabled by default]
Signed-off-by: NAlexander Shiyan <shc_work@mail.ru>
Signed-off-by: NDaniel Lezcano <daniel.lezcano@linaro.org>
      9afa27ce
    • L
      clocksource: arch_arm_timer: Fix age-old arch timer C3STOP detection issue · 82a56194
      由 Lorenzo Pieralisi 提交于 
      ARM arch timers are tightly coupled with the CPU logic and lose context
on platform implementing HW power management when cores are powered
down at run-time. Marking the arch timers as C3STOP regardless of power
management capabilities causes issues on platforms with no power management,
since in that case the arch timers cannot possibly enter states where the
timer loses context at runtime and therefore can always be used as a high
resolution clockevent device.

In order to fix the C3STOP issue in a way compliant with how real HW
works, this patch adds a boolean property to the arch timer bindings
to define if the arch timer is managed by an always-on power domain.

This power domain is present on all ARM platforms to date, and manages
HW that must not be turned off, whatever the state of other HW
components (eg power controller). On platforms with no power management
capabilities, it is the only power domain present, which encompasses
and manages power supply for all HW components in the system.

If the timer is powered by the always-on power domain, the always-on
property must be present in the bindings which means that the timer cannot
be shutdown at runtime, so it is not a C3STOP clockevent device.
If the timer binding does not contain the always-on property, the timer is
assumed to be power-gateable, hence it must be defined as a C3STOP
clockevent device.

Cc: Daniel Lezcano <daniel.lezcano@linaro.org>
Cc: Magnus Damm <damm@opensource.se>
Cc: Marc Carino <marc.ceeeee@gmail.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Acked-by: NMarc Zyngier <marc.zyngier@arm.com>
Acked-by: NRob Herring <robh@kernel.org>
Signed-off-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Signed-off-by: NDaniel Lezcano <daniel.lezcano@linaro.org>
      82a56194
    • H
      RDMA/cxgb4: Update Kconfig to include Chelsio T5 adapter · 7d0a73a4
      由 Hariprasad S 提交于 
      Signed-off-by: NHariprasad Shenai <hariprasad@chelsio.com>
Signed-off-by: NRoland Dreier <roland@purestorage.com>
      7d0a73a4
    • S
      RDMA/cxgb4: Only allow kernel db ringing for T4 devs · c2f9da92
      由 Steve Wise 提交于 
      The whole db drop avoidance stuff is for T4 only.  So we cannot allow
that to be enabled for T5 devices.
Signed-off-by: NSteve Wise <swise@opengridcomputing.com>
Signed-off-by: NRoland Dreier <roland@purestorage.com>
      c2f9da92
    • S
      RDMA/cxgb4: Force T5 connections to use TAHOE congestion control · 92e5011a
      由 Steve Wise 提交于 
      This is required to work around a T5 HW issue.
Signed-off-by: NSteve Wise <swise@opengridcomputing.com>
Signed-off-by: NRoland Dreier <roland@purestorage.com>
      92e5011a
    • S
      RDMA/cxgb4: Fix endpoint mutex deadlocks · cc18b939
      由 Steve Wise 提交于 
      In cases where the cm calls c4iw_modify_rc_qp() with the endpoint
mutex held, they must be called with internal == 1.  rx_data() and
process_mpa_reply() are not doing this.  This causes a deadlock
because c4iw_modify_rc_qp() might call c4iw_ep_disconnect() in some
!internal cases, and c4iw_ep_disconnect() acquires the endpoint mutex.
The design was intended to only do the disconnect for !internal calls.

Change rx_data(), FPDU_MODE case, to call c4iw_modify_rc_qp() with
internal == 1, and then disconnect only after releasing the mutex.

Change process_mpa_reply() to call c4iw_modify_rc_qp(TERMINATE) with
internal == 1 and set a new attr flag telling it to send a TERMINATE
message.  Previously this was implied by !internal.

Change process_mpa_reply() to return whether the caller should
disconnect after releasing the endpoint mutex.  Now rx_data() will do
the disconnect in the cases where process_mpa_reply() wants to
disconnect after the TERMINATE is sent.

Change c4iw_modify_rc_qp() RTS->TERM to only disconnect if !internal,
and to send a TERMINATE message if attrs->send_term is 1.

Change abort_connection() to not aquire the ep mutex for setting the
state, and make all calls to abort_connection() do so with the mutex
held.
Signed-off-by: NSteve Wise <swise@opengridcomputing.com>
Signed-off-by: NRoland Dreier <roland@purestorage.com>
      cc18b939
    • T
      cpufreq: ppc-corenet-cpufreq: Fix __udivdi3 modpost error · 6712d293
      由 Tim Gardner 提交于 
      bfa709bc (cpufreq: powerpc: add cpufreq
transition latency for FSL e500mc SoCs) introduced a modpost error:

ERROR: "__udivdi3" [drivers/cpufreq/ppc-corenet-cpufreq.ko] undefined!
make[1]: *** [__modpost] Error 1

Fix this by avoiding 64 bit integer division.

gcc version 4.8.2

Fixes: bfa709bc (cpufreq: powerpc: add cpufreq transition latency for FSL e500mc SoCs)
Signed-off-by: NTim Gardner <tim.gardner@canonical.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      6712d293
    • S
      cpufreq: powernow-k7: Fix double invocation of cpufreq_freq_transition_begin/end · 8997b185
      由 Srivatsa S. Bhat 提交于 
      During frequency transitions, the cpufreq core takes the responsibility of
invoking cpufreq_freq_transition_begin() and cpufreq_freq_transition_end()
for those cpufreq drivers that define the ->target_index callback but don't
set the ASYNC_NOTIFICATION flag.

The powernow-k7 cpufreq driver falls under this category, but this driver was
invoking the _begin() and _end() APIs itself around frequency transitions,
which led to double invocation of the _begin() API. The _begin API makes
contending callers wait until the previous invocation is complete. Hence,
the powernow-k7 driver ended up waiting on itself, leading to system hangs
during boot.

Fix this by removing the calls to the _begin() and _end() APIs from the
powernow-k7 driver, since they rightly belong to the cpufreq core.

Fixes: 12478cf0 (cpufreq: Make sure frequency transitions are serialized)
Signed-off-by: NSrivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
Acked-by: NViresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      8997b185
    • S
      cpufreq: powernow-k6: Fix double invocation of cpufreq_freq_transition_begin/end · 3221e55b
      由 Srivatsa S. Bhat 提交于 
      During frequency transitions, the cpufreq core takes the responsibility of
invoking cpufreq_freq_transition_begin() and cpufreq_freq_transition_end()
for those cpufreq drivers that define the ->target_index callback but don't
set the ASYNC_NOTIFICATION flag.

The powernow-k6 cpufreq driver falls under this category, but this driver was
invoking the _begin() and _end() APIs itself around frequency transitions,
which led to double invocation of the _begin() API. The _begin API makes
contending callers wait until the previous invocation is complete. Hence,
the powernow-k6 driver ended up waiting on itself, leading to system hangs
during boot.

Fix this by removing the calls to the _begin() and _end() APIs from the
powernow-k6 driver, since they rightly belong to the cpufreq core.

(Note that during ->exit(), the powernow-k6 driver sets the frequency
 without any help from the cpufreq core. So add explicit calls to the
 _begin() and _end() APIs around that frequency transition alone, to take
 care of that special case. Also, add a missing 'break' statement there.)

Fixes: 12478cf0 (cpufreq: Make sure frequency transitions are serialized)
Signed-off-by: NSrivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
Acked-by: NViresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      3221e55b
    • S
      cpufreq: powernow-k6: Fix incorrect comparison with max_multipler · 237ede16
      由 Srivatsa S. Bhat 提交于 
      The value of 'max_multiplier' is meant to be used for comparison with
clock_ratio[index].driver_data, not the index itself! Fix the code in
powernow_k6_cpu_exit() that has this bug.

Also, while at it, make the for-loop condition look for CPUFREQ_TABLE_END,
instead of hard-coding the loop count to 8.
Reported-by: NViresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: NSrivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
Acked-by: NViresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      237ede16
    • S
      cpufreq: longhaul: Fix double invocation of cpufreq_freq_transition_begin/end · 7aa0557f
      由 Srivatsa S. Bhat 提交于 
      During frequency transitions, the cpufreq core takes the responsibility of
invoking cpufreq_freq_transition_begin() and cpufreq_freq_transition_end()
for those cpufreq drivers that define the ->target_index callback but don't
set the ASYNC_NOTIFICATION flag.

The longhaul cpufreq driver falls under this category, but this driver was
invoking the _begin() and _end() APIs itself around frequency transitions,
which led to double invocation of the _begin() API. The _begin API makes
contending callers wait until the previous invocation is complete. Hence,
the longhaul driver ended up waiting on itself, leading to system hangs
during boot.

Fix this by removing the calls to the _begin() and _end() APIs from the
longhaul driver, since they rightly belong to the cpufreq core.

(Note that during module_exit(), the longhaul driver sets the frequency
 without any help from the cpufreq core. So add explicit calls to the
 _begin() and _end() APIs around that frequency transition alone, to take
 care of that special case.)

Fixes: 12478cf0 (cpufreq: Make sure frequency transitions are serialized)
Reported-and-tested-by: NMeelis Roos <mroos@linux.ee>
Signed-off-by: NSrivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      7aa0557f
    • F
      [SCSI] virtio-scsi: Skip setting affinity on uninitialized vq · 0c8482ac
      由 Fam Zheng 提交于 
      virtscsi_init calls virtscsi_remove_vqs on err, even before initializing
the vqs. The latter calls virtscsi_set_affinity, so let's check the
pointer there before setting affinity on it.

This fixes a panic when setting device's num_queues=2 on RHEL 6.5:

qemu-system-x86_64 ... \
-device virtio-scsi-pci,id=scsi0,addr=0x13,...,num_queues=2 \
-drive file=/stor/vm/dummy.raw,id=drive-scsi-disk,... \
-device scsi-hd,drive=drive-scsi-disk,...

[    0.354734] scsi0 : Virtio SCSI HBA
[    0.379504] BUG: unable to handle kernel NULL pointer dereference at 0000000000000020
[    0.380141] IP: [<ffffffff814741ef>] __virtscsi_set_affinity+0x4f/0x120
[    0.380141] PGD 0
[    0.380141] Oops: 0000 [#1] SMP
[    0.380141] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.14.0+ #5
[    0.380141] Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2007
[    0.380141] task: ffff88003c9f0000 ti: ffff88003c9f8000 task.ti: ffff88003c9f8000
[    0.380141] RIP: 0010:[<ffffffff814741ef>]  [<ffffffff814741ef>] __virtscsi_set_affinity+0x4f/0x120
[    0.380141] RSP: 0000:ffff88003c9f9c08  EFLAGS: 00010256
[    0.380141] RAX: 0000000000000000 RBX: ffff88003c3a9d40 RCX: 0000000000001070
[    0.380141] RDX: 0000000000000002 RSI: 0000000000000000 RDI: 0000000000000000
[    0.380141] RBP: ffff88003c9f9c28 R08: 00000000000136c0 R09: ffff88003c801c00
[    0.380141] R10: ffffffff81475229 R11: 0000000000000008 R12: 0000000000000000
[    0.380141] R13: ffffffff81cc7ca8 R14: ffff88003cac3d40 R15: ffff88003cac37a0
[    0.380141] FS:  0000000000000000(0000) GS:ffff88003e400000(0000) knlGS:0000000000000000
[    0.380141] CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
[    0.380141] CR2: 0000000000000020 CR3: 0000000001c0e000 CR4: 00000000000006f0
[    0.380141] Stack:
[    0.380141]  ffff88003c3a9d40 0000000000000000 ffff88003cac3d80 ffff88003cac3d40
[    0.380141]  ffff88003c9f9c48 ffffffff814742e8 ffff88003c26d000 ffff88003c26d000
[    0.380141]  ffff88003c9f9c68 ffffffff81474321 ffff88003c26d000 ffff88003c3a9d40
[    0.380141] Call Trace:
[    0.380141]  [<ffffffff814742e8>] virtscsi_set_affinity+0x28/0x40
[    0.380141]  [<ffffffff81474321>] virtscsi_remove_vqs+0x21/0x50
[    0.380141]  [<ffffffff81475231>] virtscsi_init+0x91/0x240
[    0.380141]  [<ffffffff81365290>] ? vp_get+0x50/0x70
[    0.380141]  [<ffffffff81475544>] virtscsi_probe+0xf4/0x280
[    0.380141]  [<ffffffff81363ea5>] virtio_dev_probe+0xe5/0x140
[    0.380141]  [<ffffffff8144c669>] driver_probe_device+0x89/0x230
[    0.380141]  [<ffffffff8144c8ab>] __driver_attach+0x9b/0xa0
[    0.380141]  [<ffffffff8144c810>] ? driver_probe_device+0x230/0x230
[    0.380141]  [<ffffffff8144c810>] ? driver_probe_device+0x230/0x230
[    0.380141]  [<ffffffff8144ac1c>] bus_for_each_dev+0x8c/0xb0
[    0.380141]  [<ffffffff8144c499>] driver_attach+0x19/0x20
[    0.380141]  [<ffffffff8144bf28>] bus_add_driver+0x198/0x220
[    0.380141]  [<ffffffff8144ce9f>] driver_register+0x5f/0xf0
[    0.380141]  [<ffffffff81d27c91>] ? spi_transport_init+0x79/0x79
[    0.380141]  [<ffffffff8136403b>] register_virtio_driver+0x1b/0x30
[    0.380141]  [<ffffffff81d27d19>] init+0x88/0xd6
[    0.380141]  [<ffffffff81d27c18>] ? scsi_init_procfs+0x5b/0x5b
[    0.380141]  [<ffffffff81ce88a7>] do_one_initcall+0x7f/0x10a
[    0.380141]  [<ffffffff81ce8aa7>] kernel_init_freeable+0x14a/0x1de
[    0.380141]  [<ffffffff81ce8b3b>] ? kernel_init_freeable+0x1de/0x1de
[    0.380141]  [<ffffffff817dec20>] ? rest_init+0x80/0x80
[    0.380141]  [<ffffffff817dec29>] kernel_init+0x9/0xf0
[    0.380141]  [<ffffffff817e68fc>] ret_from_fork+0x7c/0xb0
[    0.380141]  [<ffffffff817dec20>] ? rest_init+0x80/0x80
[    0.380141] RIP  [<ffffffff814741ef>] __virtscsi_set_affinity+0x4f/0x120
[    0.380141]  RSP <ffff88003c9f9c08>
[    0.380141] CR2: 0000000000000020
[    0.380141] ---[ end trace 8074b70c3d5e1d73 ]---
[    0.475018] Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000009
[    0.475018]
[    0.475068] Kernel Offset: 0x0 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffff9fffffff)
[    0.475068] ---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000009

[jejb: checkpatch fixes]
Signed-off-by: NFam Zheng <famz@redhat.com>
Acked-by: NPaolo Bonzini <pbonzini@redhat.com>
Cc: stable@vger.kernel.org
Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>
      0c8482ac
    • D
      irqchip: irq-crossbar: Not allocating enough memory · 3894e9e8
      由 Dan Carpenter 提交于 
      We are allocating the size of a pointer and not the size of the data.
This will lead to memory corruption.

There isn't actually a "cb_device" struct, btw.  The code is only able
to compile because GCC knows that all pointers are the same size.

Fixes: 96ca848e ('DRIVERS: IRQCHIP: CROSSBAR: Add support for Crossbar IP')
Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
Acked-by: NSricharan R <r.sricharan@ti.com>
Cc: Grant Likely <grant.likely@linaro.org>
Cc: Rob Herring <robh+dt@kernel.org>
Link: http://lkml.kernel.org/r/20140403072134.GA14286@mwandaSigned-off-by: NThomas Gleixner <tglx@linutronix.de>
      3894e9e8
    • T
      irqchip: armanda: Sanitize set_irq_affinity() · 8cc3cfc5
      由 Thomas Gleixner 提交于 
      The set_irq_affinity() function has two issues:

1) It has no protection against selecting an offline cpu from the
   given mask.

2) It pointlessly restricts the affinity masks to have a single cpu
   set. This collides with the irq migration code of arm.

   irq affinity is set to core 3
   core 3 goes offline

   migration code sets mask to cpu_online_mask and calls the
   irq_set_affinity() callback of the irq_chip which fails due to bit
   0,1,2 set.

So instead of doing silly for_each_cpu() loops just pick any bit of
the mask which intersects with the online mask.

Get rid of fiddling with the default_irq_affinity as well.

[ Gregory: Fixed the access to the routing register ]
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
Acked-by: NGregory CLEMENT <gregory.clement@free-electrons.com>
Tested-by: NGregory CLEMENT <gregory.clement@free-electrons.com>
Cc: Jason Cooper <jason@lakedaemon.net>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Ingo Molnar <mingo@elte.hu>
Link: http://lkml.kernel.org/r/20140304203101.088889302@linutronix.deSigned-off-by: NThomas Gleixner <tglx@linutronix.de>
      8cc3cfc5