headers
Tejun Heo | 1 Dec 2009 01:01

[PATCH] percpu: explain quick paths in pcpu_[de]populate_chunk()

pcpu_[de]populate_chunk() check whether there's actually any work to
do at the beginning and exit early if not.  This checking is done by
seeing whether the first iteration of pcpu_for_each_[un]pop_region()
covers the whole requested region.  The resulting code is a bit
unusual in that it's loop-like but never loops which apparently
confuses people.  Add comments to explain it.

Signed-off-by: Tejun Heo <tj <at> kernel.org>
Reported-by: Amerigo Wang <amwang <at> redhat.com>
Cc: Christoph Lameter <cl <at> linux-foundation.org>
---
Added to percpu#for-next.  This should be clear enough, right?

 mm/percpu.c |   14 ++++++++++++--
 1 files changed, 12 insertions(+), 2 deletions(-)

diff --git a/mm/percpu.c b/mm/percpu.c
index 442010c..c264315 100644
--- a/mm/percpu.c
+++ b/mm/percpu.c
 <at>  <at>  -912,10 +912,15  <at>  <at>  static void pcpu_depopulate_chunk(struct pcpu_chunk *chunk, int off, int size)
 	unsigned long *populated;
 	int rs, re;

-	/* quick path, check whether it's empty already */
+	/*
+	 * Quick path, check whether it's already empty.  If the
+	 * region is completely empty, the first iteration will cover
+	 * the whole region.
+	 */
(Continue reading)

Permalink | Reply | 9 comments |
headers
Divyesh Shah | 1 Dec 2009 01:04
Picon
Favicon

Re: [PATCH 06/21] blkio: Introduce blkio controller cgroup interface

On Mon, Nov 30, 2009 at 8:29 AM, Vivek Goyal <vgoyal <at> redhat.com> wrote:
> o This is basic implementation of blkio controller cgroup interface. This is
>  the common interface visible to user space and should be used by different
>  IO control policies as we implement those.
>
> Signed-off-by: Vivek Goyal <vgoyal <at> redhat.com>
> ---
>  block/Kconfig                 |   13 +++
>  block/Kconfig.iosched         |    1 +
>  block/Makefile                |    1 +
>  block/blk-cgroup.c            |  177 +++++++++++++++++++++++++++++++++++++++++
>  block/blk-cgroup.h            |   58 +++++++++++++
>  include/linux/cgroup_subsys.h |    6 ++
>  include/linux/iocontext.h     |    4 +
>  7 files changed, 260 insertions(+), 0 deletions(-)
>  create mode 100644 block/blk-cgroup.c
>  create mode 100644 block/blk-cgroup.h
>
> diff --git a/block/Kconfig b/block/Kconfig
> index 9be0b56..6ba1a8e 100644
> --- a/block/Kconfig
> +++ b/block/Kconfig
>  <at>  <at>  -77,6 +77,19  <at>  <at>  config BLK_DEV_INTEGRITY
>        T10/SCSI Data Integrity Field or the T13/ATA External Path
>        Protection.  If in doubt, say N.
>
> +config BLK_CGROUP
> +       bool
> +       depends on CGROUPS
> +       default n
(Continue reading)

Permalink | Reply | 1 comment |
headers
Eric W. Biederman | 1 Dec 2009 01:12
Favicon

Re: [PATCH 0/15] sysfs lazification final

Greg KH <greg <at> kroah.com> writes:

> On Mon, Nov 30, 2009 at 01:33:37PM -0800, Greg KH wrote:
>> On Sat, Nov 07, 2009 at 11:25:03PM -0800, Eric W. Biederman wrote:
>> > 
>> > The sysfs code updates the vfs caches immediately when the sysfs data
>> > structures change causing a lot of unnecessary complications.  The
>> > following patchset untangles that beast.  Allowing for simpler
>> > more straight forward code, the removal of a hack from the vfs
>> > to support sysfs, and human comprehensible locking on sysfs.
>> > 
>> > Most of these patches have already been reviewed and acked from the
>> > last time I had time to work on sysfs.
>> > 
>> > This acks have been folded in and the two small bugs found in the
>> > previous review have been fixed in the trailing patches (they are
>> > minor enough nits that even a bisect that happens to land in the
>> > middle should not see sysfs problems).
>> 
>> I've applied all of these to my tree now, and sorry, but something is
>> broken pretty badly.
>> 
>> When doing a simple 'ls /sys/class/input/' the process locks up.  This
>> means that X can't find any input devices, which makes for a bit of a
>> problem when wanting to use your mouse or keyboard :(
>> 
>> Attached is the state of my processes when this happens, if that helps
>> out any.
>> 
>> So I'm going to drop all of these from my tree again, as they are not
(Continue reading)

Permalink | Reply | 0 comments |
headers
john stultz | 1 Dec 2009 01:12
Picon
Favicon

Re: Time nonlinearity (gettimeofday vs. mtime)

On Fri, Nov 27, 2009 at 5:31 AM, Matthias Urlichs <matthias <at> urlichs.de> wrote:
> Lately I've seen this ugliness:
>
> 13:39:06.000313 clock_gettime(CLOCK_REALTIME, {1259325546, 341196}) = 0 <0.000010>
> 13:39:06.000685 mkdir("/var/tmp/CP_FileTest_TempFolder_d0AOiP/tempFolder1", 0777) = 0 <0.000043>
> 13:39:06.000973 stat64("/var/tmp/CP_FileTest_TempFolder_d0AOiP/tempFolder1",
{st_dev=makedev(252, 2), st_ino=1919104, st_mode=S_IFDIR|0755, st_nlink=2, st_uid=501,
st_gid=501, st_blksize=4096, st_blocks=8, st_size=4096, st_atime=2009/11/27-13:39:05,
st_mtime=2009/11/27-13:39:05, st_ctime=2009/11/27-13:39:05}) = 0 <0.000015>
>
> This strace says that st.st_mtime is smaller than time.tv_sec even though the time was acquired earlier.
> Apparently, the problem is that ext3 uses a cached time value for performance.
>
> Question: Is there a reason that the cached time is not updated every time somebody calls gettimeofday()
or clock_gettime()?
> Or did just that nobody notice this problem yet?

This behavior is expected. For performance reasons (some clocksources
take 1.3us per read), most filesystem code uses current_kernel_time()
which provides the time at the last timer tick.

If you check mainline, there's a new CLOCK_REALTIME_COARSE clockid,
that provides the same behavior as the filesystem timestamps.

thanks
-john
Permalink | Reply | 0 comments |
headers
Rusty Russell | 1 Dec 2009 01:44
Picon
Gravatar

Re: [PATCH] sched: Fix isolcpus boot option

On Mon, 30 Nov 2009 10:35:32 am Anton Blanchard wrote:
> 
> We allocate and zero cpu_isolated_map after the isolcpus __setup option
> has run. This means cpu_isolated_map always ends up empty and if
> CPUMASK_OFFSTACK is enabled we write to a cpumask that hasn't been
> allocated.
> 
> To keep the fix to a minimum this patch stores a pointer to the cmdline
> option and parses it after we allocate and zero the cpumask.

I introduced this regression in:

	commit 49557e620339cb134127b5bfbcfecc06b77d0232
	Author: Rusty Russell <rusty <at> rustcorp.com.au>
	Date:   Mon Nov 2 20:37:20 2009 +1030

	    sched: Fix boot crash by zalloc()ing most of the cpu masks

But this change made isolcpus= never work, CPUMASK_OFFSTACK or no.

Your patch works and is minimal.

Acked-by: Rusty Russell <rusty <at> rustcorp.com.au>

Thanks,
Rusty.

PS. This would have also worked:

diff --git a/kernel/sched.c b/kernel/sched.c
(Continue reading)

Permalink | Reply | 0 comments |
headers
James Y Knight | 1 Dec 2009 01:48

Re: writev data loss bug in (at least) 2.6.31 and 2.6.32pre8 x86-64


On Nov 30, 2009, at 3:55 PM, James Y Knight wrote:

> This test case fails in 2.6.23-2.6.25, because of the bug fixed in
864f24395c72b6a6c48d13f409f986dc71a5cf4a, and now again in at least 2.6.31 and 2.6.32pre8 because of
a *different* bug. This test *does not* fail 2.6.26. I have not tested anything between 2.6.26 and 2.6.31.
> 
> The bug in 2.6.31 is definitely not the same bug as 2.6.23's. This time, the zero'd area of the file doesn't
show up immediately upon writing the file. Instead, the kernel waits to mangle the file until it has to
flush the buffer to disk. *THEN* it zeros out parts of the file.
> 
> So, after writing out the new file with writev, and checking the md5sum (which is correct), this test case
asks the kernel to flush the cache for that file, and then checks the md5sum again. ONLY THEN is the file
corrupted. That is, I won't hesitate to say *incredibly evil* behavior: it took me quite some time to
figure out WTH was going wrong with my program before determining it was a kernel bug.
> 
> This test case is distilled from an actual application which doesn't even intentionally use writev: it
just uses C++'s ofstream class to write data to a file. Unfortunately, that class smart and uses writev
under the covers. Unfortunately, I guess nobody ever tests linux writev behavior, since it's broken
_so_much_of_the_time_. I really am quite astounded to see such a bad track record for such a fundamental
core system call....
> 
> My /tmp is an ext3 filesystem, in case that matters.

Further testing shows that the filesystem type *does* matter. The bug does not exhibit when the test is run
on ext2, ext4, vfat, btrfs, jfs, or xfs (and probably all the others too). Only, so far as I can determine, on ext3.

Thanks,
James--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
(Continue reading)

Permalink | Reply | 0 comments |
headers
Hidetoshi Seto | 1 Dec 2009 02:02
Favicon

Re: [PATCH 2/2] cputime: introduce thread_group_times()

Stanislaw Gruszka wrote:
> Idea is very good IMHO.

Thank you very much!

>>  #ifndef CONFIG_VIRT_CPU_ACCOUNTING
>> -	cputime_t prev_utime, prev_stime;
>> +	cputime_t prev_utime, prev_stime, prev_tgutime, prev_tgstime;
>>  #endif
> 
> I think the new values should be part of struct_signal (see below)

Good point.  I'll update patch to do so.

>>  /*
>> + * Must be called with siglock held.
>> + */
>> +void thread_group_times(struct task_struct *p, cputime_t *ut, cputime_t *st)
>> +{
>> +	struct task_cputime cputime;
>> +
>> +	__thread_group_times(p, &cputime);
>> +
>> +	if (ut)
>> +		*ut = cputime.utime;
>> +	if (st)
>> +		*st = cputime.stime;
> 
> No thread_group_times() nor task_times() is called with NULL arguments, we
> can get rid of "if ({u,s}t)" checks. Perhaps thread_group_times() should
(Continue reading)

Permalink | Reply | 0 comments |
headers
Helight.Xu | 1 Dec 2009 02:09
Picon

Re: Subject: [PATCH 2/2] fix a Section mismatch in arch/x86/pci/mmconfig-shared.c and include/linux/sfi_acpi.h

H. Peter Anvin wrote:
> Hi Len,
>
> Do you want to take this one or should I?
>   
ooh! both ok！thing is that we fix the problem!
> 	-hpa
>
>
> On 11/30/2009 02:38 AM, helight wrote:
>   
>> acpi_sfi_table_parse() should be __init. tested on x86 system!
>>     
>
>   

--

-- 
---------------------------------
Zhenwen Xu - Open and Free
Home Page:	http://zhwen.org
Permalink | Reply | 0 comments |
headers
Yinghai Lu | 1 Dec 2009 02:19

[PATCH 1/2] pci: pci_bridge_release_res

need to apply this after 9/9 patchset

prepare for pciehp_realloc

it will clear the resource size for bridge

Signed-off-by: Yinghai Lu <yinghai <at> kernel.org>

---
 drivers/pci/setup-bus.c |   42 ++++++++++++++++++++++++++++++++++++++++++
 include/linux/pci.h     |    1 +
 2 files changed, 43 insertions(+)

Index: linux-2.6/drivers/pci/setup-bus.c
===================================================================
--- linux-2.6.orig/drivers/pci/setup-bus.c
+++ linux-2.6/drivers/pci/setup-bus.c
 <at>  <at>  -739,6 +739,48  <at>  <at>  static void __ref __pci_bridge_assign_re
 		break;
 	}
 }
+
+void pci_bridge_release_res(struct pci_bus *bus)
+{
+	int idx;
+	bool changed = false;
+	struct pci_dev *dev;
+	struct resource *r;
+
+	/* The root bus? */
(Continue reading)

Permalink | Reply | 2 comments |
headers
Ping Cheng | 1 Dec 2009 02:31
Favicon

[PATCH] serial/8250_pnp.c: add new Wacom devices

This is a resend. I forgot to update the subject line last time. I am
not in the mailing list. Please cc me with your reply.  Thank you.

Add 10 serial Wacom Tablet PC devices. In fact, 
The last 3 bytes of WACF### are all reserved 
for Wacom serial OEMs.

Signed-off-by: Ping Cheng <pingc <at> wacom.com>
---
 drivers/serial/8250_pnp.c |   11 +++++++++++
 1 files changed, 11 insertions(+), 0 deletions(-)

diff --git a/drivers/serial/8250_pnp.c b/drivers/serial/8250_pnp.c
index d71dfe3..898c0f0 100644
--- a/drivers/serial/8250_pnp.c
+++ b/drivers/serial/8250_pnp.c
 <at>  <at>  -337,6 +337,15  <at>  <at>  static const struct pnp_device_id pnp_dev_table[] =
{
 	{       "WACF00A",              0       },
 	{       "WACF00B",              0       },
 	{       "WACF00C",              0       },
+	{       "WACF00D",              0       },
+	{       "WACF00E",              0       },
+	{       "WACF00F",              0       },
+	{       "WACF010",              0       },
+	{       "WACF011",              0       },
+	{       "WACF012",              0       },
+	{       "WACF013",              0       },
+	{       "WACF014",              0       },
+	{       "WACF015",              0       },
(Continue reading)

Permalink | Reply | 1 comment |

Gmane