(Sorry for the gmail client)
My 0.2, HTH:
a) AFAIK, refcount_inc() (and similar friends) don't return any value
b) they're designed to just WARN() if they saturate or if you're
attempting to increment the value 0 (as it's possibly a UAF bug)
c) refcount_inc_checked() is documented as "Similar to at
Hi All,
Am facing some issues getting CPU limiting working with cgroups v2. Pl read on
for the details; a solution is much appreciated!
Env: 5.0.0 Linux kernel on x86_64 Fedora 29
When attempting to setup CPU limiting using cgroups v2, I effectively
disabled cgroups v1 by passing
cgroup_no_v1=
Hi,
Am facing some issues getting CPU limiting working with cgroups v2. Pl read on
for the details;
a solution is much appreciated!
Env: custom 5.0.0 Linux kernel on x86_64 Fedora 29
When attempting to setup CPU limiting using cgroups v2, I effectively disabled
cgroups v1 by passing
cgroup_n
C64
(in the get_address_re sub). Also, we now have also builtin "stubs", for lack
of a better term, where additional rules for other 64-bit arch's can be plugged
into the code,
in future, as applicable.
Signed-off-by: Kaiwan N Billimoria
---
scripts/leaking_addresses.pl | 190
o detect special cases for
> > x86_64 and ppc64 (in the get_address_re sub). Also, we now have
> > also builtin "stubs", for lack of a better term, where additional
> > rules for other 64-bit arch's can be plugged in, in future, as
> > applica
;
> Add support for locating and parsing kernel configuration file.
>
> Signed-off-by: Tobin C. Harding
> Co-Developed-by: Kaiwan N Billimoria
> ---
>
> get_kernel_config_option() is not super clean, any improvements most welcome.
>
> Kaiwan,
>
> This needs your S
e:
>>> On Mon, Dec 04, 2017 at 10:51:53AM +0530, Kaiwan N Billimoria wrote:
>>> > > ---
>>> > diff --git a/scripts/leaking_addresses.pl b/scripts/leaking_addresses.pl
>>> > index 9906dcf8b807..260b52e456f1 100755
>>> > --- a/scripts/leaking_add
> On Mon, Dec 4, 2017 at 10:25 AM, Tobin C. Harding wrote:
>>
>> > With the 'eval', no warning, it's fine.
>>
>> Why not use hex()?
>
>> >
>> > foreach my $config_file (@config_files) {
>> > + $config_file =~ s/\R*//g;
>>
>> Is there some reason you don't use chomp()?
>
Wrt
On Mon, Dec 4, 2017 at 10:25 AM, Tobin C. Harding wrote:
>
> > With the 'eval', no warning, it's fine.
>
> Why not use hex()?
> >
> > foreach my $config_file (@config_files) {
> > + $config_file =~ s/\R*//g;
>
> Is there some reason you don't use chomp()?
Tobin, now you can
Nov 29, 2017 at 04:32:54PM +0530, Kaiwan N Billimoria wrote:
>> This "fallback to 0xc000" I don't really agree with.
>> Obviously, there are platforms out there that do not use a PAGE_OFFSET value
>> of
>> 0xc000. So I think that defaulting to this
Hi,
On Wed, Nov 29, 2017 at 3:46 PM, Tobin C. Harding wrote:
> On Wed, Nov 29, 2017 at 09:59:59AM +0200, Alexander Kapshuk wrote:
>> On Tue, Nov 28, 2017 at 11:10 PM, Tobin C. Harding wrote:
>> > On Tue, Nov 28, 2017 at 03:16:24PM +0200, Alexander Kapshuk wrote:
>> >> On Tue, Nov 28, 2017 at 8:3
On Tue, Nov 28, 2017 at 11:58 AM, Tobin C. Harding wrote:
>
> At this stage I am unsure
> how best to convey my ideas back to you. It seems that adding 32 bit x86
> support is making a big enough change to the script that rather than you
> patching and me maintaining we could see it more as co-dev
On Tue, Nov 28, 2017 at 7:20 AM, Tobin C. Harding wrote:
>
> Noob question: how do we _know_ this. In other words how do we know no
> userland tools rely on the current behaviour? No stress to answer Kees,
> this is a pretty general kernel dev question.
Perhaps I'm reading this wrong, but anyway:
On Fri, Nov 24, 2017 at 11:29 AM, Tobin C. Harding wrote:
> Neither of these patches applies to my tree. Are you editing the diff's
> by hand? I noticed the patches don't end with the version signature, like
> this:
>
>
> 2.7.4
I cloned your tree from here: https://github.com/tcharding/lin
Thanks Tobin, for your detailed comments.
On Wed, Nov 22, 2017 at 5:29 AM, Tobin C. Harding wrote:
> You don't typically need [xxx v1] for version 1, the v1 is implicit.
>
> Please use the git brief description prefix that is already in use i.e
>
> leaking_addresses: add support for 32-bi
On Mon, Nov 13, 2017 at 11:38 AM, Tobin C. Harding wrote:
> On Mon, Nov 13, 2017 at 11:16:28AM +0530, kaiwan.billimo...@gmail.com wrote:
>> On Mon, 2017-11-13 at 09:21 +1100, Tobin C. Harding wrote:
>> > On Fri, Nov 10, 2017 at 07:26:34PM +0530, kaiwan.billimo...@gmail.com
>> > wrote:
>> > > On T
On Mon, Nov 13, 2017 at 10:05 AM, Tobin C. Harding wrote:
> On Mon, Nov 13, 2017 at 06:37:28AM +0300, Kirill A. Shutemov wrote:
>> On Mon, Nov 13, 2017 at 10:06:46AM +1100, Tobin C. Harding wrote:
>> > On Sun, Nov 12, 2017 at 02:10:07AM +0300, Kirill A. Shutemov wrote:
...
>> >
>> > Thanks for the
>
> Yes, profiling and tracing are similar. And you need to be root to run
> the recording anyway. Thus, as long as root user can read kallsyms,
> trace-cmd should be fine. As trace-cmd requires root access to do any
> ftrace tracing.
>
> -- Steve
Got it, thanks..
On Thu, Nov 9, 2017 at 10:13 AM, Kaiwan N Billimoria
wrote:
>> But I don't know if there is anything else than the profiling code
>> that _really_ wants access to /proc/kallsyms in user space as a
>> regular user.
>
Front-ends to ftrace, like trace-cmd?
[from the
> But I don't know if there is anything else than the profiling code
> that _really_ wants access to /proc/kallsyms in user space as a
> regular user.
Am unsure about this, but kprobes? (/jprobes/kretprobes), and by
extension, wrappers over this infra (like SystemTap)?
I (hazily) recollect a scrip
20 matches
Mail list logo
