linux-kernel - Re: [RFC PATCH 4/6] relay: add relay_reserve

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <20070704031738.GB24341@Krystal>
Date:	Tue, 3 Jul 2007 23:17:38 -0400
From:	Mathieu Desnoyers <compudj@...stal.dyndns.org>
To:	Tom Zanussi <zanussi@...ibm.com>
Cc:	linux-kernel@...r.kernel.org, dwilder@...ibm.com,
	HOLZHEU@...ibm.com
Subject: Re: [RFC PATCH 4/6] relay: add relay_reserve_cpu()

* Tom Zanussi (zanussi@...ibm.com) wrote:
> This patch adds the ability to explicitly specify the per-cpu buffer
> to reserve space in.  Needed for early DTI tracing.
> 

This should come with the ability to tell relay where the already
allocated static buffers are. Can you tell me a little more on why the
standard relay_reserve would not do the job? Is smp_processor_id() not
ready to output a sensible CPU id yet ?

> Signed-off-by: Tom Zanussi <zanussi@...ibm.com>
> Signed-off-by: David Wilder <dwilder@...ibm.com>
> ---
>  relay.h |   33 +++++++++++++++++++++++++++++++++
>  1 file changed, 33 insertions(+)
> 
> diff --git a/include/linux/relay.h b/include/linux/relay.h
> index 6caedef..37a7306 100644
> --- a/include/linux/relay.h
> +++ b/include/linux/relay.h
> @@ -269,6 +269,39 @@ static inline void *relay_reserve(struct rchan *chan, size_t length)
>  }
>  
>  /**
> + *	relay_reserve_cpu - reserve slot in given cpu's channel buffer
> + *	@chan: relay channel
> + *	@length: number of bytes to reserve
> + *	@cpu: cpu to log to
> + *
> + *	Returns pointer to reserved slot, NULL if full.
> + *
> + *	Reserves a slot in the given cpu's channel buffer.
> + *	Does not protect the buffer at all - caller must provide
> + *	appropriate synchronization.
> + *
> + *	NOTE: this is almost certainly not the function you want -
> + *	use relay_reserve() instead for normal logging.  This version
> + *	is specialized for things like early tracing.
> + */
> +static inline void *relay_reserve_cpu(struct rchan *chan, size_t length,
> +				      unsigned int cpu)
> +{
> +	void *reserved;
> +	struct rchan_buf *buf = chan->buf[cpu];
> +
> +	if (unlikely(buf->offset + length > buf->chan->subbuf_size)) {
> +		length = relay_switch_subbuf(buf, length);
> +		if (!length)
> +			return NULL;
> +	}
> +	reserved = buf->data + buf->offset;
> +	buf->offset += length;
> +
> +	return reserved;
> +}
> +
> +/**
>   *	subbuf_start_reserve - reserve bytes at the start of a sub-buffer
>   *	@buf: relay channel buffer
>   *	@length: number of bytes to reserve
> 
> 
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@...r.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 

-- 
Mathieu Desnoyers
Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F  BA06 3F25 A8FE 3BAE 9A68
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/