Having just spent the weekend tracking two separate driver model problems through SCSI, I believe the biggest trap everyone falls into with the driver model (well, OK, at least with SCSI) is to try to defer a callback to the device ->release routine without realising that somewhere along the callback path we're going to drop a reference to the device. You can do this very inadvertently: One developer didn't realise bsg_unregister_queue() released a ref, and another didn't realise that transport_destroy_device() held one. The real problem is that it's fantastically easy to do this ... it's not at all clear which of the cleanup routines actually release references unless you dig down into them and it's very difficult to detect because all that happens is that devices don't get released when they should, which isn't something we ever warn about. So, what I was wondering is: is there any way we can reliably detect and warn when someone does this. Could something like lockdep (although I can't really see how dynamic detection will work because the device ->release routine is never called) or a static code analysis tool like sparse be modified to detect the unreleaseable references? James --
| Ryan Hope | reiser4 for 2.6.27-rc1 |
| Ingo Molnar | Re: 2.6.24-rc6-mm1 |
| Tim Tassonis | reiser4 for 2.6.27-rc1 |
| Ingo Molnar | Re: [patch] MTD: fix DOC2000/2001/2001PLUS build error |
git: | |
| Petko Manolov | git and binary files |
| Wink Saville | Resolving conflicts |
| Ken Pratt | pack operation is thrashing my server |
| Junio C Hamano | What's cooking in git.git (Aug 2008, #07; Sat, 23) |
| Richard Stallman | Real men don't attack straw men |
| Julien TOUCHE | setting up ssh tunnel/vpn |
| Jeffrey 'jf' Lim | Re: SSHJail patch for OpenBSD |
| Daniel Ouellet | identifying sparse files and get ride of them trick available? |
| Jim Winstead Jr. | Re: Root Disk/Book Disk Compatibility |
| Peter MacDonald | demand paging: proposal |
| Stephen Pierce | SLS |
| Drew Eckhardt | Re: 20MB drive & wdxt-gen2 controller on 386? |
