On Oct 25, 2014 9:11 PM, "Frederic Weisbecker" wrote:
>
> 2014-10-25 2:22 GMT+02:00 Andy Lutomirski :
> > Is there any good reason not to use vmalloc for x86_64 stacks?
> >
> > The tricky bits I've thought of are:
> >
> > - On any context switch, we probably need to probe the new stack
> >
On (10/25/14 17:26), Weijie Yang wrote:
> Date: Sat, 25 Oct 2014 17:26:31 +0800
> From: Weijie Yang
> To: 'Minchan Kim'
> Cc: 'Andrew Morton' , 'Dan Streetman'
> , 'Sergey Senozhatsky' ,
> 'Nitin Gupta' , 'Linux-MM' ,
> 'linux-kernel' , 'Weijie Yang'
>
> Subject: [PATCH 2/2] zram: avoid
On Sat, 25 Oct 2014 22:25:56 +0300 Timofey Titovets
wrote:
> Good time of day, people.
> I try to find 'mm' subsystem specific people and lists, but list
> linux-mm looks dead and mail archive look like deprecated.
> If i must to sent this message to another list or add CC people, let me know.
2014-10-25 2:22 GMT+02:00 Andy Lutomirski :
> Is there any good reason not to use vmalloc for x86_64 stacks?
>
> The tricky bits I've thought of are:
>
> - On any context switch, we probably need to probe the new stack
> before switching to it. That way, if it's going to fault due to an
>
[context for Linus]
Fuzzer has triggered deadlock in d_walk() with rename_lock taken twice.
AFAICS, the plausible scenario is
(child->d_flags & DCACHE_DENTRY_KILLED) ||
triggering while ascending to parent, on the pass with rename_lock already
held exclusive. In that
On Sun, Oct 26, 2014 at 03:06:08AM +, Al Viro wrote:
> > >From a quick reading of the code it simply isn't possible for d_walk to
> > take the lock twice short of memory corruption. And the fact that the
> > code has not changed in years seems to suggest it isn't the obvious
> > cause of
On Sat, Oct 25, 2014 at 08:01:41PM -0700, Eric W. Biederman wrote:
> Sasha Levin writes:
>
> > Hi all,
> >
> > While fuzzing with trinity inside a KVM tools guest running the latest -next
> > kernel, I've stumbled on the following spew:
>
> Weird. I took a quick look and I don't see any
overlayfs merge + leak fix for d_splice_alias() failure exits.
Please, pull from the usual place:
git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git for-linus
Shortlog:
Al Viro (5):
fix inode leaks on d_splice_alias() failure exits
overlayfs: don't hold ->i_mutex over
Sasha Levin writes:
> Hi all,
>
> While fuzzing with trinity inside a KVM tools guest running the latest -next
> kernel, I've stumbled on the following spew:
Weird. I took a quick look and I don't see any changes in d_walk that
in Al's tree or in Linus's kernel for years.
Has
On Sat, Oct 25, 2014 at 09:39:23PM -0400, Sasha Levin wrote:
> [ 6172.870045] trinity-c55/12752 is trying to acquire lock:
> [ 6172.870045] (rename_lock){+.+...}, at: d_walk
> (include/linux/spinlock.h:309 fs/dcache.c:1035)
> [ 6172.870045]
> [ 6172.870045] but task is already holding lock:
> [
On Sat, Oct 25, 2014 at 05:26:31PM +0800, Weijie Yang wrote:
> There is a rare NULL pointer bug in mem_used_total_show() in concurrent
> situation, like this:
> zram is not initialized, process A is a mem_used_total reader which runs
> periodicity, while process B try to init zram.
>
>
Hello,
On Sat, Oct 25, 2014 at 05:25:11PM +0800, Weijie Yang wrote:
> The commit 461a8eee6a ("zram: report maximum used memory") introduces a new
> knob "mem_used_max" in zram.stats sysfs, and wants to reset it via write 0
> to the sysfs interface.
>
> However, the current code cann't reset it
Hi all,
While fuzzing with trinity inside a KVM tools guest running the latest -next
kernel, I've stumbled on the following spew:
[ 6172.870045] =
[ 6172.870045] [ INFO: possible recursive locking detected ]
[ 6172.870045]
You have been awarded $280,000 by Siemens company. reply for details.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at
free_pi_state and exit_pi_state_list both clean up futex_pi_state's.
exit_pi_state_list takes the hb lock first, and most callers of
free_pi_state do too. requeue_pi didn't, which means free_pi_state can
free the pi_state out from under exit_pi_state_list. For example:
task A
On Sat, 25 Oct 2014, Thomas Gleixner wrote:
> > pi_state_free and exit_pi_state_list both clean up futex_pi_state's.
> > exit_pi_state_list takes the hb lock first, and most callers of
> > pi_state_free do too. requeue_pi didn't, which causes lots of problems.
>
> "causes lots of problems" is not
On Fri, Oct 24, 2014 at 12:37:41PM -0700, Nicolin Chen wrote:
> This patch simply adds a new DMATYPE for SAI which's included
> in i.MX6 Solo X.
>
> Signed-off-by: Nicolin Chen
Acked-by: Shawn Guo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a
On Oct 25, 2014 12:57 PM, "Nadav Amit" wrote:
>
>
> > On Oct 24, 2014, at 20:53, Andy Lutomirski wrote:
> >
> > On 10/24/2014 08:07 AM, Paolo Bonzini wrote:
> >> From: Nadav Amit
> >>
> >> Before changing rip (during jmp, call, ret, etc.) the target should be
> >> asserted
> >> to be canonical
Am 26.10.2014 um 01:16 schrieb Andy Lutomirski:
> On Sat, Oct 25, 2014 at 3:26 PM, Richard Weinberger
> wrote:
>> On Sat, Oct 25, 2014 at 2:22 AM, Andy Lutomirski wrote:
>>> Is there any good reason not to use vmalloc for x86_64 stacks?
>>>
>>> The tricky bits I've thought of are:
>>>
>>> - On
On Sat, Oct 25, 2014 at 3:26 PM, Richard Weinberger
wrote:
> On Sat, Oct 25, 2014 at 2:22 AM, Andy Lutomirski wrote:
>> Is there any good reason not to use vmalloc for x86_64 stacks?
>>
>> The tricky bits I've thought of are:
>>
>> - On any context switch, we probably need to probe the new
On 24.10.14 14:20, suravee.suthikulpa...@amd.com wrote:
> From: Suravee Suthikulpanit
>
> Initial revision of device tree for AMD Seattle platform
>
> Cc: Mark Rutland
> Cc: Will Deacon
> Cc: Catalin Marinas
> Cc: Rob Herring
> Signed-off-by: Suravee Suthikulpanit
> Signed-off-by: Thomas
From: Jiri Olsa
Fixing several sources config dependencies to allow
separate config builds.
This commit was originally created by Jiri Olsa in 2013. Minor changes
were needed to get it working one year later:
* Remove #ifdef directives related with GUI / TUI (because of code
changes in
The file Makefile.perf contained legacy build rules. It is replaced by
Makefile.kbuild which relies on Kbuild. Consequently, some minor
points need updates:
* The constant CONFIG_KBUILD can be removed
* The main Makefile wrapper now call Makefile.kbuild instead of
Makefile.perf
Signed-off-by:
On Sat, Oct 25, 2014 at 2:22 AM, Andy Lutomirski wrote:
> Is there any good reason not to use vmalloc for x86_64 stacks?
>
> The tricky bits I've thought of are:
>
> - On any context switch, we probably need to probe the new stack
> before switching to it. That way, if it's going to fault due
* Correctly rename internal makefile variables
* Remove makefiles in tools/perf/config which became empty and useless
* Remove builtin-cmds.h
* Remove arch/x86/Makefile
* Improve outputs of clean and install targets
* Remove creation of PERF-FEATURES file which is redundant with the
.config file
Remove NO_SLANG (replaced by CONFIG_LIBSLANG)
Remove HAVE_SLANG_SUPPORT from CFLAGS (replaced by CONFIG_LIBSLANG)
Remove NO_GTK2 (replaced by CONFIG_LIBGTK2 or CONFIG_GTK2)
Remove HAVE_GTK2_SUPPORT from CFLAGS (replaced by CONFIG_LIBGTK2)
Remove HAVE_GTK_INFO_BAR_SUPPORT from CFLAGS (replaced by
The variable CONFIG_ARCH and CONFIG_CROSS_COMPILE were added.
Signed-off-by: Alexis Berlemont
---
tools/perf/Kconfig | 24
tools/perf/Makefile.kbuild | 8
tools/perf/arch/x86/include/perf_regs.h | 8 +---
Remove NO_LIBELF (replaced by CONFIG_LIBELF)
Remove HAVE_LIBELF_SUPPORT (replaced by CONFIG_LIBELF)
Remove HAVE_LIBELF_MMAP_SUPPORT (replaced by CONFIG_LIBELF_MMAP)
Remove HAVE_LIBELF_GETPHDRNUM__SUPPORT (replaced by
CONFIG_LIBELF_GETPHDRNUM_)
Signed-off-by: Alexis Berlemont
---
Remove NO_LIBPERL (replaced by CONFIG_LIBPERL)
Remove NO_LIBPYTHON (replaced by CONFIG_LIBPYTHON)
Signed-off-by: Alexis Berlemont
---
tools/perf/builtin-script.c | 6 +++--
tools/perf/config/Makefile | 41 +
Remove NO_DEMANGLE (replaced by CONFIG_DEMANGLE)
Remove HAVE_LIBBFD_SUPPORT (replaced by CONFIG_LIBBFD)
Remove HAVE_CPLUS_DEMANGLE_SUPPORT (replaced by CONFIG_LIBIBERTY_ONLY)
Signed-off-by: Alexis Berlemont
---
tools/perf/Kconfig| 36 +--
Remove NO_LIBAUDIT (replaced by CONFIG_LIBAUDIT)
Remove HAVE_LIBAUDIT_SUPPORT from CFLAGS (replaced by CONFIG_LIBAUDIT)
Remove HAVE_TIMERFD_SUPPORT (replaced by CONFIG_TIMERFD)
Remove HAVE_ON_EXIT_SUPPORT (replaced by CONFIG_ON_EXIT)
Remove HAVE_BACKTRACE_SUPPORT (replaced by CONFIG_BACKTRACE)
* Remove NO_DWARF (replaced by CONFIG_LIBDWARF)
* Remove HAVE_DWARF_SUPPORT (replaced by CONFIG_LIBDWARF)
* Remove the useless variable PERF_HAVE_DWARF_REGS
* fix compilation issues if PERF_REGS is disabled
Signed-off-by: Alexis Berlemont
---
tools/perf/Kconfig | 59
Thanks to the python module kconfiglib, we were able to generate build
configurations. The set is, of course, not exhaustive but for each
option, all the possible states are tested. If, during development
step, a new symbol is added into the Kconfig file, the target
build-test will not fail
From: Jiri Olsa
Adding kbuild support into Makefile.kbuild. The 'legacy'
Makefile still stays untouched as it was.
It's possible to use kbuild by running 'make -f Makefile.kbuild'
with any option supported by 'legacy' Makefile.
We now have 2 config files:
'.config' - user configured setup
From: Jiri Olsa
Adding CONFIG_BUILTIN_* defines to govern builtin commands.
This will be useful for kbuild process switch.
Signed-off-by: Jiri Olsa
Cc: Arnaldo Carvalho de Melo
Cc: Peter Zijlstra
Cc: Ingo Molnar
Cc: Paul Mackerras
Cc: Corey Ashford
Cc: Frederic Weisbecker
Cc: Namhyung
In the scripts/Makefile.build, use KCONFIG_AUTOCONFIG to include a
custom path for the "auto.conf" file.
The "*conf" programs were modified so as to work with the environment
variable KCONFIG_AUTOCONFIG.
Signed-off-by: Alexis Berlemont
---
scripts/Makefile.build | 3 ++-
Hello,
Here is a proposal of perf's build process managed by Kbuild:
* The file Makefile.perf is replaced by Makefile.kbuild
* Makefile.kbuild generates a default .config file if none exists
(allyesconfig)
* Makefile.kbuild adapts the .config file according to the
features-check tests results
On Sun, 26 Oct 2014, Thomas Gleixner wrote:
> On Thu, 23 Oct 2014, Chris Friesen wrote:
> > Does the RT kernel just disallow this sort of algorithm?
>
> Yes. For a good reason. Let's add thread C
>
> A B C
> down_read(X)
> down_write(X)
>
On Thu, 23 Oct 2014, Chris Friesen wrote:
> I recently noticed that when CONFIG_PREEMPT_RT_FULL is enabled we the
> semantics change. From "include/linux/rwsem_rt.h":
>
> * Note that the semantics are different from the usual
> * Linux rw-sems, in PREEMPT_RT mode we do not allow
> * multiple
Hello,
I recently ran into an issue with the OF IRQ parsing code in the I2C core
(of_i2c_register_devices in drivers/i2c/i2c-core.c).
My DT contains the following nodes.
gpio1: gpio@e6051000 {
...
#interrupt-cells = <2>;
The bug referenced by the comment in this commit was not completely fixed in
GCC 4.8.2, as I mentioned in a thread back in February[1]. The conclusion at
that time was to make the quirk unconditional until the bug could be found and
fixed in GCC. Unfortunately, when I submitted the patch (commit
On 10/25/2014 04:55 PM, Eric W. Biederman wrote:
Hans de Bruin writes:
On 10/24/2014 08:18 PM, Eric W. Biederman wrote:
[...]
At this point I don't know enough to reproduce this.
What does /proc/mounts look like before you start dosemu?
bash-4.2$ cat /proc/mounts
rootfs / rootfs rw 0 0
Moderately recent ARM interrupt controllers can use a "split mode" EOI,
where instead of just using a single write to notify the controller of
the end of interrupt, uses the following:
- priority-drop: the interrupt is still active, but other interrupts can
now be taken
- deactivate: the
There is a number of cases where a kernel subsystem may want to
introspect the state of an interrupt at the irqchip level:
- When a peripheral is shared between virtual machines, its interrupt
state becomes part of the guest's state, and must be switched accordingly.
KVM on arm/arm64 requires
So far, GICv2 has been used in with EOImode == 0. The effect of this
mode is to perform the priority drop and the deactivation of the
interrupt at the same time.
While this works perfectly for Linux (we only have a single priority),
it causes issues when an interrupt is forwarded to a guest, and
Add the required hooks for the internal state of an interrupt
to be exposed to other subsystems.
Signed-off-by: Marc Zyngier
---
drivers/irqchip/irq-gic-v3.c | 78
1 file changed, 65 insertions(+), 13 deletions(-)
diff --git
Add the required hooks for the internal state of an interrupt
to be exposed to other subsystems.
Signed-off-by: Marc Zyngier
---
drivers/irqchip/irq-gic.c | 70 +++
1 file changed, 65 insertions(+), 5 deletions(-)
diff --git
Moderately recent ARM interrupt controllers can use a "split mode" EOI,
where instead of just using a single write to notify the controller of
the end of interrupt, uses the following:
- priority-drop: the interrupt is still active, but other interrupts can
now be taken
- deactivate: the
So far, GICv3 has been used in with EOImode == 0. The effect of this
mode is to perform the priority drop and the deactivation of the
interrupt at the same time.
While this works perfectly for Linux (we only have a single priority),
it causes issues when an interrupt is forwarded to a guest, and
Despite Linux offering a rather fine grained control over the life
cycle of an interrupt, there is a few cases where it would be very
useful to snapshot (or even set) the internal state of the interrupt
controller for a given interrupt line:
- With KVM, a device shared between VMs must have its
On Fri, Oct 24, 2014 at 05:57:24PM -0400, Rob Clark wrote:
> Oh, you are only looking at the one in mdp4_kms_init(), which could
> possibly be a simple regulator_get(). Look instead at the ones in
> hdmi_init(), where I need to know whether to defer or not. At one
No, I saw that - looking at
On Fri, 24 Oct 2014, Borislav Petkov wrote:
> On Thu, Oct 23, 2014 at 04:43:03PM -0700, Andy Lutomirski wrote:
> > Presumably the actual failure is a #GP when trying to do the rdtsc. If
> > so, wouldn't a better fix be to make that rdtsc check cpuid first? Can
> > we easily check cpuid that early?
Hi!
> >> Oh, you mean that #!/usr/bin/make -f would turn into /usr/bin/make
> >> /dev/fd/3? That could be interesting, although I can imagine it
> >> breaking things, especially if /dev/fd/3 isn't set up like that, e.g.
> >> early in boot.
> >
> > Sigh... What I mean is that fexecve(fd, ...)
This patch switch the ppc arch to use the generic RCU based
gup implementation.
Signed-off-by: Aneesh Kumar K.V
---
arch/powerpc/Kconfig | 1 +
arch/powerpc/include/asm/hugetlb.h | 8 +-
arch/powerpc/include/asm/page.h | 3 +-
Update generic gup implementation with powerpc specific details.
On powerpc at pmd level we can have hugepte, normal pmd pointer
or a pointer to the hugepage directory.
Signed-off-by: Aneesh Kumar K.V
---
Changes from V3:
* Explain pgd_huge, also move the definition to linux/hugetlb.h.
Both
On Fri, Oct 24, 2014 at 09:33:33PM -0700, Jay Vosburgh wrote:
> Paul E. McKenney wrote:
>
> >On Fri, Oct 24, 2014 at 05:20:48PM -0700, Jay Vosburgh wrote:
> >> Paul E. McKenney wrote:
> >>
> >> >On Fri, Oct 24, 2014 at 03:59:31PM -0700, Paul E. McKenney wrote:
> >> [...]
> >> >> Hmmm... It
On Oct 24, 2014 7:38 PM, "H. Peter Anvin" wrote:
>
> On 10/24/2014 05:22 PM, Andy Lutomirski wrote:
> > Is there any good reason not to use vmalloc for x86_64 stacks?
>
> Additional TLB pressure if anything else.
I wonder how much this matters. It certainly helps on context
switches if the new
On Fri, 24 Oct 2014, Ley Foon Tan wrote:
> +#ifndef _ASM_NIOS2_TIMEX_H
> +#define _ASM_NIOS2_TIMEX_H
> +
> +typedef unsigned long cycles_t;
> +
> +extern cycles_t get_cycles(void);
> +
> +#define ARCH_HAS_READ_CURRENT_TIMER
Why does NIOS need that? Does it have a hardware implementation
dependent
From: Geert Uytterhoeven
Date: Thu, 23 Oct 2014 10:25:53 +0200
> drivers/net/ethernet/apm/xgene/xgene_enet_sgmac.c: In function
> ‘xgene_enet_ecc_init’:
> drivers/net/ethernet/apm/xgene/xgene_enet_sgmac.c:126: warning: ‘data’ may be
> used uninitialized in this function
>
> Depending on the
Hi everyone
This looks good to me
Greg, please pull it into your tree
Thank you
25.10.2014, 16:27, "Alexander Stein" :
> Adjust the bulk message timeout to the other ones (1000ms). Otherwise the
> following dmesg errors can be seen on a Raspberry Pi:
> [ 31.492386] Failed to read 1-wire data
David Miller writes:
> Hey guys, was looking over the generic GUP while working on a sparc64
> issue and I noticed that you guys do speculative page gets, and after
> talking with Johannes Weiner (CC:'d) about this we don't see how it
> could be necessary.
>
> If interrupts are disabled during
On Sat, Oct 25, 2014 at 12:22:32AM +0100, Paul McQuade wrote:
> ERROR: that open brace { should be on the previous line
patch is corrupt.
thanks
sudip
>
> Signed-off-by: Paul McQuade
> ---
> drivers/staging/rtl8723au/core/rtw_ap.c | 137
> ++--
> 1 file changed,
B1;2802;0cOn Fri, 24 Oct 2014, Ley Foon Tan wrote:
> +#ifndef CONFIG_SMP
> +static inline int
> +futex_atomic_op_inuser(int encoded_op, u32 __user *uaddr)
If we add this to the generic code we want to have a proper docbook
comment describing the function.
> +{
> + int op = (encoded_op >> 28)
2014-10-25 23:30 GMT+03:00 One Thousand Gnomes :
> On Fri, 24 Oct 2014 20:50:46 -0400
> Sasha Levin wrote:
>
>> On 10/24/2014 06:22 PM, H. Peter Anvin wrote:
>> >> By the principle of least surprise, I would expect "__u32 >> N", where
>> >> > N >= 32 to return zero instead of random garbage. For
On 10/24/2014 08:18 PM, Eric W. Biederman wrote:
Hans de Bruin writes:
On 10/19/2014 07:32 PM, Hans de Bruin wrote:
On 10/15/2014 10:00 PM, Hans de Bruin wrote:
After playing an old dos game i am missing files on my nfsroot installed
laptop. Which one, wel /bin/ls is at least one of them.
On Sat, 25 Oct 2014, Thomas Gleixner wrote:
> Can you please explain detailed how this "priority drop" mode
> works?
And I mean how it works from all aspects, not only from handling the
interrupt itself.
Thanks,
tglx
--
To unsubscribe from this list: send the line "unsubscribe
Hi Paul,
Finding earlier reference to increasing RCU fanout leaf for the purpose
of "decrease[ing] cache-miss overhead for large systems", would your
suggestion be to increase the value to the next hierarchy core-count
above 16?
If we have say 32 interconnected 48-core servers; 3 sockets of
On Thu, Oct 09, 2014 at 11:39:41PM +0200, Hauke Mehrtens wrote:
> Commit 2101e533f41a ("bcma: register bcma as device tree driver")
> introduces a hard dependency on OF_ADDRESS into the bcma driver.
> OF_ADDRESS is specifically disabled for the sparc architecture.
> This results in the following
On Fri, 24 Oct 2014 20:50:46 -0400
Sasha Levin wrote:
> On 10/24/2014 06:22 PM, H. Peter Anvin wrote:
> >> By the principle of least surprise, I would expect "__u32 >> N", where
> >> > N >= 32 to return zero instead of random garbage. For N < 32 it will
> >> > return progressively smaller
Hans de Bruin writes:
> On 10/24/2014 08:18 PM, Eric W. Biederman wrote:
[...]
>> At this point I don't know enough to reproduce this.
>> What does /proc/mounts look like before you start dosemu?
>
> bash-4.2$ cat /proc/mounts
> rootfs / rootfs rw 0 0
> 10.10.0.1:/nfs/root/psion_14.1 / nfs
>
On Sat, 25 Oct 2014, Marc Zyngier wrote:
@@ -330,6 +330,7 @@ struct irq_chip {
void(*irq_mask)(struct irq_data *data);
void(*irq_mask_ack)(struct irq_data *data);
void(*irq_unmask)(struct irq_data *data);
+ void
* Andy Lutomirski wrote:
> Is there any good reason not to use vmalloc for x86_64 stacks?
In addition to what hpa mentioned, __pa()/__va() on-kstack DMA
gets tricky, for legacy drivers. (Not sure how many of these are
left though.)
Thanks,
Ingo
--
To unsubscribe from this list:
I have a device use 3-wire spi which are CS,SCK,and a DATA for
read/write.( maybe a.s.k.a SISO)
The command format like as p.18 in
www .newhavendisplay .com/app_notes/NV3035C.pdf
The spi-gpio can't register miso and mosi for same GPIO pin.
Also I traced SPI-3WIRE flag it seems only support half
On 09/10/14 21:05, Jonathan Cameron wrote:
> On 21/09/14 13:17, Jonathan Cameron wrote:
>> On 16/09/14 09:58, Naveen Krishna Chatradhi wrote:
>>> Changes since v1:
>>> 1. Rebased on top of togreg branch of IIO git.
>>>
>>> This patch set does the following
>>> 1. Use the syscon and Regmap API
On 22/10/14 15:13, Ivan T. Ivanov wrote:
> The current ADC is peripheral of Qualcomm SPMI PMIC chips. It has
> 16 bits resolution and register space inside PMIC accessible across
> SPMI bus.
>
> The driver registers itself through IIO interface.
>
> Signed-off-by: Ivan T. Ivanov
Applied to the
On 24 October 2014 18:39, Dmitry Torokhov wrote:
> On Fri, Oct 24, 2014 at 11:53:05AM +0200, Ulf Hansson wrote:
>> On 23 October 2014 16:37, Grygorii Strashko wrote:
>> > Hi Ulf,
>> >
>> > On 10/23/2014 11:11 AM, Ulf Hansson wrote:
>> >> On 22 October 2014 17:44, Geert Uytterhoeven wrote:
>>
The following patch adds a function to return tv_sec portion of
ktime_get_ts64() function in order to have a function that returns
seconds as 64-bit integers instead of 32-bit integers to address the
y2038 problem.
Since we are interested only in the seconds portion of ktime_get_ts64()
and
On Sat, Oct 25, 2014 at 10:49 PM, Hartmut Knaack wrote:
> Jonathan Cameron schrieb am 25.10.2014 20:55:
>> On 09/10/14 13:39, Daniel Baluta wrote:
>>> We need a way to store events generated by iio_dummy_evgen module,
>>> in order to correctly process IRQs in iio_simple_dummy_events.
>>>
>>> For
> On Oct 24, 2014, at 20:53, Andy Lutomirski wrote:
>
> On 10/24/2014 08:07 AM, Paolo Bonzini wrote:
>> From: Nadav Amit
>>
>> Before changing rip (during jmp, call, ret, etc.) the target should be
>> asserted
>> to be canonical one, as real CPUs do. During sysret, both target rsp and rip
HOn 25/10/14 20:49, Hartmut Knaack wrote:
> Jonathan Cameron schrieb am 25.10.2014 20:55:
>> On 09/10/14 13:39, Daniel Baluta wrote:
>>> We need a way to store events generated by iio_dummy_evgen module,
>>> in order to correctly process IRQs in iio_simple_dummy_events.
>>>
>>> For the moment, we
On Sat, Oct 25, 2014 at 11:53:52AM +0200, Miklos Szeredi wrote:
> Yes, but it's not about race with copy-up (which the ovl_path_upper()
> protects against), but race of two fsync calls with each other. If
> there's no synchronization between them, then that od->upperfile does
> indeed count as
On Fri, Oct 24, 2014 at 09:24:45AM +0200, Miklos Szeredi wrote:
> The reason I didn't do your "fix" is that it
>
> - adds more lines than it takes,
>
> - I wasn't sure at all if the lockless access is actually correct
> without the ACCESS_ONCE and all the memory barrier magic that might be
>
Jonathan Cameron schrieb am 25.10.2014 20:55:
> On 09/10/14 13:39, Daniel Baluta wrote:
>> We need a way to store events generated by iio_dummy_evgen module,
>> in order to correctly process IRQs in iio_simple_dummy_events.
>>
>> For the moment, we add two registers:
>>
>> * id_reg - ID register,
On Fri, 2014-10-24 15:38:46 -0700, Dmitry Torokhov
wrote:
> I believe the intent of the code was to drop oldest bytes from the queue,
> not the latest if we drop one byte and both latest and some oldest of we
> are dropping more than one.
>
> Signed-off-by: Dmitry Torokhov
> ---
>
On 10/24/14 21:51, Martin K. Petersen wrote:
"Michael" == Michael L Semon writes:
Michael> There was nothing regarding integrity in /sys/block/sda. I was
Michael> under the impression that both bio integrity and T10 checksums
Michael> require hardware support from good hardware, so the
On 10/25/2014 07:01 AM, Andrew Lunn wrote:
Here is another naming option:
em1dsa0-virtual-0
I prefer this over isa.
However, i think there should be some sort of separator between the
network device name and dsa.
Fine with me. Any preference ? Note that '-' is not permitted.
Guenter
--
[+CC: Felipe ]
On Sat, Oct 25, 2014 at 09:28:36AM +0200, Romain Perier wrote:
> Hi Johan,
>
> If that's still possible to do these changes, I am opened to suggestions.
Before v3.18 comes out, we can always change it with a follow-up patch.
> 2014-10-23 11:53 GMT+02:00 Johan Hovold :
> > [ +CC:
On Sat, 25 Oct 2014, Thomas Gleixner wrote:
Bah, hit send way too fast :)
> On Sat, 25 Oct 2014, Marc Zyngier wrote:
> > +int irq_get_irqchip_state(unsigned int irq, int state)
get_state(state) does not make sense. get_state(which) probably more
so. And 'which' wants to be an enum btw.
> > +
You have been sanction a donation. Reply for info.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
There is a rare NULL pointer bug in mem_used_total_show() in concurrent
situation, like this:
zram is not initialized, process A is a mem_used_total reader which runs
periodicity, while process B try to init zram.
process A process B
access meta, get a NULL
The commit 461a8eee6a ("zram: report maximum used memory") introduces a new
knob "mem_used_max" in zram.stats sysfs, and wants to reset it via write 0
to the sysfs interface.
However, the current code cann't reset it correctly, so let's fix it.
Signed-off-by: Weijie Yang
---
On Sat, 25 Oct 2014, Marc Zyngier wrote:
> +int irq_get_irqchip_state(unsigned int irq, int state)
> +{
> + struct irq_desc *desc;
> + struct irq_data *data;
> + struct irq_chip *chip;
> + int val;
> +
> + desc = irq_to_desc(irq);
> + if (!desc)
> + return
On 20.10.2014 10:04, Antoine Tenart wrote:
Linus, Sebastian,
As discussed earlier this year[1], this series introduce helpers for group based
pinctrl drivers:
- of_pinctrl_utils_read_function(): reads the function name of a
specified node, and gets the number of groups it should be
On Thu, 23 Oct 2014, Brian Silverman wrote:
First of all. Nice catch!
> pi_state_free and exit_pi_state_list both clean up futex_pi_state's.
> exit_pi_state_list takes the hb lock first, and most callers of
> pi_state_free do too. requeue_pi didn't, which causes lots of problems.
"causes lots
On 25/10/14 20:19, Daniel Baluta wrote:
> On Sat, Oct 25, 2014 at 10:01 PM, Jonathan Cameron wrote:
>> On 09/10/14 13:39, Daniel Baluta wrote:
>>> This channel will be used for exposing information about
>>> activity composite sensors. Activities supported so far:
>>> * running
>>> *
On 09/10/14 13:39, Daniel Baluta wrote:
> Adds support for the new channel types in the dummy driver:
> * a new channel IIO_ACTIVITY
> * two state transition events (running and walking)
> * a new channel IIO_STEPS and support for reading and writing
> pedometer step counter
> * step
Hi Fabian,
> use clkoff_cp for hci_cp_read_clock_offset instead of cp
> (already defined above).
>
> Suggested-by: Marcel Holtmann
> Signed-off-by: Fabian Frederick
> ---
> V2: use clkoff_cp instead of cpr (suggested by Marcel Holtmann)
>
> net/bluetooth/hci_conn.c | 7 ---
> 1 file
Good time of day, people.
I try to find 'mm' subsystem specific people and lists, but list
linux-mm looks dead and mail archive look like deprecated.
If i must to sent this message to another list or add CC people, let me know.
If questions are already asked (i can't find activity before), feel
On 09/10/14 13:39, Daniel Baluta wrote:
> From: Irina Tirdea
>
> Some devices need the height of the user to compute various
> parameters. One of this devices is Freescale's MMA9553L
> (http://www.freescale.com/files/sensors/doc/ref_manual/MMA9553LSWRM.pdf)
> that needs the height of the user to
Hi Pantelis!
On Fri, Oct 24, 2014 at 12:20:53PM +0300, Pantelis Antoniou wrote:
> Hi Stefan, Allan,
>
> Sorry, haven’t had a chance to review all this yet; will do so in the weekend.
> Just wanted to pop in and comment on a few things.
>
> > On Oct 24, 2014, at 10:00 AM, Steffen Trumtrar
> >
1 - 100 of 364 matches
Mail list logo
