Hi all,
The FS_IOC_SETFLAGS and FS_IOC_FSSETXATTR ioctls were promoted from ext4
and XFS, respectively, into the VFS. However, we didn't promote any of
the parameter checking code from those filesystems, which lead to a mess
where each filesystem open-codes whatever parameter checks they want
Currently, MSI-X vector enabling and allocation for a PCIe device is
static i.e. a device driver gets only one chance to enable a specific
number of MSI-X vectors, usually during device probe. Also, in many
cases, drivers usually reserve more than required number of vectors
anticipating their use,
On Fri, Jun 21, 2019 at 10:25:23AM -0400, Alan Stern wrote:
> On Fri, 21 Jun 2019, Andrea Parri wrote:
>
> > On Thu, Jun 20, 2019 at 11:55:58AM -0400, Alan Stern wrote:
> > > Herbert Xu recently reported a problem concerning RCU and compiler
> > > barriers. In the course of discussing the
Christoph Hellwig's on June 21, 2019 6:15 pm:
> On Thu, Jun 20, 2019 at 10:21:46AM -0700, Linus Torvalds wrote:
>> Hmm. Honestly, I've never seen anything like that in any kernel profiles.
>>
>> Compared to the problems I _do_ see (which is usually the obvious
>> cache misses, and locking), it
Eric is talking about this patch, I think:
https://patchwork.ozlabs.org/patch/1120222/
I guess I'll ask people on the github thread to test that too.
Linus
On Fri, Jun 21, 2019 at 3:38 PM Eric Dumazet wrote:
>
> Please look at my recent patch.
> Sorry I am travelling
On Fri, 21 Jun 2019, Marc Gonzalez wrote:
> On 21/06/2019 01:43, Finn Thain wrote:
>
> > On Thu, 20 Jun 2019, Marc Gonzalez wrote:
> >
> >> How likely is it that distro kernels would *not* enable CHR_DEV_SG?
> >> (Distros tend to enable everything, and then some.)
> >
> > How likely is it
On Fri, Jun 21, 2019 at 10:50:27AM -0700, Paul E. McKenney wrote:
> On Fri, Jun 21, 2019 at 10:41:04AM -0700, Paul E. McKenney wrote:
> > On Fri, Jun 21, 2019 at 06:34:14AM -0700, Paul E. McKenney wrote:
> > > On Fri, Jun 21, 2019 at 02:29:27PM +0200, Peter Zijlstra wrote:
> > > > On Fri, Jun 21,
kernel test robot's on June 21, 2019 6:20 pm:
> FYI, we noticed the following commit (built with gcc-7):
>
> commit: c427534e48381727924529455ddfa67e2985686d ("kernel/isolation: Asset
> that a housekeeping CPU comes up at boot time")
>
On Fri, Jun 21, 2019 at 4:07 PM Pierre-Loup A. Griffais
wrote:
>
>
>
> On 6/21/19 3:38 PM, Eric Dumazet wrote:
> > Please look at my recent patch.
> > Sorry I am travelling
> >
> > On Fri, Jun 21, 2019, 6:19 PM Linus Torvalds
> > mailto:torva...@linux-foundation.org>>
> > wrote:
> >
> >
On Fri, 21 Jun 2019 20:24:59 +0200 David Hildenbrand wrote:
> @Qian Cai, unfortunately I can't reproduce.
>
> If you get the chance, it would be great if you could retry with
>
> diff --git a/drivers/base/memory.c b/drivers/base/memory.c
> index 972c5336bebf..742f99ddd148 100644
> ---
On 6/20/19 4:10 PM, Tim Chen wrote:
> Add documentation for Spectre vulnerability and the mitigation mechanisms:
>
> - Explain the problem and risks
> - Document the mitigation mechanisms
> - Document the command line controls
> - Document the sysfs files
>
> Co-developed-by: Andi Kleen
>
This introduces a new command to retrieve a variable number of entries
from a bpf map wrapping the existing bpf methods:
map_get_next_key and map_lookup_elem
Note that map_dump doesn't guarantee that reading the entire table is
consistent since this function is always racing with kernel and user
Adds bpf_attr.dump structure to libbpf.
Suggested-by: Stanislav Fomichev
Signed-off-by: Brian Vazquez
---
tools/include/uapi/linux/bpf.h | 9 +
1 file changed, 9 insertions(+)
diff --git a/tools/include/uapi/linux/bpf.h b/tools/include/uapi/linux/bpf.h
index
This tests compares the amount of time that takes to read an entire
table of 100K elements on a bpf hashmap using both BPF_MAP_DUMP and
BPF_MAP_GET_NEXT_KEY + BPF_MAP_LOOKUP_ELEM.
Signed-off-by: Brian Vazquez
---
tools/testing/selftests/bpf/test_maps.c | 71 +
1 file
Move reusable code from map_lookup_elem to helper functions to avoid code
duplication in kernel/bpf/syscall.c
Suggested-by: Stanislav Fomichev
Signed-off-by: Brian Vazquez
---
kernel/bpf/syscall.c | 134 +++
1 file changed, 73 insertions(+), 61
This tests exercise the new command on a bpf hashmap and make sure it
works as expected.
Signed-off-by: Brian Vazquez
---
tools/testing/selftests/bpf/test_maps.c | 70 -
1 file changed, 68 insertions(+), 2 deletions(-)
diff --git
Make libbpf aware of new BPF_MAP_DUMP command and add bpf_map_dump and
bpf_map_dump_flags to use them from the library.
Suggested-by: Stanislav Fomichev
Signed-off-by: Brian Vazquez
---
tools/lib/bpf/bpf.c | 28
tools/lib/bpf/bpf.h | 4
This introduces a new command to retrieve a variable number of entries
from a bpf map.
This new command can be executed from the existing BPF syscall as follows:
err = bpf(BPF_MAP_DUMP, union bpf_attr *attr, u32 size)
using attr->dump.map_fd, attr->dump.prev_key, attr->dump.buf,
On 14/03/2019 02.58, George Spelvin wrote:
> On Thu, 14 Mar 2019 at 00:28:16 +0100, Rasmus Villemoes wrote:
>> Similarly one could do a SORT_SIMPLE_CMP() for when sorting an array of
>> structs according to a single numeric member. That sort is not stable,
>> so the comparison functions would
On 6/21/19 3:38 PM, Eric Dumazet wrote:
Please look at my recent patch.
Sorry I am travelling
On Fri, Jun 21, 2019, 6:19 PM Linus Torvalds
mailto:torva...@linux-foundation.org>>
wrote:
On Fri, Jun 21, 2019 at 2:41 PM Greg Kroah-Hartman
mailto:gre...@linuxfoundation.org>>
From: Luke Nelson
This is an eBPF JIT for RV32G, adapted from the JIT for RV64G.
Any feedback would be greatly appreciated.
It passes 359 out of 378 tests in test_bpf.ko. The failing tests are
features that are not supported right now:
- ALU64 DIV/MOD:
These require loops to emulate on
On Fri, Jun 21, 2019 at 11:33 AM Joe Perches wrote:
>
> On Fri, 2019-06-21 at 13:12 -0500, Bjorn Helgaas wrote:
> > On Fri, Jun 21, 2019 at 12:27 PM Joe Perches wrote:
> []
> > > Subsystem specific local PCI #defines without generic
> > > naming is poor style and makes treewide grep and
> > >
The pull request you sent on Fri, 21 Jun 2019 15:42:09 -0400:
> git://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdma.git tags/for-linus
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/121bddf39a8e39baf0df9ef1d688392c179935cd
Thank you!
--
Deet-doot-dot, I am a
On Thu, 2019-06-20 at 18:19 -0700, Matthew Garrett wrote:
> --- a/Documentation/admin-guide/kernel-parameters.txt
> +++ b/Documentation/admin-guide/kernel-parameters.txt
> @@ -2239,6 +2239,15 @@
> lockd.nlm_udpport=M [NFS] Assign UDP port.
> Format:
>
> +
On Wed, 2019-06-19 at 19:38 +0200, Greg Kroah-Hartman wrote:
> On Mon, Jun 17, 2019 at 11:59:16AM -0700, Atish Patra wrote:
> > Both RISC-V & ARM64 are using cpu-map device tree to describe
> > their cpu topology. It's better to move the relevant code to
> > a common place instead of duplicate
--
I, Mikhail Fridman have selected you specifically as one of my
beneficiaries for my Charitable Donation of $5 Million Dollars,
Check the link below for confirmation:
https://www.rt.com/business/343781-mikhail-fridman-will-charity/
I await your earliest response.
Best Regards,
Mikhail
On 06/21, Andrii Nakryiko wrote:
> )
>
> On Fri, Jun 21, 2019 at 9:11 AM Stanislav Fomichev wrote:
> >
> > On 06/21, kernel test robot wrote:
> > > FYI, we noticed the following commit (built with gcc-7):
> > >
> > > commit: 69d96519dbf0bfa1868dc8597d4b9b2cdeb009d7 ("selftests/bpf: convert
> >
On Fri, Jun 21, 2019 at 01:45:44PM -0400, J. Bruce Fields wrote:
> I'm not sure who to get review from for this kind of thing.
>
> Kees, you seem to be one of the only people to touch string_helpers.c
> at all recently, any ideas?
Hi! Yeah, I'm happy to take a look. Notes below...
>
> --b.
>
On 6/20/19 1:13 AM, Tao Ren wrote:
> On 6/20/19 1:01 AM, Ryan Chen wrote:
>> Hello Tao,
>> Let me more clear. When you set (3, 15, 14) the device sometimes
>> response nack.
>> but when you set (4, 7, 7), the device always ack. Am I right?
>> Ryan
>
> Hello Ryan,
>
> It's correct.
On Fri, Jun 21, 2019 at 2:41 PM Greg Kroah-Hartman
wrote:
>
> What specific commit caused the breakage?
Both on reddit and on github there seems to be confusion about whether
it's a problem or not. Some people have it working with the exact same
kernel that breaks for others.
And then some
On Fri, Jun 21, 2019 at 08:06:14PM +0300, Dmitry V. Levin wrote:
> On Thu, Jun 20, 2019 at 01:10:37PM +0200, Christian Brauner wrote:
> > On Thu, Jun 20, 2019 at 02:00:37PM +0300, Dmitry V. Levin wrote:
> > > Cc'ed more people as the issue is not just with the example but
> > > with the interface
On Fri, Jun 21, 2019 at 09:42:39AM +0800, Wanpeng Li wrote:
> On Thu, 20 Jun 2019 at 05:04, Marcelo Tosatti wrote:
> >
> > Hi Li,
> >
> > On Wed, Jun 19, 2019 at 08:36:06AM +0800, Wanpeng Li wrote:
> > > On Tue, 18 Jun 2019 at 21:36, Marcelo Tosatti wrote:
> > > >
> > > > On Mon, Jun 17, 2019 at
On Fri, 21 Jun 2019, Yash Shah wrote:
> DT node for SiFive FU540-C000 GEMGXL Ethernet controller driver added
>
> Signed-off-by: Yash Shah
Thanks, dropped the "reg-names" property from the patch, and queued the
following updated version for v5.2-rc.
- Paul
From: Yash Shah
Date: Fri, 21
On Fri, 2019-06-21 at 14:46 -0700, Atish Patra wrote:
> On Fri, 2019-06-21 at 14:18 -0500, Troy Benjegerdes wrote:
> > Can you post the fsbl and other images you used to boot/test this?
> >
>
Resending it without the attachment. Obviously, the mail did not go
through with the binary blob
On 6/21/19 2:41 PM, Greg Kroah-Hartman wrote:
On Fri, Jun 21, 2019 at 02:27:41PM -0700, Pierre-Loup A. Griffais wrote:
This seems to have broken us:
https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.1.11
Here's some affected users:
On Fri, Jun 21, 2019 at 02:27:41PM -0700, Pierre-Loup A. Griffais wrote:
> This seems to have broken us:
>
> https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.1.11
>
> Here's some affected users:
>
> https://github.com/ValveSoftware/steam-for-linux/issues/6326
>
>
On Fri, 21 Jun 2019, Rob Herring wrote:
> On Mon, Jun 10, 2019 at 3:46 PM Rob Herring wrote:
> >
> > On Sun, Jun 2, 2019 at 2:01 AM Paul Walmsley
> > wrote:
> > >
> > > At Rob's request, we're starting to migrate our DT binding
> > > documentation to json-schema YAML format. Start by
This seems to have broken us:
https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.1.11
Here's some affected users:
https://github.com/ValveSoftware/steam-for-linux/issues/6326
https://www.reddit.com/r/linux_gaming/comments/c37lmh/psa_steam_does_not_connect_on_kernels_newer_than/
On Tue, Jun 18, 2019 at 04:09:42AM -0700, Bitan Biswas wrote:
> The usage of BUG() macro is generally discouraged in kernel, unless
> it's a problem that results in a physical damage or loss of data.
> This patch removes unnecessary BUG() macros and replaces the rest
> with warning.
>
>
Arnd, Olof,
Still very few updates. It is mostly about removing DTC warnings by
switching the sckc to the proper bindings and converting the atmel
bindings to json-schema.
The following changes since commit a188339ca5a396acc588e5851ed7e19f66b0ebd9:
Linux 5.2-rc1 (2019-05-19 15:47:09 -0700)
Arnd, Olof,
A single fix for a warning when compiling with W=1
Please disregard the previous one, it doesn't point ot the correct
repository.
The following changes since commit a188339ca5a396acc588e5851ed7e19f66b0ebd9:
Linux 5.2-rc1 (2019-05-19 15:47:09 -0700)
are available in the Git
Arnd, Olof,
A single fix for a warning when compiling with W=1
The following changes since commit a188339ca5a396acc588e5851ed7e19f66b0ebd9:
Linux 5.2-rc1 (2019-05-19 15:47:09 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/abelloni/linux.git
On Mon, Jun 17, 2019 at 08:39:37PM +0200, Enrico Weigelt, metux IT consult
wrote:
> From: Enrico Weigelt
>
> Add more helper macros for trivial driver init cases, similar to the
> already existing module_i2c_driver()+friends - now for those which
> are initialized at other stages (eg. by
Em Mon, 17 Jun 2019 10:32:20 -0300
André Almeida escreveu:
> Add comments at vimc_streamer_s_stream and vimc_streamer_thread, making
> the vimc-stream totally documented.
I'm applying it right now.
Yet, if this is fully documented, IMO you should add it to
Documentation/media/v4l-drivers,
On Thu, 6 Jun 2019, David Rientjes wrote:
> The idea that I had was snipped from this, however, and it would be nice
> to get some feedback on it: I've suggested that direct reclaim for the
> purposes of hugepage allocation on the local node is never worthwhile
> unless and until memory
On Mon, Jun 17, 2019 at 09:53:01AM +0200, Fabrice Gasnier wrote:
> During probe, return the "get_irq" error value instead of -EINVAL which
> allows the driver to be deferred probed if needed.
> Fix also the case where of_irq_get() returns a negative value.
> Note :
> On failure of_irq_get()
On Fri, Jun 21, 2019 at 12:37 PM Matthew Garrett wrote:
> I'll check, I'm bad at finding these new fangled things.
Ah, I see - there's sysfs_match_string(), but that doesn't really work
for this case because we'd still need to do another set of checks to
see whether the level we get is in
On Fri, Jun 21, 2019 at 1:28 PM Nick Desaulniers
wrote:
>
> On Thu, Jun 20, 2019 at 1:17 AM Ard Biesheuvel
> wrote:
> > I think it is mostly controversial among non-security folks, who think
> > that every mitigation by itself should be bullet proof. Security folks
> > tend to think more about
On Fri, 21 Jun 2019, Alan Jenkins wrote:
> When setting the low and high watermarks we use min_wmark_pages(zone).
> I guess this was to reduce the line length. Then this macro was modified
> to include zone->watermark_boost. So we needed to set watermark_boost
> before we set the high and low
On Thu, 20 Jun 2019, Roman Gushchin wrote:
> As a result of reparenting a kmem_cache might belong to the root
> memory cgroup. It happens when a top-level memory cgroup is removed,
> and all associated kmem_caches are reparented to the root memory
> cgroup.
>
> The root memory cgroup is special,
On Wed, 19 Jun 2019, Shakeel Butt wrote:
> Currently for CONFIG_SLUB, if a memcg kmem cache creation is failed and
> the corresponding root kmem cache has SLAB_PANIC flag, the kernel will
> be crashed. This is unnecessary as the kernel can handle the creation
> failures of memcg kmem caches.
On Fri, Jun 21, 2019 at 10:33 PM Jason A. Donenfeld wrote:
>
> This further unifies the accessors for the fast and coarse functions, so
> that the same types of functions are available for each. There was also
> a bit of confusion with the documentation, which prior advertised a
> function that
On 6/19/19 1:15 AM, Thierry Reding wrote:
On Tue, Jun 18, 2019 at 10:58:40AM -0700, Sowjanya Komatineni wrote:
On 6/18/19 5:16 AM, Thierry Reding wrote:
On Tue, Jun 18, 2019 at 12:46:25AM -0700, Sowjanya Komatineni wrote:
This patch adds system suspend and resume support for Tegra210
On Fri, Jun 21, 2019 at 1:21 PM Nathan Chancellor
wrote:
>
> Clang warns when CONFIG_ACPI is unset:
>
> drivers/pinctrl/qcom/pinctrl-sdm845.c:1320:5: warning: 'CONFIG_ACPI' is
> not defined, evaluates to 0 [-Wundef]
> #if CONFIG_ACPI
> ^
> 1 warning generated.
>
> Use ifdef instead of if
On Fri, 2019-06-21 at 13:20 -0700, Nathan Chancellor wrote:
> Clang warns when CONFIG_ACPI is unset:
Any of these others need the same s/#if/#ifdef/ ?
$ git grep -P '^\s*#\s*if\s+CONFIG_[A-Z0-9_]+\s*$' *
arch/microblaze/include/asm/exceptions.h:#if
CONFIG_XILINX_MICROBLAZE0_USE_MSR_INSTR
This further unifies the accessors for the fast and coarse functions, so
that the same types of functions are available for each. There was also
a bit of confusion with the documentation, which prior advertised a
function that has never existed. Finally, the vanilla ktime_get_coarse()
was omitted
While this doesn't actually amount to a real difference, since the macro
evaluates to the same thing, every place else operates on ktime_t using
these functions, so let's not break the pattern.
Fixes: e3ff9c3678b4 ("timekeeping: Repair ktime_get_coarse*() granularity")
Signed-off-by: Jason A.
This makes boot uniformly boottime and tai uniformly clocktai, to
address the remaining oversights.
Signed-off-by: Jason A. Donenfeld
Cc: Arnd Bergmann
Cc: Thomas Gleixner
---
Documentation/core-api/timekeeping.rst | 2 +-
arch/x86/kvm/pmu.c |
On Thu, Jun 20, 2019 at 1:17 AM Ard Biesheuvel
wrote:
>
> On Thu, 20 Jun 2019 at 09:47, Will Deacon wrote:
>
> > On Wed, Jun 19, 2019 at 05:32:42PM -0700, Nick Desaulniers wrote:
> > > Generated via:
> > > $ ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- make defconfig
> > > $ ARCH=arm64
Clang warns when CONFIG_ACPI is unset:
drivers/pinctrl/qcom/pinctrl-sdm845.c:1320:5: warning: 'CONFIG_ACPI' is
not defined, evaluates to 0 [-Wundef]
#if CONFIG_ACPI
^
1 warning generated.
Use ifdef instead of if to resolve this.
Fixes: a229105d7a1e ("pinctrl: qcom: sdm845: Provide ACPI
On Fri, Jun 21, 2019 at 11:04 AM Krzysztof Kozlowski wrote:
>
> Enable support for Mali GPU with Panfrost driver, e.g. for Exynos5433
> and Exynos7 (having Mali T760).
>
> Signed-off-by: Krzysztof Kozlowski
> ---
> arch/arm64/configs/defconfig | 2 +-
> 1 file changed, 1 insertion(+), 1
On Sat, 22 Jun 2019, Suwan Kim wrote:
> There are bugs on vhci with usb 3.0 storage device. Originally, vhci
> doesn't supported SG. So, USB storage driver on vhci divides SG list
> into multiple URBs and it causes buffer overflow on the xhci of the
> server. So we need to add SG support to vhci
On Thu, Jun 20, 2019 at 10:22 PM Andy Lutomirski wrote:
> On Thu, Jun 20, 2019 at 6:21 PM Matthew Garrett
> wrote:
> > --- a/security/lockdown/lockdown.c
> > +++ b/security/lockdown/lockdown.c
> > @@ -33,6 +33,7 @@ static char
> > *lockdown_reasons[LOCKDOWN_CONFIDENTIALITY_MAX+1] = {
> >
On Friday, June 21, 2019 10:59:09 AM CEST Vinod Koul wrote:
> + /*
> + * The Firmware's Data Format is describe in
> + * "6.3 Data Format" R19UH0078EJ0500 Rev.5.00 page 124
> + */
> +
> + /* "Each row is 8 bytes". => firmware size must be a multiple of 8. */
> + if
Quoting Thomas Gleixner (2019-06-21 20:33:36)
> On Fri, 21 Jun 2019, Chris Wilson wrote:
>
> > Quoting Thomas Gleixner (2019-06-21 16:30:52)
> > > Chris, do you have the actual NMI lockup detector splats somewhere?
> >
> > Sorry, I'm having a hard time reproducing this at will now. The test
> >
Remove superfluous casts on output operands to avoid warnings on the
following macros:
* add_ss(sh, sl, ah, al, bh, bl)
* sub_ddmmss(sh, sl, ah, al, bh, bl)
* umul_ppmm(ph, pl, m0, m1)
Special care has been taken to keep the diff as minimal as possible from
the original header file
On Friday, June 21, 2019 10:59:10 AM CEST Vinod Koul wrote:
> From: Christian Lamparter
>
> This patch adds a firmware check for the uPD720201K8-711-BAC-A
> and uPD720202K8-711-BAA-A variant. Both of these chips are listed
> in Renesas' R19UH0078EJ0500 Rev.5.00 "User's Manual: Hardware" as
>
Hello!
On 06/20/2019 08:22 PM, Vignesh Raghavendra wrote:
> Cypress' HyperBus is Low Signal Count, High Performance Double Data Rate
> Bus interface between a host system master and one or more slave
> interfaces. HyperBus is used to connect microprocessor, microcontroller,
> or ASIC devices
On Mon, Jun 10, 2019 at 3:46 PM Rob Herring wrote:
>
> On Sun, Jun 2, 2019 at 2:01 AM Paul Walmsley wrote:
> >
> > At Rob's request, we're starting to migrate our DT binding
> > documentation to json-schema YAML format. Start by converting our cpu
> > binding documentation. While doing so,
On Friday, June 21, 2019 10:59:13 AM CEST Vinod Koul wrote:
> Allow multiple firmware file versions in table and load them in
> increasing order as we find them in the file system.
>
> Signed-off-by: Vinod Koul
> Cc: Yoshihiro Shimoda
> Cc: Christian Lamparter
> ---
>
Hi Linus,
This is probably our last -rc pull request. We don't have anything else
outstanding at the moment anyway, and with the summer months on us and
people taking trips, I expect the next weeks leading up to the merge
window to be pretty calm and sedate.
This has two simple, no brainer
On Friday, June 21, 2019 10:59:08 AM CEST Vinod Koul wrote:
> This series add support for Renesas USB controllers uPD720201 and uPD720202.
> These require firmware to be loaded and in case devices have ROM those can
> also be programmed if empty. If ROM is programmed, it runs from ROM as well.
>
The start and the size are 0 for online nodes without any memory. Avoid
the underflow, resulting in a very long loop and soft lockups.
Cc: Andrew Morton
Cc: Stephen Rothwell
Cc: Greg Kroah-Hartman
Cc: "Rafael J. Wysocki"
Cc: linux...@kvack.org
Reported-by: Qian Cai
Signed-off-by: David
On Thu, Jun 20, 2019 at 8:44 PM Kees Cook wrote:
>
> On Thu, Jun 20, 2019 at 06:19:14PM -0700, Matthew Garrett wrote:
> > +/*
> > + * If you add to this, remember to extend lockdown_reasons in
> > + * security/lockdown/lockdown.c.
> > + */
>
> Best to add something like:
>
>
Hi Linus,
The following changes since commit
9e0babf2c06c73cda2c0cd37a1653d823adb40ec:
Linux 5.2-rc5 (2019-06-16 08:49:45 -1000)
are available in the Git repository at:
git://git.linux-nfs.org/projects/anna/linux-nfs.git tags/nfs-for-5.2-
3
for you to fetch changes up to
On Fri, 21 Jun 2019, Chris Wilson wrote:
> Quoting Thomas Gleixner (2019-06-21 16:30:52)
> > Chris, do you have the actual NMI lockup detector splats somewhere?
>
> Sorry, I'm having a hard time reproducing this at will now. The test
> case depends on the right timing of the wrong event to cause
On Thu, Jun 20, 2019 at 8:23 PM Kees Cook wrote:
> bikeshed: can this just be called "security_locked_down" without the
> "is"?
Sure.
_memory_block_hinted()"
> > 5cfcd52288b6 Revert "drivers-base-memoryc-get-rid-of-
> > find_memory_block_hinted-
> > v3"
> >
> > [4.582081][T1] ACPI FADT declares the system doesn't support PCIe
> > ASPM,
> > so disable it
> &g
On Thu, Jun 20, 2019 at 10:23 PM Andy Lutomirski wrote:
>
> On Thu, Jun 20, 2019 at 6:22 PM Matthew Garrett
> wrote:
> >
> > The lockdown module is intended to allow for kernels to be locked down
> > early in boot - sufficiently early that we don't have the ability to
> > kmalloc() yet. Add
On Thu, Jun 20, 2019 at 8:22 PM Kees Cook wrote:
>
> On Thu, Jun 20, 2019 at 06:19:12PM -0700, Matthew Garrett wrote:
> > The lockdown module is intended to allow for kernels to be locked down
> > early in boot - sufficiently early that we don't have the ability to
> > kmalloc() yet. Add support
ry_hotplug: move and simplify
>>>> walk_memory_blocks()"
>>>> 59a9f3eec5d1 Revert "drivers/base/memory.c: Get rid of
>>>> find_memory_block_hinted()"
>>>> 5cfcd52288b6 Revert "drivers-base-memoryc-get-rid-of-
>>>> find_memory_blo
On Freitag, 21. Juni 2019 02:01:22 CEST you wrote:
> I think that it makes sense to put this snippet in qcom-msm8974.dtsi
> with a status of disabled, and then enable it in
> qcom-msm8974-fairphone-fp2.dts like so:
>
> imem@fe805000 {
> status = "ok";
> };
Do you want me to put the whole
On Fri, 2019-06-21 at 16:23 +0530, Yash Shah wrote:
> DT node for SiFive FU540-C000 GEMGXL Ethernet controller driver added
>
> Signed-off-by: Yash Shah
> ---
> arch/riscv/boot/dts/sifive/fu540-c000.dtsi | 16
>
> arch/riscv/boot/dts/sifive/hifive-unleashed-a00.dts |
On Thu, 20 Jun 2019, kernel test robot wrote:
> FYI, we noticed the following commit (built with gcc-7):
>
> commit: e1056a25daa6460c95e92d7d6853d05ad62458f7 ("x86/hotplug: Silence APIC
> and NMI when CPU is dead")
> https://git.kernel.org/cgit/linux/kernel/git/tip/tip.git WIP.x86/ipi
>
> in
ot;drivers/base/memory.c: Get rid of
> > > find_memory_block_hinted()"
> > > 5cfcd52288b6 Revert "drivers-base-memoryc-get-rid-of-
> > > find_memory_block_hinted-
> > > v3"
> > >
> > > [4.582081][T1] ACPI FADT declares
)
On Fri, Jun 21, 2019 at 9:11 AM Stanislav Fomichev wrote:
>
> On 06/21, kernel test robot wrote:
> > FYI, we noticed the following commit (built with gcc-7):
> >
> > commit: 69d96519dbf0bfa1868dc8597d4b9b2cdeb009d7 ("selftests/bpf: convert
> > socket_cookie test to sk storage")
> >
On Tue, Jun 4, 2019 at 12:16 PM Masahiro Yamada
wrote:
> --- a/Makefile
> +++ b/Makefile
> @@ -1363,7 +1363,7 @@ CLEAN_DIRS += $(MODVERDIR) include/ksym
> CLEAN_FILES += modules.builtin.modinfo
>
> # Directories & files removed with 'make mrproper'
> -MRPROPER_DIRS += include/config
From: kbuild test robot
drivers/staging/kpc2000/kpc_dma/kpc_dma_driver.c:200:3-8: No need to set .owner
here. The core will do it.
Remove .owner field if calls are used which set it automatically
Generated by: scripts/coccinelle/api/platform_no_drv_owner.cocci
Fixes: abddd78ef465 ("staging:
_block_hinted-
>> v3"
>>
>> [4.582081][T1] ACPI FADT declares the system doesn't support PCIe
>> ASPM,
>> so disable it
>> [4.590405][T1] ACPI: bus type PCI registered
>> [4.592908][T1] PCI: MMCONFIG for domain [bus 00-ff]
This patch adds missing mdio and ethernet PHY nodes for rk3328 ASUS
tinker board.
Signed-off-by: Katsuhiro Suzuki
---
arch/arm/boot/dts/rk3288-tinker.dtsi | 12
1 file changed, 12 insertions(+)
diff --git a/arch/arm/boot/dts/rk3288-tinker.dtsi
tree: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git WIP.x86/cpu
head: 707e6befd43ba8d754485d8d02ed4f49ec8ec667
commit: 41cf6ccef21080168970226f657daff26ecaf3e1 [8/17] x86/process/64: Use
FSGSBASE instructions on thread copy and ptrace
config: x86_64-randconfig-x016-201924
As a wakeup source when the system is in suspend there is little point
trying to access a register across the i2c bus as it is probably still
inactive. We need to prevent the irq handler from being called during
suspend.
Without this modification upon wakeup you would see the following kernel
When binding an interdomain event channel to a vcpu via
IOCTL_EVTCHN_BIND_INTERDOMAIN not only the event channel needs to be
bound, but the affinity of the associated IRQi must be changed, too.
Otherwise the IRQ and the event channel won't be moved to another vcpu
in case the original vcpu they
The relation between ag_shift and blocks_per_ag is a bit more complex,
and also depends on the fs block size.
Since blocks_per_ag is not even being used, simply omit the check.
Signed-off-by: Axel Dörfler
---
fs/befs/super.c | 7 ---
1 file changed, 7 deletions(-)
diff --git
This just enables LFS support in the VFS. The implementation already
supports large files.
Signed-off-by: Axel Dörfler
---
fs/befs/linuxvfs.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/fs/befs/linuxvfs.c b/fs/befs/linuxvfs.c
index 462d096ff3e9..1d7d91c2e63f 100644
---
tree: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git WIP.x86/cpu
head: 707e6befd43ba8d754485d8d02ed4f49ec8ec667
commit: 54f792cc63c56d994651c8e83d059d6fac00fbf9 [11/17] x86/entry/64: Handle
FSGSBASE enabled paranoid entry/exit
config: x86_64-kexec (attached as .config)
compiler:
Quoting Thomas Gleixner (2019-06-21 16:30:52)
> Chris, do you have the actual NMI lockup detector splats somewhere?
Sorry, I'm having a hard time reproducing this at will now. The test
case depends on the right timing of the wrong event to cause the GPU to
hang.
>From memory, I got the
> On Jun 21, 2019, at 5:12 AM, Peter Zijlstra wrote:
>
> On Fri, Jun 21, 2019 at 02:09:23PM +0200, Peter Zijlstra wrote:
>
>> --- /dev/null
>> +++ b/arch/x86/include/asm/jump_label_asm.h
>> @@ -0,0 +1,44 @@
>> +/* SPDX-License-Identifier: GPL-2.0 */
>> +#ifndef _ASM_X86_JUMP_LABEL_ASM_H
>>
On Fri, 2019-06-21 at 13:12 -0500, Bjorn Helgaas wrote:
> On Fri, Jun 21, 2019 at 12:27 PM Joe Perches wrote:
[]
> > Subsystem specific local PCI #defines without generic
> > naming is poor style and makes treewide grep and
> > refactoring much more difficult.
>
> Don't worry, we have the same
memoryc-get-rid-of-find_memory_block_hinted-
> v3"
>
> [4.582081][T1] ACPI FADT declares the system doesn't support PCIe
> ASPM,
> so disable it
> [4.590405][T1] ACPI: bus type PCI registered
> [4.592908][T1] PCI: MMCONFIG for domain [bus 00-ff] at
101 - 200 of 831 matches
Mail list logo
