Re: [PATCH v5 2/3] Documentation/filesystems: Fixed typo

[Robert Foss]

On 2016-09-07 07:22 PM, Kees Cook wrote:

On Mon, Sep 5, 2016 at 1:14 PM,   wrote:

From: Robert Foss 

Fixed a -> an typo.

Signed-off-by: Robert Foss 


Acked-by: Kees Cook 

This could be taken directly into the docs tree, I think -- no reason
to make it depend on the rest of the series.


Agreed. Would you like a separate submission for that?


Rob.
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Source and Make files under Documentation directory

[Shuah Khan]

Hi Jon,

I noticed there are several source files and Makefiles under the
Documentation directory. Some of them look very much like tests.

If they are indeed tests, maybe it is worth while to move them to
selftests? If you think this topic needs larger audience, I could
send in a KS topic for discussion. If we can identify useful tests,
I can volunteer to get them into selftests

I haven't looked at all of them. I did take a quick look at

timers/hpet_example.c and
filesystems/dnotify_test.c

These two looked like tests to me. The full list below:

accounting/getdelays.c   prctl/disable-tsc-on-off-stress-test.c
auxdisplay/cfag12864b-example.c  prctl/disable-tsc-test.c
blackfin/gptimers-example.c  ptp/testptp.c
filesystems/dnotify_test.c   timers/hpet_example.c
ia64/aliasing-test.c usb/usbdevfs-drop-permissions.c
laptops/dslm.c   vDSO/parse_vdso.c
pcmcia/crc32hash.c   vDSO/vdso_standalone_test_x86.c
prctl/disable-tsc-ctxt-sw-stress-test.c  vDSO/vdso_test.c


accounting/Makefile   ia64/Makefile  prctl/Makefile
auxdisplay/Makefile   laptops/Makefile   ptp/Makefile
blackfin/Makefile media/Makefile timers/Makefile
cdrom/Makefilemic/Makefile   vDSO/Makefile
DocBook/Makefile  misc-devices/Makefile  watchdog/Makefile
EDID/Makefile networking/Makefile
filesystems/Makefile  pcmcia/Makefile

thanks,
-- Shuah

-- 
Shuah Khan
Sr. Linux Kernel Developer
Open Source Innovation Group
Samsung Research America (Silicon Valley)
shua...@osg.samsung.com
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v5 2/3] Documentation/filesystems: Fixed typo

[Kees Cook]

On Mon, Sep 5, 2016 at 1:14 PM,   wrote:
> From: Robert Foss 
>
> Fixed a -> an typo.
>
> Signed-off-by: Robert Foss 

Acked-by: Kees Cook 

This could be taken directly into the docs tree, I think -- no reason
to make it depend on the rest of the series.

-Kees

> ---
>  Documentation/filesystems/proc.txt | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/Documentation/filesystems/proc.txt 
> b/Documentation/filesystems/proc.txt
> index 68080ad..fcc1ac0 100644
> --- a/Documentation/filesystems/proc.txt
> +++ b/Documentation/filesystems/proc.txt
> @@ -145,7 +145,7 @@ Table 1-1: Process specific entries in /proc
> symbol the task is blocked in - or "0" if not blocked.
>   pagemap   Page table
>   stack Report full stack trace, enable via CONFIG_STACKTRACE
> - smaps a extension based on maps, showing the memory consumption of
> + smaps an extension based on maps, showing the memory consumption of
> each mapping and flags associated with it
>   numa_maps an extension based on maps, showing the memory locality and
> binding policy as well as mem usage (in pages) of each 
> mapping.
> --
> 2.7.4
>



-- 
Kees Cook
Nexus Security
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 2/3] hwmon: xgene: Add hwmon driver

[Guenter Roeck]

On Wed, Sep 07, 2016 at 11:41:44PM +0200, Arnd Bergmann wrote:
> On Thursday, July 21, 2016 1:55:56 PM CEST Hoan Tran wrote:
> > +   ctx->comm_base_addr = cppc_ss->base_address;
> > +   if (ctx->comm_base_addr) {
> > +   ctx->pcc_comm_addr =
> > +   acpi_os_ioremap(ctx->comm_base_addr,
> > +   cppc_ss->length);
> > 
> 
> This causes the arm64 allmodconfig build to fail now, according to
> kernelci:
> 
>   1  ERROR: "memblock_is_memory" [drivers/hwmon/xgene-hwmon.ko] undefined!
> 
> Should this perhaps call ioremap() or memremap() instead?
> 
Hmmm ... almost sounds to me like blaming the messenger. e7cd190385d1 ("arm64:
mark reserved memblock regions explicitly in iomem") starts using a function
in acpi_os_ioremap() which is not exported. On top of that, memblock_is_memory()
is declared as __init_memblock, which makes me really uncomfortable.
If acpi_os_ioremap() must not be used by modules, and possibly only during
early (?) initialization, maybe its declaration should state those limitations ?

Thanks,
Guenter
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 2/3] hwmon: xgene: Add hwmon driver

[Guenter Roeck]

On Wed, Sep 07, 2016 at 11:41:44PM +0200, Arnd Bergmann wrote:
> On Thursday, July 21, 2016 1:55:56 PM CEST Hoan Tran wrote:
> > +   ctx->comm_base_addr = cppc_ss->base_address;
> > +   if (ctx->comm_base_addr) {
> > +   ctx->pcc_comm_addr =
> > +   acpi_os_ioremap(ctx->comm_base_addr,
> > +   cppc_ss->length);
> > 
> 
> This causes the arm64 allmodconfig build to fail now, according to
> kernelci:
> 
>   1  ERROR: "memblock_is_memory" [drivers/hwmon/xgene-hwmon.ko] undefined!
> 
How do you even get there ? arm64:allmodconfig fails for me in -next with

drivers/pwm/pwm-berlin.c: In function ‘berlin_pwm_suspend’:
drivers/pwm/pwm-berlin.c:245:35: error: ‘struct berlin_pwm_chip’ has no member 
named ‘chips’

Guenter
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 2/3] hwmon: xgene: Add hwmon driver

[Arnd Bergmann]

On Thursday, July 21, 2016 1:55:56 PM CEST Hoan Tran wrote:
> +   ctx->comm_base_addr = cppc_ss->base_address;
> +   if (ctx->comm_base_addr) {
> +   ctx->pcc_comm_addr =
> +   acpi_os_ioremap(ctx->comm_base_addr,
> +   cppc_ss->length);
> 

This causes the arm64 allmodconfig build to fail now, according to
kernelci:

  1  ERROR: "memblock_is_memory" [drivers/hwmon/xgene-hwmon.ko] undefined!

Should this perhaps call ioremap() or memremap() instead?

Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Ping: [PATCH v15 00/13] support "task_isolation" mode

[Francis Giraldeau]

On 2016-09-07 05:11 PM, Francis Giraldeau wrote:
> The syscall test fails on x86:
> $ sudo ./isolation
> [...]
> test_syscall: FAIL (0x100)
> test_syscall (SIGUSR1): FAIL (0x100)
>
> I wanted to debug this problem with gdb and a KVM virtual machine. However, 
> the TSC clock source is detected as non reliable, even with the boot 
> parameter tsc=reliable, and therefore prctl(PR_SET_TASK_ISOLATION, 
> PR_TASK_ISOLATION_ENABLE) always returns EAGAIN. Is there a trick to run task 
> isolation in a VM (at least for debugging purposes)?

OK, got it. The guest kernel must be compiled with CONFIG_KVM_GUEST, and then 
with virsh edit, set the clock configuration of the VM (under ):

 

  

Of course, the jitter is horrible, but at least it is possible to debug with 
GDB.

Cheers,

Francis
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Ping: [PATCH v15 00/13] support "task_isolation" mode

[Francis Giraldeau]

On 2016-08-29 12:27 PM, Chris Metcalf wrote:
> On 8/16/2016 5:19 PM, Chris Metcalf wrote:
>> Here is a respin of the task-isolation patch set.
>
> No concerns have been raised yet with the v15 version of the patch series
> in the two weeks since I posted it, and I think I have addressed all
> previously-raised concerns (or perhaps people have just given up arguing
> with me).

There is a cycle with header include in the v15 patch set on x86_64 that cause 
a compilation error. You will find the patch (and other fixes) in the following 
branch:

https://github.com/giraldeau/linux/commits/dataplane-x86-fix-inc

In the test file, it is indicated to change timer-tick.c to disable the 1Hz 
tick, is there a reason why the change is not in the patch set? I added this 
trivial change in the branch dataplane-x86-fix-inc above.

The syscall test fails on x86:

$ sudo ./isolation
[...]
test_syscall: FAIL (0x100)
test_syscall (SIGUSR1): FAIL (0x100)

I wanted to debug this problem with gdb and a KVM virtual machine. However, the 
TSC clock source is detected as non reliable, even with the boot parameter 
tsc=reliable, and therefore prctl(PR_SET_TASK_ISOLATION, 
PR_TASK_ISOLATION_ENABLE) always returns EAGAIN. Is there a trick to run task 
isolation in a VM (at least for debugging purposes)?

BTW, this was causing the test to enter an infinite loop. If the clock source 
is not reliable, maybe a different error code should be returned, because this 
situation not transient. In the mean time, I added a check for 100 max retries 
in the test (prctl_safe()).

When running only the test_jitter(), the isolation mode is lost:

[ 6741.566048] isolation/9515: task_isolation mode lost due to irq_work

With ftrace (events/workqueue/workqueue_execute_start), I get a bit more info:

 kworker/1:1-676   [001]   6610.097128: workqueue_execute_start: work 
struct 8801a784ca20: function dbs_work_handler

The governor was ondemand, so I tried to set the frequency scaling governor to 
performance, but that does not solve the issue. Is there a way to suppress this 
irq_work? Should we run the isolated task with high real-time priority, such 
that it never get preempted?

Thanks!

Francis
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC PATCH v2 07/20] x86: Provide general kernel support for memory encryption

[Borislav Petkov]

On Wed, Sep 07, 2016 at 09:30:54AM -0500, Tom Lendacky wrote:
> _PAGE_ENC is #defined as sme_me_mask and sme_me_mask has already been
> set (or not set) at this point - so it will be the mask if SME is
> active or 0 if SME is not active.

Yeah, I remember :-)

> sme_early_init() is merely propagating the mask to other structures.
> Since early_pmd_flags is mainly used in this file (one line in
> head_64.S is the other place) I felt it best to modify it here. But it
> can always be moved if you feel that is best.

Hmm, so would it work then if you stick it in early_pmd_flags'
definition like you do with the other masks? I.e.,

pmdval_t early_pmd_flags = __PAGE_KERNEL_LARGE | _PAGE_ENC & ~(_PAGE_GLOBAL | 
_PAGE_NX);

-- 
Regards/Gruss,
Boris.

ECO tip #101: Trim your mails when you reply.
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCHv12 1/3] rdmacg: Added rdma cgroup controller

[Matan Barak]

On 07/09/2016 10:55, Parav Pandit wrote:

Hi Matan,

On Thu, Sep 1, 2016 at 2:14 PM, Christoph Hellwig  wrote:

On Thu, Sep 01, 2016 at 10:25:40AM +0300, Matan Barak wrote:

Well, if I recall, the reason doing so last time was in order to allow
flexible updating of ib_core independently, which is obviously not a good
reason (to say the least).

Since the new ABI will probably define new object types (all recent
proposals go this way), the current approach could lead to either trying to
map new objects to existing cgroup resource types, which could lead to some
weird non 1:1 mapping, or having a split definitions - such that each
driver will declare its objects both in the cgroups mechanism and in its
driver dispatch table.



Even worse than that, drivers could simply ignore the cgroups support while
implementing their own resource types and get a very broken containers
support.

If drivers are broken due to ignorance of not-calling cgroup APIs,
that should be ok.
That particular driver should fix it.
If the resource creation using uverbs is using well defined rdma level
resource, uverbs level will make sure to honor cgroup limits without
involving hw drivers anyway.



All recent proposals of the new ABI schema deals with extending the 
flexibility of the current schema by letting drivers define their 
specific types, actions, attributes, etc. Even more than that, the 
dispatching starts from the driver and it chooses if it wants to use the 
common RDMA core layer or have it's own wise implementation instead.

Some drivers might even prefer not to implement the current verbs types.
These decisions were made in the OFVWG meetings.

Anyway, maybe we should consider using a more higher-level logic objects 
that could fit multiple drivers requirements.



RDMA Verb level resource is charged/uncharged by RDMA core.
RDMA HW level resource is charged/uncharged by RDMA HW driver using
well defined API and resource by cgroup core.
This scheme ensures that there is 1:1 mapping.



Sounds reasonable, but what about drivers which ignore the common code 
and implement it in their own way? What about drivers which don't 
support the standard RDMA types at all?
I guess we should find a balance between something abstract and common 
enough that will ease administrator configuration but be specific enough 
for the various models we have (or will have) in the RDMA stack.



I don't think current definition of resource type is carved out on stone.
They can be extended as we forward.
As many of us agree that, they should be well defined and it should be
agreed by cgroup and rdma community.



Of course, but since the ABI and cgroups model are somehow related, they 
should be dealt with together and approved by Doug who participated in 
some of the OFVWG meetings.



For example, today we have RDMA_VERB_xxx resources.
New well defined RDMA HW resources can be defined in rdma_cgroup.h
file as RDMA_HW_xx in same enum table.



So a driver will change the cgroups file for every new type it adds?
Will we just have a super set enum of all crazy types vendors added?



Sorry guys, but arbitrary extensibility for something not finished is the
worst idea ever.  We have two options here:

 a) delay cgroups support until the grand rewrite is done
 b) add it now and deal with the consequences later


Can we do (b) now and differ adding any HW resources to cgroup until
they are clearly called out.
Architecture and APIs are already in place to support this.



Since this affect the user, it's better to think how it fits our 
"optional standard"/"vendor types" model first. Maybe we could force all 
standard types even if the driver we use doesn't support any of them.



That being said, adding random non-Verbs hardwasre to the RDMA core is
the second worst idea ever.


We can differ adding HW resource to core and cgroup until they are
clearly defined.
In that case current architecture still holds good.



Clearly we should differ adding the actual code until a driver could 
declare such objects, but we need to decide how to expose the standard 
optional RDMA types (basically, the types you've added) and how future 
driver specific types fit in.



Guess I need to catch up with the
discussion and start using the flame thrower.


Matan,
Can you please point us to the new RFC/ABI email thread which
describes the design, partitioning of code between core vs hw drivers
etc.



One proposal is [1]. There's another one from Sean which aims for 
similar targets regards the driver specific types.


[1] https://www.spinics.net/lists/linux-rdma/msg38997.html

Matan
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC PATCH v2 01/20] x86: Documentation for AMD Secure Memory Encryption (SME)

[Borislav Petkov]

On Wed, Sep 07, 2016 at 09:02:38AM -0500, Tom Lendacky wrote:
> Ugh..  I thought I caught all of these.  Obviously not.  I'll go through
> all the patches on this.

What you could do is run all patches through scripts/checkpatch.pl
and fix those issues which make sense to you. What I'm saying is, you
shouldn't take its output to the letter but some of the stuff it catches
are valid.

Thanks.

-- 
Regards/Gruss,
Boris.

ECO tip #101: Trim your mails when you reply.
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCHv12 1/3] rdmacg: Added rdma cgroup controller

[Parav Pandit]

Hi Leon,

>> Signed-off-by: Parav Pandit 
>> +static struct rdmacg_resource_pool *
>> +get_cg_rpool_locked(struct rdma_cgroup *cg, struct rdmacg_device *device)
>> +{
>> + struct rdmacg_resource_pool *rpool;
>> +
>> + rpool = find_cg_rpool_locked(cg, device);
>> + if (rpool)
>> + return rpool;
>> +
>> + rpool = kzalloc(sizeof(*rpool), GFP_KERNEL);
>> + if (!rpool)
>> + return ERR_PTR(-ENOMEM);
>> +
>> + rpool->device = device;
>> + set_all_resource_max_limit(rpool);
>> +
>> + INIT_LIST_HEAD(>cg_node);
>> + INIT_LIST_HEAD(>dev_node);
>> + list_add_tail(>cg_node, >rpools);
>> + list_add_tail(>dev_node, >rpools);
>> + return rpool;
>> +}
>
> <...>
>
>> + for (p = cg; p; p = parent_rdmacg(p)) {
>> + rpool = get_cg_rpool_locked(p, device);
>> + if (IS_ERR_OR_NULL(rpool)) {
>
> get_cg_rpool_locked always returns !NULL (error, or pointer)

Can this change go as incremental change after this patch, since this
patch is close to completion?
Or I need to revise v13?

>
>> + ret = PTR_ERR(rpool);
>> + goto err;
>
> I didn't review the whole series yet.

Did you get a chance to review the series?
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCHv12 1/3] rdmacg: Added rdma cgroup controller

[Parav Pandit]

On Wed, Sep 7, 2016 at 2:21 PM, Matan Barak  wrote:
> On 07/09/2016 10:55, Parav Pandit wrote:
>>
>> Hi Matan,
>>
>> On Thu, Sep 1, 2016 at 2:14 PM, Christoph Hellwig  wrote:
>>>
>>> On Thu, Sep 01, 2016 at 10:25:40AM +0300, Matan Barak wrote:

 Well, if I recall, the reason doing so last time was in order to allow
 flexible updating of ib_core independently, which is obviously not a
 good
 reason (to say the least).

 Since the new ABI will probably define new object types (all recent
 proposals go this way), the current approach could lead to either trying
 to
 map new objects to existing cgroup resource types, which could lead to
 some
 weird non 1:1 mapping, or having a split definitions - such that each
 driver will declare its objects both in the cgroups mechanism and in its
 driver dispatch table.
>>
>>
 Even worse than that, drivers could simply ignore the cgroups support
 while
 implementing their own resource types and get a very broken containers
 support.
>>
>> If drivers are broken due to ignorance of not-calling cgroup APIs,
>> that should be ok.
>> That particular driver should fix it.
>> If the resource creation using uverbs is using well defined rdma level
>> resource, uverbs level will make sure to honor cgroup limits without
>> involving hw drivers anyway.
>>
>
> All recent proposals of the new ABI schema deals with extending the
> flexibility of the current schema by letting drivers define their specific
> types, actions, attributes, etc. Even more than that, the dispatching starts
> from the driver and it chooses if it wants to use the common RDMA core layer
> or have it's own wise implementation instead.
> Some drivers might even prefer not to implement the current verbs types.
> These decisions were made in the OFVWG meetings.

o.k. If some drivers doesn't implement current verbs type, there is no
point in controlling it either.
In such case application space library won't even invoke resource
allocation/free for unsupported resources.
For resources (type in your word) which are not defined in cgroup, but
exist in hw driver, cannot be controlled by cgroup.
As you highlighted in your [1], "driver's specific attributes could
someday become core's standard attributes", we should be able to add
new resource type to existing rdma cgroup.

>
> Anyway, maybe we should consider using a more higher-level logic objects
> that could fit multiple drivers requirements.
I do not have any other objects other than QP, MR etc in mind currently.
I can think of a RDMA specific socket that encompass one PD, AH,
couple of MRs, and QP.
But we don't have such resource abstraction and its data transport
APIs in place.
There is rsocket, various versions of MPI, libfabric etc in place.
So I am not sure which high level objects to defined at this point.
If you have such objects nailed down, we should be able to add them in
incremental development.

>
>> RDMA Verb level resource is charged/uncharged by RDMA core.
>> RDMA HW level resource is charged/uncharged by RDMA HW driver using
>> well defined API and resource by cgroup core.
>> This scheme ensures that there is 1:1 mapping.
>>
>
> Sounds reasonable, but what about drivers which ignore the common code and
> implement it in their own way?
Shouldn't Doug ask them to use cgroup infrastructure instead of
implementing resource charging/uncharing in their own way.
It still unlikely or difficult for drivers to group processes them
selves like cgroup to implement things in their own way.
I agree, they can completely ignore RDMA verbs resources and implement
their own HW resources.

As you pointed below, we need to find balance between which hw
resource to be defined and which not.
For example, newly added XRQ object, which could be a pure buffer_tag
with receive queue for other vendor. I am not sure how to abstract
them into single object.



> What about drivers which don't support the
> standard RDMA types at all?
> I guess we should find a balance between something abstract and common
> enough that will ease administrator configuration but be specific enough for
> the various models we have (or will have) in the RDMA stack.
>
>> I don't think current definition of resource type is carved out on stone.
>> They can be extended as we forward.
>> As many of us agree that, they should be well defined and it should be
>> agreed by cgroup and rdma community.
>>
>
> Of course, but since the ABI and cgroups model are somehow related, they
> should be dealt with together and approved by Doug who participated in some
> of the OFVWG meetings.
Sure.
>
>> For example, today we have RDMA_VERB_xxx resources.
>> New well defined RDMA HW resources can be defined in rdma_cgroup.h
>> file as RDMA_HW_xx in same enum table.
>>
>
> So a driver will change the cgroups file for every new type it adds?
Well, we wanted to avoid that such churn in cgroup file, thats why v11
was 

Re: [RFC PATCH v2 07/20] x86: Provide general kernel support for memory encryption

[Tom Lendacky]

On 09/06/2016 04:31 AM, Borislav Petkov wrote:
> On Mon, Aug 22, 2016 at 05:36:46PM -0500, Tom Lendacky wrote:
>> Adding general kernel support for memory encryption includes:
>> - Modify and create some page table macros to include the Secure Memory
>>   Encryption (SME) memory encryption mask
>> - Update kernel boot support to call an SME routine that checks for and
>>   sets the SME capability (the SME routine will grow later and for now
>>   is just a stub routine)
>> - Update kernel boot support to call an SME routine that encrypts the
>>   kernel (the SME routine will grow later and for now is just a stub
>>   routine)
>> - Provide an SME initialization routine to update the protection map with
>>   the memory encryption mask so that it is used by default
>>
>> Signed-off-by: Tom Lendacky 
> 
> ...
> 
>> diff --git a/arch/x86/kernel/head64.c b/arch/x86/kernel/head64.c
>> index 54a2372..88c7bae 100644
>> --- a/arch/x86/kernel/head64.c
>> +++ b/arch/x86/kernel/head64.c
>> @@ -28,6 +28,7 @@
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>>  
>>  /*
>>   * Manage page tables very early on.
>> @@ -42,7 +43,7 @@ static void __init reset_early_page_tables(void)
>>  {
>>  memset(early_level4_pgt, 0, sizeof(pgd_t)*(PTRS_PER_PGD-1));
>>  next_early_pgt = 0;
>> -write_cr3(__pa_nodebug(early_level4_pgt));
>> +write_cr3(__sme_pa_nodebug(early_level4_pgt));
>>  }
>>  
>>  /* Create a new PMD entry */
>> @@ -54,7 +55,7 @@ int __init early_make_pgtable(unsigned long address)
>>  pmdval_t pmd, *pmd_p;
>>  
>>  /* Invalid address or early pgt is done ?  */
>> -if (physaddr >= MAXMEM || read_cr3() != __pa_nodebug(early_level4_pgt))
>> +if (physaddr >= MAXMEM || read_cr3() != 
>> __sme_pa_nodebug(early_level4_pgt))
>>  return -1;
>>  
>>  again:
>> @@ -157,6 +158,11 @@ asmlinkage __visible void __init 
>> x86_64_start_kernel(char * real_mode_data)
>>  
>>  clear_page(init_level4_pgt);
>>  
>> +/* Update the early_pmd_flags with the memory encryption mask */
>> +early_pmd_flags |= _PAGE_ENC;
>> +
>> +sme_early_init();
>> +
> 
> So maybe this comes later but you're setting _PAGE_ENC unconditionally
> *before* sme_early_init().
> 
> I think you should set it in sme_early_init() and iff SME is enabled.

_PAGE_ENC is #defined as sme_me_mask and sme_me_mask has already been
set (or not set) at this point - so it will be the mask if SME is
active or 0 if SME is not active.  sme_early_init() is merely
propagating the mask to other structures.  Since early_pmd_flags is
mainly used in this file (one line in head_64.S is the other place) I
felt it best to modify it here.  But it can always be moved if you feel
that is best.

Thanks,
Tom

> 
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC PATCH v2 05/20] x86: Add the Secure Memory Encryption cpu feature

[Tom Lendacky]

On 09/02/2016 09:09 AM, Borislav Petkov wrote:
> On Mon, Aug 22, 2016 at 05:36:22PM -0500, Tom Lendacky wrote:
>> Update the cpu features to include identifying and reporting on the
>> Secure Memory Encryption feature.
>>
>> Signed-off-by: Tom Lendacky 
>> ---
>>  arch/x86/include/asm/cpufeature.h|7 +--
>>  arch/x86/include/asm/cpufeatures.h   |5 -
>>  arch/x86/include/asm/disabled-features.h |3 ++-
>>  arch/x86/include/asm/required-features.h |3 ++-
>>  arch/x86/kernel/cpu/scattered.c  |1 +
>>  5 files changed, 14 insertions(+), 5 deletions(-)
> 
> ...
> 
>> diff --git a/arch/x86/kernel/cpu/scattered.c 
>> b/arch/x86/kernel/cpu/scattered.c
>> index 8cb57df..d86d9a5 100644
>> --- a/arch/x86/kernel/cpu/scattered.c
>> +++ b/arch/x86/kernel/cpu/scattered.c
>> @@ -37,6 +37,7 @@ void init_scattered_cpuid_features(struct cpuinfo_x86 *c)
>>  { X86_FEATURE_HW_PSTATE,CR_EDX, 7, 0x8007, 0 },
>>  { X86_FEATURE_CPB,  CR_EDX, 9, 0x8007, 0 },
>>  { X86_FEATURE_PROC_FEEDBACK,CR_EDX,11, 0x8007, 0 },
>> +{ X86_FEATURE_SME,  CR_EAX, 0, 0x801f, 0 },
> 
> If this is in scattered CPUID features, it doesn't need any of the
> (snipped) changes above - you solely need to reuse one of the free
> defines, i.e., something like this:

Ok, that's much easier. I'll do that.

Thanks,
Tom

> 
> ---
> --- a/arch/x86/include/asm/cpufeatures.h  2016-09-02 15:49:08.853374323 
> +0200
> +++ b/arch/x86/include/asm/cpufeatures.h  2016-09-02 15:52:34.477365610 
> +0200
> @@ -100,7 +100,7 @@
>  #define X86_FEATURE_XTOPOLOGY( 3*32+22) /* cpu topology enum 
> extensions */
>  #define X86_FEATURE_TSC_RELIABLE ( 3*32+23) /* TSC is known to be reliable */
>  #define X86_FEATURE_NONSTOP_TSC  ( 3*32+24) /* TSC does not stop in C 
> states */
> -/* free, was #define X86_FEATURE_CLFLUSH_MONITOR ( 3*32+25) * "" clflush 
> reqd with monitor */
> +#define X86_FEATURE_SME  ( 3*32+25) /* Secure Memory Encryption 
> */
>  #define X86_FEATURE_EXTD_APICID  ( 3*32+26) /* has extended APICID (8 
> bits) */
>  #define X86_FEATURE_AMD_DCM ( 3*32+27) /* multi-node processor */
>  #define X86_FEATURE_APERFMPERF   ( 3*32+28) /* APERFMPERF */
> --- a/arch/x86/kernel/cpu/scattered.c 2016-09-02 15:48:52.753375005 +0200
> +++ b/arch/x86/kernel/cpu/scattered.c 2016-09-02 15:51:32.437368239 +0200
> @@ -37,6 +37,7 @@ void init_scattered_cpuid_features(struc
>   { X86_FEATURE_HW_PSTATE,CR_EDX, 7, 0x8007, 0 },
>   { X86_FEATURE_CPB,  CR_EDX, 9, 0x8007, 0 },
>   { X86_FEATURE_PROC_FEEDBACK,CR_EDX,11, 0x8007, 0 },
> + { X86_FEATURE_SME,  CR_EAX, 0, 0x801f, 0 },
>   { 0, 0, 0, 0, 0 }
>   };
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC PATCH v2 07/20] x86: Provide general kernel support for memory encryption

[Tom Lendacky]

On 09/05/2016 03:48 AM, Borislav Petkov wrote:
> On Mon, Aug 22, 2016 at 05:36:46PM -0500, Tom Lendacky wrote:
>> Adding general kernel support for memory encryption includes:
>> - Modify and create some page table macros to include the Secure Memory
>>   Encryption (SME) memory encryption mask
>> - Update kernel boot support to call an SME routine that checks for and
>>   sets the SME capability (the SME routine will grow later and for now
>>   is just a stub routine)
>> - Update kernel boot support to call an SME routine that encrypts the
>>   kernel (the SME routine will grow later and for now is just a stub
>>   routine)
>> - Provide an SME initialization routine to update the protection map with
>>   the memory encryption mask so that it is used by default
>>
>> Signed-off-by: Tom Lendacky 
>> ---
> 
> ...
> 
>> diff --git a/arch/x86/include/asm/pgtable_types.h 
>> b/arch/x86/include/asm/pgtable_types.h
>> index f1218f5..a01f0e1 100644
>> --- a/arch/x86/include/asm/pgtable_types.h
>> +++ b/arch/x86/include/asm/pgtable_types.h
>> @@ -3,6 +3,7 @@
>>  
>>  #include 
>>  #include 
>> +#include 
>>  
>>  #define FIRST_USER_ADDRESS  0UL
>>  
>> @@ -121,9 +122,9 @@
>>  
>>  #define _PAGE_PROTNONE  (_AT(pteval_t, 1) << _PAGE_BIT_PROTNONE)
>>  
>> -#define _PAGE_TABLE (_PAGE_PRESENT | _PAGE_RW | _PAGE_USER |\
>> +#define __PAGE_TABLE(_PAGE_PRESENT | _PAGE_RW | _PAGE_USER |
>> \
>>   _PAGE_ACCESSED | _PAGE_DIRTY)
> 
> Hmm, so this naming looks confusing and error-prone: the only difference
> is a single "_".
> 
> How about this instead:
> 
> #define _PAGE_TABLE_NO_ENC(_PAGE_PRESENT | _PAGE_RW | _PAGE_USER |
> \
>_PAGE_ACCESSED | _PAGE_DIRTY)
> 
> #define _PAGE_TABLE (_PAGE_TABLE_NO_ENC | _PAGE_ENC)
> 
> Or call it _PAGE_TABLE_BASE or whatever.
> 
> Ditto for __KERNPG_TABLE.
> 
> This way you can differentiate between the two and use the _NO_ENC one
> to define _PAGE_TABLE. And it will be absolutely clear when you use the
> _NO_ENC one, what you mean and that you don't want to have the enc mask
> in the PTE.
> 
> Should be less confusing IMO too.

Yup, makes sense.  I'll rework/rename.

Thanks,
Tom

> 
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC PATCH v2 07/20] x86: Provide general kernel support for memory encryption

[Tom Lendacky]

On 09/02/2016 01:14 PM, Borislav Petkov wrote:
> On Mon, Aug 22, 2016 at 05:36:46PM -0500, Tom Lendacky wrote:
>> Adding general kernel support for memory encryption includes:
>> - Modify and create some page table macros to include the Secure Memory
>>   Encryption (SME) memory encryption mask
>> - Update kernel boot support to call an SME routine that checks for and
>>   sets the SME capability (the SME routine will grow later and for now
>>   is just a stub routine)
>> - Update kernel boot support to call an SME routine that encrypts the
>>   kernel (the SME routine will grow later and for now is just a stub
>>   routine)
>> - Provide an SME initialization routine to update the protection map with
>>   the memory encryption mask so that it is used by default
>>
>> Signed-off-by: Tom Lendacky 
>> ---
> 
> ...
> 
>> diff --git a/arch/x86/include/asm/mem_encrypt.h 
>> b/arch/x86/include/asm/mem_encrypt.h
>> index 747fc52..9f3e762 100644
>> --- a/arch/x86/include/asm/mem_encrypt.h
>> +++ b/arch/x86/include/asm/mem_encrypt.h
>> @@ -15,12 +15,21 @@
>>  
>>  #ifndef __ASSEMBLY__
>>  
>> +#include 
>> +
>>  #ifdef CONFIG_AMD_MEM_ENCRYPT
>>  
>>  extern unsigned long sme_me_mask;
>>  
>>  u8 sme_get_me_loss(void);
>>  
>> +void __init sme_early_init(void);
>> +
>> +#define __sme_pa(x) (__pa((x)) | sme_me_mask)
>> +#define __sme_pa_nodebug(x) (__pa_nodebug((x)) | sme_me_mask)
>> +
>> +#define __sme_va(x) (__va((x) & ~sme_me_mask))
> 
> So I'm wondering: why not push the masking off of the SME mask into the
> __va() macro instead of defining a specific __sme_va() one?
> 
> I mean, do you even see cases where __va() would need to have to
> sme_mask left in the virtual address?
> 
> Because if not, you could mask it out in __va() so that all __va() users
> get the "clean" va, without the enc bits.

That's a good point, yes, it could go in __va().  I'll make that change.

> 
> Hmmm.
> 
> Btw, this patch is huuuge. It would be nice if you could split it, if
> possible...

Ok, I'll look at how to make this a bit more manageable.

Thanks,
Tom

> 
> Thanks.
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC PATCH v2 03/20] x86: Secure Memory Encryption (SME) build enablement

[Tom Lendacky]

On 09/02/2016 06:03 AM, Borislav Petkov wrote:
> On Mon, Aug 22, 2016 at 05:35:59PM -0500, Tom Lendacky wrote:
>> Provide the Kconfig support to build the SME support in the kernel.
>>
>> Signed-off-by: Tom Lendacky 
>> ---
>>  arch/x86/Kconfig |9 +
>>  1 file changed, 9 insertions(+)
>>
>> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
>> index c580d8c..131f329 100644
>> --- a/arch/x86/Kconfig
>> +++ b/arch/x86/Kconfig
>> @@ -1357,6 +1357,15 @@ config X86_DIRECT_GBPAGES
>>supports them), so don't confuse the user by printing
>>that we have them enabled.
>>  
>> +config AMD_MEM_ENCRYPT
>> +bool "Secure Memory Encryption support for AMD"
> 
>"AMD Secure Memory Encryption support"

Ok.

Thanks,
Tom

> 
>> +depends on X86_64 && CPU_SUP_AMD
>> +---help---
>> +  Say yes to enable the encryption of system memory. This requires
>> +  an AMD processor that supports Secure Memory Encryption (SME).
>> +  The encryption of system memory is disabled by default but can be
>> +  enabled with the mem_encrypt=on command line option.
>> +
>>  # Common NUMA Features
>>  config NUMA
>>  bool "Numa Memory Allocation and Scheduler Support"
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: pyc files in source dir with O=

[Geert Uytterhoeven]

Hi Jani,

On Wed, Sep 7, 2016 at 3:28 PM, Jani Nikula <jani.nik...@linux.intel.com> wrote:
> On Wed, 07 Sep 2016, Geert Uytterhoeven <ge...@linux-m68k.org> wrote:
>> When running "make htmldocs O=/path/to/somewhere", *.pyc files end up
>> in the source tree instead of in the build tree:
>>
>> $ git ls-files -o
>> Documentation/sphinx/kernel-doc.pyc
>> Documentation/sphinx/kernel_include.pyc
>> Documentation/sphinx/rstFlatTable.pyc
>> $
>>
>> This is with v4.8-rc5.
>>
>> With next-20160907, two more files appear:
>>
>> Documentation/sphinx/cdomain.pyc
>> Documentation/sphinx/load_config.pyc
>
> This should help
>
> diff --git a/Documentation/Makefile.sphinx b/Documentation/Makefile.sphinx
> index 92deea30b183..a4cba2d1aaf1 100644
> --- a/Documentation/Makefile.sphinx
> +++ b/Documentation/Makefile.sphinx
> @@ -53,6 +53,7 @@ loop_cmd = $(echo-cmd) $(cmd_$(1))
>
>  quiet_cmd_sphinx = SPHINX  $@ --> file://$(abspath $(BUILDDIR)/$3/$4);
>cmd_sphinx = $(MAKE) BUILDDIR=$(abspath $(BUILDDIR)) 
> $(build)=Documentation/media all;\
> +   PYTHONDONTWRITEBYTECODE=1 \
> BUILDDIR=$(abspath $(BUILDDIR)) SPHINX_CONF=$(abspath 
> $(srctree)/$(src)/$5/$(SPHINX_CONF)) \
> $(SPHINXBUILD) \
> -b $2 \

Thanks, that works (on next-20160907, doesn't apply to v4.8-rc5).
But IMHO it's a bit drastic. There's no way to let python create them in the
build directory instead?

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: pyc files in source dir with O=

[Jani Nikula]

On Wed, 07 Sep 2016, Geert Uytterhoeven <ge...@linux-m68k.org> wrote:
> When running "make htmldocs O=/path/to/somewhere", *.pyc files end up
> in the source tree instead of in the build tree:
>
> $ git ls-files -o
> Documentation/sphinx/kernel-doc.pyc
> Documentation/sphinx/kernel_include.pyc
> Documentation/sphinx/rstFlatTable.pyc
> $
>
> This is with v4.8-rc5.
>
> With next-20160907, two more files appear:
>
> Documentation/sphinx/cdomain.pyc
> Documentation/sphinx/load_config.pyc

This should help

diff --git a/Documentation/Makefile.sphinx b/Documentation/Makefile.sphinx
index 92deea30b183..a4cba2d1aaf1 100644
--- a/Documentation/Makefile.sphinx
+++ b/Documentation/Makefile.sphinx
@@ -53,6 +53,7 @@ loop_cmd = $(echo-cmd) $(cmd_$(1))
 
 quiet_cmd_sphinx = SPHINX  $@ --> file://$(abspath $(BUILDDIR)/$3/$4);
   cmd_sphinx = $(MAKE) BUILDDIR=$(abspath $(BUILDDIR)) 
$(build)=Documentation/media all;\
+   PYTHONDONTWRITEBYTECODE=1 \
BUILDDIR=$(abspath $(BUILDDIR)) SPHINX_CONF=$(abspath 
$(srctree)/$(src)/$5/$(SPHINX_CONF)) \
$(SPHINXBUILD) \
-b $2 \


Side note, I'm really sad the Sphinx build has grown so ugly and
complicated now. :(

BR,
Jani.


-- 
Jani Nikula, Intel Open Source Technology Center
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[next] make htmldocs fails with "too many values to unpack"

[Geert Uytterhoeven]

On next-20160907, "make htmldocs" fails:

Exception occurred:
  File "/usr/lib/python2.7/dist-packages/sphinx/environment.py", line
1530, in create_index
for type, value, tid, main in entries:
ValueError: too many values to unpack
The full traceback has been saved in /tmp/sphinx-err-GYk3bJ.log, if
you want to report the issue to the developers.
Please also report this if it was a user error, so that a better error
message can be provided next time.
A bug report can be filed in the tracker at
<https://bitbucket.org/birkenfeld/sphinx/issues/>. Thanks!

It works fine on v4.8-rc5.

Full traceback:

# Sphinx version: 1.2.2
# Python version: 2.7.6
# Docutils version: 0.11 release
# Jinja2 version: 2.7.2
# Loaded extensions:
#   kernel_include from
/linux-next/Documentation/sphinx/kernel_include.pyc
#   kernel-doc from /linux-next/Documentation/sphinx/kernel-doc.pyc
#   rstFlatTable from /linux-next/Documentation/sphinx/rstFlatTable.pyc
#   cdomain from /linux-next/Documentation/sphinx/cdomain.pyc
#   sphinx.ext.pngmath from
/usr/lib/python2.7/dist-packages/sphinx/ext/pngmath.pyc
#   sphinx.ext.oldcmarkup from
/usr/lib/python2.7/dist-packages/sphinx/ext/oldcmarkup.pyc
Traceback (most recent call last):
  File "/usr/lib/python2.7/dist-packages/sphinx/cmdline.py", line 254, in main
app.build(force_all, filenames)
  File "/usr/lib/python2.7/dist-packages/sphinx/application.py", line
212, in build
self.builder.build_update()
  File "/usr/lib/python2.7/dist-packages/sphinx/builders/__init__.py",
line 214, in build_update
'out of date' % len(to_build))
  File "/usr/lib/python2.7/dist-packages/sphinx/builders/__init__.py",
line 279, in build
self.finish()
  File "/usr/lib/python2.7/dist-packages/sphinx/builders/html.py",
line 458, in finish
self.write_genindex()
  File "/usr/lib/python2.7/dist-packages/sphinx/builders/html.py",
line 492, in write_genindex
genindex = self.env.create_index(self)
  File "/usr/lib/python2.7/dist-packages/sphinx/environment.py", line
1530, in create_index
for type, value, tid, main in entries:
ValueError: too many values to unpack

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

pyc files in source dir with O=

[Geert Uytterhoeven]

When running "make htmldocs O=/path/to/somewhere", *.pyc files end up
in the source tree instead of in the build tree:

$ git ls-files -o
Documentation/sphinx/kernel-doc.pyc
Documentation/sphinx/kernel_include.pyc
Documentation/sphinx/rstFlatTable.pyc
$

This is with v4.8-rc5.

With next-20160907, two more files appear:

Documentation/sphinx/cdomain.pyc
Documentation/sphinx/load_config.pyc

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v5 1/3] mm, proc: Implement /proc//totmaps

[Oleg Nesterov]

On 09/05, robert.f...@collabora.com wrote:
>
> @@ -2854,6 +2854,7 @@ static const struct pid_entry tgid_base_stuff[] = {
>   REG("clear_refs", S_IWUSR, proc_clear_refs_operations),
>   REG("smaps",  S_IRUGO, proc_pid_smaps_operations),
>   REG("pagemap",S_IRUSR, proc_pagemap_operations),
> + REG("totmaps",S_IRUGO, proc_totmaps_operations),

I must have missed something, but I fail to understand why this patch
is so complicated.

Just use ONE("totmaps", S_IRUGO, proc_totmaps_operations) ?

> +static int totmaps_proc_show(struct seq_file *m, void *data)
> +{
> + struct proc_maps_private *priv = m->private;
> + struct mm_struct *mm = priv->mm;
> + struct vm_area_struct *vma;
> + struct mem_size_stats mss_sum;
> +
> + memset(_sum, 0, sizeof(mss_sum));
> + down_read(>mmap_sem);
> + hold_task_mempolicy(priv);
^
why?

> + for (vma = mm->mmap; vma != priv->tail_vma; vma = vma->vm_next) {

Hmm. the usage of ->tail_vma looks just wrong. I guess the code should
work because it is NULL but still.

> + struct mem_size_stats mss;
> + struct mm_walk smaps_walk = {
> + .pmd_entry = smaps_pte_range,
> + .mm = vma->vm_mm,
> + .private = ,
> + };
> +
> + if (vma->vm_mm && !is_vm_hugetlb_page(vma)) {
> + memset(, 0, sizeof(mss));
> + walk_page_vma(vma, _walk);
> + add_smaps_sum(, _sum);
> + }
> + }

Why? I mean, why not walk_page_range() ? You do not need this for-each-vma
loop at all? At least if you change this patch to use the ONE() helper, and
everything else looks unneeded in this case.

Oleg.

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v6 2/4] drm: Add API for capturing frame CRCs

[Tomeu Vizoso]

Adds files and directories to debugfs for controlling and reading frame
CRCs, per CRTC:

dri/0/crtc-0/crc
dri/0/crtc-0/crc/control
dri/0/crtc-0/crc/data

Drivers can implement the set_crc_source callback() in drm_crtc_funcs to
start and stop generating frame CRCs and can add entries to the output
by calling drm_crtc_add_crc_entry.

v2:
- Lots of good fixes suggested by Thierry.
- Added documentation.
- Changed the debugfs layout.
- Moved to allocate the entries circular queue once when frame
  generation gets enabled for the first time.
v3:
- Use the control file just to select the source, and start and stop
  capture when the data file is opened and closed, respectively.
- Make variable the number of CRC values per entry, per source.
- Allocate entries queue each time we start capturing as now there
  isn't a fixed number of CRC values per entry.
- Store the frame counter in the data file as a 8-digit hex number.
- For sources that cannot provide useful frame numbers, place
   in the frame field.

v4:
- Build only if CONFIG_DEBUG_FS is enabled.
- Use memdup_user_nul.
- Consolidate calculation of the size of an entry in a helper.
- Add 0x prefix to hex numbers in the data file.
- Remove unnecessary snprintf and strlen usage in read callback.

v5:
- Made the crcs array in drm_crtc_crc_entry fixed-size
- Lots of other smaller improvements suggested by Emil Velikov

Signed-off-by: Tomeu Vizoso 
---

 Documentation/gpu/drm-uapi.rst|   6 +
 drivers/gpu/drm/Makefile  |   3 +-
 drivers/gpu/drm/drm_crtc.c|  29 +++-
 drivers/gpu/drm/drm_debugfs.c |  34 +++-
 drivers/gpu/drm/drm_debugfs_crc.c | 351 ++
 drivers/gpu/drm/drm_drv.c |  15 ++
 drivers/gpu/drm/drm_internal.h|  10 ++
 include/drm/drm_crtc.h|  41 +
 include/drm/drm_debugfs_crc.h |  78 +
 9 files changed, 564 insertions(+), 3 deletions(-)
 create mode 100644 drivers/gpu/drm/drm_debugfs_crc.c
 create mode 100644 include/drm/drm_debugfs_crc.h

diff --git a/Documentation/gpu/drm-uapi.rst b/Documentation/gpu/drm-uapi.rst
index 12b47c30fe2e..4d5f61b6c0f2 100644
--- a/Documentation/gpu/drm-uapi.rst
+++ b/Documentation/gpu/drm-uapi.rst
@@ -179,3 +179,9 @@ interfaces. Especially since all hardware-acceleration 
interfaces to
 userspace are driver specific for efficiency and other reasons these
 interfaces can be rather substantial. Hence every driver has its own
 chapter.
+
+Testing and validation
+==
+
+.. kernel-doc:: drivers/gpu/drm/drm_debugfs_crc.c
+   :doc: CRC ABI
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 4054c94a2301..9c99b051ce87 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -9,7 +9,7 @@ drm-y   :=  drm_auth.o drm_bufs.o drm_cache.o \
drm_scatter.o drm_pci.o \
drm_platform.o drm_sysfs.o drm_hashtab.o drm_mm.o \
drm_crtc.o drm_fourcc.o drm_modes.o drm_edid.o \
-   drm_info.o drm_debugfs.o drm_encoder_slave.o \
+   drm_info.o drm_encoder_slave.o \
drm_trace_points.o drm_global.o drm_prime.o \
drm_rect.o drm_vma_manager.o drm_flip_work.o \
drm_modeset_lock.o drm_atomic.o drm_bridge.o \
@@ -21,6 +21,7 @@ drm-$(CONFIG_PCI) += ati_pcigart.o
 drm-$(CONFIG_DRM_PANEL) += drm_panel.o
 drm-$(CONFIG_OF) += drm_of.o
 drm-$(CONFIG_AGP) += drm_agpsupport.o
+drm-$(CONFIG_DEBUG_FS) += drm_debugfs.o drm_debugfs_crc.o
 
 drm_kms_helper-y := drm_crtc_helper.o drm_dp_helper.o drm_probe_helper.o \
drm_plane_helper.o drm_dp_mst_topology.o drm_atomic_helper.o \
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 7f2510524f09..17cc6891dfbb 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -40,7 +40,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 
 #include "drm_crtc_internal.h"
 #include "drm_internal.h"
@@ -309,6 +309,25 @@ static void drm_crtc_unregister_all(struct drm_device *dev)
}
 }
 
+static int drm_crtc_crc_init(struct drm_crtc *crtc)
+{
+#ifdef CONFIG_DEBUG_FS
+   spin_lock_init(>crc.lock);
+   init_waitqueue_head(>crc.wq);
+   crtc->crc.source = kstrdup("auto", GFP_KERNEL);
+   if (!crtc->crc.source)
+   return -ENOMEM;
+#endif
+   return 0;
+}
+
+static void drm_crtc_crc_fini(struct drm_crtc *crtc)
+{
+#ifdef CONFIG_DEBUG_FS
+   kfree(crtc->crc.source);
+#endif
+}
+
 /**
  * drm_crtc_init_with_planes - Initialise a new CRTC object with
  *specified primary and cursor planes.
@@ -374,6 +393,12 @@ int drm_crtc_init_with_planes(struct drm_device *dev, 
struct drm_crtc *crtc,
if (cursor)
cursor->possible_crtcs = 1 << drm_crtc_index(crtc);
 
+   ret = drm_crtc_crc_init(crtc);
+   if (ret) {
+   

[PATCH v6 0/4] New debugfs API for capturing CRC of frames

[Tomeu Vizoso]

Hi,

this series basically takes the facility for continuously capturing CRCs
of frames from the i915 driver and into the DRM core.

The idea is that test suites such as IGT use this information to check
that frames that are exected to be identical, also have identical CRC
values.

Other drivers for hardware that can provide frame CRCs (including eDP
panels that support self-refresh) can easily implement the new callback
and provide userspace with the CRC values.

Thanks,

Tomeu

Tomeu Vizoso (4):
  drm/i915/debugfs: Move out pipe CRC code
  drm: Add API for capturing frame CRCs
  drm/i915: Use new CRC debugfs API
  drm/i915: Put "cooked" vlank counters in frame CRC lines

 Documentation/gpu/drm-uapi.rst|6 +
 drivers/gpu/drm/Makefile  |3 +-
 drivers/gpu/drm/drm_crtc.c|   29 +-
 drivers/gpu/drm/drm_debugfs.c |   34 +-
 drivers/gpu/drm/drm_debugfs_crc.c |  351 
 drivers/gpu/drm/drm_drv.c |   15 +
 drivers/gpu/drm/drm_internal.h|   10 +
 drivers/gpu/drm/i915/Makefile |2 +-
 drivers/gpu/drm/i915/i915_debugfs.c   |  886 +---
 drivers/gpu/drm/i915/i915_drv.c   |2 +-
 drivers/gpu/drm/i915/i915_drv.h   |3 +-
 drivers/gpu/drm/i915/i915_irq.c   |   83 ++-
 drivers/gpu/drm/i915/intel_display.c  |1 +
 drivers/gpu/drm/i915/intel_drv.h  |7 +
 drivers/gpu/drm/i915/intel_pipe_crc.c | 1014 +
 include/drm/drm_crtc.h|   41 ++
 include/drm/drm_debugfs_crc.h |   78 +++
 17 files changed, 1651 insertions(+), 914 deletions(-)
 create mode 100644 drivers/gpu/drm/drm_debugfs_crc.c
 create mode 100644 drivers/gpu/drm/i915/intel_pipe_crc.c
 create mode 100644 include/drm/drm_debugfs_crc.h

-- 
2.7.4

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/3] doc-rst:c-domain: fix sphinx version incompatibility

[Markus Heiser]

Am 06.09.2016 um 17:55 schrieb Mauro Carvalho Chehab :
...
>> Sphinx has some more of these tuples with fixed length (remember
>> conf.py, the latex_documents settings) where IMHO hash/value pairs
>> (dicts) are more suitable.
> 
> Well, the LaTeX stuff at conf.py seems to have a new field on version
> 1.4.x. At least, our config has:
> 
> # (source start file, name, description, authors, manual section).
> 
> but 1.4.x docs mentions another tuple: toctree_only.

Hmm, as far as I can see, toctree_only is supported since Release 0.3 
(May 6, 2008):

  https://github.com/sphinx-doc/sphinx/blob/master/CHANGES.old#L1025

But is was implemented optional (from the beginning):

 https://github.com/sphinx-doc/sphinx/blame/master/sphinx/builders/latex.py#L104

-- Markus --

> 
> Regards,
> Mauro
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCHv12 1/3] rdmacg: Added rdma cgroup controller

[Parav Pandit]

Hi Matan,

On Thu, Sep 1, 2016 at 2:14 PM, Christoph Hellwig  wrote:
> On Thu, Sep 01, 2016 at 10:25:40AM +0300, Matan Barak wrote:
>> Well, if I recall, the reason doing so last time was in order to allow
>> flexible updating of ib_core independently, which is obviously not a good
>> reason (to say the least).
>>
>> Since the new ABI will probably define new object types (all recent
>> proposals go this way), the current approach could lead to either trying to
>> map new objects to existing cgroup resource types, which could lead to some
>> weird non 1:1 mapping, or having a split definitions - such that each
>> driver will declare its objects both in the cgroups mechanism and in its
>> driver dispatch table.

>> Even worse than that, drivers could simply ignore the cgroups support while
>> implementing their own resource types and get a very broken containers
>> support.
If drivers are broken due to ignorance of not-calling cgroup APIs,
that should be ok.
That particular driver should fix it.
If the resource creation using uverbs is using well defined rdma level
resource, uverbs level will make sure to honor cgroup limits without
involving hw drivers anyway.

RDMA Verb level resource is charged/uncharged by RDMA core.
RDMA HW level resource is charged/uncharged by RDMA HW driver using
well defined API and resource by cgroup core.
This scheme ensures that there is 1:1 mapping.

I don't think current definition of resource type is carved out on stone.
They can be extended as we forward.
As many of us agree that, they should be well defined and it should be
agreed by cgroup and rdma community.

For example, today we have RDMA_VERB_xxx resources.
New well defined RDMA HW resources can be defined in rdma_cgroup.h
file as RDMA_HW_xx in same enum table.

>
> Sorry guys, but arbitrary extensibility for something not finished is the
> worst idea ever.  We have two options here:
>
>  a) delay cgroups support until the grand rewrite is done
>  b) add it now and deal with the consequences later
>
Can we do (b) now and differ adding any HW resources to cgroup until
they are clearly called out.
Architecture and APIs are already in place to support this.

> That being said, adding random non-Verbs hardwasre to the RDMA core is
> the second worst idea ever.

We can differ adding HW resource to core and cgroup until they are
clearly defined.
In that case current architecture still holds good.

> Guess I need to catch up with the
> discussion and start using the flame thrower.

Matan,
Can you please point us to the new RFC/ABI email thread which
describes the design, partitioning of code between core vs hw drivers
etc.
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] docs: make kernel-doc handle varargs properly

[Markus Heiser]

Am 06.09.2016 um 15:36 schrieb Jonathan Corbet :

> On Sat, 27 Aug 2016 11:43:18 +0300
> Jani Nikula  wrote:
> 
>> On Fri, 26 Aug 2016, Jonathan Corbet  wrote:
>>> As far as I can tell, the handling of "..." arguments has never worked
>>> right, so any documentation provided was ignored in favor of "variable
>>> arguments."  This makes kernel-doc handle "@...:" as documented.  It does
>>> *not* fix spots in kerneldoc comments that don't follow that convention,
>>> but they are no more broken than before.
>>> 
>>> Signed-off-by: Jonathan Corbet 
>>> ---
>>> scripts/kernel-doc | 3 ++-
>>> 1 file changed, 2 insertions(+), 1 deletion(-)
>>> 
>>> diff --git a/scripts/kernel-doc b/scripts/kernel-doc
>>> index c681e8f0ecc2..e6c52ab938fd 100755
>>> --- a/scripts/kernel-doc
>>> +++ b/scripts/kernel-doc
>>> @@ -414,7 +414,7 @@ my $doc_com_body = '\s*\* ?';
>>> my $doc_decl = $doc_com . '(\w+)';
>>> # @params and a strictly limited set of supported section names
>>> my $doc_sect = $doc_com . 
>>> -'\s*(\@\w+|description|context|returns?|notes?|examples?)\s*:(.*)';
>>> +'\s*(\@[.\w]+|description|context|returns?|notes?|examples?)\s*:(.*)'; 
>>>  
>> 
>> So this will now accept "@foo.bar.baz:" too, right? Should it be
>> something like this instead?
>> 
>> '\s*(\@\w+|\@\.\.\.|description|context|returns?|notes?|examples?)\s*:(.*)';
> 
> That works too.
> 
> I had a sort of vision of catching the "args..." notation that a lot of
> kerneldoc comments use and doing the right thing, but ran out of patience
> before getting it to work.  There are times when I find Markus's python
> kernel-doc replacement tempting...

Feel free to contact me if you want to see a RFC.

OT but BTW: Does sparse parse macros, or did sparse precompile? I mean,
are macros objects of sparse's AST or does the AST only contain
C objects?

Sorry if my question is dump, I haven't had time to take a serious
look on sparse.

-- Markus --

>  Maybe I'll beat my head against that
> wall one more time when I get a chance and, failing that, just use the
> above.
> 
> Thanks,
> 
> jon

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[RFC v2 3/3] doc-rst:c-domain: function-like macros index entry

[Markus Heiser]

From: Markus Heiser 

For function-like macros, sphinx creates 'FOO (C function)' entries.
With this patch 'FOO (C macro)' are created for function-like macros,
which is the same for object-like macros.

Signed-off-by: Markus Heiser 
---
 Documentation/sphinx/cdomain.py | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/Documentation/sphinx/cdomain.py b/Documentation/sphinx/cdomain.py
index df0419c..ead81b5 100644
--- a/Documentation/sphinx/cdomain.py
+++ b/Documentation/sphinx/cdomain.py
@@ -37,6 +37,7 @@ from docutils.parsers.rst import directives
 
 import sphinx
 from sphinx import addnodes
+from sphinx.locale import _
 from sphinx.domains.c import c_funcptr_sig_re, c_sig_re
 from sphinx.domains.c import CObject as Base_CObject
 from sphinx.domains.c import CDomain as Base_CDomain
@@ -65,6 +66,8 @@ class CObject(Base_CObject):
 "name" : directives.unchanged
 }
 
+is_function_like_macro = False
+
 def handle_func_like_macro(self, sig, signode):
 u"""Handles signatures of function-like macros.
 
@@ -104,6 +107,7 @@ class CObject(Base_CObject):
 param += nodes.emphasis(argname, argname)
 paramlist += param
 
+self.is_function_like_macro = True
 return fullname
 
 def handle_signature(self, sig, signode):
@@ -151,6 +155,12 @@ class CObject(Base_CObject):
 self.indexnode['entries'].append(
 ('single', indextext, targetname, '', None))
 
+def get_index_text(self, name):
+if self.is_function_like_macro:
+return _('%s (C macro)') % name
+else:
+return super(CObject, self).get_index_text(name)
+
 class CDomain(Base_CDomain):
 
 """C language domain."""
-- 
2.7.4

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 2/3] doc-rst:c-domain: function-like macros arguments

[Markus Heiser]

From: Markus Heiser 

Handle signatures of function-like macros well. Don't try to deduce
arguments types of function-like macros.

Signed-off-by: Markus Heiser 
---
 Documentation/sphinx/cdomain.py | 55 -
 1 file changed, 54 insertions(+), 1 deletion(-)

diff --git a/Documentation/sphinx/cdomain.py b/Documentation/sphinx/cdomain.py
index 5f0c7ed..df0419c 100644
--- a/Documentation/sphinx/cdomain.py
+++ b/Documentation/sphinx/cdomain.py
@@ -1,4 +1,5 @@
 # -*- coding: utf-8; mode: python -*-
+# pylint: disable=W0141,C0113,C0103,C0325
 u"""
 cdomain
 ~~~
@@ -25,11 +26,18 @@ u"""
 
   * :c:func:`VIDIOC_LOG_STATUS` or
   * :any:`VIDIOC_LOG_STATUS` (``:any:`` needs sphinx 1.3)
+
+ * Handle signatures of function-like macros well. Don't try to deduce
+   arguments types of function-like macros.
+
 """
 
+from docutils import nodes
 from docutils.parsers.rst import directives
 
 import sphinx
+from sphinx import addnodes
+from sphinx.domains.c import c_funcptr_sig_re, c_sig_re
 from sphinx.domains.c import CObject as Base_CObject
 from sphinx.domains.c import CDomain as Base_CDomain
 
@@ -57,9 +65,54 @@ class CObject(Base_CObject):
 "name" : directives.unchanged
 }
 
+def handle_func_like_macro(self, sig, signode):
+u"""Handles signatures of function-like macros.
+
+If the objtype is 'function' and the the signature ``sig`` is a
+function-like macro, the name of the macro is returned. Otherwise
+``False`` is returned.  """
+
+if not self.objtype == 'function':
+return False
+
+m = c_funcptr_sig_re.match(sig)
+if m is None:
+m = c_sig_re.match(sig)
+if m is None:
+raise ValueError('no match')
+
+rettype, fullname, arglist, _const = m.groups()
+arglist = arglist.strip()
+if rettype or not arglist:
+return False
+
+arglist = arglist.replace('`', '').replace('\\ ', '') # remove markup
+arglist = [a.strip() for a in arglist.split(",")]
+
+# has the first argument a type?
+if len(arglist[0].split(" ")) > 1:
+return False
+
+# This is a function-like macro, it's arguments are typeless!
+signode  += addnodes.desc_name(fullname, fullname)
+paramlist = addnodes.desc_parameterlist()
+signode  += paramlist
+
+for argname in arglist:
+param = addnodes.desc_parameter('', '', noemph=True)
+# separate by non-breaking space in the output
+param += nodes.emphasis(argname, argname)
+paramlist += param
+
+return fullname
+
 def handle_signature(self, sig, signode):
 """Transform a C signature into RST nodes."""
-fullname = super(CObject, self).handle_signature(sig, signode)
+
+fullname = self.handle_func_like_macro(sig, signode)
+if not fullname:
+fullname = super(CObject, self).handle_signature(sig, signode)
+
 if "name" in self.options:
 if self.objtype == 'function':
 fullname = self.options["name"]
-- 
2.7.4

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 0/3] doc-rst:c-domain: fix some issues in the c-domain

[Markus Heiser]

From: Markus Heiser 

Hi Jon,

according to your remarks I fixed the first and second patch. The third patch is
resend unchanged;

> Am 06.09.2016 um 14:28 schrieb Jonathan Corbet :
>
> As others have pointed out, we generally want to hide the difference
> between functions and macros, so this is probably one change we don't
> want.

I read "probably", so there might be a chance to persuade you ;)

I'm not a friend of *information hiding* and since the index is sorted
alphabetical it does no matter if the entry is 'FOO (C function)' or 'FOO (C
macro)'. The last one has the right information e.g. for someone how is looking
for a macro. FOO is a function-like macro and not a function, if the author
describes the macro he might use the word "macro FOO" but in the index it is
tagged as C function.

Macros and functions are totally different even if their notation looks
similarly. So where is the benefit of entries like 'FOO (C function)', which is
IMHO ambiguous.

I tagged the 'function-like macros index entry' patch with 'RFC' and resend it
within this series. If you and/or others have a different opinion, feel free to
drop it.

Thanks for review.

-- Markus --


Markus Heiser (3):
  doc-rst:c-domain: fix sphinx version incompatibility
  doc-rst:c-domain: function-like macros arguments
  doc-rst:c-domain: function-like macros index entry

 Documentation/sphinx/cdomain.py | 79 +++--
 1 file changed, 76 insertions(+), 3 deletions(-)

-- 
2.7.4

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html