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 addin
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
--- a/drivers/w
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 t
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 fro
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
_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 fr
_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 fr
_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 fr
_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 fr
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 3.9-
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 t
uthor: 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 te
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.
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
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 i
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 develop
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 sig
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. B
* 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 ex
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 net
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 pat
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 netli
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 demultiplexing
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 corre
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 PROTE
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 an
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 patc
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 gentl
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 path
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 t
rk occurs 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 thes
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 d
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 de
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, 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
<[E
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 it'
44 matches
Mail list logo
