This patch adds the cooling device APIs to the
new thermal framework. The register/unregister
APIs stay the same. Below are some minimal
changes:
* Use DEVICE_ATTR_RO/RW macros
* Add 'struct idr idr' to struct thermal_cooling_device
* Tidy up the error handling paths in register API
* Use therm
This patch adds Documentation for the new APIs
introduced in this patch set. The documentation
also has a model sysfs structure for reference.
Signed-off-by: Durgadoss R
---
Documentation/thermal/sysfs-api2.txt | 240 ++
1 file changed, 240 insertions(+)
create
This patch adds Documentation for ABI's introduced
for thermal subsystem (under /sys/class/thermal/).
Signed-off-by: Durgadoss R
---
Documentation/ABI/testing/sysfs-class-thermal | 161 +
1 file changed, 161 insertions(+)
create mode 100644 Documentation/ABI/testing/sys
From: "zhangwei(Jovi)"
Support multi-buffer on uprobe-based dynamic events by
using ftrace_event_file.
This patch is based kprobe-based dynamic events multibuffer
support work initially, commited by Masami(commit 41a7dd420c),
but revised as below:
Oleg changed the kprobe-based multibuffer desig
A single uprobe event might serve different users like ftrace and
perf. And this is especially important for upcoming multi buffer
support. But in this case it'll fetch (same) data from userspace
multiple times. So move it to the beginning of the dispatcher
function and reuse it for each users.
The uprobe_{trace,perf}_print functions are misnomers since what they
do is not printing. There's also a real print function named
print_uprobe_event() so they'll only increase confusion IMHO.
Rename them with double underscores to follow convention of kprobe.
Cc: Oleg Nesterov
Cc: Srikar Drona
Add support for event triggering to uprobes. This is same as kprobes
support added by Tom (plus cleanup by Steven).
Cc: Masami Hiramatsu
Cc: Oleg Nesterov
Cc: Srikar Dronamraju
Cc: zhangwei(Jovi)
Cc: Tom Zanussi
Signed-off-by: Namhyung Kim
---
kernel/trace/trace_uprobe.c | 6 --
1 file
Hello,
(Resending with LKML CC'ed)
This patchset tries to add support for recent multi buffer and event
trigger changes to uprobes. The multi buffer support patch is an
updated version of Zovi's previous patch v6 [1].
Zovi, please tell me if you have any update and/or issues with this.
Masami a
It seems there's no reason to prevent mixed used of ftrace and perf
for a single uprobe event. At least the kprobes already support it.
Cc: Masami Hiramatsu
Cc: Oleg Nesterov
Cc: Srikar Dronamraju
Cc: zhangwei(Jovi)
Signed-off-by: Namhyung Kim
---
kernel/trace/trace_uprobe.c | 9 +
Arm64 supports 32-bit mode(AArch32) and 64-bit mode(AArch64).
To enable audit on arm64, we want to use lib/audit.c and re-work it
to support compat system calls as well without copying it under
arch sub-directory.
So this patch is mandatory for my "system call audit support for arm64"
patch. Pleas
lib/audit.c provides a generic definition for auditing system calls.
This patch extends it for compat syscall support on bi-architectures
(32/64-bit) by adding lib/compat_audit.c when CONFIG_COMPAT enabled.
Each architecture that wants to use this must define audit_is_compat()
in asm/audit.h.
Sig
Each asm-generic/audit_xx.h defines a set of system calls for respective
audit permssion class (read, write, change attribute or exec).
This patch changes two entries:
1) fchown in audit_change_attr.h
Make fchown included by its own because in asm-generic/unistd.h, for example,
fchown always e
This patch adds AUDIT_ARCH_* identifiers for arm64(AArch64), and
makes CONFIG_AUDITSYSCALL selectable.
Signed-off-by: AKASHI Takahiro
---
include/uapi/linux/audit.h |2 ++
init/Kconfig |2 +-
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/include/uapi/linux/a
This patchset adds system call audit support on arm64.
Both 32-bit (AUIDT_ARCH_ARM[EB]) and 64-bit tasks (AUDIT_ARCH_AARCH64[EB])
are supported, but presuming 32-LE on 64-LE or 32-BE on 64-BE.
There are some prerequisites for this patch to work correctly:
* "generic compat system call audit suppor
Generic audit code also support compat system calls now.
This patch adds a small piece of architecture dependent code.
Signed-off-by: AKASHI Takahiro
---
arch/arm64/include/asm/audit.h | 20
arch/arm64/include/asm/syscall.h | 10 ++
2 files changed, 30 insertio
generic compat sycall audit (lib/compat_audit.c) requires unistd_32.h
for __NR_xyx compat syscall numbers. This is a different file from unistd32.h
on arm64 and so it must be generated from unistd32.h.
Signed-off-by: AKASHI Takahiro
---
arch/arm64/Makefile |4
arch/arm64
On AArch64, audit can be enabled with CONFIG_AUDIT_GENERIC.
Most of audit features are implemented in generic way. This patch
adds a small piece of architecture dependent code.
syscall_get_arch(), which is used in seccomp, should just return
AUDIT_ARCH_*.
Signed-off-by: AKASHI Takahiro
---
arch/
This patch adds auditing functions on entry to or exit from
every system call invocation.
Signed-off-by: AKASHI Takahiro
---
arch/arm64/include/asm/thread_info.h |1 +
arch/arm64/kernel/entry.S|3 +++
arch/arm64/kernel/ptrace.c | 12
3 files changed,
This macro is used mainly for audit to record system call's results, but
may also be used in test_kprobes.c.
Signed-off-by: AKASHI Takahiro
---
arch/arm64/include/asm/ptrace.h |5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm64/include/asm/ptrace.h b/arch/arm64/include/asm/ptr
On Thu, 2014-01-16 at 21:27 -0800, H. Peter Anvin wrote:
> However, I would also like support for the context extensions, but I'm
> not knowledgeable enough to describe the semantics accurately. Would
> anyone be willing to file a ticket describing how the context extension
> works well enough th
Hi All,
Any updates on my reply, Any more info is required.
Can this be pulled into the kernel tree?
Thanks & Regards,
Sohny
On Monday 13 January 2014 02:19 PM, sohny thomas wrote:
On Friday 10 January 2014 10:46 PM, Hannes Frederic Sowa wrote:
On Fri, Jan 10, 2014 at 05:33:08PM +0100, Nicol
GFP_ATOMIC is not a single gfp flag, but a macro which expands to the other
flags and LACK of __GFP_WAIT flag. To check if caller wanted to perform an
atomic allocation, the code must test __GFP_WAIT flag presence. This patch
fixes the issue introduced in v3.5-rc1
CC: sta...@vger.kernel.org
Signed
GFP_ATOMIC is not a single gfp flag, but a macro which expands to the other
flags and LACK of __GFP_WAIT flag. To check if caller wanted to perform an
atomic allocation, the code must test __GFP_WAIT flag presence.
Signed-off-by: Marek Szyprowski
---
.../lustre/include/linux/libcfs/libcfs_privat
GFP_ATOMIC is not a single gfp flag, but a macro which expands to the other
flags and LACK of __GFP_WAIT flag. To check if caller wanted to perform an
atomic allocation, the code must test __GFP_WAIT flag presence. This patch
fixes the issue introduced in v3.6-rc5
Signed-off-by: Marek Szyprowski
driver or client application.
Signed-off-by: Jonas Jensen
---
Notes:
Changes since v15:
1. rebase drivers/dma/Kconfig to next-20140117
Applies to next-20140117
.../devicetree/bindings/dma/moxa,moxart-dma.txt| 45 ++
drivers/dma/Kconfig| 8
GFP_ATOMIC is not a single gfp flag, but a macro which expands to the other
flags and LACK of __GFP_WAIT flag. To check if caller wanted to perform an
atomic allocation, the code must test __GFP_WAIT flag presence.
Signed-off-by: Marek Szyprowski
---
arch/cris/arch-v32/drivers/cryptocop.c |2
On Thu, Jan 16, 2014 at 03:22:12PM -0800, David Rientjes wrote:
> On Thu, 16 Jan 2014, Mel Gorman wrote:
>
> > diff --git a/mm/vmstat.c b/mm/vmstat.c
> > index 7249614..def5dd2 100644
> > --- a/mm/vmstat.c
> > +++ b/mm/vmstat.c
> > @@ -851,12 +851,14 @@ const char * const vmstat_text[] = {
> >
On Thu, Jan 16, 2014 at 10:50 PM, Jiri Kosina wrote:
> On Wed, 8 Jan 2014, Benjamin Tissoires wrote:
>
>> From: Benjamin Tisssoires
>>
>> This fix (not very clean though) should fix the long time USB3
>> issue that was spotted last year. The rational has been given by
>> Hans de Goede:
>
> Man th
Hi Will,
Some more thoughts below
On 16 January 2014 14:47, Jean Pihet wrote:
> Will,
>
> On 16 January 2014 13:57, Will Deacon wrote:
>> On Thu, Jan 16, 2014 at 12:26:53PM +, Jean Pihet wrote:
>>> On 16 January 2014 12:56, Will Deacon wrote:
>>> > In your previous series, compat backtraci
Hi,
I have been debugging a NULL pointer issue with perf stat unit/scale code
and in the process I ran into what appeared like a double-free issue reported
by glibc. It took me a while to realize that it was because of memory corruption
caused by a recent change in how evsel are freed.
My test ca
The cpu parameter passed to idle_balance is not needed as it could
be retrieved from the struct rq.
Signed-off-by: Daniel Lezcano
---
kernel/sched/core.c |2 +-
kernel/sched/fair.c |3 ++-
kernel/sched/sched.h |2 +-
3 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/ke
The scheduler main function 'schedule()' checks if there are no more tasks
on the runqueue. Then it checks if a task should be pulled in the current
runqueue in idle_balance() assuming it will go to idle otherwise.
But the idle_balance() releases the rq->lock in order to lookup in the sched
domain
The idle_balance modifies the idle_stamp field of the rq, making this
information to be shared across core.c and fair.c. As we can know if the
cpu is going to idle or not with the previous patch, let's encapsulate the
idle_stamp information in core.c by moving it up to the caller. The
idle_balance
With the previous patch, we have no ambiguity on going to idle. So we can pick
directly the idle task instead of looking up all the domains which will in any
case return no task except the idle_task.
Signed-off-by: Daniel Lezcano
---
kernel/sched/core.c | 43 ++
On Thu, Jan 16, 2014 at 09:12:14PM -0800, Andrew Morton wrote:
> On Thu, 16 Jan 2014 23:57:51 -0500 Steven Rostedt wrote:
>
> > When PROVE_LOCKING and PREEMPT is configured, the preempt state
> > tracking is active. Testing this out, I added a module that did the
> > following:
>
> So I assume y
If we load the null_blk module with bs=8k we get following oops:
[ 3819.812190] BUG: unable to handle kernel NULL pointer dereference at
0008
[ 3819.812387] IP: [] create_empty_buffers+0x28/0xaf
[ 3819.812527] PGD 219244067 PUD 215a06067 PMD 0
[ 3819.812640] Oops: [#1] SMP
[ 3819
On Thu 16-01-14 14:49:25, David Rientjes wrote:
> On Thu, 16 Jan 2014, Michal Hocko wrote:
>
> > > When two threads have the same badness score, it's preferable to kill the
> > > thread group leader so that the actual process name is printed to the
> > > kernel log rather than the thread group n
From: "Lad, Prabhakar"
clk_set_rate(), clk_prepare_enable() functions can fail, so check the return
values to avoid surprises.
Signed-off-by: Lad, Prabhakar
---
drivers/media/i2c/mt9p031.c | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/drivers/media/i2c/mt9p
On Thu, Jan 16, 2014 at 09:27:08PM -0800, H. Peter Anvin wrote:
> I have filed gcc tickets asking for direct support in gcc for some
> sparse extensions that we use heavily in the kernel:
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59850
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59851
>
>
On Fri, Jan 17, 2014 at 09:33:16AM +0100, Johannes Berg wrote:
> On Thu, 2014-01-16 at 21:27 -0800, H. Peter Anvin wrote:
>
> > However, I would also like support for the context extensions, but I'm
> > not knowledgeable enough to describe the semantics accurately. Would
> > anyone be willing to
From: "Lad, Prabhakar"
clk_set_rate(), clk_prepare_enable() functions can fail, so check the return
values to avoid surprises.
Signed-off-by: Lad, Prabhakar
---
drivers/media/i2c/mt9v032.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/media/i2c/mt9v03
Hi
While running LTP hugeltb tests on freescale powerpc board, I'm getting
[ 7253.637591] BUG: using smp_processor_id() in preemptible [ ]
code: hugemmap01/9048
[ 7253.637601] caller is free_hugepd_range.constprop.25+0x88/0x1a8
[ 7253.637605] CPU: 1 PID: 9048 Comm: hugemmap01 Not
This adds support for advertising the presence of ARMv8 Crypto
Extensions in the Aarch32 execution state to 32-bit ELF binaries
running in 32-bit compat mode under the arm64 kernel.
Signed-off-by: Ard Biesheuvel
---
arch/arm64/include/asm/hwcap.h | 6 ++
arch/arm64/kernel/setup.c | 32
Add ELF_HWCAP2 to the set of auxv entries that is passed to
a 32-bit ELF program running in 32-bit compat mode under a
64-bit kernel.
Signed-off-by: Ard Biesheuvel
---
fs/compat_binfmt_elf.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/fs/compat_binfmt_elf.c b/fs/compat_binfmt_elf.c
This enables AT_HWCAP2 for ARM. The generic support for this
new ELF auxv entry was added in commit 2171364d1a9 (powerpc:
Add HWCAP2 aux entry)
Signed-off-by: Ard Biesheuvel
---
arch/arm/include/asm/hwcap.h | 3 ++-
arch/arm/include/uapi/asm/hwcap.h | 4
arch/arm/kernel/setup.c
Signed-off-by: Alexander Gordeev
---
Documentation/PCI/MSI-HOWTO.txt | 23 ---
1 files changed, 20 insertions(+), 3 deletions(-)
diff --git a/Documentation/PCI/MSI-HOWTO.txt b/Documentation/PCI/MSI-HOWTO.txt
index a8d0100..3c3080e 100644
--- a/Documentation/PCI/MSI-HOWTO.tx
On 16 January 2014 23:45, Mark Brown wrote:
> On Thu, Jan 16, 2014 at 09:22:40AM -0800, Greg KH wrote:
>> On Thu, Jan 16, 2014 at 05:08:14PM +, Mark Brown wrote:
>
>> > No, the issue is happening because the drivers are registering things
>> > at module load time and not at device instantiatio
Add support for the ELF auxv entry AT_HWCAP2 when running 32-bit
ELF binaries in compat mode.
Signed-off-by: Ard Biesheuvel
---
arch/arm64/include/asm/hwcap.h | 3 ++-
arch/arm64/kernel/setup.c | 1 +
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/include/asm/hwcap
This allocates feature bits 0-4 in HWCAP2 for the crypto and CRC
extensions introduced in ARMv8.
Signed-off-by: Ard Biesheuvel
---
arch/arm/include/uapi/asm/hwcap.h | 5 +
arch/arm/kernel/setup.c | 5 +
2 files changed, 10 insertions(+)
diff --git a/arch/arm/include/uapi/asm/h
This series is a followup to the patch that was recently merged by Catalin that
allocates hwcaps bits for CRC and Crypto Extensions instructions so userland can
discover whether the current CPU has any of those capabilities.
Patch #1 enables ARM support for the ELF_HWCAP2/AT_HWCAP2 ELF auxv entry
This update obsoletes pci_enable_msi_block() function
in favor of pci_enable_msi_range().
Signed-off-by: Alexander Gordeev
---
drivers/pci/msi.c | 17 +++--
include/linux/pci.h |7 ++-
2 files changed, 17 insertions(+), 7 deletions(-)
diff --git a/drivers/pci/msi.c b/dri
On 17/01/2014 03:59, Bo Shen :
> In sama5d3 SoC, there are 16 endpoints. As the USBA_NR_ENDPOINTS
> is only 7. So, fix it for sama5d3 SoC using the udc->num_ep.
>
> Signed-off-by: Bo Shen
Acked-by: Nicolas Ferre
> ---
>
> drivers/usb/gadget/atmel_usba_udc.c | 2 +-
> 1 file changed, 1 insert
On 17/01/2014 03:59, Bo Shen :
> When the SoC is earlier than sama5d3 SoC, which have the same number
> endpoints and DMAs. However for sama5d3 SoC, it has different number
> for endpoints and DMAs. So, define USBA_NR_DMAs for DMA channels
>
> Signed-off-by: Bo Shen
Acked-by: Nicolas Ferre
> -
Howdy all,
I meet following panic when I booting my HP Compad Elite 8300 Elite SFF
desktop.
[call trace here:]
[0.569993] Kernel panic - not syncing: VFS: Unable to mount root fs on
unknown-block(0,0)
[0.578269] CPU: 1 PID: 1 Comm: swapper/0 Tainted: GW3.13.0-rc8
#1
[0.58
On 01/17/2014 05:23 PM, Nikita Yushchenko wrote:
Hi
While running LTP hugeltb tests on freescale powerpc board, I'm getting
[ 7253.637591] BUG: using smp_processor_id() in preemptible [ ]
code: hugemmap01/9048
[ 7253.637601] caller is free_hugepd_range.constprop.25+0x88/0x1a8
[
Now disabling kmemleak is an irreversible operation, but sometimes
we may need to re-enable kmemleak at runtime. So add a knob to enable
kmemleak at runtime:
echo on > /sys/kernel/debug/kmemleak
Signed-off-by: Jianguo Wu
---
Documentation/kmemleak.txt |3 ++-
mm/kmemleak.c | 3
On Fri, 2014-01-17 at 17:34 +0800, Madper Xie wrote:
> I meet following panic when I booting my HP Compad Elite 8300 Elite SFF
> desktop.
>
> [call trace here:]
> [0.569993] Kernel panic - not syncing: VFS: Unable to mount root fs on
> unknown-block(0,0)
> [0.578269] CPU: 1 PID: 1 Comm: s
Many qdiscs can queue a packet for a long time, this will lead an issue
with zerocopy skb. It means the frags will not be orphaned in an expected
short time, this breaks the assumption that virtio-net will transmit the
packet in time.
So if guest packets were queued through such kind of qdisc and
Fatal exception in interrupt
Changes since v5:
1. add local dma_cookie_t to host struct
2. store dmaengine_submit() return value to [1]
3. use [1] when calling dmaengine_tx_status()
Applies to next-20140117
.../devicetree/bindings/mmc/moxa,moxart-sdhci.txt | 28
On Tue, Jan 14, 2014 at 08:34:10PM +0100, Daniel Matuschek wrote:
> WM8804 can run with PLL frequencies of 256xfs and 128xfs for
> most sample rates. At 192kHz only 128xfs is supported. The
> existing driver selects 128xfs automatically for some lower
> samples rates. By using an additional mclk_di
From: Chen-Yu Tsai
> snprintf should be passed the complete size of the buffer, including
> the space for '\0'. The previous code resulted in the *_reset and
> *_shutdown strings being truncated.
...
> diff --git a/net/rfkill/rfkill-gpio.c b/net/rfkill/rfkill-gpio.c
...
> - snprintf(rfkill->res
On Fri, Jan 17, 2014 at 01:17:36AM -0500, r...@redhat.com wrote:
> + /*
> + * Normalize the faults_from, so all tasks in a group
> + * count according to CPU use, instead of by the raw
> + * number of faults. This pr
Hi,
Follow the mailing-list
http://comments.gmane.org/gmane.linux.ports.arm.omap/31686
>>Setting the L1 cache line size larger than it actually is should be safe.
the written code expected as L1_CACHE_BYTES should be real cache line size
has bug.
It looks like that flush_pfn_alias function shoul
From: Hannes Frederic Sowa
...
> +/**
> + * trim - perform a reciprocal multiplication in order to "clamp" a
> + *value into range [0, ep_ro), where the upper interval
> + *endpoint is right-open. This is useful, e.g. for accessing
> + *a index of an array containing ep_ro e
On Fri, Jan 17, 2014 at 5:46 PM, David Laight wrote:
> From: Chen-Yu Tsai
>> snprintf should be passed the complete size of the buffer, including
>> the space for '\0'. The previous code resulted in the *_reset and
>> *_shutdown strings being truncated.
> ...
>> diff --git a/net/rfkill/rfkill-gpio
On 01/17/2014 02:38 AM, Stephen Boyd wrote:
The 32 bit sched_clock interface supports 64 bits since 3.13-rc1.
Upgrade to the 64 bit function to allow us to remove the 32 bit
registration interface.
Cc: Maxime Ripard
Signed-off-by: Stephen Boyd
---
Cc'in Ingo because this is simple enough to p
On 01/17/2014 10:52 AM, David Laight wrote:
From: Hannes Frederic Sowa
...
+/**
+ * trim - perform a reciprocal multiplication in order to "clamp" a
+ *value into range [0, ep_ro), where the upper interval
+ *endpoint is right-open. This is useful, e.g. for accessing
+ *a
Introduce new LOCK_DELETE flock flag that is suggested to be used
internally only to map O_DENYDELETE open flag:
!O_DENYDELETE -> LOCK_DELETE | LOCK_MAND.
Signed-off-by: Pavel Shilovsky
---
fs/locks.c | 56 --
fs/namei.c
that maps them into O_DENY* flags and make them visible for
applications on mounts with sharelock option.
Signed-off-by: Pavel Shilovsky
---
fs/locks.c |1 +
fs/nfsd/nfs4state.c | 46 +-
fs/nfsd/nfsproc.c |1 +
3 files changed, 47
On Fri, Jan 17, 2014 at 09:00:09AM +, Jean Pihet wrote:
> On 16 January 2014 14:47, Jean Pihet wrote:
> >> So the simplest thing would be to make compat_user_stack_pointer expand to
> >> user_stack_pointer(current_pt_regs()) on arm64 and merge that in with your
> >> original patch fixing user_
Construct share_access value from O_DENY* flags and send it to
the server. Use NTCreateAndX command rather than Trans2
all the time we have any of O_DENY* flags regardless of unix
extensions support. Also change smb error mapping of
NT_STATUS_SHARING_VIOLATION to -ESHAREDENIED.
Signed-off-by: Pave
From: Hannes Frederic Sowa
> On Thu, Jan 16, 2014 at 10:37:37AM -0600, Christoph Lameter wrote:
> > On Thu, 16 Jan 2014, Daniel Borkmann wrote:
> >
> > > - * or else the performance is slower than a normal divide.
> > > - */
> > > -extern u32 reciprocal_value(u32 B);
> > > +struct reciprocal_value
and prepare code intrastructure to handle O_DENY* flags.
Signed-off-by: Pavel Shilovsky
---
fs/nfs/dir.c|2 +-
fs/nfs/inode.c |7 +-
fs/nfs/nfs4_fs.h| 41 +-
fs/nfs/nfs4file.c |2 +-
fs/nfs/nfs4proc.c | 194 +
Pass O_DENY* flags to NFSv4 open request. Make it return
-ESHAREDENIED on share conflicts with other opens and disable
O_DENYDELETE support since NFSv4 doesn't support it.
Add extra file descriptor counters for every fmode|denymode
value into nfs4_state. Make the client not repeat the previous
ope
Signed-off-by: Pavel Shilovsky
---
fs/locks.c |6 ++
1 file changed, 6 insertions(+)
diff --git a/fs/locks.c b/fs/locks.c
index 7ecc511..c7e780a 100644
--- a/fs/locks.c
+++ b/fs/locks.c
@@ -1904,6 +1904,12 @@ SYSCALL_DEFINE2(flock, unsigned int, fd, unsigned int,
cmd)
go
This patchset adds support of O_DENY* flags for Linux fs layer. These flags can
be used by any application that needs share reservations to organize a file
access. VFS already has some sort of this capability - now it's done through
flock/LOCK_MAND mechanis, but that approach is non-atomic. This
This patch adds 3 flags:
1) O_DENYREAD that doesn't permit read access,
2) O_DENYWRITE that doesn't permit write access,
3) O_DENYDELETE that doesn't permit delete or rename.
Network filesystems CIFS, SMB2.0, SMB3.0 and NFSv4 have such flags -
this change can benefit cifs and nfs modules as well a
Hi,
On Thu, 2014-01-16 at 13:51 -0500, J. Bruce Fields wrote:
> On Thu, Jan 16, 2014 at 11:54:07AM -0500, Bob Peterson wrote:
> > - Original Message -
> > | Something like this?
> > (snip)
> > | @@ -779,6 +782,11 @@ static struct dentry *__gfs2_lookup(struct inode
> > *dir,
> > | struct d
On Thu, Jan 16, 2014 at 10:21:24PM -0200, Henrique de Moraes Holschuh wrote:
> On Thu, 16 Jan 2014, Aravind Gopalakrishnan wrote:
> > We might want to still have a software fix for this just in case
> > someone uses older BIOSes..
>
> There is no "just in case" when it comes to someone using outda
We're worried about reading beyond the end of the array and it's a heap
allocation and the last char of the eth addr is the last byte of the
page. This causes an oops.
It's almost impossible to hit that bug.
1) You would have to have the eth addr at the end of the array.
2) It would have to be a
On Thu, Jan 16, 2014 at 07:26:17PM +, Stephen Boyd wrote:
> On 01/16, Lorenzo Pieralisi wrote:
> > On Thu, Jan 16, 2014 at 06:05:05PM +, Stephen Boyd wrote:
> > > On 01/16, Lorenzo Pieralisi wrote:
> > > > Do we really want to do that ? I am not sure. A cpus node is supposed to
> > > > be a
Hi Arnd,
On 01/02/2014 01:07 PM, Arnd Bergmann wrote:
> sleep_on and its variants are broken and going away soon. This changes
> the omap vout driver to use interruptible_sleep_on_timeout instead,
I assume you mean wait_event_interruptible_timeout here :-)
Reviewed-by: Hans Verkuil
If there ar
> > IMHO the context extension doesn't work well enough in sparse to
> > document and implement as is. It would be much better if it actually was
> > able to differentiate between contexts, rather than treating each one
> > the same.
>
> That would certainly be nice, but that's something actually
Hi Davidlohr,
We noticed LTP test failures
ltp.msgget02.1.TFAIL
ltp.semget02.2.TFAIL
ltp.semget02.3.TFAIL
and the first bad commit is
commit 5769cf6355d87f63906b3e51887eff7017c39217
Author: Davidlohr Bueso
AuthorDate: Wed Jan 15 16:56:01 2014 +1100
Commit: Steph
On 01/02/2014 01:07 PM, Arnd Bergmann wrote:
> There is no reason to use sleep_on_timeout here, and we want to get
> rid of that interface. Use the simpler msleep_interruptible instead.
Since this define is unused anyway, lets just remove it completely.
I'll post a patch for this.
Regards,
Hi Arnd!
On 01/02/2014 01:07 PM, Arnd Bergmann wrote:
> interruptible_sleep_on is racy and going away. This replaces
> one use in the radio-cadet driver with an open-coded
> wait loop that lets us check the condition under the mutex
> but sleep without it.
>
> Signed-off-by: Arnd Bergmann
> Cc:
On Fri, Jan 17, 2014 at 8:46 AM, Marek Szyprowski
wrote:
> GFP_ATOMIC is not a single gfp flag, but a macro which expands to the other
> flags and LACK of __GFP_WAIT flag. To check if caller wanted to perform an
> atomic allocation, the code must test __GFP_WAIT flag presence. This patch
> fixes t
Hi Kyle,
On Thu, Jan 16, 2014 at 11:48:17PM +, Kyle McMartin wrote:
> I received a bug report about the ruby test-suite failing on AArch64 when
> attempting to pass MAX_ARG_STRLEN sized args to execv[1]. It was
> expecting an E2BIG returned, but instead was receiving ENOMEM, and
> concatenatin
On 01/02/2014 01:07 PM, Arnd Bergmann wrote:
> interruptible_sleep_on is racy and going away. In the arv driver that
> race has probably never caused problems since it would require a whole
> video frame to be captured before the read function has a chance to
> go to sleep, but using wait_event_int
> Charles (or someone else from Wolfson), you commented on previous
> versions of this - are you still OK with it?
Looks good to me.
Privacy & Confidentiality Notice
-
This message and any attachments contain privileged and confidential
information
Hi Miklos,
A few comments below, including one piece in the code that really must be fixed.
On 01/16/2014 11:54 PM, Miklos Szeredi wrote:
>> On Wed, Jan 15, 2014 at 7:23 PM, J. Bruce Fields
>> wrote:
>>> Do you have a man page update somewhere for the two new flags?
>
> Here's the updated man
Hi Fengguang,
On Fri, Jan 17, 2014 at 6:20 PM, Fengguang Wu wrote:
> Ming Lei,
>
> We noticed that commit 74e72f894 ("lib/percpu_counter.c: fix
> __percpu_counter_add()") introduces -47.6% regression in aim7 brk_test
> on a 2S SNB server. Comparing to its parent commit:
The commit has a bug, cou
This patchset introduces support for LZ4 compression
(along with LZO) and adds functionality to list and change
compression algorithms, using new `compressor' device attribute.
Sergey Senozhatsky (3):
zram: delete zram_init_device() function
zram: introduce zram compressor operations struct
This is preparation patch to add LZ4 compression support.
struct zram_compress_ops defines common compress and decompress
prototypes. Use these ops->compress and ops->decompress callbacks
instead of direct LZO lzo1x_1_compress() and lzo1x_decompress_safe()
calls.
Compressor ops should be defined
Add compressor device attr that allows to list and select
compression algorithms.
Define and make available for selection LZ4 compressor ops.
usage example:
List available compression algorithms (currently selected
one is LZO):
cat /sys/block/zram0/compressor
lz4
Change compression algorith
allocate new `zram_meta' in disksize_store() only for uninitialised
zram device, saving a number of allocations and deallocations in case
if disksize_store() was called on currently used device. at the same
time zram_meta stack variable is not necessary, because we can set
->meta directly. there is
On Thu, Jan 16, 2014 at 04:19:11PM -0800, David Cohen wrote:
> - * Copyright (c) 2008, 2009, 2013, Intel Corporation.
> + * Copyright (c) 20014 Intel Corporation.
Heh, it should probably be 2014 :)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message
drivers/staging/comedi/drivers/das6402.c: In function 'intr_handler':
drivers/staging/comedi/drivers/das6402.c:164:3: error: implicit declaration of
function 'outw_p' [-Werror=implicit-function-declaration]
drivers/staging/speakup/speakup_dtlk.c: In function 'synth_probe':
drivers/staging/speakup/
There is an error in a comment introduced by:
commit fa070ee6dc70bcc19737a2406d741b089b3149d5
libahci: fix turning on LEDs in ahci_start_port()
Correct it.
Signed-off-by: Lukasz Dorau
---
drivers/ata/libahci.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --
Sorry for the late reply.
On Fri, Jan 10, 2014 at 8:35 PM, Tomasz Figa wrote:
> Hi Yuvaraj,
>
> In general this version looks pretty good, but I have some questions inline.
Please find my comments inline.
>
> On 10.01.2014 08:00, Yuvaraj Kumar C D wrote:
> [snip]
>
>> diff --git a/drivers/phy/ph
1 - 100 of 614 matches
Mail list logo