On 2017-04-20 23:53, Peter Rosin wrote:
> On 2017-04-18 23:53, Peter Rosin wrote:
>> On 2017-04-18 13:44, Greg Kroah-Hartman wrote:
>>> On Tue, Apr 18, 2017 at 12:59:50PM +0200, Peter Rosin wrote:
On 2017-04-18 10:51, Greg Kroah-Hartman wrote:
> On Thu, Apr 13, 2017 at 06:43:07PM +0200, Pe
On 04/18/2017 02:22 PM, Tom Lendacky wrote:
> Add sysfs support for SME so that user-space utilities (kdump, etc.) can
> determine if SME is active.
>
> A new directory will be created:
> /sys/kernel/mm/sme/
>
> And two entries within the new directory:
> /sys/kernel/mm/sme/active
> /sys/ke
On 04/18/2017 02:17 PM, Tom Lendacky wrote:
> @@ -55,7 +57,7 @@ static inline void copy_user_page(void *to, void *from,
> unsigned long vaddr,
> __phys_addr_symbol(__phys_reloc_hide((unsigned long)(x)))
>
> #ifndef __va
> -#define __va(x) ((void *)((unsigned
> long)(
On 4/21/2017 9:55 AM, Borislav Petkov wrote:
On Tue, Apr 18, 2017 at 04:17:35PM -0500, Tom Lendacky wrote:
Add support to the early boot code to use Secure Memory Encryption (SME).
Since the kernel has been loaded into memory in a decrypted state, support
is added to encrypt the kernel in place
On 4/18/2017 4:22 PM, Tom Lendacky wrote:
Add support to check if SME has been enabled and if memory encryption
should be activated (checking of command line option based on the
configuration of the default state). If memory encryption is to be
activated, then the encryption mask is set and the
On Tue, Apr 18, 2017 at 04:17:35PM -0500, Tom Lendacky wrote:
> Add support to the early boot code to use Secure Memory Encryption (SME).
> Since the kernel has been loaded into memory in a decrypted state, support
> is added to encrypt the kernel in place and update the early pagetables
s/support
On 2017-04-21 16:41, Philipp Zabel wrote:
> On Fri, 2017-04-21 at 16:32 +0200, Peter Rosin wrote:
>> On 2017-04-21 16:23, Philipp Zabel wrote:
>>> On Thu, 2017-04-13 at 18:43 +0200, Peter Rosin wrote:
>>> [...]
+int mux_chip_register(struct mux_chip *mux_chip)
+{
+ int i;
+ in
On 21 April 2017 at 08:12, Alex Shi wrote:
> The rt-mutex-design documents didn't gotten meaningful update from its
> first version. Even after owner's pending bit was removed in commit
> 8161239a8bcc
> ("rtmutex: Simplify PI algorithm and make highest prio task get lock")
> and priority list 'pl
On Fri, Apr 21, 2017 at 10:12:53PM +0800, Alex Shi wrote:
> diff --git a/Documentation/locking/rt-mutex-design.txt
> b/Documentation/locking/rt-mutex-design.txt
> index 8666070..11beb55 100644
> --- a/Documentation/locking/rt-mutex-design.txt
> +++ b/Documentation/locking/rt-mutex-design.txt
> @@
On 2017-04-21 16:18, Philipp Zabel wrote:
> Hi Peter,
>
> On Thu, 2017-04-13 at 18:43 +0200, Peter Rosin wrote:
> [...]
>> +int mux_control_select(struct mux_control *mux, int state)
>
> state could be unsigned int for the consumer facing API.
>
>> +{
>> +int ret;
>
> And mux_control_select
On Fri, 2017-04-21 at 16:32 +0200, Peter Rosin wrote:
> On 2017-04-21 16:23, Philipp Zabel wrote:
> > On Thu, 2017-04-13 at 18:43 +0200, Peter Rosin wrote:
> > [...]
> >> +int mux_chip_register(struct mux_chip *mux_chip)
> >> +{
> >> + int i;
> >> + int ret;
> >> +
> >> + for (i = 0; i < mux_chi
On Fri, 2017-04-21 at 16:55 +0200, Peter Rosin wrote:
> On 2017-04-21 16:41, Philipp Zabel wrote:
> > On Fri, 2017-04-21 at 16:32 +0200, Peter Rosin wrote:
> >> On 2017-04-21 16:23, Philipp Zabel wrote:
> >>> On Thu, 2017-04-13 at 18:43 +0200, Peter Rosin wrote:
> >>> [...]
> +int mux_chip_reg
On 2017-04-21 16:23, Philipp Zabel wrote:
> On Thu, 2017-04-13 at 18:43 +0200, Peter Rosin wrote:
> [...]
>> +int mux_chip_register(struct mux_chip *mux_chip)
>> +{
>> +int i;
>> +int ret;
>> +
>> +for (i = 0; i < mux_chip->controllers; ++i) {
>> +struct mux_control *mux = &
On Thu, 2017-04-13 at 18:43 +0200, Peter Rosin wrote:
[...]
> +int mux_chip_register(struct mux_chip *mux_chip)
> +{
> + int i;
> + int ret;
> +
> + for (i = 0; i < mux_chip->controllers; ++i) {
> + struct mux_control *mux = &mux_chip->mux[i];
> +
> + if (mux->id
Em Fri, 21 Apr 2017 08:37:45 +0200
Markus Heiser escreveu:
> Am 21.04.2017 um 01:21 schrieb Mauro Carvalho Chehab
> :
>
> > - I'm not a python programmer ;-) I just took Markus "generic" kernel-cmd
> > code, hardcoding there a call to the script.
> >
> > With (a lot of) time, I would likely
Hi Peter,
On Thu, 2017-04-13 at 18:43 +0200, Peter Rosin wrote:
[...]
> +int mux_control_select(struct mux_control *mux, int state)
state could be unsigned int for the consumer facing API.
> +{
> + int ret;
And mux_control_select should check that (0 <= state < mux->states).
regards
Philip
The rtmutex remove a pending owner bit in in rt_mutex::owner, in
commit 8161239a8bcc ("rtmutex: Simplify PI algorithm and make highest prio task
get lock")
But the document was changed accordingly. Updating it to a meaningful
state.
BTW, as 'Steven Rostedt' mentioned:
There is still technically a
The rt-mutex-design documents didn't gotten meaningful update from its
first version. Even after owner's pending bit was removed in commit 8161239a8bcc
("rtmutex: Simplify PI algorithm and make highest prio task get lock")
and priority list 'plist' changed to rbtree. So the documents are far
late o
From: Tejun Heo
Currently, writes "cgroup.procs" and "cgroup.tasks" files are all
handled by __cgroup_procs_write() on both v1 and v2. This patch
reoragnizes the write path so that there are common helper functions
that different write paths use.
While this somewhat increases LOC, the different
From: Tejun Heo
cgroup v2 is in the process of growing thread granularity support.
Once thread mode is enabled, the root cgroup of the subtree serves as
the proc_cgrp to which the processes of the subtree conceptually
belong and domain-level resource consumptions not tied to any specific
task are
From: Tejun Heo
css_task_iter currently always walks all tasks. With the scheduled
cgroup v2 thread support, the iterator would need to handle multiple
types of iteration. As a preparation, add @flags to
css_task_iter_start() and implement CSS_TASK_ITER_PROCS. If the flag
is not specified, it
From: Tejun Heo
This patch implements cgroup v2 thread support. The goal of the
thread mode is supporting hierarchical accounting and control at
thread granularity while staying inside the resource domain model
which allows coordination across different resource controllers and
handling of anony
From: Tejun Heo
cgroup v2 is in the process of growing thread granularity support.
Once thread mode is enabled, the root cgroup of the subtree serves as
the proc_cgrp to which the processes of the subtree conceptually
belong and domain-level resource consumptions not tied to any specific
task are
The debug cgroup currently resides within cgroup-v1.c and is enabled
only for v1 cgroup. To enable the debug cgroup also for v2, it
makes sense to put the code into its own file as it will no longer
be v1 specific. The only change in this patch is the expansion of
cgroup_task_count() within the deb
The cgroup_procs_write_start() took a reference to the task structure
which was not properly released within cgroup_procs_write() and so
on. So a put_task_struct() call is added to cgroup_procs_write_finish()
to match the get_task_struct() in cgroup_procs_write_start() to fix
this reference countin
Besides supporting cgroup v2 and thread mode, the following changes
are also made:
1) current_* cgroup files now resides only at the root as we don't
need duplicated files of the same function all over the cgroup
hierarchy.
2) The cgroup_css_links_read() function is modified to report
The reference count in the css_set data structure was used as a
proxy of the number of tasks attached to that css_set. However, that
count is actually not an accurate measure especially with thread mode
support. So a new variable task_count is added to the css_set to keep
track of the actual task c
From: Tejun Heo
Make the following changes in preparation for the cpu controller
interface implementation for the unified hierarchy. This patch
doesn't cause any functional differences.
* s/cpu_stats_show()/cpu_cfs_stats_show()/
* s/cpu_files/cpu_legacy_files/
* Separate out cpuacct_stats_rea
Internal processes are allowed in a thread root of the cgroup v2
default hierarchy. For those resource domain controllers that don't
want to deal with resource competition between internal processes and
child cgroups, there is now the option of specifying the sep_res_domain
flag in their cgroup_sub
The current thread mode semantics aren't sufficient to fully support
threaded controllers like cpu. The main problem is that when thread
mode is enabled at root (mainly for performance reason), all the
non-threaded controllers cannot be supported at all.
To alleviate this problem, the roles of thr
Make cpu and cpuacct cgroup controllers usable within a threaded cgroup.
Signed-off-by: Waiman Long
---
kernel/sched/core.c| 1 +
kernel/sched/cpuacct.c | 1 +
2 files changed, 2 insertions(+)
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 78dfcaa..9d8beda 100644
--- a/kernel/
From: Tejun Heo
While the cpu controller doesn't have any functional problems, there
are a couple interface issues which can be addressed in the v2
interface.
* cpuacct being a separate controller. This separation is artificial
and rather pointless as demonstrated by most use cases co-mountin
This patchset incorporates the following 2 patchsets from Tejun Heo:
1) cgroup v2 thread mode patchset (5 patches)
https://lkml.org/lkml/2017/2/2/592
2) CPU Controller on Control Group v2 (2 patches)
https://lkml.org/lkml/2016/8/5/368
Additional patches are then layered on top to implem
docs: Fix a couple typos
This commit gets rid of some minor errors in Documentation/:
* cputopology.txt: drawes -> drawers
* debugging-via-ohci1394.txt: remove an unnecessary line break
* static-keys: statemnts -> statements
* zorro.txt: busses -> buses
Signed-off-by: Stan Drozd
---
Documentati
docs: Fix a spelling error in vfio-mediated-device.txt
This commit fixes a repeated "the" in vfio-mediated-device.txt and reflows the
paragraph.
Signed-off-by: Stan Drozd
---
Documentation/vfio-mediated-device.txt | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/Documen
docs: Fix a spelling error in ioctl-number.txt
This commit fixes a misspelled header name in the ioctl numbers list
Signed-off-by: Stan Drozd
---
Documentation/ioctl/ioctl-number.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/ioctl/ioctl-number.txt
b/Docu
On 21/04/2017 12:05, Alexander Graf wrote:
>
>
> On 21.04.17 12:02, Paolo Bonzini wrote:
>>
>>
>> On 12/04/2017 18:29, Michael S. Tsirkin wrote:
>>> I don't really agree we do not need the PV flag. mwait on kvm is
>>> different from mwait on bare metal in that you are heavily penalized by
>>> s
On 21.04.17 12:02, Paolo Bonzini wrote:
On 12/04/2017 18:29, Michael S. Tsirkin wrote:
I don't really agree we do not need the PV flag. mwait on kvm is
different from mwait on bare metal in that you are heavily penalized by
scheduler for polling unless you configure the host just so.
HLT let
On 12/04/2017 18:29, Michael S. Tsirkin wrote:
> I don't really agree we do not need the PV flag. mwait on kvm is
> different from mwait on bare metal in that you are heavily penalized by
> scheduler for polling unless you configure the host just so.
> HLT lets you give up the host CPU if you kno
On 21/04/17 03:26, Li Qiang wrote:
@Daniel
2017-04-20 23:28 GMT+08:00 Daniel Thompson mailto:daniel.thomp...@linaro.org>>:
On 19/04/17 02:58, Li Qiang wrote:
CONFIG_STRICT_KERNEL_RWX is no longer selectable on most
architectures.
Update this info to thedocumentatio
40 matches
Mail list logo
