On 10/19/2017 11:26 AM, Paul Durrant wrote:
> If the domain has XENFEAT_auto_translated_physmap then use of the PV-
> specific HYPERVISOR_mmu_update hypercall is clearly incorrect.
>
> This patch adds checks in xen_remap_domain_gfn_array() and
> xen_unmap_domain_gfn_array() which call through to th
From: Jiri Olsa
Adding the check wether the eBPF file exists, to consider it
as eBPF input file. This way we can differentiate eBPF events
from events that end up with same suffix as eBPF file.
Before:
$ perf stat -e 'cpu/uops_executed.core/' true
bpf: builtin compilation failed: -95, try
From: Taeung Song
'perf record' had a '-l' option that meant "scale counter values" a very
long time ago, but it currently belongs to 'perf stat' as '-c'. So
remove it. I found this problem in the below case.
$ perf record -e cycles -l sleep 3
Error: unknown switch `l
Signed-off-by:
From: Jin Yao
In current xyarray code, xyarray__max_x() returns max_y, and xyarray__max_y()
returns max_x.
It's confusing and for code logic it looks not correct.
Error happens when closing evsel fd. Let's see this scenario:
1. Allocate an fd (pseudo-code)
perf_evsel__alloc_fd(struct perf_e
From: Jiri Olsa
Make sure the struct perf_hpp_fmt is properly unhooked before we free
it.
Signed-off-by: Jiri Olsa
Cc: Andi Kleen
Cc: Changbin Du
Cc: David Ahern
Cc: Jin Yao
Cc: Namhyung Kim
Cc: Peter Zijlstra
Cc: Wang Nan
Link: http://lkml.kernel.org/r/20171013083736.15037-3-jo...@kerne
From: Li Zhijian
In debian/ubuntu, libc.so is located at a different place,
/lib/x86_64-linux-gnu/libc-2.23.so, so it outputs like this when testing:
PING ::1(::1) 56 data bytes
64 bytes from ::1: icmp_seq=1 ttl=64 time=0.040 ms
--- ::1 ping statistics ---
1 packets transmitted, 1 recei
From: Arnaldo Carvalho de Melo
Jiri and Namhyung have long contributed a lot of code and time reviewing
patches to tools/, so lets make that reflected in the MAINTAINERS file
to encourage patch submitters to add them to the CC list, speeding up
the process of tools/perf/ patch processing.
Acked-
On Thu, Oct 19, 2017 at 11:27:42AM +0100, Mark Rutland wrote:
> On Thu, Oct 19, 2017 at 11:07:25AM +0100, Will Deacon wrote:
> > On Tue, Oct 17, 2017 at 09:44:09AM -0700, Paul E. McKenney wrote:
> > > I am happy to take the patches, but let's make sure that I am up to
> > > speed on the current sta
From: Namhyung Kim
Thomas reported that 'perf buildid-list' gets a SEGFAULT due to NULL
pointer deref when he ran it on a data with namespace events. It was
because the buildid_id__mark_dso_hit_ops lacks the namespace event
handler and perf_too__fill_default() didn't set it.
Program received
On Wed, 2017-10-18 at 12:22 +0200, Roman Pen wrote:
> the patch below fixes queue stalling when shared hctx marked for restart
> (BLK_MQ_S_SCHED_RESTART bit) but q->shared_hctx_restart stays zero. The
> root cause is that hctxs are shared between queues, but 'shared_hctx_restart'
> belongs to the
From: Jiri Olsa
Du Changbin reported crash [1] when calling perf_hpp__reset_output_field()
after unregistering field via perf_hpp__column_unregister().
This ends up in calling following list_del* sequence on
the same format:
perf_hpp__column_unregister:
list_del(&format->list);
perf_hpp
On Thu, Oct 19, 2017 at 12:25 PM, Eric W. Biederman
wrote:
> Paul Moore writes:
>
>> On Wed, Oct 18, 2017 at 8:43 PM, Eric W. Biederman
>> wrote:
>>> Aleksa Sarai writes:
>> The security implications are that anything that can change the label
>> could also hide itself and its doings fr
On Thu, Oct 19, 2017 at 01:30:15PM -0400, Mathieu Desnoyers wrote:
> [ This patch is sent directly to Linus, because it needs to be merged
> before the end of 4.14 rc cycle. It introduces a "register private
> expedited" membarrier command which allows eventual removal of
> important memory b
acme/linux into perf/urgent
(2017-10-10 19:21:37 +0200)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux.git
tags/perf-urgent-for-mingo-4.14-20171019
for you to fetch changes up to 74f8e22c153f4464060a0c2e4cfd1d6e51af2109:
perf test s
This is intended to be variable and provided by the platform.
Some platforms this year will be adopting a 32k WMI buffer, so don't
complain when encountering those platforms or any other future changes.
Signed-off-by: Mario Limonciello
Reviewed-by: Edward O'Callaghan
---
drivers/platform/x86/de
Some cases the wrong type was used for errors and checks can be
done more cleanly.
Signed-off-by: Mario Limonciello
Reviewed-by: Edward O'Callaghan
Suggested-by: Andy Shevchenko
---
drivers/platform/x86/dell-wmi.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/d
For WMI operations that are only Set or Query readable and writable sysfs
attributes created by WMI vendor drivers or the bus driver makes sense.
For other WMI operations that are run on Method, there needs to be a
way to guarantee to userspace that the results from the method call
belong to the d
WSMT is as an attestation to the OS that the platform won't
modify memory outside of pre-defined areas.
If a platform has WSMT enabled in BIOS setup, SMM calls through
dcdbas will fail. The only way to access platform data in these
instances is through the WMI SMBIOS calling interface.
Signed-of
There is a lot of error checking in place for the format of the WMI
descriptor buffer, but some of the potentially raised issues should
be considered critical failures.
If the buffer size or header don't match, this is a good indication
that the buffer format changed in a way that the rest of the
It's important for the driver to provide a R/W ioctl to ensure that
two competing userspace processes don't race to provide or read each
others data.
This userspace character device will be used to perform SMBIOS calls
from any applications.
It provides an ioctl that will allow passing the WMI ca
The dell-smbios stack only currently uses an SMI interface which grants
direct access to physical memory to the firmware SMM methods via a pointer.
This dispatcher driver adds a WMI-ACPI interface that is detected by WMI
probe and preferred over the SMI interface in dell-smbios.
Changing this to
This application uses the character device /dev/wmi/dell-smbios
to perform SMBIOS communications from userspace.
It offers demonstrations of a few simple tasks:
- Running a class/select command
- Querying a token value
- Activating a token
Signed-off-by: Mario Limonciello
Reviewed-by: Edward
Currently userspace tools can access system tokens via the dcdbas
kernel module and a SMI call that will cause the platform to execute
SMM code.
With a goal in mind of deprecating the dcdbas kernel module a different
method for accessing these tokens from userspace needs to be created.
This is in
When a userspace interface is introduced to dell-smbios filtering
support will be used to make sure that userspace doesn't make calls
deemed unsafe or that can cause the kernel drivers to get out of
sync.
A blacklist is provided for the following:
- Items that are in use by other kernel drivers
-
This splits up the dell-smbios driver into two drivers:
* dell-smbios
* dell-smbios-smm
dell-smbios can operate with multiple different dispatcher drivers to
perform SMBIOS operations.
Also modify the interface that dell-laptop and dell-wmi use align to this
model more closely. Rather than a sin
The proper way to indicate that a system is a 'supported' Dell System
is by the presence of this string in OEM strings.
Allowing the driver to load on non-Dell systems will have undefined
results.
Signed-off-by: Mario Limonciello
Reviewed-by: Edward O'Callaghan
---
drivers/platform/x86/dell-sm
All communication on individual GUIDs should occur in separate drivers.
Allowing a driver to communicate with the bus to another GUID is just
a hack that discourages drivers to adopt the bus model.
The information found from the WMI descriptor driver is now exported
for use by other drivers.
Sign
The existing way that the dell-smbios helper module and associated
other drivers (dell-laptop, dell-wmi) communicate with the platform
really isn't secure. It requires creating a buffer in physical
DMA32 memory space and passing that to the platform via SMM.
Since the platform got a physical memo
Drivers properly using the wmibus can pass their wmi_device
pointer rather than the GUID back to the WMI bus to evaluate
the proper methods.
Any "new" drivers added that use the WMI bus should use this
rather than the old wmi_evaluate_method that would take the
GUID.
Signed-off-by: Mario Limoncie
The only driver using this was dell-wmi, and it really was a hack.
The driver was getting a data attribute from another driver and this
type of action should not be encouraged.
Rather drivers that need to interact with one another should pass
data back and forth via exported functions.
Signed-off
On Thursday 19 October 2017 12:50:06 Mario Limonciello wrote:
> Some cases the wrong type was used for errors and checks can be
> done more cleanly.
>
> Signed-off-by: Mario Limonciello
> Reviewed-by: Edward O'Callaghan
> Suggested-by: Andy Shevchenko
Reviewed-by: Pali Rohár
> ---
> drivers
On Thursday 19 October 2017 12:50:07 Mario Limonciello wrote:
> This is intended to be variable and provided by the platform.
> Some platforms this year will be adopting a 32k WMI buffer, so don't
> complain when encountering those platforms or any other future changes.
>
> Signed-off-by: Mario Li
[...]
>>> > Say you want to leave the parent suspended after system resume, but the
>>> > child drivers use pm_runtime_force_suspend|resume(). The parent would
>>> > then
>>> > need to use pm_runtime_force_suspend|resume() too, no?
>>>
>>> Actually no.
>>>
>>> Currently the other options of "def
On 10/19/17 07:29, Alan Tull wrote:
> On Wed, Oct 18, 2017 at 5:34 PM, Frank Rowand wrote:
>> On 10/18/17 13:16, Rob Herring wrote:
>>> Use devicetree-compiler list for dtc issues please.
>>>
>>> On Wed, Oct 18, 2017 at 2:33 PM, Frank Rowand
>>> wrote:
Hi Rob, Alan,
On 10/18/17 08
In preparation to enabling -Wimplicit-fallthrough, mark switch cases
where we are expecting to fall through.
Signed-off-by: Gustavo A. R. Silva
---
This code was tested by compilation only (GCC 7.2.0 was used).
Please, verify if the actual intention of the code is to fall through.
net/rose/rose
On 19 October 2017 at 19:21, Grygorii Strashko wrote:
>
>
> On 10/19/2017 03:33 AM, Ulf Hansson wrote:
>> On 18 October 2017 at 23:48, Rafael J. Wysocki wrote:
>>> On Wednesday, October 18, 2017 9:45:11 PM CEST Grygorii Strashko wrote:
On 10/18/2017 09:11 AM, Ulf Hansson wrote:
>>>
>>>
In preparation to enabling -Wimplicit-fallthrough, mark switch cases
where we are expecting to fall through.
Signed-off-by: Gustavo A. R. Silva
---
This code was tested by compilation only (GCC 7.2.0 was used).
Please, verify if the actual intention of the code is to fall through.
net/netrom/nr
On Thursday 19 October 2017 12:50:08 Mario Limonciello wrote:
> + priv->interface_version = buffer[2];
> + priv->size = buffer[3];
> + ret = 0;
> + dev_set_drvdata(&wdev->dev, priv);
> + list_add_tail(&priv->list, &wmi_list);
Still missing lock when changing wmi_list.
> +
> +
"(offset & 0x3) == 1" seems like an obfuscated way of writing the
predicate, is_mci_status_msr(msr). But other than that, this change
looks fine to me.
I'm a little more concerned about the code above. At the very least,
it needs to let the host set an arbitrary value for save/restore to
work.
Re
On Thursday 19 October 2017 12:50:14 Mario Limonciello wrote:
> +/* When enabled this indicates that SMM won't work */
> +static bool test_wsmt_enabled(void)
> +{
> + struct calling_interface_token *token;
> +
> + /* if token doesn't exist, SMM will work */
> + token = dell_smbios_find_
On 19 October 2017 at 20:04, Ulf Hansson wrote:
> On 19 October 2017 at 19:21, Grygorii Strashko
> wrote:
>>
>>
>> On 10/19/2017 03:33 AM, Ulf Hansson wrote:
>>> On 18 October 2017 at 23:48, Rafael J. Wysocki wrote:
On Wednesday, October 18, 2017 9:45:11 PM CEST Grygorii Strashko wrote:
>>
> -Original Message-
> From: Pali Rohár [mailto:pali.ro...@gmail.com]
> Sent: Thursday, October 19, 2017 1:09 PM
> To: Limonciello, Mario
> Cc: dvh...@infradead.org; Andy Shevchenko ;
> LKML ; platform-driver-...@vger.kernel.org; Andy
> Lutomirski ; quasi...@google.com; r...@rjwysocki.net;
On Mon, Oct 09, 2017 at 02:39:49PM -0700, Dawid Ciezarkiewicz wrote:
> On Sun, Oct 8, 2017 at 5:15 PM, Ram Pai wrote:
> >>
> >> One thing that I don't plan to use, but might be worth thinking about is
> >> `slave + RW + STICKY` combination. If `master` mounts something RO,
> >> and `slave`
> >>
On 2017-10-18 13:42:59 [-0700], Paul E. McKenney wrote:
>
> Builds for me on x86 and 0day test robot hasn't complained, but might
> as well get it right.
So I checked you tree and there is this:
|$ git one bc2eecd7ecce40af43b6eb3d256b6076257df846
|bc2eecd7ecce ("futex: Allow for compiling out PI
On Thu, Oct 19, 2017 at 09:51:04AM -0700, Andrei Vagin wrote:
> Hi,
>
> We run CRIU tests for tip/auto-latest regularly, and a few days ago our
> test job started to detect this warning in a kernel log:
>
> [ 44.235786] WARNING: can't dereference iret registers at 8801c5f17fe0
> for ip fff
Hi,
On 10/19/2017 09:41 AM, Greg KH wrote:
Meta-comments on the code, I'm not commenting on the content, just
normal code review things that I always see in kernel code...
On Wed, Oct 18, 2017 at 10:32:28PM +0200, Krzysztof Opasiak wrote:
diff --git a/include/linux/rlimit_noti_kern.h b/include
In preparation to enabling -Wimplicit-fallthrough, mark switch cases
where we are expecting to fall through.
Notice that in this particular case I placed a "fall through" comment on
its own line, which is what GCC is expecting to find.
Signed-off-by: Gustavo A. R. Silva
---
net/openvswitch/conn
On 10/19/2017 09:41 AM, Greg KH wrote:
On Wed, Oct 18, 2017 at 10:32:29PM +0200, Krzysztof Opasiak wrote:
Add rlimit-events call to process lifecycle to ensure that
we get notified whenever process dies (to cleanup our watch
levels) or forks (to implement watch levels inheritance).
Signed-off
Original Message
Subject: Re: [PATCH v2] dell-laptop: Fix keyboard led max_brightness
property for Dell Latitude E6410
From: Darren Hart
Date: Wed, October 18, 2017 3:00 pm
To: Pali Rohár
Cc: Matthew Garrett , Andy Shevchenko
, "Gabriel M. Elder" ,
Gabriele Mazzotta , mario.limo
On Thu, Oct 19, 2017 at 1:01 AM, Christoph Hellwig wrote:
> On Wed, Oct 18, 2017 at 08:51:37AM -0700, Dan Williams wrote:
>> This use case is not "Persistent Memory". Persistent Memory is
>> something you can map and make persistent with CPU instructions.
>> Anything that requires a driver call is
Hi Linus,
please pull three small but important fixes for the parisc architecture for
kernel 4.14 from:
git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux.git
parisc-4.14-3
Three small important fixes for the parisc architecture:
- Export __cmpxchg_u64() symbol on 32bit kerne
On 10/19/2017 12:57 AM, Gregory Fong wrote:
> Hi Doug,
>
> On Wed, Oct 04, 2017 at 02:24:37PM -0700, Doug Berger wrote:
>> On 10/03/2017 08:03 PM, Gregory Fong wrote:
>>> On Fri, Sep 29, 2017 at 8:40 PM, Doug Berger wrote:
The GPIOLIB IRQ chip helpers were very appealing, but badly broke
>>>
* Joonsoo Kim [171018 01:27]:
> On Mon, Sep 25, 2017 at 07:54:37AM -0700, Tony Lindgren wrote:
> > * Joonsoo Kim [170925 01:06]:
> > > On Thu, Sep 21, 2017 at 10:28:11AM -0700, Tony Lindgren wrote:
> > > > * Joonsoo Kim [170914 23:55]:
> > > > > On Wed, Sep 13, 2017 at 09:31:27AM -0700, Tony Lin
On Thursday 19 October 2017 11:20:35 Gabriel M. Elder wrote:
> I will be happy to test out whichever patch(es) present the most
> appropriate approach, as a matter of consensus.
>
> Would that be the PATCH v2
> (https://patchwork.kernel.org/patch/10015149/) that I should be testing?
Yes, v2.
--
Hi Marc,
On 10/19/2017 01:26 PM, Marc Kleine-Budde wrote:
On 10/19/2017 01:14 PM, Oliver Hartkopp wrote:
Since we have a netlink socket interface to configure sample point, I
wonder if that should be extended to configure SSP too (or at least the
offset part of SSP)?
+1 too
The struct can_b
On 10/19/2017 02:03 AM, Gregory Fong wrote:
> Hi Doug,
>
> Nice description of the problem with dealing with a pending disabled
> wake interrupt and the solution. A few remarks:
>
> On Fri, Sep 29, 2017 at 08:40:57PM -0700, Doug Berger wrote:
>> diff --git a/drivers/gpio/gpio-brcmstb.c b/drivers
On Thu, Oct 19, 2017 at 11:44:22AM +0200, Thierry Reding wrote:
> > > Below is the call trace of tegra210_init_pllu() function:
> > > start_kernel()
> > > -> time_init()
> > > --> of_clk_init()
> > > ---> tegra210_clock_init()
> > > > tegra210_pll_init()
> > > -> tegra210_init_p
Hi,
On Thu, Oct 19, 2017 at 1:32 AM, Arnd Bergmann wrote:
> We get a build error in the irqsoff tracer in some configurations:
>
> kernel/trace/trace_irqsoff.c: In function 'trace_preempt_on':
> kernel/trace/trace_irqsoff.c:855:2: error: implicit declaration of function
> 'trace_preempt_enable_r
Build errors have been reported with CONFIG_PM=n:
drivers/net/wireless/ath/ath10k/pci.c:3416:8: error: implicit
declaration of function 'ath10k_pci_suspend'
[-Werror=implicit-function-declaration]
drivers/net/wireless/ath/ath10k/pci.c:3428:8: error: implicit
declaration of function 'ath10k_pci_re
On Thu, Oct 19, 2017 at 04:59:21AM -0700, Vadim Lomovtsev wrote:
> On Thu, Oct 19, 2017 at 06:26:45AM -0500, Bjorn Helgaas wrote:
> > On Tue, Oct 17, 2017 at 05:47:37AM -0700, Vadim Lomovtsev wrote:
> > > From: Vadim Lomovtsev
> > >
> > > version 7:
> > > - update patch description accordingly to
In preparation to enabling -Wimplicit-fallthrough, mark switch cases
where we are expecting to fall through.
Signed-off-by: Gustavo A. R. Silva
---
This code was tested by compilation only (GCC 7.2.0 was used).
Please, verify if the actual intention of the code is to fall through.
net/rxrpc/af_
Document the cgroup-aware OOM killer.
Signed-off-by: Roman Gushchin
Acked-by: Johannes Weiner
Cc: Michal Hocko
Cc: Vladimir Davydov
Cc: Tetsuo Handa
Cc: Andrew Morton
Cc: David Rientjes
Cc: Tejun Heo
Cc: kernel-t...@fb.com
Cc: cgro...@vger.kernel.org
Cc: linux-...@vger.kernel.org
Cc: linux
This patchset makes the OOM killer cgroup-aware.
v12:
- Root memory cgroup is evaluated based on sum of the oom scores
of belonging tasks
- Do not fallback to the per-process behavior if there if
it wasn't possbile to kill a memcg victim
- Rebase on top of mm tree
v11:
- Fixed an
The oom_kill_process() function consists of two logical parts:
the first one is responsible for considering task's children as
a potential victim and printing the debug information.
The second half is responsible for sending SIGKILL to all
tasks sharing the mm struct with the given victim.
This co
Add a "groupoom" cgroup v2 mount option to enable the cgroup-aware
OOM killer. If not set, the OOM selection is performed in
a "traditional" per-process way.
The behavior can be changed dynamically by remounting the cgroupfs.
Signed-off-by: Roman Gushchin
Cc: Michal Hocko
Cc: Vladimir Davydov
Implement mem_cgroup_scan_tasks() functionality for the root
memory cgroup to use this function for looking for a OOM victim
task in the root memory cgroup by the cgroup-ware OOM killer.
The root memory cgroup is treated as a leaf cgroup, so only tasks
which are directly belonging to the root cgro
Traditionally, the OOM killer is operating on a process level.
Under oom conditions, it finds a process with the highest oom score
and kills it.
This behavior doesn't suit well the system with many running
containers:
1) There is no fairness between containers. A small container with
few large pr
On 10/18, Chao Yu wrote:
> On 2017/10/18 0:41, Jaegeuk Kim wrote:
> > On 10/17, Chao Yu wrote:
> >> On 2017/10/17 7:06, Jaegeuk Kim wrote:
> >>> This patch fixes recovering incomplete xattr entries remaining in inline
> >>> xattr
> >>> and xattr block, caused by any kind of errors.
> >>>
> >>> Sig
On Wed 19 Jul 08:59 PDT 2017, Philipp Zabel wrote:
> From: Vivek Gautam
>
> Many devices may want to request a bunch of resets and control them. So
> it's better to manage them as an array. Add APIs to _get() an array of
> reset_control, reusing the _assert(), _deassert(), and _reset() APIs for
The cgroup-aware OOM killer treats leaf memory cgroups as memory
consumption entities and performs the victim selection by comparing
them based on their memory footprint. Then it kills the biggest task
inside the selected memory cgroup.
But there are workloads, which are not tolerant to a such beh
On Sun, 15 Oct 2017 11:24:08 +0200
Julia Lawall wrote:
> There is no Coccinelle version 1.2. 1.0.2 must be what was intended.
>
> Signed-off-by: Julia Lawall
Applied, thanks.
jon
>>> Something like:
>>>
>>> "because there is a dump_stack() done on allocation failures
>>> without __GFP_JNOWARN"
>>
>> How do you think about to convert such a description into a special format
>> for further reference documentation?
>
> I think it's a bad idea if it's a "special" format.
Wil
On Thu, 12 Oct 2017 15:23:26 -0500
Tom Saeger wrote:
> Batch (2) set of simple document ref fixes.
>
>
> Tom Saeger (8):
> Documentation: fix locking rt-mutex doc refs
> Documentation: fix ref to sphinx/kerneldoc.py
> Documentation: fix ref to workqueue content
> Documentation: fix ref
Bart,
On Thu, 19 Oct 2017, Bart Van Assche wrote:
> It seems like you are missing my point.
That might be a perception problem.
> Cross-release checking is really *broken* as a concept. It is impossible
> to improve it to the same reliability level as the kernel v4.13 lockdep
> code. Hence my
On Tue, Oct 17, 2017 at 6:36 PM, wrote:
> static int overlay_notify(struct overlay_changeset *ovcs,
> enum of_overlay_notify_action action)
> {
> @@ -86,8 +109,14 @@ static int overlay_notify(struct overlay_changeset *ovcs,
>
> ret = blocking_notifier_call_chain
On Mon, 16 Oct 2017 16:32:51 -0700
Randy Dunlap wrote:
> There are some good comments about bitmap operations in lib/bitmap.c
> and include/linux/bitmap.h, so format them for document generation and
> pull them into core-api/kernel-api.rst.
>
> I converted the "tables" of functions from using ta
Sorry for the delay. A couple questions:
On Wed, Sep 27, 2017 at 2:42 PM, Rob Herring wrote:
> On Tue, Sep 19, 2017 at 03:40:00PM -0700, Brendan Higgins wrote:
>> Add a common device tree for all Nuvoton NPCM750 BMCs and a board
>> specific device tree for the NPCM750 (Poleg) evaluation board.
>>
On 10/18, Chao Yu wrote:
> On 2017/10/18 2:17, Jaegeuk Kim wrote:
> > On 10/17, Chao Yu wrote:
> >>
> >>
> >> On 2017/10/17 7:04, Jaegeuk Kim wrote:
> >>> On 10/16, Chao Yu wrote:
> Hi Jaegeuk,
>
> On 2017/10/13 7:15, Jaegeuk Kim wrote:
> > This patch returns an error number to q
On Mon, 16 Oct 2017 16:02:25 -0700
Kees Cook wrote:
> In preparation for unconditionally passing the struct timer_list pointer to
> all timer callbacks, switch to using the new timer_setup() and from_timer()
> to pass the timer pointer explicitly.
>
> Signed-off-by: Kees Cook
Argh, so I'm the
On Thu, 19 Oct 2017, Thomas Gleixner wrote:
> That's not a lockdep problem and neither can the pure locking dependency
> tracking know that a particular deadlock is not possible by design. It can
> merily record the dependency chains and detect circular dependencies.
>
> There is enough code which
On 10/18, Chao Yu wrote:
> On 2017/10/18 6:03, Jaegeuk Kim wrote:
> > On 10/16, Chao Yu wrote:
> >> On 2017/10/14 1:31, Jaegeuk Kim wrote:
> >>> If there's some data written through inline data or dentry, we need to
> >>> shouw
> >>> st_blocks. This fixes reporting zero blocks even though there is
- Add a struct containing two pointer to extents and wrap both the static extent
array and the struct into a union. This is done in preparation for bumping the
{g,u}idmap limits for user namespaces.
- Add brackets around anonymous union when using designated initializers to
initialize members
This patch fix the following build warning:
drivers/clk/sunxi/clk-factors.c:279:14: warning: variable 'name' set but not
used [-Wunused-but-set-variable]
Signed-off-by: Corentin Labbe
---
drivers/clk/sunxi/clk-factors.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/clk/sunxi/clk-
There are quite some use cases where users run into the current limit for
{g,u}id mappings. Consider a user requesting us to map everything but 999, and
1001 for a given range of 10 with a sub{g,u}id layout of:
some-user:10:10
some-user:999:1
some-user:1000:1
some-user:1001:1
s
On Thu, Oct 19, 2017 at 3:18 AM, Kirill A. Shutemov
wrote:
> On Wed, Oct 18, 2017 at 04:17:30PM -0700, Shakeel Butt wrote:
>> Recently we have observed high latency in mlock() in our generic
>> library and noticed that users have started using tmpfs files even
>> without swap and the latency was d
On Thu, Oct 19, 2017 at 5:32 AM, Michal Hocko wrote:
> On Wed 18-10-17 16:17:30, Shakeel Butt wrote:
>> Recently we have observed high latency in mlock() in our generic
>> library and noticed that users have started using tmpfs files even
>> without swap and the latency was due to expensive remote
On Wed, Oct 18, 2017 at 11:24 PM, Anshuman Khandual
wrote:
> On 10/19/2017 04:47 AM, Shakeel Butt wrote:
>> Recently we have observed high latency in mlock() in our generic
>> library and noticed that users have started using tmpfs files even
>> without swap and the latency was due to expensive re
On 10/19/17 12:04, Alan Tull wrote:
> On Tue, Oct 17, 2017 at 6:36 PM, wrote:
>
>> static int overlay_notify(struct overlay_changeset *ovcs,
>> enum of_overlay_notify_action action)
>> {
>> @@ -86,8 +109,14 @@ static int overlay_notify(struct overlay_changeset *ovcs,
>>
>>
HI Thierry,
> On Fri, Sep 08, 2017 at 11:43:02AM +0200, Lukasz Majewski wrote:
> > This commit adds support for Mitsubishi aa070mc01 TFT panel working
> > with 8 bit ISP mode (pin 19 "mode" HIGH for 20 pin TFT connector).
> >
> > Signed-off-by: Lukasz Majewski
> > ---
> > drivers/gpu/drm/panel/
Currently, it is possible to mmap any offset from /dev/mem. If a
program mmaps() /dev/mem offsets outside of the addressable limits
of a system, the page table is corrupted by setting some reserved
bits.
If you mmap offset 0x0001 of /dev/mem on an x86_64 with
a 48-bit bus, the page fa
On Thu 19-10-17 19:52:15, Roman Gushchin wrote:
> Traditionally, the OOM killer is operating on a process level.
> Under oom conditions, it finds a process with the highest oom score
> and kills it.
>
> This behavior doesn't suit well the system with many running
> containers:
>
> 1) There is no
On Thu 19-10-17 12:19:26, Shakeel Butt wrote:
> On Thu, Oct 19, 2017 at 5:32 AM, Michal Hocko wrote:
> > On Wed 18-10-17 16:17:30, Shakeel Butt wrote:
> >> Recently we have observed high latency in mlock() in our generic
> >> library and noticed that users have started using tmpfs files even
> >>
On 09/05/2017 11:08 AM, Jack Henschel wrote:
> This patch improves the error message of the perf events parser
> when the PMU hardware does not support address filters.
>
> Previously, the perf returned the following error:
>> --filter option should follow a -e tracepoint or HW tracer option
> Thi
HugePages support is enabled on ARM64 and x86. On ARM32 we have support
for HugePages since kernel 3.11 [1]. Let's enable it on ARM32 too, as
it's needed for some projects like DPDK [2], LTP [3], etc. The similar
change was done in commit 74d2eb3cdb7b ("arm64: defconfig: enable a few
more common/us
On Thu, Oct 19, 2017 at 07:52:12PM +0100, Roman Gushchin wrote:
> This patchset makes the OOM killer cgroup-aware.
Hi Andrew,
I believe this code is ready for merging upstream, and it seems Michal
is in agreement. There are two main things to consider, however.
David would have really liked for
> [...]
>>
>> Sorry for the confusion. I wanted to say that if the pages which are
>> being mlocked are on caches of remote cpus then lru_add_drain_all will
>> move them to their corresponding LRUs and then remaining functionality
>> of mlock will move them again from their evictable LRUs to unevic
On Thu, Oct 19, 2017 at 08:15:05PM +0200, Sebastian Andrzej Siewior wrote:
> On 2017-10-18 13:42:59 [-0700], Paul E. McKenney wrote:
> >
> > Builds for me on x86 and 0day test robot hasn't complained, but might
> > as well get it right.
>
> So I checked you tree and there is this:
>
> |$ git one
On 10/19/2017 08:35 PM, Oliver Hartkopp wrote:
> Hi Marc,
>
> On 10/19/2017 01:26 PM, Marc Kleine-Budde wrote:
>> On 10/19/2017 01:14 PM, Oliver Hartkopp wrote:
>>> Since we have a netlink socket interface to configure sample
>>> point, I
>>> wonder if that should be extended to config
Em Thu, Oct 19, 2017 at 09:37:13PM +0200, Jack Henschel escreveu:
> On 09/05/2017 11:08 AM, Jack Henschel wrote:
> > This patch improves the error message of the perf events parser
> > when the PMU hardware does not support address filters.
> >
> > Previously, the perf returned the following error
On Wed, Aug 23, 2017 at 7:03 AM, Richard Guy Briggs wrote:
> Tracefs or debugfs were causing hundreds to thousands of PATH records to
> be associated with the init_module and finit_module SYSCALL records on a
> few modules when the following rule was in place for startup:
> -a always,exit
801 - 900 of 1278 matches
Mail list logo
