linux-kernel - Re: [RFC PATCH 04/16] rv/include: Add deterministic automata monitor definition via C macros

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <c638d724-c9d8-d640-eb99-8e684e2d594b@redhat.com>
Date:   Thu, 20 May 2021 09:13:50 +0200
From:   Daniel Bristot de Oliveira <bristot@...hat.com>
To:     Peter Zijlstra <peterz@...radead.org>
Cc:     linux-kernel@...r.kernel.org, Steven Rostedt <rostedt@...dmis.org>,
        Tommaso Cucinotta <tommaso.cucinotta@...tannapisa.it>,
        Kate Carcia <kcarcia@...hat.com>,
        Jonathan Corbet <corbet@....net>,
        Ingo Molnar <mingo@...hat.com>,
        Mauro Carvalho Chehab <mchehab@...nel.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Will Deacon <will@...nel.org>,
        Catalin Marinas <catalin.marinas@....com>,
        "Paul E. McKenney" <paulmck@...nel.org>,
        Joel Fernandes <joel@...lfernandes.org>,
        Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
        Gabriele Paoloni <gabriele.paoloni@...el.com>,
        Juri Lelli <juri.lelli@...hat.com>,
        Clark Williams <williams@...hat.com>, linux-doc@...r.kernel.org
Subject: Re: [RFC PATCH 04/16] rv/include: Add deterministic automata monitor
 definition via C macros

On 5/19/21 8:27 PM, Peter Zijlstra wrote:
> On Wed, May 19, 2021 at 01:36:25PM +0200, Daniel Bristot de Oliveira wrote:
> 
>> +struct da_monitor {
>> +	char curr_state;
>> +	bool monitoring;
>> +	void *model;
>> +};
>> +
>> +#define MAX_PID		 1024000
> 
>> +/*
>> + * Functions to define, init and get a per-task monitor.
>> + *
>> + * XXX: Make it dynamic? make it part of the task structure?
> 
> Yes !
> 
> I'd start with maybe adding a list_head to da_monitor and embedding a
> single copy into task_struct and link from there. Yes lists suck, but
> how many monitors do you realistically expect to run concurrently?

Good to know I can use the task struct! This will make my life easier. I did it
this way because I started doing the code all "out-of-tree," as modules... but
being in kernel gives such possibilities.

I will try to implement your idea! I do not see many concurrent monitors
running, and as the list search will be linear to the number of active
monitors... it might not even justify any more complex data structure.

Thanks Peter!

-- Daniel

>> + */
>> +#define DECLARE_DA_MON_INIT_PER_TASK(name, type)				\
>> +										\
>> +struct da_monitor da_mon_##name[MAX_PID];					\
> 
> That's ~16M of memory, which seems somewhat silly.
> 
>> +										\
>> +static inline struct da_monitor *da_get_monitor_##name(pid_t pid)		\
>> +{										\
>> +	return &da_mon_##name[pid];						\
>> +}										\
>> +										\
>> +void da_monitor_reset_all_##name(void)						\
>> +{										\
>> +	struct da_monitor *mon = da_mon_##name;					\
>> +	int i;									\
>> +	for (i = 0; i < MAX_PID; i++)						\
>> +		da_monitor_reset_##name(&mon[i]);				\
>> +}										\
>> +										\
>> +static void da_monitor_init_##name(void)					\
>> +{										\
>> +	struct da_monitor *mon = da_mon_##name;					\
>> +	int i;									\
>> +										\
>> +	for (i = 0; i < MAX_PID; i++) {						\
>> +		mon[i].curr_state = model_get_init_state_##name();		\
>> +		mon[i].monitoring = 0;						\
>> +		mon[i].model = model_get_model_##name();			\
>> +	}									\
>> +}										\
>