<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="generator" content="Osso Notes">
<title></title></head>
<body>
<p>----- Original message -----
<br>> Balazs Scheidler <<a href="mailto:bazsi77@gmail.com">bazsi77@gmail.com</a>> writes:
<br>>
<br>> > ----- Original message -----
<br>> > > On 11/17/2012 09:00 AM, Balazs Scheidler wrote:
<br>> > > > dbparser: support inheriting properties in a corellation action
<br>> > > >
<br>> > > > I merged this one, although I have some doubts. It uses
<br>> > > > log_msg_clone_cow(), which does have some tricky semantics, as it
<br>> > > > assumes that the cloned message will not change, once cloned.
<br>> > > >
<br>> > > > I was thinking about removing clone_cow() completely because of
<br>> > > > this tricky stuff, and whenever we need a clone we're about to
<br>> > > > change the LogMessage anyway, and delaying the actual change means
<br>> > > > that we have to do two malloc() calls, instead of one.
<br>> > > >
<br>> > > > Can you test whether changing the message that triggered the action
<br>> > > > with a rewrite rule, keeps the cloned one intact? This would need a
<br>> > > > parallel path to the db-parser().
<br>> > > It seems, that log_msg_clone_cow write protects the original log
<br>> > > message, so trying to do a log_msg_set_value on the original message
<br>> > > will result in an assertion. Sorry I didn't realize this when doing
<br>> > > the  original patch, explicitly copying all the name-value pairs
<br>> > > seemed  inefficient, but this behaviour is not desirable. Should I
<br>> > > rework the  patch this way or is there a better way of doing it?
<br>> > >
<br>> >
<br>> > I'd drop clone_cow() now, and implement a proper clone that allocates
<br>> > the logmsg header and nvtable in a single block, and copies everything
<br>> > through.
<br>> >
<br>> > that way clone+change becomes cheaper and you got a clone call that
<br>> > works in this case too.
<br>>
<br>> There's another problem, though: pattern_db_process() also sets the
<br>> original message write protected, so even if I do a proper clone, the
<br>> original will remain write protected.
<br>
<br>only in case it's stored in a correllation context.
<br>
<br>>
<br>> I'm also a bit confused about the single block header + nvtable
<br>> allocation...
<br>>
<br>> I suppose I can do clone = log_msg_alloc(msg->payload->size), copy the
<br>> header and the payload too and adjust clone->payload. Is that the
<br>> correct way to do it?
<br>>
<br>
<br>I can't really remember the code too much. double check whether there are pointer values, those would probably need adjustments.
<br>
<br>also there are iv_list_heads used when a messagee is enqueued that need cleaning.</p>
</body>
</html>