[PATCH net-2.6/stable] tg3: Restrict phy ioctl access

[PATCH net-2.6/stable] tg3: Restrict phy ioctl access

[Matt Carlson]

If management firmware is present and the device is down, the firmware
will assume control of the phy.  If a phy access were allowed from the
host, it will collide with firmware phy accesses, resulting in
unpredictable behavior.  This patch fixes the problem by disallowing phy
accesses during the problematic condition.

Upstream commit ID f746a3136a61ae535c5d0b49a9418fa21edc61b5

Signed-off-by: Matt Carlson <mcarlson@broadcom.com>
Reviewed-by: Michael Chan <mchan@broadcom.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
---
 drivers/net/tg3.c |    8 ++++++--
 1 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/net/tg3.c b/drivers/net/tg3.c
index 93b32d3..06c0e503 100644
--- a/drivers/net/tg3.c
+++ b/drivers/net/tg3.c
@@ -11158,7 +11158,9 @@ static int tg3_ioctl(struct net_device *dev, struct ifreq *ifr, int cmd)
 		if (tp->phy_flags & TG3_PHYFLG_PHY_SERDES)
 			break;			/* We have no PHY */
 
-		if (tp->phy_flags & TG3_PHYFLG_IS_LOW_POWER)
+		if ((tp->phy_flags & TG3_PHYFLG_IS_LOW_POWER) ||
+		    ((tp->tg3_flags & TG3_FLAG_ENABLE_ASF) &&
+		     !netif_running(dev)))
 			return -EAGAIN;
 
 		spin_lock_bh(&tp->lock);
@@ -11174,7 +11176,9 @@ static int tg3_ioctl(struct net_device *dev, struct ifreq *ifr, int cmd)
 		if (tp->phy_flags & TG3_PHYFLG_PHY_SERDES)
 			break;			/* We have no PHY */
 
-		if (tp->phy_flags & TG3_PHYFLG_IS_LOW_POWER)
+		if ((tp->phy_flags & TG3_PHYFLG_IS_LOW_POWER) ||
+		    ((tp->tg3_flags & TG3_FLAG_ENABLE_ASF) &&
+		     !netif_running(dev)))
 			return -EAGAIN;
 
 		spin_lock_bh(&tp->lock);
-- 
1.7.3.4

Re: [stable] [PATCH net-2.6/stable] tg3: Restrict phy ioctl access

[Greg KH]

On Tue, Feb 15, 2011 at 02:51:10PM -0800, Matt Carlson wrote:
> If management firmware is present and the device is down, the firmware
> will assume control of the phy.  If a phy access were allowed from the
> host, it will collide with firmware phy accesses, resulting in
> unpredictable behavior.  This patch fixes the problem by disallowing phy
> accesses during the problematic condition.
> 
> Upstream commit ID f746a3136a61ae535c5d0b49a9418fa21edc61b5

There is no such upstream git commit id in Linus's tree.  What am I
doing wrong here?

confused,

greg k-h

Re: [stable] [PATCH net-2.6/stable] tg3: Restrict phy ioctl access

[Matt Carlson]

On Wed, Feb 16, 2011 at 02:39:35PM -0800, Greg KH wrote:
> On Tue, Feb 15, 2011 at 02:51:10PM -0800, Matt Carlson wrote:
> > If management firmware is present and the device is down, the firmware
> > will assume control of the phy.  If a phy access were allowed from the
> > host, it will collide with firmware phy accesses, resulting in
> > unpredictable behavior.  This patch fixes the problem by disallowing phy
> > accesses during the problematic condition.
> > 
> > Upstream commit ID f746a3136a61ae535c5d0b49a9418fa21edc61b5
> 
> There is no such upstream git commit id in Linus's tree.  What am I
> doing wrong here?

The commit is in Dave Miller's net-next-2.6 tree.

Re: [stable] [PATCH net-2.6/stable] tg3: Restrict phy ioctl access

[David Miller]

From: "Matt Carlson" <mcarlson@broadcom.com>
Date: Wed, 16 Feb 2011 15:06:13 -0800

> On Wed, Feb 16, 2011 at 02:39:35PM -0800, Greg KH wrote:
>> On Tue, Feb 15, 2011 at 02:51:10PM -0800, Matt Carlson wrote:
>> > If management firmware is present and the device is down, the firmware
>> > will assume control of the phy.  If a phy access were allowed from the
>> > host, it will collide with firmware phy accesses, resulting in
>> > unpredictable behavior.  This patch fixes the problem by disallowing phy
>> > accesses during the problematic condition.
>> > 
>> > Upstream commit ID f746a3136a61ae535c5d0b49a9418fa21edc61b5
>> 
>> There is no such upstream git commit id in Linus's tree.  What am I
>> doing wrong here?
> 
> The commit is in Dave Miller's net-next-2.6 tree.
> 

If it wasn't appropriate for net-2.6, it absolutely it not appropriate
for -stable.

Re: [stable] [PATCH net-2.6/stable] tg3: Restrict phy ioctl access

[Matt Carlson]

On Wed, Feb 16, 2011 at 03:11:03PM -0800, David Miller wrote:
> From: "Matt Carlson" <mcarlson@broadcom.com>
> Date: Wed, 16 Feb 2011 15:06:13 -0800
> 
> > On Wed, Feb 16, 2011 at 02:39:35PM -0800, Greg KH wrote:
> >> On Tue, Feb 15, 2011 at 02:51:10PM -0800, Matt Carlson wrote:
> >> > If management firmware is present and the device is down, the firmware
> >> > will assume control of the phy.  If a phy access were allowed from the
> >> > host, it will collide with firmware phy accesses, resulting in
> >> > unpredictable behavior.  This patch fixes the problem by disallowing phy
> >> > accesses during the problematic condition.
> >> > 
> >> > Upstream commit ID f746a3136a61ae535c5d0b49a9418fa21edc61b5
> >> 
> >> There is no such upstream git commit id in Linus's tree.  What am I
> >> doing wrong here?
> > 
> > The commit is in Dave Miller's net-next-2.6 tree.
> > 
> 
> If it wasn't appropriate for net-2.6, it absolutely it not appropriate
> for -stable.

net-2.6 was the target tree for the patch.  The stable_kernel_rules.txt
seemed to suggest that I could just CC stable@kernel.org with the
commit ID, and Greg would pull it in as the process dictates.  If that
isn't correct, what is the preferred way to expedite the integration of
a patch?

Re: [stable] [PATCH net-2.6/stable] tg3: Restrict phy ioctl access

[Greg KH]

On Wed, Feb 16, 2011 at 03:52:48PM -0800, Matt Carlson wrote:
> On Wed, Feb 16, 2011 at 03:11:03PM -0800, David Miller wrote:
> > From: "Matt Carlson" <mcarlson@broadcom.com>
> > Date: Wed, 16 Feb 2011 15:06:13 -0800
> > 
> > > On Wed, Feb 16, 2011 at 02:39:35PM -0800, Greg KH wrote:
> > >> On Tue, Feb 15, 2011 at 02:51:10PM -0800, Matt Carlson wrote:
> > >> > If management firmware is present and the device is down, the firmware
> > >> > will assume control of the phy.  If a phy access were allowed from the
> > >> > host, it will collide with firmware phy accesses, resulting in
> > >> > unpredictable behavior.  This patch fixes the problem by disallowing phy
> > >> > accesses during the problematic condition.
> > >> > 
> > >> > Upstream commit ID f746a3136a61ae535c5d0b49a9418fa21edc61b5
> > >> 
> > >> There is no such upstream git commit id in Linus's tree.  What am I
> > >> doing wrong here?
> > > 
> > > The commit is in Dave Miller's net-next-2.6 tree.
> > > 
> > 
> > If it wasn't appropriate for net-2.6, it absolutely it not appropriate
> > for -stable.
> 
> net-2.6 was the target tree for the patch.  The stable_kernel_rules.txt
> seemed to suggest that I could just CC stable@kernel.org with the
> commit ID, and Greg would pull it in as the process dictates.  If that
> isn't correct, what is the preferred way to expedite the integration of
> a patch?

Keep reading that file, it says to put the Cc: in the signed-off-by area
of the original patch.

Also, that file says the patch has to be in Linus's tree, otherwise
sending me a git commit id of some other tree isn't going to help at
all.

thanks,

greg k-h

Re: [stable] [PATCH net-2.6/stable] tg3: Restrict phy ioctl access

[David Miller]

From: "Matt Carlson" <mcarlson@broadcom.com>
Date: Wed, 16 Feb 2011 15:52:48 -0800

> On Wed, Feb 16, 2011 at 03:11:03PM -0800, David Miller wrote:
>> From: "Matt Carlson" <mcarlson@broadcom.com>
>> Date: Wed, 16 Feb 2011 15:06:13 -0800
>> 
>> > On Wed, Feb 16, 2011 at 02:39:35PM -0800, Greg KH wrote:
>> >> On Tue, Feb 15, 2011 at 02:51:10PM -0800, Matt Carlson wrote:
>> >> > If management firmware is present and the device is down, the firmware
>> >> > will assume control of the phy.  If a phy access were allowed from the
>> >> > host, it will collide with firmware phy accesses, resulting in
>> >> > unpredictable behavior.  This patch fixes the problem by disallowing phy
>> >> > accesses during the problematic condition.
>> >> > 
>> >> > Upstream commit ID f746a3136a61ae535c5d0b49a9418fa21edc61b5
>> >> 
>> >> There is no such upstream git commit id in Linus's tree.  What am I
>> >> doing wrong here?
>> > 
>> > The commit is in Dave Miller's net-next-2.6 tree.
>> > 
>> 
>> If it wasn't appropriate for net-2.6, it absolutely it not appropriate
>> for -stable.
> 
> net-2.6 was the target tree for the patch.  The stable_kernel_rules.txt
> seemed to suggest that I could just CC stable@kernel.org with the
> commit ID, and Greg would pull it in as the process dictates.  If that
> isn't correct, what is the preferred way to expedite the integration of
> a patch?

You are posting a commit ID for the net-next-2.6 tree, that's what triggered
my response.

Unless it also went into the net-2.6 tree (in which case you should
give Greg the net-2.6 commit ID, which is also what the commit ID must
be in Linus's tree right now), the change is not appropriate for
-stable submission.

Re: [stable] [PATCH net-2.6/stable] tg3: Restrict phy ioctl access

[Matt Carlson]

On Wed, Feb 16, 2011 at 04:00:35PM -0800, Greg KH wrote:
> On Wed, Feb 16, 2011 at 03:52:48PM -0800, Matt Carlson wrote:
> > On Wed, Feb 16, 2011 at 03:11:03PM -0800, David Miller wrote:
> > > From: "Matt Carlson" <mcarlson@broadcom.com>
> > > Date: Wed, 16 Feb 2011 15:06:13 -0800
> > > 
> > > > On Wed, Feb 16, 2011 at 02:39:35PM -0800, Greg KH wrote:
> > > >> On Tue, Feb 15, 2011 at 02:51:10PM -0800, Matt Carlson wrote:
> > > >> > If management firmware is present and the device is down, the firmware
> > > >> > will assume control of the phy.  If a phy access were allowed from the
> > > >> > host, it will collide with firmware phy accesses, resulting in
> > > >> > unpredictable behavior.  This patch fixes the problem by disallowing phy
> > > >> > accesses during the problematic condition.
> > > >> > 
> > > >> > Upstream commit ID f746a3136a61ae535c5d0b49a9418fa21edc61b5
> > > >> 
> > > >> There is no such upstream git commit id in Linus's tree.  What am I
> > > >> doing wrong here?
> > > > 
> > > > The commit is in Dave Miller's net-next-2.6 tree.
> > > > 
> > > 
> > > If it wasn't appropriate for net-2.6, it absolutely it not appropriate
> > > for -stable.
> > 
> > net-2.6 was the target tree for the patch.  The stable_kernel_rules.txt
> > seemed to suggest that I could just CC stable@kernel.org with the
> > commit ID, and Greg would pull it in as the process dictates.  If that
> > isn't correct, what is the preferred way to expedite the integration of
> > a patch?
> 
> Keep reading that file, it says to put the Cc: in the signed-off-by area
> of the original patch.

Ah.  Yes.  I see that now.

> Also, that file says the patch has to be in Linus's tree, otherwise
> sending me a git commit id of some other tree isn't going to help at
> all.

I see.  Thanks for the tips.

Re: [stable] [PATCH net-2.6/stable] tg3: Restrict phy ioctl access

[Matt Carlson]

On Wed, Feb 16, 2011 at 04:10:25PM -0800, David Miller wrote:
> From: "Matt Carlson" <mcarlson@broadcom.com>
> Date: Wed, 16 Feb 2011 15:52:48 -0800
> 
> > On Wed, Feb 16, 2011 at 03:11:03PM -0800, David Miller wrote:
> >> From: "Matt Carlson" <mcarlson@broadcom.com>
> >> Date: Wed, 16 Feb 2011 15:06:13 -0800
> >> 
> >> > On Wed, Feb 16, 2011 at 02:39:35PM -0800, Greg KH wrote:
> >> >> On Tue, Feb 15, 2011 at 02:51:10PM -0800, Matt Carlson wrote:
> >> >> > If management firmware is present and the device is down, the firmware
> >> >> > will assume control of the phy.  If a phy access were allowed from the
> >> >> > host, it will collide with firmware phy accesses, resulting in
> >> >> > unpredictable behavior.  This patch fixes the problem by disallowing phy
> >> >> > accesses during the problematic condition.
> >> >> > 
> >> >> > Upstream commit ID f746a3136a61ae535c5d0b49a9418fa21edc61b5
> >> >> 
> >> >> There is no such upstream git commit id in Linus's tree.  What am I
> >> >> doing wrong here?
> >> > 
> >> > The commit is in Dave Miller's net-next-2.6 tree.
> >> > 
> >> 
> >> If it wasn't appropriate for net-2.6, it absolutely it not appropriate
> >> for -stable.
> > 
> > net-2.6 was the target tree for the patch.  The stable_kernel_rules.txt
> > seemed to suggest that I could just CC stable@kernel.org with the
> > commit ID, and Greg would pull it in as the process dictates.  If that
> > isn't correct, what is the preferred way to expedite the integration of
> > a patch?
> 
> You are posting a commit ID for the net-next-2.6 tree, that's what triggered
> my response.
> 
> Unless it also went into the net-2.6 tree (in which case you should
> give Greg the net-2.6 commit ID, which is also what the commit ID must
> be in Linus's tree right now), the change is not appropriate for
> -stable submission.

So the proper thing to do here is recall the patch, submit a new patch
to net-2.6 with a CC: stabel@kernel.org in the signed-off-by section.

Would I do the exact same thing if I were posting to net-next-2.6?
(i.e. the CC line tells you I want this patch to go to net-next-2.6,
net-2.6, then Linus's tree, then stable?)  Or would you rather I posted
a completely different patchset against net-2.6?

Re: [stable] [PATCH net-2.6/stable] tg3: Restrict phy ioctl access

[David Miller]

From: "Matt Carlson" <mcarlson@broadcom.com>
Date: Wed, 16 Feb 2011 16:39:47 -0800

> So the proper thing to do here is recall the patch, submit a new patch
> to net-2.6 with a CC: stabel@kernel.org in the signed-off-by section.

No.

I have not applied your patch yet, but when I do and I also get my
tree pulled next time into Linus's tree, you can ask stable to apply
it.

Because only at that point will it exist as a commit in Linus's tree.

Before that happens you cannot ask Greg to apply it to his tree.

Re: [PATCH net-2.6/stable] tg3: Restrict phy ioctl access

[David Miller]

From: "Matt Carlson" <mcarlson@broadcom.com>
Date: Tue, 15 Feb 2011 14:51:10 -0800

> If management firmware is present and the device is down, the firmware
> will assume control of the phy.  If a phy access were allowed from the
> host, it will collide with firmware phy accesses, resulting in
> unpredictable behavior.  This patch fixes the problem by disallowing phy
> accesses during the problematic condition.
> 
> Signed-off-by: Matt Carlson <mcarlson@broadcom.com>
> Reviewed-by: Michael Chan <mchan@broadcom.com>
> Signed-off-by: David S. Miller <davem@davemloft.net>

Applied.