2008-09-17 00:23 -!- tim_dimm(~timothyhu@cpe-76-90-98-247.socal.res.rr.com) has joined #tux3 2008-09-17 00:31 -!- tim_vimm(~Tim@cpe-76-90-98-247.socal.res.rr.com) has joined #tux3 2008-09-17 00:40 -!- pgquiles(~pgquiles@62.43.226.52.static.user.ono.com) has joined #tux3 2008-09-17 00:44 ok, I have a basic idea how I'm going to make extent creation happen in inode.c 2008-09-17 00:44 may slightly depart from tradition and not write a design note first 2008-09-17 00:45 -!- tim_vimm(~Tim@cpe-76-90-98-247.socal.res.rr.com) has left #tux3 2008-09-17 00:45 so its a surprise? 2008-09-17 01:07 http://www.phoronix.com/scan.php?page=news_item&px=NjcyNQ 2008-09-17 01:08 "An Update On The Tux3 File-System" 2008-09-17 01:08 very nice little news piece 2008-09-17 01:09 oh, and "Tux3 Report" is somehow got to #1 on the lkml.org hot list 2008-09-17 01:09 the next three posts are linus, then alan cox, then "time travel", then the original Tux3 announcement 2008-09-17 01:19 http://lwn.net/Articles/296568/ 2008-09-17 01:19 some comments there 2008-09-17 01:19 regarding the namespace 2008-09-17 01:20 -!- tim_dimm(~timothyhu@cpe-76-90-98-247.socal.res.rr.com) has joined #tux3 2008-09-17 01:20 geeks firing on random mode 2008-09-17 01:20 doesn't mean a thing until kernel untar works 2008-09-17 01:21 don't see anything on the namespace 2008-09-17 01:21 oh 2008-09-17 01:21 right 2008-09-17 01:21 "taking back teh tux" 2008-09-17 01:22 http://www.hpcwire.com/features/Cray_Unveils_Personal_Supercomputer.html 2008-09-17 01:22 noticed that one 2008-09-17 01:22 msft involvement 2008-09-17 01:22 got to be a disaster 2008-09-17 01:22 ack 2008-09-17 01:22 trying to find a higher waste-to-recovery ratio than even xbox I think 2008-09-17 01:23 tim_dimm, shap & I had a nice midnight skate, sorry we forgot to ping you 2008-09-17 01:24 don't know how we overlooked that 2008-09-17 01:24 it won't happen again 2008-09-17 01:24 dang- I would have rolled 2008-09-17 01:24 I know 2008-09-17 01:24 ACTION kicks /me 2008-09-17 01:24 ACTION agrees 2008-09-17 01:25 well I drown my sorrows in a glass of cabernet 2008-09-17 01:25 and see if I can get some progress on extent writing 2008-09-17 01:25 I spent the evening hanging shelves 2008-09-17 01:26 that's fun too 2008-09-17 01:26 loads 2008-09-17 01:26 more fun than watching paint dry 2008-09-17 01:26 -!- ChanServ changed mode/#tux3 -> +o shapor 2008-09-17 01:26 uhoh 2008-09-17 01:27 that set off all kinds of alarms 2008-09-17 01:27 ACTION aims ops priv 2008-09-17 01:27 -!- ChanServ changed mode/#tux3 -> +o flips 2008-09-17 01:28 -!- flips changed mode/#tux3 -> +o tim_dimm 2008-09-17 01:28 -!- flips changed mode/#tux3 -> +o konrad 2008-09-17 01:28 smooth operator 2008-09-17 01:28 now u r 1 2 2008-09-17 01:29 -!- flips changed mode/#tux3 -> +o tux3bot 2008-09-17 01:29 bot can kick now 2008-09-17 01:29 what you call a kickass bot 2008-09-17 01:29 hah 2008-09-17 01:29 kickbut_bot 2008-09-17 01:29 i dont think the tux has the code to do that 2008-09-17 01:30 lets find out 2008-09-17 01:32 folks 2008-09-17 01:33 <- crashes 2008-09-17 01:45 lol 2008-09-17 01:46 lots of sheriffs around now 2008-09-17 01:46 this must be the safest place on the planet 2008-09-17 01:46 ? 2008-09-17 01:46 you causing trouble again? 2008-09-17 01:46 oh 2008-09-17 01:46 all the ops 2008-09-17 01:47 -!- flips changed mode/#tux3 -> +o MaZe 2008-09-17 01:47 just don't make me use the kickbot 2008-09-17 01:48 lol 2008-09-17 01:48 I don't even know how to use *o* powers 2008-09-17 01:48 lots of chiefs not enough indians 2008-09-17 01:48 ACTION just barely refrains from kicking maze to communicate the concept 2008-09-17 01:48 I got waitqueues working 2008-09-17 01:48 flips: how's it going ? 2008-09-17 01:48 -!- flips changed mode/#tux3 -> -o flips 2008-09-17 01:48 there we are 2008-09-17 01:49 hi bh 2008-09-17 01:49 also found a bio_kern_map func 2008-09-17 01:49 pretty good, extents coming into focus 2008-09-17 01:49 yeah, I was reading something about it from your adventures with btrfs 2008-09-17 01:49 sounds... um... map what? 2008-09-17 01:49 erm, bio_map_kern 2008-09-17 01:49 apparently takes kernel data ptr and returns a bio 2008-09-17 01:50 sounds really automagic 2008-09-17 01:50 except no-one seems to use it... 2008-09-17 01:51 http://lxr.linux.no/linux+v2.6.26.5/fs/bio.c#L922 2008-09-17 01:51 add_pc_page... still don't know what pc stands for 2008-09-17 01:52 looks like a good exercise in taking something simple and making it look complex 2008-09-17 01:53 yes, well not sure what the extra pc means 2008-09-17 01:53 all that request queue passing looks doubtful 2008-09-17 01:53 what's it for? 2008-09-17 01:53 looks less than clean 2008-09-17 01:53 a lot of the bio code is like that 2008-09-17 01:53 http://lxr.linux.no/linux+v2.6.26.5/block/blk-map.c#L284 2008-09-17 01:53 seems to be the only place its used 2008-09-17 01:54 is this entire thing really such spaghetti? 2008-09-17 01:54 well, the request_queue, is apparently something you can pull out of the bio 2008-09-17 01:54 it's bogus to say "map kern" 2008-09-17 01:54 bio by default references kernel memory 2008-09-17 01:55 it's essentially just a vector of page headers 2008-09-17 01:55 the entire thing is pretty much that spagetti like or worse 2008-09-17 01:55 looks superficially plausible 2008-09-17 01:55 is mostly fluff when you dig 2008-09-17 01:56 the more I read this the more scared I am of running linux 2008-09-17 01:56 anyway, you now have officially arrived at the underbelly of linux 2008-09-17 01:56 few kernel hacks even look at this stuff 2008-09-17 01:56 I'd almost switch to windows... except better the devil you know, then devil you don't ;-) 2008-09-17 01:57 hah 2008-09-17 01:57 windows is worse with a very high degree of probability 2008-09-17 01:57 yeah, pretty sure of that 2008-09-17 01:57 bio is fast 2008-09-17 01:57 that's the redeeming thing 2008-09-17 01:57 I'm actually most annoyed about the complete lack of useful documentation 2008-09-17 01:58 yes, especially here 2008-09-17 01:58 nobody documents bios, it's new 2008-09-17 01:58 http://kerneltrap.org/man/linux/9?page=4 2008-09-17 01:58 have to let it age a bit first 2008-09-17 01:59 anyway, just write your root loader 2008-09-17 01:59 super loader 2008-09-17 01:59 then I'll kick sand at it ;) 2008-09-17 01:59 yeah, yeah, I hate writing without understanding 2008-09-17 02:00 bio is just a handle for a biovec which is just a vector of page heads with a short offset and length of data on each one 2008-09-17 02:00 it transfers to a _contiguous_ physical region 2008-09-17 02:00 right 2008-09-17 02:00 to or from 2008-09-17 02:00 the memory side can be completely discontiguous 2008-09-17 02:00 very useful 2008-09-17 02:00 it's physically contiguous? 2008-09-17 02:00 on disk it is 2008-09-17 02:00 as in on disk 2008-09-17 02:00 right 2008-09-17 02:01 not memory 2008-09-17 02:01 that's the most important aspect of the api 2008-09-17 02:01 it's just a preadv / pwritev 2008-09-17 02:01 there is tons of cruft you can ignore connected with queueing, elevatoring, and mapping bio to dma 2008-09-17 02:01 just ignore it 2008-09-17 02:01 you only care about the length field, sector address, count of bvecs, couple of other things 2008-09-17 02:02 transfer direction 2008-09-17 02:02 list is getting short 2008-09-17 02:02 endio 2008-09-17 02:02 private field 2008-09-17 02:02 fill in the fields, submit your bio, wait fot the computer to catch fire 2008-09-17 02:03 right, except bio_add_page takes pages, and I'm still not to clear on kaddr -> page conversion 2008-09-17 02:03 so I'm trying to parse that 2008-09-17 02:03 forget that 2008-09-17 02:04 just set the bvec fields yourself 2008-09-17 02:04 you only need to "map" a page in kernel if you're going to play with the data on it 2008-09-17 02:04 that's an advantage of using buffers 2008-09-17 02:04 they're always in kernel memory 2008-09-17 02:04 but 2008-09-17 02:04 you get to set up this bio 2008-09-17 02:04 virt_to_page(data) 2008-09-17 02:04 meaning you can allocate the page it's going to read the super into 2008-09-17 02:04 offset_in_page(kaddr); 2008-09-17 02:05 seem to be relevant 2008-09-17 02:05 and make that a kernel page 2008-09-17 02:05 so you don't have to "map" it 2008-09-17 02:05 you can already address it 2008-09-17 02:05 right, so I have a kmalloc 2008-09-17 02:05 which gives me a void * kaddr 2008-09-17 02:05 offset_in_page isn't anything I've used 2008-09-17 02:05 sounds like some more wanabe api 2008-09-17 02:06 so you're saying to literally fill in all the bio fields by hand? seems terrible 2008-09-17 02:06 not kmalloc, you want alloc_pages 2008-09-17 02:06 order 0 2008-09-17 02:06 = one page 2008-09-17 02:06 you'll write a helper 2008-09-17 02:06 just like everybody does 2008-09-17 02:06 nope 2008-09-17 02:06 and everybody writes a crappy helper that nobody else wants to use ;) 2008-09-17 02:06 why not kmalloc? I don't need a full page. 2008-09-17 02:07 I should be fine with kmalloc 2008-09-17 02:07 you can't store it in the bvec is why 2008-09-17 02:07 and then passing the converted - it'll work 2008-09-17 02:07 you need a _page_ 2008-09-17 02:07 I see it 2008-09-17 02:07 won't work 2008-09-17 02:07 bvecs point at struct pages 2008-09-17 02:07 don't be shy about taking a full page to read the superblock 2008-09-17 02:08 it's a tiny blip in terms of kernel memory wastage 2008-09-17 02:08 eh, it compiles 2008-09-17 02:08 it'll work - I'm stubborn 2008-09-17 02:08 kay, I'll wait for the code 2008-09-17 02:09 ;-) 2008-09-17 02:12 once you have done this you have figured out a huge part of the kernel io system 2008-09-17 02:13 it's actually simple, just wrapped in layers of crud to make it look complex 2008-09-17 02:19 hmm, well I have something which actually might work 2008-09-17 02:19 now to reread the code and then test it 2008-09-17 02:23 agh, lets test it live 2008-09-17 02:33 -!- MaZe(~MaZe@c-24-6-86-168.hsd1.ca.comcast.net) has joined #tux3 2008-09-17 02:33 hmm 2008-09-17 02:33 computer caught fire? 2008-09-17 02:33 not quite 2008-09-17 02:34 it didn't quite go away 2008-09-17 02:34 and I think it might have done something right 2008-09-17 02:34 but a reboot was needed 2008-09-17 02:34 no more testing live - not worth it 2008-09-17 02:34 right 2008-09-17 02:34 qemu or uml 2008-09-17 02:34 you got uml running didn't you? 2008-09-17 02:34 ACTION forgets 2008-09-17 02:35 Sep 17 02:25:00 nike kernel: loop: module loaded 2008-09-17 02:35 Sep 17 02:25:15 nike kernel: 0000: FA EB 21 5B 4D 61 5A 65 42 6F 6F 74 5D 00 60 B4 2008-09-17 02:35 Sep 17 02:25:15 nike kernel: 0010: 0E BB 07 00 89 E5 8B 76 10 FF 46 10 8A 04 FE 04 2008-09-17 02:35 Sep 17 02:25:15 nike kernel: 0020: CD 10 61 C3 31 C0 8E D0 BC 00 7C FB E8 DF FF 2A 2008-09-17 02:35 Sep 17 02:25:15 nike kernel: 0030: 8E D8 89 E6 06 8E C0 57 BF 00 06 FC B9 00 01 F3 2008-09-17 02:35 Sep 17 02:25:15 nike kernel: 0040: A5 EA 57 06 00 00 56 BB 07 00 B4 0E CD 10 5E AC 2008-09-17 02:35 Sep 17 02:25:15 nike kernel: 0050: 08 C0 75 F2 F4 EB FD E8 B4 FF 5B 89 C5 BF BE 07 2008-09-17 02:35 Sep 17 02:25:15 nike kernel: 0060: B1 04 E8 A9 FF 31 80 3D 80 75 0B 09 ED BE 22 07 2008-09-17 02:35 Sep 17 02:25:15 nike kernel: 0070: 75 DD 89 FD EB 08 80 3D 00 BE 3F 07 75 D1 83 C7 2008-09-17 02:35 Sep 17 02:25:15 nike kernel: 0080: 10 E2 DF E8 88 FF 5D 09 ED BE 5A 07 74 C1 E8 7D 2008-09-17 02:35 Sep 17 02:25:15 nike kernel: 0090: FF 76 BF 05 00 B4 41 BB AA 55 CD 13 72 33 81 FB 2008-09-17 02:35 Sep 17 02:25:15 nike kernel: 00A0: 55 AA 75 2D F6 C1 01 74 28 E8 62 FF 4C 8B 76 08 2008-09-17 02:35 Sep 17 02:25:15 nike kernel: 00B0: 89 36 1A 07 E8 57 FF 31 BE 12 07 B4 42 CD 13 BE 2008-09-17 02:35 Sep 17 02:25:15 nike kernel: 00C0: 97 07 73 33 31 C0 CD 13 4F 75 E9 BE 71 07 E9 7E 2008-09-17 02:35 Sep 17 02:25:15 nike kernel: 00D0: FF 8A 76 01 8B 4E 02 E8 34 FF 31 BB 00 7C B8 01 2008-09-17 02:35 Sep 17 02:25:15 nike kernel: 00E0: 02 57 CD 13 5F BE 9C 07 73 0D 31 C0 CD 13 4F 75 2008-09-17 02:35 Sep 17 02:25:15 nike kernel: 00F0: E6 BE 76 07 E9 58 FF E8 14 FF 3D 81 3E FE 7D 55 2008-09-17 02:35 qemu 2008-09-17 02:35 stil need to craft a better rootfs for it though 2008-09-17 02:36 so, was that a successful read or is that cruft? 2008-09-17 02:36 looks rather crufty 2008-09-17 02:36 0000000: faeb 215b 4d61 5a65 426f 6f74 5d00 60b4 ..![MaZeBoot].`. 2008-09-17 02:36 0000010: 0ebb 0700 89e5 8b76 10ff 4610 8a04 fe04 .......v..F..... 2008-09-17 02:36 0000020: cd10 61c3 31c0 8ed0 bc00 7cfb e8df ff2a ..a.1.....|....* 2008-09-17 02:36 0000030: 8ed8 89e6 068e c057 bf00 06fc b900 01f3 .......W........ 2008-09-17 02:36 0000040: a5ea 5706 0000 56bb 0700 b40e cd10 5eac ..W...V.......^. 2008-09-17 02:36 0000050: 08c0 75f2 f4eb fde8 b4ff 5b89 c5bf be07 ..u.......[..... 2008-09-17 02:36 0000060: b104 e8a9 ff31 803d 8075 0b09 edbe 2207 .....1.=.u....". 2008-09-17 02:36 0000070: 75dd 89fd eb08 803d 00be 3f07 75d1 83c7 u......=..?.u... 2008-09-17 02:36 0000080: 10e2 dfe8 88ff 5d09 edbe 5a07 74c1 e87d ......]...Z.t..} 2008-09-17 02:36 0000090: ff76 bf05 00b4 41bb aa55 cd13 7233 81fb .v....A..U..r3.. 2008-09-17 02:36 00000a0: 55aa 752d f6c1 0174 28e8 62ff 4c8b 7608 U.u-...t(.b.L.v. 2008-09-17 02:36 00000b0: 8936 1a07 e857 ff31 be12 07b4 42cd 13be .6...W.1....B... 2008-09-17 02:36 00000c0: 9707 7333 31c0 cd13 4f75 e9be 7107 e97e ..s31...Ou..q..~ 2008-09-17 02:36 00000d0: ff8a 7601 8b4e 02e8 34ff 31bb 007c b801 ..v..N..4.1..|.. 2008-09-17 02:36 00000e0: 0257 cd13 5fbe 9c07 730d 31c0 cd13 4f75 .W.._...s.1...Ou 2008-09-17 02:36 00000f0: e6be 7607 e958 ffe8 14ff 3d81 3efe 7d55 ..v..X....=.>.}U 2008-09-17 02:36 it worked! 2008-09-17 02:36 ooh, Mazeboot 2008-09-17 02:36 so it did perform the read from loop 2008-09-17 02:37 that's a hand crafted lba capable boot sector 2008-09-17 02:37 that I should get around to sending to hpa 2008-09-17 02:37 hpa? 2008-09-17 02:37 hpa@zytor.com 2008-09-17 02:37 what I thought 2008-09-17 02:37 I think is his nick, he's syslinux guy 2008-09-17 02:37 oh yes 2008-09-17 02:38 anyway, so the bio part mostly worked 2008-09-17 02:38 it must be a very special boot sector 2008-09-17 02:38 most likely locking got messed up somewhere 2008-09-17 02:38 or kfree happened to quickly 2008-09-17 02:38 you should post code around now 2008-09-17 02:38 give it a little more fiddling, then post 2008-09-17 02:38 hmm 2008-09-17 02:38 I'll post now 2008-09-17 02:38 :) 2008-09-17 02:38 since it'll take a while to get a rootfs 2008-09-17 02:39 static int junkfs_get_sb(struct file_system_type *fs_type, int flags, const char *dev_name, void *data, struct vfsmount *mnt) 2008-09-17 02:39 { 2008-09-17 02:39 <------>return get_sb_bdev(fs_type, flags, dev_name, data, junkfs_fill_super, mnt); 2008-09-17 02:39 } 2008-09-17 02:39 standard stuff 2008-09-17 02:39 i'll skip all the other stuff 2008-09-17 02:39 the important stuff is all in junkfs_fill_super 2008-09-17 02:39 ah, I thought this was your bio thing 2008-09-17 02:40 well 2008-09-17 02:40 I guess it is 2008-09-17 02:40 struct mz_t { 2008-09-17 02:40 <------>wait_queue_head_t wq; 2008-09-17 02:40 <------>int completed; 2008-09-17 02:40 }; 2008-09-17 02:40 nice and simple 2008-09-17 02:40 the struct to stick in the bio to wait on and mark completion 2008-09-17 02:40 static void end_io_read(struct bio *bio, int err) 2008-09-17 02:40 { 2008-09-17 02:40 <------>struct mz_t * mzp; 2008-09-17 02:40 <------>DBG_ENTER0(); 2008-09-17 02:40 <------>mzp = (struct mz_t *)bio->bi_private; 2008-09-17 02:40 <------>mzp->completed = 1; 2008-09-17 02:40 <------>bio_put(bio); 2008-09-17 02:40 you can post to tux3 list 2008-09-17 02:40 <------>wake_up(&mzp->wq); 2008-09-17 02:40 <------>DBG_RETURN0(); 2008-09-17 02:40 } 2008-09-17 02:40 don't be shy :) 2008-09-17 02:40 -!- pgquiles(~pgquiles@62.43.226.52.static.user.ono.com) has joined #tux3 2008-09-17 02:40 the end completion 2008-09-17 02:41 I'm shy. 2008-09-17 02:41 yes, good 2008-09-17 02:41 don't be 2008-09-17 02:41 I want to get a non-crashing version first 2008-09-17 02:41 optional, but if that's your fav... 2008-09-17 02:41 anyway the above just grabs the private part, marks it as completed, and wakes up the wq 2008-09-17 02:41 yes 2008-09-17 02:41 the bio_put might be the problem... 2008-09-17 02:41 it's right 2008-09-17 02:41 um 2008-09-17 02:41 might not, not sure 2008-09-17 02:42 should be ok 2008-09-17 02:42 #define SB_SIZE 512 2008-09-17 02:42 static int junkfs_fill_super(struct super_block *sb, void *data, int silent) 2008-09-17 02:42 { 2008-09-17 02:42 <------>struct mz_t *mz; 2008-09-17 02:42 <------>u8 *buf; 2008-09-17 02:42 <------>struct bio *bio; 2008-09-17 02:42 <------>int err; 2008-09-17 02:42 <------>int s, y, x; 2008-09-17 02:42 <------>DBG_ENTER0(); 2008-09-17 02:42 <------>mz = kmalloc(sizeof(struct mz_t), GFP_KERNEL); 2008-09-17 02:42 <------>if (IS_ERR(mz)) { 2008-09-17 02:42 <------><------>err = PTR_ERR(mz); 2008-09-17 02:42 <------><------>goto out_mz_null; 2008-09-17 02:42 <------>}; 2008-09-17 02:42 <------>init_waitqueue_head(&mz->wq); 2008-09-17 02:42 <------>mz->completed = 0; 2008-09-17 02:42 <------>buf = kmalloc(SB_SIZE, GFP_KERNEL); 2008-09-17 02:42 <------>if (IS_ERR(buf)) { 2008-09-17 02:42 <------><------>err = PTR_ERR(buf); 2008-09-17 02:42 <------><------>goto out_sb_null; 2008-09-17 02:42 <------>}; 2008-09-17 02:42 <------>bio = bio_alloc(GFP_KERNEL, 1); 2008-09-17 02:42 <------>if (IS_ERR(bio)) { 2008-09-17 02:42 <------><------>err = PTR_ERR(bio); 2008-09-17 02:42 <------><------>goto out_bio_null; 2008-09-17 02:42 <------>}; 2008-09-17 02:42 then we have the last function remaining - still very crufty 2008-09-17 02:42 basically, up till this point it's all kmalloc's 2008-09-17 02:43 <------>bio->bi_bdev = sb->s_bdev; 2008-09-17 02:43 <------>bio->bi_sector = 0; // first sector 2008-09-17 02:43 what we actually want to read - from sector 0 on our bdev 2008-09-17 02:43 <------>if (bio_add_page(bio, virt_to_page(buf), SB_SIZE, offset_in_page(buf)) == SB_SIZE) { 2008-09-17 02:43 <------><------>bio->bi_end_io = end_io_read; 2008-09-17 02:43 <------><------>bio->bi_private = mz; 2008-09-17 02:43 <------><------>submit_bio(READ, bio); 2008-09-17 02:43 <------><------>s = wait_event_interruptible(mz->wq, mz->completed); 2008-09-17 02:43 <------><------>DBG_MARK1(int, s); 2008-09-17 02:43 <------><------>for (y = 0; y < 16; ++y) { 2008-09-17 02:43 <------><------><------>printk(KERN_INFO "%04X:", y * 16); 2008-09-17 02:43 <------><------><------>for(x = 0; x < 16; ++x) { 2008-09-17 02:43 <------><------><------><------>printk(" %02X", buf[y * 16 + x]); 2008-09-17 02:43 <------><------><------>}; 2008-09-17 02:43 <------><------><------>printk("\n"); 2008-09-17 02:43 <------><------>}; 2008-09-17 02:43 <------>} else { 2008-09-17 02:43 <------><------>DBG_MARK0(); 2008-09-17 02:43 <------>}; 2008-09-17 02:43 <------>err = -1; 2008-09-17 02:44 there's the actual read, wait on wq, dump to dmesg 2008-09-17 02:44 ah, you did virt_to_page, that's how it worked 2008-09-17 02:44 forget that 2008-09-17 02:44 obviously the dump happened, and already had the proper content 2008-09-17 02:44 just to page = alloc_pages 2008-09-17 02:44 and use the page head directly, like all the other hacks 2008-09-17 02:44 kmallocing that will get you shouted at, trust me 2008-09-17 02:44 this is cleaner, I'm actually allocating exactly how much I need 2008-09-17 02:44 nope 2008-09-17 02:44 it's not good 2008-09-17 02:45 well 2008-09-17 02:45 unless you have an _actual_ other user of the page 2008-09-17 02:45 false economy 2008-09-17 02:45 so, you're saying grabing an empty page is cheaper? especially since it'll be returned soon anyway? 2008-09-17 02:45 it's very cheap 2008-09-17 02:45 <------>kfree(bio); 2008-09-17 02:45 <------>bio = NULL; 2008-09-17 02:45 out_bio_null: 2008-09-17 02:45 <------>kfree(sb); 2008-09-17 02:45 <------>sb = NULL; 2008-09-17 02:45 out_sb_null: 2008-09-17 02:45 <------>kfree(mz); 2008-09-17 02:45 and it's the superblock 2008-09-17 02:45 <------>mz = NULL; 2008-09-17 02:45 out_mz_null: 2008-09-17 02:46 <------>DBG_RETURN1(int, err); 2008-09-17 02:46 } 2008-09-17 02:46 and that's it 2008-09-17 02:46 it deserves a page of its own 2008-09-17 02:46 and this apparently reads and dumps correctly, but still has some nasty bug in it 2008-09-17 02:46 anyway, it looks good 2008-09-17 02:46 nothing to be shy about 2008-09-17 02:46 maybe the kfree(bio)? 2008-09-17 02:46 you can post that to the tux3 list 2008-09-17 02:46 yep 2008-09-17 02:46 don't do that 2008-09-17 02:46 you need to give that bio back to the bio system 2008-09-17 02:46 since bio_put already freed it? 2008-09-17 02:46 via bio_put 2008-09-17 02:46 right 2008-09-17 02:47 so I need to bio_put on the error path 2008-09-17 02:47 you might want to put some trace output in bio_put 2008-09-17 02:47 not on the normal return path? 2008-09-17 02:47 bio_endio should put the bio 2008-09-17 02:47 I forget 2008-09-17 02:47 very forgettable detail 2008-09-17 02:47 you need to look at the source 2008-09-17 02:48 well another endio func did bio_put 2008-09-17 02:48 hence I did as well 2008-09-17 02:48 there's a bio error mechanism too 2008-09-17 02:48 so kfree(bio) is the problem 2008-09-17 02:48 you can endio when you have an error 2008-09-17 02:48 and it will put the bio 2008-09-17 02:48 don't need to do it on a separate path 2008-09-17 02:48 right endio(bio,err) 2008-09-17 02:49 the big deal is, your wait queue and wake worked 2008-09-17 02:49 that's fun, hmm? 2008-09-17 02:49 powerful 2008-09-17 02:49 oh the wq was easy 2008-09-17 02:50 the only problem with wq, was the sometimes need for & or * 2008-09-17 02:52 I'm assuming writes would be just as simple 2008-09-17 02:54 yes 2008-09-17 02:54 it's symmetric 2008-09-17 02:59 anyway, once you have tracked down your double free I encourage you to post it to the tux3 list 2008-09-17 02:59 it's especially interesting now while it's still minimal 2008-09-17 03:01 -!- MaZe(~MaZe@c-24-6-86-168.hsd1.ca.comcast.net) has joined #tux3 2008-09-17 03:01 argh 2008-09-17 03:01