[haiku-bugs] Re: [Haiku] #7040: [net_server] interface stops working after turning it off and on
- From: "diver" <trac@xxxxxxxxxxxx>
- Date: Tue, 02 Apr 2013 08:02:43 -0000
#7040: [net_server] interface stops working after turning it off and on
----------------------------------+----------------------------
Reporter: diver | Owner: axeld
Type: bug | Status: new
Priority: normal | Milestone: R1
Component: Servers/net_server | Version: R1/Development
Resolution: | Keywords:
Blocked By: | Blocking:
Has a Patch: 1 | Platform: All
----------------------------------+----------------------------
Comment (by diver):
mmlr_thinkpad: the patch is incomplete
it should also put the device interface in the error case a few lines
above
the device_interface reference leak is real in any case
and the above patch, augmented by an additional put in the error case,
should fix that
alternatively the user_memcpy could be moved above the
user_request_get_device_interface() call, so there wouldn't be a need to
do another put
mmlr_thinkpad: as I said, it is incomplete in the sense that it doesn't
put the reference in the error case
or alternatively, the copy could be moved above getting the
device_interface so that this is not needed
jshade: mmlr_thinkpad: in case of error "interface" is null and not need
to put
mmlr_thinkpad: no it isn't
only in case the device_interface cannot be found
if copying the request from userland fails, then interface is leaked
hence the suggestion of moving copying of the request above getting the
device_interface
http://cgit.haiku-os.org/haiku/tree/src/add-
ons/kernel/network/stack/link.cpp#n470
that's what I'm talking about
jshade: but there is another similar error
in "symmetry" of interface->Acqure/ReleaseReference() use
but this happen in case of configuring both ipv4 ipv6 on interface
in this case if we delete configured intf we cannot add its back
DEVICE_CLOSED affect on data transfet after intf re-add
*transfer
after intf added the driver is reopened but it return error on "read" as
it "closed"
mmlr_thinkpad:
jshade: would you say not closing the driver on bringing an interface down
would make sense in general?
it's how freebsd behaves, but we break that as we close the driver and
then bring it up again
I've worked around that with compat ioctls that behave similar to freebsd
up/down for wireless drivers and wpa_supplicant
but if this is a problem for wired drivers as well, then we should make a
version of the ethernet module that doesn't close the driver at all
and use that one for all freebsd drivers
jshade: on close we set device_closed bit but not unload driver and not
unset flag after open device again. see compat_open()/compat_close()
mmlr_thinkpad: jshade: yes, from the driver side not
however if we set the interface down then the ethernet add-on in the net
stack will close/free the driver
I'm wondering if it wouldn't simply be better to only close/free the
driver on interface deletion, not on brining it down
--
Ticket URL: <http://dev.haiku-os.org/ticket/7040#comment:7>
Haiku <http://dev.haiku-os.org>
Haiku - the operating system.
Other related posts:
