[ltt-dev] Issue while patching "ttng-transport-formal-verif-fix-2.patch"

[ltt-dev] Issue while patching "ttng-transport-formal-verif-fix-2.patch"

[BHAVYA CHINDALOORVENKATANARAYANASETTY]

An HTML attachment was scrubbed...
URL: <http://lists.casi.polymtl.ca/pipermail/lttng-dev/attachments/20090414/75b10b45/attachment-0003.htm>

[ltt-dev] Issue while patching "ttng-transport-formal-verif-fix-2.patch"

[srikanth krishnakar]

On Tue, Apr 14, 2009 at 3:31 PM, BHAVYA CHINDALOORVENKATANARAYANASETTY <
bhavya.setty at samsung.com> wrote:

> Hi,
>
> * *
>
> *Kernel Arch - *Linux dlnalinux 2.6.27.5-117.fc10.i686 #1 SMP Tue Nov 18
> 12:19:59 EST 2008 i686 i686 i386 GNU/Linux
>
> *Downloaded packges for LTTng are,*
>
> linux-2.6.27.4.tar.bz2
>
> ltt-control-0.56-24102008.tar.gz
>
> lttv-0.11.6-13112008.tar.gz
>
> patch-2.6.27.4-lttng-0.54.tar.bz2
>
> * *
>
> * *
>
> * *
>
> When I am applying the patch below i got the dile enter option,
>
> No Idea what it has to be, Could you please help me out...
>
> **
>
What strip option you are using to apply the patches to the kernel source ?

1. Untar the kernel source.

2. cd to kernel source

Like: # cd linux-2.6.27.4-lttng

3.  Then #mkdir patches

4. Copy all the patches from patch-2.6.27.4-lttng-0.54 directory to
kernel/patches directory.

5. then # quilt push -a

This should apply all patches to the kernel source.

Please use correct kernel version and corresponding patch version that is
based on matching kernel version. Like patch-2.6.27.4-lttng-0.54 is meant
for stable kernel version linux-2.6.27.4, this patch doesn't apply on
pristine 2.6.27 kernel.

* *
>
>
> *[root at dlnalinux patch-2.6.27.4-lttng-0.54]# patch -p1 <
> /usr/src/lttng/patch-2.6.27.4-lttng-0.54/lttng-transport-formal-verif-fix-2.patch
> *
>
> can't find file to patch at input line 61
>
> Perhaps you used the wrong -p or --strip option?
>
> The text leading up to this was:
>
> --------------------------
>
> |LTTng transport formal verif fix 2
>
> |
>
> |(This is take 2 of this fix, the previous one being buggy. I took time to
> think
>
> |carefully about the offsets involved and fixed the issues the previous
> version
>
> |had)
>
> |
>
> |Running a ltt relay buffer model into the spin verification tool shown
> that in
>
> |rare cases, where subbuffers are so small that enough reserve (uncomitted)
> space
>
> |would be equal to the subbuffer size, the reader size could think that the
>
> |subbuffer is fully committed when in fact the data is currently being
> written to
>
> |it.
>
> |
>
> |Fix this by checking the commit count and write offset difference to
> figure out
>
> |if all the reserved space for this subbuffer has been committed. Given
> that the
>
> |write offset increments for the whole subbuffer each time a given
> subbuffer's
>
> |commit count increment of the amount of bytes found in a subbuffer, we
> have to
>
> |multiply the commit count by the number of subbuffers to match the value
> of the
>
> |write offset. Also, the write offset has to be brought back to the window
>
> |corresponding to the commit count being checked. This is done by
> substracting
>
> |the subbuffer offset and by then aligning on the buffer size (- 1 is used
> to
>
> |align an already aligned offset on the current value, not the next).
>
> |
>
> |Note that the retrieve count solution, used in the formal model, has not
> been
>
> |implemented in C code because of atomicity constraints due to the fact
> that
>
> |writers can push readers in flight recorder mode. Having an extra counter
> to
>
> |update makes synchronization messy.
>
> |
>
> |This fix also moves the memory barriers found in the ltt_ioctl code to
> make sure
>
> |the commit count is read before the write offset, given that the write
> barrier
>
> |orders :
>
> |
>
> |write offset and buffer write
>
> |smp_wmb()
>
> |commit count write
>
> |
>
> |the read-side should look like :
>
> |
>
> |commit count read
>
> |smp_rmb()
>
> |write offset and buffer read
>
> |
>
> |Previously, the read-side did do :
>
> |commit count read and write offset read
>
> |smp_rmb()
>
> |buffer read
>
> |
>
> |Which could lead to unordered write and commit count reads.
>
> |
>
> |Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers at polymtl.ca>
>
> |CC: Paul McKenney <Paul.McKenney at us.ibm.com>
>
> |CC: Robert Wisniewski <bob at watson.ibm.com>
>
> |---
>
> | include/linux/ltt-tracer.h |   29 ++++--
>
> | ltt/ltt-relay.c            |  211
> +++++++++++++++++++++++++++------------------
>
> | 2 files changed, 148 insertions(+), 92 deletions(-)
>
> |
>
> |Index: linux-2.6-lttng/include/linux/ltt-tracer.h
>
> |===================================================================
>
> |--- linux-2.6-lttng.orig/include/linux/ltt-tracer.h    2008-10-24
> 10:13:24.000000000 -0400
>
> |+++ linux-2.6-lttng/include/linux/ltt-tracer.h 2008-10-24
> 10:14:19.000000000 -0400
>
> --------------------------
>
> *File to patch:*
>
>
>
>
>
>  Please help....
>
>
> Regards
>
> Bhavya
>
> _______________________________________________
> ltt-dev mailing list
> ltt-dev at lists.casi.polymtl.ca
> http://lists.casi.polymtl.ca/cgi-bin/mailman/listinfo/ltt-dev
>
>


-- 
"The Good You Do, The Best You GET"

Regards
Srikanth Krishnakar
**********************
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.casi.polymtl.ca/pipermail/lttng-dev/attachments/20090414/e0a27b2e/attachment-0003.htm>