Re: [LTP] [PATCH] new testcase: kmsg01

[chrubis@suse.cz]

Hi!
> > > +static void test_read_returns_first_message(void)
> > > +{
> > > +	char msg[NUM_READ_MSGS][MAX_MSGSIZE];
> > > +	int msgs_match = 1;
> > > +	int i;
> > > +
> > > +	tst_resm(TINFO, "TEST: mult. readers will get same first message");
> > > +	for (i = 0; i < NUM_READ_MSGS; i++) {
> > > +		if (find_msg(-1, "", msg[i], MAX_MSGSIZE, 1) != 0)
> > > +			tst_resm(TFAIL, "failed to find any message");
> > > +	}
> > > +
> > > +	for (i = 0; i < NUM_READ_MSGS-1; i++)
> > > +		if (strlen(msg[i]) > 0 && strcmp(msg[i], msg[i+1]) != 0)
> > > +			msgs_match = 0;
> > > +	if (msgs_match)
> > > +		tst_resm(TPASS, "all readers got same message on first read");
> > > +	else
> > > +		tst_resm(TFAIL, "readers got different messages");
> > 
> > Is here a chance that the log would be overwritten by a kernel writing
> > urelated message? We do fill the log with a bunch of messages (126)
> > before this test, how much of the kernel log is filled by this? Looking
> > in the kernel .config I have LOG_BUF_SHIFT=18 which is 256KB which
> > should be large enough, but it could be set as low as 12 which is 4KB.
> 
> It is. Let's open extra fd, which we attempt to read only at the end.
> If reads fails with EPIPE we know that first message was overwritten.
> If that happens we can retry for NUM_READ_RETRY and repeat the test.
> If we get EPIPE in each attempt we can report TWARN.
> 

Souns good.

-- 
Cyril Hrubis
chrubis@suse.cz

------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list