Unreliable Guide to Locking - Addition?
Hi Rusty, I was going through the splendidly written document, "Unreliable Guide to Locking". I thought of something that should be mentioned in the section "Using Atomic Operations For The Reference Count" (link : http://www.kernel.org/pub/linux/kernel/people/rusty/kernel-locking/x352.html#EXAMPLES-REFCNT-ATOMIC) I guess, probably the section should also mention that " There is one race condition while using atomic_t, which is as follows : * The refcount of the object is "1". * Process A tries to perform atomic_dec_and_test(), gets "0" and hence performs a kfree() on the object. * Process B tries to perform atomic_inc() on the object. * It may so happen that the atomic_inc() of Process B is called after atomic_dec_and_test(), but before the kfree() call, which is a race condition. Usually, this race condition is avoided as: when the last atomic_dec_and_test() (the last == the one which returns 0) is being called on the object, the object is usually not accessible to others (list_del()) and hence the simultaneous atomic_inc() call never occurs. " Do you think this race condition should be included in the document? Thanks, Kedar. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Unreliable Guide to Locking - Addition?
Hi Rusty, I was going through the splendidly written document, Unreliable Guide to Locking. I thought of something that should be mentioned in the section Using Atomic Operations For The Reference Count (link : http://www.kernel.org/pub/linux/kernel/people/rusty/kernel-locking/x352.html#EXAMPLES-REFCNT-ATOMIC) I guess, probably the section should also mention that There is one race condition while using atomic_t, which is as follows : * The refcount of the object is 1. * Process A tries to perform atomic_dec_and_test(), gets 0 and hence performs a kfree() on the object. * Process B tries to perform atomic_inc() on the object. * It may so happen that the atomic_inc() of Process B is called after atomic_dec_and_test(), but before the kfree() call, which is a race condition. Usually, this race condition is avoided as: when the last atomic_dec_and_test() (the last == the one which returns 0) is being called on the object, the object is usually not accessible to others (list_del()) and hence the simultaneous atomic_inc() call never occurs. Do you think this race condition should be included in the document? Thanks, Kedar. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Kernel SCM saga.. (bk license?)
I was wondering if working on git, is in anyway, in violation of the Bitkeeper license, which states that you cannot work on any other SCM (SCM-like?) tool for "x" amount of time after using Bitkeeper ? Kedar. On Apr 8, 2005 10:12 AM, Linus Torvalds <[EMAIL PROTECTED]> wrote: > > > On Thu, 7 Apr 2005, Chris Wedgwood wrote: > > > > I'm playing with monotone right now. Superficially it looks like it > > has tons of gee-whiz neato stuff... however, it's *agonizingly* slow. > > I mean glacial. A heavily sedated sloth with no legs is probably > > faster. > > Yes. The silly thing is, at least in my local tests it doesn't actually > seem to be _doing_ anything while it's slow (there are no system calls > except for a few memory allocations and de-allocations). It seems to have > some exponential function on the number of pathnames involved etc. > > I'm hoping they can fix it, though. The basic notions do not sound wrong. > > In the meantime (and because monotone really _is_ that slow), here's a > quick challenge for you, and any crazy hacker out there: if you want to > play with something _really_ nasty (but also very _very_ fast), take a > look at kernel.org:/pub/linux/kernel/people/torvalds/. > > First one to send me the changelog tree of sparse-git (and a tool to > commit and push/pull further changes) gets a gold star, and an honorable > mention. I've put a hell of a lot of clues in there (*). > > I've worked on it (and little else) for the last two days. Time for > somebody else to tell me I'm crazy. > > Linus > > (*) It should be easier than it sounds. The database is designed so that > you can do the equivalent of a nonmerging (ie pure superset) push/pull > with just plain rsync, so replication really should be that easy (if > somewhat bandwidth-intensive due to the whole-file format). > > Never mind merging. It's not an SCM, it's a distribution and archival > mechanism. I bet you could make a reasonable SCM on top of it, though. > Another way of looking at it is to say that it's really a content- > addressable filesystem, used to track directory trees. > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Kernel SCM saga.. (bk license?)
I was wondering if working on git, is in anyway, in violation of the Bitkeeper license, which states that you cannot work on any other SCM (SCM-like?) tool for x amount of time after using Bitkeeper ? Kedar. On Apr 8, 2005 10:12 AM, Linus Torvalds [EMAIL PROTECTED] wrote: On Thu, 7 Apr 2005, Chris Wedgwood wrote: I'm playing with monotone right now. Superficially it looks like it has tons of gee-whiz neato stuff... however, it's *agonizingly* slow. I mean glacial. A heavily sedated sloth with no legs is probably faster. Yes. The silly thing is, at least in my local tests it doesn't actually seem to be _doing_ anything while it's slow (there are no system calls except for a few memory allocations and de-allocations). It seems to have some exponential function on the number of pathnames involved etc. I'm hoping they can fix it, though. The basic notions do not sound wrong. In the meantime (and because monotone really _is_ that slow), here's a quick challenge for you, and any crazy hacker out there: if you want to play with something _really_ nasty (but also very _very_ fast), take a look at kernel.org:/pub/linux/kernel/people/torvalds/. First one to send me the changelog tree of sparse-git (and a tool to commit and push/pull further changes) gets a gold star, and an honorable mention. I've put a hell of a lot of clues in there (*). I've worked on it (and little else) for the last two days. Time for somebody else to tell me I'm crazy. Linus (*) It should be easier than it sounds. The database is designed so that you can do the equivalent of a nonmerging (ie pure superset) push/pull with just plain rsync, so replication really should be that easy (if somewhat bandwidth-intensive due to the whole-file format). Never mind merging. It's not an SCM, it's a distribution and archival mechanism. I bet you could make a reasonable SCM on top of it, though. Another way of looking at it is to say that it's really a content- addressable filesystem, used to track directory trees. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: wait queue sharing..
Yes, technically, you can share the wait queue between two modules. Ofcourse, provided you can manage to initialise it before any use. Kedar. On Fri, 11 Mar 2005 17:11:18 +0530, Mohan <[EMAIL PROTECTED]> wrote: > Hello All, > > I have a question regarding the wait queues. I have a driver > pxausb_core.o which is the core driver which does all USB endpoint > handling and hardware interaction. I have one more driver on top of it > usb-serial which provides for the user-level interaction(like read, > write, ioctl). > I have implemented a blocking ioctl, which sends events about the state > of USB device(enumerated, suspended, disconnected, etc). > For this ioctl, i have declared a wait_queue and initialized (using > init_waitqueue_head() func.) in the usb_ctl.c which is part of > pxausb_core.o. (it has usb_send.c, usb_recv.c, usb_ctl.c, usb_ep0.c). > I am using that wait_queue variable in usb-ser.c. > > I just wanted to clarify myself whether the wait queues can be shared > between two driver modules. > > Thank you... > regards, > mohan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: wait queue sharing..
Yes, technically, you can share the wait queue between two modules. Ofcourse, provided you can manage to initialise it before any use. Kedar. On Fri, 11 Mar 2005 17:11:18 +0530, Mohan [EMAIL PROTECTED] wrote: Hello All, I have a question regarding the wait queues. I have a driver pxausb_core.o which is the core driver which does all USB endpoint handling and hardware interaction. I have one more driver on top of it usb-serial which provides for the user-level interaction(like read, write, ioctl). I have implemented a blocking ioctl, which sends events about the state of USB device(enumerated, suspended, disconnected, etc). For this ioctl, i have declared a wait_queue and initialized (using init_waitqueue_head() func.) in the usb_ctl.c which is part of pxausb_core.o. (it has usb_send.c, usb_recv.c, usb_ctl.c, usb_ep0.c). I am using that wait_queue variable in usb-ser.c. I just wanted to clarify myself whether the wait queues can be shared between two driver modules. Thank you... regards, mohan - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
