On Wed, May 15, 2019 at 01:09:24AM +, Anson Huang wrote:
> Add macro for the SNVS clock of the i.MX8MQ.
>
> Signed-off-by: Anson Huang
Applied, thanks.
On Wed, 22 May 2019 14:02:31 -0700
Brendan Higgins wrote:
> Cool, so do we just want to go with that? Have a single slot for KUnit
> and KTF combined?
>
> We can each present our work up to this point; maybe offer some
> background and rationale on why we made the decision we have and then we
>
Clang needs "-meabi gnu" flag to emit calls to "__gnu_mcount_nc".
Otherwise, it inserts calls to undefined "mcount".
kernel/softirq.o: In function `_local_bh_enable':
...
undefined reference to `mcount'
"-meabi gnu" resolves link failures. However, Clang does not implement
calls to
On 5/22/19 4:36 PM, Jason Gunthorpe wrote:
On Mon, May 06, 2019 at 04:35:14PM -0700, rcampb...@nvidia.com wrote:
From: Ralph Campbell
The last reference to struct hmm may be released long after the mm_struct
is destroyed because the struct hmm_mirror memory may be part of a
device driver
The do_trap function is always called with tsk == current.
Make that obvious by removing the tsk parameter.
This also makes it clear that do_trap calls force_sig_fault
on the current task.
Signed-off-by: "Eric W. Biederman"
---
arch/riscv/include/asm/bug.h | 2 +-
arch/riscv/kernel/traps.c
The __do_user_fault function is always called with tsk == current.
Make that obvious by removing the tsk parameter.
This makes it clear that __do_user_fault calls force_sig_fault
on the current task.
Signed-off-by: "Eric W. Biederman"
---
arch/unicore32/mm/fault.c | 11 ++-
1 file
The __do_user_fault function is always called with tsk == current.
Make that obvious by removing the tsk parameter.
This makes it clear that __do_user_fault calls force_sig_fault
on the current task.
Signed-off-by: "Eric W. Biederman"
---
arch/arm/mm/fault.c | 11 ++-
1 file changed, 6
The send_sigtrap function is always called with tsk == current.
Make that obvious by removing the tsk parameter.
This also makes it clear that send_sigtrap always calls
force_sig_fault on the current task.
Signed-off-by: "Eric W. Biederman"
---
arch/nds32/kernel/traps.c | 7 ---
1 file
The force_sig_info_fault function is always called with tsk == current.
Make that explicit by removing the tsk parameter.
This also makes it clear that the sh force_sig_info_fault passes
current into force_sig_fault.
Signed-off-by: "Eric W. Biederman"
---
arch/sh/mm/fault.c | 11 ---
1
Forcing a signal or not allowing a pid namespace init to ignore
SIGKILL or SIGSTOP is more cleanly computed in send_signal.
There are two cases where we don't allow a pid namespace init
to ignore SIGKILL or SIGSTOP. If the sending process is
from an ancestor pid namespace and as such is
Any time siginfo is not stored in the signal queue information is
lost. Therefore set TRACE_SIGNAL_LOSE_INFO every time the code does
not allocate a signal queue entry, and a queue overflow abort is not
triggered.
Fixes: ba005e1f4172 ("tracepoint: Add signal loss events")
Signed-off-by: "Eric W.
Update the calls of force_sig_fault that pass in a variable that is
set to current earlier to explicitly use current.
This is to make the next change that removes the task parameter
from force_sig_fault easier to verify.
Signed-off-by: "Eric W. Biederman"
---
arch/arc/kernel/traps.c | 2 +-
All callers of force_sig_info pass info.si_signo in for the signal
by definition as well as in practice.
Further all callers of force_sig_info except force_sig_fault_to_task
pass current as the target task to force_sig_info.
Factor out a static force_sig_info_to_task that
force_sig_fault_to_task
In preparation for removing the task parameter from force_sig_fault
introduce force_sig_fault_to_task and use it for the two cases where
it matters.
On mips force_fcr31_sig calls force_sig_fault and is called on either
the current task, or a task that is suspended and is being switched to
by the
As synchronous exceptions really only make sense against the current
task (otherwise how are you synchronous) remove the task parameter
from from force_sig_fault to make it explicit that is what is going
on.
The two known exceptions that deliver a synchronous exception to a
stopped ptraced task
The send_sigtrap function is always called with task == current. Make
that explicit by removing the task parameter.
This also makes it clear that the uml send_sigtrap passes current
into force_sig_fault.
Signed-off-by: "Eric W. Biederman"
---
arch/um/kernel/ptrace.c | 8
1 file
In preparation for removing the special case in force_sig_info for
only having a signal number generate an appropriate siginfo in
force_sig the last caller of force_sig_info that does not
pass a filled out siginfo.
Signed-off-by: "Eric W. Biederman"
---
kernel/signal.c | 10 +-
1 file
All of the callers pass current into force_sig_mceer so remove the
task parameter to make this obvious.
This also makes it clear that force_sig_mceerr passes current
into force_sig_info.
Signed-off-by: "Eric W. Biederman"
---
arch/arm64/kernel/traps.c| 2 +-
arch/parisc/mm/fault.c |
The send_sigtrap function is always called with task == current. Make
that explicit by removing the task parameter.
This also makes it clear that the x86 send_sigtrap passes current
into force_sig_fault.
Signed-off-by: "Eric W. Biederman"
---
arch/x86/include/asm/ptrace.h | 3 +--
force_sig_info always delivers to the current task and the signal
parameter always matches info.si_signo. So remove those parameters to
make it a simpler less error prone interface, and to make it clear
that none of the callers are doing anything clever.
This guarantees that force_sig_info will
The ptrace_break function is always called with tsk == current.
Make that obvious by removing the tsk parameter.
This also makes it clear that ptrace_break calls force_sig_fault
on the current task.
Signed-off-by: "Eric W. Biederman"
---
arch/arm/include/asm/traps.h | 2 +-
All of the remaining callers pass current into force_sig so
remove the task parameter to make this obvious and to make
misuse more difficult in the future.
This also makes it clear force_sig passes current into force_sig_info.
Signed-off-by: "Eric W. Biederman"
---
arch/alpha/kernel/signal.c
The function force_sigsegv is always called on the current task
so passing in current is redundant and not passing in current
makes this fact obvious.
This also makes it clear force_sigsegv always calls force_sig
on the current task.
Signed-off-by: "Eric W. Biederman"
---
It really only matters to debuggers but the SIGKILL does not have any
si_codes that use the fault member of the siginfo union. Correct this
the simple way and call force_sig instead of force_sig_fault when the
signal is SIGKILL.
Cc: sta...@vger.kernel.org
Cc: Dave Martin
Cc: James Morse
Cc:
The drbd module exclusively sends signals to kernel threads it creates with
kthread_create. These kernel threads do not block or ignore signals (only
flush signals after they have been delivered), nor can drbd threads
possibly be pid namespace init processes so the extra work that force_sig
Folks,
If folks can look this over and see if I have missed something I would
appreciate it.
The force_sig_info interface is designed to handle synchronous exceptions
like page faults. The locking in force_sig_info does not handle being
called on a remote task that is already running. It has
The function send_signal was split from __send_signal so that it would
be possible to bypass the namespace logic based upon current[1]. As it
turns out the si_pid and the si_uid fixup are both inappropriate in
the case of kill_pid_usb_asyncio so move that logic into send_signal.
It is difficult
The locking in force_sig_info is not prepared to deal with a task that
exits or execs (as sighand may change). The is not a locking problem
in force_sig as force_sig is only built to handle synchronous
exceptions.
Further the function force_sig_info changes the signal state if the
signal is
The locking in force_sig_info is not prepared to deal with a task that
exits or execs (as sighand may change). The is not a locking problem
in force_sig as force_sig is only built to handle synchronous
exceptions.
Further the function force_sig_info changes the signal state if the
signal is
The locking in force_sig_info is not prepared to deal with
a task that exits or execs (as sighand may change). As force_sig
is only built to handle synchronous exceptions.
Further the function force_sig_info changes the signal state if the
signal is ignored, or blocked or if SIGNAL_UNKILLABLE
Since PTRACE_KILL was introduced in 1.1.78 it has only worked if the
process is stopped in do_signal. On a ptraced but non-stopped process
PTRACE_KILL has always returned success and done nothing.
Separate the noop case of PTRACE_KILL from the case where it does
nothing. This fixes the fact
In function con_insert_unipair(), when allocation for p2 and p1[n]
fails, ENOMEM is returned, but previously allocated p1 is not freed,
remains as leaking memory. Thus we should free p1 as well when this
allocation fails.
Signed-off-by: Gen Zhang
---
diff --git a/drivers/tty/vt/consolemap.c
Acked-by: Shannon Nelson
Thanks!
sln
On Wed, May 22, 2019 at 4:25 PM dann frazier wrote:
>
> An ipsec structure will not be allocated if the hardware does not support
> offload. Fixes the following Oops:
>
> [ 191.045452] Unable to handle kernel NULL pointer dereference at virtual
> address
On Wed, May 22, 2019 at 01:54:47PM -0700, Kees Cook wrote:
> On Wed, May 22, 2019 at 09:50:55AM +0800, Gen Zhang wrote:
> > On Tue, May 21, 2019 at 01:44:33PM -0700, Kees Cook wrote:
> > > This doesn't look safe to me: p->uni_pgdir[n] will still have a handle
> > > to the freed memory, won't it?
>
From: Jisheng Zhang
Date: Wed, 22 May 2019 10:06:56 +
> Move the reset gpio dt parse and request to stmmac_mdio_register(),
> thus makes the mdio code straightforward.
>
> This patch also replace stack var mdio_bus_data with data to simplify
> the code.
>
> Signed-off-by: Jisheng Zhang
From: Jisheng Zhang
Date: Wed, 22 May 2019 10:05:09 +
> Commit 984203ceff27 ("net: stmmac: mdio: remove reset gpio free")
> removed the reset gpio free, when the driver is unbinded or rmmod,
> we miss the gpio free.
>
> This patch uses managed API to request the reset gpio, so that the
>
> RDU2 production units come with resistor connecting WP pin to
> correpsonding GPIO DNPed for both SD card slots. Drop any WP related
> configuration and mark both slots with "disable-wp".
>
> Reported-by: Chris Healy
> Signed-off-by: Andrey Smirnov
> Cc: Shawn Guo
> Cc: Fabio Estevam
> Cc:
From:
Date: Wed, 22 May 2019 08:24:43 +
> From: Claudiu Beznea
>
> SAMA5D2 SoC has a suspend mode where SoC's power is cut off. Due to this
> the registers content is lost after a suspend/resume cycle. The current
> suspend/resume implementation covers some of these registers. However
>
The SNVS LPGR IP block is also found on other i.MX SoCs that
are not covered by the current SOC_IMX6 || SOC_IMX7D logic.
One example is the i.MX7ULP.
To avoid keep expanding the SoC logic selection, make it broader
by using the more generic ARCH_MXC symbol instead.
Signed-off-by: Fabio Estevam
> -Original Message-
> From: Dmitry Vyukov
> On Fri, Apr 26, 2019 at 11:03 PM Tim Bird wrote:
> >
> > I'm in the process now of planning Automated Testing Summit 2019,
> > which is tentatively planned for Lyon, France on October 31. This is
>
> This is _November_ 1, right?
No.
The uwrite() and ulseek() functions are formatted inconsistently
with the rest of the file and the kernel overall. While we're
making other changes here let's fix this.
Signed-off-by: Matt Helsley
---
scripts/recordmcount.c | 21 +++--
scripts/recordmcount.h | 13 ++---
The strcmp is unnecessary since .text is already accepted as a
prefix in the strncmp().
Signed-off-by: Matt Helsley
---
scripts/recordmcount.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/scripts/recordmcount.c b/scripts/recordmcount.c
index a50a2aa963ad..7f835059e7c2
uread() is only used to initialize the ELF file's pseudo
private-memory mapping while uwrite() and ulseek() work within
the pseudo-mapping and extend it as necessary. Thus it is not
a complementary function to uwrite() and ulseek(). It also makes
no sense to do cleanups inside uread() when its
Move recordmcount into the objtool directory. We keep this step separate
so changes which turn recordmcount into a subcommand of objtool don't
get obscured.
Signed-off-by: Matt Helsley
---
scripts/.gitignore | 1 -
scripts/Makefile | 1 -
cleanup() mostly frees/unmaps the malloc'd/privately-mapped
copy of the ELF file recordmcount is working on, which is
set up in mmap_file(). It also deals with positioning within
the pseduo prive-mapping of the file and appending to the ELF
file.
Split into two steps:
mmap_cleanup() for
Recordmcount uses setjmp/longjmp to manage control flow as
it reads and then writes the ELF file. This unusual control
flow is hard to follow and check in addition to being unlike
kernel coding style.
So we rewrite these paths to use regular return values to
indicate error/success. When an error
Fix up the whitespace irregularity in the ELF switch
blocks.
Swapping the initial value of gpfx allows us to
simplify all but one of the one-line switch cases even
further.
Signed-off-by: Matt Helsley
---
scripts/recordmcount.c | 47 ++
1 file changed,
Redundant cleanup calls were introduced when transitioning from
the old error/success handling via setjmp/longjmp -- the longjmp
ensured the cleanup() call only happened once but replacing
the success_file()/fail_file() calls with cleanup() meant that
multiple cleanup() calls can happen as we
Use struct elf to grab the file descriptor. We will later
move these calls into other functions as we expand the
lifetime of the struct elf so that it can be passed to
objtool elf.[ch] functions.
This creates the libelf/objcount data structures and gives
us two separte ways to walk the ELF file
This series cleans up recordmcount and then makes it into
an objtool subcommand.
The series starts with 8 cleanup patches which make recordmcount
easier to review and integrate with objtool. The final 5 patches
show the beginning steps of converting recordmcount to use objtool's
ELF code rather
Rather than a standalone executable merge recordmcount as a sub
command of objtool. This is a small step towards cleaning up
recordmcount and eventually saving ELF code with objtool.
For the initial step all that's required is a bit of Makefile
changes and invoking the former main() function from
Use objtool's ELF data structures to visit the relocation
sections in the top-level ELF file walking function, do_func().
This means we can pass pointers to the relocation header structures
into nested functions and avoid the indexing patterns for them.
These conversions don't use libelf/objtool
recordmcount iterates over the sections in the order they're
listed in the ELF file and checks whether the section name
indicates it's of interest. Objtool's elf code works differently
-- it scans the elf file and builds up data structures
representing the headers, sections, etc. and then
uwrite() works within the pseudo-mapping and extends it as necessary
without needing the file descriptor (fd) parameter passed to it.
Similarly, ulseek() doesn't need its fd parameter. These parameters
were only added because the functions bear a conceptual resemblance
to write() and lseek().
On Wed, May 22, 2019 at 01:48:52PM -0400, Jerome Glisse wrote:
> > > So attached is a rebase on top of 5.2-rc1, i have tested with pingpong
> > > (prefetch and not and different sizes). Seems to work ok.
> >
> > Urk, it already doesn't apply to the rdma tree :(
> >
> > The conflicts are a
Andrew Morton wrote:
> On Thu, 23 May 2019 07:39:25 +1000 Stephen Rothwell
> wrote:
>
> > > I put an example patch into my subversion repository:
> > >
> > > svn checkout
> > > https://svn.osdn.net/svnroot/tomoyo/branches/syzbot-patches/
> > >
> > > To fetch up-to-date debug printk()
On Wed, May 22, 2019 at 12:45:17PM -0500, Josh Poimboeuf wrote:
> On Wed, May 22, 2019 at 02:49:07PM +, Alexei Starovoitov wrote:
> > The one that is broken is prog_tests/stacktrace_map.c
> > There we attach bpf to standard tracepoint where
> > kernel suppose to collect pt_regs before calling
On Mon, May 06, 2019 at 04:35:14PM -0700, rcampb...@nvidia.com wrote:
> From: Ralph Campbell
>
> The last reference to struct hmm may be released long after the mm_struct
> is destroyed because the struct hmm_mirror memory may be part of a
> device driver open file private data pointer. The file
On Wed, May 22, 2019 at 10:17:45PM +, Frank van der Linden wrote:
> For F17h AMD CPUs, the CPB capability is forcibly set, because some
> versions of that chip incorrectly report that they do not have it.
>
> However, a hypervisor may filter out the CPB capability, for good
> reasons. For
> From: linux-hyperv-ow...@vger.kernel.org
> On Behalf Of Sunil Muthuswamy
>
> Currently, the hv_sock send() iterates once over the buffer, puts data into
> the VMBUS channel and returns. It doesn't maximize on the case when there
> is a simultaneous reader draining data from the channel. In
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: 54dee406374ce8adb352c48e175176247cb8db7c
commit: 164a263bf8d003e4cbb197d52b74d26df72604d7 ASoC: Intel: Make boards more
available for compile test
date: 3 weeks ago
config: ia64-allyesconfig (attached as
On 5/17/19 3:16 PM, Jens Axboe wrote:
> On 5/17/19 2:29 PM, Ed Cashin wrote:
>> Justin Sanders, who has extensive experience with ATA over Ethernet
>> in general and AoE SCSI and block-device drivers in particular, is
>> ready to take on the role of aoe maintainer. The driver needs a more
>>
On 5/22/19 3:50 PM, Stephen Rothwell wrote:
> Hi all,
>
> Commit
>
> 04bc2bcccbd5 ("aoe: list new maintainer for aoe driver")
>
> is missing a Signed-off-by from its author.
Will get this fixed up, waiting for Ed to respond.
--
Jens Axboe
pEpkey.asc
Description: application/pgp-keys
Currently the lifetime of bpf programs attached to a cgroup is bound
to the lifetime of the cgroup itself. It means that if a user
forgets (or intentionally avoids) to detach a bpf program before
removing the cgroup, it will stay attached up to the release of the
cgroup. Since the cgroup can stay
Add a kselftest to cover bpf auto-detachment functionality.
The test creates a cgroup, associates some resources with it,
attaches a couple of bpf programs and deletes the cgroup.
Then it checks that bpf programs are going away in 5 seconds.
Expected output:
$ ./test_cgroup_attach
On Wed, May 22, 2019 at 03:24:38PM -0700, Stanislav Fomichev wrote:
> On 05/22, Roman Gushchin wrote:
> > Add a kselftest to cover bpf auto-detachment functionality.
> > The test creates a cgroup, associates some resources with it,
> > attaches a couple of bpf programs and deletes the cgroup.
> >
This patchset implements a cgroup bpf auto-detachment functionality:
bpf programs are attached as soon as possible after removal of the
cgroup, without waiting for the release of all associated resources.
Patches 2 and 3 are required to implement a corresponding kselftest
in patch 4.
v2:
1)
An ipsec structure will not be allocated if the hardware does not support
offload. Fixes the following Oops:
[ 191.045452] Unable to handle kernel NULL pointer dereference at virtual
address
[ 191.054232] Mem abort info:
[ 191.057014] ESR = 0x9604
[ 191.060057]
Convert test_cgrp2_attach2 example into a proper test_cgroup_attach
kselftest. It's better because we do run kselftest on a constant
basis, so there are better chances to spot a potential regression.
Also make it slightly less verbose to conform kselftests output style.
Output example:
$
Enable all available cgroup v2 controllers when setting up
the environment for the bpf kselftests. It's required to properly test
the bpf prog auto-detach feature. Also it will generally increase
the code coverage.
Signed-off-by: Roman Gushchin
---
tools/testing/selftests/bpf/cgroup_helpers.c |
concat_lock() and concat_unlock() only differed in terms of the mtd_xx
operation they called. Refactor them to use a common helper function and
pass a boolean flag to indicate whether lock or unlock is needed.
Signed-off-by: Chris Packham
---
Changes in v2:
- Use a boolean flag instead of
Add an implementation of the _is_locked operation for concatenated mtd
devices. This doesn't handle getting the lock status of a range that
spans chips, which is consistent with cfi_ppb_is_locked and
cfi_intelext_is_locked which only look at the first block in the range.
Signed-off-by: Chris
On Wed, May 22, 2019 at 03:18:43PM -0700, Stanislav Fomichev wrote:
> On 05/22, Roman Gushchin wrote:
> > Enable all available cgroup v2 controllers when setting up
> > the environment for the bpf kselftests. It's required to properly test
> > the bpf prog auto-detach feature. Also it will
On Wed, 22 May 2019 22:56:07 +
Sunil Muthuswamy wrote:
> Currently, the hv_sock buffer size is static and can't scale to the
> bandwidth requirements of the application. This change allows the
> applications to influence the socket buffer sizes using the SO_SNDBUF and
> the SO_RCVBUF socket
On Tue, May 21, 2019 at 12:50:57PM +, Raphael Gault wrote:
> Hi Josh,
>
> Thanks for offering your help and sorry for the late answer.
>
> My understanding is that a table of offsets is built by GCC, those
> offsets being scaled by 4 before adding them to the base label.
> I believe the
Currently, the hv_sock send() iterates once over the buffer, puts data into
the VMBUS channel and returns. It doesn't maximize on the case when there
is a simultaneous reader draining data from the channel. In such a case,
the send() can maximize the bandwidth (and consequently minimize the cpu
> From: Sunil Muthuswamy
> Sent: Wednesday, May 22, 2019 3:56 PM
> ...
> Currently, the hv_sock buffer size is static and can't scale to the
> bandwidth requirements of the application. This change allows the
> applications to influence the socket buffer sizes using the SO_SNDBUF and
> the
On Wed, May 22, 2019 at 2:49 PM syzbot
wrote:
>
> syzbot has bisected this bug to:
>
> commit 48a3c64b4649 ("Merge tag 'drm-fixes-2018-06-29' of
> git://anongit.freedesktop.org/drm/drm")
That looks very unlikely indeed. I strongly suspect your bisection is broken.
Looking at the bisection
Currently, the hv_sock buffer size is static and can't scale to the
bandwidth requirements of the application. This change allows the
applications to influence the socket buffer sizes using the SO_SNDBUF and
the SO_RCVBUF socket options.
Few interesting points to note:
1. Since the VMBUS does not
On Wed, May 22, 2019 at 3:18 PM Chris Down wrote:
>
> +Cc: linux-mm, since this broke mmots tree and has been applied there
>
> This patch is missing a definition for signal_detected in io_cqring_wait,
> which
> breaks the build.
This patch does not break the build.
The patch the breaks the
On Wed, May 22, 2019 at 06:42:11PM -0400, Jerome Glisse wrote:
> > > The way race is avoided is because mm->hmm will either be NULL or
> > > point to another hmm struct before an existing hmm is free.
> >
> > There is no locking on mm->hmm so it is useless to prevent races.
>
> There is
On Wed, May 22, 2019 at 05:54:58PM -0400, Liang, Kan wrote:
SNIP
> > [ 9680.197779] RSP: 002b:7fff595603a8 EFLAGS: 0206 ORIG_RAX:
> > ff13
> > [ 9680.205489] RAX: 4985 RBX: 000c RCX:
> > 000365ca
> > [ 9680.212748] RDX: 1e15d36cec84 RSI:
Make afs_permission() and afs_d_revalidate() do initial checks in RCU-mode
pathwalk to reduce latency in pathwalk elements that get done multiple
times. We don't need to query the server unless we've received a
notification from it that something has changed or the callback has
expired.
This
Provide an RCU-capable key lookup function. We don't want to call
afs_request_key() in RCU-mode pathwalk as request_key() might sleep, even if
we don't ask it to construct anything as it might find a key that is currently
undergoing construction.
Signed-off-by: David Howells
---
If a filesystem uses keys to hold authentication tokens, then it needs a
token for each VFS operation that might perform an authentication check -
either by passing it to the server, or using to perform a check based on
authentication data cached locally.
For open files this isn't a problem,
Move the RCU locks outwards from the keyring search functions so that a
request_key_rcu() function can be provided that searches for keys without
sleeping and without attempting to construct new keys. This new function
must be invoked with the RCU read lock held.
Signed-off-by: David Howells
Invalidate used request_key authentication keys rather than revoking them
so that they get cleaned up immediately rather than potentially hanging
around. There doesn't seem any need to keep the revoked keys around.
Signed-off-by: David Howells
---
security/keys/key.c |4 ++--
The request_key() syscall allows a process to gain access to the 'possessor'
permits of any key that grants it Search permission by virtue of request_key()
not checking whether a key it finds grants Link permission to the caller.
Signed-off-by: David Howells
---
security/keys/request_key.c |
Here's a fix and some improvements for request_key() intended for the next
merge window:
(1) Fix the lack of a Link permission check on a key found by request_key(),
thereby enabling request_key() to link keys that don't grant this
permission to the target keyring (which must still
On Wed, May 22, 2019 at 05:49:18PM -0400, Jerome Glisse wrote:
> > > > So why is mm suddenly guarenteed valid? It was a bug report that
> > > > triggered the race the mmget_not_zero is fixing, so I need a better
> > > > explanation why it is now safe. From what I see the hmm_range_fault
> > > > is
On Wed, May 22, 2019 at 8:38 AM Sean Christopherson
wrote:
>
> On Wed, May 22, 2019 at 09:56:30AM -0400, Stephen Smalley wrote:
> > On 5/22/19 9:22 AM, Jarkko Sakkinen wrote:
> > >On Wed, May 22, 2019 at 04:20:22PM +0300, Jarkko Sakkinen wrote:
> > >>On Tue, May 21, 2019 at 08:51:40AM -0700, Sean
On Wed, May 22, 2019 at 07:39:06PM -0300, Jason Gunthorpe wrote:
> On Wed, May 22, 2019 at 06:04:20PM -0400, Jerome Glisse wrote:
> > On Wed, May 22, 2019 at 05:12:47PM -0300, Jason Gunthorpe wrote:
> > > On Wed, May 22, 2019 at 01:48:52PM -0400, Jerome Glisse wrote:
> > >
> > > > static void
On Wed, 2019-05-22 at 12:26 -0700, Rick Edgecombe wrote:
> On Wed, 2019-05-22 at 10:40 -0700, David Miller wrote:
> > From: "Edgecombe, Rick P"
> > Date: Tue, 21 May 2019 01:59:54 +
> >
> > > On Mon, 2019-05-20 at 18:43 -0700, David Miller wrote:
> > > > From: "Edgecombe, Rick P"
> > > >
On Wed, May 22, 2019 at 06:04:20PM -0400, Jerome Glisse wrote:
> On Wed, May 22, 2019 at 05:12:47PM -0300, Jason Gunthorpe wrote:
> > On Wed, May 22, 2019 at 01:48:52PM -0400, Jerome Glisse wrote:
> >
> > > static void put_per_mm(struct ib_umem_odp *umem_odp)
> > > {
> > > struct
On Wed, May 22, 2019 at 12:08:31PM -0400, Vince Weaver wrote:
>
> The perf fuzzer caused my skylake machine to crash hard with the trace at
> the end here. (this is with current git)
>
> It appears to be happening in new code introduced by:
>
> commit 878068ea270ea82767ff1d26c91583263c81fba0
Hi all,
Today's linux-next merge of the slave-dma-fixes tree got a conflict in:
drivers/dma/mediatek/Makefile
between commit:
ec8f24b7faaf ("treewide: Add SPDX license identifier - Makefile/Kconfig")
from Linus' tree and commit:
e8b3ba1e38a2 ("dmaengine: mediatek: Add MediaTek UART
On 5/22/19 5:20 PM, Kees Cook wrote:
> On Wed, May 22, 2019 at 11:57:38PM +0200, Boris Brezillon wrote:
>> All this look suspicious, and even if the fall through logic
>> has no side effects in practice (which I'm still not sure is the case),
>> I think it'd be better to explicitly set the
Grant Link permission to the possessers of request_key authentication keys,
thereby allowing a daemon that is servicing upcalls to arrange things such
that only the necessary auth key is passed to the actual service program
and not all the daemon's pending auth keys.
Signed-off-by: David Howells
Here are some miscellaneous keyrings fixes and improvements intended for
the next merge window:
(1) Fix a bunch of warnings from sparse, including missing RCU bits and
kdoc-function argument mismatches
(2) Implement a keyctl to allow a key to be moved from one keyring to
another,
101 - 200 of 1323 matches
Mail list logo
