* Re: [Qemu-devel] [PATCH v2 3/4] Add cap reduction support to enable use as SUID
From: Corey Bryant @ 2011-10-24 14:13 UTC (permalink / raw)
To: Blue Swirl; +Cc: rmarwah, aliguori, qemu-devel
In-Reply-To: <CAAu8pHt0NGGEv7cpdvdtBc7Hrp2XBjJo79ce1RghVextptdVHA@mail.gmail.com>
On 10/23/2011 09:22 AM, Blue Swirl wrote:
> On Fri, Oct 21, 2011 at 15:07, Corey Bryant<coreyb@linux.vnet.ibm.com> wrote:
>> The ideal way to use qemu-bridge-helper is to give it an fscap of using:
>>
>> setcap cap_net_admin=ep qemu-bridge-helper
>>
>> Unfortunately, most distros still do not have a mechanism to package files
>> with fscaps applied. This means they'll have to SUID the qemu-bridge-helper
>> binary.
>>
>> To improve security, use libcap to reduce our capability set to just
>> cap_net_admin, then reduce privileges down to the calling user. This is
>> hopefully close to equivalent to fscap support from a security perspective.
>>
>> 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>
>> ---
>> configure | 34 ++++++++++++++++++++++++++++++++++
>> qemu-bridge-helper.c | 39 +++++++++++++++++++++++++++++++++++++++
>> 2 files changed, 73 insertions(+), 0 deletions(-)
>>
>> diff --git a/configure b/configure
>> index 6c8b659..fed66b0 100755
>> --- a/configure
>> +++ b/configure
>> @@ -128,6 +128,7 @@ vnc_thread="no"
>> xen=""
>> xen_ctrl_version=""
>> linux_aio=""
>> +cap=""
>> attr=""
>> xfs=""
>>
>> @@ -653,6 +654,10 @@ for opt do
>> ;;
>> --enable-kvm) kvm="yes"
>> ;;
>> + --disable-cap) cap="no"
>> + ;;
>> + --enable-cap) cap="yes"
>> + ;;
>> --disable-spice) spice="no"
>> ;;
>> --enable-spice) spice="yes"
>> @@ -1032,6 +1037,8 @@ echo " --disable-vde disable support for vde network"
>> echo " --enable-vde enable support for vde network"
>> echo " --disable-linux-aio disable Linux AIO support"
>> echo " --enable-linux-aio enable Linux AIO support"
>> +echo " --disable-cap disable libcap-ng support"
>> +echo " --enable-cap enable libcap-ng support"
>> echo " --disable-attr disables attr and xattr support"
>> echo " --enable-attr enable attr and xattr support"
>> echo " --disable-blobs disable installing provided firmware blobs"
>> @@ -1638,6 +1645,29 @@ EOF
>> fi
>>
>> ##########################################
>> +# libcap-ng library probe
>> +if test "$cap" != "no" ; then
>> + cap_libs="-lcap-ng"
>> + cat> $TMPC<< EOF
>> +#include<cap-ng.h>
>> +int main(void)
>> +{
>> + capng_capability_to_name(CAPNG_EFFECTIVE);
>> + return 0;
>> +}
>> +EOF
>> + if compile_prog "" "$cap_libs" ; then
>> + cap=yes
>> + libs_tools="$cap_libs $libs_tools"
>> + else
>> + if test "$cap" = "yes" ; then
>> + feature_not_found "cap"
>> + fi
>> + cap=no
>> + fi
>> +fi
>> +
>> +##########################################
>> # Sound support libraries probe
>>
>> audio_drv_probe()
>> @@ -2735,6 +2765,7 @@ echo "fdatasync $fdatasync"
>> echo "madvise $madvise"
>> echo "posix_madvise $posix_madvise"
>> echo "uuid support $uuid"
>> +echo "libcap-ng support $cap"
>> echo "vhost-net support $vhost_net"
>> echo "Trace backend $trace_backend"
>> echo "Trace output file $trace_file-<pid>"
>> @@ -2846,6 +2877,9 @@ fi
>> if test "$vde" = "yes" ; then
>> echo "CONFIG_VDE=y">> $config_host_mak
>> fi
>> +if test "$cap" = "yes" ; then
>> + echo "CONFIG_LIBCAP=y">> $config_host_mak
>> +fi
>> for card in $audio_card_list; do
>> def=CONFIG_`echo $card | tr '[:lower:]' '[:upper:]'`
>> echo "$def=y">> $config_host_mak
>> diff --git a/qemu-bridge-helper.c b/qemu-bridge-helper.c
>> index db257d5..b1562eb 100644
>> --- a/qemu-bridge-helper.c
>> +++ b/qemu-bridge-helper.c
>> @@ -33,6 +33,10 @@
>>
>> #include "net/tap-linux.h"
>>
>> +#ifdef CONFIG_LIBCAP
>> +#include<cap-ng.h>
>> +#endif
>> +
>> #define MAX_ACLS (128)
>> #define DEFAULT_ACL_FILE CONFIG_QEMU_CONFDIR "/bridge.conf"
>>
>> @@ -185,6 +189,27 @@ static int send_fd(int c, int fd)
>> return sendmsg(c,&msg, 0);
>> }
>>
>> +#ifdef CONFIG_LIBCAP
>> +static int drop_privileges(void)
>> +{
>> + /* clear all capabilities */
>> + capng_clear(CAPNG_SELECT_BOTH);
>> +
>> + if (capng_update(CAPNG_ADD, CAPNG_EFFECTIVE | CAPNG_PERMITTED,
>> + CAP_NET_ADMIN)< 0) {
>> + return -1;
>> + }
>> +
>> + /* change to calling user's real uid and gid, retaining supplemental
>> + * groups and CAP_NET_ADMIN */
>> + if (capng_change_id(getuid(), getgid(), CAPNG_CLEAR_BOUNDING)) {
>> + return -1;
>> + }
>> +
>> + return 0;
>> +}
>> +#endif
>> +
>> int main(int argc, char **argv)
>> {
>> struct ifreq ifr;
>> @@ -198,6 +223,20 @@ int main(int argc, char **argv)
>> int acl_count = 0;
>> int i, access_allowed, access_denied;
>>
>> + /* if we're run from an suid binary, immediately drop privileges preserving
>> + * cap_net_admin -- exit immediately if libcap not configured */
>> + if (geteuid() == 0&& getuid() != geteuid()) {
>> +#ifdef CONFIG_LIBCAP
>> + if (drop_privileges() == -1) {
>> + fprintf(stderr, "failed to drop privileges\n");
>> + return 1;
>> + }
>> +#else
>> + fprintf(stderr, "failed to drop privileges\n");
>
> This makes the tool useless without CONFIG_LIBCAP. Wouldn't it be
> possible to use setfsuid() instead for Linux?
>
> Some fork+setuid helper could be used for other Unix and for the lame
> OSes without any file system DAC capabilities, a different syntax that
> does not rely on underlying FS may need to be introduced. Again, I
> don't know if the tool is even interesting for non-Linux.
>
I just want to make sure that there is no chance that the helper is run
as root beyond this point. Are you saying to seteuid(getuid) and
setfsuid(root)? I'm not sure that would drop the privileges enough.
>> + return 1;
>> +#endif
>> + }
>> +
>> /* parse arguments */
>> if (argc< 3 || argc> 4) {
>> fprintf(stderr, "Usage: %s [--use-vnet] BRIDGE FD\n", argv[0]);
>> --
>> 1.7.3.4
>>
>>
>>
>
--
Regards,
Corey
^ permalink raw reply
* Re: [CONSOLIDATED PULL 20/27] libtool: Upgrade from 2.4 -> 2.4.2
From: Richard Purdie @ 2011-10-24 14:10 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
In-Reply-To: <3D2F5FE5-B1DC-44C4-8A5A-E81C41F00125@dominion.thruhere.net>
On Mon, 2011-10-24 at 15:37 +0200, Koen Kooi wrote:
> Op 24 okt. 2011, om 15:34 heeft Richard Purdie het volgende geschreven:
>
> > On Sun, 2011-10-23 at 11:26 -0700, Saul Wold wrote:
> >> From: Khem Raj <raj.khem@gmail.com>
> >>
> >> Adjust prefix.patch and delete resolve-sysroot.patch
> >> since its already applied upstream
> >>
> >> Signed-off-by: Khem Raj <raj.khem@gmail.com>
> >> ---
> >> .../libtool/{libtool.inc => libtool-2.4.2.inc} | 26 +++++++++---
> >> meta/recipes-devtools/libtool/libtool-2.4.inc | 13 ------
> >> ...libtool-cross_2.4.bb => libtool-cross_2.4.2.bb} | 2 +-
> >> ...btool-native_2.4.bb => libtool-native_2.4.2.bb} | 2 +-
> >> ...nativesdk_2.4.bb => libtool-nativesdk_2.4.2.bb} | 2 +-
> >> meta/recipes-devtools/libtool/libtool/prefix.patch | 46 ++++++++++----------
> >> .../libtool/libtool/resolve-sysroot.patch | 42 ------------------
> >> .../libtool/{libtool_2.4.bb => libtool_2.4.2.bb} | 2 +-
> >> 8 files changed, 47 insertions(+), 88 deletions(-)
> >> rename meta/recipes-devtools/libtool/{libtool.inc => libtool-2.4.2.inc} (57%)
> >> delete mode 100644 meta/recipes-devtools/libtool/libtool-2.4.inc
> >> rename meta/recipes-devtools/libtool/{libtool-cross_2.4.bb => libtool-cross_2.4.2.bb} (98%)
> >> rename meta/recipes-devtools/libtool/{libtool-native_2.4.bb => libtool-native_2.4.2.bb} (96%)
> >> rename meta/recipes-devtools/libtool/{libtool-nativesdk_2.4.bb => libtool-nativesdk_2.4.2.bb} (97%)
> >> delete mode 100644 meta/recipes-devtools/libtool/libtool/resolve-sysroot.patch
> >> rename meta/recipes-devtools/libtool/{libtool_2.4.bb => libtool_2.4.2.bb} (94%)
> >>
> >> diff --git a/meta/recipes-devtools/libtool/libtool.inc b/meta/recipes-devtools/libtool/libtool-2.4.2.inc
> >> similarity index 57%
> >> rename from meta/recipes-devtools/libtool/libtool.inc
> >> rename to meta/recipes-devtools/libtool/libtool-2.4.2.inc
> >> index ef9095b..1f652ef 100644
> >> --- a/meta/recipes-devtools/libtool/libtool.inc
> >> +++ b/meta/recipes-devtools/libtool/libtool-2.4.2.inc
> >> @@ -1,4 +1,3 @@
> >> -SUMMARY = "Generic library support script"
> >
> > Why drop the SUMMARY field?
>
> What's the difference between SUMMARY and DESCRIPTION? And what happens if both are set?
SUMMARY is a one line 74? character summary of the package, DESCRIPTION
is a multiple line stream of text containing a more verbose description.
What happens to the data is package backend specific, I know RPM has
uses for both. There was definitely discussion about this on the mailing
list at the time, I'm not sure what if anything made it into the manuals
but if its not there it should be added.
Cheers,
Richard
^ permalink raw reply
* [DRAFT PATCH] lvmcache and lvmetad
From: Petr Rockai @ 2011-10-24 14:17 UTC (permalink / raw)
To: lvm-devel
Hi,
I have been working on isolating lvmcache code from the rest of the
codebase. I am making progress slowly, since this is very tedious and
very error-prone. A lot of code is copied out around the code base and
cache internals are manipulated all over the place. I am attaching my
current state of the matters, which do not yet compile. When you expose
the internal structures, you can get things to compile though and pass
the tests as well. I will continue drilling down while trying to avoid
any new bugs.
The plan is to, when the lvmcache is finally walled off, to create a new
implementation (of the APIs) that only does the bare minimum to get LVM
going and passing the testsuite. The following step would then be to
factor this functionality out of lvmcache altogether, as far as that
turns out to be possible. After that is done, finally, I can resume work
on integrating lvmetad, which has been so far blocked out by lvmcache
mis-design. In the meantime, I'll try to integrate some lvmetad tests
into the suite (the daemon can be tested even without full LVM support).
Yours,
Petr
-------------- next part --------------
A non-text attachment was scrubbed...
Name: lvmcache.diff
Type: text/x-diff
Size: 39299 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/lvm-devel/attachments/20111024/8036749b/attachment.bin>
-------------- next part --------------
--
id' Ash = Ash; id' Dust = Dust; id' _ = undefined
^ permalink raw reply
* Re: bridge: HSR support
From: Arvid Brodin @ 2011-10-24 14:17 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev
In-Reply-To: <4E94D67A.9060207@enea.com>
Stephen Hemminger wrote:
> On Tue, 11 Oct 2011 20:25:08 +0200
> Arvid Brodin <arvid.brodin@enea.com> wrote:
>
>> Hi,
>>
>> I want to add support for HSR ("High-availability Seamless Redundancy",
>> IEC-62439-3) to the bridge code. With HSR, all connected units have two network
>> ports and are connected in a ring. All new Ethernet packets are sent on both
>> ports (or passed through if the current unit is not the originating unit). The
>> same packet is never passed twice. Non-HSR units are not allowed in the ring.
>>
>> This gives instant, reconfiguration-free failover.
>>
>> I'd like your input on how to design the user interface. To me it seems natural
>> to use bridge-utils, which of course today supports STP.
>>
>> One solution is to simply add an "hsr" command:
>>
>> # brctl hsr <bridge> on|off
>>
>> But HSR is mutually exclusive to other modes, and I think that STP and standard
>> bridge mode are mutually exclusive, too? Perhaps it would be better (more user-
>> friendly) to
>>
>> # brctl type <bridge> standard|stp|hsr
>>
>> ?
>>
>> 'brctl stp <bridge> on|off' would have to be kept for compatibility, but could
>> be a simple wrapper for 'brctl type <bridge> stp|standard'
>>
>> What do you think about this?
>>
>
> Why is it a bridge thing and not a standalone or bonding (or the new team
> device feature? Wouldn't users want to use it without all the stuff
> related to bridging. The fact that it doesn't work with STP is a big
> red flag that it doesn't belong in the bridge.
Ok, having read up some more on this it looks like STP is a standardised part of
bridging, so I guess you're right.
I need to do two things:
1) Bind two network interfaces into one (say, eth0 & eth1 => hsr0). Frames sent on
hsr0 should get an HSR tag (including the correct EtherType) and go out on both
eth0 and eth1.
2) Ingress frames on eth0 & eth1, with EtherType 0x88fb, should be captured and
handled specially (either received on hsr0 or forwarded to the other bound
physical interface).
Any ideas on the best way to implement this -- what's the nicest place to "hook
into" for this?
--
Arvid Brodin
Enea Services Stockholm AB
^ permalink raw reply
* Re: [RFC PATCH 1/2] tools/perf: Don't set attr->disabled when doing grouping
From: David Ahern @ 2011-10-24 14:19 UTC (permalink / raw)
To: Deng-Cheng Zhu
Cc: linux-kernel, Peter Zijlstra, Paul Mackerras, Ingo Molnar,
Arnaldo Carvalho de Melo
In-Reply-To: <1319453820-12992-2-git-send-email-dczhu@mips.com>
On 10/24/2011 04:56 AM, Deng-Cheng Zhu wrote:
> Events will be created at the state PERF_EVENT_STATE_OFF if attr->disabled
> is set. When these events go to arch level validate_group(), the function
> won't do anything real because they are filtered out by the state check.
Seems like a bug with the group checks. You should be able to enable and
disable events - including creating them disabled.
David
>
> Signed-off-by: Deng-Cheng Zhu <dczhu@mips.com>
> Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
> Cc: Paul Mackerras <paulus@samba.org>
> Cc: Ingo Molnar <mingo@elte.hu>
> Cc: Arnaldo Carvalho de Melo <acme@ghostprotocols.net>
> ---
> tools/perf/builtin-record.c | 6 +++---
> tools/perf/builtin-stat.c | 3 ++-
> 2 files changed, 5 insertions(+), 4 deletions(-)
>
> diff --git a/tools/perf/builtin-record.c b/tools/perf/builtin-record.c
> index f4c3fbe..67e8e4c 100644
> --- a/tools/perf/builtin-record.c
> +++ b/tools/perf/builtin-record.c
> @@ -161,7 +161,6 @@ static void config_attr(struct perf_evsel *evsel, struct perf_evlist *evlist)
> struct perf_event_attr *attr = &evsel->attr;
> int track = !evsel->idx; /* only the first counter needs these */
>
> - attr->disabled = 1;
> attr->inherit = !no_inherit;
> attr->read_format = PERF_FORMAT_TOTAL_TIME_ENABLED |
> PERF_FORMAT_TOTAL_TIME_RUNNING |
> @@ -222,10 +221,11 @@ static void config_attr(struct perf_evsel *evsel, struct perf_evlist *evlist)
> attr->mmap = track;
> attr->comm = track;
>
> - if (target_pid == -1 && target_tid == -1 && !system_wide) {
> + if (!group)
> attr->disabled = 1;
> +
> + if (target_pid == -1 && target_tid == -1 && !system_wide)
> attr->enable_on_exec = 1;
> - }
> }
>
> static bool perf_evlist__equal(struct perf_evlist *evlist,
> diff --git a/tools/perf/builtin-stat.c b/tools/perf/builtin-stat.c
> index 5deb17d..ca95475 100644
> --- a/tools/perf/builtin-stat.c
> +++ b/tools/perf/builtin-stat.c
> @@ -284,7 +284,8 @@ static int create_perf_stat_counter(struct perf_evsel *evsel)
> return perf_evsel__open_per_cpu(evsel, evsel_list->cpus, group);
>
> if (target_pid == -1 && target_tid == -1) {
> - attr->disabled = 1;
> + if (!group)
> + attr->disabled = 1;
> attr->enable_on_exec = 1;
> }
>
^ permalink raw reply
* Re: [Xen-devel] Re: [PATCH 5/6] xen/netback: Enable netback on HVM guests
From: Konrad Rzeszutek Wilk @ 2011-10-24 14:19 UTC (permalink / raw)
To: David Miller; +Cc: Ian.Campbell, netdev, dgdegra, xen-devel, david.vrabel
In-Reply-To: <20111024.053419.1995560587557035685.davem@davemloft.net>
On Mon, Oct 24, 2011 at 05:34:19AM -0400, David Miller wrote:
> From: Ian Campbell <Ian.Campbell@citrix.com>
> Date: Mon, 24 Oct 2011 10:31:08 +0100
>
> > On Thu, 2011-10-20 at 16:35 +0100, Daniel De Graaf wrote:
> >> Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
> >
> > Acked-by: Ian Campbell <ian.campbell@citrix.com>
> >
> > Normally netback patches would go in via the networking subsystem
> > maintainer's tree but since this depends on core Xen patches from this
> > series and is unlikely to conflict with anything in the net-next tree I
> > suspect it would make more sense for Konrad to take this one.
> >
> > David (Miller) does that work for you?
>
> Yes, it does.
OK, Can I stick Acked-by: David Miller on that patch?
Thank you.
^ permalink raw reply
* Re: [PATCH 1/2] drm/kms: Make i2c buses faster
From: Eugeni Dodonov @ 2011-10-24 14:19 UTC (permalink / raw)
To: Alex Deucher; +Cc: dri-devel, Jean Delvare
In-Reply-To: <CADnq5_MH1qPr6zvZYJ4bCb2kBLHu=g57JKAgDqAAfeLMAMbmXQ@mail.gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 880 bytes --]
On Sat, Oct 22, 2011 at 12:38, Alex Deucher <alexdeucher@gmail.com> wrote:
> On Fri, Oct 21, 2011 at 3:29 PM, Jean Delvare <jdelvare@suse.de> wrote:
> > Hi Alex,
> >
> > On Friday 21 October 2011 08:05:48 pm Alex Deucher wrote:
> >> On Fri, Oct 21, 2011 at 10:16 AM, Jean Delvare <jdelvare@suse.de>
> >> > Does anyone know at which speed hardware I2C engines are running
> >> > the DDC bus on various graphics cards?
> >>
> >> IIRC, we generally target the radeon hw i2c engines to run at 50 khz.
> >
> > Then it doesn't seem unreasonable to try and achieve the same for bit-
> > banged I2C. That's exactly what my patch is doing.
>
> Seems fine to me then. I don't know why we set it so low to begin
> with, but I'm certainly not an i2c expert.
>
Seems fine for me as well.
Acked-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
--
Eugeni Dodonov
<http://eugeni.dodonov.net/>
[-- Attachment #1.2: Type: text/html, Size: 1462 bytes --]
[-- Attachment #2: Type: text/plain, Size: 159 bytes --]
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [PATCH] ahci: add DT binding for Calxeda AHCI controller
From: Rob Herring @ 2011-10-24 14:20 UTC (permalink / raw)
To: Jeff Garzik; +Cc: linux-ide, linux-kernel, devicetree-discuss
In-Reply-To: <4E8A6FB3.4090909@gmail.com>
Jeff,
On 10/03/2011 09:30 PM, Rob Herring wrote:
> On 09/02/2011 10:10 AM, Rob Herring wrote:
>> From: Rob Herring <rob.herring@calxeda.com>
>>
>> Add devicetree match table to ahci platform driver for Calxeda Highbank
>> AHCI controller.
>>
>> Signed-off-by: Rob Herring <rob.herring@calxeda.com>
>> Cc: Jeff Garzik <jgarzik@pobox.com>
>> Cc: linux-ide@vger.kernel.org
>> Cc: linux-kernel@vger.kernel.org
>> Cc: devicetree-discuss@lists.ozlabs.org
>> ---
>
> Any comments on this?
>
Ping.
Can you please apply this for 3.2.
Regards,
Rob
>> .../devicetree/bindings/ata/calxeda-sata.txt | 17 +++++++++++++++++
>> drivers/ata/ahci_platform.c | 7 +++++++
>> 2 files changed, 24 insertions(+), 0 deletions(-)
>> create mode 100644 Documentation/devicetree/bindings/ata/calxeda-sata.txt
>>
>> diff --git a/Documentation/devicetree/bindings/ata/calxeda-sata.txt b/Documentation/devicetree/bindings/ata/calxeda-sata.txt
>> new file mode 100644
>> index 0000000..79caa56
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/ata/calxeda-sata.txt
>> @@ -0,0 +1,17 @@
>> +* Calxeda SATA Controller
>> +
>> +SATA nodes are defined to describe on-chip Serial ATA controllers.
>> +Each SATA controller should have its own node.
>> +
>> +Required properties:
>> +- compatible : compatible list, contains "calxeda,hb-ahci"
>> +- interrupts : <interrupt mapping for SATA IRQ>
>> +- reg : <registers mapping>
>> +
>> +Example:
>> + sata@ffe08000 {
>> + compatible = "calxeda,hb-ahci";
>> + reg = <0xffe08000 0x1000>;
>> + interrupts = <115>;
>> + };
>> +
>> diff --git a/drivers/ata/ahci_platform.c b/drivers/ata/ahci_platform.c
>> index 6fef1fa..9bfc970 100644
>> --- a/drivers/ata/ahci_platform.c
>> +++ b/drivers/ata/ahci_platform.c
>> @@ -171,11 +171,18 @@ static int __devexit ahci_remove(struct platform_device *pdev)
>> return 0;
>> }
>>
>> +static const struct of_device_id ahci_of_match[] = {
>> + { .compatible = "calxeda,hb-ahci", },
>> + {},
>> +};
>> +MODULE_DEVICE_TABLE(of, ahci_of_match);
>> +
>> static struct platform_driver ahci_driver = {
>> .remove = __devexit_p(ahci_remove),
>> .driver = {
>> .name = "ahci",
>> .owner = THIS_MODULE,
>> + .of_match_table = ahci_of_match,
>> },
>> };
>>
>
^ permalink raw reply
* Re: [GIT] Security subsystem updates for 3.2
From: Stephen Rothwell @ 2011-10-24 14:20 UTC (permalink / raw)
To: Linus Torvalds; +Cc: James Morris, linux-security-module, linux-kernel
In-Reply-To: <CA+55aFxbh9eHYe8cPH2TaTW1t5C6C+z-Bcy+kGhR0Gt=MgMvcQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 875 bytes --]
Hi Linus,
On Mon, 24 Oct 2011 15:52:56 +0200 Linus Torvalds <torvalds@linux-foundation.org> wrote:
>
> >
> > Jarkko Sakkinen (6):
> > Smack: domain transition protections (v3)
>
> So this is reverted in linux-next. I don't know why, but it's a bad
> sign. Doesn't compile?
Yeah, this:
security/smack/smack_lsm.c: In function 'smack_bprm_set_creds':
security/smack/smack_lsm.c:473:21: error: 'PER_CLEAR_ON_SETID' undeclared (first use in this function)
Caused by commit 84088ba23929 ("Smack: domain transition protections
(v3)"). PER_CLEAR_ON_SETID is defined in linux/personality.h which is not
directly included by the above file.
It appears to have been fixed in the current version of the tree by this:
Smack: compilation fix
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [CONSOLIDATED PULL 11/27] pulseaudio-0.9.23: inherit perlnative to work around build on host without XML/Parser.pm
From: Richard Purdie @ 2011-10-24 14:15 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
In-Reply-To: <91421698-3BCA-4B52-8C7C-AD842A2E62FB@dominion.thruhere.net>
On Mon, 2011-10-24 at 15:19 +0200, Koen Kooi wrote:
> Op 24 okt. 2011, om 15:15 heeft Richard Purdie het volgende geschreven:
>
> > On Sun, 2011-10-23 at 11:26 -0700, Saul Wold wrote:
> >> From: Martin Jansa <Martin.Jansa@gmail.com>
> >>
> >> Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
> >> ---
> >> .../pulseaudio/pulseaudio_0.9.23.bb | 2 +-
> >> 1 files changed, 1 insertions(+), 1 deletions(-)
> >>
> >> diff --git a/meta/recipes-multimedia/pulseaudio/pulseaudio_0.9.23.bb b/meta/recipes-multimedia/pulseaudio/pulseaudio_0.9.23.bb
> >> index 33f5e15..4ac2418 100644
> >> --- a/meta/recipes-multimedia/pulseaudio/pulseaudio_0.9.23.bb
> >> +++ b/meta/recipes-multimedia/pulseaudio/pulseaudio_0.9.23.bb
> >> @@ -4,7 +4,7 @@ PR = "r5"
> >>
> >> DEPENDS += "gdbm speex"
> >>
> >> -inherit gettext
> >> +inherit gettext perlnative
> >
> > This doesn't look right. If we need xmlparser, we should state that in
> > DEPENDS. If that is added to DEPENDS, I'm not sure we still need the
> > inherit of perlnative?
>
> If you need xmlparser during the build you almost always need the
> perlnative wrapper as well :(
I was under the impression that we'd fixed most of those issues :/. It
could well be a valid dependency in this case so I'll take the patch
with the added DEPENDS.
Cheers,
Richard
^ permalink raw reply
* Re: [patch net-next V4] net: introduce ethernet teaming device
From: Paul E. McKenney @ 2011-10-24 14:11 UTC (permalink / raw)
To: Benjamin Poirier
Cc: Jiri Pirko, netdev, davem, eric.dumazet, bhutchings, shemminger,
fubar, andy, tgraf, ebiederm, mirqus, kaber, greearb, jesse, fbl,
jzupka, Dipankar Sarma
In-Reply-To: <20111024130918.GB24473@synalogic.ca>
On Mon, Oct 24, 2011 at 09:09:19AM -0400, Benjamin Poirier wrote:
> 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.
Thank you, and please see below.
> > 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.
Indeed -- the list_for_each_entry_continue_reverse_rcu() implementation
above would only work if elements were never deleted from the list.
But people would miss that fact, resulting in list-poison oopses.
Furthermore, even if you avoid the poisoning, there is no guarantee
that you will see the same objects in reverse that you saw going
forward because some might have been added or deleted in the meantime.
So please take some other approach. For example, if the list has a
fixed upper bound, perhaps just keeping track of what elements you
visited would be workable.
Thanx, Paul
> 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 2/2] pulseaudio: inherit perlnative
From: Richard Purdie @ 2011-10-24 14:17 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
In-Reply-To: <1319380267-29794-2-git-send-email-raj.khem@gmail.com>
On Sun, 2011-10-23 at 07:31 -0700, Khem Raj wrote:
> manpage generatition uses xmltoman utility
> which inturn uses xml-parser. So we add
> libxml-parser-perl-native to DEPENDS and also
> inherit perlnative so it does not use the one
> from build host
>
> Signed-off-by: Khem Raj <raj.khem@gmail.com>
> ---
> .../pulseaudio/pulseaudio_0.9.23.bb | 6 +++---
> 1 files changed, 3 insertions(+), 3 deletions(-)
Merged to master, thanks.
Richard
^ permalink raw reply
* Re: [CONSOLIDATED PULL 20/27] libtool: Upgrade from 2.4 -> 2.4.2
From: Koen Kooi @ 2011-10-24 14:18 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
In-Reply-To: <1319465445.25011.18.camel@ted>
Op 24 okt. 2011, om 16:10 heeft Richard Purdie het volgende geschreven:
> On Mon, 2011-10-24 at 15:37 +0200, Koen Kooi wrote:
>> Op 24 okt. 2011, om 15:34 heeft Richard Purdie het volgende geschreven:
>>
>>> On Sun, 2011-10-23 at 11:26 -0700, Saul Wold wrote:
>>>> From: Khem Raj <raj.khem@gmail.com>
>>>>
>>>> Adjust prefix.patch and delete resolve-sysroot.patch
>>>> since its already applied upstream
>>>>
>>>> Signed-off-by: Khem Raj <raj.khem@gmail.com>
>>>> ---
>>>> .../libtool/{libtool.inc => libtool-2.4.2.inc} | 26 +++++++++---
>>>> meta/recipes-devtools/libtool/libtool-2.4.inc | 13 ------
>>>> ...libtool-cross_2.4.bb => libtool-cross_2.4.2.bb} | 2 +-
>>>> ...btool-native_2.4.bb => libtool-native_2.4.2.bb} | 2 +-
>>>> ...nativesdk_2.4.bb => libtool-nativesdk_2.4.2.bb} | 2 +-
>>>> meta/recipes-devtools/libtool/libtool/prefix.patch | 46 ++++++++++----------
>>>> .../libtool/libtool/resolve-sysroot.patch | 42 ------------------
>>>> .../libtool/{libtool_2.4.bb => libtool_2.4.2.bb} | 2 +-
>>>> 8 files changed, 47 insertions(+), 88 deletions(-)
>>>> rename meta/recipes-devtools/libtool/{libtool.inc => libtool-2.4.2.inc} (57%)
>>>> delete mode 100644 meta/recipes-devtools/libtool/libtool-2.4.inc
>>>> rename meta/recipes-devtools/libtool/{libtool-cross_2.4.bb => libtool-cross_2.4.2.bb} (98%)
>>>> rename meta/recipes-devtools/libtool/{libtool-native_2.4.bb => libtool-native_2.4.2.bb} (96%)
>>>> rename meta/recipes-devtools/libtool/{libtool-nativesdk_2.4.bb => libtool-nativesdk_2.4.2.bb} (97%)
>>>> delete mode 100644 meta/recipes-devtools/libtool/libtool/resolve-sysroot.patch
>>>> rename meta/recipes-devtools/libtool/{libtool_2.4.bb => libtool_2.4.2.bb} (94%)
>>>>
>>>> diff --git a/meta/recipes-devtools/libtool/libtool.inc b/meta/recipes-devtools/libtool/libtool-2.4.2.inc
>>>> similarity index 57%
>>>> rename from meta/recipes-devtools/libtool/libtool.inc
>>>> rename to meta/recipes-devtools/libtool/libtool-2.4.2.inc
>>>> index ef9095b..1f652ef 100644
>>>> --- a/meta/recipes-devtools/libtool/libtool.inc
>>>> +++ b/meta/recipes-devtools/libtool/libtool-2.4.2.inc
>>>> @@ -1,4 +1,3 @@
>>>> -SUMMARY = "Generic library support script"
>>>
>>> Why drop the SUMMARY field?
>>
>> What's the difference between SUMMARY and DESCRIPTION? And what happens if both are set?
>
> SUMMARY is a one line 74? character summary of the package, DESCRIPTION
> is a multiple line stream of text containing a more verbose description.
> What happens to the data is package backend specific, I know RPM has
> uses for both. There was definitely discussion about this on the mailing
> list at the time, I'm not sure what if anything made it into the manuals
> but if its not there it should be added.
It seems to get OR'd:
meta/classes/package_deb.bbclass: summary = bb.data.getVar('SUMMARY', localdata, True) or bb.data.getVar('DESCRIPTION', localdata, True) or "."
package_deb.bbclass: description = bb.data.getVar('DESCRIPTION', localdata, True) or "."
meta/classes/package_ipk.bbclass: summary = bb.data.getVar('SUMMARY', localdata, True) or bb.data.getVar('DESCRIPTION', localdata, True) or "."
package_ipk.bbclass: description = bb.data.getVar('DESCRIPTION', localdata, True) or "."
meta/classes/package_rpm.bbclass: srcsummary = (bb.data.getVar('SUMMARY', d, True) or bb.data.getVar('DESCRIPTION', d, True) or ".")
package_rpm.bbclass: srcdescription = bb.data.getVar('DESCRIPTION', d, True) or "."
regards,
Koen
^ permalink raw reply
* Re: [RFC][PATCH] KVM: Introduce direct MSI message injection for in-kernel irqchips
From: Michael S. Tsirkin @ 2011-10-24 14:25 UTC (permalink / raw)
To: Jan Kiszka; +Cc: Avi Kivity, Marcelo Tosatti, kvm
In-Reply-To: <4EA563FD.5060308@siemens.com>
On Mon, Oct 24, 2011 at 03:11:25PM +0200, Jan Kiszka wrote:
> 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.
A read or irq status clears pending in the same way it clears
irq line for level. I don't think this generates spurious irqs. Yes it
only works for PV.
For assigned devices, the only way I see to implement PBA
correctly is by masking the vector in the device
and looking at the actual pending bit.
> >
> >> 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.
True. But we only need that for PBA read which is unused ATM.
So kvm can just send the read to userspace, have qemu query
vfio or whatever.
> >
> >> 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.
Not sure I understand. we certainly shouldn't send masked
interrupts to the APIC if for no other reason that
the message value is invalid while masked.
> 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
Yes, level interrupts are tricky.
> --
> Siemens AG, Corporate Technology, CT T DE IT 1
> Corporate Competence Center Embedded Linux
^ permalink raw reply
* Re: Channel-less IIO events
From: Jonathan Cameron @ 2011-10-24 14:25 UTC (permalink / raw)
To: Lars-Peter Clausen; +Cc: linux-iio@vger.kernel.org
In-Reply-To: <4EA56C67.7020203@metafoo.de>
On 10/24/11 14:47, Lars-Peter Clausen wrote:
> Hi,
>
> Some chips generate events which don't really map to a channel, but are
> rather chip global. For example over-temperature events.
That one is a channel.
> Do you think this is something we should add support for or should we rather
> use a dummy channel, which doesn't report any actual values, for propagating
> the event?
Yup, have a temp channel for that one. Conceptually you might have two chips
that are otherwise identical but one has a readable temp channel, the other
doesn't. Userspace that is interested only in events won't care about
this difference. Also we want to report what the conditions are as if it were
a channel we could read. We want to know at what temperature this occurs.
There are others events such as loss of tracking / wire out for the resolvers,
but they so far have always corresponded to 'gah, it's all gone wrong' events.
Last time I asked more generally about this, Alan Cox suggested using the
signals typically employed for network sockets. General view is we didn't
want them coming through our normal event path and for example being blocked
behind the handling of another event. I then got bogged down with this
in kernel interface stuff so haven't looked at it again.
>
> My idea for supporting channel-less events is to add a event_mask to struct
> iio_info, which would be used just like a channels event_mask, but there
> would be no index for the sysfs attributes and for events we would set the
> event number to 0xffff.
Could you give more examples? The temp one to my mind definitely needs a
channel, perhaps others do not? I am not against in principal but not
yet certain exactly when this would make sense...
>
> Thanks
> - Lars
>
^ permalink raw reply
* Re: [CONSOLIDATED PULL 11/27] pulseaudio-0.9.23: inherit perlnative to work around build on host without XML/Parser.pm
From: Richard Purdie @ 2011-10-24 14:19 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
In-Reply-To: <20111024132405.GB3602@jama.jama.net>
On Mon, 2011-10-24 at 15:24 +0200, Martin Jansa wrote:
> On Mon, Oct 24, 2011 at 02:15:57PM +0100, Richard Purdie wrote:
> > On Sun, 2011-10-23 at 11:26 -0700, Saul Wold wrote:
> > > From: Martin Jansa <Martin.Jansa@gmail.com>
> > >
> > > Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
> > > ---
> > > .../pulseaudio/pulseaudio_0.9.23.bb | 2 +-
> > > 1 files changed, 1 insertions(+), 1 deletions(-)
> > >
> > > diff --git a/meta/recipes-multimedia/pulseaudio/pulseaudio_0.9.23.bb b/meta/recipes-multimedia/pulseaudio/pulseaudio_0.9.23.bb
> > > index 33f5e15..4ac2418 100644
> > > --- a/meta/recipes-multimedia/pulseaudio/pulseaudio_0.9.23.bb
> > > +++ b/meta/recipes-multimedia/pulseaudio/pulseaudio_0.9.23.bb
> > > @@ -4,7 +4,7 @@ PR = "r5"
> > >
> > > DEPENDS += "gdbm speex"
> > >
> > > -inherit gettext
> > > +inherit gettext perlnative
> >
> > This doesn't look right. If we need xmlparser, we should state that in
> > DEPENDS. If that is added to DEPENDS, I'm not sure we still need the
> > inherit of perlnative?
>
> Yes I've forgot to put it in DEPENDS, khem sent version where he is
> adding this inherit and DEPENDs..
>
> but both are needed and only work arounds because build is calling perl
> (not env perl) and perlnative helps to put perl from perl-native before
> perl from host in PATH.
>
> Reported here:
> http://lists.linuxtogo.org/pipermail/openembedded-core/2011-October/011323.html
>
> And I've sent this as work around before I'll fill oe-core bug report or
> someone updates it to 1.1 and maybe fix it too.
I've taken Khem's version of this so that should help address this
problem.
Cheers,
Richard
^ permalink raw reply
* Re: [dm-crypt] [RFC] dm-crypt and hardware-optimized crypto modules
From: Arno Wagner @ 2011-10-24 14:25 UTC (permalink / raw)
To: dm-crypt
In-Reply-To: <4EA555F1.9090506@freesources.org>
On Mon, Oct 24, 2011 at 02:11:29PM +0200, Jonas Meurer wrote:
> Am 24.10.2011 08:21, schrieb Arno Wagner:
> > Hi Jonas,
>
> Hey Arno,
>
> > the definite authority on this is Milan, but as far as I understand
> > module autoloading, as long as an implementation for a requested
> > cipher is already loaded, that will be used. Now, I expect it would
> > be possible to not build the normal AES module and thereby have the
> > HW-supported AES module loade automatically when needed. As the
> > Debian distro-kernel cannot know HW-support would be there, it
> > obviously defaults to the software implementation.
>
> Nope, the Debian distro-kernel has software implementation built into
> the kernel, and hardware-accelerated drivers built as modules. So
> according to Milans answers, the kernel crypto engine should load and
> use the hardware-optimised drivers in case they're supported.
Hmm. If the software-version is already compiled-in, that could
prevent auto-loading of the hw-version. I would expect that you
need both as modules or both compiled-in. Should be easy to test
though.
> > AFAIK, if both HW and SW support are loaded, HW support is used as
> > default. I think there is some kind of priority system in place.
> > But I am really only guessing here.
>
> I guess you're correct here ;)
>
> > I see two ways around this:
> >
> > 1. Load the HW module manually (or scripted). While I have not used
> > a Debian Distro kernel for a long time, I think adding the
> > HW-module to /etc/modules should accomplish that. Noneed to mess
> > with the initrd, unless possibly if you have encrypted root.
> >
> > 2. Roll your own kernel, possibly with HW support statically
> > compiled in. I have used Debian with kernels from kernel.org and
> > module-support turned off with good success for about 10 years now.
> > (I don't like initrds. Good for distros, but they complicate things
> > and complexity is the enemy of reliablity and efficiency. Also, I
> > like to mess around with my installatons and initrds make that
> > harder. I also do not like to use kernel modules very much,
> > although it is definitely good that they are there.)
> >
> > To use your own kernel with Debian, just boot it and tell it the
> > root partition. Of course you have to make sure it somehow has the
> > drivers it needs to fnd and mount the root partition.
>
> As I'm the maintainer of cryptsetup in Debian, I'm searching for a
> solution for default setups.
Ah, sorry. That gives you a different perspective obviously.
> I know how to manually tweak setups to
> use the hardware-optimized crypto drivers. But I need a solution for
> the default setup with default distro-kernel. Thus building custom
> kernels is out of scope in my case.
I can see that, yes.
Arno
--
Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: arno@wagner.name
GnuPG: ID: 1E25338F FP: 0C30 5782 9D93 F785 E79C 0296 797F 6B50 1E25 338F
----
Cuddly UI's are the manifestation of wishful thinking. -- Dylan Evans
If it's in the news, don't worry about it. The very definition of
"news" is "something that hardly ever happens." -- Bruce Schneier
^ permalink raw reply
* [PATCH] dt: Add empty of_match_node() macro
From: Grant Likely @ 2011-10-24 14:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1319450012-13033-1-git-send-email-nicolas.ferre@atmel.com>
On Mon, Oct 24, 2011 at 11:53:32AM +0200, Nicolas Ferre wrote:
> Add an empty macro for of_match_node() that will save
> some '#ifdef CONFIG_OF' for non-dt builds.
>
> I have chosen to use a macro instead of a function to
> be able to avoid defining the first parameter.
> In fact, this "struct of_device_id *" first parameter
> is usualy not defined as well on non-dt builds.
>
> Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
After private discussion, yes this is okay. I've picked it up.
g.
> ---
> include/linux/of.h | 1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/include/linux/of.h b/include/linux/of.h
> index 736b747..92c40a1 100644
> --- a/include/linux/of.h
> +++ b/include/linux/of.h
> @@ -303,6 +303,7 @@ static inline struct device_node *of_parse_phandle(struct device_node *np,
> }
>
> #define of_match_ptr(_ptr) NULL
> +#define of_match_node(_matches, _node) NULL
> #endif /* CONFIG_OF */
>
> static inline int of_property_read_u32(const struct device_node *np,
> --
> 1.7.5.4
>
^ permalink raw reply
* Re: [PATCH] dt: Add empty of_match_node() macro
From: Grant Likely @ 2011-10-24 14:25 UTC (permalink / raw)
To: Nicolas Ferre
Cc: robherring2, linux-kernel, linux-arm-kernel, devicetree-discuss
In-Reply-To: <1319450012-13033-1-git-send-email-nicolas.ferre@atmel.com>
On Mon, Oct 24, 2011 at 11:53:32AM +0200, Nicolas Ferre wrote:
> Add an empty macro for of_match_node() that will save
> some '#ifdef CONFIG_OF' for non-dt builds.
>
> I have chosen to use a macro instead of a function to
> be able to avoid defining the first parameter.
> In fact, this "struct of_device_id *" first parameter
> is usualy not defined as well on non-dt builds.
>
> Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
After private discussion, yes this is okay. I've picked it up.
g.
> ---
> include/linux/of.h | 1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/include/linux/of.h b/include/linux/of.h
> index 736b747..92c40a1 100644
> --- a/include/linux/of.h
> +++ b/include/linux/of.h
> @@ -303,6 +303,7 @@ static inline struct device_node *of_parse_phandle(struct device_node *np,
> }
>
> #define of_match_ptr(_ptr) NULL
> +#define of_match_node(_matches, _node) NULL
> #endif /* CONFIG_OF */
>
> static inline int of_property_read_u32(const struct device_node *np,
> --
> 1.7.5.4
>
^ permalink raw reply
* Re: [Qemu-devel] [Question] dump memory when host pci device is used by guest
From: Dave Anderson @ 2011-10-24 14:25 UTC (permalink / raw)
To: Wen Congyang
Cc: Jan Kiszka, Luiz Capitulino, qemu-devel, KAMEZAWA Hiroyuki,
Richard W.M. Jones
In-Reply-To: <4EA4CC7E.5000307@cn.fujitsu.com>
----- Original Message -----
> The question is that: 'virsh dump' can not be used when host pci device
> is used by guest. We are discussing how to fix the problem. We have determined
> that introduce a new monitor command dump. Jan suggested that the core file's
> format is gdb standard core format. Does crash support such format? If no,
> is it possible to support such format?
If you are talking about an ELF core dump of the user-space qemu-kvm process
running on the host, then it's certainly not supported.
As to whether it's possible, I suppose it could be done if a phyical-memory-read
function could be created for it, similar to what I asked about for live analysis
of a guest kernel run on/from the KVM host.
Dave
^ permalink raw reply
* Re: [PATCH V2 02/10] Introduce HostPCIDevice to access a pci device on the host.
From: Anthony PERARD @ 2011-10-24 14:25 UTC (permalink / raw)
To: Stefano Stabellini; +Cc: Xen Devel, QEMU-devel
In-Reply-To: <alpine.DEB.2.00.1110201136590.3519@kaball-desktop>
On Thu, Oct 20, 2011 at 11:57, Stefano Stabellini
<stefano.stabellini@eu.citrix.com> wrote:
> On Wed, 19 Oct 2011, Anthony PERARD wrote:
>> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
>> ---
>> Makefile.target | 1 +
>> hw/host-pci-device.c | 245 ++++++++++++++++++++++++++++++++++++++++++++++++++
>> hw/host-pci-device.h | 75 +++++++++++++++
>> 3 files changed, 321 insertions(+), 0 deletions(-)
>> create mode 100644 hw/host-pci-device.c
>> create mode 100644 hw/host-pci-device.h
>>
>> diff --git a/Makefile.target b/Makefile.target
>> index c518103..ca3420d 100644
>> --- a/Makefile.target
>> +++ b/Makefile.target
>> @@ -209,6 +209,7 @@ obj-$(CONFIG_NO_XEN) += xen-stub.o
>> obj-i386-$(CONFIG_XEN) += xen_platform.o
>>
>> # Xen PCI Passthrough
>> +obj-i386-$(CONFIG_XEN_PCI_PASSTHROUGH) += host-pci-device.o
>>
>> # Inter-VM PCI shared memory
>> CONFIG_IVSHMEM =
>> diff --git a/hw/host-pci-device.c b/hw/host-pci-device.c
>> new file mode 100644
>> index 0000000..0f25fcf
>> --- /dev/null
>> +++ b/hw/host-pci-device.c
>> @@ -0,0 +1,245 @@
>> +/*
>> + * Copyright (C) 2011 Citrix Ltd.
>> + *
>> + * This work is licensed under the terms of the GNU GPL, version 2. See
>> + * the COPYING file in the top-level directory.
>> + *
>> + */
>> +
>> +#include "qemu-common.h"
>> +#include "host-pci-device.h"
>> +
>> +static int path_to(const HostPCIDevice *d,
>> + const char *name, char *buf, ssize_t size)
>> +{
>> + return snprintf(buf, size, "/sys/bus/pci/devices/%04x:%02x:%02x.%x/%s",
>> + d->domain, d->bus, d->dev, d->func, name);
>> +}
>> +
>> +static int get_resource(HostPCIDevice *d)
>> +{
>> + int i, rc = 0;
>> + FILE *f;
>> + char path[PATH_MAX];
>> + unsigned long long start, end, flags, size;
>> +
>> + path_to(d, "resource", path, sizeof (path));
>> + f = fopen(path, "r");
>> + if (!f) {
>> + fprintf(stderr, "Error: Can't open %s: %s\n", path, strerror(errno));
>> + return -1;
>
> it would be better to return a proper error code, rather than just -1
probably -errno will do it.
>> + }
>> +
>> + for (i = 0; i < PCI_NUM_REGIONS; i++) {
>> + if (fscanf(f, "%llx %llx %llx", &start, &end, &flags) != 3) {
>> + fprintf(stderr, "Error: Syntax error in %s\n", path);
>> + rc = -1;
>
> Ditto
probably 1 with a define on the top of the file.
>> + break;
>> + }
>> + if (start) {
>> + size = end - start + 1;
>> + } else {
>> + size = 0;
>> + }
>> +
>> + if (i < PCI_ROM_SLOT) {
>> + d->io_regions[i].base_addr = start;
>> + d->io_regions[i].size = size;
>> + d->io_regions[i].flags = flags;
>> + } else {
>> + d->rom.base_addr = start;
>> + d->rom.size = size;
>> + d->rom.flags = flags;
>> + }
>> + }
>> +
>> + fclose(f);
>> + return rc;
>> +}
[...]
>> +
>> +uint32_t host_pci_find_ext_cap_offset(HostPCIDevice *d, uint32_t cap)
>> +{
>> + uint32_t header = 0;
>> + int max_cap = 480;
>> + int pos = 0x100;
>
> could you used some defined constants here?
Yes, I will.
>> + do {
>> + header = host_pci_get_long(d, pos);
>> + /*
>> + * If we have no capabilities, this is indicated by cap ID,
>> + * cap version and next pointer all being 0.
>> + */
>> + if (header == 0) {
>> + break;
>> + }
>> +
>> + if (PCI_EXT_CAP_ID(header) == cap) {
>> + return pos;
>> + }
>> +
>> + pos = PCI_EXT_CAP_NEXT(header);
>> + if (pos < 0x100) {
>> + break;
>> + }
>> +
>> + max_cap--;
>> + } while (max_cap > 0);
>> +
>> + return 0;
>> +}
--
Anthony PERARD
^ permalink raw reply
* Where is the getent(1) man page source?
From: Mark R Bannister @ 2011-10-24 14:26 UTC (permalink / raw)
To: mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w
Cc: linux-man-u79uwXL29TY76Z2rM5mHXA, espy-8fiUuRrzOP0dnm+yROfE0A
The getent.c source code is in glibc, so I'd expect to find the getent.1 man page
in the Linux man-pages project. But it's not there. Where is it? I'd like to
make it more informative.
Thanks,
Mark.
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [Qemu-devel] [PATCH V2 02/10] Introduce HostPCIDevice to access a pci device on the host.
From: Anthony PERARD @ 2011-10-24 14:25 UTC (permalink / raw)
To: Stefano Stabellini; +Cc: Xen Devel, QEMU-devel
In-Reply-To: <alpine.DEB.2.00.1110201136590.3519@kaball-desktop>
On Thu, Oct 20, 2011 at 11:57, Stefano Stabellini
<stefano.stabellini@eu.citrix.com> wrote:
> On Wed, 19 Oct 2011, Anthony PERARD wrote:
>> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
>> ---
>> Makefile.target | 1 +
>> hw/host-pci-device.c | 245 ++++++++++++++++++++++++++++++++++++++++++++++++++
>> hw/host-pci-device.h | 75 +++++++++++++++
>> 3 files changed, 321 insertions(+), 0 deletions(-)
>> create mode 100644 hw/host-pci-device.c
>> create mode 100644 hw/host-pci-device.h
>>
>> diff --git a/Makefile.target b/Makefile.target
>> index c518103..ca3420d 100644
>> --- a/Makefile.target
>> +++ b/Makefile.target
>> @@ -209,6 +209,7 @@ obj-$(CONFIG_NO_XEN) += xen-stub.o
>> obj-i386-$(CONFIG_XEN) += xen_platform.o
>>
>> # Xen PCI Passthrough
>> +obj-i386-$(CONFIG_XEN_PCI_PASSTHROUGH) += host-pci-device.o
>>
>> # Inter-VM PCI shared memory
>> CONFIG_IVSHMEM =
>> diff --git a/hw/host-pci-device.c b/hw/host-pci-device.c
>> new file mode 100644
>> index 0000000..0f25fcf
>> --- /dev/null
>> +++ b/hw/host-pci-device.c
>> @@ -0,0 +1,245 @@
>> +/*
>> + * Copyright (C) 2011 Citrix Ltd.
>> + *
>> + * This work is licensed under the terms of the GNU GPL, version 2. See
>> + * the COPYING file in the top-level directory.
>> + *
>> + */
>> +
>> +#include "qemu-common.h"
>> +#include "host-pci-device.h"
>> +
>> +static int path_to(const HostPCIDevice *d,
>> + const char *name, char *buf, ssize_t size)
>> +{
>> + return snprintf(buf, size, "/sys/bus/pci/devices/%04x:%02x:%02x.%x/%s",
>> + d->domain, d->bus, d->dev, d->func, name);
>> +}
>> +
>> +static int get_resource(HostPCIDevice *d)
>> +{
>> + int i, rc = 0;
>> + FILE *f;
>> + char path[PATH_MAX];
>> + unsigned long long start, end, flags, size;
>> +
>> + path_to(d, "resource", path, sizeof (path));
>> + f = fopen(path, "r");
>> + if (!f) {
>> + fprintf(stderr, "Error: Can't open %s: %s\n", path, strerror(errno));
>> + return -1;
>
> it would be better to return a proper error code, rather than just -1
probably -errno will do it.
>> + }
>> +
>> + for (i = 0; i < PCI_NUM_REGIONS; i++) {
>> + if (fscanf(f, "%llx %llx %llx", &start, &end, &flags) != 3) {
>> + fprintf(stderr, "Error: Syntax error in %s\n", path);
>> + rc = -1;
>
> Ditto
probably 1 with a define on the top of the file.
>> + break;
>> + }
>> + if (start) {
>> + size = end - start + 1;
>> + } else {
>> + size = 0;
>> + }
>> +
>> + if (i < PCI_ROM_SLOT) {
>> + d->io_regions[i].base_addr = start;
>> + d->io_regions[i].size = size;
>> + d->io_regions[i].flags = flags;
>> + } else {
>> + d->rom.base_addr = start;
>> + d->rom.size = size;
>> + d->rom.flags = flags;
>> + }
>> + }
>> +
>> + fclose(f);
>> + return rc;
>> +}
[...]
>> +
>> +uint32_t host_pci_find_ext_cap_offset(HostPCIDevice *d, uint32_t cap)
>> +{
>> + uint32_t header = 0;
>> + int max_cap = 480;
>> + int pos = 0x100;
>
> could you used some defined constants here?
Yes, I will.
>> + do {
>> + header = host_pci_get_long(d, pos);
>> + /*
>> + * If we have no capabilities, this is indicated by cap ID,
>> + * cap version and next pointer all being 0.
>> + */
>> + if (header == 0) {
>> + break;
>> + }
>> +
>> + if (PCI_EXT_CAP_ID(header) == cap) {
>> + return pos;
>> + }
>> +
>> + pos = PCI_EXT_CAP_NEXT(header);
>> + if (pos < 0x100) {
>> + break;
>> + }
>> +
>> + max_cap--;
>> + } while (max_cap > 0);
>> +
>> + return 0;
>> +}
--
Anthony PERARD
^ permalink raw reply
* Re: [22/27] VFS: Fix automount for negative autofs dentries
From: Greg KH @ 2011-10-24 14:22 UTC (permalink / raw)
To: Miklos Szeredi
Cc: Greg KH, Linus Torvalds, David Howells, linux-kernel, stable,
stable-review, akpm, alan, Ian Kent, Al Viro, Chuck Ebbert,
Trond Myklebust
In-Reply-To: <87pqhnifew.fsf@tucsk.pomaz.szeredi.hu>
On Sun, Oct 23, 2011 at 11:09:11PM +0200, Miklos Szeredi wrote:
> Greg KH <gregkh@suse.de> writes:
>
> > On Sun, Oct 23, 2011 at 10:35:14AM +0300, Linus Torvalds wrote:
> >> This one is debatable.
> >>
> >> I think it also wants
> >>
> >> - commit 0ec26fd0698285b31248e34bf1abb022c00f23d6 (with
> >> LOOKUP_PARENT->LOOKUP_CONTINUE too)
> >
> > Really? I thought I dropped this one from the last stable release due
> > to problems with it, or does this patch here, and the one you mention
> > below, resolve those issues?
> >
> >> - commit d94c177beeb4469cd4f6e83354ab0223353e98ed (to get the few
> >> other cases right too)
> >>
> >> anything else I missed?
> >
> > Ok, that makes a bit more sense, I'll add these if David and Miklos
> > agree that they are ok to add here. David and Miklos?
>
> IMO they are OK to add as long as they are both added.
>
> Last time the first one had to be backed out because Linus wasn't
> totally comfortable with the other one going into -stable until it got
> some testing in 3.1. Or at least that's how I understood (or
> misunderstood).
Ok, I tried applying these patches, but they didn't apply. I tried
digging the patches out of the suse kernel tree, but they didn't seem to
include all of the needed ones here.
So, I'm going to drop this patch from the 3.0.8 release, can someone
please send me the needed patches, backported to 3.0, so that I know
they are working properly?
thanks,
greg k-h
^ permalink raw reply
* Re: [Qemu-devel] [PATCH V2 08/10] Introduce Xen PCI Passthrough, qdevice (1/3)
From: Anthony PERARD @ 2011-10-24 14:29 UTC (permalink / raw)
To: Stefano Stabellini; +Cc: Xen Devel, QEMU-devel
In-Reply-To: <alpine.DEB.2.00.1110201141280.3519@kaball-desktop>
On Thu, Oct 20, 2011 at 11:59, Stefano Stabellini
<stefano.stabellini@eu.citrix.com> wrote:
>> + if (s->pm_state != NULL && s->pm_state->flags & PT_FLAG_TRANSITING) {
>> + qemu_mod_timer(s->pm_state->pm_timer,
>> + qemu_get_clock_ms(rt_clock) + s->pm_state->pm_delay);
>> + }
>
> where is this allocated?
The allocation is in the next patch, the long file that handle the config space.
--
Anthony PERARD
^ 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.