On 30/11/2018 1:13 AM, Thierry Reding wrote:
> On Thu, Nov 29, 2018 at 01:55:02PM +0800, Wei Ni wrote:
>> On 28/11/2018 6:25 PM, Thierry Reding wrote:
>>> On Wed, Nov 28, 2018 at 01:44:37PM +0800, Wei Ni wrote:
> [...]
+ bool ret = false;
+ struct of_phandle_args sensor_specs;
>-Original Message-
>From: Grant Grundler
>Sent: Wednesday, November 28, 2018 5:56 PM
>To: Ryan Lee
>Cc: broo...@kernel.org; Liam Girdwood ;
>pe...@perex.cz; ti...@suse.com; Grant Grundler
>; Kuninori Morimoto
>; Benson Leung
>; alsa-de...@alsa-project.org; LKML ker...@vger.kernel.org>;
On 30/11/2018 1:13 AM, Thierry Reding wrote:
> On Thu, Nov 29, 2018 at 01:55:02PM +0800, Wei Ni wrote:
>> On 28/11/2018 6:25 PM, Thierry Reding wrote:
>>> On Wed, Nov 28, 2018 at 01:44:37PM +0800, Wei Ni wrote:
> [...]
+ bool ret = false;
+ struct of_phandle_args sensor_specs;
>-Original Message-
>From: Grant Grundler
>Sent: Wednesday, November 28, 2018 5:56 PM
>To: Ryan Lee
>Cc: broo...@kernel.org; Liam Girdwood ;
>pe...@perex.cz; ti...@suse.com; Grant Grundler
>; Kuninori Morimoto
>; Benson Leung
>; alsa-de...@alsa-project.org; LKML ker...@vger.kernel.org>;
On 30/11/2018 1:01 AM, Eduardo Valentin wrote:
> On Wed, Nov 21, 2018 at 02:36:10PM +0800, Wei Ni wrote:
>>
>>
>> On 20/11/2018 11:38 PM, Thierry Reding wrote:
>>> On Tue, Nov 20, 2018 at 05:11:17PM +0800, Wei Ni wrote:
Add support for get_trend ops that allows soctherm
sensors to be
On 30/11/2018 1:01 AM, Eduardo Valentin wrote:
> On Wed, Nov 21, 2018 at 02:36:10PM +0800, Wei Ni wrote:
>>
>>
>> On 20/11/2018 11:38 PM, Thierry Reding wrote:
>>> On Tue, Nov 20, 2018 at 05:11:17PM +0800, Wei Ni wrote:
Add support for get_trend ops that allows soctherm
sensors to be
Hi Dave,
On 2018/11/30 0:49, Dave Rodgman wrote:
> On 28/11/2018 1:52 pm, David Sterba wrote:
>
>> The fix is adding a few branches to code that's supposed to be as fast
>> as possible. The branches would be evaluated all the time while
>> protecting against one signle bad page address. This
Hi Dave,
On 2018/11/30 0:49, Dave Rodgman wrote:
> On 28/11/2018 1:52 pm, David Sterba wrote:
>
>> The fix is adding a few branches to code that's supposed to be as fast
>> as possible. The branches would be evaluated all the time while
>> protecting against one signle bad page address. This
On (11/29/18 10:21), Dave Rodgman wrote:
> > [..]
> >> +++ b/drivers/block/zram/zcomp.c
> >> @@ -20,6 +20,7 @@
> >>
> >> static const char * const backends[] = {
> >>"lzo",
> >> + "lzo-rle",
> >> #if IS_ENABLED(CONFIG_CRYPTO_LZ4)
> >>"lz4",
> >> #endif
> >
> > [..]
> >
> >> +++
On (11/29/18 10:21), Dave Rodgman wrote:
> > [..]
> >> +++ b/drivers/block/zram/zcomp.c
> >> @@ -20,6 +20,7 @@
> >>
> >> static const char * const backends[] = {
> >>"lzo",
> >> + "lzo-rle",
> >> #if IS_ENABLED(CONFIG_CRYPTO_LZ4)
> >>"lz4",
> >> #endif
> >
> > [..]
> >
> >> +++
On 11/29/18 6:30 PM, Tom Talpey wrote:
> On 11/29/2018 9:21 PM, John Hubbard wrote:
>> On 11/29/18 6:18 PM, Tom Talpey wrote:
>>> On 11/29/2018 8:39 PM, John Hubbard wrote:
On 11/28/18 5:59 AM, Tom Talpey wrote:
> On 11/27/2018 9:52 PM, John Hubbard wrote:
>> On 11/27/18 5:21 PM, Tom
On 30/11/2018 12:46 AM, Eduardo Valentin wrote:
> On Thu, Nov 29, 2018 at 06:09:43PM +0800, Wei Ni wrote:
>> Since different platforms may not support all 4
>> sensors, so the sensor registration may be failed.
>> Add codes to parse dt to find sensor id which
>> need to be registered. So that
On 11/29/18 6:30 PM, Tom Talpey wrote:
> On 11/29/2018 9:21 PM, John Hubbard wrote:
>> On 11/29/18 6:18 PM, Tom Talpey wrote:
>>> On 11/29/2018 8:39 PM, John Hubbard wrote:
On 11/28/18 5:59 AM, Tom Talpey wrote:
> On 11/27/2018 9:52 PM, John Hubbard wrote:
>> On 11/27/18 5:21 PM, Tom
On 30/11/2018 12:46 AM, Eduardo Valentin wrote:
> On Thu, Nov 29, 2018 at 06:09:43PM +0800, Wei Ni wrote:
>> Since different platforms may not support all 4
>> sensors, so the sensor registration may be failed.
>> Add codes to parse dt to find sensor id which
>> need to be registered. So that
Here is an article illustrates the details.
https://medium.com/@topjohnwu/from-anime-game-to-android-system-security-vulnerability-9b955a182f20
And There is a similar fix on kernel-4.4:
Here is an article illustrates the details.
https://medium.com/@topjohnwu/from-anime-game-to-android-system-security-vulnerability-9b955a182f20
And There is a similar fix on kernel-4.4:
On 30/11/2018 12:39 AM, Eduardo Valentin wrote:
> Hey,
>
> On Thu, Nov 29, 2018 at 06:09:41PM +0800, Wei Ni wrote:
>> Convert warnings to info as not all platforms may
>> have all the thresholds and sensors enabled.
>>
>> Signed-off-by: Wei Ni
>> ---
>> drivers/thermal/tegra/soctherm.c | 6
On 30/11/2018 12:39 AM, Eduardo Valentin wrote:
> Hey,
>
> On Thu, Nov 29, 2018 at 06:09:41PM +0800, Wei Ni wrote:
>> Convert warnings to info as not all platforms may
>> have all the thresholds and sensors enabled.
>>
>> Signed-off-by: Wei Ni
>> ---
>> drivers/thermal/tegra/soctherm.c | 6
>> +
>> +/* acpitb.c */
>> +#define BOOT_STRING
>> +extern int kstrtoull(const char *s, unsigned int base, unsigned long long
>> *res);
>> diff --git a/lib/kstrtox.c b/lib/kstrtox.c
>> index 1006bf70bf74..a0ac1b2257b8 100644
>> --- a/lib/kstrtox.c
>> +++ b/lib/kstrtox.c
>> @@ -126,6 +126,9 @@ int
>> +
>> +/* acpitb.c */
>> +#define BOOT_STRING
>> +extern int kstrtoull(const char *s, unsigned int base, unsigned long long
>> *res);
>> diff --git a/lib/kstrtox.c b/lib/kstrtox.c
>> index 1006bf70bf74..a0ac1b2257b8 100644
>> --- a/lib/kstrtox.c
>> +++ b/lib/kstrtox.c
>> @@ -126,6 +126,9 @@ int
On 2018-11-29, Arnd Bergmann wrote:
> waitid() probably remains on my plate anyway, and I hope understand
> where we're at with it.
Having a way to wait on a processfd is something we'll eventually need,
though the semantics of zombies might get a little bit hairy. I propose
we work through that
On 2018-11-29, Arnd Bergmann wrote:
> waitid() probably remains on my plate anyway, and I hope understand
> where we're at with it.
Having a way to wait on a processfd is something we'll eventually need,
though the semantics of zombies might get a little bit hairy. I propose
we work through that
On Mon, Nov 26, 2018 at 09:12:15PM -0600, Dan Rue wrote:
> diff -Z is used to trim the trailing whitespace when comparing the
> loaded firmware file with the source firmware file. However, per the
> comment in the source code, -Z should not be necessary. In testing, the
> input and output files
On Mon, Nov 26, 2018 at 09:12:15PM -0600, Dan Rue wrote:
> diff -Z is used to trim the trailing whitespace when comparing the
> loaded firmware file with the source firmware file. However, per the
> comment in the source code, -Z should not be necessary. In testing, the
> input and output files
On Fri, Nov 30, 2018 at 01:12:01PM +1100, Stephen Rothwell wrote:
> Hi Andy,
>
> On Thu, 29 Nov 2018 16:42:34 -0600 Andy Gross wrote:
> >
> > On Thu, Nov 29, 2018 at 04:36:00PM -0600, Andy Gross wrote:
> > > On Thu, Nov 29, 2018 at 08:38:26AM -0800, Stephen Boyd wrote:
> > > > We need to check
On Fri, Nov 30, 2018 at 01:12:01PM +1100, Stephen Rothwell wrote:
> Hi Andy,
>
> On Thu, 29 Nov 2018 16:42:34 -0600 Andy Gross wrote:
> >
> > On Thu, Nov 29, 2018 at 04:36:00PM -0600, Andy Gross wrote:
> > > On Thu, Nov 29, 2018 at 08:38:26AM -0800, Stephen Boyd wrote:
> > > > We need to check
On Wed, 28 Nov 2018 18:59:30 +
Nadav Amit wrote:
> > On Nov 20, 2018, at 12:35 PM, Nadav Amit wrote:
> >
> > When modules and BPF filters are loaded, there is a time window in
> > which some memory is both writable and executable. An attacker that has
> > already found another
On Wed, 28 Nov 2018 18:59:30 +
Nadav Amit wrote:
> > On Nov 20, 2018, at 12:35 PM, Nadav Amit wrote:
> >
> > When modules and BPF filters are loaded, there is a time window in
> > which some memory is both writable and executable. An attacker that has
> > already found another
On Mon, Nov 26, 2018 at 09:12:16PM -0600, Dan Rue wrote:
> CONFIG_FW_LOADER_USER_HELPER_FALLBACK=y is required for fw_fallback.sh.
> Without it, fw_fallback.sh fails with 'usermode helper disabled so
> ignoring test'. Enable the config in selftest so that it gets built by
> default.
>
>
On Mon, Nov 26, 2018 at 09:12:16PM -0600, Dan Rue wrote:
> CONFIG_FW_LOADER_USER_HELPER_FALLBACK=y is required for fw_fallback.sh.
> Without it, fw_fallback.sh fails with 'usermode helper disabled so
> ignoring test'. Enable the config in selftest so that it gets built by
> default.
>
>
On Thu, 2018-11-29 at 11:33 +, Lorenzo Pieralisi wrote:
> On Thu, Nov 08, 2018 at 10:56:55AM +0800, honghui.zh...@mediatek.com wrote:
> > From: Honghui Zhang
> >
> > Use the devm_of_pci_get_host_bridge_resources() API in place of the PCI OF
> > DT parser.
> >
> > Signed-off-by: Honghui
On Thu, 2018-11-29 at 11:33 +, Lorenzo Pieralisi wrote:
> On Thu, Nov 08, 2018 at 10:56:55AM +0800, honghui.zh...@mediatek.com wrote:
> > From: Honghui Zhang
> >
> > Use the devm_of_pci_get_host_bridge_resources() API in place of the PCI OF
> > DT parser.
> >
> > Signed-off-by: Honghui
On 11/29/2018 9:21 PM, John Hubbard wrote:
On 11/29/18 6:18 PM, Tom Talpey wrote:
On 11/29/2018 8:39 PM, John Hubbard wrote:
On 11/28/18 5:59 AM, Tom Talpey wrote:
On 11/27/2018 9:52 PM, John Hubbard wrote:
On 11/27/18 5:21 PM, Tom Talpey wrote:
On 11/21/2018 5:06 PM, John Hubbard wrote:
On 11/29/2018 9:21 PM, John Hubbard wrote:
On 11/29/18 6:18 PM, Tom Talpey wrote:
On 11/29/2018 8:39 PM, John Hubbard wrote:
On 11/28/18 5:59 AM, Tom Talpey wrote:
On 11/27/2018 9:52 PM, John Hubbard wrote:
On 11/27/18 5:21 PM, Tom Talpey wrote:
On 11/21/2018 5:06 PM, John Hubbard wrote:
On Thu, Nov 29, 2018 at 11:20:13AM -0500, Masayoshi Mizuma wrote:
>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
On Thu, Nov 29, 2018 at 11:20:13AM -0500, Masayoshi Mizuma wrote:
>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
Petr Mladek wrote:
> See syslog_print_all() and kmsg_dump_get_buffer(). They
> start with calling msg_print_text() many times to calculate
> how many messages fit into the given buffer. Then they
> blindly copy the messages into the buffer.
>
> Now, the buffer might overflow if the size is
Petr Mladek wrote:
> See syslog_print_all() and kmsg_dump_get_buffer(). They
> start with calling msg_print_text() many times to calculate
> how many messages fit into the given buffer. Then they
> blindly copy the messages into the buffer.
>
> Now, the buffer might overflow if the size is
Hi Andy,
On Thu, 29 Nov 2018 16:42:34 -0600 Andy Gross wrote:
>
> On Thu, Nov 29, 2018 at 04:36:00PM -0600, Andy Gross wrote:
> > On Thu, Nov 29, 2018 at 08:38:26AM -0800, Stephen Boyd wrote:
> > > We need to check the call to cmd_db_read_aux_data() for the error case,
> > > so that we don't
Hi Andy,
On Thu, 29 Nov 2018 16:42:34 -0600 Andy Gross wrote:
>
> On Thu, Nov 29, 2018 at 04:36:00PM -0600, Andy Gross wrote:
> > On Thu, Nov 29, 2018 at 08:38:26AM -0800, Stephen Boyd wrote:
> > > We need to check the call to cmd_db_read_aux_data() for the error case,
> > > so that we don't
On Thu, 29 Nov 2018 11:46:52 -0500
Steven Rostedt wrote:
> On Thu, 29 Nov 2018 23:29:27 +0900
> Masami Hiramatsu wrote:
>
> > > One way to solve this is to also have a counter array that gets updated
> > > every time the index array gets updated. And save the counter to the
> > > shadow stack
On Thu, 29 Nov 2018 11:46:52 -0500
Steven Rostedt wrote:
> On Thu, 29 Nov 2018 23:29:27 +0900
> Masami Hiramatsu wrote:
>
> > > One way to solve this is to also have a counter array that gets updated
> > > every time the index array gets updated. And save the counter to the
> > > shadow stack
On 11/29/2018 8:39 PM, John Hubbard wrote:
On 11/28/18 5:59 AM, Tom Talpey wrote:
On 11/27/2018 9:52 PM, John Hubbard wrote:
On 11/27/18 5:21 PM, Tom Talpey wrote:
On 11/21/2018 5:06 PM, John Hubbard wrote:
On 11/21/18 8:49 AM, Tom Talpey wrote:
On 11/21/2018 1:09 AM, John Hubbard wrote:
On 11/29/2018 8:39 PM, John Hubbard wrote:
On 11/28/18 5:59 AM, Tom Talpey wrote:
On 11/27/2018 9:52 PM, John Hubbard wrote:
On 11/27/18 5:21 PM, Tom Talpey wrote:
On 11/21/2018 5:06 PM, John Hubbard wrote:
On 11/21/18 8:49 AM, Tom Talpey wrote:
On 11/21/2018 1:09 AM, John Hubbard wrote:
On 11/29/18 6:18 PM, Tom Talpey wrote:
> On 11/29/2018 8:39 PM, John Hubbard wrote:
>> On 11/28/18 5:59 AM, Tom Talpey wrote:
>>> On 11/27/2018 9:52 PM, John Hubbard wrote:
On 11/27/18 5:21 PM, Tom Talpey wrote:
> On 11/21/2018 5:06 PM, John Hubbard wrote:
>> On 11/21/18 8:49 AM, Tom
On 2018/11/30 10:04, Wang, Dongsheng wrote:
> On 2018/11/30 5:22, Kees Cook wrote:
>> 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
On 11/29/18 6:18 PM, Tom Talpey wrote:
> On 11/29/2018 8:39 PM, John Hubbard wrote:
>> On 11/28/18 5:59 AM, Tom Talpey wrote:
>>> On 11/27/2018 9:52 PM, John Hubbard wrote:
On 11/27/18 5:21 PM, Tom Talpey wrote:
> On 11/21/2018 5:06 PM, John Hubbard wrote:
>> On 11/21/18 8:49 AM, Tom
On 2018/11/30 10:04, Wang, Dongsheng wrote:
> On 2018/11/30 5:22, Kees Cook wrote:
>> 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
On Thu, Nov 29, 2018 at 02:06:39PM -0800, Kees Cook wrote:
> On Tue, Nov 13, 2018 at 11:56 PM Kees Cook wrote:
> > On Fri, Nov 2, 2018 at 1:24 PM, Joel Fernandes
> > wrote:
> > > On Thu, Nov 01, 2018 at 04:51:54PM -0700, Kees Cook wrote:
> > >> + workspace = kmalloc(unzipped_len +
On Thu, Nov 29, 2018 at 02:06:39PM -0800, Kees Cook wrote:
> On Tue, Nov 13, 2018 at 11:56 PM Kees Cook wrote:
> > On Fri, Nov 2, 2018 at 1:24 PM, Joel Fernandes
> > wrote:
> > > On Thu, Nov 01, 2018 at 04:51:54PM -0700, Kees Cook wrote:
> > >> + workspace = kmalloc(unzipped_len +
Hi,
On Thu, Nov 29, 2018 at 6:19 PM Ryan Case wrote:
>
> Transfers were being divided into device FIFO sized (64 byte max)
> operations which would poll for completion within a spin_lock_irqsave /
> spin_unlock_irqrestore block. This both made things slow by waiting for
> the FIFO to completely
Hi,
On Thu, Nov 29, 2018 at 6:19 PM Ryan Case wrote:
>
> Transfers were being divided into device FIFO sized (64 byte max)
> operations which would poll for completion within a spin_lock_irqsave /
> spin_unlock_irqrestore block. This both made things slow by waiting for
> the FIFO to completely
Transfers were being divided into device FIFO sized (64 byte max)
operations which would poll for completion within a spin_lock_irqsave /
spin_unlock_irqrestore block. This both made things slow by waiting for
the FIFO to completely drain before adding further data and would also
result in
Transfers were being divided into device FIFO sized (64 byte max)
operations which would poll for completion within a spin_lock_irqsave /
spin_unlock_irqrestore block. This both made things slow by waiting for
the FIFO to completely drain before adding further data and would also
result in
Hi Abel,
On Thu, 29 Nov 2018 23:50:22 + Abel Vesa wrote:
>
> --- a/drivers/clk/imx/clk-frac-pll.c
> +++ b/drivers/clk/imx/clk-frac-pll.c
> @@ -116,12 +116,13 @@ static long clk_pll_round_rate(struct clk_hw *hw,
> unsigned long rate,
> unsigned long *prate)
> {
Hi Abel,
On Thu, 29 Nov 2018 23:50:22 + Abel Vesa wrote:
>
> --- a/drivers/clk/imx/clk-frac-pll.c
> +++ b/drivers/clk/imx/clk-frac-pll.c
> @@ -116,12 +116,13 @@ static long clk_pll_round_rate(struct clk_hw *hw,
> unsigned long rate,
> unsigned long *prate)
> {
On 2018/11/30 5:22, Kees Cook wrote:
> 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
On 2018/11/30 5:22, Kees Cook wrote:
> 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
On 11/27/18 2:04 AM, Anup Patel wrote:
We explicitly differentiate between PLIC handler and context because
PLIC context is for given mode of HART whereas PLIC handler is per-CPU
software construct meant for handling interrupts from a particular
PLIC context.
Signed-off-by: Anup Patel
---
On 11/27/18 2:04 AM, Anup Patel wrote:
We explicitly differentiate between PLIC handler and context because
PLIC context is for given mode of HART whereas PLIC handler is per-CPU
software construct meant for handling interrupts from a particular
PLIC context.
Signed-off-by: Anup Patel
---
Not the queue, but the RDMA connections.
Let me describe the scenario.
1. connected nvme-rdma target with 500 namespaces
: this will make the nvme_remove_namespaces() took a long time to
complete and open the window vulnerable to this bug
2. host will take below code path for
Not the queue, but the RDMA connections.
Let me describe the scenario.
1. connected nvme-rdma target with 500 namespaces
: this will make the nvme_remove_namespaces() took a long time to
complete and open the window vulnerable to this bug
2. host will take below code path for
On Thu, Nov 29, 2018 at 2:12 PM Doug Anderson wrote:
>
> Hi,
>
> On Wed, Nov 28, 2018 at 3:55 PM Ryan Case wrote:
> > @@ -465,9 +470,19 @@ static void qcom_geni_serial_console_write(struct
> > console *co, const char *s,
> > }
> > writel_relaxed(M_CMD_CANCEL_EN,
On Thu, Nov 29, 2018 at 2:12 PM Doug Anderson wrote:
>
> Hi,
>
> On Wed, Nov 28, 2018 at 3:55 PM Ryan Case wrote:
> > @@ -465,9 +470,19 @@ static void qcom_geni_serial_console_write(struct
> > console *co, const char *s,
> > }
> > writel_relaxed(M_CMD_CANCEL_EN,
On Thu, Nov 29, 2018 at 2:59 PM Sven Van Asbroeck wrote:
>
> 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
On Thu, Nov 29, 2018 at 2:59 PM Sven Van Asbroeck wrote:
>
> 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
On 11/27/18 2:03 AM, Anup Patel wrote:
We make plic_irq_toggle() more generic so that we can enable/disable
hwirq for given cpumask. This generic plic_irq_toggle() will be
eventually used to implement set_affinity for PLIC driver.
Signed-off-by: Anup Patel
---
On 11/27/18 2:03 AM, Anup Patel wrote:
We make plic_irq_toggle() more generic so that we can enable/disable
hwirq for given cpumask. This generic plic_irq_toggle() will be
eventually used to implement set_affinity for PLIC driver.
Signed-off-by: Anup Patel
---
On 11/28/18 5:59 AM, Tom Talpey wrote:
> On 11/27/2018 9:52 PM, John Hubbard wrote:
>> On 11/27/18 5:21 PM, Tom Talpey wrote:
>>> On 11/21/2018 5:06 PM, John Hubbard wrote:
On 11/21/18 8:49 AM, Tom Talpey wrote:
> On 11/21/2018 1:09 AM, John Hubbard wrote:
>> On 11/19/18 10:57 AM, Tom
On 11/28/18 5:59 AM, Tom Talpey wrote:
> On 11/27/2018 9:52 PM, John Hubbard wrote:
>> On 11/27/18 5:21 PM, Tom Talpey wrote:
>>> On 11/21/2018 5:06 PM, John Hubbard wrote:
On 11/21/18 8:49 AM, Tom Talpey wrote:
> On 11/21/2018 1:09 AM, John Hubbard wrote:
>> On 11/19/18 10:57 AM, Tom
On Fri, Nov 30, 2018 at 01:27:07AM +, Al Viro wrote:
> And then there's sb_mount, with 3 instances and arseloads of
> races in 2 out of 3.
PS: the 3rd one (in selinux) is, AFAICS, TOCTOU-free, because
it ignores everything except the mountpoint, which is already
looked up by the caller. No
On Fri, Nov 30, 2018 at 01:27:07AM +, Al Viro wrote:
> And then there's sb_mount, with 3 instances and arseloads of
> races in 2 out of 3.
PS: the 3rd one (in selinux) is, AFAICS, TOCTOU-free, because
it ignores everything except the mountpoint, which is already
looked up by the caller. No
This does not hold at least for NVMe RDMA host driver. An example scenario
is when the RDMA connection is gone while the controller is being deleted.
In this case, the nvmf_reg_write32() for sending shutdown admin command by
the delete_work could be hung forever if the command is not completed
This does not hold at least for NVMe RDMA host driver. An example scenario
is when the RDMA connection is gone while the controller is being deleted.
In this case, the nvmf_reg_write32() for sending shutdown admin command by
the delete_work could be hung forever if the command is not completed
On Thu, Nov 29, 2018 at 04:57:20PM -0800, Casey Schaufler wrote:
> > Question: what *should* happen if we try to cross into a submount and find
> > that the thing on the other side is already mounted elsewhere, with
> > incompatible
> > LSM options? Ditto for referrals, with an extra twist -
On Thu, Nov 29, 2018 at 04:57:20PM -0800, Casey Schaufler wrote:
> > Question: what *should* happen if we try to cross into a submount and find
> > that the thing on the other side is already mounted elsewhere, with
> > incompatible
> > LSM options? Ditto for referrals, with an extra twist -
Hi Linus,
On Monday, November 19, 2018 8:11:23 AM CET Linus Walleij wrote:
> This pushes the handling of inversion semantics and open drain
> settings to the GPIO descriptor and gpiolib. All affected board
> files are also augmented.
>
> This is especially nice since we don't have to have any
>
Hi Linus,
On Monday, November 19, 2018 8:11:23 AM CET Linus Walleij wrote:
> This pushes the handling of inversion semantics and open drain
> settings to the GPIO descriptor and gpiolib. All affected board
> files are also augmented.
>
> This is especially nice since we don't have to have any
>
On Thu, Nov 29, 2018 at 12:55:21PM -0500, Masayoshi Mizuma wrote:
>On Thu, Nov 29, 2018 at 04:16:30PM +0800, Chao Fan wrote:
>> To fix the conflict between KASLR and memory-hotremove, SRAT table
>> should be parsed by RSDP pointer, then find the immovable
>> memory regions and store them in an
On Thu, Nov 29, 2018 at 12:55:21PM -0500, Masayoshi Mizuma wrote:
>On Thu, Nov 29, 2018 at 04:16:30PM +0800, Chao Fan wrote:
>> To fix the conflict between KASLR and memory-hotremove, SRAT table
>> should be parsed by RSDP pointer, then find the immovable
>> memory regions and store them in an
This patch is to add the AMBA device ID for CA73 CPU, so that CPU debug
module can be initialized successfully when a SoC contain CA73 CPUs.
This patch has been verified on 96boards Hikey960.
Signed-off-by: Leo Yan
---
drivers/hwtracing/coresight/coresight-cpu-debug.c | 4
1 file changed,
This patch is to add the AMBA device ID for CA73 CPU, so that CPU debug
module can be initialized successfully when a SoC contain CA73 CPUs.
This patch has been verified on 96boards Hikey960.
Signed-off-by: Leo Yan
---
drivers/hwtracing/coresight/coresight-cpu-debug.c | 4
1 file changed,
Hi, Eduardo
Best Regards!
Anson Huang
> -Original Message-
> From: Eduardo Valentin [mailto:edubez...@gmail.com]
> Sent: 2018年11月30日 0:49
> To: Anson Huang
> Cc: rui.zh...@intel.com; daniel.lezc...@linaro.org; robh...@kernel.org;
> mark.rutl...@arm.com; catalin.mari...@arm.com;
Hi, Eduardo
Best Regards!
Anson Huang
> -Original Message-
> From: Eduardo Valentin [mailto:edubez...@gmail.com]
> Sent: 2018年11月30日 0:49
> To: Anson Huang
> Cc: rui.zh...@intel.com; daniel.lezc...@linaro.org; robh...@kernel.org;
> mark.rutl...@arm.com; catalin.mari...@arm.com;
On Thu, Nov 29, 2018 at 12:32:46PM -0500, Masayoshi Mizuma wrote:
>Hi Chao,
>
>Thank you for your continued working.
Thanks for your test.
>
>Could you please build your patches before sending?
Sorry for the mistake, I build it with the whole patches.
I found there are some problems with the
On Thu, Nov 29, 2018 at 12:32:46PM -0500, Masayoshi Mizuma wrote:
>Hi Chao,
>
>Thank you for your continued working.
Thanks for your test.
>
>Could you please build your patches before sending?
Sorry for the mistake, I build it with the whole patches.
I found there are some problems with the
On 2018/11/29 17:59, Chunyan Zhang wrote:
Hi Adrian,
On Thu, 29 Nov 2018 at 15:36, Adrian Hunter wrote:
On 29/11/18 8:22 AM, Chunyan Zhang wrote:
On Tue, 20 Nov 2018 at 21:41, Adrian Hunter wrote:
On 12/11/18 9:26 AM, Chunyan Zhang wrote:
Some standard SD host controllers can support
On 2018/11/29 17:59, Chunyan Zhang wrote:
Hi Adrian,
On Thu, 29 Nov 2018 at 15:36, Adrian Hunter wrote:
On 29/11/18 8:22 AM, Chunyan Zhang wrote:
On Tue, 20 Nov 2018 at 21:41, Adrian Hunter wrote:
On 12/11/18 9:26 AM, Chunyan Zhang wrote:
Some standard SD host controllers can support
Hi, Eduardo
Best Regards!
Anson Huang
> -Original Message-
> From: Eduardo Valentin [mailto:edubez...@gmail.com]
> Sent: 2018年11月30日 0:51
> To: Anson Huang
> Cc: rui.zh...@intel.com; daniel.lezc...@linaro.org; robh...@kernel.org;
> mark.rutl...@arm.com; catalin.mari...@arm.com;
Hi, Eduardo
Best Regards!
Anson Huang
> -Original Message-
> From: Eduardo Valentin [mailto:edubez...@gmail.com]
> Sent: 2018年11月30日 0:51
> To: Anson Huang
> Cc: rui.zh...@intel.com; daniel.lezc...@linaro.org; robh...@kernel.org;
> mark.rutl...@arm.com; catalin.mari...@arm.com;
On Mon, Nov 26, 2018 at 11:29:40PM -0600, Eric W. Biederman wrote:
> Luis Chamberlain writes:
> > Thanks for the description of how to run into the issue described but
> > is there also a practical use case today where this is happening? I ask
> > as it would be good to know the severity of the
On Thu, Nov 29 2018, Al Viro wrote:
> On Fri, Nov 30, 2018 at 10:33:18AM +1100, NeilBrown wrote:
>>
>> The synchronize_rcu() in namespace_unlock() is called every time
>> a filesystem is unmounted. If a great many filesystems are mounted,
>> this can cause a noticable slow-down in, for example,
On Thu, Nov 29 2018, Al Viro wrote:
> On Fri, Nov 30, 2018 at 10:33:18AM +1100, NeilBrown wrote:
>>
>> The synchronize_rcu() in namespace_unlock() is called every time
>> a filesystem is unmounted. If a great many filesystems are mounted,
>> this can cause a noticable slow-down in, for example,
On Mon, Nov 26, 2018 at 11:29:40PM -0600, Eric W. Biederman wrote:
> Luis Chamberlain writes:
> > Thanks for the description of how to run into the issue described but
> > is there also a practical use case today where this is happening? I ask
> > as it would be good to know the severity of the
On Thu, Nov 29, 2018 at 6:28 PM Stephen Boyd wrote:
>
> Quoting Stephen Boyd (2018-11-07 10:37:31)
> > appropriate structure with to_platform_device() or to_i2c_client()?
> >
> > So the example would become
> >
> > struct of_driver_probe_func {
> > int (*probe)(struct device *dev);
> >
On Thu, Nov 29, 2018 at 6:28 PM Stephen Boyd wrote:
>
> Quoting Stephen Boyd (2018-11-07 10:37:31)
> > appropriate structure with to_platform_device() or to_i2c_client()?
> >
> > So the example would become
> >
> > struct of_driver_probe_func {
> > int (*probe)(struct device *dev);
> >
On 11/29/2018 3:51 PM, Al Viro wrote:
I've added linux-security-module to the CC list.
> On Thu, Nov 29, 2018 at 05:23:24PM -0500, Paul Moore wrote:
>
>>> OK, I will verify that the SELinux submount fix rebased on top of
>>> vfs/work.mount in the way I suggested above passes the same testing
>>>
On 11/29/2018 3:51 PM, Al Viro wrote:
I've added linux-security-module to the CC list.
> On Thu, Nov 29, 2018 at 05:23:24PM -0500, Paul Moore wrote:
>
>>> OK, I will verify that the SELinux submount fix rebased on top of
>>> vfs/work.mount in the way I suggested above passes the same testing
>>>
Martin Blumenstingl writes:
> Hi Kevin,
>
> On Fri, Nov 30, 2018 at 12:28 AM Kevin Hilman wrote:
>>
>> Martin Blumenstingl writes:
>>
>> > Hi Kevin,
>> >
>> > On Thu, Nov 29, 2018 at 1:30 AM Kevin Hilman wrote:
>> >>
>> >> Martin Blumenstingl writes:
>> >>
>> >> > Some Meson8b boards
Martin Blumenstingl writes:
> Hi Kevin,
>
> On Fri, Nov 30, 2018 at 12:28 AM Kevin Hilman wrote:
>>
>> Martin Blumenstingl writes:
>>
>> > Hi Kevin,
>> >
>> > On Thu, Nov 29, 2018 at 1:30 AM Kevin Hilman wrote:
>> >>
>> >> Martin Blumenstingl writes:
>> >>
>> >> > Some Meson8b boards
201 - 300 of 2748 matches
Mail list logo
