On Tue, 3 Apr 2018, Jerome Glisse wrote:
> > When dealing with the speculative fault path we should use the VMA's field
> > cached value stored in the vm_fault structure.
> >
> > Currently vm_normal_page() is using the pointer to the VMA to fetch the
> > vm_flags value. This patch provides a new
On Monday 02 April 2018 22:39:59 Ondrej Zary wrote:
> On Sunday 01 April 2018 23:21:55 Ondrej Zary wrote:
> > Hello,
> > I got a Sony Vaio VGN-CS31S laptop with Synaptics touchpad that exhibits
> > weird behavior. It seems to work until I touch the "Touch Sensor Buttons"
> > bar above the keyboard
On Fri, 2018-03-23 at 10:54 +0100, Greg Kroah-Hartman wrote:
> 4.4-stable review patch. If anyone has any objections, please let me know.
>
> --
>
> From: Keerthy
>
>
> [ Upstream commit 85fdaf8eb9bbec1f0f8a52fd5d85659d60738816 ]
>
> POWERHOLD signal has higher priority
> On Apr 3, 2018, at 12:07 PM, Matthew Wilcox wrote:
>
> On Tue, Apr 03, 2018 at 03:31:15PM +0200, Michal Hocko wrote:
>> On Mon 02-04-18 09:24:22, Buddy Lumpkin wrote:
>>> The presence of direct reclaims 10 years ago was a fairly reliable
>>> indicator that too much was being asked of a Linux
On Tue, Apr 3, 2018 at 9:29 AM, Matthew Garrett wrote:
> On Tue, Apr 3, 2018 at 8:11 AM Andy Lutomirski wrote:
>> Can you explain that much more clearly? I'm asking why booting via
>> UEFI Secure Boot should enable lockdown, and I don't see what this has
>> to do with kexec. And "someone
On Tue, Apr 3, 2018 at 1:53 PM Linus Torvalds
wrote:
> On Tue, Apr 3, 2018 at 9:29 AM, Matthew Garrett wrote:
> > On Tue, Apr 3, 2018 at 8:11 AM Andy Lutomirski wrote:
> >> Can you explain that much more clearly? I'm asking why booting via
> >> UEFI Secure Boot should enable lockdown, and I
On Tue, Apr 03, 2018 at 10:22:53AM -0700, rao.sho...@oracle.com wrote:
> +++ b/mm/slab.h
> @@ -80,6 +80,29 @@ extern const struct kmalloc_info_struct {
> unsigned long size;
> } kmalloc_info[];
>
> +#define RCU_MAX_ACCUMULATE_SIZE 25
> +
> +struct rcu_bulk_free_container {
> +
Hi Matt,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on tip/perf/core]
[also build test ERROR on v4.16 next-20180403]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux
From: Michael Kelley
Add standard interrupt handler annotations to
hyperv_vector_handler().
Signed-off-by: Michael Kelley
---
Changes in v2:
* Fixed From: line
---
arch/x86/kernel/cpu/mshyperv.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/kernel/cpu/mshyperv.c
On Fri, 2018-03-23 at 10:54 +0100, Greg Kroah-Hartman wrote:
> 4.4-stable review patch. If anyone has any objections, please let me know.
>
> --
>
> From: Ming Lei
>
>
> [ Upstream commit a4e84aae8139aca9fbfbced1f45c51ca81b57488 ]
>
> mtip32xx supposes that 'request_idx'
tcon->ses is being dereferenced before it is null checked, hence
there is a potential null pointer dereference.
Fix this by moving the pointer dereference after tcon->ses has
been properly null checked.
Addresses-Coverity-ID: 1467426 ("Dereference before null check")
Fixes: 93012bf98416 ("cifs:
On Tue, Apr 3, 2018 at 1:54 PM, Matthew Garrett wrote:
>
>> .. maybe you don't *want* secure boot, but it's been pushed in your
>> face by people with an agenda?
>
> Then turn it off, or build a self-signed kernel that doesn't do this?
Umm. So you asked a question, and then when you got an
Hi,
I noticed the subject was incorrect. Drop this patch, please.
I just sent v2.
Thanks
--
Gustavo
On 04/03/2018 03:55 PM, Gustavo A. R. Silva wrote:
tcon->ses is being dereferenced before it is null checked, hence
there is a potential null pointer dereference.
Fix this by moving the
On Tue, Apr 03, 2018 at 01:40:18PM -0700, David Rientjes wrote:
> On Tue, 3 Apr 2018, Jerome Glisse wrote:
>
> > > diff --git a/mm/memory.c b/mm/memory.c
> > > index 21b1212a0892..4bc7b0bdcb40 100644
> > > --- a/mm/memory.c
> > > +++ b/mm/memory.c
> > > @@ -2309,21 +2309,29 @@ static bool
Hi Rui,
I love your patch! Yet something to improve:
[auto build test ERROR on v4.16]
[cannot apply to linuxtv-media/master next-20180403]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Rui
On Tue, 3 Apr 2018 13:07:58 -0700
Kees Cook wrote:
> On Tue, Apr 3, 2018 at 12:41 PM, Steven Rostedt wrote:
> > Both trace_debug is set and kptr_restrict is set to zero in the same
> > code that produces the above banner. This will allow trace_printk() to
> > not be affected by security code,
On Tue, Apr 3, 2018 at 2:01 PM Linus Torvalds
wrote:
> On Tue, Apr 3, 2018 at 1:54 PM, Matthew Garrett wrote:
> >
> >> .. maybe you don't *want* secure boot, but it's been pushed in your
> >> face by people with an agenda?
> >
> > Then turn it off, or build a self-signed kernel that doesn't do
new_range is being dereferenced before it is null checked, hence
there is a potential null pointer dereference.
Fix this by moving the pointer dereference after new_range has
been properly null checked.
Addresses-Coverity-ID: 1466163 ("Dereference before null check")
Fixes: 0a7198426259 ("lib:
From: Alison Schofield
Intel's Skylake Server CPUs have a different LLC topology than previous
generations. When in Sub-NUMA-Clustering (SNC) mode, the package is
divided into two "slices", each containing half the cores, half the LLC,
and one memory controller and each slice is enumerated to
On Tue, Apr 03, 2018 at 01:49:25PM -0700, Buddy Lumpkin wrote:
> > Yes, very much this. If you have a single-threaded workload which is
> > using the entirety of memory and would like to use even more, then it
> > makes sense to use as many CPUs as necessary getting memory out of its
> > way. If
new_range is being dereferenced before it is null checked, hence
there is a potential null pointer dereference.
Fix this by moving the pointer dereference after new_range has
been properly null checked.
Addresses-Coverity-ID: 1466163 ("Dereference before null check")
Fixes: 0a7198426259 ("lib:
available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/pcmoore/audit.git tags/audit-pr-
20180403
for you to fetch changes up to ea841bafda3f7f9aa8b06a09f0f3e41c207af84f:
audit: add refused symlink to audit_names (2018-03-21 11:3
Split section "Comparison with old cropping API" in paragraphs for
easier reading and improve visible links text.
Cc: Hans Verkuil
Signed-off-by: Luca Ceresoli
---
.../media/uapi/v4l/selection-api-vs-crop-api.rst | 55 --
1 file changed, 29 insertions(+), 26 deletions(-)
Having two somewhat similar and largely overlapping APIs is confusing,
especially since the older one appears in the docs before the newer
and most featureful counterpart.
Clarify all of this in several ways:
- swap the two sections
- give a name to the two APIs in the section names
- add a
Cc: Hans Verkuil
Signed-off-by: Luca Ceresoli
---
Documentation/media/uapi/v4l/selection-api-004.rst | 2 +-
Documentation/media/uapi/v4l/selection.svg | 4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/Documentation/media/uapi/v4l/selection-api-004.rst
The API limitation described here is about the CROP API, not about the
entire V4L2.
Cc: Hans Verkuil
Signed-off-by: Luca Ceresoli
---
Documentation/media/uapi/v4l/selection-api-vs-crop-api.rst | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
These files have an automatically-generated numbering. Replaname them
to something that suggests their meaning.
Reported-by: Hans Verkuil
Cc: Hans Verkuil
Signed-off-by: Luca Ceresoli
---
.../{selection-api-004.rst => selection-api-configuration.rst} | 0
.../v4l/{selection-api-006.rst =>
On Tue, 2018-04-03 at 21:16 +0200, Heinrich Schuchardt wrote:
> Allow a space between a colon and subsequent opening bracket.
> This sequence may occur in inline assembler statements like
>
> asm(
> "ldr %[out], [%[in]]\n\t"
> : [out] "=r" (ret)
> :
On Tue, Apr 03, 2018 at 09:08:54PM +, Matthew Garrett wrote:
> > The fact is, some hardware pushes secure boot pretty hard. That has
> > *nothing* to do with some "lockdown" mode.
>
> Secure Boot ensures that the firmware will only load signed bootloaders. If
> a signed bootloader loads a
tcon->ses is being dereferenced before it is null checked, hence
there is a potential null pointer dereference.
Fix this by moving the pointer dereference after tcon->ses has
been properly null checked.
Addresses-Coverity-ID: 1467426 ("Dereference before null check")
Fixes: 93012bf98416 ("cifs:
On Tue, Apr 3, 2018 at 2:08 PM, Matthew Garrett wrote:
>
> Secure Boot ensures that the firmware will only load signed bootloaders. If
> a signed bootloader loads a kernel that's effectively an unsigned
> bootloader, there's no point in using Secure Boot
Bullshit.
I may want to know that I'm
Add null check on kmalloc() return value in order to prevent
a null pointer dereference.
Addresses-Coverity-ID: 1467429 ("Dereference null return value")
Fixes: 37c3347eb247 ("net: thunderx: add ndo_set_rx_mode callback
implementation for VF")
Signed-off-by: Gustavo A. R. Silva
---
From: Steven Rostedt (VMware)
While debugging an issue I needed to see if the pointers were being
processed correctly with trace_printk() and after using "%p" and
triggering my bug and trace output, I was disappointed that all my
pointers were random garbage and didn't produce anything useful
On Fri, 2018-03-23 at 10:54 +0100, Greg Kroah-Hartman wrote:
> 4.4-stable review patch. If anyone has any objections, please let me know.
>
> --
>
> From: Shaohua Li
>
>
> [ Upstream commit b506335e5d2b4ec687dde392a3bdbf7601778f1d ]
>
> Commit 6f287ca(md/raid10: reset the
On Tue, Apr 3, 2018 at 2:26 PM Linus Torvalds
wrote:
> On Tue, Apr 3, 2018 at 2:08 PM, Matthew Garrett wrote:
> >
> > Secure Boot ensures that the firmware will only load signed
bootloaders. If
> > a signed bootloader loads a kernel that's effectively an unsigned
> > bootloader, there's no
On Tue, Apr 3, 2018 at 2:21 PM Al Viro wrote:
> On Tue, Apr 03, 2018 at 09:08:54PM +, Matthew Garrett wrote:
> > If you don't want Secure Boot, turn it off. If you want Secure Boot,
use a
> > kernel that behaves in a way that actually increases your security.
> That assumes you *can* turn
On 03/30/2018 01:53 AM, Salvatore Mesoraca wrote:
All ciphers implemented in Linux have a block size less than or
equal to 16 bytes and the most demanding hw require 16 bytes
alignment for the block buffer.
We avoid 2 VLAs[1] by always allocating 16 bytes with 16 bytes
alignment, unless the
On Mon, 2 Apr 2018 15:57:29 -0600 nagarathnam.muthus...@oracle.com wrote:
> pid_t translate_pid(pid_t pid, int source, int target);
>
> This syscall converts pid from source pid-ns into pid in target pid-ns.
> If pid is unreachable from target pid-ns it returns zero.
>
> Pid-namespaces are
On Fri, 2018-03-23 at 10:54 +0100, Greg Kroah-Hartman wrote:
> 4.4-stable review patch. If anyone has any objections, please let me know.
>
> --
>
> From: Timmy Li
>
>
> [ Upstream commit 412b65d15a7f8a93794653968308fc100f2aa87c ]
[...]
This is not a correct fix; please also
Alan Stern wrote:
> + * Returns: 1 if @lock is locked, 0 otherwise.
> + * However, on !CONFIG_SMP builds with !CONFIG_DEBUG_SPINLOCK,
> + * the return value is always 0 (see include/linux/spinlock_up.h).
> + * Therefore you should not rely heavily on the return value.
Seems reasonable.
It
On Tue, Apr 3, 2018 at 2:31 PM, Steven Rostedt wrote:
> From: Steven Rostedt (VMware)
>
> While debugging an issue I needed to see if the pointers were being
> processed correctly with trace_printk() and after using "%p" and
> triggering my bug and trace output, I was disappointed that all my
>
On Tue, Apr 03, 2018 at 05:06:12PM -0400, Steven Rostedt wrote:
> On Tue, 3 Apr 2018 13:07:58 -0700
> Kees Cook wrote:
>
> > On Tue, Apr 3, 2018 at 12:41 PM, Steven Rostedt wrote:
> > > Both trace_debug is set and kptr_restrict is set to zero in the same
> > > code that produces the above
On Fri, 2018-03-23 at 10:54 +0100, Greg Kroah-Hartman wrote:
> 4.4-stable review patch. If anyone has any objections, please let me know.
>
> --
>
> From: Moritz Fischer
>
>
> [ Upstream commit 453d0744f6c6ca3f9749b8c57c2e85b5b9f52514 ]
>
> The issue is that the internal
Hi all,
While doing some static analysis I came across the following piece of code at
drivers/crypto/chelsio/chtls/chtls_io.c:1203:
1203 if (!size)
1204 break;
1205
1206 if (unlikely(ULP_SKB_CB(skb)->flags &
ULPCB_FLAG_NO_APPEND))
1207
On 04/03/2018 02:29 PM, Gustavo A. R. Silva wrote:
> Add null check on kmalloc() return value in order to prevent
> a null pointer dereference.
>
> Addresses-Coverity-ID: 1467429 ("Dereference null return value")
> Fixes: 37c3347eb247 ("net: thunderx: add ndo_set_rx_mode callback
>
On 04/03/2018 02:43 PM, David Howells wrote:
> Alan Stern wrote:
>
>> + * Returns: 1 if @lock is locked, 0 otherwise.
>> + * However, on !CONFIG_SMP builds with !CONFIG_DEBUG_SPINLOCK,
>> + * the return value is always 0 (see include/linux/spinlock_up.h).
>> + * Therefore you should not rely
On Tue, 3 Apr 2018, Ard Biesheuvel wrote:
> [snip]
Thanks for the input -- there are obviously still issues to be resolved.
I'll now not be pushing these to Linus for v4.17.
--
James Morris
On 04/03/2018 02:38 PM, Andrew Morton wrote:
On Mon, 2 Apr 2018 15:57:29 -0600 nagarathnam.muthus...@oracle.com wrote:
pid_t translate_pid(pid_t pid, int source, int target);
This syscall converts pid from source pid-ns into pid in target pid-ns.
If pid is unreachable from target pid-ns it
On Tue, Apr 3, 2018 at 12:29 PM, Matthew Garrett wrote:
> On Tue, Apr 3, 2018 at 9:46 AM Andy Lutomirski wrote:
>> On Tue, Apr 3, 2018 at 9:29 AM, Matthew Garrett wrote:
>> > A kernel that allows users arbitrary access to ring 0 is just an
>> > overfeatured bootloader. Why would you want secure
On Tue, 3 Apr 2018 14:45:28 -0700 Nagarathnam Muthusamy
wrote:
> > This changelog doesn't explain what the value is to our users. I
> > assume it is a performance optimization because "backward translation
> > requires scanning all tasks"? If so, please show us real-world
> > examples of the
On 04/03/2018 04:47 PM, Eric Dumazet wrote:
On 04/03/2018 02:29 PM, Gustavo A. R. Silva wrote:
Add null check on kmalloc() return value in order to prevent
a null pointer dereference.
Addresses-Coverity-ID: 1467429 ("Dereference null return value")
Fixes: 37c3347eb247 ("net: thunderx: add
On 04/03/2018 02:52 PM, Andrew Morton wrote:
On Tue, 3 Apr 2018 14:45:28 -0700 Nagarathnam Muthusamy
wrote:
This changelog doesn't explain what the value is to our users. I
assume it is a performance optimization because "backward translation
requires scanning all tasks"? If so, please
On Wed, 28 Mar 2018, Laurent Dufour wrote:
> >> diff --git a/include/linux/mm.h b/include/linux/mm.h
> >> index 4d02524a7998..2f3e98edc94a 100644
> >> --- a/include/linux/mm.h
> >> +++ b/include/linux/mm.h
> >> @@ -300,6 +300,7 @@ extern pgprot_t protection_map[16];
> >> #define FAULT_FLAG_USER
Speaking more with our internal LLVM teams, there ARE a few different
approaches to implementing asm-goto in LLVM proposed, by external parties
to Google. These proposals haven't progressed to code review, so we've
asked our LLVM teams to reignite these discussions with increased priority,
if not
On Tue, Apr 3, 2018 at 12:49 PM, David Howells wrote:
> Andy Lutomirski wrote:
>
>> >>> A kernel that allows users arbitrary access to ring 0 is just an
>> >>> overfeatured bootloader. Why would you want secure boot in that case?
>> >>
>> >> To get a chain of trust.
>> >
>> > You don't have a
I noticed commit 2554db916586 ("sched/wait: Break up long wake list
walk") in which it is claimed that
|We saw page wait list that are up to 3700+ entries long in tests of
|large 4 and 8 socket systems.
Here is another approach: instead of a waitlist a rbtree is used. The
tree is ordered by page
On Tue, 3 Apr 2018 14:43:43 -0700
Kees Cook wrote:
> > A static_key is added called "trace_debug" and if it is set, then %p will
> > not be hashed.
>
> Hrm, well, using a static key does make it weirder for an attacker to enable.
> :)
Not just weirder, much more difficult. static_keys are
Add null check on kmalloc() return value in order to prevent
a null pointer dereference.
Addresses-Coverity-ID: 1467429 ("Dereference null return value")
Fixes: 37c3347eb247 ("net: thunderx: add ndo_set_rx_mode callback
implementation for VF")
Signed-off-by: Gustavo A. R. Silva
---
Changes in
Fix PACKET_RX_RING bug for versions TPACKET_V1 and TPACKET_V2 which
casues the ring to get corrupted by allowing multiple kernel threads
to claim ownership of the same ring entry, Mark the ring entry as
already being used within the spin_lock to prevent other kernel
threads from reusing the same
Hi!
> > If you had a register dump from android with mics working, preferably
> > not in speaker mode, perhaps I could try to figure it out?
>
> OK here are four diffs against starting the phone app for regular
> call, speaker call, and muted versions of them:
>
>
Hi Jacopo,
On Tuesday, 27 March 2018 11:16:01 EEST jacopo mondi wrote:
> On Mon, Mar 26, 2018 at 10:03:31PM +0300, Laurent Pinchart wrote:
> > On Sunday, 25 March 2018 15:01:11 EEST Peter Rosin wrote:
> >> On 2018-03-20 14:56, Laurent Pinchart wrote:
> >>> On Sunday, 18 March 2018 00:15:24 EET
When using wicked with a lan78xx device attached to the system, we
end up with ethtool commands issued on the device before an ifup
got issued. That lead to the following crash:
Unable to handle kernel NULL pointer dereference at virtual address 039c
pgd = 800035b3
Hi Peter,
Thank you for the patch.
On Tuesday, 27 March 2018 00:24:43 EEST Peter Rosin wrote:
> Start list of actual chips compatible with "lvds-encoder".
>
> Signed-off-by: Peter Rosin
Reviewed-by: Laurent Pinchart
> ---
> .../devicetree/bindings/display/bridge/lvds-transmitter.txt
Hi again,
On Wednesday, 4 April 2018 01:28:29 EEST Laurent Pinchart wrote:
> On Wednesday, 28 March 2018 10:08:26 EEST Daniel Vetter wrote:
> > On Mon, Mar 26, 2018 at 11:24:42PM +0200, Peter Rosin wrote:
> > > Hi!
> > >
> > > [I got to v2 sooner than expected]
> > >
> > > I have an Atmel
On Sun, 1 Apr 2018 22:35:06 -0400 jgli...@redhat.com wrote:
> From: Ralph Campbell
>
> Use of pte_write(pte) is only valid for present pte, the common code
> which set the migration entry can be reach for both valid present
> pte and special swap entry (for device memory). Fix the code to use
Andy Lutomirski wrote:
> > If the user can arbitrarily modify the running kernel image, you cannot
> > trust anything. You cannot determine the trustworthiness of something
> > because your basis for determining that trust can be compromised.
>
> I'm having a very, very hard time coming up
On Tue, 03 Apr 2018 05:56:18 PDT (-0700), Arnd Bergmann wrote:
On Tue, Apr 3, 2018 at 2:44 PM, Sinan Kaya wrote:
On 4/3/2018 7:13 AM, Arnd Bergmann wrote:
On Tue, Apr 3, 2018 at 12:49 PM, Mark Rutland wrote:
Hi,
On Fri, Mar 30, 2018 at 11:58:13AM -0400, Sinan Kaya wrote:
The default
Hi Daniel,
On Wednesday, 28 March 2018 10:08:26 EEST Daniel Vetter wrote:
> On Mon, Mar 26, 2018 at 11:24:42PM +0200, Peter Rosin wrote:
> > Hi!
> >
> > [I got to v2 sooner than expected]
> >
> > I have an Atmel sama5d31 hooked up to an lvds encoder and then
> > on to an lvds panel. Which seems
From: Michael Kelley
Add comments describing intricacies of Hyper-V ring buffer
signaling code. This information is not in Hyper-V public
documents, so include here to capture the knowledge for
future coders.
There are no code changes in this commit.
Signed-off-by: Michael Kelley
---
On Tue, 3 Apr 2018 12:52:20 -0700
Tim Tianyang Chen wrote:
> Hi Steve, did you get a chance to take a look? cc'ing myself and a
> personal email. When I sent the patchset I forgot to include.
Sorry, I'm trying to get my own ktest patches in (I have a bunch of non
committed changes) and I need
An ability to manipulate mm_struct fields was introduced in
sake of CRIU in first place. Later we provide more suitable
and safe operation PR_SET_MM_MAP where all fields to be modifed
are passed in one structure which allows us to make more detailed
verification.
Still old interface remains
On Tue, 03 Apr 2018 02:24:25 PDT (-0700), matt.redfe...@mips.com wrote:
When these are included into arch Kconfig files, maintaining
alphabetical ordering of the selects means these get split up. To allow
for keeping things tidier and alphabetical, rename the selects to
GENERIC_LIB_*
For non-paranoid entries, idtentry knows how to switch from the
kernel stack to the user stack, as does error_entry. This results
in pointless duplication and code bloat. Make idtentry stop
thinking about stacks for non-paranoid entries.
This reduces text size by 5377 bytes.
This goes back to
On Tue, Apr 3, 2018 at 3:32 PM, David Howells wrote:
> Andy Lutomirski wrote:
>
>> > If the user can arbitrarily modify the running kernel image, you cannot
>> > trust anything. You cannot determine the trustworthiness of something
>> > because your basis for determining that trust can be
On Tue, 03 Apr 2018 05:03:56 PDT (-0700), t...@linutronix.de wrote:
Palmer Dabbelt (2):
genirq: Add CONFIG_GENERIC_IRQ_MULTI_HANDLER
RISC-V: Move to the new GENERIC_IRQ_MULTI_HANDLER handler
Oh, sorry, I must have screwed something up here. I attempted to send out a v4
of this
On Tue, 03 Apr 2018 06:51:06 PDT (-0700), matt.redfe...@mips.com wrote:
Hi Palmer,
On 29/03/18 22:59, Palmer Dabbelt wrote:
On Thu, 29 Mar 2018 03:41:21 PDT (-0700), matt.redfe...@mips.com wrote:
From: Palmer Dabbelt
As part of the MIPS conversion to use the generic GCC library routines,
Add an atomic helper to implement dirtyfb support. This is needed to
support DSI command-mode panels with x11 userspace (ie. when we can't
rely on pageflips to trigger a flush to the panel).
To signal to the driver that the async atomic update needs to
synchronize with fences, even though the fb
On Tue, 03 Apr 2018 07:45:45 PDT (-0700), jho...@kernel.org wrote:
On Tue, Apr 03, 2018 at 02:51:06PM +0100, Matt Redfearn wrote:
On 29/03/18 22:59, Palmer Dabbelt wrote:
> Ah, thanks, I think I must have forgotten about this. I assume these
> three are going through your tree?
Yeah I think
On Tue, Apr 3, 2018 at 3:39 PM, Andy Lutomirski wrote:
>
> Sure. I have no problem with having an upstream kernel have a
> lockdown feature, although I think that feature should distinguish
> between reads and writes. But I don't think the upstream kernel
> should apply a patch that ties any of
On Tue, Apr 3, 2018 at 3:46 PM Linus Torvalds
wrote:
> For example, I love signed kernel modules. The fact that I love them
> has absolutely zero to do with secure boot, though. There is
> absolutely no linkage between the two issues: I use (self-)signed
> kernel modules simply because I think
On Tue, 3 Apr 2018, Laurent Vivier wrote:
> FWIW, for the series:
>
FWIW,
https://en.wikipedia.org/wiki/Floppy_disk_hardware_emulator
;-)
On Tue, Apr 3, 2018 at 3:51 PM, Matthew Garrett wrote:
> On Tue, Apr 3, 2018 at 3:46 PM Linus Torvalds
>
> wrote:
>
>> For example, I love signed kernel modules. The fact that I love them
>> has absolutely zero to do with secure boot, though. There is
>> absolutely no linkage between the two
On Tue, 3 Apr 2018 18:11:19 +0200
Michal Hocko wrote:
> You can do so, of course. In fact it would have some advantages over
> single pages because you would fragment the memory less but this is not
> a reliable prevention from OOM killing and the complete memory
> depletion if you allow
On Wed, 4 Apr 2018 07:43:49 +1000
"Tobin C. Harding" wrote:
> > static noinline_for_stack
> > char *restricted_pointer(char *buf, char *end, const void *ptr,
> > @@ -1962,6 +1963,10 @@ char *pointer(const char *fmt, char *buf, char *end,
> > void *ptr,
> > return
On Tue, Apr 03, 2018 at 03:30:46PM -0700, Andrew Morton wrote:
> On Sun, 1 Apr 2018 22:35:06 -0400 jgli...@redhat.com wrote:
>
> > From: Ralph Campbell
> >
> > Use of pte_write(pte) is only valid for present pte, the common code
> > which set the migration entry can be reach for both valid
Hi all,
On Thu, 15 Mar 2018 09:56:56 +1100 Stephen Rothwell
wrote:
>
> [Just adding Dimitry to cc]
>
> On Thu, 15 Mar 2018 09:37:05 +1100 Stephen Rothwell
> wrote:
> >
> > Today's linux-next merge of the asm-generic tree got a conflict in:
> >
> > drivers/input/joystick/analog.c
> >
> >
On Tue, 2018-04-03 at 20:54 +0200, Ladislav Michl wrote:
> >
> > No dai device.
>
> As all call sites are already providing error message, so what about just
> removing this one completely?
No idea, none of this is code I know or care about.
Do what's appropriate.
On Tue, Apr 3, 2018 at 3:51 PM, Matthew Garrett wrote:
>
> Lockdown is clearly useful without Secure Boot (and I intend to deploy it
> that way for various things), but I still don't understand why you feel
> that the common case of booting a kernel from a boot chain that's widely
> trusted
Hi all,
On Thu, 15 Mar 2018 09:42:01 +1100 Stephen Rothwell
wrote:
>
> Today's linux-next merge of the asm-generic tree got a conflict in:
>
> arch/blackfin/kernel/bfin_ksyms.c
>
> between commit:
>
> 4d9c7a5907dd ("kbuild: rename built-in.o to built-in.a")
>
> from the kbuild tree and
On Tue, Apr 3, 2018 at 3:53 PM Andy Lutomirski wrote:
> On Tue, Apr 3, 2018 at 3:51 PM, Matthew Garrett wrote:
> > Lockdown is clearly useful without Secure Boot (and I intend to deploy
it
> > that way for various things), but I still don't understand why you feel
> > that the common case of
Hi all,
On Thu, 15 Mar 2018 12:29:21 +1100 Stephen Rothwell
wrote:
>
> Today's linux-next merge of the v4l-dvb tree got a conflict in:
>
> drivers/media/platform/blackfin/bfin_capture.c
>
> between commit:
>
> b9ec40bf7d29 ("media: platform: remove blackfin capture driver")
>
> from the
On Tue, Apr 3, 2018 at 4:08 PM, Linus Torvalds
wrote:
>
> This discussion is over until you give an actual honest-to-goodness
> reason for why you tied the two features together. No more "Why not?"
> crap.
Side note: I suspect the reason is something along the lines of "there
are political
Hi all,
On Wed, 28 Mar 2018 09:02:22 +1100 Stephen Rothwell
wrote:
>
> Today's linux-next merge of the asm-generic tree got a conflict in:
>
> arch/metag/boot/dts/Makefile
>
> between commit:
>
> b985b71d295f ("kbuild: mark $(targets) as .SECONDARY and remove .PRECIOUS
> markers")
>
>
On Tue, Apr 3, 2018 at 5:03 AM Michal Hocko wrote:
> On Mon 02-04-18 19:50:50, Wang Long wrote:
> >
> > Hi, Johannes Weiner and Tejun Heo
> >
> > I use linux-4.4.y to test the new cgroup controller io and the current
> > stable kernel linux-4.4.y has the follow logic
> >
> >
> > int
Andy Lutomirski wrote:
> I'm having a very, very hard time coming up with a scenario where I
> can "trust" something if an attacker can get root but can't modify the
> running kernel image but I can't "trust" something if the attacker
> can [modify the running kernel image].
(I think the above
On 4/3/18 3:37 PM, Cyrill Gorcunov wrote:
An ability to manipulate mm_struct fields was introduced in
sake of CRIU in first place. Later we provide more suitable
and safe operation PR_SET_MM_MAP where all fields to be modifed
are passed in one structure which allows us to make more detailed
On Tue, 3 Apr 2018 17:55:25 -0400
Jon Rosen wrote:
> Fix PACKET_RX_RING bug for versions TPACKET_V1 and TPACKET_V2 which
> casues the ring to get corrupted by allowing multiple kernel threads
> to claim ownership of the same ring entry, Mark the ring entry as
> already being used within the
On Tue, Apr 3, 2018 at 4:08 PM Linus Torvalds
wrote:
> That's not the right approach to begin with, Matthew. The onus is on
> *you* to explain why you tied them together, not on others to explain
> to you - over and over - that they have nothing to do with each other.
1) Secure Boot is
On Tue, Apr 3, 2018 at 4:17 PM, Matthew Garrett wrote:
>
> 1) Secure Boot is intended to permit the construction of a boot chain that
> only runs ring 0 code that the user considers trustworthy
No.
That may be *one* intention, for some people.
It's not an a-priori one for the actual user.
>
On Tue, Apr 3, 2018 at 4:12 PM, David Howells wrote:
>
> What use is secure boot if processes run as root can subvert your kernel?
Stop this idiocy.
The above has now been answered multiple times, several different ways.
The "point" of secure boot may be that you had no choice, or there was
no
1 - 100 of 1836 matches
Mail list logo
