The whole static protection magic is silently fixing up anything which is
handed in. That's just wrong. The offending call sites need to be fixed.
Add a debug mechanism which emits a warning if a requested mapping needs to be
fixed up. The DETECT debug mechanism is really not meant to be enabled e
With the range check it is possible to do a quick verification that the
current mapping is correct vs. the static protection areas.
In case a incorrect mapping is detected a warning is emitted and the large
page is split up. If the large page is a 2M page, then the split code is
forced to check th
Avoid the extra variable and gotos by splitting the function into the
actual algorithm and a callable function which contains the lock
protection.
Rename it to should_split_large_page() while at it so the return values make
actually sense.
Clean up the code flow, comments and general whitespace d
When the existing mapping is correct and the new requested page protections
are the same as the existing ones, then further checks can be omitted and the
large page can be preserved. The slow path 4k wise check will not come up with
a different result.
Before:
1G pages checked:
Checking static protections only page by page is slow especially for huge
pages. To allow quick checks over a complete range, add the ability to do
that.
Make the checks inclusive so the ranges can be directly used for debug output
later.
No functional change.
Signed-off-by: Thomas Gleixner
---
The extra loop which tries hard to preserve large pages in case of conflicts
with static protection regions turns out to be not preserving anything, at
least not in the experiments which have been conducted.
There might be corner cases in which the code would be able to preserve a
large page oaccs
On 14-Sep 11:32, Peter Zijlstra wrote:
> On Tue, Aug 28, 2018 at 02:53:14PM +0100, Patrick Bellasi wrote:
> > diff --git a/kernel/sched/cpufreq_schedutil.c
> > b/kernel/sched/cpufreq_schedutil.c
> > index 3fffad3bc8a8..949082555ee8 100644
> > --- a/kernel/sched/cpufreq_schedutil.c
> > +++ b/kernel
On Wed, Sep 12, 2018 at 07:22:27PM -0700, Dan Williams wrote:
> devm semantics arrange for resources to be torn down when
> device-driver-probe fails or when device-driver-release completes.
> Similar to devm_memremap_pages() there is no need to support an explicit
> remove operation when the users
On 09/10/2018 07:37 PM, Eduardo Valentin wrote:
> On Tue, Apr 10, 2018 at 02:41:54PM +0200, Bartlomiej Zolnierkiewicz wrote:
>> Hi,
>>
>> [devm]_thermal_zone_of_sensor_register() is used to register
>> thermal sensor by thermal drivers using DeviceTree. Besides
>> registering sensor this function
On Wed, Sep 12, 2018 at 07:22:22PM -0700, Dan Williams wrote:
> In preparation for consolidating all ZONE_DEVICE enabling via
> devm_memremap_pages(), teach it how to handle the constraints of
> MEMORY_DEVICE_PRIVATE ranges.
MEMORY_DEVICE_PRIVATE still somehow boggles my mind, but otherwise
this l
> An argument could be made to require that the ->kill() operation be set
> in the @pgmap arg rather than passed in separately. However, it helps
> code readability, tracking the lifetime of a given instance, to be able
> to grep the kill routine directly at the devm_memremap_pages() call
> site.
On Wed, Sep 12, 2018 at 07:22:11PM -0700, Dan Williams wrote:
> Given the fact that devm_memremap_pages() requires a percpu_ref that is
> torn down by devm_memremap_pages_release() the current support for
> mapping RAM is broken.
I agree. Do you remember why we even added it in the first place?
2018-09-12 15:43 GMT+09:00 Masahiro Yamada :
> Nobody sets 'targets' in the top-level Makefile or arch/*/Makefile,
> hence $(targets) is empty.
>
> $(wildcard .*.cmd) will do for including the .vmlinux.cmd file.
>
> Signed-off-by: Masahiro Yamada
> ---
Applied to linux-kbuild.
> Makefile | 3 +
2018-09-12 15:18 GMT+09:00 Masahiro Yamada :
> This check has been here more than a decade since commit 0c53c8e6eb45
> ("kbuild: check for wrong use of CFLAGS").
>
> Enough time for migration has passed.
>
> Signed-off-by: Masahiro Yamada
> ---
Applied to linux-kbuild.
> scripts/Makefile.build
2018-09-12 15:43 GMT+09:00 Masahiro Yamada :
> When mixed/config targets are being processed, the top Makefile
> does not need to parse the rest of targets.
>
> Signed-off-by: Masahiro Yamada
> ---
Applied to linux-kbuild.
> Makefile | 5 ++---
> 1 file changed, 2 insertions(+), 3 deletions(-)
vfree() might sleep if called not in interrupt context. Explain
that in the comment.
Signed-off-by: Andrey Ryabinin
---
mm/vmalloc.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/mm/vmalloc.c b/mm/vmalloc.c
index a728fc492557..d00d42d6bf79 100644
--- a/mm/vmalloc.c
+++ b/mm/vmalloc.c
@@
2018-09-12 13:52 GMT+09:00 Masahiro Yamada :
> $(srctree) always points to the top of the source tree whether
> KBUILD_SRC is set or not.
>
> Signed-off-by: Masahiro Yamada
> ---
Applied to linux-kbuild.
> scripts/Kbuild.include | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff
vfree() might sleep if called not in interrupt context.
So does kvfree() too. Fix misleading kvfree()'s comment about
allowed context.
Fixes: 04b8e946075d ("mm/util.c: improve kvfree() kerneldoc")
Signed-off-by: Andrey Ryabinin
---
mm/util.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Add might_sleep() calls to vfree(), kvfree() to catch potential
sleep-in-atomic bugs earlier.
Signed-off-by: Andrey Ryabinin
---
mm/util.c| 2 ++
mm/vmalloc.c | 2 ++
2 files changed, 4 insertions(+)
diff --git a/mm/util.c b/mm/util.c
index 7f1f165f46af..929ed1795bc1 100644
--- a/mm/util.c
On Fri, Sep 14, 2018 at 05:57:07PM +0530, Naresh Kamboju wrote:
> On 13 September 2018 at 18:59, Greg Kroah-Hartman
> wrote:
> > This is the start of the stable review cycle for the 4.18.8 release.
> > There are 197 patches in this series, all will be posted as a response
> > to this one. If anyo
On Fri, Sep 14, 2018 at 12:28:24PM +0200, Martin Schwidefsky wrote:
> I spent some time to get s390 converted to the common mmu_gather code.
> There is one thing I would like to request, namely the ability to
> disable the page gather part of mmu_gather. For my prototype patch
> see below, it defi
On Fri, 2018-09-14 at 05:18 +0100, Al Viro wrote:
> On Thu, Sep 13, 2018 at 04:52:09PM +0100, David Howells wrote:
> > Add two new iterator types to iov_iter:
> >
> > (1) ITER_MAPPING
> >
> > This walks through a set of pages attached to an address_space
> > that
> > are pinned or lock
Hi Saravana,
On 2018-08-02 06:27, Saravana Kannan wrote:
This driver registers itself as a devfreq device that allows devfreq
governors to make bandwidth votes for an interconnect path. This allows
applying various policies for different interconnect paths using
devfreq
governors.
Example use
On Fri, Sep 14, 2018 at 8:21 AM Michal Hocko wrote:
> On Fri 14-09-18 03:33:28, Jann Horn wrote:
> > On Wed, Sep 12, 2018 at 10:43 PM prakash.sangappa
> > wrote:
> > > On 05/09/2018 04:31 PM, Dave Hansen wrote:
> > > > On 05/07/2018 06:16 PM, prakash.sangappa wrote:
> > > >> It will be /proc//num
On 13 September 2018 at 19:00, Greg Kroah-Hartman
wrote:
> This is the start of the stable review cycle for the 4.4.156 release.
> There are 60 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.
>
> Resp
* Jiri Olsa wrote:
> On Fri, Sep 14, 2018 at 02:13:07PM +0200, Ingo Molnar wrote:
> >
> > * Peter Zijlstra wrote:
> >
> > > On Fri, Sep 14, 2018 at 01:47:25PM +0200, Jiri Olsa wrote:
> > > > On Fri, Sep 14, 2018 at 01:15:28PM +0200, Peter Zijlstra wrote:
> > > > > On Fri, Sep 14, 2018 at 11:
Acked-by: Dimitri Sivanich
On Thu, Sep 13, 2018 at 01:53:18PM -0500, Gustavo A. R. Silva wrote:
> Replace "fallthru" with a proper "fall through" annotation.
>
> This fix is part of the ongoing efforts to enabling
> -Wimplicit-fallthrough
>
> Signed-off-by: Gustavo A. R. Silva
> ---
> drivers
On 13 September 2018 at 19:00, Greg Kroah-Hartman
wrote:
> This is the start of the stable review cycle for the 4.9.127 release.
> There are 78 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.
>
> Resp
On Fri, 14 Sep 2018, Rafael J. Wysocki wrote:
> On Fri, Sep 14, 2018 at 11:53 AM Mika Penttilä
> > >> But doesn't injecting sleep time here make monotonic clock too large
> > >> by the amount of sleeptime? tick_freeze() / tick_unfreeze() already
> > >> injects the sleeptime (otherwise delta would
On 13 September 2018 at 19:00, Greg Kroah-Hartman
wrote:
> This is the start of the stable review cycle for the 4.14.70 release.
> There are 115 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.
>
> Res
On 9/14/2018 5:22 AM, Alexey Budankov wrote:
Hi Andi,
On 14.09.2018 11:54, Andi Kleen wrote:
In principle the LBRs need to be flushed between threads. So does
current code.
IMHO, ideally, LBRs stack would be preserved and restored when
switching between execution stacks. That would allow
From: Colin Ian King
Trivial fix to spelling mistake in dev_info message
Signed-off-by: Colin Ian King
---
drivers/regulator/pfuze100-regulator.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/regulator/pfuze100-regulator.c
b/drivers/regulator/pfuze100-regulator.c
On Fri, Sep 14, 2018 at 01:34:14PM +0200, Rafael J. Wysocki wrote:
[...]
> > > So for example, if your logical CPU has an idle state A that may trigger
> > > an
> > > idle state X at the cluster level (if the other logical CPUs happen to be
> > > in
> > > the right states and so on), then the w
From: Colin Ian King
Trivial fix to spelling mistake in function name and comment
Signed-off-by: Colin Ian King
---
drivers/target/iscsi/iscsi_target.c | 2 +-
drivers/target/iscsi/iscsi_target_erl2.c | 2 +-
drivers/target/iscsi/iscsi_target_erl2.h | 2 +-
drivers/target/iscsi/iscsi_t
On 13 September 2018 at 18:59, Greg Kroah-Hartman
wrote:
> This is the start of the stable review cycle for the 4.18.8 release.
> There are 197 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.
>
> Resp
Hi,
> Another possible implementation would be via a vfio region, we already
> support device specific regions via capabilities with vfio_region_info,
> so we could have an edid region which could handle both input and
> output using a defined structure and protocol within the region. With
> an
On (09/14/18 21:03), Tetsuo Handa wrote:
> > 80 bytes is quite short for OOM, agreed.
> >
> >> static char oom_print_buf[1024];
> >> DEFINE_PR_LINE_BUF(level, oom_print_buf);
> >
> > Do I get it right that you suggest to drop the "size" param?
>
> No. I just forgot to add params. ;-)
>
> >
On Fri, Sep 14, 2018 at 02:13:07PM +0200, Ingo Molnar wrote:
>
> * Peter Zijlstra wrote:
>
> > On Fri, Sep 14, 2018 at 01:47:25PM +0200, Jiri Olsa wrote:
> > > On Fri, Sep 14, 2018 at 01:15:28PM +0200, Peter Zijlstra wrote:
> > > > On Fri, Sep 14, 2018 at 11:40:22AM +0200, Ingo Molnar wrote:
> >
On Fri, 14 Sep 2018, Brijesh Singh wrote:
> On 9/14/18 2:10 AM, Borislav Petkov wrote:
> >>/*
> >> + * Clear the memory encryption mask from the .bss..decrypted section.
> >> + * The bss section will be memset to zero later in the initialization so
> >> + * there is no need to zero it aft
Rockpro64 board is a rockchip RK3399 based board from pine64.org.
This commit adds initial device tree support for Rockpro64 board.
Signed-off-by: Akash Gajjar
---
Documentation/devicetree/bindings/arm/rockchip.txt | 4 +
arch/arm64/boot/dts/rockchip/Makefile | 1 +
arch/arm64/b
* Peter Zijlstra wrote:
> On Fri, Sep 14, 2018 at 01:47:25PM +0200, Jiri Olsa wrote:
> > On Fri, Sep 14, 2018 at 01:15:28PM +0200, Peter Zijlstra wrote:
> > > On Fri, Sep 14, 2018 at 11:40:22AM +0200, Ingo Molnar wrote:
> > > > In fact keeping the files separate has scalability advantages for '
On Thu, Sep 13, 2018 at 11:51:45AM +0800, Song Qiang wrote:
> This driver tries to access a block of data on a i2c bus and it tries
> to manually make a device command frame and a consecutively read frame,
> then uses i2c_transfer() to read data. But this has already been
> implemented in i2c_smbus
On 14/09/18 12:43, Alex Elder wrote:
> On 09/14/2018 06:24 AM, Colin King wrote:
>> From: Colin Ian King
>>
>> Trivial fix to spelling mistake
>
> I hate to have two-character fixes to documentation like this. I.e.,
> as long as you're touching the README file it might have been nice to
> review
On 2018/09/14 20:50, Sergey Senozhatsky wrote:
>>> +#define DEFINE_PR_LINE_BUF(lev, name, buf, sz) \
>>> + struct pr_line name = {\
>>> + .sb = __SEQ_BUF_INITIALIZER(buf, (sz)), \
>>> + .level = lev,
On Fri, Sep 14, 2018 at 01:47:25PM +0200, Jiri Olsa wrote:
> On Fri, Sep 14, 2018 at 01:15:28PM +0200, Peter Zijlstra wrote:
> > On Fri, Sep 14, 2018 at 11:40:22AM +0200, Ingo Molnar wrote:
> > > In fact keeping the files separate has scalability advantages for 'perf
> > > report' and similar
> >
On Thu, Sep 13, 2018 at 03:40:10AM +0100, Al Viro wrote:
> From: Al Viro
>
> Signed-off-by: Al Viro
Acked-by: David Sterba
Hi Linus,
Please consider the pull to receive a small fix for mic_x100_dma driver
which fixes driver to use devm_kzalloc for driver memory so that it is
freed properly when it unregisters from dmaengine using managed API
The following changes since commit 5b394b2ddf0347bef56e50c69a58773c94343ff3
Hi Manish,
On Fri, Sep 14, 2018 at 12:48:29PM +0530, Manish Narani wrote:
> The AMS includes an ADC as well as on-chip sensors that can be used to
> sample external voltages and monitor on-die operating conditions, such
> as temperature and supply voltage levels. The AMS has two SYSMON blocks.
> P
On 9/14/18 2:10 AM, Borislav Petkov wrote:
> On Thu, Sep 13, 2018 at 04:51:10PM -0500, Brijesh Singh wrote:
>> kvmclock defines few static variables which are shared with the
>> hypervisor during the kvmclock initialization.
> ...
>
>> diff --git a/arch/x86/kernel/head64.c b/arch/x86/kernel/head
On Fri, Sep 14, 2018 at 10:07:51AM +0100, Patrick Bellasi wrote:
> On 13-Sep 21:12, Peter Zijlstra wrote:
> > On Tue, Aug 28, 2018 at 02:53:11PM +0100, Patrick Bellasi wrote:
> > > +static inline void uclamp_cpu_get_id(struct task_struct *p,
> > > + struct rq *rq, int c
On (09/14/18 19:37), Tetsuo Handa wrote:
> > @@ -20,6 +20,9 @@
> > * Annotation for a "continued" line of log printout (only done after a
> > * line that had no enclosing \n). Only to be used by core/arch code
> > * during early bootup (a continued line is not SMP-safe otherwise).
> > + *
> >
On Fri, Sep 14, 2018 at 01:15:28PM +0200, Peter Zijlstra wrote:
> On Fri, Sep 14, 2018 at 11:40:22AM +0200, Ingo Molnar wrote:
> > In fact keeping the files separate has scalability advantages for 'perf
> > report' and similar
> > parsing tools: they could read all the streams in a per-CPU fashio
On 09/14/2018 06:24 AM, Colin King wrote:
> From: Colin Ian King
>
> Trivial fix to spelling mistake
I hate to have two-character fixes to documentation like this. I.e.,
as long as you're touching the README file it might have been nice to
review it and look for other things. I suspect you fou
On 09/10/2018 07:16 PM, Eduardo Valentin wrote:
> On Tue, Apr 10, 2018 at 02:41:55PM +0200, Bartlomiej Zolnierkiewicz wrote:
>> Add thermal_zone_device_toggle() helper. Then update core code and
>> drivers to use it.
>
> Cool, but I think it would be good to have some sort of rational here
> at
After finding a bug in glibc the question came up how linux/elfcore.h
is supposed to be used from user space. As far as I can tell, it's
not possible, as it references data types that are simply unavailable
there.
The #ifndef __KERNEL__ section in that header dates back to when the
file was introd
On Fri, Sep 14, 2018 at 12:44 PM Lorenzo Pieralisi
wrote:
>
> On Fri, Sep 14, 2018 at 11:50:15AM +0200, Rafael J. Wysocki wrote:
> > On Thursday, August 9, 2018 5:39:25 PM CEST Lorenzo Pieralisi wrote:
> > > On Mon, Aug 06, 2018 at 11:20:59AM +0200, Rafael J. Wysocki wrote:
> > >
> > > [...]
> > >
On Thursday, September 13, 2018 6:08:51 PM CEST Vitaly Kuznetsov wrote:
> It is possible to observe hung_task complaints when system goes to
> suspend-to-idle state:
>
> PM: Syncing filesystems ... done.
> Freezing user space processes ... (elapsed 0.001 seconds) done.
> OOM killer disabled.
>
On 09/13/2018, 08:32 AM, chen.l...@zte.com.cn wrote:
>
>
> but 'get_mctrl' is already protected by the upper layer by spin lock,
> so, will the races happen?
>
>
> for example: in /drivers/tty/serial/serial_core.c
>
> spin_lock_irq(&uport->lock);
>
> resul
The following changes since commit 11da3a7f84f19c26da6f86af878298694ede0804:
Linux 4.19-rc3 (2018-09-09 17:26:43 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty.git tags/tty-4.19-rc4
for you to fetch changes up to 7f2bf7840b74a160f908d
The following changes since commit 5b394b2ddf0347bef56e50c69a58773c94343ff3:
Linux 4.19-rc1 (2018-08-26 14:11:59 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git
tags/staging-4.19-rc4
for you to fetch changes up to 65aac1742328
The following changes since commit 11da3a7f84f19c26da6f86af878298694ede0804:
Linux 4.19-rc3 (2018-09-09 17:26:43 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc.git
tags/char-misc-4.19-rc4
for you to fetch changes up to 422b3db2
From: Colin Ian King
Trivial fix to spelling mistake
Signed-off-by: Colin Ian King
---
drivers/staging/greybus/tools/README.loopback | 2 +-
drivers/staging/greybus/tools/loopback_test.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/greybus/tools/README
On Fri, Sep 14, 2018 at 1:14 PM My Name <18650033...@163.com> wrote:
> Adversaries often attack the Linux kernel via using
> commit_creds(prepare_kernel_cred(0)) to submit ROOT
> credential for the purpose of privilege escalation.
> For processes inside the Linux container, the above
> approach als
On (09/14/18 10:59), Petr Mladek wrote:
>
> Well, I am not sure if it is worth the code complexity.
>
Well, I don't think we need to bother that much here. Besides,
exclusive_console is cleared under logbuf_lock with preemption
disabled now. So we set it under logbuf_lock and !irq and we
clear it
On Fri, Sep 14, 2018 at 11:40:22AM +0200, Ingo Molnar wrote:
> In fact keeping the files separate has scalability advantages for 'perf
> report' and similar
> parsing tools: they could read all the streams in a per-CPU fashion already,
> from the very
> beginning.
Also writing to different fil
On Fri, Sep 07, 2018 at 11:39:47PM +0200, Jan H. Schönherr wrote:
> This patch series extends CFS with support for coscheduling. The
> implementation is versatile enough to cover many different coscheduling
> use-cases, while at the same time being non-intrusive, so that behavior of
> legacy worklo
On Thu, Sep 06, 2018 at 03:40:53PM +0100, Patrick Bellasi wrote:
> 1) _I think_ we don't want to depend on capable(CAP_SYS_NICE) but
>instead on capable(CAP_SYS_ADMIN)
>
>Does that make sense ?
Neither of them really makes sense to me.
The max clamp makes a task 'consume' less and you sh
On Fri, 14 Sep 2018, Jiri Kosina wrote:
> On Thu, 13 Sep 2018, Schaufler, Casey wrote:
>
> > > - return security_ptrace_access_check(task, mode);
> > > + if (!(mode & PTRACE_MODE_NOACCESS_CHK))
> > > + return security_ptrace_access_check(task, mode);
> > > + return 0;
> >
> > Because PTRA
Hi Kieran,
Thank you for the patch.
On Friday, 31 August 2018 21:12:57 EEST Kieran Bingham wrote:
> The R-Car Gen3 DU utilises the VSP1 hardware for memory access. The
> limits on the RPF and WPF in this pipeline are 8190x8190.
>
> Update the supported maximum sizes accordingly.
>
> Signed-off-
On Thu, 13 Sep 2018, Schaufler, Casey wrote:
> > - return security_ptrace_access_check(task, mode);
> > + if (!(mode & PTRACE_MODE_NOACCESS_CHK))
> > + return security_ptrace_access_check(task, mode);
> > + return 0;
>
> Because PTRACE_MODE_IBPB includes PTRACE_MODE_NOAUDIT you
>
From: Xin Lin <18650033...@163.com>
Adversaries often attack the Linux kernel via using
commit_creds(prepare_kernel_cred(0)) to submit ROOT
credential for the purpose of privilege escalation.
For processes inside the Linux container, the above
approach also works, because the container and the
hos
POSIX mandates that open fds and their associated file locks should be
preserved across an execve. This works, unless the process is
multithreaded at the time that execve is called.
In that case, we'll end up unsharing the files_struct but the locks will
still have their fl_owner set to the addres
Currently, we have a single refcount variable inside the files_struct.
When we go to unshare the files_struct, we check this counter and if
it's elevated, then we allocate a new files_struct instead of just
repurposing the old one, under the assumption that that indicates that
it's shared between t
In a later patch, we're going to move the unshare_files call in
__do_execve_file to later in the process, but this opens up a potential
race with clone(CLONE_FILES). We could end up bumping the refcount on
the files_struct after we've checked to see if it was shared. What we
really want to do in th
v2: fix displaced_files cleanup in __do_execve_file
v3: fix thread_count handling in unshare syscall
add new release_files_struct helper
The main difference from the earlier set is some cleanup and fixes for
the thread_count handling in the files_struct. The original looked a
bit more ugly wit
On Fri, Sep 14, 2018 at 11:50:15AM +0200, Rafael J. Wysocki wrote:
> On Thursday, August 9, 2018 5:39:25 PM CEST Lorenzo Pieralisi wrote:
> > On Mon, Aug 06, 2018 at 11:20:59AM +0200, Rafael J. Wysocki wrote:
> >
> > [...]
> >
> > > >>> > @@ -245,6 +248,56 @@ static bool always_on_power_down_ok(s
On Thu, Sep 13, 2018 at 05:59:45PM +0200, Thierry Reding wrote:
> Hi everyone,
>
> I've been trying to implement a feature on recent Tegra chips that's
> called "wake events".
By recent, is it same to assume PSCI based system ? And the GIC is power
managed by PSCI ?
--
Regards,
Sudeep
From: Harshit Jain
* This commit resolves the following warning when the mainline kernel is build
with the android environment.
-> warning :->
https://gist.github.com/dev-harsh1998/757427b16a58f5498db3d87212a9651b
* This warning is persistant in all the currently maintained android kernel i.e
On Fri, 14 Sep 2018, Yi Sun wrote:
> > > +static void hv_notify_long_spin_wait(void)
> > > +{
> > > + u64 input = spin_wait_info | 0x;
> >
> > What? The result is always 0x .
> >
> Oh, sorry for such error.
>
> > > + spin_wait_info++;
> > > + hv_do_fast_hyperc
On 2018/09/14 15:57, Sergey Senozhatsky wrote:
> On (09/13/18 23:28), Sergey Senozhatsky wrote:
>> Not that I see any problems with pr_line_flush(). But can drop it, sure.
>> pr_line() is a replacement for pr_cont() and as such it's not for multi-line
>> buffering.
>
> OK, attached.
> Let me know
On Thu, 13 Sep 2018, Thierry Reding wrote:
> I've been trying to implement a feature on recent Tegra chips that's
> called "wake events". These wake events are implemented as part of the
> power management controller (PMC) and they control which events can be
> used to wake the system from suspend.
On 9/11/18 11:27 AM, Marcel Ziswiler wrote:
On Fri, 2018-09-07 at 19:59 +0300, Dmitry Osipenko wrote:
- snip -
- With "cpufreq-info -f" I could only observe like the top 3-4 OPPs
while it does not to go further down even when idling. Why could
that
be resp. what could cause this?
What cpufre
On Thu, 13 Sep 2018 14:39:37 +0200
Peter Zijlstra wrote:
> On Thu, Sep 13, 2018 at 02:18:27PM +0200, Martin Schwidefsky wrote:
> > We may get something working with a common code mmu_gather, but I fear the
> > day someone makes a "minor" change to that subtly break s390. The debugging
> > of
> >
On 14/09/2018 12:13:39+0200, Romain Izard wrote:
> The specification for SAMA5D2 and SAMA5D4 chips, that use this IP for
> their watchdog timer, has the following advice regarding the Mode Register:
>
> "When setting the WDDIS bit, and while it is set, the fields WDV and WDD
> must not be modified
/commits/My-Name/kernel-prevent-submission-of-creds-with-higher-privileges-inside-container/20180914-164803
config: ia64-allnoconfig (attached as .config)
compiler: ia64-linux-gcc (GCC) 8.1.0
reproduce:
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin
The specification for SAMA5D2 and SAMA5D4 chips, that use this IP for
their watchdog timer, has the following advice regarding the Mode Register:
"When setting the WDDIS bit, and while it is set, the fields WDV and WDD
must not be modified."
I have observed on a board based on a SAMA5D2 chip that
A previous change of the sama5d4_wdt driver broke the device probing
with the device tree configuration described in existing DTS files,
when no value is set for the "timeout-sec" property.
Moreover, specifying any other value than 16 seconds for "timeout-sec"
leads to a watchdog reset immediately
When using watchdog_init_timeout to update the default timeout value,
an error means that there is no "timeout-sec" in the relevant device
tree node.
This should not prevent binding of the driver to the device.
Fixes: 976932e40036 ("watchdog: sama5d4: make use of timeout-secs provided in
devicet
Hi Kieran,
Thank you for the patch.
On Monday, 6 August 2018 17:39:02 EEST Kieran Bingham wrote:
> From: Kieran Bingham
>
> Add myself as a co-maintainer for the Renesas VSP driver.
>
> Signed-off-by: Kieran Bingham
Acked-by: Laurent Pinchart
and applied to my tree.
Thank you for your hel
do some checks on the label's length and ending.
Signed-off-by: Dongbo Cao
---
drivers/md/bcache/sysfs.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/md/bcache/sysfs.c b/drivers/md/bcache/sysfs.c
index e64c718f..cce793ef 100644
--- a/drivers/md/bcache/sysfs
On Fri, Sep 14, 2018 at 11:53 AM Mika Penttilä
wrote:
>
> On 09/14/2018 11:46 AM, Rafael J. Wysocki wrote:
> > On Friday, September 14, 2018 10:28:44 AM CEST Mika Penttilä wrote:
> >> Hi!
> >>
> >>
> >> On 09/14/2018 09:59 AM, Rafael J. Wysocki wrote:
> >>> From: Rafael J. Wysocki
> >>>
> >>> The
On 9/14/18 5:51 PM, Dongbo Cao wrote:
label interface will be called by bcache tools in user space.
Signed-off-by: Dongbo Cao
Hi Dongbo,
In your change I see you set superblock label to cache set. What is the
use case for doing this ?
Thanks.
Coly Li
---
drivers/md/bcache/sysfs.
--
Greetings,
I wish to seek your assistance for the transfer of US$35M depository
made by a politician for an investment programme that has
remained dormant for years now.I shall provide you with more details
and relevant documents that will help you understand the transaction.
Mr. Hama Dial
--
Greetings,
I wish to seek your assistance for the transfer of US$35M depository
made by a politician for an investment programme that has
remained dormant for years now.I shall provide you with more details
and relevant documents that will help you understand the transaction.
Mr. Hama Dial
On 09/14/2018 11:46 AM, Rafael J. Wysocki wrote:
> On Friday, September 14, 2018 10:28:44 AM CEST Mika Penttilä wrote:
>> Hi!
>>
>>
>> On 09/14/2018 09:59 AM, Rafael J. Wysocki wrote:
>>> From: Rafael J. Wysocki
>>>
>>> There is a difference in behavior between suspend-to-idle and
>>> suspend-to-R
On Thursday, August 9, 2018 5:39:25 PM CEST Lorenzo Pieralisi wrote:
> On Mon, Aug 06, 2018 at 11:20:59AM +0200, Rafael J. Wysocki wrote:
>
> [...]
>
> > >>> > @@ -245,6 +248,56 @@ static bool always_on_power_down_ok(struct
> > >>> > dev_pm_domain *domain)
> > >>> > return false;
> > >>> >
label interface will be called by bcache tools in user space.
Signed-off-by: Dongbo Cao
---
drivers/md/bcache/sysfs.c | 19 +++
1 file changed, 19 insertions(+)
diff --git a/drivers/md/bcache/sysfs.c b/drivers/md/bcache/sysfs.c
index 225b15aa..e64c718f 100644
--- a/drivers/md/bc
* Jiri Olsa wrote:
> On Fri, Sep 14, 2018 at 11:29:10AM +0900, Namhyung Kim wrote:
> > On Thu, Sep 13, 2018 at 07:10:35PM +0300, Alexey Budankov wrote:
> > > Hi,
> >
> > Hello,
> >
> > >
> > > On 13.09.2018 15:54, Jiri Olsa wrote:
> > > > hi,
> > > > sending *RFC* for threads support in perf
On 14.09.2018 11:28, Jiri Olsa wrote:
> On Fri, Sep 14, 2018 at 10:26:53AM +0200, Jiri Olsa wrote:
>
> SNIP
>
The threaded monitoring currently can't monitor backward maps
and there are probably more limitations which I haven't spotted
yet.
So far I tested on laptop:
* Namhyung Kim wrote:
> > > The perf.data stays as a single file.
>
> I'm not sure we really need to keep it as a single file. As it's a
> kind of big changes, we might consider breaking compatibility and use
> a directory structure.
Agreed - and to make use of the highly scalable Linux VFS
501 - 600 of 682 matches
Mail list logo
