Serverphorums.com

Re: [PATCH 08/10] Use __kernel_ulong_t in struct msqid64_ds

H.J. Lu — Sun, 20 May 2012 03:40:01 +0200

On Sat, May 19, 2012 at 4:47 PM, H. Peter Anvin wrote:
> On 05/18/2012 02:21 PM, Arnd Bergmann wrote:
>> On Friday 18 May 2012, H.J. Lu wrote:
>>> Since x32 uses the same kernel interface as x86-64 with a few
>>> exceptions. The current kernel header files with
>>>
>>> #ifdef __x86_64__
>>> # define __BITS_PER_LONG 64
>>> #else
>>> # define __BITS_PER_LONG 32
>>> #endif
>>>
>>> #if __BITS_PER_LONG == 64
>>> Define x86-64 types
>>> #endif
>>>
>>> work fine for x32 even if long for x32 is 32 bits. If __BITS_PER_LONG
>>> is changed to 32 for x32, many types in kernel header files will be
>>> wrong for x32.
>>>
>>
>> A lot of things are broken if __BITS_PER_LONG is set to 64 in x32 user
>> space. It was specifically introduced to get around places in exported
>> headers that incorrectly used '#ifdef CONFIG_64BIT' to define a user
>> space structure, so that we can depend on whatever the user sees
>> in bitmasks and other data structures.
>>
>
> I'm not entirely sure I follow the above statement, as it seems
> contradict itself. Either way, I would agree, __BITS_PER_LONG should be
> 32 in x32 space and if there are places where that is wrong then we need
> to fix them.
>
> Fortunately x32 is littleendian, so no "littleendian bitmask on a
> bigendian architecture" drain bamage...
>

If __BITS_PER_LONG is set to 32 for x32, we need to audit all
exported kernel headers where __BITS_PER_LONG is checked.
If long is used in those places, it has to be updated for x32.

--
H.J.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

[PATCH] x86/mce: Fix check for processor context when machine check was taken.

Tony Luck — Sun, 20 May 2012 03:30:01 +0200

Linus pointed out that checking "m->ip" was incorrect as "0" is
a legitimate value. Also we need to consider that we may have
interrupted VM86 execution (in which case "CS" isn't any use in
determining user/kernel).

Reported-by: Linus Torvalds
Signed-off-by: Tony Luck
---
In case you are unable to sleep at night worrying about those
poor systems that don't recover because they do the wrong thing
if there is a VM86 process running, or some malicious user has
a "jmp 0" at the base of a code segment.

Mea culpa: Andi fixed the VM86 part of this a year and
a half ago, and I failed to pick up the fix from his tree
when I took over. There are some other bits I need to pick
up too.

arch/x86/kernel/cpu/mcheck/mce-severity.c | 11 +++++------
arch/x86/kernel/cpu/mcheck/mce.c | 2 ++
2 files changed, 7 insertions(+), 6 deletions(-)

diff --git a/arch/x86/kernel/cpu/mcheck/mce-severity.c b/arch/x86/kernel/cpu/mcheck/mce-severity.c
index 0c82091..5dfb77a 100644
--- a/arch/x86/kernel/cpu/mcheck/mce-severity.c
+++ b/arch/x86/kernel/cpu/mcheck/mce-severity.c
@@ -165,15 +165,14 @@ static struct severity {
};

/*
- * If the EIPV bit is set, it means the saved IP is the
- * instruction which caused the MCE.
+ * No need to re-check mcgstatus here. We either found a
+ * good value for "cs" on the stack earlier (or faked one
+ * for the VM86 case) - or we didn't and "m->cs" will be
+ * zero which we will treat conservatively as "IN_KERNEL".
*/
static int error_context(struct mce *m)
{
- if (m->mcgstatus & MCG_STATUS_EIPV)
- return (m->ip && (m->cs & 3) == 3) ? IN_USER : IN_KERNEL;
- /* Unknown, assume kernel */
- return IN_KERNEL;
+ return ((m->cs & 3) == 3) ? IN_USER : IN_KERNEL;
}

int mce_severity(struct mce *m, int tolerant, char **msg)
diff --git a/arch/x86/kernel/cpu/mcheck/mce.c b/arch/x86/kernel/cpu/mcheck/mce.c
index 11c9166..a2d53f3 100644
--- a/arch/x86/kernel/cpu/mcheck/mce.c
+++ b/arch/x86/kernel/cpu/mcheck/mce.c
@@ -437,6 +437,8 @@ static inline void mce_gather_info(struct mce *m, struct pt_regs *regs)
if (m->mcgstatus & (MCG_STATUS_RIPV|MCG_STATUS_EIPV)) {
m->ip = regs->ip;
m->cs = regs->cs;
+ if (v8086_mode(regs))
+ m->cs |= 3; /* fake user mode for VM86 */
}
/* Use accurate RIP reporting if available. */
if (rip_msr)
--
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

[PATCH] net/ipv4: replace simple_strtoul with kstrtoul

Eldad Zack — Sun, 20 May 2012 02:20:01 +0200

Replace simple_strtoul with kstrtoul in three similar occurrences, all setup
handlers:
* route.c: set_rhash_entries
* tcp.c: set_thash_entries
* udp.c: set_uhash_entries

Also check if the conversion failed.

Signed-off-by: Eldad Zack
---
net/ipv4/route.c | 8 +++++++-
net/ipv4/tcp.c | 8 +++++++-
net/ipv4/udp.c | 8 +++++++-
3 files changed, 21 insertions(+), 3 deletions(-)

diff --git a/net/ipv4/route.c b/net/ipv4/route.c
index 167ea10..84d1832 100644
--- a/net/ipv4/route.c
+++ b/net/ipv4/route.c
@@ -3430,9 +3430,15 @@ struct ip_rt_acct __percpu *ip_rt_acct __read_mostly;
static __initdata unsigned long rhash_entries;
static int __init set_rhash_entries(char *str)
{
+ ssize_t ret;
+
if (!str)
return 0;
- rhash_entries = simple_strtoul(str, &str, 0);
+
+ ret = kstrtoul(str, 0, &rhash_entries);
+ if (ret)
+ return 0;
+
return 1;
}
__setup("rhash_entries=", set_rhash_entries);
diff --git a/net/ipv4/tcp.c b/net/ipv4/tcp.c
index 6589e11..6ed0552 100644
--- a/net/ipv4/tcp.c
+++ b/net/ipv4/tcp.c
@@ -3222,9 +3222,15 @@ extern struct tcp_congestion_ops tcp_reno;
static __initdata unsigned long thash_entries;
static int __init set_thash_entries(char *str)
{
+ ssize_t ret;
+
if (!str)
return 0;
- thash_entries = simple_strtoul(str, &str, 0);
+
+ ret = kstrtoul(str, 0, &thash_entries);
+ if (ret)
+ return 0;
+
return 1;
}
__setup("thash_entries=", set_thash_entries);
diff --git a/net/ipv4/udp.c b/net/ipv4/udp.c
index fe14105..662836a 100644
--- a/net/ipv4/udp.c
+++ b/net/ipv4/udp.c
@@ -2163,9 +2163,15 @@ void udp4_proc_exit(void)
static __initdata unsigned long uhash_entries;
static int __init set_uhash_entries(char *str)
{
+ ssize_t ret;
+
if (!str)
return 0;
- uhash_entries = simple_strtoul(str, &str, 0);
+
+ ret = kstrtoul(str, 0, &uhash_entries);
+ if (ret)
+ return 0;
+
if (uhash_entries && uhash_entries < UDP_HTABLE_SIZE_MIN)
uhash_entries = UDP_HTABLE_SIZE_MIN;
return 1;
--
1.7.10

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

[PATCH] net/ipv4/ipconfig: neaten __setup placement

Eldad Zack — Sun, 20 May 2012 02:10:02 +0200

The __setup macro should follow the corresponding setup handler.

Signed-off-by: Eldad Zack
---
net/ipv4/ipconfig.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/net/ipv4/ipconfig.c b/net/ipv4/ipconfig.c
index 92ac7e7..1d8076a 100644
--- a/net/ipv4/ipconfig.c
+++ b/net/ipv4/ipconfig.c
@@ -1626,11 +1626,13 @@ static int __init ip_auto_config_setup(char *addrs)

return 1;
}
+__setup("ip=", ip_auto_config_setup);

static int __init nfsaddrs_config_setup(char *addrs)
{
return ip_auto_config_setup(addrs);
}
+__setup("nfsaddrs=", nfsaddrs_config_setup);

static int __init vendor_class_identifier_setup(char *addrs)
{
@@ -1641,7 +1643,4 @@ static int __init vendor_class_identifier_setup(char *addrs)
vendor_class_identifier);
return 1;
}
-
-__setup("ip=", ip_auto_config_setup);
-__setup("nfsaddrs=", nfsaddrs_config_setup);
__setup("dhcpclass=", vendor_class_identifier_setup);
--
1.7.10

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

AJAX Uploader with Nginx, Not Catching Files

ztaylor4 — Sun, 20 May 2012 01:50:02 +0200

Has anyone set up nginx to work with an AJAX uploader like this one
before? http://valums.com/ajax-upload/

Passing the upload through to my Tornado server works fine, but I want
nginx to handle the file before it gets that far. I have nginx set up
to intercept regular file posts from our pre-AJAX page with
"upload_pass" and "upload_store," but now with the file in the body of
an XHR request, nginx doesn't treat it as a file for things like
"upload_store."

Also, my AJAX page gets back a 415 error when trying to send the file.
I'm using the script for image uploads if that makes a difference.

I was thinking I might be able to save a log of the request as the image
file, but that seems like too much of a hack.

Any help appreciated,
Zach

Posted at Nginx Forum: http://forum.nginx.org/read.php?2,226657,226657#msg-226657

_______________________________________________
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx

Re: [PATCH 08/10] Use __kernel_ulong_t in struct msqid64_ds

H. Peter Anvin — Sun, 20 May 2012 01:50:02 +0200

On 05/18/2012 02:21 PM, Arnd Bergmann wrote:
> On Friday 18 May 2012, H.J. Lu wrote:
>> Since x32 uses the same kernel interface as x86-64 with a few
>> exceptions. The current kernel header files with
>>
>> #ifdef __x86_64__
>> # define __BITS_PER_LONG 64
>> #else
>> # define __BITS_PER_LONG 32
>> #endif
>>
>> #if __BITS_PER_LONG == 64
>> Define x86-64 types
>> #endif
>>
>> work fine for x32 even if long for x32 is 32 bits. If __BITS_PER_LONG
>> is changed to 32 for x32, many types in kernel header files will be
>> wrong for x32.
>>
>
> A lot of things are broken if __BITS_PER_LONG is set to 64 in x32 user
> space. It was specifically introduced to get around places in exported
> headers that incorrectly used '#ifdef CONFIG_64BIT' to define a user
> space structure, so that we can depend on whatever the user sees
> in bitmasks and other data structures.
>

I'm not entirely sure I follow the above statement, as it seems
contradict itself. Either way, I would agree, __BITS_PER_LONG should be
32 in x32 space and if there are places where that is wrong then we need
to fix them.

Fortunately x32 is littleendian, so no "littleendian bitmask on a
bigendian architecture" drain bamage...

-hpa

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Re: Plumbers: Tweaking scheduler policy micro-conf RFP

Peter Zijlstra — Sun, 20 May 2012 01:30:01 +0200

On Sat, 2012-05-19 at 10:08 -0700, Linus Torvalds wrote:
> And I
> *do* know that the real world simply isn't simple enough that we could
> ever do a perfect job, so don't even try - instead aim for
> "understandable, maintainable, and gets the main issues roughly
> right".

I think we're in violent agreement on many points and most of this is
based on a mis-understanding. I've argued for exactly this many times.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Re: [PATCH] regulator: core: use correct device for device supply lookup

Mark Brown — Sun, 20 May 2012 01:20:01 +0200

On Sun, May 20, 2012 at 02:43:18AM +0530, Laxman Dewangan wrote:

> For mapping, the node should start from "regulators", not from pmu
> on this example.

What makes you say this? I'm really not even sure what it means.
How does a node "start" from something? Supply mappings are direct
links between consumers and regulators.

> Here my understanding is that config->of_node should contain the
> node information of the regulator being registered only. In DT case,
> it should not be null.

Right, but this is unrelated to what we're doing when the regulator is a
consumer. Then we just do the same thing as regulator_get(dev, name).

> >I still don't see any change needed here, from the above it simply looks
> >like the supplies aren't set up.

> Unfortunately,
> My regulator_get is failing if I dont correct the above logic to
> have proper config.of_node.

But this seems like it is unrelated to the patch we're discussing! Your
patch does nothing to config.of_node, it changes the device used to look
up the supply. To repeat yet again:

| context of the class device we create. I can't think of any situation
| where I'd expect that to make matters any better - the class device
| should certainly never appear in the device tree and isn't going to have
| a stable name for non-DT systems either.

*Please* engage with this, especially the non-DT part. You need to
explain how what you're saying is related to the patch you posted, you
keep talking about a "proper" config.of_node and saying this happens to
make your system work but this isn't visibily related to the patch you
posted.

What is not "proper" about the of_node that was supplied for the
regulator being registered? In what way is this related to the device
used by the regulator functioning as a consumer to request a supply?

Re: Plumbers: Tweaking scheduler policy micro-conf RFP

Peter Zijlstra — Sun, 20 May 2012 01:20:01 +0200

On Sat, 2012-05-19 at 10:08 -0700, Linus Torvalds wrote:
> Don't try to build up some perfect NUMA topology and then
> try to see how insanely well you can match a particular machine. Make
> some generic "roughly like this" topology with (say) four three of
> NUMAness, and then have architectures say "this is roughly what my
> machine looks like".

> In particular, don't even try to give random "weights" to how close
> things are to each other. Sure, you can parse (and generate) those
> complex NUMA tables, but nobody is *ever* smart enough to really use
> them. Once you move data between boards/nodes, screw the number of
> hops. You are NOT going to get some scheduling decision right that
> says "node X is closer to node Y than to node Z". Especially since the
> load is invariably going to access non-node memory too *anyway*.

I suspect this is related to the patch I recently did that creates numa
levels from the node_distance() table.

The fact is, that patch removed arch specific code. And yes initially I
tried to use the weights for more than simply creating the balance
levels but I've already realized that was a mistake and removed that
part.

So currently all it does is create load-balance levels based on how far
apart nodes are said to be and decrease the balance rate roughly
proportional to how many cpus are in each level.

The node_distance() table is mostly already a fabrication of the
arch/firmware; some people do exactly what you suggested, expose simple
groups of board vs rest and not bother with fine details.

I used the node_distance() table simply because this was an existing
arch interface that provides exactly what was needed and is used for
exactly this purpose in the mm/ part of the kernel as well.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Re: Plumbers: Tweaking scheduler policy micro-conf RFP

Peter Zijlstra — Sun, 20 May 2012 01:00:03 +0200

On Sat, 2012-05-19 at 10:08 -0700, Linus Torvalds wrote:

> Ingo, please don't take any of these patches if they are starting to
> make NUMA scheduling be some arch-specific crap.

I think there's a big mis-understanding here. I fully 100% agree with
you on that. And this thread in particular isn't about NUMA at all.

This thread is about modifying the arch interface of describing the
chip.

The current interface is we have 4 fixed topology domains:

SMT
MC
BOOK
CPU

(and the NUMA stuff comes on top of that and I just removed arch bits
from that, so lets leave that for now).

The first 3 domains depend on CONFIG_SCHED_{SMT,MC,BOOK} resp. and if an
architecture select one of those it will have to provide a function
cpu_{smt,coregroup,book}_mask and optionally put a struct sched_domain
initializer in their asm/topology.h.

Now I've had quite a few complaints from arch maintainers that the
sched_domain initializer is a far too unwieldy interface to fill out and
I quite agree with them.

Now all I've meant to propose in this thread is to replace the entire
above with a simpler interface.

Instead of the above all I'm asking of doing is providing something
along the lines of:

struct sched_topology arch_topology[] = {
{ cpu_smt_mask, ST_SMT },
{ cpu_llc_mask, ST_CACHE },
{ cpu_socket_mask, ST_SOCKET },
{ NULL, },
};

and that's just about all an arch would need to do.

That said, there are a few new things in ARM land like the big-little
stuff that have no direct relation to anything on the x86 side. And they
would very much like to have means of describing their chip topology as
well.

About power aware scheduling, yes its all a big mess and the current
stuff is horrid and broken.

That said, I do believe we can do better than nothing about it, and I'm
really not asking for anything perfect -- in fact I'm asking for pretty
much the same thing you are, something simple and understandable.

The simple pack stuff on a minimum amount of power-gated units instead
of spreading it out should get some benefit. For this we'd need to know
at what granularity a chip can power-gate.

> I'm very very serious about this. Try to make the scheduler have a
> *simple* model that people can actually understand. For example, maybe
> it can literally be a multi-level balancing thing, where the per-cpu
> runqueues are grouped into a "shared core resources" balancer that
> balances within the SMT or shared-L2 domain. And then there's an
> upper-level balancer (that runs much more seldom) that is written to
> balances within the socket. And then one that balances within the
> node/board. And finally one that balances across boards.

That is basically how the scheduler is set up. These are the
sched_domains.

There is an awful lot of complexity in that code though, and I've been
trying to clean some of that up but its very slow going.

The purpose of this thread is to both simplify and allow people to more
easily express what they really care about. For this we need to explore
the problem space.

I know I haven't replied to all your points, and I suspect many are
related to annoyances you might have from other threads and I shall
attempt to answer them later.

I do feel bad that I've managed to annoy you to such a degree though. I
really would rather have a much simpler load-balancer too.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Re: [PATCH] USB CDC-Ether - Add ZTE WWAN matches before generic Ethernet

David Miller — Sun, 20 May 2012 00:50:01 +0200

From: Andrew Bird
Date: Sat, 19 May 2012 14:56:07 +0100

> Some ZTE WWAN devices have generic CDC Ether descriptors. Add those
> into the whitelist so that we get FLAG_WWAN on the interface
>
> Signed-off-by: Andrew Bird

Applied.

But I changed the Subject line to have a more appropriate prefix,
namely "net: cdc_ether: "
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Re: [PATCH] irq_domain: Standardise legacy/linear domain selection

Mark Brown — Sun, 20 May 2012 00:50:01 +0200

On Sat, May 19, 2012 at 02:59:51PM -0600, Grant Likely wrote:

> It will actually be like all legacy users switched to creating an
> linear mapping, and then either associating already allocated
> irq_descs with that domain or telling the domain to pre-map a specific
> range of irq_descs (and manage allocations). Those two use cases will
> be separate APIs. I don't think they should be combined (at least
> from my current thinking) because it depends on whether or not the
> irq_descs are already allocated.

Hrm. Given that the target for this API is drivers that mostly don't
care and are only supporting the current linear mappings in order to
allow their GPIOs to be used with generic drivers that only want an IRQ
I'd expect we'll wind up with a similar helper somehow. Copying a
number around for irq_start isn't much hassle for individual drivers but
having to worry about more than that seems like too much effort, they
shouldn't have to care about the management of irq_descs. It'd be more
work and it'd make it more painful for platforms to change between the
preallocated and dynamic models.

Re: [PATCH 1/1] net:ipv6:fixed space issues relating to operators.

David Miller — Sun, 20 May 2012 00:40:01 +0200

From: Jeffrin Jose
Date: Sat, 19 May 2012 17:29:04 +0530

> Fixed space issues relating to operators found by
> checkpatch.pl tool in net/ipv6/udp.c
>
> Signed-off-by: Jeffrin Jose

Applied.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Re: [PATCH 1/1] net:ipv6:fixed a trailing white space issue.

David Miller — Sun, 20 May 2012 00:40:01 +0200

From: Jeffrin Jose
Date: Sat, 19 May 2012 17:15:21 +0530

> Fixed a trailing white space issue found by
> checkpatch.pl tool in net/ipv6/udp.c
>
> Signed-off-by: Jeffrin Jose

Applied.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

[-next] DRM_CIRRUS_QEMU breaks build

Jiri Slaby — Sun, 20 May 2012 00:30:01 +0200

Hi,

when that option is selected to be Y, I'm getting linking errors like:
(.text+0xefd8d): undefined reference to `ttm_tt_init'
drivers/built-in.o: In function `cirrus_mm_init':
and many others, like undefined sys_fillrect.

You perhaps have a patch on your queue already and I need not to turn
this into a patch, right :):

--- a/drivers/gpu/drm/cirrus/Kconfig
+++ b/drivers/gpu/drm/cirrus/Kconfig
@@ -1,10 +1,11 @@
config DRM_CIRRUS_QEMU
tristate "Cirrus driver for QEMU emulated device"
depends on DRM && PCI && EXPERIMENTAL
- select FB_CFB_FILLRECT
- select FB_CFB_COPYAREA
- select FB_CFB_IMAGEBLIT
+ select FB_SYS_FILLRECT
+ select FB_SYS_COPYAREA
+ select FB_SYS_IMAGEBLIT
select DRM_KMS_HELPER
+ select DRM_TTM
help
This is a KMS driver for emulated cirrus device in qemu.
It is *NOT* intended for real cirrus devices. This requires

regards,
--
js
suse labs

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Re: NVM Mapping API

Christian Stroetmann — Sun, 20 May 2012 00:20:01 +0200

On We, May 16, 2012 at 21:58, Christian Stroetmann wrote:
> On We, May 16, 2012 at 19:35, Matthew Wilcox wrote:
>> On Wed, May 16, 2012 at 10:52:00AM +0100, James Bottomley wrote:
>>> On Tue, 2012-05-15 at 09:34 -0400, Matthew Wilcox wrote:
>>>> There are a number of interesting non-volatile memory (NVM)
>>>> technologies
>>>> being developed. Some of them promise DRAM-comparable latencies and
>>>> bandwidths. At Intel, we've been thinking about various ways to
>>>> present
>>>> those to software. This is a first draft of an API that supports the
>>>> operations we see as necessary. Patches can follow easily enough once
>>>> we've settled on an API.
>>> If we start from first principles, does this mean it's usable as DRAM?
>>> Meaning do we even need a non-memory API for it? The only difference
>>> would be that some pieces of our RAM become non-volatile.
>> I'm not talking about a specific piece of technology, I'm assuming that
>> one of the competing storage technologies will eventually make it to
>> widespread production usage. Let's assume what we have is DRAM with a
>> giant battery on it.
> Our ST-RAM (see [1] for the original source of its description) is a
> concept based on the combination of a writable volatile Random-Access
> Memory (RAM) chip and a capacitor.
[...]
> Boaz asked: "What is the difference from say a PCIE DRAM card with
> battery"? It sits in the RAM slot.
>
>
>>
>> So, while we can use it just as DRAM, we're not taking advantage of the
>> persistent aspect of it if we don't have an API that lets us find the
>> data we wrote before the last reboot. And that sounds like a filesystem
>> to me.
>
> No and yes.
> 1. In the first place it is just a normal DRAM.
> 2. But due to its nature it has also many aspects of a flash memory.
> So the use case is for point
> 1. as a normal RAM module,
> and for point
> 2. as a file system,
> which again can be used
> 2.1 directly by the kernel as a normal file system,
> 2.2 directly by the kernel by the PRAMFS
> 2.3 by the proposed NVMFS, maybe as a shortcut for optimization,
> and
> 2.4 from the userspace, most potentially by using the standard VFS.
> Maybe this version 2.4 is the same as point 2.2.
>
>>> Or is there some impediment (like durability, or degradation on
>>> rewrite)
>>> which makes this unsuitable as a complete DRAM replacement?
>> The idea behind using a different filesystem for different NVM types is
>> that we can hide those kinds of impediments in the filesystem. By the
>> way, did you know DRAM degrades on every write? I think it's on the
>> order of 10^20 writes (and CPU caches hide many writes to heavily-used
>> cache lines), so it's a long way away from MLC or even SLC rates, but
>> it does exist.
>
> As I said before, a filesystem for the different NVM types would not
> be enough. These things are more complex due the possibility that they
> can be used very flexbily.
>
>>
>>> Alternatively, if it's not really DRAM, I think the UNIX file
>>> abstraction makes sense (it's a piece of memory presented as something
>>> like a filehandle with open, close, seek, read, write and mmap), but
>>> it's less clear that it should be an actual file system. The reason is
>>> that to present a VFS interface, you have to already have fixed the
>>> format of the actual filesystem on the memory because we can't nest
>>> filesystems (well, not without doing artificial loopbacks). Again,
>>> this
>>> might make sense if there's some architectural reason why the flash
>>> region has to have a specific layout, but your post doesn't shed any
>>> light on this.
>> We can certainly present a block interface to allow using unmodified
>> standard filesystems on top of chunks of this NVM. That's probably not
>> the optimum way for a filesystem to use it though; there's really no
>> point in constructing a bio to carry data down to a layer that's simply
>> going to do a memcpy().
>> --
>
> I also saw the use cases by Boaz that are
> Journals of other FS, which could be done on top of the NVMFS for
> example, but is not really what I have in mind, and
> Execute in place, for which an Elf loader feature is needed.
> Obviously, this use case was envisioned by me as well.
>
> For direct rebooting the checkpointing of standard RAM is also a
> needed function. The decision what is trashed and what is marked as
> persistent RAM content has to be made by the RAM experts of the Linux
> developers or the user. I even think that this is a special use case
> on its own with many options.
>
Because it is now about 1 year ago when I played around with the
conceptual hardware aspects of anUninterruptible Power RAM (UPRAM) like
the ST-RAM, I looked in more detail at the software side yesterday and
today. So let me please add my first use case that I had in mind last
year and coined now:
Hybrid Hibernation (HyHi) or alternatively Suspend-to-NVM,
which is similar to hybrid sleep and hibernation, but also differs a
little bit due to the uninterruptible power feature.

But as it can be seen easily here again, even with this 1 use case exist
two paths to handle the NVM that are as:
1. RAM and
2. FS,
so that it leads a further time to the discussion, if hibernation should
be a kernel or a user space function (see [1] and [2] for more
information related with the discussion about uswsup (userspace software
suspend) and suspend2, and [3] for uswsup and [4] for TuxOnIce).

Eventually, there is an interest to reuse some functions or code.

Have fun in the sun
C. Stroetmann
> [1] ST-RAM www.ontonics.com/innovation/pipeline.htm#st-ram
>
[1] LKML: Pavel Machek: RE: suspend2 merge lkml.org/lkml/2007/4/24/405
[2] KernelTrap: Linux: Reviewung Suspend2 kerneltrap.org/node/6766
[3] suspend.sourceforge.net
[4] tuxonice.net
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

[-next regression] TCP window full with EPOLLWAKEUP

Jiri Slaby — Sun, 20 May 2012 00:10:01 +0200

Hi,

a bisection shows that with the following commit from -next:
commit 4d7e30d98939a0340022ccd49325a3d70f7e0238
Author: Arve Hjønnevåg
Date: Tue May 1 21:33:34 2012 +0200

epoll: Add a flag, EPOLLWAKEUP, to prevent suspend while epoll
events are ready

====

one of mono programs I use stops receiving data from the network.
Wireshark shows that the TCP window of a connection is filled. This
means the program does not read the data fast enough after requesting
the data.

If I revert that commit on the top of -next (20120518), everything works
as expected.

regards,
--
js
suse labs

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Re: linux-next: build warning after merge of the final tree (userns tree related)

Anonymous User — Sun, 20 May 2012 00:00:01 +0200

Stephen Rothwell writes:

> Hi Eric,
>
> After merging the final tree, today's linux-next build (powerpc
> ppc44x_defconfig) produced this warning:
>
> kernel/user.c:30:4: warning: this decimal constant is unsigned only in ISO C90 [enabled by default]
> kernel/user.c:38:4: warning: this decimal constant is unsigned only in ISO C90 [enabled by default]
>
> Introduced by commit 22d917d80e84 ("userns: Rework the user_namespace
> adding uid/gid mapping support").

Ugh. I missed this email the first time through. Thank you for the
report this problem should be fixed now.

Eric

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Re: [ 31/54] kmemleak: Fix the kmemleak tracking of the percpu areas with !SMP

Catalin Marinas — Sat, 19 May 2012 23:50:02 +0200

On Sat, May 19, 2012 at 03:46:52PM +0100, Greg KH wrote:
> On Sat, May 19, 2012 at 03:27:33PM +0200, Christoph Biedl wrote:
> > Greg KH wrote...
> >
> > > 3.0-stable review patch. If anyone has any objections, please let me know.
> >
> > > From: Catalin Marinas
> > >
> > > commit 100d13c3b5b9410f604b86f5e0a34da64b8cf659 upstream.
> >
> > > + /* kmemleak tracks the percpu allocations separately */
> > > + kmemleak_free(fc);
> >
> > That one causes:
> >
> > mm/percpu.c: In function ‘setup_per_cpu_areas’:
> > mm/percpu.c:1877: error: implicit declaration of function ‘kmemleak_free’
> > make[1]: *** [mm/percpu.o] Error 1
> > make: *** [mm] Error 2
>
> Odd, it doesn't cause that problem here for me, what ARCH are you
> building for? I'm on x86-64.

This patch propagated to far in the past. Support for per-cpu areas in
kmemleak was added with commit f528f0b8e5 (kmemleak: Handle percpu
memory allocation) in 3.3-rc1. That patch introduced the correct
#include for kmemleak.h.

Commit 100d13c should only be applied to stable 3.3 and not earlier.

Thanks.

--
Catalin
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

[PHP-DEV] Re: [PHP-QA] Parallel run-tests

Felipe Pena — Sat, 19 May 2012 23:40:01 +0200

Hi Zoe,

great work on this new run-tests! :D

I was testing it and noticed a problem when running using the following command:
$ ~/dev/php5_4/sapi/cli/php run-tests.php -z 8 -p
~/dev/php5_4/sapi/cli/php ~/dev/php5_4/

It shows the PHP messages:
[...]
Fatal error: Call to undefined function gzencode() in
/home/felipe/dev/phpruntests/src/testcase/sections/configurationsections/rtGzipPostSection.php
on line 23
[...]
Notice: Undefined offset: 0 in
/home/felipe/dev/phpruntests/src/testcase/rtTestDifference.php on line
91
Fatal error: Allowed memory size of 134217728 bytes exhausted at
/home/felipe/dev/php5_4/Zend/zend_hash.c:330 (tried to allocate 81
bytes) in /home/felipe/dev/phpruntests/src/testcase/rtPhpTestFile.php
on line 108
/home/felipe/dev/php5_4/Zend/zend_hash.c(551) : ht=0x7f96e6356a50 is
inconsistent
[...]
Fatal error: Allowed memory size of 134217728 bytes exhausted at
ext/standard/var_unserializer.re:290 (tried to allocate 32 bytes) in
/home/felipe/dev/phpruntests/src/taskScheduler/rtTaskSchedulerFile.php
on line 183

2012/5/17 zoe slattery :
> Hi
>
> Over the past couple of weeks I have updated the parallel run-tests (fixed a
> couple of minor bugs in the PHP code and the build.xml), it's now almost at
> the point where I could go ahead and implement the last pieces. Here is a
> summary and a few questions:
>
> 1. In rebasing the code the the dev't stream I found a number of tests with
> non-standard sections. My code checks test case structure and objects to
> anything non-standard, the current run-tests.php mainly ignores this kind of
> thing. I fixed up about 15 of these tests (see #62022) already - I'll fix
> the rest if there are no objections - I will open another bug report first.
>
> 2. If there is agreement to use this code it would make sense to replace
> the existing run-tests code with it, or rather, it would make no sense to
> try and maintain both versions. The new code is OO PHP, it's in
> http://git.php.net/repository/phpruntests.git, is there any problem with it
> staying there long term and maybe copying a run-tests.phar into the PHP
> source directory? I have no idea what the right answer is, suggestions
> welcome.
>
> 3. I ran a couple of small tests on my dual core Mac yesterday. For a
> standard set of tests, the parallel code ran in 207 seconds, sequential in
> 293 seconds and the standard run-tests.php took 298 seconds. This is an
> improvement but I suspect we could still do better by looking at the
> scheduling algorithm.
> At the moment it's very simple, we just assemble a list of directories with
> tests in and hand them out to processors till everything is done. Being able
> to handle tests that must be run in sequence (mysql, mysqli) will mean
> making some changes to this. So, perhaps we give an explicit list to p1 and
> let the scheduler distribute the rest of the tests? Or maybe we should have
> a 'process map' for all tests for extensions that are build by default?
> Again, suggestions welcome.
>
> 4. REDIRECTTEST still needs to be implemented, I understand how it works and
> this isn't (afaict) a major issue.
>
> 5. Testing. I'm able to do basic testing on Mac OSX and Linux. I really
> need access to an 8 way Linux system, or someone who has access and would be
> interested in looking at performance? Any volunteers? This is probably the
> most interesting part of the project :-)
>
> 6. Windows. I'm not in a position to do anything much with Windows except
> some very basic checks to make sure that the sequential version runs. The
> parallel code won't work because we used pcntl(), however I know that Stefan
> and George were keen to design the code so that a Windows solution could be
> implemented if anyone thought of one. If anyone wants to pick up this aspect
> I'd be happy to get them started.
>
> Zoe
>
> --
> PHP Quality Assurance Mailing List http://www.php.net/
> To unsubscribe, visit: http://www.php.net/unsub.php
>

--
Regards,
Felipe Pena

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[GIT PULL] DT clk binding support

Rob Herring — Sat, 19 May 2012 23:30:01 +0200

Mike,

Please pull devicetree clock binding support for 3.5. It's a bit late I
know, but this shouldn't affect anyone except for highbank which uses
it. It will be good to get it in so other platforms can start using it.

If you prefer, perhaps Arnd/Olof can pull this directly if you don't
have any other pulls planned for 3.5-rc1.

Rob

The following changes since commit f0948f59dbc8e725a96ba16da666e8f5cdd43ba8:

clk: add a fixed factor clock (2012-05-08 14:13:25 -0700)

are available in the git repository at:

git://sources.calxeda.com/kernel/linux.git clk-for-3.5

for you to fetch changes up to 9dca208955ffba16adc99d982fd7432b37f76faa:

clk: add highbank clock support (2012-05-15 19:14:10 -0500)

----------------------------------------------------------------
Grant Likely (2):
clk: add DT clock binding support
clk: add DT fixed-clock binding support

Rob Herring (2):
dt: add clock binding doc to primecell bindings
clk: add highbank clock support

.../devicetree/bindings/arm/primecell.txt | 6 +
.../devicetree/bindings/clock/calxeda.txt | 17 +
.../devicetree/bindings/clock/clock-bindings.txt | 117 +++++++
.../devicetree/bindings/clock/fixed-clock.txt | 21 ++
arch/arm/Kconfig | 1 +
arch/arm/boot/dts/highbank.dts | 91 +++++-
arch/arm/mach-highbank/Makefile | 2 +-
arch/arm/mach-highbank/clock.c | 62 ----
arch/arm/mach-highbank/highbank.c | 7 +
drivers/clk/Makefile | 4 +-
drivers/clk/clk-fixed-rate.c | 23 ++
drivers/clk/clk-highbank.c | 345
++++++++++++++++++++
drivers/clk/clk.c | 140 ++++++++
drivers/clk/clkdev.c | 77 +++++
include/linux/clk-provider.h | 16 +
include/linux/clk.h | 19 ++
16 files changed, 883 insertions(+), 65 deletions(-)
create mode 100644 Documentation/devicetree/bindings/clock/calxeda.txt
create mode 100644
Documentation/devicetree/bindings/clock/clock-bindings.txt
create mode 100644 Documentation/devicetree/bindings/clock/fixed-clock.txt
delete mode 100644 arch/arm/mach-highbank/clock.c
create mode 100644 drivers/clk/clk-highbank.c
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Re: [PATCH] regulator: core: use correct device for device supply lookup

Laxman Dewangan — Sat, 19 May 2012 23:20:01 +0200

On Sunday 20 May 2012 02:20 AM, Mark Brown wrote:
> * PGP Signed by an unknown key
>
> On Sun, May 20, 2012 at 12:33:32AM +0530, Laxman Dewangan wrote:
>
>> My board dts file is
>> pmu: tps65910@d2 {
>> compatible = "ti,tps65910";
>> reg =<0xd2>;
>> interrupt-parent =<&intc>;
>> interrupts =< 0 118 0x04>;
>>
>> #gpio-cells =<2>;
>> gpio-controller;
>>
>> #interrupt-cells =<2>;
>> interrupt-controller;
>>
>> regulators {
>> vdd1_reg: vdd1 {
>> regulator-min-microvolt =< 600000>;
>> regulator-max-microvolt =<1500000>;
>> regulator-always-on;
>> regulator-boot-on;
>> ti,regulator-ext-sleep-control =<0>;
>> };
>> vdd2_reg: vdd2 {
>> regulator-min-microvolt =< 600000>;
>> regulator-max-microvolt =<1500000>;
>> regulator-always-on;
>> regulator-boot-on;
>> ti,regulator-ext-sleep-control =<4>;
>> };
>> };
>> };
> Supplies aren't specified for any of the regulators here...
Sorry, I missed this, I added the supply as
vdd2-supply = <&vdd1_reg>; in the vdd2-reg.

>> So currently, when regulator_register gets called in
>> tps65910-regulator.c, it sets the
>> config.dev = tps65910->dev;
>> config.of_node as
>> config.of_node =
>> of_find_node_by_name(tps65910->dev->of_node,
>> info->name);
>> So here config.of_node always shows NULL as the in
>> tps65910->dev->of_node does not have name same as info->name ie.
>> regulator name like vdd1, vdd2.
> Of course, this is just like any other supply - since you've not
> specified a mapping for it of course the framework isn't able to look it
> up.
>

For mapping, the node should start from "regulators", not from pmu on
this example.
This is what we already did for regulator match
static struct tps65910_board *tps65910_parse_dt_reg_data(
struct platform_device *pdev)
{

struct device_node *np = pdev->dev.parent->of_node;
struct device_node *regulators;

regulators = of_find_node_by_name(np, "regulators");
ret = of_regulator_match(pdev->dev.parent, regulators, matches,
count);
:::::::::::
}

Here my understanding is that config->of_node should contain the node
information of the regulator being registered only. In DT case, it
should not be null.

So here also we need to pass as
config.of_node = of_find_node_by_name(regulators, info->name);

>>> If there is a change needed in the core you need to explain what you
>>> believe that change will do.
>> I though this is straight but seems it is becoming more complex now.
>> I will describe all this details if we agree to change require.
> I still don't see any change needed here, from the above it simply looks
> like the supplies aren't set up.
Unfortunately,
My regulator_get is failing if I dont correct the above logic to have
proper config.of_node.

Also regulator registration failed if
- there is supply and if I dont use the config_of_node in lookup after
fixing the config.of_node issue.

This is happening with pmu (tps65910) regulator only. Fixed regulators
are working fine here if they dont depends on tps6510. Input supply for
fixed regulator from other fixed regulators are also working fine.
Each Fixed regulators are independent platform driver and hence there is
no issue as dev->of_node is perfectly set/used.

> * Unknown Key
> * 0x6E30FDDD

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

hexagon: signal bugs

Al Viro — Sat, 19 May 2012 23:20:01 +0200

1) spot the braino:
void do_trap0(struct pt_regs *regs)
....
unsigned long syscallret = 0;
...
if ((unsigned long) regs->syscall_nr >= __NR_syscalls) {
regs->r00 = -1;
} else {
syscall = (syscall_fn)
(sys_call_table[regs->syscall_nr]);
syscallret = syscall(regs->r00, regs->r01,
regs->r02, regs->r03,
regs->r04, regs->r05);
}

if (regs->syscall_nr != __NR_rt_sigreturn)
regs->r00 = syscallret;
IOW, the last if () should've been inside the "syscall_nr is not too high"
branch of the if () just above...

2) you do _not_ want syscall restarts to happen on sigreturn().
Whatever adjustment needed to be done had already been done back before
we'd saved the registers into sigcontext. So doing
regs->syscall_nr = __NR_rt_sigreturn;
in sys_rt_sigreturn() is exactly the wrong thing - for syscall restart
purposes you want it to look like a non-syscall (i.e. it should be
regs->syscall_nr = -1 to make your check in handle_signal() work).
Incidentally, I would suggest just having that thing return regs->r00;
then you can avoid all special-casing for "do we want to put the
return value of sys_...() into regs->r00?" in do_trap0().

3) if you have multiple pending signals, you need to handle all
of them before returning to userland. And you need to make sure that
syscall restart logics does not trigger on anything past the first time
around.

4) checking for !user_mode(regs) needs to be done in the loop (created
while fixing #3) in vm_entry.S where you are calling do_notify_resume();
you need to leave the loop if it's true (if you can get there on return
to kernel in the first place).
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Re: [PATCH RESEND] Documentation: devicetree: Fix value format description

Grant Likely — Sat, 19 May 2012 23:10:02 +0200

On Wed, 16 May 2012 22:33:55 +0200, Roland Stigge wrote:
> Numeric values in dts files can be specified in decimal and hex (the latter
> prefixed 0x). The current documentation is updated with this patch to prevent
> confusion about what is meant with values without "0x" (previously hex, now
> dec).
>
> Signed-off-by: Roland Stigge
> Acked-by: Rob Landley

Applied, thanks.

g.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Re: [PATCH] irq_domain: Standardise legacy/linear domain selection

Grant Likely — Sat, 19 May 2012 23:10:02 +0200

On Sat, May 19, 2012 at 2:54 PM, Mark Brown
wrote:
> On Sat, May 19, 2012 at 02:22:58PM -0600, Grant Likely wrote:
>
>> I'm looking at killing the legacy mapping entirely which will push
>> changing all the users anyway. I'm going to hold off on applying this
>> one for a day or so until I'm sure of what it will look like.
>
> I take it you're going to replace the legacy mapping with an equivalent
> thing, though, so the interface is preserved for boards? In which case
> it'd be more like replacing the linear mapping with a new mapping type
> that can also be used by legacy users I guess?

It will actually be like all legacy users switched to creating an
linear mapping, and then either associating already allocated
irq_descs with that domain or telling the domain to pre-map a specific
range of irq_descs (and manage allocations). Those two use cases will
be separate APIs. I don't think they should be combined (at least
from my current thinking) because it depends on whether or not the
irq_descs are already allocated.

g.

--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Re: [PATCH] irq_domain: Standardise legacy/linear domain selection

Mark Brown — Sat, 19 May 2012 23:00:01 +0200

On Sat, May 19, 2012 at 02:22:58PM -0600, Grant Likely wrote:

> I'm looking at killing the legacy mapping entirely which will push
> changing all the users anyway. I'm going to hold off on applying this
> one for a day or so until I'm sure of what it will look like.

I take it you're going to replace the legacy mapping with an equivalent
thing, though, so the interface is preserved for boards? In which case
it'd be more like replacing the linear mapping with a new mapping type
that can also be used by legacy users I guess?

Re: [PATCH 2/3] x86: x2apic/cluster: Make use of lowest priority delivery mode

Yinghai Lu — Sat, 19 May 2012 23:00:01 +0200

On Fri, May 18, 2012 at 3:26 AM, Alexander Gordeev wrote:
> Currently x2APIC in logical destination mode delivers interrupts to a
> single CPU, no matter how many CPUs were specified in the destination
> cpumask.
>
> This fix enables delivery of interrupts to multiple CPUs by bit-ORing
> Logical IDs of destination CPUs that have matching Cluster ID.
>
> Because only one cluster could be specified in a message destination
> address, the destination cpumask is tried for a cluster that contains
> maximum number of CPUs matching this cpumask. The CPUs in this cluster
> are selected to receive the interrupts while all other CPUs (in the
> cpumask) are ignored.
>
> Signed-off-by: Alexander Gordeev
> ---
> arch/x86/include/asm/x2apic.h | 9 --
> arch/x86/kernel/apic/x2apic_cluster.c | 140 +++++++++++++++++++++++++++++----
> arch/x86/kernel/apic/x2apic_phys.c | 9 ++-
> 3 files changed, 131 insertions(+), 27 deletions(-)
>
> diff --git a/arch/x86/include/asm/x2apic.h b/arch/x86/include/asm/x2apic.h
> index 92e54ab..7a5a832 100644
> --- a/arch/x86/include/asm/x2apic.h
> +++ b/arch/x86/include/asm/x2apic.h
> @@ -28,15 +28,6 @@ static int x2apic_apic_id_registered(void)
> return 1;
> }
>
> -/*
> - * For now each logical cpu is in its own vector allocation domain.
> - */
> -static void x2apic_vector_allocation_domain(int cpu, struct cpumask *retmask)
> -{
> - cpumask_clear(retmask);
> - cpumask_set_cpu(cpu, retmask);
> -}
> -
> static void
> __x2apic_send_IPI_dest(unsigned int apicid, int vector, unsigned int dest)
> {
> diff --git a/arch/x86/kernel/apic/x2apic_cluster.c b/arch/x86/kernel/apic/x2apic_cluster.c
> index 8f012b2..f8fa4c4 100644
> --- a/arch/x86/kernel/apic/x2apic_cluster.c
> +++ b/arch/x86/kernel/apic/x2apic_cluster.c
> @@ -96,36 +96,142 @@ static void x2apic_send_IPI_all(int vector)
> __x2apic_send_IPI_mask(cpu_online_mask, vector, APIC_DEST_ALLINC);
> }
>
> +static inline unsigned int
> +__x2apic_cluster_to_apicid(int cpu_in_cluster, const struct cpumask *cpumask)
> +{
> + unsigned int apicid = 0;
> + int cpu;
> +
> + for_each_cpu_and(cpu, per_cpu(cpus_in_cluster, cpu_in_cluster), cpumask)
> + apicid |= per_cpu(x86_cpu_to_logical_apicid, cpu);
> +
> + return apicid;
> +}
> +
> +static int
> +__x2apic_cpu_mask_to_apicid(const struct cpumask *cpumask, unsigned int *apicid)
> +{
> + int ret = 0;
> + int cpu, heaviest;
> + unsigned int weight, max_weight;
> + cpumask_var_t target_cpus, cluster_cpus;
> +
> + if (unlikely(!alloc_cpumask_var(&target_cpus, GFP_ATOMIC))) {
> + ret = -ENOMEM;
> + goto out;
> + }
> + if (unlikely(!alloc_cpumask_var(&cluster_cpus, GFP_ATOMIC))) {
> + ret = -ENOMEM;
> + goto out_free_target_cpus;
> + }
> +
> + cpumask_and(target_cpus, cpumask, cpu_online_mask);
> + max_weight = 0;
> +
> + for_each_cpu(cpu, target_cpus) {
> + cpumask_and(cluster_cpus, per_cpu(cpus_in_cluster, cpu), cpumask);
> +
> + weight = cpumask_weight(cluster_cpus);
> + if (weight > max_weight) {
> + max_weight = weight;
> + heaviest = cpu;
> + }
> +
> + cpumask_andnot(target_cpus, target_cpus, cluster_cpus);
> + }
> +
> + if (!max_weight) {
> + ret = -EINVAL;
> + goto out_free_cluster_cpus;
> + }
> +
> + *apicid = __x2apic_cluster_to_apicid(heaviest, cpumask);
> +
> +out_free_cluster_cpus:
> + free_cpumask_var(cluster_cpus);
> +out_free_target_cpus:
> + free_cpumask_var(target_cpus);
> +out:
> + return ret;
> +}
> +
> static unsigned int x2apic_cpu_mask_to_apicid(const struct cpumask *cpumask)
> {
> - /*
> - * We're using fixed IRQ delivery, can only return one logical APIC ID.
> - * May as well be the first.
> - */
> - int cpu = cpumask_first(cpumask);
> + int err;
> + int cpu;
> + unsigned int apicid;
>
> - if ((unsigned)cpu < nr_cpu_ids)
> - return per_cpu(x86_cpu_to_logical_apicid, cpu);
> - else
> - return BAD_APICID;
> + err = __x2apic_cpu_mask_to_apicid(cpumask, &apicid);
> + WARN_ON(err);
> +
> + if (!err)
> + return apicid;
> +
> + if (err == -ENOMEM) {
> + for_each_cpu(cpu, cpumask) {
> + if (cpumask_test_cpu(cpu, cpu_online_mask))
> + break;
> + }
> + if (cpu < nr_cpu_ids)
> + return __x2apic_cluster_to_apicid(cpu, cpumask);
> + }
> +
> + return BAD_APICID;
> }
>
> static unsigned int
> x2apic_cpu_mask_to_apicid_and(const struct cpumask *cpumask,
> const struct cpumask *andmask)
> {
> - int cpu;
> + int err;
> + int cpu, first_cpu;
> + unsigned int apicid;
> + cpumask_var_t target_cpus;
> +
> + if (likely(alloc_cpumask_var(&target_cpus, GFP_ATOMIC))) {
> + cpumask_and(target_cpus, cpumask, andmask);
> +
> + err = __x2apic_cpu_mask_to_apicid(target_cpus, &apicid);
> +
> + free_cpumask_var(target_cpus);
> +
> + if (!err)
> + return apicid;
> + } else {
> + err = -ENOMEM;
> + }
> +
> + WARN_ON(err);
> +
> + if (err != -ENOMEM)
> + return 0;
> +
> + apicid = 0;
> + first_cpu = nr_cpu_ids;
>
> - /*
> - * We're using fixed IRQ delivery, can only return one logical APIC ID.
> - * May as well be the first.
> - */
> for_each_cpu_and(cpu, cpumask, andmask) {
> - if (cpumask_test_cpu(cpu, cpu_online_mask))
> + if (cpumask_test_cpu(cpu, cpu_online_mask)) {
> + first_cpu = cpu;
> break;
> + }
> + }
> +
> + if (first_cpu < nr_cpu_ids) {
> + for_each_cpu_and(cpu, per_cpu(cpus_in_cluster, first_cpu),
> + cpumask) {
> + if (!cpumask_test_cpu(cpu, andmask))
> + continue;
> + apicid |= per_cpu(x86_cpu_to_logical_apicid, cpu);
> + }
> }
>
> - return per_cpu(x86_cpu_to_logical_apicid, cpu);
> + return apicid;
> +}
> +
> +static void
> +x2apic_cluster_vector_allocation_domain(int cpu, struct cpumask *retmask)
> +{
> + cpumask_copy(retmask, cpu_possible_mask);

why not using per_cpu(cpus_in_cluster, cpu) instead?

also you may add one per cpu var like x86_cpu_to_logical_cluster_apicid.

Yinghai
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Re: [PATCH] regulator: core: use correct device for device supply lookup

Mark Brown — Sat, 19 May 2012 23:00:01 +0200

On Sun, May 20, 2012 at 12:33:32AM +0530, Laxman Dewangan wrote:

> My board dts file is
> pmu: tps65910@d2 {
> compatible = "ti,tps65910";
> reg = <0xd2>;
> interrupt-parent = <&intc>;
> interrupts = < 0 118 0x04 >;
>
> #gpio-cells = <2>;
> gpio-controller;
>
> #interrupt-cells = <2>;
> interrupt-controller;
>
> regulators {
> vdd1_reg: vdd1 {
> regulator-min-microvolt = < 600000>;
> regulator-max-microvolt = <1500000>;
> regulator-always-on;
> regulator-boot-on;
> ti,regulator-ext-sleep-control = <0>;
> };
> vdd2_reg: vdd2 {
> regulator-min-microvolt = < 600000>;
> regulator-max-microvolt = <1500000>;
> regulator-always-on;
> regulator-boot-on;
> ti,regulator-ext-sleep-control = <4>;
> };
> };
> };

Supplies aren't specified for any of the regulators here...

> So currently, when regulator_register gets called in
> tps65910-regulator.c, it sets the
> config.dev = tps65910->dev;
> config.of_node as
> config.of_node =
> of_find_node_by_name(tps65910->dev->of_node,
> info->name);
> So here config.of_node always shows NULL as the in
> tps65910->dev->of_node does not have name same as info->name ie.
> regulator name like vdd1, vdd2.

Of course, this is just like any other supply - since you've not
specified a mapping for it of course the framework isn't able to look it
up.

> >If there is a change needed in the core you need to explain what you
> >believe that change will do.

> I though this is straight but seems it is becoming more complex now.
> I will describe all this details if we agree to change require.

I still don't see any change needed here, from the above it simply looks
like the supplies aren't set up.

Re: exit_mmap BUG_ON in 2.6.23

Hugh Dickins — Sat, 19 May 2012 22:50:02 +0200

On Fri, 18 May 2012, Sam Portolla wrote:
> [please cc samPortolla@yahoo.com on your replies, not subscribed to the linux-kernel mailer]
>
> Hi, I have read the thread on same issue in 3.1:
> but this is happening on earlier GNU linux version 2.6.23 for x86_64,
> which does not have THP (I believe), nor it has huge_memory.c.
> Is there a fix one of you experts could supply? Issue is not reproducible
> so far, but happened on a customer site. Some info below.
>
> kernel BUG at .../bfc/linux/kernel-2.6.x/mm/mmap.c:2049!
>
> Line 2049 is in exit_mmap():
>
> BUG_ON(mm->nr_ptes > (FIRST_USER_ADDRESS+PMD_SIZE-1)>>PMD_SHIFT);
>
> RIP: 0010:[] [] exit_mmap+0xf0/0x100
> [snip]
> Call Trace:
> [] mmput+0x44/0xd0
> [] exit_mm+0x91/0x100
> [] do_exit+0x17a/0x960
> [] __dequeue_signal+0xec/0x1b0
> [] do_group_exit+0x38/0x90
> [] get_signal_to_deliver+0x2d6/0x4b0
> [] do_notify_resume+0xaa/0x760
> [] retint_signal+0x3d/0x85

I've checked back through old ChangeLogs, and (apart from a UserModeLinux
case) I don't see any fix for a BUG_ON(nr_ptes) issue in between 2.6.19
and the much later THP issue, which you're right to think cannot be yours.

But the 2.6.19 case, and one which a video driver writer had more recently,
were both caused by unrelated code zeroing beyond what it had allocated:
happening to zero part of a higher-level page table, making it impossible
for task exit to locate all the page tables (and pages) it had to free.

Though I can't be sure, these BUG_ON(nr_ptes) reports do seem perhaps
too infrequent to be caused by bad logic in mm itself: I suspect memory
corruption in your case too.

There's no clue here as to what the cause might be, I'm afraid.
Rebuilding your kernel with CONFIG_DEBUG_PAGEALLOC=y, and slab debugging
on, might shed more light: but that's probably not something you want to
get into on a customer site, for a problem only seen once or twice.

The best I can suggest is for you to change that BUG_ON to a WARN_ON,
so at least the kernel doesn't crash there, and you might gather more
information from each time it happens; but you'll probably leak pages,
and may very well crash soon for other reasons (e.g. when evicting an
inode cannot locate all the maps of its pages).

Hugh

Re: nginx on windows keeps hanging

itpp2012 — Sat, 19 May 2012 22:40:02 +0200

Remove the PHP_FCGI_x lines and add "fastcgi_ignore_client_abort on;"
For the pool add for all of them "weight=1 fail_timeout=5"

Posted at Nginx Forum: http://forum.nginx.org/read.php?2,226613,226656#msg-226656

_______________________________________________
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx