Skip to content

cloud-kernel
cloud-kernel

openanolis / cloud-kernel
1 年多 前同步成功

通知 160
Star 36
Fork 7
cloud-kernel
cloud-kernel
切换分支/标签
  1. 16 4月, 2012 1 次提交
  3. 06 4月, 2012 1 次提交
  5. 29 3月, 2012 4 次提交
  7. 28 3月, 2012 1 次提交
  9. 27 3月, 2012 1 次提交
    • A
      mtd: do not use plain 0 as NULL · 42d7fbe2
      由 Artem Bityutskiy 提交于 
      The first 3 arguments of 'mtd_device_parse_register()' are pointers,
but many callers pass '0' instead of 'NULL'. Fix this globally. Thanks
to coccinelle for making it easy to do with the following semantic patch:

 @@
 expression mtd, types, parser_data, parts, nr_parts;
 @@
 (
 -mtd_device_parse_register(mtd, 0, parser_data, parts, nr_parts)
 +mtd_device_parse_register(mtd, NULL, parser_data, parts, nr_parts)
 |
 -mtd_device_parse_register(mtd, types, 0, parts, nr_parts)
 +mtd_device_parse_register(mtd, types, NULL, parts, nr_parts)
 |
 -mtd_device_parse_register(mtd, types, parser_data, 0, nr_parts)
 +mtd_device_parse_register(mtd, types, parser_data, NULL, nr_parts)
 )
Signed-off-by: NArtem Bityutskiy <artem.bityutskiy@linux.intel.com>
Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>
      42d7fbe2
  11. 24 3月, 2012 2 次提交
    • J
      coredump: add VM_NODUMP, MADV_NODUMP, MADV_CLEAR_NODUMP · accb61fe
      由 Jason Baron 提交于 
      Since we no longer need the VM_ALWAYSDUMP flag, let's use the freed bit
for 'VM_NODUMP' flag.  The idea is is to add a new madvise() flag:
MADV_DONTDUMP, which can be set by applications to specifically request
memory regions which should not dump core.

The specific application I have in mind is qemu: we can add a flag there
that wouldn't dump all of guest memory when qemu dumps core.  This flag
might also be useful for security sensitive apps that want to absolutely
make sure that parts of memory are not dumped.  To clear the flag use:
MADV_DODUMP.

[akpm@linux-foundation.org: s/MADV_NODUMP/MADV_DONTDUMP/, s/MADV_CLEAR_NODUMP/MADV_DODUMP/, per Roland]
[akpm@linux-foundation.org: fix up the architectures which broke]
Signed-off-by: NJason Baron <jbaron@redhat.com>
Acked-by: NRoland McGrath <roland@hack.frob.com>
Cc: Chris Metcalf <cmetcalf@tilera.com>
Cc: Avi Kivity <avi@redhat.com>
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: Richard Henderson <rth@twiddle.net>
Cc: Ivan Kokshaysky <ink@jurassic.park.msu.ru>
Cc: Matt Turner <mattst88@gmail.com>
Cc: "James E.J. Bottomley" <jejb@parisc-linux.org>
Cc: Helge Deller <deller@gmx.de>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      accb61fe
    • J
      coredump: remove VM_ALWAYSDUMP flag · 909af768
      由 Jason Baron 提交于 
      The motivation for this patchset was that I was looking at a way for a
qemu-kvm process, to exclude the guest memory from its core dump, which
can be quite large.  There are already a number of filter flags in
/proc/<pid>/coredump_filter, however, these allow one to specify 'types'
of kernel memory, not specific address ranges (which is needed in this
case).

Since there are no more vma flags available, the first patch eliminates
the need for the 'VM_ALWAYSDUMP' flag.  The flag is used internally by
the kernel to mark vdso and vsyscall pages.  However, it is simple
enough to check if a vma covers a vdso or vsyscall page without the need
for this flag.

The second patch then replaces the 'VM_ALWAYSDUMP' flag with a new
'VM_NODUMP' flag, which can be set by userspace using new madvise flags:
'MADV_DONTDUMP', and unset via 'MADV_DODUMP'.  The core dump filters
continue to work the same as before unless 'MADV_DONTDUMP' is set on the
region.

The qemu code which implements this features is at:

  http://people.redhat.com/~jbaron/qemu-dump/qemu-dump.patch

In my testing the qemu core dump shrunk from 383MB -> 13MB with this
patch.

I also believe that the 'MADV_DONTDUMP' flag might be useful for
security sensitive apps, which might want to select which areas are
dumped.

This patch:

The VM_ALWAYSDUMP flag is currently used by the coredump code to
indicate that a vma is part of a vsyscall or vdso section.  However, we
can determine if a vma is in one these sections by checking it against
the gate_vma and checking for a non-NULL return value from
arch_vma_name().  Thus, freeing a valuable vma bit.
Signed-off-by: NJason Baron <jbaron@redhat.com>
Acked-by: NRoland McGrath <roland@hack.frob.com>
Cc: Chris Metcalf <cmetcalf@tilera.com>
Cc: Avi Kivity <avi@redhat.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      909af768
  13. 23 3月, 2012 1 次提交
  15. 20 3月, 2012 2 次提交
  17. 16 3月, 2012 2 次提交
    • H
      USB: use generic platform driver on ath79 · 5d98cd4e
      由 Hauke Mehrtens 提交于 
      The ath79 usb driver doesn't do anything special and is now converted
to the generic ehci and ohci driver.
This was tested on a TP-Link TL-WR1043ND (AR9132)
Acked-by: NGabor Juhos <juhosg@openwrt.org>
CC: Imre Kaloz <kaloz@openwrt.org>
CC: linux-mips@linux-mips.org
CC: Ralf Baechle <ralf@linux-mips.org>
Signed-off-by: NHauke Mehrtens <hauke@hauke-m.de>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      5d98cd4e
    • C
      [PATCH v3] ipc: provide generic compat versions of IPC syscalls · 48b25c43
      由 Chris Metcalf 提交于 
      When using the "compat" APIs, architectures will generally want to
be able to make direct syscalls to msgsnd(), shmctl(), etc., and
in the kernel we would want them to be handled directly by
compat_sys_xxx() functions, as is true for other compat syscalls.

However, for historical reasons, several of the existing compat IPC
syscalls do not do this.  semctl() expects a pointer to the fourth
argument, instead of the fourth argument itself.  msgsnd(), msgrcv()
and shmat() expect arguments in different order.

This change adds an ARCH_WANT_OLD_COMPAT_IPC config option that can be
set to preserve this behavior for ports that use it (x86, sparc, powerpc,
s390, and mips).  No actual semantics are changed for those architectures,
and there is only a minimal amount of code refactoring in ipc/compat.c.

Newer architectures like tile (and perhaps future architectures such
as arm64 and unicore64) should not select this option, and thus can
avoid having any IPC-specific code at all in their architecture-specific
compat layer.  In the same vein, if this option is not selected, IPC_64
mode is assumed, since that's what the <asm-generic> headers expect.

The workaround code in "tile" for msgsnd() and msgrcv() is removed
with this change; it also fixes the bug that shmat() and semctl() were
not being properly handled.
Reviewed-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NChris Metcalf <cmetcalf@tilera.com>
      48b25c43
  19. 06 3月, 2012 4 次提交
  21. 05 3月, 2012 1 次提交
  23. 01 3月, 2012 2 次提交
  25. 25 2月, 2012 1 次提交
    • G
      irq_domain/mips: Allow irq_domain on MIPS · abd2363f
      由 Grant Likely 提交于 
      This patch makes IRQ_DOMAIN usable on MIPS.  It uses an ugly workaround
to preserve current behaviour so that MIPS has time to add irq_domain
registration to the irq controller drivers.  The workaround will be
removed in Linux v3.6
Signed-off-by: NGrant Likely <grant.likely@secretlab.ca>
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: Rob Herring <rob.herring@calxeda.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-mips@linux-mips.org
      abd2363f
  27. 24 2月, 2012 7 次提交
    • D
      fs: Remove missed ->fds_bits from cessation use of fd_set structs internally · 189017c2
      由 David Howells 提交于 
      Stephen Rothwell reported that the following commit broke the
linux-next build:

  1fd36adc: Replace the fd_sets in struct fdtable with an array of unsigned longs

Fix places where ->fds_bits needed to be removed as the core
kernel no longer uses fd_set internally for file descriptor
table management.  There are two places:

 (1) drivers/staging/android/binder.c

 (2) arch/mips/kernel/kspd.c

     Question: Should sp_cleanup() in the MIPS arch be using find_next_bit()
     or fls()?
Reported-by: NStephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: NDavid Howells <dhowells@redhat.com>
cc: Ralf Bächle <ralf@linux-mips.org>
cc: Arve Hjønnevåg <arve@android.com>
Link: http://lkml.kernel.org/r/20120224105707.32170.11550.stgit@warthog.procyon.org.ukSigned-off-by: NIngo Molnar <mingo@elte.hu>
      189017c2
    • B
      net: Add framework to allow sending packets with customized CRC. · 3bdc0eba
      由 Ben Greear 提交于 
      This is useful for testing RX handling of frames with bad
CRCs.

Requires driver support to actually put the packet on the
wire properly.
Signed-off-by: NBen Greear <greearb@candelatech.com>
Tested-by: NAaron Brown <aaron.f.brown@intel.com>
Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      3bdc0eba
    • I
      static keys: Introduce 'struct static_key', static_key_true()/false() and... · c5905afb
      由 Ingo Molnar 提交于 
      static keys: Introduce 'struct static_key', static_key_true()/false() and static_key_slow_[inc|dec]()

So here's a boot tested patch on top of Jason's series that does
all the cleanups I talked about and turns jump labels into a
more intuitive to use facility. It should also address the
various misconceptions and confusions that surround jump labels.

Typical usage scenarios:

        #include <linux/static_key.h>

        struct static_key key = STATIC_KEY_INIT_TRUE;

        if (static_key_false(&key))
                do unlikely code
        else
                do likely code

Or:

        if (static_key_true(&key))
                do likely code
        else
                do unlikely code

The static key is modified via:

        static_key_slow_inc(&key);
        ...
        static_key_slow_dec(&key);

The 'slow' prefix makes it abundantly clear that this is an
expensive operation.

I've updated all in-kernel code to use this everywhere. Note
that I (intentionally) have not pushed through the rename
blindly through to the lowest levels: the actual jump-label
patching arch facility should be named like that, so we want to
decouple jump labels from the static-key facility a bit.

On non-jump-label enabled architectures static keys default to
likely()/unlikely() branches.
Signed-off-by: NIngo Molnar <mingo@elte.hu>
Acked-by: NJason Baron <jbaron@redhat.com>
Acked-by: NSteven Rostedt <rostedt@goodmis.org>
Cc: a.p.zijlstra@chello.nl
Cc: mathieu.desnoyers@efficios.com
Cc: davem@davemloft.net
Cc: ddaney.cavm@gmail.com
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Link: http://lkml.kernel.org/r/20120222085809.GA26397@elte.huSigned-off-by: NIngo Molnar <mingo@elte.hu>
      c5905afb
    • B
      PCI: collapse pcibios_resource_to_bus · fb127cb9
      由 Bjorn Helgaas 提交于 
      Everybody uses the generic pcibios_resource_to_bus() supplied by the core
now, so remove the ARCH_HAS_GENERIC_PCI_OFFSETS used during conversion.
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      fb127cb9
    • B
      mips/PCI: get rid of device resource fixups · 96a6b9ad
      由 Bjorn Helgaas 提交于 
      Tell the PCI core about host bridge address translation so it can take
care of bus-to-resource conversion for us.

Here's the wrinkle on Cobalt: we can't generate normal I/O port addresses
on PCI because the GT-64111 doesn't do any address translation, so we have
this:

  CPU I/O port addresses		[io 0x0000-0xffffff]
  PCI bus I/O port addresses	[io 0x10000000-0x10ffffff]

Legacy-mode IDE controllers start out with the legacy bus addresses, e.g.,
0x1f0, assigned by pci_setup_device().  These are outside the range of
addresses GT-64111 can generate on PCI, but pcibios_fixup_device_resources()
converted them to CPU addresses anyway by adding io_offset.  Therefore, we
had to pre-adjust them in cobalt_legacy_ide_fixup().

With io_offset = 0xf0000000, we had this:

  res->start = 0x1f0	initialized in pci_setup_device()
  res->start = 0x100001f0	-= io_offset in cobalt_legacy_ide_fixup()
  res->start = 0x1f0	+= io_offset in pcibios_fixup_device_resources()

The difference after this patch is that the generic pci_bus_to_resource()
only adds the offset if the bus address is inside a host bridge window.
Since 0x1f0 is not a valid bus address and is not inside any windows, it is
unaffected, so we now have this:

  region->start = 0x1f0	initialized in pci_setup_device()
  res->start = 0x1f0	no offset by pci_bus_to_resource()

That means we can remove both pcibios_fixup_device_resources() and
cobalt_legacy_ide_fixup().

I would *rather* set the host bridge offset to zero (which corresponds
to what the GT-64111 actually does), and have both CPU and PCI addresses
of [io 0x10000000-0x10ffffff].  However, that would require changes to
generic code that assumes legacy I/O addresses, such as pic1_io_resource
([io 0x0020-0x00021]), and we'd have to keep a Cobalt IDE fixup.

Of course, none of this changes the fact that references to I/O port
0x1f0 actually go to port 0x100001f0, not 0x1f0, on the Cobalt PCI bus.
Fortunately the VT82C586 IDE controller only decodes the low 24 address
bits, so it does work.

CC: Ralf Baechle <ralf@linux-mips.org>
CC: Yoichi Yuasa <yuasa@linux-mips.org>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      96a6b9ad
    • B
      mips/PCI: removed unused pci_probe configurability · 14be538c
      由 Bjorn Helgaas 提交于 
      We never assign anything other than PCI_ASSIGN_ALL_BUSSES to pci_probe,
so just remove the indirection.  If configurability is required in the
future, please use the pci_flags/PCI_REASSIGN_ALL_BUS functionality
as is done for powerpc.

CC: Ralf Baechle <ralf@linux-mips.org>
CC: linux-mips@linux-mips.org
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      14be538c
    • B
      mips/PCI: replace pci_probe_only with pci_flags · 29090606
      由 Bjorn Helgaas 提交于 
      Some architectures (alpha, mips, powerpc) have an arch-specific
"pci_probe_only" flag.  Others use PCI_PROBE_ONLY in pci_flags for
the same purpose.  This moves mips to the pci_flags approach so
generic code can use the same test across all architectures.

CC: Ralf Baechle <ralf@linux-mips.org>
CC: linux-mips@linux-mips.org
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      29090606
  29. 22 2月, 2012 1 次提交
    • P
      sock: Introduce the SO_PEEK_OFF sock option · ef64a54f
      由 Pavel Emelyanov 提交于 
      This one specifies where to start MSG_PEEK-ing queue data from. When
set to negative value means that MSG_PEEK works as ususally -- peeks
from the head of the queue always.

When some bytes are peeked from queue and the peeking offset is non
negative it is moved forward so that the next peek will return next
portion of data.

When non-peeking recvmsg occurs and the peeking offset is non negative
is is moved backward so that the next peek will still peek the proper
data (i.e. the one that would have been picked if there were no non
peeking recv in between).

The offset is set using per-proto opteration to let the protocol handle
the locking issues and to check whether the peeking offset feature is
supported by the protocol the socket belongs to.
Signed-off-by: NPavel Emelyanov <xemul@parallels.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      ef64a54f
  31. 21 2月, 2012 9 次提交