* Re: [RFC] mac80211: Fix STA supported rate configuration with dummy entry
From: Arik Nemtsov @ 2011-10-24 11:59 UTC (permalink / raw)
To: Jouni Malinen; +Cc: Johannes Berg, Felix Fietkau, linux-wireless
In-Reply-To: <20111023194059.GA18385@jm.kir.nu>
On Sun, Oct 23, 2011 at 21:40, Jouni Malinen <j@w1.fi> wrote:
>
> Are all rate control algorithms fine with the second
> rate_control_rate_init() call? That is needed in the TDLS use case where
> the supported rate set is known only after the STA entry has been
Note that the sta-rates are not really required before second addition
(which also sets them). Initially the STA is not authorized for direct
Tx (as determined by the WLAN_STA_TDLS_PEER_AUTH bit).
We don't expect direct frames during link setup.
> added. I guess it would be possible to delay addition of the STA entry
> for TDLS until the supported rates are known, but I did not look at the
> details on what exactly that would require.
The STA is added to let us know we should drop all non-setup packets
between TDLS peers currently in link setup. We could have used a
different indication, but the STA entry is make the most sense here
since it is automatically cleaned up when we are disconnected from the
AP (as all TDLS state should be).
How about this one instead (tested hwsim with it):
>From d8b7acc16073e50f4fda3365d98ad01b21e2c631 Mon Sep 17 00:00:00 2001
From: Arik Nemtsov <arik@wizery.com>
Date: Mon, 24 Oct 2011 13:44:07 +0200
Subject: [RFC] mac80211: init rate-control for TDLS sta when supp-rates are
known
Initialize rate control algorithms only when supported rates are known
for a TDLS peer sta. Direct Tx between peers is not allowed before the
link is enabled. In turn, this only occurs after a change_station()
call that sets supported rates.
---
net/mac80211/cfg.c | 10 +++++++++-
1 files changed, 9 insertions(+), 1 deletions(-)
diff --git a/net/mac80211/cfg.c b/net/mac80211/cfg.c
index 1309bb9..9f05416d 100644
--- a/net/mac80211/cfg.c
+++ b/net/mac80211/cfg.c
@@ -829,7 +829,12 @@ static int ieee80211_add_station(struct wiphy
*wiphy, struct net_device *dev,
sdata->vif.type == NL80211_IFTYPE_STATION))
return -ENOTSUPP;
- rate_control_rate_init(sta);
+ /*
+ * for TDLS, rate control should be initialized only when supported
+ * rates are known.
+ */
+ if (!test_sta_flag(sta, WLAN_STA_TDLS_PEER))
+ rate_control_rate_init(sta);
layer2_update = sdata->vif.type == NL80211_IFTYPE_AP_VLAN ||
sdata->vif.type == NL80211_IFTYPE_AP;
@@ -913,6 +918,9 @@ static int ieee80211_change_station(struct wiphy *wiphy,
sta_apply_parameters(local, sta, params);
+ if (test_sta_flag(sta, WLAN_STA_TDLS_PEER) && params->supported_rates)
+ rate_control_rate_init(sta);
+
rcu_read_unlock();
if (sdata->vif.type == NL80211_IFTYPE_STATION &&
--
1.7.5.4
^ permalink raw reply related
* Re: match a few ecn-ip-ect in one rule
From: Sergey Naumov @ 2011-10-24 11:59 UTC (permalink / raw)
To: Jan Engelhardt; +Cc: netfilter
In-Reply-To: <alpine.LNX.2.01.1110241344010.21849@frira.zrqbmnf.qr>
> Since rules are generally combined in ORed, it only makes sense for
> matches to be ANDed (and submatch parts to be ORed at times).
Yes, I understand, but because of logic of project that I develop it
is better to use 1 rule than to search places where I have to add
workarounds to generate 2 iptables rules from 1 user specified rule.
When I use multiple -m molude inclusions, are specified parameters
combined as OR, as AND or overrided?
^ permalink raw reply
* Re: [PATCH] staging:iio:events: Make sure userspace buffer is large enough
From: Lars-Peter Clausen @ 2011-10-24 11:59 UTC (permalink / raw)
To: Jonathan Cameron
Cc: Michael Hennerich, linux-iio, device-drivers-devel, drivers
In-Reply-To: <4EA5521D.90403@cam.ac.uk>
On 10/24/2011 01:55 PM, Jonathan Cameron wrote:
> On 10/24/11 12:52, Lars-Peter Clausen wrote:
>> Make sure that the userspace buffer is large enough to hold a iio_event_data
>> struct before writing to it.
>>
> Good catch. Shall I tack this on the end of the two fixes sets I sent earlier?
Fine with me. Thanks.
>> Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
> Acked-by: Jonathan Cameron <jic23@cam.ac.uk>
>> ---
>> drivers/staging/iio/industrialio-core.c | 6 ++++--
>> 1 files changed, 4 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/staging/iio/industrialio-core.c b/drivers/staging/iio/industrialio-core.c
>> index 74904f1..733e83a 100644
>> --- a/drivers/staging/iio/industrialio-core.c
>> +++ b/drivers/staging/iio/industrialio-core.c
>> @@ -169,8 +169,11 @@ static ssize_t iio_event_chrdev_read(struct file *filep,
>> {
>> struct iio_event_interface *ev_int = filep->private_data;
>> struct iio_detected_event_list *el;
>> + size_t len = sizeof(el->ev);
>> int ret;
>> - size_t len;
>> +
>> + if (count < len)
>> + return -EINVAL;
>>
>> mutex_lock(&ev_int->event_list_lock);
>> if (list_empty(&ev_int->det_events)) {
>> @@ -192,7 +195,6 @@ static ssize_t iio_event_chrdev_read(struct file *filep,
>> el = list_first_entry(&ev_int->det_events,
>> struct iio_detected_event_list,
>> list);
>> - len = sizeof el->ev;
>> if (copy_to_user(buf, &(el->ev), len)) {
>> ret = -EFAULT;
>> goto error_mutex_unlock;
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-iio" 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 12/12] is_refname_available(): reimplement using do_for_each_ref_in_array()
From: Michael Haggerty @ 2011-10-24 11:58 UTC (permalink / raw)
To: Junio C Hamano
Cc: git, Jeff King, Drew Northup, Jakub Narebski, Heiko Voigt,
Johan Herland, Julian Phillips
In-Reply-To: <4E9FD1C3.3090302@alum.mit.edu>
On 10/20/2011 09:46 AM, Michael Haggerty wrote:
> On 10/20/2011 03:40 AM, Junio C Hamano wrote:
>> Hmm, why is this patch and only this one in the series full of whitespace
>> violations? Did you use a different settings or something?
>
> This happens rarely; I don't know why. Maybe I copy-pasted snippets
> from a view in an application that expanded the tabs. [...]
Now I think I know how this happened. When "git diff"'s output goes to
a TTY, it passes its output through the pager. The default pager, less,
seems to convert tabs into spaces. I probably copy-pasted some output
of diff into my editor then removed the first column of '+' characters.
Just another reason why tabs are evil...
:-)
Michael
--
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/
^ permalink raw reply
* [GIT PATCHES FOR 3.2] add poll_requested_events() function
From: Hans Verkuil @ 2011-10-24 11:57 UTC (permalink / raw)
To: linux-media
Cc: Andrew Morton, Jonathan Corbet, viro, linux-fsdevel, linux-kernel
Since there have been no more comment on RFCv4 of this patch series
(http://comments.gmane.org/gmane.linux.kernel/1196926), I'm posting this
pull request for v3.2.
I never received any acks or comments from Al Viro (or anyone else from
linux-fsdevel for that matter), so I'm following Andrew's suggestion and I just
go ahead with this.
This series should be pulled in via the media git repository since the media
drivers are the primary users of the new poll_requested_events() function.
Regards,
Hans
The following changes since commit a63366b935456dd0984f237642f6d4001dcf8017:
[media] mxl111sf: update demod_ops.info.name to "MaxLinear MxL111SF DVB-T demodulator" (2011-10-24
03:20:09 +0200)
are available in the git repository at:
ssh://linuxtv.org/git/hverkuil/media_tree.git pollv3
Hans Verkuil (6):
poll: add poll_requested_events() function
ivtv: only start streaming in poll() if polling for input.
videobuf2: only start streaming in poll() if so requested by the poll mask.
videobuf: only start streaming in poll() if so requested by the poll mask.
videobuf2-core: also test for pending events.
vivi: let vb2_poll handle events.
drivers/media/video/ivtv/ivtv-fileops.c | 6 ++-
drivers/media/video/videobuf-core.c | 3 +-
drivers/media/video/videobuf2-core.c | 48 +++++++++++++++++++++---------
drivers/media/video/vivi.c | 9 +-----
fs/eventpoll.c | 18 +++++++++--
fs/select.c | 38 +++++++++++-------------
include/linux/poll.h | 13 ++++++++-
7 files changed, 84 insertions(+), 51 deletions(-)
^ permalink raw reply
* Re: [RFC 4/4] watchdog: imx2: simplify resource allocation
From: Grant Likely @ 2011-10-24 11:56 UTC (permalink / raw)
To: Wolfram Sang; +Cc: linux-kernel, linux-arm-kernel, Greg KH, Tejun Heo
In-Reply-To: <1319445729-14841-5-git-send-email-w.sang@pengutronix.de>
On Mon, Oct 24, 2011 at 10:42:09AM +0200, Wolfram Sang wrote:
> Use the new devm_resource_to_mapped_ptr function to simplify the code
> and standardize the error-handling. Silently fixes a wrong type for the
> resource_size variable as well.
>
> Signed-off-by: Wolfram Sang <w.sang@pengutronix.de>
> ---
> drivers/watchdog/imx2_wdt.c | 22 +++-------------------
> 1 files changed, 3 insertions(+), 19 deletions(-)
w00t! I can see a lot of drivers simplified by using this.
g.
>
> diff --git a/drivers/watchdog/imx2_wdt.c b/drivers/watchdog/imx2_wdt.c
> index b8ef2c6..1fc6714 100644
> --- a/drivers/watchdog/imx2_wdt.c
> +++ b/drivers/watchdog/imx2_wdt.c
> @@ -247,28 +247,12 @@ static struct miscdevice imx2_wdt_miscdev = {
> static int __init imx2_wdt_probe(struct platform_device *pdev)
> {
> int ret;
> - int res_size;
> struct resource *res;
>
> res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> - if (!res) {
> - dev_err(&pdev->dev, "can't get device resources\n");
> - return -ENODEV;
> - }
> -
> - res_size = resource_size(res);
> - if (!devm_request_mem_region(&pdev->dev, res->start, res_size,
> - res->name)) {
> - dev_err(&pdev->dev, "can't allocate %d bytes at %d address\n",
> - res_size, res->start);
> - return -ENOMEM;
> - }
> -
> - imx2_wdt.base = devm_ioremap_nocache(&pdev->dev, res->start, res_size);
> - if (!imx2_wdt.base) {
> - dev_err(&pdev->dev, "ioremap failed\n");
> - return -ENOMEM;
> - }
> + ret = devm_resource_to_mapped_ptr(&pdev->dev, res, &imx2_wdt.base);
> + if (ret)
> + return ret;
>
> imx2_wdt.clk = clk_get(&pdev->dev, NULL);
> if (IS_ERR(imx2_wdt.clk)) {
> --
> 1.7.6.3
>
^ permalink raw reply
* Re: [PATCH] staging:iio:iio_utils.h: Add missing include
From: Jonathan Cameron @ 2011-10-24 11:57 UTC (permalink / raw)
To: Lars-Peter Clausen
Cc: Michael Hennerich, linux-iio, device-drivers-devel, drivers
In-Reply-To: <1319457376-16397-1-git-send-email-lars@metafoo.de>
On 10/24/11 12:56, Lars-Peter Clausen wrote:
> iio_utils.h uses opendir and friends which need dirent.h
>
> Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Acked-by: Jonathan Cameron <jic23@cam.ac.uk>
> ---
> drivers/staging/iio/Documentation/iio_utils.h | 1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/staging/iio/Documentation/iio_utils.h b/drivers/staging/iio/Documentation/iio_utils.h
> index 75938b2..dbbad8a 100644
> --- a/drivers/staging/iio/Documentation/iio_utils.h
> +++ b/drivers/staging/iio/Documentation/iio_utils.h
> @@ -13,6 +13,7 @@
> #include <ctype.h>
> #include <stdio.h>
> #include <stdint.h>
> +#include <dirent.h>
>
> #define IIO_MAX_NAME_LENGTH 30
>
^ permalink raw reply
* [RFC 4/4] watchdog: imx2: simplify resource allocation
From: Grant Likely @ 2011-10-24 11:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1319445729-14841-5-git-send-email-w.sang@pengutronix.de>
On Mon, Oct 24, 2011 at 10:42:09AM +0200, Wolfram Sang wrote:
> Use the new devm_resource_to_mapped_ptr function to simplify the code
> and standardize the error-handling. Silently fixes a wrong type for the
> resource_size variable as well.
>
> Signed-off-by: Wolfram Sang <w.sang@pengutronix.de>
> ---
> drivers/watchdog/imx2_wdt.c | 22 +++-------------------
> 1 files changed, 3 insertions(+), 19 deletions(-)
w00t! I can see a lot of drivers simplified by using this.
g.
>
> diff --git a/drivers/watchdog/imx2_wdt.c b/drivers/watchdog/imx2_wdt.c
> index b8ef2c6..1fc6714 100644
> --- a/drivers/watchdog/imx2_wdt.c
> +++ b/drivers/watchdog/imx2_wdt.c
> @@ -247,28 +247,12 @@ static struct miscdevice imx2_wdt_miscdev = {
> static int __init imx2_wdt_probe(struct platform_device *pdev)
> {
> int ret;
> - int res_size;
> struct resource *res;
>
> res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> - if (!res) {
> - dev_err(&pdev->dev, "can't get device resources\n");
> - return -ENODEV;
> - }
> -
> - res_size = resource_size(res);
> - if (!devm_request_mem_region(&pdev->dev, res->start, res_size,
> - res->name)) {
> - dev_err(&pdev->dev, "can't allocate %d bytes at %d address\n",
> - res_size, res->start);
> - return -ENOMEM;
> - }
> -
> - imx2_wdt.base = devm_ioremap_nocache(&pdev->dev, res->start, res_size);
> - if (!imx2_wdt.base) {
> - dev_err(&pdev->dev, "ioremap failed\n");
> - return -ENOMEM;
> - }
> + ret = devm_resource_to_mapped_ptr(&pdev->dev, res, &imx2_wdt.base);
> + if (ret)
> + return ret;
>
> imx2_wdt.clk = clk_get(&pdev->dev, NULL);
> if (IS_ERR(imx2_wdt.clk)) {
> --
> 1.7.6.3
>
^ permalink raw reply
* Re: [PATCH] sparse, llvm: Fix 'void *' pointer code generation
From: Pekka Enberg @ 2011-10-24 11:56 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Pekka Enberg, linux-sparse, Christopher Li, Jeff Garzik
In-Reply-To: <CA+55aFx1=9C_QDE2CfqLp1zg_t=x+VjKUPZgj2karJsS1FAZaA@mail.gmail.com>
On Mon, Oct 24, 2011 at 1:43 PM, Pekka Enberg <penberg@kernel.org> wrote:
>> Fix the issue by switching to LLVMIntType(bits_per_pointer) in
>> sym_basetype_type().
On Mon, 24 Oct 2011, Linus Torvalds wrote:
> Why bits_per_pointer? Isn't this the "base type" of void *? A more
> logical choice would seem to be to make it equivalent to "char *", and
> just make it fall through to the "case 8" case?
Indeed. Updated patch below.
Pekka
From f90242c21b21d91cfed57aa050b4726b6060dfdd Mon Sep 17 00:00:00 2001
From: Pekka Enberg <penberg@kernel.org>
Date: Mon, 24 Oct 2011 14:11:13 +0300
Subject: [PATCH] sparse, llvm: Fix 'void *' pointer code generation
Sparse front-end generates SYM_PTR with SYM_BASETYPE with bit_size set to -1
for "void *" pointers. We currently map that to LLVMVoidType() but that no
longer works with LLVM Subversion trunk:
$ ./sparse-llvm validation/backend/struct.c
sparse-llvm: Type.cpp:676: static llvm::PointerType* llvm::PointerType::get(llvm::Type*, unsigned int): Assertion `isValidElementType(EltTy) && "Invalid type for pointer element!"' failed.
Aborted
Fix the issue by switching to LLVMIntType(bits_per_pointer) in
sym_basetype_type().
Cc: Christopher Li <sparse@chrisli.org>
Cc: Jeff Garzik <jgarzik@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Pekka Enberg <penberg@kernel.org>
---
sparse-llvm.c | 4 +---
1 files changed, 1 insertions(+), 3 deletions(-)
diff --git a/sparse-llvm.c b/sparse-llvm.c
index a85dfea..fc0c2e9 100644
--- a/sparse-llvm.c
+++ b/sparse-llvm.c
@@ -79,9 +79,7 @@ static LLVMTypeRef sym_basetype_type(struct symbol *sym)
}
} else {
switch (sym->bit_size) {
- case -1:
- ret = LLVMVoidType();
- break;
+ case -1: /* 'void *' is treated like 'char *' */
case 8:
ret = LLVMInt8Type();
break;
--
1.7.6.4
^ permalink raw reply related
* Re: [RFC] [PATCH -rt 5/5] cpufreq: get rid of get_online_cpus()/put_online_cpus()
From: Yong Zhang @ 2011-10-24 11:56 UTC (permalink / raw)
To: Thomas Gleixner; +Cc: linux-kernel, linux-rt-users
In-Reply-To: <alpine.LFD.2.02.1110241343130.2633@ionos>
On Mon, Oct 24, 2011 at 01:45:16PM +0200, Thomas Gleixner wrote:
> On Mon, 24 Oct 2011, Yong Zhang wrote:
> > On Mon, Oct 24, 2011 at 11:24:51AM +0200, Thomas Gleixner wrote:
> > > > No sure whether it's big issue or not.
> > > > Mind showing more about your concern?
> > >
> > > This is probably not the only place which will run into that issue and
> > > I have not much interest to patch all those sites.
> >
> > If so, I think that kind of violation has been caught in mainline,
> > because mainline has had CPU_DOWN_PREPARE called under
> > cpu_hotplug.lock, right?
> >
> > Or am I missing something?
>
> Hmm, no. I obviously forgot that I moved it in RT :(
>
> So yes, it should be safe. Though the question is why cpufreq does not
> suffer from that that problem in mainline.
By this one: peter_zijlstra-fix-cpufreq.patch
Thanks,
Yong
^ permalink raw reply
* Re: [RFC 3/4] lib: devres: add convenience function to remap a resource
From: Grant Likely @ 2011-10-24 11:56 UTC (permalink / raw)
To: Wolfram Sang; +Cc: linux-kernel, linux-arm-kernel, Greg KH, Tejun Heo
In-Reply-To: <1319445729-14841-4-git-send-email-w.sang@pengutronix.de>
On Mon, Oct 24, 2011 at 10:42:08AM +0200, Wolfram Sang wrote:
> Almost every platform_driver does the three steps get_resource,
> request_mem_region, ioremap. This does not only lead to a lot of code
> duplication, but also a number of similar error strings and inconsistent
> error codes on failure. So, introduce a helper function which simplifies
> remapping a resource and make it hard to do something wrong.
>
> A few notes on design choices:
>
> * not 100% sure on ENOENT when the resource is invalid. Seems to be frequently
> used currently and fits "somehow"
>
> * the remapped pointer is a function argument and not a return value. This is to
> save users from forgetting to use IS_ERR/PTR_ERR.
>
> * the usage of IORESOURCE_CACHEABLE enforces calling the correct ioremap-variant.
> A number of drivers miss to call the _nocache-version, although they should do.
>
> * the new function is not named 'devm_ioremap_resource' because it does more than
> just ioremap, namely request_mem_region. I didn't want to create implicit
> knowledge here.
>
> Signed-off-by: Wolfram Sang <w.sang@pengutronix.de>
> ---
> Documentation/driver-model/devres.txt | 1 +
> include/linux/device.h | 3 ++
> lib/devres.c | 52 +++++++++++++++++++++++++++++++++
> 3 files changed, 56 insertions(+), 0 deletions(-)
>
> diff --git a/Documentation/driver-model/devres.txt b/Documentation/driver-model/devres.txt
> index badd964..3aeb4f4 100644
> --- a/Documentation/driver-model/devres.txt
> +++ b/Documentation/driver-model/devres.txt
> @@ -266,6 +266,7 @@ IOMAP
> devm_ioremap()
> devm_ioremap_nocache()
> devm_iounmap()
> + devm_resource_to_mapped_ptr() : checks resource, requests region, ioremaps
> pcim_iomap()
> pcim_iounmap()
> pcim_iomap_table() : array of mapped addresses indexed by BAR
> diff --git a/include/linux/device.h b/include/linux/device.h
> index c20dfbf..82a621c 100644
> --- a/include/linux/device.h
> +++ b/include/linux/device.h
> @@ -481,6 +481,9 @@ extern int devres_release_group(struct device *dev, void *id);
> extern void *devm_kzalloc(struct device *dev, size_t size, gfp_t gfp);
> extern void devm_kfree(struct device *dev, void *p);
>
> +int __must_check devm_resource_to_mapped_ptr(struct device *dev,
> + struct resource *res, void __iomem **dest);
> +
> struct device_dma_parameters {
> /*
> * a low level driver may set these to teach IOMMU code about
> diff --git a/lib/devres.c b/lib/devres.c
> index 78777ae..970588b 100644
> --- a/lib/devres.c
> +++ b/lib/devres.c
> @@ -85,6 +85,58 @@ void devm_iounmap(struct device *dev, void __iomem *addr)
> }
> EXPORT_SYMBOL(devm_iounmap);
>
> +/**
> + * devm_resource_to_mapped_ptr - Check, request region, and ioremap resource
Kernel doc format should have '()' for functions is:
/*
* devm_resource_to_mapped_ptr() - Check, request region, and ioremap resource
> + * @dev: Generic device to handle the resource for
> + * @res: resource to be handled
> + * @dest: Pointer to pointer which carries the remapped address
> + *
> + * Takes all necessary steps to ioremap a mem resource. Uses managed device, so
> + * everything is undone on driver detach. Checks arguments, so you can feed
> + * it the result from e.g. platform_get_resource() directly:
> + *
> + * res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> + * err = devm_resource_to_mapped_ptr(&pdev->dev, res, &priv->regs);
> + * if (err)
> + * return err;
> + */
> +int __must_check devm_resource_to_mapped_ptr(struct device *dev,
> + struct resource *res, void __iomem **dest)
I'm not happy with the API. I understand trying to avoid losing the
error code, but passing back the value in a passed in pointer is
rather horrible to use (as I discovered with the
of_property_read_u32() patches) and it becomes too easy to improperly
use it.
I'd argue that the users of this probably really won't care about the
actual error code. If this function fails, then things are rather
horribly wrong, and it would be entirely appropriate to do rely on the
dev_err() to inform the user of the actual error code.
So, just return the mapped (void __iomem *) value after requesting and
mapping the region, and make exceptional situations exceptional. :-)
Otherwise, I'm quite happy to see this helper. Good work!
g.
> +{
> + resource_size_t size;
> + const char *name;
> +
> + BUG_ON(!dev || !dest);
> +
> + *dest = NULL;
> +
> + if (!res || resource_type(res) != IORESOURCE_MEM) {
> + dev_err(dev, "invalid resource\n");
> + return -ENOENT;
> + }
> +
> + size = resource_size(res);
> + name = res->name ?: dev_name(dev);
> +
> + if (!devm_request_mem_region(dev, res->start, size, name)) {
> + dev_err(dev, "can't request region for resource %pR\n", res);
> + return -EBUSY;
> + }
> +
> + if (res->flags & IORESOURCE_CACHEABLE)
> + *dest = devm_ioremap(dev, res->start, size);
> + else
> + *dest = devm_ioremap_nocache(dev, res->start, size);
> +
> + if (!*dest) {
> + dev_err(dev, "ioremap failed for resource %pR\n", res);
> + return -ENOMEM;
> + }
> +
> + return 0;
> +}
> +EXPORT_SYMBOL(devm_resource_to_mapped_ptr);
> +
> #ifdef CONFIG_HAS_IOPORT
> /*
> * Generic iomap devres
> --
> 1.7.6.3
>
^ permalink raw reply
* [PATCH] staging:iio:iio_utils.h: Add missing include
From: Lars-Peter Clausen @ 2011-10-24 11:56 UTC (permalink / raw)
To: Jonathan Cameron
Cc: Michael Hennerich, linux-iio, device-drivers-devel, drivers,
Lars-Peter Clausen
iio_utils.h uses opendir and friends which need dirent.h
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
---
drivers/staging/iio/Documentation/iio_utils.h | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/staging/iio/Documentation/iio_utils.h b/drivers/staging/iio/Documentation/iio_utils.h
index 75938b2..dbbad8a 100644
--- a/drivers/staging/iio/Documentation/iio_utils.h
+++ b/drivers/staging/iio/Documentation/iio_utils.h
@@ -13,6 +13,7 @@
#include <ctype.h>
#include <stdio.h>
#include <stdint.h>
+#include <dirent.h>
#define IIO_MAX_NAME_LENGTH 30
--
1.7.7
^ permalink raw reply related
* [RFC 3/4] lib: devres: add convenience function to remap a resource
From: Grant Likely @ 2011-10-24 11:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1319445729-14841-4-git-send-email-w.sang@pengutronix.de>
On Mon, Oct 24, 2011 at 10:42:08AM +0200, Wolfram Sang wrote:
> Almost every platform_driver does the three steps get_resource,
> request_mem_region, ioremap. This does not only lead to a lot of code
> duplication, but also a number of similar error strings and inconsistent
> error codes on failure. So, introduce a helper function which simplifies
> remapping a resource and make it hard to do something wrong.
>
> A few notes on design choices:
>
> * not 100% sure on ENOENT when the resource is invalid. Seems to be frequently
> used currently and fits "somehow"
>
> * the remapped pointer is a function argument and not a return value. This is to
> save users from forgetting to use IS_ERR/PTR_ERR.
>
> * the usage of IORESOURCE_CACHEABLE enforces calling the correct ioremap-variant.
> A number of drivers miss to call the _nocache-version, although they should do.
>
> * the new function is not named 'devm_ioremap_resource' because it does more than
> just ioremap, namely request_mem_region. I didn't want to create implicit
> knowledge here.
>
> Signed-off-by: Wolfram Sang <w.sang@pengutronix.de>
> ---
> Documentation/driver-model/devres.txt | 1 +
> include/linux/device.h | 3 ++
> lib/devres.c | 52 +++++++++++++++++++++++++++++++++
> 3 files changed, 56 insertions(+), 0 deletions(-)
>
> diff --git a/Documentation/driver-model/devres.txt b/Documentation/driver-model/devres.txt
> index badd964..3aeb4f4 100644
> --- a/Documentation/driver-model/devres.txt
> +++ b/Documentation/driver-model/devres.txt
> @@ -266,6 +266,7 @@ IOMAP
> devm_ioremap()
> devm_ioremap_nocache()
> devm_iounmap()
> + devm_resource_to_mapped_ptr() : checks resource, requests region, ioremaps
> pcim_iomap()
> pcim_iounmap()
> pcim_iomap_table() : array of mapped addresses indexed by BAR
> diff --git a/include/linux/device.h b/include/linux/device.h
> index c20dfbf..82a621c 100644
> --- a/include/linux/device.h
> +++ b/include/linux/device.h
> @@ -481,6 +481,9 @@ extern int devres_release_group(struct device *dev, void *id);
> extern void *devm_kzalloc(struct device *dev, size_t size, gfp_t gfp);
> extern void devm_kfree(struct device *dev, void *p);
>
> +int __must_check devm_resource_to_mapped_ptr(struct device *dev,
> + struct resource *res, void __iomem **dest);
> +
> struct device_dma_parameters {
> /*
> * a low level driver may set these to teach IOMMU code about
> diff --git a/lib/devres.c b/lib/devres.c
> index 78777ae..970588b 100644
> --- a/lib/devres.c
> +++ b/lib/devres.c
> @@ -85,6 +85,58 @@ void devm_iounmap(struct device *dev, void __iomem *addr)
> }
> EXPORT_SYMBOL(devm_iounmap);
>
> +/**
> + * devm_resource_to_mapped_ptr - Check, request region, and ioremap resource
Kernel doc format should have '()' for functions is:
/*
* devm_resource_to_mapped_ptr() - Check, request region, and ioremap resource
> + * @dev: Generic device to handle the resource for
> + * @res: resource to be handled
> + * @dest: Pointer to pointer which carries the remapped address
> + *
> + * Takes all necessary steps to ioremap a mem resource. Uses managed device, so
> + * everything is undone on driver detach. Checks arguments, so you can feed
> + * it the result from e.g. platform_get_resource() directly:
> + *
> + * res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> + * err = devm_resource_to_mapped_ptr(&pdev->dev, res, &priv->regs);
> + * if (err)
> + * return err;
> + */
> +int __must_check devm_resource_to_mapped_ptr(struct device *dev,
> + struct resource *res, void __iomem **dest)
I'm not happy with the API. I understand trying to avoid losing the
error code, but passing back the value in a passed in pointer is
rather horrible to use (as I discovered with the
of_property_read_u32() patches) and it becomes too easy to improperly
use it.
I'd argue that the users of this probably really won't care about the
actual error code. If this function fails, then things are rather
horribly wrong, and it would be entirely appropriate to do rely on the
dev_err() to inform the user of the actual error code.
So, just return the mapped (void __iomem *) value after requesting and
mapping the region, and make exceptional situations exceptional. :-)
Otherwise, I'm quite happy to see this helper. Good work!
g.
> +{
> + resource_size_t size;
> + const char *name;
> +
> + BUG_ON(!dev || !dest);
> +
> + *dest = NULL;
> +
> + if (!res || resource_type(res) != IORESOURCE_MEM) {
> + dev_err(dev, "invalid resource\n");
> + return -ENOENT;
> + }
> +
> + size = resource_size(res);
> + name = res->name ?: dev_name(dev);
> +
> + if (!devm_request_mem_region(dev, res->start, size, name)) {
> + dev_err(dev, "can't request region for resource %pR\n", res);
> + return -EBUSY;
> + }
> +
> + if (res->flags & IORESOURCE_CACHEABLE)
> + *dest = devm_ioremap(dev, res->start, size);
> + else
> + *dest = devm_ioremap_nocache(dev, res->start, size);
> +
> + if (!*dest) {
> + dev_err(dev, "ioremap failed for resource %pR\n", res);
> + return -ENOMEM;
> + }
> +
> + return 0;
> +}
> +EXPORT_SYMBOL(devm_resource_to_mapped_ptr);
> +
> #ifdef CONFIG_HAS_IOPORT
> /*
> * Generic iomap devres
> --
> 1.7.6.3
>
^ permalink raw reply
* Re: [PATCH] staging:iio:events: Make sure userspace buffer is large enough
From: Jonathan Cameron @ 2011-10-24 11:55 UTC (permalink / raw)
To: Lars-Peter Clausen
Cc: Michael Hennerich, linux-iio, device-drivers-devel, drivers
In-Reply-To: <1319457163-15889-1-git-send-email-lars@metafoo.de>
On 10/24/11 12:52, Lars-Peter Clausen wrote:
> Make sure that the userspace buffer is large enough to hold a iio_event_data
> struct before writing to it.
>
Good catch. Shall I tack this on the end of the two fixes sets I sent earlier?
> Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Acked-by: Jonathan Cameron <jic23@cam.ac.uk>
> ---
> drivers/staging/iio/industrialio-core.c | 6 ++++--
> 1 files changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/staging/iio/industrialio-core.c b/drivers/staging/iio/industrialio-core.c
> index 74904f1..733e83a 100644
> --- a/drivers/staging/iio/industrialio-core.c
> +++ b/drivers/staging/iio/industrialio-core.c
> @@ -169,8 +169,11 @@ static ssize_t iio_event_chrdev_read(struct file *filep,
> {
> struct iio_event_interface *ev_int = filep->private_data;
> struct iio_detected_event_list *el;
> + size_t len = sizeof(el->ev);
> int ret;
> - size_t len;
> +
> + if (count < len)
> + return -EINVAL;
>
> mutex_lock(&ev_int->event_list_lock);
> if (list_empty(&ev_int->det_events)) {
> @@ -192,7 +195,6 @@ static ssize_t iio_event_chrdev_read(struct file *filep,
> el = list_first_entry(&ev_int->det_events,
> struct iio_detected_event_list,
> list);
> - len = sizeof el->ev;
> if (copy_to_user(buf, &(el->ev), len)) {
> ret = -EFAULT;
> goto error_mutex_unlock;
^ permalink raw reply
* Re: [PATCH] sparse, llvm: Fix 'void *' pointer code generation
From: Linus Torvalds @ 2011-10-24 11:52 UTC (permalink / raw)
To: Pekka Enberg; +Cc: linux-sparse, Christopher Li, Jeff Garzik
In-Reply-To: <1319456619-11546-1-git-send-email-penberg@kernel.org>
On Mon, Oct 24, 2011 at 1:43 PM, Pekka Enberg <penberg@kernel.org> wrote:
>
> Fix the issue by switching to LLVMIntType(bits_per_pointer) in
> sym_basetype_type().
Why bits_per_pointer? Isn't this the "base type" of void *? A more
logical choice would seem to be to make it equivalent to "char *", and
just make it fall through to the "case 8" case?
Linus
^ permalink raw reply
* [U-Boot] ====Attn: business assistance is needed in Asia very urgent====
From: TINA SAMSON @ 2011-10-24 11:52 UTC (permalink / raw)
To: u-boot
--
Firstly,i will like to introduce my self to you.I am Mrs.Tina Samson,I'm
from United Kingdom (England). I'm current working as the procurement
manager to OAK VET LTD, I need the correspondence of a reliable Business
partner. A trust worthy person that can handle business for me in Asia.
Your urgent responds is of great kind.
Regards
Mrs.Tina Samson
^ permalink raw reply
* [PATCH] staging:iio:events: Make sure userspace buffer is large enough
From: Lars-Peter Clausen @ 2011-10-24 11:52 UTC (permalink / raw)
To: Jonathan Cameron
Cc: Michael Hennerich, linux-iio, device-drivers-devel, drivers,
Lars-Peter Clausen
Make sure that the userspace buffer is large enough to hold a iio_event_data
struct before writing to it.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
---
drivers/staging/iio/industrialio-core.c | 6 ++++--
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/iio/industrialio-core.c b/drivers/staging/iio/industrialio-core.c
index 74904f1..733e83a 100644
--- a/drivers/staging/iio/industrialio-core.c
+++ b/drivers/staging/iio/industrialio-core.c
@@ -169,8 +169,11 @@ static ssize_t iio_event_chrdev_read(struct file *filep,
{
struct iio_event_interface *ev_int = filep->private_data;
struct iio_detected_event_list *el;
+ size_t len = sizeof(el->ev);
int ret;
- size_t len;
+
+ if (count < len)
+ return -EINVAL;
mutex_lock(&ev_int->event_list_lock);
if (list_empty(&ev_int->det_events)) {
@@ -192,7 +195,6 @@ static ssize_t iio_event_chrdev_read(struct file *filep,
el = list_first_entry(&ev_int->det_events,
struct iio_detected_event_list,
list);
- len = sizeof el->ev;
if (copy_to_user(buf, &(el->ev), len)) {
ret = -EFAULT;
goto error_mutex_unlock;
--
1.7.7
^ permalink raw reply related
* [U-Boot] [RFC] [PATCH 00/39] Rework of the debug() macro
From: Detlev Zundel @ 2011-10-24 11:52 UTC (permalink / raw)
To: u-boot
In-Reply-To: <201110241216.43763.marek.vasut@gmail.com>
Hi Marek,
[...]
> I certainly see your point. Btw. do you feel like help reviewing the PPC portion
> of the patches? That'd be greatly appreciated as I'm not a PPC expert. I wanted
> to avoid resubmission, so I only pushed the new set to git://git.denx.de/u-boot-
> marex.git / debug branch. There is over 50 patches now.
I fear that we have the possibility to loose efforts in communicating
our distrubuted efforts here. If want to ack only a subset of the
patches only available on a git tree, I don't know how to give my
"Acked-By" through the patchwork magic and _not_ add even more work on
your shoulders. On the other hand, the majority of fixes are printf
fixes, so if the compiler does not complain on a MAKEALL any more, I
don't see what other aspect I can evaluate on a "dry review".
Effectively I was hoping that your large patch set stabilizes and
produces no more warnings on a MAKEALL - in this case you have my
Acked-by: Detlev Zundel <dzu@denx.de>
Let me know if you have any better ideas...
Cheers
Detlev
--
Referee's report: This paper contains much that is new and much that
is true. Unfortunately, that which is true is not new and that which
is new is not true.
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: dzu at denx.de
^ permalink raw reply
* Re: Kernel BUG unable to handle kernel NULL pointer dereference
From: David Sterba @ 2011-10-24 11:51 UTC (permalink / raw)
To: Leonidas Spyropoulos; +Cc: dsterba, Mitch Harder, linux-btrfs
In-Reply-To: <CAAeznTpSsKSMe7udHH1kZmFNg6ROf4czxriNpPh_Trb_PHbtzg@mail.gmail.com>
On Mon, Oct 24, 2011 at 12:33:05PM +0100, Leonidas Spyropoulos wrote:
> Here is it, it's big and contains usless information..
>
> http://paste.pocoo.org/show/497299/
not all that useless ... I saw another BUG earlier than the one you've
reported:
[31653.267742] ------------[ cut here ]------------
[31653.267764] kernel BUG at fs/btrfs/extent-tree.c:5510!
[31653.267773] invalid opcode: 0000 [#1] PREEMPT SMP
[31653.267785] CPU 1
[31653.267790] Modules linked in: vboxdrv ipv6 loop fuse adt7475 hwmon_vid nouveau evdev uvcvideo hid_apple ttm videodev drm_kms_helper media v4l2_compat_ioctl32 drm snd_emu10k1 i2c_algo_bit mxm_wmi wmi pcspkr snd_rawmidi snd_seq_device firewire_ohci emu10k1_gp edac_core psmouse snd_util_mem edac_mce_amd k8temp firewire_core gameport snd_hwdep video serio_raw crc_itu_t sg snd_intel8x0 snd_ac97_codec usbhid ac97_bus snd_pcm snd_timer hid snd floppy i2c_nforce2 thermal processor fan button soundcore i2c_core snd_page_alloc forcedeth btrfs zlib_deflate crc32c libcrc32c ext4 jbd2 crc16 ext3 jbd mbcache ohci_hcd ehci_hcd usbcore sr_mod sd_mod cdrom sata_nv pata_amd libata scsi_mod
[31653.267989]
[31653.267995] Pid: 726, comm: btrfs-transacti Not tainted 3.0-ARCH #1 /LP UT NF4 Expert
[31653.268011] RIP: 0010:[<ffffffffa01a6263>] [<ffffffffa01a6263>] run_clustered_refs+0x813/0x830 [btrfs]
[31653.268045] RSP: 0018:ffff88013469bc70 EFLAGS: 00010286
[31653.268286] RAX: 00000000ffffffe4 RBX: ffff88012e406900 RCX: ffff8801378a6100
[31653.268296] RDX: ffff88011513a0f0 RSI: 0000000000000000 RDI: 0000000000000000
[31653.268306] RBP: ffff88013469bd50 R08: ffffffffffffffff R09: 0000000000000000
[31653.268315] R10: ffff8801346f9800 R11: ffff88013735d3f0 R12: ffff8800a9bc7f00
[31653.268325] R13: ffff88007b1d7e40 R14: ffff88011bd1e4b0 R15: 0000000000000000
[31653.268341] FS: 00007f8dcc527880(0000) GS:ffff88013fd00000(0000) knlGS:00000000f67567f0
[31653.268367] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
[31653.268380] CR2: 00007f9059631550 CR3: 00000000a499c000 CR4: 00000000000006e0
[31653.268394] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[31653.268409] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[31653.268424] Process btrfs-transacti (pid: 726, threadinfo ffff88013469a000, task ffff880136c140b0)
[31653.268443] Stack:
[31653.268449] 0000000000000000 0000000000000000 ffff880100000001 0000000000000000
[31653.268473] 0000000000000c2e 00000000a01dc529 0000000000000000 0000000000000002
[31653.268495] 0000000000000b9f 0000000000000c04 0000000000000000 ffff88013469bd90
[31653.268515] Call Trace:
[31653.268531] [<ffffffffa01a6348>] btrfs_run_delayed_refs+0xc8/0x220 [btrfs]
[31653.268549] [<ffffffffa019421a>] ? btrfs_free_path+0x2a/0x40 [btrfs]
[31653.268568] [<ffffffffa01b86c3>] btrfs_commit_transaction+0x3c3/0x8a0 [btrfs]
[31653.268581] [<ffffffff8107f790>] ? abort_exclusive_wait+0xb0/0xb0
[31653.268598] [<ffffffffa01b13ed>] transaction_kthread+0x26d/0x290 [btrfs]
[31653.268617] [<ffffffffa01b1180>] ? btrfs_congested_fn+0xd0/0xd0 [btrfs]
[31653.268627] [<ffffffff8107ee3c>] kthread+0x8c/0xa0
[31653.268638] [<ffffffff813f5d64>] kernel_thread_helper+0x4/0x10
[31653.268647] [<ffffffff8107edb0>] ? kthread_worker_fn+0x190/0x190
[31653.268657] [<ffffffff813f5d60>] ? gs_change+0x13/0x13
[31653.268673] Code: e0 e9 12 f9 ff ff 0f 0b 80 fa b2 0f 84 bc f9 ff ff 0f 0b be 95 00 00 00 48 c7 c7 37 d0 20 a0 e8 54 65 eb e0 e9 04 f9 ff ff 0f 0b <0f> 0b 0f 0b 0f 0b 0f 0b 0f 0b 0f 0b 0f 0b 66 66 66 66 66 66 2e
[31653.268928] RIP [<ffffffffa01a6263>] run_clustered_refs+0x813/0x830 [btrfs]
[31653.268956] RSP <ffff88013469bc70>
[31653.284196] ---[ end trace d5d8ee7634d1c36e ]---
and it looks related to the print_leaf bug later (eg. mentiones same functions
in the stacktrace and happens during commit).
And judging from the rest of BUG's in the paste, the filesystem is in a bad
shape. Some BUG_ON's seem to be triggered by ENOSPC (RAX containing 0xfff..e4).
david
^ permalink raw reply
* Re: [Multipath] Round-robin performance limit
From: Pasi Kärkkäinen @ 2011-10-24 11:50 UTC (permalink / raw)
To: device-mapper development; +Cc: jsullivan
In-Reply-To: <20111022150247.GF12984@reaktio.net>
On Sat, Oct 22, 2011 at 06:02:47PM +0300, Pasi Kärkkäinen wrote:
> On Wed, Oct 05, 2011 at 03:54:35PM -0400, Adam Chasen wrote:
> > John,
> > I am limited in a similar fashion. I would much prefer to use multibus
> > multipath, but was unable to achieve bandwidth which would exceed a
> > single link even though it was spread over the 4 available links. Were
> > you able to gain even a similar performance of the RAID0 setup with
> > the multibus multipath?
> >
>
> Utilizing multiple links works with for example this setup:
> - VMware ESXi 4.1 software iSCSI initiator.
> - Dell Equallogic iSCSI target.
>
> The steps needed for ESXi are:
> - Configure multiple VMkernel (vmkX) IP interfaces.
And I forgot to write this:
- Bind the vmkX interfaces to portgroups that use dedicated NICs.
> - Configure ESXi iscsi initiator to use (bind to) all the vmkX interfaces.
> - Configure the path selection policy to be RR (RoundRobin).
> - Configure multipath to switch paths after 3 IOs.
>
>
> The same should work with Linux dm-multipath.
>
>
That should be it.
-- Pasi
>
> > Thanks,
> > Adam
> >
> > On Tue, Oct 4, 2011 at 11:07 PM, John A. Sullivan III
> > <jsullivan@opensourcedevel.com> wrote:
> > > On Tue, 2011-10-04 at 16:19 -0400, Adam Chasen wrote:
> > >> Unfortunately even with playing around with various settings, queues,
> > >> and other techniques, I was never able to exceed the bandwidth of more
> > >> than one of the Ethernet links when accessing a single multipathed
> > >> LUN.
> > >>
> > >> When communicating with two different multipathed LUNs, which present
> > >> as two different multipath devices, I can saturate two links, but it
> > >> is still a one to one ratio of multipath devices to link saturation.
> > >>
> > >> After further research on multipathing, it appears people are using md
> > >> raid to achieve multipathed devices. My initial testing of using raid0
> > >> md-raid device produces the behavior I expect of multipathed devices.
> > >> I can easily saturate both links during read operations.
> > >>
> > >> I feel using md-raid is a less elegant solution than using
> > >> dm-multipath, but it will have to suffice until someone can provide me
> > >> some additional guidance.
> > >>
> > >> Thanks,
> > >> Adam
> > > We recently changed from the RAID0 approach to multipath multibus.
> > > RAID0 did seem to give more even performance over a variety of IO
> > > patterns but it had a critical flaw. We could not use the snapshot
> > > capabilities of the SAN because we could never be certain of
> > > snapshotting the RAID0 disks in a transactionally consistent state. If
> > > I have four disk in a RAID0 array and snapshot them all, how can I be
> > > assured that I have not done something like written two of three stripes
> > > and no parity. This was our singular reason for discarding RAID0 over
> > > iSCSI for multipath multibus - John
> > >
> > >>
> > >> On Mon, Oct 3, 2011 at 11:08 PM, Adam Chasen <adam@chasen.name> wrote:
> > >> > Malahal,
> > >> > After your mentioning bio vs request based I attempted to determine if
> > >> > my kernel contains the request based mpath. It seems in 2.6.31 all
> > >> > mpath was switched to request based. I have a kernel 2.6.31+ (actually
> > >> > .35 and .38), so I believe I have requrest-based mpath.
> > >> >
> > >> > All,
> > >> > There also appears to be a new multipath configuration option
> > >> > documented in the RHEL 6 beta documentation:
> > >> > rr_min_io_rq Specifies the number of I/O requests to route to a path
> > >> > before switching to the next path in the current path group, using
> > >> > request-based device-mapper-multipath. This setting should be used on
> > >> > systems running current kernels. On systems running kernels older than
> > >> > 2.6.31, use rr_min_io. The default value is 1.
> > >> >
> > >> > http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6-Beta/html/DM_Multipath/config_file_multipath.html
> > >> >
> > >> > I have not tested using this setting vs rr_min_io yet or even if my
> > >> > system supports the configuration directive.
> > >> >
> > >> > If I trust some of the claims of several VMware ESX iscsi multipath
> > >> > setups, it is possible (possibly using different software) to gain a
> > >> > multiplicative throughput by adding additional Ethernet links. This
> > >> > makes me hopeful that we can do this with open-iscsi and dm-mulitpath
> > >> > as well.
> > >> >
> > >> > It could be something obvious I am missing, but it appears a lot of
> > >> > people experience this same issue.
> > >> >
> > >> > Thanks,
> > >> > Adam
> > >> >
> > >> > On Tue, May 3, 2011 at 6:12 AM, John A. Sullivan III
> > >> > <jsullivan@opensourcedevel.com> wrote:
> > >> >> On Mon, 2011-05-02 at 22:04 -0700, Malahal Naineni wrote:
> > >> >>> John A. Sullivan III [jsullivan@opensourcedevel.com] wrote:
> > >> >>> > I'm also very curious about your findings on rr_min_io. I cannot find
> > >> >>> > my benchmarks but we tested various settings heavily. I do not recall
> > >> >>> > if we saw more even scaling with 10 or 100. I remember being surprised
> > >> >>> > that performance with it set to 1 was poor. I would have thought that,
> > >> >>> > in a bonded environment, changing paths per iSCSI command would give
> > >> >>> > optimal performance. Can anyone explain why it does not?
> > >> >>>
> > >> >>> rr_min_io of 1 will give poor performance if your multipath kernel
> > >> >>> module doesn't support request based multipath. In those BIO based
> > >> >>> multipath, multipath receives 4KB requests. Such requests can't be
> > >> >>> coalesced if they are sent on different paths.
> > >> >> <snip>
> > >> >> Ah, that makes perfect sense and why 3 seems to be the magic number in
> > >> >> Linux (4000 / 1460 (or whatever IP payload is)). Does that change with
> > >> >> Jumbo frames? In fact, how would that be optimized in Linux?
> > >> >>
> > >> >> 9KB seems to be a reasonable common jumbo frame value for various
> > >> >> vendors and that should contain two pages but, I would guess, Linux
> > >> >> can't utilize it as each block must be independently acknowledged. Is
> > >> >> that correct? Thus a frame size of a little over 4KB would be optimal
> > >> >> for Linux?
> > >> >>
> > >> >> Would that mean that rr_min_io of 1 would become optimal? However, if
> > >> >> each block needs to be acknowledged before the next is sent, I would
> > >> >> think we are still latency bound, i.e., even if I can send four requests
> > >> >> down four separate paths, I cannot send the second until the first has
> > >> >> been acknowledged and since I can easily place four packets on the same
> > >> >> path within the latency period of four packets, multibus gives me
> > >> >> absolutely no performance advantage for a single iSCSI stream and only
> > >> >> proves useful as I start multiplexing multiple iSCSI streams.
> > >> >>
> > >> >> Is that analysis correct? If so, what constitutes a separate iSCSI
> > >> >> stream? Are two separate file requests from the same file systems to the
> > >> >> same iSCSI device considered two iSCSI streams and thus can be
> > >> >> multiplexed and benefit from multipath or are they considered all part
> > >> >> of the same iSCSI stream? If they are considered one, do they become two
> > >> >> if they reside on different partitions and thus different file systems?
> > >> >> If not, then do we only see multibus performance gains between a single
> > >> >> file system host and a single iSCSI host when we use virtualization each
> > >> >> with their own iSCSI connection (as opposed to using iSCSI connections
> > >> >> in the underlying host and exposing them to the virtual machines as
> > >> >> local storage)?
> > >> >>
> > >> >> I hope I'm not hijacking this thread and realize I've asked some
> > >> >> convoluted questions but optimizing multibus through bonded links for
> > >> >> single large hosts is still a bit of a mystery to me. Thanks - John
> > >> >>
> > >> >> --
> > >> >> dm-devel mailing list
> > >> >> dm-devel@redhat.com
> > >> >> https://www.redhat.com/mailman/listinfo/dm-devel
> > >> >>
> > >> >
> > >>
> > >> --
> > >> dm-devel mailing list
> > >> dm-devel@redhat.com
> > >> https://www.redhat.com/mailman/listinfo/dm-devel
> > >
> > >
> > > --
> > > dm-devel mailing list
> > > dm-devel@redhat.com
> > > https://www.redhat.com/mailman/listinfo/dm-devel
> > >
> >
> > --
> > dm-devel mailing list
> > dm-devel@redhat.com
> > https://www.redhat.com/mailman/listinfo/dm-devel
>
> --
> dm-devel mailing list
> dm-devel@redhat.com
> https://www.redhat.com/mailman/listinfo/dm-devel
^ permalink raw reply
* Re: [PATCH bluez] add get_le/get_be helpers
From: Marcel Holtmann @ 2011-10-24 11:50 UTC (permalink / raw)
To: Vinicius Gomes; +Cc: Emeltchenko Andrei, linux-bluetooth
In-Reply-To: <CAE6HaMkxvTPa1eTj1Og7Lvqn=PvieuKJyzugPouwiUTOsnnW_g@mail.gmail.com>
Hi Vinicius,
> Sorry if this comes too late, but here's an idea:
>
> How about changing the name of the functions to something a little
> more high level, for example: in attrib/att.h we have
> att_{get,put}_u16() that uses the byte order defined in the ATT spec
> (little endian).
>
> So my suggestion is to have bt_{get,put}_u*() and sdp_{get,put}_u*
> functions (perhaps also no_{get,put}_u* for cases when we use the host
> byte order). The bt_ functions will be used for everything that uses
> the Bluetooth byte order and the sdp_ ones for SDP, which is the only
> case of Big Endian defined by Bluetooth, correct me if I am wrong.
lets not try to be too smart. We want the code clearly identify what
endian is expected. Same as the kernel handles this.
Regards
Marcel
^ permalink raw reply
* Re: [PATCH] mmc: mmci: Improve runtime PM support
From: Linus Walleij @ 2011-10-24 11:49 UTC (permalink / raw)
To: Ulf Hansson
Cc: Russell King - ARM Linux, Sebastian Rasmussen,
linux-mmc@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
Lee Jones
In-Reply-To: <4EA53B1D.9090208@stericsson.com>
On Mon, Oct 24, 2011 at 12:17 PM, Ulf Hansson
<ulf.hansson@stericsson.com> wrote:
> Russell King - ARM Linux wrote:
>> On Mon, Oct 24, 2011 at 11:54:00AM +0200, Linus Walleij wrote:
>>>
>>> It's 8 cycles on MCLK required.
>>
>> _Plus_ keeping the clock running while the card is signalling busy.
>>
>> If you don't clock the card while its signalling busy, it will never
>> go non-busy (the data line becomes frozen.)
>>
>
> (...)
> Is the aggressive clk gating feature in the mmc framework taking this into
> account as well?
Nope.
That is why frequency 0 is not handled like some special case in the
MMCI driver, which means you can turn it on but nothing spectacularly
power saving will happen. (i.e. clock gating does not gate the clock
on the mmci driver) I did a rough patch to cut the clock
but Russell pointed out the problem here (same as discussed above):
http://marc.info/?l=linux-mmc&m=129146545916794&w=2
I *was* meaning to fix it. However now I feel that since we're
anyway ironing out the painful details of runtime PM, we can
probably use that framework to handle also aggressive clock
gating.
> Potentially the framework could do a get_sync/put (in claim/release host) to
> prevent hosts from being runtime disabled. Similar how the enable/disable
> mechanism is working.
Yep. We just need to make sure the hysteresis/delay value covers
the bus activity with some margin.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH] mmc: mmci: Improve runtime PM support
From: Linus Walleij @ 2011-10-24 11:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4EA53B1D.9090208@stericsson.com>
On Mon, Oct 24, 2011 at 12:17 PM, Ulf Hansson
<ulf.hansson@stericsson.com> wrote:
> Russell King - ARM Linux wrote:
>> On Mon, Oct 24, 2011 at 11:54:00AM +0200, Linus Walleij wrote:
>>>
>>> It's 8 cycles on MCLK required.
>>
>> _Plus_ keeping the clock running while the card is signalling busy.
>>
>> If you don't clock the card while its signalling busy, it will never
>> go non-busy (the data line becomes frozen.)
>>
>
> (...)
> Is the aggressive clk gating feature in the mmc framework taking this into
> account as well?
Nope.
That is why frequency 0 is not handled like some special case in the
MMCI driver, which means you can turn it on but nothing spectacularly
power saving will happen. (i.e. clock gating does not gate the clock
on the mmci driver) I did a rough patch to cut the clock
but Russell pointed out the problem here (same as discussed above):
http://marc.info/?l=linux-mmc&m=129146545916794&w=2
I *was* meaning to fix it. However now I feel that since we're
anyway ironing out the painful details of runtime PM, we can
probably use that framework to handle also aggressive clock
gating.
> Potentially the framework could do a get_sync/put (in claim/release host) to
> prevent hosts from being runtime disabled. Similar how the enable/disable
> mechanism is working.
Yep. We just need to make sure the hysteresis/delay value covers
the bus activity with some margin.
Yours,
Linus Walleij
^ permalink raw reply
* Re: [GIT PULL rcu/next] RCU commits for 3.1
From: Paul E. McKenney @ 2011-10-24 11:48 UTC (permalink / raw)
To: Ingo Molnar
Cc: eric.dumazet, shaohua.li, ak, mhocko, alex.shi, efault,
linux-kernel
In-Reply-To: <20111024100501.GA24913@linux.vnet.ibm.com>
On Mon, Oct 24, 2011 at 03:05:01AM -0700, Paul E. McKenney wrote:
> On Tue, Oct 04, 2011 at 09:46:37AM +0200, Ingo Molnar wrote:
> >
> > * Paul E. McKenney <paulmck@linux.vnet.ibm.com> wrote:
> >
> > > On Mon, Oct 03, 2011 at 07:53:02AM +0200, Ingo Molnar wrote:
> > > >
> > > > Not sure whether you've seen this one already:
> > >
> > > This is a new one for me.
> > >
> > > > [ 18.110320] Adding 3911820k swap on /dev/sda2. Priority:-1 extents:1 across:3911820k
> > > > [ 31.803721]
> > > > [ 31.804597] ===============================
> > > > [ 31.804597] [ INFO: suspicious RCU usage. ]
> > > > [ 31.804597] -------------------------------
> > > > [ 31.804597] include/linux/cgroup.h:548 suspicious rcu_dereference_check() usage!
> > > > [ 31.804597]
> > > > [ 31.804597] other info that might help us debug this:
> > > > [ 31.804597]
> > > > [ 31.804597]
> > > > [ 31.804597] rcu_scheduler_active = 1, debug_locks = 0
> > > > [ 31.804597] 1 lock held by true/845:
> > > > [ 31.804597] #0: (&sig->cred_guard_mutex){+.+.+.}, at: [<4109f06f>] prepare_bprm_creds+0x20/0x55
> > > > [ 31.804597]
> > > > [ 31.804597] stack backtrace:
> > > > [ 31.804597] Pid: 845, comm: true Not tainted 3.1.0-rc8-tip-01699-gde204a2-dirty #157471
> > > > [ 31.804597] Call Trace:
> > > > [ 31.804597] [<412d78fa>] ? printk+0x18/0x1a
> > > > [ 31.804597] [<41044190>] lockdep_rcu_suspicious+0xb1/0xb9
> > > > [ 31.804597] [<4106d6de>] perf_event_comm+0xb1/0x357
> > > > [ 31.804597] [<4109f048>] set_task_comm+0x4d/0x54
> > >
> > > This one does task_lock(), which acquires the task's
> > > ->alloc lock. In theory, this should prevent the
> > > lockdep-RCU splat. It clearly does not, and here are
> > > some possible reasons why:
> > >
> > > 1. Something redirects to some other task along the way.
> > >
> > > 2. Something releases ->alloc_lock along the way.
> > >
> > > The output above shows no locks held, which points to #2.
> > >
> > > set_task_comm() calls perf_event_comm() shown above, which calls
> > > perf_event_comm_event(), which does rcu_read_lock(), which should
> > > also prevent the splat. Then perf_event_comm_event() calls
> > > perf_event_comm_ctx(), which calls perf_event_comm_output()...
> > >
> > > Holy inlining, Batman!!!
> > >
> > > OK, I confess, I am a wuss... Any chance of reproducing this
> > > with CONFIG_SCHED_OMIT_FRAME_POINTER=n? Or would someone more
> > > familiar with these functions be willing to enlighten me?
> >
> > Ok, i ran the tests some more and here's a similar splat with
> > framepointers enabled:
> >
> > [ 50.402719] eth0: no IPv6 routers present
> > [ 59.147572]
> > [ 59.149064] ===============================
> > [ 59.151257] [ INFO: suspicious RCU usage. ]
> > [ 59.156865] -------------------------------
> > [ 59.156865] include/linux/cgroup.h:548 suspicious rcu_dereference_check() usage!
> > [ 59.156865]
> > [ 59.156865] other info that might help us debug this:
> > [ 59.156865]
> > [ 59.156865]
> > [ 59.156865] rcu_scheduler_active = 1, debug_locks = 0
> > [ 59.156865] 1 lock held by true/667:
> > [ 59.156865] #0: (&sig->cred_guard_mutex){+.+.+.}, at: [<c111d927>] prepare_bprm_creds+0x27/0x70
> > [ 59.156865]
> > [ 59.156865] stack backtrace:
> > [ 59.156865] Pid: 667, comm: true Not tainted 3.1.0-rc8-tip+ #157499
> > [ 59.156865] Call Trace:
> > [ 59.156865] [<c1a41f7c>] ? printk+0x28/0x2a
> > [ 59.156865] [<c109d540>] lockdep_rcu_suspicious+0xc0/0xd0
> > [ 59.156865] [<c10d8a98>] perf_event_enable_on_exec+0x1c8/0x1d0
> > [ 59.156865] [<c109c364>] ? __lock_release+0x54/0xd0
> > [ 59.156865] [<c10daef8>] perf_event_comm+0x18/0x60
> > [ 59.156865] [<c111d80d>] ? set_task_comm+0x5d/0x80
> > [ 59.156865] [<c1a6ac6d>] ? _raw_spin_unlock+0x1d/0x30
> > [ 59.156865] [<c111d814>] set_task_comm+0x64/0x80
> > [ 59.156865] [<c111e355>] setup_new_exec+0xc5/0x1f0
> > [ 59.156865] [<c115313b>] load_elf_binary+0x28b/0xa00
> > [ 59.156865] [<c111de59>] ? search_binary_handler+0xd9/0x1d0
> > [ 59.156865] [<c109c364>] ? __lock_release+0x54/0xd0
> > [ 59.156865] [<c1152eb0>] ? do_mmap+0x60/0x60
> > [ 59.156865] [<c111de60>] search_binary_handler+0xe0/0x1d0
> > [ 59.156865] [<c111ddb0>] ? search_binary_handler+0x30/0x1d0
> > [ 59.156865] [<c111e17f>] do_execve_common+0x22f/0x2a0
> > [ 59.156865] [<c111e202>] do_execve+0x12/0x20
> > [ 59.156865] [<c1036462>] sys_execve+0x32/0x70
> > [ 59.156865] [<c1a6c052>] ptregs_execve+0x12/0x18
> > [ 59.156865] [<c1a6bfd7>] ? sysenter_do_call+0x12/0x36
> >
> > Config and full bootlog attached.
>
> Hello, Ingo,
>
> It appears that inlining has defeated me, so I tried reproducing under
> KVM, using the closest bootable approximation to your .config (attached).
> I booted ten times without seeing this error. I have my changes against
> 3.1-rc8. I will try against 3.1, but in the meantime any enlightenment
> would be most welcome. ;-)
And I cannot reproduce after merging into 3.1. :-(
Thanx, Paul
^ permalink raw reply
* Re: [PATCH] mmc: mmci: Improve runtime PM support
From: Ulf Hansson @ 2011-10-24 11:48 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: Sebastian Rasmussen, linux-mmc@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, Lee Jones
In-Reply-To: <20111024101416.GK9893@n2100.arm.linux.org.uk>
>> Could you maybe elaborate a bit of how the power is controlled in the
>> ARM dev boards? Would it be possible to control such a switch in "GPIO"
>> manner instead? For example via the vdd_handler or similar?
>>
>> I will also think if and see if is feasible to re-design and see if this
>> hole feature can be controlled by the variant struct instead. My feeling
>> is although it can be kind of messy. But let's see...
>
> The MCIPWR register contains two bits to control _the_ _power_ _state_.
> See Table A-4: the MCIPWR signal. See section 2.2.2. See section 3.3.1.
>
> The MCIPWR signal controls the external power switch. This is the only
> signal for it. This is the only connection for it. There is no other
> control form for this power switch.
>
Then we are only left to use the variant struct I believe. In principle,
a flag in the variant struct, could indicate whether it is OK to disable
the vcore regulator and thus clear the MCIPWR when doing runtime_suspend.
How do you feel about this kind of approach to find a solution?
BR
Ulf Hansson
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.