On 8 September 2018 2:40:21 AM IST, Greg Kroah-Hartman
wrote:
>This is the start of the stable review cycle for the 3.18.122 release.
>There are 29 patches in this series, all will be posted as a response
>to this one. If anyone has any issues with these being applied, please
>let me know.
>
On 8 September 2018 2:40:21 AM IST, Greg Kroah-Hartman
wrote:
>This is the start of the stable review cycle for the 3.18.122 release.
>There are 29 patches in this series, all will be posted as a response
>to this one. If anyone has any issues with these being applied, please
>let me know.
>
On Tue 04 Sep 04:01 PDT 2018, Baolin Wang wrote:
> diff --git a/Documentation/ABI/testing/sysfs-class-led-trigger-pattern
> b/Documentation/ABI/testing/sysfs-class-led-trigger-pattern
[..]
> +What:/sys/class/leds//hw_pattern
> +Date:September 2018
>
On Tue 04 Sep 04:01 PDT 2018, Baolin Wang wrote:
> diff --git a/Documentation/ABI/testing/sysfs-class-led-trigger-pattern
> b/Documentation/ABI/testing/sysfs-class-led-trigger-pattern
[..]
> +What:/sys/class/leds//hw_pattern
> +Date:September 2018
>
If BUG_ON() is used instead of BUG(), it means that probably the
preferred outcome is to not BUG(), therefore the condition tested should
be unlikely().
However, when CONFIG_PROFILE_ANNOTATED_BRANCHES is enabled, the hint is
disabled, to avoid generating false-positive warnings caused by
If BUG_ON() is used instead of BUG(), it means that probably the
preferred outcome is to not BUG(), therefore the condition tested should
be unlikely().
However, when CONFIG_PROFILE_ANNOTATED_BRANCHES is enabled, the hint is
disabled, to avoid generating false-positive warnings caused by
On Fri, Sep 7, 2018 at 9:40 AM, Josh Poimboeuf wrote:
> On Mon, Sep 03, 2018 at 03:59:44PM -0700, Andy Lutomirski wrote:
>> The SYSCALL64 trampoline has a couple of nice properties:
>>
>> - The usual sequence of SWAPGS followed by two GS-relative accesses to
>>set up RSP is somewhat slow
On Fri, Sep 7, 2018 at 9:40 AM, Josh Poimboeuf wrote:
> On Mon, Sep 03, 2018 at 03:59:44PM -0700, Andy Lutomirski wrote:
>> The SYSCALL64 trampoline has a couple of nice properties:
>>
>> - The usual sequence of SWAPGS followed by two GS-relative accesses to
>>set up RSP is somewhat slow
On Fri, Sep 7, 2018 at 5:04 PM, Linus Torvalds
wrote:
> On Fri, Sep 7, 2018 at 12:54 PM Thomas Gleixner wrote:
>>
>> > - We execute from an extra page and read from another extra page
>> > during the syscall. (The latter is because we need to use a relative
>> > addressing mode to find sp1 --
On Fri, Sep 7, 2018 at 5:04 PM, Linus Torvalds
wrote:
> On Fri, Sep 7, 2018 at 12:54 PM Thomas Gleixner wrote:
>>
>> > - We execute from an extra page and read from another extra page
>> > during the syscall. (The latter is because we need to use a relative
>> > addressing mode to find sp1 --
On 07/09/18 23:41, Arnd Bergmann wrote:
Could you add a comment about -Wmaybe-uninitialized next to the definition?
Otherwise that is easily lost.
Also, I see that the file has two separate definitions of BUG_ON(), and the
other one does have an unlikely() in it already. Can you change both
On 07/09/18 23:41, Arnd Bergmann wrote:
Could you add a comment about -Wmaybe-uninitialized next to the definition?
Otherwise that is easily lost.
Also, I see that the file has two separate definitions of BUG_ON(), and the
other one does have an unlikely() in it already. Can you change both
On 9/4/18 2:28 PM, Daniel Jordan wrote:
> Pavel Tatashin, Ying Huang, and I are excited to be organizing a performance
> and scalability microconference this year at Plumbers[*], which is happening
> in Vancouver this year. The microconference is scheduled for the morning of
> the second day
On 9/4/18 2:28 PM, Daniel Jordan wrote:
> Pavel Tatashin, Ying Huang, and I are excited to be organizing a performance
> and scalability microconference this year at Plumbers[*], which is happening
> in Vancouver this year. The microconference is scheduled for the morning of
> the second day
On Fri, 7 Sep 2018 14:50:59 +0200
Peter Oberparleiter wrote:
> On 06.09.2018 18:42, Masami Hiramatsu wrote:
> > Peter Oberparleiter wrote:
> >> I've attached a quick fix that should address both problems. I'd
> >> appreciate if this patch could get some testing before I post proper fix
> >>
On Fri, 7 Sep 2018 14:50:59 +0200
Peter Oberparleiter wrote:
> On 06.09.2018 18:42, Masami Hiramatsu wrote:
> > Peter Oberparleiter wrote:
> >> I've attached a quick fix that should address both problems. I'd
> >> appreciate if this patch could get some testing before I post proper fix
> >>
On Fri, Sep 07, 2018 at 04:13:35PM +0200, Arnd Bergmann wrote:
> On Fri, Sep 7, 2018 at 2:55 PM Guo Ren wrote:
> >
> > On Fri, Sep 07, 2018 at 10:14:38AM +0200, Arnd Bergmann wrote:
> > > On Fri, Sep 7, 2018 at 5:04 AM Guo Ren wrote:
> > > > On Thu, Sep 06, 2018 at 04:31:16PM +0200, Arnd
On Fri, Sep 07, 2018 at 04:13:35PM +0200, Arnd Bergmann wrote:
> On Fri, Sep 7, 2018 at 2:55 PM Guo Ren wrote:
> >
> > On Fri, Sep 07, 2018 at 10:14:38AM +0200, Arnd Bergmann wrote:
> > > On Fri, Sep 7, 2018 at 5:04 AM Guo Ren wrote:
> > > > On Thu, Sep 06, 2018 at 04:31:16PM +0200, Arnd
From: Long Li
With offset defined in rdata, transport functions need to look at this
offset when reading data into the correct places in pages.
Signed-off-by: Long Li
---
fs/cifs/cifsproto.h | 4 +++-
fs/cifs/cifssmb.c | 1 +
fs/cifs/connect.c | 5 +++--
fs/cifs/file.c | 52
From: Long Li
With offset defined in rdata, transport functions need to look at this
offset when reading data into the correct places in pages.
Signed-off-by: Long Li
---
fs/cifs/cifsproto.h | 4 +++-
fs/cifs/cifssmb.c | 1 +
fs/cifs/connect.c | 5 +++--
fs/cifs/file.c | 52
From: Long Li
It's possible that the page offset is non-zero in the pages in a request,
change the function to calculate the correct data buffer length.
Signed-off-by: Long Li
---
fs/cifs/transport.c | 20 +---
1 file changed, 17 insertions(+), 3 deletions(-)
diff --git
From: Long Li
Add a function to allocate wdata without allocating pages for data
transfer. This gives the caller an option to pass a number of pages that
point to the data buffer to write to.
wdata is reponsible for free those pages after it's done.
Signed-off-by: Long Li
---
From: Long Li
It's possible that the page offset is non-zero in the pages in a request,
change the function to calculate the correct data buffer length.
Signed-off-by: Long Li
---
fs/cifs/transport.c | 20 +---
1 file changed, 17 insertions(+), 3 deletions(-)
diff --git
From: Long Li
Add a function to allocate wdata without allocating pages for data
transfer. This gives the caller an option to pass a number of pages that
point to the data buffer to write to.
wdata is reponsible for free those pages after it's done.
Signed-off-by: Long Li
---
From: Long Li
With direct read/write functions implemented, add them to file_operations.
Dircet I/O is used under two conditions:
1. When mounting with "cache=none", CIFS uses direct I/O for all user file
data transfer.
2. When opening a file with O_DIRECT, CIFS uses direct I/O for all data
From: Long Li
With direct read/write functions implemented, add them to file_operations.
Dircet I/O is used under two conditions:
1. When mounting with "cache=none", CIFS uses direct I/O for all user file
data transfer.
2. When opening a file with O_DIRECT, CIFS uses direct I/O for all data
From: Long Li
With direct I/O read, we transfer the data directly from transport layer to
the user data buffer.
Change in v3: added support for kernel AIO
Signed-off-by: Long Li
---
fs/cifs/cifsfs.h | 1 +
fs/cifs/cifsglob.h | 5 ++
fs/cifs/file.c | 209
From: Long Li
When issuing SMB writes, pass along the write data page offset to transport.
Signed-off-by: Long Li
---
fs/cifs/cifssmb.c | 1 +
fs/cifs/smb2pdu.c | 1 +
2 files changed, 2 insertions(+)
diff --git a/fs/cifs/cifssmb.c b/fs/cifs/cifssmb.c
index 503e0ed..0a57c61 100644
---
From: Long Li
The RDMA send function needs to look at offset in the request pages, and
send data starting from there.
Signed-off-by: Long Li
---
fs/cifs/smbdirect.c | 27 +++
1 file changed, 19 insertions(+), 8 deletions(-)
diff --git a/fs/cifs/smbdirect.c
From: Long Li
When issuing SMB writes, pass along the write data page offset to transport.
Signed-off-by: Long Li
---
fs/cifs/cifssmb.c | 1 +
fs/cifs/smb2pdu.c | 1 +
2 files changed, 2 insertions(+)
diff --git a/fs/cifs/cifssmb.c b/fs/cifs/cifssmb.c
index 503e0ed..0a57c61 100644
---
From: Long Li
The RDMA send function needs to look at offset in the request pages, and
send data starting from there.
Signed-off-by: Long Li
---
fs/cifs/smbdirect.c | 27 +++
1 file changed, 19 insertions(+), 8 deletions(-)
diff --git a/fs/cifs/smbdirect.c
From: Long Li
With direct I/O read, we transfer the data directly from transport layer to
the user data buffer.
Change in v3: added support for kernel AIO
Signed-off-by: Long Li
---
fs/cifs/cifsfs.h | 1 +
fs/cifs/cifsglob.h | 5 ++
fs/cifs/file.c | 209
From: Long Li
When calculating signature for the packet, it needs to read into the
correct page offset for the data.
Signed-off-by: Long Li
---
fs/cifs/cifsencrypt.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/fs/cifs/cifsencrypt.c b/fs/cifs/cifsencrypt.c
From: Long Li
Encryption function needs to read data starting page offset from input
buffer.
This doesn't affect decryption path since it allocates its own page
buffers.
Signed-off-by: Long Li
---
fs/cifs/smb2ops.c | 20 +---
1 file changed, 13 insertions(+), 7 deletions(-)
From: Long Li
Add a function to allocate rdata without allocating pages for data
transfer. This gives the caller an option to pass a number of pages
that point to the data buffer.
rdata is reponsible for free those pages after it's done.
Signed-off-by: Long Li
---
fs/cifs/cifsglob.h | 3 +--
From: Long Li
RDMA recv function needs to place data to the correct place starting at
page offset.
Signed-off-by: Long Li
---
fs/cifs/smbdirect.c | 18 +++---
1 file changed, 11 insertions(+), 7 deletions(-)
diff --git a/fs/cifs/smbdirect.c b/fs/cifs/smbdirect.c
index
From: Long Li
It's possible that the offset is non-zero in the page to send, change the
function to pass this offset to socket.
Signed-off-by: Long Li
---
fs/cifs/transport.c | 14 ++
1 file changed, 6 insertions(+), 8 deletions(-)
diff --git a/fs/cifs/transport.c
From: Long Li
It is not necessary to deregister a memory registration after it has been
successfully invalidated.
Signed-off-by: Long Li
---
fs/cifs/smbdirect.c | 82 ++---
1 file changed, 41 insertions(+), 41 deletions(-)
diff --git
From: Long Li
Introduce a function rqst_page_get_length to return the page offset and
length for a given page in smb_rqst. This function is to be used by
following patches.
Signed-off-by: Long Li
---
fs/cifs/cifsproto.h | 3 +++
fs/cifs/misc.c | 17 +
2 files changed, 20
From: Long Li
This patch set implements direct I/O.
In normal code path (even with cache=none), CIFS copies I/O data from
user-space to kernel-space for security reasons of possible protocol
required signing and encryption on user data.
With this patch set, CIFS passes the I/O data directly
From: Long Li
Change code to pass the correct page offset during memory registration for
RDMA read/write.
Signed-off-by: Long Li
---
fs/cifs/smb2pdu.c | 18 --
fs/cifs/smbdirect.c | 29 +
fs/cifs/smbdirect.h | 2 +-
3 files changed, 34
From: Long Li
When calculating signature for the packet, it needs to read into the
correct page offset for the data.
Signed-off-by: Long Li
---
fs/cifs/cifsencrypt.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/fs/cifs/cifsencrypt.c b/fs/cifs/cifsencrypt.c
From: Long Li
Encryption function needs to read data starting page offset from input
buffer.
This doesn't affect decryption path since it allocates its own page
buffers.
Signed-off-by: Long Li
---
fs/cifs/smb2ops.c | 20 +---
1 file changed, 13 insertions(+), 7 deletions(-)
From: Long Li
Add a function to allocate rdata without allocating pages for data
transfer. This gives the caller an option to pass a number of pages
that point to the data buffer.
rdata is reponsible for free those pages after it's done.
Signed-off-by: Long Li
---
fs/cifs/cifsglob.h | 3 +--
From: Long Li
RDMA recv function needs to place data to the correct place starting at
page offset.
Signed-off-by: Long Li
---
fs/cifs/smbdirect.c | 18 +++---
1 file changed, 11 insertions(+), 7 deletions(-)
diff --git a/fs/cifs/smbdirect.c b/fs/cifs/smbdirect.c
index
From: Long Li
It's possible that the offset is non-zero in the page to send, change the
function to pass this offset to socket.
Signed-off-by: Long Li
---
fs/cifs/transport.c | 14 ++
1 file changed, 6 insertions(+), 8 deletions(-)
diff --git a/fs/cifs/transport.c
From: Long Li
It is not necessary to deregister a memory registration after it has been
successfully invalidated.
Signed-off-by: Long Li
---
fs/cifs/smbdirect.c | 82 ++---
1 file changed, 41 insertions(+), 41 deletions(-)
diff --git
From: Long Li
Introduce a function rqst_page_get_length to return the page offset and
length for a given page in smb_rqst. This function is to be used by
following patches.
Signed-off-by: Long Li
---
fs/cifs/cifsproto.h | 3 +++
fs/cifs/misc.c | 17 +
2 files changed, 20
From: Long Li
This patch set implements direct I/O.
In normal code path (even with cache=none), CIFS copies I/O data from
user-space to kernel-space for security reasons of possible protocol
required signing and encryption on user data.
With this patch set, CIFS passes the I/O data directly
From: Long Li
Change code to pass the correct page offset during memory registration for
RDMA read/write.
Signed-off-by: Long Li
---
fs/cifs/smb2pdu.c | 18 --
fs/cifs/smbdirect.c | 29 +
fs/cifs/smbdirect.h | 2 +-
3 files changed, 34
From: Long Li
With direct I/O write, user supplied buffers are pinned to the memory and data
are transferred directly from user buffers to the transport layer.
Change in v3: added support for kernel AIO
Signed-off-by: Long Li
---
fs/cifs/cifsfs.h | 1 +
fs/cifs/file.c | 195
From: Long Li
With direct I/O write, user supplied buffers are pinned to the memory and data
are transferred directly from user buffers to the transport layer.
Change in v3: added support for kernel AIO
Signed-off-by: Long Li
---
fs/cifs/cifsfs.h | 1 +
fs/cifs/file.c | 195
On Fri, Sep 07, 2018 at 10:13:13AM -0500, Rob Herring wrote:
> On Thu, Sep 6, 2018 at 8:05 AM Arnd Bergmann wrote:
> >
> > On Thu, Sep 6, 2018 at 4:13 AM Guo Ren wrote:
> > >
> > > On Wed, Sep 05, 2018 at 07:43:10PM -0500, Rob Herring wrote:
> > > > On Wed, Sep 5, 2018 at 7:10 AM Guo Ren wrote:
On Fri, Sep 07, 2018 at 10:13:13AM -0500, Rob Herring wrote:
> On Thu, Sep 6, 2018 at 8:05 AM Arnd Bergmann wrote:
> >
> > On Thu, Sep 6, 2018 at 4:13 AM Guo Ren wrote:
> > >
> > > On Wed, Sep 05, 2018 at 07:43:10PM -0500, Rob Herring wrote:
> > > > On Wed, Sep 5, 2018 at 7:10 AM Guo Ren wrote:
On Fri, Sep 07, 2018 at 10:51:15AM +0200, Benjamin Tissoires wrote:
> From: Benjamin Tissoires
>
> Prior to commit 190d7f02ce8e ("HID: input: do not increment usages when
> a duplicate is found") from the v4.18 kernel, HID used to shift the
> event codes if a duplicate usage was found. This
On Fri, Sep 07, 2018 at 10:51:15AM +0200, Benjamin Tissoires wrote:
> From: Benjamin Tissoires
>
> Prior to commit 190d7f02ce8e ("HID: input: do not increment usages when
> a duplicate is found") from the v4.18 kernel, HID used to shift the
> event codes if a duplicate usage was found. This
On Saturday, September 8, 2018 4:05 AM, Andi Kleen wrote:
> > How would you realize the function of saving/restoring the lbr stack on the
> host?
> >
> > Here, we create a perf event on the host (please see
> guest_lbr_event_create on patch 7), which essentially satisfies all the
> conditions
On Saturday, September 8, 2018 4:05 AM, Andi Kleen wrote:
> > How would you realize the function of saving/restoring the lbr stack on the
> host?
> >
> > Here, we create a perf event on the host (please see
> guest_lbr_event_create on patch 7), which essentially satisfies all the
> conditions
On Sat, Sep 8, 2018 at 2:28 AM Dave Hansen wrote:
> The vsyscall page is weird. It is in what is traditionally part of the
> kernel address space. But, it has user permissions and we handle faults
> on it like we would on a user page: interrupts on.
>
> Right now, we handle vsyscall emulation
On Sat, Sep 8, 2018 at 2:28 AM Dave Hansen wrote:
> The vsyscall page is weird. It is in what is traditionally part of the
> kernel address space. But, it has user permissions and we handle faults
> on it like we would on a user page: interrupts on.
>
> Right now, we handle vsyscall emulation
On Sat, Sep 8, 2018 at 2:25 AM Dave Hansen wrote:
> We will shortly be using this check in two locations. Put it in
> a helper before we do so.
[...]
> +/*
> + * The (legacy) vsyscall page is the long page in the kernel portion
> + * of the address space that has user-accessible permissions.
> +
On Sat, Sep 8, 2018 at 2:25 AM Dave Hansen wrote:
> We will shortly be using this check in two locations. Put it in
> a helper before we do so.
[...]
> +/*
> + * The (legacy) vsyscall page is the long page in the kernel portion
> + * of the address space that has user-accessible permissions.
> +
On Sat, Sep 8, 2018 at 2:22 AM Dave Hansen wrote:
> +* Kernel-mode access to the user address space should only occur
> +* inside well-defined areas of code listed in the exception
Actually, not areas, but single whitelisted instructions. It would
probably be nice to say that
On Sat, Sep 8, 2018 at 2:22 AM Dave Hansen wrote:
> +* Kernel-mode access to the user address space should only occur
> +* inside well-defined areas of code listed in the exception
Actually, not areas, but single whitelisted instructions. It would
probably be nice to say that
On 9/7/2018 10:38 AM, Alan Stern wrote:
> On Fri, 7 Sep 2018, Daniel Lustig wrote:
>
>> On 9/7/2018 9:09 AM, Will Deacon wrote:
>>> On Fri, Sep 07, 2018 at 12:00:19PM -0400, Alan Stern wrote:
On Thu, 6 Sep 2018, Andrea Parri wrote:
>> Have you noticed any part of the generic code
On 9/7/2018 10:38 AM, Alan Stern wrote:
> On Fri, 7 Sep 2018, Daniel Lustig wrote:
>
>> On 9/7/2018 9:09 AM, Will Deacon wrote:
>>> On Fri, Sep 07, 2018 at 12:00:19PM -0400, Alan Stern wrote:
On Thu, 6 Sep 2018, Andrea Parri wrote:
>> Have you noticed any part of the generic code
On Fri, Sep 7, 2018 at 12:54 PM Thomas Gleixner wrote:
>
> > - We execute from an extra page and read from another extra page
> > during the syscall. (The latter is because we need to use a relative
> > addressing mode to find sp1 -- it's the same *cacheline* we'd use
> > anyway, but we're
On Fri, Sep 7, 2018 at 12:54 PM Thomas Gleixner wrote:
>
> > - We execute from an extra page and read from another extra page
> > during the syscall. (The latter is because we need to use a relative
> > addressing mode to find sp1 -- it's the same *cacheline* we'd use
> > anyway, but we're
On 09/07/2018 09:37 AM, John Johansen wrote:
> hey Tony,
>
> thanks for the patch, I am curious did you're investigation look
> into what parts of DEFINE_AUDIT_SK are causing the issue?
Hi JJ.
Attached are the perf annotations for DEFINE_AUDIT_SK (percentages are relative
to the fn).
Our
On 09/07/2018 09:37 AM, John Johansen wrote:
> hey Tony,
>
> thanks for the patch, I am curious did you're investigation look
> into what parts of DEFINE_AUDIT_SK are causing the issue?
Hi JJ.
Attached are the perf annotations for DEFINE_AUDIT_SK (percentages are relative
to the fn).
Our
On Fri, Sep 07, 2018 at 10:07:39PM +, Max Asbock wrote:
> At boot time the acpi_power_meter driver greets users of non-IBM systems with
> the message:
>
> "Ignoring unsafe software power cap".
>
> This message is generally interpreted as meaning: The system is
> operating under an
On Fri, Sep 07, 2018 at 10:07:39PM +, Max Asbock wrote:
> At boot time the acpi_power_meter driver greets users of non-IBM systems with
> the message:
>
> "Ignoring unsafe software power cap".
>
> This message is generally interpreted as meaning: The system is
> operating under an
> On Sep 7, 2018, at 12:49 PM, Dave Hansen wrote:
>
>
> From: Dave Hansen
>
> The vsyscall page is weird. It is in what is traditionally part of the
> kernel address space. But, it has user permissions and we handle faults
> on it like we would on a user page: interrupts on.
>
> Right
> On Sep 7, 2018, at 12:49 PM, Dave Hansen wrote:
>
>
> From: Dave Hansen
>
> The vsyscall page is weird. It is in what is traditionally part of the
> kernel address space. But, it has user permissions and we handle faults
> on it like we would on a user page: interrupts on.
>
> Right
Fix the cell specification mechanism to allow cells to be pre-created
without having to specify at least one address (the addresses will be
upcalled for).
This allows the cell information preload service to avoid the need to issue
loads of DNS lookups during boot to get the addresses for each
Fix the cell specification mechanism to allow cells to be pre-created
without having to specify at least one address (the addresses will be
upcalled for).
This allows the cell information preload service to avoid the need to issue
loads of DNS lookups during boot to get the addresses for each
I can see it in dev, thanks for merging. ;)
On 2018/9/8 6:38, Jaegeuk Kim wrote:
> I merged as one. Please check dev. :)
>
> On 09/06, Chao Yu wrote:
>> generic/019 reports below error:
>>
>> __quota_error: 1160 callbacks suppressed
>> Quota error (device zram1): write_blk: dquota write failed
I can see it in dev, thanks for merging. ;)
On 2018/9/8 6:38, Jaegeuk Kim wrote:
> I merged as one. Please check dev. :)
>
> On 09/06, Chao Yu wrote:
>> generic/019 reports below error:
>>
>> __quota_error: 1160 callbacks suppressed
>> Quota error (device zram1): write_blk: dquota write failed
On 09/07/2018 03:34 PM, jgka...@fb.com wrote:
> Here is the third version of the patchset.
>
> Changes since the last patchset:
> - Updated commit message of first patch to clarify fixes
> - Add ack from Roman
>
> There should be no code changes since the last patchset.
>
> Let me know if any
On 09/07/2018 03:34 PM, jgka...@fb.com wrote:
> Here is the third version of the patchset.
>
> Changes since the last patchset:
> - Updated commit message of first patch to clarify fixes
> - Add ack from Roman
>
> There should be no code changes since the last patchset.
>
> Let me know if any
> On Sep 7, 2018, at 12:48 PM, Dave Hansen wrote:
>
>
> From: Dave Hansen
>
> We pass around a variable called "error_code" all around the page
> fault code. Sounds simple enough, especially since "error_code" looks
> like it exactly matches the values that the hardware gives us on the
>
> On Sep 7, 2018, at 12:48 PM, Dave Hansen wrote:
>
>
> From: Dave Hansen
>
> We pass around a variable called "error_code" all around the page
> fault code. Sounds simple enough, especially since "error_code" looks
> like it exactly matches the values that the hardware gives us on the
>
On Fri, Sep 07, 2018 at 11:10:21PM +0200, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 3.18.122 release.
> There are 29 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me
On Fri, Sep 07, 2018 at 11:10:21PM +0200, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 3.18.122 release.
> There are 29 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me
On Fri, Sep 07, 2018 at 11:09:56PM +0200, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.4.155 release.
> There are 47 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me
On Fri, Sep 07, 2018 at 11:09:56PM +0200, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.4.155 release.
> There are 47 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me
On 09/07/2018 03:21 PM, Andy Lutomirski wrote:
>> +static void
>> +do_kern_addr_space_fault(struct pt_regs *regs, unsigned long hw_error_code,
>> + unsigned long address)
>> +{
>
> Can you add a comment above this documenting *when* it’s called? Is
> it all faults, !user_mode faults,
On 09/07/2018 03:21 PM, Andy Lutomirski wrote:
>> +static void
>> +do_kern_addr_space_fault(struct pt_regs *regs, unsigned long hw_error_code,
>> + unsigned long address)
>> +{
>
> Can you add a comment above this documenting *when* it’s called? Is
> it all faults, !user_mode faults,
On Fri, Sep 07, 2018 at 11:08:54PM +0200, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.14.69 release.
> There are 89 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me
On Fri, Sep 07, 2018 at 11:08:54PM +0200, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.14.69 release.
> There are 89 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me
When reducing ring buffer size, pages are removed by scheduling a work
item on each CPU for the corresponding CPU ring buffer. After the pages
are removed from ring buffer linked list, the pages are free()d in a
tight loop. The loop does not give up CPU until all pages are removed.
In a worst case
When reducing ring buffer size, pages are removed by scheduling a work
item on each CPU for the corresponding CPU ring buffer. After the pages
are removed from ring buffer linked list, the pages are free()d in a
tight loop. The loop does not give up CPU until all pages are removed.
In a worst case
On 09/07/2018 02:34 AM, Michal Hocko wrote:
> On Thu 06-09-18 15:53:34, Shuah Khan wrote:
> [...]
>> A few critical allocations could be satisfied and root cgroup prevails. It
>> is not the
>> intent to have exclusivity at the expense of the kernel.
>
> Well, it is not "few critical
On 09/07/2018 02:34 AM, Michal Hocko wrote:
> On Thu 06-09-18 15:53:34, Shuah Khan wrote:
> [...]
>> A few critical allocations could be satisfied and root cgroup prevails. It
>> is not the
>> intent to have exclusivity at the expense of the kernel.
>
> Well, it is not "few critical
> On Sep 7, 2018, at 12:48 PM, Dave Hansen wrote:
>
>
> From: Dave Hansen
>
> The page fault handler (__do_page_fault()) basically has two sections:
> one for handling faults in the kernel porttion of the address space
> and another for faults in the user porttion of the address space.
>
> On Sep 7, 2018, at 12:48 PM, Dave Hansen wrote:
>
>
> From: Dave Hansen
>
> The page fault handler (__do_page_fault()) basically has two sections:
> one for handling faults in the kernel porttion of the address space
> and another for faults in the user porttion of the address space.
>
The comment above asm_volatile_goto mentions working around a GCC bug,
and links to a bug report that claims this has been fixed in newer
versions of GCC. Testing shows that this was resolved in GCC 4.8.2.
asm_volatile_goto should also be defined for other compilers that
support asm goto.
The comment above asm_volatile_goto mentions working around a GCC bug,
and links to a bug report that claims this has been fixed in newer
versions of GCC. Testing shows that this was resolved in GCC 4.8.2.
asm_volatile_goto should also be defined for other compilers that
support asm goto.
On Fri, Sep 7, 2018 at 4:01 PM Paul Burton wrote:
>
> Hi Rob,
>
> On Fri, Sep 07, 2018 at 03:29:03PM -0500, Rob Herring wrote:
> > On Fri, Sep 7, 2018 at 1:55 PM Paul Burton wrote:
> > > The CONFIG_CMDLINE-related logic in early_init_dt_scan_chosen() falls
> > > back to copying CONFIG_CMDLINE
At boot time the acpi_power_meter driver greets users of non-IBM systems with
the message:
"Ignoring unsafe software power cap".
This message is generally interpreted as meaning: The system is operating under
an unsafe power cap and Linux is ignoring this fact, thus living
1 - 100 of 1948 matches
Mail list logo
