* [PATCH] bfin_mac: Restore hardware time-stamping dependency on BF518
From: Lars-Peter Clausen @ 2013-01-10 14:42 UTC (permalink / raw)
To: David S. Miller
Cc: uclinux-dist-devel-ZG0+EudsQA8dtHy/vicBwGD2FQJk+8+b,
Richard Cochran, netdev-u79uwXL29TY76Z2rM5mHXA
Commit 70ac618c07 ("ptp: fixup Kconfig for two PHC drivers.") removed all
dependencies for the blackfin hardware time-stamping Kconfig entry. Hardware
time-stamping is only available on BF518 though. Since the Kconfig entry is
'default y', just updateing your kernel source and running `make defconfig` will
result in the the following build errors:
drivers/net/ethernet/adi/bfin_mac.c:694: error: implicit declaration of function ‘bfin_read_EMAC_PTP_CTL’
drivers/net/ethernet/adi/bfin_mac.c:702: error: implicit declaration of function ‘bfin_write_EMAC_PTP_FV3’
drivers/net/ethernet/adi/bfin_mac.c:712: error: implicit declaration of function ‘bfin_write_EMAC_PTP_CTL’
drivers/net/ethernet/adi/bfin_mac.c:717: error: implicit declaration of function ‘bfin_write_EMAC_PTP_FOFF’
...
This patch adds back the dependency on BF518, and since it does not make sense
to expose this config option when the blackfin MAC driver is not enabled also
restore the dependency on BFIN_MAC.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
---
drivers/net/ethernet/adi/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/ethernet/adi/Kconfig b/drivers/net/ethernet/adi/Kconfig
index e49c0ef..a948160 100644
--- a/drivers/net/ethernet/adi/Kconfig
+++ b/drivers/net/ethernet/adi/Kconfig
@@ -61,6 +61,7 @@ config BFIN_RX_DESC_NUM
config BFIN_MAC_USE_HWSTAMP
bool "Use IEEE 1588 hwstamp"
+ depends on BFIN_MAC && BF518
select PTP_1588_CLOCK
default y
---help---
--
1.8.0
_______________________________________________
Uclinux-dist-devel mailing list
Uclinux-dist-devel@blackfin.uclinux.org
https://blackfin.uclinux.org/mailman/listinfo/uclinux-dist-devel
^ permalink raw reply related
* Re: [PATCH] tun: avoid owner checks on IFF_ATTACH_QUEUE
From: Michael S. Tsirkin @ 2013-01-10 14:41 UTC (permalink / raw)
To: Jason Wang
Cc: Stefan Hajnoczi, David S. Miller, netdev, linux-kernel,
Paul Moore
In-Reply-To: <50EECFC8.9020402@redhat.com>
On Thu, Jan 10, 2013 at 10:27:20PM +0800, Jason Wang wrote:
> On 01/10/2013 10:19 PM, Michael S. Tsirkin wrote:
> > On Thu, Jan 10, 2013 at 10:08:03PM +0800, Jason Wang wrote:
> >> On 01/10/2013 07:31 PM, Michael S. Tsirkin wrote:
> >>> At the moment, we check owner when we enable queue in tun.
> >>> This seems redundant and will break some valid uses
> >>> where fd is passed around: I think TUNSETOWNER is there
> >>> to prevent others from attaching to a persistent device not
> >>> owned by them. Here the fd is already attached,
> >>> enabling/disabling queue is more like read/write.
> >> It also change the number of queues of the tuntap, maybe we should limit
> >> this.
> > Number of active queues? Why does it matter?
> > Max number of queues is already limited by SETIFF.
>
> Yes the number of active(real) queues in the kernel net device and this
> changing may introduce other events such uevent.
How can it trigger a uevent?
> With this patch, even
> if a owner is set for tap, every user could change the number of real
> queues which I don't think is not expected. Without this patch, we can
> limit a user that just do read and write.
In the end if you want very fine tuned security policy you have to
use an LSM.
Here we are talking about the expected usage without an LSM.
There, enabling/disabling queues is just an optimization:
if an application wants to process data from a single thread
it's better off getting it through a single fd.
Having to channel threading changes through a priveledged
proxy would be very awkward.
> >
> >> Note that if management layer does not call TUNSETOWNER, the check
> >> is just a nop. So if management layer want to limit the behavior, it's
> >> its duty to do this correctly.
> > The point is that management limits tun to allow SETIFF from libvirt
> > only, then passes the fds to qemu.
>
> Yes, but looks like libvirt does not call TUNSETOWNER before passing it
> to qemu, so we're ok even without this patch. And if libvirt want to do
> this, it can just call TUNSETOWNER to the user of qemu.
No, that would allow qemu to do SETIFF which we don't want.
> >>> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
> >>>
> >>> ---
> >>>
> >>> Note: this is unrelated to Stefan's bugfix.
> >>>
> >>> diff --git a/drivers/net/tun.c b/drivers/net/tun.c
> >>> index fbd106e..78e3225 100644
> >>> --- a/drivers/net/tun.c
> >>> +++ b/drivers/net/tun.c
> >>> @@ -1789,10 +1792,8 @@ static int tun_set_queue(struct file *file, struct ifreq *ifr)
> >>> tun = tfile->detached;
> >>> if (!tun)
> >>> ret = -EINVAL;
> >>> - else if (tun_not_capable(tun))
> >>> - ret = -EPERM;
> >>> else
> >>> ret = tun_attach(tun, file);
> >>> } else if (ifr->ifr_flags & IFF_DETACH_QUEUE) {
> >>> tun = rcu_dereference_protected(tfile->tun,
> >>> lockdep_rtnl_is_held());
> > --
> > To unsubscribe from this list: send the line "unsubscribe netdev" 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
* Re: [PATCH] tun: avoid owner checks on IFF_ATTACH_QUEUE
From: Jason Wang @ 2013-01-10 14:27 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Stefan Hajnoczi, David S. Miller, netdev, linux-kernel,
Paul Moore
In-Reply-To: <20130110141939.GA30557@redhat.com>
On 01/10/2013 10:19 PM, Michael S. Tsirkin wrote:
> On Thu, Jan 10, 2013 at 10:08:03PM +0800, Jason Wang wrote:
>> On 01/10/2013 07:31 PM, Michael S. Tsirkin wrote:
>>> At the moment, we check owner when we enable queue in tun.
>>> This seems redundant and will break some valid uses
>>> where fd is passed around: I think TUNSETOWNER is there
>>> to prevent others from attaching to a persistent device not
>>> owned by them. Here the fd is already attached,
>>> enabling/disabling queue is more like read/write.
>> It also change the number of queues of the tuntap, maybe we should limit
>> this.
> Number of active queues? Why does it matter?
> Max number of queues is already limited by SETIFF.
Yes the number of active(real) queues in the kernel net device and this
changing may introduce other events such uevent. With this patch, even
if a owner is set for tap, every user could change the number of real
queues which I don't think is not expected. Without this patch, we can
limit a user that just do read and write.
>
>> Note that if management layer does not call TUNSETOWNER, the check
>> is just a nop. So if management layer want to limit the behavior, it's
>> its duty to do this correctly.
> The point is that management limits tun to allow SETIFF from libvirt
> only, then passes the fds to qemu.
Yes, but looks like libvirt does not call TUNSETOWNER before passing it
to qemu, so we're ok even without this patch. And if libvirt want to do
this, it can just call TUNSETOWNER to the user of qemu.
>>> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
>>>
>>> ---
>>>
>>> Note: this is unrelated to Stefan's bugfix.
>>>
>>> diff --git a/drivers/net/tun.c b/drivers/net/tun.c
>>> index fbd106e..78e3225 100644
>>> --- a/drivers/net/tun.c
>>> +++ b/drivers/net/tun.c
>>> @@ -1789,10 +1792,8 @@ static int tun_set_queue(struct file *file, struct ifreq *ifr)
>>> tun = tfile->detached;
>>> if (!tun)
>>> ret = -EINVAL;
>>> - else if (tun_not_capable(tun))
>>> - ret = -EPERM;
>>> else
>>> ret = tun_attach(tun, file);
>>> } else if (ifr->ifr_flags & IFF_DETACH_QUEUE) {
>>> tun = rcu_dereference_protected(tfile->tun,
>>> lockdep_rtnl_is_held());
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" 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
* Re: [PATCH] tun: avoid owner checks on IFF_ATTACH_QUEUE
From: Michael S. Tsirkin @ 2013-01-10 14:19 UTC (permalink / raw)
To: Jason Wang
Cc: Stefan Hajnoczi, David S. Miller, netdev, linux-kernel,
Paul Moore
In-Reply-To: <50EECB43.8020405@redhat.com>
On Thu, Jan 10, 2013 at 10:08:03PM +0800, Jason Wang wrote:
> On 01/10/2013 07:31 PM, Michael S. Tsirkin wrote:
> > At the moment, we check owner when we enable queue in tun.
> > This seems redundant and will break some valid uses
> > where fd is passed around: I think TUNSETOWNER is there
> > to prevent others from attaching to a persistent device not
> > owned by them. Here the fd is already attached,
> > enabling/disabling queue is more like read/write.
>
> It also change the number of queues of the tuntap, maybe we should limit
> this.
Number of active queues? Why does it matter?
Max number of queues is already limited by SETIFF.
> Note that if management layer does not call TUNSETOWNER, the check
> is just a nop. So if management layer want to limit the behavior, it's
> its duty to do this correctly.
The point is that management limits tun to allow SETIFF from libvirt
only, then passes the fds to qemu.
> > Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
> >
> > ---
> >
> > Note: this is unrelated to Stefan's bugfix.
> >
> > diff --git a/drivers/net/tun.c b/drivers/net/tun.c
> > index fbd106e..78e3225 100644
> > --- a/drivers/net/tun.c
> > +++ b/drivers/net/tun.c
> > @@ -1789,10 +1792,8 @@ static int tun_set_queue(struct file *file, struct ifreq *ifr)
> > tun = tfile->detached;
> > if (!tun)
> > ret = -EINVAL;
> > - else if (tun_not_capable(tun))
> > - ret = -EPERM;
> > else
> > ret = tun_attach(tun, file);
> > } else if (ifr->ifr_flags & IFF_DETACH_QUEUE) {
> > tun = rcu_dereference_protected(tfile->tun,
> > lockdep_rtnl_is_held());
>
^ permalink raw reply
* Re: [PATCH] CDC_NCM adding support IFF_NOARP for buggy device
From: Oliver Neukum @ 2013-01-10 14:10 UTC (permalink / raw)
To: Wei Shuai; +Cc: gregkh, alexey.orishko, hans.petter.selasky, linux-usb, netdev
In-Reply-To: <1357826368-30543-1-git-send-email-cpuwolf@gmail.com>
On Thursday 10 January 2013 21:59:28 Wei Shuai wrote:
Hi,
I am afraid this is done in an unclean manner.
> diff --git a/drivers/net/usb/cdc_ncm.c b/drivers/net/usb/cdc_ncm.c
> index 71b6e92..9903f79 100644
> --- a/drivers/net/usb/cdc_ncm.c
> +++ b/drivers/net/usb/cdc_ncm.c
> @@ -545,6 +545,7 @@ EXPORT_SYMBOL_GPL(cdc_ncm_unbind);
> static int cdc_ncm_bind(struct usbnet *dev, struct usb_interface *intf)
> {
> int ret;
> + struct usb_device *udev = interface_to_usbdev(intf);
>
> /* The MBIM spec defines a NCM compatible default altsetting,
> * which we may have matched:
> @@ -572,6 +573,10 @@ static int cdc_ncm_bind(struct usbnet *dev, struct usb_interface *intf)
> cdc_ncm_comm_intf_is_mbim(intf->cur_altsetting))
> return -ENODEV;
> #endif
> + /* this buggy device cannot do ARP */
> + if( (le16_to_cpu(udev->descriptor.idVendor) == 0xAAAA) ) {
> + dev->net->flags |= IFF_NOARP;
So either you do a check here ...
> + }
>
> /* NCM data altsetting is always 1 */
> ret = cdc_ncm_bind_common(dev, intf, 1);
> @@ -1186,6 +1191,16 @@ static const struct usb_device_id cdc_devs[] = {
> .driver_info = (unsigned long) &wwan_info,
> },
>
> + /* buggy device cannot send ARP */
> + { .match_flags = USB_DEVICE_ID_MATCH_INT_INFO
> + | USB_DEVICE_ID_MATCH_VENDOR,
> + .idVendor = 0xAAAA,
> + .bInterfaceClass = USB_CLASS_COMM,
> + .bInterfaceSubClass = USB_CDC_SUBCLASS_NCM,
> + .bInterfaceProtocol = USB_CDC_PROTO_NONE,
> + .driver_info = (unsigned long) &wwan_info,
... or you define a matching id here and give it a flag in driver_info
But not both.
Regards
Oliver
^ permalink raw reply
* Re: [PATCH] tun: avoid owner checks on IFF_ATTACH_QUEUE
From: Jason Wang @ 2013-01-10 14:08 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Stefan Hajnoczi, David S. Miller, netdev, linux-kernel,
Paul Moore
In-Reply-To: <20130110113108.GF13451@redhat.com>
On 01/10/2013 07:31 PM, Michael S. Tsirkin wrote:
> At the moment, we check owner when we enable queue in tun.
> This seems redundant and will break some valid uses
> where fd is passed around: I think TUNSETOWNER is there
> to prevent others from attaching to a persistent device not
> owned by them. Here the fd is already attached,
> enabling/disabling queue is more like read/write.
It also change the number of queues of the tuntap, maybe we should limit
this. Note that if management layer does not call TUNSETOWNER, the check
is just a nop. So if management layer want to limit the behavior, it's
its duty to do this correctly.
> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
>
> ---
>
> Note: this is unrelated to Stefan's bugfix.
>
> diff --git a/drivers/net/tun.c b/drivers/net/tun.c
> index fbd106e..78e3225 100644
> --- a/drivers/net/tun.c
> +++ b/drivers/net/tun.c
> @@ -1789,10 +1792,8 @@ static int tun_set_queue(struct file *file, struct ifreq *ifr)
> tun = tfile->detached;
> if (!tun)
> ret = -EINVAL;
> - else if (tun_not_capable(tun))
> - ret = -EPERM;
> else
> ret = tun_attach(tun, file);
> } else if (ifr->ifr_flags & IFF_DETACH_QUEUE) {
> tun = rcu_dereference_protected(tfile->tun,
> lockdep_rtnl_is_held());
^ permalink raw reply
* [PATCH] CDC_NCM adding support IFF_NOARP for buggy device
From: Wei Shuai @ 2013-01-10 13:59 UTC (permalink / raw)
To: gregkh, alexey.orishko, hans.petter.selasky; +Cc: linux-usb, netdev, Wei Shuai
Signed-off-by: Wei Shuai <cpuwolf@gmail.com>
---
drivers/net/usb/cdc_ncm.c | 15 +++++++++++++++
1 files changed, 15 insertions(+), 0 deletions(-)
diff --git a/drivers/net/usb/cdc_ncm.c b/drivers/net/usb/cdc_ncm.c
index 71b6e92..9903f79 100644
--- a/drivers/net/usb/cdc_ncm.c
+++ b/drivers/net/usb/cdc_ncm.c
@@ -545,6 +545,7 @@ EXPORT_SYMBOL_GPL(cdc_ncm_unbind);
static int cdc_ncm_bind(struct usbnet *dev, struct usb_interface *intf)
{
int ret;
+ struct usb_device *udev = interface_to_usbdev(intf);
/* The MBIM spec defines a NCM compatible default altsetting,
* which we may have matched:
@@ -572,6 +573,10 @@ static int cdc_ncm_bind(struct usbnet *dev, struct usb_interface *intf)
cdc_ncm_comm_intf_is_mbim(intf->cur_altsetting))
return -ENODEV;
#endif
+ /* this buggy device cannot do ARP */
+ if( (le16_to_cpu(udev->descriptor.idVendor) == 0xAAAA) ) {
+ dev->net->flags |= IFF_NOARP;
+ }
/* NCM data altsetting is always 1 */
ret = cdc_ncm_bind_common(dev, intf, 1);
@@ -1186,6 +1191,16 @@ static const struct usb_device_id cdc_devs[] = {
.driver_info = (unsigned long) &wwan_info,
},
+ /* buggy device cannot send ARP */
+ { .match_flags = USB_DEVICE_ID_MATCH_INT_INFO
+ | USB_DEVICE_ID_MATCH_VENDOR,
+ .idVendor = 0xAAAA,
+ .bInterfaceClass = USB_CLASS_COMM,
+ .bInterfaceSubClass = USB_CDC_SUBCLASS_NCM,
+ .bInterfaceProtocol = USB_CDC_PROTO_NONE,
+ .driver_info = (unsigned long) &wwan_info,
+ },
+
/* Huawei NCM devices disguised as vendor specific */
{ USB_VENDOR_AND_INTERFACE_INFO(0x12d1, 0xff, 0x02, 0x16),
.driver_info = (unsigned long)&wwan_info,
--
1.7.6.5
^ permalink raw reply related
* Re: [PATCH 3.8-rc] tuntap: refuse to re-attach to different tun_struct
From: Jason Wang @ 2013-01-10 13:53 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: Stefan Hajnoczi, David S. Miller, netdev, linux-kernel
In-Reply-To: <20130110110737.GD13451@redhat.com>
On 01/10/2013 07:07 PM, Michael S. Tsirkin wrote:
> On Thu, Jan 10, 2013 at 06:43:20PM +0800, Jason Wang wrote:
>> On 01/10/2013 06:23 PM, Michael S. Tsirkin wrote:
>>> On Thu, Jan 10, 2013 at 08:59:48AM +0100, Stefan Hajnoczi wrote:
>>>> Multiqueue tun devices support detaching a tun_file from its tun_struct
>>>> and re-attaching at a later point in time. This allows users to disable
>>>> a specific queue temporarily.
>>>>
>>>> ioctl(TUNSETIFF) allows the user to specify the network interface to
>>>> attach by name. This means the user can attempt to attach to interface
>>>> "B" after detaching from interface "A".
>>>>
>>>> The driver is not designed to support this so check we are re-attaching
>>>> to the right tun_struct. Failure to do so may lead to oops.
>>>>
>>>> Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
>>>> ---
>>>> This fix is for 3.8-rc.
>>>>
>>>> drivers/net/tun.c | 2 ++
>>>> 1 file changed, 2 insertions(+)
>>>>
>>>> diff --git a/drivers/net/tun.c b/drivers/net/tun.c
>>>> index fbd106e..cf6da6e 100644
>>>> --- a/drivers/net/tun.c
>>>> +++ b/drivers/net/tun.c
>>>> @@ -491,6 +491,8 @@ static int tun_attach(struct tun_struct *tun, struct file *file)
>>>> err = -EINVAL;
>>>> if (rcu_dereference_protected(tfile->tun, lockdep_rtnl_is_held()))
>>>> goto out;
>>>> + if (tfile->detached && tun != tfile->detached)
>>>> + goto out;
>>>>
>>>> err = -EBUSY;
>>>> if (!(tun->flags & TUN_TAP_MQ) && tun->numqueues == 1)
>>>> --
>>>> 1.8.0.2
>>> I agree this is a bug but even with this patch, we still allow:
>>>
>>> SETIFF
>>> SETQUEUE (DISABLED)
>>> SETIFF
>>>
>>> Originally the rule always was that repeated setiff calls fail with
>>> EINVAL. We broke that when we set tun to NULL. It's probably worth
>>> preserving that, even if queue is disabled. Applying something like the below
>>> instead will address this concern, won't it?
>>>
>>> Note: works with regular userspace but I didn't test
>>> multiqueue userspace. What do you think.
>> Or just fail when tun->detached is not NULL at the beginning of
>> tun_set_iff()?
> Yes that'll also work I think. If you prefer this pls send patch.
Will post a patch, thanks.
>>> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
>>>
>>> ---
>>>
>>> diff --git a/drivers/net/tun.c b/drivers/net/tun.c
>>> index fbd106e..5ec8b08 100644
>>> --- a/drivers/net/tun.c
>>> +++ b/drivers/net/tun.c
>>> @@ -483,7 +483,7 @@ static void tun_detach_all(struct net_device *dev)
>>> BUG_ON(tun->numdisabled != 0);
>>> }
>>>
>>> -static int tun_attach(struct tun_struct *tun, struct file *file)
>>> +static int tun_attach(struct tun_struct *tun, struct file *file, bool setiff)
>>> {
>>> struct tun_file *tfile = file->private_data;
>>> int err;
>>> @@ -492,6 +492,9 @@ static int tun_attach(struct tun_struct *tun, struct file *file)
>>> if (rcu_dereference_protected(tfile->tun, lockdep_rtnl_is_held()))
>>> goto out;
>>>
>>> + if (setiff && tfile->detached)
>>> + goto out;
>>> +
>>> err = -EBUSY;
>>> if (!(tun->flags & TUN_TAP_MQ) && tun->numqueues == 1)
>>> goto out;
>>> @@ -1561,7 +1564,7 @@ static int tun_set_iff(struct net *net, struct file *file, struct ifreq *ifr)
>>> if (err < 0)
>>> return err;
>>>
>>> - err = tun_attach(tun, file);
>>> + err = tun_attach(tun, file, true);
>>> if (err < 0)
>>> return err;
>>>
>>> @@ -1627,7 +1630,7 @@ static int tun_set_iff(struct net *net, struct file *file, struct ifreq *ifr)
>>> dev->features = dev->hw_features;
>>>
>>> INIT_LIST_HEAD(&tun->disabled);
>>> - err = tun_attach(tun, file);
>>> + err = tun_attach(tun, file, true);
>>> if (err < 0)
>>> goto err_free_dev;
>>>
>>> @@ -1792,7 +1795,7 @@ static int tun_set_queue(struct file *file, struct ifreq *ifr)
>>> else if (tun_not_capable(tun))
>>> ret = -EPERM;
>>> else
>>> - ret = tun_attach(tun, file);
>>> + ret = tun_attach(tun, file, false);
>>> } else if (ifr->ifr_flags & IFF_DETACH_QUEUE) {
>>> tun = rcu_dereference_protected(tfile->tun,
>>> lockdep_rtnl_is_held());
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>>> the body of a message to majordomo@vger.kernel.org
>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>> Please read the FAQ at http://www.tux.org/lkml/
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" 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
* Re: pull request: wireless 2013-01-09
From: Sedat Dilek @ 2013-01-10 13:43 UTC (permalink / raw)
To: John W. Linville
Cc: davem-fT/PcQaiUtIeIZ0/mPfg9Q,
linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <CA+icZUV9+JgZcYKZ4DAoj69D89hF-1cqr_bTpJvfgzWZZJ41kQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Thu, Jan 10, 2013 at 11:14 AM, Sedat Dilek <sedat.dilek-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> On Wed, Jan 9, 2013 at 8:18 PM, John W. Linville <linville-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org> wrote:
>> Dave,
>>
>> Please pull this batch of fixes (and a new driver) for the 3.8 stream...
>>
>> Included is a mac80211 pull, of which Johannes says the following:
>>
>> 'This includes a number of fixes for various pieces of mac80211. I've
>> also included Thomas's memory RMC hash table optimisation since it
>> saves so much memory.'
>>
>> Also from Johannes is an iwlwifi pull:
>>
>> 'I have two fixes for iwlwifi: one to fix a lost return value that was
>> dropped in a previous patch and could cause "nobody cared" IRQ messages,
>> and one to work around a firmware issue.'
>>
>> Amitkumar Karwar brings an mwifiex for a typo in an comparison.
>>
>> Bing Zhao gives us an mwifiex fix to properly check the return value
>> from wait_event_interruptible and handle it properly.
>>
>> Chen Gang provides a fix to make iwlegacy use strlcpy instead of
>> strncpy, avoiding a potential buffer underflow.
>>
>> Julian Wollrath fixes a typo in an error message in rtlwifi.
>>
>> Larry Finger brings a b43 fix for a firmware loading problem.
>>
>> Nickolai Zeldovich avoids a use-after-free in the mwl8k driver.
>>
>> Vladimir Kondratiev brings the last big piece, the new Qualcomm/Atheros
>> wil6210 802.11ad driver. Since it is for new hardware, I hope that
>> taking it for 3.8 is not a problem.
>>
>> Please let me know if there are problems!
>>
>> Thanks,
>>
>> John
>>
>> ---
>>
>> The following changes since commit c9be4a5c49cf51cc70a993f004c5bb30067a65ce:
>>
>> net: prevent setting ttl=0 via IP_TTL (2013-01-08 17:57:10 -0800)
>>
>> are available in the git repository at:
>>
>> git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless.git for-davem
>>
>> for you to fetch changes up to a9b8a894ad7d0b90b0464c9ac7e8e5c1687edcae:
>>
>> Merge branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless into for-davem (2013-01-09 11:01:37 -0500)
>>
>> ----------------------------------------------------------------
>
> Hi John,
>
> if I look at for-davem GIT branch (online GitWeb interface) [1], this
> has no tag "master-2013-01-09" like in master branch.
> Comments?
>
Sorry, forget this, I looked at wireless-next.git#for-davem.
- Sedat -
> Regards,
> - Sedat -
>
> [1] http://git.kernel.org/?p=linux/kernel/git/linville/wireless-next.git;a=shortlog;h=refs/heads/for-davem
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 1/2] Fix phy_init for Marvell network eth driver
From: Sergei Shtylyov @ 2013-01-10 13:22 UTC (permalink / raw)
To: Kosta Zertsekel
Cc: netdev, alior, andrew, benavi, zertsekel, linux-arm-kernel
In-Reply-To: <1357819234-27752-2-git-send-email-konszert@marvell.com>
Hello.
On 10-01-2013 16:00, Kosta Zertsekel wrote:
> At least it fixes DNS323_REV_C1 board case (mach-orion5x/dsn323-setup.c file).
> Change-Id: I37d64795f79c358f66a211a150cec2263e40e295
This line has no place in the upstream commit, please remove it. Also, the
patch misses your signoff, so couldn't be applied anyway. Same about the next
patch.
WBR, Sergei
^ permalink raw reply
* RE: Fix phy_init for Marvell network eth driver
From: Kosta Zertsekel @ 2013-01-10 12:27 UTC (permalink / raw)
To: Andrew Lunn
Cc: Lior Amsalem, netdev@vger.kernel.org, Eran Ben-Avi,
linux-arm-kernel@lists.infradead.org, zertsekel@gmail.com
In-Reply-To: <20130110122441.GQ3392@lunn.ch>
> This comment is supposed to be in the header of the patch.
> Since this comment is about a bug for the D-Link DNS323_REV_C1, the fix to DSA should be in a separate patch, again with a comment about the patch, why its needed, what if fixes etc.
> I suggest you take a look at Documentation/SubmittingPatches
Oh, I know. I am really sorry for the mess with 'git sendemail' (forgot --compose flag or something).
I'll resend the patch "locally" with patch header email and then repost the both patches again on netdev and linux-arm-kernel.
Sorry again.
Thanks,
--- KostaZ
^ permalink raw reply
* Re: Fix phy_init for Marvell network eth driver
From: Andrew Lunn @ 2013-01-10 12:24 UTC (permalink / raw)
To: Kosta Zertsekel
Cc: netdev, zertsekel, andrew, benavi, linux-arm-kernel, alior
In-Reply-To: <1357819234-27752-1-git-send-email-konszert@marvell.com>
On Thu, Jan 10, 2013 at 02:00:32PM +0200, Kosta Zertsekel wrote:
> Hi all,
> resubmitting the patch for Marvell mv643xx driver (patch 1/2) adding the below explanation (thanks to Florian F.):
> The D-Link DNS323_REV_C1 board has a specific PHY device fixup using the flag MARVELL_PHY_M1118_DNS323_LEDS which is set by the architecture code in arch/arm/mach-orion5x/dns323-setup.c. This flag is unfortunately lost during the call to phy_attach() in mv643xx_eth and therefore, the underlying Marvell PHY driver cannot make use of this flag to fixup the PHY device LEDs. This patch ensures the phy->dev_flags value is passed to the phy_attach() function such that the PHY device driver can
> actually use it.
>
> Also submitting new patch 2/2 using the same (or at least very close in meaning) explanation.
>
Hi Kosta
This comment is supposed to be in the header of the patch.
Since this comment is about a bug for the D-Link DNS323_REV_C1, the
fix to DSA should be in a separate patch, again with a comment about
the patch, why its needed, what if fixes etc.
I suggest you take a look at Documentation/SubmittingPatches
Thanks
Andrew
^ permalink raw reply
* Re: Fix phy_init for Marvell network eth driver
From: Jason Cooper @ 2013-01-10 12:17 UTC (permalink / raw)
To: Kosta Zertsekel
Cc: alior, andrew, netdev, benavi, zertsekel, linux-arm-kernel
In-Reply-To: <1357819234-27752-1-git-send-email-konszert@marvell.com>
On Thu, Jan 10, 2013 at 02:00:32PM +0200, Kosta Zertsekel wrote:
> Hi all,
> resubmitting the patch for Marvell mv643xx driver (patch 1/2) adding the below explanation (thanks to Florian F.):
> The D-Link DNS323_REV_C1 board has a specific PHY device fixup using the flag MARVELL_PHY_M1118_DNS323_LEDS which is set by the architecture code in arch/arm/mach-orion5x/dns323-setup.c. This flag is unfortunately lost during the call to phy_attach() in mv643xx_eth and therefore, the underlying Marvell PHY driver cannot make use of this flag to fixup the PHY device LEDs. This patch ensures the phy->dev_flags value is passed to the phy_attach() function such that the PHY device driver can
> actually use it.
>
> Also submitting new patch 2/2 using the same (or at least very close in meaning) explanation.
Could you please put the above description in the patch commit log for
both patches? Other than that,
Acked-by: Jason Cooper <jason@lakedaemon.net>
thx,
Jason.
^ permalink raw reply
* [PATCH 2/2] Fix phy_attach - forward dev_flags for phy_attach
From: Kosta Zertsekel @ 2013-01-10 12:00 UTC (permalink / raw)
To: netdev; +Cc: zertsekel, andrew, benavi, linux-arm-kernel, alior,
Kosta Zertsekel
In-Reply-To: <1357819234-27752-1-git-send-email-konszert@marvell.com>
Change-Id: Ie3191f95c36eada6d0c673460de5393641128182
---
drivers/net/ethernet/marvell/pxa168_eth.c | 2 +-
net/dsa/slave.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/marvell/pxa168_eth.c b/drivers/net/ethernet/marvell/pxa168_eth.c
index 10d678d..63baa3b 100644
--- a/drivers/net/ethernet/marvell/pxa168_eth.c
+++ b/drivers/net/ethernet/marvell/pxa168_eth.c
@@ -1391,7 +1391,7 @@ static void phy_init(struct pxa168_eth_private *pep, int speed, int duplex)
struct phy_device *phy = pep->phy;
ethernet_phy_reset(pep);
- phy_attach(pep->dev, dev_name(&phy->dev), 0, PHY_INTERFACE_MODE_MII);
+ phy_attach(pep->dev, dev_name(&phy->dev), phy->dev_flags, PHY_INTERFACE_MODE_MII);
if (speed == 0) {
phy->autoneg = AUTONEG_ENABLE;
diff --git a/net/dsa/slave.c b/net/dsa/slave.c
index e32083d..bf09902 100644
--- a/net/dsa/slave.c
+++ b/net/dsa/slave.c
@@ -391,7 +391,7 @@ dsa_slave_create(struct dsa_switch *ds, struct device *parent,
if (p->phy != NULL) {
phy_attach(slave_dev, dev_name(&p->phy->dev),
- 0, PHY_INTERFACE_MODE_GMII);
+ phy->dev_flags, PHY_INTERFACE_MODE_GMII);
p->phy->autoneg = AUTONEG_ENABLE;
p->phy->speed = 0;
--
1.8.1
^ permalink raw reply related
* [PATCH 1/2] Fix phy_init for Marvell network eth driver
From: Kosta Zertsekel @ 2013-01-10 12:00 UTC (permalink / raw)
To: netdev; +Cc: zertsekel, andrew, benavi, linux-arm-kernel, alior,
Kosta Zertsekel
In-Reply-To: <1357819234-27752-1-git-send-email-konszert@marvell.com>
At least it fixes DNS323_REV_C1 board case (mach-orion5x/dsn323-setup.c file).
Change-Id: I37d64795f79c358f66a211a150cec2263e40e295
---
drivers/net/ethernet/marvell/mv643xx_eth.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/marvell/mv643xx_eth.c b/drivers/net/ethernet/marvell/mv643xx_eth.c
index 84c1326..7b8c1ac 100644
--- a/drivers/net/ethernet/marvell/mv643xx_eth.c
+++ b/drivers/net/ethernet/marvell/mv643xx_eth.c
@@ -2789,7 +2789,7 @@ static void phy_init(struct mv643xx_eth_private *mp, int speed, int duplex)
phy_reset(mp);
- phy_attach(mp->dev, dev_name(&phy->dev), 0, PHY_INTERFACE_MODE_GMII);
+ phy_attach(mp->dev, dev_name(&phy->dev), phy->dev_flags, PHY_INTERFACE_MODE_GMII);
if (speed == 0) {
phy->autoneg = AUTONEG_ENABLE;
--
1.8.1
^ permalink raw reply related
* Fix phy_init for Marvell network eth driver
From: Kosta Zertsekel @ 2013-01-10 12:00 UTC (permalink / raw)
To: netdev; +Cc: zertsekel, andrew, benavi, linux-arm-kernel, alior
Hi all,
resubmitting the patch for Marvell mv643xx driver (patch 1/2) adding the below explanation (thanks to Florian F.):
The D-Link DNS323_REV_C1 board has a specific PHY device fixup using the flag MARVELL_PHY_M1118_DNS323_LEDS which is set by the architecture code in arch/arm/mach-orion5x/dns323-setup.c. This flag is unfortunately lost during the call to phy_attach() in mv643xx_eth and therefore, the underlying Marvell PHY driver cannot make use of this flag to fixup the PHY device LEDs. This patch ensures the phy->dev_flags value is passed to the phy_attach() function such that the PHY device driver can
actually use it.
Also submitting new patch 2/2 using the same (or at least very close in meaning) explanation.
^ permalink raw reply
* Re: [PATCH] tun: avoid owner checks on IFF_ATTACH_QUEUE
From: Stefan Hajnoczi @ 2013-01-10 11:55 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: Jason Wang, David S. Miller, netdev, linux-kernel
In-Reply-To: <20130110113108.GF13451@redhat.com>
On Thu, Jan 10, 2013 at 01:31:08PM +0200, Michael S. Tsirkin wrote:
> At the moment, we check owner when we enable queue in tun.
> This seems redundant and will break some valid uses
> where fd is passed around: I think TUNSETOWNER is there
> to prevent others from attaching to a persistent device not
> owned by them. Here the fd is already attached,
> enabling/disabling queue is more like read/write.
>
> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
>
> ---
>
> Note: this is unrelated to Stefan's bugfix.
This should go into 3.8-rc.
Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
^ permalink raw reply
* Re: [PATCH 3.8-rc] tuntap: refuse to re-attach to different tun_struct
From: Stefan Hajnoczi @ 2013-01-10 11:53 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: David S. Miller, Jason Wang, netdev, linux-kernel
In-Reply-To: <20130110102319.GB13451@redhat.com>
On Thu, Jan 10, 2013 at 12:23:19PM +0200, Michael S. Tsirkin wrote:
> On Thu, Jan 10, 2013 at 08:59:48AM +0100, Stefan Hajnoczi wrote:
> > Multiqueue tun devices support detaching a tun_file from its tun_struct
> > and re-attaching at a later point in time. This allows users to disable
> > a specific queue temporarily.
> >
> > ioctl(TUNSETIFF) allows the user to specify the network interface to
> > attach by name. This means the user can attempt to attach to interface
> > "B" after detaching from interface "A".
> >
> > The driver is not designed to support this so check we are re-attaching
> > to the right tun_struct. Failure to do so may lead to oops.
> >
> > Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
> > ---
> > This fix is for 3.8-rc.
> >
> > drivers/net/tun.c | 2 ++
> > 1 file changed, 2 insertions(+)
> >
> > diff --git a/drivers/net/tun.c b/drivers/net/tun.c
> > index fbd106e..cf6da6e 100644
> > --- a/drivers/net/tun.c
> > +++ b/drivers/net/tun.c
> > @@ -491,6 +491,8 @@ static int tun_attach(struct tun_struct *tun, struct file *file)
> > err = -EINVAL;
> > if (rcu_dereference_protected(tfile->tun, lockdep_rtnl_is_held()))
> > goto out;
> > + if (tfile->detached && tun != tfile->detached)
> > + goto out;
> >
> > err = -EBUSY;
> > if (!(tun->flags & TUN_TAP_MQ) && tun->numqueues == 1)
> > --
> > 1.8.0.2
>
>
> I agree this is a bug but even with this patch, we still allow:
>
> SETIFF
> SETQUEUE (DISABLED)
> SETIFF
>
> Originally the rule always was that repeated setiff calls fail with
> EINVAL. We broke that when we set tun to NULL. It's probably worth
> preserving that, even if queue is disabled. Applying something like the below
> instead will address this concern, won't it?
Sounds good.
Stefan
^ permalink raw reply
* Re: [PATCH v2] net: set default_ethtool_ops in register_netdevice
From: Johannes Berg @ 2013-01-10 11:41 UTC (permalink / raw)
To: David Miller
Cc: sgruszka-H+wXaHxf7aLQT0dZR+AlfA, netdev-u79uwXL29TY76Z2rM5mHXA,
edumazet-hpIqsD4AKlfQT0dZR+AlfA, greearb-my8/4N5VtI7c+919tysfdA,
bjorn-yOkvZcmFvRU, linux-wireless-u79uwXL29TY76Z2rM5mHXA,
bhutchings-s/n/eUQHGBpZroRs9YW3xA, mirqus-Re5JQEeQqe8AvxtiuMwx3w
In-Reply-To: <20130110.021202.232771737304117743.davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
On Thu, 2013-01-10 at 02:12 -0800, David Miller wrote:
> >> On Wed, Jan 09, 2013 at 11:57:38PM -0800, David Miller wrote:
> >>> From: Stanislaw Gruszka <sgruszka-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
> >>> Date: Tue, 8 Jan 2013 16:38:51 +0100
> >>>
> >>> > Since:
> >>> >
> >>> > commit 2c60db037034d27f8c636403355d52872da92f81
> >>> > Author: Eric Dumazet <edumazet-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
> >>> > Date: Sun Sep 16 09:17:26 2012 +0000
> >>> >
> >>> > net: provide a default dev->ethtool_ops
> >>> >
> >>> > wireless core does not correctly assign ethtool_ops. In order to fix
> >>> > the problem, move assignement of default_ethtool_ops to
> >>> > register_netdevice(). This is safe because both register_netdevice()
> >>> > and dev_ethtool() are protected by RTNL lock.
> >>> >
> >>> > Patch is besed on hint of Michał Mirosław.
> >>> >
> >>> > Signed-off-by: Stanislaw Gruszka <sgruszka-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
> >>> > Cc: stable-u79uwXL29TY76Z2rM5mHXA@public.gmane.org # 3.7+
> >>> > ---
> >>> > v1 -> v2: change order of default_ethtool_ops initialization to avoid
> >>> > the problem. Change the subject accordingly.
> >>>
> >>> I don't understand this. Why is the assignment of default_ethtool_ops
> >>> at netdev allocation time not working? Is wireless really not using
> >>> alloc_netdev*()?
> >>
> >> It does. This is done on individual cfg80211 drivers , i.e. on mac80211
> >> or full mac drivers. After alloc_netdev*() call, some cfg80211 drivers
> >> provide they own ethtool_ops, but some do not. For them, wireless core
> >> provide generic cfg80211_ethtool_ops, which is assigned in
> >> NETDEV_REGISTER notify call:
> >>
> >> if (!dev->ethtool_ops)
> >> dev->ethtool_ops = &cfg80211_ethtool_ops;
> >>
> >> But after Eric's commit, dev->ethtool_ops is no longer NULL (on cfg80211
> >> drivers without custom ethtool_ops), but points to &default_ethtool_ops.
> >
> > The whole idea is to remove these kinds of NULL tests against
> > dev->ethtool_ops, thus creating the invariant that given any netdev
> > one must never be able to see a non-NULL value there.
>
> Of course I meant that we should never see a NULL value in
> dev->ethtool_ops.
>
> I would suggest fixing this by making the wireless core express it's
> intentions, that it wants to use a different default ethtool ops, to
> the netdev allocation layer.
>
> You have two way to do this:
>
> 1) Add default_ethtool_ops argument to alloc_netdev*().
>
> 2) Add a "netdev_set_default_ethtool_ops(netdev, ops)"
Neither of these work as (I think) you think they would :-)
The core wireless code doesn't allocate/register the netdev itself, the
driver does. It has to follow some constraints, but the wireless core
then hooks into the netdev notifier chain to be informed. While in the
notifier chain, it attempts to set ethtool ops, but they've long been
set already to the defaults. So that means the second way you suggested
won't work at that point any more, short of having the wireless core
code export its ethtool ops and drivers setting them.
Now arguably the wireless core code could provide its own
alloc_netdev*() wrappers, but is that really worth it? There are a lot
of possibilities there that we'd have to wrap.
johannes
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH] tun: avoid owner checks on IFF_ATTACH_QUEUE
From: Michael S. Tsirkin @ 2013-01-10 11:31 UTC (permalink / raw)
To: Jason Wang; +Cc: Stefan Hajnoczi, David S. Miller, netdev, linux-kernel
At the moment, we check owner when we enable queue in tun.
This seems redundant and will break some valid uses
where fd is passed around: I think TUNSETOWNER is there
to prevent others from attaching to a persistent device not
owned by them. Here the fd is already attached,
enabling/disabling queue is more like read/write.
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
---
Note: this is unrelated to Stefan's bugfix.
diff --git a/drivers/net/tun.c b/drivers/net/tun.c
index fbd106e..78e3225 100644
--- a/drivers/net/tun.c
+++ b/drivers/net/tun.c
@@ -1789,10 +1792,8 @@ static int tun_set_queue(struct file *file, struct ifreq *ifr)
tun = tfile->detached;
if (!tun)
ret = -EINVAL;
- else if (tun_not_capable(tun))
- ret = -EPERM;
else
ret = tun_attach(tun, file);
} else if (ifr->ifr_flags & IFF_DETACH_QUEUE) {
tun = rcu_dereference_protected(tfile->tun,
lockdep_rtnl_is_held());
--
MST
^ permalink raw reply related
* Re: [PATCH 3.8-rc] tuntap: refuse to re-attach to different tun_struct
From: Michael S. Tsirkin @ 2013-01-10 11:07 UTC (permalink / raw)
To: Jason Wang; +Cc: Stefan Hajnoczi, David S. Miller, netdev, linux-kernel
In-Reply-To: <50EE9B48.6080306@redhat.com>
On Thu, Jan 10, 2013 at 06:43:20PM +0800, Jason Wang wrote:
> On 01/10/2013 06:23 PM, Michael S. Tsirkin wrote:
> > On Thu, Jan 10, 2013 at 08:59:48AM +0100, Stefan Hajnoczi wrote:
> >> Multiqueue tun devices support detaching a tun_file from its tun_struct
> >> and re-attaching at a later point in time. This allows users to disable
> >> a specific queue temporarily.
> >>
> >> ioctl(TUNSETIFF) allows the user to specify the network interface to
> >> attach by name. This means the user can attempt to attach to interface
> >> "B" after detaching from interface "A".
> >>
> >> The driver is not designed to support this so check we are re-attaching
> >> to the right tun_struct. Failure to do so may lead to oops.
> >>
> >> Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
> >> ---
> >> This fix is for 3.8-rc.
> >>
> >> drivers/net/tun.c | 2 ++
> >> 1 file changed, 2 insertions(+)
> >>
> >> diff --git a/drivers/net/tun.c b/drivers/net/tun.c
> >> index fbd106e..cf6da6e 100644
> >> --- a/drivers/net/tun.c
> >> +++ b/drivers/net/tun.c
> >> @@ -491,6 +491,8 @@ static int tun_attach(struct tun_struct *tun, struct file *file)
> >> err = -EINVAL;
> >> if (rcu_dereference_protected(tfile->tun, lockdep_rtnl_is_held()))
> >> goto out;
> >> + if (tfile->detached && tun != tfile->detached)
> >> + goto out;
> >>
> >> err = -EBUSY;
> >> if (!(tun->flags & TUN_TAP_MQ) && tun->numqueues == 1)
> >> --
> >> 1.8.0.2
> >
> > I agree this is a bug but even with this patch, we still allow:
> >
> > SETIFF
> > SETQUEUE (DISABLED)
> > SETIFF
> >
> > Originally the rule always was that repeated setiff calls fail with
> > EINVAL. We broke that when we set tun to NULL. It's probably worth
> > preserving that, even if queue is disabled. Applying something like the below
> > instead will address this concern, won't it?
> >
> > Note: works with regular userspace but I didn't test
> > multiqueue userspace. What do you think.
>
> Or just fail when tun->detached is not NULL at the beginning of
> tun_set_iff()?
Yes that'll also work I think. If you prefer this pls send patch.
> > Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
> >
> > ---
> >
> > diff --git a/drivers/net/tun.c b/drivers/net/tun.c
> > index fbd106e..5ec8b08 100644
> > --- a/drivers/net/tun.c
> > +++ b/drivers/net/tun.c
> > @@ -483,7 +483,7 @@ static void tun_detach_all(struct net_device *dev)
> > BUG_ON(tun->numdisabled != 0);
> > }
> >
> > -static int tun_attach(struct tun_struct *tun, struct file *file)
> > +static int tun_attach(struct tun_struct *tun, struct file *file, bool setiff)
> > {
> > struct tun_file *tfile = file->private_data;
> > int err;
> > @@ -492,6 +492,9 @@ static int tun_attach(struct tun_struct *tun, struct file *file)
> > if (rcu_dereference_protected(tfile->tun, lockdep_rtnl_is_held()))
> > goto out;
> >
> > + if (setiff && tfile->detached)
> > + goto out;
> > +
> > err = -EBUSY;
> > if (!(tun->flags & TUN_TAP_MQ) && tun->numqueues == 1)
> > goto out;
> > @@ -1561,7 +1564,7 @@ static int tun_set_iff(struct net *net, struct file *file, struct ifreq *ifr)
> > if (err < 0)
> > return err;
> >
> > - err = tun_attach(tun, file);
> > + err = tun_attach(tun, file, true);
> > if (err < 0)
> > return err;
> >
> > @@ -1627,7 +1630,7 @@ static int tun_set_iff(struct net *net, struct file *file, struct ifreq *ifr)
> > dev->features = dev->hw_features;
> >
> > INIT_LIST_HEAD(&tun->disabled);
> > - err = tun_attach(tun, file);
> > + err = tun_attach(tun, file, true);
> > if (err < 0)
> > goto err_free_dev;
> >
> > @@ -1792,7 +1795,7 @@ static int tun_set_queue(struct file *file, struct ifreq *ifr)
> > else if (tun_not_capable(tun))
> > ret = -EPERM;
> > else
> > - ret = tun_attach(tun, file);
> > + ret = tun_attach(tun, file, false);
> > } else if (ifr->ifr_flags & IFF_DETACH_QUEUE) {
> > tun = rcu_dereference_protected(tfile->tun,
> > lockdep_rtnl_is_held());
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
> > Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply
* Re: [PATCH 3.8-rc] tuntap: refuse to re-attach to different tun_struct
From: Jason Wang @ 2013-01-10 10:43 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: Stefan Hajnoczi, David S. Miller, netdev, linux-kernel
In-Reply-To: <20130110102319.GB13451@redhat.com>
On 01/10/2013 06:23 PM, Michael S. Tsirkin wrote:
> On Thu, Jan 10, 2013 at 08:59:48AM +0100, Stefan Hajnoczi wrote:
>> Multiqueue tun devices support detaching a tun_file from its tun_struct
>> and re-attaching at a later point in time. This allows users to disable
>> a specific queue temporarily.
>>
>> ioctl(TUNSETIFF) allows the user to specify the network interface to
>> attach by name. This means the user can attempt to attach to interface
>> "B" after detaching from interface "A".
>>
>> The driver is not designed to support this so check we are re-attaching
>> to the right tun_struct. Failure to do so may lead to oops.
>>
>> Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
>> ---
>> This fix is for 3.8-rc.
>>
>> drivers/net/tun.c | 2 ++
>> 1 file changed, 2 insertions(+)
>>
>> diff --git a/drivers/net/tun.c b/drivers/net/tun.c
>> index fbd106e..cf6da6e 100644
>> --- a/drivers/net/tun.c
>> +++ b/drivers/net/tun.c
>> @@ -491,6 +491,8 @@ static int tun_attach(struct tun_struct *tun, struct file *file)
>> err = -EINVAL;
>> if (rcu_dereference_protected(tfile->tun, lockdep_rtnl_is_held()))
>> goto out;
>> + if (tfile->detached && tun != tfile->detached)
>> + goto out;
>>
>> err = -EBUSY;
>> if (!(tun->flags & TUN_TAP_MQ) && tun->numqueues == 1)
>> --
>> 1.8.0.2
>
> I agree this is a bug but even with this patch, we still allow:
>
> SETIFF
> SETQUEUE (DISABLED)
> SETIFF
>
> Originally the rule always was that repeated setiff calls fail with
> EINVAL. We broke that when we set tun to NULL. It's probably worth
> preserving that, even if queue is disabled. Applying something like the below
> instead will address this concern, won't it?
>
> Note: works with regular userspace but I didn't test
> multiqueue userspace. What do you think.
Or just fail when tun->detached is not NULL at the beginning of
tun_set_iff()?
> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
>
> ---
>
> diff --git a/drivers/net/tun.c b/drivers/net/tun.c
> index fbd106e..5ec8b08 100644
> --- a/drivers/net/tun.c
> +++ b/drivers/net/tun.c
> @@ -483,7 +483,7 @@ static void tun_detach_all(struct net_device *dev)
> BUG_ON(tun->numdisabled != 0);
> }
>
> -static int tun_attach(struct tun_struct *tun, struct file *file)
> +static int tun_attach(struct tun_struct *tun, struct file *file, bool setiff)
> {
> struct tun_file *tfile = file->private_data;
> int err;
> @@ -492,6 +492,9 @@ static int tun_attach(struct tun_struct *tun, struct file *file)
> if (rcu_dereference_protected(tfile->tun, lockdep_rtnl_is_held()))
> goto out;
>
> + if (setiff && tfile->detached)
> + goto out;
> +
> err = -EBUSY;
> if (!(tun->flags & TUN_TAP_MQ) && tun->numqueues == 1)
> goto out;
> @@ -1561,7 +1564,7 @@ static int tun_set_iff(struct net *net, struct file *file, struct ifreq *ifr)
> if (err < 0)
> return err;
>
> - err = tun_attach(tun, file);
> + err = tun_attach(tun, file, true);
> if (err < 0)
> return err;
>
> @@ -1627,7 +1630,7 @@ static int tun_set_iff(struct net *net, struct file *file, struct ifreq *ifr)
> dev->features = dev->hw_features;
>
> INIT_LIST_HEAD(&tun->disabled);
> - err = tun_attach(tun, file);
> + err = tun_attach(tun, file, true);
> if (err < 0)
> goto err_free_dev;
>
> @@ -1792,7 +1795,7 @@ static int tun_set_queue(struct file *file, struct ifreq *ifr)
> else if (tun_not_capable(tun))
> ret = -EPERM;
> else
> - ret = tun_attach(tun, file);
> + ret = tun_attach(tun, file, false);
> } else if (ifr->ifr_flags & IFF_DETACH_QUEUE) {
> tun = rcu_dereference_protected(tfile->tun,
> lockdep_rtnl_is_held());
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply
* Re: [PATCH] Fix phy_init for Marvell network eth driver
From: Florian Fainelli @ 2013-01-10 10:38 UTC (permalink / raw)
To: Kosta Zertsekel; +Cc: netdev, benavi, alior, linux-arm-kernel, andrew
In-Reply-To: <1357812298-26399-2-git-send-email-konszert@marvell.com>
Le 01/10/13 11:04, Kosta Zertsekel a écrit :
> At least it fixes DNS323_REV_C1 board case (mach-orion5x/dsn323-setup.c file).
This looks right, but a bit more detail would be welcome, such as:
"The D-Link DNS323_REV_C1 board has a specific PHY device fixup using
the flag MARVELL_PHY_M1118_DNS323_LEDS which is set by the architecture
code in arch/arm/mach-orion5x/dns323-setup.c. This flag is unfortunately
lost during the call to phy_attach() in mv643xx_eth and therefore, the
underlying Marvell PHY driver cannot make use of this flag to fixup the
PHY device LEDs. This patch ensures the phy->dev_flags value is passed
to the phy_attach() function such that the PHY device driver can
actually use it."
>
> Change-Id: I37d64795f79c358f66a211a150cec2263e40e295
> ---
> drivers/net/ethernet/marvell/mv643xx_eth.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/ethernet/marvell/mv643xx_eth.c b/drivers/net/ethernet/marvell/mv643xx_eth.c
> index 84c1326..7b8c1ac 100644
> --- a/drivers/net/ethernet/marvell/mv643xx_eth.c
> +++ b/drivers/net/ethernet/marvell/mv643xx_eth.c
> @@ -2789,7 +2789,7 @@ static void phy_init(struct mv643xx_eth_private *mp, int speed, int duplex)
>
> phy_reset(mp);
>
> - phy_attach(mp->dev, dev_name(&phy->dev), 0, PHY_INTERFACE_MODE_GMII);
> + phy_attach(mp->dev, dev_name(&phy->dev), phy->dev_flags, PHY_INTERFACE_MODE_GMII);
>
> if (speed == 0) {
> phy->autoneg = AUTONEG_ENABLE;
>
^ permalink raw reply
* Re: [PATCH 3.8-rc] tuntap: refuse to re-attach to different tun_struct
From: Michael S. Tsirkin @ 2013-01-10 10:23 UTC (permalink / raw)
To: Stefan Hajnoczi; +Cc: David S. Miller, Jason Wang, netdev, linux-kernel
In-Reply-To: <1357804788-19976-1-git-send-email-stefanha@redhat.com>
On Thu, Jan 10, 2013 at 08:59:48AM +0100, Stefan Hajnoczi wrote:
> Multiqueue tun devices support detaching a tun_file from its tun_struct
> and re-attaching at a later point in time. This allows users to disable
> a specific queue temporarily.
>
> ioctl(TUNSETIFF) allows the user to specify the network interface to
> attach by name. This means the user can attempt to attach to interface
> "B" after detaching from interface "A".
>
> The driver is not designed to support this so check we are re-attaching
> to the right tun_struct. Failure to do so may lead to oops.
>
> Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
> ---
> This fix is for 3.8-rc.
>
> drivers/net/tun.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/net/tun.c b/drivers/net/tun.c
> index fbd106e..cf6da6e 100644
> --- a/drivers/net/tun.c
> +++ b/drivers/net/tun.c
> @@ -491,6 +491,8 @@ static int tun_attach(struct tun_struct *tun, struct file *file)
> err = -EINVAL;
> if (rcu_dereference_protected(tfile->tun, lockdep_rtnl_is_held()))
> goto out;
> + if (tfile->detached && tun != tfile->detached)
> + goto out;
>
> err = -EBUSY;
> if (!(tun->flags & TUN_TAP_MQ) && tun->numqueues == 1)
> --
> 1.8.0.2
I agree this is a bug but even with this patch, we still allow:
SETIFF
SETQUEUE (DISABLED)
SETIFF
Originally the rule always was that repeated setiff calls fail with
EINVAL. We broke that when we set tun to NULL. It's probably worth
preserving that, even if queue is disabled. Applying something like the below
instead will address this concern, won't it?
Note: works with regular userspace but I didn't test
multiqueue userspace. What do you think.
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
---
diff --git a/drivers/net/tun.c b/drivers/net/tun.c
index fbd106e..5ec8b08 100644
--- a/drivers/net/tun.c
+++ b/drivers/net/tun.c
@@ -483,7 +483,7 @@ static void tun_detach_all(struct net_device *dev)
BUG_ON(tun->numdisabled != 0);
}
-static int tun_attach(struct tun_struct *tun, struct file *file)
+static int tun_attach(struct tun_struct *tun, struct file *file, bool setiff)
{
struct tun_file *tfile = file->private_data;
int err;
@@ -492,6 +492,9 @@ static int tun_attach(struct tun_struct *tun, struct file *file)
if (rcu_dereference_protected(tfile->tun, lockdep_rtnl_is_held()))
goto out;
+ if (setiff && tfile->detached)
+ goto out;
+
err = -EBUSY;
if (!(tun->flags & TUN_TAP_MQ) && tun->numqueues == 1)
goto out;
@@ -1561,7 +1564,7 @@ static int tun_set_iff(struct net *net, struct file *file, struct ifreq *ifr)
if (err < 0)
return err;
- err = tun_attach(tun, file);
+ err = tun_attach(tun, file, true);
if (err < 0)
return err;
@@ -1627,7 +1630,7 @@ static int tun_set_iff(struct net *net, struct file *file, struct ifreq *ifr)
dev->features = dev->hw_features;
INIT_LIST_HEAD(&tun->disabled);
- err = tun_attach(tun, file);
+ err = tun_attach(tun, file, true);
if (err < 0)
goto err_free_dev;
@@ -1792,7 +1795,7 @@ static int tun_set_queue(struct file *file, struct ifreq *ifr)
else if (tun_not_capable(tun))
ret = -EPERM;
else
- ret = tun_attach(tun, file);
+ ret = tun_attach(tun, file, false);
} else if (ifr->ifr_flags & IFF_DETACH_QUEUE) {
tun = rcu_dereference_protected(tfile->tun,
lockdep_rtnl_is_held());
^ permalink raw reply related
* Re: pull request: wireless 2013-01-09
From: Sedat Dilek @ 2013-01-10 10:14 UTC (permalink / raw)
To: John W. Linville; +Cc: davem, linux-wireless, netdev, linux-kernel
In-Reply-To: <20130109191817.GA17321@tuxdriver.com>
On Wed, Jan 9, 2013 at 8:18 PM, John W. Linville <linville@tuxdriver.com> wrote:
> Dave,
>
> Please pull this batch of fixes (and a new driver) for the 3.8 stream...
>
> Included is a mac80211 pull, of which Johannes says the following:
>
> 'This includes a number of fixes for various pieces of mac80211. I've
> also included Thomas's memory RMC hash table optimisation since it
> saves so much memory.'
>
> Also from Johannes is an iwlwifi pull:
>
> 'I have two fixes for iwlwifi: one to fix a lost return value that was
> dropped in a previous patch and could cause "nobody cared" IRQ messages,
> and one to work around a firmware issue.'
>
> Amitkumar Karwar brings an mwifiex for a typo in an comparison.
>
> Bing Zhao gives us an mwifiex fix to properly check the return value
> from wait_event_interruptible and handle it properly.
>
> Chen Gang provides a fix to make iwlegacy use strlcpy instead of
> strncpy, avoiding a potential buffer underflow.
>
> Julian Wollrath fixes a typo in an error message in rtlwifi.
>
> Larry Finger brings a b43 fix for a firmware loading problem.
>
> Nickolai Zeldovich avoids a use-after-free in the mwl8k driver.
>
> Vladimir Kondratiev brings the last big piece, the new Qualcomm/Atheros
> wil6210 802.11ad driver. Since it is for new hardware, I hope that
> taking it for 3.8 is not a problem.
>
> Please let me know if there are problems!
>
> Thanks,
>
> John
>
> ---
>
> The following changes since commit c9be4a5c49cf51cc70a993f004c5bb30067a65ce:
>
> net: prevent setting ttl=0 via IP_TTL (2013-01-08 17:57:10 -0800)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless.git for-davem
>
> for you to fetch changes up to a9b8a894ad7d0b90b0464c9ac7e8e5c1687edcae:
>
> Merge branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless into for-davem (2013-01-09 11:01:37 -0500)
>
> ----------------------------------------------------------------
Hi John,
if I look at for-davem GIT branch (online GitWeb interface) [1], this
has no tag "master-2013-01-09" like in master branch.
Comments?
Regards,
- Sedat -
[1] http://git.kernel.org/?p=linux/kernel/git/linville/wireless-next.git;a=shortlog;h=refs/heads/for-davem
^ 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