I've been doing an overhaul of the w1 netlink system and have a patch
outstanding to address this issue. It requires patches already
accepted in gregkh char-misc-next.
w1: fix netlink refcnt leak on error path
I avoided the issue by checking the length before taking any
references to avoid
I've been doing an overhaul of the w1 netlink system and have a patch
outstanding to address this issue. It requires patches already
accepted in gregkh char-misc-next.
w1: fix netlink refcnt leak on error path
I avoided the issue by checking the length before taking any
references to avoid
If userspace sends a w1 message of length 0 we leak
the refcount.
Signed-off-by: Richard Weinberger
---
drivers/w1/w1_netlink.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/w1/w1_netlink.c b/drivers/w1/w1_netlink.c
index 40788c9..7131777 100644
---
If userspace sends a w1 message of length 0 we leak
the refcount.
Signed-off-by: Richard Weinberger rich...@nod.at
---
drivers/w1/w1_netlink.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/w1/w1_netlink.c b/drivers/w1/w1_netlink.c
index 40788c9..7131777 100644
t; commit 04f482faf50535229a5a5c8d629cf963899f857c
> Author: Patrick McHardy
> Date: Mon Mar 28 08:39:36 2011 +
Good job. I was too lazy to bisect for bad commit;)
Reading the code I found problematic kthread_should_stop call from netlink
connector which causes the oops. After applying a patch, I've been testin
04f482faf50535229a5a5c8d629cf963899f857c
Author: Patrick McHardy ka...@trash.net
Date: Mon Mar 28 08:39:36 2011 +
Good job. I was too lazy to bisect for bad commit;)
Reading the code I found problematic kthread_should_stop call from netlink
connector which causes the oops. After applying a patch, I've
3.0-stable review patch. If anyone has any objections, please let me know.
--
From: Olaf Hering
commit bcc2c9c3fff859e0eb019fe6fec26f9b8eba795c upstream.
The SuSE security team suggested to use recvfrom instead of recv to be
certain that the connector message is originated
3.0-stable review patch. If anyone has any objections, please let me know.
--
From: Olaf Hering o...@aepfle.de
commit bcc2c9c3fff859e0eb019fe6fec26f9b8eba795c upstream.
The SuSE security team suggested to use recvfrom instead of recv to be
certain that the connector message is
hould_stop call from netlink
connector which causes the oops. After applying a patch, I've been testing
owfs+w1 setup for nearly two days and it seems to work very reliable (no
hangs, no memleaks etc).
More detailed description and possible fix is given below:
Function w1_search can be called from
problematic kthread_should_stop call from netlink
connector which causes the oops. After applying a patch, I've been testing
owfs+w1 setup for nearly two days and it seems to work very reliable (no
hangs, no memleaks etc).
More detailed description and possible fix is given below:
Function w1_search can
_stop call from netlink
connector which causes the oops. After applying a patch, I've been testing
owfs+w1 setup for nearly two days and it seems to work very reliable (no
hangs, no memleaks etc).
More detailed description and possible fix is given below:
Function w1_search can be called from
_stop call from netlink
connector which causes the oops. After applying a patch, I've been testing
owfs+w1 setup for nearly two days and it seems to work very reliable (no
hangs, no memleaks etc).
More detailed description and possible fix is given below:
Function w1_search can be called from
_stop call from netlink
connector which causes the oops. After applying a patch, I've been testing
owfs+w1 setup for nearly two days and it seems to work very reliable (no
hangs, no memleaks etc).
More detailed description and possible fix is given below:
Function w1_search can be called from
kthread_should_stop call from netlink
connector which causes the oops. After applying a patch, I've been testing
owfs+w1 setup for nearly two days and it seems to work very reliable (no
hangs, no memleaks etc).
More detailed description and possible fix is given below:
Function w1_search can
kthread_should_stop call from netlink
connector which causes the oops. After applying a patch, I've been testing
owfs+w1 setup for nearly two days and it seems to work very reliable (no
hangs, no memleaks etc).
More detailed description and possible fix is given below:
Function w1_search can
kthread_should_stop call from netlink
connector which causes the oops. After applying a patch, I've been testing
owfs+w1 setup for nearly two days and it seems to work very reliable (no
hangs, no memleaks etc).
More detailed description and possible fix is given below:
Function w1_search can
_stop call from netlink
connector which causes the oops. After applying a patch, I've been testing
owfs+w1 setup for nearly two days and it seems to work very reliable (no
hangs, no memleaks etc).
More detailed description and possible fix is given below:
Function w1_search can be called from
kthread_should_stop call from netlink
connector which causes the oops. After applying a patch, I've been testing
owfs+w1 setup for nearly two days and it seems to work very reliable (no
hangs, no memleaks etc).
More detailed description and possible fix is given below:
Function w1_search can
On Sun, Mar 3, 2013 at 5:41 PM, GregKH wrote:
> On Mon, Mar 04, 2013 at 12:54:52AM +0400, Evgeniy Polyakov wrote:
>> Hi
>>
>> Marcin, thanks a lot for the fix, I have to sorry I'm not on this bug yet :(
>> Sven confirmed patch fixes it, Greg please pull it into your tree.
>
> Ok, will do once
On Sun, Mar 3, 2013 at 5:41 PM, GregKH g...@kroah.com wrote:
On Mon, Mar 04, 2013 at 12:54:52AM +0400, Evgeniy Polyakov wrote:
Hi
Marcin, thanks a lot for the fix, I have to sorry I'm not on this bug yet :(
Sven confirmed patch fixes it, Greg please pull it into your tree.
Ok, will do once
On Mon, Mar 04, 2013 at 12:54:52AM +0400, Evgeniy Polyakov wrote:
> Hi
>
> Marcin, thanks a lot for the fix, I have to sorry I'm not on this bug yet :(
> Sven confirmed patch fixes it, Greg please pull it into your tree.
Ok, will do once 3.9-rc1 is out.
thanks,
greg k-h
--
To unsubscribe from
: Patrick McHardy
> > Date: Mon Mar 28 08:39:36 2011 +
>
> Good job. I was too lazy to bisect for bad commit;)
>
> Reading the code I found problematic kthread_should_stop call from netlink
> connector which causes the oops. After applying a patch, I've been testing
Marcin Jurkowski schrieb am Samstag, den 02. März um 14:50 Uhr:
> This patch adds a check if w1_search is serving netlink command, skipping
> kthread_should_stop invocation if so.
Works fine on my Raspberry Pi!
Any chance to get this fix into mainline?
Regards
Sven
--
# Turn on/off
Marcin Jurkowski schrieb am Samstag, den 02. März um 14:50 Uhr:
This patch adds a check if w1_search is serving netlink command, skipping
kthread_should_stop invocation if so.
Works fine on my Raspberry Pi!
Any chance to get this fix into mainline?
Regards
Sven
--
# Turn on/off security.
...@trash.net
Date: Mon Mar 28 08:39:36 2011 +
Good job. I was too lazy to bisect for bad commit;)
Reading the code I found problematic kthread_should_stop call from netlink
connector which causes the oops. After applying a patch, I've been testing
owfs+w1 setup for nearly two days
On Mon, Mar 04, 2013 at 12:54:52AM +0400, Evgeniy Polyakov wrote:
Hi
Marcin, thanks a lot for the fix, I have to sorry I'm not on this bug yet :(
Sven confirmed patch fixes it, Greg please pull it into your tree.
Ok, will do once 3.9-rc1 is out.
thanks,
greg k-h
--
To unsubscribe from this
9:36 2011 +
Good job. I was too lazy to bisect for bad commit;)
Reading the code I found problematic kthread_should_stop call from netlink
connector which causes the oops. After applying a patch, I've been testing
owfs+w1 setup for nearly two days and it seems to work very reliable (no
han
2011 +
Good job. I was too lazy to bisect for bad commit;)
Reading the code I found problematic kthread_should_stop call from netlink
connector which causes the oops. After applying a patch, I've been testing
owfs+w1 setup for nearly two days and it seems to work very reliable (no
hangs
From: Greg KH
3.4-stable review patch. If anyone has any objections, please let me know.
--
From: Olaf Hering
commit bcc2c9c3fff859e0eb019fe6fec26f9b8eba795c upstream.
The SuSE security team suggested to use recvfrom instead of recv to be
certain that the connector message
From: Greg KH gre...@linuxfoundation.org
3.4-stable review patch. If anyone has any objections, please let me know.
--
From: Olaf Hering o...@aepfle.de
commit bcc2c9c3fff859e0eb019fe6fec26f9b8eba795c upstream.
The SuSE security team suggested to use recvfrom instead of recv
On Tue, Jul 26, 2005 at 04:42:14AM -0400, Harald Welte ([EMAIL PROTECTED])
wrote:
> On Mon, Jul 25, 2005 at 02:02:10AM -0400, James Morris wrote:
> > On Sun, 24 Jul 2005, David S. Miller wrote:
> > >From: Evgeniy Polyakov <[EMAIL PROTECTED]>
> > >Date: Sat, 23 Jul 2005 13:14:55 +0400
> > >>Andrew
On Mon, Jul 25, 2005 at 11:33:51PM +0400, Evgeniy Polyakov wrote:
> Netlink is transport protocol - no need to add complexity into it,
> it must be as simple as possible and thus extensible.
yes. but when you run into a serious addressing shortage (like the
internet does with ipv4), you
On Mon, Jul 25, 2005 at 02:02:10AM -0400, James Morris wrote:
> On Sun, 24 Jul 2005, David S. Miller wrote:
> >From: Evgeniy Polyakov <[EMAIL PROTECTED]>
> >Date: Sat, 23 Jul 2005 13:14:55 +0400
> >>Andrew has no objection against connector and it lives in -mm
> >A patch sitting in -mm has zero
On Tue, Jul 26, 2005 at 08:14:47AM +0200, Thomas Graf ([EMAIL PROTECTED]) wrote:
> * Evgeniy Polyakov <[EMAIL PROTECTED]> 2005-07-26 08:45
> > On Tue, Jul 26, 2005 at 01:46:04AM +0200, Patrick McHardy ([EMAIL
> > PROTECTED]) wrote:
> > > Usually netlink is easily extendable by using nested TLVs.
* Evgeniy Polyakov <[EMAIL PROTECTED]> 2005-07-26 08:45
> On Tue, Jul 26, 2005 at 01:46:04AM +0200, Patrick McHardy ([EMAIL PROTECTED])
> wrote:
> > Usually netlink is easily extendable by using nested TLVs. By hiding
> > this you basically remove this extensibility.
>
> Current netlink is not
* Evgeniy Polyakov [EMAIL PROTECTED] 2005-07-26 08:45
On Tue, Jul 26, 2005 at 01:46:04AM +0200, Patrick McHardy ([EMAIL PROTECTED])
wrote:
Usually netlink is easily extendable by using nested TLVs. By hiding
this you basically remove this extensibility.
Current netlink is not extensible
On Tue, Jul 26, 2005 at 08:14:47AM +0200, Thomas Graf ([EMAIL PROTECTED]) wrote:
* Evgeniy Polyakov [EMAIL PROTECTED] 2005-07-26 08:45
On Tue, Jul 26, 2005 at 01:46:04AM +0200, Patrick McHardy ([EMAIL
PROTECTED]) wrote:
Usually netlink is easily extendable by using nested TLVs. By hiding
On Mon, Jul 25, 2005 at 02:02:10AM -0400, James Morris wrote:
On Sun, 24 Jul 2005, David S. Miller wrote:
From: Evgeniy Polyakov [EMAIL PROTECTED]
Date: Sat, 23 Jul 2005 13:14:55 +0400
Andrew has no objection against connector and it lives in -mm
A patch sitting in -mm has zero significance.
On Tue, Jul 26, 2005 at 04:42:14AM -0400, Harald Welte ([EMAIL PROTECTED])
wrote:
On Mon, Jul 25, 2005 at 02:02:10AM -0400, James Morris wrote:
On Sun, 24 Jul 2005, David S. Miller wrote:
From: Evgeniy Polyakov [EMAIL PROTECTED]
Date: Sat, 23 Jul 2005 13:14:55 +0400
Andrew has no
On Mon, Jul 25, 2005 at 11:33:51PM +0400, Evgeniy Polyakov wrote:
Netlink is transport protocol - no need to add complexity into it,
it must be as simple as possible and thus extensible.
yes. but when you run into a serious addressing shortage (like the
internet does with ipv4), you develop
On Mon, Jul 25, 2005 at 09:56:56PM -0700, Stephen Hemminger ([EMAIL PROTECTED])
wrote:
> Evgeniy Polyakov wrote:
>
> >On Tue, Jul 26, 2005 at 01:46:04AM +0200, Patrick McHardy
> >([EMAIL PROTECTED]) wrote:
> >
> >
> >>Evgeniy Polyakov wrote:
> >>
> >>
> >>>On Mon, Jul 25, 2005 at 04:32:32PM
Evgeniy Polyakov wrote:
On Tue, Jul 26, 2005 at 01:46:04AM +0200, Patrick McHardy ([EMAIL PROTECTED])
wrote:
Evgeniy Polyakov wrote:
On Mon, Jul 25, 2005 at 04:32:32PM +0200, Patrick McHardy
([EMAIL PROTECTED]) wrote:
If I understand correctly it tries to workaround some
On Tue, Jul 26, 2005 at 01:46:04AM +0200, Patrick McHardy ([EMAIL PROTECTED])
wrote:
> Evgeniy Polyakov wrote:
> >On Mon, Jul 25, 2005 at 04:32:32PM +0200, Patrick McHardy
> >([EMAIL PROTECTED]) wrote:
> >
> >>If I understand correctly it tries to workaround some netlink
> >>limitations (limited
* Patrick McHardy <[EMAIL PROTECTED]> 2005-07-26 02:16
> Thomas Graf wrote:
> >* Patrick McHardy <[EMAIL PROTECTED]> 2005-07-26 01:46
> >
> >>You still have to take care of mixed 64/32 bit environments, u64 fields
> >>for example are differently alligned.
> >
> >My solution to this (in the same
Thomas Graf wrote:
* Patrick McHardy <[EMAIL PROTECTED]> 2005-07-26 01:46
You still have to take care of mixed 64/32 bit environments, u64 fields
for example are differently alligned.
My solution to this (in the same patchset) is that we never
derference u64s but instead copy them.
I don't
* Patrick McHardy <[EMAIL PROTECTED]> 2005-07-26 01:46
> Netlink users don't have to care about shared or cloned skbs. I don't
> think its a big issue to use alloc_skb and then the usual netlink
> macros. Thomas added a number of macros that simplfiy use a lot.
Once I've finished the generic
Evgeniy Polyakov wrote:
On Mon, Jul 25, 2005 at 04:32:32PM +0200, Patrick McHardy ([EMAIL PROTECTED])
wrote:
If I understand correctly it tries to workaround some netlink
limitations (limited number of netlink families and multicast groups)
by sending everything to userspace and
On Mon, Jul 25, 2005 at 04:43:43PM +0200, Eric Leblond ([EMAIL PROTECTED])
wrote:
> Le lundi 25 juillet 2005 à 16:32 +0200, Patrick McHardy a écrit :
> > Evgeniy Polyakov wrote:
> > > On Mon, Jul 25, 2005 at 02:02:10AM -0400, James Morris ([EMAIL
> > > PROTECTED]) wrote:
> > If I understand
On Mon, Jul 25, 2005 at 04:32:32PM +0200, Patrick McHardy ([EMAIL PROTECTED])
wrote:
> Evgeniy Polyakov wrote:
> >On Mon, Jul 25, 2005 at 02:02:10AM -0400, James Morris
> >([EMAIL PROTECTED]) wrote:
> >
> >>On Sun, 24 Jul 2005, David S. Miller wrote:
> >>
> >>>From: Evgeniy Polyakov <[EMAIL
Le lundi 25 juillet 2005 à 16:32 +0200, Patrick McHardy a écrit :
> Evgeniy Polyakov wrote:
> > On Mon, Jul 25, 2005 at 02:02:10AM -0400, James Morris ([EMAIL PROTECTED])
> > wrote:
> If I understand correctly it tries to workaround some netlink
> limitations (limited number of netlink families
Evgeniy Polyakov wrote:
On Mon, Jul 25, 2005 at 02:02:10AM -0400, James Morris ([EMAIL PROTECTED])
wrote:
On Sun, 24 Jul 2005, David S. Miller wrote:
From: Evgeniy Polyakov <[EMAIL PROTECTED]>
Date: Sat, 23 Jul 2005 13:14:55 +0400
Andrew has no objection against connector and it lives in
On Mon, Jul 25, 2005 at 02:02:10AM -0400, James Morris ([EMAIL PROTECTED])
wrote:
> On Sun, 24 Jul 2005, David S. Miller wrote:
> >From: Evgeniy Polyakov <[EMAIL PROTECTED]>
> >Date: Sat, 23 Jul 2005 13:14:55 +0400
> >
> >>Andrew has no objection against connector and it lives in -mm
> >
> >A
On Sun, 24 Jul 2005, David S. Miller wrote:
From: Evgeniy Polyakov <[EMAIL PROTECTED]>
Date: Sat, 23 Jul 2005 13:14:55 +0400
Andrew has no objection against connector and it lives in -mm
A patch sitting in -mm has zero significance.
The significance I think is that Andrew is trying to
On Sun, 24 Jul 2005, David S. Miller wrote:
From: Evgeniy Polyakov [EMAIL PROTECTED]
Date: Sat, 23 Jul 2005 13:14:55 +0400
Andrew has no objection against connector and it lives in -mm
A patch sitting in -mm has zero significance.
The significance I think is that Andrew is trying to gently
On Mon, Jul 25, 2005 at 02:02:10AM -0400, James Morris ([EMAIL PROTECTED])
wrote:
On Sun, 24 Jul 2005, David S. Miller wrote:
From: Evgeniy Polyakov [EMAIL PROTECTED]
Date: Sat, 23 Jul 2005 13:14:55 +0400
Andrew has no objection against connector and it lives in -mm
A patch sitting in
Evgeniy Polyakov wrote:
On Mon, Jul 25, 2005 at 02:02:10AM -0400, James Morris ([EMAIL PROTECTED])
wrote:
On Sun, 24 Jul 2005, David S. Miller wrote:
From: Evgeniy Polyakov [EMAIL PROTECTED]
Date: Sat, 23 Jul 2005 13:14:55 +0400
Andrew has no objection against connector and it lives in
Le lundi 25 juillet 2005 à 16:32 +0200, Patrick McHardy a écrit :
Evgeniy Polyakov wrote:
On Mon, Jul 25, 2005 at 02:02:10AM -0400, James Morris ([EMAIL PROTECTED])
wrote:
If I understand correctly it tries to workaround some netlink
limitations (limited number of netlink families and
On Mon, Jul 25, 2005 at 04:32:32PM +0200, Patrick McHardy ([EMAIL PROTECTED])
wrote:
Evgeniy Polyakov wrote:
On Mon, Jul 25, 2005 at 02:02:10AM -0400, James Morris
([EMAIL PROTECTED]) wrote:
On Sun, 24 Jul 2005, David S. Miller wrote:
From: Evgeniy Polyakov [EMAIL PROTECTED]
Date: Sat,
On Mon, Jul 25, 2005 at 04:43:43PM +0200, Eric Leblond ([EMAIL PROTECTED])
wrote:
Le lundi 25 juillet 2005 à 16:32 +0200, Patrick McHardy a écrit :
Evgeniy Polyakov wrote:
On Mon, Jul 25, 2005 at 02:02:10AM -0400, James Morris ([EMAIL
PROTECTED]) wrote:
If I understand correctly it
Evgeniy Polyakov wrote:
On Mon, Jul 25, 2005 at 04:32:32PM +0200, Patrick McHardy ([EMAIL PROTECTED])
wrote:
If I understand correctly it tries to workaround some netlink
limitations (limited number of netlink families and multicast groups)
by sending everything to userspace and
* Patrick McHardy [EMAIL PROTECTED] 2005-07-26 01:46
Netlink users don't have to care about shared or cloned skbs. I don't
think its a big issue to use alloc_skb and then the usual netlink
macros. Thomas added a number of macros that simplfiy use a lot.
Once I've finished the generic netlink
Thomas Graf wrote:
* Patrick McHardy [EMAIL PROTECTED] 2005-07-26 01:46
You still have to take care of mixed 64/32 bit environments, u64 fields
for example are differently alligned.
My solution to this (in the same patchset) is that we never
derference u64s but instead copy them.
I don't
* Patrick McHardy [EMAIL PROTECTED] 2005-07-26 02:16
Thomas Graf wrote:
* Patrick McHardy [EMAIL PROTECTED] 2005-07-26 01:46
You still have to take care of mixed 64/32 bit environments, u64 fields
for example are differently alligned.
My solution to this (in the same patchset) is that we
On Tue, Jul 26, 2005 at 01:46:04AM +0200, Patrick McHardy ([EMAIL PROTECTED])
wrote:
Evgeniy Polyakov wrote:
On Mon, Jul 25, 2005 at 04:32:32PM +0200, Patrick McHardy
([EMAIL PROTECTED]) wrote:
If I understand correctly it tries to workaround some netlink
limitations (limited number of
Evgeniy Polyakov wrote:
On Tue, Jul 26, 2005 at 01:46:04AM +0200, Patrick McHardy ([EMAIL PROTECTED])
wrote:
Evgeniy Polyakov wrote:
On Mon, Jul 25, 2005 at 04:32:32PM +0200, Patrick McHardy
([EMAIL PROTECTED]) wrote:
If I understand correctly it tries to workaround some
On Mon, Jul 25, 2005 at 09:56:56PM -0700, Stephen Hemminger ([EMAIL PROTECTED])
wrote:
Evgeniy Polyakov wrote:
On Tue, Jul 26, 2005 at 01:46:04AM +0200, Patrick McHardy
([EMAIL PROTECTED]) wrote:
Evgeniy Polyakov wrote:
On Mon, Jul 25, 2005 at 04:32:32PM +0200, Patrick McHardy
On Tue, 5 Apr 2005, Evgeniy Polyakov wrote:
> On Tue, 2005-04-05 at 01:05 -0400, James Morris wrote:
> > Evgeniy,
> >
> > Please send networking patches to [EMAIL PROTECTED]
>
> It was sent there two times.
I googled around quite a lot to track the origin of the patches down but
didn't do the
On Tue, 2005-04-05 at 07:00 -0400, jamal wrote:
> and, oh yeah - wheres the documentation Evgeniy? ;->
In the tree :)
Documentation/connector/connector.txt - some notes, API.
Documentation/connector/cn_test.c - kernel example.
Uses cn_netlink_send(), notification feature.
I will send today a
and, oh yeah - wheres the documentation Evgeniy? ;->
cheers,
jamal
On Tue, 2005-04-05 at 06:44, jamal wrote:
> To be fair to Evgeniy I am not against the Konnector idea. I think that
> it is a useful feature to have an easy to use messaging between
> kernel-kernel and kernel-userspace. The fact
To be fair to Evgeniy I am not against the Konnector idea. I think that
it is a useful feature to have an easy to use messaging between
kernel-kernel and kernel-userspace. The fact that he leveraged netlink
instead of inventing things is a bonus. Having said that i have not
seriously scrutinized
curs by adding only one line (two
with the #include) in the kernel/fork.c file. Thus, the netlink
connector is a very simple and fast mechanism when you need to send a
small amount of information from kernel space to user space.
Regards,
Guillaume
-
To unsubscribe from this list: send the line "
On Tue, 2005-04-05 at 01:10 -0400, Herbert Xu wrote:
>On Tue, Apr 05, 2005 at 11:03:16AM +0400, Evgeniy Polyakov wrote:
>>
>> I received comments and feature requests from Herbert Xu and Jamal Hadi
>> Salim,
>> almost all were successfully resolved.
>
>Please do not construe my involvement in
On Tue, Apr 05, 2005 at 11:03:16AM +0400, Evgeniy Polyakov wrote:
>
> I received comments and feature requests from Herbert Xu and Jamal Hadi
> Salim,
> almost all were successfully resolved.
Please do not construe my involvement in these threads as endorsement
for this system.
In fact to this
On Tue, 2005-04-05 at 01:10 -0400, James Morris wrote:
> On Tue, 5 Apr 2005, James Morris wrote:
>
> > A few questions:
>
> Also, please allow cn_add_callback() allow it to be passed a NULL
> callback function, so the caller doesn't pass in a dummy function and your
> code doesn't waste time
On Tue, 2005-04-05 at 01:05 -0400, James Morris wrote:
> Evgeniy,
>
> Please send networking patches to [EMAIL PROTECTED]
It was sent there two times.
> Your connector code (under drivers/connector) is now in the -mm tree and
> as far as I can tell, has not received any review from the
On Tue, 5 Apr 2005, Evgeniy Polyakov wrote:
On Tue, 2005-04-05 at 01:05 -0400, James Morris wrote:
Evgeniy,
Please send networking patches to [EMAIL PROTECTED]
It was sent there two times.
I googled around quite a lot to track the origin of the patches down but
didn't do the obvious
On Tue, 2005-04-05 at 01:05 -0400, James Morris wrote:
Evgeniy,
Please send networking patches to [EMAIL PROTECTED]
It was sent there two times.
Your connector code (under drivers/connector) is now in the -mm tree and
as far as I can tell, has not received any review from the network
On Tue, 2005-04-05 at 01:10 -0400, James Morris wrote:
On Tue, 5 Apr 2005, James Morris wrote:
A few questions:
Also, please allow cn_add_callback() allow it to be passed a NULL
callback function, so the caller doesn't pass in a dummy function and your
code doesn't waste time dealing
On Tue, Apr 05, 2005 at 11:03:16AM +0400, Evgeniy Polyakov wrote:
I received comments and feature requests from Herbert Xu and Jamal Hadi
Salim,
almost all were successfully resolved.
Please do not construe my involvement in these threads as endorsement
for this system.
In fact to this day
On Tue, 2005-04-05 at 01:10 -0400, Herbert Xu wrote:
On Tue, Apr 05, 2005 at 11:03:16AM +0400, Evgeniy Polyakov wrote:
I received comments and feature requests from Herbert Xu and Jamal Hadi
Salim,
almost all were successfully resolved.
Please do not construe my involvement in these threads
) in the kernel/fork.c file. Thus, the netlink
connector is a very simple and fast mechanism when you need to send a
small amount of information from kernel space to user space.
Regards,
Guillaume
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message
To be fair to Evgeniy I am not against the Konnector idea. I think that
it is a useful feature to have an easy to use messaging between
kernel-kernel and kernel-userspace. The fact that he leveraged netlink
instead of inventing things is a bonus. Having said that i have not
seriously scrutinized
and, oh yeah - wheres the documentation Evgeniy? ;-
cheers,
jamal
On Tue, 2005-04-05 at 06:44, jamal wrote:
To be fair to Evgeniy I am not against the Konnector idea. I think that
it is a useful feature to have an easy to use messaging between
kernel-kernel and kernel-userspace. The fact
On Tue, 2005-04-05 at 07:00 -0400, jamal wrote:
and, oh yeah - wheres the documentation Evgeniy? ;-
In the tree :)
Documentation/connector/connector.txt - some notes, API.
Documentation/connector/cn_test.c - kernel example.
Uses cn_netlink_send(), notification feature.
I will send today a pathc
On Tue, 5 Apr 2005, James Morris wrote:
> A few questions:
Also, please allow cn_add_callback() allow it to be passed a NULL
callback function, so the caller doesn't pass in a dummy function and your
code doesn't waste time dealing with something which isn't real.
- James
--
James Morris
Evgeniy,
Please send networking patches to [EMAIL PROTECTED]
Your connector code (under drivers/connector) is now in the -mm tree and
as far as I can tell, has not received any review from the network
developers.
Looking at it briefly, it seems quite unfinished.
I'm not entirely sure what
Evgeniy,
Please send networking patches to [EMAIL PROTECTED]
Your connector code (under drivers/connector) is now in the -mm tree and
as far as I can tell, has not received any review from the network
developers.
Looking at it briefly, it seems quite unfinished.
I'm not entirely sure what
On Tue, 5 Apr 2005, James Morris wrote:
A few questions:
Also, please allow cn_add_callback() allow it to be passed a NULL
callback function, so the caller doesn't pass in a dummy function and your
code doesn't waste time dealing with something which isn't real.
- James
--
James Morris
88 matches
Mail list logo
