Skip to content

cloud-kernel
cloud-kernel

openanolis / cloud-kernel
接近 2 年 前同步成功

通知 170
Star 36
Fork 7
cloud-kernel
cloud-kernel
切换分支/标签
  1. 17 12月, 2017 3 次提交
    • M
      xtensa: add support for KASAN · c633544a
      由 Max Filippov 提交于 
      Cover kernel addresses above 0x90000000 by the shadow map. Enable
HAVE_ARCH_KASAN when MMU is enabled. Provide kasan_early_init that fills
shadow map with writable copies of kasan_zero_page. Call
kasan_early_init right after mmu initialization in the setup_arch.
Provide kasan_init that allocates proper shadow map pages from the
memblock and puts these pages into the shadow map for addresses from
VMALLOC area to the end of KSEG. Call kasan_init right after memblock
initialization. Don't use KASAN for the boot code, MMU and KASAN
initialization and page fault handler. Make kernel stack size 4 times
larger when KASAN is enabled to avoid stack overflows.
GCC 7.3, 8 or newer is required to build the xtensa kernel with KASAN.
Signed-off-by: NMax Filippov <jcmvbkbc@gmail.com>
      c633544a
    • M
      xtensa: move fixmap and kmap just above the KSEG · 1af1e8a3
      由 Max Filippov 提交于 
      The virtual address space between the page table and the VMALLOC region
is big enough to host KASAN shadow map and there's enough space between
the VMALLOC area and KSEG for the fixmap and kmap.
Move fixmap and kmap to the gap between VMALLOC area and KSEG, just
above the KSEG. Reorder entries in the kernel memory layout printing
code. Drop duplicate PGTABLE_START definition, use
XCHAL_PAGE_TABLE_VADDR instead.
Signed-off-by: NMax Filippov <jcmvbkbc@gmail.com>
      1af1e8a3
    • M
      xtensa: enable stack protector · 40d1a07b
      由 Max Filippov 提交于 
      The implementation is adopted from the ARM arch. GCC 7.3, 8 or newer is
required for building the xtensa kernel with SSP.
Signed-off-by: NMax Filippov <jcmvbkbc@gmail.com>
      40d1a07b
  3. 04 11月, 2017 3 次提交
  5. 03 11月, 2017 1 次提交
  7. 01 11月, 2017 2 次提交
    • P
      Update MIPS email addresses · 48c834be
      由 Paul Burton 提交于 
      MIPS will soon not be a part of Imagination Technologies, and as such
many @imgtec.com email addresses will no longer be valid. This patch
updates the addresses for those who:

 - Have 10 or more patches in mainline authored using an @imgtec.com
   email address, or any patches dated within the past year.

 - Are still with Imagination but leaving as part of the MIPS business
   unit, as determined from an internal email address list.

 - Haven't already updated their email address (ie. JamesH) or expressed
   a desire to be excluded (ie. Maciej).

 - Acked v2 or earlier of this patch, which leaves Deng-Cheng, Matt &
   myself.

New addresses are of the form firstname.lastname@mips.com, and all
verified against an internal email address list. An entry is added to
.mailmap for each person such that get_maintainer.pl will report the new
addresses rather than @imgtec.com addresses which will soon be dead.

Instances of the affected addresses throughout the tree are then
mechanically replaced with the new @mips.com address.
Signed-off-by: NPaul Burton <paul.burton@mips.com>
Cc: Deng-Cheng Zhu <dengcheng.zhu@imgtec.com>
Cc: Deng-Cheng Zhu <dengcheng.zhu@mips.com>
Acked-by: NDengcheng Zhu <dengcheng.zhu@mips.com>
Cc: Matt Redfearn <matt.redfearn@imgtec.com>
Cc: Matt Redfearn <matt.redfearn@mips.com>
Acked-by: NMatt Redfearn <matt.redfearn@mips.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: linux-kernel@vger.kernel.org
Cc: linux-mips@linux-mips.org
Cc: trivial@kernel.org
Patchwork: https://patchwork.linux-mips.org/patch/17540/Signed-off-by: NJames Hogan <jhogan@kernel.org>
      48c834be
    • R
      Revert "PM / QoS: Fix device resume latency PM QoS" · d5919dcc
      由 Rafael J. Wysocki 提交于 
      This reverts commit 0cc2b4e5 (PM / QoS: Fix device resume latency PM
QoS) as it introduced regressions on multiple systems and the fix-up
in commit 2a9a86d5 (PM / QoS: Fix default runtime_pm device resume
latency) does not address all of them.

The original problem that commit 0cc2b4e5 was attempting to fix
will be addressed later.

Fixes: 0cc2b4e5 (PM / QoS: Fix device resume latency PM QoS)
Reported-by: NGeert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      d5919dcc
  9. 24 10月, 2017 2 次提交
    • R
      PM / QoS: Fix device resume latency PM QoS · 0cc2b4e5
      由 Rafael J. Wysocki 提交于 
      The special value of 0 for device resume latency PM QoS means
"no restriction", but there are two problems with that.

First, device resume latency PM QoS requests with 0 as the
value are always put in front of requests with positive
values in the priority lists used internally by the PM QoS
framework, causing 0 to be chosen as an effective constraint
value.  However, that 0 is then interpreted as "no restriction"
effectively overriding the other requests with specific
restrictions which is incorrect.

Second, the users of device resume latency PM QoS have no
way to specify that *any* resume latency at all should be
avoided, which is an artificial limitation in general.

To address these issues, modify device resume latency PM QoS to
use S32_MAX as the "no constraint" value and 0 as the "no
latency at all" one and rework its users (the cpuidle menu
governor, the genpd QoS governor and the runtime PM framework)
to follow these changes.

Also add a special "n/a" value to the corresponding user space I/F
to allow user space to indicate that it cannot accept any resume
latencies at all for the given device.

Fixes: 85dc0b8a (PM / QoS: Make it possible to expose PM QoS latency constraints)
Link: https://bugzilla.kernel.org/show_bug.cgi?id=197323Reported-by: NReinette Chatre <reinette.chatre@intel.com>
Tested-by: NReinette Chatre <reinette.chatre@intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: NAlex Shi <alex.shi@linaro.org>
Cc: All applicable <stable@vger.kernel.org>
      0cc2b4e5
    • C
      kbuild doc: a bundle of fixes on makefiles.txt · d87e47e1
      由 Cao jin 提交于 
      It does several fixes:
1. move the displaced ld example to its reasonable place.
2. add new example for command gzip.
3. fix 2 number errors.
4. fix format of chapter 7.x, make it looks the same as other chapters.
Signed-off-by: NCao jin <caoj.fnst@cn.fujitsu.com>
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
      d87e47e1
  11. 23 10月, 2017 1 次提交
  13. 21 10月, 2017 2 次提交
  15. 20 10月, 2017 2 次提交
  17. 19 10月, 2017 5 次提交
  19. 16 10月, 2017 1 次提交
  21. 14 10月, 2017 1 次提交
  23. 13 10月, 2017 1 次提交
  25. 08 10月, 2017 1 次提交
  27. 06 10月, 2017 1 次提交
    • J
      dm raid: fix incorrect status output at the end of a "recover" process · 41dcf197
      由 Jonathan Brassow 提交于 
      There are three important fields that indicate the overall health and
status of an array: dev_health, sync_ratio, and sync_action.  They tell
us the condition of the devices in the array, and the degree to which
the array is synchronized.

This commit fixes a condition that is reported incorrectly.  When a member
of the array is being rebuilt or a new device is added, the "recover"
process is used to synchronize it with the rest of the array.  When the
process is complete, but the sync thread hasn't yet been reaped, it is
possible for the state of MD to be:
 mddev->recovery = [ MD_RECOVERY_RUNNING MD_RECOVERY_RECOVER MD_RECOVERY_DONE ]
 curr_resync_completed = <max dev size> (but not MaxSector)
 and all rdevs to be In_sync.
This causes the 'array_in_sync' output parameter that is passed to
rs_get_progress() to be computed incorrectly and reported as 'false' --
or not in-sync.  This in turn causes the dev_health status characters to
be reported as all 'a', rather than the proper 'A'.

This can cause erroneous output for several seconds at a time when tools
will want to be checking the condition due to events that are raised at
the end of a sync process.  Fix this by properly calculating the
'array_in_sync' return parameter in rs_get_progress().

Also, remove an unnecessary intermediate 'recovery_cp' variable in
rs_get_progress().
Signed-off-by: NJonathan Brassow <jbrassow@redhat.com>
Signed-off-by: NMike Snitzer <snitzer@redhat.com>
      41dcf197
  29. 05 10月, 2017 3 次提交
  31. 04 10月, 2017 2 次提交
  33. 02 10月, 2017 1 次提交
  35. 28 9月, 2017 1 次提交
  37. 26 9月, 2017 1 次提交
  39. 24 9月, 2017 2 次提交
  41. 22 9月, 2017 1 次提交
  43. 20 9月, 2017 3 次提交
    • M
      ipv6: fix net.ipv6.conf.all interface DAD handlers · 35e015e1
      由 Matteo Croce 提交于 
      Currently, writing into
net.ipv6.conf.all.{accept_dad,use_optimistic,optimistic_dad} has no effect.
Fix handling of these flags by:

- using the maximum of global and per-interface values for the
  accept_dad flag. That is, if at least one of the two values is
  non-zero, enable DAD on the interface. If at least one value is
  set to 2, enable DAD and disable IPv6 operation on the interface if
  MAC-based link-local address was found

- using the logical OR of global and per-interface values for the
  optimistic_dad flag. If at least one of them is set to one, optimistic
  duplicate address detection (RFC 4429) is enabled on the interface

- using the logical OR of global and per-interface values for the
  use_optimistic flag. If at least one of them is set to one,
  optimistic addresses won't be marked as deprecated during source address
  selection on the interface.

While at it, as we're modifying the prototype for ipv6_use_optimistic_addr(),
drop inline, and let the compiler decide.

Fixes: 7fd2561e ("net: ipv6: Add a sysctl to make optimistic addresses useful candidates")
Signed-off-by: NMatteo Croce <mcroce@redhat.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      35e015e1
    • R
      PM: docs: Drop an excess character from devices.rst · b247c211
      由 Rafael J. Wysocki 提交于 
      Drop an excess "`" from Documentation/driver-api/pm/devices.rst.

Fixes: 2728b2d2 (PM / core / docs: Convert sleep states API document to reST)
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      b247c211
    • A
      dt-bindings: fix vendor prefix for Abracon · a6899e90
      由 Alexandre Belloni 提交于 
      Commit 446810f2 ("of: add vendor prefix for Abracon Corporation")
claimed that "abcn" was used as the vendor prefix while in fact "abracon"
was used in the subsequent commits. It is also the only prefix used in the
tree.
Signed-off-by: NAlexandre Belloni <alexandre.belloni@free-electrons.com>
[robh: fix alphabetical order]
Signed-off-by: NRob Herring <robh@kernel.org>
      a6899e90