* Re: [PATCH v1 1/2] config.mak.in: set NO_OPENSSL and APPLE_COMMON_CRYPTO for macOS >10.11
From: Torsten Bögershausen @ 2016-11-09 10:51 UTC (permalink / raw)
To: Lars Schneider; +Cc: Jeff King, git, gitster
In-Reply-To: <0966CBE3-2F08-4B89-9716-4EEE3CE2526E@gmail.com>
On 09.11.16 10:29, Lars Schneider wrote:
>
>> On 09 Nov 2016, at 09:18, Torsten Bögershausen <tboegi@web.de> wrote:
>>
>> On 07.11.16 18:26, Jeff King wrote:
>>> On Sun, Nov 06, 2016 at 08:35:04PM +0100, Lars Schneider wrote:
>>>
>>>> Good point. I think I found an even easier way to achieve the same.
>>>> What do you think about the patch below?
>>>>
>>>> [...]
>>>>
>>>> diff --git a/Makefile b/Makefile
>>>> index 9d6c245..f53fcc9 100644
>>>> --- a/Makefile
>>>> +++ b/Makefile
>>>> @@ -1047,6 +1047,7 @@ ifeq ($(uname_S),Darwin)
>>>> endif
>>>> endif
>>>> ifndef NO_APPLE_COMMON_CRYPTO
>>>> + NO_OPENSSL = YesPlease
>>>> APPLE_COMMON_CRYPTO = YesPlease
>>>> COMPAT_CFLAGS += -DAPPLE_COMMON_CRYPTO
>>>> endif
>>>
>>> That is much simpler.
>> []
>> I don't know if that is a correct solution.
>>
>> If I have Mac OS 10.12 and Mac Ports installed, I may want to use
>> OPENSSL from Mac Ports.
>
> Can't you define `NO_APPLE_COMMON_CRYPTO` in that case?
> I think if you use OpenSSL then you don't need the Apple crypto lib, right?
After re-reading the Makefile: that makes sense :-)
Do you want to send a new patch ?
Feel free to omit
"Original-patch-by: Torsten Bögershausen <tboegi@web.de>"
^ permalink raw reply
* Re: [PATCH net-next 1/2] bpf, mlx4: fix prog refcount in mlx4_en_try_alloc_resources error path
From: kbuild test robot @ 2016-11-09 10:58 UTC (permalink / raw)
To: Daniel Borkmann
Cc: kbuild-all-JC7UmRfGjtg, Zhiyi Sun, bblanco-uqk4Ao+rVK5Wk0Htik3J/w,
Tariq Toukan, Yishai Hadas, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-rdma-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
alexei.starovoitov-Re5JQEeQqe8AvxtiuMwx3w
In-Reply-To: <5822F30C.1050900-FeC+5ew28dpmcu3hnIyYJQ@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 1365 bytes --]
Hi Daniel,
[auto build test ERROR on net-next/master]
url: https://github.com/0day-ci/linux/commits/Daniel-Borkmann/bpf-mlx4-fix-prog-refcount-in-mlx4_en_try_alloc_resources-error-path/20161109-182712
config: x86_64-acpi-redef (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
All errors (new ones prefixed by >>):
drivers/net/ethernet/mellanox/mlx4/en_netdev.c: In function 'mlx4_xdp_set':
>> drivers/net/ethernet/mellanox/mlx4/en_netdev.c:2752:4: error: implicit declaration of function 'bpf_prog_add_undo' [-Werror=implicit-function-declaration]
bpf_prog_add_undo(prog, priv->rx_ring_num - 1);
^~~~~~~~~~~~~~~~~
cc1: some warnings being treated as errors
vim +/bpf_prog_add_undo +2752 drivers/net/ethernet/mellanox/mlx4/en_netdev.c
2746 en_warn(priv, "Reducing the number of TX rings, to not exceed the max total rings number.\n");
2747 }
2748
2749 err = mlx4_en_try_alloc_resources(priv, tmp, &new_prof);
2750 if (err) {
2751 if (prog)
> 2752 bpf_prog_add_undo(prog, priv->rx_ring_num - 1);
2753 goto unlock_out;
2754 }
2755
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 28646 bytes --]
^ permalink raw reply
* Re: [Qemu-devel] virtIO question
From: zhunxun @ 2016-11-09 10:58 UTC (permalink / raw)
To: jkhasdev, qemu
In-Reply-To: <CAN-6CVkOBYwGkJj2FcS4pn2amm6k6KBLJa_FNPaPRAiYn0n_DA@mail.gmail.com>
I want to ask a another question,why a virt_queue in virtio include in_sgs and out_sgs,for example,send_queue of virtIO net driver have in_sgs and out_sgs，when transmit data,It add buffer to out_sgs of send_queue,but how it to use in_sgs??
zhunxun@gmail.com
From: jitendra kumar khasdev
Date: 2016-11-05 23:41
To: Peter Maydell
CC: zhunxun@gmail.com; qemu-devel
Subject: Re: [Qemu-devel] virtIO question
Have you looked at the virtio specification?
No.
This describes
the overall structure and communication mechanism, which
QEMU and Linux each only implement one half of:
http://docs.oasis-open.org/virtio/virtio/v1.0/virtio-v1.0.html
Thanks Peter. This doc looks me interesting.
---
Jitendra
^ permalink raw reply
* [Buildroot] [PATCH] infra: fix striping of ld.so and libpthread
From: Jérôme Pouiller @ 2016-11-09 10:57 UTC (permalink / raw)
To: buildroot
If 'lib' is a symlink, 'find lib' does not return correct result. So, until now,
libpthread*.so* and ld-*.so* was not stripped when 'lib' was a symlink.
We fix tit by using 'find lib/' instead of 'find lib'
Signed-off-by: J?r?me Pouiller <jezz@sysmic.org>
---
Makefile | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/Makefile b/Makefile
index 6cf5f1c..e4f5441 100644
--- a/Makefile
+++ b/Makefile
@@ -644,7 +644,7 @@ target-finalize: $(PACKAGES)
$(TARGET_DIR)/usr/lib/pkgconfig $(TARGET_DIR)/usr/share/pkgconfig \
$(TARGET_DIR)/usr/lib/cmake $(TARGET_DIR)/usr/share/cmake
find $(TARGET_DIR)/usr/{lib,share}/ -name '*.cmake' -print0 | xargs -0 rm -f
- find $(TARGET_DIR)/lib $(TARGET_DIR)/usr/lib $(TARGET_DIR)/usr/libexec \
+ find $(TARGET_DIR)/lib/ $(TARGET_DIR)/usr/lib/ $(TARGET_DIR)/usr/libexec/ \
\( -name '*.a' -o -name '*.la' \) -print0 | xargs -0 rm -f
ifneq ($(BR2_PACKAGE_GDB),y)
rm -rf $(TARGET_DIR)/usr/share/gdb
@@ -666,13 +666,13 @@ endif
# besides the one in which crash occurred; or SIGTRAP kills my program when
# I set a breakpoint"
ifeq ($(BR2_TOOLCHAIN_HAS_THREADS),y)
- find $(TARGET_DIR)/lib -type f -name 'libpthread*.so*' | \
+ find $(TARGET_DIR)/lib/ -type f -name 'libpthread*.so*' | \
xargs -r $(STRIPCMD) $(STRIP_STRIP_DEBUG)
endif
# Valgrind needs ld.so with enough information, so only strip
# debugging symbols.
- find $(TARGET_DIR)/lib -type f -name 'ld-*.so*' | \
+ find $(TARGET_DIR)/lib/ -type f -name 'ld-*.so*' | \
xargs -r $(STRIPCMD) $(STRIP_STRIP_DEBUG)
test -f $(TARGET_DIR)/etc/ld.so.conf && \
{ echo "ERROR: we shouldn't have a /etc/ld.so.conf file"; exit 1; } || true
--
2.9.3
^ permalink raw reply related
* Re: KASAN & the vmalloc area
From: Mark Rutland @ 2016-11-09 10:56 UTC (permalink / raw)
To: Dmitry Vyukov
Cc: Andy Lutomirski, Andrey Ryabinin, Laura Abbott, Ard Biesheuvel,
LKML, linux-arm-kernel, kasan-dev
In-Reply-To: <CACT4Y+ZSgfK-=wFFswMmQ+636Arz4kgwxdxz+FvEJHXvjZ8ckg@mail.gmail.com>
On Tue, Nov 08, 2016 at 02:09:27PM -0800, Dmitry Vyukov wrote:
> On Tue, Nov 8, 2016 at 11:03 AM, Mark Rutland <mark.rutland@arm.com> wrote:
> > When KASAN is selected, we allocate shadow for the whole vmalloc area,
> > using common zero pte, pmd, pud tables. Walking over these in the ptdump
> > code takes a *very* long time (I've seen up to 15 minutes with
> > KASAN_OUTLINE enabled). For DEBUG_WX [3], this means boot hangs for that
> > long, too.
[...]
> I've seen the same iteration slowness problem on x86 with
> CONFIG_DEBUG_RODATA which walks all pages. The is about 1 minute, but
> it is enough to trigger rcu stall warning.
Interesting; do you know where that happens? I can't spot any obvious
case where we'd have to walk all the page tables for DEBUG_RODATA.
> The zero pud and vmalloc-ed stacks looks like different problems.
> To overcome the slowness we could map zero shadow for vmalloc area lazily.
> However for vmalloc-ed stacks we need to map actual memory, because
> stack instrumentation will read/write into the shadow.
Sure. The point I was trying to make is that there' be fewer page tables
to walk (unless the vmalloc area was exhausted), assuming we also lazily
mapped the common zero shadow for the vmalloc area.
> One downside here is that vmalloc shadow can be as large as 1:1 (if we
> allocate 1 page in vmalloc area we need to allocate 1 page for
> shadow).
I thought per prior discussion we'd only need to allocate new pages for
the stacks in the vmalloc region, and we could re-use the zero pages?
... or are you trying to quantify the cost of the page tables?
> Re slowness: could we just skip the KASAN zero puds (the top level)
> while walking? Can they be interesting for anybody?
They're interesting for the ptdump case (which allows privileged users
to dump the tables via /sys/kernel/debug/kernel_page_tables). I've seen
25+ minute hangs there.
> We can just pretend that they are not there. Looks like a trivial
> solution for the problem at hand.
For the boot time hang it's option. Though I'd prefer that the sanity
checks applied to all of tables, shadow regions included.
Thanks,
Mark.
^ permalink raw reply
* [PATCH v3] z3fold: use per-page read/write lock
From: Vitaly Wool @ 2016-11-09 10:55 UTC (permalink / raw)
To: Linux-MM, linux-kernel; +Cc: Dan Streetman, Andrew Morton, Andi Kleen
Most of z3fold operations are in-page, such as modifying z3fold
page header or moving z3fold objects within a page. Taking
per-pool spinlock to protect per-page objects is therefore
suboptimal, and the idea of having a per-page spinlock (or rwlock)
has been around for some time. However, adding one directly to the
z3fold header makes the latter quite big on some systems so that
it won't fit in a signle chunk.
This patch implements spinlock-based per-page locking mechanism
which is lightweight enough to fit into the z3fold header.
Changes from v1 [1]:
- custom locking mechanism changed to spinlocks
- no read/write locks, just per-page spinlock
Changes from v2 [2]:
- if a page is taken off its list by z3fold_alloc(), bail out from
z3fold_free() early
[1] https://lkml.org/lkml/2016/11/5/59
[2] https://lkml.org/lkml/2016/11/8/400
Signed-off-by: Vitaly Wool <vitalywool@gmail.com>
---
mm/z3fold.c | 137 ++++++++++++++++++++++++++++++++++++++++++------------------
1 file changed, 97 insertions(+), 40 deletions(-)
diff --git a/mm/z3fold.c b/mm/z3fold.c
index d85dac0..139ef5e 100644
--- a/mm/z3fold.c
+++ b/mm/z3fold.c
@@ -98,6 +98,7 @@ enum buddy {
* struct z3fold_header - z3fold page metadata occupying the first chunk of each
* z3fold page, except for HEADLESS pages
* @buddy: links the z3fold page into the relevant list in the pool
+ * @page_lock: per-page lock
* @first_chunks: the size of the first buddy in chunks, 0 if free
* @middle_chunks: the size of the middle buddy in chunks, 0 if free
* @last_chunks: the size of the last buddy in chunks, 0 if free
@@ -105,6 +106,7 @@ enum buddy {
*/
struct z3fold_header {
struct list_head buddy;
+ spinlock_t page_lock;
unsigned short first_chunks;
unsigned short middle_chunks;
unsigned short last_chunks;
@@ -144,6 +146,7 @@ static struct z3fold_header *init_z3fold_page(struct page *page)
clear_bit(PAGE_HEADLESS, &page->private);
clear_bit(MIDDLE_CHUNK_MAPPED, &page->private);
+ spin_lock_init(&zhdr->page_lock);
zhdr->first_chunks = 0;
zhdr->middle_chunks = 0;
zhdr->last_chunks = 0;
@@ -159,6 +162,19 @@ static void free_z3fold_page(struct z3fold_header *zhdr)
__free_page(virt_to_page(zhdr));
}
+/* Lock a z3fold page */
+static inline void z3fold_page_lock(struct z3fold_header *zhdr)
+{
+ spin_lock(&zhdr->page_lock);
+}
+
+/* Unlock a z3fold page */
+static inline void z3fold_page_unlock(struct z3fold_header *zhdr)
+{
+ spin_unlock(&zhdr->page_lock);
+}
+
+
/*
* Encodes the handle of a particular buddy within a z3fold page
* Pool lock should be held as this function accesses first_num
@@ -343,50 +359,60 @@ static int z3fold_alloc(struct z3fold_pool *pool, size_t size, gfp_t gfp,
bud = HEADLESS;
else {
chunks = size_to_chunks(size);
- spin_lock(&pool->lock);
/* First, try to find an unbuddied z3fold page. */
zhdr = NULL;
for_each_unbuddied_list(i, chunks) {
- if (!list_empty(&pool->unbuddied[i])) {
- zhdr = list_first_entry(&pool->unbuddied[i],
+ spin_lock(&pool->lock);
+ zhdr = list_first_entry_or_null(&pool->unbuddied[i],
struct z3fold_header, buddy);
- page = virt_to_page(zhdr);
- if (zhdr->first_chunks == 0) {
- if (zhdr->middle_chunks != 0 &&
- chunks >= zhdr->start_middle)
- bud = LAST;
- else
- bud = FIRST;
- } else if (zhdr->last_chunks == 0)
+ if (!zhdr) {
+ spin_unlock(&pool->lock);
+ continue;
+ }
+ list_del_init(&zhdr->buddy);
+ spin_unlock(&pool->lock);
+
+ page = virt_to_page(zhdr);
+ z3fold_page_lock(zhdr);
+ if (zhdr->first_chunks == 0) {
+ if (zhdr->middle_chunks != 0 &&
+ chunks >= zhdr->start_middle)
bud = LAST;
- else if (zhdr->middle_chunks == 0)
- bud = MIDDLE;
- else {
- pr_err("No free chunks in unbuddied\n");
- WARN_ON(1);
- continue;
- }
- list_del(&zhdr->buddy);
- goto found;
+ else
+ bud = FIRST;
+ } else if (zhdr->last_chunks == 0)
+ bud = LAST;
+ else if (zhdr->middle_chunks == 0)
+ bud = MIDDLE;
+ else {
+ spin_lock(&pool->lock);
+ list_add(&zhdr->buddy, &pool->buddied);
+ spin_unlock(&pool->lock);
+ z3fold_page_unlock(zhdr);
+ pr_err("No free chunks in unbuddied\n");
+ WARN_ON(1);
+ continue;
}
+ goto found;
}
bud = FIRST;
- spin_unlock(&pool->lock);
}
/* Couldn't find unbuddied z3fold page, create new one */
page = alloc_page(gfp);
if (!page)
return -ENOMEM;
- spin_lock(&pool->lock);
+
atomic64_inc(&pool->pages_nr);
zhdr = init_z3fold_page(page);
if (bud == HEADLESS) {
set_bit(PAGE_HEADLESS, &page->private);
+ spin_lock(&pool->lock);
goto headless;
}
+ z3fold_page_lock(zhdr);
found:
if (bud == FIRST)
@@ -398,6 +424,7 @@ static int z3fold_alloc(struct z3fold_pool *pool, size_t size, gfp_t gfp,
zhdr->start_middle = zhdr->first_chunks + 1;
}
+ spin_lock(&pool->lock);
if (zhdr->first_chunks == 0 || zhdr->last_chunks == 0 ||
zhdr->middle_chunks == 0) {
/* Add to unbuddied list */
@@ -417,6 +444,8 @@ static int z3fold_alloc(struct z3fold_pool *pool, size_t size, gfp_t gfp,
*handle = encode_handle(zhdr, bud);
spin_unlock(&pool->lock);
+ if (bud != HEADLESS)
+ z3fold_page_unlock(zhdr);
return 0;
}
@@ -438,7 +467,6 @@ static void z3fold_free(struct z3fold_pool *pool, unsigned long handle)
struct page *page;
enum buddy bud;
- spin_lock(&pool->lock);
zhdr = handle_to_z3fold_header(handle);
page = virt_to_page(zhdr);
@@ -446,6 +474,7 @@ static void z3fold_free(struct z3fold_pool *pool, unsigned long handle)
/* HEADLESS page stored */
bud = HEADLESS;
} else {
+ z3fold_page_lock(zhdr);
bud = handle_to_buddy(handle);
switch (bud) {
@@ -462,37 +491,59 @@ static void z3fold_free(struct z3fold_pool *pool, unsigned long handle)
default:
pr_err("%s: unknown bud %d\n", __func__, bud);
WARN_ON(1);
- spin_unlock(&pool->lock);
+ z3fold_page_unlock(zhdr);
return;
}
}
if (test_bit(UNDER_RECLAIM, &page->private)) {
/* z3fold page is under reclaim, reclaim will free */
- spin_unlock(&pool->lock);
+ if (bud != HEADLESS)
+ z3fold_page_unlock(zhdr);
return;
}
/* Remove from existing buddy list */
- if (bud != HEADLESS)
- list_del(&zhdr->buddy);
+ if (bud != HEADLESS) {
+ spin_lock(&pool->lock);
+ /*
+ * this object may have been removed from its list by
+ * z3fold_alloc(). In that case we just do nothing,
+ * z3fold_alloc() will allocate an object and add the page
+ * to the relevant list.
+ */
+ if (!list_empty(&zhdr->buddy)) {
+ list_del(&zhdr->buddy);
+ } else {
+ spin_unlock(&pool->lock);
+ z3fold_page_unlock(zhdr);
+ return;
+ }
+ spin_unlock(&pool->lock);
+ }
if (bud == HEADLESS ||
(zhdr->first_chunks == 0 && zhdr->middle_chunks == 0 &&
zhdr->last_chunks == 0)) {
/* z3fold page is empty, free */
+ spin_lock(&pool->lock);
list_del(&page->lru);
+ spin_unlock(&pool->lock);
clear_bit(PAGE_HEADLESS, &page->private);
+ if (bud != HEADLESS)
+ z3fold_page_unlock(zhdr);
free_z3fold_page(zhdr);
atomic64_dec(&pool->pages_nr);
} else {
z3fold_compact_page(zhdr);
/* Add to the unbuddied list */
+ spin_lock(&pool->lock);
freechunks = num_free_chunks(zhdr);
list_add(&zhdr->buddy, &pool->unbuddied[freechunks]);
+ spin_unlock(&pool->lock);
+ z3fold_page_unlock(zhdr);
}
- spin_unlock(&pool->lock);
}
/**
@@ -553,7 +604,8 @@ static int z3fold_reclaim_page(struct z3fold_pool *pool, unsigned int retries)
zhdr = page_address(page);
if (!test_bit(PAGE_HEADLESS, &page->private)) {
list_del(&zhdr->buddy);
-
+ spin_unlock(&pool->lock);
+ z3fold_page_lock(zhdr);
/*
* We need encode the handles before unlocking, since
* we can race with free that will set
@@ -568,13 +620,13 @@ static int z3fold_reclaim_page(struct z3fold_pool *pool, unsigned int retries)
middle_handle = encode_handle(zhdr, MIDDLE);
if (zhdr->last_chunks)
last_handle = encode_handle(zhdr, LAST);
+ z3fold_page_unlock(zhdr);
} else {
first_handle = encode_handle(zhdr, HEADLESS);
last_handle = middle_handle = 0;
+ spin_unlock(&pool->lock);
}
- spin_unlock(&pool->lock);
-
/* Issue the eviction callback(s) */
if (middle_handle) {
ret = pool->ops->evict(pool, middle_handle);
@@ -592,7 +644,8 @@ static int z3fold_reclaim_page(struct z3fold_pool *pool, unsigned int retries)
goto next;
}
next:
- spin_lock(&pool->lock);
+ if (!test_bit(PAGE_HEADLESS, &page->private))
+ z3fold_page_lock(zhdr);
clear_bit(UNDER_RECLAIM, &page->private);
if ((test_bit(PAGE_HEADLESS, &page->private) && ret == 0) ||
(zhdr->first_chunks == 0 && zhdr->last_chunks == 0 &&
@@ -602,19 +655,22 @@ static int z3fold_reclaim_page(struct z3fold_pool *pool, unsigned int retries)
* return success.
*/
clear_bit(PAGE_HEADLESS, &page->private);
+ if (!test_bit(PAGE_HEADLESS, &page->private))
+ z3fold_page_unlock(zhdr);
free_z3fold_page(zhdr);
atomic64_dec(&pool->pages_nr);
- spin_unlock(&pool->lock);
return 0;
} else if (!test_bit(PAGE_HEADLESS, &page->private)) {
if (zhdr->first_chunks != 0 &&
zhdr->last_chunks != 0 &&
zhdr->middle_chunks != 0) {
/* Full, add to buddied list */
+ spin_lock(&pool->lock);
list_add(&zhdr->buddy, &pool->buddied);
} else {
z3fold_compact_page(zhdr);
/* add to unbuddied list */
+ spin_lock(&pool->lock);
freechunks = num_free_chunks(zhdr);
list_add(&zhdr->buddy,
&pool->unbuddied[freechunks]);
@@ -625,6 +681,8 @@ static int z3fold_reclaim_page(struct z3fold_pool *pool, unsigned int retries)
list_add(&page->lru, &pool->lru);
}
spin_unlock(&pool->lock);
+ if (!test_bit(PAGE_HEADLESS, &page->private))
+ z3fold_page_unlock(zhdr);
return -EAGAIN;
}
@@ -645,7 +703,6 @@ static void *z3fold_map(struct z3fold_pool *pool, unsigned long handle)
void *addr;
enum buddy buddy;
- spin_lock(&pool->lock);
zhdr = handle_to_z3fold_header(handle);
addr = zhdr;
page = virt_to_page(zhdr);
@@ -653,6 +710,7 @@ static void *z3fold_map(struct z3fold_pool *pool, unsigned long handle)
if (test_bit(PAGE_HEADLESS, &page->private))
goto out;
+ z3fold_page_lock(zhdr);
buddy = handle_to_buddy(handle);
switch (buddy) {
case FIRST:
@@ -671,8 +729,9 @@ static void *z3fold_map(struct z3fold_pool *pool, unsigned long handle)
addr = NULL;
break;
}
+
+ z3fold_page_unlock(zhdr);
out:
- spin_unlock(&pool->lock);
return addr;
}
@@ -687,19 +746,17 @@ static void z3fold_unmap(struct z3fold_pool *pool, unsigned long handle)
struct page *page;
enum buddy buddy;
- spin_lock(&pool->lock);
zhdr = handle_to_z3fold_header(handle);
page = virt_to_page(zhdr);
- if (test_bit(PAGE_HEADLESS, &page->private)) {
- spin_unlock(&pool->lock);
+ if (test_bit(PAGE_HEADLESS, &page->private))
return;
- }
+ z3fold_page_lock(zhdr);
buddy = handle_to_buddy(handle);
if (buddy == MIDDLE)
clear_bit(MIDDLE_CHUNK_MAPPED, &page->private);
- spin_unlock(&pool->lock);
+ z3fold_page_unlock(zhdr);
}
/**
--
2.4.2
^ permalink raw reply related
* KASAN & the vmalloc area
From: Mark Rutland @ 2016-11-09 10:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACT4Y+ZSgfK-=wFFswMmQ+636Arz4kgwxdxz+FvEJHXvjZ8ckg@mail.gmail.com>
On Tue, Nov 08, 2016 at 02:09:27PM -0800, Dmitry Vyukov wrote:
> On Tue, Nov 8, 2016 at 11:03 AM, Mark Rutland <mark.rutland@arm.com> wrote:
> > When KASAN is selected, we allocate shadow for the whole vmalloc area,
> > using common zero pte, pmd, pud tables. Walking over these in the ptdump
> > code takes a *very* long time (I've seen up to 15 minutes with
> > KASAN_OUTLINE enabled). For DEBUG_WX [3], this means boot hangs for that
> > long, too.
[...]
> I've seen the same iteration slowness problem on x86 with
> CONFIG_DEBUG_RODATA which walks all pages. The is about 1 minute, but
> it is enough to trigger rcu stall warning.
Interesting; do you know where that happens? I can't spot any obvious
case where we'd have to walk all the page tables for DEBUG_RODATA.
> The zero pud and vmalloc-ed stacks looks like different problems.
> To overcome the slowness we could map zero shadow for vmalloc area lazily.
> However for vmalloc-ed stacks we need to map actual memory, because
> stack instrumentation will read/write into the shadow.
Sure. The point I was trying to make is that there' be fewer page tables
to walk (unless the vmalloc area was exhausted), assuming we also lazily
mapped the common zero shadow for the vmalloc area.
> One downside here is that vmalloc shadow can be as large as 1:1 (if we
> allocate 1 page in vmalloc area we need to allocate 1 page for
> shadow).
I thought per prior discussion we'd only need to allocate new pages for
the stacks in the vmalloc region, and we could re-use the zero pages?
... or are you trying to quantify the cost of the page tables?
> Re slowness: could we just skip the KASAN zero puds (the top level)
> while walking? Can they be interesting for anybody?
They're interesting for the ptdump case (which allows privileged users
to dump the tables via /sys/kernel/debug/kernel_page_tables). I've seen
25+ minute hangs there.
> We can just pretend that they are not there. Looks like a trivial
> solution for the problem at hand.
For the boot time hang it's option. Though I'd prefer that the sanity
checks applied to all of tables, shadow regions included.
Thanks,
Mark.
^ permalink raw reply
* [Bug 98654] New: kernel paging request at iowrite32
From: bugzilla-daemon-CC+yJ3UmIYqDUpFQwHEjaQ @ 2016-11-09 10:56 UTC (permalink / raw)
To: nouveau-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW
[-- Attachment #1.1: Type: text/plain, Size: 5444 bytes --]
https://bugs.freedesktop.org/show_bug.cgi?id=98654
Bug ID: 98654
Summary: kernel paging request at iowrite32
Product: xorg
Version: unspecified
Hardware: Other
OS: All
Status: NEW
Severity: normal
Priority: medium
Component: Driver/nouveau
Assignee: nouveau-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org
Reporter: germano.massullo-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
QA Contact: xorg-team-go0+a7rfsptAfugRpC6u6w@public.gmane.org
This is the upstream bugreport clone of
https://bugzilla.redhat.com/show_bug.cgi?id=1343242
I attach only the first comment, for more information please see the previous
URL
================================
Additional info:
reporter: libreport-2.7.1
BUG: unable to handle kernel paging request at ffffc90000eb0000
IP: [<ffffffff813ec9ce>] iowrite32+0x2e/0x40
PGD 1b90a0067 PUD 1b90a1067 PMD bb976067 PTE 0
Oops: 0002 [#1] SMP
Modules linked in: bnep nfnetlink_queue nfnetlink_log bluetooth rfkill xfs fuse
xt_CHECKSUM ipt_MASQUERADE nf_nat_masquerade_ipv4 tun ip6t_rpfilter ip6t_REJECT
nf_reject_ipv6 xt_conntrack ip_set nfnetlink ebtable_broute bridge stp llc
ebtable_nat ip6table_mangle ip6table_nat nf_conntrack_ipv6 nf_defrag_ipv6
nf_nat_ipv6 ip6table_security ip6table_raw iptable_mangle iptable_nat
nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack
iptable_security iptable_raw ebtable_filter ebtables ip6table_filter ip6_tables
rc_dib0700_rc5 dib7000p raid456 async_raid6_recov async_memcpy async_pq
async_xor xor async_tx raid6_pq coretemp kvm_intel kvm iTCO_wdt gpio_ich
iTCO_vendor_support snd_hda_codec_analog snd_hda_codec_generic irqbypass
dvb_pll cx22702 cx88_dvb cx88_vp3054_i2c videobuf2_dvb
ir_lirc_codec lirc_dev dvb_usb_dib0700 rc_cinergy_1400 dib7000m dib0090
dib0070 dib3000mc dibx000_common dvb_usb i2c_i801 dvb_core dm_thin_pool
dm_persistent_data dm_bio_prison libcrc32c joydev cx8800 cx8802 cx88xx
snd_hda_intel videobuf2_dma_sg tveeprom videobuf2_memops videobuf2_v4l2
snd_hda_codec videobuf2_core rc_core v4l2_common snd_hda_core videodev
snd_hwdep snd_seq media snd_seq_device lpc_ich snd_pcm snd_timer snd
asus_atk0110 soundcore shpchp acpi_cpufreq tpm_tis tpm binfmt_misc nfsd
auth_rpcgss nfs_acl lockd grace sunrpc ata_generic pata_acpi nouveau video
mxm_wmi wmi i2c_algo_bit drm_kms_helper serio_raw ttm firewire_ohci
firewire_core skge crc_itu_t drm hid_logitech uas ff_memless usb_storage
pata_jmicron fjes
CPU: 1 PID: 10062 Comm: multiqueue24:sr Not tainted 4.5.5-300.fc24.x86_64 #1
Hardware name: System manufacturer System Product Name/P5B-Deluxe, BIOS 1238
09/30/2008
task: ffff8801a28bba80 ti: ffff88010ee74000 task.ti: ffff88010ee74000
RIP: 0010:[<ffffffff813ec9ce>] [<ffffffff813ec9ce>] iowrite32+0x2e/0x40
RSP: 0018:ffff88010ee77948 EFLAGS: 00010292
RAX: ffffffffa0205100 RBX: 0000000000010000 RCX: 0000000000000009
RDX: 000000001dfc5201 RSI: ffffc90000eb0000 RDI: 000000001dfc5201
RBP: ffff88010ee77950 R08: 0000000000000100 R09: 000000001deda000
R10: ffff8801a49ca800 R11: 000000001deda000 R12: 0000000000000000
R13: 000000001dfc5201 R14: 0000000000000080 R15: ffff880036a65340
FS: 00007ff0a66ea700(0000) GS:ffff8801bfc80000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: ffffc90000eb0000 CR3: 00000000a6bd1000 CR4: 00000000000006e0
Stack:
ffffffffa0174494 ffff88010ee779a8 ffffffffa017a1c6 ffff8801a49ca800
ffff8800a7426258 000000001dfd5001 0000002800000000 0000000000000100
0000000000000000 0000000000002015 ffff8801b5d6f600 ffff8800a7426258
Call Trace:
[<ffffffffa0174494>] ? nvkm_instobj_wr32+0x14/0x20 [nouveau]
[<ffffffffa017a1c6>] nv50_vm_map+0x156/0x1a0 [nouveau]
[<ffffffffa017833d>] nvkm_vm_map_at+0xdd/0x1d0 [nouveau]
[<ffffffffa017521b>] nv50_instobj_map+0x1b/0x20 [nouveau]
[<ffffffffa0175482>] nv50_instobj_boot+0xc2/0x120 [nouveau]
[<ffffffffa017539b>] nv50_instobj_acquire+0x4b/0x70 [nouveau]
[<ffffffffa01743c7>] nvkm_instobj_acquire_slow+0x17/0x30 [nouveau]
[<ffffffffa017473a>] nvkm_instobj_new+0x6a/0x170 [nouveau]
[<ffffffffa01363f4>] nvkm_memory_new+0x44/0x80 [nouveau]
[<ffffffffa0178e7f>] nvkm_vm_get+0x15f/0x250 [nouveau]
[<ffffffffa01d1b00>] nouveau_bo_vma_add+0x30/0x90 [nouveau]
[<ffffffffa01e34a9>] nouveau_channel_prep+0x1d9/0x2a0 [nouveau]
[<ffffffffa01e35c7>] nouveau_channel_new+0x57/0x6e0 [nouveau]
[<ffffffffa0133a2d>] ? nvif_device_init+0x2d/0x30 [nouveau]
[<ffffffff8121ab52>] ? kmem_cache_alloc_trace+0x1c2/0x1d0
[<ffffffffa01e2736>] nouveau_abi16_ioctl_channel_alloc+0xd6/0x2c0 [nouveau]
[<ffffffffa0050712>] drm_ioctl+0x152/0x540 [drm]
[<ffffffffa01e2660>] ? nouveau_abi16_ioctl_setparam+0x10/0x10 [nouveau]
[<ffffffffa01cb144>] nouveau_drm_ioctl+0x74/0xc0 [nouveau]
[<ffffffff81256183>] do_vfs_ioctl+0xa3/0x5d0
[<ffffffff81256729>] SyS_ioctl+0x79/0x90
[<ffffffff817cecee>] entry_SYSCALL_64_fastpath+0x12/0x6d
Code: ff ff 03 00 77 25 48 81 fe 00 00 01 00 76 07 0f b7 d6 89 f8 ef c3 55 48
89 f7 48 c7 c6 52 84 aa 81 48 89 e5 e8 54 fe ff ff 5d c3 <89> 3e c3 0f 1f 44 00
00 66 2e 0f 1f 84 00 00 00 00 00 48 81 ff
RIP [<ffffffff813ec9ce>] iowrite32+0x2e/0x40
RSP <ffff88010ee77948>
================================
--
You are receiving this mail because:
You are the assignee for the bug.
[-- Attachment #1.2: Type: text/html, Size: 6951 bytes --]
[-- Attachment #2: Type: text/plain, Size: 154 bytes --]
_______________________________________________
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau
^ permalink raw reply
* [PATCH v3] z3fold: use per-page read/write lock
From: Vitaly Wool @ 2016-11-09 10:55 UTC (permalink / raw)
To: Linux-MM, linux-kernel; +Cc: Dan Streetman, Andrew Morton, Andi Kleen
Most of z3fold operations are in-page, such as modifying z3fold
page header or moving z3fold objects within a page. Taking
per-pool spinlock to protect per-page objects is therefore
suboptimal, and the idea of having a per-page spinlock (or rwlock)
has been around for some time. However, adding one directly to the
z3fold header makes the latter quite big on some systems so that
it won't fit in a signle chunk.
This patch implements spinlock-based per-page locking mechanism
which is lightweight enough to fit into the z3fold header.
Changes from v1 [1]:
- custom locking mechanism changed to spinlocks
- no read/write locks, just per-page spinlock
Changes from v2 [2]:
- if a page is taken off its list by z3fold_alloc(), bail out from
z3fold_free() early
[1] https://lkml.org/lkml/2016/11/5/59
[2] https://lkml.org/lkml/2016/11/8/400
Signed-off-by: Vitaly Wool <vitalywool@gmail.com>
---
mm/z3fold.c | 137 ++++++++++++++++++++++++++++++++++++++++++------------------
1 file changed, 97 insertions(+), 40 deletions(-)
diff --git a/mm/z3fold.c b/mm/z3fold.c
index d85dac0..139ef5e 100644
--- a/mm/z3fold.c
+++ b/mm/z3fold.c
@@ -98,6 +98,7 @@ enum buddy {
* struct z3fold_header - z3fold page metadata occupying the first chunk of each
* z3fold page, except for HEADLESS pages
* @buddy: links the z3fold page into the relevant list in the pool
+ * @page_lock: per-page lock
* @first_chunks: the size of the first buddy in chunks, 0 if free
* @middle_chunks: the size of the middle buddy in chunks, 0 if free
* @last_chunks: the size of the last buddy in chunks, 0 if free
@@ -105,6 +106,7 @@ enum buddy {
*/
struct z3fold_header {
struct list_head buddy;
+ spinlock_t page_lock;
unsigned short first_chunks;
unsigned short middle_chunks;
unsigned short last_chunks;
@@ -144,6 +146,7 @@ static struct z3fold_header *init_z3fold_page(struct page *page)
clear_bit(PAGE_HEADLESS, &page->private);
clear_bit(MIDDLE_CHUNK_MAPPED, &page->private);
+ spin_lock_init(&zhdr->page_lock);
zhdr->first_chunks = 0;
zhdr->middle_chunks = 0;
zhdr->last_chunks = 0;
@@ -159,6 +162,19 @@ static void free_z3fold_page(struct z3fold_header *zhdr)
__free_page(virt_to_page(zhdr));
}
+/* Lock a z3fold page */
+static inline void z3fold_page_lock(struct z3fold_header *zhdr)
+{
+ spin_lock(&zhdr->page_lock);
+}
+
+/* Unlock a z3fold page */
+static inline void z3fold_page_unlock(struct z3fold_header *zhdr)
+{
+ spin_unlock(&zhdr->page_lock);
+}
+
+
/*
* Encodes the handle of a particular buddy within a z3fold page
* Pool lock should be held as this function accesses first_num
@@ -343,50 +359,60 @@ static int z3fold_alloc(struct z3fold_pool *pool, size_t size, gfp_t gfp,
bud = HEADLESS;
else {
chunks = size_to_chunks(size);
- spin_lock(&pool->lock);
/* First, try to find an unbuddied z3fold page. */
zhdr = NULL;
for_each_unbuddied_list(i, chunks) {
- if (!list_empty(&pool->unbuddied[i])) {
- zhdr = list_first_entry(&pool->unbuddied[i],
+ spin_lock(&pool->lock);
+ zhdr = list_first_entry_or_null(&pool->unbuddied[i],
struct z3fold_header, buddy);
- page = virt_to_page(zhdr);
- if (zhdr->first_chunks == 0) {
- if (zhdr->middle_chunks != 0 &&
- chunks >= zhdr->start_middle)
- bud = LAST;
- else
- bud = FIRST;
- } else if (zhdr->last_chunks == 0)
+ if (!zhdr) {
+ spin_unlock(&pool->lock);
+ continue;
+ }
+ list_del_init(&zhdr->buddy);
+ spin_unlock(&pool->lock);
+
+ page = virt_to_page(zhdr);
+ z3fold_page_lock(zhdr);
+ if (zhdr->first_chunks == 0) {
+ if (zhdr->middle_chunks != 0 &&
+ chunks >= zhdr->start_middle)
bud = LAST;
- else if (zhdr->middle_chunks == 0)
- bud = MIDDLE;
- else {
- pr_err("No free chunks in unbuddied\n");
- WARN_ON(1);
- continue;
- }
- list_del(&zhdr->buddy);
- goto found;
+ else
+ bud = FIRST;
+ } else if (zhdr->last_chunks == 0)
+ bud = LAST;
+ else if (zhdr->middle_chunks == 0)
+ bud = MIDDLE;
+ else {
+ spin_lock(&pool->lock);
+ list_add(&zhdr->buddy, &pool->buddied);
+ spin_unlock(&pool->lock);
+ z3fold_page_unlock(zhdr);
+ pr_err("No free chunks in unbuddied\n");
+ WARN_ON(1);
+ continue;
}
+ goto found;
}
bud = FIRST;
- spin_unlock(&pool->lock);
}
/* Couldn't find unbuddied z3fold page, create new one */
page = alloc_page(gfp);
if (!page)
return -ENOMEM;
- spin_lock(&pool->lock);
+
atomic64_inc(&pool->pages_nr);
zhdr = init_z3fold_page(page);
if (bud == HEADLESS) {
set_bit(PAGE_HEADLESS, &page->private);
+ spin_lock(&pool->lock);
goto headless;
}
+ z3fold_page_lock(zhdr);
found:
if (bud == FIRST)
@@ -398,6 +424,7 @@ static int z3fold_alloc(struct z3fold_pool *pool, size_t size, gfp_t gfp,
zhdr->start_middle = zhdr->first_chunks + 1;
}
+ spin_lock(&pool->lock);
if (zhdr->first_chunks == 0 || zhdr->last_chunks == 0 ||
zhdr->middle_chunks == 0) {
/* Add to unbuddied list */
@@ -417,6 +444,8 @@ static int z3fold_alloc(struct z3fold_pool *pool, size_t size, gfp_t gfp,
*handle = encode_handle(zhdr, bud);
spin_unlock(&pool->lock);
+ if (bud != HEADLESS)
+ z3fold_page_unlock(zhdr);
return 0;
}
@@ -438,7 +467,6 @@ static void z3fold_free(struct z3fold_pool *pool, unsigned long handle)
struct page *page;
enum buddy bud;
- spin_lock(&pool->lock);
zhdr = handle_to_z3fold_header(handle);
page = virt_to_page(zhdr);
@@ -446,6 +474,7 @@ static void z3fold_free(struct z3fold_pool *pool, unsigned long handle)
/* HEADLESS page stored */
bud = HEADLESS;
} else {
+ z3fold_page_lock(zhdr);
bud = handle_to_buddy(handle);
switch (bud) {
@@ -462,37 +491,59 @@ static void z3fold_free(struct z3fold_pool *pool, unsigned long handle)
default:
pr_err("%s: unknown bud %d\n", __func__, bud);
WARN_ON(1);
- spin_unlock(&pool->lock);
+ z3fold_page_unlock(zhdr);
return;
}
}
if (test_bit(UNDER_RECLAIM, &page->private)) {
/* z3fold page is under reclaim, reclaim will free */
- spin_unlock(&pool->lock);
+ if (bud != HEADLESS)
+ z3fold_page_unlock(zhdr);
return;
}
/* Remove from existing buddy list */
- if (bud != HEADLESS)
- list_del(&zhdr->buddy);
+ if (bud != HEADLESS) {
+ spin_lock(&pool->lock);
+ /*
+ * this object may have been removed from its list by
+ * z3fold_alloc(). In that case we just do nothing,
+ * z3fold_alloc() will allocate an object and add the page
+ * to the relevant list.
+ */
+ if (!list_empty(&zhdr->buddy)) {
+ list_del(&zhdr->buddy);
+ } else {
+ spin_unlock(&pool->lock);
+ z3fold_page_unlock(zhdr);
+ return;
+ }
+ spin_unlock(&pool->lock);
+ }
if (bud == HEADLESS ||
(zhdr->first_chunks == 0 && zhdr->middle_chunks == 0 &&
zhdr->last_chunks == 0)) {
/* z3fold page is empty, free */
+ spin_lock(&pool->lock);
list_del(&page->lru);
+ spin_unlock(&pool->lock);
clear_bit(PAGE_HEADLESS, &page->private);
+ if (bud != HEADLESS)
+ z3fold_page_unlock(zhdr);
free_z3fold_page(zhdr);
atomic64_dec(&pool->pages_nr);
} else {
z3fold_compact_page(zhdr);
/* Add to the unbuddied list */
+ spin_lock(&pool->lock);
freechunks = num_free_chunks(zhdr);
list_add(&zhdr->buddy, &pool->unbuddied[freechunks]);
+ spin_unlock(&pool->lock);
+ z3fold_page_unlock(zhdr);
}
- spin_unlock(&pool->lock);
}
/**
@@ -553,7 +604,8 @@ static int z3fold_reclaim_page(struct z3fold_pool *pool, unsigned int retries)
zhdr = page_address(page);
if (!test_bit(PAGE_HEADLESS, &page->private)) {
list_del(&zhdr->buddy);
-
+ spin_unlock(&pool->lock);
+ z3fold_page_lock(zhdr);
/*
* We need encode the handles before unlocking, since
* we can race with free that will set
@@ -568,13 +620,13 @@ static int z3fold_reclaim_page(struct z3fold_pool *pool, unsigned int retries)
middle_handle = encode_handle(zhdr, MIDDLE);
if (zhdr->last_chunks)
last_handle = encode_handle(zhdr, LAST);
+ z3fold_page_unlock(zhdr);
} else {
first_handle = encode_handle(zhdr, HEADLESS);
last_handle = middle_handle = 0;
+ spin_unlock(&pool->lock);
}
- spin_unlock(&pool->lock);
-
/* Issue the eviction callback(s) */
if (middle_handle) {
ret = pool->ops->evict(pool, middle_handle);
@@ -592,7 +644,8 @@ static int z3fold_reclaim_page(struct z3fold_pool *pool, unsigned int retries)
goto next;
}
next:
- spin_lock(&pool->lock);
+ if (!test_bit(PAGE_HEADLESS, &page->private))
+ z3fold_page_lock(zhdr);
clear_bit(UNDER_RECLAIM, &page->private);
if ((test_bit(PAGE_HEADLESS, &page->private) && ret == 0) ||
(zhdr->first_chunks == 0 && zhdr->last_chunks == 0 &&
@@ -602,19 +655,22 @@ static int z3fold_reclaim_page(struct z3fold_pool *pool, unsigned int retries)
* return success.
*/
clear_bit(PAGE_HEADLESS, &page->private);
+ if (!test_bit(PAGE_HEADLESS, &page->private))
+ z3fold_page_unlock(zhdr);
free_z3fold_page(zhdr);
atomic64_dec(&pool->pages_nr);
- spin_unlock(&pool->lock);
return 0;
} else if (!test_bit(PAGE_HEADLESS, &page->private)) {
if (zhdr->first_chunks != 0 &&
zhdr->last_chunks != 0 &&
zhdr->middle_chunks != 0) {
/* Full, add to buddied list */
+ spin_lock(&pool->lock);
list_add(&zhdr->buddy, &pool->buddied);
} else {
z3fold_compact_page(zhdr);
/* add to unbuddied list */
+ spin_lock(&pool->lock);
freechunks = num_free_chunks(zhdr);
list_add(&zhdr->buddy,
&pool->unbuddied[freechunks]);
@@ -625,6 +681,8 @@ static int z3fold_reclaim_page(struct z3fold_pool *pool, unsigned int retries)
list_add(&page->lru, &pool->lru);
}
spin_unlock(&pool->lock);
+ if (!test_bit(PAGE_HEADLESS, &page->private))
+ z3fold_page_unlock(zhdr);
return -EAGAIN;
}
@@ -645,7 +703,6 @@ static void *z3fold_map(struct z3fold_pool *pool, unsigned long handle)
void *addr;
enum buddy buddy;
- spin_lock(&pool->lock);
zhdr = handle_to_z3fold_header(handle);
addr = zhdr;
page = virt_to_page(zhdr);
@@ -653,6 +710,7 @@ static void *z3fold_map(struct z3fold_pool *pool, unsigned long handle)
if (test_bit(PAGE_HEADLESS, &page->private))
goto out;
+ z3fold_page_lock(zhdr);
buddy = handle_to_buddy(handle);
switch (buddy) {
case FIRST:
@@ -671,8 +729,9 @@ static void *z3fold_map(struct z3fold_pool *pool, unsigned long handle)
addr = NULL;
break;
}
+
+ z3fold_page_unlock(zhdr);
out:
- spin_unlock(&pool->lock);
return addr;
}
@@ -687,19 +746,17 @@ static void z3fold_unmap(struct z3fold_pool *pool, unsigned long handle)
struct page *page;
enum buddy buddy;
- spin_lock(&pool->lock);
zhdr = handle_to_z3fold_header(handle);
page = virt_to_page(zhdr);
- if (test_bit(PAGE_HEADLESS, &page->private)) {
- spin_unlock(&pool->lock);
+ if (test_bit(PAGE_HEADLESS, &page->private))
return;
- }
+ z3fold_page_lock(zhdr);
buddy = handle_to_buddy(handle);
if (buddy == MIDDLE)
clear_bit(MIDDLE_CHUNK_MAPPED, &page->private);
- spin_unlock(&pool->lock);
+ z3fold_page_unlock(zhdr);
}
/**
--
2.4.2
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply related
* [U-Boot] [PATCH 00/10] sunxi: Add basic PSCI support to enable SMP on the A80's first cluster
From: Chen-Yu Tsai @ 2016-11-09 10:54 UTC (permalink / raw)
To: u-boot
In-Reply-To: <75ca81dd-a7e7-d242-6e2f-6071ece507c4@redhat.com>
On Wed, Nov 9, 2016 at 6:38 PM, Hans de Goede <hdegoede@redhat.com> wrote:
> Hi,
>
> On 09-11-16 11:21, Chen-Yu Tsai wrote:
>>
>> Hi everyone,
>>
>> This series adds basic PSCI support for the A80 to enable SMP on the
>> first cluster. This at least allows people to use more than one core.
>> The term "basic" is used because the series does not add support for
>> multi-cluster cache and power management.
>>
>> The PSCI code is based on existing code for all the single cluster
>> SoCs, and the kernel patches for MCPM SMP I did some time ago.
>>
>> Unfortunately only SMP works at this time. The last patch does not
>> actually work. While the system is indeed booted non-secure, tested
>> by trying to write to secure SRAM and the results not sticking, reads
>> from the GIC CPU interface shows that it's still returning the secure
>> copy of registers, and since we use a secure monitor FIQ to do core
>> power down, the FIQ gets passed to the kernel. The patch is included
>> so people with in-depth ARM knowledge could probably help work out
>> what is wrong.
>
>
> Cools stuff, when I find some time I will review and merge
> patches 1-9 to sunxi-next.
>
> First a question though, do you see any chance that merging this might
> get in the way of enabling support for both clusters in the future?
>
> Since the interface between u-boot and the kernel here is well defined
> (and outside our control) I guess in the worst case, we would need to
> revert some bits of this series from u-boot if they turn out to be non
> suitable, right?
AFAIK with PSCI the firmware is responsible for doing all the setup
before handing the core to the kernel. For now I just return -EINVAL
for the latter 4 cores.
Once we have all the multi cluster support in, such as cluster powering,
synchronization, and CCI-400, instead of returning -EINVAL, we can have
it actually give back a working core.
And Linux can't access CCI-400 in non-secure mode anyway. This has to be
setup by the firmware.
In short, just merging the power on bits for the first cluster here
should not block any attempts to merge any future progress.
Regards
ChenYu
>
> Regards,
>
> Hans
>
>
>
>
>>
>>
>> Regards
>> ChenYu
>>
>> Chen-Yu Tsai (10):
>> ARM: PSCI: Set ARMV7_PSCI_NR_CPUS default to 8 for sun9i/A80
>> sunxi: Add CCI-400 and CPUCFG registers base address for sun9i/A80
>> sunxi: Add base address of secure SRAM B for sun9i/A80
>> sunxi: Use secure SRAM B for secure RAM for sun9i/A80
>> sunxi: Add PRCM register definition for sun9i/A80
>> sunxi: Add CPUCFG register definitions for sun9i/A80
>> sunxi: Add support for TZPC on sun9i/A80
>> sunxi: Add basic PSCI implementation for A80
>> sunxi: Enable PSCI on sun9i/A80
>> sunxi: Add PSCI core power off support for A80's first cluster
>>
>> arch/arm/cpu/armv7/Kconfig | 1 +
>> arch/arm/cpu/armv7/sunxi/Makefile | 5 +
>> arch/arm/cpu/armv7/sunxi/psci-mcpm.c | 322
>> +++++++++++++++++++++++++
>> arch/arm/cpu/armv7/sunxi/tzpc.c | 6 +
>> arch/arm/include/asm/arch-sunxi/cpu_sun9i.h | 5 +
>> arch/arm/include/asm/arch-sunxi/cpucfg_sun9i.h | 51 ++++
>> arch/arm/include/asm/arch-sunxi/prcm_sun9i.h | 55 +++++
>> arch/arm/include/asm/arch-sunxi/tzpc.h | 4 +
>> arch/arm/mach-sunxi/board.c | 3 +-
>> board/sunxi/Kconfig | 4 +
>> include/configs/sun9i.h | 4 +
>> 11 files changed, 459 insertions(+), 1 deletion(-)
>> create mode 100644 arch/arm/cpu/armv7/sunxi/psci-mcpm.c
>> create mode 100644 arch/arm/include/asm/arch-sunxi/cpucfg_sun9i.h
>> create mode 100644 arch/arm/include/asm/arch-sunxi/prcm_sun9i.h
>>
>
^ permalink raw reply
* [Buildroot] [Question] Downgrade package application.
From: Zoltan Gyarmati @ 2016-11-09 10:54 UTC (permalink / raw)
To: buildroot
In-Reply-To: <CADZ=QZmHuyjuctpfxNLn_up=41HXc_8Y+BtDx+4EScrRda04QA@mail.gmail.com>
Dear Yu-Ting Kao,
i'm not sure i full understand, but:
First try to apply your patch on the current Buildroot tree, chances are
that it will apply. If it won't apply, it's always better to try to fix
the patch against the current version than using an old one.
If it's too complicated to fix the patch, as a final resolution, you can
either:
a) download an old tarball from https://buildroot.org/downloads/
or
b) clone the Buildroot git repository and use `git checkout <old git
hash value>' to go back in time.
For both of the options the best is if you know the version the patch
was created for (for example if you know when the patch was created, you
can use a version from that time or a bit earlier)
Good luck,
Zoltan Gyarmati
https://zgyarmati.de
On 11/09/2016 11:04 AM, Yu-Ting Kao wrote:
> Hi,
>
> I have a patch for new feature on a package, but it works on lower
> version. How can I build lower version in buildroot ? Are there any
> menuconfig I can choose ?
> _______________________________________________
> buildroot mailing list
> buildroot at busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot
^ permalink raw reply
* Re: linux-next: build warning after merge of the akpm-current tree
From: Huang Shijie @ 2016-11-09 7:18 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: Andrew Morton, linux-next, linux-kernel, nd
In-Reply-To: <20161109151006.7354dfae@canb.auug.org.au>
On Wed, Nov 09, 2016 at 03:10:06PM +1100, Stephen Rothwell wrote:
Hi Stephen,
> Hi Andrew,
>
> After merging the akpm-current tree, today's linux-next build (powerpc
> ppc64_defconfig) produced this warning:
>
> mm/hugetlb.c:1166:21: warning: 'alloc_gigantic_page' defined but not used [-Wunused-function]
> static struct page *alloc_gigantic_page(int nid, unsigned int order)
The warning should be fixed by the patch (or next version of this patch):
http://marc.info/?l=linux-mm&m=147867535926059&w=2
Thanks
Huang Shijie
^ permalink raw reply
* [PULL] drm-intel-fixes
From: Jani Nikula @ 2016-11-09 10:52 UTC (permalink / raw)
To: Dave Airlie; +Cc: Daniel Vetter, intel-gfx, dri-devel
Hi Dave -
Fixes for i915, in particular includes the fix for [1].
BR,
Jani.
[1] http://lkml.kernel.org/r/2656903.keIazZlQoI@merkaba
The following changes since commit bc33b0ca11e3df467777a4fa7639ba488c9d4911:
Linux 4.9-rc4 (2016-11-05 16:23:36 -0700)
are available in the git repository at:
git://anongit.freedesktop.org/drm-intel tags/drm-intel-fixes-2016-11-09
for you to fetch changes up to 54905ab5fe7aa453610e31cec640e528aaedb2e2:
drm/i915: Limit Valleyview and earlier to only using mappable scanout (2016-11-07 19:02:35 +0200)
----------------------------------------------------------------
Chris Wilson (2):
drm/i915: Round tile chunks up for constructing partial VMAs
drm/i915: Limit Valleyview and earlier to only using mappable scanout
Dhinakaran Pandiyan (2):
drm/i915/dp: BDW cdclk fix for DP audio
drm/i915/dp: Extend BDW DP audio workaround to GEN9 platforms
Lyude (1):
drm/i915/vlv: Prevent enabling hpd polling in late suspend
Ville Syrjälä (1):
drm/i915: Respect alternate_ddc_pin for all DDI ports
drivers/gpu/drm/i915/i915_gem.c | 20 ++++++--
drivers/gpu/drm/i915/intel_display.c | 29 ++++++++++--
drivers/gpu/drm/i915/intel_hdmi.c | 84 +++++++++++++++++++--------------
drivers/gpu/drm/i915/intel_runtime_pm.c | 4 +-
4 files changed, 94 insertions(+), 43 deletions(-)
--
Jani Nikula, Intel Open Source Technology Center
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply
* Re: [PATCH v1 03/11] drivers: soc: hisi: Add support for Hisilicon Djtag driver
From: Anurup M @ 2016-11-09 10:44 UTC (permalink / raw)
To: Arnd Bergmann, John Garry
Cc: linux-arm-kernel, anurup.m, linux-kernel, mark.rutland, shyju.pv,
gabriele.paoloni, will.deacon, linuxarm, xuwei5, zhangshaokun,
sanil.kumar, tanxiaojun, shiju.jose
In-Reply-To: <1609380.NN50qvVsP7@wuerfel>
On Tuesday 08 November 2016 08:40 PM, Arnd Bergmann wrote:
> On Tuesday, November 8, 2016 1:49:43 PM CET John Garry wrote:
>> Hi Arnd,
>>
>> Thanks for the reference.
>>
>> I think the i2c interface doesn't fully satisfy our requirements as we
>> need more than just a slave bus address when accessing the slave device
>> (which I think is what i2c uses). We also need to pass "offset" and
>> "mod_mask" arguments to the djtag adapter to access specific registers
>> in the slave device.
> Ok. Are those values constant per device, or maybe a range? We may want to
> include those in the reg property as well then.
>
> Arnd
>
Hi Arnd,
The "mod_mask" is to select the sub-module within a module. This
parameter is
used for djtag write operation.
In the case of L3 cache, this will select the L3 cache bank. 0xFFFF
select all banks.
This value will change based on the L3 cache bank to be written to. I
think this value
can be in the driver itself.
For djtag read operation, the "mod_mask" is ignored. instead the input
parameter
"chain_id" is used. this will identify the sub-module or bank.
For djtag-v1, the "chain_id" is different for each L3 cache bank, But in
the case of
djtag-v2 the "chain_id" is fixed and the value is 0 as In djtag-v2 there
is separate
"module-id" for each sub-module.
The "offset" is the register offset and this value is a range for a module.
Thanks,
Anurup
^ permalink raw reply
* [PATCH 4.4 02/69] i2c: core: fix NULL pointer dereference under race condition
From: Greg Kroah-Hartman @ 2016-11-09 10:43 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Vladimir Zapolskiy, Wolfram Sang
In-Reply-To: <20161109102901.127641653@linuxfoundation.org>
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com>
commit 147b36d5b70c083cc76770c47d60b347e8eaf231 upstream.
Race condition between registering an I2C device driver and
deregistering an I2C adapter device which is assumed to manage that
I2C device may lead to a NULL pointer dereference due to the
uninitialized list head of driver clients.
The root cause of the issue is that the I2C bus may know about the
registered device driver and thus it is matched by bus_for_each_drv(),
but the list of clients is not initialized and commonly it is NULL,
because I2C device drivers define struct i2c_driver as static and
clients field is expected to be initialized by I2C core:
i2c_register_driver() i2c_del_adapter()
driver_register() ...
bus_add_driver() ...
... bus_for_each_drv(..., __process_removed_adapter)
... i2c_do_del_adapter()
... list_for_each_entry_safe(..., &driver->clients, ...)
INIT_LIST_HEAD(&driver->clients);
To solve the problem it is sufficient to do clients list head
initialization before calling driver_register().
The problem was found while using an I2C device driver with a sluggish
registration routine on a bus provided by a physically detachable I2C
master controller, but practically the oops may be reproduced under
the race between arbitraty I2C device driver registration and managing
I2C bus device removal e.g. by unbinding the latter over sysfs:
% echo 21a4000.i2c > /sys/bus/platform/drivers/imx-i2c/unbind
Unable to handle kernel NULL pointer dereference at virtual address 00000000
Internal error: Oops: 17 [#1] SMP ARM
CPU: 2 PID: 533 Comm: sh Not tainted 4.9.0-rc3+ #61
Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree)
task: e5ada400 task.stack: e4936000
PC is at i2c_do_del_adapter+0x20/0xcc
LR is at __process_removed_adapter+0x14/0x1c
Flags: NzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none
Control: 10c5387d Table: 35bd004a DAC: 00000051
Process sh (pid: 533, stack limit = 0xe4936210)
Stack: (0xe4937d28 to 0xe4938000)
Backtrace:
[<c0667be0>] (i2c_do_del_adapter) from [<c0667cc0>] (__process_removed_adapter+0x14/0x1c)
[<c0667cac>] (__process_removed_adapter) from [<c0516998>] (bus_for_each_drv+0x6c/0xa0)
[<c051692c>] (bus_for_each_drv) from [<c06685ec>] (i2c_del_adapter+0xbc/0x284)
[<c0668530>] (i2c_del_adapter) from [<bf0110ec>] (i2c_imx_remove+0x44/0x164 [i2c_imx])
[<bf0110a8>] (i2c_imx_remove [i2c_imx]) from [<c051a838>] (platform_drv_remove+0x2c/0x44)
[<c051a80c>] (platform_drv_remove) from [<c05183d8>] (__device_release_driver+0x90/0x12c)
[<c0518348>] (__device_release_driver) from [<c051849c>] (device_release_driver+0x28/0x34)
[<c0518474>] (device_release_driver) from [<c0517150>] (unbind_store+0x80/0x104)
[<c05170d0>] (unbind_store) from [<c0516520>] (drv_attr_store+0x28/0x34)
[<c05164f8>] (drv_attr_store) from [<c0298acc>] (sysfs_kf_write+0x50/0x54)
[<c0298a7c>] (sysfs_kf_write) from [<c029801c>] (kernfs_fop_write+0x100/0x214)
[<c0297f1c>] (kernfs_fop_write) from [<c0220130>] (__vfs_write+0x34/0x120)
[<c02200fc>] (__vfs_write) from [<c0221088>] (vfs_write+0xa8/0x170)
[<c0220fe0>] (vfs_write) from [<c0221e74>] (SyS_write+0x4c/0xa8)
[<c0221e28>] (SyS_write) from [<c0108a20>] (ret_fast_syscall+0x0/0x1c)
Signed-off-by: Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/i2c/i2c-core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/i2c/i2c-core.c
+++ b/drivers/i2c/i2c-core.c
@@ -1876,6 +1876,7 @@ int i2c_register_driver(struct module *o
/* add the driver to the list of i2c drivers in the driver core */
driver->driver.owner = owner;
driver->driver.bus = &i2c_bus_type;
+ INIT_LIST_HEAD(&driver->clients);
/* When registration returns, the driver core
* will have called probe() for all matching-but-unbound devices.
@@ -1886,7 +1887,6 @@ int i2c_register_driver(struct module *o
pr_debug("i2c-core: driver [%s] registered\n", driver->driver.name);
- INIT_LIST_HEAD(&driver->clients);
/* Walk the adapters that are already present */
i2c_for_each_dev(driver, __process_new_driver);
^ permalink raw reply
* Re: [PATCH nft] tests: shell: add test case for inserting element into verdict map
From: Arturo Borrero Gonzalez @ 2016-11-09 10:50 UTC (permalink / raw)
To: Liping Zhang
Cc: Pablo Neira Ayuso, Netfilter Development Mailing list,
Liping Zhang
In-Reply-To: <1478617597-13459-1-git-send-email-zlpnobody@163.com>
On 8 November 2016 at 16:06, Liping Zhang <zlpnobody@163.com> wrote:
> From: Liping Zhang <zlpnobody@gmail.com>
>
> "dalegaard@gmail.com" reports that when inserting an element into a
> verdict map, kernel crash will happen. Now add this test case so we
> can avoid future regressions fail.
>
> Signed-off-by: Liping Zhang <zlpnobody@gmail.com>
> ---
> .../shell/testcases/sets/0008create_verdict_map_0 | 25 ++++++++++++++++++++++
> 1 file changed, 25 insertions(+)
> create mode 100755 tests/shell/testcases/sets/0008create_verdict_map_0
>
Acked-by: Arturo Borrero Gonzalez <arturo@debian.org>
^ permalink raw reply
* [PATCH 4.4 07/69] mm: memcontrol: do not recurse in direct reclaim
From: Greg Kroah-Hartman @ 2016-11-09 10:43 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Johannes Weiner, Michal Hocko,
Vladimir Davydov, Tejun Heo, Andrew Morton, Linus Torvalds
In-Reply-To: <20161109102901.127641653@linuxfoundation.org>
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Johannes Weiner <hannes@cmpxchg.org>
commit 89a2848381b5fcd9c4d9c0cd97680e3b28730e31 upstream.
On 4.0, we saw a stack corruption from a page fault entering direct
memory cgroup reclaim, calling into btrfs_releasepage(), which then
tried to allocate an extent and recursed back into a kmem charge ad
nauseam:
[...]
btrfs_releasepage+0x2c/0x30
try_to_release_page+0x32/0x50
shrink_page_list+0x6da/0x7a0
shrink_inactive_list+0x1e5/0x510
shrink_lruvec+0x605/0x7f0
shrink_zone+0xee/0x320
do_try_to_free_pages+0x174/0x440
try_to_free_mem_cgroup_pages+0xa7/0x130
try_charge+0x17b/0x830
memcg_charge_kmem+0x40/0x80
new_slab+0x2d9/0x5a0
__slab_alloc+0x2fd/0x44f
kmem_cache_alloc+0x193/0x1e0
alloc_extent_state+0x21/0xc0
__clear_extent_bit+0x2b5/0x400
try_release_extent_mapping+0x1a3/0x220
__btrfs_releasepage+0x31/0x70
btrfs_releasepage+0x2c/0x30
try_to_release_page+0x32/0x50
shrink_page_list+0x6da/0x7a0
shrink_inactive_list+0x1e5/0x510
shrink_lruvec+0x605/0x7f0
shrink_zone+0xee/0x320
do_try_to_free_pages+0x174/0x440
try_to_free_mem_cgroup_pages+0xa7/0x130
try_charge+0x17b/0x830
mem_cgroup_try_charge+0x65/0x1c0
handle_mm_fault+0x117f/0x1510
__do_page_fault+0x177/0x420
do_page_fault+0xc/0x10
page_fault+0x22/0x30
On later kernels, kmem charging is opt-in rather than opt-out, and that
particular kmem allocation in btrfs_releasepage() is no longer being
charged and won't recurse and overrun the stack anymore.
But it's not impossible for an accounted allocation to happen from the
memcg direct reclaim context, and we needed to reproduce this crash many
times before we even got a useful stack trace out of it.
Like other direct reclaimers, mark tasks in memcg reclaim PF_MEMALLOC to
avoid recursing into any other form of direct reclaim. Then let
recursive charges from PF_MEMALLOC contexts bypass the cgroup limit.
Link: http://lkml.kernel.org/r/20161025141050.GA13019@cmpxchg.org
Signed-off-by: Johannes Weiner <hannes@cmpxchg.org>
Acked-by: Michal Hocko <mhocko@suse.com>
Cc: Vladimir Davydov <vdavydov.dev@gmail.com>
Cc: Tejun Heo <tj@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
mm/memcontrol.c | 9 +++++++++
mm/vmscan.c | 2 ++
2 files changed, 11 insertions(+)
--- a/mm/memcontrol.c
+++ b/mm/memcontrol.c
@@ -2055,6 +2055,15 @@ retry:
current->flags & PF_EXITING))
goto force;
+ /*
+ * Prevent unbounded recursion when reclaim operations need to
+ * allocate memory. This might exceed the limits temporarily,
+ * but we prefer facilitating memory reclaim and getting back
+ * under the limit over triggering OOM kills in these cases.
+ */
+ if (unlikely(current->flags & PF_MEMALLOC))
+ goto force;
+
if (unlikely(task_in_memcg_oom(current)))
goto nomem;
--- a/mm/vmscan.c
+++ b/mm/vmscan.c
@@ -2910,7 +2910,9 @@ unsigned long try_to_free_mem_cgroup_pag
sc.may_writepage,
sc.gfp_mask);
+ current->flags |= PF_MEMALLOC;
nr_reclaimed = do_try_to_free_pages(zonelist, &sc);
+ current->flags &= ~PF_MEMALLOC;
trace_mm_vmscan_memcg_reclaim_end(nr_reclaimed);
^ permalink raw reply
* [PATCH 4.4 08/69] KEYS: Fix short sprintf buffer in /proc/keys show function
From: Greg Kroah-Hartman @ 2016-11-09 10:43 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Ondrej Kozina, David Howells,
James Morris
In-Reply-To: <20161109102901.127641653@linuxfoundation.org>
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: David Howells <dhowells@redhat.com>
commit 03dab869b7b239c4e013ec82aea22e181e441cfc upstream.
This fixes CVE-2016-7042.
Fix a short sprintf buffer in proc_keys_show(). If the gcc stack protector
is turned on, this can cause a panic due to stack corruption.
The problem is that xbuf[] is not big enough to hold a 64-bit timeout
rendered as weeks:
(gdb) p 0xffffffffffffffffULL/(60*60*24*7)
$2 = 30500568904943
That's 14 chars plus NUL, not 11 chars plus NUL.
Expand the buffer to 16 chars.
I think the unpatched code apparently works if the stack-protector is not
enabled because on a 32-bit machine the buffer won't be overflowed and on a
64-bit machine there's a 64-bit aligned pointer at one side and an int that
isn't checked again on the other side.
The panic incurred looks something like:
Kernel panic - not syncing: stack-protector: Kernel stack is corrupted in: ffffffff81352ebe
CPU: 0 PID: 1692 Comm: reproducer Not tainted 4.7.2-201.fc24.x86_64 #1
Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011
0000000000000086 00000000fbbd2679 ffff8800a044bc00 ffffffff813d941f
ffffffff81a28d58 ffff8800a044bc98 ffff8800a044bc88 ffffffff811b2cb6
ffff880000000010 ffff8800a044bc98 ffff8800a044bc30 00000000fbbd2679
Call Trace:
[<ffffffff813d941f>] dump_stack+0x63/0x84
[<ffffffff811b2cb6>] panic+0xde/0x22a
[<ffffffff81352ebe>] ? proc_keys_show+0x3ce/0x3d0
[<ffffffff8109f7f9>] __stack_chk_fail+0x19/0x30
[<ffffffff81352ebe>] proc_keys_show+0x3ce/0x3d0
[<ffffffff81350410>] ? key_validate+0x50/0x50
[<ffffffff8134db30>] ? key_default_cmp+0x20/0x20
[<ffffffff8126b31c>] seq_read+0x2cc/0x390
[<ffffffff812b6b12>] proc_reg_read+0x42/0x70
[<ffffffff81244fc7>] __vfs_read+0x37/0x150
[<ffffffff81357020>] ? security_file_permission+0xa0/0xc0
[<ffffffff81246156>] vfs_read+0x96/0x130
[<ffffffff81247635>] SyS_read+0x55/0xc0
[<ffffffff817eb872>] entry_SYSCALL_64_fastpath+0x1a/0xa4
Reported-by: Ondrej Kozina <okozina@redhat.com>
Signed-off-by: David Howells <dhowells@redhat.com>
Tested-by: Ondrej Kozina <okozina@redhat.com>
Signed-off-by: James Morris <james.l.morris@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
security/keys/proc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/security/keys/proc.c
+++ b/security/keys/proc.c
@@ -181,7 +181,7 @@ static int proc_keys_show(struct seq_fil
struct timespec now;
unsigned long timo;
key_ref_t key_ref, skey_ref;
- char xbuf[12];
+ char xbuf[16];
int rc;
struct keyring_search_context ctx = {
^ permalink raw reply
* Re: [PATCH v3] btrfs-progs: send-test: add checking of clone-src option
From: David Sterba @ 2016-11-09 10:49 UTC (permalink / raw)
To: Tsutomu Itoh; +Cc: quwenruo, linux-btrfs
In-Reply-To: <201611090444.AA00014@WIN-5MHF4RKU941.jp.fujitsu.com>
On Wed, Nov 09, 2016 at 01:44:15PM +0900, Tsutomu Itoh wrote:
> V2: old sending stream image is used
> V3: image file has been compressed by gzip
Thanks. Should be compressed by 'xz -9', the result is now 2k instead of
11k. The extract_image now understands compressed streams. Test script
updated.
^ permalink raw reply
* [PATCH 4.4 20/69] mei: txe: dont clean an unprocessed interrupt cause.
From: Greg Kroah-Hartman @ 2016-11-09 10:43 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Alexander Usyskin, Tomas Winkler
In-Reply-To: <20161109102901.127641653@linuxfoundation.org>
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Alexander Usyskin <alexander.usyskin@intel.com>
commit 43605e293eb13c07acb546c14f407a271837af17 upstream.
SEC registers are not accessible when the TXE device is in low power
state, hence the SEC interrupt cannot be processed if device is not
awake.
In some rare cases entrance to low power state (aliveness off) and input
ready bits can be signaled at the same time, resulting in communication
stall as input ready won't be signaled again after waking up. To resolve
this IPC_HHIER_SEC bit in HHISR_REG should not be cleaned if the
interrupt is not processed.
Signed-off-by: Alexander Usyskin <alexander.usyskin@intel.com>
Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/misc/mei/hw-txe.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
--- a/drivers/misc/mei/hw-txe.c
+++ b/drivers/misc/mei/hw-txe.c
@@ -972,11 +972,13 @@ static bool mei_txe_check_and_ack_intrs(
hisr = mei_txe_br_reg_read(hw, HISR_REG);
aliveness = mei_txe_aliveness_get(dev);
- if (hhisr & IPC_HHIER_SEC && aliveness)
+ if (hhisr & IPC_HHIER_SEC && aliveness) {
ipc_isr = mei_txe_sec_reg_read_silent(hw,
SEC_IPC_HOST_INT_STATUS_REG);
- else
+ } else {
ipc_isr = 0;
+ hhisr &= ~IPC_HHIER_SEC;
+ }
generated = generated ||
(hisr & HISR_INT_STS_MSK) ||
^ permalink raw reply
* [PATCH 4.4 10/69] ALSA: hda - Merge RIRB_PRE_DELAY into CTX_WORKAROUND caps
From: Greg Kroah-Hartman @ 2016-11-09 10:43 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Takashi Iwai
In-Reply-To: <20161109102901.127641653@linuxfoundation.org>
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Takashi Iwai <tiwai@suse.de>
commit ef85f299c74e6c5dd98ec0230183be33f4c2813d upstream.
AZX_DCAPS_RIRB_PRE_DELAY is always tied with AZX_DCAPS_CTX_WORKAROUND,
which is Creative's XFi specific. So, we can replace it and reduce
one more bit free for DCAPS.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
sound/pci/hda/hda_controller.c | 2 +-
sound/pci/hda/hda_controller.h | 2 +-
sound/pci/hda/hda_intel.c | 6 ++----
3 files changed, 4 insertions(+), 6 deletions(-)
--- a/sound/pci/hda/hda_controller.c
+++ b/sound/pci/hda/hda_controller.c
@@ -956,7 +956,7 @@ irqreturn_t azx_interrupt(int irq, void
status = azx_readb(chip, RIRBSTS);
if (status & RIRB_INT_MASK) {
if (status & RIRB_INT_RESPONSE) {
- if (chip->driver_caps & AZX_DCAPS_RIRB_PRE_DELAY)
+ if (chip->driver_caps & AZX_DCAPS_CTX_WORKAROUND)
udelay(80);
snd_hdac_bus_update_rirb(bus);
}
--- a/sound/pci/hda/hda_controller.h
+++ b/sound/pci/hda/hda_controller.h
@@ -33,7 +33,7 @@
#define AZX_DCAPS_SNOOP_MASK (3 << 10) /* snoop type mask */
#define AZX_DCAPS_SNOOP_OFF (1 << 12) /* snoop default off */
#define AZX_DCAPS_RIRB_DELAY (1 << 13) /* Long delay in read loop */
-#define AZX_DCAPS_RIRB_PRE_DELAY (1 << 14) /* Put a delay before read */
+/* 14 unused */
#define AZX_DCAPS_CTX_WORKAROUND (1 << 15) /* X-Fi workaround */
#define AZX_DCAPS_POSFIX_LPIB (1 << 16) /* Use LPIB as default */
#define AZX_DCAPS_POSFIX_VIA (1 << 17) /* Use VIACOMBO as default */
--- a/sound/pci/hda/hda_intel.c
+++ b/sound/pci/hda/hda_intel.c
@@ -2406,14 +2406,12 @@ static const struct pci_device_id azx_id
.class = PCI_CLASS_MULTIMEDIA_HD_AUDIO << 8,
.class_mask = 0xffffff,
.driver_data = AZX_DRIVER_CTX | AZX_DCAPS_CTX_WORKAROUND |
- AZX_DCAPS_NO_64BIT |
- AZX_DCAPS_RIRB_PRE_DELAY | AZX_DCAPS_POSFIX_LPIB },
+ AZX_DCAPS_NO_64BIT | AZX_DCAPS_POSFIX_LPIB },
#else
/* this entry seems still valid -- i.e. without emu20kx chip */
{ PCI_DEVICE(0x1102, 0x0009),
.driver_data = AZX_DRIVER_CTX | AZX_DCAPS_CTX_WORKAROUND |
- AZX_DCAPS_NO_64BIT |
- AZX_DCAPS_RIRB_PRE_DELAY | AZX_DCAPS_POSFIX_LPIB },
+ AZX_DCAPS_NO_64BIT | AZX_DCAPS_POSFIX_LPIB },
#endif
/* CM8888 */
{ PCI_DEVICE(0x13f6, 0x5011),
^ permalink raw reply
* [PATCH 4.4 25/69] usb: increase ohci watchdog delay to 275 msec
From: Greg Kroah-Hartman @ 2016-11-09 10:44 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Bryan Paluch, Alan Stern
In-Reply-To: <20161109102901.127641653@linuxfoundation.org>
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Bryan Paluch <bryanpaluch@gmail.com>
commit ed6d6f8f42d7302f6f9b6245f34927ec20d26c12 upstream.
Increase ohci watchout delay to 275 ms. Previous delay was 250 ms
with 20 ms of slack, after removing slack time some ohci controllers don't
respond in time. Logs from systems with controllers that have the
issue would show "HcDoneHead not written back; disabled"
Signed-off-by: Bryan Paluch <bryanpaluch@gmail.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/usb/host/ohci-hcd.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/usb/host/ohci-hcd.c
+++ b/drivers/usb/host/ohci-hcd.c
@@ -72,7 +72,7 @@
static const char hcd_name [] = "ohci_hcd";
#define STATECHANGE_DELAY msecs_to_jiffies(300)
-#define IO_WATCHDOG_DELAY msecs_to_jiffies(250)
+#define IO_WATCHDOG_DELAY msecs_to_jiffies(275)
#include "ohci.h"
#include "pci-quirks.h"
^ permalink raw reply
* [PATCH] arm64: acpi: arch_apei_get_mem_attributes() should use memblock
From: James Morse @ 2016-11-09 10:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <168e341f-2377-2962-34a4-63043d5ab6d6@codeaurora.org>
Hi Tyler,
On 08/11/16 18:41, Baicar, Tyler wrote:
> This patch seems fine, APEI/GHES functionality still works properly for me.
> I tested on a 4.8 kernel with the patch you mention below from Jonathan and
> my patchset https://lkml.org/lkml/2016/10/21/746
What are the memory attributes of the region your firmware writes the error
status data to?
I guess its attributes in the UEFI memory map must be 'NC' or <empty>. In which
case the current default of Device_nGnRnE isn't so wrong. Otherwise your
firmware must be doing some cache cleaning, which shouldn't be necessary.
> My only question is when you say that this may be called from an NMI context.
> arch_apei_get_mem_attributes() only gets called from ghes_ioremap_pfn_irq()
> which only appears to get called if we are not in an NMI context.
Yes, that's broken too.
ghes_ioremap_pfn_nmi() assumes PAGE_KERNEL. If firmware writes the error data
via a non-cachable mapping, it will tell us this via the UEFI memory map, which
we currently misread.
I have patches to fix this too, but it isn't needed until someone turns on
CONFIG_HAVE_ACPI_APEI_NMI on arm64 (or ia64...).
> So can this really be called from an NMI context?
Not today, but it may be in the future. Re-mapping the EFI memory map to read it
is possible in the short term, but generates more work if we ever want to
support CONFIG_HAVE_ACPI_APEI_NMI. I implied all this into the word 'may', I
will try to be clearer next time!
Thanks,
James
^ permalink raw reply
* [PATCH 4.4 27/69] Fix potential infoleak in older kernels
From: Greg Kroah-Hartman @ 2016-11-09 10:44 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable
In-Reply-To: <20161109102901.127641653@linuxfoundation.org>
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Linus Torvalds <torvalds@linux-foundation.org>
Not upstream as it is not needed there.
So a patch something like this might be a safe way to fix the
potential infoleak in older kernels.
THIS IS UNTESTED. It's a very obvious patch, though, so if it compiles
it probably works. It just initializes the output variable with 0 in
the inline asm description, instead of doing it in the exception
handler.
It will generate slightly worse code (a few unnecessary ALU
operations), but it doesn't have any interactions with the exception
handler implementation.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/x86/include/asm/uaccess.h | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
--- a/arch/x86/include/asm/uaccess.h
+++ b/arch/x86/include/asm/uaccess.h
@@ -332,7 +332,7 @@ do { \
#define __get_user_asm_u64(x, ptr, retval, errret) \
__get_user_asm(x, ptr, retval, "q", "", "=r", errret)
#define __get_user_asm_ex_u64(x, ptr) \
- __get_user_asm_ex(x, ptr, "q", "", "=r")
+ __get_user_asm_ex(x, ptr, "q", "", "=&r")
#endif
#define __get_user_size(x, ptr, size, retval, errret) \
@@ -375,13 +375,13 @@ do { \
__chk_user_ptr(ptr); \
switch (size) { \
case 1: \
- __get_user_asm_ex(x, ptr, "b", "b", "=q"); \
+ __get_user_asm_ex(x, ptr, "b", "b", "=&q"); \
break; \
case 2: \
- __get_user_asm_ex(x, ptr, "w", "w", "=r"); \
+ __get_user_asm_ex(x, ptr, "w", "w", "=&r"); \
break; \
case 4: \
- __get_user_asm_ex(x, ptr, "l", "k", "=r"); \
+ __get_user_asm_ex(x, ptr, "l", "k", "=&r"); \
break; \
case 8: \
__get_user_asm_ex_u64(x, ptr); \
@@ -395,7 +395,7 @@ do { \
asm volatile("1: mov"itype" %1,%"rtype"0\n" \
"2:\n" \
_ASM_EXTABLE_EX(1b, 2b) \
- : ltype(x) : "m" (__m(addr)))
+ : ltype(x) : "m" (__m(addr)), "0" (0))
#define __put_user_nocheck(x, ptr, size) \
({ \
^ permalink raw reply
* [PATCH 4.4 29/69] hv: do not lose pending heartbeat vmbus packets
From: Greg Kroah-Hartman @ 2016-11-09 10:44 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Long Li, K. Y. Srinivasan
In-Reply-To: <20161109102901.127641653@linuxfoundation.org>
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Long Li <longli@microsoft.com>
commit 407a3aee6ee2d2cb46d9ba3fc380bc29f35d020c upstream.
The host keeps sending heartbeat packets independent of the
guest responding to them. Even though we respond to the heartbeat messages at
interrupt level, we can have situations where there maybe multiple heartbeat
messages pending that have not been responded to. For instance this occurs when the
VM is paused and the host continues to send the heartbeat messages.
Address this issue by draining and responding to all
the heartbeat messages that maybe pending.
Signed-off-by: Long Li <longli@microsoft.com>
Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/hv/hv_util.c | 10 +++++++---
1 file changed, 7 insertions(+), 3 deletions(-)
--- a/drivers/hv/hv_util.c
+++ b/drivers/hv/hv_util.c
@@ -283,10 +283,14 @@ static void heartbeat_onchannelcallback(
u8 *hbeat_txf_buf = util_heartbeat.recv_buffer;
struct icmsg_negotiate *negop = NULL;
- vmbus_recvpacket(channel, hbeat_txf_buf,
- PAGE_SIZE, &recvlen, &requestid);
+ while (1) {
+
+ vmbus_recvpacket(channel, hbeat_txf_buf,
+ PAGE_SIZE, &recvlen, &requestid);
+
+ if (!recvlen)
+ break;
- if (recvlen > 0) {
icmsghdrp = (struct icmsg_hdr *)&hbeat_txf_buf[
sizeof(struct vmbuspipe_hdr)];
^ 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.