* Re: [Patch v4 16/22] CIFS: SMBD: Fix the definition for SMB2_CHANNEL_RDMA_V1_INVALIDATE
From: Steve French @ 2017-10-04 22:07 UTC (permalink / raw)
To: Long Li
Cc: Steve French, linux-cifs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
samba-technical, LKML, linux-rdma-u79uwXL29TY76Z2rM5mHXA,
Christoph Hellwig, Tom Talpey, Matthew Wilcox, Long Li
In-Reply-To: <20171002023030.3582-17-longli-Lp/cVzEoVyZiJJESP9tAQJZ3qXmFLfmx@public.gmane.org>
Good catch - merged into cifs-2.6.git for-next
On Sun, Oct 1, 2017 at 9:30 PM, Long Li <longli-Lp/cVzEoVyZiJJESP9tAQJZ3qXmFLfmx@public.gmane.org> wrote:
> From: Long Li <longli-0li6OtcxBFHby3iVrkZq2A@public.gmane.org>
>
> The channel value for requesting server remote invalidating local memory
> registration should be 0x00000002
>
> Signed-off-by: Long Li <longli-0li6OtcxBFHby3iVrkZq2A@public.gmane.org>
> ---
> fs/cifs/smb2pdu.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/fs/cifs/smb2pdu.h b/fs/cifs/smb2pdu.h
> index 393ed5f..f783a08 100644
> --- a/fs/cifs/smb2pdu.h
> +++ b/fs/cifs/smb2pdu.h
> @@ -832,7 +832,7 @@ struct smb2_flush_rsp {
> /* Channel field for read and write: exactly one of following flags can be set*/
> #define SMB2_CHANNEL_NONE 0x00000000
> #define SMB2_CHANNEL_RDMA_V1 0x00000001 /* SMB3 or later */
> -#define SMB2_CHANNEL_RDMA_V1_INVALIDATE 0x00000001 /* SMB3.02 or later */
> +#define SMB2_CHANNEL_RDMA_V1_INVALIDATE 0x00000002 /* SMB3.02 or later */
>
> /* SMB2 read request without RFC1001 length at the beginning */
> struct smb2_read_plain_req {
> --
> 2.7.4
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-cifs" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Thanks,
Steve
^ permalink raw reply
* Re: [PATCHv2 1/1] [tools]: android/ion: userspace test utility for ion buffer sharing
From: Laura Abbott @ 2017-10-04 22:07 UTC (permalink / raw)
To: Pintu Kumar; +Cc: linux-kernel, Greg Kroah-Hartman, Pintu Kumar
In-Reply-To: <CAOuPNLh8+-gEia41fB1Ok6NSJnhWG=dxCRR8KcfNiQSMRb3-ng@mail.gmail.com>
On 10/04/2017 04:29 AM, Pintu Kumar wrote:
> The whole thing about this test is to share an FD over 2 independent processes.
> I think sharing an FD using fork() [parent/child] is not a real use
> case scenarios.
> Some people may not like the fork example.
> Initially when I started with ION, I also needed an FD sharing mechanism between
> 2 different process. Thus I came up with this framework using ipcsocket.
> Later, if required, we can even replace this with binder_ipc for
> android use cases.
> Anyways, binder_ipc also internally uses the same concept as this ipcsocket.
> To reduce the pain, we can invoke both the tests from a single shell scripts.
> I will try to include the same in kselftests, if possible.
>
> If fork example is really required, we can add another test for it.
> This is my opinion.
You don't have to treat them as parent/child. Once they've forked
the processes are independent so you can use the same socket behavior
you've implemented here. I prefer the fork behavior over the shell
script because it means I only need to copy one file vs. three if
I'm testing in other environments but I'm not that opposed.
Thanks,
Laura
^ permalink raw reply
* Re: [PATCH] cifs: Fake rwx permissions if we can not read the CIFS ACL
From: Steve French @ 2017-10-04 22:07 UTC (permalink / raw)
To: Ronnie Sahlberg; +Cc: linux-cifs
In-Reply-To: <CAH2r5muHtkLFHkrKdmto04E=LSLn3BXJ54h4uGnhip7E0Z-hzQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
and added cc:stable
On Wed, Oct 4, 2017 at 5:06 PM, Steve French <smfrench-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> merged into cifs-2.6.git for-next but notice minor nit about comments
> (always run checpatch before submitting)
>
> WARNING: Block comments use * on subsequent lines
> #85: FILE: fs/cifs/cifsacl.c:1160:
> + /* If we do not have permission to read the ACL
> + just clear all rwx permissions */
>
> On Tue, Oct 3, 2017 at 11:59 PM, Ronnie Sahlberg <lsahlber-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
>> If the cifsacl mount option is used and we try to list a directory that
>> contains entries where we do not have READ_CONTROL access we will see errors
>> such as "ls: cannot access '...': Permission denied"
>> and the directory listing will show files with funny attributes like
>> "-?????????? ? ? ? ? ? foo002.txt"
>>
>> This patch fixes this by checking the error from reading the security
>> descriptor and if it failed with EACCES we fake the attributes as
>> all 0.
>>
>> Signed-off-by: Ronnie Sahlberg <lsahlber-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
>> ---
>> fs/cifs/cifsacl.c | 10 +++++++++-
>> 1 file changed, 9 insertions(+), 1 deletion(-)
>>
>> diff --git a/fs/cifs/cifsacl.c b/fs/cifs/cifsacl.c
>> index b98436f5c7c7..11d0d135a9b7 100644
>> --- a/fs/cifs/cifsacl.c
>> +++ b/fs/cifs/cifsacl.c
>> @@ -1155,7 +1155,15 @@ cifs_acl_to_fattr(struct cifs_sb_info *cifs_sb, struct cifs_fattr *fattr,
>> /* if we can retrieve the ACL, now parse Access Control Entries, ACEs */
>> if (IS_ERR(pntsd)) {
>> rc = PTR_ERR(pntsd);
>> - cifs_dbg(VFS, "%s: error %d getting sec desc\n", __func__, rc);
>> + if (rc == -EACCES) {
>> + /* If we do not have permission to read the ACL
>> + just clear all rwx permissions */
>> + cifs_dbg(NOISY, "%s: EACCES reading ACL\n", __func__);
>> + fattr->cf_mode &= ~(S_IRWXUGO);
>> + rc = 0;
>> + } else
>> + cifs_dbg(VFS, "%s: error %d getting sec desc\n",
>> + __func__, rc);
>> } else {
>> rc = parse_sec_desc(cifs_sb, pntsd, acllen, fattr);
>> kfree(pntsd);
>> --
>> 2.13.3
>>
>
>
>
> --
> Thanks,
>
> Steve
--
Thanks,
Steve
^ permalink raw reply
* Re: [PATCH] cifs: Fake rwx permissions if we can not read the CIFS ACL
From: Steve French @ 2017-10-04 22:06 UTC (permalink / raw)
To: Ronnie Sahlberg; +Cc: linux-cifs
In-Reply-To: <20171004045953.28134-1-lsahlber-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
merged into cifs-2.6.git for-next but notice minor nit about comments
(always run checpatch before submitting)
WARNING: Block comments use * on subsequent lines
#85: FILE: fs/cifs/cifsacl.c:1160:
+ /* If we do not have permission to read the ACL
+ just clear all rwx permissions */
On Tue, Oct 3, 2017 at 11:59 PM, Ronnie Sahlberg <lsahlber-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
> If the cifsacl mount option is used and we try to list a directory that
> contains entries where we do not have READ_CONTROL access we will see errors
> such as "ls: cannot access '...': Permission denied"
> and the directory listing will show files with funny attributes like
> "-?????????? ? ? ? ? ? foo002.txt"
>
> This patch fixes this by checking the error from reading the security
> descriptor and if it failed with EACCES we fake the attributes as
> all 0.
>
> Signed-off-by: Ronnie Sahlberg <lsahlber-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
> ---
> fs/cifs/cifsacl.c | 10 +++++++++-
> 1 file changed, 9 insertions(+), 1 deletion(-)
>
> diff --git a/fs/cifs/cifsacl.c b/fs/cifs/cifsacl.c
> index b98436f5c7c7..11d0d135a9b7 100644
> --- a/fs/cifs/cifsacl.c
> +++ b/fs/cifs/cifsacl.c
> @@ -1155,7 +1155,15 @@ cifs_acl_to_fattr(struct cifs_sb_info *cifs_sb, struct cifs_fattr *fattr,
> /* if we can retrieve the ACL, now parse Access Control Entries, ACEs */
> if (IS_ERR(pntsd)) {
> rc = PTR_ERR(pntsd);
> - cifs_dbg(VFS, "%s: error %d getting sec desc\n", __func__, rc);
> + if (rc == -EACCES) {
> + /* If we do not have permission to read the ACL
> + just clear all rwx permissions */
> + cifs_dbg(NOISY, "%s: EACCES reading ACL\n", __func__);
> + fattr->cf_mode &= ~(S_IRWXUGO);
> + rc = 0;
> + } else
> + cifs_dbg(VFS, "%s: error %d getting sec desc\n",
> + __func__, rc);
> } else {
> rc = parse_sec_desc(cifs_sb, pntsd, acllen, fattr);
> kfree(pntsd);
> --
> 2.13.3
>
--
Thanks,
Steve
^ permalink raw reply
* [Qemu-devel] [PATCH] linux-user: Add random ioctls
From: Marco A L Barbosa @ 2017-10-04 22:06 UTC (permalink / raw)
To: qemu-devel; +Cc: qemu-trivial
I don't know how (and if it is necessary) to add buf field to
rand_pool_info struct. See
https://github.com/torvalds/linux/blob/5924bbecd0267d87c24110cbe2041b5075173a25/include/uapi/linux/random.h#L17
Signed-off-by: Marco A L Barbosa <malbarbo@gmail.com>
---
linux-user/ioctls.h | 7 +++++++
linux-user/syscall.c | 1 +
linux-user/syscall_defs.h | 9 +++++++++
linux-user/syscall_types.h | 4 ++++
4 files changed, 21 insertions(+)
diff --git a/linux-user/ioctls.h b/linux-user/ioctls.h
index e6997ff230..9240a83f30 100644
--- a/linux-user/ioctls.h
+++ b/linux-user/ioctls.h
@@ -173,6 +173,13 @@
IOCTL(SIOCGSTAMP, IOC_R, MK_PTR(MK_STRUCT(STRUCT_timeval)))
IOCTL(SIOCGSTAMPNS, IOC_R, MK_PTR(MK_STRUCT(STRUCT_timespec)))
+ IOCTL(RNDGETENTCNT, IOC_R, MK_PTR(TYPE_INT))
+ IOCTL(RNDADDTOENTCNT, IOC_W, MK_PTR(MK_STRUCT(STRUCT_rand_pool_info)))
+ IOCTL(RNDGETPOOL, IOC_R, MK_PTR(TYPE_INT))
+ IOCTL(RNDADDENTROPY, IOC_W, MK_PTR(MK_STRUCT(STRUCT_rand_pool_info)))
+ IOCTL(RNDZAPENTCNT, 0, TYPE_NULL)
+ IOCTL(RNDCLEARPOOL, 0, TYPE_NULL)
+
IOCTL(CDROMPAUSE, 0, TYPE_NULL)
IOCTL(CDROMSTART, 0, TYPE_NULL)
IOCTL(CDROMSTOP, 0, TYPE_NULL)
diff --git a/linux-user/syscall.c b/linux-user/syscall.c
index 9b6364a266..d4c21a557c 100644
--- a/linux-user/syscall.c
+++ b/linux-user/syscall.c
@@ -59,6 +59,7 @@ int __clone2(int (*fn)(void *), void *child_stack_base,
#include <linux/icmp.h>
#include <linux/icmpv6.h>
#include <linux/errqueue.h>
+#include <linux/random.h>
#include "qemu-common.h"
#ifdef CONFIG_TIMERFD
#include <sys/timerfd.h>
diff --git a/linux-user/syscall_defs.h b/linux-user/syscall_defs.h
index 40c5027e93..d14fdd82ce 100644
--- a/linux-user/syscall_defs.h
+++ b/linux-user/syscall_defs.h
@@ -1060,6 +1060,15 @@ struct target_pollfd {
#define TARGET_SIOCGIWNAME 0x8B01 /* get name == wireless
protocol */
+/* From <linux/random.h> */
+
+#define TARGET_RNDGETENTCNT TARGET_IOR('R', 0x00, int)
+#define TARGET_RNDADDTOENTCNT TARGET_IOW('R', 0x01, int)
+#define TARGET_RNDGETPOOL TARGET_IOR('R', 0x02, struct rand_pool_info)
+#define TARGET_RNDADDENTROPY TARGET_IOW('R', 0x03, struct rand_pool_info)
+#define TARGET_RNDZAPENTCNT TARGET_IO('R', 0x04)
+#define TARGET_RNDCLEARPOOL TARGET_IO('R', 0x06)
+
/* From <linux/fs.h> */
#define TARGET_BLKROSET TARGET_IO(0x12,93) /* set device read-only (0 =
read-write) */
diff --git a/linux-user/syscall_types.h b/linux-user/syscall_types.h
index 24631b09be..2e2e000424 100644
--- a/linux-user/syscall_types.h
+++ b/linux-user/syscall_types.h
@@ -266,3 +266,7 @@ STRUCT(blkpg_ioctl_arg,
TYPE_INT, /* flags */
TYPE_INT, /* datalen */
TYPE_PTRVOID) /* data */
+
+STRUCT(rand_pool_info,
+ TYPE_INT, /* entropy_count */
+ TYPE_INT) /* buf_size */
--
2.11.0
--
Marco A L Barbosa
http://malbarbo.pro.br
--
^ permalink raw reply related
* + userfaultfd-selftest-exercise-eexist-only-in-background-transfer.patch added to -mm tree
From: akpm @ 2017-10-04 22:06 UTC (permalink / raw)
To: aarcange, dgilbert, mike.kravetz, rppt, shuah, xemul, mm-commits
The patch titled
Subject: userfaultfd: selftest: exercise -EEXIST only in background transfer
has been added to the -mm tree. Its filename is
userfaultfd-selftest-exercise-eexist-only-in-background-transfer.patch
This patch should soon appear at
http://ozlabs.org/~akpm/mmots/broken-out/userfaultfd-selftest-exercise-eexist-only-in-background-transfer.patch
and later at
http://ozlabs.org/~akpm/mmotm/broken-out/userfaultfd-selftest-exercise-eexist-only-in-background-transfer.patch
Before you just go and hit "reply", please:
a) Consider who else should be cc'ed
b) Prefer to cc a suitable mailing list as well
c) Ideally: find the original patch on the mailing list and do a
reply-to-all to that, adding suitable additional cc's
*** Remember to use Documentation/SubmitChecklist when testing your code ***
The -mm tree is included into linux-next and is updated
there every 3-4 working days
------------------------------------------------------
From: Andrea Arcangeli <aarcange@redhat.com>
Subject: userfaultfd: selftest: exercise -EEXIST only in background transfer
I was stress testing some backports and with high load, after some time,
the latest version of the selftest showed some false positive in
connection with the uffdio_copy_retry. This seems to fix it while still
exercising -EEXIST in the background transfer once in a while.
The fork child will quit after the last UFFDIO_COPY is run, so a repeated
UFFDIO_COPY may not return -EEXIST. This change restricts the -EEXIST
stress to the background transfer where the memory can't go away from
under it.
Also updated uffdio_zeropage, so the interface is consistent.
Link: http://lkml.kernel.org/r/20171004171541.1495-2-aarcange@redhat.com
Signed-off-by: Andrea Arcangeli <aarcange@redhat.com>
Cc: Pavel Emelyanov <xemul@virtuozzo.com>
Cc: Mike Rapoport <rppt@linux.vnet.ibm.com>
Cc: "Dr. David Alan Gilbert" <dgilbert@redhat.com>
Cc: Mike Kravetz <mike.kravetz@oracle.com>
Cc: Shuah Khan <shuah@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
tools/testing/selftests/vm/userfaultfd.c | 25 ++++++++++++++++-----
1 file changed, 20 insertions(+), 5 deletions(-)
diff -puN tools/testing/selftests/vm/userfaultfd.c~userfaultfd-selftest-exercise-eexist-only-in-background-transfer tools/testing/selftests/vm/userfaultfd.c
--- a/tools/testing/selftests/vm/userfaultfd.c~userfaultfd-selftest-exercise-eexist-only-in-background-transfer
+++ a/tools/testing/selftests/vm/userfaultfd.c
@@ -397,7 +397,7 @@ static void retry_copy_page(int ufd, str
}
}
-static int copy_page(int ufd, unsigned long offset)
+static int __copy_page(int ufd, unsigned long offset, bool retry)
{
struct uffdio_copy uffdio_copy;
@@ -418,7 +418,7 @@ static int copy_page(int ufd, unsigned l
fprintf(stderr, "UFFDIO_COPY unexpected copy %Ld\n",
uffdio_copy.copy), exit(1);
} else {
- if (test_uffdio_copy_eexist) {
+ if (test_uffdio_copy_eexist && retry) {
test_uffdio_copy_eexist = false;
retry_copy_page(ufd, &uffdio_copy, offset);
}
@@ -427,6 +427,16 @@ static int copy_page(int ufd, unsigned l
return 0;
}
+static int copy_page_retry(int ufd, unsigned long offset)
+{
+ return __copy_page(ufd, offset, true);
+}
+
+static int copy_page(int ufd, unsigned long offset)
+{
+ return __copy_page(ufd, offset, false);
+}
+
static void *uffd_poll_thread(void *arg)
{
unsigned long cpu = (unsigned long) arg;
@@ -544,7 +554,7 @@ static void *background_thread(void *arg
for (page_nr = cpu * nr_pages_per_cpu;
page_nr < (cpu+1) * nr_pages_per_cpu;
page_nr++)
- copy_page(uffd, page_nr * page_size);
+ copy_page_retry(uffd, page_nr * page_size);
return NULL;
}
@@ -779,7 +789,7 @@ static void retry_uffdio_zeropage(int uf
}
}
-static int uffdio_zeropage(int ufd, unsigned long offset)
+static int __uffdio_zeropage(int ufd, unsigned long offset, bool retry)
{
struct uffdio_zeropage uffdio_zeropage;
int ret;
@@ -814,7 +824,7 @@ static int uffdio_zeropage(int ufd, unsi
fprintf(stderr, "UFFDIO_ZEROPAGE unexpected %Ld\n",
uffdio_zeropage.zeropage), exit(1);
} else {
- if (test_uffdio_zeropage_eexist) {
+ if (test_uffdio_zeropage_eexist && retry) {
test_uffdio_zeropage_eexist = false;
retry_uffdio_zeropage(ufd, &uffdio_zeropage,
offset);
@@ -830,6 +840,11 @@ static int uffdio_zeropage(int ufd, unsi
return 0;
}
+static int uffdio_zeropage(int ufd, unsigned long offset)
+{
+ return __uffdio_zeropage(ufd, offset, false);
+}
+
/* exercise UFFDIO_ZEROPAGE */
static int userfaultfd_zeropage_test(void)
{
_
Patches currently in -mm which might be from aarcange@redhat.com are
userfaultfd-selftest-exercise-eexist-only-in-background-transfer.patch
^ permalink raw reply
* [GIT PULL membarrier/urgent] membarrier commits for 4.14
From: Paul E. McKenney @ 2017-10-04 22:05 UTC (permalink / raw)
To: mingo
Cc: mathieu.desnoyers, peterz, boqun.feng, ahh, maged.michael, gromer,
avi, benh, paulus, mpe, davejwatson, stern, will.deacon, luto,
mingo, viro, npiggin, linux-arch, linux-kernel
Hello, Ingo,
This urgent pull request contains three commits that fix a problem
that arose when designing requested extensions to sys_membarrier()
to allow JITs to efficiently flush old code from instruction caches.
Several potential algorithms are much less painful if the user register
intent to use this functionality early on, for example, before the process
spawns the second thread. Registering at this time removes the need to
interrupt each and every thread in that process at the first expedited
sys_membarrier() system call.
However, if we let the current function out, then user programs might be
written without registration, which would make it more difficult to add
required registration after the fact. Hence the late-in-merge-window
pull request.
These have been subject to 0day test robot and -next testing and
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git urgent-for-mingo
for you to fetch changes up to 204a0fa1a3ecd9244869fa67608ad4fda232cba1:
membarrier: Document scheduler barrier requirements (2017-10-04 11:02:18 -0700)
----------------------------------------------------------------
Mathieu Desnoyers (3):
membarrier: Provide register expedited private command
membarrier: selftest: Test private expedited cmd
membarrier: Document scheduler barrier requirements
MAINTAINERS | 2 +
arch/powerpc/Kconfig | 1 +
arch/powerpc/include/asm/membarrier.h | 43 ++++++++
arch/powerpc/include/asm/thread_info.h | 3 +
arch/powerpc/kernel/Makefile | 2 +
arch/powerpc/kernel/membarrier.c | 45 +++++++++
arch/powerpc/mm/mmu_context.c | 7 ++
arch/x86/mm/tlb.c | 5 +
fs/exec.c | 1 +
include/linux/mm_types.h | 3 +
include/linux/sched/mm.h | 55 +++++++++++
include/uapi/linux/membarrier.h | 23 +++--
init/Kconfig | 3 +
kernel/fork.c | 2 +
kernel/sched/core.c | 47 +++++----
kernel/sched/membarrier.c | 25 ++++-
.../testing/selftests/membarrier/membarrier_test.c | 109 ++++++++++++++++++---
17 files changed, 329 insertions(+), 47 deletions(-)
create mode 100644 arch/powerpc/include/asm/membarrier.h
create mode 100644 arch/powerpc/kernel/membarrier.c
^ permalink raw reply
* + mm-oom-show-unreclaimable-slab-info-when-unreclaimable-slabs-user-memory.patch added to -mm tree
From: akpm @ 2017-10-04 22:04 UTC (permalink / raw)
To: yang.s, cl, iamjoonsoo.kim, mhocko, penberg, rientjes, mm-commits
The patch titled
Subject: mm: oom: show unreclaimable slab info when unreclaimable slabs > user memory
has been added to the -mm tree. Its filename is
mm-oom-show-unreclaimable-slab-info-when-unreclaimable-slabs-user-memory.patch
This patch should soon appear at
http://ozlabs.org/~akpm/mmots/broken-out/mm-oom-show-unreclaimable-slab-info-when-unreclaimable-slabs-user-memory.patch
and later at
http://ozlabs.org/~akpm/mmotm/broken-out/mm-oom-show-unreclaimable-slab-info-when-unreclaimable-slabs-user-memory.patch
Before you just go and hit "reply", please:
a) Consider who else should be cc'ed
b) Prefer to cc a suitable mailing list as well
c) Ideally: find the original patch on the mailing list and do a
reply-to-all to that, adding suitable additional cc's
*** Remember to use Documentation/SubmitChecklist when testing your code ***
The -mm tree is included into linux-next and is updated
there every 3-4 working days
------------------------------------------------------
From: "Yang Shi" <yang.s@alibaba-inc.com>
Subject: mm: oom: show unreclaimable slab info when unreclaimable slabs > user memory
Kernel may panic when oom happens without killable process sometimes it is
caused by huge unreclaimable slabs used by kernel.
Although kdump could help debug such problem, however, kdump is not
available on all architectures and it might be malfunction sometime. And,
since kernel already panic it is worthy capturing such information in
dmesg to aid touble shooting.
Print out unreclaimable slab info (used size and total size) which actual
memory usage is not zero (num_objs * size != 0) when unreclaimable slabs
amount is greater than total user memory (LRU pages).
The output looks like:
Unreclaimable slab info:
Name Used Total
rpc_buffers 31KB 31KB
rpc_tasks 7KB 7KB
ebitmap_node 1964KB 1964KB
avtab_node 5024KB 5024KB
xfs_buf 1402KB 1402KB
xfs_ili 134KB 134KB
xfs_efi_item 115KB 115KB
xfs_efd_item 115KB 115KB
xfs_buf_item 134KB 134KB
xfs_log_item_desc 342KB 342KB
xfs_trans 1412KB 1412KB
xfs_ifork 212KB 212KB
Link: http://lkml.kernel.org/r/1507152550-46205-4-git-send-email-yang.s@alibaba-inc.com
Signed-off-by: Yang Shi <yang.s@alibaba-inc.com>
Cc: Christoph Lameter <cl@linux.com>
Cc: David Rientjes <rientjes@google.com>
Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
Cc: Michal Hocko <mhocko@kernel.org>
Cc: Pekka Enberg <penberg@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
mm/oom_kill.c | 27 +++++++++++++++++++++++++--
mm/slab.h | 2 ++
mm/slab_common.c | 35 +++++++++++++++++++++++++++++++++++
3 files changed, 62 insertions(+), 2 deletions(-)
diff -puN mm/oom_kill.c~mm-oom-show-unreclaimable-slab-info-when-unreclaimable-slabs-user-memory mm/oom_kill.c
--- a/mm/oom_kill.c~mm-oom-show-unreclaimable-slab-info-when-unreclaimable-slabs-user-memory
+++ a/mm/oom_kill.c
@@ -44,6 +44,7 @@
#include <asm/tlb.h>
#include "internal.h"
+#include "slab.h"
#define CREATE_TRACE_POINTS
#include <trace/events/oom.h>
@@ -161,6 +162,25 @@ static bool oom_unkillable_task(struct t
return false;
}
+/*
+ * Print out unreclaimble slabs info when unreclaimable slabs amount is greater
+ * than all user memory (LRU pages)
+ */
+static bool is_dump_unreclaim_slabs(void)
+{
+ unsigned long nr_lru;
+
+ nr_lru = global_node_page_state(NR_ACTIVE_ANON) +
+ global_node_page_state(NR_INACTIVE_ANON) +
+ global_node_page_state(NR_ACTIVE_FILE) +
+ global_node_page_state(NR_INACTIVE_FILE) +
+ global_node_page_state(NR_ISOLATED_ANON) +
+ global_node_page_state(NR_ISOLATED_FILE) +
+ global_node_page_state(NR_UNEVICTABLE);
+
+ return (global_node_page_state(NR_SLAB_UNRECLAIMABLE) > nr_lru);
+}
+
/**
* oom_badness - heuristic function to determine which candidate task to kill
* @p: task struct of which task we should calculate
@@ -420,10 +440,13 @@ static void dump_header(struct oom_contr
cpuset_print_current_mems_allowed();
dump_stack();
- if (oc->memcg)
+ if (is_memcg_oom(oc))
mem_cgroup_print_oom_info(oc->memcg, p);
- else
+ else {
show_mem(SHOW_MEM_FILTER_NODES, oc->nodemask);
+ if (is_dump_unreclaim_slabs())
+ dump_unreclaimable_slab();
+ }
if (sysctl_oom_dump_tasks)
dump_tasks(oc->memcg, oc->nodemask);
}
diff -puN mm/slab_common.c~mm-oom-show-unreclaimable-slab-info-when-unreclaimable-slabs-user-memory mm/slab_common.c
--- a/mm/slab_common.c~mm-oom-show-unreclaimable-slab-info-when-unreclaimable-slabs-user-memory
+++ a/mm/slab_common.c
@@ -1278,6 +1278,41 @@ static int slab_show(struct seq_file *m,
return 0;
}
+void dump_unreclaimable_slab(void)
+{
+ struct kmem_cache *s, *s2;
+ struct slabinfo sinfo;
+
+ /*
+ * Here acquiring slab_mutex is risky since we don't prefer to get
+ * sleep in oom path. But, without mutex hold, it may introduce a
+ * risk of crash.
+ * Use mutex_trylock to protect the list traverse, dump nothing
+ * without acquiring the mutex.
+ */
+ if (!mutex_trylock(&slab_mutex)) {
+ pr_warn("excessive unreclaimable slab but cannot dump stats\n");
+ return;
+ }
+
+ pr_info("Unreclaimable slab info:\n");
+ pr_info("Name Used Total\n");
+
+ list_for_each_entry_safe(s, s2, &slab_caches, list) {
+ if (!is_root_cache(s) || (s->flags & SLAB_RECLAIM_ACCOUNT))
+ continue;
+
+ memset(&sinfo, 0, sizeof(sinfo));
+ get_slabinfo(s, &sinfo);
+
+ if (sinfo.num_objs > 0)
+ pr_info("%-17s %10luKB %10luKB\n", cache_name(s),
+ (sinfo.active_objs * s->size) / 1024,
+ (sinfo.num_objs * s->size) / 1024);
+ }
+ mutex_unlock(&slab_mutex);
+}
+
#if defined(CONFIG_MEMCG) && !defined(CONFIG_SLOB)
void *memcg_slab_start(struct seq_file *m, loff_t *pos)
{
diff -puN mm/slab.h~mm-oom-show-unreclaimable-slab-info-when-unreclaimable-slabs-user-memory mm/slab.h
--- a/mm/slab.h~mm-oom-show-unreclaimable-slab-info-when-unreclaimable-slabs-user-memory
+++ a/mm/slab.h
@@ -505,6 +505,8 @@ void *memcg_slab_next(struct seq_file *m
void memcg_slab_stop(struct seq_file *m, void *p);
int memcg_slab_show(struct seq_file *m, void *p);
+void dump_unreclaimable_slab(void);
+
void ___cache_free(struct kmem_cache *cache, void *x, unsigned long addr);
#ifdef CONFIG_SLAB_FREELIST_RANDOM
_
Patches currently in -mm which might be from yang.s@alibaba-inc.com are
mm-madvise-add-description-for-madv_wipeonfork-and-madv_keeponfork.patch
tools-slabinfo-add-u-option-to-show-unreclaimable-slabs-only.patch
mm-slabinfo-dump-config_slabinfo.patch
mm-oom-show-unreclaimable-slab-info-when-unreclaimable-slabs-user-memory.patch
^ permalink raw reply
* + mm-slabinfo-dump-config_slabinfo.patch added to -mm tree
From: akpm @ 2017-10-04 22:04 UTC (permalink / raw)
To: yang.s, cl, iamjoonsoo.kim, mhocko, penberg, rientjes, mm-commits
The patch titled
Subject: mm: slabinfo: remove CONFIG_SLABINFO
has been added to the -mm tree. Its filename is
mm-slabinfo-dump-config_slabinfo.patch
This patch should soon appear at
http://ozlabs.org/~akpm/mmots/broken-out/mm-slabinfo-dump-config_slabinfo.patch
and later at
http://ozlabs.org/~akpm/mmotm/broken-out/mm-slabinfo-dump-config_slabinfo.patch
Before you just go and hit "reply", please:
a) Consider who else should be cc'ed
b) Prefer to cc a suitable mailing list as well
c) Ideally: find the original patch on the mailing list and do a
reply-to-all to that, adding suitable additional cc's
*** Remember to use Documentation/SubmitChecklist when testing your code ***
The -mm tree is included into linux-next and is updated
there every 3-4 working days
------------------------------------------------------
From: "Yang Shi" <yang.s@alibaba-inc.com>
Subject: mm: slabinfo: remove CONFIG_SLABINFO
According to discussion with Christoph
(https://marc.info/?l=linux-kernel&m=150695909709711&w=2), it sounds like
it is pointless to keep CONFIG_SLABINFO around.
This patch removes the CONFIG_SLABINFO config option, but /proc/slabinfo
is still available.
Link: http://lkml.kernel.org/r/1507152550-46205-3-git-send-email-yang.s@alibaba-inc.com
Signed-off-by: Yang Shi <yang.s@alibaba-inc.com>
Cc: Christoph Lameter <cl@linux.com>
Cc: David Rientjes <rientjes@google.com>
Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
Cc: Michal Hocko <mhocko@kernel.org>
Cc: Pekka Enberg <penberg@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
init/Kconfig | 6 ------
mm/memcontrol.c | 2 --
mm/slab.c | 2 --
mm/slab_common.c | 3 ---
mm/slub.c | 2 --
5 files changed, 15 deletions(-)
diff -puN init/Kconfig~mm-slabinfo-dump-config_slabinfo init/Kconfig
--- a/init/Kconfig~mm-slabinfo-dump-config_slabinfo
+++ a/init/Kconfig
@@ -1657,12 +1657,6 @@ config HAVE_GENERIC_DMA_COHERENT
bool
default n
-config SLABINFO
- bool
- depends on PROC_FS
- depends on SLAB || SLUB_DEBUG
- default y
-
config RT_MUTEXES
bool
diff -puN mm/memcontrol.c~mm-slabinfo-dump-config_slabinfo mm/memcontrol.c
--- a/mm/memcontrol.c~mm-slabinfo-dump-config_slabinfo
+++ a/mm/memcontrol.c
@@ -4049,7 +4049,6 @@ static struct cftype mem_cgroup_legacy_f
.write = mem_cgroup_reset,
.read_u64 = mem_cgroup_read_u64,
},
-#ifdef CONFIG_SLABINFO
{
.name = "kmem.slabinfo",
.seq_start = memcg_slab_start,
@@ -4057,7 +4056,6 @@ static struct cftype mem_cgroup_legacy_f
.seq_stop = memcg_slab_stop,
.seq_show = memcg_slab_show,
},
-#endif
{
.name = "kmem.tcp.limit_in_bytes",
.private = MEMFILE_PRIVATE(_TCP, RES_LIMIT),
diff -puN mm/slab.c~mm-slabinfo-dump-config_slabinfo mm/slab.c
--- a/mm/slab.c~mm-slabinfo-dump-config_slabinfo
+++ a/mm/slab.c
@@ -4096,7 +4096,6 @@ out:
schedule_delayed_work(work, round_jiffies_relative(REAPTIMEOUT_AC));
}
-#ifdef CONFIG_SLABINFO
void get_slabinfo(struct kmem_cache *cachep, struct slabinfo *sinfo)
{
unsigned long active_objs, num_objs, active_slabs;
@@ -4404,7 +4403,6 @@ static int __init slab_proc_init(void)
return 0;
}
module_init(slab_proc_init);
-#endif
#ifdef CONFIG_HARDENED_USERCOPY
/*
diff -puN mm/slab_common.c~mm-slabinfo-dump-config_slabinfo mm/slab_common.c
--- a/mm/slab_common.c~mm-slabinfo-dump-config_slabinfo
+++ a/mm/slab_common.c
@@ -1183,8 +1183,6 @@ void cache_random_seq_destroy(struct kme
}
#endif /* CONFIG_SLAB_FREELIST_RANDOM */
-#ifdef CONFIG_SLABINFO
-
#ifdef CONFIG_SLAB
#define SLABINFO_RIGHTS (S_IWUSR | S_IRUSR)
#else
@@ -1354,7 +1352,6 @@ static int __init slab_proc_init(void)
return 0;
}
module_init(slab_proc_init);
-#endif /* CONFIG_SLABINFO */
static __always_inline void *__do_krealloc(const void *p, size_t new_size,
gfp_t flags)
diff -puN mm/slub.c~mm-slabinfo-dump-config_slabinfo mm/slub.c
--- a/mm/slub.c~mm-slabinfo-dump-config_slabinfo
+++ a/mm/slub.c
@@ -5851,7 +5851,6 @@ __initcall(slab_sysfs_init);
/*
* The /proc/slabinfo ABI
*/
-#ifdef CONFIG_SLABINFO
void get_slabinfo(struct kmem_cache *s, struct slabinfo *sinfo)
{
unsigned long nr_slabs = 0;
@@ -5883,4 +5882,3 @@ ssize_t slabinfo_write(struct file *file
{
return -EIO;
}
-#endif /* CONFIG_SLABINFO */
_
Patches currently in -mm which might be from yang.s@alibaba-inc.com are
mm-madvise-add-description-for-madv_wipeonfork-and-madv_keeponfork.patch
tools-slabinfo-add-u-option-to-show-unreclaimable-slabs-only.patch
mm-slabinfo-dump-config_slabinfo.patch
mm-oom-show-unreclaimable-slab-info-when-unreclaimable-slabs-user-memory.patch
^ permalink raw reply
* + tools-slabinfo-add-u-option-to-show-unreclaimable-slabs-only.patch added to -mm tree
From: akpm @ 2017-10-04 22:04 UTC (permalink / raw)
To: yang.s, cl, iamjoonsoo.kim, mhocko, penberg, rientjes, mm-commits
The patch titled
Subject: tools: slabinfo: add "-U" option to show unreclaimable slabs only
has been added to the -mm tree. Its filename is
tools-slabinfo-add-u-option-to-show-unreclaimable-slabs-only.patch
This patch should soon appear at
http://ozlabs.org/~akpm/mmots/broken-out/tools-slabinfo-add-u-option-to-show-unreclaimable-slabs-only.patch
and later at
http://ozlabs.org/~akpm/mmotm/broken-out/tools-slabinfo-add-u-option-to-show-unreclaimable-slabs-only.patch
Before you just go and hit "reply", please:
a) Consider who else should be cc'ed
b) Prefer to cc a suitable mailing list as well
c) Ideally: find the original patch on the mailing list and do a
reply-to-all to that, adding suitable additional cc's
*** Remember to use Documentation/SubmitChecklist when testing your code ***
The -mm tree is included into linux-next and is updated
there every 3-4 working days
------------------------------------------------------
From: "Yang Shi" <yang.s@alibaba-inc.com>
Subject: tools: slabinfo: add "-U" option to show unreclaimable slabs only
Patch series "oom: capture unreclaimable slab info in oom message", v10.
Recently we ran into a oom issue, kernel panic due to no killable process.
The dmesg shows huge unreclaimable slabs used almost 100% memory, but
kdump doesn't capture vmcore due to some reason.
So, it may sound better to capture unreclaimable slab info in oom message
when kernel panic to aid trouble shooting and cover the corner case.
Since kernel already panic, so capturing more information sounds worthy
and doesn't bother normal oom killer.
With the patchset, tools/vm/slabinfo has a new option, "-U", to show
unreclaimable slab only.
And, oom will print all non zero (num_objs * size != 0) unreclaimable
slabs in oom killer message.
This patch (of 3):
Add "-U" option to show unreclaimable slabs only.
"-U" and "-S" together can tell us what unreclaimable slabs use the most
memory to help debug huge unreclaimable slabs issue.
Link: http://lkml.kernel.org/r/1507152550-46205-2-git-send-email-yang.s@alibaba-inc.com
Signed-off-by: Yang Shi <yang.s@alibaba-inc.com>
Acked-by: Christoph Lameter <cl@linux.com>
Acked-by: David Rientjes <rientjes@google.com>
Cc: Pekka Enberg <penberg@kernel.org>
Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
Cc: Michal Hocko <mhocko@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
tools/vm/slabinfo.c | 11 ++++++++++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff -puN tools/vm/slabinfo.c~tools-slabinfo-add-u-option-to-show-unreclaimable-slabs-only tools/vm/slabinfo.c
--- a/tools/vm/slabinfo.c~tools-slabinfo-add-u-option-to-show-unreclaimable-slabs-only
+++ a/tools/vm/slabinfo.c
@@ -83,6 +83,7 @@ int output_lines = -1;
int sort_loss;
int extended_totals;
int show_bytes;
+int unreclaim_only;
/* Debug options */
int sanity;
@@ -132,6 +133,7 @@ static void usage(void)
"-L|--Loss Sort by loss\n"
"-X|--Xtotals Show extended summary information\n"
"-B|--Bytes Show size in bytes\n"
+ "-U|--Unreclaim Show unreclaimable slabs only\n"
"\nValid debug options (FZPUT may be combined)\n"
"a / A Switch on all debug options (=FZUP)\n"
"- Switch off all debug options\n"
@@ -568,6 +570,9 @@ static void slabcache(struct slabinfo *s
if (strcmp(s->name, "*") == 0)
return;
+ if (unreclaim_only && s->reclaim_account)
+ return;
+
if (actual_slabs == 1) {
report(s);
return;
@@ -1346,6 +1351,7 @@ struct option opts[] = {
{ "Loss", no_argument, NULL, 'L'},
{ "Xtotals", no_argument, NULL, 'X'},
{ "Bytes", no_argument, NULL, 'B'},
+ { "Unreclaim", no_argument, NULL, 'U'},
{ NULL, 0, NULL, 0 }
};
@@ -1357,7 +1363,7 @@ int main(int argc, char *argv[])
page_size = getpagesize();
- while ((c = getopt_long(argc, argv, "aAd::Defhil1noprstvzTSN:LXB",
+ while ((c = getopt_long(argc, argv, "aAd::Defhil1noprstvzTSN:LXBU",
opts, NULL)) != -1)
switch (c) {
case '1':
@@ -1438,6 +1444,9 @@ int main(int argc, char *argv[])
case 'B':
show_bytes = 1;
break;
+ case 'U':
+ unreclaim_only = 1;
+ break;
default:
fatal("%s: Invalid option '%c'\n", argv[0], optopt);
_
Patches currently in -mm which might be from yang.s@alibaba-inc.com are
mm-madvise-add-description-for-madv_wipeonfork-and-madv_keeponfork.patch
tools-slabinfo-add-u-option-to-show-unreclaimable-slabs-only.patch
mm-slabinfo-dump-config_slabinfo.patch
mm-oom-show-unreclaimable-slab-info-when-unreclaimable-slabs-user-memory.patch
^ permalink raw reply
* Re: [PATCH 06/13] drm/i915/cnl: Expose DVFS change functions
From: Manasi Navare @ 2017-10-04 22:07 UTC (permalink / raw)
To: Rodrigo Vivi; +Cc: intel-gfx, Kahola
In-Reply-To: <20171003070614.18396-7-rodrigo.vivi@intel.com>
On Tue, Oct 03, 2017 at 12:06:07AM -0700, Rodrigo Vivi wrote:
> From: "Kahola, Mika" <mika.kahola@intel.com>
>
> DVFS computation needs cnl_dvfs_{pre,post}_change() functions to be exposed.
> These functions will be used when computing DVFS levels in intel_dpll_mgr.c
>
> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
> Signed-off-by: Kahola, Mika <mika.kahola@intel.com>
> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Manasi Navare <manasi.d.navare@intel.com>
Manasi
> ---
> drivers/gpu/drm/i915/intel_cdclk.c | 4 ++--
> drivers/gpu/drm/i915/intel_drv.h | 2 ++
> 2 files changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_cdclk.c b/drivers/gpu/drm/i915/intel_cdclk.c
> index b35eb145d66e..af8411c2a6b9 100644
> --- a/drivers/gpu/drm/i915/intel_cdclk.c
> +++ b/drivers/gpu/drm/i915/intel_cdclk.c
> @@ -1510,7 +1510,7 @@ static void cnl_cdclk_pll_enable(struct drm_i915_private *dev_priv, int vco)
> dev_priv->cdclk.hw.vco = vco;
> }
>
> -static int cnl_dvfs_pre_change(struct drm_i915_private *dev_priv)
> +int cnl_dvfs_pre_change(struct drm_i915_private *dev_priv)
> {
> int ret;
>
> @@ -1528,7 +1528,7 @@ static int cnl_dvfs_pre_change(struct drm_i915_private *dev_priv)
> return ret;
> }
>
> -static void cnl_dvfs_post_change(struct drm_i915_private *dev_priv, int level)
> +void cnl_dvfs_post_change(struct drm_i915_private *dev_priv, int level)
> {
> mutex_lock(&dev_priv->rps.hw_lock);
> sandybridge_pcode_write(dev_priv, SKL_PCODE_CDCLK_CONTROL, level);
> diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
> index fe4650d6db03..934ccf17f8ab 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -1323,6 +1323,8 @@ void skl_init_cdclk(struct drm_i915_private *dev_priv);
> void skl_uninit_cdclk(struct drm_i915_private *dev_priv);
> void cnl_init_cdclk(struct drm_i915_private *dev_priv);
> void cnl_uninit_cdclk(struct drm_i915_private *dev_priv);
> +int cnl_dvfs_pre_change(struct drm_i915_private *dev_priv);
> +void cnl_dvfs_post_change(struct drm_i915_private *dev_priv, int level);
> void bxt_init_cdclk(struct drm_i915_private *dev_priv);
> void bxt_uninit_cdclk(struct drm_i915_private *dev_priv);
> void intel_init_cdclk_hooks(struct drm_i915_private *dev_priv);
> --
> 2.13.5
>
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply
* asn1crypto dependency missing for python-cryptography
From: Satya Bodduluri @ 2017-10-04 22:01 UTC (permalink / raw)
To: openembedded-devel
In versions of python-cryptography >=1.8.x, it includes a dependency for
asn1crypto and removes a dependency on pyasn1 as can be seen with this
commit:
https://github.com/pyca/cryptography/commit/0e6a129724b707ebf79149376251e85fad550414.
As
far as I can tell, asn1crypto isn't included in
meta-openembedded/meta-python.
I've managed to work around this by using an older version of
python-cryptography, but I just wanted to make note of this as it makes
portions of the newer versions of the cryptography library (the master
branch of meta-openembedded is using version 2.0.3 of python-cryptography)
unusable when it can't import asn1crypto. I'm not sure when I'll have time
to create a patch, but I can take a stab at it if no one else beats me.
Thanks,
Satya Bodduluri
^ permalink raw reply
* Re: [PATCH 05/13] drm/i915/cnl: extract cnl_dvfs_{pre, post}_change
From: Manasi Navare @ 2017-10-04 22:05 UTC (permalink / raw)
To: Rodrigo Vivi; +Cc: intel-gfx, Paulo Zanoni
In-Reply-To: <20171003070614.18396-6-rodrigo.vivi@intel.com>
Looks good and this refactoring makes since.
Reviewed-by: Manasi Navare <manasi.d.navare@intel.com>
On Tue, Oct 03, 2017 at 12:06:06AM -0700, Rodrigo Vivi wrote:
> From: Paulo Zanoni <paulo.r.zanoni@intel.com>
>
> These functions even have their own page in our spec,
> so extract them from cnl_set_cdclk().
>
> v2: (By Rodrigo) Fixed inverted logic on error return of
> cnl_dvfs_pre_change.
>
> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
> Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
> ---
> drivers/gpu/drm/i915/intel_cdclk.c | 33 +++++++++++++++++++++++----------
> 1 file changed, 23 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_cdclk.c b/drivers/gpu/drm/i915/intel_cdclk.c
> index 87fc42b19336..b35eb145d66e 100644
> --- a/drivers/gpu/drm/i915/intel_cdclk.c
> +++ b/drivers/gpu/drm/i915/intel_cdclk.c
> @@ -1510,12 +1510,8 @@ static void cnl_cdclk_pll_enable(struct drm_i915_private *dev_priv, int vco)
> dev_priv->cdclk.hw.vco = vco;
> }
>
> -static void cnl_set_cdclk(struct drm_i915_private *dev_priv,
> - const struct intel_cdclk_state *cdclk_state)
> +static int cnl_dvfs_pre_change(struct drm_i915_private *dev_priv)
> {
> - int cdclk = cdclk_state->cdclk;
> - int vco = cdclk_state->vco;
> - u32 val, divider, pcu_ack;
> int ret;
>
> mutex_lock(&dev_priv->rps.hw_lock);
> @@ -1524,11 +1520,30 @@ static void cnl_set_cdclk(struct drm_i915_private *dev_priv,
> SKL_CDCLK_READY_FOR_CHANGE,
> SKL_CDCLK_READY_FOR_CHANGE, 3);
> mutex_unlock(&dev_priv->rps.hw_lock);
> - if (ret) {
> +
> + if (ret)
> DRM_ERROR("Failed to inform PCU about cdclk change (%d)\n",
> ret);
> +
> + return ret;
> +}
> +
> +static void cnl_dvfs_post_change(struct drm_i915_private *dev_priv, int level)
> +{
> + mutex_lock(&dev_priv->rps.hw_lock);
> + sandybridge_pcode_write(dev_priv, SKL_PCODE_CDCLK_CONTROL, level);
> + mutex_unlock(&dev_priv->rps.hw_lock);
> +}
> +
> +static void cnl_set_cdclk(struct drm_i915_private *dev_priv,
> + const struct intel_cdclk_state *cdclk_state)
> +{
> + int cdclk = cdclk_state->cdclk;
> + int vco = cdclk_state->vco;
> + u32 val, divider, pcu_ack;
> +
> + if (cnl_dvfs_pre_change(dev_priv))
> return;
> - }
>
> /* cdclk = vco / 2 / div{1,2} */
> switch (DIV_ROUND_CLOSEST(vco, cdclk)) {
> @@ -1575,9 +1590,7 @@ static void cnl_set_cdclk(struct drm_i915_private *dev_priv,
> I915_WRITE(CDCLK_CTL, val);
>
> /* inform PCU of the change */
> - mutex_lock(&dev_priv->rps.hw_lock);
> - sandybridge_pcode_write(dev_priv, SKL_PCODE_CDCLK_CONTROL, pcu_ack);
> - mutex_unlock(&dev_priv->rps.hw_lock);
> + cnl_dvfs_post_change(dev_priv, pcu_ack);
>
> intel_update_cdclk(dev_priv);
> }
> --
> 2.13.5
>
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply
* [U-Boot] [PATCH v1 08/12] efi_loader: console support for color attributes
From: Heinrich Schuchardt @ 2017-10-04 22:01 UTC (permalink / raw)
To: u-boot
In-Reply-To: <CAF6AEGtM1DH_u8p25XXq3RyjMA2N0n0j6TB61=HS2Oa06KdmZQ@mail.gmail.com>
On 10/04/2017 10:54 PM, Rob Clark wrote:
> On Wed, Oct 4, 2017 at 2:53 PM, Heinrich Schuchardt <xypron.glpk@gmx.de> wrote:
>> On 09/10/2017 03:22 PM, Rob Clark wrote:
>>> Shell.efi uses this, and supporting color attributes makes things look
>>> nicer. Map the EFI fg/bg color attributes to ANSI escape sequences.
>>> Not all colors have a perfect match, but spec just says "Devices
>>> supporting a different number of text colors are required to emulate the
>>> above colors to the best of the device’s capabilities".
>>>
>>> Signed-off-by: Rob Clark <robdclark@gmail.com>
>>> ---
>>> include/efi_api.h | 29 +++++++++++++++++++++++++++++
>>> lib/efi_loader/efi_console.c | 30 ++++++++++++++++++++++++++++++
>>> 2 files changed, 59 insertions(+)
>>>
>>> diff --git a/include/efi_api.h b/include/efi_api.h
>>> index 87c8ffe68e..3cc1dbac2e 100644
>>> --- a/include/efi_api.h
>>> +++ b/include/efi_api.h
>>> @@ -426,6 +426,35 @@ struct simple_text_output_mode {
>>> EFI_GUID(0x387477c2, 0x69c7, 0x11d2, \
>>> 0x8e, 0x39, 0x0, 0xa0, 0xc9, 0x69, 0x72, 0x3b)
>>>
>>> +#define EFI_BLACK 0x00
>>> +#define EFI_BLUE 0x01
>>> +#define EFI_GREEN 0x02
>>> +#define EFI_CYAN 0x03
>>> +#define EFI_RED 0x04
>>> +#define EFI_MAGENTA 0x05
>>> +#define EFI_BROWN 0x06
>>> +#define EFI_LIGHTGRAY 0x07
>>> +#define EFI_BRIGHT 0x08
>>> +#define EFI_DARKGRAY 0x08
>>> +#define EFI_LIGHTBLUE 0x09
>>> +#define EFI_LIGHTGREEN 0x0a
>>> +#define EFI_LIGHTCYAN 0x0b
>>> +#define EFI_LIGHTRED 0x0c
>>> +#define EFI_LIGHTMAGENTA 0x0d
>>> +#define EFI_YELLOW 0x0e
>>> +#define EFI_WHITE 0x0f
>>> +#define EFI_BACKGROUND_BLACK 0x00
>>> +#define EFI_BACKGROUND_BLUE 0x10
>>> +#define EFI_BACKGROUND_GREEN 0x20
>>> +#define EFI_BACKGROUND_CYAN 0x30
>>> +#define EFI_BACKGROUND_RED 0x40
>>> +#define EFI_BACKGROUND_MAGENTA 0x50
>>> +#define EFI_BACKGROUND_BROWN 0x60
>>> +#define EFI_BACKGROUND_LIGHTGRAY 0x70
>>
>> Will we ever use these constants?
>>
>
> possibly not, but it is useful to understand what is going on with
> efi->ansi mapping, so I would prefer to keep them.
>
>>
>> Where are the comments explaining the defines below?
>>
>>> +
>>> +#define EFI_ATTR_FG(attr) ((attr) & 0x0f)
>>
>> This saves 8 entries in the table below.
>> +#define EFI_ATTR_FG(attr) ((attr) & 0x07)
>>
>>> +#define EFI_ATTR_BG(attr) (((attr) >> 4) & 0x7)
>>
>> Add
>> #define EFI_ATTR_BOLD(attr) (((attr) >> 3) & 0x01)
>>
>>> +
>>> struct efi_simple_text_output_protocol {
>>> void *reset;
>>> efi_status_t (EFIAPI *output_string)(
>>> diff --git a/lib/efi_loader/efi_console.c b/lib/efi_loader/efi_console.c
>>> index 2e13fdc096..fcd65ca488 100644
>>> --- a/lib/efi_loader/efi_console.c
>>> +++ b/lib/efi_loader/efi_console.c
>>> @@ -316,12 +316,42 @@ static efi_status_t EFIAPI efi_cout_set_mode(
>>> return EFI_EXIT(EFI_SUCCESS);
>>> }
>>>
>>> +static const struct {
>>> + unsigned fg;
>>> + unsigned bg;
>>> +} color[] = {
>>> + { 30, 40 }, /* 0: black */
>>> + { 34, 44 }, /* 1: blue */
>>> + { 32, 42 }, /* 2: green */
>>> + { 36, 46 }, /* 3: cyan */
>>> + { 31, 41 }, /* 4: red */
>>> + { 35, 45 }, /* 5: magenta */
>>> + { 30, 40 }, /* 6: brown, map to black */
>>
>> This should be { 33, 43 }
>>
>>> + { 37, 47 }, /* 7: light grey, map to white */
>>
>> The entries below are redundant.
>>
>>> + { 37, 47 }, /* 8: bright, map to white */
>>> + { 34, 44 }, /* 9: light blue, map to blue */
>>> + { 32, 42 }, /* A: light green, map to green */
>>> + { 36, 46 }, /* B: light cyan, map to cyan */
>>> + { 31, 41 }, /* C: light red, map to red */
>>> + { 35, 45 }, /* D: light magenta, map to magenta */
>>> + { 33, 43 }, /* E: yellow */
>>> + { 37, 47 }, /* F: white */
>>> +};
>>> +
>
> I'm not totally convinced about mapping extra colors that UEFI defines
> to bold.. unless you have some example of prior-art for this on other
> platforms.
See
Standard ECMA-48 - Control Functions for Coded Character Sets
chapter 8.3.117 SGR - SELECT GRAPHIC RENDITION
1 - bold or increased intensity
22 - normal colour or normal intensity (neither bold nor faint)
You can easily experiment in your bash shell like this:
printf "\x1b[1;32;40m bold \x1b[22;32;40m normal\x1b[22;39;49m\n";
You will find that "bold" prints bold and bright in the KDE konsole and
xterm.
Using colors 90-97 as foreground colors produces only bright but not
bold in the KDE konsole and xterm:
printf "\x1b[92;40m bold \x1b[32;40m normal\x1b[22;39;49m\n";
But these codes are not defined in ECMA-48.
Best regards
Heinrich
^ permalink raw reply
* Re: [PATCH v8 0/2] et/i40e: get information about protocols defined in ddp profile
From: Ferruh Yigit @ 2017-10-04 22:00 UTC (permalink / raw)
To: Kirill Rybalchenko, dev; +Cc: andrey.chilikin, beilei.xing, jingjing.wu
In-Reply-To: <1507125604-32117-1-git-send-email-kirill.rybalchenko@intel.com>
On 10/4/2017 3:00 PM, Kirill Rybalchenko wrote:
> This patch adds ability to request information about protocols defined in dynamic
> device personalization profile
>
> v2:
> Some code style warnings were removed
>
> v3:
> info_size parameter always represents size of the info buffer in bytes;
> fix code style;
>
> v4:
> another code style fixes
>
> v5:
> in testpmd buff_size parameter in rte_pmd_i40e_get_ddp_info function call
> always represents buffer size in bytes
>
> v6:
> fix bug with wrong usage of buff_size parameter
>
> v7:
> change misleading variable names, change order of checking variable
> for zero value
>
> v8:
> Fix code style warnings.
>
> Kirill Rybalchenko (2):
> net/i40e: get information about protocols defined in ddp profile
> app/testpmd: get information about protocols defined in ddp profile
Series Reviewed-by: Ferruh Yigit <ferruh.yigit@intel.com>
^ permalink raw reply
* Re: [PATCH RFC] gpio: of: document gpio-init nodes
From: Uwe Kleine-König @ 2017-10-04 22:00 UTC (permalink / raw)
To: Rob Herring; +Cc: Linus Walleij, Mark Rutland, linux-gpio, devicetree, kernel
In-Reply-To: <20171004205306.wzvxmstcberpws25@rob-hp-laptop>
On Wed, Oct 04, 2017 at 03:53:06PM -0500, Rob Herring wrote:
> On Fri, Sep 22, 2017 at 10:41:38PM +0200, Uwe Kleine-König wrote:
> > Sometimes it is desirable to define a "safe" configuration for a GPIO in
> > the device tree but let the operating system later still make use of
> > this pin.
> >
> > This might for example be useful to initially configure a debug pin that
> > is usually unconnected as output to prevent floating until it is used
> > later.
> >
> > Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
> > ---
> > Hello,
> >
> > this picks up a discussion that pops up now and then with our customers.
> >
> > Last time I discussed this topic with Linus Walleij my suggestion was to
> > merge this usecase with gpio-hogs, but he wasn't happy with it because
> > hogging implies that the pin is not free for other usage and he
> > suggested to use "gpio-init" instead.
> >
> > Maybe it's arguable if this "initial configuration" belongs into the
> > device tree, but IMHO defining a "safe configuration" should have a
> > place and the requirements are identical. This isn't implied by the name
> > however, but I don't have a better idea for a different name.
>
> It can be argued that by the time the kernel boots, it is way to late to
> configure pins to a safe state. Of course, even secure world reads the
> DT these days (or are at least talking about doing so). Still any s/w
> handling this could be too slow to get to a safe state.
Note I didn't target the kernel to implement this. I already have
patches that implement this in barebox which is also using dt. (After
all dt is about hardware description and not about what Linux should do,
right? :-)
> Maybe "optimal default" state would be more accurate.
>
> > Thinking further (which was also discussed last time) it would also be
> > nice to restrict usage. For example that a given pin that has
> > "output-low" as its safe setting might be configured later als high
> > output but not as input. Maybe:
>
> I can't imagine that an output can't be an input.
It might make that line float which I'd consider "unsafe" (or "not
optimal").
> Regardless, what you're describing is constraints and that seems like
> a whole other problem than default/initial state.
>
> Plus, for constraints I'd think we want this done at the pin level, not
> GPIO. And we kind of already have that with pin states.
Not 100% sure I'm up to date here, if you mean
pinctrl-names = "default", "idle"
pinctrl-0 = ... /* that's default */
pinctrl-1 = ... /* that's idle */
this doesn't help completely. If the idle/save state means that the pin
should be configured as low-output, you cannot define that in general.
You can only configure the pin into its gpio function but not say it
should be an output driving the pin low.
> > companion-reset {
> > gpio-somethingwithsafe;
> > gpios = <12 0>;
>
> "gpios" is already a defined property with a type (phandle + args). dtc
> checks for this now though gpio-hogs is already one exception, and I
> don't want to add another. Maybe it could be generalized to be allowed
> when the parent is a gpio-controller, but really I'd like to avoid this
> pattern from spreading.
I choosed the same way as gpio-hogs because IMHO they are quite similar.
Also if the propery is supposed to be located in a child node of a
gpio-controller, repeating &gpioX seems to be at least arguable.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* + makefile-introduce-config_cc_stackprotector_auto-fix-2.patch added to -mm tree
From: akpm @ 2017-10-04 21:59 UTC (permalink / raw)
To: keescook, mm-commits
The patch titled
Subject: makefile-introduce-config_cc_stackprotector_auto-fix-2
has been added to the -mm tree. Its filename is
makefile-introduce-config_cc_stackprotector_auto-fix-2.patch
This patch should soon appear at
http://ozlabs.org/~akpm/mmots/broken-out/makefile-introduce-config_cc_stackprotector_auto-fix-2.patch
and later at
http://ozlabs.org/~akpm/mmotm/broken-out/makefile-introduce-config_cc_stackprotector_auto-fix-2.patch
Before you just go and hit "reply", please:
a) Consider who else should be cc'ed
b) Prefer to cc a suitable mailing list as well
c) Ideally: find the original patch on the mailing list and do a
reply-to-all to that, adding suitable additional cc's
*** Remember to use Documentation/SubmitChecklist when testing your code ***
The -mm tree is included into linux-next and is updated
there every 3-4 working days
------------------------------------------------------
From: Kees Cook <keescook@chromium.org>
Subject: makefile-introduce-config_cc_stackprotector_auto-fix-2
special-case gcc-4.4.4
Link: http://lkml.kernel.org/r/CAGXu5jLg69y3ic7MbzUqb=SM+miqy2KYxBkrYdx9mq_N+aUicA@mail.gmail.com
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
Makefile | 8 ++++++++
1 file changed, 8 insertions(+)
diff -puN Makefile~makefile-introduce-config_cc_stackprotector_auto-fix-2 Makefile
--- a/Makefile~makefile-introduce-config_cc_stackprotector_auto-fix-2
+++ a/Makefile
@@ -1107,8 +1107,16 @@ endif
# Make sure compiler does not have buggy stack-protector support.
ifdef stackp-check
ifneq ($(shell $(CONFIG_SHELL) $(stackp-check) $(CC) $(KBUILD_CPPFLAGS) $(biarch)),y)
+ # The stack-protector is known-broken on gcc 4.4. In AUTO mode, this
+ # can just be a warning. Any breakage in other compilers should still
+ # abort the build, as that would be unexpected.
+ ifeq ($(call cc-ifversion, -eq, 0404,$(stackp-name)),AUTO)
+ @echo CONFIG_CC_STACKPROTECTOR_$(stackp-name): \
+ $(stackp-flag) available but compiler is broken >&2
+ else
@echo Cannot use CONFIG_CC_STACKPROTECTOR_$(stackp-name): \
$(stackp-flag) available but compiler is broken >&2 && exit 1
+ endif
endif
endif
@:
_
Patches currently in -mm which might be from keescook@chromium.org are
sh-boot-add-static-stack-protector-to-pre-kernel.patch
makefile-move-stackprotector-availability-out-of-kconfig.patch
makefile-introduce-config_cc_stackprotector_auto.patch
makefile-introduce-config_cc_stackprotector_auto-fix.patch
makefile-introduce-config_cc_stackprotector_auto-fix-2.patch
^ permalink raw reply
* Re: [PATCH 05/13] drm/i915/cnl: extract cnl_dvfs_{pre, post}_change
From: Ausmus, James @ 2017-10-04 21:58 UTC (permalink / raw)
To: Rodrigo Vivi; +Cc: Intel GFX, Paulo Zanoni
In-Reply-To: <20171003070614.18396-6-rodrigo.vivi@intel.com>
On Tue, Oct 3, 2017 at 12:06 AM, Rodrigo Vivi <rodrigo.vivi@intel.com> wrote:
> From: Paulo Zanoni <paulo.r.zanoni@intel.com>
>
> These functions even have their own page in our spec,
> so extract them from cnl_set_cdclk().
>
> v2: (By Rodrigo) Fixed inverted logic on error return of
> cnl_dvfs_pre_change.
>
> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
> Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: James Ausmus <james.ausmus@intel.com>
> ---
> drivers/gpu/drm/i915/intel_cdclk.c | 33 +++++++++++++++++++++++----------
> 1 file changed, 23 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_cdclk.c b/drivers/gpu/drm/i915/intel_cdclk.c
> index 87fc42b19336..b35eb145d66e 100644
> --- a/drivers/gpu/drm/i915/intel_cdclk.c
> +++ b/drivers/gpu/drm/i915/intel_cdclk.c
> @@ -1510,12 +1510,8 @@ static void cnl_cdclk_pll_enable(struct drm_i915_private *dev_priv, int vco)
> dev_priv->cdclk.hw.vco = vco;
> }
>
> -static void cnl_set_cdclk(struct drm_i915_private *dev_priv,
> - const struct intel_cdclk_state *cdclk_state)
> +static int cnl_dvfs_pre_change(struct drm_i915_private *dev_priv)
> {
> - int cdclk = cdclk_state->cdclk;
> - int vco = cdclk_state->vco;
> - u32 val, divider, pcu_ack;
> int ret;
>
> mutex_lock(&dev_priv->rps.hw_lock);
> @@ -1524,11 +1520,30 @@ static void cnl_set_cdclk(struct drm_i915_private *dev_priv,
> SKL_CDCLK_READY_FOR_CHANGE,
> SKL_CDCLK_READY_FOR_CHANGE, 3);
> mutex_unlock(&dev_priv->rps.hw_lock);
> - if (ret) {
> +
> + if (ret)
> DRM_ERROR("Failed to inform PCU about cdclk change (%d)\n",
> ret);
> +
> + return ret;
> +}
> +
> +static void cnl_dvfs_post_change(struct drm_i915_private *dev_priv, int level)
> +{
> + mutex_lock(&dev_priv->rps.hw_lock);
> + sandybridge_pcode_write(dev_priv, SKL_PCODE_CDCLK_CONTROL, level);
> + mutex_unlock(&dev_priv->rps.hw_lock);
> +}
> +
> +static void cnl_set_cdclk(struct drm_i915_private *dev_priv,
> + const struct intel_cdclk_state *cdclk_state)
> +{
> + int cdclk = cdclk_state->cdclk;
> + int vco = cdclk_state->vco;
> + u32 val, divider, pcu_ack;
> +
> + if (cnl_dvfs_pre_change(dev_priv))
> return;
> - }
>
> /* cdclk = vco / 2 / div{1,2} */
> switch (DIV_ROUND_CLOSEST(vco, cdclk)) {
> @@ -1575,9 +1590,7 @@ static void cnl_set_cdclk(struct drm_i915_private *dev_priv,
> I915_WRITE(CDCLK_CTL, val);
>
> /* inform PCU of the change */
> - mutex_lock(&dev_priv->rps.hw_lock);
> - sandybridge_pcode_write(dev_priv, SKL_PCODE_CDCLK_CONTROL, pcu_ack);
> - mutex_unlock(&dev_priv->rps.hw_lock);
> + cnl_dvfs_post_change(dev_priv, pcu_ack);
>
> intel_update_cdclk(dev_priv);
> }
> --
> 2.13.5
>
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
James Ausmus
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply
* RE: [kernel-hardening] [RFC V2 0/6] add more kernel pointer filter options
From: Roberts, William C @ 2017-10-04 21:58 UTC (permalink / raw)
To: Linus Torvalds, Jordan Glover
Cc: Tobin C. Harding, Greg KH, Petr Mladek, Joe Perches, Ian Campbell,
Sergey Senozhatsky, kernel-hardening@lists.openwall.com,
Catalin Marinas, Will Deacon, Steven Rostedt, Chris Fries,
Dave Weinstein
In-Reply-To: <CA+55aFzGsRFPtMFRv3G0FPNs6YAD3S2U94o58Lgg1MnmHwCxvA@mail.gmail.com>
> -----Original Message-----
> From: linus971@gmail.com [mailto:linus971@gmail.com] On Behalf Of Linus
> Torvalds
> Sent: Wednesday, October 4, 2017 12:19 PM
> To: Jordan Glover <Golden_Miller83@protonmail.ch>
> Cc: Tobin C. Harding <me@tobin.cc>; Greg KH <gregkh@linuxfoundation.org>;
> Petr Mladek <pmladek@suse.com>; Joe Perches <joe@perches.com>; Ian
> Campbell <ijc@hellion.org.uk>; Sergey Senozhatsky
> <sergey.senozhatsky@gmail.com>; kernel-hardening@lists.openwall.com;
> Catalin Marinas <catalin.marinas@arm.com>; Will Deacon
> <will.deacon@arm.com>; Steven Rostedt <rostedt@goodmis.org>; Roberts,
> William C <william.c.roberts@intel.com>; Chris Fries <cfries@google.com>; Dave
> Weinstein <olorin@google.com>
> Subject: Re: [kernel-hardening] [RFC V2 0/6] add more kernel pointer filter
> options
>
> On Wed, Oct 4, 2017 at 11:58 AM, Jordan Glover
> <Golden_Miller83@protonmail.ch> wrote:
> > If we knew where those leaks are hiding they will be fixed already.
> > The only thing we knew is that bugs/leaks are there. It's always
> > better to just fix all the code but it isn't realistic.
>
> Honestly, what's the difference between setting kptr_restrict to 4 and just using
> a sed-script (or maybe some coccinelle) to remove all existing plain %p users?
I can already see the hate filled irate response I'll get to this statement, thankfully I will
be away not caring.
The kernel proper is in a place where it can attempt to defend itself against stupidity, either in
tree or out of tree. Will it stop everything? Obviously not, like you said %x or disabling.
I agree with you 100% kptr restrict is odd, and I don't think anyone should have had to opt in to be
cleansed via kptr_restrict value via %pK. Opt-in never works. One nice thing now, is that checkpatch
has checking of %p usages and warns.
As far as broken things, I can't comment on desktop systems where I think it's harder to make that claim.
I see value in embedded systems where I am shipping the whole image, So I know when/what will
break.
If this was in-tree, Android would be setting this to 4 immediately FWIW.
>
> One just hides the issue and will make people work around it (likely on a global
> level by just undoing it).
>
> The other would *also* make people work around it for when they notice
> breakage, but would actually force people to do it on a case-by-case basis (and
> thus hopefully _properly_) rather than just setting kptr_restrict back to 0.
>
> Btw, this is *not* a theoretical argument.
>
> WE HAVE BEEN HERE, DONE THIS!
>
> kptr_restrict goes back to 6+ years ago, and was actually initially set to a
> restrictive value. It got undone, exactly because it caused problems. It's too big of
> a hammer, and it's too *broken* of a hammer.
>
> And exactly because kptr_restrict was pretty much an "all or nothing"
> thing, absolutely *NOTHING* has improved in the 6+ years since it was
> introduced.
>
> We have had improvements in our pointer printing that were _not_ related to
> kptr_restrict, though, See for example commit bb5e5ce545f2
> ("x86/dumpstack: Remove kernel text addresses from stack dump").
>
> Those have actually been _real_ fixes for leaking things, unlike kptr_restrict.
>
> This is why I maintain that kptr_restrict is bad. It's a badly thought out interface.
> It's wrong.
>
> We know it is crap, exactly because we've already been there. The whole notion
> of a global switch is seriously mis-designed.
>
> So I really do think that it would be better to just write a script to get rid of all raw
> %p users, and then put the ones that are needed (hopefully very few) back.
>
> It wouldn't require odd new magic sequences to override "I actually _do_ want
> %p".
>
> Linus
^ permalink raw reply
* Re: [RFC] bpf: remove global verifier state
From: Jakub Kicinski @ 2017-10-04 21:57 UTC (permalink / raw)
To: Daniel Borkmann
Cc: Alexei Starovoitov, Eric Dumazet, dsahern, netdev, oss-drivers,
david.beckett
In-Reply-To: <59D532EB.4000104@iogearbox.net>
On Wed, 04 Oct 2017 21:13:47 +0200, Daniel Borkmann wrote:
> On 10/04/2017 05:43 AM, Alexei Starovoitov wrote:
> > On Tue, Oct 03, 2017 at 08:24:06PM -0700, Eric Dumazet wrote:
> >> On Tue, 2017-10-03 at 19:52 -0700, Alexei Starovoitov wrote:
> >>
> >>> yep. looks great.
> >>> Please test it and submit officially :)
> >>> The commit aafe6ae9cee3 ("bpf: dynamically allocate digest scratch buffer")
> >>> fixed the other case where we were relying on the above mutex.
> >>> The only other spot to be adjusted is to add spin_lock/mutex or DO_ONCE() to
> >>> bpf_get_skb_set_tunnel_proto() to protect md_dst init.
> >>> imo that would be it.
> >>> Daniel, anything else comes to mind?
>
> Yes, this should be all. DO_ONCE() for the tunnel proto seems a
> good choice.
Hm. I actually did:
if (!dst) {
tmp = alloc();
if (!tmp)
return;
if (cmpxchg(&dst, NULL, tmp))
free(tmp);
}
I don't like how DO_ONCE() doesn't handle errors from the init
function :(
> >> 16 MB of log (unswappable kernel memory) per active checker.
> >>
> >> We might offer a way to oom hosts.
> >
> > right. good point!
> > we need to switch to continuous copy_to_user() after a page or so.
> > Can even do it after every vscnprintf()
> > but page at a time is probably faster.
>
> Also worst case upper limits on verification side for holding state
> aside from the log would need to be checked in terms of how much mem
> we end up holding that is not accounted against any process (and not
> really "rate-limited" anymore once we drop the mutex).
^ permalink raw reply
* [PATCH tip/core/rcu 3/3] torture: Provide TMPDIR environment variable to specify tmpdir
From: Paul E. McKenney @ 2017-10-04 21:56 UTC (permalink / raw)
To: linux-kernel
Cc: mingo, jiangshanlai, dipankar, akpm, mathieu.desnoyers, josh,
tglx, peterz, rostedt, dhowells, edumazet, fweisbec, oleg,
Paul E. McKenney
In-Reply-To: <20171004215609.GA14782@linux.vnet.ibm.com>
Both rcutorture and locktorture currently place temporary files in /tmp,
in keeping with decades-long tradition. However, sometimes it is useful
to specify an alternative temporary directory, for example, for space
or performance reasons. This commit therefore causes the torture-test
scripting to use the path specified in the TMPDIR environment variable,
or to fall back to traditional /tmp if this variable is not set.
Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
---
tools/testing/selftests/rcutorture/bin/config_override.sh | 2 +-
tools/testing/selftests/rcutorture/bin/configcheck.sh | 2 +-
tools/testing/selftests/rcutorture/bin/configinit.sh | 2 +-
tools/testing/selftests/rcutorture/bin/kvm-build.sh | 2 +-
tools/testing/selftests/rcutorture/bin/kvm-test-1-run.sh | 2 +-
tools/testing/selftests/rcutorture/bin/kvm.sh | 4 ++--
tools/testing/selftests/rcutorture/bin/parse-build.sh | 2 +-
tools/testing/selftests/rcutorture/bin/parse-torture.sh | 2 +-
8 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/tools/testing/selftests/rcutorture/bin/config_override.sh b/tools/testing/selftests/rcutorture/bin/config_override.sh
index 49fa51726ce3..ef7fcbac3d42 100755
--- a/tools/testing/selftests/rcutorture/bin/config_override.sh
+++ b/tools/testing/selftests/rcutorture/bin/config_override.sh
@@ -42,7 +42,7 @@ else
exit 1
fi
-T=/tmp/config_override.sh.$$
+T=${TMPDIR-/tmp}/config_override.sh.$$
trap 'rm -rf $T' 0
mkdir $T
diff --git a/tools/testing/selftests/rcutorture/bin/configcheck.sh b/tools/testing/selftests/rcutorture/bin/configcheck.sh
index 70fca318a82b..197deece7c7c 100755
--- a/tools/testing/selftests/rcutorture/bin/configcheck.sh
+++ b/tools/testing/selftests/rcutorture/bin/configcheck.sh
@@ -19,7 +19,7 @@
#
# Authors: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
-T=/tmp/abat-chk-config.sh.$$
+T=${TMPDIR-/tmp}/abat-chk-config.sh.$$
trap 'rm -rf $T' 0
mkdir $T
diff --git a/tools/testing/selftests/rcutorture/bin/configinit.sh b/tools/testing/selftests/rcutorture/bin/configinit.sh
index 3f81a1095206..51f66a7ce876 100755
--- a/tools/testing/selftests/rcutorture/bin/configinit.sh
+++ b/tools/testing/selftests/rcutorture/bin/configinit.sh
@@ -32,7 +32,7 @@
#
# Authors: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
-T=/tmp/configinit.sh.$$
+T=${TMPDIR-/tmp}/configinit.sh.$$
trap 'rm -rf $T' 0
mkdir $T
diff --git a/tools/testing/selftests/rcutorture/bin/kvm-build.sh b/tools/testing/selftests/rcutorture/bin/kvm-build.sh
index 46752c164676..fb66d0173638 100755
--- a/tools/testing/selftests/rcutorture/bin/kvm-build.sh
+++ b/tools/testing/selftests/rcutorture/bin/kvm-build.sh
@@ -35,7 +35,7 @@ then
exit 1
fi
-T=/tmp/test-linux.sh.$$
+T=${TMPDIR-/tmp}/test-linux.sh.$$
trap 'rm -rf $T' 0
mkdir $T
diff --git a/tools/testing/selftests/rcutorture/bin/kvm-test-1-run.sh b/tools/testing/selftests/rcutorture/bin/kvm-test-1-run.sh
index 0af36a721b9c..ab14b97c942c 100755
--- a/tools/testing/selftests/rcutorture/bin/kvm-test-1-run.sh
+++ b/tools/testing/selftests/rcutorture/bin/kvm-test-1-run.sh
@@ -38,7 +38,7 @@
#
# Authors: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
-T=/tmp/kvm-test-1-run.sh.$$
+T=${TMPDIR-/tmp}/kvm-test-1-run.sh.$$
trap 'rm -rf $T' 0
mkdir $T
diff --git a/tools/testing/selftests/rcutorture/bin/kvm.sh b/tools/testing/selftests/rcutorture/bin/kvm.sh
index b55895fb10ed..ccd49e958fd2 100755
--- a/tools/testing/selftests/rcutorture/bin/kvm.sh
+++ b/tools/testing/selftests/rcutorture/bin/kvm.sh
@@ -30,7 +30,7 @@
scriptname=$0
args="$*"
-T=/tmp/kvm.sh.$$
+T=${TMPDIR-/tmp}/kvm.sh.$$
trap 'rm -rf $T' 0
mkdir $T
@@ -222,7 +222,7 @@ do
exit 1
fi
done
-sort -k2nr $T/cfgcpu > $T/cfgcpu.sort
+sort -k2nr $T/cfgcpu -T="$T" > $T/cfgcpu.sort
# Use a greedy bin-packing algorithm, sorting the list accordingly.
awk < $T/cfgcpu.sort > $T/cfgcpu.pack -v ncpus=$cpus '
diff --git a/tools/testing/selftests/rcutorture/bin/parse-build.sh b/tools/testing/selftests/rcutorture/bin/parse-build.sh
index a6b57622c2e5..24fe5f822b28 100755
--- a/tools/testing/selftests/rcutorture/bin/parse-build.sh
+++ b/tools/testing/selftests/rcutorture/bin/parse-build.sh
@@ -28,7 +28,7 @@
F=$1
title=$2
-T=/tmp/parse-build.sh.$$
+T=${TMPDIR-/tmp}/parse-build.sh.$$
trap 'rm -rf $T' 0
mkdir $T
diff --git a/tools/testing/selftests/rcutorture/bin/parse-torture.sh b/tools/testing/selftests/rcutorture/bin/parse-torture.sh
index e3c5f0705696..f12c38909b00 100755
--- a/tools/testing/selftests/rcutorture/bin/parse-torture.sh
+++ b/tools/testing/selftests/rcutorture/bin/parse-torture.sh
@@ -27,7 +27,7 @@
#
# Authors: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
-T=/tmp/parse-torture.sh.$$
+T=${TMPDIR-/tmp}/parse-torture.sh.$$
file="$1"
title="$2"
--
2.5.2
^ permalink raw reply related
* [PATCH tip/core/rcu 1/3] rcutorture: Add interrupt-disable capability to stall-warning tests
From: Paul E. McKenney @ 2017-10-04 21:56 UTC (permalink / raw)
To: linux-kernel
Cc: mingo, jiangshanlai, dipankar, akpm, mathieu.desnoyers, josh,
tglx, peterz, rostedt, dhowells, edumazet, fweisbec, oleg,
Paul E. McKenney
In-Reply-To: <20171004215609.GA14782@linux.vnet.ibm.com>
When rcutorture sees the rcutorture.stall_cpu kernel boot parameter,
it loops with preemption disabled, which does in fact normally
generate an RCU CPU stall warning message. However, there are test
scenarios that need the stalling CPU to have interrupts disabled.
This commit therefore adds an rcutorture.stall_cpu_irqsoff kernel
boot parameter that causes the stalling CPU to disable interrupts.
Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
---
Documentation/admin-guide/kernel-parameters.txt | 3 +++
kernel/rcu/rcutorture.c | 18 +++++++++++++-----
2 files changed, 16 insertions(+), 5 deletions(-)
diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
index 05496622b4ef..bc94c47085a5 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -3539,6 +3539,9 @@
rcutorture.stall_cpu_holdoff= [KNL]
Time to wait (s) after boot before inducing stall.
+ rcutorture.stall_cpu_irqsoff= [KNL]
+ Disable interrupts while stalling if set.
+
rcutorture.stat_interval= [KNL]
Time (s) between statistics printk()s.
diff --git a/kernel/rcu/rcutorture.c b/kernel/rcu/rcutorture.c
index 45f2ffbc1e78..0273bc0a8586 100644
--- a/kernel/rcu/rcutorture.c
+++ b/kernel/rcu/rcutorture.c
@@ -89,6 +89,7 @@ torture_param(int, shutdown_secs, 0, "Shutdown time (s), <= zero to disable.");
torture_param(int, stall_cpu, 0, "Stall duration (s), zero to disable.");
torture_param(int, stall_cpu_holdoff, 10,
"Time to wait before starting stall (s).");
+torture_param(int, stall_cpu_irqsoff, 0, "Disable interrupts while stalling.");
torture_param(int, stat_interval, 60,
"Number of seconds between stats printk()s");
torture_param(int, stutter, 5, "Number of seconds to run/halt test");
@@ -1357,7 +1358,7 @@ rcu_torture_print_module_parms(struct rcu_torture_ops *cur_ops, const char *tag)
"fqs_duration=%d fqs_holdoff=%d fqs_stutter=%d "
"test_boost=%d/%d test_boost_interval=%d "
"test_boost_duration=%d shutdown_secs=%d "
- "stall_cpu=%d stall_cpu_holdoff=%d "
+ "stall_cpu=%d stall_cpu_holdoff=%d stall_cpu_irqsoff=%d "
"n_barrier_cbs=%d "
"onoff_interval=%d onoff_holdoff=%d\n",
torture_type, tag, nrealreaders, nfakewriters,
@@ -1365,7 +1366,7 @@ rcu_torture_print_module_parms(struct rcu_torture_ops *cur_ops, const char *tag)
stutter, irqreader, fqs_duration, fqs_holdoff, fqs_stutter,
test_boost, cur_ops->can_boost,
test_boost_interval, test_boost_duration, shutdown_secs,
- stall_cpu, stall_cpu_holdoff,
+ stall_cpu, stall_cpu_holdoff, stall_cpu_irqsoff,
n_barrier_cbs,
onoff_interval, onoff_holdoff);
}
@@ -1430,12 +1431,19 @@ static int rcu_torture_stall(void *args)
if (!kthread_should_stop()) {
stop_at = get_seconds() + stall_cpu;
/* RCU CPU stall is expected behavior in following code. */
- pr_alert("rcu_torture_stall start.\n");
rcu_read_lock();
- preempt_disable();
+ if (stall_cpu_irqsoff)
+ local_irq_disable();
+ else
+ preempt_disable();
+ pr_alert("rcu_torture_stall start on CPU %d.\n",
+ smp_processor_id());
while (ULONG_CMP_LT(get_seconds(), stop_at))
continue; /* Induce RCU CPU stall warning. */
- preempt_enable();
+ if (stall_cpu_irqsoff)
+ local_irq_enable();
+ else
+ preempt_enable();
rcu_read_unlock();
pr_alert("rcu_torture_stall end.\n");
}
--
2.5.2
^ permalink raw reply related
* [PATCH tip/core/rcu 2/3] rcutorture: Dump writer stack if stalled
From: Paul E. McKenney @ 2017-10-04 21:56 UTC (permalink / raw)
To: linux-kernel
Cc: mingo, jiangshanlai, dipankar, akpm, mathieu.desnoyers, josh,
tglx, peterz, rostedt, dhowells, edumazet, fweisbec, oleg,
Paul E. McKenney
In-Reply-To: <20171004215609.GA14782@linux.vnet.ibm.com>
Right now, rcutorture warns if an rcu_torture_writer() kthread stalls,
but this warning is not always all that helpful. This commit therefore
makes the first such warning include a stack dump.
This in turn requires that sched_show_task() be exported to GPL modules,
so this commit makes that change as well.
Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
---
kernel/rcu/rcutorture.c | 6 ++++++
kernel/sched/core.c | 1 +
2 files changed, 7 insertions(+)
diff --git a/kernel/rcu/rcutorture.c b/kernel/rcu/rcutorture.c
index 0273bc0a8586..362eb2f78b3c 100644
--- a/kernel/rcu/rcutorture.c
+++ b/kernel/rcu/rcutorture.c
@@ -51,6 +51,7 @@
#include <asm/byteorder.h>
#include <linux/torture.h>
#include <linux/vmalloc.h>
+#include <linux/sched/debug.h>
#include "rcu.h"
@@ -1240,6 +1241,7 @@ rcu_torture_stats_print(void)
long pipesummary[RCU_TORTURE_PIPE_LEN + 1] = { 0 };
long batchsummary[RCU_TORTURE_PIPE_LEN + 1] = { 0 };
static unsigned long rtcv_snap = ULONG_MAX;
+ static bool splatted;
struct task_struct *wtp;
for_each_possible_cpu(cpu) {
@@ -1325,6 +1327,10 @@ rcu_torture_stats_print(void)
gpnum, completed, flags,
wtp == NULL ? ~0UL : wtp->state,
wtp == NULL ? -1 : (int)task_cpu(wtp));
+ if (!splatted && wtp) {
+ sched_show_task(wtp);
+ splatted = true;
+ }
show_rcu_gp_kthreads();
rcu_ftrace_dump(DUMP_ALL);
}
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index d17c5da523a0..7ae0151dcc1d 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -5165,6 +5165,7 @@ void sched_show_task(struct task_struct *p)
show_stack(p, NULL);
put_task_stack(p);
}
+EXPORT_SYMBOL_GPL(sched_show_task);
static inline bool
state_filter_match(unsigned long state_filter, struct task_struct *p)
--
2.5.2
^ permalink raw reply related
* Re: Kernel 4.13 is broken on m68k
From: John Paul Adrian Glaubitz @ 2017-10-04 21:56 UTC (permalink / raw)
To: Linux/m68k; +Cc: Debian m68k
In-Reply-To: <9f2342b1-af46-27e9-e38d-9485d1719c07@physik.fu-berlin.de>
On 10/04/2017 11:49 PM, John Paul Adrian Glaubitz wrote:
> I can trigger the problem by switching between 4.12 and 4.13, 4.12 is fin while 4.13 is broken.
Ok, switching just the initrd to the one from 4.13 while keeping the 4.12 kernel
image results in the same crash. Maybe the glibc is broken?
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaubitz@debian.org
`. `' Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
^ permalink raw reply
* [PATCH tip/core/rcu 0/3] Torture-test update for v4.15
From: Paul E. McKenney @ 2017-10-04 21:56 UTC (permalink / raw)
To: linux-kernel
Cc: mingo, jiangshanlai, dipankar, akpm, mathieu.desnoyers, josh,
tglx, peterz, rostedt, dhowells, edumazet, fweisbec, oleg
Hello!
This series contains torture-test updates:
1. Add interrupt-disable capability to stall-warning tests.
2. Dump writer stack if rcutorture writer kthread is stalled.
3. Provide TMPDIR environment variable to specify temporary
directory in order to run rcutorture on oddly configured
systems.
Thanx, Paul
------------------------------------------------------------------------
Documentation/admin-guide/kernel-parameters.txt | 3 +
kernel/rcu/rcutorture.c | 24 +++++++++++---
kernel/sched/core.c | 1
tools/testing/selftests/rcutorture/bin/config_override.sh | 2 -
tools/testing/selftests/rcutorture/bin/configcheck.sh | 2 -
tools/testing/selftests/rcutorture/bin/configinit.sh | 2 -
tools/testing/selftests/rcutorture/bin/kvm-build.sh | 2 -
tools/testing/selftests/rcutorture/bin/kvm-test-1-run.sh | 2 -
tools/testing/selftests/rcutorture/bin/kvm.sh | 4 +-
tools/testing/selftests/rcutorture/bin/parse-build.sh | 2 -
tools/testing/selftests/rcutorture/bin/parse-torture.sh | 2 -
11 files changed, 32 insertions(+), 14 deletions(-)
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.