lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <200805172156.12686.rjw@sisk.pl>
Date:	Sat, 17 May 2008 21:56:12 +0200
From:	"Rafael J. Wysocki" <rjw@...k.pl>
To:	Tobias Diedrich <ranma+kernel@...edrich.de>
Cc:	linux-netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
	Ayaz Abdulla <aabdulla@...dia.com>
Subject: Re: hibernate event order question

On Saturday, 17 of May 2008, Tobias Diedrich wrote:
> Hello,

Hi,

> for some time now I had the problem that after a suspend to disk
> network connectivitiy was down and also wake-on-lan would not work.
> 
> First a bit of information, for the real question please see (*)
> below.
> 
> Now I just found the ethtool -d (register dump) option
> and decided I want to try to debug this long-standing bug:
> http://bugzilla.kernel.org/show_bug.cgi?id=8381
> 
> I already found out why network connectivity is down after resume:
> 
> The interfaces eth0 and eth1 are bridged into br0.
> The bridging code sets the interfaces into promiscous mode, but this
> is not properly restored after resume.
> This bug is easily fixable by calling nv_set_multicast(dev) either
> from within nv_open() or after nv_open() in nv_resume().
> 
> The second problem (does not wol after s2disk) is still unsolved
> though.  However I have found that wake-on-lan works fine if I
> "rmmod forcedeth" before suspending.  This is even a usable
> workaround for me, since the bridge device stays configured and I
> just have to reload forcedeth and readd the interfaces to the bridge
> after resume.
> 
> (*)
> Now for my question:
> AFAICS the ordering of events is as follows:
> 1) User reqests hibernate
> 2) Tasks are frozen
> 3) Device suspend callbacks get called
> 4) Device resume callbacks get called
> 5) Memory image is written to disk

6) Device suspend callbacks get called again to prepare for the system sleep
   state.

> Now, the problem I see with this is that while step 3) prepares the
> device for suspend (and wake-on-lan), step 4) may undo some of this
> preparation.
> 
> In my case, I think the fix for the first bug (promiscous mode does
> not get restored on resume) breaks wake-on-lan (since the new value
> of NvRegPacketFilterFlags may be incompatible with wake-on-lan).
> 
> Shouldn't there be a 'prepare for poweroff'-callback, which gets called
> before the system is powered off for real?

Yes, it should and it's called in recent kernels.

> --- linux-2.6.26-rc2/drivers/net/forcedeth.c	2008-05-17 14:22:06.000000000 +0200
> +++ linux-2.6.26-rc2/drivers/net/forcedeth.c	2008-05-17 19:48:56.000000000 +0200
> @@ -5823,6 +5823,7 @@
>  	writel(txreg, base + NvRegTransmitPoll);
>  
>  	rc = nv_open(dev);
> +	nv_set_multicast(dev);
>  out:
>  	return rc;
>  }

Thanks for the patch, it looks sane to me.

Rafael
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ