Perl 6 - the future is here, just unevenly distributed

IRC log for #gluster-dev, 2013-11-08

| Channels | #gluster-dev index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
01:08 yinyin joined #gluster-dev
01:19 awheeler joined #gluster-dev
01:38 awheeler joined #gluster-dev
01:58 yinyin joined #gluster-dev
02:08 bharata-rao joined #gluster-dev
02:18 [o__o] joined #gluster-dev
02:20 [o__o] left #gluster-dev
02:23 [o__o] joined #gluster-dev
02:54 bala joined #gluster-dev
02:59 kshlm joined #gluster-dev
03:07 shubhendu joined #gluster-dev
03:52 itisravi joined #gluster-dev
04:05 kanagaraj joined #gluster-dev
05:01 ppai joined #gluster-dev
05:14 lalatenduM joined #gluster-dev
05:19 aravindavk joined #gluster-dev
05:20 raghu joined #gluster-dev
05:20 ndarshan joined #gluster-dev
05:23 ababu joined #gluster-dev
05:24 bala1 joined #gluster-dev
05:29 mohankumar joined #gluster-dev
05:31 bala1 joined #gluster-dev
06:06 bulde joined #gluster-dev
06:08 bulde mohankumar: hi
06:09 bulde heard you had some doubts
06:09 bulde *questions :-)
06:09 mohankumar bulde, i am looking for clarification for avati's comment http://review.gluster.org/#/c/4​809/5/xlators/storage/bd/src/bd.c
06:09 mohankumar he mentioned using reusing @frame  in an unsafe way. Instead do a copy_frame() and STACK_DESTROY it in bd_null_rmsetxattr_cbk.
06:10 mohankumar but in so many other places i used STACK_WIND similar to this
06:13 bulde mohankumar: let me see that and understand what he meant... give me some time (say 15-30mins)
06:15 bulde ok... it was quicker than 15mins
06:15 bulde i checked his comments, and that is valid...
06:16 bulde the issue here is that, if you use the same frame to be doing a STACK_WIND(another_cbk), and doing another UNWIND() would lead into cases where before even 'another_cbk()' is called, the frame may be destroyed
06:17 bulde the rule of thumb while using frame/stack wind/unwind is to assume, if you do a UNWIND(frame), in the next line the 'frame' would be junk (as it would be freed, or being allocated by some other 'fop'.
06:18 mohankumar joined #gluster-dev
06:22 vshankar joined #gluster-dev
06:53 ndarshan joined #gluster-dev
07:08 yinyin joined #gluster-dev
07:29 mohankumar joined #gluster-dev
07:45 hagarth joined #gluster-dev
07:55 mohankumar bulde: sorry i got disconnected due to network issues
07:56 mohankumar i checked the archives for your reply, still i have doubt
08:44 bulde mohankumar: sure, ask
08:45 mohankumar bulde: STACK_WIND creates a new frame and passes that frame to the function
08:46 mohankumar STACK_UNWIND restores the parents frame and calls the cbk function
08:47 mohankumar so in bd_lookup_cbk, i call STACK_WIND(rmsetxattr_cbk, posix_removexattr), in rmsetxattr_cbk function i dont do anything, it just returns
08:47 mohankumar in bd_lookup_cbk after calling bd_get_info i do BD_STACK_UNWIND so it will use the original frame that function received
08:48 mohankumar or bd_lookup_cbk function would have called BD_STACK_UNWIND before bd_get_info function gets completed,
08:48 mohankumar so that the frame might be corrupted?
08:52 bulde1 joined #gluster-dev
09:01 mohankumar bulde1: ^^
10:37 hagarth joined #gluster-dev
10:52 bulde joined #gluster-dev
11:57 bulde joined #gluster-dev
12:15 itisravi_ joined #gluster-dev
12:29 bulde joined #gluster-dev
12:29 itisravi joined #gluster-dev
12:57 bulde joined #gluster-dev
13:11 xavih mohankumar: I think that the problem is that after calling BD_STACK_UNWIND() at bd_lookup_cbk(), the entire stack can be destroyed at any moment (when the unwinding reaches top level translator, the full stack will be destroyed), and this can happen before the unwinds that will finally call rmsetxattr_cbk() are fully processed, most probably causing a malfunction because you will access freed memory.
13:12 xavih mohankumar: allocating another stack to do the STACK_WIND() at bd_get_bd_info() prevents this
13:13 xavih mohankumar: this new stack will have to be destroyed at bd_null_rmsetxattr_cbk()
13:17 mohankumar xavih: from bd_lookup_cbk() i call bd_get_bd_info it does STACK_WIND of posix_setxattr/posix_removexattr
13:18 mohankumar whie posix_setxattr/posix_removexattr is running bd_get_bd_info might have returned to bd_lookup_cbk
13:18 mohankumar and bd_lookup_cbk might have called BD_STACK_UNWIND so that stack is freed
13:18 mohankumar if bd_null_rmsetxattr_cbk access the stack/frame, its a fault
13:19 mohankumar is my understanding correct?
13:20 xavih yes, you do not access the frame, but the underlying translator will have to access it to finally call your function (bd_null_rmsetxattr_cbk)
13:21 xavih and this access could happen to freed memory
13:25 mohankumar xavih: thanks for clarifying
13:26 xavih mohankumar: you're welcome :)
13:30 hagarth joined #gluster-dev
13:32 ndarshan joined #gluster-dev
13:33 edward1 joined #gluster-dev
13:58 awheeler joined #gluster-dev
13:59 awheeler joined #gluster-dev
14:02 mohankumar joined #gluster-dev
14:48 lpabon joined #gluster-dev
14:59 itisravi joined #gluster-dev
15:01 [o__o] left #gluster-dev
15:03 [o__o] joined #gluster-dev
15:04 wushudoin joined #gluster-dev
15:20 ira joined #gluster-dev
15:20 ira joined #gluster-dev
15:50 bulde joined #gluster-dev
15:54 bulde joined #gluster-dev
16:00 itisravi joined #gluster-dev
17:06 awheeler joined #gluster-dev
17:28 lalatenduM joined #gluster-dev
17:53 bulde joined #gluster-dev
19:13 bulde joined #gluster-dev
21:51 awheeler_ joined #gluster-dev
21:59 awheeler joined #gluster-dev
22:06 awheeler_ joined #gluster-dev
22:13 awheeler joined #gluster-dev
22:19 awheeler joined #gluster-dev
22:20 awheeler_ joined #gluster-dev
22:25 awheeler joined #gluster-dev
22:28 awheeler_ joined #gluster-dev
22:31 awheele__ joined #gluster-dev
23:30 chriswonders joined #gluster-dev
23:30 chriswonders left #gluster-dev

| Channels | #gluster-dev index | Today | | Search | Google Search | Plain-Text | summary