* Re: [Qemu-devel] [PATCH v2 3/4] Add cap reduction support to enable use as SUID
From: Blue Swirl @ 2011-10-23 13:22 UTC (permalink / raw)
To: Corey Bryant; +Cc: rmarwah, aliguori, qemu-devel
In-Reply-To: <1319209643-3866-4-git-send-email-coreyb@linux.vnet.ibm.com>
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.
> + 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
>
>
>
^ permalink raw reply
* Re: [RFC][PATCH 0/2] PM / Sleep: Extended control of suspend/hibernate interfaces
From: Rafael J. Wysocki @ 2011-10-23 13:16 UTC (permalink / raw)
To: NeilBrown; +Cc: Linux PM list, mark gross, LKML, John Stultz, Alan Stern
In-Reply-To: <20111023135745.2bfe1d80@notabene.brown>
On Sunday, October 23, 2011, NeilBrown wrote:
> On Sun, 23 Oct 2011 00:07:33 +0200 "Rafael J. Wysocki" <rjw@sisk.pl> wrote:
>
> > On Tuesday, October 18, 2011, NeilBrown wrote:
> > > On Tue, 18 Oct 2011 00:02:30 +0200 "Rafael J. Wysocki" <rjw@sisk.pl> wrote:
> > >
> > > > On Monday, October 17, 2011, NeilBrown wrote:
> > > > > On Sun, 16 Oct 2011 00:10:40 +0200 "Rafael J. Wysocki" <rjw@sisk.pl> wrote:
> > > > ...
> > > > > >
> > > > > > > But I think it is very wrong to put some hack in the kernel like your
> > > > > > > suspend_mode = disabled
> > > > > >
> > > > > > Why is it wrong and why do you think it is a "hack"?
> > > > >
> > > > > I think it is a "hack" because it is addressing a specific complaint rather
> > > > > than fixing a real problem.
> > > >
> > > > I wonder why you think that there's no real problem here.
> > > >
> > > > The problem I see is that multiple processes can use the suspend/hibernate
> > > > interfaces pretty much at the same time (not exactly in parallel, becuase
> > > > there's some locking in there, but very well there may be two different
> > > > processes operating /sys/power/state independently of each other), while
> > > > the /sys/power/wakeup_count interface was designed with the assumption that
> > > > there will be only one such process in mind.
> > >
> > > Multiple process can write to your mail box at the same time. But some how
> > > they don't. This isn't because the kernel enforces anything, but because all
> > > the relevant programs have an agreed protocol by which they arbitrate access.
> > > One upon a time this involved creating a lock file with O_CREAT|O_EXCL.
> > > These days it is fcntl locking. But it is still advisory.
> > >
> > > In the same way - we stop multiple processes from suspending/hibernating at
> > > the same time by having an agreed protocol by which they share access to the
> > > resource. The kernel does not need to be explicitly involved in this.
> >
> > Not really. The main difference is that such a protocol doesn't exist for
> > processes that may want to suspend/hibernate the system.
> >
> > Moreover, the race is real, because if you have two processes trying to use
> > /sys/power/wakeup_count at the same time, you can get:
> >
> > Process A Process B
> > read from wakeup_count
> > talk to apps
> > write to wakeup_count
> > --------- wakeup event ----------
> > read from wakeup_count
> > talk to apps
> > write to wakeup_count
> > try to suspend -> success (should be failure, because the wakeup event
> > may still be processed by applications at this point and Process A hasn't
> > checked that).
> >
> > Now, there are systems running two (or more) desktop environments each of
> > which has a power manager that may want to suspend on it's own. They both
> > will probably use pm-utils, but then I somehow doubt that pm-utils is well
> > prepared to handle such concurrency.
>
> I think that "upowerd" is the current "solution" to this problem. Different
> desktops can communicate with it to negotiate when suspend will happen.
>
> When upowerd decides to suspend, it calls the relevant pm_utils command.
>
> So with modern desktops we would never expect two different processes to be
> requesting pm_utils to suspend at the same time. If we did that would be a
> problem but we don't. There is no race here to fix.
I have a slightly different view on that. Since there is no mechanism to
prevent the race from occuring, we need to assume the race is going to happen
in certain situations.
> I'm not certain that upowerd provides good interfaces. But its existence
> shows that this sort of problem that you see is not that hard to solve.
>
> Sure: people could still design systems which exhibited racy access to
> suspend, but people have always being able to write buggy code - making up
> new interfaces isn't going to stop them.
I'd say that depends on what the new interfaces are. For one, I wouldn't
agree with the statement that we couldn't invent interfaces that were better
than what we had. :-)
> >
> > >
> > > ...
> > >
> > > > > > Well, I used to think that it's better to do things in user space. Hence,
> > > > > > the hibernate user space interface that's used by many people. And my
> > > > > > experience with that particular thing made me think that doing things in
> > > > > > the kernel may actually work better, even if they _can_ be done in user space.
> > > > > >
> > > > > > Obviously, that doesn't apply to everything, but sometimes it simply is worth
> > > > > > discussing (if not trying). If it doesn't work out, then fine, let's do it
> > > > > > differently, but I'm really not taking the "this should be done in user space"
> > > > > > argument at face value any more. Sorry about that.
> > > > >
> > > > > :-) I have had similar mixed experiences. Sometimes it can be a lot easier
> > > > > to get things working if it is all in the kernel.
> > > > > But I think that doing things in user-space leads to a lot more flexibility.
> > > > > Once you have the interfaces and designs worked out you can then start doing
> > > > > more interesting things and experimenting with ideas more easily.
> > > > >
> > > > > In this case, I think the *only* barrier to a simple solution in user-space
> > > > > is the pre-existing software that uses the 'old' kernel interface. It seems
> > > > > that interfacing with that is as easy as adding a script or two to pm-utils.
> > > >
> > > > Well, assuming that we're only going to address the systems that use PM utils.
> > >
> > > I suspect (and claim without proof :-) that any system will have some single
> > > user-space thing that is responsible for initiating suspend.
> >
> > Well, see above.
>
> See also upowerd.
>
>
> >
> > > Every time I look at one I see a whole host of things that need to be done
> > > just before suspend, and other things just after resume.
> > > They used to be in /etc/apm/event.d. Now there are
> > > in /usr/lib/pm-utils/sleep.d.
> >
> > I know of systems that don't need those hooks, however.
> >
> > > I think they were in /etc/acpid once.
> > > I've seen one thing that uses shared-library modules instead of shell scripts
> > > on the basis that it avoids forking and goes fast (and it probably does).
> > > But I doubt there is any interesting system where writing to /sys/power/state
> > > is the *only* thing you need to do for a clean suspend.
> >
> > I have such a system on my desk. :-)
>
> :-)
> I guess I would have to conclude that it is therefore not interesting :-)
>
> Would you accept that is more of an exception than the rule?
Not really. For example, on systems that run Android it is not necessary to
do anything in user space before suspending and after resuming. There is quite
a number of such systems around.
> The real point though is that lots of system do want pre/post scripts, so we
> can expect that avoiding races between such scripts is a solved problem - and
> this is what we find in e.g. upowerd.
Well, I'm not entirely convinced that this is the case. :-)
> > > So all systems will have some user-space infrastructure to support suspend,
> > > and we just need to hook in to that.
> > >
> > >
> > > >
> > > > > With that problem solved, experimenting is much easier in user-space than in
> > > > > the kernel.
> > > >
> > > > Somehow, I'm not exactly sure if we should throw all kernel-based solutions away
> > > > just yet.
> > >
> > > My rule-of-thumb is that we should reserve kernel space for when
> > > a/ it cannot be done in user space
> > > b/ it cannot be done efficient in user space
> > > c/ it cannot be done securely in user space
> > >
> > > I don't think any of those have been demonstrated yet. If/when they are it
> > > would be good to get those kernel-based solutions out of the draw (so yes:
> > > keep them out of the rubbish bin).
> >
> > I have one more rule. If my would-be user space solution has the following
> > properties:
> >
> > * It is supposed to be used by all of the existing variants of user space
> > (i.e. all existing variants of user space are expected to use the very same
> > thing).
> >
> > * It requires all of those user space variants to be modified to work with it
> > correctly.
> >
> > * It includes a daemon process having to be started on boot and run permanently.
> >
> > then it likely is better to handle the problem in the kernel.
>
> By that set or rules, upowerd, dbus, pulse audio, bluez, and probably systemd
> all need to go in the kernel. My guess is that you might not find wide
> acceptance for these rules.
Well, that's not what I thought. Perhaps I didn't express that precisely
enough. Take systemd, for example. You still can design and use a Linux-based
system without systemd, so there's no requirement that _all_ variants of user
space use the given approach. The choice of whether or not to use systemd
is not a choice between a working and non-working system.
However, this is not the case with the system daemon, becuase it's supposed
to handle problems that aren't possible to address without it. So either you
use it, or you end up with a (slightly) broken system.
> > > So I'd respond with "I'm not at all sure that we should throw away an
> > > all-userspace solution just yet". Particularly because many of us seem to
> > > still be working to understand what all the issues really are.
> >
> > OK, so perhaps we should try to implement two concurrent solutions, one
> > kernel-based and one purely in user space and decide which one is better
> > afterwards?
>
> Absolutely.
>
> My primary reason for entering this discussion is eloquently presented in
> http://xkcd.com/386/
>
> Someone said "We need to change the kernel to get race-free suspend" and this
> simply is not true. I wanted to present a way to use the existing
> functionality to provide race-free suspend - and now even have code to do it.
>
> If someone else wants to write a different implementation, either in
> userspace or kernel that is fine.
>
> They can then present it as "I know this can be implemented in userspace, but
> I don't like that solution for reasons X, Y, Z and so here is my better
> kernel-space implementation" then that is cool. We can examine X, Y, Z and
> the code and see if the argument holds up. Maybe it will, maybe not.
>
> So far the only arguments I've seen for putting the code in the kernel are:
>
> 1/ it cannot be done in userspace - demonstrably wrong
I'm not sure if that's correct. If you meant "it can be done in user space
without _any_ kernel modifications", I probably wouldn't agree.
> 2/ it is more efficient in the kernel - not demonstrated or even
> convincingly argued
I don't agree with that, but let's see.
> 3/ doing it in user-space is too confusing - we would need a clear
> demonstration that a kernel interface is less confusing - and still
> correct. Also the best way to remove confusion is with clear
> documentation and sample code, not by making up new interfaces.
The user space solution makes up new interfaces too, although they are
confined to user space.
To me, it all boils down to two factors: (1) the complexity and efficiency
of the code needed to implement the feature and (2) the complexity of the
resulting framework (be it in the kernel or in user space).
> 4/ doing it in the kernel makes it more accessible to multiple desktops.
> The success of freedesktop.org seems to contradict that.
I don't agree here too. Is Android a member of freedesktop.org?
> So if you can do it a "better" way, please do. But also please make sure
> you can quantify "better". I claim that user-space solutions are "better"
> because they are more flexible and easier to experiment with. The "no
> regressions" rule actively discourages experimentation in the kernel so
> people should only do it if there is a clear benefit.
You seem to suppose that every kernel modification necessarily has a potential
to lead to some regressions. I'm not exactly use if that's correct
(e.g. adding a new driver usually doesn't affect people who don't need it).
> User-space solutions are much easier to introduce and then deprecate.
That's demonstrably incorrect and the counter example is the hibernation user
space interface. The sheer amount of work needed to implement user
space-driven hibernation and maintain that code shows that it's not exactly
easy and it would be more difficult to deprecate than many existing kernel
interfaces at this point.
So, even if you have implemented something in user space, the "no regressions"
rule and deprecation difficulties will apply to it as well as to the kernel as
soon as you make a sufficient number of people use it.
Thanks,
Rafael
^ permalink raw reply
* Re: [RFC 4/7] mac80211: setting link-specific mesh power modes when plink open
From: Ivan Bezyazychnyy @ 2011-10-23 13:12 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless
In-Reply-To: <1319191502.3964.11.camel@jlt3.sipsolutions.net>
On 21 October 2011 14:05, Johannes Berg <johannes@sipsolutions.net> wrote:
> On Fri, 2011-10-21 at 12:37 +0400, Ivan Bezyazychnyy wrote:
>> Setting peer link-specific power mode equal to peer non-peer power mode
>> value and local link-specific power mode equal to local non-peer value
>
> You really need more verbose changelogs, I can't even parse that
> properly. How about mentioning why, what it means, etc?
Yes, I understand.
> You should also extend your cover letter to explain how the power save
> stuff works.
OK. Thank you very much for all comments.
--Ivan
^ permalink raw reply
* Re: [Qemu-devel] [PATCH v2 2/4] Add access control support to qemu bridge helper
From: Blue Swirl @ 2011-10-23 13:10 UTC (permalink / raw)
To: Corey Bryant; +Cc: rmarwah, aliguori, qemu-devel
In-Reply-To: <1319209643-3866-3-git-send-email-coreyb@linux.vnet.ibm.com>
On Fri, Oct 21, 2011 at 15:07, Corey Bryant <coreyb@linux.vnet.ibm.com> wrote:
> We go to great lengths to restrict ourselves to just cap_net_admin as an OS
> enforced security mechanism. However, we further restrict what we allow users
> to do to simply adding a tap device to a bridge interface by virtue of the fact
> that this is the only functionality we expose.
>
> This is not good enough though. An administrator is likely to want to restrict
> the bridges that an unprivileged user can access, in particular, to restrict
> an unprivileged user from putting a guest on what should be isolated networks.
>
> This patch implements an ACL mechanism that is enforced by qemu-bridge-helper.
> The ACLs are fairly simple whitelist/blacklist mechanisms with a wildcard of
> 'all'. All users are blacklisted by default, and deny takes precedence over
> allow.
>
> An interesting feature of this ACL mechanism is that you can include external
> ACL files. The main reason to support this is so that you can set different
> file system permissions on those external ACL files. This allows an
> administrator to implement rather sophisicated ACL policies based on user/group
sophisticated
> policies via the file system.
>
> As an example:
>
> /etc/qemu/bridge.conf root:qemu 0640
>
> allow br0
> include /etc/qemu/alice.conf
> include /etc/qemu/bob.conf
> include /etc/qemu/charlie.conf
>
> /etc/qemu/alice.conf root:alice 0640
> allow br1
>
> /etc/qemu/bob.conf root:bob 0640
> allow br2
>
> /etc/qemu/charlie.conf root:charlie 0640
> deny all
I think syntax 'include /etc/qemu/user.d/*.conf' or 'includedir
/etc/qemu/user.d' could be also useful.
> This ACL pattern allows any user in the qemu group to get a tap device
> connected to br0 (which is bridged to the physical network).
>
> Users in the alice group can additionally get a tap device connected to br1.
> This allows br1 to act as a private bridge for the alice group.
>
> Users in the bob group can additionally get a tap device connected to br2.
> This allows br2 to act as a private bridge for the bob group.
>
> Users in the charlie group cannot get a tap device connected to any bridge.
>
> Under no circumstance can the bob group get access to br1 or can the alice
> group get access to br2. And under no cicumstance can the charlie group
> get access to any bridge.
>
> 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>
> ---
> qemu-bridge-helper.c | 141 ++++++++++++++++++++++++++++++++++++++++++++++++++
> 1 files changed, 141 insertions(+), 0 deletions(-)
>
> diff --git a/qemu-bridge-helper.c b/qemu-bridge-helper.c
> index 2ce82fb..db257d5 100644
> --- a/qemu-bridge-helper.c
> +++ b/qemu-bridge-helper.c
> @@ -33,6 +33,105 @@
>
> #include "net/tap-linux.h"
>
> +#define MAX_ACLS (128)
If all users (or groups) in the system have an ACL, this number could
be way too low. Please use a list instead.
> +#define DEFAULT_ACL_FILE CONFIG_QEMU_CONFDIR "/bridge.conf"
> +
> +enum {
> + ACL_ALLOW = 0,
> + ACL_ALLOW_ALL,
> + ACL_DENY,
> + ACL_DENY_ALL,
> +};
> +
> +typedef struct ACLRule {
> + int type;
> + char iface[IFNAMSIZ];
> +} ACLRule;
> +
> +static int parse_acl_file(const char *filename, ACLRule *acls, int *pacl_count)
> +{
> + int acl_count = *pacl_count;
> + FILE *f;
> + char line[4096];
> +
> + f = fopen(filename, "r");
> + if (f == NULL) {
> + return -1;
> + }
> +
> + while (acl_count != MAX_ACLS &&
> + fgets(line, sizeof(line), f) != NULL) {
> + char *ptr = line;
> + char *cmd, *arg, *argend;
> +
> + while (isspace(*ptr)) {
> + ptr++;
> + }
> +
> + /* skip comments and empty lines */
> + if (*ptr == '#' || *ptr == 0) {
> + continue;
> + }
> +
> + cmd = ptr;
> + arg = strchr(cmd, ' ');
> + if (arg == NULL) {
> + arg = strchr(cmd, '\t');
> + }
> +
> + if (arg == NULL) {
> + fprintf(stderr, "Invalid config line:\n %s\n", line);
> + fclose(f);
> + errno = EINVAL;
> + return -1;
> + }
> +
> + *arg = 0;
> + arg++;
> + while (isspace(*arg)) {
> + arg++;
> + }
> +
> + argend = arg + strlen(arg);
> + while (arg != argend && isspace(*(argend - 1))) {
> + argend--;
> + }
These while loops to skip spaces are repeated, but the comment
skipping part is not, so it is not possible to have comments after
rules or split rules to several lines. I'd add a simple state variable
to track at which stage we are in parsing instead.
> + *argend = 0;
> +
> + if (strcmp(cmd, "deny") == 0) {
> + if (strcmp(arg, "all") == 0) {
> + acls[acl_count].type = ACL_DENY_ALL;
> + } else {
> + acls[acl_count].type = ACL_DENY;
> + snprintf(acls[acl_count].iface, IFNAMSIZ, "%s", arg);
> + }
> + acl_count++;
> + } else if (strcmp(cmd, "allow") == 0) {
> + if (strcmp(arg, "all") == 0) {
> + acls[acl_count].type = ACL_ALLOW_ALL;
> + } else {
> + acls[acl_count].type = ACL_ALLOW;
> + snprintf(acls[acl_count].iface, IFNAMSIZ, "%s", arg);
> + }
> + acl_count++;
> + } else if (strcmp(cmd, "include") == 0) {
> + /* ignore errors */
> + parse_acl_file(arg, acls, &acl_count);
> + } else {
> + fprintf(stderr, "Unknown command `%s'\n", cmd);
> + fclose(f);
> + errno = EINVAL;
> + return -1;
> + }
> + }
> +
> + *pacl_count = acl_count;
> +
> + fclose(f);
> +
> + return 0;
> +}
> +
> static int has_vnet_hdr(int fd)
> {
> unsigned int features = 0;
> @@ -95,6 +194,9 @@ int main(int argc, char **argv)
> const char *bridge;
> char iface[IFNAMSIZ];
> int index;
> + ACLRule acls[MAX_ACLS];
> + int acl_count = 0;
> + int i, access_allowed, access_denied;
>
> /* parse arguments */
> if (argc < 3 || argc > 4) {
> @@ -115,6 +217,45 @@ int main(int argc, char **argv)
> bridge = argv[index++];
> unixfd = atoi(argv[index++]);
>
> + /* parse default acl file */
> + if (parse_acl_file(DEFAULT_ACL_FILE, acls, &acl_count) == -1) {
> + fprintf(stderr, "failed to parse default acl file `%s'\n",
> + DEFAULT_ACL_FILE);
> + return -errno;
> + }
> +
> + /* validate bridge against acl -- default policy is to deny
> + * according acl policy if we have a deny and allow both
> + * then deny should always win over allow
> + */
> + access_allowed = 0;
> + access_denied = 0;
> + for (i = 0; i < acl_count; i++) {
> + switch (acls[i].type) {
> + case ACL_ALLOW_ALL:
> + access_allowed = 1;
> + break;
> + case ACL_ALLOW:
> + if (strcmp(bridge, acls[i].iface) == 0) {
> + access_allowed = 1;
> + }
> + break;
> + case ACL_DENY_ALL:
> + access_denied = 1;
> + break;
> + case ACL_DENY:
> + if (strcmp(bridge, acls[i].iface) == 0) {
> + access_denied = 1;
> + }
> + break;
> + }
> + }
> +
> + if ((access_allowed == 0) || (access_denied == 1)) {
> + fprintf(stderr, "access denied by acl file\n");
> + return -EPERM;
> + }
> +
> /* open a socket to use to control the network interfaces */
> ctlfd = socket(AF_INET, SOCK_STREAM, 0);
> if (ctlfd == -1) {
> --
> 1.7.3.4
>
>
>
^ permalink raw reply
* Re: [RFC 1/7] mac80211: mesh power mode indication in QoS frames
From: Ivan Bezyazychnyy @ 2011-10-23 13:10 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless
In-Reply-To: <1319190767.3964.8.camel@jlt3.sipsolutions.net>
On 21 October 2011 13:52, Johannes Berg <johannes@sipsolutions.net> wrote:
> On Fri, 2011-10-21 at 12:36 +0400, Ivan Bezyazychnyy wrote:
>
>> +/* mesh power save level subfield mask */
>> +#define IEEE80211_QOS_CTL_PS_LEVEL 0x0200
>
> That looks like it could use a better name?
Do you mean something like IEEE80211_QOS_CTL_MESH_POWER_SAVE_LEVEL?
The first half is similar to previous constants.
Thanks,
Ivan
^ permalink raw reply
* Register cache different from the real register values
From: Leon Romanovsky @ 2011-10-23 13:09 UTC (permalink / raw)
To: alsa-devel
Hi, I need your suggestions, I'm trying to add new codec to use the
asoc subsystem, all read/write operations done via standard snd_soc_*
functions with cache enabled, but register cache is different from the
real register values. Can you point me to what can I check?
Our code is based on 2.6.38 release.
Thanks
--
Leon Romanovsky | Independent Linux Consultant
www.leon.nu | leon@leon.nu
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
^ permalink raw reply
* Re: [Qemu-devel] [PATCH v2 1/4] Add basic version of bridge helper
From: Blue Swirl @ 2011-10-23 12:56 UTC (permalink / raw)
To: Corey Bryant; +Cc: rmarwah, aliguori, qemu-devel
In-Reply-To: <1319209643-3866-2-git-send-email-coreyb@linux.vnet.ibm.com>
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.
> +
> + /* 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
>
>
>
^ permalink raw reply
* [PATCH v2 1/7] clk: Add a generic clock infrastructure
From: Shawn Guo @ 2011-10-23 12:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1316730422-20027-2-git-send-email-mturquette@ti.com>
Hi Mike,
Some random comments/nits ...
On Thu, Sep 22, 2011 at 03:26:56PM -0700, Mike Turquette wrote:
> +struct clk *clk_register(const struct clk_hw_ops *ops, struct clk_hw *hw,
> + const char *name)
> +{
> + struct clk *clk;
> +
> + clk = kzalloc(sizeof(*clk), GFP_KERNEL);
> + if (!clk)
> + return NULL;
> +
> + INIT_HLIST_HEAD(&clk->children);
> + INIT_HLIST_NODE(&clk->child_node);
> +
The children and child_node are introduced in patch #2, and should not
be used in patch #1.
> + clk->name = name;
> + clk->ops = ops;
> + clk->hw = hw;
> + hw->clk = clk;
> +
> + /* Query the hardware for parent and initial rate */
> +
> + if (clk->ops->get_parent)
> + /* We don't to lock against prepare/enable here, as
> + * the clock is not yet accessible from anywhere */
/*
* Multiple line comments
*/
> + clk->parent = clk->ops->get_parent(clk->hw);
> +
> + if (clk->ops->recalc_rate)
> + clk->rate = clk->ops->recalc_rate(clk->hw);
> +
> +
One blank line is good enough.
> + return clk;
> +}
--
Regards,
Shawn
^ permalink raw reply
* Re: [patch net-next V2] net: introduce ethernet teaming device
From: Jiri Pirko @ 2011-10-23 12:51 UTC (permalink / raw)
To: Eric Dumazet
Cc: netdev, davem, bhutchings, shemminger, fubar, andy, tgraf,
ebiederm, mirqus, kaber, greearb, jesse, fbl, benjamin.poirier,
jzupka
In-Reply-To: <1319366709.27507.14.camel@edumazet-laptop>
Sun, Oct 23, 2011 at 12:45:09PM CEST, eric.dumazet@gmail.com wrote:
>Le dimanche 23 octobre 2011 à 10:25 +0200, Jiri Pirko a écrit :
>
>> Please forgive me, it's possible I'm missing something. But I see no way how
>> team->mode_ops.receive can change during team_handle_frame (holding
>> rcu_read_lock) for the reason I stated earlier.
>>
>> team_port_del() calls netdev_rx_handler_unregister() and after that it
>> calls synchronize_rcu(). That ensures that by the finish of team_port_del()
>> run, team_handle_frame() is not called for this port anymore.
>>
>> And this combined with "if (!list_empty(&team->port_list))" check in
>> team_change_mode() ensures safety.
>>
>> Of course team_port_del() and team_change_mode() are both protected by
>> team->lock so they are mutually excluded.
>
>Oh well.
>
>Jirka, I believe I do understand how RCU is working ;)
With this I do not argue :)
But note that team->mode_ops.receive is not rcu-protected pointer per
say (no rcu_assign, rcu_dereference).
>
>There is an obvious problem I pointed to you, but you persist leaving
>this potential bug.
>
>After netdev_rx_handler_unregister(), you can still have other cpus
>calling your handler and reading/using previous memory content. Only
>after synchronize_rcu() you can be safe. But in your patch the bug
>window is _exactly_ _before_ synchronize_rcu() returns.
Yes. And team->mode_ops.receive can change only after synchronize_rcu is
done. It's not possible it changes within the window you are talking about.
>
>Your spinlock wont help you at all, since readers dont take it.
>Spinlock only protects writers.
Sure. team->lock ensures that team_change_mode() is not called withing
the "bug window" but only after team_port_del() finishes.
>
>
>So a reader, even holding rcu lock, can really see two different
>mode_ops.receive values for the :
>
>if (team->mode_ops.receive)
> res = team->mode_ops.receive(team, port, skb);
>
>
>rcu_lock() doesnt mean the reader can see an unique .receive value,
I'm very well aware of this.
>
>I am afraid you misunderstood the point.
>
>Real point of RCU here is that the _writer_ wont returns from
>synchronize_rcu() if at least one reader is still running the handler.
>
>No problem with me, I'll just post a patch later, I just cant Ack your
>work as is.
>
>
>
^ permalink raw reply
* Re: [PATCH v7 08/16] ARM: LPAE: Page table maintenance for the 3-level format
From: Catalin Marinas @ 2011-10-23 12:49 UTC (permalink / raw)
To: Russell King - ARM Linux; +Cc: linux-kernel, linux-arm-kernel
In-Reply-To: <20111023115635.GA17912@n2100.arm.linux.org.uk>
On 23 October 2011 13:56, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Wed, Aug 10, 2011 at 04:03:31PM +0100, Catalin Marinas wrote:
>> This patch modifies the pgd/pmd/pte manipulation functions to support
>> the 3-level page table format. Since there is no need for an 'ext'
>> argument to cpu_set_pte_ext(), this patch conditionally defines a
>> different prototype for this function when CONFIG_ARM_LPAE.
>
> This has a really large number of ifdefs. You've split the 2 and 3
> level page table stuff into two different header files already,
> conditionalized on CONFIG_ARM_LPAE, yet we still end up with lots of
> junk in the common header file conditionalized on that symbol. Can't
> we find a way to restructure pgtable.h to sort this out more cleanly?
I'll look into this.
> Do we really need to change the set_pte_ext() prototype as well - do
> we _really_ need ifdefs around its declaration, and every usage of it
> as well? Can't we just leave the 3rd argument as zero?
The LPAE variant of cpu_v7_set_pte_ext takes the second argument as a
64-bit value:
r0 - ptep
r2, r3 - pteval
If we pass a third argument, that would go on the stack.
--
Catalin
^ permalink raw reply
* [PATCH v7 08/16] ARM: LPAE: Page table maintenance for the 3-level format
From: Catalin Marinas @ 2011-10-23 12:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20111023115635.GA17912@n2100.arm.linux.org.uk>
On 23 October 2011 13:56, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Wed, Aug 10, 2011 at 04:03:31PM +0100, Catalin Marinas wrote:
>> This patch modifies the pgd/pmd/pte manipulation functions to support
>> the 3-level page table format. Since there is no need for an 'ext'
>> argument to cpu_set_pte_ext(), this patch conditionally defines a
>> different prototype for this function when CONFIG_ARM_LPAE.
>
> This has a really large number of ifdefs. ?You've split the 2 and 3
> level page table stuff into two different header files already,
> conditionalized on CONFIG_ARM_LPAE, yet we still end up with lots of
> junk in the common header file conditionalized on that symbol. ?Can't
> we find a way to restructure pgtable.h to sort this out more cleanly?
I'll look into this.
> Do we really need to change the set_pte_ext() prototype as well - do
> we _really_ need ifdefs around its declaration, and every usage of it
> as well? ?Can't we just leave the 3rd argument as zero?
The LPAE variant of cpu_v7_set_pte_ext takes the second argument as a
64-bit value:
r0 - ptep
r2, r3 - pteval
If we pass a third argument, that would go on the stack.
--
Catalin
^ permalink raw reply
* Re: [Qemu-devel] [PATCH] gdbstub: Fix memory leak
From: Blue Swirl @ 2011-10-23 12:48 UTC (permalink / raw)
To: Stuart Brady; +Cc: qemu-devel
In-Reply-To: <20111020081000.GA5047@zubnet.me.uk>
On Thu, Oct 20, 2011 at 08:10, Stuart Brady <sdb@zubnet.me.uk> wrote:
> On Wed, Oct 19, 2011 at 01:59:04AM +0100, Stuart Brady wrote:
>> On Tue, Oct 18, 2011 at 06:18:11PM +0000, Blue Swirl wrote:
>>
>> > Cool. Please include the spatch with the commit message.
>>
>> Thanks, will do!
>
> Okay, submitted.
>
> This is the first time I've used git send-email, so let me know if I've
> missed anything.
The patches are OK, though when sending multiple patches, a cover
letter (--cover-letter) is appreciated.
^ permalink raw reply
* Re: lsusd - The Linux SUSpend Daemon
From: Rafael J. Wysocki @ 2011-10-23 12:48 UTC (permalink / raw)
To: NeilBrown; +Cc: Alan Stern, John Stultz, mark gross, Linux PM list, LKML
In-Reply-To: <20111023192147.49413485@notabene.brown>
On Sunday, October 23, 2011, NeilBrown wrote:
> On Fri, 21 Oct 2011 22:00:13 -0400 (EDT) Alan Stern
> <stern@rowland.harvard.edu> wrote:
>
> > On Sat, 22 Oct 2011, NeilBrown wrote:
> >
> > > > > It uses files in /var/run/suspend for all communication.
> > > >
> > > > I'm not so keen on using files for communication. At best, they are
> > > > rather awkward for two-way messaging. If you really want to use them,
> > > > then at least put them on a non-backed filesystem, like something under
> > > > /dev.
> > >
> > > Isn't /var/run a tmpfs filesystem? It should be.
> > > Surely /run is, so in the new world order the files should probably go
> > > there. But that is just a detail.
> >
> > On my Fedora-14 systems there is no /run, and /var/run is a regular
> > directory in a regular filesystem.
> >
> > > I like files... I particularly like 'flock' to block suspend. The
> > > rest.... whatever..
> > > With files, you only need a context switch when there is real communication.
> > > With sockets, every message sent must be read so there will be a context
> > > switch.
> > >
> > > Maybe we could do something with futexes...
> >
> > Not easily -- as far as I can tell, futexes enjoy relatively little
> > support. In any case, they provide the same service as a mutex, which
> > means you'd have to build a shared lock on top of them.
> >
> > > > > lsusd does not try to be event-loop based because:
> > > > > - /sys/power/wakeup_count is not pollable. This could probably be
> > > > > 'fixed' but I want code to work with today's kernel. It will probably
> > > >
> > > > Why does this matter?
> > >
> > > In my mind an event based program should never block. Every action should be
> > > non-blocking and only taken when 'poll' says it can.
> > > Reading /sys/power/wakeup_count can be read non-blocking, but you cannot find
> > > out when it is sensible to try to read it again. So it doesn't fit.
> >
> > There shouldn't be any trouble about making wakeup_count pollable. It
> > also would need to respect nonblocking reads, which it currently does
> > not do.
>
> Hmm.. you are correct. I wonder why I thought it did support non-blocking
> reads...
> I guess it was the code for handling an interrupted system call.
>
> I feel a bit uncomfortable with the idea of sysfs files that block but I
> don't think I can convincingly argue against it.
> A non-blocking flag could be passed in, but it would be a very messy change -
> lots of function call signatures changing needlessly: we would need a flag
> to the 'show' method ... or add a 'show_nonblock' method which would also be
> ugly.
>
>
> But I think there is a need to block - if there is an in-progress event then
> it must be possible to wait for it to complete as it may not be visible to
> userspace until then.
> We could easily enable 'poll' for wakeup_count and then make it always
> non-blocking, but I'm not really sure I want to require programs to use poll,
> only to allow them. And without using poll there is no way to wait.
>
> As wakeup_count really has to be single-access we could possibly fudge
> something by remembering the last value read (like we remember the last value
> written).
>
> - if the current count is different from the last value read, then return
> it even if there are in-progress events.
> - if the current count is the same as the last value read, then block until
> there are no in-progress events and return the new value.
> - enable sysfs_poll on wakeup_count by calling sysfs_notify_dirent at the
> end of wakeup_source_deactivated .... or calling something in
> kernel/power/main.c which calls that. However we would need to make
> sysfs_notify_dirent a lot lighter weight first. Maybe I should do that.
>
> Then a process that uses 'poll' could avoid reading wakeup_count except when
> it has changed, and then it won't block. And a process that doesn't use poll
> can block by simply reading twice - either explicitly or by going around a
> read then write and it fails
> loop a second time.
>
> I'm not sure I'm completely comfortable with that, but it is the best I could
> come up with.
Well, you're now considering doing more and more changes to the kernel
just to be able to implement something in user space to avoid making
some _other_ changes to the kernel. That doesn't sound right to me.
Thanks,
Rafael
^ permalink raw reply
* Re: [PATCH v2 1/7] clk: Add a generic clock infrastructure
From: Shawn Guo @ 2011-10-23 12:55 UTC (permalink / raw)
To: Mike Turquette
Cc: linux-kernel, linux-arm-kernel, jeremy.kerr, broonie, tglx,
linus.walleij, amit.kucheria, dsaxena, patches, linaro-dev, paul,
grant.likely, sboyd, skannan, magnus.damm, arnd.bergmann, linux,
eric.miao, richard.zhao
In-Reply-To: <1316730422-20027-2-git-send-email-mturquette@ti.com>
Hi Mike,
Some random comments/nits ...
On Thu, Sep 22, 2011 at 03:26:56PM -0700, Mike Turquette wrote:
> +struct clk *clk_register(const struct clk_hw_ops *ops, struct clk_hw *hw,
> + const char *name)
> +{
> + struct clk *clk;
> +
> + clk = kzalloc(sizeof(*clk), GFP_KERNEL);
> + if (!clk)
> + return NULL;
> +
> + INIT_HLIST_HEAD(&clk->children);
> + INIT_HLIST_NODE(&clk->child_node);
> +
The children and child_node are introduced in patch #2, and should not
be used in patch #1.
> + clk->name = name;
> + clk->ops = ops;
> + clk->hw = hw;
> + hw->clk = clk;
> +
> + /* Query the hardware for parent and initial rate */
> +
> + if (clk->ops->get_parent)
> + /* We don't to lock against prepare/enable here, as
> + * the clock is not yet accessible from anywhere */
/*
* Multiple line comments
*/
> + clk->parent = clk->ops->get_parent(clk->hw);
> +
> + if (clk->ops->recalc_rate)
> + clk->rate = clk->ops->recalc_rate(clk->hw);
> +
> +
One blank line is good enough.
> + return clk;
> +}
--
Regards,
Shawn
^ permalink raw reply
* [PATCH] DaVinci: only poll EPCPR on DM644x and DM355
From: Sergei Shtylyov @ 2011-10-23 12:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <B85A65D85D7EB246BE421B3FB0FBB5930328B2DF68@dbde02.ent.ti.com>
Hello.
On 23-10-2011 15:10, Nori, Sekhar wrote:
>> EPCPR register and PDCTL.EPCGOOD bit exist only on DaVinci DM644x and DM35x,
>> so do not try to poll EPCPR and set PDCTL.EPCGOOD on the other SoCs -- it would
>> lead to lock up if some power domain hasn't been powered up by this time (which
>> hasn't happened yet on any board, it seems).
>> Signed-off-by: Sergei Shtylyov<sshtylyov@ru.mvista.com>
> Firstly, sorry about feedback this late. I was involved in
> the bring-up of a new TI SoC which took much more of my
> time than I anticipated.
> So, I looked at power domain support for each of the 6
> DaVinci SoCs we support (don't have the specifications
But we support more than 6 SoCs... :-)
> for tnetv107x; and code does not have evidence of a separate
> DSP power domain).
> It looks like none of the SoCs except DM6446 actually support
> powering down the DSP power domain.
> DM6467, DM355, DM365 all have a single "Always ON" power
> domain. DM355 specification actually talks about EPCPR
> and EPCGOOD but that's probably due to copy paste from
> DM644x specification than anything else.
> OMAP-L137 and OMAP-L138 have additional power domains for DSP
> and Shared RAM, but do not support powering them down.
I haven't found such words in either OMAP-L137 or OMAP-L138 datasheets.
What they say is:
<<
- On PSC0 PD1/PD_DSP Domain: Controls the sleep state for DSP L1 and L2 Memories
- On PSC1 PD1/PD_SHRAM Domain: Controls the sleep state for the 128K Shared RAM
>>
Although "OMAP-L137 Application Processor System Reference Guide" indeed
said that powering off domain 1 is not supported.
Actually, I was able to power down DSP/shared RAM domains on DA830 (at
least the state transition completed); although the domains were on, at least
after U-Boot. That's how I checked that the code powering up these domains
actually locks up on this SoC.
> So, looks like the only SoC where PDSTAT might indicate a powered
> down domain is DM644x and existing code to looks alright for
> that SoC.
> At this time, it would be better to leave the code as-is and
> revisit it if/when a new SoC with programmable power domain
> support comes along.
At least on DA830 power domains appear to be programmable. So I'd still
like the patch to be applied (I could drop DM355 check though).
> Thanks,
> Sekhar
WBR, Sergei
^ permalink raw reply
* Re: [Qemu-devel] [PATCH 1/1] Introduce a new bus "ICC" to connect APIC
From: Blue Swirl @ 2011-10-23 12:40 UTC (permalink / raw)
To: pingfank; +Cc: aliguori, jan.kiszka, qemu-devel
In-Reply-To: <1318989353-5576-1-git-send-email-pingfank@linux.vnet.ibm.com>
On Wed, Oct 19, 2011 at 01:55, <pingfank@linux.vnet.ibm.com> wrote:
> From: Liu Ping Fan <pingfank@linux.vnet.ibm.com>
>
> Introduce a new structure CPUS as the controller of ICC (INTERRUPT
> CONTROLLER COMMUNICATIONS), and new bus "ICC" to hold APIC,instead
> of sysbus. So we can support APIC hot-plug feature.
Is this ICC bus or APIC hot plugging documented somewhere?
> Signed-off-by: liu ping fan <pingfank@linux.vnet.ibm.com>
> ---
> Makefile.target | 1 +
> hw/apic.c | 25 +++++++++++----
> hw/apic.h | 1 +
> hw/icc_bus.c | 91 +++++++++++++++++++++++++++++++++++++++++++++++++++++++
> hw/icc_bus.h | 56 ++++++++++++++++++++++++++++++++++
> hw/pc.c | 11 ++++--
> 6 files changed, 174 insertions(+), 11 deletions(-)
> create mode 100644 hw/icc_bus.c
> create mode 100644 hw/icc_bus.h
>
> diff --git a/Makefile.target b/Makefile.target
> index 9011f28..5607c6d 100644
> --- a/Makefile.target
> +++ b/Makefile.target
> @@ -241,6 +241,7 @@ obj-i386-$(CONFIG_KVM) += kvmclock.o
> obj-i386-$(CONFIG_SPICE) += qxl.o qxl-logger.o qxl-render.o
> obj-i386-y += testdev.o
> obj-i386-y += acpi.o acpi_piix4.o
> +obj-i386-y += icc_bus.o
>
> obj-i386-y += pcspk.o i8254.o
> obj-i386-$(CONFIG_KVM_PIT) += i8254-kvm.o
> diff --git a/hw/apic.c b/hw/apic.c
> index 69d6ac5..00d2297 100644
> --- a/hw/apic.c
> +++ b/hw/apic.c
> @@ -21,9 +21,10 @@
> #include "ioapic.h"
> #include "qemu-timer.h"
> #include "host-utils.h"
> -#include "sysbus.h"
> +#include "icc_bus.h"
> #include "trace.h"
> #include "kvm.h"
> +#include "exec-memory.h"
>
> /* APIC Local Vector Table */
> #define APIC_LVT_TIMER 0
> @@ -80,7 +81,7 @@
> typedef struct APICState APICState;
>
> struct APICState {
> - SysBusDevice busdev;
> + ICCBusDevice busdev;
> MemoryRegion io_memory;
> void *cpu_env;
> uint32_t apicbase;
> @@ -1104,9 +1105,20 @@ static const MemoryRegionOps apic_io_ops = {
> .endianness = DEVICE_NATIVE_ENDIAN,
> };
>
> -static int apic_init1(SysBusDevice *dev)
> +/**/
> +int apic_mmio_map(DeviceState *dev, target_phys_addr_t base)
> {
> - APICState *s = FROM_SYSBUS(APICState, dev);
> + APICState *s = DO_UPCAST(APICState, busdev.qdev, dev);
> +
> + memory_region_add_subregion(get_system_memory(),
> + base,
> + &s->io_memory);
> + return 0;
> +}
> +
> +static int apic_init1(ICCBusDevice *dev)
> +{
> + APICState *s = DO_UPCAST(APICState, busdev, dev);
> static int last_apic_idx;
>
> if (last_apic_idx >= MAX_APICS) {
> @@ -1114,7 +1126,6 @@ static int apic_init1(SysBusDevice *dev)
> }
> memory_region_init_io(&s->io_memory, &apic_io_ops, s, "apic",
> MSI_ADDR_SIZE);
> - sysbus_init_mmio_region(dev, &s->io_memory);
>
> s->timer = qemu_new_timer_ns(vm_clock, apic_timer, s);
> s->idx = last_apic_idx++;
> @@ -1122,7 +1133,7 @@ static int apic_init1(SysBusDevice *dev)
> return 0;
> }
>
> -static SysBusDeviceInfo apic_info = {
> +static ICCBusDeviceInfo apic_info = {
> .init = apic_init1,
> .qdev.name = "apic",
> .qdev.size = sizeof(APICState),
> @@ -1138,7 +1149,7 @@ static SysBusDeviceInfo apic_info = {
>
> static void apic_register_devices(void)
> {
> - sysbus_register_withprop(&apic_info);
> + iccbus_register_devinfo(&apic_info);
> }
>
> device_init(apic_register_devices)
> diff --git a/hw/apic.h b/hw/apic.h
> index c857d52..e2c0af5 100644
> --- a/hw/apic.h
> +++ b/hw/apic.h
> @@ -20,6 +20,7 @@ void cpu_set_apic_tpr(DeviceState *s, uint8_t val);
> uint8_t cpu_get_apic_tpr(DeviceState *s);
> void apic_init_reset(DeviceState *s);
> void apic_sipi(DeviceState *s);
> +int apic_mmio_map(DeviceState *dev, target_phys_addr_t base);
>
> /* pc.c */
> int cpu_is_bsp(CPUState *env);
> diff --git a/hw/icc_bus.c b/hw/icc_bus.c
> new file mode 100644
> index 0000000..61a408e
> --- /dev/null
> +++ b/hw/icc_bus.c
> @@ -0,0 +1,91 @@
> +/* icc_bus.c
> + * emulate x86 ICC(INTERRUPT CONTROLLER COMMUNICATIONS) bus
> + *
> + * This library is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU Lesser General Public
> + * License as published by the Free Software Foundation; either
> + * version 2 of the License, or (at your option) any later version.
> + *
> + * This library is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
> + * Lesser General Public License for more details.
> + *
> + * You should have received a copy of the GNU Lesser General Public
> + * License along with this library; if not, see <http://www.gnu.org/licenses/>
> + */
> +#include "icc_bus.h"
> +
> +static CPUS *dummy_cpus;
> +
> +
> +static ICCBusInfo icc_bus_info = {
> + .qinfo.name = "icc",
> + .qinfo.size = sizeof(ICCBus),
> + .qinfo.props = (Property[]) {
> + DEFINE_PROP_END_OF_LIST(),
> + }
> +};
> +
> +
> +
> +static int iccbus_device_init(DeviceState *dev, DeviceInfo *base)
> +{
> + ICCBusDeviceInfo *info = container_of(base, ICCBusDeviceInfo, qdev);
> + ICCBusDevice *idev = DO_UPCAST(ICCBusDevice, qdev, dev);
> +
> + return info->init(idev);
> +}
> +
> +void iccbus_register_devinfo(ICCBusDeviceInfo *info)
> +{
> + info->qdev.init = iccbus_device_init;
> + info->qdev.bus_info = &icc_bus_info.qinfo;
> + assert(info->qdev.size >= sizeof(ICCBusDevice));
> + qdev_register(&info->qdev);
> +}
> +
> +
> +
> +BusState *get_icc_bus(void)
> +{
> + return &dummy_cpus->icc_bus->qbus;
> +}
> +
> +static void cpus_reset(DeviceState *d)
> +{
> +}
> +
> +/*Must be called before vcpu's creation*/
> +static int cpus_init(SysBusDevice *dev)
> +{
> + CPUS *cpus = DO_UPCAST(CPUS, sysdev, dev);
> + BusState *b = qbus_create(&icc_bus_info.qinfo,
> + &dummy_cpus->sysdev.qdev,
> + "icc");
> + if (b == NULL) {
> + return -1;
> + }
> + b->allow_hotplug = 1; /* Yes, we can */
> + cpus->icc_bus = DO_UPCAST(ICCBus, qbus, b);
> + dummy_cpus = cpus;
> + return 0;
> +
> +}
> +
> +
> +static SysBusDeviceInfo cpus_info = {
> + .init = cpus_init,
> + .qdev.name = "cpus",
> + .qdev.size = sizeof(CPUS),
> + /*.qdev.vmsd = &vmstate_apic,*/
> + .qdev.reset = cpus_reset,
> + .qdev.no_user = 1,
> +};
> +
> +static void cpus_register_devices(void)
> +{
> + sysbus_register_withprop(&cpus_info);
> +}
> +
> +device_init(cpus_register_devices)
> diff --git a/hw/icc_bus.h b/hw/icc_bus.h
> new file mode 100644
> index 0000000..64ac153
> --- /dev/null
> +++ b/hw/icc_bus.h
> @@ -0,0 +1,56 @@
> +/* ICCBus.h
> + * emulate x86 ICC(INTERRUPT CONTROLLER COMMUNICATIONS) bus
> + *
> + * This library is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU Lesser General Public
> + * License as published by the Free Software Foundation; either
> + * version 2 of the License, or (at your option) any later version.
> + *
> + * This library is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
> + * Lesser General Public License for more details.
> + *
> + * You should have received a copy of the GNU Lesser General Public
> + * License along with this library; if not, see <http://www.gnu.org/licenses/>
> + */
> +#ifndef QEMU_ICC_H
> +#define QEMU_ICC_H
> +
> +#include "qdev.h"
> +#include "sysbus.h"
> +
> +typedef struct CPUS CPUS;
> +typedef struct ICCBus ICCBus;
> +typedef struct ICCBusInfo ICCBusInfo;
> +typedef struct ICCBusDevice ICCBusDevice;
> +typedef struct ICCBusDeviceInfo ICCBusDeviceInfo;
> +
> +struct CPUS {
> + SysBusDevice sysdev;
> + ICCBus *icc_bus;
> +};
> +
> +struct ICCBus {
> + BusState qbus;
> +};
> +
> +struct ICCBusInfo {
> + BusInfo qinfo;
> +};
> +struct ICCBusDevice {
> + DeviceState qdev;
> +};
> +
> +typedef int (*iccbus_initfn)(ICCBusDevice *dev);
> +
> +struct ICCBusDeviceInfo {
> + DeviceInfo qdev;
> + iccbus_initfn init;
> +};
> +
> +
> +void iccbus_register_devinfo(ICCBusDeviceInfo *info);
> +BusState *get_icc_bus(void);
> +
> +#endif
> diff --git a/hw/pc.c b/hw/pc.c
> index 6b3662e..78b7826 100644
> --- a/hw/pc.c
> +++ b/hw/pc.c
> @@ -24,6 +24,7 @@
> #include "hw.h"
> #include "pc.h"
> #include "apic.h"
> +#include "icc_bus.h"
> #include "fdc.h"
> #include "ide.h"
> #include "pci.h"
> @@ -875,21 +876,21 @@ DeviceState *cpu_get_current_apic(void)
> static DeviceState *apic_init(void *env, uint8_t apic_id)
> {
> DeviceState *dev;
> - SysBusDevice *d;
> + BusState *b;
> static int apic_mapped;
>
> - dev = qdev_create(NULL, "apic");
> + b = get_icc_bus();
> + dev = qdev_create(b, "apic");
> qdev_prop_set_uint8(dev, "id", apic_id);
> qdev_prop_set_ptr(dev, "cpu_env", env);
> qdev_init_nofail(dev);
> - d = sysbus_from_qdev(dev);
>
> /* XXX: mapping more APICs at the same memory location */
> if (apic_mapped == 0) {
> /* NOTE: the APIC is directly connected to the CPU - it is not
> on the global memory bus. */
> /* XXX: what if the base changes? */
> - sysbus_mmio_map(d, 0, MSI_ADDR_BASE);
> + apic_mmio_map(dev, MSI_ADDR_BASE);
> apic_mapped = 1;
> }
>
> @@ -955,6 +956,8 @@ CPUState *pc_new_cpu(const char *cpu_model)
> void pc_cpus_init(const char *cpu_model)
> {
> int i;
> + DeviceState *d = qdev_create(NULL, "cpus");
> + qdev_init_nofail(d);
This makes the 'cpus' separate device from CPUs which only makes sense
now that LAPICs are in a way shared.
I think the final model should be that PC board should create the CPUs
first, specifying also if ICC should be created (no for machines
without APIC, ISA or i386). Then each CPU should create a per-CPU ICC
bus as needed. Near APIC init, the CPUs are queried if an ICC bus
exists, if yes, an APIC will be attached to this bus (for each CPU).
If the function get_icc_bus() is still needed, it should grab the bus
from CPUState. The APIC base can be changed per CPU.
I'm not sure that a full bus is needed for now, even if it could match
real HW better, since the memory API already provides the separation
needed. Perhaps this would be needed later to make IRQs per-CPU also,
or to put IOAPIC also to the bus?
>
> /* init CPUs */
> for(i = 0; i < smp_cpus; i++) {
> --
> 1.7.4.4
>
>
>
^ permalink raw reply
* [Buildroot] [RFC] Slides "Using Buildroot for real projects"
From: Baruch Siach @ 2011-10-23 12:37 UTC (permalink / raw)
To: buildroot
In-Reply-To: <20111021154303.43f98ccd@skate>
Hi Thomas,
On Fri, Oct 21, 2011 at 03:43:03PM +0200, Thomas Petazzoni wrote:
> Le Mon, 17 Oct 2011 18:47:18 +0200,
> Thomas Petazzoni <thomas.petazzoni@free-electrons.com> a ?crit :
>
> > The current (unfinished) status of my slides is visible at:
> > http://free-electrons.com/~thomas/pub/using-buildroot-real-project.pdf
>
> First of all, I'd like to thank Peter, Baruch, Thomas, Arnout and Will
> who gave some useful comments about my slides.
>
> At the same URL above, I have published a new version, which hopefully
> addresses your comments, and also adds some more slides on various
> topics. The slides should now, at least in terms of contents, represent
> what I had in mind for this talk.
>
> Now, if you're still willing to spend some time on this, I'd like to
> have comments on:
> * remaining english typos, wording improvements, etc.
> * suggestions of additional contents/topics if there is something I
> missed. Like if you use best practices that aren't described in
> those slides.
>
> Thanks again!
Two of my earlier comments still stand.
1. Slide 23: missing -e in the 'echo' command
$ echo "/dev/mtdblock7\t\t/applog\tjffs2\tdefaults\t\t0\t0"
/dev/mtdblock7\t\t/applog\tjffs2\tdefaults\t\t0\t0
$ echo -e "/dev/mtdblock7\t\t/applog\tjffs2\tdefaults\t\t0\t0"
/dev/mtdblock7 /applog jffs2 defaults 0 0
2. Slides 24-27: header should be "Project-specific packages (x/5)", instead
of "... (x/4)". (Can't TeX do this automatically somehow?)
baruch
--
~. .~ Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
- baruch at tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -
^ permalink raw reply
* [RFC/PATCH 2/2] sparse: Use native sizes for data types
From: penberg @ 2011-10-23 12:37 UTC (permalink / raw)
To: linux-sparse; +Cc: Pekka Enberg, Christopher Li, Jeff Garzik, Linus Torvalds
In-Reply-To: <1319373420-8967-1-git-send-email-penberg@cs.helsinki.fi>
From: Pekka Enberg <penberg@kernel.org>
This patch is needed to fix the sparsec LLVM backend data type sizes.
Cc: Christopher Li <sparse@chrisli.org>
Cc: Jeff Garzik <jgarzik@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Pekka Enberg <penberg@kernel.org>
---
target.c | 10 +++++-----
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/target.c b/target.c
index 6a535bc..009002f 100644
--- a/target.c
+++ b/target.c
@@ -17,9 +17,9 @@ int max_alignment = 16;
int bits_in_bool = 8;
int bits_in_char = 8;
int bits_in_short = 16;
-int bits_in_int = 32;
-int bits_in_long = 32;
-int bits_in_longlong = 64;
+int bits_in_int = sizeof(int) * 8;
+int bits_in_long = sizeof(long) * 8;
+int bits_in_longlong = sizeof(long long) * 8;
int bits_in_longlonglong = 128;
int max_int_alignment = 4;
@@ -36,8 +36,8 @@ int max_fp_alignment = 8;
/*
* Pointer data type
*/
-int bits_in_pointer = 32;
-int pointer_alignment = 4;
+int bits_in_pointer = sizeof(void *) * 8;
+int pointer_alignment = sizeof(void *);
/*
* Enum data types
--
1.7.6.4
^ permalink raw reply related
* [RFC/PATCH 1/2] sparse: Fix including glibc headers on x86-64
From: penberg @ 2011-10-23 12:36 UTC (permalink / raw)
To: linux-sparse; +Cc: Pekka Enberg, Christopher Li, Jeff Garzik, Linus Torvalds
From: Pekka Enberg <penberg@kernel.org>
Sparse treats code as 32-bit which causes problems for userspace projects on
x86-64 Fedora if you don't have the 32-bit glibc compat package installed
("glib-devel.i686"):
$ ./sparse allocate.c
/usr/include/gnu/stubs.h:7:12: error: unable to open 'gnu/stubs-32.h'
Fix the issue by defining relevant macros on 64-bit.
Cc: Christopher Li <sparse@chrisli.org>
Cc: Jeff Garzik <jgarzik@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Pekka Enberg <penberg@kernel.org>
---
lib.c | 6 ++++++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/lib.c b/lib.c
index 396e9f1..f372296 100644
--- a/lib.c
+++ b/lib.c
@@ -827,6 +827,12 @@ void create_builtin_stream(void)
add_pre_buffer("#weak_define __LONG_MAX__ " STRINGIFY(__LONG_MAX__) "\n");
add_pre_buffer("#weak_define __LONG_LONG_MAX__ " STRINGIFY(__LONG_LONG_MAX__) "\n");
add_pre_buffer("#weak_define __WCHAR_MAX__ " STRINGIFY(__WCHAR_MAX__) "\n");
+
+#ifdef __x86_64
+ add_pre_buffer("#weak_define x86_64 1\n");
+ add_pre_buffer("#weak_define __x86_64 1\n");
+ add_pre_buffer("#weak_define __x86_64__ 1\n");
+#endif
}
static struct symbol_list *sparse_tokenstream(struct token *token)
--
1.7.6.4
^ permalink raw reply related
* Re: [PATCH 1/3] drm/i915: Ivybridge still has fences!
From: Chris Wilson @ 2011-10-23 12:35 UTC (permalink / raw)
To: Daniel Vetter, Keith Packard; +Cc: Daniel Vetter, intel-gfx, stable
In-Reply-To: <20111023120907.GG2953@phenom.ffwll.local>
On Sun, 23 Oct 2011 14:09:07 +0200, Daniel Vetter <daniel@ffwll.ch> wrote:
> Keith, can take a look at patches 1-2 and consider merging them for 3.2?
Those two are
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
^ permalink raw reply
* Redirecting ports with netfilter: unexpected varying results possibly correlated with NAT
From: Ronald @ 2011-10-23 12:29 UTC (permalink / raw)
To: netfilter
(Please cc me as I'm not subscribed to this list.)
Hello netfilter enthousiasts,
I'm seeing a problem which is highly probably related to netfilter. I
asked around on several forums, but have never received an answer. So
therefore, my last option is this mailing list. Hence this mail.
After a rather lengthy struggle with the IPSEC stack, I managed to get
my IPSEC VPN working. The next step was to properly secure it with
netfilter. However, when trying to use the setup from university,
something went wrong. The cause is the fact that I try to use port
redirection to prevent charon from listening on the default udp port
500. Charon is the IPSEC IKEv2 daemon. As far as I'm aware, there is
no way of configuring the listening port for charon, hence I tried to
use netfilter for this. So we have this:
On the client:
iptables -t nat -A OUTPUT -p udp --dport 500 -j DNAT --to-destination
:56301 (--persistent)
On the server:
iptables -t nat -A PREROUTING -p udp --dport 56301 -m addrtype
--dst-type LOCAL -j REDIRECT --to-port 500
or, as a viable alternative (yet having the exact same failing outcome):
iptables -t nat -A PREROUTING -p udp --dport 56301 -m addrtype
--dst-type LOCAL -j DNAT --to-destination :500 (--persistent)
When using tcpdump, it seems to fail when the server sends a respons
back to the cliënt (my external telfort ip is obfuscated):
For clarity:
Server --- Home Gateway --- --- --- The Internet --- --- ---
University Gateway --- Client
- Client: 130.37.154.14 is the local ip assigned to wlan0 when I'm at
the university, which is also my external ip
- Home Gateway: 144-144-144-144.ip.telfort.nl:56301 is the external ip
of my home network with port 56301 redirecting to Server:
10.1.9.253:56301
Client:
17:05:48.523138 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto
UDP (17), length 788) 130.37.154.14.isakmp >
144-144-144-144.ip.telfort.nl.56301: [|isakmp]
17:05:50.523711 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto
UDP (17), length 788) 130.37.154.14.isakmp >
144-144-144-144.ip.telfort.nl.56301: [|isakmp]
17:05:52.524039 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto
UDP (17), length 788) 130.37.154.14.isakmp >
144-144-144-144.ip.telfort.nl.56301: [|isakmp]
17:05:54.524365 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto
UDP (17), length 788) 130.37.154.14.isakmp >
144-144-144-144.ip.telfort.nl.56301: [|isakmp]
Server:
17:05:44.794566 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto
UDP (17), length 29) 10.1.9.253.56301 > 130.37.154.14.isakmp: [udp sum
ok] [|isakmp]
17:05:44.817648 IP (tos 0x0, ttl 57, id 0, offset 0, flags [DF], proto
UDP (17), length 788) 130.37.154.14.isakmp > 10.1.9.253.56301:
[|isakmp]
17:05:44.819641 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto
UDP (17), length 493) 10.1.9.253.56301 > 130.37.154.14.isakmp:
[|isakmp]
17:05:46.925299 IP (tos 0x0, ttl 57, id 0, offset 0, flags [DF], proto
UDP (17), length 788) 130.37.154.14.isakmp > 10.1.9.253.56301:
[|isakmp]
17:05:46.926450 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto
UDP (17), length 493) 10.1.9.253.56301 > 130.37.154.14.isakmp:
[|isakmp]
It seems that the responses from the server are dropped somewhere. The
client never receives them. And so, these lines go on forever. I have
raw packet dumps ready if anyone would like to see those.
However, things get even more confusing. It turns out, that if:
- I connect from university using wireless, the IP assigned to my
wireless interface (wlan0) equals the ip reported on
http://whatismyipaddress.com/
- I connect from university using a lan, the IP assigned to my
ethernet interface (eth1) does not equal the ip reported on
http://whatismyipaddress.com/
That means that wireless is just forwarded, while ethernet is NAT-ed,
by the University Gateway. Is this conclusion correct?
This seems relevant because if:
- I connect from university using wireless (apparently without NAT)
and applying port redirection: connection fails
- I connect from university using wireless (apparently without NAT)
and not applying port redirection: connection succeeds
- I connect from university using cable (apparently with NAT) and
applying port redirection: connection succeeds
- I connect from university using cable (apparently with NAT) and not
applying port redirection: connection succeeds
Conclusion: Using wireless, which is not NAT-ed, port redirection
seems to fail. Responses to the client are dropped somewhere along the
way.
Why? I have absolutely no clue of what causes these symptoms or why
this does not work. Does anyone here have an idea?
Thanks, Ronald
^ permalink raw reply
* Re: Linux 3.0.7 now on kernel.org
From: Greg KH @ 2011-10-23 12:29 UTC (permalink / raw)
To: Piotr Hosowicz; +Cc: linux-kernel, H. Peter Anvin, John Hawley, Linus Torvalds
In-Reply-To: <4EA40795.3070603@example.com>
On Sun, Oct 23, 2011 at 02:24:53PM +0200, Piotr Hosowicz wrote:
> On 23.10.2011 10:31, Greg KH wrote:
>
> >You will note that the files are signed with my new kernel release
> >signing key, and that the .tar file is signed, and then compressed, so
> >there is not signatures for the individual compressed files.
>
> And why is that? It's less handy.
I'll let hpa answer that one, he changed it for a good reason that I
can't recall at the moment :)
hpa?
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH] m68k: Merge mmu and non-mmu versions of sys_call_table
From: Geert Uytterhoeven @ 2011-10-23 12:20 UTC (permalink / raw)
To: Andreas Schwab
Cc: Arnd Bergmann, Linux/m68k, Greg Ungerer, Linux Kernel Development,
uClinux list
In-Reply-To: <m2ty70ghk9.fsf@linux-m68k.org>
On Sun, Oct 23, 2011 at 11:53, Andreas Schwab <schwab@linux-m68k.org> wrote:
> Geert Uytterhoeven <geert@linux-m68k.org> writes:
>
>> From 5739b340b334de21c6da4f65d5194957662a6dd0 Mon Sep 17 00:00:00 2001
>> From: Geert Uytterhoeven <geert@linux-m68k.org>
>> Date: Thu, 5 May 2011 20:33:02 +0200
>> Subject: [PATCH] m68k: unistd - Comment out definitions for unimplemented syscalls
>
> This is not a good idea at least for the syscalls referenced by glibc.
> It means that a glibc compiled against this <asm/unistd.h> will lose the
> ability to call those syscalls even if the running kernel happens to
> implement them.
But is any of them likely to be ever implemented on m68k?
Perhaps AFS, vserver and {get,put}pmsg()?
All others seem to be old, obsolete, or i386-only.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [Qemu-devel] [PATCH 00/26] AREG0 conversion
From: Blue Swirl @ 2011-10-23 12:14 UTC (permalink / raw)
To: Richard Henderson; +Cc: qemu-devel
In-Reply-To: <4E9F0825.2020200@twiddle.net>
On Wed, Oct 19, 2011 at 17:25, Richard Henderson <rth@twiddle.net> wrote:
> On 10/09/2011 12:20 PM, Blue Swirl wrote:
>>> I didn't bother to attach the patches, if someone wants to try, the
>>> patch set can be found here:
>>> git://repo.or.cz/qemu/blueswirl.git
>>> http://repo.or.cz/r/qemu/blueswirl.git
>>
>> I pushed the patch set to repo.or.cz so if someone wants to comment or
>> test, they are there.
>>
>> It's mostly the same stuff as before, though I split int_helper.c to
>> int32_helper.c and int64_helper.c since they have nothing in common
>> and extracted TCG iargs/oargs changes.
>>
>>> Blue Swirl (26):
>>> Document softmmu templates
>>> softmmu_header: pass CPUState to tlb_fill
>>> Move GETPC from dyngen-exec.h to exec-all.h
>
> I don't see these three in the repo.
Because I applied them earlier...
>>> Sparc: fix coding style
>
> Reviewed-by: Richard Henderson <rth@twiddle.net>
>
>>> Sparc: split helper.c
>
> Reviewed-by: Richard Henderson <rth@twiddle.net>
>
>>> Sparc: move trivial functions from op_helper.c
>
> Reviewed-by: Richard Henderson <rth@twiddle.net>
>
>>> Sparc: avoid AREG0 for raise_exception and helper_debug
>
> Reviewed-by: Richard Henderson <rth@twiddle.net>
>
>>> Sparc: fix coding style
>
> Reviewed-by: Richard Henderson <rth@twiddle.net>
>
>>> Sparc: split FPU and VIS op helpers
>
> Reviewed-by: Richard Henderson <rth@twiddle.net>
>
>>> Sparc: avoid AREG0 for float and VIS ops
>
> Reviewed-by: Richard Henderson <rth@twiddle.net>
>
>>> Sparc: split lazy condition code handling op helpers
>
> Reviewed-by: Richard Henderson <rth@twiddle.net>
>
>>> Sparc: avoid AREG0 for lazy condition code helpers
>
> Reviewed-by: Richard Henderson <rth@twiddle.net>
>
>>> Sparc: split CWP and PSTATE op helpers
>
> Reviewed-by: Richard Henderson <rth@twiddle.net>
>
>>> Sparc: avoid AREG0 for CWP and PSTATE helpers
>
> Reviewed-by: Richard Henderson <rth@twiddle.net>
> An especially nice cleanup too, avoiding all of the saved_env frobbing.
>
>>> Sparc: avoid AREG0 for softint op helpers and Leon cache control
>
> This one loses do_modify_softint in the move. Which gets re-instated
> in your following "convert int_helper to trace framework" patch. But
> in the meantime the series is non-bisectable.
Nice catch, will fix. I think I'll apply the patches before this one
now to shorten the series a bit.
>>> Sparc: avoid AREG0 for division op helpers
>
> Reviewed-by: Richard Henderson <rth@twiddle.net>
>
>>> Sparc: fix coding style in helper.c
>
> Reviewed-by: Richard Henderson <rth@twiddle.net>
>
>>> Sparc: split MMU helpers
>
> Reviewed-by: Richard Henderson <rth@twiddle.net>
>
>>> Sparc: convert mmu_helper to trace framework
>
> Reviewed-by: Richard Henderson <rth@twiddle.net>
>
>>> Sparc: convert int_helper to trace framework
>
> Reviewed-by: Richard Henderson <rth@twiddle.net>
>
>>> Sparc: convert win_helper to trace framework
>
> Reviewed-by: Richard Henderson <rth@twiddle.net>
>
>>> Sparc: split load and store op helpers
>
> Reviewed-by: Richard Henderson <rth@twiddle.net>
>
>>> TCG: add 5 arg helpers to def-helper.h
>
> Reviewed-by: Richard Henderson <rth@twiddle.net>
>
>>> Sparc: avoid AREG0 for memory access helpers
>
>> +#define WRAP_LD(rettype, fn) \
>> + rettype cpu_ ## fn (CPUState *env1, target_ulong addr) \
>> + { \
>> + CPUState *saved_env; \
>> + rettype ret; \
>> + \
>> + saved_env = env; \
>> + env = env1; \
>> + ret = fn(addr); \
>> + env = saved_env; \
>> + return ret; \
>> + }
>
> I don't think this actually works in the fault case. In particular GETPC
> will return an incorrect address. OTOH, I suppose we already have this
> problem from the other ldst helpers, e.g. ld_asi, which is where these new
> routines are going to be called from. So this doesn't really change the
> state of affairs much. I have no good ideas for solving this problem.
OK, maybe it's better to leave this and the 5 arg patch from 1.0.
> Reviewed-by: Richard Henderson <rth@twiddle.net>
>
>>> softmmu templates: optionally pass CPUState to memory access
>>> functions
>>> Sparc: avoid AREG0 wrappers for memory access helpers
>
> Both look ok. I'm certainly not fond of the intermediate state. If we
> convert target-sparc and tcg-i386, we should convert all of them, and
> not leave that intermediate state for long.
>
> Something that's clearly not going to happen for the 1.0 release.
Fully agree. Thanks for the review.
^ permalink raw reply
* LE APIs on other platforms
From: Mat Martineau @ 2011-10-23 12:12 UTC (permalink / raw)
To: linux-bluetooth
For those of you asking about iOS LE APIs at the Bluetooth summit,
here is the link to Apple's LE developer documentation:
http://developer.apple.com/library/ios/#documentation/CoreBluetooth/Reference/CoreBluetooth_Framework/_index.html
--
Mat Martineau
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum
^ 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.