Re: [BUG] 2.2.1[78] : RTNETLINK lock not properly locking ?
> It is linux-2.2, guy. 8) "threads" are not threaded there. > > Semaphores (rtnl_lock, particularly) protects only areas, which > are going to _schedule_ excplicitly or implicitly. ok, thanks a lot Alexey, now I understand. > Please, read comments. People used to consider comments as something > decorative, but they are not. I did read them again and again, but you know, when there's something you don't understand, sometimes you interprete things badly. > Any questions? not anymore, of course :-) > Sorry... > > /* NOTE: these locks are not interrupt safe, are not SMP safe, > * they are even not atomic. 8)8)8) ... and it is not a bug. > etc. > > Do you call this "very precautios"? 8) I spoke about the first ones :) thanks a lot, now I know how to proceed. Cheers, Willy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [BUG] 2.2.1[78] : RTNETLINK lock not properly locking ?
Hello! >- it will nearly never allow concurrent accesses (seems to be what was > intented when it was written) Never, to be more exact. Concurrent accesses are allowed only with rtnetlink. In 2.4 it is always exclusive, because shared access turned out to be mostly useless. >- it will not always prevent concurrent accesses, which is weird because > rtnl_lock() only relies on rtnl_shlock() (and exlock, which is empty) to > protect sensible areas It is linux-2.2, guy. 8) "threads" are not threaded there. Semaphores (rtnl_lock, particularly) protects only areas, which are going to _schedule_ excplicitly or implicitly. > ok, Dave. But the code in dev_ioctl() actually is : > > rtnl_lock(); > ret = dev_ifsioc(, cmd); > rtnl_unlock(); > > if only these lock/unlock guarantee this atomicity, then I can't > see why my A,B,C case could not work. If this is because the > kernel has been locked somewhere else, then why are the locks > still needed ? Please, read comments. People used to consider comments as something decorative, but they are not. The first group of ioctls (no lock!): /* * These ioctl calls: * - can be done by all. * - atomic and do not require locking. * - return a value */ The second group of ioctls (locked): /* * These ioctl calls: * - require superuser power. * - require strict serialization. * - do not return a value */ Any questions? >The author of rtnetlink.h has been very precautious > about the atomicity of these locks when CONFIG_RTNETLINK is set. Sorry... /* NOTE: these locks are not interrupt safe, are not SMP safe, * they are even not atomic. 8)8)8) ... and it is not a bug. etc. Do you call this "very precautios"? 8) I would say that I was absolutely careless about their atomicity because it is useless before BKL has been removed. Alexey - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [BUG] 2.2.1[78] : RTNETLINK lock not properly locking ?
> No, it guarentees that only one process may be in the middle > of modifying interface configuration state, the same and only > guarentee it makes in 2.4.x as well. ok, Dave. But the code in dev_ioctl() actually is : rtnl_lock(); ret = dev_ifsioc(, cmd); rtnl_unlock(); if only these lock/unlock guarantee this atomicity, then I can't see why my A,B,C case could not work. If this is because the kernel has been locked somewhere else, then why are the locks still needed ? The author of rtnetlink.h has been very precautious about the atomicity of these locks when CONFIG_RTNETLINK is set. I don't understand why this could change in other cases. For this reason, I don't know what to write in my code ... Regards, Willy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [BUG] 2.2.1[78] : RTNETLINK lock not properly locking ?
Date:Wed, 22 Nov 2000 12:27:57 +0100 (MET) From: Willy Tarreau <[EMAIL PROTECTED]> Quoting "David S. Miller" <[EMAIL PROTECTED]>: > All of this is protected by lock_kernel() so none of the > A,B,C,whatever spots can be interrupted in 2.2.x so, does this mean that rtnl_*lock* are completely useless ??? No, it guarentees that only one process may be in the middle of modifying interface configuration state, the same and only guarentee it makes in 2.4.x as well. Later, David S. Miller [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [BUG] 2.2.1[78] : RTNETLINK lock not properly locking ?
Quoting "David S. Miller" <[EMAIL PROTECTED]>: >Date: Wed, 22 Nov 2000 10:39:03 +0100 (MET) >From: Willy Tarreau <[EMAIL PROTECTED]> > >Thanks in advance for any comment, > > All of this is protected by lock_kernel() so none of the > A,B,C,whatever spots can be interrupted in 2.2.x so, does this mean that rtnl_*lock* are completely useless ??? Willy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [BUG] 2.2.1[78] : RTNETLINK lock not properly locking ?
Date:Wed, 22 Nov 2000 10:39:03 +0100 (MET) From: Willy Tarreau <[EMAIL PROTECTED]> Thanks in advance for any comment, All of this is protected by lock_kernel() so none of the A,B,C,whatever spots can be interrupted in 2.2.x Later, David S. Miller [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [BUG] 2.2.1[78] : RTNETLINK lock not properly locking ?
Hello! - it will nearly never allow concurrent accesses (seems to be what was intented when it was written) Never, to be more exact. Concurrent accesses are allowed only with rtnetlink. In 2.4 it is always exclusive, because shared access turned out to be mostly useless. - it will not always prevent concurrent accesses, which is weird because rtnl_lock() only relies on rtnl_shlock() (and exlock, which is empty) to protect sensible areas It is linux-2.2, guy. 8) "threads" are not threaded there. Semaphores (rtnl_lock, particularly) protects only areas, which are going to _schedule_ excplicitly or implicitly. ok, Dave. But the code in dev_ioctl() actually is : rtnl_lock(); ret = dev_ifsioc(ifr, cmd); rtnl_unlock(); if only these lock/unlock guarantee this atomicity, then I can't see why my A,B,C case could not work. If this is because the kernel has been locked somewhere else, then why are the locks still needed ? Please, read comments. People used to consider comments as something decorative, but they are not. The first group of ioctls (no lock!): /* * These ioctl calls: * - can be done by all. * - atomic and do not require locking. * - return a value */ The second group of ioctls (locked): /* * These ioctl calls: * - require superuser power. * - require strict serialization. * - do not return a value */ Any questions? The author of rtnetlink.h has been very precautious about the atomicity of these locks when CONFIG_RTNETLINK is set. Sorry... /* NOTE: these locks are not interrupt safe, are not SMP safe, * they are even not atomic. 8)8)8) ... and it is not a bug. etc. Do you call this "very precautios"? 8) I would say that I was absolutely careless about their atomicity because it is useless before BKL has been removed. Alexey - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [BUG] 2.2.1[78] : RTNETLINK lock not properly locking ?
It is linux-2.2, guy. 8) "threads" are not threaded there. Semaphores (rtnl_lock, particularly) protects only areas, which are going to _schedule_ excplicitly or implicitly. ok, thanks a lot Alexey, now I understand. Please, read comments. People used to consider comments as something decorative, but they are not. I did read them again and again, but you know, when there's something you don't understand, sometimes you interprete things badly. Any questions? not anymore, of course :-) Sorry... /* NOTE: these locks are not interrupt safe, are not SMP safe, * they are even not atomic. 8)8)8) ... and it is not a bug. etc. Do you call this "very precautios"? 8) I spoke about the first ones :) thanks a lot, now I know how to proceed. Cheers, Willy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [BUG] 2.2.1[78] : RTNETLINK lock not properly locking ?
Quoting "David S. Miller" [EMAIL PROTECTED]: Date: Wed, 22 Nov 2000 10:39:03 +0100 (MET) From: Willy Tarreau [EMAIL PROTECTED] Thanks in advance for any comment, All of this is protected by lock_kernel() so none of the A,B,C,whatever spots can be interrupted in 2.2.x so, does this mean that rtnl_*lock* are completely useless ??? Willy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [BUG] 2.2.1[78] : RTNETLINK lock not properly locking ?
No, it guarentees that only one process may be in the middle of modifying interface configuration state, the same and only guarentee it makes in 2.4.x as well. ok, Dave. But the code in dev_ioctl() actually is : rtnl_lock(); ret = dev_ifsioc(ifr, cmd); rtnl_unlock(); if only these lock/unlock guarantee this atomicity, then I can't see why my A,B,C case could not work. If this is because the kernel has been locked somewhere else, then why are the locks still needed ? The author of rtnetlink.h has been very precautious about the atomicity of these locks when CONFIG_RTNETLINK is set. I don't understand why this could change in other cases. For this reason, I don't know what to write in my code ... Regards, Willy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [BUG] 2.2.1[78] : RTNETLINK lock not properly locking ?
Date:Wed, 22 Nov 2000 10:39:03 +0100 (MET) From: Willy Tarreau [EMAIL PROTECTED] Thanks in advance for any comment, All of this is protected by lock_kernel() so none of the A,B,C,whatever spots can be interrupted in 2.2.x Later, David S. Miller [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [BUG] 2.2.1[78] : RTNETLINK lock not properly locking ?
Date:Wed, 22 Nov 2000 12:27:57 +0100 (MET) From: Willy Tarreau [EMAIL PROTECTED] Quoting "David S. Miller" [EMAIL PROTECTED]: All of this is protected by lock_kernel() so none of the A,B,C,whatever spots can be interrupted in 2.2.x so, does this mean that rtnl_*lock* are completely useless ??? No, it guarentees that only one process may be in the middle of modifying interface configuration state, the same and only guarentee it makes in 2.4.x as well. Later, David S. Miller [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
