[PATCH] arch/score/kernel/process.c: Remove useless varialbes 'ti' and 'regs'
They are useless, so remove them, the related warning (with
allmodconfig under score):
CC arch/score/kernel/process.o
arch/score/kernel/process.c: In function 'copy_thread':
arch/score/kernel/process.c:76:18: warning: unused variable 'regs'
[-Wunused-variable]
struct pt_regs *regs = current_pt_regs();
^
arch/score/kernel/process.c:74:22: warning: unused variable 'ti'
[-Wunused-variable]
struct thread_info *ti = task_thread_info(p);
^
Signed-off-by: Chen Gang
---
arch/score/kernel/process.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/arch/score/kernel/process.c b/arch/score/kernel/process.c
index a1519ad3..50bf1b0 100644
--- a/arch/score/kernel/process.c
+++ b/arch/score/kernel/process.c
@@ -71,9 +71,7 @@ void flush_thread(void) {}
int copy_thread(unsigned long clone_flags, unsigned long usp,
unsigned long arg, struct task_struct *p)
{
- struct thread_info *ti = task_thread_info(p);
struct pt_regs *childregs = task_pt_regs(p);
- struct pt_regs *regs = current_pt_regs();
p->thread.reg0 = (unsigned long) childregs;
if (unlikely(p->flags & PF_KTHREAD)) {
--
1.7.11.7
--
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 02/16] sched: Introduce CONFIG_SCHED_ENERGY
On Fri, May 23, 2014 at 07:16:29PM +0100, Morten Rasmussen wrote: > The Energy-aware scheduler implementation is guarded by > CONFIG_SCHED_ENERGY. > > Signed-off-by: Dietmar Eggemann > Signed-off-by: Morten Rasmussen > --- > arch/arm/Kconfig |5 + > 1 file changed, 5 insertions(+) > > diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig > index ab438cb..bfc3a85 100644 > --- a/arch/arm/Kconfig > +++ b/arch/arm/Kconfig Is this going to be duplicate for each architecture enabling this? Why not make a kernel/Kconfig.energy and link to that from those architectures using it? > @@ -1926,6 +1926,11 @@ config XEN > help > Say Y if you want to run Linux in a Virtual Machine on Xen on ARM. > > +config SCHED_ENERGY > + bool "Energy-aware scheduling (EXPERIMENTAL)" > + help > + Highly experimental energy aware task scheduling. > + how about adding *slightly* more info here? :) (yes, yes, I know it's an RFC) """ Highly experimental energy aware task scheduling. This will allow the kernel to keep track of energy required for different capacity levels for a given CPU. That way, the scheduler can make more informed decisions as to where a newly woken task should be placed. Heterogenous platform will benefit the most from this option. Enabling this will add a significant overhead for a task-switch. If unsure, say N here. """ > endmenu > > menu "Boot options" > -- > 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/ -- Henrik Austad -- 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] Input - synaptics: fix resolution for manually provided min/max
On Tue, Jun 03, 2014 at 01:59:35PM -0400, Benjamin Tissoires wrote:
> commit 421e08c41fda fixed the reported min/max for the X and Y axis,
> but unfortunately, it broke the resolution of those same axis.
>
> On the t540p, the resolution is the same regarding X and Y. It is not
> a problem for xf86-input-synaptics because this driver is only interested
> in the ratio between X and Y.
> Unfortunately, xf86-input-cmt uses directly the resolution, and having a
> null resolution leads to some divide by 0 errors, which are translated by
> -infinity in the resulting coordinates.
>
> Reported-by: Peter Hutterer
> Signed-off-by: Benjamin Tissoires
> Cc: sta...@vger.kernel.org
> ---
>
> Hi Dmitry,
>
> in the original submission, the test for the quirk was at the end of the
> synaptics_resolution() function. However, there was a mixmatch with the config
> in this original submission and you had to change the patch slightly.
> Unfortunately, this change created this bug which was hard to notice, which is
> why it comes that late in the cycle (and also because we are trying to find
> out
> if xf86-input-cmt could replace xf86-input-synaptics).
Hmm, I guess we are not going to quirk very old hardware so the change
is fine, applied.
>
> Anyway, as mentioned in the commit message, this will not harm a big majority
> of users, because only those using ChromeOS will be impacted (not sure they
> have the Lenovo 40 series in their kernel either).
>
> Again, it's your call to leave or not the stable@ tag, but given that all we
> put regarding those crappy devices are tagged as such, I put it there also.
>
> Cheers,
> Benjamin
>
> drivers/input/mouse/synaptics.c | 18 +-
> 1 file changed, 9 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/input/mouse/synaptics.c b/drivers/input/mouse/synaptics.c
> index c5ec703..9cff1f8 100644
> --- a/drivers/input/mouse/synaptics.c
> +++ b/drivers/input/mouse/synaptics.c
> @@ -347,15 +347,6 @@ static int synaptics_resolution(struct psmouse *psmouse)
> unsigned char resp[3];
> int i;
>
> - for (i = 0; min_max_pnpid_table[i].pnp_ids; i++)
> - if (matches_pnp_id(psmouse, min_max_pnpid_table[i].pnp_ids)) {
> - priv->x_min = min_max_pnpid_table[i].x_min;
> - priv->x_max = min_max_pnpid_table[i].x_max;
> - priv->y_min = min_max_pnpid_table[i].y_min;
> - priv->y_max = min_max_pnpid_table[i].y_max;
> - return 0;
> - }
> -
> if (SYN_ID_MAJOR(priv->identity) < 4)
> return 0;
>
> @@ -366,6 +357,15 @@ static int synaptics_resolution(struct psmouse *psmouse)
> }
> }
>
> + for (i = 0; min_max_pnpid_table[i].pnp_ids; i++)
> + if (matches_pnp_id(psmouse, min_max_pnpid_table[i].pnp_ids)) {
> + priv->x_min = min_max_pnpid_table[i].x_min;
> + priv->x_max = min_max_pnpid_table[i].x_max;
> + priv->y_min = min_max_pnpid_table[i].y_min;
> + priv->y_max = min_max_pnpid_table[i].y_max;
> + return 0;
> + }
> +
> if (SYN_EXT_CAP_REQUESTS(priv->capabilities) >= 5 &&
> SYN_CAP_MAX_DIMENSIONS(priv->ext_cap_0c)) {
> if (synaptics_send_cmd(psmouse, SYN_QUE_EXT_MAX_COORDS, resp)) {
> --
> 1.9.0
>
--
Dmitry
--
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: Crypto Update for 3.16
On Sat, Jun 07, 2014 at 07:56:53PM -0700, Linus Torvalds wrote: > > I'm assuming that the delete was actually incorrect, and should have > been a move, because it looks like the bfin_crc.c file won't compile > without it. So I've re-instated that file. Yes that would be my assumption as well. Sonic/Steven, could you please double-check the current tree to see whether it's in the right state? Thanks, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- 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: What can change in ways Linux handles memory when all memory >4G is disabled? (x86)
[+cc linux-pci, linux-pm]
On Fri, Jun 6, 2014 at 6:06 PM, Nikolay Amiantov wrote:
> Hello all,
>
> I'm trying to resolve a cryptic problem with Lenovo T440p (and with
> Dell XPS 15z, as it appears) and nvidia in my spare time. You can read
> more at [1]. Basically: when the user disables and then re-enables
> nvidia card (via ACPI, bbswitch or nouveau's dynpm) on new BIOS
> versions, something becomes really wrong. User sees fs, usb devices
> and network controllers faults of all kinds, system renders unusable
> and user can observe filesystem corruption after reboot. Nvidia
> drivers (or nouveau, or i915) can not even be loaded -- all that is
> needed to trigger a bug is to call several ACPI methods to disable and
> re-enable the card (e.g., via acpi-call module).
I don't know what ACPI methods you're calling, but (as I'm sure you
know) it's not guaranteed to be safe to call random methods because
they can make arbitrary changes to the system.
> I've attached a debugger to Windows kernel to catch ACPI calls for
> disabling and re-enabling NVIDIA card -- they don't really differ with
> what bbswitch and others use. Furthermore, the difference between ACPI
> DSDT tables in 1.14 (last good) and 1.16 (first broken) BIOSes are
> minimal, and loading table from 1.14 into system running 1.16 does not
> help. But -- all those devices are using memory I/O, so my current
> theory is that memory is somehow corrupted. There are also some
> changes in lspci output for nvidia [2].
I skimmed through [1], but I'm not sure I understood everything.
Here's what I gleaned; please correct any mistaken impressions:
1) Suspend/resume is mentioned in [1], but the problem occurs even
without any suspend/resume.
2) The problem happens on a completely stock untainted upstream
kernel even with no nvidia, nouveau, or i915 drivers loaded.
3) Disabling the nvidia device (02:00.0) by executing an ACPI method
works fine, and the system works fine after the nvidia device is
disabled.
4) This ACPI method puts the nvidia device in D3cold state.
5) Problems start when enabling the nvidia device by executing
another ACPI method.
In the D3cold state, the PCI device is entirely powered off. After it
is re-enabled, e.g., by the ACPI method in 5) above, the device needs
to be completely re-initialized. Since you're executing the ACPI
method "by hand," outside the context of the Linux power management
system, there's nothing to re-initialize the device.
This by itself shouldn't be a problem; the device should power up with
its BARs zeroed out and disabled, bus mastering disabled, etc.
BUT the kernel doesn't know about these power changes you're making,
so some things will be broken. For example, while the nvidia device
is in D3cold, lspci will return garbage for that device. After it
returns to D0, lspci should work again, but now the state of the
device (BAR assignments, interrupts, etc.) is different from what
Linux thinks it is.
If a driver does anything with the device after it returns to D0, I
think things will break, because the PCI core already knows what
resources are assigned to the device, but the device forgot them when
it was powered off. So the PCI core would happily enable the device
but it will respond at the wrong addresses.
But I think you said problems happen even without any driver for the
nvidia device, so there's probably more going on. This is a video
device, and I wouldn't be surprised if there's some legacy VGA
behavior that doesn't follow the usual PCI rules.
Can you:
1) Collect complete "lspci -vvxxx" output from the whole system, with
the nvidia card enabled.
2) Disable nvidia card.
3) Collect complete dmesg log.
4) Try "lspci -s02:00.0". I expect this to show garbage if the nvidia
card is powered off.
5) Enable nvidia card.
6) Try "lspci -vvxxx" again. You mentioned changes to devices other
than nvidia, which sounds suspicious.
7) Collect dmesg log again. I don't expect changes here, because the
kernel probably doesn't notice the power transition.
Bjorn
> I've played a bit with this theory in mind and found a very
> interesting thing -- when I reserve all memory upper than 4G with
> "memmap" kernel option ("memmap=99G$0x1"), everything works!
> Also, I've written a small utility that fills memory with zeros using
> /dev/mem and then checks it. I've checked reserved memory with it, and
> it appears that no memory in that region is corrupted at all, which is
> even more strange. I suspect that somehow when nvidia is enabled
> I/O-mapped memory regions are corrupted, and only when upper memory is
> not enabled. Also, memory map does not differ apart from missing last
> big chunk of memory with and without "memmap", and with Windows, too.
> If I enable even small chunk of "upper" memory (e.g.,
> 0x27000-0x28000), there are usual crashes.
>
> Long story short: I'm interested how memory management can differ when
> this "upper" memory regions are enabled?
>
> P.S.: This is my
[GET PULL] ext4 updates for 3.16
A fairly minor obvious merge fix will be required due to a conflicting
change to a comment made by a commit already in your tree:
- * Comments copied from block_write_full_page_endio:
++ * Comments copied from block_write_full_page:
coupled with a move of the code in question in the ext4 tree.
Thanks!!
- Ted
The following changes since commit 9ac03675010a69507c0a9d832d6a722e07d35cc6:
Merge tag 'ext4_for_linus_stable' of
git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4 (2014-04-20 20:43:47
-0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4.git
tags/ext4_for_linus
for you to fetch changes up to bd9db175dde14b606265e0d37e8319d96fe1a58f:
ext4: handle symlink properly with inline_data (2014-06-02 10:48:22 -0400)
Clean ups and miscellaneous bug fixes, in particular for the new
collapse_range and zero_range fallocate functions. In addition,
improve the scalability of adding and remove inodes from the orphan
list.
Andrey Tsyvarev (1):
ext4: do not destroy ext4_groupinfo_caches if ext4_mb_init() fails
Darrick J. Wong (3):
ext4: find the group descriptors on a 1k-block bigalloc,meta_bg filesystem
ext4: fix block bitmap initialization under sparse_super2
ext4: fix block bitmap validation when bigalloc, ^flex_bg
Dmitry Monakhov (1):
ext4: remove obsoleted check
Giedrius Rekasius (1):
ext4: remove unused local variable "stored" from ext4_readdir(...)
Jan Kara (3):
ext4: use sbi in ext4_orphan_{add|del}()
ext4: reduce contention on s_orphan_lock
ext4: fix zeroing of page during writeback
Lukas Czerner (4):
ext4: get rid of EXT4_MAP_UNINIT flag
ext4: rename uninitialized extents to unwritten
ext4: remove unnecessary double parentheses
ext4: use EXT_MAX_BLOCKS in ext4_es_can_be_merged()
Maurizio Lombardi (1):
ext4: fix wrong assert in ext4_mb_normalize_request()
Namjae Jeon (2):
ext4: fix data integrity sync in ordered mode
ext4: fix ZERO_RANGE test failure in data journalling
Stephen Hemminger (1):
ext4: make local functions static
Theodore Ts'o (5):
ext4: inline generic_file_aio_write() into ext4_file_write()
ext4: move ext4_file_dio_write() into ext4_file_write()
ext4: factor out common code in ext4_file_write()
ext4: fix locking for O_APPEND writes
ext4: add a new spinlock i_raw_lock to protect the ext4's raw inode
Zhang Zhen (1):
ext4: avoid unneeded lookup when xattr name is invalid
Zheng Liu (1):
ext4: handle symlink properly with inline_data
liang xie (1):
ext4: add missing BUFFER_TRACE before ext4_journal_get_write_access
fs/ext4/balloc.c| 66 --
fs/ext4/dir.c | 3 +-
fs/ext4/ext4.h | 59
fs/ext4/ext4_extents.h | 22 ++---
fs/ext4/ext4_jbd2.c | 7 +-
fs/ext4/ext4_jbd2.h | 4 -
fs/ext4/extents.c | 236
fs/ext4/extents_status.c| 10 +-
fs/ext4/file.c | 153 +++
fs/ext4/inline.c| 15 ++-
fs/ext4/inode.c | 90 ++
fs/ext4/mballoc.c | 8 +-
fs/ext4/migrate.c | 2 +-
fs/ext4/mmp.c | 4 +-
fs/ext4/move_extent.c | 39
fs/ext4/namei.c | 131 ---
fs/ext4/page-io.c | 32 ---
fs/ext4/resize.c| 13 +++
fs/ext4/super.c | 20 +++-
fs/ext4/xattr.c | 9 +-
include/linux/page-flags.h | 12 ++-
include/trace/events/ext4.h | 9 +-
mm/page-writeback.c | 11 ++-
23 files changed, 515 insertions(+), 440 deletions(-)
--
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: tracing: NULL ptr deref in ring_buffer_wait
On 05/08/2014 12:16 PM, Steven Rostedt wrote:
> On Thu, 08 May 2014 11:31:41 -0400
> Sasha Levin wrote:
>
>> On 05/05/2014 11:46 AM, Sasha Levin wrote:
>>> [ 3589.407670] vfs_read (fs/read_write.c:430)
>>> [ 3589.407670] SyS_read (fs/read_write.c:568 fs/read_write.c:560)
>>> [ 3589.407670] tracesys (arch/x86/kernel/entry_64.S:746)
>>> [ 3589.407670] Code: 85 cd 0c 00 00 48 c7 c1 5c e1 6d ac 48 c7 c2 af 89
>>> 6d ac 31 c0 be fa 0b 00 00 48 c7 c7 16 e1 6d ac e8 3c 68 f9 ff e9 a7 0c
>>> 00 00 <49> 81 7d 00 80 81 76 ae b8 00 00 00 00 44 0f 44 c0 eb 07 0f 1f
>>> [ 3589.407670] RIP __lock_acquire (kernel/locking/lockdep.c:3070
>>> (discriminator 1))
>>> [ 3589.407670] RSP
>>> [ 3589.407670] CR2: 01f0
>
> Is this easily reproducible?
>>> Nope, only saw it once.
>>
>> And a second time today, I guess I could put a debug patch and see if that
>> helps, if you had something in mind...
>>
>
> All I can think of is to try this:
>
> -- Steve
>
> diff --git a/kernel/trace/ring_buffer.c b/kernel/trace/ring_buffer.c
> index c634868..7cacbad 100644
> --- a/kernel/trace/ring_buffer.c
> +++ b/kernel/trace/ring_buffer.c
> @@ -558,6 +558,10 @@ void ring_buffer_wait(struct ring_buffer *buffer, int
> cpu)
> work = &buffer->irq_work;
> else {
> cpu_buffer = buffer->buffers[cpu];
> + if (unlikely(!cpu_buffer)) {
> + printk("null cpu buffer, %d\n", cpu);
> + BUG();
> + }
> work = &cpu_buffer->irq_work;
> }
>
>
Hi Steven,
Yup, it took me *that* long to reproduce it again, but I can confirm that that
BUG() gets hit (the printk shows cpu 30 like the BUG):
[ 2410.677199] kernel BUG at kernel/trace/ring_buffer.c:563!
[ 2410.679445] can: request_module (can-proto-4) failed.
[ 2410.680298] invalid opcode: [#1] PREEMPT SMP DEBUG_PAGEALLOC
[ 2410.680298] Dumping ftrace buffer:
[ 2410.680298](ftrace buffer empty)
[ 2410.680298] Modules linked in:
[ 2410.680298] CPU: 30 PID: 34851 Comm: trinity-c88 Not tainted
3.15.0-rc8-next-20140606-sasha-00021-ga9d3a0b-dirty #596
[ 2410.680298] task: 8802c866b000 ti: 8802c7724000 task.ti:
8802c7724000
[ 2410.680298] RIP: ring_buffer_wait (kernel/trace/ring_buffer.c:563)
[ 2410.680298] RSP: 0018:8802c7727de8 EFLAGS: 00010296
[ 2410.680298] RAX: 0013 RBX: 0024 RCX: 0006
[ 2410.680298] RDX: 0001 RSI: ad5030db RDI: aa1d8952
[ 2410.711484] RBP: 8802c7727e38 R08: R09:
[ 2410.711484] R10: 0001 R11: R12: 88003681e900
[ 2410.711484] R13: 88006ce7d100 R14: R15: 8800530090fc
[ 2410.721370] FS: 7f8c14bad700() GS:8806cae0()
knlGS:
[ 2410.721370] CS: 0010 DS: ES: CR0: 80050033
[ 2410.721370] CR2: 7f8c1144 CR3: 00029dd18000 CR4: 06a0
[ 2410.721370] DR0: 006d6000 DR1: 006d6000 DR2:
[ 2410.721370] DR3: DR6: 0ff0 DR7: 0600
[ 2410.721370] Stack:
[ 2410.721370] 880053008028 8802c866b000
aa1bb600
[ 2410.721370] 8802c7727e08 8802c7727e08 880053008000
880053008028
[ 2410.721370] 88006ce7d100 8802c866b000 8802c7727e48
aa24af8a
[ 2410.721370] Call Trace:
[ 2410.721370] ? bit_waitqueue (kernel/sched/wait.c:291)
[ 2410.721370] wait_on_pipe (kernel/trace/trace.c:1095)
[ 2410.721370] tracing_wait_pipe.isra.19 (kernel/trace/trace.c:4280)
[ 2410.721370] tracing_read_pipe (kernel/trace/trace.c:4326)
[ 2410.721370] vfs_read (fs/read_write.c:430)
[ 2410.721370] SyS_read (fs/read_write.c:568 fs/read_write.c:560)
[ 2410.721370] tracesys (arch/x86/kernel/entry_64.S:542)
[ 2410.721370] Code: ff ff 85 c0 75 5a eb 5d 66 90 48 8b 87 c8 00 00 00 48 63
d6 4c 8b 34 d0 4d 85 f6 75 15 48 c7 c7 6e 96 6f ae 31 c0 e8 7d 8f 2b 03 <0f> 0b
0f 1f 44 00 00 4d 8d ae d8 01 00 00 ba 01 00 00 00 48 8d
All code
0: ff (bad)
1: ff 85 c0 75 5a eb incl -0x14a58a40(%rbp)
7: 5d pop%rbp
8: 66 90 xchg %ax,%ax
a: 48 8b 87 c8 00 00 00mov0xc8(%rdi),%rax
11: 48 63 d6movslq %esi,%rdx
14: 4c 8b 34 d0 mov(%rax,%rdx,8),%r14
18: 4d 85 f6test %r14,%r14
1b: 75 15 jne0x32
1d: 48 c7 c7 6e 96 6f aemov$0xae6f966e,%rdi
24: 31 c0 xor%eax,%eax
26: e8 7d 8f 2b 03 callq 0x32b8fa8
2b:* 0f 0b ud2 <-- trapping instruction
2d: 0f 1f 44 00 00 nopl 0x0(%rax,%rax,1)
32: 4d 8d ae d8 01 00 00lea0x1d8(%r14),%r13
39: ba 01 00 00 00 mov$0x1,%edx
3e: 48 8d 00
Re: mm,x86: warning at arch/x86/mm/pat.c:781 untrack_pfn+0x65/0xb0()
On 04/11/2014 08:50 AM, Sasha Levin wrote: > Hi all, > > While fuzzing with trinity inside a KVM tools guest running the latest -next > kernel I've stumbled on the following: Ping? Still happening (rarely on -next): [ 5818.038245] WARNING: CPU: 4 PID: 22726 at arch/x86/mm/pat.c:781 untrack_pfn+0x65/0xb0() [ 5818.044203] Modules linked in: [ 5818.045172] CPU: 4 PID: 22726 Comm: trinity-c239 Tainted: GW 3.15.0-rc8-next-20140606-sasha-00021-ga9d3a0b-dirty #596 [ 5818.048317] 0009 8800024d3be8 9e50fe6b 0001 [ 5818.050516] 8800024d3c28 9b15f96c 8800024d3c38 [ 5818.052567] 88000203f400 8800024d3d68 8800024d3d68 [ 5818.053785] Call Trace: [ 5818.054483] dump_stack (lib/dump_stack.c:52) [ 5818.055586] warn_slowpath_common (kernel/panic.c:430) [ 5818.056763] warn_slowpath_null (kernel/panic.c:465) [ 5818.057789] untrack_pfn (arch/x86/mm/pat.c:781 (discriminator 3)) [ 5818.059412] unmap_single_vma (mm/memory.c:1327) [ 5818.061530] ? pagevec_lru_move_fn (include/linux/pagevec.h:44 mm/swap.c:435) [ 5818.063412] unmap_vmas (mm/memory.c:1377 (discriminator 1)) [ 5818.064610] unmap_region (mm/mmap.c:2363 (discriminator 3)) [ 5818.065453] ? validate_mm_rb (mm/mmap.c:404) [ 5818.066422] ? vma_rb_erase (mm/mmap.c:449 include/linux/rbtree_augmented.h:219 include/linux/rbtree_augmented.h:227 mm/mmap.c:488) [ 5818.067316] do_munmap (mm/mmap.c:3359 mm/mmap.c:2561) [ 5818.068126] move_vma (mm/mremap.c:313) [ 5818.069000] SyS_mremap (mm/mremap.c:446 mm/mremap.c:508 mm/mremap.c:477) [ 5818.069839] tracesys (arch/x86/kernel/entry_64.S:542) Thanks, Sasha -- 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] Per-user namespace process accounting
James Bottomley writes: > On Tue, 2014-06-03 at 10:54 -0700, Eric W. Biederman wrote: >> >> 90% of that work is already done. >> >> As long as we don't plan to support XFS (as it XFS likes to expose it's >> implementation details to userspace) it should be quite straight >> forward. > > Any implementation which doesn't support XFS is unviable from a distro > point of view. The whole reason we're fighting to get USER_NS enabled > in distros goes back to lack of XFS support (they basically refused to > turn it on until it wasn't a choice between XFS and USER_NS). If we put > them in a position where they choose a namespace feature or XFS, they'll > choose XFS. This isn't the same dicotomy. This is a simple case of not being able to use XFS mounted inside of a user namespace. Which does not cause any regression from the current use cases. The previous case was that XFS would not build at all. There were valid technical reasons but part of the reason the XFS conversion took so long was my social engineering the distro's to not enable the latest bling until there was a chance for the initial crop of bugs to be fixed. > XFS developers aren't unreasonable ... they'll help if we ask. I mean > it was them who eventually helped us get USER_NS turned on in the first > place. Fair enough. But XFS is not the place to start. For most filesystems the only really hard part is finding the handful of places where we actually need some form of error handling when on disk uids don't map to in core kuids. Which ultimately should wind up with maybe a 20 line patch for most filesystems. For XFS there are two large obstacles to overcome. - XFS journal replay does not work when the XFS filesystem is moved from a host with one combination of wordsize and endianness to a host with a different combination of wordsize and edianness. This makes XFS a bad choice of a filesystem to move between hosts in a sparse file. Every other filesystem in the kernel handles this better. - The XFS code base has a large the largest number of any ioctls of any filesystem in the linux kernel. This increases the amount of code that has to be converted. Combine that with the fact that the XFS developers chose to convert from kuids and kgids at the VFS<->FS layer instead of at the FS<->disk layer it becomes quite easy to miss changing code in an ioctl or a quota check by accident. Which all adds up to the fact that converting XFS to be mountable with a non 1-1 mapping of filesystem uids and system kuids is going to be a lot more than a simple 20 line patch. All of that said what becomes attractive about this approach is that it gets us to the point where people can ask questions about mounting normal filesystems unprivileged and the entire reason it won't be allowed are (no block devices to mount from) and concern that the filesystem error handling code is not sufficient to ward off evil users that create bad filesystem images. Eric -- 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: [Regression] commit 8a4aeec8d(libata/ahci: accommodate tag ordered controllers)
Hi Suman,
Could you forward the patches to me so that I can give a test?
I don't subscribe to linux-ide list.
Thanks,
--
Ming Lei
On Sat, Jun 7, 2014 at 5:33 AM, Suman Tripathi wrote:
> Hi ,
>
> I have just posted 3 patches "ata: Fix the dma state machine lockup for APM
> X-Gene SoC SATA controller" . This patch set has fixed this tag ordering
> issue.
> Tested in apm mustang board.
>
> Thanks,
> with regards,
> suman
>
>
> On Fri, Jun 6, 2014 at 11:41 AM, Ming Lei wrote:
>>
>> On Fri, Jun 6, 2014 at 10:57 AM, Dan Williams
>> wrote:
>> > On Fri, 2014-06-06 at 09:47 +0800, Ming Lei wrote:
>> >> Hi Tejun,
>> >>
>> >> On Thu, Jun 5, 2014 at 9:41 PM, Tejun Heo wrote:
>> >> > Hello,
>> >> >
>> >> > (cc'ing ahci_xgene folks)
>> >> >
>> >> > On Thu, Jun 05, 2014 at 09:24:04PM +0800, Ming Lei wrote:
>> >> >> On Thu, Jun 5, 2014 at 9:12 PM, Dan Williams
>> >> >> wrote:
>> >> >> > On Thu, Jun 5, 2014 at 1:53 AM, Ming Lei
>> >> >> > wrote:
>> >> >> >> Hi Dan and Tejun,
>> >> >> >>
>> >> >> >> Looks the commit 8a4aeec8d(libata/ahci: accommodate tag ordered
>> >> >> >> controllers) causes below sata failure[1] on APM AHCI controller.
>> >> >> >>
>> >> >> >> And the error does disappear after reverting the commit.
>> >> >> >
>> >> >> > Can you give some more details about the workload and the disk?
>> >> >> > What
>> >> >> > is the APM AHCI?
>> >> >>
>> >> >> The commit causes the APM arm64 based system not bootable, and not
>> >> >> special workload, just when mounting rootfs or reading init files.
>> >> >>
>> >> >> APM AHCI:
>> >> >> drivers/ata/ahci_xgene.c
>> >> >
>> >> > Urgh... so, the controller can't handle tags allocated in round-robin
>> >> > instead of lowest-first? Ming, can you please test with different
>> >> > controllers / disks / ssds and see whether the problem stays with the
>> >> > controller? Loc, can you guys please look into it so that at least
>> >> > the next revision hardware can fix the issue?
>> >>
>> >> The problem has been observed on several apm arm64 boards
>> >> with different disks.
>> >>
>> >> >
>> >> > Provided that the tag allocation itself isn't broken, which isn't too
>> >> > likely given the lack of bug reports on other controllers, we'll need
>> >> > to blacklist ahci_xgene somehow. Either disable NCQ support on it or
>> >> > implement an alternative lowest-first tag allocation for it. If this
>> >> > actually is the controller freaking out about tags allocated in a
>> >> > different order, I'm not sure how much confidence we can put in its
>> >> > NCQ implementation tho and it might be a better idea to simply plug
>> >> > NCQ support on it until we understand the details of the problem.
>> >> >
>> >> > So, something like the following? Ming, can you please verify
>> >> > whether
>> >> > the following makes the machine boot again?
>> >>
>> >> Looks the problem still persists after applying your patch of disabling
>> >> NCQ.
>> >
>> > How about the following patch?
>> >
>> > 8<-
>> > libata: allow xgene-ahci to opt-out of tag ordered submission
>> >
>> > From: Dan Williams
>> >
>> > Ming Lei reports:
>> > "Looks the commit 8a4aeec8d(libata/ahci: accommodate tag ordered
>> >controllers) causes below sata failure[1] on APM AHCI controller.
>> >
>> >And the error does disappear after reverting the commit.
>> >
>> > ata4.00: exception Emask 0x40 SAct 0xff00 SErr 0x800 action 0x6
>> > frozen
>> > ata4: SError: { HostInt }
>> > ata4.00: failed command: READ FPDMA QUEUED
>> > ata4.00: cmd 60/08:40:e0:a4:88/00:00:04:00:00/40 tag 8 ncq 4096 in
>> > res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x44
>> > (timeout)"
>> >
>> > Maintain tag ordered submission as the default, but allow xgene-ahci to
>> > continue with the old behavior.
>> >
>> > Reported-by: Ming Lei
>> > Signed-off-by: Dan Williams
>> > ---
>> > drivers/ata/ahci_xgene.c |1 +
>> > drivers/ata/libata-core.c | 42
>> > +++---
>> > drivers/ata/libata.h |2 ++
>> > include/linux/libata.h|1 +
>> > 4 files changed, 43 insertions(+), 3 deletions(-)
>> >
>> > diff --git a/drivers/ata/ahci_xgene.c b/drivers/ata/ahci_xgene.c
>> > index 77c89bf171f1..9be069f5f58a 100644
>> > --- a/drivers/ata/ahci_xgene.c
>> > +++ b/drivers/ata/ahci_xgene.c
>>
>> +#include "libata.h" is needed, otherwise build will fail.
>>
>> > @@ -300,6 +300,7 @@ static struct ata_port_operations xgene_ahci_ops = {
>> > .host_stop = xgene_ahci_host_stop,
>> > .hardreset = xgene_ahci_hardreset,
>> > .read_id = xgene_ahci_read_id,
>> > + .qc_new = ata_qc_new_fifo_order,
>> > };
>> >
>> > static const struct ata_port_info xgene_ahci_port_info = {
>> > diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
>> > index 943cc8b83e59..dd554354791f 100644
>> > --- a/drivers/ata/libata-core.c
>> > +++ b/drivers/ata/libata-core.c
>> > @@ -83,6 +83,7 @@ const struct ata_port_operations ata_base_port_
Re: [PATCH 3.14 186/228] PCI: Wrong register used to check pending traffic
On Wed, 2014-06-04 at 16:23 -0700, Greg Kroah-Hartman wrote:
> 3.14-stable review patch. If anyone has any objections, please let me know.
>
> --
>
> From: Gavin Shan
>
> commit d0b4cc4e32705ff00d90d32da7783c266c702c04 upstream.
>
> The incorrect register offset is passed to pci_wait_for_pending(), which is
> caused by commit 157e876ffe ("PCI: Add pci_wait_for_pending() (refactor
> pci_wait_for_pending_transaction())").
>
> Fixes: 157e876ffe ("PCI: Add pci_wait_for_pending() (refactor
> pci_wait_for_pending_transaction())
> Signed-off-by: Gavin Shan
> Signed-off-by: Bjorn Helgaas
> Acked-by: Alex Williamson
> Signed-off-by: Greg Kroah-Hartman
>
> ---
> drivers/pci/pci.c |5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> --- a/drivers/pci/pci.c
> +++ b/drivers/pci/pci.c
> @@ -3043,7 +3043,8 @@ int pci_wait_for_pending_transaction(str
> if (!pci_is_pcie(dev))
> return 1;
>
> - return pci_wait_for_pending(dev, PCI_EXP_DEVSTA, PCI_EXP_DEVSTA_TRPND);
> + return pci_wait_for_pending(dev, pci_pcie_cap(dev) + PCI_EXP_DEVSTA,
> + PCI_EXP_DEVSTA_TRPND);
> }
> EXPORT_SYMBOL(pci_wait_for_pending_transaction);
>
> @@ -3085,7 +3086,7 @@ static int pci_af_flr(struct pci_dev *de
> return 0;
>
> /* Wait for Transaction Pending bit clean */
> - if (pci_wait_for_pending(dev, PCI_AF_STATUS, PCI_AF_STATUS_TP))
> + if (pci_wait_for_pending(dev, pos + PCI_AF_STATUS, PCI_AF_STATUS_TP))
> goto clear;
>
> dev_err(&dev->dev, "transaction is not cleared; "
This still seems to be broken because pci_wait_for_pending() does
pci_read_config_word() but PCI_AF_STATUS is not word-aligned.
Ben.
--
Ben Hutchings
Never attribute to conspiracy what can adequately be explained by stupidity.
signature.asc
Description: This is a digitally signed message part
Re: Crypto Update for 3.16
On Wed, Jun 4, 2014 at 11:23 PM, Herbert Xu wrote:
>
> Here is the crypto update for 3.16:
There's something odd going on with bfin_crc.h.
You moved it in commit 52e6e543f2d8 ("crypto: bfin_crc - access crc
registers by readl and writel functions").
It got *deleted* by commit 3356c99ea392 ("bfin_crc: Move architecture
independant crc header file out of the blackfin folder") which claims
to just move things.
Both of those commits are by Sonic Zhang, just came to me through two
different trees (though your crypto tree, and through Steven Miao's
bfin tree).
I'm assuming that the delete was actually incorrect, and should have
been a move, because it looks like the bfin_crc.c file won't compile
without it. So I've re-instated that file.
But the state of the bfin tree seems to be crap. Somebody should take
a look at what happened here. My suspicion is that commit 3356c99ea392
was broken by Steven Miao trying to only touch files in arch/blackfin
or something.
Linus
--
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 1/1] cleanup: use bool as return type for rwsem_is_locked
On 06/07/2014 07:44 PM, Dave Chinner wrote:
> On Fri, Jun 06, 2014 at 07:39:30PM -0700, Joe Perches wrote:
>> On Fri, 2014-06-06 at 21:41 -0400, Pranith Kumar wrote:
>>> On 06/06/2014 08:59 PM, Pranith Kumar wrote:
On 06/06/2014 08:18 PM, Dave Chinner wrote:
> If you are going to change the return type to bool, then you should
> also remove the manual "!!" conversions to a boolean return and let
> the compiler do it in the most optimal way.
>> simpler still would be just removing the !! completely.
>> I presume in no case would it make an actual difference
>> in emitted code.
>>
>> ie:
>> return ip->i_lock.mr_writer;
>
> Yup, that's exactly what I meant. Casting to a bool type does all
> the work of squashing all non-zero values to 1...
>
change return type if xfs_isilocked() to bool to follow rwsem_is_locked()
Signed-off-by: Pranith Kumar
---
fs/xfs/xfs_inode.c | 8
fs/xfs/xfs_inode.h | 2 +-
2 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/fs/xfs/xfs_inode.c b/fs/xfs/xfs_inode.c
index a6115fe..c02ac49 100644
--- a/fs/xfs/xfs_inode.c
+++ b/fs/xfs/xfs_inode.c
@@ -285,25 +285,25 @@ xfs_ilock_demote(
}
#if defined(DEBUG) || defined(XFS_WARN)
-int
+bool
xfs_isilocked(
xfs_inode_t *ip,
uintlock_flags)
{
if (lock_flags & (XFS_ILOCK_EXCL|XFS_ILOCK_SHARED)) {
if (!(lock_flags & XFS_ILOCK_SHARED))
- return !!ip->i_lock.mr_writer;
+ return ip->i_lock.mr_writer;
return rwsem_is_locked(&ip->i_lock.mr_lock);
}
if (lock_flags & (XFS_IOLOCK_EXCL|XFS_IOLOCK_SHARED)) {
if (!(lock_flags & XFS_IOLOCK_SHARED))
- return !!ip->i_iolock.mr_writer;
+ return ip->i_iolock.mr_writer;
return rwsem_is_locked(&ip->i_iolock.mr_lock);
}
ASSERT(0);
- return 0;
+ return false;
}
#endif
diff --git a/fs/xfs/xfs_inode.h b/fs/xfs/xfs_inode.h
index f72bffa..efebed6 100644
--- a/fs/xfs/xfs_inode.h
+++ b/fs/xfs/xfs_inode.h
@@ -346,7 +346,7 @@ voidxfs_ilock(xfs_inode_t *, uint);
intxfs_ilock_nowait(xfs_inode_t *, uint);
void xfs_iunlock(xfs_inode_t *, uint);
void xfs_ilock_demote(xfs_inode_t *, uint);
-intxfs_isilocked(xfs_inode_t *, uint);
+bool xfs_isilocked(xfs_inode_t *, uint);
uint xfs_ilock_data_map_shared(struct xfs_inode *);
uint xfs_ilock_attr_map_shared(struct xfs_inode *);
intxfs_ialloc(struct xfs_trans *, xfs_inode_t *, umode_t,
--
1.9.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: Phantom ACL-related xattrs on 3.14.4 NFS client
Hi Trond & Christoph,
It's still broken, but in a different way.
The phantom attrs are gone, but the attr/acl interaction is still
uncertain.
I have tested vanilla 3.14.5 + this patch on x86_64.
Mount options are the same as last time (NFSv3).
This is what I see on the client:
nfsv3client% mkdir x
nfsv3client% cd x
nfsv3client% getfattr -m '.*' .
nfsv3client% getfacl .
# file: .
# owner: phil
# group: phil
user::rwx
group::rwx
other::r-x
OK so far: no more phantom attrs.
This is where things get dodgy:
nfsv3client% setfacl -m u:root:r .
nfsv3client% getfacl .
# file: .
# owner: phil
# group: phil
user::rwx
user:root:r--
group::rwx
mask::rwx
other::r-x
nfsv3client% getfattr -m '.*' .
[1]2123 segmentation fault getfattr -m '.*' .
% strace getfattr -m '.*' . 2>&1 | tail -n 20
fstat(3, {st_mode=S_IFREG|0644, st_size=26254, ...}) = 0
mmap(NULL, 26254, PROT_READ, MAP_SHARED, 3, 0) = 0x7f46a145
close(3)= 0
getrlimit(RLIMIT_NOFILE, {rlim_cur=1024, rlim_max=4*1024}) = 0
lstat(".", {st_mode=S_IFDIR|0775, st_size=4096, ...}) = 0
listxattr(".", NULL, 0) = 23
listxattr(".", "system.posix_acl_access", 256) = 23
brk(0) = 0x1138000
brk(0x1178000) = 0x1178000
brk(0) = 0x1178000
brk(0) = 0x1178000
brk(0x1159000) = 0x1159000
brk(0) = 0x1159000
mmap(NULL, 266240, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
0) = 0x7f46a140f000
brk(0) = 0x1159000
brk(0) = 0x1159000
brk(0x1139000) = 0x1139000
brk(0) = 0x1139000
--- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0x11586e8}
---
+++ killed by SIGSEGV +++
[1]2311 segmentation fault strace getfattr -m '.*' . 2>&1
|
2312 donetail -n 20
I have no idea get getfattr crashes right after the listxattr() syscall,
but it surely doesn't on the NFSv3 server nor with 3.13.
A quick check on the NFS server shows the the ACLs are correctly set:
nfsv3server% cd /path/to/x
nfsv3server% getfacl .
# file: .
# owner: phil
# group: phil
user::rwx
user:root:r--
group::rwx
mask::rwx
other::r-x
nfsv3server% getfattr -m '.*' .
# file: .
system.posix_acl_access
Back on the client, clearing the ACL confuses the client further:
nfsv3client% setfacl -b .
nfsv3client% getfacl .
# file: .
# owner: phil
# group: phil
user::rwx
group::rwx
other::r-x
nfsv3client% strace getfattr -m '.*' . 2>&1 | tail -n 20
fstat(3, {st_mode=S_IFREG|0644, st_size=26254, ...}) = 0
mmap(NULL, 26254, PROT_READ, MAP_SHARED, 3, 0) = 0x7fc7e3f9a000
close(3)= 0
getrlimit(RLIMIT_NOFILE, {rlim_cur=1024, rlim_max=4*1024}) = 0
lstat(".", {st_mode=S_IFDIR|0775, st_size=4096, ...}) = 0
listxattr(".", NULL, 0) = 23
listxattr(".", "system.posix_acl_access", 256) = 23
brk(0) = 0x1655000
brk(0x1695000) = 0x1695000
brk(0) = 0x1695000
brk(0) = 0x1695000
brk(0x1676000) = 0x1676000
brk(0) = 0x1676000
mmap(NULL, 266240, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
0) = 0x7fc7e3f59000
brk(0) = 0x1676000
brk(0) = 0x1676000
brk(0x1656000) = 0x1656000
brk(0) = 0x1656000
--- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0x16756e8}
---
+++ killed by SIGSEGV +++
[1]2353 segmentation fault strace getfattr -m '.*' . 2>&1
|
2354 donetail -n 20
nfsv3client% getfattr -n system.posix_acl_access .
# file: .
system.posix_acl_access=0sAgEABwD/BAAHAP8gAAUA/w==
See how:
* getfacl says there's no ACLs
* getfattr says there's still a system.posix_acl_access attr.
Interestingly, the server says othe
Re: workqueue: WARN at at kernel/workqueue.c:2176
On 06/06/2014 09:36 PM, Peter Zijlstra wrote:
> On Thu, Jun 05, 2014 at 06:54:35PM +0800, Lai Jiangshan wrote:
>> diff --git a/kernel/sched/core.c b/kernel/sched/core.c
>> index 268a45e..d05a5a1 100644
>> --- a/kernel/sched/core.c
>> +++ b/kernel/sched/core.c
>> @@ -1474,20 +1474,24 @@ static int ttwu_remote(struct task_struct *p, int
>> wake_flags)
>> }
>>
>> #ifdef CONFIG_SMP
>> -static void sched_ttwu_pending(void)
>> +static void sched_ttwu_pending_locked(struct rq *rq)
>> {
>> -struct rq *rq = this_rq();
>> struct llist_node *llist = llist_del_all(&rq->wake_list);
>> struct task_struct *p;
>>
>> -raw_spin_lock(&rq->lock);
>> -
>> while (llist) {
>> p = llist_entry(llist, struct task_struct, wake_entry);
>> llist = llist_next(llist);
>> ttwu_do_activate(rq, p, 0);
>> }
>> +}
>>
>> +static void sched_ttwu_pending(void)
>> +{
>> +struct rq *rq = this_rq();
>> +
>> +raw_spin_lock(&rq->lock);
>> +sched_ttwu_pending_locked(rq);
>> raw_spin_unlock(&rq->lock);
>> }
>
> OK, so this won't apply to a recent kernel.
Thank you for review.
The code here was already changed in the recent kernel?
or I touched too much to apply it?
>
>> @@ -4530,6 +4534,11 @@ int set_cpus_allowed_ptr(struct task_struct *p, const
>> struct cpumask *new_mask)
>> goto out;
>>
>> dest_cpu = cpumask_any_and(cpu_active_mask, new_mask);
>> +
>> +/* Ensure it is on rq for migration if it is waking */
>> +if (p->state == TASK_WAKING)
>> +sched_ttwu_pending_locked(rq);
>
> So I would really rather like to avoid this if possible, its doing full
> remote queueing, exactly what we tried to avoid.
set_cpus_allowed_ptr() is slow path, the bad effect introduced by this
change is limited.
>
>> +
>> if (p->on_rq) {
>> struct migration_arg arg = { p, dest_cpu };
>> /* Need help from migration thread: drop lock and wait. */
>> @@ -4576,6 +4585,10 @@ static int __migrate_task(struct task_struct *p, int
>> src_cpu, int dest_cpu)
>> if (!cpumask_test_cpu(dest_cpu, tsk_cpus_allowed(p)))
>> goto fail;
>>
>> +/* Ensure it is on rq for migration if it is waking */
>> +if (p->state == TASK_WAKING)
>> +sched_ttwu_pending_locked(rq_src);
>> +
>> /*
>> * If we're not on a rq, the next wake-up will ensure we're
>> * placed properly.
>
> Oh man, another variant.. why did you change it again? And without
> explanation for why you changed it.
>
> I don't see a reason to call sched_ttwu_pending() with rq->lock held,
> seeing as how we append to that list without it held.
sched_ttwu_pending() requires rq->lock to do actual work.
I swapped the order of "llist_del_all(&rq->wake_list)" and
"raw_spin_lock(&rq->lock);"
that it makes the lock section of rq->lock is slightly extend.
>
> I'm still thinking the previous version is good, can you explain why you
> changed it?
There was a window in the previous version.
sched_ttwu_pending();
on_rq <==> waken-up.
New patch just fixes up p->on_rq before considering it.
How about this (slight changed without touching original sched_ttwu_pending())
---
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 268a45e..cd224ea 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -1474,6 +1474,18 @@ static int ttwu_remote(struct task_struct *p, int
wake_flags)
}
#ifdef CONFIG_SMP
+static void sched_ttwu_pending_locked(struct rq *rq)
+{
+ struct llist_node *llist = llist_del_all(&rq->wake_list);
+ struct task_struct *p;
+
+ while (llist) {
+ p = llist_entry(llist, struct task_struct, wake_entry);
+ llist = llist_next(llist);
+ ttwu_do_activate(rq, p, 0);
+ }
+}
+
static void sched_ttwu_pending(void)
{
struct rq *rq = this_rq();
@@ -4530,7 +4542,7 @@ int set_cpus_allowed_ptr(struct task_struct *p, const
struct cpumask *new_mask)
goto out;
dest_cpu = cpumask_any_and(cpu_active_mask, new_mask);
- if (p->on_rq) {
+ if (p->on_rq || p->state == TASK_WAKING) {
struct migration_arg arg = { p, dest_cpu };
/* Need help from migration thread: drop lock and wait. */
task_rq_unlock(rq, p, &flags);
@@ -4576,6 +4588,10 @@ static int __migrate_task(struct
Re: [PATCH 3.14 103/228] revert "mm: vmscan: do not swap anon pages just because free+file is low"
On Sun, Jun 08, 2014 at 03:03:15AM +0100, Ben Hutchings wrote:
> On Wed, 2014-06-04 at 16:22 -0700, Greg Kroah-Hartman wrote:
> > 3.14-stable review patch. If anyone has any objections, please let me know.
> >
> > --
> >
> > From: Johannes Weiner
> >
> > commit 623762517e2370be3b3f95f4fe08d6c063a49b06 upstream.
> >
> > This reverts commit 0bf1457f0cfc ("mm: vmscan: do not swap anon pages
> > just because free+file is low") because it introduced a regression in
> > mostly-anonymous workloads, where reclaim would become ineffective and
> > trap every allocating task in direct reclaim.
> [...]
>
> That commit was not included in 3.14 or in subsequent stable updates, so
> this 'revert' is not approriate. We now have duplicate checks:
>
> /*
>* If it's foreseeable that reclaiming the file cache won't be
>* enough to get the zone back into a desirable shape, we have
>* to swap. Better start now and leave the - probably heavily
>* thrashing - remaining file pages alone.
>*/
> if (global_reclaim(sc)) {
> free = zone_page_state(zone, NR_FREE_PAGES);
> if (unlikely(file + free <= high_wmark_pages(zone))) {
> scan_balance = SCAN_ANON;
> goto out;
> }
> }
>
> /*
>* Prevent the reclaimer from falling into the cache trap: as
>* cache pages start out inactive, every cache fault will tip
>* the scan balance towards the file LRU. And as the file LRU
>* shrinks, so does the window for rotation from references.
>* This means we have a runaway feedback loop where a tiny
>* thrashing file LRU becomes infinitely more attractive than
>* anon pages. Try to detect this based on file LRU size.
>*/
> if (global_reclaim(sc)) {
> unsigned long free = zone_page_state(zone, NR_FREE_PAGES);
>
> if (unlikely(file + free <= high_wmark_pages(zone))) {
> scan_balance = SCAN_ANON;
> goto out;
> }
> }
>
> Ben.
Ugh, good catch, thanks for this. I'll go revert it now.
greg k-h
--
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.14 103/228] revert "mm: vmscan: do not swap anon pages just because free+file is low"
On Wed, 2014-06-04 at 16:22 -0700, Greg Kroah-Hartman wrote:
> 3.14-stable review patch. If anyone has any objections, please let me know.
>
> --
>
> From: Johannes Weiner
>
> commit 623762517e2370be3b3f95f4fe08d6c063a49b06 upstream.
>
> This reverts commit 0bf1457f0cfc ("mm: vmscan: do not swap anon pages
> just because free+file is low") because it introduced a regression in
> mostly-anonymous workloads, where reclaim would become ineffective and
> trap every allocating task in direct reclaim.
[...]
That commit was not included in 3.14 or in subsequent stable updates, so
this 'revert' is not approriate. We now have duplicate checks:
/*
* If it's foreseeable that reclaiming the file cache won't be
* enough to get the zone back into a desirable shape, we have
* to swap. Better start now and leave the - probably heavily
* thrashing - remaining file pages alone.
*/
if (global_reclaim(sc)) {
free = zone_page_state(zone, NR_FREE_PAGES);
if (unlikely(file + free <= high_wmark_pages(zone))) {
scan_balance = SCAN_ANON;
goto out;
}
}
/*
* Prevent the reclaimer from falling into the cache trap: as
* cache pages start out inactive, every cache fault will tip
* the scan balance towards the file LRU. And as the file LRU
* shrinks, so does the window for rotation from references.
* This means we have a runaway feedback loop where a tiny
* thrashing file LRU becomes infinitely more attractive than
* anon pages. Try to detect this based on file LRU size.
*/
if (global_reclaim(sc)) {
unsigned long free = zone_page_state(zone, NR_FREE_PAGES);
if (unlikely(file + free <= high_wmark_pages(zone))) {
scan_balance = SCAN_ANON;
goto out;
}
}
Ben.
--
Ben Hutchings
Never attribute to conspiracy what can adequately be explained by stupidity.
signature.asc
Description: This is a digitally signed message part
[for-next][PATCH] tracing: Fix memory leak on instance deletion
Ug, found a memory leak in instance deletion. Missed freeing the snapshot buffer. git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace.git for-next Head SHA1: 17f83bffd1b41b5cd6fe08ad12c8a69341542ba2 Steven Rostedt (Red Hat) (1) tracing: Fix memory leak on instance deletion trace.c |3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) --- commit a9fcaaac37b3baba1343f906f52aeb65c4d4e356 Author: Steven Rostedt (Red Hat) Date: Fri Jun 6 23:17:28 2014 -0400 tracing: Fix memory leak on instance deletion When an instance is created, it also gets a snapshot ring buffer allocated (with minimum of pages). But when it is deleted the snapshot buffer is not. There was a helper function added to match the allocation of these ring buffers to a way to free them, but it wasn't used by the deletion of an instance. Using that helper function solves this memory leak. Signed-off-by: Steven Rostedt diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c index 26cfff38e2ab..16f7038d1f4d 100644 --- a/kernel/trace/trace.c +++ b/kernel/trace/trace.c @@ -6349,8 +6349,7 @@ static int instance_delete(const char *name) event_trace_del_tracer(tr); ftrace_destroy_function_files(tr); debugfs_remove_recursive(tr->dir); - free_percpu(tr->trace_buffer.data); - ring_buffer_free(tr->trace_buffer.buffer); + free_trace_buffers(tr); kfree(tr->name); kfree(tr); -- 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] staging: rtl8821ae: rtl8821ae: hw.c: Cleaning up if statement that always evaluates to false
I find a logical error in an if statement '(X & 0xfc) == 0x3' is always false After pointing this out, Larry Finger informed what would be the correct one. '(X & 0x3) == 0x3' Signed-off-by: Rickard Strandqvist --- drivers/staging/rtl8821ae/rtl8821ae/hw.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/rtl8821ae/rtl8821ae/hw.c b/drivers/staging/rtl8821ae/rtl8821ae/hw.c index 1b8583b..52322e3 100644 --- a/drivers/staging/rtl8821ae/rtl8821ae/hw.c +++ b/drivers/staging/rtl8821ae/rtl8821ae/hw.c @@ -1623,7 +1623,7 @@ static int _rtl8821ae_set_media_status(struct ieee80211_hw *hw, rtl_write_byte(rtlpriv, (MSR), bt_msr); rtlpriv->cfg->ops->led_control(hw, ledaction); - if ((bt_msr & ~0xfc) == MSR_AP) + if ((bt_msr & MSR_AP) == MSR_AP) rtl_write_byte(rtlpriv, REG_BCNTCFG + 1, 0x00); else rtl_write_byte(rtlpriv, REG_BCNTCFG + 1, 0x66); -- 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/
Re: [PATCH] arch: tile: kernel: unaligned.c: Cleaning up uninitialized variables
On 5/31/2014 7:00 PM, Rickard Strandqvist wrote: There is a risk that the variable will be used without being initialized. This was largely found by using a static code analysis program called cppcheck. Signed-off-by: Rickard Strandqvist --- arch/tile/kernel/unaligned.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) Thanks! Taken into the tile tree with some slight modifications (initialize variables to -1 not 0, and remove the resulting dead code in find_regs). -- Chris Metcalf, Tilera Corp. http://www.tilera.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/
[PATCH] net: wireless: rtlwifi: rtl8723be: hw.c: Cleaning up if statement that always evaluates to false
I find a logical error in an if statement '(X & 0xfc) == 0x3' is always false After pointing this out, Larry Finger informed what would be the correct one. '(X & 0x3) == 0x3' Signed-off-by: Rickard Strandqvist --- drivers/net/wireless/rtlwifi/rtl8723be/hw.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/wireless/rtlwifi/rtl8723be/hw.c b/drivers/net/wireless/rtlwifi/rtl8723be/hw.c index 0fdf090..b61044f 100644 --- a/drivers/net/wireless/rtlwifi/rtl8723be/hw.c +++ b/drivers/net/wireless/rtlwifi/rtl8723be/hw.c @@ -1197,7 +1197,7 @@ static int _rtl8723be_set_media_status(struct ieee80211_hw *hw, } rtl_write_byte(rtlpriv, (MSR), bt_msr); rtlpriv->cfg->ops->led_control(hw, ledaction); - if ((bt_msr & 0x03) == MSR_AP) + if ((bt_msr & MSR_AP) == MSR_AP) rtl_write_byte(rtlpriv, REG_BCNTCFG + 1, 0x00); else rtl_write_byte(rtlpriv, REG_BCNTCFG + 1, 0x66); -- 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/
[PATCH] net: wireless: rtlwifi: rtl8723ae: hw.c: Cleaning up if statement that always evaluates to false
I find a logical error in an if statement '(X & 0xfc) == 0x3' is always false After pointing this out, Larry Finger informed what would be the correct one. '(X & 0x3) == 0x3' Signed-off-by: Rickard Strandqvist --- drivers/net/wireless/rtlwifi/rtl8723ae/hw.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/wireless/rtlwifi/rtl8723ae/hw.c b/drivers/net/wireless/rtlwifi/rtl8723ae/hw.c index 65c9e80..6703f36 100644 --- a/drivers/net/wireless/rtlwifi/rtl8723ae/hw.c +++ b/drivers/net/wireless/rtlwifi/rtl8723ae/hw.c @@ -1109,7 +1109,7 @@ static int _rtl8723ae_set_media_status(struct ieee80211_hw *hw, rtl_write_byte(rtlpriv, (MSR), bt_msr); rtlpriv->cfg->ops->led_control(hw, ledaction); - if ((bt_msr & 0x03) == MSR_AP) + if ((bt_msr & MSR_AP) == MSR_AP) rtl_write_byte(rtlpriv, REG_BCNTCFG + 1, 0x00); else rtl_write_byte(rtlpriv, REG_BCNTCFG + 1, 0x66); -- 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/
[PATCH] net: wireless: rtlwifi: rtl8192de: hw.c: Cleaning up if statement that always evaluates to false
I find a logical error in an if statement '(X & 0xfc) == 0x3' is always false After pointing this out, Larry Finger informed what would be the correct one. '(X & 0x3) == 0x3' Signed-off-by: Rickard Strandqvist --- drivers/net/wireless/rtlwifi/rtl8192de/hw.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/wireless/rtlwifi/rtl8192de/hw.c b/drivers/net/wireless/rtlwifi/rtl8192de/hw.c index 2b08671..32e791e 100644 --- a/drivers/net/wireless/rtlwifi/rtl8192de/hw.c +++ b/drivers/net/wireless/rtlwifi/rtl8192de/hw.c @@ -1128,7 +1128,7 @@ static int _rtl92de_set_media_status(struct ieee80211_hw *hw, } rtl_write_byte(rtlpriv, REG_CR + 2, bt_msr); rtlpriv->cfg->ops->led_control(hw, ledaction); - if ((bt_msr & 0xfc) == MSR_AP) + if ((bt_msr & MSR_AP) == MSR_AP) rtl_write_byte(rtlpriv, REG_BCNTCFG + 1, 0x00); else rtl_write_byte(rtlpriv, REG_BCNTCFG + 1, 0x66); -- 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/
[PATCH] net: wireless: rtlwifi: rtl8192cu: hw.c: Cleaning up if statement that always evaluates to false
I find a logical error in an if statement '(X & 0xfc) == 0x3' is always false After pointing this out, Larry Finger informed what would be the correct one. '(X & 0x3) == 0x3' Signed-off-by: Rickard Strandqvist --- drivers/net/wireless/rtlwifi/rtl8192cu/hw.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/wireless/rtlwifi/rtl8192cu/hw.c b/drivers/net/wireless/rtlwifi/rtl8192cu/hw.c index 07cb06d..40b9ad6 100644 --- a/drivers/net/wireless/rtlwifi/rtl8192cu/hw.c +++ b/drivers/net/wireless/rtlwifi/rtl8192cu/hw.c @@ -1360,7 +1360,7 @@ static int _rtl92cu_set_media_status(struct ieee80211_hw *hw, } rtl_write_byte(rtlpriv, (MSR), bt_msr); rtlpriv->cfg->ops->led_control(hw, ledaction); - if ((bt_msr & 0xfc) == MSR_AP) + if ((bt_msr & MSR_AP) == MSR_AP) rtl_write_byte(rtlpriv, REG_BCNTCFG + 1, 0x00); else rtl_write_byte(rtlpriv, REG_BCNTCFG + 1, 0x66); -- 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/
[PATCH] net: wireless: rtlwifi: rtl8192ce: hw.c: Cleaning up if statement that always evaluates to false
I find a logical error in an if statement '(X & 0xfc) == 0x3' is always false After pointing this out, Larry Finger informed what would be the correct one. '(X & 0x3) == 0x3' Signed-off-by: Rickard Strandqvist --- drivers/net/wireless/rtlwifi/rtl8192ce/hw.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/wireless/rtlwifi/rtl8192ce/hw.c b/drivers/net/wireless/rtlwifi/rtl8192ce/hw.c index 55adf04..135b351 100644 --- a/drivers/net/wireless/rtlwifi/rtl8192ce/hw.c +++ b/drivers/net/wireless/rtlwifi/rtl8192ce/hw.c @@ -1206,7 +1206,7 @@ static int _rtl92ce_set_media_status(struct ieee80211_hw *hw, rtl_write_byte(rtlpriv, (MSR), bt_msr); rtlpriv->cfg->ops->led_control(hw, ledaction); - if ((bt_msr & 0xfc) == MSR_AP) + if ((bt_msr & MSR_AP) == MSR_AP) rtl_write_byte(rtlpriv, REG_BCNTCFG + 1, 0x00); else rtl_write_byte(rtlpriv, REG_BCNTCFG + 1, 0x66); -- 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/
[PATCH] net: wireless: rtlwifi: rtl8188ee: hw.c: Cleaning up if statement that always evaluates to false
I find a logical error in an if statement '(X & 0xfc) == 0x3' is always false After pointing this out, Larry Finger informed what would be the correct one. '(X & 0x3) == 0x3' Signed-off-by: Rickard Strandqvist --- drivers/net/wireless/rtlwifi/rtl8188ee/hw.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/wireless/rtlwifi/rtl8188ee/hw.c b/drivers/net/wireless/rtlwifi/rtl8188ee/hw.c index 94cd9df..35ea614 100644 --- a/drivers/net/wireless/rtlwifi/rtl8188ee/hw.c +++ b/drivers/net/wireless/rtlwifi/rtl8188ee/hw.c @@ -1231,7 +1231,7 @@ static int _rtl88ee_set_media_status(struct ieee80211_hw *hw, rtl_write_byte(rtlpriv, (MSR), bt_msr); rtlpriv->cfg->ops->led_control(hw, ledaction); - if ((bt_msr & 0xfc) == MSR_AP) + if ((bt_msr & MSR_AP) == MSR_AP) rtl_write_byte(rtlpriv, REG_BCNTCFG + 1, 0x00); else rtl_write_byte(rtlpriv, REG_BCNTCFG + 1, 0x66); -- 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/
Re: [PATCH] net: wireless: rtlwifi: rtl8192de: hw.c: Cleaning up conjunction always evaluates to false
Hi all Good. New patches are on the way :) Best regards Rickard Strandqvist 2014-06-08 2:01 GMT+02:00 Larry Finger : > On 06/07/2014 10:24 AM, Rickard Strandqvist wrote: >> >> Hi! >> >> Yes, 0x3 was one of the most likely :) >> But wanted someone who knows the code better would be heard. >> All agreed? Then I do a new patch. >> >> Looks like it is the same error in the files below, I'll fix them all them >> to. >> >> rtl8192cu/hw.c:1363:if ((bt_msr & 0xfc) == MSR_AP) >> rtl8192ce/hw.c:1209:if ((bt_msr & 0xfc) == MSR_AP) >> rtl8188ee/hw.c:1234:if ((bt_msr & 0xfc) == MSR_AP) >> rtl8192de/hw.c:1131:if ((bt_msr & 0xfc) == MSR_AP) >> >> >> Best regards >> Rickard Strandqvist >> >> >> 2014-06-07 17:02 GMT+02:00 Peter Wu : >>> >>> On Saturday 07 June 2014 16:30:19 Rickard Strandqvist wrote: Expression '(X & 0xfc) == 0x3' is always false >>> >>> >>> While this is true, I believe that some other mistake is made. >>> I chose to remove this code, because it will not make any difference. But obviously it is rather a properly designed if statement that is needed. This was partly found using a static code analysis program called cppcheck. Signed-off-by: Rickard Strandqvist --- drivers/net/wireless/rtlwifi/rtl8192de/hw.c |5 + 1 file changed, 1 insertion(+), 4 deletions(-) diff --git a/drivers/net/wireless/rtlwifi/rtl8192de/hw.c b/drivers/net/wireless/rtlwifi/rtl8192de/hw.c index 2b08671..a1520d5 100644 --- a/drivers/net/wireless/rtlwifi/rtl8192de/hw.c +++ b/drivers/net/wireless/rtlwifi/rtl8192de/hw.c @@ -1128,10 +1128,7 @@ static int _rtl92de_set_media_status(struct ieee80211_hw *hw, } rtl_write_byte(rtlpriv, REG_CR + 2, bt_msr); rtlpriv->cfg->ops->led_control(hw, ledaction); - if ((bt_msr & 0xfc) == MSR_AP) >>> >>> >>> If you look a few lines up, then you see that bt_msr is OR-ed with MSR_AP >>> for AP interfaces. The 0xfc should be 0x03, see other drivers for >>> example: >>> >>> rtl8723ae/hw.c:1112:if ((bt_msr & 0x03) == MSR_AP) >>> rtl8723be/hw.c:1200:if ((bt_msr & 0x03) == MSR_AP) >>> rtl8192cu/hw.c:1363:if ((bt_msr & 0xfc) == MSR_AP) >>> rtl8192ce/hw.c:1209:if ((bt_msr & 0xfc) == MSR_AP) >>> rtl8188ee/hw.c:1234:if ((bt_msr & 0xfc) == MSR_AP) >>> rtl8192de/hw.c:1131:if ((bt_msr & 0xfc) == MSR_AP) >>> - rtl_write_byte(rtlpriv, REG_BCNTCFG + 1, 0x00); - else - rtl_write_byte(rtlpriv, REG_BCNTCFG + 1, 0x66); + rtl_write_byte(rtlpriv, REG_BCNTCFG + 1, 0x66); return 0; } > > > Peter, > > As you have learned here, automatically making changes suggested by some > tool may convert a visible bug into one that is invisible, and only found by > a detailed line-by-line examination of the code, and that is unlikely to > happen. Please be careful. > > From everything I see, the test in all drivers should be > > if ((bt_msr & MSR_AP) == MSR_AP) > > Larry > -- 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/
[RFC PATCH] gpio: Add a defer reset object to send board specific reset
The Problem
---
The reset signal on a hardware board is send either:
- during machine initialization
- during bus master's initialization
In some hardware design, devices on bus need a non-standard and extra reset
signal after bus is initialied. Most reason is to wake up device from hanging
state.
The board spefic reset code can not be put into machine init code, as it is
too early. This code can not also be put onto chip's driver, as it is board
specific and not suitable for a common chip driver.
Defer Reset Object
--
The defer reset object is to resolve this issue, developer can put a defer-
reset device on the board's dts file and enable DEFER RESET OBJECT CONFIG.
During driver init-calls, a defer-reset object is created and issue reset signal
after the enclosing device is initialized.
This eliminate the need to rewrite a driver module with only one purpose:
sending
a board specific reset. This also allow mainstream kernel to support many boards
that modify the common drivers to send board specific reset. Configuring
defer-reset
device in dts leave the board specific reset rules on board level and simple to
maintain.
Example dts File
usb-ehci-chip@1211000{
usb-phy = <&usb2_phy>;
defer_reset_vbus {
compatible = "defer-reset";
reset-gpios = <&gpx3 5 1>;
reset-init = <0>;
reset-end = <1>;
delay = <5>;
};
};
Block Diagram of dts File
-
+-+
| usb-ehci-chip@1211000 |
| +-+ |
| | defer-reset(gpx3) | |
| +-+ |
+-+
Signed-off-by: Houcheng Lin
---
drivers/gpio/Kconfig| 8 ++
drivers/gpio/Makefile | 1 +
drivers/gpio/gpio-defer-reset.c | 179
3 files changed, 188 insertions(+)
create mode 100644 drivers/gpio/gpio-defer-reset.c
diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index a86c49a..99aa0d6 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -851,6 +851,14 @@ config GPIO_BCM_KONA
help
Turn on GPIO support for Broadcom "Kona" chips.
+config GPIO_DEFER_RESET
+ bool "Defer reset driver via gpio"
+ depends on OF_GPIO
+ help
+ Enable defer reset drvier
+ The reset signal would be issued after a device on USB or PCI bus is
initialied.
+ The dependency of reset signal and device can be specified in board's
dts file.
+
comment "USB GPIO expanders:"
config GPIO_VIPERBOARD
diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
index 6309aff..0754758 100644
--- a/drivers/gpio/Makefile
+++ b/drivers/gpio/Makefile
@@ -101,3 +101,4 @@ obj-$(CONFIG_GPIO_WM8994) += gpio-wm8994.o
obj-$(CONFIG_GPIO_XILINX) += gpio-xilinx.o
obj-$(CONFIG_GPIO_XTENSA) += gpio-xtensa.o
obj-$(CONFIG_GPIO_ZEVIO) += gpio-zevio.o
+obj-$(CONFIG_GPIO_DEFER_RESET) += gpio-defer-reset.o
diff --git a/drivers/gpio/gpio-defer-reset.c b/drivers/gpio/gpio-defer-reset.c
new file mode 100644
index 000..c6decab
--- /dev/null
+++ b/drivers/gpio/gpio-defer-reset.c
@@ -0,0 +1,179 @@
+/*
+ * GPIO Defer Reset Driver
+ *
+ * Copyright (C) 2014 Houcheng Lin
+ * Author: Houcheng Lin
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+
+#define DRIVER_DESC "GPIO Defer Reset Driver"
+#define GDR_MAX_DEV 32
+
+
+static DEFINE_MUTEX(deferred_reset_mutex);
+static LIST_HEAD(deferred_reset_list);
+
+
+struct defer_reset_private {
+ struct list_head next;
+ struct device_node *node; /* defer_reset device */
+ intissued;
+};
+
+static void gdr_issue_reset(
+ struct platform_device *pdev, struct device_node *dnode)
+{
+ int gpio;
+ int i;
+ int count = of_gpio_named_count(dnode, "reset-gpios");
+ u32 reset_init[GDR_MAX_DEV];
+ u32 reset_end[GDR_MAX_DEV];
+ u32 delay;
+
+ if (count != of_property_count_u32_elems(dnode, "reset-init")) {
+ dev_err(&pdev->dev, "should call std error here, number is
wrong:%d\n",
+ of_property_count_u32_elems(dnode, "reset-init"));
+ return;
+ }
+ if (count != of_property_count_u32_elems(dnode, "reset-end")) {
+ dev_err(&pdev->dev, "should call std error here, number is
wrong:%d\n",
+ of_property_count_u32_elems(dnode, "reset-end"));
+ return;
Re: Missing USB XHCI and EHCI reset for kexec
On Sun, 8 Jun 2014, Benjamin Herrenschmidt wrote: > Looking at the code a bit more ... that xhci_shutdown() worries me. > > It basically just whacks xhci_halt() and optionally reset() but nothing > is done that I can see to ensure that we aren't concurrently > doing things like queuing URBs, polling the root hub etc... > > That's definitely not clean and while it might work (most of the time > at least) on actual shutdown it's definitely not right for kexec I > reckon. Yes, it really was meant for actual system shutdown. > Now there's a separate discussion that we had a while ago and might > want to resume which is to say that kexec shouldn't be calling > shutdown() anyway, but instead remove() on all drivers which is > a much better code path for the purpose of leaving the device in > a state where a driver can reconnect to it. > > However, in the case of XHCI that leads to another issue described > here: > > http://marc.info/?l=linux-usb&m=139483181809062&w=2 > > For which there was little / no discussion at all... I suppose we could > do a quirk but I don't think the problem is fundamentally > specific to the TI chip, we should probably stop both root hubs > before we halt both HCDs. The issue described in that email seems valid to me. Maybe the patch should be resubmitted. Now that xhci-hcd has changed maintainership, the discussion might move forward. In any case, you certainly can try testing with that patch installed. After all, xhci-hcd should work properly after a rmmod/modprobe sequence, and this is pretty much the same thing. Alan Stern -- 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] staging: tidspbridge: pmgr: dspapi.c: Cleaning up uninitialized variable
Hi Sure, no problem! Glad I could help, and additionally with more than just a two-line fix this time :-) Best regards Rickard Strandqvist 2014-06-07 21:44 GMT+02:00 Dan Carpenter : > On Wed, Jun 04, 2014 at 12:23:39AM +0200, Rickard Strandqvist wrote: >> There is a risk that the variables will be used without being initialized. >> Has also improved error handling, after an email proposal from Dan Carpenter. >> >> Signed-off-by: Rickard Strandqvist > > Looks ok. This fixes some information leak bugs. Thanks. > > regards, > dan carpenter > -- 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] net: wireless: rtlwifi: rtl8192de: hw.c: Cleaning up conjunction always evaluates to false
On 06/07/2014 10:24 AM, Rickard Strandqvist wrote: Hi! Yes, 0x3 was one of the most likely :) But wanted someone who knows the code better would be heard. All agreed? Then I do a new patch. Looks like it is the same error in the files below, I'll fix them all them to. rtl8192cu/hw.c:1363:if ((bt_msr & 0xfc) == MSR_AP) rtl8192ce/hw.c:1209:if ((bt_msr & 0xfc) == MSR_AP) rtl8188ee/hw.c:1234:if ((bt_msr & 0xfc) == MSR_AP) rtl8192de/hw.c:1131:if ((bt_msr & 0xfc) == MSR_AP) Best regards Rickard Strandqvist 2014-06-07 17:02 GMT+02:00 Peter Wu : On Saturday 07 June 2014 16:30:19 Rickard Strandqvist wrote: Expression '(X & 0xfc) == 0x3' is always false While this is true, I believe that some other mistake is made. I chose to remove this code, because it will not make any difference. But obviously it is rather a properly designed if statement that is needed. This was partly found using a static code analysis program called cppcheck. Signed-off-by: Rickard Strandqvist --- drivers/net/wireless/rtlwifi/rtl8192de/hw.c |5 + 1 file changed, 1 insertion(+), 4 deletions(-) diff --git a/drivers/net/wireless/rtlwifi/rtl8192de/hw.c b/drivers/net/wireless/rtlwifi/rtl8192de/hw.c index 2b08671..a1520d5 100644 --- a/drivers/net/wireless/rtlwifi/rtl8192de/hw.c +++ b/drivers/net/wireless/rtlwifi/rtl8192de/hw.c @@ -1128,10 +1128,7 @@ static int _rtl92de_set_media_status(struct ieee80211_hw *hw, } rtl_write_byte(rtlpriv, REG_CR + 2, bt_msr); rtlpriv->cfg->ops->led_control(hw, ledaction); - if ((bt_msr & 0xfc) == MSR_AP) If you look a few lines up, then you see that bt_msr is OR-ed with MSR_AP for AP interfaces. The 0xfc should be 0x03, see other drivers for example: rtl8723ae/hw.c:1112:if ((bt_msr & 0x03) == MSR_AP) rtl8723be/hw.c:1200:if ((bt_msr & 0x03) == MSR_AP) rtl8192cu/hw.c:1363:if ((bt_msr & 0xfc) == MSR_AP) rtl8192ce/hw.c:1209:if ((bt_msr & 0xfc) == MSR_AP) rtl8188ee/hw.c:1234:if ((bt_msr & 0xfc) == MSR_AP) rtl8192de/hw.c:1131:if ((bt_msr & 0xfc) == MSR_AP) - rtl_write_byte(rtlpriv, REG_BCNTCFG + 1, 0x00); - else - rtl_write_byte(rtlpriv, REG_BCNTCFG + 1, 0x66); + rtl_write_byte(rtlpriv, REG_BCNTCFG + 1, 0x66); return 0; } Peter, As you have learned here, automatically making changes suggested by some tool may convert a visible bug into one that is invisible, and only found by a detailed line-by-line examination of the code, and that is unlikely to happen. Please be careful. From everything I see, the test in all drivers should be if ((bt_msr & MSR_AP) == MSR_AP) Larry -- 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: [GIT PULL] Reiserfs & ext3 changes for 3.16-rc1
On Wed, Jun 4, 2014 at 1:27 PM, Jan Kara wrote: > Hello Linus, > > could you please pull from > > git://git.kernel.org/pub/scm/linux/kernel/git/jack/linux-fs.git for_linus > > to get big reiserfs cleanup from Jeff, an ext3 deadlock fix, and some small > cleanups. This does not work at all for me: fs/reiserfs/do_balan.c: In function ‘balance_leaf_new_nodes’: fs/reiserfs/do_balan.c:1248:3: error: implicit declaration of function ‘format_bh’ [-Werror=implicit-function-declaration] RFALSE(!buffer_journaled(tb->S_new[i]) ^ Hmm? "format_bh()"? Linus -- 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 linux-next] staging: r8192ee: Adapt flush function prototype
On 06/07/2014 12:39 PM, Vincent Stehlé wrote:
Commit 77be2c54c5bd 'mac80211: add vif to flush call' modifies the flush
operation prototype. Update r8192ee function accordingly.
This fixes the following compilation warnings:
drivers/staging/rtl8192ee/core.c: At top level:
drivers/staging/rtl8192ee/core.c:1599:2: warning: initialization from
incompatible pointer type [enabled by default]
.flush = rtl_op_flush,
^
drivers/staging/rtl8192ee/core.c:1599:2: warning: (near initialization for
‘rtl92e_ops.flush’) [enabled by default]
Signed-off-by: Vincent Stehlé
Cc: Greg Kroah-Hartman
Cc: Larry Finger
Ah yes, all the "benefits" of adding a new driver in one tree (staging) that
depends of changes in another (wireless). I have been maintaining this patch in
my own source for several weeks.
Acked-by: Larry Finger
Thanks,
Larry
---
Hi,
Linux next gives a "heads up" that the flush function of staging driver r8192ee
needs to be adapted soon.
This can be seen with e.g. linux next-20140606 and x86 allmodconfig.
Also, r8192ee would benefit from the following patch:
http://www.spinics.net/lists/linux-driver-devel/msg47690.html
Best regards,
V.
drivers/staging/rtl8192ee/core.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/rtl8192ee/core.c b/drivers/staging/rtl8192ee/core.c
index 76ea356..7f6accd 100644
--- a/drivers/staging/rtl8192ee/core.c
+++ b/drivers/staging/rtl8192ee/core.c
@@ -322,7 +322,7 @@ static void _rtl_add_wowlan_patterns(struct ieee80211_hw
*hw,
struct rtl_mac *mac = &(rtlpriv->mac80211);
struct cfg80211_pkt_pattern *patterns = wow->patterns;
struct rtl_wow_pattern rtl_pattern;
- u8 *pattern_os, *mask_os;
+ const u8 *pattern_os, *mask_os;
u8 mask[MAX_WOL_BIT_MASK_SIZE] = {0};
u8 content[MAX_WOL_PATTERN_SIZE] = {0};
u8 broadcast_addr[6] = {0xff, 0xff, 0xff, 0xff, 0xff, 0xff};
@@ -1561,7 +1561,7 @@ static void rtl_op_rfkill_poll(struct ieee80211_hw *hw)
* before switch channle or power save, or tx buffer packet
* maybe send after offchannel or rf sleep, this may cause
* dis-association by AP */
-static void rtl_op_flush(struct ieee80211_hw *hw,
+static void rtl_op_flush(struct ieee80211_hw *hw, struct ieee80211_vif *vif,
u32 queues, bool drop)
{
struct rtl_priv *rtlpriv = rtl_priv(hw);
--
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 1/1] cleanup: use bool as return type for rwsem_is_locked
On Fri, Jun 06, 2014 at 07:39:30PM -0700, Joe Perches wrote:
> On Fri, 2014-06-06 at 21:41 -0400, Pranith Kumar wrote:
> > On 06/06/2014 08:59 PM, Pranith Kumar wrote:
> > > On 06/06/2014 08:18 PM, Dave Chinner wrote:
> > >> If you are going to change the return type to bool, then you should
> > >> also remove the manual "!!" conversions to a boolean return and let
> > >> the compiler do it in the most optimal way.
> > > Agreed, please find patch below:
> > Simplify the "!!" condition. This is much simpler. :)
> []
> > diff --git a/fs/xfs/xfs_inode.c b/fs/xfs/xfs_inode.c
>
> > @@ -285,25 +285,25 @@ xfs_ilock_demote(
> > }
> >
> > #if defined(DEBUG) || defined(XFS_WARN)
> > -int
> > +bool
> > xfs_isilocked(
> > xfs_inode_t *ip,
> > uintlock_flags)
> > {
> > if (lock_flags & (XFS_ILOCK_EXCL|XFS_ILOCK_SHARED)) {
> > if (!(lock_flags & XFS_ILOCK_SHARED))
> > - return !!ip->i_lock.mr_writer;
> > + return (ip->i_lock.mr_writer != 0);
>
> simpler still would be just removing the !! completely.
> I presume in no case would it make an actual difference
> in emitted code.
>
> ie:
> return ip->i_lock.mr_writer;
Yup, that's exactly what I meant. Casting to a bool type does all
the work of squashing all non-zero values to 1...
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.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/
Free Lotto Award Notification(Reference:WIN-37-14-29-14)
>From claim´s processing office. Free Lotto Lottery Award Notification Confirmation Ticket No: 33-48-19-H5H Reference:WIN-37-14-29-14 You have won( 1 Million Euros )in the Free Lotto Lottery Award 2014 held in Madrid Spain This email was sent to notify you officially as you are advise to contact the claim´s processing office with your details immediately for claim, Contact Person: Martinez Adela Contact Email: freelottoaward...@gmail.com Signed (Announcer) Director, Cooperate HR and Communication. FREE LOTTO LOTTERY AWARD -- 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 3.10.42
I'm announcing the release of the 3.10.42 kernel. All users of the 3.10 kernel series must upgrade. The updated 3.10.y git tree can be found at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-3.10.y and can be browsed at the normal kernel.org git web browser: http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary thanks, greg k-h Documentation/i2c/busses/i2c-i801 |2 Documentation/input/elantech.txt |5 Documentation/ja_JP/HOWTO |2 Documentation/ja_JP/stable_kernel_rules.txt |6 Documentation/zh_CN/HOWTO |2 Documentation/zh_CN/stable_kernel_rules.txt |2 Makefile |2 arch/arm/boot/dts/imx53.dtsi |2 arch/arm/kernel/crash_dump.c |2 arch/metag/include/asm/barrier.h |3 arch/metag/include/asm/processor.h|2 arch/mips/cavium-octeon/octeon-irq.c |2 arch/mips/lantiq/dts/easy50712.dts|1 arch/mips/ralink/dts/mt7620a_eval.dts |1 arch/mips/ralink/dts/rt2880_eval.dts |1 arch/mips/ralink/dts/rt3052_eval.dts |1 arch/mips/ralink/dts/rt3883_eval.dts |1 arch/parisc/include/asm/processor.h |2 arch/powerpc/Makefile |4 arch/powerpc/include/asm/ppc_asm.h|7 arch/powerpc/kernel/process.c | 10 arch/s390/crypto/aes_s390.c |3 arch/s390/crypto/des_s390.c |3 arch/x86/include/asm/hugetlb.h|1 arch/x86/kernel/ldt.c |4 arch/x86/vdso/vdso32-setup.c |8 crypto/crypto_wq.c|2 drivers/acpi/blacklist.c | 13 drivers/ata/libata-core.c |9 drivers/ata/pata_at91.c | 11 drivers/base/dd.c | 17 + drivers/base/topology.c |3 drivers/block/xen-blkfront.c | 125 +++-- drivers/bluetooth/ath3k.c |2 drivers/bluetooth/btusb.c |1 drivers/bus/mvebu-mbus.c |6 drivers/char/ipmi/ipmi_kcs_sm.c |5 drivers/char/ipmi/ipmi_si_intf.c | 46 ++- drivers/clk/versatile/clk-vexpress-osc.c |2 drivers/clocksource/exynos_mct.c |4 drivers/crypto/caam/error.c | 10 drivers/gpu/drm/i915/intel_display.c | 26 + drivers/gpu/drm/nouveau/core/subdev/therm/fan.c | 19 - drivers/gpu/drm/nouveau/nouveau_acpi.c|3 drivers/gpu/drm/radeon/radeon_atpx_handler.c |7 drivers/gpu/drm/radeon/radeon_uvd.c |4 drivers/gpu/host1x/hw/intr_hw.c |4 drivers/hv/connection.c |6 drivers/hwmon/emc1403.c |4 drivers/i2c/busses/Kconfig|2 drivers/i2c/busses/i2c-designware-core.c |3 drivers/i2c/busses/i2c-i801.c |6 drivers/i2c/busses/i2c-rcar.c |9 drivers/i2c/busses/i2c-s3c2410.c |2 drivers/iio/imu/inv_mpu6050/inv_mpu_core.c|7 drivers/infiniband/ulp/isert/ib_isert.c | 27 -- drivers/infiniband/ulp/isert/ib_isert.h |2 drivers/input/keyboard/atkbd.c| 29 ++ drivers/input/mouse/elantech.c| 26 + drivers/input/mouse/elantech.h|1 drivers/input/mouse/synaptics.c | 10 drivers/iommu/amd_iommu.c |2 drivers/irqchip/irq-gic.c |8 drivers/leds/leds-pwm.c | 23 - drivers/md/dm-crypt.c | 61 drivers/md/md.c |3 drivers/media/i2c/ov7670.c|2 drivers/media/media-device.c |1 drivers/media/platform/omap3isp/isp.c |2 drivers/media/tuners/fc2580.c |6 drivers/media/tuners/fc2580_priv.h|1 drivers/media/v4l2-core/v4l2-compat-ioctl32.c | 12 drivers/net/wirele
Linux 3.14.6
I'm announcing the release of the 3.14.6 kernel. All users of the 3.14 kernel series must upgrade. The updated 3.14.y git tree can be found at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-3.14.y and can be browsed at the normal kernel.org git web browser: http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary thanks, greg k-h Documentation/devicetree/bindings/dma/ti-edma.txt |4 Documentation/i2c/busses/i2c-i801 |1 Documentation/input/elantech.txt |5 Documentation/ja_JP/HOWTO |2 Documentation/ja_JP/stable_kernel_rules.txt |6 Documentation/zh_CN/HOWTO |2 Documentation/zh_CN/stable_kernel_rules.txt |2 Makefile |2 arch/arm/boot/dts/am33xx.dtsi |2 arch/arm/boot/dts/armada-xp-db.dts|2 arch/arm/boot/dts/armada-xp-gp.dts|2 arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts |2 arch/arm/boot/dts/imx53.dtsi |2 arch/arm/boot/dts/kirkwood-mv88f6281gtw-ge.dts| 18 arch/arm/boot/dts/kirkwood-nsa310-common.dtsi | 18 arch/arm/boot/dts/ste-ccu8540.dts |1 arch/arm/common/edma.c| 48 -- arch/arm/kernel/crash_dump.c |2 arch/arm/mach-mvebu/mvebu-soc-id.c| 13 arch/arm/mach-orion5x/common.h|2 arch/arm64/kernel/irq.c | 10 arch/arm64/mm/hugetlbpage.c |4 arch/metag/include/asm/barrier.h |3 arch/metag/include/asm/processor.h|2 arch/mips/cavium-octeon/octeon-irq.c |2 arch/mips/lantiq/dts/easy50712.dts|1 arch/mips/loongson/lemote-2f/clock.c |5 arch/mips/ralink/dts/mt7620a_eval.dts |1 arch/mips/ralink/dts/rt2880_eval.dts |1 arch/mips/ralink/dts/rt3052_eval.dts |1 arch/mips/ralink/dts/rt3883_eval.dts |1 arch/parisc/Kconfig |1 arch/parisc/include/asm/processor.h |2 arch/parisc/kernel/syscall.S | 12 arch/parisc/kernel/traps.c| 54 +- arch/parisc/mm/fault.c| 44 +- arch/powerpc/Makefile |4 arch/powerpc/include/asm/ppc_asm.h|7 arch/powerpc/kernel/machine_kexec_64.c|2 arch/powerpc/kernel/time.c|3 arch/powerpc/platforms/powernv/eeh-ioda.c |3 arch/s390/crypto/aes_s390.c |3 arch/s390/crypto/des_s390.c |3 arch/x86/include/asm/hugetlb.h|1 arch/x86/kernel/ldt.c |4 arch/x86/vdso/vdso32-setup.c |8 crypto/crypto_wq.c|2 drivers/acpi/Kconfig | 17 drivers/acpi/Makefile |1 drivers/acpi/ac.c | 117 +++--- drivers/acpi/acpi_platform.c |1 drivers/acpi/acpi_processor.c |1 drivers/acpi/acpica/acglobal.h|4 drivers/acpi/acpica/tbutils.c |7 drivers/acpi/battery.c| 329 +- drivers/acpi/blacklist.c | 21 + drivers/acpi/cm_sbs.c | 105 + drivers/acpi/ec.c | 21 - drivers/acpi/video.c | 16 drivers/ata/libata-core.c |9 drivers/ata/pata_at91.c | 11 drivers/base/dd.c | 17 drivers/base/platform.c |7 drivers/base/topology.c |3 drivers/bluetooth/ath3k.c |2 drivers/bluetooth/btusb.c |5 drivers/bus/mvebu-mbus.c |6 drivers/char/ipmi/ipmi_kcs_sm.c |5 drivers/char/ipmi/ipmi_si_intf.c | 46 +- drivers/char/tpm/tpm_ppi.c|8 drivers/clk/clk.c | 74 +--- drivers/clk/tegra/clk-pll.c |2 d
Re: 3.15-rc: regression in suspend
On Sat 2014-06-07 14:06:14, Pavel Machek wrote: > On Thu 2014-05-15 17:31:54, Daniel Vetter wrote: > > On Thu, May 15, 2014 at 5:29 PM, Jiri Kosina wrote: > > >> > Note that X do work somehow after resume (I can't switch virtual > > >> > desktops and dialog is stuck on screen, but it is not complete > > >> > failure). I can do ctrl-alt-f1 and get to useful prompt. > > >> > > >> Oops. You were right. It seems it is duplicate after all. > > >> > > >> [drm:init_ring_common] *ERROR* render ring initialization failed ctl > > >> 0001f001 head 1020 tail start 3000 > > > > > > Pavel, thanks a lot for testing. > > > > > > Adding Daniel and Chris to CC -- we have another incarnation of the bug > > > that is being chased in 76554. > > > > Someone succeeding at a bisect would be awesome ... Note that the only > > key here is the ring init failure in dmesg. > > Oh and... the machine has problems comming up after reboot (never seen > those before 3.15). Sometimes, boot will hang with blank screen, and hard > powerdown is needed... Strange. It seems 3.15 with the patch reverted only boots in 30% or so cases... And I've seen resume failure, too, so maybe I was just lucky that it worked for a while. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- 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 3.4.92
I'm announcing the release of the 3.4.92 kernel. All users of the 3.4 kernel series must upgrade. The updated 3.4.y git tree can be found at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-3.4.y and can be browsed at the normal kernel.org git web browser: http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary thanks, greg k-h Documentation/i2c/busses/i2c-piix4 |2 Documentation/ja_JP/HOWTO |2 Documentation/ja_JP/stable_kernel_rules.txt|6 Documentation/kernel-parameters.txt| 20 + Documentation/zh_CN/HOWTO |2 Documentation/zh_CN/stable_kernel_rules.txt|2 Makefile |2 arch/arm/kernel/crash_dump.c |2 arch/parisc/kernel/syscall_table.S |2 arch/s390/crypto/aes_s390.c| 50 ++-- arch/x86/Kconfig |1 arch/x86/boot/Makefile |6 arch/x86/boot/compressed/Makefile |1 arch/x86/include/asm/hugetlb.h |1 arch/x86/kernel/crash.c|2 arch/x86/kernel/ldt.c |4 arch/x86/kernel/reboot.c | 11 - arch/x86/kernel/setup.c|4 arch/x86/kernel/step.c | 53 +++-- arch/x86/kernel/sys_x86_64.c |2 arch/x86/mm/mmap.c |6 arch/x86/platform/efi/efi.c| 105 ++ arch/x86/vdso/vdso32-setup.c |8 crypto/crypto_wq.c |2 drivers/acpi/blacklist.c | 13 + drivers/ata/ata_piix.c |8 drivers/ata/pata_at91.c| 11 - drivers/atm/ambassador.c |2 drivers/atm/idt77252.c |2 drivers/base/dd.c | 17 + drivers/block/floppy.c | 11 - drivers/block/nbd.c|9 drivers/char/ipmi/ipmi_kcs_sm.c|5 drivers/char/ipmi/ipmi_si_intf.c | 46 ++-- drivers/char/random.c | 24 +- drivers/crypto/caam/error.c| 10 drivers/edac/i82975x_edac.c| 11 - drivers/firmware/Kconfig | 18 + drivers/firmware/efivars.c | 256 + drivers/gpu/drm/drm_crtc_helper.c |4 drivers/gpu/drm/i915/i915_debugfs.c|6 drivers/gpu/drm/i915/i915_drv.h|4 drivers/gpu/drm/i915/i915_gem.c| 23 +- drivers/gpu/drm/i915/i915_irq.c|4 drivers/gpu/drm/i915/intel_display.c | 114 ++- drivers/gpu/drm/i915/intel_dp.c|5 drivers/gpu/drm/i915/intel_drv.h |5 drivers/gpu/drm/i915/intel_lvds.c |3 drivers/gpu/drm/i915/intel_opregion.c |2 drivers/gpu/drm/i915/intel_panel.c | 31 ++- drivers/gpu/drm/i915/intel_sdvo.c | 22 +- drivers/gpu/drm/nouveau/nouveau_acpi.c |3 drivers/gpu/drm/nouveau/nouveau_bo.c |2 drivers/gpu/drm/radeon/atombios_crtc.c |5 drivers/gpu/drm/radeon/evergreen.c |9 drivers/gpu/drm/radeon/ni.c|3 drivers/gpu/drm/radeon/r600.c |3 drivers/gpu/drm/radeon/r600_hdmi.c |4 drivers/gpu/drm/radeon/radeon_atpx_handler.c |7 drivers/gpu/drm/radeon/radeon_combios.c| 125 drivers/gpu/drm/radeon/radeon_connectors.c | 34 +++ drivers/gpu/drm/radeon/radeon_display.c|1 drivers/gpu/drm/radeon/radeon_kms.c|4 drivers/gpu/drm/radeon/radeon_mode.h |2 drivers/gpu/drm/radeon/rv770.c |3 drivers/gpu/drm/radeon/si.c|3 drivers/gpu/drm/ttm/ttm_bo.c | 32 +-- drivers/gpu/drm/vmwgfx/vmwgfx_fb.c |5 drivers/hid/hid-logitech-dj.c | 38 ++- drivers/hv/ring_buffer.c |4 drivers/hv/vmbus_drv.c |2 drivers/hwmon/emc1403.c|4 drivers/i2c/busses/Kconfig |1 drivers/i2c/busses/i2c-designware-core.c |3 drivers/i2c/busses/i2c-piix4.c |3 drivers/i2c/busses/i2c-tegra.c | 13 + drivers/idle/intel_idle.c |7 drivers/input/mouse/synaptics.c| 31 ++- drivers/md/dm-bufio.c | 26 ++ drivers/md/dm-mpath.c | 18 +
[PATCH] ip_tunnel: fix i_key matching in ip_tunnel_find
Some tunnels (though only vti as for now) can use i_key just for internal use:
for example vti uses it for fwmark'ing incoming packets. So raw i_key value
shouldn't be treated as a distinguisher for them. ip_tunnel_key_match exists for
cases when we want to compare two ip_tunnel_parms' i_keys.
Example bug:
ip link add type vti ikey 1 local 1.0.0.1 remote 2.0.0.2
ip link add type vti ikey 2 local 1.0.0.1 remote 2.0.0.2
spawned two tunnels, although it doesn't make sense.
Signed-off-by: Dmitry Popov
---
net/ipv4/ip_tunnel.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/net/ipv4/ip_tunnel.c b/net/ipv4/ip_tunnel.c
index 2acc233..cf67fe1 100644
--- a/net/ipv4/ip_tunnel.c
+++ b/net/ipv4/ip_tunnel.c
@@ -268,6 +268,7 @@ static struct ip_tunnel *ip_tunnel_find(struct
ip_tunnel_net *itn,
__be32 remote = parms->iph.daddr;
__be32 local = parms->iph.saddr;
__be32 key = parms->i_key;
+ __be16 flags = parms->i_flags;
int link = parms->link;
struct ip_tunnel *t = NULL;
struct hlist_head *head = ip_bucket(itn, parms);
@@ -275,9 +276,9 @@ static struct ip_tunnel *ip_tunnel_find(struct
ip_tunnel_net *itn,
hlist_for_each_entry_rcu(t, head, hash_node) {
if (local == t->parms.iph.saddr &&
remote == t->parms.iph.daddr &&
- key == t->parms.i_key &&
link == t->parms.link &&
- type == t->dev->type)
+ type == t->dev->type &&
+ ip_tunnel_key_match(&t->parms, flags, key))
break;
}
return 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/
Kernel for olpc-1.75
Hi! I broke installation on olpc-1.75, and I guess its time for it to start running self-compiled kernel. (It still boots if I hold right game key, but I can no longer control backlight. It does not boot at all by default.) AFAICT, olpc.fth and zImage in the boot/ directory of USB disk should do the trick. Unfortunately, 3.0 based kernels no longer compile with current tools, so I tried this version (3.6 based). commit 2a873e0e3681412ccc82a646630ffaf119d36af0 Author: Chris Ball Date: Wed Aug 22 18:51:58 2012 -0400 Revert "ARM: mmp: Send decompress and debug output to UART3 instead of UART2 This reverts commit 8fb8e2ccffd5387c4a5e4e5294270fa61716eb51. Unfortunately, no output at all with arch/arm/configs/xo_175_defconfig. I tried replacing all =m's in .config with =y, but still no output. Is there more recent kernel to work with? Is 2a87... somehow buggy? Did I miss some critical step? Will recent mainline run on olpc unmodified? Thanks, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- 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: Missing USB XHCI and EHCI reset for kexec
On Sat, 2014-06-07 at 11:40 -0400, Alan Stern wrote: > The current xhci-hcd driver includes a quirk flag (XHCI_SPURIOS_WAKEUP) > that causes the shutdown routine to reset the controller. It wasn't > meant for fixing kexec problems, but I bet you could use it for that > purpose. > > In addition, it's possible that a reset is needed in the probe pathway. Looking at the code a bit more ... that xhci_shutdown() worries me. It basically just whacks xhci_halt() and optionally reset() but nothing is done that I can see to ensure that we aren't concurrently doing things like queuing URBs, polling the root hub etc... That's definitely not clean and while it might work (most of the time at least) on actual shutdown it's definitely not right for kexec I reckon. Now there's a separate discussion that we had a while ago and might want to resume which is to say that kexec shouldn't be calling shutdown() anyway, but instead remove() on all drivers which is a much better code path for the purpose of leaving the device in a state where a driver can reconnect to it. However, in the case of XHCI that leads to another issue described here: http://marc.info/?l=linux-usb&m=139483181809062&w=2 For which there was little / no discussion at all... I suppose we could do a quirk but I don't think the problem is fundamentally specific to the TI chip, we should probably stop both root hubs before we halt both HCDs. Cheers, Ben. -- 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] cpufreq: governor: Be friendly towards latency-sensitive bursty workloads
> > the idle time or idle residency; and the high frequency of the CPU when it > > goes > > to cpu-idle does not affect/hurt the power-savings of deep idle states). > > > > Signed-off-by: Srivatsa S. Bhat > > Reviewed-by: Gautham R. Shenoy > > Acked-by: Viresh Kumar Acked-by: Pavel Machek Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- 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 v2] ip_vti: Fix 'ip tunnel add' with 'key' parameters
ip tunnel add remote 10.2.2.1 local 10.2.2.2 mode vti ikey 1 okey 2
translates to p->iflags = VTI_ISVTI|GRE_KEY and p->i_key = 1, but GRE_KEY !=
TUNNEL_KEY, so ip_tunnel_ioctl would set i_key to 0 (same story with o_key)
making us unable to create vti tunnels with [io]key via ip tunnel.
We cannot simply translate GRE_KEY to TUNNEL_KEY (as GRE module does) because
vti_tunnels with same local/remote addresses but different ikeys will be treated
as different then. So, imo the best option here is to move p->i_flags & *_KEY
check for vti tunnels from ip_tunnel.c to ip_vti.c and to think about [io]_mark
field for ip_tunnel_parm in the future.
Signed-off-by: Dmitry Popov
---
net/ipv4/ip_tunnel.c | 10 ++
net/ipv4/ip_vti.c| 8 +++-
2 files changed, 13 insertions(+), 5 deletions(-)
diff --git a/net/ipv4/ip_tunnel.c b/net/ipv4/ip_tunnel.c
index 2acc233..0a03ad1 100644
--- a/net/ipv4/ip_tunnel.c
+++ b/net/ipv4/ip_tunnel.c
@@ -747,10 +747,12 @@ int ip_tunnel_ioctl(struct net_device *dev, struct
ip_tunnel_parm *p, int cmd)
goto done;
if (p->iph.ttl)
p->iph.frag_off |= htons(IP_DF);
- if (!(p->i_flags&TUNNEL_KEY))
- p->i_key = 0;
- if (!(p->o_flags&TUNNEL_KEY))
- p->o_key = 0;
+ if (!(p->i_flags & VTI_ISVTI)) {
+ if (!(p->i_flags & TUNNEL_KEY))
+ p->i_key = 0;
+ if (!(p->o_flags & TUNNEL_KEY))
+ p->o_key = 0;
+ }
t = ip_tunnel_find(itn, p, itn->fb_tunnel_dev->type);
diff --git a/net/ipv4/ip_vti.c b/net/ipv4/ip_vti.c
index 13ef00f..b8960f3 100644
--- a/net/ipv4/ip_vti.c
+++ b/net/ipv4/ip_vti.c
@@ -313,7 +313,13 @@ vti_tunnel_ioctl(struct net_device *dev, struct ifreq
*ifr, int cmd)
return -EINVAL;
}
- p.i_flags |= VTI_ISVTI;
+ if (!(p.i_flags & GRE_KEY))
+ p.i_key = 0;
+ if (!(p.o_flags & GRE_KEY))
+ p.o_key = 0;
+
+ p.i_flags = VTI_ISVTI;
+
err = ip_tunnel_ioctl(dev, &p, cmd);
if (err)
return err;
--
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 1/1] fs/proc/kcore.c: use PAGE_ALIGN instead of ALIGN(PAGE_SIZE)
On Sat, 7 Jun 2014, Fabian Frederick wrote: > use mm.h definition > > Cc: Andrew Morton > Cc: Xishi Qiu > Signed-off-by: Fabian Frederick Acked-by: David Rientjes -- 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: [GIT PULL] char/misc driver patches for 3.16-rc1
> At the very least, we have (CAP_SYS_ADMIN?) should be required before > allowing root to compromise kernel, no? CAP_SYS_RAWIO for anything that can compromise the kernel itself. -- 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] dns_resolver: assure that dns_query() result is null-terminated
On Sat, 7 Jun 2014, Manuel Schoelling wrote:
> > kzalloc() would be unnecessary overhead (zeroing definitely comes with a
> > cost) if you're going to copy to the memory immediately afterwards. Just
> > leave the kmalloc(), do the memcpy() and explicitly zero terminate it
> > _result.
>
> Using kzalloc() was suggested of a developer on IRC (#kernelnewbies) but
> if you prefer kmalloc, that's ok, too.
> I'll send you a corrected patch in a second.
>
Using kzalloc() here instead of kmalloc() is functionally equivalent to
if (*_result) {
memset(*_result, 0, len + 1);
memcpy(*_result, upayload->data, len);
}
so for anything with len > 1 there is an unnecessary overhead in doing
this. k?alloc() can return object sizes larger than len + 1 here as well
(usually power-of-2 sizes are supported by the slab allocator) so
depending on the value of len, you may be zeroing more memory than
copying.
Your first patch had the right idea, it's just off by one.
--
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] ip_vti: Fix 'ip tunnel add' with 'key' parameters
On Sun, 08 Jun 2014 01:55:22 +0400 Sergei Shtylyov wrote: > Please surround & with spaces for consistency; this also would follow the > general kernel coding style. > WBR, Sergei > Okay, original code was without spaces, didn't want to break this, I will resend. -- 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] dns_resolver: assure that dns_query() result is null-terminated
dns_query() credulously assumes that keys are null-terminated and returns a copy of a memory block that is off by one. Signed-off-by: Manuel Schölling --- net/dns_resolver/dns_query.c |4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/net/dns_resolver/dns_query.c b/net/dns_resolver/dns_query.c index e7b6d53..6853d22 100644 --- a/net/dns_resolver/dns_query.c +++ b/net/dns_resolver/dns_query.c @@ -149,7 +149,9 @@ int dns_query(const char *type, const char *name, size_t namelen, if (!*_result) goto put; - memcpy(*_result, upayload->data, len + 1); + memcpy(*_result, upayload->data, len); + *_result[len] = '\0'; + if (_expiry) *_expiry = rkey->expiry; -- 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/
Re: [PATCH v2] dns_resolver: assure that dns_query() result is null-terminated
On 06/08/2014 01:42 AM, David Rientjes wrote: dns_query() credulously assumes that keys are null-terminated and returns a copy of a memory block that is off by one. No sign-off? Please read Documentation/SubmittingPatches. --- net/dns_resolver/dns_query.c |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/net/dns_resolver/dns_query.c b/net/dns_resolver/dns_query.c index e7b6d53..84871a2 100644 --- a/net/dns_resolver/dns_query.c +++ b/net/dns_resolver/dns_query.c @@ -145,11 +145,11 @@ int dns_query(const char *type, const char *name, size_t namelen, len = upayload->datalen; ret = -ENOMEM; - *_result = kmalloc(len + 1, GFP_KERNEL); + *_result = kzalloc(len + 1, GFP_KERNEL); if (!*_result) goto put; - memcpy(*_result, upayload->data, len + 1); + memcpy(*_result, upayload->data, len); if (_expiry) *_expiry = rkey->expiry; kzalloc() would be unnecessary overhead (zeroing definitely comes with a cost) if you're going to copy to the memory immediately afterwards. Just leave the kmalloc(), do the memcpy() and explicitly zero terminate it _result. You can also replace kmalloc()/memcpy() with kmemdup(). WBR, Sergei -- 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 1/1] mm/slab.c: add __init to init_lock_keys
On Sat, 7 Jun 2014, Fabian Frederick wrote: > init_lock_keys is only called by __init kmem_cache_init_late > > Cc: Christoph Lameter > Cc: Andrew Morton > Signed-off-by: Fabian Frederick No functional change because these functions are inlined, but it makes sense anyway. Acked-by: David Rientjes -- 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] ip_vti: Fix 'ip tunnel add' with 'key' parameters
hello.
On 06/08/2014 01:25 AM, Dmitry Popov wrote:
ip tunnel add remote 10.2.2.1 local 10.2.2.2 mode vti ikey 1 okey 2
translates to p->iflags = VTI_ISVTI|GRE_KEY and p->i_key = 1, but GRE_KEY !=
TUNNEL_KEY, so ip_tunnel_ioctl would set i_key to 0 (same story with o_key)
making us unable to create vti tunnels with [io]key via ip tunnel.
We cannot simply translate GRE_KEY to TUNNEL_KEY (as GRE module does) because
vti_tunnels with same local/remote addresses but different ikeys will be treated
as different then. So, imo the best option here is to move p->i_flags&*_KEY
check for vti tunnels from ip_tunnel.c to ip_vti.c and to think about [io]_mark
field for ip_tunnel_parm in the future.
Signed-off-by: Dmitry Popov
---
net/ipv4/ip_tunnel.c | 10 ++
net/ipv4/ip_vti.c| 8 +++-
2 files changed, 13 insertions(+), 5 deletions(-)
diff --git a/net/ipv4/ip_tunnel.c b/net/ipv4/ip_tunnel.c
index 2acc233..0a03ad1 100644
--- a/net/ipv4/ip_tunnel.c
+++ b/net/ipv4/ip_tunnel.c
@@ -747,10 +747,12 @@ int ip_tunnel_ioctl(struct net_device *dev, struct
ip_tunnel_parm *p, int cmd)
goto done;
if (p->iph.ttl)
p->iph.frag_off |= htons(IP_DF);
- if (!(p->i_flags&TUNNEL_KEY))
- p->i_key = 0;
- if (!(p->o_flags&TUNNEL_KEY))
- p->o_key = 0;
+ if (!(p->i_flags&VTI_ISVTI)) {
+ if (!(p->i_flags&TUNNEL_KEY))
+ p->i_key = 0;
+ if (!(p->o_flags&TUNNEL_KEY))
Please surround & with spaces for consistency; this also would follow the
general kernel coding style.
[...]
WBR, Sergei
--
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] dns_resolver: assure that dns_query() result is null-terminated
On Sa, 2014-06-07 at 14:42 -0700, David Rientjes wrote: > On Sat, 7 Jun 2014, Manuel Schölling wrote: > > > dns_query() credulously assumes that keys are null-terminated and > > returns a copy of a memory block that is off by one. > > No sign-off? Please read Documentation/SubmittingPatches. It's just not my day today. Sorry, I forgot about the sign-off. > > --- > > net/dns_resolver/dns_query.c |4 ++-- > > 1 file changed, 2 insertions(+), 2 deletions(-) > > > > diff --git a/net/dns_resolver/dns_query.c b/net/dns_resolver/dns_query.c > > index e7b6d53..84871a2 100644 > > --- a/net/dns_resolver/dns_query.c > > +++ b/net/dns_resolver/dns_query.c > > @@ -145,11 +145,11 @@ int dns_query(const char *type, const char *name, > > size_t namelen, > > len = upayload->datalen; > > > > ret = -ENOMEM; > > - *_result = kmalloc(len + 1, GFP_KERNEL); > > + *_result = kzalloc(len + 1, GFP_KERNEL); > > if (!*_result) > > goto put; > > > > - memcpy(*_result, upayload->data, len + 1); > > + memcpy(*_result, upayload->data, len); > > if (_expiry) > > *_expiry = rkey->expiry; > > > > kzalloc() would be unnecessary overhead (zeroing definitely comes with a > cost) if you're going to copy to the memory immediately afterwards. Just > leave the kmalloc(), do the memcpy() and explicitly zero terminate it > _result. Using kzalloc() was suggested of a developer on IRC (#kernelnewbies) but if you prefer kmalloc, that's ok, too. I'll send you a corrected patch in a second. -- 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: [GIT PULL] x86 fixes for v3.15
On Sat, Jun 7, 2014 at 1:59 PM, H. Peter Anvin wrote: > > A significantly larger than I'd like set of patches for just below the > wire. All of these, however, fix real problems. However, if you feel > it is too scary we can do it for the merge window and rely on pushing > them into -stable. Ugh. I really don't like the timing, but the patches themselves look ok. So I ended up pulling them into my 3.15 branch, even if it's just a day before release. I'm really hoping they've gone through all the regular x86 build/boot test machinery.. Linus -- 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] mm: rmap: fix use-after-free in __put_anon_vma
On Fri, 6 Jun 2014, Andrey Ryabinin wrote: > While working address sanitizer for kernel I've discovered use-after-free > bug in __put_anon_vma. > For the last anon_vma, anon_vma->root freed before child anon_vma. > Later in anon_vma_free(anon_vma) we are referencing to already freed > anon_vma->root > to check rwsem. > This patch puts freeing of child anon_vma before freeing of anon_vma->root. > > Cc: # v3.0+ > Signed-off-by: Andrey Ryabinin Acked-by: David Rientjes -- 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] dns_resolver: assure that dns_query() result is null-terminated
On Sat, 7 Jun 2014, Manuel Schölling wrote: > dns_query() credulously assumes that keys are null-terminated and > returns a copy of a memory block that is off by one. No sign-off? Please read Documentation/SubmittingPatches. > --- > net/dns_resolver/dns_query.c |4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/net/dns_resolver/dns_query.c b/net/dns_resolver/dns_query.c > index e7b6d53..84871a2 100644 > --- a/net/dns_resolver/dns_query.c > +++ b/net/dns_resolver/dns_query.c > @@ -145,11 +145,11 @@ int dns_query(const char *type, const char *name, > size_t namelen, > len = upayload->datalen; > > ret = -ENOMEM; > - *_result = kmalloc(len + 1, GFP_KERNEL); > + *_result = kzalloc(len + 1, GFP_KERNEL); > if (!*_result) > goto put; > > - memcpy(*_result, upayload->data, len + 1); > + memcpy(*_result, upayload->data, len); > if (_expiry) > *_expiry = rkey->expiry; > kzalloc() would be unnecessary overhead (zeroing definitely comes with a cost) if you're going to copy to the memory immediately afterwards. Just leave the kmalloc(), do the memcpy() and explicitly zero terminate it _result.
Re: [RFC] Per-user namespace process accounting
On Tue, 2014-06-03 at 10:54 -0700, Eric W. Biederman wrote: > Serge Hallyn writes: > > > Quoting Pavel Emelyanov (xe...@parallels.com): > >> On 05/29/2014 07:32 PM, Serge Hallyn wrote: > >> > Quoting Marian Marinov (m...@1h.com): > >> >> We are not using NFS. We are using a shared block storage that offers > >> >> us snapshots. So provisioning new containers is > >> >> extremely cheep and fast. Comparing that with untar is comparing a race > >> >> car with Smart. Yes it can be done and no, I > >> >> do not believe we should go backwards. > >> >> > >> >> We do not share filesystems between containers, we offer them block > >> >> devices. > >> > > >> > Yes, this is a real nuisance for openstack style deployments. > >> > > >> > One nice solution to this imo would be a very thin stackable filesystem > >> > which does uid shifting, or, better yet, a non-stackable way of shifting > >> > uids at mount. > >> > >> I vote for non-stackable way too. Maybe on generic VFS level so that > >> filesystems > >> don't bother with it. From what I've seen, even simple stacking is quite a > >> challenge. > > > > Do you have any ideas for how to go about it? It seems like we'd have > > to have separate inodes per mapping for each file, which is why of > > course stacking seems "natural" here. > > > > Trying to catch the uid/gid at every kernel-userspace crossing seems > > like a design regression from the current userns approach. I suppose we > > could continue in the kuid theme and introduce a iiud/igid for the > > in-kernel inode uid/gid owners. Then allow a user privileged in some > > ns to create a new mount associated with a different mapping for any > > ids over which he is privileged. > > There is a simple solution. > > We pick the filesystems we choose to support. > We add privileged mounting in a user namespace. > We create the user and mount namespace. > Global root goes into the target mount namespace with setns and performs > the mounts. > > 90% of that work is already done. > > As long as we don't plan to support XFS (as it XFS likes to expose it's > implementation details to userspace) it should be quite straight > forward. Any implementation which doesn't support XFS is unviable from a distro point of view. The whole reason we're fighting to get USER_NS enabled in distros goes back to lack of XFS support (they basically refused to turn it on until it wasn't a choice between XFS and USER_NS). If we put them in a position where they choose a namespace feature or XFS, they'll choose XFS. XFS developers aren't unreasonable ... they'll help if we ask. I mean it was them who eventually helped us get USER_NS turned on in the first place. James -- 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] ip_vti: Fix 'ip tunnel add' with 'key' parameters
ip tunnel add remote 10.2.2.1 local 10.2.2.2 mode vti ikey 1 okey 2
translates to p->iflags = VTI_ISVTI|GRE_KEY and p->i_key = 1, but GRE_KEY !=
TUNNEL_KEY, so ip_tunnel_ioctl would set i_key to 0 (same story with o_key)
making us unable to create vti tunnels with [io]key via ip tunnel.
We cannot simply translate GRE_KEY to TUNNEL_KEY (as GRE module does) because
vti_tunnels with same local/remote addresses but different ikeys will be treated
as different then. So, imo the best option here is to move p->i_flags&*_KEY
check for vti tunnels from ip_tunnel.c to ip_vti.c and to think about [io]_mark
field for ip_tunnel_parm in the future.
Signed-off-by: Dmitry Popov
---
net/ipv4/ip_tunnel.c | 10 ++
net/ipv4/ip_vti.c| 8 +++-
2 files changed, 13 insertions(+), 5 deletions(-)
diff --git a/net/ipv4/ip_tunnel.c b/net/ipv4/ip_tunnel.c
index 2acc233..0a03ad1 100644
--- a/net/ipv4/ip_tunnel.c
+++ b/net/ipv4/ip_tunnel.c
@@ -747,10 +747,12 @@ int ip_tunnel_ioctl(struct net_device *dev, struct
ip_tunnel_parm *p, int cmd)
goto done;
if (p->iph.ttl)
p->iph.frag_off |= htons(IP_DF);
- if (!(p->i_flags&TUNNEL_KEY))
- p->i_key = 0;
- if (!(p->o_flags&TUNNEL_KEY))
- p->o_key = 0;
+ if (!(p->i_flags&VTI_ISVTI)) {
+ if (!(p->i_flags&TUNNEL_KEY))
+ p->i_key = 0;
+ if (!(p->o_flags&TUNNEL_KEY))
+ p->o_key = 0;
+ }
t = ip_tunnel_find(itn, p, itn->fb_tunnel_dev->type);
diff --git a/net/ipv4/ip_vti.c b/net/ipv4/ip_vti.c
index 13ef00f..b8960f3 100644
--- a/net/ipv4/ip_vti.c
+++ b/net/ipv4/ip_vti.c
@@ -313,7 +313,13 @@ vti_tunnel_ioctl(struct net_device *dev, struct ifreq
*ifr, int cmd)
return -EINVAL;
}
- p.i_flags |= VTI_ISVTI;
+ if (!(p.i_flags & GRE_KEY))
+ p.i_key = 0;
+ if (!(p.o_flags & GRE_KEY))
+ p.o_key = 0;
+
+ p.i_flags = VTI_ISVTI;
+
err = ip_tunnel_ioctl(dev, &p, cmd);
if (err)
return err;
--
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: Missing USB XHCI and EHCI reset for kexec
On Sat, 2014-06-07 at 11:40 -0400, Alan Stern wrote: > The current xhci-hcd driver includes a quirk flag (XHCI_SPURIOS_WAKEUP) > that causes the shutdown routine to reset the controller. It wasn't > meant for fixing kexec problems, but I bet you could use it for that > purpose. > > In addition, it's possible that a reset is needed in the probe pathway. Ok, thanks. I'll have a look. A reset in the probe means fixing distros, I'd rather find a way to fix it from the kexec path entirely, even if that involves adding a quirk on the way out to reset it in shutdown() I'll see what I can come up with that works and will come back to you. Cheers, Ben. -- 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/
[GIT PULL] x86 fixes for v3.15
Hi Linus,
A significantly larger than I'd like set of patches for just below the
wire. All of these, however, fix real problems. However, if you feel
it is too scary we can do it for the merge window and rely on pushing
them into -stable.
The one thing that is genuinely scary in here is the change of SMP
initialization, but that *does* fix a confirmed hang when booting
virtual machines.
There is also a patch to actually do the right thing about not
offlining a CPU when there are not enough interrupt vectors available
in the system; the accounting was done incorrectly. The worst case
for that patch is that we fail to offline CPUs when we should (the new
code is strictly more conservative than the old), so is not
particularly risky.
Most of the rest is minor stuff; the EFI patches are all about
exporting correct information to boot loaders and kexec.
The following changes since commit d2cfd3105094f593bc1fbd0b042a7752ddf08691:
Merge tag 'sound-3.15' of
git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound (2014-06-03 12:07:30
-0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86/urgent
for you to fetch changes up to 745c51673e289acf4d9ffc2835524de73ef923fd:
x86/boot: EFI_MIXED should not prohibit loading above 4G (2014-06-07 09:31:00
-0700)
Dave Young (2):
x86/efi: earlyprintk=efi,keep fix
x86/efi: Do not export efi runtime map in case old map
H. Peter Anvin (1):
Merge tag 'efi-urgent' into x86/urgent
Igor Mammedov (3):
x86: Fix list/memory corruption on CPU hotplug
x86/smpboot: Log error on secondary CPU wakeup failure at ERR level
x86/smpboot: Initialize secondary CPU only if master CPU will wait for it
Matt Fleming (1):
x86/boot: EFI_MIXED should not prohibit loading above 4G
Yinghai Lu (1):
x86: irq: Get correct available vectors for cpu disable
arch/x86/boot/header.S | 3 +-
arch/x86/kernel/cpu/common.c | 27 ++-
arch/x86/kernel/irq.c| 16 +--
arch/x86/kernel/smpboot.c| 104 +--
arch/x86/platform/efi/efi.c | 3 ++
5 files changed, 64 insertions(+), 89 deletions(-)
diff --git a/arch/x86/boot/header.S b/arch/x86/boot/header.S
index 0ca9a5c362bc..84c223479e3c 100644
--- a/arch/x86/boot/header.S
+++ b/arch/x86/boot/header.S
@@ -375,8 +375,7 @@ xloadflags:
# define XLF0 0
#endif
-#if defined(CONFIG_RELOCATABLE) && defined(CONFIG_X86_64) && \
- !defined(CONFIG_EFI_MIXED)
+#if defined(CONFIG_RELOCATABLE) && defined(CONFIG_X86_64)
/* kernel/boot_param/ramdisk could be loaded above 4g */
# define XLF1 XLF_CAN_BE_LOADED_ABOVE_4G
#else
diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c
index a135239badb7..a4bcbacdbe0b 100644
--- a/arch/x86/kernel/cpu/common.c
+++ b/arch/x86/kernel/cpu/common.c
@@ -1221,6 +1221,17 @@ static void dbg_restore_debug_regs(void)
#define dbg_restore_debug_regs()
#endif /* ! CONFIG_KGDB */
+static void wait_for_master_cpu(int cpu)
+{
+ /*
+* wait for ACK from master CPU before continuing
+* with AP initialization
+*/
+ WARN_ON(cpumask_test_and_set_cpu(cpu, cpu_initialized_mask));
+ while (!cpumask_test_cpu(cpu, cpu_callout_mask))
+ cpu_relax();
+}
+
/*
* cpu_init() initializes state that is per-CPU. Some data is already
* initialized (naturally) in the bootstrap process, such as the GDT
@@ -1236,16 +1247,17 @@ void cpu_init(void)
struct task_struct *me;
struct tss_struct *t;
unsigned long v;
- int cpu;
+ int cpu = stack_smp_processor_id();
int i;
+ wait_for_master_cpu(cpu);
+
/*
* Load microcode on this cpu if a valid microcode is available.
* This is early microcode loading procedure.
*/
load_ucode_ap();
- cpu = stack_smp_processor_id();
t = &per_cpu(init_tss, cpu);
oist = &per_cpu(orig_ist, cpu);
@@ -1257,9 +1269,6 @@ void cpu_init(void)
me = current;
- if (cpumask_test_and_set_cpu(cpu, cpu_initialized_mask))
- panic("CPU#%d already initialized!\n", cpu);
-
pr_debug("Initializing CPU#%d\n", cpu);
clear_in_cr4(X86_CR4_VME|X86_CR4_PVI|X86_CR4_TSD|X86_CR4_DE);
@@ -1336,13 +1345,9 @@ void cpu_init(void)
struct tss_struct *t = &per_cpu(init_tss, cpu);
struct thread_struct *thread = &curr->thread;
- show_ucode_info_early();
+ wait_for_master_cpu(cpu);
- if (cpumask_test_and_set_cpu(cpu, cpu_initialized_mask)) {
- printk(KERN_WARNING "CPU#%d already initialized!\n", cpu);
- for (;;)
- local_irq_enable();
- }
+ show_ucode_info_early();
printk(KERN_INFO "Initializing CPU#%d\n", cpu);
diff --git a/arch/x86/kernel/irq.c b/arch/x86/kernel/irq.c
i
Re: [PATCH v3] cpufreq: governor: Be friendly towards latency-sensitive bursty workloads
On Sunday, June 08, 2014 02:11:43 AM Srivatsa S. Bhat wrote: > Cpufreq governors like the ondemand governor calculate the load on the CPU > periodically by employing deferrable timers. A deferrable timer won't fire > if the CPU is completely idle (and there are no other timers to be run), in > order to avoid unnecessary wakeups and thus save CPU power. > > However, the load calculation logic is agnostic to all this, and this can > lead to the problem described below. > > > Time (ms) CPU 1 > > 100Task-A running > > 110Governor's timer fires, finds load as 100% in the last >10ms interval and increases the CPU frequency. > > 110.5 Task-A running > > 120 Governor's timer fires, finds load as 100% in the last > 10ms interval and increases the CPU frequency. > > 125 Task-A went to sleep. With nothing else to do, CPU 1 > went completely idle. > > 200 Task-A woke up and started running again. > > 200.5Governor's deferred timer (which was originally programmed > to fire at time 130) fires now. It calculates load for the > time period 120 to 200.5, and finds the load is almost zero. > Hence it decreases the CPU frequency to the minimum. > > 210 Governor's timer fires, finds load as 100% in the last > 10ms interval and increases the CPU frequency. > > > So, after the workload woke up and started running, the frequency was suddenly > dropped to absolute minimum, and after that, there was an unnecessary delay of > 10ms (sampling period) to increase the CPU frequency back to a reasonable > value. > And this pattern repeats for every wake-up-from-cpu-idle for that workload. > This can be quite undesirable for latency- or response-time sensitive bursty > workloads. So we need to fix the governor's logic to detect such wake-up-from- > cpu-idle scenarios and start the workload at a reasonably high CPU frequency. > > One extreme solution would be to fake a load of 100% in such scenarios. But > that might lead to undesirable side-effects such as frequency spikes (which > might also need voltage changes) especially if the previous frequency happened > to be very low. > > We just want to avoid the stupidity of dropping down the frequency to a > minimum > and then enduring a needless (and long) delay before ramping it up back again. > So, let us simply carry forward the previous load - that is, let us just > pretend > that the 'load' for the current time-window is the same as the load for the > previous window. That way, the frequency and voltage will continue to be set > to whatever values they were set at previously. This means that bursty > workloads > will get a chance to influence the CPU frequency at which they wake up from > cpu-idle, based on their past execution history. Thus, they might be able to > avoid suffering from slow wakeups and long response-times. > > However, we should take care not to over-do this. For example, such a "copy > previous load" logic will benefit cases like this: (where # represents busy > and . represents idle) > > ##.#.###...## > > but it will be detrimental in cases like the one shown below, because it will > retain the high frequency (copied from the previous interval) even in a mostly > idle system: > > ##.#.#.#... > > (i.e., the workload finished and the remaining tasks are such that their busy > periods are smaller than the sampling interval, which causes the timer to > always get deferred. So, this will make the copy-previous-load logic copy > the initial high load to subsequent idle periods over and over again, thus > keeping the frequency high unnecessarily). > > So, we modify this copy-previous-load logic such that it is used only once > upon every wakeup-from-idle. Thus if we have 2 consecutive idle periods, the > previous load won't get blindly copied over; cpufreq will freshly evaluate the > load in the second idle interval, thus ensuring that the system comes back to > its normal state. > > [ The right way to solve this whole problem is to teach the CPU frequency > governors to also track load on a per-task basis, not just a per-CPU basis, > and then use both the data sources intelligently to set the appropriate > frequency on the CPUs. But that involves redesigning the cpufreq subsystem, > so this patch should make the situation bearable until then. ] > > Experimental results: > +---+ > > I ran a modified version of ebizzy (called 'sleeping-ebizzy') that sleeps in > between its execution such that its total utilization can be a user-defined > value, say 10% or 20% (higher the utilization specified, lesser the amount of > sleeps injected). This ebizzy was run with a sing
[PATCH] hwmon: (ina2xx) Change register cache to signed
All devices supported by the ina2xx driver are bidirectional and reports
the measured value as a signed 16 bit, but the current driver
implementation caches the number as an u16, leading to an incorrect sign
extension when reporting to the userspace in ina2xx_get_value().
This patch fixes the problem by using a s16 instead, and has been tested
on an INA219.
Signed-off-by: Fabio Baltieri
---
drivers/hwmon/ina2xx.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/hwmon/ina2xx.c b/drivers/hwmon/ina2xx.c
index 93d26e8..d994280 100644
--- a/drivers/hwmon/ina2xx.c
+++ b/drivers/hwmon/ina2xx.c
@@ -86,7 +86,7 @@ struct ina2xx_data {
unsigned long last_updated;
int kind;
- u16 regs[INA2XX_MAX_REGISTERS];
+ s16 regs[INA2XX_MAX_REGISTERS];
};
static const struct ina2xx_config ina2xx_config[] = {
--
1.8.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/
[PATCH v3] cpufreq: governor: Be friendly towards latency-sensitive bursty workloads
Cpufreq governors like the ondemand governor calculate the load on the CPU periodically by employing deferrable timers. A deferrable timer won't fire if the CPU is completely idle (and there are no other timers to be run), in order to avoid unnecessary wakeups and thus save CPU power. However, the load calculation logic is agnostic to all this, and this can lead to the problem described below. Time (ms) CPU 1 100Task-A running 110Governor's timer fires, finds load as 100% in the last 10ms interval and increases the CPU frequency. 110.5 Task-A running 120Governor's timer fires, finds load as 100% in the last 10ms interval and increases the CPU frequency. 125Task-A went to sleep. With nothing else to do, CPU 1 went completely idle. 200Task-A woke up and started running again. 200.5 Governor's deferred timer (which was originally programmed to fire at time 130) fires now. It calculates load for the time period 120 to 200.5, and finds the load is almost zero. Hence it decreases the CPU frequency to the minimum. 210Governor's timer fires, finds load as 100% in the last 10ms interval and increases the CPU frequency. So, after the workload woke up and started running, the frequency was suddenly dropped to absolute minimum, and after that, there was an unnecessary delay of 10ms (sampling period) to increase the CPU frequency back to a reasonable value. And this pattern repeats for every wake-up-from-cpu-idle for that workload. This can be quite undesirable for latency- or response-time sensitive bursty workloads. So we need to fix the governor's logic to detect such wake-up-from- cpu-idle scenarios and start the workload at a reasonably high CPU frequency. One extreme solution would be to fake a load of 100% in such scenarios. But that might lead to undesirable side-effects such as frequency spikes (which might also need voltage changes) especially if the previous frequency happened to be very low. We just want to avoid the stupidity of dropping down the frequency to a minimum and then enduring a needless (and long) delay before ramping it up back again. So, let us simply carry forward the previous load - that is, let us just pretend that the 'load' for the current time-window is the same as the load for the previous window. That way, the frequency and voltage will continue to be set to whatever values they were set at previously. This means that bursty workloads will get a chance to influence the CPU frequency at which they wake up from cpu-idle, based on their past execution history. Thus, they might be able to avoid suffering from slow wakeups and long response-times. However, we should take care not to over-do this. For example, such a "copy previous load" logic will benefit cases like this: (where # represents busy and . represents idle) ##.#.###...## but it will be detrimental in cases like the one shown below, because it will retain the high frequency (copied from the previous interval) even in a mostly idle system: ##.#.#.#... (i.e., the workload finished and the remaining tasks are such that their busy periods are smaller than the sampling interval, which causes the timer to always get deferred. So, this will make the copy-previous-load logic copy the initial high load to subsequent idle periods over and over again, thus keeping the frequency high unnecessarily). So, we modify this copy-previous-load logic such that it is used only once upon every wakeup-from-idle. Thus if we have 2 consecutive idle periods, the previous load won't get blindly copied over; cpufreq will freshly evaluate the load in the second idle interval, thus ensuring that the system comes back to its normal state. [ The right way to solve this whole problem is to teach the CPU frequency governors to also track load on a per-task basis, not just a per-CPU basis, and then use both the data sources intelligently to set the appropriate frequency on the CPUs. But that involves redesigning the cpufreq subsystem, so this patch should make the situation bearable until then. ] Experimental results: +---+ I ran a modified version of ebizzy (called 'sleeping-ebizzy') that sleeps in between its execution such that its total utilization can be a user-defined value, say 10% or 20% (higher the utilization specified, lesser the amount of sleeps injected). This ebizzy was run with a single-thread, tied to CPU 8. Behavior observed with tracing (sample taken from 40% utilization runs): Without patch: ~~ kworker/8:2-12137 416.335742: cpu_fr
Re: net: netlink executing RO memory
On Sat, 7 Jun 2014, Thomas Gleixner wrote:
> On Sat, 7 Jun 2014, Sasha Levin wrote:
> So one thing which might give us at least some data is the debug patch
> below. With CONFIG_STACKTRACE enabled and
>
> # echo 1 >/sys/kernel/debug/tracing/options/stacktrace
>
> we should get a recording of rcu_free() calls along with the
> stacktrace for each. So we should be able to see which code path
> actually queued the thing. Maybe that's enough of an hint, but at
> least it gives us an idea which code path to instrument further.
This one is better..
Thanks,
tglx
-
diff --git a/kernel/rcu/tree_plugin.h b/kernel/rcu/tree_plugin.h
index 962d1d5..7241235 100644
--- a/kernel/rcu/tree_plugin.h
+++ b/kernel/rcu/tree_plugin.h
@@ -698,6 +698,7 @@ EXPORT_SYMBOL_GPL(call_rcu);
void kfree_call_rcu(struct rcu_head *head,
void (*func)(struct rcu_head *rcu))
{
+ trace_printk("head: %p func: %pS\n", head, func);
__call_rcu(head, func, &rcu_preempt_state, -1, 1);
}
EXPORT_SYMBOL_GPL(kfree_call_rcu);
@@ -1091,6 +1092,7 @@ static void rcu_preempt_check_callbacks(int cpu)
void kfree_call_rcu(struct rcu_head *head,
void (*func)(struct rcu_head *rcu))
{
+ trace_printk("head: %p func: %pS\n", head, func);
__call_rcu(head, func, &rcu_sched_state, -1, 1);
}
EXPORT_SYMBOL_GPL(kfree_call_rcu);
diff --git a/lib/debugobjects.c b/lib/debugobjects.c
index e0731c3..fd5cafd 100644
--- a/lib/debugobjects.c
+++ b/lib/debugobjects.c
@@ -693,6 +693,9 @@ repeat:
switch (obj->state) {
case ODEBUG_STATE_ACTIVE:
+ trace_printk("free %p obj %p\n", address,
+obj->object);
+ tracing_off();
debug_print_object(obj, "free");
descr = obj->descr;
state = obj->state;
--
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: net: netlink executing RO memory
On Sat, 7 Jun 2014, Sasha Levin wrote:
> On 06/06/2014 01:45 AM, Sasha Levin wrote:
> > On 06/05/2014 04:21 PM, Sasha Levin wrote:
> >> Hi all,
> >>
> >> While fuzzing with trinity inside a KVM tools guest running the latest
> >> -next
> >> kernel I've stumbled on the following spew:
> >>
> >> [ 306.065161] kernel tried to execute NX-protected page - exploit
> >> attempt? (uid: 0)
> >> [ 306.067295] BUG: unable to handle kernel paging request at
> >> 880053b8fd08
> >
> > Same issue reproduced multiple times with exactly the same trace, so I
> > think that it
> > rules out random memory corruption.
>
> I might have another lead of this: I caught debug objects complaining about
> freeing
> active objects:
>
> [ 592.020501] ODEBUG: free active (active state 1) object type: rcu_head
> hint: (null)
So something in the memory which is freed is queued in rcu. state 1:
STATE_RCU_HEAD_QUEUED. But why is that rcu_head in the vmalloced skb
memory?
That's going to be a nice puzzle to find the culprit.
So one thing which might give us at least some data is the debug patch
below. With CONFIG_STACKTRACE enabled and
# echo 1 >/sys/kernel/debug/tracing/options/stacktrace
we should get a recording of rcu_free() calls along with the
stacktrace for each. So we should be able to see which code path
actually queued the thing. Maybe that's enough of an hint, but at
least it gives us an idea which code path to instrument further.
Thanks,
tglx
-
diff --git a/kernel/rcu/tree_plugin.h b/kernel/rcu/tree_plugin.h
index 962d1d5..7241235 100644
--- a/kernel/rcu/tree_plugin.h
+++ b/kernel/rcu/tree_plugin.h
@@ -698,6 +698,7 @@ EXPORT_SYMBOL_GPL(call_rcu);
void kfree_call_rcu(struct rcu_head *head,
void (*func)(struct rcu_head *rcu))
{
+ trace_printk("head: %p func: %pS\n", head, func);
__call_rcu(head, func, &rcu_preempt_state, -1, 1);
}
EXPORT_SYMBOL_GPL(kfree_call_rcu);
@@ -1091,6 +1092,7 @@ static void rcu_preempt_check_callbacks(int cpu)
void kfree_call_rcu(struct rcu_head *head,
void (*func)(struct rcu_head *rcu))
{
+ trace_printk("head: %p func: %pS\n", head, func);
__call_rcu(head, func, &rcu_sched_state, -1, 1);
}
EXPORT_SYMBOL_GPL(kfree_call_rcu);
diff --git a/lib/debugobjects.c b/lib/debugobjects.c
index e0731c3..7610834 100644
--- a/lib/debugobjects.c
+++ b/lib/debugobjects.c
@@ -252,8 +252,9 @@ static void debug_print_object(struct debug_obj *obj, char
*msg)
if (limit < 5 && descr != descr_test) {
void *hint = descr->debug_hint ?
- descr->debug_hint(obj->object) : NULL;
+ descr->debug_hint(obj->object) : obj->object;
limit++;
+ tracing_off();
WARN(1, KERN_ERR "ODEBUG: %s %s (active state %u) "
"object type: %s hint: %pS\n",
msg, obj_states[obj->state], obj->astate,
--
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: 3.12.9 kern.log spam from vgaswitcheroo
cc'ing list On 8 June 2014 04:08, Howard Chu wrote: > On Asus NP56D, if you use vgaswitcheroo to turn off the discrete GPU, the > kernel starts spewing these messages endlessly, until /var/log partition > fills up: > > Jun 7 17:40:27 gamba kernel: [470008.702322] [drm:radeon_cs_parser_init] > *ERROR* VM not ac > tive on asic! > Jun 7 17:40:27 gamba kernel: [470008.702325] [drm:radeon_cs_ioctl] *ERROR* > Failed to initi > alize parser ! > Jun 7 17:40:27 gamba kernel: [470008.702385] [drm:radeon_cs_parser_init] > *ERROR* VM not ac > tive on asic! > Jun 7 17:40:27 gamba kernel: [470008.702389] [drm:radeon_cs_ioctl] *ERROR* > Failed to initi > alize parser ! > > Turning the discrete GPU back on stops the stream of messages. > -- > -- Howard Chu > CTO, Symas Corp. http://www.symas.com > Director, Highland Sun http://highlandsun.com/hyc/ > Chief Architect, OpenLDAP http://www.openldap.org/project/ > -- > 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 1/1] mm/slab.c: add __init to init_lock_keys
On Sat, 7 Jun 2014, Fabian Frederick wrote: > init_lock_keys is only called by __init kmem_cache_init_late Acked-by: Christoph Lameter -- 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] staging: tidspbridge: pmgr: dspapi.c: Cleaning up uninitialized variable
On Wed, Jun 04, 2014 at 12:23:39AM +0200, Rickard Strandqvist wrote: > There is a risk that the variables will be used without being initialized. > Has also improved error handling, after an email proposal from Dan Carpenter. > > Signed-off-by: Rickard Strandqvist Looks ok. This fixes some information leak bugs. Thanks. regards, dan carpenter -- 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/
[GIT PULL] LLVMLinux patches for v3.16
Linus, Next set of patches to support compiling the kernel with clang. They've been soaking in linux-next since the last merge window. More still in the works for the next merge window... Thanks, Behan -- Behan Webster beh...@converseincode.com The following changes since commit d4c54919ed86302094c0ca7d48a8cbd4ee753e92: mm: add !pte_present() check on existing hugetlb_entry callbacks (2014-06-06 13:21:16 -0700) are available in the git repository at: git://git.linuxfoundation.org/llvmlinux/kernel.git tags/llvmlinux-for-v3.16 for you to fetch changes up to e6b80757700a11315dd81b161f8d86099214c185: arm, unwind, LLVMLinux: Enable clang to be used for unwinding the stack (2014-06-07 11:44:39 -0700) LLVMLinux patches for v3.16 Behan Webster (2): all: LLVMLinux: Change DWARF flag to support gcc and clang ARM: LLVMLinux: Change "extern inline" to "static inline" in glue-cache.h Mark Charlebois (3): crypto: LLVMLinux: aligned-attribute.patch net: netfilter: LLVMLinux: vlais-netfilter arm, unwind, LLVMLinux: Enable clang to be used for unwinding the stack Makefile | 2 +- arch/arm/include/asm/glue-cache.h | 22 +++--- arch/arm/kernel/unwind.c | 2 +- crypto/shash.c| 3 ++- net/netfilter/xt_repldata.h | 22 +- 5 files changed, 32 insertions(+), 19 deletions(-) -- 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 v2] dns_resolver: assure that dns_query() result is null-terminated
dns_query() credulously assumes that keys are null-terminated and returns a copy of a memory block that is off by one. --- net/dns_resolver/dns_query.c |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/net/dns_resolver/dns_query.c b/net/dns_resolver/dns_query.c index e7b6d53..84871a2 100644 --- a/net/dns_resolver/dns_query.c +++ b/net/dns_resolver/dns_query.c @@ -145,11 +145,11 @@ int dns_query(const char *type, const char *name, size_t namelen, len = upayload->datalen; ret = -ENOMEM; - *_result = kmalloc(len + 1, GFP_KERNEL); + *_result = kzalloc(len + 1, GFP_KERNEL); if (!*_result) goto put; - memcpy(*_result, upayload->data, len + 1); + memcpy(*_result, upayload->data, len); if (_expiry) *_expiry = rkey->expiry; -- 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/
Re: [PATCH] dns_resolver: assure that dns_query() result is null-terminated
LOL, that was stupid! Sorry, I'll send a corrected version in a second... On Sa, 2014-06-07 at 14:54 -0400, Trond Myklebust wrote: > On Sat, Jun 7, 2014 at 1:56 PM, Manuel Schölling > wrote: > > dns_query() credulously assumes that keys are null-terminated and > > returns a copy of a memory block that is off by one. > > --- > > net/dns_resolver/dns_query.c |4 +++- > > 1 file changed, 3 insertions(+), 1 deletion(-) > > > > diff --git a/net/dns_resolver/dns_query.c b/net/dns_resolver/dns_query.c > > index e7b6d53..53be635 100644 > > --- a/net/dns_resolver/dns_query.c > > +++ b/net/dns_resolver/dns_query.c > > @@ -149,7 +149,9 @@ int dns_query(const char *type, const char *name, > > size_t namelen, > > if (!*_result) > > goto put; > > > > - memcpy(*_result, upayload->data, len + 1); > > + memcpy(*_result, upayload->data, len); > > + *_result[len+1] = '\0'; > > Off by one... > > > + > > if (_expiry) > > *_expiry = rkey->expiry; > > > > -- > > 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/ > > > -- 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] dns_resolver: assure that dns_query() result is null-terminated
On Sat, Jun 7, 2014 at 1:56 PM, Manuel Schölling wrote: > dns_query() credulously assumes that keys are null-terminated and > returns a copy of a memory block that is off by one. > --- > net/dns_resolver/dns_query.c |4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > > diff --git a/net/dns_resolver/dns_query.c b/net/dns_resolver/dns_query.c > index e7b6d53..53be635 100644 > --- a/net/dns_resolver/dns_query.c > +++ b/net/dns_resolver/dns_query.c > @@ -149,7 +149,9 @@ int dns_query(const char *type, const char *name, size_t > namelen, > if (!*_result) > goto put; > > - memcpy(*_result, upayload->data, len + 1); > + memcpy(*_result, upayload->data, len); > + *_result[len+1] = '\0'; Off by one... > + > if (_expiry) > *_expiry = rkey->expiry; > > -- > 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/ -- Trond Myklebust Linux NFS client maintainer, PrimaryData trond.mykleb...@primarydata.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/
3.12.9 kern.log spam from vgaswitcheroo
On Asus NP56D, if you use vgaswitcheroo to turn off the discrete GPU, the kernel starts spewing these messages endlessly, until /var/log partition fills up: Jun 7 17:40:27 gamba kernel: [470008.702322] [drm:radeon_cs_parser_init] *ERROR* VM not ac tive on asic! Jun 7 17:40:27 gamba kernel: [470008.702325] [drm:radeon_cs_ioctl] *ERROR* Failed to initi alize parser ! Jun 7 17:40:27 gamba kernel: [470008.702385] [drm:radeon_cs_parser_init] *ERROR* VM not ac tive on asic! Jun 7 17:40:27 gamba kernel: [470008.702389] [drm:radeon_cs_ioctl] *ERROR* Failed to initi alize parser ! Turning the discrete GPU back on stops the stream of messages. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ -- 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/
[no subject]
¡¶³É¹¦µÄ²úÆ·¾Àí¡ª¡ª²úÆ·¾ÀíµÄÒ°Âù³É³¤¡· ¡¾Ö÷½²£ºCharles¡¿ ±¨ÃûÏêÇé > ¡¾Åàѵʱ¼ä¡¿2014Äê6ÔÂ23-24ÈÕÉϺ£¡¢6ÔÂ26-27ÈÕÉîÛÚ¡¢6ÔÂ30-7ÔÂ1ÈÕ±±¾© ¡¾Åàѵ¶ÔÏó¡¿ÆóÒµCEO/×ܾÀí¡¢Ñз¢×ܾÀí/¸±×Ü¡¢¹«Ë¾×ܹ¤/¼¼Êõ×ܼࡢ¹«Ë¾ÈËÁ¦×ÊÔ´×ܼࡢ²úÆ·Ïß×Ü ¼à¡¢²úÆ·¾Àí/ÏîÄ¿¾Àí¡¢PMO£¨ÏîÄ¿¹ÜÀí°ì¹«ÊÒ£©³ÉÔ±¡¢Êг¡×ܼࡢ¼¼ÊõÖ§³Ö×ܼàµÈ¡£ ¡¾Êڿη½Ê½¡¿°¸Àý·ÖÏí¡¢ÊµÎñ·ÖÎö¡¢»¥¶¯ÌÖÂÛ¡¢ÏîÄ¿Ä£Äâ¡¢ÅàѵÓÎÏ· ¡¾Åàѵ·ÑÓá¿4300Ôª/2Ìì/2ÈË ,µ¥¶ÀÒ»ÈËÊÕ·Ñ2800Ôª ¡¾³Ð°ìµ¥Î»¡¿Óî ½Ü Æó ¹Ü ¡¾±¨ÃûÈÈÏß¡¿Éî ÛÚ£º07 55-6 1282 360 ÉÏ º£: 02 1-51 602 030 ±± ¾©£º010-516 69 310 ¡¾Q QÔÚÏß¡¿ 5117 983 37 ¿Î³Ì¼ò½é > ¡¾¿Î³Ì±³¾°¡¿ ÔÚΪ¹úÄںܶà¿Æ¼¼ÆóÒµ·þÎñµÄ¹ý³ÌÖУ¬·¢ÏÖÆóÒµÖÐÆÕ±é´æÔÚÈçÏÂÎÊÌ⣺ *²úÆ·¿ª·¢±ÕÃÅÔì³µ£¬Ö»¹Ø×¢¼¼Êõ£¬²»¹Ø×¢¿Í»§£¬Ñз¢´ÓÔçæµ½Íí£¬²úÆ·¿ª·¢µÄ²»ÉÙ£¬µ«×¬Ç®µÄ²úÆ· ÇüÖ¸¿ÉÊý *²úÆ·¿ª·¢³öÀ´²ÅÕÒ¿Í»§¡¢ÕÒÂôµã£¬ÏúÊÛÈËÔ±±¨Ô¹ÎÒÃǵIJúÆ·´ÓÄïÌ¥ÖгöÀ´¾ÍÌÉÔÚµ£¼ÜÉÏ£¬²úƷûÓÐ ÓÅÊÆ£¬Ò²²»ÖªµÀ¾ºÕù¶ÔÊÖ²úÆ·µÄÈõµã£¬µ«ÎÒÃDzúÆ·µÄÈõµãÍùÍù±»¶ÔÊÖץס *¼¸ºõûÓвúƷ·±êµÄ¹æ»®£¬Óй滮ҲÖ÷ÒªÊǼ¼ÊõÇý¶¯£¬¿Í»§ÐèÇóµ½²»Á˹滮ÈËÔ±ÊÖÖУ¬¹«Ë¾Éñ¾Ä© ÉÒÓë´óÄÔʧȥÁªÏµ *Á˽âÊг¡µÄ²»¶®¼¼Êõ£¬¶®¼¼ÊõµÄ²»Á˽âÊг¡£¬²»ÖªµÀÐèÇóÓ¦¸Ã˸ºÔð£¬È±ÉÙÍ걸µÄÐèÇóÊÕ¼¯¡¢»ã×Ü ·ÖÎö»úÖÆ *°ÑÏúÊÛÇý¶¯ÎóÒÔΪÊÇÊг¡Çý¶¯£¬ÏúÊÛÈËÔ±·´À¡µÄÐèÇóÍùÍùÊǶÌÆÚÐÐΪ¡¢¶øÇҺܸöÐÔ»¯£¬Ñз¢×ÜÊDZ»¡¡ ÕâЩ¶Ìƽ¿ìµÄ¸öÐÔ»¯ÐèÇóÇý¶¯µÄÍÅÍÅת£¬»¹±»ÀÏ°åÂî¡°ÄãÃÇÕâ°ï±¿µ°£¬Ôõô¸ã²»³ö¼¸¸öÈÍ·²úÆ·³ö À´£¿¡±¡¡ µ±Ò»¸öÆóÒµ´Óµ¥Ò»²úÆ·ÏßÏò¶à²úÆ·Ïß¿çÔ½µÄʱºò£¬±ØÐëÍ»ÆƵÄÒ»¸öÆ¿¾±¾ÍÊǹ«Ë¾²úÆ·¾ÀíµÄÅàÑø£¬ ÒòΪ²úÆ·¾ÀíÊǹ«Ë¾¼ÛÖµÁ´ÖÐ×îÖØÒªµÄÒ»¸ö»·½Ú£¬ÊÇÖ±½ÓÃæÏò¿Í»§¡¢´øÁìÍŶӴ´Ôì¼ÛÖµµÄÁì¾üÈËÎ Òò´Ë²úÆ·¾Àí¸öÈ˼°ÆäËùÂÊÁìµÄÍŶӵÄÄÜÁ¦ÍùÍù¾ö¶¨Á˸òúÆ·ÔÚÊг¡ÉϵľºÕùÁ¦¡£È»¶ø£¬ºÜ¶à·¢Õ¹ÖÐ µÄÆóÒµÔÚ¹¹½¨²úÆ·¹ÜÀíÌåϵºÍÅàÑø²úÆ·¾ÀíµÄ¹ý³ÌÖÐÈ´ÃæÁٺܶàÀ§»ó£¬±ÈÈ磺 1.²úÆ·¾Àí¸ÃÈçºÎ¶¨Î»£¿ÆäÖ°ÔðÊÇʲô£¿ 2.²úÆ·¾ÀíÐèÒª¾ß±¸Ê²Ã´ÑùµÄÄÜÁ¦£¿ÈçºÎÅàÑø£¿ 3.ÈçºÎÓë¿Í»§ÓÐЧ¹µÍ¨£¬´Ó¶ø·¢¾ò¿Í»§µÄÒþÐÔÐèÇó£¿ 4.ÈçºÎ´Ó´óÁ¿µÄÐèÇóÐÅÏ¢ÖÐÌáÁ¶³öºËÐĵĿͻ§ÐèÇó£¿ 5.ÈçºÎ²ß»®ÓоºÕùÁ¦µÄ²îÒ컯²úÆ·£¿ 6.ÈçºÎÈ·±£²ß»®µÄºËÐÄÐèÇóÔÚ¿ª·¢¹ý³ÌÖб»³ä·ÖʵÏÖ£¿ 7.ÈçºÎ°ÑвúÆ·³É¹¦µÄÍÆÏòÊг¡£¿ 8.ÈçºÎ±ÜÃâ²úÆ·¾ÀíÂÙÂä³É¡°ÎÊÌâ¾Àí¡±£¿ 9.ÈçºÎʵÏÖ²úÆ·¾Àí´Ó¡°µ¥Ìô¡±Ä£Ê½Ïò¡°´òȺ¼Ü¡±Ä£Ê½µÄת±ä£¿ 10.ÈçºÎ¹¹½¨ÊʺϲúÆ·¾Àí³É³¤µÄÓÅÁ¼ÍÁÈÀ£¿ ¡¡ »ùÓÚÒÔÉϵäÐÍÎÊÌ⣬ÎÒÃǽáºÏ´óÁ¿µÄÅàѵºÍ×Éѯ°¸Àý£¬²¢²»¶Ï×ܽᣬ´Ó¶øÍƳö¸Ã¿Î³Ì£¬°¸Àý¡¢Ä£°å¡¢ ¾Ñé¡¢½Ìѵ¡¢Ñ§Ô±·ÖÏíµÈ¹á´©È«¿Î³Ì¡£ ¡¾ÅàѵÊÕÒæ¡¿ 1.Á˽â²úÆ·¾Àí²úÉúµÄ±³¾°¡¢Ê±»ú 2.Á˽ⲻͬʱÆÚ¡¢²»Í¬ÐÐÒµµÄ²úÆ·¾Àí¶¨Î»¡¢Ö°Ôð¡¢ËØÖÊ¡¢ÄÜÁ¦ÒªÇó 3.Àí½â²úÆ·¾Àí¡¢ÏîÄ¿¾Àí¡¢Êг¡¾ÀíµÄ¹Ø¼üÇø±ðÒÔ¼°ÏàÓ¦µÄ×éÖ¯ÔË×÷ 4.Àí½â²úÆ·¾ÀíµÄºËÐÄÄÜÁ¦ÊÇÈçºÎÕÛÌÚ³öÀ´µÄ 5.ÕÆÎÕÈçºÎ²ÅÄܳÖÐø²ß»®³öÓоºÕùÁ¦µÄ²úÆ·µÄ·½·¨ 6.ÕÆÎÕ²úÆ·¾ÀíÈçºÎÓÐЧµÄ¼à¹Ü²úÆ·¿ª·¢¹ý³Ì¶ø²»ÐèÒª¹ý¶ÈÏÝÈëµÄ·½·¨ 7.ÕÆÎÕвúÆ·ÉÏÊйÜÀíµÄ·½·¨£¬È·±£ÓªÏúÍŶÓ˳Àû½ÓÊÖвúÆ·µÄÏúÊÛ 8.ÕÆÎÕ²úÆ·ÉúÃüÖÜÆÚ¹ÜÀíµÄ»ù±¾·½·¨ºÍ¾ö²ß»úÖÆ£¬°ÑÂö²úÆ·µÄÍËÊÐʱ»ú 9.Á˽âÒµ½çÈçºÎÅàÑø²úÆ·¾ÀíµÄ·½·¨ 10.·ÖÏí½²Ê¦£µ0¶à¸ö×ÉѯÏîÄ¿µÄ²úÆ·¹ÜÀíºÍ²úÆ·¾Àí¶ÓÎ齨ÉèµÄ°¸Àý×ÊÁÏ£¨Á÷³Ì¡¢Öƶȡ¢Ä£°å¡¢ÑùÀý¡¡£© µ¼Ê¦¼ò½é >¡¾Charles¡¿ Ñз¢¹ÜÀí×Éѯ×ÊÉî¹ËÎÊ ¹ú¼Ò·¢¸Äί´´Ð¹ÜÀíÅàѵÖÐÐÄÌØÑû½²Ê¦ Ç廪´óѧ¹ú¼Ê¹¤³ÌÏîÄ¿¹ÜÀíÑо¿ÔºÌØÑû½²Ê¦ ¡¾×¨Òµ±³¾°¡¿ 16ÄêµÄ¸ß¿Æ¼¼ÆóÒµ´ÓÒµ±³¾°£¬¾ßÓзḻµÄ²úÆ·²ß»®¡¢²úÆ·Ñз¢¡¢²úÆ·ÖÐÊÔ¡¢²úÆ··þÎñµÈÁìÓòµÄʵ ¼ùÓë¹ÜÀí¾Ñé¡£´Óʹý²úÆ·Éè¼ÆÓ뿪·¢¡¢NPI¡¢ÏîÄ¿¾Àí¡¢²úÆ·¾Àí¡¢Ñз¢¹ÜÀí²¿¾Àí¡¢ÆóÒµ¹ÜÀí¹ËÎÊ µÈÖ°Îñ£» ÔøÔÚ¹úÄÚijÖøÃûͨÐÅÉ豸¹«Ë¾¹¤×÷¹ý£·Ä꣨97¡«04£©£¬ÆÚ¼äÓë¹ú¼Ê¶¥¼â×Éѯ¹ËÎÊÒ»Æð¹¤×÷£¬×÷Ϊ ºËÐijÉԱȫ³Ì²ÎÓëÍƶ¯¸Ã¹«Ë¾Ñз¢¹ÜÀíÌåϵµÄ±ä¸ï¹¤×÷£¬²¢×÷Ϊ²úÆ·¾ÀíÖ÷µ¼ÁËij²úÆ·Ï߶à¸ö´óÐÍÏî Ä¿µÄ²úÆ·Éè¼Æ¡¢¿ª·¢¡¢ÖÐÊÔ¡¢×ª²úÓëÉÏÊй¤×÷¡£ ¡¾Ñз¢¹ÜÀí×Éѯ¾Ñé¡¿ 7ÄêµÄÑз¢¹ÜÀí×Éѯ¾Ñ飬Ö÷µ¼ÁË20¶à¸öÑз¢¹ÜÀí×ÉѯÏîÄ¿£¬ÏîÄ¿·¶Î§Éæ¼°µ½Êг¡ÐèÇó¡¢²úÆ·¹æ»®¡¢²ú Æ·¿ª·¢¡¢²úÆ·¾ö²ß¡¢¼¼ÊõÆÀÉó¡¢¼¼Êõ¿ª·¢¡¢Ñз¢×éÖ¯¡¢Ñз¢¼¨Ð§¡¢¼¼ÊõÈÎÖ°×ʸñ¡¢ÏîÄ¿¹ÜÀí¡¢±ä¸ü¹Ü Àí¡¢ÖªÊ¶¹ÜÀí¡¢Ñз¢IT¹æ»®µÈÁìÓò¡£µäÐÍ¿Í»§ÈçÏ£º 1)¿Æ´ïͨÐÅ 2)OPPO 3)TCL¼ÒÍøÊÂÒµ²¿ 4)ËÕÖݽðÁú 5)ÓîͨÖع¤ 6)¾©Ðż¯ÍÅ 7)¸£½¨ÃôѶ 8)Öе缯ÍÅij¾üÆ·Ñо¿Ëù ¡¾Ñз¢¹ÜÀíÅàѵ¾Ñé¡¿ ÔøΪÖйú¿Õ¼ä¼¼ÊõÑо¿Ôº¡¢ÄÏÈð¿Æ¼¼¡¢TCL¼¯ÍÅ¡¢³¤ºç¼¯ÍÅ¡¢OPPO¡¢Í¬·½ÍþÊÓ¡¢±¦¸Ö¼¯ÍÅ¡¢ÖйúÒƶ¯¡¢ ´óÌƵçÐÅ¡¢ÉϺ£µçÐÅ¡¢É¹ļ¯ÍÅ¡¢¿Æ´ïͨÐÅ¡¢Öе缯ÍÅ¡¢Íþ´´¿Æ¼¼
Re: Interactivity regression since v3.11 in mm/vmscan.c
So we very recently (as in this merge window) merged a change to this very area, but that change was very specific to one case. Hillf's patch (below) apparently fixes the problem Felipe sees, and I have to say, his problem sounds a *lot* like the kind of horrible performance I've seen with writing to USB devices. I blamed non-working per-bdi throttling, but this implies it is more generic than that. The fact that the very same code also made nfsd very unhappy makes me think that the code is just fundamentally broken. And quite frankly, the whole logic is a bit questionable. That "nr_unqueued_dirty == nr_taken" test is claimed to be "implies that flushers are not keeping up", but that's not actually true at all. It just means that (a) all the pages we isolated are dirty (b) .. and none of them are under writeback and it's very possible that none of them are under writeback because nobody has even decided to start writeback on them yet, because nobody has even walked through the list yet, so they were all still marked as referenced. I guess you could say that "flushers are not keeping up", but *we're* one of the flushers, and it's not that we aren't keeping up, it's that we haven't even scanned things yet. So what do we do when we haven't scanned the list enough to see any non-referenced pages? Do we scan it a bit more? No. We decide to congestion-wait. That sounds completely and utterly stupid and broken. Does it make any sense at all? No it doesn't. It just seems to delay starting any writeback at all. I suspect the code comes from "let's not spend too much time scanning the dirty lists when everything is dirty", and is trying to avoid CPU use. But what it seems to do is actually to avoid even starting writeback in the first place, and just "congestion-waiting" even when nothing is being written back (here "nothing" is not absolute - we're only looking at a part of the dirty pages, obviously, but we're looking at the *old* dirty pages, so it's a fairly important part of it). So I really get the feeling that this code is broken, and that the patch to remove that "nr_unqueued_dirty == nr_taken" is correct. In particular, doesn't that congestion wait - which is supposed to wait for kswapd - end up waiting even when the process in question *is* kswapd? So it's not just processes like nfsd that got throttled down (which no longer happens because of the recent commit 399ba0b95670), it seems like kswapd itself gets throttled down because of this test. So at the *very* least I feel like the new current_may_throttle() needs to say that "kswapd must not be throttled", but I wonder if that whole thing just needs to go. And maybe that recent commit 399ba0b95670 is actually broken, and wanted to fix just this part too. Maybe it *should* wait for the "nr_immediate" case, which is the one that is currently aimed at *only* throttling down kswapd itself. Maybe we should remove the "current_is_kswapd()" test in the nr_immediate code instead, and make everybody throttle when they hit the actual _real_ congestion case of the whole zone being under writeback? Comments? Mel, this code is mostly attributed to you, I'd like to hear what you think in particular. Linus On Sat, Jun 7, 2014 at 5:35 AM, wrote: > > The comments around the congestion_wait, > [1] > * > * Once a zone is flagged ZONE_WRITEBACK, kswapd will count the number > * of pages under pages flagged for immediate reclaim and stall if any > * are encountered in the nr_immediate check below. > */ > if (nr_writeback && nr_writeback == nr_taken) > zone_set_flag(zone, ZONE_WRITEBACK); > > > [2] > /* > * If dirty pages are scanned that are not queued for IO, it > * implies that flushers are not keeping up. In this case, > flag > * the zone ZONE_TAIL_LRU_DIRTY and kswapd will start writing > * pages from reclaim context. It will forcibly stall in the > * next check. > */ > if (nr_unqueued_dirty == nr_taken) > zone_set_flag(zone, ZONE_TAIL_LRU_DIRTY); > > The "force stall" in [2] conflicts with "start writing pages" in [2], and > conflicts with "nr_immediate check below" in [1] as well, IIUC. > > Would you please try again based only on comment [1](based on v3.15-rc8)? > thanks > Hillf > > --- a/mm/vmscan.c Sat Jun 7 18:38:08 2014 > +++ b/mm/vmscan.c Sat Jun 7 20:08:36 2014 > @@ -1566,7 +1566,7 @@ shrink_inactive_list(unsigned long nr_to > * implies that pages are cycling through the LRU faster than > * they are written so also forcibly stall. > */ > - if (nr_unqueued_dirty == nr_taken || nr_immediate) > + if (nr_immediate) > congestion_wait(BLK_RW_ASYNC, HZ/10); > } > > -- -- To unsubs
Re: [PATCH 1/2] ARM: zynq: DT: Add XADC node
On 06/05/2014 06:05 PM, Soren Brinkmann wrote: > Add node for the Xilinx A/D Converter. > > Cc: Lars-Peter Clausen > Signed-off-by: Soren Brinkmann > --- > arch/arm/boot/dts/zynq-7000.dtsi | 8 > 1 file changed, 8 insertions(+) Applied to zynq/dt branch. Thanks, Michal -- 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] ARM: multi_v7_defconfig: Enable XADC driver
On 06/05/2014 06:05 PM, Soren Brinkmann wrote: > The Xilinx A/D Converter is found in Xilinx devices including Zynq. > > Signed-off-by: Soren Brinkmann > --- > arch/arm/configs/multi_v7_defconfig | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/arch/arm/configs/multi_v7_defconfig > b/arch/arm/configs/multi_v7_defconfig > index e2d62048e198..2d1039d8c7f1 100644 > --- a/arch/arm/configs/multi_v7_defconfig > +++ b/arch/arm/configs/multi_v7_defconfig > @@ -360,6 +360,7 @@ CONFIG_TEGRA_IOMMU_GART=y > CONFIG_TEGRA_IOMMU_SMMU=y > CONFIG_MEMORY=y > CONFIG_IIO=y > +CONFIG_XILINX_XADC=y > CONFIG_AK8975=y > CONFIG_PWM=y > CONFIG_PWM_TEGRA=y > Olof, Arnd: Are you going to take this patch directly to your tree? I will add 1/2 to my zynq/dt branch. Thanks, Michal -- 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/
[GIT PULL] target fixes for v3.15
Hi Linus, Here are the remaining fixes for v3.15. Please go ahead and pull from: git://git.kernel.org/pub/scm/linux/kernel/git/nab/target-pending.git master This series includes: - iser-target fix for ImmediateData exception reference count bug (Sagi + nab) - iscsi-target fix for MC/S login + potential iser-target MRDSL buffer overrun (Santosh + Roland) - iser-target fix for v3.15-rc multi network portal shutdown regression (nab) - target fix for allowing READ_CAPCITY during ALUA Standby access state (Chris + nab) - target fix for NULL pointer dereference of alua_access_state for un-configured devices (Chris + nab) Thank you, --nab Nicholas Bellinger (4): iser-target: Add missing target_put_sess_cmd for ImmedateData failure iser-target: Fix multi network portal shutdown regression target: Allow READ_CAPACITY opcode in ALUA Standby access state target: Fix alua_access_state attribute OOPs for un-configured devices Roland Dreier (1): iscsi-target: Fix wrong buffer / buffer overrun in iscsi_change_param_value() drivers/infiniband/ulp/isert/ib_isert.c |2 + drivers/target/iscsi/iscsi_target.c |1 + drivers/target/iscsi/iscsi_target_login.c | 70 + drivers/target/iscsi/iscsi_target_tpg.c |3 +- drivers/target/target_core_alua.c |9 drivers/target/target_core_configfs.c |5 +++ 6 files changed, 50 insertions(+), 40 deletions(-) -- 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] ARM: EXYNOS: mcpm: Don't rely on firmware's secondary_cpu_start
On Fri, Jun 06, 2014 at 10:43:05PM +0100, Doug Anderson wrote:
> On exynos mcpm systems the firmware is hardcoded to jump to an address
> in SRAM (0x02073000) when secondary CPUs come up. By default the
> firmware puts a bunch of code at that location. That code expects the
> kernel to fill in a few slots with addresses that it uses to jump back
> to the kernel's entry point for secondary CPUs.
>
> Originally (on prerelease hardware) this firmware code contained a
> bunch of workarounds to deal with boot ROM bugs. However on all
> shipped hardware we simply use this code to redirect to a kernel
> function for bringing up the CPUs.
>
> Let's stop relying on the code provided by the bootloader and just
> plumb in our own (simple) code jump to the kernel. This has the nice
> benefit of fixing problems due to the fact that older bootloaders
> (like the one shipped on the Samsung Chromebook 2) might have put
> slightly different code into this location.
>
> Once suspend/resume is implemented for systems using exynos-mcpm we'll
> need to make sure we reinstall our fixed up code after resume. ...but
> that's not anything new since IRAM (and thus the address of the
> mcpm_entry_point) is lost across suspend/resume anyway.
Can I ask you please what the firmware does for the boot (primary) cpu
on cold-boot and warm-boot (resume from suspend) ?
Does it jump to a specific (hardcoded) location ?
Is the primary CPU (MPIDR) hardcoded in firmware so that on both
cold and warm-boot firmware sees a specific MPIDR as "special" ?
I am asking to check if on this platform CPUidle (where the notion of
primary CPU disappears) has a chance to run properly.
Probably CPUidle won't attain idle states where IRAM content is lost, but I
am still worried about the primary vs secondaries firmware boot behaviour.
What happens on reboot from suspend to RAM (or to put it differently,
what does secure firmware do on reboot from suspend to RAM - in
particular how is the "jump" address to bootloader/kernel set ?)
Thank you very much.
Lorenzo
>
> Signed-off-by: Doug Anderson
> ---
> arch/arm/mach-exynos/mcpm-exynos.c | 10 ++
> 1 file changed, 6 insertions(+), 4 deletions(-)
>
> diff --git a/arch/arm/mach-exynos/mcpm-exynos.c
> b/arch/arm/mach-exynos/mcpm-exynos.c
> index 0498d0b..3a7fad0 100644
> --- a/arch/arm/mach-exynos/mcpm-exynos.c
> +++ b/arch/arm/mach-exynos/mcpm-exynos.c
> @@ -343,11 +343,13 @@ static int __init exynos_mcpm_init(void)
> pr_info("Exynos MCPM support installed\n");
>
> /*
> - * Future entries into the kernel can now go
> - * through the cluster entry vectors.
> + * U-Boot SPL is hardcoded to jump to the start of ns_sram_base_addr
> + * as part of secondary_cpu_start(). Let's redirect it to the
> + * mcpm_entry_point().
>*/
> - __raw_writel(virt_to_phys(mcpm_entry_point),
> - ns_sram_base_addr + MCPM_BOOT_ADDR_OFFSET);
> + __raw_writel(0xe59f, ns_sram_base_addr); /* ldr r0, [pc, #0] */
> + __raw_writel(0xe12fff10, ns_sram_base_addr + 4); /* bx r0 */
> + __raw_writel(virt_to_phys(mcpm_entry_point), ns_sram_base_addr + 8);
>
> iounmap(ns_sram_base_addr);
>
> --
> 2.0.0.526.g5318336
>
> --
> 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/
[PATCH] dns_resolver: assure that dns_query() result is null-terminated
dns_query() credulously assumes that keys are null-terminated and returns a copy of a memory block that is off by one. --- net/dns_resolver/dns_query.c |4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/net/dns_resolver/dns_query.c b/net/dns_resolver/dns_query.c index e7b6d53..53be635 100644 --- a/net/dns_resolver/dns_query.c +++ b/net/dns_resolver/dns_query.c @@ -149,7 +149,9 @@ int dns_query(const char *type, const char *name, size_t namelen, if (!*_result) goto put; - memcpy(*_result, upayload->data, len + 1); + memcpy(*_result, upayload->data, len); + *_result[len+1] = '\0'; + if (_expiry) *_expiry = rkey->expiry; -- 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/
Re: [PATCH] net: wan: wanxl.c: Cleaning up declaration of a while loop
Rickard Strandqvist writes:
> Unusual declaration of a while loop.
> However, believe you also want to make sure that the pointer is not NULL
Not really. The code is meant to do exactly what it currently does -
set variable desc and then check desc->stat.
All rx_descs are at this point already initialized and not NULL
(if desc was indeed NULL we better BUG*() or Oops on desc->stat access
instead of failing silently).
> --- a/drivers/net/wan/wanxl.c
> +++ b/drivers/net/wan/wanxl.c
> @@ -196,7 +196,7 @@ static inline void wanxl_tx_intr(port_t *port)
> static inline void wanxl_rx_intr(card_t *card)
> {
> desc_t *desc;
> - while (desc = &card->status->rx_descs[card->rx_in],
> + while (desc = &card->status->rx_descs[card->rx_in] &&
> desc->stat != PACKET_EMPTY) {
> if ((desc->stat & PACKET_PORT_MASK) > card->n_ports)
> pr_crit("%s: received packet for nonexistent port\n",
--
Krzysztof Halasa
--
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 v5] i2c: add driver for Rockchip RK3xxx SoC I2C adapter
Driver for the native I2C adapter found in Rockchip RK3xxx SoCs.
Configuration is only possible through devicetree. The driver is
interrupt driven and supports the I2C_M_IGNORE_NAK mangling bit.
Signed-off-by: Max Schwarz
---
Sorry for the resend, I forgot to CC the developers at Rockchip,
which I promised to do. Patch is unchanged.
The driver cannot be used without a proper clock driver
supporting rate calculation, such as Heiko Stübner's RK3xxx clock
driver series [1].
Changes since v4:
- fixed a bug in message counting in rk3x_i2c_xfer()
- Found/suggested by Wolfram Sang:
* fixed style issues
* fixed sorting in Kconfig, Makefile
* removed unneeded fields from struct rk3x_i2c
* REPEATED_START between msgs of one transfer
* fixed wrong error code on NAK
* support for SMB_QUICK (len == 0)
* removed unneeded DT check & alias handling
* sanity check for clock-frequency
Changes since v3:
- fixed style issues found by Maxime Ripard
- use dt alias id to calculate the bit offset in GRF,
as suggested by Maxime Ripard
- also use dt alias id for i2c_add_numbered_adapter()
Changes since v2:
- support for the new GRF syscon mapping by Heiko Stübner
- probe error handling improvements by Heiko Stübner
- fixed wrong remove() order found by Heiko Stübner
- removed unnecessary clk_enable() during probe
- removed switch back to old interface during remove
Changes since v1:
- dt property names "rockchip,*" suggested by Heiko Stübner
- fixed overly specific RK3188 comment (Heiko Stübner)
The dts files needed for testing on Radxa Rock are in my tree at
https://github.com/xqms/linux.git topic/i2c-rk3x-clean-v4
[1]: http://www.spinics.net/lists/arm-kernel/msg334495.html
Documentation/devicetree/bindings/i2c/i2c-rk3x.txt | 42 ++
drivers/i2c/busses/Kconfig | 10 +
drivers/i2c/busses/Makefile| 1 +
drivers/i2c/busses/i2c-rk3x.c | 769 +
4 files changed, 822 insertions(+)
create mode 100644 Documentation/devicetree/bindings/i2c/i2c-rk3x.txt
create mode 100644 drivers/i2c/busses/i2c-rk3x.c
diff --git a/Documentation/devicetree/bindings/i2c/i2c-rk3x.txt
b/Documentation/devicetree/bindings/i2c/i2c-rk3x.txt
new file mode 100644
index 000..dde6c22
--- /dev/null
+++ b/Documentation/devicetree/bindings/i2c/i2c-rk3x.txt
@@ -0,0 +1,42 @@
+* Rockchip RK3xxx I2C controller
+
+This driver interfaces with the native I2C controller present in Rockchip
+RK3xxx SoCs.
+
+Required properties :
+
+ - reg : Offset and length of the register set for the device
+ - compatible : should be "rockchip,rk3066-i2c", "rockchip,rk3188-i2c" or
+ "rockchip,rk3288-i2c".
+ - interrupts : interrupt number
+ - clocks : parent clock
+
+Required on RK3066, RK3188 :
+
+ - rockchip,grf : the phandle of the syscon node for the general register
+ file (GRF)
+ - on those SoCs an alias with the correct I2C bus ID (bit offset in the GRF)
+ is also required.
+
+Optional properties :
+
+ - clock-frequency : SCL frequency to use (in Hz). If omitted, 100kHz is used.
+
+Example:
+
+aliases {
+ i2c0 = &i2c0;
+}
+
+i2c0: i2c@2002d000 {
+ compatible = "rockchip,rk3188-i2c";
+ reg = <0x2002d000 0x1000>;
+ interrupts = ;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ rockchip,grf = <&grf>;
+
+ clock-names = "i2c";
+ clocks = <&cru PCLK_I2C0>;
+};
diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
index 7ccc51e..39307d0 100644
--- a/drivers/i2c/busses/Kconfig
+++ b/drivers/i2c/busses/Kconfig
@@ -676,6 +676,16 @@ config I2C_RIIC
This driver can also be built as a module. If so, the module
will be called i2c-riic.
+config I2C_RK3X
+ tristate "Rockchip RK3xxx I2C adapter"
+ depends on OF
+ help
+ Say Y here to include support for the I2C adapter in Rockchip RK3xxx
+ SoCs.
+
+ This driver can also be built as a module. If so, the module will
+ be called i2c-rk3x.
+
config HAVE_S3C2410_I2C
bool
help
diff --git a/drivers/i2c/busses/Makefile b/drivers/i2c/busses/Makefile
index 413d062..5582cf9 100644
--- a/drivers/i2c/busses/Makefile
+++ b/drivers/i2c/busses/Makefile
@@ -66,6 +66,7 @@ obj-$(CONFIG_I2C_PXA) += i2c-pxa.o
obj-$(CONFIG_I2C_PXA_PCI) += i2c-pxa-pci.o
obj-$(CONFIG_I2C_QUP) += i2c-qup.o
obj-$(CONFIG_I2C_RIIC) += i2c-riic.o
+obj-$(CONFIG_I2C_RK3X) += i2c-rk3x.o
obj-$(CONFIG_I2C_S3C2410) += i2c-s3c2410.o
obj-$(CONFIG_I2C_S6000)+= i2c-s6000.o
obj-$(CONFIG_I2C_SH7760) += i2c-sh7760.o
diff --git a/drivers/i2c/busses/i2c-rk3x.c b/drivers/i2c/busses/i2c-rk3x.c
new file mode 100644
index 000..7a430f4
--- /dev/null
+++ b/drivers/i2c/busses/i2c-rk3x.c
@@ -0,0 +1,769 @@
+/*
+ * Driver for I2C adapter in Rockchip RK3xxx SoC
+ *
+ * Max Schwarz
+ * based on
[PATCH linux-next] staging: r8192ee: Adapt flush function prototype
Commit 77be2c54c5bd 'mac80211: add vif to flush call' modifies the flush
operation prototype. Update r8192ee function accordingly.
This fixes the following compilation warnings:
drivers/staging/rtl8192ee/core.c: At top level:
drivers/staging/rtl8192ee/core.c:1599:2: warning: initialization from
incompatible pointer type [enabled by default]
.flush = rtl_op_flush,
^
drivers/staging/rtl8192ee/core.c:1599:2: warning: (near initialization for
‘rtl92e_ops.flush’) [enabled by default]
Signed-off-by: Vincent Stehlé
Cc: Greg Kroah-Hartman
Cc: Larry Finger
---
Hi,
Linux next gives a "heads up" that the flush function of staging driver r8192ee
needs to be adapted soon.
This can be seen with e.g. linux next-20140606 and x86 allmodconfig.
Also, r8192ee would benefit from the following patch:
http://www.spinics.net/lists/linux-driver-devel/msg47690.html
Best regards,
V.
drivers/staging/rtl8192ee/core.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/rtl8192ee/core.c b/drivers/staging/rtl8192ee/core.c
index 76ea356..7f6accd 100644
--- a/drivers/staging/rtl8192ee/core.c
+++ b/drivers/staging/rtl8192ee/core.c
@@ -322,7 +322,7 @@ static void _rtl_add_wowlan_patterns(struct ieee80211_hw
*hw,
struct rtl_mac *mac = &(rtlpriv->mac80211);
struct cfg80211_pkt_pattern *patterns = wow->patterns;
struct rtl_wow_pattern rtl_pattern;
- u8 *pattern_os, *mask_os;
+ const u8 *pattern_os, *mask_os;
u8 mask[MAX_WOL_BIT_MASK_SIZE] = {0};
u8 content[MAX_WOL_PATTERN_SIZE] = {0};
u8 broadcast_addr[6] = {0xff, 0xff, 0xff, 0xff, 0xff, 0xff};
@@ -1561,7 +1561,7 @@ static void rtl_op_rfkill_poll(struct ieee80211_hw *hw)
* before switch channle or power save, or tx buffer packet
* maybe send after offchannel or rf sleep, this may cause
* dis-association by AP */
-static void rtl_op_flush(struct ieee80211_hw *hw,
+static void rtl_op_flush(struct ieee80211_hw *hw, struct ieee80211_vif *vif,
u32 queues, bool drop)
{
struct rtl_priv *rtlpriv = rtl_priv(hw);
--
2.0.0.rc2
--
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] ipip, sit: fix ipv4_{update_pmtu,redirect} calls
On Sat, 7 Jun 2014 19:54:12 +0400
Dmitry Popov wrote:
> 3) gre:
> ipgre is a framework for subprotos which doesn't work with tunnel devices by
> itself (see net/ipv4/gre_demux.c:gre_cisco_err). Although it uses
> skb->dev->ifindex for ipv4_{update_pmtu,redirect} which might be wrong for
> hosts
> with asymmetric routing, this is not a big deal, because tunnels bound to
> device
> will not work with asymmetric routing anyway. So I think it is okay.
Actually, yes, it may not work in case of unbound tunnel and asymmetric routing,
but we'll need to put icmp redirects/frag_needed handling inside
gre_cisco_protocol->err_handler then, I am not sure if it's worth 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 v5] i2c: add driver for Rockchip RK3xxx SoC I2C adapter
Driver for the native I2C adapter found in Rockchip RK3xxx SoCs.
Configuration is only possible through devicetree. The driver is
interrupt driven and supports the I2C_M_IGNORE_NAK mangling bit.
Signed-off-by: Max Schwarz
---
The driver cannot be used without a proper clock driver
supporting rate calculation, such as Heiko Stübner's RK3xxx clock
driver series [1].
Changes since v4:
- fixed a bug in message counting in rk3x_i2c_xfer()
- Found/suggested by Wolfram Sang:
* fixed style issues
* fixed sorting in Kconfig, Makefile
* removed unneeded fields from struct rk3x_i2c
* REPEATED_START between msgs of one transfer
* fixed wrong error code on NAK
* support for SMB_QUICK (len == 0)
* removed unneeded DT check & alias handling
* sanity check for clock-frequency
Changes since v3:
- fixed style issues found by Maxime Ripard
- use dt alias id to calculate the bit offset in GRF,
as suggested by Maxime Ripard
- also use dt alias id for i2c_add_numbered_adapter()
Changes since v2:
- support for the new GRF syscon mapping by Heiko Stübner
- probe error handling improvements by Heiko Stübner
- fixed wrong remove() order found by Heiko Stübner
- removed unnecessary clk_enable() during probe
- removed switch back to old interface during remove
Changes since v1:
- dt property names "rockchip,*" suggested by Heiko Stübner
- fixed overly specific RK3188 comment (Heiko Stübner)
The dts files needed for testing on Radxa Rock are in my tree at
https://github.com/xqms/linux.git topic/i2c-rk3x-clean-v4
[1]: http://www.spinics.net/lists/arm-kernel/msg329102.html
Documentation/devicetree/bindings/i2c/i2c-rk3x.txt | 42 ++
drivers/i2c/busses/Kconfig | 10 +
drivers/i2c/busses/Makefile| 1 +
drivers/i2c/busses/i2c-rk3x.c | 769 +
4 files changed, 822 insertions(+)
create mode 100644 Documentation/devicetree/bindings/i2c/i2c-rk3x.txt
create mode 100644 drivers/i2c/busses/i2c-rk3x.c
diff --git a/Documentation/devicetree/bindings/i2c/i2c-rk3x.txt
b/Documentation/devicetree/bindings/i2c/i2c-rk3x.txt
new file mode 100644
index 000..dde6c22
--- /dev/null
+++ b/Documentation/devicetree/bindings/i2c/i2c-rk3x.txt
@@ -0,0 +1,42 @@
+* Rockchip RK3xxx I2C controller
+
+This driver interfaces with the native I2C controller present in Rockchip
+RK3xxx SoCs.
+
+Required properties :
+
+ - reg : Offset and length of the register set for the device
+ - compatible : should be "rockchip,rk3066-i2c", "rockchip,rk3188-i2c" or
+ "rockchip,rk3288-i2c".
+ - interrupts : interrupt number
+ - clocks : parent clock
+
+Required on RK3066, RK3188 :
+
+ - rockchip,grf : the phandle of the syscon node for the general register
+ file (GRF)
+ - on those SoCs an alias with the correct I2C bus ID (bit offset in the GRF)
+ is also required.
+
+Optional properties :
+
+ - clock-frequency : SCL frequency to use (in Hz). If omitted, 100kHz is used.
+
+Example:
+
+aliases {
+ i2c0 = &i2c0;
+}
+
+i2c0: i2c@2002d000 {
+ compatible = "rockchip,rk3188-i2c";
+ reg = <0x2002d000 0x1000>;
+ interrupts = ;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ rockchip,grf = <&grf>;
+
+ clock-names = "i2c";
+ clocks = <&cru PCLK_I2C0>;
+};
diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
index 7ccc51e..39307d0 100644
--- a/drivers/i2c/busses/Kconfig
+++ b/drivers/i2c/busses/Kconfig
@@ -676,6 +676,16 @@ config I2C_RIIC
This driver can also be built as a module. If so, the module
will be called i2c-riic.
+config I2C_RK3X
+ tristate "Rockchip RK3xxx I2C adapter"
+ depends on OF
+ help
+ Say Y here to include support for the I2C adapter in Rockchip RK3xxx
+ SoCs.
+
+ This driver can also be built as a module. If so, the module will
+ be called i2c-rk3x.
+
config HAVE_S3C2410_I2C
bool
help
diff --git a/drivers/i2c/busses/Makefile b/drivers/i2c/busses/Makefile
index 413d062..5582cf9 100644
--- a/drivers/i2c/busses/Makefile
+++ b/drivers/i2c/busses/Makefile
@@ -66,6 +66,7 @@ obj-$(CONFIG_I2C_PXA) += i2c-pxa.o
obj-$(CONFIG_I2C_PXA_PCI) += i2c-pxa-pci.o
obj-$(CONFIG_I2C_QUP) += i2c-qup.o
obj-$(CONFIG_I2C_RIIC) += i2c-riic.o
+obj-$(CONFIG_I2C_RK3X) += i2c-rk3x.o
obj-$(CONFIG_I2C_S3C2410) += i2c-s3c2410.o
obj-$(CONFIG_I2C_S6000)+= i2c-s6000.o
obj-$(CONFIG_I2C_SH7760) += i2c-sh7760.o
diff --git a/drivers/i2c/busses/i2c-rk3x.c b/drivers/i2c/busses/i2c-rk3x.c
new file mode 100644
index 000..7a430f4
--- /dev/null
+++ b/drivers/i2c/busses/i2c-rk3x.c
@@ -0,0 +1,769 @@
+/*
+ * Driver for I2C adapter in Rockchip RK3xxx SoC
+ *
+ * Max Schwarz
+ * based on the patches by Rockchip Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ *
Re: [PATCH 3.2 00/92] 3.2.60-rc1 review
On Sat, 2014-06-07 at 09:33 -0700, Guenter Roeck wrote: > On Sat, Jun 07, 2014 at 02:26:28AM +0100, Ben Hutchings wrote: > > This is the start of the stable review cycle for the 3.2.60 release. > > There are 92 patches in this series, which will be posted as responses > > to this one. If anyone has any issues with these being applied, please > > let me know. > > > > Responses should be made by Mon Jun 09 01:26:28 UTC 2014. > > Anything received after that time might be too late. > > > Build restults: > total: 133 pass: 98 skipped: 25 fail: 10 > > Qem tests all passed. > > No unexpected build failures; results are as expected. > > Details are available at http://server.roeck-us.net:8010/builders. Thanks. Ben. -- Ben Hutchings Knowledge is power. France is bacon. signature.asc Description: This is a digitally signed message part
Re: [PATCH v2 0/5] staging: ft1000: ft1000-usb: ft1000_debug.c: Fix style errors and warnings.
On Fri, Jun 06, 2014 at 08:02:13PM -0700, Thomas Wood wrote: > Changes since v1: > * Made single patch into a patch set. > * Added better commit messages. > > Is this better, or do I still have to split up my first patch? At first glance, it looks fine, I'll queue this up after 3.16-rc1 is out (in about a week or so). thanks, greg k-h -- 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/3] f2fs: recover fallocated space
If a fallocated file is fsynced, we should recover the i_size after sudden
power cut.
Signed-off-by: Jaegeuk Kim
---
fs/f2fs/file.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/fs/f2fs/file.c b/fs/f2fs/file.c
index d97e5c4..78110da 100644
--- a/fs/f2fs/file.c
+++ b/fs/f2fs/file.c
@@ -682,6 +682,7 @@ static int expand_inode_data(struct inode *inode, loff_t
offset,
i_size_read(inode) < new_size) {
i_size_write(inode, new_size);
mark_inode_dirty(inode);
+ f2fs_write_inode(inode, NULL);
}
return ret;
--
1.8.5.2 (Apple Git-48)
--
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/3] f2fs: avoid not to call remove_dirty_inode
There is an errorneous case during the recovery like below.
In recovery_dentry,
1) dir = f2fs_iget();
2) mark the dir with FI_DELAY_IPUT
3) goto unmap_out
After the end of recovery routine, there is no dirty dentries so the dir cannot
be released by iput in remove_dirty_dir_inode.
This patch fixes such the bug case by handling the iget and iput in the
recovery_dentry procedure.
Signed-off-by: Jaegeuk Kim
---
fs/f2fs/recovery.c | 21 +
1 file changed, 13 insertions(+), 8 deletions(-)
diff --git a/fs/f2fs/recovery.c b/fs/f2fs/recovery.c
index e950a2f..a112368 100644
--- a/fs/f2fs/recovery.c
+++ b/fs/f2fs/recovery.c
@@ -52,20 +52,13 @@ static int recover_dentry(struct page *ipage, struct inode
*inode)
goto out;
}
- if (is_inode_flag_set(F2FS_I(dir), FI_DIRTY_DIR)) {
- iput(dir);
- } else {
- add_dirty_dir_inode(dir);
- set_inode_flag(F2FS_I(dir), FI_DELAY_IPUT);
- }
-
name.len = le32_to_cpu(raw_inode->i_namelen);
name.name = raw_inode->i_name;
if (unlikely(name.len > F2FS_NAME_LEN)) {
WARN_ON(1);
err = -ENAMETOOLONG;
- goto out;
+ goto out_err;
}
retry:
de = f2fs_find_entry(dir, &name, &page);
@@ -90,11 +83,23 @@ retry:
goto retry;
}
err = __f2fs_add_link(dir, &name, inode);
+ if (err)
+ goto out_err;
+
+ if (is_inode_flag_set(F2FS_I(dir), FI_DELAY_IPUT)) {
+ iput(dir);
+ } else {
+ add_dirty_dir_inode(dir);
+ set_inode_flag(F2FS_I(dir), FI_DELAY_IPUT);
+ }
+
goto out;
out_unmap_put:
kunmap(page);
f2fs_put_page(page, 0);
+out_err:
+ iput(dir);
out:
f2fs_msg(inode->i_sb, KERN_NOTICE,
"%s: ino = %x, name = %s, dir = %lx, err = %d",
--
1.8.5.2 (Apple Git-48)
--
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/3] f2fs: fix to recover data written by dio
If data are overwritten through dio, previous f2fs doesn't remain the fsync mark
due to no additional node writes.
Note that this patch should resolve the xfstests:311.
Signed-off-by: Jaegeuk Kim
---
fs/f2fs/data.c | 3 +++
fs/f2fs/f2fs.h | 1 +
fs/f2fs/node.c | 12
3 files changed, 16 insertions(+)
diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c
index 8c250a5..39fe7d7 100644
--- a/fs/f2fs/data.c
+++ b/fs/f2fs/data.c
@@ -1041,6 +1041,9 @@ static ssize_t f2fs_direct_IO(int rw, struct kiocb *iocb,
if (check_direct_IO(inode, rw, iov, offset, nr_segs))
return 0;
+ /* clear fsync mark to recover these blocks */
+ fsync_mark_clear(F2FS_SB(inode->i_sb), inode->i_ino);
+
return blockdev_direct_IO(rw, iocb, inode, iov, offset, nr_segs,
get_data_block);
}
diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
index 9684b1f..f628c3c 100644
--- a/fs/f2fs/f2fs.h
+++ b/fs/f2fs/f2fs.h
@@ -1168,6 +1168,7 @@ struct node_info;
bool available_free_memory(struct f2fs_sb_info *, int);
int is_checkpointed_node(struct f2fs_sb_info *, nid_t);
bool fsync_mark_done(struct f2fs_sb_info *, nid_t);
+void fsync_mark_clear(struct f2fs_sb_info *, nid_t);
void get_node_info(struct f2fs_sb_info *, nid_t, struct node_info *);
int get_dnode_of_data(struct dnode_of_data *, pgoff_t, int);
int truncate_inode_blocks(struct inode *, pgoff_t);
diff --git a/fs/f2fs/node.c b/fs/f2fs/node.c
index 02a59e9..a0a1f25 100644
--- a/fs/f2fs/node.c
+++ b/fs/f2fs/node.c
@@ -153,6 +153,18 @@ bool fsync_mark_done(struct f2fs_sb_info *sbi, nid_t nid)
return fsync_done;
}
+void fsync_mark_clear(struct f2fs_sb_info *sbi, nid_t nid)
+{
+ struct f2fs_nm_info *nm_i = NM_I(sbi);
+ struct nat_entry *e;
+
+ write_lock(&nm_i->nat_tree_lock);
+ e = __lookup_nat_cache(nm_i, nid);
+ if (e)
+ e->fsync_done = false;
+ write_unlock(&nm_i->nat_tree_lock);
+}
+
static struct nat_entry *grab_nat_entry(struct f2fs_nm_info *nm_i, nid_t nid)
{
struct nat_entry *new;
--
1.8.5.2 (Apple Git-48)
--
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/
[PATCHv3 2/3] list: Fix order of arguments for hlist_add_after(_rcu)
From: Ken Helias
All other add functions for lists have the new item as first argument and the
position where it is added as second argument. This was changed for no good
reason in this function and makes using it unnecessary confusing.
The name was changed to let old code generate a compile errors instead of
using the wrong parameter order.
Signed-off-by: Ken Helias
Cc: Linux NICS
Cc: "Paul E. McKenney"
Cc: dri-de...@lists.freedesktop.org
Cc: e1000-de...@lists.sourceforge.net
Cc: net...@vger.kernel.org
Cc: de...@driverdev.osuosl.org
Cc: linux-fsde...@vger.kernel.org
Cc: b.a.t.m@lists.open-mesh.org
Cc: bri...@lists.linux-foundation.org
---
Patch based on "Add linux-next specific files for 20140606"
v3:
renamed from hlist_add_after* to hlist_add_behind
v2:
Splitted into two patches
reduced number of Cc
Documentation/RCU/whatisRCU.txt | 2 +-
drivers/gpu/drm/drm_hashtab.c| 2 +-
drivers/net/ethernet/intel/i40e/i40e_ethtool.c | 2 +-
drivers/net/ethernet/intel/ixgbe/ixgbe_ethtool.c | 2 +-
drivers/staging/lustre/lustre/libcfs/hash.c | 4 ++--
fs/namespace.c | 2 +-
fs/notify/inode_mark.c | 2 +-
fs/notify/vfsmount_mark.c| 2 +-
include/linux/list.h | 4 ++--
include/linux/rculist.h | 8
net/batman-adv/fragmentation.c | 2 +-
net/bridge/br_multicast.c| 2 +-
net/ipv4/fib_trie.c | 2 +-
net/ipv6/addrlabel.c | 2 +-
net/xfrm/xfrm_policy.c | 4 ++--
15 files changed, 21 insertions(+), 21 deletions(-)
diff --git a/Documentation/RCU/whatisRCU.txt b/Documentation/RCU/whatisRCU.txt
index 49b8551..e48c57f 100644
--- a/Documentation/RCU/whatisRCU.txt
+++ b/Documentation/RCU/whatisRCU.txt
@@ -818,7 +818,7 @@ RCU pointer/list update:
list_add_tail_rcu
list_del_rcu
list_replace_rcu
- hlist_add_after_rcu
+ hlist_add_behind_rcu
hlist_add_before_rcu
hlist_add_head_rcu
hlist_del_rcu
diff --git a/drivers/gpu/drm/drm_hashtab.c b/drivers/gpu/drm/drm_hashtab.c
index 7e4bae7..c3b80fd 100644
--- a/drivers/gpu/drm/drm_hashtab.c
+++ b/drivers/gpu/drm/drm_hashtab.c
@@ -125,7 +125,7 @@ int drm_ht_insert_item(struct drm_open_hash *ht, struct
drm_hash_item *item)
parent = &entry->head;
}
if (parent) {
- hlist_add_after_rcu(parent, &item->head);
+ hlist_add_behind_rcu(&item->head, parent);
} else {
hlist_add_head_rcu(&item->head, h_list);
}
diff --git a/drivers/net/ethernet/intel/i40e/i40e_ethtool.c
b/drivers/net/ethernet/intel/i40e/i40e_ethtool.c
index 1bb470b..7c3e596 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_ethtool.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_ethtool.c
@@ -1437,7 +1437,7 @@ static int i40e_update_ethtool_fdir_entry(struct i40e_vsi
*vsi,
/* add filter to the list */
if (parent)
- hlist_add_after(&parent->fdir_node, &input->fdir_node);
+ hlist_add_behind(&input->fdir_node, &parent->fdir_node);
else
hlist_add_head(&input->fdir_node,
&pf->fdir_filter_list);
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_ethtool.c
b/drivers/net/ethernet/intel/ixgbe/ixgbe_ethtool.c
index 23e4e6a..89b7a10 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_ethtool.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_ethtool.c
@@ -2518,7 +2518,7 @@ static int ixgbe_update_ethtool_fdir_entry(struct
ixgbe_adapter *adapter,
/* add filter to the list */
if (parent)
- hlist_add_after(&parent->fdir_node, &input->fdir_node);
+ hlist_add_behind(&input->fdir_node, &parent->fdir_node);
else
hlist_add_head(&input->fdir_node,
&adapter->fdir_filter_list);
diff --git a/drivers/staging/lustre/lustre/libcfs/hash.c
b/drivers/staging/lustre/lustre/libcfs/hash.c
index 6d2b455..6db7391 100644
--- a/drivers/staging/lustre/lustre/libcfs/hash.c
+++ b/drivers/staging/lustre/lustre/libcfs/hash.c
@@ -351,7 +351,7 @@ cfs_hash_dh_hnode_add(struct cfs_hash *hs, struct
cfs_hash_bd *bd,
cfs_hash_dhead_t, dh_head);
if (dh->dh_tail != NULL) /* not empty */
- hlist_add_after(dh->dh_tail, hnode);
+ hlist_add_behind(hnode, dh->dh_tail);
else /* empty list */
hlist_add_head(hnode, &dh->dh_head);
dh->dh_tail = hnode;
@@ -406,7 +406,7 @@ cfs_hash_dd_hnode_add(struct cfs_hash *hs, struct
cfs_hash_bd *bd,
cfs_hash_dhead_dep_t, dd_head);
if (dh->dd_tail != NULL) /* not empty */
- hlist_add_after(dh->dd_tail, hnode)
[PATCHv3 3/3] klist: Use same naming scheme as hlist for klist_add_after
From: Ken Helias
The name was modified from hlist_add_after to hlist_add_behind when adjusting
the order of arguments to match the one with klist_add_after. This is
necessary to avoid old code to compile against it when it would use it
the wrong way.
It would be good when klist would also follow this naming scheme to have a
consistent experience in all available list implementations.
Signed-off-by: Ken Helias
---
include/linux/klist.h | 2 +-
lib/klist.c | 6 +++---
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/include/linux/klist.h b/include/linux/klist.h
index a370ce5..61e5b72 100644
--- a/include/linux/klist.h
+++ b/include/linux/klist.h
@@ -44,7 +44,7 @@ struct klist_node {
extern void klist_add_tail(struct klist_node *n, struct klist *k);
extern void klist_add_head(struct klist_node *n, struct klist *k);
-extern void klist_add_after(struct klist_node *n, struct klist_node *pos);
+extern void klist_add_behind(struct klist_node *n, struct klist_node *pos);
extern void klist_add_before(struct klist_node *n, struct klist_node *pos);
extern void klist_del(struct klist_node *n);
diff --git a/lib/klist.c b/lib/klist.c
index 358a368..89b485a 100644
--- a/lib/klist.c
+++ b/lib/klist.c
@@ -140,11 +140,11 @@ void klist_add_tail(struct klist_node *n, struct klist *k)
EXPORT_SYMBOL_GPL(klist_add_tail);
/**
- * klist_add_after - Init a klist_node and add it after an existing node
+ * klist_add_behind - Init a klist_node and add it after an existing node
* @n: node we're adding.
* @pos: node to put @n after
*/
-void klist_add_after(struct klist_node *n, struct klist_node *pos)
+void klist_add_behind(struct klist_node *n, struct klist_node *pos)
{
struct klist *k = knode_klist(pos);
@@ -153,7 +153,7 @@ void klist_add_after(struct klist_node *n, struct
klist_node *pos)
list_add(&n->n_node, &pos->n_node);
spin_unlock(&k->k_lock);
}
-EXPORT_SYMBOL_GPL(klist_add_after);
+EXPORT_SYMBOL_GPL(klist_add_behind);
/**
* klist_add_before - Init a klist_node and add it before an existing node
--
2.0.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/
[PATCHv3 1/3] list: Use argument hlist_add_after names from rcu variant
From: Ken Helias
The argument names of the hlist_add_after are poorly chosen because they look
the same as the ones from hlist_add_before but have to be used completely
different. This easily confuses the reader. The creator of the
hlist_add_after_rcu function has made a lot better choice.
Signed-off-by: Ken Helias
---
v2:
Splitted into two patches
The patches to add list_add_before/behind were removed because it seems that
there is a consensus that list_add is understood by everyone automatically
as list_add_behind and list_add_tail is understood by everyone as
list_add_before even when the names suggest otherwise.
include/linux/list.h | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/include/linux/list.h b/include/linux/list.h
index ef95941..624ec7f 100644
--- a/include/linux/list.h
+++ b/include/linux/list.h
@@ -654,15 +654,15 @@ static inline void hlist_add_before(struct hlist_node *n,
*(n->pprev) = n;
}
-static inline void hlist_add_after(struct hlist_node *n,
- struct hlist_node *next)
+static inline void hlist_add_after(struct hlist_node *prev,
+ struct hlist_node *n)
{
- next->next = n->next;
- n->next = next;
- next->pprev = &n->next;
+ n->next = prev->next;
+ prev->next = n;
+ n->pprev = &prev->next;
- if(next->next)
- next->next->pprev = &next->next;
+ if (n->next)
+ n->next->pprev = &n->next;
}
/* after that we'll appear to be on some hlist and hlist_del will work */
--
2.0.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/
[tip:x86/urgent] x86/boot: EFI_MIXED should not prohibit loading above 4G
Commit-ID: 745c51673e289acf4d9ffc2835524de73ef923fd
Gitweb: http://git.kernel.org/tip/745c51673e289acf4d9ffc2835524de73ef923fd
Author: Matt Fleming
AuthorDate: Sat, 7 Jun 2014 12:26:20 +0100
Committer: H. Peter Anvin
CommitDate: Sat, 7 Jun 2014 09:31:00 -0700
x86/boot: EFI_MIXED should not prohibit loading above 4G
commit 7d453eee36ae ("x86/efi: Wire up CONFIG_EFI_MIXED") introduced a
regression for the functionality to load kernels above 4G. The relevant
(incorrect) reasoning behind this change can be seen in the commit
message,
"The xloadflags field in the bzImage header is also updated to reflect
that the kernel supports both entry points by setting both of
XLF_EFI_HANDOVER_32 and XLF_EFI_HANDOVER_64 when CONFIG_EFI_MIXED=y.
XLF_CAN_BE_LOADED_ABOVE_4G is disabled so that the kernel text is
guaranteed to be addressable with 32-bits."
This is obviously bogus since 32-bit EFI loaders will never place the
kernel above the 4G mark. So this restriction is entirely unnecessary.
But things are worse than that - since we want to encourage people to
always compile with CONFIG_EFI_MIXED=y so that their kernels work out of
the box for both 32-bit and 64-bit firmware, commit 7d453eee36ae
effectively disables XLF_CAN_BE_LOADED_ABOVE_4G completely.
Remove the overzealous and superfluous restriction and restore the
XLF_CAN_BE_LOADED_ABOVE_4G functionality.
Cc: "H. Peter Anvin"
Cc: Dave Young
Cc: Vivek Goyal
Signed-off-by: Matt Fleming
Link:
http://lkml.kernel.org/r/1402140380-15377-1-git-send-email-m...@console-pimps.org
Signed-off-by: H. Peter Anvin
---
arch/x86/boot/header.S | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/arch/x86/boot/header.S b/arch/x86/boot/header.S
index 0ca9a5c..84c2234 100644
--- a/arch/x86/boot/header.S
+++ b/arch/x86/boot/header.S
@@ -375,8 +375,7 @@ xloadflags:
# define XLF0 0
#endif
-#if defined(CONFIG_RELOCATABLE) && defined(CONFIG_X86_64) && \
- !defined(CONFIG_EFI_MIXED)
+#if defined(CONFIG_RELOCATABLE) && defined(CONFIG_X86_64)
/* kernel/boot_param/ramdisk could be loaded above 4g */
# define XLF1 XLF_CAN_BE_LOADED_ABOVE_4G
#else
--
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.2 00/92] 3.2.60-rc1 review
On Sat, Jun 07, 2014 at 02:26:28AM +0100, Ben Hutchings wrote: > This is the start of the stable review cycle for the 3.2.60 release. > There are 92 patches in this series, which will be posted as responses > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Mon Jun 09 01:26:28 UTC 2014. > Anything received after that time might be too late. > Build restults: total: 133 pass: 98 skipped: 25 fail: 10 Qem tests all passed. No unexpected build failures; results are as expected. Details are available at http://server.roeck-us.net:8010/builders. Guenter -- 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/
[PATCHv4 net-next 0/4] bridge: multicast snooping patches / exports
The first patch is simply a cosmetic patch. So far I (and maybe others
too?) have been regularly confusing these two structs, therefore I'd
suggest renaming them and therefore making the follow-up patches easier
to understand and nicer to fit in.
The second patch fixes a minor issue, but probably not worth for stable.
On the other hand the first two patches are also preparations for the
third and fourth patch:
These two patches are exporting functionality needed to marry the bridge
multicast snooping with the batman-adv multicast optimizations recently
added for the 3.15 kernel, allowing to use these optimzations in common
setups having a bridge on top of e.g. bat0, too. So far these bridged
setups would fall back to simple flooding through the batman-adv mesh
network for any multicast packet entering bat0.
More information about the batman-adv multicast optimizations currently
implemented can be found here:
http://www.open-mesh.org/projects/batman-adv/wiki/Basic-multicast-optimizations
The integration on the batman-adv side could afterwards look like this,
for instance:
http://git.open-mesh.org/batman-adv.git/commitdiff/576b59dd3e34737c702e548b21fa72059262f796?hp=f95ce7131746c65fbcdffcf2089cab59e2c2f7ac
Changes in v4:
- merged header postings from all previous patchset versions
Changes in v3:
- use EXPORT_SYMBOL_GPL() instead of EXPORT_SYMBOL()
Changes in v2:
- fix a nasty typo in PATCH 1/4, br_multicast_update_query_timer():
"br->multicast_query_interval" vs. "br->multicast_querier_interval"
=> this accidentally reduced the other querier present timer
from 255 to 125 seconds
- fix a typo in PATCH 2/4, br_ip{4,6}_multicast_query():
ntohs(ETH_P_{IP,IPV6}) vs. htons(ETH_P_{IP,IPV6})
- add missing ntohl()s before address comparison in PATCH 2/4,
br_ip4_multicast_select_querier() (thanks David!)
Cheers, Linus
--
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/
[PATCHv4 net-next 2/4] bridge: adhere to querier election mechanism specified by RFCs
MLDv1 (RFC2710 section 6), MLDv2 (RFC3810 section 7.6.2), IGMPv2
(RFC2236 section 3) and IGMPv3 (RFC3376 section 6.6.2) specify that the
querier with lowest source address shall become the selected
querier.
So far the bridge stopped its querier as soon as it heard another
querier regardless of its source address. This results in the "wrong"
querier potentially becoming the active querier or a potential,
unnecessary querying delay.
With this patch the bridge memorizes the source address of the currently
selected querier and ignores queries from queriers with a higher source
address than the currently selected one. This slight optimization is
supposed to make it more RFC compliant (but is rather uncritical and
therefore probably not necessary to be queued for stable kernels).
Signed-off-by: Linus Lüssing
---
net/bridge/br_multicast.c | 101 +++--
net/bridge/br_private.h |7
2 files changed, 95 insertions(+), 13 deletions(-)
diff --git a/net/bridge/br_multicast.c b/net/bridge/br_multicast.c
index 5ccac62..b3f17c9 100644
--- a/net/bridge/br_multicast.c
+++ b/net/bridge/br_multicast.c
@@ -789,6 +789,18 @@ static void br_ip6_multicast_querier_expired(unsigned long
data)
}
#endif
+static void br_multicast_select_own_querier(struct net_bridge *br,
+ struct br_ip *ip,
+ struct sk_buff *skb)
+{
+ if (ip->proto == htons(ETH_P_IP))
+ br->ip4_querier.addr.u.ip4 = ip_hdr(skb)->saddr;
+#if IS_ENABLED(CONFIG_IPV6)
+ else
+ br->ip6_querier.addr.u.ip6 = ipv6_hdr(skb)->saddr;
+#endif
+}
+
static void __br_multicast_send_query(struct net_bridge *br,
struct net_bridge_port *port,
struct br_ip *ip)
@@ -804,8 +816,10 @@ static void __br_multicast_send_query(struct net_bridge
*br,
skb->dev = port->dev;
NF_HOOK(NFPROTO_BRIDGE, NF_BR_LOCAL_OUT, skb, NULL, skb->dev,
dev_queue_xmit);
- } else
+ } else {
+ br_multicast_select_own_querier(br, ip, skb);
netif_rx(skb);
+ }
}
static void br_multicast_send_query(struct net_bridge *br,
@@ -1065,6 +1079,62 @@ static int br_ip6_multicast_mld2_report(struct
net_bridge *br,
}
#endif
+static bool br_ip4_multicast_select_querier(struct net_bridge *br,
+ __be32 saddr)
+{
+ if (!timer_pending(&br->ip4_own_query.timer) &&
+ !timer_pending(&br->ip4_other_query.timer))
+ goto update;
+
+ if (!br->ip4_querier.addr.u.ip4)
+ goto update;
+
+ if (ntohl(saddr) <= ntohl(br->ip4_querier.addr.u.ip4))
+ goto update;
+
+ return false;
+
+update:
+ br->ip4_querier.addr.u.ip4 = saddr;
+
+ return true;
+}
+
+#if IS_ENABLED(CONFIG_IPV6)
+static bool br_ip6_multicast_select_querier(struct net_bridge *br,
+ struct in6_addr *saddr)
+{
+ if (!timer_pending(&br->ip6_own_query.timer) &&
+ !timer_pending(&br->ip6_other_query.timer))
+ goto update;
+
+ if (ipv6_addr_cmp(saddr, &br->ip6_querier.addr.u.ip6) <= 0)
+ goto update;
+
+ return false;
+
+update:
+ br->ip6_querier.addr.u.ip6 = *saddr;
+
+ return true;
+}
+#endif
+
+static bool br_multicast_select_querier(struct net_bridge *br,
+ struct br_ip *saddr)
+{
+ switch (saddr->proto) {
+ case htons(ETH_P_IP):
+ return br_ip4_multicast_select_querier(br, saddr->u.ip4);
+#if IS_ENABLED(CONFIG_IPV6)
+ case htons(ETH_P_IPV6):
+ return br_ip6_multicast_select_querier(br, &saddr->u.ip6);
+#endif
+ }
+
+ return false;
+}
+
static void
br_multicast_update_query_timer(struct net_bridge *br,
struct bridge_mcast_other_query *query,
@@ -1127,15 +1197,13 @@ timer:
static void br_multicast_query_received(struct net_bridge *br,
struct net_bridge_port *port,
struct bridge_mcast_other_query *query,
- int saddr,
- bool is_general_query,
+ struct br_ip *saddr,
unsigned long max_delay)
{
- if (saddr && is_general_query)
- br_multicast_update_query_timer(br, query, max_delay);
- else if (timer_pending(&query->timer))
+ if (!br_multicast_select_querier(br, saddr))
return;
+ br_multicast_update_query_timer(br, query, max_delay);
br_multicast_mark_router(br, port);
}
@@ -1150,6 +1218,7 @@ static int br_ip4_multicast_query(struct net_bridge *br,
struct igmpv3
[PATCHv4 net-next 1/4] bridge: rename struct bridge_mcast_query/querier
The current naming of these two structs is very random, in that
reversing their naming would not make any semantical difference.
This patch tries to make the naming less confusing by giving them a more
specific, distinguishable naming.
This is also useful for the upcoming patches reintroducing the
"struct bridge_mcast_querier" but for storing information about the
selected querier (no matter if our own or a foreign querier).
Signed-off-by: Linus Lüssing
---
net/bridge/br_mdb.c |4 +-
net/bridge/br_multicast.c | 169 +++--
net/bridge/br_private.h | 22 +++---
3 files changed, 100 insertions(+), 95 deletions(-)
diff --git a/net/bridge/br_mdb.c b/net/bridge/br_mdb.c
index b7b1914..5df0526 100644
--- a/net/bridge/br_mdb.c
+++ b/net/bridge/br_mdb.c
@@ -418,13 +418,13 @@ static int __br_mdb_del(struct net_bridge *br, struct
br_mdb_entry *entry)
ip.proto = entry->addr.proto;
if (ip.proto == htons(ETH_P_IP)) {
- if (timer_pending(&br->ip4_querier.timer))
+ if (timer_pending(&br->ip4_other_query.timer))
return -EBUSY;
ip.u.ip4 = entry->addr.u.ip4;
#if IS_ENABLED(CONFIG_IPV6)
} else {
- if (timer_pending(&br->ip6_querier.timer))
+ if (timer_pending(&br->ip6_other_query.timer))
return -EBUSY;
ip.u.ip6 = entry->addr.u.ip6;
diff --git a/net/bridge/br_multicast.c b/net/bridge/br_multicast.c
index 7b757b5..5ccac62 100644
--- a/net/bridge/br_multicast.c
+++ b/net/bridge/br_multicast.c
@@ -35,7 +35,7 @@
#include "br_private.h"
static void br_multicast_start_querier(struct net_bridge *br,
- struct bridge_mcast_query *query);
+ struct bridge_mcast_own_query *query);
unsigned int br_mdb_rehash_seq;
static inline int br_ip_equal(const struct br_ip *a, const struct br_ip *b)
@@ -761,7 +761,7 @@ static void br_multicast_local_router_expired(unsigned long
data)
}
static void br_multicast_querier_expired(struct net_bridge *br,
-struct bridge_mcast_query *query)
+struct bridge_mcast_own_query *query)
{
spin_lock(&br->multicast_lock);
if (!netif_running(br->dev) || br->multicast_disabled)
@@ -777,7 +777,7 @@ static void br_ip4_multicast_querier_expired(unsigned long
data)
{
struct net_bridge *br = (void *)data;
- br_multicast_querier_expired(br, &br->ip4_query);
+ br_multicast_querier_expired(br, &br->ip4_own_query);
}
#if IS_ENABLED(CONFIG_IPV6)
@@ -785,7 +785,7 @@ static void br_ip6_multicast_querier_expired(unsigned long
data)
{
struct net_bridge *br = (void *)data;
- br_multicast_querier_expired(br, &br->ip6_query);
+ br_multicast_querier_expired(br, &br->ip6_own_query);
}
#endif
@@ -810,11 +810,11 @@ static void __br_multicast_send_query(struct net_bridge
*br,
static void br_multicast_send_query(struct net_bridge *br,
struct net_bridge_port *port,
- struct bridge_mcast_query *query)
+ struct bridge_mcast_own_query *own_query)
{
unsigned long time;
struct br_ip br_group;
- struct bridge_mcast_querier *querier = NULL;
+ struct bridge_mcast_other_query *other_query = NULL;
if (!netif_running(br->dev) || br->multicast_disabled ||
!br->multicast_querier)
@@ -822,31 +822,32 @@ static void br_multicast_send_query(struct net_bridge *br,
memset(&br_group.u, 0, sizeof(br_group.u));
- if (port ? (query == &port->ip4_query) :
- (query == &br->ip4_query)) {
- querier = &br->ip4_querier;
+ if (port ? (own_query == &port->ip4_own_query) :
+ (own_query == &br->ip4_own_query)) {
+ other_query = &br->ip4_other_query;
br_group.proto = htons(ETH_P_IP);
#if IS_ENABLED(CONFIG_IPV6)
} else {
- querier = &br->ip6_querier;
+ other_query = &br->ip6_other_query;
br_group.proto = htons(ETH_P_IPV6);
#endif
}
- if (!querier || timer_pending(&querier->timer))
+ if (!other_query || timer_pending(&other_query->timer))
return;
__br_multicast_send_query(br, port, &br_group);
time = jiffies;
- time += query->startup_sent < br->multicast_startup_query_count ?
+ time += own_query->startup_sent < br->multicast_startup_query_count ?
br->multicast_startup_query_interval :
br->multicast_query_interval;
- mod_timer(&query->timer, time);
+ mod_timer(&own_query->timer, time);
}
-static void br_multicast_port_query_expired(struct net_bridge_port *port,
-
[PATCHv4 net-next 4/4] bridge: memorize and export selected IGMP/MLD querier port
Adding bridge support to the batman-adv multicast optimization requires
batman-adv knowing about the existence of bridged-in IGMP/MLD queriers
to be able to reliably serve any multicast listener behind this same
bridge.
Signed-off-by: Linus Lüssing
---
include/linux/if_bridge.h |1 +
net/bridge/br_multicast.c | 72 +
net/bridge/br_private.h |1 +
3 files changed, 68 insertions(+), 6 deletions(-)
diff --git a/include/linux/if_bridge.h b/include/linux/if_bridge.h
index 44d6eb0..fd22789 100644
--- a/include/linux/if_bridge.h
+++ b/include/linux/if_bridge.h
@@ -38,5 +38,6 @@ typedef int br_should_route_hook_t(struct sk_buff *skb);
extern br_should_route_hook_t __rcu *br_should_route_hook;
int br_multicast_list_adjacent(struct net_device *dev,
struct list_head *br_ip_list);
+bool br_multicast_has_querier_adjacent(struct net_device *dev, int proto);
#endif
diff --git a/net/bridge/br_multicast.c b/net/bridge/br_multicast.c
index 772476b..cd3cf39 100644
--- a/net/bridge/br_multicast.c
+++ b/net/bridge/br_multicast.c
@@ -1081,6 +1081,7 @@ static int br_ip6_multicast_mld2_report(struct net_bridge
*br,
#endif
static bool br_ip4_multicast_select_querier(struct net_bridge *br,
+ struct net_bridge_port *port,
__be32 saddr)
{
if (!timer_pending(&br->ip4_own_query.timer) &&
@@ -1098,11 +1099,15 @@ static bool br_ip4_multicast_select_querier(struct
net_bridge *br,
update:
br->ip4_querier.addr.u.ip4 = saddr;
+ /* update protected by general multicast_lock by caller */
+ rcu_assign_pointer(br->ip4_querier.port, port);
+
return true;
}
#if IS_ENABLED(CONFIG_IPV6)
static bool br_ip6_multicast_select_querier(struct net_bridge *br,
+ struct net_bridge_port *port,
struct in6_addr *saddr)
{
if (!timer_pending(&br->ip6_own_query.timer) &&
@@ -1117,19 +1122,23 @@ static bool br_ip6_multicast_select_querier(struct
net_bridge *br,
update:
br->ip6_querier.addr.u.ip6 = *saddr;
+ /* update protected by general multicast_lock by caller */
+ rcu_assign_pointer(br->ip6_querier.port, port);
+
return true;
}
#endif
static bool br_multicast_select_querier(struct net_bridge *br,
+ struct net_bridge_port *port,
struct br_ip *saddr)
{
switch (saddr->proto) {
case htons(ETH_P_IP):
- return br_ip4_multicast_select_querier(br, saddr->u.ip4);
+ return br_ip4_multicast_select_querier(br, port, saddr->u.ip4);
#if IS_ENABLED(CONFIG_IPV6)
case htons(ETH_P_IPV6):
- return br_ip6_multicast_select_querier(br, &saddr->u.ip6);
+ return br_ip6_multicast_select_querier(br, port, &saddr->u.ip6);
#endif
}
@@ -1201,7 +1210,7 @@ static void br_multicast_query_received(struct net_bridge
*br,
struct br_ip *saddr,
unsigned long max_delay)
{
- if (!br_multicast_select_querier(br, saddr))
+ if (!br_multicast_select_querier(br, port, saddr))
return;
br_multicast_update_query_timer(br, query, max_delay);
@@ -1804,12 +1813,14 @@ int br_multicast_rcv(struct net_bridge *br, struct
net_bridge_port *port,
}
static void br_multicast_query_expired(struct net_bridge *br,
- struct bridge_mcast_own_query *query)
+ struct bridge_mcast_own_query *query,
+ struct bridge_mcast_querier *querier)
{
spin_lock(&br->multicast_lock);
if (query->startup_sent < br->multicast_startup_query_count)
query->startup_sent++;
+ rcu_assign_pointer(querier, NULL);
br_multicast_send_query(br, NULL, query);
spin_unlock(&br->multicast_lock);
}
@@ -1818,7 +1829,7 @@ static void br_ip4_multicast_query_expired(unsigned long
data)
{
struct net_bridge *br = (void *)data;
- br_multicast_query_expired(br, &br->ip4_own_query);
+ br_multicast_query_expired(br, &br->ip4_own_query, &br->ip4_querier);
}
#if IS_ENABLED(CONFIG_IPV6)
@@ -1826,7 +1837,7 @@ static void br_ip6_multicast_query_expired(unsigned long
data)
{
struct net_bridge *br = (void *)data;
- br_multicast_query_expired(br, &br->ip6_own_query);
+ br_multicast_query_expired(br, &br->ip6_own_query, &br->ip6_querier);
}
#endif
@@ -1849,8 +1860,10 @@ void br_multicast_init(struct net_bridge *br)
br->multicast_membership_interval = 260 * HZ;
br->ip4_other_query.delay_time = 0;
+ br->ip4_querier.port = NULL;
#if IS_ENABLED(CONFIG_IPV6)
br->ip6_other_query.delay
[PATCHv4 net-next 3/4] bridge: add export of multicast database adjacent to net_dev
With this new, exported function br_multicast_list_adjacent(net_dev) a
list of IPv4/6 addresses is returned. This list contains all multicast
addresses sensed by the bridge multicast snooping feature on all bridge
ports of the bridge interface of net_dev, excluding addresses from the
specified net_device itself.
Adding bridge support to the batman-adv multicast optimization requires
batman-adv knowing about the existence of bridged-in multicast
listeners to be able to reliably serve them with multicast packets.
Signed-off-by: Linus Lüssing
---
include/linux/if_bridge.h | 18 ++
net/bridge/br_multicast.c | 58 +
net/bridge/br_private.h | 12 --
3 files changed, 76 insertions(+), 12 deletions(-)
diff --git a/include/linux/if_bridge.h b/include/linux/if_bridge.h
index 1085ffe..44d6eb0 100644
--- a/include/linux/if_bridge.h
+++ b/include/linux/if_bridge.h
@@ -16,9 +16,27 @@
#include
#include
+struct br_ip {
+ union {
+ __be32 ip4;
+#if IS_ENABLED(CONFIG_IPV6)
+ struct in6_addr ip6;
+#endif
+ } u;
+ __be16 proto;
+ __u16 vid;
+};
+
+struct br_ip_list {
+ struct list_head list;
+ struct br_ip addr;
+};
+
extern void brioctl_set(int (*ioctl_hook)(struct net *, unsigned int, void
__user *));
typedef int br_should_route_hook_t(struct sk_buff *skb);
extern br_should_route_hook_t __rcu *br_should_route_hook;
+int br_multicast_list_adjacent(struct net_device *dev,
+ struct list_head *br_ip_list);
#endif
diff --git a/net/bridge/br_multicast.c b/net/bridge/br_multicast.c
index b3f17c9..772476b 100644
--- a/net/bridge/br_multicast.c
+++ b/net/bridge/br_multicast.c
@@ -11,6 +11,7 @@
*/
#include
+#include
#include
#include
#include
@@ -2141,3 +2142,60 @@ unlock:
return err;
}
+
+/**
+ * br_multicast_list_adjacent - Returns snooped multicast addresses
+ * @dev: The bridge port adjacent to which to retrieve addresses
+ * @br_ip_list:The list to store found, snooped multicast IP addresses
in
+ *
+ * Creates a list of IP addresses (struct br_ip_list) sensed by the multicast
+ * snooping feature on all bridge ports of dev's bridge device, excluding
+ * the addresses from dev itself.
+ *
+ * Returns the number of items added to br_ip_list.
+ *
+ * Notes:
+ * - br_ip_list needs to be initialized by caller
+ * - br_ip_list might contain duplicates in the end
+ * (needs to be taken care of by caller)
+ * - br_ip_list needs to be freed by caller
+ */
+int br_multicast_list_adjacent(struct net_device *dev,
+ struct list_head *br_ip_list)
+{
+ struct net_bridge *br;
+ struct net_bridge_port *port;
+ struct net_bridge_port_group *group;
+ struct br_ip_list *entry;
+ int count = 0;
+
+ rcu_read_lock();
+ if (!br_ip_list || !br_port_exists(dev))
+ goto unlock;
+
+ port = br_port_get_rcu(dev);
+ if (!port || !port->br)
+ goto unlock;
+
+ br = port->br;
+
+ list_for_each_entry_rcu(port, &br->port_list, list) {
+ if (!port->dev || port->dev == dev)
+ continue;
+
+ hlist_for_each_entry_rcu(group, &port->mglist, mglist) {
+ entry = kmalloc(sizeof(*entry), GFP_ATOMIC);
+ if (!entry)
+ goto unlock;
+
+ entry->addr = group->addr;
+ list_add(&entry->list, br_ip_list);
+ count++;
+ }
+ }
+
+unlock:
+ rcu_read_unlock();
+ return count;
+}
+EXPORT_SYMBOL_GPL(br_multicast_list_adjacent);
diff --git a/net/bridge/br_private.h b/net/bridge/br_private.h
index 97c5e46..50e2ab0 100644
--- a/net/bridge/br_private.h
+++ b/net/bridge/br_private.h
@@ -54,18 +54,6 @@ struct mac_addr
unsigned char addr[ETH_ALEN];
};
-struct br_ip
-{
- union {
- __be32 ip4;
-#if IS_ENABLED(CONFIG_IPV6)
- struct in6_addr ip6;
-#endif
- } u;
- __be16 proto;
- __u16 vid;
-};
-
#ifdef CONFIG_BRIDGE_IGMP_SNOOPING
/* our own querier */
struct bridge_mcast_own_query {
--
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/
