; see
http://atv.ne.mediaone.net/linux-multisound)
* yenta (PCMCIA) and pci_socket modules have mutual dependency
(cardbus_register, yenta_operations) (test5, worked in test3)
(reported fixed by Erik Mouw)
* Keyboard/mouse problems (should be fixed?)
* Loop
I upgraded to 2.4.3 from 2.4.1 today and I get a lot of recovery on the scsi
bus.
I also upgraded to the "latest" aic7xxx driver but still the sam problems.
A typical revery in my logs.
Mar 31 09:34:35 pescadero kernel: scsi0:0:4:0: Attempting to queue an ABORT
message
Mar 31 09:34:35 pescadero ke
"Justin T. Gibbs" wrote:
> >I upgraded to 2.4.3 from 2.4.1 today and I get a lot of recovery on the scsi
> >bus.
> >I also upgraded to the "latest" aic7xxx driver but still the sam problems.
> >A typical revery in my logs.
>
> Can you resend the recovery information after booting with "aic7xxx=ve
"Justin T. Gibbs" wrote:
> >"Justin T. Gibbs" wrote:
> >
> >> >I upgraded to 2.4.3 from 2.4.1 today and I get a lot of recovery on the scs
> >i
> >> >bus.
> >> >I also upgraded to the "latest" aic7xxx driver but still the sam problems.
> >> >A typical revery in my logs.
>
> This really looks like
On 10/27/2017 10:05 PM, Johannes Weiner wrote:
> On Thu, Oct 26, 2017 at 02:03:41PM -0700, David Rientjes wrote:
>> On Thu, 26 Oct 2017, Johannes Weiner wrote:
>>
The nack is for three reasons:
(1) unfair comparison of root mem cgroup usage to bias against that mem
cgroup
On 10/31/2017 03:34 PM, Michal Hocko wrote:
> On Tue 31-10-17 15:17:11, peter enderborg wrote:
>> On 10/27/2017 10:05 PM, Johannes Weiner wrote:
>>> On Thu, Oct 26, 2017 at 02:03:41PM -0700, David Rientjes wrote:
>>>> On Thu, 26 Oct 2017, Johannes Weiner wrote:
>
On 11/01/2017 04:22 PM, Colin Walters wrote:
>
> On Wed, Nov 1, 2017, at 11:16 AM, Colin Walters wrote:
>> as the maintainer of glib2 which is used by a *lot* of things; I'm not
> (I meant to say "a" maintainer)
>
> Also, while I'm not an expert in Android, I think the "what to kill" logic
> there
On 08/01/2018 05:19 PM, Johannes Weiner wrote:
>
> A kernel with CONFIG_PSI=y will create a /proc/pressure directory with
> 3 files: cpu, memory, and io. If using cgroup2, cgroups will also have
> cpu.pressure, memory.pressure and io.pressure files, which simply
> aggregate task stalls at the cgrou
On 06/20/2018 01:55 PM, Michal Hocko wrote:
> On Wed 20-06-18 20:20:38, Tetsuo Handa wrote:
>> Sleeping with oom_lock held can cause AB-BA lockup bug because
>> __alloc_pages_may_oom() does not wait for oom_lock. Since
>> blocking_notifier_call_chain() in out_of_memory() might sleep, sleeping
>> wi
On 06/25/2018 03:07 PM, Michal Hocko wrote:
> On Mon 25-06-18 15:03:40, peter enderborg wrote:
>> On 06/20/2018 01:55 PM, Michal Hocko wrote:
>>> On Wed 20-06-18 20:20:38, Tetsuo Handa wrote:
>>>> Sleeping with oom_lock held can cause AB-BA lockup bug because
>>
On 06/25/2018 03:07 PM, Michal Hocko wrote:
> On Mon 25-06-18 15:03:40, peter enderborg wrote:
>> On 06/20/2018 01:55 PM, Michal Hocko wrote:
>>> On Wed 20-06-18 20:20:38, Tetsuo Handa wrote:
>>>> Sleeping with oom_lock held can cause AB-BA lockup bug because
>>
On 08/01/2018 05:13 PM, Johannes Weiner wrote:
> diff --git a/include/linux/page-flags.h b/include/linux/page-flags.h
> index e34a27727b9a..7af1c3c15d8e 100644
> --- a/include/linux/page-flags.h
> +++ b/include/linux/page-flags.h
> @@ -69,13 +69,14 @@
> */
> enum pageflags {
> PG_locked,
From: peter
As preparation for RCU the allocation need to be atomic,
there is a lot of them so they do in this patch.
Signed-off-by: Peter Enderborg
---
security/selinux/ss/avtab.c | 8 +--
security/selinux/ss/conditional.c | 14 ++---
security/selinux/ss/ebitmap.c | 3
We need a copy of sidtabs, so change the generic sidtab_clone
as from a function pointer and let it use a read rwlock while
do the clone.
Signed-off-by: Peter Enderborg
---
security/selinux/ss/services.c | 20 +---
security/selinux/ss/sidtab.c | 39
Will it be part of the backport to 4.9 google android or is it for test only?
I guess that this patch is to big for the LTS tree.
On 09/07/2018 05:58 PM, Suren Baghdasaryan wrote:
> Thanks for the new patchset! Backported to 4.9 and retested on ARMv8 8
> code system running Android. Signals behave
On 7/28/20 6:02 PM, Thiébaud Weksteen wrote:
> On Tue, Jul 28, 2020 at 5:12 PM Paul Moore wrote:
>> Perhaps it would be helpful if you provided an example of how one
>> would be expected to use this new tracepoint? That would help put
>> things in the proper perspective.
> The best example is the
not right)
and there are memory leaks, extra debug info and nonsense variable etc.
From: Peter Enderborg
Date: Thu, 30 Jul 2020 14:44:53 +0200
Subject: [PATCH] RFC: selinux avc trace
This is not done yet. But it shows a trace for selinux avc.
---
include/trace/events/avc.h | 92
On 7/30/20 5:04 PM, Steven Rostedt wrote:
> On Thu, 30 Jul 2020 16:29:12 +0200
> peter enderborg wrote:
>
>> +#undef TRACE_SYSTEM
>> +#define TRACE_SYSTEM avc
>> +
>> +#if !defined(_TRACE_AVC_H) || defined(TRACE_HEADER_MULTI_READ)
>> +#define _TRACE_A
On 7/30/20 4:50 PM, Stephen Smalley wrote:
> On Thu, Jul 30, 2020 at 10:29 AM peter enderborg
> wrote:
>> I did manage to rebase it but this is about my approach.
>>
>> Compared to Thiébaud Weksteen patch this adds:
>>
>> 1 Filtering. Types goes to trace so we
On 7/30/20 6:02 PM, Steven Rostedt wrote:
> On Thu, 30 Jul 2020 17:31:17 +0200
> peter enderborg wrote:
>
>> On 7/30/20 5:04 PM, Steven Rostedt wrote:
>>> On Thu, 30 Jul 2020 16:29:12 +0200
>>> peter enderborg wrote:
>>>
>>>> +#undef TRACE_
On 7/30/20 7:16 PM, Steven Rostedt wrote:
> On Thu, 30 Jul 2020 19:05:49 +0200
> peter enderborg wrote:
>
>>>> It should be a full structure with a lot of sub strings. But that make is
>>>> even more relevant.
>>> So one event instance can have a l
On 7/30/20 9:29 PM, Steven Rostedt wrote:
> On Thu, 30 Jul 2020 21:12:39 +0200
> peter enderborg wrote:
>
>>>> avc: denied { find } for interface=vendor.qti.hardware.perf::IPerf
>>>> sid=u:r:permissioncontroller_app:s0:c230,c256,c512,c768 pid=9164
>>>
On 8/6/20 5:03 PM, Stephen Smalley wrote:
> On Thu, Aug 6, 2020 at 10:51 AM peter enderborg
> wrote:
>> On 8/6/20 3:49 PM, Stephen Smalley wrote:
>>> On Thu, Aug 6, 2020 at 9:45 AM Stephen Smalley
>>> wrote:
>>>> On 8/6/20 8:32 AM, Stephen Smalley
On 8/6/20 3:49 PM, Stephen Smalley wrote:
> On Thu, Aug 6, 2020 at 9:45 AM Stephen Smalley
> wrote:
>> On 8/6/20 8:32 AM, Stephen Smalley wrote:
>>
>>> On 8/6/20 8:24 AM, peter enderborg wrote:
>>>
>>>> On 8/6/20 2:11 PM, Stephen Smalley wrote:
On 8/6/20 2:11 PM, Stephen Smalley wrote:
> On 8/6/20 4:03 AM, Thiébaud Weksteen wrote:
>
>> From: Peter Enderborg
>>
>> Add further attributes to filter the trace events from AVC.
>
> Please include sample usage and output in the description.
>
>
Im not s
On 8/17/20 10:16 PM, Stephen Smalley wrote:
> On 8/17/20 1:07 PM, Thiébaud Weksteen wrote:
>
>> From: Peter Enderborg
>>
>> In the print out add permissions, it will look like:
>> <...>-1042 [007] 201.965142: selinux_audited:
>> re
On 8/18/20 7:53 PM, Muni Sekhar wrote:
> On Tue, Aug 18, 2020 at 11:06 PM Greg KH wrote:
>> On Tue, Aug 18, 2020 at 11:01:35PM +0530, Muni Sekhar wrote:
>>> On Tue, Aug 18, 2020 at 10:44 PM Greg KH wrote:
On Tue, Aug 18, 2020 at 10:24:13PM +0530, Muni Sekhar wrote:
> On Tue, Aug 18, 2020
On 3/24/21 9:55 AM, Christoph Hellwig wrote:
> On Tue, Mar 23, 2021 at 07:04:31PM -0700, Stephen Boyd wrote:
>> x5 : x4 : 0001
>> x3 : 0008 x2 : ff93fef25a70
>> x1 : ff93fef15788 x0 : ffe3622352e0
>> Call trace:
>> lkdtm_WARNING+0x28/0x30 [
On 3/24/21 3:04 AM, Stephen Boyd wrote:
> This series adds the kernel's build ID[1] to the stacktrace header printed
> in oops messages, warnings, etc. and the build ID for any module that
> appears in the stacktrace after the module name. The goal is to make the
> stacktrace more self-contained an
This adds a total used dma-buf memory. Details
can be found in debugfs, however it is not for everyone
and not always available.
Signed-off-by: Peter Enderborg
---
drivers/dma-buf/dma-buf.c | 12
fs/proc/meminfo.c | 2 ++
include/linux/dma-buf.h | 1 +
3 files changed
This adds a total used dma-buf memory. Details
can be found in debugfs, however it is not for everyone
and not always available. dma-buf are indirect allocated by
userspace. So with this value we can monitor and detect
userspace applications that have problems.
Signed-off-by: Peter Enderborg
This adds a total used dma-buf memory. Details
can be found in debugfs, however it is not for everyone
and not always available. dma-buf are indirect allocated by
userspace. So with this value we can monitor and detect
userspace applications that have problems.
Signed-off-by: Peter Enderborg
This adds a total used dma-buf memory. Details
can be found in debugfs, however it is not for everyone
and not always available. dma-buf are indirect allocated by
userspace. So with this value we can monitor and detect
userspace applications that have problems.
Signed-off-by: Peter Enderborg
This adds a total used dma-buf memory. Details
can be found in debugfs, however it is not for everyone
and not always available. dma-buf are indirect allocated by
userspace. So with this value we can monitor and detect
userspace applications that have problems.
Signed-off-by: Peter Enderborg
The dma-buf counter is a metric for mapped memory used by it's clients.
It is a shared buffer that is typically used for interprocess communication
or process to hardware communication. In android we used to have ION,. but
it is now replaced with dma-buf. ION had some overview metrics that was simi
does not do to much pre-allocations,
finding memory leaks in userspace, such as not all clients
close down the reference to the buffer.
Signed-off-by: Peter Enderborg
---
Documentation/filesystems/proc.rst | 5 +
drivers/dma-buf/dma-buf.c | 12
fs/proc/meminfo.c
On system where dma-buf is used it can be many clients that adds up
to a lot of memory. This can be relevant for OOM handling when
running out of memory or how system handle this memory. It may be to free
with a kill.
Suggested-by: Michal Hocko
Signed-off-by: Peter Enderborg
---
lib/show_mem.c
On 2/17/21 10:42 AM, Will Deacon wrote:
> [Please include arm64 and kvm folks for threads involving the stage-2 MMU]
>
> On Tue, Feb 16, 2021 at 03:47:52PM +0530, Preeti Nagar wrote:
>> The changes introduce a new security feature, RunTime Integrity Check
>> (RTIC), designed to protect Linux Kernel
On 2/27/21 4:30 PM, John Wood wrote:
> In order to mitigate a brute force attack all the offending tasks involved
> in the attack must be killed. In other words, it is necessary to kill all
> the tasks that share the fork and/or exec statistical data related to the
> attack. Moreover, if the attack
From: Peter Enderborg
When sending data the socket allocates memory for
payload on a cache or a page alloc. The page alloc
then might trigger compation that takes long time.
This can be avoided with smaller chunks. But
userspace can not know what is the right size for
the smaller sends. For
On 4/28/20 9:43 AM, Michal Hocko wrote:
> On Mon 27-04-20 16:35:58, Andrew Morton wrote:
> [...]
>> No consumer of GFP_ATOMIC memory should consume an unbounded amount of
>> it.
>> Subsystems such as networking will consume a certain amount and
>> will then start recycling it. The total amount in-
On 1/7/19 11:56 PM, Andrew Morton wrote:
> On Sat, 5 Jan 2019 13:35:33 -0800 Linus Torvalds
> wrote:
>
>> On Sat, Jan 5, 2019 at 1:21 PM Olof Johansson wrote:
>>> Fixes build break on most ARM/ARM64 defconfigs:
>> Interesting.
>>
>> Andrew, I thought ARM was one of the platforms that your tree c
On 09/11/2018 02:11 PM, Michal Hocko wrote:
> Why is this a problem though? IIRC this event was deliberately placed
> outside of the oom path because we wanted to count allocation failures
> and this is also documented that way
>
> oom
> The number of time the cgroup's mem
Hi Tim. Do you have a link to the new version lmkd?
On 03/18/2017 12:16 AM, Tim Murray wrote:
> Hi all,
>
> I've been working to improve Android's memory management and drop
> lowmemorykiller from the kernel, and I'd like to get some feedback on a small
> patch with a lot of side effects.
>
> C
On 03/09/2017 03:08 PM, Richard Guy Briggs wrote:
> Record the module name of a delete_module call.
>
> See: https://github.com/linux-audit/audit-kernel/issues/37
>
> Signed-off-by: Richard Guy Briggs
> ---
> kernel/module.c |2 ++
> 1 files changed, 2 insertions(+), 0 deletions(-)
>
> diff -
On 02/23/2017 09:36 PM, Martijn Coenen wrote:
> On Thu, Feb 23, 2017 at 9:24 PM, John Stultz wrote:
>> So, just for context, Android does have a userland LMK daemon (using
>> the mempressure notifiers) as you mentioned, but unfortunately I'm
>> unaware of any devices that ship with that implementa
On 02/14/2017 05:51 PM, Greg KH wrote:
> On Tue, Feb 14, 2017 at 05:09:30PM +0100, peter.enderb...@sonymobile.com
> wrote:
>> From: Peter Enderborg
>>
>> This collects stats for shrinker calls and how much
>> waste work we do within the lowmemorykiller.
>&g
On 02/14/2017 05:50 PM, Greg KH wrote:
> On Tue, Feb 14, 2017 at 05:09:30PM +0100, peter.enderb...@sonymobile.com
> wrote:
>> From: Peter Enderborg
>>
>> This collects stats for shrinker calls and how much
>> waste work we do within the lowmemorykiller.
>&g
On 02/10/2017 08:59 AM, Michal Hocko wrote:
> On Fri 10-02-17 08:51:49, Greg KH wrote:
>> On Fri, Feb 10, 2017 at 08:21:32AM +0100, peter enderborg wrote:
> [...]
>>> Until then we have to polish this version as good as we can. It is
>>> essential for android as
On 02/10/2017 08:51 AM, Greg Kroah-Hartman wrote:
> On Fri, Feb 10, 2017 at 08:21:32AM +0100, peter enderborg wrote:
>> Im not speaking for google, but I think there is a work ongoing to
>> replace this with user-space code.
> Really? I have not heard this at all, any pointers
On 02/10/2017 10:15 AM, Michal Hocko wrote:
> On Fri 10-02-17 10:05:34, peter enderborg wrote:
>> On 02/10/2017 08:59 AM, Michal Hocko wrote:
> [...]
>>> The approach was wrong from the day 1. Abusing slab shrinkers
>>> is just a bad place to stick this logic. This al
On 02/10/2017 11:27 AM, Michal Hocko wrote:
> [I have only now see this cover - it answers some of the questions I've
> had to specific patches. It would be really great if you could use git
> send-email to post patch series - it just does the right thing(tm)]
>
> On Thu 09-0
On 02/24/2017 01:28 PM, Michal Hocko wrote:
> On Fri 24-02-17 13:19:46, peter enderborg wrote:
>> On 02/23/2017 09:36 PM, Martijn Coenen wrote:
>>> On Thu, Feb 23, 2017 at 9:24 PM, John Stultz wrote:
>>>> So, just for context, Android does have a userland LMK daem
On 02/24/2017 03:11 PM, Michal Hocko wrote:
> On Fri 24-02-17 14:16:34, peter enderborg wrote:
>> On 02/24/2017 01:28 PM, Michal Hocko wrote:
> [...]
>>> Yeah, I strongly believe that the chosen approach is completely wrong.
>>> Both in abusing the shrinker interfac
On 02/24/2017 04:03 PM, Michal Hocko wrote:
> On Fri 24-02-17 15:42:49, peter enderborg wrote:
>> On 02/24/2017 03:11 PM, Michal Hocko wrote:
>>> On Fri 24-02-17 14:16:34, peter enderborg wrote:
>>>> On 02/24/2017 01:28 PM, Michal Hocko wrote:
>>> [...]
Lowmemorykiller efficiency problem and a solution.
Lowmemorykiller in android has a severe efficiency problem. The basic
problem is that the registered shrinker gets called very often without
anything actually happening. This is in some cases not a problem as
it is a simple calculation that retu
not intended
to do any calculation changes other than we do use the cache for
calculate the count values and that makes kswapd0 to shrink other
areas.
Signed-off-by: Peter Enderborg
---
drivers/staging/android/Kconfig | 1 +
drivers/staging/android/Makefile| 1
This collects stats for shrinker calls and how much
waste work we do within the lowmemorykiller.
Signed-off-by: Peter Enderborg
---
drivers/staging/android/Kconfig | 11
drivers/staging/android/Makefile| 1 +
drivers/staging/android/lowmemorykiller.c
them in their own context so they do their actions
with minimal system impact.
Signed-off-by: Peter Enderborg
---
fs/proc/base.c | 13 +++
include/linux/oom_score_notifier.h | 47
kernel/Makefile| 1 +
kernel/fork.c
This collects stats for shrinker calls and how much
waste work we do within the lowmemorykiller.
Signed-off-by: Peter Enderborg
---
drivers/staging/android/Kconfig | 11
drivers/staging/android/Makefile| 1 +
drivers/staging/android/lowmemorykiller.c
On 02/09/2017 09:13 PM, Greg Kroah-Hartman wrote:
> On Thu, Feb 09, 2017 at 04:42:35PM +0100, peter enderborg wrote:
>> This collects stats for shrinker calls and how much
>> waste work we do within the lowmemorykiller.
>>
>> Signed-off-by: Peter Enderborg
>>
On 02/09/2017 09:05 PM, Michal Hocko wrote:
> On Thu 09-02-17 14:21:52, peter enderborg wrote:
>> Fundamental changes:
>> 1 Does NOT take any RCU lock in shrinker functions.
>> 2 It returns same result for scan and counts, so we dont need to do
>> shinker will know w
t;> On Thu, Feb 09, 2017 at 08:26:41PM +0100, Michal Hocko wrote:
>>> On Thu 09-02-17 14:21:45, peter enderborg wrote:
>>>> This collects stats for shrinker calls and how much
>>>> waste work we do within the lowmemorykiller.
>>> This doesn't exp
parts in the internal structures. This data can be readed
with a debugger or saved with a crashkernel. When it is off clients
get EPERM error when accessing the functions for registering their
components.
Signed-off-by: Peter Enderborg
---
.../admin-guide/kernel-parameters.txt | 11
be activated.
Signed-off-by: Peter Enderborg
---
fs/debugfs/inode.c | 17 -
lib/Kconfig.debug | 10 ++
2 files changed, 26 insertions(+), 1 deletion(-)
diff --git a/fs/debugfs/inode.c b/fs/debugfs/inode.c
index b7f2e971ecbc..bde37dab77e0 100644
--- a/fs/debugfs/inode.c
On 7/3/20 5:57 PM, Uladzislau Rezki wrote:
> Hello, folk.
>
> I have a system based on AMD 3970x CPUs. It has 32 physical cores
> and 64 threads. It seems that "nr_cpu_ids" variable is not correctly
> set on latest 5.8-rc3 kernel. Please have a look below on dmesg output:
>
>
> urezki@pc638:~$ sud
On 8/25/20 5:20 PM, Ondrej Mosnacek wrote:
> Instead of holding the RCU read lock the whole time while accessing the
> policy, add a simple refcount mechanism to track its lifetime. After
> this, the RCU read lock is held only for a brief time when fetching the
> policy pointer and incrementing the
On 8/26/20 3:42 PM, Paul Moore wrote:
> On Mon, Aug 24, 2020 at 9:23 AM Peter Enderborg
> wrote:
>> This adds tracing of all denies. They are grouped with trace_seq for
>> each audit.
>>
>> A filter can be inserted with a write to it's filter section.
&
On 8/26/20 4:45 PM, Paul Moore wrote:
> On Wed, Aug 26, 2020 at 10:34 AM peter enderborg
> wrote:
>> On 8/26/20 3:42 PM, Paul Moore wrote:
>>> On Mon, Aug 24, 2020 at 9:23 AM Peter Enderborg
>>> wrote:
>>>> This adds tracing of all denies. They are
When there is no clients listening on event the trace return
EBADF. The file is not a bad file descriptor and to get the
userspace able to do a proper error handling it need a different
error code that separate a bad file descriptor from a empty listening.
Signed-off-by: Peter Enderborg
On 5/11/20 10:59 PM, tip-bot2 for Joel Fernandes (Google) wrote:
> The following commit has been merged into the core/rcu branch of tip:
>
> Commit-ID: 9154244c1ab6c9db4f1f25ac8f73bd46dba64287
> Gitweb:
> https://git.kernel.org/tip/9154244c1ab6c9db4f1f25ac8f73bd46dba64287
> Author:
The count and scan can be separated in time. It is a fair chance
that all work is already done when the scan starts. It
then might retry. This is can be avoided with returning SHRINK_STOP.
Signed-off-by: Peter Enderborg
---
kernel/rcu/tree.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion
On 8/27/20 3:30 PM, Paul Moore wrote:
> On Wed, Aug 26, 2020 at 11:06 AM peter enderborg
> wrote:
>> On 8/26/20 4:45 PM, Paul Moore wrote:
>>> On Wed, Aug 26, 2020 at 10:34 AM peter enderborg
>>> wrote:
>>>> On 8/26/20 3:42 PM, Paul Moore wrote:
&
0x1c/0x68
[<06748df3>] crypto_skcipher_init_tfm+0x158/0x1e0
[<17f3270c>] crypto_create_tfm+0x54/0xf0
This is caused by tfm = (struct crypto_tfm *)(mem + tfmsize);
that is keept instead of the allocated buffer in mem.
Reference counting is done on alg.
Signed-off-by
This is other solution. I dont think needs any plugin support. It will generate
one
event for eatch denial and there is possible to filter on permission.
.
046 [002] .N.. 156.351738: selinux_denied:
trace_seq=2 result=-13
scontext=system_u:system_r:cupsd_t:s0-s0:c0.
c1023 tcontext=system_u:object_r:bin_t:s0
tclass=file permission=entrypoint
Signed-off-by: Peter Enderborg
---
inc
On 9/1/20 5:31 PM, Paul Moore wrote:
> On Mon, Aug 31, 2020 at 11:34 AM peter enderborg wrote:
>> On 8/31/20 4:16 PM, Paul Moore wrote:
>>> On Thu, Aug 27, 2020 at 10:04 AM peter enderborg wrote:
> ...
>
>>>> Im happly fine with replacing the selinux_audited wi
On 8/4/20 3:59 PM, Frankie Chang wrote:
> +void probe_binder_txn_latency_free(void *ignore, struct binder_transaction
> *t,
> + int from_proc, int from_thread,
> + int to_proc, int to_thread)
> +{
> + struct rtc_time tm;
>
On 8/31/20 4:16 PM, Paul Moore wrote:
> On Thu, Aug 27, 2020 at 10:04 AM peter enderborg
> wrote:
>> On 8/27/20 3:30 PM, Paul Moore wrote:
>>> On Wed, Aug 26, 2020 at 11:06 AM peter enderborg
>>> wrote:
>>>> On 8/26/20 4:45 PM, Paul Moore wrote:
&g
On 8/13/20 5:05 PM, Casey Schaufler wrote:
> On 8/13/2020 7:48 AM, Thiébaud Weksteen wrote:
>> From: Peter Enderborg
>>
>> This patch adds further attributes to the event. These attributes are
>> helpful to understand the context of the message and can be used
>>
On 8/13/20 5:49 PM, Stephen Smalley wrote:
> On 8/13/20 11:35 AM, peter enderborg wrote:
>
>> On 8/13/20 5:05 PM, Casey Schaufler wrote:
>>> On 8/13/2020 7:48 AM, Thiébaud Weksteen wrote:
>>>> From: Peter Enderborg
>>>>
>>>> This patch a
On 8/13/20 5:49 PM, Stephen Smalley wrote:
> On 8/13/20 11:35 AM, peter enderborg wrote:
>
>> On 8/13/20 5:05 PM, Casey Schaufler wrote:
>>> On 8/13/2020 7:48 AM, Thiébaud Weksteen wrote:
>>>> From: Peter Enderborg
>>>>
>>>> This patch a
On 8/13/20 7:38 PM, Steven Rostedt wrote:
> On Thu, 13 Aug 2020 19:14:10 +0200
> peter enderborg wrote:
>
>>> To be clear, userspace tools can't use fixed secid values because
>>> secids are dynamically assigned by SELinux and thus secid 42 need
>>> no
On 8/14/20 6:51 PM, Stephen Smalley wrote:
> On Fri, Aug 14, 2020 at 9:05 AM Thiébaud Weksteen wrote:
>> On Thu, Aug 13, 2020 at 5:41 PM Stephen Smalley
>> wrote:
>>> An explanation here of how one might go about decoding audited and
>>> tclass would be helpful to users (even better would be a sc
On 8/14/20 7:08 PM, Stephen Smalley wrote:
> On Fri, Aug 14, 2020 at 1:07 PM peter enderborg
> wrote:
>> On 8/14/20 6:51 PM, Stephen Smalley wrote:
>>> On Fri, Aug 14, 2020 at 9:05 AM Thiébaud Weksteen wrote:
>>>> On Thu, Aug 13, 2020 at 5:41 PM Stephen Smalley
On 8/14/20 7:46 PM, Steven Rostedt wrote:
> On Fri, 14 Aug 2020 19:22:13 +0200
> peter enderborg wrote:
>
>> On 8/14/20 7:08 PM, Stephen Smalley wrote:
>>> On Fri, Aug 14, 2020 at 1:07 PM peter enderborg
>>> wrote:
>>>> On 8/14/20 6:51 PM, Stephen S
On 8/14/20 8:30 PM, Steven Rostedt wrote:
> On Fri, 14 Aug 2020 20:06:34 +0200
> peter enderborg wrote:
>
>> Im find with that, but then you can not do filtering? I would be
>> pretty neat with a filter saying tclass=file permission=write.
>>
> Well, if the m
On 8/14/20 7:46 PM, Steven Rostedt wrote:
> On Fri, 14 Aug 2020 19:22:13 +0200
> peter enderborg wrote:
>
>> On 8/14/20 7:08 PM, Stephen Smalley wrote:
>>> On Fri, Aug 14, 2020 at 1:07 PM peter enderborg
>>> wrote:
>>>> On 8/14/20 6:51 PM, Stephen S
On 8/14/20 7:46 PM, Steven Rostedt wrote:
> On Fri, 14 Aug 2020 19:22:13 +0200
> peter enderborg wrote:
>
>> On 8/14/20 7:08 PM, Stephen Smalley wrote:
>>> On Fri, Aug 14, 2020 at 1:07 PM peter enderborg
>>> wrote:
>>>> On 8/14/20 6:51 PM, Stephen S
On 10/23/20 9:53 PM, Michael Jeanson wrote:
> When invoked from system call enter/exit instrumentation, accessing
> user-space data is a common use-case for tracers. However, tracepoints
> currently disable preemption around iteration on the registered
> tracepoint probes and invocation of the prob
On 8/21/20 4:22 AM, Paul Moore wrote:
> On Tue, Aug 18, 2020 at 8:14 AM Stephen Smalley
> wrote:
>> On Tue, Aug 18, 2020 at 4:11 AM peter enderborg
>> wrote:
> ...
>
>>> Is there any other things we need to fix? A part 1&2 now OK?
>> They looked ok to
On 8/21/20 3:19 PM, Paul Moore wrote:
> On Fri, Aug 21, 2020 at 8:29 AM Stephen Smalley
> wrote:
>> On Thu, Aug 20, 2020 at 10:31 PM Steven Rostedt wrote:
>>> On Wed, 19 Aug 2020 09:11:08 -0400
>>> Stephen Smalley wrote:
>>>
So we'll need to update this plugin whenever we modify
securi
as filesystem, but client can
register their parts in the internal structures. This data can be readed
with a debugger or saved with a crashkernel. When it is off clients
get EPERM error when accessing the functions for registering their
components.
Signed-off-by: Peter Enderborg
---
.../admin
Since debugfs include sensitive information it need to be treated
carefully. But it also has many very useful debug functions for userspace.
With this option we can have same configuration for system with
need of debugfs and a way to turn it off. This gives a extra protection
for exposure on syst
en tracefs was part of debugfs, it is now
standalone and does not need debugfs. When debugfs is in restricted
it is compiled in but not active and return EPERM to clients and
tracefs wont work if it assumes it is active it is compiled in
kernel.
Reported-by: kernel test robot
Signed-off-by: Peter
debugfs as filesystem, but client can
register their parts in the internal structures. This data can be readed
with a debugger or saved with a crashkernel. When it is off clients
get EPERM error when accessing the functions for registering their
components.
Signed-off-by: Peter Enderborg
---
.../admin
en tracefs was part of debugfs, it is now
standalone and does not need debugfs. When debugfs is in restricted
it is compiled in but not active and return EPERM to clients and
tracefs wont work if it assumes it is active it is compiled in
kernel.
Reported-by: kernel test robot
Signed-off-by: Peter
Since debugfs include sensitive information it need to be treated
carefully. But it also has many very useful debug functions for userspace.
With this option we can have same configuration for system with
need of debugfs and a way to turn it off. This gives a extra protection
for exposure on system
debugfs as filesystem, but client can
register their parts in the internal structures. This data can be readed
with a debugger or saved with a crashkernel. When it is off clients
get EPERM error when accessing the functions for registering their
components.
Signed-off-by: Peter Enderborg
---
.../admin
Since debugfs include sensitive information it need to be treated
carefully. But it also has many very useful debug functions for userspace.
With this option we can have same configuration for system with
need of debugfs and a way to turn it off. This gives a extra protection
for exposure on system
1 - 100 of 121 matches
Mail list logo
