* Re: Fw: [Bug 54021] New: No internet with kernel 3.7 or 3.8 with LAN
From: J. K. Cliburn @ 2013-02-19 13:13 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: Chris Snook, netdev, nic-devel, Huang, Xiong
In-Reply-To: <20130218220552.4d54c9a9@nehalam.linuxnetplumber.net>
Xiong,
Can you please investigate this atl1c issue?
Jay
On 02/19/2013 12:05 AM, Stephen Hemminger wrote:
> Also, in link it references the devices
>
> $ lspci -nnk | grep -i net -A2
> 01:00.0 Ethernet controller [0200]: Atheros Communications Inc. AR8152 v1.1 Fast Ethernet [1969:2060] (rev c1)
> Subsystem: Acer Incorporated [ALI] Device [1025:0349]
> Kernel driver in use: atl1c
> --
> 02:00.0 Network controller [0280]: Atheros Communications Inc. AR9285 Wireless Network Adapter (PCI-Express) [168c:002b] (rev 01)
> Subsystem: Lite-On Communications Inc Device [11ad:6631]
> Kernel driver in use: ath9k
>
> Begin forwarded message:
>
> Date: Sun, 17 Feb 2013 05:38:37 -0800
> From: "bugzilla-daemon@bugzilla.kernel.org" <bugzilla-daemon@bugzilla.kernel.org>
> To: "stephen@networkplumber.org" <stephen@networkplumber.org>
> Subject: [Bug 54021] New: No internet with kernel 3.7 or 3.8 with LAN
>
>
> https://bugzilla.kernel.org/show_bug.cgi?id=54021
>
> Summary: No internet with kernel 3.7 or 3.8 with LAN
> Product: Networking
> Version: 2.5
> Kernel Version: since 3.7
> Platform: All
> OS/Version: Linux
> Tree: Mainline
> Status: NEW
> Severity: normal
> Priority: P1
> Component: IPV4
> AssignedTo: shemminger@linux-foundation.org
> ReportedBy: david.erbs@gmail.com
> Regression: No
>
>
> Hello since kernel update 3.7 or 3.8 I have no internet connection with LAN,
> wlan is working very well, with lan my internet connection is working for 5
> minutes, then internet is not working anymore. I have to unplug the cable and
> the i have to plug it again - so it will work 5 minutes.....
>
> I have a netbook (acer aspire one d255)
>
>
> With kernel 3.5x everything is working fine.
>
> Problem is reported here (German)
>
> http://forum.ubuntuusers.de/topic/internet-verbindung-bricht-ab/
>
> If you need more information, feel free to ask
>
>
> kind regards
>
^ permalink raw reply
* Re: [PATCH v2 0/5] Generic PHY Framework
From: Felipe Balbi @ 2013-02-19 13:12 UTC (permalink / raw)
To: Arnd Bergmann
Cc: kishon, rob, tony, linux, eballetbo, javier, balbi, gregkh, akpm,
mchehab, cesarb, davem, santosh.shilimkar, broonie, swarren,
linux-doc, linux-kernel, linux-arm-kernel, linux-omap, linux-usb,
netdev
In-Reply-To: <201302191233.54677.arnd@arndb.de>
[-- Attachment #1: Type: text/plain, Size: 3391 bytes --]
Hi,
On Tue, Feb 19, 2013 at 12:33:54PM +0000, Arnd Bergmann wrote:
> On Tuesday 19 February 2013, kishon wrote:
> > On Tuesday 19 February 2013 04:14 PM, Arnd Bergmann wrote:
> > > On Tuesday 19 February 2013, Kishon Vijay Abraham I wrote:
> > >> Added a generic PHY framework that provides a set of APIs for the PHY drivers
> > >> to create/destroy a PHY and APIs for the PHY users to obtain a reference to
> > >> the PHY with or without using phandle. To obtain a reference to the PHY
> > >> without using phandle, the platform specfic intialization code (say from board
> > >> file) should have already called phy_bind with the binding information. The
> > >> binding information consists of phy's device name, phy user device name and an
> > >> index. The index is used when the same phy user binds to mulitple phys.
> > >>
> > >> This framework will be of use only to devices that uses external PHY (PHY
> > >> functionality is not embedded within the controller).
> > >>
> > >> The intention of creating this framework is to bring the phy drivers spread
> > >> all over the Linux kernel to drivers/phy to increase code re-use and to
> > >> increase code maintainability.
> > >>
> > >> Comments to make PHY as bus wasn't done because PHY devices can be part of
> > >> other bus and making a same device attached to multiple bus leads to bad
> > >> design.
> > >
> > > How does this relate to the generic PHY interfaces in drivers/net/phy?
> >
> > Currently drivers/phy and drivers/net/phy are independent and are not
> > related to each other. There are some fundamental differences on how
> > these frameworks work. IIUC, the *net* uses bus layer (MDIO bus) to
> > match a PHY device with a PHY driver and the Ethernet device uses the
> > bus layer to get the PHY.
> > The Generic PHY Framework however doesn't have any bus layer. The PHY
> > should be like any other Platform Devices and Drivers and the framework
> > will provide some APIs to register with the framework. And there are
> > other APIs which any controller can use to get the PHY (for e.g., in the
> > case of dt boot, it can use phandle to get a reference to the PHY).
>
> Hmm, I think the use of a bus_type for a PHY actually sounds quite
> appropriate. The actual PHY device would then be a child of the
really ? I'm not so sure, the *bus* used by the PHY is ULPI, UTMI,
UTMI+, PIP3, I2C, etc... adding another 'fake' bus representation is a
bit overkill IMO.
Imagine an I2C-controlled PHY driver like isp1301, that driver will have
to register i2c_driver and phy_driver, which looks weird to me. If the
only substitute for class is a bus, we can't drop classes just yet, I'm
afraid.
Imagine a regulator bus, a pwm bus, an LED bus etc. They don't make
sense IMHO.
> platform_device (or something else) that gets probed by its parent
> bus or the DT. The operations that you define for the PHY
> actually mirror some of the things that we have for a 'struct device',
> so I think it would be quite logical to do it the same way.
>
> Note that MDIO has both a 'bus' and a 'class', and what we want here is more
> like what the 'class' was meant for, except that for new classes, we
> should actually use a 'bus', since the long-term plan is to kill off
> the concept of a 'class'. I hope that was not too confusing. :)
:)
--
balbi
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: SYSFS "errors"
From: Borislav Petkov @ 2013-02-19 13:06 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: balbi, Greg KH, Linux Kernel Mailing List, Steven Rostedt,
Frederic Weisbecker, Ingo Molnar, JBottomley, linux-scsi, davem,
netdev, Doug Thompson, linux-edac, rjw, linux-pm
In-Reply-To: <20130219094640.2abf1a66@redhat.com>
On Tue, Feb 19, 2013 at 09:46:40AM -0300, Mauro Carvalho Chehab wrote:
> Ah, now I see what you're meaning. That would require to dynamically
> create a per-mci DEVICE_ATTR().
Dude, look at the code, we do that already. And you're using it with
dev_attr_sdram_scrub_rate.
Simply change the permissions of the attribute before calling
device_create_file.
pseudo:
umode_t mode = 0;
if (mci->set...)
mode |= S_IWUSR;
if (mci->get...)
mode |= S_IRUGO;
dev_attr_sdram_scrub_rate.attr.mode = mode;
device_create_file(&mci->dev, &dev_attr_sdram_scrub_rate);
> No, on both cases, open() will return an error (-ENOENT against -EPERM).
What if it is a shell script doing:
cat /sys/devices/system/edac/mc/mc0/sdram_scrub_rate
or similar?
Simply fixing the permissions fixes *all* possible cases.
--
Regards/Gruss,
Boris.
Sent from a fat crate under my desk. Formatting is fine.
--
^ permalink raw reply
* Re: [PATCH v2 1/5] drivers: phy: add generic PHY framework
From: Arnd Bergmann @ 2013-02-19 12:56 UTC (permalink / raw)
To: Kishon Vijay Abraham I
Cc: rob, tony, linux, eballetbo, javier, balbi, gregkh, akpm, mchehab,
cesarb, davem, santosh.shilimkar, broonie, swarren, linux-doc,
linux-kernel, linux-arm-kernel, linux-omap, linux-usb, netdev
In-Reply-To: <1361253198-7401-2-git-send-email-kishon@ti.com>
On Tuesday 19 February 2013, Kishon Vijay Abraham I wrote:
> +static struct class *phy_class;
> +static LIST_HEAD(phy_list);
> +static DEFINE_MUTEX(phy_list_mutex);
> +static LIST_HEAD(phy_bind_list);
Hmm, so you actually do have a 'class'. There is a GregKH mandated ban on
new classes, meaning that one should be converted to a bus_type instead.
Also, you really should not need the global phy_list, phy_list_mutex
and phy_bind_list variables, since the driver core already provides
you with ways to iterate through devices on a class or bus.
> +/**
> + * of_phy_get - lookup and obtain a reference to a phy by phandle
> + * @dev: device that requests this phy
> + * @phandle: name of the property holding the phy phandle value
> + * @index - the index of the phy
> + *
> + * Returns the phy associated with the given phandle value,
> + * after getting a refcount to it or -ENODEV if there is no such phy or
> + * -EPROBE_DEFER if there is a phandle to the phy, but the device is
> + * not yet loaded.
> + */
> +struct phy *of_phy_get(struct device *dev, const char *phandle, u8 index)
> +{
> + struct phy *phy = NULL;
> + struct phy_bind *phy_map = NULL;
> + struct device_node *node;
> +
> + if (!dev->of_node) {
> + dev_dbg(dev, "device does not have a device node entry\n");
> + return ERR_PTR(-EINVAL);
> + }
> +
> + node = of_parse_phandle(dev->of_node, phandle, index);
> + if (!node) {
> + dev_dbg(dev, "failed to get %s phandle in %s node\n", phandle,
> + dev->of_node->full_name);
> + return ERR_PTR(-ENODEV);
> + }
I wonder whether this one should be of_parse_phandle_with_args() instead,
so you can have client-specific configuration in the property. Basically
instead of
phy = <&usbphy0 &usbphy1>;
you can pass an arbitrary number of arguments along with this, as
determined by some property in the phy node:
usbphy0: phy@10000 {
#phy-cells = <1>;
};
ehci@20000 {
phy = <&usbphy0 23>;
};
Which in turn leads to the argument (23) being passed into a phy_bind().
I also wonder if you should allow arbitrary names for the property.
Can't this always be called 'phy'? If you allow named phys, it would
more more consistent with other bindings to have a list of phy handles
in a property called "phy", and a second property called "phy-names"
that contains the named strings.
> +/**
> + * phy_create - create a new phy
> + * @dev: device that is creating the new phy
> + * @desc: descriptor of the phy
> + *
> + * Called to create a phy using phy framework.
> + */
> +struct phy *phy_create(struct device *dev, struct phy_descriptor *desc)
> +{
> + int ret;
> + struct phy *phy;
> + struct phy_bind *phy_bind;
> + const char *devname = NULL;
> ...
> +
> + devname = dev_name(dev);
> + device_initialize(&phy->dev);
> + phy->desc = desc;
> + phy->dev.class = phy_class;
> + phy->dev.parent = dev;
> + phy->dev.bus = desc->bus;
> + ret = dev_set_name(&phy->dev, "%s", devname);
Passing a bus_type through the descriptor seems misplaced. What is this for?
Why is this function not just:
struct phy *phy_create(struct device *dev, const char *label, int type,
struct phy_ops *ops);
Passing a structure like you do here seems dangerous because when someone
decides to add members to the structure, existing code will not give a
build error but silently break.
> +/**
> + * struct phy_ops - set of function pointers for performing phy operations
> + * @init: operation to be performed for initializing phy
> + * @exit: operation to be performed while exiting
> + * @suspend: suspending the phy
> + * @resume: resuming the phy
> + * @poweron: powering on the phy
> + * @shutdown: shutting down the phy
> + * @owner: the module owner containing the ops
> + */
> +struct phy_ops {
> + int (*init)(struct phy_descriptor *desc);
> + int (*exit)(struct phy_descriptor *desc);
> + int (*suspend)(struct phy_descriptor *desc);
> + int (*resume)(struct phy_descriptor *desc);
> + int (*poweron)(struct phy_descriptor *desc);
> + int (*shutdown)(struct phy_descriptor *desc);
> + struct module *owner;
> +};
Shouldn't these take the 'struct phy' as an argument? struct phy_descriptor is
not even based on a 'struct device'.
> +struct phy {
> + struct device dev;
> + struct phy_descriptor *desc;
> + struct list_head head;
> +};
Please kill off the 'head' member here and use the infrastructure we
already have. The concept of the phy_descriptor seems even more foreign
here, so best just collapse that into 'struct phy'. Maybe also rename
the structure to 'phy_device'.
Arnd
^ permalink raw reply
* [Patch] net: fix a build failure when !CONFIG_PROC_FS
From: Cong Wang @ 2013-02-19 12:47 UTC (permalink / raw)
To: netdev; +Cc: Gao feng, David S. Miller, Cong Wang
From: Cong Wang <xiyou.wangcong@gmail.com>
When !CONFIG_PROC_FS dev_mcast_init() is not defined,
actually we can just merge dev_mcast_init() into
dev_proc_init().
Reported-by: Gao feng <gaofeng@cn.fujitsu.com>
Cc: Gao feng <gaofeng@cn.fujitsu.com>
Cc: "David S. Miller" <davem@davemloft.net>
Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
---
diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
index f111b4f..b3d00fa 100644
--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@ -2646,7 +2646,6 @@ extern void netdev_notify_peers(struct net_device *dev);
extern void netdev_features_change(struct net_device *dev);
/* Load a device via the kmod */
extern void dev_load(struct net *net, const char *name);
-extern void dev_mcast_init(void);
extern struct rtnl_link_stats64 *dev_get_stats(struct net_device *dev,
struct rtnl_link_stats64 *storage);
extern void netdev_stats_to_stats64(struct rtnl_link_stats64 *stats64,
diff --git a/net/core/dev.c b/net/core/dev.c
index 8d9ddb0..17bc535 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -6260,7 +6260,6 @@ static int __init net_dev_init(void)
hotcpu_notifier(dev_cpu_callback, 0);
dst_init();
- dev_mcast_init();
rc = 0;
out:
return rc;
diff --git a/net/core/net-procfs.c b/net/core/net-procfs.c
index ac87066..0f6bb6f 100644
--- a/net/core/net-procfs.c
+++ b/net/core/net-procfs.c
@@ -341,11 +341,6 @@ static struct pernet_operations __net_initdata dev_proc_ops = {
.exit = dev_proc_net_exit,
};
-int __init dev_proc_init(void)
-{
- return register_pernet_subsys(&dev_proc_ops);
-}
-
static int dev_mc_seq_show(struct seq_file *seq, void *v)
{
struct netdev_hw_addr *ha;
@@ -408,7 +403,10 @@ static struct pernet_operations __net_initdata dev_mc_net_ops = {
.exit = dev_mc_net_exit,
};
-void __init dev_mcast_init(void)
+int __init dev_proc_init(void)
{
- register_pernet_subsys(&dev_mc_net_ops);
+ int ret = register_pernet_subsys(&dev_proc_ops);
+ if (!ret)
+ return register_pernet_subsys(&dev_mc_net_ops);
+ return ret;
}
^ permalink raw reply related
* Re: SYSFS "errors"
From: Mauro Carvalho Chehab @ 2013-02-19 12:46 UTC (permalink / raw)
To: Borislav Petkov
Cc: balbi, Greg KH, Linux Kernel Mailing List, Steven Rostedt,
Frederic Weisbecker, Ingo Molnar, JBottomley, linux-scsi, davem,
netdev, Doug Thompson, linux-edac, rjw, linux-pm
In-Reply-To: <20130219123502.GD26623@pd.tnic>
Em Tue, 19 Feb 2013 13:35:02 +0100
Borislav Petkov <bp@alien8.de> escreveu:
> On Tue, Feb 19, 2013 at 09:16:10AM -0300, Mauro Carvalho Chehab wrote:
> > I'm not sure if is there a way to pass fs permissions to something similar
> > to device_create_file().
>
> struct device_attribute.attr.mode? I.e., second arg.
Ah, now I see what you're meaning. That would require to dynamically
create a per-mci DEVICE_ATTR().
> > On both cases, an error will happen at open:
> > - if file doesn't exist (this approach), it will return -ENOENT;
> > - if file is opened with wrong permissions, open will return -EPERM.
> >
> > However, if the file is not created, readdir() won't show the file.
>
> Right, and in that case userspace which *assumes* it is always created -
> like it is now - will fail when accessing it.
>
> If simply you adjust the attributes accordingly but *always* create the
> file and it has the correct permissions, everyone is happy. Right?
No, on both cases, open() will return an error (-ENOENT against -EPERM).
If userspace doesn't check if open() failed, I can't see why
changing the open return error code would help.
--
Cheers,
Mauro
^ permalink raw reply
* Re: SYSFS "errors"
From: Borislav Petkov @ 2013-02-19 12:35 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: balbi, Greg KH, Linux Kernel Mailing List, Steven Rostedt,
Frederic Weisbecker, Ingo Molnar, JBottomley, linux-scsi, davem,
netdev, Doug Thompson, linux-edac, rjw, linux-pm
In-Reply-To: <20130219091610.2b746a30@redhat.com>
On Tue, Feb 19, 2013 at 09:16:10AM -0300, Mauro Carvalho Chehab wrote:
> I'm not sure if is there a way to pass fs permissions to something similar
> to device_create_file().
struct device_attribute.attr.mode? I.e., second arg.
> On both cases, an error will happen at open:
> - if file doesn't exist (this approach), it will return -ENOENT;
> - if file is opened with wrong permissions, open will return -EPERM.
>
> However, if the file is not created, readdir() won't show the file.
Right, and in that case userspace which *assumes* it is always created -
like it is now - will fail when accessing it.
If simply you adjust the attributes accordingly but *always* create the
file and it has the correct permissions, everyone is happy. Right?
--
Regards/Gruss,
Boris.
Sent from a fat crate under my desk. Formatting is fine.
--
^ permalink raw reply
* Re: [PATCH v2 0/5] Generic PHY Framework
From: Arnd Bergmann @ 2013-02-19 12:33 UTC (permalink / raw)
To: kishon
Cc: rob-VoJi6FS/r0vR7s880joybQ, tony-4v6yS6AI5VpBDgjK7y7TUQ,
linux-lFZ/pmaqli7XmaaqVzeoHQ, eballetbo-Re5JQEeQqe8AvxtiuMwx3w,
javier-0uQlZySMnqxg9hUCZPvPmw, balbi-l0cyMroinI0,
gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r,
akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b,
mchehab-H+wXaHxf7aLQT0dZR+AlfA, cesarb-PWySMVKUnqmsTnJN9+BGXg,
davem-fT/PcQaiUtIeIZ0/mPfg9Q, santosh.shilimkar-l0cyMroinI0,
broonie-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E,
swarren-DDmLM1+adcrQT0dZR+AlfA, linux-doc-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-omap-u79uwXL29TY76Z2rM5mHXA,
linux-usb-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <512361F0.1070500-l0cyMroinI0@public.gmane.org>
On Tuesday 19 February 2013, kishon wrote:
> On Tuesday 19 February 2013 04:14 PM, Arnd Bergmann wrote:
> > On Tuesday 19 February 2013, Kishon Vijay Abraham I wrote:
> >> Added a generic PHY framework that provides a set of APIs for the PHY drivers
> >> to create/destroy a PHY and APIs for the PHY users to obtain a reference to
> >> the PHY with or without using phandle. To obtain a reference to the PHY
> >> without using phandle, the platform specfic intialization code (say from board
> >> file) should have already called phy_bind with the binding information. The
> >> binding information consists of phy's device name, phy user device name and an
> >> index. The index is used when the same phy user binds to mulitple phys.
> >>
> >> This framework will be of use only to devices that uses external PHY (PHY
> >> functionality is not embedded within the controller).
> >>
> >> The intention of creating this framework is to bring the phy drivers spread
> >> all over the Linux kernel to drivers/phy to increase code re-use and to
> >> increase code maintainability.
> >>
> >> Comments to make PHY as bus wasn't done because PHY devices can be part of
> >> other bus and making a same device attached to multiple bus leads to bad
> >> design.
> >
> > How does this relate to the generic PHY interfaces in drivers/net/phy?
>
> Currently drivers/phy and drivers/net/phy are independent and are not
> related to each other. There are some fundamental differences on how
> these frameworks work. IIUC, the *net* uses bus layer (MDIO bus) to
> match a PHY device with a PHY driver and the Ethernet device uses the
> bus layer to get the PHY.
> The Generic PHY Framework however doesn't have any bus layer. The PHY
> should be like any other Platform Devices and Drivers and the framework
> will provide some APIs to register with the framework. And there are
> other APIs which any controller can use to get the PHY (for e.g., in the
> case of dt boot, it can use phandle to get a reference to the PHY).
Hmm, I think the use of a bus_type for a PHY actually sounds quite
appropriate. The actual PHY device would then be a child of the
platform_device (or something else) that gets probed by its parent
bus or the DT. The operations that you define for the PHY
actually mirror some of the things that we have for a 'struct device',
so I think it would be quite logical to do it the same way.
Note that MDIO has both a 'bus' and a 'class', and what we want here is more
like what the 'class' was meant for, except that for new classes, we
should actually use a 'bus', since the long-term plan is to kill off
the concept of a 'class'. I hope that was not too confusing. :)
> > Do you expect that to get merged into drivers/phy in the long run, or
> > do you want to keep the generic phy only for everything but ethernet?
>
> We'd like the PHY drivers spread all over the kernel to get merged to
> drivers/phy including Ethernet. Having said that, Ethernet itself has a
> huge PHY framework and it's going to be little challenging to adapt to
> the new PHY framework (of course there'll be changes in this PHY
> framework when we want to have network PHY added here). But adapting USB
> PHYs to the new framework will be simpler and will be taken first. Also
> when we add SATA PHY (OMAP5), it will make use of this framework as both
> SATA and USB3 uses the same PHY IP.
I think you need to have at least a concept of where you want to end up.
It's totally fine to introduce a new subsystem that does only the
minimum of what you need here, and add things as you go, but if you
already plan to merge the existing mdio bus into this, you should really
have an idea of what that will mean in the long run.
> > I think it would be problematic to have two alternative interfaces for
> > ethernet PHYs because then an ethernet driver still needs to decide
> > which subsystem to interface with.
>
> Right. For now Ethernet should continue to use their own PHY abstraction
> layer till we are a bit more clear on how to move it to drivers/phy.
Ok.
Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" 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: SYSFS "errors"
From: Mauro Carvalho Chehab @ 2013-02-19 12:16 UTC (permalink / raw)
To: Borislav Petkov
Cc: balbi, Greg KH, Linux Kernel Mailing List, Steven Rostedt,
Frederic Weisbecker, Ingo Molnar, JBottomley, linux-scsi, davem,
netdev, Doug Thompson, linux-edac, rjw, linux-pm
In-Reply-To: <20130219114345.GA26623@pd.tnic>
Em Tue, 19 Feb 2013 12:43:46 +0100
Borislav Petkov <bp@alien8.de> escreveu:
> On Tue, Feb 19, 2013 at 08:11:49AM -0300, Mauro Carvalho Chehab wrote:
> > > > I remember I saw some discussions about it in the past at bluesmoke ML,
> > > > saying that -ENODEV is the expected behavior when this is not supported.
> > > >
> > > > Changing from -ENODEV to "N/A" will break anything that would be relying
> > > > on the previous behavior. So, I think that such change will for sure break
> > > > userspace.
> > > >
> > > > If we're willing to change it, not creating the "sdram_scrub_rate" sysfs
> > > > node is less likely to affect userspace.
>
> This will break scripts which assume this file's presence implicitly.
If are there any script like that, then yes.
> [ … ]
>
> > @@ -1017,6 +1010,14 @@ int edac_create_sysfs_mci_device(struct mem_ctl_info *mci)
> > return err;
> > }
> >
> > + if (mci->set_sdram_scrub_rate && mci->get_sdram_scrub_rate) {
>
> This will break cpc925_edac.c because it defines a
> ->get_sdram_scrub_rate but not a ->set_sdram_scrub_rate.
True. Patch below fixes it.
> I think a maybe better fix would be to figure out the sysfs file
> permissions based on the presence of the two functions and *then* add
> the attribute.
>
> This way, the only visible change to userspace is the corrected sysfs
> file permissions.
I'm not sure if is there a way to pass fs permissions to something similar
to device_create_file().
On both cases, an error will happen at open:
- if file doesn't exist (this approach), it will return -ENOENT;
- if file is opened with wrong permissions, open will return -EPERM.
However, if the file is not created, readdir() won't show the file.
So, if userspace first seeks for the sdram_scrub_rate, it won't fail.
That makes the logic below a little safer, IMO.
[PATCH EDAC] edac: only create sdram_scrub_rate where supported
Currently, sdram_scrub_rate sysfs node is created even if the device
doesn't support get/set the scub rate. Change the logic to only
create this device node when the operation is supported.
If only read or only write is supported, it will keep returning -ENODEV
just like before.
Reported-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
diff --git a/drivers/edac/edac_mc_sysfs.c b/drivers/edac/edac_mc_sysfs.c
index 9c58da6..29b66a2 100644
--- a/drivers/edac/edac_mc_sysfs.c
+++ b/drivers/edac/edac_mc_sysfs.c
@@ -7,7 +7,7 @@
*
* Written Doug Thompson <norsk5@xmission.com> www.softwarebitmaker.com
*
- * (c) 2012 - Mauro Carvalho Chehab <mchehab@redhat.com>
+ * (c) 2012-2013 - Mauro Carvalho Chehab <mchehab@redhat.com>
* The entire API were re-written, and ported to use struct device
*
*/
@@ -882,7 +882,6 @@ static struct attribute *mci_attrs[] = {
&dev_attr_ce_noinfo_count.attr,
&dev_attr_ue_count.attr,
&dev_attr_ce_count.attr,
- &dev_attr_sdram_scrub_rate.attr,
&dev_attr_max_location.attr,
NULL
};
@@ -1017,6 +1016,14 @@ int edac_create_sysfs_mci_device(struct mem_ctl_info *mci)
return err;
}
+ if (mci->set_sdram_scrub_rate || mci->get_sdram_scrub_rate) {
+ err = device_create_file(&mci->dev,
+ &dev_attr_sdram_scrub_rate);
+ if (err) {
+ edac_dbg(1, "failure: create sdram_scrub_rate\n");
+ goto fail2;
+ }
+ }
/*
* Create the dimm/rank devices
*/
@@ -1061,6 +1068,7 @@ fail:
continue;
device_unregister(&dimm->dev);
}
+fail2:
device_unregister(&mci->dev);
bus_unregister(&mci->bus);
kfree(mci->bus.name);
^ permalink raw reply related
* Re: [PATCH 2/3] net: dev: fix build failed when procfs is disabled
From: Cong Wang @ 2013-02-19 12:02 UTC (permalink / raw)
To: Gao feng; +Cc: netdev, davem
In-Reply-To: <1361270592-19492-2-git-send-email-gaofeng@cn.fujitsu.com>
On 02/19/2013 06:43 PM, Gao feng wrote:
> commit 900ff8c6321418dafa03c22e215cb9646a2541b9
> "net: move procfs code to net/core/net-procfs.c"
> missed define dev_mcast_init when CONFIG_PROC
> isn't configured.
>
> Cc: Cong Wang <xiyou.wangcong@gmail.com>
> Signed-off-by: Gao feng <gaofeng@cn.fujitsu.com>
> ---
> include/linux/netdevice.h | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
> index f111b4f..91f6c7b 100644
> --- a/include/linux/netdevice.h
> +++ b/include/linux/netdevice.h
> @@ -2693,8 +2693,10 @@ extern void net_disable_timestamp(void);
>
> #ifdef CONFIG_PROC_FS
> extern int __init dev_proc_init(void);
> +extern void __init dev_mcast_init(void);
> #else
> #define dev_proc_init() 0
> +#define dev_mcast_init() {}
> #endif
>
> extern int netdev_class_create_file(struct class_attribute *class_attr);
>
Thanks for catching this!
I forgot to test !CONFIG_PROC_FS case again after grabbing the mcast piece.
I have a better fix, which moves dev_mcast_init() to dev_proc_init(),
will post it right now.
^ permalink raw reply
* Re: SYSFS "errors"
From: Borislav Petkov @ 2013-02-19 11:43 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: balbi, Greg KH, Linux Kernel Mailing List, Steven Rostedt,
Frederic Weisbecker, Ingo Molnar, JBottomley, linux-scsi, davem,
netdev, Doug Thompson, linux-edac, rjw, linux-pm
In-Reply-To: <20130219081149.46972f56@redhat.com>
On Tue, Feb 19, 2013 at 08:11:49AM -0300, Mauro Carvalho Chehab wrote:
> > > I remember I saw some discussions about it in the past at bluesmoke ML,
> > > saying that -ENODEV is the expected behavior when this is not supported.
> > >
> > > Changing from -ENODEV to "N/A" will break anything that would be relying
> > > on the previous behavior. So, I think that such change will for sure break
> > > userspace.
> > >
> > > If we're willing to change it, not creating the "sdram_scrub_rate" sysfs
> > > node is less likely to affect userspace.
This will break scripts which assume this file's presence implicitly.
[ … ]
> @@ -1017,6 +1010,14 @@ int edac_create_sysfs_mci_device(struct mem_ctl_info *mci)
> return err;
> }
>
> + if (mci->set_sdram_scrub_rate && mci->get_sdram_scrub_rate) {
This will break cpc925_edac.c because it defines a
->get_sdram_scrub_rate but not a ->set_sdram_scrub_rate.
I think a maybe better fix would be to figure out the sysfs file
permissions based on the presence of the two functions and *then* add
the attribute.
This way, the only visible change to userspace is the corrected sysfs
file permissions.
--
Regards/Gruss,
Boris.
Sent from a fat crate under my desk. Formatting is fine.
--
^ permalink raw reply
* Re: [RFC] ipv6: rt6_update_expires() seems racy
From: Neil Horman @ 2013-02-19 11:30 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, netdev, Gao feng, Jiri Bohac
Thank you Eric! I'll look at this in detail today
Neil
Eric Dumazet <eric.dumazet@gmail.com> wrote:
>Some strange crashes happen in rt6_check_expired(), with access
>to random addresses.
>
>At first glance, it looks like the RTF_EXPIRES and
>stuff added in commit 1716a96101c49186b
>(ipv6: fix problem with expired dst cache)
>are racy : same dst could be manipulated at the same time
>on different cpus.
>
>At some point, our stack believes rt->dst.from contains a dst pointer,
>while its really a jiffie value (as rt->dst.expires shares the same area
>of memory)
>
>rt6_update_expires() should be fixed, or am I missing something ?
>
>CC Neil because of https://bugzilla.redhat.com/show_bug.cgi?id=892060
>
>
>
>
^ permalink raw reply
* Re: [PATCH v2 0/5] Generic PHY Framework
From: kishon @ 2013-02-19 11:28 UTC (permalink / raw)
To: Arnd Bergmann
Cc: rob, tony, linux, eballetbo, javier, balbi, gregkh, akpm, mchehab,
cesarb, davem, santosh.shilimkar, broonie, swarren, linux-doc,
linux-kernel, linux-arm-kernel, linux-omap, linux-usb, netdev
In-Reply-To: <201302191044.28653.arnd@arndb.de>
Hi,
On Tuesday 19 February 2013 04:14 PM, Arnd Bergmann wrote:
> On Tuesday 19 February 2013, Kishon Vijay Abraham I wrote:
>> Added a generic PHY framework that provides a set of APIs for the PHY drivers
>> to create/destroy a PHY and APIs for the PHY users to obtain a reference to
>> the PHY with or without using phandle. To obtain a reference to the PHY
>> without using phandle, the platform specfic intialization code (say from board
>> file) should have already called phy_bind with the binding information. The
>> binding information consists of phy's device name, phy user device name and an
>> index. The index is used when the same phy user binds to mulitple phys.
>>
>> This framework will be of use only to devices that uses external PHY (PHY
>> functionality is not embedded within the controller).
>>
>> The intention of creating this framework is to bring the phy drivers spread
>> all over the Linux kernel to drivers/phy to increase code re-use and to
>> increase code maintainability.
>>
>> Comments to make PHY as bus wasn't done because PHY devices can be part of
>> other bus and making a same device attached to multiple bus leads to bad
>> design.
>
> How does this relate to the generic PHY interfaces in drivers/net/phy?
Currently drivers/phy and drivers/net/phy are independent and are not
related to each other. There are some fundamental differences on how
these frameworks work. IIUC, the *net* uses bus layer (MDIO bus) to
match a PHY device with a PHY driver and the Ethernet device uses the
bus layer to get the PHY.
The Generic PHY Framework however doesn't have any bus layer. The PHY
should be like any other Platform Devices and Drivers and the framework
will provide some APIs to register with the framework. And there are
other APIs which any controller can use to get the PHY (for e.g., in the
case of dt boot, it can use phandle to get a reference to the PHY).
>
> Do you expect that to get merged into drivers/phy in the long run, or
> do you want to keep the generic phy only for everything but ethernet?
We'd like the PHY drivers spread all over the kernel to get merged to
drivers/phy including Ethernet. Having said that, Ethernet itself has a
huge PHY framework and it's going to be little challenging to adapt to
the new PHY framework (of course there'll be changes in this PHY
framework when we want to have network PHY added here). But adapting USB
PHYs to the new framework will be simpler and will be taken first. Also
when we add SATA PHY (OMAP5), it will make use of this framework as both
SATA and USB3 uses the same PHY IP.
>
> I think it would be problematic to have two alternative interfaces for
> ethernet PHYs because then an ethernet driver still needs to decide
> which subsystem to interface with.
Right. For now Ethernet should continue to use their own PHY abstraction
layer till we are a bit more clear on how to move it to drivers/phy.
Thanks
Kishon
^ permalink raw reply
* Re: SYSFS "errors"
From: Mauro Carvalho Chehab @ 2013-02-19 11:11 UTC (permalink / raw)
To: balbi
Cc: Borislav Petkov, Greg KH, Linux Kernel Mailing List,
Steven Rostedt, Frederic Weisbecker, Ingo Molnar, JBottomley,
linux-scsi, davem, netdev, Doug Thompson, linux-edac, rjw,
linux-pm
In-Reply-To: <20130219101121.GJ23197@arwen.pp.htv.fi>
[-- Attachment #1: Type: text/plain, Size: 3716 bytes --]
Em Tue, 19 Feb 2013 12:11:21 +0200
Felipe Balbi <balbi@ti.com> escreveu:
> Hi,
>
> On Tue, Feb 19, 2013 at 07:03:10AM -0300, Mauro Carvalho Chehab wrote:
> > > But my gut feeling says to stay concervative and not touch this code -
> > > we don't know what uses it and how much we would break by "fixing" it.
> > > The current situation is not that big of a deal IMVHO and I'd be willing
> > > to accept the small inconcistency versus possibly breaking userspace.
> >
> > I remember I saw some discussions about it in the past at bluesmoke ML,
> > saying that -ENODEV is the expected behavior when this is not supported.
> >
> > Changing from -ENODEV to "N/A" will break anything that would be relying
> > on the previous behavior. So, I think that such change will for sure break
> > userspace.
> >
> > If we're willing to change it, not creating the "sdram_scrub_rate" sysfs
> > node is less likely to affect userspace.
>
> yeah, I agree with this. Guess we shouldn't be creating files which
> aren't supported by the underlying HW and having a read() return -ENODEV
> is quite weird IMO since that's actually 'breaking' read() interface
> although that's up to interpretations.
The enclosed (untested) patch will likely do the trick. It needs to be
tested with one of the drivers that support scrub setting (amd64_edac.c,
cpc925_edac.c, e752x_edac.c, i5100_edac.c or i7core_edac.c).
Regards,
Mauro
-
[PATCH] edac: only create sdram_scrub_rate where supported
Currently, sdram_scrub_rate sysfs node is created even if the device
doesn't support get/set the scub rate. Change the logic to only
create this device node when the operation is supported.
Reported-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
diff --git a/drivers/edac/edac_mc_sysfs.c b/drivers/edac/edac_mc_sysfs.c
index 9c58da6..937975b 100644
--- a/drivers/edac/edac_mc_sysfs.c
+++ b/drivers/edac/edac_mc_sysfs.c
@@ -7,7 +7,7 @@
*
* Written Doug Thompson <norsk5@xmission.com> www.softwarebitmaker.com
*
- * (c) 2012 - Mauro Carvalho Chehab <mchehab@redhat.com>
+ * (c) 2012-2013 - Mauro Carvalho Chehab <mchehab@redhat.com>
* The entire API were re-written, and ported to use struct device
*
*/
@@ -681,9 +681,6 @@ static ssize_t mci_sdram_scrub_rate_store(struct device *dev,
unsigned long bandwidth = 0;
int new_bw = 0;
- if (!mci->set_sdram_scrub_rate)
- return -ENODEV;
-
if (strict_strtoul(data, 10, &bandwidth) < 0)
return -EINVAL;
@@ -707,9 +704,6 @@ static ssize_t mci_sdram_scrub_rate_show(struct device *dev,
struct mem_ctl_info *mci = to_mci(dev);
int bandwidth = 0;
- if (!mci->get_sdram_scrub_rate)
- return -ENODEV;
-
bandwidth = mci->get_sdram_scrub_rate(mci);
if (bandwidth < 0) {
edac_printk(KERN_DEBUG, EDAC_MC, "Error reading scrub rate\n");
@@ -882,7 +876,6 @@ static struct attribute *mci_attrs[] = {
&dev_attr_ce_noinfo_count.attr,
&dev_attr_ue_count.attr,
&dev_attr_ce_count.attr,
- &dev_attr_sdram_scrub_rate.attr,
&dev_attr_max_location.attr,
NULL
};
@@ -1017,6 +1010,14 @@ int edac_create_sysfs_mci_device(struct mem_ctl_info *mci)
return err;
}
+ if (mci->set_sdram_scrub_rate && mci->get_sdram_scrub_rate) {
+ err = device_create_file(&mci->dev,
+ &dev_attr_sdram_scrub_rate);
+ if (err) {
+ edac_dbg(1, "failure: create sdram_scrub_rate\n");
+ goto fail2;
+ }
+ }
/*
* Create the dimm/rank devices
*/
@@ -1061,6 +1062,7 @@ fail:
continue;
device_unregister(&dimm->dev);
}
+fail2:
device_unregister(&mci->dev);
bus_unregister(&mci->bus);
kfree(mci->bus.name);
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply related
* Re: PPPOE lockdep report in dev_queue_xmit+0x8b8/0x900
From: Yanko Kaneti @ 2013-02-19 11:10 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, netdev
In-Reply-To: <1361217052.19353.101.camel@edumazet-glaptop>
On Mon, 2013-02-18 at 11:50 -0800, Eric Dumazet wrote:
> From: Eric Dumazet <edumazet@google.com>
>
> On Mon, 2013-02-18 at 19:43 +0200, Yanko Kaneti wrote:
> > Hello,
> >
> > I've had the following lockdep report for the last couple of years of
> > kernels. I don't think I've had a lockup during that time related to
> > pppoe.
> >
> > The pppoe entry in the MAINTAINERS file lists Michal Ostrowski <mostrows@earthlink.net>
> > which unfortunately bounces.
> >
>
> Thanks for the report.
>
> Could you please test following patch ?
It looks like it has done the job. I am running a kernel with the patch
and workload that otherwise inevitably triggers the splat and so far it
has been quiet.
Thanks
>
> [PATCH] ppp: set qdisc_tx_busylock to avoid LOCKDEP splat
>
> If a qdisc is installed on a ppp device, its possible to get
> a lockdep splat under stress, because nested dev_queue_xmit() can
> lock busylock a second time (on a different device, so its a false
> positive)
>
> Avoid this problem using a distinct lock_class_key for team
> devices.
>
> Reported-by: Yanko Kaneti <yaneti@declera.com>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> ---
> drivers/net/ppp/ppp_generic.c | 8 ++++++++
> 1 file changed, 8 insertions(+)
>
> diff --git a/drivers/net/ppp/ppp_generic.c b/drivers/net/ppp/ppp_generic.c
> index 4fd754e..3db9131 100644
> --- a/drivers/net/ppp/ppp_generic.c
> +++ b/drivers/net/ppp/ppp_generic.c
> @@ -1058,7 +1058,15 @@ ppp_get_stats64(struct net_device *dev, struct rtnl_link_stats64 *stats64)
> return stats64;
> }
>
> +static struct lock_class_key ppp_tx_busylock;
> +static int ppp_dev_init(struct net_device *dev)
> +{
> + dev->qdisc_tx_busylock = &ppp_tx_busylock;
> + return 0;
> +}
> +
> static const struct net_device_ops ppp_netdev_ops = {
> + .ndo_init = ppp_dev_init,
> .ndo_start_xmit = ppp_start_xmit,
> .ndo_do_ioctl = ppp_net_ioctl,
> .ndo_get_stats64 = ppp_get_stats64,
>
>
> --
> 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
* Fast Loans
From: Sec Capital Loan @ 2013-02-19 8:31 UTC (permalink / raw)
Do you need a personal or business loan without stress and quick approval? If yes, contact us today as we are currently offering loans at superb interest rate. Our loan is secured and safe,For more information and Application, Please reply to this Email.
Sincerely,
Vijay Nath
^ permalink raw reply
* Re: Universal tap device
From: Jamal Hadi Salim @ 2013-02-19 10:59 UTC (permalink / raw)
To: Jiri Pirko; +Cc: netdev, arnd, ebiederm, stephen, eric.dumazet, davem
In-Reply-To: <20130216140132.GB1536@minipsycho.orion>
I dont know what macvtap is, but what dont you like about redirecting or
mirroring packets to tap? Or packet socket?
I think tap has become a christmas tree lately compared to its humble
beginnings, and its performance is questionable - but it should still
work for what you need.
cheers,
jamal
On 13-02-16 09:01 AM, Jiri Pirko wrote:
> Hi all.
>
> Looking at macvtap and thinking about the tap solutions in general, I
> think it would be handly to have some universal tap device.
>
> This could use rx_handler to hook onto any netdev and provide chardev
> tap-like iface to it. Using that, one can just hook onto macvlan device
> and macvtap would not be needed.
>
> This would allow other scenarios like vxlan-tap, vlan-tap, bond-tap or
> whatever.
>
> Does this idea seem to be reasonable?
>
> Thanks
>
> Jiri
> --
> 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 v6 08/46] CPU hotplug: Provide APIs to prevent CPU offline from atomic context
From: Srivatsa S. Bhat @ 2013-02-19 10:58 UTC (permalink / raw)
To: David Laight
Cc: Michel Lespinasse, linux-doc, peterz, fweisbec, linux-kernel,
mingo, linux-arch, linux, xiaoguangrong, wangyun, paulmck, nikunj,
linux-pm, rusty, rostedt, rjw, namhyung, tglx, linux-arm-kernel,
netdev, oleg, vincent.guittot, sbw, tj, akpm, linuxppc-dev
In-Reply-To: <AE90C24D6B3A694183C094C60CF0A2F6026B7154@saturn3.aculab.com>
On 02/19/2013 04:12 PM, David Laight wrote:
>> I wouldn't go that far... ;-) Unfairness is not a show-stopper right?
>> IMHO, the warning/documentation should suffice for anybody wanting to
>> try out this locking scheme for other use-cases.
>
> I presume that by 'fairness' you mean 'write preference'?
>
Yep.
> I'd not sure how difficult it would be, but maybe have two functions
> for acquiring the lock for read, one blocks if there is a writer
> waiting, the other doesn't.
>
> That way you can change the individual call sites separately.
>
Right, we could probably use that method to change the call sites in
multiple stages, in the future.
> The other place I can imagine a per-cpu rwlock being used
> is to allow a driver to disable 'sleep' or software controlled
> hardware removal while it performs a sequence of operations.
>
BTW, per-cpu rwlocks use spinlocks underneath, so they can be used only
in atomic contexts (you can't sleep holding this lock). So that would
probably make it less attractive or useless to "heavy-weight" usecases
like the latter one you mentioned. They probably need to use per-cpu
rw-semaphore or some such, which allows sleeping. I'm not very certain
of the exact usecases you are talking about, but I just wanted to
point out that percpu-rwlocks might not be applicable to many scenarios.
..(which might be a good thing, considering its unfair property today).
Regards,
Srivatsa S. Bhat
^ permalink raw reply
* Re: [PATCH v2 0/5] Generic PHY Framework
From: Arnd Bergmann @ 2013-02-19 10:44 UTC (permalink / raw)
To: Kishon Vijay Abraham I
Cc: rob, tony, linux, eballetbo, javier, balbi, gregkh, akpm, mchehab,
cesarb, davem, santosh.shilimkar, broonie, swarren, linux-doc,
linux-kernel, linux-arm-kernel, linux-omap, linux-usb, netdev
In-Reply-To: <1361253198-7401-1-git-send-email-kishon@ti.com>
On Tuesday 19 February 2013, Kishon Vijay Abraham I wrote:
> Added a generic PHY framework that provides a set of APIs for the PHY drivers
> to create/destroy a PHY and APIs for the PHY users to obtain a reference to
> the PHY with or without using phandle. To obtain a reference to the PHY
> without using phandle, the platform specfic intialization code (say from board
> file) should have already called phy_bind with the binding information. The
> binding information consists of phy's device name, phy user device name and an
> index. The index is used when the same phy user binds to mulitple phys.
>
> This framework will be of use only to devices that uses external PHY (PHY
> functionality is not embedded within the controller).
>
> The intention of creating this framework is to bring the phy drivers spread
> all over the Linux kernel to drivers/phy to increase code re-use and to
> increase code maintainability.
>
> Comments to make PHY as bus wasn't done because PHY devices can be part of
> other bus and making a same device attached to multiple bus leads to bad
> design.
How does this relate to the generic PHY interfaces in drivers/net/phy?
Do you expect that to get merged into drivers/phy in the long run, or
do you want to keep the generic phy only for everything but ethernet?
I think it would be problematic to have two alternative interfaces for
ethernet PHYs because then an ethernet driver still needs to decide
which subsystem to interface with.
Arnd
^ permalink raw reply
* RE: [PATCH v6 08/46] CPU hotplug: Provide APIs to prevent CPU offline from atomic context
From: David Laight @ 2013-02-19 10:42 UTC (permalink / raw)
To: Srivatsa S. Bhat, Michel Lespinasse
Cc: tglx, peterz, tj, oleg, paulmck, rusty, mingo, akpm, namhyung,
rostedt, wangyun, xiaoguangrong, rjw, sbw, fweisbec, linux,
nikunj, linux-pm, linux-arch, linux-arm-kernel, linuxppc-dev,
netdev, linux-doc, linux-kernel, vincent.guittot
In-Reply-To: <51234C23.2030909@linux.vnet.ibm.com>
> I wouldn't go that far... ;-) Unfairness is not a show-stopper right?
> IMHO, the warning/documentation should suffice for anybody wanting to
> try out this locking scheme for other use-cases.
I presume that by 'fairness' you mean 'write preference'?
I'd not sure how difficult it would be, but maybe have two functions
for acquiring the lock for read, one blocks if there is a writer
waiting, the other doesn't.
That way you can change the individual call sites separately.
The other place I can imagine a per-cpu rwlock being used
is to allow a driver to disable 'sleep' or software controlled
hardware removal while it performs a sequence of operations.
David
^ permalink raw reply
* [PATCH 3/3] net: ipv4: fix waring -Wunused-variable
From: Gao feng @ 2013-02-19 10:43 UTC (permalink / raw)
To: netdev; +Cc: davem, Gao feng
In-Reply-To: <1361270592-19492-1-git-send-email-gaofeng@cn.fujitsu.com>
the vars ip_rt_gc_timeout is used only when
CONFIG_SYSCTL is selected.
move these vars into CONFIG_SYSCTL.
Signed-off-by: Gao feng <gaofeng@cn.fujitsu.com>
---
net/ipv4/route.c | 9 +++++----
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/net/ipv4/route.c b/net/ipv4/route.c
index 3bdd1b1..6e28514 100644
--- a/net/ipv4/route.c
+++ b/net/ipv4/route.c
@@ -117,15 +117,11 @@
#define RT_GC_TIMEOUT (300*HZ)
static int ip_rt_max_size;
-static int ip_rt_gc_timeout __read_mostly = RT_GC_TIMEOUT;
-static int ip_rt_gc_interval __read_mostly = 60 * HZ;
-static int ip_rt_gc_min_interval __read_mostly = HZ / 2;
static int ip_rt_redirect_number __read_mostly = 9;
static int ip_rt_redirect_load __read_mostly = HZ / 50;
static int ip_rt_redirect_silence __read_mostly = ((HZ / 50) << (9 + 1));
static int ip_rt_error_cost __read_mostly = HZ;
static int ip_rt_error_burst __read_mostly = 5 * HZ;
-static int ip_rt_gc_elasticity __read_mostly = 8;
static int ip_rt_mtu_expires __read_mostly = 10 * 60 * HZ;
static int ip_rt_min_pmtu __read_mostly = 512 + 20 + 20;
static int ip_rt_min_advmss __read_mostly = 256;
@@ -2423,6 +2419,11 @@ void ip_rt_multicast_event(struct in_device *in_dev)
}
#ifdef CONFIG_SYSCTL
+static int ip_rt_gc_timeout __read_mostly = RT_GC_TIMEOUT;
+static int ip_rt_gc_interval __read_mostly = 60 * HZ;
+static int ip_rt_gc_min_interval __read_mostly = HZ / 2;
+static int ip_rt_gc_elasticity __read_mostly = 8;
+
static int ipv4_sysctl_rtcache_flush(ctl_table *__ctl, int write,
void __user *buffer,
size_t *lenp, loff_t *ppos)
--
1.7.11.7
^ permalink raw reply related
* [PATCH 2/3] net: dev: fix build failed when procfs is disabled
From: Gao feng @ 2013-02-19 10:43 UTC (permalink / raw)
To: netdev; +Cc: davem, Gao feng, Cong Wang
In-Reply-To: <1361270592-19492-1-git-send-email-gaofeng@cn.fujitsu.com>
commit 900ff8c6321418dafa03c22e215cb9646a2541b9
"net: move procfs code to net/core/net-procfs.c"
missed define dev_mcast_init when CONFIG_PROC
isn't configured.
Cc: Cong Wang <xiyou.wangcong@gmail.com>
Signed-off-by: Gao feng <gaofeng@cn.fujitsu.com>
---
include/linux/netdevice.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
index f111b4f..91f6c7b 100644
--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@ -2693,8 +2693,10 @@ extern void net_disable_timestamp(void);
#ifdef CONFIG_PROC_FS
extern int __init dev_proc_init(void);
+extern void __init dev_mcast_init(void);
#else
#define dev_proc_init() 0
+#define dev_mcast_init() {}
#endif
extern int netdev_class_create_file(struct class_attribute *class_attr);
--
1.7.11.7
^ permalink raw reply related
* [PATCH 1/3] net: proc: fix build failed when procfs is not configured
From: Gao feng @ 2013-02-19 10:43 UTC (permalink / raw)
To: netdev; +Cc: davem, Gao feng
commit d4beaa66add8aebf83ab16d2fde4e4de8dac36df
"net: proc: change proc_net_fops_create to proc_create"
uses proc_create to replace proc_net_fops_create, when
CONFIG_PROC isn't configured, some build error will
occurs.
net/packet/af_packet.c: In function 'packet_net_init':
net/packet/af_packet.c:3831:48: error: 'packet_seq_fops' undeclared (first use in this function)
net/packet/af_packet.c:3831:48: note: each undeclared identifier is reported only once for each function it appears in
There may be other build fails like above,this patch
change proc_create from function to macros when CONFIG_PROC
is not configured,just like what proc_net_fops_create did
before this commit.
Reported-by: Fengguang Wu <fengguang.wu@intel.com>
Signed-off-by: Gao feng <gaofeng@cn.fujitsu.com>
---
include/linux/proc_fs.h | 9 +++------
1 file changed, 3 insertions(+), 6 deletions(-)
diff --git a/include/linux/proc_fs.h b/include/linux/proc_fs.h
index 319f694..d0a1f2c 100644
--- a/include/linux/proc_fs.h
+++ b/include/linux/proc_fs.h
@@ -187,12 +187,9 @@ static inline void proc_flush_task(struct task_struct *task)
static inline struct proc_dir_entry *create_proc_entry(const char *name,
umode_t mode, struct proc_dir_entry *parent) { return NULL; }
-static inline struct proc_dir_entry *proc_create(const char *name,
- umode_t mode, struct proc_dir_entry *parent,
- const struct file_operations *proc_fops)
-{
- return NULL;
-}
+
+#define proc_create(name, mode, parent, fops) ({ (void)(mode), NULL; })
+
static inline struct proc_dir_entry *proc_create_data(const char *name,
umode_t mode, struct proc_dir_entry *parent,
const struct file_operations *proc_fops, void *data)
--
1.7.11.7
^ permalink raw reply related
* Re: [PATCH v5 00/45] CPU hotplug: stop_machine()-free CPU hotplug
From: Vincent Guittot @ 2013-02-19 10:33 UTC (permalink / raw)
To: Steven Rostedt
Cc: Srivatsa S. Bhat, paulmck, Russell King - ARM Linux, linux-doc,
peterz, fweisbec, linux-kernel, walken, mingo, linux-arch,
xiaoguangrong, wangyun, nikunj, linux-pm, Rusty Russell, rjw,
namhyung, tglx, linux-arm-kernel, netdev, oleg, sbw, tj, akpm,
linuxppc-dev
In-Reply-To: <1361217204.23152.171.camel@gandalf.local.home>
On 18 February 2013 20:53, Steven Rostedt <rostedt@goodmis.org> wrote:
> On Mon, 2013-02-18 at 17:50 +0100, Vincent Guittot wrote:
>
>> yes for sure.
>> The problem is more linked to cpuidle and function tracer.
>>
>> cpu hotplug and function tracer work when cpuidle is disable.
>> cpu hotplug and cpuidle works if i don't enable function tracer.
>> my platform is dead as soon as I enable function tracer if cpuidle is
>> enabled. It looks like some notrace are missing in my platform driver
>> but we haven't completely fix the issue yet
>>
>
> You can bisect to find out exactly what function is the problem:
>
> cat /debug/tracing/available_filter_functions > t
>
> f(t) {
> num=`wc -l t`
> sed -ne "1,${num}p" t > t1
> let num=num+1
> sed -ne "${num},$p" t > t2
>
> cat t1 > /debug/tracing/set_ftrace_filter
> # note this may take a long time to finish
>
> echo function > /debug/tracing/current_tracer
>
> <failed? bisect f(t1), if not bisect f(t2)>
> }
>
Thanks, i'm going to have a look
Vincent
> -- Steve
>
>
>
^ permalink raw reply
* Re: SYSFS "errors"
From: Felipe Balbi @ 2013-02-19 10:12 UTC (permalink / raw)
To: Alexander Stein; +Cc: Greg KH, Felipe Balbi, Linux Kernel Mailing List, netdev
In-Reply-To: <2721602.qxhJKWaVil@ws-stein>
[-- Attachment #1: Type: text/plain, Size: 715 bytes --]
+netdev
On Tue, Feb 19, 2013 at 08:41:47AM +0100, Alexander Stein wrote:
> On Monday 18 February 2013 09:49:16, Greg KH wrote:
> > > Invalid argument - /sys/devices/virtual/net/lo/speed
> > > Invalid argument - /sys/devices/virtual/net/lo/duplex
>
> This is even true for ethernet devices which do not have a link currently or non-ethernet devices (e.g. CAN).
> > LANG=C cat /sys/class/net/enp1s8/speed
> > cat: /sys/class/net/enp1s8/speed: Invalid argument
> > ethtool enp1s8 | grep -A1 Speed
> > Speed: Unknown!
> > Duplex: Unknown! (255)
> > LANG=C cat /sys/class/net/can0/speed
> > cat: /sys/class/net/can0/speed: Invalid argument
>
> Regards,
> Alexander
>
--
balbi
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ 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