Skip to content

K
kernel_linux

OpenHarmony / kernel_linux
上一次同步 大约 4 年

通知 14
Star 8
Fork 2
K
kernel_linux
切换分支/标签
  1. 08 2月, 2013 9 次提交
    • D
      Merge branch 'fbcon-locking-fixes' of ssh://people.freedesktop.org/~airlied/linux into drm-next · 6dc1c49d
      由 Dave Airlie 提交于 
      This pulls in most of Linus tree up to -rc6, this fixes the worst lockdep
reported issues and re-enables fbcon lockdep.

(not the fbcon maintainer)
* 'fbcon-locking-fixes' of ssh://people.freedesktop.org/~airlied/linux: (529 commits)
  Revert "Revert "console: implement lockdep support for console_lock""
  fbcon: fix locking harder
  fb: Yet another band-aid for fixing lockdep mess
  fb: rework locking to fix lock ordering on takeover
      6dc1c49d
    • D
      Revert "Revert "console: implement lockdep support for console_lock"" · 5845b81b
      由 Dave Airlie 提交于 
      This reverts commit ff0d05bf.

Now that we have all the locking fixes in place, we can revert the
revert. This re-enables lockdep tracking for the console lock,
daee7797.
Signed-off-by: NDave Airlie <airlied@redhat.com>
      5845b81b
    • D
      fbcon: fix locking harder · 054430e7
      由 Dave Airlie 提交于 
      Okay so Alan's patch handled the case where there was no registered fbcon,
however the other path entered in set_con2fb_map pit.

In there we called fbcon_takeover, but we also took the console lock in a couple
of places. So push the console lock out to the callers of set_con2fb_map,

this means fbmem and switcheroo needed to take the lock around the fb notifier
entry points that lead to this.

This should fix the efifb regression seen by Maarten.
Tested-by: NMaarten Lankhorst <maarten.lankhorst@canonical.com>
Tested-by: NLu Hua <huax.lu@intel.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>
      054430e7
    • T
      fb: Yet another band-aid for fixing lockdep mess · e93a9a86
      由 Takashi Iwai 提交于 
      I've still got lockdep warnings even after Alan's patch, and it seems that
yet more band aids are required to paper over similar paths for
unbind_con_driver() and unregister_con_driver().  After this hack, lockdep
warnings are finally gone.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>
Cc: Alan Cox <alan@linux.intel.com>
Cc: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
Cc: Jiri Kosina <jkosina@suse.cz>
Cc: stable <stable@vger.kernel.org>
Tested-by: NSedat Dilek <sedat.dilek@gmail.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NDave Airlie <airlied@redhat.com>
      e93a9a86
    • A
      fb: rework locking to fix lock ordering on takeover · 50e244cc
      由 Alan Cox 提交于 
      Adjust the console layer to allow a take over call where the caller
already holds the locks.  Make the fb layer lock in order.

This is partly a band aid, the fb layer is terminally confused about the
locking rules it uses for its notifiers it seems.

[akpm@linux-foundation.org: remove stray non-ascii char, tidy comment]
[akpm@linux-foundation.org: export do_take_over_console()]
[airlied: cleanup another non-ascii char]
Signed-off-by: NAlan Cox <alan@linux.intel.com>
Cc: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
Cc: Stephen Rothwell <sfr@canb.auug.org.au>
Cc: Jiri Kosina <jkosina@suse.cz>
Cc: stable <stable@vger.kernel.org>
Tested-by: NSedat Dilek <sedat.dilek@gmail.com>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NDave Airlie <airlied@redhat.com>
      50e244cc
    • B
      x86/intel/cacheinfo: Shut up annoying warning · 84b603ab
      由 Borislav Petkov 提交于 
      I've been getting the following warning when doing randbuilds
since forever. Now it finally pissed me off just the perfect
amount so that I can fix it.

  arch/x86/kernel/cpu/intel_cacheinfo.c:489:27: warning: ‘cache_disable_0’ defined but not used [-Wunused-variable]
  arch/x86/kernel/cpu/intel_cacheinfo.c:491:27: warning: ‘cache_disable_1’ defined but not used [-Wunused-variable] arch/x86/kernel/cpu/intel_cacheinfo.c:524:27: warning: ‘subcaches’ defined but not used [-Wunused-variable]

It happens because in randconfigs where CONFIG_SYSFS is not set,
the whole sysfs-interface to L3 cache index disabling is
remaining unused and gcc correctly warns about it. Make it
optional, depending on CONFIG_SYSFS too, as is the case with
other sysfs-related machinery in this file.
Signed-off-by: NBorislav Petkov <bp@suse.de>
Cc: Andreas Herrmann <andreas.herrmann3@amd.com>
Link: http://lkml.kernel.org/r/1359969195-27362-1-git-send-email-bp@alien8.deSigned-off-by: NIngo Molnar <mingo@kernel.org>
      84b603ab
    • H
      x86, doc: Boot protocol 2.12 is in 3.8 · 521dfda9
      由 H. Peter Anvin 提交于 
      The boot protocol 2.12 changes were pulled for 3.8, so update the
documentation accordingly.
Signed-off-by: NH. Peter Anvin <hpa@linux.intel.com>
      521dfda9
    • J
      x86-64: Replace left over sti/cli in ia32 audit exit code · 313751fa
      由 Jan Beulich 提交于 
      For some reason they didn't get replaced so far by their
paravirt equivalents, resulting in code to be run with
interrupts disabled that doesn't expect so (causing, in the
observed case, a BUG_ON() to trigger) when syscall auditing is
enabled.

David (Cc-ed) came up with an identical fix, so likely this can
be taken to count as an ack from him.
Reported-by: NPeter Moody <pmoody@google.com>
Signed-off-by: NJan Beulich <jbeulich@suse.com>
Cc: David Vrabel <david.vrabel@citrix.com>
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Link: http://lkml.kernel.org/r/5108E01902000078000BA9C5@nat28.tlf.novell.comSigned-off-by: NIngo Molnar <mingo@kernel.org>
Cc: stable@vger.kernel.org
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: David Vrabel <david.vrabel@citrix.com>
Tested-by: NPeter Moody <pmoody@google.com>
      313751fa
    • D
      Merge tag 'drm-intel-next-2013-02-01' of... · cd17ef41
      由 Dave Airlie 提交于 
      Merge tag 'drm-intel-next-2013-02-01' of git://people.freedesktop.org/~danvet/drm-intel into drm-next

Daniel writes:
"Probably the last feature pull for 3.9, there's some fixes outstanding
thought that I'd like to sneak in. And maybe 3.8 takes a bit longer ...
Anyway, highlights of this pull:
- Kill the horrible IS_DISPLAYREG hack to handle the mmio offset movements
  on vlv, big thanks to Ville.
- Dynamic power well support for Haswell, shaves away a bit when only
  using the eDP port on pipe A (Paulo). Plus unclaimed register fixes
  uncovered by this.
- Clarifications of the gpu hang/reset state transitions, hopefully fixing
  a few spurious -EIO deaths in userspace.
- Haswell ELD fixes.
- Some more (pp)gtt cleanups from Ben.
- A few smaller things all over.

Plus all the stuff from the previous rather small pull request:
- Broadcast RBG improvements and reduced color range fixes from Ville.
- Ben is on a "kill legacy gtt code for good" spree, first pile of patches
  included.
- No-relocs and bo lut improvements for faster execbuf from Chris.
- Some refactorings from Imre."

* tag 'drm-intel-next-2013-02-01' of git://people.freedesktop.org/~danvet/drm-intel: (101 commits)
  GPU/i915: Fix acpi_bus_get_device() check in drivers/gpu/drm/i915/intel_opregion.c
  drm/i915: Set the SR01 "screen off" bit in i915_redisable_vga() too
  drm/i915: Kill IS_DISPLAYREG()
  drm/i915: Introduce i915_vgacntrl_reg()
  drm/i915: gen6_gmch_remove can be static
  drm/i915: dynamic Haswell display power well support
  drm/i915: check the power down well on assert_pipe()
  drm/i915: don't send DP "idle" pattern before "normal" on HSW PORT_A
  drm/i915: don't run hsw power well code on !hsw
  drm/i915: kill cargo-culted locking from power well code
  drm/i915: Only run idle processing from i915_gem_retire_requests_worker
  drm/i915: Fix CAGF for HSW
  drm/i915: Reclaim GTT space for failed PPGTT
  drm/i915: remove intel_gtt structure
  drm/i915: Add probe and remove to the gtt ops
  drm/i915: extract hw ppgtt setup/cleanup code
  drm/i915: pte_encode is gen6+
  drm/i915: vfuncs for ppgtt
  drm/i915: vfuncs for gtt_clear_range/insert_entries
  drm/i915: Error state should print /sys/kernel/debug
  ...
      cd17ef41
  3. 05 2月, 2013 4 次提交
  5. 04 2月, 2013 3 次提交
    • L
      Merge branch 'merge' of git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc · 6edacf05
      由 Linus Torvalds 提交于 
      Pull powerpc update from Benjamin Herrenschmidt:
 "Just so that you don't get too bored on your Island here's a patch for
  3.8 fixing a nasty bug that affects the new 64T support that was
  merged in 3.7.  Please apply whenever you have a chance (and an
  internet connection!)"

* 'merge' of git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc:
  powerpc/mm: Fix hash computation function
      6edacf05
    • L
      Merge branch 'drm-fixes' of git://people.freedesktop.org/~airlied/linux · f19637e7
      由 Linus Torvalds 提交于 
      Pull radeon fixes from Dave Airlie:
 "I got these late last week, the main chunks of these fix a rendering
  regression since 3.7, and the settle ones all fix the issue where we
  don't wait long enough for the memory controller to settle after
  turning it off which causes bad memory reads, they all fix real users
  bugs, and most of them are destined for stable.

  Can't remember if you had net connection on that island :-)"

I don't know if the "two tin-cans and a string" thing here on "that
island" can really be considered internet, but I guess I can pull
things.  Barely.

* 'drm-fixes' of git://people.freedesktop.org/~airlied/linux:
  drm/radeon: switch back to the CP ring for VM PT updates
  drm/radeon: prevent crash in the ring space allocation
  drm/radeon: Calling object_unrefer() when creating fb failure
  drm/radeon/r5xx-r7xx: wait for the MC to settle after MC blackout
  drm/radeon/evergreen+: wait for the MC to settle after MC blackout
  drm/radeon: protect against div by 0 in backend setup
  drm/radeon: fix backend map setup on 1 RB sumo boards
  drm/radeon: add quirk for RV100 board
  drm/radeon: add WAIT_UNTIL to the non-VM safe regs list for cayman/TN
  drm/radeon: fix MC blackout on evergreen+
      f19637e7
    • A
      powerpc/mm: Fix hash computation function · eda8eebd
      由 Aneesh Kumar K.V 提交于 
      The ASM version of hash computation function was truncating the upper bit.
Make the ASM version similar to hpt_hash function. Remove masking vsid bits.
Without this patch, we observed hang during bootup due to not satisfying page
fault request correctly. The fault handler used wrong hash values to update
the HPTE. Hence we kept looping with page fault.

hash_page(ea=000001003e260008, access=203, trap=300 ip=3fff91787134 dsisr 42000000
The computed value of hash 000000000f22f390
update: avpnv=4003e46054003e00, hash=000000000722f390, f=80000006, psize: 2 ...

BenH: The over-masking has been there for ever but only hurts with the
new 64T support introduced in 3.7
Reported-by: NMike Qiu <qiudayu@linux.vnet.ibm.com>
Signed-off-by: NAneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
Tested-by: NMike Qiu <qiudayu@linux.vnet.ibm.com>
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
CC: <stable@vger.kernel.org> [v3.7]
      eda8eebd
  7. 03 2月, 2013 1 次提交
  9. 02 2月, 2013 1 次提交
    • L
      Merge git://git.kernel.org/pub/scm/linux/kernel/git/nab/target-pending · 8b31849a
      由 Linus Torvalds 提交于 
      Pull scsi target fixes from Nicholas Bellinger:
 "Here's the current set of v3.8-rc fixes in the target-pending.git
  queue.  Apologies in advance for these missing the -rc6 release, and
  having to be destined for -rc7 code.

  The majority of these patches are regression bugfixes specific to
  v3.8-rc code changes, namely the zero-length CDB handling breakage
  after the sense_reason_t conversion, and preventing configfs port
  linking for unconfigured devices after the recent struct
  se_subsystem_dev removal.  These is also one (the divide by zero bug
  for unconfigured devices) that is CC'ed to stable."

* git://git.kernel.org/pub/scm/linux/kernel/git/nab/target-pending:
  target: Fix divide by zero bug in fabric_max_sectors for unconfigured devices
  target: Fix regression allowing unconfigured devices to fabric port link
  tcm_vhost: fix pr_err on early kick
  target: Fix zero-length READ_CAPACITY_16 regression
  target: Fix zero-length MODE_SENSE regression
  target: Fix zero-length INQUIRY additional sense code regression
      8b31849a
  11. 01 2月, 2013 16 次提交
  13. 31 1月, 2013 6 次提交
    • A
      MIPS: Function tracer: Fix broken function tracing · 58b69401
      由 Al Cooper 提交于 
      Function tracing is currently broken for all 32 bit MIPS platforms.
When tracing is enabled, the kernel immediately hangs on boot.
This is a result of commit b732d439
that changes the kernel/trace/Kconfig file so that is no longer
forces FRAME_POINTER when FUNCTION_TRACING is enabled.

MIPS frame pointers are generally considered to be useless because
they cannot be used to unwind the stack. Unfortunately the MIPS
function tracing code has bugs that are masked by the use of frame
pointers. This commit fixes the bugs so that MIPS frame pointers
don't need to be enabled.

The bugs are a result of the odd calling sequence used to call the trace
routine. This calling sequence is inserted into every traceable function
when the tracing CONFIG option is enabled. This sequence is generated
for 32bit MIPS platforms by the compiler via the "-pg" flag.

Part of the sequence is "addiu sp,sp,-8" in the delay slot after every
call to the trace routine "_mcount" (some legacy thing where 2 arguments
used to be pushed on the stack). The _mcount routine is expected to
adjust the sp by +8 before returning.  So when not disabled, the original
jalr and addiu will be there, so _mcount has to adjust sp.

The problem is that when tracing is disabled for a function, the
"jalr _mcount" instruction is replaced with a nop, but the
"addiu sp,sp,-8" is still executed and the stack pointer is left
trashed. When frame pointers are enabled the problem is masked
because any access to the stack is done through the frame
pointer and the stack pointer is restored from the frame pointer when
the function returns.

This patch writes two nops starting at the address of the "jalr _mcount"
instruction whenever tracing is disabled. This means that the
"addiu sp,sp.-8" will be converted to a nop along with the "jalr".  When
disabled, there will be two nops.

This is SMP safe because the first time this happens is during
ftrace_init() which is before any other processor has been started.
Subsequent calls to enable/disable tracing when other CPUs ARE running
will still be safe because the enable will only change the first nop
to a "jalr" and the disable, while writing 2 nops, will only be changing
the "jalr". This patch also stops using stop_machine() to call the
tracer enable/disable routines and calls them directly because the
routines are SMP safe.

When the kernel first boots we have to be able to handle the gcc
generated jalr, addui sequence until ftrace_init gets a chance to run
and change the sequence. At this point mcount just adjusts the stack
and returns. When ftrace_init runs, we convert the jalr/addui to nops.
Then whenever tracing is enabled we convert the first nop to a "jalr
mcount+8". The mcount+8 entry point skips the stack adjust.

[ralf@linux-mips.org: Folded in  Steven Rostedt's build fix.]
Signed-off-by: NAl Cooper <alcooperx@gmail.com>
Cc: rostedt@goodmis.org
Cc: ddaney.cavm@gmail.com
Cc: linux-mips@linux-mips.org
Cc: linux-kernel@vger.kernel.org
Patchwork: https://patchwork.linux-mips.org/patch/4806/
Patchwork: https://patchwork.linux-mips.org/patch/4841/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      58b69401
    • A
      dm: fix write same requests counting · fe7af2d3
      由 Alasdair G Kergon 提交于 
      When processing write same requests, fix dm to send the configured
number of WRITE SAME requests to the target rather than the number of
discards, which is not always the same.

Device-mapper WRITE SAME support was introduced by commit
23508a96 ("dm: add WRITE SAME support").
Signed-off-by: NAlasdair G Kergon <agk@redhat.com>
Acked-by: NMike Snitzer <snitzer@redhat.com>
      fe7af2d3
    • S
      mips: Move __virt_addr_valid() to a place for MIPS 64 · 196897a2
      由 Steven Rostedt 提交于 
      Commit d3ce8843 "MIPS: Fix modpost error in modules attepting to use
virt_addr_valid()" moved __virt_addr_valid() from a macro in a header
file to a function in ioremap.c. But ioremap.c is only compiled for MIPS
32, and not for MIPS 64.

When compiling for my yeeloong2, which supposedly supports hibernation,
which compiles kernel/power/snapshot.c which calls virt_addr_valid(), I
got this error:

  LD      init/built-in.o
kernel/built-in.o: In function `memory_bm_free':
snapshot.c:(.text+0x4c9c4): undefined reference to `__virt_addr_valid'
snapshot.c:(.text+0x4ca58): undefined reference to `__virt_addr_valid'
kernel/built-in.o: In function `snapshot_write_next':
(.text+0x4e44c): undefined reference to `__virt_addr_valid'
kernel/built-in.o: In function `snapshot_write_next':
(.text+0x4e890): undefined reference to `__virt_addr_valid'
make[1]: *** [vmlinux] Error 1
make: *** [sub-make] Error 2

I suspect that __virt_addr_valid() is fine for mips 64. I moved it to
mmap.c such that it gets compiled for mips 64 and 32.
Signed-off-by: NSteven Rostedt <rostedt@goodmis.org>
Cc: linux-kernel@vger.kernel.org
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/4842/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      196897a2
    • M
      dm thin: fix queue limits stacking · 0f640dca
      由 Mike Snitzer 提交于 
      thin_io_hints() is blindly copying the queue limits from the thin-pool
which can lead to incorrect limits being set.  The fix here simply
deletes the thin_io_hints() hook which leaves the existing stacking
infrastructure to set the limits correctly.

When a thin-pool uses an MD device for the data device a thin device
from the thin-pool must respect MD's constraints about disallowing a bio
from spanning multiple chunks.  Otherwise we can see problems.  If the raid0
chunksize is 1152K and thin-pool chunksize is 256K I see the following
md/raid0 error (with extra debug tracing added to thin_endio) when
mkfs.xfs is executed against the thin device:

md/raid0:md99: make_request bug: can't convert block across chunks or bigger than 1152k 6688 127
device-mapper: thin: bio sector=2080 err=-5 bi_size=130560 bi_rw=17 bi_vcnt=32 bi_idx=0

This extra DM debugging shows that the failing bio is spanning across
the first and second logical 1152K chunk (sector 2080 + 255 takes the
bio beyond the first chunk's boundary of sector 2304).  So the bio
splitting that DM is doing clearly isn't respecting the MD limits.

max_hw_sectors_kb is 127 for both the thin-pool and thin device
(queue_max_hw_sectors returns 255 so we'll excuse sysfs's lack of
precision).  So this explains why bi_size is 130560.

But the thin device's max_hw_sectors_kb should be 4 (PAGE_SIZE) given
that it doesn't have a .merge function (for bio_add_page to consult
indirectly via dm_merge_bvec) yet the thin-pool does sit above an MD
device that has a compulsory merge_bvec_fn.  This scenario is exactly
why DM must resort to sending single PAGE_SIZE bios to the underlying
layer. Some additional context for this is available in the header for
commit 8cbeb67a ("dm: avoid unsupported spanning of md stripe boundaries").

Long story short, the reason a thin device doesn't properly get
configured to have a max_hw_sectors_kb of 4 (PAGE_SIZE) is that
thin_io_hints() is blindly copying the queue limits from the thin-pool
device directly to the thin device's queue limits.

Fix this by eliminating thin_io_hints.  Doing so is safe because the
block layer's queue limits stacking already enables the upper level thin
device to inherit the thin-pool device's discard and minimum_io_size and
optimal_io_size limits that get set in pool_io_hints.  But avoiding the
queue limits copy allows the thin and thin-pool limits to be different
where it is important, namely max_hw_sectors_kb.
Reported-by: NDaniel Browning <db@kavod.com>
Signed-off-by: NMike Snitzer <snitzer@redhat.com>
Cc: stable@vger.kernel.org
Signed-off-by: NAlasdair G Kergon <agk@redhat.com>
      0f640dca
    • A
      drm/radeon/evergreen+: wait for the MC to settle after MC blackout · ed39fadd
      由 Alex Deucher 提交于 
      Some chips seem to need a little delay after blacking out
the MC before the requests actually stop.

May fix:
https://bugs.freedesktop.org/show_bug.cgi?id=56139
https://bugs.freedesktop.org/show_bug.cgi?id=57567Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
      ed39fadd
    • V
      drm/i915: Set the SR01 "screen off" bit in i915_redisable_vga() too · 209d5211
      由 Ville Syrjälä 提交于 
      From BSpec / SR01 - Clocking Mode:
"The following sequence must be used when disabling the VGA plane.
 Write SR01 to set bit 5 = 1 to disable video output.
 Wait for 100us.
 Disable the VGA plane via Bit 31 of the MMIO VGA control."

So simply call i915_disable_vga() from i915_redisable_vga().
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      209d5211