* GRE devices and MULTICAST flag.
From: Ben Greear @ 2011-09-23 19:56 UTC (permalink / raw)
To: netdev
I was under the impression that GRE tunnels could support MULTICAST
traffic, but the MULTICAST flag is not set. This is making the xorp
router crap out because it checks the MULTICAST flag and will
not start multicast on the interface if it's not set....
Is it supposed to be set?
7: gre0: <NOARP,UP,LOWER_UP> mtu 1476 qdisc noqueue state UNKNOWN
link/gre 0.0.0.0 brd 0.0.0.0
8: netb: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1476 qdisc noqueue state UNKNOWN
link/gre 192.168.100.223 peer 192.168.100.138
inet 10.0.1.1/32 scope global netb
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* tg3: BMC stops responding in 3.0
From: Arkadiusz Miśkiewicz @ 2011-09-23 19:45 UTC (permalink / raw)
To: Matt Carlson, Michael Chan; +Cc: netdev
Hi,
I was using 2.6.38.8 and recently tried to switch to 3.0.4 on Tyan S2891
platform.
This platform uses tg3:
tg3 0000:0a:09.1: eth1: Tigon3 [partno(BCM95704) rev 2003] (PCIX:133MHz:64-
bit) MAC address 00:e0:81:33:5e:af
tg3 0000:0a:09.1: eth1: attached PHY is 5704 (10/100/1000Base-T Ethernet)
(WireSpeed[1], EEE[0])
tg3 0000:0a:09.1: eth1: RXcsums[1] LinkChgREG[0] MIirq[0] ASF[0] TSOcap[1]
tg3 0000:0a:09.1: eth1: dma_rwctrl[769f4000] dma_mask[64-bit]
With 2.6.38.8 everything was working fine. With 3.0.4 there is a problem. As
soon as tg3 module is loaded or eth0 configured (can't tell which one since
the machine is 400km away from me and I have no way to play with it other than
ipmi or ssh) BMC stops responding (so all ipmitool commands over LAN stop
working). Normal tg3 activity is not affected - I can ssh-in without a problem
etc but ipmi over lan doesn't work.
From ssh console "ipmitool lan print" works, shows data but for example after
"ipmitool mc reset cold" it doesn't recover - ipmitool returns "Invalid
channel: 255". I have to reboot to 2.6.38.8 and then issue "ipmitool mc reset
cold" to recover.
Any idea which tg3 change could break this? Can't bisect this due remote
access only.
I was hoping that maybe 9e975cc291d80d5e4562d6bed15ec171e896d69b
"tg3: Fix io failures after chip reset" will fix things for me but no - this
doesn't help.
--
Arkadiusz Miśkiewicz PLD/Linux Team
arekm / maven.pl http://ftp.pld-linux.org/
^ permalink raw reply
* Re: [PATCH] net: change capability used by socket options IP{,V6}_TRANSPARENT
From: Maciej Żenczykowski @ 2011-09-23 19:33 UTC (permalink / raw)
To: Casey Schaufler; +Cc: netdev, linux-security-module, James Morris
In-Reply-To: <4E7CB5A9.2020303@schaufler-ca.com>
> Under what circumstances would a process that requires the
> new capability not require CAP_NET_ADMIN? Is there a real
> case where a process would be expected to require only this
> new capability? Adding new capability values is somewhat
> perilous and the granularity you are proposing, that of
> controlling a single bit, would explode the list of
> capabilities into the hundreds if it were applied throughout
> the kernel.
CAP_NET_ADMIN is a huge hammer, it allows one to totally
reconfigure the networking subsystem.
In a containerized multi-user/job environment, you do not want
something like an instance of a load-balanced web server, proxy
or dns server being able to do that - policy/configuration decisions
should be left up to the administrator and/or machine management
daemon(s). Each of these can make use of transparent sockets
(in various ways, mostly in coordination with large scale load balancing).
You also do not want one user running in one container being able
to sniff (CAP_NET_RAW) traffic from another user (hence CAP_NET_RAW
isn't an acceptable substitute).
One could conceivably use network namespaces for seperation, but
in this particular case they are _way_ too overkill (and also add too
much overhead).
This might be *just* a single bit in the socket, but this bit effectively
controls whether you can do certain types of privileged operations
on the socket in question - and it gets tested in various places throughout
the networking stack.
Hopefully, this answers your question.
- Maciej
^ permalink raw reply
* RE: [net-next 1/8] pci: Add flag indicating device has been assigned by KVM
From: Rose, Gregory V @ 2011-09-23 19:20 UTC (permalink / raw)
To: Konrad Rzeszutek Wilk
Cc: Kirsher, Jeffrey T, Ian Campbell, davem@davemloft.net,
Jesse Barnes, netdev@vger.kernel.org, gospo@redhat.com,
linux-pci@vger.kernel.org
In-Reply-To: <20110923190537.GA18850@phenom.oracle.com>
> -----Original Message-----
> From: Konrad Rzeszutek Wilk [mailto:konrad.wilk@oracle.com]
> Sent: Friday, September 23, 2011 12:06 PM
> To: Rose, Gregory V
> Cc: Kirsher, Jeffrey T; Ian Campbell; davem@davemloft.net; Jesse Barnes;
> netdev@vger.kernel.org; gospo@redhat.com; linux-pci@vger.kernel.org
> Subject: Re: [net-next 1/8] pci: Add flag indicating device has been
> assigned by KVM
>
> > > > Version 2 of this patch with the modified comment was just posted to
> > > netdev. Ian Campbell had mentioned that the Xen pciback driver should
> be
> > > modified to use this flag but I don't believe any patches for it have
> been
> > > created yet.
> > >
> > > http://marc.info/?i=20110729165446.GA6731@dumpdata.com
> > >
> >
> > I'm not sure who generated the patches to xen-pciback. It wasn't me and
> I couldn't tell from the links you provided who did generate that patch.
> I don't see it now though.
>
> I provided it.
>
> And I asked for a git tree so I could double check that it actually
> worked as I don't have the full set of your patches.
>
> Can you provide me a link to your public git tree or just repost it once
> more?
Ah, I get it now.
Jeff Kirsher is the maintainer of our git trees. Hopefully he'll come around and provide that info for you soon.
- Greg
^ permalink raw reply
* Re: [PATCH] tcp: ECN blackhole should not force quickack mode
From: Ilpo Järvinen @ 2011-09-23 19:17 UTC (permalink / raw)
To: Eric Dumazet
Cc: David Miller, netdev, Jerry Chu, Jamal Hadi Salim, Jim Gettys,
Dave Taht
In-Reply-To: <1316757739.2560.12.camel@edumazet-laptop>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 616 bytes --]
On Fri, 23 Sep 2011, Eric Dumazet wrote:
> While playing with a new ADSL box at home, I discovered that ECN
> blackhole can trigger suboptimal quickack mode on linux : We send one
> ACK for each incoming data frame, without any delay and eventual
> piggyback.
>
> This is because TCP_ECN_check_ce() considers that if no ECT is seen on a
> segment, this is because this segment was a retransmit.
>
> Refine this heuristic and apply it only if we seen ECT in a previous
> segment, to detect ECN blackhole at IP level.
This seems sensible thing to do.
Acked-by: Ilpo Järvinen <ilpo.jarvinen@helsinki.fi>
--
i.
^ permalink raw reply
* Re: [net-next 1/8] pci: Add flag indicating device has been assigned by KVM
From: Konrad Rzeszutek Wilk @ 2011-09-23 19:05 UTC (permalink / raw)
To: Rose, Gregory V
Cc: Kirsher, Jeffrey T, Ian Campbell, davem@davemloft.net,
Jesse Barnes, netdev@vger.kernel.org, gospo@redhat.com,
linux-pci@vger.kernel.org
In-Reply-To: <43F901BD926A4E43B106BF17856F0755019C518E23@orsmsx508.amr.corp.intel.com>
> > > Version 2 of this patch with the modified comment was just posted to
> > netdev. Ian Campbell had mentioned that the Xen pciback driver should be
> > modified to use this flag but I don't believe any patches for it have been
> > created yet.
> >
> > http://marc.info/?i=20110729165446.GA6731@dumpdata.com
> >
>
> I'm not sure who generated the patches to xen-pciback. It wasn't me and I couldn't tell from the links you provided who did generate that patch. I don't see it now though.
I provided it.
And I asked for a git tree so I could double check that it actually
worked as I don't have the full set of your patches.
Can you provide me a link to your public git tree or just repost it once more?
>
> - Greg
^ permalink raw reply
* Re: [PATCH net-next 0/2] qlcnic: Fixes
From: Anirban Chakraborty @ 2011-09-23 18:29 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Dept_NX_Linux_NIC_Driver
In-Reply-To: <20110923.142437.1502065492072634583.davem@davemloft.net>
On Sep 23, 2011, at 11:24 AM, David Miller wrote:
> From: Anirban Chakraborty <anirban.chakraborty@qlogic.com>
> Date: Fri, 23 Sep 2011 11:10:19 -0700
>
>> Do you want me to respin the patches based on current net-next and resubmit it?
>
> No need, I just haven't gotten to those patches yet.
>
> But since you bring it up I've applied them now, thanks.
Thanks a lot.
-Anirban
^ permalink raw reply
* [PATCH net/stable] can bcm: fix tx_setup off-by-one errors
From: Oliver Hartkopp @ 2011-09-23 18:23 UTC (permalink / raw)
To: David Miller; +Cc: Linux Netdev List, stable, Andre Naujoks
This patch fixes two off-by-one errors that canceled each other out.
Checking for the same condition two times in bcm_tx_timeout_tsklet() reduced
the count of frames to be sent by one. This did not show up the first time
tx_setup is invoked as an additional frame is sent due to TX_ANNONCE.
Invoking a second tx_setup on the same item led to a reduced (by 1) number of
sent frames.
Reported-by: Andre Naujoks <nautsch@gmail.com>
Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
---
diff --git a/net/can/bcm.c b/net/can/bcm.c
index d6c8ae5..c9cdb8d 100644
--- a/net/can/bcm.c
+++ b/net/can/bcm.c
@@ -365,9 +365,6 @@ static void bcm_tx_timeout_tsklet(unsigned long data)
bcm_send_to_user(op, &msg_head, NULL, 0);
}
- }
-
- if (op->kt_ival1.tv64 && (op->count > 0)) {
/* send (next) frame */
bcm_can_tx(op);
@@ -970,8 +967,9 @@ static int bcm_tx_setup(struct bcm_msg_head *msg_head, struct msghdr *msg,
/* spec: send can_frame when starting timer */
op->flags |= TX_ANNOUNCE;
- if (op->kt_ival1.tv64 && (op->count > 0)) {
- /* op->count-- is done in bcm_tx_timeout_handler */
+ /* only start timer when having more frames than sent below */
+ if (op->kt_ival1.tv64 && (op->count > 1)) {
+ /* op->count-- is done in bcm_tx_timeout_tsklet */
hrtimer_start(&op->timer, op->kt_ival1,
HRTIMER_MODE_REL);
} else
@@ -979,8 +977,11 @@ static int bcm_tx_setup(struct bcm_msg_head *msg_head, struct msghdr *msg,
HRTIMER_MODE_REL);
}
- if (op->flags & TX_ANNOUNCE)
+ if (op->flags & TX_ANNOUNCE) {
bcm_can_tx(op);
+ if (op->kt_ival1.tv64 && (op->count > 0))
+ op->count--;
+ }
return msg_head->nframes * CFSIZ + MHSIZ;
}
^ permalink raw reply related
* RE: [net-next 1/8] pci: Add flag indicating device has been assigned by KVM
From: Rose, Gregory V @ 2011-09-23 18:24 UTC (permalink / raw)
To: Konrad Rzeszutek Wilk
Cc: Kirsher, Jeffrey T, Ian Campbell, davem@davemloft.net,
Jesse Barnes, netdev@vger.kernel.org, gospo@redhat.com,
linux-pci@vger.kernel.org
In-Reply-To: <20110923180025.GA6251@phenom.oracle.com>
> -----Original Message-----
> From: Konrad Rzeszutek Wilk [mailto:konrad.wilk@oracle.com]
> Sent: Friday, September 23, 2011 11:00 AM
> To: Rose, Gregory V
> Cc: Kirsher, Jeffrey T; Ian Campbell; davem@davemloft.net; Jesse Barnes;
> netdev@vger.kernel.org; gospo@redhat.com; linux-pci@vger.kernel.org
> Subject: Re: [net-next 1/8] pci: Add flag indicating device has been
> assigned by KVM
>
> On Fri, Sep 23, 2011 at 10:04:59AM -0700, Rose, Gregory V wrote:
> > > -----Original Message-----
> > > From: Konrad Rzeszutek Wilk [mailto:konrad.wilk@oracle.com]
> > > Sent: Friday, September 23, 2011 9:43 AM
> > > To: Kirsher, Jeffrey T
> > > Cc: Rose, Gregory V; Ian Campbell; davem@davemloft.net; Jesse Barnes;
> > > netdev@vger.kernel.org; gospo@redhat.com; linux-pci@vger.kernel.org
> > > Subject: Re: [net-next 1/8] pci: Add flag indicating device has been
> > > assigned by KVM
> > >
> > > On Fri, Sep 23, 2011 at 08:45:09AM -0700, Jeff Kirsher wrote:
> > > > On Fri, 2011-09-23 at 08:11 -0700, Rose, Gregory V wrote:
> > > > > > -----Original Message-----
> > > > > > From: Ian Campbell [mailto:ijc@hellion.org.uk]
> > > > > > Sent: Friday, September 23, 2011 8:04 AM
> > > > > > To: Rose, Gregory V
> > > > > > Cc: Kirsher, Jeffrey T; davem@davemloft.net;
> konrad.wilk@oracle.com;
> > > Jesse
> > > > > > Barnes; netdev@vger.kernel.org; gospo@redhat.com; linux-
> > > > > > pci@vger.kernel.org
> > > > > > Subject: RE: [net-next 1/8] pci: Add flag indicating device has
> been
> > > > > > assigned by KVM
> > > > > >
> > > > > > On Fri, 2011-09-23 at 07:41 -0700, Rose, Gregory V wrote:
> > > > > > > > -----Original Message-----
> > > > > > > > From: Ian Campbell [mailto:ijc@hellion.org.uk]
> > > > > > > > Sent: Friday, September 23, 2011 12:28 AM
> > > > > > > > To: Kirsher, Jeffrey T
> > > > > > > > Cc: davem@davemloft.net; konrad.wilk@oracle.com; Jesse
> Barnes;
> > > Rose,
> > > > > > > > Gregory V; netdev@vger.kernel.org; gospo@redhat.com; linux-
> > > > > > > > pci@vger.kernel.org
> > > > > > > > Subject: Re: [net-next 1/8] pci: Add flag indicating device
> has
> > > been
> > > > > > > > assigned by KVM
> > > > > > > >
> > > > > > > > I suppose by that measure the comment could be less KVM
> > > specific:
> > > > > > > > > + /* Provide indication device is assigned by KVM */
> > > > > > > > > + PCI_DEV_FLAGS_ASSIGNED = (__force pci_dev_flags_t)
> 4,
> > > > > > >
> > > > > > > We can resubmit with a more generic comment, maybe this:
> > > > > > >
> > > > > > > /* Provide indication device is assigned by a Virtual Machine
> > > Manager */
> > > > > >
> > > > > > Sounds good to me.
> > > > >
> > > > > Dave, Jeff,
> > > > >
> > > > > Should I resubmit the patch or would it be more convenient to post
> a
> > > follow on patch that fixes up the comment? Either way is fine by me.
> > > > >
> > > > > - Greg
> > > > >
> > > >
> > > > let's fix up the patch in my tree and add Jesse Barnes's ACK at the
> same
> > > > time.
> > >
> > > Were are the patches now? I am kind of curious to see the changes to
> the
> > > xen pciback.
> > >
> > >
> >
> > Version 2 of this patch with the modified comment was just posted to
> netdev. Ian Campbell had mentioned that the Xen pciback driver should be
> modified to use this flag but I don't believe any patches for it have been
> created yet.
>
> http://marc.info/?i=20110729165446.GA6731@dumpdata.com
>
I'm not sure who generated the patches to xen-pciback. It wasn't me and I couldn't tell from the links you provided who did generate that patch. I don't see it now though.
- Greg
^ permalink raw reply
* Re: [PATCH net-next 0/2] qlcnic: Fixes
From: David Miller @ 2011-09-23 18:24 UTC (permalink / raw)
To: anirban.chakraborty; +Cc: netdev, Dept_NX_Linux_NIC_Driver
In-Reply-To: <09109E3F-C661-4429-A7CF-6D9C01C3171B@qlogic.com>
From: Anirban Chakraborty <anirban.chakraborty@qlogic.com>
Date: Fri, 23 Sep 2011 11:10:19 -0700
> Do you want me to respin the patches based on current net-next and resubmit it?
No need, I just haven't gotten to those patches yet.
But since you bring it up I've applied them now, thanks.
^ permalink raw reply
* Re: [PATCH net-next 0/2] qlcnic: Fixes
From: Anirban Chakraborty @ 2011-09-23 18:10 UTC (permalink / raw)
To: Anirban Chakraborty; +Cc: David Miller, netdev, Dept_NX_Linux_NIC_Driver
In-Reply-To: <1315937179-22383-3-git-send-email-anirban.chakraborty@qlogic.com>
Dave,
Do you want me to respin the patches based on current net-next and resubmit it?
thanks,
Anirban
On Sep 13, 2011, at 11:06 AM, Anirban Chakraborty wrote:
> Please apply the series to net-next. Thanks.
>
> -Anirban
>
^ permalink raw reply
* Re: [net-next 1/8] pci: Add flag indicating device has been assigned by KVM
From: Konrad Rzeszutek Wilk @ 2011-09-23 18:00 UTC (permalink / raw)
To: Rose, Gregory V
Cc: Kirsher, Jeffrey T, Ian Campbell, davem@davemloft.net,
Jesse Barnes, netdev@vger.kernel.org, gospo@redhat.com,
linux-pci@vger.kernel.org
In-Reply-To: <43F901BD926A4E43B106BF17856F0755019C518D57@orsmsx508.amr.corp.intel.com>
On Fri, Sep 23, 2011 at 10:04:59AM -0700, Rose, Gregory V wrote:
> > -----Original Message-----
> > From: Konrad Rzeszutek Wilk [mailto:konrad.wilk@oracle.com]
> > Sent: Friday, September 23, 2011 9:43 AM
> > To: Kirsher, Jeffrey T
> > Cc: Rose, Gregory V; Ian Campbell; davem@davemloft.net; Jesse Barnes;
> > netdev@vger.kernel.org; gospo@redhat.com; linux-pci@vger.kernel.org
> > Subject: Re: [net-next 1/8] pci: Add flag indicating device has been
> > assigned by KVM
> >
> > On Fri, Sep 23, 2011 at 08:45:09AM -0700, Jeff Kirsher wrote:
> > > On Fri, 2011-09-23 at 08:11 -0700, Rose, Gregory V wrote:
> > > > > -----Original Message-----
> > > > > From: Ian Campbell [mailto:ijc@hellion.org.uk]
> > > > > Sent: Friday, September 23, 2011 8:04 AM
> > > > > To: Rose, Gregory V
> > > > > Cc: Kirsher, Jeffrey T; davem@davemloft.net; konrad.wilk@oracle.com;
> > Jesse
> > > > > Barnes; netdev@vger.kernel.org; gospo@redhat.com; linux-
> > > > > pci@vger.kernel.org
> > > > > Subject: RE: [net-next 1/8] pci: Add flag indicating device has been
> > > > > assigned by KVM
> > > > >
> > > > > On Fri, 2011-09-23 at 07:41 -0700, Rose, Gregory V wrote:
> > > > > > > -----Original Message-----
> > > > > > > From: Ian Campbell [mailto:ijc@hellion.org.uk]
> > > > > > > Sent: Friday, September 23, 2011 12:28 AM
> > > > > > > To: Kirsher, Jeffrey T
> > > > > > > Cc: davem@davemloft.net; konrad.wilk@oracle.com; Jesse Barnes;
> > Rose,
> > > > > > > Gregory V; netdev@vger.kernel.org; gospo@redhat.com; linux-
> > > > > > > pci@vger.kernel.org
> > > > > > > Subject: Re: [net-next 1/8] pci: Add flag indicating device has
> > been
> > > > > > > assigned by KVM
> > > > > > >
> > > > > > > I suppose by that measure the comment could be less KVM
> > specific:
> > > > > > > > + /* Provide indication device is assigned by KVM */
> > > > > > > > + PCI_DEV_FLAGS_ASSIGNED = (__force pci_dev_flags_t) 4,
> > > > > >
> > > > > > We can resubmit with a more generic comment, maybe this:
> > > > > >
> > > > > > /* Provide indication device is assigned by a Virtual Machine
> > Manager */
> > > > >
> > > > > Sounds good to me.
> > > >
> > > > Dave, Jeff,
> > > >
> > > > Should I resubmit the patch or would it be more convenient to post a
> > follow on patch that fixes up the comment? Either way is fine by me.
> > > >
> > > > - Greg
> > > >
> > >
> > > let's fix up the patch in my tree and add Jesse Barnes's ACK at the same
> > > time.
> >
> > Were are the patches now? I am kind of curious to see the changes to the
> > xen pciback.
> >
> >
>
> Version 2 of this patch with the modified comment was just posted to netdev. Ian Campbell had mentioned that the Xen pciback driver should be modified to use this flag but I don't believe any patches for it have been created yet.
http://marc.info/?i=20110729165446.GA6731@dumpdata.com
?
^ permalink raw reply
* Re: [net-next 01/02] ixgb: eliminate checkstack warnings
From: Joe Perches @ 2011-09-23 17:59 UTC (permalink / raw)
To: Jeff Kirsher; +Cc: davem, Jesse Brandeburg, netdev, gospo
In-Reply-To: <1316779890-32436-1-git-send-email-jeffrey.t.kirsher@intel.com>
On Fri, 2011-09-23 at 05:11 -0700, Jeff Kirsher wrote:
> From: Jesse Brandeburg <jesse.brandeburg@intel.com>
>
> Really trivial fix, use kmalloc/kfree instead of stack space.
> use static const instead of const to further reduce stack usage.
>
> V2: reflect changes suggested by Joe Perches
This is a less than complete commit log as
the patch also converts a local #define
of IXGB_ETH_LENGTH_OF_ADDRESS to ETH_ALEN
^ permalink raw reply
* Re: [PATCH v5 0/3] add fec support for imx6q
From: David Miller @ 2011-09-23 17:56 UTC (permalink / raw)
To: shawn.guo; +Cc: netdev, linux-arm-kernel, patches
In-Reply-To: <1316779968-21390-1-git-send-email-shawn.guo@linaro.org>
From: Shawn Guo <shawn.guo@linaro.org>
Date: Fri, 23 Sep 2011 20:12:45 +0800
> This series adds imx6q enet support. The imx6q enet is a derivative of
> imx28 enet controller. It fixes the frame endian issue found on imx28,
> and adds 1 Gbps support.
All applied.
^ permalink raw reply
* Re: [PATCH next 0/4] Pull request for 'davem-next.r8169' branch
From: David Miller @ 2011-09-23 17:55 UTC (permalink / raw)
To: romieu; +Cc: netdev, nic_swsd, hayeswang
In-Reply-To: <20110922210202.GA16362@electric-eye.fr.zoreil.com>
From: Francois Romieu <romieu@fr.zoreil.com>
Date: Thu, 22 Sep 2011 23:02:02 +0200
> Please pull from branch 'davem-next.r8169' in repository
>
> git://violet.fr.zoreil.com/romieu/linux davem-next.r8169
>
> to get the changes below.
Pulled, thanks Francois.
^ permalink raw reply
* Re: [net-next 0/8 v2][pull request] Intel Wired LAN Driver Updates
From: David Miller @ 2011-09-23 17:57 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, gospo
In-Reply-To: <1316794367-23265-1-git-send-email-jeffrey.t.kirsher@intel.com>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Fri, 23 Sep 2011 09:12:39 -0700
> The following series contains updates to ixgbe and PCI. The PCI patch
> is a small update to add a flag to indicate when a device has been
> assigned by KVM. The ixgbe patches consist of the following:
>
> - reconfigure SR-IOV init to take advantage of the new pci flag
> - DCB cleanups/fixes
> - add WOL support for x540
> - a few cleanup/fixes
>
> -v2 Fixed up comment in the PCI patch based on feedback from Ian Campbell
>
> The following are changes since commit 9c9b1f24f2aa31a3cea94939edc551f68ebadc89:
> net/phy: add IC+ IP101A and support APS.
> and are available in the git repository at:
> git://github.com/Jkirsher/net-next.git
Pulled, thanks Jeff.
^ permalink raw reply
* Re: [net-next 02/02] ixgb: finish conversion to ndo_fix_features
From: David Miller @ 2011-09-23 17:56 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: mirq-linux, netdev, gospo
In-Reply-To: <1316779890-32436-2-git-send-email-jeffrey.t.kirsher@intel.com>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Fri, 23 Sep 2011 05:11:30 -0700
> From: Michał Mirosław <mirq-linux@rere.qmqm.pl>
>
> Finish conversion to unified ethtool ops: convert get_flags.
>
> Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl>
> Tested-by: Aaron Brown <aaron.f.brown@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Applied.
^ permalink raw reply
* Re: [net-next 01/02] ixgb: eliminate checkstack warnings
From: David Miller @ 2011-09-23 17:56 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: jesse.brandeburg, netdev, gospo
In-Reply-To: <1316779890-32436-1-git-send-email-jeffrey.t.kirsher@intel.com>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Fri, 23 Sep 2011 05:11:29 -0700
> From: Jesse Brandeburg <jesse.brandeburg@intel.com>
>
> Really trivial fix, use kmalloc/kfree instead of stack space.
> use static const instead of const to further reduce stack usage.
>
> V2: reflect changes suggested by Joe Perches
>
> before:
> [jbrandeb@jbrandeb-mobl2 linux-2.6]$ make checkstack|grep '\[ixgb\]'
> 0x00000fc1 ixgb_set_multi [ixgb]: 768
> 0x00001031 ixgb_set_multi [ixgb]: 768
> 0x000010f2 ixgb_set_multi [ixgb]: 768
> 0x061c ixgb_check_options [ixgb]: 448
> 0x09c3 ixgb_check_options [ixgb]: 448
> 0x0000649e ixgb_set_ringparam [ixgb]: 192
> 0x0000130d ixgb_xmit_frame [ixgb]: 184
> 0x000019e0 ixgb_xmit_frame [ixgb]: 184
> 0x00002267 ixgb_clean [ixgb]: 152
> 0x00002673 ixgb_clean [ixgb]: 152
>
> after:
> 0x000064ee ixgb_set_ringparam [ixgb]: 192
> 0x0000135d ixgb_xmit_frame [ixgb]: 184
> 0x00001a30 ixgb_xmit_frame [ixgb]: 184
> 0x000022b7 ixgb_clean [ixgb]: 152
> 0x000026c3 ixgb_clean [ixgb]: 152
>
> Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
> Tested-by: Aaron Brown <aaron.f.brown@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Applied.
^ permalink raw reply
* Re: [PATCH] tcp: ECN blackhole should not force quickack mode
From: David Miller @ 2011-09-23 17:47 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev, hkchu, ilpo.jarvinen, jhs, jg, dave.taht
In-Reply-To: <1316757739.2560.12.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Fri, 23 Sep 2011 08:02:19 +0200
> While playing with a new ADSL box at home, I discovered that ECN
> blackhole can trigger suboptimal quickack mode on linux : We send one
> ACK for each incoming data frame, without any delay and eventual
> piggyback.
>
> This is because TCP_ECN_check_ce() considers that if no ECT is seen on a
> segment, this is because this segment was a retransmit.
>
> Refine this heuristic and apply it only if we seen ECT in a previous
> segment, to detect ECN blackhole at IP level.
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
> CC: Jamal Hadi Salim <jhs@mojatatu.com>
> CC: Jerry Chu <hkchu@google.com>
> CC: Ilpo Järvinen <ilpo.jarvinen@helsinki.fi>
> CC: Jim Gettys <jg@freedesktop.org>
> CC: Dave Taht <dave.taht@gmail.com>
> ---
> Another possibility is to remove this (not in RFC 3168) heuristic, what
> do you think ?
Jamal, please give this a look over. Thanks!
^ permalink raw reply
* Re: [PATCH net-next] can/sja1000: add driver for EMS PCMCIA card
From: Wolfram Sang @ 2011-09-23 17:32 UTC (permalink / raw)
To: Oliver Hartkopp
Cc: David Miller, SocketCAN Core Mailing List, Linux Netdev List,
Markus Plessing, Wolfgang Grandegger, linux-pcmcia
In-Reply-To: <4E7CBB04.8070807@hartkopp.net>
[-- Attachment #1: Type: text/plain, Size: 12060 bytes --]
CCing pcmcia-devel...
On Fri, Sep 23, 2011 at 06:59:48PM +0200, Oliver Hartkopp wrote:
> This patch adds the driver for the SJA1000 based PCMCIA card 'CPC-Card' from
> EMS Dr. Thomas Wuensche (http://www.ems-wuensche.de).
>
> Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
>
> ---
>
> diff -u -r -N a/drivers/net/can/sja1000/Kconfig b/drivers/net/can/sja1000/Kconfig
> --- a/drivers/net/can/sja1000/Kconfig 2011-09-23 18:02:35.711750820 +0200
> +++ b/drivers/net/can/sja1000/Kconfig 2011-09-23 18:02:28.695751113 +0200
> @@ -29,6 +29,13 @@
> OpenFirmware bindings, e.g. if you have a PowerPC based system
> you may want to enable this option.
>
> +config CAN_EMS_PCMCIA
> + tristate "EMS CPC-CARD Card"
> + depends on PCMCIA
> + ---help---
> + This driver is for the one or two channel CPC-CARD cards from
> + EMS Dr. Thomas Wuensche (http://www.ems-wuensche.de).
> +
> config CAN_EMS_PCI
> tristate "EMS CPC-PCI, CPC-PCIe and CPC-104P Card"
> depends on PCI
> diff -u -r -N a/drivers/net/can/sja1000/Makefile b/drivers/net/can/sja1000/Makefile
> --- a/drivers/net/can/sja1000/Makefile 2011-09-23 18:02:38.595750534 +0200
> +++ b/drivers/net/can/sja1000/Makefile 2011-09-23 18:02:28.695751113 +0200
> @@ -6,6 +6,7 @@
> obj-$(CONFIG_CAN_SJA1000_ISA) += sja1000_isa.o
> obj-$(CONFIG_CAN_SJA1000_PLATFORM) += sja1000_platform.o
> obj-$(CONFIG_CAN_SJA1000_OF_PLATFORM) += sja1000_of_platform.o
> +obj-$(CONFIG_CAN_EMS_PCMCIA) += ems_pcmcia.o
> obj-$(CONFIG_CAN_EMS_PCI) += ems_pci.o
> obj-$(CONFIG_CAN_KVASER_PCI) += kvaser_pci.o
> obj-$(CONFIG_CAN_PEAK_PCI) += peak_pci.o
> diff -u -r -N a/drivers/net/can/sja1000/ems_pcmcia.c b/drivers/net/can/sja1000/ems_pcmcia.c
> --- a/drivers/net/can/sja1000/ems_pcmcia.c 1970-01-01 01:00:00.000000000 +0100
> +++ b/drivers/net/can/sja1000/ems_pcmcia.c 2011-09-23 18:13:59.227726972 +0200
> @@ -0,0 +1,331 @@
> +/*
> + * Copyright (C) 2008 Sebastian Haas (initial chardev implementation)
> + * Copyright (C) 2010 Markus Plessing <plessing@ems-wuensche.com>
> + * Rework for mainline by Oliver Hartkopp <socketcan@hartkopp.net>
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the version 2 of the GNU General Public License
> + * as published by the Free Software Foundation
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + */
> +
> +#include <linux/kernel.h>
> +#include <linux/module.h>
> +#include <linux/interrupt.h>
> +#include <linux/netdevice.h>
> +#include <linux/delay.h>
> +#include <linux/io.h>
> +#include <pcmcia/cistpl.h>
> +#include <pcmcia/ds.h>
> +#include <linux/can.h>
> +#include <linux/can/dev.h>
> +#include "sja1000.h"
> +
> +#define DRV_NAME "ems_pcmcia"
> +
> +MODULE_AUTHOR("Markus Plessing <plessing@ems-wuensche.com>");
> +MODULE_DESCRIPTION("Socket-CAN driver for EMS CPC-CARD cards");
> +MODULE_SUPPORTED_DEVICE("EMS CPC-CARD CAN card");
> +MODULE_LICENSE("GPL v2");
> +
> +#define EMS_PCMCIA_MAX_CHAN 2
> +
> +struct ems_pcmcia_card {
> + int channels;
> + struct pcmcia_device *pcmcia_dev;
> + struct net_device *net_dev[EMS_PCMCIA_MAX_CHAN];
> + void __iomem *base_addr;
> +};
> +
> +#define EMS_PCMCIA_CAN_CLOCK (16000000 / 2)
> +
> +/*
> + * The board configuration is probably following:
> + * RX1 is connected to ground.
> + * TX1 is not connected.
> + * CLKO is not connected.
> + * Setting the OCR register to 0xDA is a good idea.
> + * This means normal output mode , push-pull and the correct polarity.
> + */
> +#define EMS_PCMCIA_OCR (OCR_TX0_PUSHPULL | OCR_TX1_PUSHPULL)
> +
> +/*
> + * In the CDR register, you should set CBP to 1.
> + * You will probably also want to set the clock divider value to 7
> + * (meaning direct oscillator output) because the second SJA1000 chip
> + * is driven by the first one CLKOUT output.
> + */
> +#define EMS_PCMCIA_CDR (CDR_CBP | CDR_CLKOUT_MASK)
> +#define EMS_PCMCIA_MEM_SIZE 4096 /* Size of the remapped io-memory */
> +#define EMS_PCMCIA_CAN_BASE_OFFSET 0x100 /* Offset where controllers starts */
> +#define EMS_PCMCIA_CAN_CTRL_SIZE 0x80 /* Memory size for each controller */
> +
> +#define EMS_CMD_RESET 0x00 /* Perform a reset of the card */
> +#define EMS_CMD_MAP 0x03 /* Map CAN controllers into card' memory */
> +#define EMS_CMD_UMAP 0x02 /* Unmap CAN controllers from card' memory */
> +
> +static struct pcmcia_device_id ems_pcmcia_tbl[] = {
> + PCMCIA_DEVICE_PROD_ID123("EMS_T_W", "CPC-Card", "V2.0", 0xeab1ea23,
> + 0xa338573f, 0xe4575800),
> + PCMCIA_DEVICE_NULL,
> +};
> +
> +MODULE_DEVICE_TABLE(pcmcia, ems_pcmcia_tbl);
> +
> +static u8 ems_pcmcia_read_reg(const struct sja1000_priv *priv, int port)
> +{
> + return readb(priv->reg_base + port);
> +}
> +
> +static void ems_pcmcia_write_reg(const struct sja1000_priv *priv, int port,
> + u8 val)
> +{
> + writeb(val, priv->reg_base + port);
> +}
> +
> +static irqreturn_t ems_pcmcia_interrupt(int irq, void *dev_id)
> +{
> + struct ems_pcmcia_card *card = dev_id;
> + struct net_device *dev;
> + irqreturn_t retval = IRQ_NONE;
> + int i, again;
> +
> + /* Card not present */
> + if (readw(card->base_addr) != 0xAA55)
> + return IRQ_HANDLED;
> +
> + do {
> + again = 0;
> +
> + /* Check interrupt for each channel */
> + for (i = 0; i < card->channels; i++) {
> + dev = card->net_dev[i];
> + if (!dev)
> + continue;
> +
> + if (sja1000_interrupt(irq, dev) == IRQ_HANDLED)
> + again = 1;
> + }
> + /* At least one channel handled the interrupt */
> + if (again)
> + retval = IRQ_HANDLED;
> +
> + } while (again);
> +
> + return retval;
> +}
> +
> +/*
> + * Check if a CAN controller is present at the specified location
> + * by trying to set 'em into the PeliCAN mode
> + */
> +static inline int ems_pcmcia_check_chan(struct sja1000_priv *priv)
> +{
> + /* Make sure SJA1000 is in reset mode */
> + ems_pcmcia_write_reg(priv, REG_MOD, 1);
> + ems_pcmcia_write_reg(priv, REG_CDR, CDR_PELICAN);
> +
> + /* read reset-values */
> + if (ems_pcmcia_read_reg(priv, REG_CDR) == CDR_PELICAN)
> + return 1;
> +
> + return 0;
> +}
> +
> +static void ems_pcmcia_del_card(struct pcmcia_device *pdev)
> +{
> + struct ems_pcmcia_card *card = pdev->priv;
> + struct net_device *dev;
> + int i;
> +
> + free_irq(pdev->irq, card);
> +
> + for (i = 0; i < card->channels; i++) {
> + dev = card->net_dev[i];
> + if (!dev)
> + continue;
> +
> + printk(KERN_INFO "%s: removing %s on channel #%d\n",
> + DRV_NAME, dev->name, i);
> + unregister_sja1000dev(dev);
> + free_sja1000dev(dev);
> + }
> +
> + writeb(EMS_CMD_UMAP, card->base_addr);
> + iounmap(card->base_addr);
> + kfree(card);
> +
> + pdev->priv = NULL;
> +}
> +
> +/*
> + * Probe PCI device for EMS CAN signature and register each available
> + * CAN channel to SJA1000 Socket-CAN subsystem.
> + */
> +static int __devinit ems_pcmcia_add_card(struct pcmcia_device *pdev,
> + unsigned long base)
> +{
> + struct sja1000_priv *priv;
> + struct net_device *dev;
> + struct ems_pcmcia_card *card;
> + int err, i;
> +
> + /* Allocating card structures to hold addresses, ... */
> + card = kzalloc(sizeof(struct ems_pcmcia_card), GFP_KERNEL);
> + if (!card)
> + return -ENOMEM;
> +
> + pdev->priv = card;
> + card->channels = 0;
> +
> + card->base_addr = ioremap(base, EMS_PCMCIA_MEM_SIZE);
> + if (!card->base_addr) {
> + err = -ENOMEM;
> + goto failure_cleanup;
> + }
> +
> + /* Check for unique EMS CAN signature */
> + if (readw(card->base_addr) != 0xAA55) {
> + err = -ENODEV;
> + goto failure_cleanup;
> + }
> +
> + /* Request board reset */
> + writeb(EMS_CMD_RESET, card->base_addr);
> +
> + /* Make sure CAN controllers are mapped into card's memory space */
> + writeb(EMS_CMD_MAP, card->base_addr);
> +
> + /* Detect available channels */
> + for (i = 0; i < EMS_PCMCIA_MAX_CHAN; i++) {
> + dev = alloc_sja1000dev(0);
> + if (!dev) {
> + err = -ENOMEM;
> + goto failure_cleanup;
> + }
> +
> + card->net_dev[i] = dev;
> + priv = netdev_priv(dev);
> + priv->priv = card;
> + SET_NETDEV_DEV(dev, &pdev->dev);
> +
> + priv->irq_flags = IRQF_SHARED;
> + dev->irq = pdev->irq;
> + priv->reg_base = card->base_addr + EMS_PCMCIA_CAN_BASE_OFFSET +
> + (i * EMS_PCMCIA_CAN_CTRL_SIZE);
> +
> + /* Check if channel is present */
> + if (ems_pcmcia_check_chan(priv)) {
> + priv->read_reg = ems_pcmcia_read_reg;
> + priv->write_reg = ems_pcmcia_write_reg;
> + priv->can.clock.freq = EMS_PCMCIA_CAN_CLOCK;
> + priv->ocr = EMS_PCMCIA_OCR;
> + priv->cdr = EMS_PCMCIA_CDR;
> + priv->flags |= SJA1000_CUSTOM_IRQ_HANDLER;
> +
> + /* Register SJA1000 device */
> + err = register_sja1000dev(dev);
> + if (err) {
> + free_sja1000dev(dev);
> + goto failure_cleanup;
> + }
> +
> + card->channels++;
> +
> + printk(KERN_INFO "%s: registered %s on channel "
> + "#%d at 0x%p, irq %d\n", DRV_NAME, dev->name,
> + i, priv->reg_base, dev->irq);
> + } else
> + free_sja1000dev(dev);
> + }
> +
> + err = request_irq(dev->irq, &ems_pcmcia_interrupt, IRQF_SHARED,
> + DRV_NAME, card);
> + if (!err)
> + return 0;
> +
> +failure_cleanup:
> + ems_pcmcia_del_card(pdev);
> + return err;
> +}
> +
> +/*
> + * Setup PCMCIA socket and probe for EMS CPC-CARD
> + */
> +static int __devinit ems_pcmcia_probe(struct pcmcia_device *dev)
> +{
> + int csval;
> +
> + /* General socket configuration */
> + dev->config_flags |= CONF_ENABLE_IRQ;
> + dev->config_index = 1;
> + dev->config_regs = PRESENT_OPTION;
> +
> + /* The io structure describes IO port mapping */
> + dev->resource[0]->end = 16;
> + dev->resource[0]->flags |= IO_DATA_PATH_WIDTH_8;
> + dev->resource[1]->end = 16;
> + dev->resource[1]->flags |= IO_DATA_PATH_WIDTH_16;
> + dev->io_lines = 5;
> +
> + /* Allocate a memory window */
> + dev->resource[2]->flags =
> + (WIN_DATA_WIDTH_8 | WIN_MEMORY_TYPE_CM | WIN_ENABLE);
> + dev->resource[2]->start = dev->resource[2]->end = 0;
> +
> + csval = pcmcia_request_window(dev, dev->resource[2], 0);
> + if (csval) {
> + dev_err(&dev->dev, "pcmcia_request_window failed (err=%d)\n",
> + csval);
> + return 0;
> + }
> +
> + csval = pcmcia_map_mem_page(dev, dev->resource[2], dev->config_base);
> + if (csval) {
> + dev_err(&dev->dev, "pcmcia_map_mem_page failed (err=%d)\n",
> + csval);
> + return 0;
> + }
> +
> + csval = pcmcia_enable_device(dev);
> + if (csval) {
> + dev_err(&dev->dev, "pcmcia_enable_device failed (err=%d)\n",
> + csval);
> + return 0;
> + }
> +
> + ems_pcmcia_add_card(dev, dev->resource[2]->start);
> + return 0;
> +}
> +
> +/*
> + * Release claimed resources
> + */
> +static void ems_pcmcia_remove(struct pcmcia_device *dev)
> +{
> + ems_pcmcia_del_card(dev);
> + pcmcia_disable_device(dev);
> +}
> +
> +static struct pcmcia_driver ems_pcmcia_driver = {
> + .name = DRV_NAME,
> + .probe = ems_pcmcia_probe,
> + .remove = ems_pcmcia_remove,
> + .id_table = ems_pcmcia_tbl,
> +};
> +
> +static int __init ems_pcmcia_init(void)
> +{
> + return pcmcia_register_driver(&ems_pcmcia_driver);
> +}
> +module_init(ems_pcmcia_init);
> +
> +static void __exit ems_pcmcia_exit(void)
> +{
> + pcmcia_unregister_driver(&ems_pcmcia_driver);
> +}
> +module_exit(ems_pcmcia_exit);
>
> _______________________________________________
> Socketcan-core mailing list
> Socketcan-core@lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/socketcan-core
--
Pengutronix e.K. | Wolfram Sang |
Industrial Linux Solutions | http://www.pengutronix.de/ |
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* RE: [PATCH v6 1/8] SUNRPC: introduce helpers for reference counted rpcbind clients
From: Myklebust, Trond @ 2011-09-23 17:26 UTC (permalink / raw)
To: Stanislav Kinsbursky
Cc: linux-nfs, Pavel Emelianov, neilb, netdev, linux-kernel, bfields,
davem
In-Reply-To: <4E7C9A91.1060301@parallels.com>
> -----Original Message-----
> From: Stanislav Kinsbursky [mailto:skinsbursky@parallels.com]
> Sent: Friday, September 23, 2011 10:41 AM
> To: Myklebust, Trond
> Cc: linux-nfs@vger.kernel.org; Pavel Emelianov; neilb@suse.de;
> netdev@vger.kernel.org; linux-kernel@vger.kernel.org;
> bfields@fieldses.org; davem@davemloft.net
> Subject: Re: [PATCH v6 1/8] SUNRPC: introduce helpers for reference
> counted rpcbind clients
>
> Trond, is this patch version suits you now? Or not?
> Please, comment somehow to let me know, may I proceed with further
> development or not.
Hi Stanislav,
Yes, this version of the patch looks safe to me.
Cheers
Trond
^ permalink raw reply
* RE: [net-next 1/8] pci: Add flag indicating device has been assigned by KVM
From: Rose, Gregory V @ 2011-09-23 17:04 UTC (permalink / raw)
To: Konrad Rzeszutek Wilk, Kirsher, Jeffrey T
Cc: Ian Campbell, davem@davemloft.net, Jesse Barnes,
netdev@vger.kernel.org, gospo@redhat.com,
linux-pci@vger.kernel.org
In-Reply-To: <20110923164326.GA23363@phenom.oracle.com>
> -----Original Message-----
> From: Konrad Rzeszutek Wilk [mailto:konrad.wilk@oracle.com]
> Sent: Friday, September 23, 2011 9:43 AM
> To: Kirsher, Jeffrey T
> Cc: Rose, Gregory V; Ian Campbell; davem@davemloft.net; Jesse Barnes;
> netdev@vger.kernel.org; gospo@redhat.com; linux-pci@vger.kernel.org
> Subject: Re: [net-next 1/8] pci: Add flag indicating device has been
> assigned by KVM
>
> On Fri, Sep 23, 2011 at 08:45:09AM -0700, Jeff Kirsher wrote:
> > On Fri, 2011-09-23 at 08:11 -0700, Rose, Gregory V wrote:
> > > > -----Original Message-----
> > > > From: Ian Campbell [mailto:ijc@hellion.org.uk]
> > > > Sent: Friday, September 23, 2011 8:04 AM
> > > > To: Rose, Gregory V
> > > > Cc: Kirsher, Jeffrey T; davem@davemloft.net; konrad.wilk@oracle.com;
> Jesse
> > > > Barnes; netdev@vger.kernel.org; gospo@redhat.com; linux-
> > > > pci@vger.kernel.org
> > > > Subject: RE: [net-next 1/8] pci: Add flag indicating device has been
> > > > assigned by KVM
> > > >
> > > > On Fri, 2011-09-23 at 07:41 -0700, Rose, Gregory V wrote:
> > > > > > -----Original Message-----
> > > > > > From: Ian Campbell [mailto:ijc@hellion.org.uk]
> > > > > > Sent: Friday, September 23, 2011 12:28 AM
> > > > > > To: Kirsher, Jeffrey T
> > > > > > Cc: davem@davemloft.net; konrad.wilk@oracle.com; Jesse Barnes;
> Rose,
> > > > > > Gregory V; netdev@vger.kernel.org; gospo@redhat.com; linux-
> > > > > > pci@vger.kernel.org
> > > > > > Subject: Re: [net-next 1/8] pci: Add flag indicating device has
> been
> > > > > > assigned by KVM
> > > > > >
> > > > > > I suppose by that measure the comment could be less KVM
> specific:
> > > > > > > + /* Provide indication device is assigned by KVM */
> > > > > > > + PCI_DEV_FLAGS_ASSIGNED = (__force pci_dev_flags_t) 4,
> > > > >
> > > > > We can resubmit with a more generic comment, maybe this:
> > > > >
> > > > > /* Provide indication device is assigned by a Virtual Machine
> Manager */
> > > >
> > > > Sounds good to me.
> > >
> > > Dave, Jeff,
> > >
> > > Should I resubmit the patch or would it be more convenient to post a
> follow on patch that fixes up the comment? Either way is fine by me.
> > >
> > > - Greg
> > >
> >
> > let's fix up the patch in my tree and add Jesse Barnes's ACK at the same
> > time.
>
> Were are the patches now? I am kind of curious to see the changes to the
> xen pciback.
>
>
Version 2 of this patch with the modified comment was just posted to netdev. Ian Campbell had mentioned that the Xen pciback driver should be modified to use this flag but I don't believe any patches for it have been created yet.
- Greg
^ permalink raw reply
* [PATCH net-next] can/sja1000: add driver for EMS PCMCIA card
From: Oliver Hartkopp @ 2011-09-23 16:59 UTC (permalink / raw)
To: David Miller
Cc: SocketCAN Core Mailing List, Linux Netdev List, Markus Plessing,
Wolfgang Grandegger
This patch adds the driver for the SJA1000 based PCMCIA card 'CPC-Card' from
EMS Dr. Thomas Wuensche (http://www.ems-wuensche.de).
Signed-off-by: Oliver Hartkopp <socketcan-fJ+pQTUTwRTk1uMJSBkQmQ@public.gmane.org>
---
diff -u -r -N a/drivers/net/can/sja1000/Kconfig b/drivers/net/can/sja1000/Kconfig
--- a/drivers/net/can/sja1000/Kconfig 2011-09-23 18:02:35.711750820 +0200
+++ b/drivers/net/can/sja1000/Kconfig 2011-09-23 18:02:28.695751113 +0200
@@ -29,6 +29,13 @@
OpenFirmware bindings, e.g. if you have a PowerPC based system
you may want to enable this option.
+config CAN_EMS_PCMCIA
+ tristate "EMS CPC-CARD Card"
+ depends on PCMCIA
+ ---help---
+ This driver is for the one or two channel CPC-CARD cards from
+ EMS Dr. Thomas Wuensche (http://www.ems-wuensche.de).
+
config CAN_EMS_PCI
tristate "EMS CPC-PCI, CPC-PCIe and CPC-104P Card"
depends on PCI
diff -u -r -N a/drivers/net/can/sja1000/Makefile b/drivers/net/can/sja1000/Makefile
--- a/drivers/net/can/sja1000/Makefile 2011-09-23 18:02:38.595750534 +0200
+++ b/drivers/net/can/sja1000/Makefile 2011-09-23 18:02:28.695751113 +0200
@@ -6,6 +6,7 @@
obj-$(CONFIG_CAN_SJA1000_ISA) += sja1000_isa.o
obj-$(CONFIG_CAN_SJA1000_PLATFORM) += sja1000_platform.o
obj-$(CONFIG_CAN_SJA1000_OF_PLATFORM) += sja1000_of_platform.o
+obj-$(CONFIG_CAN_EMS_PCMCIA) += ems_pcmcia.o
obj-$(CONFIG_CAN_EMS_PCI) += ems_pci.o
obj-$(CONFIG_CAN_KVASER_PCI) += kvaser_pci.o
obj-$(CONFIG_CAN_PEAK_PCI) += peak_pci.o
diff -u -r -N a/drivers/net/can/sja1000/ems_pcmcia.c b/drivers/net/can/sja1000/ems_pcmcia.c
--- a/drivers/net/can/sja1000/ems_pcmcia.c 1970-01-01 01:00:00.000000000 +0100
+++ b/drivers/net/can/sja1000/ems_pcmcia.c 2011-09-23 18:13:59.227726972 +0200
@@ -0,0 +1,331 @@
+/*
+ * Copyright (C) 2008 Sebastian Haas (initial chardev implementation)
+ * Copyright (C) 2010 Markus Plessing <plessing-zsNKPWJ8Pib6hrUXjxyGrA@public.gmane.org>
+ * Rework for mainline by Oliver Hartkopp <socketcan-fJ+pQTUTwRTk1uMJSBkQmQ@public.gmane.org>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the version 2 of the GNU General Public License
+ * as published by the Free Software Foundation
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/interrupt.h>
+#include <linux/netdevice.h>
+#include <linux/delay.h>
+#include <linux/io.h>
+#include <pcmcia/cistpl.h>
+#include <pcmcia/ds.h>
+#include <linux/can.h>
+#include <linux/can/dev.h>
+#include "sja1000.h"
+
+#define DRV_NAME "ems_pcmcia"
+
+MODULE_AUTHOR("Markus Plessing <plessing-zsNKPWJ8Pib6hrUXjxyGrA@public.gmane.org>");
+MODULE_DESCRIPTION("Socket-CAN driver for EMS CPC-CARD cards");
+MODULE_SUPPORTED_DEVICE("EMS CPC-CARD CAN card");
+MODULE_LICENSE("GPL v2");
+
+#define EMS_PCMCIA_MAX_CHAN 2
+
+struct ems_pcmcia_card {
+ int channels;
+ struct pcmcia_device *pcmcia_dev;
+ struct net_device *net_dev[EMS_PCMCIA_MAX_CHAN];
+ void __iomem *base_addr;
+};
+
+#define EMS_PCMCIA_CAN_CLOCK (16000000 / 2)
+
+/*
+ * The board configuration is probably following:
+ * RX1 is connected to ground.
+ * TX1 is not connected.
+ * CLKO is not connected.
+ * Setting the OCR register to 0xDA is a good idea.
+ * This means normal output mode , push-pull and the correct polarity.
+ */
+#define EMS_PCMCIA_OCR (OCR_TX0_PUSHPULL | OCR_TX1_PUSHPULL)
+
+/*
+ * In the CDR register, you should set CBP to 1.
+ * You will probably also want to set the clock divider value to 7
+ * (meaning direct oscillator output) because the second SJA1000 chip
+ * is driven by the first one CLKOUT output.
+ */
+#define EMS_PCMCIA_CDR (CDR_CBP | CDR_CLKOUT_MASK)
+#define EMS_PCMCIA_MEM_SIZE 4096 /* Size of the remapped io-memory */
+#define EMS_PCMCIA_CAN_BASE_OFFSET 0x100 /* Offset where controllers starts */
+#define EMS_PCMCIA_CAN_CTRL_SIZE 0x80 /* Memory size for each controller */
+
+#define EMS_CMD_RESET 0x00 /* Perform a reset of the card */
+#define EMS_CMD_MAP 0x03 /* Map CAN controllers into card' memory */
+#define EMS_CMD_UMAP 0x02 /* Unmap CAN controllers from card' memory */
+
+static struct pcmcia_device_id ems_pcmcia_tbl[] = {
+ PCMCIA_DEVICE_PROD_ID123("EMS_T_W", "CPC-Card", "V2.0", 0xeab1ea23,
+ 0xa338573f, 0xe4575800),
+ PCMCIA_DEVICE_NULL,
+};
+
+MODULE_DEVICE_TABLE(pcmcia, ems_pcmcia_tbl);
+
+static u8 ems_pcmcia_read_reg(const struct sja1000_priv *priv, int port)
+{
+ return readb(priv->reg_base + port);
+}
+
+static void ems_pcmcia_write_reg(const struct sja1000_priv *priv, int port,
+ u8 val)
+{
+ writeb(val, priv->reg_base + port);
+}
+
+static irqreturn_t ems_pcmcia_interrupt(int irq, void *dev_id)
+{
+ struct ems_pcmcia_card *card = dev_id;
+ struct net_device *dev;
+ irqreturn_t retval = IRQ_NONE;
+ int i, again;
+
+ /* Card not present */
+ if (readw(card->base_addr) != 0xAA55)
+ return IRQ_HANDLED;
+
+ do {
+ again = 0;
+
+ /* Check interrupt for each channel */
+ for (i = 0; i < card->channels; i++) {
+ dev = card->net_dev[i];
+ if (!dev)
+ continue;
+
+ if (sja1000_interrupt(irq, dev) == IRQ_HANDLED)
+ again = 1;
+ }
+ /* At least one channel handled the interrupt */
+ if (again)
+ retval = IRQ_HANDLED;
+
+ } while (again);
+
+ return retval;
+}
+
+/*
+ * Check if a CAN controller is present at the specified location
+ * by trying to set 'em into the PeliCAN mode
+ */
+static inline int ems_pcmcia_check_chan(struct sja1000_priv *priv)
+{
+ /* Make sure SJA1000 is in reset mode */
+ ems_pcmcia_write_reg(priv, REG_MOD, 1);
+ ems_pcmcia_write_reg(priv, REG_CDR, CDR_PELICAN);
+
+ /* read reset-values */
+ if (ems_pcmcia_read_reg(priv, REG_CDR) == CDR_PELICAN)
+ return 1;
+
+ return 0;
+}
+
+static void ems_pcmcia_del_card(struct pcmcia_device *pdev)
+{
+ struct ems_pcmcia_card *card = pdev->priv;
+ struct net_device *dev;
+ int i;
+
+ free_irq(pdev->irq, card);
+
+ for (i = 0; i < card->channels; i++) {
+ dev = card->net_dev[i];
+ if (!dev)
+ continue;
+
+ printk(KERN_INFO "%s: removing %s on channel #%d\n",
+ DRV_NAME, dev->name, i);
+ unregister_sja1000dev(dev);
+ free_sja1000dev(dev);
+ }
+
+ writeb(EMS_CMD_UMAP, card->base_addr);
+ iounmap(card->base_addr);
+ kfree(card);
+
+ pdev->priv = NULL;
+}
+
+/*
+ * Probe PCI device for EMS CAN signature and register each available
+ * CAN channel to SJA1000 Socket-CAN subsystem.
+ */
+static int __devinit ems_pcmcia_add_card(struct pcmcia_device *pdev,
+ unsigned long base)
+{
+ struct sja1000_priv *priv;
+ struct net_device *dev;
+ struct ems_pcmcia_card *card;
+ int err, i;
+
+ /* Allocating card structures to hold addresses, ... */
+ card = kzalloc(sizeof(struct ems_pcmcia_card), GFP_KERNEL);
+ if (!card)
+ return -ENOMEM;
+
+ pdev->priv = card;
+ card->channels = 0;
+
+ card->base_addr = ioremap(base, EMS_PCMCIA_MEM_SIZE);
+ if (!card->base_addr) {
+ err = -ENOMEM;
+ goto failure_cleanup;
+ }
+
+ /* Check for unique EMS CAN signature */
+ if (readw(card->base_addr) != 0xAA55) {
+ err = -ENODEV;
+ goto failure_cleanup;
+ }
+
+ /* Request board reset */
+ writeb(EMS_CMD_RESET, card->base_addr);
+
+ /* Make sure CAN controllers are mapped into card's memory space */
+ writeb(EMS_CMD_MAP, card->base_addr);
+
+ /* Detect available channels */
+ for (i = 0; i < EMS_PCMCIA_MAX_CHAN; i++) {
+ dev = alloc_sja1000dev(0);
+ if (!dev) {
+ err = -ENOMEM;
+ goto failure_cleanup;
+ }
+
+ card->net_dev[i] = dev;
+ priv = netdev_priv(dev);
+ priv->priv = card;
+ SET_NETDEV_DEV(dev, &pdev->dev);
+
+ priv->irq_flags = IRQF_SHARED;
+ dev->irq = pdev->irq;
+ priv->reg_base = card->base_addr + EMS_PCMCIA_CAN_BASE_OFFSET +
+ (i * EMS_PCMCIA_CAN_CTRL_SIZE);
+
+ /* Check if channel is present */
+ if (ems_pcmcia_check_chan(priv)) {
+ priv->read_reg = ems_pcmcia_read_reg;
+ priv->write_reg = ems_pcmcia_write_reg;
+ priv->can.clock.freq = EMS_PCMCIA_CAN_CLOCK;
+ priv->ocr = EMS_PCMCIA_OCR;
+ priv->cdr = EMS_PCMCIA_CDR;
+ priv->flags |= SJA1000_CUSTOM_IRQ_HANDLER;
+
+ /* Register SJA1000 device */
+ err = register_sja1000dev(dev);
+ if (err) {
+ free_sja1000dev(dev);
+ goto failure_cleanup;
+ }
+
+ card->channels++;
+
+ printk(KERN_INFO "%s: registered %s on channel "
+ "#%d at 0x%p, irq %d\n", DRV_NAME, dev->name,
+ i, priv->reg_base, dev->irq);
+ } else
+ free_sja1000dev(dev);
+ }
+
+ err = request_irq(dev->irq, &ems_pcmcia_interrupt, IRQF_SHARED,
+ DRV_NAME, card);
+ if (!err)
+ return 0;
+
+failure_cleanup:
+ ems_pcmcia_del_card(pdev);
+ return err;
+}
+
+/*
+ * Setup PCMCIA socket and probe for EMS CPC-CARD
+ */
+static int __devinit ems_pcmcia_probe(struct pcmcia_device *dev)
+{
+ int csval;
+
+ /* General socket configuration */
+ dev->config_flags |= CONF_ENABLE_IRQ;
+ dev->config_index = 1;
+ dev->config_regs = PRESENT_OPTION;
+
+ /* The io structure describes IO port mapping */
+ dev->resource[0]->end = 16;
+ dev->resource[0]->flags |= IO_DATA_PATH_WIDTH_8;
+ dev->resource[1]->end = 16;
+ dev->resource[1]->flags |= IO_DATA_PATH_WIDTH_16;
+ dev->io_lines = 5;
+
+ /* Allocate a memory window */
+ dev->resource[2]->flags =
+ (WIN_DATA_WIDTH_8 | WIN_MEMORY_TYPE_CM | WIN_ENABLE);
+ dev->resource[2]->start = dev->resource[2]->end = 0;
+
+ csval = pcmcia_request_window(dev, dev->resource[2], 0);
+ if (csval) {
+ dev_err(&dev->dev, "pcmcia_request_window failed (err=%d)\n",
+ csval);
+ return 0;
+ }
+
+ csval = pcmcia_map_mem_page(dev, dev->resource[2], dev->config_base);
+ if (csval) {
+ dev_err(&dev->dev, "pcmcia_map_mem_page failed (err=%d)\n",
+ csval);
+ return 0;
+ }
+
+ csval = pcmcia_enable_device(dev);
+ if (csval) {
+ dev_err(&dev->dev, "pcmcia_enable_device failed (err=%d)\n",
+ csval);
+ return 0;
+ }
+
+ ems_pcmcia_add_card(dev, dev->resource[2]->start);
+ return 0;
+}
+
+/*
+ * Release claimed resources
+ */
+static void ems_pcmcia_remove(struct pcmcia_device *dev)
+{
+ ems_pcmcia_del_card(dev);
+ pcmcia_disable_device(dev);
+}
+
+static struct pcmcia_driver ems_pcmcia_driver = {
+ .name = DRV_NAME,
+ .probe = ems_pcmcia_probe,
+ .remove = ems_pcmcia_remove,
+ .id_table = ems_pcmcia_tbl,
+};
+
+static int __init ems_pcmcia_init(void)
+{
+ return pcmcia_register_driver(&ems_pcmcia_driver);
+}
+module_init(ems_pcmcia_init);
+
+static void __exit ems_pcmcia_exit(void)
+{
+ pcmcia_unregister_driver(&ems_pcmcia_driver);
+}
+module_exit(ems_pcmcia_exit);
^ permalink raw reply
* Re: [net-next 1/8] pci: Add flag indicating device has been assigned by KVM
From: Konrad Rzeszutek Wilk @ 2011-09-23 16:43 UTC (permalink / raw)
To: Jeff Kirsher
Cc: Rose, Gregory V, Ian Campbell, davem@davemloft.net, Jesse Barnes,
netdev@vger.kernel.org, gospo@redhat.com,
linux-pci@vger.kernel.org
In-Reply-To: <1316792710.2182.124.camel@jtkirshe-mobl>
On Fri, Sep 23, 2011 at 08:45:09AM -0700, Jeff Kirsher wrote:
> On Fri, 2011-09-23 at 08:11 -0700, Rose, Gregory V wrote:
> > > -----Original Message-----
> > > From: Ian Campbell [mailto:ijc@hellion.org.uk]
> > > Sent: Friday, September 23, 2011 8:04 AM
> > > To: Rose, Gregory V
> > > Cc: Kirsher, Jeffrey T; davem@davemloft.net; konrad.wilk@oracle.com; Jesse
> > > Barnes; netdev@vger.kernel.org; gospo@redhat.com; linux-
> > > pci@vger.kernel.org
> > > Subject: RE: [net-next 1/8] pci: Add flag indicating device has been
> > > assigned by KVM
> > >
> > > On Fri, 2011-09-23 at 07:41 -0700, Rose, Gregory V wrote:
> > > > > -----Original Message-----
> > > > > From: Ian Campbell [mailto:ijc@hellion.org.uk]
> > > > > Sent: Friday, September 23, 2011 12:28 AM
> > > > > To: Kirsher, Jeffrey T
> > > > > Cc: davem@davemloft.net; konrad.wilk@oracle.com; Jesse Barnes; Rose,
> > > > > Gregory V; netdev@vger.kernel.org; gospo@redhat.com; linux-
> > > > > pci@vger.kernel.org
> > > > > Subject: Re: [net-next 1/8] pci: Add flag indicating device has been
> > > > > assigned by KVM
> > > > >
> > > > > I suppose by that measure the comment could be less KVM specific:
> > > > > > + /* Provide indication device is assigned by KVM */
> > > > > > + PCI_DEV_FLAGS_ASSIGNED = (__force pci_dev_flags_t) 4,
> > > >
> > > > We can resubmit with a more generic comment, maybe this:
> > > >
> > > > /* Provide indication device is assigned by a Virtual Machine Manager */
> > >
> > > Sounds good to me.
> >
> > Dave, Jeff,
> >
> > Should I resubmit the patch or would it be more convenient to post a follow on patch that fixes up the comment? Either way is fine by me.
> >
> > - Greg
> >
>
> let's fix up the patch in my tree and add Jesse Barnes's ACK at the same
> time.
Were are the patches now? I am kind of curious to see the changes to the xen pciback.
^ permalink raw reply
* Re: [PATCH] net: change capability used by socket options IP{,V6}_TRANSPARENT
From: Casey Schaufler @ 2011-09-23 16:36 UTC (permalink / raw)
To: Maciej Żenczykowski
Cc: Maciej Żenczykowski, netdev, linux-security-module,
James Morris, Casey Schaufler
In-Reply-To: <1316734189-26668-1-git-send-email-zenczykowski@gmail.com>
On 9/22/2011 4:29 PM, Maciej Żenczykowski wrote:
> From: Maciej Żenczykowski <maze@google.com>
>
> Up till now the IP{,V6}_TRANSPARENT socket options (which actually set
> the same bit in the socket struct) have required CAP_NET_ADMIN
> privileges to set or clear the option.
>
> - we make clearing the bit not require any privileges.
> - we deprecate using CAP_NET_ADMIN for this purpose.
> - we introduce a new capability CAP_NET_TRANSPARENT,
> which is tailored to allow setting just this bit.
Under what circumstances would a process that requires the
new capability not require CAP_NET_ADMIN? Is there a real
case where a process would be expected to require only this
new capability? Adding new capability values is somewhat
perilous and the granularity you are proposing, that of
controlling a single bit, would explode the list of
capabilities into the hundreds if it were applied throughout
the kernel.
> - we allow either one of CAP_NET_TRANSPARENT or CAP_NET_RAW
> to set this bit, because raw sockets already effectively
> allow you to emulate socket transparency, and make the
> transition easier for apps not desiring to use a brand
> new capability (because of header file or glibc support)
> - we print a warning (but allow it) if you try to set
> the socket option with CAP_NET_ADMIN privs, but without
> either one of CAP_NET_TRANSPARENT or CAP_NET_RAW.
>
> The reason for introducing a new capability is that while
> transparent sockets are potentially dangerous (and can let you
> spoof your source IP on traffic), they don't normally give you
> the full 'freedom' of eavesdropping and/or spoofing that raw sockets
> give you.
>
> Signed-off-by: Maciej Żenczykowski <maze@google.com>
> Acked-by: Balazs Scheidler <bazsi@balabit.hu>
> Acked-by: David Miller <davem@redhat.com>
> ---
> include/linux/capability.h | 13 +++++++++----
> net/ipv4/ip_sockglue.c | 26 ++++++++++++++++++++++----
> net/ipv6/ipv6_sockglue.c | 29 ++++++++++++++++++++++++-----
> 3 files changed, 55 insertions(+), 13 deletions(-)
>
> diff --git a/include/linux/capability.h b/include/linux/capability.h
> index c421123..a115ed4 100644
> --- a/include/linux/capability.h
> +++ b/include/linux/capability.h
> @@ -198,7 +198,7 @@ struct cpu_vfs_cap_data {
> /* Allow modification of routing tables */
> /* Allow setting arbitrary process / process group ownership on
> sockets */
> -/* Allow binding to any address for transparent proxying */
> +/* Allow binding to any address for transparent proxying (deprecated) */
> /* Allow setting TOS (type of service) */
> /* Allow setting promiscuous mode */
> /* Allow clearing driver statistics */
> @@ -210,6 +210,7 @@ struct cpu_vfs_cap_data {
>
> /* Allow use of RAW sockets */
> /* Allow use of PACKET sockets */
> +/* Allow binding to any address for transparent proxying */
>
> #define CAP_NET_RAW 13
>
> @@ -332,7 +333,7 @@ struct cpu_vfs_cap_data {
>
> #define CAP_AUDIT_CONTROL 30
>
> -#define CAP_SETFCAP 31
> +#define CAP_SETFCAP 31
>
> /* Override MAC access.
> The base kernel enforces no MAC policy.
> @@ -357,10 +358,14 @@ struct cpu_vfs_cap_data {
>
> /* Allow triggering something that will wake the system */
>
> -#define CAP_WAKE_ALARM 35
> +#define CAP_WAKE_ALARM 35
> +
> +/* Allow binding to any address for transparent proxying */
> +
> +#define CAP_NET_TRANSPARENT 36
>
>
> -#define CAP_LAST_CAP CAP_WAKE_ALARM
> +#define CAP_LAST_CAP CAP_NET_TRANSPARENT
>
> #define cap_valid(x) ((x) >= 0 && (x) <= CAP_LAST_CAP)
>
> diff --git a/net/ipv4/ip_sockglue.c b/net/ipv4/ip_sockglue.c
> index 8905e92..44efa39 100644
> --- a/net/ipv4/ip_sockglue.c
> +++ b/net/ipv4/ip_sockglue.c
> @@ -961,12 +961,30 @@ mc_msf_out:
> break;
>
> case IP_TRANSPARENT:
> - if (!capable(CAP_NET_ADMIN)) {
> - err = -EPERM;
> - break;
> - }
> if (optlen < 1)
> goto e_inval;
> + /* Always allow clearing the transparent proxy socket option.
> + * The pre-3.2 permission for setting this was CAP_NET_ADMIN,
> + * and this is still supported - but deprecated. As of Linux
> + * 3.2 the proper permission is one of CAP_NET_TRANSPARENT
> + * (preferred, a new capability) or CAP_NET_RAW. The latter
> + * is supported to make the transition easier (and because
> + * raw sockets already effectively allow one to emulate
> + * socket transparency).
> + */
> + if (!!val && !capable(CAP_NET_TRANSPARENT)
> + && !capable(CAP_NET_RAW)) {
> + if (!capable(CAP_NET_ADMIN)) {
> + err = -EPERM;
> + break;
> + }
> + printk_once(KERN_WARNING "%s (%d): "
> + "deprecated: attempt to set socket option "
> + "IP_TRANSPARENT with CAP_NET_ADMIN but "
> + "without either one of CAP_NET_TRANSPARENT "
> + "or CAP_NET_RAW.\n",
> + current->comm, task_pid_nr(current));
> + }
> inet->transparent = !!val;
> break;
>
> diff --git a/net/ipv6/ipv6_sockglue.c b/net/ipv6/ipv6_sockglue.c
> index 2fbda5f..b8315c8 100644
> --- a/net/ipv6/ipv6_sockglue.c
> +++ b/net/ipv6/ipv6_sockglue.c
> @@ -343,13 +343,32 @@ static int do_ipv6_setsockopt(struct sock *sk, int level, int optname,
> break;
>
> case IPV6_TRANSPARENT:
> - if (!capable(CAP_NET_ADMIN)) {
> - retv = -EPERM;
> - break;
> - }
> if (optlen < sizeof(int))
> goto e_inval;
> - /* we don't have a separate transparent bit for IPV6 we use the one in the IPv4 socket */
> + /* Always allow clearing the transparent proxy socket option.
> + * The pre-3.2 permission for setting this was CAP_NET_ADMIN,
> + * and this is still supported - but deprecated. As of Linux
> + * 3.2 the proper permission is one of CAP_NET_TRANSPARENT
> + * (preferred, a new capability) or CAP_NET_RAW. The latter
> + * is supported to make the transition easier (and because
> + * raw sockets already effectively allow one to emulate
> + * socket transparency).
> + */
> + if (valbool && !capable(CAP_NET_TRANSPARENT)
> + && !capable(CAP_NET_RAW)) {
> + if (!capable(CAP_NET_ADMIN)) {
> + retv = -EPERM;
> + break;
> + }
> + printk_once(KERN_WARNING "%s (%d): "
> + "deprecated: attempt to set socket option "
> + "IPV6_TRANSPARENT with CAP_NET_ADMIN but "
> + "without either one of CAP_NET_TRANSPARENT "
> + "or CAP_NET_RAW.\n",
> + current->comm, task_pid_nr(current));
> + }
> + /* we don't have a separate transparent bit for IPV6 we use the
> + * one in the IPv4 socket */
> inet_sk(sk)->transparent = valbool;
> retv = 0;
> break;
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox