Mail Archive Search: <+subject:/^(?:^\s*(re|sv|fwd|fw)[\[\]\d]*[:>-]+\s*)*\[RFC\]\s+add\s+rtnl\s+semaphore\s+to\s+linux\-atm\s*$/>

Results:

References: [ +subject:/^(?:^\s*(re|sv|fwd|fw)[\[\]\d]*[:>-]+\s*)*\[RFC\]\s+add\s+rtnl\s+semaphore\s+to\s+linux\-atm\s*$/: 32 ]

Total 32 documents matching your query.

1. [RFC] add rtnl semaphore to linux-atm (score: 1): Author: chas williams <chas@xxxxxxxxxxxxxxxx>; Date: Wed, 01 Oct 2003 07:34:25 -0400; i am thinking about doing the following to fix the race during ATM_ITF_ANY operation. rtnl is held across registration/unregistration. this means that you can get read-only access to the device list; /archives/netdev/2003-10/msg00007.html (19,896 bytes)
2. Re: [RFC] add rtnl semaphore to linux-atm (score: 1): Author: "David S. Miller" <davem@xxxxxxxxxx>; Date: Wed, 1 Oct 2003 05:42:26 -0700; This looks like it would work. Although, unless VCC connect can potentially sleep, it might be better to keep exporting the rwlock and take it as a reader instead of grabbing the rtnl semaphore.; /archives/netdev/2003-10/msg00008.html (9,102 bytes)
3. Re: [RFC] add rtnl semaphore to linux-atm (score: 1): Author: chas williams <chas@xxxxxxxxxxxxxxxx>; Date: Wed, 01 Oct 2003 09:07:45 -0400; i had initially written it that way but remembered at one point i was going to use the rtnl semaphore to handle this problem. any opinions on what is 'better'?; /archives/netdev/2003-10/msg00009.html (8,932 bytes)
4. Re: [RFC] add rtnl semaphore to linux-atm (score: 1): Author: "David S. Miller" <davem@xxxxxxxxxx>; Date: Wed, 1 Oct 2003 06:14:26 -0700; Blocking all network configuration operations (even ones not for your subsystem) is a little bit anti-social in SMP cases. If you take the rwlock as a reader, you only interfere with a very minute cl; /archives/netdev/2003-10/msg00010.html (9,632 bytes)
5. Re: [RFC] add rtnl semaphore to linux-atm (score: 1): Author: Mitchell Blank Jr <mitch@xxxxxxxxxx>; Date: Thu, 2 Oct 2003 19:26:15 -0700; VCC connect can definately sleep - a good example is drirvers/usb/misc/speedtch.c but there are probably other ones. My personal recommendations: * There should be a per-atm-device semaphore held acr; /archives/netdev/2003-10/msg00060.html (11,480 bytes)
6. Re: [RFC] add rtnl semaphore to linux-atm (score: 1): Author: "David S. Miller" <davem@xxxxxxxxxx>; Date: Fri, 3 Oct 2003 06:58:24 -0700; Ok, but what Chas is trying to do is move the ATM device stuff over to a model that makes use of the existing network device infrastructure for solving these kinds of problems. Part of that is using; /archives/netdev/2003-10/msg00083.html (10,165 bytes)
7. Re: [RFC] add rtnl semaphore to linux-atm (score: 1): Author: Mitchell Blank Jr <mitch@xxxxxxxxxx>; Date: Fri, 3 Oct 2003 14:45:41 -0700; I have no problem with using rtnl_sem to syncronize the atmdev->{open, close,change_qos}() paths instead of a per-device semaphore. We *can't* use it to protect the state of the vcc list though becau; /archives/netdev/2003-10/msg00098.html (10,919 bytes)
8. Re: [RFC] add rtnl semaphore to linux-atm (score: 1): Author: "David S. Miller" <davem@xxxxxxxxxx>; Date: Fri, 3 Oct 2003 22:16:40 -0700; The semaphore protects "modifications", it basically serializes them. You still need a rwlock to protect the actual lists and this rwlock is what the interrupt/bh context code takes to traverse the l; /archives/netdev/2003-10/msg00103.html (10,305 bytes)
9. Re: [RFC] add rtnl semaphore to linux-atm (score: 1): Author: Mitchell Blank Jr <mitch@xxxxxxxxxx>; Date: Fri, 3 Oct 2003 22:55:26 -0700; I think we're saying approximately the same thing at this point. I'm just trying to make the point that the spinlock (or rwlock, whatever) can't be held when we call atm_dev->{open,close}() since the; /archives/netdev/2003-10/msg00104.html (11,125 bytes)
10. Re: [RFC] add rtnl semaphore to linux-atm (score: 1): Author: Mitchell Blank Jr <mitch@xxxxxxxxxx>; Date: Fri, 3 Oct 2003 23:56:29 -0700; Actually I guess there's two ways of doing it... so instead of Method 1: 1. Take rwlock for writing 2. Search for {dev,vpi,vci} tuple. If found, fail - otherwise add it as "inactive" 3. Drop rwlock 4; /archives/netdev/2003-10/msg00108.html (11,134 bytes)
11. Re: [RFC] add rtnl semaphore to linux-atm (score: 1): Author: Mitchell Blank Jr <mitch@xxxxxxxxxx>; Date: Fri, 3 Oct 2003 23:59:25 -0700; I've thought about this some more and I think we really DO want a per-atm-device semaphore for this rather than overloading rtnl_sem. A device like an ADSL card might need to do a complete physical-l; /archives/netdev/2003-10/msg00110.html (10,049 bytes)
12. Re: [RFC] add rtnl semaphore to linux-atm (score: 1): Author: chas williams <chas@xxxxxxxxxxxxxxxx>; Date: Sat, 04 Oct 2003 08:50:00 -0400; just to summarize the last couple messages and my thoughts about all of this: atm_dev will become a netdevice in the future. there is no good reason it shouldnt. the atm layer needs to start doing th; /archives/netdev/2003-10/msg00111.html (11,280 bytes)
13. Re: [RFC] add rtnl semaphore to linux-atm (score: 1): Author: Mitchell Blank Jr <mitch@xxxxxxxxxx>; Date: Sat, 4 Oct 2003 12:42:42 -0700; Agreed. I'm not sure if it's a giant win (since atm devices are pretty unique) but you seem pretty gung-ho about converting it so I'll trust you on it. Well that might be true in the tree. I think as; /archives/netdev/2003-10/msg00112.html (13,347 bytes)
14. Re: [RFC] add rtnl semaphore to linux-atm (score: 1): Author: xxxxxx>; Date: Sun, 05 Oct 2003 08:52:58 -0400; well if you ignore the sysfs and notifier handling provided by netdevice and rtnetlink then no you dont really gain anything. but i can see a use for both of these things. like to watching the carrie; /archives/netdev/2003-10/msg00127.html (13,294 bytes)
15. Re: [RFC] add rtnl semaphore to linux-atm (score: 1): Author: xxxxxx>; Date: Mon, 6 Oct 2003 02:03:04 -0700; Yeah, I've been trying to get that resolved but so far noone is anwering my emails. There are two DSL drivers in some state of completion that could be merged if the companies involved to just releas; /archives/netdev/2003-10/msg00139.html (11,860 bytes)
16. Re: [RFC] add rtnl semaphore to linux-atm (score: 1): Author: xxxxxx>; Date: Mon, 06 Oct 2003 10:46:25 -0400; i think the vswitch stuff used it. but it can be made to work w/o too much trouble. so if it isnt a problem why fix it? further, if, as you say, open and close could sleep and possibly for long perio; /archives/netdev/2003-10/msg00143.html (10,753 bytes)
17. [RFC] add rtnl semaphore to linux-atm (score: 1): Author: chas williams <chas@xxxxxxxxxxxxxxxx>; Date: Wed, 01 Oct 2003 07:34:25 -0400; i am thinking about doing the following to fix the race during ATM_ITF_ANY operation. rtnl is held across registration/unregistration. this means that you can get read-only access to the device list; /archives/netdev/2003-10/msg00749.html (19,896 bytes)
18. Re: [RFC] add rtnl semaphore to linux-atm (score: 1): Author: "David S. Miller" <davem@xxxxxxxxxx>; Date: Wed, 1 Oct 2003 05:42:26 -0700; This looks like it would work. Although, unless VCC connect can potentially sleep, it might be better to keep exporting the rwlock and take it as a reader instead of grabbing the rtnl semaphore.; /archives/netdev/2003-10/msg00750.html (9,172 bytes)
19. Re: [RFC] add rtnl semaphore to linux-atm (score: 1): Author: chas williams <chas@xxxxxxxxxxxxxxxx>; Date: Wed, 01 Oct 2003 09:07:45 -0400; i had initially written it that way but remembered at one point i was going to use the rtnl semaphore to handle this problem. any opinions on what is 'better'?; /archives/netdev/2003-10/msg00751.html (9,009 bytes)
20. Re: [RFC] add rtnl semaphore to linux-atm (score: 1): Author: "David S. Miller" <davem@xxxxxxxxxx>; Date: Wed, 1 Oct 2003 06:14:26 -0700; Blocking all network configuration operations (even ones not for your subsystem) is a little bit anti-social in SMP cases. If you take the rwlock as a reader, you only interfere with a very minute cl; /archives/netdev/2003-10/msg00752.html (9,739 bytes)

Current List: 1 - 20
Page: [1] [2]