* [GIT PULL] (xen) stable/bug.fixes-3.2 and stable/mmu.fixes for Linux 3.2-rc0
From: Konrad Rzeszutek Wilk @ 2011-10-24 12:55 UTC (permalink / raw)
To: torvalds, linux-kernel
Cc: dario.faggioli, stefano.stabellini, dan.magenheimer, dgdegra
[-- Attachment #1: Type: text/plain, Size: 3499 bytes --]
Hey Linus,
Please pull the following two branches:
git pull git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen stable/bug.fixes-3.2 stable/mmu.fixes
which contain bug-fixes to various subsystems in Xen. I am not too thrilled
that this GIT pull is all over the place, but sadly that is the nature of some
bug fixes. I could split this up in small branches but not sure whether that would
be worth it?
Anyhow, there are two branches, wherein:
#stable/bug.fixes-3.2 is based of commit a102a9ece5489e1718cd7543aa079082450ac3a2 (Linux 3.1-rc8)
and contains bug fixes found when I ran the static analyzer tool "smatch".
Most of the bugs were for the error logic path - so I am quite happy that those
are fixed now.
#stable/mmu.fixes is based of commit 322a8b034003c0d46d39af85bf24fee27b902f48 (Linux 3.1-rc1)
and contains fixes to the Xen debugfs - one attribute got lost when Jeremy did the
move from home-grown tracing to using the tracing API. Another fix is to remove
a CONFIG_DEBUG option that was causing more grief that neccessary - so removing it.
The more serious bug-fixes are in the grant mechanism - Stefano found out that when
QEMU is mapping user pages and using AIO, the kernel AIO subsystem also maps those pages.
Which in effect means that there are two page mappings for a guest page - in the
userland and in the kernel. The grant table mechanism only dealt with the
userland pages so AIO ended up getting garbage.
We also fix a sleep-inside-spinlock bug and the self-ballooning mechanism
(it was squeezing the kernel too much causing an OOM).
Anyhow, the credit list is as follow:
Dan Magenheimer (1):
xen: Fix selfballooning and ensure it doesn't go too far
Daniel De Graaf (1):
xen/gntdev: Fix sleep-inside-spinlock
Konrad Rzeszutek Wilk (10):
Revert "xen/debug: WARN_ON when identity PFN has no _PAGE_IOMAP flag set."
xen/p2m: Make debug/xen/mmu/p2m visible again.
xen/p2m: Use SetPagePrivate and its friends for M2P overrides.
xen/events: BUG() when we can't allocate our event->irq array.
xen/events: Don't check the info for NULL as it is already done.
xen/irq: If we fail during msi_capability_init return proper error code.
xen/xenbus: Remove the unnecessary check.
xen/enlighten: Fix compile warnings and set cx to known value.
xen/p2m/debugfs: Fix potential pointer exception.
xen/p2m/debugfs: Make type_name more obvious.
Stefano Stabellini (2):
xen: add an "highmem" parameter to alloc_xenballooned_pages
xen: modify kernel mappings corresponding to granted pages
arch/x86/include/asm/xen/page.h | 6 +-
arch/x86/pci/xen.c | 10 ++-
arch/x86/xen/Kconfig | 8 --
arch/x86/xen/enlighten.c | 1 +
arch/x86/xen/mmu.c | 52 ------------
arch/x86/xen/p2m.c | 128 ++++++++++++++++++++++++----
drivers/block/xen-blkback/blkback.c | 2 +-
drivers/xen/balloon.c | 12 ++-
drivers/xen/events.c | 10 ++-
drivers/xen/gntdev.c | 39 ++++++++-
drivers/xen/grant-table.c | 6 +-
drivers/xen/xen-selfballoon.c | 67 ++++++++++++++-
drivers/xen/xenbus/xenbus_probe_backend.c | 2 -
include/xen/balloon.h | 5 +-
include/xen/grant_table.h | 1 +
15 files changed, 238 insertions(+), 111 deletions(-)
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* [GIT PULL] (xen) stable/cleanups-3.2 for Linux 3.2-rc0
From: Konrad Rzeszutek Wilk @ 2011-10-24 12:56 UTC (permalink / raw)
To: torvalds, linux-kernel; +Cc: olaf, ruslan
[-- Attachment #1: Type: text/plain, Size: 1543 bytes --]
Hey Linus,
Please pull the following branch:
git pull git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen stable/cleanups-3.2
which has some exciting merge conflict patches. These patches are based on
git commit 8ded371 (Merge branch 'for-3.1/drivers' of git://git.kernel.dk/linux-block).
They are patches mostly created from running scripts/checkpatch.pl and fixing things up.
They also cause merge conflicts: git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen linux-next
has the resolution of that - but it should be fairly easy to fix it up.
Please pull!
Olaf Hering (1):
xen: use static initializers in xen-balloon.c
Ruslan Pisarev (6):
Xen: fix whitespaces,tabs coding style issue in drivers/xen/balloon.c
Xen: fix whitespaces,tabs coding style issue in drivers/xen/events.c
Xen: fix braces coding style issue in gntdev.c and grant-table.c
Xen: fix whitespaces,tabs coding style issue in drivers/xen/pci.c
Xen: fix braces coding style issue in xenbus_probe.h
Xen: fix braces and tabs coding style issue in xenbus_probe.c
drivers/xen/balloon.c | 15 +++++++--------
drivers/xen/events.c | 9 ++++-----
drivers/xen/gntdev.c | 3 +--
drivers/xen/grant-table.c | 2 +-
drivers/xen/pci.c | 4 ++--
drivers/xen/xen-balloon.c | 17 ++++++++---------
drivers/xen/xenbus/xenbus_probe.c | 7 +++----
drivers/xen/xenbus/xenbus_probe.h | 3 +--
8 files changed, 27 insertions(+), 33 deletions(-)
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* [BUG] Invalid file descriptor.
From: Daniel Wagner @ 2011-10-24 13:14 UTC (permalink / raw)
To: linux-bluetooth
To whom it might concern,
if bluez is running without an agent and the remote device tries to
connect to bluez you are able to trigger the "Invalid file descriptor".
bluetoothd[30869]: src/event.c:btd_event_bonding_complete() status 0x00
bluetoothd[30869]: src/adapter.c:adapter_get_device() A0:4E:04:F6:F5:05
bluetoothd[30869]: src/device.c:device_bonding_complete() bonding (nil)
status 0x00
bluetoothd[30869]: audio/manager.c:hf_io_cb() Authorization denied!
(bluetoothd:30869): GLib-WARNING **: Invalid file descriptor.
bluetoothd[30869]: plugins/hciops.c:disconn_complete() handle 44 status 0x00
bluetoothd[30869]: src/event.c:btd_event_disconn_complete()
bluetoothd[30869]: src/adapter.c:adapter_remove_connection()
cheers,
daniel
ps: I was told to report all crashes and bugs I find. Be prepared. I am
a very capable finding bugs :)
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 6/6] vfs: Avoid unnecessary WB_SYNC_NONE writeback during sys_sync and reorder sync passes
From: Jan Kara @ 2011-10-24 13:14 UTC (permalink / raw)
To: Christoph Hellwig; +Cc: Jan Kara, Curt Wohlgemuth, linux-fsdevel, Al Viro
In-Reply-To: <20111020095725.GF11291@infradead.org>
On Thu 20-10-11 05:57:25, Christoph Hellwig wrote:
> On Fri, Oct 07, 2011 at 10:40:55PM +0200, Jan Kara wrote:
> > wakeup_flusher_threads(0) will queue work doing complete writeback for each
> > flusher thread. Thus there is not much point in submitting another work doing
> > full inode WB_SYNC_NONE writeback by writeback_inodes_sb().
> >
> > After this change it does not make sense to call nonblocking ->sync_fs and
> > block device flush before calling sync_inodes_sb() because
> > wakeup_flusher_threads() is completely asynchronous and thus these functions
> > would be called in parallel with inode writeback running which will effectively
> > void any work they do. So we move sync_inodes_sb() call before these two
> > functions.
>
> > wakeup_flusher_threads(0);
> > - iterate_supers(sync_inodes_one_sb, &nowait);
> > + iterate_supers(sync_inodes_one_sb, &wait);
> > iterate_supers(sync_fs_one_sb, &nowait);
> > sync_all_bdevs(nowait);
> > - iterate_supers(sync_inodes_one_sb, &wait);
> > iterate_supers(sync_fs_one_sb, &wait);
> > sync_all_bdevs(wait);
> > if (unlikely(laptop_mode))
>
> This looks a bit half-assed to me. Why do we still do the non-blocking
> sync_all_bdevs call? This really only starts async writeback on the
> block device inodes, which wakeup_flusher_threads already did.
Because e.g. ext2 will dirty quite some bdev buffers while doing inode
writeback which runs in no particular order with the writeback of bdev
inode. So after sync_inodes_sb() finishes you can have too much dirty
buffers on a bdev for synchronous sync_all_bdevs() to be efficient.
But what might be the best is to do filemap_fdadawrite() on all bdevs and
then do filemap_fdatawait() on all bdevs which would solve the efficiency
issue and also don't do writeback twice unnecessarily. OK?
> Similarly I don't think the non-blocking ->sync_fs call really make
> much sense anymore here.
Yes, so as I wrote in the introductory email, I did also measurements
where non-blocking ->sync_fs was removed and I didn't see any regression
with ext3, ext4, xfs, or btrfs. OTOH I can imagine *some* filesystem can do
an equivalent of filemap_fdatawrite() on some metadata for non-blocking
->sync_fs and filemap_fdatawrite_and_wait() on the blocking one and if
there are more such filesystems on different backing storages the
performance difference can be noticeable (actually, checking the
filesystems, JFS and Ceph seem to be doing something like this). So I
that's why I didn't include the change in the end...
> Also we really need some good comment on why the order is
> like the one chose here in this function.
Good point, will add.
--
Jan Kara <jack@suse.cz>
SUSE Labs, CR
^ permalink raw reply
* Re: [BUG] Invalid file descriptor.
From: Daniel Wagner @ 2011-10-24 13:13 UTC (permalink / raw)
To: linux-wireless
In-Reply-To: <4EA53498.7030701@monom.org>
argh, sorry, wrong mailing list.
^ permalink raw reply
* Re: [PATCH] iio:staging: Add documentation for IIO_EVENT_CODE
From: Jonathan Cameron @ 2011-10-24 13:13 UTC (permalink / raw)
To: Lars-Peter Clausen
Cc: Michael Hennerich, linux-iio, device-drivers-devel, drivers
In-Reply-To: <1319461509-17434-1-git-send-email-lars@metafoo.de>
On 10/24/11 14:05, Lars-Peter Clausen wrote:
> Document the different parameters of the IIO_EVENT_CODE macro and friends.
>
> Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
>
> ---
> I'm adding this to get a clear definition of what each field is for, because
> currently there are somewhat contradicting usages of this macro. So I'm not
> quite sure if this is the correct documentation.
What you have is certainly what has intended.
Only suggestion is to perhaps standardise naming as chan_type rather than
having both that and channel_class for the same thing?
>
> ---
> drivers/staging/iio/events.h | 29 +++++++++++++++++++++++++++++
> 1 files changed, 29 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/staging/iio/events.h b/drivers/staging/iio/events.h
> index 389c781..520a20e 100644
> --- a/drivers/staging/iio/events.h
> +++ b/drivers/staging/iio/events.h
> @@ -40,6 +40,18 @@ enum iio_event_direction {
> IIO_EV_DIR_FALLING,
> };
>
> +/**
> + * IIO_EVENT_CODE() - create event identifier
> + * @chan_type: Type of the channel. Should be one of enum iio_chan_type.
> + * @diff: Whether the event is for an differential channel or not.
> + * @modifier: Modifier for the channel. Should be one of enum iio_modifier.
> + * @direction: Direction of the event. Should be one of enum iio_event_direction.
> + * @type: Type of the event. Should be one enum iio_event_type.
> + * @chan: Channel number for non-differential channels.
> + * @chan1: First channel number for differential channels.
> + * @chan2: Second channel number for differential channels.
> + */
> +
> #define IIO_EVENT_CODE(chan_type, diff, modifier, direction, \
> type, chan, chan1, chan2) \
> (((u64)type << 56) | ((u64)diff << 55) | \
> @@ -51,10 +63,27 @@ enum iio_event_direction {
> #define IIO_EV_BIT(type, direction) \
> (1 << (type*IIO_EV_DIR_MAX + direction))
>
> +/**
> + * IIO_MOD_EVENT_CODE() - create event identifier for modified channels
> + * @channelclass: Type of the channel. Should be one of enum iio_chan_type.
Ooops, I hadn't registered the different naming in here. I'd be inclined
to make this chan_type as well - might as well role it into this set.
> + * @number: Channel number for non-differential channels.
True, but given we can't have modified differential channels anyway perhaps
doesn't need to be stated here?
> + * @modifier: Modifier for the channel. Should be one of enum iio_modifier.
> + * @type: Type of the event. Should be one enum iio_event_type.
> + * @direction: Direction of the event. Should be one of enum iio_event_direction.
> + */
> +
> #define IIO_MOD_EVENT_CODE(channelclass, number, modifier, \
> type, direction) \
> IIO_EVENT_CODE(channelclass, 0, modifier, direction, type, number, 0, 0)
>
> +/**
> + * IIO_UNMOD_EVENT_CODE() - create event identifier for unmodified channels
> + * @channelclass: Type of the channel. Should be one of enum iio_chan_type.
same with naming here - switch it to chan_type.
> + * @number: Channel number for non-differential channels.
> + * @type: Type of the event. Should be one enum iio_event_type.
> + * @direction: Direction of the event. Should be one of enum iio_event_direction.
> + */
> +
> #define IIO_UNMOD_EVENT_CODE(channelclass, number, type, direction) \
> IIO_EVENT_CODE(channelclass, 0, 0, direction, type, number, 0, 0)
>
^ permalink raw reply
* [RFC] ARM: at91: gpio add mux check
From: Jean-Christophe PLAGNIOL-VILLARD @ 2011-10-24 13:13 UTC (permalink / raw)
To: linux-arm-kernel
this will check if the pio is not configured as mux first
Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
Cc: Linus Walleij <linus.walleij@stericsson.com>
Cc: swarren at nvidia.com
---
Hi,
one of the the issue is what happened it the bootloader miss
configured a pin a periph A or B?
do we need to keep the tracking of it in the pinmux?
Best Regards,
J.
arch/arm/mach-at91/gpio.c | 15 +++++++++++++++
1 files changed, 15 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-at91/gpio.c b/arch/arm/mach-at91/gpio.c
index 743f668..89761d0 100644
--- a/arch/arm/mach-at91/gpio.c
+++ b/arch/arm/mach-at91/gpio.c
@@ -38,6 +38,7 @@ struct at91_gpio_chip {
#define to_at91_gpio_chip(c) container_of(c, struct at91_gpio_chip, chip)
static void at91_gpiolib_dbg_show(struct seq_file *s, struct gpio_chip *chip);
+static int at91_gpiolib_request(struct gpio_chip *chip, unsigned offset);
static void at91_gpiolib_set(struct gpio_chip *chip, unsigned offset, int val);
static int at91_gpiolib_get(struct gpio_chip *chip, unsigned offset);
static int at91_gpiolib_direction_output(struct gpio_chip *chip,
@@ -49,6 +50,7 @@ static int at91_gpiolib_direction_input(struct gpio_chip *chip,
{ \
.chip = { \
.label = name, \
+ .request = at91_gpiolib_request, \
.direction_input = at91_gpiolib_direction_input, \
.direction_output = at91_gpiolib_direction_output, \
.get = at91_gpiolib_get, \
@@ -532,6 +534,19 @@ void __init at91_gpio_irq_setup(void)
}
/* gpiolib support */
+
+static int at91_gpiolib_request(struct gpio_chip *chip, unsigned offset)
+{
+ struct at91_gpio_chip *at91_gpio = to_at91_gpio_chip(chip);
+ void __iomem *pio = at91_gpio->regbase;
+ unsigned mask = 1 << offset;
+
+ if (__raw_readl(pio + PIO_PSR) & mask)
+ return 0;
+
+ return -EBUSY;
+}
+
static int at91_gpiolib_direction_input(struct gpio_chip *chip,
unsigned offset)
{
--
1.7.7
^ permalink raw reply related
* Re: [Qemu-devel] [PATCH v2 1/4] Add basic version of bridge helper
From: Corey Bryant @ 2011-10-24 13:12 UTC (permalink / raw)
To: Blue Swirl; +Cc: rmarwah, aliguori, qemu-devel
In-Reply-To: <CAAu8pHungyKCLtTmGi9xtXSDVy4zuHcdY4fyDAzmuGKehTKJVg@mail.gmail.com>
On 10/23/2011 08:56 AM, Blue Swirl wrote:
> On Fri, Oct 21, 2011 at 15:07, Corey Bryant<coreyb@linux.vnet.ibm.com> wrote:
>> This patch adds a helper that can be used to create a tap device attached to
>> a bridge device. Since this helper is minimal in what it does, it can be
>> given CAP_NET_ADMIN which allows qemu to avoid running as root while still
>> satisfying the majority of what users tend to want to do with tap devices.
>>
>> The way this all works is that qemu launches this helper passing a bridge
>> name and the name of an inherited file descriptor. The descriptor is one
>> end of a socketpair() of domain sockets. This domain socket is used to
>> transmit a file descriptor of the opened tap device from the helper to qemu.
>>
>> The helper can then exit and let qemu use the tap device.
>>
>> Signed-off-by: Anthony Liguori<aliguori@us.ibm.com>
>> Signed-off-by: Richa Marwaha<rmarwah@linux.vnet.ibm.com>
>> Signed-off-by: Corey Bryant<coreyb@linux.vnet.ibm.com>
>> ---
>> Makefile | 12 +++-
>> configure | 1 +
>> qemu-bridge-helper.c | 205 ++++++++++++++++++++++++++++++++++++++++++++++++++
>> 3 files changed, 216 insertions(+), 2 deletions(-)
>> create mode 100644 qemu-bridge-helper.c
>>
>> diff --git a/Makefile b/Makefile
>> index f63fc02..d9b447e 100644
>> --- a/Makefile
>> +++ b/Makefile
>> @@ -35,6 +35,8 @@ $(call set-vpath, $(SRC_PATH):$(SRC_PATH)/hw)
>>
>> LIBS+=-lz $(LIBS_TOOLS)
>>
>> +HELPERS-$(CONFIG_LINUX) = qemu-bridge-helper$(EXESUF)
>> +
>> ifdef BUILD_DOCS
>> DOCS=qemu-doc.html qemu-tech.html qemu.1 qemu-img.1 qemu-nbd.8 QMP/qmp-commands.txt
>> else
>> @@ -75,7 +77,7 @@ defconfig:
>>
>> -include config-all-devices.mak
>>
>> -build-all: $(DOCS) $(TOOLS) recurse-all
>> +build-all: $(DOCS) $(TOOLS) $(HELPERS-y) recurse-all
>>
>> config-host.h: config-host.h-timestamp
>> config-host.h-timestamp: config-host.mak
>> @@ -153,6 +155,8 @@ qemu-img$(EXESUF): qemu-img.o $(tools-obj-y)
>> qemu-nbd$(EXESUF): qemu-nbd.o $(tools-obj-y)
>> qemu-io$(EXESUF): qemu-io.o cmd.o $(tools-obj-y)
>>
>> +qemu-bridge-helper$(EXESUF): qemu-bridge-helper.o
>> +
>> qemu-img-cmds.h: $(SRC_PATH)/qemu-img-cmds.hx
>> $(call quiet-command,sh $(SRC_PATH)/scripts/hxtool -h< $< > $@," GEN $@")
>>
>> @@ -221,7 +225,7 @@ clean:
>> # avoid old build problems by removing potentially incorrect old files
>> rm -f config.mak op-i386.h opc-i386.h gen-op-i386.h op-arm.h opc-arm.h gen-op-arm.h
>> rm -f qemu-options.def
>> - rm -f *.o *.d *.a *.lo $(TOOLS) qemu-ga TAGS cscope.* *.pod *~ */*~
>> + rm -f *.o *.d *.a *.lo $(TOOLS) $(HELPERS-y) qemu-ga TAGS cscope.* *.pod *~ */*~
>> rm -Rf .libs
>> rm -f slirp/*.o slirp/*.d audio/*.o audio/*.d block/*.o block/*.d net/*.o net/*.d fsdev/*.o fsdev/*.d ui/*.o ui/*.d qapi/*.o qapi/*.d qga/*.o qga/*.d
>> rm -f qemu-img-cmds.h
>> @@ -289,6 +293,10 @@ install: all $(if $(BUILD_DOCS),install-doc) install-sysconfig
>> ifneq ($(TOOLS),)
>> $(INSTALL_PROG) $(STRIP_OPT) $(TOOLS) "$(DESTDIR)$(bindir)"
>> endif
>> +ifneq ($(HELPERS-y),)
>> + $(INSTALL_DIR) "$(DESTDIR)$(libexecdir)"
>> + $(INSTALL_PROG) $(STRIP_OPT) $(HELPERS-y) "$(DESTDIR)$(libexecdir)"
>> +endif
>> ifneq ($(BLOBS),)
>> $(INSTALL_DIR) "$(DESTDIR)$(datadir)"
>> set -e; for x in $(BLOBS); do \
>> diff --git a/configure b/configure
>> index 4f87e0a..6c8b659 100755
>> --- a/configure
>> +++ b/configure
>> @@ -2768,6 +2768,7 @@ echo "datadir=$datadir">> $config_host_mak
>> echo "sysconfdir=$sysconfdir">> $config_host_mak
>> echo "docdir=$docdir">> $config_host_mak
>> echo "confdir=$confdir">> $config_host_mak
>> +echo "libexecdir=\${prefix}/libexec">> $config_host_mak
>>
>> case "$cpu" in
>> i386|x86_64|alpha|cris|hppa|ia64|lm32|m68k|microblaze|mips|mips64|ppc|ppc64|s390|s390x|sparc|sparc64|unicore32)
>> diff --git a/qemu-bridge-helper.c b/qemu-bridge-helper.c
>> new file mode 100644
>> index 0000000..2ce82fb
>> --- /dev/null
>> +++ b/qemu-bridge-helper.c
>> @@ -0,0 +1,205 @@
>> +/*
>> + * QEMU Bridge Helper
>> + *
>> + * Copyright IBM, Corp. 2011
>> + *
>> + * Authors:
>> + * Anthony Liguori<aliguori@us.ibm.com>
>> + *
>> + * This work is licensed under the terms of the GNU GPL, version 2. See
>> + * the COPYING file in the top-level directory.
>> + *
>> + */
>> +
>> +#include "config-host.h"
>> +
>> +#include<stdio.h>
>> +#include<errno.h>
>> +#include<fcntl.h>
>> +#include<unistd.h>
>> +#include<string.h>
>> +#include<stdlib.h>
>> +#include<ctype.h>
>> +
>> +#include<sys/types.h>
>> +#include<sys/ioctl.h>
>> +#include<sys/socket.h>
>> +#include<sys/un.h>
>> +#include<sys/prctl.h>
>> +
>> +#include<net/if.h>
>> +
>> +#include<linux/sockios.h>
>> +
>> +#include "net/tap-linux.h"
>> +
>> +static int has_vnet_hdr(int fd)
>> +{
>> + unsigned int features = 0;
>> + struct ifreq ifreq;
>> +
>> + if (ioctl(fd, TUNGETFEATURES,&features) == -1) {
>> + return -errno;
>> + }
>> +
>> + if (!(features& IFF_VNET_HDR)) {
>> + return -ENOTSUP;
>> + }
>> +
>> + if (ioctl(fd, TUNGETIFF,&ifreq) != -1 || errno != EBADFD) {
>> + return -ENOTSUP;
>> + }
>> +
>> + return 1;
>> +}
>> +
>> +static void prep_ifreq(struct ifreq *ifr, const char *ifname)
>> +{
>> + memset(ifr, 0, sizeof(*ifr));
>> + snprintf(ifr->ifr_name, IFNAMSIZ, "%s", ifname);
>> +}
>> +
>> +static int send_fd(int c, int fd)
>> +{
>> + char msgbuf[CMSG_SPACE(sizeof(fd))];
>> + struct msghdr msg = {
>> + .msg_control = msgbuf,
>> + .msg_controllen = sizeof(msgbuf),
>> + };
>> + struct cmsghdr *cmsg;
>> + struct iovec iov;
>> + char req[1] = { 0x00 };
>> +
>> + cmsg = CMSG_FIRSTHDR(&msg);
>> + cmsg->cmsg_level = SOL_SOCKET;
>> + cmsg->cmsg_type = SCM_RIGHTS;
>> + cmsg->cmsg_len = CMSG_LEN(sizeof(fd));
>> + msg.msg_controllen = cmsg->cmsg_len;
>> +
>> + iov.iov_base = req;
>> + iov.iov_len = sizeof(req);
>> +
>> + msg.msg_iov =&iov;
>> + msg.msg_iovlen = 1;
>> + memcpy(CMSG_DATA(cmsg),&fd, sizeof(fd));
>> +
>> + return sendmsg(c,&msg, 0);
>> +}
>> +
>> +int main(int argc, char **argv)
>> +{
>> + struct ifreq ifr;
>> + int fd, ctlfd, unixfd;
>> + int use_vnet = 0;
>> + int mtu;
>> + const char *bridge;
>> + char iface[IFNAMSIZ];
>> + int index;
>> +
>> + /* parse arguments */
>> + if (argc< 3 || argc> 4) {
>> + fprintf(stderr, "Usage: %s [--use-vnet] BRIDGE FD\n", argv[0]);
>> + return 1;
>> + }
>> +
>> + index = 1;
>> + if (strcmp(argv[index], "--use-vnet") == 0) {
>> + use_vnet = 1;
>> + index++;
>> + if (argc == 3) {
>> + fprintf(stderr, "invalid number of arguments\n");
>> + return -1;
>> + }
>> + }
>> +
>> + bridge = argv[index++];
>> + unixfd = atoi(argv[index++]);
>> +
>> + /* open a socket to use to control the network interfaces */
>> + ctlfd = socket(AF_INET, SOCK_STREAM, 0);
>> + if (ctlfd == -1) {
>> + fprintf(stderr, "failed to open control socket\n");
>> + return -errno;
>> + }
>> +
>> + /* open the tap device */
>> + fd = open("/dev/net/tun", O_RDWR);
>> + if (fd == -1) {
>> + fprintf(stderr, "failed to open /dev/net/tun\n");
>> + return -errno;
>> + }
>> +
>> + /* request a tap device, disable PI, and add vnet header support if
>> + * requested and it's available. */
>> + prep_ifreq(&ifr, "tap%d");
>> + ifr.ifr_flags = IFF_TAP|IFF_NO_PI;
>> + if (use_vnet&& has_vnet_hdr(fd)) {
>> + ifr.ifr_flags |= IFF_VNET_HDR;
>> + }
>> +
>> + if (ioctl(fd, TUNSETIFF,&ifr) == -1) {
>> + fprintf(stderr, "failed to create tun device\n");
>> + return -errno;
>> + }
>> +
>> + /* save tap device name */
>> + snprintf(iface, sizeof(iface), "%s", ifr.ifr_name);
>> +
>> + /* get the mtu of the bridge */
>> + prep_ifreq(&ifr, bridge);
>> + if (ioctl(ctlfd, SIOCGIFMTU,&ifr) == -1) {
>> + fprintf(stderr, "failed to get mtu of bridge `%s'\n", bridge);
>> + return -errno;
>> + }
>> +
>> + /* save mtu */
>> + mtu = ifr.ifr_mtu;
>> +
>> + /* set the mtu of the interface based on the bridge */
>> + prep_ifreq(&ifr, iface);
>> + ifr.ifr_mtu = mtu;
>> + if (ioctl(ctlfd, SIOCSIFMTU,&ifr) == -1) {
>> + fprintf(stderr, "failed to set mtu of device `%s' to %d\n",
>> + iface, mtu);
>> + return -errno;
>> + }
>> +
>> + /* add the interface to the bridge */
>> + prep_ifreq(&ifr, bridge);
>> + ifr.ifr_ifindex = if_nametoindex(iface);
>> +
>> + if (ioctl(ctlfd, SIOCBRADDIF,&ifr) == -1) {
>> + fprintf(stderr, "failed to add interface `%s' to bridge `%s'\n",
>> + iface, bridge);
>> + return -errno;
>> + }
>> +
>> + /* bring the interface up */
>> + prep_ifreq(&ifr, iface);
>> + if (ioctl(ctlfd, SIOCGIFFLAGS,&ifr) == -1) {
>> + fprintf(stderr, "failed to get interface flags for `%s'\n", iface);
>> + return -errno;
>> + }
>> +
>> + ifr.ifr_flags |= IFF_UP;
>> + if (ioctl(ctlfd, SIOCSIFFLAGS,&ifr) == -1) {
>> + fprintf(stderr, "failed to set bring up interface `%s'\n", iface);
>> + return -errno;
>> + }
>
> It looks like only the above series of ioctls is Linux specific. I'm
> not familiar if other OS could support similar bridges, if so, it
> would be better to contain the bridge setup in a separate function.
> This can be done later though.
>
I agree.
>> +
>> + /* write fd to the domain socket */
>> + if (send_fd(unixfd, fd) == -1) {
>> + fprintf(stderr, "failed to write fd to unix socket\n");
>> + return -errno;
>> + }
>> +
>> + /* ... */
>> +
>> + /* profit! */
>> +
>> + close(fd);
>> +
>> + close(ctlfd);
>> +
>> + return 0;
>> +}
>> --
>> 1.7.3.4
>>
>>
>>
>
--
Regards,
Corey
^ permalink raw reply
* [PATCH] regmap: Fix word wrap in Makefile
From: Mark Brown @ 2011-10-24 13:12 UTC (permalink / raw)
To: linux-kernel; +Cc: patches, Mark Brown
80 columns FTW.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
---
drivers/base/regmap/Makefile | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/base/regmap/Makefile b/drivers/base/regmap/Makefile
index 0573c8a..f331a90 100644
--- a/drivers/base/regmap/Makefile
+++ b/drivers/base/regmap/Makefile
@@ -1,4 +1,5 @@
-obj-$(CONFIG_REGMAP) += regmap.o regcache.o regcache-indexed.o regcache-rbtree.o regcache-lzo.o
+obj-$(CONFIG_REGMAP) += regmap.o regcache.o regcache-indexed.o
+obj-$(CONFIG_REGMAP) += regcache-rbtree.o regcache-lzo.o
obj-$(CONFIG_DEBUG_FS) += regmap-debugfs.o
obj-$(CONFIG_REGMAP_I2C) += regmap-i2c.o
obj-$(CONFIG_REGMAP_SPI) += regmap-spi.o
--
1.7.6.3
^ permalink raw reply related
* [PATCH] module,bug: Add TAINT_OOT_MODULE flag for modules not built in-tree
From: Ben Hutchings @ 2011-10-24 13:12 UTC (permalink / raw)
To: LKML; +Cc: Dave Jones, Greg KH, Debian kernel maintainers, Rusty Russell
Use of the GPL or a compatible licence doesn't necessarily make the code
any good. We already consider staging modules to be suspect, and this
should also be true for out-of-tree modules which may receive very
little review.
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
---
Debian has been carrying this for the last few kernel versions. The
recent thread '[RFC] virtualbox tainting.' and discussions at KS suggest
that this might be more generally useful.
Ben.
include/linux/kernel.h | 1 +
kernel/module.c | 5 +++++
kernel/panic.c | 2 ++
scripts/mod/modpost.c | 7 +++++++
4 files changed, 15 insertions(+), 0 deletions(-)
diff --git a/include/linux/kernel.h b/include/linux/kernel.h
index 46ac9a5..2c05967 100644
--- a/include/linux/kernel.h
+++ b/include/linux/kernel.h
@@ -369,6 +369,7 @@ extern enum system_states {
#define TAINT_WARN 9
#define TAINT_CRAP 10
#define TAINT_FIRMWARE_WORKAROUND 11
+#define TAINT_OOT_MODULE 12
extern const char hex_asc[];
#define hex_asc_lo(x) hex_asc[((x) & 0x0f)]
diff --git a/kernel/module.c b/kernel/module.c
index 04379f92..c0872f1 100644
--- a/kernel/module.c
+++ b/kernel/module.c
@@ -2487,6 +2487,9 @@ static int check_modinfo(struct module *mod, struct load_info *info)
return -ENOEXEC;
}
+ if (!get_modinfo(info, "intree"))
+ add_taint_module(mod, TAINT_OOT_MODULE);
+
if (get_modinfo(info, "staging")) {
add_taint_module(mod, TAINT_CRAP);
printk(KERN_WARNING "%s: module is from the staging directory,"
@@ -3257,6 +3260,8 @@ static char *module_flags(struct module *mod, char *buf)
buf[bx++] = '(';
if (mod->taints & (1 << TAINT_PROPRIETARY_MODULE))
buf[bx++] = 'P';
+ else if (mod->taints & (1 << TAINT_OOT_MODULE))
+ buf[bx++] = 'O';
if (mod->taints & (1 << TAINT_FORCED_MODULE))
buf[bx++] = 'F';
if (mod->taints & (1 << TAINT_CRAP))
diff --git a/kernel/panic.c b/kernel/panic.c
index d7bb697..b2659360 100644
--- a/kernel/panic.c
+++ b/kernel/panic.c
@@ -177,6 +177,7 @@ static const struct tnt tnts[] = {
{ TAINT_WARN, 'W', ' ' },
{ TAINT_CRAP, 'C', ' ' },
{ TAINT_FIRMWARE_WORKAROUND, 'I', ' ' },
+ { TAINT_OOT_MODULE, 'O', ' ' },
};
/**
@@ -194,6 +195,7 @@ static const struct tnt tnts[] = {
* 'W' - Taint on warning.
* 'C' - modules from drivers/staging are loaded.
* 'I' - Working around severe firmware bug.
+ * 'O' - Out-of-tree module has been loaded.
*
* The string is overwritten by the next call to print_tainted().
*/
diff --git a/scripts/mod/modpost.c b/scripts/mod/modpost.c
index a509ff8..2bd594e 100644
--- a/scripts/mod/modpost.c
+++ b/scripts/mod/modpost.c
@@ -1849,6 +1849,12 @@ static void add_header(struct buffer *b, struct module *mod)
buf_printf(b, "};\n");
}
+static void add_intree_flag(struct buffer *b, int is_intree)
+{
+ if (is_intree)
+ buf_printf(b, "\nMODULE_INFO(intree, \"Y\");\n");
+}
+
static void add_staging_flag(struct buffer *b, const char *name)
{
static const char *staging_dir = "drivers/staging";
@@ -2169,6 +2175,7 @@ int main(int argc, char **argv)
buf.pos = 0;
add_header(&buf, mod);
+ add_intree_flag(&buf, !external_module);
add_staging_flag(&buf, mod->name);
err |= add_versions(&buf, mod);
add_depends(&buf, mod, modules);
--
1.7.7
^ permalink raw reply related
* Re: Is locking problem in snd_intel8x0_pcm_pointer() ?
From: Takashi Iwai @ 2011-10-24 13:11 UTC (permalink / raw)
To: Konstantin Ozerkov; +Cc: alsa-devel@alsa-project.org, Denis Lunev
In-Reply-To: <4EA5509C.9030504@parallels.com>
At Mon, 24 Oct 2011 15:48:44 +0400,
Konstantin Ozerkov wrote:
>
> Seems that locking is broken: snd_intel8x0_pcm_pointer() uses spin_lock()/spin_unlock() semantic
> for lock which is shared in ISR ( snd_intel8x0_update). As result we got possible deadlock inside ISR
> on UP system. And needed special kludge inside snd_intel8x0_pcm_pointer() to prevent moving
> backward (really this is race with snd_intel8x0_update).
Hm, could you elaborate how can it a problem?
snd_intel8x0_update() releases the lock before calling
snd_pcm_period_update() that calls the pointer callback.
Takashi
^ permalink raw reply
* Re: Memory leak in isp1760-hcd.c
From: Catalin Marinas @ 2011-10-24 13:11 UTC (permalink / raw)
To: Arvid Brodin; +Cc: linux-usb, linux-kernel
In-Reply-To: <4EA55F0B.1070906@enea.com>
On 24 October 2011 14:50, Arvid Brodin <arvid.brodin@enea.com> wrote:
> Catalin Marinas wrote:
>> I get the following kmemleak report coming from the ISP1760 driver:
>>
> *snip*
>>
>> Is there a race condition between isp1760_endpoint_disable and
>> isp1760_irq?
>
> Yes, I think there is. Thanks for a great bug report!
>
> Please try the patches in following emails.
Thanks. I'll try them next week as I'm at the KS now.
The good news, I'm using this leak as an example in my kmemleak presentations :)
--
Catalin
^ permalink raw reply
* Converting from Raid 5 to 6
From: Michael Busby @ 2011-10-24 13:11 UTC (permalink / raw)
To: linux-raid
At the moment i have a raid5 setup with 5 disks, i am looking to add a
6th disk and change from raid 5 to raid 6
having looked at Neil's site i have found the following command, and
just want to double check this is still the recommend way of
converting
mdadm --grow /dev/md0 --level=6 --raid-disks=6 --backup-file=/home/md.backup
also would i need to add the extra disk before or after the command?
cheers
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [RFC][PATCH] KVM: Introduce direct MSI message injection for in-kernel irqchips
From: Jan Kiszka @ 2011-10-24 13:11 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: Avi Kivity, Marcelo Tosatti, kvm
In-Reply-To: <20111024124355.GA28822@redhat.com>
On 2011-10-24 14:43, Michael S. Tsirkin wrote:
> On Mon, Oct 24, 2011 at 02:06:08PM +0200, Jan Kiszka wrote:
>> On 2011-10-24 13:09, Avi Kivity wrote:
>>> On 10/24/2011 12:19 PM, Jan Kiszka wrote:
>>>>>
>>>>> With the new feature it may be worthwhile, but I'd like to see the whole
>>>>> thing, with numbers attached.
>>>>
>>>> It's not a performance issue, it's a resource limitation issue: With the
>>>> new API we can stop worrying about user space device models consuming
>>>> limited IRQ routes of the KVM subsystem.
>>>>
>>>
>>> Only if those devices are in the same process (or have access to the
>>> vmfd). Interrupt routing together with irqfd allows you to disaggregate
>>> the device model. Instead of providing a competing implementation with
>>> new limitations, we need to remove the limitations of the old
>>> implementation.
>>
>> That depends on where we do the cut. Currently we let the IRQ source
>> signal an abstract edge on a pre-allocated pseudo IRQ line. But we
>> cannot build correct MSI-X on top of the current irqfd model as we lack
>> the level information (for PBA emulation). *)
>
>
> I don't agree here. IMO PBA emulation would need to
> clear pending bits on interrupt status register read.
> So clearing pending bits could be done by ioctl from qemu
> while setting them would be done from irqfd.
How should QEMU know if the reason for "pending" has been cleared at
device level if the device is outside the scope of QEMU? This model only
works for PV devices when you agree that spurious IRQs are OK.
>
>> So we either need to
>> extend the existing model anyway -- or push per-vector masking back to
>> the IRQ source. In the latter case, it would be a very good chance to
>> give up on limited pseudo GSIs with static routes and do MSI messaging
>> from external IRQ sources to KVM directly.
>> But all those considerations affect different APIs than what I'm
>> proposing here. We will always need a way to inject MSIs in the context
>> of the VM as there will always be scenarios where devices are better run
>> in that very same context, for performance or simplicity or whatever
>> reasons. E.g., I could imagine that one would like to execute an
>> emulated IRQ remapper rather in the hypervisor context than
>> "over-microkernelized" in a separate process.
>>
>> Jan
>>
>> *) Realized this while trying to generalize the proposed MSI-X MMIO
>> acceleration for assigned devices to arbitrary device models, vhost-net,
>
> I'm actually working on a qemu patch to get pba emulation working correctly.
> I think it's doable with existing irqfd.
irqfd has no notion of level. You can only communicate a rising edge and
then need a side channel for the state of the edge reason.
>
>> and specifically vfio.
>
> Interesting. How would you clear the pseudo interrupt level?
Ideally: not at all (for MSI). If we manage the mask at device level, we
only need to send the message if there is actually something to deliver
to the interrupt controller and masked input events would be lost on
real HW as well.
That said, we still need to address the irqfd level topic for the finite
amount of legacy interrupt lines. If a line is masked at an IRQ
controller, the device need to keep the controller up to date /wrt to
the line state, or the controller has to poll the current state on
unmask to avoid spurious injections.
Jan
--
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux
^ permalink raw reply
* Re: [PATCH] TTY: pty, fix pty counting
From: Jiri Slaby @ 2011-10-24 13:11 UTC (permalink / raw)
To: Ilya Zykov; +Cc: Greg Kroah-Hartman, Alan Cox, linux-kernel, Jiri Slaby
In-Reply-To: <4EA48094.8020508@ilyx.ru>
On 10/23/2011 11:01 PM, Ilya Zykov wrote:
> New version for commit: 24d406a6bf736f7aebdc8fa0f0ec86e0890c6d24
Although it will work, as ptms are not allowed to be reopen, it doesn't
look correct. We should decrement the count in ->remove, because we are
incrementing in install.
Now, when I understand ptm+devpts layer a bit more, instead of the
current hackish approach introduced by 24d406a6b (TTY: pty, fix pty
counting), I think we may introduce a ->remove hook specific to ptms. In
that one we could decrement the count and don't bother with the
pty_count macros anymore. Right?
BTW you cannot remove ->remove hook of pty layer. It would cause an OOPS
because driver->ttys is not allocated for ptys.
> diff -uprN a/drivers/tty/pty.c b/drivers/tty/pty.c
> --- a/drivers/tty/pty.c 2011-05-19 08:06:34.000000000 +0400
> +++ b/drivers/tty/pty.c 2011-10-23 18:01:20.000000000 +0400
> @@ -36,13 +36,15 @@
> static struct tty_driver *ptm_driver;
> static struct tty_driver *pts_driver;
> #endif
> +static int pty_count;
>
> static void pty_close(struct tty_struct *tty, struct file *filp)
> {
> BUG_ON(!tty);
> - if (tty->driver->subtype == PTY_TYPE_MASTER)
> + if (tty->driver->subtype == PTY_TYPE_MASTER) {
> WARN_ON(tty->count > 1);
> - else {
> + pty_count--;
> + } else {
> if (tty->count > 2)
> return;
> }
> @@ -446,7 +448,6 @@ static inline void legacy_pty_init(void)
> int pty_limit = NR_UNIX98_PTY_DEFAULT;
> static int pty_limit_min;
> static int pty_limit_max = NR_UNIX98_PTY_MAX;
> -static int pty_count;
>
> static struct cdev ptmx_cdev;
>
> @@ -599,15 +600,9 @@ free_mem_out:
> return -ENOMEM;
> }
>
> -static void pty_unix98_remove(struct tty_driver *driver, struct tty_struct *tty)
> -{
> - pty_count--;
> -}
> -
> static const struct tty_operations ptm_unix98_ops = {
> .lookup = ptm_unix98_lookup,
> .install = pty_unix98_install,
> - .remove = pty_unix98_remove,
> .open = pty_open,
> .close = pty_close,
> .write = pty_write,
> @@ -624,7 +619,6 @@ static const struct tty_operations ptm_u
> static const struct tty_operations pty_unix98_ops = {
> .lookup = pts_unix98_lookup,
> .install = pty_unix98_install,
> - .remove = pty_unix98_remove,
> .open = pty_open,
> .close = pty_close,
> .write = pty_write,
thanks,
--
js
suse labs
^ permalink raw reply
* Re: [PATCH RFC V2 3/5] kvm hypervisor : Add two hypercalls to support pv-ticketlock
From: Avi Kivity @ 2011-10-24 13:09 UTC (permalink / raw)
To: Srivatsa Vaddagiri
Cc: Raghavendra K T, Greg Kroah-Hartman, H. Peter Anvin, Gleb Natapov,
Virtualization, Jeremy Fitzhardinge, x86, KVM, Dave Jiang,
Thomas Gleixner, Stefano Stabellini, Xen, Sedat Dilek, Yinghai Lu,
Marcelo Tosatti, Ingo Molnar, Rik van Riel, Konrad Rzeszutek Wilk,
LKML, Suzuki Poulose, Peter Zijlstra
In-Reply-To: <20111024122734.GA10634@linux.vnet.ibm.com>
On 10/24/2011 02:27 PM, Srivatsa Vaddagiri wrote:
> Good point. Assuming yield_on_hlt=1, that would allow the vcpu to be put
> to sleep and let other vcpus make progress.
>
> I guess with that change, we can also dropthe need for other hypercall
> introduced in this patch (kvm_pv_kick_cpu_op()). Essentially a vcpu sleeping
> because of HLT instruction can be woken up by a IPI issued by vcpu releasing a
> lock.
Not if interrupts are disabled. My original plan was to use NMIs for
wakeups, but it turns out NMIs can be coalesced under certain rare
circumstances; this requires workarounds by the generic NMI code that
make NMIs too slow.
--
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.
^ permalink raw reply
* [PATCH] mfd: Remove unused wm831x_irq_data_to_mask_reg()
From: Mark Brown @ 2011-10-24 13:10 UTC (permalink / raw)
To: Samuel Ortiz; +Cc: linux-kernel, patches, Mark Brown
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
---
drivers/mfd/wm831x-irq.c | 5 -----
1 files changed, 0 insertions(+), 5 deletions(-)
diff --git a/drivers/mfd/wm831x-irq.c b/drivers/mfd/wm831x-irq.c
index f4747a4..7be5f09 100644
--- a/drivers/mfd/wm831x-irq.c
+++ b/drivers/mfd/wm831x-irq.c
@@ -325,11 +325,6 @@ static inline int irq_data_to_status_reg(struct wm831x_irq_data *irq_data)
return WM831X_INTERRUPT_STATUS_1 - 1 + irq_data->reg;
}
-static inline int irq_data_to_mask_reg(struct wm831x_irq_data *irq_data)
-{
- return WM831X_INTERRUPT_STATUS_1_MASK - 1 + irq_data->reg;
-}
-
static inline struct wm831x_irq_data *irq_to_wm831x_irq(struct wm831x *wm831x,
int irq)
{
--
1.7.6.3
^ permalink raw reply related
* Xen two tree at kernel.org
From: Konrad Rzeszutek Wilk @ 2011-10-24 13:09 UTC (permalink / raw)
To: sfr; +Cc: linux-kernel
Heya Stephen,
Could you move the #xen-two link to point at
git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git #linux-next
please?
^ permalink raw reply
* Re: [patch net-next V4] net: introduce ethernet teaming device
From: Benjamin Poirier @ 2011-10-24 13:09 UTC (permalink / raw)
To: Jiri Pirko
Cc: netdev, davem, eric.dumazet, bhutchings, shemminger, fubar, andy,
tgraf, ebiederm, mirqus, kaber, greearb, jesse, fbl, jzupka,
Dipankar Sarma, Paul E. McKenney
In-Reply-To: <1319444005-1281-1-git-send-email-jpirko@redhat.com>
On 11/10/24 10:13, Jiri Pirko wrote:
> This patch introduces new network device called team. It supposes to be
> very fast, simple, userspace-driven alternative to existing bonding
> driver.
>
> Userspace library called libteam with couple of demo apps is available
> here:
> https://github.com/jpirko/libteam
> Note it's still in its dipers atm.
>
> team<->libteam use generic netlink for communication. That and rtnl
> suppose to be the only way to configure team device, no sysfs etc.
>
> Python binding basis for libteam was recently introduced (some need
> still need to be done on it though). Daemon providing arpmon/miimon
> active-backup functionality will be introduced shortly.
> All what's necessary is already implemented in kernel team driver.
>
> Signed-off-by: Jiri Pirko <jpirko@redhat.com>
>
> v3->v4:
> - remove redundant synchronize_rcu from __team_change_mode()
> - revert "set and clear of mode_ops happens per pointer, not per
> byte"
> - extend comment of function __team_change_mode()
>
> v2->v3:
> - team_change_mtu() user rcu version of list traversal to unwind
> - set and clear of mode_ops happens per pointer, not per byte
> - port hashlist changed to be embedded into team structure
> - error branch in team_port_enter() does cleanup now
> - fixed rtln->rtnl
>
> v1->v2:
> - modes are made as modules. Makes team more modular and
> extendable.
> - several commenters' nitpicks found on v1 were fixed
> - several other bugs were fixed.
> - note I ignored Eric's comment about roundrobin port selector
> as Eric's way may be easily implemented as another mode (mode
> "random") in future.
> ---
> Documentation/networking/team.txt | 2 +
> MAINTAINERS | 7 +
> drivers/net/Kconfig | 2 +
> drivers/net/Makefile | 1 +
> drivers/net/team/Kconfig | 38 +
> drivers/net/team/Makefile | 7 +
> drivers/net/team/team.c | 1573 +++++++++++++++++++++++++++++
> drivers/net/team/team_mode_activebackup.c | 152 +++
> drivers/net/team/team_mode_roundrobin.c | 107 ++
> include/linux/Kbuild | 1 +
> include/linux/if.h | 1 +
> include/linux/if_team.h | 231 +++++
> include/linux/rculist.h | 14 +
I think you're missing some CC's for the modifications to this file.
I've taken the liberty of adding Dipankar and Paul to the discussion.
> 13 files changed, 2136 insertions(+), 0 deletions(-)
> create mode 100644 Documentation/networking/team.txt
> create mode 100644 drivers/net/team/Kconfig
> create mode 100644 drivers/net/team/Makefile
> create mode 100644 drivers/net/team/team.c
> create mode 100644 drivers/net/team/team_mode_activebackup.c
> create mode 100644 drivers/net/team/team_mode_roundrobin.c
> create mode 100644 include/linux/if_team.h
>
[...]
> diff --git a/drivers/net/team/team.c b/drivers/net/team/team.c
> new file mode 100644
> index 0000000..acfef4c
> --- /dev/null
> +++ b/drivers/net/team/team.c
> +
[...]
> +static int team_change_mtu(struct net_device *dev, int new_mtu)
> +{
> + struct team *team = netdev_priv(dev);
> + struct team_port *port;
> + int err;
> +
> + rcu_read_lock();
> + list_for_each_entry_rcu(port, &team->port_list, list) {
> + err = dev_set_mtu(port->dev, new_mtu);
> + if (err) {
> + netdev_err(dev, "Device %s failed to change mtu",
> + port->dev->name);
> + goto unwind;
> + }
> + }
> + rcu_read_unlock();
> +
> + dev->mtu = new_mtu;
> +
> + return 0;
> +
> +unwind:
> + list_for_each_entry_continue_reverse_rcu(port, &team->port_list, list)
> + dev_set_mtu(port->dev, dev->mtu);
> +
> + rcu_read_unlock();
> + return err;
> +}
> +
> +
[...]
> diff --git a/include/linux/rculist.h b/include/linux/rculist.h
> index d079290..7586b2c 100644
> --- a/include/linux/rculist.h
> +++ b/include/linux/rculist.h
> @@ -288,6 +288,20 @@ static inline void list_splice_init_rcu(struct list_head *list,
> pos = list_entry_rcu(pos->member.next, typeof(*pos), member))
>
> /**
> + * list_for_each_entry_continue_reverse_rcu - iterate backwards from the given point
> + * @pos: the type * to use as a loop cursor.
> + * @head: the head for your list.
> + * @member: the name of the list_struct within the struct.
> + *
> + * Start to iterate over list of given type backwards, continuing after
> + * the current position.
> + */
> +#define list_for_each_entry_continue_reverse_rcu(pos, head, member) \
> + for (pos = list_entry_rcu(pos->member.prev, typeof(*pos), member); \
> + &pos->member != (head); \
> + pos = list_entry_rcu(pos->member.prev, typeof(*pos), member))
> +
rcu lists can be modified while they are traversed with *_rcu()
primitives. This benefit comes with the constraint that they may only be
traversed forwards. This is implicit in the choice of *_rcu()
list-traversal primitives: they only go forwards.
You suggest to add a backwards rcu list-traversal primitive. But
consider what happens in this sequence:
CPU0 CPU1
list_for_each_entry_continue_reverse_rcu(...)
pos = list_entry_rcu(pos->member.prev, typeof(*pos), member)
list_del_rcu(&pos->member)
{ (&pos->member)->prev = LIST_POISON2 }
pos = list_entry_rcu(pos->member.prev, typeof(*pos), member)
= container_of(LIST_POISON2, typeof(*pos), member)
do_something(*pos)
BAM!
Going back to the problem you're trying to solve in team_change_mtu(),
I think you could either:
1) take team->lock instead of rcu_read_lock() throughout this particular
function
2) save each deleted element in a separate list on the side in case it's
necessary to roll back
3) remove the rcu double locking, rely on rtnl and add some
ASSERT_RTNL() if desired. You've said that you don't want to rely on
rtnl and you want to use separate locking but I fail to see what
advantage that brings to balance out the extra complexity in code and
execution? Please clarify this.
Thanks,
-Ben
> +/**
> * hlist_del_rcu - deletes entry from hash list without re-initialization
> * @n: the element to delete from the hash list.
> *
> --
> 1.7.6
>
^ permalink raw reply
* Re: [PATCH 1/2] x86 swiotlb: Verify we can perform the remapping requested.
From: Konrad Rzeszutek Wilk @ 2011-10-21 0:40 UTC (permalink / raw)
To: Eric W. Biederman, fujita.tomonori
Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, x86, linux-kernel
In-Reply-To: <m1lisj48q1.fsf@fess.ebiederm.org>
On Mon, Oct 17, 2011 at 02:19:18PM -0700, Eric W. Biederman wrote:
>
> Recently I had a driver try with a peculiar 2G dma memory limit.
> It failed in weird and strange ways because my bounce buffers were
> being allocated above 2G where the driver could not reach, and
> no error was reported when the mappings were setup.
OK, so the overflow buffer was used instead.. which presumarily
also was allocated above the 2G? That seems to point that
alloc_bootmem_low_pages is not doing its job?
>
> Use the swiotlb_dma_supported to avoid silent problems like this
> in the future.
Which driver was it that had this limit?
>
> Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
I also CC-ed Fujita on this as he is the swiotlb maintainer.
> ---
> arch/x86/kernel/pci-swiotlb.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/arch/x86/kernel/pci-swiotlb.c b/arch/x86/kernel/pci-swiotlb.c
> index 8f972cb..6a802fa 100644
> --- a/arch/x86/kernel/pci-swiotlb.c
> +++ b/arch/x86/kernel/pci-swiotlb.c
> @@ -38,7 +38,7 @@ static struct dma_map_ops swiotlb_dma_ops = {
> .unmap_sg = swiotlb_unmap_sg_attrs,
> .map_page = swiotlb_map_page,
> .unmap_page = swiotlb_unmap_page,
> - .dma_supported = NULL,
> + .dma_supported = swiotlb_dma_supported,
> };
>
> /*
> --
> 1.7.2.5
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply
* [PATCH] Shrink thread_info a bit
From: Russell King - ARM Linux @ 2011-10-24 13:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20111024130619.GE26649@sapphire.tkos.co.il>
On Mon, Oct 24, 2011 at 03:06:19PM +0200, Baruch Siach wrote:
> Hi Russell,
>
> On Mon, Oct 24, 2011 at 01:48:18PM +0100, Russell King - ARM Linux wrote:
> > Thread info comes in on Versatile Express at 752 bytes in size, which
> > is quite large. Of this, the crunch state is 184 bytes, which is only
> > used on Cirrus Logic devices.
> >
> > It is wasteful to have this in every kernel when Cirrus Logic CPUs
> > are not that widely used. So make this conditional.
> >
> > Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
> > ---
> > arch/arm/include/asm/thread_info.h | 2 ++
> > arch/arm/kernel/asm-offsets.c | 2 ++
> > 2 files changed, 4 insertions(+), 0 deletions(-)
> >
> > diff --git a/arch/arm/include/asm/thread_info.h b/arch/arm/include/asm/thread_info.h
> > index 7b5cc8d..a030be7 100644
> > --- a/arch/arm/include/asm/thread_info.h
> > +++ b/arch/arm/include/asm/thread_info.h
> > @@ -59,7 +59,9 @@ struct thread_info {
> > __u32 syscall; /* syscall number */
> > __u8 used_cp[16]; /* thread used copro */
> > unsigned long tp_value;
> > +#ifdef CONFIG_CRUNCH
> > struct crunch_state crunchstate;
> > +#endif
> > union fp_state fpstate __attribute__((aligned(8)));
> > union vfp_state vfpstate;
> > #ifdef CONFIG_ARM_THUMBEE
>
> Where is the arch/arm/kernel/asm-offsets.c hunk?
Have you looked there?
^ permalink raw reply
* [GIT PULL] (xen) stable/drivers-3.2, stable/drivers.bugfixes-3.2 and stable/pci.fixes-3.2 for Linux 3.2-rc0
From: Konrad Rzeszutek Wilk @ 2011-10-24 12:54 UTC (permalink / raw)
To: torvalds, linux-kernel
Cc: dan.carpenter, dgdegra, jbeulich, olaf, rdunlap,
stefano.stabellini, thomas, Ian.Campbell
[-- Attachment #1: Type: text/plain, Size: 4623 bytes --]
Hey Linus,
Please pull the three following git branches:
git pull git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git stable/drivers-3.2 stable/drivers.bugfixes-3.2 stable/pci.fixes-3.2
wherein:
#stable/drivers-3.2 is based on git commit 02f8c6aee8df3cdc935e9bdd4f2d020306035dbe (Linux 3.0)
and contains improvements the XenBus driver to reset and restart PV drivers when a guest
is kexec/kdump-ing itself. Also we modify the XenBus subsystem to allow the daemon (which
is in charge all of the XenBus directories/files/attributes) to be present in any domain - not
just the initial one. This slowly paves the way for disegregating guests and allowing device
driver domains.
#stable/drivers.bugfixes-3.2 is based on git commit b6fd41e29dea9c6753b1843a77e50433e6123bcb (Linux 3.1-rc6)
and contains bug-fixes to the Xen PCI backend driver and as well the Xen PCI platform driver.
Nothing really exciting in there - just the normal variety of bug-fixes found
during 3.1 cycle.
#stable/pci.fixes-3.2 is based on git commit 02f8c6aee8df3cdc935e9bdd4f2d020306035dbe (Linux 3.0)
and contains fixes to the Xen PCI frontend driver and the Xen SWIOTLB driver (fixes that
were in the native SWIOTLB driver). Also there is now support for multi-PCI domain boxes,
better reporting of errors, and checking by Xen SWIOTLB of arguments so that it won't
have to do needless work.
The credit list is as follow:
Dan Carpenter (1):
xen/pciback: double lock typo
Daniel De Graaf (2):
xenbus: Fix loopback event channel assuming domain 0
xenbus: don't rely on xen_initial_domain to detect local xenstore
Jan Beulich (4):
xen/pci: make bus notifier handler return sane values
xen/pciback: use mutex rather than spinlock in passthrough backend
xen/pciback: miscellaneous adjustments
xen/pci: support multi-segment systems
Konrad Rzeszutek Wilk (9):
xen-pcifront: Update warning comment to use 'e820_host' option.
xen-swiotlb: Retry up three times to allocate Xen-SWIOTLB
xen-swiotlb: Fix wrong panic.
xen-swiotlb: When doing coherent alloc/dealloc check before swizzling the MFNs.
xen/pciback: Use mutexes when working with Xenbus state transitions.
xen/pciback: use mutex rather than spinlock in vpci backend
xen/pv-on-hvm:kexec: Fix implicit declaration of function 'xen_hvm_domain'
xen/pciback: Do not dereference psdev during printk when it is NULL.
xen/pciback: Check if the device is found instead of blindly assuming so.
Olaf Hering (5):
xen/pv-on-hvm kexec: prevent crash in xenwatch_thread() when stale watch events arrive
xen/pv-on-hvm kexec: rebind virqs to existing eventchannel ports
xen/pv-on-hvm kexec+kdump: reset PV devices in kexec or crash kernel
xen/pv-on-hvm kexec: update xs_wire.h:xsd_sockmsg_type from xen-unstable
xen/pv-on-hvm kexec: add xs_reset_watches to shutdown watches from old kernel
Randy Dunlap (1):
xen-swiotlb: fix printk and panic args
Stefano Stabellini (2):
xen: XEN_PVHVM depends on PCI
xen: remove XEN_PLATFORM_PCI config option
Thomas Meyer (1):
xen/pciback: use resource_size()
arch/x86/pci/xen.c | 22 ++++-
arch/x86/xen/Kconfig | 3 +-
drivers/pci/xen-pcifront.c | 5 +-
drivers/xen/Kconfig | 10 --
drivers/xen/Makefile | 4 +-
drivers/xen/events.c | 37 +++++++-
drivers/xen/pci.c | 105 ++++++++++++++++++++---
drivers/xen/swiotlb-xen.c | 70 ++++++++++++----
drivers/xen/xen-pciback/conf_space.c | 1 -
drivers/xen/xen-pciback/conf_space_header.c | 5 +-
drivers/xen/xen-pciback/conf_space_quirks.c | 3 +-
drivers/xen/xen-pciback/passthrough.c | 34 +++-----
drivers/xen/xen-pciback/pci_stub.c | 35 ++++-----
drivers/xen/xen-pciback/pciback.h | 32 +++++---
drivers/xen/xen-pciback/pciback_ops.c | 1 -
drivers/xen/xen-pciback/vpci.c | 35 ++++-----
drivers/xen/xen-pciback/xenbus.c | 27 +++----
drivers/xen/xenbus/xenbus_comms.c | 4 +-
drivers/xen/xenbus/xenbus_probe.c | 101 ++++++++++++-----------
drivers/xen/xenbus/xenbus_probe_frontend.c | 121 +++++++++++++++++++++++++++
drivers/xen/xenbus/xenbus_xs.c | 17 ++++-
include/xen/interface/io/xs_wire.h | 6 +-
include/xen/interface/physdev.h | 34 +++++++-
23 files changed, 507 insertions(+), 205 deletions(-)
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH 0/4] xen: map foreign pages for shared rings by updating the PTEs directly
From: Konrad Rzeszutek Wilk @ 2011-10-20 23:44 UTC (permalink / raw)
To: David Vrabel; +Cc: xen-devel, linux-kernel, Andrew Morton
In-Reply-To: <1319107519-2253-1-git-send-email-david.vrabel@citrix.com>
On Thu, Oct 20, 2011 at 11:45:15AM +0100, David Vrabel wrote:
> This series of patches allows the vmalloc_sync_all() to be removed
> from alloc_vm_area() by getting the hypervisor to update the PTEs (in
> init_mm) directly rather than having the hypervisor look in the
> current page tables to find the PTEs.
>
> Once the hypervisor has updated the PTEs, the normal mechanism of
> syncing the page tables after a fault works as expected.
>
> This mechanism doesn't currently work on the ia64 port as that does
> not support the GNTMAP_contains_pte flag.
>
> Andrew, patch 4 (xen: map foreign pages for shared rings by updating
> the PTEs directly) depends on patch 1 so it's probably best to go via
> Konrad's Xen tree with your acked-by.
Or I can Ack patch 1 and Andrew can pick both of them. Either way - but let
mention the Ack on patch #1
>
> David
>
> David Vrabel (4):
> xen: use generic functions instead of xen_{alloc,free}_vm_area()
> block: xen-blkback: use API provided by xenbus module to map rings
> net: xen-netback: use API provided by xenbus module to map rings
> xen: map foreign pages for shared rings by updating the PTEs directly
>
> arch/ia64/include/asm/xen/grant_table.h | 29 -----------
> arch/ia64/xen/grant-table.c | 62 ------------------------
> arch/x86/include/asm/xen/grant_table.h | 7 ---
> arch/x86/xen/grant-table.c | 2 +-
> drivers/block/xen-blkback/common.h | 5 +--
> drivers/block/xen-blkback/xenbus.c | 54 +++------------------
> drivers/net/xen-netback/common.h | 11 ++--
> drivers/net/xen-netback/netback.c | 80 +++++++------------------------
> drivers/xen/xenbus/xenbus_client.c | 15 ++++--
> include/linux/vmalloc.h | 2 +-
> include/xen/grant_table.h | 1 -
> mm/vmalloc.c | 27 +++++-----
> 12 files changed, 55 insertions(+), 240 deletions(-)
> delete mode 100644 arch/ia64/include/asm/xen/grant_table.h
> delete mode 100644 arch/x86/include/asm/xen/grant_table.h
>
> --
> 1.7.2.5
^ permalink raw reply
* Re: Problem with TeVii S-470
From: Mike Mironov @ 2011-10-24 13:07 UTC (permalink / raw)
To: Linux Media Mailing List; +Cc: Josu Lazkano
In-Reply-To: <CAL9G6WX1tTSLsm-iMNWnJdWJWQQ1m31WTTzrvG3eh9BYE8fnfw@mail.gmail.com>
24.10.2011 15:29, Josu Lazkano пишет:
> 2011/10/24 Mike Mironov<subscribe@darkmike.ru>:
>> Hello!
>>
>> I have this card http://www.linuxtv.org/wiki/index.php/TeVii_S470
>>
>> I try to use it under Debian Squeeze, but I can't get channel data from it.
>>
>> I try to use drivers from 2.6.38, 2.6.39 kernels, s2-liplianin drivers with
>> 2.6.32 kernel, last linux-media drivers with 2.6.32
>>
>> With all drivers I can scan channels, but then a I'll try to lock channel I
>> get some error in syslog (module cx23885 loaded with debug=1)
>>
>> cx23885[0]/0: [f373ec80/27] cx23885_buf_queue - append to active
>> cx23885[0]/0: [f373ebc0/28] wakeup reg=477 buf=477
>> cx23885[0]/0: queue is not empty - append to active
>>
>> and finally a lot of
>>
>> cx23885[0]/0: [f42c4240/6] timeout - dma=0x03c5c000
>> cx23885[0]/0: [f42c4180/7] timeout - dma=0x3322b000
>> cx23885[0]/0: [f4374440/8] timeout - dma=0x33048000
>> cx23885[0]/0: [f4374140/9] timeout - dma=0x03d68000
>>
>> In other machine this work under Windows. Under Linux I have same effects.
>>
>> It's problem in drivers or in card? That addition information need to
>> resolve this problem?
>
> Hello Mike, I have same device on same OS, try this:
> mkdir /usr/local/src/dvbcd /usr/local/src/dvbwget
> http://tevii.com/100315_Beta_linux_tevii_ds3000.rarunrar x
> 100315_Beta_linux_tevii_ds3000.rarcp dvb-fe-ds3000.fw
> /lib/firmware/tar xjvf linux-tevii-ds3000.tar.bz2cd
> linux-tevii-ds3000make&& make install
> Regards.
I'll try use this drivers today, but for this devices drivers exist in
kernel from 2.6.33. So it must work with in-kernel drivers.
P.S. Firmware from this archive I put in /lib/firmware before all tests.
$ md5sum /lib/firmware/dvb-fe-ds3000.fw
a32d17910c4f370073f9346e71d34b80 /lib/firmware/dvb-fe-ds3000.fw
^ permalink raw reply
* Re: [Xen-devel] [PATCH 3/3] xen/blk[front|back]: Enhance discard support with secure erasing support.
From: Konrad Rzeszutek Wilk @ 2011-10-20 3:46 UTC (permalink / raw)
To: Li Dongyang
Cc: Jan Beulich, Dong Yang Li, xen-devel@lists.xensource.com,
Ian Campbell, linux-kernel@vger.kernel.org, hch@infradead.org
In-Reply-To: <CAKH3R4_TDxyNcsgZBOxQRS4U61h=bhY+Vap72AWa4CdQyQ7QfQ@mail.gmail.com>
On Thu, Oct 20, 2011 at 11:17:14AM +0800, Li Dongyang wrote:
> I think we also should mark the vbd has discard_secure if we are
> usingthe file backend,as if we punch a hole in the image, those blocks
> are freed tofilesystem and hardly to getthem back, or maybe write
> zeros to the range before we punch the hole is better?
You would have to write zeros to that range (or perhaps random values)
to emulate the secure delete. If you have a patch for that I would be interested
in seeing it.
Hmm, which reminds me - I should repost this patch series.
> On Mon, Oct 17, 2011 at 9:23 PM, Jan Beulich <JBeulich@suse.com> wrote:
> >>>> On 11.10.11 at 22:57, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
> >> --- a/drivers/block/xen-blkfront.c
> >> +++ b/drivers/block/xen-blkfront.c
> >>...
> >> @@ -705,7 +711,7 @@ static void blkif_free(struct blkfront_info *info, int suspend)
> >> static void blkif_completion(struct blk_shadow *s)
> >> {
> >> int i;
> >
> > This function gets called for all types of requests, and hence must filter
> > discard ones now that what would be nr_segments can be non-zero,
> > e.g.
> >
> > if (s->req.operation == BLKIF_OP_DISCARD)
> > return;
> >
> > Jan
> >
> >> - for (i = 0; i < s->req.nr_segments; i++)
> >> + for (i = 0; i < s->req.u1.nr_segments; i++)
> >> gnttab_end_foreign_access(s->req.u.rw.seg[i].gref, 0, 0UL);
> >> }
> >>
> >
> >
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.