headers
Herbert Xu | 1 Oct 2005 03:13
Picon
Picon

Re: [RFC][PATCH] identify in_dev_get rcu read-side critical sections

On Thu, Sep 29, 2005 at 06:06:50PM -0700, Suzanne Wood wrote:
> 
> Are there three cases then?  RCU protection with refcnt, RCU without refcnt,
> and the bare cast of the dereference? 

Correct.

The following patch renames __in_dev_get() to __in_dev_get_rtnl() and
introduces __in_dev_get_rcu() to cover the second case.

1) RCU with refcnt should use in_dev_get().
2) RCU without refcnt should use __in_dev_get_rcu().
3) All others must hold RTNL and use __in_dev_get_rtnl().

There is one exception in net/ipv4/route.c which is in fact a pre-existing
race condition.  I've marked it as such so that we remember to fix it.

This patch is based on suggestions and prior work by Suzanne Wood and
Paul McKenney.

Signed-off-by: Herbert Xu <herbert <at> gondor.apana.org.au>

Cheers,
--

-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert <at> gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

(Continue reading)






Permalink
| Reply
| 0 comments  
| 



  

  

  





headers


Suzanne Wood
 | 
1 Oct 2005 08:56






Picon





Re: [RFC][PATCH] identify in_dev_get rcu read-side critical sections


Many thanks for addressing this issue.

----- Original Message ----- 
> From: Herbert Xu <herbert <at> gondor.apana.org.au>
> Date: Sat, 1 Oct 2005 11:13:12 +1000
> 
> On Thu, Sep 29, 2005 at 06:06:50PM -0700, Suzanne Wood wrote:
>> 
>> Are there three cases then?  RCU protection with refcnt, RCU without refcnt,
>> and the bare cast of the dereference? 
> 
> Correct.
> 
> The following patch renames __in_dev_get() to __in_dev_get_rtnl() and
> introduces __in_dev_get_rcu() to cover the second case.
> 
> 1) RCU with refcnt should use in_dev_get().
> 2) RCU without refcnt should use __in_dev_get_rcu().
> 3) All others must hold RTNL and use __in_dev_get_rtnl().
> 

The naming to indicate purpose looks good and the leading underscores
in the prior work did seem to imply wrapping to add functionality.

But it is interesting to have discarded what was developed yesterday
to minimize rcu_dereference impact:

>> ----- Original message  -----
>> From: Herbert Xu <herbert <at> gondor.apana.org.au>
>> Date: Fri, 30 Sep 2005 11:19:07 +1000

(Continue reading)






Permalink
| Reply
| 0 comments  
| 



  

  

  





headers


Herbert Xu
 | 
1 Oct 2005 09:12






Picon

Picon





Re: [RFC][PATCH] identify in_dev_get rcu read-side critical sections


On Fri, Sep 30, 2005 at 11:56:41PM -0700, Suzanne Wood wrote:
> 
> But it is interesting to have discarded what was developed yesterday
> to minimize rcu_dereference impact:
>
> >> ----- Original message  -----
> >> From: Herbert Xu <herbert <at> gondor.apana.org.au>
> >> Date: Fri, 30 Sep 2005 11:19:07 +1000
> >> 
> >> On Thu, Sep 29, 2005 at 06:16:03PM -0700, Paul E. McKenney wrote:
> >>> 
> >>> OK, how about this instead?
> >>> 
> >>> rcu_read_lock();
> >>> in_dev = dev->ip_ptr;
> >>> if (in_dev) {
> >>> atomic_inc(&rcu_dereference(in_dev)->refcnt);
> >>> }
> >>> rcu_read_unlock();
> >>> return in_dev;
> >> 
> >> Looks great. 
> 
> while adding a function call level by wrapping  __in_dev_get_rcu
> with in_dev_get as suggested here.

It might look different, but it should compile to the same result.
GCC should be smart enough to combine the two branches and produce a
memory barrier only when in_dev is not NULL.


(Continue reading)






Permalink
| Reply
| 0 comments  
| 



  

  

  





headers


demarcus matherly
 | 
1 Oct 2005 15:41





ball Approved E GP.  antiquarian



It's cheaper to your local drugg sttore.
Eliminate your pressure with our antidote.
Trusted universal carriage network for all deliveries.
Most of shoppers concur that ours is lesser cost.
For correct consumption, a professional will reassesses your meedical form.
I just taking in my antidotes, they are thump up, yes!! Syd J --DC.

http://uk.geocities.com/ainfocometrue/?mmnibmb

"The universe," he observed, "makes rather an indifferent parent, I am
afraid." 

flame-proof  datamonitor  dburch AH02 elaan  crescimento
And for what? For a mere folly, a masquerade, a little thing that he could
not let go. AND HE COULD EVEN LET IT GO, he told himself. But he had
promised to be in London at mid- summer, and he knew that he would go. . . .
It was impossible to live like this any longer. 
And this, then, was to be the disaster that his old professor had foreseen
for him: the crack in the wall, the crash, the cloud of dust. And he could
not understand how it had come about. He felt that he himself was unchanged,
that he was still there, the same man he had been five years ago, and that
he was sitting stupidly by and letting some resolute offshoot of himself
spoil his life for him. This new force was not he, it was but a part of him.
He would not even admit that it was stronger than he; but it was more
active. It was by its energy that this new feeling got the better of him.
His . was the woman who had made his life, gratified his pride, given
direction to his tastes and habits. The life they led together seemed to him
beautiful. Winifred still was, as she had always been, Romance for him, and
whenever he was deeply stirred he turned to her. When the grandeur and

(Continue reading)






Permalink
| Reply
| 0 comments  
| 



  

  

  





headers


Russell King
 | 
1 Oct 2005 15:35






Picon





[PATCH] sysctl_net.c:36: error: 'core_table' undeclared here


During the build for ARM machine type "fortunet", this error occurred:

  CC      net/sysctl_net.o
net/sysctl_net.c:36: error: 'core_table' undeclared here (not in a function)

The ARM configuration which produced this error can be found in:
 arch/arm/configs/fortunet_defconfig

where the relevant options are:
CONFIG_SYSCTL=y
CONFIG_NET=y
# CONFIG_INET is not set

core_table appears to be declared in net/sock.h.  if CONFIG_INET were
defined, net/sock.h would have been included via:
  sysctl_net.c -> net/ip.h -> linux/ip.h -> net/sock.h

so include it directly.

Signed-off-by: Russell King <rmk+kernel <at> arm.linux.org.uk>

(This patch is completely untested atm; we're waiting for the machine
to complete an existing build run.  However, I think this is fairly
obviously correct.)

diff --git a/net/sysctl_net.c b/net/sysctl_net.c
--- a/net/sysctl_net.c
+++ b/net/sysctl_net.c
 <at>  <at>  -16,6 +16,8  <at>  <at> 
 #include <linux/mm.h>

(Continue reading)






Permalink
| Reply
| 0 comments  
| 



  

  

  





headers


Adrian Bunk
 | 
1 Oct 2005 16:20






Picon





[RFC: 2.6 patch] net/sunrpc/: possible cleanups


This patch contains the following possible cleanups:
- make needlessly global code static
- #if 0 the following unused global function:
  - xdr.c: xdr_decode_string
- remove the following unneeded EXPORT_SYMBOL's:
  - auth_gss/gss_mech_switch.c: gss_mech_get
  - auth_gss/gss_mech_switch.c: gss_mech_get_by_name
  - auth_gss/gss_mech_switch.c: gss_mech_get_by_pseudoflavor
  - auth_gss/gss_mech_switch.c: gss_pseudoflavor_to_service
  - auth_gss/gss_mech_switch.c: gss_service_to_auth_domain_name
  - auth_gss/gss_mech_switch.c: gss_mech_put
  - sunrpc_syms.c: rpc_wake_up_next
  - sunrpc_syms.c: rpc_new_child
  - sunrpc_syms.c: rpc_run_child
  - sunrpc_syms.c: rpc_new_task
  - sunrpc_syms.c: rpc_release_task
  - sunrpc_syms.c: rpc_release_client
  - sunrpc_syms.c: xprt_udp_slot_table_entries
  - sunrpc_syms.c: xprt_tcp_slot_table_entries
  - sunrpc_syms.c: svc_drop
  - sunrpc_syms.c: svc_authenticate
  - sunrpc_syms.c: xdr_decode_string

Please review which of these patches do make sense and which conflict 
with pending patches.

Signed-off-by: Adrian Bunk <bunk <at> stusta.de>

---


(Continue reading)






Permalink
| Reply
| 1 comment  
| 



  

  

  





headers


Dich Vu Gui Email
 | 
1 Oct 2005 17:34






Picon





Giai Phap Marketting bang cach gui email cho khach hang


Toi dang co danh sach hon 200.000 dia chi email danh cho quy vi can quang ba san pham, thuong hieu. Bao gom cac
dia chi email
 <at> hn.vnn.vn
 <at> fpt.vn
 <at> netnam.vn
 <at> ten_cong_ty.com.vn
....
Va rat nhieu cac domain khac.
Ty le email chinh xac la 98%.

Khuyen mai them chuong trinh gui email rat manh
Gia 1.500.000/1 danh sach.
Hoac 300.000/1lan gui email.
Lien lac qua dia chi email: dich_vu_email <at> gmail.com hoac YM: dich_vu_email





Permalink
| Reply
| 0 comments  
| 



  

  

  





headers


Dich Vu Gui Email
 | 
1 Oct 2005 17:34






Picon





Giai Phap Marketting bang cach gui email cho khach hang


Toi dang co danh sach hon 200.000 dia chi email danh cho quy vi can quang ba san pham, thuong hieu. Bao gom cac
dia chi email
 <at> hn.vnn.vn
 <at> fpt.vn
 <at> netnam.vn
 <at> ten_cong_ty.com.vn
....
Va rat nhieu cac domain khac.
Ty le email chinh xac la 98%.

Khuyen mai them chuong trinh gui email rat manh
Gia 1.500.000/1 danh sach.
Hoac 300.000/1lan gui email.
Lien lac qua dia chi email: dich_vu_email <at> gmail.com hoac YM: dich_vu_email





Permalink
| Reply
| 0 comments  
| 



  

  

  





headers


Michael Bellion
 | 
1 Oct 2005 17:38





Re: [ANNOUNCE] Release of nf-HiPAC 0.9.0


Hi

> > I am happy to announce the release of nf-HiPAC version 0.9.0
>
> Looking forward to talking to you about it next week!

Yes, I am looking forward to meet you and the rest of the netfilter developers 
again at the workshop next week too. The workshop has always been a lot of 
fun with a lot of interesting discussions. With the 2 days of the workshop 
and the 2 extra days of hacking on code there will probably be plenty of time 
to talk about the current state and future directions of the HiPAC project.

See you next week
	Michael Bellion







Permalink
| Reply
| 0 comments  
| 



  

  

  





headers


Alexey Dobriyan
 | 
1 Oct 2005 18:40






Picon





Re: [RFC: 2.6 patch] net/sunrpc/: possible cleanups


On Sat, Oct 01, 2005 at 04:20:41PM +0200, Adrian Bunk wrote:
> -/* Just increments the mechanism's reference count and returns its input: */
> -struct gss_api_mech * gss_mech_get(struct gss_api_mech *);
> -

> -struct gss_api_mech *
> +static struct gss_api_mech *
>  gss_mech_get(struct gss_api_mech *gm)

Comment is lost.







Permalink
| Reply
| 1 comment  
| 



  

  

  

  


  





    



Gmane