* Julien Tinnes wrote:
> On Thu, Apr 4, 2013 at 1:27 PM, H. Peter Anvin wrote:
> > On 04/04/2013 01:23 PM, Julien Tinnes wrote:
> >> On Thu, Apr 4, 2013 at 1:19 PM, Julien Tinnes wrote:
> >>> On Thu, Apr 4, 2013 at 1:12 PM, H. Peter Anvin wrote:
> On 04/04/2013 01:07 PM, Kees Cook wrote:
Hi guys,
Added some folks to CC, blame scripts/get_maintainer.pl.
Comment below ..
On Tue, Apr 02, 2013 at 02:22:05PM -0700, Nishanth Aravamudan wrote:
> From: Michael Neuling
>
> We are currently out of free bits in AT_HWCAP. With POWER8, we have
> several hardware features that we need to a
On 5 April 2013 12:18, Kukjin Kim wrote:
> Basically, this moving looks good to me, but should be re-worked based on
> for-next of samsung tree because this touches too many samsung stuff so this
> should be sent to upstream via samsung tree.
Hmm... Its already applied in Rafael's tree. But it do
Hi Kevin,
On Wednesday 03 April 2013 11:18 PM, Kevin Hilman wrote:
Sourav Poddar writes:
Hi Kevin,
On Wednesday 20 March 2013 05:36 PM, Sourav Poddar wrote:
Realised the list to whom the patch was send got dropped. Ccing
them all..
On Wednesday 20 March 2013 05:18 PM, Sourav Poddar wrote:
H
* Kees Cook wrote:
> This creates CONFIG_RANDOMIZE_BASE, so that the base offset of the kernel
> can be randomized at boot.
>
> This makes kernel vulnerabilities harder to reliably exploit, especially
> from remote attacks and local processes in seccomp containers. Keeping
> the location of ker
* Kees Cook wrote:
> Add logic for 64-bit kernel relocations. Since there is no need to
> handle 32 and 64 bit at the same time, refactor away most of the 32/64
> bit ELF differences and split the build into producing two separate
> binaries. Additionally switches to using realloc instead of a t
On Friday 05 April 2013 12:38 PM, Sourav Poddar wrote:
> Hi Kevin,
> On Wednesday 03 April 2013 11:18 PM, Kevin Hilman wrote:
>> Sourav Poddar writes:
>>
>>> Hi Kevin,
>>> On Wednesday 20 March 2013 05:36 PM, Sourav Poddar wrote:
Realised the list to whom the patch was send got dropped. Ccin
On 03/19/2013 10:16 PM, Sebastian Andrzej Siewior wrote:
> DEFINE_SRCU() and DEFINE_STATIC_SRCU() does the same thing except for
> the "static" attribute. This patch moves the common pieces into
> _DEFINE_SRCU() which is used by the the former macros either adding the
> static attribute or not.
>
On 03/19/2013 10:16 PM, Sebastian Andrzej Siewior wrote:
> There are macros for static initializer for the three out of four
> possible notifier types, that are:
> ATOMIC_NOTIFIER_HEAD()
> BLOCKING_NOTIFIER_HEAD()
> RAW_NOTIFIER_HEAD()
>
> This patch provides a static initilize
On 04/05/2013 01:51 AM, Julian Calaby wrote:
Hi Wang,
On Fri, Apr 5, 2013 at 3:01 AM, Wang YanQing wrote:
Current we can only enable lib80211 by enable a driver
in tree use it which will select it, but some out tree's
drivers also use it, so I think it has sense to make lib80211
can be enable
* Kees Cook wrote:
> This provides routines for selecting a randomized kernel base offset,
> bounded by e820 details. It tries to use RDRAND and falls back to RDTSC.
> If "noaslr" is on the kernel command line, no offset will be used.
Would it make sense to also add three other sources of ent
On 04/05/2013 06:01 AM, Randy Dunlap wrote:
On 04/04/13 16:51, Julian Calaby wrote:
Hi Wang,
On Fri, Apr 5, 2013 at 3:01 AM, Wang YanQing wrote:
Current we can only enable lib80211 by enable a driver
in tree use it which will select it, but some out tree's
drivers also use it, so I think it
On 04/04/2013 09:03 PM, Eric Valette wrote:
I fixed this already.
https://git.kernel.org/cgit/linux/kernel/git/jgarzik/libata-dev.git/commit/?h=upstream-fixes&id=8e725c7f8a60feaa88edacd4dee2c754d5ae7706
Thanks for the support. I will apply the patch manually and wait for 3.8.6
Just to conf
[Ping]
Hi, Eric Paris
Could you review this patch?
Thanks,
Lai
On 03/16/2013 12:50 AM, Lai Jiangshan wrote:
> fsnotify implements its own call_srcu() by:
> dedicated thread + synchronize_srcu()
>
> But srcu provides call_srcu() now, so we should convert them to use
> existed call_srcu()
* Kees Cook wrote:
> +config RANDOMIZE_BASE_MAX_OFFSET
> + hex "Maximum ASLR offset allowed"
> + depends on RANDOMIZE_BASE
> + default "0x1000"
> + range 0x0 0x1000
> + ---help---
> + Determines the maximal offset in bytes that will be applied to the
> + ker
On 04/04/2013 10:55 PM, Tejun Heo wrote:
>>From 5c529597e922c26910fe49b8d5f93aeaca9a2415 Mon Sep 17 00:00:00 2001
> From: Lai Jiangshan
> Date: Thu, 4 Apr 2013 10:05:38 +0800
>
> destroy_workqueue() performs several sanity checks before proceeding
> with destruction of a workqueue. One of the ch
* Ingo Molnar wrote:
>
> * Kees Cook wrote:
>
> > This provides routines for selecting a randomized kernel base offset,
> > bounded by e820 details. It tries to use RDRAND and falls back to RDTSC.
> > If "noaslr" is on the kernel command line, no offset will be used.
>
> Would it make sens
On Thu, Apr 04, 2013 at 03:28:54PM -0600, Stephen Warren wrote:
[...]
> > diff --git a/Documentation/devicetree/bindings/pci/nvidia,tegra20-pcie.txt
> > b/Documentation/devicetree/bindings/pci/nvidia,tegra20-pcie.txt
>
> > +Required properties:
>
> > +- interrupts: the interrupt outputs of the c
Linus,
please pull sound fixes for v3.9-rc6 from:
git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git for-linus
The topmost commit is fed61fb5275cf1fa4915d6415b4e376c87089d83
Sound fixes for 3.9-rc6
This contains sli
Donn Washburn wrote:
> I am not on the list
Indeed you are not on the alsa-devel list.
> It works some times
What works? And why would that be a problem?
Regards,
Clemens
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kern
On 01/19/2013 03:23 AM, Craig Hada wrote:
This patch sets the coherent DMA mask to 64-bit after the be2net driver
has been acknowledged that the system is 64-bit DMA capable. The coherent
DMA mask is examined by the Intel IOMMU driver to determine whether to
allow pass through context mapping for
For reference, here's the new binding document with all your comments
addressed (I think).
Thierry
NVIDIA Tegra PCIe controller
Required properties:
- compatible: "nvidia,tegra20-pcie"
- device_type: Must be "pci"
- reg: A list of physical base address and length for each set of controller
regi
On 04/03/2013 07:06 PM, Doug Anderson wrote:
> Lars,
>
> On Sat, Mar 16, 2013 at 7:41 AM, Lars-Peter Clausen wrote:
>> I think you still need the mutex for serialization, otherwise the requests
>> would just cancel each other out. Btw. what happens if you start a conversion
>> while another is st
Hi John,
On Thu, Apr 04, 2013 at 10:37:52AM -0700, John Stultz wrote:
> On 04/03/2013 11:55 PM, Minchan Kim wrote:
> >On Wed, Apr 03, 2013 at 04:52:19PM -0700, John Stultz wrote:
> >>Next we introduce a parallel fvrange() syscall for creating
> >>volatile ranges directly against files.
> >Okay. It
* Eric Northup wrote:
> On Thu, Apr 4, 2013 at 1:58 PM, H. Peter Anvin wrote:
> > It seems to me that you are assuming that the attacker is targeting a
> > specific system, but a bot might as well target 256 different systems and
> > see what sticks...
>
> The alarm signal from the ones that
Hi. Max.
I have a question.
Your mmc host driver set to host->max_discard_to by some value instead
of not zero ?
Thanks.
2013/4/5, Max Filippov :
> On Fri, Apr 5, 2013 at 5:53 AM, Shaohua Li wrote:
>> On Thu, Apr 04, 2013 at 06:00:18AM +0400, Max Filippov wrote:
>
> [...]
>
>>> the commit 0cfbc
Il 04/04/2013 12:27, Michael S. Tsirkin ha scritto:
> PIO and MMIO are separate address spaces, but
> ioeventfd registration code mistakenly detected
> two eventfds as duplicate if they use the same address,
> even if one is PIO and another one MMIO.
>
> Signed-off-by: Michael S. Tsirkin
Reviewe
On Fri, Apr 05, 2013 at 02:47:25PM +0800, Simon Jeons wrote:
> Hi Minchan,
> On 04/03/2013 09:11 AM, Minchan Kim wrote:
> >On Tue, Apr 02, 2013 at 03:15:23PM -0700, Hugh Dickins wrote:
> >>On Tue, 2 Apr 2013, Kirill A. Shutemov wrote:
> >>>Kirill A. Shutemov wrote:
> From: "Kirill A. Shutemov"
On Friday, April 05, 2013 3:57 PM, Tomi Valkeinen wrote:
>
> Hi,
>
> On 2013-03-29 03:40, Jingoo Han wrote:
> > VESA_DMT_VSYNC_HIGH should be used instead of VESA_DMT_HSYNC_HIGH,
> > because FB_SYNC_VERT_HIGH_ACT is related to vsync, not to hsync.
> >
> > Signed-off-by: Jingoo Han
> > Cc: Steffe
* H. Peter Anvin wrote:
> I have to admit to being somewhat skeptical toward KASLR with only 8
> bits of randomness. There are at least two potential ways of
> dramatically increasing the available randomness:
>
> 1. actually compose the kernel of multiple independently relocatable
>piec
On 04/04/2013 06:21 PM, Oskar Andero wrote:
> Some blackpoints are only valid for specific architectures. To let each
> architecture specify its own blackpoints the list has been split in two
> lists: common and arch. The common list is kept in kernel/kprobes.c and
> the arch list is kept in the ar
On 04/03/2013 07:29 PM, Michal Hocko wrote:
> On Wed 03-04-13 16:58:48, Glauber Costa wrote:
>> On 04/03/2013 01:11 PM, Li Zefan wrote:
>>> Use css_get/css_put instead of mem_cgroup_get/put.
>>>
>>> Note, if at the same time someone is moving @current to a different
>>> cgroup and removing the old
On Fri 05-04-13 09:14:58, Simon Jeons wrote:
> Hi Michal,
> On 03/22/2013 04:15 PM, Michal Hocko wrote:
> >[getting off-list]
> >
> >On Fri 22-03-13 07:46:32, Simon Jeons wrote:
> >>Hi Michal,
> >>On 03/21/2013 08:56 PM, Michal Hocko wrote:
> >>>On Thu 21-03-13 07:49:48, Simon Jeons wrote:
> >>>[..
On 04/04/2013 07:22 PM, Tejun Heo wrote:
> On Thu, Apr 04, 2013 at 05:20:28PM +0200, Michal Hocko wrote:
>>> But what harm does an additional reference do?
>>
>> No harm at all. I just wanted to be sure that this is not yet another
>> "for memcg" hack. So if this is useful for other controllers the
On Fri 05-04-13 07:41:23, Wanpeng Li wrote:
> On Thu, Apr 04, 2013 at 06:17:46PM +0200, Michal Hocko wrote:
> >On Thu 04-04-13 17:09:08, Wanpeng Li wrote:
> >> order >= MAX_ORDER pages are only allocated at boot stage using the
> >> bootmem allocator with the "hugepages=xxx" option. These pages ar
Now, memory barrier in __do_huge_pmd_anonymous_page doesn't work.
Because lru_cache_add_lru uses pagevec so it could miss spinlock
easily so above rule was broken so user might see inconsistent data.
I was not first person who pointed out the problem. Mel and Peter
pointed out a few months ago and
Hi Doug,
You're right..it's something wrong.
Actually i didn't test with your patch, but your commit message is reasonable.
I will check until next week after test.
Best Regards,
Jaehoon Chung
On 03/27/2013 03:06 AM, Doug Anderson wrote:
> Jaehoon,
>
> On Mon, Mar 18, 2013 at 3:21 AM, Jaehoon
On Thu, Apr 4, 2013 at 11:27 AM, Adrian Chadd wrote:
> Hi,
>
> Here's my first take on the version number policy:
>
> https://github.com/qca/open-ath9k-htc-firmware/wiki/VersionPolicy
>
> The summary:
>
> * major version number changes are for firmware API / behaviour
> changes that aren't backwar
(2013/04/05 11:39), Namhyung Kim wrote:
> From: Namhyung Kim
>
> Some of kernel functions are not allowed to be used by kprobes for
> some reason, so they're marked as __kprobe on the source code and
> reside on ".kprobes.text" section.
>
> However normal users which only see /proc/kallsyms don'
On 5 April 2013 01:19, Luis R. Rodriguez wrote:
> This is better than anything we had drafted before for 802.11 open
> firmware design rules. Cc'ing a few lists for wider review given that
> what we had written before for rules was for 802.11 and Bluetooth [0]
> and it was very Linux specific. We
From: Ivan Vecera
Date: Fri, 05 Apr 2013 09:51:24 +0200
> Dave, I'd like to ask when do you plan to apply this patch?
I'm waiting for the be2net driver maintainers to integrate it and
resend it to me, they're usually very good about that.
--
To unsubscribe from this list: send the line "unsubscr
Hi Roger,
On 03/20/2013 04:44 PM, Roger Quadros wrote:
> Hi Tony,
>
> These patches provide the SoC side code required to support
> the changes in the OMAP USB Host drivers done in [1], [2] & [3].
>
> Device tree support is added for Beagleboard only. I've removed
> Panda device tree support til
Hi Wanpeng,
On Fri, Apr 05, 2013 at 04:22:17PM +0800, Wanpeng Li wrote:
> On Fri, Apr 05, 2013 at 05:01:06PM +0900, Minchan Kim wrote:
> >On Fri, Apr 05, 2013 at 02:47:25PM +0800, Simon Jeons wrote:
> >> Hi Minchan,
> >> On 04/03/2013 09:11 AM, Minchan Kim wrote:
> >> >On Tue, Apr 02, 2013 at 03:1
> -Original Message-
> From: David Miller [mailto:da...@davemloft.net]
>
> From: Ivan Vecera
> Date: Fri, 05 Apr 2013 09:51:24 +0200
>
> > Dave, I'd like to ask when do you plan to apply this patch?
>
> I'm waiting for the be2net driver maintainers to integrate it and resend it to
> me,
On 04/02/2013 11:23 AM, Roger Quadros wrote:
> + Paul
>
> On 03/26/2013 12:23 PM, Roger Quadros wrote:
>> Register a device tree clock provider for the clocks
>> on the OMAP4 SoC. Also provide the binding information.
>>
>> For now we only provide AUXCLKs.
NOTE: this patch depends on
https://patc
From: KOSAKI Motohiro
Currently glibc rt/cpuclock2 test(*) sporadically fail. The
pseudo test code is here.
t0 = clock_gettime()
abs = t0 + sleeptime;
clock_nanosleep(TIMER_ABSTIME, abs)
t1 = clock_gettime()
assert(t1-t0 > sleeptime)
assert(t1 > abs)
Because current signal->cputimer->cput
On 11:47-20130405, Roger Quadros wrote:
> On 04/02/2013 11:23 AM, Roger Quadros wrote:
> > + Paul
> >
> > On 03/26/2013 12:23 PM, Roger Quadros wrote:
> >> Register a device tree clock provider for the clocks
> >> on the OMAP4 SoC. Also provide the binding
On 04/05/2013 11:48 AM, Nishanth Menon wrote:
> On 11:47-20130405, Roger Quadros wrote:
>> On 04/02/2013 11:23 AM, Roger Quadros wrote:
>>> + Paul
>>>
>>> On 03/26/2013 12:23 PM, Roger Quadros wrote:
>>>> Register a device tree clock provider for th
Hi Michal,
On 04/05/2013 04:12 PM, Michal Hocko wrote:
On Fri 05-04-13 07:41:23, Wanpeng Li wrote:
On Thu, Apr 04, 2013 at 06:17:46PM +0200, Michal Hocko wrote:
On Thu 04-04-13 17:09:08, Wanpeng Li wrote:
order >= MAX_ORDER pages are only allocated at boot stage using the
bootmem allocator wit
On 03/28/2013 10:22 AM, Wanlong Gao wrote:
> On 03/23/2013 07:28 PM, Wanlong Gao wrote:
>> This series implements virtio-scsi queue steering, which gives
>> performance improvements of up to 50% (measured both with QEMU and
>> tcm_vhost backends).
>>
>> This version rebased on Rusty's virtio ring r
On 18:33 Thu 04 Apr , Dmitry Torokhov wrote:
> Hi Oskar,
>
> On Thu, Mar 07, 2013 at 03:01:22PM +0100, oskar.and...@sonymobile.com wrote:
> > From: Aleksej Makarov
> >
> > When waking up the platform by pressing a specific key, sending a
> > release on that key makes it impossible to react o
Hi Michal,
On 04/05/2013 04:08 PM, Michal Hocko wrote:
On Fri 05-04-13 09:14:58, Simon Jeons wrote:
Hi Michal,
On 03/22/2013 04:15 PM, Michal Hocko wrote:
[getting off-list]
On Fri 22-03-13 07:46:32, Simon Jeons wrote:
Hi Michal,
On 03/21/2013 08:56 PM, Michal Hocko wrote:
On Thu 21-03-13 07
When looking through some mm code I stumbled over one part in
arch/x86/mm/pageattr.c that looks somewhat bogus to me. Cannot
say what exactly the effects are, but maybe you do (or you could
explain to me why I am wrong :)).
commit a8aed3e0752b4beb2e37cbed6df69faae88268da
Author: Andrea Arcangeli
On Fri, Apr 05, 2013 at 01:18:38AM -0300, Alexandre Pereira da Silva wrote:
> Some boards and card slots doesn't have card detect feature available.
> In that case allow to mark the cards as non-removable, via devicetree.
>
> Signed-off-by: Alexandre Pereira da Silva
Marc already sent a similar
On Fri, Apr 05, 2013 at 01:16:53AM -0300, Alexandre Pereira da Silva wrote:
> The imx23-olinuxino sdcard doesn't support card detect.
>
So it sounds more like a "broken-cd" rather than "non-removable"?
Shawn
> Signed-off-by: Alexandre Pereira da Silva
> ---
> arch/arm/boot/dts/imx23-olinuxino.
Commit 57084ede395bb3c9da7905701d34a3b7d33c9356 ("blackfin: bf537:
stamp: update board file for 193x") changed two references to
CONFIG_SND_BF5XX_SOC_AD193X (and CONFIG_SND_BF5XX_SOC_AD193X_MODULE).
One was changed to CONFIG_SND_SOC_AD193X_SPI, the other to
CONFIG_SND_SOC_AD193X_I2C. The commit exp
(2013/04/03 18:13), Li Zefan wrote:
> The cgroup core guarantees it's always safe to access the parent.
>
> Signed-off-by: Li Zefan
Acked-by: KAMEZAWA Hiroyuki
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More
(2013/04/03 18:14), Li Zefan wrote:
> Now memcg has the same life cycle as the corresponding cgroup.
> Kill the useless refcnt.
>
> Signed-off-by: Li Zefan
very very very nice. Thank you.
Acked-by: KAMEZAWA Hiroyuki
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" i
On Fri 05-04-13 16:27:59, Wanpeng Li wrote:
> On Fri, Apr 05, 2013 at 10:12:39AM +0200, Michal Hocko wrote:
> >On Fri 05-04-13 07:41:23, Wanpeng Li wrote:
> >> On Thu, Apr 04, 2013 at 06:17:46PM +0200, Michal Hocko wrote:
> >> >On Thu 04-04-13 17:09:08, Wanpeng Li wrote:
> >> >> order >= MAX_ORDER
On Fri 05-04-13 17:00:58, Simon Jeons wrote:
> Hi Michal,
> On 04/05/2013 04:08 PM, Michal Hocko wrote:
> >On Fri 05-04-13 09:14:58, Simon Jeons wrote:
> >>Hi Michal,
> >>On 03/22/2013 04:15 PM, Michal Hocko wrote:
> >>>[getting off-list]
> >>>
> >>>On Fri 22-03-13 07:46:32, Simon Jeons wrote:
> >>
From: Yasuaki Ishimatsu
If system can create movable node which all memory of the
node is allocated as ZONE_MOVABLE, setup_node_data() cannot
allocate memory for the node's pg_data_t.
So, use memblock_alloc_try_nid() instead of memblock_alloc_nid()
to retry when the first allocation fails.
Signe
The Hot Pluggable field in SRAT points out if the memory could be
hotplugged while the system is running. It is useful to print out
this info when parsing SRAT.
Signed-off-by: Tang Chen
---
arch/x86/mm/srat.c |9 ++---
1 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/arch/x
As mentioned by Liu Jiang and Wu Jiangguo, users could specify DMA,
DMA32, and HIGHMEM as movable. In order to ensure the kernel will
work correctly, we should exclude these memory ranges out from
zone_movable_limit[].
NOTE: Do find_usable_zone_for_movable() to initialize movable_zone
so tha
If kernelcore or movablecore is specified at the same time with
movablemem_map, movablemem_map will have higher priority to be
satisfied. This patch will make find_zone_movable_pfns_for_nodes()
calculate zone_movable_pfn[] with the limit from zone_movable_limit[].
Signed-off-by: Tang Chen
Review
Before this patch-set, we introduced movablemem_map boot option which allowed
users to specify physical address ranges to set memory as movable. This is not
user friendly enough for normal users.
So now, we introduce just movablemem_map=acpi to allow users to enable/disable
the kernel to use Hot P
Before parsing SRAT, memblock has already reserved some memory ranges
for other purposes, such as for kernel image. We cannot prevent
kernel from using these memory. Furthermore, if all the memory is
hotpluggable, then the system won't have enough memory to boot if we set
all of them as movable. So
Since node info in SRAT may not be in increasing order, we may meet
a lower range after we handled a higher range. So we need to keep
the lowest movable pfn each time we parse a SRAT memory entry, and
update it when we get a lower one.
This patch introduces a new array zone_movable_limit[], which
Ensure memblock will not allocate memory from areas that may be
ZONE_MOVABLE. The map info is from movablemem_map boot option.
The following problem was reported by Stephen Rothwell:
The definition of struct movablecore_map is protected by
CONFIG_HAVE_MEMBLOCK_NODE_MAP but its use in memblock_over
Since we are using struct numa_meminfo to store SRAT info, and sanitize
movablemem_map.map[], we need hotplug info in struct numa_meminfo.
This patch introduces a "bool hotpluggable" member into struct
numa_meminfo.
And modifies the following APIs' prototypes to support it:
- numa_add_memblk()
Since we have introduced hotplug info into struct numa_meminfo, we need
to consider it when cleanup numa_meminfo.
The original logic in numa_cleanup_meminfo() is:
Merge blocks on the same node, holes between which don't overlap with
memory on other nodes.
This patch modifies numa_cleanup_meminfo(
When parsing SRAT, we are able to know which memory ranges are hotpluggable,
and we add them to movablemem_map. So movablemem_map could be used to prevent
memblock from allocating memory in area which will be set as ZONE_MOVABLE later.
Signed-off-by: Tang Chen
---
arch/x86/mm/numa.c | 39 +
Since the kernel pages cannot be migrated, if we want a memory device
hotpluggable, we have to set all the memory on it as ZONE_MOVABLE.
This patch adds a boot option movablemem_map=acpi to inform the kernel
to use Hot Pluggable bit in SRAT to determine which memory device is
hotpluggable.
Signed
On 04/05/13 06:00, Rusty Russell wrote:
> Exactly. Don't workaround it here, revert it and put the
> duplicate-section-name fixup in parisc where it belongs.
>
> Assuming parisc still produces these dup sections: that patch is 4 years
> old now.
>
> Untested:
>
> diff --git a/arch/parisc/kernel/mo
On Fri, 05 Apr 2013 11:20:46 +0200, Paul Bolle wrote:
> 1) Added Jean and Guenter because they seem to take in interest in
> Blackfin's stamp files.
Doh, no, I only express my disgust and I'd rather stay away from them
as much as I can ;)
--
Jean Delvare
--
To unsubscribe from this list: send th
On Fri, Apr 05, 2013 at 12:09:42AM -0500, Nishanth Menon wrote:
> If we ignore the details of the class 1.5 implementation, we will notice
> a) regulator set_voltage equivalent set_voltage() is required.
> b) this set_voltage does some 'magic stuff' depending on the SoC and AVS class
> and calls t
On 4 April 2013 03:24, Tejun Heo wrote:
> Not a call, probably a module_param() so that it can be switched
> on/off during boot. You can make the param writable so that it can be
> flipped run-time but updating existing workqueues would be non-trivial
> and I don't think it's gonna be worthwhile.
(2013/04/05 17:16), Minchan Kim wrote:
> Now, memory barrier in __do_huge_pmd_anonymous_page doesn't work.
> Because lru_cache_add_lru uses pagevec so it could miss spinlock
> easily so above rule was broken so user might see inconsistent data.
>
> I was not first person who pointed out the proble
On Fri 05-04-13 16:54:44, Simon Jeons wrote:
> Hi Michal,
> On 04/05/2013 04:12 PM, Michal Hocko wrote:
> >On Fri 05-04-13 07:41:23, Wanpeng Li wrote:
> >>On Thu, Apr 04, 2013 at 06:17:46PM +0200, Michal Hocko wrote:
> >>>On Thu 04-04-13 17:09:08, Wanpeng Li wrote:
> order >= MAX_ORDER pages ar
On Thu, Apr 04, 2013 at 03:27:47PM -0700, Andrew Bresticker wrote:
> Regulator drivers may specify regulator_desc->supply_name which
> regulator_register() will use to find the supply node for a regulator.
> If no supply was specified in the device tree or the supply has yet
> to be registered reg
Hi Roger,
On 04/05/2013 10:30 AM, Benoit Cousson wrote:
...
>> ARM: dts: OMAP4: Add HS USB Host IP nodes
>> ARM: dts: OMAP3: Add HS USB Host IP nodes
>> ARM: dts: omap3-beagle: Add USB Host support
>
> These 3 DTS patches are good to me, but I cannot applied them on top of
> the already e
On Fri, Apr 05, 2013 at 08:37:39AM +0200, Marek Vasut wrote:
> btw. did you know you can let git send-email automatically handle CC for you
> so
> you don't have to type it into the command line by simply sticking
> Cc: Us Er
> in the commit message? Preferably under the SoB line.
Though not
Thanks for your input guys!
On 04:16 Fri 05 Apr , Masami Hiramatsu wrote:
> (2013/04/05 9:56), Joonsoo Kim wrote:
> > Hello, Oskar.
> >
> > On Thu, Apr 04, 2013 at 02:51:26PM +0200, Oskar Andero wrote:
> >> From: Toby Collett
> >>
> >> The symbol lookup can take a long time and kprobes is
>
Hi Stephen,
On 05/04/13 06:11, Stephen Boyd wrote:
> On 4/2/2013 1:31 PM, Stephen Boyd wrote:
>> Hot-plugging with CONFIG_DEBUG_PREEMPT=y on a device with arm
>> architected timers causes a slew of "using smp_processor_id() in
>> preemptible" warnings:
>>
>> BUG: using smp_processor_id() in pree
On Fri, 2013-04-05 at 14:30 +1030, Rusty Russell wrote:
> Sebastian Wankerl writes:
> > On 04/04/13 03:00, Rusty Russell wrote:
> >> Sebastian Wankerl writes:
> >>> Add non-zero module sections to sysfs on architectures unequal to PARISC.
> >>> KGDB needs all module sections for proper module deb
Commit f41caddbe73f52a42f529d668ce47b4d693fd2c0 ("omap2+: Use Kconfig
symbol in Makefile instead of obj-y") reorganized this Makefile. But,
for some reason, it also added references to CONFIG_MACH_ENCORE and
board-omap3encore.o. But there's no Kconfig symbol MACH_ENCORE and
there's no file board-om
Merge commit 952414505f55afe5cd6dc004765076aa22b3ed7e ("Merge branch
'next/cleanup' of git://git.linaro.org/people/arnd/arm-soc") added
references to CONFIG_MACH_PCM049 and board-omap4pcm049.o to this
Makefile. But there's no Kconfig symbol MACH_PCM049 and there's no file
board-omap4pcm049.c. This
On Thu, Apr 04, 2013 at 11:21:47PM -0500, Nishanth Menon wrote:
> commit 6d191a5fc7a969d972f1681e1c23781aecb06a61
> (regulator: core: Don't defer probe if there's no DT binding for a supply)
>
> Attempted to differentiate between regulator_get() with an actual
> DT binding for the supply and when
>* __mem_cgroup_free will issue static_key_slow_dec because this
>* memcg is active already. If the later initialization fails
>* then the cgroup core triggers the cleanup so we do not have
>* to do it here.
>*/
>> -mem_cgroup_get(memcg);
>> static_
On 04/03/2013 01:12 PM, Li Zefan wrote:
> Use css_get/put instead of mem_cgroup_get/put.
>
> We can't do a simple replacement, because here mem_cgroup_put()
> is called during mem_cgroup_css_free(), while mem_cgroup_css_free()
> won't be called until css refcnt goes down to 0.
>
> Instead we incr
From: Namhyung Kim
For some reason it consumed quite amount of compile time when declared
as local variable, and it disappeared when moved out of the function.
Moving other variables/tables didn't help.
On my system this single-file-change build time reduced from 11s to 3s.
Signed-off-by: Namhy
On Thu, Apr 04, 2013 at 06:17:20PM +0200, Tomasz Figa wrote:
> + if (of_property_read_u32(np, "max8952,ramp-speed", &pd->ramp_speed))
> + dev_warn(dev, "max8952,ramp-speed property not specified,
> defaulting to 32mV/us\n");
Applied both, though the above warning seems a bit hars
On Thu, Apr 04, 2013 at 06:05:17AM +0800, Axel Lin wrote:
> All users of ab8500_regulator_volt_mode_ops and ab8500_regulator_volt_ops
> do not set info->desc.enable_time, thus set_voltage_time_sel() always returns
> 0.
> Remove it.
Applied, thanks.
signature.asc
Description: Digital signature
Hi,
Here are a few GFS2 fixes which are pending. There are two patches
which fix up a couple of minor issues in the DLM interface code,
a missing error path in gfs2_rs_alloc(), two patches which fix problems
during "withdraw" and a fix for discards/FITRIM when using 4k sector
sized devices,
Steve
From: David Teigland
The temp lvb bitmap was on the stack, which could
be an alignment problem for __set_bit_le. Use
kmalloc for it instead.
Signed-off-by: David Teigland
Signed-off-by: Steven Whitehouse
diff --git a/fs/gfs2/incore.h b/fs/gfs2/incore.h
index 156e42e..5c29216 100644
--- a/fs/
From: Akinobu Mita
Use memchr_inv to verify that the specified memory range is cleared.
Signed-off-by: Akinobu Mita
Cc: Steven Whitehouse
Cc: cluster-de...@redhat.com
Cc: Christine Caulfield
Cc: David Teigland
diff --git a/fs/gfs2/lock_dlm.c b/fs/gfs2/lock_dlm.c
index b15bb45..c8423d6 10064
From: Wei Yongjun
The error code in gfs2_rs_alloc() is set to ENOMEM when error
but never be used, instead, gfs2_rs_alloc() always return 0.
Fix to return 'error'.
Signed-off-by: Wei Yongjun
Signed-off-by: Steven Whitehouse
diff --git a/fs/gfs2/rgrp.c b/fs/gfs2/rgrp.c
index d1f51fd..70d1cd0 1
When withdraw occurs, we need to continue to allow unlocks of fcntl
locks to occur, however these will only be local, since the node has
withdrawn from the cluster. This prevents triggering a VFS level
bug trap due to locks remaining when a file is closed.
Signed-off-by: Steven Whitehouse
diff -
From: David Teigland
This reminded me of another old patch I had sitting around which I never
had a chance to test. I copied this idea from the nfs code. The problem
is that when the kernel clears flocks/plocks during close, it calls posix
unlock even if there are no posix locks on the file. W
From: Bob Peterson
This patch changes GFS2's discard issuing code so that it calls
function sb_issue_discard rather than blkdev_issue_discard. The
code was calling blkdev_issue_discard and specifying the correct
sector offset and sector size, but blkdev_issue_discard expects
these values to be in
Hello,
On Fri 29-03-13 11:58:55, Dave Jones wrote:
> Just hit this very quickly after boot while fuzzing.
> (top of tree is 0776ce03b1348d39ba3035ea3ee3d268a42912ce)
Hum, but it doesn't really look ext4 related. Look:
> [ 93.602628]
> ===
1 - 100 of 498 matches
Mail list logo
