2006-10-10 17:15:59

by Greg KH

[permalink] [raw]
Subject: [patch 00/19] 2.6.17-stable review

This is the start of the stable review cycle for the 2.6.17.14 release.
There are 19 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 Thursday, Octover 12, 18:00:00 UTC.
Anything received after that time might be too late.

thanks,

the -stable release team


2006-10-10 17:16:36

by Greg KH

[permalink] [raw]
Subject: [patch 04/19] LOCKD: Fix a deadlock in nlm_traverse_files()

-stable review patch. If anyone has any objections, please let us know.

------------------
From: Trond Myklebust <[email protected]>

nlm_traverse_files() is not allowed to hold the nlm_file_mutex while calling
nlm_inspect file, since it may end up calling nlm_release_file() when
releaseing the blocks.

Signed-off-by: Trond Myklebust <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
fs/lockd/svcsubs.c | 15 +++++++++------
1 file changed, 9 insertions(+), 6 deletions(-)

--- linux-2.6.17.13.orig/fs/lockd/svcsubs.c
+++ linux-2.6.17.13/fs/lockd/svcsubs.c
@@ -238,19 +238,22 @@ static int
nlm_traverse_files(struct nlm_host *host, int action)
{
struct nlm_file *file, **fp;
- int i;
+ int i, ret = 0;

mutex_lock(&nlm_file_mutex);
for (i = 0; i < FILE_NRHASH; i++) {
fp = nlm_files + i;
while ((file = *fp) != NULL) {
+ file->f_count++;
+ mutex_unlock(&nlm_file_mutex);
+
/* Traverse locks, blocks and shares of this file
* and update file->f_locks count */
- if (nlm_inspect_file(host, file, action)) {
- mutex_unlock(&nlm_file_mutex);
- return 1;
- }
+ if (nlm_inspect_file(host, file, action))
+ ret = 1;

+ mutex_lock(&nlm_file_mutex);
+ file->f_count--;
/* No more references to this file. Let go of it. */
if (!file->f_blocks && !file->f_locks
&& !file->f_shares && !file->f_count) {
@@ -263,7 +266,7 @@ nlm_traverse_files(struct nlm_host *host
}
}
mutex_unlock(&nlm_file_mutex);
- return 0;
+ return ret;
}

/*

--

2006-10-10 17:15:33

by Greg KH

[permalink] [raw]
Subject: [patch 08/19] ext3 sequential read regression fix

-stable review patch. If anyone has any objections, please let us know.

------------------
From: Badari Pulavarty <[email protected]>

ext3-get-blocks support caused ~20% degrade in Sequential read
performance (tiobench). Problem is with marking the buffer boundary
so IO can be submitted right away. Here is the patch to fix it.

2.6.18-rc6:
-----------
# ./iotest
1048576+0 records in
1048576+0 records out
4294967296 bytes (4.3 GB) copied, 75.2726 seconds, 57.1 MB/s

real 1m15.285s
user 0m0.276s
sys 0m3.884s


2.6.18-rc6 + fix:
-----------------
[root@elm3a241 ~]# ./iotest
1048576+0 records in
1048576+0 records out
4294967296 bytes (4.3 GB) copied, 62.9356 seconds, 68.2 MB/s


The boundary block check in ext3_get_blocks_handle needs to be adjusted
against the count of blocks mapped in this call, now that it can map
more than one block.

Signed-off-by: Suparna Bhattacharya <[email protected]>
Tested-by: Badari Pulavarty <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>


---
fs/ext3/inode.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- linux-2.6.17.13.orig/fs/ext3/inode.c
+++ linux-2.6.17.13/fs/ext3/inode.c
@@ -926,7 +926,7 @@ int ext3_get_blocks_handle(handle_t *han
set_buffer_new(bh_result);
got_it:
map_bh(bh_result, inode->i_sb, le32_to_cpu(chain[depth-1].key));
- if (blocks_to_boundary == 0)
+ if (count > blocks_to_boundary)
set_buffer_boundary(bh_result);
err = count;
/* Clean up and exit */

--

2006-10-10 17:15:58

by Greg KH

[permalink] [raw]
Subject: [patch 07/19] invalidate_complete_page() race fix

-stable review patch. If anyone has any objections, please let us know.

------------------
From: Andrew Morton <[email protected]>

If a CPU faults this page into pagetables after invalidate_mapping_pages()
checked page_mapped(), invalidate_complete_page() will still proceed to remove
the page from pagecache. This leaves the page-faulting process with a
detached page. If it was MAP_SHARED then file data loss will ensue.

Fix that up by checking the page's refcount after taking tree_lock.

Cc: Nick Piggin <[email protected]>
Cc: Hugh Dickins <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
mm/truncate.c | 11 +++++++----
1 file changed, 7 insertions(+), 4 deletions(-)

--- linux-2.6.17.13.orig/mm/truncate.c
+++ linux-2.6.17.13/mm/truncate.c
@@ -68,10 +68,10 @@ invalidate_complete_page(struct address_
return 0;

write_lock_irq(&mapping->tree_lock);
- if (PageDirty(page)) {
- write_unlock_irq(&mapping->tree_lock);
- return 0;
- }
+ if (PageDirty(page))
+ goto failed;
+ if (page_count(page) != 2) /* caller's ref + pagecache ref */
+ goto failed;

BUG_ON(PagePrivate(page));
__remove_from_page_cache(page);
@@ -79,6 +79,9 @@ invalidate_complete_page(struct address_
ClearPageUptodate(page);
page_cache_release(page); /* pagecache ref */
return 1;
+failed:
+ write_unlock_irq(&mapping->tree_lock);
+ return 0;
}

/**

--

2006-10-10 17:15:59

by Greg KH

[permalink] [raw]
Subject: [patch 09/19] sysfs: remove duplicated dput in sysfs_update_file

-stable review patch. If anyone has any objections, please let us know.

------------------
From: Hidetoshi Seto <[email protected]>

Following function can drops d_count twice against one reference
by lookup_one_len.

<SOURCE>
/**
* sysfs_update_file - update the modified timestamp on an object attribute.
* @kobj: object we're acting for.
* @attr: attribute descriptor.
*/
int sysfs_update_file(struct kobject * kobj, const struct attribute * attr)
{
struct dentry * dir = kobj->dentry;
struct dentry * victim;
int res = -ENOENT;

mutex_lock(&dir->d_inode->i_mutex);
victim = lookup_one_len(attr->name, dir, strlen(attr->name));
if (!IS_ERR(victim)) {
/* make sure dentry is really there */
if (victim->d_inode &&
(victim->d_parent->d_inode == dir->d_inode)) {
victim->d_inode->i_mtime = CURRENT_TIME;
fsnotify_modify(victim);

/**
* Drop reference from initial sysfs_get_dentry().
*/
dput(victim);
res = 0;
} else
d_drop(victim);

/**
* Drop the reference acquired from sysfs_get_dentry() above.
*/
dput(victim);
}
mutex_unlock(&dir->d_inode->i_mutex);

return res;
}
</SOURCE>

PCI-hotplug (drivers/pci/hotplug/pci_hotplug_core.c) is only user of
this function. I confirmed that dentry of /sys/bus/pci/slots/XXX/*
have negative d_count value.

This patch removes unnecessary dput().

Signed-off-by: Hidetoshi Seto <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
fs/sysfs/file.c | 5 -----
1 file changed, 5 deletions(-)

--- linux-2.6.17.13.orig/fs/sysfs/file.c
+++ linux-2.6.17.13/fs/sysfs/file.c
@@ -483,11 +483,6 @@ int sysfs_update_file(struct kobject * k
(victim->d_parent->d_inode == dir->d_inode)) {
victim->d_inode->i_mtime = CURRENT_TIME;
fsnotify_modify(victim);
-
- /**
- * Drop reference from initial sysfs_get_dentry().
- */
- dput(victim);
res = 0;
} else
d_drop(victim);

--

2006-10-10 17:15:35

by Greg KH

[permalink] [raw]
Subject: [patch 01/19] dvb-core: Proper handling ULE SNDU length of 0 (CVE-2006-4623)

-stable review patch. If anyone has any objections, please let us know.

------------------
From: Ang Way Chuang <[email protected]>

ULE (Unidirectional Lightweight Encapsulation RFC 4326) decapsulation
code has a bug that allows an attacker to send a malformed ULE packet
with SNDU length of 0 and bring down the receiving machine. This patch
fix the bug and has been tested on version 2.6.17.11. This bug is 100%
reproducible and the modified source code (GPL) used to produce this bug
will be posted on http://nrg.cs.usm.my/downloads.htm shortly. The
kernel will produce a dump during CRC32 checking on faulty ULE packet.


Signed-off-by: Ang Way Chuang <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/media/dvb/dvb-core/dvb_net.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)

--- linux-2.6.17.13.orig/drivers/media/dvb/dvb-core/dvb_net.c
+++ linux-2.6.17.13/drivers/media/dvb/dvb-core/dvb_net.c
@@ -492,7 +492,8 @@ static void dvb_net_ule( struct net_devi
} else
priv->ule_dbit = 0;

- if (priv->ule_sndu_len > 32763) {
+ if (priv->ule_sndu_len > 32763 ||
+ priv->ule_sndu_len < ((priv->ule_dbit) ? 4 : 4 + ETH_ALEN)) {
printk(KERN_WARNING "%lu: Invalid ULE SNDU length %u. "
"Resyncing.\n", priv->ts_count, priv->ule_sndu_len);
priv->ule_sndu_len = 0;

--

2006-10-10 17:16:36

by Greg KH

[permalink] [raw]
Subject: [patch 05/19] NFS: More page cache revalidation fixups

-stable review patch. If anyone has any objections, please let us know.

------------------
From: Trond Myklebust <[email protected]>

Whenever the directory changes, we want to make sure that we always
invalidate its page cache. Fix up update_changeattr() and
nfs_mark_for_revalidate() so that they do so.

Signed-off-by: Trond Myklebust <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
fs/nfs/nfs4proc.c | 10 +++++-----
include/linux/nfs_fs.h | 6 +++++-
2 files changed, 10 insertions(+), 6 deletions(-)

--- linux-2.6.17.13.orig/fs/nfs/nfs4proc.c
+++ linux-2.6.17.13/fs/nfs/nfs4proc.c
@@ -185,15 +185,15 @@ static void renew_lease(const struct nfs
spin_unlock(&clp->cl_lock);
}

-static void update_changeattr(struct inode *inode, struct nfs4_change_info *cinfo)
+static void update_changeattr(struct inode *dir, struct nfs4_change_info *cinfo)
{
- struct nfs_inode *nfsi = NFS_I(inode);
+ struct nfs_inode *nfsi = NFS_I(dir);

- spin_lock(&inode->i_lock);
- nfsi->cache_validity |= NFS_INO_INVALID_ATTR;
+ spin_lock(&dir->i_lock);
+ nfsi->cache_validity |= NFS_INO_INVALID_ATTR|NFS_INO_REVAL_PAGECACHE|NFS_INO_INVALID_DATA;
if (cinfo->before == nfsi->change_attr && cinfo->atomic)
nfsi->change_attr = cinfo->after;
- spin_unlock(&inode->i_lock);
+ spin_unlock(&dir->i_lock);
}

struct nfs4_opendata {
--- linux-2.6.17.13.orig/include/linux/nfs_fs.h
+++ linux-2.6.17.13/include/linux/nfs_fs.h
@@ -234,8 +234,12 @@ static inline int nfs_caches_unstable(st

static inline void nfs_mark_for_revalidate(struct inode *inode)
{
+ struct nfs_inode *nfsi = NFS_I(inode);
+
spin_lock(&inode->i_lock);
- NFS_I(inode)->cache_validity |= NFS_INO_INVALID_ATTR | NFS_INO_INVALID_ACCESS;
+ nfsi->cache_validity |= NFS_INO_INVALID_ATTR|NFS_INO_INVALID_ACCESS;
+ if (S_ISDIR(inode->i_mode))
+ nfsi->cache_validity |= NFS_INO_REVAL_PAGECACHE|NFS_INO_INVALID_DATA;
spin_unlock(&inode->i_lock);
}


--

2006-10-10 17:17:47

by Greg KH

[permalink] [raw]
Subject: [patch 19/19] Input: logips2pp - fix button mapping for MX300

-stable review patch. If anyone has any objections, please let us know.

------------------
From: Roberto Castagnola <[email protected]>

MX300 does not have an EXTRA_BTN - it is a simple wheel mouse with
an additional task-switcher button, which is reported as side button
(and not task button).

Signed-off-by: Daniel Drake <[email protected]>
Signed-off-by: Dmitry Torokhov <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/input/mouse/logips2pp.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)

--- linux-2.6.17.13.orig/drivers/input/mouse/logips2pp.c
+++ linux-2.6.17.13/drivers/input/mouse/logips2pp.c
@@ -238,8 +238,7 @@ static struct ps2pp_info *get_model_info
{ 100, PS2PP_KIND_MX, /* MX510 */
PS2PP_WHEEL | PS2PP_SIDE_BTN | PS2PP_TASK_BTN |
PS2PP_EXTRA_BTN | PS2PP_NAV_BTN },
- { 111, PS2PP_KIND_MX, /* MX300 */
- PS2PP_WHEEL | PS2PP_EXTRA_BTN | PS2PP_TASK_BTN },
+ { 111, PS2PP_KIND_MX, PS2PP_WHEEL | PS2PP_SIDE_BTN }, /* MX300 reports task button as side */
{ 112, PS2PP_KIND_MX, /* MX500 */
PS2PP_WHEEL | PS2PP_SIDE_BTN | PS2PP_TASK_BTN |
PS2PP_EXTRA_BTN | PS2PP_NAV_BTN },

--

2006-10-10 17:18:17

by Greg KH

[permalink] [raw]
Subject: [patch 17/19] MMC: Always use a sector size of 512 bytes

-stable review patch. If anyone has any objections, please let us know.

------------------
From: Pierre Ossman <[email protected]>

Both MMC and SD specifications specify (although a bit unclearly in the MMC
case) that a sector size of 512 bytes must always be supported by the card.

Cards can report larger "native" size than this, and cards >= 2 GB even
must do so. Most other readers use 512 bytes even for these cards. We should
do the same to be compatible.

Signed-off-by: Pierre Ossman <[email protected]>
Cc: Daniel Drake <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/mmc/mmc_block.c | 49 +++---------------------------------------------
1 file changed, 4 insertions(+), 45 deletions(-)

--- linux-2.6.17.13.orig/drivers/mmc/mmc_block.c
+++ linux-2.6.17.13/drivers/mmc/mmc_block.c
@@ -325,52 +325,11 @@ static struct mmc_blk_data *mmc_blk_allo
md->read_only = mmc_blk_readonly(card);

/*
- * Figure out a workable block size. MMC cards have:
- * - two block sizes, one for read and one for write.
- * - may support partial reads and/or writes
- * (allows block sizes smaller than specified)
+ * Both SD and MMC specifications state (although a bit
+ * unclearly in the MMC case) that a block size of 512
+ * bytes must always be supported by the card.
*/
- md->block_bits = card->csd.read_blkbits;
- if (card->csd.write_blkbits != card->csd.read_blkbits) {
- if (card->csd.write_blkbits < card->csd.read_blkbits &&
- card->csd.read_partial) {
- /*
- * write block size is smaller than read block
- * size, but we support partial reads, so choose
- * the smaller write block size.
- */
- md->block_bits = card->csd.write_blkbits;
- } else if (card->csd.write_blkbits > card->csd.read_blkbits &&
- card->csd.write_partial) {
- /*
- * read block size is smaller than write block
- * size, but we support partial writes. Use read
- * block size.
- */
- } else {
- /*
- * We don't support this configuration for writes.
- */
- printk(KERN_ERR "%s: unable to select block size for "
- "writing (rb%u wb%u rp%u wp%u)\n",
- mmc_card_id(card),
- 1 << card->csd.read_blkbits,
- 1 << card->csd.write_blkbits,
- card->csd.read_partial,
- card->csd.write_partial);
- md->read_only = 1;
- }
- }
-
- /*
- * Refuse to allow block sizes smaller than 512 bytes.
- */
- if (md->block_bits < 9) {
- printk(KERN_ERR "%s: unable to support block size %u\n",
- mmc_card_id(card), 1 << md->block_bits);
- ret = -EINVAL;
- goto err_kfree;
- }
+ md->block_bits = 9;

md->disk = alloc_disk(1 << MMC_SHIFT);
if (md->disk == NULL) {

--

2006-10-10 17:17:04

by Greg KH

[permalink] [raw]
Subject: [patch 02/19] NFS: Fix a potential deadlock in nfs_release_page

-stable review patch. If anyone has any objections, please let us know.

------------------
From: Nikita Danilov <[email protected]>

nfs_wb_page() waits on request completion and, as a result, is not safe to be
called from nfs_release_page() invoked by VM scanner as part of GFP_NOFS
allocation. Fix possible deadlock by analyzing gfp mask and refusing to
release page if __GFP_FS is not set.

Signed-off-by: Nikita Danilov <[email protected]>
Signed-off-by: Trond Myklebust <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
fs/nfs/file.c | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)

--- linux-2.6.17.13.orig/fs/nfs/file.c
+++ linux-2.6.17.13/fs/nfs/file.c
@@ -325,7 +325,13 @@ static void nfs_invalidate_page(struct p

static int nfs_release_page(struct page *page, gfp_t gfp)
{
- return !nfs_wb_page(page->mapping->host, page);
+ if (gfp & __GFP_FS)
+ return !nfs_wb_page(page->mapping->host, page);
+ else
+ /*
+ * Avoid deadlock on nfs_wait_on_request().
+ */
+ return 0;
}

struct address_space_operations nfs_file_aops = {

--

2006-10-10 17:17:13

by Greg KH

[permalink] [raw]
Subject: [patch 15/19] xirc2ps_cs: Cannot reset card in atomic context

-stable review patch. If anyone has any objections, please let us know.

------------------
From: Joerg Ahrens <[email protected]>

I am using a Xircom CEM33 pcmcia NIC which has occasional hardware problems.
If the netdev watchdog detects a transmit timeout, do_reset is called which
msleeps - this is illegal in atomic context.

This patch schedules the timeout handling as a workqueue item.

Signed-off-by: Daniel Drake <[email protected]>
Signed-off-by: Jeff Garzik <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/net/pcmcia/xirc2ps_cs.c | 18 ++++++++++++++----
1 file changed, 14 insertions(+), 4 deletions(-)

--- linux-2.6.17.13.orig/drivers/net/pcmcia/xirc2ps_cs.c
+++ linux-2.6.17.13/drivers/net/pcmcia/xirc2ps_cs.c
@@ -345,6 +345,7 @@ typedef struct local_info_t {
void __iomem *dingo_ccr; /* only used for CEM56 cards */
unsigned last_ptr_value; /* last packets transmitted value */
const char *manf_str;
+ struct work_struct tx_timeout_task;
} local_info_t;

/****************
@@ -352,6 +353,7 @@ typedef struct local_info_t {
*/
static int do_start_xmit(struct sk_buff *skb, struct net_device *dev);
static void do_tx_timeout(struct net_device *dev);
+static void xirc2ps_tx_timeout_task(void *data);
static struct net_device_stats *do_get_stats(struct net_device *dev);
static void set_addresses(struct net_device *dev);
static void set_multicast_list(struct net_device *dev);
@@ -589,6 +591,7 @@ xirc2ps_probe(struct pcmcia_device *link
#ifdef HAVE_TX_TIMEOUT
dev->tx_timeout = do_tx_timeout;
dev->watchdog_timeo = TX_TIMEOUT;
+ INIT_WORK(&local->tx_timeout_task, xirc2ps_tx_timeout_task, dev);
#endif

return xirc2ps_config(link);
@@ -1341,17 +1344,24 @@ xirc2ps_interrupt(int irq, void *dev_id,
/*====================================================================*/

static void
-do_tx_timeout(struct net_device *dev)
+xirc2ps_tx_timeout_task(void *data)
{
- local_info_t *lp = netdev_priv(dev);
- printk(KERN_NOTICE "%s: transmit timed out\n", dev->name);
- lp->stats.tx_errors++;
+ struct net_device *dev = data;
/* reset the card */
do_reset(dev,1);
dev->trans_start = jiffies;
netif_wake_queue(dev);
}

+static void
+do_tx_timeout(struct net_device *dev)
+{
+ local_info_t *lp = netdev_priv(dev);
+ lp->stats.tx_errors++;
+ printk(KERN_NOTICE "%s: transmit timed out\n", dev->name);
+ schedule_work(&lp->tx_timeout_task);
+}
+
static int
do_start_xmit(struct sk_buff *skb, struct net_device *dev)
{

--

2006-10-10 17:18:54

by Greg KH

[permalink] [raw]
Subject: [patch 18/19] ahci: do not fail softreset if PHY reports no device

-stable review patch. If anyone has any objections, please let us know.

------------------
From: Tejun Heo <[email protected]>

All softreset methods are responsible for detecting device presence
and succeed softreset in such cases. AHCI didn't use to check for
device presence before proceeding with softreset and this caused
unnecessary reset retrials during probing. This patch adds presence
detection to AHCI softreset.

Signed-off-by: Tejun Heo <[email protected]>
Signed-off-by: Jeff Garzik <[email protected]>
Cc: Daniel Drake <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/scsi/ahci.c | 6 ++++++
1 file changed, 6 insertions(+)

--- linux-2.6.17.13.orig/drivers/scsi/ahci.c
+++ linux-2.6.17.13/drivers/scsi/ahci.c
@@ -548,6 +548,12 @@ static int ahci_softreset(struct ata_por

DPRINTK("ENTER\n");

+ if (!sata_dev_present(ap)) {
+ DPRINTK("PHY reports no device\n");
+ *class = ATA_DEV_NONE;
+ return 0;
+ }
+
/* prepare for SRST (AHCI-1.1 10.4.1) */
rc = ahci_stop_engine(ap);
if (rc) {

--

2006-10-10 17:17:48

by Greg KH

[permalink] [raw]
Subject: [patch 16/19] Add PIIX4 APCI quirk for the 440MX chipset too

-stable review patch. If anyone has any objections, please let us know.

------------------
From: Linus Torvalds <[email protected]>

This is confirmed to fix a hang due to PCI resource conflicts with
setting up the Cardbus bridge on old laptops with the 440MX chipsets.
Original report by Alessio Sangalli, lspci debugging help by Pekka
Enberg, and trial patch suggested by Daniel Ritz:

"From the docs available i would _guess_ this thing is really similar
to the 82443BX/82371AB combination. at least the SMBus base address
register is hidden at the very same place (32bit at 0x90 in function
3 of the "south" brigde)"

The dang thing is largely undocumented, but the patch was corroborated
by Asit Mallick:

"I am trying to find the register information. 440MX is an integration of
440BX north-bridge without AGP and PIIX4E (82371EB). PIIX4 quirk
should cover the ACPI and SMBus related I/O registers."

and verified to fix the problem by Alessio.

Cc: Daniel Ritz <[email protected]>
Cc: Asit Mallick <[email protected]>
Cc: Pekka Enberg <[email protected]>
Cc: Ivan Kokshaysky <[email protected]>
Cc: Dmitry Torokhov <[email protected]>
Tested-by: Alessio Sangalli <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/pci/quirks.c | 1 +
1 file changed, 1 insertion(+)

--- linux-2.6.17.13.orig/drivers/pci/quirks.c
+++ linux-2.6.17.13/drivers/pci/quirks.c
@@ -390,6 +390,7 @@ static void __devinit quirk_piix4_acpi(s
piix4_io_quirk(dev, "PIIX4 devres J", 0x7c, 1 << 20);
}
DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82371AB_3, quirk_piix4_acpi );
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82443MX_3, quirk_piix4_acpi );

/*
* ICH4, ICH4-M, ICH5, ICH5-M ACPI: Three IO regions pointed to by longwords at

--

2006-10-10 17:17:44

by Greg KH

[permalink] [raw]
Subject: [patch 13/19] Fix sparc64 ramdisk handling

-stable review patch. If anyone has any objections, please let us know.

------------------
From: David S. Miller <[email protected]>

[SPARC64]: Kill bogus check from bootmem_init().

There is an ancient and totally incorrect sanity check being
done on the ramdisk location. The check assumes that the
kernel is always loaded to physical address zero, which is
wrong. It was trying to validate the ramdisk value by saying that
if it fell within the kernel image address range it must be wrong.

Anyways, kill this because it actually creates problems. The
'ramdisk_image' should always be adjusted down by KERNBASE.
SILO can easily put the ramdisk in a location which causes
this test to trigger, breaking things.

[ Based almost entirely upon a patch from Ben Collins. ]

Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
arch/sparc64/mm/init.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)

--- linux-2.6.17.13.orig/arch/sparc64/mm/init.c
+++ linux-2.6.17.13/arch/sparc64/mm/init.c
@@ -902,8 +902,7 @@ static unsigned long __init bootmem_init
if (sparc_ramdisk_image || sparc_ramdisk_image64) {
unsigned long ramdisk_image = sparc_ramdisk_image ?
sparc_ramdisk_image : sparc_ramdisk_image64;
- if (ramdisk_image >= (unsigned long)_end - 2 * PAGE_SIZE)
- ramdisk_image -= KERNBASE;
+ ramdisk_image -= KERNBASE;
initrd_start = ramdisk_image + phys_base;
initrd_end = initrd_start + sparc_ramdisk_size;
if (initrd_end > end_of_phys_memory) {

--

2006-10-10 17:17:47

by Greg KH

[permalink] [raw]
Subject: [patch 12/19] SPARC64: Fix serious bug in sched_clock() on sparc64

-stable review patch. If anyone has any objections, please let us know.

------------------
From: David S. Miller <[email protected]>

[SPARC64]: Fix sched_clock() wrapping every ~17 seconds.

Unfortunately, sparc64 doesn't have an easy way to do a "64 X 64 -->
128" bit multiply like PowerPC and IA64 do. We were doing a
"64 X 64 --> 64" bit multiple which causes overflow very quickly with
a 30-bit quotient shift.

So use a quotientshift count of 10 instead of 30, just like x86 and
ARM do.

This also fixes the wrapping of printk timestamp values every ~17
seconds.

Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
arch/sparc64/kernel/time.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- linux-2.6.17.13.orig/arch/sparc64/kernel/time.c
+++ linux-2.6.17.13/arch/sparc64/kernel/time.c
@@ -1105,7 +1105,7 @@ static struct time_interpolator sparc64_
};

/* The quotient formula is taken from the IA64 port. */
-#define SPARC64_NSEC_PER_CYC_SHIFT 30UL
+#define SPARC64_NSEC_PER_CYC_SHIFT 10UL
void __init time_init(void)
{
unsigned long clock = sparc64_init_timers();

--

2006-10-10 17:19:28

by Greg KH

[permalink] [raw]
Subject: [patch 06/19] Backport: Old IDE, fix SATA detection for cabling

-stable review patch. If anyone has any objections, please let us know.

------------------

From: Michael-Luke Jones <[email protected]>

This patch is identical to that introduced in
1a1276e7b6cba549553285f74e87f702bfff6fac to the Linus' 2.6 development tree
by Alan Cox.

'This is based on the proposed patches flying around but also checks that
the device in question is new enough to have word 93 rather thanb blindly
assuming word 93 == 0 means SATA (see ATA-5, ATA-7)' -- Alan Cox

Required for my SATA drive on an Asus Pundit-R to operate above 33MBps.

Signed-off-by: Michael-Luke Jones <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/ide/ide-iops.c | 4 ++++
1 file changed, 4 insertions(+)

--- linux-2.6.17.13.orig/drivers/ide/ide-iops.c
+++ linux-2.6.17.13/drivers/ide/ide-iops.c
@@ -597,6 +597,10 @@ u8 eighty_ninty_three (ide_drive_t *driv
{
if(HWIF(drive)->udma_four == 0)
return 0;
+
+ /* Check for SATA but only if we are ATA5 or higher */
+ if (drive->id->hw_config == 0 && (drive->id->major_rev_num & 0x7FE0))
+ return 1;
if (!(drive->id->hw_config & 0x6000))
return 0;
#ifndef CONFIG_IDEDMA_IVB

--

2006-10-10 17:21:39

by Greg KH

[permalink] [raw]
Subject: [patch 10/19] Video: Fix msp343xG handling regression

-stable review patch. If anyone has any objections, please let us know.

------------------
From: Hans Verkuil <[email protected]>

The msp3430G and msp3435G models cannot do Automatic Standard Detection,
so these should be forced to BTSC. These chips are early production
versions for the msp34xxG series and are quite rare.

Due to broken handling of the 'standard' option in 2.6.17, there is
no workaround possible.

Signed-off-by: Hans Verkuil <[email protected]>
Signed-off-by: Michael Krufky <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/media/video/msp3400-driver.c | 2 ++
drivers/media/video/msp3400-driver.h | 1 +
drivers/media/video/msp3400-kthreads.c | 7 ++++---
3 files changed, 7 insertions(+), 3 deletions(-)

--- linux-2.6.17.13.orig/drivers/media/video/msp3400-driver.c
+++ linux-2.6.17.13/drivers/media/video/msp3400-driver.c
@@ -942,6 +942,8 @@ static int msp_attach(struct i2c_adapter
state->has_virtual_dolby_surround = msp_revision == 'G' && msp_prod_lo == 1;
/* Has Virtual Dolby Surround & Dolby Pro Logic: only in msp34x2 */
state->has_dolby_pro_logic = msp_revision == 'G' && msp_prod_lo == 2;
+ /* The msp343xG supports BTSC only and cannot do Automatic Standard Detection. */
+ state->force_btsc = msp_family == 3 && msp_revision == 'G' && msp_prod_hi == 3;

state->opmode = opmode;
if (state->opmode == OPMODE_AUTO) {
--- linux-2.6.17.13.orig/drivers/media/video/msp3400-driver.h
+++ linux-2.6.17.13/drivers/media/video/msp3400-driver.h
@@ -64,6 +64,7 @@ struct msp_state {
u8 has_sound_processing;
u8 has_virtual_dolby_surround;
u8 has_dolby_pro_logic;
+ u8 force_btsc;

int radio;
int opmode;
--- linux-2.6.17.13.orig/drivers/media/video/msp3400-kthreads.c
+++ linux-2.6.17.13/drivers/media/video/msp3400-kthreads.c
@@ -949,11 +949,12 @@ int msp34xxg_thread(void *data)

/* setup the chip*/
msp34xxg_reset(client);
- state->std = state->radio ? 0x40 : msp_standard;
- if (state->std != 1)
- goto unmute;
+ state->std = state->radio ? 0x40 :
+ (state->force_btsc && msp_standard == 1) ? 32 : msp_standard;
/* start autodetect */
msp_write_dem(client, 0x20, state->std);
+ if (state->std != 1)
+ goto unmute;

/* watch autodetect */
v4l_dbg(1, msp_debug, client, "started autodetect, waiting for result\n");

--

2006-10-10 17:20:21

by Greg KH

[permalink] [raw]
Subject: [patch 11/19] Video: cx24123: fix PLL divisor setup

-stable review patch. If anyone has any objections, please let us know.

------------------
From: Yeasah Pell <[email protected]>

The cx24109 datasheet says: "NOTE: if A=0, then N=N+1"

The current code is the result of a misinterpretation of the datasheet to
mean exactly the opposite of the requirement -- The actual value of N is 1 greater than the value written when A is 0, so 1 needs to be *subtracted*
from it to compensate.

Signed-off-by: Yeasah Pell <[email protected]>
Signed-off-by: Steven Toth <[email protected]>
Signed-off-by: Michael Krufky <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/media/dvb/frontends/cx24123.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)

--- linux-2.6.17.13.orig/drivers/media/dvb/frontends/cx24123.c
+++ linux-2.6.17.13/drivers/media/dvb/frontends/cx24123.c
@@ -579,8 +579,8 @@ static int cx24123_pll_calculate(struct
ndiv = ( ((p->frequency * vco_div * 10) / (2 * XTAL / 1000)) / 32) & 0x1ff;
adiv = ( ((p->frequency * vco_div * 10) / (2 * XTAL / 1000)) % 32) & 0x1f;

- if (adiv == 0)
- ndiv++;
+ if (adiv == 0 && ndiv > 0)
+ ndiv--;

/* control bits 11, refdiv 11, charge pump polarity 1, charge pump current, ndiv, adiv */
state->pllarg = (3 << 19) | (3 << 17) | (1 << 16) | (pump << 14) | (ndiv << 5) | adiv;

--

2006-10-10 17:20:22

by Greg KH

[permalink] [raw]
Subject: [patch 03/19] SUNRPC: avoid choosing an IPMI port for RPC traffic

-stable review patch. If anyone has any objections, please let us know.

------------------
From: Chuck Lever <[email protected]>

Some hardware uses port 664 for its hardware-based IPMI listener. Teach
the RPC client to avoid using that port by raising the default minimum port
number to 665.

Test plan:
Find a mainboard known to use port 664 for IPMI; enable IPMI; mount NFS
servers in a tight loop.

Signed-off-by: Chuck Lever <[email protected]>
Signed-off-by: Trond Myklebust <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
include/linux/sunrpc/xprt.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- linux-2.6.17.13.orig/include/linux/sunrpc/xprt.h
+++ linux-2.6.17.13/include/linux/sunrpc/xprt.h
@@ -37,7 +37,7 @@ extern unsigned int xprt_max_resvport;

#define RPC_MIN_RESVPORT (1U)
#define RPC_MAX_RESVPORT (65535U)
-#define RPC_DEF_MIN_RESVPORT (650U)
+#define RPC_DEF_MIN_RESVPORT (665U)
#define RPC_DEF_MAX_RESVPORT (1023U)

/*

--

2006-10-10 17:19:40

by Greg KH

[permalink] [raw]
Subject: [patch 14/19] PKT_SCHED: cls_basic: Use unsigned int when generating handle

-stable review patch. If anyone has any objections, please let us know.

------------------
From: David Miller <[email protected]>

Prevents filters from being added if the first generated
handle already exists.

Signed-off-by: Kim Nordlund <[email protected]>
Signed-off-by: Thomas Graf <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
net/sched/cls_basic.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- linux-2.6.17.13.orig/net/sched/cls_basic.c
+++ linux-2.6.17.13/net/sched/cls_basic.c
@@ -197,7 +197,7 @@ static int basic_change(struct tcf_proto
if (handle)
f->handle = handle;
else {
- int i = 0x80000000;
+ unsigned int i = 0x80000000;
do {
if (++head->hgenerator == 0x7FFFFFFF)
head->hgenerator = 1;

--

2006-10-10 17:59:50

by Greg KH

[permalink] [raw]
Subject: Re: [stable] [patch 00/19] 2.6.17-stable review

On Tue, Oct 10, 2006 at 10:13:50AM -0700, Greg KH wrote:
> This is the start of the stable review cycle for the 2.6.17.14 release.
> There are 19 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 Thursday, Octover 12, 18:00:00 UTC.
> Anything received after that time might be too late.

An all-in-one patch for this can be found at:
http://www.kernel.org/pub/linux/kernel/people/gregkh/stable/patch-2.6.17.14-rc1.gz
if anyone wants to test this out that way.

Also, this is probably going to be the last 2.6.17-stable release,
unless there is something major that we are missing here in this one.

thanks,

greg k-h

2006-10-10 18:13:37

by Hugh Dickins

[permalink] [raw]
Subject: Re: [patch 07/19] invalidate_complete_page() race fix

On Tue, 10 Oct 2006, Greg KH wrote:

> -stable review patch. If anyone has any objections, please let us know.
>
> ------------------
> From: Andrew Morton <[email protected]>
>
> If a CPU faults this page into pagetables after invalidate_mapping_pages()
> checked page_mapped(), invalidate_complete_page() will still proceed to remove
> the page from pagecache. This leaves the page-faulting process with a
> detached page. If it was MAP_SHARED then file data loss will ensue.
>
> Fix that up by checking the page's refcount after taking tree_lock.

I may have lost the plot, but I think this patch has already proved
to cause problems for NFS in 2.6.18: not good to put it into 2.6.17
stable while it's awaiting refinement for 2.6.18 stable.

Hugh

2006-10-10 19:15:15

by Greg KH

[permalink] [raw]
Subject: Re: [stable] [patch 07/19] invalidate_complete_page() race fix

On Tue, Oct 10, 2006 at 07:12:54PM +0100, Hugh Dickins wrote:
> On Tue, 10 Oct 2006, Greg KH wrote:
>
> > -stable review patch. If anyone has any objections, please let us know.
> >
> > ------------------
> > From: Andrew Morton <[email protected]>
> >
> > If a CPU faults this page into pagetables after invalidate_mapping_pages()
> > checked page_mapped(), invalidate_complete_page() will still proceed to remove
> > the page from pagecache. This leaves the page-faulting process with a
> > detached page. If it was MAP_SHARED then file data loss will ensue.
> >
> > Fix that up by checking the page's refcount after taking tree_lock.
>
> I may have lost the plot, but I think this patch has already proved
> to cause problems for NFS in 2.6.18: not good to put it into 2.6.17
> stable while it's awaiting refinement for 2.6.18 stable.

Ok, I've dropped it now.

thanks,

greg k-h

2006-10-10 19:29:32

by Jan Engelhardt

[permalink] [raw]
Subject: Re: [patch 03/19] SUNRPC: avoid choosing an IPMI port for RPC traffic


>Some hardware uses port 664 for its hardware-based IPMI listener. Teach
>the RPC client to avoid using that port by raising the default minimum port
>number to 665.

Eh, that does look more like a quick hack. What if there were enough
manufacturers around to use various parts, like manuf. A using 664, B using 800
and C using 1000? Then the port range would have to be cut down again and
again.


-`J'
--
[A

2006-10-10 19:31:52

by Andrew Morton

[permalink] [raw]
Subject: Re: [stable] [patch 07/19] invalidate_complete_page() race fix

On Tue, 10 Oct 2006 12:14:18 -0700
Greg KH <[email protected]> wrote:

> On Tue, Oct 10, 2006 at 07:12:54PM +0100, Hugh Dickins wrote:
> > On Tue, 10 Oct 2006, Greg KH wrote:
> >
> > > -stable review patch. If anyone has any objections, please let us know.
> > >
> > > ------------------
> > > From: Andrew Morton <[email protected]>
> > >
> > > If a CPU faults this page into pagetables after invalidate_mapping_pages()
> > > checked page_mapped(), invalidate_complete_page() will still proceed to remove
> > > the page from pagecache. This leaves the page-faulting process with a
> > > detached page. If it was MAP_SHARED then file data loss will ensue.
> > >
> > > Fix that up by checking the page's refcount after taking tree_lock.
> >
> > I may have lost the plot, but I think this patch has already proved
> > to cause problems for NFS in 2.6.18: not good to put it into 2.6.17
> > stable while it's awaiting refinement for 2.6.18 stable.
>
> Ok, I've dropped it now.
>

It needs invalidate_inode_pages2-ignore-page-refcounts.patch as well.

This patch (invalidate_complete_page() race fix) fixes a cramfs unmount
race and, iirc, a pagefault-vs-invalidate race which Nick was seeing.
So applying both patches would make 2.6.17 a better place, but we could live
without them.

2006-10-11 23:46:06

by Myklebust, Trond

[permalink] [raw]
Subject: Re: [patch 03/19] SUNRPC: avoid choosing an IPMI port for RPC traffic

On Tue, 2006-10-10 at 20:59 +0200, Jan Engelhardt wrote:
> >Some hardware uses port 664 for its hardware-based IPMI listener. Teach
> >the RPC client to avoid using that port by raising the default minimum port
> >number to 665.
>
> Eh, that does look more like a quick hack. What if there were enough
> manufacturers around to use various parts, like manuf. A using 664, B using 800
> and C using 1000? Then the port range would have to be cut down again and
> again.
>
>
> -`J'

Feel free to tell the board manufacturers that they are idiots, and
should not design boards that hijack specific ports without providing
the O/S with any means of detecting this, but in the meantime, it _is_
the case that they are doing this.

Cheers,
Trond

2006-10-12 00:48:45

by Alan

[permalink] [raw]
Subject: Re: [patch 03/19] SUNRPC: avoid choosing an IPMI port for RPC traffic

Ar Mer, 2006-10-11 am 19:45 -0400, ysgrifennodd Trond Myklebust:
> Feel free to tell the board manufacturers that they are idiots, and
> should not design boards that hijack specific ports without providing
> the O/S with any means of detecting this, but in the meantime, it _is_
> the case that they are doing this.

Then their hardware is faulty and should be specifically blacklisted not
make everyone have to deal with silly unmaintainable hacks.

Alan

2006-10-12 01:35:23

by Myklebust, Trond

[permalink] [raw]
Subject: Re: [patch 03/19] SUNRPC: avoid choosing an IPMI port for RPC traffic

On Thu, 2006-10-12 at 02:12 +0100, Alan Cox wrote:
> Ar Mer, 2006-10-11 am 19:45 -0400, ysgrifennodd Trond Myklebust:
> > Feel free to tell the board manufacturers that they are idiots, and
> > should not design boards that hijack specific ports without providing
> > the O/S with any means of detecting this, but in the meantime, it _is_
> > the case that they are doing this.
>
> Then their hardware is faulty and should be specifically blacklisted not
> make everyone have to deal with silly unmaintainable hacks.

They are not hacks. The actual range of ports used by the RPC client is
set using /proc/sys/sunrpc/(min|max)_resvport. People that don't have
broken motherboards can override the default range, which is all that we
are changing here.

To be fair, the motherboard manufacturers have actually registered these
ports with IANA:

asf-rmcp 623/tcp ASF Remote Management and Control Protocol
asf-rmcp 623/udp ASF Remote Management and Control Protocol

asf-secure-rmcp 664/tcp ASF Secure Remote Management and Control Protocol
asf-secure-rmcp 664/udp ASF Secure Remote Management and Control Protocol

but the problem remains that we have no way to actually detect a
motherboard that uses those ports.

Interestingly, Linux is not the only OS that has been hit by this
problem:

http://blogs.sun.com/shepler/entry/port_623_or_the_mount

Cheers,
Trond

2006-10-12 01:53:08

by Matt Domsch

[permalink] [raw]
Subject: Re: [patch 03/19] SUNRPC: avoid choosing an IPMI port for RPC traffic

On Wed, Oct 11, 2006 at 06:35:05PM -0700, Trond Myklebust wrote:
> On Thu, 2006-10-12 at 02:12 +0100, Alan Cox wrote:
> > Ar Mer, 2006-10-11 am 19:45 -0400, ysgrifennodd Trond Myklebust:
> > > Feel free to tell the board manufacturers that they are idiots, and
> > > should not design boards that hijack specific ports without providing
> > > the O/S with any means of detecting this, but in the meantime, it _is_
> > > the case that they are doing this.
> >
> > Then their hardware is faulty and should be specifically blacklisted not
> > make everyone have to deal with silly unmaintainable hacks.
>
> They are not hacks. The actual range of ports used by the RPC client is
> set using /proc/sys/sunrpc/(min|max)_resvport. People that don't have
> broken motherboards can override the default range, which is all that we
> are changing here.
>
> To be fair, the motherboard manufacturers have actually registered these
> ports with IANA:
>
> asf-rmcp 623/tcp ASF Remote Management and Control Protocol
> asf-rmcp 623/udp ASF Remote Management and Control Protocol
>
> asf-secure-rmcp 664/tcp ASF Secure Remote Management and Control Protocol
> asf-secure-rmcp 664/udp ASF Secure Remote Management and Control Protocol
>
> but the problem remains that we have no way to actually detect a
> motherboard that uses those ports.

My hackish solution was to create a fake xinetd service listening on
those ports.

http://lists.us.dell.com/pipermail/linux-poweredge/2005-November/023606.html

For the one Dell server affected, we could DMI list
it; likewise for others.


--
Matt Domsch
Software Architect
Dell Linux Solutions linux.dell.com & http://www.dell.com/linux
Linux on Dell mailing lists @ http://lists.us.dell.com

2006-10-12 02:04:14

by Myklebust, Trond

[permalink] [raw]
Subject: Re: [patch 03/19] SUNRPC: avoid choosing an IPMI port for RPC traffic

On Wed, 2006-10-11 at 20:53 -0500, Matt Domsch wrote:
> My hackish solution was to create a fake xinetd service listening on
> those ports.
>
> http://lists.us.dell.com/pipermail/linux-poweredge/2005-November/023606.html
>
> For the one Dell server affected, we could DMI list
> it; likewise for others.

Right, but that requires prior knowledge that the board in question is
afflicted. Several people that were affected by the bug were unaware of
the motherboard behaviour.
The daemon solution also fails to provide any guarantees on a NFSROOT
setup.

In any case, as I said, these are just defaults which may be overridden
by the user at runtime.

Cheers,
Trond

2006-10-12 08:29:43

by Jan Engelhardt

[permalink] [raw]
Subject: Re: [patch 03/19] SUNRPC: avoid choosing an IPMI port for RPC traffic


>Interestingly, Linux is not the only OS that has been hit by this
>problem:
>
> http://blogs.sun.com/shepler/entry/port_623_or_the_mount

There is more to it. On a machine I had set up a second,
experimental, apache on port 880. And it randomly failed to start on
a boot because mountd had taken the port first.
Man, this RPC stuff should go and use fixed ports.


-`J'
--

2006-10-12 08:43:58

by Bernd Petrovitsch

[permalink] [raw]
Subject: Re: [patch 03/19] SUNRPC: avoid choosing an IPMI port for RPC traffic

On Thu, 2006-10-12 at 09:58 +0200, Jan Engelhardt wrote:
> >Interestingly, Linux is not the only OS that has been hit by this
> >problem:
> >
> > http://blogs.sun.com/shepler/entry/port_623_or_the_mount
>
> There is more to it. On a machine I had set up a second,
> experimental, apache on port 880. And it randomly failed to start on
> a boot because mountd had taken the port first.

FWIW I had the same experience several times with port 631 (aka "IPP")
taken by some RPC service and CUPS simply didn't worked.

> Man, this RPC stuff should go and use fixed ports.

Hmm, starting the portmapper as late as possible so that other services
get the chance to use their ports?

Bernd
--
Firmix Software GmbH http://www.firmix.at/
mobil: +43 664 4416156 fax: +43 1 7890849-55
Embedded Linux Development and Services

2006-10-12 09:51:30

by Alan

[permalink] [raw]
Subject: Re: [patch 03/19] SUNRPC: avoid choosing an IPMI port for RPC traffic

Ar Mer, 2006-10-11 am 20:53 -0500, ysgrifennodd Matt Domsch:
> > > Then their hardware is faulty and should be specifically blacklisted not
> > > make everyone have to deal with silly unmaintainable hacks.
> >
> > They are not hacks. The actual range of ports used by the RPC client is
> > set using /proc/sys/sunrpc/(min|max)_resvport. People that don't have
> > broken motherboards can override the default range, which is all that we
> > are changing here.

No.. you have it backwards. The tiny tiny number of people with broken
boards can either set it themselves, use DMI, or ram the offending board
somewhere dark belonging to whoever sold it to them

> > To be fair, the motherboard manufacturers have actually registered these
> > ports with IANA:

This is irrelevant, they are stealing bits out of the incoming network
stream. That's not just rude its dangerous - they should have their own
MAC and IP stack for this. Port assignments are courtesy numbering to
avoid collisions on your own stack. They have no more right to steal
packets from that port than CERN does to claim all port 80 traffic on
the internet.

Why do I say dangerous - because they steal the data *before* your Linux
firewalling and feed it to an unauditable binary firmware which has
controlling access to large parts of the system without the OS even
seeing it.

Not a good idea IMHO on any box facing even a slightly insecure port.

> For the one Dell server affected, we could DMI list
> it; likewise for others.

This should be done with DMI I agree.


2006-10-12 09:51:54

by Alan

[permalink] [raw]
Subject: Re: [patch 03/19] SUNRPC: avoid choosing an IPMI port for RPC traffic

Ar Mer, 2006-10-11 am 19:04 -0700, ysgrifennodd Trond Myklebust:
> The daemon solution also fails to provide any guarantees on a NFSROOT
> setup.

You know the ports that will be used at NFSroot setup time and they
won't currently get near the broken box problem ports. Also NFS root is
pretty much obsoleted by the initrd/pivot_root stuff.


Alan

2006-10-12 13:03:42

by Jan Engelhardt

[permalink] [raw]
Subject: Re: [patch 03/19] SUNRPC: avoid choosing an IPMI port for RPC traffic


>> Man, this RPC stuff should go and use fixed ports.
>
>Hmm, starting the portmapper as late as possible so that other services
>get the chance to use their ports?

The SUN-TCP / SUN-UDP port mapping is a relic of old times.


-`J'
--

2006-10-12 15:01:44

by Myklebust, Trond

[permalink] [raw]
Subject: Re: [patch 03/19] SUNRPC: avoid choosing an IPMI port for RPC traffic

On Thu, 2006-10-12 at 09:58 +0200, Jan Engelhardt wrote:
> >Interestingly, Linux is not the only OS that has been hit by this
> >problem:
> >
> > http://blogs.sun.com/shepler/entry/port_623_or_the_mount
>
> There is more to it. On a machine I had set up a second,
> experimental, apache on port 880. And it randomly failed to start on
> a boot because mountd had taken the port first.
> Man, this RPC stuff should go and use fixed ports.

man 8 mountd and check out the '-p' option. statd has a similar one.
Even the in-kernel lockd daemon's can be set to listen to fixed ports.

So there really shouldn't be any problems nailing down your RPC ports.

Cheers,
Trond

2006-10-12 15:46:35

by Myklebust, Trond

[permalink] [raw]
Subject: Re: [patch 03/19] SUNRPC: avoid choosing an IPMI port for RPC traffic

On Thu, 2006-10-12 at 11:15 +0100, Alan Cox wrote:
> Ar Mer, 2006-10-11 am 20:53 -0500, ysgrifennodd Matt Domsch:
> > > > Then their hardware is faulty and should be specifically blacklisted not
> > > > make everyone have to deal with silly unmaintainable hacks.
> > >
> > > They are not hacks. The actual range of ports used by the RPC client is
> > > set using /proc/sys/sunrpc/(min|max)_resvport. People that don't have
> > > broken motherboards can override the default range, which is all that we
> > > are changing here.
>
> No.. you have it backwards. The tiny tiny number of people with broken
> boards can either set it themselves, use DMI, or ram the offending board
> somewhere dark belonging to whoever sold it to them

:-)

The main problem with that approach is that the offending boardmakers
tend to hide these details deep in technical docs that are not bundled
with the motherboard, and which consequently nobody actually reads.
Instead they see that NFS doesn't work, and conclude to waste NFS
community's time in debugging it.

We're still leaving a fairly large range of ports for the NFS client to
use: there should be 373 that are rife for the taking.

> > > To be fair, the motherboard manufacturers have actually registered these
> > > ports with IANA:
>
> This is irrelevant, they are stealing bits out of the incoming network
> stream. That's not just rude its dangerous - they should have their own
> MAC and IP stack for this. Port assignments are courtesy numbering to
> avoid collisions on your own stack. They have no more right to steal
> packets from that port than CERN does to claim all port 80 traffic on
> the internet.
>
> Why do I say dangerous - because they steal the data *before* your Linux
> firewalling and feed it to an unauditable binary firmware which has
> controlling access to large parts of the system without the OS even
> seeing it.
>
> Not a good idea IMHO on any box facing even a slightly insecure port.

No arguments with this.

2006-10-12 16:19:55

by Jan Engelhardt

[permalink] [raw]
Subject: Re: [patch 03/19] SUNRPC: avoid choosing an IPMI port for RPC traffic


>man 8 mountd and check out the '-p' option. statd has a similar one.
>Even the in-kernel lockd daemon's can be set to listen to fixed ports.
>
>So there really shouldn't be any problems nailing down your RPC ports.

Thank you for the hint. However, poking /etc/init.d/nfsserver to use
the -p option is probably just as bad as adding "mountd 49500/tcp" to
/etc/services I am currently doing -- both get reverted on a distro
upgrade. Switching to CIFS will probably solve it all - one port
instead of three/four (and a fixed one), much more firewall- and
initscript-friendly.


-`J'
--