Skip to content

K
Kernel

openeuler / Kernel
1 年多 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 21 8月, 2021 1 次提交
    • T
      dm ima: update dm documentation for ima measurement support · 17bfa968
      由 Tushar Sugandhi 提交于 
      The ima documentation for measuring DM targets (dm-ima.rst) is
missing the attribute information for the targets - 'cache', 'integrity',
'multipath', and 'snapshot'.  It is also missing the grammar for
various DM events and targets, which can help the attestation servers
to determine what data to expect for a given DM device.  Further,
the documentation needs to be updated to incorporate code changes
made to DM ima events and targets as part of this patch series.  For
instance, prefixing the event names with "dm_", adding the DM version to
events, prefixing the table hashes in the ima log with the
hash algorithm etc.  There are warnings reported by 'make htmldocs' on
dm-ima.rst, which need to be fixed.  And lastly, the expected behavior
needs to be documented when the configuration CONFIG_IMA_DISABLE_HTABLE
is disabled.

Update the documentation to add examples for 'cache', 'integrity',
'multipath', and 'snapshot' targets.  Add the grammar for
various DM events and targets in Backus Naur form,
so that the attestation servers can interpret and act on the ima
measurements for DM target.  Fix htmldocs warnings in dm-ima.rst.  Update
the documentation to be consistent with the code changes that are part of
this patch series.
Reported-by: NStephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: NTushar Sugandhi <tusharsu@linux.microsoft.com>
Signed-off-by: NMike Snitzer <snitzer@redhat.com>
      17bfa968
  3. 13 8月, 2021 1 次提交
    • W
      cgroup/cpuset: Enable memory migration for cpuset v2 · ee9707e8
      由 Waiman Long 提交于 
      When a user changes cpuset.cpus, each task in a v2 cpuset will be moved
to one of the new cpus if it is not there already. For memory, however,
they won't be migrated to the new nodes when cpuset.mems changes. This is
an inconsistency in behavior.

In cpuset v1, there is a memory_migrate control file to enable such
behavior by setting the CS_MEMORY_MIGRATE flag. Make it the default
for cpuset v2 so that we have a consistent set of behavior for both
cpus and memory.

There is certainly a cost to make memory migration the default, but it
is a one time cost that shouldn't really matter as long as cpuset.mems
isn't changed frequenty.  Update the cgroup-v2.rst file to document the
new behavior and recommend against changing cpuset.mems frequently.

Since there won't be any concurrent access to the newly allocated cpuset
structure in cpuset_css_alloc(), we can use the cheaper non-atomic
__set_bit() instead of the more expensive atomic set_bit().
Signed-off-by: NWaiman Long <longman@redhat.com>
Acked-by: NJohannes Weiner <hannes@cmpxchg.org>
Signed-off-by: NTejun Heo <tj@kernel.org>
      ee9707e8
  5. 12 8月, 2021 1 次提交
    • P
      x86/reboot: Document how to override DMI platform quirks · 12febc18
      由 Paul Gortmaker 提交于 
      commit 5955633e ("x86/reboot: Skip DMI checks if reboot set by user")
made it so that it's not required to recompile the kernel in order to
bypass broken reboot quirks compiled into an image:

 * This variable is used privately to keep track of whether or not
 * reboot_type is still set to its default value (i.e., reboot= hasn't
 * been set on the command line).  This is needed so that we can
 * suppress DMI scanning for reboot quirks.  Without it, it's
 * impossible to override a faulty reboot quirk without recompiling.

However, at the time it was not eally documented outside the source code,
and so this information isn't really available to the average user out
there.

The change is a little white lie and invented "reboot=default" since it is
easy to remember, and documents well.  The truth is that any random string
that is *not* a currently accepted string will work.

Since that doesn't document well for non-coders, and since it's unknown
what the future additions might be, lay claim on "default" since that is
exactly what it achieves.
Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
Link: https://lore.kernel.org/r/20210530162447.996461-3-paul.gortmaker@windriver.com
      12febc18
  7. 11 8月, 2021 2 次提交
  9. 28 7月, 2021 1 次提交
  11. 01 7月, 2021 7 次提交
  13. 30 6月, 2021 6 次提交
  15. 29 6月, 2021 1 次提交
  17. 26 6月, 2021 2 次提交
  19. 22 6月, 2021 4 次提交
    • P
      clocksource: Provide kernel module to test clocksource watchdog · 1253b9b8
      由 Paul E. McKenney 提交于 
      When the clocksource watchdog marks a clock as unstable, this might
be due to that clock being unstable or it might be due to delays that
happen to occur between the reads of the two clocks.  It would be good
to have a way of testing the clocksource watchdog's ability to
distinguish between these two causes of clock skew and instability.

Therefore, provide a new clocksource-wdtest module selected by a new
TEST_CLOCKSOURCE_WATCHDOG Kconfig option.  This module has a single module
parameter named "holdoff" that provides the number of seconds of delay
before testing should start, which defaults to zero when built as a module
and to 10 seconds when built directly into the kernel.  Very large systems
that boot slowly may need to increase the value of this module parameter.

This module uses hand-crafted clocksource structures to do its testing,
thus avoiding messing up timing for the rest of the kernel and for user
applications.  This module first verifies that the ->uncertainty_margin
field of the clocksource structures are set sanely.  It then tests the
delay-detection capability of the clocksource watchdog, increasing the
number of consecutive delays injected, first provoking console messages
complaining about the delays and finally forcing a clock-skew event.
Unexpected test results cause at least one WARN_ON_ONCE() console splat.
If there are no splats, the test has passed.  Finally, it fuzzes the
value returned from a clocksource to test the clocksource watchdog's
ability to detect time skew.

This module checks the state of its clocksource after each test, and
uses WARN_ON_ONCE() to emit a console splat if there are any failures.
This should enable all types of test frameworks to detect any such
failures.

This facility is intended for diagnostic use only, and should be avoided
on production systems.
Reported-by: NChris Mason <clm@fb.com>
Suggested-by: NThomas Gleixner <tglx@linutronix.de>
Signed-off-by: NPaul E. McKenney <paulmck@kernel.org>
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
Tested-by: NFeng Tang <feng.tang@intel.com>
Link: https://lore.kernel.org/r/20210527190124.440372-5-paulmck@kernel.org
      1253b9b8
    • P
      clocksource: Limit number of CPUs checked for clock synchronization · fa218f1c
      由 Paul E. McKenney 提交于 
      Currently, if skew is detected on a clock marked CLOCK_SOURCE_VERIFY_PERCPU,
that clock is checked on all CPUs.  This is thorough, but might not be
what you want on a system with a few tens of CPUs, let alone a few hundred
of them.

Therefore, by default check only up to eight randomly chosen CPUs.  Also
provide a new clocksource.verify_n_cpus kernel boot parameter.  A value of
-1 says to check all of the CPUs, and a non-negative value says to randomly
select that number of CPUs, without concern about selecting the same CPU
multiple times.  However, make use of a cpumask so that a given CPU will be
checked at most once.

Suggested-by: Thomas Gleixner <tglx@linutronix.de> # For verify_n_cpus=1.
Signed-off-by: NPaul E. McKenney <paulmck@kernel.org>
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
Acked-by: NFeng Tang <feng.tang@intel.com>
Link: https://lore.kernel.org/r/20210527190124.440372-3-paulmck@kernel.org
      fa218f1c
    • P
      clocksource: Retry clock read if long delays detected · db3a34e1
      由 Paul E. McKenney 提交于 
      When the clocksource watchdog marks a clock as unstable, this might be due
to that clock being unstable or it might be due to delays that happen to
occur between the reads of the two clocks.  Yes, interrupts are disabled
across those two reads, but there are no shortage of things that can delay
interrupts-disabled regions of code ranging from SMI handlers to vCPU
preemption.  It would be good to have some indication as to why the clock
was marked unstable.

Therefore, re-read the watchdog clock on either side of the read from the
clock under test.  If the watchdog clock shows an excessive time delta
between its pair of reads, the reads are retried.

The maximum number of retries is specified by a new kernel boot parameter
clocksource.max_cswd_read_retries, which defaults to three, that is, up to
four reads, one initial and up to three retries.  If more than one retry
was required, a message is printed on the console (the occasional single
retry is expected behavior, especially in guest OSes).  If the maximum
number of retries is exceeded, the clock under test will be marked
unstable.  However, the probability of this happening due to various sorts
of delays is quite small.  In addition, the reason (clock-read delays) for
the unstable marking will be apparent.
Reported-by: NChris Mason <clm@fb.com>
Signed-off-by: NPaul E. McKenney <paulmck@kernel.org>
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
Acked-by: NFeng Tang <feng.tang@intel.com>
Link: https://lore.kernel.org/r/20210527190124.440372-1-paulmck@kernel.org
      db3a34e1
    • B
      block: Introduce the ioprio rq-qos policy · 556910e3
      由 Bart Van Assche 提交于 
      Introduce an rq-qos policy that assigns an I/O priority to requests based
on blk-cgroup configuration settings. This policy has the following
advantages over the ioprio_set() system call:
- This policy is cgroup based so it has all the advantages of cgroups.
- While ioprio_set() does not affect page cache writeback I/O, this rq-qos
  controller affects page cache writeback I/O for filesystems that support
  assiociating a cgroup with writeback I/O. See also
  Documentation/admin-guide/cgroup-v2.rst.

Cc: Damien Le Moal <damien.lemoal@wdc.com>
Cc: Hannes Reinecke <hare@suse.de>
Cc: Christoph Hellwig <hch@lst.de>
Cc: Ming Lei <ming.lei@redhat.com>
Cc: Johannes Thumshirn <johannes.thumshirn@wdc.com>
Cc: Himanshu Madhani <himanshu.madhani@oracle.com>
Signed-off-by: NBart Van Assche <bvanassche@acm.org>
Link: https://lore.kernel.org/r/20210618004456.7280-5-bvanassche@acm.orgSigned-off-by: NJens Axboe <axboe@kernel.dk>
      556910e3
  21. 18 6月, 2021 4 次提交
  23. 17 6月, 2021 7 次提交
  25. 16 6月, 2021 2 次提交
  27. 15 6月, 2021 1 次提交