, just drop the in-kernel
copy of the ion code now, as it's not used, and is only causing problems
for everyone involved.
Cc: "Arve Hjønnevåg"
Cc: "Christian König"
Cc: Christian Brauner
Cc: Christoph Hellwig
Cc: Hridya Valsaraju
Cc: Joel Fernandes
Cc: John Stultz
Cc: Laura
this year are:
Chris Mason (chair)
Dan Williams
Kees Cook
Laura Abbott
Olof Johansson
The remaining members' terms will expire in 2021:
Greg Kroah-Hartman
Jonathan Corbet
Sasha Levin
Steven Rostedt
Ted Ts'o
On 8/13/20 10:31 AM, Johannes Berg wrote:
Hi Laura,
Seeing your reminder reminded me :)
We will be using the electronic voting method that we used in 2019. All
Linux Plumbers Attendees will automatically receive a ballot. Anyone
who is otherwise eligible to vote should e-mail
On 7/27/20 5:31 PM, Laura Abbott wrote:
On behalf of the Linux Foundation Technical Advisory Board (TAB), I'd
like to announce the voting procedures for the 2020 TAB elections.
The pool of eligible voters will consist of the following:
1) All attendees of the Linux Plumbers conference (i.e
On behalf of the Linux Foundation Technical Advisory Board (TAB), I'd
like to announce the voting procedures for the 2020 TAB elections.
The pool of eligible voters will consist of the following:
1) All attendees of the Linux Plumbers conference (i.e. kernel summit)
2) Anyone who is not a
-by: Laura Abbott
On 10/19/19 6:51 AM, Kalle Valo wrote:
Laura Abbott writes:
Nicolas Waisman noticed that even though noa_len is checked for
a compatible length it's still possible to overrun the buffers
of p2pinfo since there's no check on the upper bound of noa_num.
Bound noa_num against P2P_MAX_NOA_NUM
] Error 2
make: *** Waiting for unfinished jobs
This is because iio_utils.o is used across multiple targets.
Fix this by making iio_utils.o a proper dependency.
Signed-off-by: Laura Abbott
---
I realize that we don't really need the parallelization for tools
because it's so small but when
Nicolas Waisman noticed that even though noa_len is checked for
a compatible length it's still possible to overrun the buffers
of p2pinfo since there's no check on the upper bound of noa_num.
Bound noa_num against P2P_MAX_NOA_NUM.
Reported-by: Nicolas Waisman
Signed-off-by: Laura Abbott
---
v2
Nicolas Waisman noticed that even though noa_len is checked for
a compatible length it's still possible to overrun the buffers
of p2pinfo since there's no check on the upper bound of noa_num.
Bounds check noa_num against P2P_MAX_NOA_NUM.
Reported-by: Nicolas Waisman
Signed-off-by: Laura Abbott
On 10/7/19 9:26 PM, Al Viro wrote:
On Mon, Oct 07, 2019 at 05:50:31PM -0700, Hugh Dickins wrote:
[sorry for being MIA - had been sick through the last week, just digging
myself from under piles of mail; my apologies]
(tmpfs, very tiresomely, supports a NUMA "mpol" mount option which can
have
On 9/30/19 12:07 PM, Laura Abbott wrote:
Hi,
Fedora got a bug report https://bugzilla.redhat.com/show_bug.cgi?id=1757104
of a failure to parse options with the context mount option. From the reporter:
$ unshare -rm mount -t tmpfs tmpfs /tmp -o
'context="system_u:object_r:container_file
Hi,
Fedora got a bug report https://bugzilla.redhat.com/show_bug.cgi?id=1757104
of a failure to parse options with the context mount option. From the reporter:
$ unshare -rm mount -t tmpfs tmpfs /tmp -o
'context="system_u:object_r:container_file_t:s0:c475,c690"'
mount: /tmp: wrong fs type,
On 9/16/19 8:21 AM, Mike Rapoport wrote:
From: Mike Rapoport
arm64 calls memblock_free() for the initrd area in its implementation of
free_initrd_mem(), but this call has no actual effect that late in the boot
process. By the time initrd is freed, all the reserved memory is managed by
the page
The following are the results of the 2019 Technical Advisory Board (TAB)
elections:
1. Greg Kroah-Hartman
2. Jonathan Corbet
3. Steven Rostedt
4. Ted Ts’o
5. Sasha Levin
Thank you to all of the candidates for stepping up and running this year. We
appreciate your willingness to serve the kernel
> On Aug 28, 2019, at 1:48 PM, Laura Abbott wrote:
>
>
>> On Aug 9, 2019, at 2:26 AM, Laura Abbott wrote:
>>
>> Hello everyone,
>>
>> Friendly reminder that the TAB elections are coming soon:
>>
>> The Linux Foundation Technical Advi
> On Sep 3, 2019, at 7:13 AM, Laura Abbott wrote:
>
> Hi,
>
> On behalf of the Linux Foundation Technical Advisory Board (TAB), I'd like to
> take this opportunity to announce the voting procedures for the 2019 TAB
> elections. As was announced[1], this year we are moving
Hi,
On behalf of the Linux Foundation Technical Advisory Board (TAB), I'd like to
take this opportunity to announce the voting procedures for the 2019 TAB
elections. As was announced[1], this year we are moving to electronic voting.
Everyone who is registered for kernel summit (co-located with
> On Aug 9, 2019, at 2:26 AM, Laura Abbott wrote:
>
> Hello everyone,
>
> Friendly reminder that the TAB elections are coming soon:
>
> The Linux Foundation Technical Advisory Board (TAB) serves as the
> interface between the kernel development community and the Lin
2017
Ted Tso 2017
Tim Bird2017
Chris Mason 2018
Laura Abbott2018
Olof Johansson 2018
Kees Cook 2018
Dan Williams2018
The five slots from 2017 are all up for election. As always, please
let us know
linked in:
[4.586620] ---[ end trace f67eb9af4d8d492b ]---
Fix this by ensuring the value we set with set_freepointer is either NULL
or another value in the chain.
Reported-by: kernel test robot
Signed-off-by: Laura Abbott
---
mm/slub.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
On 7/29/19 5:43 AM, kernel test robot wrote:
FYI, we noticed the following commit (built with gcc-7):
commit: 6471384af2a6530696fc0203bafe4de41a23c9ef ("mm: security: introduce
init_on_alloc=1 and init_on_free=1 boot options")
On 7/17/19 12:31 PM, Alexander Popov wrote:
Hello!
The syzkaller [1] has a trouble with fuzzing the Linux kernel with ION Memory
Allocator.
Syzkaller uses several methods [2] to limit memory consumption of the userspace
processes calling the syscalls for testing the kernel:
- setrlimit(),
On 6/18/19 10:15 AM, Arnd Bergmann wrote:
On Tue, Jun 18, 2019 at 2:03 PM Will Deacon wrote:
From 6e004b8824d4eb6a4e61cd794fbc3a761b50135b Mon Sep 17 00:00:00 2001
From: Will Deacon
Date: Tue, 18 Jun 2019 12:56:49 +0100
Subject: [PATCH] genksyms: Teach parse about __uint128_t built-in type
On 7/1/19 5:02 PM, Tetsuo Handa wrote:
On 2019/07/01 23:02, Sumit Semwal wrote:
Acked-by: Laura Abbott
fwiw, Acked-by: Sumit Semwal
Thank you for responding. You can carry this patch via whichever tree you like.
By the way, is "memory allocation from ion_system_heap_allocate() is ca
set_section_perms(perms, n, true, s->mm);
}
set_section_perms(perms, n, true, current->active_mm);
set_section_perms(perms, n, true, _mm);
Acked-by: Laura Abbott
On 7/1/19 6:55 AM, Tetsuo Handa wrote:
Andrew, can you pick up this patch? No response from Laura Abbott nor Sumit
Semwal.
On 2019/06/21 18:58, Tetsuo Handa wrote:
From e0758655727044753399fb4f7c5f3eb25ac5cccd Mon Sep 17 00:00:00 2001
From: Tetsuo Handa
Date: Fri, 21 Jun 2019 11:22:51 +0900
, perhaps providing a
Tested-by: to add to this,
built okay on the tree that previously failed
Tested-by: Laura Abbott
Thanks,
- Arnaldo
commit a04ef2eb0a66d9479e75e536d919c8c9cd618ee3
Author: Arnaldo Carvalho de Melo
Date: Thu Jun 13 12:04:19 2019 -0300
tools build: Check
Hi,
While doing some build experiments, I found a compile failure with perf and
jvmti:
BUILDSTDERR: gcc -Wp,-MD,./.xsk.o.d -Wp,-MT,xsk.o -O2 -g -pipe -Wall
-Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS
-fexceptions -fstack-protector-strong
ee9c52d7ac ("tpm: tpm1: rewrite tpm1_get_random() using
tpm_buf structure")
Cc: Laura Abbott
Cc: Tomas Winkler
Cc: Jarkko Sakkinen
Cc: sta...@vger.kernel.org
Signed-off-by: Kees Cook
---
v3: fix never-succeed, limit checks to tpm cmd return (James, Jason)
v2: also fix tpm2 implementat
On 4/22/19 8:49 PM, Masahiro Yamada wrote:
This prepares to move CONFIG_OPTIMIZE_INLINING from x86 to a common
place. We need to eliminate potential issues beforehand.
If it is enabled for s390, the following error is reported:
In file included from arch/s390/crypto/des_s390.c:19:
On 5/16/19 3:46 AM, Will Deacon wrote:
On Thu, May 16, 2019 at 01:58:56PM +0900, Masahiro Yamada wrote:
On Thu, May 16, 2019 at 4:51 AM Laura Abbott wrote:
Commit 691efbedc60d ("arm64: vdso: use $(LD) instead of $(CC) to
link VDSO") switched to using LD explicitly. The --build
Commit 691efbedc60d ("arm64: vdso: use $(LD) instead of $(CC) to
link VDSO") switched to using LD explicitly. The --build-id option
needs to be passed explicitly, similar to x86. Add this option.
Fixes: 691efbedc60d ("arm64: vdso: use $(LD) instead of $(CC) to link VDSO")
On 5/10/19 3:43 PM, Kees Cook wrote:
This feature continues to cause more problems than it solves[1]. Its
intention was to check the bounds of page-allocator allocations by using
__GFP_COMP, for which we would need to find all missing __GFP_COMP
markings. This work has been on hold and there is
Hi,
Fedora got a bug report of a panic with kernels > 5.0:
Mar 20 10:52:38 kernel: BUG: unable to handle kernel NULL pointer dereference
at 0043
Mar 20 10:52:38 kernel: #PF error: [normal kernel read fault]
Mar 20 10:52:38 kernel: PGD 8003de1d7067 P4D 8003de1d7067 PUD
On 3/6/19 9:01 AM, John Stultz wrote:
On Wed, Mar 6, 2019 at 8:14 AM Benjamin Gaignard
wrote:
Le mar. 5 mars 2019 à 21:54, John Stultz a écrit :
+
+ printf("Allocating 1 MEG\n");
+ ret = dmabuf_heap_alloc(heap_fd, ONE_MEG, 0, _fd);
+ if (ret)
+ goto out;
+
+
Hi,
I'm working on organizing a microconference for Linux Plumbers 2019
focused on distribution kernels. The focus is on collaboration on
common problems for maintaining and distributing a kernel for any
kind of distribution (embedded, enterprise, community, internal, extrnal).
Ideally, this
l/sys_ni.c for the new system
calls.
Cc: Laura Abbott
Cc: John Stultz
Cc: Thomas Gleixner
Signed-off-by: Arnd Bergmann
---
I'm about to send off my pull requests for arm-soc, so I'd just
send another one with just this common from my y2038 tree.
---
kernel/sys_ni.c | 3 +++
1 file changed, 3
using fault injection.
Fix it by skipping the second free.
Reported-by: syzbot+e73f2fb5ed5a5df36...@syzkaller.appspotmail.com
Fixes: af33a9190d02 ("drm/vgem: Enable dmabuf import interfaces")
Reviewed-by: Chris Wilson
Cc: Laura Abbott
Cc: Daniel Vetter
Cc: sta...@vger.kernel.org
Signed-of
On 2/22/19 5:42 AM, Ritesh Harjani wrote:
Hi Laura,
On 2/19/2019 12:59 AM, Laura Abbott wrote:
Hi,
Fedora got report of a panic when I accidentally left debugging enabled
on a build https://bugzilla.redhat.com/show_bug.cgi?id=1677438
It looks like a panic from code in CONFIG_FAIL_MMC_REQUEST
On 2/20/19 12:58 AM, Heiko Carstens wrote:
On Sat, Feb 09, 2019 at 12:34:20PM -0800, Laura Abbott wrote:
On 2/5/19 12:43 PM, Heiko Carstens wrote:
On Tue, Jan 29, 2019 at 08:25:58AM +0100, Laura Abbott wrote:
On 1/23/19 5:24 AM, Heiko Carstens wrote:
On Wed, Jan 23, 2019 at 01:55:13PM +0100
On 1/24/19 8:44 AM, Brian Starkey wrote:
On Thu, Jan 24, 2019 at 10:04:46AM -0600, Andrew F. Davis wrote:
On 1/23/19 11:11 AM, Brian Starkey wrote:
[snip]
I'm very new to all this, so any pointers to history in this area are
appreciated.
[snip]
In case you didn't come across it
(i = 0; i < NUM_ORDERS; i++) {
struct ion_page_pool *pool;
+ gfp_t gfp_flags = low_order_gfp_flags;
if (orders[i] > 4)
gfp_flags = high_order_gfp_flags;
Acked-by: Laura Abbott
On 2/15/19 11:01 AM, John Stultz wrote:
On Fri, Feb 15, 2019 at 2:51 AM Brian Starkey wrote:
Hi John,
On Thu, Feb 14, 2019 at 09:38:29AM -0800, John Stultz wrote:
[snip]
Some thoughts, as this ABI break has the potential to be pretty painful.
1) Unfortunately, this ABI is exposed
Hi,
Fedora got report of a panic when I accidentally left debugging enabled
on a build https://bugzilla.redhat.com/show_bug.cgi?id=1677438
It looks like a panic from code in CONFIG_FAIL_MMC_REQUEST from the
cqhci driver because there isn't a command (high level overview)
(gdb) list
On 2/11/19 11:09 PM, Jing Xia wrote:
gfp_flags is always set high_order_gfp_flags even if allocations of
order 0 are made.But for smaller allocations, the system should be able
to reclaim some memory.
Signed-off-by: Jing Xia
Reviewed-by: Yuming Han
Reviewed-by: Zhaoyang Huang
Reviewed-by:
On 2/12/19 7:52 AM, Khalid Aziz wrote:
On 1/23/19 7:24 AM, Konrad Rzeszutek Wilk wrote:
On Thu, Jan 10, 2019 at 02:09:37PM -0700, Khalid Aziz wrote:
From: Juerg Haefliger
Enable support for eXclusive Page Frame Ownership (XPFO) for arm64 and
provide a hook for updating a single kernel page
On 2/5/19 12:43 PM, Heiko Carstens wrote:
On Tue, Jan 29, 2019 at 08:25:58AM +0100, Laura Abbott wrote:
On 1/23/19 5:24 AM, Heiko Carstens wrote:
On Wed, Jan 23, 2019 at 01:55:13PM +0100, Laura Abbott wrote:
There's a build failure with gcc9:
./arch/s390/include/asm/jump_label.h: Assembler
inux/module.h | 4 ++--
lib/crc32.c | 4 ++--
3 files changed, 18 insertions(+), 4 deletions(-)
For the entire series:
Tested-by: Laura Abbott
You can look at the full build logs at
https://koji.fedoraproject.org/koji/taskinfo?taskID=326911 .
Thanks,
Laura
On 2/4/19 1:40 AM, David Disseldorp wrote:
Hi Laura,
Thanks for the report...
On Sun, 3 Feb 2019 17:56:00 +0100, Laura Abbott wrote:
Fedora got a bug report of a new permission denied error with 5.0-rc2:
File "/usr/lib/python3.7/site-packages/rtslib_fb/utils.py", line 100,
Hi,
Fedora got a bug report of a new permission denied error with 5.0-rc2:
File "/usr/lib/python3.7/site-packages/rtslib_fb/utils.py", line 100, in fread
with open(path, 'r') as file_fd:
PermissionError: [Errno 13] Permission denied:
On 1/23/19 5:24 AM, Heiko Carstens wrote:
On Wed, Jan 23, 2019 at 01:55:13PM +0100, Laura Abbott wrote:
There's a build failure with gcc9:
./arch/s390/include/asm/jump_label.h: Assembler messages:
./arch/s390/include/asm/jump_label.h:23: Error: bad expression
./arch/s390/include/asm
On 1/28/19 5:28 AM, Bernd Edlinger wrote:
On 1/25/19 1:24 PM, Bernd Edlinger wrote:
On 1/25/19 12:39 PM, Miguel Ojeda wrote:
On Fri, Jan 25, 2019 at 11:58 AM Arnd Bergmann wrote:
On Fri, Jan 25, 2019 at 11:43 AM Laura Abbott wrote:
Commit bee20031772a ("disable -Wattribute-alias wa
; } \
- void cleanup_module(void) __attribute__((alias(#exitfn)));
+ void cleanup_module(void) __cold __attribute__((alias(#exitfn)));
#endif
Tested-by: Laura Abbott
)
__alias(__crc32c_le);
/*
* This multiplies the polynomials x and y modulo the given modulus.
Tested-by: Laura Abbott
he default (-Wattribute-alias=1).
Signed-off-by: Laura Abbott
---
This is RFC because it feels ugly. I went ahead and did the obvious fixup
but it's worth discussing if we're going to end up with an explosion or
if there's a better way to handle this in one macro.
---
include/linux/compat.h | 2 +
As an FYI for anyone who is interested, gcc9 landed in Fedora rawhide
and I built the kernel as usual.
There's a very large number of warnings from -Waddress-of-packed-member e.g.
BUILDSTDERR: drivers/scsi/ipr.c: In function 'ipr_handle_config_change':
BUILDSTDERR: drivers/scsi/ipr.c:1453:22:
/Makefile.build:277: init/main.o] Error 1
According to the toolchain people, the actual issue is the use of
"X" constraint which is too permissive. Switch to using "i" instead.
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1668703
Signed-off-by: Laura Abbott
---
arch/s390/incl
On 1/22/19 6:41 AM, Greg Kroah-Hartman wrote:
When calling debugfs functions, there is no need to ever check the
return value. The function can work or not, but the code logic should
never do something different based on this.
Cc: Russell King
Cc: Jinbum Park
Cc: Kees Cook
Cc: Laura Abbott
On 1/19/19 2:25 AM, Christoph Hellwig wrote:
On Fri, Jan 18, 2019 at 10:37:46AM -0800, Liam Mark wrote:
Add support for configuring dma mapping attributes when mapping
and unmapping memory through dma_buf_map_attachment and
dma_buf_unmap_attachment.
Signed-off-by: Liam Mark
And who is going
On 1/18/19 1:32 PM, Liam Mark wrote:
On Fri, 18 Jan 2019, Laura Abbott wrote:
On 1/18/19 10:37 AM, Liam Mark wrote:
Add support for configuring dma mapping attributes when mapping
and unmapping memory through dma_buf_map_attachment and
dma_buf_unmap_attachment.
Signed-off-by: Liam Mark
On 1/18/19 10:37 AM, Liam Mark wrote:
Add support for configuring dma mapping attributes when mapping
and unmapping memory through dma_buf_map_attachment and
dma_buf_unmap_attachment.
Signed-off-by: Liam Mark
---
include/linux/dma-buf.h | 3 +++
1 file changed, 3 insertions(+)
diff --git
On 1/18/19 12:43 PM, Andrew F. Davis wrote:
On 1/18/19 2:31 PM, Laura Abbott wrote:
On 1/17/19 8:13 AM, Andrew F. Davis wrote:
On 1/16/19 4:48 PM, Liam Mark wrote:
On Wed, 16 Jan 2019, Andrew F. Davis wrote:
On 1/15/19 1:05 PM, Laura Abbott wrote:
On 1/15/19 10:38 AM, Andrew F. Davis wrote
ment->priv;
struct ion_buffer *buffer = dmabuf->priv;
- free_duped_table(a->table);
mutex_lock(>lock);
list_del(>list);
mutex_unlock(>lock);
+ free_duped_table(a->table);
kfree(a);
}
Acked-by: Laura Abbott
On 1/17/19 8:13 AM, Andrew F. Davis wrote:
On 1/16/19 4:48 PM, Liam Mark wrote:
On Wed, 16 Jan 2019, Andrew F. Davis wrote:
On 1/15/19 1:05 PM, Laura Abbott wrote:
On 1/15/19 10:38 AM, Andrew F. Davis wrote:
On 1/15/19 11:45 AM, Liam Mark wrote:
On Tue, 15 Jan 2019, Andrew F. Davis wrote
On 1/16/19 8:05 AM, Andrew F. Davis wrote:
On 1/15/19 12:58 PM, Laura Abbott wrote:
On 1/15/19 9:47 AM, Andrew F. Davis wrote:
On 1/14/19 8:39 PM, Laura Abbott wrote:
On 1/11/19 10:05 AM, Andrew F. Davis wrote:
Hello all,
This is a set of (hopefully) non-controversial cleanups for the ION
On 1/18/19 1:59 AM, Greg Kroah-Hartman wrote:
On Fri, Jan 11, 2019 at 12:05:21PM -0600, Andrew F. Davis wrote:
When enabled the helpers functions for creating carveout and chunk heaps
should have declarations in the ION header.
Why? No one calls these from what I can tell.
Which makes me
On 1/16/19 9:12 AM, Andrew F. Davis wrote:
On 1/16/19 9:28 AM, Brian Starkey wrote:
Hi Andrew,
On Fri, Jan 11, 2019 at 12:05:20PM -0600, Andrew F. Davis wrote:
The heap name can be used for debugging but otherwise does not seem
to be required and no other part of the code will fail if left
On 1/10/19 1:09 PM, Khalid Aziz wrote:
I am continuing to build on the work Juerg, Tycho and Julian have done
on XPFO. After the last round of updates, we were seeing very
significant performance penalties when stale TLB entries were flushed
actively after an XPFO TLB update. Benchmark for
On 1/10/19 1:09 PM, Khalid Aziz wrote:
From: Julian Stecklina
We can reduce spin lock usage in xpfo_kmap to the 0->1 transition of
the mapcount. This means that xpfo_kmap() can now race and that we
get spurious page faults.
The page fault handler helps the system make forward progress by
On 1/7/19 11:18 AM, Dave Jones wrote:
[ 53.980701] NFSD: Using /var/lib/nfs/v4recovery as the NFSv4 state recovery
directory
[ 53.981216] NFSD: starting 45-second grace period (net f098)
[ 54.006802] CRED: Invalid credentials
[ 54.006880] CRED: At ./include/linux/cred.h:253
[
On 1/10/19 1:09 PM, Khalid Aziz wrote:
I am continuing to build on the work Juerg, Tycho and Julian have done
on XPFO. After the last round of updates, we were seeing very
significant performance penalties when stale TLB entries were flushed
actively after an XPFO TLB update. Benchmark for
On 1/15/19 10:43 AM, Laura Abbott wrote:
On 1/15/19 7:58 AM, Andrew F. Davis wrote:
On 1/14/19 8:32 PM, Laura Abbott wrote:
On 1/11/19 10:05 AM, Andrew F. Davis wrote:
The "unmapped" heap is very similar to the carveout heap except
the backing memory is presumed to be unmappable b
On 1/15/19 10:38 AM, Andrew F. Davis wrote:
On 1/15/19 11:45 AM, Liam Mark wrote:
On Tue, 15 Jan 2019, Andrew F. Davis wrote:
On 1/14/19 11:13 AM, Liam Mark wrote:
On Fri, 11 Jan 2019, Andrew F. Davis wrote:
Buffers may not be mapped from the CPU so skip cache maintenance here.
Accesses
On 1/15/19 9:47 AM, Andrew F. Davis wrote:
On 1/14/19 8:39 PM, Laura Abbott wrote:
On 1/11/19 10:05 AM, Andrew F. Davis wrote:
Hello all,
This is a set of (hopefully) non-controversial cleanups for the ION
framework and current set of heaps. These were found as I start to
familiarize myself
On 1/15/19 7:58 AM, Andrew F. Davis wrote:
On 1/14/19 8:32 PM, Laura Abbott wrote:
On 1/11/19 10:05 AM, Andrew F. Davis wrote:
The "unmapped" heap is very similar to the carveout heap except
the backing memory is presumed to be unmappable by the host, in
my specific case due to
On 1/11/19 10:05 AM, Andrew F. Davis wrote:
Hello all,
This is a set of (hopefully) non-controversial cleanups for the ION
framework and current set of heaps. These were found as I start to
familiarize myself with the framework to help in whatever way I
can in getting all this up to the
On 1/11/19 10:05 AM, Andrew F. Davis wrote:
The "unmapped" heap is very similar to the carveout heap except
the backing memory is presumed to be unmappable by the host, in
my specific case due to firewalls. This memory can still be
allocated from and used by devices that do have access to the
On 1/9/19 5:15 AM, Arnaldo Carvalho de Melo wrote:
Em Tue, Jan 08, 2019 at 02:17:58PM -0800, Laura Abbott escreveu:
Commit 4e21565b7fd4 ("asm-generic: add kexec_file_load system
call to unistd.h") added the system call to the generic header
but not to the perf copy resulting a compi
:44: error: '__NR_kexec_file_load' undeclared (first
use in this function)
BUILDSTDERR: :273:44: note: each undeclared identifier is reported only
once for each function it appears in
Fix this by syncing up.
Fixes: 4e21565b7fd4 ("asm-generic: add kexec_file_load system call to unistd.h")
Signed-
On 1/7/19 12:58 AM, Michael Ellerman wrote:
Laura Abbott writes:
Commit 7f92891778df ("vfio_pci: Add NVIDIA GV100GL [Tesla V100 SXM2]
subdriver") introduced a trace.h file in the local directory but
missed adding the local include path, resulting in compilation
failures with t
SXM2] subdriver")
Signed-off-by: Laura Abbott
---
I'd still like to echo my sentiment that this should not be a def_bool.
We hit this error on our internal testing and we couldn't even turn
off the driver until we fixed this.
---
drivers/vfio/pci/Makefile | 1 +
1 file changed, 1 insertion(+)
On 1/3/19 5:42 PM, Zengtao (B) wrote:
-Original Message-
From: Laura Abbott [mailto:labb...@redhat.com]
Sent: Thursday, January 03, 2019 6:31 AM
To: Zengtao (B) ; sumit.sem...@linaro.org
Cc: Greg Kroah-Hartman ; Arve Hjønnevåg
; Todd Kjos ; Martijn Coenen
; Joel Fernandes ;
de
On 1/3/19 5:49 AM, Alexey Kardashevskiy wrote:
On 03/01/2019 03:37, Laura Abbott wrote:
Hi,
I got a compilation failure when building with CONFIG_VFIO_PCI_NVLINK2
enabled:
+ make -s 'HOSTCFLAGS=-O2 -g -pipe -Wall -Werror=format-security
-Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS
On 12/24/18 12:19 AM, Qing Xia wrote:
Now, as Google's user guide, if userspace need clean ION buffer's
cache, they should call ioctl(fd, DMA_BUF_IOCTL_SYNC, sync). Then
we found that ion_dma_buf_begin_cpu_access/ion_dma_buf_end_cpu_access
will do ION buffer's map_kernel, it's not necessary. And
On 12/23/18 6:47 PM, Zengtao (B) wrote:
Hi laura:
-Original Message-
From: Laura Abbott [mailto:labb...@redhat.com]
Sent: Friday, December 21, 2018 4:50 AM
To: Zengtao (B) ; sumit.sem...@linaro.org
Cc: Greg Kroah-Hartman ; Arve Hjønnevåg
; Todd Kjos ; Martijn Coenen
; Joel Fernandes
On 12/19/18 5:39 PM, Zengtao (B) wrote:
Hi laura:
-Original Message-
From: Laura Abbott [mailto:labb...@redhat.com]
Sent: Thursday, December 20, 2018 2:10 AM
To: Zengtao (B) ; sumit.sem...@linaro.org
Cc: Greg Kroah-Hartman ; Arve Hjønnevåg
; Todd Kjos ; Martijn Coenen
; Joel Fernandes
On 12/19/18 9:19 AM, Zeng Tao wrote:
In some usecases, the buffer cached attribute is not determined at
allocation time, it's determined just before the real cpu mapping.
And from the memory view of point, a buffer should not have the cached
attribute util is really mapped by the cpu. So in this
hdr, which restores
parity with the old method.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=201741
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1659295
Reported-by: Laura Abbott
You should probably use the bugzilla reporters instead
of me given I just did the boring part of se
Hi,
There are two reports of a regression with unwinding with
379d98ddf413 ("x86: vdso: Use $LD instead of $CC to link")
https://bugzilla.kernel.org/show_bug.cgi?id=201741
https://bugzilla.redhat.com/show_bug.cgi?id=1659295
It looks like the unwinding information has been
stripped out. Any
(adding some more people, please remember to run get_maintainer.pl
to get the full list in the future)
On 12/14/18 10:15 AM, Thomas Schoebel-Theuer wrote:
Since commit commit d91525eb8ee6 ("ACPI, EINJ: Enhance error injection
tolerance level"), starting with kernel 4.0, the following happens
The latest file system corruption issue (Nominally fixed by
ffe81d45322c ("blk-mq: fix corruption with direct issue") later
fixed by c616cbee97ae ("blk-mq: punt failed direct issue to dispatch
list")) brought a lot of rightfully concerned users asking about
release schedules. 4.18 went EOL on Nov
The latest file system corruption issue (Nominally fixed by
ffe81d45322c ("blk-mq: fix corruption with direct issue") later
fixed by c616cbee97ae ("blk-mq: punt failed direct issue to dispatch
list")) brought a lot of rightfully concerned users asking about
release schedules. 4.18 went EOL on Nov
On 11/14/18 5:16 AM, David Herrmann wrote:
This reverts commit 336fd4f5f25157e9e8bd50e898a1bbcd99eaea46.
Please note that `strlcpy()` does *NOT* do what you think it does.
strlcpy() *ALWAYS* reads the full input string, regardless of the
'length' parameter. That is, if the input is not
On 11/14/18 5:16 AM, David Herrmann wrote:
This reverts commit 336fd4f5f25157e9e8bd50e898a1bbcd99eaea46.
Please note that `strlcpy()` does *NOT* do what you think it does.
strlcpy() *ALWAYS* reads the full input string, regardless of the
'length' parameter. That is, if the input is not
On 11/5/18 6:32 AM, Yangtao Li wrote:
Use DEFINE_SHOW_ATTRIBUTE macro to simplify the code.
Acked-by: Laura Abbott
Signed-off-by: Yangtao Li
---
arch/arm/mm/ptdump_debugfs.c | 12 +---
1 file changed, 1 insertion(+), 11 deletions(-)
diff --git a/arch/arm/mm/ptdump_debugfs.c b
On 11/5/18 6:32 AM, Yangtao Li wrote:
Use DEFINE_SHOW_ATTRIBUTE macro to simplify the code.
Acked-by: Laura Abbott
Signed-off-by: Yangtao Li
---
arch/arm/mm/ptdump_debugfs.c | 12 +---
1 file changed, 1 insertion(+), 11 deletions(-)
diff --git a/arch/arm/mm/ptdump_debugfs.c b
On 10/21/2018 02:20 PM, NeilBrown wrote:
I call on the community to consider what *does* need to be said, about
conduct, to people outside the community and who have recently joined.
What is the document that you would have liked to have read as you were
starting out? It is all too long ago
On 10/21/2018 02:20 PM, NeilBrown wrote:
I call on the community to consider what *does* need to be said, about
conduct, to people outside the community and who have recently joined.
What is the document that you would have liked to have read as you were
starting out? It is all too long ago
Reviewed-by: Laura Abbott
Cc: Arnd Bergmann
Cc: Ard Biesheuvel
Cc: Laura Abbott
Cc: Catalin Marinas
Co-developed-by: Arnd Bergmann
Co-developed-by: Ard Biesheuvel
Signed-off-by: Anders Roxell
---
arch/arm64/kernel/probes/kprobes.c | 27 ---
1 file changed,
1 - 100 of 2861 matches
Mail list logo
