Re: linux-next: manual merge of the block tree with the tree
On Thu, Nov 07, 2013 at 11:44:45PM -0800, Christoph Hellwig wrote: > On Thu, Nov 07, 2013 at 11:39:59PM -0800, Kent Overstreet wrote: > > On Thu, Nov 07, 2013 at 11:33:24PM -0800, Christoph Hellwig wrote: > > > The changes for direct I/O from kernel space have been in for a long > > > time, and they are blocking multiple consumers of the interface from > > > getting submitted for about a year now. Even if the guts of the > > > direct-io code will get a write based on another patchset from Kent > > > that will go on top of the immutable iovec changes we need the > > > interfaces now and not another year down the road. > > > > What else is blocked on this patch series? Honest question. > > > From me alone: > Support for ecryptfs to not double cache. > AIO support for target_core_file. > > To replace code in staging: > Removal of the lustre-specific loop driver. > > And I remember others claiming to want to submit bits, too. So, I don't think the iov_iter stuff is the right approach for solving the loop issue; it's an ugly hack and after immutable biovecs we're pretty close to a better solution and some major cleanups too. I don't know about ecryptfs and AIO for target, though - are there patches for those you could point me at so I can have a look? I can believe the iov_iter stuff is necessary for those, but I'd like to convince myself there isn't a cleaner solution. Regardless, I don't want to be blocking anyone else's work; if we do want the iov_iter stuff in now (I'm not arguing one way or the other till I look at the issues you pointed out) I can write a small patch to correctly merge with immutable bvecs; I looked at it today and it's pretty straightforward (if somewhat ugly). -- 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/
Re: [PATCH V3 06/11] perf record: Add an option to force per-cpu mmaps
On 05/11/13 19:31, Arnaldo Carvalho de Melo wrote: > PeterZ, > > Can I have your Acked-by for this one? I guess now the goal is > achieved, no? Ping > > - Arnaldo > > Em Tue, Nov 05, 2013 at 11:25:45AM -0300, Arnaldo Carvalho de Melo escreveu: >> Em Tue, Nov 05, 2013 at 02:30:24PM +0100, Jiri Olsa escreveu: >>> On Tue, Nov 05, 2013 at 03:09:30PM +0200, Adrian Hunter wrote: > right, I haven't considered the hundreds CPU machine.. I just > saw that it disables inherited events in my test ;-) maybe we > could mentioned that somewhere, because it's not clear How about this: From: Adrian Hunter By default, when tasks are specified (i.e. -p, -t or -u options) per-thread mmaps are created. Add an option to override that and force per-cpu mmaps. Signed-off-by: Adrian Hunter >>> seems ok, thanks >> Much better, but may I ask that the explanation in the man pages be >> present in the changeset commit as well? So that by just looking at 'git >> log' we can more readily get the whole picture, i.e. scalability versus >> wanting to have inherit. >> >> - Arnaldo >> >>> Acked-by: Jiri Olsa >>> >>> jirka > -- 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/
Re: [RFC PATCH] MAINTAINERS: Remove Jaroslav Kysela
Date 7.11.2013 21:04, Joe Perches wrote: > Jaroslav hasn't acked or signed a patch in quite awhile. It does not mean that I'm not willing to continue the kernel code maintenance when Takashi is offline. Keep me in. You may reorder M: lines. > Mark ISAPnp and HP VG/AnyLAN driver as orphan. I agree. > > Add sound to his CREDITS entry. > > Signed-off-by: Joe Perches > --- > CREDITS | 1 + > MAINTAINERS | 7 ++- > 2 files changed, 3 insertions(+), 5 deletions(-) > > diff --git a/CREDITS b/CREDITS > index 0640e16..01a1b34 100644 > --- a/CREDITS > +++ b/CREDITS > @@ -2021,6 +2021,7 @@ E: pe...@perex.cz > W: http://www.perex.cz > D: Original Author and Maintainer for HP 10/100 Mbit Network Adapters > D: ISA PnP > +D: ALSA/Sound > S: Sindlovy Dvory 117 > S: 370 01 Ceske Budejovice > S: Czech Republic > diff --git a/MAINTAINERS b/MAINTAINERS > index 831b869..8706839 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -3983,8 +3983,7 @@ S: Orphan > F: drivers/platform/x86/tc1100-wmi.c > > HP100: Driver for HP 10/100 Mbit/s Voice Grade Network Adapter Series > -M: Jaroslav Kysela > -S: Maintained > +S: Orphan > F: drivers/net/ethernet/hp/hp100.* > > HPET:High Precision Event Timers driver > @@ -4600,8 +4599,7 @@ F: include/linux/irqdomain.h > F: kernel/irq/irqdomain.c > > ISAPNP > -M: Jaroslav Kysela > -S: Maintained > +S: Orphan > F: Documentation/isapnp.txt > F: drivers/pnp/isapnp/ > F: include/linux/isapnp.h > @@ -7818,7 +7816,6 @@ S: Maintained > F: drivers/memstick/core/ms_block.* > > SOUND > -M: Jaroslav Kysela > M: Takashi Iwai > L: alsa-de...@alsa-project.org (moderated for non-subscribers) > W: http://www.alsa-project.org/ > -- Jaroslav Kysela Linux Kernel Sound Maintainer ALSA Project; Red Hat, Inc. -- 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/
linux-next: manual merge of the akpm-current tree with the tip tree
Hi Andrew,
Today's linux-next merge of the akpm-current tree got a conflict in
kernel/Makefile between commits 60fc28746a7b ("locking: Move the spinlock
code to kernel/locking/") and cd4d241d57c9 ("locking: Move the lglocks
code to kernel/locking/") from the tip tree and commit f5639052d567
("lglock: map to spinlock when !CONFIG_SMP") from the akpm-current tree.
I fixed it up (dropping the kernel/Makefile section of the akpm-current
commit and adding the below patch) and can carry the fix as necessary (no
action is required).
From: Stephen Rothwell
Date: Fri, 8 Nov 2013 18:45:25 +1100
Subject: [PATCH] lglock: fixup for code movement
Signed-off-by: Stephen Rothwell
---
kernel/locking/Makefile | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/kernel/locking/Makefile b/kernel/locking/Makefile
index baab8e5e7f66..bb3c65930a20 100644
--- a/kernel/locking/Makefile
+++ b/kernel/locking/Makefile
@@ -1,5 +1,5 @@
-obj-y += mutex.o semaphore.o rwsem.o lglock.o
+obj-y += mutex.o semaphore.o rwsem.o
ifdef CONFIG_FUNCTION_TRACER
CFLAGS_REMOVE_lockdep.o = -pg
@@ -8,6 +8,7 @@ CFLAGS_REMOVE_mutex-debug.o = -pg
CFLAGS_REMOVE_rtmutex-debug.o = -pg
endif
+obj-$(CONFIG_SMP) += lglock.o
obj-$(CONFIG_DEBUG_MUTEXES) += mutex-debug.o
obj-$(CONFIG_LOCKDEP) += lockdep.o
ifeq ($(CONFIG_PROC_FS),y)
--
1.8.4.2
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
pgpN3h6BYMD12.pgp
Description: PGP signature
Re: linux-next: manual merge of the block tree with the tree
On Thu, Nov 07, 2013 at 11:39:59PM -0800, Kent Overstreet wrote: > On Thu, Nov 07, 2013 at 11:33:24PM -0800, Christoph Hellwig wrote: > > The changes for direct I/O from kernel space have been in for a long > > time, and they are blocking multiple consumers of the interface from > > getting submitted for about a year now. Even if the guts of the > > direct-io code will get a write based on another patchset from Kent > > that will go on top of the immutable iovec changes we need the > > interfaces now and not another year down the road. > > What else is blocked on this patch series? Honest question. >From me alone: Support for ecryptfs to not double cache. AIO support for target_core_file. To replace code in staging: Removal of the lustre-specific loop driver. And I remember others claiming to want to submit bits, too. -- 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/
Re: linux-next: manual merge of the block tree with the tree
On Thu, Nov 07, 2013 at 11:33:24PM -0800, Christoph Hellwig wrote: > The changes for direct I/O from kernel space have been in for a long > time, and they are blocking multiple consumers of the interface from > getting submitted for about a year now. Even if the guts of the > direct-io code will get a write based on another patchset from Kent > that will go on top of the immutable iovec changes we need the > interfaces now and not another year down the road. What else is blocked on this patch series? Honest question. -- 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/
Re: [RFC 0/8] Move locking primitives into kernel/locking/
On Wed, Nov 06, 2013 at 06:29:21AM -0800, Paul E. McKenney wrote: > On Tue, Nov 05, 2013 at 01:10:44PM +0100, Peter Zijlstra wrote: > > Hi all, > > > > During Kernel Summit Dave mentioned that there wasn't a clear maintainer for > > locking bits. > > > > To remedy this Ingo suggested gathering all the various locking primitives > > and > > lockdep into a single place: kernel/locking/. > > > > I would further like to propose a MAINTAINERS entry like: > > > > LOCKING > > M: Ingo Molnar > > M: Peter Zijlstra > > M: Oleg Nesterov > > M: "Paul E. McKenney" > > M: Linus Torvalds > > T: git git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git > > locking/core > > S: Maintained > > F: kernel/locking/ > > > > Because for most 'fun' locking discussions we usually end up with at least > > those people anyway :-) > > > > Comments? > > OK, I am in. > > How are we organizing this? I could imagine divvying up the various > types of locks, having a minimum number of reviews or acks coupled > with a maximum review time, or just requiring the full set of reviews > and acks given the criticality of locking code. Other approaches? I would suggest something like an ack/review of at least 3/5, no hard deadline, because as you say, its better to get locking right :-) -- 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/
linux-next: manual merge of the akpm-current tree with the vfs tree
Hi Andrew,
Today's linux-next merge of the akpm-current tree got a conflict in
include/linux/lglock.h between commit 4314ff760e8b ("no need to keep
brlock macros anymore...") from the vfs tree and commit f5639052d567
("lglock: map to spinlock when !CONFIG_SMP") from the akpm-current tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc include/linux/lglock.h
index 96549abe8842,6561b1c0fa63..
--- a/include/linux/lglock.h
+++ b/include/linux/lglock.h
@@@ -25,6 -25,18 +25,8 @@@
#include
#include
-/* can make br locks by using local lock for read side, global lock for write
*/
-#define br_lock_init(name)lg_lock_init(name, #name)
-#define br_read_lock(name)lg_local_lock(name)
-#define br_read_unlock(name) lg_local_unlock(name)
-#define br_write_lock(name) lg_global_lock(name)
-#define br_write_unlock(name) lg_global_unlock(name)
-
-#define DEFINE_BRLOCK(name) DEFINE_LGLOCK(name)
-#define DEFINE_STATIC_BRLOCK(name)DEFINE_STATIC_LGLOCK(name)
-
+ #ifdef CONFIG_SMP
+
#ifdef CONFIG_DEBUG_LOCK_ALLOC
#define LOCKDEP_INIT_MAP lockdep_init_map
#else
pgp74X0GiabrD.pgp
Description: PGP signature
linux-next: manual merge of the akpm-current tree with the vfs tree
Hi Andrew,
Today's linux-next merge of the akpm-current tree got a conflict in
fs/autofs4/inode.c between commit baa40671d3e3 ("autofs4: make freeing
sbi rcu-delayed") from the vfs tree and commit e4af471815fc ("autofs4:
allow autofs to work outside the initial PID namespace") from the
akpm-current tree.
I fixed it up (I think - see below) and can carry the fix as necessary
(no action is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc fs/autofs4/inode.c
index 3b9cc9b973c2,1b045ecfcea2..
--- a/fs/autofs4/inode.c
+++ b/fs/autofs4/inode.c
@@@ -56,13 -56,20 +56,15 @@@ void autofs4_kill_sb(struct super_bloc
* just call kill_anon_super when we are called from
* deactivate_super.
*/
- if (sbi) /* Free wait queues, close pipe */
- if (!sbi)
- goto out_kill_sb;
-
- /* Free wait queues, close pipe */
- autofs4_catatonic_mode(sbi);
-
- put_pid(sbi->oz_pgrp);
-
- sb->s_fs_info = NULL;
- kfree(sbi);
++ if (sbi) { /* Free wait queues, close pipe */
+ autofs4_catatonic_mode(sbi);
++ put_pid(sbi->oz_pgrp);
++ }
-out_kill_sb:
DPRINTK("shutting down");
kill_litter_super(sb);
+ if (sbi)
+ kfree_rcu(sbi, rcu);
}
static int autofs4_show_options(struct seq_file *m, struct dentry *root)
pgp_HE2GEWBoK.pgp
Description: PGP signature
[PATCH] x86, efi: change name of efi_no_storage_paranoia parameter to efi_storage_paranoia
By following works, my system very often fails set_variable() to set new
variable to efi variable storage and shows "efivars: set_variable() failed:
status=-28" message.
- commit 31ff2f20d9003e74991d135f56e503fe776c127c
efi: Distinguish between "remaining space" and actually used space
- commit 8c58bf3eec3b8fc8162fe557e9361891c20758f2
x86,efi: Implement efi_no_storage_paranoia parameter
- commit f8b8404337de4e2466e2e1139ea68b1f8295974f
Modify UEFI anti-bricking code
When booting my system, remaining space of efi variable storage is about
5KB. So there is no room that sets a new variable to the storage.
According to above works, efi_no_storage_paranoia parameter was prepared
for sane UEFI which can do gc and fulfills spec. But why need a system
with a sane UEFI set the parameter? It is wrong. A system with a broken
UEFI should set the parameter.
This patch changes name of the parameter to efi_storage_paranoia and uses
all efi variable storage with no parameter.
Signed-off-by: Yasuaki Ishimatsu
CC: Matthew Garrett
CC: Richard Weinberger
CC: Lee, Chun-Y
CC: Matt Fleming
---
Documentation/kernel-parameters.txt | 10 +-
arch/x86/platform/efi/efi.c | 8
2 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/Documentation/kernel-parameters.txt
b/Documentation/kernel-parameters.txt
index fcbb736..2157c8e 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -888,11 +888,11 @@ bytes respectively. Such letter suffixes can also be
entirely omitted.
edd=[EDD]
Format: {"off" | "on" | "skip[mbr]"}
- efi_no_storage_paranoia [EFI; X86]
- Using this parameter you can use more than 50% of
- your efi variable storage. Use this parameter only if
- you are really sure that your UEFI does sane gc and
- fulfills the spec otherwise your board may brick.
+ efi_storage_paranoia [EFI; X86]
+ Using this parameter you cannot use your efi variable
+ storage when the remaining space of the storage becomes
+ less than 5KB. Use this parameter if your UEFI does
+ not sane gc and fulfills the spec.
eisa_irq_edge= [PARISC,HW]
See header of drivers/parisc/eisa.c.
diff --git a/arch/x86/platform/efi/efi.c b/arch/x86/platform/efi/efi.c
index c7e22ab..010a0eb 100644
--- a/arch/x86/platform/efi/efi.c
+++ b/arch/x86/platform/efi/efi.c
@@ -107,14 +107,14 @@ static int __init setup_add_efi_memmap(char *arg)
}
early_param("add_efi_memmap", setup_add_efi_memmap);
-static bool efi_no_storage_paranoia;
+static bool efi_storage_paranoia;
static int __init setup_storage_paranoia(char *arg)
{
- efi_no_storage_paranoia = true;
+ efi_storage_paranoia = true;
return 0;
}
-early_param("efi_no_storage_paranoia", setup_storage_paranoia);
+early_param("efi_storage_paranoia", setup_storage_paranoia);
static efi_status_t virt_efi_get_time(efi_time_t *tm, efi_time_cap_t *tc)
@@ -1066,7 +1066,7 @@ efi_status_t efi_query_variable_store(u32 attributes,
unsigned long size)
* 5KB. This figure was provided by Samsung, so should be safe.
*/
if ((remaining_size - size < EFI_MIN_RESERVE) &&
- !efi_no_storage_paranoia) {
+ efi_storage_paranoia) {
/*
* Triggering garbage collection may require that the firmware
--
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/
Re: linux-next: manual merge of the block tree with the tree
Btw, I have to state that I very much disagree with dropping the direct I/O kernel changes, and I also very much disagree with keeping the immutable iovecs in. For the latter I think the immutable iovecs are useful and do want to see them eventually, but they were merged at the latest possible point in the merge window and cause breakage all over the tree, so they very clearly are not ready at this point, and I fear even more breakage if they do get merged. The changes for direct I/O from kernel space have been in for a long time, and they are blocking multiple consumers of the interface from getting submitted for about a year now. Even if the guts of the direct-io code will get a write based on another patchset from Kent that will go on top of the immutable iovec changes we need the interfaces now and not another year down the road. -- 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/
Re: CONFIG_NO_HZ_FULL + CONFIG_PREEMPT_RT_FULL = nogo
On Thu, 2013-11-07 at 19:23 -0800, Paul E. McKenney wrote: > An untested patch that gets rid of the RCU_SOFTIRQs in this case is below. Yup, toasted. -Mike -- 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/
linux-next: manual merge of the akpm-current tree with the vfs tree
Hi Andrew,
Today's linux-next merge of the akpm-current tree got a conflict in
fs/anon_inodes.c between commit 24b0303e9532 ("take anon inode allocation
to libfs.c") from the vfs tree and commit 02f3ac4386d9 ("anon_inodefs:
forbid open via /proc") from the akpm-current tree.
I just dropped the akpm-current changes for today - they should probably
be applied to fs/libfs.c.
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
pgpHV1O64eFuZ.pgp
Description: PGP signature
Re: linux-next: build failure after merge of the userns tree
On Fri, Nov 08, 2013 at 05:58:48PM +1100, Stephen Rothwell wrote:
> Hi Eric,
>
> After merging the userns tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
>
> fs/namei.c: In function 'covered':
> fs/namei.c:3528:2: error: too many arguments to function '__lookup_mnt'
> is_covered = d_mountpoint(dentry) && __lookup_mnt(mnt, dentry, 1);
> ^
>
> Caused by my incomplete merge resolution between commits 474279dc0f77
> ("split __lookup_mnt() in two functions") from the vfs tree and
> a3b4491433f2 ("vfs: Don't allow overwriting mounts in the current mount
> namespace") from the userns tree.
Btw, I don't think the userns tree has any business touching lookup
and mount semantics in namei.c without an explicit VFS signoff.
Please drop the tree for now.
--
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/
[PATCH] nfsd:add '\n' when read file supported_krb5_enctypes
From: Weng Meiling
Signed-off-by: Weng Meiling
---
fs/nfsd/nfsctl.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/nfsd/nfsctl.c b/fs/nfsd/nfsctl.c
index 7f55517..31db42c 100644
--- a/fs/nfsd/nfsctl.c
+++ b/fs/nfsd/nfsctl.c
@@ -188,7 +188,7 @@ static const struct file_operations
export_features_operations = {
#if defined(CONFIG_SUNRPC_GSS) || defined(CONFIG_SUNRPC_GSS_MODULE)
static int supported_enctypes_show(struct seq_file *m, void *v)
{
- seq_printf(m, KRB5_SUPPORTED_ENCTYPES);
+ seq_printf(m, "%s\n", KRB5_SUPPORTED_ENCTYPES);
return 0;
}
--
1.8.3.1
--
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/
[PATCH] svcrpc: remove the unnecessary evaluation
From: Weng Meiling Signed-off-by: Weng Meiling --- net/sunrpc/svc.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/net/sunrpc/svc.c b/net/sunrpc/svc.c index b974571..e7fbe36 100644 --- a/net/sunrpc/svc.c +++ b/net/sunrpc/svc.c @@ -1104,8 +1104,6 @@ svc_process_common(struct svc_rqst *rqstp, struct kvec *argv, struct kvec *resv) rqstp->rq_vers = vers = svc_getnl(argv);/* version number */ rqstp->rq_proc = proc = svc_getnl(argv);/* procedure number */ - progp = serv->sv_program; - for (progp = serv->sv_program; progp; progp = progp->pg_next) if (prog == progp->pg_prog) break; -- 1.8.3.1 -- 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/
[PATCH RFC] dma-buf/fs Add get_[file|dma_buf]_unless_doomed
In this context, a "doomed" object is an object whose refcount has reached
zero, but that has not yet been freed.
To avoid mutual refcounting vmwgfx need to have a non-refcounted pointer to
a dma-buf in a lookup structure. The pointer is removed in the dma-buf
destructor. To allow lookup-structure private locks we need
get_dma_buf_unless_doomed(). This common refcounting scenario is described
with examples in detail in the kref documentaion.
The solution with local locks is under kref_get_unless_zero().
See also kobject_get_unless_zero() and its commit message.
Since dma-bufs are using the attached file for refcounting,
get_dma_buf_unless_doomed maps directly to a get_file_unless_doomed.
Signed-off-by: Thomas Hellstrom
---
include/linux/dma-buf.h | 16
include/linux/fs.h | 15 +++
2 files changed, 31 insertions(+)
diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h
index dfac5ed..6e58144 100644
--- a/include/linux/dma-buf.h
+++ b/include/linux/dma-buf.h
@@ -162,6 +162,22 @@ static inline void get_dma_buf(struct dma_buf *dmabuf)
get_file(dmabuf->file);
}
+/**
+ * get_dma_buf_unless_doomed - convenience wrapper for get_file_unless_doomed
+ *
+ * @dmabuf:[in]pointer to dma_buf
+ *
+ * Obtain a dma-buf reference from a lookup structure that doesn't refcount
+ * the dma-buf, but synchronizes with its release method to make sure it has
+ * not been freed yet. See for example kref_get_unless_zero documentation.
+ * Returns true if refcounting succeeds, false otherwise.
+ */
+static inline bool __must_check
+get_dma_buf_unless_doomed(struct dma_buf *dmabuf)
+{
+ return get_file_unless_doomed(dmabuf->file);
+}
+
struct dma_buf_attachment *dma_buf_attach(struct dma_buf *dmabuf,
struct device *dev);
void dma_buf_detach(struct dma_buf *dmabuf,
diff --git a/include/linux/fs.h b/include/linux/fs.h
index 3f40547..a96c333 100644
--- a/include/linux/fs.h
+++ b/include/linux/fs.h
@@ -824,6 +824,21 @@ static inline struct file *get_file(struct file *f)
atomic_long_inc(>f_count);
return f;
}
+
+/**
+ * get_file_unless_doomed - convenience wrapper for get_file_unless_doomed
+ * @file: [in]pointer to file
+ *
+ * Obtain a file reference from a lookup structure that doesn't refcount
+ * the file, but synchronizes with its release method to make sure it has
+ * not been freed yet. See for example kref_get_unless_zero documentation.
+ * Returns true if refcounting succeeds, false otherwise.
+ */
+static inline bool __must_check get_file_unless_doomed(struct file *f)
+{
+ return atomic_long_inc_not_zero(>f_count) != 0L;
+}
+
#define fput_atomic(x) atomic_long_add_unless(&(x)->f_count, -1, 1)
#define file_count(x) atomic_long_read(&(x)->f_count)
--
1.7.10.4
--
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/
late commits (Was: linux-next: manual merge of the userns tree with the vfs tree)
Hi Al, On Fri, 8 Nov 2013 17:50:55 +1100 Stephen Rothwell wrote: > > Al, I do have to wonder why a commit whose whole commit message is: > > "RCU'd vfsmounts > > _very_ preliminary, barely tested." > > is in linux-next as is not being kept over for v3.14 at this point. Oh, I see, it was discussed back at the beginning of October. Pity it didn't turn up in linux-next then so my volunteer temporary replacements could have dealt with it :-) However, it really, really needs a (better) commit message. -- Cheers, Stephen Rothwells...@canb.auug.org.au pgpk2FzQALrGI.pgp Description: PGP signature
RE: [PATCH 2/2] mtd: cmdlinepart: use cmdline partition parser lib
> Nobody has had time to test this on MTD, it seems, and as such, I > strongly recommend you do not force it through -mm. We are perfectly > capable of merging it through the MTD tree if it ever gets proper > vetting by people in MTD (not just on block devices), and I am well > aware of this patch set's existence. > > However, the patch really provides little to no benefit to the MTD > subsystem at the moment, at the added cost of reviewing the small > differences in parsing. For some reason, Cai decided to make small > differences in the parser between drivers/mtd/cmdlinepart.c and > block/cmdline-parser.c, and it is not obvious that these differences > retain the same parsing. For instance, according to my code > read-through, the block device parser seems to accept multiple > partitions to be specified with "-" (meaning "fill the remaining > device"). MTD already has code that rejects such a parser string > outright. The next '-' partition be ignore at function "cmdline_parts_set", and the client will get a right result. Is there any other worry about '-' I don't know ? > > So, I'd recommend one of the following: > (1) We (MTD users) make more time to properly test this patch and post > relevant results (i.e., tested partition strings) or > (2) Somebody (Cai?) spend time to actually make block/cmdline-parser.c > fully equivalent to the parser in drivers/mtd/cmdlinepart.c. That > means it should be trivial to compare the two and say "yes, these are > equivalent". That is currently not the case, AFAICT. I understand your worry about, we use cmdlinepart many years. I will spend time to make block/cmdline-parser.c fully equivalent to the parser in drivers/mtd/cmdlinepart.c. > > Without one of those two, I will give my NAK. > > Brian -- 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/
Re: [PATCH 3/3] DT: proc: Add runtime overlay interface in /proc
Hi Alan,
On Nov 8, 2013, at 1:38 AM, delicious quinoa wrote:
> On Tue, Nov 5, 2013 at 12:41 PM, Pantelis Antoniou
> wrote:
>> +
>> + pr_info("%s: Applied #%d overlay segments @%d\n", __func__,
>> + od->ovinfo_cnt, od->id);
>> +
>
> This could be pr_debug so that we get normally get silence unless
> something fails, like insmod.
>
> Also please take out the '#'.
>
OK, will do on the next series.
> We see it working with our fpga ip driver and it looks really great.
>
Glad to hear that.
> Alan
Regards
-- Pantelis
--
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/
Re: [PATCH 0/3 - V2] Introducing Device Tree Overlays
Hi Guenter, On Nov 8, 2013, at 1:00 AM, Guenter Roeck wrote: > On Thu, Nov 07, 2013 at 09:46:26PM +0100, Sebastian Andrzej Siewior wrote: >> On 07.11.13, Pantelis Antoniou wrote: >>> Hi Sebastian, >> Hi Pantelis, >> >>> FWIW DT has been ported to x86. And is present on arm/powerpc/mips/arc and >>> possibly >>> others. >> >> Yes, I know. I am the one that did the work for CE4100, the first one >> that boots with DT on x86. >> >>> So what are we talking about again? If you care about the non-DT case, why >>> don't you make a patch about how you could support Guenter's use case on >>> the x86. >> >> I am only saying that this "hot-plug a device at a non hot-plugagle bus at >> runtime" is not limited to DT but this solution is. X86 + ACPI is not >> the only limitation. ARM is (forced) going to ACPI as well as far I >> know. And this solution is limited to DT. This is what I am pointing >> out. >> > I can't tell about ARM, but I am not entirely sure how ACPI support on ARM > is going to help us on powerpc. > >>> His use case is not uncommon, believe it or not, and x86 would benefit from >>> something this flexible. >> >> I *think* a more flexible solution would be something like bus_type which is >> exposed via configfs. It would be attached behind a certain device/bus where >> the "physical" hotplug interface is. The user would then be able to read the >> configuration based on whatever information he has and could then create >> devices he likes at runtime. This wouldn't depend much on the firmware that >> is >> used but would require a little more work I think. >> > Quite frankly, I am interested at a solution that works and solves our > problems. > I am not looking for something that is 100% perfect and may never be > delivered. > +1 > Fortunately, the Linux kernel was willing to adopt multiple different file > systems, and still accepts new ones on a regular basis. If a new file system > is better, it will start getting used, and old file systems are being phased > out > as fewer people use them. I would hope the same should be possible with DT > overlays and possible other future solutions for the same problem, and that > we won't have to wait for the perfect solution from day 1. > Fully agreed here. I was told open source is about scratching an itch, this is worthy of scratching. > Guenter Regards -- Pantelis -- 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/
Re: kernel BUG at kernel/kallsyms.c:222!
Hi Axel, On Fri, Nov 8, 2013 at 12:20 PM, Axel Lin wrote: > > > Hi Ming, > > I have patches on top of 3.12 to support gpl32700 SoC. > So you cannot find this platform on mainline kernel. OK, I see. > I havn't tried perf, below is my config for your reference: > (to make the config smaller, I grep out disabled config entries.) I doubt CONFIG_VMSPLIT_3G/CONFIG_PAGE_OFFSET isn't used at all in your unmerged patchset, also your link script should be different with in-tree arch/arm/kernel/vmlinux.lds.S, otherwise you may put all your kernel symbols after 0xC. Maybe you need to not define PAGE_OFFSET and let it be PHYS_OFFSET at default, also VMSPLIT_3G shouldn't have been there on non-MMU linux. Thanks, -- Ming Lei -- 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/
Re: [PATCH 0/3 - V2] Introducing Device Tree Overlays
Hi Sebastian, On Nov 7, 2013, at 10:46 PM, Sebastian Andrzej Siewior wrote: > On 07.11.13, Pantelis Antoniou wrote: >> Hi Sebastian, > Hi Pantelis, > >> FWIW DT has been ported to x86. And is present on arm/powerpc/mips/arc and >> possibly >> others. > > Yes, I know. I am the one that did the work for CE4100, the first one > that boots with DT on x86. > >> So what are we talking about again? If you care about the non-DT case, why >> don't you make a patch about how you could support Guenter's use case on >> the x86. > > I am only saying that this "hot-plug a device at a non hot-plugagle bus at > runtime" is not limited to DT but this solution is. X86 + ACPI is not > the only limitation. ARM is (forced) going to ACPI as well as far I > know. And this solution is limited to DT. This is what I am pointing > out. > Who is forcing ACPI on ARM? Maybe for ARM64 and server markets but interest in ACPI for all the other markets I'd say is nil. A DT limited solution has more reach _today_ that what ACPI _might_ do sometime. There is a big big world outside of x86. >> His use case is not uncommon, believe it or not, and x86 would benefit from >> something this flexible. > > I *think* a more flexible solution would be something like bus_type which is > exposed via configfs. It would be attached behind a certain device/bus where > the "physical" hotplug interface is. The user would then be able to read the > configuration based on whatever information he has and could then create > devices he likes at runtime. This wouldn't depend much on the firmware that is > used but would require a little more work I think. > You might've missed the posting, but the original implementation was using a bus (a capebus) and that went over like a lead ballon. People use this, and find the concept useful. In a nutshell, sure, there _might_ be better ways to do it, but no-one has actually stepped forward and did it better. >> Regards >> >> -- Pantelis > > Sebastian Regards -- Pantelis -- 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/
linux-next: build failure after merge of the userns tree
Hi Eric,
After merging the userns tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:
fs/namespace.c: In function 'detach_mounts':
fs/namespace.c:1340:2: error: implicit declaration of function 'br_write_lock'
[-Werror=implicit-function-declaration]
br_write_lock(_lock);
^
fs/namespace.c:1340:17: error: 'vfsmount_lock' undeclared (first use in this
function)
br_write_lock(_lock);
^
fs/namespace.c:1340:17: note: each undeclared identifier is reported only once
for each function it appears in
fs/namespace.c:1345:2: error: implicit declaration of function
'br_write_unlock' [-Werror=implicit-function-declaration]
br_write_unlock(_lock);
^
Caused by the interaction between commit d7e58b8abc4f ("vfs: Add a
function to lazily unmount all mounts from any dentry. v3") from the
userns tree and commit 84550b9356af ("RCU'd vfsmounts") from the vfs tree.
I don't know how to fix this up, so I have just dropped the userns tree
for today. I only dropped that tree because it was the latter of the two
conflicting trees.
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
pgpTEbQCVsU5H.pgp
Description: PGP signature
Re: [PATCH] wcn36xx: Fix logging macro with unnecessary semicolon
Joe Perches writes: >> have a >> second round of convincing ath guys to change printing code. How does >> that sound? > > Luis? Kalle? Other Qualcomm/Atheros folk? I didn't quite get what you are asking from me. But for me most important is that the current debugging facilities from user's point of view don't change. I don't care if the code is in ath10k.ko or ath.ko, we are talking about ~100 lines of code anyway. > One of the nominal benefits of separating the ath_ > macros by subsystem was perf/tracing. Nominal? -- Kalle Valo -- 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/
Buyer.
Dear Buyer, I am Mr. Michael Doku, representative to my villagers in Ghana, we are prepared to provide any quantities of 99.6% purity (23 karat+) alluvial gold at any time of demand. Below is the information of our Gold dust: Quantity: Large Quantity available monthly Quality: 23karat+ plus alluvial Origin: Ghana, West Africa Assay reports provided by Geological services. We also have a reasonable quantity of Rough Diamond for sale. We seek big and genuine buyers for serious and long time business relationship. Thanks for your utmost co-operation. Best Regards. Michael Doku. Reply To:micd...@yahoo.co.uk -- 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/
linux-next: build failure after merge of the userns tree
Hi Eric,
After merging the userns tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:
fs/namei.c: In function 'covered':
fs/namei.c:3528:2: error: too many arguments to function '__lookup_mnt'
is_covered = d_mountpoint(dentry) && __lookup_mnt(mnt, dentry, 1);
^
Caused by my incomplete merge resolution between commits 474279dc0f77
("split __lookup_mnt() in two functions") from the vfs tree and
a3b4491433f2 ("vfs: Don't allow overwriting mounts in the current mount
namespace") from the userns tree.
I added the following fix up patch:
From: Stephen Rothwell
Date: Fri, 8 Nov 2013 17:56:35 +1100
Subject: [PATCH] vfs: merge fixup for __lookup_mnt() API change
Signed-off-by: Stephen Rothwell
---
fs/namei.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/namei.c b/fs/namei.c
index 83463500c582..03d999bf9a89 100644
--- a/fs/namei.c
+++ b/fs/namei.c
@@ -3525,7 +3525,7 @@ static bool covered(struct vfsmount *mnt, struct dentry
*dentry)
bool is_covered;
rcu_read_lock();
- is_covered = d_mountpoint(dentry) && __lookup_mnt(mnt, dentry, 1);
+ is_covered = d_mountpoint(dentry) && __lookup_mnt(mnt, dentry);
rcu_read_unlock();
return is_covered;
--
1.8.4.2
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
pgpU1oXLqCStx.pgp
Description: PGP signature
RE: [PATCH 2/2] mtd: cmdlinepart: use cmdline partition parser lib
>> For further information, see "https://lkml.org/lkml/2013/8/6/550; > > Thanks for doing this. Could we please get some acked-by's or, > preferably, tested-by's from the MTD people? Acked-by: Ezequiel Garcia Acked-by: Andrew Morton -- 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/
linux-next: manual merge of the userns tree with the vfs tree
Hi Eric,
Today's linux-next merge of the userns tree got a conflict in fs/mount.h
between commits 84550b9356af ("RCU'd vfsmounts") and 474279dc0f77 ("split
__lookup_mnt() in two functions") from the vfs tree and commit
d7e58b8abc4f ("vfs: Add a function to lazily unmount all mounts from any
dentry. v3") from the userns tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc fs/mount.h
index d64c594be6c4,7a6a2bb3f290..
--- a/fs/mount.h
+++ b/fs/mount.h
@@@ -77,11 -78,9 +79,12 @@@ static inline int is_mounted(struct vfs
return !IS_ERR_OR_NULL(real_mount(mnt));
}
-extern struct mount *__lookup_mnt(struct vfsmount *, struct dentry *, int);
+extern struct mount *__lookup_mnt(struct vfsmount *, struct dentry *);
+extern struct mount *__lookup_mnt_last(struct vfsmount *, struct dentry *);
+ extern void detach_mounts(struct dentry *dentry);
+extern bool legitimize_mnt(struct vfsmount *, unsigned);
+
static inline void get_mnt_ns(struct mnt_namespace *ns)
{
atomic_inc(>count);
pgpdzwPLr3_Tn.pgp
Description: PGP signature
linux-next: manual merge of the userns tree with the vfs tree
Hi Eric,
Today's linux-next merge of the userns tree got a conflict in fs/dcache.c
between commit 84550b9356af ("RCU'd vfsmounts") from the vfs tree and
commit 40216baa0101 ("vfs: Lazily remove mounts on unlinked files and
directories. v2") from the userns tree.
I fixed it up (I think - see below) and can carry the fix as necessary
(no action is required).
Al, I do have to wonder why a commit whose whole commit message is:
"RCU'd vfsmounts
_very_ preliminary, barely tested."
is in linux-next as is not being kept over for v3.14 at this point.
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc fs/dcache.c
index 6f418c540f76,1e9bf96b0132..
--- a/fs/dcache.c
+++ b/fs/dcache.c
@@@ -1362,110 -1478,17 +1362,101 @@@ void shrink_dcache_parent(struct dentr
}
EXPORT_SYMBOL(shrink_dcache_parent);
+static enum d_walk_ret umount_collect(void *_data, struct dentry *dentry)
+{
+ struct select_data *data = _data;
+ enum d_walk_ret ret = D_WALK_CONTINUE;
+
+ if (dentry->d_lockref.count) {
+ dentry_lru_del(dentry);
+ if (likely(!list_empty(>d_subdirs)))
+ goto out;
+ if (dentry == data->start && dentry->d_lockref.count == 1)
+ goto out;
+ printk(KERN_ERR
+ "BUG: Dentry %p{i=%lx,n=%s}"
+ " still in use (%d)"
+ " [unmount of %s %s]\n",
+ dentry,
+ dentry->d_inode ?
+ dentry->d_inode->i_ino : 0UL,
+ dentry->d_name.name,
+ dentry->d_lockref.count,
+ dentry->d_sb->s_type->name,
+ dentry->d_sb->s_id);
+ BUG();
+ } else if (!(dentry->d_flags & DCACHE_SHRINK_LIST)) {
+ /*
+ * We can't use d_lru_shrink_move() because we
+ * need to get the global LRU lock and do the
+ * LRU accounting.
+ */
+ d_lru_del(dentry);
+ d_shrink_add(dentry, >dispose);
+ data->found++;
+ ret = D_WALK_NORETRY;
+ }
+out:
+ if (data->found && need_resched())
+ ret = D_WALK_QUIT;
+ return ret;
+}
+
+/*
+ * destroy the dentries attached to a superblock on unmounting
+ */
+void shrink_dcache_for_umount(struct super_block *sb)
+{
+ struct dentry *dentry;
+
+ if (down_read_trylock(>s_umount))
+ BUG();
+
+ dentry = sb->s_root;
+ sb->s_root = NULL;
+ for (;;) {
+ struct select_data data;
+
+ INIT_LIST_HEAD();
+ data.start = dentry;
+ data.found = 0;
+
+ d_walk(dentry, , umount_collect, NULL);
+ if (!data.found)
+ break;
+
+ shrink_dentry_list();
+ cond_resched();
+ }
+ d_drop(dentry);
+ dput(dentry);
+
+ while (!hlist_bl_empty(>s_anon)) {
+ struct select_data data;
+ dentry = hlist_bl_entry(hlist_bl_first(>s_anon), struct
dentry, d_hash);
+
+ INIT_LIST_HEAD();
+ data.start = NULL;
+ data.found = 0;
+
+ d_walk(dentry, , umount_collect, NULL);
+ if (data.found)
+ shrink_dentry_list();
+ cond_resched();
+ }
+}
+
- static enum d_walk_ret check_and_collect(void *_data, struct dentry *dentry)
+ struct detach_data {
+ struct dentry *found;
+ };
+ static enum d_walk_ret do_detach_submounts(void *ptr, struct dentry *dentry)
{
- struct select_data *data = _data;
+ struct detach_data *data = ptr;
- if (d_mountpoint(dentry)) {
- data->found = -EBUSY;
- return D_WALK_QUIT;
- }
+ if (d_mountpoint(dentry))
+ data->found = dentry;
- return select_collect(_data, dentry);
- }
-
- static void check_and_drop(void *_data)
- {
- struct select_data *data = _data;
-
- if (d_mountpoint(data->start))
- data->found = -EBUSY;
- if (!data->found)
- __d_drop(data->start);
+ return data->found ? D_WALK_QUIT : D_WALK_CONTINUE;
}
/**
pgpj1OjZ3JpGO.pgp
Description: PGP signature
linux-next: manual merge of the userns tree with the vfs tree
Hi Eric,
Today's linux-next merge of the userns tree got a conflict in fs/namei.c
between commits 45b1139e249d ("namei: minor vfs_unlink cleanup"),
0e22d7c4652b ("locks: break delegations on unlink"), 5d375b9f8afb
("locks: helper functions for delegation breaking") and 909b30216356
("locks: break delegations on rename") from the vfs tree and commit
40216baa0101 ("vfs: Lazily remove mounts on unlinked files and
directories. v2") from the userns tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc fs/namei.c
index a4a30e396136,a12c1d31d4c8..
--- a/fs/namei.c
+++ b/fs/namei.c
@@@ -3645,22 -3670,16 +3659,20 @@@ int vfs_unlink(struct inode *dir, struc
if (!dir->i_op->unlink)
return -EPERM;
- mutex_lock(>d_inode->i_mutex);
+ mutex_lock(>i_mutex);
- if (d_mountpoint(dentry))
- error = -EBUSY;
- else {
- error = security_inode_unlink(dir, dentry);
+ error = security_inode_unlink(dir, dentry);
+ if (!error) {
++ error = try_break_deleg(target, delegated_inode);
++ if (error)
++ goto out;
+ error = dir->i_op->unlink(dir, dentry);
if (!error) {
- error = try_break_deleg(target, delegated_inode);
- if (error)
- goto out;
- error = dir->i_op->unlink(dir, dentry);
- if (!error)
- dont_mount(dentry);
+ dont_mount(dentry);
+ detach_mounts(dentry);
}
}
- mutex_unlock(>d_inode->i_mutex);
+out:
+ mutex_unlock(>i_mutex);
/* We don't d_delete() NFS sillyrenamed files--they still exist. */
if (!error && !(dentry->d_flags & DCACHE_NFSFS_RENAMED)) {
@@@ -3708,8 -3726,11 +3720,11 @@@ retry_deleg
if (nd.last.name[nd.last.len])
goto slashes;
inode = dentry->d_inode;
- if (!inode)
+ if (d_is_negative(dentry))
goto slashes;
+ error = -EBUSY;
+ if (covered(nd.path.mnt, dentry))
+ goto exit2;
ihold(inode);
error = security_path_unlink(, dentry);
if (error)
@@@ -4063,20 -4040,9 +4075,16 @@@ static int vfs_rename_other(struct inod
return error;
dget(new_dentry);
- if (target)
- mutex_lock(>i_mutex);
+ lock_two_nondirectories(source, target);
- error = -EBUSY;
- if (d_mountpoint(old_dentry)||d_mountpoint(new_dentry))
- goto out;
-
+ error = try_break_deleg(source, delegated_inode);
+ if (error)
+ goto out;
+ if (target) {
+ error = try_break_deleg(target, delegated_inode);
+ if (error)
+ goto out;
+ }
error = old_dir->i_op->rename(old_dir, old_dentry, new_dir, new_dentry);
if (error)
goto out;
pgpVSSTp5OLVP.pgp
Description: PGP signature
linux-next: manual merge of the userns tree with the vfs tree
Hi Eric,
Today's linux-next merge of the userns tree got a conflict in
fs/namespace.c between commit aba809cf0944 ("namespace.c: get rid of
mnt_ghosts") from the vfs tree and commit 484df667efe9 ("vfs: Keep a list
of mounts on a mount point") from the userns tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc fs/namespace.c
index ac2ce8a766e1,78f7c5c9e673..
--- a/fs/namespace.c
+++ b/fs/namespace.c
@@@ -1207,16 -1193,11 +1212,17 @@@ void umount_tree(struct mount *mnt, in
list_del_init(>mnt_list);
__touch_mnt_namespace(p->mnt_ns);
p->mnt_ns = NULL;
+ if (how < 2)
+ p->mnt.mnt_flags |= MNT_SYNC_UMOUNT;
list_del_init(>mnt_child);
if (mnt_has_parent(p)) {
- p->mnt_parent->mnt_ghosts++;
+ list_del_init(>mnt_mp_list);
put_mountpoint(p->mnt_mp);
+ /* move the reference to mountpoint into
->mnt_ex_mountpoint */
+ p->mnt_ex_mountpoint.dentry = p->mnt_mountpoint;
+ p->mnt_ex_mountpoint.mnt = >mnt_parent->mnt;
+ p->mnt_mountpoint = p->mnt.mnt_root;
+ p->mnt_parent = p;
p->mnt_mp = NULL;
}
change_mnt_propagation(p, MS_PRIVATE);
pgpFnj6hlwfHP.pgp
Description: PGP signature
[PATCH 1/2] gpio: davinci: Fix a check for unbanked gpio
From: "Lad, Prabhakar" This patch fixes a check for offset in gpio_to_irq_unbanked() and also assigns gpio_irq, gpio_unbanked of chips[0] to appropriate values which is used in gpio_to_irq_unbanked() function. Reported-by: Grygorii Strashko Signed-off-by: Lad, Prabhakar --- drivers/gpio/gpio-davinci.c |4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/gpio/gpio-davinci.c b/drivers/gpio/gpio-davinci.c index 8847adf..84be701 100644 --- a/drivers/gpio/gpio-davinci.c +++ b/drivers/gpio/gpio-davinci.c @@ -327,7 +327,7 @@ static int gpio_to_irq_unbanked(struct gpio_chip *chip, unsigned offset) * NOTE: we assume for now that only irqs in the first gpio_chip * can provide direct-mapped IRQs to AINTC (up to 32 GPIOs). */ - if (offset < d->irq_base) + if (offset < d->gpio_unbanked) return d->gpio_irq + offset; else return -ENODEV; @@ -419,6 +419,8 @@ static int davinci_gpio_irq_setup(struct platform_device *pdev) /* pass "bank 0" GPIO IRQs to AINTC */ chips[0].chip.to_irq = gpio_to_irq_unbanked; + chips[0].gpio_irq = bank_irq; + chips[0].gpio_unbanked = pdata->gpio_unbanked; binten = BIT(0); /* AINTC handles mask/unmask; GPIO handles triggering */ -- 1.7.9.5 -- 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/
[PATCH 2/2] ARM: davinci: Fix number of resources passed to davinci_gpio_register() call
From: "Lad, Prabhakar"
The davinci_gpio_register() function expects the number of
resources as the second parameter, but size of resources
was passed to it due to which it was causing unexpected
behaviour. This patch fixes the same by passing the
ARRAY_SIZE of resources.
Reported-by: Grygorii Strashko
Signed-off-by: Lad, Prabhakar
---
arch/arm/mach-davinci/dm355.c |2 +-
arch/arm/mach-davinci/dm365.c |2 +-
arch/arm/mach-davinci/dm644x.c |2 +-
arch/arm/mach-davinci/dm646x.c |2 +-
4 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-davinci/dm355.c b/arch/arm/mach-davinci/dm355.c
index ef9ff1f..536ce52 100644
--- a/arch/arm/mach-davinci/dm355.c
+++ b/arch/arm/mach-davinci/dm355.c
@@ -906,7 +906,7 @@ static struct davinci_gpio_platform_data
dm355_gpio_platform_data = {
int __init dm355_gpio_register(void)
{
return davinci_gpio_register(dm355_gpio_resources,
-sizeof(dm355_gpio_resources),
+ARRAY_SIZE(dm355_gpio_resources),
_gpio_platform_data);
}
/*--*/
diff --git a/arch/arm/mach-davinci/dm365.c b/arch/arm/mach-davinci/dm365.c
index 1511a06..9c96520 100644
--- a/arch/arm/mach-davinci/dm365.c
+++ b/arch/arm/mach-davinci/dm365.c
@@ -720,7 +720,7 @@ static struct davinci_gpio_platform_data
dm365_gpio_platform_data = {
int __init dm365_gpio_register(void)
{
return davinci_gpio_register(dm365_gpio_resources,
-sizeof(dm365_gpio_resources),
+ARRAY_SIZE(dm365_gpio_resources),
_gpio_platform_data);
}
diff --git a/arch/arm/mach-davinci/dm644x.c b/arch/arm/mach-davinci/dm644x.c
index 143a321..72a3aa7 100644
--- a/arch/arm/mach-davinci/dm644x.c
+++ b/arch/arm/mach-davinci/dm644x.c
@@ -792,7 +792,7 @@ static struct davinci_gpio_platform_data
dm644_gpio_platform_data = {
int __init dm644x_gpio_register(void)
{
return davinci_gpio_register(dm644_gpio_resources,
-sizeof(dm644_gpio_resources),
+ARRAY_SIZE(dm644_gpio_resources),
_gpio_platform_data);
}
/*--*/
diff --git a/arch/arm/mach-davinci/dm646x.c b/arch/arm/mach-davinci/dm646x.c
index 2a73f29..d1b646c 100644
--- a/arch/arm/mach-davinci/dm646x.c
+++ b/arch/arm/mach-davinci/dm646x.c
@@ -769,7 +769,7 @@ static struct davinci_gpio_platform_data
dm646x_gpio_platform_data = {
int __init dm646x_gpio_register(void)
{
return davinci_gpio_register(dm646x_gpio_resources,
-sizeof(dm646x_gpio_resources),
+ARRAY_SIZE(dm646x_gpio_resources),
_gpio_platform_data);
}
/*--*/
--
1.7.9.5
--
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/
[PATCH 0/2] DaVinci: GPIO: fixes
From: "Lad, Prabhakar" This patch series fixes gpio driver regestration and offset check for unbanked gpio. Lad, Prabhakar (2): gpio: davinci: Fix a check for unbanked gpio ARM: davinci: Fix number of resources passed to davinci_gpio_register() call arch/arm/mach-davinci/dm355.c |2 +- arch/arm/mach-davinci/dm365.c |2 +- arch/arm/mach-davinci/dm644x.c |2 +- arch/arm/mach-davinci/dm646x.c |2 +- drivers/gpio/gpio-davinci.c|4 +++- 5 files changed, 7 insertions(+), 5 deletions(-) -- 1.7.9.5 -- 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/
Re: [patch] fat: double unlock on error path
2013/11/8, OGAWA Hirofumi :
> Dan Carpenter writes:
>
>> There is a stray unlock here which was not intended. I have removed it.
>>
>> Fixes: 3f9f3dfb5755 ('fat: add fat_fallocate operation')
>> Signed-off-by: Dan Carpenter
>>
>> diff --git a/fs/fat/file.c b/fs/fat/file.c
>> index 03f716f..befedee 100644
>> --- a/fs/fat/file.c
>> +++ b/fs/fat/file.c
>> @@ -257,10 +257,8 @@ static long fat_fallocate(struct file *file, int
>> mode,
>> goto error;
>>
>> err = inode_newsize_ok(inode, (len + offset));
>> -if (err) {
>> -mutex_unlock(>i_mutex);
>> +if (err)
>> goto error;
>> -}
>>
>> if (mode & FALLOC_FL_KEEP_SIZE) {
>> /* First compute the number of clusters to be allocated */
>
> Right. Namjae, please include this fix to patchset at next time.
Okay, I will include it in the next patch-set.
Thank you!
>
> Thanks.
> --
> OGAWA Hirofumi
> --
> 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/
>
--
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/
Re: [PATCH 5/6] Squashfs: restructure squashfs_readpage()
On Thu, Nov 07, 2013 at 08:24:24PM +, Phillip Lougher wrote: > Restructure squashfs_readpage() splitting it into separate > functions for datablocks, fragments and sparse blocks. > > Move the memcpying (from squashfs cache entry) implementation of > squashfs_readpage_block into file_cache.c > > This allows different implementations to be supported. > > Signed-off-by: Phillip Lougher > --- > fs/squashfs/Makefile |2 +- > fs/squashfs/file.c | 142 > +++--- > fs/squashfs/file_cache.c | 38 + > fs/squashfs/squashfs.h |7 +++ > 4 files changed, 118 insertions(+), 71 deletions(-) > create mode 100644 fs/squashfs/file_cache.c > > diff --git a/fs/squashfs/Makefile b/fs/squashfs/Makefile > index 5833b96..908c0d9 100644 > --- a/fs/squashfs/Makefile > +++ b/fs/squashfs/Makefile > @@ -4,7 +4,7 @@ > > obj-$(CONFIG_SQUASHFS) += squashfs.o > squashfs-y += block.o cache.o dir.o export.o file.o fragment.o id.o inode.o > -squashfs-y += namei.o super.o symlink.o decompressor.o > +squashfs-y += namei.o super.o symlink.o decompressor.o file_cache.c file_cache.o -- Kind regards, Minchan Kim -- 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/
linux-next: manual merge of the target-updates tree with Linus' tree
Hi Nicholas,
Today's linux-next merge of the target-updates tree got a conflict in
lib/percpu-refcount.c between commit 5e9dd373dea4 ("percpu_refcount:
export symbols") from Linus' tree and commit c9e8d128fe31
("percpu-refcount: Add EXPORT_SYMBOL to use percpu_ref from modules")
from the target-updates tree.
I fixed it up (the version from Linus' tree used EXPORT_SYMBOL_GPL, so I
used that) and can carry the fix as necessary (no action is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
pgpaQfeVLj8gO.pgp
Description: PGP signature
Re: [PATCH 5/6] Squashfs: restructure squashfs_readpage()
On Thu, Nov 07, 2013 at 08:24:24PM +, Phillip Lougher wrote: > Restructure squashfs_readpage() splitting it into separate > functions for datablocks, fragments and sparse blocks. > > Move the memcpying (from squashfs cache entry) implementation of > squashfs_readpage_block into file_cache.c > > This allows different implementations to be supported. > > Signed-off-by: Phillip Lougher Reviewed-by: Minchan Kim -- Kind regards, Minchan Kim -- 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/
Re: [PATCH 4/6] Squashfs: Generalise paging handling in the decompressors (V2)
On Thu, Nov 07, 2013 at 08:24:23PM +, Phillip Lougher wrote: > Further generalise the decompressors by adding a page handler > abstraction. This adds helpers to allow the decompressors > to access and process the output buffers in an implementation > independant manner. > > This allows different types of output buffer to be passed > to the decompressors, with the implementation specific > aspects handled at decompression time, but without the > knowledge being held in the decompressor wrapper code. > > This will allow the decompressors to handle Squashfs > cache buffers, and page cache pages. > > This patch adds the abstraction and an implementation for > the caches. > > V2: also update the code in decompressor_multi*.c Thanks! > > Signed-off-by: Phillip Lougher Reviewed-by: Minchan Kim -- Kind regards, Minchan Kim -- 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/
Re: [PATCH 0/3] makedumpfile: hugepage filtering for vmcore dump
On 11/08/2013 01:21 PM, HATAYAMA Daisuke wrote: > (2013/11/08 14:12), Atsushi Kumagai wrote: >> Hello Jingbai, >> >> (2013/11/07 17:58), Jingbai Ma wrote: >>> On 11/06/2013 10:23 PM, Vivek Goyal wrote: On Wed, Nov 06, 2013 at 02:21:39AM +, Atsushi Kumagai wrote: > (2013/11/06 5:27), Vivek Goyal wrote: >> On Tue, Nov 05, 2013 at 09:45:32PM +0800, Jingbai Ma wrote: >>> This patch set intend to exclude unnecessary hugepages from vmcore dump >>> file. >>> >>> This patch requires the kernel patch to export necessary data >>> structures into >>> vmcore: "kexec: export hugepage data structure into vmcoreinfo" >>> http://lists.infradead.org/pipermail/kexec/2013-November/009997.html >>> >>> This patch introduce two new dump levels 32 and 64 to exclude all >>> unused and >>> active hugepages. The level to exclude all unnecessary pages will be >>> 127 now. >> >> Interesting. Why hugepages should be treated any differentely than normal >> pages? >> >> If user asked to filter out free page, then it should be filtered and >> it should not matter whether it is a huge page or not? > > I'm making a RFC patch of hugepages filtering based on such policy. > > I attach the prototype version. > It's able to filter out also THPs, and suitable for cyclic processing > because it depends on mem_map and looking up it can be divided into > cycles. This is the same idea as page_is_buddy(). > > So I think it's better. Agreed. Being able to treat hugepages in same manner as other pages sounds good. Jingbai, looks good to you? >>> >>> It looks good to me. >>> >>> My only concern is by this way, we only can exclude all hugepage together, >>> but can't exclude the free hugepages only. I'm not sure if user need to >>> dump out the activated hugepage only. >>> >>> Kumagai-san, please correct me, if I'm wrong. >> >> Yes, my patch treats all allocated hugetlbfs pages as user pages, >> doesn't distinguish whether the pages are actually used or not. >> I made so because I guess it's enough for almost all users. >> >> We can introduce new dump level after it's needed actually, >> but I don't think now is the time. To introduce it without >> demand will make this tool just more complex. >> > > Typically, users would allocate huge pages as much as actually they use only, > in order not to waste system memory. So, this design seems reasonable. > OK, It looks reasonable. Thanks! -- Thanks, Jingbai Ma -- 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/
Re: [PATCH 2/2] cpufreq: conservative: set requested_freq to policy max when it is over policy max
On 8 November 2013 10:53, Xiaoguang Chen wrote: > When requested_freq is over policy->max, set it to policy->max. > This can help to speed up decreasing frequency. > > Signed-off-by: Xiaoguang Chen > --- > drivers/cpufreq/cpufreq_conservative.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/drivers/cpufreq/cpufreq_conservative.c > b/drivers/cpufreq/cpufreq_conservative.c > index 218460f..25a70d0 100644 > --- a/drivers/cpufreq/cpufreq_conservative.c > +++ b/drivers/cpufreq/cpufreq_conservative.c > @@ -68,6 +68,9 @@ static void cs_check_cpu(int cpu, unsigned int load) > > dbs_info->requested_freq += get_freq_target(cs_tuners, > policy); > > + if (dbs_info->requested_freq > policy->max) > + dbs_info->requested_freq = policy->max; > + > __cpufreq_driver_target(policy, dbs_info->requested_freq, > CPUFREQ_RELATION_H); > return; Acked-by: Viresh Kumar -- 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/
[PATCH 1/2] cpufreq: conservative: fix requested_freq reduction issue
When decreasing frequency, requested_freq may be less than
freq_target, So requested_freq minus freq_target may be negative,
But reqested_freq's unit is unsigned int, then the negative result
will be one larger integer which may be even higher than
requested_freq.
This patch is to fix such issue. when result becomes negative,
set requested_freq as the min value of policy.
Signed-off-by: Xiaoguang Chen
Acked-by: Viresh Kumar
---
drivers/cpufreq/cpufreq_conservative.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/cpufreq/cpufreq_conservative.c
b/drivers/cpufreq/cpufreq_conservative.c
index f62d822..218460f 100644
--- a/drivers/cpufreq/cpufreq_conservative.c
+++ b/drivers/cpufreq/cpufreq_conservative.c
@@ -80,13 +80,18 @@ static void cs_check_cpu(int cpu, unsigned int load)
/* Check for frequency decrease */
if (load < cs_tuners->down_threshold) {
+ unsigned int freq_target;
/*
* if we cannot reduce the frequency anymore, break out early
*/
if (policy->cur == policy->min)
return;
- dbs_info->requested_freq -= get_freq_target(cs_tuners, policy);
+ freq_target = get_freq_target(cs_tuners, policy);
+ if (dbs_info->requested_freq > freq_target)
+ dbs_info->requested_freq -= freq_target;
+ else
+ dbs_info->requested_freq = policy->min;
__cpufreq_driver_target(policy, dbs_info->requested_freq,
CPUFREQ_RELATION_L);
--
1.8.0
--
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/
[PATCH 2/2] cpufreq: conservative: set requested_freq to policy max when it is over policy max
When requested_freq is over policy->max, set it to policy->max. This can help to speed up decreasing frequency. Signed-off-by: Xiaoguang Chen --- drivers/cpufreq/cpufreq_conservative.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/cpufreq/cpufreq_conservative.c b/drivers/cpufreq/cpufreq_conservative.c index 218460f..25a70d0 100644 --- a/drivers/cpufreq/cpufreq_conservative.c +++ b/drivers/cpufreq/cpufreq_conservative.c @@ -68,6 +68,9 @@ static void cs_check_cpu(int cpu, unsigned int load) dbs_info->requested_freq += get_freq_target(cs_tuners, policy); + if (dbs_info->requested_freq > policy->max) + dbs_info->requested_freq = policy->max; + __cpufreq_driver_target(policy, dbs_info->requested_freq, CPUFREQ_RELATION_H); return; -- 1.8.0 -- 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/
Re: [PATCH 0/3] makedumpfile: hugepage filtering for vmcore dump
Hello Jingbai, (2013/11/07 17:58), Jingbai Ma wrote: > On 11/06/2013 10:23 PM, Vivek Goyal wrote: >> On Wed, Nov 06, 2013 at 02:21:39AM +, Atsushi Kumagai wrote: >>> (2013/11/06 5:27), Vivek Goyal wrote: On Tue, Nov 05, 2013 at 09:45:32PM +0800, Jingbai Ma wrote: > This patch set intend to exclude unnecessary hugepages from vmcore dump > file. > > This patch requires the kernel patch to export necessary data structures > into > vmcore: "kexec: export hugepage data structure into vmcoreinfo" > http://lists.infradead.org/pipermail/kexec/2013-November/009997.html > > This patch introduce two new dump levels 32 and 64 to exclude all unused > and > active hugepages. The level to exclude all unnecessary pages will be 127 > now. Interesting. Why hugepages should be treated any differentely than normal pages? If user asked to filter out free page, then it should be filtered and it should not matter whether it is a huge page or not? >>> >>> I'm making a RFC patch of hugepages filtering based on such policy. >>> >>> I attach the prototype version. >>> It's able to filter out also THPs, and suitable for cyclic processing >>> because it depends on mem_map and looking up it can be divided into >>> cycles. This is the same idea as page_is_buddy(). >>> >>> So I think it's better. >> >> Agreed. Being able to treat hugepages in same manner as other pages >> sounds good. >> >> Jingbai, looks good to you? > > It looks good to me. > > My only concern is by this way, we only can exclude all hugepage together, > but can't exclude the free hugepages only. I'm not sure if user need to dump > out the activated hugepage only. > > Kumagai-san, please correct me, if I'm wrong. Yes, my patch treats all allocated hugetlbfs pages as user pages, doesn't distinguish whether the pages are actually used or not. I made so because I guess it's enough for almost all users. We can introduce new dump level after it's needed actually, but I don't think now is the time. To introduce it without demand will make this tool just more complex. Thanks Atsushi Kumagai -- 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/
Re: [PATCH 0/3] makedumpfile: hugepage filtering for vmcore dump
(2013/11/08 14:12), Atsushi Kumagai wrote: > Hello Jingbai, > > (2013/11/07 17:58), Jingbai Ma wrote: >> On 11/06/2013 10:23 PM, Vivek Goyal wrote: >>> On Wed, Nov 06, 2013 at 02:21:39AM +, Atsushi Kumagai wrote: (2013/11/06 5:27), Vivek Goyal wrote: > On Tue, Nov 05, 2013 at 09:45:32PM +0800, Jingbai Ma wrote: >> This patch set intend to exclude unnecessary hugepages from vmcore dump >> file. >> >> This patch requires the kernel patch to export necessary data structures >> into >> vmcore: "kexec: export hugepage data structure into vmcoreinfo" >> http://lists.infradead.org/pipermail/kexec/2013-November/009997.html >> >> This patch introduce two new dump levels 32 and 64 to exclude all unused >> and >> active hugepages. The level to exclude all unnecessary pages will be 127 >> now. > > Interesting. Why hugepages should be treated any differentely than normal > pages? > > If user asked to filter out free page, then it should be filtered and > it should not matter whether it is a huge page or not? I'm making a RFC patch of hugepages filtering based on such policy. I attach the prototype version. It's able to filter out also THPs, and suitable for cyclic processing because it depends on mem_map and looking up it can be divided into cycles. This is the same idea as page_is_buddy(). So I think it's better. >>> >>> Agreed. Being able to treat hugepages in same manner as other pages >>> sounds good. >>> >>> Jingbai, looks good to you? >> >> It looks good to me. >> >> My only concern is by this way, we only can exclude all hugepage together, >> but can't exclude the free hugepages only. I'm not sure if user need to dump >> out the activated hugepage only. >> >> Kumagai-san, please correct me, if I'm wrong. > > Yes, my patch treats all allocated hugetlbfs pages as user pages, > doesn't distinguish whether the pages are actually used or not. > I made so because I guess it's enough for almost all users. > > We can introduce new dump level after it's needed actually, > but I don't think now is the time. To introduce it without > demand will make this tool just more complex. > Typically, users would allocate huge pages as much as actually they use only, in order not to waste system memory. So, this design seems reasonable. -- Thanks. HATAYAMA, Daisuke -- 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/
Re: [PATCH v2 2/2] clocksource: sh_tmu: Add clk_prepare/unprepare support
On Thu, Nov 07, 2013 at 02:40:49PM +0100, Daniel Lezcano wrote: > On 10/31/2013 06:24 AM, Simon Horman wrote: > >On Tue, Oct 29, 2013 at 03:31:37PM +0100, Laurent Pinchart wrote: > >>Prepare the clock at probe time, as there is no other appropriate place > >>in the driver where we're allowed to sleep. > >> > >>Cc: Daniel Lezcano > >>Cc: linux-kernel@vger.kernel.org > >>Signed-off-by: Laurent Pinchart > > > >Thanks, I have queued this up. > > Ok, so those patches go through your tree, right ? > > I have been out for the Linaro connect but I saw you picked them. In > the future, I would prefer to take them in my tree as they fall > under the drivers/clocksource maintainer's umbrella. I was planning to send a pull request to you. But if you would rather just pick them up directly that is quite fine by me. Acked-by: Simon Horman -- 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/
[PATCH v3] usb: gadget: f_mass_storage: call try_to_freeze only when its safe
Call try_to_freeze() in sleep_thread() only when it's safe to sleep.
do_read() and do_write() calls sleep_thread with lock held.
Make sure these won't call try_to_freeze() by passing can_freeze flag
to sleep_thread.
Calling try_to_freeze() with a lock hold was done since day one in
f_mass_storage but since commit 0f9548ca1 ("lockdep: check that no
locks held at freeze time") lockdep complains about it.
Signed-off-by: George Cherian
Acked-by: Sebastian Andrzej Siewior
Acked-by: Alan Stern
---
change from v1 -> v2
amend the commit log
v2 -> v3
amend the comit log again
drivers/usb/gadget/f_mass_storage.c | 23 ---
1 file changed, 12 insertions(+), 11 deletions(-)
diff --git a/drivers/usb/gadget/f_mass_storage.c
b/drivers/usb/gadget/f_mass_storage.c
index a03ba2c..f2d0d4b 100644
--- a/drivers/usb/gadget/f_mass_storage.c
+++ b/drivers/usb/gadget/f_mass_storage.c
@@ -602,13 +602,14 @@ static bool start_out_transfer(struct fsg_common *common,
struct fsg_buffhd *bh)
return true;
}
-static int sleep_thread(struct fsg_common *common)
+static int sleep_thread(struct fsg_common *common, bool can_freeze)
{
int rc = 0;
/* Wait until a signal arrives or we are woken up */
for (;;) {
- try_to_freeze();
+ if (can_freeze)
+ try_to_freeze();
set_current_state(TASK_INTERRUPTIBLE);
if (signal_pending(current)) {
rc = -EINTR;
@@ -682,7 +683,7 @@ static int do_read(struct fsg_common *common)
/* Wait for the next buffer to become available */
bh = common->next_buffhd_to_fill;
while (bh->state != BUF_STATE_EMPTY) {
- rc = sleep_thread(common);
+ rc = sleep_thread(common, false);
if (rc)
return rc;
}
@@ -937,7 +938,7 @@ static int do_write(struct fsg_common *common)
}
/* Wait for something to happen */
- rc = sleep_thread(common);
+ rc = sleep_thread(common, false);
if (rc)
return rc;
}
@@ -1504,7 +1505,7 @@ static int throw_away_data(struct fsg_common *common)
}
/* Otherwise wait for something to happen */
- rc = sleep_thread(common);
+ rc = sleep_thread(common, true);
if (rc)
return rc;
}
@@ -1625,7 +1626,7 @@ static int send_status(struct fsg_common *common)
/* Wait for the next buffer to become available */
bh = common->next_buffhd_to_fill;
while (bh->state != BUF_STATE_EMPTY) {
- rc = sleep_thread(common);
+ rc = sleep_thread(common, true);
if (rc)
return rc;
}
@@ -1828,7 +1829,7 @@ static int do_scsi_command(struct fsg_common *common)
bh = common->next_buffhd_to_fill;
common->next_buffhd_to_drain = bh;
while (bh->state != BUF_STATE_EMPTY) {
- rc = sleep_thread(common);
+ rc = sleep_thread(common, true);
if (rc)
return rc;
}
@@ -2174,7 +2175,7 @@ static int get_next_command(struct fsg_common *common)
/* Wait for the next buffer to become available */
bh = common->next_buffhd_to_fill;
while (bh->state != BUF_STATE_EMPTY) {
- rc = sleep_thread(common);
+ rc = sleep_thread(common, true);
if (rc)
return rc;
}
@@ -2193,7 +2194,7 @@ static int get_next_command(struct fsg_common *common)
/* Wait for the CBW to arrive */
while (bh->state != BUF_STATE_FULL) {
- rc = sleep_thread(common);
+ rc = sleep_thread(common, true);
if (rc)
return rc;
}
@@ -2379,7 +2380,7 @@ static void handle_exception(struct fsg_common *common)
}
if (num_active == 0)
break;
- if (sleep_thread(common))
+ if (sleep_thread(common, true))
return;
}
@@ -2516,7 +2517,7 @@ static int fsg_main_thread(void *common_)
}
if (!common->running) {
- sleep_thread(common);
+ sleep_thread(common, true);
continue;
}
--
1.8.1
--
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/
Re: [PATCH v3] ext4: Fix reading of extended tv_sec (bug 23732)
On Thu, Nov 07, 2013 at 06:26:47PM -0500, David Turner wrote:
> In ext4, the bottom two bits of {a,c,m}time_extra are used to extend
> the {a,c,m}time fields, deferring the year 2038 problem to the year
> 2446. The representation (which this patch does not alter) is a bit
> hackish, in that the most-significant bit is no longer (alone)
> sufficient to indicate the sign. That's because we're representing an
> asymmetric range, with seven times as many positive values as
> negative.
>
> When decoding these extended fields, for times whose bottom 32 bits
> would represent a negative number, sign extension causes the 64-bit
> extended timestamp to be negative as well, which is not what's
> intended. This patch corrects that issue, so that the only negative
> {a,c,m}times are those between 1901 and 1970 (as per 32-bit signed
> timestamps).
>
> Signed-off-by: David Turner
> Reported-by: Mark Harris
> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=23732
> Reviewed-by: Jan Kara
Thanks, applied.
- Ted
--
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/
Re: [PATCH 00/10] leds: lp5521,5523: restore device attributes for running LED patterns
Hi Pali, Sorry for the late reply. On 10/26/2013 03:21 AM, Pali Rohár wrote: On Friday 25 October 2013 19:10:07 Bryan Wu wrote: On Fri, Oct 25, 2013 at 9:38 AM, Pali Rohár wrote: On Tuesday 13 August 2013 23:04:14 Bryan Wu wrote: On Thu, Aug 8, 2013 at 12:59 AM, Milo Kim wrote: This patch-set resolves the application conflict by restoring sysfs files. For LP5521 engine1/2/3_mode engine1/2/3_load For LP5523 engine1/2/3_mode engine1/2/3_load engine1/2/3_leds Those attributes are accessed when LED pattern is run by custom application. Those were removed when LED pattern interface was changed to generic firmware interface. Please refer to commits below. git commit 9ce7cb170f97f83a78dc948bf7d25690f15e1328 (leds-lp5521: use generic firmware interface) git commit db6eaf8388a413a5ee1b4547ce78506b9c6456b0 (leds-lp5523: use generic firmware interface) Necessary attributes are restored in this patch-set. (Other changes) New data structure is added for handling values from/to an application. Few code fixes for reducing writing I2C commands. Add LP55xx common macros for code refactoring. Documentation updates. You can also pull from the location below This branch is based on 'for-next' of linux-leds. https://github.com/milokim/lp55xx.git resolve-missing-sysfs Thanks, I've already merged the whole patchset in my -devel branch [1]. Pali, could you please help to test it on your hardware? Just grab my -devel branch and build then run. Thanks, -Bryan Hi, I see that all your patches are part of 3.12-rc5 kernel. Now I tested this example led program: # Clearing LED-state to be sure echo "disabled" > /sys/class/i2c-adapter/i2c-2/2-0032/engine1_mode echo "disabled" > /sys/class/i2c-adapter/i2c-2/2-0032/engine2_mode echo 0 > /sys/class/leds/lp5523:r/brightness echo 0 > /sys/class/leds/lp5523:g/brightness echo 0 > /sys/class/leds/lp5523:b/brightness # Setting yellow light pattern and running it echo "load" > /sys/class/i2c-adapter/i2c-2/2-0032/engine1_mode echo "01100" > /sys/class/i2c-adapter/i2c-2/2-0032/engine1_leds echo "9d804000427f0d7f7f007f004200" > /sys/class/i2c-adapter/i2c-2/2-0032/engine1_load echo "load" > /sys/class/i2c-adapter/i2c-2/2-0032/engine2_mode echo "0" > /sys/class/i2c-adapter/i2c-2/2-0032/engine2_leds echo "9d80" > /sys/class/i2c-adapter/i2c-2/2-0032/engine2_load echo "run" > /sys/class/i2c-adapter/i2c-2/2-0032/engine2_mode echo "run" > /sys/class/i2c-adapter/i2c-2/2-0032/engine1_mode echo 20 > /sys/class/leds/lp5523:r/led_current echo 2 > /sys/class/leds/lp5523:g/led_current echo 0 > /sys/class/leds/lp5523:b/led_current In the latest LP5523 driver, I just found wrong operation mode setting in case of multiple engine used. (please find a patch below) All sysfs entries exists and every echo returned 0. But led does not start blinking that yellow ligh pattern. So it not working on 3.12-rc5 kernel :-( OK, great! Do you still remember which kernel version works on you system? Milo, do you have time to take a look? I bet it's a regression somewhere. Thanks, -Bryan I do not know which version. Now I tried pattern example from Documentation/leds/leds-lp55xx.txt which using new API. echo 2 > /sys/class/i2c-adapter/i2c-2/2-0032/select_engine echo 1 > /sys/class/firmware/lp5523/loading echo "9d8044ff05ff437f" > /sys/class/firmware/lp5523/data echo 0 > /sys/class/firmware/lp5523/loading echo 1 > /sys/class/i2c-adapter/i2c-2/2-0032/run_engine But it failed at second command. In directory /sys/class/firmware/ I have only one file with name timeout. Nothing more, no lp5523 folder. I can't reproduce this issue but I found some duplicated mutex problem. But in my case, I could found /sys/class/firmware/lp5523 directory. Is any permission issue? Anyway, I've added fixed mutex code below. Could you check this patch below? If it's resolved, then I'll send official patch-set. 8< 8< --- From dad27e0d834a5635232116569aaa1fa471ac46bf Mon Sep 17 00:00:00 2001 From: Milo Kim Date: Fri, 8 Nov 2013 13:43:33 +0900 Subject: [PATCH] leds: lp5523: Fix multiple engine usage bug and remove duplicated mutex Fix multiple engine usage bug: Whenever the engine is loaded by the user-application, the operation mode is reset first. But it has a problem in case of multiple engine used because previous engine settings are cleared. The driver should update not whole 8bits but each engine bits by masking. Remove duplicate mutex: It can be a problem when a pattern is loaded via the firmware interface. LP55xx common driver has already locked the mutex in 'lp55xx_firmware_loaded()'. So it should be deleted. Signed-off-by: Milo Kim --- drivers/leds/leds-lp5523.c | 14 +- 1 file changed, 9 insertions(+), 5
Re: [PATCH] cpufreq: conservative: fix requested_freq reduction issue
2013/11/8 Viresh Kumar : > On 8 November 2013 10:31, Xiaoguang Chen wrote: >> Hi, Viresh, Sorry for the late reply. > > That's fine :) > >> I'll prepare the patch. > > Thanks. > >> BTW, do you think we should set requeste_freq to policy->max when such >> condition happens? > > I thought about that earlier, but then thought this would be a cleaner > solution. > And guess what, I was wrong.. There is one scenario for which we need to > set requested_freq correctly.. > > Suppose we have requested_freq currently greater than policy->max and load > decreases. We will start decreasing requested_freq but it will take > one iteration > to make it equal to max, which is not we want.. So we actually need to set > it to max when it gets over it. > > So, don't do the change I asked for, i.e. replacing == with >=. But > update existing > code: > > dbs_info->requested_freq += get_freq_target(cs_tuners, policy); > > this way: > > dbs_info->requested_freq += get_freq_target(cs_tuners, policy); > if (dbs_info->requested_freq > policy->max) > dbs_info->requested_freq = policy->max; OK, patch will be sent out later Xiaoguang -- 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/
Re: [patch] fat: double unlock on error path
Dan Carpenter writes:
> There is a stray unlock here which was not intended. I have removed it.
>
> Fixes: 3f9f3dfb5755 ('fat: add fat_fallocate operation')
> Signed-off-by: Dan Carpenter
>
> diff --git a/fs/fat/file.c b/fs/fat/file.c
> index 03f716f..befedee 100644
> --- a/fs/fat/file.c
> +++ b/fs/fat/file.c
> @@ -257,10 +257,8 @@ static long fat_fallocate(struct file *file, int mode,
> goto error;
>
> err = inode_newsize_ok(inode, (len + offset));
> - if (err) {
> - mutex_unlock(>i_mutex);
> + if (err)
> goto error;
> - }
>
> if (mode & FALLOC_FL_KEEP_SIZE) {
> /* First compute the number of clusters to be allocated */
Right. Namjae, please include this fix to patchset at next time.
Thanks.
--
OGAWA Hirofumi
--
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/
Re: [PATCH] cpufreq: conservative: fix requested_freq reduction issue
On 8 November 2013 10:31, Xiaoguang Chen wrote: > Hi, Viresh, Sorry for the late reply. That's fine :) > I'll prepare the patch. Thanks. > BTW, do you think we should set requeste_freq to policy->max when such > condition happens? I thought about that earlier, but then thought this would be a cleaner solution. And guess what, I was wrong.. There is one scenario for which we need to set requested_freq correctly.. Suppose we have requested_freq currently greater than policy->max and load decreases. We will start decreasing requested_freq but it will take one iteration to make it equal to max, which is not we want.. So we actually need to set it to max when it gets over it. So, don't do the change I asked for, i.e. replacing == with >=. But update existing code: dbs_info->requested_freq += get_freq_target(cs_tuners, policy); this way: dbs_info->requested_freq += get_freq_target(cs_tuners, policy); if (dbs_info->requested_freq > policy->max) dbs_info->requested_freq = policy->max; -- 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/
Re: [PATCH] cpufreq: conservative: fix requested_freq reduction issue
Hi, Viresh, Sorry for the late reply. I'll prepare the patch. BTW, do you think we should set requeste_freq to policy->max when such condition happens? Thanks Xiaoguang 2013/11/8 Viresh Kumar : > On 8 November 2013 00:36, Stratos Karafotis wrote: >> I think the existing code already checks if the requested_freq is greater >> than policy->max in __cpufreq_driver_target. > > Yes it does. But the problem is: > - cs_check_cpu() sets requested_freq above policy->max > - We execute following code because (requested_freq != policy->max) > > dbs_info->requested_freq += get_freq_target(cs_tuners, policy); > __cpufreq_driver_target(policy, dbs_info->requested_freq, > CPUFREQ_RELATION_H); > - In __cpufreq_driver_target(), we don't do anything and return early.. > - Above will keep on repeating all the time.. > > If we change the code as I have suggested it to be: > - After first loop where requested_freq went over policy->max, we will > return early from cs_check_cpu(), but we have already set freq to max.. > >> If we put this check earlier, cpufreq will never reach policy->max. > > Can you please explain why do you see that happening? -- 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/
linux-next: manual merge of the tip tree with the net-next tree
Hi all,
Today's linux-next merge of the tip tree got a conflict in
drivers/net/virtio_net.c between commit 9bb8ca86075f ("virtio-net: switch
to use XPS to choose txq") from the net-next tree and commit 827da44c6141
("net: Explicitly initialize u64_stats_sync structures for lockdep") from
the tip tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc drivers/net/virtio_net.c
index 7d0eff710913,ee384f3d612b..
--- a/drivers/net/virtio_net.c
+++ b/drivers/net/virtio_net.c
@@@ -1584,6 -1569,18 +1584,14 @@@ static int virtnet_probe(struct virtio_
if (vi->stats == NULL)
goto free;
+ for_each_possible_cpu(i) {
+ struct virtnet_stats *virtnet_stats;
+ virtnet_stats = per_cpu_ptr(vi->stats, i);
+ u64_stats_init(_stats->tx_syncp);
+ u64_stats_init(_stats->rx_syncp);
+ }
+
+
- vi->vq_index = alloc_percpu(int);
- if (vi->vq_index == NULL)
- goto free_stats;
-
mutex_init(>config_lock);
vi->config_enable = true;
INIT_WORK(>config_work, virtnet_config_changed_work);
pgpo18aydDZ0C.pgp
Description: PGP signature
Re: [PATCH] cpufreq: conservative: fix requested_freq reduction issue
On 8 November 2013 00:36, Stratos Karafotis wrote: > I think the existing code already checks if the requested_freq is greater > than policy->max in __cpufreq_driver_target. Yes it does. But the problem is: - cs_check_cpu() sets requested_freq above policy->max - We execute following code because (requested_freq != policy->max) dbs_info->requested_freq += get_freq_target(cs_tuners, policy); __cpufreq_driver_target(policy, dbs_info->requested_freq, CPUFREQ_RELATION_H); - In __cpufreq_driver_target(), we don't do anything and return early.. - Above will keep on repeating all the time.. If we change the code as I have suggested it to be: - After first loop where requested_freq went over policy->max, we will return early from cs_check_cpu(), but we have already set freq to max.. > If we put this check earlier, cpufreq will never reach policy->max. Can you please explain why do you see that happening? -- 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/
Re: [PATCH] cpufreq: conservative: fix requested_freq reduction issue
On 8 November 2013 00:27, Rafael J. Wysocki wrote: > On Thursday, November 07, 2013 10:39:38 AM Viresh Kumar wrote: >> We need another patch for fixing the other part of code where we >> increase freq.. >> We need to replace: >> >> if (dbs_info->requested_freq == policy->max) >> return; >> >> with >> >> if (dbs_info->requested_freq >= policy->max) >> return; >> >> So, that we don't run unnecessary code :) > > Care to prepare a patch? I wanted to give a chance to Xiaoguang to generate a patch for us :) Lets wait for his reply, otherwise I will do it. -- 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/
[PATCH] perf tool: Round mmap pages to power 2
Currently perf requires the -m / --mmap_pages option to be a power of 2.
To be more user friendly perf should automatically round this up to the
next power of 2.
Currently:
$ perf record -m 3 -a -- sleep 1
--mmap_pages/-m value must be a power of two.sleep: Terminated
With patch:
$ perf record -m 3 -a -- sleep 1
rounding mmap pages size to 16384 (4 pages)
...
Signed-off-by: David Ahern
Suggested-by: Ingo Molnar
Cc: Ingo Molnar
Cc: Jiri Olsa
---
tools/perf/util/evlist.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/tools/perf/util/evlist.c b/tools/perf/util/evlist.c
index b939221efd8d..9ec3a5a45f22 100644
--- a/tools/perf/util/evlist.c
+++ b/tools/perf/util/evlist.c
@@ -722,11 +722,6 @@ int perf_evlist__parse_mmap_pages(const struct option
*opt, const char *str,
if (val != (unsigned long) -1) {
/* we got file size value */
pages = PERF_ALIGN(val, page_size) / page_size;
- if (pages < (1UL << 31) && !is_power_of_2(pages)) {
- pages = next_pow2(pages);
- pr_info("rounding mmap pages size to %lu (%lu pages)\n",
- pages * page_size, pages);
- }
} else {
/* we got pages count value */
char *eptr;
@@ -737,6 +732,12 @@ int perf_evlist__parse_mmap_pages(const struct option
*opt, const char *str,
}
}
+ if (pages < (1UL << 31) && !is_power_of_2(pages)) {
+ pages = next_pow2(pages);
+ pr_info("rounding mmap pages size to %lu (%lu pages)\n",
+ pages * page_size, pages);
+ }
+
if (pages > UINT_MAX || pages > SIZE_MAX / page_size) {
pr_err("--mmap_pages/-m value too big\n");
return -1;
--
1.8.3.4 (Apple Git-47)
--
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/
[Consult] Do we need related web site link in "./COPYING" file?
Hello All: I guess COPYING is our GPL License file, it already contents related Free Software Foundation address. Do we also need content related web site link? When make patch for "arch/arm64/include/uapi/", "scripts/checkpatch.pl" will report the issue below: ERROR: Do not include the paragraph about writing to the Free Software Foundation's mailing address from the sample GPL notice. The FSF has changed addresses in the past, and may do so again. Linux already includes a copy of the GPL. #209: FILE: arch/arm64/include/uapi/asm/signal.h:13: * You should have received a copy of the GNU General Public License$ I guess, "scrpits/checkpatch.pl" wants to say: "the Linux GPL copy already contents related web site, so need not 'hard code' them in another place". BTW: I find some "^L" in COPYING file, are they for page separation? Welcome any suggestions or completions. Thanks. -- Chen Gang -- 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/
[PATCH 1/2] perf record: Move existing write_output into helper function
Code move only; no logic changes. In preparation for the mmap
based output option in the next patch.
Signed-off-by: David Ahern
Cc: Ingo Molnar
Cc: Frederic Weisbecker
Cc: Peter Zijlstra
Cc: Jiri Olsa
Cc: Namhyung Kim
Cc: Mike Galbraith
Cc: Stephane Eranian
---
tools/perf/builtin-record.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/tools/perf/builtin-record.c b/tools/perf/builtin-record.c
index 15280b5e5574..6e6a41856c41 100644
--- a/tools/perf/builtin-record.c
+++ b/tools/perf/builtin-record.c
@@ -76,7 +76,7 @@ struct perf_record {
longsamples;
};
-static int write_output(struct perf_record *rec, void *buf, size_t size)
+static int do_write_output(struct perf_record *rec, void *buf, size_t size)
{
struct perf_data_file *file = >file;
@@ -97,6 +97,11 @@ static int write_output(struct perf_record *rec, void *buf,
size_t size)
return 0;
}
+static int write_output(struct perf_record *rec, void *buf, size_t size)
+{
+ return do_write_output(rec, buf, size);
+}
+
static int process_synthesized_event(struct perf_tool *tool,
union perf_event *event,
struct perf_sample *sample __maybe_unused,
--
1.8.3.4 (Apple Git-47)
--
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/
[PATCH 0/2] perf: mmap output file - v4
Version 4. I think I have addressed all of Ingo's comments plus a few extra refactorings. Ingo: updated responses to your comment: 1. out-pages and rounding up to power of 2 - leveraging the same code used for mmap-pages. A follow on patch will do that for both mmap use cases. 2. what happens if a user sets out-pages to zero - the parsing function does not allow it David Ahern (2): perf record: Move existing write_output into helper function perf record: mmap output file - v4 tools/perf/Documentation/perf-record.txt | 5 + tools/perf/builtin-record.c | 162 ++- 2 files changed, 166 insertions(+), 1 deletion(-) -- 1.8.3.4 (Apple Git-47) -- 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/
[PATCH -tip 2/2] ftrace: Introduce nr_saved_cmdlines I/F
Introduce nr_saved_cmdlines I/F for changing the number of pid-comm list.
saved_cmdlines can store 128 command names using SAVED_CMDLINES now, but
'no-existing processes' names are often lost in saved_cmdlines when we
read trace data. So, by introducing nr_saved_cmdlines I/F, the rule storing
128 command names is changed to the command numbers defined users.
When we write a value to nr_saved_cmdlines, the number of the value will
be stored in pid-comm list:
# echo 1024 > /sys/kernel/debug/tracing/nr_saved_cmdlines
Here, 1024 command names are stored. The default number is 128 and the maximum
number is PID_MAX_DEFAULT (=32768 if CONFIG_BASE_SMALL is not set). So, if we
want to avoid to lose command names, we need to set 32768 to nr_saved_cmdlines.
We can read the maximum number of the list:
# cat /sys/kernel/debug/tracing/nr_saved_cmdlines
128
Signed-off-by: Yoshihiro YUNOMAE
Cc: Steven Rostedt
Cc: Frederic Weisbecker
Cc: Ingo Molnar
Cc: linux-kernel@vger.kernel.org
---
kernel/trace/trace.c | 211 +-
1 file changed, 189 insertions(+), 22 deletions(-)
diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
index 90cf668..afdcdfd 100644
--- a/kernel/trace/trace.c
+++ b/kernel/trace/trace.c
@@ -1237,22 +1237,96 @@ void tracing_reset_all_online_cpus(void)
}
}
-#define SAVED_CMDLINES 128
+#define SAVED_CMDLINES_DEFAULT 128
#define NO_CMDLINE_MAP UINT_MAX
-static unsigned map_pid_to_cmdline[PID_MAX_DEFAULT+1];
-static unsigned map_cmdline_to_pid[SAVED_CMDLINES];
-static char saved_cmdlines[SAVED_CMDLINES][TASK_COMM_LEN];
-static int cmdline_idx;
static arch_spinlock_t trace_cmdline_lock = __ARCH_SPIN_LOCK_UNLOCKED;
+struct saved_cmdlines_buffer {
+ unsigned map_pid_to_cmdline[PID_MAX_DEFAULT+1];
+ unsigned *map_cmdline_to_pid;
+ unsigned cmdline_num;
+ int cmdline_idx;
+ char *saved_cmdlines;
+};
+static struct saved_cmdlines_buffer *savedcmd;
/* temporary disable recording */
static atomic_t trace_record_cmdline_disabled __read_mostly;
-static void trace_init_cmdlines(void)
+static inline char *get_cmdline(int idx)
+{
+ return >saved_cmdlines[idx*TASK_COMM_LEN];
+}
+
+static inline void set_cmdline(int idx, char *cmdline)
+{
+ memcpy(get_cmdline(idx), cmdline, TASK_COMM_LEN);
+}
+
+static int allocate_cmdlines_buffer(unsigned int val,
+ struct saved_cmdlines_buffer *s)
{
- memset(_pid_to_cmdline, NO_CMDLINE_MAP, sizeof(map_pid_to_cmdline));
- memset(_cmdline_to_pid, NO_CMDLINE_MAP, sizeof(map_cmdline_to_pid));
- cmdline_idx = 0;
+ s->map_cmdline_to_pid = kmalloc(val*sizeof(unsigned), GFP_KERNEL);
+ if (!s->map_cmdline_to_pid)
+ goto out;
+
+ s->saved_cmdlines = kmalloc(val*TASK_COMM_LEN, GFP_KERNEL);
+ if (!s->saved_cmdlines)
+ goto out_free_map_cmdline_to_pid;
+
+ return 0;
+
+out_free_map_cmdline_to_pid:
+ kfree(s->map_cmdline_to_pid);
+out:
+ return -ENOMEM;
+}
+
+static void trace_init_cmdlines_buffer(unsigned int val,
+ struct saved_cmdlines_buffer *s)
+{
+ s->cmdline_idx = 0;
+ s->cmdline_num = val;
+ memset(>map_pid_to_cmdline, NO_CMDLINE_MAP,
+ sizeof(s->map_pid_to_cmdline));
+ memset(s->map_cmdline_to_pid, NO_CMDLINE_MAP, val*sizeof(unsigned));
+}
+
+static int trace_create_savedcmd(void)
+{
+ int ret;
+
+ savedcmd = kmalloc(sizeof(struct saved_cmdlines_buffer), GFP_KERNEL);
+ if (!savedcmd)
+ goto out;
+
+ ret = allocate_cmdlines_buffer(SAVED_CMDLINES_DEFAULT, savedcmd);
+ if (ret < 0)
+ goto out_free;
+
+ return 0;
+
+out_free:
+ kfree(savedcmd);
+out:
+ return -ENOMEM;
+}
+
+static void trace_init_savedcmd(void)
+{
+ trace_init_cmdlines_buffer(SAVED_CMDLINES_DEFAULT, savedcmd);
+}
+
+static int trace_create_and_init_savedcmd(void)
+{
+ int ret;
+
+ ret = trace_create_savedcmd();
+ if (ret < 0)
+ return ret;
+
+ trace_init_savedcmd();
+
+ return 0;
}
int is_tracing_stopped(void)
@@ -1424,9 +1498,9 @@ static void trace_save_cmdline(struct task_struct *tsk)
if (!arch_spin_trylock(_cmdline_lock))
return;
- idx = map_pid_to_cmdline[tsk->pid];
+ idx = savedcmd->map_pid_to_cmdline[tsk->pid];
if (idx == NO_CMDLINE_MAP) {
- idx = (cmdline_idx + 1) % SAVED_CMDLINES;
+ idx = (savedcmd->cmdline_idx + 1) % savedcmd->cmdline_num;
/*
* Check whether the cmdline buffer at idx has a pid
@@ -1434,17 +1508,17 @@ static void trace_save_cmdline(struct task_struct *tsk)
* need to clear the map_pid_to_cmdline. Otherwise we
* would read the new comm for the old pid.
*/
- pid =
[PATCH 2/2] perf record: mmap output file - v4
When recording raw_syscalls for the entire system, e.g.,
perf record -e raw_syscalls:*,sched:sched_switch -a -- sleep 1
you end up with a negative feedback loop as perf itself calls write() fairly
often. This patch handles the problem by mmap'ing the file in chunks of 64M at
a time and copies events from the event buffers to the file avoiding write
system calls.
Before (with write syscall):
perf record -o /tmp/perf.data -e raw_syscalls:*,sched:sched_switch -a --
sleep 1
[ perf record: Woken up 0 times to write data ]
[ perf record: Captured and wrote 81.843 MB /tmp/perf.data (~3575786
samples) ]
After (using mmap):
perf record -o /tmp/perf.data -e raw_syscalls:*,sched:sched_switch -a --
sleep 1
[ perf record: Woken up 31 times to write data ]
[ perf record: Captured and wrote 8.203 MB /tmp/perf.data (~358388 samples)
]
In addition to perf-trace benefits using mmap lowers the overhead of
perf-record. For example,
perf stat -i -- perf record -g -o /tmp/perf.data openssl speed aes
shows a drop in time, CPU cycles, and instructions all drop by more than a
factor of 3. Jiri also ran a test that showed a big improvement.
v4: Refactoring per Ingo's comments
v3: Removed use of bytes_at_mmap_start at the stat() that set it
Added user option to control the size of the mmap for writing file.
v2: Removed msync call before munmap per Jiri's suggestion
Signed-off-by: David Ahern
Cc: Ingo Molnar
Cc: Frederic Weisbecker
Cc: Peter Zijlstra
Cc: Jiri Olsa
Cc: Namhyung Kim
Cc: Mike Galbraith
Cc: Stephane Eranian
---
tools/perf/Documentation/perf-record.txt | 5 +
tools/perf/builtin-record.c | 155 +++
2 files changed, 160 insertions(+)
diff --git a/tools/perf/Documentation/perf-record.txt
b/tools/perf/Documentation/perf-record.txt
index 052f7c4dc00c..af11c2dd2360 100644
--- a/tools/perf/Documentation/perf-record.txt
+++ b/tools/perf/Documentation/perf-record.txt
@@ -201,6 +201,11 @@ abort events and some memory events in precise mode on
modern Intel CPUs.
--transaction::
Record transaction flags for transaction related events.
+--out-pages=::
+Number of pages to mmap for writing data to file or size specification
+with appended unit character - B/K/M/G. The size is rounded up to have nearest
+pages power of two value. Default size is 64M.
+
SEE ALSO
linkperf:perf-stat[1], linkperf:perf-list[1]
diff --git a/tools/perf/builtin-record.c b/tools/perf/builtin-record.c
index 6e6a41856c41..72dd983832f5 100644
--- a/tools/perf/builtin-record.c
+++ b/tools/perf/builtin-record.c
@@ -30,6 +30,9 @@
#include
#include
+/* output file mmap'ed N chunks at a time */
+#define MMAP_OUTPUT_SIZE (64*1024*1024)
+
#ifndef HAVE_ON_EXIT_SUPPORT
#ifndef ATEXIT_MAX
#define ATEXIT_MAX 32
@@ -65,6 +68,16 @@ static void __handle_on_exit_funcs(void)
struct perf_record {
struct perf_tooltool;
struct perf_record_opts opts;
+
+ /* for MMAP based file writes */
+ struct {
+ void*addr;
+ u64 offset; /* current location within mmap */
+ unsigned intout_pages; /* user configurable option */
+ size_t out_size; /* size of mmap segments */
+ booluse;
+ } mmap;
+
u64 bytes_written;
struct perf_data_file file;
struct perf_evlist *evlist;
@@ -76,6 +89,95 @@ struct perf_record {
longsamples;
};
+static int mmap_next_segment(struct perf_record *rec, off_t offset)
+{
+ struct perf_data_file *file = >file;
+
+ /* extend file to include a new mmap segment */
+ if (ftruncate(file->fd, offset + rec->mmap.out_size) != 0) {
+ pr_err("ftruncate failed\n");
+ return -1;
+ }
+
+ rec->mmap.addr = mmap(NULL, rec->mmap.out_size,
+ PROT_WRITE | PROT_READ, MAP_SHARED,
+ file->fd, offset);
+
+ if (rec->mmap.addr == MAP_FAILED) {
+ pr_err("mmap failed: %d: %s\n", errno, strerror(errno));
+
+ /* reset file size */
+ if (ftruncate(file->fd, offset) != 0)
+ pr_err("ftruncate failed too. Is it Halloween?\n");
+
+ return -1;
+ }
+
+ return 0;
+}
+
+static off_t next_mmap_offset(struct perf_record *rec)
+{
+ off_t offset;
+
+ /*
+* for first segment, mmap offset is current amount of data
+* already written to file. For follow on segments the output
+* starts at 0.
+*/
+ offset = rec->session->header.data_offset + rec->bytes_written;
+ if (offset < (ssize_t) rec->mmap.out_size) {
+ rec->mmap.offset = offset;
+ offset = 0;
+ } else {
+ rec->mmap.offset = 0;
+ }
+
+ /* returning offset within file -
[PATCH -tip 1/2] ftrace: Make saved_cmdlines use seq_read
Current tracing_saved_cmdlines_read() implementation is naive;
simply allocate a big buffer, construct output data on the
buffer for each read operation, and then copy a portion of
the buffer to the user space buffer. This can cause a couple of
issues such as a slow memory allocation, high cpu usage, and a
corruption of the output data.
To address these issues, make saved_cmdlines use seq_read.
Signed-off-by: Hidehiro Kawai
Signed-off-by: Yoshihiro YUNOMAE
Cc: Steven Rostedt
Cc: Frederic Weisbecker
Cc: Ingo Molnar
Cc: linux-kernel@vger.kernel.org
---
kernel/trace/trace.c | 89 ++
1 file changed, 54 insertions(+), 35 deletions(-)
diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
index 7974ba2..90cf668 100644
--- a/kernel/trace/trace.c
+++ b/kernel/trace/trace.c
@@ -3544,55 +3544,74 @@ static const struct file_operations tracing_readme_fops
= {
.llseek = generic_file_llseek,
};
-static ssize_t
-tracing_saved_cmdlines_read(struct file *file, char __user *ubuf,
- size_t cnt, loff_t *ppos)
+static void *saved_cmdlines_next(struct seq_file *m, void *v, loff_t *pos)
{
- char *buf_comm;
- char *file_buf;
- char *buf;
- int len = 0;
- int pid;
- int i;
+ unsigned int *ptr = v;
- file_buf = kmalloc(SAVED_CMDLINES*(16+TASK_COMM_LEN), GFP_KERNEL);
- if (!file_buf)
- return -ENOMEM;
+ if (*pos || m->count)
+ ptr++;
- buf_comm = kmalloc(TASK_COMM_LEN, GFP_KERNEL);
- if (!buf_comm) {
- kfree(file_buf);
- return -ENOMEM;
- }
+ (*pos)++;
+
+ for (; ptr < _cmdline_to_pid[SAVED_CMDLINES]; ptr++) {
+ if (*ptr == -1 || *ptr == NO_CMDLINE_MAP)
+ continue;
- buf = file_buf;
+ return ptr;
+ }
- for (i = 0; i < SAVED_CMDLINES; i++) {
- int r;
+ return NULL;
+}
- pid = map_cmdline_to_pid[i];
- if (pid == -1 || pid == NO_CMDLINE_MAP)
- continue;
+static void *saved_cmdlines_start(struct seq_file *m, loff_t *pos)
+{
+ void *v;
+ loff_t l = 0;
- trace_find_cmdline(pid, buf_comm);
- r = sprintf(buf, "%d %s\n", pid, buf_comm);
- buf += r;
- len += r;
+ v = _cmdline_to_pid[0];
+ while (l <= *pos) {
+ v = saved_cmdlines_next(m, v, );
+ if (!v)
+ return NULL;
}
- len = simple_read_from_buffer(ubuf, cnt, ppos,
- file_buf, len);
+ return v;
+}
- kfree(file_buf);
- kfree(buf_comm);
+static void saved_cmdlines_stop(struct seq_file *m, void *v)
+{
+}
- return len;
+static int saved_cmdlines_show(struct seq_file *m, void *v)
+{
+ char buf[TASK_COMM_LEN];
+ unsigned int *pid = v;
+
+ trace_find_cmdline(*pid, buf);
+ seq_printf(m, "%d %s\n", *pid, buf);
+ return 0;
+}
+
+static const struct seq_operations tracing_saved_cmdlines_seq_ops = {
+ .start = saved_cmdlines_start,
+ .next = saved_cmdlines_next,
+ .stop = saved_cmdlines_stop,
+ .show = saved_cmdlines_show,
+};
+
+static int tracing_saved_cmdlines_open(struct inode *inode, struct file *filp)
+{
+ if (tracing_disabled)
+ return -ENODEV;
+
+ return seq_open(filp, _saved_cmdlines_seq_ops);
}
static const struct file_operations tracing_saved_cmdlines_fops = {
-.open = tracing_open_generic,
-.read = tracing_saved_cmdlines_read,
-.llseek= generic_file_llseek,
+ .open = tracing_saved_cmdlines_open,
+ .read = seq_read,
+ .llseek = seq_lseek,
+ .release= seq_release,
};
static ssize_t
--
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/
[PATCH -tip 0/2] ftrace: Introduce the new I/F "nr_saved_cmdlines"
Hi, This patch set introduces the new I/F "nr_saved_cmdlines" for increasing the number of saved cmdlines. Current saved_cmdlines can store just 128 command names and PIDs, but process names are often lost like <...> when we read trace data. If the process exists, we can get the name by using ps command. However, if the process already has not existed, we cannot get the name. To solve this issue, we introduce the new I/F "nr_saved_cmdlines" to expand the max number of saved command line names. This I/F is very simple. If we write a number to nr_saved_cmdlines, the number of command name will be stored. And, if we read the I/F, we can get current maximum number of command name. The default number is 128 which is current default number, so this patch does not change the usage of memory for saved_cmdlines when we boot kernel. Thanks! --- Yoshihiro YUNOMAE (2): ftrace: Make saved_cmdlines use seq_read ftrace: Introduce nr_saved_cmdlines I/F kernel/trace/trace.c | 296 +- 1 file changed, 241 insertions(+), 55 deletions(-) -- Yoshihiro YUNOMAE Software Platform Research Dept. Linux Technology Center Hitachi, Ltd., Yokohama Research Laboratory E-mail: yoshihiro.yunomae...@hitachi.com -- 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/
Re: kernel BUG at kernel/kallsyms.c:222!
>>> Hi Ming, >>> >>> I found in arch/arm/include/asm/memory.h: >>> CONFIG_PAGE_OFFSET is not used if !CONFIG_MMU. >>> So looks like setting CONFIG_PAGE_OFFSET to other value still won't work. >> >> This seems like the simplest solution, but it may mean you still have >> crap in /proc/kallsyms. >> >> Does it work for you? > > Yes, it should work, but I am wondering if perf can work on uClinux. > > Axel, could you post your .config? Hi Ming, I have patches on top of 3.12 to support gpl32700 SoC. So you cannot find this platform on mainline kernel. I havn't tried perf, below is my config for your reference: (to make the config smaller, I grep out disabled config entries.) # # Automatically generated file; DO NOT EDIT. # Linux/arm 3.12.0 Kernel Configuration # CONFIG_ARM=y CONFIG_SYS_SUPPORTS_APM_EMULATION=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_HAVE_LATENCYTOP_SUPPORT=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_TRACE_IRQFLAGS_SUPPORT=y CONFIG_RWSEM_GENERIC_SPINLOCK=y CONFIG_GENERIC_HWEIGHT=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_NEED_DMA_MAP_STATE=y CONFIG_VECTORS_BASE=0x CONFIG_PHYS_OFFSET=0x CONFIG_GENERIC_BUG=y CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" CONFIG_IRQ_WORK=y # # General setup # CONFIG_BROKEN_ON_SMP=y CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_CROSS_COMPILE="" CONFIG_LOCALVERSION="" CONFIG_LOCALVERSION_AUTO=y CONFIG_HAVE_KERNEL_GZIP=y CONFIG_HAVE_KERNEL_LZMA=y CONFIG_HAVE_KERNEL_XZ=y CONFIG_HAVE_KERNEL_LZO=y CONFIG_HAVE_KERNEL_LZ4=y CONFIG_KERNEL_GZIP=y CONFIG_DEFAULT_HOSTNAME="(none)" # # IRQ subsystem # CONFIG_GENERIC_IRQ_PROBE=y CONFIG_GENERIC_IRQ_SHOW=y CONFIG_HARDIRQS_SW_RESEND=y CONFIG_GENERIC_IRQ_CHIP=y CONFIG_IRQ_DOMAIN=y CONFIG_IRQ_FORCED_THREADING=y CONFIG_KTIME_SCALAR=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_GENERIC_CLOCKEVENTS_BUILD=y # # Timers subsystem # CONFIG_HZ_PERIODIC=y # # CPU/Task time and stats accounting # CONFIG_TICK_CPU_ACCOUNTING=y # # RCU Subsystem # CONFIG_TINY_RCU=y CONFIG_LOG_BUF_SHIFT=14 CONFIG_GENERIC_SCHED_CLOCK=y CONFIG_BLK_DEV_INITRD=y CONFIG_INITRAMFS_SOURCE="" CONFIG_RD_GZIP=y CONFIG_SYSCTL=y CONFIG_ANON_INODES=y CONFIG_HAVE_UID16=y CONFIG_EXPERT=y CONFIG_UID16=y CONFIG_KALLSYMS=y CONFIG_KALLSYMS_ALL=y CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_BASE_FULL=y CONFIG_EPOLL=y CONFIG_SIGNALFD=y CONFIG_EVENTFD=y CONFIG_AIO=y CONFIG_EMBEDDED=y CONFIG_HAVE_PERF_EVENTS=y CONFIG_PERF_USE_VMALLOC=y # # Kernel Performance Events And Counters # CONFIG_COMPAT_BRK=y CONFIG_SLAB=y CONFIG_HAVE_OPROFILE=y CONFIG_HAVE_KPROBES=y CONFIG_HAVE_KRETPROBES=y CONFIG_HAVE_ARCH_TRACEHOOK=y CONFIG_HAVE_DMA_ATTRS=y CONFIG_GENERIC_SMP_IDLE_THREAD=y CONFIG_GENERIC_IDLE_POLL_SETUP=y CONFIG_HAVE_REGS_AND_STACK_ACCESS_API=y CONFIG_HAVE_CLK=y CONFIG_HAVE_DMA_API_DEBUG=y CONFIG_HAVE_ARCH_JUMP_LABEL=y CONFIG_ARCH_WANT_IPC_PARSE_VERSION=y CONFIG_HAVE_ARCH_SECCOMP_FILTER=y CONFIG_HAVE_CONTEXT_TRACKING=y CONFIG_HAVE_IRQ_TIME_ACCOUNTING=y CONFIG_HAVE_MOD_ARCH_SPECIFIC=y CONFIG_MODULES_USE_ELF_REL=y CONFIG_CLONE_BACKWARDS=y CONFIG_OLD_SIGSUSPEND3=y CONFIG_OLD_SIGACTION=y # # GCOV-based kernel profiling # CONFIG_HAVE_GENERIC_DMA_COHERENT=y CONFIG_SLABINFO=y CONFIG_BASE_SMALL=0 CONFIG_BLOCK=y # # Partition Types # CONFIG_MSDOS_PARTITION=y CONFIG_EFI_PARTITION=y # # IO Schedulers # CONFIG_IOSCHED_NOOP=y CONFIG_DEFAULT_NOOP=y CONFIG_DEFAULT_IOSCHED="noop" CONFIG_INLINE_SPIN_UNLOCK_IRQ=y CONFIG_INLINE_READ_UNLOCK=y CONFIG_INLINE_READ_UNLOCK_IRQ=y CONFIG_INLINE_WRITE_UNLOCK=y CONFIG_INLINE_WRITE_UNLOCK_IRQ=y # # System Type # CONFIG_ARCH_GPL327XX=y # # GPL327XX Implementations # CONFIG_ARCH_GPL32700=y # # Processor Type # CONFIG_CPU_ARM7TDMI=y CONFIG_CPU_32v4T=y CONFIG_CPU_ABRT_LV4T=y CONFIG_CPU_PABRT_LEGACY=y CONFIG_CPU_CACHE_V4=y # # Processor Features # CONFIG_TLS_REG_EMUL=y CONFIG_NEED_KUSER_HELPERS=y CONFIG_KUSER_HELPERS=y CONFIG_ARM_L1_CACHE_SHIFT=5 CONFIG_ARM_NR_BANKS=8 CONFIG_MULTI_IRQ_HANDLER=y CONFIG_SET_MEM_PARAM=y CONFIG_DRAM_BASE=0x CONFIG_DRAM_SIZE=0x0200 CONFIG_FLASH_MEM_BASE=0x2000 CONFIG_FLASH_SIZE=0x0040 CONFIG_PROCESSOR_ID=0x41807700 # # Bus support # # # Kernel Features # CONFIG_VMSPLIT_3G=y CONFIG_PAGE_OFFSET=0xC000 CONFIG_ARCH_NR_GPIO=0 CONFIG_PREEMPT_NONE=y CONFIG_HZ_FIXED=0 CONFIG_HZ_100=y CONFIG_HZ=100 CONFIG_AEABI=y CONFIG_HAVE_ARCH_PFN_VALID=y CONFIG_ARCH_WANT_GENERAL_HUGETLB=y CONFIG_FLATMEM=y CONFIG_FLAT_NODE_MEM_MAP=y CONFIG_HAVE_MEMBLOCK=y CONFIG_PAGEFLAGS_EXTENDED=y CONFIG_SPLIT_PTLOCK_CPUS=99 CONFIG_ZONE_DMA_FLAG=0 CONFIG_NOMMU_INITIAL_TRIM_EXCESS=1 CONFIG_NEED_PER_CPU_KM=y CONFIG_FORCE_MAX_ZONEORDER=11 # # Boot options # CONFIG_USE_OF=y CONFIG_ZBOOT_ROM_TEXT=0x0 CONFIG_ZBOOT_ROM_BSS=0x0 CONFIG_CMDLINE="" CONFIG_AUTO_ZRELADDR=y # # CPU Power Management # # # CPU Idle # # # Floating point emulation # # # At least one emulation must be selected # # # Userspace binary formats # CONFIG_ARCH_BINFMT_ELF_RANDOMIZE_PIE=y CONFIG_BINFMT_SCRIPT=y CONFIG_BINFMT_FLAT=y CONFIG_COREDUMP=y # # Power management options #
Re: [PATCH v4 0/3] x86, apic, kexec: Add disable_cpu_apic kernel parameter
(2013/11/08 12:30), Baoquan He wrote: Hi, Reccently people reported kexec didn't work correctly. After check, it's a regression. Since a code block which migrate current thread to cpu0 when executing "kexec -e", this can be reproduced by setting affinity to CPUn(n!=0). You can find this patch in this link: https://lkml.org/lkml/2013/11/5/88 Then I thought why we don't do this in kdump. I tried migrating current thread to cpu0 when crash happened, it works very well. Set affinity to make crash happened on CPUn(n!=0), then all cpus can be brought up and dump is successful. I pasted the patch as below. Only one thing worried me, whether the context related to crash cpu will be different, and do we care which cpu crashed. If it need be cared, or it doesn't involve difference, That will be great. Multiple CPUs can be supported easily in this simpler way. Meanwhile, this patch just try to migrate, if it's failed, we can avoid to bring up bsp. Watch do you think about it? We have already discussed this idea. It's the idea of my first patch and it was nacked. See the following url. (Sorry, I removed explanation of development history from patch description at v4 patch, but I've planned to write what ideas doesn't work well in documentation of this work.) https://lkml.org/lkml/2012/4/15/181 The key reason why we cannot do that is the environment we are running must be considered broken. Either interrupts or scheduler could no longer work. Tables for interrupts can be broken. The other cpus except for the crashing cpu are no longer guaranteed to be running sanely. Migrating cpu from the crashing cpu to cpu0 reduces reliability of kdump. -- Thanks. HATAYAMA, Daisuke -- 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/
[PATCH RESEND] irqchip: sun4i: Don't write to read-only registers
According to the datasheet[1], the Interrupt IRQ Pending Registers are
read-only. The implementation of sun4i_irq_ack() is wrong because it writes
to these read-only registers.
This patch removes the wrong irq_ack callback implementation and all the code
writing to these read-only registers in sun4i_of_init().
[1]
http://dl.linux-sunxi.org/A10/A10%20User%20Manual%20-%20v1.20%20%282012-04-09%2c%20DECRYPTED%29.pdf
Signed-off-by: Axel Lin
Acked-by: Maxime Ripard
---
Hi Thomas,
This patch was sent on https://lkml.org/lkml/2013/7/6/59 with Maxime's Ack.
And re-sent on https://lkml.org/lkml/2013/7/19/229
I change the subject line as the patch does is to avoid writing to read-only
registers.
Axel
drivers/irqchip/irq-sun4i.c | 18 --
1 file changed, 18 deletions(-)
diff --git a/drivers/irqchip/irq-sun4i.c b/drivers/irqchip/irq-sun4i.c
index a5438d8..29b75c0a 100644
--- a/drivers/irqchip/irq-sun4i.c
+++ b/drivers/irqchip/irq-sun4i.c
@@ -38,18 +38,6 @@ static struct irq_domain *sun4i_irq_domain;
static asmlinkage void __exception_irq_entry sun4i_handle_irq(struct pt_regs
*regs);
-static void sun4i_irq_ack(struct irq_data *irqd)
-{
- unsigned int irq = irqd_to_hwirq(irqd);
- unsigned int irq_off = irq % 32;
- int reg = irq / 32;
- u32 val;
-
- val = readl(sun4i_irq_base + SUN4I_IRQ_PENDING_REG(reg));
- writel(val | (1 << irq_off),
- sun4i_irq_base + SUN4I_IRQ_PENDING_REG(reg));
-}
-
static void sun4i_irq_mask(struct irq_data *irqd)
{
unsigned int irq = irqd_to_hwirq(irqd);
@@ -76,7 +64,6 @@ static void sun4i_irq_unmask(struct irq_data *irqd)
static struct irq_chip sun4i_irq_chip = {
.name = "sun4i_irq",
- .irq_ack= sun4i_irq_ack,
.irq_mask = sun4i_irq_mask,
.irq_unmask = sun4i_irq_unmask,
};
@@ -114,11 +101,6 @@ static int __init sun4i_of_init(struct device_node *node,
writel(0, sun4i_irq_base + SUN4I_IRQ_MASK_REG(1));
writel(0, sun4i_irq_base + SUN4I_IRQ_MASK_REG(2));
- /* Clear all the pending interrupts */
- writel(0x, sun4i_irq_base + SUN4I_IRQ_PENDING_REG(0));
- writel(0x, sun4i_irq_base + SUN4I_IRQ_PENDING_REG(1));
- writel(0x, sun4i_irq_base + SUN4I_IRQ_PENDING_REG(2));
-
/* Enable protection mode */
writel(0x01, sun4i_irq_base + SUN4I_IRQ_PROTECTION_REG);
--
1.8.1.2
--
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/
Re: [RFC] arch: Introduce new TSO memory barrier smp_tmb()
* Peter Zijlstra (pet...@infradead.org) wrote:
[...]
Hi Peter,
Looking at this simplified version of perf's ring buffer
synchronization, I get concerned about the following issue:
> /*
> * One important detail is that the kbuf part and the kbuf_writer() are
> * strictly per cpu and we can thus rely on program order for those.
> *
> * Only the userspace consumer can possibly run on another cpu, and thus we
> * need to ensure data consistency for those.
> */
>
> struct buffer {
> u64 size;
> u64 tail;
> u64 head;
> void *data;
> };
>
> struct buffer *kbuf, *ubuf;
>
> /*
> * If there's space in the buffer; store the data @buf; otherwise
> * discard it.
> */
> void kbuf_write(int sz, void *buf)
> {
> u64 tail, head, offset;
>
> do {
> tail = ACCESS_ONCE(ubuf->tail);
> offset = head = kbuf->head;
> if (CIRC_SPACE(head, tail, kbuf->size) < sz) {
> /* discard @buf */
> return;
> }
> head += sz;
> } while (local_cmpxchg(>head, offset, head) != offset)
>
Let's suppose we have a thread executing kbuf_write(), interrupted by an
IRQ or NMI right after a successful local_cmpxchg() (space reservation
in the buffer). If the nested execution context also calls kbuf_write(),
it will therefore update ubuf->head (below) with the second reserved
space, and only after that will it return to the original thread context
and continue executing kbuf_write(), thus overwriting ubuf->head with
the prior-to-last reserved offset.
All this probably works OK most of the times, when we have an event flow
guaranteeing that a following event will fix things up, but there
appears to be a risk of losing events near the end of the trace when
those are in nested execution contexts.
Thoughts ?
Thanks,
Mathieu
> /*
> * Ensure that if we see the userspace tail (ubuf->tail) such
> * that there is space to write @buf without overwriting data
> * userspace hasn't seen yet, we won't in fact store data before
> * that read completes.
> */
>
> smp_mb(); /* A, matches with D */
>
> memcpy(kbuf->data + offset, buf, sz);
>
> /*
> * Ensure that we write all the @buf data before we update the
> * userspace visible ubuf->head pointer.
> */
> smp_wmb(); /* B, matches with C */
>
> ubuf->head = kbuf->head;
> }
>
> /*
> * Consume the buffer data and update the tail pointer to indicate to
> * kernel space there's 'free' space.
> */
> void ubuf_read(void)
> {
> u64 head, tail;
>
> tail = ACCESS_ONCE(ubuf->tail);
> head = ACCESS_ONCE(ubuf->head);
>
> /*
> * Ensure we read the buffer boundaries before the actual buffer
> * data...
> */
> smp_rmb(); /* C, matches with B */
>
> while (tail != head) {
> obj = ubuf->data + tail;
> /* process obj */
> tail += obj->size;
> tail %= ubuf->size;
> }
>
> /*
> * Ensure all data reads are complete before we issue the
> * ubuf->tail update; once that update hits, kbuf_write() can
> * observe and overwrite data.
> */
> smp_mb(); /* D, matches with A */
>
> ubuf->tail = tail;
> }
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
--
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/
Re: kernel BUG at kernel/kallsyms.c:222!
2013/11/8 Rusty Russell : > Axel Lin writes: >> 2013/11/7 Ming Lei : >>> Hi, >>> >>> On Thu, Nov 7, 2013 at 10:47 AM, Axel Lin wrote: hi Ming, Seems CONFIG_PAGE_OFFSET is not configurabe in "make menuconfig". And I found CONFIG_PAGE_OFFSET=0xC000 for all below configs... $ make at91_dt_defconfig; grep CONFIG_PAGE_OFFSET .config $ make ep93xx_defconfig; grep CONFIG_PAGE_OFFSET .config $ make imx_v4_v5_defconfig; grep CONFIG_PAGE_OFFSET .config $ make mxs_defconfig; grep CONFIG_PAGE_OFFSET .config $ make omap2plus_defconfig; grep CONFIG_PAGE_OFFSET .config $ make s3c6400_defconfig; grep CONFIG_PAGE_OFFSET .config $ make at91x40_defconfig; grep CONFIG_PAGE_OFFSET .config ( at91x40_defconfig is also arm7tdmi ) >>> >>> Firstly it can be configured via VMSPLIT_3GVMSPLIT_2G/VMSPLIT_1G. >>> >>> Secondly, configurable or not isn't the point, and maybe some uclinux >>> platforms do not use CONFIG_PAGE_OFFSET at all, but they should >>> set it as a reasonable value or at least be below than the start link >>> address of vmlinux. >> >> Hi Ming, >> >> I found in arch/arm/include/asm/memory.h: >> CONFIG_PAGE_OFFSET is not used if !CONFIG_MMU. >> So looks like setting CONFIG_PAGE_OFFSET to other value still won't work. > > This seems like the simplest solution, but it may mean you still have > crap in /proc/kallsyms. > > Does it work for you? Yes, it works. Thanks, Axel -- 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/
[PATCH] arch: arm: uapi: be sure of "_UAPI" prefix for all guard macros
For all uapi headers, need use "_UAPI" prefix for its guard macro
(which will be stripped by "scripts/headers_installer.sh").
Additional completions:
- be sure that all "endif" need be appended related comment, also it
has and only has one empty line above and no any lines below either.
- be sure that all normal uapi header files need content guard macro.
- remove the default "kvm_para.h" which was added in Kbuild.
- remove the detail address of Free Software Foundation (or can not
pass "scripts/checkpatch.pl").
Cc: David Howells
Signed-off-by: Chen Gang
---
arch/arm/include/uapi/asm/byteorder.h |7 +++
arch/arm/include/uapi/asm/fcntl.h |6 +++---
arch/arm/include/uapi/asm/ioctls.h |6 +++---
arch/arm/include/uapi/asm/kvm.h |8
arch/arm/include/uapi/asm/kvm_para.h|1 -
arch/arm/include/uapi/asm/mman.h|5 +
arch/arm/include/uapi/asm/perf_regs.h |7 ---
arch/arm/include/uapi/asm/posix_types.h |6 +++---
arch/arm/include/uapi/asm/ptrace.h |1 -
arch/arm/include/uapi/asm/setup.h |1 -
arch/arm/include/uapi/asm/sigcontext.h |7 +++
arch/arm/include/uapi/asm/signal.h |1 -
arch/arm/include/uapi/asm/stat.h|6 +++---
arch/arm/include/uapi/asm/statfs.h |7 ---
14 files changed, 35 insertions(+), 34 deletions(-)
delete mode 100644 arch/arm/include/uapi/asm/kvm_para.h
diff --git a/arch/arm/include/uapi/asm/byteorder.h
b/arch/arm/include/uapi/asm/byteorder.h
index 7737974..ffd1e93 100644
--- a/arch/arm/include/uapi/asm/byteorder.h
+++ b/arch/arm/include/uapi/asm/byteorder.h
@@ -12,8 +12,8 @@
* and word accesses (data or instruction) appear as:
* d0...d31
*/
-#ifndef __ASM_ARM_BYTEORDER_H
-#define __ASM_ARM_BYTEORDER_H
+#ifndef _UAPI__ASM_ARM_BYTEORDER_H
+#define _UAPI__ASM_ARM_BYTEORDER_H
#ifdef __ARMEB__
#include
@@ -21,5 +21,4 @@
#include
#endif
-#endif
-
+#endif /* _UAPI__ASM_ARM_BYTEORDER_H */
diff --git a/arch/arm/include/uapi/asm/fcntl.h
b/arch/arm/include/uapi/asm/fcntl.h
index a80b660..4cde9c4 100644
--- a/arch/arm/include/uapi/asm/fcntl.h
+++ b/arch/arm/include/uapi/asm/fcntl.h
@@ -1,5 +1,5 @@
-#ifndef _ARM_FCNTL_H
-#define _ARM_FCNTL_H
+#ifndef _UAPI_ARM_FCNTL_H
+#define _UAPI_ARM_FCNTL_H
#define O_DIRECTORY 04 /* must be a directory */
#define O_NOFOLLOW 010 /* don't follow links */
@@ -8,4 +8,4 @@
#include
-#endif
+#endif /* _UAPI_ARM_FCNTL_H */
diff --git a/arch/arm/include/uapi/asm/ioctls.h
b/arch/arm/include/uapi/asm/ioctls.h
index 9c96298..a9d8008 100644
--- a/arch/arm/include/uapi/asm/ioctls.h
+++ b/arch/arm/include/uapi/asm/ioctls.h
@@ -1,8 +1,8 @@
-#ifndef __ASM_ARM_IOCTLS_H
-#define __ASM_ARM_IOCTLS_H
+#ifndef _UAPI__ASM_ARM_IOCTLS_H
+#define _UAPI__ASM_ARM_IOCTLS_H
#define FIOQSIZE 0x545E
#include
-#endif
+#endif /* _UAPI__ASM_ARM_IOCTLS_H */
diff --git a/arch/arm/include/uapi/asm/kvm.h b/arch/arm/include/uapi/asm/kvm.h
index c498b60..f44fad1 100644
--- a/arch/arm/include/uapi/asm/kvm.h
+++ b/arch/arm/include/uapi/asm/kvm.h
@@ -13,11 +13,11 @@
*
* You should have received a copy of the GNU General Public License
* along with this program; if not, write to the Free Software
- * Foundation, 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
+ * Foundation (the address is in a copy of the GPL).
*/
-#ifndef __ARM_KVM_H__
-#define __ARM_KVM_H__
+#ifndef _UAPI__ARM_KVM_H__
+#define _UAPI__ARM_KVM_H__
#include
#include
@@ -178,4 +178,4 @@ struct kvm_arch_memory_slot {
#define KVM_PSCI_RET_INVAL ((unsigned long)-2)
#define KVM_PSCI_RET_DENIED((unsigned long)-3)
-#endif /* __ARM_KVM_H__ */
+#endif /* _UAPI__ARM_KVM_H__ */
diff --git a/arch/arm/include/uapi/asm/kvm_para.h
b/arch/arm/include/uapi/asm/kvm_para.h
deleted file mode 100644
index 14fab8f..000
--- a/arch/arm/include/uapi/asm/kvm_para.h
+++ /dev/null
@@ -1 +0,0 @@
-#include
diff --git a/arch/arm/include/uapi/asm/mman.h b/arch/arm/include/uapi/asm/mman.h
index 41f99c5..bf6ac7c 100644
--- a/arch/arm/include/uapi/asm/mman.h
+++ b/arch/arm/include/uapi/asm/mman.h
@@ -1,4 +1,9 @@
+#ifndef _UAPI_ARM_MMAN_H
+#define _UAPI_ARM_MMAN_H
+
#include
#define arch_mmap_check(addr, len, flags) \
(((flags) & MAP_FIXED && (addr) < FIRST_USER_ADDRESS) ? -EINVAL : 0)
+
+#endif /* _UAPI_ARM_MMAN_H */
diff --git a/arch/arm/include/uapi/asm/perf_regs.h
b/arch/arm/include/uapi/asm/perf_regs.h
index ce59448..61e86fb 100644
--- a/arch/arm/include/uapi/asm/perf_regs.h
+++ b/arch/arm/include/uapi/asm/perf_regs.h
@@ -1,5 +1,5 @@
-#ifndef _ASM_ARM_PERF_REGS_H
-#define _ASM_ARM_PERF_REGS_H
+#ifndef _UAPI_ASM_ARM_PERF_REGS_H
+#define _UAPI_ASM_ARM_PERF_REGS_H
enum perf_event_arm_regs {
PERF_REG_ARM_R0,
@@ -20,4 +20,5 @@ enum perf_event_arm_regs {
PERF_REG_ARM_PC,
PERF_REG_ARM_MAX,
};
-#endif /* _ASM_ARM_PERF_REGS_H */
+
+#endif /*
Re: [PATCH 1/1] IOMMU: Save pci device id instead of pci_dev* pointer for DMAR devices
HI Bjorn,
Thanks for your review and comments very much!
>> +list_for_each_entry(dmar_dev, head, list)
>> +if (dmar_dev->segment == pci_domain_nr(dev->bus)
>> +&& dmar_dev->bus == dev->bus->number
>> +&& dmar_dev->devfn == dev->devfn)
>> +return 1;
>> +
>> /* Check our parent */
>> dev = dev->bus->self;
>
> You didn't change this, but it looks like this may have the same problem
> we've been talking about here:
>
> http://lkml.kernel.org/r/20131105232903.3790.8738.st...@bhelgaas-glaptop.roam.corp.google.com
>
> Namely, if "dev" is a VF on a virtual bus, "dev->bus->self == NULL", so
> we won't search for any of the bridges leading to the VF. I proposed a
> pci_upstream_bridge() interface that could be used like this:
>
> /* Check our parent */
> dev = pci_upstream_bridge(dev);
>
It looks good to me, because pci_upstream_bridge() is still in your next
branch, I think maybe
I can split this changes in a separate patch after 3.13-rc1.
>> static struct intel_iommu *device_to_iommu(int segment, u8 bus, u8 devfn)
>> {
>> struct dmar_drhd_unit *drhd = NULL;
>> -int i;
>> +struct dmar_device *dmar_dev;
>> +struct pci_dev *pdev;
>>
>> for_each_drhd_unit(drhd) {
>> if (drhd->ignored)
>> @@ -658,16 +659,22 @@ static struct intel_iommu *device_to_iommu(int
>> segment, u8 bus, u8 devfn)
>> if (segment != drhd->segment)
>> continue;
>>
>> -for (i = 0; i < drhd->devices_cnt; i++) {
>> -if (drhd->devices[i] &&
>> -drhd->devices[i]->bus->number == bus &&
>> -drhd->devices[i]->devfn == devfn)
>> -return drhd->iommu;
>> -if (drhd->devices[i] &&
>> -drhd->devices[i]->subordinate &&
>> -drhd->devices[i]->subordinate->number <= bus &&
>> -drhd->devices[i]->subordinate->busn_res.end >= bus)
>> -return drhd->iommu;
>> +list_for_each_entry(dmar_dev, >head, list) {
>> +if (dmar_dev->bus == bus &&
>> +dmar_dev->devfn == devfn)
>> +return drhd->iommu;
>> +
>> +pdev = pci_get_domain_bus_and_slot(dmar_dev->segment,
>> +dmar_dev->bus, dmar_dev->devfn);
>> +if (pdev->subordinate &&
>> +pdev->subordinate->number <= bus &&
>> +pdev->subordinate->busn_res.end >= bus) {
>> +pci_dev_put(pdev);
>> +return drhd->iommu;
>
> I don't know the details of how device_to_iommu() is used, but this
> style (acquire ref to pci_dev, match it to some other object, drop
> pci_dev ref, return object) makes me nervous. How do we know the
> caller isn't depending on pci_dev to remain attached to the object?
> What happens if the pci_dev disappears when we do the pci_dev_put()
> here?
Hmmm, this is the thing I am most worried about. If we just only use
(pci_dev *) poninter in drhd->devices array as a identification. Change
(pci_dev *) pointer instead of pci device id segment:bus:devfn is safe.
Or, this is a wrong way to fix this issue. I don't know IOMMU driver much now,
so IOMMU guys any comments on this issue is welcome.
If this is not safe, what about we both save pci device id and (pci_dev *)
pointer
in drhd. So we can put pci_dev ref and set pci_dev * = NULL during device
removed by bus notify, and
update (pci_dev *)pointer during device add.
like this:
struct dmar_device {
struct list_head list;
u16 segment;
u8 bus;
u8 devfn;
struct pci_dev *dev;
};
>> for_each_drhd_unit(drhd) {
>> -int i;
>> if (drhd->ignored || drhd->include_all)
>> continue;
>>
>> -for (i = 0; i < drhd->devices_cnt; i++)
>> -if (drhd->devices[i] &&
>> -!IS_GFX_DEVICE(drhd->devices[i]))
>> +list_for_each_entry(dmar_dev, >head, list) {
>> +pdev = pci_get_domain_bus_and_slot(dmar_dev->segment,
>> +dmar_dev->bus, dmar_dev->devfn);
>> +if (!IS_GFX_DEVICE(pdev)) {
>> +pci_dev_put(pdev);
>> break;
>> +}
>> +pci_dev_put(pdev);
>> +}
>>
>> -if (i < drhd->devices_cnt)
>> +if (!IS_GFX_DEVICE(pdev))
>
> I think this is clearly wrong. You acquire a pdev reference, drop the
> reference, then look at pdev again after dropping the reference. But
> as soon as you do the pci_dev_put(), you have to assume pdev is no
> longer valid.
>
You are right, should move pci_dev_put() after if
Re: [PATCH v4 0/3] x86, apic, kexec: Add disable_cpu_apic kernel parameter
Hi,
Reccently people reported kexec didn't work correctly. After check, it's
a regression. Since a code block which migrate current thread to cpu0
when executing "kexec -e", this can be reproduced by setting affinity to
CPUn(n!=0). You can find this patch in this link:
https://lkml.org/lkml/2013/11/5/88
Then I thought why we don't do this in kdump. I tried migrating current
thread to cpu0 when crash happened, it works very well. Set affinity to
make crash happened on CPUn(n!=0), then all cpus can be brought up and
dump is successful. I pasted the patch as below.
Only one thing worried me, whether the context related to crash cpu will
be different, and do we care which cpu crashed. If it need be cared, or
it doesn't involve difference, That will be great. Multiple CPUs can be
supported easily in this simpler way. Meanwhile, this patch just try to
migrate, if it's failed, we can avoid to bring up bsp.
Watch do you think about it?
diff --git a/arch/x86/kernel/crash.c b/arch/x86/kernel/crash.c
index e0e0841..9e6cf4b 100644
--- a/arch/x86/kernel/crash.c
+++ b/arch/x86/kernel/crash.c
@@ -102,6 +102,22 @@ static void kdump_nmi_shootdown_cpus(void)
void native_machine_crash_shutdown(struct pt_regs *regs)
{
+#ifdef CONFIG_SMP
+ /* The boot cpu is always logical cpu 0 */
+ int reboot_cpu_id = 0;
+
+ /* See if there has been given a command line override */
+ if ((reboot_cpu != -1) && (reboot_cpu < nr_cpu_ids) &&
+ cpu_online(reboot_cpu))
+ reboot_cpu_id = reboot_cpu;
+
+ /* Make certain the cpu I'm about to reboot on is online */
+ if (!cpu_online(reboot_cpu_id))
+ reboot_cpu_id = smp_processor_id();
+
+ /* Make certain I only run on the appropriate processor */
+ set_cpus_allowed_ptr(current, cpumask_of(reboot_cpu_id));
+
/* This function is only called after the system
* has panicked or is otherwise in a critical state.
* The minimum amount of code to allow a kexec'd kernel
@@ -114,6 +130,7 @@ void native_machine_crash_shutdown(struct pt_regs
*regs)
local_irq_disable();
kdump_nmi_shootdown_cpus();
+#endif
On 10/23/13 at 12:01am, HATAYAMA Daisuke wrote:
> This patch set is to allow kdump 2nd kernel to wake up multiple CPUs
> even if 1st kernel crashs on some AP, a continueing work from:
>
> [PATCH v3 0/2] x86, apic, kdump: Disable BSP if boot cpu is AP
> https://lkml.org/lkml/2013/10/16/300.
>
> In this version, basic design has changed. Now users need to figure
> out initial APIC ID of BSP in the 1st kernel and configures kernel
> parameter for the 2nd kernel manually using disable_cpu_apic kernel
> parameter to be newly introduced in this patch set. This design is
> more flexible than the previous version in that we no longer have to
> rely on ACPI/MP table to get initial APIC ID of BSP.
>
> Sorry, this patch set have not include in-source documentation
> requested by Borislav Petkov yet, but I'll post it later separately,
> which would be better to focus on documentation reviewing.
>
> ChangeLog
>
> v3 => v4)
>
> - Rebased on top of v3.12-rc6
>
> - Basic design has been changed. Now users need to figure out initial
> APIC ID of BSP in the 1st kernel and configures kernel parameter for
> the 2nd kernel manually using disable_cpu_apic kernel parameter to
> be newly introduced in this patch set. This design is more flexible
> than the previous version in that we no longer have to rely on
> ACPI/MP table to get initial APIC ID of BSP.
>
> v2 => v3)
>
> - Change default value of boot_cpu_is_bsp to true.
>
> - Before executing rdmsr(MSR_IA32_APICBASE), check if the number of
> processor family is larger than or equal to 6 in order to avoid
> invalid opcode exception on processors where MSR_IA32_APICBASE is
> not supported.
>
> v1 => v2)
>
> - Rebased on top of v3.12-rc5.
>
> - Fix linking time error of boot_cpu_is_bsp_init() in case of
> CONFIG_LOCAL_APIC disabled by adding empty static inline function
> instead.
>
> - Fix missing feature check by means of cpu_has_apic macro in
> boot_cpu_is_bsp_init() before calling rdmsr_safe(MSR_IA32_APICBASE).
>
> NOTE: I've checked local apic-present case only; I don't have any
> x86 processor without local apic.
>
> - Add __init annotation to boot_cpu_is_bsp_init().
>
> Test
>
> - built with and without CONFIG_LOCAL_APIC
> - tested x86_64 in case of acpi and MP table
>
> ---
>
> HATAYAMA Daisuke (3):
> x86, apic: Don't count the CPU with BP flag from MP table as booting-up
> CPU
> x86, apic: Add disable_cpu_apicid kernel parameter
> Documentation, x86, apic, kexec: Add disable_cpu_apicid kernel parameter
>
>
> Documentation/kernel-parameters.txt |9 +
> arch/x86/kernel/apic/apic.c | 29 +
> arch/x86/kernel/mpparse.c |1 -
> 3 files changed, 38 insertions(+), 1 deletion(-)
>
> --
>
> Thanks.
>
Re: PATCH] LEDS: tca6507 - fix up some comments.
On Fri, 2013-11-08 at 14:20 +1100, NeilBrown wrote: > In particular fix the capitalisation of GPIO and LED and > correct TCA6507_MAKE_CPIO, but also rewrite the comment about > platform-data to include reference to devicetree. trivia: > diff --git a/drivers/leds/leds-tca6507.c b/drivers/leds/leds-tca6507.c [] > @@ -8,7 +8,7 @@ > * double-blink. > * > * This driver can configure each line either as a 'GPIO' which is out-only > - * (no pull-up) or as an LED with variable brightness and hardware-assisted > + * (pull-up resistor required) or as an LED with variable brightness and > hardware-assisted > * blinking. Please rewrap the comment to 80 cols. -- 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/
Re: CONFIG_NO_HZ_FULL + CONFIG_PREEMPT_RT_FULL = nogo
On Thu, Nov 07, 2013 at 05:31:08AM +0100, Mike Galbraith wrote: > On Thu, 2013-11-07 at 04:26 +0100, Mike Galbraith wrote: > > On Wed, 2013-11-06 at 18:49 +0100, Thomas Gleixner wrote: > > > > I bet you are trying to work around some of the side effects of the > > > occasional tick which is still necessary despite of full nohz, right? > > > > Nope, I wanted to check out cost of nohz_full for rt, and found that it > > doesn't work at all instead, looked, and found that the sole running > > task has just awakened ksoftirqd when it wants to shut the tick down, so > > that shutdown never happens. > > Like so in virgin 3.10-rt. Box is x3550 M3 booted nowatchdog > rcu_nocbs=1-3 nohz_full=1-3, and CPUs1-3 are completely isolated via > cpusets as well. Hmmm... The fact that the CPU is getting scheduling-clock interrupts is what is causing the RCU_SOFTIRQs. If you take a scheduling-clock interrupt on a CPU that RCU is waiting for, it will do raise_softirq() in order to get the CPU to respond to RCU. So the RCU_SOFTIRQs are a direct consequence of the scheduling-clock interrupts. An untested patch that gets rid of the RCU_SOFTIRQs in this case is below. Not sure how to help with the scheduling-clock interrupts. Thanx, Paul > ... > pert-5229 [003] d..h2.. 684.481615: hrtimer_cancel: > hrtimer=88017fccbac0 > pert-5229 [003] d..h1.. 684.481616: hrtimer_expire_entry: > hrtimer=88017fccbac0 function=tick_sched_timer now=683820187877 > pert-5229 [003] d..h2.. 684.481616: sched_stat_runtime: > comm=pert pid=5229 runtime=993917 [ns] vruntime=179048871558 [ns] > pert-5229 [003] d..h1.. 684.481616: softirq_raise: vec=1 > [action=TIMER] > pert-5229 [003] d..h1.. 684.481616: hrtimer_expire_exit: > hrtimer=88017fccbac0 > pert-5229 [003] d..h2.. 684.481617: hrtimer_start: > hrtimer=88017fccbac0 function=tick_sched_timer expires=683821187500 > softexpires=683821187500 > pert-5229 [003] d...3.. 684.481618: sched_stat_runtime: > comm=pert pid=5229 runtime=1634 [ns] vruntime=179048873192 [ns] > pert-5229 [003] d.L.3.. 684.481618: sched_wakeup: > comm=ksoftirqd/3 pid=49 prio=120 success=1 target_cpu=003 > pert-5229 [003] d.L.1.. 684.481618: tick_stop: success=no > msg=more than 1 task in runqueue > > pert-5229 [003] d.L.1.. 684.481619: tick_stop: success=no > msg=more than 1 task in runqueue > > pert-5229 [003] d.L.3.. 684.481620: sched_stat_runtime: > comm=pert pid=5229 runtime=2096 [ns] vruntime=179048875288 [ns] > pert-5229 [003] d...3.. 684.481620: sched_switch: > prev_comm=pert prev_pid=5229 prev_prio=120 prev_state=R+ ==> > next_comm=ksoftirqd/3 next_pid=49 next_prio=120 > ksoftirqd/3-49[003] 111 684.481621: softirq_entry: vec=1 > [action=TIMER] > ksoftirqd/3-49[003] 111 684.481621: softirq_exit: vec=1 > [action=TIMER] > ksoftirqd/3-49[003] d...3.. 684.481622: sched_stat_runtime: > comm=ksoftirqd/3 pid=49 runtime=1934 [ns] vruntime=179039875126 [ns] > ksoftirqd/3-49[003] d...3.. 684.481622: sched_switch: > prev_comm=ksoftirqd/3 prev_pid=49 prev_prio=120 prev_state=S ==> > next_comm=pert next_pid=5229 next_prio=120 > pert-5229 [003] d...3.. 684.481623: sched_stat_runtime: > comm=pert pid=5229 runtime=1289 [ns] vruntime=179048876577 [ns] > pert-5229 [003] d..h2.. 684.482616: hrtimer_cancel: > hrtimer=88017fccbac0 > pert-5229 [003] d..h1.. 684.482617: hrtimer_expire_entry: > hrtimer=88017fccbac0 function=tick_sched_timer now=683821188024 > pert-5229 [003] d..h2.. 684.482617: sched_stat_runtime: > comm=pert pid=5229 runtime=994281 [ns] vruntime=179049870858 [ns] > pert-5229 [003] d..h1.. 684.482617: softirq_raise: vec=1 > [action=TIMER] > pert-5229 [003] d..h1.. 684.482618: softirq_raise: vec=9 > [action=RCU] > pert-5229 [003] d..h1.. 684.482618: hrtimer_expire_exit: > hrtimer=88017fccbac0 > pert-5229 [003] d..h2.. 684.482618: hrtimer_start: > hrtimer=88017fccbac0 function=tick_sched_timer expires=683822187500 > softexpires=683822187500 > pert-5229 [003] d...3.. 684.482619: sched_stat_runtime: > comm=pert pid=5229 runtime=1719 [ns] vruntime=179049872577 [ns] > pert-5229 [003] d.L.3.. 684.482619: sched_wakeup: > comm=ksoftirqd/3 pid=49 prio=120 success=1 target_cpu=003 > pert-5229 [003] d.L.1.. 684.482619: tick_stop: success=no > msg=more than 1 task in runqueue > > pert-5229 [003] d.L.1.. 684.482620: tick_stop: success=no > msg=more than 1 task in runqueue > > pert-5229 [003] d.L.3.. 684.482621: sched_stat_runtime: > comm=pert pid=5229 runtime=2204 [ns] vruntime=179049874781
PATCH] LEDS: tca6507 - fix up some comments.
In particular fix the capitalisation of GPIO and LED and
correct TCA6507_MAKE_CPIO, but also rewrite the comment about
platform-data to include reference to devicetree.
Reported-by: Bryan Wu
Signed-off-by: NeilBrown
diff --git a/drivers/leds/leds-tca6507.c b/drivers/leds/leds-tca6507.c
index 93a2b1759054..80c9d69e2bdd 100644
--- a/drivers/leds/leds-tca6507.c
+++ b/drivers/leds/leds-tca6507.c
@@ -8,7 +8,7 @@
* double-blink.
*
* This driver can configure each line either as a 'GPIO' which is out-only
- * (no pull-up) or as an LED with variable brightness and hardware-assisted
+ * (pull-up resistor required) or as an LED with variable brightness and
hardware-assisted
* blinking.
*
* Apart from OFF and ON there are three programmable brightness levels which
@@ -60,21 +60,26 @@
* and LEDs using the blink. It can only be reprogrammed when the appropriate
* counter is zero. The MASTER level has a single usage count.
*
- * Each Led has programmable 'on' and 'off' time as milliseconds. With each
+ * Each LED has programmable 'on' and 'off' time as milliseconds. With each
* there is a flag saying if it was explicitly requested or defaulted.
* Similarly the banks know if each time was explicit or a default. Defaults
* are permitted to be changed freely - they are not recognised when matching.
*
*
- * An led-tca6507 device must be provided with platform data. This data
- * lists for each output: the name, default trigger, and whether the signal
- * is being used as a GPiO rather than an led. 'struct led_plaform_data'
- * is used for this. If 'name' is NULL, the output isn't used. If 'flags'
- * is TCA6507_MAKE_CPIO, the output is a GPO.
- * The "struct led_platform_data" can be embedded in a
- * "struct tca6507_platform_data" which adds a 'gpio_base' for the GPiOs,
- * and a 'setup' callback which is called once the GPiOs are available.
+ * An led-tca6507 device must be provided with platform data or configured
+ * via devicetree.
+ * The platform-data lists for each output: the name, default trigger,
+ * and whether the signal is being used as a GPIO rather than an LED.
+ * 'struct led_plaform_data' is used for this. If 'name' is NULL, the
+ * output isn't used. If 'flags' is TCA6507_MAKE_GPIO, the output is
+ * a GPO. The "struct led_platform_data" can be embedded in a "struct
+ * tca6507_platform_data" which adds a 'gpio_base' for the GPIOs, and
+ * a 'setup' callback which is called once the GPIOs are available.
*
+ * When configured via devicetree there is one child for each output.
+ * The "reg" determines the output number and "compatible" determines
+ * whether it is an LED or a GPIO. "linux,default-trigger" can set a
+ * default trigger.
*/
#include
@@ -309,7 +314,7 @@ static void set_level(struct tca6507_chip *tca, int bank,
int level)
tca->bank[bank].level = level;
}
-/* Record all relevant time code for a given bank */
+/* Record all relevant time codes for a given bank */
static void set_times(struct tca6507_chip *tca, int bank)
{
int c1, c2;
signature.asc
Description: PGP signature
Congratulation!!! Confirm Mail Receipt!!
This is to inform you that you were among the lucky beneficiary selected to receive this donations award sum of $ 1Million US DOLLAR each as charity donations/aid from the Qatar Foundation to promote your business and personal Interest. Kindly revert back for claims processing via email: qatarfoundati...@yahoo.com.hk On behalf of the foundation, we say congratulations to you. Yours Sincerely, President of Qatar Foundation: Dr. Mohammad Fathy Saoud IMPORTANT: If you receive this message in your spam or junk its due to your network provider. -- 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/
Re: linux-next: manual merge of the block tree with the tree
On Fri, Nov 08 2013, Stephen Rothwell wrote: > Hi all, > > On Thu, 07 Nov 2013 18:04:57 -0600 Dave Kleikamp > wrote: > > > > Can you please drop the aio-direct tree for the time being? > > OK, I was afraid of this, but, yes, I can drop it. I am not quite sure > what affect this will have on Andrew's tree, though (hopefully not too > much). > > This is a bit disappointing. Dave's stuff have been sitting in > linux-next for quite some time (probably too long) so it is not as if > Kent and Jens (should) have been unaware of it. If it doesn't throw merge errors for you, I am not aware of it. -- Jens Axboe -- 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/
[PATCH 3.8 21/91] can: dev: fix nlmsg size calculation in can_get_size()
3.8.13.13 -stable review patch. If anyone has any objections, please let me know. -- From: Marc Kleine-Budde [ Upstream commit fe119a05f8ca481623a8d02efcc984332e612528 ] This patch fixes the calculation of the nlmsg size, by adding the missing nla_total_size(). Signed-off-by: Marc Kleine-Budde Signed-off-by: David S. Miller Signed-off-by: Kamal Mostafa --- drivers/net/can/dev.c | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/drivers/net/can/dev.c b/drivers/net/can/dev.c index 8233e5e..6afbe46 100644 --- a/drivers/net/can/dev.c +++ b/drivers/net/can/dev.c @@ -698,14 +698,14 @@ static size_t can_get_size(const struct net_device *dev) size_t size; size = nla_total_size(sizeof(u32)); /* IFLA_CAN_STATE */ - size += sizeof(struct can_ctrlmode); /* IFLA_CAN_CTRLMODE */ + size += nla_total_size(sizeof(struct can_ctrlmode)); /* IFLA_CAN_CTRLMODE */ size += nla_total_size(sizeof(u32)); /* IFLA_CAN_RESTART_MS */ - size += sizeof(struct can_bittiming); /* IFLA_CAN_BITTIMING */ - size += sizeof(struct can_clock); /* IFLA_CAN_CLOCK */ + size += nla_total_size(sizeof(struct can_bittiming)); /* IFLA_CAN_BITTIMING */ + size += nla_total_size(sizeof(struct can_clock)); /* IFLA_CAN_CLOCK */ if (priv->do_get_berr_counter)/* IFLA_CAN_BERR_COUNTER */ - size += sizeof(struct can_berr_counter); + size += nla_total_size(sizeof(struct can_berr_counter)); if (priv->bittiming_const)/* IFLA_CAN_BITTIMING_CONST */ - size += sizeof(struct can_bittiming_const); + size += nla_total_size(sizeof(struct can_bittiming_const)); return size; } -- 1.8.1.2 -- 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/
[PATCH 3.8 10/91] ip: fix warning in xfrm4_mode_tunnel_input
3.8.13.13 -stable review patch. If anyone has any objections, please let me know. -- From: stephen hemminger commit 9aac22deb11a3da4df5b868fc3d30b07185b0d71 upstream. Same problem as IPv6 Signed-off-by: Stephen Hemminger Signed-off-by: David S. Miller Signed-off-by: Kamal Mostafa --- net/ipv4/xfrm4_mode_tunnel.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/net/ipv4/xfrm4_mode_tunnel.c b/net/ipv4/xfrm4_mode_tunnel.c index 57dfe2b..175e8b1 100644 --- a/net/ipv4/xfrm4_mode_tunnel.c +++ b/net/ipv4/xfrm4_mode_tunnel.c @@ -142,7 +142,8 @@ static int xfrm4_mode_tunnel_input(struct xfrm_state *x, struct sk_buff *skb) for_each_input_rcu(rcv_notify_handlers, handler) handler->handler(skb); - if (err = skb_unclone(skb, GFP_ATOMIC)) + err = skb_unclone(skb, GFP_ATOMIC); + if (err) goto out; if (x->props.flags & XFRM_STATE_DECAP_DSCP) -- 1.8.1.2 -- 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/
Re: [PATCH v11 3/3] DMA: Freescale: update driver to support 8-channel DMA engine
On Mon, Nov 4, 2013 at 6:31 PM, Hongbo Zhang wrote:
> Hi Vinod Koul and Dan Williams,
> Ping?
>
Not much to review from the dmaengine side, just one question below.
It would be helpful if you can send these to the new dmaengine
patchwork at dmaeng...@vger.kernel.org with the Acks you have already
collected.
>
>
> On 10/17/2013 01:56 PM, Hongbo Zhang wrote:
>>
>> Hi Vinod,
>> I have gotten ACK from Mark for both the 1/3 and 2/3 patches.
>> Thanks.
>>
>>
>> On 09/26/2013 05:33 PM, hongbo.zh...@freescale.com wrote:
>>>
>>> From: Hongbo Zhang
>>>
>>> This patch adds support to 8-channel DMA engine, thus the driver works
>>> for both
>>> the new 8-channel and the legacy 4-channel DMA engines.
>>>
>>> Signed-off-by: Hongbo Zhang
>>> ---
>>> drivers/dma/Kconfig |9 +
>>> drivers/dma/fsldma.c |9 ++---
>>> drivers/dma/fsldma.h |2 +-
>>> 3 files changed, 12 insertions(+), 8 deletions(-)
>>>
>>> diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
>>> index 6825957..3979c65 100644
>>> --- a/drivers/dma/Kconfig
>>> +++ b/drivers/dma/Kconfig
>>> @@ -89,14 +89,15 @@ config AT_HDMAC
>>> Support the Atmel AHB DMA controller.
>>> config FSL_DMA
>>> -tristate "Freescale Elo and Elo Plus DMA support"
>>> +tristate "Freescale Elo series DMA support"
>>> depends on FSL_SOC
>>> select DMA_ENGINE
>>> select ASYNC_TX_ENABLE_CHANNEL_SWITCH
>>> ---help---
>>> - Enable support for the Freescale Elo and Elo Plus DMA controllers.
>>> - The Elo is the DMA controller on some 82xx and 83xx parts, and the
>>> - Elo Plus is the DMA controller on 85xx and 86xx parts.
>>> + Enable support for the Freescale Elo series DMA controllers.
>>> + The Elo is the DMA controller on some mpc82xx and mpc83xx parts,
>>> the
>>> + EloPlus is on mpc85xx and mpc86xx and Pxxx parts, and the Elo3 is
>>> on
>>> + some Txxx and Bxxx parts.
>>> config MPC512X_DMA
>>> tristate "Freescale MPC512x built-in DMA engine support"
>>> diff --git a/drivers/dma/fsldma.c b/drivers/dma/fsldma.c
>>> index 49e8fbd..16a9a48 100644
>>> --- a/drivers/dma/fsldma.c
>>> +++ b/drivers/dma/fsldma.c
>>> @@ -1261,7 +1261,9 @@ static int fsl_dma_chan_probe(struct fsldma_device
>>> *fdev,
>>> WARN_ON(fdev->feature != chan->feature);
>>> chan->dev = fdev->dev;
>>> -chan->id = ((res.start - 0x100) & 0xfff) >> 7;
>>> +chan->id = (res.start & 0xfff) < 0x300 ?
>>> + ((res.start - 0x100) & 0xfff) >> 7 :
>>> + ((res.start - 0x200) & 0xfff) >> 7;
>>> if (chan->id >= FSL_DMA_MAX_CHANS_PER_DEVICE) {
Isn't it a bit fragile to have this based on the resource address?
Can't device tree tell you the channel id directly by an index into
the "dma0: dma@100300" node?
--
Dan
--
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/
[PATCH] scripts: kallsyms: Use %zu to print 'size_t'
From: Fabio Estevam
Commit f3462aa95 (Kbuild: Handle longer symbols in kallsyms.c) introduced the
following warning on ARM:
scripts/kallsyms.c:121:4: warning: format '%lu' expects argument of type 'long
unsigned int', but argument 4 has type 'size_t' [-Wformat]
Use %zu to print 'size_t'.
Signed-off-by: Fabio Estevam
---
scripts/kallsyms.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/scripts/kallsyms.c b/scripts/kallsyms.c
index 11552e0..990695c 100644
--- a/scripts/kallsyms.c
+++ b/scripts/kallsyms.c
@@ -116,7 +116,7 @@ static int read_symbol(FILE *in, struct sym_entry *s)
return -1;
}
if (strlen(str) > KSYM_NAME_LEN) {
- fprintf(stderr, "Symbol %s too long for kallsyms (%lu vs %d).\n"
+ fprintf(stderr, "Symbol %s too long for kallsyms (%zu vs %d).\n"
"Please increase KSYM_NAME_LEN both in kernel
and kallsyms.c\n",
str, strlen(str), KSYM_NAME_LEN);
return -1;
--
1.8.1.2
--
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/
[PATCH 3.8 15/91] l2tp: Fix build warning with ipv6 disabled.
3.8.13.13 -stable review patch. If anyone has any objections, please let me
know.
--
From: "David S. Miller"
[ Upstream commit 8d8a51e26a6d415e1470759f2cf5f3ee3ee86196 ]
net/l2tp/l2tp_core.c: In function ‘l2tp_verify_udp_checksum’:
net/l2tp/l2tp_core.c:499:22: warning: unused variable ‘tunnel’
[-Wunused-variable]
Create a helper "l2tp_tunnel()" to facilitate this, and as a side
effect get rid of a bunch of unnecessary void pointer casts.
Signed-off-by: David S. Miller
Signed-off-by: Kamal Mostafa
---
net/l2tp/l2tp_core.c | 13 -
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/net/l2tp/l2tp_core.c b/net/l2tp/l2tp_core.c
index 8861e9f..02a922c 100644
--- a/net/l2tp/l2tp_core.c
+++ b/net/l2tp/l2tp_core.c
@@ -115,6 +115,11 @@ static void l2tp_session_set_header_len(struct
l2tp_session *session, int versio
static void l2tp_tunnel_free(struct l2tp_tunnel *tunnel);
static void l2tp_tunnel_closeall(struct l2tp_tunnel *tunnel);
+static inline struct l2tp_tunnel *l2tp_tunnel(struct sock *sk)
+{
+ return sk->sk_user_data;
+}
+
static inline struct l2tp_net *l2tp_pernet(struct net *net)
{
BUG_ON(!net);
@@ -517,7 +522,6 @@ out:
static inline int l2tp_verify_udp_checksum(struct sock *sk,
struct sk_buff *skb)
{
- struct l2tp_tunnel *tunnel = (struct l2tp_tunnel *)sk->sk_user_data;
struct udphdr *uh = udp_hdr(skb);
u16 ulen = ntohs(uh->len);
__wsum psum;
@@ -526,7 +530,7 @@ static inline int l2tp_verify_udp_checksum(struct sock *sk,
return 0;
#if IS_ENABLED(CONFIG_IPV6)
- if (sk->sk_family == PF_INET6 && !tunnel->v4mapped) {
+ if (sk->sk_family == PF_INET6 && !l2tp_tunnel(sk)->v4mapped) {
if (!uh->check) {
LIMIT_NETDEBUG(KERN_INFO "L2TP: IPv6: checksum is 0\n");
return 1;
@@ -1271,9 +1275,8 @@ EXPORT_SYMBOL_GPL(l2tp_xmit_skb);
*/
static void l2tp_tunnel_destruct(struct sock *sk)
{
- struct l2tp_tunnel *tunnel;
+ struct l2tp_tunnel *tunnel = l2tp_tunnel(sk);
- tunnel = sk->sk_user_data;
if (tunnel == NULL)
goto end;
@@ -1596,7 +1599,7 @@ int l2tp_tunnel_create(struct net *net, int fd, int
version, u32 tunnel_id, u32
}
/* Check if this socket has already been prepped */
- tunnel = (struct l2tp_tunnel *)sk->sk_user_data;
+ tunnel = l2tp_tunnel(sk);
if (tunnel != NULL) {
/* This socket has already been prepped */
err = -EBUSY;
--
1.8.1.2
--
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/
[PATCH 3.8 09/91] ipv6: fix warning in xfrm6_mode_tunnel_input
3.8.13.13 -stable review patch. If anyone has any objections, please let me know. -- From: stephen hemminger commit 0d4bfa297c3f7efb71367449ee44f9d3fb0f5871 upstream. Should not use assignment in conditional: warning: suggest parentheses around assignment used as truth value [-Wparentheses] Problem introduced by: commit 14bbd6a565e1bcdc240d44687edb93f721cfdf99 Author: Pravin B Shelar Date: Thu Feb 14 09:44:49 2013 + net: Add skb_unclone() helper function. Signed-off-by: Stephen Hemminger Signed-off-by: David S. Miller Signed-off-by: Kamal Mostafa --- net/ipv6/xfrm6_mode_tunnel.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/net/ipv6/xfrm6_mode_tunnel.c b/net/ipv6/xfrm6_mode_tunnel.c index 93c41a8..9bf6a74 100644 --- a/net/ipv6/xfrm6_mode_tunnel.c +++ b/net/ipv6/xfrm6_mode_tunnel.c @@ -69,7 +69,8 @@ static int xfrm6_mode_tunnel_input(struct xfrm_state *x, struct sk_buff *skb) if (!pskb_may_pull(skb, sizeof(struct ipv6hdr))) goto out; - if (err = skb_unclone(skb, GFP_ATOMIC)) + err = skb_unclone(skb, GFP_ATOMIC); + if (err) goto out; if (x->props.flags & XFRM_STATE_DECAP_DSCP) -- 1.8.1.2 -- 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/
[PATCH 3.8 12/91] tcp: do not forget FIN in tcp_shifted_skb()
3.8.13.13 -stable review patch. If anyone has any objections, please let me
know.
--
From: Eric Dumazet
[ Upstream commit 5e8a402f831dbe7ee831340a91439e46f0d38acd ]
Yuchung found following problem :
There are bugs in the SACK processing code, merging part in
tcp_shift_skb_data(), that incorrectly resets or ignores the sacked
skbs FIN flag. When a receiver first SACK the FIN sequence, and later
throw away ofo queue (e.g., sack-reneging), the sender will stop
retransmitting the FIN flag, and hangs forever.
Following packetdrill test can be used to reproduce the bug.
$ cat sack-merge-bug.pkt
`sysctl -q net.ipv4.tcp_fack=0`
// Establish a connection and send 10 MSS.
0.000 socket(..., SOCK_STREAM, IPPROTO_TCP) = 3
+.000 setsockopt(3, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0
+.000 bind(3, ..., ...) = 0
+.000 listen(3, 1) = 0
+.050 < S 0:0(0) win 32792
+.000 > S. 0:0(0) ack 1
+.001 < . 1:1(0) ack 1 win 1024
+.000 accept(3, ..., ...) = 4
+.100 write(4, ..., 12000) = 12000
+.000 shutdown(4, SHUT_WR) = 0
+.000 > . 1:10001(1) ack 1
+.050 < . 1:1(0) ack 2001 win 257
+.000 > FP. 10001:12001(2000) ack 1
+.050 < . 1:1(0) ack 2001 win 257
+.050 < . 1:1(0) ack 2001 win 257
// SACK reneg
+.050 < . 1:1(0) ack 12001 win 257
+0 %{ print "unacked: ",tcpi_unacked }%
+5 %{ print "" }%
First, a typo inverted left/right of one OR operation, then
code forgot to advance end_seq if the merged skb carried FIN.
Bug was added in 2.6.29 by commit 832d11c5cd076ab
("tcp: Try to restore large SKBs while SACK processing")
Signed-off-by: Eric Dumazet
Signed-off-by: Yuchung Cheng
Acked-by: Neal Cardwell
Cc: Ilpo Järvinen
Acked-by: Ilpo Järvinen
Signed-off-by: David S. Miller
Signed-off-by: Kamal Mostafa
---
net/ipv4/tcp_input.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
index b2263d8..9bef66b 100644
--- a/net/ipv4/tcp_input.c
+++ b/net/ipv4/tcp_input.c
@@ -1300,7 +1300,10 @@ static bool tcp_shifted_skb(struct sock *sk, struct
sk_buff *skb,
tp->lost_cnt_hint -= tcp_skb_pcount(prev);
}
- TCP_SKB_CB(skb)->tcp_flags |= TCP_SKB_CB(prev)->tcp_flags;
+ TCP_SKB_CB(prev)->tcp_flags |= TCP_SKB_CB(skb)->tcp_flags;
+ if (TCP_SKB_CB(skb)->tcp_flags & TCPHDR_FIN)
+ TCP_SKB_CB(prev)->end_seq++;
+
if (skb == tcp_highest_sack(sk))
tcp_advance_highest_sack(sk, skb);
--
1.8.1.2
--
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/
Re: [PATCH 3/6] Squashfs: add multi-threaded decompression using percpu variables
Hello Phillip, On Thu, Nov 07, 2013 at 08:24:22PM +, Phillip Lougher wrote: > Add a multi-threaded decompression implementation which uses > percpu variables. > > Using percpu variables has advantages and disadvantages over > implementations which do not use percpu variables. > > Advantages: the nature of percpu variables ensures decompression is > load-balanced across the multiple cores. > > Disadvantages: it limits decompression to one thread per core. At a glance, I understand your concern but I don't see benefit to make this feature as separate new config because we can modify the number of decompressor per core in the future. I don't want to create new config SQUASHFS_DECOMP_MULTI_3, SQUASHFS_DECOMP_MULTI_4 and so on. :) How about this? 1. Let's make CONFIG_DECOMPRESSOR_MAX which could be tuned by admin in Kconfig. default is CPU *2 or CPU, Otherwise, we can put it to sysfs so user can tune it in rumtime. 2. put decompressor shrink logic by slab shrinker so if system has memory pressure, we could catch the event and free some of decompressor but memory pressure is not severe again in the future, we can create new decompressor until reaching threadhold user define. We could know system memory is enough by GFP_NOWAIT, not GFP_KERNEL in get_decomp_stream's allocation indirectly. In short, let's make decompressor_multi as dynamically tuned system and user can limit the max. > > Signed-off-by: Phillip Lougher > --- > fs/squashfs/Kconfig | 57 + > fs/squashfs/Makefile| 10 +-- > fs/squashfs/decompressor_multi_percpu.c | 105 > +++ > 3 files changed, 152 insertions(+), 20 deletions(-) > create mode 100644 fs/squashfs/decompressor_multi_percpu.c > > diff --git a/fs/squashfs/Kconfig b/fs/squashfs/Kconfig > index 1c6d340..c92c75f 100644 > --- a/fs/squashfs/Kconfig > +++ b/fs/squashfs/Kconfig > @@ -25,6 +25,50 @@ config SQUASHFS > > If unsure, say N. > > +choice > + prompt "Decompressor parallelisation options" > + depends on SQUASHFS > + help > + Squashfs now supports three parallelisation options for > + decompression. Each one exhibits various trade-offs between > + decompression performance and CPU and memory usage. > + > + If in doubt, select "Single threaded compression" > + > +config SQUASHFS_DECOMP_SINGLE > + bool "Single threaded compression" > + help > + Traditionally Squashfs has used single-threaded decompression. > + Only one block (data or metadata) can be decompressed at any > + one time. This limits CPU and memory usage to a minimum. > + > +config SQUASHFS_DECOMP_MULTI > + bool "Use multiple decompressors for parallel I/O" > + help > + By default Squashfs uses a single decompressor but it gives > + poor performance on parallel I/O workloads when using multiple CPU > + machines due to waiting on decompressor availability. > + > + If you have a parallel I/O workload and your system has enough memory, > + using this option may improve overall I/O performance. > + > + This decompressor implementation uses up to two parallel > + decompressors per core. It dynamically allocates decompressors > + on a demand basis. I'm not sure it's good idea to write how many of parallel decompressor per core. IMO, It's implementation stuff and user don't need to know internal. And we could modify it in the future. > + > +config SQUASHFS_DECOMP_MULTI_PERCPU > + bool "Use percpu multiple decompressors for parallel I/O" > + help Indentation. > + By default Squashfs uses a single decompressor but it gives > + poor performance on parallel I/O workloads when using multiple CPU > + machines due to waiting on decompressor availability. > + > + This decompressor implementation uses a maximum of one > + decompressor per core. It uses percpu variables to ensure > + decompression is load-balanced across the cores. > + > +endchoice > + > config SQUASHFS_XATTR > bool "Squashfs XATTR support" > depends on SQUASHFS > @@ -63,19 +107,6 @@ config SQUASHFS_LZO > > If unsure, say N. > > -config SQUASHFS_MULTI_DECOMPRESSOR > - bool "Use multiple decompressors for handling parallel I/O" > - depends on SQUASHFS > - help > - By default Squashfs uses a single decompressor but it gives > - poor performance on parallel I/O workloads when using multiple CPU > - machines due to waiting on decompressor availability. > - > - If you have a parallel I/O workload and your system has enough memory, > - using this option may improve overall I/O performance. > - > - If unsure, say N. > - > config SQUASHFS_XZ > bool "Include support for XZ compressed file systems" > depends on SQUASHFS > diff --git a/fs/squashfs/Makefile b/fs/squashfs/Makefile > index
[PATCH v2] arch: arc: uapi: be sure of "_UAPI" prefix for all guard macros
For all uapi headers, need use "_UAPI" prefix for its guard macro
(which will be stripped by "scripts/headers_installer.sh").
And be sure that all "endif" need append (or have correct) related
comment, and all normal uapi header files need content guard macro.
Also reserve guard macro in empty file, since some "usr/include/*"
header files may check guard macro to know whether content related
header file.
Cc: David Howells
Signed-off-by: Chen Gang
---
arch/arc/include/uapi/asm/byteorder.h |6 +++---
arch/arc/include/uapi/asm/cachectl.h |6 +++---
arch/arc/include/uapi/asm/elf.h|2 +-
arch/arc/include/uapi/asm/setup.h |9 +++--
arch/arc/include/uapi/asm/sigcontext.h |6 +++---
arch/arc/include/uapi/asm/signal.h |6 +++---
arch/arc/include/uapi/asm/swab.h |6 +++---
arch/arc/include/uapi/asm/unistd.h |4
8 files changed, 27 insertions(+), 18 deletions(-)
diff --git a/arch/arc/include/uapi/asm/byteorder.h
b/arch/arc/include/uapi/asm/byteorder.h
index 9da71d4..859fde2 100644
--- a/arch/arc/include/uapi/asm/byteorder.h
+++ b/arch/arc/include/uapi/asm/byteorder.h
@@ -6,8 +6,8 @@
* published by the Free Software Foundation.
*/
-#ifndef __ASM_ARC_BYTEORDER_H
-#define __ASM_ARC_BYTEORDER_H
+#ifndef _UAPI__ASM_ARC_BYTEORDER_H
+#define _UAPI__ASM_ARC_BYTEORDER_H
#ifdef CONFIG_CPU_BIG_ENDIAN
#include
@@ -15,4 +15,4 @@
#include
#endif
-#endif /* ASM_ARC_BYTEORDER_H */
+#endif /* _UAPI__ASM_ARC_BYTEORDER_H */
diff --git a/arch/arc/include/uapi/asm/cachectl.h
b/arch/arc/include/uapi/asm/cachectl.h
index 51c73f0..2437fc6 100644
--- a/arch/arc/include/uapi/asm/cachectl.h
+++ b/arch/arc/include/uapi/asm/cachectl.h
@@ -6,8 +6,8 @@
* published by the Free Software Foundation.
*/
-#ifndef __ARC_ASM_CACHECTL_H
-#define __ARC_ASM_CACHECTL_H
+#ifndef _UAPI__ARC_ASM_CACHECTL_H
+#define _UAPI__ARC_ASM_CACHECTL_H
/*
* ARC ABI flags defined for Android's finegrained cacheflush requirements
@@ -25,4 +25,4 @@
#define DCACHE CF_D_FLUSH
#define BCACHE (CF_I_INV | CF_D_FLUSH)
-#endif
+#endif /* _UAPI__ARC_ASM_CACHECTL_H */
diff --git a/arch/arc/include/uapi/asm/elf.h b/arch/arc/include/uapi/asm/elf.h
index 0f99ac8..4e82dc6 100644
--- a/arch/arc/include/uapi/asm/elf.h
+++ b/arch/arc/include/uapi/asm/elf.h
@@ -23,4 +23,4 @@ typedef unsigned long elf_fpregset_t;
typedef elf_greg_t elf_gregset_t[ELF_NGREG];
-#endif
+#endif /* _UAPI__ASM_ARC_ELF_H */
diff --git a/arch/arc/include/uapi/asm/setup.h
b/arch/arc/include/uapi/asm/setup.h
index a6d4e44..09a8df7 100644
--- a/arch/arc/include/uapi/asm/setup.h
+++ b/arch/arc/include/uapi/asm/setup.h
@@ -1,6 +1,11 @@
/*
* setup.h is part of userspace header ABI so UAPI scripts have to generate it
* even if there's nothing to export - causing empty
- * However to prevent "patch" from discarding it we add this placeholder
- * comment
+ *
+ * And some user programs may check guard macro to know whether content related
+ * header file (e.g. some of "/usr/include/ *" header files check guard macro),
+ * so recommend to still reserve guard macro in empty file.
*/
+#ifndef _UAPI__ASM_ARC_SETUP_H
+#define _UAPI__ASM_ARC_SETUP_H
+#endif /* _UAPI__ASM_ARC_SETUP_H */
diff --git a/arch/arc/include/uapi/asm/sigcontext.h
b/arch/arc/include/uapi/asm/sigcontext.h
index 9678a11..b2063ff 100644
--- a/arch/arc/include/uapi/asm/sigcontext.h
+++ b/arch/arc/include/uapi/asm/sigcontext.h
@@ -6,8 +6,8 @@
* published by the Free Software Foundation.
*/
-#ifndef _ASM_ARC_SIGCONTEXT_H
-#define _ASM_ARC_SIGCONTEXT_H
+#ifndef _UAPI_ASM_ARC_SIGCONTEXT_H
+#define _UAPI_ASM_ARC_SIGCONTEXT_H
#include
@@ -19,4 +19,4 @@ struct sigcontext {
struct user_regs_struct regs;
};
-#endif /* _ASM_ARC_SIGCONTEXT_H */
+#endif /* _UAPI_ASM_ARC_SIGCONTEXT_H */
diff --git a/arch/arc/include/uapi/asm/signal.h
b/arch/arc/include/uapi/asm/signal.h
index fad62f7..f212d83 100644
--- a/arch/arc/include/uapi/asm/signal.h
+++ b/arch/arc/include/uapi/asm/signal.h
@@ -8,8 +8,8 @@
* Amit Bhor, Sameer Dhavale: Codito Technologies 2004
*/
-#ifndef _ASM_ARC_SIGNAL_H
-#define _ASM_ARC_SIGNAL_H
+#ifndef _UAPI_ASM_ARC_SIGNAL_H
+#define _UAPI_ASM_ARC_SIGNAL_H
/*
* This is much needed for ARC sigreturn optimization.
@@ -24,4 +24,4 @@
#include
-#endif /* _ASM_ARC_SIGNAL_H */
+#endif /* _UAPI_ASM_ARC_SIGNAL_H */
diff --git a/arch/arc/include/uapi/asm/swab.h b/arch/arc/include/uapi/asm/swab.h
index 095599a..7237a21 100644
--- a/arch/arc/include/uapi/asm/swab.h
+++ b/arch/arc/include/uapi/asm/swab.h
@@ -13,8 +13,8 @@
* -Hardware assisted single cycle bswap (Use Case of ARC custom instrn)
*/
-#ifndef __ASM_ARC_SWAB_H
-#define __ASM_ARC_SWAB_H
+#ifndef _UAPI__ASM_ARC_SWAB_H
+#define _UAPI__ASM_ARC_SWAB_H
#include
@@ -95,4 +95,4 @@
#define __SWAB_64_THRU_32__
#endif
-#endif
+#endif /* _UAPI__ASM_ARC_SWAB_H */
diff --git a/arch/arc/include/uapi/asm/unistd.h
b/arch/arc/include/uapi/asm/unistd.h
[PATCH 3.8 14/91] l2tp: fix kernel panic when using IPv4-mapped IPv6 addresses
3.8.13.13 -stable review patch. If anyone has any objections, please let me
know.
--
From: =?UTF-8?q?Fran=C3=A7ois=20Cachereul?=
[ Upstream commit e18503f41f9b12132c95d7c31ca6ee5155e44e5c ]
IPv4 mapped addresses cause kernel panic.
The patch juste check whether the IPv6 address is an IPv4 mapped
address. If so, use IPv4 API instead of IPv6.
[ 940.026915] general protection fault: [#1]
[ 940.026915] Modules linked in: l2tp_ppp l2tp_netlink l2tp_core pppox
ppp_generic slhc loop psmouse
[ 940.026915] CPU: 0 PID: 3184 Comm: memcheck-amd64- Not tainted 3.11.0+ #1
[ 940.026915] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2007
[ 940.026915] task: 880007130e20 ti: 88000737e000 task.ti:
88000737e000
[ 940.026915] RIP: 0010:[] []
ip6_xmit+0x276/0x326
[ 940.026915] RSP: 0018:88000737fd28 EFLAGS: 00010286
[ 940.026915] RAX: c748521a75ceff48 RBX: 88c30800 RCX:
[ 940.026915] RDX: 8875cc4e RSI: 0028 RDI: 8800060e5a40
[ 940.026915] RBP: 8800060e5a40 R08: R09: 8875cc90
[ 940.026915] R10: R11: R12: 88000737fda0
[ 940.026915] R13: R14: 2000 R15: 880005d3b580
[ 940.026915] FS: 7f163dc5e800() GS:81623000()
knlGS:
[ 940.026915] CS: 0010 DS: ES: CR0: 80050033
[ 940.026915] CR2: 0004032dc940 CR3: 05c25000 CR4: 06f0
[ 940.026915] Stack:
[ 940.026915] 8875cc4e 81694e90 88c30b38
0020
[ 940.026915] 1100523c4bac 88000737fdb4
88c30800
[ 940.026915] 880005d3b580 88c30b38 8800060e5a40
0020
[ 940.026915] Call Trace:
[ 940.026915] [] ? inet6_csk_xmit+0xa4/0xc4
[ 940.026915] [] ? l2tp_xmit_skb+0x503/0x55a [l2tp_core]
[ 940.026915] [] ? pskb_expand_head+0x161/0x214
[ 940.026915] [] ? pppol2tp_xmit+0xf2/0x143 [l2tp_ppp]
[ 940.026915] [] ? ppp_channel_push+0x36/0x8b [ppp_generic]
[ 940.026915] [] ? ppp_write+0xaf/0xc5 [ppp_generic]
[ 940.026915] [] ? vfs_write+0xa2/0x106
[ 940.026915] [] ? SyS_write+0x56/0x8a
[ 940.026915] [] ? system_call_fastpath+0x16/0x1b
[ 940.026915] Code: 00 49 8b 8f d8 00 00 00 66 83 7c 11 02 00 74 60 49
8b 47 58 48 83 e0 fe 48 8b 80 18 01 00 00 48 85 c0 74 13 48 8b 80 78 02
00 00 <48> ff 40 28 41 8b 57 68 48 01 50 30 48 8b 54 24 08 49 c7 c1 51
[ 940.026915] RIP [] ip6_xmit+0x276/0x326
[ 940.026915] RSP
[ 940.057945] ---[ end trace be8aba9a61c8b7f3 ]---
[ 940.058583] Kernel panic - not syncing: Fatal exception in interrupt
Signed-off-by: François CACHEREUL
Signed-off-by: David S. Miller
Signed-off-by: Kamal Mostafa
---
net/l2tp/l2tp_core.c | 27 +++
net/l2tp/l2tp_core.h | 3 +++
2 files changed, 26 insertions(+), 4 deletions(-)
diff --git a/net/l2tp/l2tp_core.c b/net/l2tp/l2tp_core.c
index 2ac884d..8861e9f 100644
--- a/net/l2tp/l2tp_core.c
+++ b/net/l2tp/l2tp_core.c
@@ -517,6 +517,7 @@ out:
static inline int l2tp_verify_udp_checksum(struct sock *sk,
struct sk_buff *skb)
{
+ struct l2tp_tunnel *tunnel = (struct l2tp_tunnel *)sk->sk_user_data;
struct udphdr *uh = udp_hdr(skb);
u16 ulen = ntohs(uh->len);
__wsum psum;
@@ -525,7 +526,7 @@ static inline int l2tp_verify_udp_checksum(struct sock *sk,
return 0;
#if IS_ENABLED(CONFIG_IPV6)
- if (sk->sk_family == PF_INET6) {
+ if (sk->sk_family == PF_INET6 && !tunnel->v4mapped) {
if (!uh->check) {
LIMIT_NETDEBUG(KERN_INFO "L2TP: IPv6: checksum is 0\n");
return 1;
@@ -1088,7 +1089,7 @@ static int l2tp_xmit_core(struct l2tp_session *session,
struct sk_buff *skb,
/* Queue the packet to IP for output */
skb->local_df = 1;
#if IS_ENABLED(CONFIG_IPV6)
- if (skb->sk->sk_family == PF_INET6)
+ if (skb->sk->sk_family == PF_INET6 && !tunnel->v4mapped)
error = inet6_csk_xmit(skb, NULL);
else
#endif
@@ -1221,7 +1222,7 @@ int l2tp_xmit_skb(struct l2tp_session *session, struct
sk_buff *skb, int hdr_len
/* Calculate UDP checksum if configured to do so */
#if IS_ENABLED(CONFIG_IPV6)
- if (sk->sk_family == PF_INET6)
+ if (sk->sk_family == PF_INET6 && !tunnel->v4mapped)
l2tp_xmit_ipv6_csum(sk, skb, udp_len);
else
#endif
@@ -1624,6 +1625,24 @@ int l2tp_tunnel_create(struct net *net, int fd, int
version, u32 tunnel_id, u32
if (cfg != NULL)
tunnel->debug = cfg->debug;
+#if IS_ENABLED(CONFIG_IPV6)
+ if (sk->sk_family == PF_INET6) {
+ struct ipv6_pinfo *np = inet6_sk(sk);
+
+ if (ipv6_addr_v4mapped(>saddr) &&
+ ipv6_addr_v4mapped(>daddr)) {
+
[PATCH 3.8 17/91] net: mv643xx_eth: fix orphaned statistics timer crash
3.8.13.13 -stable review patch. If anyone has any objections, please let me know. -- From: Sebastian Hesselbarth [ Upstream commit f564412c935111c583b787bcc18157377b208e2e ] The periodic statistics timer gets started at port _probe() time, but is stopped on _stop() only. In a modular environment, this can cause the timer to access already deallocated memory, if the module is unloaded without starting the eth device. To fix this, we add the timer right before the port is started, instead of at _probe() time. Signed-off-by: Sebastian Hesselbarth Acked-by: Jason Cooper Signed-off-by: David S. Miller Signed-off-by: Kamal Mostafa --- drivers/net/ethernet/marvell/mv643xx_eth.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/ethernet/marvell/mv643xx_eth.c b/drivers/net/ethernet/marvell/mv643xx_eth.c index 6d89717..0733685 100644 --- a/drivers/net/ethernet/marvell/mv643xx_eth.c +++ b/drivers/net/ethernet/marvell/mv643xx_eth.c @@ -2366,6 +2366,7 @@ static int mv643xx_eth_open(struct net_device *dev) mp->int_mask |= INT_TX_END_0 << i; } + add_timer(>mib_counters_timer); port_start(mp); wrlp(mp, INT_MASK_EXT, INT_EXT_LINK_PHY | INT_EXT_TX); @@ -2913,7 +2914,6 @@ static int mv643xx_eth_probe(struct platform_device *pdev) mp->mib_counters_timer.data = (unsigned long)mp; mp->mib_counters_timer.function = mib_counters_timer_wrapper; mp->mib_counters_timer.expires = jiffies + 30 * HZ; - add_timer(>mib_counters_timer); spin_lock_init(>mib_counters_lock); -- 1.8.1.2 -- 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/
[PATCH 3.8 03/91] ACPICA: Return error if DerefOf resolves to a null package element.
3.8.13.13 -stable review patch. If anyone has any objections, please let me
know.
--
From: Bob Moore
commit a50abf4842dd7d603a2ad6dcc7f1467fd2a66f03 upstream.
Disallow the dereference of a reference (via index) to an uninitialized
package element. Provides compatibility with other ACPI
implementations. ACPICA BZ 1003.
References: https://bugs.acpica.org/show_bug.cgi?id=431
Signed-off-by: Bob Moore
Signed-off-by: Lv Zheng
Signed-off-by: Rafael J. Wysocki
Signed-off-by: Kamal Mostafa
---
drivers/acpi/acpica/exoparg1.c | 13 ++---
1 file changed, 10 insertions(+), 3 deletions(-)
diff --git a/drivers/acpi/acpica/exoparg1.c b/drivers/acpi/acpica/exoparg1.c
index 1fa1ad6..c9f1a21 100644
--- a/drivers/acpi/acpica/exoparg1.c
+++ b/drivers/acpi/acpica/exoparg1.c
@@ -969,10 +969,17 @@ acpi_status acpi_ex_opcode_1A_0T_1R(struct
acpi_walk_state *walk_state)
*/
return_desc =
*(operand[0]->reference.where);
- if (return_desc) {
- acpi_ut_add_reference
- (return_desc);
+ if (!return_desc) {
+ /*
+* Element is NULL, do not
allow the dereference.
+* This provides compatibility
with other ACPI
+* implementations.
+*/
+ return_ACPI_STATUS
+
(AE_AML_UNINITIALIZED_ELEMENT);
}
+
+ acpi_ut_add_reference(return_desc);
break;
default:
--
1.8.1.2
--
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/
[PATCH 3.8 13/91] net: do not call sock_put() on TIMEWAIT sockets
3.8.13.13 -stable review patch. If anyone has any objections, please let me
know.
--
From: Eric Dumazet
[ Upstream commit 80ad1d61e72d626e30ebe8529a0455e660ca4693 ]
commit 3ab5aee7fe84 ("net: Convert TCP & DCCP hash tables to use RCU /
hlist_nulls") incorrectly used sock_put() on TIMEWAIT sockets.
We should instead use inet_twsk_put()
Signed-off-by: Eric Dumazet
Signed-off-by: David S. Miller
Signed-off-by: Kamal Mostafa
---
net/ipv4/inet_hashtables.c | 2 +-
net/ipv6/inet6_hashtables.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/ipv4/inet_hashtables.c b/net/ipv4/inet_hashtables.c
index fa3ae81..341508d 100644
--- a/net/ipv4/inet_hashtables.c
+++ b/net/ipv4/inet_hashtables.c
@@ -274,7 +274,7 @@ begintw:
if (unlikely(!INET_TW_MATCH(sk, net, acookie,
saddr, daddr, ports,
dif))) {
- sock_put(sk);
+ inet_twsk_put(inet_twsk(sk));
goto begintw;
}
goto out;
diff --git a/net/ipv6/inet6_hashtables.c b/net/ipv6/inet6_hashtables.c
index dea17fd..b9a7bfb 100644
--- a/net/ipv6/inet6_hashtables.c
+++ b/net/ipv6/inet6_hashtables.c
@@ -116,7 +116,7 @@ begintw:
}
if (unlikely(!INET6_TW_MATCH(sk, net, saddr, daddr,
ports, dif))) {
- sock_put(sk);
+ inet_twsk_put(inet_twsk(sk));
goto begintw;
}
goto out;
--
1.8.1.2
--
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/
[PATCH 3.8 01/91] ACPICA: Interpreter: Fix Store() when implicit conversion is not possible.
3.8.13.13 -stable review patch. If anyone has any objections, please let me
know.
--
From: Bob Moore
commit 3f654bad3257427bea7ba1c4d43a23d99a03622b upstream.
For the cases such as a store of a string to an existing package
object, implement the store as a CopyObject().
This is a small departure from the ACPI specification which states
that the control method should be aborted in this case. However,
ASLTS suite depends on this behavior.
Signed-off-by: Bob Moore
Signed-off-by: Lv Zheng
Signed-off-by: Rafael J. Wysocki
Signed-off-by: Kamal Mostafa
---
drivers/acpi/acpica/exstore.c | 29 -
1 file changed, 24 insertions(+), 5 deletions(-)
diff --git a/drivers/acpi/acpica/exstore.c b/drivers/acpi/acpica/exstore.c
index 90431f1..4ff37e8 100644
--- a/drivers/acpi/acpica/exstore.c
+++ b/drivers/acpi/acpica/exstore.c
@@ -487,14 +487,33 @@ acpi_ex_store_object_to_node(union acpi_operand_object
*source_desc,
default:
ACPI_DEBUG_PRINT((ACPI_DB_EXEC,
- "Storing %s (%p) directly into node (%p) with
no implicit conversion\n",
+ "Storing [%s] (%p) directly into node [%s]
(%p)"
+ " with no implicit conversion\n",
acpi_ut_get_object_type_name(source_desc),
- source_desc, node));
+ source_desc,
+ acpi_ut_get_object_type_name(target_desc),
+ node));
- /* No conversions for all other types. Just attach the source
object */
+ /*
+* No conversions for all other types. Directly store a copy of
+* the source object. NOTE: This is a departure from the ACPI
+* spec, which states "If conversion is impossible, abort the
+* running control method".
+*
+* This code implements "If conversion is impossible, treat the
+* Store operation as a CopyObject".
+*/
+ status =
+ acpi_ut_copy_iobject_to_iobject(source_desc, _desc,
+ walk_state);
+ if (ACPI_FAILURE(status)) {
+ return_ACPI_STATUS(status);
+ }
- status = acpi_ns_attach_object(node, source_desc,
- source_desc->common.type);
+ status =
+ acpi_ns_attach_object(node, new_desc,
+ new_desc->common.type);
+ acpi_ut_remove_reference(new_desc);
break;
}
--
1.8.1.2
--
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/
[PATCH 3.8 11/91] tcp: must unclone packets before mangling them
3.8.13.13 -stable review patch. If anyone has any objections, please let me
know.
--
From: Eric Dumazet
[ Upstream commit c52e2421f7368fd36cbe330d2cf41b10452e39a9 ]
TCP stack should make sure it owns skbs before mangling them.
We had various crashes using bnx2x, and it turned out gso_size
was cleared right before bnx2x driver was populating TC descriptor
of the _previous_ packet send. TCP stack can sometime retransmit
packets that are still in Qdisc.
Of course we could make bnx2x driver more robust (using
ACCESS_ONCE(shinfo->gso_size) for example), but the bug is TCP stack.
We have identified two points where skb_unclone() was needed.
This patch adds a WARN_ON_ONCE() to warn us if we missed another
fix of this kind.
Kudos to Neal for finding the root cause of this bug. Its visible
using small MSS.
Signed-off-by: Eric Dumazet
Signed-off-by: Neal Cardwell
Cc: Yuchung Cheng
Signed-off-by: David S. Miller
Signed-off-by: Kamal Mostafa
---
net/ipv4/tcp_output.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c
index acda728..0eaef9a 100644
--- a/net/ipv4/tcp_output.c
+++ b/net/ipv4/tcp_output.c
@@ -1134,6 +1134,9 @@ static void tcp_queue_skb(struct sock *sk, struct sk_buff
*skb)
static void tcp_set_skb_tso_segs(const struct sock *sk, struct sk_buff *skb,
unsigned int mss_now)
{
+ /* Make sure we own this skb before messing gso_size/gso_segs */
+ WARN_ON_ONCE(skb_cloned(skb));
+
if (skb->len <= mss_now || !sk_can_gso(sk) ||
skb->ip_summed == CHECKSUM_NONE) {
/* Avoid the costly divide in the normal
@@ -1215,9 +1218,7 @@ int tcp_fragment(struct sock *sk, struct sk_buff *skb,
u32 len,
if (nsize < 0)
nsize = 0;
- if (skb_cloned(skb) &&
- skb_is_nonlinear(skb) &&
- pskb_expand_head(skb, 0, 0, GFP_ATOMIC))
+ if (skb_unclone(skb, GFP_ATOMIC))
return -ENOMEM;
/* Get a new skb... force flag on. */
@@ -2368,6 +2369,8 @@ int __tcp_retransmit_skb(struct sock *sk, struct sk_buff
*skb)
int oldpcount = tcp_skb_pcount(skb);
if (unlikely(oldpcount > 1)) {
+ if (skb_unclone(skb, GFP_ATOMIC))
+ return -ENOMEM;
tcp_init_tso_segs(sk, skb, cur_mss);
tcp_adjust_pcount(sk, skb, oldpcount -
tcp_skb_pcount(skb));
}
--
1.8.1.2
--
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/
[PATCH 3.8 05/91] vxlan: fix ip_select_ident skb parameter
3.8.13.13 -stable review patch. If anyone has any objections, please let me
know.
--
From: Kamal Mostafa
[3.8-stable only] Fix a call to ip_select_ident() that I missed in commit
1a3365ee55bc5b7e9a752e3a535fd983714d8db2, which is the 3.8 backport
of commit 703133de331a7a7df47f31fb9de51dc6f68a9de8 upstream.
Cc: Ansis Atteka
Cc: David S. Miller
Signed-off-by: Kamal Mostafa
---
drivers/net/vxlan.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/vxlan.c b/drivers/net/vxlan.c
index 9b2cc0c..cb6f529 100644
--- a/drivers/net/vxlan.c
+++ b/drivers/net/vxlan.c
@@ -977,7 +977,7 @@ static netdev_tx_t vxlan_xmit(struct sk_buff *skb, struct
net_device *dev)
/* See iptunnel_xmit() */
if (skb->ip_summed != CHECKSUM_PARTIAL)
skb->ip_summed = CHECKSUM_NONE;
- ip_select_ident(iph, >dst, NULL);
+ ip_select_ident(skb, >dst, NULL);
err = ip_local_out(skb);
if (likely(net_xmit_eval(err) == 0)) {
--
1.8.1.2
--
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/
[PATCH 3.8 02/91] ACPICA: DeRefOf operator: Update to fully resolve FieldUnit and BufferField refs.
3.8.13.13 -stable review patch. If anyone has any objections, please let me
know.
--
From: Bob Moore
commit 63660e05ec719613b518547b40a1c501c10f0bc4 upstream.
Previously, references to these objects were resolved only to the actual
FieldUnit or BufferField object. The correct behavior is to resolve these
references to an actual value.
The problem is that DerefOf did not resolve these objects to actual
values. An "Integer" object is simple, return the value. But a field in
an operation region will require a read operation. For a BufferField, the
appropriate data must be extracted from the parent buffer.
NOTE: It appears that this issues is present in Windows7 but not
Windows8.
Signed-off-by: Bob Moore
Signed-off-by: Lv Zheng
Signed-off-by: Rafael J. Wysocki
Signed-off-by: Kamal Mostafa
---
drivers/acpi/acpica/exoparg1.c | 35 ---
1 file changed, 32 insertions(+), 3 deletions(-)
diff --git a/drivers/acpi/acpica/exoparg1.c b/drivers/acpi/acpica/exoparg1.c
index bbf01e9..1fa1ad6 100644
--- a/drivers/acpi/acpica/exoparg1.c
+++ b/drivers/acpi/acpica/exoparg1.c
@@ -997,11 +997,40 @@ acpi_status acpi_ex_opcode_1A_0T_1R(struct
acpi_walk_state *walk_state)
acpi_namespace_node
*)
return_desc);
- }
+ if (!return_desc) {
+ break;
+ }
+
+ /*
+* June 2013:
+* buffer_fields/field_units require
additional resolution
+*/
+ switch (return_desc->common.type) {
+ case ACPI_TYPE_BUFFER_FIELD:
+ case ACPI_TYPE_LOCAL_REGION_FIELD:
+ case ACPI_TYPE_LOCAL_BANK_FIELD:
+ case ACPI_TYPE_LOCAL_INDEX_FIELD:
+
+ status =
+ acpi_ex_read_data_from_field
+ (walk_state, return_desc,
+_desc);
+ if (ACPI_FAILURE(status)) {
+ goto cleanup;
+ }
- /* Add another reference to the object! */
+ return_desc = temp_desc;
+ break;
- acpi_ut_add_reference(return_desc);
+ default:
+
+ /* Add another reference to the
object */
+
+ acpi_ut_add_reference
+ (return_desc);
+ break;
+ }
+ }
break;
default:
--
1.8.1.2
--
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/
[PATCH 3.8 16/91] net: mv643xx_eth: update statistics timer from timer context only
3.8.13.13 -stable review patch. If anyone has any objections, please let me
know.
--
From: Sebastian Hesselbarth
[ Upstream commit 041b4ddb84989f06ff1df0ca869b950f1ee3cb1c ]
Each port driver installs a periodic timer to update port statistics
by calling mib_counters_update. As mib_counters_update is also called
from non-timer context, we should not reschedule the timer there but
rather move it to timer-only context.
Signed-off-by: Sebastian Hesselbarth
Acked-by: Jason Cooper
Signed-off-by: David S. Miller
Signed-off-by: Kamal Mostafa
---
drivers/net/ethernet/marvell/mv643xx_eth.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/marvell/mv643xx_eth.c
b/drivers/net/ethernet/marvell/mv643xx_eth.c
index 84c1326..6d89717 100644
--- a/drivers/net/ethernet/marvell/mv643xx_eth.c
+++ b/drivers/net/ethernet/marvell/mv643xx_eth.c
@@ -1273,15 +1273,13 @@ static void mib_counters_update(struct
mv643xx_eth_private *mp)
p->rx_discard += rdlp(mp, RX_DISCARD_FRAME_CNT);
p->rx_overrun += rdlp(mp, RX_OVERRUN_FRAME_CNT);
spin_unlock_bh(>mib_counters_lock);
-
- mod_timer(>mib_counters_timer, jiffies + 30 * HZ);
}
static void mib_counters_timer_wrapper(unsigned long _mp)
{
struct mv643xx_eth_private *mp = (void *)_mp;
-
mib_counters_update(mp);
+ mod_timer(>mib_counters_timer, jiffies + 30 * HZ);
}
--
1.8.1.2
--
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/
[PATCH 3.8 18/91] net: heap overflow in __audit_sockaddr()
3.8.13.13 -stable review patch. If anyone has any objections, please let me
know.
--
From: Dan Carpenter
[ Upstream commit 1661bf364ae9c506bc8795fef70d1532931be1e8 ]
We need to cap ->msg_namelen or it leads to a buffer overflow when we
to the memcpy() in __audit_sockaddr(). It requires CAP_AUDIT_CONTROL to
exploit this bug.
The call tree is:
___sys_recvmsg()
move_addr_to_user()
audit_sockaddr()
__audit_sockaddr()
Reported-by: Jüri Aedla
Signed-off-by: Dan Carpenter
Signed-off-by: David S. Miller
Signed-off-by: Kamal Mostafa
---
net/compat.c | 2 ++
net/socket.c | 24
2 files changed, 22 insertions(+), 4 deletions(-)
diff --git a/net/compat.c b/net/compat.c
index f0a1ba6..8903258 100644
--- a/net/compat.c
+++ b/net/compat.c
@@ -71,6 +71,8 @@ int get_compat_msghdr(struct msghdr *kmsg, struct
compat_msghdr __user *umsg)
__get_user(kmsg->msg_controllen, >msg_controllen) ||
__get_user(kmsg->msg_flags, >msg_flags))
return -EFAULT;
+ if (kmsg->msg_namelen > sizeof(struct sockaddr_storage))
+ return -EINVAL;
kmsg->msg_name = compat_ptr(tmp1);
kmsg->msg_iov = compat_ptr(tmp2);
kmsg->msg_control = compat_ptr(tmp3);
diff --git a/net/socket.c b/net/socket.c
index a61db06..809e941 100644
--- a/net/socket.c
+++ b/net/socket.c
@@ -1980,6 +1980,16 @@ struct used_address {
unsigned int name_len;
};
+static int copy_msghdr_from_user(struct msghdr *kmsg,
+struct msghdr __user *umsg)
+{
+ if (copy_from_user(kmsg, umsg, sizeof(struct msghdr)))
+ return -EFAULT;
+ if (kmsg->msg_namelen > sizeof(struct sockaddr_storage))
+ return -EINVAL;
+ return 0;
+}
+
static int ___sys_sendmsg(struct socket *sock, struct msghdr __user *msg,
struct msghdr *msg_sys, unsigned int flags,
struct used_address *used_address)
@@ -1998,8 +2008,11 @@ static int ___sys_sendmsg(struct socket *sock, struct
msghdr __user *msg,
if (MSG_CMSG_COMPAT & flags) {
if (get_compat_msghdr(msg_sys, msg_compat))
return -EFAULT;
- } else if (copy_from_user(msg_sys, msg, sizeof(struct msghdr)))
- return -EFAULT;
+ } else {
+ err = copy_msghdr_from_user(msg_sys, msg);
+ if (err)
+ return err;
+ }
if (msg_sys->msg_iovlen > UIO_FASTIOV) {
err = -EMSGSIZE;
@@ -2207,8 +2220,11 @@ static int ___sys_recvmsg(struct socket *sock, struct
msghdr __user *msg,
if (MSG_CMSG_COMPAT & flags) {
if (get_compat_msghdr(msg_sys, msg_compat))
return -EFAULT;
- } else if (copy_from_user(msg_sys, msg, sizeof(struct msghdr)))
- return -EFAULT;
+ } else {
+ err = copy_msghdr_from_user(msg_sys, msg);
+ if (err)
+ return err;
+ }
if (msg_sys->msg_iovlen > UIO_FASTIOV) {
err = -EMSGSIZE;
--
1.8.1.2
--
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/
[PATCH 3.8 19/91] proc connector: fix info leaks
3.8.13.13 -stable review patch. If anyone has any objections, please let me know. -- From: Mathias Krause [ Upstream commit e727ca82e0e9616ab4844301e6bae60ca7327682 ] Initialize event_data for all possible message types to prevent leaking kernel stack contents to userland (up to 20 bytes). Also set the flags member of the connector message to 0 to prevent leaking two more stack bytes this way. Signed-off-by: Mathias Krause Signed-off-by: David S. Miller [ kamal: backport to 3.8 (context) ] Signed-off-by: Kamal Mostafa --- drivers/connector/cn_proc.c | 17 + 1 file changed, 17 insertions(+) diff --git a/drivers/connector/cn_proc.c b/drivers/connector/cn_proc.c index 1110478..1b1d255 100644 --- a/drivers/connector/cn_proc.c +++ b/drivers/connector/cn_proc.c @@ -65,6 +65,7 @@ void proc_fork_connector(struct task_struct *task) msg = (struct cn_msg *)buffer; ev = (struct proc_event *)msg->data; + memset(>event_data, 0, sizeof(ev->event_data)); get_seq(>seq, >cpu); ktime_get_ts(); /* get high res monotonic timestamp */ put_unaligned(timespec_to_ns(), (__u64 *)>timestamp_ns); @@ -80,6 +81,7 @@ void proc_fork_connector(struct task_struct *task) memcpy(>id, _proc_event_id, sizeof(msg->id)); msg->ack = 0; /* not used */ msg->len = sizeof(*ev); + msg->flags = 0; /* not used */ /* If cn_netlink_send() failed, the data is not sent */ cn_netlink_send(msg, CN_IDX_PROC, GFP_KERNEL); } @@ -96,6 +98,7 @@ void proc_exec_connector(struct task_struct *task) msg = (struct cn_msg *)buffer; ev = (struct proc_event *)msg->data; + memset(>event_data, 0, sizeof(ev->event_data)); get_seq(>seq, >cpu); ktime_get_ts(); /* get high res monotonic timestamp */ put_unaligned(timespec_to_ns(), (__u64 *)>timestamp_ns); @@ -106,6 +109,7 @@ void proc_exec_connector(struct task_struct *task) memcpy(>id, _proc_event_id, sizeof(msg->id)); msg->ack = 0; /* not used */ msg->len = sizeof(*ev); + msg->flags = 0; /* not used */ cn_netlink_send(msg, CN_IDX_PROC, GFP_KERNEL); } @@ -122,6 +126,7 @@ void proc_id_connector(struct task_struct *task, int which_id) msg = (struct cn_msg *)buffer; ev = (struct proc_event *)msg->data; + memset(>event_data, 0, sizeof(ev->event_data)); ev->what = which_id; ev->event_data.id.process_pid = task->pid; ev->event_data.id.process_tgid = task->tgid; @@ -145,6 +150,7 @@ void proc_id_connector(struct task_struct *task, int which_id) memcpy(>id, _proc_event_id, sizeof(msg->id)); msg->ack = 0; /* not used */ msg->len = sizeof(*ev); + msg->flags = 0; /* not used */ cn_netlink_send(msg, CN_IDX_PROC, GFP_KERNEL); } @@ -160,6 +166,7 @@ void proc_sid_connector(struct task_struct *task) msg = (struct cn_msg *)buffer; ev = (struct proc_event *)msg->data; + memset(>event_data, 0, sizeof(ev->event_data)); get_seq(>seq, >cpu); ktime_get_ts(); /* get high res monotonic timestamp */ put_unaligned(timespec_to_ns(), (__u64 *)>timestamp_ns); @@ -170,6 +177,7 @@ void proc_sid_connector(struct task_struct *task) memcpy(>id, _proc_event_id, sizeof(msg->id)); msg->ack = 0; /* not used */ msg->len = sizeof(*ev); + msg->flags = 0; /* not used */ cn_netlink_send(msg, CN_IDX_PROC, GFP_KERNEL); } @@ -185,6 +193,7 @@ void proc_ptrace_connector(struct task_struct *task, int ptrace_id) msg = (struct cn_msg *)buffer; ev = (struct proc_event *)msg->data; + memset(>event_data, 0, sizeof(ev->event_data)); get_seq(>seq, >cpu); ktime_get_ts(); /* get high res monotonic timestamp */ put_unaligned(timespec_to_ns(), (__u64 *)>timestamp_ns); @@ -203,6 +212,7 @@ void proc_ptrace_connector(struct task_struct *task, int ptrace_id) memcpy(>id, _proc_event_id, sizeof(msg->id)); msg->ack = 0; /* not used */ msg->len = sizeof(*ev); + msg->flags = 0; /* not used */ cn_netlink_send(msg, CN_IDX_PROC, GFP_KERNEL); } @@ -218,6 +228,7 @@ void proc_comm_connector(struct task_struct *task) msg = (struct cn_msg *)buffer; ev = (struct proc_event *)msg->data; + memset(>event_data, 0, sizeof(ev->event_data)); get_seq(>seq, >cpu); ktime_get_ts(); /* get high res monotonic timestamp */ put_unaligned(timespec_to_ns(), (__u64 *)>timestamp_ns); @@ -229,6 +240,7 @@ void proc_comm_connector(struct task_struct *task) memcpy(>id, _proc_event_id, sizeof(msg->id)); msg->ack = 0; /* not used */ msg->len = sizeof(*ev); + msg->flags = 0; /* not used */ cn_netlink_send(msg, CN_IDX_PROC, GFP_KERNEL); } @@ -244,6 +256,7 @@ void proc_exit_connector(struct task_struct *task) msg = (struct cn_msg *)buffer;
[PATCH 3.8 06/91] tcp: TSO packets automatic sizing
3.8.13.13 -stable review patch. If anyone has any objections, please let me
know.
--
From: Eric Dumazet
commit 95bd09eb27507691520d39ee1044d6ad831c1168 upstream.
commit 02cf4ebd82ff0ac7254b88e466820a290ed8289a upstream.
commit 7eec4174ff29cd42f2acfae8112f51c228545d40 upstream.
After hearing many people over past years complaining against TSO being
bursty or even buggy, we are proud to present automatic sizing of TSO
packets.
One part of the problem is that tcp_tso_should_defer() uses an heuristic
relying on upcoming ACKS instead of a timer, but more generally, having
big TSO packets makes little sense for low rates, as it tends to create
micro bursts on the network, and general consensus is to reduce the
buffering amount.
This patch introduces a per socket sk_pacing_rate, that approximates
the current sending rate, and allows us to size the TSO packets so
that we try to send one packet every ms.
This field could be set by other transports.
Patch has no impact for high speed flows, where having large TSO packets
makes sense to reach line rate.
For other flows, this helps better packet scheduling and ACK clocking.
This patch increases performance of TCP flows in lossy environments.
A new sysctl (tcp_min_tso_segs) is added, to specify the
minimal size of a TSO packet (default being 2).
A follow-up patch will provide a new packet scheduler (FQ), using
sk_pacing_rate as an input to perform optional per flow pacing.
This explains why we chose to set sk_pacing_rate to twice the current
rate, allowing 'slow start' ramp up.
sk_pacing_rate = 2 * cwnd * mss / srtt
v2: Neal Cardwell reported a suspect deferring of last two segments on
initial write of 10 MSS, I had to change tcp_tso_should_defer() to take
into account tp->xmit_size_goal_segs
Signed-off-by: Eric Dumazet
Cc: Neal Cardwell
Cc: Yuchung Cheng
Cc: Van Jacobson
Cc: Tom Herbert
Acked-by: Yuchung Cheng
Acked-by: Neal Cardwell
Signed-off-by: David S. Miller
[ kamal: backport to 3.8 (context) ]
Signed-off-by: Kamal Mostafa
---
Documentation/networking/ip-sysctl.txt | 9 +
include/net/sock.h | 2 ++
include/net/tcp.h | 1 +
net/core/sock.c| 1 +
net/ipv4/sysctl_net_ipv4.c | 10 ++
net/ipv4/tcp.c | 28 ++-
net/ipv4/tcp_input.c | 35 +-
net/ipv4/tcp_output.c | 2 +-
8 files changed, 81 insertions(+), 7 deletions(-)
diff --git a/Documentation/networking/ip-sysctl.txt
b/Documentation/networking/ip-sysctl.txt
index dbca661..62b9a61 100644
--- a/Documentation/networking/ip-sysctl.txt
+++ b/Documentation/networking/ip-sysctl.txt
@@ -510,6 +510,15 @@ tcp_syn_retries - INTEGER
tcp_timestamps - BOOLEAN
Enable timestamps as defined in RFC1323.
+tcp_min_tso_segs - INTEGER
+ Minimal number of segments per TSO frame.
+ Since linux-3.12, TCP does an automatic sizing of TSO frames,
+ depending on flow rate, instead of filling 64Kbytes packets.
+ For specific usages, it's possible to force TCP to build big
+ TSO frames. Note that TCP stack might split too big TSO packets
+ if available window is too small.
+ Default: 2
+
tcp_tso_win_divisor - INTEGER
This allows control over what percentage of the congestion window
can be consumed by a single TSO frame.
diff --git a/include/net/sock.h b/include/net/sock.h
index 873abca..94871cc 100644
--- a/include/net/sock.h
+++ b/include/net/sock.h
@@ -228,6 +228,7 @@ struct cg_proto;
*@sk_wmem_queued: persistent queue size
*@sk_forward_alloc: space allocated forward
*@sk_allocation: allocation mode
+ *@sk_pacing_rate: Pacing rate (if supported by transport/packet
scheduler)
*@sk_sndbuf: size of send buffer in bytes
*@sk_flags: %SO_LINGER (l_onoff), %SO_BROADCAST, %SO_KEEPALIVE,
* %SO_OOBINLINE settings, %SO_TIMESTAMPING settings
@@ -352,6 +353,7 @@ struct sock {
kmemcheck_bitfield_end(flags);
int sk_wmem_queued;
gfp_t sk_allocation;
+ u32 sk_pacing_rate; /* bytes per second */
netdev_features_t sk_route_caps;
netdev_features_t sk_route_nocaps;
int sk_gso_type;
diff --git a/include/net/tcp.h b/include/net/tcp.h
index 4da2167..45f3368 100644
--- a/include/net/tcp.h
+++ b/include/net/tcp.h
@@ -292,6 +292,7 @@ extern int sysctl_tcp_thin_dupack;
extern int sysctl_tcp_early_retrans;
extern int sysctl_tcp_limit_output_bytes;
extern int sysctl_tcp_challenge_ack_limit;
+extern int sysctl_tcp_min_tso_segs;
extern atomic_long_t tcp_memory_allocated;
extern struct percpu_counter tcp_sockets_allocated;
diff --git a/net/core/sock.c b/net/core/sock.c
index b8af814..fc0d751 100644
--- a/net/core/sock.c
+++ b/net/core/sock.c
@@
[PATCH 3.8 83/91] uml: check length in exitcode_proc_write()
3.8.13.13 -stable review patch. If anyone has any objections, please let me
know.
--
From: Dan Carpenter
commit 201f99f170df14ba52ea4c52847779042b7a623b upstream.
We don't cap the size of buffer from the user so we could write past the
end of the array here. Only root can write to this file.
Reported-by: Nico Golde
Reported-by: Fabian Yamaguchi
Signed-off-by: Dan Carpenter
Signed-off-by: Linus Torvalds
Signed-off-by: Kamal Mostafa
---
arch/um/kernel/exitcode.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/arch/um/kernel/exitcode.c b/arch/um/kernel/exitcode.c
index 829df49..41ebbfe 100644
--- a/arch/um/kernel/exitcode.c
+++ b/arch/um/kernel/exitcode.c
@@ -40,9 +40,11 @@ static ssize_t exitcode_proc_write(struct file *file,
const char __user *buffer, size_t count, loff_t *pos)
{
char *end, buf[sizeof("n\0")];
+ size_t size;
int tmp;
- if (copy_from_user(buf, buffer, count))
+ size = min(count, sizeof(buf));
+ if (copy_from_user(buf, buffer, size))
return -EFAULT;
tmp = simple_strtol(buf, , 0);
--
1.8.1.2
--
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/
