twitter: linux.kernel - 26 new messages in 16 topics

linux.kernel
http://groups.google.com/group/linux.kernel?hl=en

Today's topics:

* Avoid implicit constant truncation - 3 messages, 2 authors
http://groups.google.com/group/linux.kernel/t/f08faf5f72bd4f23?hl=en
* memcg: dirty pages instrumentation - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/98b8f3d66410be44?hl=en
* Driver core: add platform_create_bundle() helper - 3 messages, 1 author
http://groups.google.com/group/linux.kernel/t/63818dfc875730b2?hl=en
* [PATCH] memcg: fix oom kill behavior. - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/9862560a1b380dda?hl=en
* snet: introduce security/snet, Makefile and Kconfig changes - 2 messages, 2
authors
http://groups.google.com/group/linux.kernel/t/c533f45a163fc63a?hl=en
* tty: Add a new VT mode which is like VT_PROCESS but doesn't require a VT_
RELDISP ioctl call - 2 messages, 2 authors
http://groups.google.com/group/linux.kernel/t/08c1b2b68bc4f84b?hl=en
* arm: Convert arm to arch_gettimeoffset() - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/dce48281dc81f8d2?hl=en
* Remove large struct from stack in DVB dib3000mc and dib7000p drivers - 2
messages, 2 authors
http://groups.google.com/group/linux.kernel/t/9c8a796391f518e0?hl=en
* Remove large struct from the stack in USB storage isd200 driver - 1 messages,
1 author
http://groups.google.com/group/linux.kernel/t/3bcee93dc6da592a?hl=en
* powerpc: remove IOMMU_VMERGE config option - 2 messages, 2 authors
http://groups.google.com/group/linux.kernel/t/cddcca743420ebb4?hl=en
* Add sysfs support for fbdefio delay - 2 messages, 2 authors
http://groups.google.com/group/linux.kernel/t/fa05f291e1c0c50c?hl=en
* x86: Look for IA32_ENERGY_PERF_BIAS support - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/1228904558c05344?hl=en
* kprobes: Introduce generic insn_slot framework - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/e4e04919aba18b58?hl=en
* [Bug 15426] New: Running many copies of bonnie++ on different filesystems
seems to deadlock in sync - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/67b921549851f1a9?hl=en
* Support for IA32_ENERGY_PERF_BIAS MSR - 2 messages, 1 author
http://groups.google.com/group/linux.kernel/t/301c36cce92041f0?hl=en
* 2.6.33 bugs (USBFS, Intel graphic) - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/db2b4cba1e267316?hl=en

==============================================================================
TOPIC: Avoid implicit constant truncation
http://groups.google.com/group/linux.kernel/t/f08faf5f72bd4f23?hl=en
==============================================================================

== 1 of 3 ==
Date: Tues, Mar 2 2010 4:10 pm
From: imunsie@au1.ibm.com

From: Ian Munsie <imunsie@au.ibm.com>

When building on 64 bit platforms, the compiler throws the following
warning:

drivers/pci/probe.c:197: warning: large integer implicitly truncated to unsigned type

This patch adds an explicit truncation to silence the compiler warning.

Signed-off-by: Ian Munsie <imunsie@au.ibm.com>
---
drivers/pci/probe.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
index 2a94309..c5d9668 100644
--- a/drivers/pci/probe.c
+++ b/drivers/pci/probe.c
@@ -195,7 +195,7 @@ int __pci_read_base(struct pci_dev *dev, enum pci_bar_type type,
res->flags |= pci_calc_resource_flags(l) | IORESOURCE_SIZEALIGN;
if (type == pci_bar_io) {
l &= PCI_BASE_ADDRESS_IO_MASK;
- mask = PCI_BASE_ADDRESS_IO_MASK & IO_SPACE_LIMIT;
+ mask = (u32)(PCI_BASE_ADDRESS_IO_MASK & IO_SPACE_LIMIT);
} else {
l &= PCI_BASE_ADDRESS_MEM_MASK;
mask = (u32)PCI_BASE_ADDRESS_MEM_MASK;
--
1.6.6.1

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

== 2 of 3 ==
Date: Tues, Mar 2 2010 4:10 pm
From: Randy Dunlap

On 03/02/10 16:01, imunsie@au1.ibm.com wrote:
> From: Ian Munsie <imunsie@au.ibm.com>
>
> When building on 64 bit platforms, the compiler throws the following
> warning:
>
> drivers/pci/probe.c:197: warning: large integer implicitly truncated to unsigned type
>
> This patch adds an explicit truncation to silence the compiler warning.

Please see/read/use Documentation/SubmittingPatches. E.g.:

The canonical patch subject line is:

Subject: [PATCH 001/123] subsystem: summary phrase

I.e., the subject: should tell us that this is a PCI: patch.

(or even pci: -- i don't care which)

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

== 3 of 3 ==
Date: Tues, Mar 2 2010 4:20 pm
From: Ian Munsie

Randy Dunlap writes:

> The canonical patch subject line is:
>
> Subject: [PATCH 001/123] subsystem: summary phrase
>
> I.e., the subject: should tell us that this is a PCI: patch.
>
> (or even pci: -- i don't care which)

Appologies and thanks for the pointer - I'm new to this.

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

==============================================================================
TOPIC: memcg: dirty pages instrumentation
http://groups.google.com/group/linux.kernel/t/98b8f3d66410be44?hl=en
==============================================================================

== 1 of 1 ==
Date: Tues, Mar 2 2010 4:10 pm
From: Vivek Goyal

On Tue, Mar 02, 2010 at 11:22:48PM +0100, Andrea Righi wrote:
> On Tue, Mar 02, 2010 at 10:05:29AM -0500, Vivek Goyal wrote:
> > On Mon, Mar 01, 2010 at 11:18:31PM +0100, Andrea Righi wrote:
> > > On Mon, Mar 01, 2010 at 05:02:08PM -0500, Vivek Goyal wrote:
> > > > > @@ -686,10 +699,14 @@ void throttle_vm_writeout(gfp_t gfp_mask)
> > > > > */
> > > > > dirty_thresh += dirty_thresh / 10; /* wheeee... */
> > > > >
> > > > > - if (global_page_state(NR_UNSTABLE_NFS) +
> > > > > - global_page_state(NR_WRITEBACK) <= dirty_thresh)
> > > > > - break;
> > > > > - congestion_wait(BLK_RW_ASYNC, HZ/10);
> > > > > +
> > > > > + dirty = mem_cgroup_page_stat(MEMCG_NR_DIRTY_WRITEBACK_PAGES);
> > > > > + if (dirty < 0)
> > > > > + dirty = global_page_state(NR_UNSTABLE_NFS) +
> > > > > + global_page_state(NR_WRITEBACK);
> > > >
> > > > dirty is unsigned long. As mentioned last time, above will never be true?
> > > > In general these patches look ok to me. I will do some testing with these.
> > >
> > > Re-introduced the same bug. My bad. :(
> > >
> > > The value returned from mem_cgroup_page_stat() can be negative, i.e.
> > > when memory cgroup is disabled. We could simply use a long for dirty,
> > > the unit is in # of pages so s64 should be enough. Or cast dirty to long
> > > only for the check (see below).
> > >
> > > Thanks!
> > > -Andrea
> > >
> > > Signed-off-by: Andrea Righi <arighi@develer.com>
> > > ---
> > > mm/page-writeback.c | 2 +-
> > > 1 files changed, 1 insertions(+), 1 deletions(-)
> > >
> > > diff --git a/mm/page-writeback.c b/mm/page-writeback.c
> > > index d83f41c..dbee976 100644
> > > --- a/mm/page-writeback.c
> > > +++ b/mm/page-writeback.c
> > > @@ -701,7 +701,7 @@ void throttle_vm_writeout(gfp_t gfp_mask)
> > >
> > >
> > > dirty = mem_cgroup_page_stat(MEMCG_NR_DIRTY_WRITEBACK_PAGES);
> > > - if (dirty < 0)
> > > + if ((long)dirty < 0)
> >
> > This will also be problematic as on 32bit systems, your uppper limit of
> > dirty memory will be 2G?
> >
> > I guess, I will prefer one of the two.
> >
> > - return the error code from function and pass a pointer to store stats
> > in as function argument.
> >
> > - Or Peter's suggestion of checking mem_cgroup_has_dirty_limit() and if
> > per cgroup dirty control is enabled, then use per cgroup stats. In that
> > case you don't have to return negative values.
> >
> > Only tricky part will be careful accouting so that none of the stats go
> > negative in corner cases of migration etc.
>
> What do you think about Peter's suggestion + the locking stuff? (see the
> previous email). Otherwise, I'll choose the other solution, passing a
> pointer and always return the error code is not bad.
>

Ok, so you are worried about that by the we finish mem_cgroup_has_dirty_limit()
call, task might change cgroup and later we might call
mem_cgroup_get_page_stat() on a different cgroup altogether which might or
might not have dirty limits specified?

But in what cases you don't want to use memory cgroup specified limit? I
thought cgroup disabled what the only case where we need to use global
limits. Otherwise a memory cgroup will have either dirty_bytes specified
or by default inherit global dirty_ratio which is a valid number. If
that's the case then you don't have to take rcu_lock() outside
get_page_stat()?

IOW, apart from cgroup being disabled, what are the other cases where you
expect to not use cgroup's page stat and use global stats?

Thanks
Vivek

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

==============================================================================
TOPIC: Driver core: add platform_create_bundle() helper
http://groups.google.com/group/linux.kernel/t/63818dfc875730b2?hl=en
==============================================================================

== 1 of 3 ==
Date: Tues, Mar 2 2010 4:10 pm
From: Greg Kroah-Hartman

From: Dmitry Torokhov <dmitry.torokhov@gmail.com>

Many legacy-style module create singleton platform devices themselves,
along with corresponding platform driver. Instead of replicating error
handling code in all such drivers, provide a helper that allocates and
registers a single platform device and a driver and binds them together.

Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
drivers/base/platform.c | 58 +++++++++++++++++++++++++++++++++++++++
include/linux/platform_device.h | 5 +++
2 files changed, 63 insertions(+), 0 deletions(-)

diff --git a/drivers/base/platform.c b/drivers/base/platform.c
index 58efaf2..937d580 100644
--- a/drivers/base/platform.c
+++ b/drivers/base/platform.c
@@ -548,6 +548,64 @@ int __init_or_module platform_driver_probe(struct platform_driver *drv,
}
EXPORT_SYMBOL_GPL(platform_driver_probe);

+/**
+ * platform_create_bundle - register driver and create corresponding device
+ * @driver: platform driver structure
+ * @probe: the driver probe routine, probably from an __init section
+ * @res: set of resources that needs to be allocated for the device
+ * @n_res: number of resources
+ * @data: platform specific data for this platform device
+ * @size: size of platform specific data
+ *
+ * Use this in legacy-style modules that probe hardware directly and
+ * register a single platform device and corresponding platform driver.
+ */
+struct platform_device * __init_or_module platform_create_bundle(
+ struct platform_driver *driver,
+ int (*probe)(struct platform_device *),
+ struct resource *res, unsigned int n_res,
+ const void *data, size_t size)
+{
+ struct platform_device *pdev;
+ int error;
+
+ pdev = platform_device_alloc(driver->driver.name, -1);
+ if (!pdev) {
+ error = -ENOMEM;
+ goto err_out;
+ }
+
+ if (res) {
+ error = platform_device_add_resources(pdev, res, n_res);
+ if (error)
+ goto err_pdev_put;
+ }
+
+ if (data) {
+ error = platform_device_add_data(pdev, data, size);
+ if (error)
+ goto err_pdev_put;
+ }
+
+ error = platform_device_add(pdev);
+ if (error)
+ goto err_pdev_put;
+
+ error = platform_driver_probe(driver, probe);
+ if (error)
+ goto err_pdev_del;
+
+ return pdev;
+
+err_pdev_del:
+ platform_device_del(pdev);
+err_pdev_put:
+ platform_device_put(pdev);
+err_out:
+ return ERR_PTR(error);
+}
+EXPORT_SYMBOL_GPL(platform_create_bundle);
+
/* modalias support enables more hands-off userspace setup:
* (a) environment variable lets new-style hotplug events work once system is
* fully running: "modprobe $MODALIAS"
diff --git a/include/linux/platform_device.h b/include/linux/platform_device.h
index 71ff887..25e64b4 100644
--- a/include/linux/platform_device.h
+++ b/include/linux/platform_device.h
@@ -77,6 +77,11 @@ extern int platform_driver_probe(struct platform_driver *driver,
#define platform_get_drvdata(_dev) dev_get_drvdata(&(_dev)->dev)
#define platform_set_drvdata(_dev,data) dev_set_drvdata(&(_dev)->dev, (data))

+extern struct platform_device *platform_create_bundle(struct platform_driver *driver,
+ int (*probe)(struct platform_device *),
+ struct resource *res, unsigned int n_res,
+ const void *data, size_t size);
+
/* early platform driver interface */
struct early_platform_driver {
const char *class_str;
--
1.7.0.1

== 2 of 3 ==
Date: Tues, Mar 2 2010 4:10 pm
From: Greg Kroah-Hartman

From: Radu Voicilas <rvoicilas@gmail.com>

No change in functionality.

Signed-off-by: Radu Voicilas <rvoicilas@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
samples/kobject/kset-example.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/samples/kobject/kset-example.c b/samples/kobject/kset-example.c
index 45b7d56..7c60881 100644
--- a/samples/kobject/kset-example.c
+++ b/samples/kobject/kset-example.c
@@ -127,7 +127,7 @@ static struct foo_attribute foo_attribute =
__ATTR(foo, 0666, foo_show, foo_store);

/*
- * More complex function where we determine which varible is being accessed by
+ * More complex function where we determine which variable is being accessed by
* looking at the attribute for the "baz" and "bar" files.
*/
static ssize_t b_show(struct foo_obj *foo_obj, struct foo_attribute *attr,
@@ -161,7 +161,7 @@ static struct foo_attribute bar_attribute =
__ATTR(bar, 0666, b_show, b_store);

/*
- * Create a group of attributes so that we can create and destory them all
+ * Create a group of attributes so that we can create and destroy them all
* at once.
*/
static struct attribute *foo_default_attrs[] = {
--
1.7.0.1

== 3 of 3 ==
Date: Tues, Mar 2 2010 4:10 pm
From: Greg Kroah-Hartman

From: Eric Miao <eric.y.miao@gmail.com>

The platform ID table is normally const, force that by adding the attribute.

Signed-off-by: Eric Miao <eric.y.miao@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
include/linux/platform_device.h | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/include/linux/platform_device.h b/include/linux/platform_device.h
index 25e64b4..2c2d035 100644
--- a/include/linux/platform_device.h
+++ b/include/linux/platform_device.h
@@ -21,7 +21,7 @@ struct platform_device {
u32 num_resources;
struct resource * resource;

- struct platform_device_id *id_entry;
+ const struct platform_device_id *id_entry;

/* arch specific additions */
struct pdev_archdata archdata;
--
1.7.0.1

==============================================================================
TOPIC: [PATCH] memcg: fix oom kill behavior.
http://groups.google.com/group/linux.kernel/t/9862560a1b380dda?hl=en
==============================================================================

== 1 of 1 ==
Date: Tues, Mar 2 2010 4:10 pm
From: KAMEZAWA Hiroyuki

On Tue, 2 Mar 2010 22:41:42 +0530
Balbir Singh <balbir@linux.vnet.ibm.com> wrote:

> * KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> [2010-03-02 11:58:34]:
>
> > Brief Summary (for Andrew)
> >
> > - Nishimura reported my fix (one year ago)
> > a636b327f731143ccc544b966cfd8de6cb6d72c6
> > doesn't work well in some extreme situation.
> >
> > - David Rientjes said mem_cgroup_oom_called() is completely
> > ugly and broken and.....
> > And he tries to remove that in his patch set.
> >
> > Then, I wrote this as bugfix onto mmotm. This patch implements
> > - per-memcg OOM lock as per-zone OOM lock
> > - avoid to return -ENOMEM via mamcg's page fault path.
> > ENOMEM causes unnecessary page_fault_out_of_memory().
> > (Even if memcg hangs, there is no change from current behavior)
> > - in addtion to MEMDIE thread, KILLED proceses go bypath memcg.
> >
> > I'm glad if this goes into 2.6.34 timeline (as bugfix). But I'm
> > afraid this seems too big as bugfix...
> >
> > My plans for 2.6.35 are
> > - oom-notifier for memcg (based on memcg threshold notifier)
> > - oom-freezer (disable oom-kill) for memcg
> > - better handling in extreme situation.
> > And now, Andrea Righi works for dirty_ratio for memcg. We'll have
> > something better in 2.6.35 kernels.
> >
> > This patch will HUNK with David's set. Then, if this hunks in mmotm,
> > I'll rework.
> >
>
> Hi, Kamezawa-San,
>
> Some review comments below.
>
> > Tested on x86-64. Nishimura-san, could you test ?
> >
> > ==
> > From: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
> >
> > In current page-fault code,
> >
> > handle_mm_fault()
> > -> ...
> > -> mem_cgroup_charge()
> > -> map page or handle error.
> > -> check return code.
> >
> > If page fault's return code is VM_FAULT_OOM, page_fault_out_of_memory()
> > is called. But if it's caused by memcg, OOM should have been already
> > invoked.
> > Then, I added a patch: a636b327f731143ccc544b966cfd8de6cb6d72c6
> >
> > That patch records last_oom_jiffies for memcg's sub-hierarchy and
> > prevents page_fault_out_of_memory from being invoked in near future.
> >
> > But Nishimura-san reported that check by jiffies is not enough
> > when the system is terribly heavy.
> >
> > This patch changes memcg's oom logic as.
> > * If memcg causes OOM-kill, continue to retry.
> > * remove jiffies check which is used now.
>
> I like this very much!
>
> > * add memcg-oom-lock which works like perzone oom lock.
> > * If current is killed(as a process), bypass charge.
> >
> > Something more sophisticated can be added but this pactch does
> > fundamental things.
> > TODO:
> > - add oom notifier
> > - add permemcg disable-oom-kill flag and freezer at oom.
> > - more chances for wake up oom waiter (when changing memory limit etc..)
> >
> > Changelog;
> > - fixed per-memcg oom lock.
> >
> > Signed-off-by: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
> > ---
> > include/linux/memcontrol.h | 6 --
> > mm/memcontrol.c | 109 +++++++++++++++++++++++++++++++++------------
> > mm/oom_kill.c | 8 ---
> > 3 files changed, 82 insertions(+), 41 deletions(-)
> >
> > Index: mmotm-2.6.33-Feb11/include/linux/memcontrol.h
> > ===================================================================
> > --- mmotm-2.6.33-Feb11.orig/include/linux/memcontrol.h
> > +++ mmotm-2.6.33-Feb11/include/linux/memcontrol.h
> > @@ -124,7 +124,6 @@ static inline bool mem_cgroup_disabled(v
> > return false;
> > }
> >
> > -extern bool mem_cgroup_oom_called(struct task_struct *task);
> > void mem_cgroup_update_file_mapped(struct page *page, int val);
> > unsigned long mem_cgroup_soft_limit_reclaim(struct zone *zone, int order,
> > gfp_t gfp_mask, int nid,
> > @@ -258,11 +257,6 @@ static inline bool mem_cgroup_disabled(v
> > return true;
> > }
> >
> > -static inline bool mem_cgroup_oom_called(struct task_struct *task)
> > -{
> > - return false;
> > -}
> > -
> > static inline int
> > mem_cgroup_inactive_anon_is_low(struct mem_cgroup *memcg)
> > {
> > Index: mmotm-2.6.33-Feb11/mm/memcontrol.c
> > ===================================================================
> > --- mmotm-2.6.33-Feb11.orig/mm/memcontrol.c
> > +++ mmotm-2.6.33-Feb11/mm/memcontrol.c
> > @@ -200,7 +200,7 @@ struct mem_cgroup {
> > * Should the accounting and control be hierarchical, per subtree?
> > */
> > bool use_hierarchy;
> > - unsigned long last_oom_jiffies;
> > + atomic_t oom_lock;
> > atomic_t refcnt;
> >
> > unsigned int swappiness;
> > @@ -1234,32 +1234,77 @@ static int mem_cgroup_hierarchical_recla
> > return total;
> > }
> >
> > -bool mem_cgroup_oom_called(struct task_struct *task)
> > +static int mem_cgroup_oom_lock_cb(struct mem_cgroup *mem, void *data)
> > {
> > - bool ret = false;
> > - struct mem_cgroup *mem;
> > - struct mm_struct *mm;
> > + int *val = (int *)data;
> > + int x;
> >
> > - rcu_read_lock();
> > - mm = task->mm;
> > - if (!mm)
> > - mm = &init_mm;
> > - mem = mem_cgroup_from_task(rcu_dereference(mm->owner));
> > - if (mem && time_before(jiffies, mem->last_oom_jiffies + HZ/10))
> > - ret = true;
> > - rcu_read_unlock();
> > - return ret;
> > + x = atomic_inc_return(&mem->oom_lock);
> > + if (x > *val)
> > + *val = x;a
>
> Use the max_t function here?
> x = max_t(int, x, *val);
>
Sure.

> > + return 0;
> > +}
> > +/*
> > + * Check OOM-Killer is already running under our hierarchy.
> > + * If someone is running, return false.
> > + */
> > +static bool mem_cgroup_oom_lock(struct mem_cgroup *mem)
> > +{
> > + int check = 0;
> > +
> > + mem_cgroup_walk_tree(mem, &check, mem_cgroup_oom_lock_cb);
> > +
> > + if (check == 1)
> > + return true;
> > + return false;
> > }
> >
> > -static int record_last_oom_cb(struct mem_cgroup *mem, void *data)
> > +static int mem_cgroup_oom_unlock_cb(struct mem_cgroup *mem, void *data)
> > {
> > - mem->last_oom_jiffies = jiffies;
> > + atomic_dec(&mem->oom_lock);
> > return 0;
> > }
> >
> > -static void record_last_oom(struct mem_cgroup *mem)
> > +static void mem_cgroup_oom_unlock(struct mem_cgroup *mem)
> > {
> > - mem_cgroup_walk_tree(mem, NULL, record_last_oom_cb);
> > + mem_cgroup_walk_tree(mem, NULL, mem_cgroup_oom_unlock_cb);
> > +}
> > +
> > +static DEFINE_MUTEX(memcg_oom_mutex);
> > +static DECLARE_WAIT_QUEUE_HEAD(memcg_oom_waitq);
> > +
> > +/*
> > + * try to call OOM killer. returns false if we should exit memory-reclaim loop.
> > + */
> > +bool mem_cgroup_handle_oom(struct mem_cgroup *mem, gfp_t mask)
> > +{
> > + DEFINE_WAIT(wait);
> > + bool locked;
> > +
> > + prepare_to_wait(&memcg_oom_waitq, &wait, TASK_INTERRUPTIBLE);
> > + /* At first, try to OOM lock hierarchy under mem.*/
> > + mutex_lock(&memcg_oom_mutex);
> > + locked = mem_cgroup_oom_lock(mem);
> > + mutex_unlock(&memcg_oom_mutex);
> > +
> > + if (locked) {
> > + finish_wait(&memcg_oom_waitq, &wait);
> > + mem_cgroup_out_of_memory(mem, mask);
> > + } else {
> > + schedule();
> > + finish_wait(&memcg_oom_waitq, &wait);
> > + }
> > + mutex_lock(&memcg_oom_mutex);
> > + mem_cgroup_oom_unlock(mem);
> > + /* TODO: more fine grained waitq ? */
> > + wake_up_all(&memcg_oom_waitq);
>
> I was wondering if we should really wake up all? Shouldn't this be per
> memcg? The waitq that is, since the check is per memcg, the wakeup
> should also be per memcg.
>
The difficulty of per-memcg waitq is because of hierarchy.

Assume following hierarhcy A and its children 01 and 02.

A/ <==== under OOM #2
01 <==== under OOM #1
02

And the OOM happens in following sequence.
1. 01 goes to OOM (#1)
2. A goes to OOM (#2)

Because oom-kill in group 01 can fix both oom under A and 01,
oom-kill under A and oom-kill under 01 should be mutual exclusive.

When OOM under 01 wakes up, we have no way to wake up waiters on A.
That's the reason I used system-wide waitq.

I think there is no big problem. But I hope someone finds a new magic
for doing logically correct things. Then, I added a TODO.
I'll add some comments.

Thanks,
-Kame

==============================================================================
TOPIC: snet: introduce security/snet, Makefile and Kconfig changes
http://groups.google.com/group/linux.kernel/t/c533f45a163fc63a?hl=en
==============================================================================

== 1 of 2 ==
Date: Tues, Mar 2 2010 4:10 pm
From: Greg KH

On Tue, Mar 02, 2010 at 09:23:07PM +0100, Samir Bellabes wrote:
> this patch creates folder security/snet and adds changes for Kconfig and Makefile

But it breaks the build, as you are referring to files here that are not
present yet. Please put this at the end of your patch series to make
the tree always build for every individual patch.

thanks,

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

== 2 of 2 ==
Date: Tues, Mar 2 2010 4:30 pm
From: Samir Bellabes

Greg KH <greg@kroah.com> writes:

> On Tue, Mar 02, 2010 at 09:23:07PM +0100, Samir Bellabes wrote:
>> this patch creates folder security/snet and adds changes for Kconfig and Makefile
>
> But it breaks the build, as you are referring to files here that are not
> present yet. Please put this at the end of your patch series to make
> the tree always build for every individual patch.

yes, sure.
thank you Greg

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

==============================================================================
TOPIC: tty: Add a new VT mode which is like VT_PROCESS but doesn't require a
VT_RELDISP ioctl call
http://groups.google.com/group/linux.kernel/t/08c1b2b68bc4f84b?hl=en
==============================================================================

== 1 of 2 ==
Date: Tues, Mar 2 2010 4:10 pm
From: Greg KH

On Tue, Mar 02, 2010 at 06:55:20PM -0500, Ari Entlich wrote:
> Hello!
>
> Could you please remove this patch from your 2.6.34 tty pull request?
> Andrew Morton questioned whether this should actually be used yet[1],
> and I responded confirming his suspicions[2]. In addition, this patch
> has not "been in the linux-next and -mm releases for a number of
> weeks now", as you suggest in your pull request.

Hm, it's been there for over a week from what I can tell, right?

I'll revert it after this batch goes into Linus's tree. Next time, warn
me a bit earlier :)

thanks,

== 2 of 2 ==
Date: Tues, Mar 2 2010 4:20 pm
From: Ari Entlich

----- "Greg KH" <gregkh@suse.de> wrote:
> Hm, it's been there for over a week from what I can tell, right?

Hmm yes, I suppose it has.

> I'll revert it after this batch goes into Linus's tree. Next time, warn
> me a bit earlier :)

I apologize; I would have if I had realized that you picking it up meant it
was on its way to mainline.

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

==============================================================================
TOPIC: arm: Convert arm to arch_gettimeoffset()
http://groups.google.com/group/linux.kernel/t/dce48281dc81f8d2?hl=en
==============================================================================

== 1 of 1 ==
Date: Tues, Mar 2 2010 4:10 pm
From: Andrew Morton

On Mon, 01 Mar 2010 14:54:14 -0800
john stultz <johnstul@us.ibm.com> wrote:

> This patch converts arm to use GENERIC_TIME via the arch_getoffset()
> infrastructure, reducing the amount of arch specific code we need to
> maintain.

It runs afoul of the pending changes in linux-next:

patching file arch/arm/Kconfig
Hunk #3 FAILED at 240.
Hunk #4 FAILED at 250.
Hunk #5 FAILED at 262.
Hunk #6 succeeded at 293 (offset 21 lines).
Hunk #7 succeeded at 301 (offset 21 lines).
Hunk #8 succeeded at 310 (offset 21 lines).
Hunk #9 succeeded at 319 (offset 21 lines).
Hunk #10 succeeded at 336 (offset 21 lines).
Hunk #11 FAILED at 344.
Hunk #12 succeeded at 364 (offset 20 lines).
Hunk #13 succeeded at 375 (offset 20 lines).
Hunk #14 succeeded at 382 (offset 20 lines).
Hunk #15 succeeded at 393 (offset 20 lines).
Hunk #16 succeeded at 407 (offset 20 lines).
Hunk #17 succeeded at 419 (offset 20 lines).
Hunk #18 succeeded at 432 (offset 20 lines).
Hunk #19 succeeded at 441 (offset 20 lines).
Hunk #20 succeeded at 450 (offset 20 lines).
Hunk #21 succeeded at 459 (offset 20 lines).
Hunk #22 succeeded at 468 (offset 20 lines).
Hunk #23 succeeded at 484 (offset 20 lines).
Hunk #24 succeeded at 495 (offset 20 lines).
Hunk #25 succeeded at 504 (offset 20 lines).
Hunk #26 succeeded at 515 (offset 20 lines).
Hunk #27 succeeded at 528 (offset 20 lines).
Hunk #28 succeeded at 542 (offset 20 lines).
Hunk #29 succeeded at 553 (offset 20 lines).
Hunk #30 succeeded at 562 (offset 20 lines).
Hunk #31 succeeded at 577 (offset 20 lines).
Hunk #32 succeeded at 601 (offset 20 lines).
Hunk #33 succeeded at 614 (offset 20 lines).
Hunk #34 FAILED at 623.
Hunk #35 succeeded at 646 (offset 26 lines).
Hunk #36 succeeded at 660 (offset 26 lines).
Hunk #37 succeeded at 672 (offset 26 lines).
Hunk #38 FAILED at 682.
Hunk #39 succeeded at 743 (offset 66 lines).
Hunk #40 succeeded at 753 (offset 66 lines).
Hunk #41 succeeded at 767 (offset 66 lines).
Hunk #42 succeeded at 777 (offset 66 lines).
Hunk #43 succeeded at 795 (offset 66 lines).
Hunk #44 succeeded at 806 (offset 66 lines).
Hunk #45 succeeded at 815 (offset 66 lines).
Hunk #46 succeeded at 944 (offset 73 lines).
6 out of 46 hunks FAILED -- saving rejects to file arch/arm/Kconfig.rej
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

==============================================================================
TOPIC: Remove large struct from stack in DVB dib3000mc and dib7000p drivers
http://groups.google.com/group/linux.kernel/t/9c8a796391f518e0?hl=en
==============================================================================

== 1 of 2 ==
Date: Tues, Mar 2 2010 4:10 pm
From: imunsie@au1.ibm.com

From: Ian Munsie <imunsie@au.ibm.com>

Compiling these drivers results in the following compiler warnings on
PowerPC 64 bit:

drivers/media/dvb/frontends/dib3000mc.c:853: warning: the frame size of 2208 bytes is larger than 2048 bytes
drivers/media/dvb/frontends/dib7000p.c:1367: warning: the frame size of 2288 bytes is larger than 2048 bytes

The <driver>_i2c_enumeration functions use a large struct to hold the
state, which is stored on the stack.

This patch allocates that structure dynamically instead, thereby
conserving the driver's use of the stack.

There is now the possibility that these functions will return -ENOMEM in
case the dynamic memory allocation fails and while a useful message will
show up in dmesg, at the moment the -ENOMEM condition is not relayed
all the way back to userspace and it will receive an -ENODEV instead.
Is it worth pursuing returning the correct error all the way up to
userspace?

Signed-off-by: Ian Munsie <imunsie@au.ibm.com>
---
drivers/media/dvb/frontends/dib3000mc.c | 43 +++++++++++++++++++-----------
drivers/media/dvb/frontends/dib7000p.c | 44 +++++++++++++++++++-----------
2 files changed, 55 insertions(+), 32 deletions(-)

diff --git a/drivers/media/dvb/frontends/dib3000mc.c b/drivers/media/dvb/frontends/dib3000mc.c
index fa85160..78c2813 100644
--- a/drivers/media/dvb/frontends/dib3000mc.c
+++ b/drivers/media/dvb/frontends/dib3000mc.c
@@ -13,6 +13,7 @@

#include <linux/kernel.h>
#include <linux/i2c.h>
+#include <linux/slab.h>

#include "dvb_frontend.h"

@@ -813,43 +814,53 @@ EXPORT_SYMBOL(dib3000mc_set_config);

int dib3000mc_i2c_enumeration(struct i2c_adapter *i2c, int no_of_demods, u8 default_addr, struct dib3000mc_config cfg[])
{
- struct dib3000mc_state st = { .i2c_adap = i2c };
+ struct dib3000mc_state *st;
int k;
u8 new_addr;
-
static u8 DIB3000MC_I2C_ADDRESS[] = {20,22,24,26};
+ int ret = 0;
+
+ st = kzalloc(sizeof(struct dib3000mc_state), GFP_KERNEL);
+ if (!st) {
+ dprintk(KERN_ERR "Out of memory allocating dib3000mc_state in %s", __func__);
+ return -ENOMEM;
+ }
+ st->i2c_adap = i2c;

for (k = no_of_demods-1; k >= 0; k--) {
- st.cfg = &cfg[k];
+ st->cfg = &cfg[k];

/* designated i2c address */
new_addr = DIB3000MC_I2C_ADDRESS[k];
- st.i2c_addr = new_addr;
- if (dib3000mc_identify(&st) != 0) {
- st.i2c_addr = default_addr;
- if (dib3000mc_identify(&st) != 0) {
+ st->i2c_addr = new_addr;
+ if (dib3000mc_identify(st) != 0) {
+ st->i2c_addr = default_addr;
+ if (dib3000mc_identify(st) != 0) {
dprintk("-E- DiB3000P/MC #%d: not identified\n", k);
- return -ENODEV;
+ ret = -ENODEV;
+ goto out;
}
}

- dib3000mc_set_output_mode(&st, OUTMODE_MPEG2_PAR_CONT_CLK);
+ dib3000mc_set_output_mode(st, OUTMODE_MPEG2_PAR_CONT_CLK);

// set new i2c address and force divstr (Bit 1) to value 0 (Bit 0)
- dib3000mc_write_word(&st, 1024, (new_addr << 3) | 0x1);
- st.i2c_addr = new_addr;
+ dib3000mc_write_word(st, 1024, (new_addr << 3) | 0x1);
+ st->i2c_addr = new_addr;
}

for (k = 0; k < no_of_demods; k++) {
- st.cfg = &cfg[k];
- st.i2c_addr = DIB3000MC_I2C_ADDRESS[k];
+ st->cfg = &cfg[k];
+ st->i2c_addr = DIB3000MC_I2C_ADDRESS[k];

- dib3000mc_write_word(&st, 1024, st.i2c_addr << 3);
+ dib3000mc_write_word(st, 1024, st->i2c_addr << 3);

/* turn off data output */
- dib3000mc_set_output_mode(&st, OUTMODE_HIGH_Z);
+ dib3000mc_set_output_mode(st, OUTMODE_HIGH_Z);
}
- return 0;
+out:
+ kfree(st);
+ return ret;
}
EXPORT_SYMBOL(dib3000mc_i2c_enumeration);

diff --git a/drivers/media/dvb/frontends/dib7000p.c b/drivers/media/dvb/frontends/dib7000p.c
index 750ae61..08d47f2 100644
--- a/drivers/media/dvb/frontends/dib7000p.c
+++ b/drivers/media/dvb/frontends/dib7000p.c
@@ -9,6 +9,7 @@
*/
#include <linux/kernel.h>
#include <linux/i2c.h>
+#include <linux/slab.h>

#include "dvb_math.h"
#include "dvb_frontend.h"
@@ -1323,47 +1324,58 @@ EXPORT_SYMBOL(dib7000p_pid_filter);

int dib7000p_i2c_enumeration(struct i2c_adapter *i2c, int no_of_demods, u8 default_addr, struct dib7000p_config cfg[])
{
- struct dib7000p_state st = { .i2c_adap = i2c };
+ struct dib7000p_state *st;
int k = 0;
u8 new_addr = 0;
+ int ret = 0;
+
+ st = kzalloc(sizeof(struct dib7000p_state), GFP_KERNEL);
+ if (!st) {
+ dprintk(KERN_ERR "Out of memory allocating dib7000p_state in %s", __func__);
+ return -ENOMEM;
+ }
+ st->i2c_adap = i2c;

for (k = no_of_demods-1; k >= 0; k--) {
- st.cfg = cfg[k];
+ st->cfg = cfg[k];

/* designated i2c address */
new_addr = (0x40 + k) << 1;
- st.i2c_addr = new_addr;
- dib7000p_write_word(&st, 1287, 0x0003); /* sram lead in, rdy */
- if (dib7000p_identify(&st) != 0) {
- st.i2c_addr = default_addr;
- dib7000p_write_word(&st, 1287, 0x0003); /* sram lead in, rdy */
- if (dib7000p_identify(&st) != 0) {
+ st->i2c_addr = new_addr;
+ dib7000p_write_word(st, 1287, 0x0003); /* sram lead in, rdy */
+ if (dib7000p_identify(st) != 0) {
+ st->i2c_addr = default_addr;
+ dib7000p_write_word(st, 1287, 0x0003); /* sram lead in, rdy */
+ if (dib7000p_identify(st) != 0) {
dprintk("DiB7000P #%d: not identified\n", k);
- return -EIO;
+ ret = -EIO;
+ goto out;
}
}

/* start diversity to pull_down div_str - just for i2c-enumeration */
- dib7000p_set_output_mode(&st, OUTMODE_DIVERSITY);
+ dib7000p_set_output_mode(st, OUTMODE_DIVERSITY);

/* set new i2c address and force divstart */
- dib7000p_write_word(&st, 1285, (new_addr << 2) | 0x2);
+ dib7000p_write_word(st, 1285, (new_addr << 2) | 0x2);

dprintk("IC %d initialized (to i2c_address 0x%x)", k, new_addr);
}

for (k = 0; k < no_of_demods; k++) {
- st.cfg = cfg[k];
- st.i2c_addr = (0x40 + k) << 1;
+ st->cfg = cfg[k];
+ st->i2c_addr = (0x40 + k) << 1;

// unforce divstr
- dib7000p_write_word(&st, 1285, st.i2c_addr << 2);
+ dib7000p_write_word(st, 1285, st->i2c_addr << 2);

/* deactivate div - it was just for i2c-enumeration */
- dib7000p_set_output_mode(&st, OUTMODE_HIGH_Z);
+ dib7000p_set_output_mode(st, OUTMODE_HIGH_Z);
}

- return 0;
+out:
+ kfree(st);
+ return ret;
}
EXPORT_SYMBOL(dib7000p_i2c_enumeration);

--
1.6.6.1

== 2 of 2 ==
Date: Tues, Mar 2 2010 4:20 pm
From: Randy Dunlap

On 03/02/10 16:00, imunsie@au1.ibm.com wrote:
> From: Ian Munsie <imunsie@au.ibm.com>
>
> Compiling these drivers results in the following compiler warnings on
> PowerPC 64 bit:
>
> drivers/media/dvb/frontends/dib3000mc.c:853: warning: the frame size of 2208 bytes is larger than 2048 bytes
> drivers/media/dvb/frontends/dib7000p.c:1367: warning: the frame size of 2288 bytes is larger than 2048 bytes
>
> The <driver>_i2c_enumeration functions use a large struct to hold the
> state, which is stored on the stack.
>
> This patch allocates that structure dynamically instead, thereby
> conserving the driver's use of the stack.

Is this the same as the already-submitted patches?

Please see http://patchwork.kernel.org/patch/77892/
and http://patchwork.kernel.org/patch/77891/

and in general, use http://patchwork.kernel.org/ and
http://patchwork.ozlabs.org/ and/or mailing lists to see if patches
have already been submitted so that you don't waste time.
Or you could comments on my patches. ;)

> There is now the possibility that these functions will return -ENOMEM in
> case the dynamic memory allocation fails and while a useful message will
> show up in dmesg, at the moment the -ENOMEM condition is not relayed
> all the way back to userspace and it will receive an -ENODEV instead.
> Is it worth pursuing returning the correct error all the way up to
> userspace?
>
> Signed-off-by: Ian Munsie <imunsie@au.ibm.com>
> ---
> drivers/media/dvb/frontends/dib3000mc.c | 43 +++++++++++++++++++-----------
> drivers/media/dvb/frontends/dib7000p.c | 44 +++++++++++++++++++-----------
> 2 files changed, 55 insertions(+), 32 deletions(-)
>
> diff --git a/drivers/media/dvb/frontends/dib3000mc.c b/drivers/media/dvb/frontends/dib3000mc.c
> index fa85160..78c2813 100644
> --- a/drivers/media/dvb/frontends/dib3000mc.c
> +++ b/drivers/media/dvb/frontends/dib3000mc.c
> @@ -13,6 +13,7 @@
>
> #include <linux/kernel.h>
> #include <linux/i2c.h>
> +#include <linux/slab.h>
>
> #include "dvb_frontend.h"
>
> @@ -813,43 +814,53 @@ EXPORT_SYMBOL(dib3000mc_set_config);
>
> int dib3000mc_i2c_enumeration(struct i2c_adapter *i2c, int no_of_demods, u8 default_addr, struct dib3000mc_config cfg[])
> {
> - struct dib3000mc_state st = { .i2c_adap = i2c };
> + struct dib3000mc_state *st;
> int k;
> u8 new_addr;
> -
> static u8 DIB3000MC_I2C_ADDRESS[] = {20,22,24,26};
> + int ret = 0;
> +
> + st = kzalloc(sizeof(struct dib3000mc_state), GFP_KERNEL);
> + if (!st) {
> + dprintk(KERN_ERR "Out of memory allocating dib3000mc_state in %s", __func__);
> + return -ENOMEM;
> + }
> + st->i2c_adap = i2c;
>
> for (k = no_of_demods-1; k >= 0; k--) {
> - st.cfg = &cfg[k];
> + st->cfg = &cfg[k];
>
> /* designated i2c address */
> new_addr = DIB3000MC_I2C_ADDRESS[k];
> - st.i2c_addr = new_addr;
> - if (dib3000mc_identify(&st) != 0) {
> - st.i2c_addr = default_addr;
> - if (dib3000mc_identify(&st) != 0) {
> + st->i2c_addr = new_addr;
> + if (dib3000mc_identify(st) != 0) {
> + st->i2c_addr = default_addr;
> + if (dib3000mc_identify(st) != 0) {
> dprintk("-E- DiB3000P/MC #%d: not identified\n", k);
> - return -ENODEV;
> + ret = -ENODEV;
> + goto out;
> }
> }
>
> - dib3000mc_set_output_mode(&st, OUTMODE_MPEG2_PAR_CONT_CLK);
> + dib3000mc_set_output_mode(st, OUTMODE_MPEG2_PAR_CONT_CLK);
>
> // set new i2c address and force divstr (Bit 1) to value 0 (Bit 0)
> - dib3000mc_write_word(&st, 1024, (new_addr << 3) | 0x1);
> - st.i2c_addr = new_addr;
> + dib3000mc_write_word(st, 1024, (new_addr << 3) | 0x1);
> + st->i2c_addr = new_addr;
> }
>
> for (k = 0; k < no_of_demods; k++) {
> - st.cfg = &cfg[k];
> - st.i2c_addr = DIB3000MC_I2C_ADDRESS[k];
> + st->cfg = &cfg[k];
> + st->i2c_addr = DIB3000MC_I2C_ADDRESS[k];
>
> - dib3000mc_write_word(&st, 1024, st.i2c_addr << 3);
> + dib3000mc_write_word(st, 1024, st->i2c_addr << 3);
>
> /* turn off data output */
> - dib3000mc_set_output_mode(&st, OUTMODE_HIGH_Z);
> + dib3000mc_set_output_mode(st, OUTMODE_HIGH_Z);
> }
> - return 0;
> +out:
> + kfree(st);
> + return ret;
> }
> EXPORT_SYMBOL(dib3000mc_i2c_enumeration);
>
> diff --git a/drivers/media/dvb/frontends/dib7000p.c b/drivers/media/dvb/frontends/dib7000p.c
> index 750ae61..08d47f2 100644
> --- a/drivers/media/dvb/frontends/dib7000p.c
> +++ b/drivers/media/dvb/frontends/dib7000p.c
> @@ -9,6 +9,7 @@
> */
> #include <linux/kernel.h>
> #include <linux/i2c.h>
> +#include <linux/slab.h>
>
> #include "dvb_math.h"
> #include "dvb_frontend.h"
> @@ -1323,47 +1324,58 @@ EXPORT_SYMBOL(dib7000p_pid_filter);
>
> int dib7000p_i2c_enumeration(struct i2c_adapter *i2c, int no_of_demods, u8 default_addr, struct dib7000p_config cfg[])
> {
> - struct dib7000p_state st = { .i2c_adap = i2c };
> + struct dib7000p_state *st;
> int k = 0;
> u8 new_addr = 0;
> + int ret = 0;
> +
> + st = kzalloc(sizeof(struct dib7000p_state), GFP_KERNEL);
> + if (!st) {
> + dprintk(KERN_ERR "Out of memory allocating dib7000p_state in %s", __func__);
> + return -ENOMEM;
> + }
> + st->i2c_adap = i2c;
>
> for (k = no_of_demods-1; k >= 0; k--) {
> - st.cfg = cfg[k];
> + st->cfg = cfg[k];
>
> /* designated i2c address */
> new_addr = (0x40 + k) << 1;
> - st.i2c_addr = new_addr;
> - dib7000p_write_word(&st, 1287, 0x0003); /* sram lead in, rdy */
> - if (dib7000p_identify(&st) != 0) {
> - st.i2c_addr = default_addr;
> - dib7000p_write_word(&st, 1287, 0x0003); /* sram lead in, rdy */
> - if (dib7000p_identify(&st) != 0) {
> + st->i2c_addr = new_addr;
> + dib7000p_write_word(st, 1287, 0x0003); /* sram lead in, rdy */
> + if (dib7000p_identify(st) != 0) {
> + st->i2c_addr = default_addr;
> + dib7000p_write_word(st, 1287, 0x0003); /* sram lead in, rdy */
> + if (dib7000p_identify(st) != 0) {
> dprintk("DiB7000P #%d: not identified\n", k);
> - return -EIO;
> + ret = -EIO;
> + goto out;
> }
> }
>
> /* start diversity to pull_down div_str - just for i2c-enumeration */
> - dib7000p_set_output_mode(&st, OUTMODE_DIVERSITY);
> + dib7000p_set_output_mode(st, OUTMODE_DIVERSITY);
>
> /* set new i2c address and force divstart */
> - dib7000p_write_word(&st, 1285, (new_addr << 2) | 0x2);
> + dib7000p_write_word(st, 1285, (new_addr << 2) | 0x2);
>
> dprintk("IC %d initialized (to i2c_address 0x%x)", k, new_addr);
> }
>
> for (k = 0; k < no_of_demods; k++) {
> - st.cfg = cfg[k];
> - st.i2c_addr = (0x40 + k) << 1;
> + st->cfg = cfg[k];
> + st->i2c_addr = (0x40 + k) << 1;
>
> // unforce divstr
> - dib7000p_write_word(&st, 1285, st.i2c_addr << 2);
> + dib7000p_write_word(st, 1285, st->i2c_addr << 2);
>
> /* deactivate div - it was just for i2c-enumeration */
> - dib7000p_set_output_mode(&st, OUTMODE_HIGH_Z);
> + dib7000p_set_output_mode(st, OUTMODE_HIGH_Z);
> }
>
> - return 0;
> +out:
> + kfree(st);
> + return ret;
> }
> EXPORT_SYMBOL(dib7000p_i2c_enumeration);
>

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

==============================================================================
TOPIC: Remove large struct from the stack in USB storage isd200 driver
http://groups.google.com/group/linux.kernel/t/3bcee93dc6da592a?hl=en
==============================================================================

== 1 of 1 ==
Date: Tues, Mar 2 2010 4:10 pm
From: imunsie@au1.ibm.com

From: Ian Munsie <imunsie@au.ibm.com>

The compiler throws the following warning when compiling for a PowerPC 64
bit machine:

drivers/usb/storage/isd200.c:580: warning: the frame size of 2208 bytes is larger than 2048 bytes

There is a struct scsi_device which is placed on the stack and is
largely responsible for such wastage. The struct is just a dummy struct
filled with NULLs and set as the scsi_cmnd->device to make the
usb_stor_Bulk_transport function happy.

This patch makes the struct static, so that it is never placed onto the
stack and silences the compiler warning.

Signed-off-by: Ian Munsie <imunsie@au.ibm.com>
---
drivers/usb/storage/isd200.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/storage/isd200.c b/drivers/usb/storage/isd200.c
index fdba2f6..e9cbc14 100644
--- a/drivers/usb/storage/isd200.c
+++ b/drivers/usb/storage/isd200.c
@@ -490,13 +490,13 @@ static int isd200_action( struct us_data *us, int action,
void* pointer, int value )
{
union ata_cdb ata;
- struct scsi_device srb_dev;
+ /* static to prevent this large struct being placed on the valuable stack */
+ static struct scsi_device srb_dev;
struct isd200_info *info = (struct isd200_info *)us->extra;
struct scsi_cmnd *srb = &info->srb;
int status;

memset(&ata, 0, sizeof(ata));
- memset(&srb_dev, 0, sizeof(srb_dev));
srb->cmnd = info->cmnd;
srb->device = &srb_dev;
++srb->serial_number;
--
1.6.6.1

==============================================================================
TOPIC: powerpc: remove IOMMU_VMERGE config option
http://groups.google.com/group/linux.kernel/t/cddcca743420ebb4?hl=en
==============================================================================

== 1 of 2 ==
Date: Tues, Mar 2 2010 4:20 pm
From: Michael Ellerman

On Wed, 2010-03-03 at 08:54 +0900, FUJITA Tomonori wrote:
> Seems that IOMMU_VMERGE option description gives the false
> information:
>
> http://marc.info/?l=linux-sparc&m=126753808727669&w=2
> http://marc.info/?l=linux-sparc&m=126753880528825&w=2
>
> IOMMU_VMERGE is unnecessary nowadays so how about removing it?

Except you didn't remove it, you just made it uneditable? Why not get
rid of it entirely.

cheers

> diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
> index 155d571..2dfa83b 100644
> --- a/arch/powerpc/Kconfig
> +++ b/arch/powerpc/Kconfig
> @@ -314,17 +314,8 @@ config 8XX_MINIMAL_FPEMU
> It is recommended that you build a soft-float userspace instead.
>
> config IOMMU_VMERGE
> - bool "Enable IOMMU virtual merging"
> + def_bool y
> depends on PPC64
> - default y
> - help
> - Cause IO segments sent to a device for DMA to be merged virtually
> - by the IOMMU when they happen to have been allocated contiguously.
> - This doesn't add pressure to the IOMMU allocator. However, some
> - drivers don't support getting large merged segments coming back
> - from *_map_sg().
> -
> - Most drivers don't have this problem; it is safe to say Y here.
>
> config IOMMU_HELPER
> def_bool PPC64

== 2 of 2 ==
Date: Tues, Mar 2 2010 4:30 pm
From: FUJITA Tomonori

On Wed, 03 Mar 2010 11:13:52 +1100
Michael Ellerman <michael@ellerman.id.au> wrote:

> On Wed, 2010-03-03 at 08:54 +0900, FUJITA Tomonori wrote:
> > Seems that IOMMU_VMERGE option description gives the false
> > information:
> >
> > http://marc.info/?l=linux-sparc&m=126753808727669&w=2
> > http://marc.info/?l=linux-sparc&m=126753880528825&w=2
> >
> > IOMMU_VMERGE is unnecessary nowadays so how about removing it?
>
> Except you didn't remove it, you just made it uneditable? Why not get
> rid of it entirely.

Oops, yeah, I should have. Here's the second version.

Thanks,

=
From: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
Subject: [PATCH] powerpc: remove IOMMU_VMERGE config option

The description says:

Cause IO segments sent to a device for DMA to be merged virtually
by the IOMMU when they happen to have been allocated contiguously.
This doesn't add pressure to the IOMMU allocator. However, some
drivers don't support getting large merged segments coming back
from *_map_sg().

Most drivers don't have this problem; it is safe to say Y here.

It's out of date. Long ago, drivers didn't have a way to tell IOMMUs
about their segment length limit (that is, the maximum segment length
that they can handle). So IOMMUs merged as many segments as possible
and gave too large segments to drivers.

dma_get_max_seg_size() was introduced to solve the above
problem. Device drives can use the API to tell IOMMU about the maximum
segment length that they can handle. In addition, the default limit
(64K) should be safe for everyone.

So this config option seems to be unnecessary.

Note that this config option just enables users to disable the virtual
merging by default. Users can still disable the virtual merging by the
boot parameter.

Signed-off-by: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
---
arch/powerpc/Kconfig | 13 -------------
arch/powerpc/kernel/iommu.c | 7 +------
2 files changed, 1 insertions(+), 19 deletions(-)

diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 155d571..c984bc5 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -313,19 +313,6 @@ config 8XX_MINIMAL_FPEMU

It is recommended that you build a soft-float userspace instead.

-config IOMMU_VMERGE
- bool "Enable IOMMU virtual merging"
- depends on PPC64
- default y
- help
- Cause IO segments sent to a device for DMA to be merged virtually
- by the IOMMU when they happen to have been allocated contiguously.
- This doesn't add pressure to the IOMMU allocator. However, some
- drivers don't support getting large merged segments coming back
- from *_map_sg().
-
- Most drivers don't have this problem; it is safe to say Y here.
-
config IOMMU_HELPER
def_bool PPC64

diff --git a/arch/powerpc/kernel/iommu.c b/arch/powerpc/kernel/iommu.c
index 5547ae6..ec94f90 100644
--- a/arch/powerpc/kernel/iommu.c
+++ b/arch/powerpc/kernel/iommu.c
@@ -42,12 +42,7 @@

#define DBG(...)

-#ifdef CONFIG_IOMMU_VMERGE
-static int novmerge = 0;
-#else
-static int novmerge = 1;
-

twitter

Tuesday, March 2, 2010

linux.kernel - 26 new messages in 16 topics - digest

0 Comments:

Post a Comment

About Me

Previous Posts