[38/50] Fix IPV6 append OOPS.
From: YOSHIFUJI Hideaki <[EMAIL PROTECTED]>
commit e1f52208bb968291f7d9142eff60b62984b4a511 in mainline.
[IPv6]: Fix NULL pointer dereference in ip6_flush_pending_frames
Some of skbs in sk->write_queue do not have skb->dst because
we do not fill skb->dst when we allocate new skb in append_data().
BTW, I think we may not need to (or we should not) increment some stats
when using corking; if 100 sendmsg() (with MSG_MORE) result in 2 packets,
how many should we increment?
If 100, we should set skb->dst for every queued skbs.
If 1 (or 2 (*)), we increment the stats for the first queued skb and
we should just skip incrementing OutDiscards for the rest of queued skbs,
adn we should also impelement this semantics in other places;
e.g., we should increment other stats just once, not 100 times.
*: depends on the place we are discarding the datagram.
I guess should just increment by 1 (or 2).
Signed-off-by: YOSHIFUJI Hideaki <[EMAIL PROTECTED]>
Signed-off-by: David S. Miller <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
---
net/ipv6/ip6_output.c |5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
--- a/net/ipv6/ip6_output.c
+++ b/net/ipv6/ip6_output.c
@@ -1423,8 +1423,9 @@ void ip6_flush_pending_frames(struct soc
struct sk_buff *skb;
while ((skb = __skb_dequeue_tail(>sk_write_queue)) != NULL) {
- IP6_INC_STATS(ip6_dst_idev(skb->dst),
- IPSTATS_MIB_OUTDISCARDS);
+ if (skb->dst)
+ IP6_INC_STATS(ip6_dst_idev(skb->dst),
+ IPSTATS_MIB_OUTDISCARDS);
kfree_skb(skb);
}
--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[39/50] Fix IPSEC AH4 options handling
From: Nick Bowler <[EMAIL PROTECTED]> commit 8ee4f391831cb96916a8e8a05f04b1c1d7dd30d8 in mainline. In testing our ESP/AH offload hardware, I discovered an issue with how AH handles mutable fields in IPv4. RFC 4302 (AH) states the following on the subject: For IPv4, the entire option is viewed as a unit; so even though the type and length fields within most options are immutable in transit, if an option is classified as mutable, the entire option is zeroed for ICV computation purposes. The current implementation does not zero the type and length fields, resulting in authentication failures when communicating with hosts that do (i.e. FreeBSD). I have tested record route and timestamp options (ping -R and ping -T) on a small network involving Windows XP, FreeBSD 6.2, and Linux hosts, with one router. In the presence of these options, the FreeBSD and Linux hosts (with the patch or with the hardware) can communicate. The Windows XP host simply fails to accept these packets with or without the patch. I have also been trying to test source routing options (using traceroute -g), but haven't had much luck getting this option to work *without* AH, let alone with. Signed-off-by: Nick Bowler <[EMAIL PROTECTED]> Signed-off-by: David S. Miller <[EMAIL PROTECTED]> Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]> --- net/ipv4/ah4.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/net/ipv4/ah4.c +++ b/net/ipv4/ah4.c @@ -46,7 +46,7 @@ static int ip_clear_mutable_options(stru memcpy(daddr, optptr+optlen-4, 4); /* Fall through */ default: - memset(optptr+2, 0, optlen-2); + memset(optptr, 0, optlen); } l -= optlen; optptr += optlen; -- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[37/50] Fix inet_diag OOPS.
From: Patrick McHardy <[EMAIL PROTECTED]>
commit 0a9c73014415d2a84dac346c1e12169142a6ad37 in mainline
[INET_DIAG]: Fix oops in netlink_rcv_skb
netlink_run_queue() doesn't handle multiple processes processing the
queue concurrently. Serialize queue processing in inet_diag to fix
a oops in netlink_rcv_skb caused by netlink_run_queue passing a
NULL for the skb.
BUG: unable to handle kernel NULL pointer dereference at virtual address
0054
[349587.500454] printing eip:
[349587.500457] c03318ae
[349587.500459] *pde =
[349587.500464] Oops: [#1]
[349587.500466] PREEMPT SMP
[349587.500474] Modules linked in: w83627hf hwmon_vid i2c_isa
[349587.500483] CPU:0
[349587.500485] EIP:0060:[]Not tainted VLI
[349587.500487] EFLAGS: 00010246 (2.6.22.3 #1)
[349587.500499] EIP is at netlink_rcv_skb+0xa/0x7e
[349587.500506] eax: ebx: ecx: c148d2a0 edx: c0398819
[349587.500510] esi: edi: c0398819 ebp: c7a21c8c esp: c7a21c80
[349587.500517] ds: 007b es: 007b fs: 00d8 gs: 0033 ss: 0068
[349587.500521] Process oidentd (pid: 17943, ti=c7a2 task=cee231c0
task.ti=c7a2)
[349587.500527] Stack: c7a21cac f7c8ba78 c7a21ca4 c0331962 c0398819
f7c8ba00 004c
[349587.500542]f736f000 c7a21cb4 c03988e3 0001 f7c8ba00 c7a21cc4
c03312a5 004c
[349587.500558]f7c8ba00 c7a21cd4 c0330681 f7c8ba00 e4695280 c7a21d00
c03307c6 7fff
[349587.500578] Call Trace:
[349587.500581] [] show_trace_log_lvl+0x1c/0x33
[349587.500591] [] show_stack_log_lvl+0x8d/0xaa
[349587.500595] [] show_registers+0x1cb/0x321
[349587.500604] [] die+0x112/0x1e1
[349587.500607] [] do_page_fault+0x229/0x565
[349587.500618] [] error_code+0x72/0x78
[349587.500625] [] netlink_run_queue+0x40/0x76
[349587.500632] [] inet_diag_rcv+0x1f/0x2c
[349587.500639] [] netlink_data_ready+0x57/0x59
[349587.500643] [] netlink_sendskb+0x24/0x45
[349587.500651] [] netlink_unicast+0x100/0x116
[349587.500656] [] netlink_sendmsg+0x1c2/0x280
[349587.500664] [] sock_sendmsg+0xba/0xd5
[349587.500671] [] sys_sendmsg+0x17b/0x1e8
[349587.500676] [] sys_socketcall+0x230/0x24d
[349587.500684] [] syscall_call+0x7/0xb
[349587.500691] ===
[349587.500693] Code: f0 ff 4e 18 0f 94 c0 84 c0 0f 84 66 ff ff ff 89 f0 e8 86
e2 fc ff e9 5a ff ff ff f0 ff 40 10 eb be 55 89 e5 57 89 d7 56 89 c6 53 <8b> 50
54 83 fa 10 72 55 8b 9e 9c 00 00 00 31 c9 8b 03 83 f8 0f
Reported by Athanasius <[EMAIL PROTECTED]>
Signed-off-by: Patrick McHardy <[EMAIL PROTECTED]>
Signed-off-by: David S. Miller <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
---
net/ipv4/inet_diag.c |4
1 file changed, 4 insertions(+)
--- a/net/ipv4/inet_diag.c
+++ b/net/ipv4/inet_diag.c
@@ -836,12 +836,16 @@ static int inet_diag_rcv_msg(struct sk_b
return inet_diag_get_exact(skb, nlh);
}
+static DEFINE_MUTEX(inet_diag_mutex);
+
static void inet_diag_rcv(struct sock *sk, int len)
{
unsigned int qlen = 0;
do {
+ mutex_lock(_diag_mutex);
netlink_run_queue(sk, , _diag_rcv_msg);
+ mutex_unlock(_diag_mutex);
} while (qlen);
}
--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/5] Fix minor bug in yield + add more debug o/p
- Fix a minor bug in yield (seen for CONFIG_FAIR_GROUP_SCHED)
- Print nr_running and load information for cfs_rq in /proc/sched_debug
- Print >cfs statistics as well (usefull for group scheduling)
Signed-off-by : Srivatsa Vaddagiri <[EMAIL PROTECTED]>
Signed-off-by : Dhaval Giani <[EMAIL PROTECTED]>
---
kernel/sched_debug.c |2 ++
kernel/sched_fair.c |3 ++-
2 files changed, 4 insertions(+), 1 deletion(-)
Index: current/kernel/sched_debug.c
===
--- current.orig/kernel/sched_debug.c
+++ current/kernel/sched_debug.c
@@ -136,6 +136,8 @@ void print_cfs_rq(struct seq_file *m, in
SPLIT_NS(spread0));
SEQ_printf(m, " .%-30s: %ld\n", "spread0",
cfs_rq->nr_sync_min_vruntime);
+ SEQ_printf(m, " .%-30s: %ld\n", "nr_running", cfs_rq->nr_running);
+ SEQ_printf(m, " .%-30s: %ld\n", "load", cfs_rq->load.weight);
}
static void print_cpu(struct seq_file *m, int cpu)
Index: current/kernel/sched_fair.c
===
--- current.orig/kernel/sched_fair.c
+++ current/kernel/sched_fair.c
@@ -726,7 +726,7 @@ static void dequeue_task_fair(struct rq
*/
static void yield_task_fair(struct rq *rq)
{
- struct cfs_rq *cfs_rq = >cfs;
+ struct cfs_rq *cfs_rq = task_cfs_rq(rq->curr);
struct rb_node **link = _rq->tasks_timeline.rb_node;
struct sched_entity *rightmost, *se = >curr->se;
struct rb_node *parent;
@@ -1025,6 +1025,7 @@ static void print_cfs_stats(struct seq_f
{
struct cfs_rq *cfs_rq;
+ print_cfs_rq(m, cpu, _rq(cpu)->cfs);
for_each_leaf_cfs_rq(cpu_rq(cpu), cfs_rq)
print_cfs_rq(m, cpu, cfs_rq);
}
--
Regards,
vatsa
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[35/50] Fix decnet device address listing.
From: Patrick McHardy <[EMAIL PROTECTED]>
commit a2221f308dabb95abb914ad858d36c2462705558 in mainline.
Not all are listed, same as the IPV4 devinet bug.
Signed-off-by: Patrick McHardy <[EMAIL PROTECTED]>
Signed-off-by: David S. Miller <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
---
net/decnet/dn_dev.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/net/decnet/dn_dev.c
+++ b/net/decnet/dn_dev.c
@@ -815,7 +815,7 @@ static int dn_nl_dump_ifaddr(struct sk_b
for (ifa = dn_db->ifa_list, dn_idx = 0; ifa;
ifa = ifa->ifa_next, dn_idx++) {
if (dn_idx < skip_naddr)
- goto cont;
+ continue;
if (dn_nl_fill_ifaddr(skb, ifa, NETLINK_CB(cb->skb).pid,
cb->nlh->nlmsg_seq, RTM_NEWADDR,
--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[36/50] Fix device address listing for ipv4.
From: Stephen Hemminger <[EMAIL PROTECTED]>
commit 596e41509550447b030f7b16adaeb0138ab585a8 in mainline
Bug: http://bugzilla.kernel.org/show_bug.cgi?id=8876
Not all ips are shown by "ip addr show" command when IPs number assigned to an
interface is more than 60-80 (in fact it depends on broadcast/label etc
presence on each address).
Steps to reproduce:
It's terribly simple to reproduce:
# for i in $(seq 1 100); do ip ad add 10.0.$i.1/24 dev eth10 ; done
# ip addr show
this will _not_ show all IPs.
Looks like the problem is in netlink/ipv4 message processing.
This is fix from bug submitter, it looks correct.
Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]>
Signed-off-by: David S. Miller <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
---
net/ipv4/devinet.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/net/ipv4/devinet.c
+++ b/net/ipv4/devinet.c
@@ -1194,7 +1194,7 @@ static int inet_dump_ifaddr(struct sk_bu
for (ifa = in_dev->ifa_list, ip_idx = 0; ifa;
ifa = ifa->ifa_next, ip_idx++) {
if (ip_idx < s_ip_idx)
- goto cont;
+ continue;
if (inet_fill_ifaddr(skb, ifa, NETLINK_CB(cb->skb).pid,
cb->nlh->nlmsg_seq,
RTM_NEWADDR, NLM_F_MULTI) <= 0)
--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[34/50] fix realtek phy id in forcedeth
From: Willy Tarreau <[EMAIL PROTECTED]>
commit ba685fb2abd71162bea6895a99449c1071b01402 in mainline.
As noticed by Chuck Ebbert, commit c5e3ae8823693b260ce1f217adca8add1bc0b3de
introduced a copy-paste typo, as realtek phy is 0x732 and not 0x1c1. Obvious
fix below suggested by Ayaz Abdulla.
Signed-off-by: Willy Tarreau <[EMAIL PROTECTED]>
Cc: Ayaz Abdulla <[EMAIL PROTECTED]>
Cc: Chuck Ebbert <[EMAIL PROTECTED]>
Signed-off-by: Jeff Garzik <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
---
drivers/net/forcedeth.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/net/forcedeth.c
+++ b/drivers/net/forcedeth.c
@@ -551,7 +551,7 @@ union ring_type {
#define PHY_OUI_MARVELL0x5043
#define PHY_OUI_CICADA 0x03f1
#define PHY_OUI_VITESSE0x01c1
-#define PHY_OUI_REALTEK0x01c1
+#define PHY_OUI_REALTEK0x0732
#define PHYID1_OUI_MASK0x03ff
#define PHYID1_OUI_SHFT6
#define PHYID2_OUI_MASK0xfc00
--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[33/50] crypto: blkcipher_get_spot() handling of buffer at end of page
From: Herbert Xu <[EMAIL PROTECTED]>
This corresponds to upstream changesets
e4630f9fd8cdc14eb1caa08dafe649eb5ae09985 and
32528d0fbda1093eeeaa7d0a2c498bbb5154099d.
[CRYPTO] blkcipher: Fix handling of kmalloc page straddling
The function blkcipher_get_spot tries to return a buffer of
the specified length that does not straddle a page. It has
an off-by-one bug so it may advance a page unnecessarily.
What's worse, one of its callers doesn't provide a buffer
that's sufficiently long for this operation.
This patch fixes both problems. Thanks to Bob Gilligan for
diagnosing this problem and providing a fix.
Signed-off-by: Herbert Xu <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
---
crypto/blkcipher.c | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
--- a/crypto/blkcipher.c
+++ b/crypto/blkcipher.c
@@ -59,11 +59,13 @@ static inline void blkcipher_unmap_dst(s
scatterwalk_unmap(walk->dst.virt.addr, 1);
}
+/* Get a spot of the specified length that does not straddle a page.
+ * The caller needs to ensure that there is enough space for this operation.
+ */
static inline u8 *blkcipher_get_spot(u8 *start, unsigned int len)
{
- if (offset_in_page(start + len) < len)
- return (u8 *)((unsigned long)(start + len) & PAGE_MASK);
- return start;
+ u8 *end_page = (u8 *)(((unsigned long)(start + len - 1)) & PAGE_MASK);
+ return start > end_page ? start : end_page;
}
static inline unsigned int blkcipher_done_slow(struct crypto_blkcipher *tfm,
@@ -155,7 +157,8 @@ static inline int blkcipher_next_slow(st
if (walk->buffer)
goto ok;
- n = bsize * 2 + (alignmask & ~(crypto_tfm_ctx_alignment() - 1));
+ n = bsize * 3 - (alignmask + 1) +
+ (alignmask & ~(crypto_tfm_ctx_alignment() - 1));
walk->buffer = kmalloc(n, GFP_ATOMIC);
if (!walk->buffer)
return blkcipher_walk_done(desc, walk, -ENOMEM);
--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] usb-skeleton leaking locks on open.
forgot to CC greg ... On Mon, Sep 24, 2007 at 09:18:22AM -0700, Mark Gross wrote: > This weekend I was hacking around with a trivial USB driver for talking > to the boot load firmware of a USB Bit Whacker. It's running the > MicroChip Pic18 boot loader firmware and I'm putting together a flash > program for writing new FW to the thing. > > Anyway in my use of the usb-skeleton.c as my starting point I discovered > my test program was getting hung up after attempting to write a buffer. > The application and driver where hung in a way that required me to > reboot to get it to clean up so I could try again. > > It turned out the code path through skel_open can grap the driver's > io_mutex lock and forget to release it. > > The following patch fixes the problem for me. > > --mgross > > Signed-off-by: Mark Gross <[EMAIL PROTECTED]> > > diff -urN -X linux-2.6.23-rc7/Documentation/dontdiff > linux-2.6.23-rc7/drivers/usb/usb-skeleton.c > linux-2.6.23-rc7-bugfix/drivers/usb/usb-skeleton.c > --- linux-2.6.23-rc7/drivers/usb/usb-skeleton.c 2007-09-24 > 08:57:54.0 -0700 > +++ linux-2.6.23-rc7-bugfix/drivers/usb/usb-skeleton.c2007-09-24 > 09:01:43.0 -0700 > @@ -125,6 +125,7 @@ > > /* save our object in the file's private structure */ > file->private_data = dev; > + mutex_unlock(>io_mutex); > > exit: > return retval; > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[31/50] Correctly close old nfsd/lockd sockets.
From: Neil Brown <[EMAIL PROTECTED]> commit 7a1fa065a0264f6b3d3003ba5635289f6583c478 in mainline. Commit aaf68cfbf2241d24d46583423f6bff5c47e088b3 added a bias to sk_inuse, so this test for an unused socket now fails. So no sockets get closed because they are old (they might get closed if the client closed them). This bug has existed since 2.6.21-rc1. Thanks to Wolfgang Walter for finding and reporting the bug. Cc: Wolfgang Walter <[EMAIL PROTECTED]> Signed-off-by: Neil Brown <[EMAIL PROTECTED]> Signed-off-by: J. Bruce Fields <[EMAIL PROTECTED]> Signed-off-by: Linus Torvalds <[EMAIL PROTECTED]> Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]> --- net/sunrpc/svcsock.c |3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) --- a/net/sunrpc/svcsock.c +++ b/net/sunrpc/svcsock.c @@ -1573,7 +1573,8 @@ svc_age_temp_sockets(unsigned long closu if (!test_and_set_bit(SK_OLD, >sk_flags)) continue; - if (atomic_read(>sk_inuse) || test_bit(SK_BUSY, >sk_flags)) + if (atomic_read(>sk_inuse) > 1 + || test_bit(SK_BUSY, >sk_flags)) continue; atomic_inc(>sk_inuse); list_move(le, _be_aged); -- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[32/50] Fix race with shared tag queue maps
From: Jens Axboe <[EMAIL PROTECTED]>
The commit in Linus upstream git tree is
f3da54ba140c6427fa4a32913e1bf406f41b5dda.
Fix race with shared tag queue maps
There's a race condition in blk_queue_end_tag() for shared tag maps,
users include stex (promise supertrak thingy) and qla2xxx. The former
at least has reported bugs in this area, not sure why we haven't seen
any for the latter. It could be because the window is narrow and that
other conditions in the qla2xxx code hide this. It's a real bug,
though, as the stex smp users can attest.
We need to ensure two things - the tag bit clearing needs to happen
AFTER we cleared the tag pointer, as the tag bit clearing/setting is
what protects this map. Secondly, we need to ensure that the visibility
of the tag pointer and tag bit clear are ordered properly.
[ I removed the SMP barriers - "test_and_clear_bit()" already implies
all the required barriers. -- Linus ]
Also see http://bugzilla.kernel.org/show_bug.cgi?id=7842
Signed-off-by: Jens Axboe <[EMAIL PROTECTED]>
Signed-off-by: Linus Torvalds <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
---
block/ll_rw_blk.c | 13 +++--
1 file changed, 7 insertions(+), 6 deletions(-)
--- a/block/ll_rw_blk.c
+++ b/block/ll_rw_blk.c
@@ -1081,12 +1081,6 @@ void blk_queue_end_tag(request_queue_t *
*/
return;
- if (unlikely(!__test_and_clear_bit(tag, bqt->tag_map))) {
- printk(KERN_ERR "%s: attempt to clear non-busy tag (%d)\n",
- __FUNCTION__, tag);
- return;
- }
-
list_del_init(>queuelist);
rq->cmd_flags &= ~REQ_QUEUED;
rq->tag = -1;
@@ -1096,6 +1090,13 @@ void blk_queue_end_tag(request_queue_t *
__FUNCTION__, tag);
bqt->tag_index[tag] = NULL;
+
+ if (unlikely(!test_and_clear_bit(tag, bqt->tag_map))) {
+ printk(KERN_ERR "%s: attempt to clear non-busy tag (%d)\n",
+ __FUNCTION__, tag);
+ return;
+ }
+
bqt->busy--;
}
--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[29/50] dir_index: error out instead of BUG on corrupt dx dirs
From: Eric Sandeen <[EMAIL PROTECTED]>
commit 3d82abae9523c33d4a16fdfdfd2bdde316d7b56a in mainline.
Convert asserts (BUGs) in dx_probe from bad on-disk data to recoverable
errors with helpful warnings. With help catching other asserts from Duane
Griffin <[EMAIL PROTECTED]>
Signed-off-by: Eric Sandeen <[EMAIL PROTECTED]>
Acked-by: Duane Griffin <[EMAIL PROTECTED]>
Acked-by: Theodore Ts'o <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
Signed-off-by: Linus Torvalds <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
---
fs/ext3/namei.c | 34 ++
fs/ext4/namei.c | 34 ++
2 files changed, 60 insertions(+), 8 deletions(-)
--- a/fs/ext3/namei.c
+++ b/fs/ext3/namei.c
@@ -380,13 +380,28 @@ dx_probe(struct dentry *dentry, struct i
entries = (struct dx_entry *) (((char *)>info) +
root->info.info_length);
- assert(dx_get_limit(entries) == dx_root_limit(dir,
- root->info.info_length));
+
+ if (dx_get_limit(entries) != dx_root_limit(dir,
+ root->info.info_length)) {
+ ext3_warning(dir->i_sb, __FUNCTION__,
+"dx entry: limit != root limit");
+ brelse(bh);
+ *err = ERR_BAD_DX_DIR;
+ goto fail;
+ }
+
dxtrace (printk("Look up %x", hash));
while (1)
{
count = dx_get_count(entries);
- assert (count && count <= dx_get_limit(entries));
+ if (!count || count > dx_get_limit(entries)) {
+ ext3_warning(dir->i_sb, __FUNCTION__,
+"dx entry: no count or count > limit");
+ brelse(bh);
+ *err = ERR_BAD_DX_DIR;
+ goto fail2;
+ }
+
p = entries + 1;
q = entries + count - 1;
while (p <= q)
@@ -424,8 +439,15 @@ dx_probe(struct dentry *dentry, struct i
if (!(bh = ext3_bread (NULL,dir, dx_get_block(at), 0, err)))
goto fail2;
at = entries = ((struct dx_node *) bh->b_data)->entries;
- assert (dx_get_limit(entries) == dx_node_limit (dir));
+ if (dx_get_limit(entries) != dx_node_limit (dir)) {
+ ext3_warning(dir->i_sb, __FUNCTION__,
+"dx entry: limit != node limit");
+ brelse(bh);
+ *err = ERR_BAD_DX_DIR;
+ goto fail2;
+ }
frame++;
+ frame->bh = NULL;
}
fail2:
while (frame >= frame_in) {
@@ -433,6 +455,10 @@ fail2:
frame--;
}
fail:
+ if (*err == ERR_BAD_DX_DIR)
+ ext3_warning(dir->i_sb, __FUNCTION__,
+"Corrupt dir inode %ld, running e2fsck is "
+"recommended.", dir->i_ino);
return NULL;
}
--- a/fs/ext4/namei.c
+++ b/fs/ext4/namei.c
@@ -380,13 +380,28 @@ dx_probe(struct dentry *dentry, struct i
entries = (struct dx_entry *) (((char *)>info) +
root->info.info_length);
- assert(dx_get_limit(entries) == dx_root_limit(dir,
- root->info.info_length));
+
+ if (dx_get_limit(entries) != dx_root_limit(dir,
+ root->info.info_length)) {
+ ext4_warning(dir->i_sb, __FUNCTION__,
+"dx entry: limit != root limit");
+ brelse(bh);
+ *err = ERR_BAD_DX_DIR;
+ goto fail;
+ }
+
dxtrace (printk("Look up %x", hash));
while (1)
{
count = dx_get_count(entries);
- assert (count && count <= dx_get_limit(entries));
+ if (!count || count > dx_get_limit(entries)) {
+ ext4_warning(dir->i_sb, __FUNCTION__,
+"dx entry: no count or count > limit");
+ brelse(bh);
+ *err = ERR_BAD_DX_DIR;
+ goto fail2;
+ }
+
p = entries + 1;
q = entries + count - 1;
while (p <= q)
@@ -424,8 +439,15 @@ dx_probe(struct dentry *dentry, struct i
if (!(bh = ext4_bread (NULL,dir, dx_get_block(at), 0, err)))
goto fail2;
at = entries = ((struct dx_node *) bh->b_data)->entries;
- assert (dx_get_limit(entries) == dx_node_limit (dir));
+ if (dx_get_limit(entries) != dx_node_limit (dir)) {
+ ext4_warning(dir->i_sb,
[30/50] ieee1394: ohci1394: fix initialization if built non-modular
From: Stefan Richter <[EMAIL PROTECTED]> Initialization of ohci1394 was broken according to one reporter if the driver was statically linked, i.e. not built as loadable module. Dmesg: PCI: Device :02:07.0 not available because of resource collisions ohci1394: Failed to enable OHCI hardware. This was reported for a Toshiba Satellite 5100-503. The cause is commit 8df4083c5291b3647e0381d3c69ab2196f5dd3b7 in Linux 2.6.19-rc1 which only served purposes of early remote debugging via FireWire. This functionality is better provided by the currently out-of-tree driver ohci1394_earlyinit. Reversal of the commit was OK'd by Andi Kleen. Same as pre-2.6.23 commit be7963b7e7f08a149e247c0bf29a4abd174e0929. Signed-off-by: Stefan Richter <[EMAIL PROTECTED]> Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]> --- drivers/ieee1394/ieee1394_core.c |2 +- drivers/ieee1394/ohci1394.c |4 +--- 2 files changed, 2 insertions(+), 4 deletions(-) --- a/drivers/ieee1394/ieee1394_core.c +++ b/drivers/ieee1394/ieee1394_core.c @@ -1279,7 +1279,7 @@ static void __exit ieee1394_cleanup(void unregister_chrdev_region(IEEE1394_CORE_DEV, 256); } -fs_initcall(ieee1394_init); /* same as ohci1394 */ +module_init(ieee1394_init); module_exit(ieee1394_cleanup); /* Exported symbols */ --- a/drivers/ieee1394/ohci1394.c +++ b/drivers/ieee1394/ohci1394.c @@ -3773,7 +3773,5 @@ static int __init ohci1394_init(void) return pci_register_driver(_pci_driver); } -/* Register before most other device drivers. - * Useful for remote debugging via physical DMA, e.g. using firescope. */ -fs_initcall(ohci1394_init); +module_init(ohci1394_init); module_exit(ohci1394_cleanup); -- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[28/50] nfs: fix oops re sysctls and V4 support
From: Alexey Dobriyan <[EMAIL PROTECTED]> commit 49af7ee181f4f516ac99eba85d3f70ed42cabe76 in mainline. NFS unregisters sysctls only if V4 support is compiled in. However, sysctl table is not V4 specific, so unregister it always. Steps to reproduce: [build nfs.ko with CONFIG_NFS_V4=n] modrobe nfs rmmod nfs ls /proc/sys Unable to handle kernel paging request at 880661c0 RIP: [] proc_sys_readdir+0xd3/0x350 PGD 203067 PUD 207063 PMD 7e216067 PTE 0 Oops: [1] SMP CPU 1 Modules linked in: lockd nfs_acl sunrpc Pid: 3335, comm: ls Not tainted 2.6.23-rc3-bloat #2 RIP: 0010:[] [] proc_sys_readdir+0xd3/0x350 RSP: 0018:81007fd93e78 EFLAGS: 00010286 RAX: 880661c0 RBX: 80466370 RCX: 880661c0 RDX: 14c0 RSI: 81007f3ad020 RDI: 81007efd8b40 RBP: 0018 R08: R09: R10: 0001 R11: 802a8570 R12: 880661c0 R13: 81007e219640 R14: 81007efd8b40 R15: 81007ded7280 FS: 2ba25ef03060() GS:81007ff81258() knlGS: CS: 0010 DS: ES: CR0: 8005003b CR2: 880661c0 CR3: 7dfaf000 CR4: 06e0 DR0: DR1: DR2: DR3: DR6: 0ff0 DR7: 0400 Process ls (pid: 3335, threadinfo 81007fd92000, task 81007d8a) Stack: 81007f3ad150 80283f30 81007fd93f48 81007efd8b40 81007ee00440 0004 000200035593 88037e9a 80466500 81007e416400 81007e219640 Call Trace: [] filldir+0x0/0xf0 [] filldir+0x0/0xf0 [] vfs_readdir+0xa7/0xc0 [] sys_getdents+0x96/0xe0 [] system_call+0x7e/0x83 Code: 41 8b 14 24 85 d2 74 dc 49 8b 44 24 08 48 85 c0 74 e7 49 3b RIP [] proc_sys_readdir+0xd3/0x350 RSP CR2: 880661c0 Kernel panic - not syncing: Fatal exception Signed-off-by: Alexey Dobriyan <[EMAIL PROTECTED]> Acked-by: Trond Myklebust <[EMAIL PROTECTED]> Cc: "J. Bruce Fields" <[EMAIL PROTECTED]> Signed-off-by: Andrew Morton <[EMAIL PROTECTED]> Signed-off-by: Linus Torvalds <[EMAIL PROTECTED]> Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]> --- fs/nfs/super.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/fs/nfs/super.c +++ b/fs/nfs/super.c @@ -181,8 +181,8 @@ void __exit unregister_nfs_fs(void) remove_shrinker(acl_shrinker); #ifdef CONFIG_NFS_V4 unregister_filesystem(_fs_type); - nfs_unregister_sysctl(); #endif + nfs_unregister_sysctl(); unregister_filesystem(_fs_type); } -- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[26/50] Leases can be hidden by flocks
From: Pavel Emelyanov <[EMAIL PROTECTED]>
commit 0e2f6db88a6900bc9db576d6b478b12ee60d61f7 in mainline.
The inode->i_flock list contains the leases, flocks and posix
locks in the specified order. However, the flocks are added in
the head of this list thus hiding the leases from F_GETLEASE
command, from time_out_leases() and other code that expects
the leases to come first.
The following example will demonstrate this:
#define _GNU_SOURCE
#include
#include
#include
#include
static void show_lease(int fd)
{
int res;
res = fcntl(fd, F_GETLEASE);
switch (res) {
case F_RDLCK:
printf("Read lease\n");
break;
case F_WRLCK:
printf("Write lease\n");
break;
case F_UNLCK:
printf("No leases\n");
break;
default:
printf("Some shit\n");
break;
}
}
int main(int argc, char **argv)
{
int fd, res;
fd = open(argv[1], O_RDONLY);
if (fd == -1) {
perror("Can't open file");
return 1;
}
res = fcntl(fd, F_SETLEASE, F_WRLCK);
if (res == -1) {
perror("Can't set lease");
return 1;
}
show_lease(fd);
if (flock(fd, LOCK_SH) == -1) {
perror("Can't flock shared");
return 1;
}
show_lease(fd);
return 0;
}
The first call to show_lease() will show the write lease set, but
the second will show no leases.
Fix the flock adding so that the leases always stay in the head
of this list.
Found during making the flocks pid-namespaces aware.
Signed-off-by: Pavel Emelyanov <[EMAIL PROTECTED]>
Acked-by: "J. Bruce Fields" <[EMAIL PROTECTED]>
Cc: Trond Myklebust <[EMAIL PROTECTED]>
Cc: Andrew Morton <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
Signed-off-by: Linus Torvalds <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
---
fs/locks.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/fs/locks.c
+++ b/fs/locks.c
@@ -786,7 +786,7 @@ find_conflict:
if (request->fl_flags & FL_ACCESS)
goto out;
locks_copy_lock(new_fl, request);
- locks_insert_lock(>i_flock, new_fl);
+ locks_insert_lock(before, new_fl);
new_fl = NULL;
error = 0;
--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[27/50] ext34: ensure do_split leaves enough free space in both blocks
From: Eric Sandeen <[EMAIL PROTECTED]>
commit ef2b02d3e617cb0400eedf2668f86215e1b0e6af in mainline.
The do_split() function for htree dir blocks is intended to split a leaf
block to make room for a new entry. It sorts the entries in the original
block by hash value, then moves the last half of the entries to the new
block - without accounting for how much space this actually moves. (IOW,
it moves half of the entry *count* not half of the entry *space*). If by
chance we have both large & small entries, and we move only the smallest
entries, and we have a large new entry to insert, we may not have created
enough space for it.
The patch below stores each record size when calculating the dx_map, and
then walks the hash-sorted dx_map, calculating how many entries must be
moved to more evenly split the existing entries between the old block and
the new block, guaranteeing enough space for the new entry.
The dx_map "offs" member is reduced to u16 so that the overall map size
does not change - it is temporarily stored at the end of the new block, and
if it grows too large it may be overwritten. By making offs and size both
u16, we won't grow the map size.
Also add a few comments to the functions involved.
This fixes the testcase reported by [EMAIL PROTECTED] on the
linux-ext4 list, "ext3 dir_index causes an error"
Thanks to Andreas Dilger for discussing the problem & solution with me.
Signed-off-by: Eric Sandeen <[EMAIL PROTECTED]>
Signed-off-by: Andreas Dilger <[EMAIL PROTECTED]>
Tested-by: Junjiro Okajima <[EMAIL PROTECTED]>
Cc: Theodore Ts'o <[EMAIL PROTECTED]>
Cc: ext4 <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
Signed-off-by: Linus Torvalds <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
---
fs/ext3/namei.c | 39 +++
fs/ext4/namei.c | 39 +++
2 files changed, 70 insertions(+), 8 deletions(-)
--- a/fs/ext3/namei.c
+++ b/fs/ext3/namei.c
@@ -140,7 +140,8 @@ struct dx_frame
struct dx_map_entry
{
u32 hash;
- u32 offs;
+ u16 offs;
+ u16 size;
};
#ifdef CONFIG_EXT3_INDEX
@@ -671,6 +672,10 @@ errout:
* Directory block splitting, compacting
*/
+/*
+ * Create map of hash values, offsets, and sizes, stored at end of block.
+ * Returns number of entries mapped.
+ */
static int dx_make_map (struct ext3_dir_entry_2 *de, int size,
struct dx_hash_info *hinfo, struct dx_map_entry
*map_tail)
{
@@ -684,7 +689,8 @@ static int dx_make_map (struct ext3_dir_
ext3fs_dirhash(de->name, de->name_len, );
map_tail--;
map_tail->hash = h.hash;
- map_tail->offs = (u32) ((char *) de - base);
+ map_tail->offs = (u16) ((char *) de - base);
+ map_tail->size = le16_to_cpu(de->rec_len);
count++;
cond_resched();
}
@@ -694,6 +700,7 @@ static int dx_make_map (struct ext3_dir_
return count;
}
+/* Sort map by hash value */
static void dx_sort_map (struct dx_map_entry *map, unsigned count)
{
struct dx_map_entry *p, *q, *top = map + count - 1;
@@ -1081,6 +1088,10 @@ static inline void ext3_set_de_type(stru
}
#ifdef CONFIG_EXT3_INDEX
+/*
+ * Move count entries from end of map between two memory locations.
+ * Returns pointer to last entry moved.
+ */
static struct ext3_dir_entry_2 *
dx_move_dirents(char *from, char *to, struct dx_map_entry *map, int count)
{
@@ -1099,6 +1110,10 @@ dx_move_dirents(char *from, char *to, st
return (struct ext3_dir_entry_2 *) (to - rec_len);
}
+/*
+ * Compact each dir entry in the range to the minimal rec_len.
+ * Returns pointer to last entry in range.
+ */
static struct ext3_dir_entry_2* dx_pack_dirents(char *base, int size)
{
struct ext3_dir_entry_2 *next, *to, *prev, *de = (struct
ext3_dir_entry_2 *) base;
@@ -1121,6 +1136,11 @@ static struct ext3_dir_entry_2* dx_pack_
return prev;
}
+/*
+ * Split a full leaf block to make room for a new dir entry.
+ * Allocate a new block, and move entries so that they are approx. equally
full.
+ * Returns pointer to de in block into which the new entry will be inserted.
+ */
static struct ext3_dir_entry_2 *do_split(handle_t *handle, struct inode *dir,
struct buffer_head **bh,struct dx_frame *frame,
struct dx_hash_info *hinfo, int *error)
@@ -1132,7 +1152,7 @@ static struct ext3_dir_entry_2 *do_split
u32 hash2;
struct dx_map_entry *map;
char *data1 = (*bh)->b_data, *data2;
- unsigned split;
+ unsigned split, move, size, i;
struct ext3_dir_entry_2 *de = NULL, *de2;
int err = 0;
@@ -1160,8 +1180,19 @@ static struct ext3_dir_entry_2 *do_split
count = dx_make_map ((struct ext3_dir_entry_2 *) data1,
[25/50] futex_compat: fix list traversal bugs
From: Arnd Bergmann <[EMAIL PROTECTED]>
commit 179c85ea53bef807621f335767e41e23f86f01df in mainline.
The futex list traversal on the compat side appears to have
a bug.
It's loop termination condition compares:
while (compat_ptr(uentry) != >list)
But that can't be right because "uentry" has the special
"pi" indicator bit still potentially set at bit 0. This
is cleared by fetch_robust_entry() into the "entry"
return value.
What this seems to mean is that the list won't terminate
when list iteration gets back to the the head. And we'll
also process the list head like a normal entry, which could
cause all kinds of problems.
So we should check for equality with "entry". That pointer
is of the non-compat type so we have to do a little casting
to keep the compiler and sparse happy.
The same problem can in theory occur with the 'pending'
variable, although that has not been reported from users
so far.
Based on the original patch from David Miller.
Acked-by: Ingo Molnar <[EMAIL PROTECTED]>
Cc: Thomas Gleixner <[EMAIL PROTECTED]>
Cc: David Miller <[EMAIL PROTECTED]>
Signed-off-by: Arnd Bergmann <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
Signed-off-by: Linus Torvalds <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
---
kernel/futex_compat.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/kernel/futex_compat.c
+++ b/kernel/futex_compat.c
@@ -61,10 +61,10 @@ void compat_exit_robust_list(struct task
if (fetch_robust_entry(, ,
>list_op_pending, ))
return;
- if (upending)
+ if (pending)
handle_futex_death((void __user *)pending + futex_offset, curr,
pip);
- while (compat_ptr(uentry) != >list) {
+ while (entry != (struct robust_list __user *) >list) {
/*
* A pending lock might already be on the list, so
* dont process it twice:
--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/5] Revert recent removal of set_curr_task()
On Tue, Sep 18, 2007 at 09:36:30PM +0200, dimm wrote:
> here is a few cleanup/simplification/optimization(s)
> based on the recent modifications in the sched-dev tree.
[refer http://marc.info/?l=linux-kernel=119014449807290]
[snip]
> (3) rework enqueue/dequeue_entity() to get rid of
> sched_class::set_curr_task()
Dmitry/Ingo,
I am sorry for not having reviewed this change properly, but I
think we need to revert this.
Some problems with current sched-devel code introduced by this change:
1. SCHED_NORMAL->SCHED_RT transition of current task
a. we reset current->se.exec_start to 0 (update_stats_curr_end)
and not initialize it again. As a result, update_curr_rt()
can calculate bogus values
b. (for CONFIG_FAIR_GROUP_SCHED):
i) higher level entities of current task arent put back
on their cfs_rq
ii) their corresponding cfs_rq->curr is not set to NULL
iii) update_stats_wait_start() not called for higher
level entities of current task.
These functions are usually accomplished by put_prev_entity()
2. SCHED_RT->SCHED_NORMAL
a. (minor) we don't initialize se->prev_sum_exec_runtime
in enqueue_entity() under if (set_curr) { } block.
As a result the current task may get preempted
almost immediately?
b. (for CONFIG_FAIR_GROUP_SCHED):
i) higher level entities of current task arent taken out
of their cfs_rq
ii) their corresponding cfs_rq->curr is not set
iii) update_stats_wait_end() and update_stats_curr_start()
arent called for higher level entities of
current task.
These functions are usually accomplished by set_next_entity()
(similar problems exist while changing groups)
In theory its possible to solve these problems w/o reintroducing
set_curr_task(). I tried doing so, but found it clutters dequeue_entity
and enqueue_entity a lot and makes it less readable. It will duplicate what
put_prev_entity() and set_next_entity() are supposed to do. Moreoever
it is slightly inefficient to do all these in dequeue_entity() if we
consider that dequeue_entity can be called on current task for other
reasons as well (like when it is abt to sleep or change its nice value).
Considering these, IMHO, it's best to re-introduce set_curr_task()
and use put_prev_task/set_curr_task whenever the current task is
changing policies/groups.
Let me know what you think.
--
Revert removal of set_curr_task.
Use put_prev_task/set_curr_task when changing groups/policies
Signed-off-by : Srivatsa Vaddagiri < [EMAIL PROTECTED]>
Signed-off-by : Dhaval Giani <[EMAIL PROTECTED]>
---
include/linux/sched.h |1
kernel/sched.c | 34 ++--
kernel/sched_fair.c | 68 ++--
kernel/sched_idletask.c |5 +++
kernel/sched_rt.c |8 +
5 files changed, 72 insertions(+), 44 deletions(-)
Index: current/include/linux/sched.h
===
--- current.orig/include/linux/sched.h
+++ current/include/linux/sched.h
@@ -870,6 +870,7 @@ struct sched_class {
struct sched_domain *sd, enum cpu_idle_type idle,
int *all_pinned, int *this_best_prio);
+ void (*set_curr_task) (struct rq *rq);
void (*task_tick) (struct rq *rq, struct task_struct *p);
void (*task_new) (struct rq *rq, struct task_struct *p);
};
Index: current/kernel/sched.c
===
--- current.orig/kernel/sched.c
+++ current/kernel/sched.c
@@ -3916,7 +3916,7 @@ EXPORT_SYMBOL(sleep_on_timeout);
void rt_mutex_setprio(struct task_struct *p, int prio)
{
unsigned long flags;
- int oldprio, on_rq;
+ int oldprio, on_rq, running;
struct rq *rq;
BUG_ON(prio < 0 || prio > MAX_PRIO);
@@ -3926,8 +3926,12 @@ void rt_mutex_setprio(struct task_struct
oldprio = p->prio;
on_rq = p->se.on_rq;
- if (on_rq)
+ running = task_running(rq, p);
+ if (on_rq) {
dequeue_task(rq, p, 0);
+ if (running)
+ p->sched_class->put_prev_task(rq, p);
+ }
if (rt_prio(prio))
p->sched_class = _sched_class;
@@ -3937,13 +3941,15 @@ void rt_mutex_setprio(struct task_struct
p->prio = prio;
if (on_rq) {
+ if (running)
+ p->sched_class->set_curr_task(rq);
enqueue_task(rq, p, 0);
/*
* Reschedule if we are currently
[23/50] Fix "Fix DAC960 driver on machines which dont support 64-bit DMA"
From: Andrew Morton <[EMAIL PROTECTED]> commit 3558c9b3232b5f0fd9f32043a191eca20fca64c6 in mainline. sparc32: drivers/block/DAC960.c: In function 'DAC960_V1_EnableMemoryMailboxInterface': drivers/block/DAC960.c:1168: error: 'DMA_32BIT_MASK' undeclared (first use in this function) drivers/block/DAC960.c:1168: error: (Each undeclared identifier is reported only Cc: <[EMAIL PROTECTED]> Cc: Alessandro Polverini <[EMAIL PROTECTED]> Cc: Jeff Garzik <[EMAIL PROTECTED]> Cc: Matthew Wilcox <[EMAIL PROTECTED]> Signed-off-by: Andrew Morton <[EMAIL PROTECTED]> Signed-off-by: Linus Torvalds <[EMAIL PROTECTED]> Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]> --- drivers/block/DAC960.c |1 + 1 file changed, 1 insertion(+) --- a/drivers/block/DAC960.c +++ b/drivers/block/DAC960.c @@ -31,6 +31,7 @@ #include #include #include +#include #include #include #include -- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[24/50] firewire: fw-ohci: ignore failure of pci_set_power_state (fix suspend regression)
From: Stefan Richter <[EMAIL PROTECTED]>
Minor regression since 2.6.22-rc1: If the experimental firewire-ohci
driver instead of ohci1394 was loaded, iBook G3 and older PowerBooks
refused to suspend.
Same as commit 5511142870046a7bed947d51ec9b320856ee120a plus format
string touch-ups from 8a8cea2734808522f02941ea16125810ee42c9c7,
"firewire: missing newline in printk". Original patch description:
Fixes (papers over) "Sleep problems with kernels >= 2.6.21 on powerpc",
http://lkml.org/lkml/2007/8/25/155. The issue is that the FireWire
controller's pci_dev.current_state of iBook G3 and presumably older
PowerBooks is still in PCI_UNKNOWN instead of PCI_D0 when the firewire
driver's .suspend method is called.
Like it was suggested earlier in http://lkml.org/lkml/2006/10/24/13, we
do not fail .suspend anymore if pci_set_power_state failed.
Signed-off-by: Stefan Richter <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
---
drivers/firewire/fw-ohci.c | 10 --
1 file changed, 4 insertions(+), 6 deletions(-)
--- a/drivers/firewire/fw-ohci.c
+++ b/drivers/firewire/fw-ohci.c
@@ -1934,14 +1934,12 @@ static int pci_suspend(struct pci_dev *p
free_irq(pdev->irq, ohci);
err = pci_save_state(pdev);
if (err) {
- fw_error("pci_save_state failed with %d", err);
+ fw_error("pci_save_state failed with %d\n", err);
return err;
}
err = pci_set_power_state(pdev, pci_choose_state(pdev, state));
- if (err) {
- fw_error("pci_set_power_state failed with %d", err);
- return err;
- }
+ if (err)
+ fw_error("pci_set_power_state failed with %d\n", err);
return 0;
}
@@ -1955,7 +1953,7 @@ static int pci_resume(struct pci_dev *pd
pci_restore_state(pdev);
err = pci_enable_device(pdev);
if (err) {
- fw_error("pci_enable_device failed with %d", err);
+ fw_error("pci_enable_device failed with %d\n", err);
return err;
}
--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[21/50] afs: mntput called before dput
From: Andreas Gruenbacher <[EMAIL PROTECTED]>
commit 1a1a1a758bf0107d1f78ff1d622f45987803d894 in mainline.
dput must be called before mntput here.
Signed-off-by: Andreas Gruenbacher <[EMAIL PROTECTED]>
Acked-By: David Howells <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
Signed-off-by: Linus Torvalds <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
---
fs/afs/mntpt.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/fs/afs/mntpt.c
+++ b/fs/afs/mntpt.c
@@ -235,8 +235,8 @@ static void *afs_mntpt_follow_link(struc
err = do_add_mount(newmnt, nd, MNT_SHRINKABLE, _vfsmounts);
switch (err) {
case 0:
- mntput(nd->mnt);
dput(nd->dentry);
+ mntput(nd->mnt);
nd->mnt = newmnt;
nd->dentry = dget(newmnt->mnt_root);
schedule_delayed_work(_mntpt_expiry_timer,
--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[22/50] Fix DAC960 driver on machines which dont support 64-bit DMA
From: Matthew Wilcox <[EMAIL PROTECTED]>
commit 868047fcbb85dbb44ddd98c336fef83236a2c06a in mainline.
Addresses http://bugzilla.kernel.org/show_bug.cgi?id=8942
Use PCI_DMA_* constants instead of own private definitions Fall back to
32-bit DMA mask if a 64-bit one fails
Signed-off-by: Matthew Wilcox <[EMAIL PROTECTED]>
Acked-by: Jeff Garzik <[EMAIL PROTECTED]>
Tested-by: Lars <[EMAIL PROTECTED]>
Cc: Alessandro Polverini <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
Signed-off-by: Linus Torvalds <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
---
drivers/block/DAC960.c | 17 ++---
drivers/block/DAC960.h |7 ---
2 files changed, 10 insertions(+), 14 deletions(-)
--- a/drivers/block/DAC960.c
+++ b/drivers/block/DAC960.c
@@ -17,8 +17,8 @@
*/
-#define DAC960_DriverVersion "2.5.48"
-#define DAC960_DriverDate "14 May 2006"
+#define DAC960_DriverVersion "2.5.49"
+#define DAC960_DriverDate "21 Aug 2007"
#include
@@ -1165,9 +1165,9 @@ static bool DAC960_V1_EnableMemoryMailbo
int i;
- if (pci_set_dma_mask(Controller->PCIDevice, DAC690_V1_PciDmaMask))
+ if (pci_set_dma_mask(Controller->PCIDevice, DMA_32BIT_MASK))
return DAC960_Failure(Controller, "DMA mask out of range");
- Controller->BounceBufferLimit = DAC690_V1_PciDmaMask;
+ Controller->BounceBufferLimit = DMA_32BIT_MASK;
if ((hw_type == DAC960_PD_Controller) || (hw_type == DAC960_P_Controller)) {
CommandMailboxesSize = 0;
@@ -1368,9 +1368,12 @@ static bool DAC960_V2_EnableMemoryMailbo
dma_addr_t CommandMailboxDMA;
DAC960_V2_CommandStatus_T CommandStatus;
- if (pci_set_dma_mask(Controller->PCIDevice, DAC690_V2_PciDmaMask))
- return DAC960_Failure(Controller, "DMA mask out of range");
- Controller->BounceBufferLimit = DAC690_V2_PciDmaMask;
+ if (!pci_set_dma_mask(Controller->PCIDevice, DMA_64BIT_MASK))
+ Controller->BounceBufferLimit = DMA_64BIT_MASK;
+ else if (!pci_set_dma_mask(Controller->PCIDevice, DMA_32BIT_MASK))
+ Controller->BounceBufferLimit = DMA_32BIT_MASK;
+ else
+ return DAC960_Failure(Controller, "DMA mask out of range");
/* This is a temporary dma mapping, used only in the scope of this function
*/
CommandMailbox = pci_alloc_consistent(PCI_Device,
--- a/drivers/block/DAC960.h
+++ b/drivers/block/DAC960.h
@@ -61,13 +61,6 @@
#define DAC960_V2_MaxPhysicalDevices 272
/*
- Define the pci dma mask supported by DAC960 V1 and V2 Firmware Controlers
- */
-
-#define DAC690_V1_PciDmaMask 0x
-#define DAC690_V2_PciDmaMask 0xULL
-
-/*
Define a 32/64 bit I/O Address data type.
*/
--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[18/50] splice: fix direct splice error handling
From: Jens Axboe <[EMAIL PROTECTED]> This is a splice patch for 2.6.22 and 2.6.21 (and earlier, I did not check. Let me know if you still maintain older stable trees!). It fixes an infinite loop in do_splice_direct(), when there's either nothing to read or nothing to write and blocking doesn't help. It could be things like running out of disk space. We need to exit both for failure and zero return, or we could be going around forever. This got fixed in 2.6.23-git with commit 51a92c0f6ce8fa85fa0e18ecda1d847e606e8066 Herbert Poetzl <[EMAIL PROTECTED]> noticed this bug in 2.6.22, and has verified that this minimal fix works. Signed-off-by: Jens Axboe <[EMAIL PROTECTED]> Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]> --- fs/splice.c |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) --- a/fs/splice.c +++ b/fs/splice.c @@ -1011,7 +1011,7 @@ long do_splice_direct(struct file *in, l max_read_len = min(len, (size_t)(PIPE_BUFFERS*PAGE_SIZE)); ret = do_splice_to(in, ppos, pipe, max_read_len, flags); - if (unlikely(ret < 0)) + if (unlikely(ret <= 0)) goto out_release; read_len = ret; @@ -1023,7 +1023,7 @@ long do_splice_direct(struct file *in, l */ ret = do_splice_from(pipe, out, _off, read_len, flags & ~SPLICE_F_NONBLOCK); - if (unlikely(ret < 0)) + if (unlikely(ret <= 0)) goto out_release; bytes += ret; -- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[19/50] rpc: fix garbage in printk in svc_tcp_accept()
From: Wolfgang Walter <[EMAIL PROTECTED]> commit 9db619e66503494e41159de3c76fafabe80d016b in mainline. we upgraded the kernel of a nfs-server from 2.6.17.11 to 2.6.22.6. Since then we get the message lockd: too many open TCP sockets, consider increasing the number of nfsd threads lockd: last TCP connect from ^\\236^\??^D These random characters in the second line are caused by a bug in svc_tcp_accept. (Note: there are two previous __svc_print_addr(sin, buf, sizeof(buf)) calls in this function, either of which would initialize buf correctly; but both are inside "if"'s and are not necessarily executed. This is less obvious in the second case, which is inside a dprintk(), which is a macro which expands to an if statement.) Signed-off-by: Wolfgang Walter <[EMAIL PROTECTED]> Signed-off-by: J. Bruce Fields <[EMAIL PROTECTED]> Signed-off-by: Linus Torvalds <[EMAIL PROTECTED]> Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]> --- net/sunrpc/svcsock.c |3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) --- a/net/sunrpc/svcsock.c +++ b/net/sunrpc/svcsock.c @@ -1090,7 +1090,8 @@ svc_tcp_accept(struct svc_sock *svsk) serv->sv_name); printk(KERN_NOTICE "%s: last TCP connect from %s\n", - serv->sv_name, buf); + serv->sv_name, __svc_print_addr(sin, + buf, sizeof(buf))); } /* * Always select the oldest socket. It's not fair, -- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[20/50] disable sys_timerfd()
From: Andrew Morton <[EMAIL PROTECTED]> commit e42601973b1bce1d2987f82159c1ebeaccc6b310 in mainline. There is still some confusion and disagreement over what this interface should actually do. So it is best that we disable it in 2.6.23 until we get that fully sorted out. (sys_timerfd() was present in 2.6.22 but it was apparently broken, so here we assume that nobody is using it yet). Cc: Michael Kerrisk <[EMAIL PROTECTED]> Cc: Davide Libenzi <[EMAIL PROTECTED]> Acked-by: Linus Torvalds <[EMAIL PROTECTED]> Signed-off-by: Andrew Morton <[EMAIL PROTECTED]> Signed-off-by: Linus Torvalds <[EMAIL PROTECTED]> Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]> --- init/Kconfig |1 + 1 file changed, 1 insertion(+) --- a/init/Kconfig +++ b/init/Kconfig @@ -505,6 +505,7 @@ config SIGNALFD config TIMERFD bool "Enable timerfd() system call" if EMBEDDED depends on ANON_INODES + depends on BROKEN default y help Enable the timerfd() system call that allows to receive timer -- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[16/50] hwmon: End of I/O region off-by-one
From: Jean Delvare <[EMAIL PROTECTED]>
Fix an off-by-one error in the I/O region declaration of two
hardware monitoring drivers (lm78 and w83781d.) We were requesting
one extra port at the end of the region.
This is a regression in 2.6.22 and could prevent other drivers from
loading properly.
Already applied to Linus' tree for 2.6.23:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=15bde2f1a8e819213f54314505a5a0509673109b
Signed-off-by: Jean Delvare <[EMAIL PROTECTED]>
Signed-off-by: Mark M. Hoffman <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
---
drivers/hwmon/lm78.c|2 +-
drivers/hwmon/w83781d.c |2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
--- a/drivers/hwmon/lm78.c
+++ b/drivers/hwmon/lm78.c
@@ -882,7 +882,7 @@ static int __init lm78_isa_device_add(un
{
struct resource res = {
.start = address,
- .end= address + LM78_EXTENT,
+ .end= address + LM78_EXTENT - 1,
.name = "lm78",
.flags = IORESOURCE_IO,
};
--- a/drivers/hwmon/w83781d.c
+++ b/drivers/hwmon/w83781d.c
@@ -1746,7 +1746,7 @@ w83781d_isa_device_add(unsigned short ad
{
struct resource res = {
.start = address,
- .end= address + W83781D_EXTENT,
+ .end= address + W83781D_EXTENT - 1,
.name = "w83781d",
.flags = IORESOURCE_IO,
};
--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[17/50] Fix debug regression in video/pwc
From: Jean Delvare <[EMAIL PROTECTED]>
Commit 85237f202d46d55c1bffe0c5b1aa3ddc0f1dce4d introduced the
following warning:
drivers/media/video/pwc/pwc-if.c: In function "pwc_video_close":
drivers/media/video/pwc/pwc-if.c:1211: warning: "i" may be used uninitialized
in this function
This is true, and can cause a broken debug message to be logged.
Here's a fix.
Fix is already in Linus' tree for 2.6.23:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=7b9fbc3e30f785412a26819aa4daf0b6c27f6c53
Signed-off-by: Jean Delvare <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
---
drivers/media/video/pwc/pwc-if.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/media/video/pwc/pwc-if.c
+++ b/drivers/media/video/pwc/pwc-if.c
@@ -1243,7 +1243,7 @@ static int pwc_video_close(struct inode
PWC_ERROR("Failed to power down camera (%d)\n",
i);
}
pdev->vopen--;
- PWC_DEBUG_OPEN("<< video_close() vopen=%d\n", i);
+ PWC_DEBUG_OPEN("<< video_close() vopen=%d\n", pdev->vopen);
} else {
pwc_cleanup(pdev);
/* Free memory (don't set pdev to 0 just yet) */
--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[14/50] JFFS2: fix write deadlock regression
From: Jason Lunz <[EMAIL PROTECTED]> Changeset fc0e01974c7530b7634a63ee3fcc57b845ea from mainline. I've bisected the deadlock when many small appends are done on jffs2 down to this commit: commit 6fe6900e1e5b6fa9e5c59aa5061f244fe3f467e2 Author: Nick Piggin <[EMAIL PROTECTED]> Date: Sun May 6 14:49:04 2007 -0700 mm: make read_cache_page synchronous Ensure pages are uptodate after returning from read_cache_page, which allows us to cut out most of the filesystem-internal PageUptodate calls. I didn't have a great look down the call chains, but this appears to fixes 7 possible use-before uptodate in hfs, 2 in hfsplus, 1 in jfs, a few in ecryptfs, 1 in jffs2, and a possible cleared data overwritten with readpage in block2mtd. All depending on whether the filler is async and/or can return with a !uptodate page. It introduced a wait to read_cache_page, as well as a read_cache_page_async function equivalent to the old read_cache_page without any callers. Switching jffs2_gc_fetch_page to read_cache_page_async for the old behavior makes the deadlocks go away, but maybe reintroduces the use-before-uptodate problem? I don't understand the mm/fs interaction well enough to say. [It's fine. dwmw2.] Signed-off-by: Jason Lunz <[EMAIL PROTECTED]> Signed-off-by: David Woodhouse <[EMAIL PROTECTED]> Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]> --- fs/jffs2/fs.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/fs/jffs2/fs.c +++ b/fs/jffs2/fs.c @@ -627,7 +627,7 @@ unsigned char *jffs2_gc_fetch_page(struc struct inode *inode = OFNI_EDONI_2SFFJ(f); struct page *pg; - pg = read_cache_page(inode->i_mapping, offset >> PAGE_CACHE_SHIFT, + pg = read_cache_page_async(inode->i_mapping, offset >> PAGE_CACHE_SHIFT, (void *)jffs2_do_readpage_unlock, inode); if (IS_ERR(pg)) return (void *)pg; -- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[15/50] V4L: cx88: Avoid a NULL pointer dereference during mpeg_open()
From: Steven Toth <[EMAIL PROTECTED]>
(cherry picked from commit 48200baeab95fd39a7f4c4f3536c7142a64ac335)
[PATCH] V4L: cx88: Avoid a NULL pointer dereference during mpeg_open()
Bug: With a hardware encoder board installed as cx88[1] and a
non-encoder boards installed as cx88[0], an OOPS is generated
during cx8802_get_device() called from mpeg_open().
Signed-off-by: Steven Toth <[EMAIL PROTECTED]>
Signed-off-by: Mauro Carvalho Chehab <[EMAIL PROTECTED]>
Signed-off-by: Michael Krufky <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
---
drivers/media/video/cx88/cx88-mpeg.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/media/video/cx88/cx88-mpeg.c
+++ b/drivers/media/video/cx88/cx88-mpeg.c
@@ -580,7 +580,7 @@ struct cx8802_dev * cx8802_get_device(st
list_for_each(list,_devlist) {
h = list_entry(list, struct cx8802_dev, devlist);
- if (h->mpeg_dev->minor == minor)
+ if (h->mpeg_dev && h->mpeg_dev->minor == minor)
return h;
}
--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[12/50] 3w-9xxx: Fix dma mask setting
From: Adam Radford <[EMAIL PROTECTED]>
[SCSI] 3w-9xxx: Fix dma mask setting
Extracted from commit 0e78d158b67fba3977f577f293c323359d80dd0e
The attached patch updates the 3ware 9000 driver:
- Fix dma mask setting to fallback to 32-bit if 64-bit fails.
Signed-off-by: Adam Radford <[EMAIL PROTECTED]>
Signed-off-by: James Bottomley <[EMAIL PROTECTED]>
Signed-off-by: Chuck Ebbert <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
---
drivers/scsi/3w-9xxx.c | 18 +++---
1 file changed, 11 insertions(+), 7 deletions(-)
--- a/drivers/scsi/3w-9xxx.c
+++ b/drivers/scsi/3w-9xxx.c
@@ -4,7 +4,7 @@
Written By: Adam Radford <[EMAIL PROTECTED]>
Modifications By: Tom Couch <[EMAIL PROTECTED]>
- Copyright (C) 2004-2006 Applied Micro Circuits Corporation.
+ Copyright (C) 2004-2007 Applied Micro Circuits Corporation.
This program is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
@@ -69,6 +69,7 @@
2.26.02.008 - Free irq handler in __twa_shutdown().
Serialize reset code.
Add support for 9650SE controllers.
+ 2.26.02.009 - Fix dma mask setting to fallback to 32-bit if 64-bit fails.
*/
#include
@@ -92,7 +93,7 @@
#include "3w-9xxx.h"
/* Globals */
-#define TW_DRIVER_VERSION "2.26.02.008"
+#define TW_DRIVER_VERSION "2.26.02.009"
static TW_Device_Extension *twa_device_extension_list[TW_MAX_SLOT];
static unsigned int twa_device_extension_count;
static int twa_major = -1;
@@ -2063,11 +2064,14 @@ static int __devinit twa_probe(struct pc
pci_set_master(pdev);
- retval = pci_set_dma_mask(pdev, sizeof(dma_addr_t) > 4 ? DMA_64BIT_MASK
: DMA_32BIT_MASK);
- if (retval) {
- TW_PRINTK(host, TW_DRIVER, 0x23, "Failed to set dma mask");
- goto out_disable_device;
- }
+ if (pci_set_dma_mask(pdev, DMA_64BIT_MASK)
+ || pci_set_consistent_dma_mask(pdev, DMA_64BIT_MASK))
+ if (pci_set_dma_mask(pdev, DMA_32BIT_MASK)
+ || pci_set_consistent_dma_mask(pdev, DMA_32BIT_MASK)) {
+ TW_PRINTK(host, TW_DRIVER, 0x23, "Failed to set dma
mask");
+ retval = -ENODEV;
+ goto out_disable_device;
+ }
host = scsi_host_alloc(_template, sizeof(TW_Device_Extension));
if (!host) {
--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[13/50] MTD: Initialise s_flags in get_sb_mtd_aux()
From: David Howells <[EMAIL PROTECTED]>
changeset 48440e893d700fb8f0de95fa7d748b711d290365 from mainline.
Initialise s_flags in get_sb_mtd_aux() from the flags parameter.
Signed-off-by: David Howells <[EMAIL PROTECTED]>
Signed-off-by: David Woodhouse <[EMAIL PROTECTED]>
Cc: Jason Lunz <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
---
drivers/mtd/mtdsuper.c |2 ++
1 file changed, 2 insertions(+)
--- a/drivers/mtd/mtdsuper.c
+++ b/drivers/mtd/mtdsuper.c
@@ -70,6 +70,8 @@ static int get_sb_mtd_aux(struct file_sy
DEBUG(1, "MTDSB: New superblock for device %d (\"%s\")\n",
mtd->index, mtd->name);
+ sb->s_flags = flags;
+
ret = fill_super(sb, data, flags & MS_SILENT ? 1 : 0);
if (ret < 0) {
up_write(>s_umount);
--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[11/50] POWERPC: Flush registers to proper task context
From: Kumar Gala <[EMAIL PROTECTED]> commit 0ee6c15e7ba7b36a217cdadb292eeaf32a057a59 in mainline. When we flush register state for FP, Altivec, or SPE in flush_*_to_thread we need to respect the task_struct that the caller has passed to us. Most cases we are called with current, however sometimes (ptrace) we may be passed a different task_struct. This showed up when using gdbserver debugging a simple program that used floating point. When gdb tried to show the FP regs they all showed up as 0, because the child's FP registers were never properly flushed to memory. Signed-off-by: Kumar Gala <[EMAIL PROTECTED]> Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]> --- arch/powerpc/kernel/process.c |6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) --- a/arch/powerpc/kernel/process.c +++ b/arch/powerpc/kernel/process.c @@ -83,7 +83,7 @@ void flush_fp_to_thread(struct task_stru */ BUG_ON(tsk != current); #endif - giveup_fpu(current); + giveup_fpu(tsk); } preempt_enable(); } @@ -143,7 +143,7 @@ void flush_altivec_to_thread(struct task #ifdef CONFIG_SMP BUG_ON(tsk != current); #endif - giveup_altivec(current); + giveup_altivec(tsk); } preempt_enable(); } @@ -182,7 +182,7 @@ void flush_spe_to_thread(struct task_str #ifdef CONFIG_SMP BUG_ON(tsk != current); #endif - giveup_spe(current); + giveup_spe(tsk); } preempt_enable(); } -- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[10/50] ACPI: Validate XSDT, use RSDT if XSDT fails
From: Zhao Yakui <[EMAIL PROTECTED]>
commit 9f3119b70cf189530f1b46a006a052e171a1622f in mainline.
ACPI 1.0 used an RSDT with 32-bit physical addresses.
ACPI 2.0 adds an XSDT with 32-bit physical addresses.
An ACPI 2.0 aware OS is supposed to use the XSDT
(when present) instead of the RSDT.
However, several systems have failed because the XSDT
contains NULL entries -- while it is missing pointers
to needed tables, such as SSDTs.
When we find an XSDT with NULL entries, discard it
and use the ACPI 1.0 RSDT instead.
http://bugzilla.kernel.org/show_bug.cgi?id=8630
Signed-off-by: Zhao Yakui <[EMAIL PROTECTED]>
Cc: Vincet Fortier <[EMAIL PROTECTED]>
Signed-off-by: Len Brown <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
---
drivers/acpi/tables/tbutils.c | 71 ++
1 file changed, 71 insertions(+)
--- a/drivers/acpi/tables/tbutils.c
+++ b/drivers/acpi/tables/tbutils.c
@@ -51,6 +51,65 @@ ACPI_MODULE_NAME("tbutils")
static acpi_physical_address
acpi_tb_get_root_table_entry(u8 * table_entry,
acpi_native_uint table_entry_size);
+/***
+ *
+ * FUNCTION:acpi_tb_check_xsdt
+ *
+ * PARAMETERS: address- Pointer to the XSDT
+ *
+ * RETURN: status
+ * AE_OK - XSDT is okay
+ * AE_NO_MEMORY - can't map XSDT
+ * AE_INVALID_TABLE_LENGTH - invalid table length
+ * AE_NULL_ENTRY - XSDT has NULL entry
+ *
+ * DESCRIPTION: validate XSDT
+**/
+
+static acpi_status
+acpi_tb_check_xsdt(acpi_physical_address address)
+{
+ struct acpi_table_header *table;
+ u32 length;
+ u64 xsdt_entry_address;
+ u8 *table_entry;
+ u32 table_count;
+ int i;
+
+ table = acpi_os_map_memory(address, sizeof(struct acpi_table_header));
+ if (!table)
+ return AE_NO_MEMORY;
+
+ length = table->length;
+ acpi_os_unmap_memory(table, sizeof(struct acpi_table_header));
+ if (length < sizeof(struct acpi_table_header))
+ return AE_INVALID_TABLE_LENGTH;
+
+ table = acpi_os_map_memory(address, length);
+ if (!table)
+ return AE_NO_MEMORY;
+
+ /* Calculate the number of tables described in XSDT */
+ table_count =
+ (u32) ((table->length -
+ sizeof(struct acpi_table_header)) / sizeof(u64));
+ table_entry =
+ ACPI_CAST_PTR(u8, table) + sizeof(struct acpi_table_header);
+ for (i = 0; i < table_count; i++) {
+ ACPI_MOVE_64_TO_64(_entry_address, table_entry);
+ if (!xsdt_entry_address) {
+ /* XSDT has NULL entry */
+ break;
+ }
+ table_entry += sizeof(u64);
+ }
+ acpi_os_unmap_memory(table, length);
+
+ if (i < table_count)
+ return AE_NULL_ENTRY;
+ else
+ return AE_OK;
+}
/***
*
@@ -341,6 +400,7 @@ acpi_tb_parse_root_table(acpi_physical_a
u32 table_count;
struct acpi_table_header *table;
acpi_physical_address address;
+ acpi_physical_address rsdt_address;
u32 length;
u8 *table_entry;
acpi_status status;
@@ -369,6 +429,8 @@ acpi_tb_parse_root_table(acpi_physical_a
*/
address = (acpi_physical_address) rsdp->xsdt_physical_address;
table_entry_size = sizeof(u64);
+ rsdt_address = (acpi_physical_address)
+ rsdp->rsdt_physical_address;
} else {
/* Root table is an RSDT (32-bit physical addresses) */
@@ -382,6 +444,15 @@ acpi_tb_parse_root_table(acpi_physical_a
*/
acpi_os_unmap_memory(rsdp, sizeof(struct acpi_table_rsdp));
+ if (table_entry_size == sizeof(u64)) {
+ if (acpi_tb_check_xsdt(address) == AE_NULL_ENTRY) {
+ /* XSDT has NULL entry, RSDT is used */
+ address = rsdt_address;
+ table_entry_size = sizeof(u32);
+ ACPI_WARNING((AE_INFO, "BIOS XSDT has NULL entry,"
+ "using RSDT"));
+ }
+ }
/* Map the RSDT/XSDT table header to get the full table length */
table = acpi_os_map_memory(address, sizeof(struct acpi_table_header));
--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[08/50] MTD: Makefile fix for mtdsuper
From: Satyam Sharma <[EMAIL PROTECTED]>
commit bec494775600b1cd7c144d31a09e1f46df9c6324 in mainline.
We want drivers/mtd/{mtdcore, mtdsuper, mtdpart}.c to be built and linked
into the same mtd.ko module. Fix the Makefile to ensure this, and remove
duplicate MODULE_ declarations in mtdpart.c, as mtdcore.c already has them.
Signed-off-by: Satyam Sharma <[EMAIL PROTECTED]>
Signed-off-by: David Woodhouse <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
---
drivers/mtd/Makefile |2 +-
drivers/mtd/mtdpart.c |4
2 files changed, 1 insertion(+), 5 deletions(-)
--- a/drivers/mtd/Makefile
+++ b/drivers/mtd/Makefile
@@ -3,9 +3,9 @@
#
# Core functionality.
+obj-$(CONFIG_MTD) += mtd.o
mtd-y := mtdcore.o mtdsuper.o
mtd-$(CONFIG_MTD_PARTITIONS) += mtdpart.o
-obj-$(CONFIG_MTD) += $(mtd-y)
obj-$(CONFIG_MTD_CONCAT) += mtdconcat.o
obj-$(CONFIG_MTD_REDBOOT_PARTS) += redboot.o
--- a/drivers/mtd/mtdpart.c
+++ b/drivers/mtd/mtdpart.c
@@ -560,7 +560,3 @@ int parse_mtd_partitions(struct mtd_info
EXPORT_SYMBOL_GPL(parse_mtd_partitions);
EXPORT_SYMBOL_GPL(register_mtd_parser);
EXPORT_SYMBOL_GPL(deregister_mtd_parser);
-
-MODULE_LICENSE("GPL");
-MODULE_AUTHOR("Nicolas Pitre <[EMAIL PROTECTED]>");
-MODULE_DESCRIPTION("Generic support for partitioning of MTD devices");
--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[09/50] USB: fix linked list insertion bugfix for usb core
From: Nathael Pajani <[EMAIL PROTECTED]>
commit e5dd01154c1e9ca2400f4682602d1a4fa54c25dd in mainline.
This patch fixes the order of list_add_tail() arguments in
usb_store_new_id() so the list can have more than one single element.
Signed-off-by: Nathael Pajani <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
---
drivers/usb/core/driver.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/usb/core/driver.c
+++ b/drivers/usb/core/driver.c
@@ -58,7 +58,7 @@ ssize_t usb_store_new_id(struct usb_dyni
dynid->id.match_flags = USB_DEVICE_ID_MATCH_DEVICE;
spin_lock(>lock);
- list_add_tail(>list, >node);
+ list_add_tail(>node, >list);
spin_unlock(>lock);
if (get_driver(driver)) {
--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[06/50] sigqueue_free: fix the race with collect_signal()
From: Oleg Nesterov <[EMAIL PROTECTED]>
commit 60187d2708caa870f0825d753df1612ea688eb9e in mainline.
Spotted by taoyue <[EMAIL PROTECTED]> and Jeremy Katz <[EMAIL PROTECTED]>.
collect_signal: sigqueue_free:
list_del_init(>list);
if (!list_empty(>list)) {
// not taken
}
q->flags &= ~SIGQUEUE_PREALLOC;
__sigqueue_free(first); __sigqueue_free(q);
Now, __sigqueue_free() is called twice on the same "struct sigqueue" with the
obviously bad implications.
In particular, this double free breaks the array_cache->avail logic, so the
same sigqueue could be "allocated" twice, and the bug can manifest itself via
the "impossible" BUG_ON(!SIGQUEUE_PREALLOC) in sigqueue_free/send_sigqueue.
Hopefully this can explain these mysterious bug-reports, see
http://marc.info/?t=11876692653
http://marc.info/?t=11846627305
Alexey Dobriyan reports this patch makes the difference for the testcase, but
nobody has an access to the application which opened the problems originally.
Also, this patch removes tasklist lock/unlock, ->siglock is enough.
Signed-off-by: Oleg Nesterov <[EMAIL PROTECTED]>
Cc: taoyue <[EMAIL PROTECTED]>
Cc: Jeremy Katz <[EMAIL PROTECTED]>
Cc: Sukadev Bhattiprolu <[EMAIL PROTECTED]>
Cc: Alexey Dobriyan <[EMAIL PROTECTED]>
Cc: Ingo Molnar <[EMAIL PROTECTED]>
Cc: Thomas Gleixner <[EMAIL PROTECTED]>
Cc: Roland McGrath <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
Signed-off-by: Linus Torvalds <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
---
kernel/signal.c | 19 +--
1 file changed, 9 insertions(+), 10 deletions(-)
--- a/kernel/signal.c
+++ b/kernel/signal.c
@@ -1259,20 +1259,19 @@ struct sigqueue *sigqueue_alloc(void)
void sigqueue_free(struct sigqueue *q)
{
unsigned long flags;
+ spinlock_t *lock = >sighand->siglock;
+
BUG_ON(!(q->flags & SIGQUEUE_PREALLOC));
/*
* If the signal is still pending remove it from the
-* pending queue.
+* pending queue. We must hold ->siglock while testing
+* q->list to serialize with collect_signal().
*/
- if (unlikely(!list_empty(>list))) {
- spinlock_t *lock = >sighand->siglock;
- read_lock(_lock);
- spin_lock_irqsave(lock, flags);
- if (!list_empty(>list))
- list_del_init(>list);
- spin_unlock_irqrestore(lock, flags);
- read_unlock(_lock);
- }
+ spin_lock_irqsave(lock, flags);
+ if (!list_empty(>list))
+ list_del_init(>list);
+ spin_unlock_irqrestore(lock, flags);
+
q->flags &= ~SIGQUEUE_PREALLOC;
__sigqueue_free(q);
}
--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[07/50] kconfig: oldconfig shall not set symbols if it does not need to
From: Roman Zippel <[EMAIL PROTECTED]>
commit f82f3f9422d4da1eeec6f6cf3e64c6c34c4fe19b in mainline.
Avoid setting the value if the symbol doesn't need to be changed or can't
be changed. Later choices may change the dependencies and thus the
possible input range.
make oldconfig from a 2.6.22 .config with CONFIG_HOTPLUG_CPU not set
was in some configurations setting CONFIG_HOTPLUG_CPU=y without asking,
even when there was no actual requirement for CONFIG_HOTPLUG_CPU.
This was triggered by SUSPEND_SMP that does a select HOTPLUG_CPU.
Signed-off-by: Roman Zippel <[EMAIL PROTECTED]>
Tested-by: Hugh Dickins <[EMAIL PROTECTED]>
Signed-off-by: Sam Ravnborg <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
---
scripts/kconfig/conf.c | 21 -
1 file changed, 12 insertions(+), 9 deletions(-)
--- a/scripts/kconfig/conf.c
+++ b/scripts/kconfig/conf.c
@@ -64,7 +64,7 @@ static void check_stdin(void)
}
}
-static void conf_askvalue(struct symbol *sym, const char *def)
+static int conf_askvalue(struct symbol *sym, const char *def)
{
enum symbol_type type = sym_get_type(sym);
tristate val;
@@ -79,7 +79,7 @@ static void conf_askvalue(struct symbol
printf("%s\n", def);
line[0] = '\n';
line[1] = 0;
- return;
+ return 0;
}
switch (input_mode) {
@@ -89,23 +89,23 @@ static void conf_askvalue(struct symbol
case set_random:
if (sym_has_value(sym)) {
printf("%s\n", def);
- return;
+ return 0;
}
break;
case ask_new:
case ask_silent:
if (sym_has_value(sym)) {
printf("%s\n", def);
- return;
+ return 0;
}
check_stdin();
case ask_all:
fflush(stdout);
fgets(line, 128, stdin);
- return;
+ return 1;
case set_default:
printf("%s\n", def);
- return;
+ return 1;
default:
break;
}
@@ -115,7 +115,7 @@ static void conf_askvalue(struct symbol
case S_HEX:
case S_STRING:
printf("%s\n", def);
- return;
+ return 1;
default:
;
}
@@ -166,6 +166,7 @@ static void conf_askvalue(struct symbol
break;
}
printf("%s", line);
+ return 1;
}
int conf_string(struct menu *menu)
@@ -179,7 +180,8 @@ int conf_string(struct menu *menu)
def = sym_get_string_value(sym);
if (sym_get_string_value(sym))
printf("[%s] ", def);
- conf_askvalue(sym, def);
+ if (!conf_askvalue(sym, def))
+ return 0;
switch (line[0]) {
case '\n':
break;
@@ -236,7 +238,8 @@ static int conf_sym(struct menu *menu)
if (sym->help)
printf("/?");
printf("] ");
- conf_askvalue(sym, sym_get_string_value(sym));
+ if (!conf_askvalue(sym, sym_get_string_value(sym)))
+ return 0;
strip(line);
switch (line[0]) {
--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[05/50] setpgid(child) fails if the child was forked by sub-thread
From: Oleg Nesterov <[EMAIL PROTECTED]>
commit b07e35f94a7b6a059f889b904529ee907dc0634d in mainline tree
Spotted by Marcin Kowalczyk <[EMAIL PROTECTED]>.
sys_setpgid(child) fails if the child was forked by sub-thread.
Fix the "is it our child" check. The previous commit
ee0acf90d320c29916ba8c5c1b2e908d81f5057d was not complete.
(this patch asks for the new same_thread_group() helper, but mainline doesn't
have it yet).
Signed-off-by: Oleg Nesterov <[EMAIL PROTECTED]>
Acked-by: Roland McGrath <[EMAIL PROTECTED]>
Tested-by: "Marcin 'Qrczak' Kowalczyk" <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
Signed-off-by: Linus Torvalds <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
---
kernel/sys.c |3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
--- a/kernel/sys.c
+++ b/kernel/sys.c
@@ -1428,7 +1428,6 @@ asmlinkage long sys_times(struct tms __u
* Auch. Had to add the 'did_exec' flag to conform completely to POSIX.
* LBT 04.03.94
*/
-
asmlinkage long sys_setpgid(pid_t pid, pid_t pgid)
{
struct task_struct *p;
@@ -1456,7 +1455,7 @@ asmlinkage long sys_setpgid(pid_t pid, p
if (!thread_group_leader(p))
goto out;
- if (p->real_parent == group_leader) {
+ if (p->real_parent->tgid == group_leader->tgid) {
err = -EPERM;
if (task_session(p) != task_session(group_leader))
goto out;
--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[03/50] DVB: get_dvb_firmware: update script for new location of tda10046 firmware
From: Andreas Arens <[EMAIL PROTECTED]>
cherry picked from commit c545d6adbcacd296f7457bd992556feb055379de
Update get_dvb_firmware script for the new location of the
tda10046 firmware.
The old location doesn't work anymore.
Signed-off-by: Andreas Arens <[EMAIL PROTECTED]>
Signed-off-by: Michael Krufky <[EMAIL PROTECTED]>
Signed-off-by: Mauro Carvalho Chehab <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
---
Documentation/dvb/get_dvb_firmware | 24
1 file changed, 12 insertions(+), 12 deletions(-)
--- a/Documentation/dvb/get_dvb_firmware
+++ b/Documentation/dvb/get_dvb_firmware
@@ -110,21 +110,21 @@ sub tda10045 {
}
sub tda10046 {
-my $sourcefile = "tt_budget_217g.zip";
-my $url = "http://www.technotrend.de/new/217g/$sourcefile;;
-my $hash = "6a7e1e2f2644b162ff0502367553c72d";
-my $outfile = "dvb-fe-tda10046.fw";
-my $tmpdir = tempdir(DIR => "/tmp", CLEANUP => 1);
+ my $sourcefile = "TT_PCI_2.19h_28_11_2006.zip";
+ my $url =
"http://technotrend-online.com/download/software/219/$sourcefile;;
+ my $hash = "6a7e1e2f2644b162ff0502367553c72d";
+ my $outfile = "dvb-fe-tda10046.fw";
+ my $tmpdir = tempdir(DIR => "/tmp", CLEANUP => 1);
-checkstandard();
+ checkstandard();
-wgetfile($sourcefile, $url);
-unzip($sourcefile, $tmpdir);
-extract("$tmpdir/software/OEM/PCI/App/ttlcdacc.dll", 0x3f731, 24478,
"$tmpdir/fwtmp");
-verify("$tmpdir/fwtmp", $hash);
-copy("$tmpdir/fwtmp", $outfile);
+ wgetfile($sourcefile, $url);
+ unzip($sourcefile, $tmpdir);
+
extract("$tmpdir/TT_PCI_2.19h_28_11_2006/software/OEM/PCI/App/ttlcdacc.dll",
0x65389, 24478, "$tmpdir/fwtmp");
+ verify("$tmpdir/fwtmp", $hash);
+ copy("$tmpdir/fwtmp", $outfile);
-$outfile;
+ $outfile;
}
sub tda10046lifeview {
--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[04/50] DVB: b2c2-flexcop: fix Airstar HD5000 tuning regression
From: Trent Piepho <[EMAIL PROTECTED]> cherry picked from commit 6175e487e314385e37f06448847e4c46c20edb44 b2c2-flexcop: fix Airstar HD5000 tuning regression Git changeset 6bdcc6e6dbab8daffd05e5026486f34ba41a6c72 dropped the stand-alone lgh06xf module, whose functionality was absorbed into the dvb-pll module. However, there was a minor difference between the code in lgh06xf and dvb-pll, which caused a regression in b2c2-flexcop devices using the LG-H06xF NIM. dvb-pll will probe for the presence of an i2c pll chip by performing a single byte read, the lgh06xf driver did not do this. Unfortunately, the code in flexcop-i2c.c does not currently support 1 byte or 0 byte reads as a probe. Such probes with the current code will always fail. In order to work around this problem, and restore proper functionality of the Airstar HD5000 device, this hack was created to make the probe appear to succeed. The single byte read in dvb_pll_attach is the only place where such a probe would ever occur, so this change is safe, and will not affect any other devices. Of course, if one knew how to actually perform the read operation, it would be better to go that route. In the meantime, however, we must apply this workaround, in order to prevent the regression that causes tuning to fail on the Airstar HD5000 ATSC device. Thanks to Jarod Wilson, who had originally reported this regression, and to Geoffrey Hausheer, whose original workaround patch led us to find the actual cause of the problem. Signed-off-by: Trent Piepho <[EMAIL PROTECTED]> Cc: Geoffrey Hausheer <[EMAIL PROTECTED]> Acked-by: Jarod Wilson <[EMAIL PROTECTED]> Signed-off-by: Michael Krufky <[EMAIL PROTECTED]> Signed-off-by: Mauro Carvalho Chehab <[EMAIL PROTECTED]> Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]> --- drivers/media/dvb/b2c2/flexcop-i2c.c |7 +++ 1 file changed, 7 insertions(+) --- a/drivers/media/dvb/b2c2/flexcop-i2c.c +++ b/drivers/media/dvb/b2c2/flexcop-i2c.c @@ -135,6 +135,13 @@ static int flexcop_master_xfer(struct i2 struct flexcop_device *fc = i2c_get_adapdata(i2c_adap); int i, ret = 0; + /* Some drivers use 1 byte or 0 byte reads as probes, which this +* driver doesn't support. These probes will always fail, so this +* hack makes them always succeed. If one knew how, it would of +* course be better to actually do the read. */ + if (num == 1 && msgs[0].flags == I2C_M_RD && msgs[0].len <= 1) + return 1; + if (mutex_lock_interruptible(>i2c_mutex)) return -ERESTARTSYS; -- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[00/50] 2.6.22-stable review
This is the start of the stable review cycle for the 2.6.22.8 release. There are 50 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let us know. If anyone is a maintainer of the proper subsystem, and wants to add a Signed-off-by: line to the patch, please respond with it. These patches are sent out with a number of different people on the Cc: line. If you wish to be a reviewer, please email [EMAIL PROTECTED] to add your name to the list. If you want to be off the reviewer list, also email us. Responses should be made by Wed September 26, 2007, 16:00:00 UTC. Anything received after that time might be too late. thanks, greg k-h - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[02/50] DVB: get_dvb_firmware: update script for new location of sp8870 firmware
From: Michael Krufky <[EMAIL PROTECTED]>
cherry picked from commit 302170a4b47e869372974abd885dd11d5536b64a
get_dvb_firmware: update script for new location of sp8870 firmware
This url is no longer valid:
http://www.technotrend.de/new/217g/tt_Premium_217g.zip
Replace with:
http://www.softwarepatch.pl/ccd06a4813cb827dbb0005071c71/tt_Premium_217g.zip
Thanks-to: Tobias Stoeber <[EMAIL PROTECTED]>
Signed-off-by: Michael Krufky <[EMAIL PROTECTED]>
Signed-off-by: Mauro Carvalho Chehab <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
---
Documentation/dvb/get_dvb_firmware |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/Documentation/dvb/get_dvb_firmware
+++ b/Documentation/dvb/get_dvb_firmware
@@ -56,7 +56,7 @@ syntax();
sub sp8870 {
my $sourcefile = "tt_Premium_217g.zip";
-my $url = "http://www.technotrend.de/new/217g/$sourcefile;;
+my $url =
"http://www.softwarepatch.pl/ccd06a4813cb827dbb0005071c71/$sourcefile;;
my $hash = "53970ec17a538945a6d8cb608a7b3899";
my $outfile = "dvb-fe-sp8870.fw";
my $tmpdir = tempdir(DIR => "/tmp", CLEANUP => 1);
--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[01/50] V4L: ivtv: fix VIDIOC_S_FBUF: new OSD values were never set
From: Hans Verkuil <[EMAIL PROTECTED]> cherry picked from commit c3624f99a8c06cfe75e0b06f23a7f7cea9d2d5ff ivtv: fix VIDIOC_S_FBUF support: new OSD values were never actually set. The values set with VIDIOC_S_FBUF were not actually used until the next VIDIOC_S_FMT. Fixed. Signed-off-by: Hans Verkuil <[EMAIL PROTECTED]> Signed-off-by: Mauro Carvalho Chehab <[EMAIL PROTECTED]> Signed-off-by: Michael Krufky <[EMAIL PROTECTED]> Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]> --- drivers/media/video/ivtv/ivtv-ioctl.c |1 + 1 file changed, 1 insertion(+) --- a/drivers/media/video/ivtv/ivtv-ioctl.c +++ b/drivers/media/video/ivtv/ivtv-ioctl.c @@ -1183,6 +1183,7 @@ int ivtv_v4l2_ioctls(struct ivtv *itv, s itv->osd_global_alpha_state = (fb->flags & V4L2_FBUF_FLAG_GLOBAL_ALPHA) != 0; itv->osd_local_alpha_state = (fb->flags & V4L2_FBUF_FLAG_LOCAL_ALPHA) != 0; itv->osd_color_key_state = (fb->flags & V4L2_FBUF_FLAG_CHROMAKEY) != 0; + ivtv_set_osd_alpha(itv); break; } -- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/5] Fair group scheduler - various fixes
Hello Ingo and Andrew, Here are various patches to fair group scheduler code present in sched-devel and in 2.6.23-rc7-mm1. These patches should apply against both sched-devel git tree and 2.6.23-rc7-mm1 (as they are both in sync now). Pls consider for inclusion after review. [there is still room for improving group fairness obtained on smp systems. By sending out these patches, i am hoping more folks can test and improve that aspect] Ingo, You may want to avoid picking Patch 5/5 as it makes sense only in -mm tree atm. -- Regards, vatsa - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[patch] usb-skeleton leaking locks on open.
This weekend I was hacking around with a trivial USB driver for talking to the boot load firmware of a USB Bit Whacker. It's running the MicroChip Pic18 boot loader firmware and I'm putting together a flash program for writing new FW to the thing. Anyway in my use of the usb-skeleton.c as my starting point I discovered my test program was getting hung up after attempting to write a buffer. The application and driver where hung in a way that required me to reboot to get it to clean up so I could try again. It turned out the code path through skel_open can grap the driver's io_mutex lock and forget to release it. The following patch fixes the problem for me. --mgross Signed-off-by: Mark Gross <[EMAIL PROTECTED]> diff -urN -X linux-2.6.23-rc7/Documentation/dontdiff linux-2.6.23-rc7/drivers/usb/usb-skeleton.c linux-2.6.23-rc7-bugfix/drivers/usb/usb-skeleton.c --- linux-2.6.23-rc7/drivers/usb/usb-skeleton.c 2007-09-24 08:57:54.0 -0700 +++ linux-2.6.23-rc7-bugfix/drivers/usb/usb-skeleton.c 2007-09-24 09:01:43.0 -0700 @@ -125,6 +125,7 @@ /* save our object in the file's private structure */ file->private_data = dev; + mutex_unlock(>io_mutex); exit: return retval; - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] 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] Trace code and documentation (resend)
On Mon, 24 Sep 2007 16:41:14 +0100 Christoph Hellwig wrote: > On Mon, Sep 24, 2007 at 08:38:34AM -0700, David Wilder wrote: > > >NACK, don't put code into Documentation/. Put it into kernel as it's > > >actually useful kernel code. > > > > Are you suggesting moving the example code into kernel? Or complaining > > about example code in /Documentation? > > Both. example code should be integrated with the build system so it > gets built. How about if we build the sample files in the Documentation/ tree? with added Kconfig, Makefiles etc. > > And add clone,exec and exit while you're at it. > > > > Hu? A syscall tracer sounds like a nice idea but that is not what I am > > trying to accomplish. I will let Systemtap handle that. > > Systemtap doesn't help anyone as it's not in the tree. I haven't even > asked you to provide a full system call tracing modulem but provide at > least one that's useful for a certain use-case (looking at processes) > instead of almost useless code. --- ~Randy Phaedrus says that Quality is about caring. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.23-rc7-mm1
Pavel Emelyanov wrote: > Balbir Singh wrote: >> Pavel Emelyanov wrote: >>> Please, try with this patch too: >>> >>> diff --git a/fs/locks.c b/fs/locks.c >>> index c0fe71a..f599508 100644 >>> --- a/fs/locks.c >>> +++ b/fs/locks.c >>> @@ -1423,7 +1423,7 @@ int generic_setlease(struct file *filp, >>> locks_copy_lock(new_fl, lease); >>> locks_insert_lock(before, new_fl); >>> >>> - *flp = fl; >>> + *flp = new_fl; >>> return 0; >>> >>> out: >>> >> Hi, Pavel, >> >> You did not signoff on the patch. > > I did not, but this is just a patch to test. I know, that it > most likely fixes the problem, but since Kamalesh didn't tell > us how he had triggered it, I'd like him to Ack it :) > > Thanks, > Pavel > > Ok, just wanted to let you know in case you missed it out. In case Andrew picked it up. That's all! -- Warm Regards, Balbir Singh Linux Technology Center IBM, ISTL - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Urgent bugzilla mainteinance needed
Bugzilla really shouldn't be accepting any mail with empty reverse-path (MAIL FROM:<>) Updated to handle this case. Ah, then should be easy fix then. I don't have access to the system though, will have to helplessly wait until one of the guys picks up... :( Sorry, can't fix this - I don't have direct access to the system, and I don't think the others will be back until Monday ;-( M. It should be working now. Thanks to David Ames for handling the mailer part. I cleaned the spam(1353 msgs) out of the bug. Awesome - thanks to both of you. M. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.23-rc7-mm1 - 'touch' command causes Oops.
On Mon, 24 Sep 2007 08:45:32 PDT, Dave Hansen said: > Any idea which fs and distro this was? I'd like to add it to my tests. initscripts-8.56-1, from Fedora Rawhide, /etc/rc.sysinit, line 325: touch /dev/.in_sysinit >/dev/null 2>&1 Specific enough? :) pgp3OvCOFx0xa.pgp Description: PGP signature
MAX_LOCKDEP_SUBCLASSES too low in 2.6.23-rc7-mm1
Hi Ingo, I got the following printk when booting 2.6.23-rc7-mm1 : BUG: MAX_LOCKDEP_SUBCLASSES too low! turning off the locking correctness validator. Is it known/correct situation ? Regards, Mathieu Here is my config. # # Automatically generated make config: don't edit # Linux kernel version: 2.6.23-rc7-mm1 # Mon Sep 24 11:52:57 2007 # CONFIG_X86_32=y CONFIG_GENERIC_TIME=y CONFIG_GENERIC_CMOS_UPDATE=y CONFIG_CLOCKSOURCE_WATCHDOG=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_SEMAPHORE_SLEEPERS=y CONFIG_X86=y CONFIG_MMU=y CONFIG_ZONE_DMA=y CONFIG_QUICKLIST=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_IOMAP=y CONFIG_GENERIC_BUG=y CONFIG_GENERIC_HWEIGHT=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_DMI=y CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" # # General setup # CONFIG_EXPERIMENTAL=y CONFIG_LOCK_KERNEL=y CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_LOCALVERSION="-testssmp" # CONFIG_LOCALVERSION_AUTO is not set CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_SYSVIPC_SYSCTL=y CONFIG_POSIX_MQUEUE=y # CONFIG_BSD_PROCESS_ACCT is not set # CONFIG_TASKSTATS is not set # CONFIG_USER_NS is not set CONFIG_AUDIT=y CONFIG_AUDITSYSCALL=y CONFIG_AUDIT_TREE=y # CONFIG_IKCONFIG is not set CONFIG_LOG_BUF_SHIFT=17 # CONFIG_CGROUPS is not set CONFIG_SYSFS_DEPRECATED=y CONFIG_RELAY=y # CONFIG_BLK_DEV_INITRD is not set # CONFIG_CC_OPTIMIZE_FOR_SIZE is not set CONFIG_SYSCTL=y CONFIG_EMBEDDED=y CONFIG_UID16=y CONFIG_SYSCTL_SYSCALL=y CONFIG_KALLSYMS=y CONFIG_KALLSYMS_ALL=y # CONFIG_KALLSYMS_EXTRA_PASS is not set CONFIG_HOTPLUG=y CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_ELF_CORE=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_ANON_INODES=y CONFIG_EPOLL=y CONFIG_SIGNALFD=y CONFIG_EVENTFD=y CONFIG_SHMEM=y CONFIG_VM_EVENT_COUNTERS=y CONFIG_SLUB_DEBUG=y # CONFIG_SLAB is not set CONFIG_SLUB=y # CONFIG_SLOB is not set CONFIG_PROC_PAGE_MONITOR=y CONFIG_PROC_KPAGEMAP=y CONFIG_RT_MUTEXES=y # CONFIG_TINY_SHMEM is not set CONFIG_BASE_SMALL=0 CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y # CONFIG_MODULE_FORCE_UNLOAD is not set # CONFIG_MODVERSIONS is not set # CONFIG_MODULE_SRCVERSION_ALL is not set CONFIG_KMOD=y CONFIG_STOP_MACHINE=y CONFIG_BLOCK=y CONFIG_LBD=y CONFIG_BLK_DEV_IO_TRACE=y CONFIG_LSF=y # CONFIG_BLK_DEV_BSG is not set # # IO Schedulers # CONFIG_IOSCHED_NOOP=y CONFIG_IOSCHED_AS=y CONFIG_IOSCHED_DEADLINE=y CONFIG_IOSCHED_CFQ=y CONFIG_DEFAULT_AS=y # CONFIG_DEFAULT_DEADLINE is not set # CONFIG_DEFAULT_CFQ is not set # CONFIG_DEFAULT_NOOP is not set CONFIG_DEFAULT_IOSCHED="anticipatory" # # Processor type and features # # CONFIG_TICK_ONESHOT is not set # CONFIG_NO_HZ is not set # CONFIG_HIGH_RES_TIMERS is not set CONFIG_GENERIC_CLOCKEVENTS_BUILD=y CONFIG_SMP=y CONFIG_X86_PC=y # CONFIG_X86_ELAN is not set # CONFIG_X86_VOYAGER is not set # CONFIG_X86_NUMAQ is not set # CONFIG_X86_SUMMIT is not set # CONFIG_X86_BIGSMP is not set # CONFIG_X86_VISWS is not set # CONFIG_X86_GENERICARCH is not set # CONFIG_X86_ES7000 is not set CONFIG_SCHED_NO_NO_OMIT_FRAME_POINTER=y CONFIG_PARAVIRT=y CONFIG_XEN=y CONFIG_VMI=y # CONFIG_M386 is not set # CONFIG_M486 is not set # CONFIG_M586 is not set # CONFIG_M586TSC is not set # CONFIG_M586MMX is not set # CONFIG_M686 is not set # CONFIG_MPENTIUMII is not set CONFIG_MPENTIUMIII=y # CONFIG_MPENTIUMM is not set # CONFIG_MPENTIUM4 is not set # CONFIG_MCORE2 is not set # CONFIG_MK6 is not set # CONFIG_MK7 is not set # CONFIG_MK8 is not set # CONFIG_MCRUSOE is not set # CONFIG_MEFFICEON is not set # CONFIG_MWINCHIPC6 is not set # CONFIG_MWINCHIP2 is not set # CONFIG_MWINCHIP3D is not set # CONFIG_MGEODEGX1 is not set # CONFIG_MGEODE_LX is not set # CONFIG_MCYRIXIII is not set # CONFIG_MVIAC3_2 is not set # CONFIG_MVIAC7 is not set # CONFIG_X86_GENERIC is not set CONFIG_X86_CMPXCHG=y CONFIG_X86_L1_CACHE_SHIFT=5 CONFIG_X86_XADD=y CONFIG_RWSEM_XCHGADD_ALGORITHM=y # CONFIG_ARCH_HAS_ILOG2_U32 is not set # CONFIG_ARCH_HAS_ILOG2_U64 is not set CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_X86_WP_WORKS_OK=y CONFIG_X86_INVLPG=y CONFIG_X86_BSWAP=y CONFIG_X86_POPAD_OK=y CONFIG_X86_GOOD_APIC=y CONFIG_X86_INTEL_USERCOPY=y CONFIG_X86_USE_PPRO_CHECKSUM=y CONFIG_X86_TSC=y CONFIG_X86_CMOV=y CONFIG_X86_MINIMUM_CPU_FAMILY=4 # CONFIG_HPET_TIMER is not set CONFIG_NR_CPUS=8 CONFIG_SCHED_SMT=y CONFIG_SCHED_MC=y # CONFIG_PREEMPT_NONE is not set # CONFIG_PREEMPT_VOLUNTARY is not set CONFIG_PREEMPT=y CONFIG_PREEMPT_BKL=y CONFIG_X86_LOCAL_APIC=y CONFIG_X86_IO_APIC=y CONFIG_X86_MCE=y CONFIG_X86_MCE_NONFATAL=y # CONFIG_X86_MCE_P4THERMAL is not set CONFIG_VM86=y # CONFIG_TOSHIBA is not set # CONFIG_I8K is not set # CONFIG_X86_REBOOTFIXUPS is not set # CONFIG_MICROCODE is not set # CONFIG_X86_MSR is not set # CONFIG_X86_CPUID is not set # # Firmware Drivers # # CONFIG_EDD is not set # CONFIG_DELL_RBU is not set CONFIG_DCDBAS=m CONFIG_DMIID=y # CONFIG_NOHIGHMEM is not set CONFIG_HIGHMEM4G=y # CONFIG_HIGHMEM64G is not set CONFIG_VMSPLIT_3G=y # CONFIG_VMSPLIT_3G_OPT is not set #
Re: [PATCH4/4] [POWERPC] Fix cpm_uart driver
Jochen Friedrich wrote: In cpm_uart_core, functions cpm_uart_init_bd and cpm_uart_init_scc an offset into DP RAM is calculated by substracting a physical memory constant from an virtual address. This patch fixes the problem by converting the virtual address into a physical first. Huh? DPRAM_BASE is a virtual address. With this patch, you'd be subtracting a virtual address from a physical address. -Scott - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Urgent bugzilla mainteinance needed
Martin J. Bligh wrote:
> Natalie Protasevich wrote:
>> On 9/23/07, David Woodhouse <[EMAIL PROTECTED]> wrote:
>>> On Sun, 2007-09-23 at 11:08 -0700, Natalie Protasevich wrote:
On 9/23/07, Diego Calleja <[EMAIL PROTECTED]> wrote:
> Take a look at http://bugzilla.kernel.org/show_bug.cgi?id=3710
>
> bugzilla tries to send a mail to the reporter, it fails ("unknown
> user account"),
> but the error failure is appended as a bugzilla comment. Then
> bugzilla tries to
> send that comment to everyone involved in the bug, including the
> reporter,
> so it fails again.Houston, we've a endless loop.
>
> There're 540 comments in that bug report already, and the
> bugme-daemon
> mail list is being spammed
I just sent emails to those who maintain bugzilla software and systems
that run it, hope someone will be online soon to help alleviate
this...
>>> Bugzilla really shouldn't be accepting any mail with empty reverse-path
>>> (MAIL FROM:<>)
Updated to handle this case.
>>
>> Ah, then should be easy fix then. I don't have access to the system
>> though, will have to helplessly wait until one of the guys picks up...
>> :(
>
> Sorry, can't fix this - I don't have direct access to the system,
> and I don't think the others will be back until Monday ;-(
>
> M.
It should be working now. Thanks to David Ames for handling the mailer
part. I cleaned the spam(1353 msgs) out of the bug.
Jon
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/3] CRED: Split the task security data and move part of it into struct cred
Serge E. Hallyn <[EMAIL PROTECTED]> wrote: > Ah, ok, so the daemon would use this to act under the user's > credentials. I was thinking the user would be using this to act > under the daemon's or kernel's sid. Think kernel service rather than daemon. NFSd provides its own daemons to override the security of, whereas cachefiles runs in the process context of whoever called NFS. > Between that and David's response, that this is only for the duration of > one syscall (IIUC), That's more or less correct. You have to add the pagefault handler to that list. > My worry arose from the fact that I don't see > security_cred_kernel_act_as() being called anywhere in this patchset... Look in: [PATCH 04/22] CRED: Request a credential record for a kernel service Which was part of a patchset I sent on the 21st Sept. get_kernel_cred() is in turn used by: [PATCH 13/22] CacheFiles: A cache that backs onto a mounted filesystem David - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 1/3] new timerfd API - new timerfd API
On Mon, 2007-09-24 at 08:42 -0700, Davide Libenzi wrote: > > > + ticks += (u64) > > > hrtimer_forward(>tmr, > > > hrtimer_cb_get_time(>tmr), > > > > You need to use ctx->tmr.base->get_time() here, otherwise you might read > > a stale time value (in case that CONFIG_HIGH_RES_TIMERS is off). > > Is the particular position of hrtimer_cb_get_time() in the code that would > break here? Because function was added by your patch ;) > Did something change later? For non high res systems we speed up the access to now by storing the current time when we start to process the hrtimer softirq callbacks. hrtimer_cb_get_time(timer) reads timer->base->now For high resolution systems hrtimer_cb_get_time() resolves to timer->base->get_time(). In the timerfd case we are not in softirq context and we read at any given later time. Also on SMP the base->now variable might be changed by the softirq running on the other CPU. tglx - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Mask Issue?
On Mon, 2007-09-24 at 16:39 +0100, Mel Gorman wrote: > I noticed this in a -mm recently and never got around to kicking it > properly because I suspected it was a compiler issue. What version > of gcc and binutils are you using? > > David Woodhouse added to cc in case this is a known problem. The only reason for this is because once upon a time, the early FPGA versions of the CAFÉ chip had the same PCI ident for all three functions. The cluebat was applied; the chip was fixed long before tape-out. We can just drop the whole class/mask thing, I suspect -- I just want to boot it on and OLPC machine before I commit that. -- dwmw2 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[patch] Show ioremap and vmap in /proc/meminfo
Hi,
For long time I've been thought the following equation is correct:
The "MemUsage" is about "Active + Inactive + Slab + PageTables +
VmallocUsed" in /proc/meminfo.
(I'm not only the person. See
https://bugzilla.redhat.com/show_bug.cgi?id=243657.)
However, some VmallocUsed doesn't really consume MemUsage: ioremap
pages and vmap pages consume just virtual address spaces.
It is a bit helpful for people who want to understand kernel memory
usage to show the number of ioremap and vmap pages in /proc/meminfo.
The following patch adds entries for ioremap and vmap to /proc/meminfo.
Signed-off-by: Masatake YAMATO <[EMAIL PROTECTED]>
diff --git a/fs/proc/internal.h b/fs/proc/internal.h
index b215c35..b888c59 100644
--- a/fs/proc/internal.h
+++ b/fs/proc/internal.h
@@ -19,6 +19,8 @@ static inline void proc_sys_init(void) { }
struct vmalloc_info {
unsigned long used;
+ unsigned long used_as_ioremap;
+ unsigned long used_as_vmap;
unsigned long largest_chunk;
};
@@ -31,6 +33,8 @@ extern void get_vmalloc_info(struct vmalloc_info *vmi);
#define get_vmalloc_info(vmi) \
do { \
(vmi)->used = 0;\
+ (vmi)->used_as_ioremap = 0; \
+ (vmi)->used_as_vmap = 0;\
(vmi)->largest_chunk = 0; \
} while(0)
diff --git a/fs/proc/mmu.c b/fs/proc/mmu.c
index 25d2d9c..5297df2 100644
--- a/fs/proc/mmu.c
+++ b/fs/proc/mmu.c
@@ -38,7 +38,9 @@ void get_vmalloc_info(struct vmalloc_info *vmi)
unsigned long prev_end;
vmi->used = 0;
-
+ vmi->used_as_ioremap = 0;
+ vmi->used_as_vmap = 0;
+
if (!vmlist) {
vmi->largest_chunk = VMALLOC_TOTAL;
}
@@ -51,6 +53,8 @@ void get_vmalloc_info(struct vmalloc_info *vmi)
for (vma = vmlist; vma; vma = vma->next) {
unsigned long addr = (unsigned long) vma->addr;
+ unsigned long flags;
+ unsigned long size;
/*
* Some archs keep another range for modules in vmlist
@@ -59,8 +63,15 @@ void get_vmalloc_info(struct vmalloc_info *vmi)
continue;
if (addr >= VMALLOC_END)
break;
-
- vmi->used += vma->size;
+
+ size = vma->size;
+ flags = vma->flags;
+
+ vmi->used += size;
+ if (flags & VM_IOREMAP)
+ vmi->used_as_ioremap += size;
+ if (flags & VM_MAP)
+ vmi->used_as_vmap += size;
free_area_size = addr - prev_end;
if (vmi->largest_chunk < free_area_size)
diff --git a/fs/proc/proc_misc.c b/fs/proc/proc_misc.c
index bee251c..d784c85 100644
--- a/fs/proc/proc_misc.c
+++ b/fs/proc/proc_misc.c
@@ -176,6 +176,8 @@ static int meminfo_read_proc(char *page, char **start,
off_t off,
"Committed_AS: %8lu kB\n"
"VmallocTotal: %8lu kB\n"
"VmallocUsed: %8lu kB\n"
+ "IORemapUsed: %8lu kB\n"
+ "VmapUsed: %8lu kB\n"
"VmallocChunk: %8lu kB\n",
K(i.totalram),
K(i.freeram),
@@ -207,6 +209,8 @@ static int meminfo_read_proc(char *page, char **start,
off_t off,
K(committed),
(unsigned long)VMALLOC_TOTAL >> 10,
vmi.used >> 10,
+ vmi.used_as_ioremap >> 10,
+ vmi.used_as_vmap >> 10,
vmi.largest_chunk >> 10
);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.23-rc7-mm1 - 'touch' command causes Oops.
On Mon, 2007-09-24 at 08:58 -0400, [EMAIL PROTECTED] wrote: > > do_times passes an unitialized vfsmount into mnt_want_write. Here's > > the quick fix (untested), but the right fix is to restructure the complete > > mess do_utimes is (never let a libc developer write your kernel code.. :)): > > Close - it still blew up, as one reference to nd.mnt remained. Fixed patch > is appended - system boots all the way with this applied. Any idea which fs and distro this was? I'd like to add it to my tests. -- Dave - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 1/3] new timerfd API - new timerfd API
On Mon, 24 Sep 2007, Thomas Gleixner wrote:
> > struct timerfd_ctx {
> > struct hrtimer tmr;
> > + int clockid;
> > ktime_t tintv;
> > wait_queue_head_t wqh;
> > int expired;
> > + u64 ticks;
> > };
>
> Can you please restructure the struct in a way which does not result in
> padding by the compiler ?
>
> struct timerfd_ctx {
> struct hrtimer tmr;
> ktime_t tintv;
> wait_queue_head_t wqh;
> u64 ticks;
> int expired;
> int clockid;
> };
Sure.
> > + ticks += (u64)
> > hrtimer_forward(>tmr,
> > hrtimer_cb_get_time(>tmr),
>
> You need to use ctx->tmr.base->get_time() here, otherwise you might read
> a stale time value (in case that CONFIG_HIGH_RES_TIMERS is off).
Is the particular position of hrtimer_cb_get_time() in the code that would
break here? Because function was added by your patch ;)
Did something change later?
> > +err_kfree_ctx:
> > + kfree(ctx);
> > + return error;
>
> You really can avoid the goto here.
Ack.
- Davide
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [00/41] Large Blocksize Support V7 (adds memmap support)
On Sun, Sep 23, 2007 at 08:56:39AM +0200, Goswin von Brederlow wrote: > As a user I know it because I didn't put a kernel source into /tmp. A > programm can't reasonably know that. Various apps requires you (admin/user) to tune the size of their caches. Seems like you never tried to setup a database, oh well. > Xen has its own memory pool and can quite agressively reclaim memory > from dom0 when needed. I just ment to say that the number in The whole point is if there's not enough ram of course... this is why you should check. > /proc/meminfo can change in a second so it is not much use knowing > what it said last minute. The numbers will change depending on what's running on your system. It's up to you to know plus I normally keep vmstat monitored in the background to see how the cache/free levels change over time. Those numbers are worthless if they could be fragmented... > I would kill any programm that does that to find out how much free ram > the system has. The admin should do that if he's unsure, not a program of course! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] 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] Trace code and documentation (resend)
On Mon, Sep 24, 2007 at 08:38:34AM -0700, David Wilder wrote: > >NACK, don't put code into Documentation/. Put it into kernel as it's > >actually useful kernel code. > > Are you suggesting moving the example code into kernel? Or complaining > about example code in /Documentation? Both. example code should be integrated with the build system so it gets built. > And add clone,exec and exit while you're at it. > > Hu? A syscall tracer sounds like a nice idea but that is not what I am > trying to accomplish. I will let Systemtap handle that. Systemtap doesn't help anyone as it's not in the tree. I haven't even asked you to provide a full system call tracing modulem but provide at least one that's useful for a certain use-case (looking at processes) instead of almost useless code. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Mask Issue?
On (19/09/07 17:57), Chris Holvenstot didst pronounce: > Still being a little new at this I am not sure if this is an issue at > all or not but I noted that while building the 2.6.23-rc6-git8 kernel > this afternoon I received the following error message: > > Building modules, stage 2. > MODPOST 1670 modules > WARNING: Can't handle masks in drivers/mtd/nand/cafe_nand:0 > > I have been building each of the kernels in the 2.6.23-rc series and had > not noted this message before. I apologize if this is a non-issue. > I noticed this in a -mm recently and never got around to kicking it properly because I suspected it was a compiler issue. What version of gcc and binutils are you using? David Woodhouse added to cc in case this is a known problem. -- Mel Gorman Part-time Phd Student Linux Technology Center University of Limerick IBM Dublin Software Lab - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 2/3] new timerfd API - wire the new timerfd API to the x86 family
On Mon, 24 Sep 2007, Michael Kerrisk wrote: > Davide, > > Is it perhaps not better to group the three syscalls contiguously with > respect to syscall numbers? The old timerfd slot can be re-used for some > other syscall later. There's no problem if they're not contiguous. Holes, unless filled immediately, need to be remembered to be filled. - Davide - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] 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] Trace code and documentation (resend)
Christoph Hellwig wrote: On Fri, Sep 21, 2007 at 09:23:28PM -0700, David J. Wilder wrote: My last posting was mangled by my mailer. I hope this one is better. Also corrected Randy's concerns. Please see previous posting for more information: http://lkml.org/lkml/2007/9/19/4 (PATCH 0/2) Note: this patch requires "[Patch 2/2] Relay reset consumed" is applied. - Trace - Provides tracing primitives Signed-off-by: Tom Zanussi <[EMAIL PROTECTED]> Signed-off-by: Martin Hunt <[EMAIL PROTECTED]> Signed-off-by: David Wilder <[EMAIL PROTECTED]> --- Documentation/trace/src/Makefile |7 + Documentation/trace/src/README | 18 + Documentation/trace/src/fork_trace.c | 119 +++ Documentation/trace/trace.txt| 164 ++ NACK, don't put code into Documentation/. Put it into kernel as it's actually useful kernel code. Are you suggesting moving the example code into kernel? Or complaining about example code in /Documentation? And add clone,exec and exit while you're at it. Hu? A syscall tracer sounds like a nice idea but that is not what I am trying to accomplish. I will let Systemtap handle that. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.23-rc7-mm1
Balbir Singh wrote: > Pavel Emelyanov wrote: >> Please, try with this patch too: >> >> diff --git a/fs/locks.c b/fs/locks.c >> index c0fe71a..f599508 100644 >> --- a/fs/locks.c >> +++ b/fs/locks.c >> @@ -1423,7 +1423,7 @@ int generic_setlease(struct file *filp, >> locks_copy_lock(new_fl, lease); >> locks_insert_lock(before, new_fl); >> >> -*flp = fl; >> +*flp = new_fl; >> return 0; >> >> out: >> > > Hi, Pavel, > > You did not signoff on the patch. I did not, but this is just a patch to test. I know, that it most likely fixes the problem, but since Kamalesh didn't tell us how he had triggered it, I'd like him to Ack it :) Thanks, Pavel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Kernel bug
On (19/09/07 17:43), Branislav Bozgai didst pronounce: > uname -a > Linux tweety 2.6.21.3-default #2 Tue Aug 7 17:11:50 EDT 2007 i686 athlon > i386 GNU/Linux > Hello, my system is crashing with following info in /var/log/messages, > thought I send it to you. Does this happen after suspend/resume by any chance? I ask because it looks vagely similar to http://groups.google.com/group/linux.kernel/browse_thread/thread/7aa897981d7d440f . The first error is interesting, the other ones look like slab lists have been hosed. Just to rule it out, have you run memtest+ on your machine to make sure you RAM is healthy? > Sep 19 17:05:33 tweety kernel: BUG: unable to handle kernel paging request at > virtual address 07e07fbc > Sep 19 17:05:33 tweety kernel: printing eip: > Sep 19 17:05:33 tweety kernel: c0154707 > Sep 19 17:05:33 tweety kernel: *pde = > Sep 19 17:05:33 tweety kernel: Oops: [#1] > Sep 19 17:05:33 tweety kernel: Modules linked in: xt_tcpudp iptable_filter > ip_tables x_tables joydev st ide_cd capability commoncap nfsd exportfs lockd > nfs_acl sunrpc it87 hwmon_vid i2c_isa i2c_core cpufreq_conservative > cpufreq_ondemand cpufreq_powersave powernow_k8 freq_table button battery ac > loop dm_mod sg sr_mod cdrom sd_mod generic usbhid ff_memless sis5513 sata_sis > 3c59x mii k8temp hwmon ehci_hcd shpchp pata_sis ohci_hcd pci_hotplug libata > sis_agp usbcore scsi_mod agpgart e1000 parport_pc lp parport ext3 mbcache jbd > linear raid456 xor raid0 edd fan siimage alim15x3 thermal processor ide_disk > ide_core > Sep 19 17:05:33 tweety kernel: CPU:0 > Sep 19 17:05:33 tweety kernel: EIP:0060:[]Not tainted VLI > Sep 19 17:05:33 tweety kernel: EFLAGS: 00010003 (2.6.21.3-default #2) > Sep 19 17:05:33 tweety kernel: EIP is at cache_alloc_refill+0xef/0x3f2 > Sep 19 17:05:33 tweety kernel: eax: 002a ebx: 09c123e8 ecx: 0006 > edx: 143baaf4 > Sep 19 17:05:33 tweety kernel: esi: e0dbf000 edi: f7f0dd40 ebp: f7f09000 > esp: eb173ed8 > Sep 19 17:05:33 tweety kernel: ds: 007b es: 007b fs: 00d8 gs: 0033 ss: > 0068 > Sep 19 17:05:33 tweety kernel: Process sshd (pid: 15749, ti=eb172000 > task=f476f030 task.ti=eb172000) > Sep 19 17:05:33 tweety kernel: Stack: 0029 00d0 f7f07c40 > 0035 e74d2200 c945ab7c df03fb7c > Sep 19 17:05:33 tweety kernel:b7d25000 b7d2f000 0246 00d0 > f7f07c40 cb5cb030 c015460e 0003 > Sep 19 17:05:33 tweety kernel:dc7e2320 0003 c0117379 c6c9f6d4 > f8c58000 eb173fb8 bf8b9c70 > Sep 19 17:05:33 tweety kernel: Call Trace: > Sep 19 17:05:33 tweety kernel: [] kmem_cache_alloc+0x36/0x40 > Sep 19 17:05:33 tweety kernel: [] copy_process+0x8e5/0xeea > Sep 19 17:05:33 tweety kernel: [] do_fork+0x9e/0x17d > Sep 19 17:05:33 tweety kernel: [] sys_clone+0x32/0x36 > Sep 19 17:05:33 tweety kernel: [] sysenter_past_esp+0x5d/0x81 > Sep 19 17:05:33 tweety kernel: === > Sep 19 17:05:33 tweety kernel: Code: 10 c7 47 30 01 00 00 00 39 c6 75 2e e9 > 8a 00 00 00 8b 44 24 08 8b 5e 14 8b 4d 00 8b 50 10 8b 04 24 0f af d3 40 03 56 > 0c 89 46 10 <8b> 44 9e 1c 89 46 14 89 54 8d 10 41 89 4d 00 8b 56 10 8b 4c 24 > Sep 19 17:05:33 tweety kernel: EIP: [] > cache_alloc_refill+0xef/0x3f2 SS:ESP 0068:eb173ed8 > Sep 19 17:05:33 tweety kernel: [ cut here ] > Sep 19 17:05:33 tweety kernel: kernel BUG at mm/slab.c:597! > Sep 19 17:05:33 tweety kernel: invalid opcode: [#2] > Sep 19 17:05:33 tweety kernel: Modules linked in: xt_tcpudp iptable_filter > ip_tables x_tables joydev st ide_cd capability commoncap nfsd exportfs lockd > nfs_acl sunrpc it87 hwmon_vid i2c_isa i2c_core cpufreq_conservative > cpufreq_ondemand cpufreq_powersave powernow_k8 freq_table button battery ac > loop dm_mod sg sr_mod cdrom sd_mod generic usbhid ff_memless sis5513 sata_sis > 3c59x mii k8temp hwmon ehci_hcd shpchp pata_sis ohci_hcd pci_hotplug libata > sis_agp usbcore scsi_mod agpgart e1000 parport_pc lp parport ext3 mbcache jbd > linear raid456 xor raid0 edd fan siimage alim15x3 thermal processor ide_disk > ide_core > Sep 19 17:05:33 tweety kernel: CPU:0 > Sep 19 17:05:33 tweety kernel: EIP:0060:[]Not tainted VLI > Sep 19 17:05:33 tweety kernel: EFLAGS: 00210202 (2.6.21.3-default #2) > Sep 19 17:05:33 tweety kernel: EIP is at kmem_cache_free+0x29/0x5a > Sep 19 17:05:33 tweety kernel: eax: 4868 ebx: e0fbb728 ecx: f7f07c40 > edx: c141f760 > Sep 19 17:05:33 tweety kernel: esi: edi: e0fbb728 ebp: e973f710 > esp: ea173f64 > Sep 19 17:05:33 tweety kernel: ds: 007b es: 007b fs: 00d8 gs: 0033 ss: > 0068 > Sep 19 17:05:33 tweety kernel: Process postmaster (pid: 3842, ti=ea172000 > task=f09a7030 task.ti=ea172000) > Sep 19 17:05:33 tweety kernel: Stack: e0fbb728 e0fbb728 c0149eef > f3a00900 e0fbb728 c014a821 > Sep 19 17:05:33 tweety kernel:b7f57000 b7f56000 b7f57000 e973f71c > e973f710 f3a00900 f3a00934
[PATCH 2/2] Uninline find_pid etc set of functions
The find_pid/_vpid/_pid_ns functions are used to find the
struct pid by its id, depending on whic id - global or
virtual - is used.
The find_vpid() is a macro that pushes the
current->nsproxy->pid_ns on the stack to call another
function - find_pid_ns(). It turned out, that this
dereference together with the push itself cause the kernel
text size to grow too much.
Move all these out-of-line. Together with the previous patch
this saves a bit less that 400 bytes from .text section.
Signed-off-by: Pavel Emelyanov <[EMAIL PROTECTED]>
---
diff --git a/fs/locks.c b/fs/locks.c
diff --git a/include/linux/pid.h b/include/linux/pid.h
index 4817c66..f79ba6f 100644
--- a/include/linux/pid.h
+++ b/include/linux/pid.h
@@ -110,9 +110,8 @@ extern struct pid_namespace init_pid_ns;
* see also find_task_by_pid() set in include/linux/sched.h
*/
extern struct pid *FASTCALL(find_pid_ns(int nr, struct pid_namespace *ns));
-
-#define find_vpid(pid) find_pid_ns(pid, current->nsproxy->pid_ns)
-#define find_pid(pid) find_pid_ns(pid, _pid_ns)
+extern struct pid *find_vpid(int nr);
+extern struct pid *find_pid(int nr);
/*
* Lookup a PID in the hash table, and return with it's count elevated.
diff --git a/kernel/pid.c b/kernel/pid.c
index e2e060e..f029c17 100644
--- a/kernel/pid.c
+++ b/kernel/pid.c
@@ -302,6 +302,18 @@ struct pid * fastcall find_pid_ns(int nr
}
EXPORT_SYMBOL_GPL(find_pid_ns);
+struct pid *find_vpid(int nr)
+{
+ return find_pid_ns(nr, current->nsproxy->pid_ns);
+}
+EXPORT_SYMBOL_GPL(find_vpid);
+
+struct pid *find_pid(int nr)
+{
+ return find_pid_ns(nr, _pid_ns);
+}
+EXPORT_SYMBOL_GPL(find_pid);
+
/*
* attach_pid() must be called with the tasklist_lock write-held.
*/
diff --git a/kernel/capability.c b/kernel/capability.c
index 0440d6d..4a881b8 100644
--- a/kernel/capability.c
+++ b/kernel/capability.c
@@ -97,7 +96,7 @@ static inline int cap_set_pg(int pgrp_nr
int found = 0;
struct pid *pgrp;
- pgrp = find_pid_ns(pgrp_nr, current->nsproxy->pid_ns);
+ pgrp = find_vpid(pgrp_nr);
do_each_pid_task(pgrp, PIDTYPE_PGID, g) {
target = g;
while_each_thread(g, target) {
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Broadcom 8603 SAS/SATA driver, rough draft
James Bottomley wrote: On the other hand, I think I can find a nice lever to move Marvell with, so I'll take this on without needing potentially to compromise your contacts. FWIW Marvell is moving quite nicely... they are actively providing docs under NDA, and sometimes sample code (or even a GPL driver) to active developers. Still trying to push them on opening docs, but one step at a time :) Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/2] Uninline find_task_by_xxx set of functions
The find_task_by_something is a set of macros are used to find
task by pid depending on what kind of pid is proposed - global
or virtual one. All of them are wrappers above the most generic
one - find_task_by_pid_type_ns() - and just substitute some
args for it.
It turned out, that dereferencing the current->nsproxy->pid_ns
construction and pushing one more argument on the stack inline
cause kernel text size to grow.
This patch moves all this stuff out-of-line into kernel/pid.c.
Together with the next patch it saves a bit less than 400 bytes
from the .text section.
Signed-off-by: Pavel Emelyanov <[EMAIL PROTECTED]>
---
diff --git a/include/linux/sched.h b/include/linux/sched.h
index 12ef317..8c0e146 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -1495,9 +1495,8 @@ extern struct pid_namespace init_pid_ns;
* type and namespace specified
* find_task_by_pid_ns():
* finds a task by its pid in the specified namespace
- * find_task_by_pid_type():
- * finds a task by its global id with the specified type, e.g.
- * by global session id
+ * find_task_by_vpid():
+ * finds a task by its virtual pid
* find_task_by_pid():
* finds a task by its global pid
*
@@ -1507,12 +1506,10 @@ extern struct pid_namespace init_pid_ns;
extern struct task_struct *find_task_by_pid_type_ns(int type, int pid,
struct pid_namespace *ns);
-#define find_task_by_pid_ns(nr, ns)\
- find_task_by_pid_type_ns(PIDTYPE_PID, nr, ns)
-#define find_task_by_pid_type(type, nr)\
- find_task_by_pid_type_ns(type, nr, _pid_ns)
-#define find_task_by_pid(nr) \
- find_task_by_pid_type(PIDTYPE_PID, nr)
+extern struct task_struct *find_task_by_pid(pid_t nr);
+extern struct task_struct *find_task_by_vpid(pid_t nr);
+extern struct task_struct *find_task_by_pid_ns(pid_t nr,
+ struct pid_namespace *ns);
extern void __set_special_pids(pid_t session, pid_t pgrp);
diff --git a/kernel/pid.c b/kernel/pid.c
index e2e060e..f029c17 100644
--- a/kernel/pid.c
+++ b/kernel/pid.c
@@ -368,6 +380,25 @@ struct task_struct *find_task_by_pid_typ
EXPORT_SYMBOL(find_task_by_pid_type_ns);
+struct task_struct *find_task_by_pid(pid_t nr)
+{
+ return find_task_by_pid_type_ns(PIDTYPE_PID, nr, _pid_ns);
+}
+EXPORT_SYMBOL(find_task_by_pid);
+
+struct task_struct *find_task_by_vpid(pid_t vnr)
+{
+ return find_task_by_pid_type_ns(PIDTYPE_PID, vnr,
+ current->nsproxy->pid_ns);
+}
+EXPORT_SYMBOL(find_task_by_vpid);
+
+struct task_struct *find_task_by_pid_ns(pid_t nr, struct pid_namespace *ns)
+{
+ return find_task_by_pid_type_ns(PIDTYPE_PID, nr, ns);
+}
+EXPORT_SYMBOL(find_task_by_pid_ns);
+
struct pid *get_task_pid(struct task_struct *task, enum pid_type type)
{
struct pid *pid;
diff --git a/fs/ioprio.c b/fs/ioprio.c
index 0a615f8..d6ff77e 100644
--- a/fs/ioprio.c
+++ b/fs/ioprio.c
@@ -94,8 +94,7 @@ asmlinkage long sys_ioprio_set(int which
if (!who)
p = current;
else
- p = find_task_by_pid_ns(who,
- current->nsproxy->pid_ns);
+ p = find_task_by_vpid(who);
if (p)
ret = set_task_ioprio(p, ioprio);
break;
@@ -182,8 +181,7 @@ asmlinkage long sys_ioprio_get(int which
if (!who)
p = current;
else
- p = find_task_by_pid_ns(who,
- current->nsproxy->pid_ns);
+ p = find_task_by_vpid(who);
if (p)
ret = get_task_ioprio(p);
break;
diff --git a/kernel/capability.c b/kernel/capability.c
index 0440d6d..4a881b8 100644
--- a/kernel/capability.c
+++ b/kernel/capability.c
@@ -63,8 +63,7 @@ asmlinkage long sys_capget(cap_user_head
read_lock(_lock);
if (pid && pid != task_pid_vnr(current)) {
- target = find_task_by_pid_ns(pid,
- current->nsproxy->pid_ns);
+ target = find_task_by_vpid(pid);
if (!target) {
ret = -ESRCH;
goto out;
@@ -198,8 +197,7 @@ asmlinkage long sys_capset(cap_user_head
read_lock(_lock);
if (pid > 0 && pid != task_pid_vnr(current)) {
- target = find_task_by_pid_ns(pid,
- current->nsproxy->pid_ns);
+ target = find_task_by_vpid(pid);
if (!target) {
ret = -ESRCH;
goto out;
diff --git a/kernel/futex.c b/kernel/futex.c
index 0c1b777..0d51412 100644
--- a/kernel/futex.c
+++
Re: [RFC] New kernel-message logging API
On Mon, 2007-09-24 at 11:22 +0200, Michael Holzheu wrote: > Together with the idea of not allowing multiple lines in the kprint_xxx > functions, that would go with our approach having message numbers to > identify a message. How does this equate/give message numbers? > If you do it like that, you can't support "%s", since then you would > store only the pointer and not the whole string. I think, that we can't > live without %s. long long would not work either. Perhaps it's better to scan the format string or indirect the printk formatting logic. Another possibility: An added pass between gcc preprocessor and compiler could compact or compress the format string without modifying the conversion specifications so __attribute__ ((format (printf)) would still work. printk could expand the compacted/compressed format. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.23-rc7-mm1 ia64 build issue in efi.c
There isn't a total_memory identifier within this function's scope. The patch was compile/link tested. Signed-off-by: Bob Picco <[EMAIL PROTECTED]> arch/ia64/kernel/efi.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) Index: linux-2.6.23-rc7-mm1/arch/ia64/kernel/efi.c === --- linux-2.6.23-rc7-mm1.orig/arch/ia64/kernel/efi.c2007-09-24 09:54:40.0 -0400 +++ linux-2.6.23-rc7-mm1/arch/ia64/kernel/efi.c 2007-09-24 10:50:51.0 -0400 @@ -1085,7 +1085,7 @@ efi_memmap_init(unsigned long *s, unsign *s = (u64)kern_memmap; *e = (u64)++k; - return total_memory; + return total_mem; } void - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] 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] Trace code and documentation (updated)
Christoph Hellwig wrote: Your mailer wrapper the patch so I can't actually apply it to start playing with the patch. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ This one should be better: http://lkml.org/lkml/2007/9/22/4 You already responded, so you must have found it. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] change inotifyfs magic as the same magic is used for futexfs (v2)
On Mon, 24 Sep 2007 12:46:06 +0400 Andrey Mirkin wrote:
> From: Andrey Mirkin <[EMAIL PROTECTED]>
>
> Right now futexfs and inotifyfs have one magic 0xBAD1DEA, that looks a little
> bit confusing.
> Use 0xBAD1DEA as magic for futexfs and 0x2BAD1DEA as magic for inotifyfs.
>
> Signed-off-by: Andrey Mirkin <[EMAIL PROTECTED]>
Acked-by: Randy Dunlap <[EMAIL PROTECTED]>
>
>
> fs/inotify_user.c |4 +++-
> include/linux/magic.h |3 +++
> kernel/futex.c|3 ++-
> 3 files changed, 8 insertions(+), 2 deletions(-)
>
> diff --git a/fs/inotify_user.c b/fs/inotify_user.c
> index 9bf2f6c..5e00933 100644
> --- a/fs/inotify_user.c
> +++ b/fs/inotify_user.c
> @@ -31,6 +31,7 @@ #include
> #include
> #include
> #include
> +#include
>
> #include
>
> @@ -684,7 +685,8 @@ static int
> inotify_get_sb(struct file_system_type *fs_type, int flags,
> const char *dev_name, void *data, struct vfsmount *mnt)
> {
> - return get_sb_pseudo(fs_type, "inotify", NULL, 0xBAD1DEA, mnt);
> + return get_sb_pseudo(fs_type, "inotify", NULL,
> + INOTIFYFS_SUPER_MAGIC, mnt);
> }
>
> static struct file_system_type inotify_fs_type = {
> diff --git a/include/linux/futex.h b/include/linux/futex.h
> diff --git a/include/linux/inotify.h b/include/linux/inotify.h
> diff --git a/include/linux/magic.h b/include/linux/magic.h
> index 36cc20d..722d475 100644
> --- a/include/linux/magic.h
> +++ b/include/linux/magic.h
> @@ -38,4 +38,7 @@ #define REISER2FS_JR_SUPER_MAGIC_STRING
> #define SMB_SUPER_MAGIC 0x517B
> #define USBDEVICE_SUPER_MAGIC0x9fa2
>
> +#define FUTEXFS_SUPER_MAGIC 0xBAD1DEA
> +#define INOTIFYFS_SUPER_MAGIC0x2BAD1DEA
> +
> #endif /* __LINUX_MAGIC_H__ */
> diff --git a/kernel/futex.c b/kernel/futex.c
> index e8935b1..856dfba 100644
> --- a/kernel/futex.c
> +++ b/kernel/futex.c
> @@ -52,6 +52,7 @@ #include
> #include
> #include
> #include
> +#include
> #include
>
> #include "rtmutex_common.h"
> @@ -2074,7 +2075,7 @@ static int futexfs_get_sb(struct file_sy
> int flags, const char *dev_name, void *data,
> struct vfsmount *mnt)
> {
> - return get_sb_pseudo(fs_type, "futex", NULL, 0xBAD1DEA, mnt);
> + return get_sb_pseudo(fs_type, "futex", NULL, FUTEXFS_SUPER_MAGIC, mnt);
> }
>
> static struct file_system_type futex_fs_type = {
> -
---
~Randy
Phaedrus says that Quality is about caring.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [v4l-dvb-maintainer] [PATCH] cafe_ccic: default to allocating DMA buffers at probe time
Hi Andres,
Still missing on your patch is your SOB ;) From what I got from Jon, he
is ok with your patch.
Cheers,
Mauro.
Em Qua, 2007-09-19 às 01:44 -0400, Andres Salomon escreveu:
> By default, we allocate DMA buffers when actually reading from the video
> capture device. On a system with 128MB or 256MB of ram, it's very easy
> for that memory to quickly become fragmented. We've had users report
> having 30+MB of memory free, but the cafe_ccic driver is still unable to
> allocate DMA buffers.
>
> Our workaround has been to make use of the 'alloc_bufs_at_load' parameter
> to allocate DMA buffers during device probing. This patch makes DMA
> buffer allocation happen during device probe by default, and changes
> the parameter to 'alloc_bufs_at_read'. The camera hardware is there,
> if the cafe_ccic driver is enabled/loaded it should do its best to ensure
> that the camera is actually usable; delaying DMA buffer allocation
> saves an insignicant amount of memory, and causes the driver to be much
> less useful.
> ---
>
> drivers/media/video/cafe_ccic.c | 18 +-
> 1 files changed, 9 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/media/video/cafe_ccic.c b/drivers/media/video/cafe_ccic.c
> index ef53618..3588a59 100644
> --- a/drivers/media/video/cafe_ccic.c
> +++ b/drivers/media/video/cafe_ccic.c
> @@ -63,13 +63,13 @@ MODULE_SUPPORTED_DEVICE("Video");
> */
>
> #define MAX_DMA_BUFS 3
> -static int alloc_bufs_at_load = 0;
> -module_param(alloc_bufs_at_load, bool, 0444);
> -MODULE_PARM_DESC(alloc_bufs_at_load,
> - "Non-zero value causes DMA buffers to be allocated at module "
> - "load time. This increases the chances of successfully getting
> "
> - "those buffers, but at the cost of nailing down the memory from
> "
> - "the outset.");
> +static int alloc_bufs_at_read = 0;
> +module_param(alloc_bufs_at_read, bool, 0444);
> +MODULE_PARM_DESC(alloc_bufs_at_read,
> + "Non-zero value causes DMA buffers to be allocated when the "
> + "video capture device is read, rather than at module load "
> + "time. This saves memory, but decreases the chances of "
> + "successfully getting those buffers.");
>
> static int n_dma_bufs = 3;
> module_param(n_dma_bufs, uint, 0644);
> @@ -1503,7 +1503,7 @@ static int cafe_v4l_release(struct inode *inode, struct
> file *filp)
> }
> if (cam->users == 0) {
> cafe_ctlr_power_down(cam);
> - if (! alloc_bufs_at_load)
> + if (alloc_bufs_at_read)
> cafe_free_dma_bufs(cam);
> }
> mutex_unlock(>s_mutex);
> @@ -2162,7 +2162,7 @@ static int cafe_pci_probe(struct pci_dev *pdev,
> /*
>* If so requested, try to get our DMA buffers now.
>*/
> - if (alloc_bufs_at_load) {
> + if (!alloc_bufs_at_read) {
> if (cafe_alloc_dma_bufs(cam, 1))
> cam_warn(cam, "Unable to alloc DMA buffers at load"
> " will try again later.");
>
> ___
> v4l-dvb-maintainer mailing list
> [EMAIL PROTECTED]
> http://www.linuxtv.org/cgi-bin/mailman/listinfo/v4l-dvb-maintainer
--
Cheers,
Mauro
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.23-rc4-mm1 and -rc6-mm1: boot failure on HP nx6325, related to clockevents
On Monday, 24 September 2007 16:23, Thomas Gleixner wrote: > On Mon, 2007-09-24 at 15:52 +0200, Rafael J. Wysocki wrote: > > > > > So I really wonder, why noacpitimer on the kernel command line makes > > > > > any > > > > > difference. I'm confused. > > > > > > > > \metoo > > > > > > > > Well, it was probably read as "noacpi". :-) > > > > > > Hmm, ACPI is in the log all over the place. > > > > Well, "noacpi" seems to be a synonym for "pci=noacpi". > > > > Anyway, it causes acpi_disable_pci() to be executed, which according to > > Documentation/kernel-parameters.txt means "Do not use ACPI for IRQ routing > > or > > for PCI scanning" (it works like this on x86_64 too, although the doc says > > it's > > x86_32-specific). > > Hrm. The local apic timer calibration does not use anything which is > related to interrupts, but if we use the local APIC timer we switch off > PIT. > > Can you boot Linus latest (w/o hrt patches) and add "apicmaintimer" to > the kernel command line please ? Works, dmesg attached. Greetings, Rafael Linux version 2.6.23-rc7test ([EMAIL PROTECTED]) (gcc version 4.1.2 20061115 (prerelease) (SUSE Linux)) #19 SMP Mon Sep 24 16:55:05 CEST 2007 Command line: root=/dev/sda3 vga=792 resume=/dev/sda1 apicmaintimer apic=verbose 2 BIOS-provided physical RAM map: BIOS-e820: - 0009fc00 (usable) BIOS-e820: 0009fc00 - 000a (reserved) BIOS-e820: 000e - 0010 (reserved) BIOS-e820: 0010 - 77fd (usable) BIOS-e820: 77fd - 77fe5600 (reserved) BIOS-e820: 77fe5600 - 77ff8000 (ACPI NVS) BIOS-e820: 77ff8000 - 8000 (reserved) BIOS-e820: e000 - f000 (reserved) BIOS-e820: fec0 - fec02000 (reserved) BIOS-e820: ffbc - ffcc (reserved) BIOS-e820: fff0 - 0001 (reserved) Entering add_active_range(0, 0, 159) 0 entries of 256 used Entering add_active_range(0, 256, 491472) 1 entries of 256 used end_pfn_map = 1048576 DMI 2.4 present. ACPI: RSDP 000F7D30, 0024 (r2 HP) ACPI: XSDT 77FE57B4, 0054 (r1 HP 0944 6070620 HP 1) ACPI: FACP 77FE5684, 00F4 (r4 HP 09443 HP 1) ACPI: DSDT 77FE58DC, EE7A (r1 HPSB4001 MSFT 10E) ACPI: FACS 77FF7E80, 0040 ACPI: APIC 77FE5808, 0062 (r1 HP 09441 HP 1) ACPI: MCFG 77FE586C, 003C (r1 HP 09441 HP 1) ACPI: TCPA 77FE58A8, 0032 (r2 HP 09441 HP 1) ACPI: SSDT 77FF4756, 0059 (r1 HP HPQNLP1 MSFT 10E) ACPI: SSDT 77FF47AF, 0206 (r1 HP PSSTBLID1 HP 1) Entering add_active_range(0, 0, 159) 0 entries of 256 used Entering add_active_range(0, 256, 491472) 1 entries of 256 used No mptable found. Zone PFN ranges: DMA 0 -> 4096 DMA324096 -> 1048576 Normal1048576 -> 1048576 Movable zone start PFN for each node early_node_map[2] active PFN ranges 0:0 -> 159 0: 256 -> 491472 On node 0 totalpages: 491375 DMA zone: 56 pages used for memmap DMA zone: 1442 pages reserved DMA zone: 2501 pages, LIFO batch:0 DMA32 zone: 6663 pages used for memmap DMA32 zone: 480713 pages, LIFO batch:31 Normal zone: 0 pages used for memmap Movable zone: 0 pages used for memmap ATI board detected. Disabling timer routing over 8254. ACPI: PM-Timer IO Port: 0x8008 ACPI: Local APIC address 0xfee0 ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled) Processor #0 (Bootup-CPU) ACPI: LAPIC (acpi_id[0x02] lapic_id[0x01] enabled) Processor #1 ACPI: LAPIC_NMI (acpi_id[0x01] high edge lint[0x1]) ACPI: IOAPIC (id[0x02] address[0xfec0] gsi_base[0]) IOAPIC[0]: apic_id 2, address 0xfec0, GSI 0-23 ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 21 low level) ACPI: IRQ0 used by override. ACPI: IRQ2 used by override. Setting APIC routing to flat Using ACPI (MADT) for SMP configuration information mapped APIC to ff5fb000 (fee0) mapped IOAPIC to ff5fa000 (fec0) swsusp: Registered nosave memory region: 0009f000 - 000a swsusp: Registered nosave memory region: 000a - 000e swsusp: Registered nosave memory region: 000e - 0010 Allocating PCI resources starting at 8800 (gap: 8000:6000) SMP: Allowing 2 CPUs, 0 hotplug CPUs PERCPU: Allocating 47320 bytes of per cpu data Built 1 zonelists in Zone order. Total pages: 483214 Kernel command line: root=/dev/sda3 vga=792 resume=/dev/sda1 apicmaintimer apic=verbose 2 Initializing CPU#0 PID hash table entries: 4096 (order: 12, 32768 bytes) Extended CMOS year: 2000 Marking TSC unstable due to TSCs unsynchronized time.c: Detected 1995.108 MHz processor. Console: colour dummy device 80x25 console [tty0] enabled Dentry cache hash table
Re: 2.6.23-rc7-mm1
On 24/09/2007 7:17 PM, Andrew Morton wrote:
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23-rc7/2.6.23-rc7-mm1/
- New git tree git-powerpc-galak.patch added to the -mm lineup: ppc32
things, mainly (Kumar Gala <[EMAIL PROTECTED]>)
I'm observing a problem with this kernel (as well as 2.6.23-rc6-mm1) which
manifests itself only in my Postfix/application mail.logs:
Sep 25 00:25:40 tornado postfix/smtp[12520]: fatal: select lock: Cannot allocate
memory
Sep 25 00:25:41 tornado postfix/master[8002]: warning: process
/usr/lib64/postfix/smtp pid 12520 exit status 1
This is happening frequently with processes started via 'master' (smtp, smtpd
and cleanup), but it does not appear to have any noticeable operational impact
apart from logging a lot of copies of this message.
The corresponding code in Postfix which triggers this is (choice of 3 files in
src/master are all possibilities which all have much the same code)
/*
* The event loop, at last.
*/
while (var_use_limit == 0 || use_count < var_use_limit || client_count > 0)
{
if (multi_server_lock != 0) {
watchdog_stop(watchdog);
if (myflock(vstream_fileno(multi_server_lock), INTERNAL_LOCK,
MYFLOCK_OP_EXCLUSIVE) < 0)
msg_fatal("select lock: %m");
}
watchdog_start(watchdog);
delay = loop ? loop(multi_server_name, multi_server_argv) : -1;
event_loop(delay);
}
multi_server_exit();
}
Now I'm not convinced this is an application problem, because I'm only seeing
this after running up kernel 2.6.23-rc6-mm1 or 2.6.23-rc7-mm1 and with NO
changes to the application itself. Using the same application binaries it does
not occur with 2.6.22 mainline. [I didn't get a lot of testing with the -mm
release prior to that unfortunately due to some other breakage.]
Is there anything new in the last two or so -mm kernels which could have caused
this?
I've put my .config up at http://www.reub.net/files/kernel/2.6.23-rc7-mm1.config
Thanks,
Reuben
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.23-rc7 + radeonfb/s2ram
On Sat, Sep 22, 2007 at 07:27:59AM +0200, Mihai Donțu wrote: > Hi, > > Today, out of curiosity, I pulled 2.6.23-rc7 (leave on the edge in a quiet > weekend). > Anyway, it seems that radeonfb and my: > "01:05.0 VGA compatible controller: ATI Technologies Inc ATI Radeon XPRESS > 200M 5955 (PCIE)" > don't get along anymore, by: > a) X somehow fails to initialize the card and everything moves really slow (I > can >see how surfaces are drawn pixel-by-pixel); furthermore, garbage stuff > appears >on the screen; Have you tried to boot your kernel with video=radeonfb:noaccel I usual add this kernel parameter when running radeonfb and X. Otherwise I've observed the same symptoms (e.g. with my radeon card at home: Radeon X300SE, 1002:5b70). Regards, Andreas - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-usb-devel] 2.6.23-rc7-mm1
On Mon, 24 Sep 2007, Jiri Slaby wrote: > On 09/24/2007 11:17 AM, Andrew Morton wrote: > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23-rc7/2.6.23-rc7-mm1/ > > Fine, but on some boots (I noticed this on rc6-mm1 too, but not before): > :00:1a.7 EHCI: BIOS handoff failed (BIOS bug ?) 01010001 > :00:1d.7 EHCI: BIOS handoff failed (BIOS bug ?) 01010001 Any changes in your BIOS setup? What about with vanilla 2.6.23-rc6? Or vanilla 2.6.23-rc7? The USB part of the code here hasn't changed in quite a while. Any difference in behavior must be the result of changes in some other part of the kernel. Possibly ACPI. This might be a good job for git-bisect. Alan Stern - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] sb1250-mac: Driver model & phylib update
On Fri, 21 Sep 2007, Andrew Morton wrote: > > A driver model and phylib update. > > akpm:/usr/src/25> diffstat patches/git-net.patch | tail -n 1 > 1013 files changed, 187667 insertions(+), 23587 deletions(-) > > Sorry, but raising networking patches against Linus's crufty > old mainline tree just isn't viable at present. Well, this is against Jeff's netdev-2.6 tree which hopefully is not as crufty as Linus's old mainline; if it is not possible to queue this change for 2.6.25 or suchlike, then I will try to resubmit later. Thanks for your attention though. Maciej - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 24/25] r/o bind mounts: track number of mount writers
> It look like a false positive to me, but really, for a patchset of > this complexity and maturity I cannot fathom how it could have > escaped any lockdep testing. the code tries to implement per cpu spinlocks, or rather it tries to bring back the brlocks from way past cute. we can educate lockdep about this quite easily; but isn't there some primitive already in existence that we can use? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] sysfs: backport of sysfs_readdir fix from 2.6.22.y to 2.6.16.y (CVE-2007-3104)
(Adrian should be CCed on things regarding 2.6.16.y kernel)
On Sun, 23 Sep 2007, Miloslav Semler wrote:
> This patch solves CVE-2007-3104 - sysfs_readdir oops.
> More can be found here:
> http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.22.y.git;a=commit;h=dc351252b33f8fede396d6173dba117bcb933607
>
> Signed-off-by: Miloslav Semler
> ---
> diff -uprN linux-2.6.16.53/fs/sysfs/dir.c linux-2.6.16.53-new/fs/sysfs/dir.c
> --- linux-2.6.16.53/fs/sysfs/dir.c 2007-07-25 23:05:45.0 +0200
> +++ linux-2.6.16.53-new/fs/sysfs/dir.c 2007-09-23 18:18:09.0 +0200
> @@ -29,6 +29,14 @@ static struct dentry_operations sysfs_de
>.d_iput = sysfs_d_iput,
> };
>
> +static unsigned int sysfs_inode_counter;
> +ino_t sysfs_get_inum(void)
> +{
> + if (unlikely(sysfs_inode_counter < 3))
> + sysfs_inode_counter = 3;
> + return sysfs_inode_counter++;
> +}
> +
> /*
> * Allocates a new sysfs_dirent and links it to the parent sysfs_dirent
> */
> @@ -40,8 +48,10 @@ static struct sysfs_dirent * sysfs_new_d
>sd = kmem_cache_alloc(sysfs_dir_cachep, GFP_KERNEL);
>if (!sd)
>return NULL;
> +
>
>memset(sd, 0, sizeof(*sd));
> + sd->s_ino = sysfs_get_inum();
>atomic_set(>s_count, 1);
>INIT_LIST_HEAD(>s_children);
>list_add(>s_sibling, _sd->s_children);
> @@ -385,7 +395,7 @@ static int sysfs_readdir(struct file * f
>
>switch (i) {
>case 0:
> - ino = dentry->d_inode->i_ino;
> +ino = parent_sd->s_ino;
>if (filldir(dirent, ".", 1, i, ino, DT_DIR) < 0)
>break;
>filp->f_pos++;
> @@ -415,10 +425,7 @@ static int sysfs_readdir(struct file * f
>
>name = sysfs_get_name(next);
>len = strlen(name);
> - if (next->s_dentry)
> - ino = next->s_dentry->d_inode->i_ino;
> - else
> - ino = iunique(sysfs_sb, 2);
> +ino = next->s_ino;
>
>if (filldir(dirent, name, len, filp->f_pos,
> ino,
> dt_type(next)) < 0)
> diff -uprN linux-2.6.16.53/fs/sysfs/inode.c
> linux-2.6.16.53-new/fs/sysfs/inode.c
> --- linux-2.6.16.53/fs/sysfs/inode.c2007-07-25 23:05:45.0 +0200
> +++ linux-2.6.16.53-new/fs/sysfs/inode.c2007-09-23 18:18:09.0
> +0200
> @@ -119,6 +119,7 @@ struct inode * sysfs_new_inode(mode_t mo
>inode->i_mapping->a_ops = _aops;
>inode->i_mapping->backing_dev_info =
> _backing_dev_info;
>inode->i_op = _inode_operations;
> +inode->i_ino = sd->s_ino;
>
>if (sd->s_iattr) {
>/* sysfs_dirent has non-default attributes
> diff -uprN linux-2.6.16.53/fs/sysfs/mount.c
> linux-2.6.16.53-new/fs/sysfs/mount.c
> --- linux-2.6.16.53/fs/sysfs/mount.c2007-07-25 23:05:45.0 +0200
> +++ linux-2.6.16.53-new/fs/sysfs/mount.c2007-09-23 18:18:09.0
> +0200
> @@ -29,6 +29,7 @@ static struct sysfs_dirent sysfs_root =
>.s_element = NULL,
>.s_type = SYSFS_ROOT,
>.s_iattr= NULL,
> +.s_ino = 1,
> };
>
> static int sysfs_fill_super(struct super_block *sb, void *data, int silent)
> diff -uprN linux-2.6.16.53/include/linux/sysfs.h
> linux-2.6.16.53-new/include/linux/sysfs.h
> --- linux-2.6.16.53/include/linux/sysfs.h 2007-07-25 23:05:45.0
> +0200
> +++ linux-2.6.16.53-new/include/linux/sysfs.h 2007-09-23 18:18:09.0
> +0200
> @@ -72,6 +72,7 @@ struct sysfs_dirent {
>void* s_element;
>int s_type;
>umode_t s_mode;
> +ino_t s_ino;
>struct dentry * s_dentry;
>struct iattr* s_iattr;
> };
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.23-rc7 - _random_ IRQ23 : nobody cared
Paul Rolland "(???) wrote: Hell, IRQ 23 is shared between libata and my modem !!! Tried using the modem? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.23-rc4-mm1 and -rc6-mm1: boot failure on HP nx6325, related to clockevents
On Mon, 2007-09-24 at 15:52 +0200, Rafael J. Wysocki wrote: > > > > So I really wonder, why noacpitimer on the kernel command line makes any > > > > difference. I'm confused. > > > > > > \metoo > > > > > > Well, it was probably read as "noacpi". :-) > > > > Hmm, ACPI is in the log all over the place. > > Well, "noacpi" seems to be a synonym for "pci=noacpi". > > Anyway, it causes acpi_disable_pci() to be executed, which according to > Documentation/kernel-parameters.txt means "Do not use ACPI for IRQ routing or > for PCI scanning" (it works like this on x86_64 too, although the doc says > it's > x86_32-specific). Hrm. The local apic timer calibration does not use anything which is related to interrupts, but if we use the local APIC timer we switch off PIT. Can you boot Linus latest (w/o hrt patches) and add "apicmaintimer" to the kernel command line please ? > And yes, it matches "noacpiwhatever" in the command line with "noacpi". Sigh. Urgh. tglx - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Broadcom 8603 SAS/SATA driver, rough draft
On Sun, 2007-09-23 at 20:14 -0400, Jeff Garzik wrote: > James Bottomley wrote: > > On Sun, 2007-09-23 at 19:43 -0400, Jeff Garzik wrote: > >> James Bottomley wrote: > >>> On Sun, 2007-09-23 at 00:04 -0400, Jeff Garzik wrote: > Rather than sitting on this for far too long, I wanted to go ahead and > get this out there. I heard some chips might be trickling out into > public hands. > >>> The first thing to note is about the specs and the pre-production > >>> hardware: the Linux Foundation has mechanism to get both into the hands > >>> of interested developers; if you can point me to contacts, I can at > >>> least get the NDA documentation programme ball rolling. > >> Well, are there interested, motivated, skilled developers with time? :) > >> > >> Otherwise it's a moot point. > > > > We have GregKH's minions ... this would be a good project for them. > > > Same answer ... GregKH has a legion ... lets use it. > > This is a good project for somebody who knows how SAS behaves on the > wire, which is a rather limited group. > > I'm willing to help anyone who proactively moves in this direction, but > they need to be proactive about it... I am the person who will have to > make introductions at Broadcom, and convince Broadcom that new Person is > a highly capable SAS software engineer. > > Telling bcm "I don't know this guy, its doubtful he knows SAS, but we > want to make him the primary engineer anyway" is not a very winning tale :) I wasn't actually planning that ... I was planning to say we have an NDA programme to allow them to get their docs and early access silicon in to the hands of potential developers who can help on the driver. > > SMP and STP, by the way, are simple frame in, frame out. If it > > identifies the initiator and target protocols and allows us to send > > frames, we can probably transmit both protocols. > [...] > > That's going to be a bit of a bit oops ... > [...] > > well, I suppose it was designed for simple direct connection ... > > That's the way it's looking. There are a few avenues for exposing > IDENTIFY and OPEN frames and related details, but no obvious "any frame, > no problem" method like with the Marvell chip. > > IMO it's also indicative that Marvell's chip uses a single set of > command and response queues, whereas Broadcom has command/response > queues for each "port" (bcm's term). Heh, OK ... I'm happy to bet that the market won't be too appreciative of a chip like this, unless its sold as pure SATA. The only real reason for HBAs to speak SAS as well as SATA is that most dual SAS/SATA enclosures have internal expanders, which this chip won't be able to talk to. On the other hand, I think I can find a nice lever to move Marvell with, so I'll take this on without needing potentially to compromise your contacts. James - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/3] CRED: Split the task security data and move part of it into struct cred
Quoting David Howells ([EMAIL PROTECTED]):
> Move into the cred struct the part of the task security data that defines how
> a
> task acts upon an object. The part that defines how something acts upon a
> task
> remains attached to the task.
>
> For SELinux this requires some of task_security_struct to be split off into
> cred_security_struct which is then attached to struct cred. Note that the
> contents of cred_security_struct may not be changed without the generation of
> a
> new struct cred.
>
> The split is as follows:
>
> (*) create_sid, keycreate_sid and sockcreate_sid just move across.
>
> (*) sid is split into victim_sid - which remains - and action_sid - which
> migrates.
My concern is with this victim_sid. Whether the concern is valid
depends on exactly how the other credentials can be used, which isn't
yet entirely clear to me.
So my concern is that while a task is acting with alternate creds,
another task can act upon it based upon victim_sid. So does this
open up the possibility for an unprivileged task to ptrace or kill
a task in the middle of a privileged operation? Is that somehow
safe in the way this is used here?
I guess I need to look more at the actual nfs patches etc.
thanks,
-serge
> (*) osid, exec_sid and ptrace_sid remain.
>
> victim_sid is the SID used to govern actions upon the task. action_sid is
> used
> to govern actions made by the task.
>
> When accessing the cred_security_struct of another process, RCU read
> procedures
> must be observed.
>
> Signed-off-by: David Howells <[EMAIL PROTECTED]>
> ---
>
> include/linux/cred.h |1
> include/linux/security.h | 34 +++
> kernel/cred.c |7 +
> security/dummy.c | 11 +
> security/selinux/exports.c|6
> security/selinux/hooks.c | 497
> +++--
> security/selinux/include/objsec.h | 16 +
> security/selinux/selinuxfs.c |8 -
> security/selinux/xfrm.c |6
> 9 files changed, 380 insertions(+), 206 deletions(-)
>
> diff --git a/include/linux/cred.h b/include/linux/cred.h
> index 22ae610..6c6feec 100644
> --- a/include/linux/cred.h
> +++ b/include/linux/cred.h
> @@ -26,6 +26,7 @@ struct cred {
> gid_t gid;/* fsgid as was */
> struct rcu_head exterminate;/* cred destroyer */
> struct group_info *group_info;
> + void*security;
>
> /* caches for references to the three task keyrings
>* - note that key_ref_t isn't typedef'd at this point, hence the odd
> diff --git a/include/linux/security.h b/include/linux/security.h
> index 1a15526..e5ed2ea 100644
> --- a/include/linux/security.h
> +++ b/include/linux/security.h
> @@ -504,6 +504,18 @@ struct request_sock;
> * @file contains the file structure being received.
> * Return 0 if permission is granted.
> *
> + * Security hooks for credential structure operations.
> + *
> + * @cred_dup:
> + * Duplicate the credentials onto a duplicated cred structure.
> + * @cred points to the credentials structure. cred->security points to the
> + * security struct that was attached to the original cred struct, but it
> + * lacks a reference for the duplication if reference counting is needed.
> + *
> + * @cred_destroy:
> + * Destroy the credentials attached to a cred structure.
> + * @cred points to the credentials structure that is to be destroyed.
> + *
> * Security hooks for task operations.
> *
> * @task_create:
> @@ -1257,6 +1269,9 @@ struct security_operations {
> struct fown_struct * fown, int sig);
> int (*file_receive) (struct file * file);
>
> + int (*cred_dup)(struct cred *cred);
> + void (*cred_destroy)(struct cred *cred);
> +
> int (*task_create) (unsigned long clone_flags);
> int (*task_alloc_security) (struct task_struct * p);
> void (*task_free_security) (struct task_struct * p);
> @@ -1864,6 +1879,16 @@ static inline int security_file_receive (struct file
> *file)
> return security_ops->file_receive (file);
> }
>
> +static inline int security_cred_dup(struct cred *cred)
> +{
> + return security_ops->cred_dup(cred);
> +}
> +
> +static inline void security_cred_destroy(struct cred *cred)
> +{
> + return security_ops->cred_destroy(cred);
> +}
> +
> static inline int security_task_create (unsigned long clone_flags)
> {
> return security_ops->task_create (clone_flags);
> @@ -2546,6 +2571,15 @@ static inline int security_file_receive (struct file
> *file)
> return 0;
> }
>
> +static inline int security_cred_dup(struct cred *cred)
> +{
> + return 0;
> +}
> +
> +static inline void security_cred_destroy(struct cred *cred)
> +{
> +}
> +
> static inline int security_task_create (unsigned long clone_flags)
> {
> return 0;
> diff --git a/kernel/cred.c b/kernel/cred.c
> index
Re: + git-nfs-vs-nfs-convert-to-new-aops.patch added to -mm tree
On Thu, 20 Sep 2007 13:20:47 +0200 Peter Zijlstra <[EMAIL PROTECTED]> wrote: > /me continues the mmap write on nfs adventure... My test prog reliably hangs like so: mm_tester D 0040b305 0 2701 2699 6042cef0 602ca520 617dfa50 617de000 617dfa90 60010b62 617dfa80 6002785d 617de000 60583840 6042bcc0 6042ca40 617dfad0 6019e3c2 0008 617de000 617dfae0 c0e7 617dfb38 0002 617dfb60 6019eb20 616e7ae0 6048bd00 Call Trace: Call Trace: 617dfa58: [<60010b62>] _switch_to+0x81/0xf5 617dfa68: [<6002785d>] pick_next_entity+0x1a/0x38 617dfa98: [<6019e3c2>] schedule+0x1b8/0x23f 617dfad8: [<6019eb20>] schedule_timeout+0xa2/0xcb 617dfaf8: [<60035dc3>] process_timeout+0x0/0xb 617dfb10: [<6019eb1b>] schedule_timeout+0x9d/0xcb 617dfb68: [<6019ea62>] io_schedule_timeout+0xf/0x17 617dfb78: [<6004f0d1>] sync_page+0x6b/0x6f 617dfb88: [<6019ecd3>] __wait_on_bit_lock+0x42/0x78 617dfbb0: [<6004fa2a>] find_lock_page+0xb4/0x155 617dfbc8: [<6004f806>] __lock_page+0x73/0xb3 617dfbf0: [<60040585>] wake_bit_function+0x0/0x2a 617dfc38: [<6004fa3c>] find_lock_page+0xc6/0x155 617dfc48: [<600570c9>] do_page_cache_readahead+0x52/0x5f 617dfc78: [<600508ea>] filemap_fault+0x151/0x2c2 617dfce8: [<6005e9c8>] __do_fault+0x6c/0x444 617dfd68: [<6005edd1>] do_linear_fault+0x31/0x33 617dfd88: [<6005f04e>] handle_mm_fault+0x130/0x228 617dfda8: [<6011e2d7>] __up_read+0x73/0x7b 617dfde8: [<600131d4>] handle_page_fault+0x120/0x2d9 617dfe08: [<601242c8>] tty_write+0x1f7/0x212 617dfe48: [<60013513>] segv+0xac/0x286 617dff28: [<60013461>] segv_handler+0x68/0x6e 617dff48: [<600232c9>] get_skas_faultinfo+0x9c/0xa1 617dff68: [<6002386f>] userspace+0x13a/0x19d 617dffc8: [<60010d4c>] fork_handler+0x86/0x8d A new nfs_sync_page() method tells me: sleeping on page: 60ba05c0 held by: [<6004f5d1>] add_to_page_cache_lru+0xf/0x3a And a rather crude printk() and dump_stack() in add_to_page_cache_lru() match: page: 60ba05c0 Call Trace: 605eda88: [<6004f5f4>] add_to_page_cache_lru+0x32/0x3a 605edaa8: [<60056ddc>] read_cache_pages+0x4a/0x8f 605edae8: [<600f8e49>] nfs_readpages+0x116/0x164 605edb38: [<600f86bb>] nfs_pagein_one+0x0/0xd2 605edb98: [<60056e58>] read_pages+0x37/0x9b 605edbd8: [<60056fbc>] __do_page_cache_readahead+0x100/0x146 605edc48: [<600570dd>] do_page_cache_readahead+0x52/0x5f 605edc78: [<600508f4>] filemap_fault+0x145/0x2c2 605edca8: [<60022b7d>] run_syscall_stub+0xd1/0xdd 605edce8: [<6005e9dc>] __do_fault+0x6c/0x444 605edd68: [<6005ede5>] do_linear_fault+0x31/0x33 605edd88: [<6005f062>] handle_mm_fault+0x130/0x228 605edda8: [<6011e2eb>] __up_read+0x73/0x7b 605edde8: [<600131d4>] handle_page_fault+0x120/0x2d9 605ede08: [<601242dc>] tty_write+0x1f7/0x212 605ede48: [<60013513>] segv+0xac/0x286 605edf28: [<60013461>] segv_handler+0x68/0x6e 605edf48: [<600232c9>] get_skas_faultinfo+0x9c/0xa1 605edf68: [<6002386f>] userspace+0x13a/0x19d 605edfc8: [<60010d4c>] fork_handler+0x86/0x8d /me wonders, missing RPC request or locking mistake... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] 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] VFS: new fgetattr() file operation
> > But it's has various dawbacks, like rmdir doesn't work if there are > > open files within an otherwise empty directory. > > > > I'd happily accept suggestions on how to deal with this differenty. > > NFS has that problem because it really has to sillyrename into the same > directory. I don't see that ssh/sftp needs to do that. Instead it can > sillyrename anywhere in the filesystem. I don't think it can. How can we find in a reliable way another directory, which is writable by the user? Miklos - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.23-rc4-mm1 and -rc6-mm1: boot failure on HP nx6325, related to clockevents
On Monday, 24 September 2007 15:05, Thomas Gleixner wrote: > On Mon, 2007-09-24 at 14:57 +0200, Rafael J. Wysocki wrote: > > > > http://tglx.de/projects/hrtimers/2.6.23-rc4/patch-2.6.23-rc4-hrt1.patches.tar.bz2 > > > > > > > > applied. I also have the 2.6.23-rc6-mm1 dmesg output ready, but > > > > there's some > > > > -mm-specific noise in it. Please let me know if you want it, though. > > > > > > Hmm: > > > > > > > Command line: root=/dev/sda3 vga=792 resume=/dev/sda1 noacpitimer > > > > apic=verbose 2 > > > ^^^ > > > > > > noacpitimer is not a valid commandline option. > > > > > > I asked for: > > > >> > > noapictimer > > > > I'm blind, sorry. > > > > > So I really wonder, why noacpitimer on the kernel command line makes any > > > difference. I'm confused. > > > > \metoo > > > > Well, it was probably read as "noacpi". :-) > > Hmm, ACPI is in the log all over the place. Well, "noacpi" seems to be a synonym for "pci=noacpi". Anyway, it causes acpi_disable_pci() to be executed, which according to Documentation/kernel-parameters.txt means "Do not use ACPI for IRQ routing or for PCI scanning" (it works like this on x86_64 too, although the doc says it's x86_32-specific). And yes, it matches "noacpiwhatever" in the command line with "noacpi". Sigh. > > Fortunately, noapictimer helps as well, dmesg attached (I have the one > > from 2.6.23-rc6-mm1 ready, too). > > Ok, at which point is the box stopping, when you omit noa* ? Is > earlyprintk giving you any useful info ? earlyprintk=vga doesn't display anything (ie. black screen) and there are no serial ports in the box. Greetings, Rafael - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] 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] VFS: new fgetattr() file operation
> But it's has various dawbacks, like rmdir doesn't work if there are > open files within an otherwise empty directory. > > I'd happily accept suggestions on how to deal with this differenty. NFS has that problem because it really has to sillyrename into the same directory. I don't see that ssh/sftp needs to do that. Instead it can sillyrename anywhere in the filesystem. Alan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] 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] VFS: new fgetattr() file operation
> On Mon, Sep 24, 2007 at 03:18:10PM +0200, Miklos Szeredi wrote: > > > Or not support such a broken protocol at all. > > > > Wonder what people would say if we removed support for NFSv[23]. > > > > Just because a protocol does not support "perfect" UNIX semantics, it > > doesn't mean it's broken. By that standard almost all network > > filesystem protocols are severely broken. > > Well, they are broken by these and other standards. At least nfs and > cifs maintainers do the workarounds for this brokeness where they belong. And my patch is not working around a problem, rather solving a problem in a correct way. Let me summarise it: There are valid reasons we have fstat() in addition to stat/lstat. For example we want to protect agains races involving unlink/rename on an open file. Say I want to implement a network filesystem with a pure unprivileged userspace sever (this is basically what sshfs does). I want my filesystem client implementation to keep all these advantages of fstat(). So how can I do that? There's a simple way: implement this operation with fstat() on the server. I get all the advantages on the remote system automatically. But for that the filesystem needs to have the open file that the fstat() on the client was performed on. It's that simple. There's really no ugly hacks going on behind the scenes. It's just that we do want to delegate some properties of this operation onto the server, and the simplest and best implementation is to just let the filesystem have the information it needs. Why is that such a big problem? Miklos - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 14/22] NFS: Use local caching
David Howells wrote: David Howells <[EMAIL PROTECTED]> wrote: Peter Staubach <[EMAIL PROTECTED]> wrote: Did I miss the section where the modified semantics about which mounted file systems can use the cache and which ones can not was implemented? Yes. fs/nfs/super.c: case Opt_sharecache: mnt->flags &= ~NFS_MOUNT_UNSHARED; break; case Opt_nosharecache: mnt->flags |= NFS_MOUNT_UNSHARED; mnt->options &= ~NFS_OPTION_FSCACHE; break; case Opt_fscache: /* sharing is mandatory with fscache */ mnt->options |= NFS_OPTION_FSCACHE; mnt->flags &= ~NFS_MOUNT_UNSHARED; break; case Opt_nofscache: mnt->options &= ~NFS_OPTION_FSCACHE; break; Hmmm... Actually, I'm not sure this is sufficient. This doesn't seem to take into account any of the other options which can cause sharing to be disabled. Perhaps SteveD can add his patch to the mix which does resolve the issues? Thanx... ps - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.23-rc7-mm1
Cedric Le Goater wrote: > putting Vlad in Cc: > > Cedric Le Goater wrote: >> Andrew Morton wrote: >>> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23-rc7/2.6.23-rc7-mm1/ >> I also get this compile error on s390. 'linux/scatterlist.h' has disappeared >> from the #include pile but where ? >> >> /home/clg/linux/2.6.23-rc7-mm1/net/sctp/auth.c: In function >> `sctp_auth_calculate_hmac': >> /home/clg/linux/2.6.23-rc7-mm1/net/sctp/auth.c:695: error: storage size of >> 'sg' isn't known >> /home/clg/linux/2.6.23-rc7-mm1/net/sctp/auth.c:695: warning: unused variable >> `sg' > > The following patch works of course but it seems to simplistic for s390. Odd that it didn't show up on x86 or ia64, but simple enough. ACK. -vlad > > Cheers, > > C. > > > Signed-off-by: Cedric Le Goater <[EMAIL PROTECTED]> > --- > net/sctp/auth.c |1 + > 1 file changed, 1 insertion(+) > > Index: 2.6.23-rc7-mm1/net/sctp/auth.c > === > --- 2.6.23-rc7-mm1.orig/net/sctp/auth.c > +++ 2.6.23-rc7-mm1/net/sctp/auth.c > @@ -36,6 +36,7 @@ > > #include > #include > +#include > #include > #include > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] 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] VFS: new fgetattr() file operation
On Mon, Sep 24, 2007 at 03:18:10PM +0200, Miklos Szeredi wrote: > > Or not support such a broken protocol at all. > > Wonder what people would say if we removed support for NFSv[23]. > > Just because a protocol does not support "perfect" UNIX semantics, it > doesn't mean it's broken. By that standard almost all network > filesystem protocols are severely broken. Well, they are broken by these and other standards. At least nfs and cifs maintainers do the workarounds for this brokeness where they belong. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: USB autosuspend and turning of usb pendrive leds
Am Montag 24 September 2007 schrieb Hans de Goede: > Oliver Neukum wrote: > > Am Freitag 21 September 2007 schrieb Jiri Kosina: > >> On Fri, 21 Sep 2007, Hans de Goede wrote: > >> > >>> Thats not what I had in mind, autosuspend doesn't work (presumably > >>> because hal keeps polling for media change) maybe I should fix hal to > >>> not keep polling for devices which don't have removable media? > >> Hi Hans, > >> > >> I think the correct solution is that HAL stops polling the device as soon > >> as it sees that it got autosuspended. > > > > And how would we notice a medium change then? If there's an alternative > > way to notice it or we know it cannot happen there's no reason to poll at > > all. > > > > It looks like hal is currently polling device of which it knows the medium is > not removable, like USB-pens. It doesn't, which is the point. The overwhelming number of USB devices don't bother to correctly declare themselves not removable SCSI devices. The discrimination will have to happen on a product:vendor basis, which means that a large database has to be built and maintained. Regards Oliver - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] 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] VFS: new fgetattr() file operation
> On Mon, Sep 24, 2007 at 03:06:06PM +0200, Miklos Szeredi wrote: > > A file isn't deleted while there are still links or open files > > refering to it. So getting the attributes for a file with nlink==0 is > > perfectly valid while the file is still open. > > Is it? Why not just pretend that the attributes are wiped when the file > is deleted. You mean "when finally unlinked"? Delete happens when the file is closed. > Effectively, they are, since they can't affect anything. Sure it can. It may be open on the server as well. > > If a network filesystem protocol can't handle operations (be it data > > or metadata) on an unlinked file, we must do sillirenaming, so that > > the file is not actually unlinked. > > Or you could call getattr right before you unlink and cache the result > in the client. The file can still be modified after being unlinked. And even if we did this caching thing and modify the attributes when the file is modified, it would not deal with access on the remote end, and would be much more complex than the other alternatives. Miklos - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.23-rc7-mm1
Pavel Emelyanov wrote: > Please, try with this patch too: > > diff --git a/fs/locks.c b/fs/locks.c > index c0fe71a..f599508 100644 > --- a/fs/locks.c > +++ b/fs/locks.c > @@ -1423,7 +1423,7 @@ int generic_setlease(struct file *filp, > locks_copy_lock(new_fl, lease); > locks_insert_lock(before, new_fl); > > - *flp = fl; > + *flp = new_fl; > return 0; > > out: > Hi, Pavel, You did not signoff on the patch. -- Warm Regards, Balbir Singh Linux Technology Center IBM, ISTL - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] 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] VFS: new fgetattr() file operation
> > If a network filesystem protocol can't handle operations (be it data > > or metadata) on an unlinked file, we must do sillirenaming, so that > > the file is not actually unlinked. > > Or not support such a broken protocol at all. Wonder what people would say if we removed support for NFSv[23]. Just because a protocol does not support "perfect" UNIX semantics, it doesn't mean it's broken. By that standard almost all network filesystem protocols are severely broken. Miklos - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Uninline kcalloc()
On Mon, 24 Sep 2007 08:59:56 EDT, Kyle Moffett said: > Proper fix is to give __kmalloc a "void *caller" parameter and have > all of the various wrapper functions pass in the value of > __builtin_return_address() appropriately. I believe that even works > properly for inline functions which may or may not be inlined. I think I looked at that, and it wasn't as easy as it looked, because there were ugly corner cases for what __builtin_return_address() returned depending on exactly what did or didn't get inlined. Basically, it's ugly stuff - if you try to use __builtin_retur_address inside kcalloc to pass to __kmalloc, and then kcalloc gets inlined, you end up passing not the routine you wanted (the caller of kcalloc), but the *parent* of that... pgpmjWivJ5Hji.pgp Description: PGP signature
[PATCH rc7-mm1] fix BUG at mm/swap.c:405!
a.k.a. mm-use-pagevec-to-rotate-reclaimable-page-fix-2.patch
rotate_reclaimable_page() is not necessarily called with IRQ disabled:
it must do so when calling the helpfully commented pagevec_move_tail().
Hmm, if pagevec_move_tail() is assuming IRQ disabled, why should it
bother with irqsave/irqrestore variants of spin_lock? Because we like
to see them on lru_lock? But vmscan.c already has one bare spin_lock().
Signed-off-by: Hugh Dickins <[EMAIL PROTECTED]>
---
mm/swap.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
--- 2.6.23-rc7-mm1/mm/swap.c2007-09-24 11:05:55.0 +0100
+++ linux/mm/swap.c 2007-09-24 13:08:12.0 +0100
@@ -102,7 +102,6 @@ static void pagevec_move_tail(struct pag
int i;
int pgmoved = 0;
struct zone *zone = NULL;
- unsigned long uninitialized_var(flags);
for (i = 0; i < pagevec_count(pvec); i++) {
struct page *page = pvec->pages[i];
@@ -110,9 +109,9 @@ static void pagevec_move_tail(struct pag
if (pagezone != zone) {
if (zone)
- spin_unlock_irqrestore(>lru_lock, flags);
+ spin_unlock(>lru_lock);
zone = pagezone;
- spin_lock_irqsave(>lru_lock, flags);
+ spin_lock(>lru_lock);
}
if (PageLRU(page) && !PageActive(page)) {
list_move_tail(>lru, >inactive_list);
@@ -120,7 +119,7 @@ static void pagevec_move_tail(struct pag
}
}
if (zone)
- spin_unlock_irqrestore(>lru_lock, flags);
+ spin_unlock(>lru_lock);
__count_vm_events(PGROTATED, pgmoved);
release_pages(pvec->pages, pvec->nr, pvec->cold);
pagevec_reinit(pvec);
@@ -150,6 +149,7 @@ void move_tail_pages()
int rotate_reclaimable_page(struct page *page)
{
struct pagevec *pvec;
+ unsigned long flags;
if (PageLocked(page))
return 1;
@@ -162,9 +162,11 @@ int rotate_reclaimable_page(struct page
if (PageLRU(page) && !PageActive(page)) {
page_cache_get(page);
+ local_irq_save(flags);
pvec = &__get_cpu_var(rotate_pvecs);
if (!pagevec_add(pvec, page))
pagevec_move_tail(pvec);
+ local_irq_restore(flags);
}
if (!test_clear_page_writeback(page))
BUG();
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.23-rc7-mm1
Please, try with this patch too: diff --git a/fs/locks.c b/fs/locks.c index c0fe71a..f599508 100644 --- a/fs/locks.c +++ b/fs/locks.c @@ -1423,7 +1423,7 @@ int generic_setlease(struct file *filp, locks_copy_lock(new_fl, lease); locks_insert_lock(before, new_fl); - *flp = fl; + *flp = new_fl; return 0; out: - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] 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] VFS: new fgetattr() file operation
On Mon, Sep 24, 2007 at 03:06:06PM +0200, Miklos Szeredi wrote: > A file isn't deleted while there are still links or open files > refering to it. So getting the attributes for a file with nlink==0 is > perfectly valid while the file is still open. Is it? Why not just pretend that the attributes are wiped when the file is deleted. Effectively, they are, since they can't affect anything. > If a network filesystem protocol can't handle operations (be it data > or metadata) on an unlinked file, we must do sillirenaming, so that > the file is not actually unlinked. Or you could call getattr right before you unlink and cache the result in the client. -- Intel are signing my paycheques ... these opinions are still mine "Bill, look, we understand that you're interested in selling us this operating system, but compare it to ours. We can't possibly take such a retrograde step." - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
