Julia Lawall writes:
> On Mon, 3 Jun 2013, Uwe Kleine-König wrote:
> For a random example, here is a function that currently uses PTR_RET:
Heheh, nice choice: I think I wrote that code originally :)
> static int __net_init iptable_raw_net_init(struct net *net)
> {
> struct ipt_replace *r
On 06/12/2013 09:31 PM, Scott Wood wrote:
On 06/12/2013 10:08:29 AM, Sebastian Andrzej Siewior wrote:
On 06/12/2013 02:47 PM, Oded Gabbay wrote:
> This patch fixes a bug in the fsl_pq_mdio.c module and in relevant
device-tree
> files regarding the correct offset of the tbipa register in the eT
On Thu, Jun 13, 2013 at 03:01:22AM +0100, Al Viro wrote:
> On Fri, Jun 07, 2013 at 05:14:52PM +0100, Al Viro wrote:
> > On Fri, Jun 07, 2013 at 11:09:05AM -0500, Dave Chiluk wrote:
> > > Can't you just use the patch from my original e-mail? Anyhow I attached
> > > it an already signed-off patch.
>
This patch silents the following sparse warnings:
drivers/net/macvtap.c:98:9: warning: incorrect type in assignment (different
address spaces)
drivers/net/macvtap.c:98:9:expected struct macvtap_queue *
drivers/net/macvtap.c:98:9:got struct macvtap_queue [noderef]
*
drivers/net/macvtap.c:12
Return -EINVAL on illegal flag instead of uninitialized value. This fixes the
kbuild test warning.
Signed-off-by: Jason Wang
---
drivers/net/macvtap.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers/net/macvtap.c b/drivers/net/macvtap.c
index edcbf1c..5a76f20 10
Hey John,
On Tue, Jun 11, 2013 at 09:22:47PM -0700, John Stultz wrote:
> At lsf-mm, the issue was brought up that there is a precedence with
> interfaces like mlock, such that new mappings in a pre-existing range
> do no inherit the mlock state.
>
> This is mostly because mlock only modifies the
On 06/13/2013 01:48 PM, Eric Dumazet wrote:
> On Thu, 2013-06-13 at 12:21 +0800, Jason Wang wrote:
>> This patch silents the following sparse warnings:
>>
>> dr
>> Signed-off-by: Jason Wang
>> ---
>> drivers/net/macvtap.c |2 +-
>> include/linux/if_macvlan.h |2 +-
>> 2 files changed
Hi Grant,
On 12 June 2013 18:58, Grant Likely wrote:
> On Mon, 3 Jun 2013 21:21:11 +0530, Pranavkumar Sawargaonkar
> wrote:
>> This patch adds support for defining and passing earlyprintk
>> related information i.e. device and address information via
>> device tree by adding it inside "chosen"
When I inject incorrect argument into uprobe_events,
[root@jovi tracing]# echo 'p:myprobe /bin/bash' > uprobe_events
[root@jovi tracing]#
it doesn't return any error value in there, this patch fix it.
Signed-off-by: zhangwei(Jovi)
---
kernel/trace/trace_uprobe.c |4 +++-
1 file changed, 3
On 6/12/2013 5:40 PM, Philip, Avinash wrote:
> On Wed, Jun 12, 2013 at 13:13:59, Nori, Sekhar wrote:
>> On 6/11/2013 6:25 PM, Philip, Avinash wrote:
>>
>>> On Tue, Jun 11, 2013 at 17:26:06, Nori, Sekhar wrote:
>>
On 5/22/2013 12:40 PM, Philip Avinash wrote:
>>
> @@ -179,13 +204,10 @@ stati
On 2013/6/13 12:04, Tejun Heo wrote:
> Hello,
>
> The changes from the last take[L] are,
>
> * Rebased on top of further percpu-refcount updates.
>
> * 0003: Broken patch description updated.
>
> * 0004: Stupid list_del_init() conversions from the last decade
> dropped.
>
> * 0005: Typ
On 06/04/2013 09:49 AM, Tushar Behera wrote:
> From: Tomasz Figa
>
> Since uart_base can be set dynamically in arch_detect_cpu(), there is no
> need to have a copy of all code locally, just to override UART base
> address.
>
> This patch removes any duplicate code in uncompress.h variant of s5p6
On 06/04/2013 09:49 AM, Tushar Behera wrote:
> For mach-exynos, uart_base is a pointer and the value is calculated
> in the machine folder. For other machines, uart_base is defined as
> a macro in platform directory. For symmetry, the uart_base macro
> definition is removed and the uart_base calcul
On 06/12/2013 06:56 AM, Sergei Shtylyov wrote:
Hello.
On 12-06-2013 15:34, Michael S. Tsirkin wrote:
commit df8ef8f3aaa6692970a436204c4429210addb23a in linux 3.5 added a way
Please also specify that commit's summary line in parens.
to control NOPROMISC macvlan flag through netlink.
On 13 June 2013 11:10, Xiaoguang Chen wrote:
> 2013/6/12 Viresh Kumar :
>> On 12 June 2013 14:39, Xiaoguang Chen wrote:
>>
>>> ret = policy->governor->governor(policy, event);
>>
>> We again reached to the same problem. We shouldn't call
>> this between taking locks, otherwise recursive l
On Thu, 2013-06-13 at 12:21 +0800, Jason Wang wrote:
> This patch silents the following sparse warnings:
>
> dr
> Signed-off-by: Jason Wang
> ---
> drivers/net/macvtap.c |2 +-
> include/linux/if_macvlan.h |2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/d
On Wed, 12 Jun 2013 20:54:32 -0700 Kent Overstreet
wrote:
> On Wed, Jun 12, 2013 at 08:03:11PM -0700, Andrew Morton wrote:
> > On Wed, 12 Jun 2013 19:05:36 -0700 Kent Overstreet
> > wrote:
> >
> > > ...
> > >
> > > > Why can't we use ida_get_new_above()?
> > > >
> > > >If it is "speed" t
On Wed, Jun 12, 2013 at 8:50 PM, Bjorn Helgaas wrote:
> On Wed, Jun 12, 2013 at 1:41 PM, Yinghai Lu wrote:
>
> I think you're saying that in systems that support both acpiphp and
> pciehp, we should be using pciehp, but we currently use acpiphp. If
> so, that's certainly a bug. How serious is i
On 13 June 2013 11:00, Tushar Behera wrote:
> On 06/10/2013 05:05 PM, Tushar Behera wrote:
>> Commit 75096579c3ac ("lib: devres: Introduce devm_ioremap_resource()")
>> introduced devm_ioremap_resource() and deprecated the use of
>> devm_request_and_ioremap().
>>
>> Signed-off-by: Tushar Behera
>>
2013/6/12 Viresh Kumar :
> On 12 June 2013 14:39, Xiaoguang Chen wrote:
>
>> ret = policy->governor->governor(policy, event);
>
> We again reached to the same problem. We shouldn't call
> this between taking locks, otherwise recursive locks problems
> would be seen again.
But this is not
On Thu, 2013-06-13 at 09:35 +1000, Dave Wiltshire wrote:
> Firstly, from my cover letter: "Perhaps I don't understand something,
> but I thought it best to generate the change and then ask. So is this
> correct?".
Sure I have no problems with that.
> But secondly, I understand that the only rea
On Wednesday, June 12, 2013 7:56 PM, Arnd Bergmann wrote:
>
> Thanks for the update! A few comments again:
>
> On Wednesday 12 June 2013 19:20:00 Jingoo Han wrote:
> >
> > diff --git a/arch/arm/boot/dts/exynos5440-ssdk5440.dts
> > b/arch/arm/boot/dts/exynos5440-ssdk5440.dts
> > index d55042b..ef
On 06/10/2013 05:05 PM, Tushar Behera wrote:
> Commit 75096579c3ac ("lib: devres: Introduce devm_ioremap_resource()")
> introduced devm_ioremap_resource() and deprecated the use of
> devm_request_and_ioremap().
>
> Signed-off-by: Tushar Behera
> CC: net...@vger.kernel.org
> CC: linux-...@vger.ker
On 13 June 2013 03:01, Marc Kleine-Budde wrote:
> Commit 75096579c3ac ("lib: devres: Introduce devm_ioremap_resource()")
> introduced devm_ioremap_resource() and encourage to check its return value
> with
> IS_ERR(). This however leads to the following sparse warnings, as
> devm_ioremap_resource(
On 06/12/2013 10:16 PM, Sören Brinkmann wrote:
> On Wed, Jun 12, 2013 at 09:33:58PM +0200, Steffen Trumtrar wrote:
>> On Wed, Jun 12, 2013 at 11:26:34AM -0700, Sören Brinkmann wrote:
>>> On Wed, Jun 12, 2013 at 08:23:45PM +0200, Steffen Trumtrar wrote:
On Wed, Jun 12, 2013 at 09:41:08AM -0700,
> -Original Message-
> From: linux-pm-ow...@vger.kernel.org [mailto:linux-pm-
> ow...@vger.kernel.org] On Behalf Of Eduardo Valentin
> Sent: Thursday, May 30, 2013 3:07 AM
> To: Zhang, Rui
> Cc: Eduardo Valentin; Amit Daniel Kachhap; R, Durgadoss; linux-
> p...@vger.kernel.org; linux-kernel
On 6/12/2013 11:04 AM, Santosh Y wrote:
/**
+ * ufshcd_query_request() - API for issuing query request to the device.
+ * @hba: ufs driver context
+ * @query: params for query request
+ * @descriptor: buffer for sending/receiving descriptor
+ * @retries: number of times to try executing t
Hi,
On 06/11/2013 06:20 AM, Rafael J. Wysocki wrote:
>
> OK, so let's try to take one step more and think about what part should belong
> to the scheduler and what part should be taken care of by the "idle" driver.
>
> Do you have any specific view on that?
I gave it some thought and went throu
On 6/12/2013 11:00 AM, Santosh Y wrote:
+/*
+ * ufshcd_wait_for_register - wait for register value to change
+ * @hba - per-adapter interface
+ * @reg - mmio register offset
+ * @mask - mask to apply to read register value
+ * @val - wait condition
+ * @interval_us - polling interval in microsecs
Return -EINVAL on illegal flag instead of uninitialized value. This fixes the
kbuild test warning.
Signed-off-by: Jason Wang
---
drivers/net/macvtap.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers/net/macvtap.c b/drivers/net/macvtap.c
index acf55ba..9f03ce3 10
This patch silents the following sparse warnings:
drivers/net/macvtap.c:98:9: warning: incorrect type in assignment (different
address spaces)
drivers/net/macvtap.c:98:9:expected struct macvtap_queue *
drivers/net/macvtap.c:98:9:got struct macvtap_queue [noderef]
*
drivers/net/macvtap.c:12
This patch adds Palmas MFD node and the regulator nodes for OMAP5.
The node definitions are based on: https://lkml.org/lkml/2013/6/6/25
Boot tested on omap5-uevm board.
Signed-off-by: Graeme Gregory
Signed-off-by: J Keerthy
Reviewed-by: Stephen Warren
---
V6:
Changed the order of properties.
Good day, I Am Chi Pui;Do not be surprised! I got your email contact via the
World Email On-line Directory" I am crediting officer at Sino Pac Bank Plc
in Hong Kong and i have a deal of $17.3M to discuss with you urgently.
Regards,
Mr.Chi Pui
--
To unsubscribe from this list: send the line "unsub
On 12 June 2013 21:20, Stephen Warren wrote:
> On 06/12/2013 02:15 AM, Viresh Kumar wrote:
>> ARCH_TEGRA selects ARCH_HAS_CPUFREQ, so CPUFREQ will be enabled for all
>> variants
>> of TEGRA. CPUFreq driver for tegra is enabled if ARCH_TEGRA is selected.
>> Driver
>> uses APIs from freq_table.c a
On 6/12/2013 6:40 AM, Tomasz Stanislawski wrote:
> Hi Casey,
> Thank you for your review.
> Please refer to comments below.
>
> On 06/12/2013 07:11 AM, Casey Schaufler wrote:
>> On 6/11/2013 5:55 AM, Tomasz Stanislawski wrote:
>>> This patch adds a hash table to quicken searching of a smack label b
Hi Bjorn,
I'm working on several acpiphp related bugfixes, and feel some
are materials for 3.10 too. Actually we have identified four bugs
related to dock station support on Sony VAIO VPCZ23A4R laptop.
I will try to send out patchset to address these bugs tonight.
Seems we really need to rethi
Hi Stephen,
> -Original Message-
> From: Stephen Warren [mailto:swar...@wwwdotorg.org]
> Sent: Wednesday, June 12, 2013 9:22 PM
> To: J, KEERTHY
> Cc: Cousson, Benoit; devicetree-disc...@lists.ozlabs.org; linux-
> o...@vger.kernel.org; linux-kernel@vger.kernel.org;
> ldewan...@nvidia.com;
Signed-off-by: Tejun Heo
---
include/linux/cgroup.h | 1 -
kernel/cgroup.c| 12
2 files changed, 13 deletions(-)
diff --git a/include/linux/cgroup.h b/include/linux/cgroup.h
index d0ad379..5830592 100644
--- a/include/linux/cgroup.h
+++ b/include/linux/cgroup.h
@@ -848,7 +8
Hello,
The changes from the last take[L] are,
* Rebased on top of further percpu-refcount updates.
* 0003: Broken patch description updated.
* 0004: Stupid list_del_init() conversions from the last decade
dropped.
* 0005: Typo fix.
* 0011: percpu_ref_init() error handling fixed. Prem
cgroup.c uses @cg for most struct css_set variables, which in itself
could be a bit confusing, but made much worse by the fact that there
are places which use @cg for struct cgroup variables.
compare_css_sets() epitomizes this confusion - @[old_]cg are struct
css_set while @cg[12] are struct cgroup
cgroups and css_sets are mapped M:N and this M:N mapping is
represented by struct cg_cgroup_link which forms linked lists on both
sides. The naming around this mapping is already confusing and struct
cg_cgroup_link exacerbates the situation quite a bit.
>From cgroup side, it starts off ->css_sets
We will add another flag indicating that the cgroup is in the process
of being killed. REMOVING / REMOVED is more difficult to distinguish
and cgroup_is_removing()/cgroup_is_removed() are a bit awkward. Also,
later percpu_ref usage will involve "kill"ing the refcnt.
s/CGRP_REMOVED/CGRP_DEAD/
s
There's no point in using kmalloc() instead of the clearing variant
for trivial stuff. We can live dangerously elsewhere. Use kzalloc()
instead and drop 0 inits.
While at it, do trivial code reorganization in cgroup_file_open().
This patch doesn't introduce any functional changes.
v2: I was ca
__put_css_set() does RCU read access on @cgrp across dropping
@cgrp->count so that it can continue accessing @cgrp even if the count
reached zero and destruction of the cgroup commenced. Given that both
sides - __css_put() and cgroup_destroy_locked() - are cold paths, this
is unnecessary. Just ma
This patch reorders the operations in cgroup_destroy_locked() such
that the userland visible parts happen before css offlining and
removal from the ->sibling list. This will be used to make css use
percpu refcnt.
While at it, split out CGRP_DEAD related comment from the refcnt
deactivation one an
Split cgroup_destroy_locked() into two steps and put the latter half
into cgroup_offline_fn() which is executed from a work item. The
latter half is responsible for offlining the css's, removing the
cgroup from internal lists, and propagating release notification to
the parent. The separation is
A css (cgroup_subsys_state) is how each cgroup is represented to a
controller. As such, it can be used in hot paths across the various
subsystems different controllers are associated with.
One of the common operations is reference counting, which up until now
has been implemented using a global a
cgroup->count tracks the number of css_sets associated with the cgroup
and used only to verify that no css_set is associated when the cgroup
is being destroyed. It's superflous as the destruction path can
simply check whether cgroup->cset_links is empty instead.
Drop cgroup->count and check ->cse
* __css_get() isn't used by anyone. Fold it into css_get().
* Add proper function comments to all css reference functions.
This patch is purely cosmetic.
v2: Typo fix as per Li.
Signed-off-by: Tejun Heo
Cc: Li Zefan
---
include/linux/cgroup.h | 48 ---
(2013/06/12 18:13), Michael Holzheu wrote:
On Tue, 11 Jun 2013 21:42:15 +0900
HATAYAMA Daisuke wrote:
2013/6/11 Michael Holzheu :
On Mon, 10 Jun 2013 22:40:24 +0900
HATAYAMA Daisuke wrote:
2013/6/8 Michael Holzheu :
Thanks for that hint! So together with your other comment regarding
er
On Wed, Jun 12, 2013 at 08:58:31PM -0700, Tejun Heo wrote:
> At first I named it percpu_ref_free() but it looked too symmetric to
> init, more so than kill, so I was worried that people might get
> confused that this is the normal interface to shutdown a percpu
> refcnt, so the weird cancel_init na
On Wed, Jun 12, 2013 at 08:56:36PM -0700, Kent Overstreet wrote:
> On Wed, Jun 12, 2013 at 08:52:35PM -0700, Tejun Heo wrote:
> > Normally, percpu_ref_init() initializes and percpu_ref_kill*()
> > initiates destruction which completes asynchronously. The
> > asynchronous destruction can be problem
On Wed, Jun 12, 2013 at 08:52:35PM -0700, Tejun Heo wrote:
> Normally, percpu_ref_init() initializes and percpu_ref_kill*()
> initiates destruction which completes asynchronously. The
> asynchronous destruction can be problematic in init failure path where
> the caller wants to destroy half-constr
On Wed, Jun 12, 2013 at 08:03:11PM -0700, Andrew Morton wrote:
> On Wed, 12 Jun 2013 19:05:36 -0700 Kent Overstreet
> wrote:
>
> > ...
> >
> > > Why can't we use ida_get_new_above()?
> > >
> > >If it is "speed" then how bad is the problem and what efforts have
> > >been made to address
Normally, percpu_ref_init() initializes and percpu_ref_kill*()
initiates destruction which completes asynchronously. The
asynchronous destruction can be problematic in init failure path where
the caller wants to destroy half-constructed object - distinguishing
half-constructed objects from the usu
Two small changes.
* Unlike most init functions, percpu_ref_init() allocates memory and
may fail. Let's mark it with __must_check in case the caller
forgets.
* percpu_ref_kill_rcu() is unnecessarily using ACCESS_ONCE() to
dereference @ref->pcpu_count, which can be misleading. The pointer
On Wed, Jun 12, 2013 at 1:41 PM, Yinghai Lu wrote:
> On Wed, Jun 12, 2013 at 10:05 AM, Bjorn Helgaas wrote:
>>> current code from acpi_pci_root_add we have
>>> 1. pci_acpi_scan_root
>>> ==> pci devices enumeration and bus scanning.
>>> ==> pci_alloc_child_bus
>>>
Implement percpu_tryget() which stops giving out references once the
percpu_ref is visible as killed. Because the refcnt is per-cpu,
different CPUs will start to see a refcnt as killed at different
points in time and tryget() may continue to succeed on subset of cpus
for a while after percpu_ref_k
On Wed, Jun 12, 2013 at 01:45:32PM -0700, Tejun Heo wrote:
> From 49d1e1a6561f1e4b190695f36d2594c7c04b8e76 Mon Sep 17 00:00:00 2001
> From: Tejun Heo
> Date: Wed, 12 Jun 2013 13:37:42 -0700
>
> * s/percpu_ref_release/percpu_ref_func_t/ as it's customary to have _t
> postfix for types and the ty
On Wed, Jun 12, 2013 at 01:40:32PM -0700, Tejun Heo wrote:
> From e96262150a513ce3d54ff221d4ace8aeec96e0bf Mon Sep 17 00:00:00 2001
> From: Tejun Heo
> Date: Wed, 12 Jun 2013 13:37:42 -0700
>
> percpu_ref_get/put() are using preempt_disable/enable() while
> percpu_ref_kill() is using plain call_r
Not sure who takes this, but please pull these 2 changes for pstore for
3.11. These are necessary to get pstore to work with on-chip RAM on
Calxeda highbank platform.
I dropped the write-combine change from this series. While write-combine
is technically the correct mapping needed for ARM, it does
On Wed, Jun 12, 2013 at 8:44 PM, Takao Indoh wrote:
> (2013/06/12 13:45), Bjorn Helgaas wrote:
>> [+cc Vivek, Haren; sorry I didn't think to add you earlier]
>>
>> On Tue, Jun 11, 2013 at 12:08 AM, Takao Indoh
>> wrote:
>>> (2013/06/11 11:20), Bjorn Helgaas wrote:
>>
I'm not sure you need to
Sorry for replying late during these days, firstly.
On 06/10/2013 10:12 PM, Thomas Gleixner wrote:
> On Sun, 9 Jun 2013, Chen Gang wrote:
>
>> >
>> > According to __internal_add_timer(), in _next_timer_interrupt(), when
>> > 'tv1.vec' find one, but need 'cascade bucket(s)', we still need find
On Fri, 2013-06-07 at 15:14 +0200, Lotfi Manseur wrote:
> Handle null termios in ftdi_set_termios(), introduced in
> commit 552f6bf1bb0eda0011c0525dd587aa9e7ba5b846
> This has been corrected in the mainline by
> commits c515598e0f5769916c31c00392cc2bfe6af74e55 and
> a816e3113b63753c330ca4751ea1d208
(2013/06/12 22:19), Don Dutile wrote:
> On 06/11/2013 07:19 PM, Sumner, William wrote:
>>
>>> (2013/06/11 11:20), Bjorn Helgaas wrote:
On Fri, Jun 7, 2013 at 2:46 AM, Takao Indoh
wrote:
> (2013/06/07 13:14), Bjorn Helgaas wrote:
>> One thing I'm not sure about is that you a
On Thu, 13 Jun 2013, Samuel Ortiz wrote:
> > +static struct vexpress_spc_drvdata *info;
> > +static u32 *vexpress_spc_config_data;
> > +static struct vexpress_config_bridge *vexpress_spc_config_bridge;
> > +static struct vexpress_config_func *opp_func, *perf_func;
> > +
> > +static int vexpress_sp
On Wed, Jun 12, 2013 at 12:32:11PM -0700, Zach Brown wrote:
> >fs/btrfs/delayed-inode.c: In function 'get_ins_del_root':
> > >> fs/btrfs/delayed-inode.c:393:1: warning: control reaches end of non-void
> > >> function [-Wreturn-type]
> >
> > vim +393 fs/btrfs/delayed-inode.c
> >
> >385
On 2013/6/13 10:38, Kent Overstreet wrote:
> On Thu, Jun 13, 2013 at 10:36:40AM +0800, Li Zefan wrote:
>> On 2013/6/13 5:03, Tejun Heo wrote:
>>> There's no point in using kmalloc() and list_del() instead of the
>>> clearing variants for trivial stuff. We can live dangerously
>>> elsewhere. Use k
Hi, Peter
Would you like to give some comments on this approach? or may be just
some hint on what's the concern? the damage on pgbench is still there...
Regards,
Michael Wang
On 05/28/2013 01:05 PM, Michael Wang wrote:
> wake-affine stuff is always trying to pull wakee close to waker, by theory
On Wed, Jun 12, 2013 at 07:56:23PM -0700, Tejun Heo wrote:
> poison. Maybe it was something which got stuck in my brain from
> before the git history or I'm just hallucinating. Anyways, yeap,
Just checked 2.4. It didn't poison then. Somehow I never got that
out of my brain all these years. #f
On Fri, 2013-06-07 at 17:20 +0800, Li Zefan wrote:
> On 2013/5/31 21:06, Ben Hutchings wrote:
> > I'm announcing the release of the 3.2.46 kernel.
> >
> > All users of the 3.2 kernel series should upgrade.
> >
> > The updated 3.2.y git tree can be found at:
> >
> > git://git.kernel.org/p
On Wed, 12 Jun 2013 19:05:36 -0700 Kent Overstreet
wrote:
> ...
>
> > Why can't we use ida_get_new_above()?
> >
> >If it is "speed" then how bad is the problem and what efforts have
> >been made to address them within the idr code? (A per-cpu magazine
> >frontend to ida_get_new_abo
On Wed, Jun 12, 2013 at 07:52:02PM -0700, Kent Overstreet wrote:
> On Wed, Jun 12, 2013 at 07:48:59PM -0700, Tejun Heo wrote:
> > On Wed, Jun 12, 2013 at 07:43:10PM -0700, Kent Overstreet wrote:
> > > list_del() does do poisoning - and list debugging is cheaper to enable
> > > than full slab debugg
On 06/12/2013 11:40 PM, Paul E. McKenney wrote:
> Breaking up locks is better than implementing high-contention locks, but
> if we must have high-contention locks, why not make them automatically
> switch between light-weight ticket locks at low contention and queued
> locks at high contention? Af
On Wed, Jun 12, 2013 at 07:48:59PM -0700, Tejun Heo wrote:
> On Wed, Jun 12, 2013 at 07:43:10PM -0700, Kent Overstreet wrote:
> > list_del() does do poisoning - and list debugging is cheaper to enable
> > than full slab debugging.
>
> Ah, right, now we have DEBUG_LIST. Completely forgot about tha
On Wed, Jun 12, 2013 at 07:43:10PM -0700, Kent Overstreet wrote:
> list_del() does do poisoning - and list debugging is cheaper to enable
> than full slab debugging.
Ah, right, now we have DEBUG_LIST. Completely forgot about that. I
don't think the cost difference matters that much as long as th
hi, Dmitry
What are the status for these patches? Thanks.
On Wed, May 15, 2013 at 2:40 PM, Dmitry Torokhov
wrote:
> Hi Chao,
>
> On Mon, May 13, 2013 at 04:02:07PM +0800, Chao Xie wrote:
>> hi, dmitry
>> What is your idea about these patches?
>> Do i need add someone else to review them?
>>
>
> N
(2013/06/12 13:45), Bjorn Helgaas wrote:
> [+cc Vivek, Haren; sorry I didn't think to add you earlier]
>
> On Tue, Jun 11, 2013 at 12:08 AM, Takao Indoh
> wrote:
>> (2013/06/11 11:20), Bjorn Helgaas wrote:
>
>>> I'm not sure you need to reset legacy devices (or non-PCI devices)
>>> yet, but the
On Mon, 2013-06-03 at 08:02 -0400, Konrad Rzeszutek Wilk wrote:
> Hey Greg,
>
> I hadn't (by mistake) put the CC: sta...@vger.kernel.org on said patch
> (Which is in the Linux kernel).
>
> If possible please back-port said patch to the existing stable trees.
> Attached is a version that applies t
On Wed, Jun 12, 2013 at 07:34:43PM -0700, James Bottomley wrote:
> On Thu, 2013-06-13 at 09:30 +0800, Fengguang Wu wrote:
> > Greetings,
> >
> > I got the below dmesg and the first bad commit is
> >
> > commit a256ba092ec57213f96059d41ac5473ff92f5e7c
> > Author: Nicholas Bellinger
> > Date: Sa
On 06/11/2013 03:32 PM, Geert Uytterhoeven wrote:
> On Tue, Jun 11, 2013 at 12:26 AM, Tony Luck wrote:
>> > On Sat, Jun 8, 2013 at 3:08 AM, Chen Gang wrote:
>>> >> using 'unsigned int *', implicitly:
>>> >> ./ia64/include/asm/bitops.h:63:__set_bit (int nr, volatile void *addr)
>> >
>> > There i
On Wed, Jun 12, 2013 at 07:41:15PM -0700, Tejun Heo wrote:
> Hello,
>
> On Wed, Jun 12, 2013 at 7:38 PM, Kent Overstreet
> wrote:
> > IMO, list_del() is preferred when the object shouldn't be reused (i.e.
> > it gets taken off a list and then it's freed). list_del_init() could
> > hide bugs.
>
Quoting Heiko Stübner (2013-06-03 15:18:32)
> Am Montag, 3. Juni 2013, 19:53:10 schrieb Mike Turquette:
> > Devicetree binding for the basic clock divider, plus the setup function
> > to register the clock. Based on the existing fixed-clock binding.
> >
> > Signed-off-by: Mike Turquette
> > ---
Hello,
On Wed, Jun 12, 2013 at 7:38 PM, Kent Overstreet wrote:
> IMO, list_del() is preferred when the object shouldn't be reused (i.e.
> it gets taken off a list and then it's freed). list_del_init() could
> hide bugs.
Nah... use-after-frees are detected much more reliably by poisoning
anyway.
Hello,
On Wed, Jun 12, 2013 at 7:36 PM, Li Zefan wrote:
> Do you mean we prefer list_del_init() than list_del() in general? Then
Yes.
> in which cases do we prefer list_del()?
Nowadays, I don't think we ever prefer list_del(). Maybe if it can be
shown that the extra init part is noticeably exp
On Thu, Jun 13, 2013 at 10:36:40AM +0800, Li Zefan wrote:
> On 2013/6/13 5:03, Tejun Heo wrote:
> > There's no point in using kmalloc() and list_del() instead of the
> > clearing variants for trivial stuff. We can live dangerously
> > elsewhere. Use kzalloc() and list_del_init() instead and drop
On 2013/6/13 5:03, Tejun Heo wrote:
> * __css_get() isn't used by anyone. Fold it into css_get().
>
> * Add proper function comments to all css reference functions.
>
> This patch is purely cosmetic.
>
> Signed-off-by: Tejun Heo
> ---
> include/linux/cgroup.h | 48
On 2013/6/13 5:03, Tejun Heo wrote:
> There's no point in using kmalloc() and list_del() instead of the
> clearing variants for trivial stuff. We can live dangerously
> elsewhere. Use kzalloc() and list_del_init() instead and drop 0
> inits.
>
Do you mean we prefer list_del_init() than list_del
My aboriginal linux project builds tiny linux systems to run under
qemu, producing as close to the same system as possible across a bunch
of different architectures. The above change broke the mips r4k build
I've been running under qemu.
Here's a toolchain and reproduction sequence:
wget
On 2013/6/13 5:03, Tejun Heo wrote:
> cgroups and css_sets are mapped M:N and this M:N mapping is
> represented by struct cg_cgroup_link which points to forms linked
> lists on both sides. The naming around this already confusing struct
> is pretty bad.
>
>>From cgroup side, it starts off ->css_s
On Thu, 2013-06-13 at 09:30 +0800, Fengguang Wu wrote:
> Greetings,
>
> I got the below dmesg and the first bad commit is
>
> commit a256ba092ec57213f96059d41ac5473ff92f5e7c
> Author: Nicholas Bellinger
> Date: Sat May 18 02:40:43 2013 -0700
>
> scsi: Split scsi_dispatch_cmd into __scsi_d
On Sat, 2013-06-01 at 00:55 -0400, David Dillow wrote:
> On Tue, 2013-05-28 at 15:45 +0200, Jiri Kosina wrote:
> > I'd be glad if you could provide your Tested-by: for the patch below.
> > Thanks a lot.
>
> I tried to test this tonight, but was thwarted by Fedora 16 on the only
> readily availabl
On 06/08/2013 06:08 PM, Chen Gang wrote:
> Several architectures have different __set_bit() API to others, in
> standard API, 2nd param of __set_bit() is 'unsigned long *', but:
>
> in 'min10300', it is 'unsigned char *',
Oh, it is my fault, for 'mn10300' it is no issue, it is not 'unsigned
cha
On Wed, 2013-05-29 at 17:37 -0400, Eduardo Valentin wrote:
> In case emulated temperature is in use, using the trend
> provided by driver layer can lead to bogus situation.
> In this case, debugger user would set a temperature value,
> but the trend would be from driver computation.
>
> To avoid t
I forget change final_start/final_end to start/end. The old code add empty
range in following case:
Before mtrr cleanup:
1. got initial MTRR range: 0-3G.
2. MTRR code try to merge 0-1M
3. result is 0-0, 0-3G, total 2 range count
After cleanup:
1. got final MTRR range: 0-3G, total 1 range count
On Wed, 2013-05-29 at 11:07 -0400, Eduardo Valentin wrote:
> Hello Rui,
>
> Here is a patch set for your consideration on ti-soc-thermal driver.
>
the whole patch set has been applied.
thanks,
rui
> This patch set is mix of:
>
> (a) patches that were added to the staging tree post 3.10-rc1 but
On 13/06/2013 05:01, Stephen Hemminger wrote:
On Wed, 12 Jun 2013 15:12:05 -0700 (PDT)
David Miller wrote:
From: Eliezer Tamir
Date: Tue, 11 Jun 2013 17:24:28 +0300
depends on X86_TSC
Wait a second, I didn't notice this before. There needs to be a better
way to test for the accur
On ARM max_pfn and max_low_pfn have always been relative to the
first valid PFN, apparently due to ancient kernels being unable
to properly handle physical memory at addresses other than 0.
A comment was added:
Note: max_low_pfn and max_pfn reflect the number of _pages_ in
the system, not the
On Wed, Jun 12, 2013 at 04:43:44PM +0900, Yoshihiro YUNOMAE wrote:
> Add a tracepoint write_tsc_offset for tracing TSC offset change.
> We want to merge ftrace's trace data of guest OSs and the host OS using
> TSC for timestamp in chronological order. We need "TSC offset" values for
> each guest wh
On 06/10/2013 10:15 PM, Thomas Gleixner wrote:
> On Sun, 9 Jun 2013, Chen Gang wrote:
>> > After finish the internal 'while', need not test TASKLET_STATE_SCHED
>> > again, so looping back to outside 'while' is only for set_bit().
>> >
>> > When use 'if' and set_bit() instead of 'while', it will sa
1 - 100 of 651 matches
Mail list logo