On 2020-05-25 17:37, Jason Gunthorpe wrote:
...
commit 318b275fbca1ab9ec0862de71420e0e92c3d1aa7
Author: Gleb Natapov
Date: Tue Mar 22 16:30:51 2011 -0700
mm: allow GUP to fail instead of waiting on a page
GUP user may want to try to acquire a reference to a page if it is already
On Mon, May 25, 2020 at 01:56:28PM -0700, John Hubbard wrote:
> On 2020-05-25 09:56, Jason Gunthorpe wrote:
> > On Mon, May 25, 2020 at 11:11:42AM -0400, Peter Xu wrote:
> > > On Mon, May 25, 2020 at 11:46:51AM -0300, Jason Gunthorpe wrote:
> > > > On Mon, May 25, 2020 at 10:28:06AM -0400, Peter
On 2020-05-24, Arvind Sankar wrote:
The compressed kernel currently contains bogus runtime relocations in
the startup code in head_{32,64}.S, which are generated by the linker,
but must not actually be processed at runtime.
This generates warnings when linking with the BFD linker, and errors
On Thu, May 14, 2020 at 08:11:24AM -0700, Divya Indi wrote:
> static void ib_nl_set_path_rec_attrs(struct sk_buff *skb,
>struct ib_sa_query *query)
> {
> @@ -889,6 +904,15 @@ static int ib_nl_make_request(struct ib_sa_query *query,
> gfp_t gfp_mask)
>
Hi Tycho,
On Mon, May 25, 2020 at 10:36 PM Tycho Andersen wrote:
>
> On Mon, May 25, 2020 at 02:18:26PM +, guo...@kernel.org wrote:
> > From: Guo Ren
> >
> > Obviously, there is no need to recover a0-a7 in reject path.
> >
> > Previous modification is from commit af33d243 by Tycho, to
> >
Hi
[This is an automated email]
This commit has been processed because it contains a -stable tag.
The stable tag indicates that it's relevant for the following trees: all
The bot has tested the following trees: v5.6.14, v5.4.42, v4.19.124, v4.14.181,
v4.9.224, v4.4.224.
v5.6.14: Failed to
Hi
[This is an automated email]
This commit has been processed because it contains a -stable tag.
The stable tag indicates that it's relevant for the following trees: all
The bot has tested the following trees: v5.6.14, v5.4.42, v4.19.124, v4.14.181,
v4.9.224, v4.4.224.
v5.6.14: Failed to
On Wed, May 20, 2020 at 05:31:28PM -0300, Arnaldo Carvalho de Melo wrote:
> Em Sun, May 10, 2020 at 11:06:09PM +0800, Changbin Du escreveu:
> > The perf has basic kernel ftrace support but lack support of most tracing
> > options. This serias is target to enhance the perf ftrace functionality so
>
On 5/24/20 8:30 AM, Greg Kroah-Hartman wrote:
> Sometimes it is better to unregister individual nodes instead of trying
> to do them all at once with software_node_unregister_nodes(), so create
> software_node_unregister() so that you can unregister them one at a
> time.
>
> This is especially
On Mon, May 25, 2020 at 06:42:50PM -0500, Jeremy Linton wrote:
> Hi,
>
> On 5/25/20 6:33 PM, Russell King - ARM Linux admin wrote:
> > On Mon, May 25, 2020 at 06:22:19PM -0500, Jeremy Linton wrote:
> > > On 5/25/20 6:09 PM, Russell King - ARM Linux admin wrote:
> > > > On Mon, May 25, 2020 at
The mm-of-the-moment snapshot 2020-05-25-16-56 has been uploaded to
http://www.ozlabs.org/~akpm/mmotm/
mmotm-readme.txt says
README for mm-of-the-moment:
http://www.ozlabs.org/~akpm/mmotm/
This is a snapshot of my -mm patch queue. Uploaded at random hopefully
more than once a week.
You
This code was using get_user_pages*(), in a "Case 2" scenario
(DMA/RDMA), using the categorization from [1]. That means that it's
time to convert the get_user_pages*() + put_page() calls to
pin_user_pages*() + unpin_user_pages() calls.
There is some helpful background in [2]: basically, this is a
On Mon, May 25, 2020 at 06:46:10PM -0500, Jeremy Linton wrote:
> Hi,
>
>
> On 5/25/20 6:12 PM, Andrew Lunn wrote:
> > > arch/powerpc/boot/dts/fsl/t4240rdb.dts: compatible =
> > > "ethernet-phy-id13e5.1002";
> > > arch/powerpc/boot/dts/fsl/t4240rdb.dts: compatible =
> > >
> Right, which is what I sort of expected. Because its falling back to a
> device list of 0x, which means probe every single MMD.
>
> Combined with the lack of filtering means that your getting a bunch of MMD
> IDs that potentially are invalid, along with any that happen to be valid.
>
Hi,
On 5/25/20 6:12 PM, Andrew Lunn wrote:
arch/powerpc/boot/dts/fsl/t4240rdb.dts: compatible = "ethernet-phy-id13e5.1002";
arch/powerpc/boot/dts/fsl/t4240rdb.dts: compatible = "ethernet-phy-id13e5.1002";
arch/powerpc/boot/dts/fsl/t4240rdb.dts: compatible = "ethernet-phy-id13e5.1002";
Hi,
On 5/25/20 6:33 PM, Russell King - ARM Linux admin wrote:
On Mon, May 25, 2020 at 06:22:19PM -0500, Jeremy Linton wrote:
On 5/25/20 6:09 PM, Russell King - ARM Linux admin wrote:
On Mon, May 25, 2020 at 05:22:07PM -0500, Jeremy Linton wrote:
On 5/25/20 5:01 PM, Russell King - ARM Linux
On 5/8/20 1:29 PM, Gavin Shan wrote:
There are two stages of page faults and the stage one page fault is
handled by guest itself. The guest is trapped to host when the page
fault is caused by stage 2 page table, for example missing. The guest
is suspended until the requested page is populated.
On Sun, 24 May 2020 15:20:25 -0700, Nathan Chancellor said:
> arm-linux-gnueabi-ld: drivers/power/reset/vexpress-poweroff.o: in function
> `vexpress_reset_probe':
> vexpress-poweroff.c:(.text+0x36c): undefined reference to
> `devm_regmap_init_vexpress_config'
The part I can't figure out is
On Mon, May 25, 2020 at 06:22:19PM -0500, Jeremy Linton wrote:
> On 5/25/20 6:09 PM, Russell King - ARM Linux admin wrote:
> > On Mon, May 25, 2020 at 05:22:07PM -0500, Jeremy Linton wrote:
> > > On 5/25/20 5:01 PM, Russell King - ARM Linux admin wrote:
> > > > On Mon, May 25, 2020 at 04:51:16PM
This code was using get_user_pages*(), in a "Case 2" scenario
(DMA/RDMA), using the categorization from [1]. That means that it's
time to convert the get_user_pages*() + put_page() calls to
pin_user_pages*() + unpin_user_pages() calls.
There is some helpful background in [2]: basically, this is a
On Mon, May 25, 2020 at 3:01 PM Akira Yokosawa wrote:
>
> On Mon, 25 May 2020 11:31:27 -0700, Andrii Nakryiko wrote:
> > On Sun, May 24, 2020 at 5:09 AM Akira Yokosawa wrote:
> >>
> >> On Fri, 22 May 2020 12:38:21 -0700, Andrii Nakryiko wrote:
> >>> On 5/22/20 10:43 AM, Paul E. McKenney wrote:
>
On Mon, May 25, 2020 at 06:16:18PM -0500, Jeremy Linton wrote:
> Hi,
>
> On 5/25/20 5:01 PM, Russell King - ARM Linux admin wrote:
> > On Mon, May 25, 2020 at 04:51:16PM -0500, Jeremy Linton wrote:
> > > So, my goals here have been to first, not break anything, and then do a
> > > slightly better
[ Sorry, forgot to CC Kyungtae ]
On Mon, May 25, 2020 at 04:27:40PM -0700, Dmitry Torokhov wrote:
> When k_ascii is invoked several times in a row there is a potential for
> signed integer overflow:
>
> UBSAN: Undefined behaviour in drivers/tty/vt/keyboard.c:888:19 signed integer
> overflow:
>
When k_ascii is invoked several times in a row there is a potential for
signed integer overflow:
UBSAN: Undefined behaviour in drivers/tty/vt/keyboard.c:888:19 signed integer
overflow:
10 * 11 cannot be represented in type 'int'
CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.6.11 #1
On 5/25/20 6:09 PM, Russell King - ARM Linux admin wrote:
On Mon, May 25, 2020 at 05:22:07PM -0500, Jeremy Linton wrote:
On 5/25/20 5:01 PM, Russell King - ARM Linux admin wrote:
On Mon, May 25, 2020 at 04:51:16PM -0500, Jeremy Linton wrote:
Hi,
On 5/25/20 5:06 AM, Russell King - ARM Linux
Hi,
On 5/25/20 5:01 PM, Russell King - ARM Linux admin wrote:
On Mon, May 25, 2020 at 04:51:16PM -0500, Jeremy Linton wrote:
Hi,
On 5/25/20 5:06 AM, Russell King - ARM Linux admin wrote:
On Sun, May 24, 2020 at 10:34:13PM -0500, Jeremy Linton wrote:
Hi,
On 5/23/20 1:37 PM, Russell King -
On Mon, May 25, 2020 at 4:04 PM Chris Packham
wrote:
>
> Change 'excpetion' to 'exception', 'handeled' to 'handled' and 'the the'
> to 'the'.
>
> Signed-off-by: Chris Packham
> ---
> arch/xtensa/kernel/entry.S | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
Thanks, applied to my
> arch/powerpc/boot/dts/fsl/t4240rdb.dts: compatible =
> "ethernet-phy-id13e5.1002";
> arch/powerpc/boot/dts/fsl/t4240rdb.dts: compatible =
> "ethernet-phy-id13e5.1002";
> arch/powerpc/boot/dts/fsl/t4240rdb.dts: compatible =
> "ethernet-phy-id13e5.1002";
>
On Mon, May 25, 2020 at 05:22:07PM -0500, Jeremy Linton wrote:
> On 5/25/20 5:01 PM, Russell King - ARM Linux admin wrote:
> > On Mon, May 25, 2020 at 04:51:16PM -0500, Jeremy Linton wrote:
> > > Hi,
> > >
> > > On 5/25/20 5:06 AM, Russell King - ARM Linux admin wrote:
> > > > On Sun, May 24,
On Thu, May 21, 2020 at 08:05:53PM -0700, Matthew Wilcox wrote:
> On Fri, May 22, 2020 at 12:57:51PM +1000, Dave Chinner wrote:
> > On Thu, May 21, 2020 at 05:04:11PM -0700, Matthew Wilcox wrote:
> > > On Fri, May 22, 2020 at 08:49:06AM +1000, Dave Chinner wrote:
> > > > Ok, so the main issue I
On Mon, May 25, 2020 at 05:17:27PM -0500, Jeremy Linton wrote:
> Hi,
>
> On 5/25/20 5:06 PM, Andrew Lunn wrote:
> > > Yes, we know even for the NXP reference hardware, one of the phy's doesn't
> > > probe out correctly because it doesn't respond to the ieee defined
> > > registers. I think at
> I know for sure we find phys that previously weren't found.
That is in itself somewhat dangerous. Those using primitive
configuration systems are probably going to use phy_find_first(),
rather than an address on the bus. I always recommend against that,
because if another PHY suddenly pops up
Change 'excpetion' to 'exception', 'handeled' to 'handled' and 'the the'
to 'the'.
Signed-off-by: Chris Packham
---
arch/xtensa/kernel/entry.S | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/xtensa/kernel/entry.S b/arch/xtensa/kernel/entry.S
index
Change 'unhandeled' to 'unhandled'.
Signed-off-by: Chris Packham
---
drivers/hid/hid-logitech-dj.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/hid/hid-logitech-dj.c b/drivers/hid/hid-logitech-dj.c
index ed9b1c1f460d..51e1305cc375 100644
---
Change 'handeled' to 'handled'.
Signed-off-by: Chris Packham
---
kernel/bpf/core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/bpf/core.c b/kernel/bpf/core.c
index 916f5132a984..1ff8e73e9b12 100644
--- a/kernel/bpf/core.c
+++ b/kernel/bpf/core.c
@@ -1543,7 +1543,7
The compressed kernel currently contains bogus runtime relocations in
the startup code in head_{32,64}.S, which are generated by the linker,
but must not actually be processed at runtime.
This generates warnings when linking with the BFD linker, and errors
with LLD, which defaults to erroring on
gcc puts the main function into .text.startup when compiled with -Os (or
-O2). This results in arch/x86/boot/main.c having a .text.startup
section which is currently not included explicitly in the linker script
setup.ld in the same directory.
The BFD linker places this orphan section immediately
The BFD linker generates runtime relocations for z_input_len and
z_output_len, even though they are absolute symbols.
This is fixed for binutils-2.35 [1]. Work around this for earlier
versions by defining two variables input_len and output_len in addition
to the symbols, and use them via
The assembly code in head_{32,64}.S, while meant to be
position-independent, generates run-time relocations because it uses
instructions such as
lealgdt(%edx), %eax
which make the assembler and linker think that the code is using %edx as
an index into gdt, and hence gdt needs to be
Add a linker script check that there are no runtime relocations, and
remove the old one that tries to check via looking for specially-named
sections in the object files.
Drop the tests for -fPIE compiler option and -pie linker option, as they
are available in all supported gcc and binutils
On Tue, May 26, 2020 at 10:55:59AM +1200, Chris Packham wrote:
> Change 'handeled' to 'handled' in the Kconfig help for SCTP.
>
> Signed-off-by: Chris Packham
Acked-by: Marcelo Ricardo Leitner
Change 'handeled' to 'handled' in the Kconfig help for SCTP.
Signed-off-by: Chris Packham
---
net/sctp/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/sctp/Kconfig b/net/sctp/Kconfig
index 6e2eb1dd64ed..68934438ee19 100644
--- a/net/sctp/Kconfig
+++
On Mon, May 25, 2020 at 09:15:07AM +0200, Greg KH wrote:
> On Sun, May 24, 2020 at 05:08:23PM -0700, Dmitry Torokhov wrote:
> > On Sat, May 23, 2020 at 11:09:35PM +, Kyungtae Kim wrote:
> > > @@ -884,8 +884,11 @@ static void k_ascii(struct vc_data *vc, unsigned
> > > char value, char up_flag)
On Sun, May 24, 2020 at 8:34 AM Greg Kroah-Hartman
wrote:
>
> It is possible for a KOBJ_REMOVE uevent to be sent to userspace way
> after the files are actually gone from sysfs, due to how reference
> counting for kobjects work. This should not be a problem, but it would
> be good to properly
On Mon, May 25, 2020 at 05:09:56PM -0500, Jeremy Linton wrote:
> Hi,
>
> On 5/25/20 3:25 AM, Russell King - ARM Linux admin wrote:
> > On Sun, May 24, 2020 at 11:28:52PM -0500, Jeremy Linton wrote:
> > > Hi,
> > >
> > > On 5/24/20 9:44 AM, Andrew Lunn wrote:
> > > > > +++ b/include/linux/phy.h
>
On Mon, 25 May 2020 21:57:41 + Wei Yang wrote:
> I see the patch just merged, so I suppose to add the above test code into that
> one?
Well, that's not really test code.
But yes, something which tests both the 32-bit and 64-bit functions would be
nice, sometime.
-
Björn, please pick this minor non-urgent patch.
applies to next-20200525 on top of the commits mentioned above
Thanks Lukas!
Daniel/Alexei, this should go to the bpf-next tree.
Yep, applied, thanks!
On 5/25/20 5:01 PM, Russell King - ARM Linux admin wrote:
On Mon, May 25, 2020 at 04:51:16PM -0500, Jeremy Linton wrote:
Hi,
On 5/25/20 5:06 AM, Russell King - ARM Linux admin wrote:
On Sun, May 24, 2020 at 10:34:13PM -0500, Jeremy Linton wrote:
Hi,
On 5/23/20 1:37 PM, Russell King - ARM
On Wed, Mar 25, 2020 at 12:29 PM Asutosh Das wrote:
>
> Currently, the frequency that devfreq provides the
> driver to set always leads the clocks to be scaled up.
> Hence, round the clock-rate to the nearest frequency
> before deciding to scale.
>
> Also update the devfreq statistics of current
On Thu, 21 May 2020 17:22:38 +0200 Christoph Hellwig wrote:
> this series start cleaning up the safe kernel and user memory probing
> helpers in mm/maccess.c, and then allows architectures to implement
> the kernel probing without overriding the address space limit and
> temporarily allowing
Hi John,
On Mon, 25 May 2020 11:18:46 -0700 John Hubbard wrote:
>
> Yes, looks good. And in fact, Andrew has the same fix-up in the mmotm branch
> of
> linux-next.git, as
>
> commit a76c281a8ddd
> ("mmap-locking-api-rename-mmap_sem-to-mmap_lock-fix").
For some reason that was not
This code was using get_user_pages_fast(), in a "Case 2" scenario
(DMA/RDMA), using the categorization from [1]. That means that it's
time to convert the get_user_pages_fast() + put_page() calls to
pin_user_pages_fast() + unpin_user_pages() calls.
There is some helpful background in [2]:
Signed-off-by: Andra Paraschiv
---
Changelog
v2 -> v3
* Update file entries to be in alphabetical order.
v1 -> v2
* No changes.
---
MAINTAINERS | 13 +
1 file changed, 13 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 50659d76976b..56d529256ba4 100644
---
Signed-off-by: Alexandru Vasile
Signed-off-by: Andra Paraschiv
---
Changelog
v2 -> v3
* Remove the include directory to use the uapi from the kernel.
* Remove the GPL additional wording as SPDX-License-Identifier is already in
place.
v1 -> v2
* New in v2.
---
Hi,
On 5/25/20 5:06 PM, Andrew Lunn wrote:
Yes, we know even for the NXP reference hardware, one of the phy's doesn't
probe out correctly because it doesn't respond to the ieee defined
registers. I think at this point, there really isn't anything we can do
about that unless we involve the
Signed-off-by: Andra Paraschiv
---
Changelog
v2 -> v3
* No changes.
v1 -> v2
* New in v2.
---
Documentation/nitro_enclaves/ne_overview.txt | 86
1 file changed, 86 insertions(+)
create mode 100644 Documentation/nitro_enclaves/ne_overview.txt
diff --git
After all the enclave resources are set, the enclave is ready for
beginning to run.
Add ioctl command logic for starting an enclave after all its resources,
memory regions and CPUs, have been set.
The enclave start information includes the local channel addressing -
vsock CID - and the flags
Signed-off-by: Andra Paraschiv
---
Changelog
v2 -> v3
* Remove the GPL additional wording as SPDX-License-Identifier is already in
place.
v1 -> v2
* Update path to Makefile to match the drivers/virt/nitro_enclaves directory.
---
drivers/virt/Makefile| 2 ++
Another resource that is being set for an enclave is memory. User space
memory regions, that need to be backed by contiguous memory regions,
are associated with the enclave.
One solution for allocating / reserving contiguous memory regions, that
is used for integration, is hugetlbfs. The user
flush_icache_user_range definition for xtensa is placed under
preprocessor condition that is not processed in noMMU configurations,
resulting in the following build errors:
fs/exec.c:1065:3: error: implicit declaration of function
‘flush_icache_user_range’
fs/binfmt_flat.c:857:2: error:
An enclave is associated with an fd that is returned after the enclave
creation logic is completed. This enclave fd is further used to setup
enclave resources. Once the enclave needs to be terminated, the enclave
fd is closed.
Add logic for enclave termination, that is mapped to the enclave fd
Signed-off-by: Andra Paraschiv
---
Changelog
v2 -> v3
* Remove the GPL additional wording as SPDX-License-Identifier is already in
place.
v1 -> v2
* Update path to Kconfig to match the drivers/virt/nitro_enclaves directory.
* Update help in Kconfig.
---
drivers/virt/Kconfig|
Before setting the memory regions for the enclave, the enclave image
needs to be placed in memory. After the memory regions are set, this
memory cannot be used anymore by the VM, being carved out.
Add ioctl command logic to get the offset in enclave memory where to
place the enclave image. Then
An enclave, before being started, has its resources set. One of its
resources is CPU.
Add ioctl command logic for enclave vCPU creation. Return as result a
file descriptor that is associated with the enclave vCPU.
Signed-off-by: Alexandru Vasile
Signed-off-by: Andra Paraschiv
---
Changelog
v2
Add ioctl command logic for enclave VM creation. It triggers a slot
allocation. The enclave resources will be associated with this slot and
it will be used as an identifier for triggering enclave run.
Return a file descriptor, namely enclave fd. This is further used by the
associated user space
The Nitro Enclaves PCI device exposes a MMIO space that this driver
uses to submit command requests and to receive command replies e.g. for
enclave creation / termination or setting enclave resources.
Add logic for handling PCI device command requests based on the given
command type.
Register an
The Nitro Enclaves driver provides an ioctl interface to the user space
for enclave lifetime management e.g. enclave creation / termination and
setting enclave resources such as memory and CPU.
This ioctl interface is mapped to a Nitro Enclaves misc device.
Signed-off-by: Andra Paraschiv
---
In addition to the replies sent by the Nitro Enclaves PCI device in
response to command requests, out-of-band enclave events can happen e.g.
an enclave crashes. In this case, the Nitro Enclaves driver needs to be
aware of the event and notify the corresponding user space process that
abstracts the
The Nitro Enclaves (NE) driver communicates with a new PCI device, that
is exposed to a virtual machine (VM) and handles commands meant for
handling enclaves lifetime e.g. creation, termination, setting memory
regions. The communication with the PCI device is handled using a MMIO
space and MSI-X
The Nitro Enclaves PCI device is used by the kernel driver as a means of
communication with the hypervisor on the host where the primary VM and
the enclaves run. It handles requests with regard to enclave lifetime.
Setup the PCI device driver and add support for MSI-X interrupts.
Signed-off-by:
Nitro Enclaves (NE) is a new Amazon Elastic Compute Cloud (EC2) capability
that allows customers to carve out isolated compute environments within EC2
instances [1].
For example, an application that processes sensitive data and runs in a VM,
can be separated from other applications running in the
The Nitro Enclaves driver handles the enclave lifetime management. This
includes enclave creation, termination and setting up its resources such
as memory and CPU.
An enclave runs alongside the VM that spawned it. It is abstracted as a
process running in the VM that launched it. The process
The Nitro Enclaves driver keeps an internal info per each enclave.
This is needed to be able to manage enclave resources state, enclave
notifications and have a reference of the PCI device that handles
command requests for enclave lifetime management.
Signed-off-by: Alexandru-Catalin Vasile
Hi,
On 5/25/20 3:25 AM, Russell King - ARM Linux admin wrote:
On Sun, May 24, 2020 at 11:28:52PM -0500, Jeremy Linton wrote:
Hi,
On 5/24/20 9:44 AM, Andrew Lunn wrote:
+++ b/include/linux/phy.h
@@ -275,6 +275,11 @@ struct mii_bus {
int reset_delay_us;
/* RESET GPIO descriptor
> Yes, we know even for the NXP reference hardware, one of the phy's doesn't
> probe out correctly because it doesn't respond to the ieee defined
> registers. I think at this point, there really isn't anything we can do
> about that unless we involve the (ACPI) firmware in currently nonstandard
>
On Mon, May 25, 2020 at 04:51:16PM -0500, Jeremy Linton wrote:
> Hi,
>
> On 5/25/20 5:06 AM, Russell King - ARM Linux admin wrote:
> > On Sun, May 24, 2020 at 10:34:13PM -0500, Jeremy Linton wrote:
> > > Hi,
> > >
> > > On 5/23/20 1:37 PM, Russell King - ARM Linux admin wrote:
> > > > On Fri,
On Mon, 25 May 2020 11:31:27 -0700, Andrii Nakryiko wrote:
> On Sun, May 24, 2020 at 5:09 AM Akira Yokosawa wrote:
>>
>> On Fri, 22 May 2020 12:38:21 -0700, Andrii Nakryiko wrote:
>>> On 5/22/20 10:43 AM, Paul E. McKenney wrote:
On Fri, May 22, 2020 at 10:32:01AM -0400, Alan Stern wrote:
Hi all,
Commit
1fe411077207 ("Replace HTTP links with HTTPS ones: documentation")
is missing a Signed-off-by from its author.
--
Cheers,
Stephen Rothwell
pgpJrDTI9Knpg.pgp
Description: OpenPGP digital signature
These two functions share the same logic.
Signed-off-by: Wei Yang
---
include/linux/bitops.h | 8 +++-
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/include/linux/bitops.h b/include/linux/bitops.h
index 5b5609e81a84..80703ef27aee 100644
--- a/include/linux/bitops.h
+++
Hi!
> >This is the multi color LED framework. This framework presents clustered
> >colored LEDs into an array and allows the user space to adjust the brightness
> >of the cluster using a single file write. The individual colored LEDs
> >intensities are controlled via a single file that is an
Hi,
On 5/25/20 4:07 PM, Russell King - ARM Linux admin wrote:
On Mon, May 25, 2020 at 04:02:13PM -0500, Jeremy Linton wrote:
So, I think you're going to have to add a work-around to ignore bit 0,
which brings up the question whether this is worth it or not.
It does ignore bit 0, it gets
On Mon, May 25, 2020 at 01:41:10PM -0700, Andrew Morton wrote:
>On Mon, 25 May 2020 18:32:16 +0300 Andy Shevchenko
> wrote:
>
>> On Mon, May 25, 2020 at 02:43:12PM +, Wei Yang wrote:
>> > On Mon, May 25, 2020 at 12:14:58PM +0300, Andy Shevchenko wrote:
>> > >On Sun, May 24, 2020 at 12:35:51PM
pr_warn("** If you see this message and you are not debugging**\n");
>pr_warn("** the kernel, report this immediately to your vendor!
> **\n");
>pr_warn("**
> **\n");
>pr_warn("** NOTICE NOTICE NOTICE
On Fri, May 22, 2020 at 7:55 AM Adrian Reber wrote:
> This enables CRIU to checkpoint and restore a process as non-root.
>
> Over the last years CRIU upstream has been asked a couple of time if it
> is possible to checkpoint and restore a process as non-root. The answer
> usually was: 'almost'.
>
Hi,
On 5/25/20 5:06 AM, Russell King - ARM Linux admin wrote:
On Sun, May 24, 2020 at 10:34:13PM -0500, Jeremy Linton wrote:
Hi,
On 5/23/20 1:37 PM, Russell King - ARM Linux admin wrote:
On Fri, May 22, 2020 at 04:30:52PM -0500, Jeremy Linton wrote:
Until this point, we have been sanitizing
The struct hyperv_ir_domain_ops is not modified and can be made const to
allow the compiler to put it in read-only memory.
Before:
textdata bss dec hex filename
29161180112052161460 drivers/iommu/hyperv-iommu.o
After:
textdata bss dec hex
Constify some structs with function pointers to allow the compiler to
put them in read-only memory. There is not dependency between the
patches.
Rikard Falkeborn (2):
iommu/hyper-v: Constify hyperv_ir_domain_ops
iommu/sun50i: Constify sun50i_iommu_ops
drivers/iommu/hyperv-iommu.c | 2 +-
The struct sun50i_iommu_ops is not modified and can be made const to
allow the compiler to put it in read-only memory.
Before:
textdata bss dec hex filename
143582501 64 16923421b drivers/iommu/sun50i-iommu.o
After:
textdata bss dec hex
From: "Joel Fernandes (Google)"
kfree_rcu()'s debug_objects logic uses the address of the object's
embedded rcu_head to queue/unqueue. Instead of this, make use of the
object's address itself as preparation for future headless kfree_rcu()
support.
Reviewed-by: Uladzislau Rezki
Signed-off-by:
From: Sebastian Andrzej Siewior
The per-CPU variable is initialized at runtime in
kfree_rcu_batch_init(). This function is invoked before
'rcu_scheduler_active' is set to 'RCU_SCHEDULER_RUNNING'.
After the initialisation, '->initialized' is to true.
The raw_spin_lock is only acquired if
It is possible that one of the channels cannot be detached
because its free channel is busy and previously queued data
has not been processed yet. On the other hand, another
channel can be successfully detached causing the monitor
work to stop.
Prevent that by rescheduling the monitor work if
Rename kvfree_rcu() function to the kvfree_rcu_local() one.
The purpose is to prevent a conflict of two same function
declarations. The kvfree_rcu() will be globally visible
what would lead to a build error. No functional change.
Cc: linux...@kvack.org
Cc: r...@vger.kernel.org
Cc: Andrew Morton
In order to reduce the dynamic need for pages in kfree_rcu(),
pre-allocate a configurable number of pages per CPU and link
them in a list. When kfree_rcu() reclaims objects, the object's
container page is cached into a list instead of being released
to the low-level page allocator.
Such an
To do so, we use an array of kvfree_rcu_bulk_data structures.
It consists of two elements:
- index number 0 corresponds to slab pointers.
- index number 1 corresponds to vmalloc pointers.
Keeping vmalloc pointers separated from slab pointers makes
it possible to invoke the right freeing API for
Update the kvfree_call_rcu() function with head-less support.
This allows RCU to reclaim objects without an embedded rcu_head.
tree-RCU:
We introduce two chains of arrays to store SLAB-backed and vmalloc
pointers, each. Storage in either of these arrays does not require
embedding an rcu_head
We can simplify KFREE_BULK_MAX_ENTR macro and get rid of
magic numbers which were used to make the structure to be
exactly one page.
Suggested-by: Boqun Feng
Reviewed-by: Joel Fernandes (Google)
Signed-off-by: Uladzislau Rezki (Sony)
Signed-off-by: Joel Fernandes (Google)
---
The following changes are introduced:
1. Rename rcu_invoke_kfree_callback() to rcu_invoke_kvfree_callback(),
as well as the associated trace events, so the rcu_kfree_callback(),
becomes rcu_kvfree_callback(). The reason is to be aligned with kvfree()
notation.
2. Rename __is_kfree_rcu_offset to
Introduce helpers to lock and unlock per-cpu "kfree_rcu_cpu"
structures. That will make kfree_call_rcu() more readable
and prevent programming errors.
Reviewed-by: Joel Fernandes (Google)
Signed-off-by: Uladzislau Rezki (Sony)
---
kernel/rcu/tree.c | 31 +++
1 file
This is a v2 of the https://lkml.org/lkml/2020/4/28/1626 series.
Please have look at v1 to find out more about motivation and details.
It is based on the latest dev.2020.05.17a Paul's branch.
Short changelog (v1 -> v2):
- Combine some patches, thus reduce the overall number;
- Switch one
Replace kfree() with kvfree() in rcu_reclaim_tiny().
This makes it possible to release either SLAB or vmalloc
objects after a GP.
Reviewed-by: Joel Fernandes (Google)
Signed-off-by: Uladzislau Rezki (Sony)
---
kernel/rcu/tiny.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff
101 - 200 of 995 matches
Mail list logo