On Mon, Jun 04, 2018 at 06:21:22PM +0200, Dmitry Vyukov wrote:
> On Tue, May 29, 2018 at 8:07 PM, Mark Rutland wrote:
> > This series scripts the generation of the various atomic headers, to
> > ensure that the various atomic APIs remain consistent, reducing the risk
> > of human error, and
On Mon, Jun 04, 2018 at 06:21:22PM +0200, Dmitry Vyukov wrote:
> On Tue, May 29, 2018 at 8:07 PM, Mark Rutland wrote:
> > This series scripts the generation of the various atomic headers, to
> > ensure that the various atomic APIs remain consistent, reducing the risk
> > of human error, and
On 06/04/2018 at 04:12 PM Alan Cox wrote:
>> A malicious program most probably won't care about that. Therefore, my
>> next question is: which memory regions can be exploited by a malicious
>> program? The complete physical memory or only the memory provided to the
>> malicious program? Should be
On 06/04/2018 at 04:12 PM Alan Cox wrote:
>> A malicious program most probably won't care about that. Therefore, my
>> next question is: which memory regions can be exploited by a malicious
>> program? The complete physical memory or only the memory provided to the
>> malicious program? Should be
On 05-06-18, 07:48, Daniel Lezcano wrote:
> As soon as we reach complete(), no timer can be set because of the
> condition before.
Why not ? We aren't using any locks here and it is possible that run_duration_ms
is set to 0 from idle_injection_stop() only after the first thread has restarted
the
On 05-06-18, 07:48, Daniel Lezcano wrote:
> As soon as we reach complete(), no timer can be set because of the
> condition before.
Why not ? We aren't using any locks here and it is possible that run_duration_ms
is set to 0 from idle_injection_stop() only after the first thread has restarted
the
> -Original Message-
> From: Eric W. Biederman [mailto:ebied...@xmission.com]
> Sent: Tuesday, June 5, 2018 11:03 AM
> To: Hatayama, Daisuke
> Cc: 'gre...@linuxfoundation.org' ;
> 't...@kernel.org' ; Okajima, Toshiyuki
> ; linux-kernel@vger.kernel.org;
> 'ebied...@aristanetworks.com'
> -Original Message-
> From: Eric W. Biederman [mailto:ebied...@xmission.com]
> Sent: Tuesday, June 5, 2018 11:03 AM
> To: Hatayama, Daisuke
> Cc: 'gre...@linuxfoundation.org' ;
> 't...@kernel.org' ; Okajima, Toshiyuki
> ; linux-kernel@vger.kernel.org;
> 'ebied...@aristanetworks.com'
On 05.06.2018 02:07, Masahiro Yamada wrote:
> Hi Stefan
>
> 2018-06-05 6:49 GMT+09:00 Stefan Agner :
>> Hi Masahiro,
>>
>> On 28.05.2018 11:22, Masahiro Yamada wrote:
>>> This will be useful to specify the required compiler version,
>>> like this:
>>>
>>> config FOO
>>> bool "Use Foo"
>>>
On 05.06.2018 02:07, Masahiro Yamada wrote:
> Hi Stefan
>
> 2018-06-05 6:49 GMT+09:00 Stefan Agner :
>> Hi Masahiro,
>>
>> On 28.05.2018 11:22, Masahiro Yamada wrote:
>>> This will be useful to specify the required compiler version,
>>> like this:
>>>
>>> config FOO
>>> bool "Use Foo"
>>>
--
Good Day,
I, Mavis Wanczyk donates $ 5 Million Dollars from part of my Powerball
Jackpot Lottery of $ 758 Million Dollars, respond with your details
for claims.
I await your earliest response and God Bless you
Good luck.
Mavis Wanczyk
--
Good Day,
I, Mavis Wanczyk donates $ 5 Million Dollars from part of my Powerball
Jackpot Lottery of $ 758 Million Dollars, respond with your details
for claims.
I await your earliest response and God Bless you
Good luck.
Mavis Wanczyk
On 5 June 2018 at 05:47, wrote:
>> -Original Message-
>> From: Daniel J Blueman [mailto:dan...@quora.org]
>> Sent: Thursday, May 31, 2018 9:21 PM
>> To: Linux Kernel; linux-a...@vger.kernel.org
>> Cc: Limonciello, Mario; Dominguez, Jared
>> Subject: 4.14.44:
On 5 June 2018 at 05:47, wrote:
>> -Original Message-
>> From: Daniel J Blueman [mailto:dan...@quora.org]
>> Sent: Thursday, May 31, 2018 9:21 PM
>> To: Linux Kernel; linux-a...@vger.kernel.org
>> Cc: Limonciello, Mario; Dominguez, Jared
>> Subject: 4.14.44:
On 05/06/2018 07:14, Viresh Kumar wrote:
> On 31-05-18, 20:25, Daniel Lezcano wrote:
>> On 29/05/2018 11:31, Viresh Kumar wrote:
>>> On 25-05-18, 11:49, Daniel Lezcano wrote:
+ /* + * The last CPU waking up is in charge of setting the
timer. If + * the CPU is hotplugged, the
On 05/06/2018 07:14, Viresh Kumar wrote:
> On 31-05-18, 20:25, Daniel Lezcano wrote:
>> On 29/05/2018 11:31, Viresh Kumar wrote:
>>> On 25-05-18, 11:49, Daniel Lezcano wrote:
+ /* + * The last CPU waking up is in charge of setting the
timer. If + * the CPU is hotplugged, the
Hi Nadav,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on linus/master]
[also build test ERROR on v4.17 next-20180604]
[cannot apply to tip/x86/core]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https
Hi Nadav,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on linus/master]
[also build test ERROR on v4.17 next-20180604]
[cannot apply to tip/x86/core]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https
> -Original Message-
> From: Eric W. Biederman [mailto:ebied...@xmission.com]
> Sent: Monday, June 4, 2018 11:45 PM
> To: Hatayama, Daisuke
> Cc: 'gre...@linuxfoundation.org' ;
> 't...@kernel.org' ; Okajima, Toshiyuki
> ; linux-kernel@vger.kernel.org;
> 'ebied...@aristanetworks.com'
> -Original Message-
> From: Eric W. Biederman [mailto:ebied...@xmission.com]
> Sent: Monday, June 4, 2018 11:45 PM
> To: Hatayama, Daisuke
> Cc: 'gre...@linuxfoundation.org' ;
> 't...@kernel.org' ; Okajima, Toshiyuki
> ; linux-kernel@vger.kernel.org;
> 'ebied...@aristanetworks.com'
Hi Nadav,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on linus/master]
[also build test ERROR on v4.17 next-20180604]
[cannot apply to tip/x86/core]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https
Hi Nadav,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on linus/master]
[also build test ERROR on v4.17 next-20180604]
[cannot apply to tip/x86/core]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https
IPQ8074 has an integrated Hexagon dsp core q6v5 and a wireless lan
(Lithium) IP. An mdt type single image format is used for the
firmware. So the mdt_load function can be directly used to load
the firmware. Also add the relevant resets required for this core.
Acked-by: Rob Herring (for bindings)
IPQ8074 has an integrated Hexagon dsp core q6v5 and a wireless lan
(Lithium) IP. An mdt type single image format is used for the
firmware. So the mdt_load function can be directly used to load
the firmware. Also add the relevant resets required for this core.
Acked-by: Rob Herring (for bindings)
Hi Nadav,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on linus/master]
[also build test ERROR on v4.17 next-20180604]
[cannot apply to tip/x86/core]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https
Hi Nadav,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on linus/master]
[also build test ERROR on v4.17 next-20180604]
[cannot apply to tip/x86/core]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https
On 06/04/18 20:57, Mika Penttilä wrote:
>
> This won't work on X86-32 because it actually uses the segment limit with fs:
> access. So there
> is a reason why the lsl based method is X86-64 only.
>
Why does that matter in any shape, way, or form? The LSL instruction
doesn't touch any of
On 06/04/18 20:57, Mika Penttilä wrote:
>
> This won't work on X86-32 because it actually uses the segment limit with fs:
> access. So there
> is a reason why the lsl based method is X86-64 only.
>
Why does that matter in any shape, way, or form? The LSL instruction
doesn't touch any of
On Mon, Jun 04, 2018 at 04:17:25PM -0700, Palmer Dabbelt wrote:
> On Tue, 29 May 2018 08:43:33 PDT (-0700), mark.rutl...@arm.com wrote:
> > We define a trivial fallback for atomic_inc_not_zero(), but don't do
> > the same for atmic64_inc_not_zero(), leading most architectures to
> > define the
On Mon, Jun 04, 2018 at 04:17:25PM -0700, Palmer Dabbelt wrote:
> On Tue, 29 May 2018 08:43:33 PDT (-0700), mark.rutl...@arm.com wrote:
> > We define a trivial fallback for atomic_inc_not_zero(), but don't do
> > the same for atmic64_inc_not_zero(), leading most architectures to
> > define the
On 03-06-18, 08:52, Janani Sankara Babu wrote:
> This patch replaces comparison of var to NULL with !var
>
> Signed-off-by: Janani Sankara Babu
> ---
> drivers/staging/greybus/core.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/staging/greybus/core.c
On 03-06-18, 08:52, Janani Sankara Babu wrote:
> This patch replaces comparison of var to NULL with !var
>
> Signed-off-by: Janani Sankara Babu
> ---
> drivers/staging/greybus/core.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/staging/greybus/core.c
On 06/05/2018 07:44 AM, Bae, Chang Seok wrote:
>>> diff --git a/arch/x86/kernel/setup_percpu.c b/arch/x86/kernel/setup_percpu.c
>>> index ea554f8..e716e94 100644
>>> --- a/arch/x86/kernel/setup_percpu.c
>>> +++ b/arch/x86/kernel/setup_percpu.c
>>> @@ -155,12 +155,21 @@ static void __init
On 06/05/2018 07:44 AM, Bae, Chang Seok wrote:
>>> diff --git a/arch/x86/kernel/setup_percpu.c b/arch/x86/kernel/setup_percpu.c
>>> index ea554f8..e716e94 100644
>>> --- a/arch/x86/kernel/setup_percpu.c
>>> +++ b/arch/x86/kernel/setup_percpu.c
>>> @@ -155,12 +155,21 @@ static void __init
On 31-05-18, 20:25, Daniel Lezcano wrote:
> On 29/05/2018 11:31, Viresh Kumar wrote:
> > On 25-05-18, 11:49, Daniel Lezcano wrote:
> >> + /*
> >> + * The last CPU waking up is in charge of setting the timer. If
> >> + * the CPU is hotplugged, the timer will move to another CPU
> >> + *
On 31-05-18, 20:25, Daniel Lezcano wrote:
> On 29/05/2018 11:31, Viresh Kumar wrote:
> > On 25-05-18, 11:49, Daniel Lezcano wrote:
> >> + /*
> >> + * The last CPU waking up is in charge of setting the timer. If
> >> + * the CPU is hotplugged, the timer will move to another CPU
> >> + *
The cooling device properties, like "#cooling-cells" and
"dynamic-power-coefficient", should either be present for all the CPUs
of a cluster or none. If these are present only for a subset of CPUs of
a cluster then things will start falling apart as soon as the CPUs are
brought online in a
The cooling device properties, like "#cooling-cells" and
"dynamic-power-coefficient", should either be present for all the CPUs
of a cluster or none. If these are present only for a subset of CPUs of
a cluster then things will start falling apart as soon as the CPUs are
brought online in a
The cooling device properties, like "#cooling-cells" and
"dynamic-power-coefficient", should either be present for all the CPUs
of a cluster or none. If these are present only for a subset of CPUs of
a cluster then things will start falling apart as soon as the CPUs are
brought online in a
The cooling device properties, like "#cooling-cells" and
"dynamic-power-coefficient", should either be present for all the CPUs
of a cluster or none. If these are present only for a subset of CPUs of
a cluster then things will start falling apart as soon as the CPUs are
brought online in a
Hi,
* Maciej Purski [180604 14:02]:
> Tony, please apply this patchset and test it on your Beaglebone. It'd be
> great if you could try to find out, which patch causes failure. They should
> be appliable on the current next.
It seems beagle-x15 boots for me except with the last patch in the
Hi,
* Maciej Purski [180604 14:02]:
> Tony, please apply this patchset and test it on your Beaglebone. It'd be
> great if you could try to find out, which patch causes failure. They should
> be appliable on the current next.
It seems beagle-x15 boots for me except with the last patch in the
>> diff --git a/arch/x86/kernel/setup_percpu.c b/arch/x86/kernel/setup_percpu.c
>> index ea554f8..e716e94 100644
>> --- a/arch/x86/kernel/setup_percpu.c
>> +++ b/arch/x86/kernel/setup_percpu.c
>> @@ -155,12 +155,21 @@ static void __init pcpup_populate_pte(unsigned long
>> addr)
>>
>> static
>> diff --git a/arch/x86/kernel/setup_percpu.c b/arch/x86/kernel/setup_percpu.c
>> index ea554f8..e716e94 100644
>> --- a/arch/x86/kernel/setup_percpu.c
>> +++ b/arch/x86/kernel/setup_percpu.c
>> @@ -155,12 +155,21 @@ static void __init pcpup_populate_pte(unsigned long
>> addr)
>>
>> static
On 02-06-18, 01:14, Olof Johansson wrote:
> And what I am saying is that it sounds like a broken binding if you don't
> allow
> that, especially since it'll be a super common case that all CPUs will specify
> the same cooling-device specifier.
I am fine with allowing the #cooling-cells property
On 02-06-18, 01:14, Olof Johansson wrote:
> And what I am saying is that it sounds like a broken binding if you don't
> allow
> that, especially since it'll be a super common case that all CPUs will specify
> the same cooling-device specifier.
I am fine with allowing the #cooling-cells property
On Mon, Jun 04, 2018 at 02:58:49PM -0700, Roland Dreier wrote:
> We plan to implement all the fancy NVMe standards like ANA, but it
> seems that there is still a requirement to let the host side choose
> policies about how to use paths (round-robin vs least queue depth for
> example). Even in the
On Mon, Jun 04, 2018 at 02:58:49PM -0700, Roland Dreier wrote:
> We plan to implement all the fancy NVMe standards like ANA, but it
> seems that there is still a requirement to let the host side choose
> policies about how to use paths (round-robin vs least queue depth for
> example). Even in the
Daniel Jordan writes:
> On Wed, May 23, 2018 at 04:26:04PM +0800, Huang, Ying wrote:
>> And for all, Any comment is welcome!
>>
>> This patchset is based on the 2018-05-18 head of mmotm/master.
>
> Trying to review this and it doesn't apply to mmotm-2018-05-18-16-44. git
> fails on patch 10:
>
Daniel Jordan writes:
> On Wed, May 23, 2018 at 04:26:04PM +0800, Huang, Ying wrote:
>> And for all, Any comment is welcome!
>>
>> This patchset is based on the 2018-05-18 head of mmotm/master.
>
> Trying to review this and it doesn't apply to mmotm-2018-05-18-16-44. git
> fails on patch 10:
>
* Pavel Machek [180603 21:03]:
> Hi!
>
> > > Aaro, I know I have asked before, but if you have common config for
> > > N900 and Droid4, please send me a copy. Yes, it should be somewhere in
> > > my inbox already, but I can't find it and version for v4.17 would be
> > > more useful.
> > >
> > >
* Pavel Machek [180603 21:03]:
> Hi!
>
> > > Aaro, I know I have asked before, but if you have common config for
> > > N900 and Droid4, please send me a copy. Yes, it should be somewhere in
> > > my inbox already, but I can't find it and version for v4.17 would be
> > > more useful.
> > >
> > >
On Fri, 1 Jun 2018, Michal Hocko wrote:
> > We've discussed the mm
> > having a single blockable mmu notifier. Regardless of how we arrive at
> > the point where the oom reaper can't free memory, which could be any of
> > those three cases, if (1) the original victim is sufficiently large
On Fri, 1 Jun 2018, Michal Hocko wrote:
> > We've discussed the mm
> > having a single blockable mmu notifier. Regardless of how we arrive at
> > the point where the oom reaper can't free memory, which could be any of
> > those three cases, if (1) the original victim is sufficiently large
Quoting Tycho Andersen (ty...@tycho.ws):
> We have reports of the following crash:
>
> PID: 7 TASK: 88085c6d61c0 CPU: 1 COMMAND: "kworker/u25:0"
> #0 [88085c6db710] machine_kexec at 81046239
> #1 [88085c6db760] crash_kexec at 810fc248
> #2
Quoting Tycho Andersen (ty...@tycho.ws):
> We have reports of the following crash:
>
> PID: 7 TASK: 88085c6d61c0 CPU: 1 COMMAND: "kworker/u25:0"
> #0 [88085c6db710] machine_kexec at 81046239
> #1 [88085c6db760] crash_kexec at 810fc248
> #2
On 06/04/2018 10:24 PM, Chang S. Bae wrote:
> The CPU (and node) number will be written, as early enough,
> to the segment limit of per CPU data and TSC_AUX MSR entry.
> The information has been retrieved by vgetcpu in user space
> and will be also loaded from the paranoid entry, when
> FSGSBASE
On 06/04/2018 10:24 PM, Chang S. Bae wrote:
> The CPU (and node) number will be written, as early enough,
> to the segment limit of per CPU data and TSC_AUX MSR entry.
> The information has been retrieved by vgetcpu in user space
> and will be also loaded from the paranoid entry, when
> FSGSBASE
* Rik van Riel [2018-06-04 16:05:55]:
> On Mon, 2018-06-04 at 15:30 +0530, Srikar Dronamraju wrote:
>
> > @@ -1554,6 +1562,9 @@ static void task_numa_compare(struct
> > task_numa_env *env,
> > if (READ_ONCE(dst_rq->numa_migrate_on))
> > return;
> >
> > + if (*move &&
* Rik van Riel [2018-06-04 16:05:55]:
> On Mon, 2018-06-04 at 15:30 +0530, Srikar Dronamraju wrote:
>
> > @@ -1554,6 +1562,9 @@ static void task_numa_compare(struct
> > task_numa_env *env,
> > if (READ_ONCE(dst_rq->numa_migrate_on))
> > return;
> >
> > + if (*move &&
On Tue, Jun 5, 2018 at 10:31 AM, Darren Hart wrote:
> On Mon, Jun 04, 2018 at 04:23:04PM +0200, Hans de Goede wrote:
>> Hi,
>>
>> On 04-06-18 15:51, Daniel Drake wrote:
>> > On Mon, Jun 4, 2018 at 7:22 AM, Hans de Goede wrote:
>> > > Is this really a case of the hardware itself processing the
>>
On Tue, Jun 5, 2018 at 10:31 AM, Darren Hart wrote:
> On Mon, Jun 04, 2018 at 04:23:04PM +0200, Hans de Goede wrote:
>> Hi,
>>
>> On 04-06-18 15:51, Daniel Drake wrote:
>> > On Mon, Jun 4, 2018 at 7:22 AM, Hans de Goede wrote:
>> > > Is this really a case of the hardware itself processing the
>>
Hi Lee,
After merging the mfd tree, today's linux-next build (x86_64 allmodconfig)
produced this warning:
drivers/mfd/cros_ec_dev.c:265:13: warning: '__remove' defined but not used
[-Wunused-function]
static void __remove(struct device *dev) { }
^~~~
Introduced by commit
Hi Lee,
After merging the mfd tree, today's linux-next build (x86_64 allmodconfig)
produced this warning:
drivers/mfd/cros_ec_dev.c:265:13: warning: '__remove' defined but not used
[-Wunused-function]
static void __remove(struct device *dev) { }
^~~~
Introduced by commit
Hi Marcus,
I have been taking a look at the pi433 driver these last days, and started
working on the remaining TODOs. I just stumbled across the following
one (drivers/staging/pi433/rf69.c):
245 // TODO: Dependency to bitrate
246 if (deviation < 600 || deviation > 50) {
247
Hi Marcus,
I have been taking a look at the pi433 driver these last days, and started
working on the remaining TODOs. I just stumbled across the following
one (drivers/staging/pi433/rf69.c):
245 // TODO: Dependency to bitrate
246 if (deviation < 600 || deviation > 50) {
247
Hi Dennis,
On Mon, Jun 04, 2018 at 08:13:43PM -0500, Dennis Gilmore wrote:
> The helios4 is a Armada388 based nas board designed by SolidRun and
> based on their SOM. It is sold by kobol.io the dts file came from
>
Hi Dennis,
On Mon, Jun 04, 2018 at 08:13:43PM -0500, Dennis Gilmore wrote:
> The helios4 is a Armada388 based nas board designed by SolidRun and
> based on their SOM. It is sold by kobol.io the dts file came from
>
On 06/04/2018 07:27 PM, Matthew Wilcox wrote:
> On Mon, Jun 04, 2018 at 06:27:09PM -0700, John Johansen wrote:
>> hey Mathew,
>>
>> I've pulled this into apparmor-next and done the retuning of
>> AA_SECID_INVALID a follow on patch. The reworking of the api to
>> return the specific error type can
On 06/04/2018 07:27 PM, Matthew Wilcox wrote:
> On Mon, Jun 04, 2018 at 06:27:09PM -0700, John Johansen wrote:
>> hey Mathew,
>>
>> I've pulled this into apparmor-next and done the retuning of
>> AA_SECID_INVALID a follow on patch. The reworking of the api to
>> return the specific error type can
On Mon, Jun 04, 2018 at 04:23:04PM +0200, Hans de Goede wrote:
> Hi,
>
> On 04-06-18 15:51, Daniel Drake wrote:
> > On Mon, Jun 4, 2018 at 7:22 AM, Hans de Goede wrote:
> > > Is this really a case of the hardware itself processing the
> > > keypress and then changing the brightness *itself* ?
>
On Mon, Jun 04, 2018 at 04:23:04PM +0200, Hans de Goede wrote:
> Hi,
>
> On 04-06-18 15:51, Daniel Drake wrote:
> > On Mon, Jun 4, 2018 at 7:22 AM, Hans de Goede wrote:
> > > Is this really a case of the hardware itself processing the
> > > keypress and then changing the brightness *itself* ?
>
Hi Patrick,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on tip/sched/core]
[also build test ERROR on next-20180604]
[cannot apply to v4.17]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https
Hi Patrick,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on tip/sched/core]
[also build test ERROR on next-20180604]
[cannot apply to v4.17]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https
On Mon, Jun 04, 2018 at 06:27:09PM -0700, John Johansen wrote:
> hey Mathew,
>
> I've pulled this into apparmor-next and done the retuning of
> AA_SECID_INVALID a follow on patch. The reworking of the api to
> return the specific error type can wait for another cycle.
Oh ... here's what I
On Mon, Jun 04, 2018 at 06:27:09PM -0700, John Johansen wrote:
> hey Mathew,
>
> I've pulled this into apparmor-next and done the retuning of
> AA_SECID_INVALID a follow on patch. The reworking of the api to
> return the specific error type can wait for another cycle.
Oh ... here's what I
I misunderstood the cause of a deadlock.
I sent v2 fixing the commit message about the reason of the deadlock.
Please ignore this and review v2.
Thank you.
> -Original Message-
> From: Steven Rostedt [mailto:rost...@goodmis.org]
> Sent: Tuesday, June 05, 2018 10:44 AM
> To: Hoeun Ryu
>
I misunderstood the cause of a deadlock.
I sent v2 fixing the commit message about the reason of the deadlock.
Please ignore this and review v2.
Thank you.
> -Original Message-
> From: Steven Rostedt [mailto:rost...@goodmis.org]
> Sent: Tuesday, June 05, 2018 10:44 AM
> To: Hoeun Ryu
>
From: Hoeun Ryu
Many console device drivers hold the uart_port->lock spinlock with irq disabled
(using spin_lock_irqsave()) while the device drivers are writing characters to
their
devices, but the device drivers just try to hold the spin lock (using
spin_trylock_irqsave()) instead if
From: Hoeun Ryu
Many console device drivers hold the uart_port->lock spinlock with irq disabled
(using spin_lock_irqsave()) while the device drivers are writing characters to
their
devices, but the device drivers just try to hold the spin lock (using
spin_trylock_irqsave()) instead if
On Mon, Jun 04, 2018 at 08:32:37PM +0800, Chris Chiu wrote:
> Make asus-wmi notify on hotkey kbd brightness changes, listen for
> brightness events and update the brightness directly in the driver.
> For this purpose, bound check on brightness in kbd_led_set must be
> based on the same data type
On Mon, Jun 04, 2018 at 08:32:37PM +0800, Chris Chiu wrote:
> Make asus-wmi notify on hotkey kbd brightness changes, listen for
> brightness events and update the brightness directly in the driver.
> For this purpose, bound check on brightness in kbd_led_set must be
> based on the same data type
ebied...@xmission.com (Eric W. Biederman) writes:
> "Hatayama, Daisuke" writes:
>
>>> Can you test this and please verify it fixes your issue?
>>
>> I tried this patch on top of v4.17 but the system fails to boot
>> without detecting root disks by dracut like this:
[snip]
>> OTOH, there's no
ebied...@xmission.com (Eric W. Biederman) writes:
> "Hatayama, Daisuke" writes:
>
>>> Can you test this and please verify it fixes your issue?
>>
>> I tried this patch on top of v4.17 but the system fails to boot
>> without detecting root disks by dracut like this:
[snip]
>> OTOH, there's no
Early check for mount permissions prevents possible allocation of 3
pages from kmalloc() pool by unpriveledged user which can be used for
spraying the kernel heap.
Signed-off-by: Ilya V. Matveychikov
---
fs/namespace.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/fs/namespace.c
Early check for mount permissions prevents possible allocation of 3
pages from kmalloc() pool by unpriveledged user which can be used for
spraying the kernel heap.
Signed-off-by: Ilya V. Matveychikov
---
fs/namespace.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/fs/namespace.c
On Mon, Jun 4, 2018 at 5:21 AM Ingo Molnar wrote:
>
> - __clear_user() micro-optimization (Alexey Dobriyan)
Was this actually tested?
I think one reason people avoided the constant was that on some
microarchitecture it ended up being a separate uop just for the
constant generation, because it
On Mon, Jun 04, 2018 at 11:27:43AM +0200, Benjamin Berg wrote:
> Hi,
>
> On Thu, 2018-05-24 at 16:33 +0800, Chris Chiu wrote:
> > I've made my change to set the brightness level directly in the
> > driver, but the
> > OSD doesn't show correctly correspond to the level value. The brightness
> >
On Mon, Jun 4, 2018 at 5:21 AM Ingo Molnar wrote:
>
> - __clear_user() micro-optimization (Alexey Dobriyan)
Was this actually tested?
I think one reason people avoided the constant was that on some
microarchitecture it ended up being a separate uop just for the
constant generation, because it
On Mon, Jun 04, 2018 at 11:27:43AM +0200, Benjamin Berg wrote:
> Hi,
>
> On Thu, 2018-05-24 at 16:33 +0800, Chris Chiu wrote:
> > I've made my change to set the brightness level directly in the
> > driver, but the
> > OSD doesn't show correctly correspond to the level value. The brightness
> >
On Tue, May 29, 2018 at 08:59:07AM +, Vadim Pasternak wrote:
> Add documentation for mlxreg-io driver sysfs interfaces for user space
> access to system's power resets control, reset causes monitoring,
> programmable devices version reading and devices selection control.
>
> Signed-off-by:
On Tue, May 29, 2018 at 08:59:07AM +, Vadim Pasternak wrote:
> Add documentation for mlxreg-io driver sysfs interfaces for user space
> access to system's power resets control, reset causes monitoring,
> programmable devices version reading and devices selection control.
>
> Signed-off-by:
On Mon, 4 Jun 2018 14:45:57 +0900
Hoeun Ryu wrote:
> From: Hoeun Ryu
>
> Many console device drivers hold the uart_port->lock spinlock with irq
> enabled
> (using spin_lock()) while the device drivers are writing characters to their
> devices,
> but the device drivers just try to hold the
On Mon, 4 Jun 2018 14:45:57 +0900
Hoeun Ryu wrote:
> From: Hoeun Ryu
>
> Many console device drivers hold the uart_port->lock spinlock with irq
> enabled
> (using spin_lock()) while the device drivers are writing characters to their
> devices,
> but the device drivers just try to hold the
Hi Patrick,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on tip/sched/core]
[also build test ERROR on v4.17 next-20180604]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux
Hi Patrick,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on tip/sched/core]
[also build test ERROR on v4.17 next-20180604]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux
Hi,
On Fri, May 25, 2018 at 06:14:40PM -0700, Ravi Chandra Sadineni wrote:
> Mark cros_ec_keyb has wake enabled by default. If we see a MKBP event
> related to keyboard, call pm_wakeup_event() to make sure wakeup
> triggers are accounted to keyb during suspend resume path.
>
> Signed-off-by:
Hi,
On Fri, May 25, 2018 at 06:14:40PM -0700, Ravi Chandra Sadineni wrote:
> Mark cros_ec_keyb has wake enabled by default. If we see a MKBP event
> related to keyboard, call pm_wakeup_event() to make sure wakeup
> triggers are accounted to keyb during suspend resume path.
>
> Signed-off-by:
Hi Patrick,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on tip/sched/core]
[also build test ERROR on v4.17 next-20180604]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux
Hi Patrick,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on tip/sched/core]
[also build test ERROR on v4.17 next-20180604]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux
1 - 100 of 1660 matches
Mail list logo
