* Re: [PATCH v7 3/6] mm: Introduce VM_LOCKONFAULT
From: Konstantin Khlebnikov @ 2015-08-25 13:58 UTC (permalink / raw)
To: Michal Hocko
Cc: Eric B Munson, Andrew Morton, Vlastimil Babka, Jonathan Corbet,
Kirill A. Shutemov, Linux Kernel Mailing List, dri-devel,
linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org, Linux API
In-Reply-To: <20150825134154.GB6285-2MMpYkNvuYDjFM9bn6wA6Q@public.gmane.org>
On Tue, Aug 25, 2015 at 4:41 PM, Michal Hocko <mhocko-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote:
> On Fri 21-08-15 14:31:32, Eric B Munson wrote:
> [...]
>> I am in the middle of implementing lock on fault this way, but I cannot
>> see how we will hanlde mremap of a lock on fault region. Say we have
>> the following:
>>
>> addr = mmap(len, MAP_ANONYMOUS, ...);
>> mlock(addr, len, MLOCK_ONFAULT);
>> ...
>> mremap(addr, len, 2 * len, ...)
>>
>> There is no way for mremap to know that the area being remapped was lock
>> on fault so it will be locked and prefaulted by remap. How can we avoid
>> this without tracking per vma if it was locked with lock or lock on
>> fault?
>
> Yes mremap is a problem and it is very much similar to mmap(MAP_LOCKED).
> It doesn't guarantee the full mlock semantic because it leaves partially
> populated ranges behind without reporting any error.
>
> Considering the current behavior I do not thing it would be terrible
> thing to do what Konstantin was suggesting and populate only the full
> ranges in a best effort mode (it is done so anyway) and document the
> behavior properly.
> "
> If the memory segment specified by old_address and old_size is
> locked (using mlock(2) or similar), then this lock is maintained
> when the segment is resized and/or relocated. As a consequence,
> the amount of memory locked by the process may change.
>
> If the range is already fully populated and the range is
> enlarged the new range is attempted to be fully populated
> as well to preserve the full mlock semantic but there is no
> guarantee this will succeed. Partially populated (e.g. created by
> mlock(MLOCK_ONFAULT)) ranges do not have the full mlock semantic
> so they are not populated on resize.
> "
>
> So what we have as a result is that partially populated ranges are
> preserved and fully populated ones work in the best effort mode the same
> way as they are now.
>
> Does that sound at least remotely reasonably?
The problem is that mremap have to scan ptes to detect that and old behaviour
becomes very fragile: one fail and mremap will never populate that vma again.
For now I think new flag "MREMAP_NOPOPULATE" is a better option.
>
>
> --
> Michal Hocko
> SUSE Labs
>
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majordomo-Bw31MaZKKs0EbZ0PF+XxCw@public.gmane.org For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: <a href=mailto:"dont-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org"> email-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org </a>
^ permalink raw reply
* Re: [PATCH v7 3/6] mm: Introduce VM_LOCKONFAULT
From: Eric B Munson @ 2015-08-25 14:29 UTC (permalink / raw)
To: Michal Hocko
Cc: Andrew Morton, Vlastimil Babka, Jonathan Corbet,
Kirill A. Shutemov, linux-kernel, dri-devel, linux-mm, linux-api
In-Reply-To: <20150825134154.GB6285@dhcp22.suse.cz>
[-- Attachment #1: Type: text/plain, Size: 2482 bytes --]
On Tue, 25 Aug 2015, Michal Hocko wrote:
> On Fri 21-08-15 14:31:32, Eric B Munson wrote:
> [...]
> > I am in the middle of implementing lock on fault this way, but I cannot
> > see how we will hanlde mremap of a lock on fault region. Say we have
> > the following:
> >
> > addr = mmap(len, MAP_ANONYMOUS, ...);
> > mlock(addr, len, MLOCK_ONFAULT);
> > ...
> > mremap(addr, len, 2 * len, ...)
> >
> > There is no way for mremap to know that the area being remapped was lock
> > on fault so it will be locked and prefaulted by remap. How can we avoid
> > this without tracking per vma if it was locked with lock or lock on
> > fault?
>
> Yes mremap is a problem and it is very much similar to mmap(MAP_LOCKED).
> It doesn't guarantee the full mlock semantic because it leaves partially
> populated ranges behind without reporting any error.
This was not my concern. Instead, I was wondering how to keep lock on
fault sematics with mremap if we do not have a VMA flag. As a user, it
would surprise me if a region I mlocked with lock on fault and then
remapped to a larger size was fully populated and locked by the mremap
call.
>
> Considering the current behavior I do not thing it would be terrible
> thing to do what Konstantin was suggesting and populate only the full
> ranges in a best effort mode (it is done so anyway) and document the
> behavior properly.
> "
> If the memory segment specified by old_address and old_size is
> locked (using mlock(2) or similar), then this lock is maintained
> when the segment is resized and/or relocated. As a consequence,
> the amount of memory locked by the process may change.
>
> If the range is already fully populated and the range is
> enlarged the new range is attempted to be fully populated
> as well to preserve the full mlock semantic but there is no
> guarantee this will succeed. Partially populated (e.g. created by
> mlock(MLOCK_ONFAULT)) ranges do not have the full mlock semantic
> so they are not populated on resize.
> "
You are proposing that mremap would scan the PTEs as Vlastimil has
suggested?
>
> So what we have as a result is that partially populated ranges are
> preserved and fully populated ones work in the best effort mode the same
> way as they are now.
>
> Does that sound at least remotely reasonably?
>
>
> --
> Michal Hocko
> SUSE Labs
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH v7 3/6] mm: Introduce VM_LOCKONFAULT
From: Michal Hocko @ 2015-08-25 14:29 UTC (permalink / raw)
To: Vlastimil Babka
Cc: Eric B Munson, Andrew Morton, Jonathan Corbet, Kirill A. Shutemov,
linux-kernel, dri-devel, linux-mm, linux-api
In-Reply-To: <55DC73E2.6050509@suse.cz>
On Tue 25-08-15 15:55:46, Vlastimil Babka wrote:
> On 08/25/2015 03:41 PM, Michal Hocko wrote:
[...]
> >So what we have as a result is that partially populated ranges are
> >preserved and fully populated ones work in the best effort mode the same
> >way as they are now.
> >
> >Does that sound at least remotely reasonably?
>
> I'll basically repeat what I said earlier:
>
> - mremap scanning existing pte's to figure out the population would slow it
> down for no good reason
So do we really need to populate the enlarged range? All the man page is
saying is that the lock is maintained. Which will be still the case. It
is true that the failure is unlikely (unless you are running in the
memcg) but you cannot rely on the full mlock semantic so what would be a
problem?
> - it would be unreliable anyway:
> - example: was the area completely populated because MLOCK_ONFAULT was not
> used or because the process faulted it already
OK, I see this as being a problem. Especially if the buffer is increase
2*original_len
> - example: was the area not completely populated because MLOCK_ONFAULT was
> used, or because mmap(MAP_LOCKED) failed to populate it fully?
What would be the difference? Both are ONFAULT now.
> I think the first point is a pointless regression for workloads that use
> just plain mlock() and don't want the onfault semantics. Unless there's some
> shortcut? Does vma have a counter of how much is populated? (I don't think
> so?)
--
Michal Hocko
SUSE Labs
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [PATCH RFC] watchdog: Add watchdog device control through sysfs attributes
From: Pratyush Anand @ 2015-08-25 16:45 UTC (permalink / raw)
To: linux-0h96xk9xTtrk1uMJSBkQmQ
Cc: linux-watchdog-u79uwXL29TY76Z2rM5mHXA,
dyoung-H+wXaHxf7aLQT0dZR+AlfA, dzickus-H+wXaHxf7aLQT0dZR+AlfA,
open list:ABI/API, open list, Wim Van Sebroeck
In-Reply-To: <d9ac417a3bc1c6846f1ddfcd3cd07e5a92865c19.1440179209.git.panand-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
Hi Guenter,
On 21/08/2015:11:18:12 PM, Pratyush Anand wrote:
> This patch adds following attributes to watchdog device's sysfs interface.
Please see if you can review it.
Does this patch look fine to you? If yes then do I need to resend it by removing
RFC tag.
~Pratyush
--
To unsubscribe from this list: send the line "unsubscribe linux-watchdog" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v9 0/3] Enable PPI sysfs interface for TPM 2.0
From: Jarkko Sakkinen @ 2015-08-25 17:03 UTC (permalink / raw)
To: Jarkko Sakkinen
Cc: tpmdd-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, peterhuewe-Mmb7MZpHnFY,
gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r,
jgunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/, Eric W. Biederman,
Guenter Roeck, open list:ABI/API, NeilBrown, Tejun Heo
In-Reply-To: <1439388347-22325-1-git-send-email-jarkko.sakkinen-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
Does this start be in the shape that there would be chance to pull this
in at some point? To be able to enable TPM 2.0 chips from Linux is quite
mandatory feature in my opinion.
Thank you.
/Jarkko
On Wed, Aug 12, 2015 at 05:05:40PM +0300, Jarkko Sakkinen wrote:
> v9:
> * Fixed naming for __compat_only_sysfs_link_entry_to_kobj()
>
> v8:
> * Renamed sysfs_link_entry_to_kobj() to
> __compat_only_sysfs_link_entry_to_kobj()
>
> v7:
> * Fixed compile error when CONFIG_SYSFS is not enabled.
>
> v6:
> * Updated documentation.
>
> v5:
> * Removed dangling export of kernfs_remove_by_name_ns() from the sysfs
> patch.
>
> v4:
> * Use sysfs_remove_link()
>
> v3:
> * Fixed to_tpm_chip() macro.
> * Split into two patches.
> * Renamed sysfs_link_group_to_kobj to sysfs_link_entry_to_kobj
> * Only create the "backwards compatibility" symlink for TPM 1.x devices.
>
> Jarkko Sakkinen (3):
> sysfs: added __compat_only_sysfs_link_entry_to_kobj()
> tpm: move the PPI attributes to character device directory.
> tpm: update PPI documentation to address the location change.
>
> Documentation/ABI/testing/sysfs-driver-ppi | 19 ++++++++-----
> drivers/char/tpm/tpm-chip.c | 24 ++++++++++------
> drivers/char/tpm/tpm.h | 17 ++++--------
> drivers/char/tpm/tpm_ppi.c | 34 ++++++++---------------
> fs/sysfs/group.c | 44 ++++++++++++++++++++++++++++++
> include/linux/sysfs.h | 11 ++++++++
> 6 files changed, 100 insertions(+), 49 deletions(-)
>
> --
> 2.5.0
>
^ permalink raw reply
* Re: [PATCH v9 0/3] Enable PPI sysfs interface for TPM 2.0
From: Peter Huewe @ 2015-08-25 17:20 UTC (permalink / raw)
To: Jarkko Sakkinen, Jarkko Sakkinen
Cc: tpmdd-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r,
jgunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/, Eric W. Biederman,
Guenter Roeck, open list:ABI/API, NeilBrown, Tejun Heo
In-Reply-To: <20150825170327.GA23185-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
Will look at it as soon as possible - relocating to the us is quite stressful.sorry about that.
But since we are already at v9 i think it is in a good shape.
Peter
Am 25. August 2015 19:03:27 MESZ, schrieb Jarkko Sakkinen <jarkko.sakkinen-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>:
>Does this start be in the shape that there would be chance to pull this
>in at some point? To be able to enable TPM 2.0 chips from Linux is
>quite
>mandatory feature in my opinion.
>
>Thank you.
>
>/Jarkko
>
>On Wed, Aug 12, 2015 at 05:05:40PM +0300, Jarkko Sakkinen wrote:
>> v9:
>> * Fixed naming for __compat_only_sysfs_link_entry_to_kobj()
>>
>> v8:
>> * Renamed sysfs_link_entry_to_kobj() to
>> __compat_only_sysfs_link_entry_to_kobj()
>>
>> v7:
>> * Fixed compile error when CONFIG_SYSFS is not enabled.
>>
>> v6:
>> * Updated documentation.
>>
>> v5:
>> * Removed dangling export of kernfs_remove_by_name_ns() from the
>sysfs
>> patch.
>>
>> v4:
>> * Use sysfs_remove_link()
>>
>> v3:
>> * Fixed to_tpm_chip() macro.
>> * Split into two patches.
>> * Renamed sysfs_link_group_to_kobj to sysfs_link_entry_to_kobj
>> * Only create the "backwards compatibility" symlink for TPM 1.x
>devices.
>>
>> Jarkko Sakkinen (3):
>> sysfs: added __compat_only_sysfs_link_entry_to_kobj()
>> tpm: move the PPI attributes to character device directory.
>> tpm: update PPI documentation to address the location change.
>>
>> Documentation/ABI/testing/sysfs-driver-ppi | 19 ++++++++-----
>> drivers/char/tpm/tpm-chip.c | 24 ++++++++++------
>> drivers/char/tpm/tpm.h | 17 ++++--------
>> drivers/char/tpm/tpm_ppi.c | 34
>++++++++---------------
>> fs/sysfs/group.c | 44
>++++++++++++++++++++++++++++++
>> include/linux/sysfs.h | 11 ++++++++
>> 6 files changed, 100 insertions(+), 49 deletions(-)
>>
>> --
>> 2.5.0
>>
--
Sent from my mobile
^ permalink raw reply
* Re: [PATCH v7 3/6] mm: Introduce VM_LOCKONFAULT
From: Michal Hocko @ 2015-08-25 18:58 UTC (permalink / raw)
To: Eric B Munson
Cc: Andrew Morton, Vlastimil Babka, Jonathan Corbet,
Kirill A. Shutemov, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
linux-mm-Bw31MaZKKs3YtjvyW6yDsg, linux-api-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20150825142902.GF17005-JqFfY2XvxFXQT0dZR+AlfA@public.gmane.org>
On Tue 25-08-15 10:29:02, Eric B Munson wrote:
> On Tue, 25 Aug 2015, Michal Hocko wrote:
[...]
> > Considering the current behavior I do not thing it would be terrible
> > thing to do what Konstantin was suggesting and populate only the full
> > ranges in a best effort mode (it is done so anyway) and document the
> > behavior properly.
> > "
> > If the memory segment specified by old_address and old_size is
> > locked (using mlock(2) or similar), then this lock is maintained
> > when the segment is resized and/or relocated. As a consequence,
> > the amount of memory locked by the process may change.
> >
> > If the range is already fully populated and the range is
> > enlarged the new range is attempted to be fully populated
> > as well to preserve the full mlock semantic but there is no
> > guarantee this will succeed. Partially populated (e.g. created by
> > mlock(MLOCK_ONFAULT)) ranges do not have the full mlock semantic
> > so they are not populated on resize.
> > "
>
> You are proposing that mremap would scan the PTEs as Vlastimil has
> suggested?
As Vlastimil pointed out this would be unnecessarily too costly. But I
am wondering whether we should populate at all during mremap considering
the full mlock semantic is not guaranteed anyway. Man page mentions only
that the lock is maintained which will be true without population as
well.
If somebody really depends on the current (and broken) implementation we
can offer MREMAP_POPULATE which would do a best effort population. This
would be independent on the locked state and would be usable for other
mappings as well (the usecase would be to save page fault overhead by
batching them).
If this would be seen as an unacceptable user visible change of behavior
then we can go with the VMA flag but I would still prefer to not export
it to the userspace so that we have a way to change this in future.
--
Michal Hocko
SUSE Labs
^ permalink raw reply
* Re: [PATCH v7 3/6] mm: Introduce VM_LOCKONFAULT
From: Eric B Munson @ 2015-08-25 19:03 UTC (permalink / raw)
To: Michal Hocko
Cc: Andrew Morton, Vlastimil Babka, Jonathan Corbet,
Kirill A. Shutemov, linux-kernel, dri-devel, linux-mm, linux-api
In-Reply-To: <20150825185829.GA10222@dhcp22.suse.cz>
[-- Attachment #1: Type: text/plain, Size: 2708 bytes --]
On Tue, 25 Aug 2015, Michal Hocko wrote:
> On Tue 25-08-15 10:29:02, Eric B Munson wrote:
> > On Tue, 25 Aug 2015, Michal Hocko wrote:
> [...]
> > > Considering the current behavior I do not thing it would be terrible
> > > thing to do what Konstantin was suggesting and populate only the full
> > > ranges in a best effort mode (it is done so anyway) and document the
> > > behavior properly.
> > > "
> > > If the memory segment specified by old_address and old_size is
> > > locked (using mlock(2) or similar), then this lock is maintained
> > > when the segment is resized and/or relocated. As a consequence,
> > > the amount of memory locked by the process may change.
> > >
> > > If the range is already fully populated and the range is
> > > enlarged the new range is attempted to be fully populated
> > > as well to preserve the full mlock semantic but there is no
> > > guarantee this will succeed. Partially populated (e.g. created by
> > > mlock(MLOCK_ONFAULT)) ranges do not have the full mlock semantic
> > > so they are not populated on resize.
> > > "
> >
> > You are proposing that mremap would scan the PTEs as Vlastimil has
> > suggested?
>
> As Vlastimil pointed out this would be unnecessarily too costly. But I
> am wondering whether we should populate at all during mremap considering
> the full mlock semantic is not guaranteed anyway. Man page mentions only
> that the lock is maintained which will be true without population as
> well.
>
> If somebody really depends on the current (and broken) implementation we
> can offer MREMAP_POPULATE which would do a best effort population. This
> would be independent on the locked state and would be usable for other
> mappings as well (the usecase would be to save page fault overhead by
> batching them).
>
> If this would be seen as an unacceptable user visible change of behavior
> then we can go with the VMA flag but I would still prefer to not export
> it to the userspace so that we have a way to change this in future.
Would you drop your objections to the VMA flag if I drop the portions of
the patch that expose it to userspace?
The rework to not use the VMA flag is pretty sizeable and is much more
ugly IMO. I know that you are not wild about using bit 30 of 32 for
this, but perhaps we can settle on not exporting it to userspace so we
can reclaim it if we really need it in the future? I can teach the
folks here to check for size vs RSS of the locked mappings for stats on
lock on fault usage so from my point of view, the proc changes are not
necessary.
> --
> Michal Hocko
> SUSE Labs
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* [PATCH v6 0/6] support "task_isolated" mode for nohz_full
From: Chris Metcalf @ 2015-08-25 19:55 UTC (permalink / raw)
To: Gilad Ben Yossef, Steven Rostedt, Ingo Molnar, Peter Zijlstra,
Andrew Morton, Rik van Riel, Tejun Heo, Frederic Weisbecker,
Thomas Gleixner, Paul E. McKenney, Christoph Lameter,
Viresh Kumar, Catalin Marinas, Will Deacon, linux-doc, linux-api,
linux-kernel
Cc: Chris Metcalf
In-Reply-To: <1438112980-9981-1-git-send-email-cmetcalf@ezchip.com>
The cover email for the patch series is getting a little unwieldy
so I will provide a terser summary here, and just update the
list of changes from version to version. Please see the previous
versions linked by the In-Reply-To for more detailed comments
about changes in earlier versions of the patch series.
v6:
restructured to be a "task_isolation" mode not a "cpu_isolated"
mode (Frederic)
v5:
rebased on kernel v4.2-rc3
converted to use CONFIG_CPU_ISOLATED and separate .c and .h files
incorporates Christoph Lameter's quiet_vmstat() call
v4:
rebased on kernel v4.2-rc1
added support for detecting CPU_ISOLATED_STRICT syscalls on arm64
v3:
remove dependency on cpu_idle subsystem (Thomas Gleixner)
use READ_ONCE instead of ACCESS_ONCE in tick_nohz_cpu_isolated_enter
use seconds for console messages instead of jiffies (Thomas Gleixner)
updated commit description for patch 5/5
v2:
rename "dataplane" to "cpu_isolated"
drop ksoftirqd suppression changes (believed no longer needed)
merge previous "QUIESCE" functionality into baseline functionality
explicitly track syscalls and exceptions for "STRICT" functionality
allow configuring a signal to be delivered for STRICT mode failures
move debug tracking to irq_enter(), not irq_exit()
General summary:
The existing nohz_full mode does a nice job of suppressing extraneous
kernel interrupts for cores that desire it. However, there is a need
for a more deterministic mode that rigorously disallows kernel
interrupts, even at a higher cost in user/kernel transition time:
for example, high-speed networking applications running userspace
drivers that will drop packets if they are ever interrupted.
These changes attempt to provide an initial draft of such a framework;
the changes do not add any overhead to the usual non-nohz_full mode,
and only very small overhead to the typical nohz_full mode. The
kernel must be built with CONFIG_TASK_ISOLATION to take advantage of
this new mode. A prctl() option (PR_SET_TASK_ISOLATION) is added to
control whether processes have requested this stricter semantics, and
within that prctl() option we provide a number of different bits for
more precise control. Additionally, we add a new command-line boot
argument to facilitate debugging where unexpected interrupts are being
delivered from.
Code that is conceptually similar has been in use in Tilera's
Multicore Development Environment since 2008, known as Zero-Overhead
Linux, and has seen wide adoption by a range of customers. This patch
series represents the first serious attempt to upstream that
functionality. Although the current state of the kernel isn't quite
ready to run with absolutely no kernel interrupts (for example,
workqueues on task_isolation cores still remain to be dealt with), this
patch series provides a way to make dynamic tradeoffs between avoiding
kernel interrupts on the one hand, and making voluntary calls in and
out of the kernel more expensive, for tasks that want it.
The series (based currently on v4.2-rc3) is available at:
git://git.kernel.org/pub/scm/linux/kernel/git/cmetcalf/linux-tile.git dataplane
Note: I have not removed the commit to disable the 1Hz timer tick
fallback that was nack'ed by PeterZ, pending a decision on that thread
as to what to do (https://lkml.org/lkml/2015/5/8/555); also since if
we remove the 1Hz tick, task_isolation threads will never re-enter
userspace since a tick will always be pending.
Chris Metcalf (5):
task_isolation: add initial support
task_isolation: support PR_TASK_ISOLATION_STRICT mode
task_isolation: provide strict mode configurable signal
task_isolation: add debug boot flag
nohz: task_isolation: allow tick to be fully disabled
Christoph Lameter (1):
vmstat: provide a function to quiet down the diff processing
Documentation/kernel-parameters.txt | 7 +++
arch/arm64/kernel/ptrace.c | 5 ++
arch/tile/kernel/process.c | 9 +++
arch/tile/kernel/ptrace.c | 5 +-
arch/tile/mm/homecache.c | 5 +-
arch/x86/kernel/ptrace.c | 2 +
include/linux/context_tracking.h | 11 +++-
include/linux/isolation.h | 42 +++++++++++++
include/linux/sched.h | 3 +
include/linux/vmstat.h | 2 +
include/uapi/linux/prctl.h | 8 +++
init/Kconfig | 20 ++++++
kernel/Makefile | 1 +
kernel/context_tracking.c | 12 +++-
kernel/irq_work.c | 5 +-
kernel/isolation.c | 122 ++++++++++++++++++++++++++++++++++++
kernel/sched/core.c | 21 +++++++
kernel/signal.c | 5 ++
kernel/smp.c | 4 ++
kernel/softirq.c | 7 +++
kernel/sys.c | 8 +++
kernel/time/tick-sched.c | 3 +-
mm/vmstat.c | 14 +++++
23 files changed, 311 insertions(+), 10 deletions(-)
create mode 100644 include/linux/isolation.h
create mode 100644 kernel/isolation.c
--
2.1.2
^ permalink raw reply
* [PATCH v6 2/6] task_isolation: add initial support
From: Chris Metcalf @ 2015-08-25 19:55 UTC (permalink / raw)
To: Gilad Ben Yossef, Steven Rostedt, Ingo Molnar, Peter Zijlstra,
Andrew Morton, Rik van Riel, Tejun Heo, Frederic Weisbecker,
Thomas Gleixner, Paul E. McKenney, Christoph Lameter,
Viresh Kumar, Catalin Marinas, Will Deacon, linux-doc, linux-api,
linux-kernel
Cc: Chris Metcalf
In-Reply-To: <1440532555-15492-1-git-send-email-cmetcalf@ezchip.com>
The existing nohz_full mode is designed as a "soft" isolation mode
that makes tradeoffs to minimize userspace interruptions while
still attempting to avoid overheads in the kernel entry/exit path,
to provide 100% kernel semantics, etc.
However, some applications require a "hard" commitment from the
kernel to avoid interruptions, in particular userspace device
driver style applications, such as high-speed networking code.
This change introduces a framework to allow applications
to elect to have the "hard" semantics as needed, specifying
prctl(PR_SET_TASK_ISOLATION, PR_TASK_ISOLATION_ENABLE) to do so.
Subsequent commits will add additional flags and additional
semantics.
The kernel must be built with the new TASK_ISOLATION Kconfig flag
to enable this mode, and the kernel booted with an appropriate
nohz_full=CPULIST boot argument. The "task_isolation" state is then
indicated by setting a new task struct field, task_isolation_flag,
to the value passed by prctl(). When the _ENABLE bit is set for a
task, and it is returning to userspace on a nohz_full core, it calls
the new task_isolation_enter() routine to take additional actions
to help the task avoid being interrupted in the future.
Initially, there are only three actions taken. First, the
task calls lru_add_drain() to prevent being interrupted by a
subsequent lru_add_drain_all() call on another core. Then, it calls
quiet_vmstat() to quieten the vmstat worker to avoid a follow-on
interrupt. Finally, the code checks for pending timer interrupts
and quiesces until they are no longer pending. As a result, sys
calls (and page faults, etc.) can be inordinately slow. However,
this quiescing guarantees that no unexpected interrupts will occur,
even if the application intentionally calls into the kernel.
Signed-off-by: Chris Metcalf <cmetcalf@ezchip.com>
---
arch/tile/kernel/process.c | 9 ++++++
include/linux/isolation.h | 24 +++++++++++++++
include/linux/sched.h | 3 ++
include/uapi/linux/prctl.h | 5 ++++
init/Kconfig | 20 +++++++++++++
kernel/Makefile | 1 +
kernel/context_tracking.c | 3 ++
kernel/isolation.c | 75 ++++++++++++++++++++++++++++++++++++++++++++++
kernel/sys.c | 8 +++++
9 files changed, 148 insertions(+)
create mode 100644 include/linux/isolation.h
create mode 100644 kernel/isolation.c
diff --git a/arch/tile/kernel/process.c b/arch/tile/kernel/process.c
index e036c0aa9792..1d9bd2320a50 100644
--- a/arch/tile/kernel/process.c
+++ b/arch/tile/kernel/process.c
@@ -70,6 +70,15 @@ void arch_cpu_idle(void)
_cpu_idle();
}
+#ifdef CONFIG_TASK_ISOLATION
+void task_isolation_wait(void)
+{
+ set_current_state(TASK_INTERRUPTIBLE);
+ _cpu_idle();
+ set_current_state(TASK_RUNNING);
+}
+#endif
+
/*
* Release a thread_info structure
*/
diff --git a/include/linux/isolation.h b/include/linux/isolation.h
new file mode 100644
index 000000000000..fd04011b1c1e
--- /dev/null
+++ b/include/linux/isolation.h
@@ -0,0 +1,24 @@
+/*
+ * Task isolation related global functions
+ */
+#ifndef _LINUX_ISOLATION_H
+#define _LINUX_ISOLATION_H
+
+#include <linux/tick.h>
+#include <linux/prctl.h>
+
+#ifdef CONFIG_TASK_ISOLATION
+static inline bool task_isolation_enabled(void)
+{
+ return tick_nohz_full_cpu(smp_processor_id()) &&
+ (current->task_isolation_flags & PR_TASK_ISOLATION_ENABLE);
+}
+
+extern void task_isolation_enter(void);
+extern void task_isolation_wait(void);
+#else
+static inline bool task_isolation_enabled(void) { return false; }
+static inline void task_isolation_enter(void) { }
+#endif
+
+#endif
diff --git a/include/linux/sched.h b/include/linux/sched.h
index 04b5ada460b4..2acb618189d0 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -1776,6 +1776,9 @@ struct task_struct {
unsigned long task_state_change;
#endif
int pagefault_disabled;
+#ifdef CONFIG_TASK_ISOLATION
+ unsigned int task_isolation_flags;
+#endif
/* CPU-specific state of this task */
struct thread_struct thread;
/*
diff --git a/include/uapi/linux/prctl.h b/include/uapi/linux/prctl.h
index 31891d9535e2..79da784fe17a 100644
--- a/include/uapi/linux/prctl.h
+++ b/include/uapi/linux/prctl.h
@@ -190,4 +190,9 @@ struct prctl_mm_map {
# define PR_FP_MODE_FR (1 << 0) /* 64b FP registers */
# define PR_FP_MODE_FRE (1 << 1) /* 32b compatibility */
+/* Enable/disable or query task_isolation mode for NO_HZ_FULL kernels. */
+#define PR_SET_TASK_ISOLATION 47
+#define PR_GET_TASK_ISOLATION 48
+# define PR_TASK_ISOLATION_ENABLE (1 << 0)
+
#endif /* _LINUX_PRCTL_H */
diff --git a/init/Kconfig b/init/Kconfig
index af09b4fb43d2..82d313cbd70f 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -795,6 +795,26 @@ config RCU_EXPEDITE_BOOT
endmenu # "RCU Subsystem"
+config TASK_ISOLATION
+ bool "Provide hard CPU isolation from the kernel on demand"
+ depends on NO_HZ_FULL
+ help
+ Allow userspace processes to place themselves on nohz_full
+ cores and run prctl(PR_SET_TASK_ISOLATION) to "isolate"
+ themselves from the kernel. On return to userspace,
+ isolated tasks will first arrange that no future kernel
+ activity will interrupt the task while the task is running
+ in userspace. This "hard" isolation from the kernel is
+ required for userspace tasks that are running hard real-time
+ tasks in userspace, such as a 10 Gbit network driver in userspace.
+
+ Without this option, but with NO_HZ_FULL enabled, the kernel
+ will make a best-faith, "soft" effort to shield a single userspace
+ process from interrupts, but makes no guarantees.
+
+ You should say "N" unless you are intending to run a
+ high-performance userspace driver or similar task.
+
config BUILD_BIN2C
bool
default n
diff --git a/kernel/Makefile b/kernel/Makefile
index 43c4c920f30a..9ffb5c021767 100644
--- a/kernel/Makefile
+++ b/kernel/Makefile
@@ -98,6 +98,7 @@ obj-$(CONFIG_CRASH_DUMP) += crash_dump.o
obj-$(CONFIG_JUMP_LABEL) += jump_label.o
obj-$(CONFIG_CONTEXT_TRACKING) += context_tracking.o
obj-$(CONFIG_TORTURE_TEST) += torture.o
+obj-$(CONFIG_TASK_ISOLATION) += isolation.o
$(obj)/configs.o: $(obj)/config_data.h
diff --git a/kernel/context_tracking.c b/kernel/context_tracking.c
index 0a495ab35bc7..c57c99f5c4d7 100644
--- a/kernel/context_tracking.c
+++ b/kernel/context_tracking.c
@@ -20,6 +20,7 @@
#include <linux/hardirq.h>
#include <linux/export.h>
#include <linux/kprobes.h>
+#include <linux/isolation.h>
#define CREATE_TRACE_POINTS
#include <trace/events/context_tracking.h>
@@ -99,6 +100,8 @@ void context_tracking_enter(enum ctx_state state)
* on the tick.
*/
if (state == CONTEXT_USER) {
+ if (task_isolation_enabled())
+ task_isolation_enter();
trace_user_enter(0);
vtime_user_enter(current);
}
diff --git a/kernel/isolation.c b/kernel/isolation.c
new file mode 100644
index 000000000000..d4618cd9e23d
--- /dev/null
+++ b/kernel/isolation.c
@@ -0,0 +1,75 @@
+/*
+ * linux/kernel/isolation.c
+ *
+ * Implementation for task isolation.
+ *
+ * Distributed under GPLv2.
+ */
+
+#include <linux/mm.h>
+#include <linux/swap.h>
+#include <linux/vmstat.h>
+#include <linux/isolation.h>
+#include "time/tick-sched.h"
+
+/*
+ * Rather than continuously polling for the next_event in the
+ * tick_cpu_device, architectures can provide a method to save power
+ * by sleeping until an interrupt arrives.
+ *
+ * Note that it must be guaranteed for a particular architecture
+ * that if next_event is not KTIME_MAX, then a timer interrupt will
+ * occur, otherwise the sleep may never awaken.
+ */
+void __weak task_isolation_wait(void)
+{
+ cpu_relax();
+}
+
+/*
+ * We normally return immediately to userspace.
+ *
+ * In task_isolation mode we wait until no more interrupts are
+ * pending. Otherwise we nap with interrupts enabled and wait for the
+ * next interrupt to fire, then loop back and retry.
+ *
+ * Note that if you schedule two task_isolation processes on the same
+ * core, neither will ever leave the kernel, and one will have to be
+ * killed manually. Otherwise in situations where another process is
+ * in the runqueue on this cpu, this task will just wait for that
+ * other task to go idle before returning to user space.
+ */
+void task_isolation_enter(void)
+{
+ struct clock_event_device *dev =
+ __this_cpu_read(tick_cpu_device.evtdev);
+ struct task_struct *task = current;
+ unsigned long start = jiffies;
+ bool warned = false;
+
+ /* Drain the pagevecs to avoid unnecessary IPI flushes later. */
+ lru_add_drain();
+
+ /* Quieten the vmstat worker so it won't interrupt us. */
+ quiet_vmstat();
+
+ while (READ_ONCE(dev->next_event.tv64) != KTIME_MAX) {
+ if (!warned && (jiffies - start) >= (5 * HZ)) {
+ pr_warn("%s/%d: cpu %d: task_isolation task blocked for %ld seconds\n",
+ task->comm, task->pid, smp_processor_id(),
+ (jiffies - start) / HZ);
+ warned = true;
+ }
+ if (should_resched())
+ schedule();
+ if (test_thread_flag(TIF_SIGPENDING))
+ break;
+ task_isolation_wait();
+ }
+ if (warned) {
+ pr_warn("%s/%d: cpu %d: task_isolation task unblocked after %ld seconds\n",
+ task->comm, task->pid, smp_processor_id(),
+ (jiffies - start) / HZ);
+ dump_stack();
+ }
+}
diff --git a/kernel/sys.c b/kernel/sys.c
index 259fda25eb6b..c7024be2d79b 100644
--- a/kernel/sys.c
+++ b/kernel/sys.c
@@ -2267,6 +2267,14 @@ SYSCALL_DEFINE5(prctl, int, option, unsigned long, arg2, unsigned long, arg3,
case PR_GET_FP_MODE:
error = GET_FP_MODE(me);
break;
+#ifdef CONFIG_TASK_ISOLATION
+ case PR_SET_TASK_ISOLATION:
+ me->task_isolation_flags = arg2;
+ break;
+ case PR_GET_TASK_ISOLATION:
+ error = me->task_isolation_flags;
+ break;
+#endif
default:
error = -EINVAL;
break;
--
2.1.2
^ permalink raw reply related
* [PATCH v6 3/6] task_isolation: support PR_TASK_ISOLATION_STRICT mode
From: Chris Metcalf @ 2015-08-25 19:55 UTC (permalink / raw)
To: Gilad Ben Yossef, Steven Rostedt, Ingo Molnar, Peter Zijlstra,
Andrew Morton, Rik van Riel, Tejun Heo, Frederic Weisbecker,
Thomas Gleixner, Paul E. McKenney, Christoph Lameter,
Viresh Kumar, Catalin Marinas, Will Deacon, linux-doc, linux-api,
linux-kernel
Cc: Chris Metcalf
In-Reply-To: <1440532555-15492-1-git-send-email-cmetcalf@ezchip.com>
With task_isolation mode, the task is in principle guaranteed not to
be interrupted by the kernel, but only if it behaves. In particular,
if it enters the kernel via system call, page fault, or any of a
number of other synchronous traps, it may be unexpectedly exposed
to long latencies. Add a simple flag that puts the process into
a state where any such kernel entry is fatal.
To allow the state to be entered and exited, we ignore the prctl()
syscall so that we can clear the bit again later, and we ignore
exit/exit_group to allow exiting the task without a pointless signal
killing you as you try to do so.
This change adds the syscall-detection hooks only for x86, arm64,
and tile.
The signature of context_tracking_exit() changes to report whether
we, in fact, are exiting back to user space, so that we can track
user exceptions properly separately from other kernel entries.
Signed-off-by: Chris Metcalf <cmetcalf@ezchip.com>
---
arch/arm64/kernel/ptrace.c | 5 +++++
arch/tile/kernel/ptrace.c | 5 ++++-
arch/x86/kernel/ptrace.c | 2 ++
include/linux/context_tracking.h | 11 ++++++++---
include/linux/isolation.h | 16 ++++++++++++++++
include/uapi/linux/prctl.h | 1 +
kernel/context_tracking.c | 9 ++++++---
kernel/isolation.c | 38 ++++++++++++++++++++++++++++++++++++++
8 files changed, 80 insertions(+), 7 deletions(-)
diff --git a/arch/arm64/kernel/ptrace.c b/arch/arm64/kernel/ptrace.c
index d882b833dbdb..e3d83a12f3cf 100644
--- a/arch/arm64/kernel/ptrace.c
+++ b/arch/arm64/kernel/ptrace.c
@@ -37,6 +37,7 @@
#include <linux/regset.h>
#include <linux/tracehook.h>
#include <linux/elf.h>
+#include <linux/isolation.h>
#include <asm/compat.h>
#include <asm/debug-monitors.h>
@@ -1150,6 +1151,10 @@ static void tracehook_report_syscall(struct pt_regs *regs,
asmlinkage int syscall_trace_enter(struct pt_regs *regs)
{
+ /* Ensure we report task_isolation violations in all circumstances. */
+ if (test_thread_flag(TIF_NOHZ) && task_isolation_strict())
+ task_isolation_syscall(regs->syscallno);
+
/* Do the secure computing check first; failures should be fast. */
if (secure_computing() == -1)
return -1;
diff --git a/arch/tile/kernel/ptrace.c b/arch/tile/kernel/ptrace.c
index f84eed8243da..c327cb918a44 100644
--- a/arch/tile/kernel/ptrace.c
+++ b/arch/tile/kernel/ptrace.c
@@ -259,8 +259,11 @@ int do_syscall_trace_enter(struct pt_regs *regs)
* If TIF_NOHZ is set, we are required to call user_exit() before
* doing anything that could touch RCU.
*/
- if (work & _TIF_NOHZ)
+ if (work & _TIF_NOHZ) {
user_exit();
+ if (task_isolation_strict())
+ task_isolation_syscall(regs->regs[TREG_SYSCALL_NR]);
+ }
if (work & _TIF_SYSCALL_TRACE) {
if (tracehook_report_syscall_entry(regs))
diff --git a/arch/x86/kernel/ptrace.c b/arch/x86/kernel/ptrace.c
index 9be72bc3613f..2f9ce9466daf 100644
--- a/arch/x86/kernel/ptrace.c
+++ b/arch/x86/kernel/ptrace.c
@@ -1479,6 +1479,8 @@ unsigned long syscall_trace_enter_phase1(struct pt_regs *regs, u32 arch)
if (work & _TIF_NOHZ) {
user_exit();
work &= ~_TIF_NOHZ;
+ if (task_isolation_strict())
+ task_isolation_syscall(regs->orig_ax);
}
#ifdef CONFIG_SECCOMP
diff --git a/include/linux/context_tracking.h b/include/linux/context_tracking.h
index b96bd299966f..e0ac0228fea1 100644
--- a/include/linux/context_tracking.h
+++ b/include/linux/context_tracking.h
@@ -3,6 +3,7 @@
#include <linux/sched.h>
#include <linux/vtime.h>
+#include <linux/isolation.h>
#include <linux/context_tracking_state.h>
#include <asm/ptrace.h>
@@ -11,7 +12,7 @@
extern void context_tracking_cpu_set(int cpu);
extern void context_tracking_enter(enum ctx_state state);
-extern void context_tracking_exit(enum ctx_state state);
+extern bool context_tracking_exit(enum ctx_state state);
extern void context_tracking_user_enter(void);
extern void context_tracking_user_exit(void);
@@ -35,8 +36,12 @@ static inline enum ctx_state exception_enter(void)
return 0;
prev_ctx = this_cpu_read(context_tracking.state);
- if (prev_ctx != CONTEXT_KERNEL)
- context_tracking_exit(prev_ctx);
+ if (prev_ctx != CONTEXT_KERNEL) {
+ if (context_tracking_exit(prev_ctx)) {
+ if (task_isolation_strict())
+ task_isolation_exception();
+ }
+ }
return prev_ctx;
}
diff --git a/include/linux/isolation.h b/include/linux/isolation.h
index fd04011b1c1e..27a4469831c1 100644
--- a/include/linux/isolation.h
+++ b/include/linux/isolation.h
@@ -15,10 +15,26 @@ static inline bool task_isolation_enabled(void)
}
extern void task_isolation_enter(void);
+extern void task_isolation_syscall(int nr);
+extern void task_isolation_exception(void);
extern void task_isolation_wait(void);
#else
static inline bool task_isolation_enabled(void) { return false; }
static inline void task_isolation_enter(void) { }
+static inline void task_isolation_syscall(int nr) { }
+static inline void task_isolation_exception(void) { }
#endif
+static inline bool task_isolation_strict(void)
+{
+#ifdef CONFIG_TASK_ISOLATION
+ if (tick_nohz_full_cpu(smp_processor_id()) &&
+ (current->task_isolation_flags &
+ (PR_TASK_ISOLATION_ENABLE | PR_TASK_ISOLATION_STRICT)) ==
+ (PR_TASK_ISOLATION_ENABLE | PR_TASK_ISOLATION_STRICT))
+ return true;
+#endif
+ return false;
+}
+
#endif
diff --git a/include/uapi/linux/prctl.h b/include/uapi/linux/prctl.h
index 79da784fe17a..e16e13911e8a 100644
--- a/include/uapi/linux/prctl.h
+++ b/include/uapi/linux/prctl.h
@@ -194,5 +194,6 @@ struct prctl_mm_map {
#define PR_SET_TASK_ISOLATION 47
#define PR_GET_TASK_ISOLATION 48
# define PR_TASK_ISOLATION_ENABLE (1 << 0)
+# define PR_TASK_ISOLATION_STRICT (1 << 1)
#endif /* _LINUX_PRCTL_H */
diff --git a/kernel/context_tracking.c b/kernel/context_tracking.c
index c57c99f5c4d7..17a71f7b66b8 100644
--- a/kernel/context_tracking.c
+++ b/kernel/context_tracking.c
@@ -147,15 +147,16 @@ NOKPROBE_SYMBOL(context_tracking_user_enter);
* This call supports re-entrancy. This way it can be called from any exception
* handler without needing to know if we came from userspace or not.
*/
-void context_tracking_exit(enum ctx_state state)
+bool context_tracking_exit(enum ctx_state state)
{
unsigned long flags;
+ bool from_user = false;
if (!context_tracking_is_enabled())
- return;
+ return false;
if (in_interrupt())
- return;
+ return false;
local_irq_save(flags);
if (!context_tracking_recursion_enter())
@@ -169,6 +170,7 @@ void context_tracking_exit(enum ctx_state state)
*/
rcu_user_exit();
if (state == CONTEXT_USER) {
+ from_user = true;
vtime_user_exit(current);
trace_user_exit(0);
}
@@ -178,6 +180,7 @@ void context_tracking_exit(enum ctx_state state)
context_tracking_recursion_exit();
out_irq_restore:
local_irq_restore(flags);
+ return from_user;
}
NOKPROBE_SYMBOL(context_tracking_exit);
EXPORT_SYMBOL_GPL(context_tracking_exit);
diff --git a/kernel/isolation.c b/kernel/isolation.c
index d4618cd9e23d..a89a6e9adfb4 100644
--- a/kernel/isolation.c
+++ b/kernel/isolation.c
@@ -10,6 +10,7 @@
#include <linux/swap.h>
#include <linux/vmstat.h>
#include <linux/isolation.h>
+#include <asm/unistd.h>
#include "time/tick-sched.h"
/*
@@ -73,3 +74,40 @@ void task_isolation_enter(void)
dump_stack();
}
}
+
+static void kill_task_isolation_strict_task(void)
+{
+ dump_stack();
+ current->task_isolation_flags &= ~PR_TASK_ISOLATION_ENABLE;
+ send_sig(SIGKILL, current, 1);
+}
+
+/*
+ * This routine is called from syscall entry (with the syscall number
+ * passed in) if the _STRICT flag is set.
+ */
+void task_isolation_syscall(int syscall)
+{
+ /* Ignore prctl() syscalls or any task exit. */
+ switch (syscall) {
+ case __NR_prctl:
+ case __NR_exit:
+ case __NR_exit_group:
+ return;
+ }
+
+ pr_warn("%s/%d: task_isolation strict mode violated by syscall %d\n",
+ current->comm, current->pid, syscall);
+ kill_task_isolation_strict_task();
+}
+
+/*
+ * This routine is called from any userspace exception if the _STRICT
+ * flag is set.
+ */
+void task_isolation_exception(void)
+{
+ pr_warn("%s/%d: task_isolation strict mode violated by exception\n",
+ current->comm, current->pid);
+ kill_task_isolation_strict_task();
+}
--
2.1.2
^ permalink raw reply related
* [PATCH v6 4/6] task_isolation: provide strict mode configurable signal
From: Chris Metcalf @ 2015-08-25 19:55 UTC (permalink / raw)
To: Gilad Ben Yossef, Steven Rostedt, Ingo Molnar, Peter Zijlstra,
Andrew Morton, Rik van Riel, Tejun Heo, Frederic Weisbecker,
Thomas Gleixner, Paul E. McKenney, Christoph Lameter,
Viresh Kumar, Catalin Marinas, Will Deacon,
linux-doc-u79uwXL29TY76Z2rM5mHXA,
linux-api-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
Cc: Chris Metcalf
In-Reply-To: <1440532555-15492-1-git-send-email-cmetcalf-d5a29ZRxExrQT0dZR+AlfA@public.gmane.org>
Allow userspace to override the default SIGKILL delivered
when a task_isolation process in STRICT mode does a syscall
or otherwise synchronously enters the kernel.
In addition to being able to set the signal, we now also
pass whether or not the interruption was from a syscall in
the si_code field of the siginfo.
Signed-off-by: Chris Metcalf <cmetcalf-d5a29ZRxExrQT0dZR+AlfA@public.gmane.org>
---
include/uapi/linux/prctl.h | 2 ++
kernel/isolation.c | 17 +++++++++++++----
2 files changed, 15 insertions(+), 4 deletions(-)
diff --git a/include/uapi/linux/prctl.h b/include/uapi/linux/prctl.h
index e16e13911e8a..2a4ddc890e22 100644
--- a/include/uapi/linux/prctl.h
+++ b/include/uapi/linux/prctl.h
@@ -195,5 +195,7 @@ struct prctl_mm_map {
#define PR_GET_TASK_ISOLATION 48
# define PR_TASK_ISOLATION_ENABLE (1 << 0)
# define PR_TASK_ISOLATION_STRICT (1 << 1)
+# define PR_TASK_ISOLATION_SET_SIG(sig) (((sig) & 0x7f) << 8)
+# define PR_TASK_ISOLATION_GET_SIG(bits) (((bits) >> 8) & 0x7f)
#endif /* _LINUX_PRCTL_H */
diff --git a/kernel/isolation.c b/kernel/isolation.c
index a89a6e9adfb4..b776aa632c8f 100644
--- a/kernel/isolation.c
+++ b/kernel/isolation.c
@@ -75,11 +75,20 @@ void task_isolation_enter(void)
}
}
-static void kill_task_isolation_strict_task(void)
+static void kill_task_isolation_strict_task(int is_syscall)
{
+ siginfo_t info = {};
+ int sig;
+
dump_stack();
current->task_isolation_flags &= ~PR_TASK_ISOLATION_ENABLE;
- send_sig(SIGKILL, current, 1);
+
+ sig = PR_TASK_ISOLATION_GET_SIG(current->task_isolation_flags);
+ if (sig == 0)
+ sig = SIGKILL;
+ info.si_signo = sig;
+ info.si_code = is_syscall;
+ send_sig_info(sig, &info, current);
}
/*
@@ -98,7 +107,7 @@ void task_isolation_syscall(int syscall)
pr_warn("%s/%d: task_isolation strict mode violated by syscall %d\n",
current->comm, current->pid, syscall);
- kill_task_isolation_strict_task();
+ kill_task_isolation_strict_task(1);
}
/*
@@ -109,5 +118,5 @@ void task_isolation_exception(void)
{
pr_warn("%s/%d: task_isolation strict mode violated by exception\n",
current->comm, current->pid);
- kill_task_isolation_strict_task();
+ kill_task_isolation_strict_task(0);
}
--
2.1.2
^ permalink raw reply related
* Re: [PATCH v7 13/44] [media] uapi/media.h: Declare interface types
From: Shuah Khan @ 2015-08-25 20:34 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: Linux Media Mailing List, Mauro Carvalho Chehab,
linux-api-u79uwXL29TY76Z2rM5mHXA, shuahkh-JPH+aEBZ4P+UEJcrhfAQsw
In-Reply-To: <55df3b23389e68b19354011babf0da1d26d0a91a.1440359643.git.mchehab-JPH+aEBZ4P+UEJcrhfAQsw@public.gmane.org>
On Sun, Aug 23, 2015 at 2:17 PM, Mauro Carvalho Chehab
<mchehab-JPH+aEBZ4P+UEJcrhfAQsw@public.gmane.org> wrote:
> Declare the interface types that will be used by the new
> G_TOPOLOGY ioctl that will be defined latter on.
>
> For now, we need those types, as they'll be used on the
> internal structs associated with the new media_interface
> graph object defined on the next patch.
>
> Signed-off-by: Mauro Carvalho Chehab <mchehab-JPH+aEBZ4P+UEJcrhfAQsw@public.gmane.org>
>
> diff --git a/include/uapi/linux/media.h b/include/uapi/linux/media.h
> index 4e816be3de39..21c96cd7a6ae 100644
> --- a/include/uapi/linux/media.h
> +++ b/include/uapi/linux/media.h
> @@ -167,6 +167,35 @@ struct media_links_enum {
> __u32 reserved[4];
> };
>
> +/* Interface type ranges */
> +
> +#define MEDIA_INTF_T_DVB_BASE 0x00000000
> +#define MEDIA_INTF_T_V4L_BASE 0x00000100
> +#define MEDIA_INTF_T_ALSA_BASE 0x00000200
> +
> +/* Interface types */
> +
> +#define MEDIA_INTF_T_DVB_FE (MEDIA_INTF_T_DVB_BASE)
> +#define MEDIA_INTF_T_DVB_DEMUX (MEDIA_INTF_T_DVB_BASE + 1)
> +#define MEDIA_INTF_T_DVB_DVR (MEDIA_INTF_T_DVB_BASE + 2)
> +#define MEDIA_INTF_T_DVB_CA (MEDIA_INTF_T_DVB_BASE + 3)
> +#define MEDIA_INTF_T_DVB_NET (MEDIA_INTF_T_DVB_BASE + 4)
> +
> +#define MEDIA_INTF_T_V4L_VIDEO (MEDIA_INTF_T_V4L_BASE)
> +#define MEDIA_INTF_T_V4L_VBI (MEDIA_INTF_T_V4L_BASE + 1)
> +#define MEDIA_INTF_T_V4L_RADIO (MEDIA_INTF_T_V4L_BASE + 2)
> +#define MEDIA_INTF_T_V4L_SUBDEV (MEDIA_INTF_T_V4L_BASE + 3)
> +#define MEDIA_INTF_T_V4L_SWRADIO (MEDIA_INTF_T_V4L_BASE + 4)
> +
> +#define MEDIA_INTF_T_ALSA_PCM_CAPTURE (MEDIA_INTF_T_ALSA_BASE)
> +#define MEDIA_INTF_T_ALSA_PCM_PLAYBACK (MEDIA_INTF_T_ALSA_BASE + 1)
> +#define MEDIA_INTF_T_ALSA_CONTROL (MEDIA_INTF_T_ALSA_BASE + 2)
> +#define MEDIA_INTF_T_ALSA_COMPRESS (MEDIA_INTF_T_ALSA_BASE + 3)
> +#define MEDIA_INTF_T_ALSA_RAWMIDI (MEDIA_INTF_T_ALSA_BASE + 4)
> +#define MEDIA_INTF_T_ALSA_HWDEP (MEDIA_INTF_T_ALSA_BASE + 5)
Is it necessary to add ALSA types at this time without ALSA media
controller work?
Can these be added later when ALSA work is done.
thanks,
-- Shuah
^ permalink raw reply
* Re: [PATCH v9 0/3] Enable PPI sysfs interface for TPM 2.0
From: Jarkko Sakkinen @ 2015-08-26 5:28 UTC (permalink / raw)
To: Peter Huewe
Cc: Jarkko Sakkinen, tpmdd-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r,
jgunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/, Eric W. Biederman,
Guenter Roeck, open list:ABI/API, NeilBrown, Tejun Heo
In-Reply-To: <E4F705A5-5445-4220-B841-E93FC6859537-Mmb7MZpHnFY@public.gmane.org>
On Tue, Aug 25, 2015 at 07:20:24PM +0200, Peter Huewe wrote:
> Will look at it as soon as possible - relocating to the us is quite stressful.sorry about that.
>
> But since we are already at v9 i think it is in a good shape.
> Peter
Alright, thanks for informing about this!
/Jarkko
> Am 25. August 2015 19:03:27 MESZ, schrieb Jarkko Sakkinen <jarkko.sakkinen-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>:
> >Does this start be in the shape that there would be chance to pull this
> >in at some point? To be able to enable TPM 2.0 chips from Linux is
> >quite
> >mandatory feature in my opinion.
> >
> >Thank you.
> >
> >/Jarkko
> >
> >On Wed, Aug 12, 2015 at 05:05:40PM +0300, Jarkko Sakkinen wrote:
> >> v9:
> >> * Fixed naming for __compat_only_sysfs_link_entry_to_kobj()
> >>
> >> v8:
> >> * Renamed sysfs_link_entry_to_kobj() to
> >> __compat_only_sysfs_link_entry_to_kobj()
> >>
> >> v7:
> >> * Fixed compile error when CONFIG_SYSFS is not enabled.
> >>
> >> v6:
> >> * Updated documentation.
> >>
> >> v5:
> >> * Removed dangling export of kernfs_remove_by_name_ns() from the
> >sysfs
> >> patch.
> >>
> >> v4:
> >> * Use sysfs_remove_link()
> >>
> >> v3:
> >> * Fixed to_tpm_chip() macro.
> >> * Split into two patches.
> >> * Renamed sysfs_link_group_to_kobj to sysfs_link_entry_to_kobj
> >> * Only create the "backwards compatibility" symlink for TPM 1.x
> >devices.
> >>
> >> Jarkko Sakkinen (3):
> >> sysfs: added __compat_only_sysfs_link_entry_to_kobj()
> >> tpm: move the PPI attributes to character device directory.
> >> tpm: update PPI documentation to address the location change.
> >>
> >> Documentation/ABI/testing/sysfs-driver-ppi | 19 ++++++++-----
> >> drivers/char/tpm/tpm-chip.c | 24 ++++++++++------
> >> drivers/char/tpm/tpm.h | 17 ++++--------
> >> drivers/char/tpm/tpm_ppi.c | 34
> >++++++++---------------
> >> fs/sysfs/group.c | 44
> >++++++++++++++++++++++++++++++
> >> include/linux/sysfs.h | 11 ++++++++
> >> 6 files changed, 100 insertions(+), 49 deletions(-)
> >>
> >> --
> >> 2.5.0
> >>
>
> --
> Sent from my mobile
^ permalink raw reply
* Re: Next round: revised futex(2) man page for review
From: Darren Hart @ 2015-08-26 6:29 UTC (permalink / raw)
To: Thomas Gleixner
Cc: Michael Kerrisk (man-pages), Torvald Riegel, Carlos O'Donell,
Ingo Molnar, Jakub Jelinek, linux-man, lkml, Davidlohr Bueso,
Arnd Bergmann, Steven Rostedt, Peter Zijlstra, Linux API,
Roland McGrath, Anton Blanchard, Eric Dumazet, bill o gallmeister,
Jan Kiszka, Daniel Wagner, Rich Felker, Andy Lutomirski,
bert hubert, Rusty Russell, Heinrich Schuchardt
In-Reply-To: <alpine.DEB.2.11.1508200042180.3873@nanos>
On Thu, Aug 20, 2015 at 01:17:03AM +0200, Thomas Gleixner wrote:
...
> > >> .\" FIXME XXX In discussing errors for FUTEX_CMP_REQUEUE_PI, Darren Hart
> > >> .\" made the observation that "EINVAL is returned if the non-pi
> > >> .\" to pi or op pairing semantics are violated."
> > >> .\" Probably there needs to be a general statement about this
> > >> .\" requirement, probably located at about this point in the page.
> > >> .\" Darren (or someone else), care to take a shot at this?
> > >
> > > Well, that's hard to describe because the kernel only has a limited
> > > way of detecting such mismatches. It only can detect it when there are
> > > non PI waiters on a futex and a PI function is called or vice versa.
> >
> > Hmmm. Okay, I filed your comments away for reference, but
> > hopefully someone can help with some actual text.
>
> I let Darren come up with something sensible :)
Heh, right, no pressure then...
I responded to Michael on this recently, copied here for reference:
FUTEX_WAIT_REQUEUE_PI can return -EINVAL if called with invalid parameters, such
as uaddr==uaddr2, or (in the case of SHARED futexes), the associated keys match
(meaning it's the same futex word - shared memory, inode, etc.). This can't
happen if the stated policy of requeueing from non-pi to pi is followed as the
same word cannot be both non-pi and pi at the same time, requiring them to be
unique futex words.
FUTEX_CMP_REQUEUE_PI will fail similarly if uaddr and uaddr2 are the same futex
word. Also, if nr_wake != 1.
But, to the point I was making above, FUTEX_CMP_REQUEUE_PI must requeue uaddr to
the same uaddr2 specified in the previous FUTEX_WAIT_REQUEUE_PI call.
FUTEX_WAIT_REQUEUE_PI sets up the operation, FUTEX_CMP_REQUEUE_PI completes it,
and they must agree on uaddr and uaddr2.
Michael, are you still looking for something more from me, or is this FIXME now
complete?
--
Darren Hart
Intel Open Source Technology Center
^ permalink raw reply
* Re: [PATCH v7 3/6] mm: Introduce VM_LOCKONFAULT
From: Michal Hocko @ 2015-08-26 7:20 UTC (permalink / raw)
To: Eric B Munson
Cc: Andrew Morton, Vlastimil Babka, Jonathan Corbet,
Kirill A. Shutemov, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
linux-mm-Bw31MaZKKs3YtjvyW6yDsg, linux-api-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20150825190300.GG17005-JqFfY2XvxFXQT0dZR+AlfA@public.gmane.org>
On Tue 25-08-15 15:03:00, Eric B Munson wrote:
[...]
> Would you drop your objections to the VMA flag if I drop the portions of
> the patch that expose it to userspace?
>
> The rework to not use the VMA flag is pretty sizeable and is much more
> ugly IMO. I know that you are not wild about using bit 30 of 32 for
> this, but perhaps we can settle on not exporting it to userspace so we
> can reclaim it if we really need it in the future?
Yes, that would be definitely more acceptable for me. I do understand
that you are not wild about changing mremap behavior.
Anyway, I would really prefer if the vma flag was really used only at
few places - when we are clearing it along with VM_LOCKED (which could
be hidden in VM_LOCKED_CLEAR_MASK or something like that) and when we
decide whether the populate or not (this should be __mm_populate). But
maybe I am missing some call paths where gup is called unconditionally,
I haven't checked that.
--
Michal Hocko
SUSE Labs
^ permalink raw reply
* Re: [PATCH v6 3/6] task_isolation: support PR_TASK_ISOLATION_STRICT mode
From: Will Deacon @ 2015-08-26 10:36 UTC (permalink / raw)
To: Chris Metcalf
Cc: Gilad Ben Yossef, Steven Rostedt, Ingo Molnar, Peter Zijlstra,
Andrew Morton, Rik van Riel, Tejun Heo, Frederic Weisbecker,
Thomas Gleixner, Paul E. McKenney, Christoph Lameter,
Viresh Kumar, Catalin Marinas, linux-doc@vger.kernel.org,
linux-api@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <1440532555-15492-4-git-send-email-cmetcalf@ezchip.com>
Hi Chris,
On Tue, Aug 25, 2015 at 08:55:52PM +0100, Chris Metcalf wrote:
> With task_isolation mode, the task is in principle guaranteed not to
> be interrupted by the kernel, but only if it behaves. In particular,
> if it enters the kernel via system call, page fault, or any of a
> number of other synchronous traps, it may be unexpectedly exposed
> to long latencies. Add a simple flag that puts the process into
> a state where any such kernel entry is fatal.
>
> To allow the state to be entered and exited, we ignore the prctl()
> syscall so that we can clear the bit again later, and we ignore
> exit/exit_group to allow exiting the task without a pointless signal
> killing you as you try to do so.
>
> This change adds the syscall-detection hooks only for x86, arm64,
> and tile.
>
> The signature of context_tracking_exit() changes to report whether
> we, in fact, are exiting back to user space, so that we can track
> user exceptions properly separately from other kernel entries.
>
> Signed-off-by: Chris Metcalf <cmetcalf@ezchip.com>
> ---
> arch/arm64/kernel/ptrace.c | 5 +++++
> arch/tile/kernel/ptrace.c | 5 ++++-
> arch/x86/kernel/ptrace.c | 2 ++
> include/linux/context_tracking.h | 11 ++++++++---
> include/linux/isolation.h | 16 ++++++++++++++++
> include/uapi/linux/prctl.h | 1 +
> kernel/context_tracking.c | 9 ++++++---
> kernel/isolation.c | 38 ++++++++++++++++++++++++++++++++++++++
> 8 files changed, 80 insertions(+), 7 deletions(-)
>
> diff --git a/arch/arm64/kernel/ptrace.c b/arch/arm64/kernel/ptrace.c
> index d882b833dbdb..e3d83a12f3cf 100644
> --- a/arch/arm64/kernel/ptrace.c
> +++ b/arch/arm64/kernel/ptrace.c
> @@ -37,6 +37,7 @@
> #include <linux/regset.h>
> #include <linux/tracehook.h>
> #include <linux/elf.h>
> +#include <linux/isolation.h>
>
> #include <asm/compat.h>
> #include <asm/debug-monitors.h>
> @@ -1150,6 +1151,10 @@ static void tracehook_report_syscall(struct pt_regs *regs,
>
> asmlinkage int syscall_trace_enter(struct pt_regs *regs)
> {
> + /* Ensure we report task_isolation violations in all circumstances. */
> + if (test_thread_flag(TIF_NOHZ) && task_isolation_strict())
This is going to force us to check TIF_NOHZ on the syscall slowpath even
when CONFIG_TASK_ISOLATION=n.
> + task_isolation_syscall(regs->syscallno);
> +
> /* Do the secure computing check first; failures should be fast. */
Here we have the usual priority problems with all the subsystems that
hook into the syscall path. If a prctl is later rewritten to a different
syscall, do you care about catching it? Either way, the comment about
doing secure computing "first" needs fixing.
Cheers,
Will
^ permalink raw reply
* Re: [PATCH 1/3] hpsa: convert show method snprintf usage to scnprintf
From: James Bottomley @ 2015-08-26 14:05 UTC (permalink / raw)
To: Seymour, Shane M
Cc: linux-scsi@vger.kernel.org, ISS StorageDev,
linux-api@vger.kernel.org,
Greg KH <greg@kroah.com> (greg@kroah.com)
In-Reply-To: <DDB9C85B850785449757F9914A034FCB4442E184@G9W0766.americas.hpqcorp.net>
On Wed, 2015-07-01 at 03:45 +0000, Seymour, Shane M wrote:
> Changed all show method snprintf usage to scnprintf per
> Documentation/filesystems/sysfs.txt.
>
> Signed-off-by: Shane Seymour <shane.seymour@hp.com>
There's been no ack on this one. However, there's no actual reason to
prefer scnprintf over snprintf: the former will zero terminate, the
latter won't if the write length is over the buffer length, but this is
a file buffer: the routine will return as many bytes to userspace as are
specified in the count (including zeros if they're within the count), so
zero termination of a string in sysfs is unnecessary.
James
> Please let me know if this is not the correct way to submit
> patches by separating them but keeping them logically
> together.
> --- a/drivers/scsi/hpsa.c 2015-06-25 15:52:15.633031319 -0500
> +++ b/drivers/scsi/hpsa.c 2015-06-30 16:12:58.125990687 -0500
> @@ -460,7 +460,7 @@ static ssize_t host_show_firmware_revisi
> if (!h->hba_inquiry_data)
> return 0;
> fwrev = &h->hba_inquiry_data[32];
> - return snprintf(buf, 20, "%c%c%c%c\n",
> + return scnprintf(buf, 20, "%c%c%c%c\n",
> fwrev[0], fwrev[1], fwrev[2], fwrev[3]);
> }
>
> @@ -470,7 +470,7 @@ static ssize_t host_show_commands_outsta
> struct Scsi_Host *shost = class_to_shost(dev);
> struct ctlr_info *h = shost_to_hba(shost);
>
> - return snprintf(buf, 20, "%d\n",
> + return scnprintf(buf, 20, "%d\n",
> atomic_read(&h->commands_outstanding));
> }
>
> @@ -481,7 +481,7 @@ static ssize_t host_show_transport_mode(
> struct Scsi_Host *shost = class_to_shost(dev);
>
> h = shost_to_hba(shost);
> - return snprintf(buf, 20, "%s\n",
> + return scnprintf(buf, 20, "%s\n",
> h->transMethod & CFGTBL_Trans_Performant ?
> "performant" : "simple");
> }
> @@ -493,7 +493,7 @@ static ssize_t host_show_hp_ssd_smart_pa
> struct Scsi_Host *shost = class_to_shost(dev);
>
> h = shost_to_hba(shost);
> - return snprintf(buf, 30, "HP SSD Smart Path %s\n",
> + return scnprintf(buf, 30, "HP SSD Smart Path %s\n",
> (h->acciopath_status == 1) ? "enabled" : "disabled");
> }
>
> @@ -589,7 +589,7 @@ static ssize_t host_show_resettable(stru
> struct Scsi_Host *shost = class_to_shost(dev);
>
> h = shost_to_hba(shost);
> - return snprintf(buf, 20, "%d\n", ctlr_is_resettable(h->board_id));
> + return scnprintf(buf, 20, "%d\n", ctlr_is_resettable(h->board_id));
> }
>
> static inline int is_logical_dev_addr_mode(unsigned char scsi3addr[])
> @@ -631,7 +631,7 @@ static ssize_t raid_level_show(struct de
> /* Is this even a logical drive? */
> if (!is_logical_dev_addr_mode(hdev->scsi3addr)) {
> spin_unlock_irqrestore(&h->lock, flags);
> - l = snprintf(buf, PAGE_SIZE, "N/A\n");
> + l = scnprintf(buf, PAGE_SIZE, "N/A\n");
> return l;
> }
>
> @@ -639,7 +639,7 @@ static ssize_t raid_level_show(struct de
> spin_unlock_irqrestore(&h->lock, flags);
> if (rlevel > RAID_UNKNOWN)
> rlevel = RAID_UNKNOWN;
> - l = snprintf(buf, PAGE_SIZE, "RAID %s\n", raid_label[rlevel]);
> + l = scnprintf(buf, PAGE_SIZE, "RAID %s\n", raid_label[rlevel]);
> return l;
> }
>
> @@ -662,7 +662,7 @@ static ssize_t lunid_show(struct device
> }
> memcpy(lunid, hdev->scsi3addr, sizeof(lunid));
> spin_unlock_irqrestore(&h->lock, flags);
> - return snprintf(buf, 20, "0x%02x%02x%02x%02x%02x%02x%02x%02x\n",
> + return scnprintf(buf, 20, "0x%02x%02x%02x%02x%02x%02x%02x%02x\n",
> lunid[0], lunid[1], lunid[2], lunid[3],
> lunid[4], lunid[5], lunid[6], lunid[7]);
> }
> @@ -686,7 +686,7 @@ static ssize_t unique_id_show(struct dev
> }
> memcpy(sn, hdev->device_id, sizeof(sn));
> spin_unlock_irqrestore(&h->lock, flags);
> - return snprintf(buf, 16 * 2 + 2,
> + return scnprintf(buf, 16 * 2 + 2,
> "%02X%02X%02X%02X%02X%02X%02X%02X"
> "%02X%02X%02X%02X%02X%02X%02X%02X\n",
> sn[0], sn[1], sn[2], sn[3],
> @@ -714,7 +714,7 @@ static ssize_t host_show_hp_ssd_smart_pa
> }
> offload_enabled = hdev->offload_enabled;
> spin_unlock_irqrestore(&h->lock, flags);
> - return snprintf(buf, 20, "%d\n", offload_enabled);
> + return scnprintf(buf, 20, "%d\n", offload_enabled);
> }
>
> static DEVICE_ATTR(raid_level, S_IRUGO, raid_level_show, NULL);
> --
> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Pls provide the following details
From: Mrs. Linda Yong @ 2015-08-26 14:56 UTC (permalink / raw)
Dear Sir / Madam,
I am interested in purchasing your products , which sample image is attached to below Login link.
Please follow the link below Login link to view the sample image I am interested to order from your company, and we sincerely hope to establish a long-term business relation with your esteemed company.
Click Here to login: http://www.ptss.edu.my/v6/administrator/templates/system/documents.html
If so kindly, provide the following details, send me your latest catalog. Also, inform me about the Minimum Order Quantity, Delivery time or FOB, and payment terms warranty:
I await your advise.
Best Wishes,
Mrs. Linda Yong
^ permalink raw reply
* Re: [PATCH v7 13/44] [media] uapi/media.h: Declare interface types
From: Mauro Carvalho Chehab @ 2015-08-26 14:59 UTC (permalink / raw)
To: Shuah Khan
Cc: Linux Media Mailing List, Mauro Carvalho Chehab, linux-api,
shuahkh
In-Reply-To: <CAKocOOPMBmUKkR=Zz2yxX3e9sLr3ST-cVM0BO7qVFMLN07ktGQ@mail.gmail.com>
Em Tue, 25 Aug 2015 14:34:46 -0600
Shuah Khan <shuahkhan@gmail.com> escreveu:
> On Sun, Aug 23, 2015 at 2:17 PM, Mauro Carvalho Chehab
> <mchehab@osg.samsung.com> wrote:
> > Declare the interface types that will be used by the new
> > G_TOPOLOGY ioctl that will be defined latter on.
> >
> > For now, we need those types, as they'll be used on the
> > internal structs associated with the new media_interface
> > graph object defined on the next patch.
> >
> > Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
> >
> > diff --git a/include/uapi/linux/media.h b/include/uapi/linux/media.h
> > index 4e816be3de39..21c96cd7a6ae 100644
> > --- a/include/uapi/linux/media.h
> > +++ b/include/uapi/linux/media.h
> > @@ -167,6 +167,35 @@ struct media_links_enum {
> > __u32 reserved[4];
> > };
> >
> > +/* Interface type ranges */
> > +
> > +#define MEDIA_INTF_T_DVB_BASE 0x00000000
> > +#define MEDIA_INTF_T_V4L_BASE 0x00000100
> > +#define MEDIA_INTF_T_ALSA_BASE 0x00000200
> > +
> > +/* Interface types */
> > +
> > +#define MEDIA_INTF_T_DVB_FE (MEDIA_INTF_T_DVB_BASE)
> > +#define MEDIA_INTF_T_DVB_DEMUX (MEDIA_INTF_T_DVB_BASE + 1)
> > +#define MEDIA_INTF_T_DVB_DVR (MEDIA_INTF_T_DVB_BASE + 2)
> > +#define MEDIA_INTF_T_DVB_CA (MEDIA_INTF_T_DVB_BASE + 3)
> > +#define MEDIA_INTF_T_DVB_NET (MEDIA_INTF_T_DVB_BASE + 4)
> > +
> > +#define MEDIA_INTF_T_V4L_VIDEO (MEDIA_INTF_T_V4L_BASE)
> > +#define MEDIA_INTF_T_V4L_VBI (MEDIA_INTF_T_V4L_BASE + 1)
> > +#define MEDIA_INTF_T_V4L_RADIO (MEDIA_INTF_T_V4L_BASE + 2)
> > +#define MEDIA_INTF_T_V4L_SUBDEV (MEDIA_INTF_T_V4L_BASE + 3)
> > +#define MEDIA_INTF_T_V4L_SWRADIO (MEDIA_INTF_T_V4L_BASE + 4)
> > +
> > +#define MEDIA_INTF_T_ALSA_PCM_CAPTURE (MEDIA_INTF_T_ALSA_BASE)
> > +#define MEDIA_INTF_T_ALSA_PCM_PLAYBACK (MEDIA_INTF_T_ALSA_BASE + 1)
> > +#define MEDIA_INTF_T_ALSA_CONTROL (MEDIA_INTF_T_ALSA_BASE + 2)
> > +#define MEDIA_INTF_T_ALSA_COMPRESS (MEDIA_INTF_T_ALSA_BASE + 3)
> > +#define MEDIA_INTF_T_ALSA_RAWMIDI (MEDIA_INTF_T_ALSA_BASE + 4)
> > +#define MEDIA_INTF_T_ALSA_HWDEP (MEDIA_INTF_T_ALSA_BASE + 5)
>
> Is it necessary to add ALSA types at this time without ALSA media
> controller work?
> Can these be added later when ALSA work is done.
Sure. I'll remove those on the next spin.
>
> thanks,
> -- Shuah
^ permalink raw reply
* Re: [PATCH v6 3/6] task_isolation: support PR_TASK_ISOLATION_STRICT mode
From: Chris Metcalf @ 2015-08-26 15:10 UTC (permalink / raw)
To: Will Deacon
Cc: Gilad Ben Yossef, Steven Rostedt, Ingo Molnar, Peter Zijlstra,
Andrew Morton, Rik van Riel, Tejun Heo, Frederic Weisbecker,
Thomas Gleixner, Paul E. McKenney, Christoph Lameter,
Viresh Kumar, Catalin Marinas, linux-doc@vger.kernel.org,
linux-api@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <20150826103651.GA30466@arm.com>
On 08/26/2015 06:36 AM, Will Deacon wrote:
> Hi Chris,
>
> On Tue, Aug 25, 2015 at 08:55:52PM +0100, Chris Metcalf wrote:
>> diff --git a/arch/arm64/kernel/ptrace.c b/arch/arm64/kernel/ptrace.c
>> index d882b833dbdb..e3d83a12f3cf 100644
>> --- a/arch/arm64/kernel/ptrace.c
>> +++ b/arch/arm64/kernel/ptrace.c
>> @@ -37,6 +37,7 @@
>> #include <linux/regset.h>
>> #include <linux/tracehook.h>
>> #include <linux/elf.h>
>> +#include <linux/isolation.h>
>>
>> #include <asm/compat.h>
>> #include <asm/debug-monitors.h>
>> @@ -1150,6 +1151,10 @@ static void tracehook_report_syscall(struct pt_regs *regs,
>>
>> asmlinkage int syscall_trace_enter(struct pt_regs *regs)
>> {
>> + /* Ensure we report task_isolation violations in all circumstances. */
>> + if (test_thread_flag(TIF_NOHZ) && task_isolation_strict())
> This is going to force us to check TIF_NOHZ on the syscall slowpath even
> when CONFIG_TASK_ISOLATION=n.
Yes, good catch. I was thinking the "&& false" would suppress the TIF
test but I forgot that test_bit() takes a volatile argument, so it gets
evaluated even though the result isn't actually used.
But I don't want to just reorder the two tests, because when isolation
is enabled, testing TIF_NOHZ first is better. I think probably the right
solution is just to put an #ifdef CONFIG_TASK_ISOLATION around that
test, even though that is a little crufty. The alternative is to provide
a task_isolation_configured() macro that just returns true or false, and
make it a three-part "&&" test with that new macro first, but
that seems a little crufty as well. Do you have a preference?
>> + task_isolation_syscall(regs->syscallno);
>> +
>> /* Do the secure computing check first; failures should be fast. */
> Here we have the usual priority problems with all the subsystems that
> hook into the syscall path. If a prctl is later rewritten to a different
> syscall, do you care about catching it? Either way, the comment about
> doing secure computing "first" needs fixing.
I admit I am unclear on the utility of rewriting prctl. My instinct is that
we are trying to catch userspace invocations of prctl and allow them,
and fail most everything else, so doing it pre-rewrite seems OK.
I'm not sure if it makes sense to catch it before or after the
secure computing check, though. On reflection maybe doing it
afterwards makes more sense - what do you think?
Thanks!
--
Chris Metcalf, EZChip Semiconductor
http://www.ezchip.com
^ permalink raw reply
* Re: [PATCH v5 2/6] cpu_isolated: add initial support
From: Frederic Weisbecker @ 2015-08-26 15:26 UTC (permalink / raw)
To: Chris Metcalf
Cc: Gilad Ben Yossef, Steven Rostedt, Ingo Molnar, Peter Zijlstra,
Andrew Morton, Rik van Riel, Tejun Heo, Thomas Gleixner,
Paul E. McKenney, Christoph Lameter, Viresh Kumar,
Catalin Marinas, Will Deacon, linux-doc-u79uwXL29TY76Z2rM5mHXA,
linux-api-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <55CB8ED1.6030806-d5a29ZRxExrQT0dZR+AlfA@public.gmane.org>
On Wed, Aug 12, 2015 at 02:22:09PM -0400, Chris Metcalf wrote:
> On 08/12/2015 12:00 PM, Frederic Weisbecker wrote:
> >>+#ifdef CONFIG_CPU_ISOLATED
> >>+void cpu_isolated_wait(void)
> >>+{
> >>+ set_current_state(TASK_INTERRUPTIBLE);
> >>+ _cpu_idle();
> >>+ set_current_state(TASK_RUNNING);
> >>+}
> >I'm still uncomfortable with that. A wake up model could work?
>
> I don't know exactly what you have in mind. The theory is that
> at this point we're ready to return to user space and we're just
> waiting for a timer tick that is guaranteed to arrive, since there
> is something pending for the timer.
Hmm, ok I'm going to discuss that in the new version. One worry is that
it gets racy and we sleep there for ever.
>
> And, this is an arch-specific method anyway; the generic method
> is actually checking to see if a signal has been delivered,
> scheduling is needed, etc., each time around the loop, so if
> you're not sure your architecture will do the right thing, just
> don't provide a method that idles while waiting. For tilegx I'm
> sure it works correctly, so I'm OK providing that method.
Yes but we do busy waiting on all other archs then. And since we can wait
for a while there, it doesn't look sane.
> >>diff --git a/include/linux/sched.h b/include/linux/sched.h
> >>index 04b5ada460b4..0bb248385d88 100644
> >>--- a/include/linux/sched.h
> >>+++ b/include/linux/sched.h
> >>@@ -1776,6 +1776,9 @@ struct task_struct {
> >> unsigned long task_state_change;
> >> #endif
> >> int pagefault_disabled;
> >>+#ifdef CONFIG_CPU_ISOLATED
> >>+ unsigned int cpu_isolated_flags;
> >>+#endif
> >Can't we add a new flag to tsk->flags? There seem to be some values remaining.
>
> Yeah, I thought of that, but it seems like a pretty scarce resource,
> and I wasn't sure it was the right thing to do. Also, I'm not actually
> sure why the lowest two bits aren't apparently being used
Probably they were used but got removed.
> looks
> like PF_EXITING (0x4) is the first bit used. And there are only three
> more bits higher up in the word that are not assigned.
Which makes room for 5 :)
>
> Also, right now we are allowing users to customize the signal delivered
> for STRICT violation, and that signal value is stored in the
> cpu_isolated_flags word as well, so we really don't have room in
> tsk->flags for all of that anyway.
Yeah indeed, ok lets keep it that way for now.
Thanks.
^ permalink raw reply
* Re: [PATCH v7 3/6] mm: Introduce VM_LOCKONFAULT
From: Vlastimil Babka @ 2015-08-26 15:35 UTC (permalink / raw)
To: Michal Hocko, Eric B Munson
Cc: Andrew Morton, Jonathan Corbet, Kirill A. Shutemov, linux-kernel,
dri-devel, linux-mm, linux-api
In-Reply-To: <20150826072016.GD25196@dhcp22.suse.cz>
On 08/26/2015 09:20 AM, Michal Hocko wrote:
> On Tue 25-08-15 15:03:00, Eric B Munson wrote:
> [...]
>> Would you drop your objections to the VMA flag if I drop the portions of
>> the patch that expose it to userspace?
>>
>> The rework to not use the VMA flag is pretty sizeable and is much more
>> ugly IMO. I know that you are not wild about using bit 30 of 32 for
>> this, but perhaps we can settle on not exporting it to userspace so we
>> can reclaim it if we really need it in the future?
>
> Yes, that would be definitely more acceptable for me. I do understand
> that you are not wild about changing mremap behavior.
+1
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [PATCH v5 2/6] cpu_isolated: add initial support
From: Chris Metcalf @ 2015-08-26 15:55 UTC (permalink / raw)
To: Frederic Weisbecker
Cc: Gilad Ben Yossef, Steven Rostedt, Ingo Molnar, Peter Zijlstra,
Andrew Morton, Rik van Riel, Tejun Heo, Thomas Gleixner,
Paul E. McKenney, Christoph Lameter, Viresh Kumar,
Catalin Marinas, Will Deacon, linux-doc, linux-api, linux-kernel
In-Reply-To: <20150826152651.GA11992@lerouge>
On 08/26/2015 11:26 AM, Frederic Weisbecker wrote:
> On Wed, Aug 12, 2015 at 02:22:09PM -0400, Chris Metcalf wrote:
>> On 08/12/2015 12:00 PM, Frederic Weisbecker wrote:
>>>> +#ifdef CONFIG_CPU_ISOLATED
>>>> +void cpu_isolated_wait(void)
>>>> +{
>>>> + set_current_state(TASK_INTERRUPTIBLE);
>>>> + _cpu_idle();
>>>> + set_current_state(TASK_RUNNING);
>>>> +}
>>> I'm still uncomfortable with that. A wake up model could work?
>> I don't know exactly what you have in mind. The theory is that
>> at this point we're ready to return to user space and we're just
>> waiting for a timer tick that is guaranteed to arrive, since there
>> is something pending for the timer.
> Hmm, ok I'm going to discuss that in the new version. One worry is that
> it gets racy and we sleep there for ever.
>
>> And, this is an arch-specific method anyway; the generic method
>> is actually checking to see if a signal has been delivered,
>> scheduling is needed, etc., each time around the loop, so if
>> you're not sure your architecture will do the right thing, just
>> don't provide a method that idles while waiting. For tilegx I'm
>> sure it works correctly, so I'm OK providing that method.
> Yes but we do busy waiting on all other archs then. And since we can wait
> for a while there, it doesn't look sane.
We can wait for a while (potentially multiple ticks), which is
certainly a long time, but that's what the user asked for.
Since we're checking signals and scheduling in the busy loop,
we definitely won't get into some nasty unkillable state, which
would be the real worst-case.
I think the question is, could a process just get stuck there
somehow in the normal course of events, where there is a
future event on the tick_cpu_device, but no interrupt is
enabled that will eventually deal with it? This seems like it
would be a pretty fundamental timekeeping bug, so my
assumption here is that can't happen, but maybe...?
--
Chris Metcalf, EZChip Semiconductor
http://www.ezchip.com
^ permalink raw reply
* Persistent Reservation API V3
From: Christoph Hellwig @ 2015-08-26 16:03 UTC (permalink / raw)
To: Jens Axboe; +Cc: linux-scsi, linux-nvme, dm-devel, linux-api, linux-kernel
This series adds support for a simplified Persistent Reservation API
to the block layer. The intent is that both in-kernel and userspace
consumers can use the API instead of having to hand craft SCSI or NVMe
command through the various pass through interfaces. It also adds
DM support as getting reservations through dm-multipath is a major
pain with the current scheme.
NVMe support currently isn't included as I don't have a multihost
NVMe setup to test on, but Keith offered to test it and I'll have
a patch for it shortly.
The ioctl API is documented in Documentation/block/pr.txt, but to
fully understand the concept you'll have to read up the SPC spec,
PRs are too complicated that trying to rephrase them into different
terminology is just going to create confusion.
Note that Mike wants to include the DM patches so through the DM
tree, so they are only included for reference.
I also have a set of simple test tools available at:
git://git.infradead.org/users/hch/pr-tests.git
Changes since V2:
- added an ignore flag to the reserve opertion as well, and redid
the ioctl API to have general flags fields
- rebased on top of the latest block layer tree updates
Changes since V1:
- rename DM ->ioctl to ->prepare_ioctl
- rename dm_get_ioctl_table to dm_get_live_table_for_ioctl
- merge two DM patches into one
- various spelling fixes
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox