* Re: [PATCH] security/selinux: fix /proc/sys/ labeling
From: Stephen Smalley @ 2011-02-01 15:59 UTC (permalink / raw)
To: Lucian Adrian Grijincu
Cc: James Morris, Eric Paris, Nick Piggin, Eric W. Biederman,
linux-kernel, linux-security-module
In-Reply-To: <AANLkTimiV_2SAwXuH-SjGav5XJixN=SnjrPrtFRRQF05@mail.gmail.com>
On Tue, 2011-02-01 at 17:53 +0200, Lucian Adrian Grijincu wrote:
> On Tue, Feb 1, 2011 at 5:02 PM, Stephen Smalley <sds@tycho.nsa.gov> wrote:
> > Is this patch really from Eric or just derived from an earlier patch by him?
>
>
> No, sorry for the confusion.
> I seem to have triggered a git send-email bug.
>
> >> Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
> >
> > And did Eric truly sign off on this patch or just on an earlier one?
>
>
> Just the earlier one. I added his sign-off because of this paragraph
> in SubmittingPatches:
> | The Signed-off-by: tag indicates that the signer was involved in the
> | development of the patch, or that he/she was in the patch's delivery path.
>
> >
> >> diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c
> >> index e276eb4..7c5dfb1 100644
> >> --- a/security/selinux/hooks.c
> >> +++ b/security/selinux/hooks.c
> >> @@ -1317,9 +1311,9 @@ static int inode_doinit_with_dentry(struct inode *inode, struct dentry *opt_dent
> >>
> >> if ((sbsec->flags & SE_SBPROC) && !S_ISLNK(inode->i_mode)) {
> >> struct proc_inode *proci = PROC_I(inode);
> >> - if (proci->pde) {
> >> + if (opt_dentry && (proci->pde || proci->sysctl)) {
> >> isec->sclass = inode_mode_to_security_class(inode->i_mode);
> >> - rc = selinux_proc_get_sid(proci->pde,
> >> + rc = selinux_proc_get_sid(opt_dentry,
> >> isec->sclass,
> >> &sid);
> >> if (rc)
> >
> > It would be nice if we could eliminate the last remaining piece of proc
> > internal knowledge from this code - why do we need the proci->pde ||
> > proci->sysctl test here? What changes without it?
>
>
> Without we label all nodes in /proc/ through selinux_proc_get_sid.
>
> /proc/1/limits should not get it's sid from here, but from
> security_task_to_inode -> selinux_task_to_inode.
>
> Without the check we send "/1/limits" to selinux_proc_get_sid, which
> strips off "/1" leaving "/limits". This will be labeled with "proc_t"
> IIRC.
Are you sure? Those inodes should be labeled by proc_pid_make_inode()
-> security_task_to_inode() -> selinux_task_to_inode(), which will set
the inode SID to match the associated task SID, and set the
isec->initialized flag. Then when inode_doinit_with_dentry gets called
later, it should bail immediately due to isec->initialized already being
set.
--
Stephen Smalley
National Security Agency
^ permalink raw reply
* [PATCH] netfilter: ipset: remove unnecessary includes
From: Patrick McHardy @ 2011-02-01 15:59 UTC (permalink / raw)
To: Jozsef Kadlecsik; +Cc: netfilter-devel@vger.kernel.org
[-- Attachment #1: Type: text/plain, Size: 0 bytes --]
[-- Attachment #2: 02.diff --]
[-- Type: text/plain, Size: 4790 bytes --]
commit 582e1fc85ca3727abd4e99109a267c514ea5c260
Author: Patrick McHardy <kaber@trash.net>
Date: Tue Feb 1 16:57:37 2011 +0100
netfilter: ipset: remove unnecessary includes
None of the set types need uaccess.h since this is handled centrally
in ip_set_core. Most set types additionally don't need bitops.h and
spinlock.h since they use neither. tcp.h is only needed by those
using before(), udp.h is not needed at all.
Signed-off-by: Patrick McHardy <kaber@trash.net>
diff --git a/net/netfilter/ipset/ip_set_bitmap_ip.c b/net/netfilter/ipset/ip_set_bitmap_ip.c
index 0474400..bca9699 100644
--- a/net/netfilter/ipset/ip_set_bitmap_ip.c
+++ b/net/netfilter/ipset/ip_set_bitmap_ip.c
@@ -13,7 +13,6 @@
#include <linux/ip.h>
#include <linux/skbuff.h>
#include <linux/errno.h>
-#include <linux/uaccess.h>
#include <linux/bitops.h>
#include <linux/spinlock.h>
#include <linux/netlink.h>
diff --git a/net/netfilter/ipset/ip_set_bitmap_ipmac.c b/net/netfilter/ipset/ip_set_bitmap_ipmac.c
index d826332..5e79017 100644
--- a/net/netfilter/ipset/ip_set_bitmap_ipmac.c
+++ b/net/netfilter/ipset/ip_set_bitmap_ipmac.c
@@ -15,9 +15,6 @@
#include <linux/etherdevice.h>
#include <linux/skbuff.h>
#include <linux/errno.h>
-#include <linux/uaccess.h>
-#include <linux/bitops.h>
-#include <linux/spinlock.h>
#include <linux/if_ether.h>
#include <linux/netlink.h>
#include <linux/jiffies.h>
diff --git a/net/netfilter/ipset/ip_set_bitmap_port.c b/net/netfilter/ipset/ip_set_bitmap_port.c
index 92074bb..165f09b 100644
--- a/net/netfilter/ipset/ip_set_bitmap_port.c
+++ b/net/netfilter/ipset/ip_set_bitmap_port.c
@@ -9,13 +9,8 @@
#include <linux/module.h>
#include <linux/ip.h>
-#include <linux/tcp.h>
-#include <linux/udp.h>
#include <linux/skbuff.h>
#include <linux/errno.h>
-#include <linux/uaccess.h>
-#include <linux/bitops.h>
-#include <linux/spinlock.h>
#include <linux/netlink.h>
#include <linux/jiffies.h>
#include <linux/timer.h>
diff --git a/net/netfilter/ipset/ip_set_hash_ip.c b/net/netfilter/ipset/ip_set_hash_ip.c
index 53964bc..43bcce2 100644
--- a/net/netfilter/ipset/ip_set_hash_ip.c
+++ b/net/netfilter/ipset/ip_set_hash_ip.c
@@ -12,9 +12,6 @@
#include <linux/ip.h>
#include <linux/skbuff.h>
#include <linux/errno.h>
-#include <linux/uaccess.h>
-#include <linux/bitops.h>
-#include <linux/spinlock.h>
#include <linux/random.h>
#include <net/ip.h>
#include <net/ipv6.h>
diff --git a/net/netfilter/ipset/ip_set_hash_ipport.c b/net/netfilter/ipset/ip_set_hash_ipport.c
index d9b1928..adbe787 100644
--- a/net/netfilter/ipset/ip_set_hash_ipport.c
+++ b/net/netfilter/ipset/ip_set_hash_ipport.c
@@ -12,9 +12,6 @@
#include <linux/ip.h>
#include <linux/skbuff.h>
#include <linux/errno.h>
-#include <linux/uaccess.h>
-#include <linux/bitops.h>
-#include <linux/spinlock.h>
#include <linux/random.h>
#include <net/ip.h>
#include <net/ipv6.h>
diff --git a/net/netfilter/ipset/ip_set_hash_ipportip.c b/net/netfilter/ipset/ip_set_hash_ipportip.c
index 80dae9d..22e23ab 100644
--- a/net/netfilter/ipset/ip_set_hash_ipportip.c
+++ b/net/netfilter/ipset/ip_set_hash_ipportip.c
@@ -12,9 +12,6 @@
#include <linux/ip.h>
#include <linux/skbuff.h>
#include <linux/errno.h>
-#include <linux/uaccess.h>
-#include <linux/bitops.h>
-#include <linux/spinlock.h>
#include <linux/random.h>
#include <net/ip.h>
#include <net/ipv6.h>
diff --git a/net/netfilter/ipset/ip_set_hash_ipportnet.c b/net/netfilter/ipset/ip_set_hash_ipportnet.c
index 8eacd8a..6033e8b 100644
--- a/net/netfilter/ipset/ip_set_hash_ipportnet.c
+++ b/net/netfilter/ipset/ip_set_hash_ipportnet.c
@@ -12,9 +12,6 @@
#include <linux/ip.h>
#include <linux/skbuff.h>
#include <linux/errno.h>
-#include <asm/uaccess.h>
-#include <asm/bitops.h>
-#include <linux/spinlock.h>
#include <linux/random.h>
#include <net/ip.h>
#include <net/ipv6.h>
diff --git a/net/netfilter/ipset/ip_set_hash_net.c b/net/netfilter/ipset/ip_set_hash_net.c
index fb0e6a6..c4db202 100644
--- a/net/netfilter/ipset/ip_set_hash_net.c
+++ b/net/netfilter/ipset/ip_set_hash_net.c
@@ -12,9 +12,6 @@
#include <linux/ip.h>
#include <linux/skbuff.h>
#include <linux/errno.h>
-#include <linux/uaccess.h>
-#include <linux/bitops.h>
-#include <linux/spinlock.h>
#include <linux/random.h>
#include <net/ip.h>
#include <net/ipv6.h>
diff --git a/net/netfilter/ipset/ip_set_hash_netport.c b/net/netfilter/ipset/ip_set_hash_netport.c
index 342250f..34a1656 100644
--- a/net/netfilter/ipset/ip_set_hash_netport.c
+++ b/net/netfilter/ipset/ip_set_hash_netport.c
@@ -12,9 +12,6 @@
#include <linux/ip.h>
#include <linux/skbuff.h>
#include <linux/errno.h>
-#include <linux/uaccess.h>
-#include <linux/bitops.h>
-#include <linux/spinlock.h>
#include <linux/random.h>
#include <net/ip.h>
#include <net/ipv6.h>
^ permalink raw reply related
* Re: [PATCH v2 3/6] KVM-GST: KVM Steal time accounting
From: Glauber Costa @ 2011-02-01 15:58 UTC (permalink / raw)
To: lidong chen
Cc: Avi Kivity, kvm, linux-kernel, aliguori, Rik van Riel,
Jeremy Fitzhardinge, Peter Zijlstra
In-Reply-To: <AANLkTi=-y7fk1HwiH8+_fSxbp_rif+MRzuhcNmwc38_V@mail.gmail.com>
On Mon, 2011-01-31 at 00:45 +0800, lidong chen wrote:
> I think we can use performance counter.
> use unhalted core cycles event, in the nmi callback funcation, count
> which process is running .
> if the vm exit is caused by nmi,discard it.
> the system time of qemu process is the time steal by kvm.
Performance counters are a scarce resource, so I'd rather not use them,
since it will mean forcing a context switch from whoever is using it at
the moment. Which is also an expensive operation anyway.
So even though it can be possible, in theory, I don't see why use it
in this particular case.
>
>
> 2011/1/30 Avi Kivity <avi@redhat.com>:
> > On 01/28/2011 09:52 PM, Glauber Costa wrote:
> >>
> >> This patch accounts steal time time in kernel/sched.
> >> I kept it from last proposal, because I still see advantages
> >> in it: Doing it here will give us easier access from scheduler
> >> variables such as the cpu rq. The next patch shows an example of
> >> usage for it.
> >>
> >> Since functions like account_idle_time() can be called from
> >> multiple places, not only account_process_tick(), steal time
> >> grabbing is repeated in each account function separatedely.
> >>
> >
> > I accept that steal time is worthwhile, but do you have some way to
> > demonstrate that the implementation actually works and is beneficial?
> >
> > Perhaps run two cpu-bound compute processes on one vcpu, overcommit that
> > vcpu, and see what happens to the processing rate with and without steal
> > time accounting. I'd expect a fairer response with steal time accounting.
> >
> > --
> > error compiling committee.c: too many arguments to function
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe kvm" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
> >
^ permalink raw reply
* Re: [1.8.0] make two-argument fetch update remote branches
From: Nguyen Thai Ngoc Duy @ 2011-02-01 15:58 UTC (permalink / raw)
To: Jay Soffian; +Cc: Thomas Rast, Junio C Hamano, git
In-Reply-To: <AANLkTi=Y9PBs_jXyCiAL9YLA8Y_jzWwqxw63hKm7fVBO@mail.gmail.com>
On Tue, Feb 1, 2011 at 2:04 PM, Jay Soffian <jaysoffian@gmail.com> wrote:
> On Mon, Jan 31, 2011 at 4:44 PM, Thomas Rast <trast@student.ethz.ch> wrote:
>> Add a fetch.updateRemoteNamespace (or so) configuration variable that
>> defaults to false. When enabled, it turns on the auto-updating
>> behaviour.
>
> Would it make sense to group the pre-1.8 compatibility switches
> together in some way, if there will be several of them? Maybe
>
> [compat]
> fetchUpdateRemoteNamespace = false
> ...
It is. I was thinking of it as a group of "short"-lived configs to
help maintain backward compatibility for some time (not for ever)
until users are forced to migrate.
--
Duy
^ permalink raw reply
* Re: [GIT PULL] XFS update for 2.6.38-rc3
From: Mark Lord @ 2011-02-01 16:00 UTC (permalink / raw)
To: Alex Elder; +Cc: akpm, torvalds, linux-kernel, xfs
In-Reply-To: <201101311642.p0VGgXTS018851@stout.americas.sgi.com>
On 11-01-31 11:42 AM, Alex Elder wrote:
> Linus, please accept the following updates for XFS, for 2.6.38-rc3
> (if it's not too late) or 2.6.38-rc4.
>
> They are all fixes for bugs that have some pretty undesirable
> consequences. They address:
> - One spot in which a hang can occur due to neglecting to drop a
> lock
> - A bug which in some cases a bogus block number can be recorded in
> a block map btree, resulting in a subsequent BUG_ON().
> - Two memory leaks
> - Three places in which extent sizes are allowed to exceed various
> size limits
> - One place where code depends on behavior that is not well-defined
> by the C standard
> - One problem in handling transaction commit errors
Are these bugs all new in 2.6.38, or should some of these fixes
also go out to -stable for earlier revisions?
> Dave Chinner (8):
> xfs: fix log ticket leak on forced shutdown.
> xfs: fix efi item leak on forced shutdown
> xfs: speculative delayed allocation uses rounddown_power_of_2 badly
> xfs: limit extent length for allocation to AG size
> xfs: prevent extsize alignment from exceeding maximum extent size
> xfs: limit extsize to size of AGs and/or MAXEXTLEN
> xfs: handle CIl transaction commit failures correctly
> xfs: fix dquot shaker deadlock
>
> bpm@sgi.com (1):
> xfs: xfs_bmap_add_extent_delay_real should init br_startblock
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
^ permalink raw reply
* Re: [PATCH v2 3/6] KVM-GST: KVM Steal time accounting
From: Glauber Costa @ 2011-02-01 15:57 UTC (permalink / raw)
To: Avi Kivity
Cc: kvm, linux-kernel, aliguori, Rik van Riel, Jeremy Fitzhardinge,
Peter Zijlstra
In-Reply-To: <4D456FF9.2010309@redhat.com>
On Sun, 2011-01-30 at 16:04 +0200, Avi Kivity wrote:
> On 01/28/2011 09:52 PM, Glauber Costa wrote:
> > This patch accounts steal time time in kernel/sched.
> > I kept it from last proposal, because I still see advantages
> > in it: Doing it here will give us easier access from scheduler
> > variables such as the cpu rq. The next patch shows an example of
> > usage for it.
> >
> > Since functions like account_idle_time() can be called from
> > multiple places, not only account_process_tick(), steal time
> > grabbing is repeated in each account function separatedely.
> >
>
> I accept that steal time is worthwhile, but do you have some way to
> demonstrate that the implementation actually works and is beneficial?
>
> Perhaps run two cpu-bound compute processes on one vcpu, overcommit that
> vcpu, and see what happens to the processing rate with and without steal
> time accounting. I'd expect a fairer response with steal time accounting.
Avi,
There are two things here:
One of them, which is solely the accounting of steal time, (patches 1 to
4) has absolutely nothing to do with what you said. Its sole purpose is
to provide the user with information about "why is my process slow if I
am using 100 % of my cpu?")
The last patch is the only one that actually tries to rebalance cpus
according to steal time information. For that, I do have some
experiments I did here to see if it is working, will try to provide more
precise data in the next submission.
^ permalink raw reply
* Radeon support state in libkms
From: Alexandre Demers @ 2011-02-01 15:56 UTC (permalink / raw)
To: dri-devel
Hi,
I was looking at the radeon support state in libkms and I found out the
following patch was proposed back in September, but never commented nor
merged. The patch was submitted by nobled.
http://lists.freedesktop.org/archives/dri-devel/2010-September/003740.html
I applied it on the latest drm git version without any problem and
compilation looks fine. Is there a reason preventing it from being merged?
If it needs testing, make your suggestion, I'll gladly make my best to
test it.
--
Alexandre Demers
^ permalink raw reply
* Re: [PATCH v2 2/3] udev: u8500 support and style fix
From: Andreas WESTIN @ 2011-02-01 15:55 UTC (permalink / raw)
To: ofono
In-Reply-To: <1296574751.1520.267.camel@aeonflux>
[-- Attachment #1: Type: text/plain, Size: 1504 bytes --]
Hi Marcel,
Jessica is out of office.
On 2011-02-01 16:39, Marcel Holtmann wrote:
> Hi Jessica,
>
>> plugins/udev.c | 5 ++++-
>> 1 files changed, 4 insertions(+), 1 deletions(-)
>
> so you wanna combine the udev rule change and the udev change together
> actually. They both belong together. The actual modem plugin driver is
> not related.
Ok, will correct.
>> diff --git a/plugins/udev.c b/plugins/udev.c
>> index ce1efe6..49b5eb8 100644
>> --- a/plugins/udev.c
>> +++ b/plugins/udev.c
>> @@ -185,7 +185,8 @@ static void add_hso(struct ofono_modem *modem,
>> devnode = udev_device_get_devnode(udev_device);
>>
>> if (g_str_has_suffix(type, "Application") == TRUE)
>> - ofono_modem_set_string(modem, APPLICATION_PORT, devnode);
>> + ofono_modem_set_string(modem, APPLICATION_PORT,
>> + devnode);
>
> What is this part doing here?
Style fix, should it be removed ?
>> else if (g_str_has_suffix(type, "Control") == TRUE)
>> ofono_modem_set_string(modem, CONTROL_PORT, devnode);
>> } else if (g_str_equal(subsystem, "net") == TRUE) {
>> @@ -636,6 +637,8 @@ done:
>> add_nokia(modem, udev_device);
>> else if (g_strcmp0(driver, "isiusb") == 0)
>> add_isi(modem, udev_device);
>> + else if (g_strcmp0(driver, "u8500") == 0)
>> + add_isi(modem, udev_device);
>> else if (g_strcmp0(driver, "n900") == 0)
>> add_isi(modem, udev_device);
>> else if (g_strcmp0(driver, "gobi") == 0)
>
Regards
Andreas
^ permalink raw reply
* [U-Boot] u-boot compilation lowlevel_init.S:619: error: #error "Unknown DDR configuration!!!"
From: Wolfgang Denk @ 2011-02-01 15:55 UTC (permalink / raw)
To: u-boot
In-Reply-To: <AANLkTikrrkC5fk7C1-Pm+Fx88h7Pu_2Nyz6rLJ=X2BTX@mail.gmail.com>
Dear Vaishali,
In message <AANLkTikrrkC5fk7C1-Pm+Fx88h7Pu_2Nyz6rLJ=X2BTX@mail.gmail.com> you wrote:
> Getting this error with the u-boot compilation http://pastebin.com/h3x90vHK
> u-boot is a git clone of the git://gitorious.org/hawkboard/u-boot.git
> plz help any idea what needs to be done to fix this .
Sorry - please contact the people responsible for that repository.
We have no idea if or how this corresponds to the mainline code we are
discussing here.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Madness takes its toll. Please have exact change.
^ permalink raw reply
* [Qemu-devel] [PATCH] linux-user: avoid gcc array overrun warning for sparc
From: Peter Maydell @ 2011-02-01 15:54 UTC (permalink / raw)
To: qemu-devel; +Cc: Blue Swirl, Riku Voipio, patches
Suppress a gcc array bounds overrun warning when filling in the SPARC
signal frame by adjusting our definition of the structure so that the
fp and callers_pc membes are part of the ins[] array rather than
separate fields; since qemu has no need to access the fields individually
there is no need to follow the kernel's structure field naming exactly.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
---
This is a fix for another warning that the armel gcc gives:
linux-user/signal.c:1979: error: array subscript is above array bounds
so if it passes review I think it's a good candidate for putting in 0.14.
linux-user/signal.c | 7 ++++---
1 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/linux-user/signal.c b/linux-user/signal.c
index 0664770..b01bd64 100644
--- a/linux-user/signal.c
+++ b/linux-user/signal.c
@@ -1817,9 +1817,10 @@ struct target_sigcontext {
/* A Sparc stack frame */
struct sparc_stackf {
abi_ulong locals[8];
- abi_ulong ins[6];
- struct sparc_stackf *fp;
- abi_ulong callers_pc;
+ abi_ulong ins[8];
+ /* It's simpler to treat fp and callers_pc as elements of ins[]
+ * since we never need to access them ourselves.
+ */
char *structptr;
abi_ulong xargs[6];
abi_ulong xxargs[1];
--
1.7.1
^ permalink raw reply related
* Re: [PATCH v2 6/6] Describe KVM_MSR_STEAL_TIME
From: Glauber Costa @ 2011-02-01 15:54 UTC (permalink / raw)
To: Avi Kivity; +Cc: kvm, linux-kernel, aliguori
In-Reply-To: <4D456555.2030606@redhat.com>
On Sun, 2011-01-30 at 15:19 +0200, Avi Kivity wrote:
> On 01/28/2011 09:52 PM, Glauber Costa wrote:
> > This patch adds documentation about usage of the newly
> > introduced KVM_MSR_STEAL_TIME.
> >
> >
> > +
> > +MSR_KVM_STEAL_TIME: 0x4b564d03
> > +
> > + data: 4-byte alignment physical address of a memory area which must be
> > + in guest RAM, plus an enable bit in bit 0.
>
> 64-byte aligned:
> - avoids wrapping around a page boundary, which may let us optimize
> things later on (see kvm_write_guest_cached()).
> - gives us 5 more unused bits to enable more options
>
> > This memory is expected to
> > + hold a copy of the following structure:
> > +
> > + struct kvm_steal_time {
> > + __u64 steal;
> > + __u32 version;
> > + __u32 flags;
> > + __u32 pad[6];
> > + }
> > +
> > + whose data will be filled in by the hypervisor periodically. Only one
> > + write, or registration, is needed for each VCPU. The interval between
> > + updates of this structure is arbitrary and implementation-dependent.
> > + The hypervisor may update this structure at any time it sees fit until
> > + anything with bit0 == 0 is written to it.
> > +
> > + Fields have the following meanings:
> > +
> > + version: guest has to check version before and after grabbing
> > + time information and check that they are both equal and even.
> > + An odd version indicates an in-progress update.
> > +
> > + flags: At this point, always zero. May be used to indicate
> > + changes in this structure in the future.
> > +
> > + steal: the amount of time in which this vCPU did not run, in
> > + nanoseconds.
> > +
>
> The guest must initialize the entire 64-byte structure to zero before
> enabling the feature.
I honestly don't see why. But I also don't see why not...
Will update it.
^ permalink raw reply
* [Lustre-devel] LUG 2011 - Registration is Open
From: Shipman, Galen M. @ 2011-02-01 15:54 UTC (permalink / raw)
To: lustre-devel
LUG 2011 will be held in Orlando, Florida from 8:30 AM Tuesday, April 12,
2011 through 12:00 noon April 14, 2011 at the Marriott World Center Golf
and Spa resort. This two-and-a-half-day event is the primary venue for
discussion and seminars on open source parallel file system technologies
with a unique focus on the Lustre parallel file system.
The conference is generously supported by the following corporate
sponsors: Bull, DataDirect Networks, Dell, HP, LSI, Oracle, SGI,
Terascala, Whamcloud, and Xyratex.
REGISTRATION IS NOW OPEN
You can now register for LUG 2011 via the conference website at
http://www.olcf.ornl.gov/event/lug-2011/ (click on the registration tab)
Early bird registration (through March 15) is $400 per person, while
standard registration (after March 15) is $550 per person for the entire
two-and-a-half-day event.
Hotel reservations can be made using the website or phone number below:
https://resweb.passkey.com/go/LUG2011
Tel: 1-800-266-9432
$179.00 (non-government)
$104.00 (government or prevailing government rate)
CALL FOR PARTICIPATION
The LUG program committee would like to invite members of the Lustre
community to submit presentation abstracts for inclusion in this year?s
meeting. It is not necessary to submit a technical paper, just an abstract
of the proposed talk no more than a page in length. Talks should be
approximately half an hour in length and reflect the work that you or your
site are doing with Lustre. The deadline to submit presentation abstracts
is February 14, 2011. For questions or to submit a presentation abstract
contact the program committee chair, Stephen Simms, at
lug-submissions at ornl.gov.
LUG 2011 is user-led with an organizing committee made up of
representatives from Commissariat ? l''?nergie atomique (CEA), Indiana
University ? Pervasive Technology Institute (IU), Lawrence Livermore
National Laboratory (LLNL), Naval Research Laboratory (NRL), ORNL, Sandia
National Laboratories (SNL), and Texas Advanced Computing Center (TACC).
http://www.olcf.ornl.gov/event/lug-2011/
^ permalink raw reply
* [Qemu-devel] KVM call minutes for Feb 1
From: Chris Wright @ 2011-02-01 15:54 UTC (permalink / raw)
To: kvm; +Cc: qemu-devel
KVM upstream merge: status, plans, coordination
- Jan has a git tree, consolidating
- qemu-kvm io threading is still an issue
- Anthony wants to just merge
- concerns with non-x86 arch and merge
- concerns with big-bang patch merge and following stability
- post 0.14 conversion to glib mainloop, non-upstreamed qemu-kvm will be
a problem if it's not there by then
- testing and nuances are still an issue (e.g. stefan berger's mmio read issue)
- qemu-kvm still evolving, needs to get sync'd or it will keep diverging
- 2 implementations of main init, cpu init, Jan has merged them into one
- qemu-kvm-x86.c file that's only a few hundred lines
- review as one patch to see the fundamental difference
QMP support status for 0.14
- declare QMP fully supported
- caveats: specific errors aren't guaranteed yet (primarily documentation)
- human monitor passthrough command is best effort
- device tree structure is not reliable, use name not path
- will send out patch to update qmp-commands.hx to document this (and Cc
libvirt)
- schema file (json subset which is python) and code generator to
generate code with C structures, also generates client library for
test cases (can test against new and old qmp server to verify hasn't
changed)
- HMP implemented in terms of QMP only
- at the end should have a test framework to test all commands
- glib/gtest framework
0.14 stable fork today
already posted 0.14 patches?
- will pick up all those patches before forking, fork at the end of the day
- will grab latest SeaBIOS and vgabios
SeaBIOS update for 0.14 (AHCI boot capable version)
- need to check if (and why) AHCI is disabled by default
- assuming no fundamental issues, could be enabled and become an
experimental new 0.14 feature
Summer of code 2011
- http://wiki.qemu.org/Google_Summer_of_Code_2011
- update wiki page with project ideas (let Anthony or Luiz know if you
want to be a mentor)
- application is due at end of the month
- mentors...be prepared that projects may take longer than just the
summer of code to complete
- join #qemu-gsoc on OFTC for gsoc discussions
Going to FOSDEM? agraf will be there...
^ permalink raw reply
* KVM call minutes for Feb 1
From: Chris Wright @ 2011-02-01 15:54 UTC (permalink / raw)
To: kvm; +Cc: qemu-devel
KVM upstream merge: status, plans, coordination
- Jan has a git tree, consolidating
- qemu-kvm io threading is still an issue
- Anthony wants to just merge
- concerns with non-x86 arch and merge
- concerns with big-bang patch merge and following stability
- post 0.14 conversion to glib mainloop, non-upstreamed qemu-kvm will be
a problem if it's not there by then
- testing and nuances are still an issue (e.g. stefan berger's mmio read issue)
- qemu-kvm still evolving, needs to get sync'd or it will keep diverging
- 2 implementations of main init, cpu init, Jan has merged them into one
- qemu-kvm-x86.c file that's only a few hundred lines
- review as one patch to see the fundamental difference
QMP support status for 0.14
- declare QMP fully supported
- caveats: specific errors aren't guaranteed yet (primarily documentation)
- human monitor passthrough command is best effort
- device tree structure is not reliable, use name not path
- will send out patch to update qmp-commands.hx to document this (and Cc
libvirt)
- schema file (json subset which is python) and code generator to
generate code with C structures, also generates client library for
test cases (can test against new and old qmp server to verify hasn't
changed)
- HMP implemented in terms of QMP only
- at the end should have a test framework to test all commands
- glib/gtest framework
0.14 stable fork today
already posted 0.14 patches?
- will pick up all those patches before forking, fork at the end of the day
- will grab latest SeaBIOS and vgabios
SeaBIOS update for 0.14 (AHCI boot capable version)
- need to check if (and why) AHCI is disabled by default
- assuming no fundamental issues, could be enabled and become an
experimental new 0.14 feature
Summer of code 2011
- http://wiki.qemu.org/Google_Summer_of_Code_2011
- update wiki page with project ideas (let Anthony or Luiz know if you
want to be a mentor)
- application is due at end of the month
- mentors...be prepared that projects may take longer than just the
summer of code to complete
- join #qemu-gsoc on OFTC for gsoc discussions
Going to FOSDEM? agraf will be there...
^ permalink raw reply
* Re: [PATCH] security/selinux: fix /proc/sys/ labeling
From: Lucian Adrian Grijincu @ 2011-02-01 15:53 UTC (permalink / raw)
To: Stephen Smalley
Cc: James Morris, Eric Paris, Nick Piggin, Eric W. Biederman,
linux-kernel, linux-security-module
In-Reply-To: <1296572538.12605.4.camel@moss-pluto>
On Tue, Feb 1, 2011 at 5:02 PM, Stephen Smalley <sds@tycho.nsa.gov> wrote:
> Is this patch really from Eric or just derived from an earlier patch by him?
No, sorry for the confusion.
I seem to have triggered a git send-email bug.
>> Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
>
> And did Eric truly sign off on this patch or just on an earlier one?
Just the earlier one. I added his sign-off because of this paragraph
in SubmittingPatches:
| The Signed-off-by: tag indicates that the signer was involved in the
| development of the patch, or that he/she was in the patch's delivery path.
>
>> diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c
>> index e276eb4..7c5dfb1 100644
>> --- a/security/selinux/hooks.c
>> +++ b/security/selinux/hooks.c
>> @@ -1317,9 +1311,9 @@ static int inode_doinit_with_dentry(struct inode *inode, struct dentry *opt_dent
>>
>> if ((sbsec->flags & SE_SBPROC) && !S_ISLNK(inode->i_mode)) {
>> struct proc_inode *proci = PROC_I(inode);
>> - if (proci->pde) {
>> + if (opt_dentry && (proci->pde || proci->sysctl)) {
>> isec->sclass = inode_mode_to_security_class(inode->i_mode);
>> - rc = selinux_proc_get_sid(proci->pde,
>> + rc = selinux_proc_get_sid(opt_dentry,
>> isec->sclass,
>> &sid);
>> if (rc)
>
> It would be nice if we could eliminate the last remaining piece of proc
> internal knowledge from this code - why do we need the proci->pde ||
> proci->sysctl test here? What changes without it?
Without we label all nodes in /proc/ through selinux_proc_get_sid.
/proc/1/limits should not get it's sid from here, but from
security_task_to_inode -> selinux_task_to_inode.
Without the check we send "/1/limits" to selinux_proc_get_sid, which
strips off "/1" leaving "/limits". This will be labeled with "proc_t"
IIRC.
--
.
..: Lucian
^ permalink raw reply
* Re: Locking in the clk API, part 2: clk_prepare/clk_unprepare
From: Uwe Kleine-König @ 2011-02-01 15:53 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: Jeremy Kerr, Dima Zavin, Saravana Kannan, Lorenzo Pieralisi,
linux-sh, Ben Herrenschmidt, Sascha Hauer, linux-kernel,
Paul Mundt, Ben Dooks, Vincent Guittot, linux-arm-kernel,
Nicolas Pitre
In-Reply-To: <20110201152458.GP31216@n2100.arm.linux.org.uk>
On Tue, Feb 01, 2011 at 03:24:58PM +0000, Russell King - ARM Linux wrote:
> On Tue, Feb 01, 2011 at 04:18:46PM +0100, Uwe Kleine-König wrote:
> > yeah, didn't thought about multiple consumers, so (as Jeremy suggested)
> > the right thing is to sleep until CLK_BUSY is cleared.
>
> A simpler way to write this is:
>
> int clk_prepare(struct clk *clk)
> {
> int ret = 0;
>
> mutex_lock(&clk->mutex);
> if (clk->prepared == 0)
> ret = clk->ops->prepare(clk);
> if (ret == 0)
> clk->prepared++;
> mutex_unlock(&clk->mutex);
>
> return ret;
> }
But you cannot call this in atomic context when you know the clock is
already prepared.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* Re: [PATCH 3/3] pnfs: fix pnfs lock inversion of i_lock and cl_lock
From: Fred Isaman @ 2011-02-01 15:54 UTC (permalink / raw)
To: Benny Halevy; +Cc: linux-nfs, Trond Myklebust
In-Reply-To: <4D48299F.4070800@panasas.com>
On Feb 1, 2011, at 10:41 AM, Benny Halevy wrote:
> I'm actually seeing that with the pnfs tree over 2.8.38-rc3
> See signature below.
> Will re-test with this patch.
>
In your retest, note that this patch depends on patch 1 of the series to work correctly.
Fred
> Benny
>
> [ INFO: possible circular locking dependency detected ]
> 2.6.38-rc3-pnfs-00391-g13858b7 #5
> -------------------------------------------------------
> test5/2174 is trying to acquire lock:
> (&sb->s_type->i_lock_key#24){+.+...}, at: [<ffffffffa018e924>] nfs_inode_set_]
>
> but task is already holding lock:
> (&(&clp->cl_lock)->rlock){+.+...}, at: [<ffffffffa018e822>] nfs_inode_set_del]
>
> which lock already depends on the new lock.
>
>
> the existing dependency chain (in reverse order) is:
>
> -> #1 (&(&clp->cl_lock)->rlock){+.+...}:
> [<ffffffff8108281f>] lock_acquire+0xd3/0x100
> [<ffffffff8147df43>] _raw_spin_lock+0x36/0x69
> [<ffffffffa0193b87>] pnfs_update_layout+0x2f5/0x4d9 [nfs]
> [<ffffffffa0166862>] nfs_write_begin+0x90/0x257 [nfs]
> [<ffffffff810e1d7b>] generic_file_buffered_write+0x106/0x267
> [<ffffffff810e33a8>] __generic_file_aio_write+0x245/0x27a
> [<ffffffff810e3439>] generic_file_aio_write+0x5c/0xaa
> [<ffffffffa016728b>] nfs_file_write+0xdf/0x177 [nfs]
> [<ffffffff8112b599>] do_sync_write+0xcb/0x108
> [<ffffffff8112bf97>] vfs_write+0xb1/0x10d
> [<ffffffff8112c0bc>] sys_write+0x4d/0x77
> [<ffffffff8100ab82>] system_call_fastpath+0x16/0x1b
>
> -> #0 (&sb->s_type->i_lock_key#24){+.+...}:
> [<ffffffff81082457>] __lock_acquire+0xa45/0xd3a
> [<ffffffff8108281f>] lock_acquire+0xd3/0x100
> [<ffffffff8147df43>] _raw_spin_lock+0x36/0x69
> [<ffffffffa018e924>] nfs_inode_set_delegation+0x1f4/0x250 [nfs]
> [<ffffffffa017cb9b>] nfs4_opendata_to_nfs4_state+0x26c/0x2c9 [nfs]
> [<ffffffffa0181827>] nfs4_do_open+0x364/0x37c [nfs]
> [<ffffffffa0181867>] nfs4_atomic_open+0x28/0x45 [nfs]
> [<ffffffffa0165edc>] nfs_open_revalidate+0xf8/0x1a1 [nfs]
> [<ffffffff81135111>] d_revalidate+0x21/0x56
> [<ffffffff811351ca>] do_revalidate+0x1d/0x7a
> [<ffffffff811353eb>] do_lookup+0x1c4/0x1f8
> [<ffffffff81137406>] link_path_walk+0x260/0x485
> [<ffffffff8113786a>] do_path_lookup+0x50/0x10d
> [<ffffffff81138658>] do_filp_open+0x137/0x65e
> [<ffffffff81129e6e>] do_sys_open+0x60/0xf2
> [<ffffffff81129f33>] sys_open+0x20/0x22
> [<ffffffff8100ab82>] system_call_fastpath+0x16/0x1b
>
>
> On 2011-01-31 17:27, Fred Isaman wrote:
>> The pnfs code was using throughout the lock order i_lock, cl_lock.
>> This conflicts with the nfs delegation code. Rework the pnfs code
>> to avoid taking both locks simultaneously.
>>
>> Currently the code takes the double lock to add/remove the layout to a
>> nfs_client list, while atomically checking that the list of lsegs is
>> empty. To avoid this, we rely on existing serializations. When a
>> layout is initialized with lseg count equal zero, LAYOUTGET's
>> openstateid serialization is in effect, making it safe to assume it
>> stays zero unless we change it. And once a layout's lseg count drops
>> to zero, it is set as DESTROYED and so will stay at zero.
>>
>> Signed-off-by: Fred Isaman <iisaman@netapp.com>
>> ---
>> fs/nfs/callback_proc.c | 2 +-
>> fs/nfs/pnfs.c | 50 +++++++++++++++++++++++++++--------------------
>> 2 files changed, 30 insertions(+), 22 deletions(-)
>>
>> diff --git a/fs/nfs/callback_proc.c b/fs/nfs/callback_proc.c
>> index 8958757..2f41dcce 100644
>> --- a/fs/nfs/callback_proc.c
>> +++ b/fs/nfs/callback_proc.c
>> @@ -188,10 +188,10 @@ static u32 initiate_bulk_draining(struct nfs_client *clp,
>> rv = NFS4ERR_DELAY;
>> list_del_init(&lo->plh_bulk_recall);
>> spin_unlock(&ino->i_lock);
>> + pnfs_free_lseg_list(&free_me_list);
>> put_layout_hdr(lo);
>> iput(ino);
>> }
>> - pnfs_free_lseg_list(&free_me_list);
>> return rv;
>> }
>>
>> diff --git a/fs/nfs/pnfs.c b/fs/nfs/pnfs.c
>> index f89c3bb..ee6c69a 100644
>> --- a/fs/nfs/pnfs.c
>> +++ b/fs/nfs/pnfs.c
>> @@ -247,13 +247,6 @@ put_lseg_locked(struct pnfs_layout_segment *lseg,
>> BUG_ON(test_bit(NFS_LSEG_VALID, &lseg->pls_flags));
>> list_del(&lseg->pls_list);
>> if (list_empty(&lseg->pls_layout->plh_segs)) {
>> - struct nfs_client *clp;
>> -
>> - clp = NFS_SERVER(ino)->nfs_client;
>> - spin_lock(&clp->cl_lock);
>> - /* List does not take a reference, so no need for put here */
>> - list_del_init(&lseg->pls_layout->plh_layouts);
>> - spin_unlock(&clp->cl_lock);
>> set_bit(NFS_LAYOUT_DESTROYED, &lseg->pls_layout->plh_flags);
>> /* Matched by initial refcount set in alloc_init_layout_hdr */
>> put_layout_hdr_locked(lseg->pls_layout);
>> @@ -319,14 +312,30 @@ mark_matching_lsegs_invalid(struct pnfs_layout_hdr *lo,
>> return invalid - removed;
>> }
>>
>> +/* note free_me must contain lsegs from a single layout_hdr */
>> void
>> pnfs_free_lseg_list(struct list_head *free_me)
>> {
>> - struct pnfs_layout_segment *lseg, *tmp;
>> + if (!list_empty(free_me)) {
>> + struct pnfs_layout_segment *lseg, *tmp;
>> + struct pnfs_layout_hdr *lo;
>>
>> - list_for_each_entry_safe(lseg, tmp, free_me, pls_list) {
>> - list_del(&lseg->pls_list);
>> - free_lseg(lseg);
>> + lo = list_first_entry(free_me,
>> + struct pnfs_layout_segment,
>> + pls_list)->pls_layout;
>> +
>> + if (test_bit(NFS_LAYOUT_DESTROYED, &lo->plh_flags)) {
>> + struct nfs_client *clp;
>> +
>> + clp = NFS_SERVER(lo->plh_inode)->nfs_client;
>> + spin_lock(&clp->cl_lock);
>> + list_del_init(&lo->plh_layouts);
>> + spin_unlock(&clp->cl_lock);
>> + }
>> + list_for_each_entry_safe(lseg, tmp, free_me, pls_list) {
>> + list_del(&lseg->pls_list);
>> + free_lseg(lseg);
>> + }
>> }
>> }
>>
>> @@ -704,6 +713,7 @@ pnfs_update_layout(struct inode *ino,
>> struct nfs_client *clp = NFS_SERVER(ino)->nfs_client;
>> struct pnfs_layout_hdr *lo;
>> struct pnfs_layout_segment *lseg = NULL;
>> + bool first = false;
>>
>> if (!pnfs_enabled_sb(NFS_SERVER(ino)))
>> return NULL;
>> @@ -734,7 +744,10 @@ pnfs_update_layout(struct inode *ino,
>> atomic_inc(&lo->plh_outstanding);
>>
>> get_layout_hdr(lo);
>> - if (list_empty(&lo->plh_segs)) {
>> + if (list_empty(&lo->plh_segs))
>> + first = true;
>> + spin_unlock(&ino->i_lock);
>> + if (first) {
>> /* The lo must be on the clp list if there is any
>> * chance of a CB_LAYOUTRECALL(FILE) coming in.
>> */
>> @@ -743,17 +756,12 @@ pnfs_update_layout(struct inode *ino,
>> list_add_tail(&lo->plh_layouts, &clp->cl_layouts);
>> spin_unlock(&clp->cl_lock);
>> }
>> - spin_unlock(&ino->i_lock);
>>
>> lseg = send_layoutget(lo, ctx, iomode);
>> - if (!lseg) {
>> - spin_lock(&ino->i_lock);
>> - if (list_empty(&lo->plh_segs)) {
>> - spin_lock(&clp->cl_lock);
>> - list_del_init(&lo->plh_layouts);
>> - spin_unlock(&clp->cl_lock);
>> - }
>> - spin_unlock(&ino->i_lock);
>> + if (!lseg && first) {
>> + spin_lock(&clp->cl_lock);
>> + list_del_init(&lo->plh_layouts);
>> + spin_unlock(&clp->cl_lock);
>> }
>> atomic_dec(&lo->plh_outstanding);
>> put_layout_hdr(lo);
^ permalink raw reply
* Re: [RFC] voice call API changes (proposal)
From: Denis Kenzior @ 2011-02-01 15:54 UTC (permalink / raw)
To: ofono
In-Reply-To: <4D482A32.1020806@nokia.com>
[-- Attachment #1: Type: text/plain, Size: 1798 bytes --]
Hi Andras,
>>> +
>>> + boolean Forwarded
>>> +
>>> + Contains the indication whether the voice call is a
>>> + forwarded call or not.
>>> +
>> So just to clarify, this is usually set on a local Incoming / Waiting
>> call, correct?
> This property would apply to both, outgoing and incoming calls.
>
> When the incoming call is a forwarded call the call is accompanied
> by a "forwarded call" SS notification.
>
> When the call is an outgoing call and the call is forwarded due to the
> remote party having a conditional or unconditional forwarding enabled,
> the outgoing call is accompanied by a "call has been forwarded"
> SS notification.
>
> I think would be a good idea, if not mandatory, to have a voice call
> property indicating the call direction.
So why do we need the below two signals if the Forwarded property
applies to both incoming and outgoing calls?
>>> + UnconditionalForwardingInEffect
>>> +
>>> + Signal is emitted when a call is made and unconditional
>>> + call forwarding supplementary service is active.
>> This is for a local dialing / alerting call. Correct?
> The notification is sent in connection with an outgoing call when
> the remote party has unconditional call forwarding enabled that
> is enforced by the network.
>>> +
>>> + ConditionalForwardingInEffect
>>> +
>>> + Signal is emitted when a call is made and some of the
>>> + conditional call forwarding supplementary services are
>>> + active.
>>> +
>> Same as above?
> The notification is sent in connection with an outgoing call when
> the remote party has such conditional call forwarding enabled
> that is enforced by the network.
>
Regards,
-Denis
^ permalink raw reply
* Re: [PATCH v2 4/6] KVM-GST: KVM Steal time registration
From: Glauber Costa @ 2011-02-01 15:53 UTC (permalink / raw)
To: Avi Kivity
Cc: kvm, linux-kernel, aliguori, Rik van Riel, Jeremy Fitzhardinge,
Peter Zijlstra
In-Reply-To: <4D45649A.4090709@redhat.com>
On Sun, 2011-01-30 at 15:16 +0200, Avi Kivity wrote:
> On 01/28/2011 09:52 PM, Glauber Costa wrote:
> > Register steal time within KVM. Everytime we sample the steal time
> > information, we update a local variable that tells what was the
> > last time read. We then account the difference.
> >
> >
> >
> > static void kvm_guest_cpu_offline(void *dummy)
> > {
> > kvm_pv_disable_apf(NULL);
> > + native_write_msr(MSR_KVM_STEAL_TIME, 0, 0);
> > apf_task_wake_all();
> > }
>
> Don't use the native_ versions, they override the pvops implementation.
> It doesn't matter for kvm, but we're not supposed to know this.
fair.
> > + /*
> > + * using nanoseconds introduces noise, which accumulates easily
> > + * leading to big steal time values. We want, however, to keep the
> > + * interface nanosecond-based for future-proofness. The hypervisor may
> > + * adopt a similar strategy, but we can't rely on that.
> > + */
> > + delta /= NSEC_PER_MSEC;
> > + delta *= NSEC_PER_MSEC;
>
> You're working around this problem both in the guest and host. So even
> if we fix it in one, it will still be broken in the other.
And if you notice, in two different ways:
I am (was) forcing to usecs in the host, and msecs in the guest.
One of the problems here, is that if we account steal time, we refrain
from accounting user / system time. Reason being, that if we account it,
we'll end up with more than HZ ticks per HZ, since we'll account ticks
as both steal and real.
And since the granularity of the cpu accounting is too coarse, we end up
with much more steal time than we should, because things that are less
than 1 unity of cputime, are often rounded up to 1 unity of cputime.
Now, I've already said that I will investigate further, and I'm ready to
back of from all of this. But assuming my analysis is right so far, what
if we keep things in nsecs or msecs, and only convert to cputime in the
time of read? This would allow us to just subtract steal time from
user/system time, in a more fine grained way.
^ permalink raw reply
* Locking in the clk API, part 2: clk_prepare/clk_unprepare
From: Uwe Kleine-König @ 2011-02-01 15:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110201152458.GP31216@n2100.arm.linux.org.uk>
On Tue, Feb 01, 2011 at 03:24:58PM +0000, Russell King - ARM Linux wrote:
> On Tue, Feb 01, 2011 at 04:18:46PM +0100, Uwe Kleine-K?nig wrote:
> > yeah, didn't thought about multiple consumers, so (as Jeremy suggested)
> > the right thing is to sleep until CLK_BUSY is cleared.
>
> A simpler way to write this is:
>
> int clk_prepare(struct clk *clk)
> {
> int ret = 0;
>
> mutex_lock(&clk->mutex);
> if (clk->prepared == 0)
> ret = clk->ops->prepare(clk);
> if (ret == 0)
> clk->prepared++;
> mutex_unlock(&clk->mutex);
>
> return ret;
> }
But you cannot call this in atomic context when you know the clock is
already prepared.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-K?nig |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* Re: Locking in the clk API, part 2: clk_prepare/clk_unprepare
From: @ 2011-02-01 15:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110201152458.GP31216@n2100.arm.linux.org.uk>
On Tue, Feb 01, 2011 at 03:24:58PM +0000, Russell King - ARM Linux wrote:
> On Tue, Feb 01, 2011 at 04:18:46PM +0100, Uwe Kleine-König wrote:
> > yeah, didn't thought about multiple consumers, so (as Jeremy suggested)
> > the right thing is to sleep until CLK_BUSY is cleared.
>
> A simpler way to write this is:
>
> int clk_prepare(struct clk *clk)
> {
> int ret = 0;
>
> mutex_lock(&clk->mutex);
> if (clk->prepared = 0)
> ret = clk->ops->prepare(clk);
> if (ret = 0)
> clk->prepared++;
> mutex_unlock(&clk->mutex);
>
> return ret;
> }
But you cannot call this in atomic context when you know the clock is
already prepared.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* Re: Features from GitSurvey 2010
From: Nguyen Thai Ngoc Duy @ 2011-02-01 15:52 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Jonathan Nieder, Dmitry S. Kravtsov, git, Shawn O. Pearce
In-Reply-To: <201102011451.17456.jnareb@gmail.com>
On Tue, Feb 1, 2011 at 8:51 PM, Jakub Narebski <jnareb@gmail.com> wrote:
> On Sun, 30 Jan 2011, Jonathan Nieder wrote:
>> > support for tracking empty directories
>>
>> Tricky to get the UI right. I am interested in and would be glad to
>> help with this one.
>
> Also one needs to remember that this would require adding extension
> to git index, because currently it tracks only files, and not
> directories. Explicitly tracking directories in the index could be
> useful for other purposes...
>
> The major difficulty of this is IMHO not the UI, but tracking all those
> tricky corner cases (like directory/file conflict, etc.).
Sort order in index is quite special/strange and must be handled
correctly when dirs and files are mixed. There are already special
directories in index: the submodules. Current git code treats
S_ISDIR() and S_ISGITLINK() the same in ce_to_dtype() and some more
places. You need to decouple it somehow.
I tried this (for another purpose) and pulled back. I recall Shawn had
a tree-based index implementation, don't know if he still has it.
Could be a good point to start adding dirs to index.
Actually tree-based index with dictionary (something like trees in
packv4) is a good feature itself. It could shrink index size down a
lot. index is frequently read/written so small index helps (webkit's
index is 16M, 4M after gzipped).
--
Duy
^ permalink raw reply
* [PATCHv2 dontapply] vhost-net tx tuning
From: Michael S. Tsirkin @ 2011-02-01 15:52 UTC (permalink / raw)
To: Steve Dobbelstein; +Cc: mashirle, kvm, netdev
In-Reply-To: <OF381CCA86.B82857CC-ON86257826.00629F88-86257826.006596F5@us.ibm.com>
OK, so thinking about it more, maybe the issue is this:
tx becomes full. We process one request and interrupt the guest,
then it adds one request and the queue is full again.
Maybe the following will help it stabilize? By default with it we will
only interrupt when we see an empty ring.
Which is liklely too much: pls try other values
in the middle: e.g. make bufs half the ring,
or bytes some small value like half ring * 200, or packets some
small value etc.
Set any one parameter to 0 to get current
behaviour (interrupt immediately when enabled).
Warning: completely untested.
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
---
diff --git a/drivers/vhost/net.c b/drivers/vhost/net.c
index aac05bc..6769cdc 100644
--- a/drivers/vhost/net.c
+++ b/drivers/vhost/net.c
@@ -32,6 +32,13 @@
* Using this limit prevents one virtqueue from starving others. */
#define VHOST_NET_WEIGHT 0x80000
+int tx_bytes_coalesce = 1000000000;
+module_param(tx_bytes_coalesce, int, 0644);
+int tx_bufs_coalesce = 1000000000;
+module_param(tx_bufs_coalesce, int, 0644);
+int tx_packets_coalesce = 1000000000;
+module_param(tx_packets_coalesce, int, 0644);
+
enum {
VHOST_NET_VQ_RX = 0,
VHOST_NET_VQ_TX = 1,
@@ -127,6 +134,9 @@ static void handle_tx(struct vhost_net *net)
int err, wmem;
size_t hdr_size;
struct socket *sock;
+ int bytes_coalesced = 0;
+ int bufs_coalesced = 0;
+ int packets_coalesced = 0;
/* TODO: check that we are running from vhost_worker? */
sock = rcu_dereference_check(vq->private_data, 1);
@@ -196,14 +206,26 @@ static void handle_tx(struct vhost_net *net)
if (err != len)
pr_debug("Truncated TX packet: "
" len %d != %zd\n", err, len);
- vhost_add_used_and_signal(&net->dev, vq, head, 0);
total_len += len;
+ packets_coalesced += 1;
+ bytes_coalesced += len;
+ bufs_coalesced += out;
+ if (unlikely(packets_coalesced > tx_packets_coalesce ||
+ bytes_coalesced > tx_bytes_coalesce ||
+ bufs_coalesced > tx_bufs_coalesce))
+ vhost_add_used_and_signal(&net->dev, vq, head, 0);
+ else
+ vhost_add_used(vq, head, 0);
if (unlikely(total_len >= VHOST_NET_WEIGHT)) {
vhost_poll_queue(&vq->poll);
break;
}
}
+ if (likely(packets_coalesced &&
+ bytes_coalesced &&
+ bufs_coalesced))
+ vhost_signal(&net->dev, vq);
mutex_unlock(&vq->mutex);
}
^ permalink raw reply related
* Re: [PATCH -v8a 3/7] sched: use a buddy to implement yield_task_fair
From: Peter Zijlstra @ 2011-02-01 15:53 UTC (permalink / raw)
To: Rik van Riel
Cc: kvm, linux-kernel, Avi Kiviti, Srivatsa Vaddagiri, Mike Galbraith,
Chris Wright, Nakajima, Jun
In-Reply-To: <20110201095103.3a79e92a@annuminas.surriel.com>
On Tue, 2011-02-01 at 09:51 -0500, Rik van Riel wrote:
> --- a/kernel/sysctl.c
> +++ b/kernel/sysctl.c
> @@ -375,13 +375,6 @@ static struct ctl_table kern_table[] = {
> .mode = 0644,
> .proc_handler = sched_rt_handler,
> },
> - {
> - .procname = "sched_compat_yield",
> - .data = &sysctl_sched_compat_yield,
> - .maxlen = sizeof(unsigned int),
> - .mode = 0644,
> - .proc_handler = proc_dointvec,
> - },
> #ifdef CONFIG_PROVE_LOCKING
> {
> .procname = "prove_locking",
>
There's another instance of sysctl_sched_compat_yield in sched.h, I'll
remove that and its definition in sched_fair.c too ;-)
^ permalink raw reply
* autofs5.0.5 patches for old kernels.
From: kiran @ 2011-02-01 15:51 UTC (permalink / raw)
To: autofs
Hi,
In autofs-5.0.5 distribution there are no kernel V5 patches for old
kernel(s2.6.9 to 2.6.17), but document INSTALL says
====================
Applying The Kernel Patch
=========================
Patches that can be applied to the kernel are located in the
`patches' directory. If you have installed autofs from an rpm
then they can be found in the packages' doc directory after
install. They consist of a kernel patch for each kernel from
2.6.9 thru 2.6.16 (the patches are in the 2.6.17-rc series so
patching a 2.6.17 or above kernel shouldn't be needed).
=================================================
Where can we find patchs for old kernels?
v5.0.5 is it not support on old kernels ?
Thanking you,
regards,
kiran
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
^ 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.