netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Ben Hutchings <bhutchings@solarflare.com>
To: Anirban Chakraborty <anirban.chakraborty@qlogic.com>
Cc: netdev <netdev@vger.kernel.org>, David Miller <davem@davemloft.net>
Subject: Re: [PATCHv3 net-next-2.6 2/3] qlcnic: Take FW dump via ethtool
Date: Thu, 12 May 2011 20:18:58 +0100	[thread overview]
Message-ID: <1305227938.5214.48.camel@bwh-desktop> (raw)
In-Reply-To: <F9877D83-226B-4C7A-AD01-E9AA441AD1CD@qlogic.com>

On Thu, 2011-05-12 at 11:53 -0700, Anirban Chakraborty wrote:
> On May 12, 2011, at 10:27 AM, Ben Hutchings wrote:
> 
> > On Wed, 2011-05-11 at 15:54 -0700, Anirban Chakraborty wrote:
> >> Driver checks if the previous dump has been cleared before taking the dump.
> >> It doesn't take the dump if it is not cleared.
> >> 
> >> Changes from v2:
> >> Added lock to protect dump data structures from being mangled while
> >> dumping or setting them via ethtool.
> > 
> > Unfortunately it still seems to be possible for the dump length to
> > change between the ethtool core calling qlcnic_get_dump_flag() and
> > qlcnic_get_dump_data().
> 
> dump length is serialized via the driver lock. dump length is a static
> entity for a given capture mask and it can only be changed when there
> is a different capture mask set in the driver (via calling set_dump()
> from ethtool core).

OK.

> Actual dump size is determined during the initial steps of FW dump
> which takes the driver lock to start with. So, I am not sure how the
> dump length could be changed between the calls to get_dump_flag and
> get_dump_data from within the ethtool core without a call to
> set_dump() in between.
[...]

What prevents this sequence:

1. Driver detects firmware dump is required, and creates the dump
(length L1).
2. User changes firmware dump flags through ethtool.
3. User starts to save firmware dump through ethtool:
   a. ethtool utility reads dump length (= L1) and allocates user buffer
   b. ethtool utility reads dump:
   c. ethtool core reads dump length (L1) and allocates kernel buffer
4. Meanwhile, driver detects firmware dump is required again, and
creates a new dump (length L2, since dump flags changed)
5. (Continuation of 3)
   d. ethtool core calls driver to read firmware dump
   e. Driver copies new dump (length L2) into buffer of length L1

Ben.

-- 
Ben Hutchings, Senior Software Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.


  reply	other threads:[~2011-05-12 19:19 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-05-11 22:54 [PATCHv3] ethtool: Added FW dump support Anirban Chakraborty
2011-05-11 22:54 ` [PATCHv3 net-next-2.6] ethtool: Added support for FW dump Anirban Chakraborty
2011-05-12 17:04   ` Ben Hutchings
2011-05-12 18:53     ` Anirban Chakraborty
2011-05-11 22:54 ` [PATCHv3 net-next-2.6 1/3] qlcnic: FW dump support Anirban Chakraborty
2011-05-11 22:54 ` [PATCHv3 net-next-2.6 2/3] qlcnic: Take FW dump via ethtool Anirban Chakraborty
2011-05-12 17:27   ` Ben Hutchings
2011-05-12 18:53     ` Anirban Chakraborty
2011-05-12 19:18       ` Ben Hutchings [this message]
2011-05-12 20:54         ` Anirban Chakraborty
2011-05-12 21:02           ` Ben Hutchings
2011-05-11 22:54 ` [PATCHv3 net-next-2.6 3/3] qlcnic: Bumped up version number to 5.0.18 Anirban Chakraborty
  -- strict thread matches above, loose matches on Subject: below --
2011-05-12 22:48 [PATCHv4] ethtool: Added FW dump support Anirban Chakraborty
2011-05-12 22:48 ` [PATCHv3 net-next-2.6 2/3] qlcnic: Take FW dump via ethtool Anirban Chakraborty
2011-05-13 18:44   ` David Miller

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1305227938.5214.48.camel@bwh-desktop \
    --to=bhutchings@solarflare.com \
    --cc=anirban.chakraborty@qlogic.com \
    --cc=davem@davemloft.net \
    --cc=netdev@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).