Re: [PATCH 00/33] AutoNUMA27

[Andrea Arcangeli]

Hi Srikar,

On Sun, Oct 14, 2012 at 12:10:19AM +0530, Srikar Dronamraju wrote:
> * Andrea Arcangeli  [2012-10-04 01:50:42]:
> 
> > Hello everyone,
> > 
> > This is a new AutoNUMA27 release for Linux v3.6.
> > 
> 
> 
> Here results of autonumabenchmark on a 328GB 64 core with ht disabled
> comparing v3.6 with autonuma27.

*snip*

>   numa01: 1805.19  1907.11  1866.39-3.88%  

Interesting. So numa01 should be improved in autonuma28fast. Not sure
why the hard binds show any difference, but I'm more concerned in
optimizing numa01. I get the same results from hard bindings on
upstream or autonuma, strange.

Could you repeat only numa01 with the origin/autonuma28fast branch?
Also if you could post the two pdf convergence chart generated by
numa01 on autonuma27 and autonuma28fast, I think that would be
interesting to see the full effect and why it is faster.

I only had the time for a quick push after having the idea added in
autonuma28fast (which is yet improved compared to autonuma28), but
I've been told already that it's dealing with numa01 on the 8 node
very well as expected.

numa01 in the 8 node is a workload without a perfect solution (other
than MADV_INTERLEAVE). Full convergence preventing cross-node traffic
is impossible because there are 2 processes spanning over 8 nodes and
all process memory is touched by all threads constantly. Yet
autonuma28fast should deal optimally that scenario too.

As a side note: numa01 on the 2 node instead converges fully (2
processes + 2 nodes = full convergence). numa01 on 2 nodes or >2nodes
is a very different kind of test.

I'll release an autonuma29 behaving like 28fast if there are no
surprises. The new algorithm change in 28fast will also save memory
once I rewrite it properly.

Thanks!
Andrea
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 RFC] brd: Add miscdevice to control creation and deletion of ramdisks

[Hannes Frederic Sowa]

On Sun, Oct 14, 2012 at 04:48:36AM +0200, Hannes Frederic Sowa wrote:
> + case BRD_CTL_DEL:
> + error = get_user(val, (int __user *)param);
> + if (error < 0)
> + break;
> + if ((val & max_part) != 0) {
> + error = -EINVAL;
> + break;
> + }
> + val >>= part_shift;
> + brd2 = NULL;
> + list_for_each_entry(brd, _devices, brd_list) {
> + if (brd->brd_number == val) {
> + brd2 = brd;
> + break;
> + }
> + }
> + if (brd2 == NULL) {
> + error = -ENODEV;
> + break;
> + }
> + brd_del_one(brd2);
> + break;

Sorry, first bug spotted. I should check the bd_openers before destroying the
device. Will be fixed in a follow-up patch, if needed.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] MM: Support more pagesizes for MAP_HUGETLB/SHM_HUGETLB v5

[Hillf Danton]

Hi Andi,

On Sat, Oct 13, 2012 at 11:38 PM, Andi Kleen  wrote:
> v2: Port to new tree. Fix unmount.
> v3: Ported to latest tree.
> v4: Ported to latest tree. Minor changes for review feedback. Updated
> description.
> v5: Remove unnecessary prototypes to fix merge error (Hillf Dalton)

s/Dalton/Danton/

>  struct file *hugetlb_file_setup(const char *name, unsigned long addr,
> size_t size, vm_flags_t acctflag,
> -   struct user_struct **user, int creat_flags)
> +   struct user_struct **user,
> +   int creat_flags, int page_size_log)
>  {
> int error = -ENOMEM;
> struct file *file;
> @@ -944,9 +957,14 @@ struct file *hugetlb_file_setup(const char *name, 
> unsigned long addr,
> struct qstr quick_string;
> struct hstate *hstate;
> unsigned long num_pages;
> +   int hstate_idx;
> +
> +   hstate_idx = get_hstate_idx(page_size_log);
> +   if (hstate_idx < 0)
> +   return ERR_PTR(-ENODEV);
>
> *user = NULL;
> -   if (!hugetlbfs_vfsmount)
> +   if (!hugetlbfs_vfsmount[hstate_idx])

Maybe
if (IS_ERR(hugetlbfs_vfsmount[hstate_idx]))
since ...

>  static int __init init_hugetlbfs_fs(void)
>  {
> +   struct hstate *h;
> int error;
> -   struct vfsmount *vfsmount;
> +   int i;
>
> error = bdi_init(_backing_dev_info);
> if (error)
> @@ -1029,14 +1048,26 @@ static int __init init_hugetlbfs_fs(void)
> if (error)
> goto out;
>
> -   vfsmount = kern_mount(_fs_type);
> +   i = 0;
> +   for_each_hstate (h) {
> +   char buf[50];
> +   unsigned ps_kb = 1U << (h->order + PAGE_SHIFT - 10);
>
> -   if (!IS_ERR(vfsmount)) {
> -   hugetlbfs_vfsmount = vfsmount;
> -   return 0;
> -   }
> +   snprintf(buf, sizeof buf, "pagesize=%uK", ps_kb);
> +   hugetlbfs_vfsmount[i] = kern_mount_data(_fs_type,
> +   buf);
>
> -   error = PTR_ERR(vfsmount);
> +   if (IS_ERR(hugetlbfs_vfsmount[i])) {
> +   pr_err(
> +   "hugetlb: Cannot mount internal hugetlbfs for page 
> size %uK",
> +  ps_kb);
> +   error = PTR_ERR(hugetlbfs_vfsmount[i]);

... hugetlbfs_vfsmount[i] is not reset.

> +   }
> +   i++;
> +   }
> +   /* Non default hstates are optional */
> +   if (hugetlbfs_vfsmount[default_hstate_idx])

ditto.

BTW, resetting looks simpler?

> +   return 0;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 RFC] brd: Add miscdevice to control creation and deletion of ramdisks

[Hannes Frederic Sowa]

While toying around with a library which needs small block devices for
quorum management, I came up with this small patch to dynamically create
and destroy ram disks (I wanted to have non-swappable backed devices).

I am not really comfortable with the the double-use of the ioctl parameter
of BRD_CTL_ADD passing the size and returning the minor id. But it seemed
the easiest way to go.  I even don't know if going the ioctl-route is
the right way.

Currently new minor ids are allocated strictly sequential. Deleted ones
won't get reused. If the ioctl way is the way to go, I may change the
bookkeeping to idrs. Feedback appreciated!

This patch is against 3.6.

This patch adds the miscdevice /dev/brd-control with two ioctls:

  1) BRD_CTL_ADD: Instantiates a new ram disk with a given size as
 parameter. This parameter is filled in with the new minor id
 on return.

  2) BRD_CTL_DEL: Deletes a ram disk. Takes the minor id as parameter.

Signed-off-by: Hannes Frederic Sowa 
---
 Documentation/ioctl/ioctl-number.txt |   1 +
 drivers/block/brd.c  | 115 ---
 include/linux/Kbuild |   1 +
 include/linux/brd.h  |  11 
 include/linux/miscdevice.h   |   1 +
 5 files changed, 122 insertions(+), 7 deletions(-)
 create mode 100644 include/linux/brd.h

diff --git a/Documentation/ioctl/ioctl-number.txt 
b/Documentation/ioctl/ioctl-number.txt
index 849b771..b8827eb 100644
--- a/Documentation/ioctl/ioctl-number.txt
+++ b/Documentation/ioctl/ioctl-number.txt
@@ -326,4 +326,5 @@ Code  Seq#(hex) Include FileComments

 0xF6   all LTTng   Linux Trace Toolkit Next Generation

+0xF7   00-01   drivers/block/brd.c block ram device control driver
 0xFD   all linux/dm-ioctl.h
diff --git a/drivers/block/brd.c b/drivers/block/brd.c
index 531ceb3..7401de7 100644
--- a/drivers/block/brd.c
+++ b/drivers/block/brd.c
@@ -19,6 +19,9 @@
 #include 
 #include 
 #include 
+#include 
+#include 
+#include 
 
 #include 
 
@@ -460,7 +463,7 @@ __setup("ramdisk_size=", ramdisk_size);
 static LIST_HEAD(brd_devices);
 static DEFINE_MUTEX(brd_devices_mutex);
 
-static struct brd_device *brd_alloc(int i)
+static struct brd_device *brd_alloc(int i, int size_kb)
 {
struct brd_device *brd;
struct gendisk *disk;
@@ -494,7 +497,7 @@ static struct brd_device *brd_alloc(int i)
disk->queue = brd->brd_queue;
disk->flags |= GENHD_FL_SUPPRESS_PARTITION_INFO;
sprintf(disk->disk_name, "ram%d", i);
-   set_capacity(disk, rd_size * 2);
+   set_capacity(disk, size_kb * 2);
 
return brd;
 
@@ -523,7 +526,7 @@ static struct brd_device *brd_init_one(int i)
goto out;
}
 
-   brd = brd_alloc(i);
+   brd = brd_alloc(i, rd_size);
if (brd) {
add_disk(brd->brd_disk);
list_add_tail(>brd_list, _devices);
@@ -553,9 +556,97 @@ static struct kobject *brd_probe(dev_t dev, int *part, 
void *data)
return kobj;
 }
 
+static long brd_control_ioctl(struct file *file, unsigned int cmd,
+   unsigned long param)
+{
+   int error = -ENOSYS;
+   int size_kb, val;
+   struct brd_device *brd, *brd2;
+
+   if (rd_nr)
+   return -EINVAL;
+
+   mutex_lock(_devices_mutex);
+   switch (cmd) {
+   case BRD_CTL_ADD:
+   error = get_user(size_kb, (int __user *)param);
+   if (error < 0)
+   break;
+   if (size_kb < 0) {
+   error = -EINVAL;
+   break;
+   }
+   val = 0;
+   list_for_each_entry(brd, _devices, brd_list) {
+   val = max(val, 1 + brd->brd_number);
+   }
+   if (val >= (MINORMASK >> part_shift)) {
+   error = -EINVAL;
+   break;
+   }
+   brd = brd_alloc(val, size_kb);
+   if (brd == NULL) {
+   error = -ENOMEM;
+   break;
+   }
+   list_add_tail(>brd_list, _devices);
+   add_disk(brd->brd_disk);
+   val <<= part_shift;
+   error = put_user(val, (int __user *)param);
+   if (error < 0)
+   break;
+   error = 0;
+   break;
+   case BRD_CTL_DEL:
+   error = get_user(val, (int __user *)param);
+   if (error < 0)
+   break;
+   if ((val & max_part) != 0) {
+   error = -EINVAL;
+   break;
+   }
+   val >>= part_shift;
+   brd2 = NULL;
+   list_for_each_entry(brd, 

Re: Local DoS through write heavy I/O on CFQ & Deadline

[Hillf Danton]

On Sun, Oct 14, 2012 at 3:33 AM, Alex Bligh  wrote:
> Or perhaps I have the wrong end of the stick.

Never mind a friendly link:)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [GIT PULL] UAPI disintegration for include/linux/{,byteorder/}*.h

[Linus Torvalds]

David,
 I want to make it very clear that if you *ever* suggest another big
include file cleanup, I will say "f*ck no" and block you from my
emails forever. Ok? So don't bother. We're done with these kinds of
games. Forever. It's not worth it, don't ever suggest it again for
some other "cleanup".

In the meantime, please fix the fact that "tools/perf" broke. I
suspect the only way to fix it is to teach perf to be compiled with
the proper "-I" incantation and a lot of header file changes. Right
now it uses things like

   #include "../../../include/linux/perf_event.h"

which was broken by this pull. Sadly, I noticed too late, and the
broken mess is long pushed out.

  Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [GIT PULL] (xen) stable/for-linus-3.7-uapi-tag for v3.7-rc0

[Randy Dunlap]

On 10/12/2012 07:16 PM, Linus Torvalds wrote:

> On Fri, Oct 12, 2012 at 10:45 PM, Konrad Rzeszutek Wilk
>  wrote:
>>
>> Please pull!
> 
> Btw, please use the -M switch to get renames as renames (and
> --summary). You diffstat:
> 
>>  include/uapi/xen/Kbuild|2 +
>>  include/uapi/xen/evtchn.h  |   88 +++
>>  include/uapi/xen/privcmd.h |   98 
>> 
>>  include/xen/Kbuild |2 -
>>  include/xen/evtchn.h   |   88 ---
>>  include/xen/privcmd.h  |   98 
>> 
>>  6 files changed, 188 insertions(+), 188 deletions(-)
> 
> is misleading, the correct one is much simpler:
> 
>  include/{ => uapi}/xen/evtchn.h  | 0
>  include/{ => uapi}/xen/privcmd.h | 0
>  include/xen/Kbuild   | 2 --
>  4 files changed, 2 insertions(+), 2 deletions(-)
>  rename include/{ => uapi}/xen/evtchn.h (100%)
>  rename include/{ => uapi}/xen/privcmd.h (100%)


showing once again that people don't read documentation  :(

(see Documentation/SubmittingPatches)

-- 
~Randy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 0/2] RFC SLUB: increase range of kmalloc slab sizes

[Andi Kleen]

Richard Kennedy  writes:

> This patch increases the range of slab sizes available to kmalloc, adding
> slabs half way between the existing power of two sized ones, so allowing 
> slightly
>  more efficient use of memory.
> Most of the new slabs already exist as kmem_cache slabs so only the 1.5k,3k & 
> 6k 
> are entirely new.

I'm not sure what order slab/slub use by default these days, but for
order 0 none of your new sizes sound like a winner:

4K / 1.5 = 2  = 4K / 2K 
4K / 3K  = 1  = 4K / 4K
8K / 6K  = 1  = 8K / 8K

I think you need better data that it actually saves memory with some
reproducible workloads.

Revisiting the sizes is a good idea -- the original Bonwick slab paper
explicitely recommended against power of twos -- but I think it needs a
more data driven process to actually select better ones than what you
used.

Most likely the best fits are different between 32bit and 64bit
and also will change occasionally as kernel data structures grow
(or rarely shrink)

In fact I suspect it would be an interesting option for feedback
control for embedded kernels - measure workload, reboot/recompile with
slab fitting the workload well.

So I think before trying any of this you need a good slab profiler
and a good set of workloads.

-Andi

-- 
a...@linux.intel.com -- Speaking for myself only
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] mm: cleanup register_node()

[KOSAKI Motohiro]

On Fri, Oct 12, 2012 at 4:22 AM, Yasuaki Ishimatsu
 wrote:
> register_node() is defined as extern in include/linux/node.h. But the function
> is only called from register_one_node() in driver/base/node.c.
>
> So the patch defines register_node() as static.
>
> CC: David Rientjes 
> CC: Andrew Morton 
> Signed-off-by: Yasuaki Ishimatsu 

Acked-by: KOSAKI Motohiro 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] usb: acm: fix the computation of the number of data bits

[Nicolas Boullis]

From: Nicolas Boullis 

The current code assumes that CSIZE is 060, which appears to be 
wrong on some arches (such as powerpc).

Signed-off-by: Nicolas Boullis 
---
diff --git a/drivers/usb/class/cdc-acm.c b/drivers/usb/class/cdc-acm.c
index 981f213..194fa8b 100644
--- a/drivers/usb/class/cdc-acm.c
+++ b/drivers/usb/class/cdc-acm.c
@@ -817,10 +817,6 @@ static const __u32 acm_tty_speed[] = {
250, 300, 350, 400
 };
 
-static const __u8 acm_tty_size[] = {
-   5, 6, 7, 8
-};
-
 static void acm_tty_set_termios(struct tty_struct *tty,
struct ktermios *termios_old)
 {
@@ -834,7 +830,21 @@ static void acm_tty_set_termios(struct tty_struct *tty,
newline.bParityType = termios->c_cflag & PARENB ?
(termios->c_cflag & PARODD ? 1 : 2) +
(termios->c_cflag & CMSPAR ? 2 : 0) : 0;
-   newline.bDataBits = acm_tty_size[(termios->c_cflag & CSIZE) >> 4];
+   switch (termios->c_cflag & CSIZE) {
+   case CS5:
+   newline.bDataBits = 5;
+   break;
+   case CS6:
+   newline.bDataBits = 6;
+   break;
+   case CS7:
+   newline.bDataBits = 7;
+   break;
+   case CS8:
+   default:
+   newline.bDataBits = 8;
+   break;
+   }
/* FIXME: Needs to clear unsupported bits in the termios */
acm->clocal = ((termios->c_cflag & CLOCAL) != 0);
 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 11/16] f2fs: add inode operations for special inodes

[Vyacheslav Dubeyko]

On Oct 14, 2012, at 12:52 AM, Arnd Bergmann wrote:

> On Friday 05 October 2012, 김재극 wrote:
>> +const char *media_ext_lists[] = {
>> +   "jpg",
>> +   "gif",
>> +   "png",
>> +   "avi",
>> +   "divx",
>> +   "mp4",
>> +   "mp3",
>> ...
> 
>> + * Set multimedia files as cold files for hot/cold data separation
>> + */
>> +static inline void set_cold_file(struct inode *inode, const unsigned char 
>> *name)
>> +{
>> +   const char **extlist = media_ext_lists;
>> +
>> +   while (*extlist) {
>> +   if (!is_multimedia_file(name, *extlist)) {
>> +   F2FS_I(inode)->is_cold = 1;
>> +   break;
>> +   }
>> +   extlist++;
>> +   }
>> +}
> 
> This is a very clever way of categorizing files by their name, but I wonder 
> if hardcoding
> the list of file name extensions at in the kernel source is the best 
> strategy. Generally
> I would consider this to be a policy that should be configurable by the user.
> 
> Unfortunately I can't think of a good interface to configure this, but maybe 
> someone
> else has a useful idea. Maybe the list can be stored in the superblock and 
> get written
> at mkfs time from the same defaults, but with the option of overriding it 
> using
> a debugfs tool.
> 

By the way, how about extended attributes? It is possible to save in extended 
attribute a hint about file's content nature during creation operation or 
later. Moreover, extended attribute gives possibility to change hint after 
renaming operation, for example.

With the best regards,
Vyacheslav Dubeyko.

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

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] rtc: davinci: clean up probe/remove routines

[Hannu Heikkinen]

Use the devres managed resource functions in the probe routine.
Also affects the remove routine where the previously used free and
release functions are not needed.

The devm_* functions eliminate the need for manual resource releasing and
simplify error handling.  Resources allocated by devm_* are freed
automatically on driver detach.

Signed-off-by: Hannu Heikkinen 
---
 drivers/rtc/rtc-davinci.c | 56 +--
 1 file changed, 15 insertions(+), 41 deletions(-)

diff --git a/drivers/rtc/rtc-davinci.c b/drivers/rtc/rtc-davinci.c
index 14c2109..ffb09c2 100644
--- a/drivers/rtc/rtc-davinci.c
+++ b/drivers/rtc/rtc-davinci.c
@@ -119,8 +119,6 @@ static DEFINE_SPINLOCK(davinci_rtc_lock);
 struct davinci_rtc {
struct rtc_device   *rtc;
void __iomem*base;
-   resource_size_t pbase;
-   size_t  base_size;
int irq;
 };
 
@@ -482,22 +480,16 @@ static int __init davinci_rtc_probe(struct 
platform_device *pdev)
 {
struct device *dev = >dev;
struct davinci_rtc *davinci_rtc;
-   struct resource *res, *mem;
+   struct resource *res;
int ret = 0;
 
-   davinci_rtc = kzalloc(sizeof(struct davinci_rtc), GFP_KERNEL);
+   davinci_rtc = devm_kzalloc(>dev, sizeof(struct tegra_rtc_info),
+   GFP_KERNEL);
if (!davinci_rtc) {
dev_dbg(dev, "could not allocate memory for private data\n");
return -ENOMEM;
}
 
-   davinci_rtc->irq = platform_get_irq(pdev, 0);
-   if (davinci_rtc->irq < 0) {
-   dev_err(dev, "no RTC irq\n");
-   ret = davinci_rtc->irq;
-   goto fail1;
-   }
-
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
if (!res) {
dev_err(dev, "no mem resource\n");
@@ -505,23 +497,16 @@ static int __init davinci_rtc_probe(struct 
platform_device *pdev)
goto fail1;
}
 
-   davinci_rtc->pbase = res->start;
-   davinci_rtc->base_size = resource_size(res);
-
-   mem = request_mem_region(davinci_rtc->pbase, davinci_rtc->base_size,
-pdev->name);
-   if (!mem) {
-   dev_err(dev, "RTC registers at %08x are not free\n",
-   davinci_rtc->pbase);
-   ret = -EBUSY;
-   goto fail1;
+   davinci_rtc->base = devm_request_and_ioremap(>dev, res);
+   if (!davinci_rtc->base) {
+   dev_err(>dev, "Unable to request mem region and grab IOs 
for device.\n");
+   return -EBUSY;
}
 
-   davinci_rtc->base = ioremap(davinci_rtc->pbase, davinci_rtc->base_size);
-   if (!davinci_rtc->base) {
-   dev_err(dev, "unable to ioremap MEM resource\n");
-   ret = -ENOMEM;
-   goto fail2;
+   davinci_rtc->irq = platform_get_irq(pdev, 0);
+   if (davinci_rtc->irq < 0) {
+   dev_err(dev, "no RTC irq\n");
+   return davinci_rtc->irq;
}
 
platform_set_drvdata(pdev, davinci_rtc);
@@ -529,9 +514,10 @@ static int __init davinci_rtc_probe(struct platform_device 
*pdev)
davinci_rtc->rtc = rtc_device_register(pdev->name, >dev,
_rtc_ops, THIS_MODULE);
if (IS_ERR(davinci_rtc->rtc)) {
+   ret = PTR_ERR(davinci_rtc->rtc);
dev_err(dev, "unable to register RTC device, err %ld\n",
PTR_ERR(davinci_rtc->rtc));
-   goto fail3;
+   return ret;
}
 
rtcif_write(davinci_rtc, PRTCIF_INTFLG_RTCSS, PRTCIF_INTFLG);
@@ -545,7 +531,7 @@ static int __init davinci_rtc_probe(struct platform_device 
*pdev)
  0, "davinci_rtc", davinci_rtc);
if (ret < 0) {
dev_err(dev, "unable to register davinci RTC interrupt\n");
-   goto fail4;
+   goto err_dev_unreg;
}
 
/* Enable interrupts */
@@ -559,15 +545,8 @@ static int __init davinci_rtc_probe(struct platform_device 
*pdev)
 
return 0;
 
-fail4:
+err_dev_unreg:
rtc_device_unregister(davinci_rtc->rtc);
-fail3:
-   platform_set_drvdata(pdev, NULL);
-   iounmap(davinci_rtc->base);
-fail2:
-   release_mem_region(davinci_rtc->pbase, davinci_rtc->base_size);
-fail1:
-   kfree(davinci_rtc);
 
return ret;
 }
@@ -584,13 +563,8 @@ static int __devexit davinci_rtc_remove(struct 
platform_device *pdev)
 
rtc_device_unregister(davinci_rtc->rtc);
 
-   iounmap(davinci_rtc->base);
-   release_mem_region(davinci_rtc->pbase, davinci_rtc->base_size);
-
platform_set_drvdata(pdev, NULL);
 
-   kfree(davinci_rtc);
-
return 0;
 }
 
-- 
1.7.12.2

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to 

Re: [PATCH 20/25] sparc: Use Kbuild infrastructure to handle asm-generic headers

[Steven Rostedt]

On Sat, 2012-10-13 at 17:54 -0400, David Miller wrote:

> I really would like to take less rather than take more.
> 
> This whole UAPI, Kbuild, etc. stuff is just bogging subsystem
> maintainers down.  This kind of stuff should just go via the person
> who does all the work and knows how it all ties together and knows
> what dependencies, if any, exist in the series.
> 
> So please merge this yourself, thanks.

OK, will do.

-- Steve


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 11/16] f2fs: add inode operations for special inodes

[Vyacheslav Dubeyko]

On Oct 14, 2012, at 12:52 AM, Arnd Bergmann wrote:

> On Friday 05 October 2012, 김재극 wrote:
>> +const char *media_ext_lists[] = {
>> +   "jpg",
>> +   "gif",
>> +   "png",
>> +   "avi",
>> +   "divx",
>> +   "mp4",
>> +   "mp3",
>> ...
> 
>> + * Set multimedia files as cold files for hot/cold data separation
>> + */
>> +static inline void set_cold_file(struct inode *inode, const unsigned char 
>> *name)
>> +{
>> +   const char **extlist = media_ext_lists;
>> +
>> +   while (*extlist) {
>> +   if (!is_multimedia_file(name, *extlist)) {
>> +   F2FS_I(inode)->is_cold = 1;
>> +   break;
>> +   }
>> +   extlist++;
>> +   }
>> +}
> 
> This is a very clever way of categorizing files by their name, but I wonder 
> if hardcoding
> the list of file name extensions at in the kernel source is the best 
> strategy. Generally
> I would consider this to be a policy that should be configurable by the user.
> 

I think that file extensions can't be a steady basis for categorization. It is 
possible that user can use any extension as you want during file naming (for 
example, save text file with png extension). Or it is possible to use file 
without any extension. Only magics in a file structure can be a steady basis. 
But analyzing of file structure on the file system driver level is a breaking 
of some fundamentals, from my point of view.

With the best regards,
Vyacheslav Dubeyko.

> Unfortunately I can't think of a good interface to configure this, but maybe 
> someone
> else has a useful idea. Maybe the list can be stored in the superblock and 
> get written
> at mkfs time from the same defaults, but with the option of overriding it 
> using
> a debugfs tool.
> 
>   Arnd
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 20/25] sparc: Use Kbuild infrastructure to handle asm-generic headers

[David Miller]

From: Steven Rostedt 
Date: Sat, 13 Oct 2012 09:54:00 -0400

> On Fri, 2012-10-12 at 23:19 -0400, David Miller wrote:
>> From: Steven Rostedt 
>> Date: Fri, 12 Oct 2012 22:26:52 -0400
>> 
>> > From: Steven Rostedt 
>> > 
>> > Use Kbuild infrastructure to handle the asm-generic headers
>> > and remove the wrapper headers that call them.
>> > 
>> > This only affects headers that do nothing but include the generic
>> > equivalent. It does not touch any header that does a little more.
>> > 
>> > Cc: linux-kbu...@vger.kernel.org
>> > Cc: sparcli...@vger.kernel.org
>> > Cc: "David S. Miller" 
>> > Signed-off-by: Steven Rostedt 
>> 
>> Acked-by: David S. Miller 
> 
> David,
> 
> Would you like to take this patch? It's not dependent on any of the
> other patches. Otherwise I'll probably ask Andrew to pull it into his
> tree. Or I can just set up a branch and have it go into linux-next for
> the next merge window.

I really would like to take less rather than take more.

This whole UAPI, Kbuild, etc. stuff is just bogging subsystem
maintainers down.  This kind of stuff should just go via the person
who does all the work and knows how it all ties together and knows
what dependencies, if any, exist in the series.

So please merge this yourself, thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/2] UAPI: Unexport part of linux/ppp-comp.h

[David Miller]

From: David Howells 
Date: Sat, 13 Oct 2012 10:08:10 +0100

> Unexport part of linux/ppp-comp.h as userspace can't make use of that bit.
> 
> Signed-off-by: David Howells 

Acked-by: David S. Miller 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [GIT PULL] Disintegrate UAPI for usb

[Greg KH]

On Tue, Oct 09, 2012 at 02:30:48PM +0100, David Howells wrote:
> Can you merge the following branch into the usb tree please.
> 
> This is to complete part of the Userspace API (UAPI) disintegration for which
> the preparatory patches were pulled recently.  After these patches, userspace
> headers will be segregated into:
> 
>   include/uapi/linux/.../foo.h
> 
> for the userspace interface stuff, and:
> 
>   include/linux/.../foo.h
> 
> for the strictly kernel internal stuff.
> 
> ---
> The following changes since commit 9e2d8656f5e8aa214e66b462680cf86b210b74a8:
> 
>   Merge branch 'akpm' (Andrew's patch-bomb) (2012-10-09 16:23:15 +0900)
> 
> are available in the git repository at:
> 
> 
>   git://git.infradead.org/users/dhowells/linux-headers.git 
> tags/disintegrate-usb-20121009
> 
> for you to fetch changes up to 5e1ddb481776a487b15b40579a000b279ce527c9:
> 
>   UAPI: (Scripted) Disintegrate include/linux/usb (2012-10-09 09:49:07 +0100)

Now pulled, thanks.

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

[PULL REQ] IXP4xx changes for Linux 3.7

[Krzysztof Halasa]

Linus,

please pull my ARM IXP4xx changes for 3.7:

The following changes since commit 4d7127dace8cf4b05eb7c8c8531fc204fbb195f4:

"Merge branch 'for-linus' of git://git.kernel.org/.../jmorris/linux-security"
(2012-10-13 11:29:00 +0900)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/chris/linux.git next

for you to fetch changes up to b94740b3b38fd8e37fcd3bb06a18ec2796061c7d:
  IXP4xx: use __iomem for MMIO (2012-10-13 20:37:30 +0200)

Build-tested for now. This is based on your current tree tip because it
depends on commits following 3.6 release.

Thanks.


Arnd Bergmann (1):
  IXP4xx: use __iomem for MMIO

Krzysztof Hałasa (9):
  IXP4xx: Fix Goramo MultiLink platform compilation.
  IXP4xx: Fix off-by-one bug in Goramo MultiLink platform.
  IXP4xx: HW pseudo-random generator is available on IXP45x/46x only.
  IXP4xx: ixp4xx_crypto driver requires Queue Manager and NPE drivers.
  IXP4xx: Remove time limit for PCI TRDY to enable use of slow devices.
  WAN: Remove redundant HDLC info printed by IXP4xx HSS driver.
  IXP4xx crypto: MOD_AES{128,192,256} already include key size.
  IXP4xx: Always ioremap() Queue Manager MMIO region at boot.
  IXP4xx: map CPU config registers within VMALLOC region.

Tim Gardner (1):
  ixp4xx: Declare MODULE_FIRMWARE usage

 arch/arm/mach-ixp4xx/common-pci.c   |  1 +
 arch/arm/mach-ixp4xx/common.c   | 13 +
 arch/arm/mach-ixp4xx/goramo_mlr.c   |  3 ++-
 arch/arm/mach-ixp4xx/include/mach/debug-macro.S |  4 ++--
 arch/arm/mach-ixp4xx/include/mach/ixp4xx-regs.h | 46 
+++--
 arch/arm/mach-ixp4xx/include/mach/qmgr.h| 12 ++--
 arch/arm/mach-ixp4xx/ixp4xx_npe.c   |  9 -
 arch/arm/mach-ixp4xx/ixp4xx_qmgr.c  | 12 +---
 drivers/char/hw_random/Kconfig  |  6 +++---
 drivers/char/hw_random/ixp4xx-rng.c |  5 -
 drivers/crypto/Kconfig  |  2 +-
 drivers/crypto/ixp4xx_crypto.c  | 12 ++--
 drivers/net/wan/ixp4xx_hss.c|  2 +-
 13 files changed, 59 insertions(+), 68 deletions(-)

-- 
Krzysztof Halasa
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [dm-crypt] PROBLEM: read starvation during writeback

[Michael Zugelder]

Hi,

I have a small update on my previously posted test case. I noticed
'cryptsetup -c null' uses cipher_null in ecb mode, and in that case, I
don't observe any read starvation. I'm not sure what the default cipher
mode is (cryptsetup uses cbc-essiv:sha256), but I can reproduce the
problem using just 'cipher_null-cbc-plain'.

The revised test case is as follows:

Preparation:
  # dmsetup create dev_zero --table "0 $((1024*1024*1024)) zero"
  # dmsetup create cipher_null-cbc-plain --table "0 $((1024*1024*1024)) crypt 
cipher_null-cbc-plain - 0 /dev/mapper/dev_zero 0"
  # dmsetup create cipher_null-ecb --table "0 $((1024*1024*1024)) crypt 
cipher_null-ecb - 0 /dev/mapper/dev_zero 0"

Testing cipher_null-cbc-plain:
  # dd if=/dev/zero bs=1M of=/dev/mapper/cipher_null-cbc-plain
  # ioping -R /dev/mapper/cipher_null-cbc-plain
1 requests completed in 9530.3 ms, 0 iops, 0.0 mb/s

Note that for some reason, dd writes extremely slow (below 100.0 MB/s on
my machine) in this test.

On the other hand, cipher_null-ecb works fine.
  # dd if=/dev/zero bs=1M of=/dev/mapper/cipher_null-ecb
  # ioping -R /dev/mapper/cipher_null-ecb
32337 requests completed in 3000.0 ms, 54042 iops, 211.1 mb/s
min/avg/max/mdev = 0.0/0.0/18.8/0.2 ms

dd writes at around 850 MB/s in that case (1.8 GB/s directly to the null
target).

I tried similar benchmarks using aes instead of cipher_null, but found
no bothersome spikes with aes-ecb, aes-cbc-plain, aes-cbc-essiv:sha256.
But aes-xts-plain sometimes drops down to 5 iops (over the course of 3
seconds).

So there is probably something very wrong with cipher_null-cbc-plain
being an order of magnitude slower than aes-cbc-plain, but the cbc mode
itself doesn't seem to cause the problem.

I also ran the benchmarks on an old Athlon 64 X2 3800+ box running
kernel 3.2 and could reproduce it with very first try for every cipher
spec I tried (cipher_null-cbc-plain, cipher_null-ecb, aes-cbc-plain,
aes-ecb, aes-xts-plain). Best I could achieve was 5 iops. But
interestingly, I didn't observe the really huge spikes (upwards of 20
seconds), as I do on my 1nd gen Core i5 Notebook.

On Sat, 2012-10-13 at 01:06 +0200, Michael Zugelder wrote:
> On Fri, 2012-10-12 at 22:34 +0200, Milan Broz wrote:
> > Btw there was a proposed rewrite of internal dmcrypt queues, if you have 
> > time,
> > you can try if it changes anything for your use case.
> > Patches in dm-devel archive
> > http://www.redhat.com/archives/dm-devel/2012-August/msg00210.html
> 
> Seems interesting, I'll try it out tomorrow.

I tried the patch set earlier today, but had the same issues when
reading while writing to a 'crypt_null' mapping.

Anything else I could do to diagnose this problem?


Michael

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 11/16] f2fs: add inode operations for special inodes

[Arnd Bergmann]

On Friday 05 October 2012, 김재극 wrote:
> +const char *media_ext_lists[] = {
> +   "jpg",
> +   "gif",
> +   "png",
> +   "avi",
> +   "divx",
> +   "mp4",
> +   "mp3",
> ...

> + * Set multimedia files as cold files for hot/cold data separation
> + */
> +static inline void set_cold_file(struct inode *inode, const unsigned char 
> *name)
> +{
> +   const char **extlist = media_ext_lists;
> +
> +   while (*extlist) {
> +   if (!is_multimedia_file(name, *extlist)) {
> +   F2FS_I(inode)->is_cold = 1;
> +   break;
> +   }
> +   extlist++;
> +   }
> +}

This is a very clever way of categorizing files by their name, but I wonder if 
hardcoding
the list of file name extensions at in the kernel source is the best strategy. 
Generally
I would consider this to be a policy that should be configurable by the user.

Unfortunately I can't think of a good interface to configure this, but maybe 
someone
else has a useful idea. Maybe the list can be stored in the superblock and get 
written
at mkfs time from the same defaults, but with the option of overriding it using
a debugfs tool.

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

[RFC] desired behaviour of syscall tracing wrt fork()

[Al Viro]

There's a lovely incosistency regarding whether we call
trace_sys_exit() for child process on return from fork()/clone()/etc.
The current situation:
* called on amd64 for 32bit newborns
* *NOT* called on i386 or amd64 for 64bit ones
* not called on arm
* called on ppc, s390, sh and sparc64
* not wired on anything else
Note that existing in-kernel users of that tracepoint (ftrace and perf)
both at least attempt to bail out in that situation.  However, the
way it's done is not guaranteed to work if we wire more architectures -
it relies on syscall_get_nr() returning negative in child, which might
or might not work everywhere.  If nothing else, it's a landmine to
avoid...

FWIW, I'd vote for not calling syscall_trace_...() on the way
from ret_from_fork() - nothing in there really wants to be called
for newborns; e.g. TIF_SYSCALL_TRACE is explicitly turned off for
newborns, audit_syscall_exit() will not see ->in_syscall set and will
log nothing and existing users of trace_sys_exit() at least attempt
to skip doing anything on those.

Comments?  AFAICS, it's not that much surgery to do...
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: Local DoS through write heavy I/O on CFQ & Deadline

[Alex Bligh]

--On 13 October 2012 21:53:09 +0800 Hillf Danton  wrote:


Take a look at the "wait for writeback" problem please.

Linux 3.0+ Disk performance problem - wrong pdflush behaviour
https://lkml.org/lkml/2012/10/10/412


I'm guessing that's related but may not be the whole story. My
test case is rather simpler, and Viktor says that with the
patch causing his regression reverted, "After I've set the dirty_bytes
over the file size the writes are never blocked.". That suggests
to me that in order to avoid write blocking he needs dirty_bytes
larger than the file size. As the bytes written in my test case
exceed RAM, that's going to be be an issue as dirty_bytes is always
going to be hit; I think it Viktor's case he is trying to avoid
it being hit at all.

Or perhaps I have the wrong end of the stick.

--
Alex Bligh
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: Intel graphics drm issue?

[Mark Hounschell]

On 10/13/2012 02:57 PM, Mark Hounschell wrote:

Hi Bruno,

Thanks for the response.

On 10/12/2012 05:14 PM, Bruno Prémont wrote:

Hi Mark,

[CCing intel-gfx]

On Fri, 12 October 2012 Mark Hounschell  wrote:

Not sure this is the correct place to ask about a possible drm issue. I
have an intel based PC with an HDMI port that I'm trying to connect to
an LG TV. I have successfully used this HDMI port connected to an Optima
projector. Using that projector, everything from the BIOS post, BIOS
configuration, and all the way up to a graphical login worked just fine.
The same HDMI port and cable connected to this TV gives me the below
messages during boot. I also get no BIOS post or BIOS configuration
output while in the BIOS. I have a monitor connected to the DVI port so
I can see what I should see on the TV there, just as when I was
connected to the Optima projector. That alone makes me pretty sure it's
not a kernel issue but here are the messages anyway. Maybe they will
give someone a hint as to what the problem may be, in the case they
might be willing to give me any pointers.

TV - LG 42lb9df
PC - intel DH77DF motherboard



[0.00] Linux version 3.4.10-lcrs (root@geexbox) (gcc version
4.7.1 20120723 [gcc-4_7-branch revision 189773] (SUSE Linux) ) #1 SMP
PREEMPT Wed Oct 10 16:16:16 EDT 2012
...
[1.897955] [drm] MTRR allocation failed.  Graphics performance may
suffer.
[1.898045] i915 :00:02.0: irq 43 for MSI/MSI-X
[1.898050] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
[1.898051] [drm] Driver supports precise vblank timestamp query.
[1.898084] [drm:intel_dsm_platform_mux_info] *ERROR* MUX INFO call
failed
[1.898737] vgaarb: device changed decodes:
PCI::00:02.0,olddecodes=io+mem,decodes=io+mem:owns=io+mem
[1.995523] [drm] Enabling RC6 states: RC6 on, RC6p on, RC6pp off
[2.299535] [drm:drm_edid_block_valid] *ERROR* EDID checksum is
invalid, remainder is 128
[2.299865] Raw EDID:
[2.299957]  ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[2.300188]  ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[2.300418]  ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[2.300648]  ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[2.300879]  ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[2.301109]  ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[2.301339]  ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[2.301569]  ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff


This looks like your LG TV either does not provide EDID information via HDMI
connector, or otherwise behaves in a special way which makes reading EDID
fail.

Did you try the TV on some other computer to check if EDID can be read there
(e.g. with nvidia/amd GPU and matching open/closed driver)?

Also make sure the TV is on (neither off nor on stand-by) as some TVs
disable too much of connector interface in those states.



I have another AMD based PC here with an nvidia card and HDMI port. Using
the nvidia driver, it boots up with no output to the tv until X starts.
Once X starts I get my kdm login screen. All is well except the resolution
is 800x600 and I have no VTs. I suspect if I had a properly configured
xorg.conf file, my resolution would be what I defined in it and work.

Using the nouveau driver, I get nothing but "no signal" on the tv.  Just
like the the intel box, except no EDID messages in the log file. I've
attached a dmesg outputs for each config.

Back on the Intel machine. I boot up with a normal monitor connected to the
DVI port of the PC. Then at the kdm login screen, I disconnect the DVI
cable from the PC and connect the TV to the PCs DVI port using a DVI/HDMI
adapter. I get a beautiful 1600x1200 resolution screen on the TV. This does
not happen using the PC HDMI port.



One other thing I failed to mention. If i connect the TV HDMI to the Intel 
boards DVI port using the adapter, at power up I get all the BIOS messages 
and can enter the BIOS and all is fine. But when I let it boot all the way 
up like this, I get nothing but "no signal" after leaving BIOS mode. 
Turning the tv on/off, cable plug/unplug does not help.


Mark


I have no control over the tv with regards to stand-by mode. Off is standby
mode, on is on.


[2.434378] i915 :00:02.0: HDMI-A-3: EDID block 0 invalid.
[2.477539] checking generic (e000 3ff) vs hw (e000
1000)
[2.477541] fb: conflicting fb hw usage inteldrmfb vs VESA VGA -
removing generic driver
[2.477549] Console: switching to colour dummy device 80x25
[2.477831] fbcon: inteldrmfb (fb0) is primary device
[2.637915] Console: switching to colour frame buffer device 128x48
[2.679625] fb0: inteldrmfb frame buffer device
[2.679626] drm: registered panic notifier
[2.691536] acpi device:4b: registered as cooling_device9
[2.691660] input: Video Bus as

Re: [PATCH 00/33] AutoNUMA27

[Srikar Dronamraju]

* Andrea Arcangeli  [2012-10-04 01:50:42]:

> Hello everyone,
> 
> This is a new AutoNUMA27 release for Linux v3.6.
> 


Here results of autonumabenchmark on a 328GB 64 core with ht disabled
comparing v3.6 with autonuma27.

$ numactl -H 
available: 8 nodes (0-7)
node 0 cpus: 0 1 2 3 4 5 6 7
node 0 size: 32510 MB
node 0 free: 31689 MB
node 1 cpus: 8 9 10 11 12 13 14 15
node 1 size: 32512 MB
node 1 free: 31930 MB
node 2 cpus: 16 17 18 19 20 21 22 23
node 2 size: 32512 MB
node 2 free: 31917 MB
node 3 cpus: 24 25 26 27 28 29 30 31
node 3 size: 32512 MB
node 3 free: 31928 MB
node 4 cpus: 32 33 34 35 36 37 38 39
node 4 size: 32512 MB
node 4 free: 31926 MB
node 5 cpus: 40 41 42 43 44 45 46 47
node 5 size: 32512 MB
node 5 free: 31913 MB
node 6 cpus: 48 49 50 51 52 53 54 55
node 6 size: 65280 MB
node 6 free: 63952 MB
node 7 cpus: 56 57 58 59 60 61 62 63
node 7 size: 65280 MB
node 7 free: 64230 MB
node distances:
node   0   1   2   3   4   5   6   7 
  0:  10  20  20  20  20  20  20  20 
  1:  20  10  20  20  20  20  20  20 
  2:  20  20  10  20  20  20  20  20 
  3:  20  20  20  10  20  20  20  20 
  4:  20  20  20  20  10  20  20  20 
  5:  20  20  20  20  20  10  20  20 
  6:  20  20  20  20  20  20  10  20 
  7:  20  20  20  20  20  20  20  10 



  KernelVersion: 3.6.0-mainline_v36
Testcase: Min  Max  Avg
  numa01: 1509.14  2098.75  1793.90
numa01_HARD_BIND:  865.43  1826.40  1334.85
 numa01_INVERSE_BIND: 3242.76  3496.71  3345.12
 numa01_THREAD_ALLOC:  944.28  1418.78  1214.32
   numa01_THREAD_ALLOC_HARD_BIND:  696.33  1004.99   825.63
numa01_THREAD_ALLOC_INVERSE_BIND: 2072.88  2301.27  2186.33
  numa02:  129.87   146.10   136.88
numa02_HARD_BIND:   25.8126.1825.97
 numa02_INVERSE_BIND:  341.96   354.73   345.59
  numa02_SMT:  160.77   246.66   186.85
numa02_SMT_HARD_BIND:   25.7738.8633.57
 numa02_SMT_INVERSE_BIND:  282.61   326.76   296.44

  KernelVersion:   3.6.0-autonuma27+

Testcase: Min  Max  Avg  %Change   
  numa01: 1805.19  1907.11  1866.39-3.88%  
numa01_HARD_BIND:  953.33  2050.23  1603.29   -16.74%  
 numa01_INVERSE_BIND: 3515.14  3882.10  3715.28-9.96%  
 numa01_THREAD_ALLOC:  323.50   362.17   348.81   248.13%  
   numa01_THREAD_ALLOC_HARD_BIND:  841.08  1205.80   977.43   -15.53%  
numa01_THREAD_ALLOC_INVERSE_BIND: 2268.35  2654.89  2439.51   -10.38%  
  numa02:   51.6473.3558.88   132.47%  
numa02_HARD_BIND:   25.2326.3125.93 0.15%  
 numa02_INVERSE_BIND:  338.39   355.70   344.82 0.22%  
  numa02_SMT:   51.7666.7858.63   218.69%  
numa02_SMT_HARD_BIND:   34.9545.3939.24   -14.45%  
 numa02_SMT_INVERSE_BIND:  287.85   300.82   295.80 0.22%  

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 01/16] f2fs: add document

[Arnd Bergmann]

On Friday 05 October 2012 20:56:06 김재극 wrote:
> This adds a document describing the mount options, proc entries, usage, and
> design of Flash-Friendly File System, namely F2FS.

Nice document!

This is a lot like the design I came up with for an experimental file system
last year, so I'll try to go through and talk about the differences to
what I had. I believe there are a few points where you are missing
optimizations that I had and that could be added.

> +
> +PROC ENTRIES
> +
> +
> +/proc/fs/f2fs/ contains information about partitions mounted as f2fs. For 
> each
> +partition, a corresponding directory, named as its device name, is provided 
> with
> +the following proc entries.
> +
> +- f2fs_stat  major file system information managed by f2fs currently
> +- f2fs_sit_stat  average SIT information about whole segments
> +- f2fs_mem_stat  current memory footprint consumed by f2fs
> +
> +e.g., in /proc/fs/f2fs/sdb1/

Unrelated to the file system design, these should not be part of procfs at
all. You can probably convert them to debugfs files easily though and perhaps
even simplify the implementation in the process (I haven't looked at how it's
done at the moment).

> +
> +DESIGN
> +
> +
> +On-disk Layout
> +--
> +
> +F2FS divides whole volume into a number of segments each of which size is 
> 2MB by
> +default. A section is composed of consecutive segments, and a zone consists 
> of a
> +set of sections.

A segment size of 2MB should work fine for most eMMC, but there are a lot of
devices using TLC (three bit per cell MLC) flash with 1.5/3/6/12 MB erase 
blocks,
in particular cheap SD cards. Your design fundamentally won't work on those if 
you
only allow power-of-two multiples of 2 MB.

Would it be possible to change the segment size to 1.5 MB as a mkfs option?
I realize that the space utilization would be slightly worse in that case,
but if we allow power-of-two multiples of either 1.5 or 2 MB, that should cover
almost all media on the market today, and most likely for the forseeable
future.

> +F2FS maintains logically six log areas. Except SB, all the log areas are 
> managed
> +in a unit of multiple segments. SB is located at the beggining of the 
> partition,
> +and there exist two superblocks to avoid file system crash. Other file system
> +metadata such as CP, NAT, SIT, and SSA are located in front part of the 
> volume.
> +Main area contains file and directory data including their indices.

This is almost identical to what I had come up with.

The main difference is the number of log areas. Given that you need seven erase
blocks (six log areas, plus a random access area), quite a number of devices
are excluded from working ideally. Making use of six log areas is definitely
a win if you manage to split the data well between hot/warm/cold blocks, but
on devices that can only handle 5, this is also clearly a loss.

I understand that all Samsung eMMC handles this well, and so would the Samsung
Class 10 'Plus' SDHC cards. The Samsung Class 4 'Essential' cards can only do
2 blocks of 6 MB plus the FAT area that you need for random access, so that
won't work well with your current design.

Excluding some of your main competitor's eMMC seems more problematic. My view
is that if we include the file system, it should fundamentally work across
all devices in the industry. It's definitely ok to use 6 log areas by default
to optimize for sane devices like yours, but please consider offering at
least using just 4 log areas as an mkfs option in order to include all other
eMMC and the main SD card brands (many Sandisk, Lexar, and a bunch of the 
noname ones). I don't think it's worth including the Toshiba/Phison/Kingston
SD card controllers though, as they are basically broken for use with a
proper file system anyway and attempting to support a single log area (plus
random area in the front) would require tradeoffs that sacrifice performance
on proper devices.

> +Each area manages the following contents.
> +- CP File system information, bitmaps for valid NAT/SIT sets, orphan
> + inode lists, and summary entries of current active segments.
> +- NATBlock address table for all the node blocks stored in 
> Main area.
> +- SITSegment information such as valid block count and 
> bitmap for the
> + validity of all the blocks.
> +- SSASummary entries which contains the owner information of 
> all the
> + data and node blocks stored in Main area.
> +- Main   Node and data blocks.
> +
> +In order to avoid misalignment between file system and flash-based storage, 
> F2FS
> +aligns the 

Re: [PATCH 1/1] tools: hv: Return the full kernel version

[Greg KH]

On Sat, Oct 13, 2012 at 04:03:31PM +, KY Srinivasan wrote:
> 
> 
> > -Original Message-
> > From: Greg KH [mailto:gre...@linuxfoundation.org]
> > Sent: Saturday, October 13, 2012 2:45 AM
> > To: KY Srinivasan
> > Cc: linux-kernel@vger.kernel.org; de...@linuxdriverproject.org; 
> > o...@aepfle.de;
> > a...@canonical.com; jasow...@redhat.com
> > Subject: Re: [PATCH 1/1] tools: hv: Return the full kernel version
> > 
> > On Fri, Oct 12, 2012 at 04:40:10PM -0700, K. Y. Srinivasan wrote:
> > > Currently, we are returning the same string for both OSBuildNumber
> > > and OSVersion keys. Return the full uts string for the OSBuild
> > > key since Windows does not impose any restrictions on this.
> > 
> > You sent me 2 patches, both 1/1, that modify the same file.  Which one
> > comes first?  Please resend both properly, and also let me know if these
> > are things that should be going into 3.7 or can wait for 3.8.
> 
> Initially,  I sent them out in the order I wanted them
> applied. I will resend them as a patch set. They can wait for 3.8.

The "order" you send them isn't always the order they are received by
people, that is why you need to have the X/2 numbering scheme.

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] binfmt_script: do not leave interp on stack

[Kees Cook]

On Fri, Oct 12, 2012 at 10:50 PM, halfdog  wrote:
> Kees Cook wrote:
>> More importantly, I also wonder if interp handling to just be
>> changed to be an allocation that needs to be cleaned up, as done with
>> argv?
>
> You mean like an allocation on the stack of the new process' growing
> stack? This would be cleaned automatically if something goes wrong
> during exec.

Either in userspace like argv, or just a straight kmalloc.

Looking at the code, the problem is that binfmt_script and binfmt_misc
are "rewrite" hacks (they change the bprm instead of actually starting
a process), and the module loading is a hack in that it retries all
the loaders a second time. These two hacks together aren't very
compatible if the error path of the rewrite hacks expects to see the
bprm go away instead of getting retried.

I'm concerned that the proposed patch is really just a band-aid on top
of a broken design.

To make this safe, either the bprm needs to be explicitly copied for
each recursion attempt (so the post-module-load retry starts with a
clean bprm), or everything about the bprm needs to stay off the stack
(to allow rewrite modifications to be stable).

I think the latter approach is best since it means we don't have to
execute the rewrite logic twice. It just means we must take a closer
look at the lifetime of that structure and make sure we're cleaning it
up correctly.

-Kees

-- 
Kees Cook
Chrome OS Security
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [git pull] vfs pile 3

[Al Viro]

On Sat, Oct 13, 2012 at 12:04:55PM -0400, Christoph Hellwig wrote:
> On Sat, Oct 13, 2012 at 05:01:15PM +0100, Al Viro wrote:
> > You know, I'm in the middle of dealing with one such TODO.  Yours, as it
> > were.  From six years ago.  kernel_thread() unexporting.  TODO comments
> > of any form are routinely shat upon and ignored, especially when shuffled
> > away into less read parts of the tree... ;-/
> > 
> > I'd rather see it done fs-by-fs.  Starting with something reasonably easy
> > to test - minixfs would do nicely.  Don't get me wrong - I'm all for
> > burying ->truncate(); what I'm worried about is that we'll end up burying
> > the warning about the reasons why vmtruncate() was a bad idea, leaving the
> > functionality exactly as it used to be...
> 
> As mentioned I agree with the concern in principle.  Let's start by
> taking Marco's patches for filesystems that use vmtruncate but don't 
> actually implement ->truncate.  There's a few I remember offhand, e.g.
> procfs and ufs right now.  Then we can do the actual work required ones
> piece by piece.

Umm... That would be what, procfs?  Frankly, I'm not sure that ATTR_SIZE for
procfs actually should not be silently ignored.  ->i_size there is completely
synthetic - it's not as if truncation would actually change the contents.

And ufs situation is quite different - there vmtruncate() is used only on the
->write_begin() side.  ->setattr() is already vmtruncate-free.  What's needed
there is an analog of e.g. ext2_write_failed().
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/2] uapi: update includes for drm content when no kernel API exists

[Luis R. Rodriguez]

On Sat, Oct 13, 2012 at 3:33 AM, Laurent Pinchart
 wrote:
> Hi Luis,
>
> On Friday 12 October 2012 16:49:31 Luis R. Rodriguez wrote:
>> From: "Luis R. Rodriguez" 
>>
>> The UAPI changes split kernel API and userspace API
>> content onto two separate header files. The userspace
>> API drm content was moved to include/uapi/drm/ with the
>> same file name while kernel specific API content was
>> kept under include/drm/ with the same file name. When
>> one file was split into two files the kernel header
>> includes the uapi header and a UAPI prefix was added to
>> the uapi header for its header guard. When there was no
>> kernel API content found the uapi header file was the
>> only one that was kept and the original guard for the
>> header file was kept. In this particular case the
>> original users of this header file were not modified
>> and the uapi header file is expected to be picked up
>> by path.
>>
>> This may work well at compilation on the kernel but when
>> backporting this creates a few complexities.
>
> Could you please provide more details about those complexities ?

Sure, the backported DRM code is as-is code from linux-next. The
header search path includes a copy of a few select header files from
linux-next, the rest are part of the compat [0] project to help with
backporting and the last set are from your own kernel. In this
particular case the UAPI effort pushed into include/uapi/drm a few
files which are now no longer present in the old include/drm/ location
when there was no respective kernel-only APIs exposed. For DRM code
that did not use the new uapi/drm/ path for old header includes this
means that upon backporting the older kernel's header file would be
used obviously leading to a series of compilation failures. By being
explicit about the path, as was done with a few other header files, we
can suck out DRM code intact from the kernel to be compilable for
older kernels. As of the v3.7-rc1 the compat-drivers project [1] will
be providing DRM modules. The new UAPI changes broke compilation on
compat-drivers when compiling DRM code so to fix this we either patch
code taken from the Linux kernel as I have done, force inclusion of a
few specific headers files, or use include_next tricks. It turns out
that forcing inclusion of -I$(M)/include/uapi as a path search prior
to your own kernel's at compilation time did not help. The
include_next trick can work as well but that'd mean synching the UAPI
files regularly into compat. I'd much prefer to have code intact when
possible when backporting so the option I stuck with then was to patch
the code directly and then as part of compat-drivers to always copy
that day's linux-next UAPI headers into the current directory for
compilation. I see no other driver code using the uapi path explicitly
though, is that by design? Would it be wrong to be explicit about
using a UAPI header alone if no kernel API files exist?

[0] https://backports.wiki.kernel.org/index.php/Documentation/compat
[1] https://backports.wiki.kernel.org/

  Luis
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 2/2] SLUB: increase the range of slab sizes available to kmalloc, allowing a somewhat more effient use of memory.

[Richard Kennedy]

This patch add new slabs sized at 1.5 * 2^n.
i.e - 24,48,96,192,384,768,1.5k,3k,6k
Most of which already exist as kmem_cache slabs, except for 1.5k, 3k & 6k.

There is no extra overhead for statically sized kmalloc, and only a small 
change for dynamically sized ones.

Minimal code changes:
new list of slab sizes
new kmalloc functions
re-factored slub initialisation

other than that the core slub code remains unchanged.

No measurable significant performance difference, nothing above the noise 
anyway.

Only tested on x86_64, so may not work on other architectures.
The code should support the use of KMALLOC_MIN_SIZE, but I have no hardware to 
test this on.

compiled with gcc 4.7.2
patch against 3.6

Signed-off-by: Richard Kennedy 
---
 include/linux/slub_def.h |  95 +--
 mm/slub.c| 162 ++-
 2 files changed, 108 insertions(+), 149 deletions(-)

diff --git a/include/linux/slub_def.h b/include/linux/slub_def.h
index df448ad..3c36009 100644
--- a/include/linux/slub_def.h
+++ b/include/linux/slub_def.h
@@ -143,62 +143,63 @@ struct kmem_cache {
 #endif
 
 /*
- * We keep the general caches in an array of slab caches that are used for
- * 2^x bytes of allocations.
+ * the table of slab sizes, should handle all of the arch cases
+ * -- but only tested on x86_64 -- caveat emptor
  */
-extern struct kmem_cache *kmalloc_caches[SLUB_PAGE_SHIFT];
 
-/*
- * Sorry that the following has to be that ugly but some versions of GCC
- * have trouble with constant propagation and loops.
+static const short __slab_sizes[] = {0, 8, 12, 16, 24, 32, 48, 64, 96,
+128, 192, 256, 384, 512, 768, 1024,
+1536, 2048, 3072, 4096, 6144, 8192};
+
+/* very ugly, but gcc will optimize these away.
+ * the comment on the original finction says :-
+ * >  Sorry that the following has to be that ugly but some versions of GCC
+ * >  have trouble with constant propagation and loops.
+ * so a simple loop just won't work.
+ *
+ * Don't allow anything smaller than, or not aligned to KMALLOC_MIN_SIZE
  */
-static __always_inline int kmalloc_index(size_t size)
+static __always_inline short __test_slab_size(size_t size, short index)
 {
-   if (!size)
+   if (__slab_sizes[index] % KMALLOC_MIN_SIZE ||
+__slab_sizes[index] < size)
return 0;
+   return 1;
+}
+
+static __always_inline short kmalloc_index(size_t size)
+{
+   if (!size) return 0;
+   if (__test_slab_size(size, 1)) return 1;
+   if (__test_slab_size(size, 2)) return 2;
+   if (__test_slab_size(size, 3)) return 3;
+   if (__test_slab_size(size, 4)) return 4;
+   if (__test_slab_size(size, 5)) return 5;
+   if (__test_slab_size(size, 6)) return 6;
+   if (__test_slab_size(size, 7)) return 7;
+   if (__test_slab_size(size, 8)) return 8;
+   if (__test_slab_size(size, 9)) return 9;
+   if (__test_slab_size(size, 10)) return 10;
+   if (__test_slab_size(size, 11)) return 11;
+   if (__test_slab_size(size, 12)) return 12;
+   if (__test_slab_size(size, 13)) return 13;
+   if (__test_slab_size(size, 14)) return 14;
+   if (__test_slab_size(size, 15)) return 15;
+   if (__test_slab_size(size, 16)) return 16;
+   if (__test_slab_size(size, 17)) return 17;
+   if (__test_slab_size(size, 18)) return 18;
+   if (__test_slab_size(size, 19)) return 19;
+   if (__test_slab_size(size, 20)) return 20;
+   if (__test_slab_size(size, 21)) return 21;
 
-   if (size <= KMALLOC_MIN_SIZE)
-   return KMALLOC_SHIFT_LOW;
-
-   if (KMALLOC_MIN_SIZE <= 32 && size > 64 && size <= 96)
-   return 1;
-   if (KMALLOC_MIN_SIZE <= 64 && size > 128 && size <= 192)
-   return 2;
-   if (size <=  8) return 3;
-   if (size <= 16) return 4;
-   if (size <= 32) return 5;
-   if (size <= 64) return 6;
-   if (size <=128) return 7;
-   if (size <=256) return 8;
-   if (size <=512) return 9;
-   if (size <=   1024) return 10;
-   if (size <=   2 * 1024) return 11;
-   if (size <=   4 * 1024) return 12;
-/*
- * The following is only needed to support architectures with a larger page
- * size than 4k. We need to support 2 * PAGE_SIZE here. So for a 64k page
- * size we would have to go up to 128k.
- */
-   if (size <=   8 * 1024) return 13;
-   if (size <=  16 * 1024) return 14;
-   if (size <=  32 * 1024) return 15;
-   if (size <=  64 * 1024) return 16;
-   if (size <= 128 * 1024) return 17;
-   if (size <= 256 * 1024) return 18;
-   if (size <= 512 * 1024) return 19;
-   if (size <= 1024 * 1024) return 20;
-   if (size <=  2 * 1024 * 1024) return 21;
BUG();
-   return -1; /* Will never be reached */
+   return -1;
+}
 
 /*
- * What we 

[PATCH 1/2] SLUB: remove hard coded magic numbers from resiliency_test

[Richard Kennedy]

Use the always inlined function kmalloc_index to translate
sizes to indexes, so that we don't have to have the slab indexes
hard coded in two places.



Signed-off-by: Richard Kennedy 
---
 mm/slub.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/mm/slub.c b/mm/slub.c
index 2fdd96f..804ac42 100644
--- a/mm/slub.c
+++ b/mm/slub.c
@@ -4418,7 +4418,7 @@ static void resiliency_test(void)
printk(KERN_ERR "\n1. kmalloc-16: Clobber Redzone/next pointer"
" 0x12->0x%p\n\n", p + 16);
 
-   validate_slab_cache(kmalloc_caches[4]);
+   validate_slab_cache(kmalloc_caches[kmalloc_index(16)]);
 
/* Hmmm... The next two are dangerous */
p = kzalloc(32, GFP_KERNEL);
@@ -4428,7 +4428,7 @@ static void resiliency_test(void)
printk(KERN_ERR
"If allocated object is overwritten then not detectable\n\n");
 
-   validate_slab_cache(kmalloc_caches[5]);
+   validate_slab_cache(kmalloc_caches[kmalloc_index(32)]);
p = kzalloc(64, GFP_KERNEL);
p += 64 + (get_cycles() & 0xff) * sizeof(void *);
*p = 0x56;
@@ -4436,27 +4436,27 @@ static void resiliency_test(void)
p);
printk(KERN_ERR
"If allocated object is overwritten then not detectable\n\n");
-   validate_slab_cache(kmalloc_caches[6]);
+   validate_slab_cache(kmalloc_caches[kmalloc_index(64)]);
 
printk(KERN_ERR "\nB. Corruption after free\n");
p = kzalloc(128, GFP_KERNEL);
kfree(p);
*p = 0x78;
printk(KERN_ERR "1. kmalloc-128: Clobber first word 0x78->0x%p\n\n", p);
-   validate_slab_cache(kmalloc_caches[7]);
+   validate_slab_cache(kmalloc_caches[kmalloc_index(128)]);
 
p = kzalloc(256, GFP_KERNEL);
kfree(p);
p[50] = 0x9a;
printk(KERN_ERR "\n2. kmalloc-256: Clobber 50th byte 0x9a->0x%p\n\n",
p);
-   validate_slab_cache(kmalloc_caches[8]);
+   validate_slab_cache(kmalloc_caches[kmalloc_index(256)]);
 
p = kzalloc(512, GFP_KERNEL);
kfree(p);
p[512] = 0xab;
printk(KERN_ERR "\n3. kmalloc-512: Clobber redzone 0xab->0x%p\n\n", p);
-   validate_slab_cache(kmalloc_caches[9]);
+   validate_slab_cache(kmalloc_caches[kmalloc_index(512)]);
 }
 #else
 #ifdef CONFIG_SYSFS
-- 
1.7.11.7

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 0/2] RFC SLUB: increase range of kmalloc slab sizes

[Richard Kennedy]

This patch increases the range of slab sizes available to kmalloc, adding
slabs half way between the existing power of two sized ones, so allowing 
slightly
 more efficient use of memory.
Most of the new slabs already exist as kmem_cache slabs so only the 1.5k,3k & 
6k 
are entirely new.
The code in get_slab_index() is simple, optimizes well and only adds a few
instructions to the code path of dynamically sized kmallocs.
It also simplifies the slab initialisation code as it removes the special case 
of the 2 
odd sized slabs of 96 & 192 and the need for the slab_index array.

I have been running this on an x86_64 desktop machine for a few weeks without 
any problems,
and have not measured any significant performance difference, nothing about the 
noise anyway.

The new slabs (1.5k,3k,6k) get used by several hundred objects on desktop 
workloads so this 
patch has a small but useful impact on memory usage.
As the other new slabs are aliased to existing slabs it's difficult to measure 
any differences.

The code should correctly support KMALLOC_MIN_SIZE and therefore work on 
architectures other
than x86_64, but I don't have any hardware to test it on. So if anyone feels 
like testing this patch
I will be interested in the results.

The patches are agains v3.6
I have only tested this on x86_64 with gcc 4.7.2

The first patch is just to tidy up hardcoded constants in resiliency_test() 
replacing them
with calls to kmalloc_index so that it will still work after the kmalloc_cache 
array get reordered.

The second patch adds the new slabs, updates the kmalloc code and 
kmem_cache_init(). 

This version is a drop in replacement for the existing code, but I could make 
it a config option if 
you prefer.

regards
Richard

Richard Kennedy (2):
  SLUB: remove hard coded magic numbers from resiliency_test
  SLUB: increase the range of slab sizes available to kmalloc, allowing
a somewhat more effient use of memory.

 include/linux/slub_def.h |  95 +-
 mm/slub.c| 174 ++-
 2 files changed, 114 insertions(+), 155 deletions(-)

-- 
1.7.11.7

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 v4 3/4] fat (exportfs): rebuild directory-inode if fat_dget() fails

[OGAWA Hirofumi]

Namjae Jeon  writes:

> + if (!fat_get_dotdot_entry(child_dir->d_inode, _bh, )) {
> + parent_logstart = fat_get_start(sbi, de);
>   parent_inode = fat_dget(sb, parent_logstart);
> + if (parent_inode || sbi->options.nfs != FAT_NFS_NOSTALE_RO)
> + goto out;
> + if (!parent_logstart)
> + /*logstart of dotdot entry is zero if
> + * if the directory's parent is root
> + */
> + parent_inode = sb->s_root->d_inode;

 get_parent() should not be called for root dir, right?
>>> Yes.
>>
>> Ah, actual question was - subdir of root can be passed to this? I guess
>> it is possible...
> Yes, you're right.

OK, I think I got where is wrong. If it is the subdir of rootdir,
fat_dget() should get the inode of root?

So, I guess if parent_logstart == 0, it is BUG().
-- 
OGAWA Hirofumi 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 2/2] Tools: hv: Don't return loopback addresses

[K. Y. Srinivasan]

Don't return loopback addresses and further don't terminate
the IP address strings with a semicolon. This is the current
behavior of Windows guests.

Signed-off-by: K. Y. Srinivasan 
Reviewed-by: Haiyang Zhang 
Reported-by: Claudio Latini 
---
 tools/hv/hv_kvp_daemon.c |   13 +
 1 files changed, 9 insertions(+), 4 deletions(-)

diff --git a/tools/hv/hv_kvp_daemon.c b/tools/hv/hv_kvp_daemon.c
index 6c7bcb9..13c2a14 100644
--- a/tools/hv/hv_kvp_daemon.c
+++ b/tools/hv/hv_kvp_daemon.c
@@ -43,6 +43,7 @@
 #include 
 #include 
 #include 
+#include 
 
 /*
  * KVP protocol: The user mode component first registers with the
@@ -882,7 +883,7 @@ static int kvp_process_ip_address(void *addrp,
addr_length = INET6_ADDRSTRLEN;
}
 
-   if ((length - *offset) < addr_length + 1)
+   if ((length - *offset) < addr_length + 2)
return HV_E_FAIL;
if (str == NULL) {
strcpy(buffer, "inet_ntop failed\n");
@@ -890,11 +891,13 @@ static int kvp_process_ip_address(void *addrp,
}
if (*offset == 0)
strcpy(buffer, tmp);
-   else
+   else {
+   strcat(buffer, ";");
strcat(buffer, tmp);
-   strcat(buffer, ";");
+   }
 
*offset += strlen(str) + 1;
+
return 0;
 }
 
@@ -956,7 +959,9 @@ kvp_get_ip_info(int family, char *if_name, int op,
 * supported address families; if not we gather info on
 * the specified address family.
 */
-   if ((family != 0) && (curp->ifa_addr->sa_family != family)) {
+   if family != 0) &&
+(curp->ifa_addr->sa_family != family))) ||
+(curp->ifa_flags & IFF_LOOPBACK)) {
curp = curp->ifa_next;
continue;
}
-- 
1.7.4.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 1/2] tools: hv: Return the full kernel version

[K. Y. Srinivasan]

Currently, we are returning the same string for both OSBuildNumber
and OSVersion keys. Return the full uts string for the OSBuild
key since Windows does not impose any restrictions on this.

Signed-off-by: K. Y. Srinivasan 
Reviewed-by: Haiyang Zhang 
Reported-by: Claudio Latini 
---
 tools/hv/hv_kvp_daemon.c |9 ++---
 1 files changed, 6 insertions(+), 3 deletions(-)

diff --git a/tools/hv/hv_kvp_daemon.c b/tools/hv/hv_kvp_daemon.c
index 5959aff..6c7bcb9 100644
--- a/tools/hv/hv_kvp_daemon.c
+++ b/tools/hv/hv_kvp_daemon.c
@@ -88,6 +88,7 @@ static char *os_major = "";
 static char *os_minor = "";
 static char *processor_arch;
 static char *os_build;
+static char *os_version;
 static char *lic_version = "Unknown version";
 static struct utsname uts_buf;
 
@@ -453,7 +454,9 @@ void kvp_get_os_info(void)
char*p, buf[512];
 
uname(_buf);
-   os_build = uts_buf.release;
+   os_version = uts_buf.release;
+   os_build = strdup(uts_buf.release);
+
os_name = uts_buf.sysname;
processor_arch = uts_buf.machine;
 
@@ -462,7 +465,7 @@ void kvp_get_os_info(void)
 * string to be of the form: x.y.z
 * Strip additional information we may have.
 */
-   p = strchr(os_build, '-');
+   p = strchr(os_version, '-');
if (p)
*p = '\0';
 
@@ -1649,7 +1652,7 @@ int main(void)
strcpy(key_name, "OSMinorVersion");
break;
case OSVersion:
-   strcpy(key_value, os_build);
+   strcpy(key_value, os_version);
strcpy(key_name, "OSVersion");
break;
case ProcessorArchitecture:
-- 
1.7.4.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 0/2] Tools: hv: kvp_daemon

[K. Y. Srinivasan]

This patch-set makes KVP implementation track the implementation
on Windows guests with regards to how IP addresses are returned.
Additionally, we  also returns more information for the
OSBuild key. 


K. Y. Srinivasan (2):
  tools: hv: Return the full kernel version
  Tools: hv: Don't return loopback addresses

 tools/hv/hv_kvp_daemon.c |   22 +++---
 1 files changed, 15 insertions(+), 7 deletions(-)

-- 
1.7.4.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 17/22] ncpfs: drop vmtruncate

[Christoph Hellwig]

>   if (attr->ia_size != i_size_read(inode)) {
> - result = vmtruncate(inode, attr->ia_size);
> + result = inode_newsize_ok(inode, attr->ia_size);
>   if (result)
>   goto out;
> +
> + truncate_setsize(inode, attr->ia_size);
>   mark_inode_dirty(inode);

inode_newsize_ok already is done as part of inode_change_ok earlier on.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 14/22] hostfs: drop vmtruncate

[Christoph Hellwig]

> +++ b/fs/hostfs/hostfs_kern.c
> @@ -848,9 +848,11 @@ int hostfs_setattr(struct dentry *dentry, struct iattr 
> *attr)
>   attr->ia_size != i_size_read(inode)) {
>   int error;
>  
> - error = vmtruncate(inode, attr->ia_size);
> - if (err)
> - return err;
> + error = inode_newsize_ok(inode, attr->ia_size);
> + if (error)
> + return error;
> +
> + truncate_setsize(inode, attr->ia_size);

The inode_change_ok call here is superflous, it's already done by
inode_change_ok at the beginning of the function.  Even if that wasn't
done doing it aftet set_attr() would be too late anyway.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 09/22] bfs: drop vmtruncate

[Christoph Hellwig]

> @@ -171,8 +171,9 @@ static int bfs_write_begin(struct file *file, struct 
> address_space *mapping,
>   bfs_get_block);
>   if (unlikely(ret)) {
>   loff_t isize = mapping->host->i_size;
> - if (pos + len > isize)
> - vmtruncate(mapping->host, isize);
> + if ((pos + len > isize) &&
> + inode_newsize_ok(mapping->host, isize) == 0)
> + truncate_setsize(mapping->host, isize);

No need for the inode_newsize_ok in the write failure handling.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 07/22] adfs: drop vmtruncate

[Christoph Hellwig]

> @@ -57,8 +57,9 @@ static int adfs_write_begin(struct file *file, struct 
> address_space *mapping,
>   _I(mapping->host)->mmu_private);
>   if (unlikely(ret)) {
>   loff_t isize = mapping->host->i_size;
> - if (pos + len > isize)
> - vmtruncate(mapping->host, isize);
> + if ((pos + len > isize) &&
> + inode_newsize_ok(mapping->host, isize) == 0)
> + truncate_setsize(mapping->host, isize);

No need for the inode_newsize_ok check here.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 06/22] ocfs2: drop vmtruncate

[Christoph Hellwig]

>   if ((attr->ia_valid & ATTR_SIZE) &&
>   attr->ia_size != i_size_read(inode)) {
> - status = vmtruncate(inode, attr->ia_size);
> + status = inode_newsize_ok(inode, attr->ia_size);
>   if (status) {
>   mlog_errno(status);
>   goto bail_commit;
>   }
> + truncate_setsize(inode, attr->ia_size);

ocfs2 already calls inode_newsize_ok earlier during ocfs2_setattr,
and there's an XXX comment just above the vmtruncate call about
how ocfs2 hacks around this.  I suspect you just want a plain
truncate_setsize here and remove the comment above it, but I'd
like to have the ocfs2 folks confirm that.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 04/22] procfs: drop vmtruncate

[Christoph Hellwig]

Looks good,

Reviewed-by: Christoph Hellwig 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 01/22] ufs: drop vmtruncate

[Christoph Hellwig]

> @@ -536,8 +536,9 @@ static int ufs_write_begin(struct file *file, struct 
> address_space *mapping,
>   ufs_getfrag_block);
>   if (unlikely(ret)) {
>   loff_t isize = mapping->host->i_size;
> - if (pos + len > isize)
> - vmtruncate(mapping->host, isize);
> + if ((pos + len > isize) &&
> + inode_newsize_ok(mapping->host, isize) == 0)
> + truncate_setsize(mapping->host, isize);

write_begin always truncates down, so there should be no call to
inode_newsize_ok here.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [git pull] vfs pile 3

[Christoph Hellwig]

On Sat, Oct 13, 2012 at 05:01:15PM +0100, Al Viro wrote:
> You know, I'm in the middle of dealing with one such TODO.  Yours, as it
> were.  From six years ago.  kernel_thread() unexporting.  TODO comments
> of any form are routinely shat upon and ignored, especially when shuffled
> away into less read parts of the tree... ;-/
> 
> I'd rather see it done fs-by-fs.  Starting with something reasonably easy
> to test - minixfs would do nicely.  Don't get me wrong - I'm all for
> burying ->truncate(); what I'm worried about is that we'll end up burying
> the warning about the reasons why vmtruncate() was a bad idea, leaving the
> functionality exactly as it used to be...

As mentioned I agree with the concern in principle.  Let's start by
taking Marco's patches for filesystems that use vmtruncate but don't 
actually implement ->truncate.  There's a few I remember offhand, e.g.
procfs and ufs right now.  Then we can do the actual work required ones
piece by piece.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] tools: hv: Return the full kernel version

[KY Srinivasan]

> -Original Message-
> From: Greg KH [mailto:gre...@linuxfoundation.org]
> Sent: Saturday, October 13, 2012 2:45 AM
> To: KY Srinivasan
> Cc: linux-kernel@vger.kernel.org; de...@linuxdriverproject.org; 
> o...@aepfle.de;
> a...@canonical.com; jasow...@redhat.com
> Subject: Re: [PATCH 1/1] tools: hv: Return the full kernel version
> 
> On Fri, Oct 12, 2012 at 04:40:10PM -0700, K. Y. Srinivasan wrote:
> > Currently, we are returning the same string for both OSBuildNumber
> > and OSVersion keys. Return the full uts string for the OSBuild
> > key since Windows does not impose any restrictions on this.
> 
> You sent me 2 patches, both 1/1, that modify the same file.  Which one
> comes first?  Please resend both properly, and also let me know if these
> are things that should be going into 3.7 or can wait for 3.8.

Initially,  I sent them out in the order I wanted them
applied. I will resend them as a patch set. They can wait for 3.8.

Regards,

K. Y
> 
> greg k-h
> 
> 


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [git pull] vfs pile 3

[Al Viro]

On Sat, Oct 13, 2012 at 11:48:10AM -0400, Christoph Hellwig wrote:
> On Sat, Oct 13, 2012 at 08:51:28AM +0100, Al Viro wrote:
> > It's somewhat pointless on its own...  If you were doing something with
> > the callers afterwards - sure, it would be make sense, but as it is...
> 
> I'd really like to see ->truncate and vmtruncate done, so from that side
> I'm absolutely in favour of this series.  What I'm a bit concerned about
> is that it just does the trivial 1:1 conversion and not actually
> converts the sequence of operations to the proper form, which was one
> of the two big reasons of moving away from ->truncate to start with.
> 
> I'd love to see the full conversion, but without adequate test coverage
> for all the fringe filesystems that might be a bit too much to expect
> from Marco.
> 
> I think just doing the easy conversions he did, and putting a TODO
> comment explaining how it should be taken further at each of the sites
> would be valueable on its own.

You know, I'm in the middle of dealing with one such TODO.  Yours, as it
were.  From six years ago.  kernel_thread() unexporting.  TODO comments
of any form are routinely shat upon and ignored, especially when shuffled
away into less read parts of the tree... ;-/

I'd rather see it done fs-by-fs.  Starting with something reasonably easy
to test - minixfs would do nicely.  Don't get me wrong - I'm all for
burying ->truncate(); what I'm worried about is that we'll end up burying
the warning about the reasons why vmtruncate() was a bad idea, leaving the
functionality exactly as it used to be...
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [git pull] vfs pile 3

[Christoph Hellwig]

On Sat, Oct 13, 2012 at 08:51:28AM +0100, Al Viro wrote:
> It's somewhat pointless on its own...  If you were doing something with
> the callers afterwards - sure, it would be make sense, but as it is...

I'd really like to see ->truncate and vmtruncate done, so from that side
I'm absolutely in favour of this series.  What I'm a bit concerned about
is that it just does the trivial 1:1 conversion and not actually
converts the sequence of operations to the proper form, which was one
of the two big reasons of moving away from ->truncate to start with.

I'd love to see the full conversion, but without adequate test coverage
for all the fringe filesystems that might be a bit too much to expect
from Marco.

I think just doing the easy conversions he did, and putting a TODO
comment explaining how it should be taken further at each of the sites
would be valueable on its own.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] task_work: Add local_irq_enable() into task_work_run()

[Al Viro]

On Sat, Oct 13, 2012 at 10:59:25PM +1300, Michael Cree wrote:

> Any chance that we could have the fixes backported to the stable queue, in 
> particular to the 3,2 kernel?  We should then be able to run the Debian built 
> SMP kernel on the autobuilders at Debian-Ports rather than having to run a 
> specially built kernel or a UP kernel.
> 
> BTW, the WARNING: at kernel/softirq.c:139 __local_bh_enable+0xe8/0x110() 
> still 
> occurs when bringing up the CPUs.  Actually it happens twice now.  I've 
> attached my dmesg dump should you wish to check.

The obvious fix is to add local_irq_disable() into do_entInt(), just before
calling handle_ipi().  But I'm not sure if we wouldn't be better off just
doing it right in the beginning of do_entInt().  Take a look at that switch
in there: case 0 - we want local_irq_disable() done before handle_ipi().
case 1 - we do local_irq_disable() right there on SMP and do it almost
instantly in case of UP, since handle_irq() will do it a few insns after
entry anyway.  case 3 - ->device_interrupt() calls handle_irq() very soon
on all subarchitectures.  That leaves machine checks and perf_irq.  I have
no idea how hot those paths really are; do we spend enough time in there
to make blanket local_disable_irq() on those painful?  If not, we'd probably
be better off just lifting local_disable_irq() to the beginning of
do_entInt() and killing it in handle_irq() - that sucker is always called
from do_entInt(), directly or via ->device_interrupt().

Comments?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] MM: Support more pagesizes for MAP_HUGETLB/SHM_HUGETLB v5

[Andi Kleen]

From: Andi Kleen 

There was some desire in large applications using MAP_HUGETLB/SHM_HUGETLB
to use 1GB huge pages on some mappings, and stay with 2MB on others. This
is useful together with NUMA policy: use 2MB interleaving on some mappings,
but 1GB on local mappings.

This patch extends the IPC/SHM syscall interfaces slightly to allow specifying
the page size.

It borrows some upper bits in the existing flag arguments and allows encoding
the log of the desired page size in addition to the *_HUGETLB flag.
When 0 is specified the default size is used, this makes the change fully
compatible.

Extending the internal hugetlb code to handle this is straight forward. Instead
of a single mount it just keeps an array of them and selects the right
mount based on the specified page size. When no page size is specified
it uses the mount of the default page size.

The change is not visible in /proc/mounts because internal mounts
don't appear there. It also has very little overhead: the additional
mounts just consume a super block, but not more memory when not used.

I also exported the new flags to the user headers
(they were previously under __KERNEL__). Right now only symbols
for x86 and some other architecture for 1GB and 2MB are defined.
The interface should already work for all other architectures
though.  Only architectures that define multiple hugetlb sizes
actually need it (that is currently x86, tile, powerpc). However
tile and powerpc have user configurable hugetlb sizes, so it's
not easy to add defines. A program on those architectures would
need to query sysfs and use the appropiate log2.

v2: Port to new tree. Fix unmount.
v3: Ported to latest tree.
v4: Ported to latest tree. Minor changes for review feedback. Updated
description.
v5: Remove unnecessary prototypes to fix merge error (Hillf Dalton)
Acked-by: Rik van Riel 
Acked-by: KAMEZAWA Hiroyuki 
Signed-off-by: Andi Kleen 
---
 arch/x86/include/asm/mman.h |3 ++
 fs/hugetlbfs/inode.c|   63 +++
 include/linux/hugetlb.h |7 +++-
 include/linux/shm.h |   19 
 include/uapi/asm-generic/mman.h |   13 
 ipc/shm.c   |3 +-
 mm/mmap.c   |5 ++-
 7 files changed, 95 insertions(+), 18 deletions(-)

diff --git a/arch/x86/include/asm/mman.h b/arch/x86/include/asm/mman.h
index 593e51d..513b05f 100644
--- a/arch/x86/include/asm/mman.h
+++ b/arch/x86/include/asm/mman.h
@@ -3,6 +3,9 @@
 
 #define MAP_32BIT  0x40/* only give out 32bit addresses */
 
+#define MAP_HUGE_2MB(21 << MAP_HUGE_SHIFT)
+#define MAP_HUGE_1GB(30 << MAP_HUGE_SHIFT)
+
 #include 
 
 #endif /* _ASM_X86_MMAN_H */
diff --git a/fs/hugetlbfs/inode.c b/fs/hugetlbfs/inode.c
index c5bc355..d34bb56 100644
--- a/fs/hugetlbfs/inode.c
+++ b/fs/hugetlbfs/inode.c
@@ -923,7 +923,7 @@ static struct file_system_type hugetlbfs_fs_type = {
.kill_sb= kill_litter_super,
 };
 
-static struct vfsmount *hugetlbfs_vfsmount;
+static struct vfsmount *hugetlbfs_vfsmount[HUGE_MAX_HSTATE];
 
 static int can_do_hugetlb_shm(void)
 {
@@ -932,9 +932,22 @@ static int can_do_hugetlb_shm(void)
return capable(CAP_IPC_LOCK) || in_group_p(shm_group);
 }
 
+static int get_hstate_idx(int page_size_log)
+{
+   struct hstate *h;
+
+   if (!page_size_log)
+   return default_hstate_idx;
+   h = size_to_hstate(1 << page_size_log);
+   if (!h)
+   return -1;
+   return h - hstates;
+}
+
 struct file *hugetlb_file_setup(const char *name, unsigned long addr,
size_t size, vm_flags_t acctflag,
-   struct user_struct **user, int creat_flags)
+   struct user_struct **user,
+   int creat_flags, int page_size_log)
 {
int error = -ENOMEM;
struct file *file;
@@ -944,9 +957,14 @@ struct file *hugetlb_file_setup(const char *name, unsigned 
long addr,
struct qstr quick_string;
struct hstate *hstate;
unsigned long num_pages;
+   int hstate_idx;
+
+   hstate_idx = get_hstate_idx(page_size_log);
+   if (hstate_idx < 0)
+   return ERR_PTR(-ENODEV);
 
*user = NULL;
-   if (!hugetlbfs_vfsmount)
+   if (!hugetlbfs_vfsmount[hstate_idx])
return ERR_PTR(-ENOENT);
 
if (creat_flags == HUGETLB_SHMFS_INODE && !can_do_hugetlb_shm()) {
@@ -963,7 +981,7 @@ struct file *hugetlb_file_setup(const char *name, unsigned 
long addr,
}
}
 
-   root = hugetlbfs_vfsmount->mnt_root;
+   root = hugetlbfs_vfsmount[hstate_idx]->mnt_root;
quick_string.name = name;
quick_string.len = strlen(quick_string.name);
quick_string.hash = 0;
@@ -971,7 +989,7 @@ struct file *hugetlb_file_setup(const char *name, unsigned 
long addr,
if (!path.dentry)
goto out_shm_unlock;
 
-  

Re: [PATCH] MM: Support more pagesizes for MAP_HUGETLB/SHM_HUGETLB v4

[Andi Kleen]

> > -   struct user_struct **user, int creat_flags);
> > +   struct user_struct **user, int creat_flags,
> > +   int page_size_log);
> > +int hugetlb_get_quota(struct address_space *mapping, long delta);
> > +void hugetlb_put_quota(struct address_space *mapping, long delta);
> > +
> > +int hugetlb_get_quota(struct address_space *mapping, long delta);
> > +void hugetlb_put_quota(struct address_space *mapping, long delta);
> 
> 
> For what to add(twice) hugetlb_get/put_quota?

Hmm probably a merge error. Thanks for catching. 

I can repost or post the trivial incremential.

-Andi

-- 
a...@linux.intel.com -- Speaking for myself only.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 v4 3/4] fat (exportfs): rebuild directory-inode if fat_dget() fails

[Namjae Jeon]

2012/10/13 OGAWA Hirofumi :
> Namjae Jeon  writes:
>
>> 2012/10/13 OGAWA Hirofumi :
>>> Namjae Jeon  writes:
>>>
 + if (!fat_get_dotdot_entry(child_dir->d_inode, _bh, )) {
 + parent_logstart = fat_get_start(sbi, de);
   parent_inode = fat_dget(sb, parent_logstart);
 + if (parent_inode || sbi->options.nfs != FAT_NFS_NOSTALE_RO)
 + goto out;
 + if (!parent_logstart)
 + /*logstart of dotdot entry is zero if
 + * if the directory's parent is root
 + */
 + parent_inode = sb->s_root->d_inode;
>>>
>>> get_parent() should not be called for root dir, right?
>> Yes.
>
> Ah, actual question was - subdir of root can be passed to this? I guess
> it is possible...
Yes, you're right.

Thanks.
> --
> OGAWA Hirofumi 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [Q] Default SLAB allocator

[Eric Dumazet]

On Sat, 2012-10-13 at 02:51 -0700, David Rientjes wrote:
> On Thu, 11 Oct 2012, Andi Kleen wrote:
> 
> > When did you last test? Our regressions had disappeared a few kernels
> > ago.
> > 
> 
> This was in August when preparing for LinuxCon, I tested netperf TCP_RR on 
> two 64GB machines (one client, one server), four nodes each, with thread 
> counts in multiples of the number of cores.  SLUB does a comparable job, 
> but once we have the the number of threads equal to three times the number 
> of cores, it degrades almost linearly.  I'll run it again next week and 
> get some numbers on 3.6.

In latest kernels, skb->head no longer use kmalloc()/kfree(), so SLAB vs
SLUB is less a concern for network loads.

In 3.7, (commit 69b08f62e17) we use fragments of order-3 pages to
populate skb->head.

SLUB was really bad in the common workload you describe (allocations
done by one cpu, freeing done by other cpus), because all kfree() hit
the slow path and cpus contend in __slab_free() in the loop guarded by
cmpxchg_double_slab(). SLAB has a cache for this, while SLUB directly
hit the main "struct page" to add the freed object to freelist.

I played some months ago adding a percpu associative cache to SLUB, then
just moved on other strategy.

(Idea for this per cpu cache was to build a temporary free list of
objects to batch accesses to struct page)



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 04/25] blackfin: Use Kbuild infrastructure for kvm_para.h

[Bob Liu]

Hi Steven,

On Sat, Oct 13, 2012 at 9:54 PM, Steven Rostedt  wrote:
> On Sat, 2012-10-13 at 00:12 -0400, Mike Frysinger wrote:
>> On Friday 12 October 2012 22:26:36 Steven Rostedt wrote:
>> > From: Steven Rostedt 
>> >
>> > All the headers but kvm_para.h use the Kbuild infrastructure to
>> > get to the asm-generic headers.
>>
>> Acked-by: Mike Frysinger 
>> -mike
>
> Thanks Mike,
>
> Would you want to pull this patch into your tree? It's not dependent on
> any of the other patches.
>

I'll apply this patch to blackfin git tree on Monday.

Thanks,
--Bob
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 v4 3/4] fat (exportfs): rebuild directory-inode if fat_dget() fails

[OGAWA Hirofumi]

Namjae Jeon  writes:

> 2012/10/13 OGAWA Hirofumi :
>> Namjae Jeon  writes:
>>
>>> + if (!fat_get_dotdot_entry(child_dir->d_inode, _bh, )) {
>>> + parent_logstart = fat_get_start(sbi, de);
>>>   parent_inode = fat_dget(sb, parent_logstart);
>>> + if (parent_inode || sbi->options.nfs != FAT_NFS_NOSTALE_RO)
>>> + goto out;
>>> + if (!parent_logstart)
>>> + /*logstart of dotdot entry is zero if
>>> + * if the directory's parent is root
>>> + */
>>> + parent_inode = sb->s_root->d_inode;
>>
>> get_parent() should not be called for root dir, right?
> Yes.

Ah, actual question was - subdir of root can be passed to this? I guess
it is possible...
-- 
OGAWA Hirofumi 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 v2] fat: editions to support fat_fallocate()

[Namjae Jeon]

Implement preallocation via the fallocate syscall on VFAT partitions.
This patch is based on an earlier patch of the same name which had some
issues detailed below and did not get accepted. Refer
https://lkml.org/lkml/2007/12/22/130.

a)The preallocated space was not persistent across remounts when the
FALLOC_FL_KEEP_SIZE flag was set. Also, writes to the file allocated new
clusters instead of using the preallocated area.

Consider the scenario:
mount-->preallocate space for a file --> unmount.
In the old patch,the preallocated space was not reflected for that
file (verified using the 'du' command).

This is now fixed with modifications to fat_fill_inode().

b)There was no need to zero out the clusters when the flag was set.

Instead of doing an expanding truncate, just allocate clusters and add
them to the fat chain. This reduces preallocation time.If the file is
seeked beyond the current file size(i_size) at the time of writing, zero
out the bytes from i_size to the seek point at write time.

Compatibility with windows:
There are no issues when FALLOC_FL_KEEP_SIZE is not set
because it just does an expanding truncate. Thus reading from the
preallocated area on windows returns null until data is written to it.

When a file with preallocated area using the FALLOC_FL_KEEP_SIZE was
written to on windows, the windows driver freed-up the preallocated
clusters and allocated new clusters for the new data. The freed up
clusters gets reflected in the free space available for the partition
which can be seen from the Volume properties.

The windows chkdsk tool also does not report any errors on a
disk containing files with preallocated space.

Signed-off-by: Namjae Jeon 
Signed-off-by: Ravishankar N 
Signed-off-by: Amit Sahrawat 
---
 fs/fat/file.c  |   82 
 fs/fat/inode.c |   59 
 2 files changed, 141 insertions(+)

diff --git a/fs/fat/file.c b/fs/fat/file.c
index 1f81cb4..cae2eec 100644
--- a/fs/fat/file.c
+++ b/fs/fat/file.c
@@ -17,8 +17,11 @@
 #include 
 #include 
 #include 
+#include 
 #include "fat.h"
 
+static long fat_fallocate(struct file *file, int mode,
+   loff_t offset, loff_t len);
 static int fat_ioctl_get_attributes(struct inode *inode, u32 __user *user_attr)
 {
u32 attr;
@@ -174,6 +177,7 @@ const struct file_operations fat_file_operations = {
 #endif
.fsync  = fat_file_fsync,
.splice_read= generic_file_splice_read,
+   .fallocate  = fat_fallocate,
 };
 
 static int fat_cont_expand(struct inode *inode, loff_t size)
@@ -211,7 +215,85 @@ static int fat_cont_expand(struct inode *inode, loff_t 
size)
 out:
return err;
 }
+/*
+ * preallocate space for a file. This implements fat's fallocate file
+ * operation, which gets called from sys_fallocate system call. User
+ * space requests len bytes at offset.If FALLOC_FL_KEEP_SIZE is set
+ * we just allocate clusters without zeroing them out.Otherwise we
+ * allocate and zero out clusters via an expanding truncate.
+ */
+static long fat_fallocate(struct file *file, int mode,
+   loff_t offset, loff_t len)
+{
+   int err = 0;
+   struct inode *inode = file->f_mapping->host;
+   int cluster, nr_cluster, fclus, dclus, free_bytes, nr_bytes;
+   struct super_block *sb = inode->i_sb;
+   struct msdos_sb_info *sbi = MSDOS_SB(sb);
 
+   /* No support for hole punch or other fallocate flags. */
+   if (mode & ~FALLOC_FL_KEEP_SIZE)
+   return -EOPNOTSUPP;
+
+   if ((offset + len) <= MSDOS_I(inode)->mmu_private) {
+   fat_msg(sb, KERN_ERR,
+   "fat_fallocate():Blocks already allocated");
+   return -EINVAL;
+   }
+
+   if ((mode & FALLOC_FL_KEEP_SIZE)) {
+   /* First compute the number of clusters to be allocated */
+   if (inode->i_size > 0) {
+   err = fat_get_cluster(inode, FAT_ENT_EOF,
+ , );
+   if (err < 0) {
+   fat_msg(sb, KERN_ERR,
+   "fat_fallocate():fat_get_cluster() 
error");
+   return err;
+   }
+   free_bytes = ((fclus+1) << sbi->cluster_bits)-
+(inode->i_size);
+   nr_bytes = (offset + len - inode->i_size) - free_bytes;
+   } else
+   nr_bytes = (offset + len - inode->i_size);
+   nr_cluster = (nr_bytes + (sbi->cluster_size - 1)) >>
+sbi->cluster_bits;
+   mutex_lock(>i_mutex);
+   /* Start the allocation.We are not zeroing out the clusters */
+   while (nr_cluster-- > 0) {
+   err = fat_alloc_clusters(inode, , 1);
+   if 

Re: [PATCH 00/25] asm-generic: Convert all to use Kbuild file

[Steven Rostedt]

On Sat, 2012-10-13 at 09:09 +, Arnd Bergmann wrote:

> Note that while you are addressing all the obvious candidates that
> have only a single #include statement in them, there is room to take
> this further because a lot of the other header files in architectures
> are still identical to their asm-generic counterparts (aside from
> whitespace and comments). I would recommend to arch maintainers that
> have not already done so to go through all the headers and replace
> the identical ones with generated headers that include the asm-generic
> version.

I was thinking of doing this as a "take 2", after this set got in.

I'm not sure if it's already there or not, but perhaps checkpatch could
add a way to see if a new file is created in arch/*/include/asm/* that
only adds an include of asm-generic (ignoring the #ifndef _FOO_H
wrappers), and tell the user to use the generic-y += in Kbuild method.

-- Steve


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 00/25] asm-generic: Convert all to use Kbuild file

[Steven Rostedt]

On Sat, 2012-10-13 at 11:17 +0100, Catalin Marinas wrote:
> Hi Steven,
> 
> On 13 October 2012 03:26, Steven Rostedt  wrote:
> > Recently I suggested to someone that was adding a new asm file that
> > currently only contained an x86 change to add a header in all archs
> > that was just a wrapper to point to the asm-generic version. I suggested
> > this because that's the way we use to do it and just to refresh my
> > memory, I looked at div64.h in a few archs and saw that was the case.
> >
> > After having the change done and just after finishing testing it, I was
> > notified that the "proper" way of doing this is to add it to the
> >
> >   arch/*/include/asm/Kbuild
> >
> > file, as 'generic-y += foo.h' and it will reference the asm-generic
> > file automatically. Well it would have been nice if I knew this before
> > and wasn't confused by seeing the incorrect method.
> 
> Since you are  cleaning this up already, could you please merge these
> patches into your series:
> 
> https://lkml.org/lkml/2012/10/11/291
> 
> The first patch adds support for generic-y in the new
> arch/*/include/uapi/asm/Kbuild file, followed by few patches to
> convert three architectures. There will probably be more to convert
> after -rc1.

If the maintainers don't, I'll be happy to take them in too. I can set
up a separate branch for this. I'll see what I can do next week,
although I'll be traveling for the RTLWS.

-- Steve


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 16/25] parisc: Use Kbuild infrastructure to handle asm-generic headers

[Steven Rostedt]

On Sat, 2012-10-13 at 13:36 +0100, James Bottomley wrote:
> On Fri, 2012-10-12 at 22:26 -0400, Steven Rostedt wrote:
> > plain text document attachment
> > (0016-parisc-Use-Kbuild-infrastructure-to-handle-asm-gener.patch)
> > From: Steven Rostedt 
> > 
> > Use Kbuild infrastructure to handle the asm-generic headers
> > and remove the wrapper headers that call them.
> > 
> > This only affects headers that do nothing but include the generic
> > equivalent. It does not touch any header that does a little more.
> > 
> > Cc: linux-kbu...@vger.kernel.org
> > Cc: linux-par...@vger.kernel.org
> > Cc: "James E.J. Bottomley" 
> > Cc: Helge Deller 
> > Signed-off-by: Steven Rostedt 
> 
> Actually, we're already evaluating a patch like this:
> 
> http://marc.info/?l=linux-kernel=134883983019018
> 
> When I compare the two, I notice you missed a few (segment.h, vga.h,
> hw_irq.h, mutex.h), so you probably want to adjust your scripts.
> 

Scripts? Naw I did this by hand:

cd arch/parisc/include/asm
vim `grep -l asm-generic *.h`

And in another terminal added the changes needed to Kbuild. I did this
by hand because it would have taken me the same time to verify scripts
to do it. By doing it by hand, I was less likely to add something that I
shouldn't have.

As Arnd mentioned, I didn't do a compare to check if what is in the
header is identical to the asm-generic version. That was going to be
"take 2". As this was just removing the simple cases of either:

foo.h:
#include 

or

foo.h:
#ifndef _ASM_PARISC_FOO_H
#define _ASM_PARISC_FOO_H
#include 
#endif

As for the ones I missed:

mutex.h has:

#include 

which did not match mutex.h, so I ignored it. It would be removed in
"take 2" because it's identical to asm-generic/mutex.h.

segment.h:
#ifndef __PARISC_SEGMENT_H
#define __PARISC_SEGMENT_H

/* Only here because we have some old header files that expect it.. */

#endif


It missed the 'grep -l asm-generic' part.

vga.h and hw_irq.h are also empty (no asm-generic added). segment.h and
hw_irq.h are also empty in asm-generic, so they could be removed in take
2 as well. vga.h has some defines, but probably wouldn't affect parisc.

I don't care if you take this patch or not. As long as the old method of
adding a stub file to include asm-generic/foo.h is removed. This patch
set was caused by my frustration of looking at how to add a new
asm-generic file and coming up with the wrong implementation, and I want
to make sure that this doesn't happen again with another developer.

-- Steve


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 V2 3/3] ARM: SPEAr13xx: Pass DW DMAC platform data from DT

[Viresh Kumar]

On 13 October 2012 19:38, Viresh Kumar  wrote:
> On 13 October 2012 17:52, Jean-Christophe PLAGNIOL-VILLARD
>  wrote:
>> On 14:18 Sat 13 Oct , Viresh Kumar wrote:
>>>On Oct 13, 2012 12:16 PM, "Jean-Christophe PLAGNIOL-VILLARD"
>>> wrote:
>>>>
>>>> On 22:42 Fri 12 Oct , Viresh Kumar wrote:
>>>> > On 12 October 2012 21:51, Jean-Christophe PLAGNIOL-VILLARD
>>>> >  wrote:
>>>> > >> >> + OF_DEV_AUXDATA("arasan,cf-spear1340", MCIF_CF_BASE, NULL,
>>>"cf"),
>>>> > >> > ?/
>>>> > >>
>>>> > >> Sorry. can't get it :(
>>>> > > what is the "cf" as paltfrom data
>>>> >
>>>> > This is dma bus_id string, which matches with what is passed from 
>>> dtb.
>>>> so pass if via dtb too
>>>
>>>Yes. Already passed in 13xx.dtsi.

Probably some confusion here. What i meant to say here is, dmac's
DT slave info has a node for cf and cf driver expects this string to come
via platform data currently.

>> so why do you keep the AUXDATA
>
> Because the compact flash driver expects it via platform data and not
> via DT. yes, it
> can be changed, but that wasn't the target of this patchset. If it has
> to be done, then
> it has to be done separately by ST guys.

--
viresh
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 V2 3/3] ARM: SPEAr13xx: Pass DW DMAC platform data from DT

[Viresh Kumar]

On 13 October 2012 17:52, Jean-Christophe PLAGNIOL-VILLARD
 wrote:
> On 14:18 Sat 13 Oct , Viresh Kumar wrote:
>>On Oct 13, 2012 12:16 PM, "Jean-Christophe PLAGNIOL-VILLARD"
>> wrote:
>>>
>>> On 22:42 Fri 12 Oct , Viresh Kumar wrote:
>>> > On 12 October 2012 21:51, Jean-Christophe PLAGNIOL-VILLARD
>>> >  wrote:
>>> > >> >> + OF_DEV_AUXDATA("arasan,cf-spear1340", MCIF_CF_BASE, NULL,
>>"cf"),
>>> > >> > ?/
>>> > >>
>>> > >> Sorry. can't get it :(
>>> > > what is the "cf" as paltfrom data
>>> >
>>> > This is dma bus_id string, which matches with what is passed from dtb.
>>> so pass if via dtb too
>>
>>Yes. Already passed in 13xx.dtsi.
> so why do you keep the AUXDATA

Because the compact flash driver expects it via platform data and not
via DT. yes, it
can be changed, but that wasn't the target of this patchset. If it has
to be done, then
it has to be done separately by ST guys.

--
viresh
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 v4 3/4] fat (exportfs): rebuild directory-inode if fat_dget() fails

[Namjae Jeon]

2012/10/13 OGAWA Hirofumi :
> Namjae Jeon  writes:
>
>> + if (!fat_get_dotdot_entry(child_dir->d_inode, _bh, )) {
>> + parent_logstart = fat_get_start(sbi, de);
>>   parent_inode = fat_dget(sb, parent_logstart);
>> + if (parent_inode || sbi->options.nfs != FAT_NFS_NOSTALE_RO)
>> + goto out;
>> + if (!parent_logstart)
>> + /*logstart of dotdot entry is zero if
>> + * if the directory's parent is root
>> + */
>> + parent_inode = sb->s_root->d_inode;
>
> get_parent() should not be called for root dir, right?
Yes.
>
>> + blknr = fat_clus_to_blknr(sbi, parent_logstart);
>> + parent_bh = sb_bread(sb, blknr);
>> + if (!parent_bh) {
>> + fat_msg(sb, KERN_ERR,
>> + "NFS:unable to read cluster of parent 
>> directory");
>> + goto out;
>> + }
>> + de = (struct msdos_dir_entry *) parent_bh->b_data;
>> + clus_to_match = fat_get_start(sbi, [0]);
>> + search_clus = fat_get_start(sbi, [1]);
>> + if (!search_clus)
>> + search_clus = sbi->root_cluster;
>> + brelse(parent_bh);
>> + do {
>> + parent_inode =  fat_traverse_cluster(sb,
>> + search_clus, clus_to_match);
>> + if (IS_ERR(parent_inode) || parent_inode)
>> + break;
>> + search_clus = fat_read_next_clus(sb,
>> + search_clus);
>> + if (search_clus < 0)
>> + break;
>> + } while (search_clus != FAT_ENT_EOF);
>> + }
>
> Please make this part as own function at least. And this is doing same
> thing with readdir, so we will have to clean this up as I said before.
Okay, I will.

Thanks.
> --
> OGAWA Hirofumi 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 23/25] unicore32: Use Kbuild infrastructure for kvm_para.h

[Steven Rostedt]

On Sat, 2012-10-13 at 20:27 +0800, guanxue...@mprc.pku.edu.cn wrote:
> > From: Steven Rostedt 
> >
> > All the headers but kvm_para.h use the Kbuild infrastructure to
> > get to the asm-generic headers.
> 
> I merged the uapi patch for unicore32.
> In that patch, kvm_para.h was moved to
> arch/unicore32/include/uapi/asm/kvm_para.h.
> Anyway, I'd like to apply this patch based on uapi modification.
> 

Sure, do whatever you want ;-)

-- Steve


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 v4 2/4] fat (exportfs): rebuild inode if ilookup() fails

[Namjae Jeon]

Hi. OGAWA.
2012/10/13 OGAWA Hirofumi :
> Namjae Jeon  writes:
>
>> --- a/fs/fat/fat.h
>> +++ b/fs/fat/fat.h
>> @@ -214,6 +214,13 @@ static inline sector_t fat_clus_to_blknr(struct 
>> msdos_sb_info *sbi, int clus)
>>   + sbi->data_start;
>>  }
>>
>> +static inline void fat_get_blknr_offset(struct msdos_sb_info *sbi,
>> + loff_t i_pos, sector_t *blknr, int *offset)
>> +{
>> + *blknr = i_pos >> sbi->dir_per_block_bits;
>> + *offset = i_pos & (sbi->dir_per_block - 1);
>> +}
>> +
>
> Let's separate fat_get_blknr_offset() cleanup and others.
Okay.
>
>> +extern loff_t fat_i_pos_read(struct msdos_sb_info *sbi, struct inode 
>> *inode);
>
> [...]
>
>> -static inline loff_t fat_i_pos_read(struct msdos_sb_info *sbi,
>> +loff_t fat_i_pos_read(struct msdos_sb_info *sbi,
>>   struct inode *inode)
>>  {
>>   loff_t i_pos;
>
> Let's move fat_i_pos_read() to fat.h to make consists with
> fat_get_blknr_offset().
Okay.
>
>>  static const struct export_operations fat_export_ops = {
>> + .encode_fh  = fat_encode_fh,
>>   .fh_to_dentry   = fat_fh_to_dentry,
>>   .fh_to_parent   = fat_fh_to_parent,
>>   .get_parent = fat_get_parent,
>> diff --git a/fs/fat/nfs.c b/fs/fat/nfs.c
>> index ef4b5fa..156903b 100644
>> --- a/fs/fat/nfs.c
>> +++ b/fs/fat/nfs.c
>> @@ -14,6 +14,14 @@
>>  #include 
>>  #include "fat.h"
>>
>> +struct fat_fid {
>> + u32 ino;
>> + u32 gen;
>> + u64 i_pos;
>> + u32 parent_ino;
>> + u32 parent_gen;
>> +} __packed;
>
> This is sizeof(fat_fid)/sizoef(u32) == 6. IIRC, nfsv2 is not supporting
> FH > 6, true?
I will check and share the result.
>
>> +int
>> +fat_encode_fh(struct inode *inode, __u32 *fh, int *lenp, struct inode 
>> *parent)
>> +{
>> + int len = *lenp;
>> + struct msdos_sb_info *sbi = MSDOS_SB(inode->i_sb);
>> + struct fat_fid *fid = (struct fat_fid *) fh;
>> + loff_t i_pos;
>> + int type = FILEID_INO32_GEN;
>> +
>> + if (parent && (len < 5)) {
>> + *lenp = 5;
>> + return 255;
>> + } else if (len < 3) {
>> + *lenp = 3;
>> + return 255;
>> + }
>> +
>> + i_pos = fat_i_pos_read(sbi, inode);
>> + *lenp = 3;
>> + fid->ino = inode->i_ino;
>> + fid->gen = inode->i_generation;
>> + fid->i_pos = i_pos;
>> + if (parent) {
>> + fid->parent_ino = parent->i_ino;
>> + fid->parent_gen = parent->i_generation;
>> + type = FILEID_INO32_GEN_PARENT;
>> + *lenp = 5;
>> + }
>> +
>> + return type;
>> +}
>
> I was also thinking to use same FH though, because of limitation of FH
> size. It looks like to be better to separate with "stale_rw".
>
> So, how about to separate at export_operations level?
Good idea!
>
> I.e. (move export_operations to fat/nfs.c)
>
> For stale_rw,
>
> const struct export_operations fat_export_ops = {
> .fh_to_dentry   = fat_fh_to_dentry,
> .fh_to_parent   = fat_fh_to_parent,
> .get_parent = fat_get_parent,
> }
>
> For nostale_ro,
>
> const struct export_operations fat_export_ops = {
> .fh_to_dentry   = fat_encode_fh,
> .fh_to_dentry   = fat_fh_to_dentry,
> .fh_to_parent   = fat_fh_to_parent,
> .get_parent = fat_get_parent,
> }
>
> And we have to think about FH format. I guess we don't need to
> inode->i_ino for nostale_ro.
>
> Maximum i_pos is 40bits, and i_gen is 32bit. So, inode and parent inode
> fits to FH of 5 len, we have to pack those though.
>
> I.e.
>
> struct fat_fid {
> u32 i_gen;
> u32 i_pos_low;
> u16 i_pos_hi;
> u16 parent_i_pos_hi;
> u32 parent_i_pos_low;
> u32 parent_i_gen;
> } __packed;
>
> And define FILEID_FAT_WITHOUT_PARENT and FILEID_FAT_WITH_PARENT.
>
> User of i_ino is only ilookup, right? So, we can add fat_ilookup() for it.
Okay.
>
> struct inode *fat_ilookup(struct super_block *sb, u64 ino)
> {
> if (stale_rw)
> return ilookup(sb, ino);
>
> return fat_iget(sb, i_pos);
> }
>
> And I noticed we need lock for fat_build_inode() for nostale_ro. Because
> fat_nfs_get_inode() doesn't hold i_mutex of parent dir, right? So, add
> lock to fat_build_inode()
>
> static inline void fat_build_inode_lock(struct msdos_sb_info *sbi)
> {
> if (sbi->options.nfs == FAT_NFS_NOSTALE_RO)
> mutex_lock(>nfs_build_inode_lock);
> }
>
> static inline void fat_build_inode_unlock(struct msdos_sb_info *sbi)
> {
> if (sbi->options.nfs == FAT_NFS_NOSTALE_RO)
> mutex_unlock(>nfs_build_inode_lock);
> }
Thanks for specific review and suggestion. :)
I will change the patches as your suggestion.
Hum.. And currently these patch-set was pushed to -mm tree and linux-next.
I am confusing I should request to revert these patch-set or make new
patches base on these patch-set

Thanks.
> --
> OGAWA Hirofumi 
--
To unsubscribe from this list: 

Re: [PATCH 15/25] openrisc: Use Kbuild infrastructure for kvm_para.h

[Steven Rostedt]

On Sat, 2012-10-13 at 08:32 +0200, Jonas Bonn wrote:
> On 13 October 2012 04:26, Steven Rostedt  wrote:
> > From: Steven Rostedt 
> >
> > All the headers but kvm_para.h use the Kbuild infrastructure to
> > get to the asm-generic headers.
> >
> > Cc: linux-kbu...@vger.kernel.org
> > Cc: li...@lists.openrisc.net
> > Cc: Jonas Bonn 
> > Signed-off-by: Steven Rostedt 
> 
> Acked-by: Jonas Bonn 

Thanks Jonas,

Would you like to pull this into your tree? It's not dependent on any of
the other patches. Or I can take care of it too.

-- Steve


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 04/25] blackfin: Use Kbuild infrastructure for kvm_para.h

[Steven Rostedt]

On Sat, 2012-10-13 at 00:12 -0400, Mike Frysinger wrote:
> On Friday 12 October 2012 22:26:36 Steven Rostedt wrote:
> > From: Steven Rostedt 
> > 
> > All the headers but kvm_para.h use the Kbuild infrastructure to
> > get to the asm-generic headers.
> 
> Acked-by: Mike Frysinger 
> -mike

Thanks Mike,

Would you want to pull this patch into your tree? It's not dependent on
any of the other patches.

-- Steve


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 20/25] sparc: Use Kbuild infrastructure to handle asm-generic headers

[Steven Rostedt]

On Fri, 2012-10-12 at 23:19 -0400, David Miller wrote:
> From: Steven Rostedt 
> Date: Fri, 12 Oct 2012 22:26:52 -0400
> 
> > From: Steven Rostedt 
> > 
> > Use Kbuild infrastructure to handle the asm-generic headers
> > and remove the wrapper headers that call them.
> > 
> > This only affects headers that do nothing but include the generic
> > equivalent. It does not touch any header that does a little more.
> > 
> > Cc: linux-kbu...@vger.kernel.org
> > Cc: sparcli...@vger.kernel.org
> > Cc: "David S. Miller" 
> > Signed-off-by: Steven Rostedt 
> 
> Acked-by: David S. Miller 

David,

Would you like to take this patch? It's not dependent on any of the
other patches. Otherwise I'll probably ask Andrew to pull it into his
tree. Or I can just set up a branch and have it go into linux-next for
the next merge window.

-- Steve


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: Local DoS through write heavy I/O on CFQ & Deadline

[Hillf Danton]

Hi Alex,

On Sat, Oct 13, 2012 at 12:29 AM, Alex Bligh  wrote:
> Michael,
>
> --On 12 October 2012 16:58:39 +0200 Michal Hocko  wrote:
>
>> Once dirty_ratio (resp. dirty_bytes) limit is hit then the process which
>> writes gets throttled. If this is not the case then there is a bug in
>> the throttling code.
>
>
> I believe that is the problem.

Take a look at the "wait for writeback" problem please.

Linux 3.0+ Disk performance problem - wrong pdflush behaviour
https://lkml.org/lkml/2012/10/10/412

Hillf
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: dtc: import latest upstream dtc

[Segher Boessenkool]

Oh, that's strange.  I'm pretty sure I've used -x assembler when I've
experimented with using cpp on dts manually before, and it seems to
have worked.


Maybe you used "-x assembler-with-cpp"?  That should work better ;-)
Or just use the "-traditional-cpp" option, i.e. "gcc -E -traditional- 
cpp".



  Note that IIRC with gcc cpp, -x assembler also means
that # won't be handled as a cpp directive except in column 0 which is
also an advantage for us, although no longer essential with your
escaping support.  Not all cpps have an equivalent option, though.


This is how the traditional C pre-processor behaves.  I don't think
this is exactly what matters for DTS, or does it ever happen that
you have a # preceded only by whitespace?  The # and ## stringification
and token pasting ops will of course bite you with the ISO C pre- 
processor,

indeed.


Segher

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] task_work: Add local_irq_enable() into task_work_run()

[Thorsten Kranzkowski]

On Sat, Oct 13, 2012 at 10:09:36AM +0900, Linus Torvalds wrote:
> On Sat, Oct 13, 2012 at 1:03 AM, Oleg Nesterov  wrote:
> > arch/alpha and probably some other architectures call
> > do_notify_resume()->task_work_run() with irqs disabled.
> 
> I'm going to ignore this patch because I *hope* it is unnecessary
> after the pull from Al that I just did.
> 
> But if that turns out to be not the case, please holler. Torsten, you
> seem to be the one who reported this, can you check the current git
> tree?

I can confirm that 4d7127d (i.e. without Olegs patch) boots without problems.

There is still the warning below, but it was already present before the
breakage.

Thanks to everyone involved,
Thorsten

> 
> Thanks,
> 
>Linus


SMP starting up secondaries.
Brought up 2 CPUs
SMP: Total of 2 processors activated (1985.89 BogoMIPS).
xor: automatically using best checksumming function:
   alpha prefetch:  2097.152 MB/sec
NET: Registered protocol family 16
[ cut here ]
WARNING: at /usr/src/linux.git/kernel/softirq.c:139 
__local_bh_enable+0x8c/0xbc()
Modules linked in:
fcb83c80 fcb924b8 fc32cc14 fcbc4078 
   0200  0001  
   fc32d130 fcb7d980 fcc27160  
   fc3535c4  fc31a93c  
   fcb84000  fc3157a0 fcb83dc0 
   0be0  fc0001e060c0  
Trace:
[] __local_bh_enable+0x8c/0xbc
[] irq_enter+0x58/0x78
[] scheduler_ipi+0x50/0xec
[] handle_ipi+0xb8/0x248
[] do_entInt+0x6c/0x240
[] irq_exit+0x68/0x7c
[] handle_irq+0xd4/0xf4
[] do_entInt+0x130/0x240
[] ret_from_sys_call+0x0/0x10
[] load_balance+0x1e4/0x770
[] cpu_idle+0x2c/0x6c
[] atomic_add.constprop.42+0x0/0x14
[] cpu_idle+0x38/0x6c
[] rest_init+0xc0/0xd4
[] _stext+0x1c/0x20

---[ end trace 40b31a85666b44ea ]---
PCI host bridge to bus :00
pci_bus :00: root bus resource [io  0x-0x1ff]
pci_bus :00: root bus resource [mem 0x-0x3fff]
pci_bus :00: No busn resource found for root bus, will use [bus 00-ff]




-- 
| Thorsten KranzkowskiInternet: dl8...@dl8bcu.de  |
| Mobile: ++49 170 1876134   Snail: Kiebitzstr. 14, 49324 Melle, Germany  |
| Ampr: dl8bcu@db0lj.#rpl.deu.eu, dl8...@marvin.dl8bcu.ampr.org [44.130.8.19] |
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] i2c: tegra: set irq name as device name

[Jean Delvare]

On Fri, 12 Oct 2012 23:19:32 +0530, Laxman Dewangan wrote:
> When watching the irqs name of tegra i2c, all instances
> irq name shows as tegra_i2c.
> 
> Passing the device name properly to have the irq names with
> instance like tegra-i2c.0, tegra-i2c.1 etc.
> 
> Signed-off-by: Laxman Dewangan 
> ---
>  drivers/i2c/busses/i2c-tegra.c |2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/drivers/i2c/busses/i2c-tegra.c b/drivers/i2c/busses/i2c-tegra.c
> index f981ac4..dcea77b 100644
> --- a/drivers/i2c/busses/i2c-tegra.c
> +++ b/drivers/i2c/busses/i2c-tegra.c
> @@ -742,7 +742,7 @@ static int __devinit tegra_i2c_probe(struct 
> platform_device *pdev)
>   }
>  
>   ret = devm_request_irq(>dev, i2c_dev->irq,
> - tegra_i2c_isr, 0, pdev->name, i2c_dev);
> + tegra_i2c_isr, 0, dev_name(>dev), i2c_dev);
>   if (ret) {
>   dev_err(>dev, "Failed to request irq %i\n", i2c_dev->irq);
>   return ret;

Good idea.

Acked-by: Jean Delvare 

-- 
Jean Delvare
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 v2 1/7] swiotlb: Make io_tlb_end a physical address instead of a virtual one

[Hillf Danton]

Hi Alexander,

On Fri, Oct 12, 2012 at 4:34 AM, Alexander Duyck
 wrote:
> This change replaces all references to the virtual address for io_tlb_end
> with references to the physical address io_tlb_end.  The main advantage of
> replacing the virtual address with a physical address is that we can avoid
> having to do multiple translations from the virtual address to the physical
> one needed for testing an existing DMA address.
>
> Signed-off-by: Alexander Duyck 
> ---
>
>  lib/swiotlb.c |   24 +---
>  1 files changed, 13 insertions(+), 11 deletions(-)
>
> diff --git a/lib/swiotlb.c b/lib/swiotlb.c
> index f114bf6..19aac9f 100644
> --- a/lib/swiotlb.c
> +++ b/lib/swiotlb.c
> @@ -57,7 +57,8 @@ int swiotlb_force;
>   * swiotlb_tbl_sync_single_*, to see if the memory was in fact allocated by 
> this
>   * API.
>   */
> -static char *io_tlb_start, *io_tlb_end;
> +static char *io_tlb_start;
> +phys_addr_t io_tlb_end;

If add io_tlb_start_phy and io_tlb_end_phy, could we get same results
with less hunks?

Hillf
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [Q] Default SLAB allocator

[Ezequiel Garcia]

Hi David,

On Sat, Oct 13, 2012 at 6:54 AM, David Rientjes  wrote:
> On Fri, 12 Oct 2012, Ezequiel Garcia wrote:
>
>> >> SLUB is a non-starter for us and incurs a >10% performance degradation in
>> >> netperf TCP_RR.
>> >
>>
>> Where are you seeing that?
>>
>
> In my benchmarking results.
>
>> Notice that many defconfigs are for embedded devices,
>> and many of them say "use SLAB"; I wonder if that's right.
>>
>
> If a device doesn't require the smallest memory footprint possible (SLOB)
> then SLAB is the right choice when there's a limited amount of memory;
> SLUB requires higher order pages for the best performance (on my desktop
> system running with CONFIG_SLUB, over 50% of the slab caches default to be
> high order).
>

But SLAB suffers from a lot more internal fragmentation than SLUB,
which I guess is a known fact. So memory-constrained devices
would waste more memory by using SLAB.
I must admit a didn't look at page order (but I will now).


>> Is there any intention to replace SLAB by SLUB?
>
> There may be an intent, but it'll be nacked as long as there's a
> performance degradation.
>
>> In that case it could make sense to change defconfigs, although
>> it wouldn't be based on any actual tests.
>>
>
> Um, you can't just go changing defconfigs without doing some due diligence
> in ensuring it won't be deterimental for those users.

Yeah, it would be very interesting to compare SLABs on at least
some of those platforms.


Ezequiel
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/4] MMC: omap_hsmmc: set platform data after probe from DT node

[Grant Likely]

Daniel Mack  wrote:

>On 13.10.2012 10:48, Grant Likely wrote:
>> 
>> somedriver_probe(struct platform_device *pdev)
>> {
>>   struct somedriver_private *somedriver;
>> 
>>   somedriver = devm_kzalloc(sizeof (*somedriver), GFP_KERNEL);
>>   somedriver->pdata = pdev->platform_data;
>>   if (OF)
>>   somedriver->pdata = devm_kzalloc(sizeof
>> (*somedriver->pdata), GFP_KERNEL);
>> }
>> 
>> The bonus with using devm_kzalloc is the driver doesn't even need to
>> do anything special to undo these allocations on failure or release.
>> :-)
>
>Ok, understood. Will keep an eye on this in the future. Thanks again
>for
>the explanation.
>
>For this particular driver, this means that both my and Balaji's ways
>of
>fixing this are wrong?

Balaji's patch looks fine since it uses a local copy of the platform data 
structure. It appears that the driver is already creating a local copy and 
Balaji is just bug fixing call sites that aren't using it yet.

g.

-- 
Grant Likely, P.Eng.
Secret Lab Technologies Ltd.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 00/16] f2fs: introduce flash-friendly file system

[Jaegeuk Kim]

2012-10-13 (토), 13:26 +0900, Namjae Jeon:
> Is there high possibility that the storage device can be rapidly
> worn-out by cleaning process ? e.g. severe fragmentation situation by
> creating and removing small files.
> 

Yes, the cleaning process in F2FS induces additional writes so that
flash storage can be worn out quickly.
However, how about in traditonal file systems?
As all of us know that, FTL has an wear-leveling issue too due to the
garbage collection overhead that is fundamentally similar to the
cleaning overhead in LFS or F2FS.

So, what's the difference between them?
IMHO, the major factor to reduce the cleaning or garbage collection
overhead is how to efficiently separate hot and cold data.
So, which is a better layer between FTL and file system to achieve that?
I think the answer is the file system, since the file system has much
more information on such a hotness of all the data, but FTL doesn't know
or is hard to figure out that kind of information.

Therefore, I think the LFS approach is more beneficial to span the life
time of the storage rather than traditional one.
And, in order to do this perfectly, one thing is a criteria, the
alignment between FTL and F2FS.

> And you told us only advantages of f2fs. Would you tell us the disadvantages ?

I think there is a scenario like this.
1) One big file is created and written data sequentially.
2) Many random writes are done across the whole file range.
3) User discards cached data by doing "drop_caches" or "reboot".

At this point, I worry about the sequential read performance due to the
fragmentation.
I don't know how frequently this use-case happens, but it is one of cons
in the LFS approach.
Nevertheless, I'm thinking that the performance could be enhanced by
cooperating with a readahead mechanism in VFS.

Thanks,

> 
> Thanks.

-- 
Jaegeuk Kim
Samsung

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 16/25] parisc: Use Kbuild infrastructure to handle asm-generic headers

[James Bottomley]

On Fri, 2012-10-12 at 22:26 -0400, Steven Rostedt wrote:
> plain text document attachment
> (0016-parisc-Use-Kbuild-infrastructure-to-handle-asm-gener.patch)
> From: Steven Rostedt 
> 
> Use Kbuild infrastructure to handle the asm-generic headers
> and remove the wrapper headers that call them.
> 
> This only affects headers that do nothing but include the generic
> equivalent. It does not touch any header that does a little more.
> 
> Cc: linux-kbu...@vger.kernel.org
> Cc: linux-par...@vger.kernel.org
> Cc: "James E.J. Bottomley" 
> Cc: Helge Deller 
> Signed-off-by: Steven Rostedt 

Actually, we're already evaluating a patch like this:

http://marc.info/?l=linux-kernel=134883983019018

When I compare the two, I notice you missed a few (segment.h, vga.h,
hw_irq.h, mutex.h), so you probably want to adjust your scripts.

James


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] MM: Support more pagesizes for MAP_HUGETLB/SHM_HUGETLB v4

[Hillf Danton]

Hi Andi,

On Fri, Oct 12, 2012 at 7:53 AM, Andi Kleen  wrote:
> diff --git a/include/linux/hugetlb.h b/include/linux/hugetlb.h
> index 2251648..c626a2a 100644
> --- a/include/linux/hugetlb.h
> +++ b/include/linux/hugetlb.h
> @@ -183,7 +183,13 @@ extern const struct file_operations 
> hugetlbfs_file_operations;
>  extern const struct vm_operations_struct hugetlb_vm_ops;
>  struct file *hugetlb_file_setup(const char *name, unsigned long addr,
> size_t size, vm_flags_t acct,
> -   struct user_struct **user, int creat_flags);
> +   struct user_struct **user, int creat_flags,
> +   int page_size_log);
> +int hugetlb_get_quota(struct address_space *mapping, long delta);
> +void hugetlb_put_quota(struct address_space *mapping, long delta);
> +
> +int hugetlb_get_quota(struct address_space *mapping, long delta);
> +void hugetlb_put_quota(struct address_space *mapping, long delta);


For what to add(twice) hugetlb_get/put_quota?

Hillf
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 V2 3/3] ARM: SPEAr13xx: Pass DW DMAC platform data from DT

[Jean-Christophe PLAGNIOL-VILLARD]

On 14:18 Sat 13 Oct , Viresh Kumar wrote:
>On Oct 13, 2012 12:16 PM, "Jean-Christophe PLAGNIOL-VILLARD"
> wrote:
>>
>> On 22:42 Fri 12 Oct , Viresh Kumar wrote:
>> > On 12 October 2012 21:51, Jean-Christophe PLAGNIOL-VILLARD
>> >  wrote:
>> > >> >> + OF_DEV_AUXDATA("arasan,cf-spear1340", MCIF_CF_BASE, NULL,
>"cf"),
>> > >> > ?/
>> > >>
>> > >> Sorry. can't get it :(
>> > > what is the "cf" as paltfrom data
>> >
>> > This is dma bus_id string, which matches with what is passed from dtb.
>> so pass if via dtb too
> 
>Yes. Already passed in 13xx.dtsi.
so why do you keep the AUXDATA

Best Regards,
J.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 23/25] unicore32: Use Kbuild infrastructure for kvm_para.h

[guanxuetao]

> From: Steven Rostedt 
>
> All the headers but kvm_para.h use the Kbuild infrastructure to
> get to the asm-generic headers.

I merged the uapi patch for unicore32.
In that patch, kvm_para.h was moved to
arch/unicore32/include/uapi/asm/kvm_para.h.
Anyway, I'd like to apply this patch based on uapi modification.

Thanks & Regards,
Guan Xuetao

>
> Cc: linux-kbu...@vger.kernel.org
> Cc: Guan Xuetao 
> Signed-off-by: Steven Rostedt 
> ---
>  arch/unicore32/include/asm/Kbuild |1 +
>  arch/unicore32/include/asm/kvm_para.h |1 -
>  2 files changed, 1 insertion(+), 1 deletion(-)
>  delete mode 100644 arch/unicore32/include/asm/kvm_para.h
>
> diff --git a/arch/unicore32/include/asm/Kbuild
> b/arch/unicore32/include/asm/Kbuild
> index c910c98..15b47f2 100644
> --- a/arch/unicore32/include/asm/Kbuild
> +++ b/arch/unicore32/include/asm/Kbuild
> @@ -24,6 +24,7 @@ generic-y += ipcbuf.h
>  generic-y += irq_regs.h
>  generic-y += kdebug.h
>  generic-y += kmap_types.h
> +generic-y += kvm_para.h
>  generic-y += local.h
>  generic-y += mman.h
>  generic-y += module.h
> diff --git a/arch/unicore32/include/asm/kvm_para.h
> b/arch/unicore32/include/asm/kvm_para.h
> deleted file mode 100644
> index 14fab8f..000
> --- a/arch/unicore32/include/asm/kvm_para.h
> +++ /dev/null
> @@ -1 +0,0 @@
> -#include 
> --
> 1.7.10.4
>
>

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] video/udlfb: fix line counting in fb_write

[Alexander Holler]

Am 10.10.2012 14:29, schrieb Florian Tobias Schandinat:
> On 08/14/2012 07:11 AM, Alexander Holler wrote:
>> Line 0 and 1 were both written to line 0 (on the display) and all
>> subsequent
>> lines had an offset of -1. The result was that the last line on the display
>> was never overwritten by writes to /dev/fbN.
>>
>> Cc: sta...@vger.kernel.org
>> Signed-off-by: Alexander Holler 
> 
> As Bernie agreed but didn't send me a pull request, I applied this one.

Thanks a lot.

> Though the formatting was screwed up and I had to fix it...

Sorry, must have happened because I've used "Edit as new" in Thunderbird
to resend the patch while just adding the RESEND to the subject.

Good to know.

Thanks,

Alexander

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 02/16] f2fs: add on-disk layout

[Jaegeuk Kim]

2012-10-12 (금), 21:05 +, Arnd Bergmann:
> On Friday 05 October 2012 20:56:44 김재극 wrote:
> > +struct f2fs_nat_entry {
> > +   __u8 version;
> > +   __le32 ino;
> > +   __le32 block_addr;
> > +} __packed;
> > +
> > +struct f2fs_nat_block {
> > +   struct f2fs_nat_entry entries[NAT_ENTRY_PER_BLOCK];
> > +} __packed;
> 
> Using "__packed" on structure is rather inefficient on CPU architectures
> that cannot do aligned accesses. I would suggest you remove this
> attribute everywhere you can. The f2fs_nat_entry is particularly
> suboptimal because it is 9 bytes long, and I'm not sure if this
> can be reasonably changed to a multiple of four.
> 
> In all other cases, you should try to lay out the structures
> so that each member is naturally aligned and you don't need any __packed
> attributes, in particular for those that are accessed a lot.
> 

Ok, I'll check all the in-memory data structures.
Thank you for comments.

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

-- 
Jaegeuk Kim
Samsung

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 v2 0/4] DMA: PL330: Fix mem leaks and balance probe/remove

[Jassi Brar]

On Fri, Oct 5, 2012 at 3:47 PM, Inderpal Singh
 wrote:
> The first 2 patches of this series fix memory leaks because the memory
> allocated for peripheral channels and DMA descriptors were not getting
> freed.
>
> The last 2 patches balance the module's remove function.
>
> This series depends on "61c6e7531d3b66b3 DMA: PL330: Check the
> pointer returned by kzalloc" which is on slave-dma's "fixes" branch.
> Hence slave-dma tree's "next" branch was merged with "fixes" and
> applied patch at [1] to fix the build error.
>
> [1] http://permalink.gmane.org/gmane.linux.kernel.next/24274
>
> Changes since v1:
>  - Protect only list_add_tail with spin_locks
>  - Return EBUSY from remove if channel is in use
>  - unregister dma_device in remove
>
> Inderpal Singh (4):
>   DMA: PL330: Free memory allocated for peripheral channels
>   DMA: PL330: Change allocation method to properly free  DMA
> descriptors
>   DMA: PL330: Balance module remove function with probe
>   DMA: PL330: unregister dma_device in module's remove function
>
>  drivers/dma/pl330.c |   53 
> ---
>  1 file changed, 38 insertions(+), 15 deletions(-)
>
All seem fine.
Acked-by: Jassi Brar 

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

[GIT PULL] UAPI disintegration for include/linux/{,byteorder/}*.h

[David Howells]

Hi Linus,

Could you pull this please?  I would recommend pulling it fairly late in the
merge window and though I regenerated it today, it may also be worth
regenerating it again before you pull it if you delay a few days.  Also I may
get acks for the unexport patches.

The patches contained herein do the following:

 (1) Remove kernel-only stuff in linux/ppp-comp.h from the UAPI.  I checked
 this with Paul Mackerras before I created the patch and he suggested some
 extra bits to unexport.

 (2) Remove linux/blk_types.h entirely from the UAPI as none of it is userspace
 applicable, and remove from the UAPI that part of linux/fs.h that was the
 reason for linux/blk_types.h being exported in the first place.  I
 discussed this with Jens Axboe before creating the patch.

 (3) The big patch of the series to disintegrate include/linux/*.h as a unit.
 This could be split up, though there would be collisions in moving stuff
 between the two Kbuild files when the parts are merged as that file is
 sorted alphabetically rather than being grouped by subsystem.

 Of this set of headers, 17 files have changed in the UAPI exported region
 since the 4th and only 8 since the 9th so there isn't much change in this
 area - as one might expect.

 It should be pretty obvious and straightforward if it does come to fixing
 up: stuff in __KERNEL__ guards stays where it is and stuff outside moves
 to the same file in the include/uapi/linux/ directory.

 If a new file appears then things get a bit more complicated as the
 "headers +=" line has to move to include/uapi/linux/Kbuild.  Only one new
 file has appeared since the 9th and I judge this type of event relatively
 unlikely.

 (4) A patch to disintegrate include/linux/byteorder/*.h as a unit.

Signed-off-by: David Howells 
---
The following changes since commit 4d7127dace8cf4b05eb7c8c8531fc204fbb195f4:

  Merge branch 'for-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security 
(2012-10-13 11:29:00 +0900)

are available in the git repository at:


  git://git.infradead.org/users/dhowells/linux-headers.git 
tags/disintegrate-main-20121013

for you to fetch changes up to 5921e6f8809b1616932ca4afd40fe449faa8fd88:

  UAPI: (Scripted) Disintegrate include/linux/byteorder (2012-10-13 10:46:49 
+0100)


UAPI Disintegration 2012-10-13


David Howells (4):
  UAPI: Unexport part of linux/ppp-comp.h
  UAPI: Unexport linux/blk_types.h
  UAPI: (Scripted) Disintegrate include/linux
  UAPI: (Scripted) Disintegrate include/linux/byteorder

 include/linux/Kbuild  |  380 -
 include/linux/a.out.h |  196 +--
 include/linux/acct.h  |  108 +-
 include/linux/adb.h   |   39 +-
 include/linux/adfs_fs.h   |   42 +-
 include/linux/agpgart.h   |   86 +-
 include/linux/apm_bios.h  |  125 +-
 include/linux/atalk.h |   43 +-
 include/linux/atm.h   |  238 +--
 include/linux/atm_tcp.h   |   54 +-
 include/linux/atmdev.h|  213 +--
 include/linux/audit.h |  381 +
 include/linux/auto_fs.h   |   68 +-
 include/linux/auxvec.h|   33 +-
 include/linux/binfmts.h   |   19 +-
 include/linux/blktrace_api.h  |  142 +-
 include/linux/bsg.h   |   63 +-
 include/linux/byteorder/Kbuild|2 -
 include/linux/byteorder/big_endian.h  |  103 +-
 include/linux/byteorder/little_endian.h   |  103 +-
 include/linux/capability.h|  346 +
 include/linux/cciss_ioctl.h   |   86 +-
 include/linux/cdrom.h |  902 +--
 include/linux/cm4000_cs.h |   60 +-
 include/linux/cn_proc.h   |  103 +-
 include/linux/coda.h  |  680 +
 include/linux/coda_psdev.h|   26 +-
 include/linux/connector.h |   56 +-
 include/linux/cramfs_fs.h |   86 +-
 include/linux/cuda.h  |   25 +-
 include/linux/cyclades.h  |  426 +-
 include/linux/dccp.h  |  236 +--
 include/linux/dlm.h   |   62 +-
 include/linux/dlm_plock.h |   37 +-
 include/linux/edd.h   |  158 +-
 include/linux/elf.h   |  414 +
 include/linux/elfcore.h   |  102 +-
 include/linux/errno.h |5 +-
 include/linux/errqueue.h  

Re: [PATCH 1/2] uapi: update includes for drm content when no kernel API exists

[Laurent Pinchart]

Hi Luis,

On Friday 12 October 2012 16:49:31 Luis R. Rodriguez wrote:
> From: "Luis R. Rodriguez" 
> 
> The UAPI changes split kernel API and userspace API
> content onto two separate header files. The userspace
> API drm content was moved to include/uapi/drm/ with the
> same file name while kernel specific API content was
> kept under include/drm/ with the same file name. When
> one file was split into two files the kernel header
> includes the uapi header and a UAPI prefix was added to
> the uapi header for its header guard. When there was no
> kernel API content found the uapi header file was the
> only one that was kept and the original guard for the
> header file was kept. In this particular case the
> original users of this header file were not modified
> and the uapi header file is expected to be picked up
> by path.
> 
> This may work well at compilation on the kernel but when
> backporting this creates a few complexities.

Could you please provide more details about those complexities ?

> To help with
> backporting [0] lets be explicit about the new uapi path
> when there is no respective kernel API header file. For
> more details on the UAPI changes see the lwn article on
> this [1].
> 
> [0] https://backports.wiki.kernel.org
> [1] http://lwn.net/Articles/507794/
> 
> Cc: dri-de...@lists.freedesktop.org
> Cc: linux-kernel@vger.kernel.org
> Cc: de...@driverdev.osuosl.org
> Cc: backpo...@vger.kernel.org
> 
> Cc: Rob Clark 
> Cc: Arnd Bergmann 
> Cc: Dave Jones 
> Cc: David Airlie 
> Cc: Ben Skeggs 
> Cc: Alan Cox 
> Cc: David Howells 
> Cc: Thomas Gleixner 
> Cc: Daniel Vetter 
> Cc: Jesse Barnes 
> Cc: Alex Deucher 
> Cc: Paul E. McKenney 
> Cc: Greg Kroah-Hartman 
> Cc: Laurent Pinchart 
> Signed-off-by: Luis R. Rodriguez 

-- 
Regards,

Laurent Pinchart

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

[GIT PULL] Disintegrate UAPI for spi

[David Howells]

Hi Linus,

Can you merge my spi disintegration patch please?

This is to complete part of the Userspace API (UAPI) disintegration for which
the preparatory patches were pulled recently.  After these patches, userspace
headers will be segregated into:

include/uapi/linux/.../foo.h

for the userspace interface stuff, and:

include/linux/.../foo.h

for the strictly kernel internal stuff.

Signed-off-by: David Howells 
Acked-by: Grant Likely 
---
The following changes since commit 9e2d8656f5e8aa214e66b462680cf86b210b74a8:

  Merge branch 'akpm' (Andrew's patch-bomb) (2012-10-09 16:23:15 +0900)

are available in the git repository at:


  git://git.infradead.org/users/dhowells/linux-headers.git 
tags/disintegrate-spi-20121009

for you to fetch changes up to 7939d3c2a677b06cf111a1304710dd97892f3695:

  UAPI: (Scripted) Disintegrate include/linux/spi (2012-10-09 09:49:03 +0100)


UAPI Disintegration 2012-10-09


David Howells (1):
  UAPI: (Scripted) Disintegrate include/linux/spi

 include/linux/spi/Kbuild  | 1 -
 include/uapi/linux/spi/Kbuild | 1 +
 include/{ => uapi}/linux/spi/spidev.h | 0
 3 files changed, 1 insertion(+), 1 deletion(-)
 rename include/{ => uapi}/linux/spi/spidev.h (100%)
.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 00/25] asm-generic: Convert all to use Kbuild file

[Catalin Marinas]

Hi Steven,

On 13 October 2012 03:26, Steven Rostedt  wrote:
> Recently I suggested to someone that was adding a new asm file that
> currently only contained an x86 change to add a header in all archs
> that was just a wrapper to point to the asm-generic version. I suggested
> this because that's the way we use to do it and just to refresh my
> memory, I looked at div64.h in a few archs and saw that was the case.
>
> After having the change done and just after finishing testing it, I was
> notified that the "proper" way of doing this is to add it to the
>
>   arch/*/include/asm/Kbuild
>
> file, as 'generic-y += foo.h' and it will reference the asm-generic
> file automatically. Well it would have been nice if I knew this before
> and wasn't confused by seeing the incorrect method.

Since you are  cleaning this up already, could you please merge these
patches into your series:

https://lkml.org/lkml/2012/10/11/291

The first patch adds support for generic-y in the new
arch/*/include/uapi/asm/Kbuild file, followed by few patches to
convert three architectures. There will probably be more to convert
after -rc1.

Thanks.

-- 
Catalin
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 v3] usbdevfs: Fix broken scatter-gather transfer

[Henrik Rydberg]

The handling of large output bulk transfers is broken; the same user
page is read over and over again. Fixed with this patch.

Cc: sta...@kernel.org
Acked-by: Peter Stuge 
Acked-by: Hans de Goede 
Acked-by: Alan Stern 
Signed-off-by: Henrik Rydberg 
---
Hi Greg,

Here is the formal and third version of the patch. Version two still
made me nervous, so I moved the increment to where it is clear that
the buffer pointer is never referenced again later in the function. I
still kept the ACKS, hope that is alright with everyone.

Thanks,
Henrik

 drivers/usb/core/devio.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/usb/core/devio.c b/drivers/usb/core/devio.c
index ebb8a9d..7f75343 100644
--- a/drivers/usb/core/devio.c
+++ b/drivers/usb/core/devio.c
@@ -1348,6 +1348,7 @@ static int proc_do_submiturb(struct dev_state *ps, struct 
usbdevfs_urb *uurb,
ret = -EFAULT;
goto error;
}
+   uurb->buffer += u;
}
totlen -= u;
}
-- 
1.7.12.2

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] task_work: Add local_irq_enable() into task_work_run()

[Michael Cree]

On Sat 13 October 2012 14:09:36 Linus Torvalds wrote:
> On Sat, Oct 13, 2012 at 1:03 AM, Oleg Nesterov  wrote:
> > arch/alpha and probably some other architectures call
> > do_notify_resume()->task_work_run() with irqs disabled.
> 
> I'm going to ignore this patch because I *hope* it is unnecessary
> after the pull from Al that I just did.
> 
> But if that turns out to be not the case, please holler. Torsten, you
> seem to be the one who reported this, can you check the current git
> tree?

I thought I might step in and run some tests.  Current git compiled for SMP 
generic Alpha and running on a 3-CPU ES45.  I have just managed to compile and 
run the test of eglibc without any RCU CPU task lockups!!  This is the first 
time in a couple or so years that I have seen a build of eglibc complete under 
an SMP kernel built for generic Alpha.

So, Al, you have made my day!

Any chance that we could have the fixes backported to the stable queue, in 
particular to the 3,2 kernel?  We should then be able to run the Debian built 
SMP kernel on the autobuilders at Debian-Ports rather than having to run a 
specially built kernel or a UP kernel.

BTW, the WARNING: at kernel/softirq.c:139 __local_bh_enable+0xe8/0x110() still 
occurs when bringing up the CPUs.  Actually it happens twice now.  I've 
attached my dmesg dump should you wish to check.

Cheers
Michael.
[0.00] Initializing cgroup subsys cpuset
[0.00] Initializing cgroup subsys cpu
[0.00] Linux version 3.6.0-generic-10664-g4e21fc1 (mjc@electro) (gcc 
version 4.5.4 (Debian 4.5.4-1+alpha) ) #1 SMP Sat Oct 13 19:29:26 NZDT 2012
[0.00] Booting GENERIC on Titan variation Privateer using machine 
vector PRIVATEER from SRM
[0.00] Major Options: SMP VERBOSE_MCHECK MAGIC_SYSRQ 
[0.00] Command line: ro root=/dev/sdb3 console=ttyS0
[0.00] memcluster 0, usage 1, start0, end  630
[0.00] memcluster 1, usage 0, start  630, end   524279
[0.00] memcluster 2, usage 1, start   524279, end   524288
[0.00] freeing pages 630:2048
[0.00] freeing pages 3961:524279
[0.00] reserving pages 3961:3969
[0.00] SMP: 3 CPUs probed -- cpu_present_mask = 7
[0.00] On node 0 totalpages: 524279
[0.00] free_area_init_node: node 0, pgdat fc0001e7b100, 
node_mem_map fc0001f02000
[0.00]   DMA zone: 3584 pages used for memmap
[0.00]   DMA zone: 0 pages reserved
[0.00]   DMA zone: 520695 pages, LIFO batch:15
[0.00] PERCPU: Embedded 5 pages/cpu @fc0003b14000 s9216 r8192 
d23552 u40960
[0.00] pcpu-alloc: s9216 r8192 d23552 u40960 alloc=5*8192
[0.00] pcpu-alloc: [0] 0 [0] 1 [0] 2 
[0.00] Built 1 zonelists in Zone order, mobility grouping on.  Total 
pages: 520695
[0.00] Kernel command line: ro root=/dev/sdb3 console=ttyS0
[0.00] PID hash table entries: 4096 (order: 2, 32768 bytes)
[0.00] Dentry cache hash table entries: 524288 (order: 9, 4194304 bytes)
[0.00] Inode-cache hash table entries: 262144 (order: 8, 2097152 bytes)
[0.00] Memory: 4134648k/4194232k available (4616k kernel code, 54544k 
reserved, 8571k data, 400k init)
[0.00] SLUB: Genslabs=16, HWalign=64, Order=0-3, MinObjects=0, CPUs=3, 
Nodes=1
[0.00] Hierarchical RCU implementation.
[0.00]  RCU restricting CPUs from NR_CPUS=4 to nr_cpu_ids=3.
[0.00] NR_IRQS:32784
[0.00] Using epoch = 2000
[0.00] Console: colour dummy device 80x25
[0.00] console [ttyS0] enabled
[1.896483] Calibrating delay loop... 2492.28 BogoMIPS (lpj=1216512)
[1.980467] pid_max: default: 32768 minimum: 301
[2.035155] Mount-cache hash table entries: 512
[2.090819] Initializing cgroup subsys cpuacct
[2.145506] Initializing cgroup subsys devices
[2.198241] Initializing cgroup subsys freezer
[2.250975] SMP starting up secondaries.
[2.298826] Performance events: Supported CPU type!
[2.375975] Brought up 3 CPUs
[2.412108] SMP: Total of 3 processors activated (7471.73 BogoMIPS).
[2.488279] [ cut here ]
[2.488279] [ cut here ]
[2.488279] WARNING: at kernel/softirq.c:139 __local_bh_enable+0xe8/0x110()
[2.488279] Modules linked in:
[2.488279] fc00ff123b60 fc0001e597e8 fc0001041848 
0200 
[2.488279]fc0001e817e8 fc0001e7db85 0001 
0040 
[2.488279]fc00010426d8 fc0001edbaa0 fc0001645940 
fc000164c040 
[2.488279]fc000106ca00 fc0001eb0cc0 fc000101bd38 
0001 
[2.488279]0001  fc000101617c 
0001 
[2.488279]0001 fc00016348d8 0002 
fc00ff097bd0 
[2.488279] Trace:
[2.488279] [] __local_bh_enable+0xe8/0x110
[2.488279] [] irq_enter+0x68/0x90
[2.488279] [] 

[PATCH] UAPI: Unexport linux/blk_types.h [ver #2]

[David Howells]

It seems that was linux/blk_types.h incorrectly exported to fix up some missing
bits required by the exported parts of linux/fs.h (READ, WRITE, READA, etc.).

So unexport linux/blk_types.h and unexport the relevant bits of linux/fs.h.

Signed-off-by: David Howells 
cc: Jens Axboe 
cc: Tejun Heo 
cc: Al Viro 
---

 include/linux/Kbuild |1 
 include/linux/fs.h   |  119 +-
 2 files changed, 59 insertions(+), 61 deletions(-)

diff --git a/include/linux/Kbuild b/include/linux/Kbuild
index d114db9..e2a1346 100644
--- a/include/linux/Kbuild
+++ b/include/linux/Kbuild
@@ -69,7 +69,6 @@ header-y += b1lli.h
 header-y += baycom.h
 header-y += bfs_fs.h
 header-y += binfmts.h
-header-y += blk_types.h
 header-y += blkpg.h
 header-y += blktrace_api.h
 header-y += bpqether.h
diff --git a/include/linux/fs.h b/include/linux/fs.h
index 65fbf57..8cb86cf 100644
--- a/include/linux/fs.h
+++ b/include/linux/fs.h
@@ -8,7 +8,6 @@
 
 #include 
 #include 
-#include 
 #include 
 
 /*
@@ -118,65 +117,6 @@ struct inodes_stat_t {
 #define FMODE_NONOTIFY ((__force fmode_t)0x100)
 
 /*
- * The below are the various read and write types that we support. Some of
- * them include behavioral modifiers that send information down to the
- * block layer and IO scheduler. Terminology:
- *
- * The block layer uses device plugging to defer IO a little bit, in
- * the hope that we will see more IO very shortly. This increases
- * coalescing of adjacent IO and thus reduces the number of IOs we
- * have to send to the device. It also allows for better queuing,
- * if the IO isn't mergeable. If the caller is going to be waiting
- * for the IO, then he must ensure that the device is unplugged so
- * that the IO is dispatched to the driver.
- *
- * All IO is handled async in Linux. This is fine for background
- * writes, but for reads or writes that someone waits for completion
- * on, we want to notify the block layer and IO scheduler so that they
- * know about it. That allows them to make better scheduling
- * decisions. So when the below references 'sync' and 'async', it
- * is referencing this priority hint.
- *
- * With that in mind, the available types are:
- *
- * READA normal read operation. Device will be plugged.
- * READ_SYNC   A synchronous read. Device is not plugged, caller can
- * immediately wait on this read without caring about
- * unplugging.
- * READA   Used for read-ahead operations. Lower priority, and the
- * block layer could (in theory) choose to ignore this
- * request if it runs into resource problems.
- * WRITE   A normal async write. Device will be plugged.
- * WRITE_SYNC  Synchronous write. Identical to WRITE, but passes down
- * the hint that someone will be waiting on this IO
- * shortly. The write equivalent of READ_SYNC.
- * WRITE_ODIRECT   Special case write for O_DIRECT only.
- * WRITE_FLUSH Like WRITE_SYNC but with preceding cache flush.
- * WRITE_FUA   Like WRITE_SYNC but data is guaranteed to be on
- * non-volatile media on completion.
- * WRITE_FLUSH_FUA Combination of WRITE_FLUSH and FUA. The IO is preceded
- * by a cache flush and data is guaranteed to be on
- * non-volatile media on completion.
- *
- */
-#define RW_MASKREQ_WRITE
-#define RWA_MASK   REQ_RAHEAD
-
-#define READ   0
-#define WRITE  RW_MASK
-#define READA  RWA_MASK
-#define KERNEL_READ(READ|REQ_KERNEL)
-#define KERNEL_WRITE   (WRITE|REQ_KERNEL)
-
-#define READ_SYNC  (READ | REQ_SYNC)
-#define WRITE_SYNC (WRITE | REQ_SYNC | REQ_NOIDLE)
-#define WRITE_ODIRECT  (WRITE | REQ_SYNC)
-#define WRITE_FLUSH(WRITE | REQ_SYNC | REQ_NOIDLE | REQ_FLUSH)
-#define WRITE_FUA  (WRITE | REQ_SYNC | REQ_NOIDLE | REQ_FUA)
-#define WRITE_FLUSH_FUA(WRITE | REQ_SYNC | REQ_NOIDLE | 
REQ_FLUSH | REQ_FUA)
-
-
-/*
  * Flag for rw_copy_check_uvector and compat_rw_copy_check_uvector
  * that indicates that they should check the contents of the iovec are
  * valid, but not check the memory that the iovec elements
@@ -417,6 +357,7 @@ struct inodes_stat_t {
 #include 
 #include 
 #include 
+#include 
 
 #include 
 
@@ -454,6 +395,64 @@ typedef void (dio_iodone_t)(struct kiocb *iocb, loff_t 
offset,
bool is_async);
 
 /*
+ * The below are the various read and write types that we support. Some of
+ * them include behavioral modifiers that send information down to the
+ * block layer and IO scheduler. Terminology:
+ *
+ * The block layer uses device plugging to defer IO a little bit, in
+ * the hope that 

[PULL REQUEST] md updates for 3.7

[NeilBrown]

MD updates for 3.7.
Latish because I needed to wait for the block tree to get merged.

Thanks,
NeilBrown



The following changes since commit 02f3939e1a9357b7c370a4a69717cf9c02452737:

  block: makes bio_split support bio without data (2012-09-28 10:38:48 +0200)

are available in the git repository at:

  git://neil.brown.name/md/ tags/md-3.7

for you to fetch changes up to 72f36d5972a166197036c1281963f6863c429bf2:

  md: refine reporting of resync/reshape delays. (2012-10-11 14:25:57 +1100)


md updates for 3.7

"discard" support, some dm-raid improvements and other assorted
bits and pieces.


Alexander Lyakas (1):
  md: When RAID5 is dirty, force reconstruct-write instead of 
read-modify-write.

Dan Carpenter (1):
  md/raid10: use correct limit variable

Denis Efremov (1):
  md/linear: rcu_dereference outside read-lock section

Jan Beulich (1):
  add further __init annotations to crypto/xor.c

Jianpeng Ma (2):
  md/bitmap:Don't use IS_ERR to judge alloc_page().
  Subject: [PATCH] md:change resync_mismatches to atomic64_t to avoid races

Jonathan Brassow (5):
  MD RAID10: Prep for DM RAID10 device replacement capability
  DM RAID: Move 'rebuild' checking code to its own function
  DM RAID: Add rebuild capability for RAID10
  DM RAID: Fix comparison of index and quantity for "rebuild" parameter
  DM RAID: Fix for "sync" directive ineffectiveness

Michael Wang (1):
  raid: replace list_for_each_continue_rcu with new interface

NeilBrown (10):
  md/raid10: submit IO from originating thread instead of md thread.
  md: avoid taking the mutex on some ioctls.
  md/raid1: Don't release reference to device while handling read error.
  md/raid5: add some missing locking in handle_failed_stripe.
  md/raid5: protect debug message against NULL derefernce.
  md/raid5: make sure to_read and to_write never go negative.
  md: writing to sync_action should clear the read-auto state.
  md: make sure manual changes to recovery checkpoint are saved.
  md/raid5: be careful not to resize_stripes too big.
  md: refine reporting of resync/reshape delays.

Shaohua Li (7):
  md: linear supports TRIM
  md: raid 0 supports TRIM
  md: raid 1 supports TRIM
  md: raid 10 supports TRIM
  MD: change the parameter of md thread
  MD: raid5 trim support
  MD: raid5 avoid unnecessary zero page for trim

 Documentation/device-mapper/dm-raid.txt |   9 ++
 crypto/xor.c|   4 +-
 drivers/md/bitmap.c |  17 +--
 drivers/md/dm-raid.c| 124 ++
 drivers/md/linear.c |  25 +++-
 drivers/md/md.c | 145 +++--
 drivers/md/md.h |   9 +-
 drivers/md/multipath.c  |   3 +-
 drivers/md/raid0.c  |  19 ++-
 drivers/md/raid1.c  |  37 --
 drivers/md/raid10.c |  95 --
 drivers/md/raid5.c  | 219 
 drivers/md/raid5.h  |   1 +
 13 files changed, 578 insertions(+), 129 deletions(-)


signature.asc
Description: PGP signature

Re: [PATCH] mm: cleanup register_node()

[David Rientjes]

On Fri, 12 Oct 2012, Yasuaki Ishimatsu wrote:

> register_node() is defined as extern in include/linux/node.h. But the function
> is only called from register_one_node() in driver/base/node.c.
> 
> So the patch defines register_node() as static.
> 
> CC: David Rientjes 
> CC: Andrew Morton 
> Signed-off-by: Yasuaki Ishimatsu 

Acked-by: David Rientjes 

Thanks!
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [Q] Default SLAB allocator

[David Rientjes]

On Fri, 12 Oct 2012, Ezequiel Garcia wrote:

> >> SLUB is a non-starter for us and incurs a >10% performance degradation in
> >> netperf TCP_RR.
> >
> 
> Where are you seeing that?
> 

In my benchmarking results.

> Notice that many defconfigs are for embedded devices,
> and many of them say "use SLAB"; I wonder if that's right.
> 

If a device doesn't require the smallest memory footprint possible (SLOB) 
then SLAB is the right choice when there's a limited amount of memory; 
SLUB requires higher order pages for the best performance (on my desktop 
system running with CONFIG_SLUB, over 50% of the slab caches default to be 
high order).

> Is there any intention to replace SLAB by SLUB?

There may be an intent, but it'll be nacked as long as there's a 
performance degradation.

> In that case it could make sense to change defconfigs, although
> it wouldn't be based on any actual tests.
> 

Um, you can't just go changing defconfigs without doing some due diligence 
in ensuring it won't be deterimental for those users.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 07/12] staging/iio/lis3l02dq: fix building without irq_to_gpio

[Jonathan Cameron]

On 09/29/2012 04:03 PM, Arnd Bergmann wrote:
> On Saturday 29 September 2012, Jonathan Cameron wrote:
>> On 09/28/2012 10:36 PM, Arnd Bergmann wrote:
>>> The driver has not been building for some time after the
>>> irq_to_gpio function has been removed from the kernel.
>>>
>>> The only board in the upstream kernel that provides
>>> this device is the "Stargate 2", which is also maintained
>>> by Jonathan Cameron. Rather than working around the problem
>>> by adding new platform data for this driver, this patch
>>> uses the of_gpio framework to get to the gpio number.
>>>
>>> However, the stargate2 code does not (yet) use DT based
>>> probing, so it is still broken, but at least building
>>> allyesconfig works again.
>> Will be optimistic to think anyone will convert a platform
>> that no one still makes (stargate 2 was pretty much intel
>> research only + some they gave to accademics - imote2 has
>> been dropped by memsic for a while now.)  If nothing else
>> there is little chance anyone will bother porting a remotely
>> up to date bootloader to these boards given how few people
>> are still using them for anything.
> 
> The way are converting most ARM platforms to DT, we should be
> able to replace the board files with .dts files once all
> device drivers have been converted over. This is taking a
> bit longer for mmp/pxa than for some of the other platforms,
> Updating the boot loader makes it easier to deploy a DT
> version, but you can also append a DT blob to the kernel
> if that's not possible, and we will in the future allow
> appending multiple DT blobs and let the early boot stages
> pick the right one based on the board ID.
Sounds good.

> 
>> I'm happy enough with this patch.  Would prefer to
>> take it post merge window as a fix than now given timing.
> 
> Ok, fair enough. It has been broken for a while, so there
> is no hurry now. I just stumbled over it when doing an
> "allyesconfig" build.
Added to togreg branch of 
git://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio.git

> 
>> Long run this driver will hopefully get replaced by the
>> unified driver for all the st accelerometers (assuming that
>> ever gets back to this long obsolete part).
> 
> Ok.
> 
>   Arnd
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [Q] Default SLAB allocator

[David Rientjes]

On Thu, 11 Oct 2012, Andi Kleen wrote:

> When did you last test? Our regressions had disappeared a few kernels
> ago.
> 

This was in August when preparing for LinuxCon, I tested netperf TCP_RR on 
two 64GB machines (one client, one server), four nodes each, with thread 
counts in multiples of the number of cores.  SLUB does a comparable job, 
but once we have the the number of threads equal to three times the number 
of cores, it degrades almost linearly.  I'll run it again next week and 
get some numbers on 3.6.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

3.6.2 causes build errors again [was: master/i586/desktop: BUILD FAILED]

[Jiri Slaby]

Hi,

This one recurred :(.

Why was the dependency added by:
commit 24cc7fb69a5b5edfdff1d38c6a213d6a33648829
Author: Jeff Mahoney 
Date:   Thu Sep 20 10:28:45 2012 -0400

x86/kbuild: archscripts depends on scripts_basic

removed in this commit upstream:
commit fe04ddf7c2910362f3817c8156e41cbd6c0ee35d
Author: Michal Marek 
Date:   Tue Sep 25 16:03:03 2012 +0200

kbuild: Do not package /boot and /lib in make tar-pkg

??

(It came to us via 3.6.2 as 4bb50fa92f0).

 Original message 
PYedmt: [cvs build] master/i586/desktop: BUILD FAILED (798d597e)
Datum: Sat, 13 Oct 2012 10:15:03 +0200 (CEST)
Od: XXX
Komu: XXX
Kopie: jsl...@suse.cz

Full log: XXX

Recent changes:

commit 798d597ed7ecd9fc52366a177721c544dfb7edf9
Author: Jiri Slaby 
Date:   Sat Oct 13 00:30:32 2012 +0200

Linux 3.6.2.

Possible causes:
  HOSTCC  scripts/basic/fixdep
/bin/sh: scripts/basic/fixdep: Permission denied
make[3]: *** [arch/x86/tools/relocs] Error 1
make[2]: *** [archscripts] Error 2
make[2]: *** Waiting for unfinished jobs
make[2]: *** wait: No child processes.  Stop.
make[1]: *** [sub-make] Error 2
make: *** [all] Error 2

Last output:
++ HOST_EXTRACFLAGS='-include
/home/abuild/rpmbuild/SOURCES/host-memcpy-hack.h'
+ test -e
/home/abuild/rpmbuild/BUILD/kernel-desktop-3.6.2/kabi/i386/symtypes-desktop
+ true
+ make -j32 all CONFIG_DEBUG_SECTION_MISMATCH=y
+ tee buildlog
make[3]: Nothing to be done for `all'.
  HOSTCC  arch/x86/tools/relocs
  GEN
/home/abuild/rpmbuild/BUILD/kernel-desktop-3.6.2/linux-obj/Makefile
  CHK include/linux/version.h
  HOSTCC  scripts/basic/fixdep
/bin/sh: scripts/basic/fixdep: Permission denied
make[3]: *** [arch/x86/tools/relocs] Error 1
make[2]: *** [archscripts] Error 2
make[2]: *** Waiting for unfinished jobs
make[2]: *** wait: No child processes.  Stop.
make[1]: *** [sub-make] Error 2
make: *** [all] Error 2
+ test 2 -eq 0
+ test 00 -gt 0
+ exit 1
error: Bad exit status from /var/tmp/rpm-tmp.xSfzzB (%build)


RPM build errors:
Bad exit status from /var/tmp/rpm-tmp.xSfzzB (%build)

Re: [PATCH] linux/compiler.h: Add __must_hold macro for functions called with a lock held

[Sam Ravnborg]

On Tue, Oct 09, 2012 at 01:36:28PM -0700, Josh Triplett wrote:
> On Tue, Oct 09, 2012 at 01:06:37PM -0700, Andrew Morton wrote:
> > On Sun, 7 Oct 2012 19:06:10 -0700
> > Josh Triplett  wrote:
> > 
> > > linux/compiler.h has macros to denote functions that acquire or release
> > > locks, but not to denote functions called with a lock held that return
> > > with the lock still held.  Add a __must_hold macro to cover that case.
> > 
> > hum.  How does this work?  Any code examples and sample sparse output? 
> > Does it apply to all lock types, etc?
> 
> It applies to all the same lock types that __acquires and __releases
> apply to: currently everything since Sparse doesn't actually do anything
> with the parameter, just the context value.
> 
> Various code examples already exist in the kernel tree for __acquires
> and __releases, and the mailing list contains many reports of the Sparse
> context warnings.
> 
> Just as __acquires and __release annotate functions that return with a
> lock acquired and get called with a lock that they drop (respectively),
> __must_hold annotates a function called with a lock acquired that return
> with that lock still acquired.
> 
> > IOW, where is all this stuff documented?
> 
> The Sparse manpage documents the context bits reasonably well.  Other
> than that, nowhere that I know of other than the Sparse testsuite and
> the source trees of projects like Linux that use Sparse.

The kernel specific macros should be documented in:

Documentation/sparse.txt

For now only __bitwise is documentd, but when we introduce new
sparse annotation macros in the kernel the documentation should
be mandatory.

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

3.7.0-pre-rc1 INFO: inconsistent lock state kswapd0/792 [HC0[0]:SC0[0]:HE1:SE1] takes: (_vma->mutex){+.+.?.}, at: [] page_lock_anon_vma+0x12d/0x1a0

[Sander Eikelenboom]

On linux kernel 3.7.0-pre-rc1 (last commit = 
4d7127dace8cf4b05eb7c8c8531fc204fbb195f4)

I get:

[ 2954.552722]
[ 2954.563914] =
[ 2954.573011] [ INFO: inconsistent lock state ]
[ 2954.582002] 3.6.0pre-rc1-20121013 #1 Tainted: GW   
[ 2954.591174] -
[ 2954.600275] inconsistent {RECLAIM_FS-ON-W} -> {IN-RECLAIM_FS-W} usage.
[ 2954.609099] kswapd0/792 [HC0[0]:SC0[0]:HE1:SE1] takes:
[ 2954.617855]  (_vma->mutex){+.+.?.}, at: [] 
page_lock_anon_vma+0x12d/0x1a0
[ 2954.626841] {RECLAIM_FS-ON-W} state was registered at:
[ 2954.635560]   [] mark_held_locks+0xa4/0x130
[ 2954.644236]   [] lockdep_trace_alloc+0xe4/0x130
[ 2954.652867]   [] kmem_cache_alloc+0x33/0xd0
[ 2954.661416]   [] do_mmu_notifier_register+0x7f/0x160
[ 2954.669906]   [] mmu_notifier_register+0xe/0x10
[ 2954.678215]   [] gntdev_open+0xa3/0xe0
[ 2954.686432]   [] misc_open+0xb0/0x1a0
[ 2954.694523]   [] chrdev_open+0x98/0x170
[ 2954.702526]   [] do_dentry_open+0x25e/0x310
[ 2954.710471]   [] finish_open+0x30/0x50
[ 2954.718305]   [] do_last+0x30e/0xe90
[ 2954.725953]   [] path_openat+0xae/0x4e0
[ 2954.733444]   [] do_filp_open+0x44/0xa0
[ 2954.740911]   [] do_sys_open+0x103/0x1f0
[ 2954.748388]   [] sys_open+0x1c/0x20
[ 2954.755772]   [] system_call_fastpath+0x16/0x1b
[ 2954.763015] irq event stamp: 2815
[ 2954.770156] hardirqs last  enabled at (2815): [] 
mutex_trylock+0x15d/0x200
[ 2954.777538] hardirqs last disabled at (2814): [] 
mutex_trylock+0x67/0x200
[ 2954.784781] softirqs last  enabled at (0): [] 
copy_process+0x52a/0x14b0
[ 2954.792016] softirqs last disabled at (0): [<  (null)>]   
(null)
[ 2954.799237] 
[ 2954.799237] other info that might help us debug this:
[ 2954.813342]  Possible unsafe locking scenario:
[ 2954.813342] 
[ 2954.827364]CPU0
[ 2954.834223]
[ 2954.840907]   lock(_vma->mutex);
[ 2954.847630]   
[ 2954.854238] lock(_vma->mutex);
[ 2954.860924] 
[ 2954.860924]  *** DEADLOCK ***
[ 2954.860924] 
[ 2954.880533] no locks held by kswapd0/792.
[ 2954.887085] 
[ 2954.887085] stack backtrace:
[ 2954.900162] Pid: 792, comm: kswapd0 Tainted: GW
3.6.0pre-rc1-20121013 #1
[ 2954.906779] Call Trace:
[ 2954.913335]  [] print_usage_bug+0x244/0x2e0
[ 2954.919970]  [] mark_lock+0x60c/0x6a0
[ 2954.926503]  [] __lock_acquire+0x636/0xdd0
[ 2954.933108]  [] ? mark_held_locks+0xa4/0x130
[ 2954.939759]  [] lock_acquire+0xba/0x100
[ 2954.946193]  [] ? page_lock_anon_vma+0x12d/0x1a0
[ 2954.952383]  [] ? page_lock_anon_vma+0x12d/0x1a0
[ 2954.958260]  [] mutex_lock_nested+0x4c/0x450
[ 2954.963944]  [] ? page_lock_anon_vma+0x12d/0x1a0
[ 2954.969414]  [] ? trace_hardirqs_on_caller+0xf8/0x200
[ 2954.974640]  [] ? lock_release+0x117/0x250
[ 2954.979593]  [] page_lock_anon_vma+0x12d/0x1a0
[ 2954.984605]  [] ? page_mapped_in_vma+0xa0/0xa0
[ 2954.989597]  [] page_referenced+0x16b/0x2a0
[ 2954.994498]  [] ? _raw_spin_unlock_irq+0x2b/0x70
[ 2954.999459]  [] shrink_active_list+0x1bd/0x300
[ 2955.004413]  [] shrink_lruvec+0x484/0x640
[ 2955.009311]  [] ? zone_watermark_ok_safe+0xa4/0xc0
[ 2955.014236]  [] kswapd+0x854/0xda0
[ 2955.018987]  [] ? trace_hardirqs_on_caller+0xf8/0x200
[ 2955.023806]  [] ? wake_up_bit+0x40/0x40
[ 2955.028496]  [] ? _raw_spin_unlock_irqrestore+0x53/0xa0
[ 2955.033247]  [] ? zone_reclaim+0x420/0x420
[ 2955.037975]  [] kthread+0xd6/0xe0
[ 2955.042682]  [] ? __init_kthread_worker+0x70/0x70
[ 2955.047400]  [] ret_from_fork+0x7c/0xb0
[ 2955.052152]  [] ? __init_kthread_worker+0x70/0x70


--
Sander

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 v4 3/4] fat (exportfs): rebuild directory-inode if fat_dget() fails

[OGAWA Hirofumi]

Namjae Jeon  writes:

> + if (!fat_get_dotdot_entry(child_dir->d_inode, _bh, )) {
> + parent_logstart = fat_get_start(sbi, de);
>   parent_inode = fat_dget(sb, parent_logstart);
> + if (parent_inode || sbi->options.nfs != FAT_NFS_NOSTALE_RO)
> + goto out;
> + if (!parent_logstart)
> + /*logstart of dotdot entry is zero if
> + * if the directory's parent is root
> + */
> + parent_inode = sb->s_root->d_inode;

get_parent() should not be called for root dir, right?

> + blknr = fat_clus_to_blknr(sbi, parent_logstart);
> + parent_bh = sb_bread(sb, blknr);
> + if (!parent_bh) {
> + fat_msg(sb, KERN_ERR,
> + "NFS:unable to read cluster of parent 
> directory");
> + goto out;
> + }
> + de = (struct msdos_dir_entry *) parent_bh->b_data;
> + clus_to_match = fat_get_start(sbi, [0]);
> + search_clus = fat_get_start(sbi, [1]);
> + if (!search_clus)
> + search_clus = sbi->root_cluster;
> + brelse(parent_bh);
> + do {
> + parent_inode =  fat_traverse_cluster(sb,
> + search_clus, clus_to_match);
> + if (IS_ERR(parent_inode) || parent_inode)
> + break;
> + search_clus = fat_read_next_clus(sb,
> + search_clus);
> + if (search_clus < 0)
> + break;
> + } while (search_clus != FAT_ENT_EOF);
> + }

Please make this part as own function at least. And this is doing same
thing with readdir, so we will have to clean this up as I said before.
-- 
OGAWA Hirofumi 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 00/25] asm-generic: Convert all to use Kbuild file

[Arnd Bergmann]

On Friday 12 October 2012 22:26:32 Steven Rostedt wrote:
> 
> Please feel free to pluck these patches into your architecture and
> run them to make sure that they boot as well (I only had the compiler
> and not the box... Also I only tested with defconfig, I may have
> broken other configs).
> 
> One note, the best thing about these changes is:
> 
>  390 files changed, 369 insertions(+), 1378 deletions(-)

Thanks a lot for doing this! I had initially converted a bunch of
architectures to use the asm-generic files this way, but gave up
after some of them turned out to be too much work to get in.

Note that while you are addressing all the obvious candidates that
have only a single #include statement in them, there is room to take
this further because a lot of the other header files in architectures
are still identical to their asm-generic counterparts (aside from
whitespace and comments). I would recommend to arch maintainers that
have not already done so to go through all the headers and replace
the identical ones with generated headers that include the asm-generic
version.

Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 2/2] UAPI: Unexport linux/blk_types.h

[David Howells]

It seems that was linux/blk_types.h incorrectly exported to fix up some missing
bits required by the exported parts of linux/fs.h (READ, WRITE, READA, etc.).

So unexport linux/blk_types.h and unexport the relevant bits of linux/fs.h.

Signed-off-by: David Howells 
cc: Jens Axboe 
cc: Tejun Heo 
cc: Al Viro 
---

 include/linux/Kbuild |1 -
 include/linux/fs.h   |2 ++
 2 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/include/linux/Kbuild b/include/linux/Kbuild
index d114db9..e2a1346 100644
--- a/include/linux/Kbuild
+++ b/include/linux/Kbuild
@@ -69,7 +69,6 @@ header-y += b1lli.h
 header-y += baycom.h
 header-y += bfs_fs.h
 header-y += binfmts.h
-header-y += blk_types.h
 header-y += blkpg.h
 header-y += blktrace_api.h
 header-y += bpqether.h
diff --git a/include/linux/fs.h b/include/linux/fs.h
index 65fbf57..c83f45c 100644
--- a/include/linux/fs.h
+++ b/include/linux/fs.h
@@ -117,6 +117,7 @@ struct inodes_stat_t {
 /* File was opened by fanotify and shouldn't generate fanotify events */
 #define FMODE_NONOTIFY ((__force fmode_t)0x100)
 
+#ifdef __KERNEL__
 /*
  * The below are the various read and write types that we support. Some of
  * them include behavioral modifiers that send information down to the
@@ -175,6 +176,7 @@ struct inodes_stat_t {
 #define WRITE_FUA  (WRITE | REQ_SYNC | REQ_NOIDLE | REQ_FUA)
 #define WRITE_FLUSH_FUA(WRITE | REQ_SYNC | REQ_NOIDLE | 
REQ_FLUSH | REQ_FUA)
 
+#endif /* __KERNEL__ */
 
 /*
  * Flag for rw_copy_check_uvector and compat_rw_copy_check_uvector

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 1/2] UAPI: Unexport part of linux/ppp-comp.h

[David Howells]

Unexport part of linux/ppp-comp.h as userspace can't make use of that bit.

Signed-off-by: David Howells 
cc: Paul Mackerras 
cc: David Miller 
---

 include/linux/ppp-comp.h |4 
 1 file changed, 4 insertions(+)

diff --git a/include/linux/ppp-comp.h b/include/linux/ppp-comp.h
index e53ff65..b7dc06f 100644
--- a/include/linux/ppp-comp.h
+++ b/include/linux/ppp-comp.h
@@ -10,6 +10,8 @@
 #ifndef _NET_PPP_COMP_H
 #define _NET_PPP_COMP_H
 
+#ifdef __KERNEL__
+
 struct module;
 
 /*
@@ -98,6 +100,8 @@ struct compressor {
 #define DECOMP_ERROR   -1  /* error detected before decomp. */
 #define DECOMP_FATALERROR  -2  /* error detected after decomp. */
 
+#endif /* __KERNEL__ */
+
 /*
  * CCP codes.
  */

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