Nabble - linux-kernel

Re: Using x86 segments against NULL pointer deference exploit

2009-11-08T22:30:45Z

On 11/06/2009 12:35 PM, matthieu castet wrote:
>
> May be the sane way should be to forbid mapping page 0, and make run
> application needing page 0 in a
> emulator. After all it is for special case [1] :
> - Win16 binary for wine
> - upstream version of dosemu and qemu have workaround
>
> But some distro still set mmap_min_addr to 0 (ubuntu+wine, ...) :(
>

Don't Do That, Then[TM].

-hpa

--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Re: specjbb2005 and aim7 regression with 2.6.32-rc kernels

2009-11-08T22:19:48Z

On Fri, 2009-11-06 at 09:04 +0100, Ingo Molnar wrote:

> * Zhang, Yanmin <yanmin_zhang@...> wrote:
>
> > Comparing with 2.6.31, specjbb2005 and aim7 have some regressions with
> > 2.6.32-rc kernels on core2 machines.
> >
> > 1) On 4*4 core tigerton: specjbb2005 has about 5% regression.
> > 2) On 2*4 stoakley: aim7 has about 5% regression.
> >
> > On Nehalem, specjbb2005 has about 2%~8% improvement instead of
> > regression.
> >
> > aim7 has much dependency on schedule patameters, such like
> > sched_latency_ns, sched_min_granularity_ns, and
> > sched_wakeup_granularity_ns. 2.6.32-rc kernel decreases these
> > parameter values. I restore them and retest aim7 on stoakley. aim7
> > regression becomes about 2% and specjbb2005 regression also becomes
> > 2%. But on Nehalem, the improvement shrinks.
>
> Which precise 2.6.32-rc commit have you tested?
>
> Since v2.6.32-rc6 Linus's tree has this one too:
>
> f685cea: sched: Strengthen buddies and mitigate buddy induced latencies
>
> Which should improve things a bit. For 2.6.33 we have queued up these
> two in -tip:
>
> a1f84a3: sched: Check for an idle shared cache in select_task_rq_fair()
> 1b9508f: sched: Rate-limit newidle
>
> If any of them fixes a performance regression we could still merge them
> into 2.6.32 as well.

1b9508f definitely fixes netperf UDP loopback regression.

Yanmin

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Re: [PATCHv8 3/3] vhost_net: a kernel-level virtio server

2009-11-08T22:17:29Z

On Sun, 8 Nov 2009 10:05:16 pm Michael S. Tsirkin wrote:

> On Fri, Nov 06, 2009 at 03:29:17PM +1030, Rusty Russell wrote:
> > > +/* Caller must have TX VQ lock */
> > > +static void tx_poll_stop(struct vhost_net *net)
> > > +{
> > > + if (likely(net->tx_poll_state != VHOST_NET_POLL_STARTED))
> > > + return;
> >
> > likely? Really?
>
> Hmm ... yes. tx poll stop is called on each packet (as long as we do not
> fill up 1/2 backend queue), the first call will stop polling
> the rest checks state and does nothing.
>
> This is because we normally do not care when the message has left the
> queue in backend device: we tell backend to send it and forget. We only
> start polling when backend tx queue fills up.

OK, good.

> > > +static void vhost_net_set_features(struct vhost_net *n, u64 features)
> > > +{
> > > + size_t hdr_size = features & (1 << VHOST_NET_F_VIRTIO_NET_HDR) ?
> > > + sizeof(struct virtio_net_hdr) : 0;
> > > + int i;
> > > + mutex_lock(&n->dev.mutex);
> > > + n->dev.acked_features = features;
> >
> > Why is this called "acked_features"? Not just "features"? I expected
> > to see code which exposed these back to userspace, and didn't.
>
> Not sure how do you mean. Userspace sets them, why
> does it want to get them exposed back?

There's something about the 'acked' which rubs me the wrong way.
"enabled_features" is perhaps a better term than "acked_features"; "acked"
seems more a user point-of-view, "enabled" seems more driver POV?

set_features matches your ioctl names, but it sounds like a fn name :(

It's marginal. And 'features' is shorter than both.

> > > + switch (ioctl) {
> > > + case VHOST_SET_VRING_NUM:
> >
> > I haven't looked at your userspace implementation, but does a generic
> > VHOST_SET_VRING_STATE & VHOST_GET_VRING_STATE with a struct make more
> > sense? It'd be simpler here,
>
> Not by much though, right?
>
> > but not sure if it'd be simpler to use?
>
> The problem is with VHOST_SET_VRING_BASE as well. I want it to be
> separate because I want to make it possible to relocate e.g. used ring
> to another address while ring is running. This would be a good debugging
> tool (you look at kernel's used ring, check descriptor, then update
> guest's used ring) and also possibly an extra way to do migration. And
> it's nicer to have vring size separate as well, because it is
> initialized by host and never changed, right?

Actually, this looks wrong to me:

+ case VHOST_SET_VRING_BASE:
...
+ vq->avail_idx = vq->last_avail_idx = s.num;

The last_avail_idx is part of the state of the driver. It needs to be saved
and restored over susp/resume. The only reason it's not in the ring itself
is because I figured the other side doesn't need to see it (which is true, but
missed debugging opportunities as well as man-in-the-middle issues like this
one). I had a patch which put this field at the end of the ring, I might
resurrect it to avoid this problem. This is backwards compatible with all
implementations. See patch at end.

I would drop avail_idx altogether: get_user is basically free, and simplifies
a lot. As most state is in the ring, all you need is an ioctl to save/restore
the last_avail_idx.

> We could merge DESC, AVAIL, USED, and it will reduce the amount of code
> in userspace. With both base, size and fds separate, it seemed a bit
> more symmetrical to have desc/avail/used separate as well.
> What's your opinion?

Well, DESC, AVAIL, and USED could easily be turned into SET/GET_LAYOUT.

> > For future reference, this is *exactly* the kind of thing which would have
> > been nice as a followup patch. Easy to separate, easy to review, not critical
> > to the core.
>
> Yes. It's not too late to split it out though: should I do it yet?

Only if you're feeling enthused. It's lightly reviewed now.

Cheers,
Rusty.

virtio: put last_used and last_avail index into ring itself.

Generally, the other end of the virtio ring doesn't need to see where
you're up to in consuming the ring. However, to completely understand
what's going on from the outside, this information must be exposed.
For example, if you want to save and restore a virtio_ring, but you're
not the consumer because the kernel is using it directly.

Fortunately, we have room to expand: the ring is always a whole number
of pages and there's hundreds of bytes of padding after the avail ring
and the used ring, whatever the number of descriptors (which must be a
power of 2).

We add a feature bit so the guest can tell the host that it's writing
out the current value there, if it wants to use that.

Signed-off-by: Rusty Russell <rusty@...>
---
drivers/virtio/virtio_ring.c | 23 +++++++++++++++--------
include/linux/virtio_ring.h | 12 +++++++++++-
2 files changed, 26 insertions(+), 9 deletions(-)

diff --git a/drivers/virtio/virtio_ring.c b/drivers/virtio/virtio_ring.c
--- a/drivers/virtio/virtio_ring.c
+++ b/drivers/virtio/virtio_ring.c
@@ -71,9 +71,6 @@ struct vring_virtqueue
/* Number we've added since last sync. */
unsigned int num_added;

- /* Last used index we've seen. */
- u16 last_used_idx;
-
/* How to notify other side. FIXME: commonalize hcalls! */
void (*notify)(struct virtqueue *vq);

@@ -278,12 +275,13 @@ static void detach_buf(struct vring_virt

static inline bool more_used(const struct vring_virtqueue *vq)
{
- return vq->last_used_idx != vq->vring.used->idx;
+ return vring_last_used(&vq->vring) != vq->vring.used->idx;
}

static void *vring_get_buf(struct virtqueue *_vq, unsigned int *len)
{
struct vring_virtqueue *vq = to_vvq(_vq);
+ struct vring_used_elem *u;
void *ret;
unsigned int i;

@@ -300,8 +298,11 @@ static void *vring_get_buf(struct virtqu
return NULL;
}

- i = vq->vring.used->ring[vq->last_used_idx%vq->vring.num].id;
- *len = vq->vring.used->ring[vq->last_used_idx%vq->vring.num].len;
+ u = &vq->vring.used->ring[vring_last_used(&vq->vring) % vq->vring.num];
+ i = u->id;
+ *len = u->len;
+ /* Make sure we don't reload i after doing checks. */
+ rmb();

if (unlikely(i >= vq->vring.num)) {
BAD_RING(vq, "id %u out of range\n", i);
@@ -315,7 +316,8 @@ static void *vring_get_buf(struct virtqu
/* detach_buf clears data, so grab it now. */
ret = vq->data[i];
detach_buf(vq, i);
- vq->last_used_idx++;
+ vring_last_used(&vq->vring)++;
+
END_USE(vq);
return ret;
}
@@ -402,7 +404,6 @@ struct virtqueue *vring_new_virtqueue(un
vq->vq.name = name;
vq->notify = notify;
vq->broken = false;
- vq->last_used_idx = 0;
vq->num_added = 0;
list_add_tail(&vq->vq.list, &vdev->vqs);
#ifdef DEBUG
@@ -413,6 +414,10 @@ struct virtqueue *vring_new_virtqueue(un

vq->indirect = virtio_has_feature(vdev, VIRTIO_RING_F_INDIRECT_DESC);

+ /* We publish indices whether they offer it or not: if not, it's junk
+ * space anyway. But calling this acknowledges the feature. */
+ virtio_has_feature(vdev, VIRTIO_RING_F_PUBLISH_INDICES);
+
/* No callback? Tell other side not to bother us. */
if (!callback)
vq->vring.avail->flags |= VRING_AVAIL_F_NO_INTERRUPT;
@@ -443,6 +448,8 @@ void vring_transport_features(struct vir
switch (i) {
case VIRTIO_RING_F_INDIRECT_DESC:
break;
+ case VIRTIO_RING_F_PUBLISH_INDICES:
+ break;
default:
/* We don't understand this bit. */
clear_bit(i, vdev->features);
diff --git a/include/linux/virtio_ring.h b/include/linux/virtio_ring.h
--- a/include/linux/virtio_ring.h
+++ b/include/linux/virtio_ring.h
@@ -29,6 +29,9 @@
/* We support indirect buffer descriptors */
#define VIRTIO_RING_F_INDIRECT_DESC 28

+/* We publish our last-seen used index at the end of the avail ring. */
+#define VIRTIO_RING_F_PUBLISH_INDICES 29
+
/* Virtio ring descriptors: 16 bytes. These can chain together via "next". */
struct vring_desc
{
@@ -87,6 +90,7 @@ struct vring {
* __u16 avail_flags;
* __u16 avail_idx;
* __u16 available[num];
+ * __u16 last_used_idx;
*
* // Padding to the next align boundary.
* char pad[];
@@ -95,6 +99,7 @@ struct vring {
* __u16 used_flags;
* __u16 used_idx;
* struct vring_used_elem used[num];
+ * __u16 last_avail_idx;
* };
*/
static inline void vring_init(struct vring *vr, unsigned int num, void *p,
@@ -111,9 +116,14 @@ static inline unsigned vring_size(unsign
{
return ((sizeof(struct vring_desc) * num + sizeof(__u16) * (2 + num)
+ align - 1) & ~(align - 1))
- + sizeof(__u16) * 2 + sizeof(struct vring_used_elem) * num;
+ + sizeof(__u16) * 2 + sizeof(struct vring_used_elem) * num + 2;
}

+/* We publish the last-seen used index at the end of the available ring, and
+ * vice-versa. These are at the end for backwards compatibility. */
+#define vring_last_used(vr) ((vr)->avail->ring[(vr)->num])
+#define vring_last_avail(vr) (*(__u16 *)&(vr)->used->ring[(vr)->num])
+
#ifdef __KERNEL__
#include <linux/irqreturn.h>
struct virtio_device;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

[PATCH percpu#for-linus] percpu: fix possible deadlock via irq lock inversion

2009-11-08T21:46:52Z

Lockdep caught the following irq lock inversion which can lead to
deadlock.

=========================================================
[ INFO: possible irq lock inversion dependency detected ]
2.6.32-rc5-tip-04815-g12f0f93-dirty #745
---------------------------------------------------------
hub 1-3:1.0: state 7 ports 2 chg 0000 evt 0004
ksoftirqd/65/199 just changed the state of lock:
(pcpu_lock){..-...}, at: [<ffffffff81130e04>] free_percpu+0x38/0x104
but this lock took another, SOFTIRQ-unsafe lock in the past:
(vmap_area_lock){+.+...}

and interrupts could create inverse lock ordering between them.

This happens because pcpu_lock is allowed to be acquired from irq
context for free_percpu() path and alloc_percpu() path may call
vfree() with pcpu_lock held. As vmap_area_lock isn't irq safe, if an
IRQ occurs while vmap_area_lock is held and the irq handler calls
free_percpu(), locking order inversion occurs.

As the nesting only occurs in the alloc path which isn't allowed to be
called from irq context, A->B->A deadlock won't occur but A->B B->A
deadlock is still possible.

The only place where vmap_area_lock is nested under pcpu_lock is while
extending area_map to free old map. Break the locking order by
temporarily releasing pcpu_lock when freeing old map. This is safe to
do as allocation path is protected with outer pcpu_alloc_mutex.

Signed-off-by: Tejun Heo <tj@...>
Reported-by: Yinghai Lu <yhlu.kernel@...>
Cc: Ingo Molnar <mingo@...>
---
If nobody objects, I'll push it to Linus tomorrow. Thanks.

mm/percpu.c | 17 +++++++++++++++--
1 file changed, 15 insertions(+), 2 deletions(-)

diff --git a/mm/percpu.c b/mm/percpu.c
index d907971..30cd343 100644
--- a/mm/percpu.c
+++ b/mm/percpu.c
@@ -372,7 +372,7 @@ static struct pcpu_chunk *pcpu_chunk_addr_search(void *addr)
static int pcpu_extend_area_map(struct pcpu_chunk *chunk, unsigned long *flags)
{
int new_alloc;
- int *new;
+ int *new, *old = NULL;
size_t size;

/* has enough? */
@@ -407,10 +407,23 @@ static int pcpu_extend_area_map(struct pcpu_chunk *chunk, unsigned long *flags)
* one of the first chunks and still using static map.
*/
if (chunk->map_alloc >= PCPU_DFL_MAP_ALLOC)
- pcpu_mem_free(chunk->map, size);
+ old = chunk->map;

chunk->map_alloc = new_alloc;
chunk->map = new;
+
+ /*
+ * pcpu_mem_free() might end up calling vfree() which uses
+ * IRQ-unsafe lock and thus can't be called with pcpu_lock
+ * held. Release and reacquire pcpu_lock if old map needs to
+ * be freed.
+ */
+ if (old) {
+ spin_unlock_irqrestore(&pcpu_lock, *flags);
+ pcpu_mem_free(old, size);
+ spin_lock_irqsave(&pcpu_lock, *flags);
+ }
+
return 0;
}

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Re: [PATCH 22/23] sysctl arm: Remove binary sysctl support

2009-11-08T21:37:58Z

Arjan van de Ven <arjan@...> writes:

> On Sun, 08 Nov 2009 19:27:07 -0800
> ebiederm@... (Eric W. Biederman) wrote:
>
>> I just took a look and the use in linux threads that I don't warn
>> about is used by glibc-2.8 but not by glibc-2.10. glibc-2.11 has just
>> been released. so by next year when the removal is scheduled we are
>> looking at multiple releases of glibc that don't use sys_sysctl. So I
>> expect shortly I can warn about all uses of sys_sysctl without anyone
>> seeing a warning.
>
> hmmmmm it's still an ABI break, and while you say "oh it's 3 glibcs
> ago".. there's the static linking case.
>
> to be honest, I don't think we can ever remove things that are used by
> glibc during its startup....

The glibc pthread code that uses sysctl has no problems if sys_sysctl
is gone. It both falls back to reading /proc/sys and it just controls
an optimization and the code works with either result. Been there,
done that.

The only reason sys_sysctl remains is because there are a handful of
other apps that needed an appropriate warning time, and we weren't
doing anything that had a reasonable chance of notifying them.

I think it is worth getting us to the point where we can run with
sysctl disabled. At the same time, this patchset gets 99%+ of the
benefit. It isolates the entire binary interface into sysctl_binary.c
so outside of that one file we have no maintenance overhead in
maintaining the binary interface, and anyone who is trying to optimize
for kernel size can trivially turn it off.

Which allows the kernel development to proceed as if the sysctl binary
interface does not exist, as it has largely always done.

Eric
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

[GIT]: Networking

2009-11-08T21:32:08Z

1) Wireless fixes, including a revert for something that added as
many bugs as it fixed. Via John Linville.

2) Rose and DecNET leaks device references. CAN protocol doesn't
lock device list accesses properly. All from Eric Dumazet.

3) TX of ixgbe can hang with ioatdma loded, fix from Don Skidmore.

4) be2net fixes for flow control programming on resume, the timing
of sending configuration commands to the chip, and a broken
status shift macro define, from Ajit Khaparde and Sathya Perla.

5) A queue of ISDN fixes via Andrew Morton.

6) Two netfilter bug fixes (Patrick McHardy has been offline for a month
or so these are the only two netfilter fixes that have gone in in
that time), from Jan Engelhardt and Jozsef Kadlecsik.

7) When PMTU discovery is off, we handle DF packets improperly in
IPIP tunnel driver. Fix from Herbert Xu.

8) fsl_pq_mdio is missing MODULE_LICENSE() tag, from Sebastian Siewior.

9) virtio_net section mismatch fix from Uwe Kleine-König.

10) IXGBE uses wrong gso_max_size on 82599 chips when DCB is enabled.
It also checks TXOFF status incorrectly when DCB is enabled. Both
fixed from Yi Zou.

11) CAN protocol needs to provide ->get_size() operation otherwise
netlink SKBs aren't sized for it correctly. From Wolfgang
Grandegger.

Please pull, thanks a lot.

The following changes since commit 7c9abfb884b8737f0afdc8a88bcea77526f0da87:
Linus Torvalds (1):
Merge branch 'kvm-updates/2.6.32' of git://git.kernel.org/pub/scm/virt/kvm/kvm

are available in the git repository at:

master.kernel.org:/pub/scm/linux/kernel/git/davem/net-2.6.git master

Ajit Khaparde (2):
be2net: fix to set proper flow control on resume
be2net: Bug fix to send config commands to hardware after netdev_register

Dan Carpenter (1):
misdn: Fix reversed 'if' in st_own_ctrl

David S. Miller (1):
Merge branch 'master' of git://git.kernel.org/.../linville/wireless-2.6

Don Skidmore (1):
ixgbe: fix traffic hangs on Tx with ioatdma loaded

Eric Dumazet (3):
rose: device refcount leak
decnet: netdevice refcount leak
can: should not use __dev_get_by_index() without locks

Finn Thain (1):
macsonic: fix crash on PowerBook 520

Herbert Xu (1):
ipip: Fix handling of DF packets when pmtudisc is OFF

Jan Engelhardt (1):
netfilter: xt_connlimit: fix regression caused by zero family value

Jiri Slaby (4):
isdn: hisax: Fix lock imbalance.
isdn: eicon: Use offsetof
isdn: eicon: Return on error
NET: cassini, fix lock imbalance

Joe Perches (1):
MAINTAINERS: Add git net-next-2.6

John W. Linville (1):
Revert "ipw2200: fix oops on missing firmware"

Jozsef Kadlecsik (1):
netfilter: nf_nat: fix NAT issue in 2.6.30.4+

Larry Finger (1):
rtl8187: Fix kernel oops when device is removed when LEDS enabled

Martin Michlmayr (1):
hisax: remove bad udelay call to fix build error on ARM

Roel Kluin (2):
isdn: hisax: Fix test in waitforxfw
isdn: hfc_usb: Fix read buffer overflow

Ron Mercer (2):
qlge: Fix early exit from mbox cmd complete wait.
qlge: Set PCIe reset type for EEH to fundamental.

Sathya Perla (1):
be2net: Fix CQE_STATUS_EXTD_SHIFT define

Sean Cross (1):
rt2x00: Don't queue ieee80211 work after USB removal

Sebastian Haas (1):
ems_usb: Fix byte order issues on big endian machines

Sebastian Siewior (1):
net/fsl_pq_mdio: add module license GPL

Stephen Hemminger (1):
bridge: prevent bridging wrong device

Tonyliu (1):
DaVinci EMAC: correct param for ISR

Torgny Johansson (1):
cdc_ether: additional Ericsson MBM PID's to the whitelist

Uwe Kleine-König (1):
virtio_net: rename driver struct to please modpost

Wolfgang Grandegger (1):
can: fix WARN_ON dump in net/core/rtnetlink.c:rtmsg_ifinfo()

Yi Zou (2):
ixgbe: Fix gso_max_size for 82599 when DCB is enabled
ixgbe: Fix checking TFCS register for TXOFF status when DCB is enabled

MAINTAINERS | 1 +
drivers/isdn/hardware/eicon/maintidi.c | 5 +-
drivers/isdn/hardware/eicon/message.c | 18 ++--
drivers/isdn/hisax/amd7930_fn.c | 1 +
drivers/isdn/hisax/diva.c | 2 +-
drivers/isdn/hisax/elsa_ser.c | 22 +++---
drivers/isdn/hisax/hfc_usb.c | 4 +-
drivers/isdn/hisax/hscx_irq.c | 2 +-
drivers/isdn/hisax/icc.c | 1 +
drivers/isdn/mISDN/stack.c | 2 +-
drivers/net/benet/be.h | 2 +
drivers/net/benet/be_cmds.h | 2 +-
drivers/net/benet/be_ethtool.c | 8 +-
drivers/net/benet/be_main.c | 28 ++++---
drivers/net/can/dev.c | 17 ++++
drivers/net/can/usb/ems_usb.c | 5 +-
drivers/net/cassini.c | 5 +-
drivers/net/davinci_emac.c | 2 +-
drivers/net/fsl_pq_mdio.c | 1 +
drivers/net/ixgbe/ixgbe_main.c | 84 +++++++++++++++++--
drivers/net/macsonic.c | 117 +++++++++++++-------------
drivers/net/qlge/qlge_main.c | 2 +
drivers/net/qlge/qlge_mpi.c | 2 +-
drivers/net/usb/Kconfig | 2 +-
drivers/net/usb/cdc_ether.c | 42 +++++++++-
drivers/net/virtio_net.c | 6 +-
drivers/net/wireless/ipw2x00/ipw2100.c | 5 +-
drivers/net/wireless/ipw2x00/ipw2200.c | 2 -
drivers/net/wireless/ipw2x00/libipw.h | 1 -
drivers/net/wireless/ipw2x00/libipw_module.c | 14 +--
drivers/net/wireless/rt2x00/rt2x00dev.c | 4 +-
drivers/net/wireless/rt2x00/rt2x00link.c | 11 ++-
drivers/net/wireless/rt2x00/rt2x00usb.c | 9 ++-
drivers/net/wireless/rtl818x/rtl8187_leds.c | 4 +-
include/net/netfilter/nf_conntrack.h | 8 +-
include/net/netfilter/nf_nat_helper.h | 4 +
net/bridge/br_if.c | 6 +-
net/can/bcm.c | 19 +++--
net/decnet/sysctl_net_decnet.c | 7 +-
net/ipv4/ipip.c | 32 ++++----
net/ipv4/netfilter/nf_nat_core.c | 3 +
net/ipv4/netfilter/nf_nat_helper.c | 34 +++++---
net/netfilter/nf_conntrack_core.c | 8 ++
net/netfilter/nf_conntrack_proto_tcp.c | 64 ++++++--------
net/netfilter/xt_connlimit.c | 10 +--
net/rose/rose_route.c | 16 ++--
46 files changed, 407 insertions(+), 237 deletions(-)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

[GIT]: Sparc

2009-11-08T21:31:38Z

Fix a locking bug pointed out by Thomas Gleixner and clarify some
aspects of our sparc64 barriers.

Please pull, thanks a lot.

The following changes since commit 2e2ec952350f25242f2e0539db16b1e46f9eb01b:
Linus Torvalds (1):
Merge branch 'bugfix' of git://git.kernel.org/.../jeremy/xen

are available in the git repository at:

master.kernel.org:/pub/scm/linux/kernel/git/davem/sparc-2.6.git master

David S. Miller (2):
sparc64: Add a comment about why we only use certain memory barriers these days.
sparc: Move of_set_property_mutex acquisition outside of devtree_lock grab.

Roel Kluin (1):
sparc64: replace parentheses in pmul()

arch/sparc/include/asm/system_64.h | 4 ++++
arch/sparc/kernel/prom_common.c | 4 ++--
arch/sparc/kernel/visemul.c | 2 +-
3 files changed, 7 insertions(+), 3 deletions(-)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

[GIT]: IDE

2009-11-08T21:30:55Z

The revert we thought we didn't need, we really do need still, even
with Bart Z.'s fix.

The issue is that we are doing these PIO setting calls before we did
the device probe and therefore we don't yet know the media type.

Yet the ->set_pio_mode() of some drivers key off of the media type to
determine whether to turn prefetching etc. on so it can't possibly
work properly.

Please pull, thanks!

The following changes since commit 7c9abfb884b8737f0afdc8a88bcea77526f0da87:
Linus Torvalds (1):
Merge branch 'kvm-updates/2.6.32' of git://git.kernel.org/pub/scm/virt/kvm/kvm

are available in the git repository at:

master.kernel.org:/pub/scm/linux/kernel/git/davem/ide-2.6.git master

David S. Miller (1):
Revert "ide: try to use PIO Mode 0 during probe if possible"

drivers/ide/ide-probe.c | 9 ---------
1 files changed, 0 insertions(+), 9 deletions(-)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Re: [patch 09/16] powerpc: Replace old style lock initializer

2009-11-08T21:15:02Z

Hi Thomas,

On Sat, 07 Nov 2009 09:55:44 +1100 Benjamin Herrenschmidt <benh@...> wrote:

>
> On Fri, 2009-11-06 at 22:41 +0000, Thomas Gleixner wrote:
> > plain text document attachment
> > (power-replace-old-style-lock-init.patch)
> > SPIN_LOCK_UNLOCKED is deprecated. Init the lock array at runtime
> > instead.
> >
> > Signed-off-by: Thomas Gleixner <tglx@...>
> > Cc: Benjamin Herrenschmidt <benh@...>
> > Cc: linuxppc-dev@...
> > ---
>
> Looks reasonable. But iseries can be a bitch, so we do need to test it
> on monday.

Tested-by: Stephen Rothwell <sfr@...>
--
Cheers,
Stephen Rothwell sfr@...
http://www.canb.auug.org.au/~sfr/

_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@...
https://lists.ozlabs.org/listinfo/linuxppc-dev

attachment0 (205 bytes) Download Attachment

Re: [RFC] Mount point suggestions for cgroup

2009-11-08T21:05:18Z

* Pavel Machek <pavel@...> [2009-11-08 18:05:12]:

> On Wed 2009-11-04 12:00:05, Balbir Singh wrote:
> > Hi, All,
> >
> > We've been having a discussion as to what would be the right place to
> > mount the cgroup filesystem. Jan has been proactively looking into
> > this. The FHS has no recommendation since cgroup filesystem came in
> > much later.
> >
> > The options are
> >
> > 1. /dev/cgroup
> > 2. /cgroup
> > 3. Some place under /sys
>
> Underr /sys, please. Actually I wonder that it may even belong /proc
> ... It *is* process related, right?
>

We already have /proc/cgroups for showing currently supported
subsystems and /proc/pid/cgroups to show which subsystems/tasks

--
Balbir
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Re: linux-next: manual merge of the net tree with the net-current tree

2009-11-08T20:59:11Z

From: Stephen Rothwell <sfr@...>
Date: Mon, 9 Nov 2009 13:03:23 +1100

> Hi all,
>
> Today's linux-next merge of the net tree got a conflict in
> drivers/net/can/usb/ems_usb.c between commit
> 2b2072e902848a63168570f500a5726744b3873a ("ems_usb: Fix byte order issues
> on big endian machines") from the net-current tree and commit
> 7b6856a0296a8f187bb88ba31fa83a08abba7966 ("can: provide library functions
> for skb allocation") from the net tree.
>
> Just context changes. I fixed it up (see below) and can carry the fix
> for a while.

I'll do a merge and resolve this, thanks Stephen!
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Re: [PATCH 22/23] sysctl arm: Remove binary sysctl support

2009-11-08T20:57:25Z

On Sun, 08 Nov 2009 19:27:07 -0800
ebiederm@... (Eric W. Biederman) wrote:

> I just took a look and the use in linux threads that I don't warn
> about is used by glibc-2.8 but not by glibc-2.10. glibc-2.11 has just
> been released. so by next year when the removal is scheduled we are
> looking at multiple releases of glibc that don't use sys_sysctl. So I
> expect shortly I can warn about all uses of sys_sysctl without anyone
> seeing a warning.

hmmmmm it's still an ABI break, and while you say "oh it's 3 glibcs
ago".. there's the static linking case.

to be honest, I don't think we can ever remove things that are used by
glibc during its startup....

--
Arjan van de Ven Intel Open Source Technology Centre
For development, discussion and tips for power savings,
visit http://www.lesswatts.org
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Re: [PATCH 2/2] net/compat_ioctl: support SIOCWANDEV

2009-11-08T20:57:11Z

From: Arnd Bergmann <arnd@...>
Date: Sun, 8 Nov 2009 22:39:24 +0100

> This adds compat_ioctl support for SIOCWANDEV, which has
> always been missing.
>
> The definition of struct compat_ifreq was missing an
> ifru_settings fields that is needed to support SIOCWANDEV,
> so add that and clean up the whitespace damage in the
> struct definition.
>
> Signed-off-by: Arnd Bergmann <arnd@...>

Applied, thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Re: [PATCH 1/2] net, compat_ioctl: fix SIOCGMII ioctls

2009-11-08T20:56:30Z

From: Arnd Bergmann <arnd@...>
Date: Sun, 8 Nov 2009 22:34:13 +0100

> SIOCGMIIPHY and SIOCGMIIREG return data through ifreq,
> so it needs to be converted on the way out as well.
>
> SIOCGIFPFLAGS is unused, but has the same problem in theory.
>
> Signed-off-by: Arnd Bergmann <arnd@...>

Applied.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Re: [RFC, PATCH 0/7] net, compat_ioctl: move handlers to net/socket.c

2009-11-08T20:55:46Z

From: Arnd Bergmann <arnd@...>
Date: Sun, 8 Nov 2009 22:31:47 +0100

> Any opinion on how to proceed with the ATM stuff? From my
> point of view, I'm fine with having moved it out of fs/compat_ioctl.c,
> but it's still a bit silly to have two half-complete implementations.

I haven't looked at that stuff yes, you can be sure it's in
my queue :-)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

linux-next: manual merge of the trivial tree with the tree

2009-11-08T20:43:05Z

Hi Jiri,

Today's linux-next merge of the trivial tree got a conflict in
drivers/net/wireless/rt2x00/rt2800usb.c between commit
fcf5154118849cca3cdf424e83f863225d8173e7 ("rt2800: add rt2800lib (part
three)") from the wireless tree and commit
305409a25f7df3c359ba67cbeb62763eeb7156e9 ("tree-wide: fix some typos and
punctuation in comments") from the trivial tree.

The misspelling is moved to a new file
(drivers/net/wireless/rt2x00/rt2800lib.c), but I didn't bother fixing it up.
--
Cheers,
Stephen Rothwell sfr@...
http://www.canb.auug.org.au/~sfr/

attachment0 (205 bytes) Download Attachment

Re: linux-next: net tree build failure

2009-11-08T20:41:16Z

From: Stephen Rothwell <sfr@...>
Date: Mon, 9 Nov 2009 13:21:51 +1100

> Subject: [PATCH] net/appletalk: using compat_ptr needs inclusion of linux/compat.h
>
> Signed-off-by: Stephen Rothwell <sfr@...>

Applied, thanks Stephen.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Re: [PATCH -v5 08/11] tracing: not trace mips_timecounter_init() in MIPS

2009-11-08T20:31:12Z

Hi,

On Mon, 2009-11-02 at 22:43 +0100, Frederic Weisbecker wrote:
[...]

> > >
> > > But I would rather see a __mips_notrace on these two core functions.
> >
> > What about this: __arch_notrace? If the arch need this, define it,
> > otherwise, ignore it! if only graph tracer need it, define it in "#ifdef
> > CONFIG_FUNCTION_GRAPH_TRACER ... #endif".
>
>
>
> The problem is that archs may want to disable tracing on different
> places.
> For example mips wants to disable tracing in timecounter_read_delta,
> but another arch may want to disable tracing somewhere else.
>
> We'll then have several unrelated __arch_notrace. One that is relevant
> for mips, another that is relevant for arch_foo, but all of them will
> apply for all arch that have defined a __arch_notrace.
>
> It's true that __mips_notrace is not very elegant as it looks like
> a specific arch annotation intruder.
>
>
> But at least that gives us a per arch filter granularity.
>
> If only static ftrace could disappear, we could keep only dynamic
> ftrace and we would then be able to filter dynamically.
> But I'm not sure it's a good idea for archs integration.
>

I think if we use something like __mips_notrace here, we may get lots of
__ARCH_notraces here too, 'Cause some other platforms(at least, as I
know, Microblaze will do it too) may also need to add one here, it will
become:

__mips_notrace __ARCH1_notrace __ARCH2_notrace .... foo() {...}

A little ugly ;)

and If a new platform need it's __ARCH_notrace, they need to touch the
common part of ftrace, more side-effects!

but with __arch_notrace, the archs only need to touch it's own part,
Although there is a side-effect as you mentioned above ;)

So, what should we do?

Regards,
Wu Zhangjin

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

[PATCH v3] x86: under bios control, restore AP's APIC_LVTTHMR to the BSP value

2009-11-08T20:21:34Z

Changes since v2:
Incorporate Ingo's comments to get BSP's thermal init value in a
'boot-CPU-only' function.

---

On platforms where bios handles the thermal monitor interrupt,
APIC_LVTTHMR on each logical CPU is programmed to generate a SMI and OS
can't touch it.

Unfortunately AP bringup sequence using INIT-SIPI-SIPI clear all
the LVT entries except the mask bit. Essentially this results in
all LVT entries including the thermal monitoring interrupt set to masked
(clearing the bios programmed value for APIC_LVTTHMR).

And this leads to kernel take over the thermal monitoring interrupt
on AP's but not on BSP (leaving the bios programmed value only on BSP).

As a result of this, we have seen system hangs when the thermal
monitoring interrupt is generated.

Fix this by reading the initial value of thermal LVT entry on BSP
and if bios has taken over the control, then program the same value
on all AP's and leave the thermal monitoring interrupt control
on all the logical cpu's to the bios.

Signed-off-by: Yong Wang <yong.y.wang@...>
Cc: stable@...
---
arch/x86/include/asm/apic.h | 6 ++++++
arch/x86/kernel/cpu/mcheck/therm_throt.c | 27 ++++++++++++++++++++++++++-
arch/x86/kernel/setup.c | 1 +
3 files changed, 33 insertions(+), 1 deletion(-)

diff --git a/arch/x86/include/asm/apic.h b/arch/x86/include/asm/apic.h
index 474d80d..97ea588 100644
--- a/arch/x86/include/asm/apic.h
+++ b/arch/x86/include/asm/apic.h
@@ -594,4 +594,10 @@ static inline physid_mask_t default_apicid_to_cpu_present(int phys_apicid)
extern u8 cpu_2_logical_apicid[NR_CPUS];
#endif

+#ifdef CONFIG_X86_THERMAL_VECTOR
+extern void get_bsp_lvtthmr_init(void);
+#else
+static inline void get_bsp_lvtthmr_init(void) { }
+#endif
+
#endif /* _ASM_X86_APIC_H */
diff --git a/arch/x86/kernel/cpu/mcheck/therm_throt.c b/arch/x86/kernel/cpu/mcheck/therm_throt.c
index b3a1dba..55c5995 100644
--- a/arch/x86/kernel/cpu/mcheck/therm_throt.c
+++ b/arch/x86/kernel/cpu/mcheck/therm_throt.c
@@ -49,6 +49,8 @@ static DEFINE_PER_CPU(struct thermal_state, thermal_state);

static atomic_t therm_throt_en = ATOMIC_INIT(0);

+static u32 lvtthmr_init __read_mostly;
+
#ifdef CONFIG_SYSFS
#define define_therm_throt_sysdev_one_ro(_name) \
static SYSDEV_ATTR(_name, 0444, therm_throt_sysdev_show_##_name, NULL)
@@ -254,6 +256,16 @@ asmlinkage void smp_thermal_interrupt(struct pt_regs *regs)
ack_APIC_irq();
}

+void get_bsp_lvtthmr_init(void)
+{
+ /*
+ * This function is only called on boot CPU. Save the init thermal
+ * LVT value on BSP and use that value to restore APs' thermal LVT
+ * entry BIOS programmed later
+ */
+ lvtthmr_init = apic_read(APIC_LVTTHMR);
+}
+
void intel_init_thermal(struct cpuinfo_x86 *c)
{
unsigned int cpu = smp_processor_id();
@@ -270,7 +282,20 @@ void intel_init_thermal(struct cpuinfo_x86 *c)
* since it might be delivered via SMI already:
*/
rdmsr(MSR_IA32_MISC_ENABLE, l, h);
- h = apic_read(APIC_LVTTHMR);
+
+ /*
+ * The initial value of thermal LVT entries on all APs always reads
+ * 0x10000 because APs are woken up by BSP issuing INIT-SIPI-SIPI
+ * sequence to them and LVT registers are reset to 0s except for
+ * the mask bits which are set to 1s when APs receive INIT IPI.
+ * Always restore the value that BIOS has programmed on AP based on
+ * BSP's info we saved since BIOS is always setting the same value
+ * for all threads/cores
+ */
+ apic_write(APIC_LVTTHMR, lvtthmr_init);
+
+ h = lvtthmr_init;
+
if ((l & MSR_IA32_MISC_ENABLE_TM1) && (h & APIC_DM_SMI)) {
printk(KERN_DEBUG
"CPU%d: Thermal monitoring handled by SMI\n", cpu);
diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
index e09f0e2..2323771 100644
--- a/arch/x86/kernel/setup.c
+++ b/arch/x86/kernel/setup.c
@@ -1002,6 +1002,7 @@ void __init setup_arch(char **cmdline_p)

init_apic_mappings();
ioapic_init_mappings();
+ get_bsp_lvtthmr_init();

/* need to wait for io_apic is mapped */
probe_nr_irqs_gsi();
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Re: [PATCH -v6 08/13] tracing: add IRQENTRY_EXIT section for MIPS

2009-11-08T20:16:36Z

Hi Ralf,

This one is also MIPS relative, also need your feedback ;)

Thanks & Regards,
Wu Zhangjin

On Mon, 2009-10-26 at 23:13 +0800, Wu Zhangjin wrote:

> This patch add a new section for MIPS to record the block of the hardirq
> handling for function graph tracer(print_graph_irq) via adding the
> __irq_entry annotation to the the entrypoints of the hardirqs(the block
> with irq_enter()...irq_exit()).
>
> Thanks goes to Steven & Frederic Weisbecker for their feedbacks.
>
> Signed-off-by: Wu Zhangjin <wuzhangjin@...>
> ---
> arch/mips/include/asm/irq.h | 29 ++---------------------------
> arch/mips/kernel/irq.c | 34 ++++++++++++++++++++++++++++++++++
> arch/mips/kernel/smp.c | 3 ++-
> arch/mips/kernel/smtc.c | 21 ++++++++++++++-------
> arch/mips/kernel/vmlinux.lds.S | 1 +
> arch/mips/sgi-ip22/ip22-int.c | 3 ++-
> arch/mips/sgi-ip22/ip22-time.c | 3 ++-
> 7 files changed, 57 insertions(+), 37 deletions(-)
>
> diff --git a/arch/mips/include/asm/irq.h b/arch/mips/include/asm/irq.h
> index 09b08d0..6cdd8c2 100644
> --- a/arch/mips/include/asm/irq.h
> +++ b/arch/mips/include/asm/irq.h
> @@ -113,36 +113,11 @@ do { \
>
> #endif
>
> -/*
> - * do_IRQ handles all normal device IRQ's (the special
> - * SMP cross-CPU interrupts have their own specific
> - * handlers).
> - *
> - * Ideally there should be away to get this into kernel/irq/handle.c to
> - * avoid the overhead of a call for just a tiny function ...
> - */
> -#define do_IRQ(irq) \
> -do { \
> - irq_enter(); \
> - __DO_IRQ_SMTC_HOOK(irq); \
> - generic_handle_irq(irq); \
> - irq_exit(); \
> -} while (0)
> +extern unsigned int do_IRQ(unsigned int irq);
>
> #ifdef CONFIG_MIPS_MT_SMTC_IRQAFF
> -/*
> - * To avoid inefficient and in some cases pathological re-checking of
> - * IRQ affinity, we have this variant that skips the affinity check.
> - */
> -
>
> -#define do_IRQ_no_affinity(irq) \
> -do { \
> - irq_enter(); \
> - __NO_AFFINITY_IRQ_SMTC_HOOK(irq); \
> - generic_handle_irq(irq); \
> - irq_exit(); \
> -} while (0)
> +extern unsigned int do_IRQ_no_affinity(unsigned int irq);
>
> #endif /* CONFIG_MIPS_MT_SMTC_IRQAFF */
>
> diff --git a/arch/mips/kernel/irq.c b/arch/mips/kernel/irq.c
> index 7b845ba..c10ea8f 100644
> --- a/arch/mips/kernel/irq.c
> +++ b/arch/mips/kernel/irq.c
> @@ -22,6 +22,7 @@
> #include <linux/seq_file.h>
> #include <linux/kallsyms.h>
> #include <linux/kgdb.h>
> +#include <linux/ftrace.h>
>
> #include <asm/atomic.h>
> #include <asm/system.h>
> @@ -150,3 +151,36 @@ void __init init_IRQ(void)
> kgdb_early_setup = 1;
> #endif
> }
> +
> +/*
> + * do_IRQ handles all normal device IRQ's (the special
> + * SMP cross-CPU interrupts have their own specific
> + * handlers).
> + */
> +unsigned int __irq_entry do_IRQ(unsigned int irq)
> +{
> + irq_enter();
> + __DO_IRQ_SMTC_HOOK(irq);
> + generic_handle_irq(irq);
> + irq_exit();
> +
> + return 1;
> +}
> +
> +#ifdef CONFIG_MIPS_MT_SMTC_IRQAFF
> +/*
> + * To avoid inefficient and in some cases pathological re-checking of
> + * IRQ affinity, we have this variant that skips the affinity check.
> + */
> +
> +unsigned int __irq_entry do_IRQ_no_affinity(unsigned int irq)
> +{
> + irq_enter();
> + __NO_AFFINITY_IRQ_SMTC_HOOK(irq);
> + generic_handle_irq(irq);
> + irq_exit();
> +
> + return 1;
> +}
> +
> +#endif /* CONFIG_MIPS_MT_SMTC_IRQAFF */
> diff --git a/arch/mips/kernel/smp.c b/arch/mips/kernel/smp.c
> index e72e684..6cdca19 100644
> --- a/arch/mips/kernel/smp.c
> +++ b/arch/mips/kernel/smp.c
> @@ -32,6 +32,7 @@
> #include <linux/cpumask.h>
> #include <linux/cpu.h>
> #include <linux/err.h>
> +#include <linux/ftrace.h>
>
> #include <asm/atomic.h>
> #include <asm/cpu.h>
> @@ -130,7 +131,7 @@ asmlinkage __cpuinit void start_secondary(void)
> /*
> * Call into both interrupt handlers, as we share the IPI for them
> */
> -void smp_call_function_interrupt(void)
> +void __irq_entry smp_call_function_interrupt(void)
> {
> irq_enter();
> generic_smp_call_function_single_interrupt();
> diff --git a/arch/mips/kernel/smtc.c b/arch/mips/kernel/smtc.c
> index 24630fd..75034a8 100644
> --- a/arch/mips/kernel/smtc.c
> +++ b/arch/mips/kernel/smtc.c
> @@ -25,6 +25,7 @@
> #include <linux/interrupt.h>
> #include <linux/kernel_stat.h>
> #include <linux/module.h>
> +#include <linux/ftrace.h>
>
> #include <asm/cpu.h>
> #include <asm/processor.h>
> @@ -939,23 +940,29 @@ static void ipi_call_interrupt(void)
>
> DECLARE_PER_CPU(struct clock_event_device, mips_clockevent_device);
>
> -void ipi_decode(struct smtc_ipi *pipi)
> +static void __irq_entry smtc_clock_tick_interrupt(void)
> {
> unsigned int cpu = smp_processor_id();
> struct clock_event_device *cd;
> + int irq = MIPS_CPU_IRQ_BASE + 1;
> +
> + irq_enter();
> + kstat_incr_irqs_this_cpu(irq, irq_to_desc(irq));
> + cd = &per_cpu(mips_clockevent_device, cpu);
> + cd->event_handler(cd);
> + irq_exit();
> +}
> +
> +void ipi_decode(struct smtc_ipi *pipi)
> +{
> void *arg_copy = pipi->arg;
> int type_copy = pipi->type;
> - int irq = MIPS_CPU_IRQ_BASE + 1;
>
> smtc_ipi_nq(&freeIPIq, pipi);
>
> switch (type_copy) {
> case SMTC_CLOCK_TICK:
> - irq_enter();
> - kstat_incr_irqs_this_cpu(irq, irq_to_desc(irq));
> - cd = &per_cpu(mips_clockevent_device, cpu);
> - cd->event_handler(cd);
> - irq_exit();
> + smtc_clock_tick_interrupt();
> break;
>
> case LINUX_SMP_IPI:
> diff --git a/arch/mips/kernel/vmlinux.lds.S b/arch/mips/kernel/vmlinux.lds.S
> index 162b299..f25df73 100644
> --- a/arch/mips/kernel/vmlinux.lds.S
> +++ b/arch/mips/kernel/vmlinux.lds.S
> @@ -46,6 +46,7 @@ SECTIONS
> SCHED_TEXT
> LOCK_TEXT
> KPROBES_TEXT
> + IRQENTRY_TEXT
> *(.text.*)
> *(.fixup)
> *(.gnu.warning)
> diff --git a/arch/mips/sgi-ip22/ip22-int.c b/arch/mips/sgi-ip22/ip22-int.c
> index 0ecd5fe..383f11d 100644
> --- a/arch/mips/sgi-ip22/ip22-int.c
> +++ b/arch/mips/sgi-ip22/ip22-int.c
> @@ -13,6 +13,7 @@
> #include <linux/init.h>
> #include <linux/kernel_stat.h>
> #include <linux/interrupt.h>
> +#include <linux/ftrace.h>
>
> #include <asm/irq_cpu.h>
> #include <asm/sgi/hpc3.h>
> @@ -150,7 +151,7 @@ static void indy_local1_irqdispatch(void)
>
> extern void ip22_be_interrupt(int irq);
>
> -static void indy_buserror_irq(void)
> +static void __irq_entry indy_buserror_irq(void)
> {
> int irq = SGI_BUSERR_IRQ;
>
> diff --git a/arch/mips/sgi-ip22/ip22-time.c b/arch/mips/sgi-ip22/ip22-time.c
> index c8f7d23..603fc91 100644
> --- a/arch/mips/sgi-ip22/ip22-time.c
> +++ b/arch/mips/sgi-ip22/ip22-time.c
> @@ -16,6 +16,7 @@
> #include <linux/interrupt.h>
> #include <linux/kernel_stat.h>
> #include <linux/time.h>
> +#include <linux/ftrace.h>
>
> #include <asm/cpu.h>
> #include <asm/mipsregs.h>
> @@ -115,7 +116,7 @@ __init void plat_time_init(void)
> }
>
> /* Generic SGI handler for (spurious) 8254 interrupts */
> -void indy_8254timer_irq(void)
> +void __irq_entry indy_8254timer_irq(void)
> {
> int irq = SGI_8254_0_IRQ;
> ULONG cnt;

Re: [PATCH] ptrace: copy_process() should disable stepping

2009-11-08T20:15:46Z

That is inappropriate use of arch details in generic code. It might
happen to be harmless fritter in practice on the arch's we have but it
is certainly not the correct way to go about things. You should just
call user_disable_single_step() unconditionally. Even on an arch with
no such machinery at all that should be defined safely as a no-op (see
linux/ptrace.h). If there is some reason not to do that, please
explain it.

Thanks,
Roland
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Re: [PATCH -v6 02/13] tracing: add mips_timecounter_read() for MIPS

2009-11-08T20:15:16Z

Hi Ralf,

Could you please give some feedback on this patch?

Really looking forward to your feedback and then resend this patchset
out ;)

Thanks & Regards,
Wu Zhangjin

On Mon, 2009-10-26 at 23:13 +0800, Wu Zhangjin wrote:

> This patch add a new function: mips_timecounter_read() to get high
> precision timestamp without extra lock.
>
> It is based on the clock counter register and the
> timecounter/cyclecounter abstraction layer of kernel.
>
> Signed-off-by: Wu Zhangjin <wuzhangjin@...>
> ---
> arch/mips/include/asm/time.h | 19 +++++++++++++++++++
> arch/mips/kernel/csrc-r4k.c | 41 +++++++++++++++++++++++++++++++++++++++++
> arch/mips/kernel/time.c | 2 ++
> 3 files changed, 62 insertions(+), 0 deletions(-)
>
> diff --git a/arch/mips/include/asm/time.h b/arch/mips/include/asm/time.h
> index df6a430..b8af7fa 100644
> --- a/arch/mips/include/asm/time.h
> +++ b/arch/mips/include/asm/time.h
> @@ -73,8 +73,18 @@ static inline int mips_clockevent_init(void)
> */
> #ifdef CONFIG_CSRC_R4K_LIB
> extern int init_r4k_clocksource(void);
> +extern int init_r4k_timecounter(void);
> +extern u64 r4k_timecounter_read(void);
> #endif
>
> +static inline u64 mips_timecounter_read(void)
> +{
> +#ifdef CONFIG_CSRC_R4K
> + return r4k_timecounter_read();
> +#else
> + return sched_clock();
> +#endif
> +}
> static inline int init_mips_clocksource(void)
> {
> #ifdef CONFIG_CSRC_R4K
> @@ -84,6 +94,15 @@ static inline int init_mips_clocksource(void)
> #endif
> }
>
> +static inline int init_mips_timecounter(void)
> +{
> +#ifdef CONFIG_CSRC_R4K
> + return init_r4k_timecounter();
> +#else
> + return 0;
> +#endif
> +}
> +
> extern void clocksource_set_clock(struct clocksource *cs, unsigned int clock);
> extern void clockevent_set_clock(struct clock_event_device *cd,
> unsigned int clock);
> diff --git a/arch/mips/kernel/csrc-r4k.c b/arch/mips/kernel/csrc-r4k.c
> index e95a3cd..4e7705f 100644
> --- a/arch/mips/kernel/csrc-r4k.c
> +++ b/arch/mips/kernel/csrc-r4k.c
> @@ -7,6 +7,7 @@
> */
> #include <linux/clocksource.h>
> #include <linux/init.h>
> +#include <linux/sched.h>
>
> #include <asm/time.h>
>
> @@ -36,3 +37,43 @@ int __init init_r4k_clocksource(void)
>
> return 0;
> }
> +
> +static struct timecounter r4k_tc = {
> + .cc = NULL,
> +};
> +
> +static cycle_t r4k_cc_read(const struct cyclecounter *cc)
> +{
> + return read_c0_count();
> +}
> +
> +static struct cyclecounter r4k_cc = {
> + .read = r4k_cc_read,
> + .mask = CLOCKSOURCE_MASK(32),
> + .shift = 32,
> +};
> +
> +int __init init_r4k_timecounter(void)
> +{
> + if (!cpu_has_counter || !mips_hpt_frequency)
> + return -ENXIO;
> +
> + r4k_cc.mult = div_sc((unsigned long)mips_hpt_frequency, NSEC_PER_SEC,
> + 32);
> +
> + timecounter_init(&r4k_tc, &r4k_cc, sched_clock());
> +
> + return 0;
> +}
> +
> +u64 r4k_timecounter_read(void)
> +{
> + u64 clock;
> +
> + if (r4k_tc.cc != NULL)
> + clock = timecounter_read(&r4k_tc);
> + else
> + clock = sched_clock();
> +
> + return clock;
> +}
> diff --git a/arch/mips/kernel/time.c b/arch/mips/kernel/time.c
> index 1f467d5..e38cca1 100644
> --- a/arch/mips/kernel/time.c
> +++ b/arch/mips/kernel/time.c
> @@ -156,4 +156,6 @@ void __init time_init(void)
>
> if (!mips_clockevent_init() || !cpu_has_mfc0_count_bug())
> init_mips_clocksource();
> + if (!cpu_has_mfc0_count_bug())
> + init_mips_timecounter();
> }

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Re: [PATCH 0/15] sysfs lazification final

2009-11-08T19:57:49Z

Eric W. Biederman wrote:

> The sysfs code updates the vfs caches immediately when the sysfs data
> structures change causing a lot of unnecessary complications. The
> following patchset untangles that beast. Allowing for simpler
> more straight forward code, the removal of a hack from the vfs
> to support sysfs, and human comprehensible locking on sysfs.
>
> Most of these patches have already been reviewed and acked from the
> last time I had time to work on sysfs.
>
> This acks have been folded in and the two small bugs found in the
> previous review have been fixed in the trailing patches (they are
> minor enough nits that even a bisect that happens to land in the
> middle should not see sysfs problems).

Thanks a lot for bringing some sanity to sysfs. :-)

--
tejun
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

linux-next: pcmcia tree build warning

2009-11-08T19:54:51Z

Hi Dominik,

Today's linux-next build (x86_64 allmodconfig) produced this warning:

drivers/char/pcmcia/cm4000_cs.c: In function 'cmm_ioctl':
/scratch/sfr/next/drivers/char/pcmcia/cm4000_cs.c:1630: warning: the frame size of 2176 bytes is larger than 2048 bytes

Introduced by commit 7194198b163c83725f52ce8e34b24cca053deea7 ("pcmcia:
use dynamic debug infrastructure, deprecate CS_CHECK (char)") which
unconditionalised "char *ioctl_names[CM_IOC_MAXNR + 1]" on the stack.
CM_IOC_MAXNR is 255, so this adds 2k to the stack frame just to allow the
printing of one of five ioctl names in a debug message. It could be made
static ...

--
Cheers,
Stephen Rothwell sfr@...
http://www.canb.auug.org.au/~sfr/

attachment0 (205 bytes) Download Attachment

Re: [PATCH 00/23] Removal of binary sysctl support

2009-11-08T19:44:02Z

Arnd Bergmann <arnd@...> writes:

> On Sunday 08 November 2009 12:16:43 Eric W. Biederman wrote:
>> This patchset reimplements sys_sysctl as a compatibility wrapper
>> around /proc/sys. After which it removes all of the code to all over
>> the kernel that is used today to implement the binary sysctls.
>>
>> I am posting this patchset to give everyone a heads up what is in
>> flight.
>>
>> I intend to carry all of these patches in my sysctl tree.
>
> Very nice patches again!
>
> Looking at what you did, I had two ideas how to move on from there,
> which may be part of your plans already:
>
> 1. Make it possible to build sysctl_binary.c as a loadable module
> so you can get a smaller kernel without losing the option to use
> binary sysctl altogether. This of course requires a small portion
> to remain in the kernel, to provide the actual syscall entry point
> and load the module on demand.

I can see how this could make sense from a distribution perspective.

> 2. On top of that, put the same code into glibc so that you don't
> even have to load the module when you're running a new glibc version.
> Since the binary sysctl ABI is stable (as in stiff and dead), there
> should be no need to synchronize any extensions to it betwen kernel
> and libc.

I don't expect we will need to move this to glibc. There are so few
users of sys_sysctl now, that I hardly expect it to be worth it to move
this code out of the kernel.

For me the big problem with sys_sysctl is solved by this patchset.
It no longer constitutes a maintenance burden on the rest of the sysctl
code, and the other sysctl users.

Now the implementation of /proc/sys can be implemented and optimized without
dealing with any sys_sysctl baggage.

All of that said if someone is interested in tweaking sysctl_binary.c to make
it easier to deal with sys_sysctl going away I don't have any problems.

Eric
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

linux-next: manual merge of the pcmcia tree with the mtd tree

2009-11-08T19:42:21Z

Hi Dominik,

Today's linux-next merge of the pcmcia tree got a conflict in
drivers/mtd/maps/pcmciamtd.c between commit
5da6bbe2f9e1db56b4a94cad2ace7d9992b1d666 ("pcmcia: convert pcmciamtd
driver to use new CIS helpers") from the mtd tree and commit
18b61b97294dad74dd00a1aa8efed0cfacb95aff ("pcmcia: convert pcmciamtd
driver to use new CIS helpers") from the pcmcia tree.

Presumably two different versions of the same change? I just used the
version from the pcmcia tree for today.
--
Cheers,
Stephen Rothwell sfr@...
http://www.canb.auug.org.au/~sfr/

attachment0 (205 bytes) Download Attachment

Re: [PATCH -v6 08/13] tracing: add IRQENTRY_EXIT section for MIPS

2009-11-08T19:31:08Z

Hi,

On Mon, 2009-11-09 at 03:26 +0100, Frederic Weisbecker wrote:

> On Mon, Oct 26, 2009 at 11:13:25PM +0800, Wu Zhangjin wrote:
> > This patch add a new section for MIPS to record the block of the hardirq
> > handling for function graph tracer(print_graph_irq) via adding the
> > __irq_entry annotation to the the entrypoints of the hardirqs(the block
> > with irq_enter()...irq_exit()).
> >
> > Thanks goes to Steven & Frederic Weisbecker for their feedbacks.
> >
> > Signed-off-by: Wu Zhangjin <wuzhangjin@...>
> > +
> > +/*
> > + * do_IRQ handles all normal device IRQ's (the special
> > + * SMP cross-CPU interrupts have their own specific
> > + * handlers).
> > + */
> > +unsigned int __irq_entry do_IRQ(unsigned int irq)
> > +{
> > + irq_enter();
> > + __DO_IRQ_SMTC_HOOK(irq);
> > + generic_handle_irq(irq);
> > + irq_exit();
> > +
> > + return 1;
> > +}
>
>
>
> Nano-neat:
>
> Why is it returning a value, it doesn't seem needed (the macro
> version didn't)?
>

Will remove it later.

> Anyway, that looks good to me. I hope the changes from macro
> to function calls will be ack by the MIPS maintainers.
>

Hope Ralf give some feedbacks about it ;)

> Reviewed-by: Frederic Weisbecker <fweisbec@...>
>

Thanks!

BTW:

Who should I resend this patchset to? you or Steven? If this patchset
are okay, I will rebase it on the latest tracing/core branch of -tip and
send the latest version out, and hope you can apply it, otherwise, I
need to rebase it to the future mainline versions again and again ;) and
at least, I have tested all of them and their combinations on YeeLoong
netbook, they work well. of course, more testing report from the other
MIPS developers are welcome ;)

Regards,
Wu Zhangjin

[PATCH] perf bench: Fix bench/sched-pipe.c to wait child process

2009-11-08T19:31:05Z

Fixed bench/sched-pipe.c to avoid the below case
notified by Ingo Molnar,

---

$ ./perf bench sched pipe
(executing 1000000 pipe operations between two tasks)

Total time:4.898 sec
$ 4.898586 usecs/op
204140 ops/sec

the shell prompt came back before the usecs/op and ops/sec line was
printed. Process teardown race, lack of wait() or so?

---

This caused by lack of calling waitpid() by parent process,
so I added it.

Signed-off-by: Hitoshi Mitake <mitake@...>
Cc: Rusty Russell <rusty@...>
Cc: Peter Zijlstra <a.p.zijlstra@...>
Cc: Paul Mackerras <paulus@...>
Cc: Mike Galbraith <efault@...>
Cc: Arnaldo Carvalho de Melo <acme@...>
Cc: Frederic Weisbecker <fweisbec@...>
Cc: Jiri Kosina <jkosina@...>
---
tools/perf/bench/sched-pipe.c | 10 +++++++---
1 files changed, 7 insertions(+), 3 deletions(-)

diff --git a/tools/perf/bench/sched-pipe.c b/tools/perf/bench/sched-pipe.c
index 3214ed2..6a29100 100644
--- a/tools/perf/bench/sched-pipe.c
+++ b/tools/perf/bench/sched-pipe.c
@@ -26,6 +26,7 @@
#include <errno.h>
#include <assert.h>
#include <sys/time.h>
+#include <sys/types.h>

#define LOOPS_DEFAULT 1000000
static int loops = LOOPS_DEFAULT;
@@ -58,8 +59,8 @@ int bench_sched_pipe(int argc, const char **argv,
* discarding returned value of read(), write()
* causes error in building environment for perf
*/
- int ret;
- pid_t pid;
+ int ret, wait_stat;
+ pid_t pid, retpid;

argc = parse_options(argc, argv, options,
bench_sched_pipe_usage, 0);
@@ -87,8 +88,11 @@ int bench_sched_pipe(int argc, const char **argv,
gettimeofday(&stop, NULL);
timersub(&stop, &start, &diff);

- if (pid)
+ if (pid) {
+ retpid = waitpid(pid, &wait_stat, 0);
+ assert((retpid == pid) && WIFEXITED(wait_stat));
return 0;
+ }

if (simple)
printf("%lu.%03lu\n",
--
1.6.5.2

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Re: [PATCH] proc: revalidate dentry returned by proc_pid_follow_link

2009-11-08T19:30:55Z

Jeff Layton <jlayton@...> writes:

>> Hmm. Looking at the code I get the impression that a file bind mount
>> will have exactly the same problem.
>>
>> Can you confirm.
>>
>> If file bind mounts also have this problem a bugfix to to just
>> proc seems questionable.
>>
>
> I'm not sure I understand what you mean by "file bind mount". Is that
> something like mounting with "-o loop" ?

# cd /tmp
# echo foo > foo
# echo bar > bar
# mount --bind foo bar
# cat bar
foo
#

> I'm not at all opposed to fixing this in a more broad fashion, but as
> best I can tell, the only place that LAST_BIND is used is in procfs.

proc does appear to be the only user of LAST_BIND. With a file bind
mount we can get to the same ok: label without a revalidate. The
difference is that we came from __follow_mount instead of follow_link.

At least that is how I read the code.

Eric
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Re: [PATCH v4 01/12] vsprintf: factorize "(null)" string

2009-11-08T19:28:03Z

On Sun, 8 Nov 2009 01:46:09 am you wrote:
> Change "<NULL>" to "(null)" and make it a static const char[] hoping that
> the compiler will make null_str a label to a read-only area containing it.

(Trimmed the 79 recipients of the original).

Hi Andre,

Consistently using <NULL> or (null) makes sense. But I'm really missing your argument: is there some reason why normal string merging won't work?

Confused,
Rusty.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Re: [PATCH v2 3/7] Adding general performance benchmarking subcommand to perf.

2009-11-08T19:27:12Z

From: Ingo Molnar <mingo@...>
Subject: Re: [PATCH v2 3/7] Adding general performance benchmarking subcommand to perf.
Date: Sun, 8 Nov 2009 12:30:13 +0100

> > >
> > > Shouldnt we output the unit of measurement, i.e. '4.575 usecs'? Also, we
> > > should perhaps print something like:
> > >
> > > % perf bench sched pipe
> > >
> > > (executing 1000000 pipe operations between two tasks)
> > >
> > > 4.575 usecs per op
> > > 218579 ops/sec
> > >
> > > ?
> >
> > I have to admit that single float value output is too simple.
> > So I'll fix the default output.
> >
> > But, I believe that simple form makes sense for
> > processing by scripts or graph tools like gnuplot.
> > I'll add the option (may be --simple) to switch
> > friendliness of outputs.
>
> Btw., could you make it Git-ish, i.e.:
>
> --format=short
>
> or:
>
> --format=simple
>
> Eventually more format options might be added.

It's good idea.
I have to admit that reserving -s for simple output is not good idea.
I'll do this.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Re: [PATCH 22/23] sysctl arm: Remove binary sysctl support

2009-11-08T19:27:07Z

Arjan van de Ven <arjan@...> writes:

> On Sun, 08 Nov 2009 15:05:05 -0800
> ebiederm@... (Eric W. Biederman) wrote:
>
>> >
>> > The practical difference is that /proc support now must be compiled
>> > in to support sys_sysctl.
>>
>> But thanks for the reminder that I need to go into glibc and fix this
>> before we disable the sys_sysctl emulation by default.
>
> how are you dealing with existing glibcs ? Or with static linked
> binaries? or.. or ..
>
> breaking a heavily used ABI like this is not going to be pretty
> or even sane, no matter which way you hate the current one.

sysctl_binary.c has all of the code to continue to provide the
existing ABI.

sys_sysctl is not heavily used at all, and this is the responsible
removal of a practically unused ABI. Last I check (and this was
before I shouted to the world that sys_sysctl is going away) I could
count on one hand all of the users of sys_sysctl.

/proc/sys will definitely continue to exist.

I just took a look and the use in linux threads that I don't warn
about is used by glibc-2.8 but not by glibc-2.10. glibc-2.11 has just
been released. so by next year when the removal is scheduled we are
looking at multiple releases of glibc that don't use sys_sysctl. So I
expect shortly I can warn about all uses of sys_sysctl without anyone
seeing a warning.

The one unfixed case I know about is fixing ioperm on arm, in the glibc
ports tree, and that will need to happen before sys_sysctl is disabled
by default. Which is all I intend to do when we reach that point in
feature removal schedule now that I have refactored the code so that
sys_sysctl no longer imposes a maintenance burden on the sane sysctl
users.

I don't hate sysctl, in fact for global tuneables I would argue for
all it's faults sysctl it is one of the better interfaces we have. I
just figure the implementation needs to be optimized for the way
sysctl is used today, the via /proc/sys.

Eric
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Re: [PATCH] perf bench:Fix bench/sched-pipe.c to wait child process

2009-11-08T19:18:36Z

From: Hitoshi Mitake <mitake@...>
Subject: [PATCH] perf bench:Fix bench/sched-pipe.c to wait child process
Date: Mon, 9 Nov 2009 12:13:08 +0900

Sorry, the title lacks space after "perf bench:".
I'll send new fixed one, please discard this.

> Fixed bench/sched-pipe.c to avoid the below case
> notified by Ingo Molnar,
>
> ---
>
> $ ./perf bench sched pipe
> (executing 1000000 pipe operations between two tasks)
>
> Total time:4.898 sec
> $ 4.898586 usecs/op
> 204140 ops/sec
>
> the shell prompt came back before the usecs/op and ops/sec line was
> printed. Process teardown race, lack of wait() or so?
>
> ---
>
> This caused by lack of calling waitpid() by parent process,
> so I added it.
>
> Signed-off-by: Hitoshi Mitake <mitake@...>
> Cc: Rusty Russell <rusty@...>
> Cc: Peter Zijlstra <a.p.zijlstra@...>
> Cc: Paul Mackerras <paulus@...>
> Cc: Mike Galbraith <efault@...>
> Cc: Arnaldo Carvalho de Melo <acme@...>
> Cc: Frederic Weisbecker <fweisbec@...>
> Cc: Jiri Kosina <jkosina@...>
> ---
> tools/perf/bench/sched-pipe.c | 10 +++++++---
> 1 files changed, 7 insertions(+), 3 deletions(-)
>
> diff --git a/tools/perf/bench/sched-pipe.c b/tools/perf/bench/sched-pipe.c
> index 3214ed2..6a29100 100644
> --- a/tools/perf/bench/sched-pipe.c
> +++ b/tools/perf/bench/sched-pipe.c
> @@ -26,6 +26,7 @@
> #include <errno.h>
> #include <assert.h>
> #include <sys/time.h>
> +#include <sys/types.h>
>
> #define LOOPS_DEFAULT 1000000
> static int loops = LOOPS_DEFAULT;
> @@ -58,8 +59,8 @@ int bench_sched_pipe(int argc, const char **argv,
> * discarding returned value of read(), write()
> * causes error in building environment for perf
> */
> - int ret;
> - pid_t pid;
> + int ret, wait_stat;
> + pid_t pid, retpid;
>
> argc = parse_options(argc, argv, options,
> bench_sched_pipe_usage, 0);
> @@ -87,8 +88,11 @@ int bench_sched_pipe(int argc, const char **argv,
> gettimeofday(&stop, NULL);
> timersub(&stop, &start, &diff);
>
> - if (pid)
> + if (pid) {
> + retpid = waitpid(pid, &wait_stat, 0);
> + assert((retpid == pid) && WIFEXITED(wait_stat));
> return 0;
> + }
>
> if (simple)
> printf("%lu.%03lu\n",
> --
> 1.6.5.2
>
>

Re: [PATCH 05/10] kbuild: sort the list of symbols exported by the kernel (__ksymtab)

2009-11-08T19:17:57Z

On Fri, 6 Nov 2009 12:54:10 am Alan Jenkins wrote:

> Sam Ravnborg wrote:
> > On Wed, Nov 04, 2009 at 10:00:50AM +0000, Alan Jenkins wrote:
> >
> >> Rusty Russell wrote:
> >>
> >>> On Tue, 3 Nov 2009 08:36:17 pm Alan Jenkins wrote:
> >>>
> >>>
> >>>> +/*
> >>>> + * We use CPP macros since they are more familiar than assembly macros.
> >>>> + * Note that CPP macros eat newlines, so each statement must be terminated
> >>>> + * by a semicolon.
> >>>> + */
> >>>> +
> >>>> +#ifdef CONFIG_HAVE_SYMBOL_PREFIX
> >>>> +#define __SYM(sym) _##sym
> >>>> +#else
> >>>> +#define __SYM(sym) sym
> >>>> +#endif
> >>>>
> >>>>
> >>> Ideally, you would used MODULE_SYMBOL_PREFIX here, but of course it's a
> >>> string. I don't think Kconfig can do arbitrary identifiers, so we can't
> >>> make CONFIG_SYMBOL_PREFIX empty or _.
> >>>
> >>> Perhaps clarify it to a bool CONFIG_HAVE_MODULE_UNDERSCORE_PREFIX then,
> >>> since that's what you're assuming here?
> >>>
> >>> Thanks,
> >>> Rusty.
> >>>
> >> I made the same assumption in patch 4. The arch defines
> >> CONFIG_HAVE_SYMBOL_PREFIX, which then causes init/Kconfig to define
> >> CONFIG_SYMBOL_PREFIX="_".
> >>
> >> Mike suggested that I hack kbuild instead, to do something like
> >>
> >> unquote = ...
> >> AFLAGS_.tmp_export-asm.o += -DSYMBOL_PREFIX=$(unquote CONFIG_SYMBOL_PREFIX)
> >>
> >> I'm experimenting with the idea, but I haven't managed to get it working
> >>
> >
> > Something like this:
> > unquote = $(patsubst "%",%,$($1))
> >
> > AFLAGS_.tmp_export-asm.o += -DSYMBOL_PREFIX=$(call unquote,CONFIG_SYMBOL_PREFIX)
> >
> > But the readability is low so we could be better off doing it direct:
> >
> > AFLAGS_.tmp_export-asm.o += -DSYMBOL_PREFIX=$(patsubst "%",",$(CONFIG_SYMBOL_PREFIX))
> >
> > Sam
> >
>
> Thanks to both of you, I have something that works now.

I've taken this, but really, it's overkill. Changing the config to a fixed
"underscore or nothing" was simpler and demonstrably sufficient for all cases
in the last 5 years.

Thanks,
Rusty.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

[PATCH] perf bench:Fix bench/sched-pipe.c to wait child process

2009-11-08T19:13:08Z