On Wed, Nov 28 2018 at 17:25 -0700, Bjorn Andersson wrote:
On Wed 28 Nov 09:39 PST 2018, Lina Iyer wrote:
On Tue, Nov 27 2018 at 14:45 -0700, Stephen Boyd wrote:
> Quoting Lina Iyer (2018-11-27 10:21:23)
> > On Tue, Nov 27 2018 at 02:12 -0700, Stephen Boyd wrote:
> > >
> > >Two reasons. First,
On Wed, Nov 28 2018 at 17:25 -0700, Bjorn Andersson wrote:
On Wed 28 Nov 09:39 PST 2018, Lina Iyer wrote:
On Tue, Nov 27 2018 at 14:45 -0700, Stephen Boyd wrote:
> Quoting Lina Iyer (2018-11-27 10:21:23)
> > On Tue, Nov 27 2018 at 02:12 -0700, Stephen Boyd wrote:
> > >
> > >Two reasons. First,
> -Original Message-
> From: linux-cifs-ow...@vger.kernel.org On
> Behalf Of Long Li
> Sent: Thursday, November 29, 2018 4:30 PM
> To: Pavel Shilovsky
> Cc: Steve French ; linux-cifs ;
> samba-technical ; Kernel Mailing List
>
> Subject: RE: [Patch v4 2/3] CIFS: Add support for direct
> -Original Message-
> From: linux-cifs-ow...@vger.kernel.org On
> Behalf Of Long Li
> Sent: Thursday, November 29, 2018 4:30 PM
> To: Pavel Shilovsky
> Cc: Steve French ; linux-cifs ;
> samba-technical ; Kernel Mailing List
>
> Subject: RE: [Patch v4 2/3] CIFS: Add support for direct
On 29/11/2018 20:36, Eduardo Valentin wrote:
> On Thu, Nov 29, 2018 at 07:26:56PM +0100, Daniel Lezcano wrote:
>> Without this patch, the thermal driver on hi6220 and hi3660 is broken.
>>
>> That is due because part of the posted patchset was merged but a small
>> change in the DT was dropped.
>>
On 29/11/2018 20:36, Eduardo Valentin wrote:
> On Thu, Nov 29, 2018 at 07:26:56PM +0100, Daniel Lezcano wrote:
>> Without this patch, the thermal driver on hi6220 and hi3660 is broken.
>>
>> That is due because part of the posted patchset was merged but a small
>> change in the DT was dropped.
>>
On Thu, Nov 29, 2018 at 10:35 PM Christian Brauner wrote:
> On Thu, Nov 29, 2018 at 10:02:13PM +0100, Arnd Bergmann wrote:
> > On Thu, Nov 29, 2018 at 9:14 PM Andy Lutomirski wrote:
> >
> > Is the current procfd_signal() proposal (under whichever name) sufficient
> > to correctly implement both
On Thu, Nov 29, 2018 at 10:35 PM Christian Brauner wrote:
> On Thu, Nov 29, 2018 at 10:02:13PM +0100, Arnd Bergmann wrote:
> > On Thu, Nov 29, 2018 at 9:14 PM Andy Lutomirski wrote:
> >
> > Is the current procfd_signal() proposal (under whichever name) sufficient
> > to correctly implement both
The mm-of-the-moment snapshot 2018-11-29-13-37 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
The mm-of-the-moment snapshot 2018-11-29-13-37 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
On Thu, Nov 29, 2018 at 10:02:13PM +0100, Arnd Bergmann wrote:
> On Thu, Nov 29, 2018 at 9:14 PM Andy Lutomirski wrote:
> > > On Nov 29, 2018, at 11:55 AM, Christian Brauner
> > > wrote:
> > >> On Thu, Nov 29, 2018 at 11:22:58AM -0800, Andy Lutomirski wrote:
> > >>> On Thu, Nov 29, 2018 at
On Thu, Nov 29, 2018 at 10:02:13PM +0100, Arnd Bergmann wrote:
> On Thu, Nov 29, 2018 at 9:14 PM Andy Lutomirski wrote:
> > > On Nov 29, 2018, at 11:55 AM, Christian Brauner
> > > wrote:
> > >> On Thu, Nov 29, 2018 at 11:22:58AM -0800, Andy Lutomirski wrote:
> > >>> On Thu, Nov 29, 2018 at
I messed up something such that waiman was not in the thread. Ccing.
On Thu, 29 Nov 2018, Waiman Long wrote:
That can be costly for x86 which will now have 2 locked instructions.
Yeah, and when used as an actual queue we should really start to notice.
Some users just have a single task in
I messed up something such that waiman was not in the thread. Ccing.
On Thu, 29 Nov 2018, Waiman Long wrote:
That can be costly for x86 which will now have 2 locked instructions.
Yeah, and when used as an actual queue we should really start to notice.
Some users just have a single task in
FYI, we noticed the following commit (built with gcc-4.9):
commit: 62f18467c40065cae25a8e52c41de0d9771cfd24 ("locking/lockdep: Complain if
a lock object has no name")
https://github.com/bvanassche/linux for-next
in testcase: trinity
with following parameters:
runtime: 300s
FYI, we noticed the following commit (built with gcc-4.9):
commit: 62f18467c40065cae25a8e52c41de0d9771cfd24 ("locking/lockdep: Complain if
a lock object has no name")
https://github.com/bvanassche/linux for-next
in testcase: trinity
with following parameters:
runtime: 300s
ST remote processor needs some specified memory regions for
firmware and IPC.
Memory regions are defined as reserved memory and should
be registered in remoteproc core thanks to rproc_add_carveout
function before rproc_start. For this, st rproc driver implements
prepare ops.
Signed-off-by: Loic
Remoteproc is now capable to create one specific sub-device per
virtio link to associate a dedicated memory pool.
This implies to change device used by virtio_rpmsg for
buffer allocation from grand-parent to parent.
Signed-off-by: Loic Pallardy
Reviewed-by: Anup Patel
Tested-by: Anup Patel
ST remote processor needs some specified memory regions for
firmware and IPC.
Memory regions are defined as reserved memory and should
be registered in remoteproc core thanks to rproc_add_carveout
function before rproc_start. For this, st rproc driver implements
prepare ops.
Signed-off-by: Loic
Remoteproc is now capable to create one specific sub-device per
virtio link to associate a dedicated memory pool.
This implies to change device used by virtio_rpmsg for
buffer allocation from grand-parent to parent.
Signed-off-by: Loic Pallardy
Reviewed-by: Anup Patel
Tested-by: Anup Patel
This patch creates a dedicated vdev subdevice for each vdev declared
in firmware resource table and associates carveout named "vdev%dbuffer"
(with %d vdev index in resource table) if any as dma coherent memory pool.
Then vdev subdevice is used as parent for virtio device.
Signed-off-by: Loic
This patch creates a dedicated vdev subdevice for each vdev declared
in firmware resource table and associates carveout named "vdev%dbuffer"
(with %d vdev index in resource table) if any as dma coherent memory pool.
Then vdev subdevice is used as parent for virtio device.
Signed-off-by: Loic
This new series corresponds to the remaining patches from [1]
addressing fixed memory region support for remote processor.
The three remaining patches allow to:
- assign a specific memory region to vdev sub device. As all virtio based
services are using virtio device parent for memory
This new series corresponds to the remaining patches from [1]
addressing fixed memory region support for remote processor.
The three remaining patches allow to:
- assign a specific memory region to vdev sub device. As all virtio based
services are using virtio device parent for memory
Today resource table supports only 32bit address fields.
This is not compliant with 64bit platform for which addresses
are cast in 32bit.
This patch adds warn messages when address cast is done.
Signed-off-by: Loic Pallardy
---
drivers/remoteproc/remoteproc_core.c | 8
1 file changed,
Correct remoteproc core behavior when memory carveout device
address is fixed in resource table and rproc device doesn't have
associated IOMMU.
Current returned error is breaking legacy on TI platforms.
This patch restores previous behavior. It adds a warn message when
allocation doesn't fit
Fix typo in comments.
Change returned error from ENOMEM to EINVAL as
not dealing with memory allocation.
Remove carveout forced da update and return an error
when no configuration match
Fixes: c874bf59add0 ("remoteproc: add helper function to check carveout device
address")
Signed-off-by: Loic
Today resource table supports only 32bit address fields.
This is not compliant with 64bit platform for which addresses
are cast in 32bit.
This patch adds warn messages when address cast is done.
Signed-off-by: Loic Pallardy
---
drivers/remoteproc/remoteproc_core.c | 8
1 file changed,
Correct remoteproc core behavior when memory carveout device
address is fixed in resource table and rproc device doesn't have
associated IOMMU.
Current returned error is breaking legacy on TI platforms.
This patch restores previous behavior. It adds a warn message when
allocation doesn't fit
Fix typo in comments.
Change returned error from ENOMEM to EINVAL as
not dealing with memory allocation.
Remove carveout forced da update and return an error
when no configuration match
Fixes: c874bf59add0 ("remoteproc: add helper function to check carveout device
address")
Signed-off-by: Loic
On Thu, 29 Nov 2018, Waiman Long wrote:
That can be costly for x86 which will now have 2 locked instructions.
Yeah, and when used as an actual queue we should really start to notice.
Some users just have a single task in the wake_q because avoiding the cost
of wake_up_process() with locks
These patches fix the comments sent on remoteproc mailing
list after acceptation of memory carveout patch series [1].
In few words, series corrects:
- memory carveout allocation for rproc without iommu
- rproc_da_to_va and trace buffer access to take into account
late carveout allocation
-
With rproc_alloc_registered_carveouts() introduction, carveouts are
allocated after resource table parsing.
rproc_da_to_va() may return NULL at trace resource registering.
This patch modifies trace debufs registering to provide device address
(da) instead of va.
da to va translation is done at
On Thu, 29 Nov 2018, Waiman Long wrote:
That can be costly for x86 which will now have 2 locked instructions.
Yeah, and when used as an actual queue we should really start to notice.
Some users just have a single task in the wake_q because avoiding the cost
of wake_up_process() with locks
These patches fix the comments sent on remoteproc mailing
list after acceptation of memory carveout patch series [1].
In few words, series corrects:
- memory carveout allocation for rproc without iommu
- rproc_da_to_va and trace buffer access to take into account
late carveout allocation
-
With rproc_alloc_registered_carveouts() introduction, carveouts are
allocated after resource table parsing.
rproc_da_to_va() may return NULL at trace resource registering.
This patch modifies trace debufs registering to provide device address
(da) instead of va.
da to va translation is done at
> Subject: Re: [Patch v4 2/3] CIFS: Add support for direct I/O write
>
> ср, 28 нояб. 2018 г. в 18:20, Long Li :
> >
> > > Subject: Re: [Patch v4 2/3] CIFS: Add support for direct I/O write
> > >
> > > ср, 31 окт. 2018 г. в 15:26, Long Li :
> > > >
> > > > From: Long Li
> > > >
> > > > With
Add alloc parameter description and correct comment
about release one.
Signed-off-by: Loic Pallardy
---
drivers/remoteproc/remoteproc_core.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/remoteproc/remoteproc_core.c
b/drivers/remoteproc/remoteproc_core.c
index
As dma member of struct rproc_mem_entry is dma_addr_t, no
need to cast in u32.
Fixes: d7c51706d095 ("remoteproc: add alloc ops in rproc_mem_entry struct")
Signed-off-by: Loic Pallardy
---
drivers/remoteproc/remoteproc_core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
With introduction of rproc_alloc_registered_carveouts() which
delays carveout allocation just before the start of the remote
processor, rproc_da_to_va() could be called before all carveouts
are allocated.
This patch adds a check in rproc_da_to_va() to return NULL if
carveout is not allocated.
> Subject: Re: [Patch v4 2/3] CIFS: Add support for direct I/O write
>
> ср, 28 нояб. 2018 г. в 18:20, Long Li :
> >
> > > Subject: Re: [Patch v4 2/3] CIFS: Add support for direct I/O write
> > >
> > > ср, 31 окт. 2018 г. в 15:26, Long Li :
> > > >
> > > > From: Long Li
> > > >
> > > > With
Add alloc parameter description and correct comment
about release one.
Signed-off-by: Loic Pallardy
---
drivers/remoteproc/remoteproc_core.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/remoteproc/remoteproc_core.c
b/drivers/remoteproc/remoteproc_core.c
index
As dma member of struct rproc_mem_entry is dma_addr_t, no
need to cast in u32.
Fixes: d7c51706d095 ("remoteproc: add alloc ops in rproc_mem_entry struct")
Signed-off-by: Loic Pallardy
---
drivers/remoteproc/remoteproc_core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
With introduction of rproc_alloc_registered_carveouts() which
delays carveout allocation just before the start of the remote
processor, rproc_da_to_va() could be called before all carveouts
are allocated.
This patch adds a check in rproc_da_to_va() to return NULL if
carveout is not allocated.
On Wed, Nov 28, 2018 at 10:45 AM Dave Hansen wrote:
>
> On 11/27/18 2:50 PM, Kees Cook wrote:
> > On Mon, Nov 19, 2018 at 9:06 AM, Dave Hansen wrote:
> >> On 11/19/18 7:43 AM, Yangtao Li wrote:
> >>> -static const struct file_operations ptdump_curusr_fops = {
> >>> - .owner =
On Wed, Nov 28, 2018 at 10:45 AM Dave Hansen wrote:
>
> On 11/27/18 2:50 PM, Kees Cook wrote:
> > On Mon, Nov 19, 2018 at 9:06 AM, Dave Hansen wrote:
> >> On 11/19/18 7:43 AM, Yangtao Li wrote:
> >>> -static const struct file_operations ptdump_curusr_fops = {
> >>> - .owner =
On Tue, Nov 27, 2018 at 8:38 PM Wang, Dongsheng
wrote:
>
> Hello Kees,
>
> On 2018/11/28 6:38, Kees Cook wrote:
> > On Thu, Nov 22, 2018 at 11:54 PM, Wang Dongsheng
> > wrote:
> >> When select ARCH_TASK_STRUCT_ON_STACK the first of thread_info variable
> >> is overwritten by STACK_END_MAGIC. In
On Tue, Nov 27, 2018 at 8:38 PM Wang, Dongsheng
wrote:
>
> Hello Kees,
>
> On 2018/11/28 6:38, Kees Cook wrote:
> > On Thu, Nov 22, 2018 at 11:54 PM, Wang Dongsheng
> > wrote:
> >> When select ARCH_TASK_STRUCT_ON_STACK the first of thread_info variable
> >> is overwritten by STACK_END_MAGIC. In
On Mon, 12 Nov 2018, Thomas Gleixner wrote:
Polite reminder
> While GPL2.0 looks about right, the correct and valid identifiers for GPL v2
> only code are 'GPL-2.0' or 'GPL-2.0-only'.
>
> Signed-off-by: Thomas Gleixner
> Cc: Masami Hiramatsu
> Cc: Shuah Khan (Samsung OSG)
>
> ---
>
>
On Mon, 12 Nov 2018, Thomas Gleixner wrote:
Polite reminder
> While GPL2.0 looks about right, the correct and valid identifiers for GPL v2
> only code are 'GPL-2.0' or 'GPL-2.0-only'.
>
> Signed-off-by: Thomas Gleixner
> Cc: Masami Hiramatsu
> Cc: Shuah Khan (Samsung OSG)
>
> ---
>
>
On Tue, Nov 27, 2018 at 8:44 PM Eric W. Biederman wrote:
>
> Kees Cook writes:
>
> > On Tue, Nov 27, 2018 at 4:38 PM, Kees Cook wrote:
> >> On Tue, Nov 27, 2018 at 3:21 PM, Tycho Andersen wrote:
> >>> On Mon, Nov 12, 2018 at 12:24:43PM -0700, Tycho Andersen wrote:
> On Mon, Nov 12, 2018
On Tue, Nov 27, 2018 at 8:44 PM Eric W. Biederman wrote:
>
> Kees Cook writes:
>
> > On Tue, Nov 27, 2018 at 4:38 PM, Kees Cook wrote:
> >> On Tue, Nov 27, 2018 at 3:21 PM, Tycho Andersen wrote:
> >>> On Mon, Nov 12, 2018 at 12:24:43PM -0700, Tycho Andersen wrote:
> On Mon, Nov 12, 2018
On 11/29/18 4:03 PM, Stephen Smalley wrote:
On 11/29/18 2:47 PM, Miklos Szeredi wrote:
On Thu, Nov 29, 2018 at 5:14 PM Stephen Smalley
wrote:
Possibly I misunderstood you, but I don't think we want to copy-up on
permission denial, as that would still allow the mounter to read/write
special
On 11/29/18 4:03 PM, Stephen Smalley wrote:
On 11/29/18 2:47 PM, Miklos Szeredi wrote:
On Thu, Nov 29, 2018 at 5:14 PM Stephen Smalley
wrote:
Possibly I misunderstood you, but I don't think we want to copy-up on
permission denial, as that would still allow the mounter to read/write
special
This patch series introduces a new flag in remoteproc core to add
support of remote processor having their firmware loading by another
way than standard remoteproc core sequence.
Firmware could be ROMed, loaded by security or bootloader before kernel
boot or loaded by a special rproc platform
Remote processor could boot independently or be started before Linux
kernel by bootloader or any firmware.
This patch introduces a new property in rproc core, named preloaded,
to be able to allocate resources and sub-devices like vdev and to
synchronize with current state without loading firmware
This patch series introduces a new flag in remoteproc core to add
support of remote processor having their firmware loading by another
way than standard remoteproc core sequence.
Firmware could be ROMed, loaded by security or bootloader before kernel
boot or loaded by a special rproc platform
Remote processor could boot independently or be started before Linux
kernel by bootloader or any firmware.
This patch introduces a new property in rproc core, named preloaded,
to be able to allocate resources and sub-devices like vdev and to
synchronize with current state without loading firmware
Post [1] and checkpatch tool indicate that usage of bool type
in structure is now no more allowed/advised.
This patch replaces bool by unsigned char (u8) and reorders
struct rproc fields to avoid padding.
[1] https://lkml.org/lkml/2017/11/21/384
Signed-off-by: Loic Pallardy
---
Post [1] and checkpatch tool indicate that usage of bool type
in structure is now no more allowed/advised.
This patch replaces bool by unsigned char (u8) and reorders
struct rproc fields to avoid padding.
[1] https://lkml.org/lkml/2017/11/21/384
Signed-off-by: Loic Pallardy
---
On Friday, November 9, 2018 3:21:32 PM CET Heikki Krogerus wrote:
> Hi,
>
> This is the second version of my proposal for "software nodes". There
> was a "dereferencing freed memory" bug in patch 3/5 which is now
> fixed. device_add_properties() and device_remove_properties() no
> longer change
On Friday, November 9, 2018 3:21:32 PM CET Heikki Krogerus wrote:
> Hi,
>
> This is the second version of my proposal for "software nodes". There
> was a "dereferencing freed memory" bug in patch 3/5 which is now
> fixed. device_add_properties() and device_remove_properties() no
> longer change
On Thu, Nov 29, 2018 at 03:47:43PM +0100, Oleg Nesterov wrote:
> On 11/29, Dmitry V. Levin wrote:
> >
> > 2. Document these values
>
> sure, they should be documented and live in include/uapi/,
>
> > chosen to avoid collisions with ptrace_message values
> > set by other ptrace events
>
> this
On Thu, Nov 29, 2018 at 03:47:43PM +0100, Oleg Nesterov wrote:
> On 11/29, Dmitry V. Levin wrote:
> >
> > 2. Document these values
>
> sure, they should be documented and live in include/uapi/,
>
> > chosen to avoid collisions with ptrace_message values
> > set by other ptrace events
>
> this
On Thu, Nov 29, 2018 at 04:16:27PM +0800, Chao Fan wrote:
> To fix the conflict between KASLR and memory-hotremove, memory
> information in SRAT table is necessary.
>
> ACPI SRAT (System/Static Resource Affinity Table) can show the details
> about memory ranges, including ranges of memory
On Thu, Nov 29, 2018 at 04:16:27PM +0800, Chao Fan wrote:
> To fix the conflict between KASLR and memory-hotremove, memory
> information in SRAT table is necessary.
>
> ACPI SRAT (System/Static Resource Affinity Table) can show the details
> about memory ranges, including ranges of memory
On Thu, Nov 29, 2018 at 9:14 PM Andy Lutomirski wrote:
> > On Nov 29, 2018, at 11:55 AM, Christian Brauner
> > wrote:
> >> On Thu, Nov 29, 2018 at 11:22:58AM -0800, Andy Lutomirski wrote:
> >>> On Thu, Nov 29, 2018 at 11:17 AM Christian Brauner
> >>> wrote:
> On November 30, 2018 5:54:18
On Thu, Nov 29, 2018 at 9:14 PM Andy Lutomirski wrote:
> > On Nov 29, 2018, at 11:55 AM, Christian Brauner
> > wrote:
> >> On Thu, Nov 29, 2018 at 11:22:58AM -0800, Andy Lutomirski wrote:
> >>> On Thu, Nov 29, 2018 at 11:17 AM Christian Brauner
> >>> wrote:
> On November 30, 2018 5:54:18
On 11/29/18 2:47 PM, Miklos Szeredi wrote:
On Thu, Nov 29, 2018 at 5:14 PM Stephen Smalley wrote:
Possibly I misunderstood you, but I don't think we want to copy-up on
permission denial, as that would still allow the mounter to read/write
special files or execute regular files to which it
On 11/29/18 2:47 PM, Miklos Szeredi wrote:
On Thu, Nov 29, 2018 at 5:14 PM Stephen Smalley wrote:
Possibly I misunderstood you, but I don't think we want to copy-up on
permission denial, as that would still allow the mounter to read/write
special files or execute regular files to which it
Rob,
Eliminating the 'compatible' property for the anybus gives me an interesting
devicetree problem.
The imx-weim code naively loops through all subnodes, applying timing settings
to the CS in the first reg entry.
In the example below, WEIM CS0 is programmed with the settings in
On Thu, Nov 29, 2018 at 4:52 PM Mika Westerberg
wrote:
>
> A malicious PCI device may use DMA to attack the system. An external
> Thunderbolt port is a convenient point to attach such a device. The OS
> may use IOMMU to defend against DMA attacks.
>
> Recent BIOSes with Thunderbolt ports mark
Rob,
Eliminating the 'compatible' property for the anybus gives me an interesting
devicetree problem.
The imx-weim code naively loops through all subnodes, applying timing settings
to the CS in the first reg entry.
In the example below, WEIM CS0 is programmed with the settings in
On Thu, Nov 29, 2018 at 4:52 PM Mika Westerberg
wrote:
>
> A malicious PCI device may use DMA to attack the system. An external
> Thunderbolt port is a convenient point to attach such a device. The OS
> may use IOMMU to defend against DMA attacks.
>
> Recent BIOSes with Thunderbolt ports mark
On Wed, Nov 28, 2018 at 12:48 PM Andy Shevchenko
wrote:
>
> The ACPI device with INT3515 _HID is representing a complex USB PD
> hardware infrastructure which includes several I2C slave ICs.
>
> We add an ID to the I2C multi instantiate list to enumerate
> all I2C slaves correctly.
>
>
On Wed, Nov 28, 2018 at 12:48 PM Andy Shevchenko
wrote:
>
> The ACPI device with INT3515 _HID is representing a complex USB PD
> hardware infrastructure which includes several I2C slave ICs.
>
> We add an ID to the I2C multi instantiate list to enumerate
> all I2C slaves correctly.
>
>
Hi Linus,
Please pull from the tag
git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git \
acpi-4.20-rc5
with top-most commit c4f784268210ae5e6749d4ba30d117bd301a70a6
Merge branch 'acpica-fixes'
on top of commit 2bbb5fa37475d7aa5fa62f34db1623f3da2dfdfa
ACPI / platform: Add
Hi Linus,
Please pull from the tag
git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git \
acpi-4.20-rc5
with top-most commit c4f784268210ae5e6749d4ba30d117bd301a70a6
Merge branch 'acpica-fixes'
on top of commit 2bbb5fa37475d7aa5fa62f34db1623f3da2dfdfa
ACPI / platform: Add
On 11/29/18 5:51 AM, William Kucharski wrote:
> Reviewed-by: William Kucharski
>
>> On Nov 29, 2018, at 4:44 AM, Yongkai Wu wrote:
>>
>> A stack trace was triggered by VM_BUG_ON_PAGE(page_mapcount(page),
>> page) in free_huge_page(). Unfortunately, the page->mapping field
>> was set to NULL
On 11/29/18 5:51 AM, William Kucharski wrote:
> Reviewed-by: William Kucharski
>
>> On Nov 29, 2018, at 4:44 AM, Yongkai Wu wrote:
>>
>> A stack trace was triggered by VM_BUG_ON_PAGE(page_mapcount(page),
>> page) in free_huge_page(). Unfortunately, the page->mapping field
>> was set to NULL
Hi Linus,
Please pull from the tag
git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git \
pm-4.20-rc5
with top-most commit 36c3aeb4b48d5b058526d606fde14db4fd7e5e6d
Merge branch 'opp/fixes-for-4.20' of
git://git.kernel.org/pub/scm/linux/kernel/git/vireshk/pm
on top of commit
Hi Linus,
Please pull from the tag
git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git \
pm-4.20-rc5
with top-most commit 36c3aeb4b48d5b058526d606fde14db4fd7e5e6d
Merge branch 'opp/fixes-for-4.20' of
git://git.kernel.org/pub/scm/linux/kernel/git/vireshk/pm
on top of commit
On 11/29/18 7:11 AM, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 4.19.6 release.
There are 110 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.
Responses should be
On 11/29/18 7:11 AM, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 4.19.6 release.
There are 110 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.
Responses should be
On 11/29/18 7:11 AM, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 4.14.85 release.
There are 100 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.
Responses should be
On 11/29/18 7:11 AM, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 4.14.85 release.
There are 100 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.
Responses should be
On Thu, 29 Nov 2018 10:21:53 + Dave Rodgman wrote:
> >> @@ -41,7 +41,7 @@ static DEFINE_IDR(zram_index_idr);
> >> static DEFINE_MUTEX(zram_index_mutex);
> >>
> >> static int zram_major;
> >> -static const char *default_compressor = "lzo";
> >> +static const char *default_compressor =
On Thu, 29 Nov 2018 10:21:53 + Dave Rodgman wrote:
> >> @@ -41,7 +41,7 @@ static DEFINE_IDR(zram_index_idr);
> >> static DEFINE_MUTEX(zram_index_mutex);
> >>
> >> static int zram_major;
> >> -static const char *default_compressor = "lzo";
> >> +static const char *default_compressor =
> [PATCH] Security: Handle hidepid option correctly
Why is this considered to be security sensitive? I can guess, but I'd
like to know your reasoning.
On Thu, 29 Nov 2018 19:08:21 +0800 d17103...@gmail.com wrote:
> From: Cheng Yang
>
> The proc_parse_options() call from proc_mount() runs
> [PATCH] Security: Handle hidepid option correctly
Why is this considered to be security sensitive? I can guess, but I'd
like to know your reasoning.
On Thu, 29 Nov 2018 19:08:21 +0800 d17103...@gmail.com wrote:
> From: Cheng Yang
>
> The proc_parse_options() call from proc_mount() runs
On 11/29/18 7:11 AM, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 4.9.142 release.
There are 92 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.
Responses should be
On 11/29/18 7:11 AM, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 4.9.142 release.
There are 92 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.
Responses should be
On 11/29/18 7:11 AM, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 4.4.166 release.
There are 86 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.
Responses should be
On 11/29/18 7:11 AM, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 4.4.166 release.
There are 86 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.
Responses should be
On 11/29/18 7:11 AM, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 3.18.128 release.
There are 83 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.
Responses should be
On 11/29/18 7:11 AM, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 3.18.128 release.
There are 83 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.
Responses should be
On Thu, Nov 29, 2018 at 11:27:00AM -0800, Andy Lutomirski wrote:
> On Thu, Nov 29, 2018 at 11:08 AM Linus Torvalds
> wrote:
> >
> > On Thu, Nov 29, 2018 at 10:58 AM Linus Torvalds
> > wrote:
> > >
> > > In contrast, if the call was wrapped in an inline asm, we'd *know* the
> > > compiler
On Thu, Nov 29, 2018 at 11:27:00AM -0800, Andy Lutomirski wrote:
> On Thu, Nov 29, 2018 at 11:08 AM Linus Torvalds
> wrote:
> >
> > On Thu, Nov 29, 2018 at 10:58 AM Linus Torvalds
> > wrote:
> > >
> > > In contrast, if the call was wrapped in an inline asm, we'd *know* the
> > > compiler
> On Nov 29, 2018, at 11:55 AM, Christian Brauner wrote:
>
>> On Thu, Nov 29, 2018 at 11:22:58AM -0800, Andy Lutomirski wrote:
>>> On Thu, Nov 29, 2018 at 11:17 AM Christian Brauner
>>> wrote:
>>>
On November 30, 2018 5:54:18 AM GMT+13:00, Andy Lutomirski
wrote:
> On Nov 29, 2018, at 11:55 AM, Christian Brauner wrote:
>
>> On Thu, Nov 29, 2018 at 11:22:58AM -0800, Andy Lutomirski wrote:
>>> On Thu, Nov 29, 2018 at 11:17 AM Christian Brauner
>>> wrote:
>>>
On November 30, 2018 5:54:18 AM GMT+13:00, Andy Lutomirski
wrote:
601 - 700 of 2748 matches
Mail list logo
